From 1f19f33e45791ea59aed048796fc68672c6723a5 Mon Sep 17 00:00:00 2001 From: Jacob McDonnell Date: Sat, 25 Apr 2026 19:59:05 -0400 Subject: docs: Removed Precompiled HTML --- static/freebsd/man1/builtin.1 3.html | 891 -- static/freebsd/man1/intro.1 3.html | 72 - static/freebsd/man3/ATOMIC_VAR_INIT.3 3.html | 315 - static/freebsd/man3/CMSG_DATA.3 3.html | 211 - static/freebsd/man3/Q_FRAWMASK.3 3.html | 101 - static/freebsd/man3/Q_IFRAWMASK.3 3.html | 133 - static/freebsd/man3/Q_INI.3 3.html | 216 - static/freebsd/man3/Q_IRAWMASK.3 3.html | 101 - static/freebsd/man3/Q_QABS.3 4.html | 84 - static/freebsd/man3/Q_QADDI.3 3.html | 113 - static/freebsd/man3/Q_QADDQ.3 3.html | 144 - static/freebsd/man3/Q_SIGNED.3 3.html | 158 - static/freebsd/man3/Q_SIGNSHFT.3 3.html | 120 - static/freebsd/man3/alloca.3 3.html | 84 - static/freebsd/man3/arb.3 3.html | 550 -- static/freebsd/man3/assert.3 3.html | 109 - static/freebsd/man3/bitstring.3 3.html | 380 - static/freebsd/man3/end.3 4.html | 61 - static/freebsd/man3/fpgetround.3 4.html | 161 - static/freebsd/man3/intro.3 3.html | 262 - static/freebsd/man3/makedev.3 3.html | 88 - static/freebsd/man3/offsetof.3 4.html | 46 - static/freebsd/man3/pthread.3 3.html | 466 - static/freebsd/man3/pthread_affinity_np.3 3.html | 138 - static/freebsd/man3/pthread_atfork.3 3.html | 95 - static/freebsd/man3/pthread_attr.3 3.html | 272 - .../freebsd/man3/pthread_attr_affinity_np.3 3.html | 140 - static/freebsd/man3/pthread_attr_get_np.3 3.html | 122 - .../man3/pthread_attr_setcreatesuspend_np.3 3.html | 77 - .../freebsd/man3/pthread_barrier_destroy.3 3.html | 131 - static/freebsd/man3/pthread_barrierattr.3 3.html | 126 - static/freebsd/man3/pthread_cancel.3 3.html | 94 - static/freebsd/man3/pthread_cleanup_pop.3 4.html | 71 - static/freebsd/man3/pthread_cleanup_push.3 4.html | 72 - .../freebsd/man3/pthread_cond_broadcast.3 4.html | 73 - static/freebsd/man3/pthread_cond_destroy.3 4.html | 80 - static/freebsd/man3/pthread_cond_init.3 3.html | 82 - static/freebsd/man3/pthread_cond_signal.3 4.html | 73 - .../freebsd/man3/pthread_cond_timedwait.3 3.html | 93 - static/freebsd/man3/pthread_cond_wait.3 3.html | 92 - static/freebsd/man3/pthread_condattr.3 3.html | 154 - static/freebsd/man3/pthread_create.3 3.html | 118 - static/freebsd/man3/pthread_detach.3 3.html | 77 - static/freebsd/man3/pthread_equal.3 4.html | 65 - static/freebsd/man3/pthread_exit.3 3.html | 94 - .../freebsd/man3/pthread_getconcurrency.3 3.html | 98 - static/freebsd/man3/pthread_getcpuclockid.3 4.html | 83 - static/freebsd/man3/pthread_getspecific.3 3.html | 80 - .../freebsd/man3/pthread_getthreadid_np.3 4.html | 63 - static/freebsd/man3/pthread_join.3 3.html | 155 - static/freebsd/man3/pthread_key_create.3 3.html | 96 - static/freebsd/man3/pthread_key_delete.3 3.html | 86 - static/freebsd/man3/pthread_kill.3 4.html | 74 - static/freebsd/man3/pthread_main_np.3 4.html | 63 - static/freebsd/man3/pthread_multi_np.3 4.html | 68 - .../freebsd/man3/pthread_mutex_consistent.3 3.html | 88 - static/freebsd/man3/pthread_mutex_destroy.3 4.html | 72 - static/freebsd/man3/pthread_mutex_init.3 3.html | 76 - static/freebsd/man3/pthread_mutex_lock.3 3.html | 83 - .../freebsd/man3/pthread_mutex_timedlock.3 3.html | 103 - static/freebsd/man3/pthread_mutex_trylock.3 3.html | 83 - static/freebsd/man3/pthread_mutex_unlock.3 3.html | 81 - static/freebsd/man3/pthread_mutexattr.3 3.html | 307 - .../man3/pthread_mutexattr_getkind_np.3 3.html | 82 - static/freebsd/man3/pthread_np.3 3.html | 179 - static/freebsd/man3/pthread_once.3 3.html | 84 - static/freebsd/man3/pthread_resume_all_np.3 4.html | 54 - static/freebsd/man3/pthread_resume_np.3 3.html | 76 - .../freebsd/man3/pthread_rwlock_destroy.3 4.html | 82 - static/freebsd/man3/pthread_rwlock_init.3 3.html | 96 - static/freebsd/man3/pthread_rwlock_rdlock.3 3.html | 119 - .../man3/pthread_rwlock_timedrdlock.3 3.html | 112 - .../man3/pthread_rwlock_timedwrlock.3 3.html | 104 - static/freebsd/man3/pthread_rwlock_unlock.3 3.html | 82 - static/freebsd/man3/pthread_rwlock_wrlock.3 3.html | 106 - .../man3/pthread_rwlockattr_destroy.3 3.html | 74 - .../man3/pthread_rwlockattr_getpshared.3 3.html | 86 - .../freebsd/man3/pthread_rwlockattr_init.3 4.html | 75 - .../man3/pthread_rwlockattr_setpshared.3 3.html | 89 - static/freebsd/man3/pthread_schedparam.3 3.html | 99 - static/freebsd/man3/pthread_self.3 4.html | 61 - static/freebsd/man3/pthread_set_name_np.3 3.html | 110 - static/freebsd/man3/pthread_setspecific.3 3.html | 91 - static/freebsd/man3/pthread_sigmask.3 3.html | 88 - .../freebsd/man3/pthread_signals_block_np.3 3.html | 94 - static/freebsd/man3/pthread_sigqueue.3 3.html | 85 - static/freebsd/man3/pthread_spin_init.3 3.html | 104 - static/freebsd/man3/pthread_spin_lock.3 3.html | 122 - .../freebsd/man3/pthread_suspend_all_np.3 4.html | 61 - static/freebsd/man3/pthread_suspend_np.3 3.html | 82 - static/freebsd/man3/pthread_testcancel.3 3.html | 302 - static/freebsd/man3/pthread_yield.3 4.html | 51 - static/freebsd/man3/qmath.3 3.html | 606 -- static/freebsd/man3/queue.3 3.html | 1187 --- static/freebsd/man3/sigevent.3 3.html | 134 - static/freebsd/man3/siginfo.3 3.html | 528 -- static/freebsd/man3/snl.3 3.html | 395 - static/freebsd/man3/stats.3 3.html | 725 -- static/freebsd/man3/stdarg.3 3.html | 182 - static/freebsd/man3/stdbit.3 4.html | 136 - static/freebsd/man3/stdckdint.3 3.html | 106 - static/freebsd/man3/sysexits.3 3.html | 136 - static/freebsd/man3/tgmath.3 3.html | 262 - static/freebsd/man3/timeradd.3 4.html | 152 - static/freebsd/man3/tree.3 3.html | 818 -- static/freebsd/man3lua/intro.3lua 4.html | 46 - static/freebsd/man4/aac.4 3.html | 196 - static/freebsd/man4/aacraid.4 3.html | 111 - static/freebsd/man4/acpi.4 3.html | 552 -- static/freebsd/man4/acpi_asus.4 4.html | 132 - static/freebsd/man4/acpi_asus_wmi.4 3.html | 83 - static/freebsd/man4/acpi_battery.4 3.html | 318 - static/freebsd/man4/acpi_dock.4 4.html | 52 - static/freebsd/man4/acpi_fujitsu.4 3.html | 159 - static/freebsd/man4/acpi_ged.4 4.html | 54 - static/freebsd/man4/acpi_hp.4 3.html | 284 - static/freebsd/man4/acpi_ibm.4 3.html | 455 - static/freebsd/man4/acpi_panasonic.4 3.html | 152 - static/freebsd/man4/acpi_rapidstart.4 3.html | 75 - static/freebsd/man4/acpi_sony.4 4.html | 73 - static/freebsd/man4/acpi_thermal.4 3.html | 129 - static/freebsd/man4/acpi_toshiba.4 3.html | 110 - static/freebsd/man4/acpi_video.4 3.html | 85 - static/freebsd/man4/acpi_wmi.4 3.html | 124 - static/freebsd/man4/ada.4 3.html | 151 - static/freebsd/man4/adm6996fc.4 4.html | 66 - static/freebsd/man4/ads111x.4 3.html | 223 - static/freebsd/man4/ae.4 3.html | 134 - static/freebsd/man4/aesni.4 3.html | 87 - static/freebsd/man4/age.4 3.html | 146 - static/freebsd/man4/agp.4 3.html | 171 - static/freebsd/man4/ahc.4 3.html | 372 - static/freebsd/man4/ahci.4 3.html | 189 - static/freebsd/man4/ahd.4 3.html | 192 - static/freebsd/man4/aibs.4 3.html | 139 - static/freebsd/man4/aio.4 3.html | 174 - static/freebsd/man4/alc.4 3.html | 148 - static/freebsd/man4/ale.4 3.html | 134 - static/freebsd/man4/alpm.4 4.html | 57 - static/freebsd/man4/altq.4 3.html | 141 - static/freebsd/man4/amdpm.4 4.html | 62 - static/freebsd/man4/amdsbwd.4 4.html | 71 - static/freebsd/man4/amdsmb.4 4.html | 52 - static/freebsd/man4/amdsmn.4 4.html | 52 - static/freebsd/man4/amdtemp.4 3.html | 95 - static/freebsd/man4/aout.4 3.html | 106 - static/freebsd/man4/apic.4 3.html | 64 - static/freebsd/man4/appleir.4 3.html | 103 - static/freebsd/man4/aq.4 4.html | 60 - static/freebsd/man4/arcmsr.4 3.html | 129 - static/freebsd/man4/arswitch.4 3.html | 71 - static/freebsd/man4/asmc.4 3.html | 164 - static/freebsd/man4/at45d.4 3.html | 150 - static/freebsd/man4/ata.4 3.html | 225 - static/freebsd/man4/ath.4 3.html | 233 - static/freebsd/man4/ath10k.4 3.html | 94 - static/freebsd/man4/ath_hal.4 3.html | 334 - static/freebsd/man4/atkbd.4 3.html | 205 - static/freebsd/man4/atkbdc.4 3.html | 100 - static/freebsd/man4/atopcase.4 4.html | 120 - static/freebsd/man4/atp.4 3.html | 118 - static/freebsd/man4/atrtc.4 4.html | 52 - static/freebsd/man4/attimer.4 3.html | 67 - static/freebsd/man4/audit.4 3.html | 122 - static/freebsd/man4/auditpipe.4 3.html | 219 - static/freebsd/man4/aue.4 3.html | 143 - static/freebsd/man4/autofs.4 3.html | 109 - static/freebsd/man4/aw_gpio.4 4.html | 97 - static/freebsd/man4/aw_mmc.4 4.html | 73 - static/freebsd/man4/aw_rtc.4 4.html | 56 - static/freebsd/man4/aw_sid.4 4.html | 67 - static/freebsd/man4/aw_spi.4 4.html | 50 - static/freebsd/man4/aw_syscon.4 4.html | 49 - static/freebsd/man4/axe.4 3.html | 183 - static/freebsd/man4/axge.4 3.html | 125 - static/freebsd/man4/axp.4 3.html | 154 - static/freebsd/man4/bce.4 3.html | 364 - static/freebsd/man4/bcm5974.4 4.html | 79 - static/freebsd/man4/bcma.4 4.html | 62 - static/freebsd/man4/bfe.4 3.html | 96 - static/freebsd/man4/bge.4 3.html | 220 - static/freebsd/man4/bhnd.4 4.html | 63 - static/freebsd/man4/bhnd_chipc.4 3.html | 69 - static/freebsd/man4/bhnd_pmu.4 4.html | 57 - static/freebsd/man4/bhndb.4 4.html | 63 - static/freebsd/man4/bhndb_pci.4 3.html | 63 - static/freebsd/man4/bhyve.4 4.html | 64 - static/freebsd/man4/blackhole.4 3.html | 105 - static/freebsd/man4/bnxt.4 3.html | 211 - static/freebsd/man4/bnxt_re.4 3.html | 80 - static/freebsd/man4/boottrace.4 3.html | 187 - static/freebsd/man4/bpf.4 3.html | 895 -- static/freebsd/man4/bridge.4 3.html | 523 -- static/freebsd/man4/bwi.4 3.html | 209 - static/freebsd/man4/bwn.4 3.html | 209 - static/freebsd/man4/bxe.4 3.html | 284 - static/freebsd/man4/bytgpio.4 3.html | 52 - static/freebsd/man4/capsicum.4 3.html | 155 - static/freebsd/man4/cardbus.4 4.html | 49 - static/freebsd/man4/carp.4 3.html | 187 - static/freebsd/man4/cas.4 3.html | 93 - static/freebsd/man4/cc_cdg.4 3.html | 129 - static/freebsd/man4/cc_chd.4 3.html | 101 - static/freebsd/man4/cc_cubic.4 3.html | 94 - static/freebsd/man4/cc_dctcp.4 3.html | 113 - static/freebsd/man4/cc_hd.4 3.html | 98 - static/freebsd/man4/cc_htcp.4 3.html | 108 - static/freebsd/man4/cc_newreno.4 3.html | 140 - static/freebsd/man4/cc_vegas.4 3.html | 111 - static/freebsd/man4/ccd.4 3.html | 173 - static/freebsd/man4/ccr.4 3.html | 91 - static/freebsd/man4/cd.4 3.html | 294 - static/freebsd/man4/cd9660.4 4.html | 67 - static/freebsd/man4/cdce.4 3.html | 163 - static/freebsd/man4/cdceem.4 3.html | 100 - static/freebsd/man4/cfi.4 3.html | 80 - static/freebsd/man4/cfiscsi.4 3.html | 88 - static/freebsd/man4/cfumass.4 3.html | 105 - static/freebsd/man4/cgem.4 3.html | 262 - static/freebsd/man4/ch.4 3.html | 278 - static/freebsd/man4/chromebook_platform.4 4.html | 57 - static/freebsd/man4/chvgpio.4 3.html | 57 - static/freebsd/man4/ciss.4 3.html | 164 - static/freebsd/man4/coretemp.4 4.html | 58 - static/freebsd/man4/cp2112.4 3.html | 68 - static/freebsd/man4/cpuctl.4 3.html | 168 - static/freebsd/man4/cpufreq.4 3.html | 279 - static/freebsd/man4/crypto.4 3.html | 275 - static/freebsd/man4/ctl.4 3.html | 205 - static/freebsd/man4/cue.4 3.html | 96 - static/freebsd/man4/cxgb.4 3.html | 109 - static/freebsd/man4/cxgbe.4 3.html | 382 - static/freebsd/man4/cxgbev.4 3.html | 244 - static/freebsd/man4/cyapa.4 3.html | 216 - static/freebsd/man4/da.4 3.html | 199 - static/freebsd/man4/dc.4 3.html | 286 - static/freebsd/man4/dcons.4 3.html | 93 - static/freebsd/man4/dcons_crom.4 4.html | 55 - static/freebsd/man4/ddb.4 3.html | 1449 --- static/freebsd/man4/devctl.4 3.html | 146 - static/freebsd/man4/devfs.4 3.html | 99 - static/freebsd/man4/disc.4 3.html | 51 - static/freebsd/man4/disk.4 3.html | 177 - static/freebsd/man4/divert.4 3.html | 178 - static/freebsd/man4/dpms.4 3.html | 44 - static/freebsd/man4/ds1307.4 3.html | 103 - static/freebsd/man4/ds3231.4 3.html | 116 - static/freebsd/man4/dtrace_audit.4 3.html | 139 - .../freebsd/man4/dtrace_callout_execute.4 3.html | 85 - static/freebsd/man4/dtrace_cam.4 4.html | 69 - static/freebsd/man4/dtrace_dtrace.4 3.html | 228 - static/freebsd/man4/dtrace_fbt.4 3.html | 352 - static/freebsd/man4/dtrace_io.4 3.html | 109 - static/freebsd/man4/dtrace_ip.4 3.html | 265 - static/freebsd/man4/dtrace_kinst.4 3.html | 89 - static/freebsd/man4/dtrace_lockstat.4 3.html | 254 - static/freebsd/man4/dtrace_pid.4 3.html | 142 - static/freebsd/man4/dtrace_priv.4 4.html | 80 - static/freebsd/man4/dtrace_proc.4 3.html | 213 - static/freebsd/man4/dtrace_profile.4 3.html | 177 - static/freebsd/man4/dtrace_sched.4 3.html | 206 - static/freebsd/man4/dtrace_sctp.4 3.html | 247 - static/freebsd/man4/dtrace_tcp.4 3.html | 482 - static/freebsd/man4/dtrace_udp.4 3.html | 199 - static/freebsd/man4/dtrace_udplite.4 3.html | 204 - static/freebsd/man4/dtrace_vfs.4 3.html | 108 - static/freebsd/man4/dummymbuf.4 3.html | 182 - static/freebsd/man4/dummynet.4 3.html | 81 - static/freebsd/man4/e6000sw.4 3.html | 59 - static/freebsd/man4/e6060sw.4 3.html | 78 - static/freebsd/man4/edsc.4 3.html | 69 - static/freebsd/man4/efidev.4 3.html | 142 - static/freebsd/man4/ehci.4 3.html | 81 - static/freebsd/man4/em.4 3.html | 243 - static/freebsd/man4/ena.4 3.html | 564 -- static/freebsd/man4/enc.4 3.html | 115 - static/freebsd/man4/enic.4 4.html | 73 - static/freebsd/man4/epair.4 3.html | 109 - static/freebsd/man4/est.4 3.html | 116 - static/freebsd/man4/et.4 3.html | 132 - static/freebsd/man4/etherswitch.4 3.html | 59 - static/freebsd/man4/eventtimers.4 3.html | 130 - static/freebsd/man4/exca.4 4.html | 30 - static/freebsd/man4/ext2fs.4 3.html | 74 - static/freebsd/man4/fd.4 4.html | 76 - static/freebsd/man4/fdc.4 3.html | 313 - static/freebsd/man4/fdescfs.4 3.html | 141 - static/freebsd/man4/fdt.4 3.html | 176 - static/freebsd/man4/fdt_pinctrl.4 3.html | 111 - static/freebsd/man4/fdtbus.4 3.html | 67 - static/freebsd/man4/ffclock.4 3.html | 113 - static/freebsd/man4/ffs.4 3.html | 273 - static/freebsd/man4/filemon.4 3.html | 205 - static/freebsd/man4/firewire.4 3.html | 91 - static/freebsd/man4/ftgpio.4 4.html | 51 - static/freebsd/man4/ftwd.4 3.html | 52 - static/freebsd/man4/full.4 3.html | 43 - static/freebsd/man4/fusefs.4 3.html | 104 - static/freebsd/man4/fwe.4 3.html | 72 - static/freebsd/man4/fwip.4 3.html | 70 - static/freebsd/man4/fwohci.4 3.html | 102 - static/freebsd/man4/fxp.4 3.html | 170 - static/freebsd/man4/gdb.4 3.html | 515 -- static/freebsd/man4/gem.4 3.html | 86 - static/freebsd/man4/genet.4 3.html | 142 - static/freebsd/man4/genetlink.4 3.html | 147 - static/freebsd/man4/geneve.4 3.html | 279 - static/freebsd/man4/geom.4 3.html | 375 - static/freebsd/man4/geom_linux_lvm.4 3.html | 76 - static/freebsd/man4/geom_uzip.4 3.html | 149 - static/freebsd/man4/geom_zero.4 3.html | 144 - static/freebsd/man4/gif.4 3.html | 239 - static/freebsd/man4/gpio.4 3.html | 148 - static/freebsd/man4/gpioiic.4 3.html | 134 - static/freebsd/man4/gpiokeys.4 3.html | 111 - static/freebsd/man4/gpioled.4 3.html | 140 - static/freebsd/man4/gpioths.4 3.html | 143 - static/freebsd/man4/gre.4 3.html | 215 - static/freebsd/man4/gve.4 3.html | 345 - static/freebsd/man4/h_ertt.4 3.html | 121 - static/freebsd/man4/hconf.4 3.html | 79 - static/freebsd/man4/hcons.4 3.html | 88 - static/freebsd/man4/hgame.4 3.html | 111 - static/freebsd/man4/hidbus.4 3.html | 78 - static/freebsd/man4/hidquirk.4 3.html | 120 - static/freebsd/man4/hidraw.4 3.html | 239 - static/freebsd/man4/hkbd.4 3.html | 174 - static/freebsd/man4/hms.4 4.html | 94 - static/freebsd/man4/hmt.4 3.html | 73 - static/freebsd/man4/hpen.4 4.html | 99 - static/freebsd/man4/hpet.4 3.html | 90 - static/freebsd/man4/hpt27xx.4 3.html | 80 - static/freebsd/man4/hptiop.4 3.html | 100 - static/freebsd/man4/hptmv.4 3.html | 80 - static/freebsd/man4/hptnr.4 4.html | 74 - static/freebsd/man4/hptrr.4 3.html | 105 - static/freebsd/man4/hsctrl.4 4.html | 88 - static/freebsd/man4/htu21.4 3.html | 106 - static/freebsd/man4/hv_kvp.4 3.html | 72 - static/freebsd/man4/hv_netvsc.4 3.html | 64 - static/freebsd/man4/hv_storvsc.4 3.html | 68 - static/freebsd/man4/hv_utils.4 3.html | 65 - static/freebsd/man4/hv_vmbus.4 3.html | 75 - static/freebsd/man4/hv_vss.4 3.html | 348 - static/freebsd/man4/hwpmc.4 3.html | 755 -- static/freebsd/man4/hwpstate_intel.4 3.html | 92 - static/freebsd/man4/hwt.4 3.html | 156 - static/freebsd/man4/i2ctinyusb.4 4.html | 69 - static/freebsd/man4/iavf.4 3.html | 310 - static/freebsd/man4/ice.4 3.html | 969 -- static/freebsd/man4/ichsmb.4 4.html | 47 - static/freebsd/man4/ichwd.4 3.html | 77 - static/freebsd/man4/icmp.4 3.html | 477 - static/freebsd/man4/icmp6.4 3.html | 398 - static/freebsd/man4/ida.4 3.html | 85 - static/freebsd/man4/ietp.4 4.html | 76 - static/freebsd/man4/if_ipsec.4 3.html | 102 - static/freebsd/man4/if_ntb.4 4.html | 75 - static/freebsd/man4/iflib.4 3.html | 242 - static/freebsd/man4/ifmib.4 3.html | 139 - static/freebsd/man4/ig4.4 3.html | 72 - static/freebsd/man4/igc.4 3.html | 134 - static/freebsd/man4/igmp.4 3.html | 117 - static/freebsd/man4/iic.4 3.html | 171 - static/freebsd/man4/iic_gpiomux.4 4.html | 63 - static/freebsd/man4/iicbb.4 4.html | 53 - static/freebsd/man4/iicbus.4 3.html | 174 - static/freebsd/man4/iichid.4 3.html | 84 - static/freebsd/man4/iicmux.4 3.html | 113 - static/freebsd/man4/iicsmb.4 4.html | 49 - static/freebsd/man4/imcsmb.4 3.html | 108 - static/freebsd/man4/inet.4 3.html | 271 - static/freebsd/man4/inet6.4 3.html | 301 - static/freebsd/man4/intpm.4 4.html | 75 - static/freebsd/man4/intro.4 3.html | 164 - static/freebsd/man4/io.4 3.html | 95 - static/freebsd/man4/ioat.4 4.html | 297 - static/freebsd/man4/ip.4 3.html | 581 -- static/freebsd/man4/ip17x.4 4.html | 56 - static/freebsd/man4/ip6.4 3.html | 559 -- static/freebsd/man4/ipfirewall.4 3.html | 112 - static/freebsd/man4/ipheth.4 3.html | 158 - static/freebsd/man4/ipmi.4 3.html | 200 - static/freebsd/man4/ips.4 3.html | 201 - static/freebsd/man4/ipsec.4 3.html | 423 - static/freebsd/man4/ipw.4 4.html | 137 - static/freebsd/man4/ipwfw.4 4.html | 66 - static/freebsd/man4/irdma.4 3.html | 253 - static/freebsd/man4/isci.4 4.html | 87 - static/freebsd/man4/iscsi.4 3.html | 94 - static/freebsd/man4/iser.4 3.html | 79 - static/freebsd/man4/isl.4 3.html | 132 - static/freebsd/man4/ismt.4 4.html | 51 - static/freebsd/man4/isp.4 3.html | 266 - static/freebsd/man4/ispfw.4 4.html | 53 - static/freebsd/man4/itwd.4 4.html | 57 - static/freebsd/man4/iwi.4 3.html | 146 - static/freebsd/man4/iwifw.4 4.html | 66 - static/freebsd/man4/iwlwifi.4 3.html | 208 - static/freebsd/man4/iwlwififw.4 3.html | 9490 -------------------- static/freebsd/man4/iwm.4 4.html | 161 - static/freebsd/man4/iwmfw.4 4.html | 71 - static/freebsd/man4/iwn.4 4.html | 187 - static/freebsd/man4/iwnfw.4 4.html | 83 - static/freebsd/man4/iwx.4 3.html | 131 - static/freebsd/man4/ix.4 3.html | 205 - static/freebsd/man4/ixl.4 3.html | 261 - static/freebsd/man4/jedec_dimm.4 3.html | 193 - static/freebsd/man4/jme.4 3.html | 168 - static/freebsd/man4/kbdmux.4 4.html | 63 - static/freebsd/man4/kcov.4 3.html | 172 - static/freebsd/man4/keyboard.4 3.html | 149 - static/freebsd/man4/kld.4 3.html | 121 - static/freebsd/man4/ksyms.4 3.html | 114 - static/freebsd/man4/ksz8995ma.4 4.html | 67 - static/freebsd/man4/ktls.4 3.html | 192 - static/freebsd/man4/ktr.4 3.html | 161 - static/freebsd/man4/kue.4 4.html | 113 - static/freebsd/man4/kvmclock.4 3.html | 76 - static/freebsd/man4/lagg.4 3.html | 198 - static/freebsd/man4/led.4 4.html | 179 - static/freebsd/man4/lge.4 3.html | 125 - static/freebsd/man4/lindebugfs.4 3.html | 76 - static/freebsd/man4/linprocfs.4 3.html | 164 - static/freebsd/man4/linsysfs.4 4.html | 95 - static/freebsd/man4/linux.4 3.html | 152 - static/freebsd/man4/linuxkpi.4 4.html | 44 - static/freebsd/man4/linuxkpi_wlan.4 3.html | 112 - static/freebsd/man4/liquidio.4 3.html | 117 - static/freebsd/man4/lm75.4 3.html | 144 - static/freebsd/man4/lo.4 3.html | 69 - static/freebsd/man4/lp.4 3.html | 231 - static/freebsd/man4/lpbb.4 4.html | 77 - static/freebsd/man4/lpt.4 3.html | 81 - static/freebsd/man4/ltc430x.4 3.html | 117 - static/freebsd/man4/mac.4 3.html | 287 - static/freebsd/man4/mac_biba.4 3.html | 197 - static/freebsd/man4/mac_bsdextended.4 3.html | 111 - static/freebsd/man4/mac_ddb.4 3.html | 80 - static/freebsd/man4/mac_do.4 3.html | 380 - static/freebsd/man4/mac_ifoff.4 3.html | 88 - static/freebsd/man4/mac_ipacl.4 3.html | 148 - static/freebsd/man4/mac_lomac.4 3.html | 177 - static/freebsd/man4/mac_mls.4 3.html | 212 - static/freebsd/man4/mac_none.4 4.html | 79 - static/freebsd/man4/mac_ntpd.4 3.html | 96 - static/freebsd/man4/mac_partition.4 3.html | 95 - static/freebsd/man4/mac_portacl.4 3.html | 144 - static/freebsd/man4/mac_priority.4 3.html | 101 - static/freebsd/man4/mac_seeotheruids.4 3.html | 93 - static/freebsd/man4/mac_stub.4 3.html | 81 - static/freebsd/man4/mac_test.4 3.html | 82 - static/freebsd/man4/malo.4 3.html | 112 - .../freebsd/man4/man4.aarch64/armv8crypto.4 3.html | 63 - static/freebsd/man4/man4.aarch64/enetc.4 3.html | 63 - static/freebsd/man4/man4.aarch64/felix.4 3.html | 83 - static/freebsd/man4/man4.aarch64/rk_gpio.4 3.html | 54 - static/freebsd/man4/man4.aarch64/rk_grf.4 3.html | 50 - .../freebsd/man4/man4.aarch64/rk_grf_gpio.4 3.html | 53 - static/freebsd/man4/man4.aarch64/rk_i2c.4 3.html | 55 - .../freebsd/man4/man4.aarch64/rk_pinctrl.4 3.html | 55 - .../freebsd/man4/man4.arm/am335x_dmtpps.4 3.html | 133 - static/freebsd/man4/man4.arm/ar40xx.4 3.html | 55 - static/freebsd/man4/man4.arm/bcm283x_pwm.4 3.html | 95 - static/freebsd/man4/man4.arm/devcfg.4 3.html | 84 - static/freebsd/man4/man4.arm/dwcotg.4 3.html | 47 - static/freebsd/man4/man4.arm/imx6_ahci.4 3.html | 48 - static/freebsd/man4/man4.arm/imx6_snvs.4 3.html | 57 - static/freebsd/man4/man4.arm/imx_spi.4 3.html | 69 - static/freebsd/man4/man4.arm/imx_wdog.4 3.html | 77 - static/freebsd/man4/man4.arm/mge.4 3.html | 121 - static/freebsd/man4/man4.arm/ti_adc.4 3.html | 115 - static/freebsd/man4/man4.i386/CPU_ELAN.4 3.html | 102 - static/freebsd/man4/man4.i386/apm.4 3.html | 187 - static/freebsd/man4/man4.i386/glxiic.4 3.html | 89 - static/freebsd/man4/man4.i386/glxsb.4 3.html | 76 - static/freebsd/man4/man4.i386/longrun.4 3.html | 106 - static/freebsd/man4/man4.i386/npx.4 3.html | 72 - static/freebsd/man4/man4.i386/pae.4 3.html | 88 - static/freebsd/man4/man4.i386/pbio.4 3.html | 136 - static/freebsd/man4/man4.i386/pnp.4 3.html | 66 - static/freebsd/man4/man4.i386/pnpbios.4 3.html | 67 - static/freebsd/man4/man4.i386/sbni.4 3.html | 113 - static/freebsd/man4/man4.i386/smapi.4 3.html | 92 - static/freebsd/man4/man4.i386/vpd.4 3.html | 69 - static/freebsd/man4/man4.powerpc/abtn.4 3.html | 79 - static/freebsd/man4/man4.powerpc/adb.4 3.html | 55 - static/freebsd/man4/man4.powerpc/akbd.4 3.html | 84 - static/freebsd/man4/man4.powerpc/ams.4 3.html | 74 - static/freebsd/man4/man4.powerpc/cuda.4 3.html | 65 - static/freebsd/man4/man4.powerpc/dtsec.4 3.html | 100 - static/freebsd/man4/man4.powerpc/llan.4 3.html | 50 - .../freebsd/man4/man4.powerpc/ofw_console.4 3.html | 98 - static/freebsd/man4/man4.powerpc/pmu.4 3.html | 98 - .../man4/man4.powerpc/powermac_nvram.4 3.html | 55 - static/freebsd/man4/man4.powerpc/smu.4 3.html | 113 - static/freebsd/man4/man4.powerpc/snd_ai2s.4 3.html | 75 - .../freebsd/man4/man4.powerpc/snd_davbus.4 3.html | 68 - static/freebsd/man4/man4.powerpc/tsec.4 3.html | 122 - static/freebsd/man4/max44009.4 4.html | 71 - static/freebsd/man4/mca.4 3.html | 229 - static/freebsd/man4/md.4 3.html | 143 - static/freebsd/man4/mdio.4 4.html | 59 - static/freebsd/man4/me.4 4.html | 65 - static/freebsd/man4/mem.4 3.html | 270 - static/freebsd/man4/mfi.4 3.html | 120 - static/freebsd/man4/mgb.4 4.html | 70 - static/freebsd/man4/miibus.4 3.html | 163 - static/freebsd/man4/mld.4 3.html | 90 - static/freebsd/man4/mlx.4 3.html | 305 - static/freebsd/man4/mlx4en.4 4.html | 85 - static/freebsd/man4/mlx4ib.4 3.html | 85 - static/freebsd/man4/mlx5en.4 3.html | 115 - static/freebsd/man4/mlx5ib.4 3.html | 100 - static/freebsd/man4/mlx5io.4 3.html | 153 - static/freebsd/man4/mmc.4 4.html | 46 - static/freebsd/man4/mmcsd.4 4.html | 43 - static/freebsd/man4/mod_cc.4 3.html | 182 - static/freebsd/man4/mos.4 3.html | 89 - static/freebsd/man4/mouse.4 3.html | 292 - static/freebsd/man4/mpi3mr.4 3.html | 78 - static/freebsd/man4/mpr.4 3.html | 351 - static/freebsd/man4/mps.4 3.html | 335 - static/freebsd/man4/mpt.4 3.html | 115 - static/freebsd/man4/mqueuefs.4 3.html | 82 - static/freebsd/man4/mrsas.4 3.html | 365 - static/freebsd/man4/msdosfs.4 3.html | 73 - static/freebsd/man4/msk.4 3.html | 177 - static/freebsd/man4/mt7915.4 3.html | 84 - static/freebsd/man4/mt7921.4 3.html | 84 - static/freebsd/man4/mtio.4 3.html | 381 - static/freebsd/man4/mtkswitch.4 4.html | 58 - static/freebsd/man4/mtw.4 4.html | 94 - static/freebsd/man4/muge.4 4.html | 58 - static/freebsd/man4/multicast.4 3.html | 750 -- static/freebsd/man4/mvs.4 3.html | 141 - static/freebsd/man4/mwl.4 3.html | 151 - static/freebsd/man4/mwlfw.4 4.html | 42 - static/freebsd/man4/mx25l.4 4.html | 152 - static/freebsd/man4/mxge.4 3.html | 151 - static/freebsd/man4/my.4 4.html | 74 - static/freebsd/man4/nctgpio.4 4.html | 69 - static/freebsd/man4/ncthwm.4 4.html | 71 - static/freebsd/man4/nda.4 3.html | 164 - static/freebsd/man4/net80211.4 3.html | 987 -- static/freebsd/man4/netdump.4 3.html | 124 - static/freebsd/man4/netfpga10g_nf10bmac.4 4.html | 56 - static/freebsd/man4/netgdb.4 3.html | 121 - static/freebsd/man4/netgraph.4 3.html | 1023 --- static/freebsd/man4/netintro.4 3.html | 334 - static/freebsd/man4/netlink.4 3.html | 307 - static/freebsd/man4/netmap.4 3.html | 1015 --- static/freebsd/man4/nfe.4 3.html | 157 - static/freebsd/man4/nfslockd.4 4.html | 54 - static/freebsd/man4/nfsmb.4 4.html | 49 - static/freebsd/man4/ng_UI.4 4.html | 75 - static/freebsd/man4/ng_async.4 3.html | 139 - static/freebsd/man4/ng_bluetooth.4 3.html | 97 - static/freebsd/man4/ng_bpf.4 3.html | 211 - static/freebsd/man4/ng_bridge.4 3.html | 230 - static/freebsd/man4/ng_btsocket.4 3.html | 313 - static/freebsd/man4/ng_car.4 3.html | 218 - static/freebsd/man4/ng_checksum.4 3.html | 138 - static/freebsd/man4/ng_cisco.4 3.html | 152 - static/freebsd/man4/ng_deflate.4 3.html | 143 - static/freebsd/man4/ng_device.4 3.html | 84 - static/freebsd/man4/ng_echo.4 4.html | 64 - static/freebsd/man4/ng_eiface.4 3.html | 96 - static/freebsd/man4/ng_etf.4 3.html | 146 - static/freebsd/man4/ng_ether.4 3.html | 193 - static/freebsd/man4/ng_ether_echo.4 4.html | 67 - static/freebsd/man4/ng_frame_relay.4 3.html | 84 - static/freebsd/man4/ng_gif.4 3.html | 92 - static/freebsd/man4/ng_gif_demux.4 4.html | 84 - static/freebsd/man4/ng_hci.4 3.html | 370 - static/freebsd/man4/ng_hole.4 3.html | 82 - static/freebsd/man4/ng_hub.4 3.html | 74 - static/freebsd/man4/ng_iface.4 3.html | 137 - static/freebsd/man4/ng_ip_input.4 4.html | 67 - static/freebsd/man4/ng_ipfw.4 3.html | 89 - static/freebsd/man4/ng_ksocket.4 3.html | 187 - static/freebsd/man4/ng_l2cap.4 3.html | 378 - static/freebsd/man4/ng_l2tp.4 3.html | 246 - static/freebsd/man4/ng_lmi.4 3.html | 120 - static/freebsd/man4/ng_macfilter.4 3.html | 209 - static/freebsd/man4/ng_mppc.4 3.html | 155 - static/freebsd/man4/ng_nat.4 3.html | 348 - static/freebsd/man4/ng_netflow.4 3.html | 304 - static/freebsd/man4/ng_one2many.4 3.html | 227 - static/freebsd/man4/ng_patch.4 3.html | 237 - static/freebsd/man4/ng_pipe.4 3.html | 211 - static/freebsd/man4/ng_ppp.4 3.html | 358 - static/freebsd/man4/ng_pppoe.4 3.html | 533 -- static/freebsd/man4/ng_pptpgre.4 3.html | 179 - static/freebsd/man4/ng_pred1.4 3.html | 138 - static/freebsd/man4/ng_rfc1490.4 3.html | 121 - static/freebsd/man4/ng_socket.4 3.html | 134 - static/freebsd/man4/ng_source.4 3.html | 281 - static/freebsd/man4/ng_split.4 4.html | 77 - static/freebsd/man4/ng_tag.4 3.html | 260 - static/freebsd/man4/ng_tcpmss.4 3.html | 129 - static/freebsd/man4/ng_tee.4 3.html | 101 - static/freebsd/man4/ng_tty.4 3.html | 114 - static/freebsd/man4/ng_ubt.4 3.html | 127 - static/freebsd/man4/ng_vjc.4 3.html | 179 - static/freebsd/man4/ng_vlan.4 3.html | 127 - static/freebsd/man4/ng_vlan_rotate.4 3.html | 209 - static/freebsd/man4/nge.4 3.html | 168 - static/freebsd/man4/nlsysevent.4 3.html | 184 - static/freebsd/man4/nmdm.4 4.html | 72 - static/freebsd/man4/ntb.4 3.html | 76 - static/freebsd/man4/ntb_hw_amd.4 3.html | 83 - static/freebsd/man4/ntb_hw_intel.4 3.html | 89 - static/freebsd/man4/ntb_hw_plx.4 3.html | 109 - static/freebsd/man4/ntb_transport.4 3.html | 93 - static/freebsd/man4/null.4 4.html | 43 - static/freebsd/man4/nullfs.4 4.html | 67 - static/freebsd/man4/numa.4 3.html | 121 - static/freebsd/man4/nvd.4 3.html | 82 - static/freebsd/man4/nvdimm.4 3.html | 87 - static/freebsd/man4/nvme.4 3.html | 220 - static/freebsd/man4/nvmf.4 3.html | 93 - static/freebsd/man4/nvmf_che.4 3.html | 88 - static/freebsd/man4/nvmf_tcp.4 3.html | 69 - static/freebsd/man4/nvmft.4 3.html | 76 - static/freebsd/man4/nvram.4 3.html | 78 - static/freebsd/man4/oce.4 3.html | 100 - static/freebsd/man4/ocs_fc.4 3.html | 168 - static/freebsd/man4/ohci.4 4.html | 74 - static/freebsd/man4/openfirm.4 3.html | 178 - static/freebsd/man4/orm.4 4.html | 46 - static/freebsd/man4/ossl.4 4.html | 82 - static/freebsd/man4/otus.4 3.html | 162 - static/freebsd/man4/otusfw.4 4.html | 44 - static/freebsd/man4/ovpn.4 4.html | 40 - static/freebsd/man4/ow.4 4.html | 51 - static/freebsd/man4/ow_temp.4 3.html | 140 - static/freebsd/man4/owc.4 3.html | 94 - static/freebsd/man4/p9fs.4 3.html | 103 - static/freebsd/man4/padlock.4 3.html | 74 - static/freebsd/man4/pass.4 3.html | 167 - static/freebsd/man4/pca954x.4 3.html | 94 - static/freebsd/man4/pccbb.4 4.html | 121 - static/freebsd/man4/pcf.4 4.html | 64 - static/freebsd/man4/pcf8574.4 3.html | 79 - static/freebsd/man4/pcf8591.4 4.html | 95 - static/freebsd/man4/pchtherm.4 3.html | 103 - static/freebsd/man4/pci.4 3.html | 580 -- static/freebsd/man4/pcib.4 3.html | 35 - static/freebsd/man4/pcm.4 3.html | 541 -- static/freebsd/man4/pf.4 3.html | 1055 --- static/freebsd/man4/pflog.4 3.html | 91 - static/freebsd/man4/pflow.4 3.html | 93 - static/freebsd/man4/pfsync.4 3.html | 208 - static/freebsd/man4/pim.4 3.html | 177 - static/freebsd/man4/pms.4 3.html | 86 - static/freebsd/man4/polling.4 3.html | 184 - static/freebsd/man4/ppbus.4 3.html | 355 - static/freebsd/man4/ppc.4 3.html | 118 - static/freebsd/man4/ppi.4 4.html | 111 - static/freebsd/man4/procdesc.4 3.html | 61 - static/freebsd/man4/procfs.4 3.html | 266 - static/freebsd/man4/proto.4 3.html | 349 - static/freebsd/man4/ps4dshock.4 3.html | 95 - static/freebsd/man4/psm.4 3.html | 663 -- static/freebsd/man4/pst.4 3.html | 63 - static/freebsd/man4/pt.4 3.html | 69 - static/freebsd/man4/ptnet.4 3.html | 98 - static/freebsd/man4/pts.4 3.html | 116 - static/freebsd/man4/pty.4 3.html | 79 - static/freebsd/man4/puc.4 4.html | 192 - static/freebsd/man4/pvscsi.4 3.html | 83 - static/freebsd/man4/pwmc.4 3.html | 176 - static/freebsd/man4/qat.4 3.html | 174 - static/freebsd/man4/qat_c2xxx.4 3.html | 82 - static/freebsd/man4/qlnxe.4 3.html | 73 - static/freebsd/man4/qlxgb.4 3.html | 73 - static/freebsd/man4/qlxgbe.4 3.html | 73 - static/freebsd/man4/qlxge.4 3.html | 72 - static/freebsd/man4/ral.4 3.html | 616 -- static/freebsd/man4/random.4 3.html | 203 - static/freebsd/man4/rccgpio.4 4.html | 54 - static/freebsd/man4/rctl.4 3.html | 65 - static/freebsd/man4/re.4 3.html | 217 - static/freebsd/man4/rge.4 3.html | 162 - static/freebsd/man4/rgephy.4 3.html | 72 - static/freebsd/man4/rights.4 3.html | 411 - static/freebsd/man4/rl.4 3.html | 221 - static/freebsd/man4/rndtest.4 4.html | 53 - static/freebsd/man4/route.4 3.html | 246 - static/freebsd/man4/rsu.4 3.html | 183 - static/freebsd/man4/rsufw.4 4.html | 44 - static/freebsd/man4/rtnetlink.4 3.html | 540 -- static/freebsd/man4/rtsx.4 3.html | 125 - static/freebsd/man4/rtw88.4 3.html | 101 - static/freebsd/man4/rtw89.4 3.html | 102 - static/freebsd/man4/rtwn.4 3.html | 239 - static/freebsd/man4/rtwn_pci.4 4.html | 56 - static/freebsd/man4/rtwn_usb.4 3.html | 347 - static/freebsd/man4/rtwnfw.4 3.html | 87 - static/freebsd/man4/rue.4 3.html | 125 - static/freebsd/man4/rum.4 3.html | 281 - static/freebsd/man4/run.4 3.html | 233 - static/freebsd/man4/runfw.4 4.html | 45 - static/freebsd/man4/sa.4 3.html | 425 - static/freebsd/man4/safe.4 3.html | 118 - static/freebsd/man4/safexcel.4 4.html | 71 - static/freebsd/man4/sbp.4 3.html | 82 - static/freebsd/man4/sbp_targ.4 4.html | 77 - static/freebsd/man4/scc.4 4.html | 60 - static/freebsd/man4/sched_4bsd.4 3.html | 66 - static/freebsd/man4/sched_ule.4 4.html | 63 - static/freebsd/man4/screen.4 3.html | 238 - static/freebsd/man4/scsi.4 3.html | 436 - static/freebsd/man4/sctp.4 3.html | 497 - static/freebsd/man4/sdhci.4 3.html | 74 - static/freebsd/man4/sem.4 3.html | 60 - static/freebsd/man4/send.4 3.html | 203 - static/freebsd/man4/ses.4 3.html | 128 - static/freebsd/man4/sfxge.4 3.html | 155 - static/freebsd/man4/sg.4 4.html | 76 - static/freebsd/man4/sge.4 3.html | 95 - static/freebsd/man4/siba.4 3.html | 75 - static/freebsd/man4/siftr.4 3.html | 717 -- static/freebsd/man4/siis.4 3.html | 116 - static/freebsd/man4/simplebus.4 4.html | 65 - static/freebsd/man4/sis.4 3.html | 170 - static/freebsd/man4/sk.4 3.html | 182 - static/freebsd/man4/smartpqi.4 3.html | 198 - static/freebsd/man4/smb.4 3.html | 185 - static/freebsd/man4/smbfs.4 3.html | 74 - static/freebsd/man4/smbios.4 4.html | 59 - static/freebsd/man4/smbus.4 3.html | 72 - static/freebsd/man4/smp.4 3.html | 148 - static/freebsd/man4/smsc.4 4.html | 78 - static/freebsd/man4/snd_als4000.4 4.html | 63 - static/freebsd/man4/snd_atiixp.4 3.html | 90 - static/freebsd/man4/snd_cmi.4 4.html | 66 - static/freebsd/man4/snd_cs4281.4 4.html | 64 - static/freebsd/man4/snd_csa.4 4.html | 76 - static/freebsd/man4/snd_dummy.4 4.html | 67 - static/freebsd/man4/snd_emu10k1.4 3.html | 78 - static/freebsd/man4/snd_emu10kx.4 3.html | 267 - static/freebsd/man4/snd_envy24.4 4.html | 71 - static/freebsd/man4/snd_envy24ht.4 4.html | 83 - static/freebsd/man4/snd_es137x.4 3.html | 105 - static/freebsd/man4/snd_fm801.4 4.html | 71 - static/freebsd/man4/snd_hda.4 3.html | 532 -- static/freebsd/man4/snd_hdsp.4 3.html | 179 - static/freebsd/man4/snd_hdspe.4 3.html | 181 - static/freebsd/man4/snd_ich.4 4.html | 84 - static/freebsd/man4/snd_maestro3.4 3.html | 86 - static/freebsd/man4/snd_neomagic.4 4.html | 65 - static/freebsd/man4/snd_solo.4 4.html | 57 - static/freebsd/man4/snd_spicds.4 3.html | 70 - static/freebsd/man4/snd_t4dwave.4 3.html | 66 - static/freebsd/man4/snd_uaudio.4 3.html | 149 - static/freebsd/man4/snd_via8233.4 4.html | 92 - static/freebsd/man4/snd_via82c686.4 3.html | 63 - static/freebsd/man4/snd_vibes.4 4.html | 63 - static/freebsd/man4/sndstat.4 3.html | 382 - static/freebsd/man4/snp.4 3.html | 91 - static/freebsd/man4/spigen.4 3.html | 186 - static/freebsd/man4/spkr.4 3.html | 191 - static/freebsd/man4/splash.4 3.html | 260 - static/freebsd/man4/ste.4 3.html | 154 - static/freebsd/man4/stf.4 3.html | 226 - static/freebsd/man4/stge.4 3.html | 142 - static/freebsd/man4/sume.4 3.html | 77 - static/freebsd/man4/superio.4 3.html | 104 - static/freebsd/man4/sym.4 3.html | 389 - static/freebsd/man4/syncache.4 3.html | 268 - static/freebsd/man4/syncer.4 3.html | 86 - static/freebsd/man4/syscons.4 3.html | 519 -- static/freebsd/man4/sysmouse.4 3.html | 371 - static/freebsd/man4/tap.4 3.html | 201 - static/freebsd/man4/tarfs.4 3.html | 125 - static/freebsd/man4/targ.4 3.html | 112 - static/freebsd/man4/tcp.4 3.html | 837 -- static/freebsd/man4/tcp_bbr.4 3.html | 145 - static/freebsd/man4/tcp_rack.4 3.html | 139 - static/freebsd/man4/tdfx.4 3.html | 104 - static/freebsd/man4/termios.4 3.html | 1050 --- static/freebsd/man4/textdump.4 3.html | 149 - static/freebsd/man4/thunderbolt.4 4.html | 34 - static/freebsd/man4/ti.4 3.html | 317 - static/freebsd/man4/timecounters.4 3.html | 97 - static/freebsd/man4/tmpfs.4 3.html | 158 - static/freebsd/man4/tpm.4 4.html | 104 - static/freebsd/man4/tslog.4 3.html | 116 - static/freebsd/man4/tty.4 3.html | 337 - static/freebsd/man4/tun.4 3.html | 225 - static/freebsd/man4/tws.4 3.html | 104 - static/freebsd/man4/u2f.4 4.html | 87 - static/freebsd/man4/u3g.4 3.html | 149 - static/freebsd/man4/uark.4 3.html | 97 - static/freebsd/man4/uart.4 3.html | 345 - static/freebsd/man4/uath.4 3.html | 247 - static/freebsd/man4/ubsa.4 4.html | 101 - static/freebsd/man4/ubser.4 4.html | 70 - static/freebsd/man4/ubtbcmfw.4 3.html | 85 - static/freebsd/man4/uchcom.4 4.html | 104 - static/freebsd/man4/ucom.4 3.html | 130 - static/freebsd/man4/ucycom.4 4.html | 91 - static/freebsd/man4/udav.4 4.html | 82 - static/freebsd/man4/udbc.4 3.html | 128 - static/freebsd/man4/udbp.4 3.html | 128 - static/freebsd/man4/udl.4 4.html | 72 - static/freebsd/man4/udp.4 3.html | 128 - static/freebsd/man4/udplite.4 3.html | 86 - static/freebsd/man4/uep.4 3.html | 81 - static/freebsd/man4/ufintek.4 4.html | 105 - static/freebsd/man4/ufoma.4 3.html | 117 - static/freebsd/man4/ufshci.4 3.html | 217 - static/freebsd/man4/uftdi.4 4.html | 234 - static/freebsd/man4/ugen.4 3.html | 258 - static/freebsd/man4/ugold.4 3.html | 56 - static/freebsd/man4/uhci.4 4.html | 70 - static/freebsd/man4/uhid.4 3.html | 139 - static/freebsd/man4/uhso.4 3.html | 118 - static/freebsd/man4/uipaq.4 4.html | 92 - static/freebsd/man4/ukbd.4 3.html | 174 - static/freebsd/man4/uled.4 4.html | 81 - static/freebsd/man4/ulpt.4 3.html | 88 - static/freebsd/man4/umass.4 3.html | 110 - static/freebsd/man4/umb.4 3.html | 95 - static/freebsd/man4/umcs.4 4.html | 99 - static/freebsd/man4/umct.4 4.html | 98 - static/freebsd/man4/umodem.4 3.html | 104 - static/freebsd/man4/umoscom.4 4.html | 73 - static/freebsd/man4/ums.4 4.html | 107 - static/freebsd/man4/unionfs.4 3.html | 75 - static/freebsd/man4/unix.4 3.html | 302 - static/freebsd/man4/upgt.4 3.html | 153 - static/freebsd/man4/uplcom.4 3.html | 155 - static/freebsd/man4/ural.4 3.html | 242 - static/freebsd/man4/ure.4 3.html | 129 - static/freebsd/man4/urio.4 4.html | 101 - static/freebsd/man4/urndis.4 3.html | 89 - static/freebsd/man4/urtw.4 3.html | 153 - static/freebsd/man4/usb.4 4.html | 154 - static/freebsd/man4/usb_quirk.4 3.html | 255 - static/freebsd/man4/usb_template.4 3.html | 142 - static/freebsd/man4/usbhid.4 3.html | 77 - static/freebsd/man4/usfs.4 3.html | 55 - static/freebsd/man4/uslcom.4 3.html | 165 - static/freebsd/man4/uvisor.4 4.html | 117 - static/freebsd/man4/uvscom.4 4.html | 89 - static/freebsd/man4/vale.4 3.html | 94 - static/freebsd/man4/veriexec.4 4.html | 88 - static/freebsd/man4/vga.4 3.html | 153 - static/freebsd/man4/vge.4 3.html | 173 - static/freebsd/man4/viapm.4 3.html | 68 - static/freebsd/man4/viawd.4 3.html | 60 - static/freebsd/man4/virtio.4 3.html | 105 - static/freebsd/man4/virtio_balloon.4 4.html | 52 - static/freebsd/man4/virtio_blk.4 3.html | 87 - static/freebsd/man4/virtio_console.4 4.html | 57 - static/freebsd/man4/virtio_gpu.4 4.html | 42 - static/freebsd/man4/virtio_random.4 4.html | 49 - static/freebsd/man4/virtio_scsi.4 4.html | 82 - static/freebsd/man4/vkbd.4 3.html | 128 - static/freebsd/man4/vlan.4 3.html | 117 - static/freebsd/man4/vmci.4 3.html | 76 - static/freebsd/man4/vmd.4 4.html | 71 - static/freebsd/man4/vmgenc.4 3.html | 73 - static/freebsd/man4/vmm.4 3.html | 155 - static/freebsd/man4/vmx.4 3.html | 135 - static/freebsd/man4/vr.4 3.html | 165 - static/freebsd/man4/vt.4 3.html | 465 - static/freebsd/man4/vte.4 3.html | 127 - static/freebsd/man4/vtnet.4 3.html | 305 - static/freebsd/man4/vxlan.4 3.html | 180 - static/freebsd/man4/watchdog.4 3.html | 186 - static/freebsd/man4/wbwd.4 3.html | 107 - static/freebsd/man4/wdatwd.4 3.html | 80 - static/freebsd/man4/wg.4 3.html | 202 - static/freebsd/man4/witness.4 3.html | 155 - static/freebsd/man4/wlan.4 3.html | 163 - static/freebsd/man4/wlan_acl.4 4.html | 46 - static/freebsd/man4/wlan_amrr.4 4.html | 50 - static/freebsd/man4/wlan_ccmp.4 4.html | 54 - static/freebsd/man4/wlan_gcmp.4 3.html | 55 - static/freebsd/man4/wlan_tkip.4 4.html | 54 - static/freebsd/man4/wlan_wep.4 3.html | 51 - static/freebsd/man4/wlan_xauth.4 3.html | 52 - static/freebsd/man4/wmt.4 4.html | 72 - static/freebsd/man4/wpi.4 3.html | 180 - static/freebsd/man4/wsp.4 3.html | 179 - static/freebsd/man4/xb360gp.4 4.html | 89 - static/freebsd/man4/xdma.4 3.html | 65 - static/freebsd/man4/xen.4 3.html | 126 - static/freebsd/man4/xhci.4 3.html | 84 - static/freebsd/man4/xl.4 3.html | 194 - static/freebsd/man4/xnb.4 3.html | 111 - static/freebsd/man4/xpt.4 4.html | 104 - static/freebsd/man4/zero.4 3.html | 44 - static/freebsd/man4/zyd.4 4.html | 166 - static/freebsd/man5/a.out.5 3.html | 354 - static/freebsd/man5/acct.5 3.html | 101 - static/freebsd/man5/ar.5 3.html | 240 - static/freebsd/man5/bluetooth.device.conf.5 3.html | 133 - static/freebsd/man5/bluetooth.hosts.5 4.html | 55 - static/freebsd/man5/bluetooth.protocols.5 4.html | 56 - static/freebsd/man5/boot.config.5 3.html | 83 - static/freebsd/man5/core.5 3.html | 153 - static/freebsd/man5/devfs.conf.5 3.html | 101 - static/freebsd/man5/devfs.rules.5 3.html | 102 - static/freebsd/man5/device.hints.5 3.html | 122 - static/freebsd/man5/dir.5 3.html | 141 - static/freebsd/man5/disktab.5 3.html | 333 - static/freebsd/man5/elf.5 3.html | 1172 --- static/freebsd/man5/ethers.5 4.html | 67 - static/freebsd/man5/eui64.5 4.html | 60 - static/freebsd/man5/fbtab.5 4.html | 55 - static/freebsd/man5/forward.5 4.html | 65 - static/freebsd/man5/freebsd-update.conf.5 3.html | 198 - static/freebsd/man5/fs.5 3.html | 336 - static/freebsd/man5/fstab.5 3.html | 272 - static/freebsd/man5/group.5 3.html | 103 - static/freebsd/man5/hesiod.conf.5 4.html | 59 - static/freebsd/man5/hosts.5 3.html | 66 - static/freebsd/man5/hosts.equiv.5 3.html | 92 - static/freebsd/man5/hosts.lpd.5 4.html | 42 - static/freebsd/man5/intro.5 4.html | 52 - static/freebsd/man5/libmap.conf.5 3.html | 153 - static/freebsd/man5/link.5 3.html | 493 - static/freebsd/man5/mailer.conf.5 3.html | 127 - static/freebsd/man5/make.conf.5 3.html | 468 - static/freebsd/man5/moduli.5 3.html | 105 - static/freebsd/man5/motd.5 4.html | 68 - static/freebsd/man5/mount.conf.5 3.html | 185 - static/freebsd/man5/networks.5 4.html | 65 - static/freebsd/man5/nsmb.conf.5 3.html | 179 - static/freebsd/man5/nsswitch.conf.5 3.html | 306 - static/freebsd/man5/os-release.5 3.html | 115 - static/freebsd/man5/passwd.5 3.html | 282 - static/freebsd/man5/pbm.5 3.html | 78 - static/freebsd/man5/periodic.conf.5 3.html | 744 -- static/freebsd/man5/pf.conf.5 3.html | 3028 ------- static/freebsd/man5/pf.os.5 3.html | 168 - static/freebsd/man5/phones.5 4.html | 55 - static/freebsd/man5/portindex.5 3.html | 89 - static/freebsd/man5/protocols.5 4.html | 67 - static/freebsd/man5/quota.user.5 3.html | 80 - static/freebsd/man5/rc.conf.5 3.html | 3187 ------- static/freebsd/man5/rctl.conf.5 4.html | 59 - static/freebsd/man5/regdomain.5 4.html | 40 - static/freebsd/man5/remote.5 3.html | 148 - static/freebsd/man5/resolver.5 3.html | 218 - static/freebsd/man5/services.5 3.html | 77 - static/freebsd/man5/shells.5 4.html | 47 - static/freebsd/man5/src.conf.5 3.html | 1550 ---- static/freebsd/man5/stab.5 3.html | 163 - static/freebsd/man5/style.Makefile.5 3.html | 168 - static/freebsd/man5/style.mdoc.5 3.html | 224 - static/freebsd/man5/sysctl.conf.5 4.html | 85 - static/freebsd/man6/intro.6 4.html | 49 - static/freebsd/man7/arch.7 3.html | 967 -- static/freebsd/man7/ascii.7 3.html | 173 - static/freebsd/man7/bsd.snmpmod.mk.7 3.html | 85 - static/freebsd/man7/build.7 3.html | 863 -- static/freebsd/man7/c.7 3.html | 363 - static/freebsd/man7/clocks.7 3.html | 105 - static/freebsd/man7/crypto.7 3.html | 327 - static/freebsd/man7/d.7 3.html | 377 - static/freebsd/man7/development.7 3.html | 128 - static/freebsd/man7/environ.7 3.html | 217 - static/freebsd/man7/firewall.7 3.html | 377 - static/freebsd/man7/freebsd-base.7 3.html | 236 - static/freebsd/man7/growfs.7 3.html | 122 - static/freebsd/man7/hier.7 3.html | 823 -- static/freebsd/man7/hostname.7 3.html | 68 - static/freebsd/man7/intro.7 4.html | 84 - static/freebsd/man7/maclabel.7 3.html | 66 - static/freebsd/man7/mitigations.7 3.html | 451 - static/freebsd/man7/named_attribute.7 3.html | 220 - static/freebsd/man7/networking.7 4.html | 110 - static/freebsd/man7/operator.7 4.html | 110 - static/freebsd/man7/orders.7 3.html | 370 - static/freebsd/man7/ports.7 3.html | 585 -- static/freebsd/man7/release.7 3.html | 562 -- static/freebsd/man7/sdoc.7 3.html | 192 - static/freebsd/man7/security.7 3.html | 725 -- static/freebsd/man7/simd.7 4.html | 458 - static/freebsd/man7/sizeof.7 3.html | 304 - static/freebsd/man7/sprog.7 3.html | 146 - static/freebsd/man7/stats.7 4.html | 107 - static/freebsd/man7/stdint.7 3.html | 87 - static/freebsd/man7/sticky.7 4.html | 53 - static/freebsd/man7/tests.7 3.html | 258 - static/freebsd/man7/tracing.7 3.html | 95 - static/freebsd/man7/tuning.7 3.html | 478 - static/freebsd/man8/beinstall.8 3.html | 107 - static/freebsd/man8/crash.8 3.html | 125 - static/freebsd/man8/debug.sh.8 3.html | 150 - static/freebsd/man8/diskless.8 3.html | 290 - static/freebsd/man8/intro.8 4.html | 52 - static/freebsd/man8/nanobsd.8 3.html | 278 - static/freebsd/man8/rc.8 3.html | 472 - static/freebsd/man8/rc.subr.8 3.html | 806 -- static/freebsd/man8/rescue.8 3.html | 112 - static/freebsd/man8/uefi.8 3.html | 132 - static/freebsd/man8/yp.8 3.html | 289 - static/freebsd/man9/BUF_ISLOCKED.9 4.html | 68 - static/freebsd/man9/BUF_LOCK.9 4.html | 71 - static/freebsd/man9/BUF_LOCKFREE.9 4.html | 61 - static/freebsd/man9/BUF_LOCKINIT.9 4.html | 60 - static/freebsd/man9/BUF_RECURSED.9 4.html | 63 - static/freebsd/man9/BUF_TIMELOCK.9 4.html | 80 - static/freebsd/man9/BUF_UNLOCK.9 4.html | 62 - static/freebsd/man9/BUS_ADD_CHILD.9 3.html | 77 - static/freebsd/man9/BUS_BIND_INTR.9 3.html | 85 - static/freebsd/man9/BUS_CHILD_DELETED.9 4.html | 52 - static/freebsd/man9/BUS_CHILD_DETACHED.9 4.html | 48 - static/freebsd/man9/BUS_CHILD_LOCATION.9 4.html | 59 - static/freebsd/man9/BUS_CHILD_PNPINFO.9 3.html | 64 - static/freebsd/man9/BUS_CONFIG_INTR.9 3.html | 103 - static/freebsd/man9/BUS_DESCRIBE_INTR.9 3.html | 91 - static/freebsd/man9/BUS_GET_CPUS.9 3.html | 88 - static/freebsd/man9/BUS_GET_PROPERTY.9 4.html | 74 - static/freebsd/man9/BUS_HINTED_CHILD.9 4.html | 57 - static/freebsd/man9/BUS_NEW_PASS.9 4.html | 50 - static/freebsd/man9/BUS_PRINT_CHILD.9 4.html | 58 - static/freebsd/man9/BUS_READ_IVAR.9 4.html | 67 - static/freebsd/man9/BUS_RESCAN.9 4.html | 48 - static/freebsd/man9/BUS_SETUP_INTR.9 3.html | 169 - static/freebsd/man9/CTASSERT.9 4.html | 65 - static/freebsd/man9/DB_COMMAND.9 3.html | 180 - static/freebsd/man9/DECLARE_GEOM_CLASS.9 3.html | 167 - static/freebsd/man9/DECLARE_MODULE.9 3.html | 105 - static/freebsd/man9/DEFINE_IFUNC.9 3.html | 118 - static/freebsd/man9/DELAY.9 4.html | 46 - static/freebsd/man9/DEVICE_ATTACH.9 4.html | 64 - static/freebsd/man9/DEVICE_DETACH.9 4.html | 58 - static/freebsd/man9/DEVICE_IDENTIFY.9 3.html | 86 - static/freebsd/man9/DEVICE_PROBE.9 3.html | 115 - static/freebsd/man9/DEVICE_SHUTDOWN.9 4.html | 55 - static/freebsd/man9/DEV_MODULE.9 4.html | 99 - static/freebsd/man9/DRIVER_MODULE.9 3.html | 139 - static/freebsd/man9/EVENTHANDLER.9 3.html | 231 - static/freebsd/man9/KASSERT.9 3.html | 161 - static/freebsd/man9/LOCK_PROFILING.9 3.html | 150 - static/freebsd/man9/MODULE_DEPEND.9 4.html | 74 - static/freebsd/man9/MODULE_PNP_INFO.9 4.html | 177 - static/freebsd/man9/MODULE_VERSION.9 4.html | 55 - static/freebsd/man9/OF_child.9 4.html | 76 - static/freebsd/man9/OF_device_from_xref.9 3.html | 101 - static/freebsd/man9/OF_finddevice.9 4.html | 73 - static/freebsd/man9/OF_getprop.9 4.html | 293 - static/freebsd/man9/OF_node_from_xref.9 3.html | 94 - static/freebsd/man9/OF_package_to_path.9 4.html | 52 - static/freebsd/man9/PCI_IOV_ADD_VF.9 3.html | 98 - static/freebsd/man9/PCI_IOV_INIT.9 4.html | 82 - static/freebsd/man9/PCI_IOV_UNINIT.9 4.html | 58 - static/freebsd/man9/PHOLD.9 4.html | 64 - static/freebsd/man9/SDT.9 4.html | 460 - static/freebsd/man9/SYSCALL_MODULE.9 4.html | 89 - static/freebsd/man9/SYSINIT.9 3.html | 138 - static/freebsd/man9/VFS.9 4.html | 45 - static/freebsd/man9/VFS_CHECKEXP.9 4.html | 88 - static/freebsd/man9/VFS_FHTOVP.9 3.html | 81 - static/freebsd/man9/VFS_MOUNT.9 4.html | 70 - static/freebsd/man9/VFS_QUOTACTL.9 4.html | 64 - static/freebsd/man9/VFS_ROOT.9 4.html | 62 - static/freebsd/man9/VFS_SET.9 4.html | 103 - static/freebsd/man9/VFS_STATFS.9 4.html | 105 - static/freebsd/man9/VFS_SYNC.9 4.html | 74 - static/freebsd/man9/VFS_UNMOUNT.9 4.html | 67 - static/freebsd/man9/VFS_VGET.9 4.html | 74 - static/freebsd/man9/VNET.9 4.html | 353 - static/freebsd/man9/VOP_ACCESS.9 4.html | 102 - static/freebsd/man9/VOP_ACLCHECK.9 4.html | 100 - static/freebsd/man9/VOP_ADVISE.9 4.html | 87 - static/freebsd/man9/VOP_ADVLOCK.9 4.html | 89 - static/freebsd/man9/VOP_ALLOCATE.9 4.html | 86 - static/freebsd/man9/VOP_ATTRIB.9 4.html | 139 - static/freebsd/man9/VOP_BMAP.9 4.html | 90 - static/freebsd/man9/VOP_BWRITE.9 4.html | 57 - static/freebsd/man9/VOP_COPY_FILE_RANGE.9 3.html | 115 - static/freebsd/man9/VOP_CREATE.9 4.html | 118 - static/freebsd/man9/VOP_DEALLOCATE.9 4.html | 99 - static/freebsd/man9/VOP_FSYNC.9 4.html | 105 - static/freebsd/man9/VOP_GETACL.9 4.html | 100 - static/freebsd/man9/VOP_GETEXTATTR.9 4.html | 119 - static/freebsd/man9/VOP_GETPAGES.9 3.html | 160 - static/freebsd/man9/VOP_INACTIVE.9 4.html | 74 - static/freebsd/man9/VOP_INOTIFY.9 4.html | 78 - static/freebsd/man9/VOP_IOCTL.9 4.html | 77 - static/freebsd/man9/VOP_LINK.9 4.html | 83 - static/freebsd/man9/VOP_LISTEXTATTR.9 4.html | 111 - static/freebsd/man9/VOP_LOCK.9 4.html | 128 - static/freebsd/man9/VOP_LOOKUP.9 4.html | 148 - static/freebsd/man9/VOP_OPENCLOSE.9 4.html | 108 - static/freebsd/man9/VOP_PATHCONF.9 4.html | 88 - static/freebsd/man9/VOP_PRINT.9 4.html | 54 - static/freebsd/man9/VOP_RDWR.9 4.html | 112 - static/freebsd/man9/VOP_READDIR.9 4.html | 109 - static/freebsd/man9/VOP_READLINK.9 4.html | 78 - static/freebsd/man9/VOP_READ_PGCACHE.9 4.html | 98 - static/freebsd/man9/VOP_REALLOCBLKS.9 4.html | 58 - static/freebsd/man9/VOP_REMOVE.9 4.html | 83 - static/freebsd/man9/VOP_RENAME.9 4.html | 93 - static/freebsd/man9/VOP_REVOKE.9 4.html | 58 - static/freebsd/man9/VOP_SETACL.9 4.html | 107 - static/freebsd/man9/VOP_SETEXTATTR.9 4.html | 121 - static/freebsd/man9/VOP_SETLABEL.9 3.html | 127 - static/freebsd/man9/VOP_STRATEGY.9 4.html | 67 - static/freebsd/man9/VOP_VPTOCNP.9 4.html | 97 - static/freebsd/man9/VOP_VPTOFH.9 4.html | 56 - static/freebsd/man9/accept_filter.9 3.html | 129 - static/freebsd/man9/accf_data.9 4.html | 73 - static/freebsd/man9/accf_dns.9 3.html | 74 - static/freebsd/man9/accf_http.9 3.html | 89 - static/freebsd/man9/accf_tls.9 3.html | 86 - static/freebsd/man9/acl.9 3.html | 207 - static/freebsd/man9/alq.9 3.html | 300 - static/freebsd/man9/altq.9 3.html | 510 -- static/freebsd/man9/atomic.9 3.html | 613 -- static/freebsd/man9/backlight.9 3.html | 97 - static/freebsd/man9/bhnd.9 3.html | 2322 ----- static/freebsd/man9/bhnd_erom.9 3.html | 355 - static/freebsd/man9/bios.9 3.html | 158 - static/freebsd/man9/bitset.9 3.html | 487 - static/freebsd/man9/bpf.9 3.html | 196 - static/freebsd/man9/buf.9 3.html | 111 - static/freebsd/man9/buf_ring.9 3.html | 130 - static/freebsd/man9/bus_activate_resource.9 3.html | 115 - static/freebsd/man9/bus_adjust_resource.9 4.html | 93 - static/freebsd/man9/bus_alloc_resource.9 3.html | 168 - static/freebsd/man9/bus_attach_children.9 3.html | 138 - static/freebsd/man9/bus_child_present.9 3.html | 86 - static/freebsd/man9/bus_dma.9 3.html | 1154 --- static/freebsd/man9/bus_generic_detach.9 4.html | 62 - static/freebsd/man9/bus_generic_new_pass.9 4.html | 49 - .../freebsd/man9/bus_generic_print_child.9 3.html | 99 - static/freebsd/man9/bus_generic_read_ivar.9 4.html | 56 - static/freebsd/man9/bus_generic_shutdown.9 4.html | 55 - static/freebsd/man9/bus_get_resource.9 4.html | 87 - static/freebsd/man9/bus_map_resource.9 3.html | 150 - static/freebsd/man9/bus_release_resource.9 4.html | 85 - static/freebsd/man9/bus_set_pass.9 4.html | 45 - static/freebsd/man9/bus_set_resource.9 4.html | 95 - static/freebsd/man9/bus_space.9 3.html | 1712 ---- static/freebsd/man9/byteorder.9 4.html | 219 - static/freebsd/man9/callout.9 3.html | 614 -- static/freebsd/man9/casuword.9 3.html | 88 - static/freebsd/man9/cd.9 3.html | 95 - static/freebsd/man9/cdefs.9 3.html | 937 -- static/freebsd/man9/cnv.9 4.html | 278 - static/freebsd/man9/condvar.9 4.html | 216 - static/freebsd/man9/config_intrhook.9 3.html | 127 - static/freebsd/man9/contigmalloc.9 3.html | 118 - static/freebsd/man9/copy.9 3.html | 130 - static/freebsd/man9/coredumper_register.9 3.html | 181 - static/freebsd/man9/counter.9 4.html | 282 - static/freebsd/man9/cpu_machdep.9 3.html | 334 - static/freebsd/man9/cpuset.9 4.html | 323 - static/freebsd/man9/cr_bsd_visible.9 3.html | 97 - static/freebsd/man9/cr_cansee.9 3.html | 72 - static/freebsd/man9/cr_canseejailproc.9 4.html | 69 - static/freebsd/man9/cr_canseeothergids.9 4.html | 64 - static/freebsd/man9/cr_canseeotheruids.9 4.html | 61 - static/freebsd/man9/critical_enter.9 3.html | 94 - static/freebsd/man9/crypto.9 3.html | 182 - static/freebsd/man9/crypto_buffer.9 3.html | 256 - static/freebsd/man9/crypto_driver.9 4.html | 269 - static/freebsd/man9/crypto_request.9 4.html | 505 -- static/freebsd/man9/crypto_session.9 3.html | 230 - static/freebsd/man9/deadfs.9 4.html | 47 - static/freebsd/man9/dev_clone.9 4.html | 67 - static/freebsd/man9/dev_refthread.9 3.html | 125 - static/freebsd/man9/devclass.9 4.html | 55 - static/freebsd/man9/devclass_find.9 4.html | 52 - static/freebsd/man9/devclass_get_count.9 4.html | 46 - static/freebsd/man9/devclass_get_device.9 4.html | 52 - static/freebsd/man9/devclass_get_devices.9 4.html | 59 - static/freebsd/man9/devclass_get_drivers.9 4.html | 59 - static/freebsd/man9/devclass_get_maxunit.9 4.html | 64 - static/freebsd/man9/devclass_get_name.9 4.html | 45 - static/freebsd/man9/devclass_get_softc.9 4.html | 53 - static/freebsd/man9/devctl_notify.9 4.html | 64 - .../freebsd/man9/devctl_process_running.9 4.html | 50 - static/freebsd/man9/devctl_safe_quote_sb.9 4.html | 51 - static/freebsd/man9/devfs_set_cdevpriv.9 3.html | 127 - static/freebsd/man9/device.9 3.html | 76 - static/freebsd/man9/device_add_child.9 3.html | 110 - static/freebsd/man9/device_delete_child.9 4.html | 60 - .../freebsd/man9/device_delete_children.9 4.html | 57 - static/freebsd/man9/device_enable.9 4.html | 63 - static/freebsd/man9/device_find_child.9 4.html | 56 - static/freebsd/man9/device_get_children.9 3.html | 78 - static/freebsd/man9/device_get_devclass.9 4.html | 46 - static/freebsd/man9/device_get_driver.9 4.html | 46 - static/freebsd/man9/device_get_ivars.9 4.html | 60 - static/freebsd/man9/device_get_name.9 4.html | 55 - static/freebsd/man9/device_get_parent.9 4.html | 47 - static/freebsd/man9/device_get_property.9 3.html | 92 - static/freebsd/man9/device_get_softc.9 4.html | 62 - static/freebsd/man9/device_get_state.9 3.html | 90 - static/freebsd/man9/device_get_sysctl.9 4.html | 56 - static/freebsd/man9/device_get_unit.9 4.html | 45 - static/freebsd/man9/device_printf.9 4.html | 53 - .../freebsd/man9/device_probe_and_attach.9 3.html | 117 - static/freebsd/man9/device_quiet.9 4.html | 64 - static/freebsd/man9/device_set_desc.9 4.html | 72 - static/freebsd/man9/device_set_driver.9 4.html | 50 - static/freebsd/man9/device_set_flags.9 4.html | 55 - static/freebsd/man9/devstat.9 3.html | 401 - static/freebsd/man9/devtoname.9 4.html | 45 - static/freebsd/man9/disk.9 3.html | 258 - static/freebsd/man9/dnv.9 3.html | 153 - static/freebsd/man9/domain.9 3.html | 194 - static/freebsd/man9/domainset.9 3.html | 160 - static/freebsd/man9/dpcpu.9 4.html | 160 - static/freebsd/man9/drbr.9 3.html | 127 - static/freebsd/man9/driver.9 3.html | 98 - static/freebsd/man9/ecn.9 3.html | 174 - static/freebsd/man9/efirt.9 3.html | 208 - static/freebsd/man9/epoch.9 4.html | 284 - static/freebsd/man9/ether_gen_addr.9 4.html | 65 - static/freebsd/man9/eventtimers.9 4.html | 252 - static/freebsd/man9/extattr.9 3.html | 87 - static/freebsd/man9/exterror.9 3.html | 185 - static/freebsd/man9/fail.9 3.html | 263 - static/freebsd/man9/fdt_pinctrl.9 3.html | 174 - static/freebsd/man9/fetch.9 3.html | 130 - static/freebsd/man9/firmware.9 3.html | 319 - static/freebsd/man9/fpu_kern.9 3.html | 192 - static/freebsd/man9/g_access.9 3.html | 151 - static/freebsd/man9/g_attach.9 3.html | 139 - static/freebsd/man9/g_bio.9 3.html | 270 - static/freebsd/man9/g_consumer.9 3.html | 128 - static/freebsd/man9/g_data.9 3.html | 104 - static/freebsd/man9/g_event.9 3.html | 176 - static/freebsd/man9/g_geom.9 3.html | 197 - static/freebsd/man9/g_provider.9 3.html | 130 - static/freebsd/man9/g_provider_by_name.9 4.html | 66 - static/freebsd/man9/g_wither_geom.9 3.html | 73 - static/freebsd/man9/get_cyclecount.9 4.html | 67 - static/freebsd/man9/getenv.9 4.html | 231 - static/freebsd/man9/getnewvnode.9 4.html | 72 - static/freebsd/man9/gone_in.9 4.html | 81 - static/freebsd/man9/groupmember.9 4.html | 74 - static/freebsd/man9/hardclock.9 3.html | 69 - static/freebsd/man9/hash.9 3.html | 211 - static/freebsd/man9/hashalloc.9 3.html | 253 - static/freebsd/man9/hashinit.9 3.html | 174 - static/freebsd/man9/hexdump.9 4.html | 79 - static/freebsd/man9/hhook.9 3.html | 292 - static/freebsd/man9/hz.9 3.html | 115 - static/freebsd/man9/ieee80211.9 3.html | 568 -- static/freebsd/man9/ieee80211_amrr.9 3.html | 159 - static/freebsd/man9/ieee80211_beacon.9 3.html | 102 - static/freebsd/man9/ieee80211_bmiss.9 3.html | 72 - static/freebsd/man9/ieee80211_crypto.9 3.html | 221 - static/freebsd/man9/ieee80211_ddb.9 4.html | 56 - static/freebsd/man9/ieee80211_input.9 3.html | 83 - static/freebsd/man9/ieee80211_node.9 3.html | 190 - static/freebsd/man9/ieee80211_output.9 3.html | 141 - static/freebsd/man9/ieee80211_proto.9 3.html | 198 - static/freebsd/man9/ieee80211_radiotap.9 3.html | 248 - static/freebsd/man9/ieee80211_regdomain.9 3.html | 118 - static/freebsd/man9/ieee80211_scan.9 3.html | 291 - static/freebsd/man9/ieee80211_vap.9 3.html | 116 - static/freebsd/man9/iflib.9 4.html | 55 - static/freebsd/man9/iflibdd.9 4.html | 367 - static/freebsd/man9/iflibdi.9 4.html | 250 - static/freebsd/man9/iflibtxrx.9 3.html | 258 - static/freebsd/man9/ifnet.9 3.html | 1731 ---- static/freebsd/man9/inittodr.9 3.html | 76 - static/freebsd/man9/insmntque.9 3.html | 84 - static/freebsd/man9/intr_event.9 3.html | 341 - static/freebsd/man9/intro.9 3.html | 387 - static/freebsd/man9/kasan.9 3.html | 137 - static/freebsd/man9/kern_reboot.9 3.html | 228 - static/freebsd/man9/kern_testfrwk.9 3.html | 150 - static/freebsd/man9/kern_yield.9 3.html | 114 - static/freebsd/man9/kernacc.9 4.html | 71 - static/freebsd/man9/kernel_mount.9 3.html | 160 - static/freebsd/man9/khelp.9 3.html | 309 - static/freebsd/man9/kmsan.9 3.html | 314 - static/freebsd/man9/kobj.9 3.html | 142 - static/freebsd/man9/kproc.9 3.html | 294 - static/freebsd/man9/kqueue.9 4.html | 299 - static/freebsd/man9/kstack_contains.9 4.html | 57 - static/freebsd/man9/kthread.9 3.html | 271 - static/freebsd/man9/ktr.9 4.html | 182 - static/freebsd/man9/lock.9 4.html | 431 - static/freebsd/man9/locking.9 3.html | 458 - static/freebsd/man9/mac.9 3.html | 200 - static/freebsd/man9/make_dev.9 4.html | 415 - static/freebsd/man9/malloc.9 4.html | 332 - static/freebsd/man9/mbchain.9 4.html | 229 - static/freebsd/man9/mbuf.9 4.html | 1032 --- static/freebsd/man9/mbuf_tags.9 4.html | 262 - static/freebsd/man9/mdchain.9 4.html | 229 - static/freebsd/man9/memcchr.9 4.html | 55 - static/freebsd/man9/memguard.9 3.html | 135 - static/freebsd/man9/mi_switch.9 3.html | 134 - static/freebsd/man9/microseq.9 4.html | 524 -- static/freebsd/man9/microtime.9 4.html | 104 - static/freebsd/man9/microuptime.9 4.html | 110 - static/freebsd/man9/mod_cc.9 3.html | 281 - static/freebsd/man9/module.9 3.html | 88 - static/freebsd/man9/mtx_pool.9 3.html | 162 - static/freebsd/man9/mutex.9 4.html | 456 - static/freebsd/man9/namei.9 3.html | 423 - static/freebsd/man9/netisr.9 4.html | 235 - static/freebsd/man9/nv.9 4.html | 1177 --- static/freebsd/man9/nvmem.9 3.html | 192 - static/freebsd/man9/ofw_bus_is_compatible.9 3.html | 138 - static/freebsd/man9/ofw_bus_status_okay.9 4.html | 72 - static/freebsd/man9/ofw_graph.9 4.html | 99 - static/freebsd/man9/osd.9 4.html | 307 - static/freebsd/man9/owll.9 4.html | 95 - static/freebsd/man9/own.9 4.html | 216 - static/freebsd/man9/p_candebug.9 4.html | 106 - static/freebsd/man9/p_cansee.9 4.html | 63 - static/freebsd/man9/panic.9 3.html | 114 - static/freebsd/man9/pci.9 4.html | 897 -- static/freebsd/man9/pci_iov_schema.9 3.html | 233 - static/freebsd/man9/pfil.9 3.html | 135 - static/freebsd/man9/pfind.9 4.html | 83 - static/freebsd/man9/pget.9 4.html | 87 - static/freebsd/man9/pgfind.9 4.html | 59 - static/freebsd/man9/physio.9 4.html | 100 - static/freebsd/man9/pmap.9 4.html | 98 - static/freebsd/man9/pmap_activate.9 4.html | 52 - static/freebsd/man9/pmap_clear_modify.9 4.html | 52 - static/freebsd/man9/pmap_copy.9 4.html | 78 - static/freebsd/man9/pmap_enter.9 3.html | 134 - static/freebsd/man9/pmap_extract.9 4.html | 88 - static/freebsd/man9/pmap_growkernel.9 4.html | 52 - static/freebsd/man9/pmap_init.9 4.html | 53 - static/freebsd/man9/pmap_is_modified.9 4.html | 70 - static/freebsd/man9/pmap_is_prefaultable.9 4.html | 56 - static/freebsd/man9/pmap_kextract.9 4.html | 83 - static/freebsd/man9/pmap_map.9 4.html | 74 - static/freebsd/man9/pmap_mincore.9 4.html | 66 - static/freebsd/man9/pmap_object_init_pt.9 4.html | 66 - .../freebsd/man9/pmap_page_exists_quick.9 4.html | 68 - static/freebsd/man9/pmap_page_init.9 4.html | 52 - static/freebsd/man9/pmap_pinit.9 4.html | 62 - static/freebsd/man9/pmap_protect.9 4.html | 54 - static/freebsd/man9/pmap_qenter.9 4.html | 78 - static/freebsd/man9/pmap_quick_enter_page.9 4.html | 93 - static/freebsd/man9/pmap_release.9 4.html | 60 - static/freebsd/man9/pmap_remove.9 4.html | 78 - static/freebsd/man9/pmap_resident_count.9 4.html | 75 - static/freebsd/man9/pmap_unwire.9 4.html | 61 - static/freebsd/man9/pmap_zero_page.9 4.html | 67 - static/freebsd/man9/printf.9 3.html | 162 - static/freebsd/man9/prison_check.9 4.html | 52 - static/freebsd/man9/priv.9 3.html | 102 - static/freebsd/man9/prng.9 4.html | 93 - static/freebsd/man9/proc_rwmem.9 4.html | 95 - static/freebsd/man9/pseudofs.9 4.html | 56 - static/freebsd/man9/psignal.9 3.html | 110 - static/freebsd/man9/pwmbus.9 3.html | 135 - static/freebsd/man9/random.9 4.html | 160 - static/freebsd/man9/random_harvest.9 4.html | 88 - static/freebsd/man9/ratecheck.9 4.html | 71 - static/freebsd/man9/redzone.9 4.html | 118 - static/freebsd/man9/refcount.9 3.html | 156 - static/freebsd/man9/regulator.9 4.html | 193 - static/freebsd/man9/resettodr.9 4.html | 49 - static/freebsd/man9/resource_int_value.9 4.html | 94 - static/freebsd/man9/rijndael.9 3.html | 99 - static/freebsd/man9/rman.9 4.html | 411 - static/freebsd/man9/rmlock.9 4.html | 366 - static/freebsd/man9/rtentry.9 3.html | 206 - static/freebsd/man9/runqueue.9 3.html | 107 - static/freebsd/man9/rwlock.9 4.html | 324 - static/freebsd/man9/sbuf.9 4.html | 525 -- static/freebsd/man9/scheduler.9 4.html | 208 - static/freebsd/man9/securelevel_gt.9 4.html | 65 - static/freebsd/man9/selrecord.9 4.html | 94 - static/freebsd/man9/sema.9 4.html | 126 - static/freebsd/man9/seqc.9 4.html | 124 - static/freebsd/man9/sf_buf.9 3.html | 110 - static/freebsd/man9/sglist.9 4.html | 471 - static/freebsd/man9/shm_map.9 4.html | 163 - static/freebsd/man9/signal.9 4.html | 356 - static/freebsd/man9/sleep.9 4.html | 307 - static/freebsd/man9/sleepqueue.9 4.html | 326 - static/freebsd/man9/smr.9 3.html | 234 - static/freebsd/man9/socket.9 4.html | 563 -- static/freebsd/man9/stack.9 4.html | 174 - static/freebsd/man9/store.9 4.html | 92 - static/freebsd/man9/style.9 3.html | 783 -- static/freebsd/man9/style.lua.9 3.html | 101 - static/freebsd/man9/superio.9 4.html | 195 - static/freebsd/man9/swi.9 3.html | 172 - static/freebsd/man9/sx.9 4.html | 301 - .../freebsd/man9/syscall_helper_register.9 4.html | 129 - static/freebsd/man9/sysctl.9 3.html | 1148 --- static/freebsd/man9/sysctl_add_oid.9 3.html | 151 - static/freebsd/man9/sysctl_ctx_init.9 3.html | 200 - static/freebsd/man9/taskqueue.9 4.html | 494 - static/freebsd/man9/tcp_functions.9 3.html | 316 - static/freebsd/man9/thread_exit.9 4.html | 50 - static/freebsd/man9/time.9 4.html | 82 - static/freebsd/man9/tvtohz.9 4.html | 60 - static/freebsd/man9/ucred.9 4.html | 188 - static/freebsd/man9/uidinfo.9 4.html | 88 - static/freebsd/man9/uio.9 3.html | 212 - static/freebsd/man9/unr.9 4.html | 186 - static/freebsd/man9/usbdi.9 3.html | 477 - static/freebsd/man9/vaccess.9 3.html | 99 - static/freebsd/man9/vaccess_acl_nfs4.9 3.html | 111 - static/freebsd/man9/vaccess_acl_posix1e.9 3.html | 109 - static/freebsd/man9/vflush.9 4.html | 81 - static/freebsd/man9/vfs_busy.9 4.html | 84 - static/freebsd/man9/vfs_getnewfsid.9 4.html | 72 - static/freebsd/man9/vfs_getopt.9 4.html | 176 - static/freebsd/man9/vfs_getvfs.9 4.html | 71 - static/freebsd/man9/vfs_mountedfrom.9 4.html | 48 - static/freebsd/man9/vfs_rootmountalloc.9 4.html | 60 - static/freebsd/man9/vfs_suser.9 4.html | 70 - static/freebsd/man9/vfs_timestamp.9 4.html | 55 - static/freebsd/man9/vfs_unbusy.9 4.html | 54 - static/freebsd/man9/vfs_unmountall.9 4.html | 41 - static/freebsd/man9/vfsconf.9 3.html | 121 - static/freebsd/man9/vget.9 4.html | 64 - static/freebsd/man9/vgone.9 4.html | 57 - static/freebsd/man9/vhold.9 4.html | 76 - static/freebsd/man9/vinvalbuf.9 4.html | 111 - static/freebsd/man9/vm_fault_prefault.9 4.html | 71 - static/freebsd/man9/vm_map.9 4.html | 290 - .../freebsd/man9/vm_map_check_protection.9 4.html | 70 - static/freebsd/man9/vm_map_delete.9 4.html | 68 - .../freebsd/man9/vm_map_entry_resize_free.9 3.html | 176 - static/freebsd/man9/vm_map_find.9 3.html | 122 - static/freebsd/man9/vm_map_findspace.9 4.html | 74 - static/freebsd/man9/vm_map_inherit.9 4.html | 75 - static/freebsd/man9/vm_map_init.9 4.html | 61 - static/freebsd/man9/vm_map_insert.9 4.html | 82 - static/freebsd/man9/vm_map_lock.9 4.html | 118 - static/freebsd/man9/vm_map_lookup.9 3.html | 83 - static/freebsd/man9/vm_map_madvise.9 4.html | 66 - static/freebsd/man9/vm_map_max.9 4.html | 66 - static/freebsd/man9/vm_map_protect.9 3.html | 105 - static/freebsd/man9/vm_map_remove.9 4.html | 69 - static/freebsd/man9/vm_map_stack.9 3.html | 102 - static/freebsd/man9/vm_map_submap.9 3.html | 78 - static/freebsd/man9/vm_map_sync.9 4.html | 71 - static/freebsd/man9/vm_map_wire.9 3.html | 99 - static/freebsd/man9/vm_page_aflag.9 4.html | 92 - static/freebsd/man9/vm_page_alloc.9 4.html | 248 - static/freebsd/man9/vm_page_bits.9 4.html | 141 - static/freebsd/man9/vm_page_busy.9 4.html | 178 - static/freebsd/man9/vm_page_deactivate.9 4.html | 50 - static/freebsd/man9/vm_page_dontneed.9 4.html | 57 - static/freebsd/man9/vm_page_free.9 3.html | 93 - static/freebsd/man9/vm_page_grab.9 4.html | 76 - static/freebsd/man9/vm_page_insert.9 4.html | 88 - static/freebsd/man9/vm_page_lookup.9 4.html | 59 - static/freebsd/man9/vm_page_rename.9 4.html | 62 - static/freebsd/man9/vm_page_wire.9 4.html | 77 - static/freebsd/man9/vm_set_page_size.9 4.html | 51 - static/freebsd/man9/vmem.9 3.html | 261 - static/freebsd/man9/vn_deallocate.9 4.html | 99 - static/freebsd/man9/vn_fullpath.9 3.html | 156 - static/freebsd/man9/vn_isdisk.9 4.html | 67 - static/freebsd/man9/vnode.9 3.html | 153 - .../freebsd/man9/vnode_pager_purge_range.9 4.html | 71 - static/freebsd/man9/vnode_pager_setsize.9 4.html | 72 - static/freebsd/man9/vref.9 4.html | 68 - static/freebsd/man9/vrefcnt.9 4.html | 48 - static/freebsd/man9/vrele.9 4.html | 85 - static/freebsd/man9/vslock.9 4.html | 79 - static/freebsd/man9/watchdog.9 4.html | 71 - static/freebsd/man9/zero_region.9 4.html | 85 - static/freebsd/man9/zone.9 3.html | 596 -- static/netbsd/man4/aac.4 4.html | 80 - static/netbsd/man4/ac97.4 4.html | 50 - static/netbsd/man4/acardide.4 4.html | 56 - static/netbsd/man4/aceride.4 4.html | 49 - static/netbsd/man4/acphy.4 4.html | 39 - static/netbsd/man4/acpi.4 4.html | 626 -- static/netbsd/man4/acpiacad.4 4.html | 44 - static/netbsd/man4/acpibat.4 4.html | 86 - static/netbsd/man4/acpibut.4 4.html | 55 - static/netbsd/man4/acpicpu.4 3.html | 236 - static/netbsd/man4/acpidalb.4 4.html | 56 - static/netbsd/man4/acpiec.4 4.html | 74 - static/netbsd/man4/acpifan.4 3.html | 57 - static/netbsd/man4/acpihed.4 4.html | 52 - static/netbsd/man4/acpilid.4 4.html | 79 - static/netbsd/man4/acpipmtr.4 4.html | 54 - static/netbsd/man4/acpismbus.4 4.html | 63 - static/netbsd/man4/acpitz.4 4.html | 96 - static/netbsd/man4/acpivga.4 4.html | 91 - static/netbsd/man4/acpivmgenid.4 4.html | 83 - static/netbsd/man4/acpiwdrt.4 4.html | 46 - static/netbsd/man4/acpiwmi.4 4.html | 83 - static/netbsd/man4/adb.4 4.html | 187 - static/netbsd/man4/adbbt.4 4.html | 43 - static/netbsd/man4/adbkbd.4 4.html | 51 - static/netbsd/man4/adbms.4 4.html | 45 - static/netbsd/man4/adc.4 4.html | 41 - static/netbsd/man4/adm1026hm.4 4.html | 128 - static/netbsd/man4/admtemp.4 3.html | 78 - static/netbsd/man4/adv.4 4.html | 144 - static/netbsd/man4/adw.4 4.html | 83 - static/netbsd/man4/age.4 4.html | 74 - static/netbsd/man4/agp.4 4.html | 230 - static/netbsd/man4/agr.4 4.html | 122 - static/netbsd/man4/aha.4 4.html | 60 - static/netbsd/man4/ahb.4 4.html | 45 - static/netbsd/man4/ahc.4 3.html | 347 - static/netbsd/man4/ahcisata.4 4.html | 55 - static/netbsd/man4/ahd.4 3.html | 149 - static/netbsd/man4/aht20temp.4 4.html | 69 - static/netbsd/man4/ai.4 4.html | 53 - static/netbsd/man4/aibs.4 3.html | 143 - static/netbsd/man4/aic.4 4.html | 56 - static/netbsd/man4/akbd.4 4.html | 121 - static/netbsd/man4/alc.4 3.html | 67 - static/netbsd/man4/ale.4 4.html | 75 - static/netbsd/man4/alipm.4 4.html | 55 - static/netbsd/man4/altmem.4 4.html | 59 - static/netbsd/man4/altq.4 4.html | 89 - static/netbsd/man4/am2315temp.4 4.html | 87 - static/netbsd/man4/amdgpio.4 4.html | 73 - static/netbsd/man4/amdpm.4 4.html | 48 - static/netbsd/man4/amdtemp.4 4.html | 75 - static/netbsd/man4/amhphy.4 4.html | 35 - static/netbsd/man4/amr.4 4.html | 173 - static/netbsd/man4/ams.4 3.html | 62 - static/netbsd/man4/an.4 3.html | 106 - static/netbsd/man4/apei.4 4.html | 107 - static/netbsd/man4/aps.4 4.html | 126 - static/netbsd/man4/aq.4 4.html | 70 - static/netbsd/man4/arcmsr.4 3.html | 113 - static/netbsd/man4/arcofi.4 4.html | 98 - static/netbsd/man4/aria.4 4.html | 59 - static/netbsd/man4/artsata.4 4.html | 53 - static/netbsd/man4/ast.4 4.html | 65 - static/netbsd/man4/asus.4 4.html | 69 - static/netbsd/man4/ata.4 4.html | 46 - static/netbsd/man4/atalk.4 4.html | 98 - static/netbsd/man4/ataraid.4 4.html | 71 - static/netbsd/man4/ate.4 4.html | 55 - static/netbsd/man4/ath.4 3.html | 450 - static/netbsd/man4/athn.4 3.html | 331 - static/netbsd/man4/atphy.4 4.html | 37 - static/netbsd/man4/atppc.4 4.html | 101 - static/netbsd/man4/attimer.4 4.html | 43 - static/netbsd/man4/atu.4 4.html | 94 - static/netbsd/man4/atw.4 3.html | 144 - static/netbsd/man4/auacer.4 4.html | 47 - static/netbsd/man4/aubtfwl.4 3.html | 58 - static/netbsd/man4/audio.4 3.html | 635 -- static/netbsd/man4/audiocs.4 4.html | 45 - static/netbsd/man4/aue.4 4.html | 145 - static/netbsd/man4/auich.4 4.html | 64 - static/netbsd/man4/auixp.4 4.html | 50 - static/netbsd/man4/autri.4 4.html | 44 - static/netbsd/man4/auvia.4 4.html | 45 - static/netbsd/man4/auvitek.4 4.html | 87 - static/netbsd/man4/awi.4 3.html | 154 - static/netbsd/man4/axe.4 4.html | 160 - static/netbsd/man4/axen.4 4.html | 94 - static/netbsd/man4/az.4 4.html | 64 - static/netbsd/man4/battery_pmu.4 4.html | 46 - static/netbsd/man4/bba.4 4.html | 46 - static/netbsd/man4/bce.4 4.html | 53 - static/netbsd/man4/bcsp.4 4.html | 57 - static/netbsd/man4/be.4 4.html | 62 - static/netbsd/man4/bge.4 3.html | 163 - static/netbsd/man4/bha.4 4.html | 68 - static/netbsd/man4/bio.4 4.html | 171 - static/netbsd/man4/bktr.4 4.html | 450 - static/netbsd/man4/bluetooth.4 4.html | 363 - static/netbsd/man4/bmtphy.4 4.html | 40 - static/netbsd/man4/bmx280thp.4 4.html | 111 - static/netbsd/man4/bnx.4 4.html | 132 - static/netbsd/man4/boca.4 4.html | 130 - static/netbsd/man4/bochsfb.4 4.html | 66 - static/netbsd/man4/bpf.4 3.html | 838 -- static/netbsd/man4/bpfjit.4 4.html | 86 - static/netbsd/man4/brgphy.4 4.html | 36 - static/netbsd/man4/bridge.4 3.html | 93 - static/netbsd/man4/bt3c.4 4.html | 78 - static/netbsd/man4/btbc.4 4.html | 41 - static/netbsd/man4/bthidev.4 4.html | 85 - static/netbsd/man4/bthub.4 4.html | 102 - static/netbsd/man4/btkbd.4 4.html | 59 - static/netbsd/man4/btmagic.4 3.html | 99 - static/netbsd/man4/btms.4 4.html | 46 - static/netbsd/man4/btsco.4 4.html | 97 - static/netbsd/man4/btuart.4 4.html | 51 - static/netbsd/man4/bwfm.4 4.html | 49 - static/netbsd/man4/bwi.4 4.html | 167 - static/netbsd/man4/cac.4 4.html | 92 - static/netbsd/man4/can.4 4.html | 105 - static/netbsd/man4/canloop.4 4.html | 46 - static/netbsd/man4/cardbus.4 4.html | 214 - static/netbsd/man4/carp.4 3.html | 159 - static/netbsd/man4/cas.4 4.html | 75 - static/netbsd/man4/ccd.4 3.html | 96 - static/netbsd/man4/cd.4 4.html | 274 - static/netbsd/man4/cdce.4 4.html | 112 - static/netbsd/man4/cec.4 4.html | 55 - static/netbsd/man4/cfb.4 4.html | 40 - static/netbsd/man4/cgd.4 3.html | 231 - static/netbsd/man4/ch.4 4.html | 67 - static/netbsd/man4/chipsfb.4 4.html | 44 - static/netbsd/man4/ciphy.4 4.html | 46 - static/netbsd/man4/cir.4 4.html | 43 - static/netbsd/man4/ciss.4 4.html | 127 - static/netbsd/man4/clcs.4 4.html | 47 - static/netbsd/man4/clct.4 4.html | 42 - static/netbsd/man4/clockctl.4 4.html | 100 - static/netbsd/man4/cmdide.4 4.html | 65 - static/netbsd/man4/cmpci.4 4.html | 136 - static/netbsd/man4/cms.4 4.html | 51 - static/netbsd/man4/cnw.4 4.html | 74 - static/netbsd/man4/com.4 4.html | 189 - static/netbsd/man4/coram.4 4.html | 56 - static/netbsd/man4/crypto.4 3.html | 616 -- static/netbsd/man4/cs.4 4.html | 51 - static/netbsd/man4/cs80bus.4 4.html | 42 - static/netbsd/man4/cuda.4 4.html | 43 - static/netbsd/man4/cue.4 4.html | 76 - static/netbsd/man4/cxdtv.4 4.html | 57 - static/netbsd/man4/cy.4 4.html | 89 - static/netbsd/man4/cypide.4 4.html | 49 - static/netbsd/man4/cz.4 3.html | 102 - static/netbsd/man4/dbcool.4 3.html | 265 - static/netbsd/man4/ddb.4 4.html | 1210 --- static/netbsd/man4/ddc.4 4.html | 54 - static/netbsd/man4/dge.4 3.html | 126 - static/netbsd/man4/dk.4 3.html | 135 - static/netbsd/man4/dm.4 3.html | 110 - static/netbsd/man4/dmoverio.4 4.html | 204 - static/netbsd/man4/dmphy.4 3.html | 37 - static/netbsd/man4/dpt.4 4.html | 109 - static/netbsd/man4/dpti.4 4.html | 53 - static/netbsd/man4/drm.4 4.html | 205 - static/netbsd/man4/drum.4 4.html | 46 - static/netbsd/man4/drvctl.4 4.html | 172 - static/netbsd/man4/ds2482ow.4 4.html | 95 - static/netbsd/man4/ds28e17iic.4 3.html | 92 - static/netbsd/man4/dse.4 4.html | 62 - static/netbsd/man4/dtide.4 4.html | 46 - static/netbsd/man4/dtv.4 4.html | 94 - static/netbsd/man4/dtviic.4 4.html | 110 - static/netbsd/man4/dwctwo.4 4.html | 41 - static/netbsd/man4/ea.4 4.html | 52 - static/netbsd/man4/eap.4 4.html | 77 - static/netbsd/man4/eb.4 4.html | 43 - static/netbsd/man4/ebus.4 4.html | 46 - static/netbsd/man4/ec.4 3.html | 102 - static/netbsd/man4/edc.4 4.html | 60 - static/netbsd/man4/ef.4 4.html | 42 - static/netbsd/man4/eg.4 4.html | 41 - static/netbsd/man4/ehci.4 4.html | 59 - static/netbsd/man4/ei.4 4.html | 40 - static/netbsd/man4/eisa.4 4.html | 103 - static/netbsd/man4/el.4 4.html | 45 - static/netbsd/man4/elmc.4 4.html | 42 - static/netbsd/man4/emcfan.4 3.html | 180 - static/netbsd/man4/emdtv.4 4.html | 66 - static/netbsd/man4/emuxki.4 4.html | 72 - static/netbsd/man4/ena.4 4.html | 78 - static/netbsd/man4/envsys.4 3.html | 403 - static/netbsd/man4/ep.4 3.html | 164 - static/netbsd/man4/epic.4 4.html | 46 - static/netbsd/man4/eqos.4 4.html | 45 - static/netbsd/man4/esa.4 4.html | 57 - static/netbsd/man4/esiop.4 4.html | 70 - static/netbsd/man4/esm.4 4.html | 56 - static/netbsd/man4/eso.4 4.html | 68 - static/netbsd/man4/esp.4 4.html | 113 - static/netbsd/man4/ess.4 4.html | 70 - static/netbsd/man4/et.4 4.html | 66 - static/netbsd/man4/etphy.4 4.html | 50 - static/netbsd/man4/ex.4 4.html | 153 - static/netbsd/man4/exphy.4 4.html | 36 - static/netbsd/man4/faith.4 3.html | 82 - static/netbsd/man4/fd.4 4.html | 72 - static/netbsd/man4/finsio.4 4.html | 138 - static/netbsd/man4/flash.4 4.html | 66 - static/netbsd/man4/fms.4 4.html | 47 - static/netbsd/man4/fmv.4 4.html | 63 - static/netbsd/man4/fss.4 4.html | 123 - static/netbsd/man4/fujbp.4 4.html | 78 - static/netbsd/man4/full.4 4.html | 43 - static/netbsd/man4/fwip.4 4.html | 59 - static/netbsd/man4/fwohci.4 4.html | 93 - static/netbsd/man4/fxp.4 4.html | 120 - static/netbsd/man4/g760a.4 4.html | 54 - static/netbsd/man4/gcscaudio.4 4.html | 52 - static/netbsd/man4/gem.4 4.html | 82 - static/netbsd/man4/genet.4 4.html | 86 - static/netbsd/man4/genfb.4 4.html | 89 - static/netbsd/man4/gentbi.4 4.html | 36 - static/netbsd/man4/geodeide.4 4.html | 62 - static/netbsd/man4/gif.4 3.html | 201 - static/netbsd/man4/glxtphy.4 3.html | 36 - static/netbsd/man4/gphyter.4 4.html | 38 - static/netbsd/man4/gpib.4 4.html | 53 - static/netbsd/man4/gpio.4 4.html | 244 - static/netbsd/man4/gpioiic.4 4.html | 75 - static/netbsd/man4/gpioirq.4 4.html | 132 - static/netbsd/man4/gpiolock.4 4.html | 58 - static/netbsd/man4/gpioow.4 4.html | 62 - static/netbsd/man4/gpiopps.4 3.html | 82 - static/netbsd/man4/gpiopwm.4 4.html | 80 - static/netbsd/man4/gpiosim.4 4.html | 51 - static/netbsd/man4/gre.4 3.html | 305 - static/netbsd/man4/gscan.4 4.html | 48 - static/netbsd/man4/gsip.4 4.html | 71 - static/netbsd/man4/gtp.4 4.html | 64 - static/netbsd/man4/gus.4 3.html | 74 - static/netbsd/man4/guspnp.4 4.html | 97 - static/netbsd/man4/hcide.4 4.html | 47 - static/netbsd/man4/hdaudio.4 4.html | 111 - static/netbsd/man4/hifn.4 4.html | 88 - static/netbsd/man4/hil.4 4.html | 61 - static/netbsd/man4/hilid.4 4.html | 40 - static/netbsd/man4/hilkbd.4 4.html | 84 - static/netbsd/man4/hilms.4 4.html | 39 - static/netbsd/man4/hme.4 4.html | 81 - static/netbsd/man4/hpacel.4 4.html | 66 - static/netbsd/man4/hpqlb.4 4.html | 57 - static/netbsd/man4/hptide.4 4.html | 50 - static/netbsd/man4/hvn.4 4.html | 63 - static/netbsd/man4/hythygtemp.4 4.html | 67 - static/netbsd/man4/iavf.4 4.html | 51 - static/netbsd/man4/ibmcd.4 4.html | 59 - static/netbsd/man4/ibmhawk.4 4.html | 43 - static/netbsd/man4/ichsmb.4 4.html | 63 - static/netbsd/man4/icmp.4 3.html | 87 - static/netbsd/man4/icmp6.4 4.html | 387 - static/netbsd/man4/icp.4 4.html | 69 - static/netbsd/man4/icsphy.4 4.html | 36 - static/netbsd/man4/iee.4 4.html | 152 - static/netbsd/man4/ieee1394if.4 4.html | 75 - static/netbsd/man4/ieee80211.4 3.html | 186 - static/netbsd/man4/ietp.4 4.html | 49 - static/netbsd/man4/ifmedia.4 4.html | 380 - static/netbsd/man4/igc.4 4.html | 68 - static/netbsd/man4/igmafb.4 4.html | 76 - static/netbsd/man4/igphy.4 4.html | 38 - static/netbsd/man4/igpio.4 4.html | 101 - static/netbsd/man4/igsfb.4 4.html | 48 - static/netbsd/man4/iha.4 4.html | 56 - static/netbsd/man4/ihidev.4 4.html | 46 - static/netbsd/man4/ihphy.4 4.html | 37 - static/netbsd/man4/iic.4 4.html | 311 - static/netbsd/man4/ikphy.4 4.html | 42 - static/netbsd/man4/ims.4 4.html | 42 - static/netbsd/man4/inet.4 4.html | 128 - static/netbsd/man4/inet6.4 3.html | 196 - static/netbsd/man4/inphy.4 4.html | 43 - static/netbsd/man4/intersil7170.4 4.html | 98 - static/netbsd/man4/intro.4 3.html | 136 - static/netbsd/man4/ioasic.4 4.html | 68 - static/netbsd/man4/ioat.4 4.html | 72 - static/netbsd/man4/iop.4 2.html | 164 - static/netbsd/man4/iophy.4 4.html | 36 - static/netbsd/man4/iopsp.4 4.html | 54 - static/netbsd/man4/ip.4 3.html | 379 - static/netbsd/man4/ip6.4 3.html | 561 -- static/netbsd/man4/ipgphy.4 4.html | 35 - static/netbsd/man4/ipmi.4 4.html | 66 - static/netbsd/man4/ipsec.4 3.html | 350 - static/netbsd/man4/ipsecif.4 3.html | 142 - static/netbsd/man4/ipw.4 4.html | 83 - static/netbsd/man4/irframe.4 4.html | 74 - static/netbsd/man4/irframetty.4 4.html | 59 - static/netbsd/man4/irmce.4 4.html | 51 - static/netbsd/man4/isa.4 4.html | 255 - static/netbsd/man4/isapnp.4 4.html | 142 - static/netbsd/man4/ismt.4 4.html | 59 - static/netbsd/man4/isp.4 4.html | 127 - static/netbsd/man4/isv.4 3.html | 72 - static/netbsd/man4/iteide.4 4.html | 54 - static/netbsd/man4/itesio.4 4.html | 145 - static/netbsd/man4/iwi.4 4.html | 85 - static/netbsd/man4/iwm.4 4.html | 55 - static/netbsd/man4/iwn.4 3.html | 220 - static/netbsd/man4/ix.4 4.html | 38 - static/netbsd/man4/ixg.4 4.html | 88 - static/netbsd/man4/ixl.4 4.html | 60 - static/netbsd/man4/ixpide.4 4.html | 59 - static/netbsd/man4/ixv.4 4.html | 63 - static/netbsd/man4/iy.4 4.html | 68 - static/netbsd/man4/jme.4 3.html | 77 - static/netbsd/man4/jmide.4 4.html | 56 - static/netbsd/man4/jmphy.4 4.html | 57 - static/netbsd/man4/joy.4 4.html | 130 - static/netbsd/man4/kcov.4 3.html | 174 - static/netbsd/man4/kloader.4 4.html | 71 - static/netbsd/man4/kse.4 4.html | 59 - static/netbsd/man4/ksyms.4 4.html | 103 - static/netbsd/man4/kttcp.4 4.html | 50 - static/netbsd/man4/kue.4 4.html | 106 - static/netbsd/man4/l2tp.4 3.html | 157 - static/netbsd/man4/lagg.4 3.html | 139 - static/netbsd/man4/lc.4 4.html | 49 - static/netbsd/man4/ld.4 4.html | 83 - static/netbsd/man4/le.4 4.html | 383 - static/netbsd/man4/lii.4 4.html | 45 - static/netbsd/man4/lm.4 4.html | 194 - static/netbsd/man4/lmenv.4 4.html | 107 - static/netbsd/man4/lmtemp.4 3.html | 118 - static/netbsd/man4/lo.4 4.html | 68 - static/netbsd/man4/lpt.4 4.html | 72 - static/netbsd/man4/lua.4 4.html | 189 - static/netbsd/man4/lxtphy.4 4.html | 36 - static/netbsd/man4/m25p.4 4.html | 48 - static/netbsd/man4/machfb.4 4.html | 76 - static/netbsd/man4/mainbus.4 4.html | 38 - static/netbsd/man4/makphy.4 4.html | 37 - static/netbsd/man4/malo.4 4.html | 148 - static/netbsd/man4/man4.alpha/intro.4 2.html | 403 - static/netbsd/man4/man4.alpha/jensenio.4 3.html | 62 - static/netbsd/man4/man4.alpha/tlsb.4 3.html | 50 - static/netbsd/man4/man4.alpha/tsciic.4 3.html | 37 - static/netbsd/man4/man4.amiga/a34kbbc.4 3.html | 40 - static/netbsd/man4/man4.amiga/afsc.4 3.html | 76 - static/netbsd/man4/man4.amiga/ahsc.4 3.html | 68 - static/netbsd/man4/man4.amiga/bppcsc.4 3.html | 63 - static/netbsd/man4/man4.amiga/cv3dpb.4 3.html | 67 - static/netbsd/man4/man4.amiga/drbbc.4 3.html | 39 - static/netbsd/man4/man4.amiga/efa.4 3.html | 106 - static/netbsd/man4/man4.amiga/em4k.4 3.html | 83 - static/netbsd/man4/man4.amiga/grfcv3d.4 3.html | 89 - static/netbsd/man4/man4.amiga/grfrh.4 3.html | 75 - static/netbsd/man4/man4.amiga/grful.4 3.html | 79 - static/netbsd/man4/man4.amiga/intro.4 2.html | 147 - static/netbsd/man4/man4.amiga/mfcs.4 3.html | 74 - static/netbsd/man4/man4.amiga/p5pb.4 3.html | 91 - static/netbsd/man4/man4.amiga/xsh.4 3.html | 69 - static/netbsd/man4/man4.amiga/zssc.4 3.html | 65 - static/netbsd/man4/man4.arc/intro.4 3.html | 183 - static/netbsd/man4/man4.atari/floppy.4 3.html | 77 - static/netbsd/man4/man4.atari/intro.4 2.html | 133 - static/netbsd/man4/man4.atari/rtc.4 3.html | 52 - static/netbsd/man4/man4.dreamcast/intro.4 3.html | 104 - static/netbsd/man4/man4.dreamcast/maple.4 3.html | 73 - static/netbsd/man4/man4.dreamcast/mlcd.4 3.html | 53 - static/netbsd/man4/man4.emips/autoconf.4 3.html | 45 - static/netbsd/man4/man4.emips/ebus.4 3.html | 51 - static/netbsd/man4/man4.emips/enic.4 3.html | 67 - static/netbsd/man4/man4.evbarm/awge.4 3.html | 50 - static/netbsd/man4/man4.evbarm/cpsw.4 3.html | 45 - static/netbsd/man4/man4.evbarm/gxio.4 3.html | 136 - static/netbsd/man4/man4.evbarm/iopaau.4 3.html | 87 - static/netbsd/man4/man4.evbarm/vcaudio.4 3.html | 54 - static/netbsd/man4/man4.evbmips/cnmac.4 3.html | 50 - .../netbsd/man4/man4.evbppc/intro_pmppc.4 3.html | 96 - static/netbsd/man4/man4.evbppc/rtc.4 3.html | 39 - static/netbsd/man4/man4.hp300/autoconf.4 3.html | 112 - static/netbsd/man4/man4.hp300/ct.4 3.html | 60 - static/netbsd/man4/man4.hp300/dcm.4 3.html | 69 - static/netbsd/man4/man4.hp300/dnkbd.4 3.html | 34 - static/netbsd/man4/man4.hp300/gbox.4 3.html | 59 - static/netbsd/man4/man4.hp300/intro.4 3.html | 171 - static/netbsd/man4/man4.hp300/ppi.4 3.html | 52 - static/netbsd/man4/man4.hp300/topcat.4 3.html | 48 - static/netbsd/man4/man4.hpcarm/intro.4 2.html | 125 - static/netbsd/man4/man4.hpcarm/j720lcd.4 3.html | 42 - static/netbsd/man4/man4.hpcsh/intro.4 3.html | 139 - static/netbsd/man4/man4.hpcsh/psh3tp.4 3.html | 44 - static/netbsd/man4/man4.hppa/asp.4 3.html | 74 - static/netbsd/man4/man4.hppa/astro.4 3.html | 46 - static/netbsd/man4/man4.hppa/dino.4 3.html | 74 - static/netbsd/man4/man4.hppa/elroy.4 3.html | 43 - static/netbsd/man4/man4.hppa/harmony.4 3.html | 79 - static/netbsd/man4/man4.hppa/mem.4 3.html | 63 - static/netbsd/man4/man4.hppa/ssio.4 3.html | 55 - static/netbsd/man4/man4.hppa/uturn.4 3.html | 55 - static/netbsd/man4/man4.i386/cmos.4 3.html | 86 - static/netbsd/man4/man4.i386/elanpar.4 3.html | 83 - static/netbsd/man4/man4.i386/elanpex.4 3.html | 107 - static/netbsd/man4/man4.i386/elansc.4 3.html | 98 - static/netbsd/man4/man4.i386/mms.4 3.html | 39 - static/netbsd/man4/man4.i386/pcibios.4 3.html | 173 - static/netbsd/man4/man4.i386/rdcide.4 3.html | 44 - static/netbsd/man4/man4.i386/rdcpcib.4 3.html | 47 - static/netbsd/man4/man4.mac68k/cpi.4 3.html | 202 - static/netbsd/man4/man4.mac68k/iwm.4 3.html | 105 - static/netbsd/man4/man4.mac68k/netdock.4 3.html | 66 - static/netbsd/man4/man4.mac68k/obio.4 3.html | 120 - static/netbsd/man4/man4.mac68k/pbbat.4 3.html | 89 - static/netbsd/man4/man4.mac68k/zsc.4 3.html | 62 - static/netbsd/man4/man4.macppc/awacs.4 3.html | 52 - static/netbsd/man4/man4.macppc/bm.4 3.html | 50 - static/netbsd/man4/man4.macppc/gm.4 3.html | 56 - static/netbsd/man4/man4.macppc/intro.4 2.html | 128 - static/netbsd/man4/man4.macppc/mesh.4 3.html | 70 - static/netbsd/man4/man4.macppc/obio.4 3.html | 125 - static/netbsd/man4/man4.macppc/pbms.4 3.html | 49 - static/netbsd/man4/man4.macppc/platinumfb.4 3.html | 55 - static/netbsd/man4/man4.macppc/snapper.4 3.html | 57 - static/netbsd/man4/man4.mvme68k/clmpcc.4 3.html | 82 - static/netbsd/man4/man4.mvme68k/intro.4 3.html | 113 - static/netbsd/man4/man4.mvme68k/mem.4 3.html | 51 - static/netbsd/man4/man4.mvme68k/memc.4 3.html | 63 - static/netbsd/man4/man4.mvme68k/ncrsc.4 3.html | 50 - static/netbsd/man4/man4.mvme68k/pcc.4 3.html | 46 - static/netbsd/man4/man4.mvme68k/pcctwo.4 3.html | 47 - static/netbsd/man4/man4.mvme68k/wdsc.4 3.html | 57 - static/netbsd/man4/man4.mvme68k/zsc.4 3.html | 56 - static/netbsd/man4/man4.pmax/asc.4 3.html | 53 - static/netbsd/man4/man4.pmax/autoconf.4 3.html | 45 - static/netbsd/man4/man4.pmax/ibus.4 3.html | 53 - static/netbsd/man4/man4.pmax/intro.4 2.html | 175 - static/netbsd/man4/man4.pmax/pm.4 3.html | 42 - static/netbsd/man4/man4.pmax/sii.4 3.html | 52 - static/netbsd/man4/man4.pmax/xcfb.4 3.html | 41 - static/netbsd/man4/man4.prep/intro.4 3.html | 105 - static/netbsd/man4/man4.prep/nvram.4 3.html | 89 - static/netbsd/man4/man4.sandpoint/nhpow.4 3.html | 173 - static/netbsd/man4/man4.sandpoint/satmgr.4 3.html | 92 - static/netbsd/man4/man4.sgimips/crime.4 3.html | 44 - static/netbsd/man4/man4.sgimips/dpclock.4 3.html | 42 - static/netbsd/man4/man4.sgimips/dsclock.4 3.html | 41 - static/netbsd/man4/man4.sgimips/gio.4 3.html | 73 - static/netbsd/man4/man4.sgimips/giopci.4 3.html | 52 - static/netbsd/man4/man4.sgimips/grtwo.4 3.html | 54 - static/netbsd/man4/man4.sgimips/haltwo.4 3.html | 44 - static/netbsd/man4/man4.sgimips/hpc.4 3.html | 86 - static/netbsd/man4/man4.sgimips/imc.4 3.html | 41 - static/netbsd/man4/man4.sgimips/intro.4 3.html | 140 - static/netbsd/man4/man4.sgimips/light.4 3.html | 58 - static/netbsd/man4/man4.sgimips/mace.4 3.html | 43 - static/netbsd/man4/man4.sgimips/mavb.4 3.html | 65 - static/netbsd/man4/man4.sgimips/mec.4 3.html | 49 - static/netbsd/man4/man4.sgimips/newport.4 3.html | 44 - static/netbsd/man4/man4.sgimips/pic.4 3.html | 41 - static/netbsd/man4/man4.sgimips/sq.4 3.html | 47 - static/netbsd/man4/man4.sgimips/wdsc.4 3.html | 47 - static/netbsd/man4/man4.sparc/apc.4 4.html | 41 - static/netbsd/man4/man4.sparc/audioamd.4 4.html | 42 - static/netbsd/man4/man4.sparc/autoconf.4 4.html | 45 - static/netbsd/man4/man4.sparc/auxreg.4 3.html | 46 - static/netbsd/man4/man4.sparc/bpp.4 4.html | 35 - static/netbsd/man4/man4.sparc/bwtwo.4 4.html | 36 - static/netbsd/man4/man4.sparc/cgeight.4 4.html | 44 - static/netbsd/man4/man4.sparc/cgfour.4 4.html | 44 - static/netbsd/man4/man4.sparc/cgfourteen.4 4.html | 45 - static/netbsd/man4/man4.sparc/cgsix.4 4.html | 142 - static/netbsd/man4/man4.sparc/cgthree.4 4.html | 41 - static/netbsd/man4/man4.sparc/cgtwo.4 4.html | 41 - static/netbsd/man4/man4.sparc/clock.4 4.html | 69 - static/netbsd/man4/man4.sparc/dbri.4 4.html | 37 - static/netbsd/man4/man4.sparc/fd.4 4.html | 110 - static/netbsd/man4/man4.sparc/ie.4 4.html | 57 - static/netbsd/man4/man4.sparc/intro.4 3.html | 257 - static/netbsd/man4/man4.sparc/kbd.4 3.html | 127 - static/netbsd/man4/man4.sparc/magma.4 4.html | 115 - static/netbsd/man4/man4.sparc/mem.4 4.html | 53 - static/netbsd/man4/man4.sparc/ms.4 4.html | 72 - static/netbsd/man4/man4.sparc/nell.4 4.html | 49 - static/netbsd/man4/man4.sparc/openprom.4 3.html | 109 - static/netbsd/man4/man4.sparc/pnozz.4 4.html | 51 - static/netbsd/man4/man4.sparc/tctrl.4 3.html | 43 - static/netbsd/man4/man4.sparc/tcx.4 4.html | 42 - static/netbsd/man4/man4.sparc/timer.4 4.html | 45 - static/netbsd/man4/man4.sparc/tslot.4 4.html | 51 - static/netbsd/man4/man4.sparc/xd.4 4.html | 54 - static/netbsd/man4/man4.sparc/xy.4 4.html | 48 - static/netbsd/man4/man4.sparc/zx.4 4.html | 41 - static/netbsd/man4/man4.sparc64/envctrl.4 4.html | 125 - static/netbsd/man4/man4.sparc64/fdc.4 4.html | 112 - static/netbsd/man4/man4.sparc64/ffb.4 4.html | 179 - static/netbsd/man4/man4.sparc64/intro.4 4.html | 153 - static/netbsd/man4/man4.sparc64/lom.4 4.html | 61 - static/netbsd/man4/man4.sparc64/psycho.4 4.html | 42 - static/netbsd/man4/man4.sparc64/pyro.4 4.html | 52 - static/netbsd/man4/man4.sparc64/sab.4 4.html | 74 - static/netbsd/man4/man4.sparc64/schizo.4 4.html | 43 - static/netbsd/man4/man4.sparc64/tadpmu.4 4.html | 44 - static/netbsd/man4/man4.sparc64/tda.4 3.html | 70 - static/netbsd/man4/man4.sun2/autoconf.4 4.html | 45 - static/netbsd/man4/man4.sun2/bwtwo.4 4.html | 32 - static/netbsd/man4/man4.sun2/ec.4 4.html | 42 - static/netbsd/man4/man4.sun2/ie.4 4.html | 47 - static/netbsd/man4/man4.sun2/intro.4 3.html | 109 - static/netbsd/man4/man4.sun2/kbd.4 3.html | 126 - static/netbsd/man4/man4.sun2/leds.4 3.html | 95 - static/netbsd/man4/man4.sun2/mem.4 4.html | 50 - static/netbsd/man4/man4.sun2/ms.4 4.html | 72 - static/netbsd/man4/man4.sun3/autoconf.4 4.html | 45 - static/netbsd/man4/man4.sun3/bwtwo.4 4.html | 36 - static/netbsd/man4/man4.sun3/cgfour.4 4.html | 36 - static/netbsd/man4/man4.sun3/cgtwo.4 4.html | 37 - static/netbsd/man4/man4.sun3/fd.4 4.html | 109 - static/netbsd/man4/man4.sun3/ie.4 4.html | 44 - static/netbsd/man4/man4.sun3/intro.4 4.html | 147 - static/netbsd/man4/man4.sun3/kbd.4 3.html | 127 - static/netbsd/man4/man4.sun3/leds.4 4.html | 98 - static/netbsd/man4/man4.sun3/mem.4 4.html | 50 - static/netbsd/man4/man4.sun3/ms.4 4.html | 72 - static/netbsd/man4/man4.vax/acc.4 4.html | 76 - static/netbsd/man4/man4.vax/ad.4 4.html | 64 - static/netbsd/man4/man4.vax/asc.4 4.html | 68 - static/netbsd/man4/man4.vax/autoconf.4 3.html | 136 - static/netbsd/man4/man4.vax/cons.4 4.html | 134 - static/netbsd/man4/man4.vax/covid.4 3.html | 128 - static/netbsd/man4/man4.vax/crl.4 4.html | 50 - static/netbsd/man4/man4.vax/css.4 3.html | 71 - static/netbsd/man4/man4.vax/ct.4 4.html | 55 - static/netbsd/man4/man4.vax/ddn.4 3.html | 76 - static/netbsd/man4/man4.vax/de.4 4.html | 76 - static/netbsd/man4/man4.vax/dh.4 4.html | 85 - static/netbsd/man4/man4.vax/dhu.4 4.html | 71 - static/netbsd/man4/man4.vax/dl.4 4.html | 95 - static/netbsd/man4/man4.vax/dmc.4 4.html | 106 - static/netbsd/man4/man4.vax/dmf.4 4.html | 105 - static/netbsd/man4/man4.vax/dmv.4 4.html | 93 - static/netbsd/man4/man4.vax/dmz.4 4.html | 89 - static/netbsd/man4/man4.vax/dn.4 4.html | 109 - static/netbsd/man4/man4.vax/dz.4 4.html | 76 - static/netbsd/man4/man4.vax/ec.4 4.html | 91 - static/netbsd/man4/man4.vax/en.4 4.html | 89 - static/netbsd/man4/man4.vax/ex.4 4.html | 71 - static/netbsd/man4/man4.vax/fl.4 4.html | 56 - static/netbsd/man4/man4.vax/hdh.4 4.html | 81 - static/netbsd/man4/man4.vax/hk.4 4.html | 205 - static/netbsd/man4/man4.vax/hp.4 4.html | 120 - static/netbsd/man4/man4.vax/ht.4 4.html | 75 - static/netbsd/man4/man4.vax/hy.4 4.html | 99 - static/netbsd/man4/man4.vax/ik.4 4.html | 66 - static/netbsd/man4/man4.vax/il.4 4.html | 78 - static/netbsd/man4/man4.vax/intro.4 3.html | 272 - static/netbsd/man4/man4.vax/ix.4 3.html | 91 - static/netbsd/man4/man4.vax/kg.4 4.html | 45 - static/netbsd/man4/man4.vax/lp.4 4.html | 62 - static/netbsd/man4/man4.vax/mem.4 4.html | 60 - static/netbsd/man4/man4.vax/mt.4 4.html | 80 - static/netbsd/man4/man4.vax/mtc.4 4.html | 49 - static/netbsd/man4/man4.vax/np.4 3.html | 98 - static/netbsd/man4/man4.vax/pcl.4 2.html | 87 - static/netbsd/man4/man4.vax/ps.4 3.html | 120 - static/netbsd/man4/man4.vax/qe.4 4.html | 47 - static/netbsd/man4/man4.vax/qt.4 4.html | 57 - static/netbsd/man4/man4.vax/rf.4 4.html | 146 - static/netbsd/man4/man4.vax/rl.4 4.html | 92 - static/netbsd/man4/man4.vax/tm.4 4.html | 83 - static/netbsd/man4/man4.vax/ts.4 4.html | 67 - static/netbsd/man4/man4.vax/tu.4 3.html | 63 - static/netbsd/man4/man4.vax/uda.4 4.html | 60 - static/netbsd/man4/man4.vax/up.4 4.html | 528 -- static/netbsd/man4/man4.vax/ut.4 4.html | 82 - static/netbsd/man4/man4.vax/uu.4 4.html | 111 - static/netbsd/man4/man4.vax/va.4 4.html | 121 - static/netbsd/man4/man4.vax/vp.4 4.html | 101 - static/netbsd/man4/man4.vax/vv.4 4.html | 80 - static/netbsd/man4/man4.x68k/bmd.4 4.html | 58 - static/netbsd/man4/man4.x68k/intio.4 4.html | 50 - static/netbsd/man4/man4.x68k/intro.4 3.html | 121 - static/netbsd/man4/man4.x68k/mfp.4 4.html | 50 - static/netbsd/man4/man4.x68k/neptune.4 4.html | 55 - static/netbsd/man4/man4.x68k/powsw.4 4.html | 48 - static/netbsd/man4/man4.x68k/vs.4 4.html | 37 - static/netbsd/man4/man4.x86/amdccp.4 4.html | 44 - static/netbsd/man4/man4.x86/amdpcib.4 4.html | 55 - static/netbsd/man4/man4.x86/amdsmn.4 4.html | 46 - static/netbsd/man4/man4.x86/amdzentemp.4 4.html | 82 - static/netbsd/man4/man4.x86/apic.4 4.html | 101 - static/netbsd/man4/man4.x86/autoconf.4 4.html | 45 - static/netbsd/man4/man4.x86/balloon.4 4.html | 159 - static/netbsd/man4/man4.x86/console.4 3.html | 114 - static/netbsd/man4/man4.x86/coretemp.4 4.html | 66 - static/netbsd/man4/man4.x86/est.4 4.html | 68 - static/netbsd/man4/man4.x86/fdc.4 4.html | 110 - static/netbsd/man4/man4.x86/fwhrng.4 4.html | 44 - static/netbsd/man4/man4.x86/hpet.4 4.html | 54 - static/netbsd/man4/man4.x86/ichlpcib.4 3.html | 95 - static/netbsd/man4/man4.x86/imcsmb.4 3.html | 113 - static/netbsd/man4/man4.x86/lpt.4 4.html | 75 - static/netbsd/man4/man4.x86/mem.4 4.html | 49 - static/netbsd/man4/man4.x86/odcm.4 4.html | 59 - static/netbsd/man4/man4.x86/powernow.4 4.html | 57 - static/netbsd/man4/man4.x86/soekrisgpio.4 4.html | 64 - static/netbsd/man4/man4.x86/tco.4 4.html | 57 - static/netbsd/man4/man4.x86/viac7temp.4 4.html | 41 - static/netbsd/man4/mbe.4 4.html | 58 - static/netbsd/man4/mc.4 4.html | 78 - static/netbsd/man4/mca.4 4.html | 102 - static/netbsd/man4/mcclock.4 4.html | 67 - static/netbsd/man4/mcd.4 4.html | 59 - static/netbsd/man4/mcommphy.4 4.html | 46 - static/netbsd/man4/mcp3kadc.4 4.html | 139 - static/netbsd/man4/mcp48x1dac.4 4.html | 100 - static/netbsd/man4/mcp980x.4 4.html | 72 - static/netbsd/man4/mcpgpio.4 4.html | 99 - static/netbsd/man4/mcx.4 3.html | 66 - static/netbsd/man4/md.4 4.html | 53 - static/netbsd/man4/mfb.4 4.html | 40 - static/netbsd/man4/mfi.4 4.html | 72 - static/netbsd/man4/mfii.4 4.html | 86 - static/netbsd/man4/mhzc.4 4.html | 44 - static/netbsd/man4/micphy.4 4.html | 39 - static/netbsd/man4/midi.4 3.html | 454 - static/netbsd/man4/mii.4 3.html | 144 - static/netbsd/man4/mk48txx.4 4.html | 146 - static/netbsd/man4/mlx.4 4.html | 87 - static/netbsd/man4/mly.4 4.html | 365 - static/netbsd/man4/mos.4 4.html | 101 - static/netbsd/man4/mpii.4 4.html | 90 - static/netbsd/man4/mpl115a.4 4.html | 56 - static/netbsd/man4/mpls.4 3.html | 261 - static/netbsd/man4/mpt.4 4.html | 65 - static/netbsd/man4/mpu.4 4.html | 57 - static/netbsd/man4/msm6242b.4 4.html | 56 - static/netbsd/man4/mtd.4 4.html | 61 - static/netbsd/man4/mtio.4 3.html | 120 - static/netbsd/man4/mue.4 4.html | 89 - static/netbsd/man4/multicast.4 3.html | 717 -- static/netbsd/man4/mvsata.4 4.html | 113 - static/netbsd/man4/nadb.4 4.html | 45 - static/netbsd/man4/nca.4 4.html | 49 - static/netbsd/man4/ncm.4 4.html | 60 - static/netbsd/man4/nct.4 4.html | 62 - static/netbsd/man4/ne.4 4.html | 133 - static/netbsd/man4/neo.4 4.html | 57 - static/netbsd/man4/netintro.4 3.html | 279 - static/netbsd/man4/nfe.4 4.html | 78 - static/netbsd/man4/nfsmb.4 4.html | 45 - static/netbsd/man4/njata.4 4.html | 73 - static/netbsd/man4/njs.4 4.html | 62 - static/netbsd/man4/npflog.4 4.html | 78 - static/netbsd/man4/nsclpcsio.4 4.html | 149 - static/netbsd/man4/nside.4 4.html | 40 - static/netbsd/man4/nsphy.4 4.html | 36 - static/netbsd/man4/nsphyter.4 4.html | 38 - static/netbsd/man4/ntwoc.4 3.html | 148 - static/netbsd/man4/null.4 4.html | 38 - static/netbsd/man4/nvme.4 3.html | 117 - static/netbsd/man4/nvmm.4 4.html | 51 - static/netbsd/man4/oak.4 4.html | 36 - static/netbsd/man4/oboe.4 4.html | 48 - static/netbsd/man4/ofisa.4 4.html | 106 - static/netbsd/man4/ohci.4 4.html | 48 - static/netbsd/man4/onewire.4 4.html | 85 - static/netbsd/man4/oosiop.4 3.html | 64 - static/netbsd/man4/opl.4 4.html | 75 - static/netbsd/man4/optiide.4 4.html | 49 - static/netbsd/man4/options.4 3.html | 2009 ----- static/netbsd/man4/osiop.4 4.html | 88 - static/netbsd/man4/otus.4 3.html | 175 - static/netbsd/man4/owtemp.4 4.html | 56 - static/netbsd/man4/pad.4 4.html | 74 - static/netbsd/man4/pas.4 4.html | 36 - static/netbsd/man4/pcdisplay.4 4.html | 52 - static/netbsd/man4/pcf8563rtc.4 4.html | 48 - static/netbsd/man4/pchtemp.4 4.html | 48 - static/netbsd/man4/pci.4 3.html | 567 -- static/netbsd/man4/pciback.4 3.html | 90 - static/netbsd/man4/pcic.4 4.html | 65 - static/netbsd/man4/pciide.4 3.html | 99 - static/netbsd/man4/pckbc.4 4.html | 51 - static/netbsd/man4/pckbd.4 4.html | 66 - static/netbsd/man4/pcmcia.4 4.html | 216 - static/netbsd/man4/pcmcom.4 4.html | 41 - static/netbsd/man4/pcn.4 4.html | 66 - static/netbsd/man4/pcppi.4 4.html | 60 - static/netbsd/man4/pcscp.4 3.html | 52 - static/netbsd/man4/pcweasel.4 3.html | 83 - static/netbsd/man4/pdcide.4 3.html | 53 - static/netbsd/man4/pdcsata.4 4.html | 47 - static/netbsd/man4/piixide.4 4.html | 51 - static/netbsd/man4/piixpcib.4 4.html | 65 - static/netbsd/man4/piixpm.4 4.html | 67 - static/netbsd/man4/pim.4 3.html | 179 - static/netbsd/man4/plip.4 4.html | 261 - static/netbsd/man4/pm3fb.4 4.html | 50 - static/netbsd/man4/pms.4 3.html | 246 - static/netbsd/man4/pmu.4 4.html | 81 - static/netbsd/man4/pnaphy.4 4.html | 43 - static/netbsd/man4/podulebus.4 4.html | 126 - static/netbsd/man4/ppbus.4 4.html | 384 - static/netbsd/man4/ppi.4 4.html | 61 - static/netbsd/man4/ppp.4 4.html | 81 - static/netbsd/man4/pppoe.4 3.html | 249 - static/netbsd/man4/pseye.4 4.html | 58 - static/netbsd/man4/ptcd.4 4.html | 61 - static/netbsd/man4/ptm.4 4.html | 78 - static/netbsd/man4/pty.4 3.html | 183 - static/netbsd/man4/puc.4 4.html | 388 - static/netbsd/man4/pud.4 4.html | 49 - static/netbsd/man4/puffs.4 4.html | 59 - static/netbsd/man4/pv.4 3.html | 36 - static/netbsd/man4/pwdog.4 4.html | 53 - static/netbsd/man4/px.4 4.html | 43 - static/netbsd/man4/pxagpio.4 4.html | 56 - static/netbsd/man4/pxaip.4 4.html | 92 - static/netbsd/man4/pxg.4 4.html | 44 - static/netbsd/man4/qat.4 4.html | 68 - static/netbsd/man4/qe.4 4.html | 53 - static/netbsd/man4/qec.4 4.html | 48 - static/netbsd/man4/qemufwcfg.4 4.html | 53 - static/netbsd/man4/qsphy.4 4.html | 36 - static/netbsd/man4/r128fb.4 4.html | 49 - static/netbsd/man4/radeonfb.4 4.html | 106 - static/netbsd/man4/radio.4 4.html | 167 - static/netbsd/man4/raid.4 3.html | 374 - static/netbsd/man4/ral.4 3.html | 325 - static/netbsd/man4/ray.4 4.html | 101 - static/netbsd/man4/rcons.4 4.html | 51 - static/netbsd/man4/rdcphy.4 4.html | 37 - static/netbsd/man4/re.4 3.html | 156 - static/netbsd/man4/rge.4 4.html | 74 - static/netbsd/man4/rgephy.4 4.html | 37 - static/netbsd/man4/rlphy.4 4.html | 38 - static/netbsd/man4/rnd.4 3.html | 547 -- static/netbsd/man4/route.4 3.html | 337 - static/netbsd/man4/rs5c372rtc.4 4.html | 47 - static/netbsd/man4/rt.4 4.html | 65 - static/netbsd/man4/rtfps.4 4.html | 73 - static/netbsd/man4/rtii.4 4.html | 67 - static/netbsd/man4/rtk.4 4.html | 47 - static/netbsd/man4/rtsx.4 4.html | 61 - static/netbsd/man4/rtw.4 3.html | 272 - static/netbsd/man4/rtwn.4 4.html | 130 - static/netbsd/man4/rum.4 3.html | 315 - static/netbsd/man4/run.4 4.html | 280 - static/netbsd/man4/s390rtc.4 4.html | 47 - static/netbsd/man4/satalink.4 4.html | 44 - static/netbsd/man4/sb.4 4.html | 91 - static/netbsd/man4/sbp.4 4.html | 55 - static/netbsd/man4/sbt.4 4.html | 48 - static/netbsd/man4/sbus.4 4.html | 149 - static/netbsd/man4/sc.4 4.html | 99 - static/netbsd/man4/sc16is7xx.4 2.html | 305 - static/netbsd/man4/schide.4 4.html | 38 - static/netbsd/man4/scmd.4 4.html | 85 - static/netbsd/man4/scmdi2c.4 4.html | 84 - static/netbsd/man4/scmdspi.4 4.html | 76 - static/netbsd/man4/scsi.4 4.html | 217 - static/netbsd/man4/sctp.4 3.html | 297 - static/netbsd/man4/sd.4 3.html | 153 - static/netbsd/man4/sdhc.4 4.html | 52 - static/netbsd/man4/sdmmc.4 4.html | 60 - static/netbsd/man4/sdtemp.4 3.html | 80 - static/netbsd/man4/se.4 4.html | 65 - static/netbsd/man4/sea.4 4.html | 50 - static/netbsd/man4/sec.4 4.html | 37 - static/netbsd/man4/seeprom.4 4.html | 113 - static/netbsd/man4/sem.4 4.html | 44 - static/netbsd/man4/ses.4 4.html | 92 - static/netbsd/man4/sf.4 4.html | 64 - static/netbsd/man4/sf2r.4 4.html | 73 - static/netbsd/man4/sfb.4 4.html | 40 - static/netbsd/man4/sgp40mox.4 3.html | 100 - static/netbsd/man4/sgsmix.4 4.html | 40 - static/netbsd/man4/shb.4 3.html | 51 - static/netbsd/man4/shmif.4 4.html | 89 - static/netbsd/man4/shpcic.4 4.html | 46 - static/netbsd/man4/sht3xtemp.4 3.html | 122 - static/netbsd/man4/sht4xtemp.4 4.html | 88 - static/netbsd/man4/si.4 4.html | 141 - static/netbsd/man4/si70xxtemp.4 3.html | 98 - static/netbsd/man4/siisata.4 4.html | 77 - static/netbsd/man4/siop.4 4.html | 88 - static/netbsd/man4/sip.4 4.html | 57 - static/netbsd/man4/siside.4 4.html | 49 - static/netbsd/man4/sk.4 3.html | 203 - static/netbsd/man4/sl.4 4.html | 94 - static/netbsd/man4/slhci.4 4.html | 142 - static/netbsd/man4/slide.4 4.html | 49 - static/netbsd/man4/slurm.4 4.html | 52 - static/netbsd/man4/sm.4 4.html | 85 - static/netbsd/man4/smsc.4 4.html | 98 - static/netbsd/man4/smscmon.4 4.html | 115 - static/netbsd/man4/smscphy.4 4.html | 48 - static/netbsd/man4/smsh.4 4.html | 64 - static/netbsd/man4/sn.4 4.html | 106 - static/netbsd/man4/sony.4 4.html | 120 - static/netbsd/man4/spc.4 4.html | 59 - static/netbsd/man4/spdmem.4 4.html | 71 - static/netbsd/man4/speaker.4 3.html | 306 - static/netbsd/man4/spi.4 4.html | 128 - static/netbsd/man4/spif.4 4.html | 99 - static/netbsd/man4/sqphy.4 4.html | 38 - static/netbsd/man4/srt.4 3.html | 108 - static/netbsd/man4/ss.4 4.html | 57 - static/netbsd/man4/ssdfb.4 4.html | 128 - static/netbsd/man4/st.4 3.html | 351 - static/netbsd/man4/ste.4 4.html | 51 - static/netbsd/man4/stf.4 3.html | 190 - static/netbsd/man4/stge.4 4.html | 67 - static/netbsd/man4/sti.4 4.html | 276 - static/netbsd/man4/stpcide.4 4.html | 51 - static/netbsd/man4/stuirda.4 4.html | 67 - static/netbsd/man4/sv.4 4.html | 48 - static/netbsd/man4/svwsata.4 4.html | 44 - static/netbsd/man4/swsensor.4 4.html | 137 - static/netbsd/man4/swwdog.4 4.html | 61 - static/netbsd/man4/sysmon.4 4.html | 56 - static/netbsd/man4/tap.4 3.html | 138 - static/netbsd/man4/tc.4 4.html | 116 - static/netbsd/man4/tcds.4 4.html | 39 - static/netbsd/man4/tcic.4 4.html | 43 - static/netbsd/man4/tcom.4 4.html | 90 - static/netbsd/man4/tcp.4 3.html | 235 - static/netbsd/man4/tcu.4 4.html | 46 - static/netbsd/man4/tdvfb.4 4.html | 84 - static/netbsd/man4/tea5767radio.4 4.html | 65 - static/netbsd/man4/termios.4 4.html | 1035 --- static/netbsd/man4/tfb.4 4.html | 42 - static/netbsd/man4/thinkpad.4 4.html | 47 - static/netbsd/man4/ti.4 4.html | 151 - static/netbsd/man4/tl.4 4.html | 74 - static/netbsd/man4/tlp.4 4.html | 427 - static/netbsd/man4/tlphy.4 4.html | 37 - static/netbsd/man4/tm121temp.4 4.html | 52 - static/netbsd/man4/tpm.4 4.html | 56 - static/netbsd/man4/tprof.4 4.html | 50 - static/netbsd/man4/tps65217pmic.4 4.html | 80 - static/netbsd/man4/tqphy.4 4.html | 42 - static/netbsd/man4/tra.4 4.html | 59 - static/netbsd/man4/trm.4 4.html | 66 - static/netbsd/man4/tsllux.4 4.html | 93 - static/netbsd/man4/tty.4 2.html | 403 - static/netbsd/man4/tun.4 4.html | 174 - static/netbsd/man4/twa.4 4.html | 47 - static/netbsd/man4/twe.4 4.html | 43 - static/netbsd/man4/txp.4 4.html | 87 - static/netbsd/man4/u3g.4 4.html | 82 - static/netbsd/man4/ualea.4 4.html | 52 - static/netbsd/man4/uark.4 4.html | 61 - static/netbsd/man4/uatp.4 3.html | 151 - static/netbsd/man4/uaudio.4 4.html | 96 - static/netbsd/man4/uberry.4 4.html | 45 - static/netbsd/man4/ubsa.4 4.html | 73 - static/netbsd/man4/ubsec.4 4.html | 89 - static/netbsd/man4/ubt.4 4.html | 106 - static/netbsd/man4/uchcom.4 4.html | 61 - static/netbsd/man4/ucom.4 4.html | 101 - static/netbsd/man4/ucycom.4 3.html | 64 - static/netbsd/man4/udav.4 4.html | 76 - static/netbsd/man4/udl.4 4.html | 71 - static/netbsd/man4/udp.4 4.html | 112 - static/netbsd/man4/udsbr.4 4.html | 45 - static/netbsd/man4/uep.4 4.html | 49 - static/netbsd/man4/uftdi.4 4.html | 134 - static/netbsd/man4/ug.4 4.html | 157 - static/netbsd/man4/ugen.4 3.html | 331 - static/netbsd/man4/ugensa.4 4.html | 105 - static/netbsd/man4/uha.4 4.html | 52 - static/netbsd/man4/uhci.4 4.html | 44 - static/netbsd/man4/uhid.4 3.html | 131 - static/netbsd/man4/uhidev.4 3.html | 56 - static/netbsd/man4/uhmodem.4 3.html | 70 - static/netbsd/man4/uhso.4 4.html | 169 - static/netbsd/man4/uintuos.4 3.html | 52 - static/netbsd/man4/uipad.4 4.html | 63 - static/netbsd/man4/uipaq.4 4.html | 63 - static/netbsd/man4/uirda.4 4.html | 55 - static/netbsd/man4/uk.4 4.html | 69 - static/netbsd/man4/ukbd.4 4.html | 49 - static/netbsd/man4/ukphy.4 4.html | 41 - static/netbsd/man4/ukyopon.4 4.html | 111 - static/netbsd/man4/ulpt.4 4.html | 67 - static/netbsd/man4/umass.4 4.html | 89 - static/netbsd/man4/umb.4 4.html | 94 - static/netbsd/man4/umcpmio.4 4.html | 479 - static/netbsd/man4/umcs.4 4.html | 59 - static/netbsd/man4/umct.4 4.html | 64 - static/netbsd/man4/umidi.4 4.html | 129 - static/netbsd/man4/umodem.4 4.html | 54 - static/netbsd/man4/ums.4 4.html | 50 - static/netbsd/man4/unix.4 4.html | 214 - static/netbsd/man4/upgt.4 4.html | 165 - static/netbsd/man4/upl.4 4.html | 82 - static/netbsd/man4/uplcom.4 4.html | 84 - static/netbsd/man4/ure.4 4.html | 83 - static/netbsd/man4/url.4 4.html | 70 - static/netbsd/man4/urndis.4 4.html | 79 - static/netbsd/man4/urtw.4 4.html | 133 - static/netbsd/man4/urtwn.4 3.html | 222 - static/netbsd/man4/usb.4 4.html | 554 -- static/netbsd/man4/usbnet.4 3.html | 84 - static/netbsd/man4/userconf.4 4.html | 102 - static/netbsd/man4/uslsa.4 4.html | 79 - static/netbsd/man4/usmsc.4 4.html | 86 - static/netbsd/man4/usscanner.4 4.html | 58 - static/netbsd/man4/ustir.4 4.html | 62 - static/netbsd/man4/uthum.4 4.html | 54 - static/netbsd/man4/utoppy.4 4.html | 235 - static/netbsd/man4/uts.4 4.html | 50 - static/netbsd/man4/uvideo.4 4.html | 56 - static/netbsd/man4/uvisor.4 4.html | 49 - static/netbsd/man4/uvscom.4 4.html | 48 - static/netbsd/man4/uxrcom.4 4.html | 72 - static/netbsd/man4/vald.4 4.html | 63 - static/netbsd/man4/valz.4 4.html | 58 - static/netbsd/man4/veriexec.4 4.html | 248 - static/netbsd/man4/vether.4 4.html | 70 - static/netbsd/man4/vga.4 4.html | 131 - static/netbsd/man4/vge.4 4.html | 148 - static/netbsd/man4/viaenv.4 4.html | 106 - static/netbsd/man4/viaide.4 4.html | 70 - static/netbsd/man4/video.4 4.html | 215 - static/netbsd/man4/vio9p.4 4.html | 67 - static/netbsd/man4/viocon.4 4.html | 70 - static/netbsd/man4/viogpu.4 4.html | 53 - static/netbsd/man4/vioif.4 4.html | 51 - static/netbsd/man4/viomb.4 4.html | 70 - static/netbsd/man4/viornd.4 4.html | 57 - static/netbsd/man4/vioscsi.4 4.html | 59 - static/netbsd/man4/virt.4 4.html | 42 - static/netbsd/man4/virtio.4 4.html | 83 - static/netbsd/man4/virtio_mmio.4 4.html | 60 - static/netbsd/man4/vlan.4 4.html | 103 - static/netbsd/man4/vmmon.4 4.html | 38 - static/netbsd/man4/vmnet.4 4.html | 38 - static/netbsd/man4/vmt.4 4.html | 95 - static/netbsd/man4/vmx.4 4.html | 94 - static/netbsd/man4/vnd.4 4.html | 78 - static/netbsd/man4/voodoofb.4 4.html | 51 - static/netbsd/man4/vr.4 4.html | 56 - static/netbsd/man4/vte.4 4.html | 69 - static/netbsd/man4/wapbl.4 4.html | 146 - static/netbsd/man4/wb.4 4.html | 55 - static/netbsd/man4/wbsio.4 4.html | 64 - static/netbsd/man4/wd.4 4.html | 99 - static/netbsd/man4/wdc.4 4.html | 86 - static/netbsd/man4/wds.4 4.html | 53 - static/netbsd/man4/we.4 4.html | 147 - static/netbsd/man4/wg.4 4.html | 189 - static/netbsd/man4/wi.4 4.html | 167 - static/netbsd/man4/wm.4 4.html | 179 - static/netbsd/man4/wpi.4 4.html | 206 - static/netbsd/man4/wsbell.4 4.html | 85 - static/netbsd/man4/wscons.4 4.html | 260 - static/netbsd/man4/wsdisplay.4 3.html | 530 -- static/netbsd/man4/wsfont.4 4.html | 42 - static/netbsd/man4/wskbd.4 4.html | 354 - static/netbsd/man4/wsmouse.4 4.html | 146 - static/netbsd/man4/wsmux.4 4.html | 90 - static/netbsd/man4/wss.4 4.html | 61 - static/netbsd/man4/wt.4 4.html | 58 - static/netbsd/man4/wwanc.4 4.html | 85 - static/netbsd/man4/xbd.4 4.html | 73 - static/netbsd/man4/xbdback.4 4.html | 81 - static/netbsd/man4/xbox.4 4.html | 42 - static/netbsd/man4/xenbus.4 4.html | 68 - static/netbsd/man4/xennet.4 4.html | 83 - static/netbsd/man4/xge.4 4.html | 82 - static/netbsd/man4/xhci.4 4.html | 49 - static/netbsd/man4/xi.4 4.html | 77 - static/netbsd/man4/xirc.4 4.html | 44 - static/netbsd/man4/xpci.4 4.html | 64 - static/netbsd/man4/xvif.4 4.html | 74 - static/netbsd/man4/yds.4 4.html | 53 - static/netbsd/man4/ym.4 4.html | 157 - static/netbsd/man4/zero.4 4.html | 37 - static/netbsd/man4/zstty.4 4.html | 374 - static/netbsd/man4/zyd.4 4.html | 305 - static/netbsd/man8/MAKEDEV.8 4.html | 815 -- static/netbsd/man8/MAKEDEV.local.8 4.html | 92 - static/netbsd/man8/afterboot.8 4.html | 795 -- static/netbsd/man8/boot.8 4.html | 223 - static/netbsd/man8/compat_30.8 4.html | 145 - static/netbsd/man8/compat_bsdos.8 4.html | 93 - static/netbsd/man8/compat_freebsd.8 4.html | 258 - static/netbsd/man8/compat_linux.8 4.html | 161 - static/netbsd/man8/compat_netbsd32.8 4.html | 109 - static/netbsd/man8/compat_sunos.8 4.html | 92 - static/netbsd/man8/compat_ultrix.8 4.html | 106 - static/netbsd/man8/creds_msdos.8 4.html | 99 - static/netbsd/man8/diskless.8 4.html | 542 -- static/netbsd/man8/hpcboot.8 4.html | 133 - static/netbsd/man8/intro.8 4.html | 44 - static/netbsd/man8/man8.hpcarm/boot.8 3.html | 80 - static/netbsd/man8/man8.mac68k/boot.8 3.html | 88 - static/netbsd/man8/man8.macppc/boot.8 3.html | 296 - static/netbsd/man8/man8.macppc/ofwboot.8 3.html | 367 - static/netbsd/man8/man8.pmax/boot.8 2.html | 162 - static/netbsd/man8/man8.prep/boot.8 3.html | 87 - static/netbsd/man8/man8.sandpoint/altboot.8 3.html | 181 - static/netbsd/man8/man8.sgimips/boot.8 3.html | 114 - static/netbsd/man8/man8.sgimips/sgivol.8 3.html | 163 - static/netbsd/man8/man8.sparc/binstall.8 3.html | 84 - static/netbsd/man8/man8.sparc/boot.8 3.html | 214 - static/netbsd/man8/man8.sparc64/boot.8 3.html | 205 - static/netbsd/man8/man8.sun2/boot.8 3.html | 137 - static/netbsd/man8/man8.sun3/boot.8 3.html | 92 - static/netbsd/man8/man8.vax/boot.8 3.html | 190 - static/netbsd/man8/man8.vax/crash.8 2.html | 175 - static/netbsd/man8/man8.vax/drtest.8 3.html | 85 - static/netbsd/man8/man8.vax/format.8 3.html | 220 - static/netbsd/man8/man8.x68k/boot.8 3.html | 193 - static/netbsd/man8/man8.x68k/loadbsd.8 3.html | 130 - static/netbsd/man8/man8.x68k/newdisk.8 3.html | 80 - static/netbsd/man8/man8.x86/boot.8 3.html | 705 -- static/netbsd/man8/man8.x86/boot_console.8 3.html | 124 - static/netbsd/man8/man8.x86/dosboot.8 3.html | 111 - static/netbsd/man8/man8.x86/mbr.8 4.html | 154 - static/netbsd/man8/man8.x86/multiboot.8 4.html | 85 - static/netbsd/man8/man8.x86/pxeboot.8 4.html | 240 - static/netbsd/man8/nis.8 4.html | 214 - static/netbsd/man8/pam.8 4.html | 79 - static/netbsd/man8/rc.8 4.html | 292 - static/netbsd/man8/rc.subr.8 4.html | 575 -- static/netbsd/man8/rescue.8 4.html | 94 - static/netbsd/man8/veriexec.8 4.html | 176 - static/netbsd/man8/wizd.8 4.html | 78 - static/netbsd/man9/KERNEL_LOCK.9 3.html | 228 - static/netbsd/man9/accept_filter.9 3.html | 140 - static/netbsd/man9/accf_data.9 3.html | 68 - static/netbsd/man9/acct_process.9 3.html | 50 - static/netbsd/man9/autoconf.9 3.html | 385 - static/netbsd/man9/bcdtobin.9 3.html | 51 - static/netbsd/man9/bcopy.9 3.html | 58 - static/netbsd/man9/bufq.9 3.html | 211 - static/netbsd/man9/bus_space.9 3.html | 2110 ----- static/netbsd/man9/clock.9 3.html | 103 - static/netbsd/man9/cnmagic.9 3.html | 164 - static/netbsd/man9/condvar.9 3.html | 362 - static/netbsd/man9/cons.9 3.html | 137 - static/netbsd/man9/cprng.9 3.html | 218 - static/netbsd/man9/cpu_configure.9 3.html | 54 - static/netbsd/man9/cpu_dumpconf.9 3.html | 69 - static/netbsd/man9/cpu_need_resched.9 3.html | 80 - static/netbsd/man9/cpu_rootconf.9 3.html | 98 - static/netbsd/man9/csf.9 3.html | 295 - static/netbsd/man9/curproc.9 3.html | 100 - static/netbsd/man9/ddc.9 3.html | 96 - static/netbsd/man9/delay.9 3.html | 51 - static/netbsd/man9/dksubr.9 3.html | 300 - static/netbsd/man9/dopowerhooks.9 3.html | 51 - static/netbsd/man9/doshutdownhooks.9 3.html | 53 - static/netbsd/man9/driver.9 3.html | 249 - static/netbsd/man9/errno.9 3.html | 101 - static/netbsd/man9/evcnt.9 3.html | 257 - static/netbsd/man9/fileassoc.9 3.html | 338 - static/netbsd/man9/firmload.9 3.html | 151 - static/netbsd/man9/flash.9 3.html | 75 - static/netbsd/man9/fstrans.9 3.html | 307 - static/netbsd/man9/genfs.9 3.html | 137 - static/netbsd/man9/genfs_can_access.9 3.html | 100 - static/netbsd/man9/hardclock.9 3.html | 59 - static/netbsd/man9/heartbeat.9 3.html | 131 - static/netbsd/man9/hz.9 3.html | 79 - static/netbsd/man9/ieee80211_proto.9 3.html | 80 - static/netbsd/man9/ieee80211_radiotap.9 3.html | 233 - static/netbsd/man9/imax.9 3.html | 83 - static/netbsd/man9/inittodr.9 3.html | 74 - static/netbsd/man9/interrupt_distribute.9 3.html | 44 - static/netbsd/man9/intro.9 3.html | 347 - static/netbsd/man9/ioctl.9 3.html | 289 - static/netbsd/man9/kcopy.9 3.html | 54 - static/netbsd/man9/kcpuset.9 3.html | 339 - static/netbsd/man9/kmem.9 3.html | 297 - static/netbsd/man9/localcount.9 3.html | 170 - static/netbsd/man9/lock.9 3.html | 49 - static/netbsd/man9/locking.9 3.html | 333 - static/netbsd/man9/ltsleep.9 3.html | 203 - static/netbsd/man9/man9.x86/rdmsr.9 3.html | 87 - static/netbsd/man9/man9.x86/tsc.9 3.html | 102 - static/netbsd/man9/memcmp.9 3.html | 55 - static/netbsd/man9/memset.9 3.html | 50 - static/netbsd/man9/microseq.9 3.html | 531 -- static/netbsd/man9/microtime.9 3.html | 121 - static/netbsd/man9/module.9 3.html | 539 -- static/netbsd/man9/namecache.9 3.html | 223 - static/netbsd/man9/nullop.9 3.html | 80 - static/netbsd/man9/optstr.9 3.html | 128 - static/netbsd/man9/panic.9 3.html | 91 - static/netbsd/man9/pci_configure_bus.9 3.html | 256 - static/netbsd/man9/pci_intr.9 3.html | 184 - static/netbsd/man9/pci_msi.9 3.html | 296 - static/netbsd/man9/pckbport.9 3.html | 319 - static/netbsd/man9/pcq.9 3.html | 162 - static/netbsd/man9/pfil.9 3.html | 246 - static/netbsd/man9/physio.9 3.html | 93 - static/netbsd/man9/pmatch.9 3.html | 59 - static/netbsd/man9/pmf.9 3.html | 320 - static/netbsd/man9/proc_find.9 3.html | 59 - static/netbsd/man9/pserialize.9 3.html | 185 - static/netbsd/man9/pslist.9 3.html | 386 - static/netbsd/man9/ras.9 3.html | 121 - static/netbsd/man9/roundup.9 3.html | 100 - static/netbsd/man9/rwlock.9 3.html | 256 - static/netbsd/man9/scanc.9 3.html | 55 - static/netbsd/man9/sched_4bsd.9 3.html | 103 - static/netbsd/man9/secmodel_extensions.9 3.html | 103 - static/netbsd/man9/signal.9 3.html | 482 - static/netbsd/man9/sockopt.9 3.html | 157 - static/netbsd/man9/strlist.9 3.html | 212 - static/netbsd/man9/tc.9 3.html | 185 - static/netbsd/man9/tcp_congctl.9 3.html | 87 - static/netbsd/man9/ucom.9 3.html | 204 - static/netbsd/man9/usbd_status.9 3.html | 97 - static/netbsd/man9/usbnet.9 3.html | 669 -- static/netbsd/man9/uvm.9 3.html | 580 -- static/netbsd/man9/uvm_hotplug.9 3.html | 443 - static/netbsd/man9/uvm_map.9 3.html | 318 - static/netbsd/man9/vattr.9 3.html | 98 - static/netbsd/man9/vfs.9 3.html | 37 - static/netbsd/man9/vfsops.9 3.html | 461 - static/netbsd/man9/video.9 3.html | 182 - static/netbsd/man9/vnodeops.9 3.html | 1441 --- static/netbsd/man9/wapbl.9 3.html | 424 - static/netbsd/man9/wsbell.9 3.html | 103 - 2607 files changed, 387934 deletions(-) delete mode 100644 static/freebsd/man1/builtin.1 3.html delete mode 100644 static/freebsd/man1/intro.1 3.html delete mode 100644 static/freebsd/man3/ATOMIC_VAR_INIT.3 3.html delete mode 100644 static/freebsd/man3/CMSG_DATA.3 3.html delete mode 100644 static/freebsd/man3/Q_FRAWMASK.3 3.html delete mode 100644 static/freebsd/man3/Q_IFRAWMASK.3 3.html delete mode 100644 static/freebsd/man3/Q_INI.3 3.html delete mode 100644 static/freebsd/man3/Q_IRAWMASK.3 3.html delete mode 100644 static/freebsd/man3/Q_QABS.3 4.html delete mode 100644 static/freebsd/man3/Q_QADDI.3 3.html delete mode 100644 static/freebsd/man3/Q_QADDQ.3 3.html delete mode 100644 static/freebsd/man3/Q_SIGNED.3 3.html delete mode 100644 static/freebsd/man3/Q_SIGNSHFT.3 3.html delete mode 100644 static/freebsd/man3/alloca.3 3.html delete mode 100644 static/freebsd/man3/arb.3 3.html delete mode 100644 static/freebsd/man3/assert.3 3.html delete mode 100644 static/freebsd/man3/bitstring.3 3.html delete mode 100644 static/freebsd/man3/end.3 4.html delete mode 100644 static/freebsd/man3/fpgetround.3 4.html delete mode 100644 static/freebsd/man3/intro.3 3.html delete mode 100644 static/freebsd/man3/makedev.3 3.html delete mode 100644 static/freebsd/man3/offsetof.3 4.html delete mode 100644 static/freebsd/man3/pthread.3 3.html delete mode 100644 static/freebsd/man3/pthread_affinity_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_atfork.3 3.html delete mode 100644 static/freebsd/man3/pthread_attr.3 3.html delete mode 100644 static/freebsd/man3/pthread_attr_affinity_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_attr_get_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_attr_setcreatesuspend_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_barrier_destroy.3 3.html delete mode 100644 static/freebsd/man3/pthread_barrierattr.3 3.html delete mode 100644 static/freebsd/man3/pthread_cancel.3 3.html delete mode 100644 static/freebsd/man3/pthread_cleanup_pop.3 4.html delete mode 100644 static/freebsd/man3/pthread_cleanup_push.3 4.html delete mode 100644 static/freebsd/man3/pthread_cond_broadcast.3 4.html delete mode 100644 static/freebsd/man3/pthread_cond_destroy.3 4.html delete mode 100644 static/freebsd/man3/pthread_cond_init.3 3.html delete mode 100644 static/freebsd/man3/pthread_cond_signal.3 4.html delete mode 100644 static/freebsd/man3/pthread_cond_timedwait.3 3.html delete mode 100644 static/freebsd/man3/pthread_cond_wait.3 3.html delete mode 100644 static/freebsd/man3/pthread_condattr.3 3.html delete mode 100644 static/freebsd/man3/pthread_create.3 3.html delete mode 100644 static/freebsd/man3/pthread_detach.3 3.html delete mode 100644 static/freebsd/man3/pthread_equal.3 4.html delete mode 100644 static/freebsd/man3/pthread_exit.3 3.html delete mode 100644 static/freebsd/man3/pthread_getconcurrency.3 3.html delete mode 100644 static/freebsd/man3/pthread_getcpuclockid.3 4.html delete mode 100644 static/freebsd/man3/pthread_getspecific.3 3.html delete mode 100644 static/freebsd/man3/pthread_getthreadid_np.3 4.html delete mode 100644 static/freebsd/man3/pthread_join.3 3.html delete mode 100644 static/freebsd/man3/pthread_key_create.3 3.html delete mode 100644 static/freebsd/man3/pthread_key_delete.3 3.html delete mode 100644 static/freebsd/man3/pthread_kill.3 4.html delete mode 100644 static/freebsd/man3/pthread_main_np.3 4.html delete mode 100644 static/freebsd/man3/pthread_multi_np.3 4.html delete mode 100644 static/freebsd/man3/pthread_mutex_consistent.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutex_destroy.3 4.html delete mode 100644 static/freebsd/man3/pthread_mutex_init.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutex_lock.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutex_timedlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutex_trylock.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutex_unlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutexattr.3 3.html delete mode 100644 static/freebsd/man3/pthread_mutexattr_getkind_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_once.3 3.html delete mode 100644 static/freebsd/man3/pthread_resume_all_np.3 4.html delete mode 100644 static/freebsd/man3/pthread_resume_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlock_destroy.3 4.html delete mode 100644 static/freebsd/man3/pthread_rwlock_init.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlock_rdlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlock_timedrdlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlock_timedwrlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlock_unlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlock_wrlock.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlockattr_destroy.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlockattr_getpshared.3 3.html delete mode 100644 static/freebsd/man3/pthread_rwlockattr_init.3 4.html delete mode 100644 static/freebsd/man3/pthread_rwlockattr_setpshared.3 3.html delete mode 100644 static/freebsd/man3/pthread_schedparam.3 3.html delete mode 100644 static/freebsd/man3/pthread_self.3 4.html delete mode 100644 static/freebsd/man3/pthread_set_name_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_setspecific.3 3.html delete mode 100644 static/freebsd/man3/pthread_sigmask.3 3.html delete mode 100644 static/freebsd/man3/pthread_signals_block_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_sigqueue.3 3.html delete mode 100644 static/freebsd/man3/pthread_spin_init.3 3.html delete mode 100644 static/freebsd/man3/pthread_spin_lock.3 3.html delete mode 100644 static/freebsd/man3/pthread_suspend_all_np.3 4.html delete mode 100644 static/freebsd/man3/pthread_suspend_np.3 3.html delete mode 100644 static/freebsd/man3/pthread_testcancel.3 3.html delete mode 100644 static/freebsd/man3/pthread_yield.3 4.html delete mode 100644 static/freebsd/man3/qmath.3 3.html delete mode 100644 static/freebsd/man3/queue.3 3.html delete mode 100644 static/freebsd/man3/sigevent.3 3.html delete mode 100644 static/freebsd/man3/siginfo.3 3.html delete mode 100644 static/freebsd/man3/snl.3 3.html delete mode 100644 static/freebsd/man3/stats.3 3.html delete mode 100644 static/freebsd/man3/stdarg.3 3.html delete mode 100644 static/freebsd/man3/stdbit.3 4.html delete mode 100644 static/freebsd/man3/stdckdint.3 3.html delete mode 100644 static/freebsd/man3/sysexits.3 3.html delete mode 100644 static/freebsd/man3/tgmath.3 3.html delete mode 100644 static/freebsd/man3/timeradd.3 4.html delete mode 100644 static/freebsd/man3/tree.3 3.html delete mode 100644 static/freebsd/man3lua/intro.3lua 4.html delete mode 100644 static/freebsd/man4/aac.4 3.html delete mode 100644 static/freebsd/man4/aacraid.4 3.html delete mode 100644 static/freebsd/man4/acpi.4 3.html delete mode 100644 static/freebsd/man4/acpi_asus.4 4.html delete mode 100644 static/freebsd/man4/acpi_asus_wmi.4 3.html delete mode 100644 static/freebsd/man4/acpi_battery.4 3.html delete mode 100644 static/freebsd/man4/acpi_dock.4 4.html delete mode 100644 static/freebsd/man4/acpi_fujitsu.4 3.html delete mode 100644 static/freebsd/man4/acpi_ged.4 4.html delete mode 100644 static/freebsd/man4/acpi_hp.4 3.html delete mode 100644 static/freebsd/man4/acpi_ibm.4 3.html delete mode 100644 static/freebsd/man4/acpi_panasonic.4 3.html delete mode 100644 static/freebsd/man4/acpi_rapidstart.4 3.html delete mode 100644 static/freebsd/man4/acpi_sony.4 4.html delete mode 100644 static/freebsd/man4/acpi_thermal.4 3.html delete mode 100644 static/freebsd/man4/acpi_toshiba.4 3.html delete mode 100644 static/freebsd/man4/acpi_video.4 3.html delete mode 100644 static/freebsd/man4/acpi_wmi.4 3.html delete mode 100644 static/freebsd/man4/ada.4 3.html delete mode 100644 static/freebsd/man4/adm6996fc.4 4.html delete mode 100644 static/freebsd/man4/ads111x.4 3.html delete mode 100644 static/freebsd/man4/ae.4 3.html delete mode 100644 static/freebsd/man4/aesni.4 3.html delete mode 100644 static/freebsd/man4/age.4 3.html delete mode 100644 static/freebsd/man4/agp.4 3.html delete mode 100644 static/freebsd/man4/ahc.4 3.html delete mode 100644 static/freebsd/man4/ahci.4 3.html delete mode 100644 static/freebsd/man4/ahd.4 3.html delete mode 100644 static/freebsd/man4/aibs.4 3.html delete mode 100644 static/freebsd/man4/aio.4 3.html delete mode 100644 static/freebsd/man4/alc.4 3.html delete mode 100644 static/freebsd/man4/ale.4 3.html delete mode 100644 static/freebsd/man4/alpm.4 4.html delete mode 100644 static/freebsd/man4/altq.4 3.html delete mode 100644 static/freebsd/man4/amdpm.4 4.html delete mode 100644 static/freebsd/man4/amdsbwd.4 4.html delete mode 100644 static/freebsd/man4/amdsmb.4 4.html delete mode 100644 static/freebsd/man4/amdsmn.4 4.html delete mode 100644 static/freebsd/man4/amdtemp.4 3.html delete mode 100644 static/freebsd/man4/aout.4 3.html delete mode 100644 static/freebsd/man4/apic.4 3.html delete mode 100644 static/freebsd/man4/appleir.4 3.html delete mode 100644 static/freebsd/man4/aq.4 4.html delete mode 100644 static/freebsd/man4/arcmsr.4 3.html delete mode 100644 static/freebsd/man4/arswitch.4 3.html delete mode 100644 static/freebsd/man4/asmc.4 3.html delete mode 100644 static/freebsd/man4/at45d.4 3.html delete mode 100644 static/freebsd/man4/ata.4 3.html delete mode 100644 static/freebsd/man4/ath.4 3.html delete mode 100644 static/freebsd/man4/ath10k.4 3.html delete mode 100644 static/freebsd/man4/ath_hal.4 3.html delete mode 100644 static/freebsd/man4/atkbd.4 3.html delete mode 100644 static/freebsd/man4/atkbdc.4 3.html delete mode 100644 static/freebsd/man4/atopcase.4 4.html delete mode 100644 static/freebsd/man4/atp.4 3.html delete mode 100644 static/freebsd/man4/atrtc.4 4.html delete mode 100644 static/freebsd/man4/attimer.4 3.html delete mode 100644 static/freebsd/man4/audit.4 3.html delete mode 100644 static/freebsd/man4/auditpipe.4 3.html delete mode 100644 static/freebsd/man4/aue.4 3.html delete mode 100644 static/freebsd/man4/autofs.4 3.html delete mode 100644 static/freebsd/man4/aw_gpio.4 4.html delete mode 100644 static/freebsd/man4/aw_mmc.4 4.html delete mode 100644 static/freebsd/man4/aw_rtc.4 4.html delete mode 100644 static/freebsd/man4/aw_sid.4 4.html delete mode 100644 static/freebsd/man4/aw_spi.4 4.html delete mode 100644 static/freebsd/man4/aw_syscon.4 4.html delete mode 100644 static/freebsd/man4/axe.4 3.html delete mode 100644 static/freebsd/man4/axge.4 3.html delete mode 100644 static/freebsd/man4/axp.4 3.html delete mode 100644 static/freebsd/man4/bce.4 3.html delete mode 100644 static/freebsd/man4/bcm5974.4 4.html delete mode 100644 static/freebsd/man4/bcma.4 4.html delete mode 100644 static/freebsd/man4/bfe.4 3.html delete mode 100644 static/freebsd/man4/bge.4 3.html delete mode 100644 static/freebsd/man4/bhnd.4 4.html delete mode 100644 static/freebsd/man4/bhnd_chipc.4 3.html delete mode 100644 static/freebsd/man4/bhnd_pmu.4 4.html delete mode 100644 static/freebsd/man4/bhndb.4 4.html delete mode 100644 static/freebsd/man4/bhndb_pci.4 3.html delete mode 100644 static/freebsd/man4/bhyve.4 4.html delete mode 100644 static/freebsd/man4/blackhole.4 3.html delete mode 100644 static/freebsd/man4/bnxt.4 3.html delete mode 100644 static/freebsd/man4/bnxt_re.4 3.html delete mode 100644 static/freebsd/man4/boottrace.4 3.html delete mode 100644 static/freebsd/man4/bpf.4 3.html delete mode 100644 static/freebsd/man4/bridge.4 3.html delete mode 100644 static/freebsd/man4/bwi.4 3.html delete mode 100644 static/freebsd/man4/bwn.4 3.html delete mode 100644 static/freebsd/man4/bxe.4 3.html delete mode 100644 static/freebsd/man4/bytgpio.4 3.html delete mode 100644 static/freebsd/man4/capsicum.4 3.html delete mode 100644 static/freebsd/man4/cardbus.4 4.html delete mode 100644 static/freebsd/man4/carp.4 3.html delete mode 100644 static/freebsd/man4/cas.4 3.html delete mode 100644 static/freebsd/man4/cc_cdg.4 3.html delete mode 100644 static/freebsd/man4/cc_chd.4 3.html delete mode 100644 static/freebsd/man4/cc_cubic.4 3.html delete mode 100644 static/freebsd/man4/cc_dctcp.4 3.html delete mode 100644 static/freebsd/man4/cc_hd.4 3.html delete mode 100644 static/freebsd/man4/cc_htcp.4 3.html delete mode 100644 static/freebsd/man4/cc_newreno.4 3.html delete mode 100644 static/freebsd/man4/cc_vegas.4 3.html delete mode 100644 static/freebsd/man4/ccd.4 3.html delete mode 100644 static/freebsd/man4/ccr.4 3.html delete mode 100644 static/freebsd/man4/cd.4 3.html delete mode 100644 static/freebsd/man4/cd9660.4 4.html delete mode 100644 static/freebsd/man4/cdce.4 3.html delete mode 100644 static/freebsd/man4/cdceem.4 3.html delete mode 100644 static/freebsd/man4/cfi.4 3.html delete mode 100644 static/freebsd/man4/cfiscsi.4 3.html delete mode 100644 static/freebsd/man4/cfumass.4 3.html delete mode 100644 static/freebsd/man4/cgem.4 3.html delete mode 100644 static/freebsd/man4/ch.4 3.html delete mode 100644 static/freebsd/man4/chromebook_platform.4 4.html delete mode 100644 static/freebsd/man4/chvgpio.4 3.html delete mode 100644 static/freebsd/man4/ciss.4 3.html delete mode 100644 static/freebsd/man4/coretemp.4 4.html delete mode 100644 static/freebsd/man4/cp2112.4 3.html delete mode 100644 static/freebsd/man4/cpuctl.4 3.html delete mode 100644 static/freebsd/man4/cpufreq.4 3.html delete mode 100644 static/freebsd/man4/crypto.4 3.html delete mode 100644 static/freebsd/man4/ctl.4 3.html delete mode 100644 static/freebsd/man4/cue.4 3.html delete mode 100644 static/freebsd/man4/cxgb.4 3.html delete mode 100644 static/freebsd/man4/cxgbe.4 3.html delete mode 100644 static/freebsd/man4/cxgbev.4 3.html delete mode 100644 static/freebsd/man4/cyapa.4 3.html delete mode 100644 static/freebsd/man4/da.4 3.html delete mode 100644 static/freebsd/man4/dc.4 3.html delete mode 100644 static/freebsd/man4/dcons.4 3.html delete mode 100644 static/freebsd/man4/dcons_crom.4 4.html delete mode 100644 static/freebsd/man4/ddb.4 3.html delete mode 100644 static/freebsd/man4/devctl.4 3.html delete mode 100644 static/freebsd/man4/devfs.4 3.html delete mode 100644 static/freebsd/man4/disc.4 3.html delete mode 100644 static/freebsd/man4/disk.4 3.html delete mode 100644 static/freebsd/man4/divert.4 3.html delete mode 100644 static/freebsd/man4/dpms.4 3.html delete mode 100644 static/freebsd/man4/ds1307.4 3.html delete mode 100644 static/freebsd/man4/ds3231.4 3.html delete mode 100644 static/freebsd/man4/dtrace_audit.4 3.html delete mode 100644 static/freebsd/man4/dtrace_callout_execute.4 3.html delete mode 100644 static/freebsd/man4/dtrace_cam.4 4.html delete mode 100644 static/freebsd/man4/dtrace_dtrace.4 3.html delete mode 100644 static/freebsd/man4/dtrace_fbt.4 3.html delete mode 100644 static/freebsd/man4/dtrace_io.4 3.html delete mode 100644 static/freebsd/man4/dtrace_ip.4 3.html delete mode 100644 static/freebsd/man4/dtrace_kinst.4 3.html delete mode 100644 static/freebsd/man4/dtrace_lockstat.4 3.html delete mode 100644 static/freebsd/man4/dtrace_pid.4 3.html delete mode 100644 static/freebsd/man4/dtrace_priv.4 4.html delete mode 100644 static/freebsd/man4/dtrace_proc.4 3.html delete mode 100644 static/freebsd/man4/dtrace_profile.4 3.html delete mode 100644 static/freebsd/man4/dtrace_sched.4 3.html delete mode 100644 static/freebsd/man4/dtrace_sctp.4 3.html delete mode 100644 static/freebsd/man4/dtrace_tcp.4 3.html delete mode 100644 static/freebsd/man4/dtrace_udp.4 3.html delete mode 100644 static/freebsd/man4/dtrace_udplite.4 3.html delete mode 100644 static/freebsd/man4/dtrace_vfs.4 3.html delete mode 100644 static/freebsd/man4/dummymbuf.4 3.html delete mode 100644 static/freebsd/man4/dummynet.4 3.html delete mode 100644 static/freebsd/man4/e6000sw.4 3.html delete mode 100644 static/freebsd/man4/e6060sw.4 3.html delete mode 100644 static/freebsd/man4/edsc.4 3.html delete mode 100644 static/freebsd/man4/efidev.4 3.html delete mode 100644 static/freebsd/man4/ehci.4 3.html delete mode 100644 static/freebsd/man4/em.4 3.html delete mode 100644 static/freebsd/man4/ena.4 3.html delete mode 100644 static/freebsd/man4/enc.4 3.html delete mode 100644 static/freebsd/man4/enic.4 4.html delete mode 100644 static/freebsd/man4/epair.4 3.html delete mode 100644 static/freebsd/man4/est.4 3.html delete mode 100644 static/freebsd/man4/et.4 3.html delete mode 100644 static/freebsd/man4/etherswitch.4 3.html delete mode 100644 static/freebsd/man4/eventtimers.4 3.html delete mode 100644 static/freebsd/man4/exca.4 4.html delete mode 100644 static/freebsd/man4/ext2fs.4 3.html delete mode 100644 static/freebsd/man4/fd.4 4.html delete mode 100644 static/freebsd/man4/fdc.4 3.html delete mode 100644 static/freebsd/man4/fdescfs.4 3.html delete mode 100644 static/freebsd/man4/fdt.4 3.html delete mode 100644 static/freebsd/man4/fdt_pinctrl.4 3.html delete mode 100644 static/freebsd/man4/fdtbus.4 3.html delete mode 100644 static/freebsd/man4/ffclock.4 3.html delete mode 100644 static/freebsd/man4/ffs.4 3.html delete mode 100644 static/freebsd/man4/filemon.4 3.html delete mode 100644 static/freebsd/man4/firewire.4 3.html delete mode 100644 static/freebsd/man4/ftgpio.4 4.html delete mode 100644 static/freebsd/man4/ftwd.4 3.html delete mode 100644 static/freebsd/man4/full.4 3.html delete mode 100644 static/freebsd/man4/fusefs.4 3.html delete mode 100644 static/freebsd/man4/fwe.4 3.html delete mode 100644 static/freebsd/man4/fwip.4 3.html delete mode 100644 static/freebsd/man4/fwohci.4 3.html delete mode 100644 static/freebsd/man4/fxp.4 3.html delete mode 100644 static/freebsd/man4/gdb.4 3.html delete mode 100644 static/freebsd/man4/gem.4 3.html delete mode 100644 static/freebsd/man4/genet.4 3.html delete mode 100644 static/freebsd/man4/genetlink.4 3.html delete mode 100644 static/freebsd/man4/geneve.4 3.html delete mode 100644 static/freebsd/man4/geom.4 3.html delete mode 100644 static/freebsd/man4/geom_linux_lvm.4 3.html delete mode 100644 static/freebsd/man4/geom_uzip.4 3.html delete mode 100644 static/freebsd/man4/geom_zero.4 3.html delete mode 100644 static/freebsd/man4/gif.4 3.html delete mode 100644 static/freebsd/man4/gpio.4 3.html delete mode 100644 static/freebsd/man4/gpioiic.4 3.html delete mode 100644 static/freebsd/man4/gpiokeys.4 3.html delete mode 100644 static/freebsd/man4/gpioled.4 3.html delete mode 100644 static/freebsd/man4/gpioths.4 3.html delete mode 100644 static/freebsd/man4/gre.4 3.html delete mode 100644 static/freebsd/man4/gve.4 3.html delete mode 100644 static/freebsd/man4/h_ertt.4 3.html delete mode 100644 static/freebsd/man4/hconf.4 3.html delete mode 100644 static/freebsd/man4/hcons.4 3.html delete mode 100644 static/freebsd/man4/hgame.4 3.html delete mode 100644 static/freebsd/man4/hidbus.4 3.html delete mode 100644 static/freebsd/man4/hidquirk.4 3.html delete mode 100644 static/freebsd/man4/hidraw.4 3.html delete mode 100644 static/freebsd/man4/hkbd.4 3.html delete mode 100644 static/freebsd/man4/hms.4 4.html delete mode 100644 static/freebsd/man4/hmt.4 3.html delete mode 100644 static/freebsd/man4/hpen.4 4.html delete mode 100644 static/freebsd/man4/hpet.4 3.html delete mode 100644 static/freebsd/man4/hpt27xx.4 3.html delete mode 100644 static/freebsd/man4/hptiop.4 3.html delete mode 100644 static/freebsd/man4/hptmv.4 3.html delete mode 100644 static/freebsd/man4/hptnr.4 4.html delete mode 100644 static/freebsd/man4/hptrr.4 3.html delete mode 100644 static/freebsd/man4/hsctrl.4 4.html delete mode 100644 static/freebsd/man4/htu21.4 3.html delete mode 100644 static/freebsd/man4/hv_kvp.4 3.html delete mode 100644 static/freebsd/man4/hv_netvsc.4 3.html delete mode 100644 static/freebsd/man4/hv_storvsc.4 3.html delete mode 100644 static/freebsd/man4/hv_utils.4 3.html delete mode 100644 static/freebsd/man4/hv_vmbus.4 3.html delete mode 100644 static/freebsd/man4/hv_vss.4 3.html delete mode 100644 static/freebsd/man4/hwpmc.4 3.html delete mode 100644 static/freebsd/man4/hwpstate_intel.4 3.html delete mode 100644 static/freebsd/man4/hwt.4 3.html delete mode 100644 static/freebsd/man4/i2ctinyusb.4 4.html delete mode 100644 static/freebsd/man4/iavf.4 3.html delete mode 100644 static/freebsd/man4/ice.4 3.html delete mode 100644 static/freebsd/man4/ichsmb.4 4.html delete mode 100644 static/freebsd/man4/ichwd.4 3.html delete mode 100644 static/freebsd/man4/icmp.4 3.html delete mode 100644 static/freebsd/man4/icmp6.4 3.html delete mode 100644 static/freebsd/man4/ida.4 3.html delete mode 100644 static/freebsd/man4/ietp.4 4.html delete mode 100644 static/freebsd/man4/if_ipsec.4 3.html delete mode 100644 static/freebsd/man4/if_ntb.4 4.html delete mode 100644 static/freebsd/man4/iflib.4 3.html delete mode 100644 static/freebsd/man4/ifmib.4 3.html delete mode 100644 static/freebsd/man4/ig4.4 3.html delete mode 100644 static/freebsd/man4/igc.4 3.html delete mode 100644 static/freebsd/man4/igmp.4 3.html delete mode 100644 static/freebsd/man4/iic.4 3.html delete mode 100644 static/freebsd/man4/iic_gpiomux.4 4.html delete mode 100644 static/freebsd/man4/iicbb.4 4.html delete mode 100644 static/freebsd/man4/iicbus.4 3.html delete mode 100644 static/freebsd/man4/iichid.4 3.html delete mode 100644 static/freebsd/man4/iicmux.4 3.html delete mode 100644 static/freebsd/man4/iicsmb.4 4.html delete mode 100644 static/freebsd/man4/imcsmb.4 3.html delete mode 100644 static/freebsd/man4/inet.4 3.html delete mode 100644 static/freebsd/man4/inet6.4 3.html delete mode 100644 static/freebsd/man4/intpm.4 4.html delete mode 100644 static/freebsd/man4/intro.4 3.html delete mode 100644 static/freebsd/man4/io.4 3.html delete mode 100644 static/freebsd/man4/ioat.4 4.html delete mode 100644 static/freebsd/man4/ip.4 3.html delete mode 100644 static/freebsd/man4/ip17x.4 4.html delete mode 100644 static/freebsd/man4/ip6.4 3.html delete mode 100644 static/freebsd/man4/ipfirewall.4 3.html delete mode 100644 static/freebsd/man4/ipheth.4 3.html delete mode 100644 static/freebsd/man4/ipmi.4 3.html delete mode 100644 static/freebsd/man4/ips.4 3.html delete mode 100644 static/freebsd/man4/ipsec.4 3.html delete mode 100644 static/freebsd/man4/ipw.4 4.html delete mode 100644 static/freebsd/man4/ipwfw.4 4.html delete mode 100644 static/freebsd/man4/irdma.4 3.html delete mode 100644 static/freebsd/man4/isci.4 4.html delete mode 100644 static/freebsd/man4/iscsi.4 3.html delete mode 100644 static/freebsd/man4/iser.4 3.html delete mode 100644 static/freebsd/man4/isl.4 3.html delete mode 100644 static/freebsd/man4/ismt.4 4.html delete mode 100644 static/freebsd/man4/isp.4 3.html delete mode 100644 static/freebsd/man4/ispfw.4 4.html delete mode 100644 static/freebsd/man4/itwd.4 4.html delete mode 100644 static/freebsd/man4/iwi.4 3.html delete mode 100644 static/freebsd/man4/iwifw.4 4.html delete mode 100644 static/freebsd/man4/iwlwifi.4 3.html delete mode 100644 static/freebsd/man4/iwlwififw.4 3.html delete mode 100644 static/freebsd/man4/iwm.4 4.html delete mode 100644 static/freebsd/man4/iwmfw.4 4.html delete mode 100644 static/freebsd/man4/iwn.4 4.html delete mode 100644 static/freebsd/man4/iwnfw.4 4.html delete mode 100644 static/freebsd/man4/iwx.4 3.html delete mode 100644 static/freebsd/man4/ix.4 3.html delete mode 100644 static/freebsd/man4/ixl.4 3.html delete mode 100644 static/freebsd/man4/jedec_dimm.4 3.html delete mode 100644 static/freebsd/man4/jme.4 3.html delete mode 100644 static/freebsd/man4/kbdmux.4 4.html delete mode 100644 static/freebsd/man4/kcov.4 3.html delete mode 100644 static/freebsd/man4/keyboard.4 3.html delete mode 100644 static/freebsd/man4/kld.4 3.html delete mode 100644 static/freebsd/man4/ksyms.4 3.html delete mode 100644 static/freebsd/man4/ksz8995ma.4 4.html delete mode 100644 static/freebsd/man4/ktls.4 3.html delete mode 100644 static/freebsd/man4/ktr.4 3.html delete mode 100644 static/freebsd/man4/kue.4 4.html delete mode 100644 static/freebsd/man4/kvmclock.4 3.html delete mode 100644 static/freebsd/man4/lagg.4 3.html delete mode 100644 static/freebsd/man4/led.4 4.html delete mode 100644 static/freebsd/man4/lge.4 3.html delete mode 100644 static/freebsd/man4/lindebugfs.4 3.html delete mode 100644 static/freebsd/man4/linprocfs.4 3.html delete mode 100644 static/freebsd/man4/linsysfs.4 4.html delete mode 100644 static/freebsd/man4/linux.4 3.html delete mode 100644 static/freebsd/man4/linuxkpi.4 4.html delete mode 100644 static/freebsd/man4/linuxkpi_wlan.4 3.html delete mode 100644 static/freebsd/man4/liquidio.4 3.html delete mode 100644 static/freebsd/man4/lm75.4 3.html delete mode 100644 static/freebsd/man4/lo.4 3.html delete mode 100644 static/freebsd/man4/lp.4 3.html delete mode 100644 static/freebsd/man4/lpbb.4 4.html delete mode 100644 static/freebsd/man4/lpt.4 3.html delete mode 100644 static/freebsd/man4/ltc430x.4 3.html delete mode 100644 static/freebsd/man4/mac.4 3.html delete mode 100644 static/freebsd/man4/mac_biba.4 3.html delete mode 100644 static/freebsd/man4/mac_bsdextended.4 3.html delete mode 100644 static/freebsd/man4/mac_ddb.4 3.html delete mode 100644 static/freebsd/man4/mac_do.4 3.html delete mode 100644 static/freebsd/man4/mac_ifoff.4 3.html delete mode 100644 static/freebsd/man4/mac_ipacl.4 3.html delete mode 100644 static/freebsd/man4/mac_lomac.4 3.html delete mode 100644 static/freebsd/man4/mac_mls.4 3.html delete mode 100644 static/freebsd/man4/mac_none.4 4.html delete mode 100644 static/freebsd/man4/mac_ntpd.4 3.html delete mode 100644 static/freebsd/man4/mac_partition.4 3.html delete mode 100644 static/freebsd/man4/mac_portacl.4 3.html delete mode 100644 static/freebsd/man4/mac_priority.4 3.html delete mode 100644 static/freebsd/man4/mac_seeotheruids.4 3.html delete mode 100644 static/freebsd/man4/mac_stub.4 3.html delete mode 100644 static/freebsd/man4/mac_test.4 3.html delete mode 100644 static/freebsd/man4/malo.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/armv8crypto.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/enetc.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/felix.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/rk_gpio.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/rk_grf.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/rk_grf_gpio.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/rk_i2c.4 3.html delete mode 100644 static/freebsd/man4/man4.aarch64/rk_pinctrl.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/am335x_dmtpps.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/ar40xx.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/bcm283x_pwm.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/devcfg.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/dwcotg.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/imx6_ahci.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/imx6_snvs.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/imx_spi.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/imx_wdog.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/mge.4 3.html delete mode 100644 static/freebsd/man4/man4.arm/ti_adc.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/CPU_ELAN.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/apm.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/glxiic.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/glxsb.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/longrun.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/npx.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/pae.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/pbio.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/pnp.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/pnpbios.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/sbni.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/smapi.4 3.html delete mode 100644 static/freebsd/man4/man4.i386/vpd.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/abtn.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/adb.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/akbd.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/ams.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/cuda.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/dtsec.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/llan.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/ofw_console.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/pmu.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/powermac_nvram.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/smu.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/snd_ai2s.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/snd_davbus.4 3.html delete mode 100644 static/freebsd/man4/man4.powerpc/tsec.4 3.html delete mode 100644 static/freebsd/man4/max44009.4 4.html delete mode 100644 static/freebsd/man4/mca.4 3.html delete mode 100644 static/freebsd/man4/md.4 3.html delete mode 100644 static/freebsd/man4/mdio.4 4.html delete mode 100644 static/freebsd/man4/me.4 4.html delete mode 100644 static/freebsd/man4/mem.4 3.html delete mode 100644 static/freebsd/man4/mfi.4 3.html delete mode 100644 static/freebsd/man4/mgb.4 4.html delete mode 100644 static/freebsd/man4/miibus.4 3.html delete mode 100644 static/freebsd/man4/mld.4 3.html delete mode 100644 static/freebsd/man4/mlx.4 3.html delete mode 100644 static/freebsd/man4/mlx4en.4 4.html delete mode 100644 static/freebsd/man4/mlx4ib.4 3.html delete mode 100644 static/freebsd/man4/mlx5en.4 3.html delete mode 100644 static/freebsd/man4/mlx5ib.4 3.html delete mode 100644 static/freebsd/man4/mlx5io.4 3.html delete mode 100644 static/freebsd/man4/mmc.4 4.html delete mode 100644 static/freebsd/man4/mmcsd.4 4.html delete mode 100644 static/freebsd/man4/mod_cc.4 3.html delete mode 100644 static/freebsd/man4/mos.4 3.html delete mode 100644 static/freebsd/man4/mouse.4 3.html delete mode 100644 static/freebsd/man4/mpi3mr.4 3.html delete mode 100644 static/freebsd/man4/mpr.4 3.html delete mode 100644 static/freebsd/man4/mps.4 3.html delete mode 100644 static/freebsd/man4/mpt.4 3.html delete mode 100644 static/freebsd/man4/mqueuefs.4 3.html delete mode 100644 static/freebsd/man4/mrsas.4 3.html delete mode 100644 static/freebsd/man4/msdosfs.4 3.html delete mode 100644 static/freebsd/man4/msk.4 3.html delete mode 100644 static/freebsd/man4/mt7915.4 3.html delete mode 100644 static/freebsd/man4/mt7921.4 3.html delete mode 100644 static/freebsd/man4/mtio.4 3.html delete mode 100644 static/freebsd/man4/mtkswitch.4 4.html delete mode 100644 static/freebsd/man4/mtw.4 4.html delete mode 100644 static/freebsd/man4/muge.4 4.html delete mode 100644 static/freebsd/man4/multicast.4 3.html delete mode 100644 static/freebsd/man4/mvs.4 3.html delete mode 100644 static/freebsd/man4/mwl.4 3.html delete mode 100644 static/freebsd/man4/mwlfw.4 4.html delete mode 100644 static/freebsd/man4/mx25l.4 4.html delete mode 100644 static/freebsd/man4/mxge.4 3.html delete mode 100644 static/freebsd/man4/my.4 4.html delete mode 100644 static/freebsd/man4/nctgpio.4 4.html delete mode 100644 static/freebsd/man4/ncthwm.4 4.html delete mode 100644 static/freebsd/man4/nda.4 3.html delete mode 100644 static/freebsd/man4/net80211.4 3.html delete mode 100644 static/freebsd/man4/netdump.4 3.html delete mode 100644 static/freebsd/man4/netfpga10g_nf10bmac.4 4.html delete mode 100644 static/freebsd/man4/netgdb.4 3.html delete mode 100644 static/freebsd/man4/netgraph.4 3.html delete mode 100644 static/freebsd/man4/netintro.4 3.html delete mode 100644 static/freebsd/man4/netlink.4 3.html delete mode 100644 static/freebsd/man4/netmap.4 3.html delete mode 100644 static/freebsd/man4/nfe.4 3.html delete mode 100644 static/freebsd/man4/nfslockd.4 4.html delete mode 100644 static/freebsd/man4/nfsmb.4 4.html delete mode 100644 static/freebsd/man4/ng_UI.4 4.html delete mode 100644 static/freebsd/man4/ng_async.4 3.html delete mode 100644 static/freebsd/man4/ng_bluetooth.4 3.html delete mode 100644 static/freebsd/man4/ng_bpf.4 3.html delete mode 100644 static/freebsd/man4/ng_bridge.4 3.html delete mode 100644 static/freebsd/man4/ng_btsocket.4 3.html delete mode 100644 static/freebsd/man4/ng_car.4 3.html delete mode 100644 static/freebsd/man4/ng_checksum.4 3.html delete mode 100644 static/freebsd/man4/ng_cisco.4 3.html delete mode 100644 static/freebsd/man4/ng_deflate.4 3.html delete mode 100644 static/freebsd/man4/ng_device.4 3.html delete mode 100644 static/freebsd/man4/ng_echo.4 4.html delete mode 100644 static/freebsd/man4/ng_eiface.4 3.html delete mode 100644 static/freebsd/man4/ng_etf.4 3.html delete mode 100644 static/freebsd/man4/ng_ether.4 3.html delete mode 100644 static/freebsd/man4/ng_ether_echo.4 4.html delete mode 100644 static/freebsd/man4/ng_frame_relay.4 3.html delete mode 100644 static/freebsd/man4/ng_gif.4 3.html delete mode 100644 static/freebsd/man4/ng_gif_demux.4 4.html delete mode 100644 static/freebsd/man4/ng_hci.4 3.html delete mode 100644 static/freebsd/man4/ng_hole.4 3.html delete mode 100644 static/freebsd/man4/ng_hub.4 3.html delete mode 100644 static/freebsd/man4/ng_iface.4 3.html delete mode 100644 static/freebsd/man4/ng_ip_input.4 4.html delete mode 100644 static/freebsd/man4/ng_ipfw.4 3.html delete mode 100644 static/freebsd/man4/ng_ksocket.4 3.html delete mode 100644 static/freebsd/man4/ng_l2cap.4 3.html delete mode 100644 static/freebsd/man4/ng_l2tp.4 3.html delete mode 100644 static/freebsd/man4/ng_lmi.4 3.html delete mode 100644 static/freebsd/man4/ng_macfilter.4 3.html delete mode 100644 static/freebsd/man4/ng_mppc.4 3.html delete mode 100644 static/freebsd/man4/ng_nat.4 3.html delete mode 100644 static/freebsd/man4/ng_netflow.4 3.html delete mode 100644 static/freebsd/man4/ng_one2many.4 3.html delete mode 100644 static/freebsd/man4/ng_patch.4 3.html delete mode 100644 static/freebsd/man4/ng_pipe.4 3.html delete mode 100644 static/freebsd/man4/ng_ppp.4 3.html delete mode 100644 static/freebsd/man4/ng_pppoe.4 3.html delete mode 100644 static/freebsd/man4/ng_pptpgre.4 3.html delete mode 100644 static/freebsd/man4/ng_pred1.4 3.html delete mode 100644 static/freebsd/man4/ng_rfc1490.4 3.html delete mode 100644 static/freebsd/man4/ng_socket.4 3.html delete mode 100644 static/freebsd/man4/ng_source.4 3.html delete mode 100644 static/freebsd/man4/ng_split.4 4.html delete mode 100644 static/freebsd/man4/ng_tag.4 3.html delete mode 100644 static/freebsd/man4/ng_tcpmss.4 3.html delete mode 100644 static/freebsd/man4/ng_tee.4 3.html delete mode 100644 static/freebsd/man4/ng_tty.4 3.html delete mode 100644 static/freebsd/man4/ng_ubt.4 3.html delete mode 100644 static/freebsd/man4/ng_vjc.4 3.html delete mode 100644 static/freebsd/man4/ng_vlan.4 3.html delete mode 100644 static/freebsd/man4/ng_vlan_rotate.4 3.html delete mode 100644 static/freebsd/man4/nge.4 3.html delete mode 100644 static/freebsd/man4/nlsysevent.4 3.html delete mode 100644 static/freebsd/man4/nmdm.4 4.html delete mode 100644 static/freebsd/man4/ntb.4 3.html delete mode 100644 static/freebsd/man4/ntb_hw_amd.4 3.html delete mode 100644 static/freebsd/man4/ntb_hw_intel.4 3.html delete mode 100644 static/freebsd/man4/ntb_hw_plx.4 3.html delete mode 100644 static/freebsd/man4/ntb_transport.4 3.html delete mode 100644 static/freebsd/man4/null.4 4.html delete mode 100644 static/freebsd/man4/nullfs.4 4.html delete mode 100644 static/freebsd/man4/numa.4 3.html delete mode 100644 static/freebsd/man4/nvd.4 3.html delete mode 100644 static/freebsd/man4/nvdimm.4 3.html delete mode 100644 static/freebsd/man4/nvme.4 3.html delete mode 100644 static/freebsd/man4/nvmf.4 3.html delete mode 100644 static/freebsd/man4/nvmf_che.4 3.html delete mode 100644 static/freebsd/man4/nvmf_tcp.4 3.html delete mode 100644 static/freebsd/man4/nvmft.4 3.html delete mode 100644 static/freebsd/man4/nvram.4 3.html delete mode 100644 static/freebsd/man4/oce.4 3.html delete mode 100644 static/freebsd/man4/ocs_fc.4 3.html delete mode 100644 static/freebsd/man4/ohci.4 4.html delete mode 100644 static/freebsd/man4/openfirm.4 3.html delete mode 100644 static/freebsd/man4/orm.4 4.html delete mode 100644 static/freebsd/man4/ossl.4 4.html delete mode 100644 static/freebsd/man4/otus.4 3.html delete mode 100644 static/freebsd/man4/otusfw.4 4.html delete mode 100644 static/freebsd/man4/ovpn.4 4.html delete mode 100644 static/freebsd/man4/ow.4 4.html delete mode 100644 static/freebsd/man4/ow_temp.4 3.html delete mode 100644 static/freebsd/man4/owc.4 3.html delete mode 100644 static/freebsd/man4/p9fs.4 3.html delete mode 100644 static/freebsd/man4/padlock.4 3.html delete mode 100644 static/freebsd/man4/pass.4 3.html delete mode 100644 static/freebsd/man4/pca954x.4 3.html delete mode 100644 static/freebsd/man4/pccbb.4 4.html delete mode 100644 static/freebsd/man4/pcf.4 4.html delete mode 100644 static/freebsd/man4/pcf8574.4 3.html delete mode 100644 static/freebsd/man4/pcf8591.4 4.html delete mode 100644 static/freebsd/man4/pchtherm.4 3.html delete mode 100644 static/freebsd/man4/pci.4 3.html delete mode 100644 static/freebsd/man4/pcib.4 3.html delete mode 100644 static/freebsd/man4/pcm.4 3.html delete mode 100644 static/freebsd/man4/pf.4 3.html delete mode 100644 static/freebsd/man4/pflog.4 3.html delete mode 100644 static/freebsd/man4/pflow.4 3.html delete mode 100644 static/freebsd/man4/pfsync.4 3.html delete mode 100644 static/freebsd/man4/pim.4 3.html delete mode 100644 static/freebsd/man4/pms.4 3.html delete mode 100644 static/freebsd/man4/polling.4 3.html delete mode 100644 static/freebsd/man4/ppbus.4 3.html delete mode 100644 static/freebsd/man4/ppc.4 3.html delete mode 100644 static/freebsd/man4/ppi.4 4.html delete mode 100644 static/freebsd/man4/procdesc.4 3.html delete mode 100644 static/freebsd/man4/procfs.4 3.html delete mode 100644 static/freebsd/man4/proto.4 3.html delete mode 100644 static/freebsd/man4/ps4dshock.4 3.html delete mode 100644 static/freebsd/man4/psm.4 3.html delete mode 100644 static/freebsd/man4/pst.4 3.html delete mode 100644 static/freebsd/man4/pt.4 3.html delete mode 100644 static/freebsd/man4/ptnet.4 3.html delete mode 100644 static/freebsd/man4/pts.4 3.html delete mode 100644 static/freebsd/man4/pty.4 3.html delete mode 100644 static/freebsd/man4/puc.4 4.html delete mode 100644 static/freebsd/man4/pvscsi.4 3.html delete mode 100644 static/freebsd/man4/pwmc.4 3.html delete mode 100644 static/freebsd/man4/qat.4 3.html delete mode 100644 static/freebsd/man4/qat_c2xxx.4 3.html delete mode 100644 static/freebsd/man4/qlnxe.4 3.html delete mode 100644 static/freebsd/man4/qlxgb.4 3.html delete mode 100644 static/freebsd/man4/qlxgbe.4 3.html delete mode 100644 static/freebsd/man4/qlxge.4 3.html delete mode 100644 static/freebsd/man4/ral.4 3.html delete mode 100644 static/freebsd/man4/random.4 3.html delete mode 100644 static/freebsd/man4/rccgpio.4 4.html delete mode 100644 static/freebsd/man4/rctl.4 3.html delete mode 100644 static/freebsd/man4/re.4 3.html delete mode 100644 static/freebsd/man4/rge.4 3.html delete mode 100644 static/freebsd/man4/rgephy.4 3.html delete mode 100644 static/freebsd/man4/rights.4 3.html delete mode 100644 static/freebsd/man4/rl.4 3.html delete mode 100644 static/freebsd/man4/rndtest.4 4.html delete mode 100644 static/freebsd/man4/route.4 3.html delete mode 100644 static/freebsd/man4/rsu.4 3.html delete mode 100644 static/freebsd/man4/rsufw.4 4.html delete mode 100644 static/freebsd/man4/rtnetlink.4 3.html delete mode 100644 static/freebsd/man4/rtsx.4 3.html delete mode 100644 static/freebsd/man4/rtw88.4 3.html delete mode 100644 static/freebsd/man4/rtw89.4 3.html delete mode 100644 static/freebsd/man4/rtwn.4 3.html delete mode 100644 static/freebsd/man4/rtwn_pci.4 4.html delete mode 100644 static/freebsd/man4/rtwn_usb.4 3.html delete mode 100644 static/freebsd/man4/rtwnfw.4 3.html delete mode 100644 static/freebsd/man4/rue.4 3.html delete mode 100644 static/freebsd/man4/rum.4 3.html delete mode 100644 static/freebsd/man4/run.4 3.html delete mode 100644 static/freebsd/man4/runfw.4 4.html delete mode 100644 static/freebsd/man4/sa.4 3.html delete mode 100644 static/freebsd/man4/safe.4 3.html delete mode 100644 static/freebsd/man4/safexcel.4 4.html delete mode 100644 static/freebsd/man4/sbp.4 3.html delete mode 100644 static/freebsd/man4/sbp_targ.4 4.html delete mode 100644 static/freebsd/man4/scc.4 4.html delete mode 100644 static/freebsd/man4/sched_4bsd.4 3.html delete mode 100644 static/freebsd/man4/sched_ule.4 4.html delete mode 100644 static/freebsd/man4/screen.4 3.html delete mode 100644 static/freebsd/man4/scsi.4 3.html delete mode 100644 static/freebsd/man4/sctp.4 3.html delete mode 100644 static/freebsd/man4/sdhci.4 3.html delete mode 100644 static/freebsd/man4/sem.4 3.html delete mode 100644 static/freebsd/man4/send.4 3.html delete mode 100644 static/freebsd/man4/ses.4 3.html delete mode 100644 static/freebsd/man4/sfxge.4 3.html delete mode 100644 static/freebsd/man4/sg.4 4.html delete mode 100644 static/freebsd/man4/sge.4 3.html delete mode 100644 static/freebsd/man4/siba.4 3.html delete mode 100644 static/freebsd/man4/siftr.4 3.html delete mode 100644 static/freebsd/man4/siis.4 3.html delete mode 100644 static/freebsd/man4/simplebus.4 4.html delete mode 100644 static/freebsd/man4/sis.4 3.html delete mode 100644 static/freebsd/man4/sk.4 3.html delete mode 100644 static/freebsd/man4/smartpqi.4 3.html delete mode 100644 static/freebsd/man4/smb.4 3.html delete mode 100644 static/freebsd/man4/smbfs.4 3.html delete mode 100644 static/freebsd/man4/smbios.4 4.html delete mode 100644 static/freebsd/man4/smbus.4 3.html delete mode 100644 static/freebsd/man4/smp.4 3.html delete mode 100644 static/freebsd/man4/smsc.4 4.html delete mode 100644 static/freebsd/man4/snd_als4000.4 4.html delete mode 100644 static/freebsd/man4/snd_atiixp.4 3.html delete mode 100644 static/freebsd/man4/snd_cmi.4 4.html delete mode 100644 static/freebsd/man4/snd_cs4281.4 4.html delete mode 100644 static/freebsd/man4/snd_csa.4 4.html delete mode 100644 static/freebsd/man4/snd_dummy.4 4.html delete mode 100644 static/freebsd/man4/snd_emu10k1.4 3.html delete mode 100644 static/freebsd/man4/snd_emu10kx.4 3.html delete mode 100644 static/freebsd/man4/snd_envy24.4 4.html delete mode 100644 static/freebsd/man4/snd_envy24ht.4 4.html delete mode 100644 static/freebsd/man4/snd_es137x.4 3.html delete mode 100644 static/freebsd/man4/snd_fm801.4 4.html delete mode 100644 static/freebsd/man4/snd_hda.4 3.html delete mode 100644 static/freebsd/man4/snd_hdsp.4 3.html delete mode 100644 static/freebsd/man4/snd_hdspe.4 3.html delete mode 100644 static/freebsd/man4/snd_ich.4 4.html delete mode 100644 static/freebsd/man4/snd_maestro3.4 3.html delete mode 100644 static/freebsd/man4/snd_neomagic.4 4.html delete mode 100644 static/freebsd/man4/snd_solo.4 4.html delete mode 100644 static/freebsd/man4/snd_spicds.4 3.html delete mode 100644 static/freebsd/man4/snd_t4dwave.4 3.html delete mode 100644 static/freebsd/man4/snd_uaudio.4 3.html delete mode 100644 static/freebsd/man4/snd_via8233.4 4.html delete mode 100644 static/freebsd/man4/snd_via82c686.4 3.html delete mode 100644 static/freebsd/man4/snd_vibes.4 4.html delete mode 100644 static/freebsd/man4/sndstat.4 3.html delete mode 100644 static/freebsd/man4/snp.4 3.html delete mode 100644 static/freebsd/man4/spigen.4 3.html delete mode 100644 static/freebsd/man4/spkr.4 3.html delete mode 100644 static/freebsd/man4/splash.4 3.html delete mode 100644 static/freebsd/man4/ste.4 3.html delete mode 100644 static/freebsd/man4/stf.4 3.html delete mode 100644 static/freebsd/man4/stge.4 3.html delete mode 100644 static/freebsd/man4/sume.4 3.html delete mode 100644 static/freebsd/man4/superio.4 3.html delete mode 100644 static/freebsd/man4/sym.4 3.html delete mode 100644 static/freebsd/man4/syncache.4 3.html delete mode 100644 static/freebsd/man4/syncer.4 3.html delete mode 100644 static/freebsd/man4/syscons.4 3.html delete mode 100644 static/freebsd/man4/sysmouse.4 3.html delete mode 100644 static/freebsd/man4/tap.4 3.html delete mode 100644 static/freebsd/man4/tarfs.4 3.html delete mode 100644 static/freebsd/man4/targ.4 3.html delete mode 100644 static/freebsd/man4/tcp.4 3.html delete mode 100644 static/freebsd/man4/tcp_bbr.4 3.html delete mode 100644 static/freebsd/man4/tcp_rack.4 3.html delete mode 100644 static/freebsd/man4/tdfx.4 3.html delete mode 100644 static/freebsd/man4/termios.4 3.html delete mode 100644 static/freebsd/man4/textdump.4 3.html delete mode 100644 static/freebsd/man4/thunderbolt.4 4.html delete mode 100644 static/freebsd/man4/ti.4 3.html delete mode 100644 static/freebsd/man4/timecounters.4 3.html delete mode 100644 static/freebsd/man4/tmpfs.4 3.html delete mode 100644 static/freebsd/man4/tpm.4 4.html delete mode 100644 static/freebsd/man4/tslog.4 3.html delete mode 100644 static/freebsd/man4/tty.4 3.html delete mode 100644 static/freebsd/man4/tun.4 3.html delete mode 100644 static/freebsd/man4/tws.4 3.html delete mode 100644 static/freebsd/man4/u2f.4 4.html delete mode 100644 static/freebsd/man4/u3g.4 3.html delete mode 100644 static/freebsd/man4/uark.4 3.html delete mode 100644 static/freebsd/man4/uart.4 3.html delete mode 100644 static/freebsd/man4/uath.4 3.html delete mode 100644 static/freebsd/man4/ubsa.4 4.html delete mode 100644 static/freebsd/man4/ubser.4 4.html delete mode 100644 static/freebsd/man4/ubtbcmfw.4 3.html delete mode 100644 static/freebsd/man4/uchcom.4 4.html delete mode 100644 static/freebsd/man4/ucom.4 3.html delete mode 100644 static/freebsd/man4/ucycom.4 4.html delete mode 100644 static/freebsd/man4/udav.4 4.html delete mode 100644 static/freebsd/man4/udbc.4 3.html delete mode 100644 static/freebsd/man4/udbp.4 3.html delete mode 100644 static/freebsd/man4/udl.4 4.html delete mode 100644 static/freebsd/man4/udp.4 3.html delete mode 100644 static/freebsd/man4/udplite.4 3.html delete mode 100644 static/freebsd/man4/uep.4 3.html delete mode 100644 static/freebsd/man4/ufintek.4 4.html delete mode 100644 static/freebsd/man4/ufoma.4 3.html delete mode 100644 static/freebsd/man4/ufshci.4 3.html delete mode 100644 static/freebsd/man4/uftdi.4 4.html delete mode 100644 static/freebsd/man4/ugen.4 3.html delete mode 100644 static/freebsd/man4/ugold.4 3.html delete mode 100644 static/freebsd/man4/uhci.4 4.html delete mode 100644 static/freebsd/man4/uhid.4 3.html delete mode 100644 static/freebsd/man4/uhso.4 3.html delete mode 100644 static/freebsd/man4/uipaq.4 4.html delete mode 100644 static/freebsd/man4/ukbd.4 3.html delete mode 100644 static/freebsd/man4/uled.4 4.html delete mode 100644 static/freebsd/man4/ulpt.4 3.html delete mode 100644 static/freebsd/man4/umass.4 3.html delete mode 100644 static/freebsd/man4/umb.4 3.html delete mode 100644 static/freebsd/man4/umcs.4 4.html delete mode 100644 static/freebsd/man4/umct.4 4.html delete mode 100644 static/freebsd/man4/umodem.4 3.html delete mode 100644 static/freebsd/man4/umoscom.4 4.html delete mode 100644 static/freebsd/man4/ums.4 4.html delete mode 100644 static/freebsd/man4/unionfs.4 3.html delete mode 100644 static/freebsd/man4/unix.4 3.html delete mode 100644 static/freebsd/man4/upgt.4 3.html delete mode 100644 static/freebsd/man4/uplcom.4 3.html delete mode 100644 static/freebsd/man4/ural.4 3.html delete mode 100644 static/freebsd/man4/ure.4 3.html delete mode 100644 static/freebsd/man4/urio.4 4.html delete mode 100644 static/freebsd/man4/urndis.4 3.html delete mode 100644 static/freebsd/man4/urtw.4 3.html delete mode 100644 static/freebsd/man4/usb.4 4.html delete mode 100644 static/freebsd/man4/usb_quirk.4 3.html delete mode 100644 static/freebsd/man4/usb_template.4 3.html delete mode 100644 static/freebsd/man4/usbhid.4 3.html delete mode 100644 static/freebsd/man4/usfs.4 3.html delete mode 100644 static/freebsd/man4/uslcom.4 3.html delete mode 100644 static/freebsd/man4/uvisor.4 4.html delete mode 100644 static/freebsd/man4/uvscom.4 4.html delete mode 100644 static/freebsd/man4/vale.4 3.html delete mode 100644 static/freebsd/man4/veriexec.4 4.html delete mode 100644 static/freebsd/man4/vga.4 3.html delete mode 100644 static/freebsd/man4/vge.4 3.html delete mode 100644 static/freebsd/man4/viapm.4 3.html delete mode 100644 static/freebsd/man4/viawd.4 3.html delete mode 100644 static/freebsd/man4/virtio.4 3.html delete mode 100644 static/freebsd/man4/virtio_balloon.4 4.html delete mode 100644 static/freebsd/man4/virtio_blk.4 3.html delete mode 100644 static/freebsd/man4/virtio_console.4 4.html delete mode 100644 static/freebsd/man4/virtio_gpu.4 4.html delete mode 100644 static/freebsd/man4/virtio_random.4 4.html delete mode 100644 static/freebsd/man4/virtio_scsi.4 4.html delete mode 100644 static/freebsd/man4/vkbd.4 3.html delete mode 100644 static/freebsd/man4/vlan.4 3.html delete mode 100644 static/freebsd/man4/vmci.4 3.html delete mode 100644 static/freebsd/man4/vmd.4 4.html delete mode 100644 static/freebsd/man4/vmgenc.4 3.html delete mode 100644 static/freebsd/man4/vmm.4 3.html delete mode 100644 static/freebsd/man4/vmx.4 3.html delete mode 100644 static/freebsd/man4/vr.4 3.html delete mode 100644 static/freebsd/man4/vt.4 3.html delete mode 100644 static/freebsd/man4/vte.4 3.html delete mode 100644 static/freebsd/man4/vtnet.4 3.html delete mode 100644 static/freebsd/man4/vxlan.4 3.html delete mode 100644 static/freebsd/man4/watchdog.4 3.html delete mode 100644 static/freebsd/man4/wbwd.4 3.html delete mode 100644 static/freebsd/man4/wdatwd.4 3.html delete mode 100644 static/freebsd/man4/wg.4 3.html delete mode 100644 static/freebsd/man4/witness.4 3.html delete mode 100644 static/freebsd/man4/wlan.4 3.html delete mode 100644 static/freebsd/man4/wlan_acl.4 4.html delete mode 100644 static/freebsd/man4/wlan_amrr.4 4.html delete mode 100644 static/freebsd/man4/wlan_ccmp.4 4.html delete mode 100644 static/freebsd/man4/wlan_gcmp.4 3.html delete mode 100644 static/freebsd/man4/wlan_tkip.4 4.html delete mode 100644 static/freebsd/man4/wlan_wep.4 3.html delete mode 100644 static/freebsd/man4/wlan_xauth.4 3.html delete mode 100644 static/freebsd/man4/wmt.4 4.html delete mode 100644 static/freebsd/man4/wpi.4 3.html delete mode 100644 static/freebsd/man4/wsp.4 3.html delete mode 100644 static/freebsd/man4/xb360gp.4 4.html delete mode 100644 static/freebsd/man4/xdma.4 3.html delete mode 100644 static/freebsd/man4/xen.4 3.html delete mode 100644 static/freebsd/man4/xhci.4 3.html delete mode 100644 static/freebsd/man4/xl.4 3.html delete mode 100644 static/freebsd/man4/xnb.4 3.html delete mode 100644 static/freebsd/man4/xpt.4 4.html delete mode 100644 static/freebsd/man4/zero.4 3.html delete mode 100644 static/freebsd/man4/zyd.4 4.html delete mode 100644 static/freebsd/man5/a.out.5 3.html delete mode 100644 static/freebsd/man5/acct.5 3.html delete mode 100644 static/freebsd/man5/ar.5 3.html delete mode 100644 static/freebsd/man5/bluetooth.device.conf.5 3.html delete mode 100644 static/freebsd/man5/bluetooth.hosts.5 4.html delete mode 100644 static/freebsd/man5/bluetooth.protocols.5 4.html delete mode 100644 static/freebsd/man5/boot.config.5 3.html delete mode 100644 static/freebsd/man5/core.5 3.html delete mode 100644 static/freebsd/man5/devfs.conf.5 3.html delete mode 100644 static/freebsd/man5/devfs.rules.5 3.html delete mode 100644 static/freebsd/man5/device.hints.5 3.html delete mode 100644 static/freebsd/man5/dir.5 3.html delete mode 100644 static/freebsd/man5/disktab.5 3.html delete mode 100644 static/freebsd/man5/elf.5 3.html delete mode 100644 static/freebsd/man5/ethers.5 4.html delete mode 100644 static/freebsd/man5/eui64.5 4.html delete mode 100644 static/freebsd/man5/fbtab.5 4.html delete mode 100644 static/freebsd/man5/forward.5 4.html delete mode 100644 static/freebsd/man5/freebsd-update.conf.5 3.html delete mode 100644 static/freebsd/man5/fs.5 3.html delete mode 100644 static/freebsd/man5/fstab.5 3.html delete mode 100644 static/freebsd/man5/group.5 3.html delete mode 100644 static/freebsd/man5/hesiod.conf.5 4.html delete mode 100644 static/freebsd/man5/hosts.5 3.html delete mode 100644 static/freebsd/man5/hosts.equiv.5 3.html delete mode 100644 static/freebsd/man5/hosts.lpd.5 4.html delete mode 100644 static/freebsd/man5/intro.5 4.html delete mode 100644 static/freebsd/man5/libmap.conf.5 3.html delete mode 100644 static/freebsd/man5/link.5 3.html delete mode 100644 static/freebsd/man5/mailer.conf.5 3.html delete mode 100644 static/freebsd/man5/make.conf.5 3.html delete mode 100644 static/freebsd/man5/moduli.5 3.html delete mode 100644 static/freebsd/man5/motd.5 4.html delete mode 100644 static/freebsd/man5/mount.conf.5 3.html delete mode 100644 static/freebsd/man5/networks.5 4.html delete mode 100644 static/freebsd/man5/nsmb.conf.5 3.html delete mode 100644 static/freebsd/man5/nsswitch.conf.5 3.html delete mode 100644 static/freebsd/man5/os-release.5 3.html delete mode 100644 static/freebsd/man5/passwd.5 3.html delete mode 100644 static/freebsd/man5/pbm.5 3.html delete mode 100644 static/freebsd/man5/periodic.conf.5 3.html delete mode 100644 static/freebsd/man5/pf.conf.5 3.html delete mode 100644 static/freebsd/man5/pf.os.5 3.html delete mode 100644 static/freebsd/man5/phones.5 4.html delete mode 100644 static/freebsd/man5/portindex.5 3.html delete mode 100644 static/freebsd/man5/protocols.5 4.html delete mode 100644 static/freebsd/man5/quota.user.5 3.html delete mode 100644 static/freebsd/man5/rc.conf.5 3.html delete mode 100644 static/freebsd/man5/rctl.conf.5 4.html delete mode 100644 static/freebsd/man5/regdomain.5 4.html delete mode 100644 static/freebsd/man5/remote.5 3.html delete mode 100644 static/freebsd/man5/resolver.5 3.html delete mode 100644 static/freebsd/man5/services.5 3.html delete mode 100644 static/freebsd/man5/shells.5 4.html delete mode 100644 static/freebsd/man5/src.conf.5 3.html delete mode 100644 static/freebsd/man5/stab.5 3.html delete mode 100644 static/freebsd/man5/style.Makefile.5 3.html delete mode 100644 static/freebsd/man5/style.mdoc.5 3.html delete mode 100644 static/freebsd/man5/sysctl.conf.5 4.html delete mode 100644 static/freebsd/man6/intro.6 4.html delete mode 100644 static/freebsd/man7/arch.7 3.html delete mode 100644 static/freebsd/man7/ascii.7 3.html delete mode 100644 static/freebsd/man7/bsd.snmpmod.mk.7 3.html delete mode 100644 static/freebsd/man7/build.7 3.html delete mode 100644 static/freebsd/man7/c.7 3.html delete mode 100644 static/freebsd/man7/clocks.7 3.html delete mode 100644 static/freebsd/man7/crypto.7 3.html delete mode 100644 static/freebsd/man7/d.7 3.html delete mode 100644 static/freebsd/man7/development.7 3.html delete mode 100644 static/freebsd/man7/environ.7 3.html delete mode 100644 static/freebsd/man7/firewall.7 3.html delete mode 100644 static/freebsd/man7/freebsd-base.7 3.html delete mode 100644 static/freebsd/man7/growfs.7 3.html delete mode 100644 static/freebsd/man7/hier.7 3.html delete mode 100644 static/freebsd/man7/hostname.7 3.html delete mode 100644 static/freebsd/man7/intro.7 4.html delete mode 100644 static/freebsd/man7/maclabel.7 3.html delete mode 100644 static/freebsd/man7/mitigations.7 3.html delete mode 100644 static/freebsd/man7/named_attribute.7 3.html delete mode 100644 static/freebsd/man7/networking.7 4.html delete mode 100644 static/freebsd/man7/operator.7 4.html delete mode 100644 static/freebsd/man7/orders.7 3.html delete mode 100644 static/freebsd/man7/ports.7 3.html delete mode 100644 static/freebsd/man7/release.7 3.html delete mode 100644 static/freebsd/man7/sdoc.7 3.html delete mode 100644 static/freebsd/man7/security.7 3.html delete mode 100644 static/freebsd/man7/simd.7 4.html delete mode 100644 static/freebsd/man7/sizeof.7 3.html delete mode 100644 static/freebsd/man7/sprog.7 3.html delete mode 100644 static/freebsd/man7/stats.7 4.html delete mode 100644 static/freebsd/man7/stdint.7 3.html delete mode 100644 static/freebsd/man7/sticky.7 4.html delete mode 100644 static/freebsd/man7/tests.7 3.html delete mode 100644 static/freebsd/man7/tracing.7 3.html delete mode 100644 static/freebsd/man7/tuning.7 3.html delete mode 100644 static/freebsd/man8/beinstall.8 3.html delete mode 100644 static/freebsd/man8/crash.8 3.html delete mode 100644 static/freebsd/man8/debug.sh.8 3.html delete mode 100644 static/freebsd/man8/diskless.8 3.html delete mode 100644 static/freebsd/man8/intro.8 4.html delete mode 100644 static/freebsd/man8/nanobsd.8 3.html delete mode 100644 static/freebsd/man8/rc.8 3.html delete mode 100644 static/freebsd/man8/rc.subr.8 3.html delete mode 100644 static/freebsd/man8/rescue.8 3.html delete mode 100644 static/freebsd/man8/uefi.8 3.html delete mode 100644 static/freebsd/man8/yp.8 3.html delete mode 100644 static/freebsd/man9/BUF_ISLOCKED.9 4.html delete mode 100644 static/freebsd/man9/BUF_LOCK.9 4.html delete mode 100644 static/freebsd/man9/BUF_LOCKFREE.9 4.html delete mode 100644 static/freebsd/man9/BUF_LOCKINIT.9 4.html delete mode 100644 static/freebsd/man9/BUF_RECURSED.9 4.html delete mode 100644 static/freebsd/man9/BUF_TIMELOCK.9 4.html delete mode 100644 static/freebsd/man9/BUF_UNLOCK.9 4.html delete mode 100644 static/freebsd/man9/BUS_ADD_CHILD.9 3.html delete mode 100644 static/freebsd/man9/BUS_BIND_INTR.9 3.html delete mode 100644 static/freebsd/man9/BUS_CHILD_DELETED.9 4.html delete mode 100644 static/freebsd/man9/BUS_CHILD_DETACHED.9 4.html delete mode 100644 static/freebsd/man9/BUS_CHILD_LOCATION.9 4.html delete mode 100644 static/freebsd/man9/BUS_CHILD_PNPINFO.9 3.html delete mode 100644 static/freebsd/man9/BUS_CONFIG_INTR.9 3.html delete mode 100644 static/freebsd/man9/BUS_DESCRIBE_INTR.9 3.html delete mode 100644 static/freebsd/man9/BUS_GET_CPUS.9 3.html delete mode 100644 static/freebsd/man9/BUS_GET_PROPERTY.9 4.html delete mode 100644 static/freebsd/man9/BUS_HINTED_CHILD.9 4.html delete mode 100644 static/freebsd/man9/BUS_NEW_PASS.9 4.html delete mode 100644 static/freebsd/man9/BUS_PRINT_CHILD.9 4.html delete mode 100644 static/freebsd/man9/BUS_READ_IVAR.9 4.html delete mode 100644 static/freebsd/man9/BUS_RESCAN.9 4.html delete mode 100644 static/freebsd/man9/BUS_SETUP_INTR.9 3.html delete mode 100644 static/freebsd/man9/CTASSERT.9 4.html delete mode 100644 static/freebsd/man9/DB_COMMAND.9 3.html delete mode 100644 static/freebsd/man9/DECLARE_GEOM_CLASS.9 3.html delete mode 100644 static/freebsd/man9/DECLARE_MODULE.9 3.html delete mode 100644 static/freebsd/man9/DEFINE_IFUNC.9 3.html delete mode 100644 static/freebsd/man9/DELAY.9 4.html delete mode 100644 static/freebsd/man9/DEVICE_ATTACH.9 4.html delete mode 100644 static/freebsd/man9/DEVICE_DETACH.9 4.html delete mode 100644 static/freebsd/man9/DEVICE_IDENTIFY.9 3.html delete mode 100644 static/freebsd/man9/DEVICE_PROBE.9 3.html delete mode 100644 static/freebsd/man9/DEVICE_SHUTDOWN.9 4.html delete mode 100644 static/freebsd/man9/DEV_MODULE.9 4.html delete mode 100644 static/freebsd/man9/DRIVER_MODULE.9 3.html delete mode 100644 static/freebsd/man9/EVENTHANDLER.9 3.html delete mode 100644 static/freebsd/man9/KASSERT.9 3.html delete mode 100644 static/freebsd/man9/LOCK_PROFILING.9 3.html delete mode 100644 static/freebsd/man9/MODULE_DEPEND.9 4.html delete mode 100644 static/freebsd/man9/MODULE_PNP_INFO.9 4.html delete mode 100644 static/freebsd/man9/MODULE_VERSION.9 4.html delete mode 100644 static/freebsd/man9/OF_child.9 4.html delete mode 100644 static/freebsd/man9/OF_device_from_xref.9 3.html delete mode 100644 static/freebsd/man9/OF_finddevice.9 4.html delete mode 100644 static/freebsd/man9/OF_getprop.9 4.html delete mode 100644 static/freebsd/man9/OF_node_from_xref.9 3.html delete mode 100644 static/freebsd/man9/OF_package_to_path.9 4.html delete mode 100644 static/freebsd/man9/PCI_IOV_ADD_VF.9 3.html delete mode 100644 static/freebsd/man9/PCI_IOV_INIT.9 4.html delete mode 100644 static/freebsd/man9/PCI_IOV_UNINIT.9 4.html delete mode 100644 static/freebsd/man9/PHOLD.9 4.html delete mode 100644 static/freebsd/man9/SDT.9 4.html delete mode 100644 static/freebsd/man9/SYSCALL_MODULE.9 4.html delete mode 100644 static/freebsd/man9/SYSINIT.9 3.html delete mode 100644 static/freebsd/man9/VFS.9 4.html delete mode 100644 static/freebsd/man9/VFS_CHECKEXP.9 4.html delete mode 100644 static/freebsd/man9/VFS_FHTOVP.9 3.html delete mode 100644 static/freebsd/man9/VFS_MOUNT.9 4.html delete mode 100644 static/freebsd/man9/VFS_QUOTACTL.9 4.html delete mode 100644 static/freebsd/man9/VFS_ROOT.9 4.html delete mode 100644 static/freebsd/man9/VFS_SET.9 4.html delete mode 100644 static/freebsd/man9/VFS_STATFS.9 4.html delete mode 100644 static/freebsd/man9/VFS_SYNC.9 4.html delete mode 100644 static/freebsd/man9/VFS_UNMOUNT.9 4.html delete mode 100644 static/freebsd/man9/VFS_VGET.9 4.html delete mode 100644 static/freebsd/man9/VNET.9 4.html delete mode 100644 static/freebsd/man9/VOP_ACCESS.9 4.html delete mode 100644 static/freebsd/man9/VOP_ACLCHECK.9 4.html delete mode 100644 static/freebsd/man9/VOP_ADVISE.9 4.html delete mode 100644 static/freebsd/man9/VOP_ADVLOCK.9 4.html delete mode 100644 static/freebsd/man9/VOP_ALLOCATE.9 4.html delete mode 100644 static/freebsd/man9/VOP_ATTRIB.9 4.html delete mode 100644 static/freebsd/man9/VOP_BMAP.9 4.html delete mode 100644 static/freebsd/man9/VOP_BWRITE.9 4.html delete mode 100644 static/freebsd/man9/VOP_COPY_FILE_RANGE.9 3.html delete mode 100644 static/freebsd/man9/VOP_CREATE.9 4.html delete mode 100644 static/freebsd/man9/VOP_DEALLOCATE.9 4.html delete mode 100644 static/freebsd/man9/VOP_FSYNC.9 4.html delete mode 100644 static/freebsd/man9/VOP_GETACL.9 4.html delete mode 100644 static/freebsd/man9/VOP_GETEXTATTR.9 4.html delete mode 100644 static/freebsd/man9/VOP_GETPAGES.9 3.html delete mode 100644 static/freebsd/man9/VOP_INACTIVE.9 4.html delete mode 100644 static/freebsd/man9/VOP_INOTIFY.9 4.html delete mode 100644 static/freebsd/man9/VOP_IOCTL.9 4.html delete mode 100644 static/freebsd/man9/VOP_LINK.9 4.html delete mode 100644 static/freebsd/man9/VOP_LISTEXTATTR.9 4.html delete mode 100644 static/freebsd/man9/VOP_LOCK.9 4.html delete mode 100644 static/freebsd/man9/VOP_LOOKUP.9 4.html delete mode 100644 static/freebsd/man9/VOP_OPENCLOSE.9 4.html delete mode 100644 static/freebsd/man9/VOP_PATHCONF.9 4.html delete mode 100644 static/freebsd/man9/VOP_PRINT.9 4.html delete mode 100644 static/freebsd/man9/VOP_RDWR.9 4.html delete mode 100644 static/freebsd/man9/VOP_READDIR.9 4.html delete mode 100644 static/freebsd/man9/VOP_READLINK.9 4.html delete mode 100644 static/freebsd/man9/VOP_READ_PGCACHE.9 4.html delete mode 100644 static/freebsd/man9/VOP_REALLOCBLKS.9 4.html delete mode 100644 static/freebsd/man9/VOP_REMOVE.9 4.html delete mode 100644 static/freebsd/man9/VOP_RENAME.9 4.html delete mode 100644 static/freebsd/man9/VOP_REVOKE.9 4.html delete mode 100644 static/freebsd/man9/VOP_SETACL.9 4.html delete mode 100644 static/freebsd/man9/VOP_SETEXTATTR.9 4.html delete mode 100644 static/freebsd/man9/VOP_SETLABEL.9 3.html delete mode 100644 static/freebsd/man9/VOP_STRATEGY.9 4.html delete mode 100644 static/freebsd/man9/VOP_VPTOCNP.9 4.html delete mode 100644 static/freebsd/man9/VOP_VPTOFH.9 4.html delete mode 100644 static/freebsd/man9/accept_filter.9 3.html delete mode 100644 static/freebsd/man9/accf_data.9 4.html delete mode 100644 static/freebsd/man9/accf_dns.9 3.html delete mode 100644 static/freebsd/man9/accf_http.9 3.html delete mode 100644 static/freebsd/man9/accf_tls.9 3.html delete mode 100644 static/freebsd/man9/acl.9 3.html delete mode 100644 static/freebsd/man9/alq.9 3.html delete mode 100644 static/freebsd/man9/altq.9 3.html delete mode 100644 static/freebsd/man9/atomic.9 3.html delete mode 100644 static/freebsd/man9/backlight.9 3.html delete mode 100644 static/freebsd/man9/bhnd.9 3.html delete mode 100644 static/freebsd/man9/bhnd_erom.9 3.html delete mode 100644 static/freebsd/man9/bios.9 3.html delete mode 100644 static/freebsd/man9/bitset.9 3.html delete mode 100644 static/freebsd/man9/bpf.9 3.html delete mode 100644 static/freebsd/man9/buf.9 3.html delete mode 100644 static/freebsd/man9/buf_ring.9 3.html delete mode 100644 static/freebsd/man9/bus_activate_resource.9 3.html delete mode 100644 static/freebsd/man9/bus_adjust_resource.9 4.html delete mode 100644 static/freebsd/man9/bus_alloc_resource.9 3.html delete mode 100644 static/freebsd/man9/bus_attach_children.9 3.html delete mode 100644 static/freebsd/man9/bus_child_present.9 3.html delete mode 100644 static/freebsd/man9/bus_dma.9 3.html delete mode 100644 static/freebsd/man9/bus_generic_detach.9 4.html delete mode 100644 static/freebsd/man9/bus_generic_new_pass.9 4.html delete mode 100644 static/freebsd/man9/bus_generic_print_child.9 3.html delete mode 100644 static/freebsd/man9/bus_generic_read_ivar.9 4.html delete mode 100644 static/freebsd/man9/bus_generic_shutdown.9 4.html delete mode 100644 static/freebsd/man9/bus_get_resource.9 4.html delete mode 100644 static/freebsd/man9/bus_map_resource.9 3.html delete mode 100644 static/freebsd/man9/bus_release_resource.9 4.html delete mode 100644 static/freebsd/man9/bus_set_pass.9 4.html delete mode 100644 static/freebsd/man9/bus_set_resource.9 4.html delete mode 100644 static/freebsd/man9/bus_space.9 3.html delete mode 100644 static/freebsd/man9/byteorder.9 4.html delete mode 100644 static/freebsd/man9/callout.9 3.html delete mode 100644 static/freebsd/man9/casuword.9 3.html delete mode 100644 static/freebsd/man9/cd.9 3.html delete mode 100644 static/freebsd/man9/cdefs.9 3.html delete mode 100644 static/freebsd/man9/cnv.9 4.html delete mode 100644 static/freebsd/man9/condvar.9 4.html delete mode 100644 static/freebsd/man9/config_intrhook.9 3.html delete mode 100644 static/freebsd/man9/contigmalloc.9 3.html delete mode 100644 static/freebsd/man9/copy.9 3.html delete mode 100644 static/freebsd/man9/coredumper_register.9 3.html delete mode 100644 static/freebsd/man9/counter.9 4.html delete mode 100644 static/freebsd/man9/cpu_machdep.9 3.html delete mode 100644 static/freebsd/man9/cpuset.9 4.html delete mode 100644 static/freebsd/man9/cr_bsd_visible.9 3.html delete mode 100644 static/freebsd/man9/cr_cansee.9 3.html delete mode 100644 static/freebsd/man9/cr_canseejailproc.9 4.html delete mode 100644 static/freebsd/man9/cr_canseeothergids.9 4.html delete mode 100644 static/freebsd/man9/cr_canseeotheruids.9 4.html delete mode 100644 static/freebsd/man9/critical_enter.9 3.html delete mode 100644 static/freebsd/man9/crypto.9 3.html delete mode 100644 static/freebsd/man9/crypto_buffer.9 3.html delete mode 100644 static/freebsd/man9/crypto_driver.9 4.html delete mode 100644 static/freebsd/man9/crypto_request.9 4.html delete mode 100644 static/freebsd/man9/crypto_session.9 3.html delete mode 100644 static/freebsd/man9/deadfs.9 4.html delete mode 100644 static/freebsd/man9/dev_clone.9 4.html delete mode 100644 static/freebsd/man9/dev_refthread.9 3.html delete mode 100644 static/freebsd/man9/devclass.9 4.html delete mode 100644 static/freebsd/man9/devclass_find.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_count.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_device.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_devices.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_drivers.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_maxunit.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_name.9 4.html delete mode 100644 static/freebsd/man9/devclass_get_softc.9 4.html delete mode 100644 static/freebsd/man9/devctl_notify.9 4.html delete mode 100644 static/freebsd/man9/devctl_process_running.9 4.html delete mode 100644 static/freebsd/man9/devctl_safe_quote_sb.9 4.html delete mode 100644 static/freebsd/man9/devfs_set_cdevpriv.9 3.html delete mode 100644 static/freebsd/man9/device.9 3.html delete mode 100644 static/freebsd/man9/device_add_child.9 3.html delete mode 100644 static/freebsd/man9/device_delete_child.9 4.html delete mode 100644 static/freebsd/man9/device_delete_children.9 4.html delete mode 100644 static/freebsd/man9/device_enable.9 4.html delete mode 100644 static/freebsd/man9/device_find_child.9 4.html delete mode 100644 static/freebsd/man9/device_get_children.9 3.html delete mode 100644 static/freebsd/man9/device_get_devclass.9 4.html delete mode 100644 static/freebsd/man9/device_get_driver.9 4.html delete mode 100644 static/freebsd/man9/device_get_ivars.9 4.html delete mode 100644 static/freebsd/man9/device_get_name.9 4.html delete mode 100644 static/freebsd/man9/device_get_parent.9 4.html delete mode 100644 static/freebsd/man9/device_get_property.9 3.html delete mode 100644 static/freebsd/man9/device_get_softc.9 4.html delete mode 100644 static/freebsd/man9/device_get_state.9 3.html delete mode 100644 static/freebsd/man9/device_get_sysctl.9 4.html delete mode 100644 static/freebsd/man9/device_get_unit.9 4.html delete mode 100644 static/freebsd/man9/device_printf.9 4.html delete mode 100644 static/freebsd/man9/device_probe_and_attach.9 3.html delete mode 100644 static/freebsd/man9/device_quiet.9 4.html delete mode 100644 static/freebsd/man9/device_set_desc.9 4.html delete mode 100644 static/freebsd/man9/device_set_driver.9 4.html delete mode 100644 static/freebsd/man9/device_set_flags.9 4.html delete mode 100644 static/freebsd/man9/devstat.9 3.html delete mode 100644 static/freebsd/man9/devtoname.9 4.html delete mode 100644 static/freebsd/man9/disk.9 3.html delete mode 100644 static/freebsd/man9/dnv.9 3.html delete mode 100644 static/freebsd/man9/domain.9 3.html delete mode 100644 static/freebsd/man9/domainset.9 3.html delete mode 100644 static/freebsd/man9/dpcpu.9 4.html delete mode 100644 static/freebsd/man9/drbr.9 3.html delete mode 100644 static/freebsd/man9/driver.9 3.html delete mode 100644 static/freebsd/man9/ecn.9 3.html delete mode 100644 static/freebsd/man9/efirt.9 3.html delete mode 100644 static/freebsd/man9/epoch.9 4.html delete mode 100644 static/freebsd/man9/ether_gen_addr.9 4.html delete mode 100644 static/freebsd/man9/eventtimers.9 4.html delete mode 100644 static/freebsd/man9/extattr.9 3.html delete mode 100644 static/freebsd/man9/exterror.9 3.html delete mode 100644 static/freebsd/man9/fail.9 3.html delete mode 100644 static/freebsd/man9/fdt_pinctrl.9 3.html delete mode 100644 static/freebsd/man9/fetch.9 3.html delete mode 100644 static/freebsd/man9/firmware.9 3.html delete mode 100644 static/freebsd/man9/fpu_kern.9 3.html delete mode 100644 static/freebsd/man9/g_access.9 3.html delete mode 100644 static/freebsd/man9/g_attach.9 3.html delete mode 100644 static/freebsd/man9/g_bio.9 3.html delete mode 100644 static/freebsd/man9/g_consumer.9 3.html delete mode 100644 static/freebsd/man9/g_data.9 3.html delete mode 100644 static/freebsd/man9/g_event.9 3.html delete mode 100644 static/freebsd/man9/g_geom.9 3.html delete mode 100644 static/freebsd/man9/g_provider.9 3.html delete mode 100644 static/freebsd/man9/g_provider_by_name.9 4.html delete mode 100644 static/freebsd/man9/g_wither_geom.9 3.html delete mode 100644 static/freebsd/man9/get_cyclecount.9 4.html delete mode 100644 static/freebsd/man9/getenv.9 4.html delete mode 100644 static/freebsd/man9/getnewvnode.9 4.html delete mode 100644 static/freebsd/man9/gone_in.9 4.html delete mode 100644 static/freebsd/man9/groupmember.9 4.html delete mode 100644 static/freebsd/man9/hardclock.9 3.html delete mode 100644 static/freebsd/man9/hash.9 3.html delete mode 100644 static/freebsd/man9/hashalloc.9 3.html delete mode 100644 static/freebsd/man9/hashinit.9 3.html delete mode 100644 static/freebsd/man9/hexdump.9 4.html delete mode 100644 static/freebsd/man9/hhook.9 3.html delete mode 100644 static/freebsd/man9/hz.9 3.html delete mode 100644 static/freebsd/man9/ieee80211.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_amrr.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_beacon.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_bmiss.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_crypto.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_ddb.9 4.html delete mode 100644 static/freebsd/man9/ieee80211_input.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_node.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_output.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_proto.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_radiotap.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_regdomain.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_scan.9 3.html delete mode 100644 static/freebsd/man9/ieee80211_vap.9 3.html delete mode 100644 static/freebsd/man9/iflib.9 4.html delete mode 100644 static/freebsd/man9/iflibdd.9 4.html delete mode 100644 static/freebsd/man9/iflibdi.9 4.html delete mode 100644 static/freebsd/man9/iflibtxrx.9 3.html delete mode 100644 static/freebsd/man9/ifnet.9 3.html delete mode 100644 static/freebsd/man9/inittodr.9 3.html delete mode 100644 static/freebsd/man9/insmntque.9 3.html delete mode 100644 static/freebsd/man9/intr_event.9 3.html delete mode 100644 static/freebsd/man9/intro.9 3.html delete mode 100644 static/freebsd/man9/kasan.9 3.html delete mode 100644 static/freebsd/man9/kern_reboot.9 3.html delete mode 100644 static/freebsd/man9/kern_testfrwk.9 3.html delete mode 100644 static/freebsd/man9/kern_yield.9 3.html delete mode 100644 static/freebsd/man9/kernacc.9 4.html delete mode 100644 static/freebsd/man9/kernel_mount.9 3.html delete mode 100644 static/freebsd/man9/khelp.9 3.html delete mode 100644 static/freebsd/man9/kmsan.9 3.html delete mode 100644 static/freebsd/man9/kobj.9 3.html delete mode 100644 static/freebsd/man9/kproc.9 3.html delete mode 100644 static/freebsd/man9/kqueue.9 4.html delete mode 100644 static/freebsd/man9/kstack_contains.9 4.html delete mode 100644 static/freebsd/man9/kthread.9 3.html delete mode 100644 static/freebsd/man9/ktr.9 4.html delete mode 100644 static/freebsd/man9/lock.9 4.html delete mode 100644 static/freebsd/man9/locking.9 3.html delete mode 100644 static/freebsd/man9/mac.9 3.html delete mode 100644 static/freebsd/man9/make_dev.9 4.html delete mode 100644 static/freebsd/man9/malloc.9 4.html delete mode 100644 static/freebsd/man9/mbchain.9 4.html delete mode 100644 static/freebsd/man9/mbuf.9 4.html delete mode 100644 static/freebsd/man9/mbuf_tags.9 4.html delete mode 100644 static/freebsd/man9/mdchain.9 4.html delete mode 100644 static/freebsd/man9/memcchr.9 4.html delete mode 100644 static/freebsd/man9/memguard.9 3.html delete mode 100644 static/freebsd/man9/mi_switch.9 3.html delete mode 100644 static/freebsd/man9/microseq.9 4.html delete mode 100644 static/freebsd/man9/microtime.9 4.html delete mode 100644 static/freebsd/man9/microuptime.9 4.html delete mode 100644 static/freebsd/man9/mod_cc.9 3.html delete mode 100644 static/freebsd/man9/module.9 3.html delete mode 100644 static/freebsd/man9/mtx_pool.9 3.html delete mode 100644 static/freebsd/man9/mutex.9 4.html delete mode 100644 static/freebsd/man9/namei.9 3.html delete mode 100644 static/freebsd/man9/netisr.9 4.html delete mode 100644 static/freebsd/man9/nv.9 4.html delete mode 100644 static/freebsd/man9/nvmem.9 3.html delete mode 100644 static/freebsd/man9/ofw_bus_is_compatible.9 3.html delete mode 100644 static/freebsd/man9/ofw_bus_status_okay.9 4.html delete mode 100644 static/freebsd/man9/ofw_graph.9 4.html delete mode 100644 static/freebsd/man9/osd.9 4.html delete mode 100644 static/freebsd/man9/owll.9 4.html delete mode 100644 static/freebsd/man9/own.9 4.html delete mode 100644 static/freebsd/man9/p_candebug.9 4.html delete mode 100644 static/freebsd/man9/p_cansee.9 4.html delete mode 100644 static/freebsd/man9/panic.9 3.html delete mode 100644 static/freebsd/man9/pci.9 4.html delete mode 100644 static/freebsd/man9/pci_iov_schema.9 3.html delete mode 100644 static/freebsd/man9/pfil.9 3.html delete mode 100644 static/freebsd/man9/pfind.9 4.html delete mode 100644 static/freebsd/man9/pget.9 4.html delete mode 100644 static/freebsd/man9/pgfind.9 4.html delete mode 100644 static/freebsd/man9/physio.9 4.html delete mode 100644 static/freebsd/man9/pmap.9 4.html delete mode 100644 static/freebsd/man9/pmap_activate.9 4.html delete mode 100644 static/freebsd/man9/pmap_clear_modify.9 4.html delete mode 100644 static/freebsd/man9/pmap_copy.9 4.html delete mode 100644 static/freebsd/man9/pmap_enter.9 3.html delete mode 100644 static/freebsd/man9/pmap_extract.9 4.html delete mode 100644 static/freebsd/man9/pmap_growkernel.9 4.html delete mode 100644 static/freebsd/man9/pmap_init.9 4.html delete mode 100644 static/freebsd/man9/pmap_is_modified.9 4.html delete mode 100644 static/freebsd/man9/pmap_is_prefaultable.9 4.html delete mode 100644 static/freebsd/man9/pmap_kextract.9 4.html delete mode 100644 static/freebsd/man9/pmap_map.9 4.html delete mode 100644 static/freebsd/man9/pmap_mincore.9 4.html delete mode 100644 static/freebsd/man9/pmap_object_init_pt.9 4.html delete mode 100644 static/freebsd/man9/pmap_page_exists_quick.9 4.html delete mode 100644 static/freebsd/man9/pmap_page_init.9 4.html delete mode 100644 static/freebsd/man9/pmap_pinit.9 4.html delete mode 100644 static/freebsd/man9/pmap_protect.9 4.html delete mode 100644 static/freebsd/man9/pmap_qenter.9 4.html delete mode 100644 static/freebsd/man9/pmap_quick_enter_page.9 4.html delete mode 100644 static/freebsd/man9/pmap_release.9 4.html delete mode 100644 static/freebsd/man9/pmap_remove.9 4.html delete mode 100644 static/freebsd/man9/pmap_resident_count.9 4.html delete mode 100644 static/freebsd/man9/pmap_unwire.9 4.html delete mode 100644 static/freebsd/man9/pmap_zero_page.9 4.html delete mode 100644 static/freebsd/man9/printf.9 3.html delete mode 100644 static/freebsd/man9/prison_check.9 4.html delete mode 100644 static/freebsd/man9/priv.9 3.html delete mode 100644 static/freebsd/man9/prng.9 4.html delete mode 100644 static/freebsd/man9/proc_rwmem.9 4.html delete mode 100644 static/freebsd/man9/pseudofs.9 4.html delete mode 100644 static/freebsd/man9/psignal.9 3.html delete mode 100644 static/freebsd/man9/pwmbus.9 3.html delete mode 100644 static/freebsd/man9/random.9 4.html delete mode 100644 static/freebsd/man9/random_harvest.9 4.html delete mode 100644 static/freebsd/man9/ratecheck.9 4.html delete mode 100644 static/freebsd/man9/redzone.9 4.html delete mode 100644 static/freebsd/man9/refcount.9 3.html delete mode 100644 static/freebsd/man9/regulator.9 4.html delete mode 100644 static/freebsd/man9/resettodr.9 4.html delete mode 100644 static/freebsd/man9/resource_int_value.9 4.html delete mode 100644 static/freebsd/man9/rijndael.9 3.html delete mode 100644 static/freebsd/man9/rman.9 4.html delete mode 100644 static/freebsd/man9/rmlock.9 4.html delete mode 100644 static/freebsd/man9/rtentry.9 3.html delete mode 100644 static/freebsd/man9/runqueue.9 3.html delete mode 100644 static/freebsd/man9/rwlock.9 4.html delete mode 100644 static/freebsd/man9/sbuf.9 4.html delete mode 100644 static/freebsd/man9/scheduler.9 4.html delete mode 100644 static/freebsd/man9/securelevel_gt.9 4.html delete mode 100644 static/freebsd/man9/selrecord.9 4.html delete mode 100644 static/freebsd/man9/sema.9 4.html delete mode 100644 static/freebsd/man9/seqc.9 4.html delete mode 100644 static/freebsd/man9/sf_buf.9 3.html delete mode 100644 static/freebsd/man9/sglist.9 4.html delete mode 100644 static/freebsd/man9/shm_map.9 4.html delete mode 100644 static/freebsd/man9/signal.9 4.html delete mode 100644 static/freebsd/man9/sleep.9 4.html delete mode 100644 static/freebsd/man9/sleepqueue.9 4.html delete mode 100644 static/freebsd/man9/smr.9 3.html delete mode 100644 static/freebsd/man9/socket.9 4.html delete mode 100644 static/freebsd/man9/stack.9 4.html delete mode 100644 static/freebsd/man9/store.9 4.html delete mode 100644 static/freebsd/man9/style.9 3.html delete mode 100644 static/freebsd/man9/style.lua.9 3.html delete mode 100644 static/freebsd/man9/superio.9 4.html delete mode 100644 static/freebsd/man9/swi.9 3.html delete mode 100644 static/freebsd/man9/sx.9 4.html delete mode 100644 static/freebsd/man9/syscall_helper_register.9 4.html delete mode 100644 static/freebsd/man9/sysctl.9 3.html delete mode 100644 static/freebsd/man9/sysctl_add_oid.9 3.html delete mode 100644 static/freebsd/man9/sysctl_ctx_init.9 3.html delete mode 100644 static/freebsd/man9/taskqueue.9 4.html delete mode 100644 static/freebsd/man9/tcp_functions.9 3.html delete mode 100644 static/freebsd/man9/thread_exit.9 4.html delete mode 100644 static/freebsd/man9/time.9 4.html delete mode 100644 static/freebsd/man9/tvtohz.9 4.html delete mode 100644 static/freebsd/man9/ucred.9 4.html delete mode 100644 static/freebsd/man9/uidinfo.9 4.html delete mode 100644 static/freebsd/man9/uio.9 3.html delete mode 100644 static/freebsd/man9/unr.9 4.html delete mode 100644 static/freebsd/man9/usbdi.9 3.html delete mode 100644 static/freebsd/man9/vaccess.9 3.html delete mode 100644 static/freebsd/man9/vaccess_acl_nfs4.9 3.html delete mode 100644 static/freebsd/man9/vaccess_acl_posix1e.9 3.html delete mode 100644 static/freebsd/man9/vflush.9 4.html delete mode 100644 static/freebsd/man9/vfs_busy.9 4.html delete mode 100644 static/freebsd/man9/vfs_getnewfsid.9 4.html delete mode 100644 static/freebsd/man9/vfs_getopt.9 4.html delete mode 100644 static/freebsd/man9/vfs_getvfs.9 4.html delete mode 100644 static/freebsd/man9/vfs_mountedfrom.9 4.html delete mode 100644 static/freebsd/man9/vfs_rootmountalloc.9 4.html delete mode 100644 static/freebsd/man9/vfs_suser.9 4.html delete mode 100644 static/freebsd/man9/vfs_timestamp.9 4.html delete mode 100644 static/freebsd/man9/vfs_unbusy.9 4.html delete mode 100644 static/freebsd/man9/vfs_unmountall.9 4.html delete mode 100644 static/freebsd/man9/vfsconf.9 3.html delete mode 100644 static/freebsd/man9/vget.9 4.html delete mode 100644 static/freebsd/man9/vgone.9 4.html delete mode 100644 static/freebsd/man9/vhold.9 4.html delete mode 100644 static/freebsd/man9/vinvalbuf.9 4.html delete mode 100644 static/freebsd/man9/vm_fault_prefault.9 4.html delete mode 100644 static/freebsd/man9/vm_map.9 4.html delete mode 100644 static/freebsd/man9/vm_map_check_protection.9 4.html delete mode 100644 static/freebsd/man9/vm_map_delete.9 4.html delete mode 100644 static/freebsd/man9/vm_map_entry_resize_free.9 3.html delete mode 100644 static/freebsd/man9/vm_map_find.9 3.html delete mode 100644 static/freebsd/man9/vm_map_findspace.9 4.html delete mode 100644 static/freebsd/man9/vm_map_inherit.9 4.html delete mode 100644 static/freebsd/man9/vm_map_init.9 4.html delete mode 100644 static/freebsd/man9/vm_map_insert.9 4.html delete mode 100644 static/freebsd/man9/vm_map_lock.9 4.html delete mode 100644 static/freebsd/man9/vm_map_lookup.9 3.html delete mode 100644 static/freebsd/man9/vm_map_madvise.9 4.html delete mode 100644 static/freebsd/man9/vm_map_max.9 4.html delete mode 100644 static/freebsd/man9/vm_map_protect.9 3.html delete mode 100644 static/freebsd/man9/vm_map_remove.9 4.html delete mode 100644 static/freebsd/man9/vm_map_stack.9 3.html delete mode 100644 static/freebsd/man9/vm_map_submap.9 3.html delete mode 100644 static/freebsd/man9/vm_map_sync.9 4.html delete mode 100644 static/freebsd/man9/vm_map_wire.9 3.html delete mode 100644 static/freebsd/man9/vm_page_aflag.9 4.html delete mode 100644 static/freebsd/man9/vm_page_alloc.9 4.html delete mode 100644 static/freebsd/man9/vm_page_bits.9 4.html delete mode 100644 static/freebsd/man9/vm_page_busy.9 4.html delete mode 100644 static/freebsd/man9/vm_page_deactivate.9 4.html delete mode 100644 static/freebsd/man9/vm_page_dontneed.9 4.html delete mode 100644 static/freebsd/man9/vm_page_free.9 3.html delete mode 100644 static/freebsd/man9/vm_page_grab.9 4.html delete mode 100644 static/freebsd/man9/vm_page_insert.9 4.html delete mode 100644 static/freebsd/man9/vm_page_lookup.9 4.html delete mode 100644 static/freebsd/man9/vm_page_rename.9 4.html delete mode 100644 static/freebsd/man9/vm_page_wire.9 4.html delete mode 100644 static/freebsd/man9/vm_set_page_size.9 4.html delete mode 100644 static/freebsd/man9/vmem.9 3.html delete mode 100644 static/freebsd/man9/vn_deallocate.9 4.html delete mode 100644 static/freebsd/man9/vn_fullpath.9 3.html delete mode 100644 static/freebsd/man9/vn_isdisk.9 4.html delete mode 100644 static/freebsd/man9/vnode.9 3.html delete mode 100644 static/freebsd/man9/vnode_pager_purge_range.9 4.html delete mode 100644 static/freebsd/man9/vnode_pager_setsize.9 4.html delete mode 100644 static/freebsd/man9/vref.9 4.html delete mode 100644 static/freebsd/man9/vrefcnt.9 4.html delete mode 100644 static/freebsd/man9/vrele.9 4.html delete mode 100644 static/freebsd/man9/vslock.9 4.html delete mode 100644 static/freebsd/man9/watchdog.9 4.html delete mode 100644 static/freebsd/man9/zero_region.9 4.html delete mode 100644 static/freebsd/man9/zone.9 3.html delete mode 100644 static/netbsd/man4/aac.4 4.html delete mode 100644 static/netbsd/man4/ac97.4 4.html delete mode 100644 static/netbsd/man4/acardide.4 4.html delete mode 100644 static/netbsd/man4/aceride.4 4.html delete mode 100644 static/netbsd/man4/acphy.4 4.html delete mode 100644 static/netbsd/man4/acpi.4 4.html delete mode 100644 static/netbsd/man4/acpiacad.4 4.html delete mode 100644 static/netbsd/man4/acpibat.4 4.html delete mode 100644 static/netbsd/man4/acpibut.4 4.html delete mode 100644 static/netbsd/man4/acpicpu.4 3.html delete mode 100644 static/netbsd/man4/acpidalb.4 4.html delete mode 100644 static/netbsd/man4/acpiec.4 4.html delete mode 100644 static/netbsd/man4/acpifan.4 3.html delete mode 100644 static/netbsd/man4/acpihed.4 4.html delete mode 100644 static/netbsd/man4/acpilid.4 4.html delete mode 100644 static/netbsd/man4/acpipmtr.4 4.html delete mode 100644 static/netbsd/man4/acpismbus.4 4.html delete mode 100644 static/netbsd/man4/acpitz.4 4.html delete mode 100644 static/netbsd/man4/acpivga.4 4.html delete mode 100644 static/netbsd/man4/acpivmgenid.4 4.html delete mode 100644 static/netbsd/man4/acpiwdrt.4 4.html delete mode 100644 static/netbsd/man4/acpiwmi.4 4.html delete mode 100644 static/netbsd/man4/adb.4 4.html delete mode 100644 static/netbsd/man4/adbbt.4 4.html delete mode 100644 static/netbsd/man4/adbkbd.4 4.html delete mode 100644 static/netbsd/man4/adbms.4 4.html delete mode 100644 static/netbsd/man4/adc.4 4.html delete mode 100644 static/netbsd/man4/adm1026hm.4 4.html delete mode 100644 static/netbsd/man4/admtemp.4 3.html delete mode 100644 static/netbsd/man4/adv.4 4.html delete mode 100644 static/netbsd/man4/adw.4 4.html delete mode 100644 static/netbsd/man4/age.4 4.html delete mode 100644 static/netbsd/man4/agp.4 4.html delete mode 100644 static/netbsd/man4/agr.4 4.html delete mode 100644 static/netbsd/man4/aha.4 4.html delete mode 100644 static/netbsd/man4/ahb.4 4.html delete mode 100644 static/netbsd/man4/ahc.4 3.html delete mode 100644 static/netbsd/man4/ahcisata.4 4.html delete mode 100644 static/netbsd/man4/ahd.4 3.html delete mode 100644 static/netbsd/man4/aht20temp.4 4.html delete mode 100644 static/netbsd/man4/ai.4 4.html delete mode 100644 static/netbsd/man4/aibs.4 3.html delete mode 100644 static/netbsd/man4/aic.4 4.html delete mode 100644 static/netbsd/man4/akbd.4 4.html delete mode 100644 static/netbsd/man4/alc.4 3.html delete mode 100644 static/netbsd/man4/ale.4 4.html delete mode 100644 static/netbsd/man4/alipm.4 4.html delete mode 100644 static/netbsd/man4/altmem.4 4.html delete mode 100644 static/netbsd/man4/altq.4 4.html delete mode 100644 static/netbsd/man4/am2315temp.4 4.html delete mode 100644 static/netbsd/man4/amdgpio.4 4.html delete mode 100644 static/netbsd/man4/amdpm.4 4.html delete mode 100644 static/netbsd/man4/amdtemp.4 4.html delete mode 100644 static/netbsd/man4/amhphy.4 4.html delete mode 100644 static/netbsd/man4/amr.4 4.html delete mode 100644 static/netbsd/man4/ams.4 3.html delete mode 100644 static/netbsd/man4/an.4 3.html delete mode 100644 static/netbsd/man4/apei.4 4.html delete mode 100644 static/netbsd/man4/aps.4 4.html delete mode 100644 static/netbsd/man4/aq.4 4.html delete mode 100644 static/netbsd/man4/arcmsr.4 3.html delete mode 100644 static/netbsd/man4/arcofi.4 4.html delete mode 100644 static/netbsd/man4/aria.4 4.html delete mode 100644 static/netbsd/man4/artsata.4 4.html delete mode 100644 static/netbsd/man4/ast.4 4.html delete mode 100644 static/netbsd/man4/asus.4 4.html delete mode 100644 static/netbsd/man4/ata.4 4.html delete mode 100644 static/netbsd/man4/atalk.4 4.html delete mode 100644 static/netbsd/man4/ataraid.4 4.html delete mode 100644 static/netbsd/man4/ate.4 4.html delete mode 100644 static/netbsd/man4/ath.4 3.html delete mode 100644 static/netbsd/man4/athn.4 3.html delete mode 100644 static/netbsd/man4/atphy.4 4.html delete mode 100644 static/netbsd/man4/atppc.4 4.html delete mode 100644 static/netbsd/man4/attimer.4 4.html delete mode 100644 static/netbsd/man4/atu.4 4.html delete mode 100644 static/netbsd/man4/atw.4 3.html delete mode 100644 static/netbsd/man4/auacer.4 4.html delete mode 100644 static/netbsd/man4/aubtfwl.4 3.html delete mode 100644 static/netbsd/man4/audio.4 3.html delete mode 100644 static/netbsd/man4/audiocs.4 4.html delete mode 100644 static/netbsd/man4/aue.4 4.html delete mode 100644 static/netbsd/man4/auich.4 4.html delete mode 100644 static/netbsd/man4/auixp.4 4.html delete mode 100644 static/netbsd/man4/autri.4 4.html delete mode 100644 static/netbsd/man4/auvia.4 4.html delete mode 100644 static/netbsd/man4/auvitek.4 4.html delete mode 100644 static/netbsd/man4/awi.4 3.html delete mode 100644 static/netbsd/man4/axe.4 4.html delete mode 100644 static/netbsd/man4/axen.4 4.html delete mode 100644 static/netbsd/man4/az.4 4.html delete mode 100644 static/netbsd/man4/battery_pmu.4 4.html delete mode 100644 static/netbsd/man4/bba.4 4.html delete mode 100644 static/netbsd/man4/bce.4 4.html delete mode 100644 static/netbsd/man4/bcsp.4 4.html delete mode 100644 static/netbsd/man4/be.4 4.html delete mode 100644 static/netbsd/man4/bge.4 3.html delete mode 100644 static/netbsd/man4/bha.4 4.html delete mode 100644 static/netbsd/man4/bio.4 4.html delete mode 100644 static/netbsd/man4/bktr.4 4.html delete mode 100644 static/netbsd/man4/bluetooth.4 4.html delete mode 100644 static/netbsd/man4/bmtphy.4 4.html delete mode 100644 static/netbsd/man4/bmx280thp.4 4.html delete mode 100644 static/netbsd/man4/bnx.4 4.html delete mode 100644 static/netbsd/man4/boca.4 4.html delete mode 100644 static/netbsd/man4/bochsfb.4 4.html delete mode 100644 static/netbsd/man4/bpf.4 3.html delete mode 100644 static/netbsd/man4/bpfjit.4 4.html delete mode 100644 static/netbsd/man4/brgphy.4 4.html delete mode 100644 static/netbsd/man4/bridge.4 3.html delete mode 100644 static/netbsd/man4/bt3c.4 4.html delete mode 100644 static/netbsd/man4/btbc.4 4.html delete mode 100644 static/netbsd/man4/bthidev.4 4.html delete mode 100644 static/netbsd/man4/bthub.4 4.html delete mode 100644 static/netbsd/man4/btkbd.4 4.html delete mode 100644 static/netbsd/man4/btmagic.4 3.html delete mode 100644 static/netbsd/man4/btms.4 4.html delete mode 100644 static/netbsd/man4/btsco.4 4.html delete mode 100644 static/netbsd/man4/btuart.4 4.html delete mode 100644 static/netbsd/man4/bwfm.4 4.html delete mode 100644 static/netbsd/man4/bwi.4 4.html delete mode 100644 static/netbsd/man4/cac.4 4.html delete mode 100644 static/netbsd/man4/can.4 4.html delete mode 100644 static/netbsd/man4/canloop.4 4.html delete mode 100644 static/netbsd/man4/cardbus.4 4.html delete mode 100644 static/netbsd/man4/carp.4 3.html delete mode 100644 static/netbsd/man4/cas.4 4.html delete mode 100644 static/netbsd/man4/ccd.4 3.html delete mode 100644 static/netbsd/man4/cd.4 4.html delete mode 100644 static/netbsd/man4/cdce.4 4.html delete mode 100644 static/netbsd/man4/cec.4 4.html delete mode 100644 static/netbsd/man4/cfb.4 4.html delete mode 100644 static/netbsd/man4/cgd.4 3.html delete mode 100644 static/netbsd/man4/ch.4 4.html delete mode 100644 static/netbsd/man4/chipsfb.4 4.html delete mode 100644 static/netbsd/man4/ciphy.4 4.html delete mode 100644 static/netbsd/man4/cir.4 4.html delete mode 100644 static/netbsd/man4/ciss.4 4.html delete mode 100644 static/netbsd/man4/clcs.4 4.html delete mode 100644 static/netbsd/man4/clct.4 4.html delete mode 100644 static/netbsd/man4/clockctl.4 4.html delete mode 100644 static/netbsd/man4/cmdide.4 4.html delete mode 100644 static/netbsd/man4/cmpci.4 4.html delete mode 100644 static/netbsd/man4/cms.4 4.html delete mode 100644 static/netbsd/man4/cnw.4 4.html delete mode 100644 static/netbsd/man4/com.4 4.html delete mode 100644 static/netbsd/man4/coram.4 4.html delete mode 100644 static/netbsd/man4/crypto.4 3.html delete mode 100644 static/netbsd/man4/cs.4 4.html delete mode 100644 static/netbsd/man4/cs80bus.4 4.html delete mode 100644 static/netbsd/man4/cuda.4 4.html delete mode 100644 static/netbsd/man4/cue.4 4.html delete mode 100644 static/netbsd/man4/cxdtv.4 4.html delete mode 100644 static/netbsd/man4/cy.4 4.html delete mode 100644 static/netbsd/man4/cypide.4 4.html delete mode 100644 static/netbsd/man4/cz.4 3.html delete mode 100644 static/netbsd/man4/dbcool.4 3.html delete mode 100644 static/netbsd/man4/ddb.4 4.html delete mode 100644 static/netbsd/man4/ddc.4 4.html delete mode 100644 static/netbsd/man4/dge.4 3.html delete mode 100644 static/netbsd/man4/dk.4 3.html delete mode 100644 static/netbsd/man4/dm.4 3.html delete mode 100644 static/netbsd/man4/dmoverio.4 4.html delete mode 100644 static/netbsd/man4/dmphy.4 3.html delete mode 100644 static/netbsd/man4/dpt.4 4.html delete mode 100644 static/netbsd/man4/dpti.4 4.html delete mode 100644 static/netbsd/man4/drm.4 4.html delete mode 100644 static/netbsd/man4/drum.4 4.html delete mode 100644 static/netbsd/man4/drvctl.4 4.html delete mode 100644 static/netbsd/man4/ds2482ow.4 4.html delete mode 100644 static/netbsd/man4/ds28e17iic.4 3.html delete mode 100644 static/netbsd/man4/dse.4 4.html delete mode 100644 static/netbsd/man4/dtide.4 4.html delete mode 100644 static/netbsd/man4/dtv.4 4.html delete mode 100644 static/netbsd/man4/dtviic.4 4.html delete mode 100644 static/netbsd/man4/dwctwo.4 4.html delete mode 100644 static/netbsd/man4/ea.4 4.html delete mode 100644 static/netbsd/man4/eap.4 4.html delete mode 100644 static/netbsd/man4/eb.4 4.html delete mode 100644 static/netbsd/man4/ebus.4 4.html delete mode 100644 static/netbsd/man4/ec.4 3.html delete mode 100644 static/netbsd/man4/edc.4 4.html delete mode 100644 static/netbsd/man4/ef.4 4.html delete mode 100644 static/netbsd/man4/eg.4 4.html delete mode 100644 static/netbsd/man4/ehci.4 4.html delete mode 100644 static/netbsd/man4/ei.4 4.html delete mode 100644 static/netbsd/man4/eisa.4 4.html delete mode 100644 static/netbsd/man4/el.4 4.html delete mode 100644 static/netbsd/man4/elmc.4 4.html delete mode 100644 static/netbsd/man4/emcfan.4 3.html delete mode 100644 static/netbsd/man4/emdtv.4 4.html delete mode 100644 static/netbsd/man4/emuxki.4 4.html delete mode 100644 static/netbsd/man4/ena.4 4.html delete mode 100644 static/netbsd/man4/envsys.4 3.html delete mode 100644 static/netbsd/man4/ep.4 3.html delete mode 100644 static/netbsd/man4/epic.4 4.html delete mode 100644 static/netbsd/man4/eqos.4 4.html delete mode 100644 static/netbsd/man4/esa.4 4.html delete mode 100644 static/netbsd/man4/esiop.4 4.html delete mode 100644 static/netbsd/man4/esm.4 4.html delete mode 100644 static/netbsd/man4/eso.4 4.html delete mode 100644 static/netbsd/man4/esp.4 4.html delete mode 100644 static/netbsd/man4/ess.4 4.html delete mode 100644 static/netbsd/man4/et.4 4.html delete mode 100644 static/netbsd/man4/etphy.4 4.html delete mode 100644 static/netbsd/man4/ex.4 4.html delete mode 100644 static/netbsd/man4/exphy.4 4.html delete mode 100644 static/netbsd/man4/faith.4 3.html delete mode 100644 static/netbsd/man4/fd.4 4.html delete mode 100644 static/netbsd/man4/finsio.4 4.html delete mode 100644 static/netbsd/man4/flash.4 4.html delete mode 100644 static/netbsd/man4/fms.4 4.html delete mode 100644 static/netbsd/man4/fmv.4 4.html delete mode 100644 static/netbsd/man4/fss.4 4.html delete mode 100644 static/netbsd/man4/fujbp.4 4.html delete mode 100644 static/netbsd/man4/full.4 4.html delete mode 100644 static/netbsd/man4/fwip.4 4.html delete mode 100644 static/netbsd/man4/fwohci.4 4.html delete mode 100644 static/netbsd/man4/fxp.4 4.html delete mode 100644 static/netbsd/man4/g760a.4 4.html delete mode 100644 static/netbsd/man4/gcscaudio.4 4.html delete mode 100644 static/netbsd/man4/gem.4 4.html delete mode 100644 static/netbsd/man4/genet.4 4.html delete mode 100644 static/netbsd/man4/genfb.4 4.html delete mode 100644 static/netbsd/man4/gentbi.4 4.html delete mode 100644 static/netbsd/man4/geodeide.4 4.html delete mode 100644 static/netbsd/man4/gif.4 3.html delete mode 100644 static/netbsd/man4/glxtphy.4 3.html delete mode 100644 static/netbsd/man4/gphyter.4 4.html delete mode 100644 static/netbsd/man4/gpib.4 4.html delete mode 100644 static/netbsd/man4/gpio.4 4.html delete mode 100644 static/netbsd/man4/gpioiic.4 4.html delete mode 100644 static/netbsd/man4/gpioirq.4 4.html delete mode 100644 static/netbsd/man4/gpiolock.4 4.html delete mode 100644 static/netbsd/man4/gpioow.4 4.html delete mode 100644 static/netbsd/man4/gpiopps.4 3.html delete mode 100644 static/netbsd/man4/gpiopwm.4 4.html delete mode 100644 static/netbsd/man4/gpiosim.4 4.html delete mode 100644 static/netbsd/man4/gre.4 3.html delete mode 100644 static/netbsd/man4/gscan.4 4.html delete mode 100644 static/netbsd/man4/gsip.4 4.html delete mode 100644 static/netbsd/man4/gtp.4 4.html delete mode 100644 static/netbsd/man4/gus.4 3.html delete mode 100644 static/netbsd/man4/guspnp.4 4.html delete mode 100644 static/netbsd/man4/hcide.4 4.html delete mode 100644 static/netbsd/man4/hdaudio.4 4.html delete mode 100644 static/netbsd/man4/hifn.4 4.html delete mode 100644 static/netbsd/man4/hil.4 4.html delete mode 100644 static/netbsd/man4/hilid.4 4.html delete mode 100644 static/netbsd/man4/hilkbd.4 4.html delete mode 100644 static/netbsd/man4/hilms.4 4.html delete mode 100644 static/netbsd/man4/hme.4 4.html delete mode 100644 static/netbsd/man4/hpacel.4 4.html delete mode 100644 static/netbsd/man4/hpqlb.4 4.html delete mode 100644 static/netbsd/man4/hptide.4 4.html delete mode 100644 static/netbsd/man4/hvn.4 4.html delete mode 100644 static/netbsd/man4/hythygtemp.4 4.html delete mode 100644 static/netbsd/man4/iavf.4 4.html delete mode 100644 static/netbsd/man4/ibmcd.4 4.html delete mode 100644 static/netbsd/man4/ibmhawk.4 4.html delete mode 100644 static/netbsd/man4/ichsmb.4 4.html delete mode 100644 static/netbsd/man4/icmp.4 3.html delete mode 100644 static/netbsd/man4/icmp6.4 4.html delete mode 100644 static/netbsd/man4/icp.4 4.html delete mode 100644 static/netbsd/man4/icsphy.4 4.html delete mode 100644 static/netbsd/man4/iee.4 4.html delete mode 100644 static/netbsd/man4/ieee1394if.4 4.html delete mode 100644 static/netbsd/man4/ieee80211.4 3.html delete mode 100644 static/netbsd/man4/ietp.4 4.html delete mode 100644 static/netbsd/man4/ifmedia.4 4.html delete mode 100644 static/netbsd/man4/igc.4 4.html delete mode 100644 static/netbsd/man4/igmafb.4 4.html delete mode 100644 static/netbsd/man4/igphy.4 4.html delete mode 100644 static/netbsd/man4/igpio.4 4.html delete mode 100644 static/netbsd/man4/igsfb.4 4.html delete mode 100644 static/netbsd/man4/iha.4 4.html delete mode 100644 static/netbsd/man4/ihidev.4 4.html delete mode 100644 static/netbsd/man4/ihphy.4 4.html delete mode 100644 static/netbsd/man4/iic.4 4.html delete mode 100644 static/netbsd/man4/ikphy.4 4.html delete mode 100644 static/netbsd/man4/ims.4 4.html delete mode 100644 static/netbsd/man4/inet.4 4.html delete mode 100644 static/netbsd/man4/inet6.4 3.html delete mode 100644 static/netbsd/man4/inphy.4 4.html delete mode 100644 static/netbsd/man4/intersil7170.4 4.html delete mode 100644 static/netbsd/man4/intro.4 3.html delete mode 100644 static/netbsd/man4/ioasic.4 4.html delete mode 100644 static/netbsd/man4/ioat.4 4.html delete mode 100644 static/netbsd/man4/iop.4 2.html delete mode 100644 static/netbsd/man4/iophy.4 4.html delete mode 100644 static/netbsd/man4/iopsp.4 4.html delete mode 100644 static/netbsd/man4/ip.4 3.html delete mode 100644 static/netbsd/man4/ip6.4 3.html delete mode 100644 static/netbsd/man4/ipgphy.4 4.html delete mode 100644 static/netbsd/man4/ipmi.4 4.html delete mode 100644 static/netbsd/man4/ipsec.4 3.html delete mode 100644 static/netbsd/man4/ipsecif.4 3.html delete mode 100644 static/netbsd/man4/ipw.4 4.html delete mode 100644 static/netbsd/man4/irframe.4 4.html delete mode 100644 static/netbsd/man4/irframetty.4 4.html delete mode 100644 static/netbsd/man4/irmce.4 4.html delete mode 100644 static/netbsd/man4/isa.4 4.html delete mode 100644 static/netbsd/man4/isapnp.4 4.html delete mode 100644 static/netbsd/man4/ismt.4 4.html delete mode 100644 static/netbsd/man4/isp.4 4.html delete mode 100644 static/netbsd/man4/isv.4 3.html delete mode 100644 static/netbsd/man4/iteide.4 4.html delete mode 100644 static/netbsd/man4/itesio.4 4.html delete mode 100644 static/netbsd/man4/iwi.4 4.html delete mode 100644 static/netbsd/man4/iwm.4 4.html delete mode 100644 static/netbsd/man4/iwn.4 3.html delete mode 100644 static/netbsd/man4/ix.4 4.html delete mode 100644 static/netbsd/man4/ixg.4 4.html delete mode 100644 static/netbsd/man4/ixl.4 4.html delete mode 100644 static/netbsd/man4/ixpide.4 4.html delete mode 100644 static/netbsd/man4/ixv.4 4.html delete mode 100644 static/netbsd/man4/iy.4 4.html delete mode 100644 static/netbsd/man4/jme.4 3.html delete mode 100644 static/netbsd/man4/jmide.4 4.html delete mode 100644 static/netbsd/man4/jmphy.4 4.html delete mode 100644 static/netbsd/man4/joy.4 4.html delete mode 100644 static/netbsd/man4/kcov.4 3.html delete mode 100644 static/netbsd/man4/kloader.4 4.html delete mode 100644 static/netbsd/man4/kse.4 4.html delete mode 100644 static/netbsd/man4/ksyms.4 4.html delete mode 100644 static/netbsd/man4/kttcp.4 4.html delete mode 100644 static/netbsd/man4/kue.4 4.html delete mode 100644 static/netbsd/man4/l2tp.4 3.html delete mode 100644 static/netbsd/man4/lagg.4 3.html delete mode 100644 static/netbsd/man4/lc.4 4.html delete mode 100644 static/netbsd/man4/ld.4 4.html delete mode 100644 static/netbsd/man4/le.4 4.html delete mode 100644 static/netbsd/man4/lii.4 4.html delete mode 100644 static/netbsd/man4/lm.4 4.html delete mode 100644 static/netbsd/man4/lmenv.4 4.html delete mode 100644 static/netbsd/man4/lmtemp.4 3.html delete mode 100644 static/netbsd/man4/lo.4 4.html delete mode 100644 static/netbsd/man4/lpt.4 4.html delete mode 100644 static/netbsd/man4/lua.4 4.html delete mode 100644 static/netbsd/man4/lxtphy.4 4.html delete mode 100644 static/netbsd/man4/m25p.4 4.html delete mode 100644 static/netbsd/man4/machfb.4 4.html delete mode 100644 static/netbsd/man4/mainbus.4 4.html delete mode 100644 static/netbsd/man4/makphy.4 4.html delete mode 100644 static/netbsd/man4/malo.4 4.html delete mode 100644 static/netbsd/man4/man4.alpha/intro.4 2.html delete mode 100644 static/netbsd/man4/man4.alpha/jensenio.4 3.html delete mode 100644 static/netbsd/man4/man4.alpha/tlsb.4 3.html delete mode 100644 static/netbsd/man4/man4.alpha/tsciic.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/a34kbbc.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/afsc.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/ahsc.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/bppcsc.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/cv3dpb.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/drbbc.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/efa.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/em4k.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/grfcv3d.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/grfrh.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/grful.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/intro.4 2.html delete mode 100644 static/netbsd/man4/man4.amiga/mfcs.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/p5pb.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/xsh.4 3.html delete mode 100644 static/netbsd/man4/man4.amiga/zssc.4 3.html delete mode 100644 static/netbsd/man4/man4.arc/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.atari/floppy.4 3.html delete mode 100644 static/netbsd/man4/man4.atari/intro.4 2.html delete mode 100644 static/netbsd/man4/man4.atari/rtc.4 3.html delete mode 100644 static/netbsd/man4/man4.dreamcast/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.dreamcast/maple.4 3.html delete mode 100644 static/netbsd/man4/man4.dreamcast/mlcd.4 3.html delete mode 100644 static/netbsd/man4/man4.emips/autoconf.4 3.html delete mode 100644 static/netbsd/man4/man4.emips/ebus.4 3.html delete mode 100644 static/netbsd/man4/man4.emips/enic.4 3.html delete mode 100644 static/netbsd/man4/man4.evbarm/awge.4 3.html delete mode 100644 static/netbsd/man4/man4.evbarm/cpsw.4 3.html delete mode 100644 static/netbsd/man4/man4.evbarm/gxio.4 3.html delete mode 100644 static/netbsd/man4/man4.evbarm/iopaau.4 3.html delete mode 100644 static/netbsd/man4/man4.evbarm/vcaudio.4 3.html delete mode 100644 static/netbsd/man4/man4.evbmips/cnmac.4 3.html delete mode 100644 static/netbsd/man4/man4.evbppc/intro_pmppc.4 3.html delete mode 100644 static/netbsd/man4/man4.evbppc/rtc.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/autoconf.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/ct.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/dcm.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/dnkbd.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/gbox.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/ppi.4 3.html delete mode 100644 static/netbsd/man4/man4.hp300/topcat.4 3.html delete mode 100644 static/netbsd/man4/man4.hpcarm/intro.4 2.html delete mode 100644 static/netbsd/man4/man4.hpcarm/j720lcd.4 3.html delete mode 100644 static/netbsd/man4/man4.hpcsh/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.hpcsh/psh3tp.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/asp.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/astro.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/dino.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/elroy.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/harmony.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/mem.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/ssio.4 3.html delete mode 100644 static/netbsd/man4/man4.hppa/uturn.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/cmos.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/elanpar.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/elanpex.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/elansc.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/mms.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/pcibios.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/rdcide.4 3.html delete mode 100644 static/netbsd/man4/man4.i386/rdcpcib.4 3.html delete mode 100644 static/netbsd/man4/man4.mac68k/cpi.4 3.html delete mode 100644 static/netbsd/man4/man4.mac68k/iwm.4 3.html delete mode 100644 static/netbsd/man4/man4.mac68k/netdock.4 3.html delete mode 100644 static/netbsd/man4/man4.mac68k/obio.4 3.html delete mode 100644 static/netbsd/man4/man4.mac68k/pbbat.4 3.html delete mode 100644 static/netbsd/man4/man4.mac68k/zsc.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/awacs.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/bm.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/gm.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/intro.4 2.html delete mode 100644 static/netbsd/man4/man4.macppc/mesh.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/obio.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/pbms.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/platinumfb.4 3.html delete mode 100644 static/netbsd/man4/man4.macppc/snapper.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/clmpcc.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/mem.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/memc.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/ncrsc.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/pcc.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/pcctwo.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/wdsc.4 3.html delete mode 100644 static/netbsd/man4/man4.mvme68k/zsc.4 3.html delete mode 100644 static/netbsd/man4/man4.pmax/asc.4 3.html delete mode 100644 static/netbsd/man4/man4.pmax/autoconf.4 3.html delete mode 100644 static/netbsd/man4/man4.pmax/ibus.4 3.html delete mode 100644 static/netbsd/man4/man4.pmax/intro.4 2.html delete mode 100644 static/netbsd/man4/man4.pmax/pm.4 3.html delete mode 100644 static/netbsd/man4/man4.pmax/sii.4 3.html delete mode 100644 static/netbsd/man4/man4.pmax/xcfb.4 3.html delete mode 100644 static/netbsd/man4/man4.prep/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.prep/nvram.4 3.html delete mode 100644 static/netbsd/man4/man4.sandpoint/nhpow.4 3.html delete mode 100644 static/netbsd/man4/man4.sandpoint/satmgr.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/crime.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/dpclock.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/dsclock.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/gio.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/giopci.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/grtwo.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/haltwo.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/hpc.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/imc.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/light.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/mace.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/mavb.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/mec.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/newport.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/pic.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/sq.4 3.html delete mode 100644 static/netbsd/man4/man4.sgimips/wdsc.4 3.html delete mode 100644 static/netbsd/man4/man4.sparc/apc.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/audioamd.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/autoconf.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/auxreg.4 3.html delete mode 100644 static/netbsd/man4/man4.sparc/bpp.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/bwtwo.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/cgeight.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/cgfour.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/cgfourteen.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/cgsix.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/cgthree.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/cgtwo.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/clock.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/dbri.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/fd.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/ie.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.sparc/kbd.4 3.html delete mode 100644 static/netbsd/man4/man4.sparc/magma.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/mem.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/ms.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/nell.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/openprom.4 3.html delete mode 100644 static/netbsd/man4/man4.sparc/pnozz.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/tctrl.4 3.html delete mode 100644 static/netbsd/man4/man4.sparc/tcx.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/timer.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/tslot.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/xd.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/xy.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc/zx.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/envctrl.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/fdc.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/ffb.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/intro.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/lom.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/psycho.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/pyro.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/sab.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/schizo.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/tadpmu.4 4.html delete mode 100644 static/netbsd/man4/man4.sparc64/tda.4 3.html delete mode 100644 static/netbsd/man4/man4.sun2/autoconf.4 4.html delete mode 100644 static/netbsd/man4/man4.sun2/bwtwo.4 4.html delete mode 100644 static/netbsd/man4/man4.sun2/ec.4 4.html delete mode 100644 static/netbsd/man4/man4.sun2/ie.4 4.html delete mode 100644 static/netbsd/man4/man4.sun2/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.sun2/kbd.4 3.html delete mode 100644 static/netbsd/man4/man4.sun2/leds.4 3.html delete mode 100644 static/netbsd/man4/man4.sun2/mem.4 4.html delete mode 100644 static/netbsd/man4/man4.sun2/ms.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/autoconf.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/bwtwo.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/cgfour.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/cgtwo.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/fd.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/ie.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/intro.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/kbd.4 3.html delete mode 100644 static/netbsd/man4/man4.sun3/leds.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/mem.4 4.html delete mode 100644 static/netbsd/man4/man4.sun3/ms.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/acc.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ad.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/asc.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/autoconf.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/cons.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/covid.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/crl.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/css.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/ct.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ddn.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/de.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dh.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dhu.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dl.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dmc.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dmf.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dmv.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dmz.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dn.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/dz.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ec.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/en.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ex.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/fl.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/hdh.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/hk.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/hp.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ht.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/hy.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ik.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/il.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/ix.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/kg.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/lp.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/mem.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/mt.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/mtc.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/np.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/pcl.4 2.html delete mode 100644 static/netbsd/man4/man4.vax/ps.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/qe.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/qt.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/rf.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/rl.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/tm.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ts.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/tu.4 3.html delete mode 100644 static/netbsd/man4/man4.vax/uda.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/up.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/ut.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/uu.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/va.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/vp.4 4.html delete mode 100644 static/netbsd/man4/man4.vax/vv.4 4.html delete mode 100644 static/netbsd/man4/man4.x68k/bmd.4 4.html delete mode 100644 static/netbsd/man4/man4.x68k/intio.4 4.html delete mode 100644 static/netbsd/man4/man4.x68k/intro.4 3.html delete mode 100644 static/netbsd/man4/man4.x68k/mfp.4 4.html delete mode 100644 static/netbsd/man4/man4.x68k/neptune.4 4.html delete mode 100644 static/netbsd/man4/man4.x68k/powsw.4 4.html delete mode 100644 static/netbsd/man4/man4.x68k/vs.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/amdccp.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/amdpcib.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/amdsmn.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/amdzentemp.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/apic.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/autoconf.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/balloon.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/console.4 3.html delete mode 100644 static/netbsd/man4/man4.x86/coretemp.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/est.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/fdc.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/fwhrng.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/hpet.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/ichlpcib.4 3.html delete mode 100644 static/netbsd/man4/man4.x86/imcsmb.4 3.html delete mode 100644 static/netbsd/man4/man4.x86/lpt.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/mem.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/odcm.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/powernow.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/soekrisgpio.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/tco.4 4.html delete mode 100644 static/netbsd/man4/man4.x86/viac7temp.4 4.html delete mode 100644 static/netbsd/man4/mbe.4 4.html delete mode 100644 static/netbsd/man4/mc.4 4.html delete mode 100644 static/netbsd/man4/mca.4 4.html delete mode 100644 static/netbsd/man4/mcclock.4 4.html delete mode 100644 static/netbsd/man4/mcd.4 4.html delete mode 100644 static/netbsd/man4/mcommphy.4 4.html delete mode 100644 static/netbsd/man4/mcp3kadc.4 4.html delete mode 100644 static/netbsd/man4/mcp48x1dac.4 4.html delete mode 100644 static/netbsd/man4/mcp980x.4 4.html delete mode 100644 static/netbsd/man4/mcpgpio.4 4.html delete mode 100644 static/netbsd/man4/mcx.4 3.html delete mode 100644 static/netbsd/man4/md.4 4.html delete mode 100644 static/netbsd/man4/mfb.4 4.html delete mode 100644 static/netbsd/man4/mfi.4 4.html delete mode 100644 static/netbsd/man4/mfii.4 4.html delete mode 100644 static/netbsd/man4/mhzc.4 4.html delete mode 100644 static/netbsd/man4/micphy.4 4.html delete mode 100644 static/netbsd/man4/midi.4 3.html delete mode 100644 static/netbsd/man4/mii.4 3.html delete mode 100644 static/netbsd/man4/mk48txx.4 4.html delete mode 100644 static/netbsd/man4/mlx.4 4.html delete mode 100644 static/netbsd/man4/mly.4 4.html delete mode 100644 static/netbsd/man4/mos.4 4.html delete mode 100644 static/netbsd/man4/mpii.4 4.html delete mode 100644 static/netbsd/man4/mpl115a.4 4.html delete mode 100644 static/netbsd/man4/mpls.4 3.html delete mode 100644 static/netbsd/man4/mpt.4 4.html delete mode 100644 static/netbsd/man4/mpu.4 4.html delete mode 100644 static/netbsd/man4/msm6242b.4 4.html delete mode 100644 static/netbsd/man4/mtd.4 4.html delete mode 100644 static/netbsd/man4/mtio.4 3.html delete mode 100644 static/netbsd/man4/mue.4 4.html delete mode 100644 static/netbsd/man4/multicast.4 3.html delete mode 100644 static/netbsd/man4/mvsata.4 4.html delete mode 100644 static/netbsd/man4/nadb.4 4.html delete mode 100644 static/netbsd/man4/nca.4 4.html delete mode 100644 static/netbsd/man4/ncm.4 4.html delete mode 100644 static/netbsd/man4/nct.4 4.html delete mode 100644 static/netbsd/man4/ne.4 4.html delete mode 100644 static/netbsd/man4/neo.4 4.html delete mode 100644 static/netbsd/man4/netintro.4 3.html delete mode 100644 static/netbsd/man4/nfe.4 4.html delete mode 100644 static/netbsd/man4/nfsmb.4 4.html delete mode 100644 static/netbsd/man4/njata.4 4.html delete mode 100644 static/netbsd/man4/njs.4 4.html delete mode 100644 static/netbsd/man4/npflog.4 4.html delete mode 100644 static/netbsd/man4/nsclpcsio.4 4.html delete mode 100644 static/netbsd/man4/nside.4 4.html delete mode 100644 static/netbsd/man4/nsphy.4 4.html delete mode 100644 static/netbsd/man4/nsphyter.4 4.html delete mode 100644 static/netbsd/man4/ntwoc.4 3.html delete mode 100644 static/netbsd/man4/null.4 4.html delete mode 100644 static/netbsd/man4/nvme.4 3.html delete mode 100644 static/netbsd/man4/nvmm.4 4.html delete mode 100644 static/netbsd/man4/oak.4 4.html delete mode 100644 static/netbsd/man4/oboe.4 4.html delete mode 100644 static/netbsd/man4/ofisa.4 4.html delete mode 100644 static/netbsd/man4/ohci.4 4.html delete mode 100644 static/netbsd/man4/onewire.4 4.html delete mode 100644 static/netbsd/man4/oosiop.4 3.html delete mode 100644 static/netbsd/man4/opl.4 4.html delete mode 100644 static/netbsd/man4/optiide.4 4.html delete mode 100644 static/netbsd/man4/options.4 3.html delete mode 100644 static/netbsd/man4/osiop.4 4.html delete mode 100644 static/netbsd/man4/otus.4 3.html delete mode 100644 static/netbsd/man4/owtemp.4 4.html delete mode 100644 static/netbsd/man4/pad.4 4.html delete mode 100644 static/netbsd/man4/pas.4 4.html delete mode 100644 static/netbsd/man4/pcdisplay.4 4.html delete mode 100644 static/netbsd/man4/pcf8563rtc.4 4.html delete mode 100644 static/netbsd/man4/pchtemp.4 4.html delete mode 100644 static/netbsd/man4/pci.4 3.html delete mode 100644 static/netbsd/man4/pciback.4 3.html delete mode 100644 static/netbsd/man4/pcic.4 4.html delete mode 100644 static/netbsd/man4/pciide.4 3.html delete mode 100644 static/netbsd/man4/pckbc.4 4.html delete mode 100644 static/netbsd/man4/pckbd.4 4.html delete mode 100644 static/netbsd/man4/pcmcia.4 4.html delete mode 100644 static/netbsd/man4/pcmcom.4 4.html delete mode 100644 static/netbsd/man4/pcn.4 4.html delete mode 100644 static/netbsd/man4/pcppi.4 4.html delete mode 100644 static/netbsd/man4/pcscp.4 3.html delete mode 100644 static/netbsd/man4/pcweasel.4 3.html delete mode 100644 static/netbsd/man4/pdcide.4 3.html delete mode 100644 static/netbsd/man4/pdcsata.4 4.html delete mode 100644 static/netbsd/man4/piixide.4 4.html delete mode 100644 static/netbsd/man4/piixpcib.4 4.html delete mode 100644 static/netbsd/man4/piixpm.4 4.html delete mode 100644 static/netbsd/man4/pim.4 3.html delete mode 100644 static/netbsd/man4/plip.4 4.html delete mode 100644 static/netbsd/man4/pm3fb.4 4.html delete mode 100644 static/netbsd/man4/pms.4 3.html delete mode 100644 static/netbsd/man4/pmu.4 4.html delete mode 100644 static/netbsd/man4/pnaphy.4 4.html delete mode 100644 static/netbsd/man4/podulebus.4 4.html delete mode 100644 static/netbsd/man4/ppbus.4 4.html delete mode 100644 static/netbsd/man4/ppi.4 4.html delete mode 100644 static/netbsd/man4/ppp.4 4.html delete mode 100644 static/netbsd/man4/pppoe.4 3.html delete mode 100644 static/netbsd/man4/pseye.4 4.html delete mode 100644 static/netbsd/man4/ptcd.4 4.html delete mode 100644 static/netbsd/man4/ptm.4 4.html delete mode 100644 static/netbsd/man4/pty.4 3.html delete mode 100644 static/netbsd/man4/puc.4 4.html delete mode 100644 static/netbsd/man4/pud.4 4.html delete mode 100644 static/netbsd/man4/puffs.4 4.html delete mode 100644 static/netbsd/man4/pv.4 3.html delete mode 100644 static/netbsd/man4/pwdog.4 4.html delete mode 100644 static/netbsd/man4/px.4 4.html delete mode 100644 static/netbsd/man4/pxagpio.4 4.html delete mode 100644 static/netbsd/man4/pxaip.4 4.html delete mode 100644 static/netbsd/man4/pxg.4 4.html delete mode 100644 static/netbsd/man4/qat.4 4.html delete mode 100644 static/netbsd/man4/qe.4 4.html delete mode 100644 static/netbsd/man4/qec.4 4.html delete mode 100644 static/netbsd/man4/qemufwcfg.4 4.html delete mode 100644 static/netbsd/man4/qsphy.4 4.html delete mode 100644 static/netbsd/man4/r128fb.4 4.html delete mode 100644 static/netbsd/man4/radeonfb.4 4.html delete mode 100644 static/netbsd/man4/radio.4 4.html delete mode 100644 static/netbsd/man4/raid.4 3.html delete mode 100644 static/netbsd/man4/ral.4 3.html delete mode 100644 static/netbsd/man4/ray.4 4.html delete mode 100644 static/netbsd/man4/rcons.4 4.html delete mode 100644 static/netbsd/man4/rdcphy.4 4.html delete mode 100644 static/netbsd/man4/re.4 3.html delete mode 100644 static/netbsd/man4/rge.4 4.html delete mode 100644 static/netbsd/man4/rgephy.4 4.html delete mode 100644 static/netbsd/man4/rlphy.4 4.html delete mode 100644 static/netbsd/man4/rnd.4 3.html delete mode 100644 static/netbsd/man4/route.4 3.html delete mode 100644 static/netbsd/man4/rs5c372rtc.4 4.html delete mode 100644 static/netbsd/man4/rt.4 4.html delete mode 100644 static/netbsd/man4/rtfps.4 4.html delete mode 100644 static/netbsd/man4/rtii.4 4.html delete mode 100644 static/netbsd/man4/rtk.4 4.html delete mode 100644 static/netbsd/man4/rtsx.4 4.html delete mode 100644 static/netbsd/man4/rtw.4 3.html delete mode 100644 static/netbsd/man4/rtwn.4 4.html delete mode 100644 static/netbsd/man4/rum.4 3.html delete mode 100644 static/netbsd/man4/run.4 4.html delete mode 100644 static/netbsd/man4/s390rtc.4 4.html delete mode 100644 static/netbsd/man4/satalink.4 4.html delete mode 100644 static/netbsd/man4/sb.4 4.html delete mode 100644 static/netbsd/man4/sbp.4 4.html delete mode 100644 static/netbsd/man4/sbt.4 4.html delete mode 100644 static/netbsd/man4/sbus.4 4.html delete mode 100644 static/netbsd/man4/sc.4 4.html delete mode 100644 static/netbsd/man4/sc16is7xx.4 2.html delete mode 100644 static/netbsd/man4/schide.4 4.html delete mode 100644 static/netbsd/man4/scmd.4 4.html delete mode 100644 static/netbsd/man4/scmdi2c.4 4.html delete mode 100644 static/netbsd/man4/scmdspi.4 4.html delete mode 100644 static/netbsd/man4/scsi.4 4.html delete mode 100644 static/netbsd/man4/sctp.4 3.html delete mode 100644 static/netbsd/man4/sd.4 3.html delete mode 100644 static/netbsd/man4/sdhc.4 4.html delete mode 100644 static/netbsd/man4/sdmmc.4 4.html delete mode 100644 static/netbsd/man4/sdtemp.4 3.html delete mode 100644 static/netbsd/man4/se.4 4.html delete mode 100644 static/netbsd/man4/sea.4 4.html delete mode 100644 static/netbsd/man4/sec.4 4.html delete mode 100644 static/netbsd/man4/seeprom.4 4.html delete mode 100644 static/netbsd/man4/sem.4 4.html delete mode 100644 static/netbsd/man4/ses.4 4.html delete mode 100644 static/netbsd/man4/sf.4 4.html delete mode 100644 static/netbsd/man4/sf2r.4 4.html delete mode 100644 static/netbsd/man4/sfb.4 4.html delete mode 100644 static/netbsd/man4/sgp40mox.4 3.html delete mode 100644 static/netbsd/man4/sgsmix.4 4.html delete mode 100644 static/netbsd/man4/shb.4 3.html delete mode 100644 static/netbsd/man4/shmif.4 4.html delete mode 100644 static/netbsd/man4/shpcic.4 4.html delete mode 100644 static/netbsd/man4/sht3xtemp.4 3.html delete mode 100644 static/netbsd/man4/sht4xtemp.4 4.html delete mode 100644 static/netbsd/man4/si.4 4.html delete mode 100644 static/netbsd/man4/si70xxtemp.4 3.html delete mode 100644 static/netbsd/man4/siisata.4 4.html delete mode 100644 static/netbsd/man4/siop.4 4.html delete mode 100644 static/netbsd/man4/sip.4 4.html delete mode 100644 static/netbsd/man4/siside.4 4.html delete mode 100644 static/netbsd/man4/sk.4 3.html delete mode 100644 static/netbsd/man4/sl.4 4.html delete mode 100644 static/netbsd/man4/slhci.4 4.html delete mode 100644 static/netbsd/man4/slide.4 4.html delete mode 100644 static/netbsd/man4/slurm.4 4.html delete mode 100644 static/netbsd/man4/sm.4 4.html delete mode 100644 static/netbsd/man4/smsc.4 4.html delete mode 100644 static/netbsd/man4/smscmon.4 4.html delete mode 100644 static/netbsd/man4/smscphy.4 4.html delete mode 100644 static/netbsd/man4/smsh.4 4.html delete mode 100644 static/netbsd/man4/sn.4 4.html delete mode 100644 static/netbsd/man4/sony.4 4.html delete mode 100644 static/netbsd/man4/spc.4 4.html delete mode 100644 static/netbsd/man4/spdmem.4 4.html delete mode 100644 static/netbsd/man4/speaker.4 3.html delete mode 100644 static/netbsd/man4/spi.4 4.html delete mode 100644 static/netbsd/man4/spif.4 4.html delete mode 100644 static/netbsd/man4/sqphy.4 4.html delete mode 100644 static/netbsd/man4/srt.4 3.html delete mode 100644 static/netbsd/man4/ss.4 4.html delete mode 100644 static/netbsd/man4/ssdfb.4 4.html delete mode 100644 static/netbsd/man4/st.4 3.html delete mode 100644 static/netbsd/man4/ste.4 4.html delete mode 100644 static/netbsd/man4/stf.4 3.html delete mode 100644 static/netbsd/man4/stge.4 4.html delete mode 100644 static/netbsd/man4/sti.4 4.html delete mode 100644 static/netbsd/man4/stpcide.4 4.html delete mode 100644 static/netbsd/man4/stuirda.4 4.html delete mode 100644 static/netbsd/man4/sv.4 4.html delete mode 100644 static/netbsd/man4/svwsata.4 4.html delete mode 100644 static/netbsd/man4/swsensor.4 4.html delete mode 100644 static/netbsd/man4/swwdog.4 4.html delete mode 100644 static/netbsd/man4/sysmon.4 4.html delete mode 100644 static/netbsd/man4/tap.4 3.html delete mode 100644 static/netbsd/man4/tc.4 4.html delete mode 100644 static/netbsd/man4/tcds.4 4.html delete mode 100644 static/netbsd/man4/tcic.4 4.html delete mode 100644 static/netbsd/man4/tcom.4 4.html delete mode 100644 static/netbsd/man4/tcp.4 3.html delete mode 100644 static/netbsd/man4/tcu.4 4.html delete mode 100644 static/netbsd/man4/tdvfb.4 4.html delete mode 100644 static/netbsd/man4/tea5767radio.4 4.html delete mode 100644 static/netbsd/man4/termios.4 4.html delete mode 100644 static/netbsd/man4/tfb.4 4.html delete mode 100644 static/netbsd/man4/thinkpad.4 4.html delete mode 100644 static/netbsd/man4/ti.4 4.html delete mode 100644 static/netbsd/man4/tl.4 4.html delete mode 100644 static/netbsd/man4/tlp.4 4.html delete mode 100644 static/netbsd/man4/tlphy.4 4.html delete mode 100644 static/netbsd/man4/tm121temp.4 4.html delete mode 100644 static/netbsd/man4/tpm.4 4.html delete mode 100644 static/netbsd/man4/tprof.4 4.html delete mode 100644 static/netbsd/man4/tps65217pmic.4 4.html delete mode 100644 static/netbsd/man4/tqphy.4 4.html delete mode 100644 static/netbsd/man4/tra.4 4.html delete mode 100644 static/netbsd/man4/trm.4 4.html delete mode 100644 static/netbsd/man4/tsllux.4 4.html delete mode 100644 static/netbsd/man4/tty.4 2.html delete mode 100644 static/netbsd/man4/tun.4 4.html delete mode 100644 static/netbsd/man4/twa.4 4.html delete mode 100644 static/netbsd/man4/twe.4 4.html delete mode 100644 static/netbsd/man4/txp.4 4.html delete mode 100644 static/netbsd/man4/u3g.4 4.html delete mode 100644 static/netbsd/man4/ualea.4 4.html delete mode 100644 static/netbsd/man4/uark.4 4.html delete mode 100644 static/netbsd/man4/uatp.4 3.html delete mode 100644 static/netbsd/man4/uaudio.4 4.html delete mode 100644 static/netbsd/man4/uberry.4 4.html delete mode 100644 static/netbsd/man4/ubsa.4 4.html delete mode 100644 static/netbsd/man4/ubsec.4 4.html delete mode 100644 static/netbsd/man4/ubt.4 4.html delete mode 100644 static/netbsd/man4/uchcom.4 4.html delete mode 100644 static/netbsd/man4/ucom.4 4.html delete mode 100644 static/netbsd/man4/ucycom.4 3.html delete mode 100644 static/netbsd/man4/udav.4 4.html delete mode 100644 static/netbsd/man4/udl.4 4.html delete mode 100644 static/netbsd/man4/udp.4 4.html delete mode 100644 static/netbsd/man4/udsbr.4 4.html delete mode 100644 static/netbsd/man4/uep.4 4.html delete mode 100644 static/netbsd/man4/uftdi.4 4.html delete mode 100644 static/netbsd/man4/ug.4 4.html delete mode 100644 static/netbsd/man4/ugen.4 3.html delete mode 100644 static/netbsd/man4/ugensa.4 4.html delete mode 100644 static/netbsd/man4/uha.4 4.html delete mode 100644 static/netbsd/man4/uhci.4 4.html delete mode 100644 static/netbsd/man4/uhid.4 3.html delete mode 100644 static/netbsd/man4/uhidev.4 3.html delete mode 100644 static/netbsd/man4/uhmodem.4 3.html delete mode 100644 static/netbsd/man4/uhso.4 4.html delete mode 100644 static/netbsd/man4/uintuos.4 3.html delete mode 100644 static/netbsd/man4/uipad.4 4.html delete mode 100644 static/netbsd/man4/uipaq.4 4.html delete mode 100644 static/netbsd/man4/uirda.4 4.html delete mode 100644 static/netbsd/man4/uk.4 4.html delete mode 100644 static/netbsd/man4/ukbd.4 4.html delete mode 100644 static/netbsd/man4/ukphy.4 4.html delete mode 100644 static/netbsd/man4/ukyopon.4 4.html delete mode 100644 static/netbsd/man4/ulpt.4 4.html delete mode 100644 static/netbsd/man4/umass.4 4.html delete mode 100644 static/netbsd/man4/umb.4 4.html delete mode 100644 static/netbsd/man4/umcpmio.4 4.html delete mode 100644 static/netbsd/man4/umcs.4 4.html delete mode 100644 static/netbsd/man4/umct.4 4.html delete mode 100644 static/netbsd/man4/umidi.4 4.html delete mode 100644 static/netbsd/man4/umodem.4 4.html delete mode 100644 static/netbsd/man4/ums.4 4.html delete mode 100644 static/netbsd/man4/unix.4 4.html delete mode 100644 static/netbsd/man4/upgt.4 4.html delete mode 100644 static/netbsd/man4/upl.4 4.html delete mode 100644 static/netbsd/man4/uplcom.4 4.html delete mode 100644 static/netbsd/man4/ure.4 4.html delete mode 100644 static/netbsd/man4/url.4 4.html delete mode 100644 static/netbsd/man4/urndis.4 4.html delete mode 100644 static/netbsd/man4/urtw.4 4.html delete mode 100644 static/netbsd/man4/urtwn.4 3.html delete mode 100644 static/netbsd/man4/usb.4 4.html delete mode 100644 static/netbsd/man4/usbnet.4 3.html delete mode 100644 static/netbsd/man4/userconf.4 4.html delete mode 100644 static/netbsd/man4/uslsa.4 4.html delete mode 100644 static/netbsd/man4/usmsc.4 4.html delete mode 100644 static/netbsd/man4/usscanner.4 4.html delete mode 100644 static/netbsd/man4/ustir.4 4.html delete mode 100644 static/netbsd/man4/uthum.4 4.html delete mode 100644 static/netbsd/man4/utoppy.4 4.html delete mode 100644 static/netbsd/man4/uts.4 4.html delete mode 100644 static/netbsd/man4/uvideo.4 4.html delete mode 100644 static/netbsd/man4/uvisor.4 4.html delete mode 100644 static/netbsd/man4/uvscom.4 4.html delete mode 100644 static/netbsd/man4/uxrcom.4 4.html delete mode 100644 static/netbsd/man4/vald.4 4.html delete mode 100644 static/netbsd/man4/valz.4 4.html delete mode 100644 static/netbsd/man4/veriexec.4 4.html delete mode 100644 static/netbsd/man4/vether.4 4.html delete mode 100644 static/netbsd/man4/vga.4 4.html delete mode 100644 static/netbsd/man4/vge.4 4.html delete mode 100644 static/netbsd/man4/viaenv.4 4.html delete mode 100644 static/netbsd/man4/viaide.4 4.html delete mode 100644 static/netbsd/man4/video.4 4.html delete mode 100644 static/netbsd/man4/vio9p.4 4.html delete mode 100644 static/netbsd/man4/viocon.4 4.html delete mode 100644 static/netbsd/man4/viogpu.4 4.html delete mode 100644 static/netbsd/man4/vioif.4 4.html delete mode 100644 static/netbsd/man4/viomb.4 4.html delete mode 100644 static/netbsd/man4/viornd.4 4.html delete mode 100644 static/netbsd/man4/vioscsi.4 4.html delete mode 100644 static/netbsd/man4/virt.4 4.html delete mode 100644 static/netbsd/man4/virtio.4 4.html delete mode 100644 static/netbsd/man4/virtio_mmio.4 4.html delete mode 100644 static/netbsd/man4/vlan.4 4.html delete mode 100644 static/netbsd/man4/vmmon.4 4.html delete mode 100644 static/netbsd/man4/vmnet.4 4.html delete mode 100644 static/netbsd/man4/vmt.4 4.html delete mode 100644 static/netbsd/man4/vmx.4 4.html delete mode 100644 static/netbsd/man4/vnd.4 4.html delete mode 100644 static/netbsd/man4/voodoofb.4 4.html delete mode 100644 static/netbsd/man4/vr.4 4.html delete mode 100644 static/netbsd/man4/vte.4 4.html delete mode 100644 static/netbsd/man4/wapbl.4 4.html delete mode 100644 static/netbsd/man4/wb.4 4.html delete mode 100644 static/netbsd/man4/wbsio.4 4.html delete mode 100644 static/netbsd/man4/wd.4 4.html delete mode 100644 static/netbsd/man4/wdc.4 4.html delete mode 100644 static/netbsd/man4/wds.4 4.html delete mode 100644 static/netbsd/man4/we.4 4.html delete mode 100644 static/netbsd/man4/wg.4 4.html delete mode 100644 static/netbsd/man4/wi.4 4.html delete mode 100644 static/netbsd/man4/wm.4 4.html delete mode 100644 static/netbsd/man4/wpi.4 4.html delete mode 100644 static/netbsd/man4/wsbell.4 4.html delete mode 100644 static/netbsd/man4/wscons.4 4.html delete mode 100644 static/netbsd/man4/wsdisplay.4 3.html delete mode 100644 static/netbsd/man4/wsfont.4 4.html delete mode 100644 static/netbsd/man4/wskbd.4 4.html delete mode 100644 static/netbsd/man4/wsmouse.4 4.html delete mode 100644 static/netbsd/man4/wsmux.4 4.html delete mode 100644 static/netbsd/man4/wss.4 4.html delete mode 100644 static/netbsd/man4/wt.4 4.html delete mode 100644 static/netbsd/man4/wwanc.4 4.html delete mode 100644 static/netbsd/man4/xbd.4 4.html delete mode 100644 static/netbsd/man4/xbdback.4 4.html delete mode 100644 static/netbsd/man4/xbox.4 4.html delete mode 100644 static/netbsd/man4/xenbus.4 4.html delete mode 100644 static/netbsd/man4/xennet.4 4.html delete mode 100644 static/netbsd/man4/xge.4 4.html delete mode 100644 static/netbsd/man4/xhci.4 4.html delete mode 100644 static/netbsd/man4/xi.4 4.html delete mode 100644 static/netbsd/man4/xirc.4 4.html delete mode 100644 static/netbsd/man4/xpci.4 4.html delete mode 100644 static/netbsd/man4/xvif.4 4.html delete mode 100644 static/netbsd/man4/yds.4 4.html delete mode 100644 static/netbsd/man4/ym.4 4.html delete mode 100644 static/netbsd/man4/zero.4 4.html delete mode 100644 static/netbsd/man4/zstty.4 4.html delete mode 100644 static/netbsd/man4/zyd.4 4.html delete mode 100644 static/netbsd/man8/MAKEDEV.8 4.html delete mode 100644 static/netbsd/man8/MAKEDEV.local.8 4.html delete mode 100644 static/netbsd/man8/afterboot.8 4.html delete mode 100644 static/netbsd/man8/boot.8 4.html delete mode 100644 static/netbsd/man8/compat_30.8 4.html delete mode 100644 static/netbsd/man8/compat_bsdos.8 4.html delete mode 100644 static/netbsd/man8/compat_freebsd.8 4.html delete mode 100644 static/netbsd/man8/compat_linux.8 4.html delete mode 100644 static/netbsd/man8/compat_netbsd32.8 4.html delete mode 100644 static/netbsd/man8/compat_sunos.8 4.html delete mode 100644 static/netbsd/man8/compat_ultrix.8 4.html delete mode 100644 static/netbsd/man8/creds_msdos.8 4.html delete mode 100644 static/netbsd/man8/diskless.8 4.html delete mode 100644 static/netbsd/man8/hpcboot.8 4.html delete mode 100644 static/netbsd/man8/intro.8 4.html delete mode 100644 static/netbsd/man8/man8.hpcarm/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.mac68k/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.macppc/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.macppc/ofwboot.8 3.html delete mode 100644 static/netbsd/man8/man8.pmax/boot.8 2.html delete mode 100644 static/netbsd/man8/man8.prep/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.sandpoint/altboot.8 3.html delete mode 100644 static/netbsd/man8/man8.sgimips/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.sgimips/sgivol.8 3.html delete mode 100644 static/netbsd/man8/man8.sparc/binstall.8 3.html delete mode 100644 static/netbsd/man8/man8.sparc/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.sparc64/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.sun2/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.sun3/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.vax/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.vax/crash.8 2.html delete mode 100644 static/netbsd/man8/man8.vax/drtest.8 3.html delete mode 100644 static/netbsd/man8/man8.vax/format.8 3.html delete mode 100644 static/netbsd/man8/man8.x68k/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.x68k/loadbsd.8 3.html delete mode 100644 static/netbsd/man8/man8.x68k/newdisk.8 3.html delete mode 100644 static/netbsd/man8/man8.x86/boot.8 3.html delete mode 100644 static/netbsd/man8/man8.x86/boot_console.8 3.html delete mode 100644 static/netbsd/man8/man8.x86/dosboot.8 3.html delete mode 100644 static/netbsd/man8/man8.x86/mbr.8 4.html delete mode 100644 static/netbsd/man8/man8.x86/multiboot.8 4.html delete mode 100644 static/netbsd/man8/man8.x86/pxeboot.8 4.html delete mode 100644 static/netbsd/man8/nis.8 4.html delete mode 100644 static/netbsd/man8/pam.8 4.html delete mode 100644 static/netbsd/man8/rc.8 4.html delete mode 100644 static/netbsd/man8/rc.subr.8 4.html delete mode 100644 static/netbsd/man8/rescue.8 4.html delete mode 100644 static/netbsd/man8/veriexec.8 4.html delete mode 100644 static/netbsd/man8/wizd.8 4.html delete mode 100644 static/netbsd/man9/KERNEL_LOCK.9 3.html delete mode 100644 static/netbsd/man9/accept_filter.9 3.html delete mode 100644 static/netbsd/man9/accf_data.9 3.html delete mode 100644 static/netbsd/man9/acct_process.9 3.html delete mode 100644 static/netbsd/man9/autoconf.9 3.html delete mode 100644 static/netbsd/man9/bcdtobin.9 3.html delete mode 100644 static/netbsd/man9/bcopy.9 3.html delete mode 100644 static/netbsd/man9/bufq.9 3.html delete mode 100644 static/netbsd/man9/bus_space.9 3.html delete mode 100644 static/netbsd/man9/clock.9 3.html delete mode 100644 static/netbsd/man9/cnmagic.9 3.html delete mode 100644 static/netbsd/man9/condvar.9 3.html delete mode 100644 static/netbsd/man9/cons.9 3.html delete mode 100644 static/netbsd/man9/cprng.9 3.html delete mode 100644 static/netbsd/man9/cpu_configure.9 3.html delete mode 100644 static/netbsd/man9/cpu_dumpconf.9 3.html delete mode 100644 static/netbsd/man9/cpu_need_resched.9 3.html delete mode 100644 static/netbsd/man9/cpu_rootconf.9 3.html delete mode 100644 static/netbsd/man9/csf.9 3.html delete mode 100644 static/netbsd/man9/curproc.9 3.html delete mode 100644 static/netbsd/man9/ddc.9 3.html delete mode 100644 static/netbsd/man9/delay.9 3.html delete mode 100644 static/netbsd/man9/dksubr.9 3.html delete mode 100644 static/netbsd/man9/dopowerhooks.9 3.html delete mode 100644 static/netbsd/man9/doshutdownhooks.9 3.html delete mode 100644 static/netbsd/man9/driver.9 3.html delete mode 100644 static/netbsd/man9/errno.9 3.html delete mode 100644 static/netbsd/man9/evcnt.9 3.html delete mode 100644 static/netbsd/man9/fileassoc.9 3.html delete mode 100644 static/netbsd/man9/firmload.9 3.html delete mode 100644 static/netbsd/man9/flash.9 3.html delete mode 100644 static/netbsd/man9/fstrans.9 3.html delete mode 100644 static/netbsd/man9/genfs.9 3.html delete mode 100644 static/netbsd/man9/genfs_can_access.9 3.html delete mode 100644 static/netbsd/man9/hardclock.9 3.html delete mode 100644 static/netbsd/man9/heartbeat.9 3.html delete mode 100644 static/netbsd/man9/hz.9 3.html delete mode 100644 static/netbsd/man9/ieee80211_proto.9 3.html delete mode 100644 static/netbsd/man9/ieee80211_radiotap.9 3.html delete mode 100644 static/netbsd/man9/imax.9 3.html delete mode 100644 static/netbsd/man9/inittodr.9 3.html delete mode 100644 static/netbsd/man9/interrupt_distribute.9 3.html delete mode 100644 static/netbsd/man9/intro.9 3.html delete mode 100644 static/netbsd/man9/ioctl.9 3.html delete mode 100644 static/netbsd/man9/kcopy.9 3.html delete mode 100644 static/netbsd/man9/kcpuset.9 3.html delete mode 100644 static/netbsd/man9/kmem.9 3.html delete mode 100644 static/netbsd/man9/localcount.9 3.html delete mode 100644 static/netbsd/man9/lock.9 3.html delete mode 100644 static/netbsd/man9/locking.9 3.html delete mode 100644 static/netbsd/man9/ltsleep.9 3.html delete mode 100644 static/netbsd/man9/man9.x86/rdmsr.9 3.html delete mode 100644 static/netbsd/man9/man9.x86/tsc.9 3.html delete mode 100644 static/netbsd/man9/memcmp.9 3.html delete mode 100644 static/netbsd/man9/memset.9 3.html delete mode 100644 static/netbsd/man9/microseq.9 3.html delete mode 100644 static/netbsd/man9/microtime.9 3.html delete mode 100644 static/netbsd/man9/module.9 3.html delete mode 100644 static/netbsd/man9/namecache.9 3.html delete mode 100644 static/netbsd/man9/nullop.9 3.html delete mode 100644 static/netbsd/man9/optstr.9 3.html delete mode 100644 static/netbsd/man9/panic.9 3.html delete mode 100644 static/netbsd/man9/pci_configure_bus.9 3.html delete mode 100644 static/netbsd/man9/pci_intr.9 3.html delete mode 100644 static/netbsd/man9/pci_msi.9 3.html delete mode 100644 static/netbsd/man9/pckbport.9 3.html delete mode 100644 static/netbsd/man9/pcq.9 3.html delete mode 100644 static/netbsd/man9/pfil.9 3.html delete mode 100644 static/netbsd/man9/physio.9 3.html delete mode 100644 static/netbsd/man9/pmatch.9 3.html delete mode 100644 static/netbsd/man9/pmf.9 3.html delete mode 100644 static/netbsd/man9/proc_find.9 3.html delete mode 100644 static/netbsd/man9/pserialize.9 3.html delete mode 100644 static/netbsd/man9/pslist.9 3.html delete mode 100644 static/netbsd/man9/ras.9 3.html delete mode 100644 static/netbsd/man9/roundup.9 3.html delete mode 100644 static/netbsd/man9/rwlock.9 3.html delete mode 100644 static/netbsd/man9/scanc.9 3.html delete mode 100644 static/netbsd/man9/sched_4bsd.9 3.html delete mode 100644 static/netbsd/man9/secmodel_extensions.9 3.html delete mode 100644 static/netbsd/man9/signal.9 3.html delete mode 100644 static/netbsd/man9/sockopt.9 3.html delete mode 100644 static/netbsd/man9/strlist.9 3.html delete mode 100644 static/netbsd/man9/tc.9 3.html delete mode 100644 static/netbsd/man9/tcp_congctl.9 3.html delete mode 100644 static/netbsd/man9/ucom.9 3.html delete mode 100644 static/netbsd/man9/usbd_status.9 3.html delete mode 100644 static/netbsd/man9/usbnet.9 3.html delete mode 100644 static/netbsd/man9/uvm.9 3.html delete mode 100644 static/netbsd/man9/uvm_hotplug.9 3.html delete mode 100644 static/netbsd/man9/uvm_map.9 3.html delete mode 100644 static/netbsd/man9/vattr.9 3.html delete mode 100644 static/netbsd/man9/vfs.9 3.html delete mode 100644 static/netbsd/man9/vfsops.9 3.html delete mode 100644 static/netbsd/man9/video.9 3.html delete mode 100644 static/netbsd/man9/vnodeops.9 3.html delete mode 100644 static/netbsd/man9/wapbl.9 3.html delete mode 100644 static/netbsd/man9/wsbell.9 3.html diff --git a/static/freebsd/man1/builtin.1 3.html b/static/freebsd/man1/builtin.1 3.html deleted file mode 100644 index 9e877661..00000000 --- a/static/freebsd/man1/builtin.1 3.html +++ /dev/null @@ -1,891 +0,0 @@ - - - - - - -
BUILTIN(1)General Commands ManualBUILTIN(1)
-
-
-

-

builtin, keybinds - — index of FreeBSD shell built-in - commands

-
-
-

-

See the manual for your shell for operation details.

-
-
-

-

This page provides an index of builtin - commands, keywords, and keyboard bindings provided by - csh(1) and sh(1), the command line - interpreters which comprise the BSD user - environment.

-
-

-

Below is a table which lists builtin - commands and keywords, whether they exist as standalone utilities, and the - standard shells that provide them.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
csh(1)sh(1)
NoNoYes
NoYesNo
NoNoYes
NoYesYes
NoYesNo
YesNoYes
NoNoYes
NoNoYes
NoYesYes
NoYesNo
NoYesYes
NoNoYes
NoYesNo
NoYesYes
NoYesNo
NoNoYes
NoYesNo
NoYesYes
NoYesYes
NoYesYes
NoNoYes
NoYesNo
NoYesYes
NoYesNo
NoYesNo
NoNoYes
NoNoYes
YesYesYes
NoYesNo
NoNoYes
NoYesYes
NoYesNo
NoYesNo
NoYesNo
NoNoYes
NoYesYes
NoYesYes
NoYesYes
NoNoYes
YesNoYes
NoNoYes
NoYesYes
NoNoYes
NoYesNo
NoNoYes
NoYesNo
NoNoYes
NoYesNo
NoYesNo
NoNoYes
NoYesNo
NoYesNo
NoYesNo
NoYesYes
NoNoYes
NoYesYes
YesYesYes
NoYesNo
NoNoYes
NoYesNo
YesYesNo
NoYesNo
NoYesNo
YesYesNo
YesYesNo
NoYesNo
NoYesNo
NoYesNo
YesYesNo
YesNoYes
NoYesNo
YesNoYes
NoNoYes
NoNoYes
NoYesNo
NoYesNo
NoNoYes
NoYesNo
NoYesYes
NoYesNo
NoYesNo
NoYesNo
NoNoYes
NoYesYes
NoYesNo
NoYesNo
NoYesNo
NoYesNo
NoYesNo
YesNoYes
NoNoYes
YesYesNo
NoNoYes
NoNoYes
YesNoYes
NoNoYes
NoNoYes
NoYesYes
NoYesYes
NoYesNo
NoYesNo
NoYesNo
NoYesYes
NoYesNo
NoNoYes
NoYesYes
NoYesNo
YesYesNo
NoYesYes
-
-
-

-

The command line environment also provides the following default - keyboard bindings:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
csh(1)sh(1)
^H^H
^M | ^J^M | ^J
^I^I
^A^A
^E^E
^F^F
^B^B
^L^L
^U^U
^W^W
^K^K
^Y^Y
^T^T
End of File (EOF)^D^D
Interupt (SIGINT)^C^C
Process info (SIGINFO)^T^T
No^G
^P^P
^N^N
^V^V
^S^S
^Q^Q
Suspend Job (SIGTSTP)^Z^Z
ScrLk*ScrLk*
-

*: Bindings marked ‘*’ are - provided by vt(4), the console driver.

-
-
-
-

-

csh(1), echo(1), - false(1), kill(1), - login(1), nice(1), - nohup(1), printenv(1), - printf(1), pwd(1), - sh(1), test(1), - time(1), true(1), - which(1)

-
-
-

-

The builtin manual page first appeared in - FreeBSD 3.4.

-
-
-

-

This manual page was written by Alexander - Ziaee - <ziaee@FreeBSD.org> - from an earlier version by Sheldon Hearn - <sheldonh@FreeBSD.org>.

-
-
-

-

While builtin commands may exist in more - than one shell or standalone, each may be implemented differently.

-

Standalone utilities and their manuals must be called by their - path from a shell with a builtin command of the same - name.

-
-
- - - - - -
December 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man1/intro.1 3.html b/static/freebsd/man1/intro.1 3.html deleted file mode 100644 index ed05da08..00000000 --- a/static/freebsd/man1/intro.1 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
INTRO(1)General Commands ManualINTRO(1)
-
-
-

-

intro — - introduction to general commands (tools and - utilities)

-
-
-

-

Section one of the manual contains most of the commands which - comprise the FreeBSD user environment. Some of the - commands included with the system in section one are text editors, command - shell interpreters, searching and sorting tools, file manipulation commands, - system status commands, remote file copy commands, mail commands, compilers - and compiler tools, formatted output tools, and line printer commands.

-

Tens of thousands of additional commands are available to be - installed with pkg(8), or compiled with the - ports(7) collection. Some of which include web browsers, - office suites, calendars, conferencing utilities, integrated development - environments, media players, audio and video processing suites, etc.

-

All commands set a status value upon exit which may be tested to - see if the command completed normally. Traditionally, the value 0 signifies - successful completion of the command, while a value >0 indicates an - error. Some commands attempt to describe the nature of the failure by using - exit codes as defined in sysexits(3), while others simply - set the status to an arbitrary value >0 (typically 1).

-
-
-

-
-
/bin/
-
Commands fundamental to single- and multi-user modes.
-
/usr/bin/
-
General commands included with the base system.
-
/usr/local/bin/
-
Locally installed commands from pkg(8) or - ports(7).
-
-
-
-

-

apropos(1), man(1), - which(1), intro(2), - intro(3), sysexits(3), - intro(4), intro(5), - intro(6), intro(7), - ports(7), security(7), - intro(8), pkg(8), - intro(9)

-

Tutorials in the UNIX User's Manual - Supplementary Documents.

-
-
-

-

The intro(1) manual page first appeared in - Version 6 AT&T UNIX.

-
-
- - - - - -
April 12, 2024FreeBSD 15.0
diff --git a/static/freebsd/man3/ATOMIC_VAR_INIT.3 3.html b/static/freebsd/man3/ATOMIC_VAR_INIT.3 3.html deleted file mode 100644 index 5149c119..00000000 --- a/static/freebsd/man3/ATOMIC_VAR_INIT.3 3.html +++ /dev/null @@ -1,315 +0,0 @@ - - - - - - -
ATOMIC_VAR_INIT(3)Library Functions ManualATOMIC_VAR_INIT(3)
-
-
-

-

ATOMIC_VAR_INIT, - atomic_init, atomic_load, - atomic_store, - atomic_exchange, - atomic_compare_exchange_strong, - atomic_compare_exchange_weak, - atomic_fetch_add, - atomic_fetch_and, - atomic_fetch_or, - atomic_fetch_sub, - atomic_fetch_xor, - atomic_is_lock_free — - type-generic atomic operations

-
-
-

-

#include - <stdatomic.h>

-

_Atomic(T) v = ATOMIC_VAR_INIT(c); -
- void -
- atomic_init(_Atomic(T) - *object, T - value);

-

T -
- atomic_load(_Atomic(T) - *object);

-

T -
- atomic_load_explicit(_Atomic(T) - *object, memory_order - order);

-

void -
- atomic_store(_Atomic(T) - *object, T - desired);

-

void -
- atomic_store_explicit(_Atomic(T) - *object, T desired, - memory_order order);

-

T -
- atomic_exchange(_Atomic(T) - *object, T - desired);

-

T -
- atomic_exchange_explicit(_Atomic(T) - *object, T desired, - memory_order order);

-

_Bool -
- atomic_compare_exchange_strong(_Atomic(T) - *object, T - *expected, T - desired);

-

_Bool -
- atomic_compare_exchange_strong_explicit(_Atomic(T) - *object, T - *expected, T - desired, memory_order - success, memory_order - failure);

-

_Bool -
- atomic_compare_exchange_weak(_Atomic(T) - *object, T - *expected, T - desired);

-

_Bool -
- atomic_compare_exchange_weak_explicit(_Atomic(T) - *object, T - *expected, T - desired, memory_order - success, memory_order - failure);

-

T -
- atomic_fetch_add(_Atomic(T) - *object, T - operand);

-

T -
- atomic_fetch_add_explicit(_Atomic(T) - *object, T operand, - memory_order order);

-

T -
- atomic_fetch_and(_Atomic(T) - *object, T - operand);

-

T -
- atomic_fetch_and_explicit(_Atomic(T) - *object, T operand, - memory_order order);

-

T -
- atomic_fetch_or(_Atomic(T) - *object, T - operand);

-

T -
- atomic_fetch_or_explicit(_Atomic(T) - *object, T operand, - memory_order order);

-

T -
- atomic_fetch_sub(_Atomic(T) - *object, T - operand);

-

T -
- atomic_fetch_sub_explicit(_Atomic(T) - *object, T operand, - memory_order order);

-

T -
- atomic_fetch_xor(_Atomic(T) - *object, T - operand);

-

T -
- atomic_fetch_xor_explicit(_Atomic(T) - *object, T operand, - memory_order order);

-

_Bool -
- atomic_is_lock_free(const - _Atomic(T) *object);

-
-
-

-

The header - <stdatomic.h> provides - type-generic macros for atomic operations. Atomic operations can be used by - multithreaded programs to provide shared variables between threads that in - most cases may be modified without acquiring locks.

-

Atomic variables are declared using the - () - type specifier. These variables are not type-compatible with their - non-atomic counterparts. Depending on the compiler used, atomic variables - may be opaque and can therefore only be influenced using the macros - described.

-

The - () - macro initializes the atomic variable object with a - value. Atomic variables can be initialized while being - declared using - ().

-

The - () - macro returns the value of atomic variable object. The - () - macro sets the atomic variable object to its - desired value.

-

The - () - macro combines the behaviour of atomic_load() and - atomic_store(). It sets the atomic variable - object to its desired value and - returns the original contents of the atomic variable.

-

The - () - macro stores a desired value into atomic variable - object, only if the atomic variable is equal to its - expected value. Upon success, the macro returns - true. Upon failure, the - desired value is overwritten with the value of the - atomic variable and false is returned. The - () - macro is identical to - atomic_compare_exchange_strong(), but is allowed to - fail even if atomic variable object is equal to its - expected value.

-

The - () - macro adds the value operand to atomic variable - object and returns the original contents of the atomic - variable.

-

The - () - macro applies the - operator - to atomic variable object and - operand and stores the value into - object, while returning the original contents of the - atomic variable.

-

The - () - macro applies the - operator to - atomic variable object and - operand and stores the value into - object, while returning the original contents of the - atomic variable.

-

The - () - macro subtracts the value operand from atomic variable - object and returns the original contents of the atomic - variable.

-

The - () - macro applies the - operator - to atomic variable object and - operand and stores the value into - object, while returning the original contents of the - atomic variable.

-

The - () - macro returns whether atomic variable object uses - locks when using atomic operations.

-
-
-

-

The atomic operations described previously are implemented in such - a way that they disallow both the compiler and the executing processor to - re-order any nearby memory operations across the atomic operation. In - certain cases this behaviour may cause suboptimal performance. To mitigate - this, every atomic operation has an _explicit() - version that allows the re-ordering to be configured.

-

The order parameter of these - () - macros can have one of the following values.

-
-
-
No operation orders memory.
-
-
Perform consume operation.
-
-
Acquire fence.
-
-
Release fence.
-
-
Acquire and release fence.
-
-
Sequentially consistent acquire and release fence.
-
-

The previously described macros are identical to - the - () - macros, when order is - memory_order_seq_cst.

-
-
-

-

These atomic operations are typically implemented by the compiler, - as they must be implemented type-generically and must often use special - hardware instructions. As this interface has not been adopted by most - compilers yet, the - <stdatomic.h> header - implements these macros on top of existing compiler intrinsics to provide - forward compatibility.

-

This means that certain aspects of the interface, such as support - for different barrier types may simply be ignored. When using GCC, all - atomic operations are executed as if they are using - memory_order_seq_cst.

-

Instead of using the atomic operations provided by this interface, - ISO/IEC 9899:2011 (“ISO C11”) - allows the atomic variables to be modified directly using built-in language - operators. This behaviour cannot be emulated for older compilers. To prevent - unintended non-atomic access to these variables, this header file places the - atomic variable in a structure when using an older compiler.

-

When using GCC on architectures on which it lacks support for - built-in atomic intrinsics, these macros may emit function calls to fallback - routines. These fallback routines are only implemented for 32-bits and - 64-bits datatypes, if supported by the CPU.

-
-
-

-

pthread(3), atomic(9)

-
-
-

-

These macros attempt to conform to ISO/IEC - 9899:2011 (“ISO C11”).

-
-
-

-

These macros appeared in FreeBSD 10.0.

-
-
-

-

Ed Schouten - <ed@FreeBSD.org> -
- David Chisnall - <theraven@FreeBSD.org>

-
-
- - - - - -
December 27, 2011FreeBSD 15.0
diff --git a/static/freebsd/man3/CMSG_DATA.3 3.html b/static/freebsd/man3/CMSG_DATA.3 3.html deleted file mode 100644 index bbc6823b..00000000 --- a/static/freebsd/man3/CMSG_DATA.3 3.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - -
CMSG_DATA(3)Library Functions ManualCMSG_DATA(3)
-
-
-

-

CMSG_DATA, - CMSG_FIRSTHDR, CMSG_LEN, - CMSG_NXTHDR, CMSG_SPACE - — socket control message routines for ancillary data - access

-
-
-

-

#include - <sys/socket.h>

-

unsigned char * -
- CMSG_DATA(struct - cmsghdr *);

-

struct cmsghdr * -
- CMSG_FIRSTHDR(struct - msghdr *);

-

size_t -
- CMSG_LEN(size_t);

-

struct cmsghdr * -
- CMSG_NXTHDR(struct - msghdr *, struct cmsghdr - *);

-

size_t -
- CMSG_SPACE(size_t);

-
-
-

-

The control message API is used to construct ancillary data - objects for use in control messages sent and received across sockets.

-

Control messages are passed around by the - recvmsg(2) and sendmsg(2) system calls. - The cmsghdr structure, described in - recvmsg(2), is used to specify a chain of control - messages.

-

These routines should be used instead of directly accessing the - control message header members and data buffers as they ensure that - necessary alignment constraints are met.

-

The following routines are provided:

-
-
(cmsg)
-
This routine accesses the data portion of the control message header - cmsg. It ensures proper alignment constraints on the - beginning of ancillary data are met.
-
(msghdr)
-
This routine accesses the first control message attached to the message - msghdr. If no control messages are attached to the - message, this routine returns NULL.
-
(len)
-
This routine determines the size in bytes of a control message, which - includes the control message header. len specifies - the length of the data held by the control message. This value is what is - normally stored in the cmsg_len of each control - message. This routine accounts for any alignment constraints on the - beginning of ancillary data.
-
(msghdr, - cmsg)
-
This routine returns the location of the control message following - cmsg in the message msghdr. If - cmsg is the last control message in the chain, this - routine returns NULL.
-
(len)
-
This routine determines the size in bytes needed to hold a control message - and its contents of length len, which includes the - control message header. This value is what is normally stored in - msg_msgcontrollen. This routine accounts for any - alignment constraints on the beginning of ancillary data as well as any - needed to pad the next control message.
-
-
-
-

-

The following example constructs a control message containing a - file descriptor in the parent process and passes it over a pre-shared socket - over the child process. Then the child process sends a "hello" - string to the parent process using the received file descriptor.

-
-
#include <sys/socket.h>
-
-#include <err.h>
-#include <stdio.h>
-#include <string.h>
-#include <sysexits.h>
-#include <unistd.h>
-
-#define	HELLOLEN    sizeof("hello")
-
-int
-main()
-{
-	struct msghdr msg;
-	union {
-		struct cmsghdr hdr;
-		unsigned char	 buf[CMSG_SPACE(sizeof(int))];
-	} cmsgbuf;
-	char buf[HELLOLEN];
-	int hellofd[2];
-	int presharedfd[2];
-	struct cmsghdr *cmsg;
-
-	if (socketpair(PF_LOCAL, SOCK_STREAM, 0, presharedfd) == -1)
-		err(EX_OSERR, "failed to create a pre-shared socket pair");
-
-	memset(&msg, 0, sizeof(msg));
-	msg.msg_control = &cmsgbuf.buf;
-	msg.msg_controllen = sizeof(cmsgbuf.buf);
-	msg.msg_iov = NULL;
-	msg.msg_iovlen = 0;
-
-	switch (fork()) {
-	case -1:
-		err(EX_OSERR, "fork");
-	case 0:
-		close(presharedfd[0]);
-		strlcpy(buf, "hello", HELLOLEN);
-
-		if (recvmsg(presharedfd[1], &msg, 0) == -1)
-			err(EX_IOERR, "failed to receive a message");
-		if (msg.msg_flags & (MSG_CTRUNC | MSG_TRUNC))
-			errx(EX_IOERR, "control message truncated");
-		for (cmsg = CMSG_FIRSTHDR(&msg); cmsg != NULL;
-		    cmsg = CMSG_NXTHDR(&msg, cmsg)) {
-			if (cmsg->cmsg_len == CMSG_LEN(sizeof(int)) &&
-			    cmsg->cmsg_level == SOL_SOCKET &&
-			    cmsg->cmsg_type == SCM_RIGHTS) {
-				hellofd[1] = *(int *)CMSG_DATA(cmsg);
-				printf("child: sending '%s'\n", buf);
-				if (write(hellofd[1], buf, HELLOLEN) == -1)
-				    err(EX_IOERR, "failed to send 'hello'");
-			}
-		}
-		break;
-	default:
-		close(presharedfd[1]);
-
-		if (socketpair(PF_LOCAL, SOCK_STREAM, 0, hellofd) == -1)
-			err(EX_OSERR, "failed to create a 'hello' socket pair");
-
-		cmsg = CMSG_FIRSTHDR(&msg);
-		cmsg->cmsg_len = CMSG_LEN(sizeof(int));
-		cmsg->cmsg_level = SOL_SOCKET;
-		cmsg->cmsg_type = SCM_RIGHTS;
-		*(int *)CMSG_DATA(cmsg) = hellofd[1];
-
-		if (sendmsg(presharedfd[0], &msg, 0) == -1)
-			err(EX_IOERR, "sendmsg");
-		close(hellofd[1]);
-
-		if (read(hellofd[0], buf, HELLOLEN) == -1)
-			err(EX_IOERR, "failed to receive 'hello'");
-		printf("parent: received '%s'\n", buf);
-		break;
-	}
-
-	return (0);
-}
-
-
-
-

-

recvmsg(2), sendmsg(2), - socket(2), ip(4), - ip6(4), unix(4)

-
-
-

-
    -
  • W. Stevens and - M. Thomas, Advanced Sockets API - for IPv6, RFC 2292, - February 1998.
    • -
  • W. Stevens, M. - Thomas, E. Nordmark, and - T. Jinmei, Advanced Sockets - Application Program Interface (API) for IPv6, RFC - 3542, May 2003.
    • -
-
-
-

-

The control message API first appeared in - 4.2BSD. This manual page was originally written by - Jared Yanovich - <jaredy@OpenBSD.org> - for OpenBSD 3.8 and eventually brought to - FreeBSD 12.0 by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
March 13, 2020FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_FRAWMASK.3 3.html b/static/freebsd/man3/Q_FRAWMASK.3 3.html deleted file mode 100644 index 841a9deb..00000000 --- a/static/freebsd/man3/Q_FRAWMASK.3 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
Q_FRAWMASK(3)Library Functions ManualQ_FRAWMASK(3)
-
-
-

-

Q_FRAWMASK, - Q_GFRAW, Q_GFABSVAL, - Q_GFVAL, Q_SFVAL — - fixed-point math functions which manipulate the fractional - data bits

-
-
-

-

#include - <sys/qmath.h>

-

ITYPE -
- Q_FRAWMASK(QTYPE - q);

-

ITYPE -
- Q_GFRAW(QTYPE - q);

-

ITYPE -
- Q_GFABSVAL(QTYPE - q);

-

ITYPE -
- Q_GFVAL(QTYPE - q);

-

QTYPE -
- Q_SFVAL(QTYPE - q, ITYPE fv);

-
-
-

-

() - returns a q-specific bit mask for - q's fractional data bits.

-

() - returns q's raw masked fractional data bits.

-

() - and - () - return the absolute and real values of q's fractional - data bits respectively.

-

() - sets q's fractional data bits to the value - fv.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types.

-

For more details, see qmath(3).

-
-
-

-

Q_FRAWMASK(), - Q_GFRAW(), Q_GFABSVAL() and - Q_GFVAL() return their respective values as integers - of the same underlying ITYPE as q.

-

Q_SFVAL() returns the value of - q post set.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_IFRAWMASK.3 3.html b/static/freebsd/man3/Q_IFRAWMASK.3 3.html deleted file mode 100644 index 1605bcdf..00000000 --- a/static/freebsd/man3/Q_IFRAWMASK.3 3.html +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - -
Q_IFRAWMASK(3)Library Functions ManualQ_IFRAWMASK(3)
-
-
-

-

Q_IFRAWMASK, - Q_IFVALIMASK, Q_IFVALFMASK, - Q_GIFRAW, Q_GIFABSVAL, - Q_GIFVAL, Q_SIFVAL, - Q_SIFVALS — fixed-point math - functions which manipulate the combined integer/fractional data - bits

-
-
-

-

#include - <sys/qmath.h>

-

ITYPE -
- Q_IFRAWMASK(QTYPE - q);

-

ITYPE -
- Q_IFVALIMASK(QTYPE - q);

-

ITYPE -
- Q_IFVALFMASK(QTYPE - q);

-

ITYPE -
- Q_GIFRAW(QTYPE - q);

-

ITYPE -
- Q_GIFABSVAL(QTYPE - q);

-

ITYPE -
- Q_GIFVAL(QTYPE - q);

-

QTYPE -
- Q_SIFVAL(QTYPE - q, ITYPE ifv);

-

QTYPE -
- Q_SIFVALS(QTYPE - q, ITYPE iv, - ITYPE fv);

-
-
-

-

() - returns a q-specific bit mask for - q's combined integer and fractional data bits.

-

() - and - () - return q-specific bit masks for the integer and - fractional bits of q's combined integer and fractional - data bits value, i.e., are applicable to the values returned by - Q_GIFABSVAL() and - Q_GIFVAL().

-

() - returns q's raw masked integer/fractional data - bits.

-

() - and - () - return the absolute and real values of q's - integer/fractional data bits respectively.

-

() - sets q's combined integer/fractional data bits to the - value ifv, whereas - () - independently sets q's integer and fractional data - bits to the separate values iv and - fv.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types.

-

For more details, see qmath(3).

-
-
-

-

Q_IFRAWMASK(), - Q_IFVALIMASK(), - Q_IFVALFMASK(), - Q_GIFABSVAL(), Q_GIFVAL(), - Q_GIFRAW(), Q_GIFABSVAL() - and Q_GIFVAL() return their respective values as - integers of the same underlying ITYPE as q.

-

Q_SIFVAL() and - Q_SIFVALS() return the value of - q post change.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_INI.3 3.html b/static/freebsd/man3/Q_INI.3 3.html deleted file mode 100644 index b02de100..00000000 --- a/static/freebsd/man3/Q_INI.3 3.html +++ /dev/null @@ -1,216 +0,0 @@ - - - - - - -
Q_INI(3)Library Functions ManualQ_INI(3)
-
-
-

-

Q_INI, Q_NCBITS, - Q_BT, Q_TC, - Q_NTBITS, Q_NFCBITS, - Q_MAXNFBITS, Q_NFBITS, - Q_NIBITS, Q_RPSHFT, - Q_ABS, Q_MAXSTRLEN, - Q_TOSTR, Q_SHL, - Q_SHR, Q_DEBUG — - fixed-point math miscellaneous - functions/variables

-
-
-

-

#include - <sys/qmath.h>

-

QTYPE -
- Q_INI(QTYPE - *q, ITYPE iv, - ITYPE dfv, - int rpshft);

-

Q_NCBITS

-

__typeof(q) -
- Q_BT(QTYPE - q);

-

ITYPE -
- Q_TC(QTYPE - q, ITYPE v);

-

uint32_t -
- Q_NTBITS(QTYPE - q);

-

uint32_t -
- Q_NFCBITS(QTYPE - q);

-

uint32_t -
- Q_MAXNFBITS(QTYPE - q);

-

uint32_t -
- Q_NFBITS(QTYPE - q);

-

uint32_t -
- Q_NIBITS(QTYPE - q);

-

uint32_t -
- Q_RPSHFT(QTYPE - q);

-

NTYPE -
- Q_ABS(NTYPE - n);

-

uint32_t -
- Q_MAXSTRLEN(QTYPE - q, int base);

-

char * -
- Q_TOSTR(QTYPE - q, int prec, - int base, - char *s, - int slen);

-

ITYPE -
- Q_SHL(QTYPE - q, ITYPE iv);

-

ITYPE -
- Q_SHR(QTYPE - q, ITYPE iv);

-

char *, ... -
- Q_DEBUG(QTYPE - q, char *prefmt, - char *postfmt, - incfmt);

-

ITYPE -
- Q_DFV2BFV(ITYPE - dfv, int - nfbits);

-
-
-

-

() - initialises a Q number with the supplied integral value - iv and decimal fractional value - dfv, with appropriate control bits based on the - requested radix shift point rpshft. - dfv must be passed as a preprocessor literal to - preserve leading zeroes.

-

The Q_NCBITS defined constant specifies - the number of reserved control bits, currently 3.

-

(), - (), - (), - () - and - () - return the q-specific count of total, control-encoded - fractional, maximum fractional, effective fractional, and integer bits - applicable to q respectively.

-

() - returns the C data type of q, while - () - returns v type casted to the C data type of - q.

-

() - returns the bit position of q's binary radix point - relative to bit zero.

-

() - returns the absolute value of any standard numeric type (that uses the MSB - as a sign bit, but not Q numbers) passed in as n. The - function is signed/unsigned type safe.

-

() - and - () - return the integral value v left or right shifted by - the appropriate amount for q.

-

() - calculates the maximum number of characters that may be required to render - the C-string representation of q with numeric base - base.

-

() - renders the C-string representation of q with numeric - base base and fractional precision - prec into s which has an - available capacity of slen characters. - base must be in range [2,16]. Specifying - prec as -1 renders the number's fractional component - with maximum precision. If slen is greater than zero - but insufficient to hold the complete C-string, the '\0' C-string terminator - will be written to *s, thereby returning a zero length - C-string.

-

() - returns a format string and associated data suitable for printf-like - rendering of debugging information pertaining to q. If - either prefmt and/or postfmt are - specified, they are prepended and appended to the resulting format string - respectively. The incfmt boolean specifies whether to - include (true) or exclude - (false) the raw format string itself in the debugging - output.

-

() - converts decimal fractional value dfv to its - binary-encoded representation with nfbits of binary - precision. dfv must be passed as a preprocessor - literal to preserve leading zeroes. The returned value can be used to set a - Q number's fractional bits, for example using - ().

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types. NTYPE is used to refer to any numeric - type and is therefore a superset of QTYPE and - ITYPE.

-

For more details, see qmath(3).

-
-
-

-

Q_INI() returns the initialised Q number - which can be used to chain initialise additional Q numbers.

-

Q_TOSTR() returns a pointer to the '\0' - C-string terminator appended to s after the rendered - numeric data, or NULL on buffer overflow.

-

Q_DFV2BFV() returns the binary-encoded - representation of decimal fractional value dfv with - nfbits of binary precision.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_IRAWMASK.3 3.html b/static/freebsd/man3/Q_IRAWMASK.3 3.html deleted file mode 100644 index 54f410ac..00000000 --- a/static/freebsd/man3/Q_IRAWMASK.3 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
Q_IRAWMASK(3)Library Functions ManualQ_IRAWMASK(3)
-
-
-

-

Q_IRAWMASK, - Q_GIRAW, Q_GIABSVAL, - Q_GIVAL, Q_SIVAL — - fixed-point math functions which manipulate the integer - data bits

-
-
-

-

#include - <sys/qmath.h>

-

ITYPE -
- Q_IRAWMASK(QTYPE - q);

-

ITYPE -
- Q_GIRAW(QTYPE - q);

-

ITYPE -
- Q_GIABSVAL(QTYPE - q);

-

ITYPE -
- Q_GIVAL(QTYPE - q);

-

QTYPE -
- Q_SIVAL(QTYPE - q, ITYPE iv);

-
-
-

-

() - returns a q-specific bit mask for - q's integer data bits.

-

() - returns q's raw masked integer data bits.

-

() - and - () - return the absolute and real values of q's integer - data bits respectively.

-

() - sets q's integer data bits to the value - iv.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types.

-

For more details, see qmath(3).

-
-
-

-

Q_IRAWMASK(), - Q_GIRAW(), Q_GIABSVAL() and - Q_GIVAL() return their respective values as integers - of the same underlying ITYPE as q.

-

Q_SIVAL() returns the value of - q post change.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_QABS.3 4.html b/static/freebsd/man3/Q_QABS.3 4.html deleted file mode 100644 index 210c2ce5..00000000 --- a/static/freebsd/man3/Q_QABS.3 4.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
Q_QABS(3)Library Functions ManualQ_QABS(3)
-
-
-

-

Q_QABS, Q_Q2S, - Q_Q2F — fixed-point math - functions which operate on a single Q number

-
-
-

-

#include - <sys/qmath.h>

-

QTYPE -
- Q_QABS(QTYPE - q);

-

double -
- Q_Q2D(QTYPE - q);

-

float -
- Q_Q2F(QTYPE - q);

-
-
-

-

The - () - function returns an absolute value representation of - q.

-

The - () and - () - functions return the double and float representations of - q respectively.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE.

-

For more details, see qmath(3).

-
-
-

-

Q_QABS() function returns a QTYPE that is - identical to that of q.

-

The Q_Q2D() and - Q_Q2F() functions return the double and float - representations of q respectively.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_QADDI.3 3.html b/static/freebsd/man3/Q_QADDI.3 3.html deleted file mode 100644 index 67faa1cf..00000000 --- a/static/freebsd/man3/Q_QADDI.3 3.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
Q_QADDI(3)Library Functions ManualQ_QADDI(3)
-
-
-

-

Q_QADDI, Q_QDIVI, - Q_QMULI, Q_QSUBI, - Q_QFRACI, Q_QCPYVALI - — fixed-point math functions which apply integers to - a Q number

-
-
-

-

#include - <sys/qmath.h>

-

int -
- Q_QADDI(QTYPE - *a, ITYPE b);

-

int -
- Q_QDIVI(QTYPE - *a, ITYPE b);

-

int -
- Q_QMULI(QTYPE - *a, ITYPE b);

-

int -
- Q_QSUBI(QTYPE - *a, ITYPE b);

-

int -
- Q_QFRACI(QTYPE - *q, ITYPE n, - ITYPE d);

-

int -
- Q_QCPYVALI(QTYPE - *q, ITYPE i);

-
-
-

-

The - (), - (), - () - and - () - functions add, divide, multiply or subtract b - to/by/from a respectively, storing the result in - a.

-

The - () - function computes the fraction n divided by - d and stores the fixed-point result in - q.

-

The - () - function overwrites q's integer and fractional bits - with the Q representation of integer value i.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types.

-

For more details, see qmath(3).

-
-
-

-

Q_QADDI(), - Q_QDIVI(), Q_QMULI(), - Q_QSUBI(), Q_QFRACI() and - Q_QCPYVALI() functions return 0 on success, or an - errno on failure. EINVAL is returned for - divide-by-zero. EOVERFLOW and - ERANGE are returned for overflow and underflow - respectively.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_QADDQ.3 3.html b/static/freebsd/man3/Q_QADDQ.3 3.html deleted file mode 100644 index 8306c7af..00000000 --- a/static/freebsd/man3/Q_QADDQ.3 3.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - -
Q_QADDQ(3)Library Functions ManualQ_QADDQ(3)
-
-
-

-

Q_QADDQ, Q_QDIVQ, - Q_QMULQ, Q_QSUBQ, - Q_NORMPREC, Q_QMAXQ, - Q_QMINQ, Q_QCLONEQ, - Q_CPYVALQ — fixed-point math - functions which operate on two Q numbers

-
-
-

-

#include - <sys/qmath.h>

-

int -
- Q_QADDQ(QTYPE - *a, QTYPE b);

-

int -
- Q_QDIVQ(QTYPE - *a, QTYPE b);

-

int -
- Q_QMULQ(QTYPE - *a, QTYPE b);

-

int -
- Q_QSUBQ(QTYPE - *a, QTYPE b);

-

int -
- Q_NORMPREC(QTYPE - *a, QTYPE *b);

-

QTYPE -
- Q_QMAXQ(QTYPE - a, QTYPE b);

-

QTYPE -
- Q_QMINQ(QTYPE - a, QTYPE b);

-

int -
- Q_QCLONEQ(QTYPE - *l, QTYPE r);

-

int -
- Q_QCPYVALQ(QTYPE - *l, QTYPE r);

-
-
-

-

The - (), - (), - (), - and - () - functions add, divide, multiply or subtract b - to/by/from a respectively, storing the result in - a. Both arguments must be initialized with the same - fractional radix point.

-

The - () - function attempts to normalise the precision of a and - b if they differ. The greater of the two precisions is - preferred if possible, unless that would truncate integer component data for - the other operand, in which case the highest precision that preserves the - integer component of both a and - b is selected.

-

The - () - and - () - functions return the larger or smaller of a and - b respectively.

-

The - () - and - () - functions attempt to store identical or representational copies of - r, in l respectively. An - identical Q number produced by cloning copies the control bits as well as - the verbatim integer/fractional bits. A representational copy only copies - the values of r's integer and fractional bits, - representing them in the bits available per l's Q - format.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE.

-

For more details, see qmath(3).

-
-
-

-

The Q_QADDQ(), - Q_QDIVQ(), Q_QMULQ(), - Q_QSUBQ() Q_NORMPREC(), - Q_QCLONEQ() and Q_QCPYVALQ() - functions return 0 on success, or an errno on failure. - EINVAL is returned for divide-by-zero. - EOVERFLOW and ERANGE are - returned for overflow and underflow respectively. ERANGE is - also returned when the precision of arguments does not match.

-

The Q_QMAXQ() and - Q_QMINQ() functions return the numerically larger or - smaller of their two inputs respectively.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_SIGNED.3 3.html b/static/freebsd/man3/Q_SIGNED.3 3.html deleted file mode 100644 index 7a85a17f..00000000 --- a/static/freebsd/man3/Q_SIGNED.3 3.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - -
Q_SIGNED(3)Library Functions ManualQ_SIGNED(3)
-
-
-

-

Q_SIGNED, Q_LTZ, - Q_PRECEQ, Q_QLTQ, - Q_QLEQ, Q_QGTQ, - Q_QGEQ, Q_QEQ, - Q_QNEQ, Q_OFLOW, - Q_RELPREC — fixed-point math - comparison and logic functions

-
-
-

-

#include - <sys/qmath.h>

-

bool -
- Q_SIGNED(NTYPE - n);

-

bool -
- Q_LTZ(NTYPE - n);

-

bool -
- Q_PRECEQ(QTYPE - a, QTYPE b);

-

bool -
- Q_QLTQ(QTYPE - a, QTYPE b);

-

bool -
- Q_QLEQ(QTYPE - a, QTYPE b);

-

bool -
- Q_QGTQ(QTYPE - a, QTYPE b);

-

bool -
- Q_QGEQ(QTYPE - a, QTYPE b);

-

bool -
- Q_QEQ(QTYPE - a, QTYPE b);

-

bool -
- Q_QNEQ(QTYPE - a, QTYPE b);

-

bool -
- Q_OFLOW(QTYPE - q, ITYPE iv);

-

int -
- Q_RELPREC(QTYPE - a, QTYPE b);

-
-
-

-

() - returns true if the numeric data type passed in as - n is signed, or false - otherwise.

-

() - returns true if the numeric value passed in as - n is negative (requires types which use the MSB as the - sign bit), or false otherwise.

-

() - returns true if the number of a - and b fractional bits is the same, - false otherwise.

-

The - (), - (), - (), - (), - () - and - () - functions compare two Q numbers, returning true if - a is less than, less than or equal to, greater than, - greater than or equal to, equal to, or not equal to b - respectively, or false otherwise. The integral and - fractional values are used to perform the comparison, without explicit - concern for the underlying number of integer versus fractional bits.

-

() - returns true if integer value iv - cannot be stored in q without truncation, or false - otherwise.

-

() - returns the relative precision of a versus - b. In terms of - - notation, this function returns the difference between the - values of - a and b. For example, a return - value of +4 means that a has an additional 4 bits of - fractional precision compared to b.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types. NTYPE is used to refer to any numeric - type and is therefore a superset of QTYPE and - ITYPE.

-

For more details, see qmath(3).

-
-
-

-

The Q_SIGNED(), - Q_LTZ(), Q_PRECEQ(), - Q_QLTQ(), Q_QLEQ(), - Q_QGTQ(), Q_QGEQ(), - Q_QEQ(), Q_QNEQ() and - Q_OFLOW() functions return expressions that evaluate - to boolean true or false.

-

Q_RELPREC() returns the relative precision - difference as a signed integer.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/Q_SIGNSHFT.3 3.html b/static/freebsd/man3/Q_SIGNSHFT.3 3.html deleted file mode 100644 index abc0eca2..00000000 --- a/static/freebsd/man3/Q_SIGNSHFT.3 3.html +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - -
Q_SIGNSHFT(3)Library Functions ManualQ_SIGNSHFT(3)
-
-
-

-

Q_SIGNSHFT, - Q_SSIGN, Q_CRAWMASK, - Q_SRAWMASK, Q_GCRAW, - Q_GCVAL, Q_SCVAL — - fixed-point math functions which manipulate the - control/sign data bits

-
-
-

-

#include - <sys/qmath.h>

-

uint32_t -
- Q_SIGNSHFT(QTYPE - q);

-

QTYPE -
- Q_SSIGN(QTYPE - q, bool isneg);

-

ITYPE -
- Q_CRAWMASK(QTYPE - q);

-

ITYPE -
- Q_SRAWMASK(QTYPE - q);

-

ITYPE -
- Q_GCRAW(QTYPE - q);

-

ITYPE -
- Q_GCVAL(QTYPE - q);

-

QTYPE -
- Q_SCVAL(QTYPE - q, ITYPE cv);

-
-
-

-

() - gets the bit position of q's sign bit relative to bit - zero.

-

() - sets the sign bit of q based on the boolean - isneg.

-

() - and - () - return q-specific bit masks for - q's control bits and sign bit respectively.

-

() - and - () - get the raw masked control bits and value of q's - control bits respectively.

-

() - sets q's control bits to the value - cv.

-

All of those functions operate on the following data types: - s8q_t, u8q_t, - s16q_t, u16q_t, - s32q_t, u32q_t, - s64q_t, and u64q_t, which are - referred to generically as QTYPE. The - ITYPE refers to the stdint(7) - integer types.

-

For more details, see qmath(3).

-
-
-

-

Q_SIGNSHFT() returns the sign bit's - position as an integer.

-

Q_SSIGN() returns the value of - q post change.

-

Q_CRAWMASK(), - Q_SRAWMASK(), Q_GCRAW() and - Q_GCVAL() return their respective values as integers - of the same underlying ITYPE as q.

-

Q_SCVAL() returns the value of - q post change.

-
-
-

-

errno(2), qmath(3), - stdint(7)

-
-
-

-

The qmath(3) functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath(3) functions and this manual page were - written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/alloca.3 3.html b/static/freebsd/man3/alloca.3 3.html deleted file mode 100644 index ae0dd6bf..00000000 --- a/static/freebsd/man3/alloca.3 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
ALLOCA(3)Library Functions ManualALLOCA(3)
-
-
-

-

alloca — memory - allocator

-
-
-

-

#include - <stdlib.h>

-

void * -
- alloca(size_t - size);

-
-
-

-

The - () - function or macro allocates size bytes of space in the - stack frame of the caller. This temporary space is automatically freed on - return.

-
-
-

-

alloca() returns a pointer to the - beginning of the allocated space.

-
-
-

-

brk(2), calloc(3), - getpagesize(3), malloc(3), - realloc(3)

-
-
-

-

alloca() appeared in - Version 7 AT&T UNIX/32V.

-
-
-

-

alloca() is machine and compiler - dependent; its use is discouraged.

-

alloca() is slightly unsafe because it - cannot ensure that the pointer returned points to a valid and usable block - of memory. The allocation made may exceed the bounds of the stack, or even - go further into other objects in memory, and - alloca() cannot determine such an error. Avoid - alloca() with large unbounded allocations.

-

The use of C99 variable-length arrays and - alloca() in the same function will cause the - lifetime of alloca()'s storage to be limited to the - block containing the alloca(). For example, in the - following snippet, p's lifetime does not extend - outside of the block, whereas it would've if vla - hadn't been defined or had been defined as a fixed-length array:

-
-
char *p;
-{
-	const int n = 100;
-	int vla[n];
-	p = alloca(32);
-	strcpy(p, "Hello, world!");
-	printf("Inside: %s\n", p); /* Valid. */
-}
-printf("Outside: %s\n", p); /* Undefined. */
-
-
-
- - - - - -
February 19, 2026FreeBSD 15.0
diff --git a/static/freebsd/man3/arb.3 3.html b/static/freebsd/man3/arb.3 3.html deleted file mode 100644 index f8219d50..00000000 --- a/static/freebsd/man3/arb.3 3.html +++ /dev/null @@ -1,550 +0,0 @@ - - - - - - -
ARB(3)Library Functions ManualARB(3)
-
-
-

-

ARB_PROTOTYPE, - ARB_PROTOTYPE_STATIC, - ARB_PROTOTYPE_INSERT, - ARB_PROTOTYPE_INSERT_COLOR, - ARB_PROTOTYPE_REMOVE, - ARB_PROTOTYPE_REMOVE_COLOR, - ARB_PROTOTYPE_FIND, - ARB_PROTOTYPE_NFIND, - ARB_PROTOTYPE_NEXT, - ARB_PROTOTYPE_PREV, - ARB_PROTOTYPE_MINMAX, - ARB_PROTOTYPE_REINSERT, - ARB_GENERATE, - ARB_GENERATE_STATIC, - ARB_GENERATE_INSERT, - ARB_GENERATE_INSERT_COLOR, - ARB_GENERATE_REMOVE, - ARB_GENERATE_REMOVE_COLOR, - ARB_GENERATE_FIND, - ARB_GENERATE_NFIND, - ARB_GENERATE_NEXT, - ARB_GENERATE_PREV, - ARB_GENERATE_MINMAX, - ARB_GENERATE_REINSERT, - ARB8_ENTRY, ARB16_ENTRY, - ARB32_ENTRY, ARB8_HEAD, - ARB16_HEAD, ARB32_HEAD, - ARB_ALLOCSIZE, - ARB_INITIALIZER, ARB_ROOT, - ARB_EMPTY, ARB_FULL, - ARB_CURNODES, ARB_MAXNODES, - ARB_NEXT, ARB_PREV, - ARB_MIN, ARB_MAX, - ARB_FIND, ARB_NFIND, - ARB_LEFT, ARB_LEFTIDX, - ARB_RIGHT, ARB_RIGHTIDX, - ARB_PARENT, ARB_PARENTIDX, - ARB_GETFREE, ARB_FREEIDX, - ARB_FOREACH, - ARB_FOREACH_FROM, - ARB_FOREACH_SAFE, - ARB_FOREACH_REVERSE, - ARB_FOREACH_REVERSE_FROM, - ARB_FOREACH_REVERSE_SAFE, - ARB_INIT, ARB_INSERT, - ARB_REMOVE, ARB_REINSERT, - ARB_RESET_TREE — array-based - red-black trees

-
-
-

-

#include - <sys/arb.h>

-

ARB_PROTOTYPE(NAME, - TYPE, - FIELD, - CMP);

-

ARB_PROTOTYPE_STATIC(NAME, - TYPE, - FIELD, - CMP);

-

ARB_PROTOTYPE_INSERT(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_INSERT_COLOR(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_REMOVE(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_REMOVE_COLOR(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_FIND(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_NFIND(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_NEXT(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_PREV(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_MINMAX(NAME, - TYPE, - ATTR);

-

ARB_PROTOTYPE_REINSERT(NAME, - TYPE, - ATTR);

-

ARB_GENERATE(NAME, - TYPE, - FIELD, - CMP);

-

ARB_GENERATE_STATIC(NAME, - TYPE, - FIELD, - CMP);

-

ARB_GENERATE_INSERT(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

ARB_GENERATE_INSERT_COLOR(NAME, - TYPE, - FIELD, - ATTR);

-

ARB_GENERATE_REMOVE(NAME, - TYPE, - FIELD, - ATTR);

-

ARB_GENERATE_REMOVE_COLOR(NAME, - TYPE, - FIELD, - ATTR);

-

ARB_GENERATE_FIND(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

ARB_GENERATE_NFIND(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

ARB_GENERATE_NEXT(NAME, - TYPE, - FIELD, - ATTR);

-

ARB_GENERATE_PREV(NAME, - TYPE, - FIELD, - ATTR);

-

ARB_GENERATE_MINMAX(NAME, - TYPE, - FIELD, - ATTR);

-

ARB_GENERATE_REINSERT(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

ARB<8|16|32>_ENTRY();

-

ARB<8|16|32>_HEAD(HEADNAME, - TYPE);

-

size_t -
- ARB_ALLOCSIZE(ARB_HEAD - *head, - int<8|16|32>_t - maxnodes, struct TYPE - *elm);

-

ARB_INITIALIZER(ARB_HEAD - *head, - int<8|16|32>_t - maxnodes);

-

struct TYPE * -
- ARB_ROOT(ARB_HEAD - *head);

-

bool -
- ARB_EMPTY(ARB_HEAD - *head);

-

bool -
- ARB_FULL(ARB_HEAD - *head);

-

int<8|16|32>_t -
- ARB_CURNODES(ARB_HEAD - *head);

-

int<8|16|32>_t -
- ARB_MAXNODES(ARB_HEAD - *head);

-

struct TYPE * -
- ARB_NEXT(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- ARB_PREV(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- ARB_MIN(NAME, - ARB_HEAD *head);

-

struct TYPE * -
- ARB_MAX(NAME, - ARB_HEAD *head);

-

struct TYPE * -
- ARB_FIND(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- ARB_NFIND(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- ARB_LEFT(struct - TYPE *elm, ARB_ENTRY - NAME);

-

int<8|16|32>_t -
- ARB_LEFTIDX(struct - TYPE *elm, ARB_ENTRY - NAME);

-

struct TYPE * -
- ARB_RIGHT(struct - TYPE *elm, ARB_ENTRY - NAME);

-

int<8|16|32>_t -
- ARB_RIGHTIDX(struct - TYPE *elm, ARB_ENTRY - NAME);

-

struct TYPE * -
- ARB_PARENT(struct - TYPE *elm, ARB_ENTRY - NAME);

-

int<8|16|32>_t -
- ARB_PARENTIDX(struct - TYPE *elm, ARB_ENTRY - NAME);

-

struct TYPE * -
- ARB_GETFREE(ARB_HEAD - *head, FIELD);

-

int<8|16|32>_t -
- ARB_FREEIDX(ARB_HEAD - *head);

-

ARB_FOREACH(VARNAME, - NAME, - ARB_HEAD *head);

-

ARB_FOREACH_FROM(VARNAME, - NAME, - POS_VARNAME);

-

ARB_FOREACH_SAFE(VARNAME, - NAME, - ARB_HEAD *head, - TEMP_VARNAME);

-

ARB_FOREACH_REVERSE(VARNAME, - NAME, - ARB_HEAD *head);

-

ARB_FOREACH_REVERSE_FROM(VARNAME, - NAME, - POS_VARNAME);

-

ARB_FOREACH_REVERSE_SAFE(VARNAME, - NAME, - ARB_HEAD *head, - TEMP_VARNAME);

-

void -
- ARB_INIT(struct - TYPE *elm, FIELD, - ARB_HEAD *head, - int<8|16|32>_t - maxnodes);

-

struct TYPE * -
- ARB_INSERT(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- ARB_REMOVE(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- ARB_REINSERT(NAME, - ARB_HEAD *head, - struct TYPE *elm);

-

void -
- ARB_RESET_TREE(ARB_HEAD - *head, NAME, - int<8|16|32>_t - maxnodes);

-
-
-

-

These macros define data structures for and array-based red-black - trees. They use a single, continuous chunk of memory, and are useful e.g., - when the tree needs to be transferred between userspace and kernel.

-

In the macro definitions, TYPE - is the name tag of a user defined structure that must contain a field of - type ARB_ENTRY, named ENTRYNAME. - The argument HEADNAME is the name tag of a user - defined structure that must be declared using the - () - macro. The argument NAME has to be a unique name - prefix for every tree that is defined.

-

The function prototypes are declared with - (), - or - (). - The function bodies are generated with - ARB_GENERATE(), or - ARB_GENERATE_STATIC(). See the examples below for - further explanation of how these macros are used.

-

A red-black tree is a binary search tree with the node color as an - extra attribute. It fulfills a set of conditions:

-
    -
  1. Every search path from the root to a leaf consists of the same number of - black nodes.
    2. -
  2. Each red node (except for the root) has a black parent.
    3. -
  3. Each leaf node is black.
    4. -
-

Every operation on a red-black tree is bounded as - (lg - n). The maximum height of a red-black tree is - (n - + 1).

-

() - trees require entries to be allocated as an array, and uses array indices to - link entries together. The maximum number of ARB_*() - tree entries is therefore constrained by the minimum of array size and - choice of signed integer data type used to store array indices. Use - () - to compute the size of memory chunk to allocate.

-

A red-black tree is headed by a structure defined - by the - () - macro. A structure is declared with either of the following:

-
(HEADNAME, - TYPE) head;
-

where HEADNAME is the name of the structure - to be defined, and struct TYPE is the type of the - elements to be inserted into the tree.

-

The - () - variant includes a suffix denoting the signed integer data type size (in - bits) used to store array indices. For example, - () - creates a red-black tree head structure with 8-bit signed array indices - capable of indexing up to 128 entries.

-

The - () - macro declares a structure that allows elements to be connected in the tree. - Similarly to the - () - macro, the ARB_ENTRY() variant includes a suffix - denoting the signed integer data type size (in bits) used to store array - indices. Entries should use the same number of bits as the tree head - structure they will be linked into.

-

In order to use the functions that manipulate - the tree structure, their prototypes need to be declared with the - () - or - () - macro, where NAME is a unique identifier for this - particular tree. The TYPE argument is the type of the - structure that is being managed by the tree. The FIELD - argument is the name of the element defined by - ARB_ENTRY(). Individual prototypes can be declared - with - (), - (), - (), - (), - (), - (), - (), - (), - (), - and - () - in case not all functions are required. The individual prototype macros - expect NAME, TYPE, and - ATTR arguments. The ATTR - argument must be empty for global functions or static - for static functions.

-

The function bodies are generated with the - () - or - () - macro. These macros take the same arguments as the - ARB_PROTOTYPE() and - ARB_PROTOTYPE_STATIC() macros, but should be used - only once. As an alternative individual function bodies are generated with - the - (), - (), - (), - (), - (), - (), - (), - (), - (), - and - () - macros.

-

Finally, the CMP argument is the name of a - function used to compare tree nodes with each other. The function takes two - arguments of type struct TYPE *. If the first argument - is smaller than the second, the function returns a value smaller than zero. - If they are equal, the function returns zero. Otherwise, it should return a - value greater than zero. The compare function defines the order of the tree - elements.

-

The - () - macro initializes the tree referenced by head, with - the array length of maxnodes.

-

The red-black tree can also be initialized - statically by using the - () - macro:

-
(HEADNAME, - TYPE) head = - ARB_INITIALIZER(&head, - maxnodes);
-

The - () - macro inserts the new element elm into the tree.

-

The - () - macro removes the element elm from the tree pointed by - head.

-

The - () - and - () - macros can be used to find a particular element in the tree.

-
-
struct TYPE find, *res;
-find.key = 30;
-res = ARB_FIND(NAME, head, &find);
-
-

The - (), - (), - (), - (), - and - () - macros can be used to traverse the tree:

-

-
for (np = ARB_MIN(NAME, &head); - np != NULL; np = ARB_NEXT(NAME, &head, np))
-

Or, for simplicity, one can use the - () - or - () - macro:

-
ARB_FOREACH(np, - NAME, head)
-

The macros - () - and - () - traverse the tree referenced by head in a forward or reverse direction - respectively, assigning each element in turn to np. However, unlike their - unsafe counterparts, they permit both the removal of np as well as freeing - it from within the loop safely without interfering with the traversal.

-

Both - () - and - () - may be used to continue an interrupted traversal in a forward or reverse - direction respectively. The head pointer is not required. The pointer to the - node from where to resume the traversal should be passed as their last - argument, and will be overwritten to provide safe traversal.

-

The - () - macro should be used to check whether a red-black tree is empty.

-

Given that ARB trees have an intrinsic upper bound - on the number of entries, some ARB-specific additional macros are defined. - The - () - macro returns a boolean indicating whether the current number of tree - entries equals the tree's maximum. The - () - and - () - macros return the current and maximum number of entries respectively. The - () - macro returns a pointer to the next free entry in the array of entries, - ready to be linked into the tree. The ARB_INSERT() - returns NULL if the element was inserted in the tree - successfully, otherwise they return a pointer to the element with the - colliding key.

-

Accordingly, - () - returns the pointer to the removed element otherwise they return - NULL to indicate an error.

-

The - () - macro updates the position of the element elm in the - tree. This must be called if a member of a tree is - modified in a way that affects comparison, such as by modifying a node's - key. This is a lower overhead alternative to removing the element and - reinserting it again.

-

The - () - macro discards the tree topology. It does not modify embedded object values - or the free list.

-
-
-

-

queue(3), tree(3)

-
-
-

-

The ARB macros first appeared in - FreeBSD 13.0.

-
-
-

-

The ARB macros were implemented by - Lawrence Stewart - <lstewart@FreeBSD.org>, - based on tree(3) macros written by -
- Niels Provos.

-
-
- - - - - -
October 14, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/assert.3 3.html b/static/freebsd/man3/assert.3 3.html deleted file mode 100644 index b8d9739e..00000000 --- a/static/freebsd/man3/assert.3 3.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - -
ASSERT(3)Library Functions ManualASSERT(3)
-
-
-

-

assert, - static_assert — expression - verification macro

-
-
-

-

#include - <assert.h>

-

assert(expression);

-

static_assert(expression);

-

static_assert(expression, - message);

-
-
-

-

The - () - macro tests the given expression and if it is false, - the calling process is terminated. A diagnostic message is written to - stderr and the function abort(3) - is called, effectively terminating the program.

-

If expression is true, the - () - macro does nothing.

-

The - () - macro may be removed at compile time by defining - NDEBUG as a macro (e.g., by using the - cc(1) option - -DNDEBUG). Unlike most other - include files, <assert.h> - may be included multiple times. Each time whether or not - NDEBUG is defined determines the behavior of assert - from that point forward until the end of the unit or another include of - <assert.h>.

-

The - () - macro should only be used for ensuring the developer's expectations hold - true. It is not appropriate for regular run-time error detection.

-

The - () - macro expands to - (), - and, contrarily to assert(), makes assertions at - compile-time. Once the constraint is violated, the compiler produces a - diagnostic message including the string literal message, if provided. The - initial form of the _Static_assert() containing a - string literal message was introduced in C11 standard, and the other form - with no string literal is to be implemented by C2x and some compilers may - lack its adoption at present.

-
-
-

-

The assertion:

-
assert(1 == 0);
-generates a diagnostic message similar to the following: -
Assertion failed: (1 == 0), function - main, file main.c, line 100.
-

The following assert tries to assert there was no partial - read:

-
assert(read(fd, buf, nbytes) == - nbytes);
-However, there are two problems. First, it checks for normal conditions, rather - than conditions that indicate a bug. Second, the code will disappear if - NDEBUG is defined, changing the semantics of the - program. -

The following asserts that the size of the S structure is 16. - Otherwise, it produces a diagnostic message which points at the constraint - and includes the provided string literal:

-
static_assert(sizeof(struct S) == 16, - "size mismatch");
-If none is provided, it only points at the constraint. -
-
-

-

abort2(2), abort(3)

-
-
-

-

The assert() macro conforms to - ISO/IEC 9899:1999 - (“ISO C99”).

-

The static_assert() macro conforms to - ISO/IEC 9899:2011 - (“ISO C11”).

-
-
-

-

An assert macro appeared in - Version 7 AT&T UNIX.

-
-
- - - - - -
April 20, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/bitstring.3 3.html b/static/freebsd/man3/bitstring.3 3.html deleted file mode 100644 index 9a6b8fdf..00000000 --- a/static/freebsd/man3/bitstring.3 3.html +++ /dev/null @@ -1,380 +0,0 @@ - - - - - - -
BITSTRING(3)Library Functions ManualBITSTRING(3)
-
-
-

-

bit_alloc, - bit_clear, bit_count, - bit_decl, bit_ffc, - bit_ffs, bit_ff_at, - bit_ffc_at, bit_ffs_at, - bit_ffc_area, bit_ffs_area, - bit_ff_area_at, - bit_ffc_area_at, - bit_ffs_area_at, bit_nclear, - bit_nset, bit_ntest, - bit_set, bit_test, - bitstr_size — bit-string - manipulation functions and macros

-
-
-

-

#include - <bitstring.h>

-

bitstr_t * -
- bit_alloc(size_t - nbits);

-

void -
- bit_decl(bitstr_t - *name, size_t - nbits);

-

void -
- bit_clear(bitstr_t - *name, size_t - bit);

-

void -
- bit_count(bitstr_t - *name, size_t - count, size_t - nbits, ssize_t - *value);

-

void -
- bit_ffc(bitstr_t - *name, size_t - nbits, ssize_t - *value);

-

void -
- bit_ffs(bitstr_t - *name, size_t - nbits, ssize_t - *value);

-

void -
- bit_ffc_at(bitstr_t - *name, size_t - start, size_t - nbits, ssize_t - *value);

-

void -
- bit_ffs_at(bitstr_t - *name, size_t - start, size_t - nbits, ssize_t - *value);

-

void -
- bit_ff_at(bitstr_t - *name, size_t - start, size_t - nbits, int match, - ssize_t *value);

-

void -
- bit_ffc_area(bitstr_t - *name, size_t - nbits, size_t size, - ssize_t *value);

-

void -
- bit_ffs_area(bitstr_t - *name, size_t - nbits, size_t size, - ssize_t *value);

-

void -
- bit_ffc_area_at(bitstr_t - *name, size_t - start, size_t - nbits, size_t size, - ssize_t *value);

-

void -
- bit_ffs_area_at(bitstr_t - *name, size_t - start, size_t - nbits, size_t size, - ssize_t *value);

-

void -
- bit_ff_area_at(bitstr_t - *name, size_t - start, size_t - nbits, size_t size, - int match, - ssize_t *value);

-

bit_foreach(bitstr_t - *name, size_t - nbits, size_t - var);

-

bit_foreach_at(bitstr_t - *name, size_t - start, size_t - nbits, size_t - var);

-

bit_foreach_unset(bitstr_t - *name, size_t - nbits, size_t - var);

-

bit_foreach_unset_at(bitstr_t - *name, size_t - start, size_t - nbits, size_t - var);

-

void -
- bit_nclear(bitstr_t - *name, size_t - start, size_t - stop);

-

void -
- bit_nset(bitstr_t - *name, size_t - start, size_t - stop);

-

int -
- bit_ntest(bitstr_t - *name, size_t - start, size_t stop, - int match);

-

void -
- bit_set(bitstr_t - *name, size_t - bit);

-

int -
- bitstr_size(size_t - nbits);

-

int -
- bit_test(bitstr_t - *name, size_t - bit);

-
-
-

-

These macros operate on strings of bits.

-

The function - () - returns a pointer of type “bitstr_t *” - to sufficient space to store nbits bits, or - NULL if no space is available. If successful, the - returned bit string is initialized with all bits cleared.

-

The macro - () - declares a bit string with sufficient space to store - nbits bits. bit_decl() may be - used to include statically sized bit strings in structure definitions or to - create bit strings on the stack. Users of this macro are responsible for - initialization of the bit string, typically via a global initialization of - the containing struct or use of the bit_nset() or - () - functions.

-

The macro - () - returns the number of bytes necessary to store nbits - bits. This is useful for copying bit strings.

-

The functions - () - and - () - clear or set the zero-based numbered bit bit, in the - bit string name.

-

The - () - and - () - functions set or clear the zero-based numbered bits from - start through stop in the bit - string name.

-

The - () - function evaluates to non-zero if the zero-based numbered bit - bit of bit string name is set, - and zero otherwise.

-

The - () - function evaluates to non-zero if the zero-based numbered bits from - start through stop in the bit - string name all have the value - match.

-

The function - () - stores in the location referenced by value the - zero-based number of the first bit not set in the array of - nbits bits referenced by name. - If all bits are set, the location referenced by value - is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit set in the array of - nbits bits referenced by name. - If no bits are set, the location referenced by value - is set to -1.

-

The function - () - stores in the location referenced by value the - zero-based number of the first bit not set in the array of - nbits bits referenced by name, - at or after the zero-based bit index start. If all - bits at or after start are set, the location - referenced by value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit set in the array of - nbits bits referenced by name, - at or after the zero-based bit index start. If no bits - are set after start, the location referenced by - value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit in the array of - nbits bits referenced by name, - at or after the zero-based bit index start that has - value match. If no bits after - start match that value, the location referenced by - value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit beginning a sequence of unset bits of - at least size unset bits in the array of - nbits bits referenced by name. - If no sequence of contiguous unset bits of the specified - size can be found, the location referenced by - value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit beginning a sequence of set bits of - at least size set bits in the array of - nbits bits referenced by name. - If no sequence of contiguous set bits of the specified - size can be found, the location referenced by - value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit beginning a sequence of unset bits of - at least size unset bits in the array of - nbits bits referenced by name, - at or after the zero-based bit index start. If no - sequence of contiguous unset bits of the specified - size can be found at or after - start, the location referenced by - value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit beginning a sequence of set bits of - at least size set bits in the array of - nbits bits referenced by name, - at or after the zero-based bit index start. If no - sequence of contiguous set bits of the specified size - can be found at or after start, the location - referenced by value is set to -1.

-

The - () - function stores in the location referenced by value - the zero-based number of the first bit beginning a sequence of bits of at - least size bits in the array of - nbits bits referenced by name, - at or after the zero-based bit index start in which - all bits have the value match. If no sequence of - contiguous such bits of the specified size can be - found at or after start, the location referenced by - value is set to -1.

-

The - () - function stores in the location referenced by value - the number of bits set in the array of nbits bits - referenced by name, at or after the zero-based bit - index start.

-

The macro - () - traverses all set bits in the array of nbits - referenced by name in the forward direction, assigning - each location in turn to var.

-

The macro - () - traverses all set bits in the array of nbits - referenced by name in the forward direction at or - after the zero-based bit index start, assigning each - location in turn to var.

-

The macro - () - traverses all unset bits in the array of nbits - referenced by name in the forward direction, assigning - each location in turn to var.

-

The macro - () - traverses all unset bits in the array of nbits - referenced by name in the forward direction at or - after the zero-based bit index start, assigning each - location in turn to var.

-

The arguments in bit string macros are evaluated only once and may - safely have side effects.

-
-
-

-
-
#include <limits.h>
-#include <bitstring.h>
-
-...
-#define	LPR_BUSY_BIT		0
-#define	LPR_FORMAT_BIT		1
-#define	LPR_DOWNLOAD_BIT	2
-...
-#define	LPR_AVAILABLE_BIT	9
-#define	LPR_MAX_BITS		10
-
-make_lpr_available()
-{
-	bitstr_t bit_decl(bitlist, LPR_MAX_BITS);
-	...
-	bit_nclear(bitlist, 0, LPR_MAX_BITS - 1);
-	...
-	if (!bit_test(bitlist, LPR_BUSY_BIT)) {
-		bit_clear(bitlist, LPR_FORMAT_BIT);
-		bit_clear(bitlist, LPR_DOWNLOAD_BIT);
-		bit_set(bitlist, LPR_AVAILABLE_BIT);
-	}
-}
-
-
-
-

-

malloc(3), stdbit(3), - bitset(9)

-
-
-

-

The bitstring functions first appeared in - 4.4BSD.

-
-
- - - - - -
November 21, 2023FreeBSD 15.0
diff --git a/static/freebsd/man3/end.3 4.html b/static/freebsd/man3/end.3 4.html deleted file mode 100644 index d4224605..00000000 --- a/static/freebsd/man3/end.3 4.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - -
END(3)Library Functions ManualEND(3)
-
-
-

-

end, etext, - edata — end boundaries of - image segments

-
-
-

-

extern end; -
- extern etext; -
- extern edata;

-
-
-

-

The globals end, etext - and edata are program segment end addresses.

-

etext is the first address after the end of - the text segment.

-

edata is the first address after the end of - the initialized data segment.

-

end is the first address after the end of - the data segment (BSS) when the program is loaded. Use the - sbrk(2) system call with zero as its argument to find the - current end of the data segment.

-
-
-

-

sbrk(2), malloc(3), - a.out(5)

-
-
-

-

An end manual page appeared in - Version 6 AT&T UNIX.

-
-
-

-

Traditionally, no variable existed that pointed to the start of - the text segment because the text segment always started at address zero. - Although it is no longer valid to make this assumption, no variable similar - to the ones documented above exists to point to the start of the text - segment.

-
-
- - - - - -
August 28, 2000FreeBSD 15.0
diff --git a/static/freebsd/man3/fpgetround.3 4.html b/static/freebsd/man3/fpgetround.3 4.html deleted file mode 100644 index 4547c0b3..00000000 --- a/static/freebsd/man3/fpgetround.3 4.html +++ /dev/null @@ -1,161 +0,0 @@ - - - - - - -
FPGETROUND(3)Library Functions ManualFPGETROUND(3)
-
-
-

-

fpgetround, - fpsetround, fpsetprec, - fpgetprec, fpgetmask, - fpsetmask, fpgetsticky, - fpresetsticky — IEEE - floating point interface

-
-
-

-

#include - <ieeefp.h>

-
-
typedef enum {
-	FP_RN,		/* round to nearest */
-	FP_RM,		/* round down to minus infinity */
-	FP_RP,		/* round up to plus infinity */
-	FP_RZ		/* truncate */
-} fp_rnd_t;
-
-
-fp_rnd_t -
-fpgetround(void); -

fp_rnd_t -
- fpsetround(fp_rnd_t - direction);

-
-
typedef enum {
-	FP_PS,		/* 24 bit (single-precision) */
-	FP_PRS,		/* reserved */
-	FP_PD,		/* 53 bit (double-precision) */
-	FP_PE		/* 64 bit (extended-precision) */
-} fp_prec_t;
-
-
-fp_prec_t -
-fpgetprec(void); -

fp_prec_t -
- fpsetprec(fp_prec_t - precision);

-
-
#define fp_except_t	int
-#define FP_X_INV	0x01	/* invalid operation */
-#define FP_X_DNML	0x02	/* denormal */
-#define FP_X_DZ		0x04	/* zero divide */
-#define FP_X_OFL	0x08	/* overflow */
-#define FP_X_UFL	0x10	/* underflow */
-#define FP_X_IMP	0x20	/* (im)precision */
-#define FP_X_STK	0x40	/* stack fault */
-
-
-fp_except_t -
-fpgetmask(void); -

fp_except_t -
- fpsetmask(fp_except_t - mask);

-

fp_except_t -
- fpgetsticky(void);

-

fp_except_t -
- fpresetsticky(fp_except_t - sticky);

-
-
-

-

The routines described herein are deprecated. New code should use - the functionality provided by fenv(3).

-

When a floating point exception is detected, the exception sticky - flag is set and the exception mask is tested. If the mask is set, then a - trap occurs. These routines allow both setting the floating point exception - masks, and resetting the exception sticky flags after an exception is - detected. In addition, they allow setting the floating point rounding mode - and precision.

-

The - () - function returns the current floating point rounding mode.

-

The - () - function sets the floating point rounding mode and returns the previous - mode.

-

The - () - function returns the current floating point precision.

-

The - () - function sets the floating point precision and returns the previous - precision.

-

The - () - function returns the current floating point exception masks.

-

The - () - function sets the floating point exception masks and returns the previous - masks.

-

The - () - function returns the current floating point sticky flags.

-

The - () - function clears the floating point sticky flags and returns the previous - flags.

-

Sample code which prevents a trap on divide-by-zero:

-
-
fpsetmask(~FP_X_DZ);
-a = 1.0;
-b = 0;
-c = a / b;
-fpresetsticky(FP_X_DZ);
-fpsetmask(FP_X_DZ);
-
-
-
-

-

The fpgetprec() and - fpsetprec() functions provide functionality - unavailable on many platforms. At present, they are implemented only on the - i386 and amd64 platforms. Changing precision is not a supported feature: it - may be ineffective when code is compiled to take advantage of SSE, and many - library functions and compiler optimizations depend upon the default - precision for correct behavior.

-
-
-

-

fenv(3), isnan(3)

-
-
-

-

These routines are based on SysV/386 routines of the same - name.

-
-
-

-

After a floating point exception and before a mask is set, the - sticky flags must be reset. If another exception occurs before the sticky - flags are reset, then a wrong exception type may be signaled.

-
-
- - - - - -
December 3, 2010FreeBSD 15.0
diff --git a/static/freebsd/man3/intro.3 3.html b/static/freebsd/man3/intro.3 3.html deleted file mode 100644 index fc96555d..00000000 --- a/static/freebsd/man3/intro.3 3.html +++ /dev/null @@ -1,262 +0,0 @@ - - - - - - -
INTRO(3)Library Functions ManualINTRO(3)
-
-
-

-

intro — - introduction to the C libraries

-
-
-

- - - - - -
cc[flags] file ... - [-llibrary]
-
-
-

-

This section provides an overview of the C library functions, - their error returns and other common definitions and concepts. Most of these - functions are available from the C library, libc. Other - libraries, such as the math library, libm, must be - indicated at compile time with the -l option of the - compiler.

-

The various libraries (followed by the loader flag):

-
-
-
(-lbluetooth) The bluetooth - library. See bluetooth(3).
-
-
(-lc) Standard C library - functions. When using the C compiler cc(1), it is not - necessary to supply the loader flag - -lc for these functions. - There are several `libraries' or groups of functions included inside of - libc: -
-
standard I/O routines
-
see stdio(3)
-
database routines
-
see db(3)
-
bit string operators
-
see bitstring(3)
-
bit and byte utilities
-
see stdbit(3)
-
string operators
-
see string(3) and bstring(3)
-
character tests and character operators
-
see ctype(3)
-
storage allocation
-
see mpool(3)
-
regular-expressions
-
see regex(3)
-
remote procedure calls (RPC)
-
see rpc(3)
-
time functions
-
see time(3)
-
signal handling
-
see signal(3)
-
-
-
-
(-lcalendar) The calendar - arithmetic library. See calendar(3).
-
-
(-lcam) The common access - method user library. See cam(3).
-
-
(-lcrypt) The crypt library. - See crypt(3).
-
-
(-lcurses - -ltermcap) Terminal - independent screen management routines for two dimensional non-bitmap - display terminals. See ncurses(3).
-
-
(-lcuse) The userland - character device library. See cuse(3).
-
-
(-lcompat) Functions which - are obsolete but are available for compatibility with - 4.3BSD. In particular, a number of system call - interfaces provided in previous releases of BSD - have been included for source code compatibility. Use of these routines - should, for the most part, be avoided. The manual page entry for each - compatibility routine indicates the proper interface to use.
-
-
(-ldevinfo) The Device and - Resource Information Utility library. See - devinfo(3).
-
-
(-ldevstat) The Device - Statistics library. See devstat(3).
-
-
(-ldwarf) The DWARF access - library. See dwarf(3).
-
-
(-lelf) The ELF access - library. See elf(3).
-
-
(-lfetch) The file transfer - library. See fetch(3).
-
-
(-lfigpar) The configuration - file parsing library. See figpar(3).
-
-
(-lgpio) The general-purpose - input output library (GPIO). See gpio(3).
-
-
(-lgssapi) The generic - security service application programming interface. See - gssapi(3).
-
-
(-ljail) The jail library. - See jail(3).
-
-
(-lkvm) Functions used to - access kernel memory are in this library. They can be used against both a - running system and a crash dump. See kvm(3).
-
-
(-ll) The library for - lex(1).
-
-
(-lm) The math library. See - math(3).
-
-
(-lmd) The message digest - library. See md4(3), md5(3), - sha(3), sha256(3), - sha512(3), ripemd(3), - skein(3).
-
-
(-lmp)
-
-
(-lpam) The pluggable - authentication module library. See pam(3).
-
-
(-lpcap) The packet capture - library. See pcap(3).
-
-
(-lpmc) The performance - counters library. See pmc(3).
-
-
(-lpthread) The POSIX - threads library. See pthread(3).
-
-
(-lstdthreads) The ISO C11 - standard <threads.h> - library. See thrd_create(3).
-
-
(-lsysdecode) The system - argument decoding library. See sysdecode(3).
-
-
(-ltermcap) The terminal - independent operation library package. See - termcap(3).
-
-
(-lusb) The USB access - library. See usb(3).
-
-
(-lvgl) The video graphics - library. See vgl(3).
-
-
(-ly) The library for - yacc(1).
-
-
(-lz) The general-purpose - data compression library. See zlib(3).
-
-
-
-

-
-
/usr/lib/libc.a
-
the C library
-
/usr/lib/libm.a
-
the math library
-
-
-
-

-

The system libraries are located in /lib - and /usr/lib. A library has the following naming - convention:

-
-
libc.so.7
-
-

Libraries with an ‘.a’ suffix are static. When a - program is linked against a static library, all necessary library code will - be included in the binary. This means the binary can be run even when the - libraries are unavailable. However, it can be inefficient with both disk - space and memory usage during execution. The C compiler, - cc(1), can be instructed to link statically by specifying - the -static flag.

-

Libraries with a ‘.so.X’ suffix are dynamic - libraries. When code is linked dynamically, the library code that the - application needs is not included in the binary. Instead, data structures - are added containing information about which dynamic libraries to link with. - When the binary is executed, the run-time linker ld.so(1) - reads these data structures and loads them into the process virtual address - space. rtld(1) loads the shared libraries when the program - is executed.

-

‘X’ represents the library version number of the - library. In the example above, a binary linked with - libc.so.8 would not be usable on a system where only - libc.so.7 is available.

-

The advantages of dynamic libraries are that multiple instances of - the same library can share address space, and the physical size of the - binary is smaller. A namespace per shared library is available via hidden - visibility, allowing multiple compilation units in a library to share things - without making them available to other libraries. It is possible to load - libraries dynamically via dlopen(3). The disadvantage is - the added complexity that comes with loading the libraries dynamically, and - the extra time taken to load the libraries. Of course, if the libraries are - not available, the binary will be unable to execute. Calls across shared - libraries are also slightly slower and cannot be inlined, not even with link - time optimization. The C compiler, cc(1), can be - instructed to link dynamically by specifying the - -shared flag.

-

Shared libraries, as well as static libraries on architectures - which produce position-independent executables (PIEs) by default, contain - position-independent code (PIC). Normally, compilers produce relocatable - code. Relocatable code needs to be modified at run-time, depending on where - in memory it is to be run. The C compiler, cc(1), can be - instructed to generate PIC code by specifying the - -fPIC flag.

-

Static libraries are generated using the ar(1) - utility. The libraries contain an index to the contents of the library, - stored within the library itself. The index lists each symbol defined by a - member of a library that is a relocatable object file. This speeds up - linking to the library, and allows routines in the library to call each - other regardless of their placement within the library.

-
-
-

-

ar(1), cc(1), - ld(1), nm(1), - intro(2), math(3), - stdio(3), make.conf(5), - src.conf(5)

-
-
-

-

An intro manual appeared in - Version 7 AT&T UNIX.

-
-
- - - - - -
November 10, 2025FreeBSD 15.0
diff --git a/static/freebsd/man3/makedev.3 3.html b/static/freebsd/man3/makedev.3 3.html deleted file mode 100644 index ee9cb148..00000000 --- a/static/freebsd/man3/makedev.3 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
MAKEDEV(3)Library Functions ManualMAKEDEV(3)
-
-
-

-

makedev, major, - minor — device number - conversion

-
-
-

-

#include - <sys/types.h>

-

dev_t -
- makedev(int - major, int - minor);

-

int -
- major(dev_t - dev);

-

int -
- minor(dev_t - dev);

-
-
-

-

The - () - macro returns a device number created from the provided - major and minor number. The - () - and - () - macros return the original numbers from the device number - dev. In other words, for a value - dev of the type dev_t, and - values ma, mi of the type - int, the assertions

-
dev == makedev(major(dev), - minor(dev))
-
ma == major(makedev(ma, - mi))
-
mi == minor(makedev(ma, - mi))
-are valid. -

In previous implementations of FreeBSD all - block and character devices were uniquely identified by a pair of stable - major and minor numbers. The major number referred to a certain device class - (e.g. disks, TTYs) while the minor number identified an instance within the - device class. Later versions of FreeBSD - automatically generate a unique device number for each character device - visible in /dev/. These numbers are not divided in - device classes and are not guaranteed to be stable upon reboot or driver - reload.

-

On FreeBSD these macros are only used by - utilities that need to exchange numbers with other operating systems that - may use different encodings for dev_t, but also - applications that present these numbers to the user in a more conventional - way.

-
-
-

-

The major() and - minor() macros return numbers whose value can span - the complete range of an int.

-
-
-

-

mknod(2), devname(3), - devfs(4)

-
-
- - - - - -
August 3, 2017FreeBSD 15.0
diff --git a/static/freebsd/man3/offsetof.3 4.html b/static/freebsd/man3/offsetof.3 4.html deleted file mode 100644 index 99b78ff5..00000000 --- a/static/freebsd/man3/offsetof.3 4.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - -
OFFSETOF(3)Library Functions ManualOFFSETOF(3)
-
-
-

-

offsetof — offset - of a structure member

-
-
-

-

#include - <stddef.h>

-

size_t -
- offsetof(type, - member);

-
-
-

-

The - () - macro expands to an integer constant expression of type - size_t and yields the offset, in bytes, of the field - member from the start of the structure - type.

-

A compiler error will result if member is - not aligned to a byte boundary (i.e. it is a bit-field).

-
-
-

-

The offsetof() macro conforms to - ANSI X3.159-1989 - (“ANSI C89”).

-
-
- - - - - -
February 18, 2010FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread.3 3.html b/static/freebsd/man3/pthread.3 3.html deleted file mode 100644 index 5f60899b..00000000 --- a/static/freebsd/man3/pthread.3 3.html +++ /dev/null @@ -1,466 +0,0 @@ - - - - - - -
PTHREAD(3)Library Functions ManualPTHREAD(3)
-
-
-

-

pthread — POSIX - thread functions

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-
-
-

-

POSIX threads are a set of functions that support applications - with requirements for multiple flows of control, called - , - within a process. Multithreading is used to improve the performance of a - program.

-

The POSIX thread functions are summarized in this section in the - following groups:

-

-
    -
  • Thread Routines
    • -
  • Attribute Object Routines
    • -
  • Mutex Routines
    • -
  • Condition Variable Routines
    • -
  • Read/Write Lock Routines
    • -
  • Per-Thread Context Routines
    • -
  • Cleanup Routines
    • -
-

FreeBSD extensions to the POSIX thread - functions are summarized in pthread_np(3).

-
-

-
-
int - (pthread_t - *thread, const pthread_attr_t *attr, - void *(*start_routine)(void *), void - *arg);
-
Creates a new thread of execution.
-
int - (pthread_t - thread)
-
Cancels execution of a thread.
-
int - (pthread_t - thread)
-
Marks a thread for deletion.
-
int - (pthread_t - t1, pthread_t t2)
-
Compares two thread IDs.
-
void - (void - *value_ptr)
-
Terminates the calling thread.
-
int - (pthread_t - thread, void **value_ptr)
-
Causes the calling thread to wait for the termination of the specified - thread.
-
int - (pthread_t - thread, int sig)
-
Delivers a signal to a specified thread.
-
int - (pthread_once_t - *once_control, void (*init_routine)(void))
-
Calls an initialization routine once.
-
pthread_t - (void)
-
Returns the thread ID of the calling thread.
-
int - (int - state, int *oldstate)
-
Sets the current thread's cancelability state.
-
int - (int - type, int *oldtype)
-
Sets the current thread's cancelability type.
-
void - (void)
-
Creates a cancellation point in the calling thread.
-
void - (void)
-
Allows the scheduler to run another thread instead of the current - one.
-
-
-
-

-
-
int - (pthread_attr_t - *attr)
-
Destroy a thread attributes object.
-
int - (const - pthread_attr_t *attr, int *inheritsched);
-
Get the inherit scheduling attribute from a thread attributes object.
-
int - (const - pthread_attr_t *attr, struct sched_param - *param);
-
Get the scheduling parameter attribute from a thread attributes - object.
-
int - (const - pthread_attr_t *attr, int *policy)
-
Get the scheduling policy attribute from a thread attributes object.
-
int - (const - pthread_attr_t *attr, int *contentionscope)
-
Get the contention scope attribute from a thread attributes object.
-
int - (const - pthread_attr_t *attr, size_t *stacksize)
-
Get the stack size attribute from a thread attributes object.
-
int - (const - pthread_attr_t *attr, void **stackaddr)
-
Get the stack address attribute from a thread attributes object.
-
int - (const - pthread_attr_t *attr, int *detachstate)
-
Get the detach state attribute from a thread attributes object.
-
int - (pthread_attr_t - *attr)
-
Initialize a thread attributes object with default values.
-
int - (pthread_attr_t - *attr, int inheritsched)
-
Set the inherit scheduling attribute in a thread attributes object.
-
int - (pthread_attr_t - *attr, const struct sched_param *param);
-
Set the scheduling parameter attribute in a thread attributes object.
-
int - (pthread_attr_t - *attr, int policy)
-
Set the scheduling policy attribute in a thread attributes object.
-
int - (pthread_attr_t - *attr, int contentionscope)
-
Set the contention scope attribute in a thread attributes object.
-
int - (pthread_attr_t - *attr, size_t stacksize)
-
Set the stack size attribute in a thread attributes object.
-
int - (pthread_attr_t - *attr, void *stackaddr)
-
Set the stack address attribute in a thread attributes object.
-
int - (pthread_attr_t - *attr, int detachstate)
-
Set the detach state in a thread attributes object.
-
-
-
-

-
-
int - (pthread_mutexattr_t - *attr)
-
Destroy a mutex attributes object.
-
int - (const - pthread_mutexattr_t *restrict attr, int *restrict - ceiling)
-
Obtain priority ceiling attribute of mutex attribute object.
-
int - (const - pthread_mutexattr_t *restrict attr, int *restrict - protocol)
-
Obtain protocol attribute of mutex attribute object.
-
int - (const - pthread_mutexattr_t *restrict attr, int *restrict - type)
-
Obtain the mutex type attribute in the specified mutex attributes - object.
-
int - (pthread_mutexattr_t - *attr)
-
Initialize a mutex attributes object with default values.
-
int - (pthread_mutexattr_t - *attr, int ceiling)
-
Set priority ceiling attribute of mutex attribute object.
-
int - (pthread_mutexattr_t - *attr, int protocol)
-
Set protocol attribute of mutex attribute object.
-
int - (pthread_mutexattr_t - *attr, int type)
-
Set the mutex type attribute that is used when a mutex is created.
-
int - (pthread_mutex_t - *mutex)
-
Destroy a mutex.
-
int - (pthread_mutex_t - *mutex, const pthread_mutexattr_t *attr);
-
Initialize a mutex with specified attributes.
-
int - (pthread_mutex_t - *mutex)
-
Lock a mutex and block until it becomes available.
-
int - (pthread_mutex_t - *mutex, const struct timespec *abstime);
-
Lock a mutex and block until it becomes available or until the timeout - expires.
-
int - (pthread_mutex_t - *mutex)
-
Try to lock a mutex, but do not block if the mutex is locked by another - thread, including the current thread.
-
int - (pthread_mutex_t - *mutex)
-
Unlock a mutex.
-
-
-
-

-
-
int - (pthread_condattr_t - *attr)
-
Destroy a condition variable attributes object.
-
int - (pthread_condattr_t - *attr)
-
Initialize a condition variable attributes object with default - values.
-
int - (pthread_cond_t - *cond)
-
Unblock all threads currently blocked on the specified condition - variable.
-
int - (pthread_cond_t - *cond)
-
Destroy a condition variable.
-
int - (pthread_cond_t - *cond, const pthread_condattr_t *attr)
-
Initialize a condition variable with specified attributes.
-
int - (pthread_cond_t - *cond)
-
Unblock at least one of the threads blocked on the specified condition - variable.
-
int - (pthread_cond_t - *cond, pthread_mutex_t *mutex, - const struct timespec *abstime);
-
Unlock the specified mutex, wait no longer than the specified time for a - condition, and then relock the mutex.
-
int - (pthread_cond_t - *, pthread_mutex_t *mutex)
-
Unlock the specified mutex, wait for a condition, and relock the - mutex.
-
-
-
-

-
-
int - (pthread_rwlock_t - *lock)
-
Destroy a read/write lock object.
-
int - (pthread_rwlock_t - *lock, const pthread_rwlockattr_t *attr);
-
Initialize a read/write lock object.
-
int - (pthread_rwlock_t - *lock)
-
Lock a read/write lock for reading, blocking until the lock can be - acquired.
-
int - (pthread_rwlock_t - *lock)
-
Attempt to lock a read/write lock for reading, without blocking if the - lock is unavailable.
-
int - (pthread_rwlock_t - *lock)
-
Attempt to lock a read/write lock for writing, without blocking if the - lock is unavailable.
-
int - (pthread_rwlock_t - *lock)
-
Unlock a read/write lock.
-
int - (pthread_rwlock_t - *lock)
-
Lock a read/write lock for writing, blocking until the lock can be - acquired.
-
int - (pthread_rwlockattr_t - *attr)
-
Destroy a read/write lock attribute object.
-
int - (const - pthread_rwlockattr_t *attr, int *pshared);
-
Retrieve the process shared setting for the read/write lock attribute - object.
-
int - (pthread_rwlockattr_t - *attr)
-
Initialize a read/write lock attribute object.
-
int - (pthread_rwlockattr_t - *attr, int pshared)
-
Set the process shared setting for the read/write lock attribute - object.
-
-
-
-

-
-
int - (pthread_key_t - *key, void (*routine)(void *))
-
Create a thread-specific data key.
-
int - (pthread_key_t - key)
-
Delete a thread-specific data key.
-
void * - (pthread_key_t - key)
-
Get the thread-specific value for the specified key.
-
int - (pthread_key_t - key, const void *value_ptr)
-
Set the thread-specific value for the specified key.
-
-
-
-

-
-
int - (void - (*prepare)(void), void (*parent)(void), - void (*child)(void));
-
Register fork handlers.
-
void - (int - execute)
-
Remove the routine at the top of the calling thread's cancellation cleanup - stack and optionally invoke it.
-
void - (void - (*routine)(void *), void *routine_arg)
-
Push the specified cancellation cleanup handler onto the calling thread's - cancellation stack.
-
-
-
-
-

-

The current FreeBSD POSIX thread - implementation is built into the 1:1 Threading Library - (libthr, -lthr) library. It contains thread-safe versions of - Standard C Library (libc, -lc) functions and - the thread functions. Threaded applications are linked with this - library.

-
-
-

-

libthr(3), pthread_atfork(3), - pthread_attr(3), pthread_cancel(3), - pthread_cleanup_pop(3), - pthread_cleanup_push(3), - pthread_cond_broadcast(3), - pthread_cond_destroy(3), - pthread_cond_init(3), - pthread_cond_signal(3), - pthread_cond_timedwait(3), - pthread_cond_wait(3), - pthread_condattr_destroy(3), - pthread_condattr_init(3), - pthread_create(3), pthread_detach(3), - pthread_equal(3), pthread_exit(3), - pthread_getspecific(3), pthread_join(3), - pthread_key_delete(3), pthread_kill(3), - pthread_mutex_destroy(3), - pthread_mutex_init(3), - pthread_mutex_lock(3), - pthread_mutex_trylock(3), - pthread_mutex_unlock(3), - pthread_mutexattr_destroy(3), - pthread_mutexattr_getprioceiling(3), - pthread_mutexattr_getprotocol(3), - pthread_mutexattr_gettype(3), - pthread_mutexattr_init(3), - pthread_mutexattr_setprioceiling(3), - pthread_mutexattr_setprotocol(3), - pthread_mutexattr_settype(3), - pthread_np(3), pthread_once(3), - pthread_rwlock_destroy(3), - pthread_rwlock_init(3), - pthread_rwlock_rdlock(3), - pthread_rwlock_unlock(3), - pthread_rwlock_wrlock(3), - pthread_rwlockattr_destroy(3), - pthread_rwlockattr_getpshared(3), - pthread_rwlockattr_init(3), - pthread_rwlockattr_setpshared(3), - pthread_self(3), - pthread_setcancelstate(3), - pthread_setcanceltype(3), - pthread_setspecific(3), - pthread_testcancel(3)

-
-
-

-

The functions with the pthread_ prefix and - not _np suffix or - pthread_rwlock prefix conform to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-

The functions with the pthread_ prefix and - _np suffix are non-portable extensions to POSIX - threads.

-

The functions with the pthread_rwlock - prefix are extensions created by The Open Group as part of the - Version 2 of the Single UNIX Specification - (“SUSv2”).

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_affinity_np.3 3.html b/static/freebsd/man3/pthread_affinity_np.3 3.html deleted file mode 100644 index c239533c..00000000 --- a/static/freebsd/man3/pthread_affinity_np.3 3.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - -
PTHREAD_AFFINITY_NP(3)Library Functions ManualPTHREAD_AFFINITY_NP(3)
-
-
-

-

pthread_getaffinity_np, - pthread_setaffinity_np — - manage CPU affinity

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_getaffinity_np(pthread_t - td, size_t - cpusetsize, cpuset_t - *cpusetp);

-

int -
- pthread_setaffinity_np(pthread_t - td, size_t - cpusetsize, const - cpuset_t *cpusetp);

-
-
-

-

() - and pthread_setaffinity_np() allow the manipulation - of sets of CPUs available to the specified thread.

-

Masks of type - cpuset_t are composed using the - CPU_SET macros. If the user-supplied mask is not - large enough to fit all of the matching CPUs, - () - fails with ERANGE. Calls to - pthread_setaffinity_np() tolerate masks of any size - with no restrictions. The kernel uses the meaningful part of the mask, where - the upper bound is the maximum CPU id present in the system. If bits for - non-existing CPUs are set, calls to - pthread_setaffinity_np() fail with - EINVAL.

-

The supplied mask should have a size of - cpusetsize bytes. This size is usually provided by - calling sizeof(cpuset_t) which is ultimately - determined by the value of CPU_SETSIZE as defined in - <sys/cpuset.h>.

-

() - retrieves the mask from the thread specified by td, - and stores it in the space provided by cpusetp.

-

() - attempts to set the mask for the thread specified by - td to the value in cpusetp.

-
-
-

-

If successful, the - pthread_getaffinity_np() and - pthread_setaffinity_np() functions will return zero. - Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_getaffinity_np() and - pthread_setaffinity_np() functions may fail if:

-
-
[]
-
The cpusetp argument specified when calling - pthread_setaffinity_np() was not a valid - value.
-
[]
-
The pthread_setaffinity_np() call would leave a - thread without a valid CPU to run on because the set does not overlap with - the thread's anonymous mask.
-
[]
-
The cpusetp pointer passed was invalid.
-
[]
-
The thread specified by the td argument could not be - found.
-
[]
-
The cpusetsize was smaller than needed to fit all of - the matching CPUs.
-
[]
-
The calling thread did not have the credentials required to complete the - operation.
-
-
-
-

-

cpuset(1), cpuset(2), - cpuset_getid(2), cpuset_setid(2), - pthread(3), - pthread_attr_getaffinity_np(3), - pthread_attr_setaffinity_np(3), - pthread_np(3)

-
-
-

-

The pthread_getaffinity_np and - pthread_setaffinity_np functions are non-standard - FreeBSD extensions and may be not available on other - operating systems.

-
-
-

-

The pthread_getaffinity_np and - pthread_setaffinity_np function first appeared in - FreeBSD 7.2.

-
-
-

-

The pthread_getaffinity_np and - pthread_setaffinity_np functions were written by - David Xu - <davidxu@FreeBSD.org>, - and this manpage was written by Xin LI - <delphij@FreeBSD.org>.

-
-
- - - - - -
January 29, 2023FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_atfork.3 3.html b/static/freebsd/man3/pthread_atfork.3 3.html deleted file mode 100644 index b0774124..00000000 --- a/static/freebsd/man3/pthread_atfork.3 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
PTHREAD_ATFORK(3)Library Functions ManualPTHREAD_ATFORK(3)
-
-
-

-

pthread_atfork — - register fork handlers

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_atfork(void - (*prepare)(void), void (*parent)(void), - void (*child)(void));

-
-
-

-

The - () - function declares fork handlers to be called before and after - fork(2), in the context of the thread that called - fork(2).

-

The handlers registered with - () - are called at the moments in time described below:

-
-
prepare
-
Before fork(2) processing commences in the parent - process. If more than one prepare handler is - registered they will be called in the opposite order they were - registered.
-
parent
-
After fork(2) completes in the parent process. If more - than one parent handler is registered they will be - called in the same order they were registered.
-
child
-
After fork(2) processing completes in the child process. - If more than one child handler is registered they - will be called in the same order they were registered.
-
-

If no handling is desired at one or more of these three points, a - null pointer may be passed as the corresponding fork handler.

-
-
-

-

If successful, the pthread_atfork() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_atfork() function will fail - if:

-
-
[]
-
Insufficient table space exists to record the fork handler addresses.
-
-
-
-

-

fork(2), pthread(3)

-
-
-

-

The pthread_atfork() function is expected - to conform to IEEE Std 1003.1 - (“POSIX.1”).

-
-
-

-

This manpage was written by Alex Vasylenko - <lxv@omut.org>.

-
-
- - - - - -
June 21, 2004FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_attr.3 3.html b/static/freebsd/man3/pthread_attr.3 3.html deleted file mode 100644 index 44ab49e9..00000000 --- a/static/freebsd/man3/pthread_attr.3 3.html +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - -
PTHREAD_ATTR(3)Library Functions ManualPTHREAD_ATTR(3)
-
-
-

-

pthread_attr_init, - pthread_attr_destroy, - pthread_attr_setstack, - pthread_attr_getstack, - pthread_attr_setstacksize, - pthread_attr_getstacksize, - pthread_attr_setguardsize, - pthread_attr_getguardsize, - pthread_attr_setstackaddr, - pthread_attr_getstackaddr, - pthread_attr_setdetachstate, - pthread_attr_getdetachstate, - pthread_attr_setinheritsched, - pthread_attr_getinheritsched, - pthread_attr_setschedparam, - pthread_attr_getschedparam, - pthread_attr_setschedpolicy, - pthread_attr_getschedpolicy, - pthread_attr_setscope, - pthread_attr_getscope — - thread attribute operations

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_attr_init(pthread_attr_t - *attr);

-

int -
- pthread_attr_destroy(pthread_attr_t - *attr);

-

int -
- pthread_attr_setstack(pthread_attr_t - *attr, void - *stackaddr, size_t - stacksize);

-

int -
- pthread_attr_getstack(const - pthread_attr_t * restrict attr, - void ** restrict - stackaddr, size_t * - restrict stacksize);

-

int -
- pthread_attr_setstacksize(pthread_attr_t - *attr, size_t - stacksize);

-

int -
- pthread_attr_getstacksize(const - pthread_attr_t *restrict attr, - size_t *restrict - stacksize);

-

int -
- pthread_attr_setguardsize(pthread_attr_t - *attr, size_t - guardsize);

-

int -
- pthread_attr_getguardsize(const - pthread_attr_t * restrict attr, - size_t * restrict - guardsize);

-

int -
- pthread_attr_setstackaddr(pthread_attr_t - *attr, void - *stackaddr);

-

int -
- pthread_attr_getstackaddr(const - pthread_attr_t *attr, - void **stackaddr);

-

int -
- pthread_attr_setdetachstate(pthread_attr_t - *attr, int - detachstate);

-

int -
- pthread_attr_getdetachstate(const - pthread_attr_t *attr, int - *detachstate);

-

int -
- pthread_attr_setinheritsched(pthread_attr_t - *attr, int - inheritsched);

-

int -
- pthread_attr_getinheritsched(const - pthread_attr_t *restrict attr, - int *restrct - inheritsched);

-

int -
- pthread_attr_setschedparam(pthread_attr_t - *attr, const struct - sched_param *param);

-

int -
- pthread_attr_getschedparam(const - pthread_attr_t *attr, - struct sched_param - *param);

-

int -
- pthread_attr_setschedpolicy(pthread_attr_t - *attr, int - policy);

-

int -
- pthread_attr_getschedpolicy(const - pthread_attr_t *restrict attr, - int *restrict - policy);

-

int -
- pthread_attr_setscope(pthread_attr_t - *attr, int - contentionscope);

-

int -
- pthread_attr_getscope(const - pthread_attr_t *restrict attr, - int *restrict - contentionscope);

-
-
-

-

Thread attributes are used to specify parameters to - (). - One attribute object can be used in multiple calls to - pthread_create(), with or without modifications - between calls.

-

The - () - function initializes attr with all the default thread - attributes.

-

The - () - function destroys attr.

-

The - () - functions set the attribute that corresponds to each function name.

-

The - () - functions copy the value of the attribute that corresponds to each function - name to the location pointed to by the second function parameter.

-
-
-

-

If successful, these functions return 0. Otherwise, an error - number is returned to indicate the error.

-
-
-

-

The pthread_attr_init() function will fail - if:

-
-
[]
-
Out of memory.
-
-

The pthread_attr_destroy() function will - fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_attr_setstacksize() and - pthread_attr_setstack() functions will fail if:

-
-
[]
-
stacksize is less than - PTHREAD_STACK_MIN.
-
-

The pthread_attr_setdetachstate() function - will fail if:

-
-
[]
-
Invalid value for detachstate.
-
-

The pthread_attr_setinheritsched() - function will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_attr_setschedparam() function - will fail if:

-
-
[]
-
Invalid value for attr.
-
[]
-
Invalid value for param.
-
-

The pthread_attr_setschedpolicy() function - will fail if:

-
-
[]
-
Invalid value for attr.
-
[]
-
Invalid or unsupported value for policy.
-
-

The pthread_attr_setscope() function will - fail if:

-
-
[]
-
Invalid value for attr.
-
[]
-
Invalid or unsupported value for - contentionscope.
-
-
-
-

-

pthread_attr_affinity_np(3), - pthread_attr_get_np(3), - pthread_create(3)

-
-
-

-

pthread_attr_init(), - pthread_attr_destroy(), - pthread_attr_setstacksize(), - pthread_attr_getstacksize(), - pthread_attr_setstackaddr(), - pthread_attr_getstackaddr(), - pthread_attr_setdetachstate(), and - pthread_attr_getdetachstate() functions conform to - ISO/IEC 9945-1:1996 (“POSIX.1”)

-

The pthread_attr_setinheritsched(), - pthread_attr_getinheritsched(), - pthread_attr_setschedparam(), - pthread_attr_getschedparam(), - pthread_attr_setschedpolicy(), - pthread_attr_getschedpolicy(), - pthread_attr_setscope(), and - pthread_attr_getscope() functions conform to - Version 2 of the Single UNIX Specification - (“SUSv2”)

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_attr_affinity_np.3 3.html b/static/freebsd/man3/pthread_attr_affinity_np.3 3.html deleted file mode 100644 index 78cbbb23..00000000 --- a/static/freebsd/man3/pthread_attr_affinity_np.3 3.html +++ /dev/null @@ -1,140 +0,0 @@ - - - - - - -
PTHREAD_ATTR_AFFINITY_NP(3)Library Functions ManualPTHREAD_ATTR_AFFINITY_NP(3)
-
-
-

-

pthread_attr_getaffinity_np, - pthread_attr_setaffinity_np — - manage CPU affinity in thread attribute objects

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_attr_getaffinity_np(const - pthread_attr_t *pattr, - size_t cpusetsize, - cpuset_t *cpusetp);

-

int -
- pthread_attr_setaffinity_np(pthread_attr_t - *pattr, size_t - cpusetsize, const - cpuset_t *cpusetp);

-
-
-

-

The - () - and pthread_attr_setaffinity_np() functions allow - the manipulation of sets of CPUs available to the specified thread attribute - object.

-

Masks of type - cpuset_t are composed using the - CPU_SET macros. If the user-supplied mask is not - large enough to fit all of the matching CPUs, - () - fails with ERANGE. Calls to - pthread_attr_setaffinity_np() tolerate masks of any - size with no restrictions. - pthread_attr_setaffinity_np() uses the meaningful - part of the mask, where the upper bound is the maximum CPU id present in the - system. If bits for non-existing CPUs are set, calls to - pthread_attr_setaffinity_np() fail with - EINVAL.

-

The supplied mask should have a size of - cpusetsize bytes. This size is usually provided by - calling sizeof(cpuset_t) which is ultimately - determined by the value of CPU_SETSIZE as defined in - <sys/cpuset.h>.

-

() - retrieves the mask from the thread attribute object specified by - pattr, and stores it in the space provided by - cpusetp.

-

() - sets the mask for the thread attribute object specified by - pattr to the value in - cpusetp.

-
-
-

-

If successful, the - pthread_attr_getaffinity_np() and - pthread_attr_setaffinity_np() functions will return - zero. Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_attr_getaffinity_np() - functions will fail if:

-
-
[]
-
The pattr or the attribute specified by it is - NULL.
-
[]
-
The cpusetsize is too small.
-
-

The pthread_attr_setaffinity_np() function - will fail if:

-
-
[]
-
The pattr or the attribute specified by it is - NULL.
-
[]
-
The cpusetp specified a CPU that was outside the set - supported by the kernel.
-
[]
-
Insufficient memory exists to store the cpuset mask.
-
-
-
-

-

cpuset(1), cpuset(2), - cpuset_getid(2), cpuset_setid(2), - pthread_getaffinity_np(3), - pthread_np(3), - pthread_setaffinity_np(3)

-
-
-

-

The pthread_attr_getaffinity_np and - pthread_attr_setaffinity_np functions are - non-standard FreeBSD extensions and may be not - available on other operating systems.

-
-
-

-

The pthread_attr_getaffinity_np and - pthread_attr_setaffinity_np functions first appeared - in FreeBSD 7.2.

-
-
-

-

The pthread_attr_getaffinity_np and - pthread_attr_setaffinity_np functions were written - by David Xu - <davidxu@FreeBSD.org>, - and this manpage was written by Xin LI - <delphij@FreeBSD.org>.

-
-
- - - - - -
January 29, 2023FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_attr_get_np.3 3.html b/static/freebsd/man3/pthread_attr_get_np.3 3.html deleted file mode 100644 index 44e831a4..00000000 --- a/static/freebsd/man3/pthread_attr_get_np.3 3.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - -
PTHREAD_ATTR_GET_NP(3)Library Functions ManualPTHREAD_ATTR_GET_NP(3)
-
-
-

-

pthread_attr_get_np — - get attributes of an existing thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_attr_get_np(pthread_t - pid, pthread_attr_t - *dst);

-
-
-

-

The - () - function is used to retrieve the attributes of the specified thread into an - existing pthread_attr_t structure. The attributes' - values are the current ones for the target thread, except for the stack top - address if not properly aligned for the architecture, since in this case its - value has been adjusted internally before use.

-

Argument dst must - be a pointer to a valid attributes object (it was initialized at some point - by pthread_attr_init(3) and was not destroyed since then). - After a successful call to - (), - the individual attributes' values can be retrieved as usual via the - corresponding accessor functions as documented in - pthread_attr(3). After a failed call to - pthread_attr_get_np(), the object pointed to by - dst is left unmodified, and can continue to be used as - if the failed call never happened.

-
-
-

-

If successful, pthread_attr_get_np() - function returns 0. Otherwise, an error number is returned to indicate the - error.

-
-
-

-

This function retrieves the stack size of the thread specified by - the pid argument:

-
-
size_t
-my_thread_stack_size(pthread_t tid)
-{
-	pthread_attr_t attr;
-	size_t size;
-
-	pthread_attr_init(&attr);
-	pthread_attr_get_np(tid, &attr);
-	pthread_attr_getstacksize(&attr, &size);
-	pthread_attr_destroy(&attr);
-	return (size);
-}
-
-
-
-

-

The pthread_attr_get_np() function will - fail if:

-
-
[]
-
One of the arguments has an invalid value.
-
[]
-
No thread could be found corresponding to that specified by the given - thread ID.
-
[]
-
There was not enough memory to allocate additional storage needed by the - attributes object's implementation.
-
-
-
-

-

pthread_attr(3), - pthread_attr_destroy(3), - pthread_attr_getdetachstate(3), - pthread_attr_getinheritsched(3), - pthread_attr_getschedparam(3), - pthread_attr_getschedpolicy(3), - pthread_attr_getscope(3), - pthread_attr_getstack(3), - pthread_attr_getstackaddr(3), - pthread_attr_getstacksize(3), - pthread_attr_init(3), pthread_np(3)

-
-
-

-

The pthread_attr_get_np() function and - this manual page were written by Alexey Zelkin - <phantom@FreeBSD.org>, - and the latter was revised by -
- Olivier Certner - <olce@FreeBSD.org>.

-
-
- - - - - -
January 5, 2024FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_attr_setcreatesuspend_np.3 3.html b/static/freebsd/man3/pthread_attr_setcreatesuspend_np.3 3.html deleted file mode 100644 index 8a5578aa..00000000 --- a/static/freebsd/man3/pthread_attr_setcreatesuspend_np.3 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
PTHREAD_ATTR_SETCREATESUSPEND_NP(3)Library Functions ManualPTHREAD_ATTR_SETCREATESUSPEND_NP(3)
-
-
-

-

pthread_attr_setcreatesuspend_np — - prepare attribute for creation of suspended - thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_attr_setcreatesuspend_np(pthread_attr_t - *attr);

-
-
-

-

The - () - instructs pthread_create(3) that the thread created with - the attr attribute should be created and left in a - suspended state until explicitly resumed by the call to - () - or - ().

-
-
-

-

The pthread_attr_setcreatesuspend_np() - function returns the value 0 if successful; otherwise the - value -1 is returned and the global variable - errno is set to indicate the error.

-
-
-

-

The pthread_attr_setcreatesuspend_np() - function will fail if:

-
-
[]
-
The value specified by attr is invalid.
-
-
-
-

-

pthread_attr_destroy(3), - pthread_attr_init(3), pthread_create(3), - pthread_np(3), pthread_resume_all_np(3), - pthread_resume_np(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_barrier_destroy.3 3.html b/static/freebsd/man3/pthread_barrier_destroy.3 3.html deleted file mode 100644 index 10145908..00000000 --- a/static/freebsd/man3/pthread_barrier_destroy.3 3.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - -
PTHREAD_BARRIER(3)Library Functions ManualPTHREAD_BARRIER(3)
-
-
-

-

pthread_barrier_destroy, - pthread_barrier_init, - pthread_barrier_wait — - destroy, initialize or wait on a barrier object

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_barrier_destroy(pthread_barrier_t - *barrier);

-

int -
- pthread_barrier_init(pthread_barrier_t - *restrict barrier, const - pthread_barrierattr_t *attr, - unsigned count);

-

int -
- pthread_barrier_wait(pthread_barrier_t - *barrier);

-
-
-

-

The - () - function will initialize barrier with attributes - specified in attr, or if it is - NULL, with default attributes. The number of threads - that must call pthread_barrier_wait() before any of - the waiting threads can be released is specified by - count. The - () - function will destroy barrier and release any - resources that may have been allocated on its behalf.

-

The - () - function will synchronize calling threads at barrier. - The threads will be blocked from making further progress until a sufficient - number of threads calls this function. The number of threads that must call - it before any of them will be released is determined by the - count argument to - pthread_barrier_init(). Once the threads have been - released the barrier will be reset.

-
-
-

-

In 1:1 Threading Library (libthr, -lthr) - the PTHREAD_BARRIER_SERIAL_THREAD return value will - always be returned by the last thread to reach the barrier.

-
-
-

-

If successful, both - pthread_barrier_destroy() and - pthread_barrier_init() will return zero. Otherwise, - an error number will be returned to indicate the error. If the call to - pthread_barrier_wait() is successful, all but one of - the threads will return zero. That one thread will return - PTHREAD_BARRIER_SERIAL_THREAD. Otherwise, an error - number will be returned to indicate the error.

-

None of these functions will return - EINTR.

-
-
-

-

The pthread_barrier_destroy() function - will fail if:

-
-
[]
-
An attempt was made to destroy barrier while it was - in use.
-
-

The pthread_barrier_destroy() and - pthread_barrier_wait() functions may fail if:

-
-
[]
-
The value specified by barrier is invalid.
-
-

The pthread_barrier_init() function will - fail if:

-
-
[]
-
The system lacks resources, other than memory, to initialize - barrier.
-
[]
-
The count argument is less than 1.
-
[]
-
Insufficient memory to initialize barrier.
-
-
-
-

-

pthread_barrierattr(3)

-
-
-

-

The pthread_barrier_destroy(), - pthread_barrier_init() and - pthread_barrier_wait() functions first appeared in - N:M Threading Library (libkse, -lkse) in - FreeBSD 5.2, and in 1:1 Threading - Library (libthr, -lthr) in FreeBSD 5.3.

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_barrierattr.3 3.html b/static/freebsd/man3/pthread_barrierattr.3 3.html deleted file mode 100644 index 9c433bc6..00000000 --- a/static/freebsd/man3/pthread_barrierattr.3 3.html +++ /dev/null @@ -1,126 +0,0 @@ - - - - - - -
PTHREAD_BARRIERATTR(3)Library Functions ManualPTHREAD_BARRIERATTR(3)
-
-
-

-

pthread_barrierattr_destroy, - pthread_barrierattr_getpshared, - pthread_barrierattr_init, - pthread_barrierattr_setpshared — - manipulate a barrier attribute object

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_barrierattr_destroy(pthread_barrierattr_t - *attr);

-

int -
- pthread_barrierattr_getpshared(const - pthread_barrierattr_t *restrict attr, int *restrict - pshared);

-

int -
- pthread_barrierattr_init(pthread_barrierattr_t - *attr);

-

int -
- pthread_barrierattr_setpshared(pthread_barrierattr_t - *attr, int pshared);

-
-
-

-

The - () - function will initialize attr with default attributes. - The - () - function will destroy attr and release any resources - that may have been allocated on its behalf.

-

The - () - function will put the value of the process-shared attribute from - attr into the memory area pointed to by - pshared. The - () - function will set the process-shared attribute of attr - to the value specified in pshared. The argument - pshared may have one of the following values:

-
-
-
The barrier object it is attached to may only be accessed by threads in - the same process as the one that created the object.
-
-
The barrier object it is attached to may be accessed by threads in - processes other than the one that created the object.
-
-
-
-

-

If successful, all these functions will return zero. Otherwise, an - error number will be returned to indicate the error.

-

None of these functions will return - EINTR.

-
-
-

-

The pthread_barrierattr_destroy(), - pthread_barrierattr_getpshared() and - pthread_barrierattr_setpshared() functions may fail - if:

-
-
[]
-
The value specified by attr is invalid.
-
-

The pthread_barrierattr_init() function - will fail if:

-
-
[]
-
Insufficient memory to initialize the barrier attribute object - attr.
-
-

The pthread_barrierattr_setpshared() - function will fail if:

-
-
[]
-
The value specified in pshared is not one of the - allowed values.
-
-
-
-

-

pthread_barrier_destroy(3), - pthread_barrier_init(3), - pthread_barrier_wait(3)

-
-
-

-

The pthread_barrierattr_*() functions - first appeared in N:M Threading Library (libkse, - -lkse) in FreeBSD 5.2, and in - 1:1 Threading Library (libthr, -lthr) in - FreeBSD 5.3. Support for process-shared barriers - appeared in FreeBSD 11.0.

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cancel.3 3.html b/static/freebsd/man3/pthread_cancel.3 3.html deleted file mode 100644 index e350d4eb..00000000 --- a/static/freebsd/man3/pthread_cancel.3 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
PTHREAD_CANCEL(3)Library Functions ManualPTHREAD_CANCEL(3)
-
-
-

-

pthread_cancel — - cancel execution of a thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cancel(pthread_t - thread);

-
-
-

-

The - () - function requests that thread be canceled. The target - thread's cancelability state and type determines when the cancellation takes - effect. When the cancellation is acted on, the cancellation cleanup handlers - for thread are called. When the last cancellation - cleanup handler returns, the thread-specific data destructor functions will - be called for thread. When the last destructor - function returns, thread will be terminated.

-

The cancellation processing in the target - thread runs asynchronously with respect to the calling thread returning from - ().

-

A status of PTHREAD_CANCELED is made - available to any threads joining with the target. The symbolic constant - PTHREAD_CANCELED expands to a constant expression of - type (void *), whose value matches no pointer to an - object in memory nor the value NULL.

-
-
-

-

If successful, the pthread_cancel() - functions will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_cancel() function will fail - if:

-
-
[]
-
No thread could be found corresponding to that specified by the given - thread ID.
-
-
-
-

-

pthread_cleanup_pop(3), - pthread_cleanup_push(3), - pthread_exit(3), pthread_join(3), - pthread_setcancelstate(3), - pthread_setcanceltype(3), - pthread_testcancel(3)

-
-
-

-

The pthread_cancel() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
-

-

This manual page was written by David - Leonard - <d@openbsd.org> for the - OpenBSD implementation of - pthread_cancel().

-
-
- - - - - -
January 17, 1999FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cleanup_pop.3 4.html b/static/freebsd/man3/pthread_cleanup_pop.3 4.html deleted file mode 100644 index aac50d1c..00000000 --- a/static/freebsd/man3/pthread_cleanup_pop.3 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
PTHREAD_CLEANUP_POP(3)Library Functions ManualPTHREAD_CLEANUP_POP(3)
-
-
-

-

pthread_cleanup_pop — - call the first cleanup routine

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

void -
- pthread_cleanup_pop(int - execute);

-
-
-

-

The - () - function pops the top cleanup routine off of the current threads cleanup - routine stack, and, if execute is non-zero, it will - execute the function. If there is no cleanup routine then - pthread_cleanup_pop() does nothing.

-

The - () - function is implemented as a macro that closes a block. Invocations of this - function must appear as standalone statements that are paired with an - earlier call of pthread_cleanup_push(3) in the same - lexical scope.

-
-
-

-

The pthread_cleanup_pop() function does - not return any value.

-
-
-

-

None

-
-
-

-

pthread_cleanup_push(3), - pthread_exit(3)

-
-
-

-

The pthread_cleanup_pop() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
October 25, 2014FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cleanup_push.3 4.html b/static/freebsd/man3/pthread_cleanup_push.3 4.html deleted file mode 100644 index 534d43c4..00000000 --- a/static/freebsd/man3/pthread_cleanup_push.3 4.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
PTHREAD_CLEANUP_PUSH(3)Library Functions ManualPTHREAD_CLEANUP_PUSH(3)
-
-
-

-

pthread_cleanup_push — - add a cleanup function for thread exit

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

void -
- pthread_cleanup_push(void - (*cleanup_routine)(void *), - void *arg);

-
-
-

-

The - () - function adds cleanup_routine to the top of the stack - of cleanup handlers that get called when the current thread exits.

-

When cleanup_routine is called, it is passed - arg as its only argument.

-

The - () - function is implemented as a macro that opens a new block. Invocations of - this function must appear as standalone statements that are paired with a - later call of pthread_cleanup_pop(3) in the same lexical - scope.

-
-
-

-

The pthread_cleanup_push() function does - not return any value.

-
-
-

-

None

-
-
-

-

pthread_cleanup_pop(3), - pthread_exit(3)

-
-
-

-

The pthread_cleanup_push() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
October 25, 2014FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cond_broadcast.3 4.html b/static/freebsd/man3/pthread_cond_broadcast.3 4.html deleted file mode 100644 index 47e7dad1..00000000 --- a/static/freebsd/man3/pthread_cond_broadcast.3 4.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
PTHREAD_COND_BROADCAST(3)Library Functions ManualPTHREAD_COND_BROADCAST(3)
-
-
-

-

pthread_cond_broadcast — - unblock all threads waiting for a condition - variable

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cond_broadcast(pthread_cond_t - *cond);

-
-
-

-

The - () - function unblocks all threads waiting for the condition variable - cond.

-
-
-

-

If successful, the - pthread_cond_broadcast() function will return zero, - otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_cond_broadcast() function will - fail if:

-
-
[]
-
The value specified by cond is invalid.
-
-
-
-

-

pthread_cond_destroy(3), - pthread_cond_init(3), - pthread_cond_signal(3), - pthread_cond_timedwait(3), - pthread_cond_wait(3)

-
-
-

-

The pthread_cond_broadcast() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
July 28, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cond_destroy.3 4.html b/static/freebsd/man3/pthread_cond_destroy.3 4.html deleted file mode 100644 index 7c5d18cc..00000000 --- a/static/freebsd/man3/pthread_cond_destroy.3 4.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
PTHREAD_COND_DESTROY(3)Library Functions ManualPTHREAD_COND_DESTROY(3)
-
-
-

-

pthread_cond_destroy — - destroy a condition variable

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cond_destroy(pthread_cond_t - *cond);

-
-
-

-

The - () - function frees the resources allocated by the condition variable - cond.

-
-
-

-

A condition variable can be destroyed immediately after all the - threads that are blocked on it are awakened.

-
-
-

-

If successful, the pthread_cond_destroy() - function will return zero, otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_cond_destroy() function will - fail if:

-
-
[]
-
The value specified by cond is invalid.
-
[]
-
The variable cond is locked by another thread.
-
-
-
-

-

pthread_cond_broadcast(3), - pthread_cond_init(3), - pthread_cond_signal(3), - pthread_cond_timedwait(3), - pthread_cond_wait(3)

-
-
-

-

The pthread_cond_destroy() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
July 28, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cond_init.3 3.html b/static/freebsd/man3/pthread_cond_init.3 3.html deleted file mode 100644 index a750e401..00000000 --- a/static/freebsd/man3/pthread_cond_init.3 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
PTHREAD_COND_INIT(3)Library Functions ManualPTHREAD_COND_INIT(3)
-
-
-

-

pthread_cond_init — - create a condition variable

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cond_init(pthread_cond_t - *restrict cond, const - pthread_condattr_t *restrict attr);

-
-
-

-

The - () - function creates a new condition variable, with attributes specified with - attr. If attr is NULL the - default attributes are used.

-
-
-

-

If successful, the pthread_cond_init() - function will return zero and put the new condition variable id into - cond, otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_cond_init() function will fail - if:

-
-
[]
-
The value specified by attr is invalid.
-
[]
-
The process cannot allocate enough memory to create another condition - variable.
-
[]
-
The system temporarily lacks the resources to create another condition - variable.
-
-
-
-

-

pthread_cond_broadcast(3), - pthread_cond_destroy(3), - pthread_cond_signal(3), - pthread_cond_timedwait(3), - pthread_cond_wait(3), - pthread_condattr(3)

-
-
-

-

The pthread_cond_init() function conforms - to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cond_signal.3 4.html b/static/freebsd/man3/pthread_cond_signal.3 4.html deleted file mode 100644 index 76db2855..00000000 --- a/static/freebsd/man3/pthread_cond_signal.3 4.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
PTHREAD_COND_SIGNAL(3)Library Functions ManualPTHREAD_COND_SIGNAL(3)
-
-
-

-

pthread_cond_signal — - unblock a thread waiting for a condition - variable

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cond_signal(pthread_cond_t - *cond);

-
-
-

-

The - () - function unblocks one thread waiting for the condition variable - cond.

-
-
-

-

If successful, the pthread_cond_signal() - function will return zero, otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_cond_signal() function will - fail if:

-
-
[]
-
The value specified by cond is invalid.
-
-
-
-

-

pthread_cond_broadcast(3), - pthread_cond_destroy(3), - pthread_cond_init(3), - pthread_cond_timedwait(3), - pthread_cond_wait(3)

-
-
-

-

The pthread_cond_signal() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
July 28, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cond_timedwait.3 3.html b/static/freebsd/man3/pthread_cond_timedwait.3 3.html deleted file mode 100644 index bb53b789..00000000 --- a/static/freebsd/man3/pthread_cond_timedwait.3 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
PTHREAD_COND_TIMEDWAIT(3)Library Functions ManualPTHREAD_COND_TIMEDWAIT(3)
-
-
-

-

pthread_cond_timedwait — - wait on a condition variable for a specific amount of - time

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cond_timedwait(pthread_cond_t - *cond, pthread_mutex_t - *mutex, const struct - timespec *abstime);

-
-
-

-

The - () - function atomically blocks the current thread waiting on the condition - variable specified by cond, and releases the mutex - specified by mutex. The waiting thread unblocks only - after another thread calls pthread_cond_signal(3), or - pthread_cond_broadcast(3) with the same condition - variable, or if the system time reaches the time specified in - abstime, and the current thread reacquires the lock on - mutex.

-

The clock used to measure abstime can be - specified during creation of the condition variable using - pthread_condattr_setclock(3).

-
-
-

-

If successful, the - pthread_cond_timedwait() function will return zero. - Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_cond_timedwait() function will - fail if:

-
-
[]
-
The value specified by cond, - mutex or abstime is - invalid.
-
[]
-
The system time has reached or exceeded the time specified in - abstime.
-
[]
-
The specified mutex was not locked by the calling - thread.
-
-
-
-

-

pthread_cond_broadcast(3), - pthread_cond_destroy(3), - pthread_cond_init(3), - pthread_cond_signal(3), - pthread_cond_wait(3), - pthread_condattr_setclock(3)

-
-
-

-

The pthread_cond_timedwait() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
May 9, 2010FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_cond_wait.3 3.html b/static/freebsd/man3/pthread_cond_wait.3 3.html deleted file mode 100644 index 693abbab..00000000 --- a/static/freebsd/man3/pthread_cond_wait.3 3.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
PTHREAD_COND_WAIT(3)Library Functions ManualPTHREAD_COND_WAIT(3)
-
-
-

-

pthread_cond_wait — - wait on a condition variable

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_cond_wait(pthread_cond_t - *restrict cond, - pthread_mutex_t *restrict - mutex);

-
-
-

-

The - () - function atomically blocks the current thread waiting on the condition - variable specified by cond, and releases the mutex - specified by mutex. The waiting thread unblocks only - after another thread calls pthread_cond_signal(3), or - pthread_cond_broadcast(3) with the same condition - variable, and the current thread reacquires the lock on - mutex.

-
-
-

-

If successful, the pthread_cond_wait() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_cond_wait() function will fail - if:

-
-
[]
-
The value specified by cond or the value specified - by mutex is invalid.
-
[]
-
The specified mutex was not locked by the calling - thread.
-
[]
-
The argument mutex points to a robust mutex and the - process containing the previous owning thread terminated while holding the - mutex lock. The lock was granted to the caller and it is up to the new - owner to make the state consistent.
-
[]
-
The state protected by the mutex is not - recoverable.
-
-
-
-

-

pthread_cond_broadcast(3), - pthread_cond_destroy(3), - pthread_cond_init(3), - pthread_cond_signal(3), - pthread_cond_timedwait(3), - pthread_mutex_consistent(3)

-
-
-

-

The pthread_cond_wait() function conforms - to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
August 7, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_condattr.3 3.html b/static/freebsd/man3/pthread_condattr.3 3.html deleted file mode 100644 index 2cbb12b1..00000000 --- a/static/freebsd/man3/pthread_condattr.3 3.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - -
PTHREAD_CONDATTR(3)Library Functions ManualPTHREAD_CONDATTR(3)
-
-
-

-

pthread_condattr_init, - pthread_condattr_destroy, - pthread_condattr_getclock, - pthread_condattr_setclock, - pthread_condattr_getpshared, - pthread_condattr_setpshared — - condition attribute operations

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_condattr_init(pthread_condattr_t - *attr);

-

int -
- pthread_condattr_destroy(pthread_condattr_t - *attr);

-

int -
- pthread_condattr_getclock(pthread_condattr_t - * restrict attr, clockid_t * restrict - clock_id);

-

int -
- pthread_condattr_setclock(pthread_condattr_t - *attr, clockid_t - clock_id);

-

int -
- pthread_condattr_getpshared(pthread_condattr_t - * restrict attr, int * restrict pshared);

-

int -
- pthread_condattr_setpshared(pthread_condattr_t - *attr, int - pshared);

-
-
-

-

Condition attribute objects are used to specify parameters to - ().

-

The - () - function initializes a condition attribute object with the default - attributes.

-

The - () - function destroys a condition attribute object.

-

The - () - function will put the value of the clock attribute from - attr into the memory area pointed to by - clock_id. The - () - function will set the clock attribute of attr to the - value specified in clock_id. The clock attribute - affects the interpretation of abstime in - pthread_cond_timedwait(3) and may be set to - CLOCK_REALTIME (default), - CLOCK_TAI, or - CLOCK_MONOTONIC.

-

The - () - function will put the value of the process-shared attribute from - attr into the memory area pointed to by - pshared. The - () - function will set the process-shared attribute of attr - to the value specified in pshared. The argument - pshared may have one of the following values:

-
-
-
The condition variable it is attached to may only be accessed by threads - in the same process as the one that created the object.
-
-
The condition variable it is attached to may be accessed by threads in - processes other than the one that created the object.
-
-See libthr(3) for details of the implementation of shared - condition variables, and their limitations. -
-
-

-

If successful, these functions return 0. Otherwise, an error - number is returned to indicate the error.

-
-
-

-

The pthread_condattr_init() function will - fail if:

-
-
[]
-
Out of memory.
-
-

The pthread_condattr_destroy() function - will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_condattr_setclock() function - will fail if:

-
-
[]
-
The value specified in clock_id is not one of the - allowed values.
-
-

The pthread_condattr_setpshared() function - will fail if:

-
-
[]
-
The value specified in pshared is not one of the - allowed values.
-
-
-
-

-

libthr(3), - pthread_cond_init(3), - pthread_cond_timedwait(3)

-
-
-

-

The pthread_condattr_init() and - pthread_condattr_destroy() functions conform to - ISO/IEC 9945-1:1996 (“POSIX.1”)

-
-
- - - - - -
October 27, 2023FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_create.3 3.html b/static/freebsd/man3/pthread_create.3 3.html deleted file mode 100644 index afac00f8..00000000 --- a/static/freebsd/man3/pthread_create.3 3.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - -
PTHREAD_CREATE(3)Library Functions ManualPTHREAD_CREATE(3)
-
-
-

-

pthread_create — - create a new thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_create(pthread_t - *restrict thread, const - pthread_attr_t *restrict attr, - void *(*start_routine)(void - *), void *restrict - arg);

-
-
-

-

The - () - function is used to create a new thread, with attributes specified by - attr, within a process. If attr - is NULL, the default attributes are used. If the - attributes specified by attr are modified later, the - thread's attributes are not affected. Upon successful completion - pthread_create() will store the ID of the created - thread in the location specified by thread.

-

The thread is created executing - start_routine with arg as its - sole argument. If the start_routine returns, the - effect is as if there was an implicit call to - () - using the return value of start_routine as the exit - status. Note that the thread in which - () - was originally invoked differs from this. When it returns from - main(), the effect is as if there was an implicit - call to - () - using the return value of main() as the exit - status.

-

The signal state of the new thread is initialized as:

-
    -
  • The signal mask is inherited from the creating thread.
    • -
  • The set of signals pending for the new thread is empty.
    • -
-
-
-

-

If successful, the pthread_create() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_create() function can return - any of the following errors:

-
-
[]
-
The system lacked the necessary resources to create another thread.
-
[]
-
The system-imposed limit on the total number of threads in a process - [PTHREAD_THREADS_MAX] would be exceeded.
-
[]
-
The RACCT_NTHR limit would be exceeded; see - racct(2).
-
[]
-
The caller does not have permission to set the scheduling parameters or - scheduling policy.
-
[]
-
A value specified by attr is invalid.
-
[]
-
The CPU set specified by attr would prevent the - thread from running on any CPU.
-
[]
-
The stack base specified by attr is invalid, or the - kernel was unable to put required initial data on the stack.
-
-
-
-

-

cpuset_setaffinity(2), - fork(2), racct(2), - thr_new(2), pthread_attr(3), - pthread_cancel(3), - pthread_cleanup_pop(3), - pthread_cleanup_push(3), - pthread_exit(3), pthread_join(3)

-
-
-

-

The pthread_create() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_detach.3 3.html b/static/freebsd/man3/pthread_detach.3 3.html deleted file mode 100644 index b411f981..00000000 --- a/static/freebsd/man3/pthread_detach.3 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
PTHREAD_DETACH(3)Library Functions ManualPTHREAD_DETACH(3)
-
-
-

-

pthread_detach — - detach a thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_detach(pthread_t - thread);

-
-
-

-

The - () - function is used to indicate to the implementation that storage for the - thread thread can be reclaimed when the thread - terminates. If thread has not terminated, - pthread_detach() will not cause it to terminate. The - effect of multiple pthread_detach() calls on the - same target thread is unspecified.

-
-
-

-

If successful, the pthread_detach() - function will return zero. Otherwise an error number will be returned to - indicate the error. Note that the function does not change the value of - errno as it did for some drafts of the standard. These early drafts also - passed a pointer to pthread_t as the argument. Beware!

-
-
-

-

The pthread_detach() function will fail - if:

-
-
[]
-
The implementation has detected that the value specified by - thread does not refer to a joinable thread.
-
[]
-
No thread could be found corresponding to that specified by the given - thread ID, thread.
-
-
-
-

-

pthread_join(3)

-
-
-

-

The pthread_detach() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_equal.3 4.html b/static/freebsd/man3/pthread_equal.3 4.html deleted file mode 100644 index 256279b4..00000000 --- a/static/freebsd/man3/pthread_equal.3 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
PTHREAD_EQUAL(3)Library Functions ManualPTHREAD_EQUAL(3)
-
-
-

-

pthread_equal — - compare thread IDs

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_equal(pthread_t - t1, pthread_t - t2);

-
-
-

-

The - () - function compares the thread IDs t1 and - t2.

-
-
-

-

The pthread_equal() function will return - non-zero if the thread IDs t1 and - t2 correspond to the same thread, otherwise it will - return zero.

-
-
-

-

None.

-
-
-

-

pthread_create(3), - pthread_exit(3)

-
-
-

-

The pthread_equal() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_exit.3 3.html b/static/freebsd/man3/pthread_exit.3 3.html deleted file mode 100644 index 91e7e2ce..00000000 --- a/static/freebsd/man3/pthread_exit.3 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
PTHREAD_EXIT(3)Library Functions ManualPTHREAD_EXIT(3)
-
-
-

-

pthread_exit — - terminate the calling thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

void -
- pthread_exit(void - *value_ptr);

-
-
-

-

The - () - function terminates the calling thread and makes the value - value_ptr available to any successful join with the - terminating thread. Any cancellation cleanup handlers that have been pushed - and are not yet popped are popped in the reverse order that they were pushed - and then executed. After all cancellation handlers have been executed, if - the thread has any thread-specific data, appropriate destructor functions - are called in an unspecified order. Thread termination does not release any - application visible process resources, including, but not limited to, - mutexes and file descriptors, nor does it perform any process level cleanup - actions, including, but not limited to, calling - () - routines that may exist.

-

An implicit call to - () - is made when a thread other than the thread in which - () - was first invoked returns from the start routine that was used to create it. - The function's return value serves as the thread's exit status.

-

The behavior of - () - is undefined if called from a cancellation handler or destructor function - that was invoked as the result of an implicit or explicit call to - pthread_exit().

-

After a thread has terminated, the result of - access to local (auto) variables of the thread is undefined. Thus, - references to local variables of the exiting thread should not be used for - the - () - value_ptr parameter value.

-

The process will exit with an exit status of 0 after the - last thread has been terminated. The behavior is as if the implementation - called () - with a zero argument at thread termination time.

-
-
-

-

The pthread_exit() function cannot return - to its caller.

-
-
-

-

None.

-
-
-

-

_exit(2), exit(3), - pthread_cancel(3), pthread_create(3), - pthread_join(3)

-
-
-

-

The pthread_exit() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
- - - - - -
March 15, 2014FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_getconcurrency.3 3.html b/static/freebsd/man3/pthread_getconcurrency.3 3.html deleted file mode 100644 index c9bbee7f..00000000 --- a/static/freebsd/man3/pthread_getconcurrency.3 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
PTHREAD_GETCONCURRENCY(3)Library Functions ManualPTHREAD_GETCONCURRENCY(3)
-
-
-

-

pthread_getconcurrency, - pthread_setconcurrency — get - or set level of concurrency

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_getconcurrency(void);

-

int -
- pthread_setconcurrency(int - new_level);

-
-
-

-

The - () - function allows an application to inform the threads implementation of its - desired concurrency level, new_level. The actual level - of concurrency provided by the implementation as a result of this function - call is unspecified. If new_level is zero, it causes - the implementation to maintain the concurrency level at its discretion as if - pthread_setconcurrency() was never called. The - () - function returns the value set by a previous call to the - pthread_setconcurrency() function. If the - pthread_setconcurrency() function was not previously - called, this function returns zero to indicate that the implementation is - maintaining the concurrency level. When an application calls - pthread_setconcurrency(), it is informing the - implementation of its desired concurrency level. The implementation uses - this as a hint, not a requirement.

-
-
-

-

If successful, the - pthread_setconcurrency() function returns zero. - Otherwise, an error number is returned to indicate the error. The - pthread_getconcurrency() function always returns the - concurrency level set by a previous call to - pthread_setconcurrency(). If the - pthread_setconcurrency() function has never been - called, pthread_getconcurrency() returns zero.

-
-
-

-

The pthread_setconcurrency() function will - fail if:

-
-
[]
-
The value specified by new_level is negative.
-
[]
-
The value specified by new_level would cause a - system resource to be exceeded.
-
-
-
-

-

Use of these functions changes the state of the underlying - concurrency upon which the application depends. Library developers are - advised to not use the pthread_getconcurrency() and - pthread_setconcurrency() functions since their use - may conflict with an application's use of these functions.

-
-
-

-

The pthread_getconcurrency() and - pthread_setconcurrency() functions conform to - Version 2 of the Single UNIX Specification - (“SUSv2”).

-
-
- - - - - -
April 11, 2003FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_getcpuclockid.3 4.html b/static/freebsd/man3/pthread_getcpuclockid.3 4.html deleted file mode 100644 index 420a357d..00000000 --- a/static/freebsd/man3/pthread_getcpuclockid.3 4.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
PTHREAD_GETCPUCLOCKID(3)Library Functions ManualPTHREAD_GETCPUCLOCKID(3)
-
-
-

-

pthread_getcpuclockid — - access a thread CPU-time clock

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h> -
- #include <time.h>

-

int -
- pthread_getcpuclockid(pthread_t - thread_id, clockid_t - *clock_id);

-
-
-

-

The - () - returns the clock ID of the CPU-time clock of the thread specified by - thread_id, if the thread described by - thread_id exists.

-
-
-

-

Upon successful completion, - pthread_getcpuclockid() returns zero; otherwise, an - error number is returned to indicate the error.

-
-
-

-

The pthread_getcpuclockid() function will - fail if:

-
-
[]
-
The value specified by thread_id does not refer to - an existing thread.
-
-
-
-

-

clock_gettime(2)

-
-
-

-

The pthread_getcpuclockid() function - conforms to IEEE Std 1003.1-2004 - (“POSIX.1”).

-
-
-

-

The pthread_getcpuclockid() function first - appeared in FreeBSD 10.0.

-
-
-

-

David Xu - <davidxu@FreeBSD.org>

-
-
- - - - - -
August 21, 2012FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_getspecific.3 3.html b/static/freebsd/man3/pthread_getspecific.3 3.html deleted file mode 100644 index 563118b9..00000000 --- a/static/freebsd/man3/pthread_getspecific.3 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
PTHREAD_GETSPECIFIC(3)Library Functions ManualPTHREAD_GETSPECIFIC(3)
-
-
-

-

pthread_getspecific — - get a thread-specific data value

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

void * -
- pthread_getspecific(pthread_key_t - key);

-
-
-

-

The - () - function returns the value currently bound to the specified - key on behalf of the calling thread.

-

The effect of calling - () - with a key value not obtained from - () - or after key has been deleted with - () - is undefined.

-

The - () - function may be called from a thread-specific data destructor function. A - call to pthread_getspecific() for the - thread-specific data key being destroyed returns the value NULL, unless the - value is changed (after the destructor starts) by a call to - ().

-
-
-

-

The pthread_getspecific() function will - return the thread-specific data value associated with the given - key. If no thread-specific data value is associated - with key, then the value NULL is returned.

-
-
-

-

None.

-
-
-

-

pthread_key_create(3), - pthread_key_delete(3), - pthread_setspecific(3)

-
-
-

-

The pthread_getspecific() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_getthreadid_np.3 4.html b/static/freebsd/man3/pthread_getthreadid_np.3 4.html deleted file mode 100644 index 808d8c28..00000000 --- a/static/freebsd/man3/pthread_getthreadid_np.3 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
PTHREAD_GETTHREADID_NP(3)Library Functions ManualPTHREAD_GETTHREADID_NP(3)
-
-
-

-

pthread_getthreadid_np — - get the calling thread's integral ID

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_getthreadid_np(void);

-
-
-

-

The - () - function returns the unique integral ID of the calling thread. Its semantics - is similar to the AIX's pthread_getthreadid_np() - function.

-
-
-

-

The pthread_getthreadid_np() function - returns the thread integral ID of the calling thread.

-
-
-

-

None.

-
-
-

-

pthread_np(3), - pthread_self(3)

-
-
-

-

This manual page was written by Jung-uk - Kim - <jkim@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_join.3 3.html b/static/freebsd/man3/pthread_join.3 3.html deleted file mode 100644 index 44f7fc06..00000000 --- a/static/freebsd/man3/pthread_join.3 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
PTHREAD_JOIN(3)Library Functions ManualPTHREAD_JOIN(3)
-
-
-

-

pthread_join, - pthread_peekjoin_np, - pthread_timedjoin_np - pthread_tryjoin_np — inspect - thread termination state

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_join(pthread_t - thread, void - **value_ptr);

-

#include - <pthread_np.h>

-

int -
- pthread_peekjoin_np(pthread_t - thread, void **value_ptr);

-

int -
- pthread_timedjoin_np(pthread_t - thread, void **value_ptr, const - struct timespec *abstime);

-

int -
- pthread_tryjoin_np(pthread_t - thread, void - **value_ptr);

-
-
-

-

The - () - function suspends execution of the calling thread until the target - thread terminates unless the target - thread has already terminated.

-

On return from a successful - () - call with a non-NULL value_ptr argument, the value - passed to - () - by the terminating thread is stored in the location referenced by - value_ptr. When a - pthread_join() returns successfully, the target - thread has been terminated. The results of multiple simultaneous calls to - pthread_join() specifying the same target thread are - undefined. If the thread calling pthread_join() is - cancelled, then the target thread is not detached.

-

The - () - function is equivalent to the pthread_join() - function except it will return ETIMEDOUT if target - thread does not exit before specified absolute time passes.

-

The - () - only peeks into the exit status of the specified thread. If the thread has - not exited, the EBUSY error is returned. Otherwise, - zero is returned and the thread exit value is optionally stored into the - location of *value_ptr. The target thread is left - unjoined and can be used as an argument for the - pthread_join() family of functions again.

-

The - () - function joins the thread if it is already terminated, same as - pthread_join(). If the thread has not yet - terminated, the function returns EBUSY.

-

A thread that has exited but remains unjoined counts against - [_POSIX_THREAD_THREADS_MAX].

-
-
-

-

If successful, the described functions return zero. Otherwise an - error number is returned to indicate the error or special condition.

-
-
-

-

The pthread_join(), - pthread_peekjoin_np(), and - pthread_timedjoin_np() functions will fail if:

-
-
[]
-
The implementation has detected that the value specified by - thread does not refer to a joinable thread.
-
[]
-
No thread could be found corresponding to that specified by the given - thread ID, thread.
-
[]
-
A deadlock was detected or the value of thread - specifies the calling thread.
-
[]
-
The implementation detected that another caller is already waiting on - thread.
-
-

Additionally, the pthread_timedjoin_np() - function will fail if:

-
-
[]
-
The specified absolute time passed while - pthread_timedjoin_np() waited for thread - exit.
-
-

The pthread_peekjoin_np() and - pthread_tryjoin_np() functions will also fail - if:

-
-
[]
-
The specified thread has not yet exited.
-
-
-
-

-

wait(2), pthread(3), - pthread_create(3), pthread_np(3)

-
-
-

-

The pthread_join() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”). The - pthread_timedjoin_np() function is a - FreeBSD extension which first appeared in - FreeBSD 6.1. The - pthread_peekjoin_np() function is a - FreeBSD extension which first appearead in - FreeBSD 13.0. The - pthread_tryjoin_np() function is a - FreeBSD extension which first appearead in - FreeBSD 16.0.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_key_create.3 3.html b/static/freebsd/man3/pthread_key_create.3 3.html deleted file mode 100644 index 58110c8d..00000000 --- a/static/freebsd/man3/pthread_key_create.3 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
PTHREAD_KEY_CREATE(3)Library Functions ManualPTHREAD_KEY_CREATE(3)
-
-
-

-

pthread_key_create — - thread-specific data key creation

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_key_create(pthread_key_t - *key, void - (*destructor)(void *));

-
-
-

-

The - () - function creates a thread-specific data key visible to all threads in the - process. Key values provided by pthread_key_create() - are opaque objects used to locate thread-specific data. Although the same - key value may be used by different threads, the values bound to the key by - () - are maintained on a per-thread basis and persist for the life of the calling - thread.

-

Upon key creation, the value NULL is associated with the new key - in all active threads. Upon thread creation, the value NULL is associated - with all defined keys in the new thread.

-

An optional destructor function may be associated with each key - value. At thread exit, if a key value has a non-NULL destructor pointer, and - the thread has a non-NULL value associated with the key, the function - pointed to is called with the current associated value as its sole argument. - The order of destructor calls is unspecified if more than one destructor - exists for a thread when it exits.

-

If, after all the destructors have been called for all non-NULL - values with associated destructors, there are still some non-NULL values - with associated destructors, then the process is repeated. If, after at - least [PTHREAD_DESTRUCTOR_ITERATIONS] iterations of destructor calls for - outstanding non-NULL values, there are still some non-NULL values with - associated destructors, the implementation stops calling destructors.

-
-
-

-

If successful, the pthread_key_create() - function will store the newly created key value at the location specified by - key and returns zero. Otherwise an error number will - be returned to indicate the error.

-
-
-

-

The pthread_key_create() function will - fail if:

-
-
[]
-
The system lacked the necessary resources to create another - thread-specific data key, or the system-imposed limit on the total number - of keys per process [PTHREAD_KEYS_MAX] would be exceeded.
-
[]
-
Insufficient memory exists to create the key.
-
-
-
-

-

pthread_getspecific(3), - pthread_key_delete(3), - pthread_setspecific(3)

-
-
-

-

The pthread_key_create() function conforms - to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_key_delete.3 3.html b/static/freebsd/man3/pthread_key_delete.3 3.html deleted file mode 100644 index 723aa503..00000000 --- a/static/freebsd/man3/pthread_key_delete.3 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
PTHREAD_KEY_DELETE(3)Library Functions ManualPTHREAD_KEY_DELETE(3)
-
-
-

-

pthread_key_delete — - delete a thread-specific data key

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_key_delete(pthread_key_t - key);

-
-
-

-

The - () - function deletes a thread-specific data key previously returned by - (). - The thread-specific data values associated with key - need not be NULL at the time that - pthread_key_delete() is called. It is the - responsibility of the application to free any application storage or perform - any cleanup actions for data structures related to the deleted key or - associated thread-specific data in any threads; this cleanup can be done - either before or after pthread_key_delete() is - called. Any attempt to use key following the call to - pthread_key_delete() results in undefined - behavior.

-

The - () - function is callable from within destructor functions. Destructor functions - are not invoked by pthread_key_delete(). Any - destructor function that may have been associated with - key will no longer be called upon thread exit.

-
-
-

-

If successful, the pthread_key_delete() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_key_delete() function will - fail if:

-
-
[]
-
The key value is invalid.
-
-
-
-

-

pthread_getspecific(3), - pthread_key_create(3), - pthread_setspecific(3)

-
-
-

-

The pthread_key_delete() function conforms - to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_kill.3 4.html b/static/freebsd/man3/pthread_kill.3 4.html deleted file mode 100644 index d3ae0617..00000000 --- a/static/freebsd/man3/pthread_kill.3 4.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
PTHREAD_KILL(3)Library Functions ManualPTHREAD_KILL(3)
-
-
-

-

pthread_kill — - send a signal to a specified thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h> -
- #include <signal.h>

-

int -
- pthread_kill(pthread_t - thread, int - sig);

-
-
-

-

The - () - function sends a signal, specified by sig, to a - thread, specified by thread. If - sig is 0, error checking is performed, but no signal - is actually sent.

-
-
-

-

If successful, pthread_kill() returns 0. - Otherwise, an error number is returned.

-
-
-

-

The pthread_kill() function will fail - if:

-
-
[]
-
thread is an invalid thread ID.
-
[]
-
sig is an invalid or unsupported signal number.
-
-
-
-

-

kill(2), pthread_self(3), - raise(3)

-
-
-

-

The pthread_kill() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”)

-
-
- - - - - -
April 27, 2000FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_main_np.3 4.html b/static/freebsd/man3/pthread_main_np.3 4.html deleted file mode 100644 index 4f3e6d1b..00000000 --- a/static/freebsd/man3/pthread_main_np.3 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
PTHREAD_MAIN_NP(3)Library Functions ManualPTHREAD_MAIN_NP(3)
-
-
-

-

pthread_main_np — - identify the initial thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_main_np(void);

-
-
-

-

The - () - function is used in userland threads environment to identify the initial - thread. Its semantics is similar to the Solaris's - () - function.

-
-
-

-

The pthread_main_np() function returns 1 - if the calling thread is the initial thread, 0 if the calling thread is not - the initial thread, and -1 if the thread's initialization has not yet - completed.

-
-
-

-

pthread_create(3), - pthread_equal(3), pthread_np(3), - pthread_self(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_multi_np.3 4.html b/static/freebsd/man3/pthread_multi_np.3 4.html deleted file mode 100644 index 3fd0901d..00000000 --- a/static/freebsd/man3/pthread_multi_np.3 4.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
PTHREAD_MULTI_NP(3)Library Functions ManualPTHREAD_MULTI_NP(3)
-
-
-

-

pthread_multi_np, - pthread_single_np — switch - between multi- and single-threaded scheduling modes

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_multi_np(void);

-

int -
- pthread_single_np(void);

-
-
-

-

The - () - function switches the process to a single-threaded mode, i.e., suspends all - threads except the current. The semantics of this function is similar to - pthread_suspend_all_np(3).

-

The - () - function switches the process to a multi-threaded mode. The semantics of - this function is similar to pthread_resume_all_np(3).

-
-
-

-

The pthread_multi_np() and - pthread_single_np functions always return 0.

-
-
-

-

pthread_np(3), - pthread_resume_all_np(3), - pthread_suspend_all_np(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_consistent.3 3.html b/static/freebsd/man3/pthread_mutex_consistent.3 3.html deleted file mode 100644 index 2ce46974..00000000 --- a/static/freebsd/man3/pthread_mutex_consistent.3 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_CONSISTENT(3)Library Functions ManualPTHREAD_MUTEX_CONSISTENT(3)
-
-
-

-

pthread_mutex_consistent — - mark state protected by robust mutex as - consistent

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutex_consistent(pthread_mutex_t - *mutex);

-
-
-

-

If the process containing the thread owning a robust mutex - terminates while holding the mutex, the mutex becomes inconsistent and the - next thread that acquires the mutex lock is notified of the state by the - return value EOWNERDEAD. In this case, the mutex - does not become normally usable again until the state is marked - consistent.

-

The - (), - when called with the mutex argument, which points to - the initialized robust mutex in an inconsistent state, marks the by mutex as - consistent again. The consequent unlock of the mutex, by either - () - or other methods, allows other contenders to lock the mutex.

-

If the mutex in the inconsistent - state is not marked consistent by the call to - () - before unlock, further attempts to lock the mutex - result in the ENOTRECOVERABLE condition reported by - the locking functions.

-
-
-

-

If successful, pthread_mutex_consistent() - will return zero, otherwise an error number will be returned to indicate the - error.

-
-
-

-

The pthread_mutex_lock() function will - fail if:

-
-
[]
-
The mutex pointed to by the mutex argument is not - robust, or is not in the inconsistent state.
-
-
-
-

-

pthread_mutex_init(3), - pthread_mutex_lock(3), - pthread_mutex_unlock(3), - pthread_mutexattr_setrobust(3)

-
-
-

-

The pthread_mutex_lock() function conforms - to Version 4 of the Single UNIX Specification - (“SUSv4”).

-
-
- - - - - -
March 27, 2017FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_destroy.3 4.html b/static/freebsd/man3/pthread_mutex_destroy.3 4.html deleted file mode 100644 index 4d5b6bd5..00000000 --- a/static/freebsd/man3/pthread_mutex_destroy.3 4.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_DESTROY(3)Library Functions ManualPTHREAD_MUTEX_DESTROY(3)
-
-
-

-

pthread_mutex_destroy — - free resources allocated for a mutex

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutex_destroy(pthread_mutex_t - *mutex);

-
-
-

-

The - () - function frees the resources allocated for mutex.

-
-
-

-

If successful, pthread_mutex_destroy() - will return zero, otherwise an error number will be returned to indicate the - error.

-
-
-

-

The pthread_mutex_destroy() function will - fail if:

-
-
[]
-
The value specified by mutex is invalid.
-
[]
-
Mutex is locked by another thread.
-
-
-
-

-

pthread_mutex_init(3), - pthread_mutex_lock(3), - pthread_mutex_trylock(3), - pthread_mutex_unlock(3)

-
-
-

-

The pthread_mutex_destroy() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
July 29, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_init.3 3.html b/static/freebsd/man3/pthread_mutex_init.3 3.html deleted file mode 100644 index 883374ac..00000000 --- a/static/freebsd/man3/pthread_mutex_init.3 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_INIT(3)Library Functions ManualPTHREAD_MUTEX_INIT(3)
-
-
-

-

pthread_mutex_init — - create a mutex

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutex_init(pthread_mutex_t - *restrict mutex, const - pthread_mutexattr_t *restrict attr);

-
-
-

-

The - () - function creates a new mutex, with attributes specified with - attr. If attr is NULL the - default attributes are used.

-
-
-

-

If successful, pthread_mutex_init() will - return zero and put the new mutex id into mutex, - otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_mutex_init() function will - fail if:

-
-
[]
-
The value specified by attr is invalid.
-
[]
-
The process cannot allocate enough memory to create another mutex.
-
-
-
-

-

pthread_mutex_destroy(3), - pthread_mutex_lock(3), - pthread_mutex_trylock(3), - pthread_mutex_unlock(3), - pthread_mutexattr(3)

-
-
-

-

The pthread_mutex_init() function conforms - to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_lock.3 3.html b/static/freebsd/man3/pthread_mutex_lock.3 3.html deleted file mode 100644 index d4a80620..00000000 --- a/static/freebsd/man3/pthread_mutex_lock.3 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_LOCK(3)Library Functions ManualPTHREAD_MUTEX_LOCK(3)
-
-
-

-

pthread_mutex_lock — - lock a mutex

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutex_lock(pthread_mutex_t - *mutex);

-
-
-

-

The - () - function locks mutex. If the mutex is already locked, - the calling thread will block until the mutex becomes available.

-
-
-

-

If successful, pthread_mutex_lock() will - return zero, otherwise an error number will be returned to indicate the - error.

-
-
-

-

The pthread_mutex_lock() function will - fail if:

-
-
[]
-
The value specified by mutex is invalid.
-
[]
-
A deadlock would occur if the thread blocked waiting for - mutex.
-
[]
-
The argument mutex points to a robust mutex and the - process containing the previous owning thread terminated while holding the - mutex lock. The lock was granted to the caller and it is up to the new - owner to make the state consistent.
-
[]
-
The state protected by the mutex is not - recoverable.
-
-
-
-

-

pthread_mutex_consistent(3), - pthread_mutex_destroy(3), - pthread_mutex_init(3), - pthread_mutex_trylock(3), - pthread_mutex_unlock(3)

-
-
-

-

The pthread_mutex_lock() function conforms - to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
August 7, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_timedlock.3 3.html b/static/freebsd/man3/pthread_mutex_timedlock.3 3.html deleted file mode 100644 index 8bc58642..00000000 --- a/static/freebsd/man3/pthread_mutex_timedlock.3 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_TIMEDLOCK(3)Library Functions ManualPTHREAD_MUTEX_TIMEDLOCK(3)
-
-
-

-

pthread_mutex_timedlock — - lock a mutex without blocking indefinitely

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h> -
- #include <time.h>

-

int -
- pthread_mutex_timedlock(pthread_mutex_t - *restrict mutex, const - struct timespec *restrict abs_timeout);

-
-
-

-

The - () - function will lock mutex. If it is already locked the - calling thread will block until the mutex becomes available or the timeout, - specified by abs_timeout, expires. The time of the timeout is an absolute - time and is not relative to the current time.

-
-
-

-

If successful, pthread_mutex_timedlock() - will return zero, otherwise an error number will be returned to indicate the - error.

-
-
-

-

The pthread_mutex_timedlock() function - will fail if:

-
-
[Er ENOTRECOVERABLE]
-
The mutex was created with the protocol attribute - having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is - higher than the mutex's current priority ceiling.
-
[]
-
The process or thread would have blocked, and - abs_timeout specified a nanosecond value less than - zero or greater than or equal to 1 billion.
-
[]
-
The mutex parameter is invalid.
-
[]
-
The mutex could not be locked before the timeout - expired.
-
[]
-
The mutex could not be acquired because the maximum - number of recursive locks for the mutex has been - exceeded.
-
[]
-
The current thread already owns the mutex.
-
[]
-
The argument mutex points to a robust mutex and the - process containing the previous owning thread terminated while holding the - mutex lock. The lock was granted to the caller and it is up to the new - owner to make the state consistent.
-
[]
-
The state protected by the mutex is not - recoverable.
-
-
-
-

-

pthread_mutex_consistent(3), - pthread_mutex_destroy(3), - pthread_mutex_init(3), - pthread_mutex_lock(3), - pthread_mutex_trylock(3), - pthread_mutex_unlock(3)

-
-
-

-

The pthread_mutex_timedlock() function is - expected to conform to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
August 7, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_trylock.3 3.html b/static/freebsd/man3/pthread_mutex_trylock.3 3.html deleted file mode 100644 index 938da761..00000000 --- a/static/freebsd/man3/pthread_mutex_trylock.3 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_TRYLOCK(3)Library Functions ManualPTHREAD_MUTEX_TRYLOCK(3)
-
-
-

-

pthread_mutex_trylock — - attempt to lock a mutex without blocking

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutex_trylock(pthread_mutex_t - *mutex);

-
-
-

-

The - () - function locks mutex. If the mutex is already locked, - pthread_mutex_trylock() will not block waiting for - the mutex, but will return an error condition.

-
-
-

-

If successful, pthread_mutex_trylock() - will return zero, otherwise an error number will be returned to indicate the - error.

-
-
-

-

The pthread_mutex_trylock() function will - fail if:

-
-
[]
-
The value specified by mutex is invalid.
-
[]
-
Mutex is already locked.
-
[]
-
The argument mutex points to a robust mutex and the - process containing the previous owning thread terminated while holding the - mutex lock. The lock was granted to the caller and it is up to the new - owner to make the state consistent.
-
[]
-
The state protected by the mutex is not - recoverable.
-
-
-
-

-

pthread_mutex_consistent(3), - pthread_mutex_destroy(3), - pthread_mutex_init(3), - pthread_mutex_lock(3), - pthread_mutex_unlock(3)

-
-
-

-

The pthread_mutex_trylock() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
August 7, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutex_unlock.3 3.html b/static/freebsd/man3/pthread_mutex_unlock.3 3.html deleted file mode 100644 index 0a674813..00000000 --- a/static/freebsd/man3/pthread_mutex_unlock.3 3.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
PTHREAD_MUTEX_UNLOCK(3)Library Functions ManualPTHREAD_MUTEX_UNLOCK(3)
-
-
-

-

pthread_mutex_unlock — - unlock a mutex

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutex_unlock(pthread_mutex_t - *mutex);

-
-
-

-

If the current thread holds the lock on - mutex, then the - () - function unlocks mutex.

-

If the argument pointed by the - mutex is a robust mutex in the inconsistent state, and - the call to - () - function was not done prior to unlocking, further locking attempts on the - mutex mutex are denied and locking functions return - ENOTRECOVERABLE error.

-
-
-

-

If successful, pthread_mutex_unlock() will - return zero, otherwise an error number will be returned to indicate the - error.

-
-
-

-

The pthread_mutex_unlock() function will - fail if:

-
-
[]
-
The value specified by mutex is invalid.
-
[]
-
The current thread does not hold a lock on - mutex.
-
-
-
-

-

pthread_mutex_destroy(3), - pthread_mutex_init(3), - pthread_mutex_lock(3), - pthread_mutex_trylock(3)

-
-
-

-

The pthread_mutex_unlock() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
April 29, 2016FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutexattr.3 3.html b/static/freebsd/man3/pthread_mutexattr.3 3.html deleted file mode 100644 index 867f21fd..00000000 --- a/static/freebsd/man3/pthread_mutexattr.3 3.html +++ /dev/null @@ -1,307 +0,0 @@ - - - - - - -
PTHREAD_MUTEXATTR(3)Library Functions ManualPTHREAD_MUTEXATTR(3)
-
-
-

-

pthread_mutexattr_init, - pthread_mutexattr_destroy, - pthread_mutexattr_setprioceiling, - pthread_mutexattr_getprioceiling, - pthread_mutexattr_setprotocol, - pthread_mutexattr_getprotocol, - pthread_mutexattr_setpshared, - pthread_mutexattr_getpshared, - pthread_mutexattr_setrobust, - pthread_mutexattr_getrobust, - pthread_mutexattr_settype, - pthread_mutexattr_gettype — - mutex attribute operations

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_mutexattr_init(pthread_mutexattr_t - *attr);

-

int -
- pthread_mutexattr_destroy(pthread_mutexattr_t - *attr);

-

int -
- pthread_mutexattr_setprioceiling(pthread_mutexattr_t - *attr, int prioceiling);

-

int -
- pthread_mutexattr_getprioceiling(const - pthread_mutexattr_t *attr, int - *prioceiling);

-

int -
- pthread_mutexattr_setprotocol(pthread_mutexattr_t - *attr, int - protocol);

-

int -
- pthread_mutexattr_getprotocol(const - pthread_mutexattr_t *restrict attr, int *restrict - protocol);

-

int -
- pthread_mutexattr_setpshared(pthread_mutexattr_t - *attr, int shared);

-

int -
- pthread_mutexattr_getpshared(const - pthread_mutexattr_t *attr, int *shared);

-

int -
- pthread_mutexattr_setrobust(pthread_mutexattr_t - *attr, int - robust);

-

int -
- pthread_mutexattr_getrobust(pthread_mutexattr_t - *attr, int - *robust);

-

int -
- pthread_mutexattr_settype(pthread_mutexattr_t - *attr, int - type);

-

int -
- pthread_mutexattr_gettype(const - pthread_mutexattr_t *restrict attr, int *restrict - type);

-
-
-

-

Mutex attributes are used to specify parameters to - (). - One attribute object can be used in multiple calls to - pthread_mutex_init(), with or without modifications - between calls.

-

The - () - function initializes attr with all the default mutex - attributes.

-

The - () - function destroys attr.

-

The - () - function sets the priority ceiling for the mutex, used by threads executed - under the PTHREAD_PRIO_PROTECT protocol.

-

The - () - function specifies the protocol to be followed in utilizing mutexes. The - protocol argument can take one of the following - values:

-
-
PTHREAD_PRIO_NONE
-
Priority and scheduling of the thread owning this mutex is not affected by - its mutex ownership.
-
PTHREAD_PRIO_INHERIT
-
Request priority-inheritance protocol, where the thread owning the mutex - is executed at the highest priority among priorities of all threads - waiting on any mutex owned by this thread.
-
PTHREAD_PRIO_PROTECT
-
Request priority-inheritance protocol, where the thread owning the mutex - is executed at highest priority among priorities or priority ceilings of - all threads waiting on any mutex owned by this thread.
-
-

The - () - function sets the process-shared attribute of attr to - the value specified in pshared. The argument - pshared may have one of the following values:

-
-
-
The mutex may only be used by threads in the same process as the one that - created the object.
-
-
The mutex may be used by threads in processes other than the one that - created the object, assuming other processes share access to the memory - where the mutex was allocated.
-
-See libthr(3) for details of the implementation of the shared - mutexes, and their limitations. -

The - () - function specifies robustness attribute of the mutex. Possible values for - the robust argument are

-
-
PTHREAD_MUTEX_STALLED
-
No special actions are taken if the thread owning the mutex is terminated - without unlocking the mutex lock. This can lead to deadlocks if no other - thread can unlock the mutex. This is the default value.
-
PTHREAD_MUTEX_ROBUST
-
If the process containing the owning thread of a robust mutex, or owning - thread, terminates while holding the mutex lock, the next thread that - acquires the mutex is notified about the termination by the return value - EOWNERDEAD from the locking function. Then, either - pthread_mutex_consistent(3) can be used to repair the - mutex lock state, or pthread_mutex_unlock(3) can unlock - the mutex lock but also put it an unusable state, where all further - attempts to acquire it result in the - ENOTRECOVERABLE error.
-
-

The - () - function sets the type of the mutex. The type affects the behavior of calls - which lock and unlock the mutex. The possible values for the - type argument are

-
-
PTHREAD_MUTEX_NORMAL
-
Both recursive locking, and unlocking when the lock is not owned by the - current thread, cause an error to be returned from the corresponding - functions. This matches PTHREAD_MUTEX_ERRORCHECK - but somewhat contradicts the behavior mandated by POSIX.
-
PTHREAD_MUTEX_ERRORCHECK
-
Both recursive locking, and unlocking when the lock is not owned by the - current thread, cause an error returned from the corresponding - functions.
-
PTHREAD_MUTEX_RECURSIVE
-
Recursive locking is allowed. Attempt to unlock when current thread is not - an owner of the lock causes an error to be returned.
-
PTHREAD_MUTEX_DEFAULT
-
The FreeBSD implementation maps this type to - PTHREAD_MUTEX_ERRORCHECK type.
-
-

The - () - functions copy the value of the attribute that corresponds to each function - name to the location pointed to by the second function parameter.

-
-
-

-

If successful, these functions return 0. Otherwise, an error - number is returned to indicate the error.

-
-
-

-

The pthread_mutexattr_init() function will - fail if:

-
-
[]
-
Out of memory.
-
-

The pthread_mutexattr_destroy() function - will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_mutexattr_setprioceiling() - function will fail if:

-
-
[]
-
Invalid value for attr, or invalid value for - prioceiling.
-
-

The pthread_mutexattr_getprioceiling() - function will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_mutexattr_setprotocol() - function will fail if:

-
-
[]
-
Invalid value for attr, or invalid value for - protocol.
-
-

The pthread_mutexattr_getprotocol() - function will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_mutexattr_setpshared() - function will fail if:

-
-
[]
-
Invalid value for attr, or invalid value for - shared.
-
-

The pthread_mutexattr_getpshared() - function will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_mutexattr_settype() function - will fail if:

-
-
[]
-
Invalid value for attr, or invalid value for - type.
-
-

The pthread_mutexattr_gettype() function - will fail if:

-
-
[]
-
Invalid value for attr.
-
-

The pthread_mutexattr_setrobust() function - will fail if:

-
-
[]
-
Invalid value for attr, or invalid value for - robust.
-
-

The pthread_mutexattr_getrobust() function - will fail if:

-
-
[]
-
Invalid value for attr.
-
-
-
-

-

libthr(3), - pthread_mutex_init(3)

-
-
-

-

The pthread_mutexattr_init() and - pthread_mutexattr_destroy() functions conform to - ISO/IEC 9945-1:1996 (“POSIX.1”)

-

The pthread_mutexattr_setprioceiling(), - pthread_mutexattr_getprioceiling(), - pthread_mutexattr_setprotocol(), - pthread_mutexattr_getprotocol(), - pthread_mutexattr_setpshared(), - pthread_mutexattr_getpshared(), - pthread_mutexattr_settype(), and - pthread_mutexattr_gettype() functions conform to - Version 2 of the Single UNIX Specification - (“SUSv2”). The - pthread_mutexattr_setrobust() and - pthread_mutexattr_getrobust() functions conform to - Version 4 of the Single UNIX Specification - (“SUSv4”).

-
-
- - - - - -
October 27, 2023FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_mutexattr_getkind_np.3 3.html b/static/freebsd/man3/pthread_mutexattr_getkind_np.3 3.html deleted file mode 100644 index e463c89f..00000000 --- a/static/freebsd/man3/pthread_mutexattr_getkind_np.3 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
PTHREAD_MUTEXATTR_GETKIND_NP(3)Library Functions ManualPTHREAD_MUTEXATTR_GETKIND_NP(3)
-
-
-

-

pthread_mutexattr_getkind_np, - pthread_mutexattr_setkind_np — - mutex attribute operations (legacy)

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_mutexattr_getkind_np(pthread_mutexattr_t - attr);

-

int -
- pthread_mutexattr_setkind_np(pthread_mutexattr_t - *attr, int - kind);

-
-
-

-
These functions are deprecated and non-portable - implementation of the mutex type manipulation.
-

It is recommended to use the - pthread_mutexattr_gettype(3) and - pthread_mutexattr_settype(3) functions instead.

-
-
-

-

The pthread_mutexattr_getkind_np() - function returns a positive value representing the “kind” of - the mutex attribute attr if successful; otherwise the - value -1 is returned and the global variable errno is - set to indicate the error.

-

-
- The pthread_mutexattr_setkind_np() function returns - the value 0 if successful; otherwise the value -1 is returned - and the global variable errno is set to indicate the - error.

-
-
-

-

The pthread_mutexattr_getkind_np() and - pthread_mutexattr_setkind_np() functions will fail - if:

-
-
[]
-
The value specified by attr is invalid.
-
-
-
-

-

pthread_mutex_destroy(3), - pthread_mutex_init(3), - pthread_mutexattr_gettype(3), - pthread_mutexattr_settype(3), - pthread_np(3)

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_np.3 3.html b/static/freebsd/man3/pthread_np.3 3.html deleted file mode 100644 index f51957de..00000000 --- a/static/freebsd/man3/pthread_np.3 3.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
PTHREAD_NP(3)Library Functions ManualPTHREAD_NP(3)
-
-
-

-

pthread_np — - FreeBSD extensions to POSIX thread functions

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-
-
-

-

This manual page documents extensions to the POSIX thread - functions. These extensions may or may not be portable to other operating - systems.

-

The POSIX thread functions are summarized in this section in the - following groups:

-

-
    -
  • Thread Routines
    • -
  • Attribute Object Routines
    • -
  • Mutex Routines
    • -
-
-

-
-
int - (pthread_t - td, size_t cpusetsize, cpuset_t - *cpusetp);
-
Get the CPU affinity of a specified thread.
-
int - (pthread_t - thread, char *name, size_t - len)
-
Get the name of a specified thread.
-
int - (pthread_t - thread, char *name, size_t - len)
-
Get the name of a specified thread.
-
int - (void)
-
Get the calling thread's integral ID.
-
int - (void)
-
Identify the initial thread.
-
int - (void)
-
Sets the thread's scheduling mode to multi-threaded.
-
int - (pthread_t - thread, void **value_ptr)
-
Peek into the exit status of a specified thread.
-
int - (void)
-
Resume all suspended threads.
-
int - (pthread_t - td, size_t cpusetsize, const - cpuset_t *cpusetp);
-
Set the CPU affinity of a specified thread.
-
int - (pthread_t - thread, char *name)
-
Sets the specified thread's name.
-
int - (pthread_t - thread, char *name)
-
Sets the specified thread's name.
-
void - (void)
-
Blocks all asynchronous signals, quickly.
-
int - (void)
-
Sets the thread's scheduling mode to single-threaded.
-
int - (pthread_t - tid)
-
Suspend the specified thread.
-
int - (void)
-
Suspend all active threads.
-
int - (pthread_t - thread, void **value_ptr, const - struct timespec *abstime);
-
A variant of - () - with a timeout.
-
-
-
-

-
-
int - (pthread_t - pid, pthread_attr_t *dst);
-
Get the attributes of an existent thread.
-
int - (const - pthread_attr_t *pattr, size_t cpusetsize, - cpuset_t *cpusetp);
-
Get the CPU affinity mask from the thread attribute object.
-
int - (pthread_attr_t - *pattr, size_t cpusetsize, const - cpuset_t *cpusetp);
-
Set the CPU affinity mask for the thread attribute object.
-
int - (pthread_attr_t - *attr)
-
Permit creation of suspended threads.
-
-
-
-

-
-
int - (pthread_mutexattr_t - attr)
-
Deprecated, use pthread_mutexattr_gettype(3) - instead.
-
int - (pthread_mutexattr_t - *attr)
-
Deprecated, use pthread_mutexattr_settype(3) - instead.
-
-
-
-
-

-

libthr(3), pthread(3), - pthread_affinity_np(3), - pthread_attr_affinity_np(3), - pthread_attr_get_np(3), - pthread_attr_setcreatesuspend_np(3), - pthread_getthreadid_np(3), - pthread_join(3), pthread_main_np(3), - pthread_multi_np(3), - pthread_mutexattr_getkind_np(3), - pthread_resume_all_np(3), - pthread_resume_np(3), - pthread_set_name_np(3), - pthread_signals_block_np(3), - pthread_suspend_all_np(3), - pthread_suspend_np(3), - pthread_switch_add_np(3)

-
-
-

-

All of these functions are non-portable extensions to POSIX - threads.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_once.3 3.html b/static/freebsd/man3/pthread_once.3 3.html deleted file mode 100644 index f0b90d08..00000000 --- a/static/freebsd/man3/pthread_once.3 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
PTHREAD_ONCE(3)Library Functions ManualPTHREAD_ONCE(3)
-
-
-

-

pthread_once — - dynamic package initialization

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

pthread_once_t once_control = - PTHREAD_ONCE_INIT; -
- int -
- pthread_once(pthread_once_t - *once_control, void - (*init_routine)(void));

-
-
-

-

The first call to - () - by any thread in a process, with a given once_control, - will call the - () - with no arguments. Subsequent calls to - pthread_once() with the same - once_control will not call the - init_routine(). On return from - pthread_once(), it is guaranteed that - init_routine() has completed. The - once_control parameter is used to determine whether - the associated initialization routine has been called.

-

The function - () - is not a cancellation point. However, if - () - is a cancellation point and is cancelled, the effect on - once_control is as if - pthread_once() was never called.

-

The constant PTHREAD_ONCE_INIT is defined by - header <pthread.h>.

-

The behavior of - () - is undefined if once_control has automatic storage - duration or is not initialized by - PTHREAD_ONCE_INIT.

-
-
-

-

If successful, the pthread_once() function - will return zero. Otherwise an error number will be returned to indicate the - error.

-
-
-

-

None.

-
-
-

-

The pthread_once() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_resume_all_np.3 4.html b/static/freebsd/man3/pthread_resume_all_np.3 4.html deleted file mode 100644 index a9c661f8..00000000 --- a/static/freebsd/man3/pthread_resume_all_np.3 4.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
PTHREAD_RESUME_ALL_NP(3)Library Functions ManualPTHREAD_RESUME_ALL_NP(3)
-
-
-

-

pthread_resume_all_np — - resume all suspended threads

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

void -
- pthread_resume_all_np(void);

-
-
-

-

The - () - function causes all active threads to be scanned and resumes those which - were previously suspended.

-
-
-

-

pthread_attr_setcreatesuspend_np(3), - pthread_np(3), pthread_resume_np(3), - pthread_suspend_all_np(3), - pthread_suspend_np(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_resume_np.3 3.html b/static/freebsd/man3/pthread_resume_np.3 3.html deleted file mode 100644 index 438b09dd..00000000 --- a/static/freebsd/man3/pthread_resume_np.3 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
PTHREAD_RESUME_NP(3)Library Functions ManualPTHREAD_RESUME_NP(3)
-
-
-

-

pthread_resume_np — - resume suspended thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_resume_np(pthread_t - tid);

-
-
-

-

The - () - function, called on a suspended thread, causes it to resume. If a thread - specified by the tid argument is not suspended, no - actions will be performed.

-
-
-

-

If successful, pthread_resume_np() - function returns 0. Otherwise, an error number is returned to indicate the - error.

-
-
-

-

The pthread_resume_np() function will fail - if:

-
-
[]
-
The value specified by the tid argument is - invalid.
-
[]
-
No thread could be found corresponding to the thread ID specified by the - tid argument.
-
-
-
-

-

pthread_attr_setcreatesuspend_np(3), - pthread_np(3), pthread_resume_all_np(3), - pthread_suspend_all_np(3), - pthread_suspend_np(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_destroy.3 4.html b/static/freebsd/man3/pthread_rwlock_destroy.3 4.html deleted file mode 100644 index d2e502e7..00000000 --- a/static/freebsd/man3/pthread_rwlock_destroy.3 4.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_DESTROY(3)Library Functions ManualPTHREAD_RWLOCK_DESTROY(3)
-
-
-

-

pthread_rwlock_destroy — - destroy a read/write lock

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_destroy(pthread_rwlock_t - *lock);

-
-
-

-

The - () - function is used to destroy a read/write lock previously created with - ().

-
-
-

-

If successful, the - pthread_rwlock_destroy() function will return zero. - Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlock_destroy() function will - fail if:

-
-
[]
-
The caller does not have the privilege to perform the operation.
-
-

The pthread_rwlock_destroy() function may - fail if:

-
-
[]
-
The system has detected an attempt to destroy the object referenced by - lock while it is locked.
-
[]
-
The value specified by lock is invalid.
-
-
-
-

-

pthread_rwlock_init(3)

-
-
-

-

The pthread_rwlock_destroy() function is - expected to conform to Version 2 of the Single UNIX - Specification (“SUSv2”).

-
-
-

-

The pthread_rwlock_destroy() function - first appeared in FreeBSD 3.0.

-
-
- - - - - -
August 4, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_init.3 3.html b/static/freebsd/man3/pthread_rwlock_init.3 3.html deleted file mode 100644 index bf78b5f8..00000000 --- a/static/freebsd/man3/pthread_rwlock_init.3 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_INIT(3)Library Functions ManualPTHREAD_RWLOCK_INIT(3)
-
-
-

-

pthread_rwlock_init — - initialize a read/write lock

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_init(pthread_rwlock_t - *restrict lock, const - pthread_rwlockattr_t *restrict attr);

-
-
-

-

The - () - function is used to initialize a read/write lock, with attributes specified - by attr. If attr is NULL, the - default read/write lock attributes are used.

-

The results of calling - () - with an already initialized lock are undefined.

-
-
-

-

If successful, the pthread_rwlock_init() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_rwlock_init() function will - fail if:

-
-
[]
-
The system lacked the necessary resources (other than memory) to - initialize the lock.
-
[]
-
Insufficient memory exists to initialize the lock.
-
[]
-
The caller does not have sufficient privilege to perform the - operation.
-
-

The pthread_rwlock_init() function may - fail if:

-
-
[]
-
The system has detected an attempt to re-initialize the object referenced - by lock, a previously initialized but not yet - destroyed read/write lock.
-
[]
-
The value specified by attr is invalid.
-
-
-
-

-

pthread_rwlock_destroy(3), - pthread_rwlockattr_init(3), - pthread_rwlockattr_setpshared(3)

-
-
-

-

The pthread_rwlock_init() function is - expected to conform to Version 2 of the Single UNIX - Specification (“SUSv2”).

-
-
-

-

The pthread_rwlock_init() function first - appeared in FreeBSD 3.0.

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_rdlock.3 3.html b/static/freebsd/man3/pthread_rwlock_rdlock.3 3.html deleted file mode 100644 index a54dcdae..00000000 --- a/static/freebsd/man3/pthread_rwlock_rdlock.3 3.html +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_RDLOCK(3)Library Functions ManualPTHREAD_RWLOCK_RDLOCK(3)
-
-
-

-

pthread_rwlock_rdlock, - pthread_rwlock_tryrdlock — - acquire a read/write lock for reading

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_rdlock(pthread_rwlock_t - *lock);

-

int -
- pthread_rwlock_tryrdlock(pthread_rwlock_t - *lock);

-
-
-

-

The - () - function acquires a read lock on lock provided that - lock is not presently held for writing and no writer - threads are presently blocked on the lock. If the read lock cannot be - immediately acquired, the calling thread blocks until it can acquire the - lock.

-

The - () - function performs the same action, but does not block if the lock cannot be - immediately obtained (i.e., the lock is held for writing or there are - waiting writers).

-

A thread may hold multiple concurrent - read locks. If so, - () - must be called once for each lock obtained.

-

The results of acquiring a read lock while the calling thread - holds a write lock are undefined.

-
-
-

-

To prevent writer starvation, writers are favored over - readers.

-
-
-

-

If successful, the pthread_rwlock_rdlock() - and pthread_rwlock_tryrdlock() functions will return - zero. Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlock_tryrdlock() function - will fail if:

-
-
[]
-
The lock could not be acquired because a writer holds the lock or was - blocked on it.
-
-

The pthread_rwlock_rdlock() and - pthread_rwlock_tryrdlock() functions may fail - if:

-
-
[]
-
The lock could not be acquired because the maximum number of read locks - against lock has been exceeded.
-
[]
-
The current thread already owns lock for - writing.
-
[]
-
The value specified by lock is invalid.
-
[]
-
Insufficient memory exists to initialize the lock (applies to statically - initialized locks only).
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlock_trywrlock(3), - pthread_rwlock_unlock(3), - pthread_rwlock_wrlock(3)

-
-
-

-

The pthread_rwlock_rdlock() and - pthread_rwlock_tryrdlock() functions are expected to - conform to Version 2 of the Single UNIX - Specification (“SUSv2”).

-
-
-

-

The pthread_rwlock_rdlock() function first - appeared in FreeBSD 3.0.

-
-
- - - - - -
August 4, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_timedrdlock.3 3.html b/static/freebsd/man3/pthread_rwlock_timedrdlock.3 3.html deleted file mode 100644 index c7ba73b7..00000000 --- a/static/freebsd/man3/pthread_rwlock_timedrdlock.3 3.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_TIMEDRDLOCK(3)Library Functions ManualPTHREAD_RWLOCK_TIMEDRDLOCK(3)
-
-
-

-

pthread_rwlock_timedrdlock — - acquire a read-write lock for reading or give up after a - specified period

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_timedrdlock(pthread_rwlock_t - *restrict rwlock, const - struct timespec *restrict abs_timeout);

-
-
-

-

This function acquires a read lock on the read-write lock - rwlock. However, if the lock cannot be acquired - without waiting for another thread to unlock the lock, this wait shall be - terminated when abs_timeout expires.

-

A thread may hold multiple concurrent read locks. The - pthread_rwlock_unlock(3) function must be called once for - each lock acquired.

-

If the thread should be - interrupted by a signal, the - () - function will be automatically restarted after the thread returns from the - signal handler.

-

The calling thread may deadlock if at the time the call is made it - holds a write lock on rwlock. The results are - undefined if this function is called with an uninitialized read-write - lock.

-
-
-

-

To prevent writer starvation, writers are favored over - readers.

-
-
-

-

If successful, the - pthread_rwlock_timedrdlock() function will return - zero. Otherwise, an error number will be returned to indicate the error.

-

This function shall not return an error code of - EINTR.

-
-
-

-

The pthread_rwlock_timedrdlock() function - will fail if:

-
-
[]
-
The lock could not be acquired before the specified timeout expired.
-
-

The pthread_rwlock_timedrdlock() function - may fail if:

-
-
[]
-
The read lock could not be acquired because the maximum number of read - locks for rwlock would be exceeded.
-
[]
-
The calling thread already holds a write lock on - rwlock.
-
[]
-
The value specified by rwlock does not refer to an - initialized read-write lock object, or the - abs_timeout nanosecond value is less than zero or - greater than or equal to 1 billion.
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlock_timedwrlock(3), - pthread_rwlock_unlock(3)

-
-
-

-

The pthread_rwlock_timedrdlock() function - is expected to conform to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
-

-

The pthread_rwlock_timedrdlock() function - first appeared in FreeBSD 5.2.

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_timedwrlock.3 3.html b/static/freebsd/man3/pthread_rwlock_timedwrlock.3 3.html deleted file mode 100644 index 4995cab7..00000000 --- a/static/freebsd/man3/pthread_rwlock_timedwrlock.3 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_TIMEDWRLOCK(3)Library Functions ManualPTHREAD_RWLOCK_TIMEDWRLOCK(3)
-
-
-

-

pthread_rwlock_timedwrlock — - acquire a read-write lock for writing or give up after a - specified period

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_timedwrlock(pthread_rwlock_t - *restrict rwlock, const - struct timespec *restrict abs_timeout);

-
-
-

-

This function acquires a write lock on the read-write lock - rwlock. However, if the lock cannot be acquired - without waiting for another thread to unlock the lock, this wait shall be - terminated when abs_timeout expires.

-

If the thread should be - interrupted by a signal, the - () - function will be automatically restarted after the thread returns from the - signal handler.

-

The calling thread may deadlock if at the time the call is made it - holds rwlock. The results are undefined if this - function is called with an uninitialized read-write lock.

-
-
-

-

To prevent writer starvation, writers are favored over - readers.

-
-
-

-

If successful, the - pthread_rwlock_timedwrlock() function will return - zero. Otherwise, an error number will be returned to indicate the error.

-

This function shall not return an error code of - EINTR.

-
-
-

-

The pthread_rwlock_timedwrlock() function - shall fail if:

-
-
[]
-
The lock could not be acquired before the specified timeout expired.
-
-

The pthread_rwlock_timedwrlock() function - may fail if:

-
-
[]
-
The calling thread already holds rwlock.
-
[]
-
The value specified by rwlock does not refer to an - initialized read-write lock object, or the - abs_timeout nanosecond value is less than zero or - greater than or equal to 1 billion.
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlock_timedrdlock(3), - pthread_rwlock_unlock(3)

-
-
-

-

The pthread_rwlock_timedwrlock() function - is expected to conform to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
-

-

The pthread_rwlock_timedwrlock() function - first appeared in FreeBSD 5.2.

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_unlock.3 3.html b/static/freebsd/man3/pthread_rwlock_unlock.3 3.html deleted file mode 100644 index d93e16c0..00000000 --- a/static/freebsd/man3/pthread_rwlock_unlock.3 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_UNLOCK(3)Library Functions ManualPTHREAD_RWLOCK_UNLOCK(3)
-
-
-

-

pthread_rwlock_unlock — - release a read/write lock

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_unlock(pthread_rwlock_t - *lock);

-
-
-

-

The - () - function is used to release the read/write lock previously obtained by - (), - (), - (), - or - ().

-
-
-

-

If successful, the pthread_rwlock_unlock() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-

The results are undefined if lock is not - held by the calling thread.

-
-
-

-

The pthread_rwlock_unlock() function may - fail if:

-
-
[]
-
The value specified by lock is invalid.
-
[]
-
The current thread does not own the read/write lock.
-
-
-
-

-

pthread_rwlock_rdlock(3), - pthread_rwlock_wrlock(3)

-
-
-

-

The pthread_rwlock_unlock() function is - expected to conform to Version 2 of the Single UNIX - Specification (“SUSv2”).

-
-
-

-

The pthread_rwlock_unlock() function first - appeared in FreeBSD 3.0.

-
-
- - - - - -
August 4, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlock_wrlock.3 3.html b/static/freebsd/man3/pthread_rwlock_wrlock.3 3.html deleted file mode 100644 index 09591f6c..00000000 --- a/static/freebsd/man3/pthread_rwlock_wrlock.3 3.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - -
PTHREAD_RWLOCK_WRLOCK(3)Library Functions ManualPTHREAD_RWLOCK_WRLOCK(3)
-
-
-

-

pthread_rwlock_wrlock, - pthread_rwlock_trywrlock — - acquire a read/write lock for writing

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlock_wrlock(pthread_rwlock_t - *lock);

-

int -
- pthread_rwlock_trywrlock(pthread_rwlock_t - *lock);

-
-
-

-

The - () - function blocks until a write lock can be acquired against - lock. The - () - function performs the same action, but does not block if the lock cannot be - immediately obtained.

-

The results are undefined if the calling thread already holds the - lock at the time the call is made.

-
-
-

-

To prevent writer starvation, writers are favored over - readers.

-
-
-

-

If successful, the pthread_rwlock_wrlock() - and pthread_rwlock_trywrlock() functions will return - zero. Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlock_trywrlock() function - will fail if:

-
-
[]
-
The calling thread is not able to acquire the lock without blocking.
-
-

The pthread_rwlock_wrlock() and - pthread_rwlock_trywrlock() functions may fail - if:

-
-
[]
-
The calling thread already owns the read/write lock (for reading or - writing).
-
[]
-
The value specified by lock is invalid.
-
[]
-
Insufficient memory exists to initialize the lock (applies to statically - initialized locks only).
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlock_rdlock(3), - pthread_rwlock_tryrdlock(3), - pthread_rwlock_unlock(3)

-
-
-

-

The pthread_rwlock_wrlock() and - pthread_rwlock_trywrlock() functions are expected to - conform to Version 2 of the Single UNIX - Specification (“SUSv2”).

-
-
-

-

The pthread_rwlock_wrlock() function first - appeared in FreeBSD 3.0.

-
-
- - - - - -
August 4, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlockattr_destroy.3 3.html b/static/freebsd/man3/pthread_rwlockattr_destroy.3 3.html deleted file mode 100644 index 5898a0f5..00000000 --- a/static/freebsd/man3/pthread_rwlockattr_destroy.3 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
PTHREAD_RWLOCKATTR_DESTROY(3)Library Functions ManualPTHREAD_RWLOCKATTR_DESTROY(3)
-
-
-

-

pthread_rwlockattr_destroy — - destroy a read/write lock attributes object

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlockattr_destroy(pthread_rwlockattr_t - *attr);

-
-
-

-

The - () - function is used to destroy a read/write lock attributes object previously - created with - ().

-
-
-

-

If successful, the - pthread_rwlockattr_destroy() function will return - zero. Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlockattr_destroy() function - may fail if:

-
-
[]
-
The value specified by attr is invalid.
-
-
-
-

-

pthread_rwlockattr_init(3)

-
-
-

-

The pthread_rwlockattr_destroy() function - is expected to conform to Version 2 of the Single - UNIX Specification (“SUSv2”).

-
-
-

-

The pthread_rwlockattr_destroy() function - first appeared in FreeBSD 3.0.

-
-
- - - - - -
August 4, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlockattr_getpshared.3 3.html b/static/freebsd/man3/pthread_rwlockattr_getpshared.3 3.html deleted file mode 100644 index d9ca9c23..00000000 --- a/static/freebsd/man3/pthread_rwlockattr_getpshared.3 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
PTHREAD_RWLOCKATTR_GETPSHARED(3)Library Functions ManualPTHREAD_RWLOCKATTR_GETPSHARED(3)
-
-
-

-

pthread_rwlockattr_getpshared — - get the process shared attribute

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlockattr_getpshared(const - pthread_rwlockattr_t *restrict attr, int *restrict - pshared);

-
-
-

-

The - () - function is used to get the process shared setting of a read/write lock - attribute object. The setting is returned via pshared, - and may be one of two values:

-
-
-
Any thread of any process that has access to the memory where the - read/write lock resides can manipulate the lock.
-
-
Only threads created within the same process as the thread that - initialized the read/write lock can manipulate the lock. This is the - default value.
-
-
-
-

-

If successful, the - pthread_rwlockattr_getpshared() function will return - zero. Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlockattr_getpshared() - function may fail if:

-
-
[]
-
The value specified by attr is invalid.
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlockattr_init(3), - pthread_rwlockattr_setpshared(3)

-
-
-

-

The pthread_rwlockattr_getpshared() - function is expected to conform to Version 2 of the - Single UNIX Specification (“SUSv2”).

-
-
-

-

The pthread_rwlockattr_getpshared() - function first appeared in FreeBSD 3.0.

-
-
- - - - - -
August 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlockattr_init.3 4.html b/static/freebsd/man3/pthread_rwlockattr_init.3 4.html deleted file mode 100644 index c6382a73..00000000 --- a/static/freebsd/man3/pthread_rwlockattr_init.3 4.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
PTHREAD_RWLOCKATTR_INIT(3)Library Functions ManualPTHREAD_RWLOCKATTR_INIT(3)
-
-
-

-

pthread_rwlockattr_init — - initialize a read/write lock attributes object

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlockattr_init(pthread_rwlockattr_t - *attr);

-
-
-

-

The - () - function is used to initialize a read/write lock attributes object.

-
-
-

-

If successful, the - pthread_rwlockattr_init() function will return zero. - Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlockattr_init() function - will fail if:

-
-
[]
-
Insufficient memory exists to initialize the attributes object.
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlockattr_destroy(3), - pthread_rwlockattr_getpshared(3), - pthread_rwlockattr_setpshared(3)

-
-
-

-

The pthread_rwlockattr_init() function is - expected to conform to Version 2 of the Single UNIX - Specification (“SUSv2”).

-
-
-

-

The pthread_rwlockattr_init() function - first appeared in FreeBSD 3.0.

-
-
- - - - - -
August 4, 1998FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_rwlockattr_setpshared.3 3.html b/static/freebsd/man3/pthread_rwlockattr_setpshared.3 3.html deleted file mode 100644 index 527a421c..00000000 --- a/static/freebsd/man3/pthread_rwlockattr_setpshared.3 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
PTHREAD_RWLOCKATTR_SETPSHARED(3)Library Functions ManualPTHREAD_RWLOCKATTR_SETPSHARED(3)
-
-
-

-

pthread_rwlockattr_setpshared — - set the process shared attribute

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_rwlockattr_setpshared(pthread_rwlockattr_t - *attr, int - pshared);

-
-
-

-

The - () - function sets the process shared attribute of attr to - the value referenced by pshared. The - pshared argument may be one of two values:

-
-
-
Any thread of any process that has access to the memory where the - read/write lock resides can manipulate the lock.
-
-
Only threads created within the same process as the thread that - initialized the read/write lock can manipulate the lock. This is the - default value.
-
-
-
-

-

If successful, the - pthread_rwlockattr_setpshared() function will return - zero. Otherwise an error number will be returned to indicate the error.

-
-
-

-

The pthread_rwlockattr_setpshared() - function will fail if:

-
-
[]
-
The value specified by attr or - pshared is invalid.
-
-
-
-

-

pthread_rwlock_init(3), - pthread_rwlockattr_getpshared(3), - pthread_rwlockattr_init(3)

-
-
-

-

The pthread_rwlockattr_setpshared() - function is expected to conform to Version 2 of the - Single UNIX Specification (“SUSv2”).

-
-
-

-

The pthread_rwlockattr_setpshared() - function first appeared in FreeBSD 3.0. Support for - process-shared read/write locks appeared in FreeBSD - 11.0.

-
-
- - - - - -
May 31, 2016FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_schedparam.3 3.html b/static/freebsd/man3/pthread_schedparam.3 3.html deleted file mode 100644 index 6413a4f4..00000000 --- a/static/freebsd/man3/pthread_schedparam.3 3.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - -
PTHREAD_SCHEDPARAM(3)Library Functions ManualPTHREAD_SCHEDPARAM(3)
-
-
-

-

pthread_setschedparam, - pthread_getschedparam — - thread scheduling parameter manipulation

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_setschedparam(pthread_t - thread, int policy, - const struct sched_param - *param);

-

int -
- pthread_getschedparam(pthread_t - thread, int *restrict - policy, struct - sched_param *restrict param);

-
-
-

-

The - () - and - () - functions set and get the scheduling parameters of individual threads. The - scheduling policy for a thread can either be - SCHED_FIFO (first in, first out), - SCHED_RR (round-robin), or - SCHED_OTHER (timesharing). Valid thread priorities - (accessed via param->sched_priority) must be within - the range returned by the sched_get_priority_min(2) and - sched_get_priority_max(2) system calls.

-
-
-

-

If successful, these functions return 0. Otherwise, an error - number is returned to indicate the error.

-
-
-

-

The pthread_setschedparam() function will - fail if:

-
-
[]
-
Invalid value for policy.
-
[]
-
Invalid value for scheduling parameters.
-
[]
-
The calling thread does not have sufficient privilege to perform the - operation.
-
[]
-
Non-existent thread thread.
-
-

The pthread_getschedparam() function will - fail if:

-
-
[]
-
Non-existent thread thread.
-
-
-
-

-

sched_get_priority_max(2), - sched_get_priority_min(2)

-
-
-

-

The pthread_setschedparam() and - pthread_getschedparam() functions conform to - Version 2 of the Single UNIX Specification - (“SUSv2”).

-
-
- - - - - -
October 17, 2022FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_self.3 4.html b/static/freebsd/man3/pthread_self.3 4.html deleted file mode 100644 index c22ee712..00000000 --- a/static/freebsd/man3/pthread_self.3 4.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - -
PTHREAD_SELF(3)Library Functions ManualPTHREAD_SELF(3)
-
-
-

-

pthread_self — get - the calling thread's ID

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

pthread_t -
- pthread_self(void);

-
-
-

-

The - () - function returns the thread ID of the calling thread.

-
-
-

-

The pthread_self() function returns the - thread ID of the calling thread.

-
-
-

-

None.

-
-
-

-

pthread_create(3), - pthread_equal(3), - pthread_getthreadid_np(3)

-
-
-

-

The pthread_self() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_set_name_np.3 3.html b/static/freebsd/man3/pthread_set_name_np.3 3.html deleted file mode 100644 index 76e23cff..00000000 --- a/static/freebsd/man3/pthread_set_name_np.3 3.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - -
PTHREAD_SET_NAME_NP(3)Library Functions ManualPTHREAD_SET_NAME_NP(3)
-
-
-

-

pthread_get_name_np, - pthread_getname_np, - pthread_set_name_np, - pthread_setname_np — set and - retrieve the thread name

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

void -
- pthread_get_name_np(pthread_t - thread, char *name, - size_t len);

-

int -
- pthread_getname_np(pthread_t - thread, char *name, - size_t len);

-

void -
- pthread_set_name_np(pthread_t - thread, const char - *name);

-

int -
- pthread_setname_np(pthread_t - thread, const char - *name);

-
-
-

-

The - () - and - () - functions apply a copy of the given name to the given - thread.

-

The - () - and - () - functions retrieve the name associated with - thread. If - pthread_set_name_np() was not previously called for - thread, the buffer pointed to by - name will be empty.

-
-
-

-

The pthread_getname_np and - pthread_setname_np will fail if

-
-
[]
-
No thread could be found in the current process corresponding to that - specified by the given thread ID thread.
-
-

Because of the debugging nature of - pthread_get_name_np and - pthread_set_name_np functions, all errors that may - appear inside are silently ignored.

-
-
-

-

thr_set_name(2), - pthread_np(3)

-
-
-

-

pthread_set_name_np() and - pthread_get_name_np() are non-standard extensions. - pthread_setname_np() and - pthread_getname_np() are also non-standard, but are - implemented by larger number of operating systems so they are in fact more - portable.

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org> - and -
- Yuri Pankov - <yuripv@yuripv.net>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_setspecific.3 3.html b/static/freebsd/man3/pthread_setspecific.3 3.html deleted file mode 100644 index 770dfe59..00000000 --- a/static/freebsd/man3/pthread_setspecific.3 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
PTHREAD_SETSPECIFIC(3)Library Functions ManualPTHREAD_SETSPECIFIC(3)
-
-
-

-

pthread_setspecific — - set a thread-specific data value

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_setspecific(pthread_key_t - key, const void - *value);

-
-
-

-

The - () - function associates a thread-specific value with a key - obtained via a previous call to - (). - Different threads can bind different values to the same key. These values - are typically pointers to blocks of dynamically allocated memory that have - been reserved for use by the calling thread.

-

The effect of calling - () - with a key value not obtained from - () - or after key has been deleted with - () - is undefined.

-

The - () - function may be called from a thread-specific data destructor function, - however this may result in lost storage or infinite loops if doing so causes - non-NULL key values to remain after [PTHREAD_DESTRUCTOR_ITERATIONS] - iterations of destructor calls have been made.

-
-
-

-

If successful, the pthread_setspecific() - function will return zero. Otherwise an error number will be returned to - indicate the error.

-
-
-

-

The pthread_setspecific() function will - fail if:

-
-
[]
-
Insufficient memory exists to associate the value with the - key.
-
[]
-
The key value is invalid.
-
-
-
-

-

pthread_getspecific(3), - pthread_key_create(3), - pthread_key_delete(3)

-
-
-

-

The pthread_setspecific() function - conforms to ISO/IEC 9945-1:1996 - (“POSIX.1”).

-
-
- - - - - -
April 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_sigmask.3 3.html b/static/freebsd/man3/pthread_sigmask.3 3.html deleted file mode 100644 index 02bfa4ad..00000000 --- a/static/freebsd/man3/pthread_sigmask.3 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
PTHREAD_SIGMASK(3)Library Functions ManualPTHREAD_SIGMASK(3)
-
-
-

-

pthread_sigmask — - examine and/or change a thread's signal mask

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h> -
- #include <signal.h>

-

int -
- pthread_sigmask(int - how, const sigset_t * - restrict set, sigset_t * - restrict oset);

-
-
-

-

The - () - function examines and/or changes the calling thread's signal mask.

-

If set is not NULL, - it specifies a set of signals to be modified, and how - specifies what to set the signal mask to:

-
-
-
Union of the current mask and set.
-
-
Intersection of the current mask and the complement of - set.
-
-
set.
-
-

If oset is not NULL, the previous signal - mask is stored in the location pointed to by oset.

-

SIGKILL and - SIGSTOP cannot be blocked, and will be silently - ignored if included in the signal mask.

-
-
-

-

If successful, pthread_sigmask() returns - 0. Otherwise, an error is returned.

-
-
-

-

The pthread_sigmask() function will fail - if:

-
-
[]
-
how is not one of the defined values.
-
-
-
-

-

sigaction(2), sigpending(2), - sigprocmask(2), sigsuspend(2), - sigsetops(3)

-
-
-

-

The pthread_sigmask() function conforms to - ISO/IEC 9945-1:1996 (“POSIX.1”)

-
-
- - - - - -
February 19, 2011FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_signals_block_np.3 3.html b/static/freebsd/man3/pthread_signals_block_np.3 3.html deleted file mode 100644 index 04d9dc4d..00000000 --- a/static/freebsd/man3/pthread_signals_block_np.3 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
PTHREAD_SIGNALS_BLOCK_NP(3)Library Functions ManualPTHREAD_SIGNALS_BLOCK_NP(3)
-
-
-

-

pthread_signals_block_np, - pthread_signals_unblock_np — - fast asynchronous signals blocking and - unblocking

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

void -
- pthread_signals_block_np(void);

-

void -
- pthread_signals_unblock_np(void);

-
-
-

-

The - () - and - () - functions provide user programs an interface to the fast asynchronous - signals blocking facility sigfastblock(2).

-

Blocking signals with - () - disables delivery of any asynchronous signal, until unblocked. Signal - blocking establishes a critical section where the execution flow of the - thread cannot be diverted into a signal handler. Blocking signals is fast, - it is performed by a single memory write into a location established with - the kernel.

-

Synchronous signal delivery cannot be blocked in general, - including with these functions.

-

The blocked state established by - the - () - is not completely POSIX-compliant. Specifically, system calls executed while - in a blocked section, might abort sleep and return - EINTR upon queuing of an asynchronous signal to the - thread, but the signal handler is not called until the last unblock is - done.

-

Calls to pthread_signals_block_np can be - nested, and must be complemented by an equal count of calls to - pthread_signals_unblock_np to return the calling - thread to the standard mode of signal receiving.

-

An example use of these function might be the - construction of the CPU state that cannot be done atomically, and which - includes stages where the state of the thread is not ABI compliant. If a - signal is delivered while such state is not yet finished, signal handlers - would misbehave. Using standard functions - (()) - to establish critical section might be much slower, because - sigprocmask() is system call, while - pthread_signals_block_np() consists of a single - atomic memory write.

-
-
-

-

The functions do not return a value.

-
-
-

-

There are no errors reported by the functions.

-
-
-

-

sigfastblock(2), - sigprocmask(2), pthread_sigmask(3), - pthread_np(3)

-
-
- - - - - -
May 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_sigqueue.3 3.html b/static/freebsd/man3/pthread_sigqueue.3 3.html deleted file mode 100644 index b56d92a2..00000000 --- a/static/freebsd/man3/pthread_sigqueue.3 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
PTHREAD_SIGQUEUE(3)Library Functions ManualPTHREAD_SIGQUEUE(3)
-
-
-

-

pthread_sigqueue — - queue a signal to a specified thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h> -
- #include <signal.h>

-

int -
- pthread_sigqueue(pthread_t - thread, int sig, - const union sigval - value);

-
-
-

-

The - () - function queues a signal, specified by sig, to a - thread, specified by thread. If - sig is 0, error checking is performed, but no signal - is actually sent. The value is queued together with - the signal, and becomes available in siginfo_t data - passed to the signal handler.

-

The pthread_sigqueue function is similar - to sigqueue(2), but targets a thread in the current - process instead of a process. See sigqueue(2) for details - about signal queueing and delivery selection.

-
-
-

-

If successful, pthread_sigqueue() returns - 0. Otherwise, an error number is returned.

-
-
-

-

The pthread_sigqueue() function will fail - if:

-
-
[]
-
No resources are available to queue the signal. The current process has - already queued {SIGQUEUE_MAX} signals that are - still pending, or a system-wide resource limit has been exceeded.
-
[]
-
thread is an invalid thread ID.
-
[]
-
sig is an invalid or unsupported signal number.
-
-
-
-

-

sigqueue(2)

-
-
-

-

The pthread_sigqueue() function is a - FreeBSD extension. An identical function with the - same semantic is available in other operating systems.

-
-
- - - - - -
April 21, 2024FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_spin_init.3 3.html b/static/freebsd/man3/pthread_spin_init.3 3.html deleted file mode 100644 index 53d4f70e..00000000 --- a/static/freebsd/man3/pthread_spin_init.3 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
PTHREAD_SPIN_INIT(3)Library Functions ManualPTHREAD_SPIN_INIT(3)
-
-
-

-

pthread_spin_init, - pthread_spin_destroy — - initialize or destroy a spin lock

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_spin_init(pthread_spinlock_t - *lock, int - pshared);

-

int -
- pthread_spin_destroy(pthread_spinlock_t - *lock);

-
-
-

-

The - () - function will initialize lock to an unlocked state and - allocate any resources necessary to begin using it. If - pshared is set to - PTHREAD_PROCESS_SHARED, any thread, whether - belonging to the process in which the spinlock was created or not, that has - access to the memory area where lock resides, can use - lock. If it is set to - PTHREAD_PROCESS_PRIVATE, it can only be used by - threads within the same process.

-

The - () - function will destroy lock and release any resources - that may have been allocated on its behalf.

-
-
-

-

If successful, both pthread_spin_init() - and pthread_spin_destroy() will return zero. - Otherwise, an error number will be returned to indicate the error.

-

Neither of these functions will return - EINTR.

-
-
-

-

The pthread_spin_init() and - pthread_spin_destroy() functions will fail if:

-
-
[]
-
An attempt to initialize or destroy lock while it is - in use.
-
[]
-
The value specified by lock is invalid.
-
-

The pthread_spin_init() function will fail - if:

-
-
[]
-
Insufficient resources, other than memory, to initialize - lock.
-
[]
-
Insufficient memory to initialize lock.
-
-
-
-

-

pthread_spin_lock(3), - pthread_spin_unlock(3)

-
-
-

-

The pthread_spin_init() and - pthread_spin_destroy() functions first appeared in - N:M Threading Library (libkse, -lkse) in - FreeBSD 5.2, and in 1:1 Threading - Library (libthr, -lthr) in FreeBSD 5.3. - Support for process-shared spinlocks appeared in FreeBSD - 11.0.

-
-
- - - - - -
May 31, 2016FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_spin_lock.3 3.html b/static/freebsd/man3/pthread_spin_lock.3 3.html deleted file mode 100644 index 1babc686..00000000 --- a/static/freebsd/man3/pthread_spin_lock.3 3.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - -
PTHREAD_SPIN_LOCK(3)Library Functions ManualPTHREAD_SPIN_LOCK(3)
-
-
-

-

pthread_spin_lock, - pthread_spin_trylock, - pthread_spin_unlock — lock - or unlock a spin lock

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_spin_lock(pthread_spinlock_t - *lock);

-

int -
- pthread_spin_trylock(pthread_spinlock_t - *lock);

-

int -
- pthread_spin_unlock(pthread_spinlock_t - *lock);

-
-
-

-

The - () - function will acquire lock if it is not currently - owned by another thread. If the lock cannot be acquired immediately, it will - spin attempting to acquire the lock (it will not sleep) until it becomes - available.

-

The - () - function is the same as pthread_spin_lock() except - that if it cannot acquire lock immediately it will - return with an error.

-

The - () - function will release lock, which must have been - previously locked by a call to pthread_spin_lock() - or pthread_spin_trylock().

-
-
-

-

If successful, all these functions will return zero. Otherwise, an - error number will be returned to indicate the error.

-

None of these functions will return - EINTR.

-
-
-

-

The pthread_spin_lock(), - pthread_spin_trylock() and - pthread_spin_unlock() functions will fail if:

-
-
[]
-
The value specified by lock is invalid or is not - initialized.
-
-

The pthread_spin_lock() function may fail - if:

-
-
[]
-
The calling thread already owns the lock.
-
-

The pthread_spin_trylock() function will - fail if:

-
-
[]
-
Another thread currently holds lock.
-
-

The pthread_spin_unlock() function may - fail if:

-
-
[]
-
The calling thread does not own lock.
-
-
-
-

-

pthread_spin_destroy(3), - pthread_spin_init(3)

-
-
-

-

The pthread_spin_lock(), - pthread_spin_trylock() and - pthread_spin_unlock() functions first appeared in - N:M Threading Library (libkse, -lkse) in - FreeBSD 5.2, and in 1:1 Threading - Library (libthr, -lthr) in FreeBSD 5.3.

-
-
-

-

The implementation of pthread_spin_lock(), - pthread_spin_trylock() and - pthread_spin_unlock() is expected to conform to - IEEE Std 1003.2 (“POSIX.2”).

-
-
- - - - - -
January 22, 2004FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_suspend_all_np.3 4.html b/static/freebsd/man3/pthread_suspend_all_np.3 4.html deleted file mode 100644 index ae0af02c..00000000 --- a/static/freebsd/man3/pthread_suspend_all_np.3 4.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - -
PTHREAD_SUSPEND_ALL_NP(3)Library Functions ManualPTHREAD_SUSPEND_ALL_NP(3)
-
-
-

-

pthread_suspend_all_np — - suspend all active threads

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

void -
- pthread_suspend_all_np(void);

-
-
-

-

The - () - function causes all active threads to be suspended. The only exception is - the current thread, the thread that called the - pthread_suspend_all_np() function.

-

It is not safe for the caller of the - () - function to use any non-async signal safe functions, besides - pthread_resume_all_np(3), until threads are resumed, - unless measures are taken to ensure that all threads are suspended at safe - points.

-
-
-

-

pthread_np(3), - pthread_resume_all_np(3), - pthread_resume_np(3), - pthread_suspend_np(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_suspend_np.3 3.html b/static/freebsd/man3/pthread_suspend_np.3 3.html deleted file mode 100644 index c9949026..00000000 --- a/static/freebsd/man3/pthread_suspend_np.3 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
PTHREAD_SUSPEND_NP(3)Library Functions ManualPTHREAD_SUSPEND_NP(3)
-
-
-

-

pthread_suspend_np — - suspend a thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread_np.h>

-

int -
- pthread_suspend_np(pthread_t - tid);

-
-
-

-

The - () - function, called on an active thread, causes it to suspend.

-

It is not safe for the caller of the - () - function to use any non-async signal safe functions, except - pthread_resume_np(3), until suspended thread is resumed, - unless measures are taken to ensure that the thread is suspended at a safe - point.

-
-
-

-

If successful, pthread_suspend_np() - function returns 0. Otherwise, an error number is returned to indicate the - error.

-
-
-

-

The pthread_suspend_np() function will - fail if:

-
-
[]
-
An attempt was made to suspend the current thread.
-
[]
-
The value specified by the tid argument is - invalid.
-
[]
-
No thread could be found corresponding to the thread ID specified by the - tid argument.
-
-
-
-

-

pthread_np(3), - pthread_resume_all_np(3), - pthread_resume_np(3), - pthread_suspend_all_np(3)

-
-
-

-

This manual page was written by Alexey - Zelkin - <phantom@FreeBSD.org>.

-
-
- - - - - -
October 12, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_testcancel.3 3.html b/static/freebsd/man3/pthread_testcancel.3 3.html deleted file mode 100644 index 27a2a47d..00000000 --- a/static/freebsd/man3/pthread_testcancel.3 3.html +++ /dev/null @@ -1,302 +0,0 @@ - - - - - - -
PTHREAD_TESTCANCEL(3)Library Functions ManualPTHREAD_TESTCANCEL(3)
-
-
-

-

pthread_setcancelstate, - pthread_setcanceltype, - pthread_testcancel — set - cancelability state

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

int -
- pthread_setcancelstate(int - state, int - *oldstate);

-

int -
- pthread_setcanceltype(int - type, int - *oldtype);

-

void -
- pthread_testcancel(void);

-
-
-

-

The - () - function atomically both sets the calling thread's cancelability state to - the indicated state and, if - oldstate is not NULL, returns - the previous cancelability state at the location referenced by - oldstate. Legal values for state - are PTHREAD_CANCEL_ENABLE and - PTHREAD_CANCEL_DISABLE. The function is - async-signal-safe.

-

The - () - function atomically both sets the calling thread's cancelability type to the - indicated type and, if oldtype - is not NULL, returns the previous cancelability type - at the location referenced by oldtype. Legal values - for type are - PTHREAD_CANCEL_DEFERRED and - PTHREAD_CANCEL_ASYNCHRONOUS.

-

The cancelability state and type of any newly created - threads, including the thread in which - () was - first invoked, are PTHREAD_CANCEL_ENABLE and - PTHREAD_CANCEL_DEFERRED respectively.

-

The - () - function creates a cancellation point in the calling thread. The - pthread_testcancel() function has no effect if - cancelability is disabled.

-
-

-

The cancelability state of a thread determines the action taken - upon receipt of a cancellation request. The thread may control cancellation - in a number of ways.

-

Each thread maintains its own “cancelability state” - which may be encoded in two bits:

-
-
-
When cancelability is PTHREAD_CANCEL_DISABLE, - cancellation requests against the target thread are held pending.
-
-
When cancelability is enabled and the cancelability type is - PTHREAD_CANCEL_ASYNCHRONOUS, new or pending - cancellation requests may be acted upon at any time. When cancelability is - enabled and the cancelability type is - PTHREAD_CANCEL_DEFERRED, cancellation requests are - held pending until a cancellation point (see below) is reached. If - cancelability is disabled, the setting of the cancelability type has no - immediate effect as all cancellation requests are held pending; however, - once cancelability is enabled again the new type will be in effect.
-
-
-
-

-

Cancellation points will occur when a thread is executing the - following functions:

-
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
The fcntl() function is a cancellation point if - cmd is F_SETLKW.
-
()
-
 
-
()
-
 
-
()
-
The kevent() function is a cancellation point if - it is potentially blocking, such as when the nevents - argument is non-zero.
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
pthread_testcancel()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
()
-
 
-
-
-
-
-

-

The pthread_setcancelstate() and - pthread_setcanceltype() functions are used to - control the points at which a thread may be asynchronously canceled. For - cancellation control to be usable in modular fashion, some rules must be - followed.

-

For purposes of this discussion, consider an object to be a - generalization of a procedure. It is a set of procedures and global - variables written as a unit and called by clients not known by the object. - Objects may depend on other objects.

-

First, cancelability should only be disabled on entry to an - object, never explicitly enabled. On exit from an object, the cancelability - state should always be restored to its value on entry to the object.

-

This follows from a modularity argument: if the client of an - object (or the client of an object that uses that object) has disabled - cancelability, it is because the client does not want to have to worry about - how to clean up if the thread is canceled while executing some sequence of - actions. If an object is called in such a state and it enables cancelability - and a cancellation request is pending for that thread, then the thread will - be canceled, contrary to the wish of the client that disabled.

-

Second, the cancelability type may be explicitly set - to either - or - - upon entry to an object. But as with the cancelability state, on exit from - an object that cancelability type should always be restored to its value on - entry to the object.

-

Finally, only functions that are cancel-safe may be called from a - thread that is asynchronously cancelable.

-
-
-

-

If successful, the - pthread_setcancelstate() and - pthread_setcanceltype() functions will return zero. - Otherwise, an error number shall be returned to indicate the error.

-
-
-

-

The function pthread_setcancelstate() may - fail with:

-
-
[]
-
The specified state is not PTHREAD_CANCEL_ENABLE - or PTHREAD_CANCEL_DISABLE.
-
-

The function pthread_setcanceltype() may - fail with:

-
-
[]
-
The specified state is not PTHREAD_CANCEL_DEFERRED - or PTHREAD_CANCEL_ASYNCHRONOUS.
-
-
-
-

-

pthread_cancel(3)

-
-
-

-

The pthread_testcancel() function conforms - to ISO/IEC 9945-1:1996 (“POSIX.1”). - The standard allows implementations to make many more functions cancellation - points.

-

The pthread_setcancelstate() function is - async-signal-safe as required by.

-
-
-

-

This manual page was written by David - Leonard - <d@openbsd.org> for the - OpenBSD implementation of - pthread_cancel(3).

-
-
- - - - - -
March 18, 2017FreeBSD 15.0
diff --git a/static/freebsd/man3/pthread_yield.3 4.html b/static/freebsd/man3/pthread_yield.3 4.html deleted file mode 100644 index 0c922c5c..00000000 --- a/static/freebsd/man3/pthread_yield.3 4.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
PTHREAD_YIELD(3)Library Functions ManualPTHREAD_YIELD(3)
-
-
-

-

pthread_yield — - yield control of the current thread

-
-
-

-

POSIX Threads Library (libpthread, - -lpthread)

-
-
-

-

#include - <pthread.h>

-

void -
- pthread_yield(void);

-
-
-

-

The - () - forces the running thread to relinquish the processor until it again becomes - the head of its thread list.

-
-
-

-

sched_yield(2)

-
-
-

-

The pthread_yield() is a non-portable (but - quite common) extension to IEEE Std 1003.1-2001 - (“POSIX.1”).

-
-
- - - - - -
September 18, 2006FreeBSD 15.0
diff --git a/static/freebsd/man3/qmath.3 3.html b/static/freebsd/man3/qmath.3 3.html deleted file mode 100644 index d5f66a94..00000000 --- a/static/freebsd/man3/qmath.3 3.html +++ /dev/null @@ -1,606 +0,0 @@ - - - - - - -
QMATH(3)Library Functions ManualQMATH(3)
-
-
-

-

qmath — - fixed-point math library based on the “Q” - number format

-
-
-

-

#include - <sys/qmath.h>

-
-
-

-

The qmath data types and APIs support - fixed-point math based on the “Q” number format. The APIs have - been built around the following data types: s8q_t, - u8q_t, s16q_t, - u16q_t, s32q_t, - u32q_t, s64q_t, and - u64q_t, which are referred to generically in the - earlier API definitions as QTYPE. The - ITYPE refers to the stdint(7) - integer types. NTYPE is used to refer to any numeric - type and is therefore a superset of QTYPE and - ITYPE.

-

This scheme can represent Q numbers with [2, 4, 6, 8, - 16, 32, 48] bits of precision after the binary radix point, depending on the - rpshft argument to - (). The - number of bits available for the integral component is not explicitly - specified, and implicitly consumes the remaining available bits of the - chosen Q data type.

-

Operations on Q numbers maintain the precision of their arguments. - The fractional component is truncated to fit into the destination, with no - rounding. None of the operations is affected by the floating-point - environment.

-

For more details, see the - IMPLEMENTATION DETAILS - below.

-
-
-

-
-

- - - - - - - - - -
Description
Q_INI(3)initialise a Q number
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_QADDQ(3)addition
Q_QDIVQ(3)division
Q_QMULQ(3)multiplication
Q_QSUBQ(3)subtraction
Q_NORMPREC(3)normalisation
Q_QMAXQ(3)maximum function
Q_QMINQ(3)minimum function
Q_QCLONEQ(3)identical copy
Q_QCPYVALQ(3)representational copy
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_QADDI(3)addition
Q_QDIVI(3)division
Q_QMULI(3)multiplication
Q_QSUBI(3)subtraction
Q_QFRACI(3)fraction
Q_QCPYVALI(3)overwrite
-
-
-

- - - - - - - - - - - - - - - - - -
Description
Q_QABS(3)absolute value
Q_Q2D(3)double representation
Q_Q2F(3)float representation
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_SIGNED(3)determine sign
Q_LTZ(3)less than zero
Q_PRECEQ(3)compare bits
Q_QLTQ(3)less than
Q_QLEQ(3)less or equal
Q_QGTQ(3)greater than
Q_QGEQ(3)greater or equal
Q_QEQ(3)equal
Q_QNEQ(3)not equal
Q_OFLOW(3)would overflow
Q_RELPREC(3)relative precision
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_SIGNSHFT(3)sign bit position
Q_SSIGN(3)sign bit
Q_CRAWMASK(3)control bitmask
Q_SRAWMASK(3)sign bitmask
Q_GCRAW(3)raw control bits
Q_GCVAL(3)value of control bits
Q_SCVAL(3)set control bits
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_IFRAWMASK(3)integer/fractional bitmask
Q_IFVALIMASK(3)value of integer bits
Q_IFVALFMASK(3)value of fractional bits
Q_GIFRAW(3)raw integer/fractional bits
Q_GIFABSVAL(3)absolute value of fractional bits
Q_GIFVAL(3)real value of fractional bits
Q_SIFVAL(3)set integer/fractional bits
Q_SIFVALS(3)set separate integer/fractional values
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_IRAWMASK(3)integer bitmask
Q_GIRAW(3)raw integer bits
Q_GIABSVAL(3)absolute value of integer bits
Q_GIVAL(3)real value of integer bits
Q_SIVAL(3)set integer bits
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_FRAWMASK(3)fractional bitmask
Q_GFRAW(3)raw fractional bits
Q_GFABSVAL(3)absolute value of fractional bits
Q_GFVAL(3)real value of fractional bits
Q_SFVAL(3)set fractional bits
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description
Q_NCBITS(3)number of reserved control bits
Q_BT(3)C data type
Q_TC(3)casted data type
Q_NTBITS(3)number of total bits
Q_NFCBITS(3)number of control-encoded fractional bits
Q_MAXNFBITS(3)number of maximum fractional bits
Q_NFBITS(3)number of effective fractional bits
Q_NIBITS(3)number of integer bits
Q_RPSHFT(3)bit position of radix point
Q_ABS(3)absolute value
Q_MAXSTRLEN(3)number of characters to render string
Q_TOSTR(3)render string
Q_SHL(3)left-shifted value
Q_SHR(3)right-shifted value
Q_DEBUG(3)render debugging information
Q_DFV2BFV(3)convert decimal fractional value
-
-
-
-

-

The qmath data types and APIs support - fixed-point math based on the “Q” number format. This - implementation uses the Q notation - , - where - specifies the number of bits for integral data (excluding the sign bit for - signed types), and - specifies the - number of bits for fractional data.

-

The APIs have been built around the following q_t derived data - types:

-
-
typedef int8_t		s8q_t;
-typedef uint8_t		u8q_t;
-typedef int16_t		s16q_t;
-typedef uint16_t	u16q_t;
-typedef int32_t		s32q_t;
-typedef uint32_t	u32q_t;
-typedef int64_t		s64q_t;
-typedef uint64_t	u64q_t;
-
-

These types are referred to generically in the earlier API - definitions as QTYPE, while - ITYPE refers to the stdint(7) - integer types the Q data types are derived from. NTYPE - is used to refer to any numeric type and is therefore a superset of - QTYPE and ITYPE.

-

The 3 least significant bits (LSBs) of all q_t data types are - reserved for embedded control data:

-
    -
  • bits 1-2 specify the binary radix point shift index operand, with - 00,01,10,11 == 1,2,3,4.
    • -
  • bit 3 specifies the radix point shift index operand multiplier as 2 (0) or - 16 (1).
    • -
-

This scheme can therefore represent Q numbers with - [2,4,6,8,16,32,48,64] bits of precision after the binary radix point. The - number of bits available for the integral component is not explicitly - specified, and implicitly consumes the remaining available bits of the - chosen Q data type.

-

Additionally, the most significant bit (MSB) of signed Q types - stores the sign bit, with bit value 0 representing a positive number and bit - value 1 representing a negative number. Negative numbers are stored as - absolute values with the sign bit set, rather than the more typical two's - complement representation. This avoids having to bit shift negative numbers, - which can result in undefined behaviour from some compilers.

-

This binary representation used for Q numbers therefore comprises - a set of distinct data bit types and associated bit counts. Data bit - types/labels, listed in LSB to MSB order, are: control ‘C’, - fractional ‘F’, integer ‘I’ and sign - ‘S’. The following example illustrates the binary - representation of a Q20.8 number represented using a s32q_t variable:

-
-
M                                                             L
-S                                                             S
-B                                                             B
-
-3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
-1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
-
-S I I I I I I I I I I I I I I I I I I I I F F F F F F F F C C C
-
-

Important bit counts are: total, control, control-encoded - fractional, maximum fractional, effective fractional and integer bits.

-

The count of total bits is derived from the size of the q_t data - type. For example, a s32q_t has 32 total bits.

-

The count of control-encoded fractional bits is derived from - calculating the number of fractional bits per the control bit encoding - scheme. For example, the control bits binary value of 101 encodes a - fractional bit count of 2 x 16 = 32 fractional bits.

-

The count of maximum fractional bits is derived from the - difference between the counts of total bits and control/sign bits. For - example, a s32q_t has a maximum of 32 - 3 - 1 = 28 fractional bits.

-

The count of effective fractional bits is derived from the minimum - of the control-encoded fractional bits and the maximum fractional bits. For - example, a s32q_t with 32 control-encoded fractional bits is effectively - limited to 28 fractional bits.

-

The count of integer bits is derived from the difference between - the counts of total bits and all other non-integer data bits (the sum of - control, fractional and sign bits.) For example, a s32q_t with 8 effective - fractional bits has 32 - 3 - 8 - 1 = 20 integer bits. The count of integer - bits can be zero if all available numeric data bits have been reserved for - fractional data, e.g., when the number of control-encoded fractional bits is - greater than or equal to the underlying Q data type's maximum fractional - bits.

-
-
-

-
-

-
-
u64q_t a, pi, r;
-char buf[32]
-
-Q_INI(&a, 0, 0, 16);
-Q_INI(&pi, 3, 14159, 16);
-Q_INI(&r, 4, 2, 16);
-
-Q_QCLONEQ(&a, r);
-Q_QMULQ(&a, r);
-Q_QMULQ(&a, pi);
-
-Q_TOSTR(a, -1, 10, buf, sizeof(buf));
-printf("%s\n", buf);
-
-
-
-

-

Declare a Q20.8 s32q_t number s32, - initialise it with the fixed-point value for 5/3, and render a debugging - representation of the variable (including its full precision decimal - C-string representation), to the console:

-
-
s32q_t s32;
-Q_INI(&s32, 0, 0, 8);
-Q_QFRACI(&s32, 5, 3);
-char buf[Q_MAXSTRLEN(s32, 10)];
-Q_TOSTR(s32, -1, 10, buf, sizeof(buf));
-printf(Q_DEBUG(s32, "", "\n\ttostr=%s\n\n", 0), buf);
-
-

The above code outputs the following to the console:

-
-
"s32"@0x7fffffffe7d4
-	type=s32q_t, Qm.n=Q20.8, rpshft=11, imin=0xfff00001, \
-imax=0xfffff
-	qraw=0x00000d53
-	imask=0x7ffff800, fmask=0x000007f8, cmask=0x00000007, \
-ifmask=0x7ffffff8
-	iraw=0x00000800, iabsval=0x1, ival=0x1
-	fraw=0x00000550, fabsval=0xaa, fval=0xaa
-	tostr=1.664
-
-

Note: The "\" present in the rendered output above - indicates a manual line break inserted to keep the man page within 80 - columns and is not part of the actual output.

-
-
-
-

-

errno(2), math(3), - Q_FRAWMASK(3), Q_IFRAWMASK(3), - Q_INI(3), Q_IRAWMASK(3), - Q_QABS(3), Q_QADDI(3), - Q_QADDQ(3), Q_SIGNED(3), - Q_SIGNSHFT(3), stdint(7)

-
-
-

-

The qmath functions first appeared in - FreeBSD 13.0.

-
-
-

-

The qmath functions and this manual page - were written by Lawrence Stewart - <lstewart@FreeBSD.org> - and sponsored by Netflix, Inc.

-
-
- - - - - -
July 4, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/queue.3 3.html b/static/freebsd/man3/queue.3 3.html deleted file mode 100644 index d35abcb8..00000000 --- a/static/freebsd/man3/queue.3 3.html +++ /dev/null @@ -1,1187 +0,0 @@ - - - - - - -
QUEUE(3)Library Functions ManualQUEUE(3)
-
-
-

-

SLIST_CLASS_ENTRY, - SLIST_CLASS_HEAD, - SLIST_CONCAT, SLIST_EMPTY, - SLIST_EMPTY_ATOMIC, - SLIST_ENTRY, SLIST_FIRST, - SLIST_FOREACH, - SLIST_FOREACH_FROM, - SLIST_FOREACH_FROM_SAFE, - SLIST_FOREACH_SAFE, - SLIST_HEAD, - SLIST_HEAD_INITIALIZER, - SLIST_INIT, - SLIST_INSERT_AFTER, - SLIST_INSERT_HEAD, - SLIST_NEXT, SLIST_REMOVE, - SLIST_REMOVE_AFTER, - SLIST_REMOVE_HEAD, - SLIST_SPLIT_AFTER, - SLIST_SWAP, - STAILQ_CLASS_ENTRY, - STAILQ_CLASS_HEAD, - STAILQ_CONCAT, STAILQ_EMPTY, - STAILQ_EMPTY_ATOMIC, - STAILQ_ENTRY, STAILQ_FIRST, - STAILQ_FOREACH, - STAILQ_FOREACH_FROM, - STAILQ_FOREACH_FROM_SAFE, - STAILQ_FOREACH_SAFE, - STAILQ_HEAD, - STAILQ_HEAD_INITIALIZER, - STAILQ_INIT, - STAILQ_INSERT_AFTER, - STAILQ_INSERT_HEAD, - STAILQ_INSERT_TAIL, - STAILQ_LAST, STAILQ_NEXT, - STAILQ_REMOVE, - STAILQ_REMOVE_AFTER, - STAILQ_REMOVE_HEAD, - STAILQ_REVERSE, - STAILQ_SPLIT_AFTER, - STAILQ_SWAP, - LIST_CLASS_ENTRY, - LIST_CLASS_HEAD, - LIST_CONCAT, LIST_EMPTY, - LIST_EMPTY_ATOMIC, - LIST_ENTRY, LIST_FIRST, - LIST_FOREACH, - LIST_FOREACH_FROM, - LIST_FOREACH_FROM_SAFE, - LIST_FOREACH_SAFE, - LIST_HEAD, - LIST_HEAD_INITIALIZER, - LIST_INIT, - LIST_INSERT_AFTER, - LIST_INSERT_BEFORE, - LIST_INSERT_HEAD, LIST_NEXT, - LIST_PREV, LIST_REMOVE, - LIST_REPLACE, - LIST_SPLIT_AFTER, LIST_SWAP, - TAILQ_CLASS_ENTRY, - TAILQ_CLASS_HEAD, - TAILQ_CONCAT, TAILQ_EMPTY, - TAILQ_EMPTY_ATOMIC, - TAILQ_ENTRY, TAILQ_FIRST, - TAILQ_FOREACH, - TAILQ_FOREACH_FROM, - TAILQ_FOREACH_FROM_SAFE, - TAILQ_FOREACH_REVERSE, - TAILQ_FOREACH_REVERSE_FROM, - TAILQ_FOREACH_REVERSE_FROM_SAFE, - TAILQ_FOREACH_REVERSE_SAFE, - TAILQ_FOREACH_SAFE, - TAILQ_HEAD, - TAILQ_HEAD_INITIALIZER, - TAILQ_INIT, - TAILQ_INSERT_AFTER, - TAILQ_INSERT_BEFORE, - TAILQ_INSERT_HEAD, - TAILQ_INSERT_TAIL, - TAILQ_LAST, TAILQ_NEXT, - TAILQ_PREV, TAILQ_REMOVE, - TAILQ_REPLACE, - TAILQ_SPLIT_AFTER, - TAILQ_SWAP — implementations - of singly-linked lists, singly-linked tail queues, lists and tail - queues

-
-
-

-

#include - <sys/queue.h>

-

SLIST_CLASS_ENTRY(CLASSTYPE);

-

SLIST_CLASS_HEAD(HEADNAME, - CLASSTYPE);

-

SLIST_CONCAT(SLIST_HEAD - *head1, SLIST_HEAD - *head2, TYPE, - SLIST_ENTRY NAME);

-

SLIST_EMPTY(SLIST_HEAD - *head);

-

SLIST_EMPTY_ATOMIC(SLIST_HEAD - *head);

-

SLIST_ENTRY(TYPE);

-

SLIST_FIRST(SLIST_HEAD - *head);

-

SLIST_FOREACH(TYPE - *var, SLIST_HEAD - *head, SLIST_ENTRY - NAME);

-

SLIST_FOREACH_FROM(TYPE - *var, SLIST_HEAD - *head, SLIST_ENTRY - NAME);

-

SLIST_FOREACH_FROM_SAFE(TYPE - *var, SLIST_HEAD - *head, SLIST_ENTRY - NAME, TYPE - *temp_var);

-

SLIST_FOREACH_SAFE(TYPE - *var, SLIST_HEAD - *head, SLIST_ENTRY - NAME, TYPE - *temp_var);

-

SLIST_HEAD(HEADNAME, - TYPE);

-

SLIST_HEAD_INITIALIZER(SLIST_HEAD - head);

-

SLIST_INIT(SLIST_HEAD - *head);

-

SLIST_INSERT_AFTER(TYPE - *listelm, TYPE - *elm, SLIST_ENTRY - NAME);

-

SLIST_INSERT_HEAD(SLIST_HEAD - *head, TYPE *elm, - SLIST_ENTRY NAME);

-

SLIST_NEXT(TYPE - *elm, SLIST_ENTRY - NAME);

-

SLIST_REMOVE(SLIST_HEAD - *head, TYPE *elm, - TYPE, - SLIST_ENTRY NAME);

-

SLIST_REMOVE_AFTER(TYPE - *elm, SLIST_ENTRY - NAME);

-

SLIST_REMOVE_HEAD(SLIST_HEAD - *head, SLIST_ENTRY - NAME);

-

SLIST_SPLIT_AFTER(SLIST_HEAD - *head, TYPE *elm, - SLIST_HEAD *rest, - SLIST_ENTRY NAME);

-

SLIST_SWAP(SLIST_HEAD - *head1, SLIST_HEAD - *head2, TYPE);

-

STAILQ_CLASS_ENTRY(CLASSTYPE);

-

STAILQ_CLASS_HEAD(HEADNAME, - CLASSTYPE);

-

STAILQ_CONCAT(STAILQ_HEAD - *head1, STAILQ_HEAD - *head2);

-

STAILQ_EMPTY(STAILQ_HEAD - *head);

-

STAILQ_EMPTY_ATOMIC(STAILQ_HEAD - *head);

-

STAILQ_ENTRY(TYPE);

-

STAILQ_FIRST(STAILQ_HEAD - *head);

-

STAILQ_FOREACH(TYPE - *var, STAILQ_HEAD - *head, STAILQ_ENTRY - NAME);

-

STAILQ_FOREACH_FROM(TYPE - *var, STAILQ_HEAD - *head, STAILQ_ENTRY - NAME);

-

STAILQ_FOREACH_FROM_SAFE(TYPE - *var, STAILQ_HEAD - *head, STAILQ_ENTRY - NAME, TYPE - *temp_var);

-

STAILQ_FOREACH_SAFE(TYPE - *var, STAILQ_HEAD - *head, STAILQ_ENTRY - NAME, TYPE - *temp_var);

-

STAILQ_HEAD(HEADNAME, - TYPE);

-

STAILQ_HEAD_INITIALIZER(STAILQ_HEAD - head);

-

STAILQ_INIT(STAILQ_HEAD - *head);

-

STAILQ_INSERT_AFTER(STAILQ_HEAD - *head, TYPE - *listelm, TYPE - *elm, STAILQ_ENTRY - NAME);

-

STAILQ_INSERT_HEAD(STAILQ_HEAD - *head, TYPE *elm, - STAILQ_ENTRY NAME);

-

STAILQ_INSERT_TAIL(STAILQ_HEAD - *head, TYPE *elm, - STAILQ_ENTRY NAME);

-

STAILQ_LAST(STAILQ_HEAD - *head, TYPE *elm, - STAILQ_ENTRY NAME);

-

STAILQ_NEXT(TYPE - *elm, STAILQ_ENTRY - NAME);

-

STAILQ_REMOVE(STAILQ_HEAD - *head, TYPE *elm, - TYPE, - STAILQ_ENTRY NAME);

-

STAILQ_REMOVE_AFTER(STAILQ_HEAD - *head, TYPE *elm, - STAILQ_ENTRY NAME);

-

STAILQ_REMOVE_HEAD(STAILQ_HEAD - *head, STAILQ_ENTRY - NAME);

-

STAILQ_REVERSE(STAILQ_HEAD - *head, TYPE, - STAILQ_ENTRY NAME);

-

STAILQ_SPLIT_AFTER(STAILQ_HEAD - *head, TYPE *elm, - STAILQ_HEAD *rest, - STAILQ_ENTRY NAME);

-

STAILQ_SWAP(STAILQ_HEAD - *head1, STAILQ_HEAD - *head2, TYPE);

-

LIST_CLASS_ENTRY(CLASSTYPE);

-

LIST_CLASS_HEAD(HEADNAME, - CLASSTYPE);

-

LIST_CONCAT(LIST_HEAD - *head1, LIST_HEAD - *head2, TYPE, - LIST_ENTRY NAME);

-

LIST_EMPTY(LIST_HEAD - *head);

-

LIST_EMPTY_ATOMIC(LIST_HEAD - *head);

-

LIST_ENTRY(TYPE);

-

LIST_FIRST(LIST_HEAD - *head);

-

LIST_FOREACH(TYPE - *var, LIST_HEAD - *head, LIST_ENTRY - NAME);

-

LIST_FOREACH_FROM(TYPE - *var, LIST_HEAD - *head, LIST_ENTRY - NAME);

-

LIST_FOREACH_FROM_SAFE(TYPE - *var, LIST_HEAD - *head, LIST_ENTRY - NAME, TYPE - *temp_var);

-

LIST_FOREACH_SAFE(TYPE - *var, LIST_HEAD - *head, LIST_ENTRY - NAME, TYPE - *temp_var);

-

LIST_HEAD(HEADNAME, - TYPE);

-

LIST_HEAD_INITIALIZER(LIST_HEAD - head);

-

LIST_INIT(LIST_HEAD - *head);

-

LIST_INSERT_AFTER(TYPE - *listelm, TYPE - *elm, LIST_ENTRY - NAME);

-

LIST_INSERT_BEFORE(TYPE - *listelm, TYPE - *elm, LIST_ENTRY - NAME);

-

LIST_INSERT_HEAD(LIST_HEAD - *head, TYPE *elm, - LIST_ENTRY NAME);

-

LIST_NEXT(TYPE - *elm, LIST_ENTRY - NAME);

-

LIST_PREV(TYPE - *elm, LIST_HEAD - *head, TYPE, - LIST_ENTRY NAME);

-

LIST_REMOVE(TYPE - *elm, LIST_ENTRY - NAME);

-

LIST_REPLACE(TYPE - *elm, TYPE *new, - LIST_ENTRY NAME);

-

LIST_SPLIT_AFTER(LIST_HEAD - *head, TYPE *elm, - LIST_HEAD *rest, - LIST_ENTRY NAME);

-

LIST_SWAP(LIST_HEAD - *head1, LIST_HEAD - *head2, TYPE, - LIST_ENTRY NAME);

-

TAILQ_CLASS_ENTRY(CLASSTYPE);

-

TAILQ_CLASS_HEAD(HEADNAME, - CLASSTYPE);

-

TAILQ_CONCAT(TAILQ_HEAD - *head1, TAILQ_HEAD - *head2, TAILQ_ENTRY - NAME);

-

TAILQ_EMPTY(TAILQ_HEAD - *head);

-

TAILQ_EMPTY_ATOMIC(TAILQ_HEAD - *head);

-

TAILQ_ENTRY(TYPE);

-

TAILQ_FIRST(TAILQ_HEAD - *head);

-

TAILQ_FOREACH(TYPE - *var, TAILQ_HEAD - *head, TAILQ_ENTRY - NAME);

-

TAILQ_FOREACH_FROM(TYPE - *var, TAILQ_HEAD - *head, TAILQ_ENTRY - NAME);

-

TAILQ_FOREACH_FROM_SAFE(TYPE - *var, TAILQ_HEAD - *head, TAILQ_ENTRY - NAME, TYPE - *temp_var);

-

TAILQ_FOREACH_REVERSE(TYPE - *var, TAILQ_HEAD - *head, HEADNAME, - TAILQ_ENTRY NAME);

-

TAILQ_FOREACH_REVERSE_FROM(TYPE - *var, TAILQ_HEAD - *head, HEADNAME, - TAILQ_ENTRY NAME);

-

TAILQ_FOREACH_REVERSE_FROM_SAFE(TYPE - *var, TAILQ_HEAD - *head, HEADNAME, - TAILQ_ENTRY NAME, - TYPE *temp_var);

-

TAILQ_FOREACH_REVERSE_SAFE(TYPE - *var, TAILQ_HEAD - *head, HEADNAME, - TAILQ_ENTRY NAME, - TYPE *temp_var);

-

TAILQ_FOREACH_SAFE(TYPE - *var, TAILQ_HEAD - *head, TAILQ_ENTRY - NAME, TYPE - *temp_var);

-

TAILQ_HEAD(HEADNAME, - TYPE);

-

TAILQ_HEAD_INITIALIZER(TAILQ_HEAD - head);

-

TAILQ_INIT(TAILQ_HEAD - *head);

-

TAILQ_INSERT_AFTER(TAILQ_HEAD - *head, TYPE - *listelm, TYPE - *elm, TAILQ_ENTRY - NAME);

-

TAILQ_INSERT_BEFORE(TYPE - *listelm, TYPE - *elm, TAILQ_ENTRY - NAME);

-

TAILQ_INSERT_HEAD(TAILQ_HEAD - *head, TYPE *elm, - TAILQ_ENTRY NAME);

-

TAILQ_INSERT_TAIL(TAILQ_HEAD - *head, TYPE *elm, - TAILQ_ENTRY NAME);

-

TAILQ_LAST(TAILQ_HEAD - *head, - HEADNAME);

-

TAILQ_NEXT(TYPE - *elm, TAILQ_ENTRY - NAME);

-

TAILQ_PREV(TYPE - *elm, HEADNAME, - TAILQ_ENTRY NAME);

-

TAILQ_REMOVE(TAILQ_HEAD - *head, TYPE *elm, - TAILQ_ENTRY NAME);

-

TAILQ_REPLACE(TAILQ_HEAD - *head, TYPE *elm, - TYPE *new, - TAILQ_ENTRY NAME);

-

TAILQ_SPLIT_AFTER(TAILQ_HEAD - *head, TYPE *elm, - TAILQ_HEAD *rest, - TAILQ_ENTRY NAME);

-

TAILQ_SWAP(TAILQ_HEAD - *head1, TAILQ_HEAD - *head2, TYPE, - TAILQ_ENTRY NAME);

-
-
-

-

These macros define and operate on four types of data structures - which can be used in both C and C++ source code:

-
    -
  1. Lists
    2. -
  2. Singly-linked lists
    3. -
  3. Singly-linked tail queues
    4. -
  4. Tail queues
    5. -
-All four structures support the following functionality: -
    -
  1. Insertion of a new entry at the head of the list.
    2. -
  2. Insertion of a new entry after any element in the list.
    3. -
  3. O(1) removal of an entry from the head of the list.
    4. -
  4. Forward traversal through the list.
    5. -
  5. Splitting a list in two after any element in the list.
    6. -
  6. Swapping the contents of two lists.
    7. -
-

Singly-linked lists are the simplest of the four data structures - and support only the above functionality. Singly-linked lists are ideal for - applications with large datasets and few or no removals, or for implementing - a LIFO queue. Singly-linked lists add the following functionality:

-
    -
  1. O(n) removal of any entry in the list.
    2. -
  2. O(n) concatenation of two lists.
    3. -
-

Singly-linked tail queues add the following functionality:

-
    -
  1. Entries can be added at the end of a list.
    2. -
  2. O(n) removal of any entry in the list.
    3. -
  3. They may be concatenated.
    4. -
-However: -
    -
  1. All list insertions must specify the head of the list.
    2. -
  2. Each head entry requires two pointers rather than one.
    3. -
  3. Code size is about 15% greater and operations run about 20% slower than - singly-linked lists.
    4. -
-

Singly-linked tail queues are ideal for applications with large - datasets and few or no removals, or for implementing a FIFO queue.

-

All doubly linked types of data structures (lists and tail queues) - additionally allow:

-
    -
  1. Insertion of a new entry before any element in the list.
    2. -
  2. O(1) removal of any entry in the list.
    3. -
-However: -
    -
  1. Each element requires two pointers rather than one.
    2. -
  2. Code size and execution time of operations (except for removal) is about - twice that of the singly-linked data-structures.
    3. -
-

Linked lists are the simplest of the doubly linked data - structures. They add the following functionality over the above:

-
    -
  1. O(n) concatenation of two lists.
    2. -
  2. They may be traversed backwards.
    3. -
-However: -
    -
  1. To traverse backwards, an entry to begin the traversal and the list in - which it is contained must be specified.
    2. -
-

Tail queues add the following functionality:

-
    -
  1. Entries can be added at the end of a list.
    2. -
  2. They may be traversed backwards, from tail to head.
    3. -
  3. They may be concatenated.
    4. -
-However: -
    -
  1. All list insertions and removals must specify the head of the list.
    2. -
  2. Each head entry requires two pointers rather than one.
    3. -
  3. Code size is about 15% greater and operations run about 20% slower than - singly-linked lists.
    4. -
-

In the macro definitions, TYPE is the name - of a user defined structure. The structure must contain a field called - NAME which is of type - SLIST_ENTRY, STAILQ_ENTRY, - LIST_ENTRY, or TAILQ_ENTRY. - In the macro definitions, CLASSTYPE is the name of a - user defined class. The class must contain a field called - NAME which is of type - SLIST_CLASS_ENTRY, - STAILQ_CLASS_ENTRY, - LIST_CLASS_ENTRY, or - TAILQ_CLASS_ENTRY. The argument - HEADNAME is the name of a user defined structure that - must be declared using the macros SLIST_HEAD, - SLIST_CLASS_HEAD, - STAILQ_HEAD, - STAILQ_CLASS_HEAD, - LIST_HEAD, LIST_CLASS_HEAD, - TAILQ_HEAD, or - TAILQ_CLASS_HEAD. See the examples below for further - explanation of how these macros are used.

-
-
-

-

A singly-linked list is headed by a structure defined by the - SLIST_HEAD macro. This structure contains a single - pointer to the first element on the list. The elements are singly linked for - minimum space and pointer manipulation overhead at the expense of O(n) - removal for arbitrary elements. New elements can be added to the list after - an existing element or at the head of the list. An - SLIST_HEAD structure is declared as follows:

-
-
SLIST_HEAD(HEADNAME, TYPE) head;
-
-

where HEADNAME is the name of the structure - to be defined, and TYPE is the type of the elements to - be linked into the list. A pointer to the head of the list can later be - declared as:

-
-
struct HEADNAME *headp;
-
-

(The names head and - headp are user selectable.)

-

The macro SLIST_HEAD_INITIALIZER evaluates - to an initializer for the list head.

-

The macro SLIST_CONCAT concatenates the - list headed by head2 onto the end of the one headed by - head1 removing all entries from the former. Use of - this macro should be avoided as it traverses the entirety of the - head1 list. A singly-linked tail queue should be used - if this macro is needed in high-usage code paths or to operate on long - lists.

-

The macro SLIST_EMPTY evaluates to true if - there are no elements in the list. The - SLIST_EMPTY_ATOMIC variant has the same behavior, - but can be safely used in contexts where it is possible that a different - thread is concurrently updating the list.

-

The macro SLIST_ENTRY declares a structure - that connects the elements in the list.

-

The macro SLIST_FIRST returns the first - element in the list or NULL if the list is empty.

-

The macro SLIST_FOREACH traverses the list - referenced by head in the forward direction, assigning - each element in turn to var.

-

The macro SLIST_FOREACH_FROM behaves - identically to SLIST_FOREACH when - var is NULL, else it treats var - as a previously found SLIST element and begins the loop at - var instead of the first element in the SLIST - referenced by head.

-

The macro - SLIST_FOREACH_SAFE traverses the list referenced by - head in the forward direction, assigning each element - in turn to var. However, unlike - () - here it is permitted to both remove var as well as - free it from within the loop safely without interfering with the - traversal.

-

The macro SLIST_FOREACH_FROM_SAFE behaves - identically to SLIST_FOREACH_SAFE when - var is NULL, else it treats var - as a previously found SLIST element and begins the loop at - var instead of the first element in the SLIST - referenced by head.

-

The macro SLIST_INIT initializes the list - referenced by head.

-

The macro SLIST_INSERT_HEAD inserts the - new element elm at the head of the list.

-

The macro SLIST_INSERT_AFTER inserts the - new element elm after the element - listelm.

-

The macro SLIST_NEXT returns the next - element in the list.

-

The macro SLIST_REMOVE_AFTER removes the - element after elm from the list. Unlike - SLIST_REMOVE, this macro does not traverse the entire - list.

-

The macro SLIST_REMOVE_HEAD removes the - element elm from the head of the list. For optimum - efficiency, elements being removed from the head of the list should - explicitly use this macro instead of the generic - SLIST_REMOVE macro.

-

The macro SLIST_REMOVE removes the element - elm from the list. Use of this macro should be avoided - as it traverses the entire list. A doubly-linked list should be used if this - macro is needed in high-usage code paths or to operate on long lists.

-

The macro SLIST_SPLIT_AFTER splits the - list referenced by head, making - rest reference the list formed by elements after - elm in head.

-

The macro SLIST_SWAP swaps the contents of - head1 and head2.

-
-
-

-
-
SLIST_HEAD(slisthead, entry) head =
-    SLIST_HEAD_INITIALIZER(head);
-struct slisthead *headp;		/* Singly-linked List head. */
-struct entry {
-	...
-	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
-	...
-} *n1, *n2, *n3, *np;
-
-SLIST_INIT(&head);			/* Initialize the list. */
-
-n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
-SLIST_INSERT_HEAD(&head, n1, entries);
-
-n2 = malloc(sizeof(struct entry));	/* Insert after. */
-SLIST_INSERT_AFTER(n1, n2, entries);
-
-SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
-free(n2);
-
-n3 = SLIST_FIRST(&head);
-SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
-free(n3);
-					/* Forward traversal. */
-SLIST_FOREACH(np, &head, entries)
-	np-> ...
-					/* Safe forward traversal. */
-SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
-	np->do_stuff();
-	...
-	SLIST_REMOVE(&head, np, entry, entries);
-	free(np);
-}
-
-while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
-	n1 = SLIST_FIRST(&head);
-	SLIST_REMOVE_HEAD(&head, entries);
-	free(n1);
-}
-
-
-
-

-

A singly-linked tail queue is headed by a structure defined by the - STAILQ_HEAD macro. This structure contains a pair of - pointers, one to the first element in the tail queue and the other to the - last element in the tail queue. The elements are singly linked for minimum - space and pointer manipulation overhead at the expense of O(n) removal for - arbitrary elements. New elements can be added to the tail queue after an - existing element, at the head of the tail queue, or at the end of the tail - queue. A STAILQ_HEAD structure is declared as - follows:

-
-
STAILQ_HEAD(HEADNAME, TYPE) head;
-
-

where HEADNAME is the name of the - structure to be defined, and TYPE is the type of the - elements to be linked into the tail queue. A pointer to the head of the tail - queue can later be declared as:

-
-
struct HEADNAME *headp;
-
-

(The names head and - headp are user selectable.)

-

The macro STAILQ_HEAD_INITIALIZER - evaluates to an initializer for the tail queue - head.

-

The macro STAILQ_CONCAT concatenates the - tail queue headed by head2 onto the end of the one - headed by head1 removing all entries from the - former.

-

The macro STAILQ_EMPTY evaluates to true - if there are no items on the tail queue. The - STAILQ_EMPTY_ATOMIC variant has the same behavior, - but can be safely used in contexts where it is possible that a different - thread is concurrently updating the queue.

-

The macro STAILQ_ENTRY declares a - structure that connects the elements in the tail queue.

-

The macro STAILQ_FIRST returns the first - item on the tail queue or NULL if the tail queue is empty.

-

The macro STAILQ_FOREACH traverses the - tail queue referenced by head in the forward - direction, assigning each element in turn to var.

-

The macro STAILQ_FOREACH_FROM behaves - identically to STAILQ_FOREACH when - var is NULL, else it treats var - as a previously found STAILQ element and begins the loop at - var instead of the first element in the STAILQ - referenced by head.

-

The macro - STAILQ_FOREACH_SAFE traverses the tail queue - referenced by head in the forward direction, assigning - each element in turn to var. However, unlike - () - here it is permitted to both remove var as well as - free it from within the loop safely without interfering with the - traversal.

-

The macro STAILQ_FOREACH_FROM_SAFE behaves - identically to STAILQ_FOREACH_SAFE when - var is NULL, else it treats var - as a previously found STAILQ element and begins the loop at - var instead of the first element in the STAILQ - referenced by head.

-

The macro STAILQ_INIT initializes the tail - queue referenced by head.

-

The macro STAILQ_INSERT_HEAD inserts the - new element elm at the head of the tail queue.

-

The macro STAILQ_INSERT_TAIL inserts the - new element elm at the end of the tail queue.

-

The macro STAILQ_INSERT_AFTER inserts the - new element elm after the element - listelm.

-

The macro STAILQ_LAST returns the last - item on the tail queue. If the tail queue is empty the return value is - NULL.

-

The macro STAILQ_NEXT returns the next - item on the tail queue, or NULL this item is the last.

-

The macro STAILQ_REMOVE_AFTER removes the - element after elm from the tail queue. Unlike - STAILQ_REMOVE, this macro does not traverse the entire - tail queue.

-

The macro STAILQ_REMOVE_HEAD removes the - element at the head of the tail queue. For optimum efficiency, elements - being removed from the head of the tail queue should use this macro - explicitly rather than the generic STAILQ_REMOVE - macro.

-

The macro STAILQ_REMOVE removes the - element elm from the tail queue. Use of this macro - should be avoided as it traverses the entire list. A doubly-linked tail - queue should be used if this macro is needed in high-usage code paths or to - operate on long tail queues.

-

The macro STAILQ_REVERSE reverses the - queue in place.

-

The macro STAILQ_SPLIT_AFTER splits the - tail queue referenced by head, making - rest reference the tail queue formed by elements after - elm in head.

-

The macro STAILQ_SWAP swaps the contents - of head1 and head2.

-
-
-

-
-
STAILQ_HEAD(stailhead, entry) head =
-    STAILQ_HEAD_INITIALIZER(head);
-struct stailhead *headp;		/* Singly-linked tail queue head. */
-struct entry {
-	...
-	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
-	...
-} *n1, *n2, *n3, *np;
-
-STAILQ_INIT(&head);			/* Initialize the queue. */
-
-n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
-STAILQ_INSERT_HEAD(&head, n1, entries);
-
-n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
-STAILQ_INSERT_TAIL(&head, n1, entries);
-
-n2 = malloc(sizeof(struct entry));	/* Insert after. */
-STAILQ_INSERT_AFTER(&head, n1, n2, entries);
-					/* Deletion. */
-STAILQ_REMOVE(&head, n2, entry, entries);
-free(n2);
-					/* Deletion from the head. */
-n3 = STAILQ_FIRST(&head);
-STAILQ_REMOVE_HEAD(&head, entries);
-free(n3);
-					/* Forward traversal. */
-STAILQ_FOREACH(np, &head, entries)
-	np-> ...
-					/* Safe forward traversal. */
-STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
-	np->do_stuff();
-	...
-	STAILQ_REMOVE(&head, np, entry, entries);
-	free(np);
-}
-					/* TailQ Deletion. */
-while (!STAILQ_EMPTY(&head)) {
-	n1 = STAILQ_FIRST(&head);
-	STAILQ_REMOVE_HEAD(&head, entries);
-	free(n1);
-}
-					/* Faster TailQ Deletion. */
-n1 = STAILQ_FIRST(&head);
-while (n1 != NULL) {
-	n2 = STAILQ_NEXT(n1, entries);
-	free(n1);
-	n1 = n2;
-}
-STAILQ_INIT(&head);
-
-
-
-

-

A list is headed by a structure defined by the - LIST_HEAD macro. This structure contains a single - pointer to the first element on the list. The elements are doubly linked so - that an arbitrary element can be removed without traversing the list. New - elements can be added to the list after an existing element, before an - existing element, or at the head of the list. A - LIST_HEAD structure is declared as follows:

-
-
LIST_HEAD(HEADNAME, TYPE) head;
-
-

where HEADNAME is the name of the structure - to be defined, and TYPE is the type of the elements to - be linked into the list. A pointer to the head of the list can later be - declared as:

-
-
struct HEADNAME *headp;
-
-

(The names head and - headp are user selectable.)

-

The macro LIST_HEAD_INITIALIZER evaluates - to an initializer for the list head.

-

The macro LIST_CONCAT concatenates the - list headed by head2 onto the end of the one headed by - head1 removing all entries from the former. Use of - this macro should be avoided as it traverses the entirety of the - head1 list. A tail queue should be used if this macro - is needed in high-usage code paths or to operate on long lists.

-

The macro LIST_EMPTY evaluates to true if - there are no elements in the list. The - LIST_EMPTY_ATOMIC variant has the same behavior, but - can be safely used in contexts where it is possible that a different thread - is concurrently updating the list.

-

The macro LIST_ENTRY declares a structure - that connects the elements in the list.

-

The macro LIST_FIRST returns the first - element in the list or NULL if the list is empty.

-

The macro LIST_FOREACH traverses the list - referenced by head in the forward direction, assigning - each element in turn to var.

-

The macro LIST_FOREACH_FROM behaves - identically to LIST_FOREACH when - var is NULL, else it treats var - as a previously found LIST element and begins the loop at - var instead of the first element in the LIST - referenced by head.

-

The macro - LIST_FOREACH_SAFE traverses the list referenced by - head in the forward direction, assigning each element - in turn to var. However, unlike - () - here it is permitted to both remove var as well as - free it from within the loop safely without interfering with the - traversal.

-

The macro LIST_FOREACH_FROM_SAFE behaves - identically to LIST_FOREACH_SAFE when - var is NULL, else it treats var - as a previously found LIST element and begins the loop at - var instead of the first element in the LIST - referenced by head.

-

The macro LIST_INIT initializes the list - referenced by head.

-

The macro LIST_INSERT_HEAD inserts the new - element elm at the head of the list.

-

The macro LIST_INSERT_AFTER inserts the - new element elm after the element - listelm.

-

The macro LIST_INSERT_BEFORE inserts the - new element elm before the element - listelm.

-

The macro LIST_NEXT returns the next - element in the list, or NULL if this is the last.

-

The macro LIST_PREV returns the previous - element in the list, or NULL if this is the first. List - head must contain element - elm.

-

The macro LIST_REMOVE removes the element - elm from the list.

-

The macro - () - replaces the element elm with - new in the list. The element new - must not already be on a list.

-

The macro LIST_SPLIT_AFTER splits the list - referenced by head, making rest - reference the list formed by elements after elm in - head.

-

The macro LIST_SWAP swaps the contents of - head1 and head2.

-
-
-

-
-
LIST_HEAD(listhead, entry) head =
-    LIST_HEAD_INITIALIZER(head);
-struct listhead *headp;			/* List head. */
-struct entry {
-	...
-	LIST_ENTRY(entry) entries;	/* List. */
-	...
-} *n1, *n2, *n3, *np, *np_temp;
-
-LIST_INIT(&head);			/* Initialize the list. */
-
-n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
-LIST_INSERT_HEAD(&head, n1, entries);
-
-n2 = malloc(sizeof(struct entry));	/* Insert after. */
-LIST_INSERT_AFTER(n1, n2, entries);
-
-n3 = malloc(sizeof(struct entry));	/* Insert before. */
-LIST_INSERT_BEFORE(n2, n3, entries);
-
-LIST_REMOVE(n2, entries);		/* Deletion. */
-free(n2);
-					/* Forward traversal. */
-LIST_FOREACH(np, &head, entries)
-	np-> ...
-
-					/* Safe forward traversal. */
-LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
-	np->do_stuff();
-	...
-	LIST_REMOVE(np, entries);
-	free(np);
-}
-
-while (!LIST_EMPTY(&head)) {		/* List Deletion. */
-	n1 = LIST_FIRST(&head);
-	LIST_REMOVE(n1, entries);
-	free(n1);
-}
-
-n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
-while (n1 != NULL) {
-	n2 = LIST_NEXT(n1, entries);
-	free(n1);
-	n1 = n2;
-}
-LIST_INIT(&head);
-
-
-
-

-

A tail queue is headed by a structure defined by the - TAILQ_HEAD macro. This structure contains a pair of - pointers, one to the first element in the tail queue and the other to the - last element in the tail queue. The elements are doubly linked so that an - arbitrary element can be removed without traversing the tail queue. New - elements can be added to the tail queue after an existing element, before an - existing element, at the head of the tail queue, or at the end of the tail - queue. A TAILQ_HEAD structure is declared as - follows:

-
-
TAILQ_HEAD(HEADNAME, TYPE) head;
-
-

where HEADNAME is the name of the - structure to be defined, and TYPE is the type of the - elements to be linked into the tail queue. A pointer to the head of the tail - queue can later be declared as:

-
-
struct HEADNAME *headp;
-
-

(The names head and - headp are user selectable.)

-

The macro TAILQ_HEAD_INITIALIZER evaluates - to an initializer for the tail queue head.

-

The macro TAILQ_CONCAT concatenates the - tail queue headed by head2 onto the end of the one - headed by head1 removing all entries from the - former.

-

The macro TAILQ_EMPTY evaluates to true if - there are no items on the tail queue. The - TAILQ_EMPTY_ATOMIC variant has the same behavior, - but can be safely used in contexts where it is possible that a different - thread is concurrently updating the queue.

-

The macro TAILQ_ENTRY declares a structure - that connects the elements in the tail queue.

-

The macro TAILQ_FIRST returns the first - item on the tail queue or NULL if the tail queue is empty.

-

The macro TAILQ_FOREACH traverses the tail - queue referenced by head in the forward direction, - assigning each element in turn to var. - var is set to NULL if the loop - completes normally, or if there were no elements.

-

The macro TAILQ_FOREACH_FROM behaves - identically to TAILQ_FOREACH when - var is NULL, else it treats var - as a previously found TAILQ element and begins the loop at - var instead of the first element in the TAILQ - referenced by head.

-

The macro TAILQ_FOREACH_REVERSE traverses - the tail queue referenced by head in the reverse - direction, assigning each element in turn to var.

-

The macro TAILQ_FOREACH_REVERSE_FROM - behaves identically to TAILQ_FOREACH_REVERSE when - var is NULL, else it treats var - as a previously found TAILQ element and begins the reverse loop at - var instead of the last element in the TAILQ - referenced by head.

-

The macros TAILQ_FOREACH_SAFE and - TAILQ_FOREACH_REVERSE_SAFE traverse the list - referenced by head in the forward or reverse direction - respectively, assigning each element in turn to var. - However, unlike their unsafe counterparts, - TAILQ_FOREACH and - TAILQ_FOREACH_REVERSE permit to both remove - var as well as free it from within the loop safely - without interfering with the traversal.

-

The macro TAILQ_FOREACH_FROM_SAFE behaves - identically to TAILQ_FOREACH_SAFE when - var is NULL, else it treats var - as a previously found TAILQ element and begins the loop at - var instead of the first element in the TAILQ - referenced by head.

-

The macro TAILQ_FOREACH_REVERSE_FROM_SAFE - behaves identically to TAILQ_FOREACH_REVERSE_SAFE - when var is NULL, else it treats - var as a previously found TAILQ element and begins the - reverse loop at var instead of the last element in the - TAILQ referenced by head.

-

The macro TAILQ_INIT initializes the tail - queue referenced by head.

-

The macro TAILQ_INSERT_HEAD inserts the - new element elm at the head of the tail queue.

-

The macro TAILQ_INSERT_TAIL inserts the - new element elm at the end of the tail queue.

-

The macro TAILQ_INSERT_AFTER inserts the - new element elm after the element - listelm.

-

The macro TAILQ_INSERT_BEFORE inserts the - new element elm before the element - listelm.

-

The macro TAILQ_LAST returns the last item - on the tail queue. If the tail queue is empty the return value is - NULL.

-

The macro TAILQ_NEXT returns the next item - on the tail queue, or NULL if this item is the last.

-

The macro TAILQ_PREV returns the previous - item on the tail queue, or NULL if this item is the first.

-

The macro TAILQ_REMOVE removes the element - elm from the tail queue.

-

The macro - () - replaces the element elm with - new in the tail queue. The element - new must not already be on a list.

-

The macro TAILQ_SPLIT_AFTER splits the - tail queue referenced by head, making - rest reference the tail queue formed by elements after - elm in head.

-

The macro TAILQ_SWAP swaps the contents of - head1 and head2.

-
-
-

-
-
TAILQ_HEAD(tailhead, entry) head =
-    TAILQ_HEAD_INITIALIZER(head);
-struct tailhead *headp;			/* Tail queue head. */
-struct entry {
-	...
-	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
-	...
-} *n1, *n2, *n3, *n4, *np;
-
-TAILQ_INIT(&head);			/* Initialize the queue. */
-
-n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
-TAILQ_INSERT_HEAD(&head, n1, entries);
-
-n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
-TAILQ_INSERT_TAIL(&head, n1, entries);
-
-n2 = malloc(sizeof(struct entry));	/* Insert after. */
-TAILQ_INSERT_AFTER(&head, n1, n2, entries);
-
-n3 = malloc(sizeof(struct entry));	/* Insert before. */
-TAILQ_INSERT_BEFORE(n2, n3, entries);
-
-TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
-free(n2);
-
-n4 = malloc(sizeof(struct entry));	/* Replacement. */
-TAILQ_REPLACE(&head, n3, n4, entries);
-free(n3);
-					/* Forward traversal. */
-TAILQ_FOREACH(np, &head, entries)
-	np-> ...
-					/* Safe forward traversal. */
-TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
-	np->do_stuff();
-	...
-	TAILQ_REMOVE(&head, np, entries);
-	free(np);
-}
-					/* Reverse traversal. */
-TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
-	np-> ...
-					/* TailQ Deletion. */
-while (!TAILQ_EMPTY(&head)) {
-	n1 = TAILQ_FIRST(&head);
-	TAILQ_REMOVE(&head, n1, entries);
-	free(n1);
-}
-					/* Faster TailQ Deletion. */
-n1 = TAILQ_FIRST(&head);
-while (n1 != NULL) {
-	n2 = TAILQ_NEXT(n1, entries);
-	free(n1);
-	n1 = n2;
-}
-TAILQ_INIT(&head);
-
-
-
-

-

queue(3) provides several diagnostic and - debugging facilities.

-

Check code that performs basic integrity and API conformance - checks is automatically inserted when using queue macros in the kernel if - compiling it with INVARIANTS. One can request - insertion or elision of check code by respectively defining one of the - macros QUEUE_MACRO_DEBUG_ASSERTIONS or - QUEUE_MACRO_NO_DEBUG_ASSERTIONS before first inclusion - of <sys/queue.h>. When check - code encounters an anomaly, it panics the kernel or aborts the program. To - this end, in the kernel or in _STANDALONE builds, it - by default calls panic(), while in userland builds - it prints the diagnostic message on stderr and then - calls abort(). These behaviors can be overridden by - defining a custom QMD_PANIC() macro before first - inclusion of <sys/queue.h>. - The diagnostic messages automatically include the source file, line and - function where the failing check occurred. This behavior can be overridden - by defining a custom QMD_ASSERT() macro before first - inclusion of - <sys/queue.h>.

-

The SLIST_REMOVE_PREVPTR() macro is - available to aid debugging:

-
-
SLIST_REMOVE_PREVPTR(TYPE - **prev, TYPE *elm, SLIST_ENTRY - NAME)
-
-

Removes element elm, which must directly - follow the element whose &SLIST_NEXT() is - prev, from the list. This macro may insert, under - conditions detailed above, check code that validates that - elm indeed follows prev in - the list (through the QMD_SLIST_CHECK_PREVPTR() - macro).

-
-
-

When debugging, it can be useful to trace queue changes. To enable - tracing, define the macro QUEUE_MACRO_DEBUG_TRACE. - Note that, at the moment, only macros for regular tail queues have been - instrumented.

-

It can also be useful to trash pointers that have been unlinked - from a queue, to detect use after removal. To enable pointer trashing, - define the macro QUEUE_MACRO_DEBUG_TRASH at compile - time. Note that, at the moment, only a limited number of macros have been - instrumented. The macro - QMD_IS_TRASHED(void *ptr) - returns true if ptr has been trashed by the - QUEUE_MACRO_DEBUG_TRASH option.

-
-
-

-

arb(3), tree(3)

-
-
-

-

The queue functions first appeared in - 4.4BSD.

-
-
- - - - - -
April 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man3/sigevent.3 3.html b/static/freebsd/man3/sigevent.3 3.html deleted file mode 100644 index 794ab90d..00000000 --- a/static/freebsd/man3/sigevent.3 3.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - -
SIGEVENT(3)Library Functions ManualSIGEVENT(3)
-
-
-

-

sigevent — - asynchronous event notification

-
-
-

-

#include - <signal.h>

-
-
-

-

Some operations permit threads to request asynchronous - notification of events via a struct sigevent - structure. This structure contains several fields that describe the - requested notification:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
intsigev_notifynotification method
intsigev_signosignal number
union sigvalsigev_valuesignal value
intsigev_notify_kqueuekqueue(2) file descriptor
unsigned shortsigev_notify_kevent_flagskevent flags
lwpid_tsigev_notify_thread_idLWP ID
void (*)(union sigval)sigev_notify_functioncallback function pointer
pthread_attr_t *sigev_notify_attributescallback thread attributes
-

The sigev_notify field specifies the - notification method used when the event triggers:

-
-
-
No notification is sent.
-
-
The signal sigev_signo is queued as a real-time - signal to the calling process. The value stored in - sigev_value will be present in the - si_value of the siginfo_t - structure of the queued signal.
-
-
The notification function in sigev_notify_function - is called in a separate thread context. The thread is created with the - attributes specified in *sigev_notify_attributes. - The value stored in sigev_value is passed as the - sole argument to sigev_notify_function. If - sigev_notify_attributes is - NULL, the thread is created with default - attributes.
-
-
A new kevent is posted to the kqueue - sigev_notify_kqueue. The udata - member of the kevent structure contains the value stored in - sigev_value. The meaning of other fields in the - kevent are specific to the type of triggered event.
-
-
The signal sigev_signo is queued to the thread whose - LWP ID is sigev_notify_thread_id. The value stored - in sigev_value will be present in the - si_value of the siginfo_t - structure of the queued signal.
-
-
-
-

-

Note that programs wishing to use - SIGEV_THREAD notifications must link against the - POSIX Real-time Library (librt, -lrt).

-
-
-

-

aio_read(2), mq_notify(2), - timer_create(2), siginfo(3)

-
-
-

-

The struct sigevent type conforms to - IEEE Std 1003.1-2004 (“POSIX.1”).

-
-
-

-

The sigevent structure first appeared in - FreeBSD 3.3.

-
-
- - - - - -
February 25, 2020FreeBSD 15.0
diff --git a/static/freebsd/man3/siginfo.3 3.html b/static/freebsd/man3/siginfo.3 3.html deleted file mode 100644 index fb0a09d2..00000000 --- a/static/freebsd/man3/siginfo.3 3.html +++ /dev/null @@ -1,528 +0,0 @@ - - - - - - -
SIGINFO(3)Library Functions ManualSIGINFO(3)
-
-
-

-

siginfo — signal - generation information

-
-
-

-

#include - <signal.h>

-
-
-

-

A process may request signal information when it is catching a - signal. The information specifies why the system generated that signal. To - request signal information in a signal handler, the user can set - SA_SIGINFO in sa_flags before - sigaction(2) is called, otherwise the user can use - sigwaitinfo(2) and sigtimedwait(2) to - get signal information. In either case, the system returns the information - in a structure of type siginfo_t, which includes the - following information:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
intsi_signosignal number
intsi_errnoerror number
intsi_codesignal code
union sigvalsi_valuesignal value
pid_tsi_pidsending process ID
uid_tsi_uidsending process's real user ID
void*si_addrvirtual address
intsi_statusexit value or signal
longsi_bandband event for SIGPOLL
intsi_trapnomachine trap code
intsi_timeridPOSIX timer ID
intsi_overrunPOSIX timer overrun count
intsi_mqdPOSIX message queue ID
intsi_syscallsystem-call number for system calls blocked by Capsicum
-

The si_signo member contains the signal - number.

-

The si_errno member contains an error number - defined in the file - <errno.h>.

-

The si_code member contains a code which - describes the cause of the signal. The macros specified in the - Code column of the following table are defined for use as - values of si_code that are signal-specific or - non-signal-specific reasons why the signal was generated:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
illegal opcode
illegal operand
illegal addressing mode
illegal trap
illegal privileged opcode
illegal privileged register
coprocessor error
internal stack error
integer divide by zero
integer overflow
floating-point divide by zero
floating-point overflow
floating-point underflow
floating-point inexact result
invalid floating-point operation
subscript out of range
address not mapped to object
invalid permissions for mapped object
invalid address alignment
nonexistent physical address
object-specific hardware error
cannot alloc a page to map at fault
process breakpoint
process trace trap
DTrace induced trap
capabilities protective trap
child has exited
child has terminated abnormally and did not create a core file
child has terminated abnormally and created a core file
traced child has trapped
child has stopped
stopped child has continued
data input available
output buffers available
input message available
I/O error
high priority input available
device disconnected
AnyOnly the si_signo member is meaningful; the value - of all other members is unspecified.
signal sent by kill(2)
signal sent by sigqueue(2)
signal generated by expiration of a timer set by - timer_settime(2)
signal generated by completion of an asynchronous I/O request
signal generated by arrival of a message on an empty message queue
signal generated by miscellaneous parts of the kernel
signal sent by pthread_kill(3)
-

For synchronous signals, si_addr is - generally set to the address of the faulting instruction. However, - synchronous signals raised by a faulting memory access such as - SIGSEGV and SIGBUS may - report the address of the faulting memory access (if available) in - si_addr instead. Additionally - SIGTRAP raised by a hardware watchpoint exception - may report the data address that triggered the watchpoint in - si_addr.

-

Synchronous signals set si_trapno to a - machine-dependent trap number.

-

In addition, the following signal-specific information is - available:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
si_pidchild process ID
si_statusexit value or signal; if si_code is equal to - CLD_EXITED, then it is equal to the exit value of - the child process, otherwise, it is equal to a signal that caused the - child process to change state.
si_uidreal user ID of the process that sent the signal
si_bandband event for POLL_IN, - POLL_OUT, or POLL_MSG
-

Finally, the following code-specific information is available:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
si_pidthe process ID that sent the signal
si_uidreal user ID of the process that sent the signal
si_valuethe value passed to sigqueue(2) system call
si_pidthe process ID that sent the signal
si_uidreal user ID of the process that sent the signal
si_valuethe value passed to timer_create(2) system call
si_timeridthe timer ID returned by timer_create(2) system - call
si_overruntimer overrun count corresponding to the signal
si_errnoIf timer overrun will be {DELAYTIMER_MAX}, an - error code defined in - <errno.h> is set
si_valuethe value passed to aio system calls
si_valuethe value passed to mq_notify(2) system call
si_mqdthe ID of the message queue which generated the signal
si_pidthe process ID that sent the signal
si_uidreal user ID of the process that sent the signal
-
-
-

-

Currently, the kernel never generates the - SIGPOLL signal. SIGCHLD - signal is queued when a process changed its status or exited. POSIX Realtime - Extensions like aio, timer, and message queue also queue signals. Signals - with code SI_USER, SI_KERNEL - or SI_LWP are only queued if there are sufficient - resources; otherwise, SI_NOINFO results. For some - hardware architectures, the exact value of si_addr - might not be available.

-
-
-

-

aio_read(2), kill(2), - mq_notify(2), sigaction(2), - sigqueue(2), sigwaitinfo(2), - timer_create(2), timer_settime(2), - waitpid(2), pthread_kill(3)

-
-
-

-

The siginfo_t type conforms to - IEEE Std 1003.1-2004 (“POSIX.1”).

-
-
-

-

Full support for POSIX signal information first appeared in - FreeBSD 7.0. The codes - SI_USER and SI_KERNEL can be - generated as of FreeBSD 8.1. The code - SI_LWP can be generated as of - FreeBSD 9.0.

-
-
-

-

This manual page was written by David Xu - <davidxu@FreeBSD.org>.

-
-
- - - - - -
February 17, 2021FreeBSD 15.0
diff --git a/static/freebsd/man3/snl.3 3.html b/static/freebsd/man3/snl.3 3.html deleted file mode 100644 index 5af578e0..00000000 --- a/static/freebsd/man3/snl.3 3.html +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -
SNL(3)Library Functions ManualSNL(3)
-
-
-

-

snl_init, - snl_free, snl_read_message, - snl_send, snl_get_seq, - snl_allocz, snl_clear_lb, - snl_parse_nlmsg, - snl_parse_header, - snl_parse_attrs, - snl_parse_attrs_raw, - snl_attr_get_flag, - snl_attr_get_ip, - snl_attr_get_uint16, - snl_attr_get_uint32, - snl_attr_get_string, - snl_attr_get_stringn, - snl_attr_get_nla, - snl_field_get_uint8, - snl_field_get_uint16, - snl_field_get_uint32 — - simple netlink library

-
-
-

-

#include - <netlink/netlink_snl.h> -
- #include - <netlink/netlink_snl_route.h>

-

bool -
- snl_init(struct - snl_state *ss, int - netlink_family);

-

snl_free(struct - snl_state *ss);

-

struct nlmsghdr * -
- snl_read_message(struct - snl_state *ss);

-

bool -
- snl_send(struct - snl_state *ss, void - *data, int sz);

-

uint32_t -
- snl_get_seq(struct - snl_state *ss);

-

void * -
- snl_allocz(struct - snl_state *ss, int - len);

-

snl_clear_lb(struct - snl_state *ss);

-

bool -
- snl_parse_nlmsg(struct - snl_state *ss, struct - nlmsghdr *hdr, const - struct snl_hdr_parser *ps, - void *target);

-

bool -
- snl_parse_header(struct - snl_state *ss, void - *hdr, int len, - const struct snl_hdr_parser - *ps, int pslen, - void *target);

-

bool -
- snl_parse_attrs(struct - snl_state *ss, struct - nlmsghdr *hdr, int - hdrlen, const struct - snl_attr_parser *ps, int - pslen, void - *target);

-

bool -
- snl_parse_attrs_raw(struct - snl_state *ss, struct - nlattr *nla_head, int - len, const struct - snl_attr_parser *ps, int - pslen, void - *target);

-

bool -
- snl_attr_get_flag(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_uint8(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_uint16(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_uint32(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_uint64(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_string(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_stringn(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_nla(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_ip(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-

bool -
- snl_attr_get_ipvia(struct - snl_state *ss, struct - nlattr *nla, void - *target);

-
-
-

-

The snl(3) library provides an easy way of - sending and receiving Netlink messages, taking care of serialisation and - deserialisation.

-
-

-

Call - () - with a pointer to the struct snl_state and the - desired Netlink family to initialise the library instance. To free the - library instance, call - ().

-

The library functions are NOT multithread-safe. If multithreading - is desired, consider initializing an instance per thread.

-
-
-

-

The library uses pre-allocated extendable memory buffers to handle - message parsing. The typical usage pattern is to allocate the necessary data - structures during the message parsing or writing process via - () - and free all allocated data at once using - () - after handling the message.

-
-
-

-

The library does not currently offer any wrappers for writing - netlink messages. Simple request messages can be composed by filling in all - needed fields directly. Example for constructing an interface dump - request:

-
-
	struct {
-		struct nlmsghdr hdr;
-		struct ifinfomsg ifmsg;
-	} msg = {
-		.hdr.nlmsg_type = RTM_GETLINK,
-		.hdr.nlmsg_flags = NLM_F_DUMP | NLM_F_REQUEST,
-		.hdr.nlmsg_seq = snl_get_seq(ss),
-	};
-	msg.hdr.nlmsg_len = sizeof(msg);
-
-() - can be used to generate a unique message number. To send the resulting - message, - () - can be used. -
-
-

-

To receive a message, use - (). - Currently, this call is blocking.

-

The library provides an easy way to - convert the message to the pre-defined C structure. For each message type, - one needs to define rules, converting the protocol header fields and the - desired attributes to the specified structure. It can be accomplished by - using message parsers. Each message parser consists of an array of attribute - getters and an array of header field getters. The former array needs to be - sorted by the attribute type. There is a - () - macro to check if the order is correct. - (parser_name, - family header type, struct - snl_field_parser[], struct snl_attr_parser[]) - can be used to create a new parser. - (parser_name, - struct snl_field_parser[]) can be used to create an - attribute-only message parser.

-

Each attribute getter needs to be embedded in the following - structure:

-
-
typedef bool snl_parse_attr_f(struct snl_state *ss, struct nlattr *attr, const void *arg, void *target);
-struct snl_attr_parser {
-	uint16_t		type;	/* Attribute type */
-	uint16_t		off;	/* field offset in the target structure */
-	snl_parse_attr_f	*cb;	/* getter function to call */
-	const void		*arg;	/* getter function custom argument */
-};
-
-The generic attribute getter has the following signature: - bool - (struct - snl_state *ss, struct nlattr *nla, - const void *arg, void *target). - nla contains the pointer of the attribute to use as the datasource. The target - field is the pointer to the field in the target structure. It is up to the - getter to know the type of the target field. The getter must check the input - attribute and return false if the attribute is not formed correctly. - Otherwise, the getter fetches the attribute value and stores it in the target, - then returns true. It is possible to use snl_allocz() - to create the desired data structure . A number of predefined getters for the - common data types exist. - () - converts a flag-type attribute to an uint8_t value of 1 or 0, depending on the - attribute presence. - () - stores a uint8_t type attribute into the uint8_t target field. - () - stores a uint16_t type attribute into the uint16_t target field. - () - stores a uint32_t type attribute into the uint32_t target field. - () - stores a uint64_t type attribute into the uint64_t target field. - () - and - () - stores a pointer to the sockaddr structure with the IPv4/IPv6 address - contained in the attribute. Sockaddr is allocated using - snl_allocz(). - () - stores a pointer to the NULL-terminated string. The string itself is allocated - using snl_allocz(). - () - stores a pointer to the specified attribute. - () - stores a pointer to the non-NULL-terminated string. -

Similarly, each family header getter needs to be embedded in the - following structure:

-
-
typedef void snl_parse_field_f(struct snl_state *ss, void *hdr, void *target);
-struct snl_field_parser {
-	uint16_t		off_in;	/* field offset in the input structure */
-	uint16_t                off_out;/* field offset in the target structure */
-	snl_parse_field_f       *cb;	/* getter function to call */
-};
-
-The generic field getter has the following signature: void - snl_field_get_<type> "struct snl_state *ss" "void - *src" "void *target" . A number of pre-defined getters for the - common data types exist. - () - fetches an uint8_t value and stores it in the target. - () - fetches an uint8_t value and stores it in the target. - () - fetches an uint32_t value and stores it in the target. -
-
-
-

-

The following example demonstrates how to list all system - interfaces using netlink.

-
-
#include <stdio.h>
-
-#include <netlink/netlink.h>
-#include <netlink/netlink_route.h>
-#include "netlink/netlink_snl.h"
-#include "netlink/netlink_snl_route.h"
-
-struct nl_parsed_link {
-	uint32_t		ifi_index;
-	uint32_t		ifla_mtu;
-	char			*ifla_ifname;
-};
-
-#define	_IN(_field)	offsetof(struct ifinfomsg, _field)
-#define	_OUT(_field)	offsetof(struct nl_parsed_link, _field)
-static const struct snl_attr_parser ap_link[] = {
-	{ .type = IFLA_IFNAME, .off = _OUT(ifla_ifname), .cb = snl_attr_get_string },
-	{ .type = IFLA_MTU, .off = _OUT(ifla_mtu), .cb = snl_attr_get_uint32 },
-};
-static const struct snl_field_parser fp_link[] = {
-	{.off_in = _IN(ifi_index), .off_out = _OUT(ifi_index), .cb = snl_field_get_uint32 },
-};
-#undef _IN
-#undef _OUT
-SNL_DECLARE_PARSER(link_parser, struct ifinfomsg, fp_link, ap_link);
-
-
-int
-main(int ac, char *argv[])
-{
-	struct snl_state ss;
-
-	if (!snl_init(&ss, NETLINK_ROUTE))
-		return (1);
-
-	struct {
-		struct nlmsghdr hdr;
-		struct ifinfomsg ifmsg;
-	} msg = {
-		.hdr.nlmsg_type = RTM_GETLINK,
-		.hdr.nlmsg_flags = NLM_F_DUMP | NLM_F_REQUEST,
-		.hdr.nlmsg_seq = snl_get_seq(&ss),
-	};
-	msg.hdr.nlmsg_len = sizeof(msg);
-
-	if (!snl_send(&ss, &msg, sizeof(msg))) {
-		snl_free(&ss);
-		return (1);
-	}
-
-	struct nlmsghdr *hdr;
-	while ((hdr = snl_read_message(&ss)) != NULL && hdr->nlmsg_type != NLMSG_DONE) {
-		if (hdr->nlmsg_seq != msg.hdr.nlmsg_seq)
-			break;
-
-		struct nl_parsed_link link = {};
-		if (!snl_parse_nlmsg(&ss, hdr, &link_parser, &link))
-			continue;
-		printf("Link#%u %s mtu %u\n", link.ifi_index, link.ifla_ifname, link.ifla_mtu);
-	}
-
-	return (0);
-}
-
-
-
-

-

genetlink(4), netlink(4), and - rtnetlink(4)

-
-
-

-

The SNL library appeared in - FreeBSD 13.2.

-
-
-

-

This library was implemented by Alexander - Chernikov - <melifaro@FreeBSD.org>.

-
-
- - - - - -
December 16, 2022FreeBSD 15.0
diff --git a/static/freebsd/man3/stats.3 3.html b/static/freebsd/man3/stats.3 3.html deleted file mode 100644 index fb277eab..00000000 --- a/static/freebsd/man3/stats.3 3.html +++ /dev/null @@ -1,725 +0,0 @@ - - - - - - -
STATS(3)Library Functions ManualSTATS(3)
-
-
-

-

stats — statistics - gathering

-
-
-

-

library “libstats”

-
-
-

-

#include - <sys/arb.h> -
- #include <sys/qmath.h> -
- #include <sys/stats.h>

-
-

-

int -
- stats_tpl_alloc(const char - *name, uint32_t flags);

-

int -
- stats_tpl_fetch_allocid(const char - *name, uint32_t hash);

-

int -
- stats_tpl_fetch(int tpl_id, - struct statsblob_tpl **tpl);

-

int -
- stats_tpl_id2name(uint32_t - tpl_id, char *buf, size_t - len);

-

int -
- stats_tpl_sample_rates(SYSCTL_HANDLER_ARGS);

-

int -
- stats_tpl_sample_rollthedice(struct - stats_tpl_sample_rate *rates, int nrates, - void *seed_bytes, size_t - seed_len);

-

struct voistatspec -
- STATS_VSS_SUM();

-

struct voistatspec -
- STATS_VSS_MAX();

-

struct voistatspec -
- STATS_VSS_MIN();

-

struct voistatspec -
- STATS_VSS_CRHIST<32|64>_LIN(lb, - ub, stepinc, - vsdflags);

-

struct voistatspec -
- STATS_VSS_CRHIST<32|64>_EXP(lb, - ub, stepbase, - stepexp, vsdflags);

-

struct voistatspec -
- STATS_VSS_CRHIST<32|64>_LINEXP(lb, - ub, nlinsteps, - stepbase, vsdflags);

-

struct voistatspec -
- STATS_VSS_CRHIST<32|64>_USR(HBKTS((lb), - ...), vsdflags);

-

struct voistatspec -
- STATS_VSS_DRHIST<32|64>_USR(HBKTS((lb, - ), - ...), vsdflags);

-

struct voistatspec -
- STATS_VSS_DVHIST<32|64>_USR(HBKTS((), - ...), vsdflags);

-

struct voistatspec -
- STATS_VSS_TDGSTCLUST<32|64>(nctroids, - prec);

-

int -
- stats_tpl_add_voistats(uint32_t - tpl_id, int32_t voi_id, const - char *voi_name, enum vsd_dtype voi_dtype, - uint32_t nvss, struct voistatspec - *vss, uint32_t flags);

-
-
-

-

int -
- stats_voi_update_<abs|rel>_<dtype>(struct - statsblob *sb, int32_t voi_id, - <dtype> voival);

-
-
-

-

struct statsblob * -
- stats_blob_alloc(uint32_t - tpl_id, uint32_t flags);

-

int -
- stats_blob_init(struct statsblob - *sb, uint32_t tpl_id, uint32_t - flags);

-

int -
- stats_blob_clone(struct statsblob - **dst, size_t dstmaxsz, struct - statsblob *src, uint32_t flags);

-

void -
- stats_blob_destroy(struct statsblob - *sb);

-

int -
- stats_voistat_fetch_dptr(struct - statsblob *sb, int32_t voi_id, - enum voi_stype stype, enum vsd_dtype - *retdtype, struct voistatdata **retvsd, - size_t *retvsdsz);

-

int -
- stats_voistat_fetch_<dtype>(struct - statsblob *sb, int32_t voi_id, - enum voi_stype stype, <dtype> - *ret);

-

int -
- stats_blob_snapshot(struct statsblob - **dst, size_t dstmaxsz, struct - statsblob *src, uint32_t flags);

-

int -
- stats_blob_tostr(struct statsblob - *sb, struct sbuf *buf, enum - sb_str_fmt fmt, uint32_t flags);

-

int -
- stats_voistatdata_tostr(const struct - voistatdata *vsd, enum vsd_dtype dtype, - enum sb_str_fmt fmt, struct sbuf - *buf, int objdump);

-

typedef int -
- (*stats_blob_visitcb_t)(struct - sb_visit *sbv, void - *usrctx);

-

int -
- stats_blob_visit(struct statsblob - *sb, stats_blob_visitcb_t func, - void *usrctx);

-
-
-
-

-

The stats framework facilitates real-time - kernel and user space statistics gathering. The framework is built around - the “statsblob”, an object embedded within a contiguous memory - allocation that is mostly opaque to consumers and stores all required state. - A “statsblob” object can itself be embedded within other - objects either directly or indirectly using a pointer.

-

Objects or subsystems for which statistics are to be gathered are - initialized from a template “statsblob”, which acts as the - blueprint for an arbitrary set of Variables Of Interest (VOIs) and their - associated statistics. Each template defines a schema plus associated - metadata, which are kept separate to minimize the memory footprint of - blobs.

-

Data gathering hook functions added at appropriate locations - within the code base of interest feed VOI data into the framework for - processing.

-

Each “statsblob”, consists of a - struct statsblob header and opaque internal blob - structure per the following diagram:

-
-
---------------------------------------------------------
-|   struct  |		       uint8_t			|
-| statsblob |		      opaque[]			|
----------------------------------------------------------
-
-

The publicly visible 8-byte header is defined as:

-
-
struct statsblob {
-	uint8_t		abi;
-	uint8_t		endian;
-	uint16_t	flags;
-	uint16_t	maxsz;
-	uint16_t	cursz;
-	uint8_t		opaque[];
-};
-
-

abi specifies which API version the blob's - opaque internals conform to - (STATS_ABI_V1 is the only version currently - defined). endian specifies the endianness of - the blob's fields (SB_LE for little endian, - SB_BE for big endian, or - SB_UE for unknown endianness). - cursz specifies the size of the blob, while - maxsz specifies the size of the underlying memory - allocation in which the blob is embedded. Both cursz - and maxsz default to units of bytes, unless a flag is - set in flags that dictates otherwise.

-

Templates are constructed by associating arbitrary VOI IDs with a - set of statistics, where each statistic is specified using a - struct voistatspec per the definition below:

-
-
struct voistatspec {
-	vss_hlpr_fn		hlpr;
-	struct vss_hlpr_info	*hlprinfo;
-	struct voistatdata	*iv;
-	size_t			vsdsz;
-	uint32_t		flags;
-	enum vsd_dtype		vs_dtype : 8;
-	enum voi_stype		stype : 8;
-};
-
-

It is generally expected that consumers will not - work with struct voistatspec directly, and instead use - the - () - helper macros.

-

The stats framework offers the following - statistics for association with VOIs:

-
-
-
The sum of VOI values.
-
-
The maximum VOI value.
-
-
The minimum VOI value.
-
-
A static bucket histogram of VOI values, including a count of - “out-of-band/bucket” values which did not match any bucket. - Histograms can be specified as - “ontinuous - Range” (CRHIST), - “Discrete Range” - (DRHIST) or “Discrete - alue” - (DVHIST), with 32 or 64 bit bucket counters, depending on the VOI - semantics.
-
-
A dynamic bucket histogram of VOI values based on the t-digest method - (refer to the t-digest paper in the SEE - ALSO section below).
-
-

A “visitor software design pattern”-like scheme is - employed to facilitate iterating over a blob's data without concern for the - blob's structure. The data provided to visitor callback functions is - encapsulated in struct sb_visit per the definition - below:

-
-
struct sb_visit {
-	struct voistatdata	*vs_data;
-	uint32_t		tplhash;
-	uint32_t		flags;
-	int16_t			voi_id;
-	int16_t			vs_dsz;
-	enum vsd_dtype		voi_dtype : 8;
-	enum vsd_dtype		vs_dtype : 8;
-	int8_t			vs_stype;
-	uint16_t		vs_errs;
-};
-
-

The - () - and stats_tpl_sample_rollthedice() functions utilize - struct stats_tpl_sample_rate to encapsulate - per-template sample rate information per the definition below:

-
-
struct stats_tpl_sample_rate {
-	int32_t		tpl_slot_id;
-	uint32_t	tpl_sample_pct;
-};
-
-

The tpl_slot_id member - holds the template's slot ID obtained from - () - or stats_tpl_fetch_allocid(). The - tpl_sample_pct member holds the template's sample rate - as an integer percentage in the range [0,100].

-

The - stats_tpl_sr_cb_t conformant function pointer that is - required as the arg1 of - () - is defined as:

-
-
enum stats_tpl_sr_cb_action {
-	TPL_SR_UNLOCKED_GET,
-	TPL_SR_RLOCKED_GET,
-	TPL_SR_RUNLOCK,
-	TPL_SR_PUT
-};
-typedef int (*stats_tpl_sr_cb_t)(enum stats_tpl_sr_cb_action action,
-    struct stats_tpl_sample_rate **rates, int *nrates, void *ctx);
-
-

It is required that a conformant function:

-
    -
  • Return an appropriate errno(2) on error, otherwise - 0.
    • -
  • When called with "action == TPL_SR_*_GET", return the - subsystem's rates list ptr and count, locked or unlocked as - requested.
    • -
  • When called with "action == TPL_SR_RUNLOCK", unlock the - subsystem's rates list ptr and count. Pair with a prior "action == - TPL_SR_RLOCKED_GET" call.
    • -
  • When called with "action == - TPL_SR_PUT", update the subsystem's rates list ptr and count to the - sysctl processed values and return the inactive list details in - rates and nrates for garbage - collection by - ().
    • -
-

Where templates need to be referenced via textual means, for - example via a MIB variable, the following string based template spec formats - can be used:

-
    -
  1. "<tplname>":<tplhash>, for example - "TCP_DEFAULT":1731235399
    2. -
  2. "<tplname>", for example "TCP_DEFAULT"
    3. -
  3. :<tplhash>, for example :1731235399
    4. -
-

The first form is the normative spec format generated by the - framework, while the second and third forms are convenience formats - primarily for user input. The use of inverted commas around the template - name is optional.

-
-

-

The in-kernel stats framework exposes the - following framework-specific variables in the - kern.stats branch of the sysctl(3) - MIB.

-
-
templates
-
Read-only CSV list of registered templates in normative template spec - form.
-
-
-
-

-

The - () - function allocates a new template with the specified unique name and returns - its runtime-stable template slot ID for use with other API functions. The - flags argument is currently unused.

-

The - () - function returns the runtime-stable template slot ID of any registered - template matching the specified name and hash.

-

The - () - function returns the pointer to the registered template object at the - specified template slot ID.

-

The - () - function returns the name of the registered template object at the specified - template slot ID.

-

The - () - function provides a generic handler for template sample rates management and - reporting via sysctl(3) MIB variables. Subsystems can use - this function to create a subsystem-specific - SYSCTL_PROC(9) MIB variable that manages and reports - subsystem-specific template sampling rates. Subsystems must supply a - stats_tpl_sr_cb_t conformant function pointer as the - sysctl's arg1, which is a callback used to interact - with the subsystem's stats template sample rates list. Subsystems can - optionally specify the sysctl's arg2 as non-zero, - which causes a zero-initialized allocation of arg2-sized contextual memory - to be heap-allocated and passed in to all subsystem callbacks made during - the operation of stats_tpl_sample_rates().

-

The - () - function makes a weighted random template selection from the supplied array - of template sampling rates. The cumulative percentage of all sampling rates - should not exceed 100. If no seed is supplied, a PRNG is used to generate a - true random number so that every selection is independent. If a seed is - supplied, selection will be made randomly across different seeds, but - deterministically given the same seed.

-

The - () - function is used to add a VOI and associated set of statistics to the - registered template object at the specified template slot ID. The set of - statistics is passed as an array of struct voistatspec - which can be initialized using the STATS_VSS_*() - helper macros or manually for non-standard use cases. For static - vss arrays, the nvss count of - array elements can be determined by passing vss to the - () - macro. The SB_VOI_RELUPDATE flag can be passed to - configure the VOI for use with - (), - which entails maintaining an extra 8 bytes of state in the blob at each - update.

-
-
-

-

The - () - and stats_voi_update_rel_<dtype>() functions - both update all the statistics associated with the VOI identified by - voi_id. The “abs” call uses - voival as an absolute value, whereas the - “rel” call uses voival as a value - relative to that of the previous update function call, by adding it to the - previous value and using the result for the update. Relative updates are - only possible for VOIs that were added to the template with the - SB_VOI_RELUPDATE flag specified to - stats_tpl_add_voistats().

-
-
-

-

The stats_blob_alloc() function allocates - and initializes a new blob based on the registered template object at the - specified template slot ID.

-

The - () - function initializes a new blob in an existing memory allocation based on - the registered template object at the specified template slot ID.

-

The - () - function duplicates the src blob into - dst, leaving only the maxsz - field of dst untouched. The - SB_CLONE_ALLOCDST flag can be passed to instruct the - function to allocate a new blob of appropriate size into which to clone - src, storing the new pointer in - *dst. The - SB_CLONE_USRDSTNOFAULT or - SB_CLONE_USRDST flags can be set to respectively - signal that copyout_nofault(9) or - copyout(9) should be used because - *dst is a user space address.

-

The - () - function calls stats_blob_clone() to obtain a copy - of src and then performs any additional functions - required to produce a coherent blob snapshot. The flags interpreted by - stats_blob_clone() also apply to - stats_blob_snapshot(). Additionally, the - SB_CLONE_RSTSRC flag can be used to effect a reset - of the src blob's statistics after a snapshot is - successfully taken.

-

The - () - function destroys a blob previously created with - (), - stats_blob_clone() or - stats_blob_snapshot().

-

The - () - function allows the caller to iterate over the contents of a blob. The - callback function func is called for every VOI and - statistic in the blob, passing a struct sb_visit and - the user context argument usrctx to the callback - function. The sbv passed to the callback function may - have one or more of the following flags set in the - flags struct member to provide useful metadata about - the iteration: SB_IT_FIRST_CB, - SB_IT_LAST_CB, - SB_IT_FIRST_VOI, - SB_IT_LAST_VOI, - SB_IT_FIRST_VOISTAT, - SB_IT_LAST_VOISTAT, - SB_IT_NULLVOI and - SB_IT_NULLVOISTAT. Returning a non-zero value from - the callback function terminates the iteration.

-

The - () - renders a string representation of a blob into the sbuf(9) - buf. Currently supported render formats are - SB_STRFMT_FREEFORM and - SB_STRFMT_JSON. The - SB_TOSTR_OBJDUMP flag can be passed to render - version specific opaque implementation detail for debugging or - string-to-binary blob reconstruction purposes. The - SB_TOSTR_META flag can be passed to render template - metadata into the string representation, using the blob's template hash to - lookup the corresponding template.

-

The - () - renders a string representation of an individual statistic's data into the - sbuf(9) buf. The same render formats - supported by the stats_blob_tostr() function can be - specified, and the objdump boolean has the same - meaning as the SB_TOSTR_OBJDUMP flag.

-

The - () - function returns an internal blob pointer to the specified - stype statistic data for the VOI - voi_id. The - () - functions are convenience wrappers around - stats_voistat_fetch_dptr() to perform the extraction - for simple data types.

-
-
-
-

-

The following notes apply to STATS_ABI_V1 format statsblobs.

-
-

-

Blobs are laid out as three distinct memory regions following the - header:

-
-
------------------------------------------------------
-|   struct    | struct |   struct   |     struct     |
-| statsblobv1 | voi [] | voistat [] | voistatdata [] |
-------------------------------------------------------
-
-

Blobs store VOI and statistic blob state (8 bytes for - struct voi and 8 bytes for struct - voistat respectively) in sparse arrays, using the - voi_id and enum voi_stype as - array indices. This allows O(1) access to any voi/voistat pair in the blob, - at the expense of 8 bytes of wasted memory per vacant slot for templates - which do not specify contiguously numbered VOIs and/or statistic types. Data - storage for statistics is only allocated for non-vacant slot pairs.

-

To provide a concrete example, a blob with the following - specification:

-
    -
  • Two VOIs; ID 0 and 2; added to the template in that order
    • -
  • VOI 0 is of data type int64_t, is configured with - SB_VOI_RELUPDATE to enable support for relative - updates using - stats_voi_update_rel_<dtype>(), and has a - VS_STYPE_MIN statistic associated with it.
    • -
  • VOI 2 is of data type uint32_t with - VS_STYPE_SUM and - VS_STYPE_MAX statistics associated with it.
    • -
-

would have the following memory layout:

-
-
--------------------------------------
-| header			     | struct statsblobv1, 32 bytes
-|------------------------------------|
-| voi[0]			     | struct voi, 8 bytes
-| voi[1] (vacant)		     | struct voi, 8 bytes
-| voi[2]			     | struct voi, 8 bytes
-|------------------------------------|
-| voi[2]voistat[VOISTATE] (vacant)   | struct voistat, 8 bytes
-| voi[2]voistat[SUM]		     | struct voistat, 8 bytes
-| voi[2]voistat[MAX]		     | struct voistat, 8 bytes
-| voi[0]voistat[VOISTATE]	     | struct voistat, 8 bytes
-| voi[0]voistat[SUM] (vacant)	     | struct voistat, 8 bytes
-| voi[0]voistat[MAX] (vacant)	     | struct voistat, 8 bytes
-| voi[0]voistat[MIN]		     | struct voistat, 8 bytes
-|------------------------------------|
-| voi[2]voistat[SUM]voistatdata      | struct voistatdata_int32, 4 bytes
-| voi[2]voistat[MAX]voistatdata      | struct voistatdata_int32, 4 bytes
-| voi[0]voistat[VOISTATE]voistatdata | struct voistatdata_numeric, 8 bytes
-| voi[0]voistat[MIN]voistatdata      | struct voistatdata_int64, 8 bytes
---------------------------------------
-				       TOTAL 136 bytes
-
-

When rendered to string format using - stats_blob_tostr(), the - SB_STRFMT_FREEFORM fmt and the - SB_TOSTR_OBJDUMP flag, the rendered output is:

-
-
struct statsblobv1@0x8016250a0, abi=1, endian=1, maxsz=136, cursz=136, \
-  created=6294158585626144, lastrst=6294158585626144, flags=0x0000, \
-  stats_off=56, statsdata_off=112, tplhash=2994056564
-    vois[0]: id=0, name="", flags=0x0001, dtype=INT_S64, voistatmaxid=3, \
-      stats_off=80
-        vois[0]stat[0]: stype=VOISTATE, flags=0x0000, dtype=VOISTATE, \
-          dsz=8, data_off=120
-            voistatdata: prev=0
-        vois[0]stat[1]: stype=-1
-        vois[0]stat[2]: stype=-1
-        vois[0]stat[3]: stype=MIN, flags=0x0000, dtype=INT_S64, \
-          dsz=8, data_off=128
-            voistatdata: 9223372036854775807
-    vois[1]: id=-1
-    vois[2]: id=2, name="", flags=0x0000, dtype=INT_U32, voistatmaxid=2, \
-      stats_off=56
-        vois[2]stat[0]: stype=-1
-        vois[2]stat[1]: stype=SUM, flags=0x0000, dtype=INT_U32, dsz=4, \
-          data_off=112
-            voistatdata: 0
-        vois[2]stat[2]: stype=MAX, flags=0x0000, dtype=INT_U32, dsz=4, \
-          data_off=116
-            voistatdata: 0
-
-

Note: The "\" present in the rendered output above - indicates a manual line break inserted to keep the man page within 80 - columns and is not part of the actual output.

-
-
-

-

The stats framework does not provide any - concurrency protection at the individual blob level, instead requiring that - consumers guarantee mutual exclusion when calling API functions that - reference a non-template blob.

-

The list of templates is protected with a - rwlock(9) in-kernel, and pthread(3) rw - lock in user space to support concurrency between template management and - blob initialization operations.

-
-
-
-

-

stats_tpl_alloc() returns a runtime-stable - template slot ID on success, or a negative errno on failure. -EINVAL is - returned if any problems are detected with the arguments. -EEXIST is - returned if an existing template is registered with the same name. -ENOMEM - is returned if a required memory allocation fails.

-

stats_tpl_fetch_allocid() returns a - runtime-stable template slot ID, or negative errno on failure. -ESRCH is - returned if no registered template matches the specified name and/or - hash.

-

stats_tpl_fetch() returns 0 on success, or - ENOENT if an invalid tpl_id is specified.

-

stats_tpl_id2name() returns 0 on success, - or an errno on failure. EOVERFLOW is returned if the length of - buf specified by len is too - short to hold the template's name. ENOENT is returned if an invalid - tpl_id is specified.

-

stats_tpl_sample_rollthedice() returns a - valid template slot id selected from rates or -1 if a - NULL selection was made, that is no stats collection this roll.

-

stats_tpl_add_voistats() return 0 on - success, or an errno on failure. EINVAL is returned if any problems are - detected with the arguments. EFBIG is returned if the resulting blob would - have exceeded the maximum size. EOPNOTSUPP is returned if an attempt is made - to add more VOI stats to a previously configured VOI. ENOMEM is returned if - a required memory allocation fails.

-

stats_voi_update_abs_<dtype>() and - stats_voi_update_rel_<dtype>() return 0 on - success, or EINVAL if any problems are detected with the arguments.

-

stats_blob_init() returns 0 on success, or - an errno on failure. EINVAL is returned if any problems are detected with - the arguments. EOVERFLOW is returned if the template blob's - cursz is larger than the maxsz - of the blob being initialized.

-

stats_blob_alloc() returns a pointer to a - newly allocated and initialized blob based on the specified template with - slot ID tpl_id, or NULL if the memory allocation - failed.

-

stats_blob_clone() and - stats_blob_snapshot() return 0 on success, or an - errno on failure. EINVAL is returned if any problems are detected with the - arguments. ENOMEM is returned if the SB_CLONE_ALLOCDST flag was specified - and the memory allocation for dst fails. EOVERFLOW is - returned if the src blob's cursz is larger than the - maxsz of the dst blob.

-

stats_blob_visit() returns 0 on success, - or EINVAL if any problems are detected with the arguments.

-

stats_blob_tostr() and - stats_voistatdata_tostr() return 0 on success, or an - errno on failure. EINVAL is returned if any problems are detected with the - arguments, otherwise any error returned by - sbuf_error() for buf is - returned.

-

stats_voistat_fetch_dptr() returns 0 on - success, or EINVAL if any problems are detected with the arguments.

-

stats_voistat_fetch_<dtype>() - returns 0 on success, or an errno on failure. EINVAL is returned if any - problems are detected with the arguments. EFTYPE is returned if the - requested data type does not match the blob's data type for the specified - voi_id and stype.

-
-
-

-

errno(2), arb(3), - qmath(3), tcp(4), - sbuf(9)

-

Ted Dunning and - Otmar Ertl, Computing Extremely - Accurate Quantiles Using t-digests, - https://github.com/tdunning/t-digest/raw/master/docs/t-digest-paper/histo.pdf.

-
-
-

-

The stats framework first appeared in - FreeBSD 13.0.

-
-
-

-

The stats framework and this manual page - were written by Lawrence Stewart - ⟨lstewart@FreeBSD.org⟩ and sponsored by Netflix, Inc.

-
-
-

-

Granularity of timing-dependent network statistics, in particular - TCP_RTT, depends on the HZ timer. To minimize the - measurement error avoid using HZ lower than 1000.

-
-
- - - - - -
December 2, 2019FreeBSD 15.0
diff --git a/static/freebsd/man3/stdarg.3 3.html b/static/freebsd/man3/stdarg.3 3.html deleted file mode 100644 index 287f235a..00000000 --- a/static/freebsd/man3/stdarg.3 3.html +++ /dev/null @@ -1,182 +0,0 @@ - - - - - - -
STDARG(3)Library Functions ManualSTDARG(3)
-
-
-

-

stdarg — variable - argument lists

-
-
-

-

#include - <stdarg.h>

-

void -
- va_start(va_list - ap, last);

-

type -
- va_arg(va_list - ap, type);

-

void -
- va_copy(va_list - dest, va_list - src);

-

void -
- va_end(va_list - ap);

-
-
-

-

A function may be called with a varying number of arguments of - varying types. The include file - <stdarg.h> declares a type - (va_list) and defines four macros for stepping through a - list of arguments whose number and types are not known to the called - function.

-

The called function must declare an object of type - va_list which is used by the macros - (), - va_arg(), va_copy(), and - va_end().

-

The - () - macro initializes ap for subsequent use by - va_arg(), va_copy(), and - va_end(), and must be called first.

-

The parameter last is the name of the last - parameter before the variable argument list, i.e., the last parameter of - which the calling function knows the type.

-

Because the address of this parameter is used in - the - () - macro, it should not be declared as a register variable, or as a function or - an array type.

-

The - () - macro expands to an expression that has the type and value of the next - argument in the call. The parameter ap is the - va_list ap initialized by - va_start() or va_copy(). - Each call to va_arg() modifies - ap so that the next call returns the next argument. - The parameter type is a type name specified so that - the type of a pointer to an object that has the specified type can be - obtained simply by adding a * to type.

-

If there is no next argument, or if type is - not compatible with the type of the actual next argument (as promoted - according to the default argument promotions), random errors will occur.

-

The first use of the - () - macro after that of the va_start() macro returns the - argument after last. Successive invocations return the - values of the remaining arguments.

-

The - () - macro copies a variable argument list, previously initialized by - va_start(), from src to - dest. The state is preserved such that it is - equivalent to calling va_start() with the same - second argument used with src, and calling - va_arg() the same number of times as called with - src.

-

The - () - macro cleans up any state associated with the variable argument list - ap.

-

Each invocation of - () - or va_copy() must be paired with a corresponding - invocation of va_end() in the same function.

-
-
-

-

The va_arg() macro returns the value of - the next argument.

-

The va_start(), - va_copy(), and va_end() - macros return no value.

-
-
-

-

The function - takes a - string of format characters and prints out the argument associated with each - format character based on the type.

-
-
void foo(char *fmt, ...)
-{
-	va_list ap;
-	int d;
-	char c, *s;
-
-	va_start(ap, fmt);
-	while (*fmt)
-		switch(*fmt++) {
-		case 's':			/* string */
-			s = va_arg(ap, char *);
-			printf("string %s\n", s);
-			break;
-		case 'd':			/* int */
-			d = va_arg(ap, int);
-			printf("int %d\n", d);
-			break;
-		case 'c':			/* char */
-			/* Note: char is promoted to int. */
-			c = va_arg(ap, int);
-			printf("char %c\n", c);
-			break;
-		}
-	va_end(ap);
-}
-
-
-
-

-

These macros are - - compatible with the historic macros they replace.

-
-
-

-

The va_start(), - va_arg(), va_copy(), and - va_end() macros conform to ISO/IEC - 9899:1999 (“ISO C99”).

-
-
-

-

The va_start(), - va_arg() and va_end() macros - were introduced in ANSI X3.159-1989 - (“ANSI C89”). The - va_copy() macro was introduced in - ISO/IEC 9899:1999 - (“ISO C99”).

-
-
-

-

Unlike the varargs macros, the - stdarg macros do not permit programmers to code a - function with no fixed arguments. This problem generates work mainly when - converting varargs code to stdarg - code, but it also creates difficulties for variadic functions that wish to - pass all of their arguments on to a function that takes a - va_list argument, such as - vfprintf(3).

-
-
- - - - - -
October 18, 2024FreeBSD 15.0
diff --git a/static/freebsd/man3/stdbit.3 4.html b/static/freebsd/man3/stdbit.3 4.html deleted file mode 100644 index d2ae955c..00000000 --- a/static/freebsd/man3/stdbit.3 4.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - -
STDBIT(3)Library Functions ManualSTDBIT(3)
-
-
-

-

stdbit — bit and - byte utilities

-
-
-

-

Standard C Library (libc, -lc) -
- #include <stdbit.h>

-

#define __STDC_ENDIAN_LITTLE__ -
- #define __STDC_ENDIAN_BIG__ -
- #define __STDC_ENDIAN_NATIVE__

-

unsigned int -
- stdc_count_leading_zeros(value);

-

unsigned int -
- stdc_count_leading_ones(value);

-

unsigned int -
- stdc_count_trailing_zeros(value);

-

unsigned int -
- stdc_count_trailing_ones(value);

-

unsigned int -
- stdc_first_leading_zero(value);

-

unsigned int -
- stdc_first_leading_one(value);

-

unsigned int -
- stdc_first_trailing_zero(value);

-

unsigned int -
- stdc_first_trailing_one(value);

-

unsigned int -
- stdc_count_zeros(value);

-

unsigned int -
- stdc_count_ones(value);

-

bool -
- stdc_has_single_bit(value);

-

unsigned int -
- stdc_bit_width(value);

-

typeof(value) -
- stdc_bit_floor(value);

-

typeof(value) -
- stdc_bit_ceil(value);

-
-
-

-

The __STDC_ENDIAN_NATIVE__ macro describes - the byte order or endianness of the machine for which the program is built. - If the machine has big-endian byte order, this macro is equal to - __STDC_ENDIAN_BIG__. If the machine has - little-endian byte order, this macro is equal to - __STDC_ENDIAN_LITTLE__. Otherwise, the macro has a - value that is equal to neither.

-

The bit and byte utility functions analyze the bits within - a datum. Each function func is provided in five variants - stdc_func_type(value) - where value is of type unsigned - char, unsigned short, unsigned - int, unsigned long, or unsigned - long long for type being - , - , - , - , or - - respectively. Additionally, for each func, a type-generic - macro - stdc_func(value) - that picks the appropriate function - stdc_func_type(value) - based on the type of value is provided.

-
-
-

-

arch(7), bitstring(3), - ffs(3), fls(3), - stdc_count_leading_zeros(3), - stdc_count_leading_ones(3), - stdc_count_trailing_zeros(3), - stdc_count_trailing_ones(3), - stdc_first_leading_zero(3), - stdc_first_leading_one(3), - stdc_first_trailing_zero(3), - stdc_first_trailing_one(3), - stdc_count_zeros(3), stdc_count_ones(3), - stdc_has_single_bit(3), - stdc_bit_width(3), stdc_bit_floor(3), - stdc_bit_ceil(3)

-
-
-

-

The macros and functions of the - <stdbit.h> header conform - to.

-
-
-

-

The <stdbit.h> - header and the macros and functions defined therein where added in - FreeBSD 15.1.

-
-
-

-

Robert Clausecker - <fuz@FreeBSD.org>

-
-
- - - - - -
November 9, 2025FreeBSD 15.0
diff --git a/static/freebsd/man3/stdckdint.3 3.html b/static/freebsd/man3/stdckdint.3 3.html deleted file mode 100644 index 5434f16e..00000000 --- a/static/freebsd/man3/stdckdint.3 3.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - -
STDCKDINT(3)Library Functions ManualSTDCKDINT(3)
-
-
-

-

stdckdint — - checked integer arithmetic

-
-
-

-

#include - <stdckdint.h>

-

bool -
- ckd_add(type1 - *result, type2 a, - type3 b);

-

bool -
- ckd_sub(type1 - *result, type2 a, - type3 b);

-

bool -
- ckd_mul(type1 - *result, type2 a, - type3 b);

-
-
-

-

The function-like macros ckd_add, - ckd_sub, and ckd_mul perform - checked integer addition, subtraction, and multiplication, respectively. If - the result of adding, subtracting, or multiplying a - and b as if their respective types had infinite range - fits in type1, it is stored in the location pointed to - by result and the macro evaluates to - false. Otherwise, the macro evaluates to - true and the contents of the location pointed to by - result is the result of the operation wrapped to the - range of type1.

-
-
-

-

The ckd_add, - ckd_sub, and ckd_mul macros - evaluate to true if the requested operation - overflowed the result type and false otherwise.

-
-
-

-
-
#include <assert.h>
-#include <limits.h>
-#include <stdckdint.h>
-
-int main(void)
-{
-	int result;
-
-	assert(!ckd_add(&result, INT_MAX, 0));
-	assert(result == INT_MAX);
-	assert(ckd_add(&result, INT_MAX, 1));
-	assert(result == INT_MIN);
-
-	assert(!ckd_sub(&result, INT_MIN, 0));
-	assert(result == INT_MIN);
-	assert(ckd_sub(&result, INT_MIN, 1));
-	assert(result == INT_MAX);
-
-	assert(!ckd_mul(&result, INT_MAX / 2, 2));
-	assert(result == INT_MAX - 1);
-	assert(ckd_mul(&result, INT_MAX / 2 + 1, 2));
-	assert(result == INT_MIN);
-
-	return 0;
-}
-
-
-
-

-

The ckd_add, - ckd_sub, and ckd_mul macros - were first introduced in FreeBSD 14.0.

-
-
-

-

The ckd_add, - ckd_sub, and ckd_mul macros - and this manual page were written by Dag-Erling - Smørgrav - <des@FreeBSD.org>.

-
-
- - - - - -
September 5, 2023FreeBSD 15.0
diff --git a/static/freebsd/man3/sysexits.3 3.html b/static/freebsd/man3/sysexits.3 3.html deleted file mode 100644 index 3991825f..00000000 --- a/static/freebsd/man3/sysexits.3 3.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - -
SYSEXITS(3)Library Functions ManualSYSEXITS(3)
-
-
-

-

sysexits — legacy - exit status codes for system programs

-
-
-

-

#include - <sysexits.h>

-
-
-

-

Some commands attempt to describe the nature of a failure - condition by using these pre-defined exit codes. This interface has been - deprecated and is retained only for compatibility. Its use is - discouraged.

-
-
-

-

The successful exit is always indicated by a status of 0, or - . - Error numbers begin at - - to reduce the possibility of clashing with other exit statuses that random - programs may already return. The meaning of the codes is approximately as - follows:

-
-
- (64)
-
The command was used incorrectly, e.g., with the wrong number of - arguments, a bad flag, a bad syntax in a parameter, or whatever.
-
- (65)
-
The input data was incorrect in some way. This should only be used for - user's data and not system files.
-
- (66)
-
An input file (not a system file) did not exist or was not readable. This - could also include errors like “No message” to a mailer (if - it cared to catch it).
-
- (67)
-
The user specified did not exist. This might be used for mail addresses or - remote logins.
-
- (68)
-
The host specified did not exist. This is used in mail addresses or - network requests.
-
- (69)
-
A service is unavailable. This can occur if a support program or file does - not exist. This can also be used as a catchall message when something you - wanted to do does not work, but you do not know why.
-
- (70)
-
An internal software error has been detected. This should be limited to - non-operating system related errors as possible.
-
- (71)
-
An operating system error has been detected. This is intended to be used - for such things as “cannot fork”, “cannot create - pipe”, or the like. It includes things like getuid returning a user - that does not exist in the passwd file.
-
- (72)
-
Some system file (e.g., /etc/passwd, - /var/run/utx.active, etc.) does not exist, cannot - be opened, or has some sort of error (e.g., syntax error).
-
- (73)
-
A (user specified) output file cannot be created.
-
- (74)
-
An error occurred while doing I/O on some file.
-
- (75)
-
Temporary failure, indicating something that is not really an error. In - sendmail, this means that a mailer (e.g.) could not create a connection, - and the request should be reattempted later.
-
- (76)
-
The remote system returned something that was “not possible” - during a protocol exchange.
-
- (77)
-
You did not have sufficient permission to perform the operation. This is - not intended for file system problems, which should use - EX_NOINPUT or EX_CANTCREAT, but rather - for higher level permissions.
-
- (78)
-
Something was found in an unconfigured or misconfigured state.
-
-

The numerical values corresponding to the symbolical ones are - given in parenthesis for easy reference.

-
-
-

-

err(3), exit(3), - style(9)

-
-
-

-

The sysexits file first appeared in - 4BSD.

-
-
-

-

This manual page was written by Jörg - Wunsch.

-
-
-

-
-
This interface is not portable.
-
 
-
The choice of an appropriate exit value is often ambiguous.
-
 
-
-
-
- - - - - -
May 9, 2024FreeBSD 15.0
diff --git a/static/freebsd/man3/tgmath.3 3.html b/static/freebsd/man3/tgmath.3 3.html deleted file mode 100644 index 095cff0f..00000000 --- a/static/freebsd/man3/tgmath.3 3.html +++ /dev/null @@ -1,262 +0,0 @@ - - - - - - -
TGMATH(3)Library Functions ManualTGMATH(3)
-
-
-

-

tgmath — - type-generic macros

-
-
-

-

#include - <tgmath.h>

-
-
-

-

The header - <tgmath.h> provides - type-generic macros for - <math.h> and - <complex.h> functions that - have float (suffixed with - ), - double and long double (suffixed - with ) - versions. The arguments that vary across the three functions and have type - float, double and - long double, respectively, are called - .

-

The following rules describe which function is actually called if - a type-generic macro is invoked. If any generic argument has type - long double or long double - complex, the long double function is called. - Else, if any generic argument has type double, - double complex or an integer type, the - double version is invoked. Otherwise, the macro - expands to the float implementation.

-

For the macros in the following table, both real and complex - functions exist. The real functions are prototyped in - <math.h> and the complex - equivalents in <complex.h>. - The complex function is called if any of the generic arguments is a complex - value. Otherwise, the real equivalent is called.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
()acos()()
()asin()()
()atan()()
()acosh()()
()asinh()()
()atanh()()
()cos()()
()sin()()
()tan()()
()cosh()()
()sinh()()
()tanh()()
()exp()()
()log()()
()pow()()
()sqrt()()
()fabs()()
-

No complex functions exist for the following macros, so passing a - complex value to a generic argument invokes undefined behaviour:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
()()()()
()()()()
()()()()
()()()()
()()()()
()()()()
()()()()
()()()()
()()()
()()()
-

The following macros always expand to a complex function:

- - - - - - - - -
()()()()()
-

This header includes - <complex.h> and - <math.h>.

-
-
-

-

The header - <tgmath.h> conforms to - ISO/IEC 9899:1999 - (“ISO C99”).

-
-
-

-

The header - <tgmath.h> first appeared in - FreeBSD 5.3.

-
-
-

-

Before ISO/IEC 9899:2011 - (“ISO C11”), the header - <tgmath.h> could not be - implemented with strictly conforming C code and needed special compiler - support. As of ISO/IEC 9899:2011 - (“ISO C11”), this header file can be implemented - using the - () - language keyword. In addition to compilers that support this keyword, this - header file works with GCC.

-
-
-

-

Many of the functions mentioned here are not prototyped in - <math.h> or - <complex.h> as they are not - yet implemented. This prevents the corresponding type-generic macro from - working at all.

-
-
- - - - - -
January 4, 2012FreeBSD 15.0
diff --git a/static/freebsd/man3/timeradd.3 4.html b/static/freebsd/man3/timeradd.3 4.html deleted file mode 100644 index bdce73ed..00000000 --- a/static/freebsd/man3/timeradd.3 4.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - -
TIMERADD(3)Library Functions ManualTIMERADD(3)
-
-
-

-

timeradd, - timersub, timerclear, - timerisset, timercmp, - timespecadd, timespecsub, - timespecclear, - timespecisset, timespeccmp - — operations on timevals and timespecs

-
-
-

-

#include - <sys/time.h>

-

void -
- timeradd(struct - timeval *a, struct - timeval *b, struct - timeval *res);

-

void -
- timersub(struct - timeval *a, struct - timeval *b, struct - timeval *res);

-

void -
- timerclear(struct - timeval *tvp);

-

int -
- timerisset(struct - timeval *tvp);

-

int -
- timercmp(struct - timeval *a, struct - timeval *b, - CMP);

-

void -
- timespecadd(struct - timespec *a, struct - timespec *b, struct - timespec *res);

-

void -
- timespecsub(struct - timespec *a, struct - timespec *b, struct - timespec *res);

-

void -
- timespecclear(struct - timespec *ts);

-

int -
- timespecisset(struct - timespec *ts);

-

int -
- timespeccmp(struct - timespec *a, struct - timespec *b, - CMP);

-
-
-

-

These macros are provided for manipulating - timeval and timespec structures - for use with the clock_gettime(2), - clock_settime(2), gettimeofday(2) and - settimeofday(2) calls. The timeval - structure is defined in - <sys/time.h> as:

-
-
struct timeval {
-	long	tv_sec;		/* seconds since Jan. 1, 1970 */
-	long	tv_usec;	/* and microseconds */
-};
-
-

And the timespec structure is defined in - <time.h> as:

-
-
struct timespec {
-	time_t tv_sec;		/* seconds */
-	long   tv_nsec;		/* and nanoseconds */
-};
-
-

() - and - () - add the time information stored in a to - b and store the result in res. - The results are simplified such that the value of - res->tv_usec or - res->tv_nsec is always less than 1 second.

-

() - and - () - subtract the time information stored in b from - a and store the result in - res.

-

() - and - () - initialize their argument to midnight (0 hour) January 1st, 1970 (the - Epoch).

-

() - and - () - return true if their argument is set to any time value other than the - Epoch.

-

() - and - () - compare a to b using the - comparison operator given in CMP, and return the - result of that comparison.

-
-
-

-

clock_gettime(2), - gettimeofday(2)

-
-
-

-

The timeradd() family of macros were - imported from NetBSD 1.1, and appeared in - FreeBSD 2.2.6. The - timespecadd() family of macros were imported from - NetBSD 1.3 into FreeBSD 3.0, - though they were not exposed to userland until FreeBSD - 12.0.

-
-
- - - - - -
July 30, 2018FreeBSD 15.0
diff --git a/static/freebsd/man3/tree.3 3.html b/static/freebsd/man3/tree.3 3.html deleted file mode 100644 index 547c060d..00000000 --- a/static/freebsd/man3/tree.3 3.html +++ /dev/null @@ -1,818 +0,0 @@ - - - - - - -
TREE(3)Library Functions ManualTREE(3)
-
-
-

-

SPLAY_PROTOTYPE, - SPLAY_GENERATE, SPLAY_ENTRY, - SPLAY_HEAD, - SPLAY_INITIALIZER, - SPLAY_ROOT, SPLAY_EMPTY, - SPLAY_NEXT, SPLAY_MIN, - SPLAY_MAX, SPLAY_FIND, - SPLAY_LEFT, SPLAY_RIGHT, - SPLAY_FOREACH, SPLAY_INIT, - SPLAY_INSERT, SPLAY_REMOVE, - RB_PROTOTYPE, - RB_PROTOTYPE_STATIC, - RB_PROTOTYPE_INSERT, - RB_PROTOTYPE_INSERT_COLOR, - RB_PROTOTYPE_REMOVE, - RB_PROTOTYPE_REMOVE_COLOR, - RB_PROTOTYPE_FIND, - RB_PROTOTYPE_NFIND, - RB_PROTOTYPE_NEXT, - RB_PROTOTYPE_PREV, - RB_PROTOTYPE_MINMAX, - RB_PROTOTYPE_REINSERT, - RB_GENERATE, - RB_GENERATE_STATIC, - RB_GENERATE_INSERT, - RB_GENERATE_INSERT_COLOR, - RB_GENERATE_REMOVE, - RB_GENERATE_REMOVE_COLOR, - RB_GENERATE_FIND, - RB_GENERATE_NFIND, - RB_GENERATE_NEXT, - RB_GENERATE_PREV, - RB_GENERATE_MINMAX, - RB_GENERATE_REINSERT, - RB_ENTRY, RB_HEAD, - RB_INITIALIZER, RB_ROOT, - RB_EMPTY, RB_NEXT, - RB_PREV, RB_MIN, - RB_MAX, RB_FIND, - RB_NFIND, RB_LEFT, - RB_RIGHT, RB_PARENT, - RB_FOREACH, RB_FOREACH_FROM, - RB_FOREACH_SAFE, - RB_FOREACH_REVERSE, - RB_FOREACH_REVERSE_FROM, - RB_FOREACH_REVERSE_SAFE, - RB_INIT, RB_INSERT, - RB_INSERT_NEXT, - RB_INSERT_PREV, RB_REMOVE, - RB_REINSERT, RB_AUGMENT - RB_AUGMENT_CHECK, - RB_UPDATE_AUGMENT — - implementations of splay and rank-balanced (wavl) - trees

-
-
-

-

#include - <sys/tree.h>

-

SPLAY_PROTOTYPE(NAME, - TYPE, - FIELD, - CMP);

-

SPLAY_GENERATE(NAME, - TYPE, - FIELD, - CMP);

-

SPLAY_ENTRY(TYPE);

-

SPLAY_HEAD(HEADNAME, - TYPE);

-

struct TYPE * -
- SPLAY_INITIALIZER(SPLAY_HEAD - *head);

-

SPLAY_ROOT(SPLAY_HEAD - *head);

-

bool -
- SPLAY_EMPTY(SPLAY_HEAD - *head);

-

struct TYPE * -
- SPLAY_NEXT(NAME, - SPLAY_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- SPLAY_MIN(NAME, - SPLAY_HEAD *head);

-

struct TYPE * -
- SPLAY_MAX(NAME, - SPLAY_HEAD *head);

-

struct TYPE * -
- SPLAY_FIND(NAME, - SPLAY_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- SPLAY_LEFT(struct - TYPE *elm, SPLAY_ENTRY - NAME);

-

struct TYPE * -
- SPLAY_RIGHT(struct - TYPE *elm, SPLAY_ENTRY - NAME);

-

SPLAY_FOREACH(VARNAME, - NAME, - SPLAY_HEAD *head);

-

void -
- SPLAY_INIT(SPLAY_HEAD - *head);

-

struct TYPE * -
- SPLAY_INSERT(NAME, - SPLAY_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- SPLAY_REMOVE(NAME, - SPLAY_HEAD *head, - struct TYPE *elm);

-

RB_PROTOTYPE(NAME, - TYPE, - FIELD, - CMP);

-

RB_PROTOTYPE_STATIC(NAME, - TYPE, - FIELD, - CMP);

-

RB_PROTOTYPE_INSERT(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_INSERT_COLOR(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_REMOVE(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_REMOVE_COLOR(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_FIND(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_NFIND(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_NEXT(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_PREV(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_MINMAX(NAME, - TYPE, - ATTR);

-

RB_PROTOTYPE_REINSERT(NAME, - TYPE, - ATTR);

-

RB_GENERATE(NAME, - TYPE, - FIELD, - CMP);

-

RB_GENERATE_STATIC(NAME, - TYPE, - FIELD, - CMP);

-

RB_GENERATE_INSERT(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

RB_GENERATE_INSERT_COLOR(NAME, - TYPE, - FIELD, - ATTR);

-

RB_GENERATE_REMOVE(NAME, - TYPE, - FIELD, - ATTR);

-

RB_GENERATE_REMOVE_COLOR(NAME, - TYPE, - FIELD, - ATTR);

-

RB_GENERATE_FIND(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

RB_GENERATE_NFIND(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

RB_GENERATE_NEXT(NAME, - TYPE, - FIELD, - ATTR);

-

RB_GENERATE_PREV(NAME, - TYPE, - FIELD, - ATTR);

-

RB_GENERATE_MINMAX(NAME, - TYPE, - FIELD, - ATTR);

-

RB_GENERATE_REINSERT(NAME, - TYPE, - FIELD, - CMP, - ATTR);

-

RB_ENTRY(TYPE);

-

RB_HEAD(HEADNAME, - TYPE);

-

RB_INITIALIZER(RB_HEAD - *head);

-

struct TYPE * -
- RB_ROOT(RB_HEAD - *head);

-

bool -
- RB_EMPTY(RB_HEAD - *head);

-

struct TYPE * -
- RB_NEXT(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- RB_PREV(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- RB_MIN(NAME, - RB_HEAD *head);

-

struct TYPE * -
- RB_MAX(NAME, - RB_HEAD *head);

-

struct TYPE * -
- RB_FIND(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- RB_NFIND(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- RB_LEFT(struct - TYPE *elm, RB_ENTRY - NAME);

-

struct TYPE * -
- RB_RIGHT(struct - TYPE *elm, RB_ENTRY - NAME);

-

struct TYPE * -
- RB_PARENT(struct - TYPE *elm, RB_ENTRY - NAME);

-

RB_FOREACH(VARNAME, - NAME, - RB_HEAD *head);

-

RB_FOREACH_FROM(VARNAME, - NAME, - POS_VARNAME);

-

RB_FOREACH_SAFE(VARNAME, - NAME, - RB_HEAD *head, - TEMP_VARNAME);

-

RB_FOREACH_REVERSE(VARNAME, - NAME, - RB_HEAD *head);

-

RB_FOREACH_REVERSE_FROM(VARNAME, - NAME, - POS_VARNAME);

-

RB_FOREACH_REVERSE_SAFE(VARNAME, - NAME, - RB_HEAD *head, - TEMP_VARNAME);

-

void -
- RB_INIT(RB_HEAD - *head);

-

struct TYPE * -
- RB_INSERT(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- RB_INSERT_NEXT(NAME, - RB_HEAD *head, - struct TYPE *elm, - struct TYPE *next);

-

struct TYPE * -
- RB_INSERT_PREV(NAME, - RB_HEAD *head, - struct TYPE *elm, - struct TYPE *prev);

-

struct TYPE * -
- RB_REMOVE(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

struct TYPE * -
- RB_REINSERT(NAME, - RB_HEAD *head, - struct TYPE *elm);

-

void -
- RB_AUGMENT(NAME, - struct TYPE *elm);

-

bool -
- RB_AUGMENT_CHECK(NAME, - struct TYPE *elm);

-

void -
- RB_UPDATE_AUGMENT(NAME, - struct TYPE *elm);

-
-
-

-

These macros define data structures for different types of trees: - splay trees and rank-balanced (wavl) trees.

-

In the macro definitions, - TYPE is the name tag of a user defined structure that - must contain a field of type SPLAY_ENTRY, or - RB_ENTRY, named ENTRYNAME. The - argument HEADNAME is the name tag of a user defined - structure that must be declared using the macros - (), - or RB_HEAD(). The argument - NAME has to be a unique name prefix for every tree - that is defined.

-

The function prototypes are declared with - (), - RB_PROTOTYPE(), or - RB_PROTOTYPE_STATIC(). The function bodies are - generated with SPLAY_GENERATE(), - RB_GENERATE(), or - RB_GENERATE_STATIC(). See the examples below for - further explanation of how these macros are used.

-
-
-

-

A splay tree is a self-organizing data structure. Every operation - on the tree causes a splay to happen. The splay moves the requested node to - the root of the tree and partly rebalances it.

-

This has the benefit that request locality causes faster lookups - as the requested nodes move to the top of the tree. On the other hand, every - lookup causes memory writes.

-

The Balance Theorem bounds the total access time for - m operations and n inserts on an - initially empty tree as - ((m - + n)lg n). The amortized cost for a sequence of - m accesses to a splay tree is - O(lg n).

-

A splay tree is headed by a structure defined by - the - () - macro. A structure is declared as follows:

-
SPLAY_HEAD(HEADNAME, - TYPE) head;
-

where HEADNAME is the name of the structure - to be defined, and struct TYPE is the type of the - elements to be inserted into the tree.

-

The - () - macro declares a structure that allows elements to be connected in the - tree.

-

In order to use the functions that - manipulate the tree structure, their prototypes need to be declared with the - () - macro, where NAME is a unique identifier for this - particular tree. The TYPE argument is the type of the - structure that is being managed by the tree. The FIELD - argument is the name of the element defined by - SPLAY_ENTRY().

-

The function bodies are generated with the - () - macro. It takes the same arguments as the - SPLAY_PROTOTYPE() macro, but should be used only - once.

-

Finally, the CMP argument is the name of a - function used to compare tree nodes with each other. The function takes two - arguments of type struct TYPE *. If the first argument - is smaller than the second, the function returns a value smaller than zero. - If they are equal, the function returns zero. Otherwise, it should return a - value greater than zero. The compare function defines the order of the tree - elements.

-

The - () - macro initializes the tree referenced by head.

-

The splay tree can also be initialized - statically by using the - () - macro like this:

-
SPLAY_HEAD(HEADNAME, - TYPE) head = - SPLAY_INITIALIZER(&head);
-

The - () - macro inserts the new element elm into the tree.

-

The - () - macro removes the element elm from the tree pointed by - head.

-

The - () - macro can be used to find a particular element in the tree.

-
-
struct TYPE find, *res;
-find.key = 30;
-res = SPLAY_FIND(NAME, head, &find);
-
-

The - (), - (), - (), - and - () - macros can be used to traverse the tree:

-
-
for (np = SPLAY_MIN(NAME, &head); np != NULL; np = SPLAY_NEXT(NAME, &head, np))
-
-

Or, for simplicity, one can use the - () - macro:

-
SPLAY_FOREACH(np, - NAME, head)
-

The - () - macro should be used to check whether a splay tree is empty.

-
-
-

-

Rank-balanced (RB) trees are a framework for defining - height-balanced binary search trees, including AVL and red-black trees. Each - tree node has an associated rank. Balance conditions are expressed by - conditions on the differences in rank between any node and its children. - Rank differences are stored in each tree node.

-

The balance conditions implemented by the RB macros lead to weak - AVL (wavl) trees, which combine the best aspects of AVL and red-black trees. - Wavl trees rebalance after an insertion in the same way AVL trees do, with - the same worst-case time as red-black trees offer, and with better balance - in the resulting tree. Wavl trees rebalance after a removal in a way that - requires less restructuring, in the worst case, than either AVL or red-black - trees do. Removals can lead to a tree almost as unbalanced as a red-black - tree; insertions lead to a tree becoming as balanced as an AVL tree.

-

A rank-balanced tree is headed by a structure defined - by the - () - macro. A structure is declared as follows:

-
RB_HEAD(HEADNAME, - TYPE) head;
-

where HEADNAME is the name of the structure - to be defined, and struct TYPE is the type of the - elements to be inserted into the tree.

-

The - () - macro declares a structure that allows elements to be connected in the - tree.

-

In order to use the functions that manipulate - the tree structure, their prototypes need to be declared with the - () - or - () - macro, where NAME is a unique identifier for this - particular tree. The TYPE argument is the type of the - structure that is being managed by the tree. The FIELD - argument is the name of the element defined by - RB_ENTRY(). Individual prototypes can be declared - with - (), - (), - (), - (), - (), - (), - (), - (), - (), - and - () - in case not all functions are required. The individual prototype macros - expect NAME, TYPE, and - ATTR arguments. The ATTR - argument must be empty for global functions or static - for static functions.

-

The function bodies are generated with the - () - or - () - macro. These macros take the same arguments as the - RB_PROTOTYPE() and - RB_PROTOTYPE_STATIC() macros, but should be used - only once. As an alternative individual function bodies are generated with - the - (), - (), - (), - (), - (), - (), - (), - (), - (), - and - () - macros.

-

Finally, the CMP argument is the name of a - function used to compare tree nodes with each other. The function takes two - arguments of type struct TYPE *. If the first argument - is smaller than the second, the function returns a value smaller than zero. - If they are equal, the function returns zero. Otherwise, it should return a - value greater than zero. The compare function defines the order of the tree - elements.

-

The - () - macro initializes the tree referenced by head.

-

The rank-balanced tree can also be initialized - statically by using the - () - macro like this:

-
RB_HEAD(HEADNAME, - TYPE) head = - RB_INITIALIZER(&head);
-

The - () - macro inserts the new element elm into the tree.

-

The - () - macro inserts the new element elm into the tree - immediately after a given element.

-

The - () - macro inserts the new element elm into the tree - immediately before a given element.

-

The - () - macro removes the element elm from the tree pointed by - head.

-

The - () - and RB_NFIND() macros can be used to find a - particular element in the tree.

-

The - () - macro returns the element in the tree equal to the provided key, or - NULL if there is no such element.

-

The - () - macro returns the least element greater than or equal to the provided key, - or NULL if there is no such element.

-
-
struct TYPE find, *res, *resn;
-find.key = 30;
-res = RB_FIND(NAME, head, &find);
-resn = RB_NFIND(NAME, head, &find);
-
-

The - (), - (), - (), - (), - and - () - macros can be used to traverse the tree:

-

-
for (np = RB_MIN(NAME, &head); np - != NULL; np = RB_NEXT(NAME, &head, np))
-

Or, for simplicity, one can use the - () - or - () - macro:

-
RB_FOREACH(np, - NAME, head)
-

The macros - () - and - () - traverse the tree referenced by head in a forward or reverse direction - respectively, assigning each element in turn to np. However, unlike their - unsafe counterparts, they permit both the removal of np as well as freeing - it from within the loop safely without interfering with the traversal.

-

Both - () - and - () - may be used to continue an interrupted traversal in a forward or reverse - direction respectively. The head pointer is not required. The pointer to the - node from where to resume the traversal should be passed as their last - argument, and will be overwritten to provide safe traversal.

-

The - () - macro should be used to check whether a rank-balanced tree is empty.

-

The - () - macro updates the position of the element elm in the - tree. This must be called if a member of a tree is - modified in a way that affects comparison, such as by modifying a node's - key. This is a lower overhead alternative to removing the element and - reinserting it again.

-

The - () - macro updates augmentation data of the element elm in - the tree. By default, it has no effect. It is not meant to be invoked by the - RB user. If RB_AUGMENT() is defined by the RB user, - then when an element is inserted or removed from the tree, it is invoked for - every element in the tree that is the root of an altered subtree, working - from the bottom of the tree up to the top. It is typically used to maintain - some associative accumulation of tree elements, such as sums, minima, - maxima, and the like.

-

The - () - macro updates augmentation data of the element elm in - the tree. By default, it does nothing and returns false. If - RB_AUGMENT_CHECK() is defined, then when an element - is inserted or removed from the tree, it is invoked for every element in the - tree that is the root of an altered subtree, working from the bottom of the - tree up toward the top, until it returns false to indicate that it did not - change the element and so working further up the tree would change nothing. - It is typically used to maintain some associative accumulation of tree - elements, such as sums, minima, maxima, and the like.

-

The - () - macro updates augmentation data of the element elm and - its ancestors in the tree. If RB_AUGMENT() is - defined by the RB user, then when an element in the tree is changed, without - changing the order of items in the tree, invoking this function on that - element restores consistency of the augmentation state of the tree as if the - element had been removed and inserted again.

-
-
-

-

The following example demonstrates how to declare a rank-balanced - tree holding integers. Values are inserted into it and the contents of the - tree are printed in order. To maintain the sum of the values in the tree, - each element maintains the sum of its value and the sums from its left and - right subtrees. Lastly, the internal structure of the tree is printed.

-
-
#define RB_AUGMENT(entry) sumaug(entry)
-
-#include <sys/tree.h>
-#include <err.h>
-#include <stdio.h>
-#include <stdlib.h>
-
-struct node {
-	RB_ENTRY(node) entry;
-	int i, sum;
-};
-
-int
-intcmp(struct node *e1, struct node *e2)
-{
-	return (e1->i < e2->i ? -1 : e1->i > e2->i);
-}
-
-void
-sumaug(struct node *e)
-{
-	e->sum = e->i;
-	if (RB_LEFT(e, entry) != NULL)
-		e->sum += RB_LEFT(e, entry)->sum;
-	if (RB_RIGHT(e, entry) != NULL)
-		e->sum += RB_RIGHT(e, entry)->sum;
-}
-
-RB_HEAD(inttree, node) head = RB_INITIALIZER(&head);
-RB_GENERATE(inttree, node, entry, intcmp)
-
-int testdata[] = {
-	20, 16, 17, 13, 3, 6, 1, 8, 2, 4, 10, 19, 5, 9, 12, 15, 18,
-	7, 11, 14
-};
-
-void
-print_tree(struct node *n)
-{
-	struct node *left, *right;
-
-	if (n == NULL) {
-		printf("nil");
-		return;
-	}
-	left = RB_LEFT(n, entry);
-	right = RB_RIGHT(n, entry);
-	if (left == NULL && right == NULL)
-		printf("%d", n->i);
-	else {
-		printf("%d(", n->i);
-		print_tree(left);
-		printf(",");
-		print_tree(right);
-		printf(")");
-	}
-}
-
-int
-main(void)
-{
-	int i;
-	struct node *n;
-
-	for (i = 0; i < sizeof(testdata) / sizeof(testdata[0]); i++) {
-		if ((n = malloc(sizeof(struct node))) == NULL)
-			err(1, NULL);
-		n->i = testdata[i];
-		RB_INSERT(inttree, &head, n);
-	}
-
-	RB_FOREACH(n, inttree, &head) {
-		printf("%d\n", n->i);
-	}
-	print_tree(RB_ROOT(&head));
-	printf("\nSum of values = %d\n", RB_ROOT(&head)->sum);
-	return (0);
-}
-
-
-
-

-

Trying to free a tree in the following way is a common error:

-
-
SPLAY_FOREACH(var, NAME, head) {
-	SPLAY_REMOVE(NAME, head, var);
-	free(var);
-}
-free(head);
-
-

Since var is freed, the - () - macro refers to a pointer that may have been reallocated already. Proper - code needs a second variable.

-
-
for (var = SPLAY_MIN(NAME, head); var != NULL; var = nxt) {
-	nxt = SPLAY_NEXT(NAME, head, var);
-	SPLAY_REMOVE(NAME, head, var);
-	free(var);
-}
-
-

Both - () - and SPLAY_INSERT() return - NULL if the element was inserted in the tree - successfully, otherwise they return a pointer to the element with the - colliding key.

-

Accordingly, - () - and SPLAY_REMOVE() return the pointer to the removed - element otherwise they return NULL to indicate an - error.

-
-
-

-

arb(3), queue(3)

-

Bernhard Haeupler, - Siddhartha Sen, and Robert E. - Tarjan, Rank-Balanced Trees, - ACM Transactions on Algorithms, - 4, 11, - http://sidsen.azurewebsites.net/papers/rb-trees-talg.pdf, - June 2015.

-
-
-

-

The tree macros first appeared in FreeBSD - 4.6.

-
-
-

-

The author of the tree macros is Niels - Provos.

-
-
- - - - - -
August 2, 2024FreeBSD 15.0
diff --git a/static/freebsd/man3lua/intro.3lua 4.html b/static/freebsd/man3lua/intro.3lua 4.html deleted file mode 100644 index 77f73cc5..00000000 --- a/static/freebsd/man3lua/intro.3lua 4.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - -
INTRO(3lua)3luaINTRO(3lua)
-
-
-

-

intro — - introduction to the Lua modules for flua - (FreeBSD Lua)

-
-
-

-

This section describes - - (FreeBSD Lua) and the Lua modules provided in the - FreeBSD base system.

-

The Lua modules provided by FreeBSD - are:

-
-
jail(3lua)
-
Wrapper for jail(3).
-
-
-
-

-

jail(3lua)

-
-
-

-

Ryan Moeller, with inspiration from - NetBSD intro(3lua), by -
- Marc Balmer.

-
-
- - - - - -
October 24, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/aac.4 3.html b/static/freebsd/man4/aac.4 3.html deleted file mode 100644 index ca809a77..00000000 --- a/static/freebsd/man4/aac.4 3.html +++ /dev/null @@ -1,196 +0,0 @@ - - - - - - -
AAC(4)Device Drivers ManualAAC(4)
-
-
-

-

aac — Adaptec - AdvancedRAID Controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device aac -
-device aacp -

To compile in debugging code: -
- options AAC_DEBUG=N

-
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
aac_load="YES"
-
-
-
-

-

The aac driver provides support for the - Adaptec AAC family of SCSI Ultra2, Ultra160, and Ultra320, SATA and SAS RAID - controllers.

-

Access to RAID containers is available via the - /dev/aacd? device nodes. The - aacp device enables the SCSI pass-thru interface and - allows devices connected to the card such as CD-ROMs to be available via the - CAM scsi(4) subsystem. Note that not all cards allow this - interface to be enabled.

-

The /dev/aac? device nodes provide access - to the management interface of the controller. One node exists per installed - card. The aliases /dev/afa? and - /dev/hpn? exist for compatibility with the Dell and - HP versions of management tools, respectively. If the - aac_linux.ko and linux.ko - modules are loaded, the Linux-compatible ioctl(2) - interface for the management device will be enabled and will allow - Linux-based management applications to control the card.

-
-
-

-

The aac driver supports the following - Parallel SCSI, SATA, and 3G SAS RAID controllers from the Adaptec AAC - family:

-

-
    -
  • Adaptec AAC-364
    • -
  • Adaptec RAID 2045
    • -
  • Adaptec RAID 2405
    • -
  • Adaptec RAID 2445
    • -
  • Adaptec RAID 2805
    • -
  • Adaptec RAID 3085
    • -
  • Adaptec RAID 31205
    • -
  • Adaptec RAID 31605
    • -
  • Adaptec RAID 5085
    • -
  • Adaptec RAID 51205
    • -
  • Adaptec RAID 51245
    • -
  • Adaptec RAID 51605
    • -
  • Adaptec RAID 51645
    • -
  • Adaptec RAID 52445
    • -
  • Adaptec RAID 5405
    • -
  • Adaptec RAID 5445
    • -
  • Adaptec RAID 5805
    • -
  • Adaptec SAS RAID 3405
    • -
  • Adaptec SAS RAID 3805
    • -
  • Adaptec SAS RAID 4000SAS
    • -
  • Adaptec SAS RAID 4005SAS
    • -
  • Adaptec SAS RAID 4800SAS
    • -
  • Adaptec SAS RAID 4805SAS
    • -
  • Adaptec SATA RAID 2020SA ZCR
    • -
  • Adaptec SATA RAID 2025SA ZCR
    • -
  • Adaptec SATA RAID 2026ZCR
    • -
  • Adaptec SATA RAID 2410SA
    • -
  • Adaptec SATA RAID 2420SA
    • -
  • Adaptec SATA RAID 2610SA
    • -
  • Adaptec SATA RAID 2620SA
    • -
  • Adaptec SATA RAID 2810SA
    • -
  • Adaptec SATA RAID 2820SA
    • -
  • Adaptec SATA RAID 21610SA
    • -
  • Adaptec SCSI RAID 2020ZCR
    • -
  • Adaptec SCSI RAID 2025ZCR
    • -
  • Adaptec SCSI RAID 2120S
    • -
  • Adaptec SCSI RAID 2130S
    • -
  • Adaptec SCSI RAID 2130SLP
    • -
  • Adaptec SCSI RAID 2230SLP
    • -
  • Adaptec SCSI RAID 2200S
    • -
  • Adaptec SCSI RAID 2240S
    • -
  • Adaptec SCSI RAID 3230S
    • -
  • Adaptec SCSI RAID 3240S
    • -
  • Adaptec SCSI RAID 5400S
    • -
  • Dell CERC SATA RAID 2
    • -
  • Dell PERC 2/Si
    • -
  • Dell PERC 2/QC
    • -
  • Dell PERC 3/Si
    • -
  • Dell PERC 3/Di
    • -
  • Dell PERC 320/DC
    • -
  • HP ML110 G2 (Adaptec SATA RAID 2610SA)
    • -
  • HP NetRAID 4M
    • -
  • IBM ServeRAID 8i
    • -
  • IBM ServeRAID 8k
    • -
  • IBM ServeRAID 8s
    • -
  • ICP RAID ICP5045BL
    • -
  • ICP RAID ICP5085BL
    • -
  • ICP RAID ICP5085SL
    • -
  • ICP RAID ICP5125BR
    • -
  • ICP RAID ICP5125SL
    • -
  • ICP RAID ICP5165BR
    • -
  • ICP RAID ICP5165SL
    • -
  • ICP RAID ICP5445SL
    • -
  • ICP RAID ICP5805BL
    • -
  • ICP RAID ICP5805SL
    • -
  • ICP ICP5085BR SAS RAID
    • -
  • ICP ICP9085LI SAS RAID
    • -
  • ICP ICP9047MA SATA RAID
    • -
  • ICP ICP9067MA SATA RAID
    • -
  • ICP ICP9087MA SATA RAID
    • -
  • ICP ICP9014RO SCSI RAID
    • -
  • ICP ICP9024RO SCSI RAID
    • -
  • Legend S220
    • -
  • Legend S230
    • -
  • Sun STK RAID REM
    • -
  • Sun STK RAID EM
    • -
  • SG-XPCIESAS-R-IN
    • -
  • SG-XPCIESAS-R-EX
    • -
  • AOC-USAS-S4i
    • -
  • AOC-USAS-S8i
    • -
  • AOC-USAS-S4iR
    • -
  • AOC-USAS-S8iR
    • -
  • AOC-USAS-S8i-LP
    • -
  • AOC-USAS-S8iR-LP
    • -
-
-
-

-
-
/dev/aac?
-
aac management interface
-
/dev/aacd?
-
disk/container interface
-
-
-
-

-

Compiling with AAC_DEBUG set to a number - between 0 and 3 will enable increasingly verbose debug messages.

-

The adapter can send status and alert messages asynchronously to - the driver. These messages are printed on the system console, and are also - queued for retrieval by a management application.

-
-
-

-

kld(4), linux(4), - scsi(4), kldload(8)

-
-
-

-

The aac driver first appeared in - FreeBSD 4.3.

-
-
-

-

Mike Smith - <msmith@FreeBSD.org> -
- Scott Long - <scottl@FreeBSD.org>

-
-
-

-

This driver is not compatible with Dell controllers that have - version 1.x firmware. The firmware version is the same as the kernel version - printed in the BIOS POST and driver attach messages.

-

The controller is not actually paused on suspend/resume.

-
-
- - - - - -
September 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/aacraid.4 3.html b/static/freebsd/man4/aacraid.4 3.html deleted file mode 100644 index 90c0bc2d..00000000 --- a/static/freebsd/man4/aacraid.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
AACRAID(4)Device Drivers ManualAACRAID(4)
-
-
-

-

aacraid — Adaptec - Series 6/7/8 6G and 12G SAS+SATA RAID controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device aacraid -

To compile in debugging code: -
- options AACRAID_DEBUG=N

-
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
aacraid_load="YES"
-
-
-
-

-

The aacraid driver provides support for - the Adaptec by PMC RAID controllers, including Series 6/7/8 and upcoming - families.

-

The RAID containers are handled via the - aacraidp0 bus. The physical buses are represented by - the aacraidp? devices (beginning with aacraidp1). - These devices enable the SCSI pass-passthrough interface and allows devices - connected to the card such as CD-ROMs to be available via the CAM - scsi(4) subsystem. Note that not all cards allow this - interface to be enabled.

-

The /dev/aacraid? device nodes provide - access to the management interface of the controller. One node exists per - installed card. If the aacraid_linux.ko and - linux.ko modules are loaded, the Linux-compatible - ioctl(2) interface for the management device will be - enabled and will allow Linux-based management applications to control the - card.

-
-
-

-

The aacraid driver supports the following - Adaptec 6G and 12G SAS/SATA RAID controllers:

-

-
    -
  • Adaptec ASR-6405(T|E)
    • -
  • Adaptec ASR-6445
    • -
  • Adaptec ASR-6805(T|E|Q|TQ)
    • -
  • Adaptec ASR-7085
    • -
  • Adaptec ASR-7805(Q)
    • -
  • Adaptec ASR-70165
    • -
  • Adaptec ASR-71605(E|Q)
    • -
  • Adaptec ASR-71685
    • -
  • Adaptec ASR-72405
    • -
  • Adaptec Series 8 cards
    • -
-
-
-

-
-
/dev/aacraid?
-
aacraid management interface
-
-
-
-

-

Compiling with AACRAID_DEBUG set to a - number between 0 and 3 will enable increasingly verbose debug messages.

-

The adapter can send status and alert messages asynchronously to - the driver. These messages are printed on the system console, and are also - queued for retrieval by a management application.

-
-
-

-

kld(4), linux(4), - scsi(4), kldload(8)

-
-
-

-

Achim Leubner - <achim@FreeBSD.org> -
- Ed Maste - <emaste@FreeBSD.org> -
- Scott Long - <scottl@FreeBSD.org>

-
-
-

-

The controller is not actually paused on suspend/resume.

-
-
- - - - - -
September 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi.4 3.html b/static/freebsd/man4/acpi.4 3.html deleted file mode 100644 index e0e6ab2f..00000000 --- a/static/freebsd/man4/acpi.4 3.html +++ /dev/null @@ -1,552 +0,0 @@ - - - - - - -
ACPI(4)Device Drivers ManualACPI(4)
-
-
-

-

acpi — Advanced - Configuration and Power Management support

-
-
-

-

device acpi

-

-
- options ACPI_DEBUG -
- options DDB

-
-
-

-

The acpi driver provides support for the - Intel/Microsoft/Compaq/Toshiba ACPI standard. This support includes platform - hardware discovery (superseding the PnP and PCI BIOS), as well as power - management (superseding APM) and other features. ACPI core support is - provided by the ACPI CA reference implementation from Intel.

-

Note that the acpi driver is automatically - loaded by the loader(8), and should only be compiled into - the kernel on platforms where ACPI is mandatory.

-
-
-

-

The acpi driver is intended to provide - power management without user intervention. If the default settings are not - optimal, the following sysctls can be used to modify or monitor - acpi behavior. Note that some variables will be - available only if the given hardware supports them (such as - hw.acpi.acline).

-
-
debug.acpi.enable_debug_objects
-
Enable dumping Debug objects without options - ACPI_DEBUG. Default is 0, ignore Debug objects.
-
dev.cpu.N.cx_usage
-
Debugging information listing the percent of total usage for each sleep - state. The values are reset when dev.cpu.N.cx_lowest - is modified.
-
dev.cpu.N.cx_lowest
-
Lowest Cx state to use for idling the CPU. A scheduling algorithm will - select states between C1 and this setting as - system load dictates. To enable ACPI CPU idling control, - machdep.idle should be set to - acpi if it is listed in - machdep.idle_available.
-
dev.cpu.N.cx_supported
-
List of supported CPU idle states and their transition latency in - microseconds. Each state has a type (e.g., C2). - C1 is equivalent to the ia32 - HLT instruction, C2 - provides a deeper sleep with the same semantics, and - C3 provides the deepest sleep but additionally - requires bus mastering to be disabled. States greater than - C3 provide even more power savings with the same - semantics as the C3 state. Deeper sleeps provide - more power savings but increased transition latency when an interrupt - occurs.
-
dev.cpu.N.cx_method
-
List of supported CPU idle states and their transition methods, as - directed by the firmware.
-
hw.acpi.acline
-
AC line state (1 means online, 0 means on battery power).
-
hw.acpi.disable_on_reboot
-
Disable ACPI during the reboot process. Most systems reboot fine with ACPI - still enabled, but some require exiting to legacy mode first. Default is - 0, leave ACPI enabled.
-
hw.acpi.handle_reboot
-
Use the ACPI Reset Register capability to reboot the system. Some newer - systems require use of this register, while some only work with legacy - rebooting support.
-
hw.acpi.lid_switch_state
-
Sleep type (awake, - standby, s2mem, - s2idle, hibernate, - poweroff) to enter when the lid switch (i.e., a - notebook screen) is closed, or - “NONE” (do nothing). Default is - “NONE”.
-
hw.acpi.power_button_state
-
Sleep type (awake, - standby, s2mem, - s2idle, hibernate, - poweroff) to enter when the power button is - pressed, or “NONE” (do nothing). - Default is poweroff.
-
hw.acpi.reset_video
-
Reset the video adapter from real mode during the resume path. Some - systems need this help, others have display problems if it is enabled. - Default is 0 (disabled).
-
hw.acpi.s4bios
-
Indicate whether the system supports S4BIOS. This - means that the BIOS can handle all the functions of suspending the system - to disk. Otherwise, the OS is responsible for suspending to disk - (S4OS). Most current systems do not support - S4BIOS.
-
hw.acpi.sleep_button_state
-
Sleep type (awake, - standby, s2mem, - s2idle, hibernate, - poweroff) to enter when the sleep button is - pressed. This is usually a special function button on the keyboard. - Default is usually s2mem if supported, and - s2idle if not.
-
hw.acpi.sleep_delay
-
Wait this number of seconds between preparing the system to suspend and - actually entering the suspend state. Default is 1 second.
-
hw.acpi.supported_sleep_state
-
ACPI S-states - (S1–S5) supported - by the BIOS. -
-
-
Quick suspend to RAM. The CPU enters a lower power state, but most - peripherals are left running.
-
-
Lower power state than S1, but with the same - basic characteristics. Not supported by many systems.
-
-
Suspend to RAM. Most devices are powered off, and the system stops - running except for memory refresh.
-
-
Suspend to disk. All devices are powered off, and the system stops - running. When resuming, the system starts as if from a cold power on. - Not yet supported by FreeBSD unless - S4BIOS is available.
-
-
System shuts down cleanly and powers off.
-
-
-
hw.acpi.verbose
-
Enable verbose printing from the various ACPI subsystems.
-
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in - /boot/loader.conf. Many of these tunables also have - a matching sysctl(8) entry for access after boot.

-
-
acpi_dsdt_load
-
Enables loading of a custom ACPI DSDT.
-
acpi_dsdt_name
-
Name of the DSDT table to load, if loading is enabled.
-
debug.acpi.disabled
-
Selectively disables portions of ACPI for debugging purposes.
-
debug.acpi.interpreter_slack
-
Enable less strict ACPI implementations. Default is 1, ignore common BIOS - mistakes.
-
debug.acpi.max_threads
-
Specify the number of task threads that are started on boot. Limiting this - to 1 may help work around various BIOSes that cannot handle parallel - requests. The default value is 3.
-
debug.acpi.quirks
-
Override any automatic quirks completely.
-
debug.acpi.resume_beep
-
Beep the PC speaker on resume. This can help diagnose suspend/resume - problems. Default is 0 (disabled).
-
hint.acpi.0.disabled
-
Set this to 1 to disable all of ACPI. If ACPI has been disabled on your - system due to a blacklist entry for your BIOS, you can set this to 0 to - re-enable ACPI for testing.
-
hw.acpi.ec.poll_timeout
-
Delay in milliseconds to wait for the EC to respond. Try increasing this - number if you get the error - "AE_NO_HARDWARE_RESPONSE".
-
hw.acpi.host_mem_start
-
Override the assumed memory starting address for PCI host bridges.
-
hw.acpi.install_interface, - hw.acpi.remove_interface
-
Install or remove OS interface(s) to control return value of - ‘_OSI’ query method. When an OS - interface is specified in hw.acpi.install_interface, - _OSI query for the interface returns it is - . - Conversely, when an OS interface is specified in - hw.acpi.remove_interface, - _OSI query returns it is - . Multiple interfaces can be specified in a - comma-separated list and any leading white spaces will be ignored. For - example, "FreeBSD, Linux" is a valid - list of two interfaces "FreeBSD" and - "Linux".
-
hw.acpi.hw.acpi.override_isa_irq_polarity - (x86)
-
Forces active-lo polarity for edge-triggered ISA interrupts. Some older - systems incorrectly specify active-lo polarity for ISA interrupts and this - override fixes those systems. This override is enabled by default on - systems with Intel CPUs, but can be enabled or disabled by setting the - tunable explicitly.
-
hw.acpi.reset_video
-
Enables calling the VESA reset BIOS vector on the resume path. This can - fix some graphics cards that have problems such as LCD white-out after - resume. Default is 0 (disabled).
-
hw.acpi.serialize_methods
-
Allow override of whether methods execute in parallel or not. Enable this - for serial behavior, which fixes - "AE_ALREADY_EXISTS" errors for AML that - really cannot handle parallel method execution. It is off by default since - this breaks recursive methods and some IBMs use such code.
-
hw.acpi.verbose
-
Turn on verbose debugging information about what ACPI is doing.
-
hw.pci.link.%s.%d.irq
-
Override the interrupt to use for this link and index. This capability - should be used carefully, and only if a device is not working with - acpi enabled. "%s" is the name of the - link (e.g., LNKA). "%d" is the resource index when the link - supports multiple IRQs. Most PCI links only have one IRQ resource, so the - below form should be used.
-
hw.pci.link.%s.irq
-
Override the interrupt to use. This capability should be used carefully, - and only if a device is not working with acpi - enabled. "%s" is the name of the link (e.g., LNKA).
-
-
-
-

-

Since ACPI support on different platforms varies greatly, there - are many debugging and tuning options available.

-

For machines known not to work with acpi - enabled, there is a BIOS blacklist. Currently, the blacklist only controls - whether acpi should be disabled or not. In the - future, it will have more granularity to control features (the - infrastructure for that is already there).

-

To enable acpi (for debugging purposes, - etc.) on machines that are on the blacklist, set the kernel environment - variable hint.acpi.0.disabled to 0. Before trying - this, consider updating your BIOS to a more recent version that may be - compatible with ACPI.

-

To disable the acpi driver completely, set - the kernel environment variable hint.acpi.0.disabled - to 1.

-

Some i386 machines totally fail to operate with some or all of - ACPI disabled. Other i386 machines fail with ACPI enabled. Disabling all or - part of ACPI on non-i386 platforms (i.e., platforms where ACPI support is - mandatory) may result in a non-functional system.

-

The acpi driver comprises a set of - drivers, which may be selectively disabled in case of problems. To disable a - sub-driver, list it in the kernel environment variable - debug.acpi.disabled. Multiple entries can be listed, - separated by a space.

-

ACPI sub-devices and features that can be disabled:

-
-
-
Disable all ACPI features and devices.
-
-
(device) Supports AC adapter.
-
-
(feature) Probes and attaches subdevices. Disabling - will avoid scanning the ACPI namespace entirely.
-
-
(feature) Attaches standard ACPI sub-drivers and - devices enumerated in the ACPI namespace. Disabling this has a similar - effect to disabling “bus”, except - that the ACPI namespace will still be scanned.
-
-
(device) Supports ACPI button devices (typically - power and sleep buttons).
-
-
(device) Control-method batteries device.
-
-
(device) Supports CPU power-saving and speed-setting - functions.
-
-
(device) Supports the ACPI Embedded Controller - interface, used to communicate with embedded platform controllers.
-
-
(device) Supports an ISA bus bridge defined in the - ACPI namespace, typically as a child of a PCI bus.
-
-
(device) Supports an ACPI laptop lid switch, which - typically puts a system to sleep.
-
-
(feature) Do not ask firmware for available - x86-vendor specific methods to enter Cx sleep - states. Only query and use the generic I/O-based entrance method. The knob - is provided to work around inconsistencies in the tables filled by - firmware.
-
-
(feature) Do not honor quirks. Quirks automatically - disable ACPI functionality based on the XSDT table's OEM vendor name and - revision date.
-
-
(device) Supports Host to PCI bridges.
- -
(feature) Performs PCI interrupt routing.
-
-
(device) Pseudo-devices containing resources which - ACPI claims.
-
-
(device) Supports system cooling and heat - management.
-
-
(device) Implements a timecounter using the ACPI - fixed-frequency timer.
-
-
(device) Supports acpi_video(4) - which may conflict with agp(4) device.
-
-

It is also possible to avoid portions of the ACPI namespace which - may be causing problems, by listing the full path of the root of the region - to be avoided in the kernel environment variable - debug.acpi.avoid. The object and all of its children - will be ignored during the bus/children scan of the namespace. The ACPI CA - code will still know about the avoided region.

-
-
-

-

To enable debugging output, acpi must be - compiled with options ACPI_DEBUG. Debugging output - is separated between layers and levels, where a layer is a component of the - ACPI subsystem, and a level is a particular kind of debugging output.

-

Both layers and levels are specified as a whitespace-separated - list of tokens, with layers listed in debug.acpi.layer - and levels in debug.acpi.level.

-

The first set of layers is for ACPI-CA components, and the second - is for FreeBSD drivers. The ACPI-CA layer - descriptions include the prefix for the files they refer to. The supported - layers are:

-

-
-
-
Utility ("ut") functions
-
-
Hardware access ("hw")
-
-
Event and GPE ("ev")
-
-
Table access ("tb")
-
-
Namespace evaluation ("ns")
-
-
AML parser ("ps")
-
-
Internal representation of interpreter state ("ds")
-
-
Execute AML methods ("ex")
-
-
Resource parsing ("rs")
-
-
Debugger implementation ("db", "dm")
-
-
Usermode support routines ("os")
-
-
Disassembler implementation (unused)
-
-
All the above ACPI-CA components
-
-
AC adapter driver
-
-
Control-method battery driver
-
-
ACPI, ISA, and PCI bus drivers
-
-
Power and sleep button driver
-
-
Embedded controller driver
-
-
Fan driver
-
-
Platform-specific driver for hotkeys, LED, etc.
-
-
Power resource driver
-
-
CPU driver
-
-
System power management controller driver
-
-
Thermal zone driver
-
-
Timer driver
-
-
All the above FreeBSD ACPI drivers
-
-

The supported levels are:

-

-
-
-
Initialization progress
-
-
Stores to objects
-
-
General information and progress
-
-
Repair a common problem with predefined methods
-
-
All the previous levels
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
All the previous levels
-
-
 
-
-
 
-
-
 
-
-
All the previous levels
-
-
Synonym for "ACPI_LV_VERBOSITY2"
-
-
 
-
-
 
-
-
 
-
-
 
-
-
All the previous levels
-
-
 
-
-
 
-
-
 
-
-
 
-
-
All levels after - "ACPI_LV_VERBOSITY3"
-
-
 
-
-
 
-
-

Selection of the appropriate layer and level values is important - to avoid massive amounts of debugging output. For example, the following - configuration is a good way to gather initial information. It enables debug - output for both ACPI-CA and the acpi driver, - printing basic information about errors, warnings, and progress.

-
-
debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
-debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS"
-
-

Debugging output by the ACPI CA subsystem is prefixed with the - module name in lowercase, followed by a source line number. Output from the - FreeBSD-local code follows the same format, but the - module name is uppercased.

-
-
-

-

ACPI interprets bytecode named AML (ACPI Machine Language) - provided by the BIOS vendor as a memory image at boot time. Sometimes, the - AML code contains a bug that does not appear when parsed by the Microsoft - implementation. FreeBSD provides a way to override - it with your own AML code to work around or debug such problems. Note that - all AML in your DSDT and any SSDT tables is overridden.

-

In order to load your AML code, you must edit - /boot/loader.conf and include the following - lines.

-
-
acpi_dsdt_load="YES"
-acpi_dsdt_name="/boot/acpi_dsdt.aml" # You may change this name.
-
-

In order to prepare your AML code, you will need the - acpidump(8) and iasl(8) utilities and - some ACPI knowledge.

-
-
-

-

ACPI is only found and supported on i386/ia32 and amd64.

-
-
-

-

kenv(1), acpi_thermal(4), - device.hints(5), loader.conf(5), - acpiconf(8), acpidump(8), - config(8), iasl(8)

-

Compaq Computer - Corporation, Intel Corporation, - Microsoft Corporation, Phoenix - Technologies Ltd., and Toshiba Corporation, - Advanced Configuration and Power Interface - Specification, - http://acpi.info/spec.htm, - August 25, 2003.

-
-
-

-

The ACPI CA subsystem is developed and maintained by Intel - Architecture Labs.

-

The following people made notable contributions to the ACPI - subsystem in FreeBSD: Michael - Smith, Takanori Watanabe - <takawata@jp.FreeBSD.org>, - Mitsuru IWASAKI - <iwasaki@jp.FreeBSD.org>, - Munehiro Matsuda, Nate - Lawson, the ACPI-jp mailing list at - <acpi-jp@jp.FreeBSD.org>, - and many other contributors.

-

This manual page was written by Michael - Smith - <msmith@FreeBSD.org>.

-
-
-

-

Many BIOS versions have serious bugs that may cause system - instability, break suspend/resume, or prevent devices from operating - properly due to IRQ routing problems. Upgrade your BIOS to the latest - version available from the vendor before deciding it is a problem with - acpi.

-
-
- - - - - -
March 21, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_asus.4 4.html b/static/freebsd/man4/acpi_asus.4 4.html deleted file mode 100644 index 1ac223e9..00000000 --- a/static/freebsd/man4/acpi_asus.4 4.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - -
ACPI_ASUS(4)Device Drivers ManualACPI_ASUS(4)
-
-
-

-

acpi_asus — Asus - Laptop Extras

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_asus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_asus_load="YES"
-
-
-
-

-

The acpi_asus driver provides support for - the extra ACPI-controlled gadgets, such as hotkeys and leds, found on recent - Asus (and Medion) laptops. It allows one to use the - sysctl(8) interface to manipulate the brightness of the - LCD panel and the display output state. Hotkey events are passed to - devd(8) for easy handling in userspace with the default - configuration in /etc/devd/asus.conf.

-

Currently, the following Asus laptops are fully supported:

-

-
    -
  • xxN
    • -
  • A1x
    • -
  • A2x
    • -
  • A3N
    • -
  • A4D
    • -
  • A6VM
    • -
  • D1x
    • -
  • J1x
    • -
  • L2B
    • -
  • L2D
    • -
  • L2E
    • -
  • L3C
    • -
  • L3D
    • -
  • L3H
    • -
  • L4E
    • -
  • L4R
    • -
  • L5x
    • -
  • L8x
    • -
  • M1A
    • -
  • M2E
    • -
  • M6N
    • -
  • M6R
    • -
  • S1x
    • -
  • S2x
    • -
  • V6V
    • -
  • W5A
    • -
  • Eee PC
    • -
-

Additionally, acpi_asus also - supports the Asus-compatible - interface - found in - laptops.

-
-
-

-

The following sysctls are currently implemented:

-
-
hw.acpi.asus.lcd_brightness
-
Makes the LCD backlight brighter or dimmer (higher values are - brighter).
-
hw.acpi.asus.lcd_backlight
-
Turns the LCD backlight on or off.
-
hw.acpi.asus.video_output
-
Sets the active display to use according to a bitwise OR of the following: -

-
-
-
No display
-
-
LCD
-
-
CRT
-
-
TV-Out
-
-

Some models also support video switching via the generic - acpi_video(4) driver. Most models do not, however.

-
-
-

Defaults for these variables can be set in - sysctl.conf(5), which is parsed at boot-time.

-
-
-

-

acpi(4), acpi_asus_wmi(4), - acpi_video(4), sysctl.conf(5), - sysctl(8)

-

The acpi4asus Project, - http://sourceforge.net/projects/acpi4asus/.

-
-
-

-

The acpi_asus driver first appeared in - FreeBSD 5.3.

-
-
-

-

The acpi_asus driver and this manual page - were written by Philip Paeps - <philip@FreeBSD.org>.

-

Inspiration came from the - started by Julien Lerouge which - maintains a driver implementing this functionality in the Linux kernel.

-
-
- - - - - -
February 8, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_asus_wmi.4 3.html b/static/freebsd/man4/acpi_asus_wmi.4 3.html deleted file mode 100644 index 637bdb0f..00000000 --- a/static/freebsd/man4/acpi_asus_wmi.4 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
ACPI_ASUS_WMI(4)Device Drivers ManualACPI_ASUS_WMI(4)
-
-
-

-

acpi_asus_wmi — - Asus Laptop WMI Extras

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_asus_wmi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_asus_wmi_load="YES"
-
-
-
-

-

The acpi_asus_wmi driver provides support - for the extra WMI-controlled gadgets, such as hotkeys and leds, found on - Asus laptops. It allows one to use the sysctl(8) interface - to manipulate the brightness of the LCD panel and keyboard backlight, power - on/off different internal components, such as WiFi, Bluetooth, camera, - cardreader, etc, read some sensors. Hotkey events are passed to - devd(8) for easy handling in userspace with the default - configuration in /etc/devd/asus.conf. Some hotkey - events, such as keyboard backlight and touchpad control, are handled inside - the driver.

-
-
-

-

The following sysctls are currently implemented:

-
-
dev.acpi_asus_wmi.0.handle_keys
-
Specifies whether driver should handle some hardware keys, such as - keyboard backlight, internally.
-
-

Number of other variables under the same sysctl branch are - model-specific.

-

Defaults for these variables can be set in - sysctl.conf(5), which is parsed at boot-time.

-
-
-

-
-
/dev/backlight/acpi_asus_wmi0
-
Keyboard backlight(8) device node.
-
-
-
-

-

acpi(4), acpi_asus(4), - acpi_video(4), sysctl.conf(5), - backlight(8), devd(8), - sysctl(8)

-
-
-

-

The acpi_asus_wmi driver first appeared in - FreeBSD 10.0.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org>

-
-
- - - - - -
March 25, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_battery.4 3.html b/static/freebsd/man4/acpi_battery.4 3.html deleted file mode 100644 index 3c23170a..00000000 --- a/static/freebsd/man4/acpi_battery.4 3.html +++ /dev/null @@ -1,318 +0,0 @@ - - - - - - -
ACPI_BATTERY(4)Device Drivers ManualACPI_BATTERY(4)
-
-
-

-

acpi_battery — - ACPI battery management subsystem

-
-
-

-

device acpi

-
-
-

-

The acpi_battery is a driver for battery - management features of the ACPI module.

-

An ACPI-compatible battery device supports either a Control Method - Battery interface or a Smart Battery subsystem interface. The former is - accessed by the AML (ACPI Machine Language) code control methods, and the - latter is controlled directly through the ACPI EC (Embedded Controller) - typically via an SMBus interface.

-

This driver supports the sysctl(8) and - ioctl(2) interfaces as well as the - devd(8) event notification interface.

-
-
-

-

Every ioctl for the acpi_battery driver - takes a single integer value for the battery unit number as an argument, and - returns a specific structure for each request. A special unit number - ACPI_BATTERY_ALL_UNITS specifies all of the attached - units and reports accumulated information.

-
-
- int
-
Returns the number of battery units in the system. The unit number - argument will be ignored.
-
- struct acpi_battinfo
-
Returns the following: -
-
cap
-
Battery capacity in percent,
-
min
-
Remaining battery life in minutes,
-
state
-
Current status of the battery encoded in the following: -
-
- (0x0001)
-
Battery is discharging,
-
- (0x0002)
-
Battery is being charged, or
-
- (0x0004)
-
Remaining battery life is critically low.
-
-

Note that the status bits of each battery will be - consolidated when ACPI_BATTERY_ALL_UNITS is - specified.

-
-
rate
-
Current battery discharging rate in mW. -1 - means not discharging right now.
-
-
-
- struct acpi_bix
-
Returns battery information given by the ACPI _BIX - (Battery Information) object, which is the static portion of the Control - Method Battery information. In the case of a Smart Battery attached to - SMBus or a Control Method Battery with a _BIF - object, this ioctl will build a struct acpi_bix - structure based on the obtained information and return it. -
-
rev
-
Revision number of the object. There are the following well-known - values: -
-
- (0x0000)
-
A _BIX object in ACPI 4.0.
-
- (0x0001)
-
A _BIX object in ACPI 6.0.
-
- (0xffff)
-
A _BIX object built from the - _BIF object found on the system.
-
-

Note that this field should be - checked by using - (var, - rev) macro when checking the minimum revision - number.

-
-
units
-
Indicates the units used by the battery to report its capacity and - charge rate encoded in the following: -
-
ACPI_BIX_UNITS_MW (0x00000000)
-
in mW (power)
-
ACPI_BIX_UNITS_MA (0x00000001)
-
in mA (current)
-
-

Note that capacity is expressed in mWh or mAh, and rate is - expressed in mW or mA, respectively.

-
-
dcap
-
The Battery's design capacity, which is the nominal capacity of a new - battery. This is expressed as power or current depending on the value - of units.
-
lfcap
-
Predicted battery capacity when fully charged. Typically this will - decrease every charging cycle.
-
btech
-
Battery technology: -
-
0x00000000 Primary cell (non-rechargeable)
-
 
-
0x00000001 Secondary cell (rechargeable)
-
 
-
-
-
dvol
-
Design voltage in mV, which is the nominal voltage of a new - battery.
-
wcap
-
Design capacity of warning. When a discharging battery device reaches - this capacity, notification is sent to the system.
-
lcap
-
Design capacity of low.
-
cycles
-
(rev 0 or newer) The number of cycles the battery has experienced. A - cycle means an amount of discharge occurred which was approximately - equal to the value of Design Capacity.
-
accuracy
-
(rev 0 or newer) The accuracy of the battery capacity measurement, in - thousandth of a percent.
-
stmax
-
(rev 0 or newer) The Maximum Sampling Time of the battery in - milliseconds. This is the maximum duration between two consecutive - measurements of the battery's capacities specified in - _BST. If two succeeding readings of - _BST beyond this duration occur, two different - results can be returned.
-
stmin
-
(rev 0 or newer) The Minimum Sampling Time of the battery in - milliseconds.
-
aimax
-
(rev 0 or newer) The Maximum Average Interval of the battery in - milliseconds. This is the length of time within which the battery - averages the capacity measurements specified in - _BST. The Sampling Time specifies the - frequency of measurements, and the Average Interval specifies the - width of the time window of every measurement.
-
aimin
-
(rev 0 or newer) The Minimum Average Interval of the battery in - milliseconds.
-
gra1
-
Battery capacity granularity between low and - warning. This is expressed as power or current - depending on the value of units.
-
gra2
-
Battery capacity granularity between warning and - full. This is expressed as power or current - depending on the value of units.
-
model
-
Model number of the battery as a string.
-
serial
-
Serial number of the battery as a string.
-
type
-
Type identifier of the battery as a string.
-
oeminfo
-
OEM-specific information of the battery as a string.
-
scap
-
(rev 1 or newer) Battery swapping capability encoded in the following: -
-
ACPI_BIX_SCAP_NO (0x00000000)
-
Non-swappable
-
ACPI_BIX_SCAP_COLD (0x00000001)
-
Cold-swappable
-
ACPI_BIX_SCAP_HOT (0x00000010)
-
Hot-swappable
-
-
-
-
-
- struct acpi_bif
-
(deprecated) Returns battery information given by the ACPI - _BIF (Battery Information) object, which was - deprecated in ACPI 4.0 specification. The data structure is a subset of - struct acpi_bix. -

Note that this ioctl will built a struct - acpi_bif structure based on the obtained information even if this - object is not available and a _BIX object is - found.

-
-
ACPIIO_BATT_GET_BST struct acpi_bst
-
Returns battery information given by the ACPI _BST - (Battery Status) object, which is the present battery status. In the case - of a Smart Battery attached to SMBus, this ioctl will build a - struct acpi_bst structure based on the obtained - information and return it. -
-
state
-
Battery state. The value is encoded in the same way as - state of struct - acpi_battinfo.
-
rate
-
Battery present rate of charging or discharging. The unit of the value - depends on unit of struct - acpi_bif.
-
cap
-
Battery remaining capacity. The unit of this value depends on - unit of struct - acpi_bif.
-
volt
-
Battery present voltage.
-
-
-
-
-
-

-

The following sysctl(8) variables export battery - status. Note that they are accumulated status of all of the connected - batteries:

-
-
hw.acpi.battery.info_expire
-
Information cache expiration time in seconds. The battery information - obtained by _BIX or _BIF - object will be stored and reused for successive read access to this MIB - within the specified period.
-
hw.acpi.battery.units
-
Number of battery units in the system.
-
hw.acpi.battery.state
-
Current battery charging status. This is same as - state of struct - acpi_battinfo.
-
hw.acpi.battery.rate
-
Current battery discharging rate in mW.
-
hw.acpi.battery.time
-
Remaining battery life in minutes. If the battery is not discharging, the - value shows -1.
-
hw.acpi.battery.life
-
Battery capacity in percent.
-
-
-
-

-

Battery-related event notifications are sent to the userland via - the devd(8) interface. See - /etc/devd.conf and devd.conf(5) - for more details. Note that notifications are supported only by the Control - Method Battery.

-

The acpi_battery driver sends events with - the following attributes:

-

-
-
system
-
-
subsystem
-
-
type
-
The fully qualified battery object path as in the ASL.
-
notify
-
An integer designating the event: -

-
-
-
Battery status was changed.
-
-
Battery information was changed.
-
-
-
-
-
-

-

acpi(4), acpiconf(8)

-
-
-

-

Nate Lawson - <njl@FreeBSD.org>, - Munehiro Matsuda, Takanori - Watanabe - <takawata@FreeBSD.org>, - Mitsuru IWASAKI - <iwasaki@FreeBSD.org>, - Hans Petter Selasky - <hselasky@FreeBSD.org>, - and Hiroki Sato - <hrs@FreeBSD.org>.

-

This manual page was written by Takanori - Watanabe - <takawata@FreeBSD.org> - and Hiroki Sato - <hrs@FreeBSD.org>.

-
-
- - - - - -
February 16, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_dock.4 4.html b/static/freebsd/man4/acpi_dock.4 4.html deleted file mode 100644 index 843f36e0..00000000 --- a/static/freebsd/man4/acpi_dock.4 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
ACPI_DOCK(4)Device Drivers ManualACPI_DOCK(4)
-
-
-

-

acpi_dock — Laptop - Docking Station device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device acpi_dock
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_dock_load="YES"
-
-
-
-

-

The acpi_dock driver provides support for - laptop docking stations.

-
-
-

-

acpi(4)

-
-
-

-

The acpi_dock device driver first appeared - in FreeBSD 7.0.

-
-
-

-

The acpi_dock device driver was written by - Mitsuru IWASAKI - <iwasaki@FreeBSD.org>.

-
-
- - - - - -
May 20, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_fujitsu.4 3.html b/static/freebsd/man4/acpi_fujitsu.4 3.html deleted file mode 100644 index abf8009b..00000000 --- a/static/freebsd/man4/acpi_fujitsu.4 3.html +++ /dev/null @@ -1,159 +0,0 @@ - - - - - - -
ACPI_FUJITSU(4)Device Drivers ManualACPI_FUJITSU(4)
-
-
-

-

acpi_fujitsu — - Fujitsu Laptop Extras

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_fujitsu
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_fujitsu_load="YES"
-
-
-
-

-

The acpi_fujitsu driver enables the - ACPI-controlled buttons on Fujitsu notebooks. The button events are sent to - userspace via devd(8), and a sysctl(8) - interface is provided to simulate the hardware events.

-

Using this driver, one can control the brightness of the display, - the volume of the speakers, and the internal (eraserhead) mouse pointer.

-
-
-

-

These sysctls are currently implemented:

-
-
hw.acpi.fujitsu.lcd_brightness
-
Makes the LCD backlight brighter or dimmer.
-
hw.acpi.fujitsu.pointer_enable
-
Enables or disables the internal mouse pointer.
-
hw.acpi.fujitsu.volume
-
Controls the speaker volume.
-
hw.acpi.fujitsu.mute
-
Mutes the speakers.
-
-

Defaults for these sysctls can be set in - sysctl.conf(5).

-
-
-

-

The following can be added to devd.conf(5) in - order to pass button events to a - /usr/local/sbin/acpi_oem_exec.sh script:

-
-
notify 10 {
-        match "system"		"ACPI";
-        match "subsystem"	"FUJITSU";
-        action "/usr/local/sbin/acpi_oem_exec.sh $notify fujitsu";
-};
-
-

A possible - /usr/local/sbin/acpi_oem_exec.sh script might look - like:

-
-
#!/bin/sh
-#
-if [ "$1" = "" -o "$2" = "" ]
-then
-        echo "usage: $0 notify oem_name"
-        exit 1
-fi
-NOTIFY=`echo $1`
-LOGGER="logger"
-CALC="bc"
-BC_PRECOMMANDS="scale=2"
-ECHO="echo"
-CUT="cut"
-MAX_LCD_BRIGHTNESS=7
-MAX_VOLUME=16
-OEM=$2
-DISPLAY_PIPE=/tmp/acpi_${OEM}_display
-
-case ${NOTIFY} in
-        0x00)
-                LEVEL=`sysctl -n hw.acpi.${OEM}.mute`
-                if [ "$LEVEL" = "1" ]
-                then
-                        MESSAGE="volume muted"
-                else
-                        MESSAGE="volume unmuted"
-                fi
-                ;;
-        0x01)
-                LEVEL=`sysctl -n hw.acpi.${OEM}.pointer_enable`
-                if [ "$LEVEL" = "1" ]
-                then
-                        MESSAGE="pointer enabled"
-                else
-                        MESSAGE="pointer disabled"
-                fi
-                ;;
-        0x02)
-                LEVEL=`sysctl -n hw.acpi.${OEM}.lcd_brightness`
-                PERCENT=`${ECHO} "${BC_PRECOMMANDS} ; \
-			 ${LEVEL} / ${MAX_LCD_BRIGHTNESS} * 100" |\
-			 ${CALC} | ${CUT} -d . -f 1`
-                MESSAGE="brightness level ${PERCENT}%"
-                ;;
-        0x03)
-                LEVEL=`sysctl -n hw.acpi.${OEM}.volume`
-                PERCENT=`${ECHO} "${BC_PRECOMMANDS} ; \
-			${LEVEL} / ${MAX_VOLUME} * 100" | \
-			 ${CALC} | ${CUT} -d . -f 1`
-                MESSAGE="volume level ${PERCENT}%"
-                ;;
-        *)
-                ;;
-        esac
-        ${LOGGER} ${MESSAGE}
-        if [ -p ${DISPLAY_PIPE} ]
-        then
-                ${ECHO} ${MESSAGE} >> ${DISPLAY_PIPE} &
-        fi
-exit 0
-
-
-
-

-

acpi(4), sysctl.conf(5), - devd(8), sysctl(8)

-
-
-

-

The acpi_fujitsu driver first appeared in - FreeBSD 5.4.

-
-
-

-

The acpi_fujitsu driver was written by - Sean Bullington - <shegget@gmail.com>, - Anish Mistry - <mistry.7@osu.edu>, - and Marc Santcroos - <marks@ripe.net>.

-

This manual page was written by Philip - Paeps - <philip@FreeBSD.org>.

-
-
- - - - - -
February 8, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_ged.4 4.html b/static/freebsd/man4/acpi_ged.4 4.html deleted file mode 100644 index fafe3ee3..00000000 --- a/static/freebsd/man4/acpi_ged.4 4.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
ACPI_GED(4)Device Drivers ManualACPI_GED(4)
-
-
-

-

acpi_ged — ACPI - Generic Event Device

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_ged
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_ged_load="YES"
-
-
-
-

-

The acpi_ged driver provides support for - generic events interface. This handles interrupts and evaluates the specific - ACPI method. This may generate optionally ACPI notify for another - device.

-
-
-

-

acpi(4)

-
-
-

-

The acpi_ged device driver first appeared - in FreeBSD 13.3.

-
-
-

-

The acpi_ged driver was written by - Takanori Watanabe - <takawata@FreeBSD.org>

-
-
- - - - - -
October 18, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_hp.4 3.html b/static/freebsd/man4/acpi_hp.4 3.html deleted file mode 100644 index 873500d7..00000000 --- a/static/freebsd/man4/acpi_hp.4 3.html +++ /dev/null @@ -1,284 +0,0 @@ - - - - - - -
ACPI_HP(4)Device Drivers ManualACPI_HP(4)
-
-
-

-

acpi_hp — ACPI - extras driver for HP laptops

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_hp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_hp_load="YES"
-
-
-
-

-

The acpi_hp driver provides support for - ACPI-controlled features found on HP laptops that use a WMI enabled BIOS - (e.g., HP Compaq 8510p and 6510p).

-

The main purpose of this driver is to provide an interface, - accessible via sysctl(8), devd(8) and - devfs(8), through which applications can determine and - change the status of various laptop components and BIOS settings.

-
-

devd(8) - Events

-

Devd events received by devd(8) provide the - following information:

-

-
-
-
system
-
"ACPI"
-
subsystem
-
"HP"
-
type
-
The source of the event in the ACPI namespace. The value depends on the - model.
-
notify
-
Event code (see below).
-
-
-

Event codes:

-

-
-
-
-
WLAN on air status changed to 0 (not on air)
-
-
WLAN on air status changed to 1 (on air)
-
-
Bluetooth on air status changed to 0 (not on air)
-
-
Bluetooth on air status changed to 1 (on air)
-
-
WWAN on air status changed to 0 (not on air)
-
-
WWAN on air status changed to 1 (on air)
-
-
-
-
-

devfs(8) - Device

-

You can read /dev/hpcmi to see your current BIOS settings. The - detail level can be adjusted by setting the sysctl - cmi_detail as described below.

-
-
-
-

-

The following sysctls are currently implemented:

-
-

-
-
dev.acpi_hp.0.wlan_enabled
-
Toggle WLAN chip activity.
-
dev.acpi_hp.0.wlan_radio
-
(read-only) WLAN radio status (controlled by hardware switch)
-
dev.acpi_hp.0.wlan_on_air
-
(read-only) WLAN on air (chip enabled, hardware switch enabled + enabled - in BIOS)
-
dev.acpi_hp.0.wlan_enabled_if_radio_on
-
If set to 1, the WLAN chip will be enabled if the radio is turned on
-
dev.acpi_hp.0.wlan_disable_if_radio_off
-
If set to 1, the WLAN chip will be disabled if the radio is turned - off
-
-
-
-

-
-
dev.acpi_hp.0.bt_enabled
-
Toggle Bluetooth chip activity.
-
dev.acpi_hp.0.bt_radio
-
(read-only) Bluetooth radio status (controlled by hardware switch)
-
dev.acpi_hp.0.bt_on_air
-
(read-only) Bluetooth on air (chip enabled, hardware switch enabled + - enabled in BIOS)
-
dev.acpi_hp.0.bt_enabled_if_radio_on
-
If set to 1, the Bluetooth chip will be enabled if the radio is turned - on
-
dev.acpi_hp.0.bt_disable_if_radio_off
-
If set to 1, the Bluetooth chip will be disabled if the radio is turned - off
-
-
-
-

-
-
dev.acpi_hp.0.wwan_enabled
-
Toggle WWAN chip activity.
-
dev.acpi_hp.0.wwan_radio
-
(read-only) WWAN radio status (controlled by hardware switch)
-
dev.acpi_hp.0.wwan_on_air
-
(read-only) WWAN on air (chip enabled, hardware switch enabled + enabled - in BIOS)
-
dev.acpi_hp.0.wwan_enabled_if_radio_on
-
If set to 1, the WWAN chip will be enabled if the radio is turned on
-
dev.acpi_hp.0.wwan_disable_if_radio_off
-
If set to 1, the WWAN chip will be disabled if the radio is turned - off
-
-
-
-

-
-
dev.acpi_hp.0.als_enabled
-
Toggle ambient light sensor (ALS)
-
dev.acpi_hp.0.display
-
(read-only) Display status (bitmask)
-
dev.acpi_hp.0.hdd_temperature
-
(read-only) HDD temperature
-
dev.acpi_hp.0.is_docked
-
(read-only) Docking station status (1 if docked)
-
dev.acpi_hp.0.cmi_detail
-
Bitmask to control detail level in /dev/hpcmi output (values can be ORed). -
-
-
-
Show path component of BIOS setting
-
-
Show a list of valid options for the BIOS setting
-
-
Show additional flags of BIOS setting (ReadOnly etc.)
-
-
Query highest BIOS entry instance. This is broken on many HP models - and therefore disabled by default.
-
-
-
-
dev.acpi_hp.0.verbose
-
(read-only) Set verbosity level
-
-

Defaults for these sysctls can be set in - sysctl.conf(5).

-
-
-
-

-

The acpi_hp driver has been reported to - support the following hardware:

-

-
    -
  • HP Compaq 8510p
    • -
  • HP Compaq nx7300
    • -
-

It should work on most HP laptops that feature a WMI enabled - BIOS.

-
-
-

-
-
/dev/hpcmi
-
Interface to read BIOS settings
-
-
-
-

-

The following can be added to devd.conf(5) in - order disable the LAN interface when WLAN on air and reenable if it is - not:

-
-
notify 0 {
-	match "system"          "ACPI";
-	match "subsystem"       "HP";
-	match "notify"          "0xc0";
-	action                  "ifconfig em0 up";
-};
-
-notify 0 {
-	match "system"          "ACPI";
-	match "subsystem"       "HP";
-	match "notify"          "0xc1";
-	action                  "ifconfig em0 down";
-};
-
-

Enable the ambient light sensor:

-
-
sysctl dev.acpi_hp.0.als_enabled=1
-
-

Enable Bluetooth:

-
-
sysctl dev.acpi_hp.0.bt_enabled=1
-
-

Get BIOS settings:

-
-
cat /dev/hpcmi
-
-Serial Port                                Disable
-Infrared Port                              Enable
-Parallel Port                              Disable
-Flash Media Reader                         Disable
-USB Ports including Express Card slot      Enable
-1394 Port                                  Enable
-Cardbus Slot                               Disable
-Express Card Slot                          Disable
-(...)
-
-

Set maximum detail level for /dev/hpcmi output:

-
-
sysctl dev.acpi_hp.0.cmi_detail=7
-
-
-
-

-

acpi(4), acpi_wmi(4), - sysctl.conf(5), devd(8), - devfs(8), sysctl(8)

-
-
-

-

The acpi_hp device driver first appeared - in FreeBSD 8.0.

-
-
-

-

The acpi_hp driver was written by - Michael Gmelin - <freebsd@grem.de>.

-

It has been inspired by hp-wmi driver, which implements a subset - of these features (hotkeys) on Linux.

-
-
HP CMI whitepaper:
-
https://h20331.www2.hp.com/Hpsub/downloads/cmi_whitepaper.pdf
-
wmi-hp for Linux:
-
https://www.kernel.org
-
WMI and ACPI:
-
http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx
-
-

This manual page was written by Michael - Gmelin - <freebsd@grem.de>.

-
-
-

-

This driver is experimental and has only been tested on i386 on an - HP Compaq 8510p which featured all supported wireless devices - (WWAN/BT/WLAN). Expect undefined results when operating on different - hardware.

-

Loading the driver is slow. Reading from - /dev/hpcmi is even slower.

-

Additional features like HP specific sensor readings or writing - BIOS settings are not supported.

-
-
- - - - - -
June 19, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_ibm.4 3.html b/static/freebsd/man4/acpi_ibm.4 3.html deleted file mode 100644 index 2dc10faf..00000000 --- a/static/freebsd/man4/acpi_ibm.4 3.html +++ /dev/null @@ -1,455 +0,0 @@ - - - - - - -
ACPI_IBM(4)Device Drivers ManualACPI_IBM(4)
-
-
-

-

acpi_ibm — - ThinkPad ACPI extras driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_ibm
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_ibm_load="YES"
-
-
-
-

-

The acpi_ibm driver provides support for - hotkeys and other components of ThinkPad laptops. The main purpose of this - driver is to provide an interface, accessible via - sysctl(8) and devd(8), through which - applications can determine the status of various laptop components.

-

While the sysctl(8) interface is enabled - automatically after loading the driver, the devd(8) - interface has to be enabled explicitly, as it may alter the default action - of certain keys. This is done by setting the events - sysctl as described below. Specifying which keys should generate events is - done by setting a bitmask, whereas each bit represents one key or key - combination. This bitmask, accessible via the - eventmask sysctl, is set to - availmask by default, a value representing all - possible keypress events on the specific ThinkPad model.

-
-

devd(8) - Events

-

Hotkey events received by devd(8) provide the - following information:

-

-
-
-
system
-
"ACPI"
-
subsystem
-
"IBM"
-
type
-
The source of the event in the ACPI namespace. The value depends on the - model.
-
notify
-
Event code (see below).
-
-
-

Depending on the ThinkPad model, event codes may vary. On a - ThinkPad T41p these are as follows:

-

-
-
-
-
Fn + F1
-
-
Fn + F2
-
-
Fn + F3 (LCD backlight)
-
-
Fn + F4 (Suspend to RAM)
-
-
Fn + F5 (Bluetooth)
-
-
Fn + F6
-
-
Fn + F7 (Screen expand)
-
-
Fn + F8
-
-
Fn + F9
-
-
Fn + F10
-
-
Fn + F11
-
-
Fn + F12 (Suspend to disk)
-
-
Fn + Backspace
-
-
Fn + Insert
-
-
Fn + Delete
-
-
Fn + Home (Brightness up)
-
-
Fn + End (Brightness down)
-
-
Fn + PageUp (ThinkLight)
-
-
Fn + PageDown
-
-
Fn + Space (Zoom)
-
-
Volume Up
-
-
Volume Down
-
-
Mute
-
-
Access IBM Button
-
-
-
-
-

led(4) - Interface

-

The acpi_ibm driver provides a - led(4) interface for the ThinkLight. The ThinkLight can be - made to blink by writing ASCII strings to the - /dev/led/thinklight device.

-
-
-
-

-

The following sysctls are currently implemented:

-
-
dev.acpi_ibm.0.initialmask
-
(read-only) Bitmask of ACPI events before the - acpi_ibm driver was loaded.
-
dev.acpi_ibm.0.availmask
-
(read-only) Bitmask of all supported ACPI events.
-
dev.acpi_ibm.0.events
-
Enable ACPI events and set the eventmask to - availmask. Without the - acpi_ibm driver being loaded, only the Fn+F4 - button generates an ACPI event.
-
dev.acpi_ibm.0.eventmask
-
Sets the ACPI events which are reported to devd(8). - Fn+F3, Fn+F4 and Fn+F12 always generate ACPI events, regardless which - value eventmask has. Depending on the ThinkPad - model, the meaning of different bits in the - eventmask may vary. On a ThinkPad T41p this is a - bitwise OR of the following: -

-
-
-
Fn + F1
-
-
Fn + F2
-
-
Fn + F3 (LCD backlight)
-
-
Fn + F4 (Suspend to RAM)
-
-
Fn + F5 (Bluetooth)
-
-
Fn + F6
-
-
Fn + F7 (Screen expand)
-
-
Fn + F8
-
-
Fn + F9
-
-
Fn + F10
-
-
Fn + F11
-
-
Fn + F12 (Suspend to disk)
-
-
Fn + Backspace
-
-
Fn + Insert
-
-
Fn + Delete
-
-
Fn + Home (Brightness up)
-
-
Fn + End (Brightness down)
-
-
Fn + PageUp (ThinkLight)
-
-
Fn + PageDown
-
-
Fn + Space (Zoom)
-
-
Volume Up
-
-
Volume Down
-
-
Mute
-
-
Access IBM Button
-
-
-
dev.acpi_ibm.0.hotkey
-
(read-only) Status of several buttons. Every time a button is pressed, the - respecting bit is toggled. It is a bitwise OR of the following: -

-
-
-
Home Button
-
-
Search Button
-
-
Mail Button
-
-
Access IBM Button
-
-
Zoom
-
-
Wireless LAN Button
-
-
Video Button
-
-
Hibernate Button
-
-
ThinkLight Button
-
-
Screen Expand
-
-
Brightness Up/Down Button
-
-
Volume Up/Down/Mute Button
-
-
-
dev.acpi_ibm.0.lcd_brightness
-
Current brightness level of the display.
-
dev.acpi_ibm.0.volume
-
Speaker volume.
-
dev.acpi_ibm.0.mute
-
Indicates, whether the speakers are muted or not.
-
dev.acpi_ibm.0.mic_mute
-
Indicates, whether the microphone led (present on some model) is on or - not. Note that this does not mean that the microphone input is muted.
-
dev.acpi_ibm.0.thinklight
-
Indicates, whether the ThinkLight keyboard light is activated or not.
-
dev.acpi_ibm.0.bluetooth
-
Toggle Bluetooth chip activity.
-
dev.acpi_ibm.0.wlan
-
(read-only) Indicates whether the WLAN chip is active or not.
-
dev.acpi_ibm.0.fan
-
Indicates whether the fan is in automatic (1) or manual (0) mode. Default - is automatic mode. This sysctl should be used with extreme precaution, - since disabling automatic fan control might overheat the ThinkPad and lead - to permanent damage if the fan_level is not set - accordingly.
-
dev.acpi_ibm.0.fan_level
-
Indicates at what speed the fan should run when being in manual mode. - Valid values range from 0 (off) to 7 (max) and 8. Level 8 is used by the - driver to set the fan in unthrottled mode. In this mode, the fan is set to - spin freely and will quickly reach a very high speed. Use this mode only - if absolutely necessary, e.g., if the system has reached its critical - temperature and it is about to shut down. The resulting speed differs from - model to model. On a T41p this is as follows: -

-
-
-
off
-
-
~3000 RPM
-
-
~3600 RPM
-
-
~4300 RPM
-
-
~6400 RPM (Full-speed, unthrottled)
-
-
-
dev.acpi_ibm.0.fan_speed
-
(read-only) Fan speed in rounds per minute. A few older ThinkPads report - the fan speed in levels ranging from 0 (off) to 7 (max).
-
dev.acpi_ibm.0.thermal
-
(read-only) Shows the readings of up to eight different temperature - sensors. Most ThinkPads include six or more temperature sensors but only - expose the CPU temperature through acpi_thermal(4). Some - ThinkPads have the below sensor layout which might vary depending on the - specific model: -

-
    -
  1. CPU
    2. -
  2. Mini PCI Module
    3. -
  3. HDD
    4. -
  4. GPU
    5. -
  5. Built-in battery
    6. -
  6. UltraBay battery
    7. -
  7. Built-in battery
    8. -
  8. UltraBay battery
    9. -
-
-
dev.acpi_ibm.0.handlerevents
-
devd(8) events handled by - acpi_ibm when events is set - to 1. Events are specified as a whitespace-separated list of event code in - hexadecimal or decimal form. Note that the event maybe handled twice - (e.g., Brightness up/down) if ACPI BIOS already handled the event.
-
-

Defaults for these sysctls can be set in - sysctl.conf(5).

-
-
-

-
-
/dev/led/thinklight
-
ThinkLight led(4) device node
-
-
-
-

-

The following can be added to devd.conf(5) in - order to pass button events to a - /usr/local/sbin/acpi_oem_exec.sh script:

-
-
notify 10 {
-        match "system"          "ACPI";
-        match "subsystem"       "IBM";
-        action "/usr/local/sbin/acpi_oem_exec.sh $notify ibm";
-};
-
-

A possible - /usr/local/sbin/acpi_oem_exec.sh script might look - like:

-
-
#!/bin/sh
-#
-if [ "$1" = "" -o "$2" = "" ]
-then
-        echo "usage: $0 notify oem_name"
-        exit 1
-fi
-NOTIFY=`echo $1`
-LOGGER="logger"
-CALC="bc"
-BC_PRECOMMANDS="scale=2"
-ECHO="echo"
-CUT="cut"
-MAX_LCD_BRIGHTNESS=7
-MAX_VOLUME=14
-OEM=$2
-DISPLAY_PIPE=/tmp/acpi_${OEM}_display
-
-case ${NOTIFY} in
-        0x05)
-                LEVEL=`sysctl -n dev.acpi_${OEM}.0.bluetooth`
-                if [ "$LEVEL" = "1" ]
-                then
-                        sysctl dev.acpi_${OEM}.0.bluetooth=0
-                        MESSAGE="bluetooth disabled"
-                else
-                        sysctl dev.acpi_${OEM}.0.bluetooth=1
-                        MESSAGE="bluetooth enabled"
-                fi
-                ;;
-        0x10|0x11)
-                LEVEL=`sysctl -n dev.acpi_${OEM}.0.lcd_brightness`
-                PERCENT=`${ECHO} "${BC_PRECOMMANDS} ; \
-                         ${LEVEL} / ${MAX_LCD_BRIGHTNESS} * 100" |\
-                         ${CALC} | ${CUT} -d . -f 1`
-                MESSAGE="brightness level ${PERCENT}%"
-                ;;
-        0x12)
-                LEVEL=`sysctl -n dev.acpi_${OEM}.0.thinklight`
-                if [ "$LEVEL" = "1" ]
-                then
-                        MESSAGE="thinklight enabled"
-                else
-                        MESSAGE="thinklight disabled"
-                fi
-                ;;
-        0x15|0x16)
-                LEVEL=`sysctl -n dev.acpi_${OEM}.0.volume`
-                PERCENT=`${ECHO} "${BC_PRECOMMANDS} ; \
-                        ${LEVEL} / ${MAX_VOLUME} * 100" | \
-                         ${CALC} | ${CUT} -d . -f 1`
-                MESSAGE="volume level ${PERCENT}%"
-                ;;
-        0x17)
-                LEVEL=`sysctl -n dev.acpi_${OEM}.0.mute`
-                if [ "$LEVEL" = "1" ]
-                then
-                        MESSAGE="volume muted"
-                else
-                        MESSAGE="volume unmuted"
-                fi
-                ;;
-	0x1b)
-		LEVEL=`sysctl -n dev.acpi_ibm.0.mic_led`
-		if [ $LEVEL -eq 0 ]; then
-			sysctl dev.acpi_ibm.0.mic_led=1
-			mixer rec.volume=0
-		fi
-		if [ $LEVEL -eq 1 ]; then
-			sysctl dev.acpi_ibm.0.mic_led=0
-			mixer rec.volume=30%
-		fi
-		;;
-        *)
-                ;;
-esac
-${LOGGER} ${MESSAGE}
-if [ -p ${DISPLAY_PIPE} ]
-then
-        ${ECHO} ${MESSAGE} >> ${DISPLAY_PIPE} &
-fi
-exit 0
-
-

The following example specify that event code 0x04 (Suspend to - RAM), 0x10 (Brightness up) and 0x11 (Brightness down) are handled by - acpi_ibm.

-
-
sysctl dev.acpi_ibm.0.handlerevents='0x04 0x10 0x11'
-
-

in sysctl.conf(5):

-
-
dev.acpi_ibm.0.handlerevents=0x04\ 0x10\ 0x11
-
-
-
-

-

acpi(4), led(4), - sysctl.conf(5), devd(8), - sysctl(8)

-
-
-

-

The acpi_ibm device driver first appeared - in FreeBSD 6.0.

-
-
-

-

The acpi_ibm driver was written by - Takanori Watanabe - <takawata@FreeBSD.org> - and later mostly rewritten by Markus Brueffer - <markus@FreeBSD.org>. - This manual page was written by Christian Brueffer - <brueffer@FreeBSD.org> - and Markus Brueffer - <markus@FreeBSD.org>.

-
-
- - - - - -
March 13, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_panasonic.4 3.html b/static/freebsd/man4/acpi_panasonic.4 3.html deleted file mode 100644 index 97ab84c8..00000000 --- a/static/freebsd/man4/acpi_panasonic.4 3.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - -
ACPI_PANASONIC(4)Device Drivers ManualACPI_PANASONIC(4)
-
-
-

-

acpi_panasonic — - ACPI hotkey driver for Panasonic laptops

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_panasonic
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_panasonic_load="YES"
-
-
-
-

-

The acpi_panasonic driver enables such - hotkey facilities of various Panasonic laptops as changing LCD brightness, - controlling mixer volumes, entering sleep or suspended state and so on. On - the following models it is reported to work: Let's note (or Toughbook, - outside Japan) CF-R1N, CF-R2A and CF-R3. It may also work on other models as - well.

-

The driver consists of three functionalities. The first is to - detect hotkey events and take corresponding actions, which include changing - LCD luminance and speaker mute state. The second role is to notify - occurrences of the event by way of devctl(4) and - eventually to devd(8). The third and last is to provide a - way to adjust LCD brightness and sound mute state via - sysctl(8).

-
-

-

There are 9 hotkeys available on the supported hardware:

-

-
-
-
-
Make LCD backlight darker.
-
-
Make LCD backlight brighter.
-
-
Switch video output between LCD and CRT. Not supported by the - acpi_panasonic driver.
-
-
Toggle muting the speaker.
-
-
Turn the mixer volume down.
-
-
Turn the mixer volume up.
-
-
Enter suspend-to-RAM state.
-
-
Show battery status.
-
-
Enter suspend-to-disk state.
-
-
-

Actions are automatically taken within the driver for - Fn+F1, Fn+F2 and - Fn+F4. For the other events such as mixer control and - showing battery status, devd(8) should take the role as - described below.

-
-
-

devd(8) - Events

-

When notified to devd(8), the hotkey event - provides the following information:

-

-
-
-
system
-
"ACPI"
-
subsystem
-
"Panasonic"
-
type
-
The source of the event in ACPI namespace. The value depends on the model - but typically "\_SB_.HKEY".
-
notify
-
Event code (see below).
-
-
-

Event codes to be generated are assigned as follows:

-
-
-
0x81-0x86, 0x89
-
- pressed. 0x81 corresponds to Fn+F1, 0x82 corresponds to - Fn+F2, and so on.
-
0x01-0x07, 0x09, 0x1a
-
- released. 0x01 corresponds to Fn+F1, 0x02 corresponds to - Fn+F2, and so on.
-
-
-
-
-
-

-

The following MIBs are available:

-
-
hw.acpi.panasonic.lcd_brightness_max
-
The maximum level of brightness. This read-only value is automatically set - according to hardware model.
-
hw.acpi.panasonic.lcd_brightness_min
-
The minimum level of brightness. This read-only value is automatically set - according to hardware model.
-
hw.acpi.panasonic.lcd_brightness
-
Current brightness level of the LCD (read-write). The value ranges from - hw.acpi.panasonic.lcd_brightness_min to - hw.acpi.panasonic.lcd_brightness_max.
-
hw.acpi.panasonic.sound_mute
-
A read-write boolean flag to control whether to mute the speaker. The - value 1 means to mute and 0 not.
-
-
-
-

-

acpi(4), devd.conf(5), - devd(8), sysctl(8)

-
-
-

-

The acpi_panasonic driver first appeared - in FreeBSD 5.3.

-
-
-

-

The acpi_panasonic driver and this manual - page were written by OGAWA Takaya - <t-ogawa@triaez.kaisei.org> - and TAKAHASHI Yoshihiro - <nyan@FreeBSD.org>.

-
-
- - - - - -
June 19, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_rapidstart.4 3.html b/static/freebsd/man4/acpi_rapidstart.4 3.html deleted file mode 100644 index 9754586a..00000000 --- a/static/freebsd/man4/acpi_rapidstart.4 3.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
ACPI_RAPIDSTART(4)Device Drivers ManualACPI_RAPIDSTART(4)
-
-
-

-

acpi_rapidstart — - Intel rapid start technology ACPI driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device - acpi_rapidstart
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_rapidstart_load="YES"
-
-
-
-

-

The acpi_rapidstart driver provides - support for Intel Rapid Start technology ACPI device interface. Note that - this is only for the ACPI device interface. This has _CID PNP0C02 so it - should be loaded at boot time to avoid attaching to the acpi_sysresource - driver.

-
-
-

-

The following sysctl(8) nodes are currently - implemented:

-
-
dev.acpi_rapidstart.0.ffs
-
Rapid start flag. It is a bitwise OR of the following: -

-
-
-
Enter Fast Flash Standby in RTC wake.
-
-
Enter Fast Flash Standby in Critical Battery Wake enable
-
-
-
dev.acpi_rapidstart.0.ftv
-
Fast Flash Standby timer value in minutes.
-
-
-
-

-

acpi(4), sysctl(8)

-
-
-

-

The acpi_rapidstart driver first appeared - in FreeBSD 10.0.

-
-
-

-

The acpi_rapidstart driver was written by - Takanori Watanabe - <takawata@FreeBSD.org>.

-
-
- - - - - -
May 8, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_sony.4 4.html b/static/freebsd/man4/acpi_sony.4 4.html deleted file mode 100644 index 8805885b..00000000 --- a/static/freebsd/man4/acpi_sony.4 4.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
ACPI_SONY(4)Device Drivers ManualACPI_SONY(4)
-
-
-

-

acpi_sony — ACPI - notebook controller driver for Sony laptops

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_sony
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_sony_load="YES"
-
-
-
-

-

The acpi_sony driver provides support for - the notebook controller in Sony laptops. Note that not all features will - work on all laptop models.

-
-
-

-

The following sysctl nodes are currently implemented:

-
-
dev.acpi_sony.0.brightness
-
Current brightness level of the display.
-
dev.acpi_sony.0.brightness_default
-
Default brightness level of the display (survives reboot).
-
dev.acpi_sony.0.contrast
-
Current contrast level of the display.
-
dev.acpi_sony.0.bass_gain
-
Enable or disable the Bass Gain feature.
-
dev.acpi_sony.0.cdp
-
Turns the CD power on or off.
-
dev.acpi_sony.0.azp
-
Turns the audio power on or off.
-
dev.acpi_sony.0.lnp
-
Turns the wired network interface power on or off.
-
-
-
-

-

acpi(4), sysctl(8)

-
-
-

-

The acpi_sony driver first appeared in - FreeBSD 6.0.

-
-
-

-

The acpi_sony driver was written by - Takanori Watanabe - <takawata@FreeBSD.org>.

-
-
- - - - - -
February 8, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_thermal.4 3.html b/static/freebsd/man4/acpi_thermal.4 3.html deleted file mode 100644 index aae47629..00000000 --- a/static/freebsd/man4/acpi_thermal.4 3.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - -
ACPI_THERMAL(4)Device Drivers ManualACPI_THERMAL(4)
-
-
-

-

acpi_thermal — - ACPI thermal management subsystem

-
-
-

-

device acpi

-
-
-

-

The acpi_thermal driver provides the - thermal management features of the ACPI module. This driver has a - sysctl(8) interface and a devd(8) - notification interface. The sysctls export properties of each ACPI thermal - zone object.

-

There can be multiple thermal zones in a system. For example, each - CPU and the enclosure could all be separate thermal zones, each with its own - setpoints and cooling devices. Thermal zones are numbered sequentially in - the order they appear in the AML.

-

The acpi_thermal driver also activates the - active cooling system according to each thermal zone's setpoints.

-
-
-

-
-
hw.acpi.thermal.min_runtime
-
Number of seconds to continue active cooling once started. A new active - cooling level will not be selected until this interval expires.
-
hw.acpi.thermal.polling_rate
-
Number of seconds between polling the current temperature.
-
hw.acpi.thermal.user_override
-
If set to 1, allow user override of various setpoints (below). The - original values for these settings are obtained from the BIOS and system - overheating and possible damage could occur if changed. Default is 0 (no - override).
-
hw.acpi.thermal.tz%d.active
-
Current active cooling system state. If this is non-negative, the - appropriate _AC%d object is running. Set this value to the desired active - cooling level to force the corresponding fan object to the appropriate - level.
-
hw.acpi.thermal.tz%d.passive_cooling
-
If set to 1, passive cooling is enabled. It does cooling without fans - using cpufreq(4) as the mechanism for controlling CPU - speed. Default is enabled for tz0 where it is available.
-
hw.acpi.thermal.tz%d.thermal_flags
-
Current thermal zone status. These are bit-masked values.
-
hw.acpi.thermal.tz%d.temperature
-
Current temperature for this zone.
-
hw.acpi.thermal.tz%d._PSV
-
Temperature to start passive cooling by throttling down CPU, etc. This - value can be overridden by the user.
-
hw.acpi.thermal.tz%d._CR3
-
Temperature to start critical suspend to RAM (S3). This value can be - overridden by the user.
-
hw.acpi.thermal.tz%d._HOT
-
Temperature to start critical suspend to disk (S4). This value can be - overridden by the user.
-
hw.acpi.thermal.tz%d._CRT
-
Temperature to start critical shutdown (S5). This value can be overridden - by the user.
-
hw.acpi.thermal.tz%d._ACx
-
Temperatures at which to switch to the corresponding active cooling level. - The lower the _ACx value, the higher the cooling power.
-
-

All temperatures are printed in Celsius. Values can be set in - Celsius (by providing a trailing "C") or Kelvin (by leaving off - any trailing letter). When setting a value by sysctl(8), - do not specify a trailing decimal (i.e., 90C instead of 90.0C).

-
-
-

-

Notifies are passed to userland via devd(8). See - /etc/devd.conf and devd.conf(5) - for examples. The acpi_thermal driver sends events - with the following attributes:

-

-
-
system
-
-
subsystem
-
-
type
-
The fully qualified thermal zone object path as in the ASL.
-
notify
-
An integer designating the event: -

-
-
-
Current temperature has changed.
-
-
One or more trip points (_ACx, _PSV) have changed.
-
-
One or more device lists (_ALx, _PSL, _TZD) have changed.
-
-
Non-standard notify that the system will shutdown if the temperature - stays above _CRT or _HOT for one more poll cycle.
-
-
-
-
-
-

-

acpi(4), cpufreq(4), - acpidump(8)

-
-
-

-

Michael Smith

-

This manual page was written by Takanori - Watanabe.

-
-
- - - - - -
November 21, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_toshiba.4 3.html b/static/freebsd/man4/acpi_toshiba.4 3.html deleted file mode 100644 index 7fc2902d..00000000 --- a/static/freebsd/man4/acpi_toshiba.4 3.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - -
ACPI_TOSHIBA(4)Device Drivers ManualACPI_TOSHIBA(4)
-
-
-

-

acpi_toshiba — - Toshiba HCI interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device acpi_toshiba
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
acpi_toshiba_load="YES"
-
-
-
-

-

HCI is Toshiba's - which is somewhat uniform across their models. The - acpi_toshiba driver allows the user to manipulate - HCI-controlled hardware using a number of sysctl(8) - variables.

-
-
-

-

The following sysctls are currently implemented:

-
-
hw.acpi.toshiba.force_fan
-
Causes active cooling to be forcibly enabled - (‘1’) or disabled - (‘0’) regardless of the current - temperature.
-
hw.acpi.toshiba.video_output
-
Sets the active display to use according to a bitwise OR of the following: -

-
-
-
No display
-
-
LCD
-
-
CRT
-
-
TV-Out
-
-

Only some systems (i.e., the Libretto L5) support video - switching via this hardware-specific driver. Use the - acpi_video(4) driver for generic video output - support.

-
-
hw.acpi.toshiba.lcd_brightness
-
Makes the LCD backlight brighter or dimmer (higher values are - brighter).
-
hw.acpi.toshiba.lcd_backlight
-
Turns the LCD backlight on and off.
-
hw.acpi.toshiba.cpu_speed
-
Sets the CPU speed to the specified speed. This provides functionality - similar to the hw.acpi.cpu.throttle_state variable. - Higher sysctl values mean lower CPU speeds.
-
-

Defaults for these variables can be set in - sysctl.conf(5), which is parsed at boot-time.

-
-
-

-

The hw.acpi.toshiba.enable_fn_keys tunable - enables or disables the function keys on the keyboard. Function keys are - enabled by default.

-

This behaviour can be changed at the loader(8) - prompt or in loader.conf(5).

-
-
-

-

acpi(4), acpi_video(4), - loader.conf(5), sysctl.conf(5), - sysctl(8)

-
-
-

-

The acpi_toshiba driver first appeared in - FreeBSD 5.1.

-
-
-

-

The acpi_toshiba driver was written by - Hiroyuki Aizu - <aizu@navi.org>. This - manual page was written by Philip Paeps - <philip@FreeBSD.org>.

-
-
- - - - - -
February 8, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_video.4 3.html b/static/freebsd/man4/acpi_video.4 3.html deleted file mode 100644 index 642ee8dd..00000000 --- a/static/freebsd/man4/acpi_video.4 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
ACPI_VIDEO(4)Device Drivers ManualACPI_VIDEO(4)
-
-
-

-

acpi_video — ACPI - Video Extensions driver

-
-
-

-

device acpi_video

-
-
-

-

This driver uses the ACPI Video Extensions to control display - switching and backlight brightness. The availability of the - sysctl(8) variables depends on the functions offered by - the host's ACPI implementation.

-
-
-

-

The following sysctls are currently implemented, where - ⟨device⟩ is crt, - lcd, or tv:

-
-
hw.acpi.video.⟨device⟩.active
-
Current state of the output device.
-
hw.acpi.video.⟨device⟩.levels
-
List of supported brightness levels.
-
hw.acpi.video.⟨device⟩.brightness
-
Current brightness level of the device.
-
hw.acpi.video.⟨device⟩.fullpower
-
Preset brightness level to be used in full power mode.
-
hw.acpi.video.⟨device⟩.economy
-
Preset brightness level to be used in economy mode.
-
-

Defaults for these variables can be set in - sysctl.conf(5), which is parsed at boot-time.

-
-
-

-

In order for acpi_video to attach - correctly, acpi_video should be loaded after any of - the DRM kernel modules. This can be achieved by setting the correct order in - rc.conf(5) using the kld_list directive.

-
-
-

-

acpi(4), loader.conf(5), - sysctl.conf(5), sysctl(8)

-
-
-

-

The acpi_video driver first appeared in - FreeBSD 5.3.

-
-
-

-

The acpi_video driver was written by - Taku YAMAMOTO - <taku@cent.saitama-u.ac.jp>. - This manual page was written by Mark Santcroos - <marks@ripe.net>.

-
-
-

-

Some systems only perform output switching via SMM even though - they export the proper information via ACPI. On such systems, the proper - hotkeys or OEM driver (for example, acpi_toshiba(4)) must - be used instead.

-
-
- - - - - -
November 8, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/acpi_wmi.4 3.html b/static/freebsd/man4/acpi_wmi.4 3.html deleted file mode 100644 index 6c65a826..00000000 --- a/static/freebsd/man4/acpi_wmi.4 3.html +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - -
ACPI_WMI(4)Device Drivers ManualACPI_WMI(4)
-
-
-

-

acpi_wmi — ACPI to - WMI mapping driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-

-
device - acpi_wmi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-

-
acpi_wmi_load="YES"
-
-
-

-

The acpi_wmi driver provides an interface - for vendor specific WMI implementations (e.g. HP and Acer laptops). It - creates /dev/wmistat%d, which can be read to get - information about GUIDs found in the system.

-
-
-

-
-
/dev/wmistat%d
-
WMI status devices.
-
-
-
-

-

The following sysctl node is currently implemented:

-
-
dev.acpi_wmi.%d.bmof
-
binary Managed Object Format (MOF) buffer
-
-
-
-

-

Read GUIDs from the first WMI interface found in the system:

-
-
# cat /dev/wmistat0
-GUID                                  INST EXPE METH STR EVENT OID
-{5FB7F034-2C63-45E9-BE91-3D44E2C707E4}   1 NO   WMAA NO  NO    AA
-{95F24279-4D7B-4334-9387-ACCDC67EF61C}   1 NO   NO   NO  0x80+ -
-{2B814318-4BE8-4707-9D84-A190A859B5D0}   1 NO   NO   NO  0xA0  -
-{05901221-D566-11D1-B2F0-00A0C9062910}   1 NO   NO   NO  NO    AB
-{1F4C91EB-DC5C-460B-951D-C7CB9B4B8D5E}   1 NO   WMBA NO  NO    BA
-{2D114B49-2DFB-4130-B8FE-4A3C09E75133}  57 NO   NO   NO  NO    BC
-{988D08E3-68F4-4C35-AF3E-6A1B8106F83C}  20 NO   NO   NO  NO    BD
-{14EA9746-CE1F-4098-A0E0-7045CB4DA745}   1 NO   NO   NO  NO    BE
-{322F2028-0F84-4901-988E-015176049E2D}   2 NO   NO   NO  NO    BF
-{8232DE3D-663D-4327-A8F4-E293ADB9BF05}   0 NO   NO   NO  NO    BG
-{8F1F6436-9F42-42C8-BADC-0E9424F20C9A}   0 NO   NO   NO  NO    BH
-{8F1F6435-9F42-42C8-BADC-0E9424F20C9A}   0 NO   NO   NO  NO    BI
-
-

Read first WMI interface description with - from - ports/converters/bmfdec:

-
-
# sysctl -b dev.acpi_wmi.0.bmof | bmf2mof
-[abstract]
-class Lenovo_BIOSElement {
-};
-
-[WMI, Dynamic, Provider("WMIProv"), WmiExpense(1), Description("Bios Setting"),
-GUID("{51F5230E-9677-46cd-A1CF-C0B23EE34DB7}"), Locale("MS\0x409")]
-class Lenovo_BiosSetting : Lenovo_BiosElement {
-  [key, read] String InstanceName;
-    [read] Boolean Active;
-      [WmiDataId(1), Description("BIOS setting")] String CurrentSetting;
-      };
-   ...
-
-
-
-

-

acpi(4)

-
-
-

-

Windows Instrumentation: WMI - and ACPI, Microsoft Corporation, - https://github.com/microsoft/Windows-driver-samples/tree/main/wmi/wmiacpi.

-
-
-

-

The acpi_wmi device driver first appeared - in FreeBSD 8.0.

-
-
-

-

The acpi_wmi driver was written by - Michael Gmelin - <freebsd@grem.de>.

-

Work inspired by the Linux - driver - written by Carlos Corbacho.

-

MOF handling inspired by the Linux - driver - written by Andy Lutomirski.

-

This manual page was written by Michael - Gmelin - <freebsd@grem.de>.

-
-
- - - - - -
June 12, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ada.4 3.html b/static/freebsd/man4/ada.4 3.html deleted file mode 100644 index 3ef5f31e..00000000 --- a/static/freebsd/man4/ada.4 3.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - -
ADA(4)Device Drivers ManualADA(4)
-
-
-

-

ada — ATA Direct - Access device driver

-
-
-

-

device ada

-
-
-

-

The ada driver provides support for direct - access devices, implementing the ATA command protocol, that are attached to - the system through a host adapter supported by the CAM subsystem.

-

The host adapter must also be separately configured into the - system before an ATA direct access device can be configured.

-
-
-

-

Command queuing allows the device to process multiple transactions - concurrently, often re-ordering them to reduce the number and length of - seeks. ATA defines two types of queuing: TCQ (Tagged Command Queuing, PATA - legacy) and NCQ (Native Command Queuing, SATA). The - ada device driver takes full advantage of NCQ, when - supported. To ensure that transactions to distant parts of the media, which - may be deferred indefinitely by servicing requests closer to the current - head position, are completed in a timely fashion, an ordered transaction is - sent every 7 seconds during continuous device operation.

-
-
-

-

Many direct access devices are equipped with read and/or write - caches. Parameters affecting the device's cache are reported in device - IDENTIFY data and can be examined and modified via the - camcontrol(8) utility.

-

The read cache is used to store data from device-initiated read - ahead operations as well as frequently used data. The read cache is - transparent to the user and can be enabled without any adverse effect. Most - devices with a read cache come from the factory with it enabled.

-

The write cache can greatly decrease the latency of write - operations and allows the device to reorganize writes to increase efficiency - and performance. This performance gain comes at a price. Should the device - lose power while its cache contains uncommitted write operations, these - writes will be lost. The effect of a loss of write transactions on a file - system is non-deterministic and can cause corruption. Most devices age write - transactions to limit the vulnerability to a few transactions recently - reported as complete, but it is nonetheless recommended that systems with - write cache enabled devices reside on an Uninterruptible Power Supply (UPS). - The ada device driver ensures that the cache and - media are synchronized upon final close of the device or an unexpected - shutdown (panic) event. This ensures that it is safe to disconnect power - once the operating system has reported that it has halted.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.cam.ada.retry_count
-
-

This variable determines how many times the - ada driver will retry a READ or WRITE command. - This does not affect the number of retries used during probe time or for - the ada driver dump routine. This value - currently defaults to 4.

-
-
kern.cam.ada.default_timeout
-
-

This variable determines how long the - ada driver will wait before timing out an - outstanding command. The units for this value are seconds, and the - default is currently 30 seconds.

-
-
kern.cam.ada.spindown_shutdown
-
-

This variable determines whether to spin-down disks when - shutting down. Set to 1 to enable spin-down, 0 to disable. The default - is currently enabled.

-
-
kern.cam.sort_io_queue
-
 
-
kern.cam.ada.X.sort_io_queue
-
-

These variables determine whether request queue should be - sorted trying to optimize head seeks. Set to 1 to enable sorting, 0 to - disable, -1 to leave it as-is. The default is sorting enabled for HDDs - and disabled SSDs.

-
-
kern.cam.ada.read_ahead
-
 
-
kern.cam.ada.X.read_ahead
-
 
-
kern.cam.ada.write_cache
-
 
-
kern.cam.ada.X.write_cache
-
-

These variables determine whether device read-ahead and write - caches should be enabled globally or per-device or disabled. Set to 1 to - enable write cache, 0 to disable, -1 to leave it as-is. Values modified - at runtime take effect only after device reset (using the reset - subcommand of camcontrol(8)). Because of that, this - setting should be changed in /boot/loader.conf - instead of /etc/sysctl.conf. The global default - is currently 1. The per-device default is to leave it as-is (follow - global setting).

-
-
-
-
-

-
-
/dev/ada*
-
ATA device nodes
-
-
-
-

-

ahci(4), cam(4), - da(4), mvs(4), nda(4), - siis(4)

-
-
-

-

The ada driver first appeared in - FreeBSD 8.0.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org>

-
-
- - - - - -
December 20, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/adm6996fc.4 4.html b/static/freebsd/man4/adm6996fc.4 4.html deleted file mode 100644 index c9e3c76d..00000000 --- a/static/freebsd/man4/adm6996fc.4 4.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
ADM6996FC(4)Device Drivers ManualADM6996FC(4)
-
-
-

-

adm6996fc — driver - for Infineon ADM6996FC fast ethernet switch chip

-
-
-

-

device mdio -
- device etherswitch -
- device adm6996fc

-

-
- hint.adm6996fc.0.at="mdio0"

-
-
-

-

The adm6996fc device driver provides a - management interface to Infineon ADM6996FC fast ethernet switch chip. This - driver use smi interface by ethernet interface.

-

This driver support is port and dot1q vlan. dot1q support port - base tag/untag.

-
-
-

-

Configure dot1q vlan by etherswitchcfg command.

-

-
# etherswitchcfg config vlan_mode - dot1q
-

Configure port 5 is tagging port.

-

-
# etherswitchcfg port5 - addtag
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The adm6996fc device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The adm6996fc driver was written by - Hiroki Mori

-
-
- - - - - -
April 5, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ads111x.4 3.html b/static/freebsd/man4/ads111x.4 3.html deleted file mode 100644 index 167aed20..00000000 --- a/static/freebsd/man4/ads111x.4 3.html +++ /dev/null @@ -1,223 +0,0 @@ - - - - - - -
ADS111x(4)Device Drivers ManualADS111x(4)
-
-
-

-

ads111x — driver - for ADS101x and ADS111x i2c analog to digital converters

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ads111x
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ads111x_load="YES"
-
-
-
-

-

The ads111x driver provides support for - the ADS101x/ADS111x family of analog to digital converter (ADC) devices. The - supported devices are all similar to each other, varying in features such as - resolution and number of input channels. The devices offer a number of - configuration options which can be set via hints, FDT data, and - sysctl(8).

-

The sysctl(8) utility provides access to the - voltage measurements made by the device. Each time the - dev.ads111x.<unit>.<channel>.voltage - variable is accessed for a given channel, the driver switches the chip's - internal mux to choose the right input pins for that channel, directs it to - make a single measurement, and returns the measured value in microvolts. The - amount of time required to make the measurement is a function of the - sampling rate configured for the device. While device is directed to make a - single measurement, it still averages the input values for the same amount - of time as it would to emit one sample if it were in continuous mode. For - example, if the sample rate were configured as 125 samples per second, a - single measurement would require 8 milliseconds.

-

For devices that support multiple input pins, the device datasheet - describes mux settings to control how those pins are interpreted when making - either single-ended or differential measurements. There are eight possible - ways to combine the inputs from the four pins. The - ads111x driver models that by creating a separate - output channel for each of the eight combinations. To make a measurement on - a given pin or pair of pins, you simply access the voltage variable for the - channel number that corresponds the mux setting number (0 through 7) shown - in the datasheet. When the driver is configured with hints or FDT data, it - creates sysctl variables for just the channels specified in the config data. - When there is no channel config data, it creates all eight possible channels - so that you can access whichever one(s) you need.

-

For devices that include an alert output - pin, the ads111x driver does not directly support - the pin in terms of sensing or acting on changes in the pin state. However, - you may connect the pin to a gpio input or fan controller or other external - device, and use the driver's sysctl variables to configure behavior and - threshold values for the pin. The driver avoids perturbing your settings as - it does other manipulations to the config register.

-
-
-

-

Sysctl variables are used to access the voltage measurements, and - to change the configuration of the channels. All writeable variables may - also be set as loader(8) tunables. Channel numbers in - these sysctl variables range from 0 through 7.

-
-
dev.ads111x.<unit>.config
-
Provides access to the configuration register bits that control the alert - pin configuration. Other bits which are controlled by the driver are - masked out, and cannot be viewed or changed using this variable.
-
dev.ads111x.<unit>.lo_thresh
-
Sets the low threshold for activating the alert pin.
-
dev.ads111x.<unit>.hi_thresh
-
Sets the high threshold for activating the alert pin.
-
dev.ads111x.<unit>.<channel>.rate_index
-
Sets the sample rate for the channel. The device datasheet documents eight - available sample rates, chosen by setting a value of 0 through 7 into the - corresponding control register bits. This variable sets the value used for - those bits when making a measurement on the given channel. -

Because measurements are always made in single-shot mode, - think of this variable as controlling the averaging time for a single - sample; the time to make a measurement is 1 / samplerate.

-
-
dev.ads111x.<unit>.<channel>.gain_index
-
Sets the programmable gain amplifier for the channel on devices which have - an internal amplifier. The device datasheet documents eight available gain - values, chosen by setting a value of 0 through 7 into the corresponding - control register bits. This variable sets the value used for those bits - when making a measurement on the given channel.
-
dev.ads111x.<unit>.<channel>.voltage
-
Reading this variable causes the device to make a measurement on the - corresponding input pin(s) and return the voltage in microvolts. -

Note that this variable does not appear when you list multiple - sysctl variables -- you must access it specifically by name, because - accessing it triggers device I/O.

-
-
-
-
-

-

The ads111x driver provides support for - the following devices:

-

- - - - - - - - - - - - - -
ADS1013ADS1113
ADS1014ADS1114
ADS1015ADS1115
-
-
-

-

On an fdt(4) based system, the - ads111x device is defined as a slave device subnode - of the i2c bus controller node. All properties documented in the - ads1015.txt bindings document can be used with the - ads111x device.

-

The following properties are required in the - ads111x device subnode:

-
-
compatible
-
One of the following: - - - - - - - - - - - - - -
“ti,ads1013”“ti,ads1113”
“ti,ads1014”“ti,ads1114”
“ti,ads1015”“ti,ads1115”
-
-
reg
-
I2c slave address of device.
-
-

Specific channels can be configured by adding child nodes to the - ads111x node, as described in the standard - ads1015.txt bindings document. If no channels are configured, sysctl - variables will be created for all possible channels supported by the device - type, otherwise only the specified channels are created.

-
-

-
-
adc@48 {
-    compatible = "ti,ads1115";
-    reg = <0x48>;
-    status = "okay";
-    #address-cells = <1>;
-    #size-cells = <0>;
-
-    channel@6 {
-        reg = <6>;
-        ti,gain = <3>;
-        ti,datarate = <4>;
-    };
-    channel@7 {
-        reg = <7>;
-        ti,gain = <1>;
-        ti,datarate = <7>;
-    };
-};
-
-
-
-
-

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - ads111x:

-
-
hint.ads111x.<unit>.at
-
The iicbus instance the ads111x instance is - attached to.
-
hint.ads111x.<unit>.<channel>.gain_index
-
The amplifier gain, as described above for the sysctl variable - dev.ads111x.<unit>.<channel>.gain_index.
-
hint.ads111x.<unit>.<channel>.rate_index
-
The sample rate, as described above for the sysctl variable - dev.ads111x.<unit>.<channel>.rate_index.
-
-

If no channels are configured, sysctl variables will be created - for all possible channels supported by the device type, otherwise only the - specified channels are created.

-
-
-

-

fdt(4), sysctl(8)

-
-
-

-

The ads111x driver first appeared in - FreeBSD 13.0.

-
-
- - - - - -
September 2, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ae.4 3.html b/static/freebsd/man4/ae.4 3.html deleted file mode 100644 index 71d58eed..00000000 --- a/static/freebsd/man4/ae.4 3.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - -
AE(4)Device Drivers ManualAE(4)
-
-
-

-

ae — - Attansic/Atheros L2 FastEthernet controller - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device ae
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ae_load="YES"
-
-
-
-

-

The ae device driver provides support for - Attansic/Atheros L2 PCIe FastEthernet controllers.

-

The controller supports hardware Ethernet checksum processing, - hardware VLAN tag stripping/insertion and an interrupt moderation mechanism. - Attansic L2 also features a 64-bit multicast hash filter.

-

The ae driver supports the following media - types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Select 10Mbps operation.
-
-
Set 100Mbps (FastEthernet) operation.
-
-

The ae driver provides support for the - following media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ae driver supports Attansic/Atheros L2 - PCIe FastEthernet controllers, and is known to support the following - hardware:

-

-
    -
  • ASUS EeePC 701
    • -
  • ASUS EeePC 900
    • -
-

Other hardware may or may not work with this driver.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.ae.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
-
-
-

-

The ae driver collects a number of useful - MAC counter during the work. The statistics is available via the - dev.ae.%d.stats sysctl(8) tree, - where %d corresponds to the controller number.

-
-
-

-
-
ae%d: watchdog timeout.
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
ae%d: reset timeout.
-
The card reset operation has been timed out.
-
ae%d: Generating random ethernet address.
-
No valid Ethernet address was found in the controller NVRAM and registers. - Random locally administered address with ASUS OUI identifier will be used - instead.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The ae driver and this manual page was - written by Stanislav Sedov - <stas@FreeBSD.org>. - It first appeared in FreeBSD 7.1.

-
-
-

-

The Attansic L2 FastEthernet controller supports DMA but does not - use a descriptor based transfer mechanism via scatter-gather DMA. Thus the - data should be copied to/from the controller memory on each - transmit/receive. Furthermore, a lot of data alignment restrictions apply. - This may introduce a high CPU load on systems with heavy network activity. - Luckily enough this should not be a problem on modern hardware as L2 does - not support speeds faster than 100Mbps.

-
-
- - - - - -
May 17, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/aesni.4 3.html b/static/freebsd/man4/aesni.4 3.html deleted file mode 100644 index 29f10fab..00000000 --- a/static/freebsd/man4/aesni.4 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
AESNI(4)Device Drivers ManualAESNI(4)
-
-
-

-

aesni — driver for - the AES and SHA accelerator on x86 CPUs

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device cryptodev -
-device aesni
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
aesni_load="YES"
-
-
-
-

-

Starting with Intel Westmere and AMD Bulldozer, some x86 - processors implement a new set of instructions called AESNI. The set of six - instructions accelerates the calculation of the key schedule for key lengths - of 128, 192, and 256 of the Advanced Encryption Standard (AES) symmetric - cipher, and provides a hardware implementation of the regular and the last - encryption and decryption rounds.

-

The processor capability is reported as AESNI in the Features2 - line at boot.

-

Starting with the Intel Goldmont and AMD Ryzen microarchitectures, - some x86 processors implement a new set of SHA instructions. The set of - seven instructions accelerates the calculation of SHA1 and SHA256 - hashes.

-

The processor capability is reported as SHA in the Structured - Extended Features line at boot.

-

The aesni driver does not attach on - systems that lack both CPU capabilities. On systems that support only one of - AESNI or SHA extensions, the driver will attach and support that one - function.

-

The aesni driver registers itself to - accelerate AES and SHA operations for crypto(4). Besides - speed, the advantage of using the aesni driver is - that the AESNI operation is data-independent, thus eliminating some attack - vectors based on measuring cache use and timings typically present in - table-driven implementations.

-
-
-

-

crypt(3), crypto(4), - intro(4), ipsec(4), - padlock(4), random(4), - crypto(7), crypto(9)

-
-
-

-

The aesni driver first appeared in - FreeBSD 9.0. SHA support was added in - FreeBSD 12.0.

-
-
-

-

The aesni driver was written by - Konstantin Belousov - <kib@FreeBSD.org> and - Conrad Meyer - <cem@FreeBSD.org>. The - key schedule calculation code was adopted from the sample provided by Intel - and used in the analogous OpenBSD driver. The hash - step intrinsics implementations were supplied by Intel.

-
-
- - - - - -
July 29, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/age.4 3.html b/static/freebsd/man4/age.4 3.html deleted file mode 100644 index 654e274b..00000000 --- a/static/freebsd/man4/age.4 3.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - -
AGE(4)Device Drivers ManualAGE(4)
-
-
-

-

age — - Attansic/Atheros L1 Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device age
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_age_load="YES"
-
-
-
-

-

The age device driver provides support for - Attansic/Atheros L1 PCI Express Gigabit Ethernet controllers.

-

All LOMs supported by the age driver have - TCP/UDP/IP checksum offload for both transmit and receive, TCP segmentation - offload (TSO), hardware VLAN tag stripping/insertion features and an - interrupt moderation mechanism as well as a 64-bit multicast hash - filter.

-

The L1 also supports Jumbo Frames (up to 10240 bytes), which can - be configured via the interface MTU setting. Selecting an MTU larger than - 1500 bytes with the ifconfig(8) utility configures the - adapter to receive and transmit Jumbo Frames.

-

The age driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-
Set 1000baseTX operation over twisted pair.
-
-

The age driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The age driver provides support for LOMs - based on Attansic/Atheros L1 Gigabit Ethernet controller chips, - including:

-

-
    -
  • ASUS M2N8-VMX
    • -
  • ASUS M2V
    • -
  • ASUS M3A
    • -
  • ASUS P2-M2A590G
    • -
  • ASUS P5B-E
    • -
  • ASUS P5B-MX/WIFI-AP
    • -
  • ASUS P5B-VMSE
    • -
  • ASUS P5K
    • -
  • ASUS P5KC
    • -
  • ASUS P5KPL-C
    • -
  • ASUS P5KPL-VM
    • -
  • ASUS P5K-SE
    • -
  • ASUS P5K-V
    • -
  • ASUS P5L-MX
    • -
  • ASUS P5DL2-VM
    • -
  • ASUS P5L-VM 1394
    • -
  • ASUS G2S
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.age.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
hw.age.msix_disable
-
This tunable disables MSI-X support on the Ethernet hardware. The default - value is 0.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.age.%d.int_mod
-
Maximum amount of time to delay interrupt processing in units of 2us. The - accepted range is 0 to 65000, the default is 50 (100us). Value 0 - completely disables the interrupt moderation.
-
dev.age.%d.process_limit
-
Maximum amount of Rx events to be processed in the event loop before - rescheduling a taskqueue. The accepted range is 30 to 255, the default - value is 128 events. The interface does not need to be brought down and up - again before a change takes effect.
-
dev.age.%d.stats
-
Display lots of useful MAC counters maintained in the driver.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The age driver was written by - Pyun YongHyeon - <yongari@FreeBSD.org>. - It first appeared in FreeBSD 7.1.

-
-
- - - - - -
September 18, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/agp.4 3.html b/static/freebsd/man4/agp.4 3.html deleted file mode 100644 index f812f887..00000000 --- a/static/freebsd/man4/agp.4 3.html +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -
AGP(4)Device Drivers ManualAGP(4)
-
-
-

-

agp — generic - interface to the Accelerated Graphics Port (AGP)

-
-
-

-

device agp

-
-
-

-

The agp driver is slated to be removed in - FreeBSD 16.0.

-
-
-

-

The agp driver provides uniform, abstract - methods for controlling the following devices:

-

-
-
Ali:
-
M1541, M1621 and M1671 host to AGP bridges
-
AMD:
-
751, 761 and 762 host to AGP bridges
-
ATI:
-
RS100, RS200, RS250 and RS300 AGP bridges
-
Intel:
-
i820, i840, i845, i850, and i860 host to AGP bridges
-
Intel:
-
i810, i810-DC100, i810E, i815, 830M, 845G, 845M, 852GM, 852GME, 855GM, - 855GME, 865G, 915G and 915GM SVGA controllers
-
Intel:
-
82443BX, 82443GX, 82443LX, 82815, 82820, 82830, 82840, 82845, 82845G, - 82850, 82855, 82855GM, 82860, 82865, 82875P, E7205 and E7505 host to AGP - bridges
-
NVIDIA:
-
nForce and nForce2 AGP controllers
-
SiS:
-
530, 540, 550, 620, 630, 645, 645DX, 648, 650, 651, 655, 661, 730, 735, - 740, 741, 745, 746, 760 and 5591 host to AGP bridges
-
VIA:
-
3296, 82C597, 82C598, 82C691, 82C694X, 82C8363, 8235, 8237, 8361, 8367, - 8371, 8377, 8501, 8601, 862x, 8633, 8653, 8703, 8753, 8754, 8763, 8783, - KT880, PM800, PM880, PN800, PN880, PT880, XM266 and XN266 host to PCI - bridges
-
-

The most common application of agp is for - running X(7) (ports/x11/xorg-docs) - on the Intel i81x controllers.

-
-
-

-

The following ioctl(2) operations can be - performed on /dev/agpgart, which are defined in - <sys/agpio.h>:

-
-
-
Returns state of the agp system. The result is a - pointer to the following structure: -
- 
typedef struct _agp_info {
-	agp_version version;  /* version of the driver        */
-	uint32_t bridge_id;   /* bridge vendor/device         */
-	uint32_t agp_mode;    /* mode info of bridge          */
-	off_t aper_base;      /* base of aperture             */
-	size_t aper_size;     /* size of aperture             */
-	size_t pg_total;      /* max pages (swap + system)    */
-	size_t pg_system;     /* max pages (system)           */
-	size_t pg_used;       /* current pages used           */
-} agp_info;
-
-
-
-
Acquire control of the AGP chipset for use by this client. Returns - EBUSY if the AGP chipset is already acquired by - another client.
-
-
Release control of the AGP chipset. This does not unbind or free any - allocated memory, which is the responsibility of the client to handle if - necessary.
-
-
Enable the AGP hardware with the relevant mode. This - ioctl(2) takes the following structure: -
- 
typedef struct _agp_setup {
-	uint32_t agp_mode;    /* mode info of bridge */
-} agp_setup;
-
-

The mode bits are defined in - <sys/agpio.h>.

-
-
-
Allocate physical memory suitable for mapping into the AGP aperture. This - ioctl(2) takes the following structure: -
- 
typedef struct _agp_allocate {
-	int key;              /* tag of allocation            */
-	size_t pg_count;      /* number of pages              */
-	uint32_t type;        /* 0 == normal, other devspec   */
-	uint32_t physical;    /* device specific (some devices
-			       * need a phys address of the
-			       * actual page behind the gatt
-			       * table)                       */
-} agp_allocate;
-
-

Returns a handle to the allocated memory.

-
-
-
Free the previously allocated memory associated with the handle - passed.
-
-
Bind the allocated memory at given offset with the AGP aperture. Returns - EINVAL if the memory is already bound or the - offset is not at AGP page boundary. This ioctl(2) takes - the following structure: -
- 
typedef struct _agp_bind {
-	int key;         /* tag of allocation            */
-	off_t pg_start;  /* starting page to populate    */
-} agp_bind;
-
-

The tag of allocation is the handle returned by - AGPIOC_ALLOCATE.

-
-
-
Unbind memory from the AGP aperture. Returns - EINVAL if the memory is not bound. This - ioctl(2) takes the following structure: -
- 
typedef struct _agp_unbind {
-	int key;                /* tag of allocation         */
-	uint32_t priority;      /* priority for paging out   */
-} agp_unbind;
-
-
-
-
-
-

-
-
/dev/agpgart
-
AGP device node.
-
-
-
-

-

X(7) - (ports/x11/xorg)

-
-
-

-

The agp driver first appeared in - FreeBSD 4.1.

-
-
- - - - - -
October 24, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ahc.4 3.html b/static/freebsd/man4/ahc.4 3.html deleted file mode 100644 index 919d48ce..00000000 --- a/static/freebsd/man4/ahc.4 3.html +++ /dev/null @@ -1,372 +0,0 @@ - - - - - - -
AHC(4)Device Drivers ManualAHC(4)
-
-
-

-

ahc — Adaptec - VL/ISA/PCI SCSI host adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device ahc -

For one or more PCI cards: -
- device pci

-
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
ahc_load="YES"
-ahc_isa_load="YES"
-ahc_pci_load="YES"
-
-
-
-

-

This driver provides access to the SCSI bus(es) connected to the - Adaptec AIC77xx and AIC78xx host adapter chips.

-

Driver features include support for twin and wide busses, fast, - ultra or ultra2 synchronous transfers depending on controller type, tagged - queueing, SCB paging, and target mode.

-

Per target configuration performed in the SCSI-Select menu, - accessible at boot is honored by this driver. This includes - synchronous/asynchronous transfers, maximum synchronous negotiation rate, - wide transfers, disconnection, the host adapter's SCSI ID. For systems that - store non-volatile settings in a system specific manner rather than a serial - eeprom directly connected to the aic7xxx controller, the BIOS must be - enabled for the driver to access this information. This restriction applies - to many chip-down motherboard configurations.

-

Performance and feature sets vary throughout the aic7xxx product - line. The following table provides a comparison of the different chips - supported by the ahc driver. Note that wide and twin - channel features, although always supported by a particular chip, may be - disabled in a particular motherboard or card design.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MIPSBusMaxSyncMaxWidthSCBsFeatures
aic777010VL10MHz16Bit41
aic785010PCI/3210MHz8Bit3
aic786010PCI/3220MHz8Bit3
aic787010PCI/3210MHz16Bit16
aic788010PCI/3220MHz16Bit16
aic789020PCI/3240MHz16Bit163 4 5 6 7 8
aic789120PCI/6440MHz16Bit163 4 5 6 7 8
aic789220PCI/6480MHz16Bit163 4 5 6 7 8
aic789515PCI/3220MHz16Bit162 3 4 5
aic7895C15PCI/3220MHz16Bit162 3 4 5 8
aic789620PCI/3240MHz16Bit162 3 4 5 6 7 8
aic789720PCI/6440MHz16Bit162 3 4 5 6 7 8
aic789920PCI/6480MHz16Bit162 3 4 5 6 7 8
-

-
    -
  1. Multiplexed Twin Channel Device - One controller servicing two - busses.
    2. -
  2. Multi-function Twin Channel Device - Two controllers on one chip.
    3. -
  3. Command Channel Secondary DMA Engine - Allows scatter gather list and SCB - prefetch.
    4. -
  4. 64 Byte SCB Support - SCSI CDB is embedded in the SCB to eliminate an - extra DMA.
    5. -
  5. Block Move Instruction Support - Doubles the speed of certain sequencer - operations.
    6. -
  6. ‘Bayonet’ style Scatter Gather Engine - Improves S/G - prefetch performance.
    7. -
  7. Queuing Registers - Allows queueing of new transactions without pausing - the sequencer.
    8. -
  8. Multiple Target IDs - Allows the controller to respond to selection as a - target on multiple SCSI IDs.
    9. -
-
-
-
-

-

To allow PCI adapters to use memory mapped I/O if enabled:

-

options AHC_ALLOW_MEMIO=(0 -- disabled, 1 -- - enabled)

-
Memory mapped I/O is more efficient than the - alternative, programmed I/O. Most PCI BIOSes will map devices so that either - technique for communicating with the card is available. In some cases, usually - when the PCI device is sitting behind a PCI->PCI bridge, the BIOS may fail - to properly initialize the chip for memory mapped I/O. The typical symptom of - this problem is a system hang if memory mapped I/O is attempted. -

Most modern motherboards perform the initialization correctly and - work fine with this option enabled and it is the default. This option can - also be dynamically configured through a device hint documented below.

-
-

To statically configure one or more controllers to assume the - target role:

-

options AHC_TMODE_ENABLE=<bitmask of - units>

-
The value assigned to this option should be a - bitmap of all units where target mode is desired. For example, a value of - 0x25, would enable target mode on units 0, 2, and 5. A value of 0x8a enables - it for units 1, 3, and 7. -

Note that controllers can be dynamically configured through a - device hint documented below.

-
-
-
-

-

The following options are switchable by setting values in - /boot/device.hints.

-

They are:

-
-
hint.ahc.N.tmode_enable
-
A hint to define whether the SCSI target mode is enabled, defaults to - disabled (0 -- disabled, 1 -- enabled).
-
hint.ahc.N.allow_memio
-
A hint to define whether memory mapped io is enabled or disabled for this - adapter, defaults to enabled (0 -- disabled, 1 -- enabled).
-
-
-
-

-

The ahc driver supports the following - VL/ISA/PCI parallel SCSI controllers and cards:

-

-
    -
  • Adaptec AIC7770 host adapter chip
    • -
  • Adaptec AIC7850 host adapter chip
    • -
  • Adaptec AIC7860 host adapter chip
    • -
  • Adaptec AIC7870 host adapter chip
    • -
  • Adaptec AIC7880 host adapter chip
    • -
  • Adaptec AIC7890 host adapter chip
    • -
  • Adaptec AIC7891 host adapter chip
    • -
  • Adaptec AIC7892 host adapter chip
    • -
  • Adaptec AIC7895 host adapter chip
    • -
  • Adaptec AIC7896 host adapter chip
    • -
  • Adaptec AIC7897 host adapter chip
    • -
  • Adaptec AIC7899 host adapter chip
    • -
  • Adaptec 274X(W)
    • -
  • Adaptec 274X(T)
    • -
  • Adaptec 2910
    • -
  • Adaptec 2915
    • -
  • Adaptec 2920C
    • -
  • Adaptec 2930C
    • -
  • Adaptec 2930U2
    • -
  • Adaptec 2940
    • -
  • Adaptec 2940J
    • -
  • Adaptec 2940N
    • -
  • Adaptec 2940U
    • -
  • Adaptec 2940AU
    • -
  • Adaptec 2940UW
    • -
  • Adaptec 2940UW Dual
    • -
  • Adaptec 2940UW Pro
    • -
  • Adaptec 2940U2W
    • -
  • Adaptec 2940U2B
    • -
  • Adaptec 2950U2W
    • -
  • Adaptec 2950U2B
    • -
  • Adaptec 19160B
    • -
  • Adaptec 29160B
    • -
  • Adaptec 29160N
    • -
  • Adaptec 3940
    • -
  • Adaptec 3940U
    • -
  • Adaptec 3940AU
    • -
  • Adaptec 3940UW
    • -
  • Adaptec 3940AUW
    • -
  • Adaptec 3940U2W
    • -
  • Adaptec 3950U2
    • -
  • Adaptec 3960
    • -
  • Adaptec 39160
    • -
  • Adaptec 3985
    • -
  • Adaptec 4944UW
    • -
  • Many motherboards with on-board SCSI support
    • -
-
-
-

-

Every transaction sent to a device on the SCSI bus is assigned a - ‘SCSI Control Block’ (SCB). The SCB contains all of the - information required by the controller to process a transaction. The chip - feature table lists the number of SCBs that can be stored in on-chip memory. - All chips with model numbers greater than or equal to 7870 allow for the on - chip SCB space to be augmented with external SRAM up to a maximum of 255 - SCBs. Very few Adaptec controller configurations have external SRAM.

-

If external SRAM is not available, SCBs are a limited - resource. Using the SCBs in a straight forward manner would only allow the - driver to handle as many concurrent transactions as there are physical SCBs. - To fully utilize the SCSI bus and the devices on it, requires much more - concurrency. The solution to this problem is - , a concept - similar to memory paging. SCB paging takes advantage of the fact that - devices usually disconnect from the SCSI bus for long periods of time - without talking to the controller. The SCBs for disconnected transactions - are only of use to the controller when the transfer is resumed. When the - host queues another transaction for the controller to execute, the - controller firmware will use a free SCB if one is available. Otherwise, the - state of the most recently disconnected (and therefore most likely to stay - disconnected) SCB is saved, via dma, to host memory, and the local SCB - reused to start the new transaction. This allows the controller to queue up - to 255 transactions regardless of the amount of SCB space. Since the local - SCB space serves as a cache for disconnected transactions, the more SCB - space available, the less host bus traffic consumed saving and restoring SCB - data.

-
-
-

-

ahd(4), cd(4), - da(4), sa(4), - scsi(4)

-
-
-

-

The ahc driver appeared in - FreeBSD 2.0.

-
-
-

-

The ahc driver, the AIC7xxx sequencer-code - assembler, and the firmware running on the aic7xxx chips was written by - Justin T. Gibbs.

-
-
-

-

Some Quantum drives (at least the Empire 2100 and 1080s) will not - run on an AIC7870 Rev B in synchronous mode at 10MHz. Controllers with this - problem have a 42 MHz clock crystal on them and run slightly above 10MHz. - This confuses the drive and hangs the bus. Setting a maximum synchronous - negotiation rate of 8MHz in the SCSI-Select utility will allow normal - operation.

-

Although the Ultra2 and Ultra160 products have sufficient - instruction ram space to support both the initiator and target roles - concurrently, this configuration is disabled in favor of allowing the target - role to respond on multiple target ids. A method for configuring dual role - mode should be provided.

-

Tagged Queuing is not supported in target mode.

-

Reselection in target mode fails to function correctly on all high - voltage differential boards as shipped by Adaptec. Information on how to - modify HVD board to work correctly in target mode is available from - Adaptec.

-
-
- - - - - -
September 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ahci.4 3.html b/static/freebsd/man4/ahci.4 3.html deleted file mode 100644 index eac6f2ad..00000000 --- a/static/freebsd/man4/ahci.4 3.html +++ /dev/null @@ -1,189 +0,0 @@ - - - - - - -
AHCI(4)Device Drivers ManualAHCI(4)
-
-
-

-

ahci — Serial ATA - Advanced Host Controller Interface driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device ahci
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ahci_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hint.ahci.X.msi
-
controls Message Signaled Interrupts (MSI) usage by the specified - controller. -

-
-
-
0
-
MSI disabled;
-
1
-
single MSI vector used, if supported;
-
2
-
multiple MSI vectors used, if supported (default);
-
-
-
-
hint.ahci.X.ccc
-
controls Command Completion Coalescing (CCC) usage by the specified - controller. Non-zero value enables CCC and defines maximum time (in ms), - request can wait for interrupt, if there are some more requests present on - controller queue. CCC reduces number of context switches on systems with - many parallel requests, but it can decrease disk performance on some - workloads due to additional command latency.
-
hint.ahci.X.direct
-
controls whether the driver should use direct command completion from - interrupt thread(s), or queue them to CAM completion threads. Default - value depends on number of MSI interrupts supported and number of - implemented SATA ports.
-
hint.ahci.X.em
-
controls whether the driver should implement virtual enclosure management - device on top of SGPIO or other interface. Default value depends on - controller capabilities.
-
hint.ahcich.X.pm_level
-
controls SATA interface Power Management for the specified channel, - allowing some power to be saved at the cost of additional command latency. - Possible values: -

-
-
-
0
-
interface Power Management is disabled (default);
-
1
-
device is allowed to initiate PM state change, host is passive;
-
2
-
host initiates PARTIAL PM state transition every time port becomes - idle;
-
3
-
host initiates SLUMBER PM state transition every time port becomes - idle.
-
4
-
driver initiates PARTIAL PM state transition 1ms after port becomes - idle;
-
5
-
driver initiates SLUMBER PM state transition 125ms after port becomes - idle.
-
-
-

Some controllers, such as ICH8, do not implement modes 2 and 3 - with NCQ used. Because of artificial entering latency, performance - degradation in modes 4 and 5 is much smaller then in modes 2 and 3.

-

Note that interface Power Management complicates device - presence detection. A manual bus reset/rescan may be needed after device - hot-plug, unless hardware implements Cold Presence Detection.

-
-
hint.ahcich.X.sata_rev
-
setting to nonzero value limits maximum SATA revision (speed). Values 1, 2 - and 3 are respectively 1.5, 3 and 6Gbps.
-
hw.ahci.force
-
setting to nonzero value forces driver attach to some known AHCI-capable - chips even if they are configured for legacy IDE emulation. Default is - 1.
-
-
-
-

-

This driver provides the CAM(4) subsystem with - native access to the SATA ports of AHCI-compatible controllers. Each SATA - port found is represented to CAM as a separate bus with one target, or, if - HBA supports Port Multipliers, 16 targets. Most of the bus-management - details are handled by the SATA-specific transport of CAM. Connected ATA - disks are handled by the ATA protocol disk peripheral driver - ada(4). ATAPI devices are handled by the SCSI protocol - peripheral drivers cd(4), da(4), - sa(4), etc.

-

Driver features include support for Serial ATA and ATAPI devices, - Port Multipliers (including FIS-based switching, when supported), hardware - command queues (up to 32 commands per port), Native Command Queuing, SATA - interface Power Management, device hot-plug and Message Signaled - Interrupts.

-

Driver supports "LED" enclosure management messages, - defined by the AHCI. When supported by hardware, it allows to control - per-port activity, locate and fault LEDs via the led(4) - API or emulated ses(4) device for localization and status - reporting purposes. Supporting AHCI controllers may transmit that - information to the backplane controllers via SGPIO interface. Backplane - controllers interpret received statuses in some way (IBPI standard) to - report them using present indicators.

-
-
-

-

The ahci driver supports AHCI compatible - controllers having PCI class 1 (mass storage), subclass 6 (SATA) and - programming interface 1 (AHCI).

-

Also, in cooperation with atamarvell and atajmicron drivers of - ata(4), it supports AHCI part of legacy-PATA + AHCI-SATA combined - controllers, such as JMicron JMB36x and Marvell 88SE61xx.

-

The ahci driver also supports AHCI devices - that act as PCI bridges for nvme(4) using Intel Rapid - Storage Technology (RST). To use the nvme(4) device, - either one must set the SATA mode in the BIOS to AHCI (from RST), or one - must accept the performance with RST enabled due to interrupt sharing. - FreeBSD will automatically detect AHCI devices with - this extension that are in RST mode. When that happens, - ahci will attach nvme(4) children - to the ahci device.

-
-
-

-
-
/dev/led/ahci*.*.act
-
activity LED device nodes
-
/dev/led/ahci*.*.fault
-
fault LED device nodes
-
/dev/led/ahci*.*.locate
-
locate LED device nodes
-
-
-
-

-
-
dev.ahcich.X.disable_phy
-
Set to 1 to disable the phy for the drive on channel X. Set to 0 to enable - the phy. Useful for turning off troublemakers. Also useful for debugging - when you need the ada drive to come and go.
-
-
-
-

-

ada(4), ata(4), - cam(4), cd(4), da(4), - sa(4), ses(4)

-
-
-

-

The ahci driver first appeared in - FreeBSD 8.0.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org>

-
-
- - - - - -
December 17, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ahd.4 3.html b/static/freebsd/man4/ahd.4 3.html deleted file mode 100644 index 819cbe9b..00000000 --- a/static/freebsd/man4/ahd.4 3.html +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - -
AHD(4)Device Drivers ManualAHD(4)
-
-
-

-

ahd — Adaptec - PCI/PCI-X Ultra320 SCSI host adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device ahd -

To compile in debugging code: -
- options AHD_DEBUG -
- options AHD_DEBUG_OPTS=<bitmask of options> -
- options AHD_REG_PRETTY_PRINT

-
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ahd_load="YES"
-
-
-
-

-

This driver provides access to the SCSI bus(es) connected to - Adaptec AIC79xx host adapter chips.

-

Driver features include support for narrow and wide busses, fast, - ultra, ultra2, ultra160, and ultra320 synchronous transfers, packetized - transfers, tagged queueing, 512 SCB's, and target mode.

-

The AHD_DEBUG_OPTS option is used to - control which diagnostic messages are printed to the console when - AHD_DEBUG is enabled. Logically OR the following - bits together:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Function
0x0001Show miscellaneous information
0x0002Show sense data
0x0004Show Serial EEPROM contents
0x0008Show bus termination settings
0x0010Show host memory usage
0x0020Show SCSI protocol messages
0x0040Show mode pointer of the chip register window
0x0080Show selection timeouts
0x0100Show FIFO usage messages
0x0200Show Queue Full status
0x0400Show SCB queue status
0x0800Show inbound packet information
0x1000Show S/G list information
0x2000Enable extra diagnostic code in the firmware
-

The AHD_REG_PRETTY_PRINT option compiles - in support for human-readable bit definitions for each register that is - printed by the debugging code. However, it also bloats the compiled size of - the driver by approximately 215KB.

-

Per target configuration performed in the SCSI-Select menu, - accessible at boot, is honored by this driver. This includes - synchronous/asynchronous transfers, maximum synchronous negotiation rate, - wide transfers, disconnection, and the host adapter's SCSI ID.

-
-
-

-

To statically configure one or more controllers to assume the - target role:

-

options AHD_TMODE_ENABLE <bitmask of - units>

-
The value assigned to this option should be a - bitmap of all units where target mode is desired. For example, a value of - 0x25, would enable target mode on units 0, 2, and 5. A value of 0x8a enables - it for units 1, 3, and 7. -

Note that controllers can be dynamically configured through a - device hint documented below.

-

-
-
-
-

-

The following options are switchable by setting values in - /boot/device.hints.

-

They are:

-
-
hint.ahd.N.tmode_enable
-
A hint to define whether the SCSI target mode is enabled (0 -- disabled, 1 - -- enabled).
-
-
-
-

-

The ahd driver supports the following - PCI/PCI-X parallel SCSI controllers:

-

-
    -
  • Adaptec AIC7901 host adapter chip
    • -
  • Adaptec AIC7901A host adapter chip
    • -
  • Adaptec AIC7902 host adapter chip
    • -
  • Adaptec 29320 host adapter
    • -
  • Adaptec 39320 host adapter
    • -
  • Many motherboards with on-board SCSI support
    • -
-
-
-

-

ahc(4), cd(4), - da(4), sa(4), - scsi(4)

-
-
-

-

The ahd driver first appeared in - FreeBSD 4.7.

-
-
-

-

The ahd driver, the AIC7xxx sequencer-code - assembler, and the firmware running on the aic79xx chips was written by - Justin T. Gibbs. This manual page is based on the - ahc(4) manual page.

-
-
-

-

The current generation of 79xx chips do not support target mode in - Ultra320 mode. Target mode in general has not been well tested in this - driver.

-
-
- - - - - -
September 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/aibs.4 3.html b/static/freebsd/man4/aibs.4 3.html deleted file mode 100644 index b4598de0..00000000 --- a/static/freebsd/man4/aibs.4 3.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - -
AIBS(4)Device Drivers ManualAIBS(4)
-
-
-

-

aibs — ASUSTeK AI - Booster ACPI ATK0110 voltage, temperature and fan sensor

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device aibs
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
aibs_load="YES"
-
-
-
-

-

The aibs driver provides support for the - voltage, temperature and fan sensors available through the ATK0110 ASOC ACPI - device on ASUSTeK motherboards. The number of sensors of each type, as well - as the description of each sensor, varies according to the motherboard.

-

The driver supports an arbitrary set of sensors, provides - descriptions regarding what each sensor is used for, and reports the current - values as well as the supposed range specifications of each sensor's input - as defined by the motherboard manufacturer through ACPI.

-

The range specifications are as follows:

-
    -
  • Voltage sensors have a lower and an upper range specification.
    • -
  • Temperature sensors have two upper specifications.
    • -
  • Fan sensors may either have only the lower specification, or, depending on - the DSDT, one lower and one upper specification.
    • -
-

Sensor readings and the range specifications are made available - through the sysctl(3) interface, and can be monitored with - sysctl(8). For example, on an ASUS V3-P5G965 barebone:

-
-
> sysctl dev.aibs.0.{volt,temp,fan}
-dev.aibs.0.volt.0: 1192 850 1600
-dev.aibs.0.volt.1: 3312 2970 3630
-dev.aibs.0.volt.2: 5017 4500 5500
-dev.aibs.0.volt.3: 12302 10200 13800
-dev.aibs.0.temp.0: 28.0C 80.0C 95.0C
-dev.aibs.0.temp.1: 55.0C 60.0C 95.0C
-dev.aibs.0.fan.0: 878 600 7200
-dev.aibs.0.fan.1: 0 700 7200
-
-> sysctl -d dev.aibs.0.{volt,temp,fan}
-dev.aibs.0.volt:
-dev.aibs.0.volt.0: Vcore Voltage
-dev.aibs.0.volt.1:  +3.3 Voltage
-dev.aibs.0.volt.2:  +5 Voltage
-dev.aibs.0.volt.3:  +12 Voltage
-dev.aibs.0.temp:
-dev.aibs.0.temp.0: CPU Temperature
-dev.aibs.0.temp.1: MB Temperature
-dev.aibs.0.fan:
-dev.aibs.0.fan.0: CPU FAN Speed
-dev.aibs.0.fan.1: CHASSIS FAN Speed
-
-

Generally, sensors provided by the aibs - driver may also be supported by certain other drivers or utilities that - access the ISA / LPC or I2C / SMBus devices directly. The precise collection - of aibs sensors is comprised of the sensors - specifically utilised in the motherboard design, which may be supported - through a combination of one or more physical hardware monitoring chips.

-

The aibs driver, however, provides the - following advantages when compared to the native hardware monitoring drivers - or other utilities:

-
    -
  • Sensor values from aibs are expected to be more - reliable. For example, voltage sensors in many hardware monitoring chips - can only sense voltage from 0 to 2 or 4 volts, and the excessive voltage - is removed by the resistors, which may vary with the motherboard and with - the voltage that is being sensed. In aibs, the - required resistor factors are provided by the motherboard manufacturer - through ACPI; in the native drivers, the resistor factors are encoded into - the driver based on the chip manufacturer's recommendations. In essence, - sensor values from aibs are very likely to be - identical to the readings from the Hardware Monitor screen in the - BIOS.
    • -
  • Sensor descriptions from aibs are more likely to - match the markings on the motherboard.
    • -
  • Sensor range specifications are supported by aibs. - The range specification is reported for each individual sensor as - suggested by the motherboard manufacturer. For example, the threshold for - the CPU temperature sensor is likely to be significantly higher than that - for the chassis temperature sensor.
    • -
  • Support for newer chips in aibs. Newer chips may - miss a native driver, but should be supported through - aibs regardless.
    • -
-
-
-

-

sysctl(3), acpi(4), - sysctl(8)

-
-
-

-

The aibs driver first appeared in - OpenBSD 4.7, DragonFly 2.5, - NetBSD 6.0 and FreeBSD - 9.0.

-

An earlier version of the driver, - acpi_aiboost, first appeared in - FreeBSD 7.0 and NetBSD - 5.0.

-
-
-

-

The aibs driver was written for - OpenBSD, DragonFly, - NetBSD and FreeBSD by - Constantine A. Murenin - <cnst@FreeBSD.org>, - Raouf Boutaba Research Group, David R. Cheriton School of Computer Science, - University of Waterloo.

-

An earlier version of the driver, named - acpi_aiboost, was written for - FreeBSD by Takanori - Watanabe.

-
-
- - - - - -
April 4, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/aio.4 3.html b/static/freebsd/man4/aio.4 3.html deleted file mode 100644 index 0f5f0960..00000000 --- a/static/freebsd/man4/aio.4 3.html +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - -
AIO(4)Device Drivers ManualAIO(4)
-
-
-

-

aio — asynchronous - I/O

-
-
-

-

The aio facility provides system calls for - asynchronous I/O. Asynchronous I/O operations are not completed - synchronously by the calling thread. Instead, the calling thread invokes one - system call to request an asynchronous I/O operation. The status of a - completed request is retrieved later via a separate system call.

-

Asynchronous I/O operations on some file descriptor types may - block an AIO daemon indefinitely resulting in process and/or system hangs. - Operations on these file descriptor types are considered - “unsafe” and disabled by default. They can be enabled by - setting the vfs.aio.enable_unsafe sysctl node to a - non-zero value.

-

Asynchronous I/O operations on sockets, raw disk devices, and - regular files on local filesystems do not block indefinitely and are always - enabled.

-

The aio facility uses kernel processes - (also known as AIO daemons) to service most asynchronous I/O requests. These - processes are grouped into pools containing a variable number of processes. - Each pool will add or remove processes to the pool based on load. Pools can - be configured by sysctl nodes that define the minimum and maximum number of - processes as well as the amount of time an idle process will wait before - exiting.

-

One pool of AIO daemons is used to service asynchronous I/O - requests for sockets. These processes are named - “soaiod<N>”. The following sysctl nodes are used with - this pool:

-
-
kern.ipc.aio.num_procs
-
The current number of processes in the pool.
-
kern.ipc.aio.target_procs
-
The minimum number of processes that should be present in the pool.
-
kern.ipc.aio.max_procs
-
The maximum number of processes permitted in the pool.
-
kern.ipc.aio.lifetime
-
The amount of time a process is permitted to idle in clock ticks. If a - process is idle for this amount of time and there are more processes in - the pool than the target minimum, the process will exit.
-
-

A second pool of AIO daemons is used to service all other - asynchronous I/O requests except for I/O requests to raw disks. These - processes are named “aiod<N>”. The following sysctl - nodes are used with this pool:

-
-
vfs.aio.num_aio_procs
-
The current number of processes in the pool.
-
vfs.aio.target_aio_procs
-
The minimum number of processes that should be present in the pool.
-
vfs.aio.max_aio_procs
-
The maximum number of processes permitted in the pool.
-
vfs.aio.aiod_lifetime
-
The amount of time a process is permitted to idle in clock ticks. If a - process is idle for this amount of time and there are more processes in - the pool than the target minimum, the process will exit.
-
-

Asynchronous I/O requests for raw disks are queued directly to the - disk device layer after temporarily wiring the user pages associated with - the request. These requests are not serviced by any of the AIO daemon - pools.

-

Several limits on the number of asynchronous I/O requests are - imposed both system-wide and per-process. These limits are configured via - the following sysctls:

-
-
vfs.aio.max_buf_aio
-
The maximum number of queued asynchronous I/O requests for raw disks - permitted for a single process. Asynchronous I/O requests that have - completed but whose status has not been retrieved via - aio_return(2) or aio_waitcomplete(2) - are not counted against this limit.
-
vfs.aio.num_buf_aio
-
The number of queued asynchronous I/O requests for raw disks - system-wide.
-
vfs.aio.max_aio_queue_per_proc
-
The maximum number of asynchronous I/O requests for a single process - serviced concurrently by the default AIO daemon pool.
-
vfs.aio.max_aio_per_proc
-
The maximum number of outstanding asynchronous I/O requests permitted for - a single process. This includes requests that have not been serviced, - requests currently being serviced, and requests that have completed but - whose status has not been retrieved via aio_return(2) or - aio_waitcomplete(2).
-
vfs.aio.num_queue_count
-
The number of outstanding asynchronous I/O requests system-wide.
-
vfs.aio.max_aio_queue
-
The maximum number of outstanding asynchronous I/O requests permitted - system-wide.
-
-

Asynchronous I/O control buffers should be zeroed before - initializing individual fields. This ensures all fields are initialized.

-

All asynchronous I/O control buffers contain a - sigevent structure in the - aio_sigevent field which can be used to request - notification when an operation completes.

-

For SIGEV_KEVENT notifications, the - sigevent's sigev_notify_kqueue - field should contain the descriptor of the kqueue that the event should be - attached to, its sigev_notify_kevent_flags field may - contain EV_ONESHOT, - EV_CLEAR, and/or - EV_DISPATCH, and its - sigev_notify field should be set to - SIGEV_KEVENT. The posted kevent will contain:

- - - - - - - - - - - - - - - - - - - - - -
identasynchronous I/O control buffer pointer
filter
flags
udatavalue stored in aio_sigevent.sigev_value
-

For SIGEV_SIGNO and - SIGEV_THREAD_ID notifications, the information for - the queued signal will include SI_ASYNCIO in the - si_code field and the value stored in - sigevent.sigev_value in the - si_value field.

-

For SIGEV_THREAD notifications, the value - stored in aio_sigevent.sigev_value is passed to the - aio_sigevent.sigev_notify_function as described in - sigevent(3).

-
-
-

-

aio_cancel(2), aio_error(2), - aio_read(2), aio_readv(2), - aio_return(2), aio_suspend(2), - aio_waitcomplete(2), aio_write(2), - aio_writev(2), lio_listio(2), - sigevent(3), sysctl(8)

-
-
-

-

The aio facility appeared as a kernel - option in FreeBSD 3.0. The - aio kernel module appeared in - FreeBSD 5.0. The aio - facility was integrated into all kernels in FreeBSD - 11.0.

-
-
- - - - - -
January 2, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/alc.4 3.html b/static/freebsd/man4/alc.4 3.html deleted file mode 100644 index e2503200..00000000 --- a/static/freebsd/man4/alc.4 3.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - -
ALC(4)Device Drivers ManualALC(4)
-
-
-

-

alc — Atheros - AR813x/AR815x/AR816x/AR817x Gigabit/Fast Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device alc
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_alc_load="YES"
-
-
-
-

-

The alc device driver provides support for - Atheros AR813x, AR815x, AR816x and AR817x PCI Express Gigabit/Fast Ethernet - controllers.

-

All LOMs supported by the alc driver have - TCP/UDP/IP checksum offload for transmit, TCP segmentation offload (TSO), - hardware VLAN tag stripping/insertion features, Wake On Lan (WOL) and an - interrupt moderation mechanism as well as a 64-bit multicast hash - filter.

-

The AR813x, AR815x, AR816x and AR817x supports Jumbo Frames (up to - 9216, 6144, 9216 and 9216 bytes, respectively), which can be configured via - the interface MTU setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames.

-

The alc driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-
Set 1000baseTX operation over twisted pair.
-
-

The alc driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The alc device driver provides support for - the following Ethernet controllers:

-

-
    -
  • Atheros AR8131 PCI Express Gigabit Ethernet controller
    • -
  • Atheros AR8132 PCI Express Fast Ethernet controller
    • -
  • Atheros AR8151 v1.0 PCI Express Gigabit Ethernet controller
    • -
  • Atheros AR8151 v2.0 PCI Express Gigabit Ethernet controller
    • -
  • Atheros AR8152 v1.1 PCI Express Fast Ethernet controller
    • -
  • Atheros AR8152 v2.0 PCI Express Fast Ethernet controller
    • -
  • Atheros AR8161 PCI Express Gigabit Ethernet controller
    • -
  • Atheros AR8162 PCI Express Fast Ethernet controller
    • -
  • Atheros AR8171 PCI Express Gigabit Ethernet controller
    • -
  • Atheros AR8172 PCI Express Fast Ethernet controller
    • -
  • Killer E2200 Gigabit Ethernet controller
    • -
  • Killer E2400 Gigabit Ethernet controller
    • -
  • Killer E2500 Gigabit Ethernet controller
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.alc.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
hw.alc.msix_disable
-
This tunable disables MSI-X support on the Ethernet hardware. The default - value is 2, which means to enable or disable MSI-X based on the card type; - for "Killer" cards (E2x00) MSI-X will be disabled, while on - other cards it will be enabled. Set this to 0 to force MSI-X to be - enabled, or 1 to force it to be disabled regardless of card type.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.alc.%d.int_rx_mod
-
Maximum amount of time to delay receive interrupt processing in units of - 1us. The accepted range is 0 to 130000, the default is 100(100us). Value 0 - completely disables the interrupt moderation.
-
dev.alc.%d.int_tx_mod
-
Maximum amount of time to delay transmit interrupt processing in units of - 1us. The accepted range is 0 to 130000, the default is 1000(1ms). Value 0 - completely disables the interrupt moderation.
-
dev.alc.%d.process_limit
-
Maximum amount of Rx frames to be processed in the event loop before - rescheduling a taskqueue. The accepted range is 32 to 255, the default - value is 64 events. The interface does not need to be brought down and up - again before a change takes effect.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The alc driver was written by - Pyun YongHyeon - <yongari@FreeBSD.org>. - It first appeared in FreeBSD 8.0.

-
-
- - - - - -
August 22, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/ale.4 3.html b/static/freebsd/man4/ale.4 3.html deleted file mode 100644 index a27678df..00000000 --- a/static/freebsd/man4/ale.4 3.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - -
ALE(4)Device Drivers ManualALE(4)
-
-
-

-

ale — Atheros - AR8121/AR8113/AR8114 Gigabit/Fast Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device ale
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ale_load="YES"
-
-
-
-

-

The ale device driver provides support for - Atheros AR8121 PCI Express Gigabit Ethernet controllers and Atheros - AR8113/AR8114 PCI Express Fast Ethernet controllers.

-

All LOMs supported by the ale driver have - TCP/UDP/IP checksum offload for both receive and transmit, TCP segmentation - offload (TSO), hardware VLAN tag stripping/insertion features, Wake On Lan - (WOL) and an interrupt coalescing/moderation mechanism as well as a 64-bit - multicast hash filter.

-

The AR8121 also supports Jumbo Frames (up to 8132 bytes), which - can be configured via the interface MTU setting. Selecting an MTU larger - than 1500 bytes with the ifconfig(8) utility configures - the adapter to receive and transmit Jumbo Frames.

-

The ale driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-
Set 1000baseTX operation over twisted pair.
-
-

The ale driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ale device driver provides support for - the following Ethernet controllers:

-

-
    -
  • Atheros AR8113 PCI Express Fast Ethernet controller
    • -
  • Atheros AR8114 PCI Express Fast Ethernet controller
    • -
  • Atheros AR8121 PCI Express Gigabit Ethernet controller
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.ale.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
hw.ale.msix_disable
-
This tunable disables MSI-X support on the Ethernet hardware. The default - value is 0.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.ale.%d.int_rx_mod
-
Maximum amount of time to delay receive interrupt processing in units of - 1us. The accepted range is 0 to 130000, the default is 30(30us). Value 0 - completely disables the interrupt moderation.
-
dev.ale.%d.int_tx_mod
-
Maximum amount of time to delay transmit interrupt processing in units of - 1us. The accepted range is 0 to 130000, the default is 1000(1ms). Value 0 - completely disables the interrupt moderation.
-
dev.ale.%d.process_limit
-
Maximum amount of Rx frames to be processed in the event loop before - rescheduling a taskqueue. The accepted range is 32 to 255, the default - value is 128 events. The interface does not need to be brought down and up - again before a change takes effect.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The ale driver was written by - Pyun YongHyeon - <yongari@FreeBSD.org>. - It first appeared in FreeBSD 7.1.

-
-
- - - - - -
November 12, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/alpm.4 4.html b/static/freebsd/man4/alpm.4 4.html deleted file mode 100644 index e545902c..00000000 --- a/static/freebsd/man4/alpm.4 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
ALPM(4)Device Drivers ManualALPM(4)
-
-
-

-

alpm — Acer - Aladdin 15x3 Power Management controller driver

-
-
-

-

device smbus -
- device smb -
- device alpm

-
-
-

-

This driver provides access to the Aladdin 15x3 Power Management - Unit. Currently, only smbus controller function is implemented.

-

The embedded SMBus controller of the Aladdin chipset may give you - access to the monitoring facilities of your mainboard. See - smb(4) for writing user code to fetch voltages, - temperature and so on from the monitoring chip of your mainboard.

-
-
-

-

smb(4), smbus(4)

-
-
-

-

The alpm manual page first appeared in - FreeBSD 4.0.

-
-
-

-

This manual page was written by Nicolas - Souchu - <nsouch@FreeBSD.org>.

-
-
-

-

Only polling mode is supported.

-
-
- - - - - -
February 13, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/altq.4 3.html b/static/freebsd/man4/altq.4 3.html deleted file mode 100644 index 8c7031c5..00000000 --- a/static/freebsd/man4/altq.4 3.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - -
ALTQ(4)Device Drivers ManualALTQ(4)
-
-
-

-

ALTQ — alternate - queuing of network packets

-
-
-

-

options ALTQ

-

-
- options ALTQ_CBQ -
- options ALTQ_CODEL -
- options ALTQ_RED -
- options ALTQ_RIO -
- options ALTQ_HFSC -
- options ALTQ_CDNR -
- options ALTQ_PRIQ -
- options ALTQ_FAIRQ

-
-
-

-

The ALTQ system is a framework which - provides several disciplines for queuing outgoing network packets. This is - done by modifications to the interface packet queues. See - altq(9) for details.

-

The user interface for ALTQ is implemented - by the pfctl(8) utility, so please refer to the - pfctl(8) and the pf.conf(5) man pages - for a complete description of the ALTQ capabilities - and how to use it.

-
-

-

The following options in the kernel configuration file are related - to ALTQ operation:

-

-
-
-
Enable ALTQ.
-
-
Build the “Class Based Queuing” discipline.
-
-
Build the “Controlled Delay” discipline.
-
-
Build the “Random Early Detection” extension.
-
-
Build “Random Early Drop” for input and output.
-
-
Build the “Hierarchical Packet Scheduler” discipline.
-
-
Build the traffic conditioner. This option is meaningless at the moment as - the conditioner is not used by any of the available disciplines or - consumers.
-
-
Build the “Priority Queuing” discipline.
-
-
Build the “Fair Queuing” discipline.
-
-
Required if the TSC is unusable.
-
-
Enable additional debugging facilities.
-
-

Note that ALTQ-disciplines cannot be - loaded as kernel modules. In order to use a certain discipline you have to - build it into a custom kernel. The pf(4) interface, that - is required for the configuration process of ALTQ - can be loaded as a module.

-
-
-
-

-

The driver modifications described in altq(9) - are required to use a certain network card with - ALTQ. They have been applied to the following - hardware drivers: ae(4), age(4), - alc(4), ale(4), - aue(4), axe(4), - bce(4), bfe(4), - bge(4), bxe(4), - cas(4), dc(4), em(4), - epair(4), et(4), - fxp(4), gem(4), - igb(4), ix(4), jme(4), - le(4), liquidio(4), - msk(4), mxge(4), - my(4), nfe(4), nge(4), - qlxgb(4), re(4), - rl(4), sge(4), sis(4), - sk(4), ste(4), - stge(4), ti(4), - udav(4), vge(4), - vr(4), vte(4), and - xl(4).

-

The tun(4), if_bridge(4), - if_vlan(4), and ng_iface(4) pseudo - drivers also do support ALTQ.

-

An example:

-
-
altq on igb0 cbq queue { def aq }
-queue def bandwidth 90% cbq (default borrow)
-queue aq bandwidth 10Mb cbq
-
-pass in on igb0.10 proto udp all queue aq keep state
-
-
-
-

-

pf(4), pf.conf(5), - ipfw(8), pfctl(8), - altq(9)

-
-
-

-

The ALTQ system first appeared in March - 1997 and found home in the KAME project (https://www.kame.net). It was - imported to FreeBSD in 5.3 .

-
-
- - - - - -
January 21, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/amdpm.4 4.html b/static/freebsd/man4/amdpm.4 4.html deleted file mode 100644 index 1a92b763..00000000 --- a/static/freebsd/man4/amdpm.4 4.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - -
AMDPM(4)Device Drivers ManualAMDPM(4)
-
-
-

-

amdpm — AMD - 756/766/768/8111 Power Management controller driver

-
-
-

-

device smbus -
- device smb -
- device amdpm

-
-
-

-

This driver provides access to AMD 756/766/768/8111 Power - management controllers. Currently, only the SMBus 1.0 controller function is - implemented. The SMBus 2.0 functionality of the AMD 8111 controller is - supported via the amdsmb(4) driver.

-

The embedded SMBus controller of the AMD 756 chipset may give you - access to the monitoring facilities of your mainboard. See - smb(4) for writing user code to fetch voltages, - temperature and so on from the monitoring chip of your mainboard.

-
-
-

-

amdsmb(4), intpm(4), - smb(4), smbus(4)

-
-
-

-

The amdpm driver first appeared in - FreeBSD 4.5.

-
-
-

-

This driver was written by Matthew C. - Forman. Based heavily on the alpm driver by - Nicolas Souchu. This manual page was written by - Murray Stokely - <murray@FreeBSD.org>.

-
-
-

-

Only polling mode is supported.

-
-
- - - - - -
December 31, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/amdsbwd.4 4.html b/static/freebsd/man4/amdsbwd.4 4.html deleted file mode 100644 index b1348ab4..00000000 --- a/static/freebsd/man4/amdsbwd.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
AMDSBWD(4)Device Drivers ManualAMDSBWD(4)
-
-
-

-

amdsbwd — device - driver for the AMD southbridge watchdog timers

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device amdsbwd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
amdsbwd_load="YES"
-
-
-
-

-

The amdsbwd driver provides - watchdog(4) support for the watchdog timers present on the - supported chipsets.

-
-
-

-

The amdsbwd driver supports the following - chipsets:

-

-
    -
  • AMD SB600/7x0/8x0/9x0 southbridges
    • -
  • AMD Axx/Hudson/Bolton FCHs
    • -
  • AMD FCHs integrated into Family 15h Models 60h-6Fh, 70h-7Fh - Processors
    • -
  • AMD FCHs integrated into Family 16h Models 00h-0Fh, 30h-3Fh - Processors
    • -
-
-
-

-

watchdog(4), watchdog(8), - watchdogd(8), watchdog(9)

-
-
-

-

The amdsbwd driver first appeared in - FreeBSD 7.3 and FreeBSD - 8.1.

-
-
-

-

The amdsbwd driver was written by - Andriy Gapon - <avg@FreeBSD.org>. - This manual page was written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
September 8, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/amdsmb.4 4.html b/static/freebsd/man4/amdsmb.4 4.html deleted file mode 100644 index 92712059..00000000 --- a/static/freebsd/man4/amdsmb.4 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
AMDSMB(4)Device Drivers ManualAMDSMB(4)
-
-
-

-

amdsmb — AMD-8111 - SMBus 2.0 controller driver

-
-
-

-

device pci -
- device smbus -
- device smb -
- device amdsmb

-
-
-

-

The amdsmb driver provides access to the - AMD-8111 SMBus 2.0 controller.

-
-
-

-

amdpm(4), intpm(4), - smb(4), smbus(4)

-
-
-

-

The amdsmb driver first appeared in - FreeBSD 6.2.

-
-
-

-

The amdsmb driver was written by - Ruslan Ermilov - <ru@FreeBSD.org>.

-
-
- - - - - -
December 31, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/amdsmn.4 4.html b/static/freebsd/man4/amdsmn.4 4.html deleted file mode 100644 index 75127dae..00000000 --- a/static/freebsd/man4/amdsmn.4 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
AMDSMN(4)Device Drivers ManualAMDSMN(4)
-
-
-

-

amdsmn — device - driver for AMD processor System Management Network

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device amdsmn
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
amdsmn_load="YES"
-
-
-
-

-

The amdsmn driver provides support for - resources on the System Management Network bus in AMD Family 17h - processors.

-
-
-

-

loader(8)

-
-
-

-

The amdsmn driver first appeared in - FreeBSD 12.0.

-
-
-

-

Conrad Meyer - <cem@FreeBSD.org>

-
-
- - - - - -
September 5, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/amdtemp.4 3.html b/static/freebsd/man4/amdtemp.4 3.html deleted file mode 100644 index 4e9e19cb..00000000 --- a/static/freebsd/man4/amdtemp.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
AMDTEMP(4)Device Drivers ManualAMDTEMP(4)
-
-
-

-

amdtemp — device - driver for AMD processor on-die digital thermal sensor

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device amdtemp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
amdtemp_load="YES"
-
-
-
-

-

The amdtemp driver provides support for - the on-die digital thermal sensor present in AMD Family 0Fh, 10h, 11h, 12h, - 14h, 15h, 16h, and 17h processors.

-

For Family 0Fh processors, the amdtemp - driver reports each core's temperature through sysctl nodes, named - dev.amdtemp.%d.core{0,1}.sensor{0,1}. The driver also - creates dev.cpu.%d.temperature in the corresponding - CPU device's sysctl tree, displaying the maximum temperature of the two - sensors located in each CPU core.

-

For Family 10h, 11h, 12h, 14h, 15h, 16h, and 17h processors, the - driver reports each package's temperature through a sysctl node, named - dev.amdtemp.%d.core0.sensor0. The driver also creates - dev.cpu.%d.temperature in the corresponding CPU - device's sysctl tree, displaying the temperature of the shared sensor - located in each CPU package.

-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.amdtemp.%d.sensor_offset
-
 
-
-Add the given offset to the temperature of the sensor. Default is 0. -
-
-

-

coretemp(4), loader(8), - sysctl(8)

-
-
-

-

The amdtemp driver first appeared in - FreeBSD 7.1.

-
-
-

-

Rui Paulo - <rpaulo@FreeBSD.org> -
- Norikatsu Shigemura - <nork@FreeBSD.org> -
- Jung-uk Kim - <jkim@FreeBSD.org>

-
-
-

-

For Family 10h and later processors, “(the reported - temperature) is a non-physical temperature measured on an arbitrary scale - and it does not represent an actual physical temperature like die or case - temperature. Instead, it specifies the processor temperature relative to the - point at which the system must supply the maximum cooling for the - processor's specified maximum case temperature and maximum thermal power - dissipation” according to BIOS and - Kernel Developer's Guide (BKDG) for AMD Processors, - http://developer.amd.com/resources/developer-guides-manuals/.

-
-
- - - - - -
September 5, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/aout.4 3.html b/static/freebsd/man4/aout.4 3.html deleted file mode 100644 index 75f51d33..00000000 --- a/static/freebsd/man4/aout.4 3.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - -
AOUT(4)Device Drivers ManualAOUT(4)
-
-
-

-

aout — kernel - support for executing binary files in legacy a.out format

-
-
-

-
-
kldload a.out
-
-
-
-

-

The a.out(5) executable format was used before - the release of FreeBSD 3.0. Since i386 was the only - supported architecture at that time, a.out(5) executables - can only be activated on platforms that support execution of i386 code, such - as i386 and amd64.

-

To add kernel support for old syscalls and old syscall invocation - methods, place the following options in the kernel configuration file:

-
options COMPAT_43 -
-options COMPAT_FREEBSD32
-

The COMPAT_FREEBSD32 option is only required - on 64-bit CPU architectures.

-

The aout.ko module needs to be loaded with - the kldload(8) utility in order to support the - a.out(5) image activator:

-
kldload aout
-

Alternatively, to load the module at boot time, place the - following line in loader.conf(5):

-
-
aout_load="YES"
-
-

The a.out(5) format was mainstream quite a long - time ago. Reasonable default settings and security requirements of modern - operating systems today contradict the default environment of that time and - require adjustments of the system to mimic natural environment for old - binaries.

-

The following sysctl(8) tunables are useful for - this:

-
-
-
security.bsd.map_at_zero
-
Set to 1 to allow mapping of process pages at address 0. Some very old - ZMAGIC executable images require text mapping at - address 0.
-
kern.pid_max
-
Old versions of FreeBSD used signed 16-bit type - for pid_t. Current kernels use 32-bit type for - pid_t, and allow process id's up to 99999. Such - values cannot be represented by old pid_t, mostly - causing issues for processes using wait(2) syscalls, for - example shells. Set the sysctl to 30000 to work around the problem.
-
kern.elf32.read_exec
-
Set to 1 to force any accessible memory mapping performed by 32-bit - process to allow execution, see mmap(2). Old i386 CPUs - did not have a bit in PTE which disallowed execution from the page, so - many old programs did not specify PROT_EXEC even for - mapping of executable code. The sysctl forces - PROT_EXEC if mapping has any access allowed at all. - The setting is only needed if the host architecture allows non-executable - mappings.
-
-
-
-
-

-

execve(2), a.out(5), - elf(5), sysctl(8)

-
-
-

-

The a.out(5) executable format was used on - ancient AT&T UNIX and served as the main - executable format for FreeBSD from the beginning up - to FreeBSD 2.2.9. In FreeBSD - 3.0 it was superseded by elf(5).

-
-
-

-

The aout manual page was written by - Konstantin Belousov - <kib@FreeBSD.org>.

-
-
-

-

On 64bit architectures, not all wrappers for older syscalls are - implemented.

-
-
- - - - - -
August 14, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/apic.4 3.html b/static/freebsd/man4/apic.4 3.html deleted file mode 100644 index 25426ae0..00000000 --- a/static/freebsd/man4/apic.4 3.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
APIC(4)Device Drivers ManualAPIC(4)
-
-
-

-

apic — Advanced - Programmable Interrupt Controller (APIC) driver

-
-
-

-

This driver is a mandatory part of amd64 kernel. To compile this - driver into i386 kernel, place the following line in your kernel - configuration file:

-
device apic
-

The following tunables are settable from the - loader(8):

-
-
hint.apic.X.clock
-
controls event timers functionality support. Setting to 0, disables it. - Default value is 1.
-
hint.apic.X.disabled
-
Set this to 1 to disable APIC support, falling back to the legacy - PIC.
-
-
-
-

-

There are two components in the Intel APIC system, the local APIC - (LAPIC) and the I/O APIC. There is one local APIC in each CPU in the system. - There is typically one I/O APIC for each peripheral bus in the system.

-

Local APICs manage all external interrupts for a specific - processor. In addition, they are able to accept and generate inter-processor - interrupts (IPIs).

-

I/O APICs contain a redirection table, which is used to route the - interrupts they receive from peripheral buses to one or more local - APICs.

-

Each local APIC includes one 32-bit programmable timer. This - driver uses them to supply kernel with one event timer named - "LAPIC". Event timer provided by the driver supports both one-shot - and periodic modes. Because of local APIC nature it is per-CPU. The timer - frequency is not reported by the platform and so automatically measured by - the driver on the first use. Depending on CPU model this timer may stop in - C3 and deeper CPU sleep states. Driver automatically adjusts event timer - priority and reports it to prevent entering dangerous sleep states when it - is used.

-
-
-

-

atrtc(4), attimer(4), - eventtimers(4), hpet(4)

-
-
- - - - - -
June 19, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/appleir.4 3.html b/static/freebsd/man4/appleir.4 3.html deleted file mode 100644 index 1845b338..00000000 --- a/static/freebsd/man4/appleir.4 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
APPLEIR(4)Device Drivers ManualAPPLEIR(4)
-
-
-

-

appleir — Apple IR - receiver driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device appleir -
-device hidbus -
-device hid -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
appleir_load="YES"
-
-
-
-

-

The appleir driver provides support for - Apple IR receivers found in Mac computers (2006-2011 era). It supports both - Apple Remote controls and generic IR remotes using the NEC infrared - protocol.

-

Supported devices include:

-
    -
  • Apple IR Receiver (USB product IDs 0x8240, 0x8241, 0x8242, 0x8243, - 0x1440)
    • -
-

The driver decodes proprietary Apple Remote button presses and - provides a default keymap for common NEC protocol codes used by generic IR - remotes. Unmapped button codes can be accessed via the raw HID device at - /dev/hidrawX for custom userland remapping.

-

The /dev/input/eventX device presents the - remote control as an evdev input device with standard KEY_* codes suitable - for media applications.

-
-
-

-

The appleir driver supports Apple IR - receivers with USB vendor ID 0x05ac and the following product IDs:

-

-
-
0x8240
-
Apple IR Receiver (first generation)
-
0x8241
-
Apple IR Receiver
-
0x8242
-
Apple IR Receiver (Mac Mini 2011, MacBook Pro 3,1)
-
0x8243
-
Apple IR Receiver
-
0x1440
-
Apple IR Receiver (slim)
-
-
-
-

-
-
/dev/input/eventX
-
evdev input device
-
/dev/hidrawX
-
raw HID device for custom button mapping
-
-
-
-

-

evdev , hidbus(4), - usbhid(4)

-

NEC Infrared Transmission Protocol: - https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol

-
-
-

-

The appleir driver first appeared in - FreeBSD 16.0.

-
-
-

-

Abdelkader Boudih - <freebsd@seuros.com>

-

Based on protocol reverse-engineering by James McKenzie and - others.

-
-
- - - - - -
February 13, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/aq.4 4.html b/static/freebsd/man4/aq.4 4.html deleted file mode 100644 index 21e5f2ca..00000000 --- a/static/freebsd/man4/aq.4 4.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - -
AQ(4)Device Drivers ManualAQ(4)
-
-
-

-

aq — Aquantia / - Marvell AQ1xx 10 Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device aq
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_aq_load="YES"
-
-
-
-

-

The aq device driver provides support for - PCIe 1/2.5/5/10 Gigabit Ethernet adapters based on Aquantia (now Marvell) - AQtion AQC1xx Ethernet controllers.

-

For more information on configuring this device, see - ifconfig(8).

-

The aq driver is experimental, and has a - number of caveats and limitations.

-
-
-

-

The aq driver supports the following 10 - Gigabit Ethernet PCIe controllers:

-

-
    -
  • aQuantia AQC107
    • -
  • aQuantia AQC108
    • -
  • aQuantia AQC109
    • -
  • aQuantia AQC111
    • -
  • aQuantia AQC112
    • -
-
-
-

-

arp(4), miibus(4), - ifconfig(8)

-
-
- - - - - -
December 1, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/arcmsr.4 3.html b/static/freebsd/man4/arcmsr.4 3.html deleted file mode 100644 index 352c6c88..00000000 --- a/static/freebsd/man4/arcmsr.4 3.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - -
ARCMSR(4)Device Drivers ManualARCMSR(4)
-
-
-

-

arcmsr — Areca - RAID Controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device da -
-device arcmsr
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
arcmsr_load="YES"
-
-
-
-

-

The arcmsr driver provides support for the - Areca ARC-11xx, ARC-12xx, ARC-13xx, ARC-16xx and ARC-18xx series of SAS and - SATA RAID controllers. These controllers feature RAID-0, 1, 3, 5, 6, and 10 - and JBOD acceleration for up to 16 SATA drives. RAID level and stripe level - migration, online capacity expansion, hot insertion/removal, automatic - failover and rebuild, and SMART are also supported. Access to the arrays is - provided via the SCSI CAM /dev/da? device nodes. A - management interface is also present via the - /dev/arcmsr? device node. Management tools for i386 - and amd64 are available from Areca.

-
-
-

-

The arcmsr driver supports the following - Areca PCI-X/PCIe SATA/SAS/NVMe RAID host adapters:

-

-
    -
  • ARC-1110
    • -
  • ARC-1120
    • -
  • ARC-1130
    • -
  • ARC-1160
    • -
  • ARC-1170
    • -
  • ARC-1110ML
    • -
  • ARC-1120ML
    • -
  • ARC-1130ML
    • -
  • ARC-1160ML
    • -
  • ARC-1200
    • -
  • ARC-1201
    • -
  • ARC-1203
    • -
  • ARC-1210
    • -
  • ARC-1212
    • -
  • ARC-1213
    • -
  • ARC-1214
    • -
  • ARC-1216
    • -
  • ARC-1220
    • -
  • ARC-1222
    • -
  • ARC-1223
    • -
  • ARC-1224
    • -
  • ARC-1226
    • -
  • ARC-1230
    • -
  • ARC-1231
    • -
  • ARC-1260
    • -
  • ARC-1261
    • -
  • ARC-1270
    • -
  • ARC-1280
    • -
  • ARC-1210ML
    • -
  • ARC-1220ML
    • -
  • ARC-1231ML
    • -
  • ARC-1261ML
    • -
  • ARC-1280ML
    • -
  • ARC-1380
    • -
  • ARC-1381
    • -
  • ARC-1680
    • -
  • ARC-1681
    • -
  • ARC-1880
    • -
  • ARC-1882
    • -
  • ARC-1883
    • -
  • ARC-1884
    • -
  • ARC-1886
    • -
-
-
-

-
-
/dev/da?
-
Array block device
-
/dev/arcmsr?
-
Management interface
-
-
-
-

-

da(4), scbus(4)

-
-
-

-

The arcmsr driver first appeared in - FreeBSD 5.4.

-
-
-

-

The driver was written by Erich Chen - <erich@areca.com.tw>.

-
-
-

-

The driver has been tested on i386 and amd64. It likely requires - additional work to function on big-endian architectures.

-
-
- - - - - -
April 5, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/arswitch.4 3.html b/static/freebsd/man4/arswitch.4 3.html deleted file mode 100644 index 3650f932..00000000 --- a/static/freebsd/man4/arswitch.4 3.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
ARSWITCH(4)Device Drivers ManualARSWITCH(4)
-
-
-

-

arswitch — Atheros - AR8000 series Ethernet switch driver

-
-
-

-

device mdio -
- device etherswitch -
- device arswitch

-
-
-

-

The arswitch driver provides a management - interface to Atheros AR8000 series Ethernet switch controllers. The driver - uses an mdio(4) or miibus(4) interface - to configure the ethernet interface.

-

This driver supports port based vlan, and IEEE 802.1Q (QinQ). - These options can be configured with the etherswitchcfg(8) - command. arswitch supports - addtag, striptag, and - doubletag. addtag and - striptag are mutually exclusive.

-

Setting the switch MAC address is not supported.

-
-
-

-

The arswitch driver supports the following - Ethernet switch controllers:

-

-
    -
  • Atheros AR8327 Seven-port Gigabit Ethernet Switch
    • -
  • Atheros AR8316 Six-port Gigabit Ethernet Switch
    • -
  • Atheros AR8236 Six-port Fast Ethernet Switch
    • -
  • Atheros AR8226 Six-port Fast Ethernet Switch
    • -
  • Atheros AR8216 Six-port Fast Ethernet Switch
    • -
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The arswitch device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The arswitch manual was written by - Felix Johnson.

-
-
- - - - - -
May 11, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/asmc.4 3.html b/static/freebsd/man4/asmc.4 3.html deleted file mode 100644 index 94a058c9..00000000 --- a/static/freebsd/man4/asmc.4 3.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - -
ASMC(4)Device Drivers ManualASMC(4)
-
-
-

-

asmc — device - driver for the Apple System Management Controller (SMC)

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device asmc
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
asmc_load="YES"
-
-
-
-

-

The asmc driver controls the Apple System - Management Controller (SMC for short) found on Intel Apple systems.

-

The SMC is known to be found on the following systems:

-

-
    -
  • MacBook
    • -
  • MacBook Pro
    • -
  • Intel MacMini
    • -
  • Mac Pro
    • -
  • MacBook Air
    • -
  • Intel iMac
    • -
-

With this driver, you can configure your keyboard backlight - brightness, check temperatures of several sensors, check the speed of the - internal fans and check the status of the Sudden Motion Sensor.

-

Variables related to the SMC control and inspection are exported - via sysctl(3) under the device tree - dev.asmc.

-
-
-

-

On MacBook Pro systems, you can control the keyboard brightness by - writing a value to the dev.asmc.%d.light.control - sysctl MIB or with backlight(8) utility.

-

The following sysctl MIBs contains the raw value returned by the - left and right light sensors: dev.asmc.%d.light.left - or dev.asmc.%d.light.right.

-
-
-

-

The number of temperature sensors and their description varies - among systems. You can inspect the temperature sensors on your system by - traversing the dev.asmc.temp sysctl MIB.

-

All values are in degrees celsius.

-
-
-

-

The dev.asmc.fan.%d sysctl tree contains the - leaf nodes speed, safespeed, - minspeed, maxspeed and - targetspeed. Each of these leaf nodes represent the - current fan speed, the safest minimum fan speed, the minimum speed and the - maximum speed respectively.

-

All values are in RPM.

-
-
-

-

When the kernel is compiled with the - ASMC_DEBUG option, a set of sysctl nodes is provided - under dev.asmc.%d.raw for reading and writing - arbitrary SMC keys by name.

-

-
-
dev.asmc.%d.raw.key
-
Set the 4-character SMC key name to access (e.g., “AUPO”). - Setting this automatically queries the key's length and type.
-
dev.asmc.%d.raw.value
-
Read or write the key's value as a hex string.
-
dev.asmc.%d.raw.len
-
The auto-detected value length in bytes (read-only).
-
dev.asmc.%d.raw.type
-
The 4-character SMC type string (e.g., “ui8”, - “flt”) (read-only).
-
-

Example usage:

-
-
sysctl dev.asmc.0.raw.key=AUPO
-sysctl dev.asmc.0.raw.value
-sysctl dev.asmc.0.raw.value=01
-
-
-
-

-

The Sudden Motion Sensor (SMS for short) is a device that detects - laptop movement and notifies the operating system via an interrupt. The - sysctl MIBs present under dev.asmc.sms all relate to - the SMS.

-

The most interesting usage of this device is to park the disk - heads when the laptop is moved harshly. First, you need to install - ataidle(8) - (ports/sysutils/ataidle) and then configure - devd(8) the following way:

-
-
notify 0 {
-	match "system"		"ACPI";
-	match "subsystem"	"asmc";
-	action			"/usr/local/sbin/ataidle -s X Y";
-};
-
-

Do not forget to change the X and - Y values in the command above.

-

Also, please note that parking the disk heads too many times can - dramatically reduce your hard drive's life span. Do not rely solely on the - SMS to protect your hard drive: good care and common sense can increase your - hard drive's life.

-
-
-

-
-
/dev/backlight/asmc0
-
Keyboard backlight(8) device node.
-
-
-
-

-

ataidle(8) - (ports/sysutils/ataidle), - backlight(8), devd(8), - sysctl(8)

-
-
-

-

The asmc driver first appeared in - FreeBSD 8.0.

-
-
-

-

Rui Paulo - <rpaulo@FreeBSD.org> - (Google Summer of Code project)

-
-
-

-

Support for the latest models was never tested and is most likely - not fully working.

-
-
- - - - - -
March 29, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/at45d.4 3.html b/static/freebsd/man4/at45d.4 3.html deleted file mode 100644 index ed076e17..00000000 --- a/static/freebsd/man4/at45d.4 3.html +++ /dev/null @@ -1,150 +0,0 @@ - - - - - - -
AT45D(4)Device Drivers ManualAT45D(4)
-
-
-

-

at45d — driver for - DataFlash(tm) non-volatile storage devices

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device at45d
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
at45d_load="YES"
-
-
-
-

-

The at45d driver provides support for the - family of non-volatile storage devices known collectively as DataFlash(tm). - DataFlash chips typically have part numbers beginning with AT45DB. The - at45d driver supports only the SPI bus versions of - each AT45DB device, indicated by the last digit of the part number being 1 - or 2.

-

The at45d driver uses opcode 0x9f to read - the manufacturer and device ID data to determine whether the device is - supported. The device ID is looked up using a table of data within the - driver which describes the attributes of each supported device, such as - block size, sector size, and device capacity. When a supported device is - found, the at45d driver creates a disk device and - makes it accessible at /dev/flash/at45d?. The new - disk device is then tasted by the available geom(4) - modules as with any disk device.

-
-
-

-

The at45d driver provides support for the - following devices:

-

-
    -
  • AT45DB011B
    • -
  • AT45DB021B
    • -
  • AT45DB041x
    • -
  • AT45DB081B
    • -
  • AT45DB161x
    • -
  • AT45DB321x
    • -
  • AT45DB321x
    • -
  • AT45DB641E
    • -
  • AT45DB642x
    • -
-
-
-

-

On an fdt(4) based system, the - at45d device is defined as a slave device subnode of - the SPI bus controller node. All properties documented in the - spibus.txt bindings document can be used with the - at45d device. The most commonly-used ones are - documented below.

-

The following properties are required in the - at45d device subnode:

-
-
compatible
-
Must be the string "atmel,at45".
-
reg
-
Chip select address of device.
-
spi-max-frequency
-
The maximum bus frequency to use when communicating with this slave - device. Actual bus speed may be lower, depending on the capabilities of - the SPI bus controller hardware.
-
-

The following properties are optional for the - at45d device subnode:

-
-
freebsd,sectorsize
-
The sector size of the disk created for this storage device. It must be a - multiple of the device's page size. The default is the device page - size.
-
spi-cpha
-
Empty property indicating the slave device requires shifted clock phase - (CPHA) mode.
-
spi-cpol
-
Empty property indicating the slave device requires inverse clock polarity - (CPOL) mode.
-
spi-cs-high
-
Empty property indicating the slave device requires chip select active - high.
-
-
-
-

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - at45d:

-
-
hint.at45d.%d.at
-
The spibus the at45d instance is attached to.
-
hint.at45d.%d.clock
-
The maximum bus frequency to use when communicating with this device. - Actual bus speed may be lower, depending on the capabilities of the SPI - bus controller hardware.
-
hint.at45d.%d.cs
-
The chip-select number to assert when performing I/O for this device. Set - the high bit (1 << 31) to invert the logic level of the chip select - line.
-
hint.at45d.%d.mode
-
The SPI mode (0-3) to use when communicating with this device.
-
hint.at45d.%d.sectorsize
-
The sector size of the disk created for this storage device. It must be a - multiple of the device's page size. The default is the device page - size.
-
-
-
-

-
-
/dev/flash/at45d?
-
Provides read/write access to the storage device.
-
/dev/flash/spi?
-
An alias for the /dev/at45d? device, for backwards - compatibility with older versions of the driver.
-
-
-
-

-

fdt(4), geom(4)

-
-
-

-

The at45d driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
March 2, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ata.4 3.html b/static/freebsd/man4/ata.4 3.html deleted file mode 100644 index 04d8646b..00000000 --- a/static/freebsd/man4/ata.4 3.html +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - -
ATA(4)Device Drivers ManualATA(4)
-
-
-

-

ata — generic - ATA/SATA controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device ata
-

Alternatively, to load the driver as set of modules at boot time, - place some of the following lines in loader.conf(5):

-
-
ata_load="YES"
-
-ataisa_load="YES"
-atapci_load="YES"
-
-ataacard_load="YES"
-ataacerlabs_load="YES"
-ataamd_load="YES"
-ataati_load="YES"
-atacenatek_load="YES"
-atacypress_load="YES"
-atacyrix_load="YES"
-atahighpoint_load="YES"
-ataintel_load="YES"
-ataite_load="YES"
-atajmicron_load="YES"
-atamarvell_load="YES"
-atamicron_load="YES"
-atanational_load="YES"
-atanetcell_load="YES"
-atanvidia_load="YES"
-atapromise_load="YES"
-ataserverworks_load="YES"
-atasiliconimage_load="YES"
-atasis_load="YES"
-atavia_load="YES"
-
-

The first line is for the common hardware independent code, and is - a prerequisite for the other modules. The next three lines are generic - bus-specific drivers. The rest are vendor-specific PCI drivers.

-

The following tunables are settable from the - loader(8):

-
-
hw.ata.ata_dma_check_80pin
-
set to 0 to disable the 80pin cable check (the default is 1, check the - cable).
-
hint.atapci.X.msi
-
set to 1 to allow Message Signalled Interrupts (MSI) to be used by the - specified PCI ATA controller, if supported.
-
hint.ata.X.devX.mode
-
limits the initial ATA mode for the specified device on the specified - channel.
-
hint.ata.X.mode
-
limits the initial ATA mode for every device on the specified - channel.
-
hint.ata.X.pm_level
-
controls SATA interface Power Management for the specified channel, - allowing some power savings at the cost of additional command latency. - Possible values: -

-
-
-
0
-
Interface Power Management is disabled. This is the default - value.
-
1
-
The device is allowed to initiate a PM state change; the host is - passive.
-
-
-
-
hint.ata.X.devX.sata_rev
-
limits the initial SATA revision (speed) for the specified device on the - specified channel. Values 1, 2 and 3 are respectively 1.5, 3 and - 6Gbps.
-
hint.ata.X.sata_rev
-
Same, but for every device on the specified channel.
-
-
-
-

-

The ata driver gives the - CAM(4) subsystem access to the ATA (IDE) and SATA ports of - many generic controllers. Depending on the controller, each PATA (IDE) port - or each one or two SATA ports are represented to CAM as a separate bus with - one or two targets. Most of the bus-management details are handled by the - ATA/SATA-specific transport of CAM. Connected ATA disks are handled by the - ATA protocol disk peripheral driver ada(4). ATAPI devices - are handled by the SCSI protocol peripheral drivers cd(4), - da(4), sa(4), etc.

-

This driver supports ATA, and for the most of controllers, ATAPI - devices. Command queuing and SATA port multipliers are not supported. Device - hot-plug and SATA interface power management is supported only on some - controllers.

-

The ata driver can change the transfer - mode when the system is up and running. See the - negotiate subcommand of - camcontrol(8).

-

The ata driver sets the maximum - transfer mode supported by the hardware as default. However, the - ata driver sometimes warns: - “”. This means that the - ata driver has detected that the required 80 - conductor cable is not present or could not be detected properly, or that - one of the devices on the channel only accepts up to UDMA2/ATA33. The - hw.ata.ata_dma_check_80pin tunable can be set to 0 to - disable this check.

-
-
-

-

The ata driver supports the IDE interface - on the following ATA/SATA controllers:

-

-
-
Acard:
-
ATP850P, ATP860A, ATP860R, ATP865A, ATP865R.
-
ALI:
-
M5228, M5229, M5281, M5283, M5287, M5288, M5289.
-
AMD:
-
AMD756, AMD766, AMD768, AMD8111, CS5536.
-
ATI:
-
IXP200, IXP300, IXP400, IXP600, IXP700, IXP800.
-
CMD:
-
CMD646, CMD646U2, CMD648, CMD649.
-
Cypress:
-
Cypress 82C693.
-
Cyrix:
-
Cyrix 5530.
-
HighPoint:
-
HPT302, HPT366, HPT368, HPT370, HPT371, HPT372, HPT372N, HPT374.
-
Intel:
-
6300ESB, 31244, PIIX, PIIX3, PIIX4, ESB2, ICH, ICH0, ICH2, ICH3, ICH4, - ICH5, ICH6, ICH7, ICH8, ICH9, ICH10, SCH, PCH.
-
ITE:
-
IT8211F, IT8212F, IT8213F.
-
JMicron:
-
JMB360, JMB361, JMB363, JMB365, JMB366, JMB368.
-
Marvell
-
88SE6101, 88SE6102, 88SE6111, 88SE6121, 88SE6141, 88SE6145.
-
National:
-
SC1100.
-
NetCell:
-
NC3000, NC5000.
-
nVidia:
-
nForce, nForce2, nForce2 MCP, nForce3, nForce3 MCP, nForce3 Pro, nForce4, - MCP51, MCP55, MCP61, MCP65, MCP67, MCP73, MCP77, MCP79, MCP89.
-
Promise:
-
PDC20246, PDC20262, PDC20263, PDC20265, PDC20267, PDC20268, PDC20269, - PDC20270, PDC20271, PDC20275, PDC20276, PDC20277, PDC20318, PDC20319, - PDC20371, PDC20375, PDC20376, PDC20377, PDC20378, PDC20379, PDC20571, - PDC20575, PDC20579, PDC20580, PDC20617, PDC20618, PDC20619, PDC20620, - PDC20621, PDC20622, PDC40518, PDC40519, PDC40718, PDC40719.
-
ServerWorks:
-
HT1000, ROSB4, CSB5, CSB6, K2, Frodo4, Frodo8.
-
Silicon Image:
-
SiI0680, SiI3112, SiI3114, SiI3512.
-
SiS:
-
SIS180, SIS181, SIS182, SIS5513, SIS530, SIS540, SIS550, SIS620, SIS630, - SIS630S, SIS633, SIS635, SIS730, SIS733, SIS735, SIS745, SIS961, SIS962, - SIS963, SIS964, SIS965.
-
VIA:
-
VT6410, VT6420, VT6421, VT82C586, VT82C586B, VT82C596, VT82C596B, - VT82C686, VT82C686A, VT82C686B, VT8231, VT8233, VT8233A, VT8233C, VT8235, - VT8237, VT8237A, VT8237S, VT8251, CX700, VX800, VX855, VX900.
-
-

Some of above chips can be configured for AHCI mode. In such case - they are supported by ahci(4) driver instead.

-

Unknown ATA chipsets are supported in PIO modes, and if the - standard busmaster DMA registers are present and contain valid setup, DMA is - also enabled, although the max mode is limited to UDMA33, as it is not known - what the chipset can do and how to program it.

-
-
-

-

Please remember that in order to use UDMA4/ATA66 and above modes - you - use 80 conductor cables. Please assure that ribbon cables are no longer than - 45cm. In case of rounded ATA cables, the length depends on the quality of - the cables. SATA cables can be up to 1m long according to the specification. - External SATA cables can be 2m long and more, but not all controllers work - well on long cables, especially at high speeds.

-
-
-

-

ada(4), ahci(4), - cam(4), cd(4), mvs(4), - siis(4), camcontrol(8)

-
-
-

-

The ata driver first appeared in - FreeBSD 4.0. It was turned into a - CAM(4) interface module in FreeBSD - 9.0.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org> -
- Søren Schmidt - <sos@FreeBSD.org>

-
-
- - - - - -
March 23, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/ath.4 3.html b/static/freebsd/man4/ath.4 3.html deleted file mode 100644 index e84661ea..00000000 --- a/static/freebsd/man4/ath.4 3.html +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - -
ATH(4)Device Drivers ManualATH(4)
-
-
-

-

ath — Atheros IEEE - 802.11 wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ath -
-device ath_hal -
-device ath_rate_sample -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ath_load="YES"
-
-
-
-

-

The ath driver provides support for - wireless network adapters based on the Atheros AR5210, AR5211, AR5212, - AR5416 and AR9300 programming APIs. These APIs are used by a wide variety of - chips; most all chips with a PCI, PCIe and/or CardBus interface are - supported.

-

Supported features include 802.11 and 802.3 frames, power - management, BSS, IBSS, MBSS, WDS/DWDS TDMA, and host-based access point - operation modes. All host/device interaction is via DMA.

-

The ath driver encapsulates all IP and ARP - traffic as 802.11 frames, however it can receive either 802.11 or 802.3 - frames. Transmit speed and operating mode is selectable and depends on the - specific chipset. AR5210-based devices support 802.11a operation with - transmit speeds of 6 Mbps, 9 Mbps, 12 Mbps, 18 Mbps, 24 Mbps, 36 Mbps, 48 - Mbps, and 54 Mbps. AR5211-based devices support 802.11a and 802.11b - operation with transmit speeds as above for 802.11a operation and 1Mbps, - 2Mbps, 5.5 Mbps and 11Mbps for 802.11b operation. AR5212-based devices - support 802.11a, 802.11b, and 802.11g operation with transmit speeds - appropriate to each. AR5416 and later class devices are capable of 802.11n - operation. Most chips also support an Atheros Turbo Mode (TM) that operates - in the 5GHz frequency range with 2x the transmit speeds. Some chips also - support Turbo mode in the 2.4GHz range with 802.11g though this support is - not presently available due to regulatory requirements. (Note that Turbo - modes are, however, only interoperable with other Atheros-based devices.) - AR5212-based and AR5416-based devices also support half- (10MHz) and - quarter-width (5MHz) channels. The actual transmit speed used is dependent - on signal quality and the “rate control” algorithm employed by - the driver. All chips support WEP encryption. AR5212, AR5416 and later parts - have hardware support for the AES-CCM, TKIP, and Michael cryptographic - operations required for WPA. To enable encryption, use - ifconfig(8) as shown below.

-

The driver supports station, - adhoc, adhoc-demo, - hostap, mesh, - wds, and monitor mode - operation. Multiple hostap virtual interfaces may be - configured for simultaneous use on cards that use a 5212 or later part. When - multiple interfaces are configured each may have a separate mac address that - is formed by setting the U/L bits in the mac address assigned to the - underlying device. Any number of wds virtual - interfaces may be configured together with hostap - interfaces. Multiple station interfaces may be - operated together with hostap interfaces to - construct a wireless repeater device. The driver also support - tdma operation when compiled with - options IEEE80211_SUPPORT_TDMA (which also enables - the required 802.11 support). For more information on configuring this - device, see ifconfig(8).

-

Devices supported by the ath driver come - in Cardbus, ExpressCard, Mini-PCI and Mini-PCIe packages. Wireless cards in - Cardbus and ExpressCard slots may be inserted and ejected on the fly.

-
-
-

-

The ath driver supports all Atheros - Cardbus, ExpressCard, PCI and PCIe cards, except those that are based on the - AR5005VL chipset.

-
-
-

-

Join a specific BSS network with WEP encryption:

-
-
ifconfig wlan0 create wlandev ath0
-ifconfig wlan0 inet 192.168.0.20 netmask 0xffffff00 ssid my_net \
-	wepmode on wepkey 0x8736639624
-
-

Join/create an 802.11b IBSS network with network name - “my_net”:

-
-
ifconfig wlan0 create wlandev ath0 wlanmode adhoc
-ifconfig wlan0 inet 192.168.0.22 netmask 0xffffff00 ssid my_net \
-	mode 11b
-
-

Create an 802.11g host-based access point:

-
-
ifconfig wlan0 create wlandev ath0 wlanmode hostap
-ifconfig wlan0 inet 192.168.0.10 netmask 0xffffff00 ssid my_ap \
-	mode 11g
-
-

Create an 802.11a mesh station:

-
-
ifconfig wlan0 create wlandev ath0 wlanmode mesh
-ifconfig wlan0 meshid my_mesh mode 11a inet 192.168.0.10/24
-
-

Create two virtual 802.11a host-based access points, one with WEP - enabled and one with no security, and bridge them to the fxp0 (wired) - device:

-
-
ifconfig wlan0 create wlandev ath0 wlanmode hostap \
-	ssid paying-customers wepmode on wepkey 0x1234567890 \
-	mode 11a up
-ifconfig wlan1 create wlandev ath0 wlanmode hostap bssid \
-	ssid freeloaders up
-ifconfig bridge0 create addm wlan0 addm wlan1 addm fxp0 up
-
-

Create a master node in a two slot TDMA BSS configured to use 2.5 - millisecond slots.

-
-
ifconfig wlan0 create wlandev ath0 wlanmode tdma \
-	ssid tdma-test tmdaslot 0 tdmaslotlen 2500 \
-	channel 36 up
-
-
-
-

-
-
ath%d: unable to attach hardware; HAL status %u
-
The Atheros Hardware Access Layer was unable to configure the hardware as - requested. The status code is explained in the HAL include file - sys/dev/ath/ath_hal/ah.h.
-
ath%d: failed to allocate descriptors: %d
-
The driver was unable to allocate contiguous memory for the transmit and - receive descriptors. This usually indicates system memory is scarce and/or - fragmented.
-
ath%d: unable to setup a data xmit queue!
-
The request to the HAL to set up the transmit queue for normal data frames - failed. This should not happen.
-
ath%d: unable to setup a beacon xmit queue!
-
The request to the HAL to set up the transmit queue for 802.11 beacon - frames failed. This should not happen.
-
ath%d: 802.11 address: %s
-
The MAC address programmed in the EEPROM is displayed.
-
ath%d: hardware error; resetting
-
An unrecoverable error in the hardware occurred. Errors of this sort - include unrecoverable DMA errors. The driver will reset the hardware and - continue.
-
ath%d: rx FIFO overrun; resetting
-
The receive FIFO in the hardware overflowed before the data could be - transferred to the host. This typically occurs because the hardware ran - short of receive descriptors and had no place to transfer received data. - The driver will reset the hardware and continue.
-
ath%d: unable to reset hardware; hal status %u
-
The Atheros Hardware Access Layer was unable to reset the hardware as - requested. The status code is explained in the HAL include file - sys/dev/ath/ath_hal/ah.h. This should not - happen.
-
ath%d: unable to start recv logic
-
The driver was unable to restart frame reception. This should not - happen.
-
ath%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware and continue. This should not - happen.
-
ath%d: bogus xmit rate 0x%x
-
An invalid transmit rate was specified for an outgoing frame. The frame is - discarded. This should not happen.
-
ath%d: ath_chan_set: unable to reset channel %u (%u MHz)
-
The Atheros Hardware Access Layer was unable to reset the hardware when - switching channels during scanning. This should not happen.
-
ath%d: failed to enable memory mapping
-
The driver was unable to enable memory-mapped I/O to the PCI device - registers. This should not happen.
-
ath%d: failed to enable bus mastering
-
The driver was unable to enable the device as a PCI bus master for doing - DMA. This should not happen.
-
ath%d: cannot map register space
-
The driver was unable to map the device registers into the host address - space. This should not happen.
-
ath%d: could not map interrupt
-
The driver was unable to allocate an IRQ for the device interrupt. This - should not happen.
-
ath%d: could not establish interrupt
-
The driver was unable to install the device interrupt handler. This should - not happen.
-
-
-
-

-

ath_hal(4), cardbus(4), - intro(4), wlan(4), - wlan_ccmp(4), wlan_tkip(4), - wlan_wep(4), wlan_xauth(4), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The ath device driver first appeared in - FreeBSD 5.2.

-
-
-

-

Revision A1 of the D-LINK DWL-G520 and DWL-G650 are based on an - Intersil PrismGT chip and are not supported by this driver.

-
-
-

-

The driver does supports optional station mode power-save - operation.

-

The AR5210 can only do WEP in hardware; consequently hardware - assisted WEP is disabled in order to allow software implementations of TKIP - and CCMP to function. Hardware WEP can be re-enabled by modifying the - driver.

-
-
- - - - - -
August 7, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/ath10k.4 3.html b/static/freebsd/man4/ath10k.4 3.html deleted file mode 100644 index 8115b68f..00000000 --- a/static/freebsd/man4/ath10k.4 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
ATH10K(4)Device Drivers ManualATH10K(4)
-
-
-

-

ath10k — Qualcomm - Atheros IEEE 802.11ac wireless network driver

-
-
-

-

The driver will auto-load without any user interaction using - devmatch(8) if enabled in - rc.conf(5).

-

Only if auto-loading is explicitly disabled, place the following - lines in rc.conf(5) to manually load the driver as a - module at boot time:

-
-
kld_list="${kld_list} if_ath10k"
-
-

It is discouraged to load the driver from - loader(8).

-
-
-

-

The ath10k driver is derived from Qualcomm - Atheros' Linux ath10k driver

-

This driver requires firmware to be loaded - before it will work. The package - wifi-firmware-ath10k-kmod from the - ports/net/wifi-firmware-ath10k-kmod port needs to be - installed before the driver is loaded. Otherwise no - wlan(4) interface can be created using - ifconfig(8). The driver uses the - - and - - compat framework to bridge between the Linux and native - FreeBSD driver code as well as to the native - net80211(4) wireless stack.

-

While ath10k supports all 802.11 a/b/g/n - and ac the compatibility code currently only supports 802.11 a/b/g modes. - Support for 802.11 n/ac is to come.

-
-
-

-

The ath10k driver supports PCIe devices - with the following chipsets:

-

-
-
-
QCA6174
-
 
-
QCA9377
-
 
-
QCA9887
-
 
-
QCA9888
-
 
-
QCA988X
-
 
-
QCA9984
-
 
-
QCA99X0
-
 
-
-
-
-
-

-

wlan(4), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The ath10k driver first appeared in - FreeBSD 14.0.

-
-
-

-

Certainly.

-
-
- - - - - -
September 30, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ath_hal.4 3.html b/static/freebsd/man4/ath_hal.4 3.html deleted file mode 100644 index c49f717f..00000000 --- a/static/freebsd/man4/ath_hal.4 3.html +++ /dev/null @@ -1,334 +0,0 @@ - - - - - - -
ATH_HAL(4)Device Drivers ManualATH_HAL(4)
-
-
-

-

ath_hal — Atheros - Hardware Access Layer (HAL)

-
-
-

-

device ath_hal or -
- device ath_ar5210 -
- device ath_ar5211 -
- device ath_ar5212 -
- device ath_rf2413 -
- device ath_rf2417 -
- device ath_rf2425 -
- device ath_rf5111 -
- device ath_rf5112 -
- device ath_rf5413 -
- device ath_ar5416 -
- device ath_ar9160 -
- device ath_ar9280 -
- device ath_ar9285 -
- device ath_ar9287 -
- device ath_ar9300

-
-
-

-

The hal provides hardware support for wireless network adapters - based on the Atheros AR5210, AR5211, AR5212, AR5213, AR2413, AR2417, AR2425, - AR5413, AR5416, AR5418, AR5424, AR9160, AR9220, AR9280, AR9285, AR9287, - AR9380, AR9390, AR9580, AR9590, AR9562 and QCA9565 chips (and companion - RF/baseband parts). This code is part of the ath(4) driver - but configured separately to allow fine-grained control over the set of - chips supported. Selecting ath_hal enables support - for all PCI and Cardbus devices.

-

Some devices come in Cardbus/MiniPCI/PCI format. Others (for - example AR2413, AR2427, AR5418, AR9280, AR9285, AR9287) come in PCIe, - Mini-PCIe or ExpressCard format.

-

Historically this code has been released in a binary-only form and - packaged as a separate module. With the release of source code for the hal - this is no longer true and the code is tightly integrated with the - driver.

-
-
-

-

The following cards are among those supported by the - ath_hal module:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ChipBusStandard
Aztech WL830PCAR5212CardBusb/g
D-Link DWL-A650AR5210CardBusa
D-Link DWL-AB650AR5211CardBusa/b
D-Link DWL-A520AR5210PCIa
D-Link DWL-AG520AR5212PCIa/b/g
D-Link DWL-AG650AR5212CardBusa/b/g
D-Link DWL-G520BAR5212PCIb/g
D-Link DWL-G650BAR5212CardBusb/g
Elecom LD-WL54AGAR5212Cardbusa/b/g
Elecom LD-WL54AR5211Cardbusa
Fujitsu E5454AR5212Cardbusa/b/g
Fujitsu FMV-JW481AR5212Cardbusa/b/g
Fujitsu E5454AR5212Cardbusa/b/g
HP NC4000AR5212PCIa/b/g
I/O Data WN-ABAR5212CardBusa/b
I/O Data WN-AGAR5212CardBusa/b/g
I/O Data WN-A54AR5212CardBusa
Linksys WMP55AGAR5212PCIa/b/g
Linksys WPC51ABAR5211CardBusa/b
Linksys WPC55AGAR5212CardBusa/b/g
NEC PA-WL/54AGAR5212CardBusa/b/g
Netgear WAG311AR5212PCIa/b/g
Netgear WAB501AR5211CardBusa/b
Netgear WAG511AR5212CardBusa/b/g
Netgear WG311 (aka WG311v1)AR5212PCIb/g
Netgear WG311v2AR5212PCIb/g
Netgear WG311TAR5212PCIb/g
Netgear WG511TAR5212CardBusb/g
Orinoco 8480AR5212CardBusa/b/g
Orinoco 8470WDAR5212CardBusa/b/g
Proxim Skyline 4030AR5210CardBusa
Proxim Skyline 4032AR5210PCIa
Samsung SWL-5200NAR5212CardBusa/b/g
SMC SMC2735WAR5210CardBusa
Sony PCWA-C700AR5212Cardbusa/b
Sony PCWA-C300SAR5212Cardbusb/g
Sony PCWA-C500AR5210Cardbusa
3Com 3CRPAG175AR5212CardBusa/b/g
TP-LINK TL-WDN4800AR9380PCIea/b/g/n
-
-
-

-

ath(4)

-
-
-

-

The ath_hal module first appeared in - FreeBSD 5.2.

-
-
-

-

See ath(4) for known bugs.

-
-
- - - - - -
August 7, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/atkbd.4 3.html b/static/freebsd/man4/atkbd.4 3.html deleted file mode 100644 index 96cab9d1..00000000 --- a/static/freebsd/man4/atkbd.4 3.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - -
ATKBD(4)Device Drivers ManualATKBD(4)
-
-
-

-

atkbd — the AT - keyboard interface

-
-
-

-

options ATKBD_DFLT_KEYMAP -
- makeoptions ATKBD_DFLT_KEYMAP=_keymap_name_ -
- options KBD_DISABLE_KEYMAP_LOAD -
- device atkbd

-

In /boot/device.hints: -
- hint.atkbd.0.at="atkbdc" -
- hint.atkbd.0.irq="1"

-
-
-

-

The atkbd driver, together with the - atkbdc driver, provides access to the AT 84 keyboard - or the AT enhanced keyboard which is connected to the AT keyboard - controller.

-

This driver is required for the console driver - syscons(4) or vt(4).

-

There can be only one atkbd - device defined in the kernel configuration file. This device also requires - the atkbdc keyboard controller to be present. The - number must - always be 1; there is no provision of changing the number.

-
-

-

The AT keyboard has a number of function keys. They are numbered - as follows and can be associated with strings by the - kbdcontrol(1) command. You can use a keyboard map file - (see kbdmap(5)) to map them to arbitrary keys, - particularly the functions in the range from 65 to 96 which are not used by - default.

-

-
-
Function Key number
-
Function Key
-
1, 2,...12
-
F1, F2,... F12
-
13, 14,...24
-
Shift+F1, Shift+F2,... Shift+F12
-
25, 26,...36
-
Ctl+F1, Ctl+F2,... Ctl+F12
-
37, 38,...48
-
Shift+Ctl+F1, Shift+Ctl+F2,... Shift+Ctl+F12
-
49
-
Home and Numpad 7 (without NumLock)
-
50
-
Up Arrow and Numpad 8 (without NumLock)
-
51
-
Page Up and Numpad 9 (without NumLock)
-
52
-
Numpad -
-
53
-
Left Arrow and Numpad 4 (without NumLock)
-
54
-
Numpad 5 (without NumLock)
-
55
-
Right Arrow and Numpad 6 (without NumLock)
-
56
-
Numpad +
-
57
-
End and Numpad 1 (without NumLock)
-
58
-
Down Arrow and Numpad 2 (without NumLock)
-
59
-
Page Down and Numpad 3 (without NumLock)
-
60
-
Ins and Numpad 0 (without NumLock)
-
61
-
Del
-
62
-
Left GUI Key
-
63
-
Right GUI Key
-
64
-
Menu
-
65, 66,...96
-
free (not used by default)
-
-

See the man page for the kbdcontrol(1) command - for how to assign a string to the function key.

-
-
-
-

-
-

-

The following kernel configuration options control the - atkbd driver.

-
-
-
This option sets the default, built-in keymap of the - atkbd driver to the named keymap. See - EXAMPLES below.
-
-
The keymap can be modified by the kbdcontrol(1) command. - This option will disable this feature and prevent the user from changing - key assignment.
-
-
-
-

-

The atkbd driver accepts the following - driver flags. They can be set either in - /boot/device.hints, or else from within the boot - loader (see loader(8)).

-
-
bit 0 (FAIL_IF_NO_KBD)
-
By default the atkbd driver will install even if a - keyboard is not actually connected to the system. This option prevents the - driver from being installed in this situation.
-
bit 1 (NO_RESET)
-
When this option is given, the atkbd driver will - not reset the keyboard when initializing it. It may be useful for laptop - computers whose function keys have special functions and these functions - are forgotten when the keyboard is reset.
-
bit 2 (ALT_SCANCODESET)
-
Certain keyboards, such as those on some ThinkPad models, behave like the - old XT keyboard and require this option.
-
bit 3 (NO_PROBE_TEST)
-
When this option is given, the atkbd driver will - not test the keyboard port during the probe routine. Some machines hang - during boot when this test is performed.
-
-
-
-
-

-

The atkbd driver requires the keyboard - controller atkbdc. Thus, the kernel configuration - file should contain the following lines.

-

-
device atkbdc
-
device atkbd
-

The following example shows how to set the default, built-in - keymap to jp.106.kbd.

-

-
device atkbdc
-
options - ATKBD_DFLT_KEYMAP
-
makeoptions - ATKBD_DFLT_KEYMAP=jp.106
-
device atkbd
-

In both cases, you also need to have following lines in - /boot/device.hints.

-

-
hint.atkbdc.0.at="isa"
-
hint.atkbdc.0.port="0x060"
-
hint.atkbd.0.at="atkbdc"
-
hint.atkbd.0.irq="1"
-
-
-

-

kbdcontrol(1), atkbdc(4), - psm(4), syscons(4), - vt(4), kbdmap(5), - loader(8)

-
-
-

-

The atkbd driver first appeared in - FreeBSD 3.1.

-
-
-

-

The atkbd driver was written by - Søren Schmidt - <sos@FreeBSD.org> and - Kazutaka Yokota - <yokota@FreeBSD.org>. - This manual page was written by Kazutaka Yokota.

-
-
- - - - - -
January 29, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/atkbdc.4 3.html b/static/freebsd/man4/atkbdc.4 3.html deleted file mode 100644 index 4b8ff782..00000000 --- a/static/freebsd/man4/atkbdc.4 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
ATKBDC(4)Device Drivers ManualATKBDC(4)
-
-
-

-

atkbdc — the AT - keyboard controller interface

-
-
-

-

options KBD_RESETDELAY=N -
- options KBD_MAXWAIT=N -
- options KBD_DELAY1=N -
- options KBD_DELAY2=N -
- options KBDIO_DEBUG=N -
- device atkbdc

-

In /boot/device.hints: -
- hint.atkbdc.0.at="isa" -
- hint.atkbdc.0.port="0x060"

-
-
-

-

The keyboard controller atkbdc provides - I/O services for the AT keyboard and PS/2 mouse style pointing devices. This - controller is required for the keyboard driver atkbd - and the PS/2 pointing device driver psm.

-

There can be only one atkbdc device - configured in the system.

-
-
-

-
-

-

The following kernel configuration options can be used to control - the atkbdc driver. They may be set in the kernel - configuration file (see config(8)).

-
-
, -
-
The keyboard driver atkbd and the pointing device - driver psm may ask the - atkbdc driver to reset these devices during the - boot process. It sometimes takes a long time before these devices respond - to the reset command. These options control how long the - atkbdc driver should wait before eventually giving - up -- the driver will wait X * - Y msecs at most. If the drivers seem unable to - detect devices, you may want to increase these values. The default values - are 200 msec for X and 5 for - Y.
-
-
DELAY1 sets the initial key repeat delay to X. The - default value is 500ms. DELAY2 sets the key repeat delay to - Y. The default value is 100ms.
-
-
Sets the debug level to N. The default value is - zero, which suppresses all debugging output.
-
-
-
-
-

-

atkbd(4), psm(4), - config(8)

-
-
-

-

The atkbdc driver first appeared in - FreeBSD 3.1. It is based on the kbdio module in - FreeBSD 2.2.

-
-
-

-

The kbdio module, the atkbdc driver and - this manual page were written by Kazutaka Yokota - <yokota@FreeBSD.org>.

-
-
- - - - - -
February 26, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/atopcase.4 4.html b/static/freebsd/man4/atopcase.4 4.html deleted file mode 100644 index 12b5d03b..00000000 --- a/static/freebsd/man4/atopcase.4 4.html +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - -
ATOPCASE(4)Device Drivers ManualATOPCASE(4)
-
-
-

-

atopcase — Apple - HID-over-SPI transport driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device atopcase -
-device intelspi -
-device spibus -
-device hidbus -
-device hkbd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
atopcase_load="YES"
-hkbd_load="YES"
-
-
-
-

-

The atopcase driver provides support for - Human Interface Devices (HID) on Serial Peripheral Interface (SPI) buses on - Apple Intel Macs.

-
-
-

-

The atopcase driver supports the following - MacBooks produced in 2015-2018 years:

-

-
    -
  • Macbook8,1
    • -
  • Macbook9,1
    • -
  • Macbook10,1
    • -
  • MacbookPro11,4
    • -
  • MacbookPro12,1
    • -
  • MacbookPro13,1
    • -
  • MacbookPro13,2
    • -
  • MacbookPro13,3
    • -
  • MacbookPro14,1
    • -
  • MacbookPro14,2
    • -
  • MacbookPro14,3
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.hid.atopcase.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/backlight/atopcase0
-
Keyboard backlight(8) device node.
-
-
-
-

-

acpi(4), loader.conf(5), - backlight(8), loader(8)

-
-
-

-

The atopcase driver first appeared in - FreeBSD 14.0.

-
-
-

-

The atopcase driver was originally written - by Val Packett - <val@packett.cool> - and marginally improved upon by Vladimir Kondratyev - <wulf@FreeBSD.org>.

-

This manual page was written by Vladimir - Kondratyev - <wulf@FreeBSD.org>.

-
-
-

-

Device interrupts are not acknowledged on some hardware that - results in interrupt storm. Installation of Darwin OSI in - acpi(4) driver fixes the issue. To install Darwin OSI add - following lines to loader.conf(5):

-
-
hw.acpi.install_interface="Darwin"
-
 
-
hw.acpi.remove_interface="Windows - 2009, Windows 2012"
-
 
-
-
-
- - - - - -
August 17, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/atp.4 3.html b/static/freebsd/man4/atp.4 3.html deleted file mode 100644 index f0a77cd8..00000000 --- a/static/freebsd/man4/atp.4 3.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - -
ATP(4)Device Drivers ManualATP(4)
-
-
-

-

atp — Apple - touchpad driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device atp -
-device hid -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
atp_load="YES"
-
-
-
-

-

The atp driver provides support for the - Apple Internal Trackpad device found in many Apple laptops. Older - (Fountain/Geyser) and the newer (Wellspring) trackpad families are all - supported through a unified driver.

-

The driver simulates a three-button mouse using multi-finger tap - detection. Single finger tap generates a left-button click; two-finger tap - maps to the middle button; whereas a three-finger tap gets treated as a - right button click.

-

There is support for 2-finger horizontal scrolling, which - translates to page-back/forward events; vertical multi-finger scrolling - emulates the mouse wheel.

-

A double-tap followed by a drag is treated as a selection gesture; - a virtual left-button click is assumed for the lifespan of the drag.

-

atp supports dynamic reconfiguration using - sysctl(8); through nodes under - hw.usb.atp. Pointer sensitivity can be controlled - using the sysctl tunable hw.usb.atp.scale_factor. - Smaller values of scale_factor result in faster - movement. A simple high-pass filter is used to reduce contributions from - small movements; the threshold for this filter may be controlled by - hw.usb.atp.small_movement. The maximum tolerable - duration of a touch gesture is controlled by - hw.usb.atp.touch_timeout (in microseconds); beyond - this period, touches are considered to be slides. (This conversion also - happens when a finger stroke accumulates at least - hw.usb.atp.slide_min_movement movement (in mickeys). - The maximum time (in microseconds) to allow an association between a double- - tap and drag gesture may be controlled by - hw.usb.atp.double_tap_threshold. Should one want to - disable tap detection and rely only upon physical button presses, set the - following sysctl to a value of 2 - hw.usb.atp.tap_minimum.

-
-
-

-

The atp driver provides support for the - following Product IDs:

-

-
    -
  • PowerBooks, iBooks (IDs: 0x020e, 0x020f, 0x0210, 0x0214, 0x0215, - 0x0216)
    • -
  • Core Duo MacBook & MacBook Pro (IDs: 0x0217, 0x0218, 0x0219)
    • -
  • Core2 Duo MacBook & MacBook Pro (IDs: 0x021a, 0x021b, 0x021c)
    • -
  • Core2 Duo MacBook3,1 (IDs: 0x0229, 0x022a, 0x022b)
    • -
  • 12 inch PowerBook and iBook (IDs: 0x030a, 0x030b)
    • -
  • 15 inch PowerBook (IDs: 0x020e, 0x020f, 0x0215)
    • -
  • 17 inch PowerBook (ID: 0x020d)
    • -
  • Almost all recent Macbook-Pros and Airs (IDs: 0x0223, 0x0223, 0x0224, - 0x0224, 0x0225, 0x0225, 0x0230, 0x0230, 0x0231, 0x0231, 0x0232, 0x0232, - 0x0236, 0x0236, 0x0237, 0x0237, 0x0238, 0x0238, 0x023f, 0x023f, 0x0240, - 0x0241, 0x0242, 0x0243, 0x0244, 0x0245, 0x0246, 0x0247, 0x0249, 0x024a, - 0x024b, 0x024c, 0x024d, 0x024e, 0x0252, 0x0252, 0x0253, 0x0253, 0x0254, - 0x0254, 0x0259, 0x025a, 0x025b, 0x0262, 0x0262, 0x0263, 0x0264, 0x0290, - 0x0291, 0x0292)
    • -
-

To discover the product-id of a touchpad, search for 'Trackpad' in - the output of lshal(1) and look up the property - usb_device.product_id.

-
-
-

-

atp creates a blocking pseudo-device file, - /dev/atp0, which presents the mouse as a - sysmouse or mousesystems type - device--see moused(8) for an explanation of these mouse - types.

-
-
-

-

sysmouse(4), usb(4), - loader.conf(5), xorg.conf(5) - (ports/x11/xorg), moused(8), - sysctl(8)

-
-
-

-

The atp driver was written by - Rohit Grover - <rgrover1@gmail.com>.

-
-
- - - - - -
February 24, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/atrtc.4 4.html b/static/freebsd/man4/atrtc.4 4.html deleted file mode 100644 index 1488f8fb..00000000 --- a/static/freebsd/man4/atrtc.4 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
ATRTC(4)Device Drivers ManualATRTC(4)
-
-
-

-

atrtc — AT - Real-Time Clock (RTC) driver

-
-
-

-

This driver is a mandatory part of i386/amd64 kernels.

-

The following tunables are settable from the - loader(8):

-
-
hint.atrtc.X.clock
-
controls event timers functionality support. Setting to 0, disables it. - Default value is 1.
-
hw.atrtc.enabled
-
Forces enabling or disabling of the device(s). Setting to 0 disables it, - setting to 1 enables it, bypassing any platform configuration hints. - Default value is -1 (autodetect).
-
-
-
-

-

This driver uses RTC hardware to supply kernel with time-of-day - clock with 1 second resolution and one event timer. This hardware uses base - frequency of 32768Hz for advancing time-of-day clock and generating periodic - interrupts. Interrupts could be generated with fixed number of frequencies, - from 2Hz to 8192Hz, obtained by dividing base frequency by one of supported - power-of-2 divisors.

-

Event timer provided by the driver is irrelevant to CPU power - states.

-
-
-

-

apic(4), attimer(4), - eventtimers(4), hpet(4)

-
-
- - - - - -
December 15, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/attimer.4 3.html b/static/freebsd/man4/attimer.4 3.html deleted file mode 100644 index a43f8daf..00000000 --- a/static/freebsd/man4/attimer.4 3.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
ATTIMER(4)Device Drivers ManualATTIMER(4)
-
-
-

-

attimer — i8254 - Programmable Interval Timer (AT Timer) driver

-
-
-

-

This driver is a mandatory part of x86 kernels.

-

The following tunables are settable from the - loader(8):

-
-
hint.attimer.X.clock
-
controls support for the event timer functionality. Setting this value to - 0 disables it. The default value is - 1.
-
hint.attimer.X.timecounter
-
controls support for the time counter functionality. Setting this value to - 0 disables it. The default value is - 1.
-
hw.i8254.freq
-
allows overriding the default counter frequency. The same value is also - available at run-time via the machdep.i8254_freq - sysctl.
-
-
-
-

-

This driver uses i8254 Programmable Interval Timer (AT Timer) - hardware to supply the kernel with one timecounter and one event timer, and - to generate sound tones for the system speaker. This hardware includes three - channels. Each channel includes a 16 bit counter which decreases with a - known, platform-dependent frequency. Counters can operate in several - different modes, including periodic and one-shot. The output of each channel - has platform-defined wiring: one channel is wired to the interrupt - controller and may be used as event timer, one channel is wired to the - speaker and used to generate sound tones, and one timer is reserved for - platform purposes.

-

The attimer driver uses a single hardware - channel to provide both time counter and event timer functionality. To make - this possible, the respective counter must be running in periodic mode. As a - result, the one-shot event timer mode is supported only when time counter - functionality is disabled.

-

The event timer provided by the driver is irrelevant to CPU power - states.

-
-
-

-

apic(4), atrtc(4), - eventtimers(4), hpet(4), - timecounters(4)

-
-
- - - - - -
May 26, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/audit.4 3.html b/static/freebsd/man4/audit.4 3.html deleted file mode 100644 index 7ef98101..00000000 --- a/static/freebsd/man4/audit.4 3.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - -
AUDIT(4)Device Drivers ManualAUDIT(4)
-
-
-

-

audit — Security - Event Audit

-
-
-

-

options AUDIT

-
-
-

-

Security Event Audit is a facility to provide fine-grained, - configurable logging of security-relevant events, and is intended to meet - the requirements of the Common Criteria (CC) Common Access Protection - Profile (CAPP) evaluation. The FreeBSD - audit facility implements the de facto industry - standard BSM API, file formats, and command line interface, first found in - the Solaris operating system. Information on the user space implementation - can be found in libbsm(3).

-

Audit support is enabled at boot, if present in the kernel, using - an rc.conf(5) flag. The audit daemon, - auditd(8), is responsible for configuring the kernel to - perform audit, pushing configuration data from the - various audit configuration files into the kernel.

-
-

-

The kernel audit facility provides a - special device, /dev/audit, which is used by - auditd(8) to monitor for audit - events, such as requests to cycle the log, low disk space conditions, and - requests to terminate auditing. This device is not intended for use by - applications.

-
-
-

-

Audit pipe special devices, discussed in - auditpipe(4), provide a configurable live tracking - mechanism to allow applications to tee the audit trail, as well as to - configure custom preselection parameters to track users and events in a - fine-grained manner.

-
-
-

-

The DTrace Audit Provider, dtaudit(4), allows D - scripts to enable capture of in-kernel audit records for kernel audit event - types, and then process their contents during audit commit or BSM - generation.

-
-
-
-

-

auditreduce(1), praudit(1), - audit(2), auditctl(2), - auditon(2), getaudit(2), - getauid(2), poll(2), - select(2), setaudit(2), - setauid(2), libbsm(3), - auditpipe(4), dtaudit(4), - audit.log(5), audit_class(5), - audit_control(5), audit_event(5), - audit_user(5), audit_warn(5), - rc.conf(5), audit(8), - auditd(8), auditdistd(8)

-
-
-

-

The OpenBSM implementation was created by McAfee Research, the - security division of McAfee Inc., under contract to Apple Computer Inc. in - 2004. It was subsequently adopted by the TrustedBSD Project as the - foundation for the OpenBSM distribution.

-

Support for kernel audit first appeared in - FreeBSD 6.2.

-
-
-

-

This software was created by McAfee Research, the security - research division of McAfee, Inc., under contract to Apple Computer Inc. - Additional authors include Wayne Salamon, - Robert Watson, and SPARTA Inc.

-

The Basic Security Module (BSM) interface to audit records and - audit event stream format were defined by Sun Microsystems.

-

This manual page was written by Robert - Watson - <rwatson@FreeBSD.org>.

-
-
-

-

The FreeBSD kernel does not fully validate - that audit records submitted by user applications are syntactically valid - BSM; as submission of records is limited to privileged processes, this is - not a critical bug.

-

Instrumentation of auditable events in the kernel is not complete, - as some system calls do not generate audit records, or generate audit - records with incomplete argument information.

-

Mandatory Access Control (MAC) labels, as provided by the - mac(4) facility, are not audited as part of records - involving MAC decisions.

-

Currently the audit syscalls are not - supported for jailed processes. However, if a process has - audit session state associated with it, audit - records will still be produced and a zonename token containing the jail's ID - or name will be present in the audit records.

-
-
- - - - - -
April 28, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/auditpipe.4 3.html b/static/freebsd/man4/auditpipe.4 3.html deleted file mode 100644 index b388b82c..00000000 --- a/static/freebsd/man4/auditpipe.4 3.html +++ /dev/null @@ -1,219 +0,0 @@ - - - - - - -
AUDITPIPE(4)Device Drivers ManualAUDITPIPE(4)
-
-
-

-

auditpipe — - pseudo-device for live audit event tracking

-
-
-

-

options AUDIT

-
-
-

-

While audit trail files generated with audit(4) - and maintained by auditd(8) provide a reliable long-term - store for audit log information, current log files are owned by the audit - daemon until terminated making them somewhat unwieldy for live monitoring - applications such as host-based intrusion detection. For example, the log - may be cycled and new records written to a new file without notice to - applications that may be accessing the file.

-

The audit facility provides an audit pipe facility for - applications requiring direct access to live BSM audit data for the purposes - of real-time monitoring. Audit pipes are available via a clonable special - device, /dev/auditpipe, subject to the permissions - on the device node, and provide a "tee" of the audit event stream. - As the device is clonable, more than one instance of the device may be - opened at a time; each device instance will provide independent access to - all records.

-

The audit pipe device provides discrete BSM audit records; if the - read buffer passed by the application is too small to hold the next record - in the sequence, it will be dropped. Unlike audit data written to the audit - trail, the reliability of record delivery is not guaranteed. In particular, - when an audit pipe queue fills, records will be dropped. Audit pipe devices - are blocking by default, but support non-blocking I/O, asynchronous I/O - using SIGIO, and polled operation via - select(2) and poll(2).

-

Applications may choose to track the global audit trail, or - configure local preselection parameters independent of the global audit - trail parameters.

-
-

-

The following ioctls retrieve and set various audit pipe record - queue properties:

-
-
-
Query the current number of records available for reading on the - pipe.
-
-
Retrieve the current maximum number of records that may be queued for - reading on the pipe.
-
-
Set the current maximum number of records that may be queued for reading - on the pipe. The new limit must fall between the queue limit minimum and - queue limit maximum queryable using the following two ioctls.
-
-
Query the lowest possible maximum number of records that may be queued for - reading on the pipe.
-
-
Query the highest possible maximum number of records that may be queued - for reading on the pipe.
-
-
Flush all outstanding records on the audit pipe; useful after setting - initial preselection properties to delete records queued during the - configuration process which may not match the interests of the user - process.
-
-
Query the maximum size of an audit record, which is a useful minimum size - for a user space buffer intended to hold audit records read from the audit - pipe.
-
-
-
-

-

By default, the audit pipe facility configures pipes to present - records matched by the system-wide audit trail, configured by - auditd(8). However, the preselection mechanism for audit - pipes can be configured using alternative criteria, including pipe-local - flags and naflags settings, as well as auid-specific selection masks. This - allows applications to track events not captured in the global audit trail, - as well as limit records presented to those of specific interest to the - application.

-

The following ioctls configure the preselection mode on an audit - pipe:

-
-
-
Return the current preselect mode on the audit pipe. The ioctl argument - should be of type int.
-
-
Set the current preselection mode on the audit pipe. The ioctl argument - should be of type int.
-
-

Possible preselection mode values are:

-
-
-
Use the global audit trail preselection parameters to select records for - the audit pipe.
-
-
Use local audit pipe preselection; this model is similar to the global - audit trail configuration model, consisting of global flags and naflags - parameters, as well as a set of per-auid masks. These parameters are - configured using further ioctls.
-
-

After changing the audit pipe preselection mode, records selected - under earlier preselection configuration may still be in the audit pipe - queue. The application may flush the current record queue after changing the - configuration to remove possibly undesired records.

-
-
-

-

The following ioctls configure the preselection parameters used - when an audit pipe is configured for the - AUDITPIPE_PRESELECT_MODE_LOCAL preselection - mode.

-
-
-
Retrieve the current default preselection flags for attributable events on - the pipe. These flags correspond to the flags field - in audit_control(5). The ioctl argument should be of - type au_mask_t.
-
-
Set the current default preselection flags for attributable events on the - pipe. These flags correspond to the flags field in - audit_control(5). The ioctl argument should be of type - au_mask_t.
-
-
Retrieve the current default preselection flags for non-attributable - events on the pipe. These flags correspond to the - naflags field in audit_control(5). - The ioctl argument should be of type au_mask_t.
-
-
Set the current default preselection flags for non-attributable events on - the pipe. These flags correspond to the naflags - field in audit_control(5). The ioctl argument should be - of type au_mask_t.
-
-
Query the current preselection masks for a specific auid on the pipe. The - ioctl argument should be of type struct - auditpipe_ioctl_preselect. The auid to query is specified via the - ap_auid field of type au_id_t; - the mask will be returned via ap_mask of type - au_mask_t.
-
-
Set the current preselection masks for a specific auid on the pipe. - Arguments are identical to - AUDITPIPE_GET_PRESELECT_AUID, except that the - caller should properly initialize the ap_mask field - to hold the desired preselection mask.
-
-
Delete the current preselection mask for a specific auid on the pipe. Once - called, events associated with the specified auid will use the default - flags mask. The ioctl argument should be of type - au_id_t.
-
-
Delete all auid specific preselection specifications.
-
-
-
-
-

-

The praudit(1) utility may be directly executed - on /dev/auditpipe to review the default audit - trail.

-
-
-

-

poll(2), select(2), - audit(4), dtaudit(4), - audit_control(5), audit(8), - auditd(8)

-
-
-

-

The OpenBSM implementation was created by McAfee Research, the - security division of McAfee Inc., under contract to Apple Computer Inc. in - 2004. It was subsequently adopted by the TrustedBSD Project as the - foundation for the OpenBSM distribution.

-

Support for kernel audit first appeared in - FreeBSD 6.2.

-
-
-

-

The audit pipe facility was designed and implemented by - Robert Watson - <rwatson@FreeBSD.org>.

-

The Basic Security Module (BSM) interface to audit records and - audit event stream format were defined by Sun Microsystems.

-
-
-

-

See the audit(4) manual page for information on - audit-related bugs and limitations.

-

The configurable preselection mechanism mirrors the selection - model present for the global audit trail. It might be desirable to provide a - more flexible selection model.

-

The per-pipe audit event queue is fifo, with drops occurring if - either the user thread provides in sufficient for the record on the queue - head, or on enqueue if there is insufficient room. It might be desirable to - support partial reads of records, which would be more compatible with - buffered I/O as implemented in system libraries, and to allow applications - to select which records are dropped, possibly in the style of - preselection.

-
-
- - - - - -
April 28, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/aue.4 3.html b/static/freebsd/man4/aue.4 3.html deleted file mode 100644 index b8d46074..00000000 --- a/static/freebsd/man4/aue.4 3.html +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - -
AUE(4)Device Drivers ManualAUE(4)
-
-
-

-

aue — ADMtek AN986 - Pegasus USB Fast Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device aue
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_aue_load="YES"
-
-
-
-

-

The aue driver provides support for USB - Fast Ethernet adapters based on the ADMtek AN986 Pegasus chipset.

-

The LinkSys USB10T adapters that contain the AN986 Pegasus chipset - will operate at 100Base-TX and full-duplex.

-

The Pegasus contains a 10/100 Ethernet MAC with MII interface and - is designed to work with both Ethernet and HomePNA transceivers. Although - designed to interface with 100Mbps peripherals, the existing USB standard - specifies a maximum transfer speed of 12Mbps. Users should therefore not - expect to actually achieve 100Mbps speeds with these devices.

-

The Pegasus supports a 64-bit multicast hash table, single perfect - filter entry for the station address and promiscuous mode. Packets are - received and transmitted over separate USB bulk transfer endpoints.

-

The aue driver supports the following - media types:

-
-
autoselect
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file.
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to enable full-duplex operation. Not - specifying full duplex implies - half-duplex mode.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to enable full-duplex - operation. Not specifying full duplex implies - half-duplex mode.
-
-

The aue driver supports the following - media options:

-
-
full-duplex
-
Force full duplex operation. The interface will operate in half duplex - mode if this media option is not specified.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The aue driver supports the following USB - Fast Ethernet adapters based on the ADMtek AN986 Pegasus chipset:

-

-
    -
  • Abocom UFE1000, DSB650TX_NA
    • -
  • Accton USB320-EC, SpeedStream
    • -
  • ADMtek AN986, AN8511
    • -
  • Billionton USB100, USB100LP, USB100EL, USBE100
    • -
  • Corega Ether FEther USB-T, FEther USB-TX, FEther USB-TXS
    • -
  • D-Link DSB-650, DSB-650TX, DSB-650TX-PNA
    • -
  • Elecom LD-USBL/TX
    • -
  • Elsa Microlink USB2Ethernet
    • -
  • HP hn210e
    • -
  • I-O Data USB ETTX
    • -
  • Kingston KNU101TX
    • -
  • LinkSys USB10T adapters that contain the AN986 Pegasus chipset, USB10TA, - USB10TX, USB100TX, USB100H1
    • -
  • MELCO LUA-TX, LUA2-TX
    • -
  • Netgear FA101
    • -
  • Planex UE-200TX
    • -
  • Sandberg USB to Network Link (model number 133-06)
    • -
  • Siemens Speedstream
    • -
  • SmartBridges smartNIC
    • -
  • SMC 2202USB
    • -
  • SOHOware NUB100
    • -
-
-
-

-
-
aue%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
aue%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), ifconfig(8)

-

ADMtek AN986 data sheet, - http://www.admtek.com.tw.

-
-
-

-

The aue device driver first appeared in - FreeBSD 4.0.

-
-
-

-

The aue driver was written by - Bill Paul - <wpaul@ee.columbia.edu>.

-
-
- - - - - -
May 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/autofs.4 3.html b/static/freebsd/man4/autofs.4 3.html deleted file mode 100644 index 9f3ddbb1..00000000 --- a/static/freebsd/man4/autofs.4 3.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - -
AUTOFS(4)Device Drivers ManualAUTOFS(4)
-
-
-

-

autofs — - automounter filesystem

-
-
-

-

To compile this driver into the kernel, place the following line - in the kernel configuration file:

-
options AUTOFS
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
autofs_load="YES"
-
-
-
-

-

The autofs driver is the kernel component - of the automounter infrastructure. Its job is to pass mount requests to the - automountd(8) daemon, and pause the processes trying to - access the automounted filesystem until the mount is completed. It is - mounted by the automount(8).

-
-
-

-

These options are available when mounting - autofs file systems:

-
-
-
Mount options for all filesystems specified in the map entry.
-
-
Filesystem mountpoint prefix.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
vfs.autofs.debug
-
Verbosity level for log messages from the autofs - driver. Set to 0 to disable logging or 1 to warn about potential problems. - Larger values enable debugging output. Defaults to 1.
-
vfs.autofs.interruptible
-
Set to 1 to allow mount requests to be interrupted by signal. Defaults to - 1.
-
vfs.autofs.retry_delay
-
Number of seconds before retrying mount requests. Defaults to 1.
-
vfs.autofs.retry_attempts
-
Number of attempts before failing mount. Defaults to 3.
-
vfs.autofs.cache
-
Number of seconds to wait before reinvoking - automountd(8) for any given file or directory. Defaults - to 600.
-
vfs.autofs.timeout
-
Number of seconds to wait for automountd(8) to handle - the mount request. Defaults to 30.
-
vfs.autofs.mount_on_stat
-
Set to 1 to trigger mount on stat(2) on mountpoint. - Defaults to 0.
-
-
-
-

-

To unmount all mounted autofs - filesystems:

-

-
umount -At autofs
-

To mount autofs filesystems specified in - auto_master(5):

-

-
automount
-
-
-

-

auto_master(5), automount(8), - automountd(8), autounmountd(8)

-
-
-

-

The autofs driver first appeared in - FreeBSD 10.1.

-
-
-

-

The autofs was developed by - Edward Tomasz Napierala - <trasz@FreeBSD.org> - under sponsorship from the FreeBSD Foundation.

-
-
- - - - - -
December 2, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/aw_gpio.4 4.html b/static/freebsd/man4/aw_gpio.4 4.html deleted file mode 100644 index 777a689e..00000000 --- a/static/freebsd/man4/aw_gpio.4 4.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - -
AW_GPIO(4)Device Drivers ManualAW_GPIO(4)
-
-
-

-

aw_gpio — driver - for the GPIO and pin muxing functionalities on Allwinner SoC

-
-
-

-

device gpio -
- options SOC_ALLWINNER_A10 -
- options SOC_ALLWINNER_A13 -
- options SOC_ALLWINNER_A20 -
- options SOC_ALLWINNER_A31 -
- options SOC_ALLWINNER_A31S -
- options SOC_ALLWINNER_A33 -
- options SOC_ALLWINNER_A83T -
- options SOC_ALLWINNER_H2PLUS -
- options SOC_ALLWINNER_H3 -
- options SOC_ALLWINNER_A64 -
- options SOC_ALLWINNER_H5 -
- options SOC_ALLWINNER_D1

-
-
-

-

The aw_gpio device driver provides support - for the Allwinner pin muxing and GPIO on Allwinner SoCs.

-
-
-

-

The current version of the aw_gpio driver - supports the GPIO/pinmuxing controller with one of the following compatible - strings :

-

-
    -
  • allwinner,sun4i-a10-pinctrl
    • -
  • allwinner,sun5i-a13-pinctrl
    • -
  • allwinner,sun7i-a20-pinctrl
    • -
  • allwinner,sun6i-a31-pinctrl
    • -
  • allwinner,sun6i-a31s-pinctrl
    • -
  • allwinner,sun6i-a31-r-pinctrl
    • -
  • allwinner,sun6i-a33-pinctrl
    • -
  • allwinner,sun8i-a83t-pinctrl
    • -
  • allwinner,sun8i-a83t-r-pinctrl
    • -
  • allwinner,sun8i-h3-pinctrl
    • -
  • allwinner,sun50i-h5-pinctrl
    • -
  • allwinner,sun8i-h3-r-pinctrl
    • -
  • allwinner,sun50i-a64-pinctrl
    • -
  • allwinner,sun50i-a64-r-pinctrl
    • -
  • allwinner,sun20i-d1-pinctrl
    • -
-
-
-

-

fdt(4), gpio(4)

-
-
-

-

The aw_gpio device driver first appeared - in FreeBSD 10.0.

-
-
-

-

The aw_gpio device driver was originally - written by Ganbold Tsagaankhuu - <ganbold@freebsd.org>. - This manual page was written by -
- Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
October 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/aw_mmc.4 4.html b/static/freebsd/man4/aw_mmc.4 4.html deleted file mode 100644 index c9588701..00000000 --- a/static/freebsd/man4/aw_mmc.4 4.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
AW_MMC(4)Device Drivers ManualAW_MMC(4)
-
-
-

-

aw_mmc — driver - for the SD/MMC controller in Allwinner SoC

-
-
-

-

device mmc

-
-
-

-

The aw_mmc device driver provides support - for the Allwinner SD/MMC host controller.

-
-
-

-

The current version of the aw_mmc driver - supports the SD/MMC controller with one of the following compatible strings - :

-

-
    -
  • allwinner,sun4i-a10-mmc
    • -
  • allwinner,sun5i-a13-mmc
    • -
  • allwinner,sun7i-a20-mmc
    • -
  • allwinner,sun50i-a64-mmc
    • -
  • allwinner,sun20i-d1-mmc
    • -
-
-
-

-

The following read-only variables are available via - sysctl(8):

-
-
dev.aw_mmc.req_timeout
-
Request timeout in seconds (default: 10) .
-
-
-
-

-

fdt(4), mmc(4)

-
-
-

-

The aw_mmc device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The aw_mmc device driver was originally - written by Alexander Fedorov - <alexander.fedorov@rtlservice.com>. - Later work and this manual page was done by -
- Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
October 20, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/aw_rtc.4 4.html b/static/freebsd/man4/aw_rtc.4 4.html deleted file mode 100644 index 976a09a6..00000000 --- a/static/freebsd/man4/aw_rtc.4 4.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - -
AW_RTC(4)Device Drivers ManualAW_RTC(4)
-
-
-

-

aw_rtc — driver - for the real-time clock (RTC) controller in Allwinner SoC

-
-
-

-

The aw_rtc device driver provides support - for the Allwinner RTC controller.

-
-
-

-

The current version of the aw_rtc driver - supports the RTC controller with any of the following compatible - strings:

-

-
    -
  • allwinner,sun4i-a10-rtc
    • -
  • allwinner,sun7i-a20-rtc
    • -
  • allwinner,sun6i-a31-rtc
    • -
  • allwinner,sun8i-h3-rtc
    • -
  • allwinner,sun20i-d1-rtc
    • -
  • allwinner,sun50i-h5-rtc
    • -
  • allwinner,sun50i-h6-rtc
    • -
-
-
-

-

The aw_rtc device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The aw_rtc device driver was written by - Vladimir Belian - <fate10@gmail.com>. - This manual page was written by -
- Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
December 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/aw_sid.4 4.html b/static/freebsd/man4/aw_sid.4 4.html deleted file mode 100644 index 930e1b7f..00000000 --- a/static/freebsd/man4/aw_sid.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
AW_SID(4)Device Drivers ManualAW_SID(4)
-
-
-

-

aw_sid — driver - for the SID controller in Allwinner SoC

-
-
-

-

The aw_sid device driver provides support - for the Allwinner SID (Security ID) controller. This controller provides - root security keys that may be used as either a device unique ID or to - generate a MAC address.

-
-
-

-

The aw_sid driver supports the SID - controller with one of the following compatible strings:

-

-
    -
  • allwinner,sun4i-a10-sid
    • -
  • allwinner,sun7i-a20-sid
    • -
  • allwinner,sun50i-a64-sid
    • -
  • allwinner,sun8i-a83t-sid
    • -
  • allwinner,sun8i-h3-sid
    • -
  • allwinner,sun50i-h5-sid
    • -
  • allwinner,sun20i-d1-sid
    • -
-
-
-

-

The following read-only variables are available via - sysctl(8):

-
-
dev.aw_sid.rootkey
-
Root security key for this device.
-
-
-
-

-

The aw_sid device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The aw_sid device driver was written by - Jared McNeill - <jmcneill@invisible.ca>. - This manual page was written by -
- Kyle Evans - <kevans@FreeBSD.org>.

-
-
- - - - - -
October 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/aw_spi.4 4.html b/static/freebsd/man4/aw_spi.4 4.html deleted file mode 100644 index 29f61bc1..00000000 --- a/static/freebsd/man4/aw_spi.4 4.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
AW_SPI(4)Device Drivers ManualAW_SPI(4)
-
-
-

-

aw_spi — driver - for the SPI controller in Allwinner SoC

-
-
-

-

device aw_spi

-
-
-

-

The aw_spi device driver provides support - for the Allwinner SPI host controller.

-
-
-

-

The current version of the aw_spi driver - supports the SPI controller with one of the following compatible - strings:

-

-
    -
  • allwinner,sun8i-h3-spi
    • -
-
-
-

-

The aw_spi device driver first appeared in - FreeBSD 12.0.

-
-
-

-

The aw_spi device driver was written by - Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
May 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/aw_syscon.4 4.html b/static/freebsd/man4/aw_syscon.4 4.html deleted file mode 100644 index 67b8c2c1..00000000 --- a/static/freebsd/man4/aw_syscon.4 4.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
AW_SYSCON(4)Device Drivers ManualAW_SYSCON(4)
-
-
-

-

aw_syscon — driver - for the system controller in Allwinner SoC

-
-
-

-

The aw_syscon device driver provides - support for the Allwinner system controller. This controller provides - registers for tying together related functionality in a common space. - aw_syscon is required for ethernet functionality on - supported devices.

-
-
-

-

The aw_syscon driver supports the system - controller with one of the following compatible strings:

-

-
    -
  • allwinner,sun50i-a64-system-controller
    • -
  • allwinner,sun50i-a64-system-control
    • -
  • allwinner,sun8i-a83t-system-controller
    • -
  • allwinner,sun8i-h3-system-controller
    • -
  • allwinner,sun8i-h3-system-control
    • -
  • allwinner,sun50i-h5-system-control
    • -
  • allwinner,sun20i-d1-system-control
    • -
-
-
-

-

The aw_syscon device driver was written by - Kyle Evans - <kevans@FreeBSD.org>.

-
-
- - - - - -
November 11, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/axe.4 3.html b/static/freebsd/man4/axe.4 3.html deleted file mode 100644 index f38890de..00000000 --- a/static/freebsd/man4/axe.4 3.html +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - -
AXE(4)Device Drivers ManualAXE(4)
-
-
-

-

axe — ASIX - Electronics AX88x7x/760 USB Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device axe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_axe_load="YES"
-
-
-
-

-

The axe driver provides support for USB - Ethernet adapters based on the ASIX Electronics AX88172, AX88178, AX88772, - AX88772A, AX88772B and AX88760 USB 2.0 chipsets.

-

The AX88172, AX88772, AX88772A, AX88772B and AX88760 contain a - 10/100 Ethernet MAC with MII interface and are designed to work with both - Ethernet and HomePNA transceivers. The AX88178 has a 10/100/1000 Ethernet - MAC with GMII/RGMII interface for interfacing with Gigabit Ethernet PHY.

-

These devices will operate with both USB 1.x and USB 2.0 - controllers, however performance with 1.x controllers will be limited since - the USB 1.x standard specifies a maximum transfer speed of 12Mbps. Users - with USB 1.x controllers should therefore not expect to actually achieve - 100Mbps speeds with these devices.

-

All chipsets support a 64-bit multicast hash table, single perfect - filter entry for the station address, all-multicast mode and promiscuous - mode. Packets are received and transmitted over separate USB bulk transfer - endpoints.

-

The axe driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000Mbps (Gigabit Ethernet) operation (AX88178 only). The - ifconfig(8) mediaopt option can - also be used to select either full-duplex or - half-duplex modes.
-
-

The axe driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The axe driver supports ASIX Electronics - AX88172/AX88178/AX88772/AX88772A/AX88772B/AX88760 based USB Ethernet - adapters including:

-

AX88172:

-
    -
  • AboCom UF200
    • -
  • Acer Communications EP1427X2
    • -
  • ASIX AX88172
    • -
  • ATen UC210T
    • -
  • Billionton SnapPort
    • -
  • Billionton USB2AR
    • -
  • Buffalo (Melco Inc.) LUA-U2-KTX
    • -
  • Corega USB2_TX
    • -
  • D-Link DUBE100
    • -
  • Goodway GWUSB2E
    • -
  • JVC MP_PRX1
    • -
  • LinkSys USB200M
    • -
  • Netgear FA120
    • -
  • Sitecom LN-029
    • -
  • System TALKS Inc. SGC-X2UL
    • -
-

AX88178:

-
    -
  • ASIX AX88178
    • -
  • Belkin F5D5055
    • -
  • Logitec LAN-GTJ/U2A
    • -
  • Buffalo (Melco Inc.) LUA3-U2-AGT
    • -
  • Planex Communications GU1000T
    • -
  • Sitecom Europe LN-028
    • -
-

AX88772:

-
    -
  • ASIX AX88772
    • -
  • Buffalo (Melco Inc.) LUA3-U2-ATX
    • -
  • D-Link DUBE100B1
    • -
  • Planex UE-200TX-G
    • -
  • Planex UE-200TX-G2
    • -
-

AX88772A:

-
    -
  • ASIX AX88772A
    • -
  • Cisco-Linksys USB200Mv2
    • -
-

AX88772B:

-
    -
  • ASIX AX88772B
    • -
  • Lenovo USB 2.0 Ethernet
    • -
-

AX88760:

-
    -
  • ASIX AX88760
    • -
-
-
-

-
-
axe%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
axe%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), rgephy(4), - vlan(4), ifconfig(8)

-

ASIX AX88x7x and AX88760 data - sheets, - http://www.asix.com.tw.

-
-
-

-

The axe device driver first appeared in - FreeBSD 5.0.

-
-
-

-

The axe driver was written by - Bill Paul - <wpaul@windriver.com>.

-
-
- - - - - -
November 24, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/axge.4 3.html b/static/freebsd/man4/axge.4 3.html deleted file mode 100644 index 86efead8..00000000 --- a/static/freebsd/man4/axge.4 3.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - -
AXGE(4)Device Drivers ManualAXGE(4)
-
-
-

-

axge — ASIX - Electronics AX88178A/179/179A USB Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device xhci -
-device ehci -
-device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device axge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_axge_load="YES"
-
-
-
-

-

The axge driver provides support for USB - Gigabit Ethernet adapters based on the ASIX Electronics AX88179/AX88179A USB - 3.0 and AX88178A USB 2.0 chipsets.

-

The AX88179, AX88179A and AX88178A contain a 10/100/1000 Ethernet - MAC with a GMII interface for interfacing with the Gigabit Ethernet PHY.

-

These devices will operate with both USB 1.x and USB 2.0 - controllers, and the AX88179/AX88179A will operate with USB 3.0 controllers. - Packets are received and transmitted over separate USB bulk transfer - endpoints.

-

The axge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000Mbps (Gigabit Ethernet) operation (AX88178 only). The - ifconfig(8) mediaopt option can - also be used to select either full-duplex or - half-duplex modes.
-
-

The axge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The axge driver supports the following USB - Gigabit Ethernet controllers:

-

-
    -
  • ASIX Electronics AX88179A
    • -
  • ASIX Electronics AX88179
    • -
  • ASIX Electronics AX88178A
    • -
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), rgephy(4), - vlan(4), ifconfig(8)

-
-
-

-

The axge device driver first appeared in - FreeBSD 10.1.

-
-
-

-

The axge driver was written by - Kevin Lo - <kevlo@FreeBSD.org> - and Li-Wen Hsu - <lwhsu@FreeBSD.org>. - This manual page was adapted by Mark Johnston - <markj@FreeBSD.org> - from the axe(4) manual page.

-
-
- - - - - -
May 25, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/axp.4 3.html b/static/freebsd/man4/axp.4 3.html deleted file mode 100644 index a8a099d0..00000000 --- a/static/freebsd/man4/axp.4 3.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - -
AXP(4)Device Drivers ManualAXP(4)
-
-
-

-

axp — Advanced - Micro Devices 10G Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device axp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_axp_load="YES"
-
-
-
-

-

The axp driver enables PCI-E based 10G - Ethernet controller inbuilt in the AMD EPYC processors.

-

The following features are supported.

-

-
    -
  • 1G/10G SFP+ Link
    • -
  • Jumbo frames (9000 Bytes)
    • -
  • Transmit and Receive checksum offload
    • -
  • TCP segmentation offload (TSO)
    • -
  • VLAN tag insertion/extraction
    • -
  • VLAN checksum offload
    • -
  • VLAN TSO
    • -
  • Receive side steering (RSS)
    • -
  • IPV4 and IPV6 capable
    • -
  • MSI-X interrupts
    • -
  • Split header
    • -
-

All the above mentioned features are enabled by default.

-

For hardware related questions, please refer the documentation - supplied along with AMD EPYC processors.

-
-
-

-

The following variables are available as - sysctl(8) variables:

-
-
dev.ax.X.mac_stats
-
Dumps the transmit and receive statistics counter values for the - controller. This includes statistics specific to each transmit and receive - queue.
-
dev.ax.X.channels_info
-
Dumps the permissible and default configured transmit and receive channel - information.
-
dev.ax.X.ringparam_info
-
Dumps the permissible and default configured descriptor information for - the transmit and receive queue.
- -
Dumps the current link setting like link mode, speed, duplex - settings.
-
dev.ax.X.pauseparam_info
-
Dumps the current flow-control settings.
-
dev.ax.X.coalesce_info
-
Dumps the current interrupt coalescing settings.
- -
Dumps the current state of the Link.
-
dev.ax.X.drv_info
-
Dumps the driver and controller firmware version information.
-
dev.ax.X.YYYY_register
-
 
-
dev.ax.X.YYYY_register_values
-
Sysctl to dump a specific register from a specific block of the - controller. YYYY specifies the block. The following blocks are supported. -
    -
  • xpcs
    • -
  • xgmac
    • -
  • xprop
    • -
  • xi2c
    • -
-

Set the offset of the register to the first variable, and then - read the value of the register by reading the second variable.

-
-
dev.ax.X.axgbe_debug_level
-
Configure the log-level for the driver. Default is 0. Supports 0-3.
- -
This variable enables the workaround for an intermittent link issue. When - link does not come up for long time, this variable can be set to 1 to - reset the phy and bring up the link.
-
-
-
-

-

The following variable is available as - loader.conf(5) tunable.

-
-
dev.ax.X.sph_enable
-
This variable controls split header feature for the interface. Default is - 1, meaning the split header support is enabled. -

This variable must be set before loading the driver, either - via loader.conf(5) or through - kenv(1). This cannot be modified when driver is - loaded.

-

Setting this variable in loader.conf(5) - needs the system to be restarted to take effect. When using - kenv(1), use the wrapper variable - dev.ax.sph_enable, which will - configure(enable/disable) split header support for all - axp interfaces.

-

To use netmap with this device, split header support must be - disabled (set this variable to 0).

-
-
-
-
-

-

arp(4), iflib(4), - netmap(4), vlan(4), - ifconfig(8)

-
-
-

-

The axp device driver first appeared in - FreeBSD 13.0.

-

Another version of the driver is already present in - FreeBSD. This driver was named as "axgbe" - earlier, which is renamed as "axa" now. This driver is for the - ACPI based Ethernet controllers in the previous/older version of the - hardware. This driver is authored by - <andrew@FreeBSD.org>.

-
-
-

-

The axp device driver was written by - Advanced Micro Devices Inc.

-

For any issues and support requirements, email the details to - <rajesh1.kumar@amd.com>.

-
-
- - - - - -
February 19, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/bce.4 3.html b/static/freebsd/man4/bce.4 3.html deleted file mode 100644 index 697ab5ab..00000000 --- a/static/freebsd/man4/bce.4 3.html +++ /dev/null @@ -1,364 +0,0 @@ - - - - - - -
BCE(4)Device Drivers ManualBCE(4)
-
-
-

-

bce — QLogic - NetXtreme II (BCM5706/5708/5709/5716) PCI/PCIe Gigabit Ethernet adapter - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device bce
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_bce_load="YES"
-
-
-
-

-

The bce driver supports QLogic's NetXtreme - II product family, including the BCM5706, BCM5708, BCM5709 and BCM5716 - Ethernet controllers.

-

The NetXtreme II product family is composed of various Converged - NIC (or CNIC) Ethernet controllers which support a TCP Offload Engine (TOE), - Remote DMA (RDMA), and iSCSI acceleration, in addition to standard L2 - Ethernet traffic, all on the same controller.

-

The following features are supported in the - bce driver under - FreeBSD:

-

-
    -
  • IP/TCP/UDP checksum offload
    • -
  • Jumbo frames (up to 9022 bytes)
    • -
  • VLAN tag stripping
    • -
  • Interrupt coalescing
    • -
  • 10/100/1000Mbps operation in full-duplex mode
    • -
  • 10/100Mbps operation in half-duplex mode
    • -
-

The bce driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Sets 1000Mbps operation. Only full-duplex mode is - supported at this speed.
-
-
Set 1000baseT operation over twisted pair. Only - full-duplex mode is supported.
-
-
Set 2500Mbps operation. Only full-duplex mode is - supported.
-
-

The bce driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The bce driver provides support for - various NICs based on the QLogic NetXtreme II family of Gigabit Ethernet - controllers, including the following:

-

-
    -
  • QLogic NetXtreme II BCM5706 1000Base-SX
    • -
  • QLogic NetXtreme II BCM5706 1000Base-T
    • -
  • QLogic NetXtreme II BCM5708 1000Base-SX
    • -
  • QLogic NetXtreme II BCM5708 1000Base-T
    • -
  • QLogic NetXtreme II BCM5709 1000Base-SX
    • -
  • QLogic NetXtreme II BCM5709 1000Base-T
    • -
  • QLogic NetXtreme II BCM5716 1000Base-T
    • -
  • Dell PowerEdge 1950 integrated BCM5708 NIC
    • -
  • Dell PowerEdge 2950 integrated BCM5708 NIC
    • -
  • Dell PowerEdge R710 integrated BCM5709 NIC
    • -
  • HP NC370F Multifunction Gigabit Server Adapter
    • -
  • HP NC370T Multifunction Gigabit Server Adapter
    • -
  • HP NC370i Multifunction Gigabit Server Adapter
    • -
  • HP NC371i Multifunction Gigabit Server Adapter
    • -
  • HP NC373F PCIe Multifunc Giga Server Adapter
    • -
  • HP NC373T PCIe Multifunction Gig Server Adapter
    • -
  • HP NC373i Multifunction Gigabit Server Adapter
    • -
  • HP NC373m Multifunction Gigabit Server Adapter
    • -
  • HP NC374m PCIe Multifunction Adapter
    • -
  • HP NC380T PCIe DP Multifunc Gig Server Adapter
    • -
  • HP NC382T PCIe DP Multifunction Gigabit Server Adapter
    • -
  • HP NC382i DP Multifunction Gigabit Server Adapter
    • -
  • HP NC382m DP 1GbE Multifunction BL-c Adapter
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.bce.verbose
-
Enable/Disable verbose logging and output to the console. Useful for - debugging (default 0).
-
hw.bce.msi_enable
-
Enable/Disable MSI support (default 1).
-
hw.bce.tso_enable
-
Enable/Disable TSO support (default 1).
-
hw.bce.strict_rx_mtu
-
Enable/Disable strict RX frame size checking (default 0).
-
hw.bce.hdr_split
-
Enable/Disable frame header/payload splitting (default 1).
-
hw.bce.rx_pages
-
Set the number of memory pages assigned to receive packets by the driver. - Due to alignment issues, this value can only be of the set 1, 2, 4 or 8 - (default 2).
-
hw.bce.tx_pages
-
Set the number of memory pages assigned to transmit packets by the driver. - Due to alignment issues, this value can only be of the set 1, 2, 4 or 8 - (default 2).
-
hw.bce.rx_ticks
-
Time in microsecond ticks to wait before generating a status block updates - due to RX processing activity. Values from 0-100 are valid. A value of 0 - disables this status block update. Cannot be set to 0 if - hw.bce.rx_quick_cons_trip is also 0 (default 18).
-
hw.bce.rx_ticks_int
-
Time in microsecond ticks to wait during RX interrupt processing before - generating a status block update. Values from 0-100 are valid. Valid - values are in the range from 0-100. A value of 0 disables this status - block update (default 18).
-
hw.bce.rx_quick_cons_trip
-
Number of RX Quick BD Chain entries that must be completed before a status - block is generated. Values from 0-256 are valid. A value of 0 disables - this status block update. Cannot be set to 0 if hw.bce.rx_ticks is also 0 - (default 6).
-
hw.bce.rx_quick_cons_trip_int
-
Number of RX quick BD entries that must be completed before a status block - is generated duing interrupt processing. Values from 0-256 are valid. A - value of 0 disables this status block update (default 6).
-
hw.bce.tx_ticks
-
Time in microsecond ticks to wait before a status block update is - generated due to TX activity. Values from 0-100 are valid. A value of 0 - disables this status block update. Cannot be set to 0 if - hw.bce.tx_quick_cons_trip is also 0 (default 80).
-
hw.bce.tx_ticks_int
-
Time in microsecond ticks to wait in interrupt processing before a status - block update is generated due to TX activity Values from 0-100 are valid. - A value of 0 disables this status block update (default 80).
-
hw.bce.tx_cons_trip
-
How many TX Quick BD Chain entries that must be completed before a status - block is generated. Values from 0-100 are valid. A value of 0 disables - this status block update. Cannot be set to 0 if hw.bce.tx_ticks is also 0 - (default 20).
-
hw.bce.tx_cons_trip_int
-
How many TX Quick BD Chain entries that must be completed before a status - block is generated during an interrupt. Values from 0-100 are valid. A - value of 0 disables this status block update (default 20).
-
-
-
-

-
-
bce%d: PCI memory allocation failed!
-
The driver has encountered a fatal initialization error.
-
bce%d: PCI map interrupt failed!
-
The driver has encountered a fatal initialization error.
-
bce%d: Unsupported controller revision (%c%d)
-
The driver does not support the controller revision in use.
-
bce%d: Controller initialization failed!
-
The driver has encountered a fatal initialization error.
-
bce%d: NVRAM test failed!
-
The driver could not access the controller NVRAM correctly.
-
bce%d: DMA resource allocation failed!
-
The driver could not allocate DMA memory to setup the controllers host - memory data structures.
-
bce%d: Interface allocation failed!
-
The driver could not create a network interface for the controller.
-
bce%d: PHY probe failed!
-
The driver could not access the PHY used by the controller.
-
bce%d: Failed to setup IRQ!
-
The driver could not initialize the IRQ handler.
-
bce%d: Error: PHY read timeout!
-
The driver could not read a PHY register before the timeout period - expired.
-
bce%d: PHY write timeout!
-
The driver could not write to the PHY register because a timeout - occurred.
-
bce%d: Timeout error reading NVRAM at offset 0x%08X!
-
The driver could not write to NVRAM because a timeout occurred.
-
bce%d: Unknown Flash NVRAM found!
-
The driver does not recognize the NVRAM device being used and therefore - cannot access it correctly.
-
bce%d: Invalid NVRAM magic value!
-
The driver cannot read NVRAM or the NVRAM is corrupt.
-
bce%d: Invalid Manufacturing Information NVRAM CRC!
-
The driver cannot read NVRAM or the NVRAM is corrupt.
-
bce%d: Invalid Feature Configuration Information NVRAM CRC!
-
The driver cannot read NVRAM or the NVRAM is corrupt.
-
bce%d: DMA mapping error!
-
The driver was unable to map memory into DMA addressable space required by - the controller.
-
bce%d: Could not allocate parent DMA tag!
-
The driver could not allocate a PCI compatible DMA tag.
-
bce%d: Could not allocate status block DMA tag!
-
The driver could not allocate a DMA tag for the controller's status - block.
-
bce%d: Could not allocate status block DMA memory!
-
The driver could not allocate DMA addressable memory for the controller's - status block.
-
bce%d: Could not map status block DMA memory!
-
The driver could not map the status block memory into the controller's DMA - address space.
-
bce%d: Could not allocate statistics block DMA tag!
-
The driver could not allocate a DMA tag for the controller's statistics - block.
-
bce%d: Could not allocate statistics block DMA memory!
-
The driver could not allocate DMA addressable memory for the controller's - statistics block.
-
bce%d: Could not map statistics block DMA memory!
-
The driver could not map the statistics block memory into the controller's - DMA address space.
-
bce%d: Could not allocate TX descriptor chain DMA tag!
-
The driver could not allocate a DMA tag for the controller's TX - chain.
-
bce%d: Could not allocate TX descriptor chain DMA memory!
-
The driver could not allocate DMA addressable memory for the controller's - TX chain.
-
bce%d: Could not map TX descriptor chain DMA memory!
-
The driver could not map the TX descriptor chain memory into the - controller's DMA address space.
-
bce%d: Could not allocate TX mbuf DMA tag!
-
The driver could not allocate a DMA tag for the controller's TX mbuf - memory.
-
bce%d: Unable to create TX mbuf DMA map!
-
The driver could not map the TX mbuf memory into the controller's DMA - address space.
-
bce%d: Could not allocate RX descriptor chain DMA tag!
-
The driver could not allocate a DMA tag for the controller's RX - chain.
-
bce%d: Could not allocate RX descriptor chain
-
The driver could not allocate DMA addressable memory for the controller's - RX chain.
-
bce%d: Could not map RX descriptor chain DMA memory!
-
The driver could not map the RX descriptor chain memory into the - controller's DMA address space.
-
bce%d: Could not allocate RX mbuf DMA tag!
-
The driver could not allocate a DMA tag for the controller's RX mbuf - memory.
-
bce%d: Unable to create RX mbuf DMA map!
-
The driver could not map the RX mbuf memory into the controller's DMA - address space.
-
bce%d: Firmware synchronization timeout!
-
The driver was not able to synchronize with the firmware running on the - controller. The firmware may be stopped or hung.
-
bce%d: Invalid Ethernet address!
-
The driver was not able to read a valid Ethernet MAC address from - NVRAM.
-
bce%d: Reset failed!
-
The driver has encountered a fatal initialization error.
-
bce%d: Byte swap is incorrect!
-
The driver has encountered a fatal initialization error. Contact the - author with details of the CPU architecture and system chipset in - use.
-
bce%d: Firmware did not complete initialization!
-
The driver has encountered a fatal initialization error.
-
bce%d: Bootcode not running!
-
The driver has encountered a fatal initialization error.
-
bce%d: Error mapping mbuf into RX chain!
-
The driver could not map a RX mbuf into DMA addressable memory.
-
bce%d: Error filling RX chain: rx_bd[0x%04X]!
-
The driver was unable to allocate enough mbufs to fill the RX chain during - initialization. Try increasing the number of mbufs available in the - system, increase system memory, or if using jumbo frames, make sure enough - 9KB mbufs are available.
-
bce%d: Failed to allocate new mbuf, incoming frame dropped!
-
The driver was unable to allocate a new mbuf for the RX chain and reused - the mbuf for the received frame, dropping the incoming frame in the - process. Try increasing the number of mbufs available in the system or - increase system memory.
-
bce%d: Controller reset failed!
-
A fatal initialization error has occurred.
-
bce%d: Controller initialization failed!
-
A fatal initialization error has occurred.
-
bce%d: Block initialization failed!
-
A fatal initialization error has occurred.
-
bce%d: Error mapping mbuf into TX chain!
-
The driver could not map a TX mbuf into DMA addressable memory.
-
bce%d: Error registering poll function!
-
The driver received an error while attempting to register the poll - function.
-
bce%d: Changing VLAN_MTU not supported.
-
Changing the VLAN MTU is not currently supported by the driver.
-
bce%d: Cannot change VLAN_HWTAGGING while management firmware - (ASF/IPMI/UMP) is running!
-
Management firmware to support ASF/IPMI/UMP requires that VLAN tag - stripping be enabled in the controller.
-
bce%d: Changing VLAN_HWTAGGING not supported!
-
Disabling VLAN tag stripping is not currently supported by the - driver.
-
bce%d: Watchdog timeout occurred, resetting!
-
The device has stopped responding to the network, there is a problem with - the cable connection, or a driver logic problem has occurred..
-
bce%d: Fatal attention detected: 0x%08X!
-
A controller hardware failure has occurred. If the problem continues - replace the controller.
-
-
-
-

-

For support questions please contact your QLogic approved reseller - or QLogic Technical Support at - http://support.qlogic.com, or by E-mail at - <support@qlogic.com>.

-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The bce device driver first appeared in - FreeBSD 6.1.

-
-
-

-

The bce driver was written by - David Christensen - <davidch@broadcom.com>.

-
-
- - - - - -
June 4, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/bcm5974.4 4.html b/static/freebsd/man4/bcm5974.4 4.html deleted file mode 100644 index b4fa00a6..00000000 --- a/static/freebsd/man4/bcm5974.4 4.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
BCM5974(4)Device Drivers ManualBCM5974(4)
-
-
-

-

bcm5974 — - Wellspring touchpad driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device bcm5974 -
-device hidbus -
-device hid -
-device usbhid -
-device usb -
-device evdev -

-
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
bcm5974_load="YES"
-
-
-
-

-

The bcm5974 driver provides support for - the Wellspring touchpads found in many Apple laptops.

-

To get multi-touch device working in X(7) - (ports/x11/xorg-docs), install - ports/x11-drivers/xf86-input-libinput.

-
-
-

-

bcm5974 creates a pseudo-device file, - /dev/input/eventX which presents the multi-touch - device as an input event device.

-
-
-

-

hid(4), loader.conf(5), - xorg.conf(5) (ports/x11/xorg), - libinput(4) - (ports/x11-drivers/xf86-input-libinput).

-
-
-

-

The bcm5974 driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>. - It is based on wsp(4) driver written by - Huang Wen Hui - <huanghwh@gmail.com>.

-
-
-

-

bcm5974 cannot act like - sysmouse(4)

-
-
- - - - - -
February 27, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/bcma.4 4.html b/static/freebsd/man4/bcma.4 4.html deleted file mode 100644 index 8c78eea5..00000000 --- a/static/freebsd/man4/bcma.4 4.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - -
BCMA(4)Device Drivers ManualBCMA(4)
-
-
-

-

bcma — Broadcom - AMBA Backplane driver

-
-
-

-

To compile this driver into the kernel, add the following lines to - the kernel configuration file:

-
device bhnd -
-device bcma
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
bcma_load="YES"
-
-
-
-

-

The bcma driver provides - bhnd(4) support for devices using the ARM AMBA-based - backplane architecture found in later Broadcom Home Networking Division's - network chipsets and embedded systems.

-

A common interconnect connects all of the backplane's functional - blocks. These functional blocks, known as cores, use the ARM AMBA AXI or APB - interface to communicate with devices attached to the interconnect.

-

The IP cores used in siba(4) devices were - adapted by Broadcom for compatibility with the new interconnect.

-
-
-

-

bhnd(4), intro(4), - siba(4)

-
-
-

-

The bcma device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The bcma driver was written by - Landon Fuller - <landonf@FreeBSD.org>.

-
-
- - - - - -
June 3, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/bfe.4 3.html b/static/freebsd/man4/bfe.4 3.html deleted file mode 100644 index 3929c7c9..00000000 --- a/static/freebsd/man4/bfe.4 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
BFE(4)Device Drivers ManualBFE(4)
-
-
-

-

bfe — Broadcom - BCM4401 Ethernet Device Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device bfe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_bfe_load="YES"
-
-
-
-

-

The bfe driver is unmaintained and may be - removed from FreeBSD in a future release. - FreeBSD.

-
-
-

-

The bfe driver provides support for - Broadcom BCM4401 based Fast Ethernet adapters.

-

The bfe driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options.
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-

The bfe driver supports the following - media options:

-
-
-
Set full duplex operation.
-
-

For further information on configuring this device, see - ifconfig(8).

-
-
-

-
-
bfe%d: couldn't map memory
-
A fatal initialization error has occurred.
-
bfe%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
bfe%d: failed to allocate DMA resources
-
There are not enough mbufs available for allocation.
-
bfe%d: watchdog timeout -- resetting
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), ifconfig(8)

-
-
-

-

The bfe device driver first appeared in - FreeBSD 5.1.

-
-
-

-

The bfe device driver was written by - Stuart Walsh and Duncan - Barclay. This manual page was written by Stuart - Walsh.

-
-
- - - - - -
July 16, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/bge.4 3.html b/static/freebsd/man4/bge.4 3.html deleted file mode 100644 index d57c1d20..00000000 --- a/static/freebsd/man4/bge.4 3.html +++ /dev/null @@ -1,220 +0,0 @@ - - - - - - -
BGE(4)Device Drivers ManualBGE(4)
-
-
-

-

bge — Broadcom - BCM57xx/BCM590x Gigabit/Fast Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device bge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_bge_load="YES"
-
-
-
-

-

The bge driver provides support for - various NICs based on the Broadcom BCM570x, 571x, 572x, 575x, 576x, 578x, - 5776x and 5778x Gigabit Ethernet controller chips and the 590x and 5779x - Fast Ethernet controller chips.

-

All of these NICs are capable of 10, 100 and 1000Mbps speeds over - CAT5 copper cable, except for the SysKonnect SK-9D41 which supports only - 1000Mbps over multimode fiber. The BCM570x builds upon the technology of the - Alteon Tigon II. It has two R4000 CPU cores and is PCI v2.2 and PCI-X v1.0 - compliant. It supports IP, TCP and UDP checksum offload for both receive and - transmit, multiple RX and TX DMA rings for QoS applications, rules-based - receive filtering, and VLAN tag stripping/insertion as well as a 256-bit - multicast hash filter. Additional features may be provided via value-add - firmware updates. The BCM570x supports TBI (ten bit interface) and GMII - transceivers, which means it can be used with either copper or 1000baseX - fiber applications. Note however the device only supports a single speed in - TBI mode.

-

Most BCM5700-based cards also use the Broadcom BCM5401 or BCM5411 - 10/100/1000 copper gigabit transceivers, which support autonegotiation of - 10, 100 and 1000Mbps modes in full or half duplex.

-

The BCM5700, BCM5701, BCM5702, BCM5703, BCM5704, BCM5714, BCM5717, - BCM5719, BCM5720, BCM5780 and BCM57765 also support jumbo frames, which can - be configured via the interface MTU setting. Selecting an MTU larger than - 1500 bytes with the ifconfig(8) utility configures the - adapter to receive and transmit jumbo frames. Using jumbo frames can greatly - improve performance for certain tasks, such as file transfers and data - streaming.

-

The bge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX operation over twisted pair. Only - full-duplex mode is supported.
-
-
Set 1000Mbps (Gigabit Ethernet) operation. Both - full-duplex and - half-duplex modes are supported.
-
-

The bge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The bge driver provides support for - various NICs based on the Broadcom BCM570x family of Gigabit Ethernet - controller chips, including the following:

-

-
    -
  • 3Com 3c996-SX (1000baseSX)
    • -
  • 3Com 3c996-T (10/100/1000baseTX)
    • -
  • Apple Thunderbolt Display (10/100/1000baseTX)
    • -
  • Apple Thunderbolt to Gigabit Ethernet Adapter (10/100/1000baseTX)
    • -
  • Dell PowerEdge 1750 integrated BCM5704C NIC (10/100/1000baseTX)
    • -
  • Dell PowerEdge 2550 integrated BCM5700 NIC (10/100/1000baseTX)
    • -
  • Dell PowerEdge 2650 integrated BCM5703 NIC (10/100/1000baseTX)
    • -
  • Dell PowerEdge R200 integrated BCM5750 NIC (10/100/1000baseTX)
    • -
  • Dell PowerEdge R300 integrated BCM5722 NIC (10/100/1000baseTX)
    • -
  • IBM x235 server integrated BCM5703x NIC (10/100/1000baseTX)
    • -
  • HP Compaq dc7600 integrated BCM5752 NIC (10/100/1000baseTX)
    • -
  • HP ProLiant NC7760 embedded Gigabit NIC (10/100/1000baseTX)
    • -
  • HP ProLiant NC7770 PCI-X Gigabit NIC (10/100/1000baseTX)
    • -
  • HP ProLiant NC7771 PCI-X Gigabit NIC (10/100/1000baseTX)
    • -
  • HP ProLiant NC7781 embedded PCI-X Gigabit NIC (10/100/1000baseTX)
    • -
  • Netgear GA302T (10/100/1000baseTX)
    • -
  • SysKonnect SK-9D21 (10/100/1000baseTX)
    • -
  • SysKonnect SK-9D41 (1000baseSX)
    • -
-
-
-

-

The following tunables can be set at the - loader(8) prompt before booting the kernel, or stored in - loader.conf(5).

-
-
hw.bge.allow_asf
-
Allow the ASF feature for cooperating with IPMI. Can cause system lockup - problems on a small number of systems. Enabled by default.
-
dev.bge.%d.msi
-
Non-zero value enables MSI support on the Ethernet hardware. The default - value is 1.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.bge.%d.forced_collapse
-
Allow collapsing multiple transmit buffers into a single buffer to - increase transmit performance with the cost of CPU cycles. The default - value is 0 to disable transmit buffer collapsing.
-
dev.bge.%d.forced_udpcsum
-
Enable UDP transmit checksum offloading even if controller can generate - UDP datagrams with checksum value 0. UDP datagrams with checksum value 0 - can confuse receiver host as it means sender did not compute UDP checksum. - The default value is 0 which disables UDP transmit checksum offloading. - The interface need to be brought down and up again before a change takes - effect.
-
-
-
-

-
-
bge%d: couldn't map memory
-
A fatal initialization error has occurred.
-
bge%d: couldn't map ports
-
A fatal initialization error has occurred.
-
bge%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
bge%d: no memory for softc struct!
-
The driver failed to allocate memory for per-device instance information - during initialization.
-
bge%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
bge%d: firmware handshake timed out, found 0xffffffff
-
The device was physically disconnected from the system, or there is a - problem with the device causing it to stop responding to the host it is - attached to.
-
bge%d: no memory for jumbo buffers!
-
The driver failed to allocate memory for jumbo frames during - initialization.
-
bge%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-
-
-

-

The bge device driver first appeared in - FreeBSD 4.5.

-
-
-

-

The bge driver was written by - Bill Paul - <wpaul@windriver.com>.

-
-
-

-

Hotplug is not currently supported in - FreeBSD, hence, Thunderbolt interfaces need to be - connected prior to system power up on Apple systems in order for the - interface to be detected. Also, due to the lack of hotplug support, - Thunderbolt-based interfaces must not be removed while the system is up as - the kernel is currently unable to cope with a bge - interface disappearing.

-

The UDP transmit checksum offloading is disabled by default, see - dev.bge.%d.forced_udpcsum. To avoid problems when the - interface is a member of a bridge(4) interface, all - transmit checksum offloading is initially disabled in this case. Transmit - checksum offloading can be enabled using ifconfig(8).

-
-
- - - - - -
January 16, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/bhnd.4 4.html b/static/freebsd/man4/bhnd.4 4.html deleted file mode 100644 index 05ec0810..00000000 --- a/static/freebsd/man4/bhnd.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
BHND(4)Device Drivers ManualBHND(4)
-
-
-

-

bhnd — Broadcom - Home Networking Division interconnect bus

-
-
-

-

To compile this driver into the kernel, add the following lines to - the kernel configuration file:

-
device bhnd
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
bhnd_load="YES"
-
-
-
-

-

The bhnd driver provides a unified kernel - bus interface to the on-chip interconnects used in Broadcom Home Networking - Division (HND) devices.

-

The Broadcom HND device family consists of SoCs (System On a Chip) - and host-connected chipsets based on a common library of Broadcom IP cores - connected via an internal hardware bus architecture. Drivers for these cores - are implemented against the unified bhnd - interface.

-

The Sonic Inc. Silicon Backplane used in earlier HND devices is - supported by the siba(4) BHND driver.

-

The ARM AMBA-based interconnect used in later HND devices is - supported by the bcma(4) BHND driver.

-
-
-

-

bcma(4), bhndb(4), - intro(4), siba(4)

-
-
-

-

The bhnd device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The bhnd driver was written by - Landon Fuller - <landonf@FreeBSD.org>.

-
-
- - - - - -
June 3, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/bhnd_chipc.4 3.html b/static/freebsd/man4/bhnd_chipc.4 3.html deleted file mode 100644 index f103a424..00000000 --- a/static/freebsd/man4/bhnd_chipc.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
BHND_CHIPC(4)Device Drivers ManualBHND_CHIPC(4)
-
-
-

-

bhnd_chipc — - Broadcom Home Networking Division ChipCommon - Driver

-
-
-

-

To compile this driver into the kernel, add this line to the - kernel configuration file:

-
device bhnd
-

To compile driver support for all additional devices found in - embedded systems, add the following additional lines to the kernel - configuration file:

-
device cfi -
-device gpio -
-device spibus -
-device uart
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
bhnd_load="YES"
-
-
-
-

-

The bhnd_chipc driver supports the - ChipCommon core found in Broadcom Home Networking Division network chipsets - and embedded systems.

-

The ChipCommon core provides an interface to common hardware - facilities, including device identification, UARTs, CFI and SPI flash, - One-time Programmable (OTP) Memory, and GPIO.

-
-
-

-

bhnd(4), intro(4)

-
-
-

-

The bhnd_chipc device driver first - appeared in FreeBSD 11.0.

-
-
-

-

The bhnd_chipc driver was written by - Landon Fuller - <landonf@FreeBSD.org>, - and Michael Zhilin - <mizhka@FreeBSD.org>.

-
-
- - - - - -
October 16, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/bhnd_pmu.4 4.html b/static/freebsd/man4/bhnd_pmu.4 4.html deleted file mode 100644 index 394faf09..00000000 --- a/static/freebsd/man4/bhnd_pmu.4 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
BHND_PMU(4)Device Drivers ManualBHND_PMU(4)
-
-
-

-

bhnd_pmu — - Broadcom Home Networking Division PMU Driver

-
-
-

-

To compile this driver into the kernel, add this line to the - kernel configuration file:

-
device bhnd
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
bhnd_load="YES"
-
-
-
-

-

The bhnd_pmu driver supports the Power - Management Unit (PMU) found in Broadcom Home Networking Division network - chipsets and embedded systems.

-

The PMU provides a hardware interface for managing the device's - clock and power topology.

-
-
-

-

bhnd(4), intro(4)

-
-
-

-

The bhnd_pmu device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The bhnd_pmu driver was derived from - Broadcom's ISC-licensed Linux PMU drivers, and was ported to - FreeBSD and bhnd(4) by - Landon Fuller - <landonf@FreeBSD.org>.

-
-
- - - - - -
October 16, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/bhndb.4 4.html b/static/freebsd/man4/bhndb.4 4.html deleted file mode 100644 index f2b66c5b..00000000 --- a/static/freebsd/man4/bhndb.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
BHNDB(4)Device Drivers ManualBHNDB(4)
-
-
-

-

bhndb — Broadcom - Home Networking Division interconnect bridge driver

-
-
-

-

To compile this driver into the kernel, add the following lines to - the kernel configuration file:

-
device bhnd -
-device bhndb
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
bhndb_load="YES"
-
-
-
-

-

The bhndb driver provides - bhnd(4) host bridge support for Broadcom Home Networking - Division's wireless chipsets and network adapters.

-

To enable use for PCI/PCIe systems, see the - bhndb_pci(4) driver.

-
-
-

-

bhnd(4), bhndb_pci(4), - bwn(4), intro(4)

-
-
-

-

The bhndb device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The bhndb driver was written by - Landon Fuller - <landonf@FreeBSD.org>.

-
-
-

-

The bhndb driver does not currently - support PCMCIA or SDIO devices.

-
-
- - - - - -
October 16, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/bhndb_pci.4 3.html b/static/freebsd/man4/bhndb_pci.4 3.html deleted file mode 100644 index 76e5f49a..00000000 --- a/static/freebsd/man4/bhndb_pci.4 3.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
BHNDB_PCI(4)Device Drivers ManualBHNDB_PCI(4)
-
-
-

-

bhndb_pci — - Broadcom Home Networking Division PCI host bridge - driver

-
-
-

-

To compile this driver into the kernel, add the following lines to - the kernel configuration file:

-
device bhnd -
-device bhndb -
-device bhndb_pci -
-device pci
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
bhndb_pci_load="YES"
-
-
-
-

-

The bhndb_pci driver provides - bhndb(4) support for the PCI and PCIe host bridge cores - found in Broadcom Home Networking Division's wireless chipsets and network - adapters.

-
-
-

-

bhnd(4), bhndb(4), - bwn(4), intro(4), - pci(4)

-
-
-

-

The bhndb_pci device driver first appeared - in FreeBSD 11.0.

-
-
-

-

The bhndb_pci driver was written by - Landon Fuller - <landonf@FreeBSD.org>.

-
-
- - - - - -
October 16, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/bhyve.4 4.html b/static/freebsd/man4/bhyve.4 4.html deleted file mode 100644 index b8e9234b..00000000 --- a/static/freebsd/man4/bhyve.4 4.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
BHYVE(4)Device Drivers ManualBHYVE(4)
-
-
-

-

bhyve — virtual - machine monitor

-
-
-

-

/usr/sbin/bhyve -
- /usr/sbin/bhyveload -
- /usr/sbin/bhyvectl -
- /boot/kernel/vmm.ko

-
-
-

-

bhyve is a virtual machine monitor that is - hosted by FreeBSD. It is used to host unmodified guest operating systems on - top of FreeBSD.

-

bhyve relies heavily on hardware assist - provided by the CPU and chipset to virtualize processor and memory - resources.

-
-
-

-

vmm(4), bhyve(8), - bhyvectl(8), bhyveload(8)

-
-
-

-

bhyve first appeared in - FreeBSD 10.0, and was developed at NetApp Inc.

-
-
-

-

bhyve was developed by - Peter Grehan - <grehan@FreeBSD.org> - and Neel Natu - <neel@FreeBSD.org> at - NetApp Inc.

-
-
-

-

bhyve is considered experimental in - FreeBSD.

-
-
- - - - - -
January 5, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/blackhole.4 3.html b/static/freebsd/man4/blackhole.4 3.html deleted file mode 100644 index 14a9f20c..00000000 --- a/static/freebsd/man4/blackhole.4 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
BLACKHOLE(4)Device Drivers ManualBLACKHOLE(4)
-
-
-

-

blackhole — - quietly drop refused SCTP, TCP, or UDP packets

-
-
-

-

sysctl net.inet.sctp.blackhole[={0 | 1 | - 2}] -
- sysctl net.inet.tcp.blackhole[={0 | 1 | 2 | 3}] -
- sysctl net.inet.tcp.blackhole_local[={0 | 1}] -
- sysctl net.inet.udp.blackhole[={0 | 1}] -
- sysctl net.inet.udp.blackhole_local[={0 | 1}]

-
-
-

-

The blackhole sysctl(8) - MIB is used to control system behaviour when connection requests are - received on SCTP, TCP, or UDP ports where there is no socket listening or - unexpected packets are received on listening sockets.

-

The blackhole behaviour is useful to slow down an attacker who is - port-scanning a system in an attempt to detect vulnerable services. It might - also slow down an attempted denial of service attack.

-

The blackhole behaviour is disabled by default. If enabled, the - locally originated packets would still be responded to, unless also - net.inet.tcp.blackhole_local (for TCP) and/or - net.inet.udp.blackhole_local (for UDP) are - enforced.

-
-

-

Setting the SCTP blackhole MIB to a numeric value of one will - prevent sending an ABORT packet in response to an incoming INIT. A MIB value - of two will do the same, but will also prevent sending an ABORT packet when - unexpected packets are received.

-
-
-

-

Normal behaviour, when a TCP SYN segment is received on a port - where there is no socket accepting connections, is for the system to return - a RST segment, and drop the incoming SYN segment. The connecting system will - see this as a “Connection refused”. By setting the TCP - blackhole MIB to a numeric value of one, the incoming SYN segment is merely - dropped, and no RST is sent, making the system appear as a blackhole. By - setting the MIB value to two, any segment arriving on a closed port is - dropped without returning a RST. Setting the MIB value to three, any segment - arriving on a closed port or an unexpected segment on a listening port is - dropped without sending a RST in reply. This provides some degree of - protection against stealth port scans.

-
-
-

-

Enabling blackhole behaviour turns off the sending of an ICMP port - unreachable message in response to a UDP datagram which arrives on a port - where there is no socket listening. It must be noted that this behaviour - will prevent remote systems from running traceroute(8) to - a system.

-
-
-
-

-

The SCTP, TCP, and UDP blackhole features should not be regarded - as a replacement for firewall solutions. Better security would consist of - the blackhole sysctl(8) MIB used - in conjunction with one of the available firewall packages.

-

This mechanism is not a substitute for securing a system. It - should be used together with other security mechanisms.

-
-
-

-

ip(4), sctp(4), - tcp(4), udp(4), - ipf(8), ipfw(8), - pfctl(8), sysctl(8)

-
-
-

-

The TCP and UDP blackhole MIBs first - appeared in FreeBSD 4.0.

-

The SCTP blackhole MIB first appeared in - FreeBSD 9.1.

-
-
-

-

Geoffrey M. Rehmet

-
-
- - - - - -
September 24, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/bnxt.4 3.html b/static/freebsd/man4/bnxt.4 3.html deleted file mode 100644 index 9699d491..00000000 --- a/static/freebsd/man4/bnxt.4 3.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - -
BNXT(4)Device Drivers ManualBNXT(4)
-
-
-

-

bnxt — Broadcom - NetXtreme family 10Gb to 400Gb Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device bnxt
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_bnxt_load="YES"
-
-
-
-

-

The bnxt driver provides support for PCIe - NICs based on the Broadcom BCM573XX, BCM574XX, BCM575XX, and BCM576XX - Ethernet controllers.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The bnxt driver supports the following - Broadcom 10Gb to 400Gb Ethernet controllers:

-

-
    -
  • Broadcom BCM57301 NetXtreme-C 10Gb Ethernet Controller
    • -
  • Broadcom BCM57302 NetXtreme-C 10Gb/25Gb Ethernet Controller
    • -
  • Broadcom BCM57304 NetXtreme-C 10Gb/25Gb/40Gb/50Gb Ethernet Controller
    • -
  • Broadcom BCM57304 NetXtreme-C Ethernet Virtual Function
    • -
  • Broadcom BCM57314 NetXtreme-C Ethernet Virtual Function
    • -
  • Broadcom BCM57402 NetXtreme-E 10Gb Ethernet Controller
    • -
  • Broadcom BCM57402 NetXtreme-E Ethernet Partition
    • -
  • Broadcom BCM57404 NetXtreme-E 10Gb/25Gb Ethernet Controller
    • -
  • Broadcom BCM57404 NetXtreme-E Ethernet Virtual Function
    • -
  • Broadcom BCM57404 NetXtreme-E Partition
    • -
  • Broadcom BCM57406 NetXtreme-E 10GBASE-T Ethernet Controller
    • -
  • Broadcom BCM57406 NetXtreme-E Partition
    • -
  • Broadcom BCM57407 NetXtreme-E 10GBase-T Ethernet Controller
    • -
  • Broadcom BCM57407 NetXtreme-E 25Gb Ethernet Controller
    • -
  • Broadcom BCM57407 NetXtreme-E Partition
    • -
  • Broadcom BCM57412 NetXtreme-E Partition
    • -
  • Broadcom BCM57414 NetXtreme-E Ethernet Virtual Function
    • -
  • Broadcom BCM57414 NetXtreme-E Partition
    • -
  • Broadcom BCM57416 NetXtreme-E Partition
    • -
  • Broadcom BCM57417 NetXtreme-E Ethernet Partition
    • -
  • Broadcom BCM57454 NetXtreme-E 10Gb/25Gb/40Gb/50Gb/100Gb Ethernet
    • -
  • Broadcom BCM57502 NetXtreme-E 10Gb/25Gb/50Gb Ethernet
    • -
  • Broadcom N425 BCM57504 NetXtreme-E 10Gb/25Gb Ethernet
    • -
  • Broadcom P425 BCM57504 NetXtreme-E 10Gb/25Gb Ethernet
    • -
  • Broadcom N1100 BCM57504 NetXtreme-E 10Gb/25Gb/50Gb/100Gb Ethernet
    • -
  • Broadcom N2100 BCM57508 Thor 10Gb/25Gb/50Gb/100Gb Ethernet
    • -
  • Broadcom P2100 BCM57508 Thor 10Gb/25Gb/50Gb/100Gb Ethernet
    • -
  • Broadcom N2200 BCM57608 Thor 2 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet
    • -
  • Broadcom P2200 BCM57608 Thor 2 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet
    • -
  • Broadcom N1400 BCM57608 Thor 2 25Gb/50Gb/100Gb/200Gb/400Gb Ethernet
    • -
  • Broadcom P1400 BCM57608 Thor 2 25Gb/50Gb/100Gb/200Gb/400Gb Ethernet
    • -
-
-
-

-

These variables must be set before loading the driver, either via - loader.conf(5) or through the use of - kenv(1). These are provided by the - iflib(4) framework, and might be better documented - there.

-
-
dev.bnxt.X.iflib.override_nrxds
-
Override the number of RX descriptors for each queue. The value is a comma - separated list of three positive integers: the size of the completion - ring, the size of the receive ring, and the size of the aggregation ring - respectively. The completion ring should be at least the size of the - aggregation ring plus four times the size of the receive ring. These - numbers must be powers of two, and zero means to use the default. Defaults - to 0,0,0.
-
dev.bnxt.X.iflib.override_ntxds
-
Override the number of TX descriptors for each queue. The value is a comma - separated list of two positive integers: the size of the completion ring, - and the size of the transmit ring respectively. The completion ring should - be at least twice the size of the transmit ring. These numbers must be - powers of two, and zero means to use the default. Defaults to 0,0.
-
dev.bnxt.X.iflib.override_qs_enable
-
When set, allows the number of transmit and receive queues to be - different. If not set, the lower of the number of TX or RX queues will be - used for both.
-
dev.bnxt.X.iflib.override_nrxqs
-
Set the number of RX queues. If zero, the number of RX queues is derived - from the number of cores on the socket connected to the controller. - Defaults to 0.
-
dev.bnxt.X.iflib.override_ntxqs
-
Set the number of TX queues. If zero, the number of TX queues is derived - from the number of cores on the socket connected to the controller.
-
-

These sysctl(8) variables can be changed at any - time:

-
-
dev.bnxt.X.vlan_only
-
Require that incoming frames must have a VLAN tag on them that matches one - that is configured for the NIC. Normally, both frames that have a matching - VLAN tag and frames that have no VLAN tag are accepted. Defaults to - 0.
-
dev.bnxt.X.vlan_strip
-
When non-zero the NIC strips VLAN tags on receive. Defaults to 0.
-
dev.bnxt.X.rx_stall
-
Enable buffering rather than dropping frames when there are no available - host RX buffers for DMA. Defaults to 0.
-
dev.bnxt.X.rss_type
-
Comma-separated list of RSS hash types to support. Default is all types. - Defaults to ipv4,tcp_ipv4,udp_ipv4,ipv6,tcp_ipv6,udp_ipv6.
-
dev.bnxt.X.rss_key
-
Current RSS key. Defaults to a randomly generated value which is generated - for each device during attach.
-
dev.bnxt.X.ver.hwrm_min_ver
-
Minimum HWRM (HardWare Resource Manager) firmware API to support. If the - firmware implements an older version, a warning will be printed, and the - firmware should be upgraded. Defaults to 1.2.2.
-
-

These sysctl(8) variables are read-only:

-
-
dev.bnxt.X.if_name
-
Current interface name of the device. This will normally be - bnxtX, but this can be changed using - ifconfig name. This sysctl allows correlating an - interface with a child of dev.bnxt.
-
dev.bnxt.X.nvram.*
-
Information about the NVRAM device which contains the device - firmware.
-
dev.bnxt.X.ver.*
-
Version-related information about the device and firmware:
-
dev.bnxt.X.ver.hwrm_if
-
Supported HWRM API version of the currently running firmware.
-
dev.bnxt.X.ver.driver_hwrm_if
-
HWRM API version the driver was built to support.
-
dev.bnxt.X.hwstats.*
-
Per-queue statistics tracked by the hardware.
-
dev.bnxt.X.hwstats.port_stats.*
-
Per-port statistics tracked by the hardware.
-
dev.bnxt.X.hwstats.rxq0.drop_pkts
-
Number of packets dropped by hardware on queue zero. This number might - seem high, but the count includes packets dropped due to incorrect - destination MAC, unsubscribed multicast address, and other normal reasons - to ignore Ethernet frames.
-
dev.bnxt.X.hwstats.rxq0.tpa_*
-
statistics related to HW LRO.
-
dev.bnxt.X.hw_lro.*
-
Enable / Disable HW LRO feature. Defaults to disable. Enabling HW LRO - could cause issues when forwarding is enabled on host.
-
dev.bnxt.X.fc
-
Enable / Disable Flow Control feature. Defaults to Enable
-
-
-
-

-
-
bnxt%d: %s command returned %s error.
-
Device firmware rejected a command from the driver. There might be a - driver/firmware HWRM API mismatch.
-
bnxt%d: Timeout sending %s (timeout: %d) seq %d
-
Device firmware unresponsive. A PCI device reset is likely needed.
-
bnxt%d: Timeout sending %s (timeout: %d) msg {0x%x 0x%x} len:%d v: %d
-
Partial firmware response. A PCI device reset is likely needed. -

As of this writing, the system must be rebooted to initiate a - PCI device reset.

-
-
-
-
-

-

altq(4), arp(4), - iflib(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The bnxt device driver first appeared in - FreeBSD 11.1.

-
-
-

-

The bnxt driver was written by - Jack Vogel - <jfvogel@gmail.com> - and Stephen Hurd - <shurd@freebsd.org>, - and is currently maintained by Broadcom Limited - <freebsd.pdl@broadcom.com>.

-
-
- - - - - -
December 10, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/bnxt_re.4 3.html b/static/freebsd/man4/bnxt_re.4 3.html deleted file mode 100644 index fadffeef..00000000 --- a/static/freebsd/man4/bnxt_re.4 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
BNXT_RE(4)Device Drivers ManualBNXT_RE(4)
-
-
-

-

bnxt_re — Broadcom - NetXtreme-E RoCE driver

-
-
-

-

To compile this driver into the kernel, place these lines in your - kernel configuration file:

-
options COMPAT_LINUXKPI -
-device bnxt -
-device bnxt_re
-

To load the driver as a module at run-time, run this command as - root:

-
-
kldload bnxt_re
-
-

To load the driver as a module at boot time, place this line in - loader.conf(5):

-
-
bnxt_re_load="YES"
-
-
-
-

-

The bnxt_re driver provides support for - Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE) for - Broadcom NetXtreme-E PCI Express network adapters.

-
-
-

-

The bnxt_re driver provides support for - NetXtreme-E BCM575xx 10/20/25/40/50/100/200Gb network adapters, - including:

-

-
    -
  • Broadcom BCM57502 NetXtreme-E 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet
    • -
  • Broadcom BCM57504 NetXtreme-E 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet
    • -
  • Broadcom BCM57508 NetXtreme-E 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet
    • -
-
-
-

-

For general information and support, go to the Broadcom support - website at: http://www.broadcom.com/.

-

Report driver issues with supported adapters to - <freebsd.pdl@broadcom.com>.

-
-
-

-

bnxt_re(4), ifconfig(8)

-
-
-

-

The bnxt_re device driver first appeared - in FreeBSD 15.0.

-
-
-

-

The bnxt_re driver was written by - Broadcom <freebsd.pdl@broadcom.com>.

-
-
- - - - - -
May 15, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/boottrace.4 3.html b/static/freebsd/man4/boottrace.4 3.html deleted file mode 100644 index 18c262a0..00000000 --- a/static/freebsd/man4/boottrace.4 3.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - -
BOOTTRACE(4)Device Drivers ManualBOOTTRACE(4)
-
-
-

-

boottrace — - Boot-time, run-time, and shutdown-time tracing - facility

-
-
-

-

#include - <sys/boottrace.h>

-
-
-

-

boottrace is a kernel-userspace interface - for capturing trace events during system boot and shutdown (in particular, - one-shot events).

-

Event annotations are present in:

- -

boottrace is unconditionally compiled into - the kernel and disabled by default.

-
-
-

-

Events are stored in three event tables: boot-time events, - run-time events, and shutdown-time events.

- - - - - - - - - - - - - - - - - -
boot-time eventsBoot, kernel initialization, and rc(8) execution; - until init(8) transitions into multi-user mode
run-time eventsFrom when the system has completed booting (including - rc(8) execution) and init(8) - transitions to multi-user mode until the beginning of shutdown - procedures
shutdown-time eventsAfter initialization of a shutdown, a reboot, or a kernel panic
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). - boottrace features the following loader - tunables:

-
-
kern.boottrace.dotrace_kernel
-
Set to ‘1’ to enable tracing of - kernel events. Default: ‘1’ - (enabled).
-
kern.boottrace.dotrace_user
-
Set to ‘1’ to enable tracing of - userspace events. Default: ‘1’ - (enabled).
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.boottrace.boottrace
-
Create a new trace event and write it to the boot-time table. -

A new trace event consists of a process name and an event - description, separated by a colon - (‘:’). If the colon is missing or - if the provided string for the process name is empty, the process name - is inferred from the invoking process (which is its executable - name).

-
-
kern.boottrace.enabled
-
Set to ‘1’ to enable tracing. This - is a read-only sysctl(8) variable. Default: - ‘0’ (disabled).
-
kern.boottrace.log
-
Show the events stored in boot-time and run-time tables. This is an opaque - sysctl(8) variable.
-
kern.boottrace.runtrace
-
Same as kern.boottrace.boottrace, but write to the - run-time table.
-
kern.boottrace.shuttrace
-
Same as kern.boottrace.boottrace, but write to the - shutdown-time table.
-
kern.boottrace.shutdown_trace
-
Log shutdown-time events to the console before the system halts.
-
kern.boottrace.shutdown_trace_threshold
-
Set a time threshold for logging shutdown-time events in milliseconds. An - event is ignored if the time difference to the previous event is less than - the threshold value. Default: ‘0’ - (logs all events).
-
-
-
-

-

Create a new trace event with a process name “foo” - and an event description “bar” using - sysctl(8):

-
-
sysctl kern.boottrace.boottrace="foo:bar"
-
-

Here is a sample output of - kern.boottrace.log (shortened with - “[...]” for readability):

-
-
CPU      msecs      delta process                  event                                      PID CPUtime IBlks OBlks
-  0   44872811          0 kernel                   sysinit 0x2100001                            0    0.00     0     0
-  0   44872812          1 kernel                   sysinit 0x2110000                            0    0.00     0     0
-  0   44872812          0 kernel                   sysinit 0x2140000                            0    0.00     0     0
-[...]
-  0   44872817          0 kernel                   sysinit 0x2800000                            0    0.00     0     0
-  0   44873820       1003 kernel                   sysinit 0x2880000                            0    0.00     0     0
-  0   44873820          0 kernel                   sysinit 0x2888000                            0    0.00     0     0
-[...]
-  1   44875735          0 kernel                   sysinit 0xfffffff                            0    0.00     0     0
-  1   44875735          0 swapper                  mi_startup done                              0    0.00     0     0
-  0   44875750         15 init                     init(8) starting...                          1    0.00     0     0
-  0   44875751          1 init                     /etc/rc starting...                          1    0.00     0     0
-  0   44875831         80 boottrace                /etc/rc.d/rctl start                        26    0.00     0     0
-  1   44875839          8 boottrace                /etc/rc.d/rctl done                         26    0.00     2     0
-[...]
-  0   44876446          0 boottrace                /etc/rc.d/netif start                      390    0.00     0     0
-  1   44881116       4670 boottrace                /etc/rc.d/netif done                       390    0.12    34     0
-[...]
-  0   44882866          1 boottrace                /etc/rc.d/securelevel start               1679    0.00     0     0
-  0   44882872          6 boottrace                /etc/rc.d/securelevel done                1679    0.00     0     0
-  1   44882879          7 init                     /etc/rc finished                             1    2.22   743    15
-Total measured time: 10068 msecs
-
-
-CPU      msecs      delta process                  event                                      PID CPUtime IBlks OBlks
-  1   44882880          0 init                     multi-user start                             1    2.22   743    15
-  0   44918215      35335 kldload                  hwpmc.ko: sysinit 0xd800000               1698    0.00     0     0
-Total measured time: 35335 msecs
-
-
-
-

-

tslog(4), boottrace(8), - sysctl(8)

-
-
-

-

NetApp created boottrace to diagnose slow - devices and subsystems. Once upstreamed, boottrace - was first publicly released with FreeBSD 14.0.

-
-
-

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
July 1, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/bpf.4 3.html b/static/freebsd/man4/bpf.4 3.html deleted file mode 100644 index 806967f6..00000000 --- a/static/freebsd/man4/bpf.4 3.html +++ /dev/null @@ -1,895 +0,0 @@ - - - - - - -
BPF(4)Device Drivers ManualBPF(4)
-
-
-

-

bpf — Berkeley - Packet Filter

-
-
-

-

device bpf

-
-
-

-

The Berkeley Packet Filter provides a raw interface to data link - layers in a protocol independent fashion. All packets on the network, even - those destined for other hosts, are accessible through this mechanism.

-

The packet filter appears as a character special device, - /dev/bpf. After opening the device, the file - descriptor must be bound to a specific network interface with the - BIOCSETIF ioctl. A given interface can be shared by - multiple listeners, and the filter underlying each descriptor will see an - identical packet stream.

-

Associated with each open instance of a - bpf file is a user-settable packet filter. Whenever - a packet is received by an interface, all file descriptors listening on that - interface apply their filter. Each descriptor that accepts the packet - receives its own copy.

-

A packet can be sent out on the network by writing to a - bpf file descriptor. The writes are unbuffered, - meaning only one packet can be processed per write. Currently, only writes - to Ethernets and SLIP links are supported.

-
-
-

-

bpf devices deliver packet data to the - application via memory buffers provided by the application. The buffer mode - is set using the BIOCSETBUFMODE ioctl, and read - using the BIOCGETBUFMODE ioctl.

-
-

-

By default, bpf devices operate in the - BPF_BUFMODE_BUFFER mode, in which packet data is - copied explicitly from kernel to user memory using the - read(2) system call. The user process will declare a fixed - buffer size that will be used both for sizing internal buffers and for all - read(2) operations on the file. This size is queried using - the BIOCGBLEN ioctl, and is set using the - BIOCSBLEN ioctl. Note that an individual packet - larger than the buffer size is necessarily truncated.

-
-
-

-

bpf devices may also operate in the - BPF_BUFMODE_ZEROCOPY mode, in which packet data is - written directly into two user memory buffers by the kernel, avoiding both - system call and copying overhead. Buffers are of fixed (and equal) size, - page-aligned, and an even multiple of the page size. The maximum zero-copy - buffer size is returned by the BIOCGETZMAX ioctl. - Note that an individual packet larger than the buffer size is necessarily - truncated.

-

The user process registers two memory buffers using the - BIOCSETZBUF ioctl, which accepts a - struct bpf_zbuf pointer as an argument:

-
-
struct bpf_zbuf {
-	void *bz_bufa;
-	void *bz_bufb;
-	size_t bz_buflen;
-};
-
-

bz_bufa is a pointer to the userspace - address of the first buffer that will be filled, and - bz_bufb is a pointer to the second buffer. - bpf will then cycle between the two buffers as they - fill and are acknowledged.

-

Each buffer begins with a fixed-length header to hold - synchronization and data length information for the buffer:

-
-
struct bpf_zbuf_header {
-	volatile u_int  bzh_kernel_gen;	/* Kernel generation number. */
-	volatile u_int  bzh_kernel_len;	/* Length of data in the buffer. */
-	volatile u_int  bzh_user_gen;	/* User generation number. */
-	/* ...padding for future use... */
-};
-
-

The header structure of each buffer, including all padding, should - be zeroed before it is configured using BIOCSETZBUF. - Remaining space in the buffer will be used by the kernel to store packet - data, laid out in the same format as with buffered read mode.

-

The kernel and the user process follow a simple acknowledgement - protocol via the buffer header to synchronize access to the buffer: when the - header generation numbers, bzh_kernel_gen and - bzh_user_gen, hold the same value, the kernel owns the - buffer, and when they differ, userspace owns the buffer.

-

While the kernel owns the buffer, the contents are unstable and - may change asynchronously; while the user process owns the buffer, its - contents are stable and will not be changed until the buffer has been - acknowledged.

-

Initializing the buffer headers to all 0's before registering the - buffer has the effect of assigning initial ownership of both buffers to the - kernel. The kernel signals that a buffer has been assigned to userspace by - modifying bzh_kernel_gen, and userspace acknowledges - the buffer and returns it to the kernel by setting the value of - bzh_user_gen to the value of - bzh_kernel_gen.

-

In order to avoid caching and memory re-ordering effects, the user - process must use atomic operations and memory barriers when checking for and - acknowledging buffers:

-
-
#include <machine/atomic.h>
-
-/*
- * Return ownership of a buffer to the kernel for reuse.
- */
-static void
-buffer_acknowledge(struct bpf_zbuf_header *bzh)
-{
-
-	atomic_store_rel_int(&bzh->bzh_user_gen, bzh->bzh_kernel_gen);
-}
-
-/*
- * Check whether a buffer has been assigned to userspace by the kernel.
- * Return true if userspace owns the buffer, and false otherwise.
- */
-static int
-buffer_check(struct bpf_zbuf_header *bzh)
-{
-
-	return (bzh->bzh_user_gen !=
-	    atomic_load_acq_int(&bzh->bzh_kernel_gen));
-}
-
-

The user process may force the assignment of the next buffer, if - any data is pending, to userspace using the - BIOCROTZBUF ioctl. This allows the user process to - retrieve data in a partially filled buffer before the buffer is full, such - as following a timeout; the process must recheck for buffer ownership using - the header generation numbers, as the buffer will not be assigned to - userspace if no data was present.

-

As in the buffered read mode, kqueue(2), - poll(2), and select(2) may be used to - sleep awaiting the availability of a completed buffer. They will return a - readable file descriptor when ownership of the next buffer is assigned to - user space.

-

In the current implementation, the kernel may assign zero, one, or - both buffers to the user process; however, an earlier implementation - maintained the invariant that at most one buffer could be assigned to the - user process at a time. In order to both ensure progress and high - performance, user processes should acknowledge a completely processed buffer - as quickly as possible, returning it for reuse, and not block waiting on a - second buffer while holding another buffer.

-
-
-
-

-

The ioctl(2) command codes below are defined in - <net/bpf.h>. All commands - require these includes:

-
-
	#include <sys/types.h>
-	#include <sys/time.h>
-	#include <sys/ioctl.h>
-	#include <net/bpf.h>
-
-

Additionally, BIOCGETIF and - BIOCSETIF require - <sys/socket.h> and - <net/if.h>.

-

In addition to FIONREAD the following - commands may be applied to any open bpf file. The - (third) argument to ioctl(2) should be a pointer to the - type indicated.

-
-
-
(struct bpf_iflist) Returns list of available - tapping points, that can later be attached to with - BIOCSETIF. On entry the - bi_ubuf shall point to user supplied buffer. The - bi_size shall specify length of the buffer, or 0 if - the request is used to determine the required length. The - bi_count can be used to limit the output to first - count entries, otherwise shall be 0. On return, if - the buffer length was enough to accommodate all desired entries, then the - supplied buffer is filled with NUL-terminated names of available tapping - points and bi_count is set to the number of copied - names. Otherwise ENOSPC is returned.
-
-
(u_int) Returns the required buffer length for - reads on bpf files.
-
-
(u_int) Sets the buffer length for reads on - bpf files. The buffer must be set before the file - is attached to an interface with BIOCSETIF. If the - requested buffer size cannot be accommodated, the closest allowable size - will be set and returned in the argument. A read call will result in - EINVAL if it is passed a buffer that is not this - size.
-
-
(u_int) Returns the type of the data link layer - underlying the attached interface. EINVAL is - returned if no interface has been specified. The device types, prefixed - with “DLT_”, are defined in - <net/bpf.h>.
-
-
(struct bpf_dltlist) Returns an array of the - available types of the data link layer underlying the attached interface: -
- 
struct bpf_dltlist {
-	u_int bfl_len;
-	u_int *bfl_list;
-};
-
-

The available types are returned in the array pointed to by - the bfl_list field while their length in u_int is - supplied to the bfl_len field. - ENOMEM is returned if there is not enough buffer - space and EFAULT is returned if a bad address is - encountered. The bfl_len field is modified on - return to indicate the actual length in u_int of the array returned. If - bfl_list is NULL, the - bfl_len field is set to indicate the required - length of an array in u_int.

-
-
-
(u_int) Changes the type of the data link layer - underlying the attached interface. EINVAL is - returned if no interface has been specified or the specified type is not - available for the interface.
-
-
Forces the interface into promiscuous mode. All packets, not just those - destined for the local host, are processed. Since more than one file can - be listening on a given interface, a listener that opened its interface - non-promiscuously may receive packets promiscuously. This problem can be - remedied with an appropriate filter. -

The interface remains in promiscuous mode until all files - listening promiscuously are closed.

-
-
-
Flushes the buffer of incoming packets, and resets the statistics that are - returned by BIOCGSTATS.
-
-
(struct ifreq) Returns the name of the hardware - interface that the file is listening on. The name is returned in the - ifr_name field of the ifreq structure. All other - fields are undefined.
-
-
(struct ifreq) Sets the hardware interface - associated with the file. This command must be performed before any - packets can be read. The device is indicated by name using the - ifr_name field of the - ifreq structure. Additionally, performs the - actions of BIOCFLUSH.
-
-
 
-
-
(struct timeval) Sets or gets the read timeout - parameter. The argument specifies the length of time to wait before timing - out on a read request. This parameter is initialized to zero by - open(2), indicating no timeout.
-
-
(struct bpf_stat) Returns the following structure - of packet statistics: -
- 
struct bpf_stat {
-	u_int bs_recv;    /* number of packets received */
-	u_int bs_drop;    /* number of packets dropped */
-};
-
-

The fields are:

-
-
-
the number of packets received by the descriptor since opened or reset - (including any buffered since the last read call); and
-
-
the number of packets which were accepted by the filter but dropped by - the kernel because of buffer overflows (i.e., the application's reads - are not keeping up with the packet traffic).
-
-
-
-
(u_int) Enables or disables “immediate - mode”, based on the truth value of the argument. When immediate - mode is enabled, reads return immediately upon packet reception. - Otherwise, a read will block until either the kernel buffer becomes full - or a timeout occurs. This is useful for programs like - rarpd(8) which must respond to messages in real time. - The default for a new file is off.
-
-
 
-
-
(struct bpf_program) Sets the read filter program - used by the kernel to discard uninteresting packets. An array of - instructions and its length is passed in using the following structure: -
- 
struct bpf_program {
-	u_int bf_len;
-	struct bpf_insn *bf_insns;
-};
-
-

The filter program is pointed to by the - bf_insns field while its length in units of - ‘struct bpf_insn’ is given by the - bf_len field. See section - FILTER MACHINE for an - explanation of the filter language. The only difference between - BIOCSETF and BIOCSETFNR - is BIOCSETF performs the actions of - BIOCFLUSH while - BIOCSETFNR does not.

-
-
-
(struct bpf_program) Sets the write filter program - used by the kernel to control what type of packets can be written to the - interface. See the BIOCSETF command for more - information on the bpf filter program.
-
-
(struct bpf_version) Returns the major and minor - version numbers of the filter language currently recognized by the kernel. - Before installing a filter, applications must check that the current - version is compatible with the running kernel. Version numbers are - compatible if the major numbers match and the application minor is less - than or equal to the kernel minor. The kernel version number is returned - in the following structure: -
- 
struct bpf_version {
-        u_short bv_major;
-        u_short bv_minor;
-};
-
-

The current version numbers are given by - BPF_MAJOR_VERSION and - BPF_MINOR_VERSION from - <net/bpf.h>. An - incompatible filter may result in undefined behavior (most likely, an - error returned by - () - or haphazard packet matching).

-
-
-
 
-
-
(u_int) Sets or gets the receive signal. This - signal will be sent to the process or process group specified by - FIOSETOWN. It defaults to - SIGIO.
-
-
 
-
-
(u_int) Sets or gets the status of the - “header complete” flag. Set to zero if the link level source - address should be filled in automatically by the interface output routine. - Set to one if the link level source address will be written, as provided, - to the wire. This flag is initialized to zero by default.
-
-
 
-
-
(u_int) These commands are obsolete but left for - compatibility. Use BIOCSDIRECTION and - BIOCGDIRECTION instead. Sets or gets the flag - determining whether locally generated packets on the interface should be - returned by BPF. Set to zero to see only incoming packets on the - interface. Set to one to see packets originating locally and remotely on - the interface. This flag is initialized to one by default.
-
-
 
-
-
(u_int) Sets or gets the setting determining - whether incoming, outgoing, or all packets on the interface should be - returned by BPF. Set to BPF_D_IN to see only - incoming packets on the interface. Set to - BPF_D_INOUT to see packets originating locally and - remotely on the interface. Set to BPF_D_OUT to see - only outgoing packets on the interface. This setting is initialized to - BPF_D_INOUT by default.
-
-
 
-
-
(u_int) Set or get format and resolution of the - time stamps returned by BPF. Set to - BPF_T_MICROTIME, - BPF_T_MICROTIME_FAST, - BPF_T_MICROTIME_MONOTONIC, or - BPF_T_MICROTIME_MONOTONIC_FAST to get time stamps - in 64-bit struct timeval format. Set to - BPF_T_NANOTIME, - BPF_T_NANOTIME_FAST, - BPF_T_NANOTIME_MONOTONIC, or - BPF_T_NANOTIME_MONOTONIC_FAST to get time stamps - in 64-bit struct timespec format. Set to - BPF_T_BINTIME, - BPF_T_BINTIME_FAST, - BPF_T_NANOTIME_MONOTONIC, or - BPF_T_BINTIME_MONOTONIC_FAST to get time stamps in - 64-bit struct bintime format. Set to - BPF_T_NONE to ignore time stamp. All 64-bit time - stamp formats are wrapped in struct bpf_ts. The - BPF_T_MICROTIME_FAST, - BPF_T_NANOTIME_FAST, - BPF_T_BINTIME_FAST, - BPF_T_MICROTIME_MONOTONIC_FAST, - BPF_T_NANOTIME_MONOTONIC_FAST, and - BPF_T_BINTIME_MONOTONIC_FAST are analogs of - corresponding formats without _FAST suffix but do not perform a full time - counter query, so their accuracy is one timer tick. The - BPF_T_MICROTIME_MONOTONIC, - BPF_T_NANOTIME_MONOTONIC, - BPF_T_BINTIME_MONOTONIC, - BPF_T_MICROTIME_MONOTONIC_FAST, - BPF_T_NANOTIME_MONOTONIC_FAST, and - BPF_T_BINTIME_MONOTONIC_FAST store the time - elapsed since kernel boot. This setting is initialized to - BPF_T_MICROTIME by default.
-
-
(u_int) Set packet feedback mode. This allows - injected packets to be fed back as input to the interface when output via - the interface is successful. When BPF_D_INOUT - direction is set, injected outgoing packet is not returned by BPF to avoid - duplication. This flag is initialized to zero by default.
-
-
Set the locked flag on the bpf descriptor. This - prevents the execution of ioctl commands which could change the underlying - operating parameters of the device.
-
-
 
-
-
(u_int) Get or set the current - bpf buffering mode; possible values are - BPF_BUFMODE_BUFFER, buffered read mode, and - BPF_BUFMODE_ZBUF, zero-copy buffer mode.
-
-
(struct bpf_zbuf) Set the current zero-copy buffer - locations; buffer locations may be set only once zero-copy buffer mode has - been selected, and prior to attaching to an interface. Buffers must be of - identical size, page-aligned, and an integer multiple of pages in size. - The three fields bz_bufa, - bz_bufb, and bz_buflen must be - filled out. If buffers have already been set for this device, the ioctl - will fail.
-
-
(size_t) Get the largest individual zero-copy - buffer size allowed. As two buffers are used in zero-copy buffer mode, the - limit (in practice) is twice the returned size. As zero-copy buffers - consume kernel address space, conservative selection of buffer size is - suggested, especially when there are multiple bpf - descriptors in use on 32-bit systems.
-
-
Force ownership of the next buffer to be assigned to userspace, if any - data present in the buffer. If no data is present, the buffer will remain - owned by the kernel. This allows consumers of zero-copy buffering to - implement timeouts and retrieve partially filled buffers. In order to - handle the case where no data is present in the buffer and therefore - ownership is not assigned, the user process must check - bzh_kernel_gen against - bzh_user_gen.
-
-
Set the VLAN PCP bits to the supplied value.
-
-
-
-

-

bpf now supports several standard - ioctl(2)'s which allow the user to do async and/or - non-blocking I/O to an open - file - descriptor.

-
-
-
(int) Returns the number of bytes that are - immediately available for reading.
-
-
(struct ifreq) Returns the address associated with - the interface.
-
-
(int) Sets or clears non-blocking I/O. If arg is - non-zero, then doing a read(2) when no data is available - will return -1 and errno will be set to - EAGAIN. If arg is zero, non-blocking I/O is - disabled. Note: setting this overrides the timeout set by - BIOCSRTIMEOUT.
-
-
(int) Enables or disables async I/O. When enabled - (arg is non-zero), the process or process group specified by - FIOSETOWN will start receiving - SIGIO 's when packets arrive. Note that you must - do an FIOSETOWN in order for this to take effect, - as the system will not default this for you. The signal may be changed via - BIOCSRSIG.
-
-
 
-
-
(int) Sets or gets the process or process group - (if negative) that should receive SIGIO when - packets are available. The signal may be changed using - BIOCSRSIG (see above).
-
-
-
-

-

One of the following structures is prepended to each packet - returned by read(2) or via a zero-copy buffer:

-
-
struct bpf_xhdr {
-	struct bpf_ts	bh_tstamp;     /* time stamp */
-	uint32_t	bh_caplen;     /* length of captured portion */
-	uint32_t	bh_datalen;    /* original length of packet */
-	u_short		bh_hdrlen;     /* length of bpf header (this struct
-					  plus alignment padding) */
-};
-
-struct bpf_hdr {
-	struct timeval	bh_tstamp;     /* time stamp */
-	uint32_t	bh_caplen;     /* length of captured portion */
-	uint32_t	bh_datalen;    /* original length of packet */
-	u_short		bh_hdrlen;     /* length of bpf header (this struct
-					  plus alignment padding) */
-};
-
-

The fields, whose values are stored in host order, and are:

-

-
-
-
The time at which the packet was processed by the packet filter.
-
-
The length of the captured portion of the packet. This is the minimum of - the truncation amount specified by the filter and the length of the - packet.
-
-
The length of the packet off the wire. This value is independent of the - truncation amount specified by the filter.
-
-
The length of the bpf header, which may not be - equal to - (struct - bpf_xhdr) or sizeof(struct - bpf_hdr).
-
-

The bh_hdrlen field exists to account for - padding between the header and the link level protocol. The purpose here is - to guarantee proper alignment of the packet data structures, which is - required on alignment sensitive architectures and improves performance on - many other architectures. The packet filter ensures that the - bpf_xhdr, bpf_hdr and the - network layer header will be word aligned. Currently, - bpf_hdr is used when the time stamp is set to - BPF_T_MICROTIME, - BPF_T_MICROTIME_FAST, - BPF_T_MICROTIME_MONOTONIC, - BPF_T_MICROTIME_MONOTONIC_FAST, or - BPF_T_NONE for backward compatibility reasons. - Otherwise, bpf_xhdr is used. However, - bpf_hdr may be deprecated in the near future. Suitable - precautions must be taken when accessing the link layer protocol fields on - alignment restricted machines. (This is not a problem on an Ethernet, since - the type field is a short falling on an even offset, and the addresses are - probably accessed in a bytewise fashion).

-

Additionally, individual packets are padded so that each starts on - a word boundary. This requires that an application has some knowledge of how - to get from packet to packet. The macro - BPF_WORDALIGN is defined in - <net/bpf.h> to facilitate - this process. It rounds up its argument to the nearest word aligned value - (where a word is BPF_ALIGNMENT bytes wide).

-

For example, if ‘p’ points - to the start of a packet, this expression will advance it to the next - packet:

-
p = (char *)p + - BPF_WORDALIGN(p->bh_hdrlen + p->bh_caplen)
-

For the alignment mechanisms to work properly, the buffer passed - to read(2) must itself be word aligned. The - malloc(3) function will always return an aligned - buffer.

-
-
-

-

A filter program is an array of instructions, with all branches - forwardly directed, terminated by a - - instruction. Each instruction performs some action on the pseudo-machine - state, which consists of an accumulator, index register, scratch memory - store, and implicit program counter.

-

The following structure defines the instruction format:

-
-
struct bpf_insn {
-	u_short     code;
-	u_char      jt;
-	u_char      jf;
-	bpf_u_int32 k;
-};
-
-

The k field is used in different ways by - different instructions, and the jt and - jf fields are used as offsets by the branch - instructions. The opcodes are encoded in a semi-hierarchical fashion. There - are eight classes of instructions: BPF_LD, - BPF_LDX, BPF_ST, - BPF_STX, BPF_ALU, - BPF_JMP, BPF_RET, and - BPF_MISC. Various other mode and operator bits are - or'd into the class to give the actual instructions. The classes and modes - are defined in - <net/bpf.h>.

-

Below are the semantics for each defined - bpf instruction. We use the convention that A is the - accumulator, X is the index register, P[] packet data, and M[] scratch - memory store. P[i:n] gives the data at byte offset “i” in the - packet, interpreted as a word (n=4), unsigned halfword (n=2), or unsigned - byte (n=1). M[i] gives the i'th word in the scratch memory store, which is - only addressed in word units. The memory store is indexed from 0 to - BPF_MEMWORDS - 1. k, - jt, and jf are the - corresponding fields in the instruction definition. “len” - refers to the length of the packet.

-
-
-
These instructions copy a value into the accumulator. The type of the - source operand is specified by an “addressing mode” and can - be a constant (BPF_IMM), packet data at a fixed - offset (BPF_ABS), packet data at a variable offset - (BPF_IND), the packet length - (BPF_LEN), or a word in the scratch memory store - (BPF_MEM). For BPF_IND and - BPF_ABS, the data size must be specified as a word - (BPF_W), halfword (BPF_H), - or byte (BPF_B). The semantics of all the - recognized BPF_LD instructions follow. -
- 
BPF_LD+BPF_W+BPF_ABS	A <- P[k:4]
-BPF_LD+BPF_H+BPF_ABS	A <- P[k:2]
-BPF_LD+BPF_B+BPF_ABS	A <- P[k:1]
-BPF_LD+BPF_W+BPF_IND	A <- P[X+k:4]
-BPF_LD+BPF_H+BPF_IND	A <- P[X+k:2]
-BPF_LD+BPF_B+BPF_IND	A <- P[X+k:1]
-BPF_LD+BPF_W+BPF_LEN	A <- len
-BPF_LD+BPF_IMM		A <- k
-BPF_LD+BPF_MEM		A <- M[k]
-
-
-
-
These instructions load a value into the index register. Note that the - addressing modes are more restrictive than those of the accumulator loads, - but they include BPF_MSH, a hack for efficiently - loading the IP header length. -
- 
BPF_LDX+BPF_W+BPF_IMM	X <- k
-BPF_LDX+BPF_W+BPF_MEM	X <- M[k]
-BPF_LDX+BPF_W+BPF_LEN	X <- len
-BPF_LDX+BPF_B+BPF_MSH	X <- 4*(P[k:1]&0xf)
-
-
-
-
This instruction stores the accumulator into the scratch memory. We do not - need an addressing mode since there is only one possibility for the - destination. -
- 
BPF_ST			M[k] <- A
-
-
-
-
This instruction stores the index register in the scratch memory store. -
- 
BPF_STX			M[k] <- X
-
-
-
-
The alu instructions perform operations between the accumulator and index - register or constant, and store the result back in the accumulator. For - binary operations, a source mode is required - (BPF_K or BPF_X). -
- 
BPF_ALU+BPF_ADD+BPF_K	A <- A + k
-BPF_ALU+BPF_SUB+BPF_K	A <- A - k
-BPF_ALU+BPF_MUL+BPF_K	A <- A * k
-BPF_ALU+BPF_DIV+BPF_K	A <- A / k
-BPF_ALU+BPF_MOD+BPF_K	A <- A % k
-BPF_ALU+BPF_AND+BPF_K	A <- A & k
-BPF_ALU+BPF_OR+BPF_K	A <- A | k
-BPF_ALU+BPF_XOR+BPF_K	A <- A ^ k
-BPF_ALU+BPF_LSH+BPF_K	A <- A << k
-BPF_ALU+BPF_RSH+BPF_K	A <- A >> k
-BPF_ALU+BPF_ADD+BPF_X	A <- A + X
-BPF_ALU+BPF_SUB+BPF_X	A <- A - X
-BPF_ALU+BPF_MUL+BPF_X	A <- A * X
-BPF_ALU+BPF_DIV+BPF_X	A <- A / X
-BPF_ALU+BPF_MOD+BPF_X	A <- A % X
-BPF_ALU+BPF_AND+BPF_X	A <- A & X
-BPF_ALU+BPF_OR+BPF_X	A <- A | X
-BPF_ALU+BPF_XOR+BPF_X	A <- A ^ X
-BPF_ALU+BPF_LSH+BPF_X	A <- A << X
-BPF_ALU+BPF_RSH+BPF_X	A <- A >> X
-BPF_ALU+BPF_NEG		A <- -A
-
-
-
-
The jump instructions alter flow of control. Conditional jumps compare the - accumulator against a constant (BPF_K) or the - index register (BPF_X). If the result is true (or - non-zero), the true branch is taken, otherwise the false branch is taken. - Jump offsets are encoded in 8 bits so the longest jump is 256 - instructions. However, the jump always (BPF_JA) - opcode uses the 32 bit k field as the offset, - allowing arbitrarily distant destinations. All conditionals use unsigned - comparison conventions. -
- 
BPF_JMP+BPF_JA		pc += k
-BPF_JMP+BPF_JGT+BPF_K	pc += (A > k) ? jt : jf
-BPF_JMP+BPF_JGE+BPF_K	pc += (A >= k) ? jt : jf
-BPF_JMP+BPF_JEQ+BPF_K	pc += (A == k) ? jt : jf
-BPF_JMP+BPF_JSET+BPF_K	pc += (A & k) ? jt : jf
-BPF_JMP+BPF_JGT+BPF_X	pc += (A > X) ? jt : jf
-BPF_JMP+BPF_JGE+BPF_X	pc += (A >= X) ? jt : jf
-BPF_JMP+BPF_JEQ+BPF_X	pc += (A == X) ? jt : jf
-BPF_JMP+BPF_JSET+BPF_X	pc += (A & X) ? jt : jf
-
-
-
-
The return instructions terminate the filter program and specify the - amount of packet to accept (i.e., they return the truncation amount). A - return value of zero indicates that the packet should be ignored. The - return value is either a constant (BPF_K) or the - accumulator (BPF_A). -
- 
BPF_RET+BPF_A		accept A bytes
-BPF_RET+BPF_K		accept k bytes
-
-
-
-
The miscellaneous category was created for anything that does not fit into - the above classes, and for any new instructions that might need to be - added. Currently, these are the register transfer instructions that copy - the index register to the accumulator or vice versa. -
- 
BPF_MISC+BPF_TAX	X <- A
-BPF_MISC+BPF_TXA	A <- X
-
-
-
-

The bpf interface provides - the following macros to facilitate array initializers: - (opcode, - operand) and - (opcode, - operand, true_offset, - false_offset).

-
-
-

-

A set of sysctl(8) variables controls the - behaviour of the bpf subsystem

-
-
net.bpf.optimize_writers: - 0
-
Various programs use BPF to send (but not receive) raw packets (cdpd, - lldpd, dhcpd, dhcp relays, etc. are good examples of such programs). They - do not need incoming packets to be send to them. Turning this option on - makes new BPF users to be attached to write-only interface list until - program explicitly specifies read filter via - (). - This removes any performance degradation for high-speed interfaces.
-
net.bpf.stats:
-
Binary interface for retrieving general statistics.
-
net.bpf.zerocopy_enable: - 0
-
Permits zero-copy to be used with net BPF readers. Use with caution.
-
net.bpf.maxinsns: - 512
-
Maximum number of instructions that BPF program can contain. Use - tcpdump(1) -d option to - determine approximate number of instruction for any filter.
-
net.bpf.maxbufsize: - 524288
-
Maximum buffer size to allocate for packets buffer.
-
net.bpf.bufsize: - 4096
-
Default buffer size to allocate for packets buffer.
-
-
-
-

-

The following filter is taken from the Reverse ARP Daemon. It - accepts only Reverse ARP requests.

-
-
struct bpf_insn insns[] = {
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_REVARP, 0, 3),
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ARPOP_REVREQUEST, 0, 1),
-	BPF_STMT(BPF_RET+BPF_K, sizeof(struct ether_arp) +
-		 sizeof(struct ether_header)),
-	BPF_STMT(BPF_RET+BPF_K, 0),
-};
-
-

This filter accepts only IP packets between host 128.3.112.15 and - 128.3.112.35.

-
-
struct bpf_insn insns[] = {
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 8),
-	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 26),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x8003700f, 0, 2),
-	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 30),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x80037023, 3, 4),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x80037023, 0, 3),
-	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 30),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x8003700f, 0, 1),
-	BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
-	BPF_STMT(BPF_RET+BPF_K, 0),
-};
-
-

Finally, this filter returns only TCP finger packets. We must - parse the IP header to reach the TCP header. The - BPF_JSET instruction checks that the IP fragment - offset is 0 so we are sure that we have a TCP header.

-
-
struct bpf_insn insns[] = {
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 10),
-	BPF_STMT(BPF_LD+BPF_B+BPF_ABS, 23),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, IPPROTO_TCP, 0, 8),
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
-	BPF_JUMP(BPF_JMP+BPF_JSET+BPF_K, 0x1fff, 6, 0),
-	BPF_STMT(BPF_LDX+BPF_B+BPF_MSH, 14),
-	BPF_STMT(BPF_LD+BPF_H+BPF_IND, 14),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 79, 2, 0),
-	BPF_STMT(BPF_LD+BPF_H+BPF_IND, 16),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 79, 0, 1),
-	BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
-	BPF_STMT(BPF_RET+BPF_K, 0),
-};
-
-
-
-

-

tcpdump(1), ioctl(2), - kqueue(2), poll(2), - select(2), ng_bpf(4), - bpf(9)

-

McCanne, S. and - Jacobson V., An efficient, - extensible, and portable network monitor.

-
-
-

-

The Enet packet filter was created in 1980 by Mike Accetta and - Rick Rashid at Carnegie-Mellon University. Jeffrey Mogul, at Stanford, - ported the code to BSD and continued its development - from 1983 on. Since then, it has evolved into the Ultrix Packet Filter at - DEC, a STREAMS NIT module under SunOS 4.1, and BPF.

-
-
-

-

Steven McCanne, of Lawrence Berkeley - Laboratory, implemented BPF in Summer 1990. Much of the design is due to - Van Jacobson.

-

Support for zero-copy buffers was added by Robert - N. M. Watson under contract to Seccuris Inc.

-
-
-

-

The read buffer must be of a fixed size (returned by the - BIOCGBLEN ioctl).

-

A file that does not request promiscuous mode may receive - promiscuously received packets as a side effect of another file requesting - this mode on the same hardware interface. This could be fixed in the kernel - with additional processing overhead. However, we favor the model where all - files must assume that the interface is promiscuous, and if so desired, must - utilize a filter to reject foreign packets.

-

The SEESENT, - DIRECTION, and FEEDBACK - settings have been observed to work incorrectly on some interface types, - including those with hardware loopback rather than software loopback, and - point-to-point interfaces. They appear to function correctly on a broad - range of Ethernet-style interfaces.

-
-
- - - - - -
December 10, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/bridge.4 3.html b/static/freebsd/man4/bridge.4 3.html deleted file mode 100644 index 60d81a4a..00000000 --- a/static/freebsd/man4/bridge.4 3.html +++ /dev/null @@ -1,523 +0,0 @@ - - - - - - -
IF_BRIDGE(4)Device Drivers ManualIF_BRIDGE(4)
-
-
-

-

if_bridge — - network bridge device

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device if_bridge
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_bridge_load="YES"
-bridgestp_load="YES"
-
-
-
-

-

The if_bridge driver creates a logical - link between two or more IEEE 802 networks that use the same (or - “similar enough”) framing format. For example, it is possible - to bridge Ethernet and 802.11 networks together, but it is not possible to - bridge Ethernet and Token Ring together.

-

Each if_bridge interface is created at - runtime using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5).

-

When it is created, the - if_bridge interface gets assigned a link (MAC) - address in the range of universally administered addresses reserved for the - FreeBSD Foundation by hashing the host UUID, jail name, and the interface - name. If this fails, a random, locally administered address is generated - instead. This address is guaranteed to be unique - across all - if_bridge interfaces on the local machine. Thus you - can theoretically have two bridges on different machines with the same link - addresses. The address can be changed by assigning the desired link address - using ifconfig(8).

-

If sysctl(8) node - net.link.bridge.inherit_mac has a non-zero value, the - newly created bridge will inherit the MAC address from its first member - instead of choosing a random link-level address. This will provide more - predictable bridge MAC addresses without any additional configuration, but - currently this feature is known to break some L2 protocols, for example - PPPoE that is provided by ng_pppoe(4) and - ppp(8). Currently this feature is considered as - experimental and is turned off by default.

-

A bridge can be used to provide several services, such as a simple - 802.11-to-Ethernet bridge for wireless hosts, or traffic isolation.

-

A bridge works like a switch, forwarding traffic from one - interface to another. Multicast and broadcast packets are always forwarded - to all interfaces that are part of the bridge. For unicast traffic, the - bridge learns which MAC addresses are associated with which interfaces and - will forward the traffic selectively.

-

By default the bridge logs MAC address port flapping to - syslog(3). This behavior can be disabled by setting the - sysctl(8) variable - net.link.bridge.log_mac_flap to - 0.

-

All the bridged member interfaces need to be up in order to pass - network traffic. These can be enabled using ifconfig(8) or - ifconfig_⟨interface⟩="up" - in rc.conf(5).

-

The MTU of the first member interface to be added is used as the - bridge MTU. All additional members will have their MTU changed to match. If - the MTU of a bridge is changed after its creation, the MTU of all member - interfaces is also changed to match.

-

The TOE, TSO, TXCSUM and TXCSUM6 capabilities on all interfaces - added to the bridge are disabled if any of the interfaces do not - support/enable them. The LRO capability is always disabled. All the - capabilities are restored when the interface is removed from the bridge. - Changing capabilities at run-time may cause NIC reinit and a link flap.

-

The bridge supports “monitor mode”, where the - packets are discarded after bpf(4) processing, and are not - processed or forwarded further. This can be used to multiplex the input of - two or more interfaces into a single bpf(4) stream. This - is useful for reconstructing the traffic for network taps that transmit the - RX/TX signals out through two separate interfaces.

-

To allow the host to communicate with bridge members, IP addresses - should be assigned to the if_bridge interface - itself, not to the bridge's member interfaces. Attempting to assign an IP - address to a bridge member interface, or add a member interface with an - assigned IP address to a bridge, will return an - EINVAL (“Invalid argument”) error. For - compatibility with older releases where this was permitted, setting the - sysctl(8) variable - net.link.bridge.member_ifaddrs to 1 will permit this - configuration. This sysctl variable will be removed in - FreeBSD 16.0.

-
-
-

-

if_bridge supports the - AF_INET6 address family on bridge interfaces. The - following rc.conf(5) variable configures an IPv6 - link-local address on bridge0 interface:

-
-
ifconfig_bridge0_ipv6="inet6 auto_linklocal"
-
-

However, the AF_INET6 address family has a - concept of scope zone. Bridging multiple interfaces changes the zone - configuration because multiple links are merged to each other and form a new - single link while the member interfaces still work individually. This means - each member interface still has a separate link-local scope zone and the - if_bridge interface has another single, aggregated - link-local scope zone at the same time. This situation is clearly against - the description "zones of the same scope cannot overlap" in - Section 5, RFC 4007. Although it works in most cases, it can cause some - counterintuitive or undesirable behavior in some edge cases when both, the - if_bridge interface and one of the member - interfaces, have an IPv6 address and applications use both of them.

-

To prevent this situation, if_bridge - checks whether a link-local scoped IPv6 address is configured on a member - interface to be added and the if_bridge interface. - When the if_bridge interface has IPv6 addresses, - IPv6 addresses on the member interface will be automatically removed before - the interface is added.

-

This behavior can be disabled by setting - sysctl(8) variable - net.link.bridge.allow_llz_overlap to - 1.

-

Note that ACCEPT_RTADV and - AUTO_LINKLOCAL interface flags are not enabled by - default on if_bridge interfaces even when - net.inet6.ip6.accept_rtadv and/or - net.inet6.ip6.auto_linklocal is set to - 1.

-
-
-

-

The if_bridge driver implements the Rapid - Spanning Tree Protocol (RSTP or 802.1w) with backwards compatibility with - the legacy Spanning Tree Protocol (STP). Spanning Tree is used to detect and - remove loops in a network topology.

-

RSTP provides faster spanning tree convergence than legacy STP, - the protocol will exchange information with neighbouring switches to quickly - transition to forwarding without creating loops.

-

The code will default to RSTP mode but will downgrade any port - connected to a legacy STP network so is fully backward compatible. A bridge - can be forced to operate in STP mode without rapid state transitions via the - proto command in ifconfig(8).

-

The bridge can log STP port changes to syslog(3) - by setting the net.link.bridge.log_stp node using - sysctl(8).

-
-
-

-

Virtual LANs (VLANs), defined in the IEEE 802.1Q standard, allow - traffic on a bridge to be segregated into separate logical networks which - cannot communicate with each other. For example, two interfaces in VLAN 10 - would be able to communicate with each other, but not with another interface - in VLAN 20.

-

Each VLAN is identified by a number between 1 and 4094 inclusive. - By default, all traffic on the bridge is assigned to "VLAN 0", a - pseudo-VLAN used for historical compatibility. When VLANs are in use on a - bridge, it is recommended to explicitly assign all traffic to a VLAN rather - than using VLAN 0.

-

The bridge implements Independent VLAN Learning (IVL), meaning - that host addresses are learned separately for each VLAN, and the same host - address may exist on several different ports in different VLANs.

-

If a vlan(4) interface is configured on an - interface which is also an if_bridge member - interface, all tagged frames will be processed by the - vlan(4) interface and will not be visible to the bridge. - This configuration is not recommended and may be unsupported in a future - release.

-
-

-

Incoming frames on a member interface may be either tagged or - untagged. Tagged frames contain an 802.1Q header indicating which VLAN the - frame belongs to, while untagged frames do not. When a tagged frame is - received, the frame is automatically assigned to the VLAN in the tag - (subject to any configured VLAN access list), while untagged frames are - assigned to the interface's configured Port VLAN ID (PVID), or to VLAN 0 if - no PVID is configured.

-
-
-

-

An interface's PVID may be configured using the - ifconfig(8) ifuntagged - command:

-
-
ifconfig bridge0 ifuntagged ix0 10
-
-

Or by using the untagged option to - addm:

-
-
ifconfig bridge0 addm ix0 untagged 10
-
-

This will assign all untagged traffic received on the interface to - the specified VLAN, and any traffic transmitted on the interface in this - VLAN will have its VLAN tag (if present) removed. Conversely, any traffic - transmitted on the interface in a different VLAN will have a tag added, to - allow the remote system to assign the traffic to the appropriate VLAN.

-
-
-

-

Sometimes it is useful to allow the host itself to communicate in - a VLAN, for example to provide routing to other hosts in the VLAN. To do - this, create a vlan(4) interface on top of the - if_bridge interface with the appropriate VLAN tag. - For example, to allow the host to communicate in VLAN 10:

-
-
ifconfig bridge0.10 create inet6 2001:db8::1/64
-
-
-
-

-

For historical reasons, the default - if_bridge configuration allows all interfaces to - send tagged traffic for any VLAN, meaning that VLANs do not provide security - separation. To restrict which interfaces may communicate in which VLANs, - enable VLAN filtering on the bridge:

-
-
ifconfig bridge0 vlanfilter
-
-

This has the following effects on bridge members:

-
    -
  • No untagged frames will be accepted from a member interface unless the - interface has a PVID configured.
    • -
  • No tagged frames will be accepted from a member interface unless the VLAN - identifier is present in the interface's VLAN access list.
    • -
  • Frames with stacked tags (Q-in-Q) will not be accepted from a member - interface unless the qinq option (see below) has - been configured for that member.
    • -
-

To configure the VLAN access list, use the - ifconfig(8) iftagged, - +iftagged or -iftagged - commands. For example, to allow an interface to communicate in VLANs 10, 20, - and any VLAN from 100 to 199:

-
-
ifconfig bridge0 iftagged ix0 10,20,100-199
-
-
-
-

-

IEEE 802.1ad, also called Q-in-Q or “tag stacking”, - allows a single Ethernet frame to contain multiple tags. This allows one - Ethernet network to transport traffic between endpoints using its own VLAN - tags without interfering with any pre-existing tags, and is often used in - service provider networks to provide “virtual wire” Ethernet - services.

-

When VLAN filtering is enabled, if_bridge - does not permit member interfaces to send Q-in-Q frames, because in certain - configuration this allows “VLAN-hopping” attacks on the - bridge. For example, consider a bridge with port ix0 configured as a tagged - port in VLAN 10, and port ix1 configured as untagged in VLAN 10 and tagged - in VLAN 20. If ix0 is allowed to send Q-in-Q frames, then it can send a - frame with two tags: one for VLAN 10, followed by one for VLAN 20. When the - bridge forwards the frame to ix1, it will strip the VLAN tag for VLAN 10, - then forward the frame to ix1 with the tag for VLAN 20 intact, effectively - allowing ix1 to send traffic on VLAN 20 even though the bridge configuration - should not permit that.

-

To permit an interface to send Q-in-Q frames, set the - ifconfig(8) qinq flag on the - interface. This is only required on the interface which will send Q-in-Q - frames, not the interface receiving the frames.

-

Alternatively, set the defqinq flag on the - bridge itself to enable Q-in-Q for all newly-added interfaces by - default.

-
-
-
-

-

Packet filtering can be used with any firewall package that hooks - in via the pfil(9) framework. When filtering is enabled, - bridged packets will pass through the filter inbound on the originating - interface, on the bridge interface and outbound on the appropriate - interfaces. Either stage can be disabled. The filtering behavior can be - controlled using sysctl(8):

-
-
net.link.bridge.pfil_onlyip
-
Controls the handling of non-IP packets which are not passed to - pfil(9). Set to 1 to only allow - IP packets to pass (subject to firewall rules), set to - 0 to unconditionally pass all non-IP Ethernet - frames.
-
net.link.bridge.pfil_member
-
Set to 1 to enable filtering on the incoming and - outgoing member interfaces, set to 0 to disable - it.
-
net.link.bridge.pfil_bridge
-
Set to 1 to enable filtering on the bridge - interface, set to 0 to disable it.
-
net.link.bridge.pfil_local_phys
-
Set to 1 to additionally filter on the physical - interface for locally destined packets. Set to 0 - to disable this feature.
-
net.link.bridge.ipfw
-
Set to 1 to enable layer2 filtering with - ipfirewall(4), set to 0 to - disable it. This needs to be enabled for dummynet(4) - support. When ipfw is enabled, - pfil_bridge and pfil_member - will be disabled so that IPFW is not run twice; these can be re-enabled if - desired.
-
net.link.bridge.ipfw_arp
-
Set to 1 to enable layer2 ARP filtering with - ipfirewall(4), set to 0 to - disable it. Requires ipfw to be enabled.
-
-

ARP and REVARP packets are forwarded without being filtered and - others that are not IP nor IPv6 packets are not forwarded when - pfil_onlyip is enabled. IPFW can filter Ethernet types - using mac-type so all packets are passed to the - filter for processing.

-

The packets originating from the bridging host will be seen by the - filter on the interface that is looked up in the routing table.

-

The packets destined to the bridging host will be seen by the - filter on the interface with the MAC address equal to the packet's - destination MAC. There are situations when some of the bridge members are - sharing the same MAC address (for example the vlan(4) - interfaces: they are currently sharing the MAC address of the parent - physical interface). It is not possible to distinguish between these - interfaces using their MAC address, excluding the case when the packet's - destination MAC address is equal to the MAC address of the interface on - which the packet was entered to the system. In this case the filter will see - the incoming packet on this interface. In all other cases the interface seen - by the packet filter is chosen from the list of bridge members with the same - MAC address and the result strongly depends on the member addition sequence - and the actual implementation of if_bridge. It is - not recommended to rely on the order chosen by the current - if_bridge implementation since it may change in the - future.

-

The previous paragraph is best illustrated with the following - pictures. Let

-
    -
  • the MAC address of the incoming packet's destination is - nn:nn:nn:nn:nn:nn,
    • -
  • the interface on which packet entered the system is - ifX,
    • -
  • ifX MAC address is - xx:xx:xx:xx:xx:xx,
    • -
  • there are possibly other bridge members with the same MAC address - xx:xx:xx:xx:xx:xx,
    • -
  • the bridge has more than one interface that are sharing the same MAC - address yy:yy:yy:yy:yy:yy; we will call them - vlanY1, vlanY2, etc.
    • -
-

If the MAC address nn:nn:nn:nn:nn:nn is - equal to xx:xx:xx:xx:xx:xx the filter will see the - packet on interface ifX no matter if there are any - other bridge members carrying the same MAC address. But if the MAC address - nn:nn:nn:nn:nn:nn is equal to - yy:yy:yy:yy:yy:yy then the interface that will be - seen by the filter is one of the vlanYn. It is not - possible to predict the name of the actual interface without the knowledge - of the system state and the if_bridge implementation - details.

-

This problem arises for any bridge members that are sharing the - same MAC address, not only to the vlan(4) ones: they were - taken just as an example of such a situation. So if one wants to filter the - locally destined packets based on their interface name, one should be aware - of this implication. The described situation will appear at least on the - filtering bridges that are doing IP-forwarding; in some of such cases it is - better to assign the IP address only to the - if_bridge interface and not to the bridge members. - Enabling net.link.bridge.pfil_local_phys will let you - do the additional filtering on the physical interface.

-
-
-

-

netmap(4) applications may open a bridge - interface in emulated mode. The netmap application will receive all packets - which arrive from member interfaces. In particular, packets which would - otherwise be forwarded to another member interface will be received by the - netmap application.

-

When the netmap(4) application transmits a - packet to the host stack via the bridge interface, - if_bridge receive it and attempts to determine its - ‘source’ interface by looking up the - source MAC address in the interface's learning tables. Packets for which no - matching source interface is found are dropped and the input error counter - is incremented. If a matching source interface is found, - if_bridge treats the packet as though it was - received from the corresponding interface and handles it normally without - passing the packet back to netmap(4).

-
-
-

-

The following when placed in the file - /etc/rc.conf will cause a bridge called - “bridge0” to be created, and will add - the interfaces “wlan0” and - “fxp0” to the bridge, and then enable - packet forwarding. Such a configuration could be used to implement a simple - 802.11-to-Ethernet bridge (assuming the 802.11 interface is in ad-hoc - mode).

-
-
cloned_interfaces="bridge0"
-ifconfig_bridge0="addm wlan0 addm fxp0 up"
-
-

For the bridge to forward packets, all member interfaces and the - bridge need to be up. The above example would also require:

-
-
create_args_wlan0="wlanmode hostap"
-ifconfig_wlan0="up ssid my_ap mode 11g"
-ifconfig_fxp0="up"
-
-

The following will cause a bridge to be created with two VLANs, 10 - and 20, where the “em” interfaces can - only communicate in their assigned VLANs, while - “ix0” is a trunk port which can - communicate in either VLAN:

-
-
cloned_interfaces="bridge0"
-ifconfig_bridge0="vlanfilter \
-	addm em0 untagged 10 \
-	addm em1 untagged 10 \
-	addm em2 untagged 20 \
-	addm em3 untagged 20 \
-	addm ix0 tagged 10,20"
-ifconfig_em0="up"
-ifconfig_em1="up"
-ifconfig_em2="up"
-ifconfig_em3="up"
-ifconfig_ix0="up"
-
-

The previous example could be extended to allow the host to - communicate in VLANs 10 and 20:

-
-
vlans_bridge0="10 20"
-ifconfig_bridge0_10_ipv6="inet6 2001:db8:0:10::1/64"
-ifconfig_bridge0_20_ipv6="inet6 2001:db8:0:20::1/64"
-
-

Consider a system with two 4-port Ethernet boards. The following - will cause a bridge consisting of all 8 ports with Rapid Spanning Tree - enabled to be created:

-
-
ifconfig bridge0 create
-ifconfig bridge0 \
-    addm fxp0 stp fxp0 \
-    addm fxp1 stp fxp1 \
-    addm fxp2 stp fxp2 \
-    addm fxp3 stp fxp3 \
-    addm fxp4 stp fxp4 \
-    addm fxp5 stp fxp5 \
-    addm fxp6 stp fxp6 \
-    addm fxp7 stp fxp7 \
-    up
-
-

The bridge can be used as a regular host interface at the same - time as bridging between its member ports. In this example, the bridge - connects em0 and em1, and will receive its IP address through DHCP:

-
-
cloned_interfaces="bridge0"
-ifconfig_bridge0="addm em0 addm em1 DHCP"
-ifconfig_em0="up"
-ifconfig_em1="up"
-
-

The bridge can tunnel Ethernet across an IP internet using the - EtherIP protocol. This can be combined with ipsec(4) to - provide an encrypted connection. Create a gif(4) interface - and set the local and remote IP addresses for the tunnel, these are reversed - on the remote bridge.

-
-
ifconfig gif0 create
-ifconfig gif0 tunnel 1.2.3.4 5.6.7.8 up
-ifconfig bridge0 create
-ifconfig bridge0 addm fxp0 addm gif0 up
-
-
-
-

-

gif(4), ipf(4), - ipfw(4), netmap(4), - pf(4), vlan(4), - ifconfig(8)

-
-
-

-

The if_bridge driver first appeared in - FreeBSD 6.0.

-
-
-

-

The bridge driver was originally written - by Jason L. Wright - <jason@thought.net> - as part of an undergraduate independent study at the University of North - Carolina at Greensboro.

-

This version of the if_bridge driver has - been heavily modified from the original version by Jason R. - Thorpe - <thorpej@wasabisystems.com>.

-

Rapid Spanning Tree Protocol (RSTP) support was added by - Andrew Thompson - <thompsa@FreeBSD.org>.

-
-
-

-

The if_bridge driver currently supports - only Ethernet and Ethernet-like (e.g., 802.11) network devices, which can be - configured with the same MTU size as the bridge device.

-
-
- - - - - -
October 13, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/bwi.4 3.html b/static/freebsd/man4/bwi.4 3.html deleted file mode 100644 index 6de36a91..00000000 --- a/static/freebsd/man4/bwi.4 3.html +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - -
BWI(4)Device Drivers ManualBWI(4)
-
-
-

-

bwi — Broadcom - BCM43xx IEEE 802.11b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device bwi -
-device wlan -
-device wlan_amrr -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_bwi_load="YES"
-
-
-
-

-

The bwi driver provides support for - Broadcom BCM43xx based PCI/CardBus network adapters.

-

It supports station and - monitor mode operation. Only one virtual interface - may be configured at any time. For more information on configuring this - device, see ifconfig(8).

-

This driver requires firmware to be loaded before it will work. - The ports/net/bwi-firmware-kmod port needs to be - installed before ifconfig(8) will work.

-
-
-

-

The bwi driver supports Broadcom BCM43xx - based wireless devices, including:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Apple Airport ExtremeBCM4306PCIb/g
Apple Airport ExtremeBCM4318PCIb/g
ASUS WL-100gBCM4306CardBusb/g
ASUS WL-138gBCM4318PCIb/g
Buffalo WLI-CB-G54SBCM4318CardBusb/g
Buffalo WLI-PCI-G54SBCM4306PCIb/g
Compaq R4035 onboardBCM4306PCIb/g
Dell Wireless 1390BCM4311Mini PCIb/g
Dell Wireless 1470BCM4318Mini PCIb/g
Dell Truemobile 1300 r2BCM4306Mini PCIb/g
Dell Truemobile 1400BCM4309Mini PCIb/g
HP nx6125BCM4319PCIb/g
Linksys WPC54G Ver 3BCM4318CardBusb/g
Linksys WPC54GS Ver 2BCM4318CardBusb/g
TRENDnet TEW-401PCplusBCM4306CardBusb/g
US Robotics 5411BCM4318CardBusb/g
-

The bwi driver uses the older v3 version - of Broadcom's firmware. While this older firmware does support most BCM43xx - parts, the bwn(4) driver works better for the newer chips - it supports. You must use the bwi driver if you are - using older Broadcom chipsets (BCM4301, BCM4303 and BCM4306 rev 2). The v4 - version of the firmware that bwn(4) uses does not support - these chips.

-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
ifconfig wlan create wlandev bwi0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - “my_net”:

-

-
ifconfig wlan create wlandev bwi0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev bwi0 ssid my_net \
-        wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-

arp(4), cardbus(4), - intro(4), pci(4), - wlan(4), wlan_amrr(4), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

The bwi driver first appeared in - FreeBSD 8.0.

-
-
-

-

The bwi driver was written for - DragonFly by Sepherosa - Ziehau and subsequently ported to - FreeBSD.

-
-
-

-

Some card based on the BCM4306 and BCM4309 chips do not work - properly on channel 1, 2 and 3.

-
-
- - - - - -
August 7, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/bwn.4 3.html b/static/freebsd/man4/bwn.4 3.html deleted file mode 100644 index e00ce0ad..00000000 --- a/static/freebsd/man4/bwn.4 3.html +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - -
BWN(4)Device Drivers ManualBWN(4)
-
-
-

-

bwn — Broadcom - BCM43xx SoftMAC IEEE 802.11 wireless network driver

-
-
-

-

To compile this driver into the kernel, add the following lines to - the kernel configuration file:

-
device bwn -
-device bhnd -
-device bhndb -
-device bhndb_pci -
-device bcma -
-device siba -
-device gpio -
-device wlan -
-device wlan_amrr -
-device firmware
-

To load the driver as a module at boot, add the following lines to - loader.conf(5):

-
-
if_bwn_load="YES"
-
-
-
-

-

The bwn driver provides support for - Broadcom BCM43xx based PCI/CardBus network adapters.

-

It supports station and - monitor mode operation. Only one virtual interface - may be configured at any time. For more information on configuring this - device, see ifconfig(8).

-

This driver requires firmware to be loaded before it will work. - The ports/net/bwn-firmware-kmod port needs to be - installed before ifconfig(8) will work. In most cases the - bwn_v4_ucode kernel module from the port should be - used. However, if an LP (low power) PHY is being used, the - bwn_v4_lp_ucode module should be used.

-
-
-

-

The bwn driver supports Broadcom BCM43xx - based wireless devices, including:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Apple Airport ExtremeBCM4318PCIb/g
ASUS WL-138gBCM4318PCIb/g
Buffalo WLI-CB-G54SBCM4318CardBusb/g
Dell Wireless 1390BCM4311Mini PCIb/g
Dell Wireless 1470BCM4318Mini PCIb/g
Dell Truemobile 1400BCM4309Mini PCIb/g
HP Compaq 6715bBCM4312PCIb/g
HP nx6125BCM4319PCIb/g
Linksys WPC54G Ver 3BCM4318CardBusb/g
Linksys WPC54GS Ver 2BCM4318CardBusb/g
US Robotics 5411BCM4318CardBusb/g
-

Users of older Broadcom chipsets (BCM4301, BCM4303 and BCM4306 rev - 2) must use bwi(4) because the v4 version of the firmware - does not support these chips. The newer firmware is too big to fit into - these old chips.

-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
ifconfig wlan create wlandev bwn0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - “my_net”:

-

-
ifconfig wlan create wlandev bwn0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev bwn0 ssid my_net \
-        wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.bwn.usedma
-
This tunable enables DMA operations on the hardware. If the value is 0, - PIO mode would be used. The default value is 1.
-
-
-
-

-

arp(4), bcma(4), - bhnd(4), bhndb(4), - bwi(4), cardbus(4), - intro(4), pci(4), - siba(4), wlan(4), - wlan_amrr(4), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The bwn driver first appeared in - FreeBSD 8.1. The driver was updated to support the - common Broadcom bhnd(4) bus interface in - FreeBSD 12.0.

-
-
-

-

The bwn driver was written by - Weongyo Jeong - <weongyo@FreeBSD.org>. - Support for bhnd(4) was added by Landon - Fuller - <landonf@FreeBSD.org>.

-
-
-

-

Some LP PHY devices have DMA operation problems that in that case - try to use PIO mode.

-
-
- - - - - -
December 16, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/bxe.4 3.html b/static/freebsd/man4/bxe.4 3.html deleted file mode 100644 index 1b69f1fa..00000000 --- a/static/freebsd/man4/bxe.4 3.html +++ /dev/null @@ -1,284 +0,0 @@ - - - - - - -
BXE(4)Device Drivers ManualBXE(4)
-
-
-

-

bxe — QLogic - NetXtreme II Ethernet 10Gb PCIe adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device bxe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_bxe_load="YES"
-
-
-
-

-

The bxe driver provides support for PCIe - 10Gb Ethernet adapters based on the QLogic NetXtreme II family of 10Gb - chips. The driver supports Jumbo Frames, VLAN tagging, checksum offload - (IPv4, TCP, UDP, IPv6-TCP, IPv6-UDP), MSI-X interrupts, TCP Segmentation - Offload (TSO), Large Receive Offload (LRO), and Receive Side Scaling - (RSS).

-
-
-

-

The bxe driver provides support for - various NICs based on the QLogic NetXtreme II family of 10Gb Ethernet - controller chips, including the following:

-

-
    -
  • QLogic NetXtreme II BCM57710 10Gb
    • -
  • QLogic NetXtreme II BCM57711 10Gb
    • -
  • QLogic NetXtreme II BCM57711E 10Gb
    • -
  • QLogic NetXtreme II BCM57712 10Gb
    • -
  • QLogic NetXtreme II BCM57712-MF 10Gb
    • -
  • QLogic NetXtreme II BCM57800 10Gb
    • -
  • QLogic NetXtreme II BCM57800-MF 10Gb
    • -
  • QLogic NetXtreme II BCM57810 10Gb
    • -
  • QLogic NetXtreme II BCM57810-MF 10Gb
    • -
  • QLogic NetXtreme II BCM57840 10Gb / 20Gb
    • -
  • QLogic NetXtreme II BCM57840-MF 10Gb
    • -
-
-
-

-

There a number of configuration parameters that can be set to - tweak the driver's behavior. These parameters can be set via the - loader.conf(5) file to take effect during the next system - boot. The following parameters affect ALL instances of the driver.

-
-
hw.bxe.debug
-
DEFAULT = 0 -
- Sets the default logging level of the driver. See the Diagnostics and - Debugging section below for more details.
-
hw.bxe.interrupt_mode
-
DEFAULT = 2 -
- Sets the default interrupt mode: 0=IRQ, 1=MSI, 2=MSIX. If set to MSIX and - allocation fails, the driver will roll back and attempt MSI allocation. If - MSI allocation fails, the driver will roll back and attempt fixed level - IRQ allocation. If IRQ allocation fails, then the driver load fails. With - MSI/MSIX, the driver attempts to allocate a vector for each queue in - addition to one more for default processing.
-
hw.bxe.queue_count
-
DEFAULT = 4 -
- Sets the default number of fast path packet processing queues. Note that one - MSI/MSIX interrupt vector is allocated per-queue.
-
hw.bxe.max_rx_bufs
-
DEFAULT = 0 -
- Sets the maximum number of receive buffers to allocate per-queue. Zero(0) - means to allocate a receive buffer for every buffer descriptor. By default - this equates to 4080 buffers per-queue which is the maximum value for this - config parameter.
-
hw.bxe.hc_rx_ticks
-
DEFAULT = 25 -
- Sets the number of ticks for host interrupt coalescing in the receive - path.
-
hw.bxe.hc_tx_ticks
-
DEFAULT = 50 -
- Sets the number of ticks for host interrupt coalescing in the transmit - path.
-
hw.bxe.rx_budget
-
DEFAULT = 0xffffffff -
- Sets the maximum number of receive packets to process in an interrupt. If - the budget is reached then the remaining/pending packets will be processed - in a scheduled taskqueue.
-
hw.bxe.max_aggregation_size
-
DEFAULT = 32768 -
- Sets the maximum LRO aggregation byte size. The higher the value the more - packets the hardware will aggregate. Maximum is 65K.
-
hw.bxe.mrrs
-
DEFAULT = -1 -
- Sets the PCI MRRS: -1=Auto, 0=128B, 1=256B, 2=512B, 3=1KB
-
hw.bxe.autogreeen
-
DEFAULT = 0 -
- Set AutoGrEEEN: 0=HW_DEFAULT, 1=FORCE_ON, 2=FORCE_OFF
-
hw.bxe.udp_rss
-
DEFAULT = 0 -
- Enable/Disable 4-tuple RSS for UDP: 0=DISABLED, 1=ENABLED
-
-

Special care must be taken when modifying the number of queues and - receive buffers. FreeBSD imposes a limit on the - maximum number of mbuf(9) allocations. If buffer - allocations fail, the interface initialization will fail and the interface - will not be usable. The driver does not make a best effort for buffer - allocations. It is an all or nothing effort.

-

You can tweak the mbuf(9) allocation limit using - sysctl(8) and view the current usage with - netstat(1) as follows:

-
-
# netstat -m
-# sysctl kern.ipc.nmbclusters
-# sysctl kern.ipc.nmbclusters=<#>
-
-

There are additional configuration parameters that can be set on a - per-instance basis to dynamically override the default configuration. The - '#' below must be replaced with the driver instance / interface unit - number:

-
-
dev.bxe.#.debug
-
DEFAULT = 0 -
- Sets the default logging level of the driver instance. See - hw.bxe.debug above and the Diagnostics and Debugging - section below for more details.
-
dev.bxe.#.rx_budget
-
DEFAULT = 0xffffffff -
- Sets the maximum number of receive packets to process in an interrupt for - the driver instance. See hw.bxe.rx_budget above for - more details.
-
-

Additional items can be configured using - ifconfig(8):

-
-
MTU - Maximum Transmission Unit
-
DEFAULT = 1500 -
- RANGE = 46-9184 -
- # ifconfig bxe# mtu <n>
-
Promiscuous Mode
-
DEFAULT = OFF -
- # ifconfig bxe# [ promisc | -promisc ]
-
Rx/Tx Checksum Offload
-
DEFAULT = RX/TX CSUM ON -
- Note that the Rx and Tx settings are not independent. -
- # ifconfig bxe# [ rxcsum | -rxcsum | txcsum | -txcsum ]
-
TSO - TCP Segmentation Offload
-
DEFAULT = ON -
- # ifconfig bxe# [ tso | -tso | tso6 | -tso6 ]
-
LRO - TCP Large Receive Offload
-
DEFAULT = ON -
- # ifconfig bxe# [ lro | -lro ]
-
-
-
-

-

There are many statistics exposed by bxe - via sysctl(8).

-

To dump the default driver configuration:

-
-
# sysctl -a | grep hw.bxe
-
-

To dump every instance's configuration and detailed - statistics:

-
-
# sysctl -a | grep dev.bxe
-
-

To dump information for a single instance (replace the '#' with - the driver instance / interface unit number):

-
-
# sysctl -a | grep dev.bxe.#
-
-

To dump information for all the queues of a single instance:

-
-
# sysctl -a | grep dev.bxe.#.queue
-
-

To dump information for a single queue of a single instance - (replace the additional '#' with the queue number):

-
-
# sysctl -a | grep dev.bxe.#.queue.#
-
-

The bxe driver has the ability to dump a - ton of debug messages to the system log. The default level of logging can be - set with the hw.bxe.debug sysctl(8). - Take care with this setting as it can result in too many logs being dumped. - Since this parameter is the default one, it affects every instance and will - dramatically change the timing in the driver. A better alternative to aid in - debugging is to dynamically change the debug level of a specific instance - with the dev.bxe.#.debug sysctl(8). - This allows you to turn on/off logging of various debug groups - on-the-fly.

-

The different debug groups that can be toggled are:

-
-
DBG_LOAD   0x00000001 /* load and unload    */
-DBG_INTR   0x00000002 /* interrupt handling */
-DBG_SP     0x00000004 /* slowpath handling  */
-DBG_STATS  0x00000008 /* stats updates      */
-DBG_TX     0x00000010 /* packet transmit    */
-DBG_RX     0x00000020 /* packet receive     */
-DBG_PHY    0x00000040 /* phy/link handling  */
-DBG_IOCTL  0x00000080 /* ioctl handling     */
-DBG_MBUF   0x00000100 /* dumping mbuf info  */
-DBG_REGS   0x00000200 /* register access    */
-DBG_LRO    0x00000400 /* lro processing     */
-DBG_ASSERT 0x80000000 /* debug assert       */
-DBG_ALL    0xFFFFFFFF /* flying monkeys     */
-
-

For example, to debug an issue in the receive path on bxe0:

-
-
# sysctl dev.bxe.0.debug=0x22
-
-

When finished turn the logging back off:

-
-
# sysctl dev.bxe.0.debug=0
-
-
-
-

-

For support questions please contact your QLogic approved reseller - or QLogic Technical Support at - http://support.qlogic.com, or by E-mail at - <support@qlogic.com>.

-
-
-

-

netstat(1), altq(4), - arp(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The bxe device driver first appeared in - FreeBSD 9.0.

-
-
-

-

The bxe driver was written by - Eric Davis - <edavis@broadcom.com>, -
- David Christensen - <davidch@broadcom.com>, - and -
- Gary Zambrano - <zambrano@broadcom.com>.

-
-
- - - - - -
April 29, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/bytgpio.4 3.html b/static/freebsd/man4/bytgpio.4 3.html deleted file mode 100644 index c8333deb..00000000 --- a/static/freebsd/man4/bytgpio.4 3.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
BYTGPIO(4)Device Drivers ManualBYTGPIO(4)
-
-
-

-

bytgpio — Intel - Bay Trail SoC GPIO controller

-
-
-

-

device gpio -
- device bytgpio

-
-
-

-

The bytgpio is a driver for GPIO - controller that can be found in Intel's Bay Trail SoC family.

-

Bay Trail SoC has three banks of GPIO pins exposed to userland as - /dev/gpiocN, where N is 0, 1, and 2. Pins in each bank are pre-named to - match names on boards schematics: GPIO_S0_SCnn, GPIO_S0_NCnn, and - GPIO_S5_nn.

-
-
-

-

gpio(3), gpio(4), - gpioctl(8)

-
-
-

-

The bytgpio manual page first appeared in - FreeBSD 11.1.

-
-
-

-

This driver and man page was written by Oleksandr - Tymoshenko - <gonzo@FreeBSD.org>.

-
-
- - - - - -
May 9, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/capsicum.4 3.html b/static/freebsd/man4/capsicum.4 3.html deleted file mode 100644 index 3292827c..00000000 --- a/static/freebsd/man4/capsicum.4 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
CAPSICUM(4)Device Drivers ManualCAPSICUM(4)
-
-
-

-

Capsicum — - lightweight OS capability and sandbox framework

-
-
-

-

options CAPABILITY_MODE -
- options CAPABILITIES

-
-
-

-

Capsicum is a lightweight OS capability - and sandbox framework implementing a hybrid capability system model. - Capsicum is designed to blend capabilities with - UNIX. This approach achieves many of the benefits of least-privilege - operation, while preserving existing UNIX APIs and performance, and presents - application authors with an adoption path for capability-oriented - design.

-

Capabilities are unforgeable tokens of authority that can be - delegated and must be presented to perform an action. - Capsicum makes file descriptors into - capabilities.

-

Capsicum can be used for application and - library compartmentalisation, the decomposition of larger bodies of software - into isolated (sandboxed) components in order to implement security policies - and limit the impact of software vulnerabilities.

-

Capsicum provides two core kernel - primitives:

-
-
capability mode
-
A process mode, entered by invoking cap_enter(2), in - which access to global OS namespaces (such as the file system and PID - namespaces) is restricted; only explicitly delegated rights, referenced by - memory mappings or file descriptors, may be used. Once set, the flag is - inherited by future children processes, and may not be cleared. -

Access to system calls in capability mode is restricted: some - system calls requiring global namespace access are unavailable, while - others are constrained. For instance, sysctl(2) can be - used to query process-local information such as address space layout, - but also to monitor a system's network connections. - sysctl(2) is constrained by explicitly marking - ≈60 of over 15000 parameters as permitted in capability mode; all - others are denied.

-

The system calls which require constraints are - sysctl(2), shm_open(2) (which is - permitted to create anonymous memory objects but not named ones) and the - openat(2) family of system calls. The - openat(2) calls already accept a file descriptor - argument as the directory to perform the open(2), - rename(2), etc. relative to; in capability mode the - openat(2) family of system calls are constrained so - that they can only operate on objects “under” the provided - file descriptor.

-
-
capabilities
-
Limit operations that can be called on file descriptors. For example, a - file descriptor returned by open(2) may be refined using - cap_rights_limit(2) so that only - read(2) and write(2) can be called, - but not fchmod(2). The complete list of the capability - rights can be found in the rights(4) manual page.
-
-

In some cases, Capsicum requires use of - alternatives to traditional POSIX APIs in order to name objects using - capabilities rather than global namespaces:

-
-
process descriptors
-
File descriptors representing processes, allowing parent processes to - manage child processes without requiring access to the PID namespace; - described in greater detail in procdesc(4).
-
anonymous shared memory
-
An extension to the POSIX shared memory API to support anonymous swap - objects associated with file descriptors; described in greater detail in - shm_open(2).
-
-

In some cases, Capsicum limits the valid - values of some parameters to traditional APIs in order to restrict access to - global namespaces:

-
-
process IDs
-
Processes can only act upon their own process ID with syscalls such as - cpuset_setaffinity(2).
-
-

FreeBSD provides some additional - functionality to support application sandboxing that is not part of - Capsicum itself:

-
-
capsicum_helpers(3)
-
A set of a inline functions which simplify modifying programs to use - Capsicum.
-
libcasper(3)
-
A library that provides services for sandboxed applications, such as - operating on files specified on a command line or establishing network - connections.
-
-
-
-

-

cap_enter(2), - cap_fcntls_limit(2), cap_getmode(2), - cap_ioctls_limit(2), - cap_rights_limit(2), fchmod(2), - open(2), pdfork(2), - pdgetpid(2), pdkill(2), - pdwait4(2), read(2), - shm_open(2), write(2), - cap_rights_get(3), capsicum_helpers(3), - libcasper(3), procdesc(4)

-
-
-

-

Capsicum first appeared in - FreeBSD 9.0, and was developed at the University of - Cambridge.

-
-
-

-

Capsicum was developed by - Robert Watson - <rwatson@FreeBSD.org> - and Jonathan Anderson - <jonathan@FreeBSD.org> - at the University of Cambridge, and Ben Laurie - <benl@FreeBSD.org> - and Kris Kennaway - <kris@FreeBSD.org> at - Google, Inc., and Pawel Jakub Dawidek - <pawel@dawidek.net>. - Portions of this manual page are drawn from - Robert N. M. Watson, - Jonathan Anderson, Ben - Laurie, and Kris Kennaway, - Capsicum: practical capabilities for UNIX, - USENIX Security Symposium, August - 2010, DOI: - 10.5555/1929820.1929824.

-
-
- - - - - -
January 23, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/cardbus.4 4.html b/static/freebsd/man4/cardbus.4 4.html deleted file mode 100644 index 2f305c3d..00000000 --- a/static/freebsd/man4/cardbus.4 4.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
CARDBUS(4)Device Drivers ManualCARDBUS(4)
-
-
-

-

cardbus — CardBus - bus driver

-
-
-

-

device cardbus

-
-
-

-

The cardbus driver implements the CardBus - bus. The cardbus driver supports all cardbus bridges - in the system.

-
-
-

-

The driver supports the following tunable parameters, which may be - added to /boot/loader.conf or set via the - sysctl(8) command:

-
-
-
Non-zero values cause more verbose information to be printed when a 32-bit - CardBus card is inserted or removed.
-
-
Non-zero value causes the CIS parsing of the 32-bit CardBus card to be - much more verbose and include a complete CIS dump.
-
-
-
-

-

pccbb(4)

-
-
- - - - - -
July 9, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/carp.4 3.html b/static/freebsd/man4/carp.4 3.html deleted file mode 100644 index 73085df5..00000000 --- a/static/freebsd/man4/carp.4 3.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - -
CARP(4)Device Drivers ManualCARP(4)
-
-
-

-

carp — Common - Address Redundancy Protocol

-
-
-

-

device carp

-
-
-

-

The CARP allows multiple hosts on the same local network to share - a set of IPv4 and/or IPv6 addresses. Its primary purpose is to ensure that - these addresses are always available.

-

To use carp, the administrator needs to - configure at a minimum a common virtual host ID (vhid), and attach at least - one IP address to this vhid on each machine which is to take part in the - virtual group. Additional parameters can also be set on a per-vhid basis: - advbase and advskew, which - are used to control how frequently the host sends advertisements when it is - the master for a virtual host, and pass which is - used to authenticate carp advertisements. The - advbase parameter stands for “advertisement - base”. It is measured in seconds and specifies the base of the - advertisement interval. The advskew parameter stands - for “advertisement skew”. It is measured in 1/256 of seconds. - It is added to the base advertisement interval to make one host advertise a - bit slower that the other does. Both advbase and - advskew are put inside CARP advertisements. These - values can be configured using ifconfig(8).

-

CARP defaults to using multicast messages, but can be configured - to unicast announcements to peers using the peer and - peer6 parameters. Default addresses can be restored - using mcast and mcast6. Note - that TTL verification is disabled if the peer address is not a multicast - address. These values can be configured using - ifconfig(8).

-

carp(4) can be configured to use either the - non-standard CARP protocol, or VRRPv3 (RFC 5798). Use the - carpver parameter to select either 2 (CARP) or 3 - (VRRPv3). VRRPv3 specific parameters can be configured using the - vrrpprio and vrrpinterval - parameters.

-

CARP virtual hosts can be configured on multicast-capable - interfaces: Ethernet, layer 2 VLAN, FDDI and Token Ring. An arbitrary number - of virtual host IDs can be configured on an interface. An arbitrary number - of IPv4 or IPv6 addresses can be attached to a particular vhid. It is - important that all hosts participating in a vhid have the same list of - prefixes configured on the vhid, since all the prefixes are included in the - cryptographic checksum supplied in each advertisement. Multiple vhids - running on one interface participate in master/backup elections - independently.

-

Additionally, there are a number of global parameters which can be - set using sysctl(8):

-
-
net.inet.carp.allow
-
Allow carp operation. When disabled, virtual hosts - remain in initial state, neither sending nor receiving announcements or - traffic. Enabled by default.
-
net.inet.carp.preempt
-
Allow virtual hosts to preempt each other. When enabled, a vhid in a - backup state would preempt a master that is announcing itself with a lower - advskew. Disabled by default.
-
net.inet.carp.dscp
-
DSCP value in carp packet. Valid Values are 0 to 63. A value of 4 is - equivalent to the old standard of TOS LOW_DELAY. TOS values were - deprecated and replaced by DSCP in 1998. The default value is 56 - (CS7/Network Control).
-
net.inet.carp.log
-
Determines what events relating to carp vhids are - logged. A value of 0 disables any logging. A value of 1 enables logging - state changes of carp vhids. Values above 1 enable - logging of bad carp packets. The default value is - 1.
-
net.inet.carp.demotion
-
This value shows the current level of CARP demotion. The value is added to - the actual advskew sent in announcements for all vhids. During normal - system operation the demotion factor is zero. However, problematic - conditions raise its level: when carp experiences - problem with sending announcements, when an interface running a vhid goes - down, or while the pfsync(4) interface is not - synchronized. The demotion factor can be adjusted writing to the sysctl - oid. The signed value supplied to the sysctl(8) command - is added to current demotion factor. This allows to control - carp behaviour depending on some external - conditions, for example on the status of some daemon utility.
-
net.inet.carp.ifdown_demotion_factor
-
This value is added to net.inet.carp.demotion when - an interface running a vhid goes down. The default value is 240 (the - maximum advskew value).
-
net.inet.carp.senderr_demotion_factor
-
This value is added to net.inet.carp.demotion when - carp experiences errors sending its announcements. - The default value is 240 (the maximum advskew value).
-
-
-
-

-

Sometimes it is useful to get notified about - carp status change events. This can be accomplished - by using devd(8) hooks. Master/slave events are signalled - under system CARP. The subsystem specifies the vhid - and name of the interface where the master/slave event occurred. The type of - the message displays the new state of the vhid. Please see - devd.conf(5) and the - EXAMPLES section for more - information.

-
-
-

-

For firewalls and routers with multiple interfaces, it is - desirable to failover all of the addresses running - carp together, when one of the physical interfaces - goes down. This is achieved by the use of the preempt option. Enable it on - both hosts A and B:

-

-
sysctl - net.inet.carp.preempt=1
-

Assume that host A is the preferred master and we are running the - 192.168.1.0/24 prefix on em0 and 192.168.2.0/24 on em1. This is the setup - for host A (advskew is above 0 so it could be overwritten in the emergency - situation from the other host):

-
-
ifconfig em0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.1/24
-ifconfig em1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.2.1/24
-
-

The setup for host B is identical, but it has a higher - advskew:

-
-
ifconfig em0 vhid 1 advskew 200 pass mekmitasdigoat 192.168.1.1/24
-ifconfig em1 vhid 2 advskew 200 pass mekmitasdigoat 192.168.2.1/24
-
-

When one of the physical interfaces of host A fails, - advskew is demoted to a configured value on all its - carp vhids. Due to the preempt option, host B would - start announcing itself, and thus preempt host A on both interfaces instead - of just the failed one.

-

Processing of carp status change events - can be set up by using the following devd.conf rule:

-
-
notify 0 {
-	match "system"          "CARP";
-	match "subsystem"       "[0-9]+@[0-9a-z.]+";
-	match "type"            "(MASTER|BACKUP)";
-	action "/root/carpcontrol.sh $subsystem $type";
-};
-
-

To see carp packets decoded in - tcpdump(1) output, one needs to specify the - -T carp option, otherwise - tcpdump(1) will interpret them as VRRP packets:

-
-
tcpdump -npi vlan0 -T carp
-
-
-
-

-

tcpdump(1), inet(4), - pfsync(4), devd.conf(5), - rc.conf(5), ifconfig(8), - sysctl(8)

-
-
-

-

The carp device first appeared in - OpenBSD 3.5. The carp device - was imported into FreeBSD 5.4. In - FreeBSD 10.0, carp was - significantly rewritten, and is no longer a pseudo-interface.

-
-
- - - - - -
March 11, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/cas.4 3.html b/static/freebsd/man4/cas.4 3.html deleted file mode 100644 index baeda46f..00000000 --- a/static/freebsd/man4/cas.4 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
CAS(4)Device Drivers ManualCAS(4)
-
-
-

-

cas — Sun - Cassini/Cassini+ and National Semiconductor DP83065 Saturn Gigabit Ethernet - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device cas
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_cas_load="YES"
-
-
-
-

-

The cas driver provides support for the - Sun Cassini/Cassini+ and National Semiconductor DP83065 Saturn Gigabit - Ethernet controllers.

-

All controllers supported by the cas - driver have TCP/UDP checksum offload capability for both receive and - transmit, support for the reception and transmission of extended frames for - vlan(4) and an interrupt coalescing/moderation mechanism - as well as a 512-bit multicast hash filter.

-

The cas driver also supports Jumbo Frames - (up to 9022 bytes), which can be configured via the interface MTU setting. - Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames.

-
-
-

-

The chips supported by the cas driver - are:

-

-
    -
  • National Semiconductor DP83065 Saturn Gigabit Ethernet
    • -
  • Sun Cassini Gigabit Ethernet
    • -
  • Sun Cassini+ Gigabit Ethernet
    • -
-

The following add-on cards are known to work with the - cas driver at this time:

-

-
    -
  • Sun GigaSwift Ethernet 1.0 MMF (Cassini Kuheen) (part no. 501-5524)
    • -
  • Sun GigaSwift Ethernet 1.0 UTP (Cassini) (part no. 501-5902)
    • -
  • Sun GigaSwift Ethernet UTP (GCS) (part no. 501-6719)
    • -
  • Sun Quad GigaSwift Ethernet UTP (QGE) (part no. 501-6522)
    • -
  • Sun Quad GigaSwift Ethernet PCI-X (QGE-X) (part no. 501-6738)
    • -
-
-
-

-

altq(4), miibus(4), - netintro(4), vlan(4), - ifconfig(8)

-
-
-

-

The cas device driver appeared in - FreeBSD 8.0 and FreeBSD 7.3. - It is named after the cas driver which first - appeared in OpenBSD 4.1 and supports the same set of - controllers but is otherwise unrelated.

-
-
-

-

The cas driver was written by - Marius Strobl - <marius@FreeBSD.org> - based on the gem(4) driver.

-
-
- - - - - -
April 18, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_cdg.4 3.html b/static/freebsd/man4/cc_cdg.4 3.html deleted file mode 100644 index 2a9418e1..00000000 --- a/static/freebsd/man4/cc_cdg.4 3.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - -
CC_CDG(4)Device Drivers ManualCC_CDG(4)
-
-
-

-

cc_cdg — CDG - Congestion Control Algorithm

-
-
-

-

CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm - which reacts to both packet loss and inferred queuing delay. It attempts to - operate as a delay-based algorithm where possible, but utilises heuristics - to detect loss-based TCP cross traffic and will compete effectively as - required. CDG is therefore incrementally deployable and suitable for use on - shared networks.

-

During delay-based operation, CDG uses a delay-gradient based - probabilistic backoff mechanism, and will also try to infer non congestion - related packet losses and avoid backing off when they occur. During - loss-based operation, CDG essentially reverts to - cc_newreno(4)-like behaviour.

-

CDG switches to loss-based operation when it detects that a - configurable number of consecutive delay-based backoffs have had no - measurable effect. It periodically attempts to return to delay-based - operation, but will keep switching back to loss-based operation as - required.

-
-
-

-

The algorithm exposes the following variables in the - net.inet.tcp.cc.cdg branch of the - sysctl(3) MIB:

-
-
version
-
Current algorithm/implementation version number.
-
beta_delay
-
Delay-based window decrease factor as a percentage (on delay-based - backoff, w = w * beta_delay / 100). Default is 70.
-
beta_loss
-
Loss-based window decrease factor as a percentage (on loss-based backoff, - w = w * beta_loss / 100). Default is 50.
-
exp_backoff_scale
-
Scaling parameter for the probabilistic exponential backoff. Default is - 2.
-
smoothing_factor
-
Number of samples used for moving average smoothing (0 means no - smoothing). Default is 8.
-
loss_compete_consec_cong
-
Number of consecutive delay-gradient based congestion episodes which will - trigger loss-based CC compatibility. Default is 5.
-
loss_compete_hold_backoff
-
Number of consecutive delay-gradient based congestion episodes to hold the - window backoff for loss-based CC compatibility. Default is 5.
-
alpha_inc
-
If non-zero, this enables an experimental mode where CDG's window increase - factor (alpha) is increased by 1 MSS every alpha_inc - RTTs during congestion avoidance mode. (Setting - alpha_inc to 1 results in the most aggressive growth - of the window increase factor over time. Use higher - alpha_inc values for slower growth.) Default is - 0.
-
-
-
-

-

cc_chd(4), cc_cubic(4), - cc_dctcp(4), cc_hd(4), - cc_htcp(4), cc_newreno(4), - cc_vegas(4), h_ertt(4), - mod_cc(4), tcp(4), - khelp(9), mod_cc(9)

-

D. A. Hayes and - G. Armitage, Revisiting TCP - Congestion Control using Delay Gradients, Networking - 2011 Proceedings, Part II, 328-341, - May 2011.

-

N. Khademi and - G. Armitage, Minimising RTT - across homogeneous 802.11 WLANs with CAIA Delay-Gradient TCP (v0.1), - CAIA Technical Report 121113A, - http://caia.swin.edu.au/reports/121113A/CAIA-TR-121113A.pdf, - November 2012.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and The Cisco University Research - Program Fund, a corporate advised fund of Silicon Valley Community - Foundation.

-
-
-

-

The cc_cdg congestion control module first - appeared in FreeBSD 9.2.

-

The module was first released in 2011 by David Hayes whilst - working on the NewTCP research project at Swinburne University of - Technology's Centre for Advanced Internet Architectures, Melbourne, - Australia. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_cdg congestion control module was - written by David Hayes - <david.hayes@ieee.org>. - This manual page was written by Lawrence Stewart - <lstewart@FreeBSD.org> - and Grenville Armitage - <garmitage@swin.edu.au>.

-
-
-

-

The underlying algorithm and parameter values are still a work in - progress and may not be optimal for some network scenarios.

-
-
- - - - - -
May 13, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_chd.4 3.html b/static/freebsd/man4/cc_chd.4 3.html deleted file mode 100644 index e9f6a4b4..00000000 --- a/static/freebsd/man4/cc_chd.4 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
CC_CHD(4)Device Drivers ManualCC_CHD(4)
-
-
-

-

cc_chd — CHD - Congestion Control Algorithm

-
-
-

-

CHD enhances the HD algorithm implemented in - cc_hd(4). It provides tolerance to non-congestion related - packet loss and improvements to coexistence with traditional loss-based TCP - flows, especially when the bottleneck link is lightly multiplexed.

-

Like HD, the algorithm aims to keep network queuing delays below a - particular threshold (queue_threshold) and decides to reduce the congestion - window (cwnd) probabilistically based on its estimate of the network queuing - delay.

-

It differs from HD in three key aspects:

-
    -
  • The probability of cwnd reduction due to congestion is calculated once per - round trip time instead of each time an acknowledgement is received as - done by cc_hd(4).
    • -
  • Packet losses that occur while the queuing delay is less than - queue_threshold do not cause cwnd to be reduced.
    • -
  • CHD uses a shadow window to help regain lost transmission opportunities - when competing with loss-based TCP flows.
    • -
-
-
-

-

The algorithm exposes the following tunable variables in the - net.inet.tcp.cc.chd branch of the - sysctl(3) MIB:

-
-
queue_threshold
-
Queueing congestion threshold (qth) in ticks. Default is 20.
-
pmax
-
Per RTT maximum backoff probability as a percentage. Default is 50.
-
qmin
-
Minimum queuing delay threshold (qmin) in ticks. Default is 5.
-
loss_fair
-
If 1, cwnd is adjusted using the shadow window when a congestion related - loss is detected. Default is 1.
-
use_max
-
If 1, the maximum RTT seen within the measurement period is used as the - basic delay measurement for the algorithm, otherwise a sampled RTT - measurement is used. Default is 1.
-
-
-
-

-

cc_cdg(4), cc_cubic(4), - cc_dctcp(4), cc_hd(4), - cc_htcp(4), cc_newreno(4), - cc_vegas(4), h_ertt(4), - mod_cc(4), tcp(4), - khelp(9), mod_cc(9)

-

D. A. Hayes and - G. Armitage, Improved coexistence - and loss tolerance for delay based TCP congestion control, - in 35th Annual IEEE Conference on Local Computer - Networks, 24-31, October - 2010.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The cc_chd congestion control module first - appeared in FreeBSD 9.0.

-

The module was first released in 2010 by David Hayes whilst - working on the NewTCP research project at Swinburne University of - Technology's Centre for Advanced Internet Architectures, Melbourne, - Australia. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_chd congestion control module and - this manual page were written by David Hayes - <david.hayes@ieee.org>.

-
-
- - - - - -
May 13, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_cubic.4 3.html b/static/freebsd/man4/cc_cubic.4 3.html deleted file mode 100644 index 117c6659..00000000 --- a/static/freebsd/man4/cc_cubic.4 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
CC_CUBIC(4)Device Drivers ManualCC_CUBIC(4)
-
-
-

-

cc_cubic — CUBIC - Congestion Control Algorithm

-
-
-

-

The CUBIC congestion control algorithm was designed to provide - increased throughput in fast and long-distance networks. The CUBIC - congestion control algorithm is the default for TCP. It attempts to maintain - fairness when competing with legacy NewReno TCP in lower speed scenarios - where NewReno is able to operate adequately.

-

The congestion window is increased as a function of the time - elapsed since the last congestion event. During regular operation, the - window increase function follows a cubic function, with the inflection point - set to be the congestion window value reached at the last congestion event. - CUBIC also calculates an estimate of the congestion window that NewReno - would have achieved at a given time after a congestion event. When updating - the congestion window, the algorithm will choose the larger of the - calculated CUBIC and estimated NewReno windows.

-

CUBIC also backs off less on congestion by changing the - multiplicative decrease factor from 1/2 (used by standard NewReno TCP) to - 4/5.

-

The implementation was done in a clean-room fashion, and is based - on the Internet Draft and paper referenced in the - SEE ALSO section below.

-
-
-

-

There are currently no tunable MIB variables.

-
-
-

-

cc_cdg(4), cc_chd(4), - cc_dctcp(4), cc_hd(4), - cc_htcp(4), cc_newreno(4), - cc_vegas(4), mod_cc(4), - tcp(4), mod_cc(9)

-

Sangtae Ha, - Injong Rhee, and Lisong - Xu, CUBIC for Fast Long-Distance Networks, - https://tools.ietf.org/id/draft-rhee-tcpm-cubic-02.txt.

-

Sangtae Ha, - Injong Rhee, and Lisong - Xu, CUBIC: a new TCP-friendly high-speed TCP - variant, SIGOPS Oper. Syst. Rev., - 5, 42, - 64-74, July - 2008.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The cc_cubic congestion control module - first appeared in FreeBSD 9.0.

-

This became the default congestion algorithm for FreeBSD in - version FreeBSD 14.0, replacing - cc_newreno(4).

-

The module was first released in 2009 by Lawrence Stewart whilst - studying at Swinburne University of Technology's Centre for Advanced - Internet Architectures, Melbourne, Australia. More details are available - at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_cubic congestion control module and - this manual page were written by Lawrence Stewart - <lstewart@FreeBSD.org> - and David Hayes - <david.hayes@ieee.org>.

-
-
- - - - - -
February 4, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_dctcp.4 3.html b/static/freebsd/man4/cc_dctcp.4 3.html deleted file mode 100644 index db66dbac..00000000 --- a/static/freebsd/man4/cc_dctcp.4 3.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
CC_DCTCP(4)Device Drivers ManualCC_DCTCP(4)
-
-
-

-

cc_dctcp — DCTCP - Congestion Control Algorithm

-
-
-

-

The DCTCP (data center TCP) congestion control algorithm aims to - maximise throughput and minimise latency in data center networks by - utilising the proportion of Explicit Congestion Notification (ECN) marks - received from capable hardware as a congestion signal.

-

DCTCP uses fraction of ECN marked packets to update congestion - window. The window reduction ratio is always <= 1/2. Only when all of the - packets are marked, congestion window is halved.

-

In order to keep the accuracy of the ECN marked fraction, a DCTCP - receiver mirrors back incoming (or missing) CE marks by setting (or - clearing) ECE marks. This feedback methodology is also adopted when the - receiver uses delayed ACK.

-

The FreeBSD DCTCP implementation includes - two minor modifications for the one-sided deployment. Considering the - situation that DCTCP is used as sender and classic ECN is used as receiver, - DCTCP sets the CWR flag as the reaction to the ECE flag. In addition, when - classic ECN is used as sender and DCTCP is used as receiver, DCTCP avoids to - mirror back ACKs only when the CWR flag is set in the incoming packet.

-

The other specifications are based on the paper and the RFC - referenced in the SEE ALSO section - below.

-
-
-

-

The algorithm exposes the following tunable variables in the - net.inet.tcp.cc.dctcp branch of the - sysctl(3) MIB:

-
-
alpha
-
The initial value to estimate the congestion on the link. The valid range - is from 0 to 1024, where 1024 reduces the congestion window to half, if a - CE is observed in the first window and alpha could - not yet adjust to the congestion level on that path. Default is 1024.
-
shift_g
-
An estimation gain in the alpha calculation. This - influences the responsiveness when adjusting alpha to the most recent - observed window. Valid range from 0 to 10, the default is 4, resulting in - an effective gain of 1 / ( 2 ^ shift_g ), or - 1/16th.
-
slowstart
-
A flag if the congestion window should be reduced by one half after slow - start. Valid settings 0 and 1, default 0.
-
ect1
-
Controls if a DCTCP session should use IP ECT(0) marking when sending out - segments (default), or ECT(1) marking making use of L4S infrastructure. - Changes to this setting will only affect new sessions, existing sessions - will retain their previous marking value.
-
-
-
-

-

cc_cdg(4), cc_chd(4), - cc_cubic(4), cc_hd(4), - cc_htcp(4), cc_newreno(4), - cc_vegas(4), mod_cc(4), - tcp(4), mod_cc(9)

-

Mohammad Alizadeh, - Albert Greenberg, David A. - Maltz, Jitendra Padhye, - Parveen Patel, Balaji - Prabhakar, Sudipta Sengupta, and - Murari Sridharan, Data Center TCP - (DCTCP), ACM SIGCOMM 2010, - http://research.microsoft.com/pubs/121386/dctcp-public.pdf, - 63-74, July - 2010.

-

Stephen Bensley, - Dave Thaler, Praveen - Balasubramanian, Lars Eggert, and - Glenn Judd, Data Center TCP - (DCTCP): TCP Congestion Control for Data Centers, - https://tools.ietf.org/html/rfc8257.

-
-
-

-

The cc_dctcp congestion control module - first appeared in FreeBSD 11.0.

-

The module was first released in 2014 by Midori Kato studying at - Keio University, Japan.

-
-
-

-

The cc_dctcp congestion control module and - this manual page were written by Midori Kato - katoon@sfc.wide.ad.jp - and Lars Eggert - lars@netapp.com with help - and modifications from Hiren Panchasara - hiren@FreeBSD.org

-
-
- - - - - -
November 8, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_hd.4 3.html b/static/freebsd/man4/cc_hd.4 3.html deleted file mode 100644 index 69b3dffa..00000000 --- a/static/freebsd/man4/cc_hd.4 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
CC_HD(4)Device Drivers ManualCC_HD(4)
-
-
-

-

cc_hd — HD - Congestion Control Algorithm

-
-
-

-

The HD congestion control algorithm is an implementation of the - Hamilton Institute's delay-based congestion control which aims to keep - network queuing delays below a particular threshold (queue_threshold).

-

HD probabilistically reduces the congestion window (cwnd) based on - its estimate of the network queuing delay. The probability of reducing cwnd - is zero at hd_qmin or less, rising to a maximum at queue_threshold, and then - back to zero at the maximum queuing delay.

-

Loss-based congestion control algorithms such as NewReno probe for - network capacity by filling queues until there is a packet loss. HD competes - with loss-based congestion control algorithms by allowing its probability of - reducing cwnd to drop from a maximum at queue_threshold to be zero at the - maximum queuing delay. This has been shown to work well when the bottleneck - link is highly multiplexed.

-
-
-

-

The algorithm exposes the following tunable variables in the - net.inet.tcp.cc.hd branch of the - sysctl(3) MIB:

-
-
queue_threshold
-
Queueing congestion threshold (qth) in ticks. Default is 20.
-
pmax
-
Per packet maximum backoff probability as a percentage. Default is 5.
-
qmin
-
Minimum queuing delay threshold (qmin) in ticks. Default is 5.
-
-
-
-

-

cc_cdg(4), cc_chd(4), - cc_cubic(4), cc_dctcp(4), - cc_htcp(4), cc_newreno(4), - cc_vegas(4), h_ertt(4), - mod_cc(4), tcp(4), - khelp(9), mod_cc(9)

-

L. Budzisz, - R. Stanojevic, R. Shorten, - and F. Baker, A strategy for fair - coexistence of loss and delay-based congestion control algorithms, - IEEE Commun. Lett., 7, - 13, 555-557, - Jul 2009.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The Hamilton Institute have recently made some improvements to the - algorithm implemented by this module and have called it Coexistent-TCP - (C-TCP). The improvements should be evaluated and potentially incorporated - into this module.

-
-
-

-

The cc_hd congestion control module first - appeared in FreeBSD 9.0.

-

The module was first released in 2010 by David Hayes whilst - working on the NewTCP research project at Swinburne University of - Technology's Centre for Advanced Internet Architectures, Melbourne, - Australia. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_hd congestion control module and - this manual page were written by David Hayes - <david.hayes@ieee.org>.

-
-
- - - - - -
May 13, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_htcp.4 3.html b/static/freebsd/man4/cc_htcp.4 3.html deleted file mode 100644 index bb9dc3f1..00000000 --- a/static/freebsd/man4/cc_htcp.4 3.html +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - -
CC_HTCP(4)Device Drivers ManualCC_HTCP(4)
-
-
-

-

cc_htcp — H-TCP - Congestion Control Algorithm

-
-
-

-

The H-TCP congestion control algorithm was designed to provide - increased throughput in fast and long-distance networks. It attempts to - maintain fairness when competing with legacy NewReno TCP in lower speed - scenarios where NewReno is able to operate adequately.

-

The congestion window is increased as a function of the time - elapsed since the last congestion event. The window increase algorithm - operates like NewReno for the first second after a congestion event, and - then switches to a high-speed mode based on a quadratic increase - function.

-

The implementation was done in a clean-room fashion, and is based - on the Internet Draft and other documents referenced in the - SEE ALSO section below.

-
-
-

-

The algorithm exposes the following tunable variables in the - net.inet.tcp.cc.htcp branch of the - sysctl(3) MIB:

-
-
adaptive_backoff
-
Controls use of the adaptive backoff algorithm, which is designed to keep - network queues non-empty during congestion recovery episodes. Default is 0 - (disabled).
-
rtt_scaling
-
Controls use of the RTT scaling algorithm, which is designed to make - congestion window increase during congestion avoidance mode invariant with - respect to RTT. Default is 0 (disabled).
-
-
-
-

-

cc_cdg(4), cc_chd(4), - cc_cubic(4), cc_dctcp(4), - cc_hd(4), cc_newreno(4), - cc_vegas(4), mod_cc(4), - tcp(4), mod_cc(9)

-

D. Leith and - R. Shorten, H-TCP: TCP Congestion - Control for High Bandwidth-Delay Product Paths, - https://tools.ietf.org/id/draft-leith-tcp-htcp-06.txt.

-

D. Leith, - R. Shorten, and T. Yee, - H-TCP: A framework for congestion control in high-speed - and long-distance networks, Proc. PFLDnet, - 2005.

-

G. Armitage, - L. Stewart, M. Welzl, and - J. Healy, An independent H-TCP - implementation under FreeBSD 7.0: description and observed behaviour, - SIGCOMM Comput. Commun. Rev., 3, - 38, 27-38, - July 2008.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The cc_htcp congestion control module - first appeared in FreeBSD 9.0.

-

The module was first released in 2007 by James Healy and Lawrence - Stewart whilst working on the NewTCP research project at Swinburne - University of Technology's Centre for Advanced Internet Architectures, - Melbourne, Australia, which was made possible in part by a grant from the - Cisco University Research Program Fund at Community Foundation Silicon - Valley. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_htcp congestion control module was - written by James Healy - <jimmy@deefa.com> and - Lawrence Stewart - <lstewart@FreeBSD.org>.

-

This manual page was written by Lawrence - Stewart - <lstewart@FreeBSD.org> - and David Hayes - <david.hayes@ieee.org>.

-
-
- - - - - -
May 13, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_newreno.4 3.html b/static/freebsd/man4/cc_newreno.4 3.html deleted file mode 100644 index 3328b3c4..00000000 --- a/static/freebsd/man4/cc_newreno.4 3.html +++ /dev/null @@ -1,140 +0,0 @@ - - - - - - -
CC_NEWRENO(4)Device Drivers ManualCC_NEWRENO(4)
-
-
-

-

cc_newreno — - NewReno Congestion Control Algorithm

-
-
-

-

#include - <netinet/cc/cc_newreno.h>

-
-
-

-

Details about the algorithm can be found in RFC5681.

-
-
-

-

The cc_newreno module supports a number of - socket options under TCP_CCALGOOPT (refer to tcp(4) and - mod_cc(9) for details) which can be set with - setsockopt(2) and tested with - getsockopt(2). The cc_newreno - socket options use this structure defined in - <sys/netinet/cc/cc_newreno.h>:

-
-
struct cc_newreno_opts {
-	int name;
-	uint32_t val;
-}
-
-
-
CC_NEWRENO_BETA
-
Multiplicative window decrease factor, specified as a percentage, applied - to the congestion window in response to a congestion signal per: cwnd = - (cwnd * CC_NEWRENO_BETA) / 100. Default is 50.
-
CC_NEWRENO_BETA_ECN
-
Multiplicative window decrease factor, specified as a percentage, applied - to the congestion window in response to an ECN congestion signal when - net.inet.tcp.cc.abe=1 per: cwnd = (cwnd * - CC_NEWRENO_BETA_ECN) / 100. Default is 80. -

Note that currently the only way to enable hystart++ is to - enable it via socket option. When enabling it a value of 1 will enable - precise internet-draft (version 4) behavior (subject to any MIB variable - settings), other setting (2 and 3) are experimental.

-
-
-

Note that hystart++ requires the TCP stack be able to call to the - congestion controller with both the newround function - as well as the rttsample function. Currently the only - TCP stacks that provide this feedback to the congestion controller is - rack.

-
-
-

-

The algorithm exposes these variables in the - net.inet.tcp.cc.newreno branch of the - sysctl(3) MIB:

-
-
beta
-
Multiplicative window decrease factor, specified as a percentage, applied - to the congestion window in response to a congestion signal per: cwnd = - (cwnd * beta) / 100. Default is 50.
-
beta_ecn
-
Multiplicative window decrease factor, specified as a percentage, applied - to the congestion window in response to an ECN congestion signal when - net.inet.tcp.cc.abe=1 per: cwnd = (cwnd * beta_ecn) - / 100. Default is 80.
-
-
-
-

-

cc_cdg(4), cc_chd(4), - cc_cubic(4), cc_dctcp(4), - cc_hd(4), cc_htcp(4), - cc_vegas(4), mod_cc(4), - tcp(4), mod_cc(9)

-

Mark Allman, - Vern Paxson, and Ethan - Blanton, TCP Congestion Control, - RFC 5681.

-

Naeem Khademi, - Michael Welzl, Grenville - Armitage, and Gorry Fairhurst, - TCP Alternative Backoff with ECN (ABE), - RFC 8511.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The cc_newreno congestion control - algorithm first appeared in its modular form in FreeBSD - 9.0.

-

This was the default congestion control algorithm in FreeBSD - before version FreeBSD 14.0, after which - cc_cubic(4) replaced it.

-

The module was first released in 2007 by James Healy and Lawrence - Stewart whilst working on the NewTCP research project at Swinburne - University of Technology's Centre for Advanced Internet Architectures, - Melbourne, Australia, which was made possible in part by a grant from the - Cisco University Research Program Fund at Community Foundation Silicon - Valley. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_newreno congestion control module - was written by James Healy - <jimmy@deefa.com>, - Lawrence Stewart - <lstewart@FreeBSD.org> - and David Hayes - <david.hayes@ieee.org>.

-

Support for TCP ABE was added by Tom Jones - <tj@enoti.me>.

-

This manual page was written by Lawrence - Stewart - <lstewart@FreeBSD.org>.

-
-
- - - - - -
February 4, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/cc_vegas.4 3.html b/static/freebsd/man4/cc_vegas.4 3.html deleted file mode 100644 index 8660bca9..00000000 --- a/static/freebsd/man4/cc_vegas.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
CC_VEGAS(4)Device Drivers ManualCC_VEGAS(4)
-
-
-

-

cc_vegas — Vegas - Congestion Control Algorithm

-
-
-

-

The Vegas congestion control algorithm uses what the authors term - the actual and expected transmission rates to determine whether there is - congestion along the network path i.e.

-
    -
  • actual rate = (total data sent in a RTT) / RTT
    • -
  • expected rate = cwnd / RTTmin
    • -
  • diff = expected - actual
    • -
-

where RTT is the measured instantaneous round trip time and RTTmin - is the smallest round trip time observed during the connection.

-

The algorithm aims to keep diff between two parameters alpha and - beta, such that:

-
    -
  • alpha < diff < beta
    • -
-

If diff > beta, congestion is inferred and cwnd is decremented - by one packet (or the maximum TCP segment size). If diff < alpha, then - cwnd is incremented by one packet. Alpha and beta govern the amount of - buffering along the path.

-

The implementation was done in a clean-room fashion, and is based - on the paper referenced in the SEE ALSO - section below.

-
-
-

-

The time from the transmission of a marked packet until the - receipt of an acknowledgement for that packet is measured once per RTT. This - implementation does not implement Brakmo's and Peterson's original duplicate - ACK policy since clock ticks in today's machines are not as coarse as they - were (i.e. 500ms) when Vegas was originally designed. Note that modern TCP - recovery processes such as fast retransmit and SACK are enabled by default - in the TCP stack.

-
-
-

-

The algorithm exposes the following tunable variables in the - net.inet.tcp.cc.vegas branch of the - sysctl(3) MIB:

-
-
alpha
-
Query or set the Vegas alpha parameter as a number of buffers on the path. - When setting alpha, the value must satisfy: 0 < alpha < beta. - Default is 1.
-
beta
-
Query or set the Vegas beta parameter as a number of buffers on the path. - When setting beta, the value must satisfy: 0 < alpha < beta. Default - is 3.
-
-
-
-

-

cc_cdg(4), cc_chd(4), - cc_cubic(4), cc_dctcp(4), - cc_hd(4), cc_htcp(4), - cc_newreno(4), h_ertt(4), - mod_cc(4), tcp(4), - khelp(9), mod_cc(9)

-

L. S. Brakmo and - L. L. Peterson, TCP Vegas: end to - end congestion avoidance on a global internet, IEEE J. - Sel. Areas Commun., 8, - 13, 1465-1480, - October 1995.

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The cc_vegas congestion control module - first appeared in FreeBSD 9.0.

-

The module was first released in 2010 by David Hayes whilst - working on the NewTCP research project at Swinburne University of - Technology's Centre for Advanced Internet Architectures, Melbourne, - Australia. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The cc_vegas congestion control module and - this manual page were written by David Hayes - <david.hayes@ieee.org>.

-
-
- - - - - -
May 13, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ccd.4 3.html b/static/freebsd/man4/ccd.4 3.html deleted file mode 100644 index fe91f3ca..00000000 --- a/static/freebsd/man4/ccd.4 3.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - -
CCD(4)Device Drivers ManualCCD(4)
-
-
-

-

ccd — Concatenated - Disk driver

-
-
-

-

device ccd

-
-
-

-

The ccd driver provides the capability of - combining one or more disks/partitions into one virtual disk.

-

This document assumes that you are familiar with how to generate - kernels, how to properly configure disks and devices in a kernel - configuration file, and how to partition disks.

-

In order to compile in support for the - ccd, you must add a line similar to the following to - your kernel configuration file:

-

-
device ccd # concatenated disk - devices
-

As of the FreeBSD 3.0 release, you do not - need to configure your kernel with ccd but may - instead use it as a kernel loadable module. Simply running - ccdconfig(8) will load the module into the kernel.

-

A ccd may be either serially concatenated - or interleaved. To serially concatenate the partitions, specify the - interleave factor of 0. Note that mirroring may not be used with an - interleave factor of 0.

-

There is a run-time utility that is used for configuring - ccds. See ccdconfig(8) for more - information.

-
-

-

If a ccd is interleaved correctly, a - “striping” effect is achieved, which can increase sequential - read/write performance. The interleave factor is expressed in units of - DEV_BSIZE (usually 512 bytes). For large writes, the - optimum interleave factor is typically the size of a track, while for large - reads, it is about a quarter of a track. (Note that this changes greatly - depending on the number and speed of disks.) For instance, with eight 7,200 - RPM drives on two Fast-Wide SCSI buses, this translates to about 128 for - writes and 32 for reads. A larger interleave tends to work better when the - disk is taking a multitasking load by localizing the file I/O from any given - process onto a single disk. You lose sequential performance when you do - this, but sequential performance is not usually an issue with a multitasking - load.

-

An interleave factor must be specified when using a mirroring - configuration, even when you have only two disks (i.e., the layout winds up - being the same no matter what the interleave factor). The interleave factor - will determine how I/O is broken up, however, and a value 128 or greater is - recommended.

-

ccd has an option for a parity disk, but - does not currently implement it.

-

The best performance is achieved if all component disks have the - same geometry and size. Optimum striping cannot occur with different disk - types.

-

For random-access oriented workloads, such as news servers, a - larger interleave factor (e.g., 65,536) is more desirable. Note that there - is not much ccd can do to speed up applications that - are seek-time limited. Larger interleave factors will at least reduce the - chance of having to seek two disk-heads to read one directory or a file.

-
-
-

-

You can configure the ccd to - “mirror” any even number of disks. See - ccdconfig(8) for how to specify the necessary flags. For - example, if you have a ccd configuration specifying - four disks, the first two disks will be mirrored with the second two disks. - A write will be run to both sides of the mirror. A read will be run to - either side of the mirror depending on what the driver believes to be most - optimal. If the read fails, the driver will automatically attempt to read - the same sector from the other side of the mirror. Currently - ccd uses a dual seek zone model to optimize reads - for a multi-tasking load rather than a sequential load.

-

In an event of a disk failure, you can use dd(1) - to recover the failed disk.

-

Note that a one-disk ccd is not the same - as the original partition. In particular, this means if you have a file - system on a two-disk mirrored ccd and one of the - disks fail, you cannot mount and use the remaining partition as itself; you - have to configure it as a one-disk ccd. You cannot - replace a disk in a mirrored ccd partition without - first backing up the partition, then replacing the disk, then restoring the - partition.

-
-
-

-

The Linux compatibility mode does not try to read the label that - Linux' md(4) driver leaves on the raw devices. You will - have to give the order of devices and the interleave factor on your own. - When in Linux compatibility mode, ccd will convert - the interleave factor from Linux terminology. That means you give the same - interleave factor that you gave as chunk size in Linux.

-

If you have a Linux md(4) device in - “legacy” mode, do not use the - CCDF_LINUX flag in ccdconfig(8). - Use the CCDF_NO_OFFSET flag instead. In that case - you have to convert the interleave factor on your own, usually it is Linux' - chunk size multiplied by two.

-

Using a Linux RAID this way is potentially dangerous and can - destroy the data in there. Since FreeBSD does not - read the label used by Linux, changes in Linux might invalidate the - compatibility layer.

-

However, using this is reasonably safe if you test the - compatibility before mounting a RAID read-write for the first time. Just - using ccdconfig(8) without mounting does not write - anything to the Linux RAID. Then you do a - fsck.ext2fs - (ports/filesystems/e2fsprogs) on the - ccd device using the -n - flag. You can mount the file system read-only to check files in there. If - all this works, it is unlikely that there is a problem with - ccd. Keep in mind that even when the Linux - compatibility mode in ccd is working correctly, bugs - in FreeBSD's ex2fs - implementation would still destroy your data.

-
-
-
-

-

If just one (or more) of the disks in a - ccd fails, the entire file system will be lost - unless you are mirroring the disks.

-

If one of the disks in a mirror is lost, you should still be able - to back up your data. If a write error occurs, however, data read from that - sector may be non-deterministic. It may return the data prior to the write - or it may return the data that was written. When a write error occurs, you - should recover and regenerate the data as soon as possible.

-

Changing the interleave or other parameters for a - ccd disk usually destroys whatever data previously - existed on that disk.

-
-
-

-
-
/dev/ccd*
-
ccd device special files
-
-
-
-

-

dd(1), ccdconfig(8), - config(8), disklabel(8), - fsck(8), mount(8), - newfs(8)

-
-
-

-

The concatenated disk driver was originally written at the - University of Utah.

-
-
- - - - - -
January 23, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ccr.4 3.html b/static/freebsd/man4/ccr.4 3.html deleted file mode 100644 index c2695093..00000000 --- a/static/freebsd/man4/ccr.4 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
CCR(4)Device Drivers ManualCCR(4)
-
-
-

-

ccr — Chelsio T6 - crypto accelerator driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ccr -
-device cxgbe
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
ccr_load="YES"
-
-
-
-

-

The ccr driver provides support for the - crypto accelerator engine included on PCI Express Ethernet adapters based on - the Chelsio Terminator 6 ASIC (T6). The driver accelerates AES-CBC, AES-CCM, - AES-CTR, AES-GCM, AES-XTS, SHA1, SHA2-224, SHA2-256, SHA2-384, SHA2-512, - SHA1-HMAC, SHA2-224-HMAC, SHA2-256-HMAC, SHA2-384-HMAC, and SHA2-512-HMAC - operations for crypto(9) consumers such as - ktls(4), geli(4), and - ipsec(4). The driver also supports chaining one of - AES-CBC, AES-CTR, or AES-XTS with SHA1-HMAC, SHA2-224-HMAC, SHA2-256-HMAC, - SHA2-384-HMAC, or SHA2-512-HMAC for encrypt-then-authenticate operations. - For further hardware information and questions related to hardware - requirements, see http://www.chelsio.com/.

-

The ccr driver attaches as a child of an - existing Chelsio NIC device and thus requires that the - cxgbe(4) driver be active.

-
-
-

-

The ccr driver supports the crypto - accelerator engine included on adapters based on the T6 ASIC:

-

-
    -
  • Chelsio T6225-CR
    • -
  • Chelsio T6225-SO-CR
    • -
  • Chelsio T62100-LP-CR
    • -
  • Chelsio T62100-SO-CR
    • -
  • Chelsio T62100-CR
    • -
-
-
-

-

For general information and support, go to the Chelsio support - website at: http://www.chelsio.com/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - <support@chelsio.com>.

-
-
-

-

crypto(4), cxgbe(4), - geli(4), ipsec(4), - ktls(4), crypto(7), - crypto(9)

-
-
-

-

The ccr device driver first appeared in - FreeBSD 12.0.

-
-
-

-

The ccr driver was written by - John Baldwin - <jhb@FreeBSD.org>.

-
-
- - - - - -
November 25, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/cd.4 3.html b/static/freebsd/man4/cd.4 3.html deleted file mode 100644 index a091d660..00000000 --- a/static/freebsd/man4/cd.4 3.html +++ /dev/null @@ -1,294 +0,0 @@ - - - - - - -
CD(4)Device Drivers ManualCD(4)
-
-
-

-

cd — SCSI CD-ROM - driver

-
-
-

-

device cd

-
-
-

-

The cd driver provides support for a SCSI - CD-ROM (Compact Disc-Read Only Memory) drive. In an attempt to look like a - regular disk, the cd driver synthesizes a partition - table, with one partition covering the entire CD-ROM. It is possible to - modify this partition table using disklabel(8), but it - will only last until the CD-ROM is unmounted. In general the interfaces are - similar to those described by ada(4) and - da(4).

-

As the SCSI adapter is probed during boot, the SCSI bus is scanned - for devices. Any devices found which answer as CDROM (type 5) or WORM (type - 4) type devices will be `attached' to the cd driver. - Prior to FreeBSD 2.1, the first device found will be - attached as cd0 the next, - cd1, etc. Beginning in FreeBSD - 2.1 it is possible to specify what cd unit a device should come on - line as; refer to scsi(4) for details on kernel - configuration.

-

The system utility disklabel(8) may be used to - read the synthesized disk label structure, which will contain correct - figures for the size of the CD-ROM should that information be required.

-
-
-

-

Any number of CD-ROM devices may be attached to the system - regardless of system configuration as all resources are dynamically - allocated.

-
-
-

-

The following ioctl(2) calls which apply to SCSI - CD-ROM drives are defined in the header files - <sys/cdio.h> and - <sys/disklabel.h>.

-
-
-
(struct ioc_play_track) Start audio playback given - a track address and length. The structure is defined as follows: -
- 
struct ioc_play_track
-{
-	u_char	start_track;
-	u_char	start_index;
-	u_char	end_track;
-	u_char	end_index;
-};
-
-
-
-
(struct ioc_play_blocks) Start audio playback - given a block address and length. The structure is defined as follows: -
- 
struct ioc_play_blocks
-{
-	int	blk;
-	int	len;
-};
-
-
-
-
(struct ioc_play_msf) Start audio playback given a - `minutes-seconds-frames' address and length. The structure is defined as - follows: -
- 
struct ioc_play_msf
-{
-	u_char	start_m;
-	u_char	start_s;
-	u_char	start_f;
-	u_char	end_m;
-	u_char	end_s;
-	u_char	end_f;
-};
-
-
-
-
(struct ioc_read_subchannel) Read information from - the subchannel at the location specified by this structure: -
- 
struct ioc_read_subchannel {
-	u_char address_format;
-#define CD_LBA_FORMAT	1
-#define CD_MSF_FORMAT	2
-	u_char data_format;
-#define CD_SUBQ_DATA		0
-#define CD_CURRENT_POSITION	1
-#define CD_MEDIA_CATALOG	2
-#define CD_TRACK_INFO		3
-	u_char track;
-	int	data_len;
-	struct  cd_sub_channel_info *data;
-};
-
-
-
-
(struct ioc_toc_header) Return summary information - about the table of contents for the mounted CD-ROM. The information is - returned into the following structure: -
- 
struct ioc_toc_header {
-	u_short len;
-	u_char  starting_track;
-	u_char  ending_track;
-};
-
-
-
-
(struct ioc_read_toc_entry) Return information - from the table of contents entries mentioned. (Yes, this command name is - misspelled.) The argument structure is defined as follows: -
- 
struct ioc_read_toc_entry {
-	u_char	address_format;
-	u_char	starting_track;
-	u_short	data_len;
-	struct  cd_toc_entry *data;
-};
-
- The requested data is written into an area of size - data_len and pointed to by - data.
-
-
(struct ioc_patch) Attach various audio channels - to various output channels. The argument structure is defined thusly: -
- 
struct ioc_patch {
-	u_char	patch[4];
-	/* one for each channel */
-};
-
-
-
-
 
-
-
(struct ioc_vol) Get (set) information about the - volume settings of the output channels. The argument structure is as - follows: -
- 
struct	ioc_vol
-{
-	u_char	vol[4];
-	/* one for each channel */
-};
-
-
-
-
Patch all output channels to all source channels.
-
-
Patch left source channel to the left output channel and the right source - channel to the right output channel.
-
-
Mute output without changing the volume settings.
-
-
 
-
-
Attach both output channels to the left (right) source channel.
-
-
 
-
-
Turn on (off) debugging for the appropriate device.
-
-
 
-
-
Pause (resume) audio play, without resetting the location of the - read-head.
-
-
Reset the drive.
-
-
 
-
-
Tell the drive to spin-up (-down) the CD-ROM.
-
-
 
-
-
Tell the drive to allow (prevent) manual ejection of the CD-ROM disc. Not - all drives support this feature.
-
-
Eject the CD-ROM.
-
-
Tell the drive to close its door and load the media. Not all drives - support this feature.
-
-
-
-

-

When a CD-ROM is changed in a drive controlled by the - cd driver, then the act of changing the media will - invalidate the disklabel and information held within the kernel. To stop - corruption, all accesses to the device will be discarded until there are no - more open file descriptors referencing the device. During this period, all - new open attempts will be rejected. When no more open file descriptors - reference the device, the first next open will load a new set of parameters - (including disklabel) for the drive.

-

The audio code in the cd driver only - support SCSI-2 standard audio commands. As many CD-ROM manufacturers have - not followed the standard, there are many CD-ROM drives for which audio will - not work. Some work is planned to support some of the more common `broken' - CD-ROM drives; however, this is not yet under way.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.cam.cd.retry_count
-
-

This variable determines how many times the - cd driver will retry a READ or WRITE command. - This does not affect the number of retries used during probe time or for - the cd driver dump routine. This value currently - defaults to 4.

-
-
kern.cam.cd.%d.minimum_cmd_size
-
-

The cd driver attempts to - automatically determine whether the drive it is talking to supports 6 - byte or 10 byte MODE SENSE/MODE SELECT operations. Many SCSI drives only - support 6 byte commands, and ATAPI drives only support 10 byte commands. - The cd driver first attempts to determine - whether the protocol in use typically supports 6 byte commands by - issuing a CAM Path Inquiry CCB. It will then default to 6 byte or 10 - byte commands as appropriate. After that, the cd - driver defaults to using 6 byte commands (assuming the protocol the - drive speaks claims to support 6 byte commands), until one fails with a - SCSI ILLEGAL REQUEST error. Then it tries the 10 byte version of the - command to see if that works instead. Users can change the default via - per-drive sysctl variables and loader tunables. Where “%d” - is the unit number of the drive in question. Valid minimum command sizes - are 6 and 10. Any value above 6 will be rounded to 10, and any value - below 6 will be rounded to 6.

-
-
-
-
-

-
-
/dev/cd[0-9][a-h]
-
raw mode CD-ROM devices
-
-
-
-

-

None.

-
-
-

-

cam(4), cd9660(4), - da(4), disklabel(8), - cd(9)

-
-
-

-

This cd driver is based upon the - cd driver written by Julian Elischer, which appeared - in 386BSD-0.1. The CAM version of the - cd driver was written by Kenneth Merry and first - appeared in FreeBSD 3.0.

-
-
-

-

The names of the structures used for the third argument to - ioctl() were poorly chosen, and a number of spelling - errors have survived in the names of the ioctl() - commands.

-
-
- - - - - -
April 8, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/cd9660.4 4.html b/static/freebsd/man4/cd9660.4 4.html deleted file mode 100644 index 85043a49..00000000 --- a/static/freebsd/man4/cd9660.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
CD9660(4)Device Drivers ManualCD9660(4)
-
-
-

-

cd9660 — ISO-9660 - file system

-
-
-

-

To link into the kernel:

-
options CD9660
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
cd9660_load="YES"
-
-
-
-

-

The cd9660 driver will permit the - FreeBSD kernel to access the cd9660 file system.

-
-
-

-

To mount a cd9660 volume located on - /dev/cd0:

-

-
mount -t cd9660 /dev/cd0 - /mnt
-
-
-

-

etdump(1), nmount(2), - unmount(2), cd(4), - fstab(5), mount(8), - mount_cd9660(8)

-
-
-

-

The cd9660 driver first appeared in - 4.4BSD-Lite.

-
-
-

-

The cd9660 kernel implementation was - originally written by Pace Willisson - <pace@blitz.com> and - Atsushi Murai - <amurai@spec.co.jp>.

-

This manual page was written by Enji - Cooper - <ngie@FreeBSD.org>.

-
-
- - - - - -
January 18, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/cdce.4 3.html b/static/freebsd/man4/cdce.4 3.html deleted file mode 100644 index b8ce5fb9..00000000 --- a/static/freebsd/man4/cdce.4 3.html +++ /dev/null @@ -1,163 +0,0 @@ - - - - - - -
CDCE(4)Device Drivers ManualCDCE(4)
-
-
-

-

cdce — USB - Communication Device Class Ethernet (ECM/NCM) driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device cdce
-

Mobile Devices (e.g., Huawei E3372, E5573 and others) may need - additionally the u3g command port:

-
device ucom -
-device u3g
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_cdce_load="YES"
-
-
-
-

-

The cdce driver provides support for USB - Host-to-Host (aka USB-to-USB) and USB-to-Ethernet bridges based on the USB - Communication Device Class Ethernet Control Model (CDC ECM) and Network - Control Model (CDC NCM) specifications. It also provides device-side CDC ECM - support.

-

The USB bridge appears as a regular network interface on both - sides, transporting Ethernet frames.

-

For more information on configuring this device, see - ifconfig(8).

-

USB 1.x bridges support speeds of up to 12Mbps, and USB 2.0 speeds - of up to 480Mbps.

-

Packets are received and transmitted over separate USB bulk - transfer endpoints.

-

The cdce driver does not support different - media types or options.

-
-
-

-

The cdce driver supports USB Ethernet - interfaces implementing the USB Communication Device Class Ethernet Control - Model (CDC ECM) or Network Control Model (CDC NCM) protocol, such as:

-

-
    -
  • Android USB tethering
    • -
  • iPhone USB tethering
    • -
  • Realtek RTL8153 USB 3.0 to Gigabit Ethernet controller
    • -
  • Prolific PL-2501 Host-to-Host Bridge controller
    • -
  • Sharp Zaurus PDA
    • -
  • Terayon TJ-715 DOCSIS Cable Modem
    • -
  • Huawei 3G/4G LTE (e.g., E3372, E5573) and other mobile network - devices
    • -
-
-
-

-

Mobile cdce Network Devices may need a - connect command sequence via the u3g(4) serial command - port before activating the NCM/ECM/ACM network interface. For example:

-

-
echo - 'AT^NDISUP=1,1,"internet"' > /dev/cuaU[0].0
-

Wwhere “internet” is your providers apn name.

-
-
-

-
-
cdce%d: no union descriptor
-
The driver could not fetch an interface descriptor from the USB device. - For a manually added USB vendor/product, the CDCE_NO_UNION flag can be - tried to work around the missing descriptor.
-
cdce%d: no data interface
-
-
cdce%d: could not read endpoint descriptor
-
-
cdce%d: unexpected endpoint
-
-
cdce%d: could not find data bulk in/out
-
For a manually added USB vendor/product, these errors indicate that the - bridge is not compatible with the driver.
-
cdce%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
cdce%d: no memory for rx list -- packet dropped!
-
Memory allocation through MGETHDR or MCLGET failed, the system is running - low on mbufs.
-
cdce%d: abort/close rx/tx pipe failed
-
-
cdce%d: rx/tx list init failed
-
-
cdce%d: open rx/tx pipe failed
-
-
cdce%d: usb error on rx/tx
-
-
-
-
-

-

arp(4), cdceem(4), - intro(4), ipheth(4), - netintro(4), u3g(4), - ucom(4), urndis(4), - usb(4), ifconfig(8)

-

Universal Serial Bus Class - Definitions for Communication Devices, - http://www.usb.org/developers/devclass_docs/usbcdc11.pdf.

-

Data sheet Prolific PL-2501 - Host-to-Host Bridge/Network Controller, - http://tech.prolific.com.tw/visitor/fcabdl.asp?fid=20679530.

-
-
-

-

The cdce device driver first appeared in - OpenBSD 3.6, NetBSD 3.0 and - FreeBSD 6.0.

-
-
-

-

The cdce driver was written by - Craig Boston - <craig@tobuj.gank.org> - based on the aue(4) driver written by - Bill Paul - <wpaul@windriver.com> - and ported to OpenBSD by Daniel - Hartmeier - <dhartmei@openbsd.org>.

-
-
-

-

Many USB devices notoriously fail to report their class and - interfaces correctly. Undetected products might work flawlessly when their - vendor and product IDs are added to the driver manually.

-
-
- - - - - -
December 23, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/cdceem.4 3.html b/static/freebsd/man4/cdceem.4 3.html deleted file mode 100644 index 289225d0..00000000 --- a/static/freebsd/man4/cdceem.4 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
CDCEEM(4)Device Drivers ManualCDCEEM(4)
-
-
-

-

cdceem — USB - Communication Device Class Ethernet Emulation Model driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device cdceem
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_cdceem_load="YES"
-
-
-
-

-

The cdceem driver provides support for USB - devices based on the USB Communication Device Class Ethernet Emulation Model - (CDC EEM) specification.

-

The driver works on both host, and device-side; see - usb_template(4) for details.

-

The USB device appears as a regular network interface on both - sides, transporting Ethernet frames.

-

For more information on configuring this device, see - ifconfig(8).

-

The cdceem driver does not support - different media types or options.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.cdceem.debug
-
Verbosity level for log messages from the cdceem - driver. Set to 0 to disable logging or 1 to warn about potential problems. - Larger values enable debugging output. Defaults to 1.
-
hw.usb.cdceem.send_echoes
-
If set to 1, the driver will send an Echo EEM packet when the interface is - brought up. While responding to Echo is mandatory, some devices cannot - handle it. Only use for debugging. Defaults to 0.
-
hw.usb.cdceem.send_fake_crc
-
If set to 1, the driver will use 0xdeadbeef as the CRC value for outgoing - Data EEM packets. Only use for debugging. Defaults to 0.
-
-
-
-

-

arp(4), cdce(4), - intro(4), ipheth(4), - netintro(4), urndis(4), - usb(4), usb_template(4), - ifconfig(8)

-

Universal Serial Bus - Communications Class Subclass Specification for Ethernet Emulation Model - Devices, - https://usb.org/sites/default/files/CDC_EEM10.pdf.

-
-
-

-

The cdceem device driver first appeared in - FreeBSD 12.1.

-
-
-

-

The cdceem driver was written by - Edward Tomasz Napierala - <trasz@FreeBSD.org> - under sponsorship from Hewlett Packard Enterprise.

-
-
- - - - - -
September 18, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/cfi.4 3.html b/static/freebsd/man4/cfi.4 3.html deleted file mode 100644 index a8eab073..00000000 --- a/static/freebsd/man4/cfi.4 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
CFI(4)Device Drivers ManualCFI(4)
-
-
-

-

cfi, cfid — - driver for Common Flash Interface (CFI) NOR - flash

-
-
-

-

device cfi -
- device cfid -
- options CFI_SUPPORT_STRATAFLASH -
- options CFI_ARMEDANDDANGEROUS

-

In /boot/device.hints: -
- hint.cfi.0.at="nexus0" -
- hint.cfi.0.maddr=0x74000000 -
- hint.cfi.0.msize=0x4000000

-

In DTS file: -
- flash@74000000 { -
- compatible = "cfi-flash"; -
- reg = <0x74000000 0x4000000>; -
- };

-
-
-

-

The cfi device driver provides a - management interface to NOR flash devices supporting the Common Flash - Interface (CFI) specification. Its companion device - cfid provides a geom(4) disk - interface to the device.

-

Special support for features of the Intel StrataFlash line are - available with the CFI_SUPPORT_STRATAFLASH kernel - option. Additional support for write-once bits to switch part of Intel - StrataFlash devices to read-only can be enabled by the - CFI_ARMEDANDDANGEROUS kernel option.

-
-
-

-

led(4)

-
-
-

-

The cfi device driver first appeared in - FreeBSD 8.0.

-
-
-

-

The cfi driver was written by - Juniper Networks with StrataFlash support by -
- Sam Leffler. This manual page was written by SRI - International and the University of Cambridge Computer Laboratory under - DARPA/AFRL contract (FA8750-10-C-0237) (“CTSRD”), as part of - the DARPA CRASH research programme.

-
-
- - - - - -
January 20, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/cfiscsi.4 3.html b/static/freebsd/man4/cfiscsi.4 3.html deleted file mode 100644 index 28230c19..00000000 --- a/static/freebsd/man4/cfiscsi.4 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
CFISCSI(4)Device Drivers ManualCFISCSI(4)
-
-
-

-

cfiscsi — CAM - Target Layer iSCSI target frontend

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device cfiscsi -
-device ctl -
-device iscsi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
cfiscsi_load="YES"
-
-
-
-

-

The cfiscsi subsystem provides the kernel - component of an iSCSI target. The target is the iSCSI server, providing LUNs - backed by local files and volumes to remote initiators. The userspace - component is provided by ctld(8). - cfiscsi is implemented as a ctl(4) - frontend and uses infrastructure provided by iscsi(4).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.cam.ctl.iscsi.debug
-
Verbosity level for log messages from the kernel part of iSCSI target. Set - to 0 to disable logging or 1 to warn about potential problems. Larger - values enable debugging output. Defaults to 1.
-
kern.cam.ctl.iscsi.maxtags
-
The number of outstanding commands to advertise to each iSCSI initiator. - Current implementation is not very accurate, so do not set this below 2. - Defaults to 256.
-
kern.cam.ctl.iscsi.ping_timeout
-
The number of seconds to wait for the iSCSI initiator to respond to a - NOP-In PDU. In the event that there is no response within that time the - session gets forcibly terminated. Set to 0 to disable sending NOP-In PDUs. - Defaults to 5.
-
-
-
-

-

ctl(4), iscsi(4), - ctl.conf(5), ctld(8)

-
-
-

-

The cfiscsi subsystem first appeared in - FreeBSD 10.0 as part of the ctl(4) - driver. It was split off of ctl(4) in - FreeBSD 12.0.

-
-
-

-

The cfiscsi subsystem was developed by - Edward Tomasz Napierala - <trasz@FreeBSD.org> - under sponsorship from the FreeBSD Foundation. This manual page was written - by Enji Cooper - <ngie@FreeBSD.org>.

-
-
- - - - - -
May 28, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/cfumass.4 3.html b/static/freebsd/man4/cfumass.4 3.html deleted file mode 100644 index a846b4ce..00000000 --- a/static/freebsd/man4/cfumass.4 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
CFUMASS(4)Device Drivers ManualCFUMASS(4)
-
-
-

-

cfumass — USB - device side support for Mass Storage Class Transport

-
-
-

-

This driver can be compiled into the kernel by placing these lines - in the kernel configuration file:

-
device usb -
-device usb_template -
-device ctl -
-device cfumass
-

The driver module can also be loaded at boot by adding this line - to loader.conf(5):

-
-
cfumass_load="YES"
-
-
-
-

-

The cfumass driver provides device side - support for emulating an USB mass storage device compliant with the USB Mass - Storage Class Bulk-Only (BBB) Transport specification, implemented as a - ctl(4) frontend driver.

-

To use cfumass:

-
    -
  • cfumass must be loaded as a module or compiled - into the kernel.
    • -
  • The USB Mass Storage template must be chosen by setting the - hw.usb.template sysctl to 0.
    • -
  • The USB OTG port must be working in USB device-side mode. This happens - automatically upon connection to a USB host.
    • -
  • There must be a ctl(4) LUN configured for the - cfumass port.
    • -
-

Upon loading, the driver creates a ctl(4) port - named cfumass, presenting the first LUN mapped for - that port - usually LUN 0 - to the USB host. See - ctl.conf(5) and ctld(8) for details on - configuring the LUN. See the cfumass_enable and - cfumass_dir rc(8) variables in - rc.conf(5) for an automated way to configure it at - boot.

-
-
-

-

These variables are available as both sysctl(8) - variables and loader(8) tunables:

-
-
hw.usb.cfumass.debug
-
Verbosity level for log messages from the cfumass - driver. Set to 0 to disable logging or 1 to warn about potential problems. - Larger values enable debugging output. Defaults to 1.
-
hw.usb.cfumass.ignore_stop
-
Ignore START STOP UNIT SCSI commands with START and LOEJ bits cleared. - Some initiators send that command to stop the target when the user - attempts to gracefully eject the drive, but fail to start it when the - drive is reconnected. Set to 0 to handle the command in a - standards-compliant way, 1 to ignore it and log a warning, or 2 to ignore - it silently. Defaults to 1.
-
hw.usb.cfumass.max_lun
-
Max LUN number to report to the initiator (USB host). Must be between 0 - and 15. Some initiators incorrectly handle values larger than 0. Defaults - to 0.
-
-
-
-

-

ctl(4), umass(4), - usb(4), usb_template(4), - ctl.conf(5), ctld(8)

-
-
-

-

The cfumass driver first appeared in - FreeBSD 11.1.

-
-
-

-

The cfumass driver was developed by - Edward Tomasz Napierala - <trasz@FreeBSD.org> - under sponsorship from the FreeBSD Foundation.

-
-
- - - - - -
April 21, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/cgem.4 3.html b/static/freebsd/man4/cgem.4 3.html deleted file mode 100644 index 4b855a29..00000000 --- a/static/freebsd/man4/cgem.4 3.html +++ /dev/null @@ -1,262 +0,0 @@ - - - - - - -
CGEM(4)Device Drivers ManualCGEM(4)
-
-
-

-

cgem — Cadence GEM - Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ether -
-device miibus -
-device cgem
-
-
-

-

The cgem driver provides support for the - Cadence GEM (Gigabit Ethernet MAC). The Cadence GEM is used in some SoC - (System on a Chip) devices such as the Xilinx Zynq-7000, the Xilinx Zynq - UltraScale+, and the SiFive HiFive Unleashed.

-

The cgem driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode using ifconfig(8) or by - adding media options to rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000Mbps (Gigabit Ethernet) operation over twisted pair. The GEM - supports 1000Mbps in full-duplex mode only.
-
-

The cgem driver supports the following - media options:

-
-
-
Force full-duplex operation.
-
-
Force half-duplex operation.
-
-

The driver provides support for TCP/UDP/IP checksum offloading - (although disabled by default). The device and driver also support 1536-byte - frames for VLANs (vlanmtu).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.cgem.%d.rxbufs
-
The number of receive buffers allocated to the hardware. The default value - is 256. The maximum value is 511. If this number is increased while the - interface is UP, it will not take effect until the next packet is - received. If this number is decreased while the interface is UP, buffers - will not be immediately removed from the receive buffer ring but the - number of buffers will decrease as packets are received until it reaches - the new value.
-
dev.cgem.%d.rxhangwar
-
This tunable enables a work-around to recover from receive hangs. The - default value is 1. Set to 0 to disable the work-around.
-
-

The following read-only variables are available as - sysctl(8) variables:

-
-
dev.cgem.%d._rxoverruns
-
This variable counts the number of receive packet buffer overrun - interrupts.
-
dev.cgem.%d._rxnobufs
-
This variable counts the number of interrupts due to the GEM buffer ring - going empty.
-
dev.cgem.%d._rxdmamapfails
-
This variable is the number of times bus_dmamap_load_mbuf_sg(9) failed in - the receive path.
-
dev.cgem.%d._txfull
-
The number of times the GEM's transmit ring was full.
-
dev.cgem.%d._txdmamapfails
-
This variable is the number of times bus_dmamap_load_mbuf_sg(9) failed in - the transmit path.
-
dev.cgem.%d._txdefrags
-
This variable is the number of times the driver needed to call m_defrag(9) - because a packet queued for transmit had too many DMA segments.
-
dev.cgem.%d._txdefragfails
-
This variable is the number of times m_defrag(9) - failed.
-
dev.cgem.%d.stats.*
-
The following variables are useful MAC counters supplied by the - hardware:
-
dev.cgem.%d.stats.tx_bytes
-
A 64-bit counter of the number of bytes transmitted in frames without - error.
-
dev.cgem.%d.stats.tx_frames
-
Counter of frames transmitted without error excluding pause frames.
-
dev.cgem.%d.stats.tx_frames_bcast
-
Counter of broadcast frames transmitted without error excluding pause - frames.
-
dev.cgem.%d.stats.tx_frames_multi
-
Counter of multicast frames transmitted without error excluding pause - frames.
-
dev.cgem.%d.stats.tx_frames_pause
-
Counter of pause frames transmitted without error.
-
dev.cgem.%d.stats.tx_frames_64b
-
Counter of 64 byte frames transmitted without error.
-
dev.cgem.%d.stats.tx_frames_65to127b
-
Counter of 65 to 127 byte frames transmitted without error.
-
dev.cgem.%d.stats.tx_frames_128to255b
-
Counter of 128 to 255 byte frames transmitted without error.
-
dev.cgem.%d.stats.tx_frames_256to511b
-
Counter of 256 to 511 byte frames transmitted without error.
-
dev.cgem.%d.stats.tx_frames_512to1023b
-
Counter of 512 to 1023 byte frames transmitted without error.
-
dev.cgem.%d.stats.tx_frames_1024to1536b
-
Counter of 1024 to 1536 byte frames transmitted without error.
-
dev.cgem.%d.stats.tx_under_runs
-
Counter of frames not transmitted due to a transmit underrun.
-
dev.cgem.%d.stats.tx_single_collisn
-
Counter of frames experiencing a single collision before being - successfully transmitted.
-
dev.cgem.%d.stats.tx_multi_collisn
-
Counter of frames experiencing between 2 and 15 collisions before being - successfully transmitted.
-
dev.cgem.%d.stats.tx_excsv_collisn
-
Counter of frames that failed to transmit because they experienced 16 - collisions.
-
dev.cgem.%d.stats.tx_late_collisn
-
Counter of frames that experienced a late collision.
-
dev.cgem.%d.stats.tx_deferred_frames
-
Counter of frames experiencing deferral due to carrier sense being active - on their first attempt at transmission.
-
dev.cgem.%d.stats.tx_carrier_sense_errs
-
Counter of frames transmitted where carrier sense was not seen during - transmission or where carrier sense was deasserted after being asserted in - a transmit frame without collision.
-
dev.cgem.%d.stats.rx_bytes
-
A 64-bit counter of bytes received without error excluding pause - frames.
-
dev.cgem.%d.stats.rx_frames
-
Counter of frames received without error excluding pause frames.
-
dev.cgem.%d.stats.rx_frames_bcast
-
Counter of broadcast frames receive without error excluding pause - frames.
-
dev.cgem.%d.stats.rx_frames_multi
-
Counter of multicast frames receive without error excluding pause - frames.
-
dev.cgem.%d.stats.rx_frames_pause
-
Counter of pause frames received without error.
-
dev.cgem.%d.stats.rx_frames_64b
-
Counter of 64-byte frames received without error.
-
dev.cgem.%d.stats.rx_frames_65to127b
-
Counter of 65 to 127 byte frames received without error.
-
dev.cgem.%d.stats.rx_frames_128to255b
-
Counter of 128 to 255 byte frames received without error.
-
dev.cgem.%d.stats.rx_frames_256to511b
-
Counter of 256 to 511 byte frames received without error.
-
dev.cgem.%d.stats.rx_frames_512to1023b
-
Counter of 512 to 1023 byte frames received without error.
-
dev.cgem.%d.stats.rx_frames_1024to1536b
-
Counter of 1024 to 1536 byte frames received without error.
-
dev.cgem.%d.stats.rx_frames_undersize
-
Counter of frames received less than 64 bytes in length that do not also - have either a CRC error or an alignment error.
-
dev.cgem.%d.stats.rx_frames_oversize
-
Counter of frames received exceeding 1536 bytes and do not also have - either a CRC error or an alignment error.
-
dev.cgem.%d.stats.rx_frames_jabber
-
Counter of frames received exceeding 1536 bytes and also have either a CRC - error, an alignment error, or a receive symbol error.
-
dev.cgem.%d.stats.rx_frames_fcs_errs
-
Counter of frames received with a bad CRC and are between 64 and 1536 - bytes.
-
dev.cgem.%d.stats.rx_frames_length_errs
-
Counter of frames received that are shorter than that extracted from the - length field.
-
dev.cgem.%d.stats.rx_symbol_errs
-
Counter of receive symbol errors.
-
dev.cgem.%d.stats.rx_align_errs
-
Counter of received frames that are not an integral number of bytes.
-
dev.cgem.%d.stats.rx_resource_errs
-
Counter of frames successfully receive by the MAC but could not be copied - to memory because no receive buffer was available.
-
dev.cgem.%d.stats.rx_overrun_errs
-
Counter of frames that are address recognized but were not copied to - memory due to a receive overrun.
-
dev.cgem.%d.stats.rx_frames_ip_hdr_csum_errs
-
Counter of frames discarded due to an incorrect IP header checksum when - checksum offloading is enabled.
-
dev.cgem.%d.stats.rx_frames_tcp_csum_errs
-
Counter of frames discarded due to an incorrect TCP checksum when checksum - offloading is enabled.
-
dev.cgem.%d.stats.rx_frames_udp_csum_errs
-
Counter of frames discarded due to an incorrect UDP checksum when checksum - offloading is enabled.
-
-
-
-

-

miibus(4), ifconfig(8)

-

Zynq-7000 SoC Technical - Reference Manual (Xilinx doc UG585), - http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf.

-
-
-

-

The cgem device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The cgem driver and this manual page was - written by Thomas Skibo - <thomasskibo@yahoo.com>.

-
-
-

-

The GEM can perform TCP/UDP/IP checksum offloading. However, when - transmit checksum offloading is enabled, the GEM generates and replaces - checksums for all packets it transmits. In a system that is forwarding - packets, the device could potentially correct the checksum of packet that - was corrupted in transit. For this reason, checksum offloading is disabled - by default but can be enabled using ifconfig(8).

-

When receive checksum offloading is enabled, the device will - discard packets with bad TCP/UDP/IP checksums. The bad packets will not be - counted in any netstat(1) statistics. There are - sysctl(8) variables that count packets discarded by the - hardware (see below).

-

The GEM used in the Zynq-7000 has a bug such that the receiver can - potentially freeze up under a high load. The issue is described in sec. 16.7 - "Known Issues" of the Zynq-7000 SoC Technical Reference Manual - (Xilinx UG585 v1.7). The cgem driver implements the - work-around suggested in the manual. It is believed that the bug does not - exist in the Zynq UltraScale+ and SiFive SoCs so the work-around is disabled - in those instances and enabled in all others. The work-around can be - disabled by setting the dev.cgem.%d.rxhangwar - sysctl(8) variable to 0.

-
-
- - - - - -
January 10, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ch.4 3.html b/static/freebsd/man4/ch.4 3.html deleted file mode 100644 index e70095c2..00000000 --- a/static/freebsd/man4/ch.4 3.html +++ /dev/null @@ -1,278 +0,0 @@ - - - - - - -
CH(4)Device Drivers ManualCH(4)
-
-
-

-

ch — SCSI - media-changer (juke box) driver

-
-
-

-

device ch

-
-
-

-

The ch driver provides support for a - SCSI media changer. It allows many slots of media to be - multiplexed between a number of drives. The changer device may optionally be - equipped with a bar code reader, which reads label information attached to - the media.

-

A SCSI adapter must also be separately configured into the system - before a SCSI changer can be configured.

-

As the SCSI adapter is probed during boot, the - SCSI bus is scanned for devices. Any devices found which - answer as 'Changer' type devices will be 'attached' to the - ch driver. In FreeBSD - releases prior to 2.1, the first found will be attached as - and the next, - etc. - Beginning in 2.1 it is possible to specify what ch unit a device should come - on line as; refer to scsi(4) for details on kernel - configuration.

-
-
-

-

It is only necessary to explicitly configure one - ch device; data structures are dynamically allocated - as media changes are found on the SCSI bus.

-
-
-

-

User mode programs communicate with the changer driver through a - number of ioctls which are described below. Changer element addresses used - in the communication between the kernel and the changer device are mapped to - zero-based logical addresses. Element types are specified as follows:

-
-
-
Medium transport element (picker).
-
-
Storage element (slot).
-
-
Import/export element (portal).
-
-
Data transfer element (drive).
-
-

The following ioctl(2) calls apply to the - changer. They are defined in the header file - <sys/chio.h>.

-
-
-
(struct changer_move) Move a medium from one element - to another () using the current picker. The source and destination - elements are specified in a changer_move structure, which includes at - least the following fields: -
- 
u_int cm_fromtype; /* element type to move from */
-u_int cm_fromunit; /* logical unit of from element */
-u_int cm_totype;   /* element type to move to */
-u_int cm_tounit;   /* logical unit of to element */
-u_int cm_flags;	   /* misc. flags */
-
- If the CM_INVERT in the - cm_flags field is set, the medium changer is - instructed to flip the medium while moving it.
-
-
(struct changer_exchange) Move the medium located in - the source element to the first destination element, and move the medium - that had been in the first destination element to the second destination - element. In case of a simple exchange, the source and second destination - elements should be the same. The current picker is used to perform the - operation. The addresses of the affected elements is specified to the - ioctl in a changer_exchange structure which includes - at least the following fields: -
- 
u_int ce_srctype;	 /* element type of source */
-u_int ce_srcunit;	 /* logical unit of source */
-u_int ce_fdsttype; /* element type of first destination */
-u_int ce_fdstunit; /* logical unit of first destination */
-u_int ce_sdsttype; /* element type of second destination */
-u_int ce_sdstunit; /* logical unit of second destination */
-u_int ce_flags;	 /* misc. flags */
-
- In ce_flags, CM_INVERT1 and/or - CM_INVERT2 may be set to flip the first or second - medium during the exchange operation, respectively. -

.

-
-
-
(struct changer_position) Position the current - picker in front of the specified element. The element is specified with a - changer_position structure, which includes at least the following - elements: -
- 
u_int cp_type;  /* element type */
-u_int cp_unit;  /* logical unit of element */
-u_int cp_flags; /* misc. flags */
-
- The cp_flags field may be set to - CP_INVERT to invert the picker during the - operation.
-
-
(int) Return the logical address of the current - picker.
-
-
(int) Select the picker specified by the given - logical address.
-
-
(struct changer_params) Return the configuration - parameters for the media changer. This ioctl fills the changer_params - structure passed by the user with at least the following fields: -
- 
u_int cp_npickers; /* number of pickers */
-u_int cp_nslots;   /* number of slots */
-u_int cp_nportals; /* number of import/export portals */
-u_int cp_ndrives;  /* number of drives */
-
-

This call can be used by applications to query the dimensions - of the jukebox before using the CHIGSTATUS ioctl - to query the jukebox status.

-
-
-
Perform the - call on the media changer device. This forces the - media changer to update its internal status information with respect to - loaded media. It also scans any barcode labels provided that it has a - label reader. The ch driver's status is not - affected by this call.
-
-
(struct changer_element_status_request) Perform the - call on the media changer device. This call reads the - element status information of the media changer and converts it to an - array of changer_element_status structures. -

With each call to CHIOGSTATUS, the - status of one or more elements of one type may be queried.

-

The application passes a - changer_element_status_request structure to the - ch driver which contains the following - fields:

-
- 
u_int                          cesr_element_type;
-u_int                          cesr_element_base;
-u_int                          cesr_element_count;
-u_int                          cesr_flags;
-struct changer_element_status *cesr_element_status;
-
-

This structure is read by the driver to determine the type, - logical base address and number of elements for which information is to - be returned in the array of changer_element_status - structures pointed to by the cesr_element_status - field. The application must allocate enough memory for - cesr_element_count status structures (see below). - The cesr_flags can optionally be set to - CESR_VOLTAGS to indicate that volume tag (bar - code) information is to be read from the jukebox and returned.

-

The cesr_element_base and - cesr_element_count fields must be valid with - respect to the physical configuration of the changer. If they are not, - the CHIOGSTATUS ioctl returns the - EINVAL error code.

-

The information about the elements is returned in an array of - changer_element_status structures. This structure - include at least the following fields:

-
- 
u_int            ces_addr;      /* element address in media changer */
-u_char           ces_flags;     /* see CESTATUS definitions below */
-u_char           ces_sensecode; /* additional sense code for element */
-u_char           ces_sensequal; /* additional sense code qualifier */
-u_char           ces_invert;    /* invert bit */
-u_char           ces_svalid;    /* source address (ces_source) valid */
-u_short          ces_source;    /* source address of medium */
-changer_voltag_t ces_pvoltag;   /* primary volume tag */
-changer_voltag_t ces_avoltag;   /* alternate volume tag */
-u_char           ces_idvalid;   /* ces_scsi_id is valid */
-u_char           ces_scsi_id;   /* SCSI id of element (if ces_idvalid is nonzero) */
-u_char           ces_lunvalid;  /* ces_scsi_lun is valid */
-u_char           ces_scsi_lun;  /* SCSI lun of element (if ces_lunvalid is nonzero) */
-
-

The ces_addr field contains the address - of the element in the coordinate system of the media changer. It is not - used by the driver, and should be used for diagnostic purposes only.

-

The following flags are defined for the - ces_flags field:

-
-
-
A medium is present.
-
-
The medium has been deposited by the operator (and not by a - picker).
-
-
The element is in an exceptional state (e.g. invalid barcode label, - barcode not yet scanned).
-
-
The element is accessible by the picker.
-
-
The element supports medium export.
-
-
The element supports medium import.
-
-

Note that not all flags are valid for all element types.

-
-
-
-
-

-

This version of the ch driver has been - tested with a DEC TZ875 (5 slot, one DLT drive) and a Breece Hill Q47 (60 - slot, four DLT drives, barcode reader).

-

Many of the features the ch driver - supports are not thoroughly tested due to the fact that the devices - available for testing do not support the necessary commands. This is true - for alternate volume tags, media flipping, import/export element handling, - multiple picker operation and other things.

-
-
-

-
-
/dev/ch[0-9]
-
device entries
-
-
-
-

-

If the media changer does not support features requested by the - ch driver, it will produce both console error - messages and failure return codes to the ioctls described here.

-
-
-

-

chio(1), cam(4), - cd(4), da(4), - sa(4)

-
-
-

-

The ch driver appeared in - 386BSD-0.1.

-
-
-

-

The ch driver was written by - Jason R. Thorpe - <thorpej@and.com> for - And Communications, http://www.and.com/. It was - added to the system by Stefan Grefen - <grefen@goofy.zdv.uni-mainz.de> - who apparently had such a device. It was ported to CAM by - Kenneth Merry - <ken@FreeBSD.org>. It - was updated to support volume tags by Hans Huebner - <hans@artcom.de>.

-
-
- - - - - -
May 14, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/chromebook_platform.4 4.html b/static/freebsd/man4/chromebook_platform.4 4.html deleted file mode 100644 index 9e78f7db..00000000 --- a/static/freebsd/man4/chromebook_platform.4 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
CHROMEBOOK_PLATFORM(4)Device Drivers ManualCHROMEBOOK_PLATFORM(4)
-
-
-

-

chromebook_platform — - support driver for hardware on various Chromebook - models

-
-
-

-

To compile this driver into the kernel, place the following lines - into the kernel configuration file:

-
device - chromebook_platform
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
chromebook_platform_load="YES"
-
-
-
-

-

The chromebook_platform driver provides - automatic configuration for devices that cannot be enumerated or safely - probed. In particular, I2C peripherals are different from model to model. - chromebook_platform has a model-specific information - about the I2C peripherals, their drivers, their bus attachments and slave - addresses.

-

Note that chromebook_platform does not - load driver modules for the peripherals. Those have to be compiled into the - kernel or loaded separately.

-
-
-

-

cyapa(4), iicbus(4), - isl(4)

-
-
-

-

The chromebook_platform driver and this - manual page were written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
October 13, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/chvgpio.4 3.html b/static/freebsd/man4/chvgpio.4 3.html deleted file mode 100644 index 1b736c18..00000000 --- a/static/freebsd/man4/chvgpio.4 3.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
CHVGPIO(4)Device Drivers ManualCHVGPIO(4)
-
-
-

-

chvgpio — Intel - Cherry View SoC GPIO controller

-
-
-

-

device gpio -
- device chvgpio

-
-
-

-

chvgpio supports the GPIO controller that - can be found in Intel's Cherry View SoC family.

-

The Cherry View SoC has 5 banks of GPIO pins, NORTH, EAST, - SOUTHEAST, SOUTHWEST and VIRTUAL. All but VIRTUAL are exposed to userland as - /dev/gpiocN, where N is 0-3. Pins in each bank are - pre-named to match names in the Intel® Atom™ Z8000 Processor - Series Vol 2

-
-
-

-

gpio(3), gpio(4), - gpioctl(8)

-

Intel® Atom™ - Z8000 Processor Series Vol 1.

-

Intel® Atom™ - Z8000 Processor Series Vol 2.

-
-
-

-

The chvgpio manual page first appeared in - FreeBSD 12.

-
-
-

-

This driver and man page were written by Tom - Jones - <tj@enoti.me>.

-
-
- - - - - -
November 17, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ciss.4 3.html b/static/freebsd/man4/ciss.4 3.html deleted file mode 100644 index 25465ac8..00000000 --- a/static/freebsd/man4/ciss.4 3.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - -
CISS(4)Device Drivers ManualCISS(4)
-
-
-

-

ciss — Common - Interface for SCSI-3 Support driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device ciss
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ciss_load="YES"
-
-
-
-

-

The ciss driver claims to provide a common - interface between generic SCSI transports and intelligent host adapters.

-

The ciss driver supports - as defined in - the document entitled CISS Command Interface for SCSI-3 - Support Open Specification, Version 1.04, Valence Number 1, dated - 2000/11/27, produced by Compaq Computer Corporation.

-

We provide a shim layer between the - ciss interface and CAM(4), - offloading most of the queueing and being-a-disk chores onto CAM. Entry to - the driver is via the PCI bus attachment - (), - (), - etc. and via the CAM interface - (), - and - (). - The Compaq ciss adapters require faked responses to - get reasonable behavior out of them. In addition, the - ciss command set is by no means adequate to support - the functionality of a RAID controller, and thus the supported Compaq - adapters utilize portions of the control protocol from earlier Compaq - adapter families.

-

Currently ciss supports the - “simple” and “performant” transport layer.

-

Non-disk devices (such as internal DATs and devices attached to - the external SCSI bus) are supported as normal CAM devices provided that - they are exported by the controller firmware and are not marked as being - masked. Masked devices can be exposed by setting the - hw.ciss.expose_hidden_physical tunable to non-zero at - boot time. Direct Access devices (such as disk drives) are only exposed as - pass(4) devices. Hot-insertion and removal of devices is - supported and notification messages will be reported to the console and - logs.

-

The problem which adapter freezes with the message “ADAPTER - HEARTBEAT FAILED” might be solved by updating the firmware and/or - setting the hw.ciss.nop_message_heartbeat tunable to - non-zero at boot time.

-
-
-

-

The ciss driver supports controllers - implementing Common Interface for SCSI-3 Support Open Specification v1.04, - including:

-

-
    -
  • Compaq Smart Array 5300 (simple mode only)
    • -
  • Compaq Smart Array 532
    • -
  • Compaq Smart Array 5i
    • -
  • HP Smart Array 5312
    • -
  • HP Smart Array 6i
    • -
  • HP Smart Array 641
    • -
  • HP Smart Array 642
    • -
  • HP Smart Array 6400
    • -
  • HP Smart Array 6400 EM
    • -
  • HP Smart Array E200
    • -
  • HP Smart Array E200i
    • -
  • HP Smart Array E500
    • -
  • HP Smart Array H240
    • -
  • HP Smart Array H240ar
    • -
  • HP Smart Array H240nr
    • -
  • HP Smart Array H241
    • -
  • HP Smart Array H244br
    • -
  • HP Smart Array P212
    • -
  • HP Smart Array P220i
    • -
  • HP Smart Array P222
    • -
  • HP Smart Array P230i
    • -
  • HP Smart Array P240nr
    • -
  • HP Smart Array P244br
    • -
  • HP Smart Array P246br
    • -
  • HP Smart Array P400
    • -
  • HP Smart Array P400i
    • -
  • HP Smart Array P410
    • -
  • HP Smart Array P410i
    • -
  • HP Smart Array P411
    • -
  • HP Smart Array P420
    • -
  • HP Smart Array P420i
    • -
  • HP Smart Array P421
    • -
  • HP Smart Array P430
    • -
  • HP Smart Array P430i
    • -
  • HP Smart Array P431
    • -
  • HP Smart Array P440
    • -
  • HP Smart Array P440ar
    • -
  • HP Smart Array P441
    • -
  • HP Smart Array P530
    • -
  • HP Smart Array P531
    • -
  • HP Smart Array P542d
    • -
  • HP Smart Array P600
    • -
  • HP Smart Array P700m
    • -
  • HP Smart Array P712m
    • -
  • HP Smart Array P721m
    • -
  • HP Smart Array P731m
    • -
  • HP Smart Array P741m
    • -
  • HP Smart Array P800
    • -
  • HP Smart Array P812
    • -
  • HP Smart Array P822
    • -
  • HP Smart Array P830
    • -
  • HP Smart Array P830i
    • -
  • HP Smart Array P840
    • -
  • HP Smart Array P840ar
    • -
  • HP Smart Array P841
    • -
  • HP Modular Smart Array 20 (MSA20)
    • -
  • HP Modular Smart Array 500 (MSA500)
    • -
-

Additionally, several HP Smart Array controllers are supported by - PCI subdevice ID only, as no model name is available for them: 0x3220, - 0x3222, 0x3230, 0x3231, 0x3232, 0x3233, 0x3236, 0x3238, 0x3239, 0x323A, - 0x323B, 0x323C, and 0x324B (all with PCI subvendor 0x103C).

-
-
-

-

cam(4), pass(4), - xpt(4), loader.conf(5), - camcontrol(8)

-

CISS Command Interface for - SCSI-3 Support Open Specification, Version 1.04, Valence Number 1, - Compaq Computer Corporation, - 2000/11/27.

-
-
-

-

The ciss driver was written by - Mike Smith - <msmith@FreeBSD.org>.

-

This manual page is based on his comments and was written by - Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
April 6, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/coretemp.4 4.html b/static/freebsd/man4/coretemp.4 4.html deleted file mode 100644 index 2b5cf120..00000000 --- a/static/freebsd/man4/coretemp.4 4.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - -
CORETEMP(4)Device Drivers ManualCORETEMP(4)
-
-
-

-

coretemp — device - driver for Intel Core on-die digital thermal sensor

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device coretemp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
coretemp_load="YES"
-
-
-
-

-

The coretemp driver provides support for - the on-die digital thermal sensor present in Intel Core and newer CPUs.

-

The coretemp driver reports each core's - temperature through a sysctl node in the corresponding CPU device's sysctl - tree, named dev.cpu.%d.temperature.

-
-
-

-

amdtemp(4), sysctl(8)

-
-
-

-

The coretemp driver first appeared in - FreeBSD 7.0.

-
-
-

-

The coretemp driver was written by - Rui Paulo - <rpaulo@FreeBSD.org> - as part of a Google Summer of Code project. This manual page was written by - Dag-Erling Smørgrav - <des@FreeBSD.org>.

-
-
- - - - - -
August 23, 2007FreeBSD 15.0
diff --git a/static/freebsd/man4/cp2112.4 3.html b/static/freebsd/man4/cp2112.4 3.html deleted file mode 100644 index 50b2f3b0..00000000 --- a/static/freebsd/man4/cp2112.4 3.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
CP2112(4)Device Drivers ManualCP2112(4)
-
-
-

-

cp2112 — driver - for a USB GPIO and I2C peripheral device

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device cp2112 -
-device usb -
-device gpio -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
cp2112_load="YES"
-
-
-
-

-

The cp2112 driver provides support for - Silicon Labs CP2112 device. The device has 8 general purpose I/O pins and an - I2C controller that supports a subset of the I2C protocol.

-

All pins support both input and output modes. An output pin can be - configured either for open-drain or push-pull operation. Pins 0, 1 and 7 - support special functions: I2C transmit indication, I2C receive indication - and clock output respectively. At the moment the - cp2112 driver does not provide a way to enable and - configure the special functions.

-

The I2C controller supports read transactions with up to 512 bytes - of data, write transactions with up to 61 bytes of data and a write followed - by the repeated start followed by a read transactions where the write can be - up to 16 bytes and the read can be up to 512 bytes. Zero length transfers - are not supported. The cp2112 driver creates a - gpio(4) and iicbus(4) child buses to - expose the respective functions.

-
-
-

-

gpio(4), iicbus(4), - usb(4)

-
-
-

-

The cp2112 driver and this manual page was - written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
August 12, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/cpuctl.4 3.html b/static/freebsd/man4/cpuctl.4 3.html deleted file mode 100644 index 5459dec1..00000000 --- a/static/freebsd/man4/cpuctl.4 3.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
CPUCTL(4)Device Drivers ManualCPUCTL(4)
-
-
-

-

cpuctl — cpuctl - pseudo device

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device cpuctl
-

Alternatively, to load the driver as a module at boot time, place - the following in loader.conf(5):

-
-
cpuctl_load="YES"
-
-
-
-

-

The special device /dev/cpuctl presents - interface to the system CPU. It provides functionality to retrieve CPUID - information, read/write machine specific registers (MSR) and perform CPU - firmware updates.

-

For each CPU present in the system, the special device - /dev/cpuctl%d with the appropriate index will be - created. For multicore CPUs such a special device will be created for each - core.

-

Currently, only i386 and amd64 processors are supported.

-
-
-

-

All of the supported operations are invoked using the - ioctl(2) system call. Currently, the following ioctls are - defined:

-
-
- cpuctl_msr_args_t *args
-
 
-
- cpuctl_msr_args_t *args
-
Read/write CPU machine specific register. The - cpuctl_msr_args_t structure is defined in - <sys/cpuctl.h> as: -
- 
typedef struct {
-	int		msr;	/* MSR to read */
-	uint64_t	data;
-} cpuctl_msr_args_t;
-
-
-
- cpuctl_msr_args_t *args
-
 
-
- cpuctl_msr_args_t *args
-
Set/clear MSR bits according to the mask given in the - data field.
-
- cpuctl_cpuid_args_t *args
-
Retrieve CPUID information. Arguments are supplied in the following - structure: -
- 
typedef struct {
-	int		level;		/* CPUID level */
-	uint32_t	data[4];
-} cpuctl_cpuid_args_t;
-
-

It is equivalent to the - CPUCTL_CPUID_COUNT request with - level_type set to 0.

-
-
- cpuctl_cpuid_count_args_t *args
-
Retrieve CPUID information. Arguments are supplied in the following - structure: -
- 
typedef struct {
-	int		level;		/* CPUID level */
-	int		level_type;	/* CPUID level type */
-	uint32_t	data[4];
-} cpuctl_cpuid_count_args_t;
-
-

The level field indicates the CPUID - level to retrieve, it is loaded into the %eax - register before the CPUID instruction is executed, The - level_type field indicates the CPUID level type to - retrieve, it is loaded into the %ecx register.

-

The data field is used to store the - received CPUID data. That is, data[0] contains the - value of %eax register after the CPUID instruction - is executed, data[1] is for - %ebx, data[2] for - %ecx, and data[3] for - %edx.

-
-
-
Update CPU firmware (microcode). The structure is defined in - <sys/cpuctl.h> as: -
- 
typedef struct {
-	void	*data;
-	size_t	size;
-} cpuctl_update_args_t;
-
-

The data field should point to the - firmware image of size size.

-
-
-

For additional information refer to - cpuctl.h.

-
-
-

-
-
/dev/cpuctl
-
 
-
-
-
-

-
-
[]
-
The operation requested is not supported by the device (e.g., unsupported - architecture or the CPU is disabled).
-
[]
-
Incorrect request was supplied, or microcode image is not correct.
-
[]
-
No physical memory was available to complete the request.
-
[]
-
The firmware image address points outside the process address space.
-
-
-
-

-

hwpmc(4), cpucontrol(8)

-
-
-

-

The cpuctl driver first appeared in - FreeBSD 7.2.

-
-
-

-

The cpuctl module and this manual page - were written by Stanislav Sedov - <stas@FreeBSD.org>.

-
-
-

-

Yes, probably, report if any.

-
-
- - - - - -
June 20, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/cpufreq.4 3.html b/static/freebsd/man4/cpufreq.4 3.html deleted file mode 100644 index c2b02a7d..00000000 --- a/static/freebsd/man4/cpufreq.4 3.html +++ /dev/null @@ -1,279 +0,0 @@ - - - - - - -
CPUFREQ(4)Device Drivers ManualCPUFREQ(4)
-
-
-

-

cpufreq — CPU - frequency control framework

-
-
-

-

device cpufreq

-

-
- #include <sys/cpu.h>

-

int -
- cpufreq_levels(device_t - dev, struct cf_level - *levels, int - *count);

-

int -
- cpufreq_set(device_t - dev, const struct - cf_level *level, int - priority);

-

int -
- cpufreq_get(device_t - dev, struct cf_level - *level);

-

int -
- cpufreq_drv_settings(device_t - dev, struct cf_setting *sets, - int *count);

-

int -
- cpufreq_drv_type(device_t - dev, int - *type);

-

int -
- cpufreq_drv_set(device_t - dev, const struct - cf_setting *set);

-

int -
- cpufreq_drv_get(device_t - dev, struct cf_setting - *set);

-
-
-

-

The cpufreq driver provides a unified - kernel and user interface to CPU frequency control drivers. It combines - multiple drivers offering different settings into a single interface of all - possible levels. Users can access this interface directly via - sysctl(8) or by indicating to - /etc/rc.d/power_profile that it should switch - settings when the AC line state changes via - rc.conf(5).

-
-
-

-

These settings may be overridden by kernel drivers requesting - alternate settings. If this occurs, the original values will be restored - once the condition has passed (e.g., the system has cooled sufficiently). If - a sysctl cannot be set due to an override condition, it will return - EPERM.

-

The frequency cannot be changed if TSC is in use as the - timecounter and the hardware does not support invariant TSC. This is because - the timecounter system needs to use a source that has a constant rate. (On - invariant TSC hardware, the TSC runs at the P0 rate regardless of the - configured P-state.) Modern hardware mostly has invariant TSC. The - timecounter source can be changed with the - kern.timecounter.hardware sysctl. Available modes - are in kern.timecounter.choice sysctl entry.

-
-
dev.cpu.%d.freq
-
Current active CPU frequency in MHz.
-
dev.cpu.%d.freq_driver
-
The specific cpufreq driver used by this cpu.
-
dev.cpu.%d.freq_levels
-
Currently available levels for the CPU (frequency/power usage). Values are - in units of MHz and milliwatts.
-
dev.DEVICE.%d.freq_settings
-
Currently available settings for the driver (frequency/power usage). - Values are in units of MHz and milliwatts. This is helpful for - understanding which settings are offered by which driver for debugging - purposes.
-
debug.cpufreq.lowest
-
Lowest CPU frequency in MHz to offer to users. This setting is also - accessible via a tunable with the same name. This can be used to disable - very low levels that may be unusable on some systems.
-
debug.cpufreq.verbose
-
Print verbose messages. This setting is also accessible via a tunable with - the same name.
-
debug.hwpstate_pstate_limit
-
If enabled, the AMD hwpstate driver limits administrative control of - P-states (including by powerd(8)) to the value in the - 0xc0010061 MSR, known as "PStateCurLim[CurPstateLimit]." It is - disabled (0) by default. On some hardware, the limit register seems to - simply follow the configured P-state, which results in the inability to - ever raise the P-state back to P0 from a reduced frequency state.
-
-
-
-

-

The following device drivers offer absolute frequency control via - the cpufreq interface. Usually, only one of these - can be active at a time.

-

-
-
acpi_perf
-
ACPI CPU performance states
-
est(4)
-
Intel Enhanced SpeedStep
-
hwpstate
-
AMD Cool'n'Quiet2 used in K10 through Family 17h
-
hwpstate_intel(4)
-
Intel SpeedShift driver
-
ichss
-
Intel SpeedStep for ICH
-
powernow
-
AMD PowerNow! and Cool'n'Quiet for K7 and K8
-
smist
-
Intel SMI-based SpeedStep for PIIX4
-
-

The following device drivers offer relative frequency control and - have an additive effect:

-

-
-
acpi_throttle
-
ACPI CPU throttling
-
p4tcc
-
Pentium 4 Thermal Control Circuitry
-
-
-
-

-

Kernel components can query and set CPU frequencies through the - cpufreq kernel interface. This involves obtaining a - cpufreq device, calling - () - to get the currently available frequency levels, checking the current level - with cpufreq_get(), and setting a new one from the - list with cpufreq_set(). Each level may actually - reference more than one cpufreq driver but kernel - components do not need to be aware of this. The - total_set element of struct - cf_level provides a summary of the frequency and power for this level. - Unknown or irrelevant values are set to - CPUFREQ_VAL_UNKNOWN.

-

The - () - method takes a cpufreq device and an empty array of - levels. The count value should - be set to the number of levels available and after the function completes, - will be set to the actual number of levels returned. If there are more - levels than count will allow, it should return - E2BIG.

-

The - () - method takes a pointer to space to store a level. - After successful completion, the output will be the current active level and - is equal to one of the levels returned by - cpufreq_levels().

-

The - () - method takes a pointer a level and attempts to - activate it. The priority (i.e., - CPUFREQ_PRIO_KERN) tells - cpufreq whether to override previous settings while - activating this level. If priority is higher than the - current active level, that level will be saved and overridden with the new - level. If a level is already saved, the new level is set without overwriting - the older saved level. If cpufreq_set() is called - with a NULL level, the saved - level will be restored. If there is no saved level, - cpufreq_set() will return - ENXIO. If priority is lower - than the current active level's priority, this method returns - EPERM.

-
-
-

-

Kernel drivers offering hardware-specific CPU frequency control - export their individual settings through the cpufreq - driver interface. This involves implementing these methods: - cpufreq_drv_settings(), - cpufreq_drv_type(), - cpufreq_drv_set(), and - cpufreq_drv_get(). Additionally, the driver must - attach a device as a child of a CPU device so that these methods can be - called by the cpufreq framework.

-

The - () - method returns an array of currently available settings, each of type - struct cf_setting. The driver should set unknown or - irrelevant values to CPUFREQ_VAL_UNKNOWN. All the - following elements for each setting should be returned:

-
-
struct cf_setting {
-	int	freq;	/* CPU clock in MHz or 100ths of a percent. */
-	int	volts;	/* Voltage in mV. */
-	int	power;	/* Power consumed in mW. */
-	int	lat;	/* Transition latency in us. */
-	device_t dev;	/* Driver providing this setting. */
-};
-
-

On entry to this method, count contains the - number of settings that can be returned. On successful completion, the - driver sets it to the actual number of settings returned. If the driver - offers more settings than count will allow, it should - return E2BIG.

-

The - () - method indicates the type of settings it offers, either - CPUFREQ_TYPE_ABSOLUTE or - CPUFREQ_TYPE_RELATIVE. Additionally, the driver may - set the CPUFREQ_FLAG_INFO_ONLY flag if the settings - it provides are information for other drivers only and cannot be passed to - cpufreq_drv_set() to activate them.

-

The - () - method takes a driver setting and makes it active. If the setting is invalid - or not currently available, it should return - EINVAL.

-

The - () - method returns the currently-active driver setting. The - struct cf_setting returned must be valid for passing - to cpufreq_drv_set(), including all elements being - filled out correctly. If the driver cannot infer the current setting (even - by estimating it with - ()) - then it should set all elements to - CPUFREQ_VAL_UNKNOWN.

-
-
-

-

acpi(4), est(4), - timecounters(4), powerd(8), - sysctl(8)

-
-
-

-

Nate Lawson -
- Bruno Ducrot contributed the - powernow driver.

-
-
-

-

The following drivers have not yet been converted to the - cpufreq interface: longrun(4).

-

Notification of CPU and bus frequency changes is not implemented - yet.

-

When multiple CPUs offer frequency control, they cannot be set to - different levels and must all offer the same frequency settings.

-
-
- - - - - -
April 4, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/crypto.4 3.html b/static/freebsd/man4/crypto.4 3.html deleted file mode 100644 index 82054007..00000000 --- a/static/freebsd/man4/crypto.4 3.html +++ /dev/null @@ -1,275 +0,0 @@ - - - - - - -
CRYPTO(4)Device Drivers ManualCRYPTO(4)
-
-
-

-

crypto, cryptodev - — user-mode access to hardware-accelerated - cryptography

-
-
-

-

device crypto -
- device cryptodev

-

-
- #include <sys/ioctl.h> -
- #include <sys/time.h> -
- #include - <crypto/cryptodev.h>

-
-
-

-

The crypto driver gives user-mode - applications access to hardware-accelerated cryptographic transforms as - implemented by the crypto(9) in-kernel interface.

-

The /dev/crypto special device provides an - ioctl(2) based interface. User-mode applications open the - special device and then issue ioctl(2) calls on the - descriptor. User-mode access to /dev/crypto is - controlled by the kern.cryptodevallowsoft - sysctl(8) variable. If this variable is zero, then - user-mode sessions are only permitted to use cryptography coprocessors.

-
-
-

-

Use of the device requires a basic series of steps:

-
    -
  1. Open the /dev/crypto device.
    2. -
  2. Create a session with CIOCGSESSION or - CIOCGSESSION2. Applications will require at least - one symmetric session. Since cipher and MAC keys are tied to sessions, - many applications will require more.
    3. -
  3. Submit requests, synchronously with CIOCCRYPT or - CIOCCRYPTAEAD.
    4. -
  4. Optionally destroy a session with - CIOCFSESSION.
    5. -
  5. Close the /dev/crypto device. This will - automatically close any remaining sessions associated with the file - descriptor.
    6. -
-
-
-

-

cryptodev provides a context-based API to - traditional symmetric-key encryption (or privacy) algorithms, keyed and - unkeyed one-way hash (HMAC and MAC) algorithms, encrypt-then-authenticate - (ETA) fused operations, and authenticated encryption with additional data - (AEAD) operations. For ETA operations, drivers perform both a privacy - algorithm and an integrity-check algorithm in a single pass over the data: - either a fused encrypt/HMAC-generate operation, or a fused - HMAC-verify/decrypt operation. Similarly, for AEAD operations, drivers - perform either an encrypt/MAC-generate operation or a MAC-verify/decrypt - operation.

-

The algorithm(s) and key(s) to use are specified when a session is - created. Individual requests are able to specify per-request initialization - vectors or nonces.

-
-

-

For a list of supported algorithms, see - crypto(7).

-
-
-

-
-
- struct crypt_find_op *fop
-
-
- 
struct crypt_find_op {
-    int     crid;       /* driver id + flags */
-    char    name[32];   /* device/driver name */
-};
-
-
-
- If crid is -1, then find the driver named - name and return the id in - crid. If crid is not -1, - return the name of the driver with crid in - name. In either case, if the driver is not found, - ENOENT is returned.
-
- struct session_op *sessp
-
-
- 
struct session_op {
-    uint32_t cipher;	/* e.g. CRYPTO_AES_CBC */
-    uint32_t mac;	/* e.g. CRYPTO_SHA2_256_HMAC */
-
-    uint32_t keylen;	/* cipher key */
-    const void *key;
-    int mackeylen;	/* mac key */
-    const void *mackey;
-
-    uint32_t ses;	/* returns: ses # */
-};
-
-
-
- Create a new cryptographic session on a file descriptor for the device; that - is, a persistent object specific to the chosen privacy algorithm, - integrity algorithm, and keys specified in sessp. - The special value 0 for either privacy or integrity is reserved to - indicate that the indicated operation (privacy or integrity) is not - desired for this session. ETA sessions specify both privacy and integrity - algorithms. AEAD sessions specify only a privacy algorithm. -

Multiple sessions may be bound to a single file descriptor. - The session ID returned in sessp->ses is - supplied as a required field in the operation structure - crypt_op for future encryption or hashing - requests.

-

For non-zero privacy algorithms, the privacy algorithm must be - specified in sessp->cipher, the key length in - sessp->keylen, and the key value in the octets - addressed by sessp->key.

-

For keyed one-way hash algorithms, the one-way hash must be - specified in sessp->mac, the key length in - sessp->mackey, and the key value in the octets - addressed by sessp->mackeylen.

-

Support for a specific combination of fused privacy and - integrity-check algorithms depends on whether the underlying hardware - supports that combination. Not all combinations are supported by all - hardware, even if the hardware supports each operation as a stand-alone - non-fused operation.

-
-
- struct session2_op *sessp
-
-
- 
struct session2_op {
-    uint32_t cipher;	/* e.g. CRYPTO_AES_CBC */
-    uint32_t mac;	/* e.g. CRYPTO_SHA2_256_HMAC */
-
-    uint32_t keylen;	/* cipher key */
-    const void *key;
-    int mackeylen;	/* mac key */
-    const void *mackey;
-
-    uint32_t ses;	/* returns: ses # */
-    int	crid;		/* driver id + flags (rw) */
-    int ivlen;		/* length of nonce/IV */
-    int maclen;		/* length of MAC/tag */
-    int	pad[2];		/* for future expansion */
-};
-
-
-
- This request is similar to CIOGSESSION but adds additional fields. -

sessp->crid requests either a - specific crypto device or a class of devices (software vs hardware).

-

sessp->ivlen specifies the length of - the IV or nonce supplied with each request. If this field is set to - zero, the default IV or nonce length is used.

-

sessp->maclen specifies the length of - the MAC or authentication tag supplied or computed by each request. If - this field is set to zero, the full MAC is used.

-

The sessp->pad field must be - initialized to zero.

-
-
- struct crypt_op *cr_op
-
-
- 
struct crypt_op {
-    uint32_t ses;
-    uint16_t op;	/* e.g. COP_ENCRYPT */
-    uint16_t flags;
-    u_int len;
-    const void *src;
-    void *dst;
-    void *mac;		/* must be large enough for result */
-    const void *iv;
-};
-
-
-
- Request an encryption/decryption (or hash) operation. To encrypt, set - cr_op->op to COP_ENCRYPT. - To decrypt, set cr_op->op to - COP_DECRYPT. The field - cr_op->len supplies the length of the input - buffer; the fields cr_op->src, - cr_op->dst, cr_op->mac, - cr_op->iv supply the addresses of the input - buffer, output buffer, one-way hash, and initialization vector, - respectively. -

If a session is using either fused encrypt-then-authenticate - or an AEAD algorithm, decryption operations require the associated hash - as an input. If the hash is incorrect, the operation will fail with - EBADMSG and the output buffer will remain - unchanged.

-
-
- struct crypt_aead *cr_aead
-
-
- 
struct crypt_aead {
-    uint32_t ses;
-    uint16_t op;	/* e.g. COP_ENCRYPT */
-    uint16_t flags;
-    u_int len;
-    u_int aadlen;
-    u_int ivlen;
-    const void *src;
-    void *dst;
-    const void *aad;	/* additional authenticated data */
-    void *tag;		/* must fit for chosen TAG length */
-    const void *iv;
-};
-
-
-
- The CIOCCRYPTAEAD is similar to the - CIOCCRYPT but provides additional data in - cr_aead->aad to include in the authentication - mode.
-
- u_int32_t ses_id
-
Destroys the session identified by ses_id.
-
-
-
-
-

-

aesni(4), ipsec(4), - padlock(4), safe(4), - crypto(7), geli(8), - crypto(9)

-
-
-

-

The crypto driver first appeared in - OpenBSD 3.0. The crypto - driver was imported to FreeBSD 5.0.

-
-
-

-

Error checking and reporting is weak.

-

The values specified for symmetric-key key sizes to - CIOCGSESSION must exactly match the values expected - by opencrypto(9). The output buffer and MAC buffers - supplied to CIOCCRYPT must follow whether privacy or - integrity algorithms were specified for session: if you request a - non-NULL algorithm, you must - supply a suitably-sized buffer.

-
-
- - - - - -
October 6, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ctl.4 3.html b/static/freebsd/man4/ctl.4 3.html deleted file mode 100644 index 33136be2..00000000 --- a/static/freebsd/man4/ctl.4 3.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - -
CTL(4)Device Drivers ManualCTL(4)
-
-
-

-

ctl — CAM Target - Layer

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ctl
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ctl_load="YES"
-
-
-
-

-

The ctl subsystem provides SCSI target - devices emulation. It supports features such as:

-

-
    -
  • Disk, CD-ROM and processor device emulation
    • -
  • Tagged queueing
    • -
  • SCSI task attribute support (ordered, head of queue, simple tags)
    • -
  • SCSI implicit command ordering support
    • -
  • Full task management support (abort, query, reset, etc.)
    • -
  • Support for multiple ports, initiators, targets and backing stores
    • -
  • Support for VMWare VAAI and Microsoft ODX offload (COMPARE AND WRITE, - XCOPY, POPULATE TOKEN/WRITE USING TOKEN, WRITE SAME and UNMAP)
    • -
  • Persistent reservation support
    • -
  • Extensive VPD/mode/log pages support
    • -
  • Featured error reporting, error injection and basic SMART support
    • -
  • High Availability clustering support with ALUA
    • -
  • All I/O handled in-kernel, no userland context switch overhead
    • -
-

The ctl subsystem includes multiple - frontends to provide access using different transport protocols and - implementations:

-
-
camsim
-
Provides access for local system via virtual initiator mode - CAM(4) SIM.
-
camtgt
-
Provides access for remote systems via target mode - CAM(4) SIMs, such as Fibre Channel - isp(4) and mpt(4).
-
cfumass
-
Provides access for remote systems via USB Mass Storage Class Bulk Only - (BBB) Transport.
-
ha
-
Internal frontend used to receive requests from other node ports in High - Availability cluster.
-
ioctl
-
Provides access for local user-level applications via - ioctl(2) based API.
-
iscsi
-
Provides access for remote systems via the iSCSI protocol using - cfiscsi(4).
-
tpc
-
Internal frontend used to receive requests from Third Party Copy engine, - implementing copy offload operations.
-
-

The ctl subsystem includes two backends to - create logical units using different kinds of backing stores:

-
-
block
-
Stores data in ZFS ZVOLs, files or raw block devices.
-
ramdisk
-
Stores data in RAM, that makes it mostly useful for performance testing. - Depending on configured capacity can work as black hole, thin or thick - provisioned disk.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.cam.ctl.debug
-
Bit mask of enabled CTL log levels: -
-
-
1
-
log commands with errors;
-
2
-
log all commands;
-
4
-
log data for commands other then READ/WRITE.
-
-
- Defaults to 0.
-
kern.cam.ctl.ha_id
-
Specifies unique position of this node within High Availability cluster. - Default is 0 -- no HA, 1 and 2 -- HA enabled at specified position.
-
kern.cam.ctl.ha_mode
-
Specifies High Availability cluster operation mode: -
-
-
0
-
Active/Standby -- primary node has backend access and processes - requests, while secondary can only do basic LUN discovery and - reservation;
-
1
-
Active/Active -- both nodes have backend access and process requests, - while secondary node synchronizes processing with primary one;
-
2
-
Active/Active -- primary node has backend access and processes - requests, while secondary node forwards all requests and data to - primary one;
-
-
- All above modes require established connection between HA cluster nodes. If - connection is not configured, secondary node will report Unavailable - state; if configured but not established -- Transitioning state. Defaults - to 0.
-
kern.cam.ctl.ha_peer
-
String value, specifying method to establish connection to peer HA node. - Can be "listen IP:port", "connect IP:port" or - empty.
- -
Reports present state of connection between HA cluster nodes: -
-
-
0
-
not configured;
-
1
-
configured but not established;
-
2
-
established.
-
-
-
-
kern.cam.ctl.ha_role
-
Specifies default role of this node: -
-
-
0
-
primary;
-
1
-
secondary.
-
-
- This role can be overridden on per-LUN basis using "ha_role" LUN - option, so that for one LUN one node is primary, while for another -- - another. Role change from primary to secondary for HA modes 0 and 2 closes - backends, the opposite change -- opens. If there is no primary node (both - nodes are secondary, or secondary node has no connection to primary one), - secondary node(s) report Transitioning state. State with two primary nodes - is illegal (split brain condition).
-
-
-
-

-

The following variables are available as - loader(8) tunables:

-
-
kern.cam.ctl.max_luns
-
Specifies the maximum number of LUNs we support, must be a power of 2. The - default value is 1024.
-
kern.cam.ctl.max_ports
-
Specifies the maximum number of ports we support, must be a power of 2. - The default value is 1024.
-
-
-
-

-

cfiscsi(4), cfumass(4), - ctladm(8), ctld(8), - ctlstat(8)

-
-
-

-

The ctl subsystem first appeared in - FreeBSD 9.1.

-
-
-

-

The ctl subsystem was originally written - by Kenneth Merry - <ken@FreeBSD.org>. - Later work was done by -
- Alexander Motin - <mav@FreeBSD.org>.

-
-
- - - - - -
March 29, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/cue.4 3.html b/static/freebsd/man4/cue.4 3.html deleted file mode 100644 index 2d1603cf..00000000 --- a/static/freebsd/man4/cue.4 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
CUE(4)Device Drivers ManualCUE(4)
-
-
-

-

cue — CATC - USB-EL1210A USB Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device cue
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_cue_load="YES"
-
-
-
-

-

The cue driver provides support for USB - Ethernet adapters based on the Computer Access Technology Corporation's - USB-EL1210A chipset.

-

The USB-EL1210A supports a 512-bit multicast hash filter, single - perfect filter entry for the station address and promiscuous mode. Packets - are received and transmitted over separate USB bulk transfer endpoints.

-

The CATC chipset supports only 10Mbps half-duplex - mode, hence there are no - () - modes to select.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The cue driver supports CATC USB-EL1210A - based USB Ethernet adapters including:

-

-
    -
  • Belkin F5U011/F5U111
    • -
  • CATC Netmate
    • -
  • CATC Netmate II
    • -
  • SmartBridges SmartLink
    • -
-
-
-

-
-
cue%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
cue%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
-
-
-

-

arp(4), netintro(4), - ng_ether(4), ifconfig(8)

-
-
-

-

The cue device driver first appeared in - FreeBSD 4.0.

-
-
-

-

The cue driver was written by - Bill Paul - <wpaul@ee.columbia.edu>.

-
-
- - - - - -
July 24, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/cxgb.4 3.html b/static/freebsd/man4/cxgb.4 3.html deleted file mode 100644 index 7d42789c..00000000 --- a/static/freebsd/man4/cxgb.4 3.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - -
CXGB(4)Device Drivers ManualCXGB(4)
-
-
-

-

cxgb — Chelsio T3 - 10 Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device firmware -
-device cxgb
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_cxgb_load="YES"
-
-
-
-

-

The cxgb driver supports Transmit/Receive - checksum offload, Jumbo Frames, TCP segmentation offload (TSO), Large - Receive Offload (LRO), VLAN hardware insertion / extraction, and VLAN - checksum offload. For further hardware information, see - http://www.chelsio.com/.

-

For questions related to hardware requirements, refer to the - documentation supplied with your Chelsio T3 adapter. All hardware - requirements listed apply to use with FreeBSD.

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 9000.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The cxgb driver supports 10 Gigabit and 1 - Gigabit Ethernet adapters based on the T3 and T3B chipset:

-

-
    -
  • Chelsio 10GBase-CX4
    • -
  • Chelsio 10GBase-LR
    • -
  • Chelsio 10GBase-SR
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
-

-
-
cxgb%d: Unable to allocate bus resource: memory
-
A fatal initialization error has occurred.
-
cxgb%d: Unable to allocate bus resource: interrupt
-
A fatal initialization error has occurred.
-
cxgb%d: Could not find firmware image %s
-
The appropriate firmware kld module was not installed. This is a fatal - initialization error.
-
-
-
-

-

For general information and support, go to the Chelsio support - website at: http://www.chelsio.com/.

-

If an issue is identified with the released source code on the - supported kernel with a supported adapter, email the specific information - related to the issue to - <support@chelsio.com>.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The cxgb device driver first appeared in - FreeBSD 6.3 and FreeBSD - 7.0.

-
-
-

-

The cxgb driver was written by - Kip Macy - <kmacy@FreeBSD.org> - with substantial support from Scott Long - <scottl@FreeBSD.org>.

-
-
- - - - - -
March 14, 2007FreeBSD 15.0
diff --git a/static/freebsd/man4/cxgbe.4 3.html b/static/freebsd/man4/cxgbe.4 3.html deleted file mode 100644 index 96010d56..00000000 --- a/static/freebsd/man4/cxgbe.4 3.html +++ /dev/null @@ -1,382 +0,0 @@ - - - - - - -
CXGBE(4)Device Drivers ManualCXGBE(4)
-
-
-

-

cxgbe — Chelsio - T7, T6, T5, and T4 based 1Gb to 400Gb Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device cxgbe
-

To load the driver as a module at boot time, place the following - lines in loader.conf(5):

-
-
t7fw_cfg_load="YES"
-t6fw_cfg_load="YES"
-t5fw_cfg_load="YES"
-t4fw_cfg_load="YES"
-if_cxgbe_load="YES"
-
-
-
-

-

The cxgbe driver provides support for PCI - Express Ethernet adapters based on the Chelsio Terminator 7, Terminator 6, - Terminator 5, and Terminator 4 ASICs (T7, T6, T5, and T4). The driver - supports Jumbo Frames, Transmit/Receive checksum offload, TCP segmentation - offload (TSO), Large Receive Offload (LRO), VLAN tag insertion/extraction, - VLAN checksum offload, VLAN TSO, VXLAN checksum offload, VXLAN TSO, and - Receive Side Steering (RSS). For further hardware information and questions - related to hardware requirements, see - http://www.chelsio.com/.

-

The cxgbe driver uses different names for - devices based on the associated ASIC:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
T7chechnexvche
T6cct6nexvcc
T5cxlt5nexvcxl
T4cxgbet4nexvcxgbe
-

Loader tunables with the hw.cxgbe prefix apply to all cards. The - driver provides sysctl MIBs for both ports and parent devices using the - names above. For example, a T5 adapter provides port MIBs under dev.cxl and - adapter-wide MIBs under dev.t5nex. References to sysctl MIBs in the - remainder of this page use dev.<port> for port MIBs and - dev.<nexus> for adapter-wide MIBs.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The cxgbe driver supports 400Gb, 200Gb, - 50Gb, and 10Gb Ethernet adapters based on the T7 ASIC:

-

-
    -
  • Chelsio S71400
    • -
  • Chelsio S72200
    • -
  • Chelsio S72200-OCP
    • -
  • Chelsio T72200
    • -
  • Chelsio T72200-DPU
    • -
  • Chelsio T72200-FH
    • -
  • Chelsio T72200-FH-DPU
    • -
  • Chelsio T72200-OCP
    • -
  • Chelsio S7450-DPU
    • -
  • Chelsio S7450-OCP
    • -
  • Chelsio T71200-iNIC
    • -
  • Chelsio T7250
    • -
  • Chelsio T7210-BT
    • -
  • Chelsio T7410-BT-OCP
    • -
-

The cxgbe driver supports 100Gb and 25Gb - Ethernet adapters based on the T6 ASIC:

-

-
    -
  • Chelsio T6225-CR
    • -
  • Chelsio T6225-SO-CR
    • -
  • Chelsio T62100-LP-CR
    • -
  • Chelsio T62100-SO-CR
    • -
  • Chelsio T62100-CR
    • -
-

The cxgbe driver supports 40Gb, 10Gb and - 1Gb Ethernet adapters based on the T5 ASIC:

-

-
    -
  • Chelsio T580-CR
    • -
  • Chelsio T580-LP-CR
    • -
  • Chelsio T580-LP-SO-CR
    • -
  • Chelsio T560-CR
    • -
  • Chelsio T540-CR
    • -
  • Chelsio T540-LP-CR
    • -
  • Chelsio T522-CR
    • -
  • Chelsio T520-LL-CR
    • -
  • Chelsio T520-CR
    • -
  • Chelsio T520-SO
    • -
  • Chelsio T520-BT
    • -
  • Chelsio T504-BT
    • -
-

The cxgbe driver supports 10Gb and 1Gb - Ethernet adapters based on the T4 ASIC:

-

-
    -
  • Chelsio T420-CR
    • -
  • Chelsio T422-CR
    • -
  • Chelsio T440-CR
    • -
  • Chelsio T420-BCH
    • -
  • Chelsio T440-BCH
    • -
  • Chelsio T440-CH
    • -
  • Chelsio T420-SO
    • -
  • Chelsio T420-CX
    • -
  • Chelsio T420-BT
    • -
  • Chelsio T404-BT
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). - There are multiple tunables that control the number of queues of various - types. A negative value for such a tunable instructs the driver to create up - to that many queues if there are enough CPU cores available.

-
-
hw.cxgbe.ntxq
-
Number of NIC tx queues used for a port. The default is 16 or the number - of CPU cores in the system, whichever is less.
-
hw.cxgbe.nrxq
-
Number of NIC rx queues used for a port. The default is 8 or the number of - CPU cores in the system, whichever is less.
-
hw.cxgbe.nofldtxq
-
Number of TOE tx queues used for a port. The default is 8 or the number of - CPU cores in the system, whichever is less.
-
hw.cxgbe.nofldrxq
-
Number of TOE rx queues used for a port. The default is 2 or the number of - CPU cores in the system, whichever is less.
-
hw.cxgbe.num_vis
-
Number of virtual interfaces (VIs) created for each port. Each virtual - interface creates a separate network interface. The first virtual - interface on each port is required and represents the primary network - interface on the port. Additional virtual interfaces on a port are named - using the Virtual Interface name from the table above. Additional virtual - interfaces use a single pair of queues for rx and tx as well an additional - pair of queues for TOE rx and tx. The default is 1.
-
hw.cxgbe.holdoff_timer_idx
-
 
-
hw.cxgbe.holdoff_timer_idx_ofld
-
Timer index value used to delay interrupts. The holdoff timer list has the - values 1, 5, 10, 50, 100, and 200 by default (all values are in - microseconds) and the index selects a value from this list. - holdoff_timer_idx_ofld applies to queues used for TOE rx. The default - value is 1 which means the timer value is 5us. Different interfaces can be - assigned different values at any time via the - dev.<port>.X.holdoff_tmr_idx and - dev.<port>.X.holdoff_tmr_idx_ofld sysctls.
-
hw.cxgbe.holdoff_pktc_idx
-
 
-
hw.cxgbe.holdoff_pktc_idx_ofld
-
Packet-count index value used to delay interrupts. The packet-count list - has the values 1, 8, 16, and 32 by default, and the index selects a value - from this list. holdoff_pktc_idx_ofld applies to queues used for TOE rx. - The default value is -1 which means packet counting is disabled and - interrupts are generated based solely on the holdoff timer value. - Different interfaces can be assigned different values via the - dev.<port>.X.holdoff_pktc_idx and - dev.<port>.X.holdoff_pktc_idx_ofld sysctls. These sysctls work only - when the interface has never been marked up (as done by ifconfig up).
-
hw.cxgbe.qsize_txq
-
Number of entries in a transmit queue's descriptor ring. A buf_ring of the - same size is also allocated for additional software queuing. See - ifnet(9). The default value is 1024. Different - interfaces can be assigned different values via the - dev.<port>.X.qsize_txq sysctl. This sysctl works only when the - interface has never been marked up (as done by ifconfig up).
-
hw.cxgbe.qsize_rxq
-
Number of entries in a receive queue's descriptor ring. The default value - is 1024. Different interfaces can be assigned different values via the - dev.<port>.X.qsize_rxq sysctl. This sysctl works only when the - interface has never been marked up (as done by ifconfig up).
-
hw.cxgbe.interrupt_types
-
Permitted interrupt types. Bit 0 represents INTx (line interrupts), bit 1 - MSI, and bit 2 MSI-X. The default is 7 (all allowed). The driver selects - the best possible type out of the allowed types.
-
hw.cxgbe.pcie_relaxed_ordering
-
PCIe Relaxed Ordering. -1 indicates the driver should determine whether to - enable or disable PCIe RO. 0 disables PCIe RO. 1 enables PCIe RO. 2 - indicates the driver should not modify the PCIe RO setting. The default is - -1.
-
hw.cxgbe.fw_install
-
0 prohibits the driver from installing a firmware on the card. 1 allows - the driver to install a new firmware if internal driver heuristics - indicate that the new firmware is preferable to the one already on the - card. 2 instructs the driver to always install the new firmware on the - card as long as it is compatible with the driver and is a different - version than the one already on the card. The default is 1.
-
hw.cxgbe.fl_pktshift
-
Number of padding bytes inserted before the beginning of an Ethernet frame - in the receive buffer. The default value is 0. A value of 2 would ensure - that the Ethernet payload (usually the IP header) is at a 4 byte aligned - address. 0-7 are all valid values.
-
hw.cxgbe.fl_pad
-
A non-zero value ensures that writes from the hardware to a receive buffer - are padded up to the specified boundary. The default is -1 which lets the - driver pick a pad boundary. 0 disables trailer padding completely.
-
hw.cxgbe.cong_drop
-
Controls the hardware response to congestion. -1 disables congestion - feedback and is not recommended. 0 instructs the hardware to backpressure - its pipeline on congestion. This usually results in the port emitting - PAUSE frames. 1 instructs the hardware to drop frames destined for - congested queues. 2 instructs the hardware to both backpressure the - pipeline and drop frames.
-
hw.cxgbe.pause_settings
-
PAUSE frame settings. Bit 0 is rx_pause, bit 1 is tx_pause, bit 2 is - pause_autoneg. rx_pause = 1 instructs the hardware to heed incoming PAUSE - frames, 0 instructs it to ignore them. tx_pause = 1 allows the hardware to - emit PAUSE frames when its receive FIFO reaches a high threshold, 0 - prohibits the hardware from emitting PAUSE frames. pause_autoneg = 1 - overrides the rx_pause and tx_pause bits and instructs the hardware to - negotiate PAUSE settings with the link peer. The default is 7 (all three = - 1). This tunable establishes the default PAUSE settings for all ports. - Settings can be displayed and controlled on a per-port basis via the - dev.<port>.X.pause_settings sysctl.
-
hw.cxgbe.fec
-
Forward Error Correction settings. -1 (default) means driver should - automatically pick a value. 0 disables FEC. Finer grained control can be - achieved by setting individual bits. Bit 0 enables RS FEC, bit 1 enables - BASE-R FEC (aka Firecode FEC), bit 2 enables NO FEC, and bit 6 enables the - FEC that is recommended by the transceiver/cable that is plugged in. These - bits can be set together in any combination. This tunable establishes the - default FEC settings for all ports. Settings can be controlled on a - per-port basis via the dev.<port>.X.requested_fec sysctl. The FEC in - use on the link is available in dev.<port>.X.link_fec when the link - is up.
-
hw.cxgbe.autoneg
-
Link autonegotiation settings. This tunable establishes the default - autonegotiation settings for all ports. Settings can be displayed and - controlled on a per-port basis via the dev.<port>.X.autoneg sysctl. - 0 disables autonegotiation. 1 enables autonegotiation. The default is -1 - which lets the driver pick a value. dev.<port>.X.autoneg is -1 for - port and module combinations that do not support autonegotiation.
-
hw.cxgbe.buffer_packing
-
Allow the hardware to deliver multiple frames in the same receive buffer - opportunistically. The default is -1 which lets the driver decide. 0 or 1 - explicitly disable or enable this feature.
-
hw.cxgbe.largest_rx_cluster
-
 
-
hw.cxgbe.safest_rx_cluster
-
Sizes of rx clusters. Each of these must be set to one of the sizes - available (usually 2048, 4096, 9216, and 16384) and largest_rx_cluster - must be greater than or equal to safest_rx_cluster. The defaults are 16384 - and 4096 respectively. The driver never attempts to allocate a receive - buffer larger than largest_rx_cluster and falls back to allocating buffers - of safest_rx_cluster size if an allocation larger than safest_rx_cluster - fails. Note that largest_rx_cluster merely establishes a ceiling -- the - driver is allowed to allocate buffers of smaller sizes.
-
hw.cxgbe.config_file
-
Select a pre-packaged device configuration file. A configuration file - contains a recipe for partitioning and configuring the hardware resources - on the card. This tunable is for specialized applications only and should - not be used in normal operation. The configuration profile currently in - use is available in the dev.<nexus>.X.cf and - dev.<nexus>.X.cfcsum sysctls.
-
hw.cxgbe.linkcaps_allowed
-
 
-
hw.cxgbe.niccaps_allowed
-
 
-
hw.cxgbe.toecaps_allowed
-
 
-
hw.cxgbe.rdmacaps_allowed
-
 
-
hw.cxgbe.iscsicaps_allowed
-
 
-
hw.cxgbe.fcoecaps_allowed
-
Disallowing capabilities provides a hint to the driver and firmware to not - reserve hardware resources for that feature. Each of these is a bit field - with a bit for each sub-capability within the capability. This tunable is - for specialized applications only and should not be used in normal - operation. The capabilities for which hardware resources have been - reserved are listed in dev.<nexus>.X.*caps sysctls.
-
hw.cxgbe.tx_vm_wr
-
Setting this to 1 instructs the driver to use VM work requests to transmit - data. This lets PF interfaces transmit frames to VF interfaces over the - internal switch in the ASIC. Note that the cxgbev(4) VF - driver always uses VM work requests and is not affected by this tunable. - The default value is 0 and should be changed only if PF and VF interfaces - need to communicate with each other. Different interfaces can be assigned - different values using the dev.<port>.X.tx_vm_wr sysctl when the - interface is administratively down.
-
hw.cxgbe.attack_filter
-
Set to 1 to enable the "attack filter". Default is 0. The attack - filter will drop an incoming frame if any of these conditions is true: src - ip/ip6 == dst ip/ip6; tcp and src/dst ip is not unicast; src/dst ip is - loopback (127.x.y.z); src ip6 is not unicast; src/dst ip6 is loopback - (::1/128) or unspecified (::/128); tcp and src/dst ip6 is mcast - (ff00::/8). This facility is available on T4 and T5 based cards only.
-
hw.cxgbe.drop_ip_fragments
-
Set to 1 to drop all incoming IP fragments. Default is 0. Note that this - drops valid frames.
-
hw.cxgbe.drop_pkts_with_l2_errors
-
Set to 1 to drop incoming frames with Layer 2 length or checksum errors. - Default is 1.
-
hw.cxgbe.drop_pkts_with_l3_errors
-
Set to 1 to drop incoming frames with IP version, length, or checksum - errors. The IP checksum is validated for TCP or UDP packets only. Default - is 0.
-
hw.cxgbe.drop_pkts_with_l4_errors
-
Set to 1 to drop incoming frames with Layer 4 (TCP or UDP) length, - checksum, or other errors. Default is 0.
-
-
-
-

-

For general information and support, go to the Chelsio support - website at: http://www.chelsio.com/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - <support@chelsio.com>.

-
-
-

-

arp(4), ccr(4), - cxgb(4), cxgbev(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The cxgbe device driver first appeared in - FreeBSD 9.0. Support for T5 cards first appeared in - FreeBSD 9.2 and FreeBSD - 10.0. Support for T6 cards first appeared in FreeBSD - 11.1 and FreeBSD 12.0. Support for T7 cards - first appeared in FreeBSD 15.0.

-
-
-

-

The cxgbe driver was written by - Navdeep Parhar - <np@FreeBSD.org>.

-
-
- - - - - -
December 17, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/cxgbev.4 3.html b/static/freebsd/man4/cxgbev.4 3.html deleted file mode 100644 index adcc7c91..00000000 --- a/static/freebsd/man4/cxgbev.4 3.html +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - -
CXGBEV(4)Device Drivers ManualCXGBEV(4)
-
-
-

-

cxgbev — Chelsio - T4-, T5-, and T6-based 100Gb, 40Gb, 25Gb, 10Gb, and 1Gb Ethernet VF - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device cxgbe -
-device cxgbev
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_cxgbev_load="YES"
-
-
-
-

-

The cxgbev driver provides support for - Virtual Functions on PCI Express Ethernet adapters based on the Chelsio - Terminator 4, Terminator 5, and Terminator 6 ASICs (T4, T5, and T6). The - driver supports Jumbo Frames, Transmit/Receive checksum offload, TCP - segmentation offload (TSO), Large Receive Offload (LRO), VLAN tag - insertion/extraction, VLAN checksum offload, VLAN TSO, and Receive Side - Steering (RSS). For further hardware information and questions related to - hardware requirements, see - http://www.chelsio.com/.

-

The cxgbev driver uses different names for - devices based on the associated ASIC:

- - - - - - - - - - - - - - - - - - - - - -
T4cxgbevt4vf
T5cxlvt5vf
T6ccvt6vf
-

Loader tunables with the hw.cxgbe prefix apply to VFs from all - cards. The Physical Function driver for Chelsio Terminator adapters shares - these tunables. The driver provides sysctl MIBs for both ports and parent - devices using the names above. For example, a T5 VF provides port MIBs under - dev.cxlv and parent device MIBs under dev.t5vf. References to sysctl MIBs in - the remainder of this page use dev.<port> for port MIBs and - dev.<nexus> for parent device MIBs.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The cxgbev driver supports Virtual - Functions on 100Gb and 25Gb Ethernet adapters based on the T6 ASIC:

-

-
    -
  • Chelsio T6225-CR
    • -
  • Chelsio T6225-SO-CR
    • -
  • Chelsio T62100-LP-CR
    • -
  • Chelsio T62100-SO-CR
    • -
  • Chelsio T62100-CR
    • -
-

The cxgbev driver supports Virtual - Functions on 40Gb, 10Gb and 1Gb Ethernet adapters based on the T5 ASIC:

-

-
    -
  • Chelsio T580-CR
    • -
  • Chelsio T580-LP-CR
    • -
  • Chelsio T580-LP-SO-CR
    • -
  • Chelsio T560-CR
    • -
  • Chelsio T540-CR
    • -
  • Chelsio T540-LP-CR
    • -
  • Chelsio T522-CR
    • -
  • Chelsio T520-LL-CR
    • -
  • Chelsio T520-CR
    • -
  • Chelsio T520-SO
    • -
  • Chelsio T520-BT
    • -
  • Chelsio T504-BT
    • -
-

The cxgbev driver supports Virtual - Functions on 10Gb and 1Gb Ethernet adapters based on the T4 ASIC:

-

-
    -
  • Chelsio T420-CR
    • -
  • Chelsio T422-CR
    • -
  • Chelsio T440-CR
    • -
  • Chelsio T420-BCH
    • -
  • Chelsio T440-BCH
    • -
  • Chelsio T440-CH
    • -
  • Chelsio T420-SO
    • -
  • Chelsio T420-CX
    • -
  • Chelsio T420-BT
    • -
  • Chelsio T404-BT
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.cxgbe.ntxq
-
Number of tx queues used for a port. The default is 16 or the number of - CPU cores in the system, whichever is less.
-
hw.cxgbe.nrxq
-
Number of rx queues used for a port. The default is 8 or the number of CPU - cores in the system, whichever is less.
-
hw.cxgbe.holdoff_timer_idx
-
Timer index value used to delay interrupts. The holdoff timer list has the - values 1, 5, 10, 50, 100, and 200 by default (all values are in - microseconds) and the index selects a value from this list. The default - value is 1 which means the timer value is 5us. Different interfaces can be - assigned different values at any time via the - dev.<port>.X.holdoff_tmr_idx sysctl.
-
hw.cxgbe.holdoff_pktc_idx
-
Packet-count index value used to delay interrupts. The packet-count list - has the values 1, 8, 16, and 32 by default, and the index selects a value - from this list. The default value is -1 which means packet counting is - disabled and interrupts are generated based solely on the holdoff timer - value. Different interfaces can be assigned different values via the - dev.<port>.X.holdoff_pktc_idx sysctl. This sysctl works only when - the interface has never been marked up (as done by ifconfig up).
-
hw.cxgbe.qsize_txq
-
Number of entries in a transmit queue's descriptor ring. A buf_ring of the - same size is also allocated for additional software queuing. See - ifnet(9). The default value is 1024. Different - interfaces can be assigned different values via the - dev.<port>.X.qsize_txq sysctl. This sysctl works only when the - interface has never been marked up (as done by ifconfig up).
-
hw.cxgbe.qsize_rxq
-
Number of entries in a receive queue's descriptor ring. The default value - is 1024. Different interfaces can be assigned different values via the - dev.<port>.X.qsize_rxq sysctl. This sysctl works only when the - interface has never been marked up (as done by ifconfig up).
-
hw.cxgbe.interrupt_types
-
Permitted interrupt types. Bit 0 represents INTx (line interrupts), bit 1 - MSI, and bit 2 MSI-X. The default is 7 (all allowed). The driver selects - the best possible type out of the allowed types. Note that Virtual - Functions do not support INTx interrupts and fail to attach if neither MSI - nor MSI-X are enabled.
-
hw.cxgbe.fl_pktshift
-
Number of padding bytes inserted before the beginning of an Ethernet frame - in the receive buffer. The default value of 2 ensures that the Ethernet - payload (usually the IP header) is at a 4 byte aligned address. 0-7 are - all valid values.
-
hw.cxgbe.fl_pad
-
A non-zero value ensures that writes from the hardware to a receive buffer - are padded up to the specified boundary. The default is -1 which lets the - driver pick a pad boundary. 0 disables trailer padding completely.
-
hw.cxgbe.buffer_packing
-
Allow the hardware to deliver multiple frames in the same receive buffer - opportunistically. The default is -1 which lets the driver decide. 0 or 1 - explicitly disable or enable this feature.
-
hw.cxgbe.allow_mbufs_in_cluster
-
1 allows the driver to lay down one or more mbufs within the receive - buffer opportunistically. This is the default. 0 prohibits the driver from - doing so.
-
hw.cxgbe.largest_rx_cluster
-
 
-
hw.cxgbe.safest_rx_cluster
-
Sizes of rx clusters. Each of these must be set to one of the sizes - available (usually 2048, 4096, 9216, and 16384) and largest_rx_cluster - must be greater than or equal to safest_rx_cluster. The defaults are 16384 - and 4096 respectively. The driver never attempts to allocate a receive - buffer larger than largest_rx_cluster and falls back to allocating buffers - of safest_rx_cluster size if an allocation larger than safest_rx_cluster - fails. Note that largest_rx_cluster merely establishes a ceiling -- the - driver is allowed to allocate buffers of smaller sizes.
-
-

Certain settings and resources for Virtual Functions are dictated - by the parent Physical Function driver. For example, the Physical Function - driver limits the number of queues available to a Virtual Function. Some of - these limits can be adjusted in the firmware configuration file used with - the Physical Function driver.

-

The PAUSE settings on the port of a Virtual Function are inherited - from the settings of the same port on the Physical Function. Virtual - Functions cannot modify the setting and track changes made to the associated - port's setting by the Physical Function driver.

-

Receive queues on a Virtual Function always drop packets in - response to congestion (equivalent to setting - hw.cxgbe.cong_drop to 1).

-

The VF driver currently depends on the PF driver. As a result, - loading the VF driver also loads the PF driver as a dependency.

-
-
-

-

For general information and support, go to the Chelsio support - website at: http://www.chelsio.com/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - <support@chelsio.com>.

-
-
-

-

arp(4), cxgbe(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The cxgbev device driver first appeared in - FreeBSD 11.1 and FreeBSD - 11.1.

-
-
-

-

The cxgbev driver was written by - Navdeep Parhar - <np@FreeBSD.org> and - John Baldwin - <jhb@FreeBSD.org>.

-
-
- - - - - -
November 10, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/cyapa.4 3.html b/static/freebsd/man4/cyapa.4 3.html deleted file mode 100644 index 80f8f9b8..00000000 --- a/static/freebsd/man4/cyapa.4 3.html +++ /dev/null @@ -1,216 +0,0 @@ - - - - - - -
CYAPA(4)Device Drivers ManualCYAPA(4)
-
-
-

-

cyapa — Cypress - APA trackpad with I2C interface driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into the kernel configuration file:

-
device cyapa -
-device ig4 -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
cyapa_load="YES"
-ig4_load="YES"
-
-

On many Chromebook models this driver can be automatically - configured with the help of the chromebook_platform(4) - driver. Alternatively, the

-
- - - - - -
cyapadriver can be manually configured in - /boot/device.hints: -
- hint.cyapa.0.at="iicbus0" -
- hint.cyapa.0.addr="0xCE" -
- hint.cyapa.1.at="iicbus1" -
- hint.cyapa.1.addr="0xCE"
-
-
-

-

The cyapa driver provides support for the - Cypress APA trackpad. It emulates the IntelliMouse PS/2 protocol. It - supports basic mouse ioctls, so that moused(8) is - supported properly.

-
-

-
-
                   2/3               1/3
-          +--------------------+------------+
-          |                    |   Middle   |
-          |                    |   Button   |
-          |       Left         |            |
-          |      Button        +------------+
-          |                    |   Right    |
-          |                    |   Button   |
-          +--------------------+............|
-          |     Thumb/Button Area           | 15%
-          +---------------------------------+
-
-
-
-

-
-
Two finger scrolling
-
Use two fingers for Z axis scrolling.
-
Button down/second finger
-
While one finger clicks and holds down the touchpad, the second finger can - be used to move the mouse cursor. This can be useful for drawing or - selecting text.
-
Thumb/Button area
-
The lower 15% of the trackpad will not affect the mouse cursor position. - This allows for high precision clicking, by controlling the cursor with - the index finger and pushing/holding the pad down with the thumb.
-
Trackpad button
-
Push physical button. The left two thirds of the pad issues a LEFT button - event. The upper right corner issues a MIDDLE button event. The lower - right corner issues a RIGHT button. Optionally, tap to click can be - enabled (see below).
-
-

On a system using device.hints(5), these values - are configurable for cyapa:

-
-
hint.cyapa.%d.at
-
target iicbus(4).
-
hint.cyapa.%d.addr
-
cyapa i2c address on the - iicbus(4).
-
-
-
-
-

-

These sysctl(8) variables are available:

-
-
debug.cyapa_idle_freq
-
Scan frequency in idle mode, the default is 1.
-
debug.cyapa_slow_freq
-
Scan frequency in slow mode, the default is 20.
-
debug.cyapa_norm_freq
-
Scan frequency in normal mode, the default is 100.
-
debug.cyapa_minpressure
-
Minimum pressure to detect a finger, the default is 12.
-
debug.cyapa_enable_tapclick
-
Controls tap to click. Possible values: -
-
0
-
Tap to click is disabled. This is the default value.
-
1
-
Tap to click always generates a left mouse button event.
-
2
-
Tap to click generates left mouse button event if the left 2/3rds of - the pad are tapped and a right mouse button event otherwise.
-
3
-
Tap to click generates mouse button events as if the physical button - was pressed (see DESCRIPTION - above).
-
-
-
debug.cyapa_tapclick_min_ticks
-
Minimum tap duration in ticks to create a click, the default is 1.
-
debug.cyapa_tapclick_max_ticks
-
Maximum tap duration in ticks to create a click, the default is 8.
-
debug.cyapa_move_min_ticks
-
Minimum ticks before cursor movement occurs, the default is 4.
-
debug.cyapa_scroll_wait_ticks
-
Ticks to wait before starting to scroll, the default is 0.
-
debug.cyapa_scroll_stick_ticks
-
Ticks while preventing cursor movement on single finger after scroll, the - default is 15.
-
debug.cyapa_thumbarea_percent
-
Size of bottom thumb area in percent, the default is 15.
-
debug.cyapa_debug
-
Setting this to a non-zero value enables debug output to console and - syslog, the default is 0.
-
debug.cyapa_reset
-
Setting this to a non-zero value reinitializes the device. The sysctl - resets to zero immediately.
-
-
-
-

-

cyapa creates - /dev/cyapa0, which presents the mouse as an - IntelliMouse PS/2 device. It supports - moused(8) levels 0 through 2, level 1 is used by - default.

-
-
-

-

To use cyapa with - moused(8), add the following lines to the - rc.conf(5) file:

-

-
moused_enable="YES"
-
moused_port="/dev/cyapa0"
-

If vertical scrolling is not desired, add

-

-
moused_flags="-l0"
-

to rc.conf(5).

-

Enable tap to click for the left and the right mouse button and - disable the thumb area by adding these lines to the - sysctl.conf(5) file:

-

-
debug.cyapa_thumbarea_percent=0
-
debug.cyapa_enable_tapclick=2
-
-
-

-

chromebook_platform(4), - ig4(4), iicbus(4), - sysmouse(4), moused(8)

-
-
-

-

The original cyapa driver was written for - DragonFly by Matthew - Dillon.

-

It has been ported, modified, and enhanced for - FreeBSD by Michael Gmelin - <freebsd@grem.de>.

-

This manual page was written by Michael - Gmelin - <freebsd@grem.de>.

-
-
-

-

The cyapa driver detects the device from - the I2C address. This might have unforeseen consequences if the - initialization sequence is sent to an unknown device at that address.

-
-
- - - - - -
December 18, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/da.4 3.html b/static/freebsd/man4/da.4 3.html deleted file mode 100644 index dcb1ffe7..00000000 --- a/static/freebsd/man4/da.4 3.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - -
DA(4)Device Drivers ManualDA(4)
-
-
-

-

da — SCSI Direct - Access device driver

-
-
-

-

device da

-
-
-

-

The da driver provides support for all - SCSI devices of the direct access class that are attached to the system - through a supported SCSI Host Adapter. The direct access class includes - disk, magneto-optical, and solid-state devices.

-

A SCSI Host adapter must also be separately configured into the - system before a SCSI direct access device can be configured.

-
-
-

-

Many direct access devices are equipped with read and/or write - caches. Parameters affecting the device's cache are stored in mode page 8, - the caching control page. Mode pages can be examined and modified via the - camcontrol(8) utility.

-

The read cache is used to store data from device-initiated read - ahead operations as well as frequently used data. The read cache is - transparent to the user and can be enabled without any adverse effect. Most - devices with a read cache come from the factory with it enabled. The read - cache can be disabled by setting the RCD (Read Cache Disable) bit in the - caching control mode page.

-

The write cache can greatly decrease the latency of write - operations and allows the device to reorganize writes to increase efficiency - and performance. This performance gain comes at a price. Should the device - lose power while its cache contains uncommitted write operations, these - writes will be lost. The effect of a loss of write transactions on a file - system is non-deterministic and can cause corruption. Most devices age write - transactions to limit vulnerability to a few transactions recently reported - as complete, but it is none-the-less recommended that systems with write - cache enabled devices reside on an Uninterruptible Power Supply (UPS). The - da device driver ensures that the cache and media - are synchronized upon final close of the device or an unexpected shutdown - (panic) event. This ensures that it is safe to disconnect power once the - operating system has reported that it has halted. The write cache can be - enabled by setting the WCE (Write Cache Enable) bit in the caching control - mode page.

-
-
-

-

The da device driver will take full - advantage of the SCSI feature known as tagged queueing. Tagged queueing - allows the device to process multiple transactions concurrently, often - re-ordering them to reduce the number and length of seeks. To ensure that - transactions to distant portions of the media, which may be deferred - indefinitely by servicing requests nearer the current head position, are - completed in a timely fashion, an ordered tagged transaction is sent every - 15 seconds during continuous device operation.

-
-
-

-

Direct Access devices have the capability of mapping out portions - of defective media. Media recovery parameters are located in mode page 1, - the Read-Write Error Recovery mode page. The most important media remapping - features are 'Auto Write Reallocation' and 'Auto Read Reallocation' which - can be enabled via the AWRE and ARRE bits, respectively, of the Read-Write - Error Recovery page. Many devices do not ship from the factory with these - feature enabled. Mode pages can be examined and modified via the - camcontrol(8) utility.

-
-
-

-

It is only necessary to explicitly configure one - da device; data structures are dynamically allocated - as disks are found on the SCSI bus.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.cam.da.default_timeout
-
This variable determines how long the da driver - will wait before timing out an outstanding command. The units for this - value are seconds, and the default is currently 60 seconds.
-
kern.cam.da.disable_wp_protection
-
Disable detection of write-protected disks. Default is disabled. - (detection of write-protected disks is enabled).
-
kern.cam.da.enable_biospeedup
-
Enable BIO_SPEEDUP processing. Default is - enabled.
-
kern.cam.da.enable_uma_ccbs
-
Use UMA for CCBs. Default is enabled.
-
kern.cam.da.poll_period
-
Media polling period in seconds. Default is 3 seconds.
-
kern.cam.da.retry_count
-
This variable determines how many times the da - driver will retry a READ or WRITE command. This does not affect the number - of retries used during probe time or for the da - driver dump routine. This value currently defaults to 4.
-
kern.cam.da.send_ordered
-
Send Ordered Tags. On shutdown, step through all the - da peripheral drivers, and if the device is still - open, sync the disk to physical media. Default is enabled.
-
kern.cam.sort_io_queue
-
 
-
kern.cam.da.X.sort_io_queue
-
These variables determine whether request queue should be sorted trying to - optimize head seeks. Set to 1 to enable sorting, 0 to disable, -1 to leave - it as-is. The default is sorting enabled for HDDs and disabled for - SSDs.
-
kern.cam.da.X.delete_method
-
This variable specifies method to handle BIO_DELETE requests: -
-
ATA_TRIM
-
ATA TRIM via ATA COMMAND PASS THROUGH command,
-
UNMAP
-
UNMAP command,
-
WS16
-
WRITE SAME(16) command with UNMAP flag,
-
WS10
-
WRITE SAME(10) command with UNMAP flag,
-
ZERO
-
WRITE SAME(10) command without UNMAP flag,
-
DISABLE
-
disable BIO_DELETE support.
-
-
-
kern.cam.da.X.minimum_cmd_size
-
This variable determines what the minimum READ/WRITE CDB size is for a - given da unit. Valid minimum command size values - are 6, 10, 12 and 16 bytes. The default is 6 bytes. -

The da driver issues a CAM Path - Inquiry CCB at probe time to determine whether the protocol the device - in question speaks (e.g. ATAPI) typically does not allow 6 byte - commands. If it does not, the da driver will - default to using at least 10 byte CDBs. If a 6 byte READ or WRITE fails - with an ILLEGAL REQUEST error, the da driver - will then increase the default CDB size for the device to 10 bytes and - retry the command. CDB size is always chosen as the smallest READ/WRITE - CDB that will satisfy the specified minimum command size, and the LBA - and length of the READ or WRITE in question. (e.g., a write to an LBA - larger than 2^32 will require a 16 byte CDB.)

-
-
-
-
-

-

If a device becomes invalidated (media is removed, device becomes - unresponsive) the disklabel and information held within the kernel about the - device will be invalidated. To avoid corruption of a newly inserted piece of - media or a replacement device, all accesses to the device will be discarded - until the last file descriptor referencing the old device is closed. During - this period, all new open attempts will be rejected.

-
-
-

-
-
/dev/da*
-
SCSI disk device nodes
-
-
-
-

-

None.

-
-
-

-

ada(4), cam(4), - geom(4), nda(4), - gpart(8)

-
-
-

-

The da driver was written for the CAM SCSI - subsystem by Justin T. Gibbs. Many ideas were - gleaned from the sd device driver written and ported - from Mach 2.5 by Julian Elischer.

-
-
- - - - - -
September 10, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/dc.4 3.html b/static/freebsd/man4/dc.4 3.html deleted file mode 100644 index 2afde9b4..00000000 --- a/static/freebsd/man4/dc.4 3.html +++ /dev/null @@ -1,286 +0,0 @@ - - - - - - -
DC(4)Device Drivers ManualDC(4)
-
-
-

-

dc — DEC/Intel - 21143 and clone 10/100 Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device dc
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_dc_load="YES"
-
-
-
-

-

The dc driver provides support for several - PCI Fast Ethernet adapters and embedded controllers based on the DEC/Intel - 21143 chipset and clones.

-

All of supported chipsets have the same general register layout, - DMA descriptor format and method of operation. All of the clone chips are - based on the 21143 design with various modifications. The 21143 itself has - support for 10baseT, BNC, AUI, MII and symbol media attachments, 10 and - 100Mbps speeds in full or half duplex, built in NWAY autonegotiation and - wake on LAN. The 21143 also offers several receive filter programming - options including perfect filtering, inverse perfect filtering and hash - table filtering.

-

Some clone chips duplicate the 21143 fairly closely while others - only maintain superficial similarities. Some support only MII media - attachments. Others use different receiver filter programming mechanisms. At - least one supports only chained DMA descriptors (most support both chained - descriptors and contiguously allocated fixed size rings). Some chips - (especially the PNIC) also have peculiar bugs. The - dc driver does its best to provide generalized - support for all of these chipsets in order to keep special case code to a - minimum.

-

These chips are used by many vendors which makes it difficult to - provide a complete list of all supported cards.

-

The dc driver supports the following media - types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file. -

Note: the built-in NWAY autonegotiation on the original PNIC - 82c168 chip is horribly broken and is not supported by the - dc driver at this time (see the - BUGS section for details). The original - 82c168 appears on very early revisions of the LinkSys LNE100TX and - Matrox FastNIC.

-
-
-
Set 10Mbps operation. The mediaopt option can also - be used to enable full-duplex operation. Not - specifying full-duplex implies - half-duplex mode.
-
-
Set 100Mbps (Fast Ethernet) operation. The - mediaopt option can also be used to enable - full-duplex operation. Not specifying - full-duplex implies - half-duplex mode.
-
-

The dc driver supports the following media - options:

-
-
-
Force full duplex operation. The interface will operate in half duplex - mode if this media option is not specified.
-
-

Note that the 100baseTX media type may not be available on certain - Intel 21143 adapters which support 10Mbps media attachments only. For more - information on configuring this device, see - ifconfig(8).

-
-
-

-

The dc driver provides support for the - following chipsets:

-

-
    -
  • DEC/Intel 21143
    • -
  • ADMtek AL981 Comet, AN985 Centaur, ADM9511 Centaur II and ADM9513 Centaur - II
    • -
  • ALi/ULi M5261 and M5263
    • -
  • ASIX Electronics AX88140A and AX88141
    • -
  • Conexant LANfinity RS7112 (miniPCI)
    • -
  • Davicom DM9009, DM9100, DM9102 and DM9102A
    • -
  • Lite-On 82c168 and 82c169 PNIC
    • -
  • Lite-On/Macronix 82c115 PNIC II
    • -
  • Macronix 98713, 98713A, 98715, 98715A, 98715AEC-C, 98725, 98727 and - 98732
    • -
  • Xircom X3201 (cardbus only)
    • -
-

The following NICs are known to work with the - dc driver at this time:

-

-
    -
  • 3Com OfficeConnect 10/100B (ADMtek AN985 Centaur-P)
    • -
  • Abocom FE2500
    • -
  • Accton EN1217 (98715A)
    • -
  • Accton EN2242 MiniPCI
    • -
  • Adico AE310TX (98715A)
    • -
  • Alfa Inc GFC2204 (ASIX AX88140A)
    • -
  • Built in 10Mbps only Ethernet on Compaq Presario 7900 series desktops - (21143, non-MII)
    • -
  • Built in Ethernet on LinkSys EtherFast 10/100 Instant GigaDrive (DM9102, - MII)
    • -
  • CNet Pro110B (ASIX AX88140A)
    • -
  • CNet Pro120A (98715A or 98713A) and CNet Pro120B (98715)
    • -
  • Compex RL100-TX (98713 or 98713A)
    • -
  • D-Link DFE-570TX (21143, MII, quad port)
    • -
  • Digital DE500-BA 10/100 (21143, non-MII)
    • -
  • ELECOM Laneed LD-CBL/TXA (ADMtek AN985)
    • -
  • Hawking CB102 CardBus
    • -
  • IBM EtherJet Cardbus Adapter
    • -
  • Intel PRO/100 Mobile Cardbus (versions that use the X3201 chipset)
    • -
  • Jaton XpressNet (Davicom DM9102)
    • -
  • Kingston KNE100TX (21143, MII)
    • -
  • Kingston KNE110TX (PNIC 82c169)
    • -
  • LinkSys LNE100TX (PNIC 82c168, 82c169)
    • -
  • LinkSys LNE100TX v2.0 (PNIC II 82c115)
    • -
  • LinkSys LNE100TX v4.0/4.1 (ADMtek AN985 Centaur-P)
    • -
  • Matrox FastNIC 10/100 (PNIC 82c168, 82c169)
    • -
  • Melco LGY-PCI-TXL
    • -
  • Microsoft MN-120 10/100 CardBus (ADMTek Centaur-C)
    • -
  • Microsoft MN-130 10/100 PCI (ADMTek Centaur-P)
    • -
  • NDC SOHOware SFA110A (98713A)
    • -
  • NDC SOHOware SFA110A Rev B4 (98715AEC-C)
    • -
  • NetGear FA310-TX Rev. D1, D2 or D3 (PNIC 82c169)
    • -
  • Netgear FA511
    • -
  • PlaneX FNW-3602-T (ADMtek AN985)
    • -
  • SMC EZ Card 10/100 1233A-TX (ADMtek AN985)
    • -
  • SVEC PN102-TX (98713)
    • -
  • Xircom Cardbus Realport
    • -
  • Xircom Cardbus Ethernet 10/100
    • -
  • Xircom Cardbus Ethernet II 10/100
    • -
-
-
-

-
-
dc%d: couldn't map ports/memory
-
A fatal initialization error has occurred.
-
dc%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
dc%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - but the device failed to acknowledge the transmission before a timeout - expired. This can happen if the device is unable to deliver interrupts for - some reason, of if there is a problem with the network connection (cable - or network equipment) that results in a loss of link.
-
dc%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
dc%d: TX underrun -- increasing TX threshold
-
The device generated a transmit underrun error while attempting to DMA and - transmit a packet. This happens if the host is not able to DMA the packet - data into the NIC's FIFO fast enough. The driver will dynamically increase - the transmit start threshold so that more data must be DMAed into the FIFO - before the NIC will start transmitting it onto the wire.
-
dc%d: TX underrun -- using store and forward mode
-
The device continued to generate transmit underruns even after all - possible transmit start threshold settings had been tried, so the driver - programmed the chip for store and forward mode. In this mode, the NIC will - not begin transmission until the entire packet has been transferred into - its FIFO memory.
-
dc%d: chip is in D3 power state -- setting to D0
-
This message applies only to adapters which support power management. Some - operating systems place the controller in low power mode when shutting - down, and some PCI BIOSes fail to bring the chip out of this state before - configuring it. The controller loses all of its PCI configuration in the - D3 state, so if the BIOS does not set it back to full power mode in time, - it will not be able to configure it correctly. The driver tries to detect - this condition and bring the adapter back to the D0 (full power) state, - but this may not be enough to return the driver to a fully operational - condition. If you see this message at boot time and the driver fails to - attach the device as a network interface, you will have to perform a - second warm boot to have the device properly configured. -

Note that this condition only occurs when warm booting from - another operating system. If you power down your system prior to booting - FreeBSD, the card should be configured - correctly.

-
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-

ADMtek AL981, AL983 and AL985 - data sheets, - http://www.admtek.com.tw.

-

ASIX Electronics AX88140A and - AX88141 data sheets, - http://www.asix.com.tw.

-

Davicom DM9102 data - sheet, - http://www.davicom.com.tw/userfile/24247/DM9102H-DS-F01-021508.pdf.

-

Intel 21143 Hardware Reference - Manual, - http://developer.intel.com.

-

Macronix 98713/A, 98715/A and - 98725 data sheets, - http://www.macronix.com.

-

Macronix 98713/A and 98715/A - app notes, - http://www.macronix.com.

-
-
-

-

The dc device driver first appeared in - FreeBSD 4.0.

-
-
-

-

The dc driver was written by - Bill Paul - <wpaul@ee.columbia.edu>.

-
-
-

-

The Macronix application notes claim that in order to put the - chips in normal operation, the driver must write a certain magic number into - the CSR16 register. The numbers are documented in the app notes, but the - exact meaning of the bits is not.

-

The 98713A seems to have a problem with 10Mbps full duplex mode. - The transmitter works but the receiver tends to produce many unexplained - errors leading to very poor overall performance. The 98715A does not exhibit - this problem. All other modes on the 98713A seem to work correctly.

-

The original 82c168 PNIC chip has built in NWAY support which is - used on certain early LinkSys LNE100TX and Matrox FastNIC cards, however it - is horribly broken and difficult to use reliably. Consequently, - autonegotiation is not currently supported for this chipset: the driver - defaults the NIC to 10baseT half duplex, and it is up to the operator to - manually select a different mode if necessary. (Later cards use an external - MII transceiver to implement NWAY autonegotiation and work correctly.)

-

The dc driver programs 82c168 and 82c169 - PNIC chips to use the store and forward setting for the transmit start - threshold by default. This is to work around problems with some NIC/PCI bus - combinations where the PNIC can transmit corrupt frames when operating at - 100Mbps, probably due to PCI DMA burst transfer errors.

-

The 82c168 and 82c169 PNIC chips also have a receiver bug that - sometimes manifests during periods of heavy receive and transmit activity, - where the chip will improperly DMA received frames to the host. The chips - appear to upload several kilobytes of garbage data along with the received - frame data, dirtying several RX buffers instead of just the expected one. - The dc driver detects this condition and will - salvage the frame; however, it incurs a serious performance penalty in the - process.

-

The PNIC chips also sometimes generate a transmit underrun error - when the driver attempts to download the receiver filter setup frame, which - can result in the receive filter being incorrectly programmed. The - dc driver will watch for this condition and requeue - the setup frame until it is transferred successfully.

-

The ADMtek AL981 chip (and possibly the AN985 as well) has been - observed to sometimes wedge on transmit: this appears to happen when the - driver queues a sequence of frames which cause it to wrap from the end of - the transmit descriptor ring back to the beginning. The - dc driver attempts to avoid this condition by not - queuing any frames past the end of the transmit ring during a single - invocation of the dc_start() routine. This - workaround has a negligible impact on transmit performance.

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/dcons.4 3.html b/static/freebsd/man4/dcons.4 3.html deleted file mode 100644 index cca97d5a..00000000 --- a/static/freebsd/man4/dcons.4 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
DCONS(4)Device Drivers ManualDCONS(4)
-
-
-

-

dcons — dumb - console device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
options GDB -
-device firewire -
-device dcons
-

Alternatively, to load the driver as a module at boot time, place - the following line in your kernel configuration file:

-
options GDB
-

and in loader.conf(5):

-
dcons_load="YES"
-
-
-

-

The dcons device is a simple console - device which just reads from and writes to an allocated buffer for input and - output respectively. It is of no use by itself and it is supposed that the - buffer is accessed via a bus like firewire(4) or - kvm(3) for interaction.

-

The buffer consists of 4 channels. There are 2 ports, one for the - console TTY and another is GDB port, then each port has an input channel and - an output channel.

-
-
-

-
-
/dev/dcons
-
 
-
/etc/ttys
-
 
-
-
-
-

-

If you want to run getty(8) on - dcons, insert the following line into - ttys(5) and send a HUP signal to - init(8) using kill(1).

-
-
dcons	"/usr/libexec/getty std.115200"	vt100	on  secure
-
-

Once the fwohci(4) device is initialized to - allow physical access, the buffer can be accessed from another host via a - firewire(4) bus using the dconschat(8) - application. See dconschat(8) for more details.

-

If you want to use dcons as a - gdb(1) (ports/devel/gdb) port, add - the following line into loader.conf(5):

-
-
dcons_gdb="1"
-
-
-
-

-

dcons_crom(4), ddb(4), - firewire(4), fwohci(4), - gdb(4), ttys(5), - conscontrol(8), dconschat(8), - fwcontrol(8)

-
-
-

-

Hidetoshi Shimokawa - <simokawa@FreeBSD.org>

-
-
-

-

This driver is currently under development.

-
-
- - - - - -
January 26, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/dcons_crom.4 4.html b/static/freebsd/man4/dcons_crom.4 4.html deleted file mode 100644 index 77af8f93..00000000 --- a/static/freebsd/man4/dcons_crom.4 4.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
DCONS_CROM(4)Device Drivers ManualDCONS_CROM(4)
-
-
-

-

dcons_crom — - Configuration ROM stub for - dcons(4)

-
-
-

-

device dcons_crom -
- device dcons -
- device firewire

-
-
-

-

The dcons_crom exposes the buffer address - of dcons(4) through the Configuration ROM of - firewire(4). This address is supposed to be used by - dconschat(8).

-
-
-

-

dcons(4), firewire(4), - fwohci(4), dconschat(8), - fwcontrol(8)

-
-
-

-

Hidetoshi Shimokawa - <simokawa@FreeBSD.org>

-
-
-

-

If you load dcons_crom.ko manually after - the system is booted, you may have to initiate a bus reset using - “fwcontrol -r” - to update the Configuration ROM.

-
-
- - - - - -
June 16, 2003FreeBSD 15.0
diff --git a/static/freebsd/man4/ddb.4 3.html b/static/freebsd/man4/ddb.4 3.html deleted file mode 100644 index 196eff35..00000000 --- a/static/freebsd/man4/ddb.4 3.html +++ /dev/null @@ -1,1449 +0,0 @@ - - - - - - -
DDB(4)Device Drivers ManualDDB(4)
-
-
-

-

ddb — interactive - kernel debugger

-
-
-

-

In order to enable kernel debugging facilities include:

-
options KDB -
-options DDB
-

To prevent activation of the debugger on kernel - panic(9):

-
options - KDB_UNATTENDED
-

In order to print a stack trace of the current thread on the - console for a panic:

-
options KDB_TRACE
-

To print the numerical value of symbols in addition to the - symbolic representation, define:

-
options DDB_NUMSYM
-

To enable the gdb(4) backend, so that remote - debugging with kgdb(1) - (ports/devel/gdb) is possible, include:

-
options GDB
-
-
-

-

The ddb kernel debugger is an interactive - debugger with a syntax inspired by gdb(1) - (ports/devel/gdb). If linked into the running - kernel, it can be invoked locally with the - ‘debug’ keymap(5) - action, usually mapped to Ctrl+Alt+Esc, or by setting the - debug.kdb.enter sysctl to 1. The debugger is also - invoked on kernel panic(9) if the - debug.debugger_on_panic sysctl(8) - MIB variable is set non-zero, which is the default unless the - KDB_UNATTENDED option is specified. Similarly, if - the debug.debugger_on_recursive_panic variable is set - to 1, then the debugger will be invoked on a - recursive kernel panic. This variable has a default value of - 0, and has no effect if - debug.debugger_on_panic is already set non-zero.

-

The current location is called dot. The - dot is displayed with a hexadecimal format at a - prompt. The commands examine and - write update dot to the - address of the last line examined or the last location modified, and set - next to the address of the next location to be - examined or changed. Other commands do not change dot, - and set next to be the same as - dot.

-

The general command syntax is: - command[/modifier] - [addr][,count]

-

A blank line repeats the previous command from the address - next with count 1 and no modifiers. Specifying - addr sets dot to the address. - Omitting addr uses dot. A - missing count is taken to be 1 for printing commands - or infinity for stack traces. A count of -1 is - equivalent to a missing count. Options that are - supplied but not supported by the given command are - usually ignored.

-

The ddb debugger has a pager feature (like - the more(1) command) for the output. If an output line - exceeds the number set in the lines variable, it - displays “--More--” and waits for a - response. The valid responses for it are:

-

-
-
-
one more page
-
-
one more line
-
-
abort the current command, and return to the command input mode
-
-

Finally, ddb provides a small (currently - 10 items) command history, and offers simple - emacs-style command line editing capabilities. In - addition to the emacs control keys, the usual ANSI - arrow keys may be used to browse through the history buffer, and move the - cursor within the current line.

-
-
-

-
-

-
-
-
Print a short summary of the available commands and command abbreviations. -

-
-
[/AISabcdghilmorsuxz - ...] [addr][,count]
-
 
-
[/AISabcdghilmorsuxz - ...] [addr][,count]
-
Display the addressed locations according to the formats in the modifier. - Multiple modifier formats display multiple locations. If no format is - specified, the last format specified for this command is used. -

The format characters are:

-
-
-
look at by bytes (8 bits)
-
-
look at by half words (16 bits)
-
-
look at by long words (32 bits)
-
-
look at by quad words (64 bits)
-
-
print the location being displayed
-
-
print the location with a line number if possible
-
-
display in unsigned hex
-
-
display in signed hex
-
-
display in unsigned octal
-
-
display in signed decimal
-
-
display in unsigned decimal
-
-
display in current radix, signed
-
-
display low 8 bits as a character. Non-printing characters are - displayed as an octal escape code (e.g., - ‘\000’).
-
-
display the null-terminated string at the location. Non-printing - characters are displayed as octal escapes.
-
-
display in unsigned hex with character dump at the end of each line. - The location is also displayed in hex at the beginning of each - line.
-
-
display as a disassembled instruction
-
-
display as a disassembled instruction with possible alternate formats - depending on the machine. On i386, this selects the alternate format - for the instruction decoding (16 bits in a 32-bit code segment and - vice versa).
-
-
display a symbol name for the pointer stored at the address
-
-

-
-
-
Examine forward: execute an examine command with - the last specified parameters to it except that the next address displayed - by it is used as the start address. -

-
-
-
Examine backward: execute an examine command with - the last specified parameters to it except that the last start address - subtracted by the size displayed by it is used as the start address. -

-
-
[/acdoruxz]
-
 
-
[/acdoruxz]
-
Print addrs according to the modifier character (as - described above for examine). Valid formats are: - a, x, - z, o, - d, u, - r, and c. If no modifier - is specified, the last one specified to it is used. The argument - addr can be a string, in which case it is printed as - it is. For example: -
- 
print/x "eax = " $eax "\necx = " $ecx "\n"
-
-

will print like:

-
- 
eax = xxxxxx
-ecx = yyyyyy
-
-

-
-
[/d - depth] [name]
-
Pretty-print symbol specified by name using CTF - debugging data. Works for all symbols exported by the kernel and loaded - kernel modules. -

If the d modifier has been specified, - contents of structs nested up to depth levels deep - will also be included in the output.

-

-
-
pprint - struct[/d depth] - [name][addr]
-
Print memory at addr as struct - name. Works for all structs defined by the kernel - and loaded kernel modules. -

If the d modifier has been specified, - contents of structs nested up to depth levels deep - will also be included in the output.

-

-
-
[/bhl] - addr expr1 [expr2 ...]
-
 
-
[/bhl] - addr expr1 [expr2 ...]
-
Write the expressions specified after addr on the - command line at succeeding locations starting with - addr. The write unit size can be specified in the - modifier with a letter b (byte), - h (half word) or l (long - word) respectively. If omitted, long word is assumed. -

Warning: since there is no delimiter between - expressions, strange things may happen. It is best to enclose each - expression in parentheses.

-

-
-
- $variable - [=] expr
-
Set the named variable or register with the value of - expr. Valid variable names are described below. -

-
-
[/u] - [addr][,count]
-
 
-
[/u] - [addr][,count]
-
Set a break point at addr. If - count is supplied, the - continue command will not stop at this break point - on the first count - 1 times that it is hit. If the - break point is set, a break point number is printed with - ‘#’. This number can be used in - deleting the break point or adding conditions to it. -

If the u modifier is specified, this - command sets a break point in user address space. Without the - u option, the address is considered to be in the - kernel space, and a wrong space address is rejected with an error - message. This modifier can be used only if it is supported by machine - dependent routines.

-

Warning: If a user text is shadowed by a - normal user space debugger, user space break points may not work - correctly. Setting a break point at the low-level code paths may also - cause strange behavior.

-

-
-
- [addr]
-
 
-
- [addr]
-
 
-
- #number
-
 
-
- #number
-
Delete the specified break point. The break point can be specified by a - break point number with ‘#’, or by - using the same addr specified in the original - break command, or by omitting - addr to get the default address of - dot. -

-
-
-
Halt the system. -

-
-
- [addr][,size]
-
Set a watchpoint for a region. Execution stops when an attempt to modify - the region occurs. The size argument defaults to 4. - If you specify a wrong space address, the request is rejected with an - error message. -

Warning: Attempts to watch wired kernel - memory may cause unrecoverable error in some systems such as i386. - Watchpoints on user addresses work best.

-

-
-
- [addr][,size]
-
Set a hardware watchpoint for a region if supported by the architecture. - Execution stops when an attempt to modify the region occurs. The - size argument defaults to 4. -

Warning: The hardware debug facilities do - not have a concept of separate address spaces like the watch command - does. Use hwatch for setting watchpoints on - kernel address locations only, and avoid its use on user mode address - spaces.

-

-
-
- [addr][,size]
-
Delete specified hardware watchpoint. -

-
-
- sig pid
-
Send signal sig to process - pid. The signal is acted on upon returning from the - debugger. This command can be used to kill a process causing resource - contention in the case of a hung system. See signal(3) - for a list of signals. Note that the arguments are reversed relative to - kill(2). -

-
-
[/p][,count]
-
 
-
[/p][,count]
-
Single step count times. If the - p modifier is specified, print each instruction at - each step. Otherwise, only print the last instruction. -

Warning: depending on machine type, it may - not be possible to single-step through some low-level code paths or user - space code. On machines with software-emulated single-stepping (e.g., - pmax), stepping through code executed by interrupt handlers will - probably do the wrong thing.

-

-
-
[/c]
-
 
-
[/c]
-
Continue execution until a breakpoint or watchpoint. If the - c modifier is specified, count instructions while - executing. Some machines (e.g., pmax) also count loads and stores. -

Warning: when counting, the debugger is - really silently single-stepping. This means that single-stepping on - low-level code may cause strange behavior.

-

-
-
[/p]
-
Stop at the next call or return instruction. If the - p modifier is specified, print the call nesting - depth and the cumulative instruction count at each call or return. - Otherwise, only print when the matching return is hit. -

-
-
[/p]
-
 
-
[/p]
-
Stop at the matching return instruction. If the p - modifier is specified, print the call nesting depth and the cumulative - instruction count at each call or return. Otherwise, only print when the - matching return is hit. -

-
-
[/u] - [pid | - tid][,count]
-
 
-
[/u] - [pid | - tid][,count]
-
 
-
[/u] - [pid | - tid][,count]
-
 
-
[/u] - [pid | - tid][,count]
-
Stack trace. The u option traces user space; if - omitted, trace only traces kernel space. The - optional argument count is the number of frames to - be traced. If count is omitted, all frames are - printed. -

Warning: User space stack trace is valid - only if the machine dependent code supports it.

-

-
- -
Search memory for value. The optional - count argument limits the search. -

-
-
[/s] - [seconds]
-
 
-
[/s] - [seconds]
-
Hard reset the system. If the optional argument - seconds is given, the debugger will wait for this - long, at most a week, before rebooting. When the s - modifier is given, the command will skip running any registered shutdown - handlers and attempt the most basic reset. -

-
-
- addr | tid
-
Switch the debugger to the thread with ID tid, if - the argument is a decimal number, or address addr, - otherwise. -

-
-
- [exp]
-
Program the watchdog(4) timer to fire in - 2^exp seconds. If no argument is provided, the - watchdog timer is disabled.
-
-
-
-

-
-
- addr
-
Prints the address of the thread whose kernel-mode stack contains - addr, if any. -

-
-
- active trace
-
 
-
-
Show a stack trace for every thread running on a CPU. -

-
-
- all - procs[/a]
-
 
-
[/a]
-
Display all process information. The process information may not be shown - if it is not supported in the machine, or the bottom of the stack of the - target process is not in the main memory at that time. The - a modifier will print command line arguments for - each process. -

-
-
- all - tcpcbs[/bil]
-
Show the same output as "show tcpcb" does, but for all TCP - control blocks within the system. The b modifier - will request BBLog entries to be printed. If the i - modifier is provided, the corresponding IP control block is also shown. - Using the l modifier will limit the output to TCP - control blocks, which are locked. -

-
-
- all trace
-
 
-
-
Show a stack trace for every thread in the system. -

-
-
- all ttys
-
Show all TTY's within the system. Output is similar to - pstat(8), but also includes the address of the TTY - structure. -

-
-
- all vnets
-
Show the same output as "show vnet" does, but lists all - virtualized network stacks within the system. -

-
-
- allchains
-
Show the same information like "show lockchain" does, but for - every thread in the system. -

-
-
- alllocks
-
Show all locks that are currently held. This command is only available if - witness(4) is included in the kernel. -

-
-
- allpcpu
-
The same as "show pcpu", but for every CPU present in the - system. -

-
-
- allrman
-
Show information related with resource management, including interrupt - request lines, DMA request lines, I/O ports, I/O memory addresses, and - Resource IDs. -

-
-
- apic
-
Dump data about APIC IDT vector mappings. -

-
-
- badstacks
-
Walk the witness(4) graph and print any lock-order - violations. This command is only available if witness(4) - is included in the kernel. -

-
-
- breaks
-
Show breakpoints set with the "break" command. -

-
-
- bio addr
-
Show information about the bio structure struct bio - present at addr. See the - sys/bio.h header file and - g_bio(9) for more details on the exact meaning of the - structure fields. -

-
-
- buffer addr
-
Show information about the buf structure struct buf - present at addr. See the - sys/buf.h header file for more details on the - exact meaning of the structure fields. -

-
-
- callout addr
-
Show information about the callout structure struct - callout present at addr. -

-
-
- cdev [addr]
-
Show the internal devfs state of the cdev structure located at - addr. If no argument is provided, show the list of - all created cdevs, consisting of the devfs node name and the - struct cdev address. -

-
-
- conifhk
-
Lists hooks currently waiting for completion in - (). -

-
-
- cpusets
-
Print numbered root and assigned CPU affinity sets. See - cpuset(2) for more details. -

-
-
- cyrixreg
-
Show registers specific to the Cyrix processor. -

-
-
- devmap
-
Prints the contents of the static device mapping table. Currently only - available on the ARM architecture. -

-
-
- domain addr
-
Print protocol domain structure struct domain at - address addr. See the - sys/domain.h header file for more details on the - exact meaning of the structure fields. -

-
-
- ffs [addr]
-
Show brief information about ffs mount at the address - addr, if argument is given. Otherwise, provides the - summary about each ffs mount. -

-
-
- file addr
-
Show information about the file structure struct - file present at address addr. -

-
-
- files
-
Show information about every file structure in the system. -

-
-
- freepages
-
Show the number of physical pages in each of the free lists. -

-
-
- geom [addr]
-
If the addr argument is not given, displays the - entire GEOM topology. If addr is given, displays - details about the given GEOM object (class, geom, provider or consumer). -

-
-
- idt
-
Show IDT layout. The first column specifies the IDT vector. The second one - is the name of the interrupt/trap handler. Those functions are machine - dependent. -

-
-
- igi_list addr
-
Show information about the IGMP structure struct - igmp_ifsoftc present at addr. -

-
-
- iosched addr
-
Show information about the I/O scheduler struct - cam_iosched_softc located at addr. -

-
-
- inodedeps [addr]
-
Show brief information about each inodedep structure. If - addr is given, only inodedeps belonging to the fs - located at the supplied address are shown. -

-
-
- inpcb addr
-
Show information on IP Control Block struct in_pcb - present at addr. -

-
-
- intr
-
Dump information about interrupt handlers. -

-
-
- intrcnt
-
Dump the interrupt statistics. -

-
-
- irqs
-
Show interrupt lines and their respective kernel threads. -

-
-
- ktr[/avV]
-
Print the contents of the ktr(4) trace buffer. The - v modifier will request fully verbose output, - causing the file, line number, and timestamp to be printed for each trace - entry. The V modifier will request only the - timestamps to be printed. The a modifier will - request that the output be unpaginated. -

-
-
- lapic
-
Show information from the local APIC registers for this CPU. -

-
-
- lock addr
-
Show lock structure. The output format is as follows: -
-
:
-
Class of the lock. Possible types include mutex(9), - rmlock(9), rwlock(9), - sx(9).
-
:
-
Name of the lock.
-
:
-
Flags passed to the lock initialization function. - flags values are lock class specific.
-
:
-
Current state of a lock. state values are lock class - specific.
-
:
-
Lock owner.
-
-

-
-
- lockchain addr
-
Show all threads a particular thread at address addr - is waiting on based on non-spin locks. -

-
-
- lockedbufs
-
Show the same information as "show buf", but for every locked - struct buf object. -

-
-
- lockedvnods
-
List all locked vnodes in the system. -

-
-
- locks
-
Prints all locks that are currently acquired. This command is only - available if witness(4) is included in the kernel. -

-
-
- locktree
-
-

-
-
- malloc[/i]
-
Prints malloc(9) memory allocator statistics. If the - i modifier is specified, format output as - machine-parseable comma-separated values ("CSV"). The output - columns are as follows: -

-
-
-
-
Specifies a type of memory. It is the same as a description string - used while defining the given memory type with - MALLOC_DECLARE(9).
-
-
Number of memory allocations of the given type, for which - free(9) has not been called yet.
-
-
Total memory consumed by the given allocation type.
-
-
Number of memory allocation requests for the given memory type.
-
-
-

The same information can be gathered in userspace with - “vmstat - -m”.

-

-
-
- map[/f] - addr
-
Prints the VM map at addr. If the - f modifier is specified the complete map is - printed. -

-
-
- msgbuf
-
Print the system's message buffer. It is the same output as in the - “dmesg” case. It is useful if you - got a kernel panic, attached a serial cable to the machine and want to get - the boot messages from before the system hang. -

-
-
- mount [addr]
-
Displays details about the mount point located at - addr. If no addr is specified, - displays short info about all currently mounted file systems. -

-
-
- object[/f] - addr
-
Prints the VM object at addr. If the - f option is specified the complete object is - printed. -

-
-
- panic
-
Print the panic message if set. -

-
-
- page
-
Show statistics on VM pages. -

-
-
- pageq
-
Show statistics on VM page queues. -

-
-
- pciregs
-
Print PCI bus registers. The same information can be gathered in userspace - by running “pciconf - -lv”. -

-
-
- pcpu
-
Print current processor state. The output format is as follows: -

-
-
-
-
Processor identifier.
-
-
Thread pointer, process identifier and the name of the process.
-
-
Control block pointer.
-
-
FPU thread pointer.
-
-
Idle thread pointer.
-
-
CPU identifier coming from APIC.
-
-
LDT pointer.
-
-
Names of spin locks held.
-
-
-

-
-
- pgrpdump
-
Dump process groups present within the system. -

-
-
- prison [addr]
-
Show the prison structure located at addr. If no - addr argument is specified, show information about - all prisons in the system. -

-
-
- proc [addr]
-
Show information about the process structure located at address - addr, or the current process if no argument is - specified. -

-
-
- procvm [addr]
-
Show process virtual memory layout for the process located at - addr, or the current process if no argument is - specified. -

-
-
- protosw addr
-
Print protocol switch structure struct protosw at - address addr. -

-
-
- registers[/u]
-
Display the register set. If the u modifier is - specified, the register contents of the thread's previous trapframe are - displayed instead. Usually, this corresponds to the saved state from - userspace. -

-
-
- rman addr
-
Show resource manager object struct rman at address - addr. Addresses of particular pointers can be - gathered with "show allrman" command. -

-
-
- route addr
-
Show route table result for destination addr. At - this time, INET and INET6 formatted addresses are supported. -

-
-
- routetable [af]
-
Show full route table or tables. If af is specified, - show only routes for the given numeric address family. If no argument is - specified, dump the route table for all address families. -

-
-
- rtc
-
Show real time clock value. Useful for long debugging sessions. -

-
-
- sleepchain
-
Deprecated. Now an alias for show - lockchain. -

-
-
- sleepq addr
-
 
-
- sleepqueue addr
-
Show the sleepqueue(9) structure located at - addr. -

-
-
- sockbuf addr
-
Show the socket buffer struct sockbuf located at - addr. -

-
-
- socket addr
-
Show the socket object struct socket located at - addr. -

-
-
- sysregs
-
Show system registers (e.g., cr0-4 on i386.) Not - present on some platforms. -

-
-
- tcpcb[/bi] - addr
-
Print TCP control block struct tcpcb lying at - address addr. For exact interpretation of output, - visit netinet/tcp.h header file. The - b modifier will request BBLog entries to be - printed. If the i modifier is provided, the - corresponding IP control block is also shown. -

-
-
- thread [addr | - tid]
-
If no addr or tid is - specified, show detailed information about current thread. Otherwise, - print information about the thread with ID tid or - kernel address addr. (If the argument is a decimal - number, it is assumed to be a tid.) -

-
-
- threads
-
Show all threads within the system. Output format is as follows: -

-
-
-
-
Thread identifier (TID)
-
-
Thread structure address
-
-
Backtrace.
-
-
-

-
-
- tty addr
-
Display the contents of a TTY structure in a readable form. -

-
-
- turnstile addr
-
Show turnstile struct turnstile structure at address - addr. Turnstiles are structures used within the - FreeBSD kernel to implement synchronization - primitives which, while holding a specific type of lock, cannot sleep or - context switch to another thread. Currently, those are: - mutex(9), rwlock(9), - rmlock(9). -

-
-
- uma[/i]
-
Show UMA allocator statistics. If the i modifier - is specified, format output as machine-parseable comma-separated values - ("CSV"). The output contains the following columns: -

-
-
-
-
Name of the UMA zone. The same string that was passed to - uma_zcreate(9) as a first argument.
-
-
Size of a given memory object (slab).
-
-
Number of slabs being currently used.
-
-
Number of free slabs within the UMA zone.
-
-
Number of allocations requests to the given zone.
-
-
Total memory in use (either allocated or free) by a zone, in - bytes.
-
-
Number of free slabs within the UMA zone that were freed on a - different NUMA domain than allocated. (The count in the - Free column is inclusive of - XFree.)
-
-
-

The same information might be gathered in the userspace with - the help of “vmstat - -z”.

-

-
-
- unpcb addr
-
Shows UNIX domain socket private control block struct - unpcb present at the address addr. -

-
-
- vmochk
-
Prints, whether the internal VM objects are in a map somewhere and none - have zero ref counts. -

-
-
- vmopag
-
Walk the list of VM objects in the system, printing the indices and - physical addresses of the VM pages belonging to each object. -

-
-
- vnet addr
-
Prints virtualized network stack struct vnet - structure present at the address addr. -

-
-
- vnode addr
-
Prints vnode struct vnode structure lying at - addr. For the exact interpretation of the output, - look at the sys/vnode.h header file. -

-
-
- vnodebufs addr
-
Shows clean/dirty buffer lists of the vnode located at - addr. -

-
-
- vpath addr
-
Walk the namecache to lookup the pathname of the vnode located at - addr. -

-
-
- watches
-
Displays all watchpoints. Shows watchpoints set with "watch" - command. -

-
-
- witness
-
Shows information about lock acquisition coming from the - witness(4) subsystem.
-
-
-
-

-
-
-
Initiate a kernel core dump to the device(s) configured by - dumpon(8). -

-
-
-
Switches to remote GDB mode. In remote GDB mode, another machine is - required that runs gdb(1) - (ports/devel/gdb) using the remote debug feature, - with a connection to the serial console port on the target machine. -

-
-
- -s server - [-g gateway - -c client - -i iface]
-
Configure netdump(4) with the provided parameters, and - immediately perform a netdump. -

There are some known limitations. Principally, - netdump(4) only supports IPv4 at this time. The - address arguments to the netdump command must be - dotted decimal IPv4 addresses. (Hostnames are not supported.) At - present, the command only works if the machine is in a panic state. - Finally, the ddb netdump - command does not provide any way to configure compression or - encryption.

-

-
-
- -s server - [-g gateway - -c client - -i iface]
-
Initiate a netgdb(4) session with the provided - parameters. -

netgdb has identical limitations to - netdump.

-

-
-
-
 
-
-
 
-
-
 
-
-
ddb supports a basic output capture facility, - which can be used to retrieve the results of debugging commands from - userspace using sysctl(3). capture - on enables output capture; capture off - disables capture. capture reset will clear the - capture buffer and disable capture. capture status - will report current buffer use, buffer size, and disposition of output - capture. -

Userspace processes may inspect and manage - ddb capture state using - sysctl(8):

-

debug.ddb.capture.bufsize may be used to - query or set the current capture buffer size.

-

debug.ddb.capture.maxbufsize may be used - to query the compile-time limit on the capture buffer size.

-

debug.ddb.capture.bytes may be used to - query the number of bytes of output currently in the capture buffer.

-

debug.ddb.capture.data returns the - contents of the buffer as a string to an appropriately privileged - process.

-

This facility is particularly useful in concert with the - scripting and textdump(4) facilities, allowing - scripted debugging output to be captured and committed to disk as part - of a textdump for later analysis. The contents of the capture buffer may - also be inspected in a kernel core dump using kgdb(1) - (ports/devel/gdb).

-

-
-
-
 
-
-
 
-
-
 
-
-
Run, define, list, and delete scripts. See the - SCRIPTING section for more information - on the scripting facility. -

-
-
-
 
-
-
 
-
-
 
-
-
Use the textdump dump command to immediately - perform a textdump. More information may be found in - textdump(4). The textdump set - command may be used to force the next kernel core dump to be a textdump - rather than a traditional memory dump or minidump. - textdump status reports whether a textdump has - been scheduled. textdump unset cancels a request - to perform a textdump as the next kernel core dump.
-
-
-
-
-

-

The debugger accesses registers and variables as - $name. Register names are as - in the “show - registers” command. Some variables are - suffixed with numbers, and may have some modifier following a colon - immediately after the variable name. For example, register variables can - have a u modifier to indicate user register (e.g., - “$eax:u”).

-

Built-in variables currently supported are:

-

-
-
radix
-
Input and output radix.
-
maxoff
-
Addresses are printed as - “symbol+offset” - unless offset is greater than - maxoff.
-
maxwidth
-
The width of the displayed line.
-
lines
-
The number of lines. It is used by the built-in pager. Setting it to 0 - disables paging.
-
tabstops
-
Tab stop width.
-
workxx
-
Work variable; xx can take values from 0 to 31.
-
-
-
-

-

Most expression operators in C are supported except - ‘~’, - ‘^’, and unary - ‘&’. Special rules in - ddb are:

-
-
Identifiers
-
The name of a symbol is translated to the value of the symbol, which is - the address of the corresponding object. - ‘.’ and - ‘:’ can be used in the identifier. - If supported by an object format dependent routine, - [filename:]func:lineno, - [filename:]variable, and - [filename:]lineno can be - accepted as a symbol.
-
Numbers
-
Radix is determined by the first two letters: - ‘0x’: hex, - ‘0o’: octal, - ‘0t’: decimal; otherwise, follow - current radix.
-
-
dot
-
-
next
-
-
address of the start of the last line examined. Unlike - dot or next, this is only - changed by examine or - write command.
-
-
last address explicitly specified.
-
variable
-
Translated to the value of the specified variable. It may be followed by a - ‘:’ and modifiers as described - above.
-
a#b
-
A binary operator which rounds up the left hand side to the next multiple - of right hand side.
-
expr
-
Indirection. It may be followed by a - ‘:’ and modifiers as described - above.
-
-
-
-

-

ddb supports a basic scripting facility to - allow automating tasks or responses to specific events. Each script consists - of a list of DDB commands to be executed sequentially, and is assigned a - unique name. Certain script names have special meaning, and will be - automatically run on various ddb events if scripts - by those names have been defined.

-

The script command may be used to define a - script by name. Scripts consist of a series of ddb - commands separated with the ‘;’ - character. For example:

-
-
script kdb.enter.panic=bt; show pcpu
-script lockinfo=show alllocks; show lockedvnods
-
-

The scripts command lists currently - defined scripts.

-

The run command execute a script by name. - For example:

-
-
run lockinfo
-
-

The unscript command may be used to delete - a script by name. For example:

-
-
unscript kdb.enter.panic
-
-

These functions may also be performed from userspace using the - ddb(8) command.

-

Certain scripts are run automatically, if defined, for specific - ddb events. The follow scripts are run when various - events occur:

-
-
kdb.enter.acpi
-
The kernel debugger was entered as a result of an - acpi(4) event.
-
kdb.enter.bootflags
-
The kernel debugger was entered at boot as a result of the debugger boot - flag being set.
-
kdb.enter.break
-
The kernel debugger was entered as a result of a serial or console - break.
-
kdb.enter.cam
-
The kernel debugger was entered as a result of a CAM(4) - event.
-
kdb.enter.mac
-
The kernel debugger was entered as a result of an assertion failure in the - mac_test(4) module of the TrustedBSD MAC Framework.
-
kdb.enter.netgraph
-
The kernel debugger was entered as a result of a - netgraph(4) event.
-
kdb.enter.panic
-
panic(9) was called.
-
kdb.enter.powerpc
-
The kernel debugger was entered as a result of an unimplemented interrupt - type on the powerpc platform.
-
kdb.enter.sysctl
-
The kernel debugger was entered as a result of the - debug.kdb.enter sysctl being set.
-
kdb.enter.unionfs
-
The kernel debugger was entered as a result of an assertion failure in the - union file system.
-
kdb.enter.unknown
-
The kernel debugger was entered, but no reason has been set.
-
kdb.enter.vfslock
-
The kernel debugger was entered as a result of a VFS lock violation.
-
kdb.enter.watchdog
-
The kernel debugger was entered as a result of a watchdog firing.
-
kdb.enter.witness
-
The kernel debugger was entered as a result of a - witness(4) violation.
-
-

In the event that none of these scripts is found, - ddb will attempt to execute a default script:

-
-
kdb.enter.default
-
The kernel debugger was entered, but a script exactly matching the reason - for entering was not defined. This can be used as a catch-all to handle - cases not specifically of interest; for example, - kdb.enter.witness might be defined to have special - handling, and kdb.enter.default might be defined to - simply panic and reboot.
-
-
-
-

-

On machines with an ISA expansion bus, a simple NMI generation - card can be constructed by connecting a push button between the A01 and B01 - (CHCHK# and GND) card fingers. Momentarily shorting these two fingers - together may cause the bridge chipset to generate an NMI, which causes the - kernel to pass control to ddb. Some bridge chipsets - do not generate a NMI on CHCHK#, so your mileage may vary. The NMI allows - one to break into the debugger on a wedged machine to diagnose problems. - Other bus' bridge chipsets may be able to generate NMI using bus specific - methods. There are many PCI and PCIe add-in cards which can generate NMI for - debugging. Modern server systems typically use IPMI to generate signals to - enter the debugger. The devel/ipmitool port can be - used to send the chassis power diag command which - delivers an NMI to the processor. Embedded systems often use JTAG for - debugging, but rarely use it in combination with - ddb.

-

Serial consoles can break to the debugger by sending a BREAK - condition on the serial line. This requires a kernel built with - options BREAK_TO_DEBUGGER is specified in the - kernel. Most terminal emulation programs can send a break sequence with a - special key sequence or menu selection. Sending the break can be difficult - or even happen spuriously in some setups. An alternative method is to build - a kernel with options ALT_BREAK_TO_DEBUGGER then the - sequence of CR TILDE CTRL-B enters the debugger; CR TILDE CTRL-P causes a - panic; and CR TILDE CTRL-R causes an immediate reboot. In all these - sequences, CR represents Carriage Return and is usually sent by pressing the - Enter or Return key. TILDE is the ASCII tilde character (~). CTRL-x is - Control x, sent by pressing the Control key, then x, then releasing - both.

-

The break-to-debugger behavior can be enabled by setting - sysctl(8) - debug.kdb.break_to_debugger to 1. The - alt-break-to-debugger behavior can be enabled by setting - sysctl(8) - debug.kdb.alt_break_to_debugger to 1. The debugger can - be entered by setting sysctl(8) - debug.kdb.enter to 1.

-

Output can be interrupted, paused, and resumed with the control - characters CTRL-C, CTRL-S, and CTRL-Q. Because these control characters are - received as in-band data from the console, there is an input buffer, and - once that buffer fills ddb must either stop - responding to control characters or drop additional input while continuing - to search for control characters. This behavior is controlled by the tunable - sysctl(8) - debug.ddb.prioritize_control_input, which defaults to - 1. The input buffer size is 512 bytes.

-
-
-

-

Header files mentioned in this manual page can be found below - /usr/include directory.

-

-
    -
  • sys/buf.h
    • -
  • sys/domain.h
    • -
  • netinet/in_pcb.h
    • -
  • sys/socket.h
    • -
  • sys/vnode.h
    • -
-
-
-

-

gdb(1) - (ports/devel/gdb), kgdb(1) - (ports/devel/gdb), acpi(4), - CAM(4), gdb(4), - mac_ddb(4), mac_test(4), - netgraph(4), textdump(4), - witness(4), ddb(8), - sysctl(8), panic(9)

-
-
-

-

The ddb debugger was developed for Mach, - and ported to 386BSD-0.1. This manual page - translated from man(7) macros by Garrett - Wollman.

-

Robert N. M. Watson added support for - ddb output capture, textdump(4) - and scripting in FreeBSD 7.1.

-
-
- - - - - -
October 31, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/devctl.4 3.html b/static/freebsd/man4/devctl.4 3.html deleted file mode 100644 index ef6b602a..00000000 --- a/static/freebsd/man4/devctl.4 3.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - -
DEVCTL(4)Device Drivers ManualDEVCTL(4)
-
-
-

-

devctl — device - event reporting and device control interface

-
-
-

-

The

-
- - - - - -
devctldriver is automatically included in the kernel.
-
-
-

-

The devctl device is used to report device - events from the kernel. Future versions will allow for some device control - as well.

-
-
-

-

This design allows only one reader for - /dev/devctl. This is not desirable in the long run, - but will get a lot of hair out of this implementation. Maybe we should make - this device a clonable device.

-

Also note: we specifically do not attach a device to the - device_t tree to avoid potential chicken and egg - problems. One could argue that all of this belongs to the root node. One - could also further argue that the sysctl(3) interface that - we have now might more properly be an ioctl(2) - interface.

-

SIGIO support is included in the driver. - However, the author is not sure that the SIGIO - support is done correctly. It was copied from a driver that had - SIGIO support that likely has not been tested since - FreeBSD 3.4 or FreeBSD - 2.2.8!

-

The read channel for this device is used to report changes to - userland in realtime. We return one record at a time. If you try to read - this device a character at a time, you will lose the rest of the data. - Listening programs are expected to cope.

-

The sysctl hw.bus.devctl_queue can be used - to control queue length. It is set to 0 to disable - devctl when no devd(8) is - running.

-
-
-

-

The devctl device uses an ASCII protocol. - The driver returns one record at a time to its readers. Each record is - terminated with a newline. The first character of the record is the event - type.

-

- - - - - - - - - - - - - - - - - - - - - -
Description
!A notify event, such as a link state change.
+Device node in tree attached.
-Device node in tree detached.
?Unknown device detected.
-
-

-

Except for the first character in the record, attach and detach - messages have the same format.

-

-
Tdev - at parent - on location
-

- - - - - - - - - - - - - - - - - - - - - -
Description
T+ or -
devThe device name that was attached/detached.
parentThe device name of the parent bus that attached the device.
locationBus specific location information.
-

The nomatch messages can be used to load devices driver. If you - load a device driver, then one of two things can happen. If the device - driver attaches to something, you will get a device attached message. If it - does not, then nothing will happen.

-

The attach and detach messages arrive after the event. This means - one cannot use the attach message to load an alternate driver. The attach - message driver has already claimed this device. One cannot use the detach - messages to flush data to the device. The device is already gone.

-

All values passed back are of the form ‘key=value’ - or ‘key="value"’. When the latter, the string - “value” must have any internal backslashes doubled. It must - also have any internal double quote characters ‘’ preceded by - a backslash. All other characters should be passed through.

-
-
-
-

-

devd(8)

-
-
- - - - - -
September 21, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/devfs.4 3.html b/static/freebsd/man4/devfs.4 3.html deleted file mode 100644 index fe9fad98..00000000 --- a/static/freebsd/man4/devfs.4 3.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - -
DEVFS(4)Device Drivers ManualDEVFS(4)
-
-
-

-

devfs — device - file system

-
-
-

-
-
devfs	/dev	devfs rw 0 0
-
-
-
-

-

The device file system, or devfs, provides - access to kernel's device namespace in the global file system namespace. The - conventional mount point is /dev.

-

The file system includes several directories, links, symbolic - links and devices, some of which can also be written. In a chroot'ed - environment, devfs(8) can be used to create a new - /dev mount point.

-

The mknod(8) tool can be used to recover deleted - device entries under devfs.

-

The fdescfs(4) filesystem is an alternate means - for populating /dev/fd. The character devices that - both devfs and fdescfs(4) present - in /dev/fd correspond to the open file descriptors - of the process accessing the directory. devfs only - creates files for the standard file descriptors 0, - 1 and 2. - fdescfs(4) creates files for all open descriptors.

-

The options are as follows:

-
-
- options
-
Use the specified mount options, as described in - mount(8). The following devfs file system-specific - options are available: -
-
=ruleset
-
Set ruleset number ruleset as the current - ruleset for the mount-point and apply all its rules. If the ruleset - number ruleset does not exist, an empty ruleset - with the number ruleset is created. See - devfs(8) for more information on working with devfs - rulesets.
-
-
-
-
-
-

-
-
/dev
-
The normal devfs mount point.
-
-
-
-

-

To mount a devfs volume located on - /mychroot/dev:

-

-
mount -t devfs devfs - /mychroot/dev
-
-
-

-

fdescfs(4), devfs(8), - mount(8), make_dev(9)

-
-
-

-

The devfs file system first appeared in - FreeBSD 2.0. It became the preferred method for - accessing devices in FreeBSD 5.0 and the only method - in FreeBSD 6.0. The devfs - manual page first appeared in FreeBSD 2.2.

-
-
-

-

The devfs manual page was written by - Mike Pritchard - <mpp@FreeBSD.org>.

-
-
- - - - - -
June 30, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/disc.4 3.html b/static/freebsd/man4/disc.4 3.html deleted file mode 100644 index 0493e738..00000000 --- a/static/freebsd/man4/disc.4 3.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
DISC(4)Device Drivers ManualDISC(4)
-
-
-

-

disc — software - discard network interface

-
-
-

-

device disc

-
-
-

-

The disc interface is a software discard - mechanism which may be used for performance analysis and/or software - testing. As with other network interfaces, the discard interface must have - network addresses assigned for each address family with which it is to be - used. These addresses may be set or changed with the - SIOCSIFADDR ioctl(2).

-

Each disc interface is created at runtime - using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5).

-
-
-

-

inet(4), intro(4)

-
-
-

-

The disc device appears to have been - derived from the lo(4) device around the time of - 4.4BSD. This manpage was adapted from - lo(4) and first appeared in FreeBSD - 5.0.

-
-
- - - - - -
May 25, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/disk.4 3.html b/static/freebsd/man4/disk.4 3.html deleted file mode 100644 index 3aa31a90..00000000 --- a/static/freebsd/man4/disk.4 3.html +++ /dev/null @@ -1,177 +0,0 @@ - - - - - - -
disk(4)Device Drivers Manualdisk(4)
-
-
-

-

disk — common disk - interfaces

-
-
-

-

device cd

-
-
-

-

Common block device IOCTLs

-

All the block devices in the system should support these disk - ioctl(2) commands defined here. Much of this information - is also available via the geom(2) attributes.

-
-
-

-

The following ioctl(2) calls apply to disk - drives, and are defined in the - <sys/disk.h> header - file.

-
-
-
(u_int) Get the sector or block size of the device - in bytes. The sector size is the smallest unit of data which can be - transferred from this device. This is usually a power of 2 but it might - not be (e.g. CDROM audio). Operations to block devices such as - lseek(2), read(2), and - write(2) may only be performed at file offsets that are - integral multiple of this size.
-
-
(off_t) Get the size of the entire device in - bytes. This should be a multiple of the sector size.
-
-
(u_int) Return the firmware's notion of number of - sectors per track. This value is mostly used for compatibility with - various ill designed disk label formats. Use this value only when - absolutely required. Its interpretation and use is largely obsolete.
-
-
(u_int) Return the firmware's notion of number of - heads per cylinder. This value is mostly used for compatibility with - various ill designed disk label formats. Use this value only when - absolutely required. Its interpretation and use is largely obsolete.
-
-
Flush write cache of the device.
-
-
(off_t[2]) Mark data on the device as unused. The - first element is the offset to start deleting. The second element is the - length to delete. Providers may use this information to free storage or - instruct storage devices the contents can be discarded.
-
-
(char[DISK_IDENT_SIZE]) Get the ident for this - provider. Ident is a unique and fixed identifier for this provider. - Ident's properties are as follow: -
    -
  • preserved between reboots,
    • -
  • preserved across a provider being detached/attached,
    • -
  • provider's name can change - ident can't,
    • -
  • ident value should not be based on on-disk metadata; in other words, - copying whole data from one disk to another should not yield the same - ident for the other disk,
    • -
  • there can be more than one provider with the same ident, but only if - they point at exactly the same physical storage, this is the case for - multipathing for example,
    • -
  • GEOM classes that consume a single provider and provide single - provider, like geli(8), the identifier should be - formed by attaching that provider's class name to the ident of the - underlying provider,
    • -
  • ident is an NUL-terminated ASCII string (is printable),
    • -
  • ident is optional and applications can't relay on its presence.
    • -
-
-
-
(char[MAXPATHLEN]) Store the provider name for the - device in a buffer. The buffer must be at least MAXPATHLEN bytes - long.
-
-
(off_t) Get the size of the device's optimal - access block in bytes. This should be a multiple of the sector size.
-
-
(off_t) Get the offset of the first device's - optimal access block in bytes. This should be a multiple of the sector - size.
-
-
(char[MAXPATHLEN]) Get a string defining the - physical path for a given provider. This has similar rules to ident, but - is intended to uniquely identify the physical location of the device, not - the current occupant of that location. The buffer must be at least - MAXPATHLEN bytes long.
-
-
(struct diocgattr_arg) -
- 
struct diocgattr_arg {
-	char name[64];
-	int len;
-	union {
-		char str[DISK_IDENT_SIZE];
-		off_t off;
-		int i;
-		uint16_t u16;
-	} value;
-};
-
- Get a geom attribute from the provider. Format of the returned data is - specific to the attribute.
-
-
(struct disk_zone_arg) Send disk zone - commands.
-
-
(struct diocskerneldump_arg) Enable/Disable the - device for kernel core dumps.
-
-
(struct diocskerneldump_arg) Get current kernel - netdump configuration details for a given index. -
- 
/*
- * Sentinel values for kda_index.
- *
- * If kda_index is KDA_REMOVE_ALL, all dump configurations are cleared.
- *
- * If kda_index is KDA_REMOVE_DEV, all dump configurations for the specified
- * device are cleared.
- *
- * If kda_index is KDA_REMOVE, only the specified dump configuration for the
- * given device is removed from the list of fallback dump configurations.
- *
- * If kda_index is KDA_APPEND, the dump configuration is added after all
- * existing dump configurations.
- *
- * Otherwise, the new configuration is inserted into the fallback dump list at
- * index 'kda_index'.
- */
-#define	KDA_REMOVE		UINT8_MAX
-#define	KDA_REMOVE_ALL		(UINT8_MAX - 1)
-#define	KDA_REMOVE_DEV		(UINT8_MAX - 2)
-#define	KDA_APPEND		(UINT8_MAX - 3)
-struct diocskerneldump_arg {
-	uint8_t		 kda_index;
-	uint8_t		 kda_compression;
-	uint8_t		 kda_encryption;
-	uint8_t		 kda_key[KERNELDUMP_KEY_MAX_SIZE];
-	uint32_t	 kda_encryptedkeysize;
-	uint8_t		*kda_encryptedkey;
-	char		 kda_iface[IFNAMSIZ];
-	union kd_ip	 kda_server;
-	union kd_ip	 kda_client;
-	union kd_ip	 kda_gateway;
-	uint8_t		 kda_af;
-};
-
-
-
-
-
-

-

The manual page was written by M Warner - Losh - <imp@FreeBSD.org> from - text largely derived from - <sys/disk.h>.

-
-
- - - - - -
November 20, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/divert.4 3.html b/static/freebsd/man4/divert.4 3.html deleted file mode 100644 index 1e20fc6d..00000000 --- a/static/freebsd/man4/divert.4 3.html +++ /dev/null @@ -1,178 +0,0 @@ - - - - - - -
DIVERT(4)Device Drivers ManualDIVERT(4)
-
-
-

-

divert — kernel - packet diversion mechanism

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h>

-

int -
- socket(PF_DIVERT, - SOCK_RAW, - 0);

-

To enable support for divert sockets, place the following lines in - the kernel configuration file:

-
options IPDIVERT
-

Alternatively, to load the driver as a module at boot time, add - the following lines into the loader.conf(5) file:

-
-
ipdivert_load="YES"
-
-
-
-

-

Divert sockets allow to intercept and re-inject packets flowing - through the ipfw(4) and pf(4) firewalls. - A divert socket can be bound to a specific divert - port via the bind(2) system call. The sockaddr argument - shall be sockaddr_in with sin_port set to the desired value. Note that the - divert port has nothing to do with TCP/UDP ports. It - is just a cookie whose value depends on the firewall in use. For - ipfw(4) this is the number of the rule which diverted the - packet; for pf(4) this is a value which indicates the - original direction through the firewall of the diverted packet. A divert - socket bound to a divert port will receive all packets diverted to that port - by the firewall. Packets may also be written to a divert port, in which case - they re-enter firewall processing at the next rule.

-

By reading from and writing to a divert socket, matching packets - can be passed through an arbitrary ``filter'' as they travel through the - host machine, special routing tricks can be done, etc.

-
-
-

-

Packets are diverted either as they are ``incoming'' or - ``outgoing.'' Incoming packets are diverted after reception on an IP - interface, whereas outgoing packets are diverted before next hop - forwarding.

-

Diverted packets may be read unaltered via - read(2), recv(2), or - recvfrom(2). In the latter case, the address returned will - have its port set to some tag supplied by the packet diverter, (usually the - cookie described above) and the IP address set to the (first) address of the - interface on which the packet was received (if the packet was incoming) or - INADDR_ANY (if the packet was outgoing). The - interface name (if defined for the packet) will be placed in the 8 bytes - following the address, if it fits.

-
-
-

-

Writing to a divert socket is similar to writing to a raw IP - socket; the packet is injected ``as is'' into the normal kernel IP packet - processing using sendto(2) and minimal error checking is - done. Packets are distinguished as either incoming or outgoing. If - sendto(2) is used with a destination IP address of - INADDR_ANY, then the packet is treated as if it were - outgoing, i.e., destined for a non-local address. Otherwise, the packet is - assumed to be incoming and full packet routing is done.

-

In the latter case, the IP address specified must match the - address of some local interface, or an interface name must be found after - the IP address. If an interface name is found, that interface will be used - and the value of the IP address will be ignored (other than the fact that it - is not INADDR_ANY). This is to indicate on which - interface the packet “arrived”.

-

Normally, packets read as incoming should be written as incoming; - similarly for outgoing packets. When reading and then writing back packets, - passing the same socket address supplied by recvfrom(2) - unmodified to sendto(2) simplifies things (see below).

-

The port part of the socket address passed to the - sendto(2) contains a tag that should be meaningful to the - diversion module. In the case of ipfw(8) the tag is - interpreted as the rule number - rule - processing should restart.

-
-
-

-

Packets written into a divert socket (using - sendto(2)) re-enter the packet filter at the rule number - following the tag given in the port part of the socket address, which is - usually already set at the rule number that caused the diversion (not the - next rule if there are several at the same number). If the 'tag' is altered - to indicate an alternative re-entry point, care should be taken to avoid - loops, where the same packet is diverted more than once at the same - rule.

-
-
-

-

If a packet is diverted but no socket is bound to the port, or if - IPDIVERT is not enabled or loaded in the kernel, the - packet is dropped.

-

Incoming packet fragments which get diverted are fully reassembled - before delivery; the diversion of any one fragment causes the entire packet - to get diverted. If different fragments divert to different ports, then - which port ultimately gets chosen is unpredictable.

-

Note that packets arriving on the divert socket by the - ipfw(8) tee action are delivered - as-is and packet fragments do not get reassembled in this case.

-

Packets are received and sent unchanged, except that packets read - as outgoing have invalid IP header checksums, and packets written as - outgoing have their IP header checksums overwritten with the correct value. - Packets written as incoming and having incorrect checksums will be dropped. - Otherwise, all header fields are unchanged (and therefore in network - order).

-

Creating a divert socket requires - super-user access.

-
-
-

-

Writing to a divert socket can return these errors, along with the - usual errors possible when writing raw packets:

-
-
[]
-
The packet had an invalid header, or the IP options in the packet and the - socket options set were incompatible.
-
[]
-
The destination address contained an IP address not equal to - INADDR_ANY that was not associated with any - interface.
-
-
-
-

-

bind(2), recvfrom(2), - sendto(2), socket(2), - ipfw(4), pf(4), - ipfw(8)

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>, - Whistle Communications Corp.

-
-
-

-

This is an attempt to provide a clean way for user mode processes - to implement various IP tricks like address translation, but it could be - cleaner.

-

It is questionable whether incoming fragments should be - reassembled before being diverted. For example, if only some fragments of a - packet destined for another machine do not get routed through the local - machine, the packet is lost. This should probably be a settable socket - option in any case.

-
-
- - - - - -
January 23, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/dpms.4 3.html b/static/freebsd/man4/dpms.4 3.html deleted file mode 100644 index b8830386..00000000 --- a/static/freebsd/man4/dpms.4 3.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - -
DPMS(4)Device Drivers ManualDPMS(4)
-
-
-

-

dpms — VESA BIOS - DPMS driver

-
-
-

-

device dpms

-
-
-

-

The dpms driver uses the VESA BIOS to - manage an external display during suspend and resume. When the machine - suspends, the dpms driver turns the external display - off. When the machine resumes, it restores the display to its state when the - driver was first loaded.

-
-
-

-

acpi_video(4)

-
-
-

-

The VESA BIOS DPMS calls do not provide any way to identify a - particular display or adapter to manipulate. As a result, this driver may - have unexpected results on systems with multiple displays and/or - adapters.

-
-
- - - - - -
August 23, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/ds1307.4 3.html b/static/freebsd/man4/ds1307.4 3.html deleted file mode 100644 index 3b6dea8e..00000000 --- a/static/freebsd/man4/ds1307.4 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
DS1307(4)Device Drivers ManualDS1307(4)
-
-
-

-

ds1307 — 64 x 8, - serial, i2c real-time clock (RTC)

-
-
-

-

device iic -
- device iicbus -
- device ds1307

-
-
-

-

The ds1307 serial real-time clock (RTC) is - a low-power, full binary-coded decimal (BCD) clock/calendar plus 56 bytes of - NV SRAM.

-

The ds1307 has a built-in power-sense - circuit that detects power failures and automatically switches to the backup - supply. Timekeeping operation continues while the part operates from the - backup supply.

-

Access to ds1307 settings is made with the - sysctl(8) interface:

-
-
dev.ds1307.0.%desc: Maxim DS1307 RTC
-dev.ds1307.0.%driver: ds1307
-dev.ds1307.0.%location: addr=0xd0
-dev.ds1307.0.%pnpinfo: name=rtc compat=maxim,ds1307
-dev.ds1307.0.%parent: iicbus1
-dev.ds1307.0.sqwe: 1
-dev.ds1307.0.sqw_freq: 32768
-dev.ds1307.0.sqw_out: 0
-
-
-
dev.ds1307.%d.sqwe
-
If set to 1, the SQW pin drives a square-wave of - dev.ds1307.%d.sqw_freq frequency. If set to 0, the - output level of SQW pin is controlled by - dev.ds1307.%d.sqw_out.
-
dev.ds1307.%d.sqw_freq
-
Select the frequency of the SQW pin when the square-wave output is enabled - on dev.ds1307.%d.sqwe. It can be set to 1, 4096, - 8192 and 32768.
-
dev.ds1307.%d.sqw_out
-
Set the output level of the SQW pin when - dev.ds1307.%d.sqwe is set to 0.
-
-

Please check the ds1307 datasheet for more - details.

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - ds1307:

-
-
hint.ds1307.%d.at
-
The iicbus(4) that the ds1307 is - connected to.
-
hint.ds1307.%d.addr
-
The i2c address of ds1307.
-
-

On a FDT(4) based system the following - properties must be set:

-
-
compatible
-
Must always be set to "dallas,ds1307" or - "maxim,ds1307".
-
reg
-
The i2c address of ds1307. The default address for - ds1307 is 0xd0.
-
-
-
-

-

fdt(4), iic(4), - iicbus(4), sysctl(8)

-
-
-

-

The ds1307 driver first appeared in - FreeBSD 11.0.

-
-
-

-

The ds1307 driver and this manual page - were written by Luiz Otavio O Souza - <loos@FreeBSD.org>.

-
-
- - - - - -
December 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ds3231.4 3.html b/static/freebsd/man4/ds3231.4 3.html deleted file mode 100644 index 6db7c133..00000000 --- a/static/freebsd/man4/ds3231.4 3.html +++ /dev/null @@ -1,116 +0,0 @@ - - - - - - -
DS3231(4)Device Drivers ManualDS3231(4)
-
-
-

-

ds3231 — Extremely - Accurate i2c-integrated real-time clock (RTC)/TCXO/Crystal

-
-
-

-

device iic -
- device iicbus -
- device ds3231

-
-
-

-

The ds3231 is a low-cost, extremely - accurate I2C realtime clock (RTC) with an integrated temperature-compensated - crystal oscillator (TCXO) and crystal.

-

The device incorporates a battery input and maintains accurate - timekeeping when main power to the device is interrupted.

-

Access to ds3231 data is made with the - sysctl(8) interface:

-
-
dev.ds3231.0.%desc: Maxim DS3231 RTC
-dev.ds3231.0.%driver: ds3231
-dev.ds3231.0.%location: addr=0xd0
-dev.ds3231.0.%pnpinfo: name=rtc compat=maxim,ds3231
-dev.ds3231.0.%parent: iicbus1
-dev.ds3231.0.temperature: 23.2C
-dev.ds3231.0.temp_conv: 0
-dev.ds3231.0.bbsqw: 0
-dev.ds3231.0.sqw_freq: 8192
-dev.ds3231.0.sqw_mode: interrupt
-dev.ds3231.0.32khz_enable: 1
-
-
-
dev.ds3231.%d.temperature
-
The read-only value of the current temperature read by the RTC.
-
dev.ds3231.%d.temp_conv
-
Start a new temperature conversion. When read as 1, a temperature - conversion is in progress. When read as 0 and then set to 1, a temperature - conversion is started. The temperature conversion runs automatically on - power up and once every 64 seconds afterward.
-
dev.ds3231.%d.bbsqw
-
If set to 1 and dev.ds3231.%d.sqw_mode is set to - square-wave, battery-backed square-wave output is enabled. If set to 0, - the SQW pin will be set to high impendance when the RTC is being powered - by battery.
-
dev.ds3231.%d.sqw_freq
-
Select the frequency of the SQW pin when the square-wave output is enabled - on dev.ds3231.%d.sqw_mode. It can be set to 1, 1024, - 4096, and 8192.
-
dev.ds3231.%d.sqw_mode
-
Set the operation mode for the SQW pin. It can be set to 'interrupt' - (default) or 'square-wave'. In interrupt mode, the SQW pin is used to - generate interrupts for the RTC alarms. In square-wave mode, the SQW pin - drives a square-wave of dev.ds3231.%d.sqw_freq - frequency.
-
dev.ds3231.%d.32khz_enable
-
Enable the 32kHz output.
-
-

Please check the ds3231 datasheet for more - details.

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - ds3231:

-
-
hint.ds3231.%d.at
-
The iicbus(4) that the ds3231 is - connected to.
-
hint.ds3231.%d.addr
-
The 8-bit i2c address of ds3231. The default 8-bit - address for ds3231 is 0xd0.
-
-

On a FDT(4) based system the following - properties must be set:

-
-
compatible
-
Must always be set to "maxim,ds3231".
-
reg
-
The 7-bit i2c address of ds3231. The default 7-bit - address for ds3231 is 0x68.
-
-
-
-

-

fdt(4), iic(4), - iicbus(4), sysctl(8)

-
-
-

-

The ds3231 driver first appeared in - FreeBSD 11.0.

-
-
-

-

The ds3231 driver and this manual page - were written by Luiz Otavio O Souza - <loos@FreeBSD.org>.

-
-
- - - - - -
December 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_audit.4 3.html b/static/freebsd/man4/dtrace_audit.4 3.html deleted file mode 100644 index 60d8245f..00000000 --- a/static/freebsd/man4/dtrace_audit.4 3.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - -
DTRACE_AUDIT(4)Device Drivers ManualDTRACE_AUDIT(4)
-
-
-

-

dtrace_audit — A - DTrace provider for tracing audit(4) events

-
-
-

-

audit:event:aue_*:commit(char - *eventname, struct - audit_record *ar);

-

audit:event:aue_*:bsm(char - *eventname, struct - audit_record *ar, const - void *, - size_t);

-

To compile this module into the kernel, place the following in - your kernel configuration file:

-
-
options DTAUDIT
-
-

Alternatively, to load the module at boot time, place the - following line in loader.conf(5):

-
-
dtaudit_load="YES"
-
-
-
-

-

The DTrace dtaudit provider allows users - to trace events in the kernel security auditing subsystem, - audit(4). audit(4) provides detailed - logging of a configurable set of security-relevant system calls, including - key arguments (such as file paths) and return values that are copied - race-free as the system call proceeds. The dtaudit - provider allows DTrace scripts to selectively enable in-kernel audit-record - capture for system calls, and then access those records in either the - in-kernel format or BSM format (audit.log(5)) when the - system call completes. While the in-kernel audit record data structure is - subject to change as the kernel changes over time, it is a much more - friendly interface for use in D scripts than either those available via the - DTrace system-call provider or the BSM trail itself.

-
-

-

The dtaudit provider relies on - audit(4) being compiled into the kernel. - dtaudit probes become available only once there is - an event-to-name mapping installed in the kernel, normally done by - auditd(8) during the boot process, if audit is enabled in - rc.conf(5):

-
-
auditd_enable="YES"
-
-

If dtaudit probes are required earlier in - boot -- for example, in single-user mode -- or without enabling - audit(4), they can be preloaded in the boot loader by - adding this line to loader.conf(5).

-
-
audit_event_load="YES"
-
-
-
-

-

The - () - probes fire synchronously during system-call return, giving access to two - arguments: a char * audit event name, and the - struct audit_record * in-kernel audit record. Because - the probe fires in system-call return, the user thread has not yet regained - control, and additional information from the thread and process remains - available for capture by the script.

-

The - () - probes fire asynchronously from system-call return, following BSM conversion - and just prior to being written to disk, giving access to four arguments: a - char * audit event name, the struct - audit_record * in-kernel audit record, a const void - * pointer to the converted BSM record, and a - size_t for the length of the BSM record.

-
-
-
-

-

When a set of dtaudit probes are - registered, corresponding in-kernel audit records will be captured and their - probes will fire regardless of whether the audit(4) - subsystem itself would have captured the record for the purposes of writing - it to the audit trail, or for delivery to a auditpipe(4). - In-kernel audit records allocated only because of enabled - dtaudit(4) probes will not be unnecessarily written to the - audit trail or enabled pipes.

-
-
-

-

dtrace(1), audit(4), - audit.log(5), loader.conf(5), - rc.conf(5), auditd(8)

-
-
-

-

The dtaudit provider first appeared in - FreeBSD 12.0.

-
-
-

-

This software and this manual page were developed by BAE Systems, - the University of Cambridge Computer Laboratory, and Memorial University - under DARPA/AFRL contract (FA8650-15-C-7558) (“CADETS”), as - part of the DARPA Transparent Computing (TC) research program. The - dtaudit provider and this manual page were written - by Robert Watson - <rwatson@FreeBSD.org>.

-
-
-

-

Because audit(4) maintains its primary - event-to-name mapping database in userspace, that database must be loaded - into the kernel before dtaudit probes become - available.

-

dtaudit is only able to provide access to - system-call audit events, not the full scope of userspace events, such as - those relating to login, password change, and so on.

-
-
- - - - - -
April 28, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_callout_execute.4 3.html b/static/freebsd/man4/dtrace_callout_execute.4 3.html deleted file mode 100644 index 8ed4d139..00000000 --- a/static/freebsd/man4/dtrace_callout_execute.4 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
DTRACE_CALLOUT_EXECUTE(4)Device Drivers ManualDTRACE_CALLOUT_EXECUTE(4)
-
-
-

-

dtrace_callout_execute — - a DTrace provider for the callout API

-
-
-

- - - - - -
callout_execute:kernel::callout_start
-
- - - - - -
callout_execute:kernel::callout_end
-
-
-

-

The callout_execute provider allows for - tracing the callout(9) mechanism.

-

The - callout_execute:kernel::callout_start - probe fires just before a callout.

-

The - callout_execute:kernel::callout_end - probe fires right after a callout.

-

The only argument to the callout_execute - probes, args[0], is a callout handler - struct callout * of the invoked callout.

-
-
-

-
-

-

The following d(7) script generates a - distribution graph of callout(9) execution times:

-
-
callout_execute:::callout_start
-{
-    self->cstart = timestamp;
-}
-
-callout_execute:::callout_end
-{
-    @length = quantize(timestamp - self->cstart);
-}
-
-
-
-
-

-

dtrace(1), tracing(7), - callout(9), SDT(9)

-
-
-

-

The callout_execute provider was written - by Robert N. M. Watson - <rwatson@FreeBSD.org>.

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
November 4, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_cam.4 4.html b/static/freebsd/man4/dtrace_cam.4 4.html deleted file mode 100644 index f8e3ca2a..00000000 --- a/static/freebsd/man4/dtrace_cam.4 4.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
DTRACE_CAM(4)Device Drivers ManualDTRACE_CAM(4)
-
-
-

-

dtrace_cam — a - DTrace provider for tracing events related to CAM

-
-
-

-

cam::xpt:action(union - ccb *ccn);

-

cam::xpt:done(union - ccb *ccb);

-

cam::xpt:async-cb(void - *cbarg, uint32_t - async_code, struct - cam_path *path, void - *async_Arg);

-
-
-

-

The cam provider allows the tracing of CAM - events. The - () - probe fires when a CAM Control Block (ccb) is submitted to a CAM SIM driver. - The - () - probe fires when that request completes. The - () - probe fires just before an async callback is called.

-
-
-

-
-
-

-
-
-

-
-
-

-

dtrace(1), SDT(9)

-
-
-

-

The cam provider first appeared in - FreeBSD 15.1 and 16.0.

-
-
-

-

This manual page was written by Warner - Losh - <imp@FreeBSD.org>.

-
-
- - - - - -
December 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_dtrace.4 3.html b/static/freebsd/man4/dtrace_dtrace.4 3.html deleted file mode 100644 index f8097489..00000000 --- a/static/freebsd/man4/dtrace_dtrace.4 3.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - -
DTRACE_DTRACE(4)Device Drivers ManualDTRACE_DTRACE(4)
-
-
-

-

dtrace_dtrace — a - DTrace provider for BEGIN, END, and ERROR probes

-
-
-

- - - - - -
dtrace:::BEGIN
-
- - - - - -
dtrace:::END
-
- - - - - -
dtrace:::ERROR
-
-
-

-

The dtrace provider implements three - special probes related to the life cycle of the DTrace program itself.

-
-

-

The dtrace:::BEGIN - probe fires at the beginning of a dtrace(1), program - before tracing has begun. It provides a convenient place for initializing - variables and printing column headers.

-

Variables such as stack or - execname cannot be relied upon in the execution - context of the - dtrace:::BEGIN probe.

-
-
-

-

The dtrace:::END - probe fires at the end of a dtrace(1) program, when all - tracing has stopped.

-
-
-

-

The dtrace:::ERROR - probe fires when an unexpected runtime error occurs in another probe.

-

The following table describes the arguments to - dtrace:::ERROR.

- - - - - - - - - - - - - - - - - - - - - - - - - -
arg1Enabled probe identifier (EPID) of the probe where the runtime error - occurred
arg2Index of the action statement that caused the error
arg3DIF offset into the action if available (otherwise -1)
arg4Fault type
arg5Accessed address (or 0 if not applicable) when - arg4 is of fault type - DTRACEFLT_BADADDR, - DTRACEFLT_BADALIGN, - DTRACEFLT_KPRIV, or - DTRACEFLT_UPRIV
-

The fault types are:

-
-
-
-
Unknown fault
-
-
Bad address
-
-
Bad alignment
-
-
Illegal operation
-
-
Divide-by-zero
-
-
Out of scratch space
-
-
Illegal kernel access
-
-
Illegal user access
-
-
Tuple stack overflow
-
-
Bad stack
-
-
-
-
-
-

-
-
<sys/dtrace.h>
-
The header file containing the definitions of DTrace fault types.
-
-
-
-

-
-

-

The following script uses the - dtrace:::BEGIN probe to - print column headers. Note the pragma line setting the - ‘quiet’ option to disable the default - column headers.

-
-
#pragma D option quiet
-
-dtrace:::BEGIN
-{
-    printf("   %12s %-20s    %-20s %s\n",
-        "DELTA(us)", "OLD", "NEW", "TIMESTAMP");
-}
-
-
-
-

-

The following script causes a runtime error by dereferencing a - pointer on address 19930908 in the - BEGIN probe. As a result, the - ERROR probe fires and prints out - “Oops” along with the probe arguments. At that point, the - program ends and fires the END probe.

-
-
ERROR
-{
-    printf("Oops\n");
-    printf("EPID (arg1): %d\n", arg1);
-    printf("Action index (arg2): %d\n", arg2);
-    printf("DIF offset (arg3): %d\n", arg3);
-    printf("Fault type (arg4): %d\n", arg4);
-    printf("Accessed address (arg5): %X\n", arg5);
-    exit(1);
-}
-BEGIN
-{
-    *(int *)0x19931101;
-}
-END {
-    printf("Bye");
-}
-
-

This script will result in the following output:

-
-
CPU     ID                    FUNCTION:NAME
-  2      3                           :ERROR Oops
-EPID (arg1): 2
-Action index (arg2): 1
-DIF offset (arg3): 16
-Fault type: 1
-arg5: 19931101
-
-dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): invalid address (0x19931101) in action #1 at DIF offset 16
-  2      2                             :END Bye
-
-
-
-
-

-

dtrace(1), tracing(7)

-

The illumos Dynamic Tracing - Guide, - https://illumos.org/books/dtrace/chp-dtrace.html, - 2008, Chapter dtrace - Provider.

-
-
-

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
-

-

The dtrace:::ERROR - probe arguments cannot be accessed through the typed - args[] array.

-

dtrace(1) will not fire the - dtrace:::ERROR probe - recursively. If an error occurs in one of the action statements of the - dtrace:::ERROR, then - dtrace(1) will abort further processing of the - dtrace:::ERROR probe's - actions.

-
-
- - - - - -
July 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_fbt.4 3.html b/static/freebsd/man4/dtrace_fbt.4 3.html deleted file mode 100644 index be0c843c..00000000 --- a/static/freebsd/man4/dtrace_fbt.4 3.html +++ /dev/null @@ -1,352 +0,0 @@ - - - - - - -
DTRACE_FBT(4)Device Drivers ManualDTRACE_FBT(4)
-
-
-

-

dtrace_fbt — a - DTrace provider for dynamic kernel tracing based on function - boundaries

-
-
-

- - - - - -
fbt:module:function:entry
-
- - - - - -
fbt:module:function:return
-
-
-

-

The Function Boundary Tracing (fbt) - provider instruments the entry and return of almost every kernel function - corresponding to an elf(5) symbol in the kernel and loaded - kernel modules.

-

fbt:module:function:entry - fires whenever the function is called. - fbt:module:function:return - fires when the function returns.

-

The module in the probe description is - either the name of the loaded kernel module or - ‘kernel’ for functions compiled into - the kernel.

-
-

-

The fbt will always instrument a - function's entry, but its return will be intsrumented so long as it can find - a ‘ret’ instruction.

-

In some cases, fbt cannot instrument a - function's entry and/or return. Refer to subsection - Frame Pointer for more details.

-
-
-

-

The arguments of the entry probe - (fbt:module:function:entry) - are the arguments of the traced function call.

- - - - - - - - - - - - - - - - - - - - - -
args[0]Function's first argument, typed (e.g., malloc(9)'s - size_t size)
args[1]Function's second argument, typed (e.g., malloc(9)'s - struct malloc_type *type)
args[2]Function's third argument, typed (e.g., malloc(9)'s - int flags)
......
-

The arguments of the return probe - (fbt:module:function:return) - are args[0] (the offset of the firing return - instruction within the function; useful to tell apart two different return - statements in a single function) and args[1] (the - return value, if any).

- - - - - - - - - - - - - -
args[0]Offset of the traced return instruction
args[1]Function's return value (e.g., a kernel virtual address if returning - from a successful malloc(9))
-

Subsection Example 2: - Getting - Details About Probe's Arguments shows how to get probe's argument count - and types directly with dtrace(1) without having to resort - to the reading function's source code or documentation.

-
-
-
-

-
-

-

The following example shows how to list all the available - fbt probes.

-
-
# dtrace -l -P fbt
-   ID   PROVIDER     MODULE              FUNCTION NAME
-[...]
-31868        fbt     kernel           hammer_time entry
-31869        fbt     kernel           hammer_time return
-[...]
-
-

Since hammer_time() is a part of the - kernel and not a separate loaded module, the module - column displays ‘kernel’.

-
-
-

-

The following example shows how to generate a program stability - report of malloc(9)'s entry and return probes. Those - reports are useful to view the probe's number of arguments and their - types.

-
-
# dtrace -l -v -n fbt::malloc:entry
-[...]
-        Argument Types
-                args[0]: size_t
-                args[1]: struct malloc_type *
-                args[2]: int
-
-

The count and types of - fbt::malloc:entry arguments - match the function signature of malloc(9): - args[0] is size_t, - args[1] is struct malloc_type *, - and args[2] is int.

-
-
# dtrace -l -v -n fbt::malloc:return
-[...]
-        Argument Types
-                args[0]: int
-                args[1]: void *
-
-

The return probe reports two arguments and - their types: the return instruction offset (the usual - int) and the function's return value, which in this - case is void *, as malloc(9) returns - a kernel virtual address.

-
-
-

-
-
# dtrace -n 'fbt::kmem*:entry { @[probefunc] = count(); }'
-dtrace: description 'fbt::kmem*:entry ' matched 47 probes
-^C
-  kmem_alloc_contig                                     1
-  kmem_alloc_contig_domainset                           1
-  kmem_cache_reap_active                                1
-  kmem_alloc_contig_pages                               2
-  kmem_free                                             2
-  kmem_std_destructor                                  19
-  kmem_std_constructor                                 26
-  kmem_cache_free                                     151
-  kmem_cache_alloc                                    181
-
-
-
-

-
-
# dtrace -q -n 'fbt::kmem*:entry { @[caller] = count(); } END { printa("%40a %@16d\n", @); }'
-^C
-                kernel`contigmalloc+0x33                1
-                        kernel`free+0xd3                1
-           kernel`kmem_alloc_contig+0x29                1
-kernel`kmem_alloc_contig_domainset+0x19a                1
-           zfs.ko`arc_reap_cb_check+0x16                1
-
-
-
-

-
-
# dtrace -q -n 'fbt::malloc:entry { @[caller] = count(); } END { printa("%45a %@16d\n", @); }'
-^C
-        kernel`devclass_get_devices+0xa8                1
-                   kernel`sys_ioctl+0xb7                1
-           dtrace.ko`dtrace_ioctl+0x15c1                1
-            dtrace.ko`dtrace_ioctl+0x972                2
-        dtrace.ko`dtrace_dof_create+0x35                2
-             kernel`kern_poll_kfds+0x2f0                4
-             kernel`kern_poll_kfds+0x28a               19
-
-
-
-

-
-
# dtrace -q -n 'fbt::malloc:entry { @[stack()] = count(); }'
-^C
-              dtrace.ko`dtrace_dof_create+0x35
-              dtrace.ko`dtrace_ioctl+0x827
-              kernel`devfs_ioctl+0xd1
-              kernel`VOP_IOCTL_APV+0x2a
-              kernel`vn_ioctl+0xb6
-              kernel`devfs_ioctl_f+0x1e
-              kernel`kern_ioctl+0x286
-              kernel`sys_ioctl+0x12f
-              kernel`amd64_syscall+0x169
-              kernel`0xffffffff81092b0b
-                2
-
-
-
-

-
-
# dtrace -q -n 'fbt::vmem_alloc:entry { @[args[0]->vm_name] = quantize(arg1); }'
-^C
-
-  kernel arena dom
-           value  ------------- Distribution ------------- count
-            2048 |                                         0
-            4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@              4
-            8192 |@@@@@@@@@@@@@                            2
-           16384 |                                         0
-
-
-
-

-

This DTrace script measures the total time spent in - vm_page*() kernel functions. The - quantize() aggregation organizes the measurements - into power-of-two buckets, providing a time distribution in nanoseconds for - each function.

-
-
fbt::vm_page*:entry {
-    self->start = timestamp;
-}
-
-fbt::vm_page*:return /self->start/ {
-    @[probefunc] = quantize(timestamp - self->start);
-    self->start = 0;
-}
-
-
-
-
-

-

dtrace(1), dtrace_kinst(4), - tracing(7)

-

Brendan Gregg and - Jim Mauro, DTrace: Dynamic Tracing - in Oracle Solaris, Mac OS X and FreeBSD, Prentice - Hall, - https://www.brendangregg.com/dtracebook/, - pp. 898–903, - 2011.

-

The illumos Dynamic Tracing - Guide, - https://illumos.org/books/dtrace/chp-fbt.html#chp-fbt, - 2008, Chapter fbt - Provider.

-
-
-

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
-

-
-

-

fbt probes are by definition tightly - coupled to kernel code; if the code underlying a script changes, the script - may fail to run or may produce incorrect results. Scripts written for one - version of FreeBSD might not work on others, and - almost certainly will not work on other operating systems.

-

Individual fbt probes often do not - correspond nicely to logical system events. For example, consider a DTrace - script which prints the destination address of every IP packet as the kernel - hands them over to the network card driver (NIC). An - fbt-based implementation of such a script is a - discouragingly difficult task: it involves instrumenting at least four - different functions in different parts of the IPv4 and IPv6 code. At the - same time, with the dtrace_ip(4) provider the script is a - simple one-liner:

-
dtrace -n 'ip:::send - {printf("%s", args[2]->ip_daddr);}'
-

Make sure to review available dtrace(1) - providers first before implementing a custom script with the - fbt provider. If none of the DTrace providers offer - the desired probes, consider adding new statically-defined tracing probes - (SDT(9)).

-
-
-

-

Inline functions are not instrumentable by - fbt as they lack a frame pointer. A developer might - explicitly disable inlining by adding the - ‘__noinline’ attribute to a function - definition, but of course this requires a recompilation of the kernel. - Building the kernel with -fno-omit-frame-pointer is - another way of preserving frame pointers. Note, that sometimes compilers - will omit the frame pointer in leaf functions, even when configured with - -fno-omit-frame-pointer.

-

Function returns via a tail call are also not instrumentable by - fbt. As a result, a function might have an entry - probe and a mix of instrumented and uninstrumentable returns.

-

Use dtrace_kinst(4) to trace arbitrary - instructions inside kernel functions and work around some of the limitations - of fbt.

-
-
-

-

The fbt provider cannot attach to - functions inside DTrace provider kernel modules.

-
-
-
- - - - - -
July 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_io.4 3.html b/static/freebsd/man4/dtrace_io.4 3.html deleted file mode 100644 index 71eeeb78..00000000 --- a/static/freebsd/man4/dtrace_io.4 3.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - -
DTRACE_IO(4)Device Drivers ManualDTRACE_IO(4)
-
-
-

-

dtrace_io — a - DTrace provider for tracing events related to disk I/O

-
-
-

-

io:::start(struct - bio *, struct devstat - *);

-

io:::done(struct - bio *, struct devstat - *);

-
-
-

-

The io provider allows the tracing of disk - I/O events. The - () - probe fires when a I/O request is about to be sent to the backing driver of - a disk(9) object. This occurs after all - GEOM(4) transformations have been performed on the - request. The - () - probe fires when a I/O request is completed. Both probes take a - struct bio * representing the I/O request as their - first argument. The second argument is a struct devstat - * for the underlying disk(9) object.

-
-
-

-

The fields of struct bio are described in - the g_bio(9) manual page, and the fields of - struct devstat are described in the - devstat(9) manual page. Translators for the - bufinfo_t and devinfo_t D types - are defined in /usr/lib/dtrace/io.d.

-
-
-

-
-
/usr/lib/dtrace/io.d
-
DTrace type and translator definitions for the io - provider.
-
-
-
-

-

The following script shows a per-process breakdown of total I/O by - disk device:

-
-
#pragma D option quiet
-
-io:::start
-{
-        @[args[1]->device_name, execname, pid] = sum(args[0]->bio_length);
-}
-
-END
-{
-        printf("%10s %20s %10s %15s\n", "DEVICE", "APP", "PID", "BYTES");
-        printa("%10s %20s %10d %15@d\n", @);
-}
-
-
-
-

-

This provider is not compatible with the - io provider found in Solaris, as its probes use - native FreeBSD argument types.

-
-
-

-

dtrace(1), devstat(9), - SDT(9)

-
-
-

-

The io provider first appeared in - FreeBSD 9.2 and 10.0.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org>.

-
-
-

-

The io:::wait-start() and - io:::wait-done() probes are not currently - implemented on FreeBSD.

-
-
- - - - - -
October 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_ip.4 3.html b/static/freebsd/man4/dtrace_ip.4 3.html deleted file mode 100644 index 81db8858..00000000 --- a/static/freebsd/man4/dtrace_ip.4 3.html +++ /dev/null @@ -1,265 +0,0 @@ - - - - - - -
DTRACE_IP(4)Device Drivers ManualDTRACE_IP(4)
-
-
-

-

dtrace_ip — a - DTrace provider for tracing events related to the IPv4 and IPv6 - protocols

-
-
-

-

ip:::receive(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - ifinfo_t *, - ipv4info_t *, - ipv6info_t *);

-

ip:::send(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - ifinfo_t *, - ipv4info_t *, - ipv6info_t *);

-
-
-

-

The DTrace ip provider allows users to - trace events in the ip(4) and ip6(4) - protocol implementations. The - () - probe fires whenever the kernel prepares to transmit an IP packet, and the - () - probe fires whenever the kernel receives an IP packet. The arguments to - these probes can be used to obtain detailed information about the IP headers - of the corresponding packet, as well as the network interface on which the - packet was sent or received. Unlike the dtrace_tcp(4) and - dtrace_udp(4) providers, ip - provider probes are triggered by forwarded packets. That is, the probes will - fire on packets that are not destined to the local host.

-
-
-

-

The pktinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t pkt_addr
-
Always set to 0.
-
-
-

The csinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t cs_addr
-
Always set to 0.
-
uint64_t cs_cid
-
A pointer to the struct inpcb for this packet, or - NULL.
-
pid_t cs_pid
-
Always set to 0.
-
-
-

The ipinfo_t argument contains IP fields - common to both IPv4 and IPv6 packets. Its fields are:

-
-
-
uint8_t ip_ver
-
IP version of the packet, 4 for IPv4 packets and 6 for IPv6 packets.
-
uint32_t ip_plength
-
IP payload size. This does not include the size of the IP header or IPv6 - option headers.
-
string ip_saddr
-
IP source address.
-
string ip_daddr
-
IP destination address.
-
-
-

The ifinfo_t argument - describes the outgoing and incoming interfaces for the packet in the - () - and - () - probes respectively. Its fields are:

-
-
-
string if_name
-
The interface name.
-
int8_t if_local
-
A boolean value indicating whether or not the interface is a loopback - interface.
-
uintptr_t if_addr
-
A pointer to the struct ifnet which describes the - interface. See the ifnet(9) manual page.
-
-
-

The ipv4info_t argument contains - the fields of the IP header for IPv4 packets. This argument is - NULL for IPv6 packets. DTrace scripts should use the - () - field in the ipinfo_t argument to determine whether to - use this argument. Its fields are:

-
-
-
uint8_t ipv4_ver
-
IP version. This will always be 4 for IPv4 packets.
-
uint8_t ipv4_ihl
-
The IP header length, including options, in 32-bit words.
-
uint8_t ipv4_tos
-
IP type of service field.
-
uint16_t ipv4_length
-
The total packet length, including the header, in bytes.
-
uint16_t ipv4_ident
-
Identification field.
-
uint8_t ipv4_flags
-
The IP flags.
-
uint16_t ipv4_offset
-
The fragment offset of the packet.
-
uint8_t ipv4_ttl
-
Time to live field.
-
uint8_t ipv4_protocol
-
Next-level protocol ID.
-
string ipv4_protostr
-
A string containing the name of the encapsulated protocol. The protocol - strings are defined in the protocol array in - /usr/lib/dtrace/ip.d
-
uint16_t ipv4_checksum
-
The IP checksum.
-
ipaddr_t ipv4_src
-
IPv4 source address.
-
ipaddr_t ipv4_dst
-
IPv4 destination address.
-
string ipv4_saddr
-
A string representation of the source address.
-
string ipv4_daddr
-
A string representation of the destination address.
-
ipha_t *ipv4_hdr
-
A pointer to the raw IPv4 header.
-
-
-

The ipv6info_t argument - contains the fields of the IP header for IPv6 packets. Its fields are not - set for IPv4 packets; as with the ipv4info_t argument, - the - () - field should be used to determine whether this argument is valid. Its fields - are:

-
-
-
uint8_t ipv6_ver
-
IP version. This will always be 6 for IPv6 packets.
-
uint8_t ipv6_tclass
-
The traffic class, used to set the differentiated services codepoint and - extended congestion notification flags.
-
uint32_t ipv6_flow
-
The flow label of the packet.
-
uint16_t ipv6_plen
-
The IP payload size, including extension headers, in bytes.
-
uint8_t ipv6_nexthdr
-
An identifier for the type of the next header.
-
string ipv6_nextstr
-
A string representation of the type of the next header.
-
uint8_t ipv6_hlim
-
The hop limit.
-
ip6_addr_t *ipv6_src
-
IPv6 source address.
-
ip6_addr_t *ipv6_dst
-
IPv6 destination address.
-
string ipv6_saddr
-
A string representation of the source address.
-
string ipv6_daddr
-
A string representation of the destination address.
-
struct ip6_hdr *ipv6_hdr
-
A pointer to the raw IPv6 header.
-
-
-
-
-

-
-
/usr/lib/dtrace/ip.d
-
DTrace type and translator definitions for the ip - provider.
-
-
-
-

-

The following script counts received packets by remote host - address.

-
-
ip:::receive
-{
-        @num[args[2]->ip_saddr] = count();
-}
-
-

This script will print some details of each IP packet as it is - sent or received by the kernel:

-
-
#pragma D option quiet
-#pragma D option switchrate=10Hz
-
-dtrace:::BEGIN
-{
-        printf(" %10s %30s    %-30s %8s %6s\n", "DELTA(us)", "SOURCE",
-            "DEST", "INT", "BYTES");
-        last = timestamp;
-}
-
-ip:::send
-{
-        this->elapsed = (timestamp - last) / 1000;
-        printf(" %10d %30s -> %-30s %8s %6d\n", this->elapsed,
-            args[2]->ip_saddr, args[2]->ip_daddr, args[3]->if_name,
-            args[2]->ip_plength);
-        last = timestamp;
-}
-
-ip:::receive
-{
-        this->elapsed = (timestamp - last) / 1000;
-        printf(" %10d %30s <- %-30s %8s %6d\n", this->elapsed,
-            args[2]->ip_daddr, args[2]->ip_saddr, args[3]->if_name,
-            args[2]->ip_plength);
-        last = timestamp;
-}
-
-
-
-

-

This provider is compatible with the ip - providers found in Solaris and Darwin.

-
-
-

-

dtrace(1), dtrace_tcp(4), - dtrace_udp(4), ip(4), - ip6(4), ifnet(9), - SDT(9)

-
-
-

-

The ip provider first appeared in - FreeBSD 10.0.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org>.

-
-
- - - - - -
September 14, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_kinst.4 3.html b/static/freebsd/man4/dtrace_kinst.4 3.html deleted file mode 100644 index 504cb7c0..00000000 --- a/static/freebsd/man4/dtrace_kinst.4 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
DTRACE_KINST(4)Device Drivers ManualDTRACE_KINST(4)
-
-
-

-

dtrace_kinst — a - DTrace provider for tracing arbitrary instructions in a given kernel - function

-
-
-

-

kinst::<function>:<instruction>

-
-
-

-

The DTrace kinst provider allows the user - to trace any instruction in a given kernel function. <function> - corresponds to the function to be traced, and <instruction> is the - offset to the specific instruction, and can be obtained from the function's - disassembly using kgdb from the gdb package.

-

kinst creates probes on-demand, meaning it - searches for and parses the function's instructions each time - dtrace(1) is run, and not at module load time. This is in - contrast to dtrace_fbt(4)'s load-time parsing, since - kinst can potentially create thousands of probes for - just a single function, instead of up to two (entry and return) in the case - of dtrace_fbt(4). A result of this is that - dtrace -l -P kinst will not match any probes.

-
-
-

-

The provider is currently implemented only for amd64.

-
-
-

-

Find the offset corresponding to the third instruction in - vm_fault() and trace it, printing the contents of - the RSI register:

-
-
# kgdb
-(kgdb) disas /r vm_fault
-Dump of assembler code for function vm_fault:
-   0xffffffff80876df0 <+0>:     55      push   %rbp
-   0xffffffff80876df1 <+1>:     48 89 e5        mov    %rsp,%rbp
-   0xffffffff80876df4 <+4>:     41 57   push   %r15
-
-# dtrace -n 'kinst::vm_fault:4 {printf("%#x", regs[R_RSI]);}'
-  2  81500                       vm_fault:4 0x827c56000
-  2  81500                       vm_fault:4 0x827878000
-  2  81500                       vm_fault:4 0x1fab9bef0000
-  2  81500                       vm_fault:4 0xe16cf749000
-  0  81500                       vm_fault:4 0x13587c366000
-  ...
-
-

Trace all instructions in - amd64_syscall():

-
-
# dtrace -n 'kinst::amd64_syscall:'
-
-
-
-

-

dtrace(1), dtrace_fbt(4)

-
-
-

-

The kinst provider first appeared in - FreeBSD 14.0.

-
-
-

-

This manual page was written by Christos - Margiolis - <christos@FreeBSD.org>.

-
-
- - - - - -
July 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_lockstat.4 3.html b/static/freebsd/man4/dtrace_lockstat.4 3.html deleted file mode 100644 index 61bc1ce2..00000000 --- a/static/freebsd/man4/dtrace_lockstat.4 3.html +++ /dev/null @@ -1,254 +0,0 @@ - - - - - - -
DTRACE_LOCKSTAT(4)Device Drivers ManualDTRACE_LOCKSTAT(4)
-
-
-

-

dtrace_lockstat — - a DTrace provider for tracing kernel locking - events

-
-
-

-

lockstat:::adaptive-acquire(struct - mtx *);

-

lockstat:::adaptive-release(struct - mtx *);

-

lockstat:::adaptive-spin(struct - mtx *, - uint64_t);

-

lockstat:::adaptive-block(struct - mtx *, - uint64_t);

-

lockstat:::spin-acquire(struct - mtx *);

-

lockstat:::spin-release(struct - mtx *);

-

lockstat:::spin-spin(struct - mtx *, - uint64_t);

-

lockstat:::rw-acquire(struct - rwlock *, int);

-

lockstat:::rw-release(struct - rwlock *, int);

-

lockstat:::rw-block(struct - rwlock *, uint64_t, - int, - int, - int);

-

lockstat:::rw-spin(struct - rwlock *, - uint64_t);

-

lockstat:::rw-upgrade(struct - rwlock *);

-

lockstat:::rw-downgrade(struct - rwlock *);

-

lockstat:::sx-acquire(struct - sx *, int);

-

lockstat:::sx-release(struct - sx *, int);

-

lockstat:::sx-block(struct - sx *, uint64_t, - int, - int, - int);

-

lockstat:::sx-spin(struct - sx *, - uint64_t);

-

lockstat:::sx-upgrade(struct - sx *);

-

lockstat:::sx-downgrade(struct - sx *);

-

lockstat:::lockmgr-acquire(struct - lock *, int);

-

lockstat:::lockmgr-release(struct - lock *, int);

-

lockstat:::lockmgr-disown(struct - lock *, int);

-

lockstat:::lockmgr-block(struct - lock *, uint64_t, - int, - int, - int);

-

lockstat:::lockmgr-upgrade(struct - lock *);

-

lockstat:::lockmgr-downgrade(struct - lock *);

-

lockstat:::thread-spin(struct - mtx *, uint64);

-
-
-

-

The DTrace lockstat provider allows the - tracing of events related to locking on FreeBSD.

-

The dtrace_lockstat provider - contains DTrace probes for inspecting kernel lock state transitions. Probes - exist for the lockmgr(9), mutex(9), - rwlock(9), and sx(9) lock types. The - lockstat(1) utility can be used to collect and display - data collected from the dtrace_lockstat provider. - Each type of lock has - () - and - () - probes which expose the lock structure being operated upon, as well as - probes which fire when a thread contends with other threads for ownership of - a lock.

-

The - () - and - () - probes fire when an MTX_DEF - mutex(9) is acquired and released, respectively. The only - argument is a pointer to the lock structure which describes the lock being - acquired or released.

-

The - () - probe fires when a thread spins while waiting for a - MTX_DEF mutex(9) to be released by - another thread. The first argument is a pointer to the lock structure that - describes the lock and the second argument is the amount of time, in - nanoseconds, that the mutex spent spinning. The - () - probe fires when a thread takes itself off the CPU while trying to acquire - an MTX_DEF mutex(9) that is owned - by another thread. The first argument is a pointer to the lock structure - that describes the lock and the second argument is the length of time, in - nanoseconds, that the waiting thread was blocked. The - lockstat:::adaptive-block() and - lockstat:::adaptive-spin() probes fire only after - the lock has been successfully acquired, and in particular, after the - lockstat:::adaptive-acquire() probe fires.

-

The - () - and - () - probes fire when a MTX_SPIN - mutex(9) is acquired or released, respectively. The only - argument is a pointer to the lock structure which describes the lock being - acquired or released.

-

The - () - probe fires when a thread spins while waiting for a - MTX_SPIN mutex(9) to be released - by another thread. The first argument is a pointer to the lock structure - that describes the lock and the second argument is the length of the time - spent spinning, in nanoseconds. The - lockstat:::spin-spin() probe fires only after the - lock has been successfully acquired, and in particular, after the - lockstat:::spin-acquire() probe fires.

-

The - () - and - () - probes fire when a rwlock(9) is acquired or released, - respectively. The first argument is a pointer to the structure which - describes the lock being acquired. The second argument is - 0 if the lock is being acquired or released as a - writer, and 1 if it is being acquired or released as - a reader. The - () - and - (), - and - () - and - () - probes fire upon the corresponding events for sx(9) and - lockmgr(9) locks, respectively. The - () - probe fires when a lockmgr(9) exclusive lock is disowned. - In this state, the lock remains exclusively held, but may be released by a - different thread. The lockstat:::lockmgr-release() - probe does not fire when releasing a disowned lock. The first argument is a - pointer to the structure which describes the lock being disowned. The second - argument is 0, for compatibility with - lockstat:::lockmgr-release().

-

The - (), - (), - and - () - probes fire when a thread removes itself from the CPU while waiting to - acquire a lock of the corresponding type. The - () - and - () - probes fire when a thread spins while waiting to acquire a lock of the - corresponding type. All probes take the same set of arguments. The first - argument is a pointer to the lock structure that describes the lock. The - second argument is the length of time, in nanoseconds, that the waiting - thread was off the CPU or spinning for the lock. The third argument is - 0 if the thread is attempting to acquire the lock as - a writer, and 1 if the thread is attempting to - acquire the lock as a reader. The fourth argument is - 0 if the thread is waiting for a reader to release - the lock, and 1 if the thread is waiting for a - writer to release the lock. The fifth argument is the number of readers that - held the lock when the thread first attempted to acquire the lock. This - argument will be 0 if the fourth argument is - 1.

-

The - (), - (), - and - () - probes fire when a thread successfully upgrades a held - lockmgr(9), rwlock(9), or - sx(9) shared/reader lock to an exclusive/writer lock. The - only argument is a pointer to the structure which describes the lock being - acquired. The - (), - (), - and - () - probes fire when a thread downgrades a held lockmgr(9), - rwlock(9), or sx(9) exclusive/writer - lock to a shared/reader lock.

-

The - () - probe fires when a thread spins on a thread lock, which is a specialized - MTX_SPIN mutex(9). The first - argument is a pointer to the structure that describes the lock and the - second argument is the length of time, in nanoseconds, that the thread was - spinning.

-
-
-

-

dtrace(1), lockstat(1), - locking(9), mutex(9), - rwlock(9), SDT(9), - sx(9)

-
-
-

-

The dtrace_lockstat provider first - appeared in Solaris. The FreeBSD implementation of - the dtrace_lockstat provider first appeared in - FreeBSD 9.

-
-
-

-

This manual page was written by George V. - Neville-Neil - <gnn@FreeBSD.org> and - Mark Johnston - <markj@FreeBSD.org>.

-
-
-

-

Probes for rmlock(9) locks have not yet been - added.

-
-
- - - - - -
September 3, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_pid.4 3.html b/static/freebsd/man4/dtrace_pid.4 3.html deleted file mode 100644 index 1940d840..00000000 --- a/static/freebsd/man4/dtrace_pid.4 3.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - -
DTRACE_PID(4)Device Drivers ManualDTRACE_PID(4)
-
-
-

-

dtrace_pid — a - DTrace provider for dynamic userspace tracing based on function boundary - instrumentation

-
-
-

- - - - - -
pidPID:module:function:entry
-
- - - - - -
pidPID:module:function:[offset]
-
- - - - - -
pidPID:module:function:return
-
-
-

-

The pid provider implements userspace - dynamic tracing by instrumenting the entry and return of functions in - userspace programs. Refer to dtrace_fbt(4) for more - details about function boundary instrumentation.

-

The pid provider provides the following - probes:

-
-
pidPID:module:function:entry
-
instruments the entry of the function.
-
pidPID:module:function:[offset]
-
instruments the instruction within the function - located at offset bytes (expressed as a hexadecimal - integer).
-
pidPID:module:function:return
-
instruments the return from the function.
-
-
-

-

The arguments of the entry probe - (pidPID:module:function:entry) - are the arguments of the traced function call.

- - - - - - - - - - - - - - - - - - - - - -
uint64_t arg0Function's first argument
uint64_t arg1Function's second argument
uint64_t arg2Function's third argument
......
-

The offset probes - (pidPID:module:function:[offset]) - do not define any arguments. Use uregs[] to inspect - the registers.

-

The arguments of the return probe - (pidPID:module:function:return) - are the program counter and the function's return value.

- - - - - - - - - - - - - -
uint64_t arg0Program counter
uint64_t arg1Function's return value
-

Note that all probe arguments within the - pid provider are of type - uint64_t.

-
-
-
-

-

dtrace(1), dtrace_fbt(4), - dtrace_kinst(4), elf(5), - d(7), tracing(7)

-

Brendan Gregg and - Jim Mauro, DTrace: Dynamic Tracing - in Oracle Solaris, Mac OS X and FreeBSD, Prentice - Hall, - https://www.brendangregg.com/dtracebook/, - 2011.

-

The illumos Dynamic Tracing - Guide, - https://illumos.org/books/dtrace/chp-pid.html, - 2008, Chapter pid - Provider.

-
-
-

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
November 6, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_priv.4 4.html b/static/freebsd/man4/dtrace_priv.4 4.html deleted file mode 100644 index 6c06cb3a..00000000 --- a/static/freebsd/man4/dtrace_priv.4 4.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
DTRACE_PRIV(4)Device Drivers ManualDTRACE_PRIV(4)
-
-
-

-

dtrace_priv — a - DTrace provider for the kernel privilege checking API

-
-
-

- - - - - -
priv:kernel:priv_check:priv-ok
-
- - - - - -
priv:kernel:priv_check:priv-err
-
-
-

-

The priv provider allows for tracing the - priv(9) API.

-

The - priv:kernel:priv_check:priv-ok - probe fires upon a successful kernel privilege check.

-

The - priv:kernel:priv_check:priv-err - probe fires upon a failed kernel privilege check.

-

The only argument to the priv probes, - args[0], is the requested privilege number - int priv.

-
-
-

-
-

-

The following script captures an array of counters, one for each - stack trace leading to a failed kernel privilege check:

-
-
priv:::priv-err
-{
-	@traces[stack()] = count();
-}
-
-
-
-
-

-

dtrace(1), tracing(7), - priv(9), SDT(9)

-
-
-

-

The priv provider was written by - Robert N. M. Watson - <rwatson@FreeBSD.org>.

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
November 12, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_proc.4 3.html b/static/freebsd/man4/dtrace_proc.4 3.html deleted file mode 100644 index 9d6489b3..00000000 --- a/static/freebsd/man4/dtrace_proc.4 3.html +++ /dev/null @@ -1,213 +0,0 @@ - - - - - - -
DTRACE_PROC(4)Device Drivers ManualDTRACE_PROC(4)
-
-
-

-

dtrace_proc — a - DTrace provider for tracing events related to user processes

-
-
-

-

proc:::create(struct - proc *, struct proc - *, int);

-

proc:::exec(char - *);

-

proc:::exec-failure(int);

-

proc:::exec-success(char - *);

-

proc:::exit(int);

-

proc:::signal-clear(int, - ksiginfo_t *);

-

proc:::signal-discard(struct - thread *, struct proc - *, int);

-

proc:::signal-send(struct - thread *, struct proc - *, int);

-
-
-

-

The DTrace proc provider provides insight - into events related to user processes: process and thread creation and - termination events, and process signalling.

-

The - () - probe fires when a user process is created via the - fork(2), vfork(2), - pdfork(2), or rfork(2) system calls. In - particular, kernel processes created with the kproc(9) KPI - will not trigger this probe. The proc:::create() - probe's first two arguments are the new child process and its parent, - respectively. The third argument is a mask of rfork(2) - flags indicating which process resources are to be shared between the parent - and child processes.

-

The - () - probe fires when a process attempts to execute a file. Its argument is the - specified filename for the file. If the attempt fails because of an error, - the - () - probe will subsequently fire, providing the corresponding - errno(2) value in its first argument. Otherwise, the - () - probe will fire.

-

The - () - probe fires when a process exits or is terminated. Its argument is the - corresponding SIGCHLD signal code; valid values are - documented in the siginfo(3) manual page and defined in - signal.h. For example, when a process exits - normally, the value of args[0] will be - CLD_EXITED.

-

The - () - probe fires when a signal is about to be sent to a process. The - () - probe fires when a signal is sent to a process that ignores it. This probe - will fire after the proc:::signal-send() probe for - the signal in question. The arguments to these probes are the thread and - process to which the signal will be sent, and the signal number of the - signal. Valid signal numbers are defined in the signal(3) - manual page. The - () - probe fires when a pending signal has been cleared by one of the - sigwait(2), sigtimedwait(2), or - sigwaitinfo(2) system calls. Its arguments are the signal - number of the cleared signal, and a pointer to the corresponding signal - information. The siginfo_t for the signal can be - obtained from args[1]->ksi_info.

-
-
-

-

Though the proc provider probes use native - FreeBSD arguments types, standard D types for - processes and threads are available. These are - psinfo_t and lwpsinfo_t - respectively, and are defined in - /usr/lib/dtrace/psinfo.d. This file also defines two - global variables, curpsinfo and - curlwpsinfo, which provide representations of the - current process and thread using these types.

-

The fields of psinfo_t are:

-
-
-
int pr_nlwp
-
Number of threads in the process.
-
pid_t pr_pid
-
Process ID.
-
pid_t pr_ppid
-
Process ID of the parent process, or 0 if the process does not have a - parent.
-
pid_t pr_pgid
-
Process ID of the process group leader.
-
pid_t pr_sid
-
Session ID, or 0 if the process does not belong to a session.
-
pid_t pr_uid
-
Real user ID.
-
pid_t pr_euid
-
Effective user ID.
-
pid_t pr_gid
-
Real group ID.
-
pid_t pr_egid
-
Effective group ID.
-
uintptr_t pr_addr
-
Pointer to the struct proc for the process.
-
string pr_psargs
-
Process arguments.
-
u_int pr_arglen
-
Length of the process argument string.
-
u_int pr_jailid
-
Jail ID of the process.
-
-
-

The fields of lwpsinfo_t are:

-
-
-
id_t pr_lwpid
-
Thread ID.
-
int pr_flag
-
Thread flags.
-
int pr_pri
-
Real scheduling priority of the thread.
-
char pr_state
-
Currently always 0.
-
char pr_sname
-
Currently always ‘?’.
-
short pr_syscall
-
Currently always 0.
-
uintptr_t pr_addr
-
Pointer to the struct thread for the thread.
-
uintptr_t pr_wchan
-
Current wait address on which the thread is sleeping.
-
-
-
-
-

-
-
/usr/lib/dtrace/psinfo.d
-
DTrace type and translator definitions for the - proc provider.
-
-
-
-

-

The following script logs process execution events as they - occur:

-
-
#pragma D option quiet
-
-proc:::exec-success
-{
-        printf("%s", curpsinfo->pr_psargs);
-}
-
-

Note that the pr_psargs field is subject - to the limit defined by the kern.ps_arg_cache_limit - sysctl. In particular, processes with an argument list longer than the value - defined by this sysctl cannot be logged in this way.

-
-
-

-

The proc provider in - FreeBSD is not compatible with the - proc provider in Solaris. In particular, - FreeBSD uses the native struct - proc and struct thread types for probe arguments - rather than translated types. Additionally, a number of - proc provider probes found in Solaris are not - currently available on FreeBSD.

-
-
-

-

dtrace(1), errno(2), - fork(2), pdfork(2), - rfork(2), vfork(2), - siginfo(3), signal(3), - dtrace_sched(4), kproc(9)

-
-
-

-

The proc provider first appeared in - FreeBSD 7.1.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org>.

-
-
- - - - - -
March 3, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_profile.4 3.html b/static/freebsd/man4/dtrace_profile.4 3.html deleted file mode 100644 index 05375af3..00000000 --- a/static/freebsd/man4/dtrace_profile.4 3.html +++ /dev/null @@ -1,177 +0,0 @@ - - - - - - -
DTRACE_PROFILE(4)Device Drivers ManualDTRACE_PROFILE(4)
-
-
-

-

dtrace_profile — a - DTrace provider for firing probes at a given time interval

-
-
-

- - - - - -
profile:::profile-rate[unit]
-
- - - - - -
profile:::tick-rate[unit]
-
-
-

-

The profile provider implements three - special probes related to the life cycle of the DTrace program itself.

-
-

-

The - profile:::profile probes - fire on all CPUs and are suitable for measuring the whole system - periodically.

-

The profile:::tick - probes fire on a single CPU, potentially a different one every time. They - are useful, e.g., for printing partial results periodically.

-
-
-

-

The profile provider probes will fire at - the specified rate.

-

The default unit is hz. The - profile provider supports the following time - units:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
, - nsecnanoseconds
, - usecmicroseconds
, - msecmilliseconds
, - secseconds
, - minminutes
, - hourhours
, - daydays
Hertz (frequency per second)
-
-
-

-

The arguments of the profile provider - probes are:

-
-
arg0
-
The PC (program counter) in the kernel when the probe triggered, or 0 if - the process was not in the kernel at that time.
-
arg1
-
The PC in the user process when the probe triggered, or 0 if the process - was in the kernel when the probe triggered.
-
-

Use arguments arg0 and - arg1 to tell if the profile - provider probe fired in the kernel or in the userspace context.

-
-
-
-

-

The sysctl(8) variable - kern.dtrace.profile.aframes controls the number of - skipped artificial frames for the profile - provider.

-
-
-

-
-

-

The following DTrace one-liner uses the - profile provider to collect stack traces over 60 - seconds.

-
-
dtrace -x stackframes=100 -n 'profile-197 /arg0/ {@[stack()] = count();} tick-60s {exit(0);}
-
-

The system is profiled at the 197 Hz to avoid sampling in lockstep - with other periodic activities. This unnatural frequency minimizes the - chance of overlapping with other events.

-

Option -x - stackframes=100 increases the maximum number of - kernel stack frames to unwind during stack().

-

Checking if arg0 is not zero makes sure that - profiling happens when the program is in the kernel context.

-

Refer to - https://www.brendangregg.com/flamegraphs.html - to learn about generating flame graphs from the obtained stack traces.

-
-
-
-

-

dtrace(1), tracing(7)

-

The illumos Dynamic Tracing - Guide, - https://www.illumos.org/books/dtrace/chp-profile.html, - 2008, Chapter profile - Provider.

-

Brendan Gregg and - Jim Mauro, DTrace: Dynamic Tracing - in Oracle Solaris, Mac OS X and FreeBSD, Prentice - Hall, - https://www.brendangregg.com/dtracebook/, - pp. 24–25, - 2011.

-
-
-

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
July 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_sched.4 3.html b/static/freebsd/man4/dtrace_sched.4 3.html deleted file mode 100644 index 91922212..00000000 --- a/static/freebsd/man4/dtrace_sched.4 3.html +++ /dev/null @@ -1,206 +0,0 @@ - - - - - - -
DTRACE_SCHED(4)Device Drivers ManualDTRACE_SCHED(4)
-
-
-

-

dtrace_sched — a - DTrace provider for tracing CPU scheduling events

-
-
-

-

sched:::change-pri(struct - thread *, struct proc - *, uint8_t);

-

sched:::dequeue(struct - thread *, struct proc - *, void *);

-

sched:::enqueue(struct - thread *, struct proc - *, void *, - int);

-

sched:::lend-pri(struct - thread *, struct proc - *, uint8_t, - struct thread *);

-

sched:::load-change(int, - int);

-

sched:::off-cpu(struct - thread *, struct proc - *);

-

sched:::on-cpu();

-

sched:::preempt();

-

sched:::remain-cpu();

-

sched:::surrender(struct - thread *, struct proc - *);

-

sched:::sleep();

-

sched:::tick(struct - thread *, struct proc - *);

-

sched:::wakeup(struct - thread *, struct proc - *);

-
-
-

-

The DTrace sched provider allows the - tracing of events related to CPU scheduling in the 4BSD and ULE - schedulers.

-

The - () - probe fires when a thread's active scheduling priority is about to be - updated. The first two arguments are the thread whose priority is about to - be changed, and the corresponding process. The third argument is the new - absolute priority for the thread, while the current value is given by - args[0]->td_priority. The - () - probe fires when the currently-running thread elevates the priority of - another thread via priority lending. The first two arguments are the thread - whose priority is about to be changed, and the corresponding process. The - third argument is the new absolute priority for the thread. The fourth - argument is the currently-running thread.

-

The - () - probe fires immediately before a runnable thread is removed from a scheduler - run queue. This may occur when the thread is about to begin execution on a - CPU, or because the thread is being migrated to a different run queue. The - latter event may occur in several circumstances: the scheduler may be - attempting to rebalance load between multiple CPUs, the thread's scheduling - priority may have changed, or the thread's CPU affinity settings may have - changed. The first two arguments to - sched:::dequeue() are the thread and corresponding - process. The third argument is currently always - NULL. The - () - probe fires when a runnable thread is about to be added to a scheduler run - queue. Its first two arguments are the thread and corresponding process. The - third argument is currently always NULL. The fourth - argument is a boolean value that is non-zero if the thread is enqueued at - the beginning of its run queue slot, and zero if the thread is instead - enqueued at the end.

-

The - () - probe fires after the load of a thread queue is adjusted. The first argument - is the cpuid for the CPU associated with the thread queue, and the second - argument is the adjusted load of the thread queue, i.e., the number of - elements in the queue.

-

The - () - probe is triggered by the scheduler suspending execution of the - currently-running thread, and the - () - probe fires when the current thread has been selected to run on a CPU and is - about to begin or resume execution. The arguments to - sched:::off-cpu() are the thread and corresponding - process selected to run following the currently-running thread. If these two - threads are the same, the sched:::remain-cpu() probe - will fire instead.

-

The - () - probe fires when the scheduler is called upon to make a scheduling decision - by a thread running on a different CPU, via an interprocessor interrupt. The - arguments to this probe are the interrupted thread and its corresponding - process. This probe currently always fires in the context of the interrupted - thread.

-

The - () - probe will fire immediately before the currently-running thread is - preempted. When this occurs, the scheduler will select a new thread to run, - and one of the sched:::off-cpu() or - () - probes will subsequently fire, depending on whether or not the scheduler - selects the preempted thread.

-

The - () - probe fires immediately before the currently-running thread is about to - suspend execution and begin waiting for a condition to be met. The - () - probe fires when a thread is set up to resume execution after having gone to - sleep. Its arguments are the thread being awoken, and the corresponding - process.

-

The - () - fires before each scheduler clock tick. Its arguments are the - currently-running thread and its corresponding process.

-
-
-

-

The sched provider probes use the kernel - types struct proc and struct - thread to represent processes and threads, respectively. These - structures have many fields and are defined in - sys/proc.h. In a probe body, the currently-running - thread can always be obtained with the curthread - global variable, which has type struct thread *. For - example, when a running thread is about to sleep, the - sched:::sleep() probe fires in the context of that - thread, which can be accessed using curthread. The - curcpu global variable contains the cpuid of the CPU - on which the currently-running thread is executing.

-
-
-

-

The following script gives a breakdown of CPU utilization by - process name:

-
-
sched:::on-cpu
-{
-        self->ts = timestamp;
-}
-
-sched:::off-cpu
-/self->ts != 0/
-{
-        @[execname] = sum((timestamp - self->ts) / 1000);
-        self->ts = 0;
-}
-
-

Here, DTrace stores a timestamp each time a thread is scheduled to - run, and computes the time elapsed in microseconds when it is descheduled. - The results are summed by process name.

-
-
-

-

This provider is not compatible with the - sched provider found in Solaris. In particular, the - probe argument types are native FreeBSD types, and - the sched:::cpucaps-sleep(), - sched:::cpucaps-wakeup(), - sched:::schedctl-nopreempt(), - sched:::schedctl-preempt(), and - sched:::schedctl-yield() probes are not available in - FreeBSD.

-

The sched:::lend-pri() and - sched:::load-change() probes are specific to - FreeBSD.

-
-
-

-

dtrace(1), sched_4bsd(4), - sched_ule(4), SDT(9), - sleepqueue(9)

-
-
-

-

The sched provider first appeared in - FreeBSD 8.4 and 9.1.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org>.

-
-
- - - - - -
April 18, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_sctp.4 3.html b/static/freebsd/man4/dtrace_sctp.4 3.html deleted file mode 100644 index 6cf33abc..00000000 --- a/static/freebsd/man4/dtrace_sctp.4 3.html +++ /dev/null @@ -1,247 +0,0 @@ - - - - - - -
DTRACE_SCTP(4)Device Drivers ManualDTRACE_SCTP(4)
-
-
-

-

dtrace_sctp — a - DTrace provider for tracing events related to the sctp(4) - protocol

-
-
-

-

sctp:cwnd::init(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:cwnd::ack(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:cwnd::rttvar(uint64_t, - uint64_t, - uint64_t, - uint64_t, - uint64_t);

-

sctp:cwnd::rttstep(uint64_t, - uint64_t, - uint64_t, - uint64_t, - uint64_t);

-

sctp:cwnd::fr(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:cwnd::to(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:cwnd::bl(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:cwnd::ecn(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:cwnd::pd(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:rwnd:assoc:val(uint32_t, - uint32_t, - int, - int);

-

sctp:flightsize:net:val(uint32_t, - uint32_t, - uintptr_t, - int, - int);

-

sctp:flightsize:assoc:val(uint32_t, - uint32_t, - int, - int);

-

sctp:::receive(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - sctpsinfo_t *, - sctpinfo_t *);

-

sctp:::send(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - sctpsinfo_t *, - sctpinfo_t *);

-

sctp:::state-change(void - *, csinfo_t *, - void *, - sctpsinfo_t *, - void *, - sctplsinfo_t *);

-
-
-

-

The DTrace sctp provider allows users to - trace events in the sctp(4) protocol implementation. This - provider is similar to the dtrace_ip(4) and - dtrace_udp(4) providers, but additionally contains probes - corresponding to protocol events at a level higher than packet reception and - transmission.

-

The - () - probes track changes in the congestion window on a netp. The - () - probes track changes in the receiver window for an assoc. The - () - probe tracks changes in the flight size on a net or assoc and the - () - probe provides the total flight version.

-

The arguments of all - sctp probes except for - () - and - () - are the Vtag for this end, the port number of the local side, the pointer to - struct sctp_nets *changing, the old value of the - cwnd, and the new value of the cwnd.

-

The arguments of - () - are similar to the above except the fourth argument is the up/down - amount.

-

The - () - probe arguments are a bitmap of Vtag << 32 | - localport << 16 | - remoteport, a bitmap of obw - | nbw, a bitmap of bwrtt | - newrtt, flight, and a bitmap - of (cwnd << 32) | point - << 16 | retval(0/1).

-

The - () - probe fires when a remotely-initiated active SCTP open succeeds. At this - point the new connection is in the ESTABLISHED state, and the probe - arguments expose the headers associated with the final ACK of the four-way - handshake.

-

The - () - and - () - probes fire when the host sends or receives an SCTP packet, respectively. As - with the dtrace_udp(4) provider, - sctp probes fire only for packets sent by or to the - local host; forwarded packets are handled in the IP layer and are only - visible to the dtrace_ip(4) provider.

-

The - () - probe fires upon local SCTP association state transitions. Its first, third - and fifth arguments are currently always NULL. Its - last argument describes the from-state in the transition, and the to-state - can be obtained from args[3]->sctps_state.

-
-
-

-
-
/usr/lib/dtrace/sctp.d
-
DTrace type and translator definitions for the - sctp provider.
-
-
-
-

-

A script that logs SCTP packets in real time:

-
-
#pragma D option quiet
-#pragma D option switchrate=10hz
-
-dtrace:::BEGIN
-{
-        printf(" %3s %15s:%-5s      %15s:%-5s\n", "CPU",
-            "LADDR", "LPORT", "RADDR", "RPORT");
-}
-
-sctp:::send
-{
-        printf(" %3d %16s:%-5d -> %16s:%-5d\n", cpu,
-            args[2]->ip_saddr, args[4]->sctp_sport,
-            args[2]->ip_daddr, args[4]->sctp_dport);
-}
-
-sctp:::receive
-{
-        printf(" %3d %16s:%-5d <- %16s:%-5d\n", cpu,
-            args[2]->ip_daddr, args[4]->sctp_dport,
-            args[2]->ip_saddr, args[4]->sctp_sport);
-}
-
-A script that logs SCTP association state changes as they occur: -
-
#pragma D option quiet
-#pragma D option switchrate=10
-
-int last[int];
-
-dtrace:::BEGIN
-{
-        printf(" %3s %12s  %-25s    %-25s\n",
-            "CPU", "DELTA(us)", "OLD", "NEW");
-}
-
-sctp:::state-change
-/ last[args[1]->cs_cid] /
-{
-        this->elapsed = (timestamp - last[args[1]->cs_cid]) / 1000;
-        printf(" %3d %12d  %-25s -> %-25s\n", cpu, this->elapsed,
-            sctp_state_string[args[5]->sctps_state],
-            sctp_state_string[args[3]->sctps_state]);
-        last[args[1]->cs_cid] = timestamp;
-}
-
-sctp:::state-change
-/ last[args[1]->cs_cid] == 0 /
-{
-        printf(" %3d %12s  %-25s -> %-25s\n", cpu, "-",
-            sctp_state_string[args[5]->sctps_state],
-            sctp_state_string[args[3]->sctps_state]);
-        last[args[1]->cs_cid] = timestamp;
-}
-
-
-
-

-

The sctp:::send(), - sctp:::receive(), and - sctp:::state-change() probes are compatible with the - sctp provider in Solaris. All other probes are only - available in FreeBSD.

-
-
-

-

dtrace(1), dtrace_ip(4), - dtrace_udp(4), dtrace_udplite(4), - sctp(4), SDT(9)

-
-
-

-

This manual page was written by Devin - Teske - <dteske@FreeBSD.org>.

-
-
- - - - - -
June 29, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_tcp.4 3.html b/static/freebsd/man4/dtrace_tcp.4 3.html deleted file mode 100644 index ce201c10..00000000 --- a/static/freebsd/man4/dtrace_tcp.4 3.html +++ /dev/null @@ -1,482 +0,0 @@ - - - - - - -
DTRACE_TCP(4)Device Drivers ManualDTRACE_TCP(4)
-
-
-

-

dtrace_tcp — a - DTrace provider for tracing events related to the tcp(4) - protocol

-
-
-

-

tcp:::accept-established(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::accept-refused(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::connect-established(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::connect-refused(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::connect-request(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::receive(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::send(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - tcpsinfo_t *, - tcpinfo_t *);

-

tcp:::state-change(void - *, csinfo_t *, - void *, - tcpsinfo_t *, - void *, - tcplsinfo_t *);

-

tcp:::siftr(siftrinfo_t - *);

-
-
-

-

The DTrace tcp provider allows users to - trace events in the tcp(4) protocol implementation. This - provider is similar to the dtrace_ip(4) and - dtrace_udp(4) providers, but additionally contains probes - corresponding to protocol events at a level higher than packet reception and - transmission. All tcp probes except for - () - and tcp:::siftr() have the same number and type of - arguments. The last three arguments are used to describe a TCP segment: the - ipinfo_t argument exposes the version-agnostic fields - of the IP header, while the tcpinfo_t argument exposes - the TCP header, and the tcpsinfo_t argument describes - details of the corresponding TCP connection state, if any. Their fields are - described in the ARGUMENTS section.

-

The - () - probe fires when a remotely-initiated active TCP open succeeds. At this - point the new connection is in the ESTABLISHED state, and the probe - arguments expose the headers associated with the final ACK of the three-way - handshake. The tcp:::accept-refused() probe fires - when a SYN arrives on a port without a listening socket. The probe arguments - expose the headers associated with the RST to be transmitted to the remote - host in response to the SYN segment.

-

The - (), - (), - and - () - probes are similar to the ‘accept’ - probes, except that they correspond to locally-initiated TCP connections. - The tcp:::connect-established() probe fires when the - SYN-ACK segment of a three-way handshake is received from the remote host - and a final ACK is prepared for transmission. This occurs immediately after - the local connection state transitions from SYN-SENT to ESTABLISHED. The - probe arguments describe the headers associated with the received SYN-ACK - segment. The tcp:::connect-refused() probe fires - when the local host receives a RST segment in response to a SYN segment, - indicating that the remote host refused to open a connection. The probe - arguments describe the IP and TCP headers associated with the received RST - segment. The tcp:::connect-request() probe fires as - the kernel prepares to transmit the initial SYN segment of a three-way - handshake.

-

The - () - and - () - probes fire when the host sends or receives a TCP packet, respectively. As - with the dtrace_udp(4) provider, - tcp probes fire only for packets sent by or to the - local host; forwarded packets are handled in the IP layer and are only - visible to the dtrace_ip(4) provider.

-

The - () - probe fires upon local TCP connection state transitions. Its first, third - and fifth arguments are currently always NULL. Its - last argument describes the from-state in the transition, and the to-state - can be obtained from args[3]->tcps_state.

-

The - () - probe fires when a TCP segment is sent or received by the host. For a - detailed description see siftr(4). The - siftrinfo_t argument provides the information about - the TCP connection.

-
-
-

-

The pktinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uinptr_t pkt_addr
-
Always set to 0.
-
-
-

The csinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t cs_addr
-
Always set to 0.
-
uint64_t cs_cid
-
A pointer to the struct inpcb for this packet, or - NULL.
-
pid_t cs_pid
-
Always set to 0.
-
-
-

The ipinfo_t type is a version-agnostic - representation of fields from an IP header. Its fields are described in the - dtrace_ip(4) manual page.

-

The tcpsinfo_t - type is used to provide a stable representation of TCP connection state. - Some tcp probes, such as - (), - fire in a context where there is no TCP connection; this argument is - NULL in that case. Its fields are:

-
-
-
uintptr_t tcps_addr
-
The address of the corresponding TCP control block. This is currently a - pointer to a struct tcpcb.
-
int tcps_local
-
A boolean indicating whether the connection is local to the host. - Currently unimplemented and always set to -1.
-
int tcps_active
-
A boolean indicating whether the connection was initiated by the local - host. Currently unimplemented and always set to -1.
-
uint16_t tcps_lport
-
Local TCP port.
-
uint16_t tcps_rport
-
Remote TCP port.
-
string tcps_laddr
-
Local address.
-
string tcps_raddr
-
Remote address.
-
int32_t tcps_state
-
Current TCP state. The valid TCP state values are given by the constants - prefixed with ‘TCPS_’ in - /usr/lib/dtrace/tcp.d.
-
uint32_t tcps_iss
-
Initial send sequence number.
-
uint32_t tcps_suna
-
Initial sequence number of sent but unacknowledged data.
-
uint32_t tcps_snxt
-
Next sequence number for send.
-
uint32_t tcps_rack
-
Sequence number of received and acknowledged data.
-
uint32_t tcps_rnxt
-
Next expected sequence number for receive.
-
u_long tcps_swnd
-
TCP send window size.
-
int32_t tcps_snd_ws
-
Window scaling factor for the TCP send window.
-
u_long tcps_rwnd
-
TCP receive window size.
-
int32_t tcps_rcv_ws
-
Window scaling factor for the TCP receive window.
-
u_long tcps_cwnd
-
TCP congestion window size.
-
u_long tcps_cwnd_ssthresh
-
Congestion window threshold at which slow start ends and congestion - avoidance begins.
-
uint32_t tcps_sack_fack
-
Last sequence number selectively acknowledged by the receiver.
-
uint32_t tcps_sack_snxt
-
Next selectively acknowledge sequence number at which to begin - retransmitting.
-
uint32_t tcps_rto
-
Round-trip timeout, in milliseconds.
-
uint32_t tcps_mss
-
Maximum segment size.
-
int tcps_retransmit
-
A boolean indicating that the local sender is retransmitting data.
-
int tcps_srtt
-
Smoothed round-trip time.
-
-
-

The tcpinfo_t type exposes the fields in a - TCP segment header in host order. Its fields are:

-
-
-
uint16_t tcp_sport
-
Source TCP port.
-
uint16_t tcp_dport
-
Destination TCP port.
-
uint32_t tcp_seq
-
Sequence number.
-
uint32_t tcp_ack
-
Acknowledgement number.
-
uint8_t tcp_offset
-
Data offset, in bytes.
-
uint8_t tcp_flags
-
TCP flags.
-
uint16_t tcp_window
-
TCP window size.
-
uint16_t tcp_checksum
-
Checksum.
-
uint16_t tcp_urgent
-
Urgent data pointer.
-
struct tcphdr *tcp_hdr
-
A pointer to the raw TCP header.
-
-
-

The tcplsinfo_t - type is used by the - () - probe to provide the from-state of a transition. Its fields are:

-
-
-
int32_t tcps_state
-
A TCP state. The valid TCP state values are given by the constants - prefixed with ‘TCPS_’ in - /usr/lib/dtrace/tcp.d.
-
-
-

The siftrinfo_t type is - used by the - () - probe to provide the state of the TCP connection. Its fields are:

-
-
-
uint8_t direction
-
Direction of packet that triggered the log message. Either "0" - for in, or "1" for out.
-
uint8_t ipver
-
The version of the IP protocol being used. Either "1" for IPv4, - or "2" for IPv6.
-
uint16_t lport
-
The TCP port that the local host is communicating via.
-
uint16_t rport
-
The TCP port that the remote host is communicating via.
-
string laddr
-
The IPv4 or IPv6 address of the local host.
-
string raddr
-
The IPv4 or IPv6 address of the remote host.
-
uint32_t snd_cwnd
-
The current congestion window (CWND) for the flow, in bytes.
-
uint32_t snd_wnd
-
The current sending window for the flow, in bytes. The post scaled value - is reported, except during the initial handshake (first few packets), - during which time the unscaled value is reported.
-
uint32_t rcv_wnd
-
The current receive window for the flow, in bytes. The post scaled value - is always reported.
-
uint32_t t_flags2
-
The current value of the t_flags2 for the flow.
-
uint32_t snd_ssthresh
-
The slow start threshold (SSTHRESH) for the flow, in bytes.
-
int conn_state
-
A TCP state. The valid TCP state values are given by the constants - prefixed with ‘TCPS_’ in - /usr/lib/dtrace/tcp.d.
-
uint32_t mss
-
The maximum segment size (MSS) for the flow, in bytes.
-
uint32_t srtt
-
The current smoothed RTT (SRTT) for the flow in microseconds.
-
u_char sack_enabled
-
SACK enabled indicator. 1 if SACK enabled, 0 otherwise.
-
u_char snd_scale
-
The current window scaling factor for the sending window.
-
u_char rcv_scale
-
The current window scaling factor for the receiving window.
-
u_int t_flags
-
The current value of the t_flags for the flow.
-
uint32_t rto
-
The current retransmission timeout (RTO) for the flow in microseconds. - Divide by HZ to get the timeout length in seconds.
-
u_int snd_buf_hiwater
-
The current size of the socket send buffer in bytes.
-
u_int snd_buf_cc
-
The current number of bytes in the socket send buffer.
-
u_int rcv_buf_hiwater
-
The current size of the socket receive buffer in bytes.
-
u_int rcv_buf_cc
-
The current number of bytes in the socket receive buffer.
-
u_int sent_inflight_bytes
-
The current number of unacknowledged bytes in-flight. Bytes acknowledged - via SACK are not excluded from this count.
-
int t_segqlen
-
The current number of segments in the reassembly queue.
-
u_int flowid
-
Flowid for the connection. A caveat: Zero '0' either represents a valid - flowid or a default value when the flowid is not being set.
-
u_int flowtype
-
Flow type for the connection. Flowtype defines which protocol fields are - hashed to produce the flowid. A complete listing is available in - /usr/include/sys/mbuf.h under - M_HASHTYPE_*.
-
-
-
-
-

-
-
/usr/lib/dtrace/tcp.d
-
DTrace type and translator definitions for all the probes of the - tcp provider except the - siftr probe.
-
/usr/lib/dtrace/siftr.d
-
DTrace type and translator definitions for the - siftr probe of the tcp - provider.
-
-
-
-

-

The following script logs TCP segments in real time:

-
-
#pragma D option quiet
-#pragma D option switchrate=10hz
-
-dtrace:::BEGIN
-{
-        printf(" %3s %15s:%-5s      %15s:%-5s %6s  %s\n", "CPU",
-            "LADDR", "LPORT", "RADDR", "RPORT", "BYTES", "FLAGS");
-}
-
-tcp:::send
-{
-        this->length = args[2]->ip_plength - args[4]->tcp_offset;
-        printf(" %3d %16s:%-5d -> %16s:%-5d %6d  (", cpu, args[2]->ip_saddr,
-            args[4]->tcp_sport, args[2]->ip_daddr, args[4]->tcp_dport,
-            this->length);
-        printf("%s", args[4]->tcp_flags & TH_FIN ? "FIN|" : "");
-        printf("%s", args[4]->tcp_flags & TH_SYN ? "SYN|" : "");
-        printf("%s", args[4]->tcp_flags & TH_RST ? "RST|" : "");
-        printf("%s", args[4]->tcp_flags & TH_PUSH ? "PUSH|" : "");
-        printf("%s", args[4]->tcp_flags & TH_ACK ? "ACK|" : "");
-        printf("%s", args[4]->tcp_flags & TH_URG ? "URG|" : "");
-        printf("%s", args[4]->tcp_flags == 0 ? "null " : "");
-        printf("\b)\n");
-}
-
-tcp:::receive
-{
-        this->length = args[2]->ip_plength - args[4]->tcp_offset;
-        printf(" %3d %16s:%-5d <- %16s:%-5d %6d  (", cpu,
-            args[2]->ip_daddr, args[4]->tcp_dport, args[2]->ip_saddr,
-            args[4]->tcp_sport, this->length);
-        printf("%s", args[4]->tcp_flags & TH_FIN ? "FIN|" : "");
-        printf("%s", args[4]->tcp_flags & TH_SYN ? "SYN|" : "");
-        printf("%s", args[4]->tcp_flags & TH_RST ? "RST|" : "");
-        printf("%s", args[4]->tcp_flags & TH_PUSH ? "PUSH|" : "");
-        printf("%s", args[4]->tcp_flags & TH_ACK ? "ACK|" : "");
-        printf("%s", args[4]->tcp_flags & TH_URG ? "URG|" : "");
-        printf("%s", args[4]->tcp_flags == 0 ? "null " : "");
-        printf("\b)\n");
-}
-
-The following script logs TCP connection state changes as they occur: -
-
#pragma D option quiet
-#pragma D option switchrate=25hz
-
-int last[int];
-
-dtrace:::BEGIN
-{
-        printf("   %12s %-20s    %-20s %s\n",
-            "DELTA(us)", "OLD", "NEW", "TIMESTAMP");
-}
-
-tcp:::state-change
-{
-        this->elapsed = (timestamp - last[args[1]->cs_cid]) / 1000;
-        printf("   %12d %-20s -> %-20s %d\n", this->elapsed,
-            tcp_state_string[args[5]->tcps_state],
-            tcp_state_string[args[3]->tcps_state], timestamp);
-        last[args[1]->cs_cid] = timestamp;
-}
-
-tcp:::state-change
-/last[args[1]->cs_cid] == 0/
-{
-        printf("   %12s %-20s -> %-20s %d\n", "-",
-            tcp_state_string[args[5]->tcps_state],
-            tcp_state_string[args[3]->tcps_state], timestamp);
-        last[args[1]->cs_cid] = timestamp;
-}
-
-The following script uses the siftr probe to show the current value of CWND and - SSTHRESH when a packet is sent or received: -
-
#pragma D option quiet
-#pragma D option switchrate=10hz
-
-dtrace:::BEGIN
-{
-        printf(" %3s %16s:%-5s %16s:%-5s %10s %10s\n",
-            "DIR", "LADDR", "LPORT", "RADDR", "RPORT", "CWND", "SSTHRESH");
-}
-
-tcp:::siftr
-{
-        printf(" %3s %16s:%-5d %16s:%-5d %10u %10u\n",
-            siftr_dir_string[args[0]->direction],
-            args[0]->laddr, args[0]->lport, args[0]->raddr, args[0]->rport,
-            args[0]->snd_cwnd, args[0]->snd_ssthresh);
-}
-
-
-
-

-

This provider is compatible with the tcp - provider in Solaris.

-
-
-

-

dtrace(1), dtrace_ip(4), - dtrace_sctp(4), dtrace_udp(4), - dtrace_udplite(4), siftr(4), - tcp(4), SDT(9)

-
-
-

-

The tcp provider first appeared in - FreeBSD 10.0.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org>.

-
-
-

-

The tcps_local and - tcps_active fields of tcpsinfo_t - are not filled in by the translator.

-
-
- - - - - -
July 2, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_udp.4 3.html b/static/freebsd/man4/dtrace_udp.4 3.html deleted file mode 100644 index 64baf51e..00000000 --- a/static/freebsd/man4/dtrace_udp.4 3.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - -
DTRACE_UDP(4)Device Drivers ManualDTRACE_UDP(4)
-
-
-

-

dtrace_udp — a - DTrace provider for tracing events related to the UDP protocol

-
-
-

-

udp:::receive(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - udpsinfo_t *, - udpinfo_t *);

-

udp:::send(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - udpsinfo_t *, - udpinfo_t *);

-
-
-

-

The DTrace udp provider allows users to - trace events in the udp(4) protocol implementation. The - () - probe fires whenever the kernel prepares to transmit a UDP packet, and the - () - probe fires whenever the kernel receives a UDP packet, unless the UDP header - is incomplete, the destination port is 0, the length field is invalid, or - the checksum is wrong. The arguments to these probes can be used to obtain - detailed information about the IP and UDP headers of the corresponding - packet.

-
-
-

-

The pktinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t pkt_addr
-
Always set to 0.
-
-
-

The csinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t cs_addr
-
Always set to 0.
-
uint64_t cs_cid
-
A pointer to the struct inpcb for this packet, or - NULL.
-
pid_t cs_pid
-
Always set to 0.
-
-
-

The ipinfo_t argument contains IP fields - common to both IPv4 and IPv6 packets. Its fields are:

-
-
-
uint8_t ip_ver
-
IP version of the packet, 4 for IPv4 packets and 6 for IPv6 packets.
-
uint32_t ip_plength
-
IP payload size. This does not include the size of the IP header or IPv6 - option headers.
-
string ip_saddr
-
IP source address.
-
string ip_daddr
-
IP destination address.
-
-
-

The udpsinfo_t argument contains the state - of the UDP connection associated with the packet. Its fields are:

-
-
-
uintptr_t udps_addr
-
Pointer to the struct inpcb containing the IP state - for the associated socket.
-
uint16_t udps_lport
-
Local UDP port.
-
uint16_t udps_rport
-
Remote UDP port.
-
string udps_laddr
-
Local IPv4 or IPv6 address.
-
string udps_raddr
-
Remote IPv4 or IPv6 address.
-
-
-

The udpinfo_t argument is the raw UDP header - of the packet, with all fields in host order. Its fields are:

-
-
-
uint16_t udp_sport
-
Source UDP port.
-
uint16_t udp_dport
-
Destination UDP port.
-
uint16_t udp_length
-
Length of the UDP header and payload, in bytes.
-
uint16_t udp_checksum
-
A checksum of the UDP header and payload, or 0 if no checksum was - calculated.
-
struct udphdr *udp_hdr
-
A pointer to the raw UDP header.
-
-
-
-
-

-
-
/usr/lib/dtrace/udp.d
-
DTrace type and translator definitions for the udp - provider.
-
-
-
-

-

The following script counts transmitted packets by destination - port.

-
-
udp:::send
-{
-        @num[args[4]->udp_dport] = count();
-}
-
-

This script will print some details of each UDP packet as it is - sent or received by the kernel:

-
-
#pragma D option quiet
-#pragma D option switchrate=10Hz
-
-dtrace:::BEGIN
-{
-        printf(" %10s %36s    %-36s %6s\n", "DELTA(us)", "SOURCE",
-            "DEST", "BYTES");
-        last = timestamp;
-}
-
-udp:::send
-{
-        this->elapsed = (timestamp - last) / 1000;
-        self->dest = strjoin(strjoin(args[2]->ip_daddr, ":"),
-             lltostr(args[4]->udp_dport));
-        printf(" %10d %30s:%-5d -> %-36s %6d\n", this->elapsed,
-            args[2]->ip_saddr, args[4]->udp_sport,
-            self->dest, args[4]->udp_length);
-        last = timestamp;
-}
-
-udp:::receive
-{
-        this->elapsed = (timestamp - last) / 1000;
-        self->dest = strjoin(strjoin(args[2]->ip_saddr, ":"),
-             lltostr(args[4]->udp_sport));
-        printf(" %10d %30s:%-5d <- %-36s %6d\n", this->elapsed,
-            args[2]->ip_daddr, args[4]->udp_dport,
-            self->dest, args[4]->udp_length);
-        last = timestamp;
-}
-
-
-
-

-

This provider is compatible with the udp - provider in Solaris.

-
-
-

-

dtrace(1), dtrace_ip(4), - dtrace_sctp(4), dtrace_tcp(4), - dtrace_udplite(4), udp(4), - SDT(9)

-
-
-

-

The udp provider first appeared in - FreeBSD 10.0.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org>.

-
-
- - - - - -
August 1, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_udplite.4 3.html b/static/freebsd/man4/dtrace_udplite.4 3.html deleted file mode 100644 index 77a6e5f8..00000000 --- a/static/freebsd/man4/dtrace_udplite.4 3.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - -
DTRACE_UDPLITE(4)Device Drivers ManualDTRACE_UDPLITE(4)
-
-
-

-

dtrace_udplite — a - DTrace provider for tracing events related to the UDP-Lite - protocol

-
-
-

-

udplite:::receive(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - udplitesinfo_t *, - udpliteinfo_t *);

-

udplite:::send(pktinfo_t - *, csinfo_t *, - ipinfo_t *, - udplitesinfo_t *, - udpliteinfo_t *);

-
-
-

-

The DTrace udplite provider allows users - to trace events in the udplite(4) protocol implementation. - The - () - probe fires whenever the kernel prepares to transmit a UDP-Lite packet, and - the - () - probe fires whenever the kernel receives a UDP-Lite packet, unless the - UDP-Lite header is incomplete, the destination port is 0, the length field - is invalid, or the checksum is wrong. The arguments to these probes can be - used to obtain detailed information about the IP and UDP-Lite headers of the - corresponding packet.

-
-
-

-

The pktinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t pkt_addr
-
Always set to 0.
-
-
-

The csinfo_t argument is currently - unimplemented and is included for compatibility with other implementations - of this provider. Its fields are:

-
-
-
uintptr_t cs_addr
-
Always set to 0.
-
uint64_t cs_cid
-
A pointer to the struct inpcb for this packet, or - NULL.
-
pid_t cs_pid
-
Always set to 0.
-
-
-

The ipinfo_t argument contains IP fields - common to both IPv4 and IPv6 packets. Its fields are:

-
-
-
uint8_t ip_ver
-
IP version of the packet, 4 for IPv4 packets and 6 for IPv6 packets.
-
uint32_t ip_plength
-
IP payload size. This does not include the size of the IP header or IPv6 - option headers.
-
string ip_saddr
-
IP source address.
-
string ip_daddr
-
IP destination address.
-
-
-

The udplitesinfo_t argument contains the - state of the UDP-Lite connection associated with the packet. Its fields - are:

-
-
-
uintptr_t udplites_addr
-
Pointer to the struct inpcb containing the IP state - for the associated socket.
-
uint16_t udplites_lport
-
Local UDP-Lite port.
-
uint16_t udplites_rport
-
Remote UDP-Lite port.
-
string udplites_laddr
-
Local IPv4 or IPv6 address.
-
string udplites_raddr
-
Remote IPv4 or IPv6 address.
-
-
-

The udpliteinfo_t argument is the raw - UDP-Lite header of the packet, with all fields in host order. Its fields - are:

-
-
-
uint16_t udplite_sport
-
Source UDP-Lite port.
-
uint16_t udplite_dport
-
Destination UDP-Lite port.
-
uint16_t udplite_coverage
-
Checksum coverage of the UDP-Lite header, in bytes, or 0 for full - coverage.
-
uint16_t udplite_checksum
-
A checksum of the UDP-Lite header and payload, or 0 if no checksum was - calculated.
-
struct udplitehdr *udplite_hdr
-
A pointer to the raw UDP-Lite header.
-
-
-
-
-

-
-
/usr/lib/dtrace/udplite.d
-
DTrace type and translator definitions for the - udplite provider.
-
-
-
-

-

The following script counts transmitted packets by destination - port.

-
-
udplite:::send
-{
-        @num[args[4]->udplite_dport] = count();
-}
-
-

This script will print some details of each UDP-Lite packet as it - is sent or received by the kernel:

-
-
#pragma D option quiet
-#pragma D option switchrate=10Hz
-
-dtrace:::BEGIN
-{
-        printf(" %10s %36s    %-36s %6s\n", "DELTA(us)", "SOURCE",
-            "DEST", "COV");
-        last = timestamp;
-}
-
-udplite:::send
-{
-        this->elapsed = (timestamp - last) / 1000;
-        self->dest = strjoin(strjoin(args[2]->ip_daddr, ":"),
-             lltostr(args[4]->udplite_dport));
-        printf(" %10d %30s:%-5d -> %-36s %6d\n", this->elapsed,
-            args[2]->ip_saddr, args[4]->udplite_sport,
-            self->dest, args[4]->udplite_coverage);
-        last = timestamp;
-}
-
-udplite:::receive
-{
-        this->elapsed = (timestamp - last) / 1000;
-        self->dest = strjoin(strjoin(args[2]->ip_saddr, ":"),
-             lltostr(args[4]->udplite_sport));
-        printf(" %10d %30s:%-5d <- %-36s %6d\n", this->elapsed,
-            args[2]->ip_daddr, args[4]->udplite_dport,
-            self->dest, args[4]->udplite_coverage);
-        last = timestamp;
-}
-
-
-
-

-

dtrace(1), dtrace_ip(4), - dtrace_sctp(4), dtrace_tcp(4), - dtrace_udp(4), udplite(4), - SDT(9)

-
-
-

-

The udplite provider first appeared in - FreeBSD 12.0.

-
-
-

-

This manual page was written by Mark - Johnston - <markj@FreeBSD.org> - and -
- Michael Tuexen - <tuexen@FreeBSD.org>.

-
-
- - - - - -
August 1, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/dtrace_vfs.4 3.html b/static/freebsd/man4/dtrace_vfs.4 3.html deleted file mode 100644 index 9937b55f..00000000 --- a/static/freebsd/man4/dtrace_vfs.4 3.html +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - -
DTRACE_VFS(4)Device Drivers ManualDTRACE_VFS(4)
-
-
-

-

dtrace_vfs — a - DTrace provider for Virtual File System

-
-
-

- - - - - -
vfs:fplookup:function:name
-
- - - - - -
vfs:namecache:function:name
-
- - - - - -
vfs:namei:function:name
-
- - - - - -
vfs:vop:function:name
-
-
-

-

The DTrace vfs provider allows users to - trace events in the VFS(9) layer, the kernel interface for - file systems on FreeBSD.

-

Run ‘dtrace -l -P vfs’ to - list all vfs probes. Add -v - to generate program stability reports, which contain information about the - number of probe arguments and their types.

-

The fplookup - module defines a single probe, - (struct - nameidata *ndp, int line, bool - status_code), that instruments the fast path lookup code in - VFS(9).

-

The namecache module provides probes - related to the VFS(9) cache. Consult the source code in - src/sys/kern/vfs_cache.c for more details.

-

The namei module manages probes related to - pathname translation and lookup operations. Refer to - namei(9) to learn more.

-

The vop module contains probes related to - the functions responsible for vnode(9) operations.

-
-
-

-

This provider is specific to FreeBSD.

-
-
-

-

Check what lookups failed to be handled in a lockless manner:

-
-
# dtrace -n 'vfs:fplookup:lookup:done { @[arg1, arg2] = count(); }'
-
-
-
-

-

dtrace(1), d(7), - SDT(9), namei(9), - VFS(9)

-

Brendan Gregg and - Jim Mauro, DTrace: Dynamic Tracing - in Oracle Solaris, Mac OS X and FreeBSD, Prentice - Hall, - https://www.brendangregg.com/dtracebook/, - pp. 335–351, - 2011.

-
-
-

-

The FreeBSD vfs - provider was written by Robert Watson - <rwatson@FreeBSD.org>.

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
November 3, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dummymbuf.4 3.html b/static/freebsd/man4/dummymbuf.4 3.html deleted file mode 100644 index 0ac85716..00000000 --- a/static/freebsd/man4/dummymbuf.4 3.html +++ /dev/null @@ -1,182 +0,0 @@ - - - - - - -
DUMMYMBUF(4)Device Drivers ManualDUMMYMBUF(4)
-
-
-

-

dummymbuf — mbuf - alteration pfil hooks

-
-
-

-

To compile the driver into the kernel, place the following line in - the kernel configuration file:

-
device dummymbuf
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
dummymbuf_load="YES"
-
-
-
-

-

This module is intended to test networking code in the face of - unusual mbuf layouts. The special pfil(9) hooks are - provided for mbuf alteration and can be listed with - pfilctl(8) as follows:

-
-
            Hook                      Type
-       dummymbuf:ethernet         Ethernet
-       dummymbuf:inet6                IPv6
-       dummymbuf:inet                 IPv4
-
-

To activate a hook it must be linked to the respective - pfil(9) head. pfilctl(8) can be used for - the linking.

-

Each time a hook is invoked it reads a single shared set of - RULES from - net.dummymbuf.rules sysctl. The rules are evaluated - sequentially and each matching rule performs the specified operation over - the mbuf.

-

After every successfully applied operation the - net.dummymbuf.hits sysctl counter is increased.

-

A hook returns an altered mbuf for further processing, but it - drops a packet if rules parsing or an operation fails. Also, the first mbuf - of the original chain may be changed.

-

The module is VNET(9) based, hence every - jail(2) provides its own set of hooks and sysctl - variables.

-
-
-

-

The set of rules is a semicolon separated list. An empty string is - treated as a parsing failure. A rule conceptually has two parts, filter and - operation, with the following syntax:

-
-
{inet | inet6 | ethernet} {in | out} <ifname> <opname>[ <opargs>];
-
-
-

-

The first word of a rule matches pfil(9) type. - The second matches packet's direction, and the third matches the network - interface a packet is coming from.

-
-
-

-

An operation may have arguments separated from its name by space. - The available operations are:

-
-
pull-head <number-of-bytes>
-
Unconditionally creates a brand new cluster-based mbuf and links it to be - the first mbuf of the original mbuf chain, with respective packet header - moving. After, the given number of bytes are pulled from the original mbuf - chain. -

If it is asked to pull 0 bytes then the first mbuf of the - resulting chain will be left empty. Asking to pull more than - MCLBYTES is treated as an operation failure. If - a mbuf chain has less data than asked then the entire packet is pulled - with tail mbuf(s) left empty.

-

As a result, only the layout of a mbuf chain is altered, its - content logically is left intact.

-
-
enlarge <number-of-bytes>
-
Unconditionally replace the mbuf with an mbuf of the specified size.
-
-
-
-
-

-

The following variables are available:

-
-
net.dummymbuf.rules
-
A string representing a single set of - RULES shared among all - dummymbuf hooks.
-
net.dummymbuf.hits
-
Number of times a rule has been applied. It is reset to zero upon - writing.
-
-
-
-

-

As it was intended, dummymbuf can be found - useful for firewall testing. A mbuf chain could be altered before it hits a - firewall to test that the latter can handle a case respectively. Thus, it is - important to have correct sequence of hooks. A test case should prepare and - enable a firewall first to get its hooks linked. After, the - pfilctl(8) should be used to link - dummymbuf hook(s) to put them in front of a - firewall.

-

The following links dummymbuf:inet6 hook for - inbound and puts it in front of other hooks:

-
-
pfilctl link -i dummymbuf:inet6 inet6
-
-

And this does the same for outbound:

-
-
pfilctl link -o -a dummymbuf:inet6 inet6
-
-

For instance, we want to test a scenario in which the very first - mbuf in a chain has zero m_len, to verify that a firewall can correctly read - the packet data despite that. The following set of rules does it for inbound - and outbound:

-
-
sysctl net.dummymbuf.rules="inet6 in em0 pull-head 0; inet6 out em0 pull-head 0;"
-
-

It is encouraged to verify - net.dummymbuf.hits sysctl counter along with other - test assertions to make sure that dummymbuf really - does its work and there is no false positive due to misconfiguration. It is - a good idea to reset it before the action:

-
-
sysctl net.dummymbuf.hits=0
-
-

It is equally important to cleanup the things after the test - case:

-
-
pfilctl unlink -i dummymbuf:inet6 inet6
-pfilctl unlink -o dummymbuf:inet6 inet6
-sysctl net.dummymbuf.rules=""
-
-

If a test case operates within a temporary vnet then explicit - cleanup can be omitted, the dummymbuf facilities - will vanish along with its vnet instance.

-
-
-

-
-
dummymbuf: <filter match>: rule parsing failed: <the rule in - question>
-
If everything looks fine then extra spaces removal may help due to the - parser is kept very simple.
-
dummymbuf: <filter match>: mbuf operation failed: <the rule in - question>
-
Incorrect operation argument has been found, mbuf allocation has failed, - etc.
-
-
-
-

-

jail(2), pfilctl(8), - mbuf(9), pfil(9), - VNET(9)

-
-
-

-

The module and this manual page were written by - Igor Ostapenko - <pm@igoro.pro>.

-
-
- - - - - -
January 6, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/dummynet.4 3.html b/static/freebsd/man4/dummynet.4 3.html deleted file mode 100644 index 9bc4c22d..00000000 --- a/static/freebsd/man4/dummynet.4 3.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
DUMMYNET(4)Device Drivers ManualDUMMYNET(4)
-
-
-

-

dummynet — traffic - shaper, bandwidth manager and delay emulator

-
-
-

-

The dummynet system facility permits the - control of traffic going through the various network interfaces, by applying - bandwidth and queue size limitations, implementing different scheduling and - queue management policies, and emulating delays and losses.

-

The user interface for dummynet is - implemented by the dnctl(8) utility, so please refer to - the dnctl(8) manpage for a complete description of the - dummynet capabilities and how to use it.

-
-

-

The following options in the kernel configuration file are related - to dummynet operation:

-

-
-
-
-
enable ipfirewall (if dummynet is to be used with - ipfw)
-
-
enable firewall output
-
-
limit firewall output
-
-
enable dummynet operation
-
-
set the timer granularity
-
-
-

Generally, the following options are required:

-
-
options IPFIREWALL
-options DUMMYNET
-options HZ=1000		# strongly recommended
-
-

Additionally, one may want to increase the number of mbuf clusters - (used to store network packets) according to the sum of the bandwidth-delay - products and queue sizes of all configured pipes.

-
-
-
-

-

setsockopt(2), if_bridge(4), - ip(4), pf.conf(5), - dnctl(8), ipfw(8), - sysctl(8)

-
-
-

-

The dummynet facility was initially - implemented as a testing tool for TCP congestion control by - Luigi Rizzo - <luigi@iet.unipi.it>, - as described on ACM Computer Communication Review, Jan.97 issue. Later it - has been modified to work at the IP and bridging levels, integrated with the - ipfw(4) packet filter, and extended to support multiple - queueing and scheduling policies.

-
-
- - - - - -
September 10, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/e6000sw.4 3.html b/static/freebsd/man4/e6000sw.4 3.html deleted file mode 100644 index 83a43f51..00000000 --- a/static/freebsd/man4/e6000sw.4 3.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
E6000SW(4)Device Drivers ManualE6000SW(4)
-
-
-

-

e6000sw — Marvell - 88E6000 series Gigabit Ethernet switch driver

-
-
-

-

device mdio -
- etherswitch -
- e6000sw

-
-
-

-

The e6000sw driver supports Marvell - Gigabit Ethernet switch controllers.

-
-
-

-

The e6000sw driver supports the following - Gigabit Ethernet switch controllers:

-

-
    -
  • Marvell 88E6190X
    • -
  • Marvell 88E6190
    • -
  • Marvell 88E6176
    • -
  • Marvell 88E6172
    • -
  • Marvell 88E6171
    • -
  • Marvell 88E6341
    • -
  • Marvell 88E6141
    • -
-
-
-

-

e6060sw(4), etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The e6000sw driver appeared in - FreeBSD 11.0.

-
-
- - - - - -
April 16, 2026
diff --git a/static/freebsd/man4/e6060sw.4 3.html b/static/freebsd/man4/e6060sw.4 3.html deleted file mode 100644 index 0fceb14a..00000000 --- a/static/freebsd/man4/e6060sw.4 3.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
E6060SW(4)Device Drivers ManualE6060SW(4)
-
-
-

-

e6060sw — Marvell - 88E6060/88E6063/88E6065 Fast Ethernet switch driver

-
-
-

-

device mdio -
- device etherswitch -
- device e6060sw

-

-
- hint.e6060sw.0.at="mdio0"

-
-
-

-

The e6060sw device driver provides a - management interface to Marvell 88E6060 and 88E6065 fast ethernet switch - chip. This driver use smi interface by ethernet interface.

-

88E6060 support is only port vlan. 88E6065 support is port and - dot1q vlan. dot1q support group base tag/untag.

-
-
-

-

The e6060sw driver supports the following - Fast Ethernet switch controllers:

-

-
    -
  • Marvell 88E6060
    • -
  • Marvell 88E6063
    • -
  • Marvell 88E6065
    • -
-
-
-

-

Configure dot1q vlan on 88E6065 by etherswitchcfg command.

-

-
# etherswitchcfg config vlan_mode - dot1q
-

Configure vlangroup with dot1q tag on 88E6065. This example is - port0 as vlan 2.

-

-
# etherswitchcfg vlangroup2 vlan 2 - members 0,5t port0 pvid 2
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The e6060sw device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The e6060sw driver was written by - Hiroki Mori

-
-
- - - - - -
May 10, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/edsc.4 3.html b/static/freebsd/man4/edsc.4 3.html deleted file mode 100644 index 1cbbba44..00000000 --- a/static/freebsd/man4/edsc.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
EDSC(4)Device Drivers ManualEDSC(4)
-
-
-

-

edsc — Ethernet - discard network interface

-
-
-

-

device edsc

-
-
-

-

The edsc interface is a software discard - mechanism which may be used for performance analysis and software testing. - It imitates an Ethernet device, which allows for its use in conjunction with - such drivers as if_bridge(4) and - vlan(4).

-

As with other network interfaces, an edsc - interface must have network addresses assigned for each address family with - which it is to be used. These addresses may be set or changed with the - SIOCSIFADDR ioctl(2) or - ifconfig(8) utility.

-

Each edsc interface is created at runtime - using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5).

-
-
-

-

ioctl(2), arp(4), - if_bridge(4), inet(4), - intro(4), vlan(4), - rc.conf(5), arp(8), - ifconfig(8)

-
-
-

-

The edsc device was derived from the - disc(4) device and first appeared in - FreeBSD 6.3. This manpage was adapted from - disc(4).

-
-
-

-

Since outgoing packets are just discarded by - edsc, ARP requests stay unreplied. Consequently, an - IP packet cannot be sent via edsc until a static - arp(4) entry is created for its next hop using - arp(8).

-

Initially an edsc interface has a zero - link level address. It can be changed with ifconfig(8) - lladdr if needed.

-
-
- - - - - -
March 25, 2007FreeBSD 15.0
diff --git a/static/freebsd/man4/efidev.4 3.html b/static/freebsd/man4/efidev.4 3.html deleted file mode 100644 index 015c7084..00000000 --- a/static/freebsd/man4/efidev.4 3.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - -
EFIDEV(4)Device Drivers ManualEFIDEV(4)
-
-
-

-

efidev, efirtc - — user-mode access to UEFI runtime - services

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
options EFIRT
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
efirt_load="YES"
-
-

The driver may be disabled by setting the - loader(8) tunable efi.rt.disabled to - “1”.

-
-
-

-

The efidev device provides user-mode - access to UEFI runtime services. efidev also - includes a driver to provide a time-of-day clock using the UEFI real time - clock (RTC). However, the RTC may not always be available, based on the UEFI - firmware. If the RTC is not available, it will not be registered as a - time-of-day clock and the time related ioctls below will not be - functional.

-

efidev provides the following ioctls - defined in <sys/efiio.h> - with supplemental structures and constants defined in - <sys/efi.h>:

-
-
- (struct efi_get_table_ioc)
-
Copy the UEFI table specified by the uuid field of - the struct efi_get_table_ioc into the - buf field. The memory size for the buf field can be - queried by passing NULL pointer as a buf value. - The required size will be stored in the table_len - field. The size of the allocated memory must be specified in the - buf_len field. -
- 
struct efi_get_table_ioc {
-	void *buf;
-	struct uuid uuid;
-	size_t table_len;
-	size_t buf_len;
-};
-
-
-
- (struct efi_tm)
-
Get the time from the RTC, if the RTC is available. The - struct efi_tm passed is populated with the current - time, unless an error occurs. -
- 
struct efi_tm {
-	uint16_t	tm_year;
-	uint8_t		tm_mon
-	uint8_t		tm_mday
-	uint8_t		tm_hour;
-	uint8_t		tm_min;
-	uint8_t		tm_sec;
-	uint8_t		 __pad1;
-	uint32_t	tm_nsec;
-	int16_t		tm_tz;
-	uint8_t		tm_dst;
-	uint8_t		__pad2;
-};
-
-
-
- (struct efi_tm)
-
Sets the time stored by the RTC, if the RTC is available.
-
- (struct efi_var_ioc)
-
Gets data from the variable described by the vendor and name fields of the - struct efi_var_ioc into the - data field. EFIIOC_VAR_GET - (struct efi_var_ioc) will also populate the - attrib field. -
- 
struct efi_var_ioc {
-	efi_char	*name;
-	size_t		 namesize;
-	struct uuid	 vendor;
-	uint32_t	 attrib;
-	void		*data;
-	size_t		 datasize;
-};
-
-
-
- (struct efi_var_ioc)
-
Used for enumerating all UEFI variables. The initial call should use an - empty string for the name attribute. Subsequent calls should supply the - vendor uuid and name of the last variable returned.
-
- (struct efi_var_ioc)
-
Sets data and attributes for the variable described by the name and vendor - in the struct efi_var_ioc.
-
-
-
-

-
-
/dev/efi
-
 
-
-
-
-

-

efivar(3), efirt(9)

-
-
-

-

A efidev device first appeared in - FreeBSD 11.1.

-
-
-

-

efidev is currently only available on - amd64 and arm64.

-
-
- - - - - -
June 18, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ehci.4 3.html b/static/freebsd/man4/ehci.4 3.html deleted file mode 100644 index b89ae9d7..00000000 --- a/static/freebsd/man4/ehci.4 3.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
EHCI(4)Device Drivers ManualEHCI(4)
-
-
-

-

ehci — USB - Enhanced Host Controller driver

-
-
-

-

device ehci

-
-
-

-

The ehci driver provides support for the - USB Enhanced Host Controller Interface, which is used by USB 2.0 - controllers.

-

EHCI controllers are peculiar in that they can only handle the USB - 2.0 protocol. This means that they normally have one or more companion - controllers (i.e., ohci(4) or uhci(4)) - handling USB 1.x devices. Consequently each USB connector is electrically - connected to two USB controllers. The handling of this is totally automatic, - but can be noticed since USB 1.x and USB 2.0 devices plugged in to the same - connector appear to connect to different USB buses.

-
-
-

-

When the kernel has been compiled with options - USB_DEBUG, some tunables become available that affect the behavior of - ehci. These tunables can be set at the - loader(8) prompt before booting the kernel or stored in - loader.conf(5).

-
-
hw.usb.ehci.lostintrbug
-
This tunable enables the lost interrupt quirk. The default value is 0 - (off).
-
hw.usb.ehci.iaadbug
-
This tunable enables the EHCI doorbell quirk. The default value is 0 - (off).
-
hw.usb.ehci.no_hs
-
This tunable disables USB devices to attach like HIGH-speed ones and will - force all attached devices to attach to the FULL- or LOW-speed companion - controller. The default value is 0 (off).
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.ehci.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

ohci(4), uhci(4), - usb(4), xhci(4)

-
-
-

-

The ehci device driver first appeared in - FreeBSD 5.1.

-
-
- - - - - -
April 24, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/em.4 3.html b/static/freebsd/man4/em.4 3.html deleted file mode 100644 index 028ade0a..00000000 --- a/static/freebsd/man4/em.4 3.html +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - -
EM(4)Device Drivers ManualEM(4)
-
-
-

-

em, lem, - igb — Intel(R) PRO/1000 - Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device em
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_em_load="YES"
-
-
-
-

-

The em driver provides support for - PCI/PCI-X Gigabit Ethernet adapters based on the Intel 82540, 82541ER, - 82541PI, 82542, 82543, 82544, 82545, 82546, 82546EB, 82546GB, and 82547 - controller chips.

-

The em driver provides support for PCI - Express Gigabit Ethernet adapters based on the Intel 82571, 82572, 82573, - 82574, and 82583 Ethernet controller chips.

-

The em driver provides support for Gigabit - Ethernet adapters connected to I/O Controller Hub (ICH) and Platform - Controller Hub (PCH) including Intel 80003ES2LAN, 82562, 82566, 82567, - 82577, 82578, 82579, i217, i218, and i219.

-

The em driver provides support for PCI - Express Gigabit Ethernet adapters based on the Intel 82575, 82576, 82580, - i210, i211, and i35x. These appear as igb interfaces - to maintain compatibility with existing infrastructure.

-

The driver supports Transmit/Receive checksum offload and Jumbo - Frames on all but 82542-based adapters.

-

Furthermore it supports TCP segmentation offload (TSO) on all - adapters but those based on the 82542, 82543, 82544 and 82547 controller - chips. The identification LEDs of the adapters supported by the - em driver can be controlled via the - led(4) API for localization purposes. For further hardware - information, see the README included with the - driver.

-

For questions related to hardware requirements, refer to the - documentation supplied with your Intel PRO/1000 adapter. All hardware - requirements listed apply to use with FreeBSD.

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 16114.

-

This driver supports hardware assisted VLANs. The - em driver supports the following media types:

-
-
-
Enables auto-negotiation for speed and duplex.
-
-
Sets 10Mbps operation. Use the mediaopt option to - select full-duplex mode.
-
-
Sets 100Mbps operation. Use the mediaopt option to - select full-duplex mode.
-
-
Sets 1000Mbps operation. Only full-duplex mode is - supported at this speed.
-
-
Sets 1000Mbps operation. Only full-duplex mode is - supported at this speed.
-
-

The em driver supports the following media - options:

-
-
-
Forces full-duplex operation
-
-
Forces half-duplex operation.
-
-

Only use mediaopt to set the driver to - full-duplex. If mediaopt is - not specified, the driver defaults to - half-duplex.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The em driver supports Gigabit Ethernet - adapters based on the Intel 82540, 82541ER, 82541PI, 82542, 82543, 82544, - 82545, 82546, 82546EB, 82546GB, 82547, 82571, 82572, 82573, 82574, 82575, - 82576, and 82580 controller chips:

-

-
    -
  • Intel Gigabit ET Dual Port Server Adapter (82576)
    • -
  • Intel Gigabit VT Quad Port Server Adapter (82575)
    • -
  • Intel Single, Dual and Quad Gigabit Ethernet Controller (82580)
    • -
  • Intel i210 and i211 Gigabit Ethernet Controller
    • -
  • Intel i350 and i354 Gigabit Ethernet Controller
    • -
  • Intel PRO/1000 CT Network Connection (82547)
    • -
  • Intel PRO/1000 F Server Adapter (82543)
    • -
  • Intel PRO/1000 Gigabit Server Adapter (82542)
    • -
  • Intel PRO/1000 GT Desktop Adapter (82541PI)
    • -
  • Intel PRO/1000 MF Dual Port Server Adapter (82546)
    • -
  • Intel PRO/1000 MF Server Adapter (82545)
    • -
  • Intel PRO/1000 MF Server Adapter (LX) (82545)
    • -
  • Intel PRO/1000 MT Desktop Adapter (82540)
    • -
  • Intel PRO/1000 MT Desktop Adapter (82541)
    • -
  • Intel PRO/1000 MT Dual Port Server Adapter (82546)
    • -
  • Intel PRO/1000 MT Quad Port Server Adapter (82546EB)
    • -
  • Intel PRO/1000 MT Server Adapter (82545)
    • -
  • Intel PRO/1000 PF Dual Port Server Adapter (82571)
    • -
  • Intel PRO/1000 PF Quad Port Server Adapter (82571)
    • -
  • Intel PRO/1000 PF Server Adapter (82572)
    • -
  • Intel PRO/1000 PT Desktop Adapter (82572)
    • -
  • Intel PRO/1000 PT Dual Port Server Adapter (82571)
    • -
  • Intel PRO/1000 PT Quad Port Server Adapter (82571)
    • -
  • Intel PRO/1000 PT Server Adapter (82572)
    • -
  • Intel PRO/1000 T Desktop Adapter (82544)
    • -
  • Intel PRO/1000 T Server Adapter (82543)
    • -
  • Intel PRO/1000 XF Server Adapter (82544)
    • -
  • Intel PRO/1000 XT Server Adapter (82544)
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). See - iflib(4) for per-instance variables.

-
-
hw.em.disable_crc_stripping
-
Disable or enable hardware stripping of CRC field. This is mostly useful - on BMC/IPMI shared interfaces where stripping the CRC causes remote access - over IPMI to fail. Default 0 (enabled).
-
hw.em.eee_setting
-
Disable or enable Energy Efficient Ethernet. Default 1 (disabled).
-
hw.em.smart_pwr_down
-
Enable or disable smart power down features on newer adapters. Default 0 - (disabled).
-
hw.em.sbp
-
Show bad packets when in promiscuous mode. Default 0 (off).
-
hw.em.rx_int_delay
-
This value delays the generation of receive interrupts in units of 1.024 - microseconds. The default value is 0, since adapters may hang with this - feature being enabled.
-
hw.em.rx_abs_int_delay
-
If hw.em.rx_int_delay is non-zero, this tunable - limits the maximum delay in which a receive interrupt is generated.
-
hw.em.tx_int_delay
-
This value delays the generation of transmit interrupts in units of 1.024 - microseconds. The default value is 64.
-
hw.em.tx_abs_int_delay
-
If hw.em.tx_int_delay is non-zero, this tunable - limits the maximum delay in which a transmit interrupt is generated.
-
hw.em.max_interrupt_rate
-
Maximum interrupts per second. The default value is 8000.
-
hw.em.rx_process_limit
-
Maximum number of received packets to process at a time, -1 means - unlimited. The default value is 100.
-
-
-
-

-
-
/dev/led/em*
-
identification LED device nodes
-
-
-
-

-

Make the identification LED of em0 blink:

-

-
echo f2 > - /dev/led/em0
-

Turn the identification LED of em0 off again:

-

-
echo 0 > /dev/led/em0
-
-
-

-
-
em%d: Unable to allocate bus resource: memory
-
A fatal initialization error has occurred.
-
em%d: Unable to allocate bus resource: interrupt
-
A fatal initialization error has occurred.
-
em%d: watchdog timeout -- resetting
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

For general information and support, go to the Intel support - website at: http://support.intel.com.

-

If an issue is identified with the released source code on the - supported kernel with a supported adapter, email the specific information - related to the issue to - <freebsd@intel.com>.

-
-
-

-

altq(4), arp(4), - iflib(4), led(4), - netintro(4), ng_ether(4), - polling(4), vlan(4), - ifconfig(8)

-
-
-

-

The em device driver first appeared in - FreeBSD 4.4. em was merged - with the lem and igb device - drivers and converted to the iflib(4) framework in - FreeBSD 12.0.

-
-
-

-

The em driver was originally written by - Intel Corporation - <freebsd@intel.com>. - It was merged with the igb driver and converted to - the iflib(4) framework by Matthew - Macy - <mmacy@mattmacy.io> - and Sean Bruno - <sbruno@FreeBSD.org>.

-
-
- - - - - -
March 20, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ena.4 3.html b/static/freebsd/man4/ena.4 3.html deleted file mode 100644 index 28354471..00000000 --- a/static/freebsd/man4/ena.4 3.html +++ /dev/null @@ -1,564 +0,0 @@ - - - - - - -
ENA(4)Device Drivers ManualENA(4)
-
-
-

-

ena — AWS EC2 - Elastic Network Adapter (ENA) driver

-
-
-

-

To compile this driver into the kernel, place the following line - in the kernel configuration file:

-
device ena
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ena_load="YES"
-
-
-
-

-

The ENA is a networking interface designed to make good use of - modern CPU features and system architectures.

-

The ENA device exposes a lightweight management interface with a - minimal set of memory mapped registers and extendable command set through an - Admin Queue.

-

The driver supports a range of ENA devices, is link-speed - independent (i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), - and has a negotiated and extendable feature set.

-

Some ENA devices support SR-IOV. This driver is used for both the - SR-IOV Physical Function (PF) and Virtual Function (VF) devices.

-

The ENA devices enable high speed and low overhead network traffic - processing by providing multiple Tx/Rx queue pairs (the maximum number is - advertised by the device via the Admin Queue), a dedicated MSI-X interrupt - vector per Tx/Rx queue pair, and CPU cacheline optimized data placement.

-

When RSS is enabled, each Tx/Rx queue pair is bound to a - corresponding CPU core and its NUMA domain. The order of those bindings is - based on the RSS bucket mapping. For builds with RSS support disabled, the - CPU and NUMA management is left to the kernel. Receive-side scaling (RSS) is - supported for multi-core scaling.

-

The ena driver and its corresponding - devices implement health monitoring mechanisms such as watchdog, enabling - the device and driver to recover in a manner transparent to the application, - as well as debug logs.

-

Some of the ENA devices support a working mode called Low-latency - Queue (LLQ), which saves several more microseconds.

-

Support for the netmap(4) framework is provided - by the ena driver. Kernel must be built with the - DEV_NETMAP option to be able to use this feature.

-
-
-

-

The ena driver supports the following PCI - vendor ID/device IDs:

-

-
    -
  • 1d0f:0ec2 - ENA PF
    • -
  • 1d0f:1ec2 - ENA PF with LLQ support
    • -
  • 1d0f:ec20 - ENA VF
    • -
  • 1d0f:ec21 - ENA VF with LLQ support
    • -
-
-
-

-

The ena driver's behavior can be changed - using run-time or boot-time sysctl arguments. The boot-time arguments can be - set at the loader(8) prompt before booting the kernel, or - stored in the loader.conf(5). The run-time arguments can - be set using the sysctl(8) command.

-

Boot-time tunables:

-
-
hw.ena.enable_9k_mbufs
-
Use 9k mbufs for the Rx descriptors. The default is 0. If the node value - is set to 1, 9k mbufs will be used for the Rx buffers. If set to 0, page - size mbufs will be used instead. -

Using 9k buffers for Rx can improve Rx throughput, but in low - memory conditions it might increase allocation time, as the system has - to look for 3 contiguous pages. This can further lead to OS instability, - together with ENA driver reset and NVMe timeouts. If network performance - is critical and memory capacity is sufficient, the 9k mbufs can be - used.

-
-
hw.ena.force_large_llq_header
-
Force the driver to use large (224 bytes) or regular (96 bytes) LLQ header - size. The default value is 2 and the recommended LLQ header size will be - used. If the node value is set to 0, the regular size LLQ header will be - used, which is 96B. In some cases, the packet header can be bigger than - this (for example - IPv6 with multiple extensions). In such a situation, - the large LLQ header size which is 224B should be used, and can be forced - by setting this node value to 1. Using large LLQ header size will take - effect only if the device supports both LLQ and large LLQ headers. - Otherwise, it will fallback to the no LLQ mode or regular header size. -

Increasing LLQ header size reduces the size of the Tx queue by - half, so it may affect the number of dropped Tx packets.

-
-
-

Run-time tunables:

-
-
hw.ena.log_level
-
Controls extra logging verbosity of the driver. The default is 2. The - higher the logging level, the more logs will be printed out. 0 means all - extra logs are disabled and only error logs will be printed out. Default - value (2) reports errors, warnings and is verbose about driver operation. -

The possible flags are:

-

-
    -
  • 0 - ENA_ERR - Enable driver error messages and ena_com error - logs.
    • -
  • 1 - ENA_WARN - Enable logs for non-critical errors.
    • -
  • 2 - ENA_INFO - Make the driver more verbose about its actions.
    • -
  • 3 - ENA_DBG - Enable debug logs.
    • -
-

NOTE: In order to enable logging on the Tx/Rx data path, - driver must be compiled with ENA_LOG_IO_ENABLE compilation flag.

-

Example: To enable logs for errors and warnings, the following - command should be used:

-
- 
sysctl hw.ena.log_level=1
-
-
-
dev.ena.X.io_queues_nb
-
Number of the currently allocated and used IO queues. The default is - max_num_io_queues. Controls the number of IO queue pairs (Tx/Rx). As this - call has to reallocate the queues, it will reset the interface and restart - all the queues - this means that everything, which was currently held in - the queue, will be lost, leading to potential packet drops. -

This call can fail if the system isn't able to provide the - driver with enough resources. In that situation, the driver will try to - revert the previous number of the IO queues. If this also fails, the - device reset will be triggered.

-

Example: To use only 2 Tx and Rx queues for the device ena1, - the following command should be used:

-
- 
sysctl dev.ena.1.io_queues_nb=2
-
-
-
dev.ena.X.rx_queue_size
-
Size of the Rx queue. The default is 1024. Controls the number of IO - descriptors for each Rx queue. The user may want to increase the Rx queue - size if they observe a high number of Rx drops in the driver's statistics. - For performance reasons, the Rx queue size must be a power of 2. -

This call can fail if the system isn't able to provide the - driver with enough resources. In that situation, the driver will try to - revert to the previous number of the descriptors. If this also fails, - the device reset will be triggered.

-

Example: To increase Rx ring size to 8K descriptors for the - device ena0, the following command should be used:

-
- 
sysctl dev.ena.0.rx_queue_size=8192
-
-
-
dev.ena.X.buf_ring_size
-
Size of the Tx buffer ring (drbr). The default is 4096. Input must be a - power of 2. Controls the number of mbufs that can be held in the Tx buffer - ring. The drbr is used as a multiple-producer, single-consumer lockless - ring for buffering extra mbufs coming from the stack in case the Tx - procedure is busy sending the packets, or the Tx ring is full. Increasing - the size of the buffer ring may reduce the number of Tx packets being - dropped in case of a big Tx burst, which cannot be handled by the IO queue - immediately. Each Tx queue has its own drbr. -

It is recommended to keep the drbr with at least the default - value, but in case the system lacks the resources, it can be reduced. - This call can fail if the system is not able to provide the driver with - enough resources. In that situation, the driver will try to revert to - the previous number of the drbr and trigger the device reset.

-

Example: To set drbr size for interface ena0 to 2048, the - following command should be used:

-
- 
sysctl dev.ena.0.buf_ring_size=2048
-
-
-
dev.ena.X.eni_metrics.sample_interval
-
Interval in seconds for updating ENI metrics. The default is 0. Determines - how often (if ever) the ENI metrics should be updated. The ENI metrics are - being updated asynchronously in a timer service in order to avoid admin - queue overload by sysctl node reading. The value in this node controls the - interval between issuing admin commands to the device, which will update - the ENI metrics values. -

If some application is periodically monitoring the - eni_metrics, then the ENI metrics interval can be adjusted accordingly. - Value 0 turns off the update completely. Value 1 is the minimum interval - and is equal to 1 second. The maximum allowed update interval is 1 - hour.

-

Example: To update ENI metrics for the device ena1 every 10 - seconds, the following command should be used:

-
- 
sysctl dev.ena.1.eni_metrics.sample_interval=10
-
-
-
dev.ena.X.rss.indir_table_size
-
RSS indirection table size. The default is 128. Returns the number of - entries in the RSS indirection table. -

Example: To read the RSS indirection table size, the following - command should be used:

-
- 
sysctl dev.ena.0.rss.indir_table_size
-
-
-
dev.ena.X.rss.indir_table
-
RSS indirection table mapping. The default is x:y key-pairs of - indir_table_size length. Updates selected indices of the RSS indirection - table. -

The entry string consists of one or more x:y keypairs, where x - stands for the table index and y for its new value. Table indices that - don't need to be updated can be omitted from the string and will retain - their existing values.

-

If an index is entered more than once, the last value is - used.

-

Example: To update two selected indices in the RSS indirection - table, e.g. setting index 0 to queue 5 and then index 5 to queue 0, the - following command should be used:

-
- 
sysctl dev.ena.0.rss.indir_table="0:5 5:0"
-
-
-
dev.ena.X.rss.key
-
RSS hash key. The default is 40 bytes long randomly generated hash key. - Controls the RSS Toeplitz hash algorithm key value. -

Only available when driver compiled without the kernel side - RSS support.

-

Example: To change the RSS hash key value to

-

0x6d, 0x5a, 0x56, 0xda, 0x25, 0x5b, 0x0e, 0xc2, -
- 0x41, 0x67, 0x25, 0x3d, 0x43, 0xa3, 0x8f, 0xb0, -
- 0xd0, 0xca, 0x2b, 0xcb, 0xae, 0x7b, 0x30, 0xb4, -
- 0x77, 0xcb, 0x2d, 0xa3, 0x80, 0x30, 0xf2, 0x0c, -
- 0x6a, 0x42, 0xb7, 0x3b, 0xbe, 0xac, 0x01, 0xfa

-

the following command should be used:

-
- 
sysctl dev.ena.0.rss.key=6d5a56da255b0ec24167253d43a38fb0d0ca2bcbae7b30b477cb2da38030f20c6a42b73bbeac01fa
-
-
-
-
-
-

-
-

-
-
ena%d: failed to init mmio read less
-
-

Error occurred during initialization of the mmio register read - request.

-
-
ena%d: Can not reset device
-
-

Device could not be reset. -
- Device may not be responding or is already during reset.

-
-
ena%d: device version is too low
-
-

Version of the controller is too old and it is not supported - by the driver.

-
-
ena%d: Invalid dma width value %d
-
-

The controller is unable to request dma transaction width. -
- Device stopped responding or it demanded invalid value.

-
-
ena%d: Can not initialize ena admin queue with device
-
-

Initialization of the Admin Queue failed. -
- Device may not be responding or there was a problem with initialization of - the resources.

-
-
ena%d: Cannot get attribute for ena device rc: %d
-
-

Failed to get attributes of the device from the - controller.

-
-
ena%d: Cannot configure aenq groups rc: %d
-
-

Errors occurred when trying to configure AENQ groups.

-
-
-
-
-

-
-
ena%d: PCI resource allocation failed!
-
-
ena%d: failed to pmap registers bar
-
-
ena%d: can not allocate ifnet structure
-
-
ena%d: Error with network interface setup
-
-
ena%d: Failed to enable and set the admin interrupts
-
-
ena%d: Error, MSI-X is already enabled
-
-
ena%d: Failed to enable MSIX, vectors %d rc %d
-
-
ena%d: Not enough number of MSI-X allocated: %d
-
-
ena%d: Error with MSI-X enablement
-
-
ena%d: could not allocate irq vector: %d
-
-
ena%d: unable to allocate bus resource: registers!
-
-
ena%d: unable to allocate bus resource: msix!
-
-

Resource allocation failed when initializing the device. -
- Driver will not be attached.

-
-
ena%d: ENA device init failed (err: %d)
-
-
ena%d: Cannot initialize device
-
-

Device initialization failed. -
- Driver will not be attached.

-
-
ena%d: failed to register interrupt handler for irq %ju: %d
-
-

Error occurred when trying to register Admin Queue interrupt - handler.

-
-
ena%d: Cannot setup mgmnt queue intr
-
-

Error occurred during configuration of the Admin Queue - interrupts.

-
-
ena%d: Enable MSI-X failed
-
-

Configuration of the MSI-X for Admin Queue failed. -
- There could be lack of resources or interrupts could not have been - configured. -
- Driver will not be attached.

-
-
ena%d: VLAN is in use, detach first
-
-

VLANs are being used when trying to detach the driver. -
- VLANs must be detached first and then detach routine have to be called - again.

-
-
ena%d: Unmapped RX DMA tag associations
-
-
ena%d: Unmapped TX DMA tag associations
-
-

Error occurred when trying to destroy RX/TX DMA tag.

-
-
ena%d: Cannot init indirect table
-
-
ena%d: Cannot fill indirect table
-
-
ena%d: Cannot fill hash function
-
-
ena%d: Cannot fill hash control
-
-
ena%d: WARNING: RSS was not properly initialized, it will affect - bandwidth
-
-

Error occurred during initialization of one of RSS resources. -
- The device will work with reduced performance because all RX packets will - be passed to queue 0 and there will be no hash information.

-
-
ena%d: LLQ is not supported. Fallback to host mode policy.
-
-
ena%d: Failed to configure the device mode. Fallback to host mode - policy.
-
-
ena%d: unable to allocate LLQ bar resource. Fallback to host mode - policy.
-
-

Error occurred during Low-latency Queue mode setup. -
- The device will work, but without the LLQ performance gain.

-
-
ena%d: failed to enable write combining.
-
-

Error occurred while setting the Write Combining mode, - required for the LLQ.

-
-
ena%d: failed to tear down irq: %d
-
-
ena%d: dev has no parent while releasing res for irq: %d
-
Release of the interrupts failed.
-
-
-
-

-
-
ena%d: Invalid MTU setting. new_mtu: %d max_mtu: %d min mtu: %d
-
-

Requested MTU value is not supported and will not be set.

-
-
ena%d: Failed to set MTU to %d
-
-

This message appears when either MTU change feature is not - supported, or device communication error has occurred.

-
-
ena%d: Keep alive watchdog timeout.
-
-

Device stopped responding and will be reset.

-
-
ena%d: Found a Tx that wasn't completed on time, qid %d, index %d.
-
-

Packet was pushed to the NIC but not sent within given time - limit. -
- It may be caused by hang of the IO queue.

-
-
ena%d: The number of lost tx completion is above the threshold (%d > - %d). Reset the device
-
-

If too many Tx weren't completed on time the device is going - to be reset. -
- It may be caused by hanged queue or device.

-
-
ena%d: Trigger reset is on
-
-

Device will be reset. -
- Reset is triggered either by watchdog or if too many TX packets were not - completed on time.

-
-
ena%d: device reset scheduled but trigger_reset is off
-
-

Reset task has been triggered, but the driver did not request - it. -
- Device reset will not be performed.

-
-
ena%d: Device reset failed
-
-

Error occurred while trying to reset the device.

-
-
ena%d: Cannot initialize device
-
-
ena%d: Error, mac address are different
-
-
ena%d: Error, device max mtu is smaller than ifp MTU
-
-
ena%d: Validation of device parameters failed
-
-
ena%d: Enable MSI-X failed
-
-
ena%d: Failed to create I/O queues
-
-
ena%d: Reset attempt failed. Can not reset the device
-
-

Error occurred while trying to restore the device after - reset.

-
-
ena%d: Device reset completed successfully, Driver info: %s
-
-

Device has been correctly restored after reset and is ready to - use.

-
-
ena%d: Allocation for Tx Queue %u failed
-
-
ena%d: Allocation for Rx Queue %u failed
-
-
ena%d: Unable to create Rx DMA map for buffer %d
-
-
ena%d: Failed to create io TX queue #%d rc: %d
-
-
ena%d: Failed to get TX queue handlers. TX queue num %d rc: %d
-
-
ena%d: Failed to create io RX queue[%d] rc: %d
-
-
ena%d: Failed to get RX queue handlers. RX queue num %d rc: %d
-
-
ena%d: could not allocate irq vector: %d
-
-
ena%d: failed to register interrupt handler for irq %ju: %d
-
-

IO resources initialization failed. -
- Interface will not be brought up.

-
-
ena%d: LRO[%d] Initialization failed!
-
-

Initialization of the LRO for the RX ring failed.

-
-
ena%d: failed to alloc buffer for rx queue
-
-
ena%d: failed to add buffer for rx queue %d
-
-
ena%d: refilled rx qid %d with only %d mbufs (from %d)
-
-

Allocation of resources used on RX path failed. -
- If happened during initialization of the IO queue, the interface will not - be brought up.

-
-
ena%d: NULL mbuf in rx_info
-
-

Error occurred while assembling mbuf from descriptors.

-
-
ena%d: tx_info doesn't have valid mbuf
-
-
ena%d: Invalid req_id: %hu
-
-
ena%d: failed to prepare tx bufs
-
-

Error occurred while preparing a packet for transmission.

-
-
ena%d: ioctl promisc/allmulti
-
-

IOCTL request for the device to work in promiscuous/allmulti - mode. -
- See ifconfig(8) for more details.

-
-
-
-
-
-

-

If an issue is identified with the released source code with a - supported adapter, please email the specific information related to the - issue to - <akiyano@amazon.com>, - <osamaabb@amazon.com> - and - <darinzon@amazon.com>.

-
-
-

-

netmap(4), vlan(4), - ifconfig(8)

-
-
-

-

The ena driver first appeared in - FreeBSD 11.1.

-
-
-

-

The ena driver was developed by Amazon and - originally written by Semihalf.

-
-
- - - - - -
November 14, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/enc.4 3.html b/static/freebsd/man4/enc.4 3.html deleted file mode 100644 index f75c5d00..00000000 --- a/static/freebsd/man4/enc.4 3.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - -
ENC(4)Device Drivers ManualENC(4)
-
-
-

-

enc — - Encapsulating Interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device enc
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_enc_load="YES"
-
-
-
-

-

The enc interface is a software loopback - mechanism that allows hosts or firewalls to filter - ipsec(4) traffic using any firewall package that hooks in - via the pfil(9) framework.

-

The enc interface allows an administrator - to see incoming and outgoing packets before and after they will be or have - been processed by ipsec(4) via - tcpdump(1).

-

The “enc0” interface - inherits all IPsec traffic. Thus all IPsec traffic can be filtered based on - “enc0”, and all IPsec traffic could be - seen by invoking tcpdump(1) on the - “enc0” interface.

-

What can be seen with tcpdump(1) and what will - be passed on to the firewalls via the pfil(9) framework - can be independently controlled using the following - sysctl(8) variables:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
DefaultsSuggested
net.enc.out.ipsec_bpf_mask0x000000030x00000001
net.enc.out.ipsec_filter_mask0x000000010x00000001
net.enc.in.ipsec_bpf_mask0x000000010x00000002
net.enc.in.ipsec_filter_mask0x000000010x00000002
-

For the incoming path a value of 0x1 means - “before stripping off the outer - header” and 0x2 means - “after stripping off the outer - header”. For the outgoing path 0x1 - means “with only the inner header” and - 0x2 means “with outer and - inner headers”.

-
-
incoming path                                          |------|
----- IPsec processing ---- (before) ---- (after) ----> |      |
-                                                       | Host |
-<--- IPsec processing ---- (after) ----- (before) ---- |      |
-outgoing path                                          |------|
-
-

Most people will want to run with the suggested defaults for - ipsec_filter_mask and rely on the security policy - database for the outer headers.

-

Note that packets are captured by BPF before firewall processing. - The special value 0x4 can be configured in the - ipsec_bpf_mask and packets will be also captured after - firewall processing.

-
-
-

-

To see the packets processed via ipsec(4), - adjust the sysctl(8) variables according to your need and - run:

-

-
tcpdump -i enc0
-
-
-

-

tcpdump(1), bpf(4), - ipf(4), ipfw(4), - ipsec(4), pf(4)

-
-
- - - - - -
August 9, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/enic.4 4.html b/static/freebsd/man4/enic.4 4.html deleted file mode 100644 index 971384c9..00000000 --- a/static/freebsd/man4/enic.4 4.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
ENIC(4)Device Drivers ManualENIC(4)
-
-
-

-

enic — VIC - Ethernet NIC driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device enic
-

To load the driver as a module at run-time, run the following - command as root:

-
-
kldload if_enic
-
-

To load the driver as a module at boot time, place the following - lines in loader.conf(5):

-
-
if_enic_load="YES"
-
-
-
-

-

The enic driver provides support for Cisco - Virtual Interface Card. Support is limited to basic network connectivity. - Media is controlled by the NIC itself since there can be multiple virtual - PCI NIC devices exposed to the PCI bus.

-
-
-

-

The enic driver should supports all known - Cisco VIC cards.

-
-
-

-

The enic network interface is configured - using ifconfig(8) and the sysctl(8) tree - at dev.enic.<N>. All configurable entries are - also tunables, and can be put directly into the - loader.conf(5) for persistent configuration.

-
-
-

-

ifconfig(8)

-
-
-

-

The enic device driver first appeared in - FreeBSD 14.0.

-
-
-

-

The enic driver was written by - Cisco UCS team based of the DPDK driver.

-
-
- - - - - -
September 7, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/epair.4 3.html b/static/freebsd/man4/epair.4 3.html deleted file mode 100644 index c79e723a..00000000 --- a/static/freebsd/man4/epair.4 3.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - -
EPAIR(4)Device Drivers ManualEPAIR(4)
-
-
-

-

epair — A pair of - virtual back-to-back connected Ethernet interfaces

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device epair
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_epair_load="YES"
-
-
-
-

-

The epair is a pair of Ethernet-like - software interfaces, which are connected back-to-back with a virtual - cross-over cable.

-

Each epair interface pair is created at - runtime using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5). While for cloning you only give either - epair or epair<n> the - epair pair will be named like - epair<n>[ab]. This means the names of the - first epair interfaces will be - epair0a and epair0b.

-

Like any other Ethernet interface, an - epair needs to have a network address. If the - tunable net.link.epair.ether_gen_addr=0, each - epair will be assigned a random locally administered - address, that is only guaranteed to be unique within one network stack. The - tunable net.link.epair.ether_gen_addr=1 will generate - a stable MAC address with FreeBSD OUI using - ether_gen_addr(9). This tunable defaults to 1 in - FreeBSD 15.0 and might be removed in - FreeBSD 16.0. To change the default addresses one - may use the SIOCSIFADDR ioctl(2) or - ifconfig(8) utility.

-

The basic intent is to provide connectivity between two virtual - network stack instances. When connected to an - if_bridge(4), one end of the interface pair can also be - part of another (virtual) LAN. As with any other Ethernet interface, - epair can have a vlan(4) - configured on top of it.

-

The epair has RXCSUM and RXCSUM6 enabled - because it may receive a packet where the checksum has already been - validated by a physical interface.

-

The epair supports TXCSUM and TXCSUM6 for - TCP and UDP, but only by forwarding the order to compute the checksum. Thus, - when using an epair interface, a TCP or UDP sender - can offload checksum computation to a physical interface. Note that, in case - the packet does not leave the host, the checksum is unnecessary and will be - ignored if offloaded. Such packets contain an incorrect checksum, since it - is not computed yet. TXCSUM and TXCSUM6 are synchronized between the - epair interface pair (i.e., enabling/disabling the - capability on one end enables/disables it on the other end). In case one end - is in a bridge and the bridge disabled TXCSUM or TXCSUM6, this avoids a - sender to send packets with checksum offloading into the bridge by using the - other end.

-

The epair supports VLAN_HWTAGGING without - actually adding a VLAN tag. The sending epair end - just forwards the offloading information to the other end. The receiving - epair end leaves the offloading information set to - pretend that there was a VLAN tag in the Ethernet header, which has been - removed already. To avoid a situation where the receiving - epair end has VLAN_HWTAGGING disabled, this - capability is synchronized between the epair - interface pair (i.e., enabling/disabling the capability on one end - enables/disables it on the other end).

-
-
-

-

ioctl(2), altq(4), - bpf(4), if_bridge(4), - vlan(4), loader.conf(5), - rc.conf(5), ifconfig(8)

-
-
-

-

The epair interface first appeared in - FreeBSD 8.0.

-
-
-

-

The epair interface was written by - Bjoern A. Zeeb, CK Software GmbH, under sponsorship - from the FreeBSD Foundation.

-
-
- - - - - -
January 30, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/est.4 3.html b/static/freebsd/man4/est.4 3.html deleted file mode 100644 index 3404b1c1..00000000 --- a/static/freebsd/man4/est.4 3.html +++ /dev/null @@ -1,116 +0,0 @@ - - - - - - -
EST(4)Device Drivers ManualEST(4)
-
-
-

-

est — Enhanced - Speedstep Technology

-
-
-

-

To compile this capability into your kernel place the following - line in your kernel configuration file:

-
device cpufreq
-
-
-

-

The est interface provides support for the - Intel Enhanced Speedstep Technology.

-

Note that est capabilities are - automatically loaded by the cpufreq(4) driver.

-
-
-

-

The est interface is intended to allow - cpufreq(4) to access and implement Intel Enhanced - SpeedStep Technology via acpi(4) and the acpi_perf - interface accessors. If the default settings are not optimal, the following - sysctls can be used to modify or monitor est - behavior.

-
-
hw.est.msr_info
-
Attempt to infer information from direct probing of the msr. Should only - be used in diagnostic cases. (default 0)
-
hw.est.strict
-
Validate frequency requested is accepted by the CPU when set. It appears - that this will only work on single core cpus. (default 0)
-
-
-
-

-

The following sysctl(8) values are available

-
-
dev.est.%d.%desc
-
Description of support, almost always Enhanced SpeedStep Frequency - Control.
-
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
-
 
-
dev.est.%d.%driver
-
Driver in use, always est.
-
dev.est.0.%driver: est
-
 
-
dev.est.%d.%parent
-
The CPU that is exposing these frequencies. For example - cpu0.
-
dev.est.0.%parent: cpu0
-
 
-
dev.est.%d.freq_settings.
-
The valid frequencies that are allowed by this CPU and their step - values.
-
dev.est.0.freq_settings: 2201/45000 2200/45000 2000/39581 1900/37387
-
1800/34806 1700/32703 1600/30227 1500/28212 1400/25828 1300/23900 - 1200/21613 1100/19775 1000/17582 900/15437 800/13723
-
-
-
-

-
-
est%d: <Enhanced SpeedStep Frequency Control> on cpu%d
-
-

Indicates normal startup of this interface.

-
-
est: CPU supports Enhanced Speedstep, but is not recognized.
-
-
est: cpu_vendor GenuineIntel, msr 471c471c0600471c
-
-
device_attach: est%d attach returned 6
-
-

Indicates all attempts to attach to this interface have - failed. This usually indicates an improper BIOS setting restricting O/S - control of the CPU speeds. Consult your BIOS documentation for more - details.

-
-
-
-
-

-

est is only found on supported Intel - CPUs.

-
-
-

-

cpufreq(4)

-

Intel 64 and IA-32 - Architectures Software Developer Manuals, - http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html.

-
-
-

-

This manual page was written by Sean Bruno - <sbruno@FreeBSD.org>.

-
-
- - - - - -
April 21, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/et.4 3.html b/static/freebsd/man4/et.4 3.html deleted file mode 100644 index 25b6a668..00000000 --- a/static/freebsd/man4/et.4 3.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - -
ET(4)Device Drivers ManualET(4)
-
-
-

-

et — Agere ET1310 - 10/100/Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device et
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_et_load="YES"
-
-
-
-

-

The et driver supports PCI Express - Ethernet adapters based on the Agere ET1310 chip.

-

The et driver supports the following media - types:

-

-
-
autoselect
-
Enable autoselection of the media types and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file. -

-
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes. -

-
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to select either full-duplex - or half-duplex modes. -

-
-
1000baseT
-
Set 1000Mbps (Gigabit Ethernet) operation. The - mediaopt option can only be set to - full-duplex mode.
-
-

The et driver supports the following - media options:

-

-
-
full-duplex
-
Force full-duplex operation. -

-
-
half-duplex
-
Force half-duplex operation.
-
-

Note that the 1000baseT media type is only available if it is - supported by the adapter. For more information on configuring this device, - see ifconfig(8).

-
-
-

-

The et driver supports Agere ET1310 - 10/100/Gigabit Ethernet adapters.

-
-
-

-
-
hw.et.rx_intr_npkts
-
This value controls how many packets should be received before a receive - interrupt is generated. The default value is 32. It is recommended to set - this value above 38 to prevent the host from being livelocked under a high - degree of stress.
-
hw.et.rx_intr_delay
-
This value delays the generation of receive interrupts in units of ~4 - microseconds. It is used together with - hw.et.rx_intr_npkts to achieve RX interrupt - moderation. The default value is 20.
-
hw.et.tx_intr_nsegs
-
This value controls how many segments (not packets) should be transmitted - before a transmit interrupt is generated. The default value is 126. It is - recommended to set this value below 280 to prevent the TX ring from - underflowing.
-
hw.et.timer
-
This value controls how often a timer interrupt should be generated. It is - used together with hw.et.tx_intr_nsegs to achieve TX - interrupt moderation. The default value is 1000000000 (nanoseconds).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The et device driver first appeared in - DragonFly 1.11. The first - FreeBSD release to include it was - FreeBSD 8.0.

-
-
-

-

The et driver was written by - Sepherosa Ziehau - <sepherosa@gmail.com> - for DragonFly. It was ported to - FreeBSD by Xin LI - <delphij@FreeBSD.org>.

-
-
- - - - - -
December 9, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/etherswitch.4 3.html b/static/freebsd/man4/etherswitch.4 3.html deleted file mode 100644 index f48ec902..00000000 --- a/static/freebsd/man4/etherswitch.4 3.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
ETHERSWITCH(4)Device Drivers ManualETHERSWITCH(4)
-
-
-

-

etherswitch — - Ethernet switch framework

-
-
-

-

To compile the framework into the kernel, place the following - lines in the kernel configuration file:

-
device etherswitch -
-device miiproxy -
-device iicbus
-
-
-

-

The etherswitch driver provides a - framework for Ethernet switch devices.

-
-
-

-
-
/dev/etherswitch?
-
etherswitch device nodes
-
-
-
-

-

adm6996fc(4), ar40xx(4), - arswitch(4), e6000sw(4), - e6060sw(4), iicbus(4), - ksz8995ma(4), etherswitchcfg(8)

-
-
-

-

The etherswitch framework first appeared - in FreeBSD 10.0.

-
-
-

-

Stefan Bethke

-
-
- - - - - -
April 5, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/eventtimers.4 3.html b/static/freebsd/man4/eventtimers.4 3.html deleted file mode 100644 index 098d782e..00000000 --- a/static/freebsd/man4/eventtimers.4 3.html +++ /dev/null @@ -1,130 +0,0 @@ - - - - - - -
EVENTTIMERS(4)Device Drivers ManualEVENTTIMERS(4)
-
-
-

-

eventtimers — - kernel event timers subsystem

-
-
-

-

Kernel uses several types of time-related devices, such as: real - time clocks, time counters and event timers. Real time clocks responsible - for tracking real world time, mostly when system is down. Time counters are - responsible for generation of monotonically increasing timestamps for - precise uptime tracking purposes, when system is running. Event timers are - responsible for generating interrupts at specified time or periodically, to - run different time-based events. This page is about the last.

-
-
-

-

Kernel uses time-based events for many different purposes: - scheduling, statistics, time keeping, profiling and many other things, based - on callout(9) mechanism. These purposes now grouped into - three main callbacks:

-
-
()
-
callout(9) and timekeeping events entry. Called with - frequency defined by hz variable, usually - 1000Hz.
-
()
-
statistics and scheduler events entry. Called with frequency about - 128Hz.
-
()
-
profiler events entry. When enabled, called with frequency about - 8KHz.
-
-

Different platforms provide different kinds of timer hardware. The - goal of the event timers subsystem is to provide unified way to control that - hardware, and to use it, supplying kernel with all required time-based - events.

-

Each driver implementing event timers, registers them at the - subsystem. It is possible to see the list of present event timers, like - this, via kern.eventtimer sysctl:

-
-
kern.eventtimer.choice: HPET(550) LAPIC(400) i8254(100) RTC(0)
-kern.eventtimer.et.LAPIC.flags: 15
-kern.eventtimer.et.LAPIC.frequency: 0
-kern.eventtimer.et.LAPIC.quality: 400
-kern.eventtimer.et.i8254.flags: 1
-kern.eventtimer.et.i8254.frequency: 1193182
-kern.eventtimer.et.i8254.quality: 100
-kern.eventtimer.et.RTC.flags: 17
-kern.eventtimer.et.RTC.frequency: 32768
-kern.eventtimer.et.RTC.quality: 0
-kern.eventtimer.et.HPET.flags: 7
-kern.eventtimer.et.HPET.frequency: 14318180
-kern.eventtimer.et.HPET.quality: 550
-
-

where:

-
-
kern.eventtimer.et.X.flags
-
is a bitmask, defining event timer capabilities: -
-
-
1
-
periodic mode supported,
-
2
-
one-shot mode supported,
-
4
-
timer is per-CPU,
-
8
-
timer may stop when CPU goes to sleep state,
-
16
-
timer supports only power-of-2 divisors.
-
-
-
-
kern.eventtimer.et.X.frequency
-
is a timer base frequency,
-
kern.eventtimer.et.X.quality
-
is an integral value, defining how good is this timer, comparing to - others.
-
-

Timers management code of the kernel chooses one timer from that - list. Current choice can be read and affected via - kern.eventtimer.timer tunable/sysctl. Several other - tunables/sysctls are affecting how exactly this timer is used:

-
-
kern.eventtimer.periodic
-
allows to choose periodic and one-shot operation mode. In periodic mode, - periodic interrupts from timer hardware are taken as the only source of - time for time events. One-shot mode instead uses currently selected time - counter to precisely schedule all needed events and programs event timer - to generate interrupt exactly in specified time. Default value depends of - chosen timer capabilities, but one-shot mode is preferred, until other is - forced by user or hardware.
-
kern.eventtimer.singlemul
-
in periodic mode specifies how much times higher timer frequency should - be, to not strictly alias - () - and - () - events. Default values are 1, 2 or 4, depending on configured HZ - value.
-
kern.eventtimer.idletick
-
makes each CPU to receive every timer interrupt independently of whether - they busy or not. By default this options is disabled. If chosen timer is - per-CPU and runs in periodic mode, this option has no effect - all - interrupts are always generating.
-
-
-
-

-

apic(4), atrtc(4), - attimer(4), hpet(4), - timecounters(4), eventtimers(9)

-
-
- - - - - -
March 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/exca.4 4.html b/static/freebsd/man4/exca.4 4.html deleted file mode 100644 index da302055..00000000 --- a/static/freebsd/man4/exca.4 4.html +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - -
EXCA(4)Device Drivers ManualEXCA(4)
-
-
-

-

exca — helper - module for PC Card and CardBus systems

-
-
-

-

The exca module is used to implement the - Intel ExCA interface to PC Cards.

-
-
-

-

pccbb(4)

-
-
- - - - - -
February 23, 2003FreeBSD 15.0
diff --git a/static/freebsd/man4/ext2fs.4 3.html b/static/freebsd/man4/ext2fs.4 3.html deleted file mode 100644 index 04dd2b1e..00000000 --- a/static/freebsd/man4/ext2fs.4 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
EXT2FS(4)Device Drivers ManualEXT2FS(4)
-
-
-

-

ext2fs — - ext2/ext3/ext4 file system

-
-
-

-

To link into the kernel:

-
options EXT2FS
-

To load as a kernel loadable module:

-

-
kldload ext2fs
-
-
-

-

The ext2fs driver will permit the - FreeBSD kernel to access ext2 file systems and its - derivatives. It currently implements most of the features required by - and - ext4 file systems. Support for Extended Attributes in - ext4 is experimental. Journalling and encryption are - currently not supported.

-
-
-

-

To mount a ext2fs volume located on - /dev/ada1s1:

-

-
mount -t ext2fs /dev/ada1s1 - /mnt
-
-
-

-

nmount(2), unmount(2), - fstab(5), mount(8)

-
-
-

-

The ext2fs driver first appeared in - FreeBSD 2.2.

-
-
-

-

The ext2fs kernel implementation is - derived from code written, or modified, by Godmar - Back using the UFS CSRG sources for CMU Mach.

-

John Dyson did the initial port to - FreeBSD. Aditya Sarawgi - merged important parts of the allocation code from a clean-room - NetBSD implementation. Zheng - Liu and Fedor Uporov implemented the read and - write support respectively for ext4 filesystems. The - FreeBSD community has contributed a huge amount of - modifications.

-

The initial version of this manual page was written by - Craig Rodrigues - <rodrigc@FreeBSD.org>.

-
-
- - - - - -
December 30, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/fd.4 4.html b/static/freebsd/man4/fd.4 4.html deleted file mode 100644 index 295bd9a1..00000000 --- a/static/freebsd/man4/fd.4 4.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
FD(4)Device Drivers ManualFD(4)
-
-
-

-

fd, stdin, - stdout, stderr — - file descriptor files

-
-
-

-

The files /dev/fd/0 through - /dev/fd/# refer to file descriptors which can be - accessed through the file system. If the file descriptor is open and the - mode the file is being opened with is a subset of the mode of the existing - descriptor, the call:

-
-
fd = open("/dev/fd/0", mode);
-
-

and the call:

-
-
fd = fcntl(0, F_DUPFD, 0);
-
-

are equivalent.

-

Opening the files /dev/stdin, - /dev/stdout and /dev/stderr - is equivalent to the following calls:

-
-
fd = fcntl(STDIN_FILENO,  F_DUPFD, 0);
-fd = fcntl(STDOUT_FILENO, F_DUPFD, 0);
-fd = fcntl(STDERR_FILENO, F_DUPFD, 0);
-
-

Flags to the open(2) call other than - O_RDONLY, O_WRONLY and - O_RDWR are ignored.

-
-
-

-

By default, /dev/fd is provided by - devfs(4), which provides nodes for the first three file - descriptors. Some sites may require nodes for additional file descriptors; - these can be made available by mounting fdescfs(4) on - /dev/fd.

-
-
-

-
-
/dev/fd/#
-
 
-
/dev/stdin
-
 
-
/dev/stdout
-
 
-
/dev/stderr
-
 
-
-
-
-

-

devfs(4), fdescfs(4), - tty(4)

-
-
- - - - - -
June 9, 1993FreeBSD 15.0
diff --git a/static/freebsd/man4/fdc.4 3.html b/static/freebsd/man4/fdc.4 3.html deleted file mode 100644 index 012d0888..00000000 --- a/static/freebsd/man4/fdc.4 3.html +++ /dev/null @@ -1,313 +0,0 @@ - - - - - - -
FDC(4)Device Drivers ManualFDC(4)
-
-
-

-

fdc — PC - architecture floppy disk controller driver

-
-
-

-

device fdc

-

In /boot/device.hints: -
- hint.fdc.0.at="isa" -
- hint.fdc.0.port="0x3F0" -
- hint.fdc.0.irq="6" -
- hint.fdc.0.drq="2" -
- hint.fdc.0.flags="0x0" -
- hint.fd.0.at="fdc0" -
- hint.fd.0.drive="0" -
- hint.fd.0.flags="0x0" -
- hint.fd.1.at="fdc0" -
- hint.fd.1.drive="1" -
- hint.fd.1.flags="0x0"

-
-
-

-

The fdc driver is deprecated and may not - be present in FreeBSD 16.0 and later.

-
-
-

-
-

-

This driver provides access to floppy disk drives. Floppy disks - using either FM (single-density) or MFM (double or high-density) recording - can be handled.

-

Floppy disk controllers can connect up to four - drives each. The fdc driver can currently handle up - to two drives per controller (or four drives on ACPI). Upon driver - initialization, an attempt is made to find out the type of the floppy - controller in use. The known controller types are either the original NE765 - or i8272 chips, or alternatively - - controllers that are compatible with the NE72065 or i82077 chips. These - enhanced controllers (among other enhancements) implement a FIFO for floppy - data transfers that will automatically be enabled once an enhanced chip has - been detected. This FIFO activation can be disabled using the per-controller - flags value of 0x1.

-

By default, this driver creates a single device node - /dev/fdN for each attached - drive with number N. For historical reasons, device - nodes that use a trailing UFS-style partition letter (ranging from - ‘a’ through ‘h’) can also be accessed, which - will be implemented as symbolic links to the main device node.

-

Accessing the main device node will attempt to autodetect the - density of the available medium for multi-density devices. Thus it is - possible to use either a 720 KB medium or a 1440 KB medium in a high-density - 3.5 inch standard floppy drive. Normally, this autodetection will only - happen once at the first call to open(2) for the device - after inserting the medium. This assumes the drive offers proper changeline - support so media changes can be detected by the driver. To indicate a drive - that does not have the changeline support, this can be overridden using the - per-drive device flags value of 0x10 (causing each - call to open(2) to perform the autodetection).

-

When trying to use a floppy device with special-density media, - other device nodes can be created, of the form - /dev/fdN.MMMM, - where N is the drive number, and - MMMM is a number between one and four digits - describing the device density. Up to 15 additional subdevices per drive can - be created that way. The administrator is free to decide on a policy how to - assign these numbers. The two common policies are to either implement - subdevices numbered 1 through 15, or to use a number that describes the - medium density in kilobytes. Initially, each of those devices will be - configured to the maximal density that is possible for the drive type (like - 1200 KB for 5.25 inch HD drives or 1440 KB for 3.5 inch HD drives). The - desired density to be used on that subdevice needs to be configured using - fdcontrol(8).

-

Drive types are configured using the lower four bits of the - per-drive device flags. The following values can be specified:

-
-
-
1
-
5.25 inch double-density device with 40 cylinders (360 KB native - capacity)
-
2
-
5.25 inch high-density device with 80 cylinders (1200 KB native - capacity)
-
3
-
3.5 inch double-density device with 80 cylinders (720 KB native - capacity)
-
4
-
3.5 inch high-density device with 80 cylinders (1440 KB native - capacity)
-
5
-
3.5 inch extra-density device with 80 cylinders (2880 KB native capacity, - usage currently restricted to at most 1440 KB media)
-
6
-
Same as type 5, available for compatibility with some BIOSes
-
-
-

On IA32 architectures, the drive type can be specified as 0 for - the drives. In that case, the CMOS configuration memory will be consulted to - obtain the value for that drive. The ACPI probe automatically determines - these values via the _FDE and _FDI methods, but this can be overridden by - specifying a drive type hint.

-

Normally, each configured drive will be probed at initialization - time, using a short seek sequence. This is intended to find out about drives - that have been configured but are actually missing or otherwise not - responding. (The ACPI probe method does not perform this seek.) In some - environments (like laptops with detachable drives), it might be desirable to - bypass this drive probe, and pretend a drive to be there so the driver - autoconfiguration will work even if the drive is currently not present. For - that purpose, a per-drive device flags value of 0x20 - needs to be specified.

-
-
-

-

In addition to the normal read and write functionality, the - fdc driver offers a number of configurable options - using ioctl(2). In order to access any of this - functionality, programmers need to include the header file - <sys/fdcio.h> into their - programs. The call to open(2) can be performed in two - possible ways. When opening the device without the - O_NONBLOCK flag set, the device is opened in a - normal way, which would cause the main device nodes to perform automatic - media density selection, and which will yield a file descriptor that is - fully available for any I/O operation or any of the following - ioctl(2) commands.

-

When opening the device with O_NONBLOCK - set, automatic media density selection will be bypassed, and the device - remains in a half-opened state. No actual I/O operations are possible, but - many of the ioctl(2) commands described below can be - performed. This mode is intended for access to the device without the - requirement to have an accessible media present, like for status inquiries - to the drive, or in order to format a medium. - O_NONBLOCK needs to be cleared before I/O operations - are possible on the descriptor, which requires a prior specification of the - density using the FD_STYPE command (see below). - Operations that are not allowed on the half-opened descriptor will cause an - error value of EAGAIN.

-

The following ioctl(2) commands are currently - available:

-
-
-
Used to format a floppy disk medium. Third argument is a pointer to a - struct fd_formb specifying which track to format, - and which parameters to fill into the ID fields of the floppy disk - medium.
-
-
Returns the current density definition record for the selected device. - Third argument is a pointer to struct fd_type.
-
-
Adjusts the density definition of the selected device. Third argument is a - pointer to struct fd_type. For the fixed-density - subdevices (1 through 15 per drive), this operation is restricted to a - process with superuser privileges. For the auto-selecting subdevice 0, the - operation is temporarily allowed to any process, but this setting will be - lost again upon the next autoselection. This can be used when formatting a - new medium (which will require to open the device using - O_NONBLOCK, and thus to later adjust the density - using FD_STYPE).
-
-
Obtain the current drive options. Third argument is a pointer to - int, containing a bitwise union of the following - possible flag values: -
-
-
Do not automatically retry operations upon failure.
-
-
Do not cause “hard error” kernel logs for failed I/O - operations.
-
-
Do not indicate I/O errors when returning from - read(2) or write(2) system calls. - The caller is assumed to use FD_GSTAT calls in - order to inquire about the success of each operation. This is intended - to allow even erroneous data from bad blocks to be retrieved using - normal I/O operations.
-
-
Device performs automatic density selection. Unlike the above flags, - this one is read-only.
-
-
-
-
Set device options, see above for their meaning. Third argument is a - pointer to int. Drive options will always be cleared - when closing the descriptor.
-
-
Clear the internal low-level error counter. Normally, controller-level I/O - errors are only logged up to FDC_ERRMAX errors - (currently defined to 100). This command resets the counter. Requires - superuser privileges.
-
-
Read one sector ID field from the floppy disk medium. Third argument is a - pointer to struct fdc_readid, where the read data - will be returned. Can be used to analyze a floppy disk medium.
-
-
Return the recent floppy disk controller status, if available. Third - argument is a pointer to struct fdc_status, where - the status registers (ST0, ST1, ST2, C, H, R, and N) are being returned. - EINVAL will be caused if no recent status is - available.
-
-
Returns the floppy disk drive type. Third argument is a pointer to - enum fd_drivetype. This type is the same as being - used in the per-drive configuration flags, or in the CMOS configuration - data or ACPI namespace on IA32 systems.
-
-
-
-
-

-
-
-
Selectively enable debugging by setting one or more flags. -
-
-
Dump device registers on reset.
-
-
When an IO operation completes, print the number of retries when that - number is greater than zero.
-
-
Print when the number of retries exceeds - debug.fdc.retries - (EIO). Print when the option - FDOPT_NOERROR is set and an error would have - returned from a write operation.
-
-
Print detailed IO command information.
-
-
Print status registers.
-
-
Print detailed status registers when interrupts complete. Print the - source code line number close to the source of a non-zero return from - a thread worker operation.
-
-
Print when the disk appears to be lost. Print cylinder, head, sector, - and sector shift information after a request to read an ID field. - Notify whether a disk probe resulted in finding a disk. When detecting - the density of media present, indicate whether the autosensing was - successful, and if so, the size of the medium in kilobytes. Print - detailed type information when setting the drive type.
-
-
Print when an unknown IOCTL is used.
-
-
-
-
For enhanced controllers, allows a non-default FIFO threshold setting. The - default is 8 bytes.
-
-
Maximum number of retries to attempt. The default is 10.
-
-
Specification byte one (step-rate + head unload). The default step rate is - 6 ms. The default head unload time is 240 ms.
-
-
Specification byte two (head load time + no-dma). The default head load - time is 16 ms, and no-dma is 0 (disabled).
-
-
Head settling time in - - / hz seconds. The default value is set during device attach.
-
-
-
-

-
-
/dev/fd*
-
floppy disk device nodes
-
-
-
-

-

fdread(1), fdwrite(1), - ioctl(2), open(2), - read(2), write(2), - fdcontrol(8), fdformat(8)

-
-
-

-

This man page was initially written by Wilko - Bulte, and later vastly rewritten by Jörg - Wunsch.

-
-
- - - - - -
November 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/fdescfs.4 3.html b/static/freebsd/man4/fdescfs.4 3.html deleted file mode 100644 index 9e0f124a..00000000 --- a/static/freebsd/man4/fdescfs.4 3.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - -
FDESCFS(4)Device Drivers ManualFDESCFS(4)
-
-
-

-

fdescfs — - file-descriptor file system

-
-
-

-
-
fdescfs	/dev/fd	fdescfs rw 0 0
-
-
-
-

-

The file-descriptor file system, or - fdescfs, provides access to the per-process file - descriptor namespace in the global file system namespace. The conventional - mount point is /dev/fd.

-

The file system's contents appear as a list of numbered files - which correspond to the open files of the process reading the directory. The - files /dev/fd/0 through - /dev/fd/# refer to file descriptors which can be - accessed through the file system.

-

The following mount options can be used when mounting - fdescfs filesystem:

-
-
-
For file descriptors referencing vnodes, instead of the - dup(2) semantic described above, implement re-opening of - the referenced vnode. See below for more details.
-
-
Report the type of the fdescfs vnode as - VLNK instead of FreeBSD - traditional VCHR. For linux(4) - ABI compatibility mount fdescfs volume with the - linrdlnk option.
-
-
Treat fdescfs vnodes as symbolic links - consistently, in particular, follow the resolved name for the name - lookups. This option is strictly stronger than the - linrdlnk option, it changes not only the type - returned by stat(2), but also causes the - fdescfs files to behave as symlinks.
-
-

For fdescfs mounted without the - nodup mount option, if the file descriptor is open - and the mode the file is being opened with is a subset of the mode of the - existing descriptor, the call:

-
-
fd = open("/dev/fd/0", mode);
-
-

and the call:

-
-
fd = fcntl(0, F_DUPFD, 0);
-
-

are equivalent. Flags to the open(2) call other - than O_RDONLY, O_WRONLY and - O_RDWR are ignored.

-

For fdescfs mounted with the - nodup option, and file descriptor referencing a - vnode, the call:

-
-
fd = open("/dev/fd/0", mode);
-
-

reopens the referenced vnode with the specified - mode. In other words, the - () call - above is equivalent to

-
-
fd = openat(0, "", O_EMPTY_PATH, mode);
-
-

In particular, if the file descriptor was opened with - the O_PATH flag, then either - O_EMPTY_PATH or - () over - fdescfs mount with nodup - option allows one to convert it to a regularly opened file, assuming that - the current permissions allow the requested mode.

-

- /dev/fd/0, /dev/fd/1 and - /dev/fd/2 files are created by default when devfs - alone is mounted. fdescfs creates entries for all - file descriptors opened by the process.

-
-
-

-
-
/dev/fd/#
-
 
-
-
-
-

-

To mount a fdescfs volume located on - /dev/fd:

-

-
mount -t fdescfs none - /dev/fd
-

For linux(4) ABI compatibility:

-

-
mount -t fdescfs -o linrdlnk none - /compat/linux/dev/fd
-

For substitute of O_EMPTY_PATH flag - use:

-

-
mount -t fdescfs -o nodup none - /dev/fdpath
-
-
-

-

devfs(4), mount(8)

-
-
-

-

The fdescfs file system first appeared in - 4.4BSD. The fdescfs manual - page first appeared in FreeBSD 2.2.

-
-
-

-

The fdescfs manual page was written by - Mike Pritchard - <mpp@FreeBSD.org>, and - was based on the manual page written by Jan-Simon - Pendry.

-
-
- - - - - -
July 11, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/fdt.4 3.html b/static/freebsd/man4/fdt.4 3.html deleted file mode 100644 index a45fb990..00000000 --- a/static/freebsd/man4/fdt.4 3.html +++ /dev/null @@ -1,176 +0,0 @@ - - - - - - -
FDT(4)Device Drivers ManualFDT(4)
-
-
-

-

fdt — Flattened - Device Tree support

-
-
-

-

options FDT -
- makeoptions FDT_DTS_FILE=<board name>.dts -
- options FDT_DTB_STATIC

-
-
-

-

is a mechanism for describing computer hardware - resources, which cannot be probed or self enumerated, in a uniform and - portable way. The primary consumers of this technology are - where a lot of designs are based on similar chips, but have - different assignment of pins, memory layout, addresses bindings, interrupts - routing and other resources.

-

Configuration data, which cannot be self discovered in run-time, - has to be supplied from external source. The concept of a flattened device - tree is a platform and architecture independent approach for resolving such - problems. The idea is inherited from Open Firmware IEEE 1275 device-tree - notion, and has been successfully adopted by the embedded industry. The - scheme works in the following way:

-
    -
  • Hardware platform resources are - - described in a human readable text source format, where all non - self-enumerating information is gathered.
    • -
  • This source description is converted - - into a binary object i.e. a flattened device tree - - which is passed to the kernel at boot time.
    • -
  • The kernel (driver) learns about hardware resources details and - dependencies from this [externally supplied] blob, which eliminates the - need for embedding any information about the underlying platform hardware - resources in the kernel.
    • -
  • The flattened device tree mechanism in principle does not depend on any - particular first-stage bootloader or firmware features. The only overall - requirement for the environment is to provide a complete device tree - description to the kernel.
    • -
-

The fdt layer allows any platform code in - the kernel to retrieve information about hardware resources from a unified - origin, which brings advantages to the embedded applications (eliminates - hard-coded configuration approach, enforces code to be data driven and - extensible) leading to easier porting and maintenance.

-
-
-

-
-
Device tree source (DTS)
-
The device tree source is a text file which describes hardware resources - of a computer system in a human-readable form, with certain hierarchical - structure (a tree). The default location for DTS files in the - FreeBSD source repository is - sys/dts directory.
-
Device tree blob (DTB)
-
The textual device tree description (DTS file) is first converted - (compiled) into a binary object (the device tree blob) i.e. the DTB, which - is handed over to the final consumer (typically kernel) for parsing and - processing of its contents.
-
Device tree compiler (DTC)
-
A utility program executed on the host, which transforms (compiles) a - textual description of a device tree (DTS) into a binary object - (DTB).
-
Device tree bindings
-
While the device tree textual description and the binary object are media - to convey the hardware configuration information, an actual meaning and - interpretation of the contents are defined by the device tree - bindings. They are certain conventions describing - definitions (encoding) of particular nodes in a device tree and their - properties, allowed values, ranges and so on. Such reference conventions - were provided by the legacy Open Firmware bindings, further supplemented - by the ePAPR specification.
-
-
-
-

-

In order for the system to support fdt it - is required that FreeBSD world be built with the - WITH_FDT build knob supplied either via - src.conf(5) or command line defined with -D.

-

This creates the user space dtc compiler - and enables fdt support in - loader(8).

-
-
-

-

There is a couple of options for managing - fdt support at the FreeBSD - kernel level.

-
-
makeoptions DTS+=<board - name>.dts
-
Specifies device tree source (DTS) files for a given kernel. The indicated - DTS files will be converted (compiled) into a binary form along with - building the kernel itself. Any DTS file names not written as an absolute - path must be specified relative to the default location of DTS sources - i.e., sys/dts.
-
makeoptions DTSO+=<overlay - name>.dtso
-
Specifies device tree source overlay (DTSO) files for a given kernel. - Overlay files will be built with the kernel as with the makeoption - DTS described above. Overlay files specified as - relative paths will be relative to the default location of DTS overlays - for the platform being built i.e., - sys/dts/arm/overlays.
-
options FDT
-
The primary option for enabling fdt support in the - kernel. It covers all low-level and infrastructure parts of - fdt kernel support, which primarily are the - fdtbus(4) and simplebus(4) drivers, as - well as helper routines and libraries.
-
makeoptions FDT_DTS_FILE=<board - name>.dts
-
Specifies a preferred (default) device tree source (DTS) file for a given - kernel. It will be built along with the kernel as if it were supplied via - the makeoption DTS described above. This makeoption - is not mandatory unless FDT_DTB_STATIC is also defined (see below).
-
options FDT_DTB_STATIC
-
Typically, the device tree blob (DTB) is a stand-alone file, physically - separate from the kernel, but this option lets statically embed a DTB file - into a kernel image. Note that when this is specified the FDT_DTS_FILE - makeoption becomes mandatory (as there needs to be a DTS file specified in - order to embed it into the kernel image).
-
-
-
-

-

fdtbus(4), openfirm(4), - simplebus(4)

-
-
-

-

IEEE Std 1275: IEEE Standard for Boot (Initialization - Configuration) Firmware: Core Requirements and Practices - (Open Firmware).

-

Power.org Standard for Embedded Power Architecture Platform - Requirements (ePAPR).

-
-
-

-

The fdt support first appeared in - FreeBSD 9.0.

-
-
-

-

The fdt support was developed by Semihalf - under sponsorship from the FreeBSD Foundation. This manual page was written - by Rafal Jaworowski.

-
-
- - - - - -
March 28, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/fdt_pinctrl.4 3.html b/static/freebsd/man4/fdt_pinctrl.4 3.html deleted file mode 100644 index 97f4264c..00000000 --- a/static/freebsd/man4/fdt_pinctrl.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
FDT_PINCTRL(4)Device Drivers ManualFDT_PINCTRL(4)
-
-
-

-

fdt_pinctrl — FDT - I/O pin multiplexing support

-
-
-

-

device fdt_pinctrl

-
-
-

-

Pin multiplexing is a technology used to re-purpose a single - physical connection (depending on chip packaging it may be pin, ball, or - pad) by routing its signal to any one of several different SoC internal - devices. For example, based on the actual device design, a single SoC chip - pin might perform any of these roles: SPI clock, I2C data, GPIO pin, or PWM - signal. Function selection is performed by the pinmux controller, a SoC - hardware block which is usually controlled by a set of registers. Pinmux - controller capabilities and register format depend on the actual hardware - implementation.

-

On fdt(4) based systems, the pinmux controller - is represented by a node in the device tree. It may have any number of child - nodes representing pin configuration groups. Properties of such nodes are - hardware-specific and handled by individual pinctrl drivers.

-
-

-

Pinmux controller device tree node

-
-
pinctrl@7e220000 {
-    compatible = "vndr,soc1715-pinctrl";
-    reg = <0x7e220000 0x100>
-
-    spi0_pins: spi0 {
-        vndr,pins = <11 12>
-        vndr,functions = <ALT0 ALT5>
-    }
-
-    i2c0_pins: i2c0 {
-        ...
-    }
-}
-
-

Client devices are hardware devices that require certain pin - configurations to function properly. Depending on the state the device is in - (active, idle) it might require different pin configurations. Each - configuration is described by setting the pinctrl-N property to the list of - phandles pointing to specific child nodes of the pinmux controller node. N - is an integer value starting with 0 and incremented by 1 for every new set - of pin configurations. pinctrl-0 is a default configuration that is applied - in the fdt_pinctrl_configure_tree(9) call. In addition to - referring to pin configurations by index, they can be referred to by name if - the pinctrl-names property is set. The value of pinctrl-names is a list of - strings with names for each pinctrl-N property. Client devices can request - specific configuration using fdt_pinctrl_configure(9) and - fdt_pinctrl_configure_by_name(9).

-
-
-

-
-
backlight@7f000000 {
-    compatible = "vndr,vndr-bl"
-    reg = <0x7f000000 0x20>
-    ...
-    pinctrl-name = "active", "idle"
-    pinctrl-0 = <&backlight_active_pins>
-    pinctrl-1 = <&backlight_idle_pins>
-}
-
-

The pinctrl driver should implement the FDT_PINCTRL_CONFIGURE - method, register itself as a pin configuration handler by calling - fdt_pinctrl_register function, and call - fdt_pinctrl_configure_tree(9) to configure pins for all - enabled devices (devices where the "status" property is not set to - "disabled").

-
-
-
-

-

fdt_pinctrl(9)

-
-
-

-

The fdt_pinctrl driver first appeared in - FreeBSD 10.2.

-
-
-

-

The fdt_pinctrl device driver was - developed by Ian Lepore - <ian@FreeBSD.org>. - This manual page was written by Oleksandr Tymoshenko - <gonzo@FreeBSD.org>.

-
-
- - - - - -
March 3, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/fdtbus.4 3.html b/static/freebsd/man4/fdtbus.4 3.html deleted file mode 100644 index 2fa87b47..00000000 --- a/static/freebsd/man4/fdtbus.4 3.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
FDTBUS(4)Device Drivers ManualFDTBUS(4)
-
-
-

-

fdtbus — Flattened - Device Tree bus driver

-
-
-

-

options FDT

-
-
-

-

The fdtbus abstract bus driver is the - primary connection and translation layer between fdt(4) - hardware resources description and FreeBSD native - newbus device drivers framework. For an embedded system - fdtbus represents peripherals typically found on a - highly integrated chip (system-on-chip).

-

The fdtbus driver provides generic, common - infrastructure for all fdt(4) oriented device drivers, and - its main responsibilities are the following:

-
    -
  • Creating newbus children that reflect fdt(4) nodes in - the flattened device tree.
    • -
  • Managing SYS_RES_IRQ resources.
    • -
  • Managing SYS_RES_MEMORY, SYS_RES_IOPORT resources.
    • -
-
-
-

-

fdt(4), openfirm(4), - simplebus(4)

-
-
-

-

IEEE Std 1275: IEEE Standard for Boot (Initialization - Configuration) Firmware: Core Requirements and Practices - (Open Firmware).

-

Power.org Standard for Embedded Power Architecture Platform - Requirements (ePAPR).

-
-
-

-

The fdtbus support first appeared in - FreeBSD 9.0.

-
-
-

-

The fdtbus support was developed by - Semihalf under sponsorship from the FreeBSD Foundation. This manual page was - written by Rafal Jaworowski.

-
-
- - - - - -
July 12, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/ffclock.4 3.html b/static/freebsd/man4/ffclock.4 3.html deleted file mode 100644 index c3f3477d..00000000 --- a/static/freebsd/man4/ffclock.4 3.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
FFCLOCK(4)Device Drivers ManualFFCLOCK(4)
-
-
-

-

FFCLOCK — - Feed-forward system clock

-
-
-

-

options FFCLOCK

-
-
-

-

The ntpd(8) daemon has been the dominant - solution for system clock synchronisation for many years, which has in turn - influenced the design of the system clock. The ntpd daemon implements a - feedback control algorithm which has been demonstrated to perform poorly in - common use cases.

-

Feed-forward clock synchronisation algorithms implemented by an - appropriate daemon, in concert with the FFCLOCK - kernel support, have been shown to provide highly robust and accurate clock - synchronisation. In addition to time keeping, the - FFCLOCK kernel mechanism provides new timestamping - capabilities and the ability to use specialised clocks. Feed-forward - synchronisation is also very well suited for virtualised environments, - reducing the overhead of timekeeping in guests and ensuring continued smooth - operation of the system clock during guest live migration.

-

The FFCLOCK kernel support provides - feed-forward timestamping functions within the kernel and system calls to - support feed-forward synchronisation daemons (see - ffclock(2)).

-
-

-

The following kernel configuration options are related to - FFCLOCK:

-

-
-
-
Enable feed-forward clock support.
-
-
-
-

-

When feed-forward clock support is compiled into the kernel, - multiple system clocks become available to choose from. System clock - configuration is possible via the kern.sysclock - sysctl(8) tree which provides the following variables:

-
-
-
kern.sysclock.active
-
Name of the current active system clock which is serving time. Set to one - of the names in kern.sysclock.available in order to - change the default active system clock.
-
kern.sysclock.available
-
Lists the names of available system clocks (read-only).
-
-
-

Feed-forward system clock configuration is possible via the - kern.sysclock.ffclock sysctl tree which provides the - following variables:

-
-
-
kern.sysclock.ffclock.version
-
Feed-forward clock kernel version (read-only).
-
kern.sysclock.ffclock.ffcounter_bypass
-
Use reliable hardware timecounter as the feed-forward counter. Will - eventually be useful for virtualised environment like - xen(4), but currently does nothing.
-
-
-
-
-
-

-

clock_gettime(2), ffclock(2), - bpf(4), timecounters(4), - sysctl(8)

-
-
-

-

Feed-forward clock support first appeared in - FreeBSD 10.0.

-
-
-

-

The feed-forward clock support was written by - Julien Ridoux - <jridoux@unimelb.edu.au> - in collaboration with Darryl Veitch - <dveitch@unimelb.edu.au> - at the University of Melbourne under sponsorship from the FreeBSD - Foundation.

-

This manual page was written by Julien - Ridoux - <jridoux@unimelb.edu.au> - and Lawrence Stewart - <lstewart@FreeBSD.org>.

-
-
- - - - - -
December 1, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/ffs.4 3.html b/static/freebsd/man4/ffs.4 3.html deleted file mode 100644 index 6c903d85..00000000 --- a/static/freebsd/man4/ffs.4 3.html +++ /dev/null @@ -1,273 +0,0 @@ - - - - - - -
FFS(4)Device Drivers ManualFFS(4)
-
-
-

-

ffs, ufs — - Berkeley fast file system

-
-
-

-

In the kernel configuration file: -
- options FFS -
- options QUOTA -
- options SOFTUPDATES -
- options SUIDDIR -
- options UFS_ACL -
- options UFS_DIRHASH -
- options UFS_EXTATTR -
- options UFS_EXTATTR_AUTOSTART -
- options UFS_GJOURNAL

-

In fstab(5):

-
-
/dev/disk0a	/mnt ufs rw 1 1
-
-
-
-

-

The Berkeley fast file system provides facilities to store file - system data onto a disk device. ffs has been - optimized over the years for speed and reliability and is the default - FreeBSD file system.

-
-

-
-
options QUOTA
-
This option allows system administrators to set limits on disk usage on a - per-user basis. Quotas can be used only on file systems mounted with the - quota option; see quota(1) and - edquota(8).
-
-
-
-

-
-
options SOFTUPDATES
-
The soft updates feature tracks writes to the disk and enforces metadata - update dependencies (e.g., updating free block maps) to ensure that the - file system remains consistent. -

To create a new file system with the soft updates enabled, use - newfs(8) command:

-

-
newfs - -U fs
-

fs can be either a mount point listed in - fstab(5) (e.g., /usr), or a - disk device (e.g., /dev/da0a).

-

It is possible to enable soft updates on an - unmounted file system by using - tunefs(8) command:

-

-
tunefs - -n enable - fs
-

Soft updates can also add journaling that reduces the time - spent by fsck_ffs(8) cleaning up a filesystem after a - crash from several minutes to a few seconds. The journal is placed in an - inode named .sujournal, and is kept as a - circular log of segments containing records that describe metadata - operations.

-

To create a new file system with both the soft updates and - soft updates journaling enabled, use the following command:

-

-
newfs - -j fs
-

This runs tunefs(8) command after - newfs(8) command with -U flag - enabled. It is possible to enable soft updates journaling on an - unmounted file system by using - tunefs(8) command:

-

-
tunefs - -j enable - fs
-

This flag automatically enables the soft updates feature when - it is not enabled. Note that this tunefs(8) command - will fail if a file .sujournal already exists - before enabling the soft updates journaling.

-
-
-
-
-

-
-
options SUIDDIR
-
For use in file sharing environments on networks including Microsoft - Windows and Apple Macintosh computers, this option allows files on file - systems mounted with the suiddir option to inherit - the ownership of its directory, i.e., “if it's my directory, it - must be my file.”
-
-
-
-

-
-
options UFS_ACL
-
Access control lists allow the association of fine-grained discretionary - access control information with files and directories. This option - requires the presence of the UFS_EXTATTR option, - and it is recommended that UFS_EXTATTR_AUTOSTART - is included as well, so that ACLs are enabled atomically upon mounting the - file system.
-
-

In order to enable support for ACLs, two extended attributes must - be available in the EXTATTR_NAMESPACE_SYSTEM - namespace: posix1e.acl_access, which holds the - access ACL, and posix1e.acl_default, which holds the - default ACL for directories. If you are using file system extended - attributes, the following commands may be used to allocate space for and - create the necessary EA backing files for ACLs in the root of each file - system. In these examples, the root file system is used; see - Extended Attributes for more - details.

-
-
mkdir -p /.attribute/system
-cd /.attribute/system
-extattrctl initattr -p / 388 posix1e.acl_access
-extattrctl initattr -p / 388 posix1e.acl_default
-
-

On the next mount of the root file system, the attributes will be - automatically started if UFS_EXTATTR_AUTOSTART is - included in the kernel configuration, and ACLs will be enabled.

-
-
-

-
-
options UFS_DIRHASH
-
Implements a hash-based lookup scheme for directories in order to speed up - accesses to very large directories.
-
-
-
-

-
-
options UFS_EXTATTR
-
Extended attributes allow the association of additional arbitrary metadata - with files and directories, which can be assigned and retrieved from - userland as well as from within the kernel; see - extattrctl(8).
-
options UFS_EXTATTR_AUTOSTART
-
If this option is defined, ffs will search for a - .attribute subdirectory of the file system root - during the mount operation. If found, extended attribute support will be - automatically started for that file system.
-
-
-
-

-
-
options UFS_GJOURNAL
-
Implements a block level journaling of a UFS file system, which is for - both data and metadata. To enable this, create a - gjournal(8) GEOM provider for a block device by using - the following command: -

-
gjournal label - da0
-

In this example, /dev/da0 is used as - the target block device, and /dev/da0.journal is - created. Then create a new file system by using - newfs(8) with the block level journaling flag and - mount it:

-

-
newfs - -J /dev/da0.journal
-
mount - -o async - /dev/da0.journal /mnt
-

async option is not mandatory but - recommended for better performance because the journaling guarantees the - consistency of an async mount.

-

It is also possible to enable the block level journaling on an - existing file system. To do so, use gjournal(8) - utility to label the underlying block device and - tunefs(8) utility to enable the block level journaling - flag:

-

-
gjournal label - da0
-
tunefs - -J enable - /dev/da0.journal
-
mount - -o async - /dev/da0.journal /mnt
-
-
-
-
-

sysctl(8) - MIBs

-

The following sysctl(8) MIBs are defined for use - with ffs:

-
-
vfs.ffs.doasyncfree
-
Asynchronously write out modified i-node and indirect blocks upon - reallocating file system blocks to be contiguous. (Default: 1).
-
vfs.ffs.doreallocblks
-
Enable support for the rearrangement of blocks to be contiguous. (Default: - 1).
-
vfs.ffs.prttimechgs
-
Print a console message when timestamps for UFS1 filesystems are found to - be in the future and are changed to be the present time. (Default: - 0).
-
-
-
-
-

-

The ffs manual page first appeared in - FreeBSD 4.5.

-
-
-

-

quota(1), acl(3), - extattr(3), edquota(8), - extattrctl(8), fsck_ffs(8), - sysctl(8), tunefs(8)

-

M. McKusick, - W. Joy, S. Leffler, and - R. Fabry, A Fast File System for - UNIX, ACM Transactions on Computer Systems, - 2, 3, - 181-197, August - 1984.

-

M. McKusick, - Soft Updates: A Technique for Eliminating Most Synchronous - Writes in the Fast Filesystem, Proceedings of the - Freenix Track at the 1999 Usenix Annual Technical Conference, - 71-84, June - 2000.

-

M. McKusick and - J. Roberson, Journaled - Soft-updates, BSD Canada Conference 2010 (BSDCan), - May 2010.

-
-
- - - - - -
February 24, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/filemon.4 3.html b/static/freebsd/man4/filemon.4 3.html deleted file mode 100644 index 669aa259..00000000 --- a/static/freebsd/man4/filemon.4 3.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - -
FILEMON(4)Device Drivers ManualFILEMON(4)
-
-
-

-

filemon — the - filemon device

-
-
-

-

device filemon

-

-
- #include - <dev/filemon/filemon.h>

-
-
-

-

The filemon device allows a process to - collect file operations data of its children. The device - /dev/filemon responds to two - ioctl(2) calls.

-

filemon is not - intended to be a security auditing tool. Many system calls are not tracked - and binaries using a non-native ABI may not be fully audited. It is intended - for auditing of processes for the purpose of determining their dependencies - using an efficient and easily parsable format. An example of this is - make(1) which uses this module with - - to handle incremental builds more smartly.

-

System calls are denoted using the following single letters:

-

-
-
‘A’
-
openat(2). The next log entry may be lacking an absolute - path or be inaccurate.
-
‘C’
-
chdir(2)
-
‘D’
-
unlink(2)
-
‘E’
-
execve(2)
-
‘F’
-
fork(2), vfork(2)
-
‘L’
-
link(2), linkat(2), - symlink(2)
-
‘M’
-
rename(2)
-
‘R’
-
open(2) or openat(2) for read
-
‘W’
-
open(2) or openat(2) for write
-
‘X’
-
_exit(2)
-
-

Note that ‘R’ following - ‘W’ records can represent a single - open(2) for R/W, or two separate open(2) - calls, one for ‘R’ and one for - ‘W’. Note that only successful system - calls are captured.

-
-
-

-

User mode programs communicate with the - filemon driver through a number of ioctls which are - described below. Each takes a single argument.

-
-
-
Write the internal tracing buffer to the supplied open file - descriptor.
-
-
Child process ID to trace. This should normally be done under the control - of a parent in the child after fork(2) but before - anything else. See the example below.
-
-
-
-

-

The ioctl() function returns the value 0 - if successful; otherwise the value -1 is returned and the global variable - errno is set to indicate the error.

-
-
-

-

The ioctl() system call with - FILEMON_SET_FD will fail if:

-
-
[]
-
The filemon handle is already associated with a - file descriptor.
-
[]
-
The file descriptor has an invalid type and cannot be used for - tracing.
-
[]
-
The file descriptor is invalid or not opened for writing.
-
-

The ioctl() system call with - FILEMON_SET_PID will fail if:

-
-
[]
-
No process having the specified process ID exists.
-
[]
-
The process ID specified is already being traced and was not the current - process.
-
-

The close() system call on the filemon - file descriptor may fail with the errors from write(2) if - any error is encountered while writing the log. It may also fail if:

-
-
[]
-
An invalid address was used for a traced system call argument, resulting - in no log entry for the system call.
-
[]
-
An argument for a traced system call was too long, resulting in no log - entry for the system call.
-
-
-
-

-
-
/dev/filemon
-
 
-
-
-
-

-
-
#include <sys/types.h>
-#include <sys/stat.h>
-#include <sys/wait.h>
-#include <sys/ioctl.h>
-#include <dev/filemon/filemon.h>
-#include <fcntl.h>
-#include <err.h>
-#include <errno.h>
-#include <unistd.h>
-
-static void
-open_filemon(void)
-{
-	pid_t child, wait_rv;
-	int fm_fd, fm_log;
-
-	if ((fm_fd = open("/dev/filemon", O_RDWR | O_CLOEXEC)) == -1)
-		err(1, "open(\"/dev/filemon\", O_RDWR)");
-	if ((fm_log = open("filemon.out",
-	    O_CREAT | O_WRONLY | O_TRUNC | O_CLOEXEC, DEFFILEMODE)) == -1)
-		err(1, "open(filemon.out)");
-
-	if (ioctl(fm_fd, FILEMON_SET_FD, &fm_log) == -1)
-		err(1, "Cannot set filemon log file descriptor");
-
-	if ((child = fork()) == 0) {
-		child = getpid();
-		if (ioctl(fm_fd, FILEMON_SET_PID, &child) == -1)
-			err(1, "Cannot set filemon PID");
-		/* Do something here. */
-	} else if (child == -1)
-		err(1, "Cannot fork child");
-	else {
-		while ((wait_rv = wait(&child)) == -1 &&
-		    errno == EINTR)
-			;
-		if (wait_rv == -1)
-			err(1, "cannot wait for child");
-		close(fm_fd);
-	}
-}
-
-

Creates a file named filemon.out and - configures the filemon device to write the - filemon buffer contents to it.

-
-
-

-

dtrace(1), ktrace(1), - script(1), truss(1), - ioctl(2)

-
-
-

-

A filemon device appeared in - FreeBSD 9.1.

-
-
-

-

Unloading the module may panic the system, thus requires using - kldunload -f.

-
-
- - - - - -
April 19, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/firewire.4 3.html b/static/freebsd/man4/firewire.4 3.html deleted file mode 100644 index 8b34ad1c..00000000 --- a/static/freebsd/man4/firewire.4 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
FIREWIRE(4)Device Drivers ManualFIREWIRE(4)
-
-
-

-

firewire — - IEEE1394 High-performance Serial Bus

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device firewire
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
firewire_load="YES"
-
-
-
-

-

The firewire driver is slated to be - removed prior to FreeBSD 16.0.

-
-
-

-

FreeBSD provides machine-independent bus - support and raw drivers for firewire interfaces.

-

The firewire driver consists of two - layers: the controller and the bus layer. The controller attaches to a - physical bus (like pci(4)). The - firewire bus attaches to the controller. Additional - drivers can be attached to the bus.

-

Up to 63 devices, including the host itself, can be attached to a - firewire bus. The root node is dynamically assigned - with a PHY device function. Also, the other firewire - bus specific parameters, e.g., node ID, cycle master, isochronous resource - manager and bus manager, are dynamically assigned, after bus reset is - initiated. On the firewire bus, every device is - identified by an EUI 64 address.

-

Debugging over the firewire interface is possible with the - dcons(4) driver. Please see - https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-dcons - for details on how to setup debugging with firewire.

-
-
-

-
-
/dev/fw0.0
-
 
-
/dev/fwmem0.0
-
 
-
-
-
-

-

dcons(4), fwe(4), - fwip(4), fwohci(4), - pci(4), sbp(4), - eui64(5), fwcontrol(8), - kldload(8), sysctl(8)

-
-
-

-

The firewire driver first appeared in - FreeBSD 5.0.

-
-
-

-

The firewire driver was written by - Katsushi Kobayashi and Hidetoshi - Shimokawa for the FreeBSD project.

-
-
-

-

See fwohci(4) for security notes.

-
-
- - - - - -
January 23, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ftgpio.4 4.html b/static/freebsd/man4/ftgpio.4 4.html deleted file mode 100644 index 35c6eb17..00000000 --- a/static/freebsd/man4/ftgpio.4 4.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
FTGPIO(4)Device Drivers ManualFTGPIO(4)
-
-
-

-

ftgpio — GPIO - Controller on Fintek Super I/O",

-
-
-

-

device ftgpio -
- device gpio -
- device gpioled

-
-
-

-

The ftgpio is a driver for the GPIO - controller found on Fintek Super I/O chips.

-
-
-

-

gpio(3), gpio(4), - gpioled(4), superio(4), - gpioctl(8)

-
-
-

-

The ftgpio manual page first appeared in - FreeBSD 14.0.

-
-
-

-

The ftgpio driver was partially written by - Stéphane Rochoy - <stéphane.rochoy@stormshield.eu>.

-
-
- - - - - -
December 28, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/ftwd.4 3.html b/static/freebsd/man4/ftwd.4 3.html deleted file mode 100644 index 4d26ebf9..00000000 --- a/static/freebsd/man4/ftwd.4 3.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
FTWD(4)Device Drivers ManualFTWD(4)
-
-
-

-

ftwd — Fintek - F81803 watchdog timer

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device superio -
-device ftwd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ftwd_load="YES"
-
-
-
-

-

The ftwd driver provides - watchdog(4) support for the watchdog timer in the Fintek - F81803 chip.

-
-
-

-

superio(4), watchdog(4), - device.hints(5), watchdog(8), - watchdogd(8), watchdog(9)

-
-
-

-

This manual page was written by Poul-Henning - Kamp - <phk@FreeBSD.org>.

-
-
- - - - - -
November 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/full.4 3.html b/static/freebsd/man4/full.4 3.html deleted file mode 100644 index 39719e60..00000000 --- a/static/freebsd/man4/full.4 3.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - -
FULL(4)Device Drivers ManualFULL(4)
-
-
-

-

full — the full - device

-
-
-

-

The full device supplies an endless stream - of zeros when read. However, it will always be full when writing to it.

-
-
-

-
-
/dev/full
-
 
-
-
-
-

-

null(4), zero(4)

-
-
-

-

This device and man page was written by Eitan - Adler - <eadler@FreeBSD.org>.

-
-
- - - - - -
May 9, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/fusefs.4 3.html b/static/freebsd/man4/fusefs.4 3.html deleted file mode 100644 index e9db0b9d..00000000 --- a/static/freebsd/man4/fusefs.4 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
FUSEFS(4)Device Drivers ManualFUSEFS(4)
-
-
-

-

fusefs — File - system in USErspace

-
-
-

-

To link into the kernel:

-
options FUSEFS
-

To load as a loadable kernel module:

-

-
kldload fusefs
-
-
-

-

The fusefs driver implements a file system - that is serviced by a userspace program.

-

There are many uses for fusefs. Userspace - daemons can access libraries or programming languages that cannot run in - kernel-mode, for example. fusefs is also useful for - developing and debugging file systems, because a crash of the daemon will - not take down the entire operating system. Finally, the - fusefs API is portable. Many daemons can run on - multiple operating systems with minimal modifications.

-
-
-

-

The following sysctl(8) variables are - available:

-
-
vfs.fusefs.kernelabi_major
-
Major version of the FUSE kernel ABI supported by this driver.
-
vfs.fusefs.kernelabi_minor
-
Minor version of the FUSE kernel ABI supported by this driver.
-
vfs.fusefs.data_cache_mode
-
Controls how fusefs will cache file data for - pre-7.23 file systems. A value of 0 will disable caching entirely. Every - data access will be forwarded to the daemon. A value of 1 will select - write-through caching. Reads will be cached in the VFS layer as usual. - Writes will be immediately forwarded to the daemon, and also added to the - cache. A value of 2 will select write-back caching. Reads and writes will - both be cached, and writes will occasionally be flushed to the daemon by - the page daemon. Write-back caching is usually unsafe, especially for FUSE - file systems that require network access. -

FUSE file systems using protocol 7.23 or later specify their - cache behavior on a per-mountpoint basis, ignoring this sysctl.

-
-
vfs.fusefs.stats.filehandle_count
-
Current number of open FUSE file handles.
-
vfs.fusefs.stats.lookup_cache_hits
-
Total number of lookup cache hits.
-
vfs.fusefs.stats.lookup_cache_misses
-
Total number of lookup cache misses.
-
vfs.fusefs.stats.node_count
-
Current number of allocated FUSE vnodes.
-
vfs.fusefs.stats.ticket_count
-
Current number of allocated FUSE tickets, which is roughly equal to the - number of FUSE operations currently being processed by daemons.
-
-
-
-

-

mount_fusefs(8)

-
-
-

-

The fuse driver was written as the part of - the FreeBSD implementation of the FUSE userspace - file system framework (see - https://github.com/libfuse/libfuse) - and first appeared in the sysutils/fusefs-kmod port, - supporting FreeBSD 6.0. It was added to the base - system in FreeBSD 10.0, and renamed to - fusefs for FreeBSD 12.1.

-
-
-

-

The fuse driver was originally written by - Csaba Henk as a Google Summer of Code project in - 2005. It was further developed by Ilya Putsikau - during Google Summer of Code 2011, and that version was integrated into the - base system by Attilio Rao - <attilio@FreeBSD.org>.

-

This manual page was written by Alan - Somers - <asomers@FreeBSD.org>.

-
-
- - - - - -
July 31, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/fwe.4 3.html b/static/freebsd/man4/fwe.4 3.html deleted file mode 100644 index 009c20d1..00000000 --- a/static/freebsd/man4/fwe.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
FWE(4)Device Drivers ManualFWE(4)
-
-
-

-

fwe — Ethernet - emulation driver for FireWire

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device firewire -
-device fwe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_fwe_load="YES"
-
-
-
-

-

The fwe driver provides non-standard - Ethernet emulation over FireWire (IEEE 1394).

-

firewire(4) and fwohci(4) must - be configured in the kernel as well.

-

This driver exploits asynchronous stream over IEEE 1394 to carry - Ethernet frames. The stream channel can be specified by the - hw.firewire.fwe.stream_ch - sysctl(8).

-

This driver supports polling(4) as well if it is - compiled with the DEVICE_POLLING option.

-
-
-

-

arp(4), firewire(4), - fwip(4), fwohci(4), - netintro(4), ng_ether(4), - polling(4), ifconfig(8), - kldload(8), sysctl(8)

-
-
-

-

The fwe device driver first appeared in - FreeBSD 5.0.

-
-
-

-

The fwe driver and this manual page were - written by Hidetoshi Shimokawa.

-
-
-

-

This driver emulates Ethernet in a very adhoc way and it does not - reserve a stream channel using an isochronous manager. Note that this driver - uses a protocol which is very different from RFC 2734 (IPv4 over IEEE - 1394).

-
-
- - - - - -
July 16, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/fwip.4 3.html b/static/freebsd/man4/fwip.4 3.html deleted file mode 100644 index 0cd9c631..00000000 --- a/static/freebsd/man4/fwip.4 3.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - -
FWIP(4)Device Drivers ManualFWIP(4)
-
-
-

-

fwip — IP over - FireWire driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device firewire -
-device fwip
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
firewire_load="YES"
-if_fwip_load="YES"
-
-
-
-

-

The fwip driver provides standard IP over - FireWire (IEEE 1394) based on the protocols described in RFC 2734 and RFC - 3146.

-

The firewire(4) and fwohci(4) - drivers must be configured in the kernel as well.

-

This driver supports polling(4) as well if it is - compiled with the DEVICE_POLLING option.

-
-
-

-

arp(4), firewire(4), - fwe(4), fwohci(4), - netintro(4), polling(4), - ifconfig(8), kldload(8), - sysctl(8)

-
-
-

-

The fwip device driver first appeared in - FreeBSD 5.3.

-
-
-

-

The fwip driver and this manual page were - written by Doug Rabson, based on earlier work by - Hidetoshi Shimokawa.

-
-
-

-

This driver currently does not support the MCAP protocol for - multicast IP over FireWire. Multicast packets are treated as broadcast - packets which is sufficient for most trivial uses of multicast.

-
-
- - - - - -
July 16, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/fwohci.4 3.html b/static/freebsd/man4/fwohci.4 3.html deleted file mode 100644 index 3139e409..00000000 --- a/static/freebsd/man4/fwohci.4 3.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - -
FWOHCI(4)Device Drivers ManualFWOHCI(4)
-
-
-

-

fwohci — OHCI - FireWire chipset device driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device firewire
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
firewire_load="YES"
-
-

To disable physical access (see - BUGS section for detail), put the following - line in loader.conf(5):

-
-
hw.firewire.phydma_enable=0
-
-
-
-

-

The fwohci driver provides support for - PCI/CardBus FireWire interface cards. The driver supports the following IEEE - 1394 OHCI chipsets:

-

-
    -
  • Adaptec AHA-894x/AIC-5800
    • -
  • Apple Pangea
    • -
  • Apple UniNorth
    • -
  • Intel 82372FB
    • -
  • IOGEAR GUF320
    • -
  • Lucent / Agere FW322/323
    • -
  • NEC uPD72861
    • -
  • NEC uPD72870
    • -
  • NEC uPD72871/2
    • -
  • NEC uPD72873
    • -
  • NEC uPD72874
    • -
  • National Semiconductor CS4210
    • -
  • Ricoh R5C551
    • -
  • Ricoh R5C552
    • -
  • Sony CX3022
    • -
  • Sony i.LINK (CXD3222)
    • -
  • Texas Instruments PCI4410A
    • -
  • Texas Instruments PCI4450
    • -
  • Texas Instruments PCI4451
    • -
  • Texas Instruments TSB12LV22
    • -
  • Texas Instruments TSB12LV23
    • -
  • Texas Instruments TSB12LV26
    • -
  • Texas Instruments TSB43AA22
    • -
  • Texas Instruments TSB43AB21/A/AI/A-EP
    • -
  • Texas Instruments TSB43AB22/A
    • -
  • Texas Instruments TSB43AB23
    • -
  • Texas Instruments TSB82AA2
    • -
  • VIA Fire II (VT6306)
    • -
-
-
-

-

firewire(4), fwe(4), - fwip(4), sbp(4), - fwcontrol(8), kldload(8)

-
-
-

-

The fwohci device driver first appeared in - FreeBSD 5.0.

-
-
-

-

The fwohci device driver was written by - Katsushi Kobayashi and Hidetoshi - Shimokawa.

-
-
-

-

The driver allows physical access from any nodes on the bus by - default. This means that any devices on the bus can read and modify any - memory space which can be accessed by an IEEE 1394 OHCI chip. It is allowed - mostly for sbp(4) devices. This should be changed to allow - it only for specific devices. Anyway, FireWire is a bus and not expected to - be connected with un-trustable devices because a node can monitor all the - traffic.

-
-
- - - - - -
December 24, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/fxp.4 3.html b/static/freebsd/man4/fxp.4 3.html deleted file mode 100644 index aef306f3..00000000 --- a/static/freebsd/man4/fxp.4 3.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - -
FXP(4)Device Drivers ManualFXP(4)
-
-
-

-

fxp — Intel - EtherExpress PRO/100 Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device fxp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_fxp_load="YES"
-
-
-
-

-

The fxp driver provides support for - Ethernet adapters based on the Intel i82557, i82558, i82559, i82550, and - i82562 chips. The driver supports TCP/UDP/IP checksum offload for both - transmit and receive on i82550 and i82551. On i82559 only TCP/UDP checksum - offload for receive is supported. TCP segmentation offload (TSO) for IPv4 as - well as VLAN hardware tag insertion/stripping is supported on i82550 and - i82551. Wake On Lan (WOL) support is provided on all controllers except - i82557, i82259ER and early i82558 revisions.

-

The fxp driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The autoselected mode - can be overridden by adding the media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-

The fxp driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

Note that 100baseTX media type is not available on the Pro/10. For - further information on configuring this device, see - ifconfig(8).

-

The fxp driver supports reception and - transmission of extended frames for vlan(4). This - capability of fxp can be controlled by means of the - vlanmtu parameter to - ifconfig(8).

-

The fxp driver also supports a special - link option:

-
-
-
Some chip revisions have loadable microcode which can be used to reduce - the interrupt load on the host cpu. Not all boards have microcode support. - Setting the link0 flag with - ifconfig(8) will download the microcode to the chip if - it is available.
-
-
-
-

-

Adapters supported by the fxp driver - include:

-

-
    -
  • Intel EtherExpress PRO/10
    • -
  • Intel InBusiness 10/100
    • -
  • Intel PRO/100B / EtherExpressPRO/100 B PCI Adapter
    • -
  • Intel PRO/100+ Management Adapter
    • -
  • Intel PRO/100 VE Desktop Adapter
    • -
  • Intel PRO/100 VM Network Connection
    • -
  • Intel PRO/100 M Desktop Adapter
    • -
  • Intel PRO/100 S Desktop, Server and Dual-Port Server Adapters
    • -
  • Many on-board network interfaces on Intel motherboards
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). The - following variables are available as both loader(8) - tunables and sysctl(8) variables:

-
-
dev.fxp.%d.int_delay
-
Maximum amount of time, in microseconds, that an interrupt may be delayed - in an attempt to coalesce interrupts. This is only effective if the Intel - microcode is loaded. The accepted range is 300 to 3000, the default is - 1000.
-
dev.fxp.%d.bundle_max
-
Number of packets that will be bundled, before an interrupt is generated. - This is only effective if the Intel microcode is loaded. The accepted - range is 1 to 65535, the default is 6.
-
-
-
-

-

The following variables are available as - sysctl(8) variables.

-
-
dev.fxp.%d.rnr
-
This is a read-only variable and shows the number of events of RNR - (resource not ready).
-
dev.fxp.%d.stats
-
This is a read-only variable and displays useful MAC counters maintained - in the driver.
-
-
-
-

-
-
fxp%d: couldn't map memory
-
A fatal initialization error has occurred.
-
fxp%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
fxp%d: Failed to malloc memory
-
There are not enough mbuf's available for allocation.
-
fxp%d: device timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
fxp%d: Microcode loaded, int_delay: %d usec bundle_max: %d
-
The chip has successfully downloaded the microcode, and changed the - parameterized values to the given settings.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-
-
-

-

The fxp device driver first appeared in - FreeBSD 2.1.

-
-
-

-

The fxp device driver was written by - David Greenman. It has then been updated to use the - busdma API and made endian-clean by Maxime Henrion. - This manual page was written by David E. - O'Brien.

-
-
- - - - - -
November 26, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/gdb.4 3.html b/static/freebsd/man4/gdb.4 3.html deleted file mode 100644 index c4f340ef..00000000 --- a/static/freebsd/man4/gdb.4 3.html +++ /dev/null @@ -1,515 +0,0 @@ - - - - - - -
GDB(4)Device Drivers ManualGDB(4)
-
-
-

-

gdb — external - kernel debugger

-
-
-

-

makeoptions DEBUG=-g -
- options DDB

-
-
-

-

The gdb kernel debugger is a variation of - gdb(1) (ports/devel/gdb) which - understands some aspects of the FreeBSD kernel - environment. It can be used in a number of ways:

-
    -
  • It can be used to examine the memory of the processor on which it - runs.
    • -
  • It can be used to analyse a processor dump after a panic.
    • -
  • It can be used to debug another system interactively via a serial or - firewire link. In this mode, the processor can be stopped and single - stepped.
    • -
  • With a firewire link, it can be used to examine the memory of a remote - system without the participation of that system. In this mode, the - processor cannot be stopped and single stepped, but it can be of use when - the remote system has crashed and is no longer responding.
    • -
-

When used for remote debugging, gdb - requires the presence of the ddb(4) kernel debugger. - Commands exist to switch between gdb and - ddb(4).

-
-
-

-

When debugging kernels, it is practically essential to have built - a kernel with debugging symbols (makeoptions - DEBUG=-g). It is easiest to perform operations from the kernel build - directory, by default - /usr/obj/usr/src/sys/GENERIC.

-

First, ensure you have a copy of the debug macros in the - directory:

-

-
make gdbinit
-

This command performs some transformations on the macros installed - in /usr/src/tools/debugscripts to adapt them to the - local environment.

-
-

-

To look at and change the contents of the memory of the system you - are running on,

-

-
gdb -k -wcore kernel.debug - /dev/mem
-

In this mode, you need the -k flag to - indicate to gdb(1) - (ports/devel/gdb) that the “dump file” - /dev/mem is a kernel data file. You can look at live - data, and if you include the -wcore option, you can - change it at your peril. The system does not stop (obviously), so a number - of things will not work. You can set breakpoints, but you cannot - “continue” execution, so they will not work.

-
-
-

-

By default, crash dumps are stored in the directory - /var/crash. Investigate them from the kernel build - directory with:

-

-
gdb -k kernel.debug - /var/crash/vmcore.29
-

In this mode, the system is obviously stopped, so you can only - look at it.

-
-
- -

In the following discussion, the term “local system” - refers to the system running the debugger, and “remote system” - refers to the live system being debugged.

-

To debug a live system with a remote link, the kernel must be - compiled with the option options DDB. The option - options BREAK_TO_DEBUGGER enables the debugging - machine stop the debugged machine once a connection has been established by - pressing ‘^C’.

-
-
- -

When using a serial port for the remote link on the i386 platform, - the serial port must be identified by setting the flag bit - 0x80 for the specified interface. Generally, this - port will also be used as a serial console (flag bit - 0x10), so the entry in - /boot/device.hints should be:

-

-
hint.sio.0.flags="0x90"
-
-
- -

As with serial debugging, to debug a live system with a firewire - link, the kernel must be compiled with the option options - DDB.

-

A number of steps must be performed to set up a firewire link:

-
    -
  • Ensure that both systems have firewire(4) support, and - that the kernel of the remote system includes the - dcons(4) and dcons_crom(4) drivers. If - they are not compiled into the kernel, load the KLDs: -

    -
    kldload firewire
    -

    On the remote system only:

    -
    - 
    kldload dcons
-kldload dcons_crom
    -
    -

    You should see something like this in the - dmesg(8) output of the remote system:

    -
    - 
    fwohci0: BUS reset
-fwohci0: node_id=0x8800ffc0, gen=2, non CYCLEMASTER mode
-firewire0: 2 nodes, maxhop <= 1, cable IRM = 1
-firewire0: bus manager 1
-firewire0: New S400 device ID:00c04f3226e88061
-dcons_crom0: <dcons configuration ROM> on firewire0
-dcons_crom0: bus_addr 0x22a000
    -
    -

    It is a good idea to load these modules at boot time with the - following entry in /boot/loader.conf:

    -

    -
    dcons_crom_enable="YES"
    -

    This ensures that all three modules are loaded. There is no - harm in loading dcons(4) and - dcons_crom(4) on the local system, but if you only - want to load the firewire(4) module, include the - following in /boot/loader.conf:

    -

    -
    firewire_enable="YES"
    -
    • -
  • Next, use fwcontrol(8) to find the firewire node - corresponding to the remote machine. On the local machine you might see: -
    - 
    # fwcontrol
-2 devices (info_len=2)
-node        EUI64        status
-   1  0x00c04f3226e88061      0
-   0  0x000199000003622b      1
    -
    -

    The first node is always the local system, so in this case, - node 0 is the remote system. If there are more than two systems, check - from the other end to find which node corresponds to the remote system. - On the remote machine, it looks like this:

    -
    - 
    # fwcontrol
-2 devices (info_len=2)
-node        EUI64        status
-   0  0x000199000003622b      0
-   1  0x00c04f3226e88061      1
    -
    -
    • -
  • Next, establish a firewire connection with dconschat(8): -

    -
    dconschat -br -G 5556 -t - 0x000199000003622b
    -

    0x000199000003622b is the EUI64 - address of the remote node, as determined from the output of - fwcontrol(8) above. When started in this manner, - dconschat(8) establishes a local tunnel connection - from port localhost:5556 to the remote debugger. - You can also establish a console port connection with the - -C option to the same invocation - dconschat(8). See the dconschat(8) - manpage for further details.

    -

    The dconschat(8) utility does not return - control to the user. It displays error messages and console output for - the remote system, so it is a good idea to start it in its own - window.

    -
    • -
  • Finally, establish connection: -
    - 
    # gdb kernel.debug
-GNU gdb 5.2.1 (FreeBSD)
-
-Ready to go.  Enter 'tr' to connect to the remote target
-with /dev/cuau0, 'tr /dev/cuau1' to connect to a different port
-or 'trf portno' to connect to the remote target with the firewire
-interface.  portno defaults to 5556.
-
-Type 'getsyms' after connection to load kld symbols.
-
-If you are debugging a local system, you can use 'kldsyms' instead
-to load the kld symbols.  That is a less obnoxious interface.
-(gdb) trf
-0xc21bd378 in ?? ()
    -
    -

    The trf macro assumes a connection on - port 5556. If you want to use a different port (by changing the - invocation of dconschat(8) above), use the - tr macro instead. For example, if you want to - use port 4711, run dconschat(8) like this:

    -

    -
    dconschat -br -G 4711 -t - 0x000199000003622b
    -

    Then establish connection with:

    -
    - 
    (gdb) tr localhost:4711
-0xc21bd378 in ?? ()
    -
    -
    • -
-
-
- -

In addition to the conventional debugging via firewire described - in the previous section, it is possible to debug a remote system without its - cooperation, once an initial connection has been established. This - corresponds to debugging a local machine using - /dev/mem. It can be very useful if a system crashes - and the debugger no longer responds. To use this method, set the - sysctl(8) variables - hw.firewire.fwmem.eui64_hi and - hw.firewire.fwmem.eui64_lo to the upper and lower - halves of the EUI64 ID of the remote system, respectively. From the previous - example, the remote machine shows:

-
-
# fwcontrol
-2 devices (info_len=2)
-node        EUI64        status
-   0  0x000199000003622b      0
-   1  0x00c04f3226e88061      1
-
-

Enter:

-
-
# sysctl -w hw.firewire.fwmem.eui64_hi=0x00019900
-hw.firewire.fwmem.eui64_hi: 0 -> 104704
-# sysctl -w hw.firewire.fwmem.eui64_lo=0x0003622b
-hw.firewire.fwmem.eui64_lo: 0 -> 221739
-
-

Note that the variables must be explicitly stated in hexadecimal. - After this, you can examine the remote machine's state with the following - input:

-
-
# gdb -k kernel.debug /dev/fwmem0.0
-GNU gdb 5.2.1 (FreeBSD)
-
-Reading symbols from /boot/kernel/dcons.ko...done.
-Loaded symbols for /boot/kernel/dcons.ko
-Reading symbols from /boot/kernel/dcons_crom.ko...done.
-Loaded symbols for /boot/kernel/dcons_crom.ko
-#0  sched_switch (td=0xc0922fe0) at /usr/src/sys/kern/sched_4bsd.c:621
-0xc21bd378 in ?? ()
-
-

In this case, it is not necessary to load the symbols explicitly. - The remote system continues to run.

-
-
-
-

-

The user interface to gdb is via - gdb(1) (ports/devel/gdb), so - gdb(1) (ports/devel/gdb) commands - also work. This section discusses only the extensions for kernel debugging - that get installed in the kernel build directory.

-
-

-

The following macros manipulate the debugging environment:

-
-
-
Switch back to ddb(4). This command is only meaningful - when performing remote debugging.
-
-
Display kldstat information for the target machine - and invite user to paste it back in. This is required because - gdb does not allow data to be passed to shell - scripts. It is necessary for remote debugging and crash dumps; for local - memory debugging use kldsyms instead.
-
-
Read in the symbol tables for the debugging machine. This does not work - for remote debugging and crash dumps; use getsyms - instead.
-
- interface
-
Debug a remote system via the specified serial or firewire interface.
-
-
Debug a remote system via serial interface - /dev/cuau0.
-
-
Debug a remote system via serial interface - /dev/cuau1.
-
-
Debug a remote system via firewire interface at default port 5556.
-
-

The commands tr0, - tr1 and trf are convenience - commands which invoke tr.

-
-
-

-

The following macros are convenience functions intended to make - things easier than the standard gdb(1) - (ports/devel/gdb) commands.

-
-
-
Select stack frame 0 and show assembler-level details.
-
-
Select stack frame 1 and show assembler-level details.
-
-
Select stack frame 2 and show assembler-level details.
-
-
Select stack frame 3 and show assembler-level details.
-
-
Select stack frame 4 and show assembler-level details.
-
-
Select stack frame 5 and show assembler-level details.
-
-
Show 12 words in hex, starting at current ebp - value.
-
-
List the next 10 instructions from the current eip - value.
-
-
Show the register contents and the first four parameters of the current - stack frame.
-
-
Show the first parameter of current stack frame in various formats.
-
-
Show the second parameter of current stack frame in various formats.
-
-
Show the third parameter of current stack frame in various formats.
-
-
Show the fourth parameter of current stack frame in various formats.
-
-
Show the fifth parameter of current stack frame in various formats.
-
-
Show the last 12 words on stack in hexadecimal.
-
-
Show the register contents and the first ten parameters.
-
-
Single step 1 instruction (over calls) and show next instruction.
-
-
Single step 1 instruction (through calls) and show next instruction.
-
-
-
-

-

The following macros access other processes. The - gdb debugger does not understand the concept of - multiple processes, so they effectively bypass the entire - gdb environment.

-
-
- pid
-
Show a backtrace for the process pid.
-
-
Show backtraces for all processes in the system.
-
-
Show a backtrace for the process previously selected with - defproc.
-
- ebp
-
Show a backtrace from the ebp address - specified.
-
- pid
-
Specify the PID of the process for some other commands in this - section.
-
- frame
-
Show frame frame of the stack of the process - previously selected with defproc.
-
- proc
-
Show some PCB contents of the process proc.
-
-
-
-

-

You can use standard gdb(1) - (ports/devel/gdb) commands to look at most data - structures. The macros in this section are convenience functions which - typically display the data in a more readable format, or which omit less - interesting parts of the structure.

-
-
-
Show information about the buffer header pointed to by the variable - bp in the current frame.
-
-
Show the contents (char *) of - bp->data in the current frame.
-
-
Show detailed information about the buffer header (struct - bp) pointed at by the local variable bp.
-
- bp
-
Show summary information about the buffer header (struct - bp) pointed at by the parameter bp.
-
-
Print a number of fields from the buffer header pointed at in by the - pointer bp in the current environment.
-
-
Show some information of the vnode pointed to by the - local variable vp.
-
-
-
-

-
-
-
Check unallocated memory for modifications. This assumes that the kernel - has been compiled with options DIAGNOSTIC. This - causes the contents of free memory to be set to - 0xdeadc0de.
-
-
Print the system message buffer. This corresponds to the - dmesg(8) utility. This macro used to be called - msgbuf. It can take a very long time over a serial - line, and it is even slower via firewire or local memory due to - inefficiencies in gdb. When debugging a crash dump - or over firewire, it is not necessary to start gdb - to access the message buffer: instead, use an appropriate variation of -
- 
dmesg -M /var/crash/vmcore.0 -N kernel.debug
-dmesg -M /dev/fwmem0.0 -N kernel.debug
-
-
-
-
Equivalent of the kldstat(8) utility without - options.
-
-
Print the command name of the current process.
-
-
Show process status. This corresponds in concept, but not in appearance, - to the ps(1) utility. When debugging a crash dump or - over firewire, it is not necessary to start gdb to - display the ps(1) output: instead, use an appropriate - variation of -
- 
ps -M /var/crash/vmcore.0 -N kernel.debug
-ps -M /dev/fwmem0.0 -N kernel.debug
-
-
-
-
Kludge for writing macros. When writing macros, it is convenient to paste - them back into the gdb window. Unfortunately, if - the macro is already defined, gdb insists on - asking -

-
Redefine foo?
-

It will not give up until you answer - ‘y’. This command is that answer. - It does nothing else except to print a warning message to remind you to - remove it again.

-
-
-
-
-
-

-

gdb(1) - (ports/devel/gdb), ps(1), - ddb(4), firewire(4), - dconschat(8), dmesg(8), - fwcontrol(8), kldload(8)

-
-
-

-

This man page was written by Greg Lehey - <grog@FreeBSD.org>.

-
-
-

-

The gdb(1) - (ports/devel/gdb) debugger was never designed to - debug kernels, and it is not a very good match. Many problems exist.

-

The gdb implementation is very - inefficient, and many operations are slow.

-

Serial debugging is even slower, and race conditions can make it - difficult to run the link at more than 9600 bps. Firewire connections do not - have this problem.

-

The debugging macros “just grew.” In general, the - person who wrote them did so while looking for a specific problem, so they - may not be general enough, and they may behave badly when used in ways for - which they were not intended, even if those ways make sense.

-

Many of these commands only work on the ia32 architecture.

-
-
- - - - - -
May 17, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/gem.4 3.html b/static/freebsd/man4/gem.4 3.html deleted file mode 100644 index 6d6c66dd..00000000 --- a/static/freebsd/man4/gem.4 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
GEM(4)Device Drivers ManualGEM(4)
-
-
-

-

gem — GEM/GMAC - Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device gem
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_gem_load="YES"
-
-
-
-

-

The gem driver provides support for the - GMAC Ethernet hardware found mostly in the last Apple PowerBooks G3s and - most G4-based Apple hardware.

-

All controllers supported by the gem - driver have TCP checksum offload capability for both receive and transmit, - support for the reception and transmission of extended frames for - vlan(4) and a 512-bit multicast hash filter.

-
-
-

-

Chips supported by the gem driver - include:

-

-
    -
  • Apple GMAC
    • -
  • Sun GEM Gigabit Ethernet
    • -
-

The following add-on cards are known to work with the - gem driver at this time:

-

-
    -
  • Sun Gigabit Ethernet PCI 2.0/3.0 (GBE/P) (part no. 501-4373)
    • -
-
-
-

-

altq(4), miibus(4), - netintro(4), vlan(4), - ifconfig(8)

-
-
-

-

The gem device driver appeared in - NetBSD 1.6. The first - FreeBSD version to include it was - FreeBSD 5.0.

-
-
-

-

The gem driver was written for - NetBSD by Eduardo Horvath - <eeh@NetBSD.org>. It - was ported to FreeBSD by Thomas - Moestl - <tmm@FreeBSD.org> and - later on improved by Marius Strobl - <marius@FreeBSD.org>. - The man page was written by Thomas Klausner - <wiz@NetBSD.org>.

-
-
- - - - - -
April 18, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/genet.4 3.html b/static/freebsd/man4/genet.4 3.html deleted file mode 100644 index c23fd109..00000000 --- a/static/freebsd/man4/genet.4 3.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - -
GENET(4)Device Drivers Manual (aarch64)GENET(4)
-
-
-

-

genet — Raspberry - Pi 4 / BCM2711 Gigabit Ethernet controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in the kernel configuration file:

-
device miibus -
-device genet
-
-
-

-

The genet driver supports the BCM2711 - Ethernet controller as found on the Raspberry Pi 4.

-

The following features are supported in the - genet driver in FreeBSD:

-

-
    -
  • IP/TCP/UDP checksum offload for IPv4 and IPv6
    • -
  • 10/100/1000Mbps operation in full-duplex mode
    • -
  • 10/100Mbps operation in half-duplex mode
    • -
-

Note that the operation of transmit checksum offload is coupled - for IPv4 and IPv6; to disable it, both must be disabled even if both address - families are not in use.

-

The genet driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseT operation over twisted pair. Only - full-duplex mode is supported.
-
-

The genet driver supports the following - media options set with the mediaopt option to the - ifconfig(8) command:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The genet driver supports the Ethernet - controller portion of the Broadcom BCM2711 on the Raspberry Pi 4 Model B and - related systems. It utilizes the BCM54213PE PHY.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). The - following loader tunable variable is available, and is also available as a - read-only sysctl(8) variable:

-
-
hw.genet.rx_batch
-
The maximum number of packets to pass to the link-layer input routine at - one time. The default is 16.
-
-
-
-

-

The following variable is available as a - sysctl(8) variable:

-
-
hw.genet.tx_hdr_min
-
When the driver is given an output packet in a buffer chain in which the - first buffer contains only the Ethernet header, the number of bytes of the - packet to add to the Ethernet header in the first buffer. Certain packets - may be lost if this value is too small. The default value is 56, and is - sufficient for the observed cases to date.
-
-
-
-

-

The genet driver has no diagnostics that - are likely in normal operation. However, when the - debug option is set with - ifconfig(8), most failures that cause packet loss in the - transmit and receive paths cause a cryptic diagnostic message naming the - failure. These messages generally make sense only when looking at the driver - source.

-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The genet device driver first appeared in - FreeBSD 13.0.

-
-
-

-

The genet driver was written by - Mike Karels - <karels@freebsd.org>. - Portions are derived from the bcmgenet driver in - NetBSD by Jared McNeill, and parts of the structure - and common code are from the awg driver for the Allwinner EMAC by Jared - McNeill.

-
-
- - - - - -
December 8, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/genetlink.4 3.html b/static/freebsd/man4/genetlink.4 3.html deleted file mode 100644 index df0a66c7..00000000 --- a/static/freebsd/man4/genetlink.4 3.html +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - -
GENETLINK(4)Device Drivers ManualGENETLINK(4)
-
-
-

-

genetlink — - Generic Netlink

-
-
-

-

#include - <netlink/netlink.h> -
- #include - <netlink/netlink_generic.h>

-

int -
- socket(AF_NETLINK, - SOCK_DGRAM, - NETLINK_GENERIC);

-
-
-

-

The NETLINK_GENERIC is a - "container" family, used for dynamic registration of other - families belonging to the various subsystems. These subsystems provide a - string family name during registration and receive a dynamically-allocated - family id. Allocated family identifiers are then used by applications to get - access to functions provided by that subsystem via netlink. There are - standard methods for resolving string family names to family identifiers. A - similar mechanism works for the notification groups provided by those - families.

-

All generic netlink families share a common header:

-
-
struct genlmsghdr {
-	uint8_t		cmd;		/* command within the family */
-	uint8_t		version;	/* ABI version for the cmd */
-	uint16_t	reserved;	/* reserved: set to 0 */
-};
-
-The family id is encoded in the nlmsg_type of the base - netlink header. The cmd field is the command identifier - within the family. The version field is the command - version. -
-
-

-

The generic Netlink framework provides the base family, - GENL_ID_CTRL ("nlctrl") with a fixed - family id. This family is used to list the details of all registered - families.

-

The following messages are supported by the framework:

-
-

-

Fetches a single family or all registered families, depending on - the NLM_F_DUMP flag. Each family is reported as - CTRL_CMD_NEWFAMILY message. The following filters - are recognised by the kernel:

-

-
-
CTRL_ATTR_FAMILY_ID	(uint16_t) current family id assigned by kernel
-CTRL_ATTR_FAMILY_NAME	(string) family name
-
-
-
-

-
-
-
(uint16_t) Dynamically-assigned family identifier.
-
-
(string) Family name.
-
-
(uint32_t) Family mandatory header size (typically 0).
-
-
(uint32_t) Maximum attribute number valid for the family.
-
-
(nested) List of the operations supported by the family. The attribute - consists of a list of nested TLVs, with attribute values monotonically - incremented, starting from 0. The following attributes are present in each - TLV: -
-
-
Operation (message) number.
-
-
Operation flags. The following flags are supported: -
- 
GENL_ADMIN_PERM		requires elevated permissions
-GENL_CMD_CAP_DO		operation is a modification request
-GENL_CMD_CAP_DUMP	operation is a get/dump request
-
-
-
-
-
-
(nested) List of the notification groups supported by the family. The - attribute consists of a list of nested TLVs, with attribute values - monotonically incremented, starting from 0. The following attributes are - present in each TLV: -
-
-
Group id that can be used in - NETLINK_ADD_MEMBERSHIP - setsockopt(2).
-
-
(string) Human-readable name of the group.
-
-
-
-
-
-

-

The following groups are defined:

-
-
"notify"	Notifies on family registrations/removal.
-
-
-
-
-

-

snl(3), netlink(4)

-
-
-

-

The NETLINK_GENERIC protocol family - appeared in FreeBSD 13.2.

-
-
-

-

The netlink was implemented by Alexander - Chernikov - <melifaro@FreeBSD.org>. - It was derived from the Google Summer of Code 2021 project by - Ng Peng Nam Sean.

-
-
- - - - - -
November 1, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/geneve.4 3.html b/static/freebsd/man4/geneve.4 3.html deleted file mode 100644 index f01e9c73..00000000 --- a/static/freebsd/man4/geneve.4 3.html +++ /dev/null @@ -1,279 +0,0 @@ - - - - - - -
GENEVE(4)Device Drivers ManualGENEVE(4)
-
-
-

-

geneve — Generic - Network Virtualization Encapsulation interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file: -
- device geneve

-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5): -
- if_geneve_load="YES"

-
-
-

-

The geneve driver creates a generic - network virtualization tunnel interfaces for Tentant Systems over an L3 - (IP/UDP) underlay network that provides a Layer 2 (ethernet) or Layer 3 - service using geneve protocol.

-

This driver corresponds to RFC 8926 for format specification and - by default uses the multicast-learning-based approach for its control plane. - To provide control plane independence all of the driver-specific operations - are implemented using rtnetlink(4) and all the - ioctl(2) calls are implemented using the - nv(9) library. Each geneve - interface is created at runtime using interface cloning. This is most easily - done with the ifconfig(8) create - command or using the cloned_interfaces variable in - rc.conf(5). The interface may be removed with the - ifconfig(8) destroy command.

-

The geneve interface must be configured in - either L2 or L3 mode. An L2 geneve tunnel could be - used as a backplane between the virtual switches residing in hypervisors, - switches, or other appliances.

-

The L3 geneve tunnel provides virtualized - IP forwarding service similar to IP/VRF.

-

By default the geneve driver creates an L2 - interface that supports the usual network ioctl(2)s and - thus can be used with ifconfig(8) like any other Ethernet - interface. An L2 geneve interface encapsulates the - Ethernet frame by prepending IP/UDP and geneve - headers. Thus, the encapsulated (inner) frame is able to be transmitted over - a routed, Layer 3 network to the remote host.

-

The geneve interface may be configured in - either unicast or multicast mode. When in unicast mode, the interface - creates a tunnel to a single remote host, and all traffic is transmitted to - that host. When in multicast mode, the interface joins an IP multicast - group, and receives packets sent to the group address, and transmits packets - to either the multicast group address, or directly to the remote host if - there is an appropriate forwarding table entry.

-

When the geneve interface is brought up, a - udp(4) socket(9) is created based on the - configuration, such as the local address for unicast mode or the group - address for multicast mode, and the listening (local) port number. Since - multiple geneve interfaces may be created that - either use the same local address or join the same group address, and use - the same port, the driver may share a socket among multiple interfaces. - However, each interface within a socket must belong to a unique - geneve segment per vnet(9). The - analogous vlan(4) configuration would be a physical - interface configured as the parent device for multiple VLAN interfaces, each - with a unique VLAN tag. Each geneve segment is - identified by a 24-bit value in the geneve header - called the “Virtual Network Identifier”, or VNI. This value - can be set with ifconfig(8) - geneveid parameter.

-

When configured with the ifconfig(8) - genevelearn parameter, the interface dynamically - creates forwarding table entries from received packets. An entry in the - forwarding table maps the inner source MAC address to the outer remote IP - address. During transmit, the interface attempts to lookup an entry for the - encapsulated destination MAC address. If an entry is found, the IP address - in the entry is used to directly transmit the encapsulated frame to the - destination. Otherwise, when configured in multicast mode, the interface - must flood the frame to all hosts in the group. The maximum number of - entries in the table is configurable with the ifconfig(8) - genevemaxaddr command. Stale entries in the table - are periodically pruned. The timeout is configurable with the - ifconfig(8) genevetimeout - command.

-
-

-

Since the geneve interface encapsulates - the Ethernet frame with an IP, UDP, and geneve - header, the resulting frame may be larger than the MTU of the physical - network. The geneve specification recommends the - physical network MTU be configured to use jumbo frames to accommodate the - encapsulated frame size.

-

By default, the geneve driver sets its MTU - to usual ethernet MTU of 1500 bytes, reduced by the size of geneve headers - prepended which is depends on genevemode.

-

Alternatively, the ifconfig(8) - mtu command may be used to set the fixed MTU size on - the geneve interface to allow the encapsulated frame - to fit in the current MTU of the physical network. If the - mtu command was used, system no longer adjust the - geneve interface MTU on routing or address - changes.

-
-
-

-

TTL value of geneve interface can change - by using the ifconfig(8) genevettl - command and it also can be inherited from carrying packet. You can set the - genevettl to a number value or - inherit option to be inherited at the encapsulation - and decapsulation point.

-
-
-

-

Just like the TTL value, ToS value can be inherited at the - encapsulation point using ifconfig(8) - genevedscpinherit. As defined in RFC 8926, ECN value - follows the RFC 6040 for both ingress and egress traffic.

-
-
-

-

To make sure fragmentation does not happing during transmission, - you can set the ifconfig(8) - genevedf value to set value - which sets the DF bit on IPv4 header and IP_DONTFRAG option on both IPv4 and - IPv6 sockets. Similar to other options, it can be set to - inherit value.

-
-
-

-

To create the geneve interface with - multicast underlay, one must use ifconfig(8) - genevegroup instead of - geneveremote and set it to a multicast address (e.g. - ff08::db8:0:1, 239.0.0.1). One can set the outbound multicast interface with - ifconfig(8) genevedev to bound its - multicast group to specific interface.

-

The ip_mroute kernel module for IPv4 - underlay and ip6_mroute for IPv6 underlay must be - loaded for multicast(4) to function.

-
-
-
-

-

The geneve driver supports hardware - checksum offload (receive and transmit) and TSO on the encapsulated traffic - over physical interfaces that support these features. The - geneve interface examines the - genevedev interface, if one is specified, or the - interface hosting the genevelocal address, and - configures its capabilities based on the hardware offload capabilities of - that physical interface. If multiple physical interfaces will transmit or - receive traffic for the geneve then they all must - have the same hardware capabilities. The transmit routine of a - geneve interface may fail with - ENXIO if an outbound physical interface does not - support an offload that the geneve interface is - requesting. This can happen if there are multiple physical interfaces - involved, with different hardware capabilities, or an interface capability - was disabled after the geneve interface had already - started.

-
-
-

-
-
       Host A (198.51.100.10)
-       +--------------------+
-       | VNI 100 10.1.1.0/24|
-       | VNI 200 10.2.2.0/24|
-       +---------+----------+
-                 |
-         (198.51.100.0/24)
-                 |
- +---------------v---------------+
- | Host B (203.0.113.1)          |
- |        +------+-------+       |
- | geneve0|              |geneve1|
- | +------v----+   +-----v-----+ |
- | | bridge0   |   | bridge1   | |
- | | (VNI 100) |   | (VNI 200) | |
- | +------+----+   +----+------+ |
- |        |             |        |
- +--------v-------------v--------+
-   epair0b|             |epair1b
-   +------+----+   +----+------+
-   | Jail A    |   | Jail B    |
-   | (10.1.1.x)|   | (10.2.2.x)|
-   +-----------+   +-----------+
-
-

Assume host A has the (external) IP address 198.51.100.10 and two - internal addresses of 10.1.1.1/24 and 10.2.2.1/24, while host B has the - external address of 203.0.113.10 and two jails with their own separate - VNET(9). the following commands will configure the - tunnel:

-

On host A, create a l2 geneve interface in - unicast mode:

-
-
ifconfig geneve0 create geneveid 100 genevelocal 198.51.100.10 geneveremote 203.0.113.1
-ifconfig geneve1 create geneveid 200 genevelocal 198.51.100.10 geneveremote 203.0.113.1
-
-

On host B:

-
-
ifconfig geneve0 create geneveid 100 genevelocal 203.0.113.1 geneveremote 198.51.100.10
-ifconfig geneve1 create geneveid 200 genevelocal 203.0.113.1 geneveremote 198.51.100.10
-ifconfig bridge0 addm geneve0 addm epair0a
-ifconfig bridge1 addm geneve1 addm epair1a
-
-

The example below demonstrate multicast configuration with - IPv6:

-
-
                      ----------- VNI 42 -----------
-                     /                              \
-2001:db8::1/64 --- Host A ------ Multicast ------- Host B --- 2001:db8::2/64
-                  3fff::1 [em0] ff08::db8:1 [em0]  3fff::2
-
-

Create a geneve interface in multicast - mode, with the genevelocal address of 3fff::1, and - the genevegroup address of ff08::db8:0:1. The em0 - interface will be used to transmit multicast packets. On host A:

-
-
ifconfig geneve0 create geneveid 42 genevelocal 3fff::1 genevegroup ff08::db8:1 genevedev em0
-
-

On host B:

-
-
ifconfig geneve0 create geneveid 42 genevelocal 3fff::2 genevegroup ff08::db8:1 genevedev em0
-
-

Once created, the geneve interface can be - configured with ifconfig(8).

-

The following when placed in the file - /etc/rc.conf will cause a geneve interface called - “geneve0” to be created, and will - configure the interface in unicast mode.

-
-
cloned_interfaces="geneve0"
-create_args_geneve0="geneveid 108 genevelocal 192.168.100.1 geneveremote 192.168.100.2"
-
-
-
-

-

inet(4), inet6(4), - multicast(4), rtnetlink(4), - vlan(4), rc.conf(5), - ifconfig(8), sysctl(8)

-

J. Gross, Ed., - I. Gross, Ed., and T. Sridhar, - Ed., Geneve: Generic Network Virtualization - Encapsulation, November 2020, - RFC 8926.

-
-
-

-

The geneve driver was written by - Seyed Pouria Mousavizadeh Tehrani - ⟨info@spmzt.net⟩

-
-
-

-

Current geneve implementation with netlink can't set geneve - options other than genevemode during interface cloning in ifconfig without - specifying the interface index.

-
-
- - - - - -
March 31, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/geom.4 3.html b/static/freebsd/man4/geom.4 3.html deleted file mode 100644 index 51c52e01..00000000 --- a/static/freebsd/man4/geom.4 3.html +++ /dev/null @@ -1,375 +0,0 @@ - - - - - - -
GEOM(4)Device Drivers ManualGEOM(4)
-
-
-

-

GEOM — modular - disk I/O request transformation framework

-
-
-

-

options GEOM_CACHE -
- options GEOM_CONCAT -
- options GEOM_ELI -
- options GEOM_GATE -
- options GEOM_JOURNAL -
- options GEOM_LABEL -
- options GEOM_LINUX_LVM -
- options GEOM_MAP -
- options GEOM_MIRROR -
- options GEOM_MOUNTVER -
- options GEOM_MULTIPATH -
- options GEOM_NOP -
- options GEOM_PART_APM -
- options GEOM_PART_BSD -
- options GEOM_PART_BSD64 -
- options GEOM_PART_EBR -
- options GEOM_PART_EBR_COMPAT -
- options GEOM_PART_GPT -
- options GEOM_PART_LDM -
- options GEOM_PART_MBR -
- options GEOM_RAID -
- options GEOM_RAID3 -
- options GEOM_SHSEC -
- options GEOM_STRIPE -
- options GEOM_UZIP -
- options GEOM_VIRSTOR -
- options GEOM_ZERO

-
-
-

-

The GEOM framework provides an - infrastructure in which “classes” can perform transformations - on disk I/O requests on their path from the upper kernel to the device - drivers and back.

-

Transformations in a GEOM context range - from the simple geometric displacement performed in typical disk - partitioning modules over RAID algorithms and device multipath resolution to - full blown cryptographic protection of the stored data.

-

Compared to traditional “volume management”, - GEOM differs from most and in some cases all - previous implementations in the following ways:

-
    -
  • GEOM is extensible. It is trivially simple to - write a new class of transformation and it will not be given stepchild - treatment. If someone for some reason wanted to mount IBM MVS diskpacks, a - class recognizing and configuring their VTOC information would be a - trivial matter.
    • -
  • GEOM is topologically agnostic. Most volume - management implementations have very strict notions of how classes can fit - together, very often one fixed hierarchy is provided, for instance, - subdisk - plex - volume.
    • -
-

Being extensible means that new transformations are treated no - differently than existing transformations.

-

Fixed hierarchies are bad because they make it impossible to - express the intent efficiently. In the fixed hierarchy above, it is not - possible to mirror two physical disks and then partition the mirror into - subdisks, instead one is forced to make subdisks on the physical volumes and - to mirror these two and two, resulting in a much more complex configuration. - GEOM on the other hand does not care in which order - things are done, the only restriction is that cycles in the graph will not - be allowed.

-
-
-

-

GEOM is quite object oriented and - consequently the terminology borrows a lot of context and semantics from the - OO vocabulary:

-

A “class”, represented by the data structure - g_class implements one particular kind of - transformation. Typical examples are MBR disk partition, BSD disklabel, and - RAID5 classes.

-

An instance of a class is called a “geom” and - represented by the data structure g_geom. In a typical - i386 FreeBSD system, there will be one geom of class - MBR for each disk.

-

A “provider”, represented by the data structure - g_provider, is the front gate at which a geom offers - service. A provider is “a disk-like thing which appears in - /dev” - a logical disk in other words. All - providers have three main properties: “name”, - “sectorsize” and “size”.

-

A “consumer” is the backdoor through which a geom - connects to another geom provider and through which I/O requests are - sent.

-

The topological relationship between these entities are as - follows:

-
    -
  • A class has zero or more geom instances.
    • -
  • A geom has exactly one class it is derived from.
    • -
  • A geom has zero or more consumers.
    • -
  • A geom has zero or more providers.
    • -
  • A consumer can be attached to zero or one providers.
    • -
  • A provider can have zero or more consumers attached.
    • -
-

All geoms have a rank-number assigned, which is used to detect and - prevent loops in the acyclic directed graph. This rank number is assigned as - follows:

-
    -
  1. A geom with no attached consumers has rank=1.
    2. -
  2. A geom with attached consumers has a rank one higher than the highest rank - of the geoms of the providers its consumers are attached to.
    3. -
-
-
-

-

In addition to the straightforward attach, which attaches a - consumer to a provider, and detach, which breaks the bond, a number of - special topological maneuvers exists to facilitate configuration and to - improve the overall flexibility.

-
-
-
is a process that happens whenever a new class or new provider is created, - and it provides the class a chance to automatically configure an instance - on providers which it recognizes as its own. A typical example is the MBR - disk-partition class which will look for the MBR table in the first sector - and, if found and validated, will instantiate a geom to multiplex - according to the contents of the MBR. -

A new class will be offered to all existing providers in turn - and a new provider will be offered to all classes in turn.

-

Exactly what a class does to recognize if it should accept the - offered provider is not defined by GEOM, but the - sensible set of options are:

-
    -
  • Examine specific data structures on the disk.
    • -
  • Examine properties like “sectorsize” or - “mediasize” for the provider.
    • -
  • Examine the rank number of the provider's geom.
    • -
  • Examine the method name of the provider's geom.
    • -
-

Tasting is controlled by the - kern.geom.notaste sysctl. To disable tasting, set - the sysctl to 1, to re-enable tasting, set the sysctl to 0.

-
-
-
is the process by which a provider is removed while it potentially is - still being used. -

When a geom orphans a provider, all future I/O requests will - “bounce” on the provider with an error code set by the - geom. Any consumers attached to the provider will receive notification - about the orphanization when the event loop gets around to it, and they - can take appropriate action at that time.

-

A geom which came into being as a result of a normal taste - operation should self-destruct unless it has a way to keep functioning - whilst lacking the orphaned provider. Geoms like disk slicers should - therefore self-destruct whereas RAID5 or mirror geoms will be able to - continue as long as they do not lose quorum.

-

When a provider is orphaned, this does not necessarily result - in any immediate change in the topology: any attached consumers are - still attached, any opened paths are still open, any outstanding I/O - requests are still outstanding.

-

The typical scenario is:

-

-
    -
  • A device driver detects a disk has departed and orphans the provider - for it.
    • -
  • The geoms on top of the disk receive the orphanization event and - orphan all their providers in turn. Providers which are not attached - to will typically self-destruct right away. This process continues in - a quasi-recursive fashion until all relevant pieces of the tree have - heard the bad news.
    • -
  • Eventually the buck stops when it reaches geom_dev at the top of the - stack.
    • -
  • Geom_dev will call destroy_dev(9) to stop any more - requests from coming in. It will sleep until any and all outstanding - I/O requests have been returned. It will explicitly close (i.e.: zero - the access counts), a change which will propagate all the way down - through the mesh. It will then detach and destroy its geom.
    • -
  • The geom whose provider is now detached will destroy the provider, - detach and destroy its consumer and destroy its geom.
    • -
  • This process percolates all the way down through the mesh, until the - cleanup is complete.
    • -
-

While this approach seems byzantine, it does provide the - maximum flexibility and robustness in handling disappearing devices.

-

The one absolutely crucial detail to be aware of is that if - the device driver does not return all I/O requests, the tree will not - unravel.

-
-
-
is a special case of orphanization used to protect against stale metadata. - It is probably easiest to understand spoiling by going through an example. -

Imagine a disk, da0, on top of which - an MBR geom provides da0s1 and - da0s2, and on top of - da0s1 a BSD geom provides - da0s1a through da0s1e, - and that both the MBR and BSD geoms have autoconfigured based on data - structures on the disk media. Now imagine the case where - da0 is opened for writing and those data - structures are modified or overwritten: now the geoms would be operating - on stale metadata unless some notification system can inform them - otherwise.

-

To avoid this situation, when the open of - da0 for write happens, all attached consumers - are told about this and geoms like MBR and BSD will self-destruct as a - result. When da0 is closed, it will be offered - for tasting again and, if the data structures for MBR and BSD are still - there, new geoms will instantiate themselves anew.

-

Now for the fine print:

-

If any of the paths through the MBR or BSD module were open, - they would have opened downwards with an exclusive bit thus rendering it - impossible to open da0 for writing in that case. - Conversely, the requested exclusive bit would render it impossible to - open a path through the MBR geom while da0 is - open for writing.

-

From this it also follows that changing the size of open geoms - can only be done with their cooperation.

-

Finally: the spoiling only happens when the write count goes - from zero to non-zero and the retasting happens only when the write - count goes from non-zero to zero.

-
-
-
is the process where the administrator issues instructions for a - particular class to instantiate itself. There are multiple ways to express - intent in this case - a particular provider may be specified with a level - of override forcing, for instance, a BSD disklabel module to attach to a - provider which was not found palatable during the TASTE operation. -

Finally, I/O is the reason we even do this: it concerns itself - with sending I/O requests through the graph.

-
-
,
-
represented by struct bio, originate at a consumer, - are scheduled on its attached provider and, when processed, are returned - to the consumer. It is important to realize that the - struct bio which enters through the provider of a - particular geom does not “come out on the other side”. Even - simple transformations like MBR and BSD will clone the - struct bio, modify the clone, and schedule the clone - on their own consumer. Note that cloning the struct - bio does not involve cloning the actual data area specified in the - I/O request. -

In total, four different I/O requests exist in - GEOM: read, write, delete, and “get - attribute”.

-

Read and write are self explanatory.

-

Delete indicates that a certain range of data is no longer - used and that it can be erased or freed as the underlying technology - supports. Technologies like flash adaptation layers can arrange to erase - the relevant blocks before they will become reassigned and cryptographic - devices may want to fill random bits into the range to reduce the amount - of data available for attack.

-

It is important to recognize that a delete indication is not a - request and consequently there is no guarantee that the data actually - will be erased or made unavailable unless guaranteed by specific geoms - in the graph. If “secure delete” semantics are required, a - geom should be pushed which converts delete indications into (a sequence - of) write requests.

-

“Get attribute” supports inspection and - manipulation of out-of-band attributes on a particular provider or path. - Attributes are named by ASCII strings and they will be discussed in a - separate section below.

-
-
-

(Stay tuned while the author rests his brain and fingers: more to - come.)

-
-
-

-

Several flags are provided for tracing - GEOM operations and unlocking protection mechanisms - via the kern.geom.debugflags sysctl. All of these - flags are off by default, and great care should be taken in turning them - on.

-
-
0x01 (G_T_TOPOLOGY)
-
Provide tracing of topology change events.
-
0x02 (G_T_BIO)
-
Provide tracing of buffer I/O requests.
-
0x04 (G_T_ACCESS)
-
Provide tracing of access check controls.
-
0x08 (unused)
-
 
-
0x10 (allow foot shooting)
-
Allow writing to Rank 1 providers. This would, for example, allow the - super-user to overwrite the MBR on the root disk or write random sectors - elsewhere to a mounted disk. The implications are obvious.
-
0x40 (G_F_DISKIOCTL)
-
This is unused at this time.
-
0x80 (G_F_CTLDUMP)
-
Dump contents of gctl requests.
-
-
-
-

-

libgeom(3), geom(8), - DECLARE_GEOM_CLASS(9), disk(9), - g_access(9), g_attach(9), - g_bio(9), g_consumer(9), - g_data(9), g_event(9), - g_geom(9), g_provider(9), - g_provider_by_name(9)

-
-
-

-

This software was initially developed for the - FreeBSD Project by Poul-Henning - Kamp and NAI Labs, the Security Research Division of Network - Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 - (“CBOSS”), as part of the DARPA CHATS research program.

-

The following obsolete GEOM components - were removed in FreeBSD 13.0:

-
    -
  • GEOM_BSD,
    • -
  • GEOM_FOX,
    • -
  • GEOM_MBR,
    • -
  • GEOM_SUNLABEL, and
    • -
  • GEOM_VOL.
    • -
-

Use

-
    -
  • GEOM_PART_BSD,
    • -
  • GEOM_MULTIPATH,
    • -
  • GEOM_PART_MBR, and
    • -
  • GEOM_LABEL
    • -
-options, respectively, instead. -
-
-

-

Poul-Henning Kamp - <phk@FreeBSD.org>

-
-
- - - - - -
July 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/geom_linux_lvm.4 3.html b/static/freebsd/man4/geom_linux_lvm.4 3.html deleted file mode 100644 index 3b494baf..00000000 --- a/static/freebsd/man4/geom_linux_lvm.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
GEOM_LINUX_LVM(4)Device Drivers ManualGEOM_LINUX_LVM(4)
-
-
-

-

geom_linux_lvm — - GEOM based Linux LVM logical volume mapping

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
options - GEOM_LINUX_LVM
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
geom_linux_lvm_load="YES"
-
-
-
-

-

The geom_linux_lvm framework provides - support for mapping Linux LVM volumes to GEOM providers. - geom_linux_lvm currently supports linear stripes - with segments on one or more physical disks. The parser is able to read LVM2 - Text Format metadata, the logical volumes will be assembled and made - available under /dev/linux_lvm/. The metadata is - read-only, logical volumes cannot be allocated or resized.

-
-
-

-

To view which geom_linux_lvm devices are - available:

-
-
# geom linux_lvm list
-Geom name: vg1
-Providers:
-1. Name: linux_lvm/vg1-home
-   Mediasize: 4294967296 (4.0G)
-   Sectorsize: 512
-   Mode: r0w0e0
-2. Name: linux_lvm/vg1-logs
-   Mediasize: 4294967296 (4.0G)
-   Sectorsize: 512
-   Mode: r0w0e0
-Consumers:
-1. Name: ada0s1
-   Mediasize: 80023716864 (75G)
-   Sectorsize: 512
-   Mode: r0w0e0
-
-
-
-

-

GEOM(4), geom(8)

-
-
-

-

The geom_linux_lvm driver was written by - Andrew Thompson - <thompsa@FreeBSD.org>.

-
-
- - - - - -
October 1, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/geom_uzip.4 3.html b/static/freebsd/man4/geom_uzip.4 3.html deleted file mode 100644 index 9d13a904..00000000 --- a/static/freebsd/man4/geom_uzip.4 3.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - -
GEOM_UZIP(4)Device Drivers ManualGEOM_UZIP(4)
-
-
-

-

geom_uzip — GEOM - based compressed disk images and partitions

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device xz -
-options zstd -
-options GEOM_UZIP
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
geom_uzip_load="YES"
-
-
-
-

-

The geom_uzip framework provides support - for compressed read-only disk images. This allows significant storage - savings at the expense of some CPU time on each read. Data written in the - GEOM label area allows geom_uzip to detect - compressed images which have been created with mkuzip(8) - and presented to the kernel as a logical disk device via - md(4). geom_uzip creates a unique - md#.uzip device for each image.

-

geom_uzip is not limited to supporting - only md(4) images. The image can also reside on a block - device. (For example, a disk, USB flash drive, DVD-ROM, etc). The - appropriate device node will appear with the .uzip - suffix.

-
-
# gpart show da0
-=>      0  7833600  da0  BSD  (3.7G)
-        0  2097152    1  freebsd-ufs  (1.0G)
-  2097152  5736448       - free -  (2.7G)
-# gpart add -t freebsd-ufs -s 1G da0
-da0b added
-# dd if=/tmp/20160217_dcomp_zcomp.uzip bs=256k of=/dev/da0b
-3190+1 records in
-3190+1 records out
-836331008 bytes transferred in 111.021489 secs (7533055 bytes/sec)
-# fsck -t ffs /dev/da0b.uzip
-** /dev/da0b.uzip (NO WRITE)
-** Last Mounted on /mnt
-** Phase 1 - Check Blocks and Sizes
-** Phase 2 - Check Pathnames
-** Phase 3 - Check Connectivity
-** Phase 4 - Check Reference Counts
-** Phase 5 - Check Cyl groups
-97455 files, 604242 used, 184741 free (2349 frags, 22799 blocks,
-   0.3% fragmentation)
-# mount -o ro /dev/da0b.uzip /mnt
-# df /dev/da0b.uzip
-Filesystem     1K-blocks    Used  Avail Capacity  Mounted on
-/dev/da0b.uzip   3155932 2416968 738964    77%    /mnt
-
-

The geom_uzip device is subsequently used - by FreeBSD kernel to access the uncompressed data. - The geom_uzip driver does not allow write operations - to the underlying disk image. To check which “providers” match - a given geom_uzip device:

-
-
# geom uzip list
-Geom name: md1.uzip
-Providers:
-1. Name: md1.uzip
-   Mediasize: 22003712 (21M)
-   Sectorsize: 512
-Consumers:
-1. Name: md1
-   Mediasize: 9563648 (9.1M)
-   Sectorsize: 512
-
-Geom name: da0b.uzip
-Providers:
-1. Name: da0b.uzip
-   Mediasize: 3355443200 (3.1G)
-   Sectorsize: 512
-Consumers:
-1. Name: da0b
-   Mediasize: 1073741824 (1.0G)
-   Sectorsize: 512
-
-

geom_uzip allows mounting the root file - system from a compressed disk partition by setting the - vfs.root.mountfrom tunable. See - loader.conf(5) for details.

-
-
-

-

Several flags are provided for tracing - geom_uzip I/O operations and TOC parsing via the - following sysctls.

-
-
kern.geom.uzip.debug
-
Log level. Zero disables logging. Higher values enable more verbose debug - logging for geom_uzip. Supported levels are from 0 - (no logging) to 4 (maximum amount of logging).
-
kern.geom.uzip.debug_block
-
Log operations involving compressed cluster number.
-
-
-
-

-

GEOM(4), md(4), - geom(8), mkuzip(8)

-
-
-

-

Zstd support was added in FreeBSD - 13.0.

-
-
-

-

The geom_uzip driver was written by - Max Khon - <fjoe@FreeBSD.org>. - The block de-duplication code as well as some - geom_uzip driver optimizations have been contributed - by Maxim Sobolev - <sobomax@FreeBSD.org>. - The LZMA decompression support and CLOOP 3.0 support have been added by - Aleksandr Rybalko - <ray@FreeBSD.org>.

-

This manual page was written by Ceri - Davies - <ceri@FreeBSD.org>.

-
-
- - - - - -
April 28, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/geom_zero.4 3.html b/static/freebsd/man4/geom_zero.4 3.html deleted file mode 100644 index bcb10b27..00000000 --- a/static/freebsd/man4/geom_zero.4 3.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - -
GEOM_ZERO(4)Device Drivers ManualGEOM_ZERO(4)
-
-
-

-

gzero, geom_zero - — GEOM-based zero disk/block device

-
-
-

-

options GEOM_ZERO

-

In loader.conf(5) or - sysctl.conf(5): -
- kern.geom.zero.byte -
- kern.geom.zero.clear

-
-
-

-

gzero is a GEOM(4) - device simulating a one-exabyte disk. It throws away any data written to it, - and returns the value of kern.geom.zero.byte for every - byte read from it.

-

gzero differs from - zero(4), which is a regular character device and has an - infinite length, while /dev/gzero is a - GEOM(4) provider of large, but limited, size.

-

Consult geom(8) for instructions on how to use - the supported commands of the GEOM(4) - ZERO class.

-

gzero is useful for benchmarking - performance of GEOM and GEOM classes where compression of the data does not - affect the results (blocks from /dev/gzero compress - exceptionally well). Examples of such benchmarks include comparing the speed - of two disk encryption algorithms and comparing a hardware versus software - implementation of a single encryption algorithm.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.geom.zero.byte
-
This variable sets the fill byte of the gzero - device. Default: ‘0’.
-
kern.geom.zero.clear
-
This variable controls the clearing of the read data buffer. If set to - ‘0’, gzero - will not copy any data into the read data buffers and just return the read - data buffers as they are without modifying them. In particular, it will - not fill the read buffer with the value of - kern.geom.zero.byte. This is useful for read - benchmarking to reduce the measurement noise caused by extra memory - initialization. Default: ‘1’.
-
-
-
-

-
-
/dev/gzero
-
The gzero device.
-
-
-
-

-

Create the /dev/gzero device by loading - the geom_zero kernel module:

-
-
# geom zero load
-
-

Show information about the gzero - device:

-
-
# geom zero list
-Geom name: gzero
-Providers:
-1. Name: gzero
-   Mediasize: 1152921504606846976 (1.0E)
-   Sectorsize: 512
-   Mode: r0w0egzero0
-
-

Set the fill byte of the gzero device to - 70 (decimal for letter “F” in ascii(7)):

-
-
# sysctl kern.geom.zero.byte=70
-kern.geom.zero.byte: 0 -> 70
-# head -c 1 /dev/gzero
-F
-
-

Benchmark read and write throughput of geli(8)'s - default encryption algorithm with a 4-KiB sector size:

-
-
# geom zero load
-# geli onetime -s 4096 gzero
-# sysctl kern.geom.zero.clear=0
-# dd if=/dev/gzero.eli of=/dev/zero bs=4k count=$((1024 * 256))
-262144+0 records in
-262144+0 records out
-1073741824 bytes transferred in 1.258195 secs (853398307 bytes/sec)
-# dd if=/dev/zero of=/dev/gzero.eli bs=4k count=$((1024 * 256))
-262144+0 records in
-262144+0 records out
-1073741824 bytes transferred in 1.663118 secs (645619658 bytes/sec)
-
-
-
-

-

GEOM(4), zero(4), - geom(8), sysctl(8), - bio(9)

-
-
-

-

A gzero device first appeared in - FreeBSD 6.

-
-
-

-

The gzero device was written by - Paweł Jakub Dawidek - <pjd@FreeBSD.org>.

-

The gzero manual page was originally - written by Greg White - <gkwhite@gmail.com> - and rewritten by Mateusz Piotrowski - <0mp@FreeBSD.org> - before landing in FreeBSD.

-
-
- - - - - -
November 9, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/gif.4 3.html b/static/freebsd/man4/gif.4 3.html deleted file mode 100644 index 7672ce46..00000000 --- a/static/freebsd/man4/gif.4 3.html +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - -
GIF(4)Device Drivers ManualGIF(4)
-
-
-

-

gif — generic - tunnel interface

-
-
-

-

device gif

-
-
-

-

The gif interface is a generic tunnelling - device for IPv4 and IPv6. It can tunnel IPv[46] traffic over IPv[46]. - Therefore, there can be four possible configurations. The behavior of - gif is mainly based on RFC2893 IPv6-over-IPv4 - configured tunnel. On NetBSD, - gif can also tunnel ISO traffic over IPv[46] using - EON encapsulation. Note that gif does not perform - GRE encapsulation; use gre(4) for GRE encapsulation.

-

The gif interface can also tunnel Ethernet - traffic over IPv4 or IPv6 when combined with a - if_bridge(4) interface using EtherIP protocol. See - if_bridge(4) for detailed setup.

-

Each gif interface is created at runtime - using interface cloning. This is most easily done with the - “ifconfig - create” command or using the - ifconfig_⟨interface⟩ - variable in rc.conf(5).

-

To use gif, the administrator needs to - configure the protocol and addresses used for the outer header. This can be - done by using ifconfig(8) tunnel, - or SIOCSIFPHYADDR ioctl. The administrator also - needs to configure the protocol and addresses for the inner header, with - ifconfig(8). Note that IPv6 link-local addresses (those - that start with fe80::) will be automatically - configured whenever possible. You may need to remove IPv6 link-local - addresses manually using ifconfig(8), if you want to - disable the use of IPv6 as the inner header (for example, if you need a pure - IPv4-over-IPv6 tunnel). Finally, you must modify the routing table to route - the packets through the gif interface.

-
-

-

The gif interface uses the fixed length, - 1280, to determine whether the outgoing IPv6 packets - are split. This means the MTU value configured on the interface will be - ignored when the outer protocol is IPv6. When the - NOCLAMP interface flag is set, - gif uses the same configured value as IPv4 - communications. This behavior prevents potential issues when the path MTU is - smaller than the interface MTU. This section describes the reason why the - default behavior is different. The NOCLAMP interface - flag can be set using the following command:

-

-
ifconfig gif0 - noclamp
-

and clear the flag using the following:

-

-
ifconfig gif0 - -noclamp
-

where gif0 is the actual interface name.

-

A tunnel interface always has an implicit smaller MTU for the - inner protocol than the outer protocol because of the additional header. - Note that the interface MTU on a gif interface, the - default value is 1280, is used as MTU for the outer - protocol. This means that the MTU for the inner protocol varies depending on - the outer protocol header length. If an outgoing packet bigger than the - inner protocol MTU arrives at a gif interface for - encapsulation, it will be split into fragments. Specifically, if IPv4 is - used as the outer protocol, the inner is 20 octets smaller than the - interface MTU. In the case of the default interface MTU, - 1280, inner packets bigger than - 1260 will be fragmented. In the case of IPv6, the - inner is 40 octets smaller than the outer.

-

This fragmentation is not harmful though it can degrade the - performance. Note that while an increased MTU on gif - interface helps to mitigate this reduced performance issue, it can also - cause packet losses on the intermediate narrowest path between the two - communication endpoints in IPv6. IPv6 allows fragmentation only on the - sender, not on the routers in the communication path. A big outgoing packet - will be dropped on a router with a smaller MTU.

-

In normal IPv6 communication, an ICMPv6 Packet Too Big error will - be sent back to the sender, who can adjust the packet length and re-send it. - This process is performed in the upper protocols than L3, such as TCP, and - makes the packet length shorter so that packets go through the path without - fragmentation. This behavior is known as path MTU discovery.

-

When using a gif interface, the Packet Too - Big message is generated for the outer protocol. Since the - gif interface does not translate this error to the - inner protocol, the inner protocol sees it just as a packet loss with no - useful information to adjust the length of the next packets. In this - situation, path MTU discovery does not work, and communications of the inner - protocol become stalled.

-

In order to avoid this, a gif interface - silently splits a packet of over 1240 octets into fragments to make the - outer protocol packets equal or shorter than 1280 octets, even when the - interface MTU is configured as larger than 1280. Note that this occurs only - when the outer protocol is IPv6. 1280 is the - smallest MTU in IPv6 and guarantees no packet loss occurs on intermediate - routers.

-

As mentioned earlier, the performance is sub-optimal if the actual - path MTU is larger than 1280. A typical confusing - scenario is as follows. The gif interface can have - Ethernet, whose MTU is usually 1500, as the inner protocol. It is called an - EtherIP tunnel, and can be configured by adding the - gif interface as a member of - if_bridge(4) interface. The if_bridge(4) - interface forcibly changes the MTU of the gif - interface with those for the other member interfaces, which are likely 1500. - In this case, a situation in which the MTU of the - gif interface is 1500 but fragmentation in 1280 - octets always occurs.

-

The default behavior is most conservative to prevent confusing - packet loss. Depending on the network configuration, enabling the - NOCLAMP interface flag might be helpful for better - performance. It is crucial to ensure that the path MTU is equal to or larger - than the interface MTU when enabling this flag.

-
-
-

-

The gif device can be configured to be ECN - friendly, as described in - draft-ietf-ipsec-ecn-02.txt. This is turned off by - default, and can be turned on by the IFF_LINK1 - interface flag.

-

Without IFF_LINK1, - gif will show normal behavior, as described in - RFC2893. This can be summarized as follows:

-
-
-
Ingress
-
Set outer TOS bit to 0.
-
Egress
-
Drop outer TOS bit.
-
-
-

With IFF_LINK1, - gif will copy ECN bits (0x02 - and 0x01 on IPv4 TOS byte or IPv6 traffic class - byte) on egress and ingress, as follows:

-
-
-
Ingress
-
Copy TOS bits except for ECN CE (masked with 0xfe) - from inner to outer. Set ECN CE bit to 0.
-
Egress
-
Use inner TOS bits with some change. If outer ECN CE bit is - 1, enable ECN CE bit on the inner.
-
-
-

Note that the ECN friendly behavior violates RFC2893. This should - be used in mutual agreement with the peer.

-
-
-

-

A malicious party may try to circumvent security filters by using - tunnelled packets. For better protection, gif - performs both martian and ingress filtering against the outer source address - on egress. Note that martian/ingress filters are in no way complete. You may - want to secure your node by using packet filters. Ingress filtering can - break tunnel operation in an asymmetrically routed network. It can be turned - off by IFF_LINK2 bit.

-
-
-

-

By default, gif tunnels may not be nested. - This behavior may be modified at runtime by setting the - sysctl(8) variable - net.link.gif.max_nesting to the desired level of - nesting.

-
-
-
-

-

gre(4), if_bridge(4), - inet(4), inet6(4), - ifconfig(8)

-

R. Gilligan and - E. Nordmark, Transition - Mechanisms for IPv6 Hosts and Routers, RFC2893, - http://tools.ietf.org/html/rfc2893, - August 2000.

-

Sally Floyd, - David L. Black, and K. K. - Ramakrishnan, IPsec Interactions with ECN, - December 1999, - draft-ietf-ipsec-ecn-02.txt.

-

R. Housley and - S. Hollenbeck, EtherIP: Tunneling - Ethernet Frames in IP Datagrams, RFC 3378, - September 2002.

-
-
-

-

The gif device first appeared in the WIDE - hydrangea IPv6 kit.

-
-
-

-

There are many tunnelling protocol specifications, all defined - differently from each other. The gif device may not - interoperate with peers which are based on different specifications, and are - picky about outer header fields. For example, you cannot usually use - gif to talk with IPsec devices that use IPsec tunnel - mode.

-

If the outer protocol is IPv4, gif does - not try to perform path MTU discovery for the encapsulated packet (DF bit is - set to 0).

-

If the outer protocol is IPv6, path MTU discovery for encapsulated - packets may affect communication over the interface. The first - bigger-than-pmtu packet may be lost. To avoid the problem, you may want to - set the interface MTU for gif to 1240 or smaller, - when the outer header is IPv6 and the inner header is IPv4.

-

The gif device does not translate ICMP - messages for the outer header into the inner header.

-

In the past, gif had a multi-destination - behavior, configurable via NOCLAMP flag. The - behavior is obsolete and is no longer supported. This flag is now used to - determine whether performing fragmentation when the outer protocol is - IPv6.

-
-
- - - - - -
August 27, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/gpio.4 3.html b/static/freebsd/man4/gpio.4 3.html deleted file mode 100644 index 7e024634..00000000 --- a/static/freebsd/man4/gpio.4 3.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - -
GPIO(4)Device Drivers ManualGPIO(4)
-
-
-

-

gpiobus — GPIO bus - system

-
-
-

-

To compile these devices into your kernel and use the device - hints, place the following lines in your kernel configuration file:

-
device gpio -
-device gpioiic -
-device gpioled
-

Additional device entries for the ARM - architecture include:

-
device a10_gpio -
-device bcm_gpio -
-device imx51_gpio -
-device lpcgpio -
-device mv_gpio -
-device ti_gpio -
-device gpio_avila -
-device gpio_cambria -
-device zy7_gpio -
-device pxagpio
-

Additional device entries for the MIPS - architecture include:

-
device ar71xxx_gpio -
-device octeon_gpio -
-device rt305_gpio
-

Additional device entries for the POWERPC - architecture include:

-
device wiigpio -
-device macgpio
-

Additional device entries for the RISC-V - architecture include:

-
device sifive_gpio
-
-
-

-

The gpiobus system provides a simple - interface to the GPIO pins that are usually available on embedded - architectures and can provide bit banging style devices to the system.

-

The acronym GPIO means - “General-Purpose Input/Output.”

-

The BUS physically consists of multiple pins that can - be configured for input/output, IRQ delivery, SDA/SCL - use, - etc.

-

On some embedded architectures (like MIPS), discovery of the bus - and configuration of the pins is done via device.hints(5) - in the platform's kernel config(5) file.

-

On some others (like ARM), where FDT(4) is used - to describe the device tree, the bus discovery is done via the DTS passed to - the kernel, being either statically compiled in, or by a variety of ways - where the boot loader (or Open Firmware enabled system) passes the DTS blob - to the kernel at boot.

-

On a device.hints(5) based system these hints - can be used to configure drivers for devices attached to - gpiobus pins:

-
-
hint.driver.unit.at
-
The gpiobus where the device is attached. For - example, "gpiobus0". driver and - unit are the driver name and the unit number for the - device driver.
-
hint.driver.unit.pins
-
This is a bitmask of the pins on the gpiobus that - are connected to the device. The pins will be allocated to the specified - driver instance. Only pins with numbers from 0 to 31 can be specified - using this hint.
-
hint.driver.unit.pin_list
-
This is a list of pin numbers of pins on the - gpiobus that are connected to the device. The pins - will be allocated to the specified driver instance. This is a more user - friendly alternative to the pins hint. Additionally, - this hint allows specifying pin numbers greater than 31. The numbers can - be decimal or hexadecimal with 0x prefix. Any non-digit character can be - used as a separator. For example, it can be a comma, a slash or a space. - The separator can be followed by any number of space characters.
-
-

The following device.hints(5) are only provided - by the ar71xx_gpio driver:

-
-
hint.gpio.%d.pinmask
-
This is a bitmask of pins on the GPIO board that we would like to expose - for use to the host operating system. To expose pin 0, 4 and 7, use the - bitmask of 10010001 converted to the hexadecimal value 0x0091.
-
hint.gpio.%d.pinon
-
This is a bitmask of pins on the GPIO board that will be set to ON at host - start. To set pin 2, 5 and 13 to be set ON at boot, use the bitmask of - 10000000010010 converted to the hexadecimal value 0x2012.
-
hint.gpio.function_set
-
 
-
hint.gpio.function_clear
-
These are bitmasks of pins that will remap a pin to handle a specific - function (USB, UART TX/RX, etc) in the Atheros function registers. This is - mainly used to set/clear functions that we need when they are set up or - not set up by uBoot.
-
-

Simply put, each pin of the GPIO interface is connected to an - input/output of some device in a system.

-
-
-

-

gpioiic(4), gpioled(4), - iicbus(4), device.hints(5), - gpioctl(8)

-
-
-

-

The gpiobus manual page first appeared in - FreeBSD 10.0.

-
-
-

-

This manual page was written by Sean Bruno - <sbruno@FreeBSD.org>.

-
-
- - - - - -
August 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/gpioiic.4 3.html b/static/freebsd/man4/gpioiic.4 3.html deleted file mode 100644 index 0732727e..00000000 --- a/static/freebsd/man4/gpioiic.4 3.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - -
GPIOIIC(4)Device Drivers ManualGPIOIIC(4)
-
-
-

-

gpioiic — GPIO I2C - bit-banging device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device gpio -
-device gpioiic -
-device iicbb -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
gpioiic_load="YES"
-
-
-
-

-

The gpioiic driver provides an IIC - bit-banging interface using two GPIO pins for the SCL and SDA lines on the - bus.

-

gpioiic simulates an open collector kind - of output when managing the pins on the bus, even on systems which don't - directly support configuring gpio pins in that mode. The pins are never - driven to the logical value of '1'. They are driven to '0' or switched to - input mode (Hi-Z/tri-state), and an external pullup resistor pulls the line - to the 1 state unless some other device on the bus is driving it to 0.

-
-
-

-

On a device.hints(5) based system, such as MIPS, - these values are configurable for gpioiic:

-
-
hint.gpioiic.%d.at
-
The gpiobus you are attaching to. Normally just - gpiobus0 on systems with a single bank of gpio pins.
-
hint.gpioiic.%d.pins
-
This is a bitmask of the pins on the gpiobus that - are to be used for SCLOCK and SDATA from the GPIO IIC bit-banging bus. To - configure pin 0 and 7, use the bitmask of 0b10000001 and convert it to a - hexadecimal value of 0x0081. Please note that this mask should only ever - have two bits set (any other bits - i.e., pins - will be ignored). Because - gpioiic must be a child of the gpiobus, both gpio - pins must be part of that bus.
-
hint.gpioiic.%d.scl
-
Indicates which bit in the hint.gpioiic.%d.pins - should be used as the SCLOCK source. Optional, defaults to 0.
-
hint.gpioiic.%d.sda
-
Indicates which bit in the hint.gpioiic.%d.pins - should be used as the SDATA source. Optional, defaults to 1.
-
-
-
-

-

On an FDT(4) based system, such as ARM, the DTS - node for gpioiic conforms to the standard bindings - document i2c/i2c-gpio.yaml. The device node typically appears at the root of - the device tree. The following is an example of a - gpioiic node with one slave device on the IIC - bus:

-
-
/ {
-	gpioiic0 {
-		compatible = "i2c-gpio";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_gpioiic0>;
-		scl-gpios = <&gpio1  5 GPIO_ACTIVE_HIGH>;
-		sda-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
-		status = "okay";
-
-		/* One slave device on the i2c bus. */
-		rtc@51 {
-			compatible="nxp,pcf2127";
-			reg = <0x51>;
-			status = "okay";
-		};
-	};
-};
-
-

Where:

-
-
compatible
-
Should be set to "i2c-gpio". The deprecated string - "gpioiic" is also accepted for backwards compatibility.
-
scl-gpios - sda-gpios
-
These properties indicate which GPIO pins should be used for clock and - data on the GPIO IIC bit-banging bus. There is no requirement that the two - pins belong to the same gpio controller.
-
pinctrl-names pinctrl-0
-
These properties may be required to configure the chosen pins as gpio - pins, unless the pins default to that state on your system.
-
-
-
-

-

fdt(4), gpio(4), - iic(4), iicbb(4), - iicbus(4)

-
-
-

-

The gpioiic manual page first appeared in - FreeBSD 10.1.

-
-
-

-

This manual page was written by Luiz Otavio O - Souza.

-
-
- - - - - -
December 1, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/gpiokeys.4 3.html b/static/freebsd/man4/gpiokeys.4 3.html deleted file mode 100644 index c17dfbf7..00000000 --- a/static/freebsd/man4/gpiokeys.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
GPIOKEYS(4)Device Drivers ManualGPIOKEYS(4)
-
-
-

-

gpiokeys — GPIO - keys device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
options FDT -
-device gpio -
-device gpiokeys
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
gpiokeys_load="YES"
-
-
-
-

-

The gpiokeys driver provides a way to - represent a set of general purpose inputs as a keyboard(4) - device. At the moment the driver supports only FDT(4) - based systems. The DTS determines what pins are mapped to buttons and what - key codes are generated for each virtual button. The - keyboard(4) device can be used from userland to monitor - for input changes.

-

On an FDT(4) based system the DTS part for a - gpiokeys device usually looks like:

-
-
/ {
-
-	...
-
-	gpio_keys {
-		compatible = "gpio-keys";
-
-		btn1 {
-			label = "button1";
-			linux,code = <KEY_1>;
-			gpios = <&gpio 0 3 GPIO_ACTIVE_LOW>
-		};
-
-		btn2 {
-			label = "button2";
-			linux,code = <KEY_2>;
-			gpios = <&gpio 0 4 GPIO_ACTIVE_LOW>
-		};
-	};
-};
-
-

For more details about the gpios property, - please consult - /usr/src/sys/dts/bindings-gpio.txt.

-

The gpiokeys driver supports two - properties for specifying a key code.

-

The property freebsd,code specifies a - FreeBSD native scancode compatible with - kbdmap(5) keyboard maps.

-

The property linux,code specifies an evdev - scancode. That scancode is internally translated to a native scancode. Note - that not all evdev scancodes have corresponding native scancodes. If a - scancode cannot be translated, then a diagnostic message is printed and the - input is ignored.

-

The property label is a descriptive name of - a button. It is used for diagnostic messages only. This property is - optional. If not set, the node name is used in its place.

-

The property autorepeat determines whether - autorepeat is enabled for a button.

-

The property debounce-interval defines - debouncing interval time in milliseconds. If not specified the interval - defaults to 5.

-
-
-

-

fdt(4), gpio(4), - keyboard(4), kbdmap(5)

-
-
-

-

The gpiokeys manual page first appeared in - FreeBSD 12.2.

-
-
-

-

The gpiokeys driver was written by - Oleksandr Tymoshenko - <gonzo@FreeBSD.org>. - This manual page was written by -
- Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
August 5, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/gpioled.4 3.html b/static/freebsd/man4/gpioled.4 3.html deleted file mode 100644 index 9cf95ebd..00000000 --- a/static/freebsd/man4/gpioled.4 3.html +++ /dev/null @@ -1,140 +0,0 @@ - - - - - - -
GPIOLED(4)Device Drivers ManualGPIOLED(4)
-
-
-

-

gpioled — GPIO LED - generic device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device gpio -
-device gpioled
-
-
-

-

The gpioled driver provides glue to attach - a led(4) compatible device to a GPIO pin. Each LED in the - system has a name which is used to export a device - as /dev/led/<name>. The GPIO pin can then be - controlled by writing to this device as described in - led(4).

-

On a device.hints(5) based system, like - MIPS, these values are configurable for - gpioled:

-
-
hint.gpioled.%d.at
-
The gpiobus you are attaching to. Normally assigned to gpiobus0.
-
hint.gpioled.%d.name
-
Arbitrary name of device in /dev/led/ to create - for led(4).
-
hint.gpioled.%d.pins
-
Which pin on the GPIO interface to map to this instance. Please note that - this mask should only ever have one bit set (any other bits - i.e., pins - - will be ignored).
-
hint.gpioled.%d.invert
-
Use pin inversion. If set to 1, the pin will be set to 0 to light the LED, - and 1 to clear it.
-
hint.gpioled.%d.invmode
-
Whether or not to use hardware support when pin inversion is requested. - Must be one of: -
-
auto
-
Use hardware pin inversion if available, else fallback to software pin - inversion. This is the default.
-
hw
-
Use hardware pin inversion.
-
sw
-
Use software pin inversion.
-
-
-
hint.gpioled.%d.state
-
The initial state of the LED when the driver takes control over it. If set - to 1 or 0, the LED will be on or off correspondingly. If set to -1, the - LED will be kept in its original state.
-
-

On a FDT(4) based system, like - ARM, the DTS part for a - gpioled device usually looks like:

-
-
gpio: gpio {
-
-	gpio-controller;
-	...
-
-	led0 {
-		compatible = "gpioled";
-		gpios = <&gpio 16 2 0>;		/* GPIO pin 16. */
-		name = "ok";
-	};
-
-	led1 {
-		compatible = "gpioled";
-		gpios = <&gpio 17 2 0>;		/* GPIO pin 17. */
-		name = "user-led1";
-	};
-};
-
-

Optionally, you can choose to combine all the LEDs under a single - “gpio-leds” compatible node:

-
-
simplebus0 {
-
-	...
-
-	leds {
-		compatible = "gpio-leds";
-
-		led0 {
-			gpios = <&gpio 16 2 0>;
-			name = "ok"
-		};
-
-		led1 {
-			gpios = <&gpio 17 2 0>;
-			name = "user-led1"
-		};
-	};
-};
-
-

Both methods are equally supported and it is possible to have the - LEDs defined with any sort of mix between the methods. The only restriction - is that a GPIO pin cannot be mapped by two different (gpio)leds.

-

For more details about the gpios property, - please consult - /usr/src/sys/dts/bindings-gpio.txt.

-

The property name is the arbitrary name of - the device in /dev/led/ to create for - led(4).

-
-
-

-

fdt(4), gpio(4), - gpioiic(4), led(4)

-
-
-

-

The gpioled manual page first appeared in - FreeBSD 10.1.

-
-
-

-

This manual page was written by Luiz Otavio O - Souza.

-
-
- - - - - -
May 23, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/gpioths.4 3.html b/static/freebsd/man4/gpioths.4 3.html deleted file mode 100644 index 26442c77..00000000 --- a/static/freebsd/man4/gpioths.4 3.html +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - -
GPIOTHS(4)Device Drivers ManualGPIOTHS(4)
-
-
-

-

gpioths — driver - for DHTxx and AM320x temperature and humidity sensors

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device gpioths
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
gpioths_load="YES"
-
-
-
-

-

The gpioths driver supports the DHTxx and - AM320x family of temperature and humidity sensors. The driver automatically - reads the values from the sensor once every 5 seconds, and makes the results - available via sysctl(8) variables.

-
-
-

-

The gpioths driver provides support for - the following devices:

-

- - - - - - - - - - - - - -
DHT11DHT12
DHT21DHT22
AM3201AM3202
-

The supported devices are all similar to each other, varying - primarily in accuracy and resolution. The devices require a single wire for - data communications, using a custom protocol which is not compatible with - Maxim's 1-wire(tm). The AM320x devices also support connection to an i2c - bus, but this driver supports only the single-wire connection option.

-
-
-

-

Sysctl variables are used to access the most recent temperature - and humidity measurements.

-
-
dev.gpioths.<unit>.temperature
-
The current temperature in integer deciKelvins. Note that - sysctl(8) will convert those units to display in decimal - degrees Celsius.
-
dev.gpioths.<unit>.humidity
-
The current relative humidity, as an integer percentage.
-
dev.gpioths.<unit>.fails
-
The number of failed attempts to communicate with the sensor since the - last good access. Cleared whenever a set of measurements is successfully - retrieved.
-
-
-
-

-

On an fdt(4) based system, a - gpioths device node is typically defined directly - under the root node, or under a simplebus node that represents a collection - of devices on a board.

-

The following properties are required in the - gpioths device subnode:

-
-
compatible
-
Must be "dht11".
-
gpios
-
A reference to the gpio device and pin for data communications.
-
-
-

-
-
/dts-v1/;
-/plugin/;
-#include <dt-bindings/gpio/gpio.h>
-
-/ {
-    compatible = "wand,imx6q-wandboard";
-};
-
-&{/} {
-    dht0 {
-        compatible = "dht11";
-        gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
-    };
-};
-
-
-
-
-

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - gpioths:

-
-
hint.gpioths.<unit>.at
-
The gpiobus(4) instance the - gpioths instance is attached to.
-
hint.gpioths.pins
-
A bitmask with a single bit set to indicate which gpio pin on the - gpiobus(4) to use for data communications.
-
-
-
-

-

fdt(4), gpiobus(4), - sysctl(8)

-
-
-

-

The gpioths driver first appeared in - FreeBSD 11.1.

-
-
- - - - - -
December 8, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/gre.4 3.html b/static/freebsd/man4/gre.4 3.html deleted file mode 100644 index 61256a86..00000000 --- a/static/freebsd/man4/gre.4 3.html +++ /dev/null @@ -1,215 +0,0 @@ - - - - - - -
GRE(4)Device Drivers ManualGRE(4)
-
-
-

-

gre — - encapsulating network device

-
-
-

-

To compile the driver into the kernel, place the following line in - the kernel configuration file:

-
device gre
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_gre_load="YES"
-
-
-
-

-

The gre network interface pseudo device - encapsulates datagrams into IP. These encapsulated datagrams are routed to a - destination host, where they are decapsulated and further routed to their - final destination. The “tunnel” appears to the inner datagrams - as one hop.

-

gre interfaces are dynamically created and - destroyed with the ifconfig(8) - create and destroy - subcommands.

-

This driver corresponds to RFC 2784. Encapsulated datagrams are - prepended an outer datagram and a GRE header. The GRE header specifies the - type of the encapsulated datagram and thus allows for tunneling other - protocols than IP. GRE mode is also the default tunnel mode on Cisco - routers. gre also supports Cisco WCCP protocol, both - version 1 and version 2.

-

The gre interfaces support a number of - additional parameters to the ifconfig(8):

-
-
grekey
-
Set the GRE key used for outgoing packets. A value of 0 disables the key - option.
-
enable_csum
-
Enables checksum calculation for outgoing packets.
-
enable_seq
-
Enables use of sequence number field in the GRE header for outgoing - packets.
-
udpencap
-
Enables UDP-in-GRE encapsulation (see the - GRE-IN-UDP - ENCAPSULATION Section below for details).
-
udpport
-
Set the source UDP port for outgoing packets. A value of 0 disables the - persistence of source UDP port for outgoing packets. See the - GRE-IN-UDP - ENCAPSULATION Section below for details.
-
-
-
-

-

The gre supports GRE in UDP encapsulation - as defined in RFC 8086. A GRE in UDP tunnel offers the possibility of better - performance for load-balancing GRE traffic in transit networks. - Encapsulating GRE in UDP enables use of the UDP source port to provide - entropy to ECMP hashing.

-

The GRE in UDP tunnel uses single value 4754 as UDP destination - port. The UDP source port contains a 14-bit entropy value that is generated - by the encapsulator to identify a flow for the encapsulated packet. The - udpport option can be used to disable this behaviour - and use single source UDP port value. The value of - udpport should be within the ephemeral port range, - i.e., 49152 to 65535 by default.

-

Note that a GRE in UDP tunnel is unidirectional; the tunnel - traffic is not expected to be returned back to the UDP source port values - used to generate entropy. This may impact NAPT (Network Address Port - Translator) middleboxes. If such tunnels are expected to be used on a path - with a middlebox, the tunnel can be configured either to disable use of the - UDP source port for entropy or to enable middleboxes to pass packets with - UDP source port entropy.

-
-
-

-
-
192.168.1.* --- Router A  -------tunnel-------- Router B --- 192.168.2.*
-                   \                              /
-                    \                            /
-                     +------ the Internet ------+
-
-

Assuming router A has the (external) IP address A and the internal - address 192.168.1.1, while router B has external address B and internal - address 192.168.2.1, the following commands will configure the tunnel:

-

On router A:

-
-
ifconfig greN create
-ifconfig greN inet 192.168.1.1 192.168.2.1
-ifconfig greN inet tunnel A B
-route add -net 192.168.2 -netmask 255.255.255.0 192.168.2.1
-
-

On router B:

-
-
ifconfig greN create
-ifconfig greN inet 192.168.2.1 192.168.1.1
-ifconfig greN inet tunnel B A
-route add -net 192.168.1 -netmask 255.255.255.0 192.168.1.1
-
-

In case when internal and external IP addresses are the same, - different routing tables (FIB) should be used. The default FIB will be - applied to IP packets before GRE encapsulation. After encapsulation GRE - interface should set different FIB number to outgoing packet. Then different - FIB will be applied to such encapsulated packets. According to this FIB - packet should be routed to tunnel endpoint.

-
-
Host X -- Host A (198.51.100.1) ---tunnel--- Cisco D (203.0.113.1) -- Host E
-                   \                                   /
-                    \                                 /
-	             +----- Host B ----- Host C -----+
-                       (198.51.100.254)
-
-

On Host A (FreeBSD):

-

First of multiple FIBs should be configured via loader.conf:

-
-
net.fibs=2
-net.add_addr_allfibs=0
-
-

Then routes to the gateway and remote tunnel endpoint via this - gateway should be added to the second FIB:

-
-
route add -net 198.51.100.0 -netmask 255.255.255.0 -fib 1 -iface em0
-route add -host 203.0.113.1 -fib 1 198.51.100.254
-
-

And GRE tunnel should be configured to change FIB for encapsulated - packets:

-
-
ifconfig greN create
-ifconfig greN inet 198.51.100.1 203.0.113.1
-ifconfig greN inet tunnel 198.51.100.1 203.0.113.1 tunnelfib 1
-
-
-
-

-

The MTU of gre interfaces is set to 1476 - by default, to match the value used by Cisco routers. This may not be an - optimal value, depending on the link between the two tunnel endpoints. It - can be adjusted via ifconfig(8).

-

For correct operation, the gre device - needs a route to the decapsulating host that does not run over the tunnel, - as this would be a loop.

-

The kernel must be set to forward datagrams by setting the - net.inet.ip.forwarding sysctl(8) - variable to non-zero.

-

By default, gre tunnels may not be nested. - This behavior may be modified at runtime by setting the - sysctl(8) variable - net.link.gre.max_nesting to the desired level of - nesting.

-
-
-

-

gif(4), inet(4), - ip(4), me(4), - netintro(4), protocols(5), - ifconfig(8), sysctl(8)

-
-
-

-

S. Hanks, - T. Li, D. Farinacci, and - P. Traina, Generic Routing - Encapsulation (GRE), RFC 1701, - October 1994.

-

S. Hanks, - T. Li, D. Farinacci, and - P. Traina, Generic Routing - Encapsulation over IPv4 networks, RFC 1702, - October 1994.

-

D. Farinacci, - T. Li, S. Hanks, - D. Meyer, and P. Traina, - Generic Routing Encapsulation (GRE), - RFC 2784, March - 2000.

-

G. Dommety, - Key and Sequence Number Extensions to GRE, - RFC 2890, September - 2000.

-
-
-

-

Andrey V. Elsukov - <ae@FreeBSD.org> -
- Heiko W.Rupp - <hwr@pilhuhn.de>

-
-
-

-

The current implementation uses the key only for outgoing packets. - Incoming packets with a different key or without a key will be treated as if - they would belong to this interface.

-

The sequence number field also used only for outgoing packets.

-
-
- - - - - -
August 21, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/gve.4 3.html b/static/freebsd/man4/gve.4 3.html deleted file mode 100644 index e42c19b1..00000000 --- a/static/freebsd/man4/gve.4 3.html +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - -
GVE(4)Device Drivers ManualGVE(4)
-
-
-

-

gve — Ethernet - driver for Google Virtual NIC (gVNIC)

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device gve
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_gve_load="YES"
-
-
-
-

-

gVNIC is a virtual network interface designed specifically for - Google Compute Engine (GCE). It is required to support per-VM Tier-1 - networking performance, and for using certain VM shapes on GCE.

-

gve is the driver for gVNIC. It supports - the following features:

-

-
    -
  • RX checksum offload
    • -
  • TX chesksum offload
    • -
  • TCP Segmentation Offload (TSO)
    • -
  • Large Receive Offload (LRO) in software
    • -
  • Jumbo frames
    • -
  • Receive Side Scaling (RSS)
    • -
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

gve binds to a single PCI device ID - presented by gVNIC:

-

-
    -
  • 0x1AE0:0x0042
    • -
-
-
-

-

Change the TX queue count to 4 for the gve0 interface:

-
sysctl dev.gve.0.num_tx_queues=4
-

Change the RX queue count to 4 for the gve0 interface:

-
sysctl dev.gve.0.num_rx_queues=4
-

Change the TX ring size to 512 for the gve0 interface:

-
sysctl dev.gve.0.tx_ring_size=512
-

Change the RX ring size to 512 for the gve0 interface:

-
sysctl dev.gve.0.rx_ring_size=512
-
-
-

-

The following messages are recorded during driver - initialization:

-
-
Enabled MSIX with %d vectors
-
-
Configured device resources
-
-
Successfully attached %s
-
-
Deconfigured device resources
-
-
-

These messages are seen if driver initialization fails. Global - (across-queues) allocation failures:

-
-
Failed to configure device resources: err=%d
-
-
No compatible queue formats
-
-
Failed to allocate ifnet struct
-
-
Failed to allocate admin queue mem
-
-
Failed to alloc DMA mem for DescribeDevice
-
-
Failed to allocate QPL page
-
-
-

irq and BAR allocation failures:

-
-
Failed to acquire any msix vectors
-
-
Tried to acquire %d msix vectors, got only %d
-
-
Failed to setup irq %d for Tx queue %d
-
-
Failed to setup irq %d for Rx queue %d
-
-
Failed to allocate irq %d for mgmnt queue
-
-
Failed to setup irq %d for mgmnt queue, err: %d
-
-
Failed to allocate BAR0
-
-
Failed to allocate BAR2
-
-
Failed to allocate msix table
-
-
-

Rx queue-specific allocation failures:

-
-
No QPL left for rx ring %d
-
-
Failed to alloc queue resources for rx ring %d
-
-
Failed to alloc desc ring for rx ring %d
-
-
Failed to alloc data ring for rx ring %d
-
-
-

Tx queue-specific allocation failures:

-
-
No QPL left for tx ring %d
-
-
Failed to alloc queue resources for tx ring %d
-
-
Failed to alloc desc ring for tx ring %d
-
-
Failed to vmap fifo, qpl_id = %d
-
-
-

The following messages are recorded when the interface detach - fails:

-
-
Failed to deconfigure device resources: err=%d
-
-
-

If bootverbose is on, the following messages are recorded when the - interface is being brought up:

-
-
Created %d rx queues
-
-
Created %d tx queues
-
-
MTU set to %d
-
-
-

The following messages are recorded when the interface is being - brought down:

-
-
Destroyed %d rx queues
-
-
Destroyed %d tx queues
-
-
-

These messages are seen if errors are encountered when bringing - the interface up or down:

-
-
Failed to destroy rxq %d, err: %d
-
-
Failed to destroy txq %d, err: %d
-
-
Failed to create rxq %d, err: %d
-
-
Failed to create txq %d, err: %d
-
-
Failed to set MTU to %d
-
-
Invalid new MTU setting. new mtu: %d max mtu: %d min mtu: %d
-
-
Cannot bring the iface up when detached
-
-
Reached max number of registered pages %lu > %lu
-
-
Failed to init lro for rx ring %d
-
-
-

These messages are seen if any admin queue command fails:

-
-
AQ command(%u): failed with status %d
-
-
AQ command(%u): unknown status code %d
-
-
AQ commands timed out, need to reset AQ
-
-
Unknown AQ command opcode %d
-
-
-

These messages appear if a TX timeout is detected:

-
-
Found %d timed out packet(s) on txq%d, kicking it for completions
-
-
Found %d timed out packet(s) on txq%d with its last kick %ld sec ago which - is less than the cooldown period %d. Resetting device
-
-
-

These messages are recorded when the device is being reset due to - an error:

-
-
Scheduling reset task!
-
-
Waiting until admin queue is released.
-
-
Admin queue released
-
-
-

If it was the NIC that requested the reset, this message is - recorded:

-
-
Device requested reset
-
-
-

If the reset fails during the reinitialization phase, this message - is recorded:

-
-
Restore failed!
-
-
-

These two messages correspond to the NIC alerting the driver to - link state changes:

-
-
Device link is up.
-
-
Device link is down.
-
-
-

Apart from these messages, the driver exposes per-queue packet and - error counters as sysctl nodes. Global (across queues) counters can be read - using netstat(1).

-
-
-

-

gve exposes the following - sysctl(8) variables:

-
-
hw.gve.driver_version
-
The driver version. This is read-only.
-
hw.gve.queue_format
-
The queue format in use. This is read-only.
-
hw.gve.disable_hw_lro
-
Setting this boot-time tunable to 1 disables Large Receive Offload (LRO) - in the NIC. The default value is 0, which means hardware LRO is enabled by - default. The software LRO stack in the kernel is always used. This sysctl - variable needs to be set before loading the driver, using - loader.conf(5).
-
hw.gve.allow_4k_rx_buffers
-
Setting this boot-time tunable to 1 enables support for 4K RX Buffers. The - default value is 0, which means 2K RX Buffers will be used. 4K RX Buffers - are only supported on DQO_RDA and DQO_QPL queue formats. When enabled, 4K - RX Buffers will be used either when HW LRO is enabled or mtu is greated - than 2048. This sysctl variable needs to be set before loading the driver, - using loader.conf(5).
-
dev.gve.X.num_rx_queues and - dev.gve.X.num_tx_queues
-
Run-time tunables that represent the number of currently used RX/TX - queues. The default value is the max number of RX/TX queues the device can - support. -

This call turns down the interface while setting up the new - queues, which may potentially cause any new packets to be dropped. This - call can fail if the system is not able to provide the driver with - enough resources. In that situation, the driver will revert to the - previous number of RX/TX queues. If this also fails, a device reset will - be triggered.

-

Note: sysctl nodes for queue stats remain available even if a - queue is removed.

-
-
dev.gve.X.rx_ring_size and - dev.gve.X.tx_ring_size
-
Run-time tunables that represent the current ring size for RX/TX queues. - The default value is set to device defaults for ring size. -

This call turns down the interface while setting up the queues - with the new ring size, which may potentially cause any new packets to - be dropped. This call can fail if the system is not able to provide the - driver with enough resources. In that situation, the driver will try to - revert to the previous ring size for RX/TX queues. If this also fails, - the device will be in an unhealthy state and will need to be reloaded. - This value must be a power of 2 and within the defined range.

-
-
-
-
-

-

gve does not support the transmission of - VLAN-tagged packets. All VLAN-tagged traffic is dropped.

-
-
-

-

gve features different datapath modes - called queue formats:

-

-
    -
  • GQI_QPL: "QPL" stands for "Queue Page List" and refers - to the fact that hardware expects a fixed bounce buffer and cannot access - arbitrary memory. GQI is the older descriptor format. The G in - "GQI" refers to an older generation of hardware, and the - "QI" stands for "Queue In-order" referring to the fact - that the NIC sends Tx and Rx completions in the same order as the one in - which the corresponding descriptors were posted by the driver.
    • -
  • DQO_RDA: DQO is the descriptor format required to take full advantage of - next generation VM shapes. "RDA" stands for "Raw DMA - Addressing" and refers to the fact that hardware can work with DMA-ed - packets and does not expect them to be copied into or out of a fixed - bounce buffer. The D in "DQO" refers to a newer generation of - hardware, and the "QO" stands for "Queue Out-of-order" - referring to the fact that the NIC might send Tx and Rx completions in an - order different from the one in which the corresponding descriptors were - posted by the driver.
    • -
  • DQO_QPL: The next generation descriptor format in the "QPL" - mode.
    • -
-
-
-

-

Please email gvnic-drivers@google.com with the specifics of the - issue encountered.

-
-
-

-

netstat(1), loader.conf(5), - ifconfig(8), sysctl(8)

-
-
-

-

The gve device driver first appeared in - FreeBSD 13.3.

-
-
-

-

The gve driver was written by Google.

-
-
- - - - - -
May 20, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/h_ertt.4 3.html b/static/freebsd/man4/h_ertt.4 3.html deleted file mode 100644 index 0015d296..00000000 --- a/static/freebsd/man4/h_ertt.4 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
H_ERTT(4)Device Drivers ManualH_ERTT(4)
-
-
-

-

h_ertt — Enhanced - Round Trip Time Khelp module

-
-
-

-

#include - <netinet/khelp/h_ertt.h>

-
-
-

-

The h_ertt Khelp module works within the - khelp(9) framework to provide TCP with a per-connection, - low noise estimate of the instantaneous RTT. The implementation attempts to - be robust in the face of delayed acknowledgements, TCP Segmentation Offload - (TSO), receivers who manipulate TCP timestamps and lack of the TCP timestamp - option altogether.

-

TCP receivers using delayed acknowledgements either acknowledge - every second packet (reflecting the time stamp of the first) or use a - timeout to trigger the acknowledgement if no second packet arrives. If the - heuristic used by h_ertt determines that the - receiver is using delayed acknowledgements, it measures the RTT using the - second packet (the one that triggers the acknowledgement). It does not - measure the RTT if the acknowledgement is for the first packet, since it - cannot be accurately determined.

-

When TSO is in use, h_ertt will - momentarily disable TSO whilst marking a packet to use for a new - measurement. The process has negligible impact on the connection.

-

h_ertt associates the following struct - with each connection's TCP control block:

-
-
struct ertt {
-	TAILQ_HEAD(txseginfo_head, txseginfo) txsegi_q;	/* Private. */
-	long		bytes_tx_in_rtt;		/* Private. */
-	long		bytes_tx_in_marked_rtt;
-	unsigned long	marked_snd_cwnd;
-	int		rtt;
-	int		maxrtt;
-	int		minrtt;
-	int		dlyack_rx;			/* Private. */
-	int		timestamp_errors;		/* Private. */
-	int		markedpkt_rtt;			/* Private. */
-	uint32_t	flags;
-};
-
-

The fields marked as private should not be manipulated by any code - outside of the h_ertt implementation. The - non-private fields provide the following data:

-
-
-
bytes_tx_in_marked_rtt
-
The number of bytes transmitted in the - markedpkt_rtt.
-
marked_snd_cwnd
-
The value of cwnd for the marked rtt measurement.
-
rtt
-
The most recent RTT measurement.
-
maxrtt
-
The longest RTT measurement that has been taken.
-
minrtt
-
The shortest RTT measurement that has been taken.
-
flags
-
The ERTT_NEW_MEASUREMENT flag will be set by the implementation when a new - measurement is available. It is the responsibility of - h_ertt consumers to unset the flag if they wish to - use it as a notification method for new measurements.
-
-
-
-
-

-

cc_chd(4), cc_hd(4), - cc_vegas(4), mod_cc(4), - hhook(9), khelp(9)

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The h_ertt module first appeared in - FreeBSD 9.0.

-

The module was first released in 2010 by David Hayes whilst - working on the NewTCP research project at Swinburne University of - Technology's Centre for Advanced Internet Architectures, Melbourne, - Australia. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The h_ertt Khelp module and this manual - page were written by David Hayes - <david.hayes@ieee.org>.

-
-
-

-

The module maintains enhanced RTT estimates for all new TCP - connections created after the time at which the module was loaded. It might - be beneficial to see if it is possible to have the module only affect - connections which actually care about ERTT estimates.

-
-
- - - - - -
January 18, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/hconf.4 3.html b/static/freebsd/man4/hconf.4 3.html deleted file mode 100644 index 02b7ede5..00000000 --- a/static/freebsd/man4/hconf.4 3.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
HCONF(4)Device Drivers ManualHCONF(4)
-
-
-

-

hconf — MS Windows - Precision Touchpad configuration driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device hconf -
-device hid -
-device hidbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hconf_load="YES"
-
-
-
-

-

The hconf driver provides support for - generic MS Windows Precision Touchpad configuration collection. It enables - the host to configure two different aspects of the device. One allows the - host to select input mode, and the other allows the host to be selective in - what is reported.

-
-
-

-

Next parameters are available as sysctl(8) - variables. Debug parameter is available as loader(8) - tunable as well.

-
-
dev.hconf.*.input_mode
-
HID device input mode: 0 = mouse, 3 = touchpad.
-
dev.hconf.*.surface_switch
-
Enable / disable switch for surface: 1 = on, 0 = off.
-
dev.hconf.*.buttons_switch
-
Enable / disable switch for buttons: 1 = on, 0 = off.
-
hw.hid.hconf.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

hms(4), hmt(4)

-
-
-

-

The hconf driver first appeared in - FreeBSD 13.0.

-
-
-

-

The hconf driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>. - Switch parameter support was added by Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
January 18, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/hcons.4 3.html b/static/freebsd/man4/hcons.4 3.html deleted file mode 100644 index f188887b..00000000 --- a/static/freebsd/man4/hcons.4 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
HCONS(4)Device Drivers ManualHCONS(4)
-
-
-

-

hcons — HID - consumer page controls driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device hcons -
-device hid -
-device hidbus -
-device hidmap -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hcons_load="YES"
-
-
-
-

-

The hcons driver provides support for HID - consumer page controls most often used as "Multimedia keys" found - on many keyboards.

-

The /dev/input/event* device presents the - consumer page controls as a evdev type device.

-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.hcons.X.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-

It default value is set with loader(8) - tunable:

-
-
hw.hid.hcons.debug
-
 
-
-
-
-

-
-
/dev/input/event*
-
input event device node.
-
-
-
-

-

iichid(4), usbhid(4)

-
-
-

-

The hcons driver first appeared in - FreeBSD 13.0.

-
-
-

-

The hcons driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
January 23, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/hgame.4 3.html b/static/freebsd/man4/hgame.4 3.html deleted file mode 100644 index 7d49e12b..00000000 --- a/static/freebsd/man4/hgame.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
HGAME(4)Device Drivers ManualHGAME(4)
-
-
-

-

hgame — generic - HID gamepad, joystick, and controller evdev driver

-
-
-

-

device hgame -
- device hid -
- device hidbus -
- device hidmap -
- device evdev

-

In sysctl.conf(5): -
- dev.hgame.X.debug

-

In loader.conf(5): -
- hw.hid.hgame.debug -
- hgame_load

-
-
-

-

The hgame driver supports generic game - controllers that attach to the HID transport backend, and presents them to - applications over the evdev interface.

-

If the appropriate hardware is detected, the driver will be loaded - automatically by devmatch(8). To load the driver manually - at boot time, set the hgame_load variable to - YES at the loader(8) prompt, or add - it to loader.conf(5).

-

To give user applications access to the game - controllers, allow user access to the - /dev/input/event* nodes with inclusion of user in - the - group.

-
-
-

-

The hgame driver supports HID gamepads, - joysticks, and controllers such as:

-

-
    -
  • 8bitdo USB Wireless Adapter 2
    • -
-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.hgame.X.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-

Its default value is set with loader(8) - tunable:

-
-
hw.hid.hgame.debug
-
 
-
-
-
-

-
-
/dev/input/event*
-
input event device (evdev) node
-
-
-
-

-

iichid(4), ps4dshock(4), - usbhid(4), xb360gp(4), - devfs.rules(5)

-
-
-

-

The hgame driver first appeared in - FreeBSD 13.0.

-
-
-

-

The hgame driver was written by - Val Packett - <val@packett.cool>.

-

This manual page was written by Vladimir - Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
November 30, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/hidbus.4 3.html b/static/freebsd/man4/hidbus.4 3.html deleted file mode 100644 index c37f5046..00000000 --- a/static/freebsd/man4/hidbus.4 3.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
HIDBUS(4)Device Drivers ManualHIDBUS(4)
-
-
-

-

hidbus — generic - HID bus driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device hidbus -
-device hid
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hidbus_load="YES"
-
-
-
-

-

The hidbus driver provides support for - multiple HID driver attachments to single HID transport backend. See - iichid(4) or usbhid(4).

-

Each HID device can have several components, e.g., a keyboard and - a mouse. These components use different report identifiers (a byte) combined - into groups called collections to distinguish which one data is coming from. - The hidbus driver has other drivers attached that - handle particular kinds of devices and hidbus - broadcasts data to all of them.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.hid.hidbus.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

hconf(4), hcons(4), - hgame(4), hidraw(4), - hkbd(4), hms(4), - hmt(4), hpen(4), - hsctrl(4), hskbd(4), - iichid(4), usbhid(4)

-
-
-

-

The hidbus driver first appeared in - FreeBSD 13.0.

-
-
-

-

The hidbus driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
September 14, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/hidquirk.4 3.html b/static/freebsd/man4/hidquirk.4 3.html deleted file mode 100644 index 396fc8db..00000000 --- a/static/freebsd/man4/hidquirk.4 3.html +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - -
HIDQUIRK(4)Device Drivers ManualHIDQUIRK(4)
-
-
-

-

hidquirk — HID - quirks module

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device hid
-

Alternatively, to load the module at boot time, place the - following line in loader.conf(5):

-
-
hidquirk_load="YES"
-
-
-
-

-

The hidquirk module provides support for - adding quirks for HID devices

-
-
HQ_HID_IGNORE
-
device should be ignored by hid class
-
HQ_KBD_BOOTPROTO
-
device should set the boot protocol
-
HQ_MS_BOOTPROTO
-
device should set the boot protocol
-
HQ_MS_BAD_CLASS
-
doesn't identify properly
-
HQ_MS_LEADING_BYTE
-
mouse sends an unknown leading byte
-
HQ_MS_REVZ
-
mouse has Z-axis reversed
-
HQ_MS_VENDOR_BTN
-
mouse has buttons in vendor usage page
-
HQ_SPUR_BUT_UP
-
spurious mouse button up events
-
HQ_MT_TIMESTAMP
-
Multitouch device exports HW timestamps - 0x1b5a01
-
-

See /sys/dev/hid/hidquirk.h for the - complete list of supported quirks.

-
-
-

-

The following tunable can be set at the - loader(8) prompt before booting the kernel, or stored in - loader.conf(5).

-
-
hw.hid.quirk.%d
-
The value is a string whose format is: -
- 
"BusId VendorId ProductId LowRevision HighRevision HQ_QUIRK,..."
-
-

Installs the quirks HQ_QUIRK,... for - all HID devices matching BusId and - VendorId and ProductId - which have a hardware revision between and including - LowRevision and - HighRevision.

-

BusId, - VendorId, ProductId, - LowRevision and - HighRevision are all 16 bits numbers which can - be decimal or hexadecimal based.

-

A maximum of 100 variables hw.hid.quirk.0, - .1, ..., .99 can be defined.

-

If a matching entry is found in the kernel's internal quirks - table, it is replaced by the new definition.

-

Else a new entry is created given that the quirk table is not - full.

-

The kernel iterates over the - hw.hid.quirk.N variables starting at - N = 0 and stops at N = - 99 or the first non-existing one.

-
-
-
-
-

-

To install a quirk at boot time, place one or several lines like - the following in loader.conf(5):

-
-
hw.hid.quirk.0="0x18 0x6cb 0x1941 0 0xffff HQ_MT_TIMESTAMP"
-
-
-
-

-

The hidquirk module appeared in - FreeBSD 13.0.

-
-
-

-

The hidquirk driver was written by - Hans Petter Selasky - <hselasky@FreeBSD.org> - for usb(4) subsystem and adopted to - hid(4) by Vladimir Kondratyev - <wulf@FreeBSD.org>. - This manual page is based on usb_quirk(4) manual page - written by Nick Hibma - <n_hibma@FreeBSD.org>.

-
-
- - - - - -
September 16, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/hidraw.4 3.html b/static/freebsd/man4/hidraw.4 3.html deleted file mode 100644 index 8c1d253c..00000000 --- a/static/freebsd/man4/hidraw.4 3.html +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - -
HIDRAW(4)Device Drivers ManualHIDRAW(4)
-
-
-

-

hidraw — Raw - Access to HID devices

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hidraw -
-device hid -
-device hidbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hidraw_load="YES"
-
-
-
-

-

The hidraw driver provides a raw interface - to Human Interface Devices (HIDs). The reports are sent to and received from - the device unmodified.

-

The device handles 2 sets of ioctl(2) calls:

-

FreeBSD uhid(4) - -compatible calls:

-
-
- (int)
-
Get the report identifier used by this HID report.
-
- (struct hidraw_gen_descriptor)
-
Get the HID report descriptor. Copies a maximum of - hgd_maxlen bytes of the report descriptor data into - the memory specified by hgd_data. Upon return - hgd_actlen is set to the number of bytes copied. - Using this descriptor the exact layout and meaning of data to/from the - device can be found. The report descriptor is delivered without any - processing. -
- 
struct hidraw_gen_descriptor {
-	void   *hgd_data;
-	uint16_t hgd_maxlen;
-	uint16_t hgd_actlen;
-	uint8_t	hgd_report_type;
-	...
-};
-
-
-
- (int)
-
Sets the device in a mode where each read(2) will return - the current value of the input report. Normally a - read(2) will only return the data that the device - reports on its interrupt pipe. This call may fail if the device does not - support this feature.
-
- (struct hidraw_gen_descriptor)
-
Get a report from the device without waiting for data on the interrupt - pipe. Copies a maximum of hgd_maxlen bytes of the - report data into the memory specified by hgd_data. - Upon return hgd_actlen is set to the number of bytes - copied. The hgd_report_type field indicates which - report is requested. It should be - HID_INPUT_REPORT, - HID_OUTPUT_REPORT, or - HID_FEATURE_REPORT. On a device which uses - numbered reports, the first byte of the returned data is the report - number. The report data begins from the second byte. For devices which do - not use numbered reports, the report data begins at the first byte. This - call may fail if the device does not support this feature.
-
- (struct hidraw_gen_descriptor)
-
Set a report in the device. The hgd_report_type - field indicates which report is to be set. It should be - HID_INPUT_REPORT, - HID_OUTPUT_REPORT, or - HID_FEATURE_REPORT. The value of the report is - specified by the hgd_data and the - hgd_maxlen fields. On a device which uses numbered - reports, the first byte of data to be sent is the report number. The - report data begins from the second byte. For devices which do not use - numbered reports, the report data begins at the first byte. This call may - fail if the device does not support this feature.
-
- (struct hidraw_device_info)
-
Returns information about the device, like vendor ID and product ID. This - call will not issue any hardware transfers.
-
-

Linux hidraw -compatible calls:

-
-
- (int)
-
Get the HID report descriptor size. Returns the size of the device report - descriptor to use with HIDIOCGRDESC - ioctl(2).
-
- (struct hidraw_report_descriptor)
-
Get the HID report descriptor. Copies a maximum of - size bytes of the report descriptor data into the - memory specified by value. -
- 
struct hidraw_report_descriptor {
-	uint32_t	size;
-	uint8_t		value[HID_MAX_DESCRIPTOR_SIZE];
-};
-
-
-
- (struct hidraw_devinfo)
-
Get structure containing the bus type, the vendor ID (VID), and product ID - (PID) of the device. The bus type can be one of: - BUS_USB or BUS_I2C which - are defined in dev/evdev/input.h. -
- 
struct hidraw_devinfo {
-	uint32_t	bustype;
-	int16_t		vendor;
-	int16_t		product;
-};
-
-
-
- (char[] buf)
-
Get device description. Copies a maximum of len - bytes of the device description previously set with - device_set_desc(9) procedure into the memory specified - by buf.
-
- (char[] buf)
-
Get the newbus path to the device. Copies a maximum of - len bytes of the newbus device path into the memory - specified by buf.
-
- (void[] buf)
-
 
-
- (void[] buf)
-
 
-
- (void[] buf)
-
Get respectively a feature, input or output report from the device. Copies - a maximum of len bytes of the report data into the - memory specified by buf. The first byte of the - supplied buffer should be set to the report number of the requested - report. For devices which do not use numbered reports, set the first byte - to 0. The report will be returned starting at the first byte of the buffer - (ie: the report number is not returned). This call may fail if the device - does not support this feature.
-
- (void[] buf)
-
 
-
- (void[] buf)
-
 
-
- (void[] buf)
-
Set respectively a feature, input or output Report in the device. The - value of the report is specified by the buf and the - len parameters. Set the first byte of the supplied - buffer to the report number. For devices which do not use numbered - reports, set the first byte to 0. The report data begins in the second - byte. Make sure to set len accordingly, to one more than the length of the - report (to account for the report number). This call may fail if the - device does not support this feature.
-
-

Use read(2) to get data from the device. Data - should be read in chunks of the size prescribed by the report descriptor. On - a device which uses numbered reports, the first byte of the returned data is - the report number. The report data begins from the second byte. For devices - which do not use numbered reports, the report data begins at the first - byte.

-

Use write(2) to send data to the device. Data - should be written in chunks of the size prescribed by the report descriptor. - The first byte of the buffer passed to write(2) should be - set to the report number. If the device does not use numbered reports, there - are 2 operation modes: hidraw mode and - uhid(4) mode. In the hidraw mode, - the first byte should be set to 0 and the report data itself should begin at - the second byte. In the uhid(4) mode, the report data - should begin at the first byte. The modes can be switched with issuing one - of HIDIOCGRDESC or - HID_GET_REPORT_DESC ioctl(2) - accordingly. Default mode is hidraw.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.hid.hidraw.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/hidraw?
-
 
-
-
-
-

-

usbhidctl(1), hid(4), - hidbus(4), uhid(4)

-
-
-

-

The uhid(4) driver appeared in - NetBSD 1.4. hidraw protocol - support was added in FreeBSD 13 by - Vladimir Kondratyev - <wulf@FreeBSD.org>. - This manual page was adopted from NetBSD by - Tom Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
- - - - - -
April 27, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/hkbd.4 3.html b/static/freebsd/man4/hkbd.4 3.html deleted file mode 100644 index 25add3dc..00000000 --- a/static/freebsd/man4/hkbd.4 3.html +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - -
HKBD(4)Device Drivers ManualHKBD(4)
-
-
-

-

hkbd — HID - keyboard driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hkbd -
-device hid -
-device hidbus -
-device evdev -
-options EVDEV_SUPPORT
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hkbd_load="YES"
-
-
-
-

-

The hkbd driver provides support for - keyboards that attach to the HID transport backend. - hid(4), hidbus(4), and one of - iichid(4) or usbhid(4) must be - configured in the kernel as well.

-
-
-

-

By default, the keyboard subsystem does not create the appropriate - devices yet. Make sure you reconfigure your kernel with the following option - in the kernel config file:

-

-
options KBD_INSTALL_CDEV
-

If both an AT keyboard HID keyboards are used at the same time, - the AT keyboard will appear as kbd0 in - /dev. The HID keyboards will be - kbd1, kbd2, etc. You can see - some information about the keyboard with the following command:

-

-
kbdcontrol -i < - /dev/kbd1
-

or load a keymap with

-

-
kbdcontrol -l keymaps/pt.iso < - /dev/kbd1
-

See kbdcontrol(1) for more possible options.

-

You can swap console keyboards by using the command

-

-
kbdcontrol -k /dev/kbd1
-

From this point on, the first HID keyboard will be the keyboard to - be used by the console.

-

If you want to use a HID keyboard as your default and - not use an AT keyboard at all, you will have to remove the - device atkbd line from the kernel configuration - file. Because of the device initialization order, the HID keyboard will be - detected the - console driver initializes itself and you have to explicitly tell the - console driver to use the existence of the HID keyboard. This can be done in - one of the following two ways.

-

Run the following command as a part of system initialization:

-

-
kbdcontrol -k /dev/kbd0 < - /dev/ttyv0 > /dev/null
-

(Note that as the HID keyboard is the only keyboard, it is - accessed as /dev/kbd0) or otherwise tell the console - driver to periodically look for a keyboard by setting a flag in the kernel - configuration file:

-

-
device sc0 at isa? flags - 0x100
-

With the above flag, the console driver will try to detect any - keyboard in the system if it did not detect one while it was initialized at - boot time.

-
-
-

-
options KBD_INSTALL_CDEV
-

Make the keyboards available through a character device in - /dev.

-

-
options HKBD_DFLT_KEYMAP
-
makeoptions - HKBD_DFLT_KEYMAP=fr.iso
-

The above lines will put the French ISO keymap in the ukbd driver. - You can specify any keymap in - /usr/share/syscons/keymaps or - /usr/share/vt/keymaps (depending on the console - driver being used) with this option.

-

-
options - KBD_DISABLE_KEYMAP_LOADING
-

Do not allow the user to change the keymap. Note that these - options also affect the AT keyboard driver, atkbd(4).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.hid.hkbd.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
hw.hid.hkbd.apple_swap_cmd_opt
-
Swap the Command & Option keys on Apple keyboards if set to 1. Default - is 0.
-
hw.hid.hkbd.apple_swap_cmd_ctl
-
Swap the Command & Control keys on Apple keyboards if set to 1. - Default is 0.
-
hw.hid.hkbd.apple_fn_mode
-
Direct access to media keys without holding Fn if set to 1. Default is - 0.
-
hw.hid.hkbd.no_leds
-
Disables setting of keyboard LEDs if set to 1. Default is 0.
-
-
-
-

-
-
/dev/kbd*
-
blocking device nodes
-
/dev/input/event*
-
input event device nodes.
-
-
-
-

-
device hkbd
-

Add the hkbd driver to the kernel.

-
-
-

-

kbdcontrol(1), hid(4), - hidbus(4), iichid(4), - syscons(4), usbhid(4), - vt(4), config(8)

-
-
-

-

The hkbd driver was written by - Lennart Augustsson - <augustss@cs.chalmers.se> - for NetBSD and was substantially rewritten for - FreeBSD by Kazutaka YOKOTA - <yokota@zodiac.mech.utsunomiya-u.ac.jp>.

-

This manual page was written by Nick Hibma - <n_hibma@FreeBSD.org> - with a large amount of input from Kazutaka YOKOTA - <yokota@zodiac.mech.utsunomiya-u.ac.jp>.

-
-
- - - - - -
April 23, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/hms.4 4.html b/static/freebsd/man4/hms.4 4.html deleted file mode 100644 index 22a7c594..00000000 --- a/static/freebsd/man4/hms.4 4.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
HMS(4)Device Drivers ManualHMS(4)
-
-
-

-

hms — HID mouse - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device hms -
-device hidbus -
-device hid -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hms_load="YES"
-
-
-
-

-

The hms driver provides support for HID - mice that attach to the HID transport backend. See - iichid(4) or usbhid(4). Supported are - mice with any number of buttons, mice with a wheel and absolute mice.

-

The /dev/input/eventX device presents the - mouse as a evdev type device.

-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.hms.X.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-

It default value is derived from loader(8) - tunable:

-
-
hw.hid.hms.debug
-
 
-
-
-
-

-
-
/dev/input/eventX
-
input event device node.
-
-
-
-

-

iichid(4), usbhid(4), - xorg.conf(5) (ports/x11/xorg)

-
-
-

-

hms cannot act like - sysmouse(4)

-
-
-

-

The hms driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-

This manual page was originally written by Nick - Hibma - <n_hibma@FreeBSD.org> - for umt(4) driver and was adopted for - hms by Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
September 12, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/hmt.4 3.html b/static/freebsd/man4/hmt.4 3.html deleted file mode 100644 index 3fbd08a8..00000000 --- a/static/freebsd/man4/hmt.4 3.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
HMT(4)Device Drivers ManualHMT(4)
-
-
-

-

hmt — MS Windows - 7/8/10 - compatible HID multi-touch device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device hmt -
-device hidbus -
-device hid -
-device hconf -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hmt_load="YES"
-
-
-
-

-

The hmt driver provides support for the MS - Windows 7/8/10 - compatible HID multi-touch devices found in many - laptops.

-

To get multi-touch device working in X(7) - (ports/x11/xorg-docs), install - ports/x11-drivers/xf86-input-evdev.

-
-
-

-

hmt creates a pseudo-device file, - /dev/input/eventX which presents the multi-touch - device as an input event device.

-
-
-

-

hid(4), loader.conf(5), - xorg.conf(5) (ports/x11/xorg), - evdev(4) - (ports/x11-drivers/xf86-input-evdev).

-
-
-

-

The hmt driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
-

-

hmt cannot act like - sysmouse(4)

-
-
- - - - - -
August 11, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/hpen.4 4.html b/static/freebsd/man4/hpen.4 4.html deleted file mode 100644 index b75aa83c..00000000 --- a/static/freebsd/man4/hpen.4 4.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - -
HPEN(4)Device Drivers ManualHPEN(4)
-
-
-

-

hpen — MS Windows - compatible HID pen tablet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device hpen -
-device hid -
-device hidbus -
-device hidmap -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hpen_load="YES"
-
-
-
-

-

The hpen driver provides support for - generic MS Windows compatible HID pen tablet and digitizer that attach to - the HID transport backend. See iichid(4) or - usbhid(4).

-

The /dev/input/event* device presents the - pen as a evdev type device.

-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.hpen.X.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-

It's default value is set with loader(8) - tunable:

-
-
hw.hid.hpen.debug
-
 
-
-
-
-

-
-
/dev/input/event*
-
input event device node.
-
-
-
-

-

iichid(4), usbhid(4), - xorg.conf(5) (ports/x11/xorg)

-
-
-

-

hpen cannot act like - sysmouse(4).

-

Pen battery charge level reporting is not supported.

-
-
-

-

The hpen driver first appeared in - FreeBSD 13.0.

-
-
-

-

The hpen driver was written by - Val Packett - <val@packett.cool>.

-

This manual page was written by Vladimir - Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
September 14, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/hpet.4 3.html b/static/freebsd/man4/hpet.4 3.html deleted file mode 100644 index f3988d55..00000000 --- a/static/freebsd/man4/hpet.4 3.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - -
HPET(4)Device Drivers ManualHPET(4)
-
-
-

-

hpet — High - Precision Event Timer driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device acpi
-

The following tunables are settable from the - loader(8):

-
-
hint.hpet.X.allowed_irqs
-
is a 32bit mask. Each set bit allows driver to use respective IRQ, if BIOS - also set respective capability bit in comparator's configuration register. - Default value is 0xffff0000, except some known broken hardware.
-
hint.hpet.X.clock
-
controls event timers functionality support. Setting to 0, disables it. - Default value is 1.
-
hint.hpet.X.legacy_route
-
controls "LegacyReplacement Route" mode. If enabled, HPET will - steal IRQ0 of i8254 timer and IRQ8 of RTC. Before using it, make sure that - respective drivers are not using interrupts, by setting also: -
- 
hint.attimer.0.clock=0
-hint.atrtc.0.clock=0
-
- Default value is 0.
-
hint.hpet.X.per_cpu
-
controls how much per-CPU event timers should driver attempt to register. - This functionality requires every comparator in a group to have own - unshared IRQ, so it depends on hardware capabilities and interrupts - configuration. Default value is 1.
-
-
-
-

-

This driver uses High Precision Event Timer hardware (part of the - chipset, usually enumerated via ACPI) to supply kernel with one time counter - and several (usually from 3 to 8) event timers. This hardware includes - single main counter with known increment frequency (10MHz or more), and - several programmable comparators (optionally with automatic reload feature). - When value of the main counter matches current value of any comparator, - interrupt can be generated. Depending on hardware capabilities and - configuration, interrupt can be delivered as regular I/O APIC interrupt (ISA - or PCI) in range from 0 to 31, or as Front Side Bus interrupt, alike to PCI - MSI interrupts, or in so called "LegacyReplacement Route" HPET can - steal IRQ0 of i8254 and IRQ8 of the RTC. Interrupt can be either edge- or - level-triggered. In last case they could be safely shared with PCI IRQs. - Driver prefers to use FSB interrupts, if supported, to avoid sharing. If it - is not possible, it uses single sharable IRQ from PCI range. Other modes - (LegacyReplacement and ISA IRQs) require special care to setup, but could be - configured manually via device hints.

-

Event timers provided by the driver support both one-shot an - periodic modes and irrelevant to CPU power states.

-

Depending on hardware capabilities and configuration, driver can - expose each comparator as separate event timer or group them into one or - several per-CPU event timers. In last case interrupt of every of those - comparators within group is bound to specific CPU core. This is possible - only when each of these comparators has own unsharable IRQ.

-
-
-

-

acpi(4), apic(4), - atrtc(4), attimer(4), - eventtimers(4), timecounters(4)

-
-
-

-

The hpet driver first appeared in - FreeBSD 6.3. Support for event timers was added in - FreeBSD 9.0.

-
-
- - - - - -
September 14, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/hpt27xx.4 3.html b/static/freebsd/man4/hpt27xx.4 3.html deleted file mode 100644 index c3e469d2..00000000 --- a/static/freebsd/man4/hpt27xx.4 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
HPT27XX(4)Device Drivers ManualHPT27XX(4)
-
-
-

-

hpt27xx — - HighPoint RocketRAID 27xx SAS 6Gb/s HBA card - driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hpt27xx
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hpt27xx_load="YES"
-
-
-
-

-

The hpt27xx driver provides support for - HighPoint's RocketRAID 27xx based RAID controller.

-

These devices support SAS disk drives and provide RAID0 - (striping), RAID1 (mirroring), and RAID5 functionality.

-
-
-

-

The hpt27xx driver supports the following - SAS controllers:

-

-
    -
  • HighPoint's RocketRAID 271x series
    • -
  • HighPoint's RocketRAID 272x series
    • -
  • HighPoint's RocketRAID 274x series
    • -
  • HighPoint's RocketRAID 276x series
    • -
  • HighPoint's RocketRAID 278x series
    • -
-
-
-

-

The hpt27xx driver only works on the i386 - and amd64 platforms as it requires a binary blob object from the - manufacturer which they only supply for these platforms. The - hpt27xx driver does - work on - i386 with pae(4) enabled.

-
-
-

-

kld(4), kldload(8), - loader(8)

-
-
-

-

The hpt27xx device driver first appeared - in FreeBSD 10.0.

-
-
-

-

The hpt27xx device driver was written by - HighPoint Technologies, Inc.. This manual page was - written by Xin LI - <delphij@FreeBSD.org> - for iXsystems, Inc.

-
-
- - - - - -
December 28, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/hptiop.4 3.html b/static/freebsd/man4/hptiop.4 3.html deleted file mode 100644 index 7d9345e3..00000000 --- a/static/freebsd/man4/hptiop.4 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
HPTIOP(4)Device Drivers ManualHPTIOP(4)
-
-
-

-

hptiop — HighPoint - RocketRAID 3xxx/4xxx device driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hptiop -
-device scbus -
-device da
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hptiop_load="YES"
-
-
-
-

-

The hptiop driver provides support for the - HighPoint RocketRAID 3xxx/4xxx series of SAS and SATA RAID controllers.

-
-
-

-

The hptiop driver supports the following - SAS and SATA RAID controllers:

-

-
    -
  • HighPoint RocketRAID 4522
    • -
  • HighPoint RocketRAID 4521
    • -
  • HighPoint RocketRAID 4520
    • -
  • HighPoint RocketRAID 4322
    • -
  • HighPoint RocketRAID 4321
    • -
  • HighPoint RocketRAID 4320
    • -
  • HighPoint RocketRAID 4311
    • -
  • HighPoint RocketRAID 4310
    • -
  • HighPoint RocketRAID 3640
    • -
  • HighPoint RocketRAID 3622
    • -
  • HighPoint RocketRAID 3620
    • -
-

The hptiop driver also supports the - following SAS and SATA RAID controllers that are already End-of-Life:

-

-
    -
  • HighPoint RocketRAID 4211
    • -
  • HighPoint RocketRAID 4210
    • -
  • HighPoint RocketRAID 3560
    • -
  • HighPoint RocketRAID 3540
    • -
  • HighPoint RocketRAID 3530
    • -
  • HighPoint RocketRAID 3522
    • -
  • HighPoint RocketRAID 3521
    • -
  • HighPoint RocketRAID 3520
    • -
  • HighPoint RocketRAID 3511
    • -
  • HighPoint RocketRAID 3510
    • -
  • HighPoint RocketRAID 3410
    • -
  • HighPoint RocketRAID 3320
    • -
  • HighPoint RocketRAID 3220
    • -
  • HighPoint RocketRAID 3122
    • -
  • HighPoint RocketRAID 3120
    • -
  • HighPoint RocketRAID 3020
    • -
-
-
-

-

The hptiop driver has only been tested on - the i386 and amd64 platforms.

-
-
-

-

cam(4), hptmv(4)

-
-
-

-

The hptiop device driver first appeared in - FreeBSD 7.0.

-
-
-

-

The hptiop driver was written by - HighPoint Technologies, Inc.

-
-
- - - - - -
July 5, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hptmv.4 3.html b/static/freebsd/man4/hptmv.4 3.html deleted file mode 100644 index 8b17375a..00000000 --- a/static/freebsd/man4/hptmv.4 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
HPTMV(4)Device Drivers ManualHPTMV(4)
-
-
-

-

hptmv — HighPoint - RocketRAID 182x device driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hptmv
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hptmv_load="YES"
-
-
-
-

-

The hptmv driver provides support for - HighPoint's RocketRAID 182x based RAID controller.

-

These devices support ATA disk drives and provide RAID0 - (striping), RAID1 (mirroring), and RAID5 functionality.

-
-
-

-

The hptmv driver supports the following - ATA RAID controllers:

-

-
    -
  • HighPoint's RocketRAID 182x series
    • -
-
-
-

-

The hptmv driver only works on the i386 - and amd64 platforms as it requires a binary blob object from the - manufacturer which they only supply for these platforms. The - hptmv driver does - work on - i386 with pae(4) enabled.

-
-
-

-

kld(4), kldload(8), - loader(8)

-
-
-

-

The hptmv device driver first appeared in - FreeBSD 5.3.

-
-
-

-

The hptmv device driver was written by - HighPoint Technologies, Inc., and ported to - FreeBSD by Scott Long. This - manual page was written by David E. O'Brien.

-
-
-

-

The hptmv driver does not support - manipulating the RAID from the OS, RAIDs need to be set up from the on-board - BIOS.

-
-
- - - - - -
November 17, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/hptnr.4 4.html b/static/freebsd/man4/hptnr.4 4.html deleted file mode 100644 index f297ae7d..00000000 --- a/static/freebsd/man4/hptnr.4 4.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
HPTNR(4)Device Drivers ManualHPTNR(4)
-
-
-

-

hptnr — HighPoint - DC Series Data Center HBA card driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hptnr
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hptnr_load="YES"
-
-
-
-

-

The hptnr driver provides support for - HighPoint's DC Series Data Center HBA card.

-
-
-

-

The hptnr driver supports the following - SATA controllers:

-

-
    -
  • HighPoint's DC7280 series
    • -
  • HighPoint's Rocket R750 series
    • -
-
-
-

-

The hptnr driver only works on the i386 - and amd64 platforms as it requires a binary blob object from the - manufacturer which they only supply for these platforms. The - hptnr driver does - work on - i386 with pae(4) enabled.

-
-
-

-

kld(4), kldload(8), - loader(8)

-
-
-

-

The hptnr device driver first appeared in - FreeBSD 9.2.

-
-
-

-

The hptnr device driver was written by - HighPoint Technologies, Inc.. This manual page was - written by Xin LI - <delphij@FreeBSD.org> - for iXsystems, Inc.

-
-
- - - - - -
July 5, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hptrr.4 3.html b/static/freebsd/man4/hptrr.4 3.html deleted file mode 100644 index 216538df..00000000 --- a/static/freebsd/man4/hptrr.4 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
HPTRR(4)Device Drivers ManualHPTRR(4)
-
-
-

-

hptrr — HighPoint - RocketRAID device driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device hptrr -
-device scbus -
-device da
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hptrr_load="YES"
-
-

The following tunables are settable from the loader:

-
-
hw.hptrr.attach_generic
-
set to 1 to permit driver attach to chips with generic Marvell - (non-HighPoint) PCI identification. These chips are also supported by - ata(4) and mvs(4). Some vendors are - using same chips, but without providing RAID BIOS.
-
-
-
-

-

The hptrr driver provides support for - HighPoint's RocketRAID based RAID controllers.

-

These devices support SATA/ATA disk drives and provide RAID0 - (striping), RAID1 (mirroring), and RAID5 functionality.

-
-
-

-

The hptrr driver supports the following - RAID controllers:

-

-
    -
  • RocketRAID 172x series
    • -
  • RocketRAID 174x series
    • -
  • RocketRAID 2210
    • -
  • RocketRAID 222x series
    • -
  • RocketRAID 2240
    • -
  • RocketRAID 230x series
    • -
  • RocketRAID 231x series
    • -
  • RocketRAID 232x series
    • -
  • RocketRAID 2340
    • -
  • RocketRAID 2522
    • -
-
-
-

-

The hptrr driver only works on the i386 - and amd64 platforms as it requires a binary blob object from the - manufacturer which they only supply for these platforms. The - hptrr driver does - work on - i386 with pae(4) enabled.

-

This driver does not support the RR182x series controller. See the - hptmv(4) manual page for details on support.

-

This driver supersedes the older rr232x driver.

-
-
-

-

ata(4), cam(4), - hptmv(4), mvs(4), - loader(8)

-
-
-

-

The hptrr device driver first appeared in - FreeBSD 6.3.

-
-
-

-

The hptrr device driver was written by - HighPoint Technologies, Inc., and ported to - FreeBSD by Scott Long. This - manual page was written by David E. O'Brien.

-
-
-

-

The hptrr driver does not support - manipulating the RAID from the OS, RAIDs need to be set up from the on-board - BIOS.

-
-
- - - - - -
June 6, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/hsctrl.4 4.html b/static/freebsd/man4/hsctrl.4 4.html deleted file mode 100644 index 9af4e176..00000000 --- a/static/freebsd/man4/hsctrl.4 4.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
HSCTRL(4)Device Drivers ManualHSCTRL(4)
-
-
-

-

hsctrl — HID - system controls driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device hsctrl -
-device hid -
-device hidbus -
-device hidmap -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
hsctrl_load="YES"
-
-
-
-

-

The hsctrl driver provides support for HID - system controls most often used as "Power off/Sleep keys" found on - many keyboards.

-

The /dev/input/event* device presents the - consumer page controls as a evdev type device.

-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.hsctrl.X.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-

It default value is set with loader(8) - tunable:

-
-
hw.hid.hsctrl.debug
-
 
-
-
-
-

-
-
/dev/input/event*
-
input event device node.
-
-
-
-

-

iichid(4), usbhid(4)

-
-
-

-

The hsctrl driver first appeared in - FreeBSD 13.0.

-
-
-

-

The hsctrl driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
January 26, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/htu21.4 3.html b/static/freebsd/man4/htu21.4 3.html deleted file mode 100644 index 71ac5903..00000000 --- a/static/freebsd/man4/htu21.4 3.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - -
HTU21(4)Device Drivers ManualHTU21(4)
-
-
-

-

htu21 — driver for - HTU21D and compatible temperature and humidity sensors

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device htu21 -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
htu21_load="YES"
-
-
-
-

-

The htu21 driver provides temperature and - relative humidity readings over I2C bus for the supported sensors:

-
    -
  • HTU21D
    • -
  • SHT21
    • -
  • Si7021
    • -
-

The htu21 driver reports data via - sysctl(8) entries in the device's node in the - sysctl(8) tree:

-
-
temperature
-
The temperature, in hundredths of Kelvin.
-
humidity
-
The relative humidity, in hundredths of a percent.
-
crc_errors
-
The number of CRC errors in reading the measurements from the device.
-
power
-
The good power indication. This can be useful with battery powered - sensors.
-
heater
-
The built-in heater control. The heater can be used for testing and for - recovery from saturation after high humidity.
-
hold_bus
-
Whether the sensor should hold SCL low while performing the measurement. - Normally, the sensor releases the bus and NACKs all accessed until the - measurement is completed. The hold mode may be useful in mult-master - environments.
-
-

On an FDT(4) based system the following - properties must be set:

-
-
compatible
-
Must be set to "meas,htu21".
-
reg
-
The I2C address of htu21. Although, it is - hard-wired to 0x40 (7-bit) on all supported sensors.
-
-

The DTS part for a htu21 device usually - looks like:

-
-
/ {
-
-	...
-	htu21d {
-		compatible = "meas,htu21";
-		reg = <0x40>;
-	};
-};
-
-
-
-

-

fdt(4), iicbus(4), - sysctl(8)

-
-
-

-

The htu21 driver and this manual page was - written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
-

-

There is no way to control the measurement resolution.

-

Some sensor variants do not provide a serial number or use an - incompatible format. The htu21 driver does not - distinguish those variants and may complain about incorrect serial number - checksum.

-
-
- - - - - -
January 19, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/hv_kvp.4 3.html b/static/freebsd/man4/hv_kvp.4 3.html deleted file mode 100644 index 792b9e59..00000000 --- a/static/freebsd/man4/hv_kvp.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
HYPER-V(4)Device Drivers ManualHYPER-V(4)
-
-
-

-

hv_kvp — Hyper-V - Key Value Pair Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in the system kernel configuration file:

-
device hyperv
-
-
-

-

The hv_kvp driver provides the ability to - store, retrieve, modify and delete key value pairs for - FreeBSD guest partitions running on Hyper-V. Hyper-V - allows administrators to store custom metadata in the form of key value - pairs inside the FreeBSD guest partition. - Administrators can use Windows Powershell scripts to add, read, modify and - delete such key value pairs.

-

The driver is bare bones and merely forwards requests to its - counterpart user mode daemon, hv_kvp_daemon(8). The daemon - maintains pools of key value pairs and does the actual metadata - management.

-

The same driver and daemon combination are also used to set and - get IP addresses from a FreeBSD guest.

-

The set functionality is particularly useful when the - FreeBSD guest is assigned a static IP address and is - failed over from one Hyper-V host to another. After failover, Hyper-V uses - the set IP functionality to automatically update the - FreeBSD guest's IP address to its original static - value.

-

On the other hand, the get IP functionality is used to update the - guest IP address in the Hyper-V management console window.

-
-
-

-

hv_ata_pci_disengage(4), - hv_netvsc(4), hv_storvsc(4), - hv_utils(4), hv_vmbus(4), - hv_kvp_daemon(8)

-
-
-

-

Support for hv_kvp first appeared in - FreeBSD 10.0. The driver was developed through a - joint effort between Citrix Incorporated, Microsoft Corporation and Network - Appliance Incorporated.

-
-
-

-

FreeBSD support for - hv_kvp was first added by Microsoft - BSD Integration Services Team - <bsdic@microsoft.com>.

-
-
- - - - - -
September 10, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hv_netvsc.4 3.html b/static/freebsd/man4/hv_netvsc.4 3.html deleted file mode 100644 index 931e50f2..00000000 --- a/static/freebsd/man4/hv_netvsc.4 3.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
HYPER-V(4)Device Drivers ManualHYPER-V(4)
-
-
-

-

hv_netvsc — - Hyper-V Network Virtual Service Consumer

-
-
-

-

To compile this driver into the kernel, place the following lines - in the system kernel configuration file:

-
device hyperv
-
-
-

-

The hv_netvsc driver implements the - virtual network device for FreeBSD guest partitions - running on Hyper-V. FreeBSD guest partitions running - on Hyper-V do not have direct access to network devices attached to the - Hyper-V server. Although a FreeBSD guest can access - network devices using Hyper-V's full emulation mode, the performance in this - mode tends to be unsatisfactory.

-

To counter the above issues, the hv_netvsc - driver implements a network Virtual Service Consumer (VSC) that relays - network requests from the guest partition to the network Virtual Service - Provider (VSP) hosted in the root partition using the high performance data - exchange infrastructure provided by hv_vmbus(4) driver. - The VSP in the root partition then forwards the network related requests to - the physical network card.

-
-
-

-

hv_ata_pci_disengage(4), - hv_storvsc(4), hv_utils(4), - hv_vmbus(4)

-
-
-

-

Support for hv_netvsc first appeared in - FreeBSD 10.0. The driver was developed through a - joint effort between Citrix Incorporated, Microsoft Corporation, and Network - Appliance Incorporated.

-
-
-

-

FreeBSD support for - hv_netvsc was first added by - Microsoft BSD Integration Services Team - <bsdic@microsoft.com>.

-
-
- - - - - -
September 10, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hv_storvsc.4 3.html b/static/freebsd/man4/hv_storvsc.4 3.html deleted file mode 100644 index 0c220d56..00000000 --- a/static/freebsd/man4/hv_storvsc.4 3.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
HYPER-V(4)Device Drivers ManualHYPER-V(4)
-
-
-

-

hv_storvsc — - Hyper-V Storage Virtual Service Consumer

-
-
-

-

To compile this driver into the kernel, place the following lines - in the system kernel configuration file:

-
device hyperv
-
-
-

-

The hv_storvsc driver implements the - virtual store device for FreeBSD guest partitions - running on Hyper-V. FreeBSD guest partitions running - on Hyper-V do not have direct access to storage devices attached to the - Hyper-V server. Although a FreeBSD guest can access - storage devices using Hyper-V's full emulation mode, the performance in this - mode tends to be unsatisfactory.

-

To counter the above issues, the - hv_storvsc driver implements a storage Virtual - Service Consumer (VSC) that relays storage requests from the guest partition - to the storage Virtual Service Provider (VSP) hosted in the root partition - using the high performance data exchange infrastructure provided by - hv_vmbus(4) driver. The VSP in the root partition then - forwards the storage related requests to the physical storage device.

-

This driver functions by presenting a SCSI HBA interface to the - Common Access Method (CAM) layer. CAM control blocks (CCBs) are converted - into VSCSI protocol messages which are delivered to the root partition VSP - over the Hyper-V VMBus.

-
-
-

-

hv_ata_pci_disengage(4), - hv_netvsc(4), hv_utils(4), - hv_vmbus(4)

-
-
-

-

Support for hv_storvsc first appeared in - FreeBSD 10.0. The driver was developed through a - joint effort between Citrix Incorporated, Microsoft Corporation, and Network - Appliance Incorporated.

-
-
-

-

FreeBSD support for - hv_storvsc was first added by - Microsoft BSD Integration Services Team - <bsdic@microsoft.com>.

-
-
- - - - - -
September 10, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hv_utils.4 3.html b/static/freebsd/man4/hv_utils.4 3.html deleted file mode 100644 index d9c6a6fb..00000000 --- a/static/freebsd/man4/hv_utils.4 3.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
HYPER-V(4)Device Drivers ManualHYPER-V(4)
-
-
-

-

hv_utils — Hyper-V - Utilities Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in the system kernel configuration file:

-
device hyperv
-
-
-

-

The hv_utils driver provides time keeping, - shutdown and heartbeat functionality for FreeBSD - guest partitions running on Hyper-V. Hyper-V is a hypervisor-based - virtualization technology from Microsoft. The - hv_utils driver is one of the core drivers required - to be present in guest partitions running on Hyper-V. This driver provides - the following functionalities to guest partitions:

-

(a) Time Keeping: The clock inside the guest partition will remain - accurate by synchronizing to the clock on the virtualization server via - Timesync service, and with the help of the pluggable time source device.

-

(b) Integrated shutdown: Guest partitions running - FreeBSD can be shut down from Hyper-V Manager - console by using the "Shut down" command.

-

(c) Heartbeat: This feature allows the virtualization server to - detect whether the guest partition is running and responsive.

-
-
-

-

hv_ata_pci_disengage(4), - hv_netvsc(4), hv_storvsc(4), - hv_vmbus(4)

-
-
-

-

Support for hv_utils first appeared in - FreeBSD 10.0. The driver was developed through a - joint effort between Citrix Incorporated, Microsoft Corporation, and Network - Appliance Incorporated.

-
-
-

-

FreeBSD support for - hv_utils was first added by - Microsoft BSD Integration Services Team - <bsdic@microsoft.com>.

-
-
- - - - - -
September 10, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hv_vmbus.4 3.html b/static/freebsd/man4/hv_vmbus.4 3.html deleted file mode 100644 index eb77f8f0..00000000 --- a/static/freebsd/man4/hv_vmbus.4 3.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
HYPER-V(4)Device Drivers ManualHYPER-V(4)
-
-
-

-

hv_vmbus — Hyper-V - Virtual Machine Bus (VMBus) Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in the system kernel configuration file:

-
device hyperv -
-device pci
-
-
-

-

The hv_vmbus provides a high performance - communication interface between guest and root partitions in Hyper-V. - Hyper-V is a hypervisor-based virtualization technology from Microsoft. - Hyper-V supports isolation in terms of a partition. A partition is a logical - unit of isolation, supported by the hypervisor, in which operating systems - execute.

-

The Microsoft hypervisor must have at least one parent, or root, - partition, running Windows Server operating system. The virtualization stack - runs in the parent partition and has direct access to the hardware devices. - The root partition then creates the child partitions which host the guest - operating systems.

-

Child partitions do not have direct access to other hardware - resources and are presented a virtual view of the resources, as virtual - devices (VDevs). Requests to the virtual devices are redirected either via - the VMBus or the hypervisor to the devices in the parent partition, which - handles the requests.

-

The VMBus is a logical inter-partition communication channel. The - parent partition hosts Virtualization Service Providers (VSPs) which - communicate over the VMBus to handle device access requests from child - partitions. Child partitions host Virtualization Service Consumers (VSCs) - which redirect device requests to VSPs in the parent partition via the - VMBus. The Hyper-V VMBus driver defines and implements the interface that - facilitate high performance bi-directional communication between the VSCs - and VSPs. All VSCs utilize the VMBus driver.

-
-
-

-

hv_netvsc(4), hv_storvsc(4), - hv_utils(4)

-
-
-

-

Support for hv_vmbus first appeared in - FreeBSD 10.0. The driver was developed through a - joint effort between Citrix Incorporated, Microsoft Corporation, and Network - Appliance Incorporated.

-
-
-

-

FreeBSD support for - hv_vmbus was first added by - Microsoft BSD Integration Services Team - <bsdic@microsoft.com>.

-
-
- - - - - -
September 10, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/hv_vss.4 3.html b/static/freebsd/man4/hv_vss.4 3.html deleted file mode 100644 index a66c4bc4..00000000 --- a/static/freebsd/man4/hv_vss.4 3.html +++ /dev/null @@ -1,348 +0,0 @@ - - - - - - -
HV_VSS(4)Device Drivers ManualHV_VSS(4)
-
-
-

-

hv_vss — Hyper-V - Volume Shadow Copy Service API

-
-
-

-

#include - <dev/hyperv/hv_snapshot.h>

-
-
#define VSS_SUCCESS		0x00000000
-#define VSS_FAIL		0x00000001
-
-enum hv_vss_op_t {
-	HV_VSS_NONE = 0,
-	HV_VSS_CHECK,
-	HV_VSS_FREEZE,
-	HV_VSS_THAW,
-	HV_VSS_COUNT
-};
-
-struct hv_vss_opt_msg {
-	uint32_t	opt;		/* operation */
-	uint32_t	status;		/* 0 for success, 1 for error */
-	uint64_t	msgid;		/* an ID used to identify the transaction */
-	uint8_t		reserved[48];	/* reserved values are all zeroes */
-};
-
-
-
-

-

The freeze or thaw functionality of application is important to - guarantee the application consistent backup. On windows platform, VSS is - defined to do live backup. But for VM guest running on Hyper-V, the - corresponding VSS is not defined yet. For example, a running database server - instance, it knows when the applications' freeze/thaw should start or - finish. But it is not aware of the freeze/thaw notification from Hyper-V - host. The hv_vss is designed to notify application - freeze/thaw request. Thus, it plays a role of broker to forward the - freeze/thaw command from Hyper-V host to userland application if it - registered VSS service on FreeBSD VM, and sends the - result back to Hyper-V host.

-

Generally, hv_vss_daemon(8) takes the - responsibility to freeze/thaw UFS file system, and it is automatically - launched after system boots. When Hyper-V host wants to take a snapshot of - the FreeBSD VM, it will first send VSS capability - check to FreeBSD VM. The - hv_vss received the request and forward the request - to userland application if it is registered. Only after - hv_vss received the VSS_SUCCESS response from - application, the hv_vss_daemon(8) will be informed to - check whether file system freeze/thaw is supported. Any error occurs during - this period, hv_vss will inform Hyper-V host that - VSS is not supported. In addition, there is a default timeout limit before - sending response to Hyper-V host. If the total response time from - application and hv_vss_daemon(8) exceeds this value, - timeout will occur and VSS unsupported is responded to Hyper-V host.

-

After Hyper-V host confirmed the FreeBSD - VM supports VSS, it will send freeze request to VM, and - hv_vss will first forward it to application. After - application finished freezing, it should inform - hv_vss and file system level freezing will be - triggered by hv_vss_daemon(8). After all freezing on both - application and hv_vss_daemon(8) were finished, the - hv_vss will inform Hyper-V host that freezing is - done. Of course, there is a timeout limit as same as VSS capability is set - to make sure freezing on FreeBSD VM is not hang. If - there is any error occurs or timeout happened, the freezing is failed on - Hyper-V side.

-

Hyper-V host will send thaw request after taking the snapshot, - typically, this period is very short in order not to block the running - application. hv_vss firstly thaw the file system by - notifying hv_vss_daemon(8), then notifies user registered - application. There is also a timeout check before sending response to - Hyper-V host.

-

All the default timeout limit used in VSS capability check, freeze - or thaw is the same. It is 15 seconds currently.

-
-
-

-

hv_vss only support UFS currently. If any - of file system partition is non UFS, the VSS capability check will fail. If - application does not register VSS, hv_vss only - support backup for file system level consistent. The device should be closed - before it was opened again. If you want to simultaneously open - "/dev/hv_appvss_dev" two or more times, an error (-1) will be - returned, and errno was set.

-

If hv_vss_daemon(8) was killed after system - boots, the VSS functionality will not work.

-
-
-

-

The following is a complete example which does nothing except for - waiting 2 seconds when receiving those notifications from - hv_vss

-
-
#include <string.h>
-#include <stdio.h>
-#include <sys/ioctl.h>
-#include <sys/param.h>
-#include <sys/ucred.h>
-#include <sys/mount.h>
-#include <sys/types.h>
-#include <unistd.h>
-#include <stdlib.h>
-#include <poll.h>
-#include <stdint.h>
-#include <syslog.h>
-#include <errno.h>
-#include <err.h>
-#include <fcntl.h>
-#include <ufs/ffs/fs.h>
-#include <paths.h>
-#include <sys/ioccom.h>
-#include <dev/hyperv/hv_snapshot.h>
-
-#define UNDEF_FREEZE_THAW	(0)
-#define FREEZE			(1)
-#define THAW			(2)
-#define CHECK			(3)
-
-#define	VSS_LOG(priority, format, args...) do	{				\
-		if (is_debugging == 1) {					\
-			if (is_daemon == 1)					\
-				syslog(priority, format, ## args);		\
-			else							\
-				printf(format, ## args);			\
-		} else {							\
-			if (priority < LOG_DEBUG) {				\
-				if (is_daemon == 1)				\
-					syslog(priority, format, ## args);	\
-				else						\
-					printf(format, ## args);		\
-			}							\
-		}								\
-	} while(0)
-
-#define CHECK_TIMEOUT		1
-#define CHECK_FAIL		2
-#define FREEZE_TIMEOUT		1
-#define FREEZE_FAIL		2
-#define THAW_TIMEOUT		1
-#define THAW_FAIL		2
-
-static int is_daemon        = 1;
-static int is_debugging     = 0;
-static int simu_opt_waiting = 2; // seconds
-
-#define GENERIC_OPT(TIMEOUT, FAIL)						\
-	do {									\
-		sleep(simu_opt_waiting);					\
-		if (opt == CHECK_TIMEOUT) {					\
-			sleep(simu_opt_waiting * 10);				\
-			VSS_LOG(LOG_INFO, "%s timeout simulation\n",		\
-			    __func__);						\
-			return (0);						\
-		} else if (opt == CHECK_FAIL) {					\
-			VSS_LOG(LOG_INFO, "%s failure simulation\n",		\
-			    __func__);						\
-			return (CHECK_FAIL);					\
-		} else {							\
-			VSS_LOG(LOG_INFO, "%s success simulation\n",		\
-			    __func__);						\
-			return (0);						\
-		}								\
-	} while (0)
-
-static int
-check(int opt)
-{
-	GENERIC_OPT(CHECK_TIMEOUT, CHECK_FAIL);
-}
-
-static int
-freeze(int opt)
-{
-	GENERIC_OPT(FREEZE_TIMEOUT, FREEZE_FAIL);
-}
-
-static int
-thaw(int opt)
-{
-	GENERIC_OPT(THAW_TIMEOUT, THAW_FAIL);
-}
-
-static void usage(const char* cmd) {
-	fprintf(stderr,
-	    "%s -f <0|1|2>: simulate app freeze."
-	    " 0: successful, 1: freeze timeout, 2: freeze failed\n"
-	    " -c <0|1|2>: simulate vss feature check"
-	    " -t <0|1|2>: simulate app thaw."
-	    " 0: successful, 1: freeze timeout, 2: freeze failed\n"
-	    " -d : enable debug mode\n"
-	    " -n : run this tool under non-daemon mode\n", cmd);
-}
-
-int
-main(int argc, char* argv[]) {
-	int ch, freezesimuop = 0, thawsimuop = 0, checksimuop = 0, fd, r, error;
-	uint32_t op;
-	struct pollfd app_vss_fd[1];
-	struct hv_vss_opt_msg  userdata;
-
-	while ((ch = getopt(argc, argv, "f:c:t:dnh")) != -1) {
-		switch (ch) {
-		case 'f':
-			/* Run as regular process for debugging purpose. */
-			freezesimuop = (int)strtol(optarg, NULL, 10);
-			break;
-		case 't':
-			thawsimuop = (int)strtol(optarg, NULL, 10);
-			break;
-		case 'c':
-			checksimuop = (int)strtol(optarg, NULL, 10);
-			break;
-		case 'd':
-			is_debugging = 1;
-			break;
-		case 'n':
-			is_daemon = 0;
-			break;
-		case 'h':
-		default:
-			usage(argv[0]);
-			exit(0);
-		}
-	}
-
-	openlog("APPVSS", 0, LOG_USER);
-	/* Become daemon first. */
-	if (is_daemon == 1)
-		daemon(1, 0);
-	else
-		VSS_LOG(LOG_DEBUG, "Run as regular process.\n");
-
-	VSS_LOG(LOG_INFO, "HV_VSS starting; pid is: %d\n", getpid());
-
-	fd = open(VSS_DEV(APP_VSS_DEV_NAME), O_RDWR);
-	if (fd < 0) {
-		VSS_LOG(LOG_ERR, "Fail to open %s, error: %d %s\n",
-		    VSS_DEV(APP_VSS_DEV_NAME), errno, strerror(errno));
-		exit(EXIT_FAILURE);
-	}
-	app_vss_fd[0].fd     = fd;
-	app_vss_fd[0].events = POLLIN | POLLRDNORM;
-
-	while (1) {
-		r = poll(app_vss_fd, 1, INFTIM);
-
-		VSS_LOG(LOG_DEBUG, "poll returned r = %d, revent = 0x%x\n",
-		    r, app_vss_fd[0].revents);
-
-		if (r == 0 || (r < 0 && errno == EAGAIN) ||
-		    (r < 0 && errno == EINTR)) {
-			/* Nothing to read */
-			continue;
-		}
-
-		if (r < 0) {
-			/*
-			 * For poll return failure other than EAGAIN,
-			 * we want to exit.
-			 */
-			VSS_LOG(LOG_ERR, "Poll failed.\n");
-			perror("poll");
-			exit(EIO);
-		}
-
-		/* Read from character device */
-		error = ioctl(fd, IOCHVVSSREAD, &userdata);
-		if (error < 0) {
-			VSS_LOG(LOG_ERR, "Read failed.\n");
-			perror("pread");
-			exit(EIO);
-		}
-
-		if (userdata.status != 0) {
-			VSS_LOG(LOG_ERR, "data read error\n");
-			continue;
-		}
-
-		op = userdata.opt;
-
-		switch (op) {
-		case HV_VSS_CHECK:
-			error = check(checksimuop);
-			break;
-		case HV_VSS_FREEZE:
-			error = freeze(freezesimuop);
-			break;
-		case HV_VSS_THAW:
-			error = thaw(thawsimuop);
-			break;
-		default:
-			VSS_LOG(LOG_ERR, "Illegal operation: %d\n", op);
-			error = VSS_FAIL;
-		}
-		if (error)
-			userdata.status = VSS_FAIL;
-		else
-			userdata.status = VSS_SUCCESS;
-		error = ioctl(fd, IOCHVVSSWRITE, &userdata);
-		if (error != 0) {
-			VSS_LOG(LOG_ERR, "Fail to write to device\n");
-			exit(EXIT_FAILURE);
-		} else {
-			VSS_LOG(LOG_INFO, "Send response %d for %s to kernel\n",
-			    userdata.status, op == HV_VSS_FREEZE ? "Freeze" :
-			    (op == HV_VSS_THAW ? "Thaw" : "Check"));
-		}
-	}
-	return 0;
-}
-
-
-
-

-

hv_utils(4), - hv_vss_daemon(8)

-
-
-

-

The daemon was introduced in October 2016 and developed by - Microsoft Corp.

-
-
-

-

FreeBSD support for - hv_vss was first added by Microsoft - BSD Integration Services Team - <bsdic@microsoft.com>.

-
-
- - - - - -
October 12, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/hwpmc.4 3.html b/static/freebsd/man4/hwpmc.4 3.html deleted file mode 100644 index a1ad831b..00000000 --- a/static/freebsd/man4/hwpmc.4 3.html +++ /dev/null @@ -1,755 +0,0 @@ - - - - - - -
HWPMC(4)Device Drivers ManualHWPMC(4)
-
-
-

-

hwpmc — Hardware - Performance Monitoring Counter support

-
-
-

-

The following option must be present in the kernel configuration - file:

-
options HWPMC_HOOKS
-

Additionally, for i386 systems:

-
device apic
-

To load the driver as a module at boot time:

-
-
sysrc kld_list+=hwpmc
-
-

Alternatively, to compile the driver into the kernel:

-
device hwpmc
-

To enable debugging features (see - DEBUGGING):

-
options KTR -
-options KTR_COMPILE=(KTR_SUBSYS) -
-options KTR_MASK=(KTR_SUBSYS) -
-options HWPMC_DEBUG
-
-
-

-

The hwpmc driver virtualizes the hardware - performance monitoring facilities in modern CPUs and provides support for - using these facilities from user level processes.

-

The driver supports multi-processor systems.

-

PMCs are allocated using the - PMC_OP_PMCALLOCATE request. A successful - PMC_OP_PMCALLOCATE request will return a handle to - the requesting process. Subsequent operations on the allocated PMC use this - handle to denote the specific PMC. A process that has successfully allocated - a PMC is termed an “owner process”.

-

PMCs may be allocated with process or system scope.

-
-
-
The PMC is active only when a thread belonging to a process it is attached - to is scheduled on a CPU.
-
-
The PMC operates independently of processes and measures hardware events - for the system as a whole.
-
-

PMCs may be allocated for counting or for sampling:

-
-
-
In counting modes, the PMCs count hardware events. These counts are - retrievable using the PMC_OP_PMCREAD system call - on all architectures. Some architectures offer faster methods of reading - these counts.
-
-
In sampling modes, the PMCs are configured to sample the CPU instruction - pointer (and optionally to capture the call chain leading up to the - sampled instruction pointer) after a configurable number of hardware - events have been observed. Instruction pointer samples and call chain - records are usually directed to a log file for subsequent analysis.
-
-

Scope and operational mode are orthogonal; a PMC may thus be - configured to operate in one of the following four modes:

-
-
Process-scope, counting
-
These PMCs count hardware events whenever a thread in their attached - process is scheduled on a CPU. These PMCs normally count from zero, but - the initial count may be set using the - PMC_OP_SETCOUNT operation. Applications can read - the value of the PMC anytime using the - PMC_OP_PMCRW operation.
-
Process-scope, sampling
-
These PMCs sample the target processes instruction pointer after they have - seen the configured number of hardware events. The PMCs only count events - when a thread belonging to their attached process is active. The desired - frequency of sampling is set using the - PMC_OP_SETCOUNT operation prior to starting the - PMC. Log files are configured using the - PMC_OP_CONFIGURELOG operation.
-
System-scope, counting
-
These PMCs count hardware events seen by them independent of the processes - that are executing. The current count on these PMCs can be read using the - PMC_OP_PMCRW request. These PMCs normally count - from zero, but the initial count may be set using the - PMC_OP_SETCOUNT operation.
-
System-scope, sampling
-
These PMCs will periodically sample the instruction pointer of the CPU - they are allocated on, and will write the sample to a log for further - processing. The desired frequency of sampling is set using the - PMC_OP_SETCOUNT operation prior to starting the - PMC. Log files are configured using the - PMC_OP_CONFIGURELOG operation. -

System-wide statistical sampling can only be enabled by a - process with super-user privileges.

-
-
-

Processes are allowed to allocate as many PMCs as the hardware and - current operating conditions permit. Processes may mix allocations of - system-wide and process-private PMCs. Multiple processes may be using PMCs - simultaneously.

-

Allocated PMCs are started using the - PMC_OP_PMCSTART operation, and stopped using the - PMC_OP_PMCSTOP operation. Stopping and starting a - PMC is permitted at any time the owner process has a valid handle to the - PMC.

-

Process-private PMCs need to be attached to a target process - before they can be used. Attaching a process to a PMC is done using the - PMC_OP_PMCATTACH operation. An already attached PMC - may be detached from its target process using the converse - PMC_OP_PMCDETACH operation. Issuing a - PMC_OP_PMCSTART operation on an as yet unattached - PMC will cause it to be attached to its owner process. The following rules - determine whether a given process may attach a PMC to another target - process:

-
    -
  • A non-jailed process with super-user privileges is allowed to attach to - any other process in the system.
    • -
  • Other processes are only allowed to attach to targets that they would be - able to attach to for debugging (as determined by - p_candebug(9)).
    • -
-

PMCs are released using PMC_OP_PMCRELEASE. - After a successful PMC_OP_PMCRELEASE operation the - handle to the PMC will become invalid.

-
-

-

The PMC_OP_PMCALLOCATE operation supports - the following flags that modify the behavior of an allocated PMC:

-
-
-
This modifier informs sampling PMCs to record a callchain when capturing a - sample. The maximum depth to which call chains are recorded is specified - by the kern.hwpmc.callchaindepth kernel - tunable.
-
-
This modifier is valid only for a PMC being allocated in process-private - mode. It signifies that the PMC will track hardware events for its target - process and the target's current and future descendants.
-
-
This modifier is valid only for a PMC being allocated in process-private - mode. When this modifier is present, at every context switch, - hwpmc will log a record containing the number of - hardware events seen by the target process when it was scheduled on the - CPU.
-
-
This modifier is valid only for a PMC being allocated in process-private - mode. With this modifier present, hwpmc will - maintain per-process counts for each target process attached to a PMC. At - process exit time, a record containing the target process' PID and the - accumulated per-process count for that process will be written to the - configured log file.
-
-

Modifiers PMC_F_LOG_PROCEXIT and - PMC_F_LOG_PROCCSW may be used in combination with - modifier PMC_F_DESCENDANTS to track the behavior of - complex pipelines of processes. PMCs with modifiers - PMC_F_LOG_PROCEXIT and - PMC_F_LOG_PROCCSW cannot be started until their - owner process has configured a log file.

-
-
-

-

The hwpmc driver may deliver signals to - processes that have allocated PMCs:

-
-
-
A PMC_OP_PMCRW operation was attempted on a - process-private PMC that does not have attached target processes.
-
-
The hwpmc driver is being unloaded from the - kernel.
-
-
-
-

-

A PMC row is defined as the set of PMC resources at the same - hardware address in the CPUs in a system. Since process scope PMCs need to - move between CPUs following their target threads, allocation of a process - scope PMC reserves all PMCs in a PMC row for use only with process scope - PMCs. Accordingly a PMC row will be in one of the following - dispositions:

-
-
-
Hardware counters in this row are free and may be use to satisfy either of - system scope or process scope allocation requests.
-
-
Hardware counters in this row are in use by process scope PMCs and are - only available for process scope allocation requests.
-
-
Some hardware counters in this row have been administratively disabled or - are in use by system scope PMCs. Non-disabled hardware counters in such a - row may be used for satisfying system scope allocation requests. No - process scope PMCs will use hardware counters in this row.
-
-
-
-
-

-

The API and ABI documented in this manual page may change in the - future. This interface is intended to be consumed by the - pmc(3) library; other consumers are unsupported. - Applications targeting PMCs should use the pmc(3) library - API.

-
-
-

-

The hwpmc driver operates using a system - call number that is dynamically allotted to it when it is loaded into the - kernel.

-

The hwpmc driver supports the following - operations:

-
-
-
Configure a log file for PMCs that require a log file. The - hwpmc driver will write log data to this file - asynchronously. If it encounters an error, logging will be stopped and the - error code encountered will be saved for subsequent retrieval by a - PMC_OP_FLUSHLOG request.
-
-
Transfer buffered log data inside hwpmc to a - configured output file. This operation returns to the caller after the - write operation has returned. The returned error code reflects any pending - error state inside hwpmc.
-
-
Retrieve the capabilities associated with a specific PMC counter. Some - capabilities may be limited to specific indices (i.e., not available - across all counters within a class).
-
-
Retrieve information about the highest possible CPU number for the system, - and the number of hardware performance monitoring counters available per - CPU.
-
-
Retrieve module statistics (for analyzing the behavior of - hwpmc itself).
-
-
Retrieve the version number of API.
-
-
Retrieve information about the current state of the PMCs on a given - CPU.
-
-
Set the administrative state (i.e., whether enabled or disabled) for the - hardware PMCs managed by the hwpmc driver. The - invoking process needs to possess the - PRIV_PMC_MANAGE privilege.
-
-
Allocate and configure a PMC. On successful allocation, a handle to the - PMC (a 32 bit value) is returned.
-
-
Attach a process mode PMC to a target process. The PMC will be active - whenever a thread in the target process is scheduled on a CPU. -

If the PMC_F_DESCENDANTS flag had been - specified at PMC allocation time, then the PMC is attached to all - current and future descendants of the target process.

-
-
-
Detach a PMC from its target process.
-
-
Release a PMC.
-
-
Read and write a PMC. This operation is valid only for PMCs configured in - counting modes.
-
-
Set the initial count (for counting mode PMCs) or the desired sampling - rate (for sampling mode PMCs).
-
-
Start a PMC.
-
-
Stop a PMC.
-
-
Insert a timestamped user record into the log file.
-
-
-

-

Some i386 family CPUs support the RDPMC instruction which allows a - user process to read a PMC value without needing to invoke a - PMC_OP_PMCRW operation. On such CPUs, the machine - address associated with an allocated PMC is retrievable using the - PMC_OP_PMCX86GETMSR system call.

-
-
-
Retrieve the MSR (machine specific register) number associated with the - given PMC handle. -

The PMC needs to be in process-private mode and allocated - without the PMC_F_DESCENDANTS modifier flag, and - should be attached only to its owner process at the time of the - call.

-
-
-
-
-

-

AMD64 CPUs support the RDPMC instruction which allows a user - process to read a PMC value without needing to invoke a - PMC_OP_PMCRW operation. The machine address - associated with an allocated PMC is retrievable using the - PMC_OP_PMCX86GETMSR system call.

-
-
-
Retrieve the MSR (machine specific register) number associated with the - given PMC handle. -

The PMC needs to be in process-private mode and allocated - without the PMC_F_DESCENDANTS modifier flag, and - should be attached only to its owner process at the time of the - call.

-
-
-
-
-
-

-

The behavior of hwpmc is influenced by the - following sysctl(8) and loader(8) - tunables:

-
-
kern.hwpmc.callchaindepth - (integer, read-only)
-
The maximum number of call chain records to capture per sample. The - default is 8.
-
kern.hwpmc.debugflags - (string, read-write)
-
(Only available if the hwpmc driver was compiled - with -DDEBUG.) Control the verbosity of debug - messages from the hwpmc driver.
-
kern.hwpmc.hashsize - (integer, read-only)
-
The number of rows in the hash tables used to keep track of owner and - target processes. The default is 16.
-
kern.hwpmc.logbuffersize - (integer, read-only)
-
The size in kilobytes of each log buffer used by - hwpmc's logging function. The default buffer size - is 256KB. The maximum value is 16MB.
-
kern.hwpmc.mincount - (integer, read-write)
-
The minimum sampling rate for sampling mode PMCs. The default count is - 1000 events.
-
kern.hwpmc.mtxpoolsize - (integer, read-only)
-
The size of the spin mutex pool used by the PMC driver. The default is - 32.
-
kern.hwpmc.nbuffers_pcpu - (integer, read-only)
-
The number of log buffers per CPU used by hwpmc - for logging. The default is 32. The product of - kern.hwpmc.nbuffers_pcpu and - kern.hwpmc.logbuffersize must not exceed 32MB per - CPU.
-
kern.hwpmc.nsamples - (integer, read-only)
-
The number of entries in the per-CPU ring buffer used during sampling. The - default is 512.
-
security.bsd.unprivileged_syspmcs - (boolean, read-write)
-
If set to non-zero, allow unprivileged processes to allocate system-wide - PMCs. The default value is 0.
-
security.bsd.unprivileged_proc_debug - (boolean, read-write)
-
If set to 0, the hwpmc driver will only allow - privileged processes to attach PMCs to other processes.
-
-

These variables may be set in the kernel environment using - kenv(1) before hwpmc is - loaded.

-
-
-

-
-

-

The kernel driver requires all physical CPUs in an SMP system to - have identical performance monitoring counter hardware.

-
-
-

-

On platforms that sparsely number CPUs and which support - hot-plugging of CPUs, requests that specify non-existent or disabled CPUs - will fail with an error. Applications allocating system-scope PMCs need to - be aware of the possibility of such transient failures.

-
-
-

-

Historically, on the x86 architecture, - FreeBSD has permitted user processes running at a - processor CPL of 3 to read the TSC using the RDTSC instruction. The - hwpmc driver preserves this behavior.

-
-
-

-

On CPUs with HTT support, Intel P4 PMCs are capable of qualifying - only a subset of hardware events on a per-logical CPU basis. Consequently, - if HTT is enabled on a system with Intel Pentium P4 PMCs, then the - hwpmc driver will reject allocation requests for - process-private PMCs that request counting of hardware events that cannot be - counted separately for each logical CPU.

-
-
-
-

-
-
hwpmc: [class/npmc/capabilities]...
-
Announce the presence of npmc PMCs of class - class, with capabilities described by bit string - capabilities.
-
hwpmc: kernel version (0x%x) does not match module version (0x%x).
-
The module loading process failed because a version mismatch was detected - between the currently executing kernel and the module being loaded.
-
hwpmc: this kernel has not been compiled with 'options HWPMC_HOOKS'.
-
The module loading process failed because the currently executing kernel - was not configured with the required configuration option - HWPMC_HOOKS.
-
hwpmc: tunable hashsize=%d must be greater than zero.
-
A negative value was supplied for tunable - kern.hwpmc.hashsize.
-
hwpmc: logbuffersize=%d must be greater than zero and less than or equal - to %d, resetting to %d.
-
A negative value was supplied for tunable - kern.hwpmc.logbuffersize.
-
hwpmc: nbuffers_pcpu=%d must be greater than zero, resetting to %d.
-
A negative value was supplied for tunable - kern.hwpmc.nbuffers_pcpu.
-
hwpmc: tunable nsamples=%d out of range.
-
The value for tunable kern.hwpmc.nsamples was - negative or greater than 65535.
-
hwpmc: nbuffers_pcpu=%d * logbuffersize=%d exceeds %dMB per CPU limit, - resetting to defaults (%d * %d).
-
The product of tunables kern.hwpmc.nbuffers_pcpu and - kern.hwpmc.logbuffersize exceeds the maximum per-CPU - memory limit. Both tunables are reset to their compiled defaults.
-
-
-
-

-

The hwpmc module can be configured to - record trace entries using the ktr(4) interface. This is - useful for debugging the driver's functionality, primarily during - development. This debugging functionality is not enabled by default, and - requires recompiling the kernel and hwpmc module - after adding the following to the kernel config:

-
-
options KTR
-options KTR_COMPILE=(KTR_SUBSYS)
-options KTR_MASK=(KTR_SUBSYS)
-options HWPMC_DEBUG
-
-

This alone is not enough to enable tracing; one must also - configure the kern.hwpmc.debugflags - sysctl(8) variable, which provides fine-grained control - over which types of events are logged to the trace buffer.

-

hwpmc trace events are grouped by 'major' - and 'minor' flag types. The major flag names are as follows:

-

-
-
-
cpu
-
CPU events
-
csw
-
Context switch events
-
logging
-
Logging events
-
md
-
Machine-dependent/class-dependent events
-
module
-
Miscellaneous events
-
owner
-
PMC owner events
-
pmc
-
PMC management events
-
process
-
Process events
-
sampling
-
Sampling events
-
-
-

The minor flags for each major flag group can vary. The individual - minor flag names are:

-
allocaterow, allocate, attach, bind, config, exec, - exit, find, flush, fork, getbuf, hook, init, intr, linktarget, mayberemove, - ops, read, register, release, remove, sample, scheduleio, select, signal, swi, - swo, start, stop, syscall, unlinktarget, write
-

The kern.hwpmc.debugflags variable is a - string with a custom format. The string should contain a space-separated - list of event specifiers. Each event specifier consists of the major flag - name, followed by an equal sign (=), followed by a comma-separated list of - minor event types. To track all events for a major group, an asterisk (*) - can be given instead of minor event names.

-

For example, to trace all allocation and release events, set - debugflags as follows:

-
-
kern.hwpmc.debugflags="pmc=allocate,release md=allocate,release"
-
-

To trace all events in the process and context switch major flag - groups:

-
-
kern.hwpmc.debugflags="process=* csw=*"
-
-

To disable all trace events, set the variable to an empty - string.

-
-
kern.hwpmc.debugflags=""
-
-

Trace events are recorded by ktr(4), and can be - inspected at run-time using the ktrdump(8) utility, or at - the ddb(4) prompt after a panic with the 'show ktr' - command.

-
-
-

-

A command issued to the hwpmc driver may - fail with the following errors:

-
-
[]
-
Helper process creation failed for a - PMC_OP_CONFIGURELOG request due to a temporary - resource shortage in the kernel.
-
[]
-
A PMC_OP_CONFIGURELOG operation was requested - while an existing log was active.
-
[]
-
A DISABLE operation was requested using the - PMC_OP_PMCADMIN request for a set of hardware - resources currently in use for process-private PMCs.
-
[]
-
A PMC_OP_PMCADMIN operation was requested on an - active system mode PMC.
-
[]
-
A PMC_OP_PMCATTACH operation was requested for a - target process that already had another PMC using the same hardware - resources attached to it.
-
[]
-
A PMC_OP_PMCRW request writing a new value was - issued on a PMC that was active.
-
[]
-
A PMC_OP_PMCSETCOUNT request was issued on a PMC - that was active.
-
[]
-
A PMC_OP_PMCSTART operation was requested without - a log file being configured for a PMC allocated with - PMC_F_LOG_PROCCSW and - PMC_F_LOG_PROCEXIT modifiers.
-
[]
-
A PMC_OP_PMCSTART operation was requested on a - system-wide sampling PMC without a log file being configured.
-
[]
-
A PMC_OP_PMCATTACH request was reissued for a - target process that already is the target of this PMC.
-
[]
-
A bad address was passed in to the driver.
-
[]
-
An invalid PMC handle was specified.
-
[]
-
An invalid CPU number was passed in for a - PMC_OP_GETPMCINFO operation.
-
[]
-
The pm_flags argument to a - PMC_OP_CONFIGURELOG request contained unknown - flags.
-
[]
-
A PMC_OP_CONFIGURELOG request to de-configure a - log file was issued without a log file being configured.
-
[]
-
A PMC_OP_FLUSHLOG request was issued without a log - file being configured.
-
[]
-
An invalid CPU number was passed in for a - PMC_OP_PMCADMIN operation.
-
[]
-
An invalid operation request was passed in for a - PMC_OP_PMCADMIN operation.
-
[]
-
An invalid PMC ID was passed in for a - PMC_OP_PMCADMIN operation.
-
[]
-
A suitable PMC matching the parameters passed in to a - PMC_OP_PMCALLOCATE request could not be - allocated.
-
[]
-
An invalid PMC mode was requested during a - PMC_OP_PMCALLOCATE request.
-
[]
-
An invalid CPU number was specified during a - PMC_OP_PMCALLOCATE request.
-
[]
-
A CPU other than PMC_CPU_ANY was specified in a - PMC_OP_PMCALLOCATE request for a process-private - PMC.
-
[]
-
A CPU number of PMC_CPU_ANY was specified in a - PMC_OP_PMCALLOCATE request for a system-wide - PMC.
-
[]
-
The pm_flags argument to an - PMC_OP_PMCALLOCATE request contained unknown - flags.
-
[]
-
(On Intel Pentium 4 CPUs with HTT support) A - PMC_OP_PMCALLOCATE request for a process-private - PMC was issued for an event that does not support counting on a - per-logical CPU basis.
-
[]
-
A PMC allocated for system-wide operation was specified with a - PMC_OP_PMCATTACH or - PMC_OP_PMCDETACH request.
-
[]
-
The pm_pid argument to a - PMC_OP_PMCATTACH or - PMC_OP_PMCDETACH request specified an illegal - process ID.
-
[]
-
A PMC_OP_PMCDETACH request was issued for a PMC - not attached to the target process.
-
[]
-
Argument pm_flags to a - PMC_OP_PMCRW request contained illegal flags.
-
[]
-
A PMC_OP_PMCX86GETMSR operation was requested for - a PMC not in process-virtual mode, or for a PMC that is not solely - attached to its owner process, or for a PMC that was allocated with flag - PMC_F_DESCENDANTS.
-
[]
-
A PMC_OP_WRITELOG request was issued for an owner - process without a log file configured.
-
[]
-
The system was not able to allocate kernel memory.
-
[]
-
(On i386 and amd64 architectures) A - PMC_OP_PMCX86GETMSR operation was requested for - hardware that does not support reading PMCs directly with the RDPMC - instruction.
-
[]
-
A PMC_OP_GETPMCINFO operation was requested for an - absent or disabled CPU.
-
[]
-
A PMC_OP_PMCALLOCATE operation specified - allocation of a system-wide PMC on an absent or disabled CPU.
-
[]
-
A PMC_OP_PMCSTART or - PMC_OP_PMCSTOP request was issued for a - system-wide PMC that was allocated on a CPU that is currently absent or - disabled.
-
[]
-
A PMC_OP_PMCALLOCATE request was issued for PMC - capabilities not supported by the specified PMC class.
-
[]
-
(i386 architectures) A sampling mode PMC was requested on a CPU lacking an - APIC.
-
[]
-
A PMC_OP_PMCADMIN request was issued by a process - without super-user privilege or by a jailed super-user process.
-
[]
-
A PMC_OP_PMCATTACH operation was issued for a - target process that the current process does not have permission to attach - to.
-
[]
-
(i386 and amd64 architectures) A PMC_OP_PMCATTACH - operation was issued on a PMC whose MSR has been retrieved using - PMC_OP_PMCX86GETMSR.
-
[]
-
A process issued a PMC operation request without having allocated any - PMCs.
-
[]
-
A process issued a PMC operation request after the PMC was detached from - all of its target processes.
-
[]
-
A PMC_OP_PMCATTACH or - PMC_OP_PMCDETACH request specified a non-existent - process ID.
-
[]
-
The target process for a PMC_OP_PMCDETACH - operation is not being monitored by hwpmc.
-
-
-
-

-

kenv(1), pmc(3), - pmclog(3), ddb(4), - ktr(4), kldload(8), - ktrdump(8), pmccontrol(8), - pmcstat(8), sysctl(8), - kproc_create(9), p_candebug(9)

-
-
-

-

The hwpmc driver first appeared in - FreeBSD 6.0.

-
-
-

-

The hwpmc driver was written by - Joseph Koshy - <jkoshy@FreeBSD.org>.

-
-
-

-

The driver samples the state of the kernel's logical processor - support at the time of initialization (i.e., at module load time). On CPUs - supporting logical processors, the driver could misbehave if logical - processors are subsequently enabled or disabled while the driver is - active.

-

On the i386 architecture, the driver requires that the local APIC - on the CPU be enabled for sampling mode to be supported. Many - single-processor motherboards keep the APIC disabled in BIOS; on such - systems hwpmc will not support sampling PMCs.

-
-
-

-

PMCs may be used to monitor the actual behavior of the system on - hardware. In situations where this constitutes an undesirable information - leak, the following options are available:

-
    -
  1. Set the sysctl(8) tunable - security.bsd.unprivileged_syspmcs to 0. This ensures - that unprivileged processes cannot allocate system-wide PMCs and thus - cannot observe the hardware behavior of the system as a whole. This - tunable may also be set at boot time using loader(8), or - with kenv(1) prior to loading the - hwpmc driver into the kernel.
    2. -
  2. Set the sysctl(8) tunable - security.bsd.unprivileged_proc_debug to 0. This will - ensure that an unprivileged process cannot attach a PMC to any process - other than itself and thus cannot observe the hardware behavior of other - processes with the same credentials.
    3. -
-

System administrators should note that on IA-32 platforms - FreeBSD makes the content of the IA-32 TSC counter - available to all processes via the RDTSC instruction.

-
-
- - - - - -
July 8, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/hwpstate_intel.4 3.html b/static/freebsd/man4/hwpstate_intel.4 3.html deleted file mode 100644 index 0b43db22..00000000 --- a/static/freebsd/man4/hwpstate_intel.4 3.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
HWPSTATE_INTEL(4)Device Drivers ManualHWPSTATE_INTEL(4)
-
-
-

-

hwpstate_intel — - Intel Speed Shift Technology driver

-
-
-

-

To compile this driver into your kernel place the following line - in your kernel configuration file:

-
device cpufreq
-
-
-

-

The hwpstate_intel driver provides support - for hardware-controlled performance states on Intel platforms, also known as - Intel Speed Shift Technology.

-
-
-

-
-
hint.hwpstate_intel.0.disabled
-
Can be used to disable hwpstate_intel, allowing - other compatible drivers to manage performance states, like - est(4). Defaults to "0" (enabled).
-
machdep.hwpstate_pkg_ctrl
-
Selects between package-level control (the default) and per-core control. - "1" selects package-level control and "0" selects - core-level control.
-
-
-
-

-

The following sysctl(8) values are available

-
-
dev.hwpstate_intel.%d.%desc
-
Describes the attached driver
-
dev.hwpstate_intel.0.%desc: Intel Speed Shift
-
 
-
dev.hwpstate_intel.%d.%driver
-
Driver in use, always hwpstate_intel.
-
dev.hwpstate_intel.0.%driver: hwpstate_intel
-
 
-
dev.hwpstate_intel.%d.%parent
-
The CPU that is exposing these frequencies. For example - cpu0.
-
dev.hwpstate_intel.0.%parent: cpu0
-
 
-
dev.hwpstate_intel.%d.epp
-
Energy/Performance Preference. Valid values range from 0 to 100. Setting - this field conveys a hint to the hardware regarding a preference towards - performance (at value 0), energy efficiency (at value 100), or somewhere - in between.
-
dev.hwpstate_intel.0.epp: 0
-
 
-
-
-
-

-

hwpstate_intel is only found on supported - Intel CPUs.

-
-
-

-

cpufreq(4)

-

Intel 64 and IA-32 - Architectures Software Developer Manuals, - http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html.

-
-
-

-

This manual page was written by D Scott - Phillips - <scottph@FreeBSD.org>.

-
-
- - - - - -
April 21, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/hwt.4 3.html b/static/freebsd/man4/hwt.4 3.html deleted file mode 100644 index 0fceef39..00000000 --- a/static/freebsd/man4/hwt.4 3.html +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - -
HWT(4)Device Drivers ManualHWT(4)
-
-
-

-

hwt — Hardware - Trace Framework

-
-
-

-

options HWT_HOOKS -
- device hwt

-

At least one of: -
- device intel_pt (amd64) -
- device coresight (arm64) -
- device spe (arm64)

-

In rc.conf(5): -
- kld_list="hwt"

-
-
-

-

The hwt framework provides infrastructure - for hardware-assisted tracing. It collects detailed information about - software execution and stores it as events in highly compressed format into - DRAM. The events cover information about control flow changes of a program, - whether branches taken or not, exceptions taken, timing information, cycles - elapsed and more. The information collected allows to reconstruct entire - program flow of a given application without noticeable performance - impact.

-
-
-

-

The framework supports several tracing technologies found on - arm64 and amd64 systems:

-

-
    -
  • ARM Coresight
    • -
  • ARM Statistical Profiling Extension (SPE)
    • -
  • Intel Processor Trace (PT)
    • -
-

The hwt framework supports two modes of - operation:

-
-
-
Capture CPU activity in kernel mode.
-
-
Capture activity of each of a process's threads in user mode.
-
-
-
-

-

When loaded into kernel, the hwt framework - provides /dev/hwt character device. The only - ioctl(2) request it accepts is - HWT_IOC_ALLOC. This request allocates kernel tracing - context (CTX) based on requested mode of operation, set of CPUs and/or - pid.

-

Upon successful CTX allocation, the ioctl returns a CTX - identification number (ident).

-

Each CTX is then managed using its own dedicated character device - found at /dev/hwt_${ident}_${d}, where ident is a - unique identification number of tracing context, d is either cpu_id (in HWT - CPU mode) or process pid (in HWT Thread mode).

-
-
-

-

During tracing of a target process, HWT records runtime events - such as threads creation, exec and mmap system calls. These events are - logged as "records" within a particular CTX associated with traced - process.

-

Additionally, HWT can suspend the target thread upon exec or mmap - system calls if requested by the user. This pause allows user-space tools to - retrieve the records and adjust tracing settings before execution continues. - This feature is especially useful when address range filtering is enabled, - allowing tracing of specific functions within the target executable or a - dynamic library.

-
-
-

-

The following options in the kernel configuration file are - mandatory and related to hwt operation:

-

-
-
-
Enable kernel hooks.
-
-
-
-

-

Once a CTX is allocated, its management character device accepts - several ioctl(2) requests:

-
-
-
Start tracing. In HWT CPU mode the tracing does actually start with this - ioctl(2) request. In the Thread mode, the tracing - "running" flag set, but tracing begins after scheduler switches - the target thread onto CPU and return to user mode.
-
-
Stop tracing of the particular CTX.
-
-
Copy all or part of records collected during hook invocation and - associated with this CTX to userspace.
-
-
Get current pointer in buffer that is filled by tracing units in - real-time.
-
-
Set architecture-specific config (optional).
-
-
Wake up a thread that has been put to sleep by HWT framework hooks.
-
-
For SPE-only, the kernel is waiting for userspace to notify that it has - copied out a buffer to avoid data loss/overwriting buffers.
-
-
-
-

-

tracing(7), hwt(8)

-
-
-

-

The hwt framework first appeared in - FreeBSD 15.0.

-
-
-

-

Ruslan Bukin - <br@FreeBSD.org> -
- Bojan Novković - <bnovkov@freebsd.org> -
- Zachary Leaf - <zachary.leaf@arm.com>

-
-
- - - - - -
July 12, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/i2ctinyusb.4 4.html b/static/freebsd/man4/i2ctinyusb.4 4.html deleted file mode 100644 index 299b8caf..00000000 --- a/static/freebsd/man4/i2ctinyusb.4 4.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
I2CTINYUSB(4)Device Drivers ManualI2CTINYUSB(4)
-
-
-

-

i2ctinyusb — - driver for a USB / I2C bridge device

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device i2ctinyusb -
-device usb -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
i2ctinyusb_load="YES"
-
-
-
-

-

The i2ctinyusb driver provides support for - the device designed by Till Harbaum known as i2c-tiny-usb. This is initially - a very simple circuit built with an Atmel AVR ATtiny45, but a Raspberry Pi - Pico (RP2040) implementation also exists.

-

The i2ctinyusb driver creates a - iicbus(4) child bus to expose the iic functions, enabling - I2C sensors, converters and displays to be connected to any computer with a - USB port.

-

More information about this device can be found at:

-
-
https://github.com/harbaum/I2C-Tiny-USB
-
-

and (for the Raspberry Pi Pico version):

-
-
https://github.com/Nicolai-Electronics/rp2040-i2c-interface
-
-

The I2C controller supports read and write transactions with up to - 1024 bytes of data, and a write followed by the repeated start followed by a - read transactions up to 1024 bytes. Zero length transfers are not - supported.

-
-
-

-

iicbus(4), usb(4)

-
-
-

-

The i2ctinyusb driver and this manual page - was written by Denis Bodor - <dbodor@rollmops.ninja>.

-
-
- - - - - -
February 18, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/iavf.4 3.html b/static/freebsd/man4/iavf.4 3.html deleted file mode 100644 index 5d9ea7c5..00000000 --- a/static/freebsd/man4/iavf.4 3.html +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - -
IAVF(4)Device Drivers ManualIAVF(4)
-
-
-

-

iavf — Intel - Ethernet Adaptive Virtual Function Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device iavf
-

To load the driver as a module at boot time, place the following - lines in loader.conf(5):

-
-
if_iavf_load="YES"
-
-
-
-

-

The iavf driver provides support for any - PCI Virtual Function created from certain Intel Ethernet devices. This - driver is compatible with virtual functions bound to devices based on the - following:

-

-
    -
  • Intel® Ethernet Controller E810-C
    • -
  • Intel® Ethernet Controller E810-XXV
    • -
  • Intel® Ethernet Connection E822-C
    • -
  • Intel® Ethernet Connection E822-L
    • -
  • Intel® Ethernet Connection E823-C
    • -
  • Intel® Ethernet Connection E823-L
    • -
  • Intel® Ethernet Controller I710
    • -
  • Intel® Ethernet Controller X710
    • -
  • Intel® Ethernet Controller XL710
    • -
  • Intel® Ethernet Network Connection X722
    • -
  • Intel® Ethernet Controller XXV710
    • -
  • Intel® Ethernet Controller V710
    • -
-

The associated Physical Function (PF) drivers for this VF driver - are:

-

- -

For questions related to hardware requirements, refer to the - documentation supplied with your Intel Ethernet Adapter. All hardware - requirements listed apply to use with FreeBSD.

-
-

-

The VF driver is normally used in a virtualized environment where - a host driver manages SR-IOV, and provides a VF device to the guest.

-

In the FreeBSD guest, the iavf driver - would be loaded and will function using the VF device assigned to it.

-

The VF driver provides most of the same functionality as the core - driver, but is actually a subordinate to the host. Access to many controls - is accomplished by a request to the host via what is called the "Admin - queue." These are startup and initialization events, however; once in - operation, the device is self-contained and should achieve near native - performance.

-

Some notable limitations of the VF environment:

-
    -
  • The PF can configure the VF to allow promiscuous mode, using a - configuration parameter in iovctl.conf(5); otherwise, - promiscuous mode will not work
    • -
  • Media info is not available from the PF, so the active media will always - be displayed as auto in ifconfig(8)
    • -
-
-
-

-

Adaptive Virtual Function (AVF) allows the virtual function - driver, or VF, to adapt to changing feature sets of the physical function - driver (PF) with which it is associated. This allows system administrators - to update a PF without having to update all the VFs associated with it. All - AVFs have a single common device ID and branding string.

-

AVFs have a minimum set of features known as "base - mode," but may provide additional features depending on what features - are available in the PF with which the AVF is associated. The following are - base mode features:

-
    -
  • 4 Queue Pairs (QP) and associated Configuration Status Registers (CSRs) - for Tx/Rx
    • -
  • iavf descriptors and ring format
    • -
  • Descriptor write-back completion
    • -
  • 1 control queue, with iavf descriptors, CSRs and ring format
    • -
  • 5 MSI-X interrupt vectors and corresponding iavf CSRs
    • -
  • 1 Interrupt Throttle Rate (ITR) index
    • -
  • 1 Virtual Station Interface (VSI) per VF
    • -
  • 1 Traffic Class (TC), TC0
    • -
  • Receive Side Scaling (RSS) with 64 entry indirection table and key, - configured through the PF
    • -
  • 1 unicast MAC address reserved per VF
    • -
  • 8 MAC address filters for each VF on an Intel® Ethernet 800 Series - device
    • -
  • 16 MAC address filters for each VF on an Intel® Ethernet 700 Series - device
    • -
  • Stateless offloads - non-tunneled checksums
    • -
  • AVF device ID
    • -
  • HW mailbox is used for VF to PF communications
    • -
-
-
-
-

-
-

-

It is important to note that 100G operation can generate high - numbers of interrupts, often incorrectly being interpreted as a storm - condition in the kernel. It is suggested that this be resolved by setting - hw.intr_storm_threshold to 0.

-

The default is 1000.

-

Best throughput results are seen with a large MTU; use 9706 if - possible. The default number of descriptors per ring is 1024. Increasing - this may improve performance, depending on your use case.

-
-
-

-

iflib(4) is a common framework for network - interface drivers for FreeBSD that uses a shared set - of sysctl names.

-

The default iavf driver depends on it, but - it can be compiled without it.

-
-
-

-

Jumbo Frames support is enabled by changing the Maximum - Transmission Unit (MTU) to a value larger than the default value of - 1500.

-

Use the ifconfig(8) command to increase the MTU - size.

-

To confirm the MTU used between two specific devices, use - route(8):

-
-
route get <destination_IP_address>
-
-

NOTE:

-
    -
  • The maximum MTU setting for jumbo frames is 9706. This corresponds to the - maximum jumbo frame size of 9728 bytes.
    • -
  • This driver will attempt to use multiple page-sized buffers to receive - each jumbo packet. This should help to avoid buffer starvation issues when - allocating receive packets.
    • -
  • Packet loss may have a greater impact on throughput when you use jumbo - frames. If you observe a drop in performance after enabling jumbo frames, - enabling flow control may mitigate the issue.
    • -
-
-
-

-

Checksum offloading supports both TCP and UDP packets and is - supported for both transmit and receive.

-

TSO (TCP Segmentation Offload) supports both IPv4 and IPv6. Both - of these features are enabled and disabled via - ifconfig(8).

-

NOTE:

-
    -
  • TSO requires Tx checksum; if Tx checksum is disabled then TSO will also be - disabled.
    • -
-
-
-

-

LRO (Large Receive Offload) may provide Rx performance - improvement. However, it is incompatible with packet-forwarding workloads. - You should carefully evaluate the environment and enable LRO when - possible.

-
-
-

-

Allows you to set the Rx and Tx descriptor rings independently. - Set them via these iflib(4) sysctls:

-
-
dev.iavf.#.iflib.override_nrxds
-
 
-
dev.iavf.#.iflib.override_ntxds
-
 
-
-
-
- -

The VF driver does not have access to flow control settings. It - must be managed from the host side.

-
-
-
-

-

arp(4), ice(4), - iflib(4), ixl(4), - netintro(4), vlan(4), - ifconfig(8)

-

See the “Intel® Ethernet Adapters and Devices User - Guide” for additional information on features. It is available on the - Intel website at either of the following:

- -

For information on how to identify your adapter, and for the - latest Intel network drivers, refer to the Intel Support website: - ⟨http://www.intel.com/support⟩

-
-
-

-
-

-

The fix to resolve CVE-2016-8105, referenced in Intel SA-00069 - ⟨https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00069.html⟩, - is included in this and future versions of the driver.

-
-
-

-

FreeBSD may have a low number of network - memory buffers (mbufs) by default. If your mbuf value is too low, it may - cause the driver to fail to initialize and/or cause the system to become - unresponsive. You can check to see if the system is mbuf-starved by running - netstat -m. Increase the number of mbufs by editing - the lines below in sysctl.conf(5):

-
-
kern.ipc.nmbclusters
-kern.ipc.nmbjumbop
-kern.ipc.nmbjumbo9
-kern.ipc.nmbjumbo16
-kern.ipc.nmbufs
-
-

The amount of memory that you allocate is system specific, and may - require some trial and error. Also, increasing the following in - sysctl.conf(5) could help increase network - performance:

-
-
kern.ipc.maxsockbuf
-net.inet.tcp.sendspace
-net.inet.tcp.recvspace
-net.inet.udp.maxdgram
-net.inet.udp.recvspace
-
-
-
-

-

Under small packet UDP stress with the - iavf driver, the system may drop UDP packets due to - socket buffers being full. Setting the PF driver's Flow Control variables to - the minimum may resolve the issue.

-
-
-

-

LRO must be turned off when forwarding traffic.

-
-
-
-

-

For general information, go to the Intel support website at - ⟨http://www.intel.com/support/⟩.

-

If an issue is identified with the released source code on a - supported kernel with a supported adapter, email the specific information - related to the issue to - <freebsd@intel.com>.

-
-
-

-

Intel® is a trademark or registered trademark of Intel - Corporation or its subsidiaries in the United States and / or other - countries.

-

Other names and brands may be claimed as the property of - others.

-
-
-

-

The iavf device driver first appeared in - FreeBSD 10.1 under the name - ixlv. It was converted to use - iflib(4) and renamed in FreeBSD - 12.4.

-
-
-

-

The iavf driver was written by the - Intel Corporation - <freebsd@intel.com>

-
-
- - - - - -
May 21, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ice.4 3.html b/static/freebsd/man4/ice.4 3.html deleted file mode 100644 index 0ea4686e..00000000 --- a/static/freebsd/man4/ice.4 3.html +++ /dev/null @@ -1,969 +0,0 @@ - - - - - - -
ICE(4)Device Drivers ManualICE(4)
-
-
-

-

ice — Intel - Ethernet 800 Series 1GbE to 200GbE driver

-
-
-

-

device iflib -
- device ice

-

In loader.conf(5): -
- if_ice_load -
- hw.ice.enable_health_events -
- hw.ice.irdma -
- hw.ice.irdma_max_msix -
- hw.ice.debug.enable_tx_fc_filter -
- hw.ice.debug.enable_tx_lldp_filter -
- hw.ice.debug.ice_tx_balance_en

-

In sysctl.conf(5) or - loader.conf(5): -
- dev.ice.#.current_speed -
- dev.ice.#.fw_version -
- dev.ice.#.ddp_version -
- dev.ice.#.pba_number -
- dev.ice.#.hw.mac.*

-
-
-

-

The ice driver provides support for any - PCI Express adapter or LOM (LAN On Motherboard) in the Intel Ethernet 800 - Series.

-

The following topics are covered in this manual:

-

- -
-

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 9706. For - more information, see the Jumbo - Frames section.

-

This driver version supports VLANs. For information on enabling - VLANs, see vlan(4). For additional information on - configuring VLANs, see ifconfig(8)'s “VLAN - Parameters” section.

-

Offloads are also controlled via the interface, for instance, - checksumming for both IPv4 and IPv6 can be set and unset, TSO4 and/or TSO6, - and finally LRO can be set and unset.

-

For more information on configuring this device, see - ifconfig(8).

-

The associated Virtual Function (VF) driver for this driver is - iavf(4).

-

The associated RDMA driver for this driver is - irdma(4).

-
-
-

-

The DDP package loads during device initialization. The driver - looks for the ice_ddp module and checks that it contains a - valid DDP package file.

-

If the driver is unable to load the DDP package, the device will - enter Safe Mode. Safe Mode disables advanced and performance features and - supports only basic traffic and minimal functionality, such as updating the - NVM or downloading a new driver or DDP package. Safe Mode only applies to - the affected physical function and does not impact any other PFs. See the - “Intel Ethernet Adapters and Devices User Guide” for more - details on DDP and Safe Mode.

-

If issues are encountered with the DDP package file, an updated - driver or ice_ddp module may need to be downloaded. See - the log messages for more information.

-

The DDP package cannot be updated if any PF drivers are already - loaded. To overwrite a package, unload all PFs and then reload the driver - with the new package.

-

Only one DDP package can be used per driver, even if more than one - installed device uses the driver.

-

Only the first loaded PF per device can download a package for - that device.

-
-
-

-

Jumbo Frames support is enabled by changing the Maximum - Transmission Unit (MTU) to a value larger than the default value of - 1500.

-

Use ifconfig(8) to increase the MTU size.

-

The maximum MTU setting for jumbo frames is 9706. This corresponds - to the maximum jumbo frame size of 9728 bytes.

-

This driver will attempt to use multiple page sized buffers to - receive each jumbo packet. This should help to avoid buffer starvation - issues when allocating receive packets.

-

Packet loss may have a greater impact on throughput when jumbo - frames are in use. If a drop in performance is observed after enabling jumbo - frames, enabling flow control may mitigate the issue.

-
-
-

-

Remote Direct Memory Access, or RDMA, allows a network device to - transfer data directly to and from application memory on another system, - increasing throughput and lowering latency in certain networking - environments.

-

The ice driver supports both the iWARP (Internet Wide Area RDMA - Protocol) and RoCEv2 (RDMA over Converged Ethernet) protocols. The major - difference is that iWARP performs RDMA over TCP, while RoCEv2 uses UDP.

-

Devices based on the Intel Ethernet 800 Series do not support RDMA - when operating in multiport mode with more than 4 ports.

-

For detailed installation and configuration information for RDMA, - see irdma(4).

-
-
-

-

For debugging/testing purposes, a sysctl can be used to set up a - mirroring interface on a port. The interface can receive mirrored RDMA - traffic for packet analysis tools like tcpdump(1). This - mirroring may impact performance.

-

To use RDMA monitoring, more MSI-X interrupts may need to be - reserved. Before the ice driver loads, configure the - following tunable provided by iflib(4):

-
-
dev.ice.<interface #>.iflib.use_extra_msix_vectors=4
-
-

The number of extra MSI-X interrupt vectors may need to be - adjusted.

-

To create/delete the interface:

-
-
sysctl dev.ice.<interface #>.create_interface=1
-sysctl dev.ice.<interface #>.delete_interface=1
-
-

The mirrored interface receives both LAN and RDMA traffic. - Additional filters can be configured in tcpdump.

-

To differentiate the mirrored interface from the primary - interface, the network interface naming convention is:

-
-
<driver name><port number><modifier><modifier unit number>
-
-

For example, “ice0m0” is the - first mirroring interface on - “ice0”.

-
-
-

-

Data Center Bridging (DCB) is a configuration Quality of Service - implementation in hardware. It uses the VLAN priority tag (802.1p) to filter - traffic. That means that there are 8 different priorities that traffic can - be filtered into. It also enables priority flow control (802.1Qbb) which can - limit or eliminate the number of dropped packets during network stress. - Bandwidth can be allocated to each of these priorities, which is enforced at - the hardware level (802.1Qaz).

-

DCB is normally configured on the network using the DCBX protocol - (802.1Qaz), a specialization of LLDP (802.1AB). The - ice driver supports the following mutually exclusive - variants of DCBX support:

-

-
    -
  • Firmware-based LLDP Agent
    • -
  • Software-based LLDP Agent
    • -
-

In firmware-based mode, firmware intercepts all LLDP traffic and - handles DCBX negotiation transparently for the user. In this mode, the - adapter operates in “willing” DCBX mode, receiving DCB - settings from the link partner (typically a switch). The local user can only - query the negotiated DCB configuration. For information on configuring DCBX - parameters on a switch, please consult the switch manufacturer'ss - documentation.

-

In software-based mode, LLDP traffic is forwarded to the network - stack and user space, where a software agent can handle it. In this mode, - the adapter can operate in “nonwilling” DCBX mode and DCB - configuration can be both queried and set locally. This mode requires the - FW-based LLDP Agent to be disabled.

-

Firmware-based mode and software-based mode are controlled by the - “fw_lldp_agent” sysctl. Refer to the Firmware Link Layer - Discovery Protocol Agent section for more information.

-

Link-level flow control and priority flow control are mutually - exclusive. The ice driver will disable link flow control when priority flow - control is enabled on any traffic class (TC). It will disable priority flow - control when link flow control is enabled.

-

To enable/disable priority flow control in software-based DCBX - mode:

-
-
sysctl dev.ice.<interface #>.pfc=1 (or 0 to disable)
-
-

Enhanced Transmission Selection (ETS) allows bandwidth to be - assigned to certain TCs, to help ensure traffic reliability. To view the - assigned ETS configuration, use the following:

-
-
sysctl dev.ice.<interface #>.ets_min_rate
-
-

To set the minimum ETS bandwidth per TC, separate the values by - commas. All values must add up to 100. For example, to set all TCs to a - minimum bandwidth of 10% and TC 7 to 30%, use the following:

-
-
sysctl dev.ice.<interface #>.ets_min_rate=10,10,10,10,10,10,10,30
-
-

To set the User Priority (UP) to a TC mapping for a port, separate - the values by commas. For example, to map UP 0 and 1 to TC 0, UP 2 and 3 to - TC 1, UP 4 and 5 to TC 2, and UP 6 and 7 to TC 3, use the following:

-
-
sysctl dev.ice.<interface #>.up2tc_map=0,0,1,1,2,2,3,3
-
-
-
-

-

The ice driver supports setting DSCP-based - Layer 3 Quality of Service (L3 QoS) in the PF driver. The driver initializes - in L2 QoS mode by default; L3 QoS is disabled by default. Use the following - sysctl to enable or disable L3 QoS:

-
-
sysctl dev.ice.<interface #>.pfc_mode=1 (or 0 to disable)
-
-

If L3 QoS mode is disabled, it returns to L2 QoS mode.

-

To map a DSCP value to a traffic class, separate the values by - commas. For example, to map DSCPs 0-3 and DSCP 8 to DCB TCs 0-3 and 4, - respectively:

-
-
sysctl dev.ice.<interface #>.dscp2tc_map.0-7=0,1,2,3,0,0,0,0
-sysctl dev.ice.<interface #>.dscp2tc_map.8-15=4,0,0,0,0,0,0,0
-
-

To change the DSCP mapping back to the default traffic class, set - all the values back to 0.

-

To view the currently configured mappings, use the following:

-
-
sysctl dev.ice.<interface #>.dscp2tc_map
-
-

L3 QoS mode is not available when FW-LLDP is enabled.

-

FW-LLDP cannot be enabled if L3 QoS mode is active.

-

Disable FW-LLDP before switching to L3 QoS mode.

-

Refer to the - Firmware - Link Layer Discovery Protocol Agent section in this README for more - information on disabling FW-LLDP.

-
-
- -

Use sysctl to change FW-LLDP settings. The FW-LLDP setting is per - port and persists across boots.

-

To enable the FW-LLDP Agent:

-
-
sysctl dev.ice.<interface #>.fw_lldp_agent=1
-
-

To disable the FW-LLDP Agebt:

-
-
sysctl dev.ice.<interface #>.fw_lldp_agent=0
-
-

To check the current LLDP setting:

-
-
sysctl dev.ice.<interface #>.fw_lldp_agent
-
-

The UEFI HII LLDP Agent attribute must be enabled for this setting - to take effect. If the “LLDP AGENT” attribute is set to - disabled, the FW-LLDP Agent cannot be enabled from the driver.

-
-
- -

Ethernet Flow Control (IEEE 802.3x or LFC) can be configured with - sysctl(8) to enable receiving and transmitting pause - frames for ice. When transmit is enabled, pause - frames are generated when the receive packet buffer crosses a predefined - threshold. When receive is enabled, the transmit unit will halt for the time - delay specified in the firmware when a pause frame is received.

-

Flow Control is disabled by default.

-

Use sysctl to change the flow control settings for a single - interface without reloading the driver:

-
-
sysctl dev.ice.<interface #>.fc
-
-

The available values for flow control are:

-
-
0 = Disable flow control
-1 = Enable Rx pause
-2 = Enable Tx pause
-3 = Enable Rx and Tx pause
-
-

Verify that link flow control was negotiated on the link by - checking the interface entry in ifconfig(8) and looking - for the flags “txpause” and/or “rxpause” in the - “media” status.

-

The ice driver requires flow control on - both the port and link partner. If flow control is disabled on one of the - sides, the port may appear to hang on heavy traffic.

-

For more information on priority flow control, refer to the - Data Center Bridging - section.

-

The VF driver does not have access to flow control. It must be - managed from the host side.

-
-
-

-

Forward Error Correction (FEC) improves link stability but - increases latency. Many high quality optics, direct attach cables, and - backplane channels can provide a stable link without FEC.

-

For devices to benefit from this feature, link partners must have - FEC enabled.

-

If the allow_no_fec_modules_in_auto sysctl - is enabled Auto FEC negotiation will include - “FEC” in case the link partner does - not have FEC enabled or is not FEC capable:

-
-
sysctl dev.ice.<interface #>.allow_no_fec_modules_in_auto=1
-
-

NOTE: This flag is currently not supported on the Intel Ethernet - 830 Series.

-

To show the current FEC settings that are negotiated on the - link:

-
-
sysctl dev.ice.<interface #>.negotiated_fec
-
-

To view or set the FEC setting that was requested on the link:

-
-
sysctl dev.ice.<interface #>.requested_fec
-
-

To see the valid FEC modes for the link:

-
-
sysctl -d dev.ice.<interface #>.requested_fec
-
-
-
-

-

The speed and duplex settings cannot be hard set.

-

To have the device change the speeds it will use in - auto-negotiation or force link with:

-
-
sysctl dev.ice.<interface #>.advertise_speed=<mask>
-
-

Supported speeds will vary by device. Depending on the speeds the - device supports, valid bits used in a speed mask could include:

-
-
0x0 - Auto
-0x2 - 100 Mbps
-0x4 - 1 Gbps
-0x8 - 2.5 Gbps
-0x10 - 5 Gbps
-0x20 - 10 Gbps
-0x80 - 25 Gbps
-0x100 - 40 Gbps
-0x200 - 50 Gbps
-0x400 - 100 Gbps
-0x800 - 200 Gbps
-
-
-
- -

When the link_active_on_if_down sysctl is - set to “0”, the port's link will go down when the interface is - brought down. By default, link will stay up.

-

To disable link when the interface is down:

-
-
sysctl dev.ice.<interface #>.link_active_on_if_down=0
-
-
-
-

-

The ice driver allows for the generation - of firmware logs for supported categories of events, to help debug issues - with Customer Support. Refer to the “Intel Ethernet Adapters and - Devices User Guide” for an overview of this feature and additional - tips.

-

At a high level, to capture a firmware log:

-
    -
  1. Set the configuration for the firmware log.
    2. -
  2. Perform the necessary steps to reproduce the issue.
    3. -
  3. Capture the firmware log.
    4. -
  4. Stop capturing the firmware log.
    5. -
  5. Reset the firmware log settings as needed.
    6. -
  6. Work with Customer Support to debug the issue.
    7. -
-

NOTE: Firmware logs are generated in a binary format and must be - decoded by Customer Support. Information collected is related only to - firmware and hardware for debug purposes.

-

Once the driver is loaded, it will create the - fw_log sysctl node under the debug section of the - driver's sysctl list. The driver groups these events into categories, called - “modules”. Supported modules include:

-

-
-
-
general
-
General (Bit 0)
-
ctrl
-
Control (Bit 1)
- -
Link Management (Bit 2)
- -
Link Topology Detection (Bit 3)
-
dnl
-
Link Control Technology (Bit 4)
-
i2c
-
I2C (Bit 5)
-
sdp
-
SDP (Bit 6)
-
mdio
-
MDIO (Bit 7)
-
adminq
-
Admin Queue (Bit 8)
-
hdma
-
Host DMA (Bit 9)
-
lldp
-
LLDP (Bit 10)
-
dcbx
-
DCBx (Bit 11)
-
dcb
-
DCB (Bit 12)
-
xlr
-
XLR (function-level resets; Bit 13)
-
nvm
-
NVM (Bit 14)
-
auth
-
Authentication (Bit 15)
-
vpd
-
Vital Product Data (Bit 16)
-
iosf
-
Intel On-Chip System Fabric (Bit 17)
-
parser
-
Parser (Bit 18)
-
sw
-
Switch (Bit 19)
-
scheduler
-
Scheduler (Bit 20)
-
txq
-
TX Queue Management (Bit 21)
-
acl
-
ACL (Access Control List; Bit 22)
-
post
-
Post (Bit 23)
-
watchdog
-
Watchdog (Bit 24)
-
task_dispatch
-
Task Dispatcher (Bit 25)
-
mng
-
Manageability (Bit 26)
-
synce
-
SyncE (Bit 27)
-
health
-
Health (Bit 28)
-
tsdrv
-
Time Sync (Bit 29)
-
pfreg
-
PF Registration (Bit 30)
-
mdlver
-
Module Version (Bit 31)
-
-
-

The verbosity level of the firmware logs can be modified. It is - possible to set only one log level per module, and each level includes the - verbosity levels lower than it. For instance, setting the level to - “normal” will also log warning and error messages. Available - verbosity levels are:

-

-
    -
  • 0 = none
    • -
  • 1 = error
    • -
  • 2 = warning
    • -
  • 3 = normal
    • -
  • 4 = verbose
    • -
-

To set the desired verbosity level for a module, use the following - sysctl command and then register it:

-
-
sysctl dev.ice.<interface #>.debug.fw_log.severity.<module>=<level>
-
-

For example:

-
-
sysctl dev.ice.0.debug.fw_log.severity.link=1
-sysctl dev.ice.0.debug.fw_log.severity.link_topo=2
-sysctl dev.ice.0.debug.fw_log.register=1
-
-

To log firmware messages after booting, but before the driver - initializes, use kenv(1) to set the tunable. The - on_load setting tells the device to register the - variable as soon as possible during driver load. For example:

-
-
kenv dev.ice.0.debug.fw_log.severity.link=1
-kenv dev.ice.0.debug.fw_log.severity.link_topo=2
-kenv dev.ice.0.debug.fw_log.on_load=1
-
-

To view the firmware logs and redirect them to a file, use the - following command:

-
-
dmesg > log_output
-
-

NOTE: Logging a large number of modules or too high of a verbosity - level will add extraneous messages to dmesg and could hinder debug - efforts.

-
-
-

-

Intel Ethernet 800 Series devices support debug dump, which allows - gathering of runtime register values from the firmware for - “clusters” of events and then write the results to a single - dump file, for debugging complicated issues in the field.

-

This debug dump contains a snapshot of the device and its existing - hardware configuration, such as switch tables, transmit scheduler tables, - and other information. Debug dump captures the current state of the - specified cluster(s) and is a stateless snapshot of the whole device.

-

NOTE: Like with firmware logs, the contents of the debug dump are - not human-readable. Work with Customer Support to decode the file.

-

Debug dump is per device, not per PF.

-

Debug dump writes all information to a single file.

-

To generate a debug dump file in FreeBSD - do the following:

-

Specify the cluster(s) to include in the dump file, using a - bitmask and the following command:

-
-
sysctl dev.ice.<interface #>.debug.dump.clusters=<bitmask>
-
-

To print the complete cluster bitmask and parameter list to the - screen, pass the -d argument. For example:

-
-
sysctl -d dev.ice.0.debug.dump.clusters
-
-

Possible bitmask values for clusters - are:

-
    -
  • 0 - Dump all clusters (only supported on Intel Ethernet E810 Series and - Intel Ethernet E830 Series)
    • -
  • 0x1 - Switch
    • -
  • 0x2 - ACL
    • -
  • 0x4 - Tx Scheduler
    • -
  • 0x8 - Profile Configuration
    • -
  • 0x20 - Link
    • -
  • 0x80 - DCB
    • -
  • 0x100 - L2P
    • -
  • 0x400000 - Manageability Transactions (only supported on Intel Ethernet - E810 Series)
    • -
-

For example, to dump the Switch, DCB, and L2P clusters, use the - following:

-
-
sysctl dev.ice.0.debug.dump.clusters=0x181
-
-

To dump all clusters, use the following:

-
-
sysctl dev.ice.0.debug.dump.clusters=0
-
-

NOTE: Using 0 will skip Manageability Transactions data.

-

If a single cluster is not specified, the driver will dump all - clusters to a single file. Issue the debug dump command, using the - following:

-
-
sysctl -b dev.ice.<interface #>.debug.dump.dump=1 > dump.bin
-
-

NOTE: The driver will not receive the command if the sysctl is not - set to “1”.

-

Replace “dump.bin” above with the preferred file - name.

-

To clear the clusters mask before a - subsequent debug dump and then do the dump:

-
-
sysctl dev.ice.0.debug.dump.clusters=0
-sysctl dev.ice.0.debug.dump.dump=1
-
-
-
-

-

The ice driver supports the ability to obtain the values of the - PHY registers from Intel(R) Ethernet 810 Series devices in order to debug - link and connection issues during runtime.

-

The driver provides information about:

-
    -
  • Rx and Tx Equalization parameters
    • -
  • RS FEC correctable and uncorrectable block counts
    • -
-

Use the following sysctl to read the PHY registers:

-
-
sysctl dev.ice.<interface #>.debug.phy_statistics
-
-

NOTE: The contents of the registers are not human-readable. Like - with firmware logs and debug dump, work with Customer Support to decode the - file.

-
-
-

-

Some Intel(R) Ethernet 800 Series devices allow for enabling a - transmit balancing feature to improve transmit performance under certain - conditions. When enabled, this feature should provide more consistent - transmit performance across queues and/or PFs and VFs.

-

By default, transmit balancing is disabled in the NVM. To enable - this feature, use one of the following to persistently change the setting - for the device:

-
    -
  • Use the Ethernet Port Configuration Tool (EPCT) to enable the - tx_balancing option. Refer to the EPCT readme for - more information.
    • -
  • Enable the Transmit Balancing device setting in UEFI HII.
    • -
-

When the driver loads, it reads the transmit balancing setting - from the NVM and configures the device accordingly.

-

NOTE: The user selection for transmit balancing in EPCT or HII is - persistent across reboots. The system must be rebooted for the selected - setting to take effect.

-

This setting is device wide.

-

The driver, NVM, and DDP package must all support this - functionality to enable the feature.

-
-
-

-

Intel(R) Ethernet 810 Series and Intel(R) Ethernet 830 Series - devices can display temperature data (in degrees Celsius) via:

-
-
sysctl dev.ice.<interface #>.temp
-
-
-
-

-

FreeBSD may have a low number of network - memory buffers (mbufs) by default. If the number of mbufs available is too - low, it may cause the driver to fail to initialize and/or cause the system - to become unresponsive. Check to see if the system is mbuf-starved by - running netstat -m. Increase - the number of mbufs by editing the lines below in - /etc/sysctl.conf:

-
-
kern.ipc.nmbclusters
-kern.ipc.nmbjumbop
-kern.ipc.nmbjumbo9
-kern.ipc.nmbjumbo16
-kern.ipc.nmbufs
-
-

The amount of memory that should be allocated is system specific, - and may require some trial and error. Also, increasing the following in - /etc/sysctl.conf could help increase network - performance:

-
-
kern.ipc.maxsockbuf
-net.inet.tcp.sendspace
-net.inet.tcp.recvspace
-net.inet.udp.maxdgram
-net.inet.udp.recvspace
-
-
-
-

-

There are additional tools available from Intel to help configure - and update the adapters covered by this driver. These tools can be - downloaded directly from Intel at - https://downloadcenter.intel.com, - by searching for their names:

- -
-
-

-

Modules based on 100GBASE-SR4, active optical cable (AOC), and - active copper cable (ACC) do not support auto-negotiation per the IEEE - specification. To obtain link with these modules, auto-negotiation must be - turned off on the link partner's switch ports.

-

Note that adapters also support all passive and active limiting - direct attach cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 - specifications.

-
-
-

-

Some PCIe x8 slots are actually configured as x4 slots. These - slots have insufficient bandwidth for full line rate with dual port and quad - port devices. In addition, if a PCIe v4.0 or v3.0-capable adapter is placed - into into a PCIe v2.x slot, full bandwidth will not be possible.

-

The driver detects this situation and writes the following message - in the system log:

-
PCI-Express bandwidth available for this device may - be insufficient for optimal performance. Please move the device to a different - PCI-e link with more lanes and/or higher transfer rate.
-

If this error occurs, moving the adapter to a true PCIe x8 or x16 - slot will resolve the issue. For best performance, install devices in the - following PCI slots:

-
    -
  • Any 100Gbps-capable Intel(R) Ethernet 800 Series device: Install in a PCIe - v4.0 x8 or v3.0 x16 slot
    • -
  • A 200Gbps-capable Intel(R) Ethernet 830 Series device: Install in a PCIe - v5.0 x8 or v4.0 x16 slot
    • -
-

For questions related to hardware requirements, refer to the - documentation supplied with the adapter.

-
-
-
-

-

The ice driver supports the following - Intel 800 series 1Gb to 200Gb Ethernet controllers:

-

-
    -
  • Intel Ethernet Controller E810-C
    • -
  • Intel Ethernet Controller E810-XXV
    • -
  • Intel Ethernet Connection E822-C
    • -
  • Intel Ethernet Connection E822-L
    • -
  • Intel Ethernet Connection E823-C
    • -
  • Intel Ethernet Connection E823-L
    • -
  • Intel Ethernet Connection E825-C
    • -
  • Intel Ethernet Connection E830-C
    • -
  • Intel Ethernet Connection E830-CC
    • -
  • Intel Ethernet Connection E830-L
    • -
  • Intel Ethernet Connection E830-XXV
    • -
  • Intel Ethernet Connection E835-C
    • -
  • Intel Ethernet Connection E835-CC
    • -
  • Intel Ethernet Connection E835-L
    • -
  • Intel Ethernet Connection E835-XXV
    • -
-

The ice driver supports some adapters in - this series with SFP28/QSFP28 cages which have firmware that requires that - Intel qualified modules are used; these qualified modules are listed below. - This qualification check cannot be disabled by the driver.

-

The ice driver supports 100Gb Ethernet - adapters with these QSFP28 modules:

-

-
    -
  • Intel 100G QSFP28 100GBASE-SR4 E100GQSFPSR28SRX
    • -
  • Intel 100G QSFP28 100GBASE-SR4 SPTMBP1PMCDF
    • -
  • Intel 100G QSFP28 100GBASE-CWDM4 SPTSBP3CLCCO
    • -
  • Intel 100G QSFP28 100GBASE-DR SPTSLP2SLCDF
    • -
-

The ice driver supports 25Gb and 10Gb - Ethernet adapters with these SFP28 modules:

-

-
    -
  • Intel 10G/25G SFP28 25GBASE-SR E25GSFP28SR
    • -
  • Intel 25G SFP28 25GBASE-SR E25GSFP28SRX (Extended Temp)
    • -
  • Intel 25G SFP28 25GBASE-LR E25GSFP28LRX (Extended Temp)
    • -
-

The ice driver supports 10Gb and 1Gb - Ethernet adapters with these SFP+ modules:

-

-
    -
  • Intel 1G/10G SFP+ 10GBASE-SR E10GSFPSR
    • -
  • Intel 1G/10G SFP+ 10GBASE-SR E10GSFPSRG1P5
    • -
  • Intel 1G/10G SFP+ 10GBASE-SR E10GSFPSRG2P5
    • -
  • Intel 10G SFP+ 10GBASE-SR E10GSFPSRX (Extended Temp)
    • -
  • Intel 1G/10G SFP+ 10GBASE-LR E10GSFPLR
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). See - the iflib(4) man page for more information on using iflib - sysctl variables as tunables.

-
-
hw.ice.enable_health_events
-
Set to 1 to enable firmware health event reporting across all devices. - Enabled by default. -

If enabled, when the driver receives a firmware health event - message, it will print out a description of the event to the kernel - message buffer and if applicable, possible actions to take to remedy - it.

-
-
hw.ice.irdma
-
Set to 1 to enable the RDMA client interface, required by the - irdma(4) driver. Enabled by default.
-
hw.ice.rdma_max_msix
-
Set the maximum number of per-device MSI-X vectors that are allocated for - use by the irdma(4) driver. Set to 64 by default.
-
hw.ice.debug.enable_tx_fc_filter
-
Set to 1 to enable the TX Flow Control filter across all devices. Enabled - by default. -

If enabled, the hardware will drop any transmitted Ethertype - 0x8808 control frames that do not originate from the hardware.

-
-
hw.ice.debug.enable_tx_lldp_filter
-
Set to 1 to enable the TX LLDP filter across all devices. Enabled by - default. -

If enabled, the hardware will drop any transmitted Ethertype - 0x88cc LLDP frames that do not originate from the hardware. This must be - disabled in order to use LLDP daemon software such as - lldpd(8).

-
-
hw.ice.debug.ice_tx_balance_en
-
Set to 1 to allow the driver to use the 5-layer Tx Scheduler tree topology - if configured by the DDP package. -

Enabled by default.

-
-
-
-
-

-
-
dev.ice.#.current_speed
-
This is a display of the current link speed of the interface. This is - expected to match the speed of the media type in-use displayed by - ifconfig(8).
-
dev.ice.#.fw_version
-
Displays the current firmware and NVM versions of the adapter. This - information should be submitted along with any support requests.
-
dev.ice.#.ddp_version
-
Displays the current DDP package version downloaded to the adapter. This - information should be submitted along with any support requests.
-
dev.ice.#.pba_number
-
Displays the Product Board Assembly Number. May be used to help identify - the type of adapter in use. This sysctl may not exist depending on the - adapter type.
-
dev.ice.#.hw.mac.*
-
This sysctl tree contains statistics collected by the hardware for the - port.
-
-
-
-

-

It is important to note that 100G operation can generate high - numbers of interrupts, often incorrectly being interpreted as a storm - condition in the kernel. It is suggested that this be resolved by setting - hw.intr_storm_threshold to 0.

-
-
-

-

The driver supports additional optional parameters for created VFs - (Virtual Functions) when using iovctl(8):

-
-
mac-addr (unicast-mac)
-
Set the Ethernet MAC address that the VF will use. If unspecified, the VF - will use a randomly generated MAC address and - “allow-set-mac” will be set to true.
-
mac-anti-spoof (bool)
-
Prevent the VF from sending Ethernet frames with a source address that - does not match its own. Enabled by default.
-
allow-set-mac (bool)
-
Allow the VF to set its own Ethernet MAC address. Disallowed by - default.
-
allow-promisc (bool)
-
Allow the VF to inspect all of the traffic sent to the port that it is - created on. Disabled by default.
-
num-queues (uint16_t)
-
Specify the number of queues the VF will have. By default, this is set to - the number of MSI-X vectors supported by the VF minus one.
-
mirror-src-vsi (uint16_t)
-
Specify which VSI the VF will mirror traffic from by setting this to a - value other than -1. All traffic from that VSI will be mirrored to this - VF. Can be used as an alternative method to mirror RDMA traffic to another - interface than the method described in the - RDMA Monitoring section. Not - affected by the “allow-promisc” parameter.
-
max-vlan-allowed (uint16_t)
-
Specify maximum number of VLAN filters that the VF can use. Receiving - traffic on a VLAN requires a hardware filter which are a finite resource; - this is used to prevent a VF from starving other VFs or the PF of filter - resources. By default, this is set to 16.
-
max-mac-filters (uint16_t)
-
Specify maximum number of MAC address filters that the VF can use. Each - allowed MAC address requires a hardware filter which are a finite - resource; this is used to prevent a VF from starving other VFs or the PF - of filter resources. The VF's default mac address does not count towards - this limit. By default, this is set to 64.
-
-

An up to date list of parameters and their defaults can be found - by using iovctl(8) with the -S - option.

-

For more information on standard and mandatory parameters, see - iovctl.conf(5).

-
-
-

-

For general information and support, go to the Intel support - website at: - http://www.intel.com/support/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - <freebsd@intel.com>.

-
-
-

-

iflib(4), vlan(4), - ifconfig(8), sysctl(8)

-
-
-

-

The ice device driver first appeared in - FreeBSD 12.2.

-
-
-

-

The ice driver was written by - Intel Corporation - <freebsd@intel.com>.

-
-
- - - - - -
November 5, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ichsmb.4 4.html b/static/freebsd/man4/ichsmb.4 4.html deleted file mode 100644 index 08cbca6f..00000000 --- a/static/freebsd/man4/ichsmb.4 4.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - -
ICHSMB(4)Device Drivers ManualICHSMB(4)
-
-
-

-

ichsmb — Intel ICH - SMBus controller driver

-
-
-

-

device pci -
- device smbus -
- device smb -
- device ichsmb

-
-
-

-

The ichsmb driver provides - smbus(4) support for the SMBus controller logical device - contained in all Intel motherboard chipsets starting from 82801AA (ICH).

-
-
-

-

intpm(4), ismt(4), - smb(4), smbus(4)

-
-
-

-

Archie L. Cobbs - <archie@FreeBSD.org>

-
-
- - - - - -
July 20, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/ichwd.4 3.html b/static/freebsd/man4/ichwd.4 3.html deleted file mode 100644 index 86194b99..00000000 --- a/static/freebsd/man4/ichwd.4 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
ICHWD(4)Device Drivers ManualICHWD(4)
-
-
-

-

ichwd — device - driver for the Intel ICH watchdog interrupt timer

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ichwd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ichwd_load="YES"
-
-
-
-

-

The ichwd driver provides - watchdog(4) support for the watchdog interrupt timer - present on all Intel ICH motherboard chipsets.

-

The ICH WDT counts down in ticks of approximately 0.6 seconds; the - exact value depends on hardware quality and environmental factors. Supported - watchdog intervals range from 2 to 63 ticks.

-

In QEMU, there is a dedicated watchdog implementation for x86 - systems based on the Intel 6300ESB controller hub. Support for this watchdog - is provided by this kernel module.

-

Optionally, set the hw.i6300esbwd.x.locked=1 - sysctl(8) to prevent users from disabling the watchdog - timeout check after it has been enabled.

-

Note that on some ICH-based systems, the WDT may be present but - disabled, either in hardware or by the BIOS. The - ichwd driver attempts to detect this condition and - will refuse to attach if it believes the WDT is disabled.

-
-
-

-

watchdog(4), watchdog(8), - watchdogd(8), watchdog(9)

-

Using the Intel ICH Family - Watchdog Timer (WDT), Intel Application Note - AP-725, Document Number - 292273-001.

-
-
-

-

The ichwd driver first appeared in - FreeBSD 5.3.

-
-
-

-

The ichwd driver was written by - Wm. Daryl Hawkins - <dhawkins@tamu.edu> - of Texas A&M University and Dag-Erling - Smørgrav - <des@FreeBSD.org>. - This manual page was written by Dag-Erling - Smørgrav - <des@FreeBSD.org>.

-
-
- - - - - -
January 3, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/icmp.4 3.html b/static/freebsd/man4/icmp.4 3.html deleted file mode 100644 index 78c88ccb..00000000 --- a/static/freebsd/man4/icmp.4 3.html +++ /dev/null @@ -1,477 +0,0 @@ - - - - - - -
ICMP(4)Device Drivers ManualICMP(4)
-
-
-

-

icmp — Internet - Control Message Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h>

-

int -
- socket(AF_INET, - SOCK_RAW, - proto);

-
-
-

-

ICMP is the error and control message protocol used by IP and the - Internet protocol family. It may be accessed through a “raw - socket” for network monitoring and diagnostic functions. The - proto parameter to the socket call to create an ICMP - socket is obtained from getprotobyname(3). ICMP sockets - are connectionless, and are normally used with the - sendto(2) and recvfrom(2) calls, though - the connect(2) call may also be used to fix the - destination for future packets (in which case the read(2) - or recv(2) and write(2) or - send(2) system calls may be used).

-

Outgoing packets automatically have an IP header prepended to them - (based on the destination address). Incoming packets are received with the - IP header and options intact.

-
-

-

ICMP messages are classified according to the type and code fields - present in the ICMP header. The abbreviations for the types and codes may be - used in rules in pf.conf(5). The following types are - defined:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0echorepEcho reply
3unreachDestination unreachable
4squenchPacket loss, slow down
5redirShorter route exists
6althostAlternate host address
8echoreqEcho request
9routeradvRouter advertisement
10routersolRouter solicitation
11timexTime exceeded
12paramprobInvalid IP header
13timereqTimestamp request
14timerepTimestamp reply
15inforeqInformation request
16inforepInformation reply
17maskreqAddress mask request
18maskrepAddress mask reply
30traceTraceroute
31dataconvData conversion problem
32mobredirMobile host redirection
33ipv6-whereIPv6 where-are-you
34ipv6-hereIPv6 i-am-here
35mobregreqMobile registration request
36mobregrepMobile registration reply
39skipSKIP
40photurisPhoturis
-

The following codes are defined:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0net-unrunreachNetwork unreachable
1host-unrunreachHost unreachable
2proto-unrunreachProtocol unreachable
3port-unrunreachPort unreachable
4needfragunreachFragmentation needed but DF bit set
5srcfailunreachSource routing failed
6net-unkunreachNetwork unknown
7host-unkunreachHost unknown
8isolateunreachHost isolated
9net-prohibunreachNetwork administratively prohibited
10host-prohibunreachHost administratively prohibited
11net-tosunreachInvalid TOS for network
12host-tosunreachInvalid TOS for host
13filter-prohibunreachProhibited access
14host-precedunreachPrecedence violation
15cutoff-precedunreachPrecedence cutoff
0redir-netredirShorter route for network
1redir-hostredirShorter route for host
2redir-tos-netredirShorter route for TOS and network
3redir-tos-hostredirShorter route for TOS and host
0normal-advrouteradvNormal advertisement
16common-advrouteradvSelective advertisement
0transittimexTime exceeded in transit
1reassembtimexTime exceeded in reassembly
0badheadparamprobInvalid option pointer
1optmissparamprobMissing option
2badlenparamprobInvalid length
1unknown-indphoturisUnknown security index
2auth-failphoturisAuthentication failed
3decrypt-failphoturisDecryption failed
-
-
-

-

The ICMP protocol implements a number of variables in the - net.inet.icmp branch of the - sysctl(3) MIB, which can also be read or modified with - sysctl(8).

-
-
bmcastecho
-
(boolean) Enable/disable ICMP replies received via - broadcast or multicast. Defaults to false.
-
drop_redirect
-
(boolean) Enable/disable dropping of ICMP Redirect - packets. Defaults to false.
-
icmplim
-
(unsigned integer) Mean rate limit for replies in - packets/second. The actual limit is icmplim plus a - random jitter limited by icmplim_jitter. If set to - zero, no limiting will occur. Defaults to 200.
-
icmplim_jitter
-
(unsigned integer) A random jitter between the - negative of icmplim_jitter and - icmplim_jitter is applied to - icmplim for limiting the sending rate of replies. - icmplim_jitter must be smaller than - icmplim, if icmplim is not - zero. If set to zero, no jitter will be applied. Defaults to 16.
-
icmplim_output
-
(boolean) Enable/disable logging of ICMP replies - bandwidth limiting. Defaults to true.
-
log_redirect
-
(boolean) Enable/disable logging of ICMP Redirect - packets. Defaults to false.
-
maskfake
-
(unsigned integer) When - maskrepl is set and this value is non-zero, it will - be used instead of the real address mask when the system replies to an - ICMP Address Mask Request packet. Defaults to 0.
-
maskrepl
-
(boolean) Enable/disable replies to ICMP Address - Mask Request packets. Defaults to false.
-
quotelen
-
(integer) Number of bytes from original packet to - quote in ICMP reply. This number is internally enforced to be at least 8 - bytes (per RFC792) and at most the maximal space left in the ICMP reply - mbuf.
-
redirtimeout
-
(integer) Delay in seconds before expiring route - created by ICMP redirect.
-
reply_from_interface
-
(boolean) Use the IP address of the interface the - packet came in through for responses to packets which are not directly - addressed to us. If enabled, this rule is processed before all others. By - default, continue with normal source selection. Enabling this option is - particularly useful on routers because it makes external traceroutes show - the actual path a packet has taken instead of the possibly different - return path.
-
reply_src
-
(str) An interface name used for the ICMP reply - source in response to packets which are not directly addressed to us. By - default continue with normal source selection.
-
tstamprepl
-
(boolean) Enable/disable replies to ICMP Timestamp - packets. Defaults to true.
-
-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[]
-
when trying to establish a connection on a socket which already has one, - or when trying to send a datagram with the destination address specified - and the socket is already connected;
-
[]
-
when trying to send a datagram, but no destination address is specified, - and the socket has not been connected;
-
[]
-
when the system runs out of memory for an internal data structure;
-
[]
-
when an attempt is made to create a socket with a network address for - which no network interface exists.
-
-
-
-

-

recv(2), send(2), - sysctl(3), inet(4), - intro(4), ip(4), - pf.conf(5), sysctl(8)

-
-
-

-

The icmp protocol implementation appeared - in 4.2BSD.

-
-
- - - - - -
December 11, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/icmp6.4 3.html b/static/freebsd/man4/icmp6.4 3.html deleted file mode 100644 index e2aece9b..00000000 --- a/static/freebsd/man4/icmp6.4 3.html +++ /dev/null @@ -1,398 +0,0 @@ - - - - - - -
ICMP6(4)Device Drivers ManualICMP6(4)
-
-
-

-

icmp6 — Internet - Control Message Protocol for IPv6

-
-
-

-

#include - <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet/icmp6.h>

-

int -
- socket(AF_INET6, - SOCK_RAW, - IPPROTO_ICMPV6);

-
-
-

-

ICMPv6 is the error and control message protocol used by IPv6 and - the IPv6 protocol family (see ip6(4) and - inet6(4)). It may be accessed through a “raw - socket” for network monitoring and diagnostic functions.

-

The proto parameter to the - socket(2) call to create an ICMPv6 socket may be obtained - from getprotobyname(3). ICMPv6 sockets are connectionless, - and are normally used with the sendto(2) and - recvfrom(2) calls, though the connect(2) - call may also be used to fix the destination for future packets (in which - case read(2) or recv(2) and - write(2) or send(2) system calls may be - used).

-

Outgoing packets automatically have an IPv6 header prepended to - them (based on the destination address). Incoming packets on the socket are - received with the IPv6 header and any extension headers removed.

-
-

-

ICMPv6 messages are classified according to the type and code - fields present in the ICMPv6 header. The abbreviations for the types and - codes may be used in rules in pf.conf(5). The following - types are defined:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1unreachDestination unreachable
2toobigPacket too big
3timexTime exceeded
4paramprobInvalid IPv6 header
128echoreqEcho service request
129echorepEcho service reply
130groupqryGroup membership query
130listqryMulticast listener query
131grouprepGroup membership report
131listenrepMulticast listener report
132grouptermGroup membership termination
132listendoneMulticast listener done
133routersolRouter solicitation
134routeradvRouter advertisement
135neighbrsolNeighbor solicitation
136neighbradvNeighbor advertisement
137redirShorter route exists
138routrrenumRoute renumbering
139fqdnreqFQDN query
139niqryNode information query
139wrureqWho-are-you request
140fqdnrepFQDN reply
140nirepNode information reply
140wrurepWho-are-you reply
200mtracerespmtrace response
201mtracemtrace messages
-

The following codes are defined:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0noroute-unrunreachNo route to destination
1admin-unrunreachAdministratively prohibited
2beyond-unrunreachBeyond scope of source address
2notnbr-unrunreachNot a neighbor (obsolete)
3addr-unrunreachAddress unreachable
4port-unrunreachPort unreachable
0transittimexTime exceeded in transit
1reassembtimexTime exceeded in reassembly
0badheadparamprobErroneous header field
1nxthdrparamprobUnrecognized next header
2redirUnrecognized option
0redironlinkredirRedirection to on-link node
1redirrouterredirRedirection to better router
-
-
-

-

All ICMPv6 messages are prefixed with an ICMPv6 header. This - header corresponds to the icmp6_hdr structure and has - the following definition:

-
-
struct icmp6_hdr {
-	uint8_t  icmp6_type;	/* type field */
-	uint8_t  icmp6_code;	/* code field */
-	uint16_t icmp6_cksum;	/* checksum field */
-	union {
-		uint32_t icmp6_un_data32[1]; /* type-specific */
-		uint16_t icmp6_un_data16[2]; /* type-specific */
-		uint8_t  icmp6_un_data8[4];  /* type-specific */
-	} icmp6_dataun;
-} __packed;
-
-#define icmp6_data32	icmp6_dataun.icmp6_un_data32
-#define icmp6_data16	icmp6_dataun.icmp6_un_data16
-#define icmp6_data8	icmp6_dataun.icmp6_un_data8
-#define icmp6_pptr	icmp6_data32[0]	/* parameter prob */
-#define icmp6_mtu	icmp6_data32[0]	/* packet too big */
-#define icmp6_id	icmp6_data16[0]	/* echo request/reply */
-#define icmp6_seq	icmp6_data16[1]	/* echo request/reply */
-#define icmp6_maxdelay	icmp6_data16[0]	/* mcast group membership*/
-
-

icmp6_type describes the type of the - message. Suitable values are defined in - ⟨netinet/icmp6.h⟩. - icmp6_code describes the sub-type of the message and - depends on icmp6_type. - icmp6_cksum contains the checksum for the message and - is filled in by the kernel on outgoing messages. The other fields are used - for type-specific purposes.

-
-
-

-

Because of the extra functionality of ICMPv6 in comparison to - ICMPv4, a larger number of messages may be potentially received on an ICMPv6 - socket. Input filters may therefore be used to restrict input to a subset of - the incoming ICMPv6 messages so only interesting messages are returned by - the recv(2) family of calls to an application.

-

The icmp6_filter structure may be used to - refine the input message set according to the ICMPv6 type. By default, all - messages types are allowed on newly created raw ICMPv6 sockets. The - following macros may be used to refine the input set:

-
-
void - (struct - icmp6_filter *filterp)
-
Allow all incoming messages. filterp is modified to - allow all message types.
-
void - (struct - icmp6_filter *filterp)
-
Ignore all incoming messages. filterp is modified to - ignore all message types.
-
void - (int - type, struct icmp6_filter *filterp)
-
Allow ICMPv6 messages with the given type. - filterp is modified to allow such messages.
-
void - (int - type, struct icmp6_filter *filterp)
-
Ignore ICMPv6 messages with the given type. - filterp is modified to ignore such messages.
-
int - (int - type, const struct icmp6_filter *filterp)
-
Determine if the given filter will allow an ICMPv6 message of the given - type.
-
int - (int - type, const struct icmp6_filter *filterp)
-
Determine if the given filter will ignore an ICMPv6 message of the given - type.
-
-

The getsockopt(2) and - setsockopt(2) calls may be used to obtain and install the - filter on ICMPv6 sockets at option level - IPPROTO_ICMPV6 and name - ICMP6_FILTER with a pointer to the - icmp6_filter structure as the option value.

-
-
-
-

-

getsockopt(2), recv(2), - send(2), setsockopt(2), - socket(2), getprotobyname(3), - inet6(4), ip6(4), - netintro(4)

-

W. Stevens and - M. Thomas, Advanced Sockets API - for IPv6, RFC 2292, - February 1998.

-

A. Conta and - S. Deering, Internet Control - Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) - Specification, RFC 2463, - December 1998.

-

W. Stevens, - M. Thomas, E. Nordmark, - and T. Jinmei, Advanced Sockets - Application Program Interface (API) for IPv6, RFC - 3542, May 2003.

-

A. Conta, - S. Deering, and M. Gupta, - Internet Control Message Protocol (ICMPv6) for the - Internet Protocol Version 6 (IPv6) Specification, - RFC 4443, March - 2006.

-
-
- - - - - -
November 1, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/ida.4 3.html b/static/freebsd/man4/ida.4 3.html deleted file mode 100644 index 676d1c81..00000000 --- a/static/freebsd/man4/ida.4 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
IDA(4)Device Drivers ManualIDA(4)
-
-
-

-

ida — Compaq - Intelligent Drive Array Controllers

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device ida
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ida_load="YES"
-
-
-
-

-

The Compaq Intelligent Drive Array (IDA) technology is used to - distribute data across an array of hard drives. It unites these hard drives - into one or more high-performance logical drives. The drive array is managed - by an array controller.

-

These controllers have the ability to provide fault tolerance for - the connected drives and optionally provide write cache for the logical - drives. It is also possible for an application to access the SCSI bus - subsystem directly by using the pass-through interface.

-
-
-

-

The following controllers are supported by the - ida driver:

-

-
    -
  • Compaq SMART Array 221
    • -
  • Compaq Integrated SMART Array Controller
    • -
  • Compaq SMART Array 4200
    • -
  • Compaq SMART Array 4250ES
    • -
  • Compaq SMART 3200 Controller
    • -
  • Compaq SMART 3100ES Controller
    • -
  • Compaq SMART-2/DH Controller
    • -
  • Compaq SMART-2/SL Controller
    • -
  • Compaq SMART-2/P Controller
    • -
-
-
-

-

Extreme caution should be exercised when using the pass-through - interface. It is possible to interfere with normal system I/O and cause - hangs if pass-through is used to an active device. Pass-through should only - be used to a device that is otherwise quiescent.

-
-
-

-

cam(4), pass(4), - xpt(4), camcontrol(8)

-
-
-

-

The ida driver was written by - Jonathan Lemon - <jlemon@FreeBSD.org> - and Matthew N. Dodd - <mdodd@FreeBSD.org>. - This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
February 15, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ietp.4 4.html b/static/freebsd/man4/ietp.4 4.html deleted file mode 100644 index 06a01a02..00000000 --- a/static/freebsd/man4/ietp.4 4.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
IETP(4)Device Drivers ManualIETP(4)
-
-
-

-

ietp — Elantech - I2C touchpad device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device ietp -
-device hidbus -
-device hid -
-device iichid -
-device iicbus -
-device evdev -

-
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ietp_load="YES"
-
-
-
-

-

The ietp driver provides support for the - Elantech I2C touchpad multi-touch devices found in many laptops.

-

To get multi-touch device working in X(7) - (ports/x11/xorg-docs), install - ports/x11-drivers/xf86-input-libinput.

-
-
-

-

ietp creates a pseudo-device file, - /dev/input/eventX which presents the multi-touch - device as an input event device.

-
-
-

-

hid(4), loader.conf(5), - xorg.conf(5) (ports/x11/xorg), - libinput(4) - (ports/x11-drivers/xf86-input-libinput).

-
-
-

-

The ietp driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
-

-

ietp cannot act like - sysmouse(4)

-
-
- - - - - -
February 27, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/if_ipsec.4 3.html b/static/freebsd/man4/if_ipsec.4 3.html deleted file mode 100644 index 70eee8f8..00000000 --- a/static/freebsd/man4/if_ipsec.4 3.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - -
if_ipsec(4)Device Drivers Manualif_ipsec(4)
-
-
-

-

if_ipsec — IPsec - virtual tunneling interface

-
-
-

-

The if_ipsec network interface is a part - of the FreeBSD IPsec implementation. To compile it - into the kernel, place this line in the kernel configuration file:

-
options IPSEC
-

It can also be loaded as part of the ipsec - kernel module if the kernel was compiled with

-
options IPSEC_SUPPORT
-
-
-

-

The if_ipsec network interface is targeted - for creating route-based VPNs. It can tunnel IPv4 and IPv6 traffic over - either IPv4 or IPv6 and secure it with ESP.

-

if_ipsec interfaces are dynamically - created and destroyed with the ifconfig(8) - create and destroy - subcommands. The administrator must configure IPsec - tunnel endpoint addresses. These addresses will be - used for the outer IP header of ESP packets. The administrator can also - configure the protocol and addresses for the inner IP header with - ifconfig(8), and modify the routing table to route the - packets through the if_ipsec interface.

-

When the if_ipsec interface is configured, - it automatically creates special security policies. These policies can be - used to acquire security associations from the IKE daemon, which are needed - for establishing an IPsec tunnel. It is also possible to create needed - security associations manually with the setkey(8) - utility.

-

Each if_ipsec interface has an additional - numeric configuration option reqid - id. This id is used to - distinguish traffic and security policies between several - if_ipsec interfaces. The - reqid can be specified on interface creation and - changed later. If not specified, it is automatically assigned. Note that - changing reqid will lead to generation of new - security policies, and this may require creating new security - associations.

-
-
-

-

The example below shows manual configuration of an IPsec tunnel - between two FreeBSD hosts. Host A has the IP address 192.168.0.3, and host B - has the IP address 192.168.0.5.

-

On host A:

-
-
ifconfig ipsec0 create reqid 100
-ifconfig ipsec0 inet tunnel 192.168.0.3 192.168.0.5
-ifconfig ipsec0 inet 172.16.0.3/16 172.16.0.5
-setkey -c
-add 192.168.0.3 192.168.0.5 esp 10000 -m tunnel -u 100 -E rijndael-cbc "VerySecureKey!!1";
-add 192.168.0.5 192.168.0.3 esp 10001 -m tunnel -u 100 -E rijndael-cbc "VerySecureKey!!2";
-^D
-
-

On host B:

-
-
ifconfig ipsec0 create reqid 200
-ifconfig ipsec0 inet tunnel 192.168.0.5 192.168.0.3
-ifconfig ipsec0 inet 172.16.0.5/16 172.16.0.3
-setkey -c
-add 192.168.0.3 192.168.0.5 esp 10000 -m tunnel -u 200 -E rijndael-cbc "VerySecureKey!!1";
-add 192.168.0.5 192.168.0.3 esp 10001 -m tunnel -u 200 -E rijndael-cbc "VerySecureKey!!2";
-^D
-
-

Note the value 100 on host A and value 200 on host B are used as - reqid. The same value must be used as identifier of the policy entry in the - setkey(8) command.

-
-
-

-

gif(4), gre(4), - ipsec(4), ifconfig(8), - setkey(8)

-
-
-

-

Andrey V. Elsukov - <ae@FreeBSD.org>

-
-
- - - - - -
February 6, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/if_ntb.4 4.html b/static/freebsd/man4/if_ntb.4 4.html deleted file mode 100644 index 27b057d3..00000000 --- a/static/freebsd/man4/if_ntb.4 4.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
IF_NTB(4)Device Drivers ManualIF_NTB(4)
-
-
-

-

if_ntb — Virtual - Ethernet interface for Non-Transparent Bridges

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device ntb -
-device ntb_transport -
-device if_ntb
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
if_ntb_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hw.if_ntb.num_queues
-
Limits maximal number of queues per interface. Default is unlimited.
-
-
-
-

-

The if_ntb driver attaches on top of the - ntb_transport(4) driver to utilize one or more of its - packet queues to create virtual Ethernet network interface between the - systems. Typical MTU for the interface is about 64KB to reduce overhead. - Default MAC address for the interface is randomly generated.

-

The if_ntb driver does not implement any - real hardware offload, but since PCIe link is protected by CRC32, in some - situations it may be possible to save some CPU cycles by enabling fake - checksum offload on both link sides via setting - rxcsum and txcsum interface - options.

-
-
-

-

ntb_transport(4)

-
-
-

-

The if_ntb driver was developed by Intel - and originally written by Carl Delsey - <carl@FreeBSD.org>. - Later improvements were done by Conrad E. Meyer - <cem@FreeBSD.org> and - Alexander Motin - <mav@FreeBSD.org>.

-
-
-

-

Linux supports only one queue per interface, so manual - configuration may be required for compatibility.

-
-
- - - - - -
September 2, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/iflib.4 3.html b/static/freebsd/man4/iflib.4 3.html deleted file mode 100644 index 0373e222..00000000 --- a/static/freebsd/man4/iflib.4 3.html +++ /dev/null @@ -1,242 +0,0 @@ - - - - - - -
IFLIB(4)Device Drivers ManualIFLIB(4)
-
-
-

-

iflib — Network - Interface Driver Framework

-
-
-

-

device pci -
- device iflib

-
-
-

-

iflib is a framework for network interface - drivers for FreeBSD. It is designed to remove a - large amount of the boilerplate that is often needed for modern network - interface devices, allowing driver authors to focus on the specific code - needed for their hardware. This allows for a shared set of - sysctl(8) names, rather than each driver naming them - individually.

-
-
-

-

These variables must be set before loading the driver, either via - loader.conf(5) or through the use of - kenv(1). They are all prefixed by - dev.X.Y.iflib. where X is the driver name, and Y is - the instance number.

-
-
override_nrxds
-
Override the number of RX descriptors for each queue. The value is a comma - separated list of positive integers. Some drivers only use a single value, - but others may use more. These numbers must be powers of two, and zero - means to use the default. Individual drivers may have additional - restrictions on allowable values. Defaults to all zeros.
-
override_ntxds
-
Override the number of TX descriptors for each queue. The value is a comma - separated list of positive integers. Some drivers only use a single value, - but others may use more. These numbers must be powers of two, and zero - means to use the default. Individual drivers may have additional - restrictions on allowable values. Defaults to all zeros.
-
override_qs_enable
-
When set, allows the number of transmit and receive queues to be - different. If not set, the lower of the number of TX or RX queues will be - used for both.
-
override_nrxqs
-
Set the number of RX queues. If zero, the number of RX queues is derived - from the number of cores on the socket connected to the controller. - Defaults to 0.
-
override_ntxqs
-
Set the number of TX queues. If zero, the number of TX queues is derived - from the number of cores on the socket connected to the controller.
-
disable_msix
-
Disables MSI-X interrupts for the device.
-
core_offset
-
Specifies a starting core offset to assign queues to. If the value is - unspecified or 65535, cores are assigned sequentially across - controllers.
-
separate_txrx
-
Requests that RX and TX queues not be paired on the same core. If this is - zero or not set, an RX and TX queue pair will be assigned to each core. - When set to a non-zero value, TX queues are assigned to cores following - the last RX queue.
-
simple_tx
-
When set to one, iflib uses a simple transmit routine with no queuing at - all. By default, iflib uses a highly optimized, lockless, transmit queue - called mp_ring. This performs well when there are more CPU cores than NIC - queues and prevents lock contention for transmit resources. Unfortunately, - mp_ring incurs unneeded overheads on workloads where resource contention - is not a problem (well behaved applications on systems where there are as - many NIC queues as CPU cores). Note that when this is enabled, the - tx_abdicate sysctl is no longer applicable and is ignored. Defaults to - zero.
-
-

These sysctl(8) variables can be changed at any - time:

-
-
tx_abdicate
-
Controls how the transmit ring is serviced. If set to zero, when a frame - is submitted to the transmission ring, the same task that is submitting it - will service the ring unless there's already a task servicing the TX ring. - This ensures that whenever there is a pending transmission, the transmit - ring is being serviced. This results in higher transmit throughput. If set - to a non-zero value, task returns immediately and the transmit ring is - serviced by a different task. This returns control to the caller faster - and under high receive load, may result in fewer dropped RX frames.
-
tx_defer_mfree
-
Controls the threshold in packets before iflib will free the memory - (mbufs) for the packets that it has transmitted. When this is nonzero, - mbufs will be freed outside the transmit lock. Setting this can reduce - lock contention and CPU use when using simple_tx. Note that this applies - only when simple_tx is enabled.
-
tx_reclaim_thresh
-
Controls the threshold in packets before iflib will ask the driver how - many transmitted packets can be reclaimed. Determining how many many - packets can be reclaimed can be expensive on some drivers.
-
tx_reclaim_ticks
-
Controls the time in ticks before iflib will ask the driver how many - transmitted packets can be reclaimed. Determining how many many packets - can be reclaimed can be expensive on some drivers.
-
rx_budget
-
Sets the maximum number of frames to be received at a time. Zero (the - default) indicates the default (currently 16) should be used.
-
-

There are also some global sysctls which can change behaviour for - all drivers, and may be changed at any time.

-
-
net.iflib.min_tx_latency
-
If this is set to a non-zero value, iflib will avoid any attempt to - combine multiple transmits, and notify the hardware as quickly as possible - of new descriptors. This will lower the maximum throughput, but will also - lower transmit latency.
-
net.iflib.no_tx_batch
-
Some NICs allow processing completed transmit descriptors in batches. - Doing so usually increases the transmit throughput by reducing the number - of transmit interrupts. Setting this to a non-zero value will disable the - use of this feature.
-
-

These sysctl(8) variables are read-only:

-
-
driver_version
-
A string indicating the internal version of the driver.
-
-

There are a number of queue state sysctl(8) - variables as well:

-
-
txqZ
-
The following are repeated for each transmit queue, where Z is the - transmit queue instance number: -
-
r_abdications
-
Number of consumer abdications in the MP ring for this queue. An - abdication occurs on every ring submission when tx_abdicate is - true.
-
r_restarts
-
Number of consumer restarts in the MP ring for this queue. A restart - occurs when an attempt to drain a non-empty ring fails, and the ring - is already in the STALLED state.
-
r_stalls
-
Number of consumer stalls in the MP ring for this queue. A stall - occurs when an attempt to drain a non-empty ring fails.
-
r_starts
-
Number of normal consumer starts in the MP ring for this queue. A - start occurs when the MP ring transitions from IDLE to BUSY.
-
r_drops
-
Number of drops in the MP ring for this queue. A drop occurs when - there is an attempt to add an entry to an MP ring with no available - space.
-
r_enqueues
-
Number of entries which have been enqueued to the MP ring for this - queue.
-
ring_state
-
MP (soft) ring state. This provides a snapshot of the current MP ring - state, including the producer head and tail indexes, the consumer - index, and the state. The state is one of "IDLE", - "BUSY", "STALLED", or "ABDICATED".
-
txq_cleaned
-
The number of transmit descriptors which have been reclaimed. Total - cleaned.
-
txq_processed
-
The number of transmit descriptors which have been processed, but may - not yet have been reclaimed.
-
txq_in_use
-
Descriptors which have been added to the transmit queue, but have not - yet been cleaned. This value will include both untransmitted - descriptors as well as descriptors which have been processed.
-
txq_cidx_processed
-
The transmit queue consumer index of the next descriptor to - process.
-
txq_cidx
-
The transmit queue consumer index of the oldest descriptor to - reclaim.
-
txq_pidx
-
The transmit queue producer index where the next descriptor to - transmit will be inserted.
-
no_tx_dma_setup
-
Number of times DMA mapping a transmit mbuf failed for reasons other - than EFBIG.
-
txd_encap_efbig
-
Number of times DMA mapping a transmit mbuf failed due to requiring - too many segments.
-
tx_map_failed
-
Number of times DMA mapping a transmit mbuf failed for any reason (sum - of no_tx_dma_setup and txd_encap_efbig)
-
no_desc_avail
-
Number of times a descriptor couldn't be added to the transmit ring - because the transmit ring was full.
-
mbuf_defrag_failed
-
Number of times both m_collapse(9) and - m_defrag(9) failed after an - EFBIG error result from DMA mapping a transmit - mbuf.
-
m_pullups
-
Number of times m_pullup(9) was called attempting to - parse a header.
-
mbuf_defrag
-
Number of times m_defrag(9) was called.
-
-
-
rxqZ
-
The following are repeated for each receive queue, where Z is the receive - queue instance number: -
-
rxq_fl0.credits
-
Credits currently available in the receive ring.
-
rxq_fl0.cidx
-
Current receive ring consumer index.
-
rxq_fl0.pidx
-
Current receive ring producer index.
-
-
-
-

Additional OIDs useful for driver and iflib development are - exposed when the INVARIANTS and/or WITNESS options are enabled in the - kernel.

-
-
-

-

iflib(9)

-
-
-

-

This framework was introduced in FreeBSD - 11.0.

-
-
- - - - - -
January 7, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/ifmib.4 3.html b/static/freebsd/man4/ifmib.4 3.html deleted file mode 100644 index 20d76a0a..00000000 --- a/static/freebsd/man4/ifmib.4 3.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - -
IFMIB(4)Device Drivers ManualIFMIB(4)
-
-
-

-

ifmib — Management - Information Base for network interfaces

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <sys/sysctl.h> -
- #include <sys/time.h> -
- #include <net/if.h> -
- #include <net/if_mib.h>

-
-
-

-

The ifmib facility is an application of - the sysctl(3) interface to provide management information - about network interfaces to client applications such as - netstat(1), slstat(8), and SNMP - management agents. This information is structured as a table, where each row - in the table represents a logical network interface (either a hardware - device or a software pseudo-device like lo(4)). There are - two columns in the table, each containing a single structure: one column - contains generic information relevant to all interfaces, and the other - contains information specific to the particular class of interface. - (Generally the latter will implement the SNMP MIB defined for that - particular interface class, if one exists and can be implemented in the - kernel.)

-

The ifmib facility is accessed via the - “net.link.generic” branch of the - sysctl(3) MIB. The manifest constants for each level in - the sysctl(3) name are defined in - <net/if_mib.h>. The index of - the last row in the table is given by - “net.link.generic.system.ifcount” (or, - using the manifest constants, CTL_NET, - PF_LINK, NETLINK_GENERIC, - IFMIB_SYSTEM, - IFMIB_IFCOUNT). A management application searching - for a particular interface should start with row 1 and continue through the - table row-by-row until the desired interface is found, or the interface - count is reached. Note that the table may be sparse, i.e., a given row may - not exist, indicated by an errno of - ENOENT. Such an error should be ignored, and the - next row should be checked.

-

The generic interface information, common to all interfaces, can - be accessed via the following procedure:

-
-
int
-get_ifmib_general(int row, struct ifmibdata *ifmd)
-{
-	int name[6];
-	size_t len;
-
-	name[0] = CTL_NET;
-	name[1] = PF_LINK;
-	name[2] = NETLINK_GENERIC;
-	name[3] = IFMIB_IFDATA;
-	name[4] = row;
-	name[5] = IFDATA_GENERAL;
-
-	len = sizeof(*ifmd);
-
-	return sysctl(name, 6, ifmd, &len, (void *)0, 0);
-}
-
-

The fields in struct ifmibdata are as - follows:

-
-
-
(char []) the name of the interface, including the - unit number
-
-
(int) the number of promiscuous listeners
-
-
(int) the interface's flags (defined in - <net/if.h>)
-
-
(int) the current instantaneous length of the send - queue
-
-
(int) the number of packets dropped at this - interface because the send queue was full
-
-
(struct if_data) more information from a structure - defined in <net/if.h> (see - if_data(9))
-
-

Class-specific information can be retrieved by examining the - IFDATA_LINKSPECIFIC column instead. Note that the - form and length of the structure will depend on the class of interface. For - IFT_ETHER, IFT_ISO88023, and - IFT_STARLAN interfaces, the structure is called - “struct ifmib_iso_8802_3” (defined in - <net/if_mib.h>), and - implements a superset of the RFC 1650 MIB for Ethernet-like networks.

-
-
-

-

sysctl(3), intro(4), - ifnet(9)

-

F. Kastenholz, - Definitions of Managed Objects for the Ethernet-like - Interface Types Using SMIv2, August 1994, - RFC 1650.

-
-
-

-

The ifmib interface first appeared in - FreeBSD 2.2.

-
-
-

-

Many Ethernet-like interfaces do not yet support the Ethernet MIB. - Regardless, all interfaces automatically support the generic MIB.

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ig4.4 3.html b/static/freebsd/man4/ig4.4 3.html deleted file mode 100644 index 11ff31c0..00000000 --- a/static/freebsd/man4/ig4.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
IG4(4)Device Drivers ManualIG4(4)
-
-
-

-

ig4 — Synopsys - DesignWare I2C Controller

-
-
-

-

To compile this driver into the kernel, place the following lines - into the kernel configuration file:

-
device ig4 -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ig4_load="YES"
-
-
-
-

-

The ig4 driver provides access to - peripherals attached to an I2C controller.

-
-
-

-

ig4 supports the I2C controllers based on - Synopsys DesignWare IP that can be found in Intel(R) Core(TM) processors - starting from the fourth generation, Intel(R) Bay Trail, Apollo Lake SoC - families, and some AMD systems.

-
-
-

-

These sysctl(8) variables are available:

-
-
debug.ig4_dump
-
This sysctl is a zero-based bit mask. When any of the bits are set, a - register dump is printed for every I2C transfer on an - ig4 device with the same unit number.
-
-
-
-

-

iic(4), iicbus(4)

-
-
-

-

The ig4 driver was written for - DragonFly by Matthew Dillon - and subsequently ported to FreeBSD by - Michael Gmelin - <freebsd@grem.de>.

-

This manual page was written by Michael - Gmelin - <freebsd@grem.de>.

-
-
- - - - - -
September 13, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/igc.4 3.html b/static/freebsd/man4/igc.4 3.html deleted file mode 100644 index 6be6136b..00000000 --- a/static/freebsd/man4/igc.4 3.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - -
IGC(4)Device Drivers ManualIGC(4)
-
-
-

-

igc — Intel - Ethernet Controller I225 2.5GbE driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device igc
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_igc_load="YES"
-
-
-
-

-

The igc driver provides support for any - PCI Express adapter or LOM (LAN On Motherboard) based on the Intel I225 - Multi Gigabit Controller. The driver supports Transmit/Receive checksum - offload, Jumbo Frames, MSI/MSI-X, TSO, and RSS.

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 9216 - bytes.

-

This driver version supports VLAN hardware insertion / extraction, - and VLAN checksum offload. For information on enabling VLANs, see - ifconfig(8). The igc driver - supports the following media types:

-
-
-
Enables auto-negotiation for speed and duplex.
-
-
Sets 10Mbps operation. Use the mediaopt option to - select half-duplex mode.
-
-
Sets 100Mbps operation. Use the mediaopt option to - select half-duplex mode.
-
-
Sets 1000Mbps operation. Only full-duplex mode is - supported at this speed.
-
-
Sets 2500Mbps operation. Only full-duplex mode is - supported at this speed.
-
-
-
-

-

The igc driver supports the following - 2.5Gb Ethernet controllers:

-

-
    -
  • I220-V
    • -
  • I221-V
    • -
  • I225-LM
    • -
  • I225-LMvP(2)
    • -
  • I225-V
    • -
  • I225-IT, I225-IT(2)
    • -
  • I225-K, I225-K(2)
    • -
  • I226-LM
    • -
  • I226-LMvP
    • -
  • I226-V
    • -
  • I226-IT
    • -
  • I226-K
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.igc.igc_disable_crc_stripping
-
Disable or enable hardware stripping of CRC field. This is mostly useful - on BMC/IPMI shared interfaces where stripping the CRC causes remote access - over IPMI to fail. Default 0 (enabled).
-
hw.igc.sbp
-
Show bad packets when in promiscuous mode. Default is false.
-
hw.igc.eee_setting
-
Disable or enable Energy Efficient Ethernet. Default 1 (disabled).
-
hw.igc.max_interrupt_rate
-
Maximum device interrupts per second. The default is 8000.
-
-
-
-

-
-
igc%d: Hardware Initialization Failed
-
A fatal initialization error has occurred.
-
igc%d: Unable to allocate bus resource: memory
-
A fatal initialization error has occurred.
-
igc%d: Invalid MAC address
-
The MAC address programmed into the EEPROM is either empty or a - multicast/broadcast address.
-
-
-
-

-

altq(4), arp(4), - iflib(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The igc device driver first appeared in - FreeBSD 13.1.

-
-
-

-

The igc was originally written by - Intel Corporation and converted to the - iflib(4) framework by Netgate.

-
-
- - - - - -
March 9, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/igmp.4 3.html b/static/freebsd/man4/igmp.4 3.html deleted file mode 100644 index 7f412f35..00000000 --- a/static/freebsd/man4/igmp.4 3.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - -
IGMP(4)Device Drivers ManualIGMP(4)
-
-
-

-

igmp — Internet - Group Management Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet/in_systm.h> -
- #include <netinet/ip.h> -
- #include <netinet/igmp.h>

-

int -
- socket(AF_INET, - SOCK_RAW, - IPPROTO_IGMP);

-
-
-

-

IGMP is a control plane protocol used by IPv4 hosts and routers to - propagate multicast group membership information. Normally this protocol is - not used directly, except by the kernel itself, in response to multicast - membership requests by user applications. Routing protocols may open a raw - socket to directly interact with igmp.

-

As of FreeBSD 8.0, IGMP version 3 is - implemented. This adds support for Source-Specific Multicast (SSM), whereby - applications may communicate to upstream multicast routers that they are - only interested in receiving multicast streams from particular sources.

-
-
-

-
-
net.inet.igmp.stats
-
This opaque read-only variable exposes the stack-wide IGMPv3 protocol - statistics to netstat(1).
-
net.inet.igmp.ifinfo
-
This opaque read-only variable exposes the per-link IGMPv3 status to - ifmcstat(8).
-
net.inet.igmp.gsrdelay
-
This variable specifies the time threshold, in seconds, for processing - Group-and-Source Specific Queries (GSR). As GSR query processing requires - maintaining state on the host, it may cause memory to be allocated, and is - therefore a potential attack point for Denial-of-Service (DoS). If more - than one GSR query is received within this threshold, it will be dropped, - to mitigate the potential for DoS.
-
net.inet.igmp.default_version
-
This variable controls the default version of IGMP to be used on all - links. This sysctl is normally set to 3 by default.
-
net.inet.igmp.legacysupp
-
If this variable is non-zero, then IGMP v1 and v2 membership reports - received on a link will be allowed to suppress the IGMP v3 state-change - reports which would otherwise be issued by this host. This sysctl is - normally enabled by default.
-
net.inet.igmp.v2enable
-
If this variable is non-zero, then IGMP v2 membership queries will be - processed by this host, and backwards compatibility will be enabled until - the v2 'Old Querier Present' timer expires. This sysctl is normally - enabled by default.
-
net.inet.igmp.v1enable
-
If this variable is non-zero, then IGMP v1 membership queries will be - processed by this host, and backwards compatibility will be enabled until - the v1 'Old Querier Present' timer expires. This sysctl is normally - enabled by default.
-
net.inet.igmp.sendlocal
-
If this variable is non-zero, then IGMP state-changes for groups in the - 224.0.0.0/24 link-scope prefix will be issued. This behaviour is - recommended if deploying FreeBSD in a network - environment with layer 2 devices which snoop IGMP traffic to mitigate - multicast propagation throughout the network. This sysctl is normally - enabled by default.
-
net.inet.igmp.sendra
-
If this variable is non-zero, then IGMP v2 and v3 reports will contain the - IP Router Alert option. This sysctl is normally enabled by default.
-
net.inet.igmp.recvifkludge
-
If this variable is non-zero, then received IGMP reports which contain - 0.0.0.0 as their source will be rewritten to contain the subnet address. - This is useful when there are hosts on-link which have not yet been - configured with a primary IPv4 address. This sysctl is normally enabled by - default.
-
-
-
-

-

netstat(1), sourcefilter(3), - inet(4), multicast(4), - ifmcstat(8)

-
-
-

-

The igmp manual page re-appeared in - FreeBSD 8.0.

-
-
- - - - - -
March 9, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/iic.4 3.html b/static/freebsd/man4/iic.4 3.html deleted file mode 100644 index 97457fe9..00000000 --- a/static/freebsd/man4/iic.4 3.html +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -
IIC(4)Device Drivers ManualIIC(4)
-
-
-

-

iic — I2C generic - I/O device driver

-
-
-

-

device iic

-

-
- #include - <dev/iicbus/iic.h>

-
-
-

-

The iic device driver provides generic I/O - to any iicbus(4) instance. In order to control I2C - devices, use /dev/iic? with the following - ioctls:

-
-
-
(struct iiccmd) Sends the start condition to the - slave specified by the slave element to the bus. The - slave element consists of a 7-bit address and a - read/write bit (that is, a 7-bit address << 1 | r/w). A read - operation is initiated when the read/write bit is set, or a write - operation when it is cleared. All other elements are ignored. If - successful, the file descriptor receives exclusive ownership of the - underlying iicbus instance.
-
-
(struct iiccmd) Sends the repeated start condition - to the slave specified by the slave element to the - bus. The slave address should be specified as in - I2CSTART. All other elements are ignored. - I2CSTART must have previously been issued on the - same file descriptor.
-
-
No argument is passed. Sends the stop condition to the bus. If - I2CSTART was previously issued on the file - descriptor, the current transaction is terminated and exclusive ownership - of the underlying iicbus instance is released. Otherwise, no action is - performed.
-
-
(struct iiccmd) Resets the bus. The argument is - completely ignored. This command does not require - I2CSTART to have been previously issued on the - file descriptor. If it was previously issued, exclusive ownership of the - underlying iicbus instance is released.
-
-
(struct iiccmd) Writes data to the - iicbus(4). The bus must already be started by a previous - I2CSTART on the file descriptor. The - slave element is ignored. The - count element is the number of bytes to write. The - last element is a boolean flag. It must be zero when - additional read commands will follow, or non-zero if this is the last - command. The buf element is a pointer to the data to - write to the bus.
-
-
(struct iiccmd) Reads data from the - iicbus(4). The bus must already be started by a previous - I2CSTART on the file descriptor. The - slave element is ignored. The - count element is the number of bytes to read. The - last element is a boolean flag. It must be zero when - additional read commands will follow, or non-zero if this is the last - command. The buf element is a pointer to where to - store the data read from the bus. Short reads on the bus produce undefined - results.
-
-
(struct iic_rdwr_data) Generic read/write interface. - Allows for an arbitrary number of commands to be sent to an arbitrary - number of devices on the bus. Any previous transaction started by - I2CSTART must be terminated by - I2CSTOP or I2CRSTCARD - before I2CRDWR can be issued on the same file - descriptor. A read transfer is specified if - IIC_M_RD is set in flags. - Otherwise the transfer is a write transfer. The - slave element specifies the 7-bit address with the - read/write bit for the transfer. The read/write bit will be handled by the - iicbus stack based on the specified transfer operation. The - len element is the number of (struct - iic_msg) messages encoded on (struct - iic_rdwr_data). The buf element is a buffer - for that data. This ioctl is intended to be Linux compatible.
-
-
(uint8_t) Associate the specified address with the - file descriptor for use by subsequent read(2) or - write(2) calls. The argument is an 8-bit address (that - is, a 7-bit address << 1). The read/write bit in the - least-significant position is ignored. Any subsequent read or write - operation will set or clear that bit as needed.
-
-

The following data structures are defined in - <dev/iicbus/iic.h> and - referenced above:

-
-
struct iiccmd {
-	u_char slave;
-	int count;
-	int last;
-	char *buf;
-};
-
-/* Designed to be compatible with linux's struct i2c_msg */
-struct iic_msg
-{
-	uint16_t	slave;
-	uint16_t	flags;
-#define	IIC_M_WR	0	/* Fake flag for write */
-#define	IIC_M_RD	0x0001	/* read vs write */
-#define	IIC_M_NOSTOP	0x0002	/* do not send a I2C stop after message */
-#define	IIC_M_NOSTART	0x0004	/* do not send a I2C start before message */
-	uint16_t	len;	/* msg length */
-	uint8_t *	buf;
-};
-
-struct iic_rdwr_data {
-	struct iic_msg *msgs;
-	uint32_t nmsgs;
-};
-
-

It is also possible to use read(2) or - write(2), in which case the I2C start/stop handshake is - managed by iicbus(4). The address used for the read/write - operation is the one passed to the most recent - I2CSTART ioctl(2) or - I2CSADDR ioctl(2) on the open - /dev/iic? file descriptor. Closing the file - descriptor clears any addressing state established by a previous - I2CSTART or I2CSADDR, stops - any transaction established by a not-yet-terminated - I2CSTART, and releases iicbus ownership. Because - addressing state is stored on a per-file-descriptor basis, it is permissible - for multiple file descriptors to be simultaneously open on the same - /dev/iic? device. Concurrent transactions on those - descriptors are synchronized by the exclusive-ownership requests issued to - the underlying iicbus instance.

-
-
-

-

ioctl(2), read(2), - write(2), iicbus(4)

-
-
-

-

The iic manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu and M. Warner Losh.

-
-
- - - - - -
May 15, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/iic_gpiomux.4 4.html b/static/freebsd/man4/iic_gpiomux.4 4.html deleted file mode 100644 index a5ba5bb3..00000000 --- a/static/freebsd/man4/iic_gpiomux.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
IIC_GPIOMUX(4)Device Drivers ManualIIC_GPIOMUX(4)
-
-
-

-

iic_gpiomux — - driver for I2C mux hardware controlled via GPIO

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device iic_gpiomux
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
iic_gpiomux_load="YES"
-
-
-
-

-

The iic_gpiomux driver supports any type - of I2C bus multiplexer (mux) hardware that is controlled by manipulating the - state of one or more GPIO pins. It automatically connects an upstream I2C - bus to one of the downstream buses as needed when slave devices on the - downstream buses initiate I/O. More information on the automatic switching - behavior is available in iicmux(4).

-
-
-

-

On an fdt(4) based system, an - iic_gpiomux device node may be defined as a child - node of any arbitrary bus in the FDT data. The - i2c-parent property indicates the connection to the - upstream I2C bus. The children of the iic_gpiomux - node are additional i2c buses, which will have their own i2c slave devices - described in their child nodes.

-

The iic_gpiomux driver conforms to the - standard i2c/i2c-mux-gpio.txt bindings document.

-
-
-

-

iicbus(4), iicmux(4)

-
-
-

-

The iic_gpiomux driver first appeared in - FreeBSD 13.0.

-
-
- - - - - -
January 1, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/iicbb.4 4.html b/static/freebsd/man4/iicbb.4 4.html deleted file mode 100644 index 5cb6522a..00000000 --- a/static/freebsd/man4/iicbb.4 4.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -
IICBB(4)Device Drivers ManualIICBB(4)
-
-
-

-

iicbb — I2C - generic bit-banging driver

-
-
-

-

device iicbb

-

-
- device lpbb

-

For one or more iicbus busses: -
- device iicbus

-
-
-

-

The - - driver provides support to any bit-banging interface for the - iicbus(4) system.

-
-
-

-

iicbus(4), lpbb(4), - ppbus(4)

-
-
-

-

The iicbb manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
October 25, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/iicbus.4 3.html b/static/freebsd/man4/iicbus.4 3.html deleted file mode 100644 index 5afa5a0f..00000000 --- a/static/freebsd/man4/iicbus.4 3.html +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - -
IICBUS(4)Device Drivers ManualIICBUS(4)
-
-
-

-

iicbus — I2C bus - system

-
-
-

-

device iicbus -
- device iicbb

-

-
- device iic -
- device ic -
- device iicsmb

-
-
-

-

The - - system provides a uniform, modular and architecture-independent system for - the implementation of drivers to control various I2C devices and to utilize - different I2C controllers.

-
-
-

-

I2C is an acronym for Inter Integrated Circuit bus. The I2C bus - was developed in the early 1980's by Philips semiconductors. Its purpose was - to provide an easy way to connect a CPU to peripheral chips in a TV-set.

-

The BUS physically consists of 2 active wires and a ground - connection. The active wires, SDA and SCL, are both bidirectional. Where SDA - is the Serial DAta line and SCL is the Serial CLock line.

-

Every component hooked up to the bus has its own unique address - whether it is a CPU, LCD driver, memory, or complex function chip. Each of - these chips can act as a receiver and/or transmitter depending on its - functionality. Obviously an LCD driver is only a receiver, while a memory or - I/O chip can both be transmitter and receiver. Furthermore there may be one - or more BUS MASTERs.

-

The BUS MASTER is the chip issuing the commands on the BUS. In the - I2C protocol specification it is stated that the IC that initiates a data - transfer on the bus is considered the BUS MASTER. At that time all the - others are regarded to as the BUS SLAVEs. As mentioned before, the IC bus is - a Multi-MASTER BUS. This means that more than one IC capable of initiating - data transfer can be connected to it.

-
-
-

-

Some I2C device drivers are available:

-

- - - - - - - - - - - - - - - - - -
general i/o operation
network IP interface
I2C to SMB software bridge
-
-
-

-

The I2C protocol may be implemented by hardware or software. - Software interfaces rely on very simple hardware, usually two lines twiddled - by 2 registers. Hardware interfaces are more intelligent and receive 8-bit - characters they write to the bus according to the I2C protocol.

-

I2C interfaces may act on the bus as slave devices, allowing - spontaneous bidirectional communications, thanks to the multi-master - capabilities of the I2C protocol.

-

Some I2C interfaces are available:

-

- - - - - - - - - - - - - - - - - -
Philips PCF8584 master/slave interface
generic bit-banging master-only driver
parallel port specific bit-banging interface
-
-
-

-

The operating frequency of an I2C bus may be fixed or - configurable. The bus may be used as part of some larger standard interface, - and that interface specification may require a fixed frequency. The driver - for that hardware would not honor an attempt to configure a different speed. - A general purpose I2C bus, such as those found in many embedded systems, - will often support multiple bus frequencies.

-

When a system supports multiple I2C buses, a different frequency - can be configured for each bus by number, represented by the - %d in the variable names below. Buses can be - configured using any combination of device hints, Flattened Device Tree - (FDT) data, tunables set via loader(8), or at runtime - using sysctl(8). When configuration is supplied using more - than one method, FDT and hint data will be overridden by a tunable, which - can be overridden by sysctl(8).

-
-

-

Set hint.iicbus.%d.frequency to the - frequency in Hz, on systems that use device hints to configure I2C devices. - The hint is also honored by systems that use FDT data if no frequency is - configured using FDT.

-
-
-

-

Configure the I2C bus speed using the FDT standard - clock-frequency property of the node describing the - I2C controller hardware.

-
-
-

-

Set dev.iicbus.%d.frequency in - loader.conf(5). The same variable can be changed at any - time with sysctl(8). Reset the bus using - i2c(8) or the iic(4) - I2CRSTCARD ioctl to make the change take effect.

-
-
-
-

-

fdt(4), iic(4), - iicbb(4), lpbb(4), - pcf(4), i2c(8)

-
-
-

-

The iicbus manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
March 7, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/iichid.4 3.html b/static/freebsd/man4/iichid.4 3.html deleted file mode 100644 index c5dc8855..00000000 --- a/static/freebsd/man4/iichid.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
IICHID(4)Device Drivers ManualIICHID(4)
-
-
-

-

iichid — I2C HID - transport driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iichid
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
iichid_load="YES"
-
-
-
-

-

The iichid driver provides a interface to - I2C Human Interface Devices (HIDs).

-
-
-

-

Next parameters are available as sysctl(8) - variables. Debug parameter is available as loader(8) - tunable as well.

-
-
dev.iichid.*.sampling_rate_fast
-
Active sampling rate in num/second (for sampling mode).
-
dev.iichid.*.sampling_rate_slow
-
Idle sampling rate in num/second (for sampling mode).
-
dev.iichid.*.sampling_hysteresis
-
Number of missing samples before enabling of slow mode (for sampling - mode).
-
hw.iichid.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

ig4(4)

-
-
-

-

The iichid does not support GPIO - interrupts yet. In that case iichid enables sampling - mode with periodic polling of hardware by driver means. See - dev.iichid.*.sampling_* sysctl(8) variables for tuning of - sampling parameters.

-
-
-

-

The iichid driver first appeared in - FreeBSD 13.0.

-
-
-

-

The iichid driver was written by - Marc Priggemeyer - <marc.priggemeyer@gmail.com> - and Vladimir Kondratyev - <wulf@FreeBSD.org>.

-

This manual page was written by Vladimir - Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
September 21, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/iicmux.4 3.html b/static/freebsd/man4/iicmux.4 3.html deleted file mode 100644 index a5a32816..00000000 --- a/static/freebsd/man4/iicmux.4 3.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
IICMUX(4)Device Drivers ManualIICMUX(4)
-
-
-

-

iicmux — I2C bus - mulitiplexer framework

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device iicmux
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
iicmux_load="YES"
-
-

Note that it is usually not necessary to explicitly load the - driver module, as it will be loaded automatically along with the driver for - the specific mux hardware in use.

-
-
-

-

The iicmux framework provides support code - to help implement drivers for various I2C bus multiplexer (mux) hardware. - iicmux is not a standalone driver, it is a - collection of support functions and driver methods which are used by - individual mux hardware drivers. It will be loaded automatically when needed - by a mux hardware driver. This manual page provides an overview of the I2C - mux framework and its behavior.

-

Generally speaking, an I2C mux is connected to an upstream I2C - bus, and to one or more downstream I2C buses, and it can be commanded to - connect any one of the downstream buses to the upstream bus. Some hardware - may be able to connect multiple downstream buses at the same time, but that - concept is not supported by iicmux.

-

The iicmux framework operates - automatically when I2C slave devices initiate I/O. It does not require (or - even allow for) any external control to select the active downstream - bus.

-

When there is no I/O in progress, the mux is said to be in the - “idle” state. Some mux hardware has the ability to disconnect - all downstream buses when in an idle state. Other hardware must always have - one of the downstream buses connected. Individual mux hardware drivers - typically provide a way to select which downstream bus (if any) should be - connected while in the idle state. In the absence of such configuration, - whichever downstream bus was last used remains connected to the upstream - bus.

-

When an I2C slave device on a bus - downstream of a mux initiates I/O, it first requests exclusive use of the - bus by calling - (). - This request is communicated to the bus's parent, which is the - iicmux framework mux driver. Once exclusive bus - ownership is obtained, the mux driver connects the upstream I2C bus to the - downstream bus which hosts the slave device that requested bus ownership. - The mux hardware maintains that upstream-to-downstream connection until the - slave device calls - (). - Before releasing ownership, the mux driver returns the mux hardware to the - idle state.

-
-
-

-

On an fdt(4) based system, an I2C mux device - node is defined as a child node of its upstream I2C bus when the mux device - is an I2C slave itself. It may be defined as a child node of any other bus - or device in the system when it is not an I2C slave, in which case the - i2c-parent property indicates which upstream bus the - mux is attached to. In either case, the children of the mux node are - additional I2C buses, which will have one or more I2C slave devices - described in their child nodes.

-

Drivers using the iicmux framework conform - to the standard i2c/i2c-mux.txt bindings - document.

-
-
-

-

On a device.hints(5) based system, these values - are configurable for iicmux framework drivers :

-
-
hint.<driver>.<unit>.at
-
The upstream iicbus(4) the - iicmux instance is attached to.
-
-

When configured via hints, the driver automatically adds an iicbus - instance for every downstream bus supported by the chip. There is currently - no way to indicate used versus unused downstream buses.

-
-
-

-

iicbus(4)

-
-
-

-

The iicmux framework first appeared in - FreeBSD 13.0.

-
-
- - - - - -
January 1, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/iicsmb.4 4.html b/static/freebsd/man4/iicsmb.4 4.html deleted file mode 100644 index eeff9050..00000000 --- a/static/freebsd/man4/iicsmb.4 4.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
IICSMB(4)Device Drivers ManualIICSMB(4)
-
-
-

-

iicsmb — I2C to - SMBus bridge

-
-
-

-

device iicsmb

-

For one or more smbus busses: -
- device smbus

-
-
-

-

The - - driver supports SMB commands over iicbus(4) for the - smbus(4) system.

-
-
-

-

smbus(4)

-
-
-

-

The iicsmb manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
August 10, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/imcsmb.4 3.html b/static/freebsd/man4/imcsmb.4 3.html deleted file mode 100644 index 57c1b819..00000000 --- a/static/freebsd/man4/imcsmb.4 3.html +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - -
IMCSMB(4)Device Drivers ManualIMCSMB(4)
-
-
-

-

imcsmb — Intel - integrated Memory Controller (iMC) SMBus controller driver

-
-
-

-

device pci -
- device smbus -
- device imcsmb

-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
imcsmb_load="YES"
-
-
-
-

-

The imcsmb driver provides - smbus(4) support for the SMBus controller functionality in - the integrated Memory Controllers (iMCs) embedded in Intel Sandybridge-Xeon, - Ivybridge-Xeon, Haswell-Xeon, and Broadwell-Xeon CPUs. Each CPU implements - one or more iMCs, depending on the number of cores; each iMC implements two - SMBus controllers (iMC-SMBs). The iMC-SMBs are used by the iMCs to read - configuration information from the DIMMs during POST. They may also be used, - by motherboard firmware or a BMC, to monitor the temperature of the - DIMMs.

-

The iMC-SMBs are - general-purpose - SMBus controllers. By their nature, they are only ever attached to DIMMs, so - they implement only the SMBus operations need for communicating with DIMMs. - Specifically:

-

-
    -
  • READB
    • -
  • READW
    • -
  • WRITEB
    • -
  • WRITEW
    • -
-

A more detailed discussion of the hardware and driver architecture - can be found at the top of - sys/dev/imcsmb/imcsmb_pci.c.

-
-
-

-

As mentioned above, firmware might use the iMC-SMBs to read DIMM - temperatures. The public iMC documentation does not describe any sort of - coordination mechanism to prevent requests from different sources -- such as - the motherboard firmware, a BMC, or the operating system -- from interfering - with each other.

-

-
Therefore, it is highly recommended that developers contact - the motherboard vendor for any board-specific instructions on how to disable - and re-enable DIMM temperature monitoring.
-

DIMM temperature monitoring should be - disabled before returning from - (), - and re-enabled before returning from - (). - The driver includes comments to that effect at the appropriate locations. - The driver has been tested and shown to work, with only that type of - modification, on certain motherboards from Intel. (Unfortunately, those - modifications were based on material covered under a non-disclosure - agreement, and therefore are not included in this driver.) The driver has - also been tested and shown to work as-is on various motherboards from - SuperMicro.

-

The smb(4) driver will connect to the - smbus(4) instances created by - imcsmb. However, since the IMC-SMBs are not - general-purpose SMBus controllers, using smbmsg(8) with - those smb(4) devices is not supported.

-
-
-

-

jedec_dimm(4), smbus(4)

-
-
-

-

The imcsmb driver first appeared in - FreeBSD 12.0.

-
-
-

-

The imcsmb driver was originally written - for Panasas by Joe Kloss. It was substantially - refactored, and this manual page was written, by -
- Ravi Pokala - <rpokala@freebsd.org>

-
-
- - - - - -
March 2, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/inet.4 3.html b/static/freebsd/man4/inet.4 3.html deleted file mode 100644 index e1c7551a..00000000 --- a/static/freebsd/man4/inet.4 3.html +++ /dev/null @@ -1,271 +0,0 @@ - - - - - - -
INET(4)Device Drivers ManualINET(4)
-
-
-

-

inet — Internet - protocol family

-
-
-

-

#include - <sys/types.h> -
- #include <netinet/in.h>

-
-
-

-

The Internet protocol family is a collection of protocols layered - atop the - (IP) transport layer, and utilizing the Internet address - format. The Internet family provides protocol support for the - SOCK_STREAM, SOCK_DGRAM, and - SOCK_RAW socket types; the - SOCK_RAW interface provides access to the IP - protocol.

-
-
-

-

Internet addresses are four byte quantities, stored in network - standard format (on little endian machines, such as the alpha, amd64 and - i386 these are word and byte reversed). The include file - <netinet/in.h> defines this - address as a discriminated union.

-

Sockets bound to the Internet protocol family utilize the - following addressing structure,

-
-
struct sockaddr_in {
-	uint8_t		sin_len;
-	sa_family_t	sin_family;
-	in_port_t	sin_port;
-	struct in_addr	sin_addr;
-	char		sin_zero[8];
-};
-
-

Sockets may be created with the local address - INADDR_ANY to affect “wildcard” - matching on incoming messages. The address in a connect(2) - or sendto(2) call may be given as - INADDR_ANY to mean “this host”. The - distinguished address INADDR_BROADCAST is allowed as - a shorthand for the broadcast address on the primary network if the first - network configured supports broadcast.

-
-
-

-

The Internet protocol family is comprised of the IP network - protocol, Internet Control Message Protocol (ICMP), Internet Group - Management Protocol (IGMP), Transmission Control Protocol (TCP), and User - Datagram Protocol (UDP). TCP is used to support the - SOCK_STREAM abstraction while UDP is used to support - the SOCK_DGRAM abstraction. A raw interface to IP is - available by creating an Internet socket of type - SOCK_RAW. The ICMP message protocol is accessible - from a raw socket.

-

The inet address on an interface consist - of the address itself, the netmask, either broadcast address in case of a - broadcast interface or peers address in case of point-to-point interface. - The following ioctl(2) commands are provided for a - datagram socket in the Internet domain:

-

-
-
-
-
Add address to an interface. The command requires struct - in_aliasreq as argument.
-
-
Delete address from an interface. The command requires - struct ifreq as argument.
-
-
 
-
-
 
-
-
 
-
-
Return address information from interface. The returned value is in - struct ifreq. This way of address information - retrieval is obsoleted, a preferred way is to use - getifaddrs(3) API.
-
-
-
-

-

In addition to the variables supported by the transport protocols - in net.inet (for which the respective manual pages may - be consulted), there are a number of general variables implemented in the - net.inet.ip branch of the sysctl(3) - MIB, which can be also read or modified with sysctl(8). - The following general variables are defined:

-
-
accept_sourceroute
-
Boolean: enable/disable accepting of source-routed IP packets (default - false).
-
allow_net0
-
Boolean: allow forwarding of, and ICMP responses to, packets with - addresses in 0.0.0.0/8.
-
allow_net240
-
Boolean: allow forwarding of, and ICMP responses to, packets with - addresses in 240.0.0.0/4.
-
curfrags
-
Integer: Current number of IPv4 fragments across all reassembly queues in - all VNETs (read-only).
-
forwarding
-
Boolean: enable/disable forwarding of IP packets. Defaults to off.
-
fragpackets
-
Integer: Current number of IPv4 fragment reassembly queue entries for the - VNET (read-only).
-
fragttl
-
Integer: time to live for IPv4 packet fragments in the per-VNET reassemby - queue.
-
loopback_prefixlen
-
Integer: prefix length of the address space reserved for loopback - purposes. The default is 8, meaning that 127.0.0.0/8 is reserved for - loopback, and cannot be sent, received, or forwarded on a non-loopback - interface. Use of other values is experimental.
-
maxfragbucketsize
-
Integer: maximum number of reassembly queues per bucket. Fragmented - packets are hashed to buckets. Each bucket has a list of reassembly - queues. The system must compare the incoming packets to the existing - reassembly queues in the bucket to find a matching reassembly queue. To - preserve system resources, the system limits the number of reassembly - queues allowed in each bucket. This limit is recalculated when the number - of mbuf clusters is changed or when the value of - maxfragpackets changes. This is a per-VNET - limit.
-
maxfragpackets
-
Integer: maximum number of fragmented packets the host will accept and - simultaneously hold in the reassembly queue for a particular VNET. 0 means - that the host will not accept any fragmented packets for that VNET. -1 - means that the host will not apply this limit for that VNET. This limit is - recalculated when the number of mbuf clusters is changed. This is a - per-VNET limit.
-
maxfrags
-
Integer: maximum number of fragments the host will accept and - simultaneously hold across all reassembly queues in all VNETs. If set to - 0, reassembly is disabled. If set to -1, this limit is not applied. This - limit is recalculated when the number of mbuf clusters is changed. This is - a global limit.
-
maxfragsperpacket
-
Integer: maximum number of fragments the host will accept and hold in the - reassembly queue for a packet. 0 means that the host will not accept any - fragmented packets for the VNET. This is a per-VNET limit.
-
mcast
-
Variables under the net.inet.ip.mcast node are - documented in ip(4).
-
no_same_prefix
-
Boolean: Refuse to create same prefixes on different interfaces. This is a - per-VNET value.
-
portrange
-
Variables under the net.inet.ip.portrange node - control port ranges used by transport protocols; see - ip(4) for details.
-
process_options
-
Integer: control IP options processing. By setting this variable to 0, all - IP options in the incoming packets will be ignored, and the packets will - be passed unmodified. By setting to 1, IP options in the incoming packets - will be processed accordingly. By setting to 2, an ICMP “prohibited - by filter” message will be sent back in response to incoming - packets with IP options. Default is 1. This sysctl(8) - variable affects packets destined for a local host as well as packets - forwarded to some other host.
-
random_id
-
Boolean: control IP IDs generation behavior. Setting this - sysctl(8) to 1 causes the ID field in - - IP datagrams (or all IP datagrams, if rfc6864 is - disabled) to be randomized instead of incremented by 1 with each packet - generated. This closes a minor information leak which allows remote - observers to determine the rate of packet generation on the machine by - watching the counter. At the same time, on high-speed links, it can - decrease the ID reuse cycle greatly. Default is 0 (sequential IP IDs). - IPv6 flow IDs and fragment IDs are always random.
-
random_id_collisions
-
Integer: count of IP ID collisions (read-only, per-VNET).
-
random_id_period
-
Integer: size of the IP ID array, which is the number of previous packets - for which the IDs are recorded. The number must be between 512 and 32768 - inclusive. This is a per-VNET value.
-
random_id_total
-
Integer: count of IP IDs created (read-only, per-VNET).
-
reass_hashsize
-
Number of hash slots in the IPv4 reassembly queue (loader tunable).
-
redirect
-
Boolean: enable/disable sending of ICMP redirects in response to IP - packets for which a better, and for the sender directly reachable, route - and next hop is known. Defaults to on.
-
rfc1122_strong_es
-
Boolean: in non-forwarding mode (forwarding is disabled) partially - implement the Strong End System model per RFC1122. If a packet with - destination address that is local arrives on a different interface than - the interface the address belongs to, the packet would be silently - dropped. Enabling this option may break certain setups, e.g. having an - alias address(es) on loopback that are expected to be reachable by outside - traffic. Enabling some other network features, e.g. - carp(4) or destination address rewriting - pfil(4) filters may override and bypass this check. - Disabled by default.
-
rfc6864
-
Boolean: control IP IDs generation behaviour. True value enables RFC6864 - support, which specifies that IP ID field of - - datagrams can be set to any value. The FreeBSD - implementation sets it to zero. Enabled by default.
-
source_address_validation
-
Boolean: perform source address validation for packets destined for the - local host. Consider this as following Section 3.2 of RFC3704/BCP84, where - we treat local host as our own infrastructure. Forwarded packets are - unaffected by this and it should not be considered an anti-spoof feature - for a router. Enabled by default.
-
sourceroute
-
Boolean: enable/disable forwarding of source-routed IP packets (default - false).
-
ttl
-
Integer: default time-to-live (“TTL”) to use for outgoing IP - packets.
-
-
-
-
-

-

ioctl(2), socket(2), - getifaddrs(3), sysctl(3), - icmp(4), intro(4), - ip(4), ipfirewall(4), - route(4), tcp(4), - udp(4), sysctl(8), - pfil(9)

-

An Introductory 4.3 BSD - Interprocess Communication Tutorial, PS1, - 7.

-

An Advanced 4.3 BSD - Interprocess Communication Tutorial, PS1, - 8.

-
-
-

-

The inet protocol interface appeared in - 4.2BSD. The “protocol cloning” code - appeared in FreeBSD 2.1.

-
-
-

-

The Internet protocol support is subject to change as the Internet - protocols develop. Users should not depend on details of the current - implementation, but rather the services exported.

-
-
- - - - - -
December 31, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/inet6.4 3.html b/static/freebsd/man4/inet6.4 3.html deleted file mode 100644 index f9bf58a0..00000000 --- a/static/freebsd/man4/inet6.4 3.html +++ /dev/null @@ -1,301 +0,0 @@ - - - - - - -
INET6(4)Device Drivers ManualINET6(4)
-
-
-

-

inet6 — Internet - protocol version 6 family

-
-
-

-

#include - <sys/types.h> -
- #include <netinet/in.h>

-
-
-

-

The inet6 family is an updated version of - inet(4) family. While inet(4) implements - Internet Protocol version 4, inet6 implements - Internet Protocol version 6.

-

inet6 is a collection of - protocols layered atop the - (IPv6) transport layer, and utilizing the IPv6 address - format. The inet6 family provides protocol support - for the SOCK_STREAM, - SOCK_DGRAM, and SOCK_RAW - socket types; the SOCK_RAW interface provides access - to the IPv6 protocol.

-
-
-

-

IPv6 addresses are 16 byte quantities, stored in network standard - byteorder. The include file - <netinet/in.h> defines this - address as a discriminated union.

-

Sockets bound to the inet6 family utilize - the following addressing structure:

-
-
struct sockaddr_in6 {
-	uint8_t		sin6_len;
-	sa_family_t	sin6_family;
-	in_port_t	sin6_port;
-	uint32_t	sin6_flowinfo;
-	struct in6_addr	sin6_addr;
-	uint32_t	sin6_scope_id;
-};
-
-

Sockets may be created with the local address - “::” (which is equal to IPv6 address - 0:0:0:0:0:0:0:0) to effect “wildcard” - matching on incoming messages.

-

The IPv6 specification defines scoped addresses, like link-local - or site-local addresses. A scoped address is ambiguous to the kernel, if it - is specified without a scope identifier. To manipulate scoped addresses - properly from the userland, programs must use the advanced API defined in - RFC2292. A compact description of the advanced API is available in - ip6(4). If a scoped address is specified without an - explicit scope, the kernel may raise an error. Note that scoped addresses - are not for daily use at this moment, both from a specification and an - implementation point of view.

-

The KAME implementation supports an extended numeric IPv6 address - notation for link-local addresses, like - “fe80::1%de0” to specify - “fe80::1 on de0 - interface”. This notation is supported by - getaddrinfo(3) and getnameinfo(3). Some - of normal userland programs, such as telnet(1) or - ftp(1), are able to use this notation. With special - programs like ping(8), you can specify the outgoing - interface by an extra command line option to disambiguate scoped - addresses.

-

Scoped addresses are handled specially in the kernel. In kernel - structures like routing tables or interface structures, a scoped address - will have its interface index embedded into the address. Therefore, the - address in some kernel structures is not the same as that on the wire. The - embedded index will become visible through a - PF_ROUTE socket, kernel memory accesses via - kvm(3) and on some other occasions. HOWEVER, users should - never use the embedded form. For details please consult - IMPLEMENTATION supplied with KAME kit.

-
-
-

-

The inet6 family is comprised of the IPv6 - network protocol, Internet Control Message Protocol version 6 (ICMPv6), - Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). TCP - is used to support the SOCK_STREAM abstraction while - UDP is used to support the SOCK_DGRAM abstraction. - Note that TCP and UDP are common to inet(4) and - inet6. A raw interface to IPv6 is available by - creating an Internet socket of type SOCK_RAW. The - ICMPv6 message protocol is accessible from a raw socket.

-
-

-

A number of variables are implemented in the - net.inet6 branch of the sysctl(3) - MIB. In addition to the variables supported by the transport protocols (for - which the respective manual pages may be consulted), the following general - variables are defined:

-
-
-
(ip6.forwarding) Boolean: enable/disable forwarding of IPv6 packets. Also, - identify if the node is acting as a router. Defaults to off.
-
-
(ip6.redirect) Boolean: enable/disable sending of ICMPv6 redirects in - response to unforwardable IPv6 packets. This option is ignored unless the - node is routing IPv6 packets, and should normally be enabled on all - systems. Defaults to on.
-
-
(ip6.hlim) Integer: default hop limit value to use for outgoing IPv6 - packets. This value applies to all the transport protocols on top of IPv6. - There are APIs to override the value.
-
-
(ip6.maxfrags) Integer: maximum number of fragments the host will accept - and simultaneously hold across all reassembly queues in all VNETs. If set - to 0, fragment reassembly is disabled. If set to -1, this limit is not - applied. This limit is recalculated when the number of mbuf clusters is - changed. This is a global limit.
-
-
(ip6.maxfragpackets) Integer: maximum number of fragmented packets the - node will accept and simultaneously hold in the reassembly queue for a - particular VNET. 0 means that the node will not accept any fragmented - packets for that VNET. -1 means that the node will not apply this limit - for that VNET. This limit is recalculated when the number of mbuf clusters - is changed. This is a per-VNET limit.
-
-
(ip6.maxfragbucketsize) Integer: maximum number of reassembly queues per - bucket. Fragmented packets are hashed to buckets. Each bucket has a list - of reassembly queues. The system must compare the incoming packets to the - existing reassembly queues in the bucket to find a matching reassembly - queue. To preserve system resources, the system limits the number of - reassembly queues allowed in each bucket. This limit is recalculated when - the number of mbuf clusters is changed or when the value of - ip6.maxfragpackets changes. This is a per-VNET - limit.
-
-
(ip6.maxfragsperpacket) Integer: maximum number of fragments the host will - accept and hold in the ressembly queue for a packet. This is a per-VNET - limit.
-
-
(ip6.accept_rtadv) Boolean: the default value of a per-interface flag to - enable/disable receiving of ICMPv6 router advertisement packets, and - autoconfiguration of address prefixes and default routers. The node must - be a host (not a router) for the option to be meaningful. Defaults to - off.
-
-
(ip6.auto_linklocal) Boolean: the default value of a per-interface flag to - enable/disable performing automatic link-local address configuration. - Defaults to on.
-
-
(ip6.log_interval) Integer: default interval between IPv6 packet - forwarding engine log output (in seconds).
-
-
(ip6.hdrnestlimit) Integer: default number of the maximum IPv6 extension - headers permitted on incoming IPv6 packets. If set to 0, the node will - accept as many extension headers as possible.
-
-
(ip6.dad_count) Integer: default number of IPv6 DAD (duplicated address - detection) probe packets. The packets will be generated when IPv6 - interface addresses are configured.
-
-
(ip6.grand_count) Integer: default number of IPv6 GRAND (gratuitous - neighbor discovery) unsolicited NA packets. The packets will be generated - when IPv6 interface addresses are configured or when there are changes to - link-layer interface addresses.
-
-
(ip6.auto_flowlabel) Boolean: enable/disable automatic filling of IPv6 - flowlabel field, for outstanding connected transport protocol packets. The - field might be used by intermediate routers to identify packet flows. - Defaults to on.
-
-
(ip6.defmcasthlim) Integer: default hop limit value for an IPv6 multicast - packet sourced by the node. This value applies to all the transport - protocols on top of IPv6. There are APIs to override the value as - documented in ip6(4).
-
-
(ip6.gifhlim) Integer: default maximum hop limit value for an IPv6 packet - generated by gif(4) tunnel interface.
-
-
(ip6.kame_version) String: identifies the version of KAME IPv6 stack - implemented in the kernel.
-
-
(ip6.use_deprecated) Boolean: enable/disable use of deprecated address, - specified in RFC2462 5.5.4. Defaults to on.
-
-
(ip6.rr_prune) Integer: default interval between IPv6 router renumbering - prefix babysitting, in seconds.
-
-
(ip6.v6only) Boolean: enable/disable the prohibited use of IPv4 mapped - address on AF_INET6 sockets. Defaults to on.
-
ip6.log_cannot_forward
-
Boolean: log packets that can't be forwarded because of unspecified source - address or destination address beyond the scope of the source address as - described in RFC4443. Enabled by default.
-
ip6.source_address_validation
-
Boolean: perform source address validation for packets destined for the - local host. Consider this as following Section 3.2 of RFC3704/BCP84, where - we treat local host as our own infrastructure. This has no effect on - packets to be forwarded, so don't consider it as anti-spoof feature for a - router. Enabled by default.
-
-
-
-

-

By default, FreeBSD does not route IPv4 - traffic to AF_INET6 sockets. The default behavior - intentionally violates RFC2553 for security reasons. Listen to two sockets - if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed - with certain per-socket/per-node configuration, however, it is not - recommended to do so. Consult ip6(4) for details.

-

The behavior of AF_INET6 TCP/UDP socket is - documented in RFC2553. Basically, it says this:

-
    -
  • A specific bind on an AF_INET6 socket - (bind(2) with an address specified) should accept IPv6 - traffic to that address only.
    • -
  • If you perform a wildcard bind on an AF_INET6 - socket (bind(2) to IPv6 address - ::), and there is no wildcard bind - AF_INET socket on that TCP/UDP port, IPv6 traffic - as well as IPv4 traffic should be routed to that - AF_INET6 socket. IPv4 traffic should be seen as if - it came from an IPv6 address like ::ffff:10.1.1.1. - This is called an IPv4 mapped address.
    • -
  • If there are both a wildcard bind AF_INET socket - and a wildcard bind AF_INET6 socket on one TCP/UDP - port, they should behave separately. IPv4 traffic should be routed to the - AF_INET socket and IPv6 should be routed to the - AF_INET6 socket.
    • -
-

However, RFC2553 does not define the ordering constraint between - calls to bind(2), nor how IPv4 TCP/UDP port numbers and - IPv6 TCP/UDP port numbers relate to each other (should they be integrated or - separated). Implemented behavior is very different from kernel to kernel. - Therefore, it is unwise to rely too much upon the behavior of - AF_INET6 wildcard bind sockets. It is recommended to - listen to two sockets, one for AF_INET and another - for AF_INET6, when you would like to accept both - IPv4 and IPv6 traffic.

-

It should also be noted that malicious parties can take advantage - of the complexity presented above, and are able to bypass access control, if - the target node routes IPv4 traffic to AF_INET6 - socket. Users are advised to take care handling connections from IPv4 mapped - address to AF_INET6 sockets.

-
-
-
-

-

ioctl(2), socket(2), - sysctl(3), icmp6(4), - intro(4), ip6(4), - tcp(4), udp(4)

-

A. Conta, - S. Deering, and M. Gupta, - Internet Control Message Protocol (ICMPv6) for the - Internet Protocol Version 6 (IPv6) Specification, - RFC 4443, March - 2006.

-
-
-

-

Tatsuya Jinmei and - Atsushi Onoe, An Extension of - Format for IPv6 Scoped Addresses, internet - draft, - draft-ietf-ipngwg-scopedaddr-format-02.txt, - June 2000, work in progress - material.

-
-
-

-

The inet6 protocol interfaces are defined - in RFC2553 and RFC2292. The implementation described herein appeared in the - WIDE/KAME project.

-
-
-

-

The IPv6 support is subject to change as the Internet protocols - develop. Users should not depend on details of the current implementation, - but rather the services exported.

-

Users are suggested to implement “version - independent” code as much as possible, as you will need to support - both inet(4) and inet6.

-
-
- - - - - -
January 31, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/intpm.4 4.html b/static/freebsd/man4/intpm.4 4.html deleted file mode 100644 index 5e04b3c8..00000000 --- a/static/freebsd/man4/intpm.4 4.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
INTPM(4)Device Drivers ManualINTPM(4)
-
-
-

-

intpm — Intel - PIIX4 Power Management controller driver

-
-
-

-

device pci -
- device smbus -
- device smb -
- device intpm

-
-
-

-

The intpm driver provides access to Intel - PIIX4 compatible Power Management controllers. Currently, only - smbus(4) controller function is implemented.

-
-
-

-

The intpm driver supports the following - chipsets:

-

-
    -
  • Intel 82371AB/82443MX
    • -
  • ATI IXP400
    • -
  • AMD SB600/7x0/8x0/9x0 southbridges
    • -
  • AMD Axx/Hudson/Bolton FCHs
    • -
  • AMD FCH integrated into Family 15h Models 60h-6Fh, 70h-7Fh Processors
    • -
  • AMD FCH integrated into Family 16h Models 00h-0Fh, 30h-3Fh Processors
    • -
-
-
-

-

amdpm(4), amdsmb(4), - ichsmb(4), smb(4), - smbus(4)

-
-
-

-

The intpm driver first appeared in - FreeBSD 3.4.

-
-
-

-

This manual page was written by Takanori - Watanabe - <takawata@shidahara1.planet.sci.kobe-u.ac.jp>.

-
-
-

-

This device requires IRQ 9 exclusively. To use this, you should - enable ACPI function in BIOS configuration, or PnP mechanism assigns - conflicted IRQ for PnP ISA card. And do not use IRQ 9 for Non-PnP ISA - cards.

-
-
- - - - - -
September 22, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/intro.4 3.html b/static/freebsd/man4/intro.4 3.html deleted file mode 100644 index d9e2e6a9..00000000 --- a/static/freebsd/man4/intro.4 3.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - -
INTRO(4)Device Drivers ManualINTRO(4)
-
-
-

-

intro — - introduction to devices and device drivers

-
-
-

-

This section contains information related to devices, device - drivers and miscellaneous hardware.

-
-

-

Device is a term used mostly for hardware-related stuff that - belongs to the system, like disks, printers, or a graphics display with its - keyboard. There are also so-called - - where a device driver emulates the behaviour of a device in software without - any particular underlying hardware. A typical example for the latter class - is /dev/mem, a mechanism whereby the physical memory - can be accessed using file access semantics.

-

The device abstraction generally provides a common set of system - calls, which are dispatched to the corresponding device driver by the upper - layers of the kernel. The set of system calls available for devices is - chosen from open(2), close(2), - read(2), write(2), - ioctl(2), select(2), and - mmap(2). Not all drivers implement all system calls; for - example, calling mmap(2) on a keyboard device is not - likely to be useful.

-

Aspects of the device abstraction have changed significantly in - FreeBSD over the past two decades. The section - Historical Notes describes some - of the more important differences.

-
-
-

-

Most of the devices in FreeBSD are - accessed through - , sometimes also called - . They are located within instances of the - devfs(4) filesystem, which is conventionally mounted on - the directory /dev in the file system hierarchy (see - also hier(7)).

-

The devfs(4) filesystem creates or removes - device nodes automatically according to the physical hardware recognized as - present at any given time. For pseudo-devices, device nodes may be created - and removed dynamically as required, depending on the nature of the - device.

-

Access restrictions to device nodes are usually subject to the - regular file permissions of the device node entry, instead of being enforced - directly by the drivers in the kernel. But since device nodes are not stored - persistently between reboots, those file permissions are set at boot time - from rules specified in devfs.conf(5), or dynamically - according to rules defined in devfs.rules(5) or set using - the devfs(8) command. In the latter case, different rules - may be used to make different sets of devices visible within different - instances of the devfs(4) filesystem, which may be used, - for example, to prevent jailed subsystems from accessing unsafe devices. - Manual changes to device node permissions may still be made, but will not - persist.

-
-
-

-

Drivers for network devices do not use device nodes in order to be - accessed. Their selection is based on other decisions inside the kernel, and - instead of calling open(2), use of a network device is - generally introduced by using the system call - socket(2).

-
-
-

-

For each kernel, there is a configuration file that is used as a - base to select the facilities and drivers for that kernel, and to tune - several options. See config(8) for a detailed description - of the files involved. The individual manual pages in this section provide a - sample line for the configuration file in their synopsis portions. See also - the files /usr/src/sys/conf/NOTES and - /usr/src/sys/${ARCH}/conf/NOTES.

-

Drivers need not be statically compiled into the kernel; they may - also be loaded as modules, in which case any device nodes they provide will - appear only after the module is loaded (and has attached to suitable - hardware, if applicable).

-
-
-

-

Prior to FreeBSD 6.0, device nodes could - be created in the traditional way as persistent entries in the file system. - While such entries can still be created, they no longer function to access - devices.

-

Prior to FreeBSD 5.0, devices - for disk and tape drives existed in two variants, known as - and - - devices, or to use better terms, buffered and unbuffered (raw) devices. The - traditional names are reflected by the letters - “b” and - “c” as the file type identification in - the output of “ls -l”. Raw devices - were traditionally named with a prefix of - “r”, for example - /dev/rda0 would denote the raw version of the disk - whose buffered device was /dev/da0. - ; all disk devices are now “raw” in the - traditional sense, even though they are not given - “r” prefixes, and - “buffered” devices no longer exist at all.

-

Buffered devices were accessed through a buffer - cache maintained by the operating system; historically this was the system's - primary disk cache, but in FreeBSD this was rendered - obsolete by the introduction of unified virtual memory management. Buffered - devices could be read or written at any byte position, with the buffer - mechanism handling the reading and writing of disk blocks. In contrast, raw - disk devices can be read or written only at positions and lengths that are - multiples of the underlying device block size, and - write(2) calls are - , - not returning to the caller until the data has been handed off to the - device.

-
-
-
-

-

close(2), ioctl(2), - mmap(2), open(2), - read(2), select(2), - socket(2), write(2), - devfs(4), hier(7), - config(8)

-
-
-

-

This manual page first appeared in FreeBSD - 2.1.

-
-
-

-

This man page has been rewritten by Andrew - Gierth from an earlier version written by - Jörg Wunsch with initial input by - David E. O'Brien.

-
-
- - - - - -
April 3, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/io.4 3.html b/static/freebsd/man4/io.4 3.html deleted file mode 100644 index d26e4c65..00000000 --- a/static/freebsd/man4/io.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
IO(4)Device Drivers ManualIO(4)
-
-
-

-

io — I/O privilege - file

-
-
-

-

device io

-

-
- #include <sys/types.h> -
- #include <sys/ioctl.h> -
- #include <dev/io/iodev.h> -
- #include <machine/iodev.h>

-
-
struct iodev_pio_req {
-	u_int access;
-	u_int port;
-	u_int width;
-	u_int val;
-};
-
-
-
-

-

The special file /dev/io is a controlled - security hole that allows a process to gain I/O privileges (which are - normally reserved for kernel-internal code). This can be useful in order to - write userland programs that handle some hardware directly.

-

The usual operations on the device are to open it via the - open(2) interface and to send I/O requests to the file - descriptor using the ioctl(2) syscall.

-

The ioctl(2) requests available for - /dev/io are mostly platform dependent, but there are - also some in common between all of them. The - IODEV_PIO is used by all the architectures in order - to request that an I/O operation be performed. It takes a 'struct - iodev_pio_req' argument that must be previously setup.

-

The access member specifies the type of - operation requested. It may be:

-
-
-
The operation is an "in" type. A value will be read from the - specified port (retrieved from the port member) and - the result will be stored in the val member.
-
-
The operation is a "out" type. The value will be fetched from - the val member and will be written out to the - specified port (defined as the port member).
-
-

Finally, the width member specifies the size - of the operand to be read/written, expressed in bytes.

-

In addition to any file access permissions on - /dev/io, the kernel enforces that only the - super-user may open this device.

-
-
-

-

The /dev/io interface used to be very i386 - specific and worked differently. The initial implementation simply raised - the - of the current thread when open(2) was called on the - device. This behaviour is retained in the current implementation as legacy - support for both i386 and amd64 architectures.

-
-
-

-

close(2), i386_get_ioperm(2), - i386_set_ioperm(2), ioctl(2), - open(2), mem(4)

-
-
-

-

The io file appeared in - FreeBSD 1.0.

-
-
- - - - - -
June 1, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/ioat.4 4.html b/static/freebsd/man4/ioat.4 4.html deleted file mode 100644 index dc69c907..00000000 --- a/static/freebsd/man4/ioat.4 4.html +++ /dev/null @@ -1,297 +0,0 @@ - - - - - - -
IOAT(4)Device Drivers Manual (amd64)IOAT(4)
-
-
-

-

I/OAT — Intel I/O - Acceleration Technology

-
-
-

-

To compile this driver into your kernel, place the following line - in your kernel configuration file:

-
device ioat
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
ioat_load="YES"
-
-

In loader.conf(5):

-

-
- hw.ioat.force_legacy_interrupts=0

-

In loader.conf(5) or - sysctl.conf(5):

-

-
- hw.ioat.enable_ioat_test=0 -
- hw.ioat.debug_level=0 (only critical errors; maximum - of 3)

-

-
- typedef void -
- (*bus_dmaengine_callback_t)(void - *arg, int - error);

-

-
- bus_dmaengine_t -
- ioat_get_dmaengine(uint32_t - channel_index);

-

void -
- ioat_put_dmaengine(bus_dmaengine_t - dmaengine);

-

int -
- ioat_get_hwversion(bus_dmaengine_t - dmaengine);

-

size_t -
- ioat_get_max_io_size(bus_dmaengine_t - dmaengine);

-

int -
- ioat_set_interrupt_coalesce(bus_dmaengine_t - dmaengine, uint16_t - delay);

-

uint16_t -
- ioat_get_max_coalesce_period(bus_dmaengine_t - dmaengine);

-

void -
- ioat_acquire(bus_dmaengine_t - dmaengine);

-

int -
- ioat_acquire_reserve(bus_dmaengine_t - dmaengine, uint32_t - n, int mflags);

-

void -
- ioat_release(bus_dmaengine_t - dmaengine);

-

struct bus_dmadesc * -
- ioat_copy(bus_dmaengine_t - dmaengine, bus_addr_t dst, - bus_addr_t src, bus_size_t len, - bus_dmaengine_callback_t callback_fn, - void *callback_arg, uint32_t - flags);

-

struct bus_dmadesc * -
- ioat_copy_8k_aligned(bus_dmaengine_t - dmaengine, bus_addr_t dst1, - bus_addr_t dst2, bus_addr_t - src1, bus_addr_t src2, - bus_dmaengine_callback_t callback_fn, - void *callback_arg, uint32_t - flags);

-

struct bus_dmadesc * -
- ioat_copy_crc(bus_dmaengine_t - dmaengine, bus_addr_t dst, - bus_addr_t src, bus_size_t len, - uint32_t *initialseed, bus_addr_t - crcptr, bus_dmaengine_callback_t callback_fn, - void *callback_arg, uint32_t - flags);

-

struct bus_dmadesc * -
- ioat_crc(bus_dmaengine_t - dmaengine, bus_addr_t src, - bus_size_t len, uint32_t - *initialseed, bus_addr_t crcptr, - bus_dmaengine_callback_t callback_fn, - void *callback_arg, uint32_t - flags);

-

struct bus_dmadesc * -
- ioat_blockfill(bus_dmaengine_t - dmaengine, bus_addr_t dst, - uint64_t fillpattern, bus_size_t - len, bus_dmaengine_callback_t callback_fn, - void *callback_arg, uint32_t - flags);

-

struct bus_dmadesc * -
- ioat_null(bus_dmaengine_t - dmaengine, bus_dmaengine_callback_t callback_fn, - void *callback_arg, uint32_t - flags);

-
-
-

-

The I/OAT driver provides a kernel API to - a variety of DMA engines on some Intel server platforms.

-

There is a number of DMA channels per CPU package. (Typically 4 or - 8.) Each may be used independently. Operations on a single channel proceed - sequentially.

-

Blockfill operations can be used to write a 64-bit pattern to - memory.

-

Copy operations can be used to offload memory copies to the DMA - engines.

-

Null operations do nothing, but may be used to test the interrupt - and callback mechanism.

-

All operations can optionally trigger an interrupt at completion - with the DMA_INT_EN flag. For example, a user might - submit multiple operations to the same channel and only enable an interrupt - and callback for the last operation.

-

The hardware can delay and - coalesce interrupts on a given channel for a configurable period of time, in - microseconds. This may be desired to reduce the processing and interrupt - overhead per descriptor, especially for workflows consisting of many small - operations. Software can control this on a per-channel basis with the - () - API. The - () - API can be used to determine the maximum coalescing period supported by the - hardware, in microseconds. Current platforms support up to a 16.383 - millisecond coalescing period. Optimal configuration will vary by workflow - and desired operation latency.

-

All operations are safe to use in a non-blocking context with the - DMA_NO_WAIT flag. (Of course, allocations may fail and - operations requested with DMA_NO_WAIT may return - NULL.)

-

Operations that depend on the result of prior operations should - use DMA_FENCE. For example, such a scenario can happen - when two related DMA operations are queued. First, a DMA copy to one - location (A), followed directly by a DMA copy from A to B. In this scenario, - some classes of I/OAT hardware may prefetch A for the second operation - before it is written by the first operation. To avoid reading a stale value - in sequences of dependent operations, use - DMA_FENCE.

-

All operations, as well as - (), - can return NULL in special circumstances. For example, if the - I/OAT driver is being unloaded, or the administrator - has induced a hardware reset, or a usage error has resulted in a hardware - error state that needs to be recovered from.

-

It is invalid to attempt to submit new DMA operations in a - bus_dmaengine_callback_t context.

-

The CRC operations have three distinct modes. The default mode is - to accumulate. By accumulating over multiple descriptors, a user may gather - a CRC over several chunks of memory and only write out the result once.

-

The DMA_CRC_STORE flag causes - the operation to emit the CRC32C result. If - DMA_CRC_INLINE is set, the result is written inline - with the destination data (or source in - () - mode). If DMA_CRC_INLINE is not set, the result is - written to the provided crcptr.

-

Similarly, the DMA_CRC_TEST flag causes the - operation to compare the CRC32C result to an existing checksum. If - DMA_CRC_INLINE is set, the result is compared against - the inline four bytes trailing the source data. If it is not set, the result - is compared against the value pointed to by - crcptr.

-

() - calculates a CRC32C while copying data. ioat_crc() - only computes a CRC32C of some data. If the - initialseed argument to either routine is non-NULL, - the CRC32C engine is initialized with the value it points to.

-
-
-

-

A typical user will lookup the DMA engine object for a given - channel with ioat_get_dmaengine(). When the user - wants to offload a copy, they will first - ioat_acquire() the - bus_dmaengine_t object for exclusive access to enqueue - operations on that channel. Optionally, the user can reserve space by using - () - instead. If ioat_acquire_reserve() succeeds, there - is guaranteed to be room for N new operations in the - internal ring buffer.

-

Then, they will submit one or more operations - using - (), - (), - (), - ioat_copy_crc(), ioat_crc(), - or - (). - After queuing one or more individual DMA operations, they will - ioat_release() the - bus_dmaengine_t to drop their exclusive access to the - channel. The routine they provided for the callback_fn - argument will be invoked with the provided - callback_arg when the operation is complete. When they - are finished with the bus_dmaengine_t, the user should - ().

-

Users MUST NOT block between - () - and - (). - Users SHOULD NOT hold bus_dmaengine_t references for a - very long time to enable fault recovery and kernel module unload.

-

For an example of usage, see - src/sys/dev/ioat/ioat_test.c.

-
-
-

-
-
/dev/ioat_test
-
test device for ioatcontrol(8)
-
-
-
-

-

ioatcontrol(8)

-
-
-

-

The I/OAT driver first appeared in - FreeBSD 11.0.

-
-
-

-

The I/OAT driver was developed by - Jim Harris - <jimharris@FreeBSD.org>, -
- Carl Delsey - <carl.r.delsey@intel.com>, - and -
- Conrad Meyer - <cem@FreeBSD.org>. - This manual page was written by -
- Conrad Meyer - <cem@FreeBSD.org>.

-
-
-

-

Copy operation takes bus addresses as parameters, not virtual - addresses.

-

Buffers for individual copy operations must be physically - contiguous.

-

Copies larger than max transfer size (1MB, but may vary by - hardware) are not supported. Future versions will likely support this by - breaking up the transfer into smaller sizes.

-
-
-

-

The I/OAT driver only supports blockfill, - copy, and null operations at this time. The driver does not yet support - advanced DMA modes, such as XOR, that some I/OAT devices support.

-
-
- - - - - -
May 3, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/ip.4 3.html b/static/freebsd/man4/ip.4 3.html deleted file mode 100644 index 29442b8d..00000000 --- a/static/freebsd/man4/ip.4 3.html +++ /dev/null @@ -1,581 +0,0 @@ - - - - - - -
IP(4)Device Drivers ManualIP(4)
-
-
-

-

ip — Internet - Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h>

-

int -
- socket(AF_INET, - SOCK_RAW, - proto);

-
-
-

-

IP is the transport layer protocol used by the Internet protocol - family. Options may be set at the IP level when using higher-level protocols - that are based on IP (such as TCP and UDP). It may also be accessed through - a “raw socket” when developing new protocols, or - special-purpose applications.

-

There are several IP-level setsockopt(2) and - getsockopt(2) options. IP_OPTIONS - may be used to provide IP options to be transmitted in the IP header of each - outgoing packet or to examine the header options on incoming packets. IP - options may be used with any socket type in the Internet family. The format - of IP options to be sent is that specified by the IP protocol specification - (RFC-791), with one exception: the list of addresses for Source Route - options must include the first-hop gateway at the beginning of the list of - gateways. The first-hop gateway address will be extracted from the option - list and the size adjusted accordingly before use. To disable previously - specified options, use a zero-length buffer:

-
-
setsockopt(s, IPPROTO_IP, IP_OPTIONS, NULL, 0);
-
-

IP_TOS may be used to set the differential - service codepoint (DSCP) and the explicit congestion notification (ECN) - codepoint. Setting the ECN codepoint - the two least significant bits - on a - socket using a transport protocol implementing ECN has no effect.

-

IP_TTL configures the time-to-live (TTL) - field in the IP header for SOCK_STREAM, - SOCK_DGRAM, and certain types of - SOCK_RAW sockets. For example,

-
-
int tos = IPTOS_DSCP_EF;       /* see <netinet/ip.h> */
-setsockopt(s, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
-
-int ttl = 60;                   /* max = 255 */
-setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
-
-

IP_IPSEC_POLICY controls IPSec policy for - sockets. For example,

-
-
const char *policy = "in ipsec ah/transport//require";
-char *buf = ipsec_set_policy(policy, strlen(policy));
-setsockopt(s, IPPROTO_IP, IP_IPSEC_POLICY, buf, ipsec_get_policylen(buf));
-
-

IP_MINTTL may be used to set the minimum - acceptable TTL a packet must have when received on a socket. All packets - with a lower TTL are silently dropped. This option is only really useful - when set to 255, preventing packets from outside the directly connected - networks reaching local listeners on sockets.

-

IP_DONTFRAG may be used to set the Don't - Fragment flag on IP packets. Currently this option is respected only on - udp(4) and raw ip sockets, unless - the IP_HDRINCL option has been set. On - tcp(4) sockets, the Don't Fragment flag is controlled by - the Path MTU Discovery option. Sending a packet larger than the MTU size of - the egress interface, determined by the destination address, returns an - EMSGSIZE error.

-

If the IP_ORIGDSTADDR option is enabled on - a SOCK_DGRAM socket, the - recvmsg(2) call will return the destination IP address and - destination port for a UDP datagram. The msg_control - field in the msghdr structure points to a buffer that - contains a cmsghdr structure followed by the - sockaddr_in structure. The cmsghdr fields have the - following values:

-
-
cmsg_len = CMSG_LEN(sizeof(struct sockaddr_in))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_ORIGDSTADDR
-
-

If the IP_RECVDSTADDR option is enabled on - a SOCK_DGRAM socket, the - recvmsg(2) call will return the destination IP address for - a UDP datagram. The msg_control field in the - msghdr structure points to a buffer that contains a - cmsghdr structure followed by the IP address. The - cmsghdr fields have the following values:

-
-
cmsg_len = CMSG_LEN(sizeof(struct in_addr))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVDSTADDR
-
-

The source address to be used for outgoing UDP datagrams on a - socket can be specified as ancillary data with a type code of - IP_SENDSRCADDR. The msg_control field in the msghdr - structure should point to a buffer that contains a - cmsghdr structure followed by the IP address. The - cmsghdr fields should have the following values:

-
-
cmsg_len = CMSG_LEN(sizeof(struct in_addr))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_SENDSRCADDR
-
-

The socket should be either bound to - INADDR_ANY and a local port, and the address - supplied with IP_SENDSRCADDR shouldn't be - INADDR_ANY, or the socket should be bound to a local - address and the address supplied with IP_SENDSRCADDR - should be INADDR_ANY. In the latter case bound - address is overridden via generic source address selection logic, which - would choose IP address of interface closest to destination.

-

For convenience, IP_SENDSRCADDR is defined - to have the same value as IP_RECVDSTADDR, so the - IP_RECVDSTADDR control message from - recvmsg(2) can be used directly as a control message for - sendmsg(2).

-

If the IP_ONESBCAST option is enabled on a - SOCK_DGRAM or a SOCK_RAW - socket, the destination address of outgoing broadcast datagrams on that - socket will be forced to the undirected broadcast address, - INADDR_BROADCAST, before transmission. This is in - contrast to the default behavior of the system, which is to transmit - undirected broadcasts via the first network interface with the - IFF_BROADCAST flag set.

-

This option allows applications to choose which interface is used - to transmit an undirected broadcast datagram. For example, the following - code would force an undirected broadcast to be transmitted via the interface - configured with the broadcast address 192.168.2.255:

-
-
char msg[512];
-struct sockaddr_in sin;
-int onesbcast = 1;	/* 0 = disable (default), 1 = enable */
-
-setsockopt(s, IPPROTO_IP, IP_ONESBCAST, &onesbcast, sizeof(onesbcast));
-sin.sin_addr.s_addr = inet_addr("192.168.2.255");
-sin.sin_port = htons(1234);
-sendto(s, msg, sizeof(msg), 0, &sin, sizeof(sin));
-
-

It is the application's responsibility to set the - IP_TTL option to an appropriate value in order to - prevent broadcast storms. The application must have sufficient credentials - to set the SO_BROADCAST socket level option, - otherwise the IP_ONESBCAST option has no effect.

-

If the IP_BINDANY option is enabled on a - SOCK_STREAM, SOCK_DGRAM or a - SOCK_RAW socket, one can bind(2) - to any address, even one not bound to any available network interface in the - system. This functionality (in conjunction with special firewall rules) can - be used for implementing a transparent proxy. The - PRIV_NETINET_BINDANY privilege is needed to set this - option.

-

If the IP_RECVTTL option is enabled on a - SOCK_DGRAM socket, the recvmsg(2) - call will return the IP TTL (time to live) field for a UDP datagram. The - msg_control field in the msghdr structure points to a buffer that contains a - cmsghdr structure followed by the TTL. The cmsghdr fields have the following - values:

-
-
cmsg_len = CMSG_LEN(sizeof(u_char))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVTTL
-
-

If the IP_RECVTOS option is enabled on a - SOCK_DGRAM socket, the recvmsg(2) - call will return the IP TOS (type of service) field for a UDP datagram. The - msg_control field in the msghdr structure points to a buffer that contains a - cmsghdr structure followed by the TOS. The cmsghdr fields have the following - values:

-
-
cmsg_len = CMSG_LEN(sizeof(u_char))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVTOS
-
-

If the IP_RECVIF option is enabled on a - SOCK_DGRAM socket, the recvmsg(2) - call returns a struct sockaddr_dl corresponding to the - interface on which the packet was received. The - msg_control field in the msghdr - structure points to a buffer that contains a cmsghdr - structure followed by the struct sockaddr_dl. The - cmsghdr fields have the following values:

-
-
cmsg_len = CMSG_LEN(sizeof(struct sockaddr_dl))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVIF
-
-

IP_PORTRANGE may be used to set the port - range used for selecting a local port number on a socket with an unspecified - (zero) port number. It has the following possible values:

-
-
-
use the default range of values, normally - IPPORT_HIFIRSTAUTO through - IPPORT_HILASTAUTO. This is adjustable through the - sysctl setting: net.inet.ip.portrange.first and - net.inet.ip.portrange.last.
-
-
use a high range of values, normally - IPPORT_HIFIRSTAUTO and - IPPORT_HILASTAUTO. This is adjustable through the - sysctl setting: net.inet.ip.portrange.hifirst and - net.inet.ip.portrange.hilast.
-
-
use a low range of ports, which are normally restricted to privileged - processes on UNIX systems. The range is normally - from IPPORT_RESERVED - 1 down to - IPPORT_RESERVEDSTART in descending order. This is - adjustable through the sysctl setting: - net.inet.ip.portrange.lowfirst and - net.inet.ip.portrange.lowlast.
-
-

The range of privileged ports which only may be opened by - root-owned processes may be modified by the - net.inet.ip.portrange.reservedlow and - net.inet.ip.portrange.reservedhigh sysctl settings. - The values default to the traditional range, 0 through - IPPORT_RESERVED - 1 (0 through 1023), respectively. - Note that these settings do not affect and are not accounted for in the use - or calculation of the other net.inet.ip.portrange - values above. Changing these values departs from - UNIX tradition and has security consequences that - the administrator should carefully evaluate before modifying these - settings.

-

Ports are allocated at random within the specified port range in - order to increase the difficulty of random spoofing attacks. In scenarios - such as benchmarking, this behavior may be undesirable. In these cases, - net.inet.ip.portrange.randomized can be used to toggle - randomization off.

-
-

-

IP multicasting is supported only on - AF_INET sockets of type - SOCK_DGRAM and SOCK_RAW, and - only on networks where the interface driver supports multicasting.

-

The IP_MULTICAST_TTL option changes the - time-to-live (TTL) for outgoing multicast datagrams in order to control the - scope of the multicasts:

-
-
u_char ttl;	/* range: 0 to 255, default = 1 */
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
-
-

Datagrams with a TTL of 1 are not forwarded beyond the local - network. Multicast datagrams with a TTL of 0 will not be transmitted on any - network, but may be delivered locally if the sending host belongs to the - destination group and if multicast loopback has not been disabled on the - sending socket (see below). Multicast datagrams with TTL greater than 1 may - be forwarded to other networks if a multicast router is attached to the - local network.

-

For hosts with multiple interfaces, where an interface has not - been specified for a multicast group membership, each multicast transmission - is sent from the primary network interface. The - IP_MULTICAST_IF option overrides the default for - subsequent transmissions from a given socket:

-
-
struct in_addr addr;
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
-
-

where "addr" is the local IP address of the desired - interface or INADDR_ANY to specify the default - interface.

-

To specify an interface by index, an instance of - ip_mreqn may be passed instead. The - imr_ifindex member should be set to the index of the - desired interface, or 0 to specify the default interface. The kernel - differentiates between these two structures by their size.

-

The use of IP_MULTICAST_IF is - not recommended, as multicast memberships are scoped to - each individual interface. It is supported for legacy use only by - applications, such as routing daemons, which expect to be able to transmit - link-local IPv4 multicast datagrams (224.0.0.0/24) on multiple interfaces, - without requesting an individual membership for each interface.

-

An interface's local IP address and multicast capability can be - obtained via the SIOCGIFCONF and - SIOCGIFFLAGS ioctls. Normal applications should not - need to use this option.

-

If a multicast datagram is sent to a group to which the sending - host itself belongs (on the outgoing interface), a copy of the datagram is, - by default, looped back by the IP layer for local delivery. The - IP_MULTICAST_LOOP option gives the sender explicit - control over whether or not subsequent datagrams are looped back:

-
-
u_char loop;	/* 0 = disable, 1 = enable (default) */
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
-
-

This option improves performance for applications that may have no - more than one instance on a single host (such as a routing daemon), by - eliminating the overhead of receiving their own transmissions. It should - generally not be used by applications for which there may be more than one - instance on a single host (such as a conferencing program) or for which the - sender does not belong to the destination group (such as a time querying - program).

-

The sysctl setting net.inet.ip.mcast.loop - controls the default setting of the - IP_MULTICAST_LOOP socket option for new sockets.

-

A multicast datagram sent with an initial TTL greater than 1 may - be delivered to the sending host on a different interface from that on which - it was sent, if the host belongs to the destination group on that other - interface. The loopback control option has no effect on such delivery.

-

A host must become a member of a multicast group before it can - receive datagrams sent to the group. To join a multicast group, use the - IP_ADD_MEMBERSHIP option:

-
-
struct ip_mreqn mreqn;
-setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreqn, sizeof(mreqn));
-
-

where mreqn is the following structure:

-
-
struct ip_mreqn {
-    struct in_addr imr_multiaddr; /* IP multicast address of group */
-    struct in_addr imr_address;   /* local IP address of interface */
-    int            imr_ifindex;   /* interface index */
-}
-
-

imr_ifindex should be set to the index of a - particular multicast-capable interface if the host is multihomed. If - imr_ifindex is non-zero, value of - imr_interface is ignored. Otherwise, if - imr_ifindex is 0, kernel will use IP address from - imr_interface to lookup the interface. Value of - imr_interface may be set to - INADDR_ANY to choose the default interface, although - this is not recommended; this is considered to be the first interface - corresponding to the default route. Otherwise, the first multicast-capable - interface configured in the system will be used.

-

Legacy struct ip_mreq, that lacks - imr_ifindex field is also supported by - IP_ADD_MEMBERSHIP setsockopt. In this case kernel - would behave as if imr_ifindex was set to zero: - imr_interface will be used to lookup interface.

-

Prior to FreeBSD 7.0, if the - imr_interface member is within the network range - 0.0.0.0/8, it is treated as an interface index in - the system interface MIB, as per the RIP Version 2 MIB Extension (RFC-1724). - In versions of FreeBSD since 7.0, this behavior is - no longer supported. Developers should instead use the RFC 3678 multicast - source filter APIs; in particular, - MCAST_JOIN_GROUP.

-

Up to IP_MAX_MEMBERSHIPS memberships may - be added on a single socket. Membership is associated with a single - interface; programs running on multihomed hosts may need to join the same - group on more than one interface.

-

To drop a membership, use:

-
-
struct ip_mreq mreq;
-setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
-
-

where mreq contains the same values as used - to add the membership. Memberships are dropped when the socket is closed or - the process exits.

-

The IGMP protocol uses the primary IP address of the interface as - its identifier for group membership. This is the first IP address configured - on the interface. If this address is removed or changed, the results are - undefined, as the IGMP membership state will then be inconsistent. If - multiple IP aliases are configured on the same interface, they will be - ignored.

-

This shortcoming was addressed in IPv6; MLDv2 requires that the - unique link-local address for an interface is used to identify an MLDv2 - listener.

-
-
-

-

Since FreeBSD 8.0, the use of - Source-Specific Multicast (SSM) is supported. These extensions require an - IGMPv3 multicast router in order to make best use of them. If a legacy - multicast router is present on the link, FreeBSD - will simply downgrade to the version of IGMP spoken by the router, and the - benefits of source filtering on the upstream link will not be present, - although the kernel will continue to squelch transmissions from blocked - sources.

-

Each group membership on a socket now has a filter mode:

-
-
-
Datagrams sent to this group are accepted, unless the source is in a list - of blocked source addresses.
-
-
Datagrams sent to this group are accepted only if the source is in a list - of accepted source addresses.
-
-

Groups joined using the legacy - IP_ADD_MEMBERSHIP option are placed in - exclusive-mode, and are able to request that certain sources are blocked or - allowed. This is known as the - .

-

To block a multicast source on an existing group membership:

-
-
struct ip_mreq_source mreqs;
-setsockopt(s, IPPROTO_IP, IP_BLOCK_SOURCE, &mreqs, sizeof(mreqs));
-
-

where mreqs is the following structure:

-
-
struct ip_mreq_source {
-    struct in_addr imr_multiaddr; /* IP multicast address of group */
-    struct in_addr imr_sourceaddr; /* IP address of source */
-    struct in_addr imr_interface; /* local IP address of interface */
-}
-
-imr_sourceaddr should be set to the address of the source - to be blocked. -

To unblock a multicast source on an existing group:

-
-
struct ip_mreq_source mreqs;
-setsockopt(s, IPPROTO_IP, IP_UNBLOCK_SOURCE, &mreqs, sizeof(mreqs));
-
-

The IP_BLOCK_SOURCE and - IP_UNBLOCK_SOURCE options are not - permitted for inclusive-mode group memberships.

-

To join a multicast group in MCAST_INCLUDE - mode with a single source, or add another source to an existing - inclusive-mode membership:

-
-
struct ip_mreq_source mreqs;
-setsockopt(s, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, &mreqs, sizeof(mreqs));
-
-

To leave a single source from an existing group in inclusive - mode:

-
-
struct ip_mreq_source mreqs;
-setsockopt(s, IPPROTO_IP, IP_DROP_SOURCE_MEMBERSHIP, &mreqs, sizeof(mreqs));
-
-If this is the last accepted source for the group, the membership will be - dropped. -

The - IP_ADD_SOURCE_MEMBERSHIP and - IP_DROP_SOURCE_MEMBERSHIP options are - not accepted for exclusive-mode group memberships. - However, both exclusive and inclusive mode memberships support the use of - the documented in RFC 3678. For management of source filter lists - using this API, please refer to sourcefilter(3).

-

The sysctl settings - net.inet.ip.mcast.maxsocksrc and - net.inet.ip.mcast.maxgrpsrc are used to specify an - upper limit on the number of per-socket and per-group source filter entries - which the kernel may allocate.

-
-
-

-

Raw IP sockets are connectionless, and are normally used with the - sendto(2) and recvfrom(2) calls, though - the connect(2) call may also be used to fix the - destination for future packets (in which case the read(2) - or recv(2) and write(2) or - send(2) system calls may be used).

-

If proto is 0, the default protocol - IPPROTO_RAW is used for outgoing packets, and only - incoming packets destined for that protocol are received. If - proto is non-zero, that protocol number will be used - on outgoing packets and to filter incoming packets.

-

Outgoing packets automatically have an IP header prepended to them - (based on the destination address and the protocol number the socket is - created with), unless the IP_HDRINCL option has been - set. Unlike in previous BSD releases, incoming - packets are received with IP header and options intact, leaving all fields - in network byte order.

-

IP_HDRINCL indicates the complete IP - header is included with the data and may be used only with the - SOCK_RAW type.

-
-
#include <netinet/in_systm.h>
-#include <netinet/ip.h>
-
-int hincl = 1;                  /* 1 = on, 0 = off */
-setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
-
-

Unlike previous BSD releases, the program - must set all the fields of the IP header, including the following:

-
-
ip->ip_v = IPVERSION;
-ip->ip_hl = hlen >> 2;
-ip->ip_id = 0;  /* 0 means kernel set appropriate value */
-ip->ip_off = htons(offset);
-ip->ip_len = htons(len);
-
-

The packet should be provided as is to be sent over wire. This - implies all fields, including ip_len and - ip_off to be in network byte order. See - byteorder(3) for more information on network byte order. - If the ip_id field is set to 0 then the kernel will - choose an appropriate value. If the header source address is set to - INADDR_ANY, the kernel will choose an appropriate - address.

-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[]
-
when trying to establish a connection on a socket which already has one, - or when trying to send a datagram with the destination address specified - and the socket is already connected;
-
[]
-
when trying to send a datagram, but no destination address is specified, - and the socket has not been connected;
-
[]
-
when the system runs out of memory for an internal data structure;
-
[]
-
when an attempt is made to create a socket with a network address for - which no network interface exists.
-
[]
-
when an attempt is made to create a raw IP socket by a non-privileged - process.
-
-

The following errors specific to IP may occur when setting or - getting IP options:

-
-
[]
-
An unknown socket option name was given.
-
[]
-
The IP option field was improperly formed; an option field was shorter - than the minimum value or longer than the option buffer provided.
-
-

The following errors may occur when attempting to send IP - datagrams via a “raw socket” with the - IP_HDRINCL option set:

-
-
[]
-
The user-supplied ip_len field was not equal to the - length of the datagram written to the socket.
-
-
-
-

-

getsockopt(2), recv(2), - send(2), byteorder(3), - CMSG_DATA(3), sourcefilter(3), - icmp(4), igmp(4), - inet(4), intro(4), - multicast(4)

-

D. Thaler, - B. Fenner, and B. Quinn, - Socket Interface Extensions for Multicast Source - Filters, RFC 3678, Jan - 2004.

-
-
-

-

The ip protocol appeared in - 4.2BSD. The ip_mreqn structure - appeared in Linux 2.4.

-
-
-

-

Before FreeBSD 10.0 packets received on - raw IP sockets had the ip_hl subtracted from the - ip_len field.

-

Before FreeBSD 11.0 packets received on - raw IP sockets had the ip_len and - ip_off fields converted to host byte order. Packets - written to raw IP sockets were expected to have ip_len - and ip_off in host byte order.

-
-
- - - - - -
August 9, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ip17x.4 4.html b/static/freebsd/man4/ip17x.4 4.html deleted file mode 100644 index a7355d9a..00000000 --- a/static/freebsd/man4/ip17x.4 4.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - -
IP17X(4)Device Drivers ManualIP17X(4)
-
-
-

-

ip17x — IC Plus - IP17x series Fast Ethernet switch driver

-
-
-

-

device mdio -
- device etherswitch -
- device ip17x

-
-
-

-

The ip17x driver supports the IC Plus - IP17X series Fast Ethernet switch controllers.

-
-
-

-

The ip17x driver supports the following - Fast Ethernet switch controllers:

-

-
    -
  • IC Plus IP178C
    • -
  • IC Plus IP175D
    • -
  • IC Plus IP175C
    • -
  • IC Plus IP175A
    • -
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The ip17x driver appeared in - FreeBSD 10.0.

-
-
- - - - - -
May 18, 2025
diff --git a/static/freebsd/man4/ip6.4 3.html b/static/freebsd/man4/ip6.4 3.html deleted file mode 100644 index 5a1f70ec..00000000 --- a/static/freebsd/man4/ip6.4 3.html +++ /dev/null @@ -1,559 +0,0 @@ - - - - - - -
IP6(4)Device Drivers ManualIP6(4)
-
-
-

-

ip6 — Internet - Protocol version 6 (IPv6) network layer

-
-
-

-

#include - <sys/socket.h> -
- #include <netinet/in.h>

-

int -
- socket(AF_INET6, - SOCK_RAW, - proto);

-
-
-

-

The IPv6 network layer is used by the IPv6 protocol family for - transporting data. IPv6 packets contain an IPv6 header that is not provided - as part of the payload contents when passed to an application. IPv6 header - options affect the behavior of this protocol and may be used by high-level - protocols (such as the tcp(4) and udp(4) - protocols) as well as directly by “raw sockets”, which process - IPv6 messages at a lower-level and may be useful for developing new - protocols and special-purpose applications.

-
- -

All IPv6 packets begin with an IPv6 header. When data received by - the kernel are passed to the application, this header is not included in - buffer, even when raw sockets are being used. Likewise, when data are sent - to the kernel for transmit from the application, the buffer is not examined - for an IPv6 header: the kernel always constructs the header. To directly - access IPv6 headers from received packets and specify them as part of the - buffer passed to the kernel, link-level access (bpf(4), - for example) must instead be utilized.

-

The header has the following definition:

-
-
struct ip6_hdr {
-     union {
-          struct ip6_hdrctl {
-               uint32_t ip6_un1_flow;	/* 20 bits of flow ID */
-               uint16_t ip6_un1_plen;	/* payload length */
-               uint8_t  ip6_un1_nxt;	/* next header */
-               uint8_t  ip6_un1_hlim;	/* hop limit */
-          } ip6_un1;
-          uint8_t ip6_un2_vfc;	/* version and class */
-     } ip6_ctlun;
-     struct in6_addr ip6_src;	/* source address */
-     struct in6_addr ip6_dst;	/* destination address */
-} __packed;
-
-#define ip6_vfc		ip6_ctlun.ip6_un2_vfc
-#define ip6_flow	ip6_ctlun.ip6_un1.ip6_un1_flow
-#define ip6_plen	ip6_ctlun.ip6_un1.ip6_un1_plen
-#define ip6_nxt		ip6_ctlun.ip6_un1.ip6_un1_nxt
-#define ip6_hlim	ip6_ctlun.ip6_un1.ip6_un1_hlim
-#define ip6_hops	ip6_ctlun.ip6_un1.ip6_un1_hlim
-
-

All fields are in network-byte order. Any options specified (see - Options below) must also be specified in - network-byte order.

-

ip6_flow specifies the flow ID. - ip6_plen specifies the payload length. - ip6_nxt specifies the type of the next header. - ip6_hlim specifies the hop limit.

-

The top 4 bits of ip6_vfc specify the class - and the bottom 4 bits specify the version.

-

ip6_src and ip6_dst - specify the source and destination addresses.

-

The IPv6 header may be followed by any number of extension headers - that start with the following generic definition:

-
-
struct ip6_ext {
-     uint8_t ip6e_nxt;
-     uint8_t ip6e_len;
-} __packed;
-
-
-
-

-

IPv6 allows header options on packets to manipulate the behavior - of the protocol. These options and other control requests are accessed with - the getsockopt(2) and setsockopt(2) - system calls at level IPPROTO_IPV6 and by using - ancillary data in recvmsg(2) and - sendmsg(2). They can be used to access most of the fields - in the IPv6 header and extension headers.

-

The following socket options are supported:

-
-
- int *
-
Get or set the default hop limit header field for outgoing unicast - datagrams sent on this socket.
-
- u_int *
-
Get or set the interface from which multicast packets will be sent. For - hosts with multiple interfaces, each multicast transmission is sent from - the primary network interface. The interface is specified as its index as - provided by if_nametoindex(3). A value of zero specifies - the default interface.
-
- int *
-
Get or set the default hop limit header field for outgoing multicast - datagrams sent on this socket. This option controls the scope of multicast - datagram transmissions. -

Datagrams with a hop limit of 1 are not forwarded beyond the - local network. Multicast datagrams with a hop limit of zero will not be - transmitted on any network but may be delivered locally if the sending - host belongs to the destination group and if multicast loopback (see - below) has not been disabled on the sending socket. Multicast datagrams - with a hop limit greater than 1 may be forwarded to the other networks - if a multicast router (such as mrouted(8) - (ports/net/mrouted)) is attached to the local - network.

-
-
- u_int *
-
Get or set the status of whether multicast datagrams will be looped back - for local delivery when a multicast datagram is sent to a group to which - the sending host belongs. -

This option improves performance for applications that may - have no more than one instance on a single host (such as a router - daemon) by eliminating the overhead of receiving their own - transmissions. It should generally not be used by applications for which - there may be more than one instance on a single host (such as a - conferencing program) or for which the sender does not belong to the - destination group (such as a time-querying program).

-

A multicast datagram sent with an initial hop limit greater - than 1 may be delivered to the sending host on a different interface - from that on which it was sent if the host belongs to the destination - group on that other interface. The multicast loopback control option has - no effect on such delivery.

-
-
- struct ipv6_mreq *
-
Join a multicast group. A host must become a member of a multicast group - before it can receive datagrams sent to the group. -
- 
struct ipv6_mreq {
-	struct in6_addr	ipv6mr_multiaddr;
-	unsigned int	ipv6mr_interface;
-};
-
-

ipv6mr_interface may be set to zeroes to - choose the default multicast interface or to the index of a particular - multicast-capable interface if the host is multihomed. Membership is - associated with a single interface; programs running on multihomed hosts - may need to join the same group on more than one interface.

-

If the multicast address is unspecified (i.e., all zeroes), - messages from all multicast addresses will be accepted by this group. - Note that setting to this value requires superuser privileges.

-
-
- struct ipv6_mreq *
-
Drop membership from the associated multicast group. Memberships are - automatically dropped when the socket is closed or when the process - exits.
-
- int *
-
Get or set whether a datagram's original destination address and port are - returned as ancillary data along with the payload in subsequent - recvmsg(2) calls. The information is stored in the - ancillary data as a sockaddr_in6 structure.
-
- int *
-
Get or set the allocation policy of ephemeral ports for when the kernel - automatically binds a local address to this socket. The following values - are available: -

-
-
-
Use the regular range of non-reserved ports (varies, see - ip(4)).
-
-
Use a high range (varies, see ip(4)).
-
-
Use a low, reserved range (600-1023, see - ip(4)).
-
-
-
- int *
-
Get or set whether additional information about subsequent packets will be - provided as ancillary data along with the payload in subsequent - recvmsg(2) calls. The information is stored in the - following structure in the ancillary data returned: -
- 
struct in6_pktinfo {
-	struct in6_addr ipi6_addr;    /* src/dst IPv6 address */
-	unsigned int    ipi6_ifindex; /* send/recv if index */
-};
-
-
-
- int *
-
Get or set whether the hop limit header field from subsequent packets will - be provided as ancillary data along with the payload in subsequent - recvmsg(2) calls. The value is stored as an - int in the ancillary data returned.
-
- int *
-
Get or set whether the hop-by-hop options from subsequent packets will be - provided as ancillary data along with the payload in subsequent - recvmsg(2) calls. The option is stored in the following - structure in the ancillary data returned: -
- 
struct ip6_hbh {
-	uint8_t ip6h_nxt;	/* next header */
-	uint8_t ip6h_len;	/* length in units of 8 octets */
-/* followed by options */
-} __packed;
-
-

The - () - routine and family of routines may be used to manipulate this data.

-

This option requires superuser privileges.

-
-
- int *
-
Get or set whether the destination options from subsequent packets will be - provided as ancillary data along with the payload in subsequent - recvmsg(2) calls. The option is stored in the following - structure in the ancillary data returned: -
- 
struct ip6_dest {
-	uint8_t ip6d_nxt;	/* next header */
-	uint8_t ip6d_len;	/* length in units of 8 octets */
-/* followed by options */
-} __packed;
-
-

The - () - routine and family of routines may be used to manipulate this data.

-

This option requires superuser privileges.

-
-
- int *
-
Get or set the value of the traffic class field used for outgoing - datagrams on this socket. The value must be between -1 and 255. A value of - -1 resets to the default value.
-
- int *
-
Get or set the status of whether the traffic class header field will be - provided as ancillary data along with the payload in subsequent - recvmsg(2) calls. The header field is stored as a single - value of type int.
-
- int *
-
Get or set whether the routing header from subsequent packets will be - provided as ancillary data along with the payload in subsequent - recvmsg(2) calls. The header is stored in the following - structure in the ancillary data returned: -
- 
struct ip6_rthdr {
-	uint8_t ip6r_nxt;	/* next header */
-	uint8_t ip6r_len;	/* length in units of 8 octets */
-	uint8_t ip6r_type;	/* routing type */
-	uint8_t ip6r_segleft;	/* segments left */
-/* followed by routing-type-specific data */
-} __packed;
-
-

The - () - routine and family of routines may be used to manipulate this data.

-

This option requires superuser privileges.

-
-
- struct cmsghdr *
-
Get or set all header options and extension headers at one time on the - last packet sent or received on the socket. All options must fit within - the size of an mbuf (see mbuf(9)). Options are specified - as a series of cmsghdr structures followed by - corresponding values. cmsg_level is set to - IPPROTO_IPV6, cmsg_type to - one of the other values in this list, and trailing data to the option - value. When setting options, if the length optlen to - setsockopt(2) is zero, all header options will be reset - to their default values. Otherwise, the length should specify the size the - series of control messages consumes. -

Instead of using sendmsg(2) to specify - option values, the ancillary data used in these calls that correspond to - the desired header options may be directly specified as the control - message in the series of control messages provided as the argument to - setsockopt(2).

-
-
- int *
-
Get or set the byte offset into a packet where the 16-bit checksum is - located. When set, this byte offset is where incoming packets will be - expected to have checksums of their data stored and where outgoing packets - will have checksums of their data computed and stored by the kernel. A - value of -1 specifies that no checksums will be checked on incoming - packets and that no checksums will be computed or stored on outgoing - packets. The offset of the checksum for ICMPv6 sockets cannot be relocated - or turned off.
-
- int *
-
Get or set whether only IPv6 connections can be made to this socket. For - wildcard sockets, this can restrict connections to IPv6 only.
-
- int *
-
Get or set whether the minimal IPv6 maximum transmission unit (MTU) size - will be used to avoid fragmentation from occurring for subsequent outgoing - datagrams.
-
- int *
-
Get or set the ipsec(4) authentication level.
-
- int *
-
Get or set the ESP transport level.
-
- int *
-
Get or set the ESP encapsulation level.
-
- int *
-
Get or set the ipcomp(4) level.
-
-

The IPV6_PKTINFO, - IPV6_HOPLIMIT, IPV6_HOPOPTS, - IPV6_DSTOPTS, IPV6_RTHDR, - and IPV6_ORIGDSTADDR options will return ancillary - data along with payload contents in subsequent recvmsg(2) - calls with cmsg_level set to - IPPROTO_IPV6 and cmsg_type set - to respective option name value (e.g., - IPV6_HOPTLIMIT). Some of these options may also be - used directly as ancillary cmsg_type values in - sendmsg(2) to set options on the packet being transmitted - by the call. The cmsg_level value must be - IPPROTO_IPV6. For these options, the ancillary data - object value format is the same as the value returned as explained for each - when received with recvmsg(2).

-

Note that using sendmsg(2) to specify options on - particular packets works only on UDP and raw sockets. To manipulate header - options for packets on TCP sockets, only the socket options may be used.

-

In some cases, there are multiple APIs defined for manipulating an - IPv6 header field. A good example is the outgoing interface for multicast - datagrams, which can be set by the IPV6_MULTICAST_IF - socket option, through the IPV6_PKTINFO option, and - through the sin6_scope_id field of the socket address - passed to the sendto(2) system call.

-

Resolving these conflicts is implementation dependent. This - implementation determines the value in the following way: options specified - by using ancillary data (i.e., sendmsg(2)) are considered - first, options specified by using IPV6_PKTOPTIONS to - set “sticky” options are considered second, options specified - by using the individual, basic, and direct socket options (e.g., - IPV6_UNICAST_HOPS) are considered third, and options - specified in the socket address supplied to sendto(2) are - the last choice.

-
-
-

-

IPv6 multicasting is supported only on - AF_INET6 sockets of type - SOCK_DGRAM and SOCK_RAW, and - only on networks where the interface driver supports multicasting. Socket - options (see above) that manipulate membership of multicast groups and other - multicast options include IPV6_MULTICAST_IF, - IPV6_MULTICAST_HOPS, - IPV6_MULTICAST_LOOP, - IPV6_LEAVE_GROUP, and - IPV6_JOIN_GROUP.

-
-
-

-

Raw IPv6 sockets are connectionless and are normally used with the - sendto(2) and recvfrom(2) calls, - although the connect(2) call may be used to fix the - destination address for future outgoing packets so that - send(2) may instead be used and the - bind(2) call may be used to fix the source address for - future outgoing packets instead of having the kernel choose a source - address.

-

By using connect(2) or - bind(2), raw socket input is constrained to only packets - with their source address matching the socket destination address if - connect(2) was used and to packets with their destination - address matching the socket source address if bind(2) was - used.

-

If the proto argument to - socket(2) is zero, the default protocol - (IPPROTO_RAW) is used for outgoing packets. For - incoming packets, protocols recognized by kernel are - passed to the - application socket (e.g., tcp(4) and - udp(4)) except for some ICMPv6 messages. The ICMPv6 - messages not passed to raw sockets include echo, timestamp, and address mask - requests. If proto is non-zero, only packets with this - protocol will be passed to the socket.

-

IPv6 fragments are also not passed to application sockets until - they have been reassembled. If reception of all packets is desired, - link-level access (such as bpf(4)) must be used - instead.

-

Outgoing packets automatically have an IPv6 header prepended to - them (based on the destination address and the protocol number the socket - was created with). Incoming packets are received by an application without - the IPv6 header or any extension headers.

-

Outgoing packets will be fragmented automatically by the kernel if - they are too large. Incoming packets will be reassembled before being sent - to the raw socket, so packet fragments or fragment headers will never be - seen on a raw socket.

-
-
-
-

-

The following determines the hop limit on the next packet - received:

-
-
struct iovec iov[2];
-u_char buf[BUFSIZ];
-struct cmsghdr *cm;
-struct msghdr m;
-int optval;
-bool found;
-u_char data[2048];
-
-/* Create socket. */
-
-(void)memset(&m, 0, sizeof(m));
-(void)memset(&iov, 0, sizeof(iov));
-
-iov[0].iov_base = data;		/* buffer for packet payload */
-iov[0].iov_len = sizeof(data);	/* expected packet length */
-
-m.msg_name = &from;		/* sockaddr_in6 of peer */
-m.msg_namelen = sizeof(from);
-m.msg_iov = iov;
-m.msg_iovlen = 1;
-m.msg_control = (caddr_t)buf;	/* buffer for control messages */
-m.msg_controllen = sizeof(buf);
-
-/*
- * Enable the hop limit value from received packets to be
- * returned along with the payload.
- */
-optval = 1;
-if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &optval,
-    sizeof(optval)) == -1)
-	err(1, "setsockopt");
-
-found = false;
-do {
-	if (recvmsg(s, &m, 0) == -1)
-		err(1, "recvmsg");
-	for (cm = CMSG_FIRSTHDR(&m); cm != NULL;
-	     cm = CMSG_NXTHDR(&m, cm)) {
-		if (cm->cmsg_level == IPPROTO_IPV6 &&
-		    cm->cmsg_type == IPV6_HOPLIMIT &&
-		    cm->cmsg_len == CMSG_LEN(sizeof(int))) {
-			found = true;
-			(void)printf("hop limit: %d\n",
-			    *(int *)CMSG_DATA(cm));
-			break;
-		}
-	}
-} while (!found);
-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[EISCONN]
-
when trying to establish a connection on a socket which already has one or - when trying to send a datagram with the destination address specified and - the socket is already connected.
-
[ENOTCONN]
-
when trying to send a datagram, but no destination address is specified, - and the socket has not been connected.
-
[ENOBUFS]
-
when the system runs out of memory for an internal data structure.
-
[EADDRNOTAVAIL]
-
when an attempt is made to create a socket with a network address for - which no network interface exists.
-
[EACCES]
-
when an attempt is made to create a raw IPv6 socket by a non-privileged - process.
-
-

The following errors specific to IPv6 may occur when setting or - getting header options:

-
-
[EINVAL]
-
An unknown socket option name was given.
-
[EINVAL]
-
An ancillary data object was improperly formed.
-
-
-
-

-

getsockopt(2), recv(2), - send(2), setsockopt(2), - socket(2), CMSG_DATA(3), - if_nametoindex(3), inet6_opt_init(3), - bpf(4), icmp6(4), - inet6(4), ip(4), - netintro(4), tcp(4), - udp(4)

-

W. Stevens and - M. Thomas, Advanced Sockets API - for IPv6, RFC 2292, - February 1998.

-

S. Deering and - R. Hinden, Internet Protocol, - Version 6 (IPv6) Specification, RFC 2460, - December 1998.

-

R. Gilligan, - S. Thomson, J. Bound, and - W. Stevens, Basic Socket - Interface Extensions for IPv6, RFC 2553, - March 1999.

-

R. Gilligan, - S. Thomson, J. Bound, - J. McCann, and W. Stevens, - Basic Socket Interface Extensions for IPv6, - RFC 3493, February - 2003.

-

W. Stevens, - M. Thomas, E. Nordmark, - and T. Jinmei, Advanced Sockets - Application Program Interface (API) for IPv6, RFC - 3542, May 2003.

-

S. Deering and - R. Hinden, Internet Protocol, - Version 6 (IPv6) Specification, RFC 8200, - July 2017.

-

W. Stevens, - B. Fenner, and A. Rudoff, - UNIX Network Programming, 3rd Edition, - Addison-Wesley Professional, November - 2003.

-
-
-

-

Most of the socket options are defined in RFC 2292 / 3542 or RFC - 2553 / 3493. The IPV6_PORTRANGE socket option and - the conflict resolution rule are not defined in the RFCs and should be - considered implementation dependent.

-
-
- - - - - -
July 24, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/ipfirewall.4 3.html b/static/freebsd/man4/ipfirewall.4 3.html deleted file mode 100644 index ebaf6272..00000000 --- a/static/freebsd/man4/ipfirewall.4 3.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - -
IPFW(4)Device Drivers ManualIPFW(4)
-
-
-

-

ipfw — IP packet - filter and traffic accounting

-
-
-

-

To compile the driver into the kernel, place the following option - in the kernel configuration file:

-
options IPFIREWALL
-

Other related kernel options which may also be useful are:

-
options - IPFIREWALL_DEFAULT_TO_ACCEPT -
-options IPDIVERT -
-options IPFIREWALL_NAT -
-options IPFIREWALL_NAT64 -
-options IPFIREWALL_NPTV6 -
-options IPFIREWALL_PMOD -
-options IPFIREWALL_VERBOSE -
-options IPFIREWALL_VERBOSE_LIMIT=100 -
-options LIBALIAS
-

To load the driver as a module at boot time, add the following - line into the loader.conf(5) file:

-
-
ipfw_load="YES"
-
-
-
-

-

The ipfw system facility allows filtering, - redirecting, and other operations on IP packets travelling through network - interfaces.

-

The default behavior of ipfw is to block - all incoming and outgoing traffic. This behavior can be modified, to allow - all traffic through the ipfw firewall by default, by - enabling the IPFIREWALL_DEFAULT_TO_ACCEPT kernel - option. This option may be useful when configuring - ipfw for the first time. If the default - ipfw behavior is to allow everything, it is easier - to cope with firewall-tuning mistakes which may accidentally block all - traffic.

-

When using natd(8) in conjunction with - ipfw as NAT facility, the kernel option - IPDIVERT enables diverting packets to - natd(8) for translation.

-

When using the in-kernel NAT facility of - ipfw, the kernel option - IPFIREWALL_NAT enables basic - libalias(3) functionality in the kernel.

-

When using any of the IPv4 to IPv6 transition mechanisms in - ipfw, the kernel option - IPFIREWALL_NAT64 enables all of these NAT64 methods - in the kernel.

-

When using the IPv6 network prefix translation facility of - ipfw, the kernel option - IPFIREWALL_NPTV6 enables this functionality in the - kernel.

-

When using the packet modification facility of - ipfw, the kernel option - IPFIREWALL_PMOD enables this functionality in the - kernel.

-

To enable logging of packets passing through - ipfw, enable the - IPFIREWALL_VERBOSE kernel option. The - IPFIREWALL_VERBOSE_LIMIT option will prevent - syslogd(8) from flooding system logs or causing local - Denial of Service. This option may be set to the number of packets which - will be logged on a per-entry basis before the entry is rate-limited.

-

When using the in-kernel NAT facility of - ipfw, the kernel option - LIBALIAS enables full libalias(3) - functionality in the kernel. Full functionality refers to included support - for ftp, bbt, skinny, irc, pptp and smedia packets, which are missing in the - basic libalias(3) functionality accomplished with the - IPFIREWALL_NAT kernel option.

-

The user interface for ipfw is implemented - by the ipfw(8) utility, so please refer to the - ipfw(8) man page for a complete description of the - ipfw capabilities and how to use it.

-
-
-

-

setsockopt(2), libalias(3), - divert(4), ip(4), - ip6(4), ipfw(8), - natd(8), sysctl(8), - syslogd(8), pfil(9)

-
-
- - - - - -
August 19, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ipheth.4 3.html b/static/freebsd/man4/ipheth.4 3.html deleted file mode 100644 index 6bae6834..00000000 --- a/static/freebsd/man4/ipheth.4 3.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - -
IPHETH(4)Device Drivers ManualIPHETH(4)
-
-
-

-

ipheth — USB Apple - iPhone/iPad tethered Ethernet driver

-
-
-

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_ipheth_load="YES"
-
-

Alternatively, to compile this driver into the kernel, place the - following lines in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device ipheth
-
-
-

-

The ipheth driver provides support for - network access through Apple iPhone and iPad devices, often referred to as - USB tethering.

-

ipheth should work with any Apple iPhone - or iPad device. In most cases this must be explicitly enabled on the device - first.

-

For more information on configuring this device, see - ifconfig(8). The device does not support different media - types or options.

-
-
-

-

The following devices are supported by the - ipheth driver:

-

-
    -
  • Apple iPhone tethering (all models)
    • -
  • Apple iPad tethering (all models)
    • -
-
-
-

-
-
Manual Configuration
-
-

The following example shows how to manually configure network - access on a device that is not automatically recognized.

-

First, load the driver and find out the unit and the address - of the USB Apple device:

-
- 
# kldload ipheth
-# usbconfig | grep Apple
-ugen0.2: <Apple Inc. iPhone> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
-
-

In this example, the unit and the address of the device is 0.2 - (“ugen0.2”), and its configuration - index is 0 (“cfg=0”).

-

Secondly, check what other configurations are available for - the device:

-
- 
# usbconfig -d 0.2 dump_all_config_desc | grep -E '(^ Conf|iConf)'
- Configuration index 0
-    iConfiguration = 0x0005  <PTP>
- Configuration index 1
-    iConfiguration = 0x0006  <iPod USB Interface>
- Configuration index 2
-    iConfiguration = 0x0007  <PTP + Apple Mobile Device>
- Configuration index 3
-    iConfiguration = 0x0008  <PTP + Apple Mobile Device + Apple USB Ethernet>
-
-

In this example, there are 4 different configurations - available. The configuration with index 3 seems to be related to - Ethernet. It is time to configure the device:

-
- 
# usbconfig -d 0.2 set_config 3
-# usbconfig | grep 'Apple.*cfg=3'
-ugen0.2: <Apple Inc. iPhone> at usbus0, cfg=3 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
-
-

At this point the Apple device should ask whether the - FreeBSD machine can be trusted (“Mobile - Data” has to be on).

-

A new - USB Ethernet - interface should become available:

-
- 
# dmesg | grep 'ue[0-9]'
-ue0: <USB Ethernet> on ipheth0
-ue0: bpf attached
-ue0: Ethernet address: 4e:7c:5f:2c:5f:7a
-
-

At this point it might be necessary to run - usbmuxd(1) (available in ports(7) at - comms/usbmuxd):

-
- 
# usbmuxd --enable-exit --foreground --user root --verbose
-
-

Now it is time to configure the network interface:

-
- 
# sysrc ifconfig_ue0="SYNCDHCP"
-ifconfig_ue0:  -> SYNCDHCP
-# service netif restart ue0
-
-

That is it. The machine should now be connected to the network - via USB tethering.

-
-
-
-
-

-

arp(4), cdce(4), - cdceem(4), intro(4), - netintro(4), urndis(4), - usb(4), ifconfig(8), - usbconfig(8)

-
-
-

-

The ipheth device driver first appeared in - FreeBSD 8.2.

-
-
-

-

The ipheth driver was written by - Hans Petter Selasky - <hselasky@FreeBSD.org>.

-
-
-

-

Some devices are not recognized automatically and may need to be - manually configured to use an alternative configuration with the - usbconfig(8) utility. See - EXAMPLES for workarounds.

-
-
- - - - - -
January 29, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/ipmi.4 3.html b/static/freebsd/man4/ipmi.4 3.html deleted file mode 100644 index a02d82b8..00000000 --- a/static/freebsd/man4/ipmi.4 3.html +++ /dev/null @@ -1,200 +0,0 @@ - - - - - - -
IPMI(4)Device Drivers ManualIPMI(4)
-
-
-

-

ipmi — OpenIPMI - compatible IPMI interface driver

-
-
-

-

device ipmi

-

To manually specify I/O attachment in - /boot/device.hints: -
- hint.ipmi.0.at="isa" -
- hint.ipmi.0.port="0xCA2" -
- hint.ipmi.0.spacing="8" -
- hint.ipmi.0.mode="KCS"

-

To manually specify memory attachment in - /boot/device.hints: -
- hint.ipmi.0.at="isa" -
- hint.ipmi.0.maddr="0xf0000000" -
- hint.ipmi.0.spacing="8" -
- hint.ipmi.0.mode="SMIC"

-

Meaning of spacing:

-
-
-
8
-
8 bit alignment
-
16
-
16 bit alignment
-
32
-
32 bit alignment
-
-
-

If the port and - spacing are not specified the interface type default - will be used. Only specify either the port for I/O - access or maddr for memory access.

-
-
-

-

The IPMI (Intelligent Platform Management Interface) is a standard - for monitoring system hardware by permitting generic code to detect and - monitor the sensors in a system. The IPMI standard offers watchdog support, - an FRU database, and other support extensions. It is currently being adopted - by the makers of many single board and embedded system manufacturers.

-

The ipmi driver in - FreeBSD is heavily adopted from the standard and - Linux driver; however, not all features described in the standard are - supported.

-

The ipmi driver implements the power - cycling option to shutdown(8) to implement power cycling - of the system. The motherboard's BMC must support the chassis device and the - optional power cycle subcomand of the chassis control command as described - in section 28.3 of the IPMI standard. The length of time the system is off - will be at least one second, but may be longer if the power cycle interval - has been set (see section 28.9).

-
-
-

-

Sending and receiving messages through the - ipmi driver requires the use of - ioctl(2). The ioctls are used due to the complexity of - data sent to and from the device. The ioctl(2) command - codes below are defined in - <sys/ipmi.h>. The third - argument to ioctl(2) should be a pointer to the type - indicated.

-

Currently the following ioctls are supported:

-
-
- (struct ipmi_recv)
-
Receive a message. Possible error values: -
-
[EAGAIN]
-
No messages are in the process queue.
-
[EFAULT]
-
An address supplied was invalid.
-
[EMSGSIZE]
-
The address could not fit in the message buffer and will remain in the - buffer.
-
-
-
- (struct ipmi_recv)
-
Like IPMICTL_RECEIVE_MSG but if the message cannot - fit into the buffer, it will truncate the contents instead of leaving the - data in the buffer.
-
- (struct ipmi_req)
-
Send a message to the interface. Possible error values: -
-
[EFAULT]
-
An address supplied was invalid.
-
[ENOMEM]
-
Buffers could not be allowed for the command, out of memory.
-
-
-
- (unsigned int)
-
Set the slave address for source messages.
-
- (unsigned int)
-
Get the slave address for source messages.
-
- (unsigned int)
-
Set the slave LUN for source messages.
-
- (unsigned int)
-
Get the slave LUN for source messages.
-
-
-

-
-
- (struct ipmi_cmdspec)
-
Register to receive a specific command. Possible error values: -
-
[EFAULT]
-
An supplied address was invalid.
-
[EBUSY]
-
The network function/command is already in use.
-
[ENOMEM]
-
Could not allocate memory.
-
-
-
- (struct ipmi_cmdspec)
-
Unregister to receive a specific command. Possible error values: -
-
[EFAULT]
-
An address supplied was invalid.
-
[ENOENT]
-
The network function/command was not found.
-
-
-
-
-
-

-
-
- (int)
-
Set whether this interface receives events. Possible error values: -
-
[EFAULT]
-
An address supplied was invalid.
-
-
-
-
-
-
-

-

ioctl(2), watchdog(4), - reboot(8), shutdown(8), - watchdog(8), watchdogd(8), - watchdog(9)

-
-
-

-

The ipmi driver first appeared in - FreeBSD 6.2.

-
-
-

-

The ipmi driver was written by - Doug Ambrisko - <ambrisko@FreeBSD.org>. - This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
-

-

Not all features of the MontaVista driver are supported.

-

Currently, IPMB and BT modes are not implemented.

-
-
- - - - - -
October 25, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ips.4 3.html b/static/freebsd/man4/ips.4 3.html deleted file mode 100644 index 022b137f..00000000 --- a/static/freebsd/man4/ips.4 3.html +++ /dev/null @@ -1,201 +0,0 @@ - - - - - - -
IPS(4)Device Drivers ManualIPS(4)
-
-
-

-

ips — IBM/Adaptec - ServeRAID controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device ips
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ips_load="YES"
-
-
-
-

-

The ips driver claims to support the IBM - (now Adaptec) ServeRAID series SCSI controller cards.

-

These cards come with a built in configuration utility - stored in the firmware known as the ISPR. This utility is accessed with the - ⟨⟩ - key combination during the initial card POST.

-

It is highly recommended that this utility be used to configure - the card before attempting to diagnose the below error messages.

-

In some cases, the ips driver can have - difficulties attaching during the system initialization period. To avoid - these difficulties, set the hw.ips.0.disable tunable - to 1. It will prevent the driver from attaching.

-
-
-

-

Controllers supported by the ips driver - include:

-

-
    -
  • IBM ServeRAID 3H
    • -
  • ServeRAID 4L/4M/4H
    • -
  • ServeRAID Series 5
    • -
  • ServeRAID 6i/6M
    • -
  • ServeRAID 7t/7k/7M
    • -
-

Newer ServeRAID controllers are supported by the - aac(4) or mfi(4) driver.

-
-
-

-

Several error codes may be shown when the card initializes the IBM - ISPR utility and are independent of FreeBSD.

-
-
ips%d: failed to get adapter configuration data from device
-
-
ips%d: failed to get drive configuration data from device
-
-

Unable to obtain adapter or drive configuration.

-
-
ips%d iobuf error
-
-

A buffer input/output error has occurred. - [ENXIO]

-
-
-
-

-
-
Attaching bus failed
-
-

This message is undocumented.

-
-
WARNING: command timeout. Adapter is in toaster mode, resetting
-
-

A command timeout has caused the adapter to be reset.

-
-
AIEE! adapter reset failed, giving up and going home! Have a nice day
-
-

An error occurred while attempting to reset the adapter.

-
-
unable to get adapter configuration
-
-
unable to get drive configuration
-
-

There was an error when attempting to get configuration - information.

-
-
Adapter error during initialization.
-
-
adapter initialization failed
-
-

There was an error while attempting to initialize the - adapter.

-
-
adapter failed config check
-
-
adapter clear failed
-
-

There was an error while checking the adapter.

-
-
device is disabled
-
-

The adapter is disabled.

-
-
resource allocation failed
-
-
irq allocation failed
-
-
irq setup failed
-
-

The driver was unable to allocate resources for the - device.

-
-
-
-
-

-
-
can't alloc command dma tag
-
-
can't alloc SG dma tag
-
-
can't alloc dma tag for statue queue
-
-
dmamap failed
-
-

Failure to map or allocate DMA resources.

-
-
-
-
-

-
-
failed to initialize command buffers
-
-
no mem for command slots!
-
-

The ips driver will return - [ENOMEM] in such cases.

-
-
ERROR: unable to get a command! can't flush cache!
-
-
ERROR: cache flush command failed!
-
-
ERROR: unable to get a command! can't update nvram
-
-
ERROR: nvram update command failed!
-
-
ERROR: unable to get a command! can't sync cache!
-
-
ERROR: cache sync command failed!
-
-
ERROR: unable to get a command! can't sync cache!
-
-
ERROR: etable command failed!
-
-
-
-
-
-

-

Unlike many of the other SCSI devices in - FreeBSD, the ips driver does - not use the cam(4) SCSI subsystem.

-
-
-

-

aac(4), ch(4), - da(4), mfi(4), - sysctl(8)

-
-
-

-

The ips driver was written by - David Jefferys and Scott - Long - <scottl@FreeBSD.org>.

-

This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
August 7, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/ipsec.4 3.html b/static/freebsd/man4/ipsec.4 3.html deleted file mode 100644 index c5768845..00000000 --- a/static/freebsd/man4/ipsec.4 3.html +++ /dev/null @@ -1,423 +0,0 @@ - - - - - - -
IPSEC(4)Device Drivers ManualIPSEC(4)
-
-
-

-

ipsec — Internet - Protocol Security protocol

-
-
-

-

options IPSEC -
- options IPSEC_SUPPORT -
- device crypto

-

-
- #include <sys/types.h> -
- #include <netinet/in.h> -
- #include <netipsec/ipsec.h> -
- #include - <netipsec/ipsec6.h>

-
-
-

-

ipsec is a security protocol implemented - within the Internet Protocol layer of the networking stack. - ipsec is defined for both IPv4 and IPv6 - (inet(4) and inet6(4)). - ipsec is a set of protocols, ESP (for Encapsulating - Security Payload) AH (for Authentication Header), and IPComp (for IP Payload - Compression Protocol) that provide security services for IP datagrams. AH - both authenticates and guarantees the integrity of an IP packet by attaching - a cryptographic checksum computed using one-way hash functions. ESP, in - addition, prevents unauthorized parties from reading the payload of an IP - packet by also encrypting it. IPComp tries to increase communication - performance by compressing IP payload, thus reducing the amount of data - sent. This will help nodes on slow links but with enough computing power. - ipsec operates in one of two modes: transport mode - or tunnel mode. Transport mode is used to protect peer-to-peer communication - between end nodes. Tunnel mode encapsulates IP packets within other IP - packets and is designed for security gateways such as VPN endpoints.

-

System configuration requires the crypto(4) - subsystem.

-

The packets can be passed to a virtual enc(4) - interface, to perform packet filtering before outbound encryption and after - decapsulation inbound.

-

To properly filter on the inner packets of an - ipsec tunnel with firewalls, you can change the - values of the following sysctls

- - - - - - - - - - - - - - - - -
DefaultEnable
net.inet.ipsec.filtertunnel01
net.inet6.ipsec6.filtertunnel01
-
-

-

ipsec is controlled by a key management - and policy engine, that reside in the operating system kernel. Key - management is the process of associating keys with security associations, - also know as SAs. Policy management dictates when new security associations - created or destroyed.

-

The key management engine can be accessed from userland by using - PF_KEY sockets. The PF_KEY - socket API is defined in RFC2367.

-

The policy engine is controlled by an extension to the - PF_KEY API, setsockopt(2) - operations, and sysctl(3) interface. The kernel implements - an extended version of the PF_KEY interface and - allows the programmer to define IPsec policies which are similar to the - per-packet filters. The setsockopt(2) interface is used to - define per-socket behavior, and sysctl(3) interface is - used to define host-wide default behavior.

-

The kernel code does not implement a dynamic encryption key - exchange protocol such as IKE (Internet Key Exchange). Key exchange - protocols are beyond what is necessary in the kernel and should be - implemented as daemon processes which call the - APIs.

-
-
-

-

IPsec policies can be managed in one of two ways, either by - configuring per-socket policies using the setsockopt(2) - system calls, or by configuring kernel level packet filter-based policies - using the PF_KEY interface, via the - setkey(8) you can define IPsec policies against packets - using rules similar to packet filtering rules. Refer to - setkey(8) on how to use it.

-

Depending on the socket's address family, IPPROTO_IP or - IPPROTO_IPV6 transport level and IP_IPSEC_POLICY or IPV6_IPSEC_POLICY socket - options may be used to configure per-socket security policies. A - properly-formed IPsec policy specification structure can be created using - ipsec_set_policy(3) function and used as socket option - value for the setsockopt(2) call.

-

When setting policies using the setkey(8) - command, the “default” option - instructs the system to use its default policy, as explained below, for - processing packets. The following sysctl variables are available for - configuring the system's IPsec behavior. The variables can have one of two - values. A 1 means - “use”, which means that if there is a - security association then use it but if there is not then the packets are - not processed by IPsec. The value 2 is synonymous - with “require”, which requires that a - security association must exist for the packets to move, and not be dropped. - These terms are defined in ipsec_set_policy(3).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeChangeable
net.inet.ipsec.esp_trans_deflevintegeryes
net.inet.ipsec.esp_net_deflevintegeryes
net.inet.ipsec.ah_trans_deflevintegeryes
net.inet.ipsec.ah_net_deflevintegeryes
net.inet6.ipsec6.esp_trans_deflevintegeryes
net.inet6.ipsec6.esp_net_deflevintegeryes
net.inet6.ipsec6.ah_trans_deflevintegeryes
net.inet6.ipsec6.ah_net_deflevintegeryes
-

If the kernel does not find a matching, system wide, policy then - the default value is applied. The system wide default policy is specified by - the following sysctl(8) variables. - 0 means - “discard” which asks the kernel to - drop the packet. 1 means - “none”.

- - - - - - - - - - - - - - - - -
TypeChangeable
net.inet.ipsec.def_policyintegeryes
net.inet6.ipsec6.def_policyintegeryes
-
-
-

-

When the ipsec protocols are configured - for use, all protocols are included in the system. To selectively - enable/disable protocols, use sysctl(8).

- - - - - - - - - - - - - - - - - -
Default
net.inet.esp.esp_enableOn
net.inet.ah.ah_enableOn
net.inet.ipcomp.ipcomp_enableOn
-

In addition the following variables are accessible via - sysctl(8), for tweaking the kernel's IPsec behavior:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeChangeable
net.inet.ipsec.ah_cleartosintegeryes
net.inet.ipsec.ah_offsetmaskintegeryes
net.inet.ipsec.dfbitintegeryes
net.inet.ipsec.ecnintegeryes
net.inet.ipsec.debugintegeryes
net.inet.ipsec.natt_cksum_policyintegeryes
net.inet.ipsec.check_policy_historyintegeryes
net.inet.ipsec.random_idintegeryes
net.inet6.ipsec6.ecnintegeryes
net.inet6.ipsec6.debugintegeryes
-

The variables are interpreted as follows:

-
-
-
If set to non-zero, the kernel clears the type-of-service field in the - IPv4 header during AH authentication data computation. This variable is - used to get current systems to inter-operate with devices that implement - RFC1826 AH. It should be set to non-zero (clear the type-of-service field) - for RFC2402 conformance.
-
-
During AH authentication data computation, the kernel will include a 16bit - fragment offset field (including flag bits) in the IPv4 header, after - computing logical AND with the variable. The variable is used for - inter-operating with devices that implement RFC1826 AH. It should be set - to zero (clear the fragment offset field during computation) for RFC2402 - conformance.
-
-
This variable configures the kernel behavior on IPv4 IPsec tunnel - encapsulation. If set to 0, the DF bit on the outer IPv4 header will be - cleared while 1 means that the outer DF bit is set regardless from the - inner DF bit and 2 indicates that the DF bit is copied from the inner - header to the outer one. The variable is supplied to conform to RFC2401 - chapter 6.1.
-
-
If set to non-zero, IPv4 IPsec tunnel encapsulation/decapsulation behavior - will be friendly to ECN (explicit congestion notification), as documented - in draft-ietf-ipsec-ecn-02.txt. - gif(4) talks more about the behavior.
-
-
If set to non-zero, debug messages will be generated via - syslog(3).
-
-
Controls how the kernel handles TCP and UDP checksums when ESP in UDP - encapsulation is used for IPsec transport mode. If set to a non-zero - value, the kernel fully recomputes checksums for inbound TCP segments and - UDP datagrams after they are decapsulated and decrypted. If set to 0 and - original addresses were configured for corresponding SA by the IKE daemon, - the kernel incrementally recomputes checksums for inbound TCP segments and - UDP datagrams. If addresses were not configured, the checksums are - ignored.
-
-
Enables strict policy checking for inbound packets. By default, inbound - security policies check that packets handled by IPsec have been decrypted - and authenticated. If this variable is set to a non-zero value, each - packet handled by IPsec is checked against the history of IPsec security - associations. The IPsec security protocol, mode, and SA addresses must - match.
-
-
Enables randomization of encapsulated IPv4 packets ID. By default, ID - randomization is not enabled.
-
-

Variables under the net.inet6.ipsec6 tree - have similar meanings to those described above.

-
-
-
-

-

The ipsec protocol acts as a plug-in to - the inet(4) and inet6(4) protocols and - therefore supports most of the protocols defined upon those IP-layer - protocols. The icmp(4) and icmp6(4) - protocols may behave differently with ipsec because - ipsec can prevent icmp(4) or - icmp6(4) routines from looking into the IP payload.

-
-
-

-

ioctl(2), socket(2), - ipsec_set_policy(3), crypto(4), - enc(4), icmp6(4), - if_ipsec(4), intro(4), - ip6(4), setkey(8), - sysctl(8)

-

S. Kent and - R. Atkinson, IP Authentication - Header, RFC 2404.

-

S. Kent and - R. Atkinson, IP Encapsulating - Security Payload (ESP), RFC 2406.

-
-
-

-

Daniel L. McDonald, - Craig Metz, and Bao G. - Phan, PF_KEY Key Management API, Version 2, - RFC, 2367.

-

D. L. McDonald, - A Simple IP Security API Extension to BSD Sockets, - internet draft, - draft-mcdonald-simple-ipsec-api-03.txt, - work in progress material.

-
-
-

-

The original ipsec implementation appeared - in the WIDE/KAME IPv6/IPsec stack.

-

For FreeBSD 5.0 a fully locked IPsec - implementation called fast_ipsec was brought in. The protocols drew heavily - on the OpenBSD implementation of the IPsec - protocols. The policy management code was derived from the KAME - implementation found in their IPsec protocols. The fast_ipsec implementation - lacked ip6(4) support but made use of the - crypto(4) subsystem.

-

For FreeBSD 7.0 ip6(4) - support was added to fast_ipsec. After this the old KAME IPsec - implementation was dropped and fast_ipsec became what now is the only - ipsec implementation in - FreeBSD.

-
-
-

-

There is no single standard for the policy engine API, so the - policy engine API described herein is just for this implementation.

-

AH and tunnel mode encapsulation may not work as you might expect. - If you configure inbound “require” policy with an AH tunnel or - any IPsec encapsulating policy with AH (like - “esp/tunnel/A-B/use - ah/transport/A-B/require”), tunnelled packets will be - rejected. This is because the policy check is enforced on the inner packet - on reception, and AH authenticates encapsulating (outer) packet, not the - encapsulated (inner) packet (so for the receiving kernel there is no sign of - authenticity). The issue will be solved when we revamp our policy engine to - keep all the packet decapsulation history.

-

When a large database of security associations or policies is - present in the kernel the SADB_DUMP and - SADB_SPDDUMP operations on - PF_KEY sockets may fail due to lack of space. - Increasing the socket buffer size may alleviate this problem.

-

The IPcomp protocol may occasionally error because of - zlib(3) problems.

-

This documentation needs more review.

-
-
- - - - - -
March 4, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ipw.4 4.html b/static/freebsd/man4/ipw.4 4.html deleted file mode 100644 index 41cfb422..00000000 --- a/static/freebsd/man4/ipw.4 4.html +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - -
IPW(4)Device Drivers ManualIPW(4)
-
-
-

-

ipw — Intel - PRO/Wireless 2100 IEEE 802.11a/b driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ipw -
-device ipwfw -
-device pci -
-device wlan -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ipw_load="YES"
-
-

In both cases, place the following line in - loader.conf(5) to acknowledge the firmware license (see - below):

-
-
legal.intel_ipw.license_ack=1
-
-
-
-

-

The ipw driver provides support for Intel - PRO/Wireless 2100 802.11a/b wireless network devices in - station, adhoc, and - monitor mode operation. Only one virtual interface - may be configured at any time.

-

This driver requires the firmware built with the - ipwfw module to work. For the loaded firmware to be - enabled for use the license at - /usr/share/doc/legal/intel_ipw.LICENSE must be - agreed by adding the following line to loader.conf(5):

-

-
legal.intel_ipw.license_ack=1
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ipw driver provides support for the - Intel PRO/Wireless 2100a/b MiniPCI network adapter.

-
-
-

-
-
/usr/share/doc/legal/intel_ipw.LICENSE
-
ipw firmware license
-
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev ipw0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev ipw0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev ipw0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev ipw0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
ipw%d: device timeout
-
The driver will reset the hardware. This should not happen.
-
ipw%d: firmware error
-
The onboard microcontroller crashes for some reason. The driver will reset - the hardware. This should not happen.
-
ipw%d: timeout waiting for firmware initialization to complete
-
The onboard microcontroller failed to initialize in time. This should not - happen.
-
ipw%d: could not load firmware image '%s'
-
The driver failed to load the firmware image using the - firmware(9) subsystem. Verify the - ipwfw(4) firmware module is installed and the license - agreement loader(8) tunable has been set.
-
ipw%d: could not load microcode
-
An attempt to upload the microcode image to the onboard microcontroller - failed. This should not happen.
-
ipw%d: could not load firmware
-
An attempt to upload the firmware image to the onboard microcontroller - failed. This should not happen.
-
-
-
-

-

ipwfw(4), pci(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - networking(7), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The original ipw driver was written by - Damien Bergamini - <damien.bergamini@free.fr>.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ipwfw.4 4.html b/static/freebsd/man4/ipwfw.4 4.html deleted file mode 100644 index 48325d36..00000000 --- a/static/freebsd/man4/ipwfw.4 4.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
IPWFW(4)Device Drivers ManualIPWFW(4)
-
-
-

-

ipwfw — Firmware - Module for Intel PRO/Wireless 2100 driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device ipwfw
-

This will include three firmware images inside the kernel. If you - want to pick only the firmware image for the mode you want to operate your - network adapter in choose one of the following:

-
device ipwbssfw -
-device ipwibssfw -
-device ipwmonitorfw
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
ipw_bss_load="YES"
-ipw_ibss_load="YES"
-ipw_monitor_load="YES"
-
-
-
-

-

This module provides access to firmware sets for the Intel - PRO/Wireless 2100 series of IEEE 802.11 adapters. It may be statically - linked into the kernel, or loaded as a module.

-

For the loaded firmware to be enabled for use the license at - /usr/share/doc/legal/intel_ipw.LICENSE must be - agreed to by adding the following line to - loader.conf(5):

-

-
legal.intel_ipw.license_ack=1
-
-
-

-
-
/usr/share/doc/legal/intel_ipw.LICENSE
-
ipwfw firmware license
-
-
-
-

-

ipw(4), firmware(9)

-
-
- - - - - -
October 15, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/irdma.4 3.html b/static/freebsd/man4/irdma.4 3.html deleted file mode 100644 index 8fa60be8..00000000 --- a/static/freebsd/man4/irdma.4 3.html +++ /dev/null @@ -1,253 +0,0 @@ - - - - - - -
IRDMA(4)Device Drivers ManualIRDMA(4)
-
-
-

-

irdma — RDMA - FreeBSD driver for Intel(R) Ethernet Controller E810

-
-
-

-

This module relies on ice(4)

-
-
The following kernel options should be included in the configuration:
-
options OFED -
- options OFED_DEBUG_INIT -
- options COMPAT_LINUXKPI -
- options SDP -
- options IPOIB_CM
-
-
-
-

-
-

-

The irdma driver provides RDMA protocol - support on RDMA-capable Intel Ethernet 800 Series NICs which are supported - by ice(4)

-

The driver supports both iWARP and RoCEv2 protocols.

-
-
-
-

-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
dev.irdma<interface_number>.roce_enable
-
enables RoCEv2 protocol usage on <interface_numer> interface. -

By default RoCEv2 protocol is used.

-
-
dev.irdma<interface_number>.dcqcn_cc_cfg_valid
-
indicates that all DCQCN parameters are valid and should be updated in - registers or QP context. -

Setting this parameter to 1 means - that settings in - , - , - , - , - are - taken into account. Otherwise default values are used.

-

Note: "roce_enable" must also be set for this - tunable to take effect.

-
-
dev.irdma<interface_number>.dcqcn_min_dec_factor
-
The minimum factor by which the current transmit rate can be changed when - processing a CNP. Value is given as a percentage (1-100). -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_min_rate_MBps
-
The minimum value, in Mbits per second, for rate to limit. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_F
-
The number of times to stay in each stage of bandwidth recovery. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_T
-
The number of microseconds that should elapse before increasing the CWND - in DCQCN mode. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_B
-
The number of bytes to transmit before updating CWND in DCQCN mode. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_rai_factor
-
The number of MSS to add to the congestion window in additive increase - mode. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_hai_factor
-
The number of MSS to add to the congestion window in hyperactive increase - mode. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
dev.irdma<interface_number>.dcqcn_rreduce_mperiod
-
The minimum time between 2 consecutive rate reductions for a single flow. - Rate reduction will occur only if a CNP is received during the relevant - time interval. -

Note: "roce_enable" and - "dcqcn_cc_cfg_valid" must also be set for this tunable to take - effect.

-
-
-
-
-

-

Sysctl controls are available for runtime adjustments.

-
-
dev.irdma<interface_number>.debug
-
defines level of debug messages. -

Typical value: 1 for errors only, 0x7fffffff for full - debug.

-
-
dev.irdma<interface_number>.dcqcn_enable
-
enables the DCQCN algorithm for RoCEv2. -

Note: "roce_enable" must also be set for this sysctl - to take effect.

-

Note: The change may be set at any time, but it will be - applied only to newly created QPs.

-
-
-
-
-

-
    -
  1. To load the irdma driver, run: -
    - 
    kldload irdma
    -
    - If if_ice is not already loaded, the system will load it on its own. Please - check whether the value of sysctl hw.ice.irdma is 1, - if the irdma driver is not loading. To change the value put: -
    - 
    hw.ice.irdma=1
    -
    - in /boot/loader.conf and reboot.
    2. -
  2. To check that the driver was loaded, run: -
    - 
    sysctl -a | grep infiniband
    -
    - Typically, if everything goes well, around 190 entries per PF will - appear.
    3. -
  3. Each interface of the card may work in either iWARP or RoCEv2 mode. To - enable RoCEv2 compatibility, add: -
    - 
    dev.irdma<interface_number>.roce_enable=1
    -
    - where <interface_number> is a desired ice interface number on which - RoCEv2 protocol needs to be enabled, into: - /boot/loader.conf , for instance: -
    -
    dev.irdma0.roce_enable=0
    -
     
    -
    dev.irdma1.roce_enable=1
    -
     
    -
    - will keep iWARP mode on ice0 and enable RoCEv2 mode on interface ice1. The - RoCEv2 mode is the default. -

    To check irdma roce_enable status, run:

    -
    - 
    sysctl dev.irdma<interface_number>.roce_enable
    -
    - for instance: -
    - 
    sysctl dev.irdma2.roce_enable
    -
    - with returned value of '0' indicate the iWARP mode, and the value of '1' - indicate the RoCEv2 mode. -

    Note: An interface configured in one mode will not be able to - connect to a node configured in another mode.

    -

    Note: RoCEv2 has currently limited support, for functional - testing only. DCB and Priority Flow Controller (PFC) are not currently - supported which may lead to significant performance loss or connectivity - issues.

    -
    4. -
  4. Enable flow control in the ice driver: -
    - 
    sysctl dev.ice.<interface_number>.fc=3
    -
    - Enable flow control on the switch your system is connected to. See your - switch documentation for details.
    5. -
  5. The source code for krping software is provided with the kernel in - /usr/src/sys/contrib/rdma/krping/. To compile the software, change - directory to /usr/src/sys/modules/rdma/krping/ and invoke the following: -
    -
    make clean
    -
     
    -
    make
    -
     
    -
    make install
    -
     
    -
    kldload krping
    -
     
    -
    -
    6. -
  6. Start a krping server on one machine: -
    - 
    echo size=64,count=1,port=6601,addr=100.0.0.189,server > /dev/krping
    -
    -
    7. -
  7. Connect a client from another machine: -
    - 
    echo size=64,count=1,port=6601,addr=100.0.0.189,client > /dev/krping
    -
    -
    8. -
-
-
-
-

-

For general information and support, go to the Intel support - website at: - http://support.intel.com/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - freebsd@intel.com.

-
-
-

-

ice(4)

-
-
-

-

The irdma driver was prepared by - Bartosz Sobczak - <bartosz.sobczak@intel.com>.

-
-
- - - - - -
March 30, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/isci.4 4.html b/static/freebsd/man4/isci.4 4.html deleted file mode 100644 index 101d16f2..00000000 --- a/static/freebsd/man4/isci.4 4.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
ISCI(4)Device Drivers ManualISCI(4)
-
-
-

-

isci — Intel C600 - Serial Attached SCSI driver

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device isci
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
isci_load="YES"
-
-
-
-

-

The isci driver provides support for Intel - C600 SAS controllers.

-
-
-

-

To force legacy interrupts for all isci - driver instances, set the following tunable value in - loader.conf(5):

-
-
hw.isci.force_legacy_interrupts=1
-
-
-
-

-

To enable debugging prints from the isci - driver, set the

-
-
hw.isci.debug_level
-
-

variable to a value between 1 and 4 in - loader.conf(5).

-

The hardware layer in the isci driver has - extensive logging capabilities which are disabled by default for performance - reasons. These can be enabled by adding

-
-
options ISCI_LOGGING
-
-

to the kernel configuration file.

-
-
-

-

cd(4), ch(4), - da(4), pci(4), sa(4), - scsi(4)

-
-
-

-

The isci driver first appeared in - FreeBSD 8.3 and 9.1.

-
-
-

-

The isci driver was developed by Intel and - originally written by Jim Harris - <jimharris@FreeBSD.org> - with contributions from Sohaib Ahsan and input from - Scott Long - <scottl@FreeBSD.org>.

-

This man page was written by Jim Harris - <jimharris@FreeBSD.org>.

-
-
- - - - - -
January 23, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/iscsi.4 3.html b/static/freebsd/man4/iscsi.4 3.html deleted file mode 100644 index a8359e02..00000000 --- a/static/freebsd/man4/iscsi.4 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
ISCSI(4)Device Drivers ManualISCSI(4)
-
-
-

-

iscsi — iSCSI - initiator

-
-
-

-

To compile this driver into the kernel, place the following line - in the kernel configuration file:

-
device iscsi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
iscsi_load="YES"
-
-
-
-

-

The iscsi subsystem provides the kernel - component of an iSCSI initiator, responsible for implementing the Full - Feature Phase of the iSCSI protocol. The initiator is the iSCSI client, - which connects to an iSCSI target, providing local access to a remote block - device. The userland component is provided by iscsid(8) - and both the kernel and userland are configured using - iscsictl(8).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.iscsi.debug
-
Verbosity level for log messages from the iscsi - driver. Set to 0 to disable logging or 1 to warn about potential problems. - Larger values enable debugging output. Defaults to 1.
-
kern.iscsi.ping_timeout
-
The number of seconds to wait for the target to respond to a NOP-Out PDU. - In the event that there is no response within that time the session gets - forcibly restarted. Set to 0 to disable sending NOP-Out PDUs. Defaults to - 5.
-
kern.iscsi.iscsid_timeout
-
The number of seconds to wait for iscsid(8) to establish - a session. After that time iscsi will abort and - retry. Defaults to 60.
-
kern.iscsi.login_timeout
-
The number of seconds to wait for a login attempt to succeed. After that - time iscsi will abort and retry. Defaults to - 60.
-
kern.iscsi.maxtags
-
The maximum number of outstanding IO requests. Defaults to 255.
-
kern.iscsi.fail_on_disconnection
-
Controls the behavior after an iSCSI connection has been dropped due to - network problems. When set to 1, a dropped connection causes the iSCSI - device nodes to be destroyed. After reconnecting, they will be created - again. By default, the device nodes are left intact. While the connection - is down all input/output operations are suspended, to be retried after the - connection is reestablished.
-
-
-
-

-

iser(4), iscsi.conf(5), - iscsictl(8), iscsid(8)

-
-
-

-

The iscsi subsystem first appeared in - FreeBSD 10.0.

-
-
-

-

The iscsi subsystem was developed by - Edward Tomasz Napierala - <trasz@FreeBSD.org> - under sponsorship from the FreeBSD Foundation.

-
-
- - - - - -
May 28, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/iser.4 3.html b/static/freebsd/man4/iser.4 3.html deleted file mode 100644 index bc61e0f5..00000000 --- a/static/freebsd/man4/iser.4 3.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
ISER(4)Device Drivers ManualISER(4)
-
-
-

-

iser — iSCSI - Extensions for RDMA (iSER) driver

-
-
-

-

To compile this driver into the kernel, place the following line - in the kernel configuration file:

-
device iser
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
iser_load="YES"
-
-
-
-

-

The iser (iSCSI Extensions for RDMA) - initiator driver extends the iSCSI protocol to RDMA. It permits data to be - transferred directly into and out of SCSI buffers without intermediate data - copies. iSER uses the RDMA protocol suite to supply higher bandwidth for - block storage transfers (zero copy behavior). To that fact, it eliminates - the TCP/IP processing overhead while preserving the compatibility with iSCSI - protocol. The initiator is the iSCSI/iSER client, which connects to an - iSCSI/iSER target, providing local access to a remote block device. The - userland component is provided by iscsid(8) and both the - kernel and userland are configured using iscsictl(8).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.iser.debug
-
Verbosity level for log messages from the iser - driver. Set to 0 to disable logging or 1 to warn about potential problems. - Larger values enable info and debugging output. Defaults to 0.
-
-
-
-

-

iscsi(4), iscsi.conf(5), - iscsictl(8), iscsid(8)

-
-
-

-

The iser subsystem first appeared in - FreeBSD 11.0.

-
-
-

-

The iser subsystem was developed by - Max Gurtovoy - <maxg@mellanox.com> - and -
- Sagi Grimberg - <sagig@mellanox.com> - under sponsorship from Mellanox Technologies.

-
-
- - - - - -
June 6, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/isl.4 3.html b/static/freebsd/man4/isl.4 3.html deleted file mode 100644 index 0b04d14e..00000000 --- a/static/freebsd/man4/isl.4 3.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - -
ISL(4)Device Drivers ManualISL(4)
-
-
-

-

isl — Intersil(TM) - I2C ISL29018 sensor driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into the kernel configuration file:

-
device isl -
-device ig4 -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
isl_load="YES"
-ig4_load="YES"
-
-

On many Chromebook models this driver can be automatically - configured with the help of the chromebook_platform(4) - driver. Alternatively, the

-
- - - - - -
isldriver can be manually configured in - /boot/device.hints: -
- hint.isl.0.at="iicbus0" -
- hint.isl.0.addr="0x88" -
- hint.isl.1.at="iicbus1" -
- hint.isl.1.addr="0x88"
-
-
-

-

The isl driver provides access to sensor - data provided by the Intersil(TM) I2C ISL29018 Digital Ambient Light Sensor - and Proximity Sensor with Interrupt Function. Functionality is basic and - provided through the sysctl(8) interface.

-

On a system using device.hints(5), these values - are configurable for isl:

-
-
hint.isl.%d.at
-
target iicbus(4).
-
hint.isl.%d.addr
-
isl i2c address on the - iicbus(4).
-
-
-
-

-

The following sysctl(8) variables are - available:

-
-
dev.isl.X.als
-
Current ALS (Ambient Light Sensor) readout.
-
dev.isl.X.ir
-
Current IR (InfraRed) sensor readout.
-
dev.isl.X.prox
-
Current proximity sensor readout.
-
dev.isl.X.resolution
-
Current sensor resolution.
-
dev.isl.X.range
-
Current sensor range.
-
-
-
-

-
-

-
-
$ sysctl dev.isl.0.als
-dev.isl.0.als: 64
-
-
-
-

-

This requires the port - graphics/intel-backlight and only works with laptops - using a supported Intel(R) GPU.

-
-
$ pkg install intel-backlight
-$ sh /usr/local/share/examples/intel-backlight/isl_backlight.sh
-
-
-
-
-

-

chromebook_platform(4), - ig4(4), iicbus(4)

-
-
-

-

The isl driver was written by - Michael Gmelin - <freebsd@grem.de>.

-

This manual page was written by Michael - Gmelin - <freebsd@grem.de>.

-
-
-

-

The isl driver detects the device based - from the I2C address. This might have unforeseen consequences if the - initialization sequence is sent to an unknown device at that address.

-
-
- - - - - -
December 18, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/ismt.4 4.html b/static/freebsd/man4/ismt.4 4.html deleted file mode 100644 index bd6fd28c..00000000 --- a/static/freebsd/man4/ismt.4 4.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
ISMT(4)Device Drivers ManualISMT(4)
-
-
-

-

ismt — Intel SMBus - Message Transport (SMBus 2.0) driver

-
-
-

-

device pci -
- device smbus -
- device smb -
- device ismt

-
-
-

-

This driver provides access to the SMBus 2.0 controller device - contained in the Intel Atom S1200, C2000 and C3000 CPUs.

-
-
-

-

ichsmb(4), smb(4), - smbus(4)

-
-
-

-

The ismt driver first appeared in - FreeBSD 10.3.

-
-
-

-

Jim Harris - <jimharris@FreeBSD.org>

-
-
- - - - - -
March 4, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/isp.4 3.html b/static/freebsd/man4/isp.4 3.html deleted file mode 100644 index 52df9d2c..00000000 --- a/static/freebsd/man4/isp.4 3.html +++ /dev/null @@ -1,266 +0,0 @@ - - - - - - -
ISP(4)Device Drivers ManualISP(4)
-
-
-

-

isp — Qlogic - FibreChannel SCSI Host Adapters driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device isp -
-device ispfw
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
isp_load="YES"
-ispfw_load="YES"
-
-
-
-

-

This driver provides access to FibreChannel SCSI devices.

-

It supports initiator and target modes of FCP SCSI profile, - utilizing Class 3 and Class 2 connections. Support is available for Public - and Private loops, Point-to-Point and Fabric connections.

-

Supported FC-Tape functionality is highly recommended for - connections to tape drives that support it. It encompasses four elements - from the T-10 FCP-4 specification:

-
    -
  • Precise Delivery of Commands
    • -
  • Confirmed Completion of FCP I/O Operations
    • -
  • Retransmission of Unsuccessfully Transmitted IUs
    • -
  • Task Retry Identification
    • -
-

Together these features allow for link level error recovery with - tape devices. Without it, an initiator cannot, for instance, tell whether a - tape write command that has timed out resulted in all, part or none of the - data going to the tape drive. FC-Tape is automatically enabled when - connecting controller that supports it to a target that supports it. It may - be disabled using configuration and hint options described below.

-
-
-

-

The isp driver supports the following - optical Fibre Channel adapters:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Model:Speed:Bus:
Qlogic QLE2874 (2814)64GbPCIe
Qlogic QLE2870/QLE2872 (2812)64GbPCIe
Qlogic QLE2774 (2814)32GbPCIe
Qlogic QLE2770/QLE2772 (2812)32GbPCIe
Qlogic 2740/2742/2764 (2722/2714)32GbPCIe
Qlogic 2690/2692/2694 (2684/2692)16GbPCIe
Qlogic 267x/836x (2031/8031) FCoE16GbPCIe
Qlogic 256x (2532)8GbPCIe
Qlogic 246x (2432)4GbPCIe
Qlogic 24224GbPCI-X
-
-
-

-

Firmware loading is supported and handled by - firmware(9). The correct firmware is either loaded - automatically, if available for this type of adapter, or by manually loading - the ispfw(4) module. It is strongly recommended that you - use the firmware available from ispfw(4) as it is the one - that most likely has been tested with this driver.

-
-
-

-

Target mode support for Fibre Channel adapters may be enabled with - the

-

options ISP_TARGET_MODE

-

option.

-

To disable FC-Tape, use the following configuration option:

-

options ISP_FCTAPE_OFF

-

Note that even if the ISP_FCTAPE_OFF option is used, it may be - overridden by the fctape hint described below.

-
-
-

-

The following options are switchable by setting values in - /boot/device.hints.

-

They are:

-
-
hint.isp.N.msi
-
Limit on number of Message Signaled Interrupts (MSI) to be used.
-
hint.isp.N.msix
-
Limit on number of Extended Message Signaled Interrupts (MSI-X) to be - used.
-
hint.isp.N.fwload_disable
-
A hint value to disable loading of firmware provided by - ispfw(4).
-
hint.isp.N.fwload_force
-
A hint value to prefer firmware provided by ispfw(4), - even if it is older than the firmware in flash on the board. If - fwload_disable is also specified, fwload_force will be ignored. -

By default, with 27XX and newer controllers, the - isp(4) driver will use the newer firmware. For older - controllers, the isp(4) driver will use the firmware - provided by ispfw(4) if it is available, and otherwise - use the firmware in flash on the board.

-
-
hint.isp.N.ignore_nvram
-
A hint value to ignore board NVRAM settings for. Otherwise use NVRAM - settings.
-
hint.isp.N.fullduplex
-
A hint value to set full duplex mode.
-
hint.isp.N.topology
-
A hint value to select topology of connection. Supported values are: -

-
-
-
Prefer arbitrated loop and fallback to point to point.
-
-
Prefer point to point and fallback to arbitrated loop.
-
-
Arbitrated loop only.
-
-
Point to point only.
-
-
-
hint.isp.N.portwwn
-
This should be the full 64 bit World Wide Port Name you would like to use, - overriding the value in NVRAM for the card.
-
hint.isp.N.nodewwn
-
This should be the full 64 bit World Wide Node Name you would like to use, - overriding the value in NVRAM for the card.
-
hint.isp.N.iid
-
A hint to override or set the Initiator ID or Loop ID. For Fibre Channel - cards in Local Loop topologies it is strongly - recommended that you set this value to non-zero.
-
hint.isp.N.role
-
A hint to define default role for isp instance (0 -- none, 1 -- target, 2 - -- initiator, 3 -- both).
-
hint.isp.N.debug
-
A hint value for a driver debug level (see the file - /usr/src/sys/dev/isp/ispvar.h for the values.
-
hint.isp.N.vports
-
A hint to create specified number of additional virtual ports.
-
hint.isp.N.nofctape
-
Set this to 1 to disable FC-Tape operation on the given isp instance.
-
hint.isp.N.fctape
-
Set this to 1 to enable FC-Tape operation on the given isp instance for - targets that support it.
-
-
-
-

-
-
dev.isp.N.loop_down_limit
-
This value says how long to wait in seconds after loop has gone down - before giving up and expiring all of the devices that were visible. The - default is 300 seconds (5 minutes). A separate (nonadjustable) timeout is - used when booting to not stop booting on lack of FC connectivity.
-
dev.isp.N.gone_device_time
-
This value says how long to wait for devices to reappear if they - (temporarily) disappear due to loop or fabric events. While this timeout - is running, I/O to those devices will simply be held.
-
dev.isp.N.use_gff_id
-
 
-
dev.isp.N.use_gft_id
-
Setting those options to 0 allows to disable use of GFF_ID and GFT_ID SNS - requests during FC fabric scan. It may be useful if switch does not - implement them correctly, preventing some devices from being found. - Disabling them may cause unneeded logins to ports not supporting target - role or even FCP at all. The default is 1 (enabled).
-
dev.isp.N.wwnn
-
This is the readonly World Wide Node Name value for this port.
-
dev.isp.N.wwpn
-
This is the readonly World Wide Port Name value for this port.
-
dev.isp.N.fw_version_flash
-
The readonly flash firmware version value in the active region of the - controller.
-
dev.isp.N.fw_version_ispfw
-
The readonly firmware version value provided by - ispfw(4).
-
dev.isp.N.fw_version_run
-
The readonly firmware version value currently executed on the - controller.
-
-
-
-

-

da(4), intro(4), - ispfw(4), sa(4), - scsi(4), gmultipath(8)

-
-
-

-

The isp driver was written by - Matthew Jacob originally for NetBSD at NASA/Ames - Research Center. Later improvement was done by -
- Alexander Motin - <mav@FreeBSD.org>.

-
-
-

-

The driver currently ignores some NVRAM settings.

-
-
- - - - - -
April 8, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ispfw.4 4.html b/static/freebsd/man4/ispfw.4 4.html deleted file mode 100644 index 5baad64e..00000000 --- a/static/freebsd/man4/ispfw.4 4.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -
ISPFW(4)Device Drivers ManualISPFW(4)
-
-
-

-

ispfw — Firmware - for Qlogic FibreChannel SCSI Host Adapters

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ispfw
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ispfw_load="YES"
-
-
-
-

-

This trivial driver provides access to firmware sets for the - Qlogic FibreChannel SCSI Host Adapters. It may either be statically linked - into the kernel, or loaded as a module. In either case, the - isp(4) driver will notice that firmware is available to be - downloaded onto Qlogic cards (to replace the usually out of date firmware on - the cards). This will kick the f/w into getting unstuck.

-
-
-

-

isp(4)

-
-
-

-

This driver was written by Matthew Jacob. - Later improvement was done by -
- Alexander Motin - <mav@FreeBSD.org>.

-
-
- - - - - -
October 27, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/itwd.4 4.html b/static/freebsd/man4/itwd.4 4.html deleted file mode 100644 index 489ad7d0..00000000 --- a/static/freebsd/man4/itwd.4 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
ITWD(4)Device Drivers ManualITWD(4)
-
-
-

-

itwd — device - driver for ITE Super I/O chips watchdog timer

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device superio -
-device itwd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
itwd_load="YES"
-
-
-
-

-

The itwd driver provides - watchdog(4) support for the watchdog timer present on at - least the following Super I/O chips:

-
    -
  • IT8721F
    • -
  • IT8728F
    • -
  • IT8771F
    • -
-
-
-

-

superio(4), watchdog(4), - device.hints(5), watchdog(8), - watchdogd(8), watchdog(9)

-
-
-

-

This manual page was written by Andriy - Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
October 16, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/iwi.4 3.html b/static/freebsd/man4/iwi.4 3.html deleted file mode 100644 index 0f5d68c5..00000000 --- a/static/freebsd/man4/iwi.4 3.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - -
IWI(4)Device Drivers ManualIWI(4)
-
-
-

-

iwi — Intel - PRO/Wireless 2200BG/2225BG/2915ABG IEEE 802.11 network driver

-
-
-

-

To compile this driver into the kernel, include the following - lines in your kernel configuration file:

-
device iwi -
-device iwifw -
-device pci -
-device wlan -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_iwi_load="YES"
-
-

In both cases, place the following line in - loader.conf(5) to acknowledge the firmware license (see - below):

-
-
legal.intel_iwi.license_ack=1
-
-
-
-

-

The iwi driver provides support for Intel - PRO/Wireless 2200BG/2225BG/2915ABG IEEE 802.11a/b/g wireless network devices - in station, adhoc, and - monitor mode operation. Only one virtual interface - may be configured at any time.

-

This driver requires the firmware built with the - iwifw module to work. For the loaded firmware to be - enabled for use the license at - /usr/share/doc/legal/intel_iwi.LICENSE must be - agreed by adding the following line to loader.conf(5):

-

-
legal.intel_iwi.license_ack=1
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The iwi driver supports the following - wireless network devices:

-

-
    -
  • Intel PRO/Wireless 2200BG MiniPCI Network Connection
    • -
  • Intel PRO/Wireless 2225BG PCI Network Connection
    • -
  • Intel PRO/Wireless 2915ABG MiniPCI Network Connection
    • -
-
-
-

-
-
/usr/share/doc/legal/intel_iwi.LICENSE
-
iwi firmware license
-
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev iwi0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev iwi0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev iwi0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev iwi0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
iwi%d: device timeout
-
The driver will reset the hardware. This should not happen.
-
iwi%d: firmware error
-
The onboard microcontroller crashed for some reason. The driver will reset - the hardware. This should not happen.
-
iwi%d: timeout waiting for firmware initialization to complete
-
The onboard microcontroller failed to initialize in time. This should not - happen.
-
iwi%d: could not load firmware image '%s'
-
The driver failed to load the firmware image using the - firmware(9) subsystem. Verify the - iwifw(4) firmware module is installed and the license - agreement loader(8) tunable has been set.
-
iwi%d: could not load boot firmware
-
An attempt to upload the boot firmware image to the onboard - microcontroller failed. This should not happen.
-
iwi%d: could not load microcode
-
An attempt to upload the microcode image to the onboard microcontroller - failed. This should not happen.
-
iwi%d: could not load main firmware
-
An attempt to upload the main firmware image to the onboard - microcontroller failed. This should not happen.
-
-
-
-

-

iwifw(4), pci(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - networking(7), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The original iwi driver was written by - Damien Bergamini - <damien.bergamini@free.fr>.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/iwifw.4 4.html b/static/freebsd/man4/iwifw.4 4.html deleted file mode 100644 index f2d5493a..00000000 --- a/static/freebsd/man4/iwifw.4 4.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
IWIFW(4)Device Drivers ManualIWIFW(4)
-
-
-

-

iwifw — Firmware - Module for Intel PRO/Wireless 2200BG/2225BG/2915ABG driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device iwifw
-

This will include three firmware images inside the kernel. If you - want to pick only the firmware image for the mode you want to operate your - network adapter in choose one of the following:

-
device iwibssfw -
-device iwiibssfw -
-device iwimonitorfw
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
iwi_bss_load="YES"
-iwi_ibss_load="YES"
-iwi_monitor_load="YES"
-
-
-
-

-

This module provides access to firmware sets for the Intel - PRO/Wireless 2200BG/2225BG/2915ABG series of IEEE 802.11 adapters. It may be - statically linked into the kernel, or loaded as a module.

-

For the loaded firmware to be enabled for use the license at - /usr/share/doc/legal/intel_iwi.LICENSE must be - agreed to by adding the following line to - loader.conf(5):

-

-
legal.intel_iwi.license_ack=1
-
-
-

-
-
/usr/share/doc/legal/intel_iwi.LICENSE
-
iwifw firmware license
-
-
-
-

-

iwi(4), firmware(9)

-
-
- - - - - -
October 15, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/iwlwifi.4 3.html b/static/freebsd/man4/iwlwifi.4 3.html deleted file mode 100644 index 57f82100..00000000 --- a/static/freebsd/man4/iwlwifi.4 3.html +++ /dev/null @@ -1,208 +0,0 @@ - - - - - - -
IWLWIFI(4)Device Drivers ManualIWLWIFI(4)
-
-
-

-

iwlwifi — Intel - IEEE 802.11a/b/g/n/ac/ax/be wireless network driver

-
-
-

-

The driver will auto-load without any user interaction using - devmatch(8) if enabled in - rc.conf(5).

-

Only if auto-loading is explicitly disabled, place the following - lines in rc.conf(5) to manually load the driver as a - module at boot time:

-
-
kld_list="${kld_list} if_iwlwifi"
-
-

The driver should automatically load any - iwlwififw(4) firmware needed for the particular chipset. - See section FILES below for how to install - the firmware.

-

It is not possible to load the driver from - loader(8).

-
-
-

-

The iwlwifi driver provides support for - Intel Wireless network devices.

-

iwlwifi is derived from Intel's Linux - iwlwifi driver. The iwm(4) and iwx(4) - drivers together are approximately equivalent to Intel's Linux iwlwifi/mvm - driver.

-

In addition iwlwifi already supports - Intel's Linux iwlwifi/mld chipsets.

-

iwlwifi still complements the - iwn(4) driver which supports older chipsets and would be - equivalent to Intel's Linux iwlwifi/dvm, which - iwlwifi does not support.

-

The driver uses the - - and linuxkpi compat framework to bridge between the Linux - and native FreeBSD driver code as well as to the - native net80211(4) wireless stack.

-
-
-

-

The iwlwifi driver supports PCIe devices - from the - sub-driver with the following chipset generations:

-

-
    -
  • 7000
    • -
  • 8000
    • -
  • 9000
    • -
  • 22000
    • -
  • AX210
    • -
-

The iwlwifi driver supports PCIe - devices from the - sub-driver with the following chipset generations:

-

-
    -
  • BZ
    • -
  • SC
    • -
-

These chipset generations match the following common device - names:

-

-
    -
  • Intel(R) Dual Band Wireless AC 7260
    • -
  • Intel(R) Dual Band Wireless N 7260
    • -
  • Intel(R) Wireless N 7260
    • -
  • Intel(R) Dual Band Wireless AC 3160
    • -
  • Intel(R) Dual Band Wireless N 3160
    • -
  • Intel(R) Wireless N 3160
    • -
  • Intel(R) Dual Band Wireless AC 3165
    • -
  • Intel(R) Dual Band Wireless AC 3168
    • -
  • Intel(R) Dual Band Wireless AC 7265
    • -
  • Intel(R) Wireless N 7265
    • -
  • Intel(R) Dual Band Wireless N 7265
    • -
  • Intel(R) Dual Band Wireless AC 8260
    • -
  • Intel(R) Dual Band Wireless N 8260
    • -
  • Intel(R) Dual Band Wireless AC 4165
    • -
  • Intel(R) Dual Band Wireless AC 8265
    • -
  • Intel(R) Dual Band Wireless AC 8275
    • -
  • Killer (R) Wireless-AC 1550 Wireless Network Adapter (9260NGW) 160MHz
    • -
  • Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
    • -
  • Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
    • -
  • Killer(R) Wireless-AC 1550s Wireless Network Adapter (9560D2W) 160MHz
    • -
  • Killer(R) Wireless-AC 1550i Wireless Network Adapter (9560NGW) 160MHz
    • -
  • Killer(R) Wi-Fi 6E AX1690s 160MHz Wireless Network Adapter (411D2W)
    • -
  • Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
    • -
  • Intel(R) Wireless-AC 9260-1
    • -
  • Intel(R) Wi-Fi 6 AX200 160MHz
    • -
  • Killer(R) Wi-Fi 6 AX1650w 160MHz Wireless Network Adapter (200D2W)
    • -
  • Killer(R) Wi-Fi 6 AX1650x 160MHz Wireless Network Adapter (200NGW)
    • -
  • Intel(R) Wi-Fi 6 AX201 160MHz
    • -
  • Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201D2W)
    • -
  • Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)
    • -
  • Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201NGW)
    • -
  • Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201D2W)
    • -
  • Intel(R) Wi-Fi 6E AX211 160MHz
    • -
  • Intel(R) Wi-Fi 6 AX210 160MHz
    • -
  • Killer(R) Wi-Fi 6E AX1675w 160MHz Wireless Network Adapter (210D2W)
    • -
  • Killer(R) Wi-Fi 6E AX1675x 160MHz Wireless Network Adapter (210NGW)
    • -
  • Intel(R) Wi-Fi 6E AX411 160MHz
    • -
  • Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
    • -
  • Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
    • -
  • Intel(R) Wireless-AC 9461 160MHz
    • -
  • Intel(R) Wireless-AC 9461
    • -
  • Intel(R) Wireless-AC 9462 160MHz
    • -
  • Intel(R) Wireless-AC 9462
    • -
  • Intel(R) Wireless-AC 9560 160MHz
    • -
  • Intel(R) Wireless-AC 9560
    • -
  • Intel(R) Wireless-AC 9270 160MHz
    • -
  • Intel(R) Wireless-AC 9270
    • -
  • Intel(R) Wireless-AC 9162 160MHz
    • -
  • Intel(R) Wireless-AC 9162
    • -
  • Intel(R) Wireless-AC 9260 160MHz
    • -
  • Intel(R) Wireless-AC 9260
    • -
  • Intel(R) Wi-Fi 6 AX101
    • -
  • Intel(R) Wi-Fi 6 AX203
    • -
  • Intel(R) Wi-Fi 6E AX231 160MHz
    • -
  • Intel(R) Wi-Fi 7 BE201 320MHz
    • -
  • Intel(R) Wi-Fi 7 BE200 320MHz
    • -
  • Intel(R) Wi-Fi 7 BE202 160MHz
    • -
  • Intel(R) TBD Sc device
    • -
  • Intel(R) TBD Sc2 device
    • -
  • Intel(R) TBD Sc2f device
    • -
-
-
-

-

The iwlwifi driver supports the following - loader(8) tunable and read-only - sysctl(8) variables:

-
-
compat.linuxkpi.iwlwifi_11n_disable
-
Turn off 802.11n support in the driver. Default - ‘1’.
-
compat.linuxkpi.iwlwifi_disable_11ac
-
Turn off 802.11ac support in the driver. Default - ‘1’.
-
-

The names of the tunables are derived from the Linux iwlwifi - driver module parameters and are mapped automatically by - linuxkpi. They were not adjusted so that they stay - consistent with upstream Linux, e.g., for documentation available and - problem investigations. This left their names inconsistent between - themselves and inconsistent to FreeBSD style.

-

The tunables are automatically adjusted by the firmware package - for chipsets which can enable 11n and 11ac. In case of problems a user may - want to override the provided values in - /boot/loader.conf.local with the above defaults.

-
-
-

-

The iwlwifi driver requires firmware from - ports/net/wifi-firmware-iwlwifi-kmod. This firmware - package will be installed automatically with fwget(8) if - the appropriate hardware is detected at installation or runtime.

-

As a last resort for bootstrapping, individual firmware files can - be manually downloaded, e.g., on a different computer and transferred using - a umass(4) device. The firmware files can be found at - git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git - with names as requested by the driver. Copies should be placed into the - /boot/firmware directory.

-
-
-

-

iwlwififw(4), iwm(4), - iwn(4), iwx(4), - wlan(4), networking(7), - fwget(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The iwlwifi driver first appeared in - FreeBSD 13.1. 802.11n and 802.11ac support for the - 22000 and later chipsets first appeared in FreeBSD - 14.3.

-
-
-

-

iwlwifi - known bugs

-

While iwlwifi supports - 802.11a/b/g/n/ac/ax/be modes, the compatibility code currently only supports - 802.11a/b/g/n/ac modes. 802.11n/ac is only available on the 22000 and later - chipset generations. 802.11ax/be and 6Ghz support are planned.

-
-
- - - - - -
August 19, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/iwlwififw.4 3.html b/static/freebsd/man4/iwlwififw.4 3.html deleted file mode 100644 index ceac34f7..00000000 --- a/static/freebsd/man4/iwlwififw.4 3.html +++ /dev/null @@ -1,9490 +0,0 @@ - - - - - - -
IWLWIFIFW(4)Device Drivers ManualIWLWIFIFW(4)
-
-
-

-

iwlwififw — - Firmware for Intel iwlwifi wireless network - driver

-
-
-

-

The iwlwifi(4) driver should auto-load any - firmware needed. It is discouraged to load the driver or firmware manually - from loader(8).

-
-
-

-

Firmware files are available from ports(7) for - the various chipset models supported by the iwlwifi(4) - driver. Modern chipsets often require a .ucode and - an accompanying .pnvm file.

-

One can use fwget(8) to install the correct - firmware package.

-

The list is provided as a reference as to with file prefix is - needed for a specific card as far as it can be determined and the port - flavor.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Name
VendorDeviceSubv.Subd.FlavorFirmware-Prefix
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x40707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x40727000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x41707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x4c607000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x4c707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x40607000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x406a7000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x41607000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b1any0x40627000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b1any0x41627000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b2any0x42707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b2any0x42727000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b2any0x42607000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b2any0x426a7000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b2any0x42627000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x44707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x44727000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x44607000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x446a7000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b1any0x44627000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x48707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x486e7000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x4a707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x4a6e7000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x4a6c7000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x45707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x45607000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b2any0x43707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b2any0x43607000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x50707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x50727000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x51707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0x57707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x40207000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x402a7000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b2any0x42207000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0x44207000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc0707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc0727000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc1707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc0607000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc06a7000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc1607000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b1any0xc0627000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b1any0xc1627000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc7707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc7607000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b2any0xc2707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xcc707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xcc607000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b2any0xc2727000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b2any0xc2607000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b2any0xc26a7000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b2any0xc2627000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc4707000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc4727000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc4607000iwlwifi-7260
Intel(R) Wireless N 7260
0x80860x08b1any0xc4627000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b1any0xc5707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc5607000iwlwifi-7260
Intel(R) Dual Band Wireless AC 7260
0x80860x08b2any0xc3707000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc3607000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc0207000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc02a7000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b2any0xc2207000iwlwifi-7260
Intel(R) Dual Band Wireless N 7260
0x80860x08b1any0xc4207000iwlwifi-7260
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x00707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x00727000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x01707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x01727000iwlwifi-3160
Intel(R) Dual Band Wireless N 3160
0x80860x08b3any0x00607000iwlwifi-3160
Intel(R) Wireless N 3160
0x80860x08b3any0x00627000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b4any0x02707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b4any0x02727000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x04707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x04727000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b4any0x03707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x80707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x80727000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x81707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x81727000iwlwifi-3160
Intel(R) Dual Band Wireless N 3160
0x80860x08b3any0x80607000iwlwifi-3160
Intel(R) Wireless N 3160
0x80860x08b3any0x80627000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b4any0x82707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b4any0x83707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b4any0x82727000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x84707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x85707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x10707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3160
0x80860x08b3any0x11707000iwlwifi-3160
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x40107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x40127000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3166any0x42127000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x44107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x45107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x41107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3166any0x43107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3166any0x42107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x80107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3165
0x80860x3165any0x81107000iwlwifi-7265D
Intel(R) Dual Band Wireless AC 3168
0x80860x24fbany0x20107000iwlwifi-3168
Intel(R) Dual Band Wireless AC 3168
0x80860x24fbany0x21107000iwlwifi-3168
Intel(R) Dual Band Wireless AC 3168
0x80860x24fbany0x20507000iwlwifi-3168
Intel(R) Dual Band Wireless AC 3168
0x80860x24fbany0x21507000iwlwifi-3168
Intel(R) Dual Band Wireless AC 3168
0x80860x24fbany0000007000iwlwifi-3168
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x50107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x51107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x51007000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x53107000iwlwifi-7265
Intel(R) Wireless N 7265
0x80860x095bany0x53027000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x52107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x5c107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x50127000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x54127000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x54107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x55107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x54007000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x10107000iwlwifi-7265
Intel(R) Dual Band Wireless N 7265
0x80860x095aany0x50007000iwlwifi-7265
Intel(R) Dual Band Wireless N 7265
0x80860x095aany0x500a7000iwlwifi-7265
Intel(R) Dual Band Wireless N 7265
0x80860x095bany0x52007000iwlwifi-7265
Intel(R) Wireless N 7265
0x80860x095aany0x50027000iwlwifi-7265
Intel(R) Wireless N 7265
0x80860x095aany0x51027000iwlwifi-7265
Intel(R) Wireless N 7265
0x80860x095bany0x52027000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x90107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x90127000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x900a7000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x91107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x91127000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x92107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x92007000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x95107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x93107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x94107000iwlwifi-7265
Intel(R) Dual Band Wireless N 7265
0x80860x095aany0x50207000iwlwifi-7265
Intel(R) Dual Band Wireless N 7265
0x80860x095aany0x502a7000iwlwifi-7265
Intel(R) Dual Band Wireless N 7265
0x80860x095aany0x54207000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x50907000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x51907000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x55907000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x52907000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x54907000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x5f107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x52127000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095bany0x520a7000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x90007000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x94007000iwlwifi-7265
Intel(R) Dual Band Wireless AC 7265
0x80860x095aany0x9e107000iwlwifi-7265
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x00108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x10108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x10b08000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x01308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x11308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x01328000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x11328000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x01108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x01f08000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x00128000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x10128000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x11108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x00508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x02508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x10508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x01508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x11508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f4any0x00308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f4any0x10308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xc0108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xc1108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xd0108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xc0508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xd0508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xd0b08000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0xb0b08000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x80108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x81108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x90108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x91108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f4any0x80308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f4any0x90308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f4any0xc0308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f4any0xd0308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x81308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x91308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x81328000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x91328000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x80508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x81508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x90508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x91508000iwlwifi-8000C
Intel(R) Dual Band Wireless N 8260
0x80860x24f3any0x00048000iwlwifi-8000C
Intel(R) Dual Band Wireless N 8260
0x80860x24f3any0x00448000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 4165
0x80860x24f5any0x00108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 4165
0x80860x24f6any0x00308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x08108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x09108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x08508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x09508000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x09308000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8265
0x80860x24f3any0000008000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8260
0x80860x24f3any0x40108000iwlwifi-8000C
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x00108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x01108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x11108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x11308000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x01308000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x10108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x10d08000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x00508000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x01508000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x90108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x81108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x80508000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x80108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x08108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x91108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x81308000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x09108000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x09308000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x09508000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x08508000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x10148000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8275
0x80860x24fdany0x3e028000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8275
0x80860x24fdany0x3e018000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8275
0x80860x24fdany0x10128000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8275
0x80860x24fdany0x00128000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x00148000iwlwifi-8265
Intel(R) Dual Band Wireless AC 8265
0x80860x24fdany0x90748000iwlwifi-8265
(unknown)
0x80860x2526anyany9000(unknown)
(unknown)
0x80860x271banyany9000(unknown)
(unknown)
0x80860x271canyany9000(unknown)
(unknown)
0x80860x30dcanyany9000(unknown)
(unknown)
0x80860x31dcanyany9000(unknown)
(unknown)
0x80860x9df0anyany9000(unknown)
(unknown)
0x80860xa370anyany9000(unknown)
(unknown)
0x80860x02f0anyany22000(unknown)
(unknown)
0x80860x06f0anyany22000(unknown)
(unknown)
0x80860x34f0anyany22000(unknown)
(unknown)
0x80860x3df0anyany22000(unknown)
(unknown)
0x80860x4df0anyany22000(unknown)
(unknown)
0x80860x43f0anyany22000(unknown)
(unknown)
0x80860xa0f0anyany22000(unknown)
(unknown)
0x80860x2723anyany22000(unknown)
(unknown)
0x80860x2725anyanyAX210(unknown)
(unknown)
0x80860x7a70anyanyAX210(unknown)
(unknown)
0x80860x7af0anyanyAX210(unknown)
(unknown)
0x80860x51f0anyanyAX210(unknown)
(unknown)
0x80860x51f1anyanyAX210(unknown)
(unknown)
0x80860x54f0anyanyAX210(unknown)
(unknown)
0x80860x7f70anyanyAX210(unknown)
(unknown)
0x80860x2729anyanyAX210(unknown)
(unknown)
0x80860x7e40anyanyAX210(unknown)
(unknown)
0x80860x2727anyanyBZ(unknown)
(unknown)
0x80860x272danyanyBZ(unknown)
(unknown)
0x80860x272banyanyBZ(unknown)
(unknown)
0x80860xa840any000000BZ(unknown)
(unknown)
0x80860xa840any0x0090BZ(unknown)
(unknown)
0x80860xa840any0x0094BZ(unknown)
(unknown)
0x80860xa840any0x0098BZ(unknown)
(unknown)
0x80860xa840any0x009cBZ(unknown)
(unknown)
0x80860xa840any0x00c0BZ(unknown)
(unknown)
0x80860xa840any0x00c4BZ(unknown)
(unknown)
0x80860xa840any0x00e0BZ(unknown)
(unknown)
0x80860xa840any0x00e4BZ(unknown)
(unknown)
0x80860xa840any0x00e8BZ(unknown)
(unknown)
0x80860xa840any0x00ecBZ(unknown)
(unknown)
0x80860xa840any0x0100BZ(unknown)
(unknown)
0x80860xa840any0x0110BZ(unknown)
(unknown)
0x80860xa840any0x0114BZ(unknown)
(unknown)
0x80860xa840any0x0118BZ(unknown)
(unknown)
0x80860xa840any0x011cBZ(unknown)
(unknown)
0x80860xa840any0x0310BZ(unknown)
(unknown)
0x80860xa840any0x0314BZ(unknown)
(unknown)
0x80860xa840any0x0510BZ(unknown)
(unknown)
0x80860xa840any0x0a10BZ(unknown)
(unknown)
0x80860xa840any0x1671BZ(unknown)
(unknown)
0x80860xa840any0x1672BZ(unknown)
(unknown)
0x80860xa840any0x1771BZ(unknown)
(unknown)
0x80860xa840any0x1772BZ(unknown)
(unknown)
0x80860xa840any0x1791BZ(unknown)
(unknown)
0x80860xa840any0x1792BZ(unknown)
(unknown)
0x80860xa840any0x4090BZ(unknown)
(unknown)
0x80860xa840any0x40c4BZ(unknown)
(unknown)
0x80860xa840any0x40e0BZ(unknown)
(unknown)
0x80860xa840any0x4110BZ(unknown)
(unknown)
0x80860xa840any0x4314BZ(unknown)
(unknown)
0x80860x7740anyanyBZ(unknown)
(unknown)
0x80860x4d40anyanyBZ(unknown)
(unknown)
0x80860xe440anyanySC(unknown)
(unknown)
0x80860xe340anyanySC(unknown)
(unknown)
0x80860xd340anyanySC(unknown)
(unknown)
0x80860x6e70anyanySC(unknown)
Killer (R) Wireless-AC 1550 Wireless Network Adapter (9260NGW) - 160MHz
0x80860x2526any0x1550iwlwifiiwlwifi-9260-th-b0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x80860x2526any0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x80860x2526any0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x80860x30dcany0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x80860x30dcany0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x80860x31dcany0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x80860x31dcany0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x80860xa370any0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x80860xa370any0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wireless-AC 1550s Wireless Network Adapter (9560D2W) - 160MHz
0x80860x54f0any0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x80860x54f0any0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wireless-AC 1550s Wireless Network Adapter (9560D2W) - 160MHz
0x80860x51f0any0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wireless-AC 1550i Wireless Network Adapter (9560NGW) - 160MHz
0x80860x51f0any0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wi-Fi 6E AX1690s 160MHz Wireless Network Adapter (411D2W)
0x80860x51f0any0x1691AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
0x80860x51f0any0x1692AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
0x80860x51f1any0x1692AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690s 160MHz Wireless Network Adapter (411D2W)
0x80860x54f0any0x1691AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
0x80860x54f0any0x1692AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690s 160MHz Wireless Network Adapter (411D2W)
0x80860x7a70any0x1691AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
0x80860x7a70any0x1692AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690s 160MHz Wireless Network Adapter (411D2W)
0x80860x7af0any0x1691AX210iwlwifi-so-a0-gf4-a0
Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
0x80860x7af0any0x1692AX210iwlwifi-so-a0-gf4-a0
Intel(R) Wireless-AC 9260-1
0x80860x271cany0x0214iwlwifiiwlwifi-9260-th-b0-jf-b0
Killer(R) Wi-Fi 6E AX1690s 160MHz Wireless Network Adapter (411D2W)
0x80860x7e40any0x1691AX210(null)
Killer(R) Wi-Fi 6E AX1690i 160MHz Wireless Network Adapter (411NGW)
0x80860x7e40any0x1692AX210(null)
Intel(R) Wi-Fi 6 AX200 160MHz
0x80860x2723anyany22000iwlwifi-cc-a0
Killer(R) Wi-Fi 6 AX1650w 160MHz Wireless Network Adapter (200D2W)
0x80860x2723any0x165322000iwlwifi-cc-a0
Killer(R) Wi-Fi 6 AX1650x 160MHz Wireless Network Adapter (200NGW)
0x80860x2723any0x165422000iwlwifi-cc-a0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x43f0any0x007022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x43f0any0x007422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x43f0any0x007822000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x43f0any0x007c22000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201D2W)
0x80860x43f0any0x165122000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)
0x80860x43f0any0x165222000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x43f0any0x207422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x43f0any0x407022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x007022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x007422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x007822000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x007c22000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x0a1022000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201NGW)
0x80860xa0f0any0x165122000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201D2W)
0x80860xa0f0any0x165222000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x207422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x407022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860xa0f0any0x607422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x007022000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x007422000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x607422000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x007822000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x007c22000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x031022000iwlwifi-QuZ-a0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201D2W)
0x80860x02f0any0x165122000iwlwifi-QuZ-a0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)
0x80860x02f0any0x165222000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x207422000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x02f0any0x407022000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x007022000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x007422000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x007822000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x007c22000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x031022000iwlwifi-QuZ-a0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201D2W)
0x80860x06f0any0x165122000iwlwifi-QuZ-a0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)
0x80860x06f0any0x165222000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x207422000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x06f0any0x407022000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x007022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x007422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x007822000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x007c22000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x031022000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201NGW)
0x80860x34f0any0x165122000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201D2W)
0x80860x34f0any0x165222000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x207422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x34f0any0x407022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x007022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x007422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x007822000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x007c22000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x031022000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201NGW)
0x80860x3df0any0x165122000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201D2W)
0x80860x3df0any0x165222000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x207422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x3df0any0x407022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x007022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x007422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x007822000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x007c22000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x031022000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650s 160MHz Wireless Network Adapter (201NGW)
0x80860x4df0any0x165122000iwlwifi-Qu-b0-hr-b0
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201D2W)
0x80860x4df0any0x165222000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x207422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x407022000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x80860x4df0any0x607422000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x2725any0x0090AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x0020AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x2020AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x0024AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x0310AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x0510AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x0a10AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0xe020AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0xe024AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x4020AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x6020AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6 AX210 160MHz
0x80860x2725any0x6024AX210iwlwifi-ty-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675w 160MHz Wireless Network Adapter (210D2W)
0x80860x2725any0x1673AX210iwlwifi-ty-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675x 160MHz Wireless Network Adapter (210NGW)
0x80860x2725any0x1674AX210iwlwifi-ty-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7a70any0x0090AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7a70any0x0098AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX411 160MHz
0x80860x7a70any0x00b0AX210iwlwifi-so-a0-gf4-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7a70any0x0310AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7a70any0x0510AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7a70any0x0a10AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7af0any0x0090AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7af0any0x0098AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX411 160MHz
0x80860x7af0any0x00b0AX210iwlwifi-so-a0-gf4-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7af0any0x0310AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7af0any0x0510AX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX211 160MHz
0x80860x7af0any0x0a10AX210iwlwifi-so-a0-gf-a0
Killer(R) Wireless-AC 1550s Wireless Network Adapter (9560D2W) - 160MHz
0x80860x7a70any0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wireless-AC 1550i Wireless Network Adapter (9560NGW) - 160MHz
0x80860x7a70any0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wireless-AC 1550s Wireless Network Adapter (9560D2W) - 160MHz
0x80860x7af0any0x1551iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wireless-AC 1550i Wireless Network Adapter (9560NGW) - 160MHz
0x80860x7af0any0x1552iwlwifiiwlwifi-9000-pu-b0-jf-b0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x2726any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x2726any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x51f0any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x51f0any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x51f1any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x51f1any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x54f0any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x54f0any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x7a70any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x7a70any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x7af0any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x7af0any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x7f70any0x1671AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x7f70any0x1672AX210iwlwifi-so-a0-gf-a0
Killer(R) Wi-Fi 6E AX1675s 160MHz Wireless Network Adapter (211NGW)
0x80860x7e40any0x1671AX210(null)
Killer(R) Wi-Fi 6E AX1675i 160MHz Wireless Network Adapter (211NGW)
0x80860x7e40any0x1672AX210(null)
Intel(R) Wireless-AC 9461 160MHz
0x8086anyanyanyiwlwifiiwlwifi-9000-pu-b0-jf-b0
Intel(R) Wireless-AC 9461
0x8086anyanyanyiwlwifiiwlwifi-9000-pu-b0-jf-b0
Intel(R) Wireless-AC 9462 160MHz
0x8086anyanyanyiwlwifiiwlwifi-9000-pu-b0-jf-b0
Intel(R) Wireless-AC 9462
0x8086anyanyanyiwlwifiiwlwifi-9000-pu-b0-jf-b0
Intel(R) Wireless-AC 9560 160MHz
0x8086anyanyanyiwlwifiiwlwifi-9000-pu-b0-jf-b0
Intel(R) Wireless-AC 9560
0x8086anyanyanyiwlwifiiwlwifi-9000-pu-b0-jf-b0
Intel(R) Wireless-AC 9270 160MHz
0x80860x2526anyanyiwlwifiiwlwifi-9260-th-b0-jf-b0
Intel(R) Wireless-AC 9270
0x80860x2526anyanyiwlwifiiwlwifi-9260-th-b0-jf-b0
Intel(R) Wireless-AC 9162 160MHz
0x80860x271banyanyiwlwifiiwlwifi-9260-th-b0-jf-b0
Intel(R) Wireless-AC 9162
0x80860x271banyanyiwlwifiiwlwifi-9260-th-b0-jf-b0
Intel(R) Wireless-AC 9260 160MHz
0x80860x2526anyanyiwlwifiiwlwifi-9260-th-b0-jf-b0
Intel(R) Wireless-AC 9260
0x80860x2526anyanyiwlwifiiwlwifi-9260-th-b0-jf-b0
Intel(R) Wireless-AC 9461 160MHz
0x8086anyanyany22000iwlwifi-Qu-b0-jf-b0
Intel(R) Wireless-AC 9461
0x8086anyanyany22000iwlwifi-Qu-b0-jf-b0
Intel(R) Wireless-AC 9462 160MHz
0x8086anyanyany22000iwlwifi-Qu-b0-jf-b0
Intel(R) Wireless-AC 9462
0x8086anyanyany22000iwlwifi-Qu-b0-jf-b0
Intel(R) Wireless-AC 9560 160MHz
0x8086anyanyany22000iwlwifi-Qu-b0-jf-b0
Intel(R) Wireless-AC 9560
0x8086anyanyany22000iwlwifi-Qu-b0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x8086anyany0x155122000iwlwifi-Qu-b0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x8086anyany0x155222000iwlwifi-Qu-b0-jf-b0
Intel(R) Wireless-AC 9461 160MHz
0x8086anyanyany22000iwlwifi-Qu-c0-jf-b0
Intel(R) Wireless-AC 9461
0x8086anyanyany22000iwlwifi-Qu-c0-jf-b0
Intel(R) Wireless-AC 9462 160MHz
0x8086anyanyany22000iwlwifi-Qu-c0-jf-b0
Intel(R) Wireless-AC 9462
0x8086anyanyany22000iwlwifi-Qu-c0-jf-b0
Intel(R) Wireless-AC 9560 160MHz
0x8086anyanyany22000iwlwifi-Qu-c0-jf-b0
Intel(R) Wireless-AC 9560
0x8086anyanyany22000iwlwifi-Qu-c0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x8086anyany0x155122000iwlwifi-Qu-c0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x8086anyany0x155222000iwlwifi-Qu-c0-jf-b0
Intel(R) Wireless-AC 9461 160MHz
0x8086anyanyany22000iwlwifi-QuZ-a0-jf-b0
Intel(R) Wireless-AC 9461
0x8086anyanyany22000iwlwifi-QuZ-a0-jf-b0
Intel(R) Wireless-AC 9462 160MHz
0x8086anyanyany22000iwlwifi-QuZ-a0-jf-b0
Intel(R) Wireless-AC 9462
0x8086anyanyany22000iwlwifi-QuZ-a0-jf-b0
Intel(R) Wireless-AC 9560 160MHz
0x8086anyanyany22000iwlwifi-QuZ-a0-jf-b0
Intel(R) Wireless-AC 9560
0x8086anyanyany22000iwlwifi-QuZ-a0-jf-b0
Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)
0x8086anyany0x155122000iwlwifi-QuZ-a0-jf-b0
Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)
0x8086anyany0x155222000iwlwifi-QuZ-a0-jf-b0
Intel(R) Wi-Fi 6 AX101
0x8086anyanyany22000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX203
0x8086anyanyany22000iwlwifi-Qu-b0-hr-b0
Intel(R) Wi-Fi 6 AX101
0x8086anyanyany22000iwlwifi-Qu-c0-hr-b0
Intel(R) Wi-Fi 6 AX203
0x8086anyanyany22000iwlwifi-Qu-c0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x8086anyanyany22000iwlwifi-Qu-c0-hr-b0
Intel(R) Wi-Fi 6 AX101
0x8086anyanyany22000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX203
0x8086anyanyany22000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x8086anyanyany22000iwlwifi-QuZ-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x8086anyanyanyAX210(null)
Intel(R) Wi-Fi 6E AX211 160MHz
0x8086anyanyanyAX210(null)
Intel(R) Wi-Fi 6E AX231 160MHz
0x8086anyanyanyAX210(null)
Intel(R) Wi-Fi 6 AX203
0x8086anyanyanyAX210iwlwifi-so-a0-hr-b0
Intel(R) Wi-Fi 6 AX101
0x8086anyanyanyAX210iwlwifi-so-a0-hr-b0
Intel(R) Wi-Fi 6 AX201 160MHz
0x8086anyanyanyAX210iwlwifi-so-a0-hr-b0
Intel(R) Wi-Fi 6E AX211 160MHz
0x8086anyanyanyAX210iwlwifi-so-a0-gf-a0
Intel(R) Wi-Fi 6E AX411 160MHz
0x8086anyanyanyAX210iwlwifi-so-a0-gf4-a0
Intel(R) Wireless-AC 9560 160MHz
0x8086anyanyanyAX210iwlwifi-so-a0-jf-b0
Intel(R) Wireless-AC 9560
0x8086anyanyanyAX210iwlwifi-so-a0-jf-b0
Intel(R) Wireless-AC 9461 160MHz
0x8086anyanyanyAX210iwlwifi-so-a0-jf-b0
Intel(R) Wireless-AC 9462 160MHz
0x8086anyanyanyAX210iwlwifi-so-a0-jf-b0
Intel(R) Wireless-AC 9461
0x8086anyanyanyAX210iwlwifi-so-a0-jf-b0
Intel(R) Wireless-AC 9462
0x8086anyanyanyAX210iwlwifi-so-a0-jf-b0
Intel(R) Wi-Fi 7 BE201 320MHz
0x8086anyanyanyBZ(null)
Intel(R) Wi-Fi 7 BE200 320MHz
0x8086anyanyanyBZ(null)
Intel(R) Wi-Fi 7 BE202 160MHz
0x8086anyanyanyBZ(null)
Intel(R) TBD device
0x8086anyanyanySC(null)
Intel(R) TBD Sc2 device
0x8086anyanyanySC(null)
Intel(R) TBD Sc2f device
0x8086anyanyanySC(null)
-

: - some devices can only be determined correctly at run-time based on hardware - registers (or by other special magic not replicated in the above - listing).

-
-
-

-

A copy of the iwlwifi(4) firmware license is - installed along with the wifi-firmware-iwlwifi-kmod - package or the ports/net/wifi-firmware-iwlwifi-kmod - port (or each of its flavors).

-
-
-

-

iwlwifi(4), fwget(8), - firmware(9)

-
-
-

-

The iwlwififw firmware modules first - appeared in FreeBSD 13.1 and were removed before - FreeBSD 14.3 and replaced by - ports(7) based firmware packages.

-
-
- - - - - -
May 12, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/iwm.4 4.html b/static/freebsd/man4/iwm.4 4.html deleted file mode 100644 index e539fea5..00000000 --- a/static/freebsd/man4/iwm.4 4.html +++ /dev/null @@ -1,161 +0,0 @@ - - - - - - -
IWM(4)Device Drivers ManualIWM(4)
-
-
-

-

iwm — Intel IEEE - 802.11ac wireless network driver

-
-
-

-

To compile this driver into the kernel, include the following - lines in your kernel configuration file:

-
device iwm -
-device pci -
-device wlan -
-device firmware
-

You also need to select a firmware for your device. Choose one - from:

-
device iwm3160fw -
-device iwm3168fw -
-device iwm7260fw -
-device iwm7265fw -
-device iwm7265Dfw -
-device iwm8000Cfw -
-device iwm8265fw -
-device iwm9000fw -
-device iwm9260fw
-

Or you can use

-
device iwmfw
-

to include them all.

-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_iwm_load="YES"
-iwm3160fw_load="YES"
-iwm3168fw_load="YES"
-iwm7260fw_load="YES"
-iwm7265fw_load="YES"
-iwm7265Dfw_load="YES"
-iwm8000Cfw_load="YES"
-iwm8265fw_load="YES"
-iwm9000fw_load="YES"
-iwm9260fw_load="YES"
-
-
-
-

-

The iwm driver supports running most Intel - Wireless AC series network devices in station mode - operation. Only one virtual interface may be configured at any time. This - driver requires the firmware built with the iwmfw(4) - module to work.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The iwm driver supports the following PCIe - Wi-Fi devices:

-

-
    -
  • Intel Dual Band Wireless AC 3160
    • -
  • Intel Dual Band Wireless AC 3165
    • -
  • Intel Dual Band Wireless AC 3168
    • -
  • Intel Dual Band Wireless AC 7260
    • -
  • Intel Dual Band Wireless AC 7265
    • -
  • Intel Dual Band Wireless AC 8260
    • -
  • Intel Dual Band Wireless AC 8265
    • -
  • Intel Dual Band Wireless AC 9260
    • -
  • Intel Dual Band Wireless AC 9270
    • -
  • Intel Dual Band Wireless AC 946X
    • -
  • Intel Dual Band Wireless AC 9560
    • -
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev iwm0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev iwm0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev iwm0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev iwm0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
iwm%d: device timeout
-
The driver will reset the hardware. This should not happen.
-
iwm%d: firmware error
-
The onboard microcontroller crashed for some reason. The driver will reset - the hardware. This should not happen.
-
iwm%d: timeout waiting for firmware initialization to complete
-
The onboard microcontroller failed to initialize in time. This should not - happen.
-
iwm%d: could not load firmware image '%s'
-
The driver failed to load the firmware image using the - firmware(9) subsystem. Verify the - iwmfw(4) firmware module is present.
-
iwm%d: could not load boot firmware
-
An attempt to upload the boot firmware image to the onboard - microcontroller failed. This should not happen.
-
iwm%d: could not load microcode
-
An attempt to upload the microcode image to the onboard microcontroller - failed. This should not happen.
-
iwm%d: could not load main firmware
-
An attempt to upload the main firmware image to the onboard - microcontroller failed. This should not happen.
-
-
-
-

-

iwlwifi(4), iwmfw(4), - pci(4), wlan(4), - wlan_ccmp(4), wlan_tkip(4), - wlan_wep(4), networking(7), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

Currently, iwm only supports 802.11a/b/g - modes. It will not associate to access points that are configured to operate - only in 802.11n/ac modes.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/iwmfw.4 4.html b/static/freebsd/man4/iwmfw.4 4.html deleted file mode 100644 index c0278fea..00000000 --- a/static/freebsd/man4/iwmfw.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
IWMFW(4)Device Drivers ManualIWMFW(4)
-
-
-

-

iwmfw — Firmware - Module for Intel Wireless driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device iwmfw
-

This will include firmware images for all iwm(4) - devices inside the kernel. If you want to pick only the firmware image for - your network adapter choose one of the following:

-
device iwm3160fw -
-device iwm3168fw -
-device iwm7260fw -
-device iwm7265fw -
-device iwm7265Dfw -
-device iwm8000Cfw -
-device iwm8265fw -
-device iwm9000fw -
-device iwm9260fw
-

Alternatively, to load the driver as a module at boot time, place - one of the following lines in loader.conf(5):

-
-
iwm3160fw_load="YES"
-iwm3168fw_load="YES"
-iwm7260fw_load="YES"
-iwm7265fw_load="YES"
-iwm7265Dfw_load="YES"
-iwm8000Cfw_load="YES"
-iwm8265fw_load="YES"
-iwm9000fw_load="YES"
-iwm9260fw_load="YES"
-
-
-
-

-

This module provides access to firmware sets for the Intel Dual - Band Wireless WiFi 3160, 3165, 3168, 7260, 7265, 8000, 8260, 8265, 9000 and - 9260 series of IEEE 802.11n/11ac adapters. It may be statically linked into - the kernel, or loaded as a module.

-
-
-

-

iwm(4), firmware(9)

-
-
- - - - - -
February 4, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/iwn.4 4.html b/static/freebsd/man4/iwn.4 4.html deleted file mode 100644 index 2b4f5e99..00000000 --- a/static/freebsd/man4/iwn.4 4.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - -
IWN(4)Device Drivers ManualIWN(4)
-
-
-

-

iwn — Intel IEEE - 802.11n wireless network driver

-
-
-

-

To compile this driver into the kernel, include the following - lines in your kernel configuration file:

-
device iwn -
-device pci -
-device wlan -
-device firmware
-

You also need to select a firmware for your device. Choose one - from:

-
device iwn1000fw -
-device iwn100fw -
-device iwn105fw -
-device iwn135fw -
-device iwn2000fw -
-device iwn2030fw -
-device iwn4965fw -
-device iwn5000fw -
-device iwn5150fw -
-device iwn6000fw -
-device iwn6000g2afw -
-device iwn6000g2bfw -
-device iwn6050fw
-

Or you can use

-
device iwnfw
-

to include them all.

-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_iwn_load="YES"
-iwn1000fw_load="YES"
-iwn100fw_load="YES"
-iwn105fw_load="YES"
-iwn135fw_load="YES"
-iwn2000fw_load="YES"
-iwn2030fw_load="YES"
-iwn4965fw_load="YES"
-iwn5000fw_load="YES"
-iwn5150fw_load="YES"
-iwn6000fw_load="YES"
-iwn6000g2afw_load="YES"
-iwn6000g2bfw_load="YES"
-iwn6050fw_load="YES"
-
-
-
-

-

The iwn driver supports - station and monitor mode - operation. Only one virtual interface may be configured at any time. For - more information on configuring this device, see - ifconfig(8).

-

This driver requires the firmware built with the - iwnfw module to work.

-
-
-

-

The iwn driver provides support for:

-

-
    -
  • Intel Centrino Advanced-N 6200
    • -
  • Intel Centrino Advanced-N 6205
    • -
  • Intel Centrino Advanced-N 6230
    • -
  • Intel Centrino Advanced-N 6235
    • -
  • Intel Centrino Advanced-N + WiMAX 6250
    • -
  • Intel Centrino Ultimate-N 6300
    • -
  • Intel Centrino Wireless-N 100
    • -
  • Intel Centrino Wireless-N 105
    • -
  • Intel Centrino Wireless-N 130
    • -
  • Intel Centrino Wireless-N 135
    • -
  • Intel Centrino Wireless-N 1000
    • -
  • Intel Centrino Wireless-N 1030
    • -
  • Intel Centrino Wireless-N 2200
    • -
  • Intel Centrino Wireless-N 2230
    • -
  • Intel Centrino Wireless-N 4965
    • -
  • Intel Centrino Wireless-N 5100
    • -
  • Intel Centrino Wireless-N 6150
    • -
  • Intel Centrino Wireless-N 6200
    • -
  • Intel Centrino Wireless-N 6250
    • -
  • Intel Centrino Wireless-N + WiMAX 6150
    • -
  • Intel Ultimate N WiFi Link 5300
    • -
  • Intel Wireless WiFi Link 4965
    • -
  • Intel WiFi Link 5100
    • -
  • Intel WiMAX/WiFi Link 5150
    • -
  • Intel WiMAX/WiFi Link 5350
    • -
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
# ifconfig wlan create wlandev iwn0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - ‘my_net’:

-

-
# ifconfig wlan create wlandev iwn0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
# ifconfig wlan create wlandev iwn0 ssid my_net \
-	wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
# ifconfig wlan create wlandev iwn0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
iwn%d: device timeout
-
The driver will reset the hardware. This should not happen.
-
iwn%d: firmware error
-
The onboard microcontroller crashed for some reason. The driver will reset - the hardware. This should not happen.
-
iwn%d: timeout waiting for firmware initialization to complete
-
The onboard microcontroller failed to initialize in time. This should not - happen.
-
iwn%d: could not load firmware image '%s'
-
The driver failed to load the firmware image using the - firmware(9) subsystem. Verify the - iwnfw(4) firmware module is present.
-
iwn%d: could not load boot firmware
-
An attempt to upload the boot firmware image to the onboard - microcontroller failed. This should not happen.
-
iwn%d: could not load microcode
-
An attempt to upload the microcode image to the onboard microcontroller - failed. This should not happen.
-
iwn%d: could not load main firmware
-
An attempt to upload the main firmware image to the onboard - microcontroller failed. This should not happen.
-
-
-
-

-

iwnfw(4), pci(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - networking(7), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The original iwn driver was written by - Damien Bergamini - <damien.bergamini@free.fr>.

-
-
- - - - - -
October 17, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/iwnfw.4 4.html b/static/freebsd/man4/iwnfw.4 4.html deleted file mode 100644 index a60876b9..00000000 --- a/static/freebsd/man4/iwnfw.4 4.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
IWNFW(4)Device Drivers ManualIWNFW(4)
-
-
-

-

iwnfw — Firmware - Module for Intel Wireless driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device iwnfw
-

This will include firmware images for all iwn(4) - devices inside the kernel. If you want to pick only the firmware image for - your network adapter choose one of the following:

-
device iwn1000fw -
-device iwn100fw -
-device iwn105fw -
-device iwn135fw -
-device iwn2000fw -
-device iwn2030fw -
-device iwn4965fw -
-device iwn5000fw -
-device iwn5150fw -
-device iwn6000fw -
-device iwn6000g2afw -
-device iwn6000g2bfw -
-device iwn6050fw
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
iwn1000fw_load="YES"
-iwn100fw_load="YES"
-iwn105fw_load="YES"
-iwn135fw_load="YES"
-iwn2000fw_load="YES"
-iwn2030fw_load="YES"
-iwn4965fw_load="YES"
-iwn5000fw_load="YES"
-iwn5150fw_load="YES"
-iwn6000fw_load="YES"
-iwn6000g2afw_load="YES"
-iwn6000g2bfw_load="YES"
-iwn6050fw_load="YES"
-
-
-
-

-

This module provides access to firmware sets for the Intel - Wireless WiFi Link 100, 105, 135, 1000, 2000, 2030, 4965, 5000 and 6000 - series of IEEE 802.11n adapters. It may be statically linked into the - kernel, or loaded as a module.

-
-
-

-

iwn(4), firmware(9)

-
-
- - - - - -
August 30, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/iwx.4 3.html b/static/freebsd/man4/iwx.4 3.html deleted file mode 100644 index 33748e80..00000000 --- a/static/freebsd/man4/iwx.4 3.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - -
IWX(4)Device Drivers Manual (amd64)IWX(4)
-
-
-

-

iwx — Intel WiFi 6 - IEEE 802.11ax wireless network driver

-
-
-

-

To compile this driver into the kernel, include the following - lines in your kernel configuration file:

-
device iwx -
-device pci -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_iwx_load="YES"
-
-
-
-

-

The iwx driver supports the Intel Wi-Fi 6 - series of M.2 wireless network adapters. If the appropriate hardware is - detected, and iwlwifi(4) is blacklisted in - rc.conf(5), the driver will be automatically loaded with - devmatch(8). The iwx driver can be - configured at runtime with ifconfig(8) or at boot with - rc.conf(5).

-

These are the modes the iwx driver can - operate in:

-
-
station mode
-
This is used when associating with an access point, through which all - traffic passes. Background scanning is supported in this mode, see - ifconfig(8). Station mode is the default.
-
monitor mode
-
In this mode the driver is able to receive packets without associating - with an access point. This disables the internal receive filter and - enables the card to capture packets from networks which it wouldn't - normally have access to, or to scan for access points.
-
-
-
-

-

The iwx driver supports the following M.2 - wireless network adapters:

-

-
    -
  • Intel Wi-Fi 6 AX200
    • -
  • Intel Wi-Fi 6 AX201 CNVi
    • -
  • Intel Wi-Fi 6 AX210
    • -
  • Intel Wi-Fi 6 AX211 CNVi
    • -
-
-
-

-

The iwx driver supports the following - sysctl(8) variables:

-
-
dev.iwx.?.debug
-
Specify debug level as a bitmask. Default - ‘0’.
-
-
-
-

-

The iwx driver requires firmware from - ports/net/wifi-firmware-iwlwifi-kmod. This firmware - package will be installed automatically with fwget(8) if - the appropriate hardware is detected at installation or runtime.

-
-
-

-
-
iwx0: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
iwx0: fatal firmware error
-
For some reason, the firmware crashed. The driver will reset the hardware. - This should not happen.
-
iwx0: radio is disabled by hardware switch
-
The radio transmitter is off and thus no packet can go out. The driver - will reset the hardware. Make sure the laptop radio switch is on.
-
iwx0: could not read firmware ... (error N)
-
For some reason, the driver was unable to read the firmware image from the - filesystem. The file might be missing or corrupted.
-
iwx0: firmware too short: N bytes
-
The firmware image is corrupted and can't be loaded into the adapter.
-
iwx0: could not load firmware
-
An attempt to load the firmware into the adapter failed. The driver will - reset the hardware.
-
-
-
-

-

intro(4), iwlwifi(4), - iwlwififw(4), wlan(4), - networking(7), fwget(8), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

The iwx driver appeared in - FreeBSD 15.0.

-
-
-

-

The iwx driver does not support hardware - encryption offload.

-

The iwx driver does not support 802.11ax. - Additional work is required in ieee80211(9) before those - features can be supported.

-
-
- - - - - -
November 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ix.4 3.html b/static/freebsd/man4/ix.4 3.html deleted file mode 100644 index 95e03345..00000000 --- a/static/freebsd/man4/ix.4 3.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - -
IX(4)Device Drivers ManualIX(4)
-
-
-

-

ix — Intel 10Gb - Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device ix
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ix_load="YES"
-
-
-
-

-

The ix driver provides support for - Intel(R) 10Gb Ethernet PCIe adapters. The driver supports Jumbo Frames, - MSIX, TSO, and RSS.

-

For questions related to hardware requirements, refer to the - documentation supplied with your Intel 10GbE adapter. All hardware - requirements listed apply to use with FreeBSD.

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 9710.

-

This driver version supports VLANs. For information on enabling - VLANs, see ifconfig(8).

-
-
-

-

The ix driver supports Intel 10Gb Ethernet - PCIe adapters, including:

-

-
    -
  • Intel(R) Ethernet E610
    • -
  • Intel(R) Ethernet X553
    • -
  • Intel(R) Ethernet X552
    • -
  • Intel(R) Ethernet X550
    • -
  • Intel(R) Ethernet X540 Bypass
    • -
  • Intel(R) Ethernet X540
    • -
  • Intel(R) Ethernet X520 Bypass (82599)
    • -
  • Intel(R) Ethernet X520 (82599)
    • -
  • Intel(R) 10 Gigabit Server Adapter (82598EB)
    • -
-
-
-

-

The ix driver supports the following - loader tunables:

-
-
hw.ix.max_interrupt_rate
-
Maximum interrupts per second.
-
hw.ix.flow_control
-
Default flow control used for all adapters.
-
hw.ix.advertise_speed
-
Default advertised speed for all adapters.
-
hw.ix.enable_msix
-
Enable Message Signalled Interrupts (MSI-X).
-
hw.ix.allow_unsupported_sfp
-
Allow unsupported small form-factor pluggable (SFP) modules. Use at your - own risk.
-
hw.ix.enable_fdir
-
Enable Flow Director. Flow Director directs Ethernet packets to the core - where the packet consuming process, application, container, or - microservice is running.
-
hw.ix.enable_rss
-
Enable Receive-Side Scaling (RSS). When RSS is enabled, all of the receive - data processing for a particular TCP connection is shared across multiple - processors or processor cores. Without RSS, all of the processing is - performed by a single processor, resulting in inefficient system cache - utilization. This has no effect if your system has only one processing - unit.
-
hw.ix.enable_aim
-
Enable Adaptive Interrupt Moderation (AIM). Vary the interrupt rate over - time based on the traffic for that interrupt vector.
-
-
-
-

-

The ix driver supports the following - sysctl(8) variables:

-
-
dev.ix.?.debug.dump.clusters
-
Specify a bitmask to select firmware event clusters to be included in the - debug dump. Possible values include: -

-
-
0
-
All clusters excluding Manageability Transactions
-
0x1
-
Link cluster
-
0x2
-
Full CSR Space excluding RCW registers
-
-

This feature is only supported on E610 devices.

-
-
dev.ix.?.debug.dump.dump
-
Specify 1 to generate a per-device debugging snapshot. Output must be - redirected to a file and decoded by Intel Customer Support. -

This feature is only supported on E610.

-
-
dev.ix.?.debug.fw_log.severity.<module>
-
Specify firmware logging verbosity level for the specified module. - Available levels include: -

-
-
0
-
none
-
1
-
error
-
2
-
warning
-
3
-
normal
-
4
-
verbose
-
-

Supported modules: general, ctrl, link, link_topo, dnl, i2c, - sdp, mdio, adminq, hdma, lldp, dcbx, dcb, xlr, nvm, auth, vpd, iosf, - parser, sw, scheduler, txq, acl, post, watchdog, task_dispatch, mng, - synce, health, tsdrv, pfreg, mdlver.

-

This feature is only supported on E610 devices.

-
-
dev.ix.?.debug.fw_log.register
-
Specify 1 to apply per-device firmware logging configuration. -

This feature is only supported on E610 devices.

-
-
dev.ix.?.debug.fw_log.on_load
-
Enable firmware logging during driver initialization when set via - kenv(1). -

This feature is only supported on E610 devices.

-
-
-
-
-

-
-
ix%d: Unable to allocate bus resource: memory
-
A fatal initialization error has occurred.
-
ix%d: Unable to allocate bus resource: interrupt
-
A fatal initialization error has occurred.
-
ix%d: watchdog timeout -- resetting
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

For general information and support, go to the Intel support - website at: http://support.intel.com.

-

If an issue is identified with the released source code on the - supported kernel with a supported adapter, email the specific information - related to the issue to - <freebsd@intel.com>.

-
-
-

-

altq(4), arp(4), - iflib(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8), - sysctl(8)

-
-
-

-

The ix device driver first appeared in - FreeBSD 7.0.

-
-
-

-

The ix driver was written by - Intel Corporation - <freebsd@intel.com>.

-
-
-

-

Intel (R) Flow director support is not fully implemented in - FreeBSD at this time and additional work is required - before those features can be supported.

-

Enabling flow director may route traffic to the wrong RX queue of - the NIC, resulting in sub-optimal performance on the receive side.

-
-
- - - - - -
November 10, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ixl.4 3.html b/static/freebsd/man4/ixl.4 3.html deleted file mode 100644 index f730bf63..00000000 --- a/static/freebsd/man4/ixl.4 3.html +++ /dev/null @@ -1,261 +0,0 @@ - - - - - - -
IXL(4)Device Drivers ManualIXL(4)
-
-
-

-

ixl — Intel - Ethernet 700 Series Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device ixl
-

To load the driver as a module at boot time, place the following - lines in loader.conf(5):

-
-
if_ixl_load="YES"
-
-
-
-

-
-

-

The ixl driver provides support for any - PCI Express adapter or LOM (LAN On Motherboard) in the Intel Ethernet 700 - Series. As of this writing, the series includes devices with these model - numbers:

-

-
    -
  • XL710 (40G)
    • -
  • X710 (10G)
    • -
  • XXV710 (25G)
    • -
  • X722 (10G)
    • -
-

The driver supports Jumbo Frames, TX/RX checksum offload, TCP - segmentation offload (TSO), Large Receive Offload (LRO), VLAN tag - insertion/extraction, VLAN checksum offload, VLAN TSO, and Receive Side - Steering (RSS), all for both IPv4 and IPv6. For further hardware information - and questions related to hardware requirements, see - http://support.intel.com/.

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 9706.

-

Offloads are also controlled via the interface, for instance, - checksumming for both IPv4 and IPv6 can be set and unset, TSO4 and/or TSO6, - and finally LRO can be set and unset.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

There are additional tools available from Intel to help configure - and update the adapters covered by this driver. These tools can be - downloaded directly from Intel at - https://downloadcenter.intel.com, - by searching for their names, or by installing certain packages:

- -
-
-
-

-

The ixl driver supports the Intel Ethernet - 700 series. Most adapters in this series with SFP+/SFP28/QSFP+ cages have - firmware that requires that Intel qualified modules are used; these - qualified modules are listed below. This qualification check cannot be - disabled by the driver.

-

The ixl driver supports 40Gb Ethernet - adapters with these QSFP+ modules:

-

-
    -
  • Intel 4x10G/40G QSFP+ 40GBASE-SR4 E40GQSFPSR
    • -
  • Intel 4x10G/40G QSFP+ 40GBASE-LR4 E40GQSFPLR
    • -
-

The ixl driver supports 25Gb Ethernet - adapters with these SFP28 modules:

-

-
    -
  • Intel 10G/25G SFP28 25GBASE-SR E25GSFP28SR
    • -
  • Intel 10G/25G SFP28 25GBASE-SR E25GSFP28SRX (Extended Temp)
    • -
-

The ixl driver supports 25Gb and 10Gb - Ethernet adapters with these SFP+ modules:

-

-
    -
  • Intel 1G/10G SFP+ SR FTLX8571D3BCV-IT
    • -
  • Intel 1G/10G SFP+ SR AFBR-703SDZ-IN2
    • -
  • Intel 1G/10G SFP+ LR FTLX1471D3BCV-IT
    • -
  • Intel 1G/10G SFP+ LR AFCT-701SDZ-IN2
    • -
  • Intel 1G/10G SFP+ 10GBASE-SR E10GSFPSR
    • -
  • Intel 10G SFP+ 10GBASE-SR E10GSFPSRX (Extended Temp)
    • -
  • Intel 1G/10G SFP+ 10GBASE-LR E10GSFPLR
    • -
-

Note that adapters also support all passive and active limiting - direct attach cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 - specifications.

-

This is not an exhaustive list; please consult product - documentation for an up-to-date list of supported media.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.ixl.rx_itr
-
The RX interrupt rate value, set to 62 (124 usec) by default.
-
hw.ixl.tx_itr
-
The TX interrupt rate value, set to 122 (244 usec) by default.
-
hw.ixl.i2c_access_method
-
Access method that driver will use for I2C read and writes via - sysctl(8) or verbose ifconfig(8) - information display: -
- 
0 - best available method
-1 - bit bang via I2CPARAMS register
-2 - register read/write via I2CCMD register
-3 - Use Admin Queue command (default best)
-
-

Using the Admin Queue is only supported on 710 devices with FW - version 1.7 or newer. Set to 0 by default.

-
-
hw.ixl.enable_tx_fc_filter
-
Filter out packets with Ethertype 0x8808 from being sent out by - non-adapter sources. This prevents (potentially untrusted) software or - iavf(4) devices from sending out flow control packets - and creating a DoS (Denial of Service) event. Enabled by default.
-
hw.ixl.enable_head_writeback
-
When the driver is finding the last TX descriptor processed by the - hardware, use a value written to memory by the hardware instead of - scanning the descriptor ring for completed descriptors. Enabled by - default; disable to mimic the TX behavior found in - ix(4).
-
-
-
-

-
-
dev.ixl.#.fc
-
Sets the 802.3x flow control mode that the adapter will advertise on the - link. A value of 0 disables flow control, 3 enables full, 1 is RX, and 2 - is TX pause. -

The negotiated flow control setting can be viewed in - ifconfig(8), in the interface's media field.

-
-
dev.ixl.#.advertise_speed
-
Set the speeds that the interface will advertise on the link. - dev.ixl.#.supported_speeds contains the speeds that - are allowed to be set.
-
dev.ixl.#.current_speed
-
Displays the current speed.
-
dev.ixl.#.fw_version
-
Displays the current firmware and NVM versions of the adapter.
-
dev.ixl.#.debug.switch_vlans
-
Set the Ethertype used by the hardware itself to handle internal services. - Frames with this Ethertype will be dropped without notice. Defaults to - 0x88a8, which is a well known number for IEEE - 802.1ad VLAN stacking. If you need 802.1ad support, set this number to any - another Ethertype i.e. 0xffff.
-
-
-
-

-

It is important to note that 40G operation can generate high - numbers of interrupts, often incorrectly being interpreted as a storm - condition in the kernel. It is suggested that this be resolved by - setting:

-
-
hw.intr_storm_threshold: - 0
-
 
-
-
-
-

-

The driver supports additional optional parameters for created VFs - (Virtual Functions) when using iovctl(8):

-
-
mac-addr (unicast-mac)
-
Set the Ethernet MAC address that the VF will use. If unspecified, the VF - will use a randomly generated MAC address.
-
mac-anti-spoof (bool)
-
Prevent the VF from sending Ethernet frames with a source address that - does not match its own.
-
allow-set-mac (bool)
-
Allow the VF to set its own Ethernet MAC address
-
allow-promisc (bool)
-
Allow the VF to inspect all of the traffic sent to the port.
-
num-queues (uint16_t)
-
Specify the number of queues the VF will have. By default, this is set to - the number of MSI-X vectors supported by the VF minus one.
-
-

An up to date list of parameters and their defaults can be found - by using iovctl(8) with the -S option.

-
-
-

-

For general information and support, go to the Intel support - website at: - http://support.intel.com/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - freebsd@intel.com.

-
-
-

-

arp(4), iavf(4), - iflib(4), netintro(4), - vlan(4), ifconfig(8), - iovctl(8)

-
-
-

-

The ixl device driver first appeared in - FreeBSD 10.1. It was converted to use - iflib(9) in FreeBSD 12.

-
-
-

-

The ixl driver was written by - Jack Vogel - <jfv@freebsd.org> and - Eric Joyner - <erj@freebsd.org>.

-
-
- - - - - -
August 1, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/jedec_dimm.4 3.html b/static/freebsd/man4/jedec_dimm.4 3.html deleted file mode 100644 index 71cd7359..00000000 --- a/static/freebsd/man4/jedec_dimm.4 3.html +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - -
JEDEC_DIMM(4)Device Drivers ManualJEDEC_DIMM(4)
-
-
-

-

jedec_dimm — - report asset information and temperatures for JEDEC DDR3 / - DDR4 DIMMs

-
-
-

-
device jedec_dimm -
-device smbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
jedec_dimm_load="YES"
-
-

Addressing information must be manually specified in - /boot/device.hints:

-
-
hint.jedec_dimm.0.at="smbus0"
-

-hint.jedec_dimm.0.addr="0xa0"
-

-hint.jedec_dimm.0.slotid="Silkscreen"
-
-
-
-

-

The jedec_dimm driver reports asset - information (Part Number, Serial Number) encoded in the “Serial - Presence Detect” (SPD) data on JEDEC DDR3 and DDR4 DIMMs. It also - calculates and reports the memory capacity of the DIMM, in megabytes. If the - DIMM includes a “Thermal Sensor On DIMM” (TSOD), the - temperature is also reported.

-

The jedec_dimm driver accesses the SPD and - TSOD over the smbus(4).

-

The data is reported via a sysctl(8) interface; - all values are read-only:

-
-
dev.jedec_dimm.X.%desc
-
a string description of the DIMM, including TSOD and slotid info if - present.
-
dev.jedec_dimm.X.capacity
-
the DIMM's memory capacity, in megabytes
-
dev.jedec_dimm.X.mfg_week
-
the week within the year in which the DIMM was manufactured
-
dev.jedec_dimm.X.mfg_year
-
the year in which the DIMM was manufactured
-
dev.jedec_dimm.X.part
-
the manufacturer's part number of the DIMM
-
dev.jedec_dimm.X.serial
-
the manufacturer's serial number of the DIMM
-
dev.jedec_dimm.X.slotid
-
a copy of the corresponding hint, if set
-
dev.jedec_dimm.X.temp
-
if a TSOD is present, the reported temperature
-
dev.jedec_dimm.X.type
-
the DIMM type (DDR3 or DDR4)
-
-

These values are configurable for - jedec_dimm via - device.hints(5):

-
-
hint.jedec_dimm.X.at
-
the smbus(4) to which the DIMM is connected
-
hint.jedec_dimm.X.addr
-
the SMBus address of the SPD. JEDEC specifies that the four - most-significant bits of the address are the “Device Type - Identifier” (DTI), and that the DTI of the SPD is 0xa. Since the - least-significant bit of an SMBus address is the read/write bit, and is - always written as 0, that means the four least-significant bits of the - address must be even.
-
hint.jedec_dimm.X.slotid
-
optional slot identifier. If populated with the DIMM slot name - silkscreened on the motherboard, this provides a mapping between the DIMM - slot name and the DIMM serial number. That mapping is useful for detailed - asset tracking, and makes it easier to physically locate a specific DIMM - when doing a replacement. This is useful when assembling multiple - identical systems, as might be done by a system vendor. The mapping - between bus/address and DIMM slot must first be determined, either through - motherboard documentation or trial-and-error.
-
-

If the DIMMs are on an I2C bus behind an - iicbus(4) controller, then the iicsmb(4) - bridge driver can be used to attach the smbus(4).

-
-
-

-

Consider two DDR4 DIMMs with the following hints:

-
-
hint.jedec_dimm.0.at="smbus0"
-hint.jedec_dimm.0.addr="0xa0"
-hint.jedec_dimm.0.slotid="A1"
-
-hint.jedec_dimm.6.at="smbus1"
-hint.jedec_dimm.6.addr="0xa8"
-
-

Their sysctl(8) output (sorted):

-
-
dev.jedec_dimm.0.%desc: DDR4 DIMM w/ Atmel TSOD (A1)
-dev.jedec_dimm.0.%driver: jedec_dimm
-dev.jedec_dimm.0.%location: addr=0xa0
-dev.jedec_dimm.0.%parent: smbus0
-dev.jedec_dimm.0.%pnpinfo:
-dev.jedec_dimm.0.capacity: 16384
-dev.jedec_dimm.0.mfg_week: 30
-dev.jedec_dimm.0.mfg_year: 17
-dev.jedec_dimm.0.part: 36ASF2G72PZ-2G1A2
-dev.jedec_dimm.0.serial: 0ea815de
-dev.jedec_dimm.0.slotid: A1
-dev.jedec_dimm.0.temp: 32.7C
-dev.jedec_dimm.0.type: DDR4
-
-dev.jedec_dimm.6.%desc: DDR4 DIMM w/ TSE2004av compliant TSOD
-dev.jedec_dimm.6.%driver: jedec_dimm
-dev.jedec_dimm.6.%location: addr=0xa8
-dev.jedec_dimm.6.%parent: smbus1
-dev.jedec_dimm.6.%pnpinfo:
-dev.jedec_dimm.6.capacity: 8192
-dev.jedec_dimm.6.mfg_week: 13
-dev.jedec_dimm.6.mfg_year: 19
-dev.jedec_dimm.6.part: VRA9MR8B2H1603
-dev.jedec_dimm.6.serial: 0c4c46ad
-dev.jedec_dimm.6.temp: 43.1C
-dev.jedec_dimm.6.type: DDR4
-
-

You can use smbmsg(8) to probe for devices.

-
-
-

-

jedec_dimm implements a superset of the - functionality of the now-deleted jedec_ts(4). Hints for - jedec_ts(4) can be mechanically converted for use with - jedec_dimm. Two changes are required:

-
    -
  1. In all jedec_ts(4) hints, replace - “jedec_ts” with “jedec_dimm”
    2. -
  2. In jedec_ts(4) “addr” hints, replace the - TSOD DTI “0x3” with the SPD DTI “0xa”
    3. -
-

The following sed(1) script will perform the - necessary changes:

-
-
sed -i ".old" -e 's/jedec_ts/jedec_dimm/' \
-    -e '/jedec_dimm/s/addr="0x3/addr="0xa/' /boot/device.hints
-
-
-
-

-

iicbus(4), iicsmb(4), - smbus(4), sysctl(8)

-
-
-

-

(DDR3 SPD) JEDEC, - Standard 21-C, Annex K.

-

(DDR3 TSOD) JEDEC, - Standard 21-C, TSE2002av.

-

(DDR4 SPD) JEDEC, - Standard 21-C, Annex L.

-

(DDR4 TSOD) JEDEC, - Standard 21-C, TSE2004av.

-
-
-

-

The jedec_dimm driver first appeared in - FreeBSD 12.0.

-
-
-

-

The jedec_dimm driver and this manual page - were written by Ravi Pokala - <rpokala@freebsd.org>. - They are both based in part on the now-deleted jedec_ts(4) - driver and manual page, written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
January 2, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/jme.4 3.html b/static/freebsd/man4/jme.4 3.html deleted file mode 100644 index f9142b19..00000000 --- a/static/freebsd/man4/jme.4 3.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
JME(4)Device Drivers ManualJME(4)
-
-
-

-

jme — JMicron - Gigabit/Fast Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device jme
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_jme_load="YES"
-
-
-
-

-

The jme device driver provides support for - JMicron JMC25x PCI Express Gigabit Ethernet controllers and JMicron JMC26x - PCI Express Fast Ethernet controllers.

-

All LOMs supported by the jme driver have - TCP/UDP/IP checksum offload for both transmit and receive, TCP segmentation - offload (TSO), hardware VLAN tag stripping/insertion features, Wake On Lan - (WOL) and an interrupt coalescing/moderation mechanism as well as a 64-bit - multicast hash filter.

-

The JMC25x also supports Jumbo Frames (up to 9216 bytes), which - can be configured via the interface MTU setting. Selecting an MTU larger - than 1500 bytes with the ifconfig(8) utility configures - the adapter to receive and transmit Jumbo Frames.

-

The jme driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-
Set 1000baseTX operation over twisted pair.
-
-

The jme driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The jme device driver provides support for - the following Ethernet controllers:

-

-
    -
  • JMicron JMC250 PCI Express Gigabit Ethernet controller
    • -
  • JMicron JMC251 PCI Express Gigabit Ethernet with Card Read Host - controller
    • -
  • JMicron JMC260 PCI Express Fast Ethernet controller
    • -
  • JMicron JMC261 PCI Express Gigabit Ethernet with Card Read Host - controller
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.jme.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
hw.jme.msix_disable
-
This tunable disables MSI-X support on the Ethernet hardware. The default - value is 0.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.jme.%d.tx_coal_to
-
This variable sets the maximum amount of time to delay before sending a Tx - completion interrupt, in microseconds. The accepted range is 1 to 65535; - the default is 100 (100us).
-
dev.jme.%d.tx_coal_pkt
-
This variable sets the maximum number of outgoing packets which may be - coalesced together into a single Tx completion interrupt. The accepted - range is 1 to 255; the default is 8.
-
dev.jme.%d.rx_coal_to
-
This variable sets the maximum amount of time to wait for additional - packets to arrive (for possible packet coalescing) before firing an Rx - completion interrupt, in microseconds. The accepted range is 1 to 65535; - the default is 100 (100us).
-
dev.jme.%d.rx_coal_pkt
-
This variable sets the maximum number of incoming packets which may be - coalesced into a single Rx completion interrupt. The accepted range is 1 - to 255; the default is 2.
-
dev.jme.%d.process_limit
-
This variable sets the maximum number of events that will be processed in - a single batch before the handler is requeued into a taskqueue. The - accepted range is 10 to 255; the default value is 128 events. The - interface does not need to be brought down and up again before a change - takes effect.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The jme driver was written by - Pyun YongHyeon - <yongari@FreeBSD.org>. - It first appeared in FreeBSD 7.1.

-
-
-

-

The jme driver tries to avoid unnecessary - station address reprogramming for controllers that use eFuse to store - station address. The number of times that eFuse can be safely reprogrammed - is 16 at most. In addition, there is no way to restore the factory default - station address once the station address has been reprogrammed via eFuse. It - is highly recommended not to reprogram the station address and it is the - responsibility of the administrator to store the original station address in - a safe place when station address is changed.

-

There are two known 1000baseT link establishment issues with - JMC25x. If the full mask revision number of JMC25x controller is less than - or equal to 4 and the link partner enabled the IEEE 802.3az Energy Efficient - Ethernet feature, the controller will not be able to establish a 1000baseT - link. Also, if the length of the cable is longer than 120 meters, the - controller can not establish a 1000baseT link. The known workaround for - these issues is to force manual link configuration with 100baseTX instead of - relying on auto-negotiation. The full mask revision number of controller can - be checked with the verbose kernel boot option. Use the lower nibble of the - chip revision number to get the full mask revision of the controller.

-
-
- - - - - -
March 4, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/kbdmux.4 4.html b/static/freebsd/man4/kbdmux.4 4.html deleted file mode 100644 index f55a4124..00000000 --- a/static/freebsd/man4/kbdmux.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
KBDMUX(4)Device Drivers ManualKBDMUX(4)
-
-
-

-

kbdmux — keyboard - multiplexer

-
-
-

-

device kbdmux

-

In /boot/device.hints: -
- hint.kbdmux.0.disabled="1"

-
-
-

-

The kbdmux keyboard driver provides - support for basic keyboard multiplexing. It is built around the idea of a - “super keyboard”. The kbdmux driver - acts as a master keyboard consuming input from all slave keyboards attached - to it.

-

Slave keyboards can be attached to or detached from the - kbdmux keyboard driver with the - kbdcontrol(1) utility.

-
-
-

-

kbdcontrol(1), atkbd(4), - syscons(4), ukbd(4), - vt(4)

-
-
-

-

The kbdmux module was implemented in - FreeBSD 6.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

The kbdmux keyboard driver switches all - slave keyboards into K_RAW mode. Thus all slave - keyboards attached to the kbdmux keyboard share the - same state. The kbdmux keyboard is logically - equivalent to one keyboard with lots of duplicated keys.

-
-
- - - - - -
July 12, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/kcov.4 3.html b/static/freebsd/man4/kcov.4 3.html deleted file mode 100644 index 8a4abc0d..00000000 --- a/static/freebsd/man4/kcov.4 3.html +++ /dev/null @@ -1,172 +0,0 @@ - - - - - - -
KCOV(4)Device Drivers ManualKCOV(4)
-
-
-

-

kcov — interface - for collecting kernel code coverage information

-
-
-

-

To compile KCOV into the kernel, place the following lines in your - kernel configuration file:

-
options COVERAGE -
-options KCOV
-

The following header file defines the application interface - provided by KCOV:

-

-
- #include <sys/kcov.h>

-
-
-

-

kcov is a module that enables collection - of code coverage information from the kernel. It relies on code - instrumentation enabled by the COVERAGE kernel - option. When kcov is enabled by a user-mode thread, - it collects coverage information only for that thread, excluding hard - interrupt handlers. As a result, kcov is not suited - to collect comprehensive coverage data for the entire kernel; its main - purpose is to provide input for coverage-guided system call fuzzers.

-

In typical usage, a user-mode thread first allocates a chunk of - memory to be shared with kcov. The thread then - enables coverage tracing, with coverage data being written by the kernel to - the shared memory region. When tracing is disabled, the kernel relinquishes - its access to the shared memory region, and the written coverage data may be - consumed.

-

The shared memory buffer can be treated as a 64-bit unsigned - integer followed by an array of records. The integer records the number of - valid records and is updated by the kernel as coverage information is - recorded. The state of the tracing buffer can be reset by writing the value - 0 to this field. The record layout depends on the tracing mode set using the - KIOENABLE ioctl.

-

Two tracing modes are implemented, - KCOV_MODE_TRACE_PC and - KCOV_MODE_TRACE_CMP. PC-tracing records a program - counter value for each basic block executed while tracing is enabled. In - this mode, each record is a single 64-bit unsigned integer containing the - program counter value. Comparison tracing provides information about data - flow; information about dynamic variable comparisons is recorded. Such - records provide information about the results of c(7) - ‘if’ or - ‘switch’ statements, for example. In - this mode each record consists of four 64-bit unsigned integers. The first - integer is a bitmask defining attributes of the variables involved in the - comparison. KCOV_CMP_CONST is set if one of the - variables has a constant value at compile-time, and - KCOV_CMP_SIZE(n) specifies the width of the - variables:

-

-
-
:
-
a comparison of 8-bit integers
-
:
-
a comparison of 16-bit integers
-
:
-
a comparison of 32-bit integers
-
:
-
a comparison of 64-bit integers
-
-

The second and third fields record the values of the two - variables, and the fourth and final field stores the program counter value - of the comparison.

-
-
-

-

Applications interact with kcov using the - ioctl(2) system call. Each thread making use of - kcov must use a separate file descriptor for - /dev/kcov. The following ioctls are defined:

-
-
- size_t entries
-
Set the size of the tracing buffer in units of - KCOV_ENTRY_SIZE. The buffer may then be mapped - into the calling thread's address space by calling - mmap(2) on the kcov device - file.
-
- int mode
-
Enable coverage tracing for the calling thread. Valid modes are - KCOV_MODE_TRACE_PC and - KCOV_MODE_TRACE_CMP.
-
-
Disable coverage tracing for the calling thread.
-
-
-
-

-

kcov creates the - /dev/kcov device file.

-
-
-

-

The following code sample collects information about basic block - coverage for kernel code executed while printing - ‘Hello, world’.

-
-
size_t sz;
-uint64_t *buf;
-int fd;
-
-fd = open("/dev/kcov", O_RDWR);
-if (fd == -1)
-	err(1, "open(/dev/kcov)");
-sz = 1ul << 20; /* 1MB */
-if (ioctl(fd, KIOSETBUFSIZE, sz / KCOV_ENTRY_SIZE) != 0)
-	err(1, "ioctl(KIOSETBUFSIZE)");
-buf = mmap(NULL, sz, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
-if (buf == MAP_FAILED)
-	err(1, "mmap");
-
-/* Enable PC tracing. */
-if (ioctl(fd, KIOENABLE, KCOV_MODE_TRACE_PC) != 0)
-	err(1, "ioctl(KIOENABLE)");
-
-/* Clear trace records from the preceding ioctl() call. */
-buf[0] = 0;
-
-printf("Hello, world!\n");
-
-/* Disable PC tracing. */
-if (ioctl(fd, KIODISABLE, 0) != 0)
-	err(1, "ioctl(KIODISABLE)");
-
-for (uint64_t i = 1; i < buf[0]; i++)
-	printf("%#jx\n", (uintmax_t)buf[i]);
-
-The output of this program can be approximately mapped to line numbers in kernel - source code: -
-
# ./kcov-test | sed 1d | addr2line -e /usr/lib/debug/boot/kernel/kernel.debug
-
-
-
-

-

ioctl(2), mmap(2)

-
-
-

-

kcov first appeared in - FreeBSD 13.0.

-
-
-

-

The FreeBSD implementation of - kcov does not yet support remote tracing.

-
-
- - - - - -
August 18, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/keyboard.4 3.html b/static/freebsd/man4/keyboard.4 3.html deleted file mode 100644 index 9e27a0ef..00000000 --- a/static/freebsd/man4/keyboard.4 3.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - -
KEYBOARD(4)Device Drivers ManualKEYBOARD(4)
-
-
-

-

keyboard — pc - keyboard interface

-
-
-

-

The PC keyboard is used as the console character input device. The - keyboard is owned by the current virtual console. To switch between the - virtual consoles use the sequence ALT+Fn, which means - hold down ALT and press one of the function keys. The virtual console with - the same number as the function key is then selected as the current virtual - console and given exclusive use of the keyboard and display.

-

The console allows entering values that are not physically present - on the keyboard via a special keysequence. To use this facility press and - hold down ALT, then enter a decimal number from 0-255 via the numerical - keypad, then release ALT. The entered value is then used as the ASCII value - for one character. This way it is possible to enter any ASCII value, not - present on the keyboard. The console driver also includes a history - function. It is activated by pressing the scroll-lock key. This holds the - display, and enables the cursor arrows for scrolling up and down through the - last scrolled out lines.

-

The keyboard is configurable to suit the individual user and the - different national layout.

-

The keys on the keyboard can have any of the following - functions:

-

-
-
Normal key
-
Enter the ASCII value associated with the key.
-
Function key
-
Enter a string of ASCII values.
-
Switch Key
-
Switch virtual console.
-
Modifier Key
-
Change the meaning of another key.
-
-

The keyboard is seen as a number of keys numbered from 1 to n. - This number is often referred to as the "scancode" for a given - key. The number of the key is transmitted as an 8 bit char with bit 7 as 0 - when a key is pressed, and the number with bit 7 as 1 when released. This - makes it possible to make the mapping of the keys fully configurable.

-

The meaning of every key is programmable via the PIO_KEYMAP ioctl - call, that takes a structure keymap_t as argument. The layout of this - structure is as follows:

-
-
		struct keymap {
-			u_short	n_keys;
-			struct key_t {
-				u_char map[NUM_STATES];
-				u_char spcl;
-				u_char flgs;
-			} key[NUM_KEYS];
-		};
-
-

The field n_keys tells the system how many keydefinitions - (scancodes) follows. Each scancode is then specified in the key_t - substructure.

-

Each scancode can be translated to any of 8 different values, - depending on the shift, control, and alt state. These eight possibilities - are represented by the map array, as shown below:

-
-
                                                            alt
- scan                          cntrl          alt    alt   cntrl
- code     base   shift  cntrl  shift   alt   shift  cntrl  shift
- map[n]      0       1      2      3     4       5      6      7
- ----     ------------------------------------------------------
- 0x1E      'a'     'A'   0x01   0x01    'a'    'A'   0x01   0x01
-
-

This is the default mapping for the key labelled 'A' which - normally has scancode 0x1E. The eight states are as shown, giving the 'A' - key its normal behavior. The spcl field is used to give the key - "special" treatment, and is interpreted as follows. Each bit - corresponds to one of the states above. If the bit is 0 the key emits the - number defined in the corresponding map[] entry. If the bit is 1 the key is - "special". This means it does not emit anything; instead it - changes the "state". That means it is a shift, control, alt, lock, - switch-screen, function-key or no-op key. The bitmap is backwards i.e., 7 - for base, 6 for shift etc.

-

The flgs field defines if the key should react on caps-lock (1), - num-lock (2), both (3) or ignore both (0).

-

The kbdcontrol(1) utility is used to load such a - description into/outof the kernel at runtime. This makes it possible to - change the key assignments at runtime, or more important to get (GIO_KEYMAP - ioctl) the exact key meanings from the kernel (e.g. used by the X - server).

-

The function keys can be programmed using the SETFKEY ioctl - call.

-

This ioctl takes an argument of the type fkeyarg_t:

-
-
		struct fkeyarg {
-			u_short	keynum;
-			char	keydef[MAXFK];
-			char	flen;
-		};
-
-

The field keynum defines which function key that is programmed. - The array keydef should contain the new string to be used (MAXFK long), and - the length should be entered in flen.

-

The GETFKEY ioctl call works in a similar manner, except it - returns the current setting of keynum.

-

The function keys are numbered like this:

-
-
	F1-F12 			key 1 - 12
-	Shift F1-F12		key 13 - 24
-	Ctrl F1-F12		key 25 - 36
-	Ctrl+shift F1-F12	key 37 - 48
-
-	Home			key 49
-	Up arrow		key 50
-	Page Up			key 51
-	(keypad) -		key 52
-	Left arrow		key 53
-	(keypad) 5              key 54
-	Right arrow		key 55
-	(keypad) +		key 56
-	End			key 57
-	Down arrow		key 58
-	Page down		key 59
-	Insert 			key 60
-	Delete			key 61
-
-	Left window		key 62
-	Right window		key 63
-	Menu			key 64
-
-

The kbdcontrol(1) utility also allows changing - these values at runtime.

-
-
-

-

Søren Schmidt - <sos@FreeBSD.org>

-
-
- - - - - -
January 8, 1995FreeBSD 15.0
diff --git a/static/freebsd/man4/kld.4 3.html b/static/freebsd/man4/kld.4 3.html deleted file mode 100644 index ee1c132c..00000000 --- a/static/freebsd/man4/kld.4 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
KLD(4)Device Drivers ManualKLD(4)
-
-
-

-

kld — dynamic - kernel linker facility

-
-
-

-

The LKM (Loadable Kernel Modules) facility has been deprecated in - FreeBSD 3.0 and above in favor of the - kld interface. This interface, like its predecessor, - allows the system administrator to dynamically add and remove functionality - from a running system. This ability also helps software developers to - develop new parts of the kernel without constantly rebooting to test their - changes.

-

Various types of modules can be loaded into the system. There are - several defined module types, listed below, which can be added to the system - in a predefined way. In addition, there is a generic type, for which the - module itself handles loading and unloading.

-

The FreeBSD system makes extensive use of - loadable kernel modules, and provides loadable versions of most file - systems, the NFS client and server, all the screen-savers, and the Linux - emulator. kld modules are placed by default in the - /boot/kernel directory along with their matching - kernel.

-

The kld interface is used through the - kldload(8), kldunload(8) and - kldstat(8) programs.

-

The kldload(8) program can load either - a.out(5) or ELF formatted loadable modules. The - kldunload(8) program unloads any given loaded module, if - no other module is dependent upon the given module. The - kldstat(8) program is used to check the status of the - modules currently loaded into the system.

-

Kernel modules may only be loaded or unloaded if the system - security level kern.securelevel is less than one.

-
-
-

-
-
-
New block and character device drivers may be loaded into the system with - kld. Device nodes for the loaded drivers are - automatically created when a module is loaded and destroyed when it is - unloaded by devfs(4). You can specify userland programs - that will run when new devices become available as a result of loading - modules, or existing devices go away when modules are unloaded, by - configuring devd(8).
-
-
-
-

-
-
/boot/kernel
-
directory containing module binaries built for the kernel also residing in - the directory.
-
/usr/include/sys/module.h
-
file containing definitions required to compile a - kld module
-
/usr/share/examples/kld
-
example source code implementing a sample kld module
-
-
-
-

-

kldfind(2), kldfirstmod(2), - kldload(2), kldnext(2), - kldstat(2), kldunload(2), - devfs(4), devd(8), - kldload(8), kldstat(8), - kldunload(8), sysctl(8)

-
-
-

-

The kld facility appeared in - FreeBSD 3.0 and was designed as a replacement for - the lkm facility, which was similar in functionality - to the loadable kernel modules facility provided by SunOS 4.1.3.

-
-
-

-

The kld facility was originally - implemented by Doug Rabson - <dfr@FreeBSD.org>.

-
-
-

-

If a module B, is dependent on another module A, but is not - compiled with module A as a dependency, then kldload(8) - fails to load module B, even if module A is already present in the - system.

-

If multiple modules are dependent on module A, and are compiled - with module A as a dependency, then kldload(8) loads an - instance of module A when any of the modules are loaded.

-

If a custom entry point is used for a module, and the module is - compiled as an ‘ELF’ binary, then kldload(8) - fails to execute the entry point.

-

kldload(8) points the user to read - dmesg(8) for any error encountered while loading a - module.

-

When system internal interfaces change, old modules often cannot - detect this, and such modules when loaded will often cause crashes or - mysterious failures.

-
-
- - - - - -
January 13, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/ksyms.4 3.html b/static/freebsd/man4/ksyms.4 3.html deleted file mode 100644 index 5186aaed..00000000 --- a/static/freebsd/man4/ksyms.4 3.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - -
KSYMS(4)Device Drivers ManualKSYMS(4)
-
-
-

-

ksyms — kernel - symbol table interface

-
-
-

-

device ksyms

-
-
-

-

The /dev/ksyms character device provides a - read-only interface to a snapshot of the kernel symbol table. The in-kernel - symbol manager is designed to be able to handle many types of symbols - tables, however, only elf(5) symbol tables are supported - by this device. The ELF format image contains two sections: a symbol table - and a corresponding string table.

-
-
-
-
The SYMTAB section contains the symbol table entries present in the - current running kernel, including the symbol table entries of any loaded - modules. The symbols are ordered by the kernel module load time starting - with kernel file symbols first, followed by the first loaded module's - symbols and so on.
-
-
The STRTAB section contains the symbol name strings from the kernel and - any loaded modules that the symbol table entries reference.
-
-
-

Elf formatted symbol table data read from the - /dev/ksyms file represents the state of the kernel - at the time when the device is opened. Since - /dev/ksyms has no text or data, most of the fields - are initialized to NULL. The ksyms driver does not - block the loading or unloading of modules into the kernel while the - /dev/ksyms file is open but may contain stale - data.

-
-
-

-
-
/dev/ksyms
-
 
-
-
-
-

-

An open(2) of /dev/ksyms - will fail if:

-
-
[]
-
The device is already open. A process must close - /dev/ksyms before it can be opened again.
-
[]
-
There is a resource shortage in the kernel.
-
[]
-
The driver was unsuccessful in creating a snapshot of the kernel symbol - table. This may occur if the kernel was in the process of loading or - unloading a module.
-
-
-
-

-

nlist(3), elf(5), - kldload(8)

-
-
-

-

A ksyms device exists in many different - operating systems. This implementation is similar in function to the Solaris - and NetBSD ksyms driver.

-

The ksyms driver first appeared in - FreeBSD 8.0 to support - lockstat(1).

-
-
-

-

The ksyms driver was written by - Stacey Son - <sson@FreeBSD.org>.

-
-
-

-

Because files can be dynamically linked into the kernel at any - time the symbol information can vary. When you open the - /dev/ksyms file, you have access to an ELF image - which represents a snapshot of the state of the kernel symbol information at - that instant in time. Keeping the device open does not block the loading or - unloading of kernel modules. To get a new snapshot you must close and - re-open the device.

-

A process is only allowed to open the - /dev/ksyms file once at a time. The process must - close the /dev/ksyms before it is allowed to open it - again.

-
-
- - - - - -
August 2, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ksz8995ma.4 4.html b/static/freebsd/man4/ksz8995ma.4 4.html deleted file mode 100644 index a1ea8e12..00000000 --- a/static/freebsd/man4/ksz8995ma.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
KSZ8995MA(4)Device Drivers ManualKSZ8995MA(4)
-
-
-

-

ksz8995ma — driver - for Micrel KSZ8995MA fast ethernet switch chip

-
-
-

-

device spibus -
- device etherswitch -
- device ksz8995ma

-

-
- hint.ksz8995ma.0.at="spibus0"

-
-
-

-

The ksz8995ma device driver provides a - management interface to Micrel KSZ8995MA fast ethernet switch chip. This - driver use spi interface. KSZ8995 series have many vertion but only support - MA/FQ version.

-

This driver support is port and dot1q vlan. dot1q support port - base tag/untag.

-
-
-

-

Configure dot1q vlan by etherswitchcfg command.

-

-
# etherswitchcfg config vlan_mode - dot1q
-

Configure port 5 is tagging port.

-

-
# etherswitchcfg port5 - addtag
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The ksz8995ma device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The ksz8995ma driver was written by - Hiroki Mori

-
-
- - - - - -
April 6, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ktls.4 3.html b/static/freebsd/man4/ktls.4 3.html deleted file mode 100644 index c4bfc728..00000000 --- a/static/freebsd/man4/ktls.4 3.html +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - -
KTLS(4)Device Drivers ManualKTLS(4)
-
-
-

-

ktls — kernel - Transport Layer Security

-
-
-

-

options KERN_TLS

-
-
-

-

The ktls facility allows the kernel to - perform Transport Layer Security (TLS) framing on TCP sockets. With - ktls, the initial handshake for a socket using TLS - is performed in userland. Once the session keys are negotiated, they are - provided to the kernel via the TCP_TXTLS_ENABLE and - TCP_RXTLS_ENABLE socket options. Both socket options - accept a struct tls_enable structure as their - argument. The members of this structure describe the cipher suite used for - the TLS session and provide the session keys used for the respective - direction.

-

ktls only permits the session keys to be - set once in each direction. As a result, applications must disable rekeying - when using ktls.

-
-

-

ktls can operate in different modes. A - given socket may use different modes for transmit and receive, or a socket - may only offload a single direction. The available modes are:

-
-
-
ktls is not enabled.
-
-
TLS records are encrypted or decrypted in the kernel in the socket layer - via crypto(9). Typically the encryption or decryption is - performed in software, but it may also be performed by co-processors.
-
-
TLS records are encrypted or decrypted by the network interface card - (NIC). In this mode, the network stack does not work with encrypted data. - Instead, the NIC encrypts TLS records as they are being transmitted, or - decrypts received TLS records before providing them to the host. -

Network interfaces which support this feature will advertise - the TXTLS4 (for IPv4) and/or - TXTLS6 (for IPv6) capabilities as reported by - ifconfig(8). These capabilities can also be controlled - by ifconfig(8).

-

If a network interface supports rate limiting (also known as - packet pacing) for TLS offload, the interface will advertise the - TXTLS_RTLMT capability.

-
-
-
TLS records are encrypted by the NIC using a TCP offload engine (TOE). - This is similar to TCP_TLS_MODE_IFNET in that the - network stack does not work with encrypted data. However, this mode works - in tandem with a TOE to handle interactions between TCP and TLS.
-
-
-
-

-

Once TLS transmit is enabled by a successful set of the - TCP_TXTLS_ENABLE socket option, all data written on - the socket is stored in TLS records and encrypted. Most data is transmitted - in application layer TLS records, and the kernel chooses how to partition - data among TLS records. Individual TLS records with a fixed length and - record type can be sent by sendmsg(2) with the TLS record - type set in a TLS_SET_RECORD_TYPE control message. - The payload of this control message is a single byte holding the desired TLS - record type. This can be used to send TLS records with a type other than - application data (for example, handshake messages) or to send application - data records with specific contents (for example, empty fragments).

-

The current TLS transmit mode of a socket can be queried via the - TCP_TXTLS_MODE socket option. A socket using TLS - transmit offload can also set the TCP_TXTLS_MODE - socket option to toggle between TCP_TLS_MODE_SW and - TCP_TLS_MODE_IFNET.

-
-
-

-

Once TLS receive is enabled by a successful set of the - TCP_RXTLS_ENABLE socket option, all data read from - the socket is returned as decrypted TLS records. Each received TLS record - must be read from the socket using recvmsg(2). Each - received TLS record will contain a TLS_GET_RECORD - control message along with the decrypted payload. The control message - contains a struct tls_get_record which includes fields - from the TLS record header. If an invalid or corrupted TLS record is - received, recvmsg(2) will fail with one of the following - errors:

-
-
[EINVAL]
-
The version fields in a TLS record's header did not match the version - required by the struct tls_enable structure used to - enable in-kernel TLS.
-
[EMSGSIZE]
-
A TLS record's length was either too small or too large.
-
[EMSGSIZE]
-
The connection was closed after sending a truncated TLS record.
-
[EBADMSG]
-
The TLS record failed to match the included authentication tag.
-
-

The current TLS receive mode of a socket can be queried via the - TCP_RXTLS_MODE socket option. At present, the mode - cannot be changed.

-
-
-

-

ktls uses several sysctl nodes under the - kern.ipc.tls node. A few of them are described - below:

-
-
kern.ipc.tls.enable
-
Determines if new kernel TLS sessions can be created.
-
kern.ipc.tls.cbc_enable
-
Determines if new kernel TLS sessions with a cipher suite using AES-CBC - can be created.
-
kern.ipc.tls.sw
-
A tree of nodes containing statistics for TLS sessions using - TCP_TLS_MODE_SW.
-
kern.ipc.tls.ifnet
-
A tree of nodes containing statistics for TLS sessions using - TCP_TLS_MODE_IFNET.
-
kern.ipc.tls.toe
-
A tree of nodes containing statistics for TLS sessions using - TCP_TLS_MODE_TOE.
-
kern.ipc.tls.stats
-
A tree of nodes containing various kernel TLS statistics.
-
-

The kern.ipc.mb_use_ext_pgs sysctl controls - whether the kernel may use unmapped mbufs. They are required for TLS - transmit.

-
-
-

-

The cxgbe(4) and mlx5en(4) - drivers include support for the TCP_TLS_MODE_IFNET - mode.

-

The cxgbe(4) driver includes support for the - TCP_TLS_MODE_TOE mode.

-
-
-

-

OpenSSL 3.0 and later include support for - ktls. The security/openssl* - and security/gnutls ports may also be built with - support for ktls by enabling the - KTLS option. OpenSSL in the base system includes - KTLS support when built with WITH_OPENSSL_KTLS.

-

Applications using a supported library should generally work with - ktls without any changes provided they use standard - interfaces such as SSL_read(3) and - SSL_write(3). Additional performance may be gained by the - use of SSL_sendfile(3).

-
-
-
-

-

ktls assumes the presence of a direct map - of physical memory when performing software encryption and decryption. As a - result, it is only supported on architectures with a direct map.

-
-
-

-

cxgbe(4), mlx5en(4), - tcp(4), src.conf(5), - ifconfig(8), sysctl(8), - crypto(9)

-
-
-

-

Kernel TLS first appeared in FreeBSD - 13.0.

-
-
- - - - - -
October 31, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ktr.4 3.html b/static/freebsd/man4/ktr.4 3.html deleted file mode 100644 index 9271fb74..00000000 --- a/static/freebsd/man4/ktr.4 3.html +++ /dev/null @@ -1,161 +0,0 @@ - - - - - - -
KTR(4)Device Drivers ManualKTR(4)
-
-
-

-

ktr — kernel - tracing facility

-
-
-

-

options KTR -
- options ALQ -
- options KTR_ALQ -
- options KTR_COMPILE=(KTR_LOCK|KTR_INTR|KTR_PROC) -
- options KTR_CPUMASK=0x3 -
- options KTR_ENTRIES=8192 -
- options KTR_MASK=(KTR_INTR|KTR_PROC) -
- options KTR_VERBOSE

-
-
-

-

The ktr facility allows kernel events to - be logged while the kernel executes so that they can be examined later when - debugging. The only mandatory option to enable ktr - is “options KTR”.

-

The KTR_ENTRIES option sets the size of - the buffer of events. The size of the buffer in the currently running kernel - can be found via the sysctl debug.ktr.entries. By - default the buffer contains 1024 entries.

-
-

-

Event levels can be enabled or disabled to trim excessive and - overly verbose logging. First, a mask of events is specified at compile time - via the KTR_COMPILE option to limit which events are - actually compiled into the kernel. The default value for this option is for - all events to be enabled.

-

Secondly, the actual events logged while the kernel runs can be - further masked via the run time event mask. The - KTR_MASK option sets the default value of the run - time event mask. The runtime event mask can also be set by the - loader(8) via the debug.ktr.mask - environment variable. It can also be examined and set after booting via the - debug.ktr.mask sysctl. By default the run time mask is - set to block any tracing. The definitions of the event mask bits can be - found in - <sys/ktr_class.h>.

-

Furthermore, there is a CPU event mask whose default value can be - changed via the KTR_CPUMASK option. When two or more - parameters to KTR_CPUMASK, are used, it is important - they are not separated by whitespace. A CPU must have the bit corresponding - to its logical id set in this bitmask for events that occur on it to be - logged. This mask can be set by the loader(8) via the - debug.ktr.cpumask environment variable. It can also be - examined and set after booting via the - debug.ktr.cpumask sysctl. By default, only CPUs - specified in KTR_CPUMASK will log events. See - sys/conf/NOTES for more information.

-
-
-

-

By default, events are only logged to the internal buffer for - examination later, but if the verbose flag is set then they are dumped to - the kernel console as well. This flag can also be set from the loader via - the debug.ktr.verbose environment variable, or it can - be examined and set after booting via the - debug.ktr.verbose sysctl. If the flag is set to zero, - which is the default, then verbose output is disabled. If the flag is set to - one, then the contents of the log message and the CPU number are printed to - the kernel console. If the flag is greater than one, then the filename and - line number of the event are output to the console in addition to the log - message and the CPU number. The KTR_VERBOSE option - sets the flag to one.

-
-
-

-

The KTR buffer can be examined from within - ddb(4) via the show ktr - [/vV] command. This command displays the contents of - the trace buffer one page at a time. At the - “--more--” prompt, the Enter key - displays one more entry and prompts again. The spacebar displays another - page of entries. Any other key quits. By default the timestamp, filename, - and line number are not displayed with each log entry. If the - /v modifier is specified, then they are displayed in - addition to the normal output. If the /V modifier is - specified, then just the timestamp is displayed in addition to the normal - output. Note that the events are displayed in reverse chronological order. - That is, the most recent events are displayed first.

-
-
-

-

The KTR_ALQ option can be used to log - ktr entries to disk for post analysis using the - ktrdump(8) utility. This option depends on the - ALQ option. Due to the potentially high volume of - trace messages the trace mask should be selected carefully. This feature is - configured through a group of sysctls.

-
-
debug.ktr.alq_file
-
displays or sets the file that ktr will log to. By - default its value is /tmp/ktr.out. If the file - name is changed while ktr is enabled it will not - take effect until the next invocation.
-
debug.ktr.alq_enable
-
enables logging of ktr entries to disk if it is - set to one. Setting this to 0 will terminate logging to disk and revert to - logging to the normal ktr ring buffer. Data is not sent to the ring buffer - while logging to disk.
-
debug.ktr.alq_max
-
is the maximum number of entries that will be recorded to disk, or 0 for - infinite. This is helpful for limiting the number of particularly high - frequency entries that are recorded.
-
debug.ktr.alq_depth
-
determines the number of entries in the write buffer. This is the buffer - that holds entries before they are written to disk and defaults to the - value of the KTR_ENTRIES option.
-
debug.ktr.alq_failed
-
records the number of times we failed to write an entry due to overflowing - the write buffer. This may happen if the frequency of the logged - ktr messages outpaces the depth of the queue.
-
debug.ktr.alq_cnt
-
records the number of entries that have currently been written to - disk.
-
-
-
-
-

-

ktrdump(8), alq(9), - ktr(9)

-
-
-

-

The KTR kernel tracing facility first appeared in - BSD/OS 3.0 and was imported into - FreeBSD 5.0.

-
-
- - - - - -
March 26, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/kue.4 4.html b/static/freebsd/man4/kue.4 4.html deleted file mode 100644 index 69d9c857..00000000 --- a/static/freebsd/man4/kue.4 4.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
KUE(4)Device Drivers ManualKUE(4)
-
-
-

-

kue — Kawasaki LSI - KL5KUSB101B USB Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device kue
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_kue_load="YES"
-
-
-
-

-

The kue driver provides support for USB - Ethernet adapters based on the Kawasaki LSI KL5KLUSB101B chipset.

-

The KL5KLUSB101B supports a 128-entry multicast filter, single - perfect filter entry for the station address and promiscuous mode. Packets - are received and transmitted over separate USB bulk transfer endpoints.

-

The Kawasaki chipset supports only 10Mbps half-duplex - mode, hence there are no - () - modes to select.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The kue driver supports Kawasaki LSI - KL5KLUSB101B based USB Ethernet adapters including:

-

-
    -
  • 3Com 3c19250
    • -
  • 3Com 3c460 HomeConnect Ethernet USB Adapter
    • -
  • ADS Technologies USB-10BT
    • -
  • AOX USB101
    • -
  • ATen UC10T
    • -
  • Abocom URE 450
    • -
  • Corega USB-T
    • -
  • D-Link DSB-650C
    • -
  • Entrega NET-USB-E45, NET-HUB-3U1E
    • -
  • I/O Data USB ETT
    • -
  • Kawasaki DU-H3E
    • -
  • LinkSys USB10T
    • -
  • Netgear EA101
    • -
  • Peracom USB Ethernet Adapter
    • -
  • Psion Gold Port USB Ethernet adapter
    • -
  • SMC 2102USB, 2104USB
    • -
-
-
-

-
-
kue%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
kue%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
-
-
-

-

arp(4), netintro(4), - ng_ether(4), ifconfig(8)

-
-
-

-

The kue device driver first appeared in - FreeBSD 4.0.

-
-
-

-

The kue driver was written by - Bill Paul - <wpaul@ee.columbia.edu>.

-
-
-

-

The kue driver does not accumulate - Ethernet collisions statistics because the Kawasaki firmware does not appear - to maintain any internal statistics.

-
-
- - - - - -
July 24, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/kvmclock.4 3.html b/static/freebsd/man4/kvmclock.4 3.html deleted file mode 100644 index ce4cc343..00000000 --- a/static/freebsd/man4/kvmclock.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
KVMCLOCK(4)Device Drivers ManualKVMCLOCK(4)
-
-
-

-

kvmclock — - Para-virtualized clock driver for x86 KVM guests

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device kvm_clock
-
-
-

-

This driver reads time-keeping information from the - para-virtualized clock device provided by the KVM hypervisor on Linux hosts. - The kvmclock driver is only implemented on i386 and - amd64 platforms. It acts as a timecounters(4) device and - is preferred over the Time Stamp Counter (TSC) when available. The driver - exports timekeeping information via /dev/pvclock, - enabling the implementation of clock_gettime(2) and - related functions without entering the kernel.

-

The kvmclock driver works by accessing a - per-vCPU timekeeping structure maintained by the hypervisor. It uses a - combination of TSC readings and information from the shared structure to - produce a high-resolution timecounter which is invariant under hypervisor - events such as vCPU migration and live VM migration.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.kvmclock.0.vdso_enable_without_rdtscp
-
By default, timekeeping information is exported to userspace only when the - (virtual) CPU announces support for the “rdtscp” - instruction. Setting this sysctl to 1 overrides this behavior, allowing - timekeeping information to be exported even in the absence of - “rdtscp” support. However, this breaks compatibility with - copies of /lib/libc.so.7 released prior to - FreeBSD 14.0, and statically linked binaries which - embed a copy of the system C library. Thus, this sysctl value should not - be changed if the system may execute binaries older than - FreeBSD 14.0.
-
dev.kvmclock.0.vdso_force_unstable
-
Mark the timecounter as unstable for userspace consumers. This is mostly - useful for debugging the driver and userspace timekeeping code, and - generally should not be touched.
-
-
-
-

-

timecounters(4)

-
-
-

-

The kvmclock driver first appeared in - FreeBSD 13.1.

-
-
- - - - - -
February 1, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/lagg.4 3.html b/static/freebsd/man4/lagg.4 3.html deleted file mode 100644 index 65363587..00000000 --- a/static/freebsd/man4/lagg.4 3.html +++ /dev/null @@ -1,198 +0,0 @@ - - - - - - -
LAGG(4)Device Drivers ManualLAGG(4)
-
-
-

-

lagg — link - aggregation and link failover interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device lagg
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_lagg_load="YES"
-
-
-
-

-

The lagg interface allows aggregation of - multiple network interfaces as one virtual lagg - interface for the purpose of providing fault-tolerance and high-speed - links.

-

Each lagg interface is created at runtime - using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5).

-

A lagg interface can be created using the - ifconfig laggN - create command. It can use different link - aggregation protocols specified using the laggproto - proto option. Child interfaces can be added using the - laggport child-iface option - and removed using the -laggport - child-iface option.

-

The driver currently supports the aggregation protocols - failover (the default), - lacp, loadbalance, - roundrobin, broadcast, and - none. The protocols determine which ports are used - for outgoing traffic and whether a specific port accepts incoming traffic. - The interface link state is used to validate if the port is active or - not.

-
-
-
Sends traffic only through the active port. If the master port becomes - unavailable, the next active port is used. The first interface added is - the master port; any interfaces added after that are used as failover - devices. -

By default, received traffic is only accepted when it is - received through the active port. This constraint can be relaxed by - setting the net.link.lagg.failover_rx_all - sysctl(8) variable to a nonzero value, which is useful - for certain bridged network setups.

-
-
-
Supports the IEEE 802.1AX (formerly 802.3ad) Link Aggregation Control - Protocol (LACP) and the Marker Protocol. LACP will negotiate a set of - aggregable links with the peer in to one or more Link Aggregated Groups. - Each LAG is composed of ports of the same speed, set to full-duplex - operation. The traffic will be balanced across the ports in the LAG with - the greatest total speed, in most cases there will only be one LAG which - contains all ports. In the event of changes in physical connectivity, Link - Aggregation will quickly converge to a new configuration.
-
-
Balances outgoing traffic across the active ports based on hashed protocol - header information and accepts incoming traffic from any active port. This - is a static setup and does not negotiate aggregation with the peer or - exchange frames to monitor the link. The hash includes the Ethernet source - and destination address, and, if available, the VLAN tag, and the IP - source and destination address.
-
-
Distributes outgoing traffic using a round-robin scheduler through all - active ports and accepts incoming traffic from any active port. Using - roundrobin mode can cause unordered packet arrival - at the client. Throughput might be limited as the client performs - CPU-intensive packet reordering.
-
-
Sends frames to all ports of the LAG and receives frames on any port of - the LAG.
-
-
This protocol is intended to do nothing: it disables any traffic without - disabling the lagg interface itself.
-
-

The MTU of the first interface to be added is used as the lagg - MTU. All additional interfaces are required to have exactly the same - value.

-

The loadbalance and - lacp modes will use the RSS hash from the network - card if available to avoid computing one, this may give poor traffic - distribution if the hash is invalid or uses less of the protocol header - information. Local hash computation can be forced per interface by setting - the -use_flowid ifconfig(8) flag. - The default for new interfaces is set via the - net.link.lagg.default_use_flowid - sysctl(8).

-

When creating a lagg interface, the - laggtype can be specified as either - ethernet or infiniband. If - neither is specified then the default is - ethernet.

-
-
-

-

Create a link aggregation using LACP with two - bge(4) Gigabit Ethernet interfaces:

-
-
# ifconfig bge0 up
-# ifconfig bge1 up
-# ifconfig lagg0 create
-# ifconfig lagg0 laggproto lacp laggport bge0 laggport bge1 \
-	192.168.1.1 netmask 255.255.255.0
-
-

Create a link aggregation using ROUNDROBIN with two - bge(4) Gigabit Ethernet interfaces and set a stride of 500 - packets per interface:

-
-
# ifconfig bge0 up
-# ifconfig bge1 up
-# ifconfig lagg0 create
-# ifconfig lagg0 laggproto roundrobin laggport bge0 laggport bge1 \
-	192.168.1.1 netmask 255.255.255.0
-# ifconfig lagg0 rr_limit 500
-
-

The following example uses an active failover interface to set up - roaming between wired and wireless networks using two network devices. - Whenever the wired master interface is unplugged, the wireless failover - device will be used:

-
-
# ifconfig em0 ether 00:11:22:33:44:55 up
-# ifconfig wlan0 create wlandev ath0 ssid my_net up
-# ifconfig lagg0 create
-# ifconfig lagg0 laggproto failover laggport em0 laggport wlan0 \
-	192.168.1.1 netmask 255.255.255.0
-
-

(Note the MAC address of the wired device is forced to match that - of the wireless device, ‘00:11:22:33:44:55’ in this example, - as some common wireless devices will not allow MAC addresses to be - changed.)

-

The following example shows how to create an infiniband failover - interface.

-
-
# ifconfig ib0 up
-# ifconfig ib1 up
-# ifconfig lagg0 create laggtype infiniband
-# ifconfig lagg0 laggproto failover laggport ib0 laggport ib1 \
-	1.1.1.1 netmask 255.255.255.0
-
-

Configure two ethernets for failover with static IP in - /etc/rc.conf:

-
-
cloned_interfaces="lagg0"
-ifconfig_lagg0="laggproto failover laggport bge0 laggport bge1 \
-	10.1.29.21/24"
-ifconfig_bge0="up"
-ifconfig_bge1="up"
-
-
-
-

-

ng_one2many(4), rc.conf(5), - ifconfig(8), sysctl(8)

-
-
-

-

The lagg device first appeared in - FreeBSD 6.3.

-
-
-

-

The lagg driver was written under the name - trunk by Reyk Floeter - <reyk@openbsd.org>. - The LACP implementation was written by YAMAMOTO - Takashi for NetBSD.

-
-
-

-

There is no way to configure LACP administrative variables, - including system and port priorities. The current implementation always - performs active-mode LACP and uses 0x8000 as system and port priorities.

-
-
- - - - - -
January 16, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/led.4 4.html b/static/freebsd/man4/led.4 4.html deleted file mode 100644 index 65f29ef0..00000000 --- a/static/freebsd/man4/led.4 4.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
LED(4)Device Drivers ManualLED(4)
-
-
-

-

led — API for - manipulating LED's, lamps and other annunciators

-
-
-

-

#include - <dev/led/led.h>

-

-
- typedef void led_t(void *priv, int onoff);

-

struct cdev * -
- led_create_state(led_t - *func, void *priv, - char const *name, - int state);

-

struct cdev * -
- led_create(led_t - *func, void *priv, - char const *name);

-

void -
- led_destroy(struct - cdev *);

-
-
-

-

The led driver provides generic support - for handling LEDs, lamps and other annunciators.

-

The hardware driver must supply a function to turn the annunciator - on and off and the device name of the annunciator - relative to /dev/led/. The - priv argument is passed back to this on/off function - and can be used however the hardware driver sees fit.

-

The lamp can be controlled by opening and writing ASCII strings to - the /dev/led/bla device.

-

In the following, we will use this special notation to indicate - the resulting output of the annunciator:

-

-
-
-
-
The annunciator is on for 1/10th second.
-
-
The annunciator is off for 1/10th second.
-
-
-

State can be set directly, and since the change happens - immediately, it is possible to flash the annunciator with very short periods - and synchronize it with program events. It should be noted that there is a - non-trivial overhead, so this may not be usable for benchmarking or - measuring short intervals.

-

-
-
-
-
Turn the annunciator off immediately.
-
-
Turn the annunciator on immediately.
-
-
-

Flashing can be set with a given period. The pattern continues - endlessly.

-

-
-
-
-
_*
-
-
_*
-
-
__**
-
-
___***
-
...
-
 
-
-
_________*********
-
-
-

Three high-level commands are available:

-
-
-
-
Numbers. Each digit is blinked out at 1/10th second, zero as ten pulses. - Between digits a one second pause and after the last digit a two second - pause after which the sequence is repeated.
-
-
String. This gives full control over the annunciator. Letters - ‘A’ ... - ‘J’ turn the annunciator on for from - 1/10th to one full second. Letters - ‘a’ ... - ‘j’ turn the annunciator off for - 1/10th to one full second. Letters - ‘u’ and - ‘U’ turn the annunciator off and on - respectively when the next UTC second starts. Unless terminated with a - ‘.’, the sequence is immediately - repeated.
-
-
Morse. -

-
-
-
‘.’
-
becomes ‘_*’
-
‘-’
-
becomes ‘_***’
-
‘ ’
-
becomes ‘__’
-
‘\n’
-
becomes ‘____’
-
-
-
-
-
-

The sequence is repeated after a one second pause.

-
-
-

-
-
/dev/led/*
-
 
-
-
-
-

-

A ‘d12’ flashes the lamp

-

-
*__________*_*______________________________
-

A ‘sAaAbBa’ flashes

-

-
*_*__**_
-
-
/usr/bin/morse -l "Soekris rocks" > /dev/led/error
-
-
-
-

-

morse(6)

-
-
-

-

The led driver first appeared in - FreeBSD 5.2.

-
-
-

-

This software was written by Poul-Henning - Kamp - <phk@FreeBSD.org>.

-

This manual page was written by Sergey A. - Osokin - <osa@FreeBSD.org> and - Poul-Henning Kamp - <phk@FreeBSD.org>.

-
-
- - - - - -
April 24, 2007FreeBSD 15.0
diff --git a/static/freebsd/man4/lge.4 3.html b/static/freebsd/man4/lge.4 3.html deleted file mode 100644 index bfe2b08d..00000000 --- a/static/freebsd/man4/lge.4 3.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - -
LGE(4)Device Drivers ManualLGE(4)
-
-
-

-

lge — Level 1 - LXT1001 NetCellerator PCI Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device lge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_lge_load="YES"
-
-
-
-

-

The lge driver provides support for - various NICs based on the Level 1 LXT1001 NetCellerator Gigabit Ethernet - controller chip.

-

The LXT1001 supports fiber PHYs and also a GMII port for use with - 10/100/1000 copper PHYs, however there are currently no NICs on the market - that use this feature.

-

The LXT1001 supports TCP/IP checksum offload for receive and - VLAN-based filtering as well as a 64-bit multicast hash filter. It also - supports jumbo frames, which can be configured via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit jumbo frames. Using jumbo frames can greatly improve performance - for certain tasks, such as file transfers and data streaming.

-

The lge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 1000baseSX operation over fiber optic cable. Both - full-duplex and - half-duplex modes are supported.
-
-

The lge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

Adapters supported by the lge driver - include:

-

-
    -
  • SMC TigerCard 1000 (SMC9462SX)
    • -
  • D-Link DGE-500SX
    • -
-
-
-

-
-
lge%d: couldn't map memory
-
A fatal initialization error has occurred.
-
lge%d: couldn't map ports
-
A fatal initialization error has occurred.
-
lge%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
lge%d: no memory for softc struct!
-
The driver failed to allocate memory for per-device instance information - during initialization.
-
lge%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
lge%d: no memory for jumbo buffers!
-
The driver failed to allocate memory for jumbo frames during - initialization.
-
lge%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

arp(4), miibus(4), - netintro(4), ng_ether(4), - ifconfig(8)

-

Level 1 LXT1001 Programming - Manual, - https://www.FreeBSD.org/~wpaul/Level1/LXT1001SRM.pdf.

-
-
-

-

The lge device driver first appeared in - FreeBSD 4.4.

-
-
-

-

The lge driver was written by - Bill Paul - <william.paul@windriver.com>.

-
-
- - - - - -
July 16, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/lindebugfs.4 3.html b/static/freebsd/man4/lindebugfs.4 3.html deleted file mode 100644 index 1cae24b2..00000000 --- a/static/freebsd/man4/lindebugfs.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
LINDEBUGFS(4)Device Drivers ManualLINDEBUGFS(4)
-
-

-
-

-

lindebugfs — Linux - file system for debugging

-
-
-

-
-
lindebugfs		/sys/kernel/debug	lindebugfs	rw 0 0
-
-
-
-

-

The debug file system, or debugfs, makes process debugging easier - by providing a simple API for data transfer between the kernel and user - space. Debugfs is not a general-purpose file system and should not be used - as a storage medium. Instead, developers can implement the debugfs interface - in their code to generate debug information about their program at runtime. - FreeBSD's lindebugfs uses the - pseudofs(9) file system construction kit to model itself - after Linux's debugfs. The lindebugfs API is - intended for use with programs that take advantage of FreeBSD's LinuxKPI - compatibility layer.

-

When mounted, lindebugfs will populate - with pseudo files from any running process that calls - debugfs_create_file(). Since - lindebugfs is a pseudo file system, file contents - will be generated dynamically based on program provided file operations. The - current lindebugfs implementation formally supports - seq_file and simple_attr_file virtual file formats.

-
-
-

-

Load the lindebugfs kernel module:

-

-
kldload lindebugfs
-

Mount the lindebugfs file system on - /sys/kernel/debug:

-

-
mount -t lindebugfs lindebugfs - /sys/kernel/debug
-
-
-

-

mount(1), linprocfs(4), - linsysfs(4), linux(4), - pseudofs(9)

-
-
-

-

The lindebugfs file system first appeared - in FreeBSD 12.1.

-
-
-

-

The initial implementation for lindebugfs - was created by Matthew Macy. This manual page was written by Jake - Freeland.

-
-
- - - - - -
August 10, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/linprocfs.4 3.html b/static/freebsd/man4/linprocfs.4 3.html deleted file mode 100644 index 79a0d2e1..00000000 --- a/static/freebsd/man4/linprocfs.4 3.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - -
LINPROCFS(4)Device Drivers ManualLINPROCFS(4)
-
-
-

-

linprocfs — Linux - process file system

-
-
-

-
-
linprocfs		/compat/linux/proc	linprocfs	rw 0 0
-
-
-
-

-

The Linux process file system, or - linprocfs, emulates a subset of Linux' process file - system and is required for the complete operation of some Linux - binaries.

-

The linprocfs provides a two-level view of - process space. At the highest level, processes themselves are named, - according to their process ids in decimal, with no leading zeros. There is - also a special node called self which always refers - to the process making the lookup request.

-

Each process node is a directory containing several files:

-
-
auxv
-
The auxiliary vector passed to the program.
-
cmdline
-
The command line used to execute the process.
-
cwd
-
A symbolic link pointing to the current work directory of the - process.
-
environ
-
The list of environment variables and values of the process. Every - variable and pair value is separated from the next by a NULL byte.
-
exe
-
A reference to the vnode from which the process text was read. This can be - used to gain access to the process' symbol table, or to start another copy - of the process.
-
limits
-
The soft and hard limits for the process along with the units used.
-
maps
-
Memory map of the process.
-
mem
-
The complete virtual memory image of the process. Only those addresses - which exist in the process can be accessed. Reads and writes to this file - modify the process. Writes to the text segment remain private to the - process.
-
mountinfo
-
Information about mount points.
-
mounts
-
Similar to the above.
-
oom_score_adj
-
Score adjustment for the Out Of Memory killer.
-
root
-
Symbolic link to the root directory for this process.
-
stat
-
Process statistics. It includes user, nice, system, idle, iowait, irq, - softirq, steal, guest and guest_nice.
-
statm
-
Process size statistics. It includes total program size, resident set - size, number of resident shared pages (unused), text size, library size - (unused), data + stack and dirty pages (unused).
-
status
-
Process statistics in human readable form. It includes process name, - state, PID, etc.
-
task
-
Dummy directory to avoid problems in specific software such as - Chromium.
-
-

Each node is owned by the process's user, and belongs to that - user's primary group, except for the mem node, which - belongs to the kmem group.

-
-
-

-
-
/compat/linux/proc
-
The normal mount point for linprocfs.
-
/compat/linux/proc/cmdline
-
Contains the path of the kernel image used to boot the system.
-
/compat/linux/proc/cpuinfo
-
CPU vendor and model information in human-readable form.
-
/compat/linux/proc/devices
-
List of character and block devices. The later is usually empty on - FreeBSD.
-
/compat/linux/proc/filesystems
-
List of supported filesystems. For pseudo filesystems, the first column - contains - .
-
/compat/linux/proc/meminfo
-
System memory information in human-readable form.
-
/compat/linux/proc/modules
-
Loaded kernel modules. Empty for now.
-
/compat/linux/proc/mounts
-
Devices corresponding mount points.
-
/compat/linux/proc/mtab
-
Same as above.
-
/compat/linux/proc/partitions
-
Partition information including major and minor numbers, number of blocks - and name. The rest of the fields are set to zero.
-
/compat/linux/proc/stat
-
System statistics. For each cpu it includes at most user time, nice time, - system time and idle time, iowait (time waiting for I/O to complete), - times serving irqs and softirq, steal, guest and guest_nice times that - represent times spent in different modes in a virtualized environment. The - last columns are set to zero. This file also contains brief statistics for - disks, context switches and more.
-
/compat/linux/proc/swap
-
Information about the swap device if any.
-
/compat/linux/proc/uptime
-
Time since the last boot and time spent in idle state.
-
/compat/linux/proc/version
-
Version of the emulated linux system.
-
/compat/linux/proc/⟨pid⟩
-
A directory containing process information for process - pid.
-
/compat/linux/proc/self
-
A symlink to a directory containing process information for the current - process.
-
-
-
-

-

To mount a linprocfs file system on - /compat/linux/proc:

-

-
mount -t linprocfs linprocfs - /compat/linux/proc
-
-
-

-

mount(2), unmount(2), - auxv(3), linux(4), - procfs(5), pseudofs(9)

-
-
-

-

The linprocfs first appeared in - FreeBSD 4.0.

-
-
-

-

The linprocfs was derived from - procfs by Pierre Beyssac. - This manual page was written by Dag-Erling - Smørgrav, based on the procfs(5) manual page - by Garrett Wollman.

-
-
- - - - - -
December 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/linsysfs.4 4.html b/static/freebsd/man4/linsysfs.4 4.html deleted file mode 100644 index 1ad2a4ee..00000000 --- a/static/freebsd/man4/linsysfs.4 4.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
LINSYSFS(4)Device Drivers ManualLINSYSFS(4)
-
-
-

-

linsysfs — Linux - kernel objects file system

-
-
-

-
-
linsysfs		/compat/linux/sys	linsysfs	rw 0 0
-
-
-
-

-

The Linux system file system, or linsysfs, - emulates a subset of the Linux sys file system and is required for the - complete operation of some Linux binaries.

-

The linsysfs provides a two-level view of - devices. At the highest level, PCI devices themselves are named, according - to their bus, slot and function in the system hierarchy. PCI storage devices - are listed in the scsi_host class with a device - symlink to the PCI directories of the devices.

-

Each device node is a directory containing some files and - directories:

-
-
host
-
A place holder for storage host information.
-
pci_id
-
A directory for the pci_id that contains either - the device information or another directory structure for a PCI - bridge.
-
-

Each host node of scsi_host is a directory containing some files - and directories:

-
-
proc_name
-
The Linux registered driver name for these devices.
-
device
-
A symlink to the PCI device directory.
-
-
-
-

-
-
/compat/linux/sys
-
The normal mount point for linsysfs.
-
/compat/linux/sys/class/scsi_host
-
The storage host node.
-
/compat/linux/sys/devices/pci0000:00
-
The PCI device hierarchy node.
-
-
-
-

-

The most common usage follows:

-

-
mount -t linsysfs linsysfs - /compat/linux/sys
-

where /compat/linux/sys is a mount - point.

-
-
-

-

nmount(2), unmount(2), - linprocfs(4), linux(4), - pseudofs(9)

-
-
-

-

The linsysfs driver first appeared in - FreeBSD 6.2.

-
-
-

-

The linsysfs driver was derived from - linprocfs by Doug Ambrisko. - This manual page was edited by Doug Ambrisko, based - on the linprocfs(4) manual page by - Garrett Wollman.

-
-
- - - - - -
November 13, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/linux.4 3.html b/static/freebsd/man4/linux.4 3.html deleted file mode 100644 index d10dae0d..00000000 --- a/static/freebsd/man4/linux.4 3.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - -
LINUX(4)Device Drivers ManualLINUX(4)
-
-
-

-

linux — Linux ABI - support

-
-
-

-

To enable the Linux ABI at boot time, place the following line in - rc.conf(5):

-
-
linux_enable="YES"
-
-
-
-

-

The linux kernel module provides limited - Linux ABI (application binary interface) compatibility, making it possible - to run many unmodified Linux applications without the need for - virtualization or emulation. Some of the facilities provided are:

-
    -
  • Linux to native system call translation
    • -
  • Linux-specific system calls
    • -
  • Special signal handling for Linux processes
    • -
  • Path translation mechanism
    • -
  • Linux-specific virtual file systems
    • -
-

The path translation mechanism makes Linux processes look up file - paths under emul_path (defaulting to - /compat/linux) before /. For - example, when a Linux process attempts to open - /etc/passwd, it will first access - /compat/linux/etc/passwd, falling back to - /etc/passwd if the compat path does not exist. This - is used to make sure Linux processes load Linux shared libraries instead of - their similarly-named FreeBSD counterparts, and also to provide alternative - versions of certain other files and virtual file systems.

-

To install Linux shared libraries and system files into - /compat/linux, either use the - emulators/linux_base-c7 port or package, or - debootstrap(8) installed from - sysutils/debootstrap.

-

To avoid mounting Linux-specific filesystems at startup, add the - following line to the rc.conf(5) file:

-

-
linux_mounts_enable="NO"
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
compat.linux.debug
-
Enable debugging messages. Set to 0 to silence them. Defaults to 3. A - setting of 1 prints debug messages, tells about unimplemented stuff (only - once). Set to 2 is like 1, but also prints messages about implemented but - not tested stuff (only once). Setting it to 3 or higher is like 2, but no - rate limiting of messages.
-
compat.linux.default_openfiles
-
Default soft openfiles resource limit for Linux applications. Set to -1 to - disable the limit. Defaults to 1024.
-
compat.linux.emul_path
-
Path to the Linux run-time environment. Defaults to - /compat/linux.
-
compat.linux.osname
-
Linux kernel operating system name. Defaults to "Linux".
-
compat.linux.osrelease
-
Linux kernel operating system release. Changing this to something else is - discouraged on non-development systems, because it may change the way - Linux programs work. Some versions of GNU libc are known to use different - syscalls depending on the value of this sysctl.
-
compat.linux.oss_version
-
Linux Open Sound System version. Defaults to 198144.
-
compat.linux.preserve_vstatus
-
When set to 1, it prevents Linux applications from resetting the - termios(4) VSTATUS setting. From a user perspective, - this makes SIGINFO work for Linux executables. - Defaults to 1.
-
compat.linux.setid_allowed
-
Enable handling of set-user-ID and set-group-ID mode bits for the new - process image file when image is to be executed under Linux ABI. When set - to 0, new Linux images always use credentials of the program that issued - the execve(2) call, regardless of the image file mode. - This might be reasonable or even required, because - FreeBSD does not emulate the Linux environment - completely, and missed features may result in security vulnerabilities. - Defaults to 1.
-
compat.linux32.emulate_i386
-
In the x86_64 (amd64) world enable the real i386 Linuxulator behavior. For - example, when set to 0, Linux uname -m will return "x86_64" even - if uname itself is a i386 Linux executable. When set to 1, Linux i386 - uname -m will return "i686". Defaults to 0.
-
-
-
-

-
-
/compat/linux
-
Linux run-time environment
-
/compat/linux/dev
-
device file system, see devfs(4)
-
/compat/linux/dev/fd
-
file descriptor file system mounted with the - linrdlnk option, see - fdescfs(4)
-
/compat/linux/dev/mqueue
-
symbolic link to a mqueuefs mount, see mqueuefs(4)
-
/compat/linux/dev/shm
-
in-memory file system, see tmpfs(4)
-
/compat/linux/proc
-
Linux process file system, see linprocfs(4)
-
/compat/linux/sys
-
Linux kernel objects file system, see linsysfs(4)
-
-
-
-

-

brandelf(1), fdescfs(4), - linprocfs(4), linsysfs(4), - mqueuefs(4), pty(4), - tmpfs(4), elf(5)

-
-
-

-

Linux ABI support first appeared for i386 in - FreeBSD 2.1. Support for amd64 binaries first - appeared in FreeBSD 10.3. Support for arm64 binaries - first appeared in FreeBSD 12.0.

-
-
-

-

Support for some of the Linux-specific system calls and system - call arguments is missing.

-
-
- - - - - -
May 19, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/linuxkpi.4 4.html b/static/freebsd/man4/linuxkpi.4 4.html deleted file mode 100644 index 0a47b03a..00000000 --- a/static/freebsd/man4/linuxkpi.4 4.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - -
LINUXKPI(4)Device Drivers ManualLINUXKPI(4)
-
-
-

-

linuxkpi — Linux - Kernel Programming Interface support

-
-
-

-

The linuxkpi kernel module provides a - limited KPI (kernel programming interface) to allow Linux kernel drivers and - other Linux kernel code to be compiled on FreeBSD - and used along the FreeBSD kernel with little or no - modification.

-

While historically - , and certain vendor drivers - have used linuxkpi. - - for graphics driver support and linuxkpi_wlan(4) for - wireless drivers are prominent consumers.

-

linuxkpi is not to be confused with - linux(4) which provides limited Linux ABI (application - binary interface) compatibility to allow running Linux application binaries - unmodified on FreeBSD.

-
-
-

-

linuxkpi_wlan(4)

-
-
- - - - - -
June 13, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/linuxkpi_wlan.4 3.html b/static/freebsd/man4/linuxkpi_wlan.4 3.html deleted file mode 100644 index 7650ae28..00000000 --- a/static/freebsd/man4/linuxkpi_wlan.4 3.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - -
LINUXKPI_WLAN(4)Device Drivers ManualLINUXKPI_WLAN(4)
-
-
-

-

linuxkpi_wlan — - LinuxKPI 802.11 support

-
-
-

-

The linuxkpi_wlan kernel module provides - an 802.11 compat layer to translate between Linux 802.11 drivers and the - native net8011 wireless stack. It currently supports - - based drivers. Parts of the - - exist but there is no code for net80211 to drive it.

-

linuxkpi_wlan currently - supports the following - - operating modes:

-
-
-
client station in an infrastructure bss (IBSS).
-
-

Compat code for 802.11n (HT) and 802.11ac (VHT) is implemented but - support may vary for different drivers due to different KPI usage.

-

Crypto support for hardware acceleration needs to be enabled using - the compat.linuxkpi.80211.hw_crypto tunable. The - following cipher suites are supported:

-
-
-
Support for wlan_tkip(4) has to be manually enabled - using the compat.linuxkpi.80211.tkip tunable.
-
-
Support for wlan_ccmp(4) is available.
-
-
Support for wlan_gcmp(4) is available.
-
-Further cipher suites will be implemented as soon as - net80211(4) grows support. While it would be possible to - implement wlan_wep(4) support, it was decided not to do so - given has been deprecated since 2004. -

The list of supported drivers includes - iwlwifi(4), rtw88(4), and - rtw89(4).

-
-
-

-

The linuxkpi_wlan module supports the - following loader(8) tunable and read-only - sysctl(8) variables:

-
-
compat.linuxkpi.80211.hw_crypto
-
Turn on hardware crypto offload support. Default - ‘0’.
-
compat.linuxkpi.80211.tkip
-
Turn on support for wlan_tkip(4) offloading. Default - ‘0’.
-
-

The linuxkpi_wlan module supports the - following sysctl(8) variables:

-
-
compat.linuxkpi.80211.debug
-
If the kernel is compiled with IEEE80211_DEBUG or - LINUXKPI_DEBUG_80211 is manually enabled, the - sysctl is a bitmask to turn on individual debug messages. See - sys/compat/linuxkpi/common/src/linux_80211.h for - details.
-
compat.linuxkpi.80211.IF.dump_stas
-
Print statistics for a given, associated wlan(4) - interface; typically IF would be - .
-
compat.linuxkpi.80211.IF.dump_stas_queues
-
Like compat.linuxkpi.80211.IF.dump_stas but also - print queue statistics. This sysctl is ‘hidden’ and normally - only needed for debugging purposes.
-
-
-
-

-

iwlwifi(4), linuxkpi(4), - rtw88(4), rtw89(4), - wlan(4)

-
-
-

-

The linuxkpi_wlan module first appeared in - FreeBSD 13.1. Support for IEEE 802.11n and 802.11ac - in linuxkpi_wlan first appeared in - FreeBSD 14.3.

-
-
-

-

LinuxKPI 802.11 support was developed by Bjoern - A. Zeeb under sponsorship from the FreeBSD Foundation.

-
-
- - - - - -
December 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/liquidio.4 3.html b/static/freebsd/man4/liquidio.4 3.html deleted file mode 100644 index 91398bb5..00000000 --- a/static/freebsd/man4/liquidio.4 3.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - -
LIQUIDIO(4)Device Drivers ManualLIQUIDIO(4)
-
-
-

-

liquidio — Cavium - 10Gb/25Gb Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device lio
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_lio_load="YES"
-
-
-
-

-

The liquidio driver provides support for - 23XX 10Gb/25Gb Ethernet adapters. The driver supports Jumbo Frames, - Transmit/Receive checksum offload, TCP segmentation offload (TSO), Large - Receive Offload (LRO), VLAN tag insertion/extraction, VLAN checksum offload, - VLAN TSO, and Receive Side Steering (RSS)

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 16000.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The liquidio driver supports the following - cards:

-

-
    -
  • LiquidIO II CN2350 210SV/225SV
    • -
  • LiquidIO II CN2360 210SV/225SV
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.lio.fw_type
-
-

String that specifies type of firmware to be loaded. Default - is "nic". Use "none" to load firmware from - flash.

-
-
hw.lio.num_queues_per_pf0
-
-

Unsigned integers that specify number of queues per PF0. Valid - range is 0 to 64. Use 0 to derive autoconfigures based on the number of - cpus with a max of 8

-
-
hw.lio.num_queues_per_pf1
-
-

Unsigned integers that specify number of queues per PF1. Valid - range is 0 to 64. Use 0 to derive autoconfigures based on the number of - cpus with a max of 8

-
-
hw.lio.console_bitmask
-
-

Bitmask indicating which consoles have debug output redirected - to syslog.

-
-
hw.lio.rss
-
-

To enable/disable driver RSS support

-
-
hw.lio.hwlro
-
-

To enable/disable hardware LRO

-
-
-
-
-

-

For general information and support, go to the Cavium support - website at: http://support.cavium.com.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - vlan(4), ifconfig(8)

-
-
-

-

The liquidio device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The liquidio driver was written by - Derek Chickles - <derek.chickles@cavium.com>.

-
-
- - - - - -
August 17, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/lm75.4 3.html b/static/freebsd/man4/lm75.4 3.html deleted file mode 100644 index 3c1d4c1d..00000000 --- a/static/freebsd/man4/lm75.4 3.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - -
LM75(4)Device Drivers ManualLM75(4)
-
-
-

-

lm75 — lm75 i2c - digital temperature sensor driver

-
-
-

-

device iic -
- device iicbus -
- device lm75

-
-
-

-

The lm75 driver provides access to sensor - data and configuration over the iicbus(4).

-

It provides an easy and simple way to check the functionality of - an i2c bus as it provides read and write access to the - lm75 configuration register.

-

The access to lm75 data is made via the - sysctl(8) interface:

-
-
dev.lm75.0.%desc: LM75 temperature sensor
-dev.lm75.0.%driver: lm75
-dev.lm75.0.%location: addr=0x49
-dev.lm75.0.%pnpinfo: name=lm750 compat=national,lm75
-dev.lm75.0.%parent: iicbus3
-dev.lm75.0.temperature: 27.1C
-dev.lm75.0.thyst: 75.0C
-dev.lm75.0.tos: 80.0C
-dev.lm75.0.faults: 1
-dev.lm75.0.mode: comparator
-dev.lm75.0.polarity: active-low
-dev.lm75.0.shutdown: 0
-
-
-
dev.lm75.%d.temperature
-
Is the read-only value of the current temperature read by the sensor.
-
dev.lm75.%d.thyst
-
Sets the hysteresis temperature. Once the temperature gets over the - overtemperature shutdown value (tos) it needs to drop below the hysteresis - temperature to disable the output (interrupt) pin again.
-
dev.lm75.%d.tos
-
Sets the overtemperature shutdown value. Once the temperature gets over - this value the output pin will be enabled. The way the output (interrupt) - pin works, depends on the mode configuration.
-
dev.lm75.%d.faults
-
Is the number of faults that must occur consecutively to activate the - interrupt (output) pin. It can be set to 1, 2, 4, and 6.
-
dev.lm75.%d.mode
-
Sets the operation mode for the sensor interrupt pin. It can be set to - 'comparator' (default) or 'interrupt'.
-
dev.lm75.%d.polarity
-
Sets the polarity of the sensor interrupt pin. It can be set to - 'active-low' (default) or 'active-high'. Please note that the output pin - is an open-drain output and it needs a proper pull-up resistor to - work.
-
dev.lm75.%d.shutdown
-
When set to '1' it shuts down the sensor. The temperature conversion stops - but the sensor remains with its i2c bus active, i.e., it can be woken up - by setting this option to '0' again.
-
-

Please check the lm75 datasheet for more - details.

-

When used together with snmp_lm75(3) it allows - the monitoring of lm75 temperature data over - SNMP.

-

The lm75 driver supports both the low and - the high resolution models.

-

The low resolution model (lm75) provides a 9 bit output with the - LSB representing 0.5C.

-

The high resolution model (lm75a) provides an 11 bit output with - the LSB representing 0.125C.

-

The driver tries to auto-detect the lm75 - model, but the detection of some lm75 clones may not - work reliably.

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - lm75:

-
-
hint.lm75.%d.at
-
Is the iicbus(4) you are attaching to.
-
hint.lm75.%d.addr
-
Is the lm75 i2c address on the - iicbus(4).
-
-

On a FDT(4) based system, such as - ARM, the DTS part for a lm75 - device usually looks like:

-
-
i2c {
-	/* Properties describing the controller appear here. */
-	...
-	lm750@49 {
-		compatible = "national,lm75";
-		reg = <0x49>;
-	};
-};
-
-

Where:

-
-
compatible
-
Should always be set to "national,lm75".
-
reg
-
Indicates which 7-bit i2c address the lm75 is - wired at. lm75 temperature sensors can be wired to - 8 different addresses, allowing up to 8 sensors on the same - iicbus(4).
-
-
-
-

-

snmp_lm75(3), fdt(4), - iic(4), iicbus(4), - sysctl(8)

-
-
-

-

The lm75 driver first appeared in - FreeBSD 11.0.

-
-
-

-

The lm75 driver and this manual page were - written by Luiz Otavio O Souza - <loos@FreeBSD.org>.

-
-
- - - - - -
December 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/lo.4 3.html b/static/freebsd/man4/lo.4 3.html deleted file mode 100644 index 58444b20..00000000 --- a/static/freebsd/man4/lo.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
LO(4)Device Drivers ManualLO(4)
-
-
-

-

lo — software - loopback network interface

-
-
-

-

device loop

-
-
-

-

The loop interface is a software loopback - mechanism which may be used for performance analysis, software testing, - and/or local communication. As with other network interfaces, the loopback - interface must have network addresses assigned for each address family with - which it is to be used. These addresses may be set with the appropriate - ioctl(2) commands for corresponding address families. The - loopback interface should be the last interface configured, as protocols may - use the order of configuration as an indication of priority. The loopback - should - be - configured first unless no hardware interfaces exist.

-

If the transmit checksum offload capability flag is enabled on a - loopback interface, checksums will not be generated by IP, UDP, TCP, or SCTP - for packets sent on the interface.

-

If the receive checksum offload capability flag is enabled on a - loopback interface, checksums will not be validated by IP, UDP, TCP, or SCTP - for packets received on the interface.

-

By default, both receive and transmit checksum flags will be - enabled, in order to avoid the overhead of checksumming for local - communication where data corruption is unlikely. If transmit checksum - generation is disabled, then validation should also be disabled in order to - avoid packets being dropped due to invalid checksums.

-
-
-

-
-
lo%d: can't handle af%d.
-
The interface was handed a message with addresses formatted in an - unsuitable address family; the packet was dropped.
-
-
-
-

-

inet(4), intro(4)

-
-
-

-

The lo device appeared in - 4.2BSD. The current checksum generation and - validation avoidance policy appeared in FreeBSD - 8.0.

-
-
- - - - - -
June 23, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/lp.4 3.html b/static/freebsd/man4/lp.4 3.html deleted file mode 100644 index 0977e1f2..00000000 --- a/static/freebsd/man4/lp.4 3.html +++ /dev/null @@ -1,231 +0,0 @@ - - - - - - -
LP(4)Device Drivers ManualLP(4)
-
-
-

-

lp — printer port - Internet Protocol driver

-
-
-

- - - - - -
ifconfigplip0 myaddress hisaddress - [-link0] -

-
- device ppbus -
- device plip -
- device ppc

-
-
-
-

-

The lp driver allows a PC parallel printer - port to be used as a point-to-point network interface between two similarly - configured systems. Data is transferred 4 bits at a time, using the printer - status lines for input: hence there is no requirement for special - bidirectional hardware and any standard AT-compatible printer port with - working interrupts may be used.

-

During the boot process, for each plip - device which is probed and has an interrupt assigned, a corresponding - network device is created.

-

Configuring an lp device with - ifconfig(8) causes the corresponding - parallel port bus to be reserved for PLIP until the - network interface is configured 'down'.

-

The communication protocol is selected by the - link0 flag:

-
-
-
(default) Use FreeBSD mode (LPIP). This is the - simpler of the two modes and therefore slightly more efficient.
-
-
Use Crynwr/Linux compatible mode (CLPIP). This mode has a simulated - Ethernet packet header, and is easier to interface to other types of - equipment.
-
-

The interface MTU defaults to 1500, but may be set to any value. - Both ends of the link must be configured with the same MTU.

-
-

-

The cable connecting the two parallel ports should be wired as - follows:

-
-
	Pin	Pin	Description
-	2	15	Data0 -> ERROR*
-	3	13	Data1 -> SLCT
-	4	12	Data2 -> PE
-	5	10	Data3 -> ACK*
-	6	11	Data4 -> BUSY
-	15	2	ERROR* -> Data0
-	13	3	SLCT   -> Data1
-	12	4	PE     -> Data2
-	10	5	ACK*   -> Data3
-	11	6	BUSY   -> Data4
-	18-25	18-25	Ground
-
-

Cables with this wiring are widely available as 'Laplink' cables, - and are often coloured yellow.

-

The connections are symmetric, and provide 5 lines in each - direction (four data plus one handshake). The two modes use the same wiring, - but make a different choice of which line to use as handshake.

-
-
-

-

The signal lines are used as follows:

-
-
-
Data out, bit 0.
-
-
Data out, bit 1.
-
-
Data out, bit 2.
-
-
Handshake out.
-
-
Data out, bit 3.
-
-
Data in, bit 0.
-
-
Data in, bit 1.
-
-
Data in, bit 2.
-
-
Data in, bit 3.
-
-
Handshake in.
-
-

When idle, all data lines are at zero. Each byte is signalled in - four steps: sender writes the 4 most significant bits and raises the - handshake line; receiver reads the 4 bits and raises its handshake to - acknowledge; sender places the 4 least significant bits on the data lines - and lowers the handshake; receiver reads the data and lowers its - handshake.

-

The packet format has a two-byte header, comprising the fixed - values 0x08, 0x00, immediately followed by the IP header and data.

-

The start of a packet is indicated by simply signalling the first - byte of the header. The end of the packet is indicated by inverting the data - lines (i.e., writing the ones-complement of the previous nibble to be - transmitted) without changing the state of the handshake.

-

Note that the end-of-packet marker assumes that the handshake - signal and the data-out bits can be written in a single instruction - - otherwise certain byte values in the packet data would falsely be - interpreted as end-of-packet. This is not a problem for the PC printer port, - but requires care when implementing this protocol on other equipment.

-
-
-

-

The signal lines are used as follows:

-
-
-
Data out, bit 0.
-
-
Data out, bit 1.
-
-
Data out, bit 2.
-
-
Data out, bit 3.
-
-
Handshake out.
-
-
Data in, bit 0.
-
-
Data in, bit 1.
-
-
Data in, bit 2.
-
-
Data in, bit 3.
-
-
Handshake in.
-
-

When idle, all data lines are at zero. Each byte is signalled in - four steps: sender writes the 4 least significant bits and raises the - handshake line; receiver reads the 4 bits and raises its handshake to - acknowledge; sender places the 4 most significant bits on the data lines and - lowers the handshake; receiver reads the data and lowers its handshake. - [Note that this is the opposite nibble order to LPIP mode].

-

Packet format is:

-
-
Length (least significant byte)
-Length (most significant byte)
-12 bytes of supposed MAC addresses (ignored by FreeBSD).
-Fixed byte 0x08
-Fixed byte 0x00
-<IP datagram>
-Checksum byte.
-
-

The length includes the 14 header bytes, but not the length bytes - themselves nor the checksum byte.

-

The checksum is a simple arithmetic sum of all the bytes (again, - including the header but not checksum or length bytes). - FreeBSD calculates outgoing checksums, but does not - validate incoming ones.

-

The start of packet has to be signalled specially, since the line - chosen for handshake-in cannot be used to generate an interrupt. The sender - writes the value 0x08 to the data lines, and waits for the receiver to - respond by writing 0x01 to its data lines. The sender then starts signalling - the first byte of the packet (the length byte).

-

End of packet is deduced from the packet length and is not - signalled specially (although the data lines are restored to the zero, idle - state to avoid spuriously indicating the start of the next packet).

-
-
-
-

-

ppbus(4), ppc(4), - ifconfig(8)

-
-
-

-

Busy-waiting loops are used while handshaking bytes, (and worse - still when waiting for the receiving system to respond to an interrupt for - the start of a packet). Hence a fast system talking to a slow one will - consume excessive amounts of CPU. This is unavoidable in the case of CLPIP - mode due to the choice of handshake lines; it could theoretically be - improved in the case of LPIP mode.

-

Polling timeouts are controlled by counting loop iterations rather - than timers, and so are dependent on CPU speed. This is somewhat stabilised - by the need to perform (slow) ISA bus cycles to actually read the port.

-
-
- - - - - -
March 4, 1996FreeBSD 15.0
diff --git a/static/freebsd/man4/lpbb.4 4.html b/static/freebsd/man4/lpbb.4 4.html deleted file mode 100644 index dd5bb149..00000000 --- a/static/freebsd/man4/lpbb.4 4.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
LPBB(4)Device Drivers ManualLPBB(4)
-
-
-

-

lpbb — parallel - port I2C bit-banging interface

-
-
-

-

device iicbus -
- device iicbb

-

-
- device lpbb -
- device iic

-
-
-

-

The - - driver supports the Philips official I2C parallel bit-banging interface.

-
-
-                                         LS05 pin 14 (Vcc) o      -------
-                                                           |      |     |
-            +--+--+---------------------+--+--+------------+------+-o 1 |
-            |  |  |                     |  |  |           ===.1uF | +5V |
-  -------- [R][R][R] 3x10K       3x10K [R][R][R]   LS05    |      |     |
-  |      |  |  |  |                     |  |  |    pin 7 o-+------+-o 2 |
-  | 12 o-+--+  |  |   3|\ 4             |  |  |    (Gnd)          | GND |
-  | 17 o-+-----|--|----| >o-------------+--|--|--------------+    |     |
-  |      |     |  |    |/        8 /|9     |  |     10 /|11  +----+-o 3 |
-  | 15 o-+-----+--|--------------o< |------+--|------o< |----+    | SCL |
-  |      |        |   1|\ 2        \|         |        \|         |     |
-  |  9 o-+--------|----| >o-------------------+--------------+----+-o 4 |
-  |      |        |    |/                            6 /|5   |    | SDA |
-  | 11 o-+--------+----------------------------------o< |----+    -------
-  | 10 o-+-+                                           \|          4-pin
-  | 13 o-+-+--oGND                                              Connector
-  | 25 o-+-+      ------------------ Part List --------------------------
-  --------        | 1 - .1 uF capacitor   | 6 - 10K 5% resistors        |
-  25-pin male D   | 1 - 4-pin connector   | 1 - 25-pin male D connector |
-  connector to PC | 1 - 74LS05 open collector hex inverter              |
-  printer port    -------------------------------------------------------
-
-
-
-

-

iicbb(4), iicbus(4), - ppbus(4)

-
-
-

-

The lpbb manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
October 25, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/lpt.4 3.html b/static/freebsd/man4/lpt.4 3.html deleted file mode 100644 index 42ff0867..00000000 --- a/static/freebsd/man4/lpt.4 3.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
LPT(4)Device Drivers ManualLPT(4)
-
-
-

-

lpt — generic - printer device driver

-
-
-

-

device ppc -
- device ppbus -
- device lpt

-
-
-

-

The current - driver - is the port of the original lpt driver to the ppbus(4) - system.

-

One purpose of this port was to allow parallel port sharing with - other parallel devices. Secondly, inb()/outb() calls have been replaced by - ppbus function calls. lpt is now arch-independent thanks to the ppbus - interface. See ppbus(4) for more info about the ppbus - system.

-

The parallel port bus is allocated by lpt when the printer device - is opened and released only when the transfer is completed: either when the - device is closed or when the entire buffer is sent in interrupt driven - mode.

-

The driver can be configured to be either interrupt-driven, or to - poll the printer. Ports that are configured to be interrupt-driven can be - switched to polled mode by using the lptcontrol(8) - command.

-

Depending on your hardware, extended capabilities may be - configured with the lptcontrol(8) command. With an ECP/ISA - port, you can take advantage of FIFO and DMA.

-

In order to retrieve printer info from /dev/lpt0, just apply the - cat command to the device. If the printer supports - IEEE1284 nibble mode and has data to send to the host, you will get it.

-
-
-

-
-
/dev/lpt0
-
first parallel port driver
-
-
-
-

-

ppbus(4), ppc(4), - lptcontrol(8)

-
-
-

-

This driver replaces the functionality of the lpa driver, which is - now defunct.

-
-
-

-

There are lots of them, especially in cheap parallel port - implementations.

-

It is only possible to open a lpt port when a printer is connected - and on-line, making it impossible to run lptcontrol(8) - when there is no printer connected.

-

This driver could still stand a rewrite.

-
-
- - - - - -
February 14, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ltc430x.4 3.html b/static/freebsd/man4/ltc430x.4 3.html deleted file mode 100644 index d5122a4f..00000000 --- a/static/freebsd/man4/ltc430x.4 3.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - -
LTC430X(4)Device Drivers ManualLTC430X(4)
-
-
-

-

ltc430x — driver - for LTC4305 and LTC4306 I2C mux chips

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ltc430x
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ltc430x_load="YES"
-
-
-
-

-

The ltc430x driver supports the LTC4305 - and LTC4306 I2C bus multiplexer (mux) chips. It automatically connects an - upstream I2C bus to one of several downstream buses as needed when slave - devices on the downstream buses initiate I/O. More information on the - automatic switching behavior is available in - iicmux(4).

-
-
-

-

On an fdt(4) based system, an - ltc430x device node is defined as a child node of - its upstream i2c bus. The children of the ltc430x - node are additional i2c buses, which will have their own i2c slave devices - described in their child nodes.

-

The ltc430x driver conforms to the - standard i2c/i2c-mux-ltc4306.txt bindings document, - except that the following optional properties are not currently supported - and will be ignored if present:

-
    -
  • enable-gpios
    • -
  • gpio-controller
    • -
  • #gpio-cells
    • -
  • ltc,downstream-accelerators-enable
    • -
  • ltc,upstream-accelerators-enable
    • -
-

In addition, the following additional property is supported:

-
-
-
freebsd,ctlreg2
-
A value to store into the chip's control register 2 during initialization. - Consult the chip datasheet for the meaning of the various bits in the - register.
-
-
-
-
-

-

On a device.hints(5) based system, the following - hints are required:

-
-
-
hint.ltc430x.<unit>.at
-
The upstream iicbus(4) the - ltc430x instance is attached to.
-
hint.ltc430x.<unit>.addr
-
The slave address of the ltc430x instance on the - upstream bus.
-
hint.ltc430x.<unit>.chip_type
-
The type of chip the driver is controlling. Valid values are - “ltc4305” and “ltc4306”.
-
-
-

The following hints are optional:

-
-
-
hint.ltc430x.<unit>.ctlreg2
-
A value to store into the chip's control register 2 during initialization. - Consult the chip datasheet for the meaning of the various bits in the - register. This hint is optional; when missing, the driver does not update - control register 2.
-
hint.ltc430x.<unit>.idle_disconnect
-
Whether to disconnect all downstream busses from the upstream bus when - idle. If set to zero, the most recently used downstream bus is left - connected to the upstream bus after IO completes. Any non-zero value - causes all downstream busses to be disconnected when idle. This hint is - optional; when missing, the driver behaves as if it were zero.
-
-
-

When configured via hints, the driver automatically adds an iicbus - instance for every downstream bus supported by the chip. There is currently - no way to indicate used versus unused downstream channels.

-
-
-

-

iicbus(4), iicmux(4)

-
-
-

-

The ltc430x driver first appeared in - FreeBSD 13.0.

-
-
- - - - - -
September 2, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/mac.4 3.html b/static/freebsd/man4/mac.4 3.html deleted file mode 100644 index 0af6d005..00000000 --- a/static/freebsd/man4/mac.4 3.html +++ /dev/null @@ -1,287 +0,0 @@ - - - - - - -
MAC(4)Device Drivers ManualMAC(4)
-
-
-

-

mac — Mandatory - Access Control

-
-
-

-

options MAC

-
-
-

-
-

-

The Mandatory Access Control, or MAC, framework allows - administrators to finely control system security by providing for a loadable - security policy architecture. It is important to note that due to its - nature, MAC security policies may only restrict access relative to one - another and the base system policy; they cannot override traditional - UNIX security provisions such as file permissions - and superuser checks.

-

Currently, the following MAC policy modules are shipped with - FreeBSD:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
mac_biba(4)Biba integrity policyyesboot only
mac_bsdextended(4)File system firewallnoany time
mac_ddb(4)ddb(4) interface restrictionsnoany time
mac_do(4)Change command's uid/gidnoany time
mac_ifoff(4)Interface silencingnoany time
mac_ipacl(4)IP Address access controlnoany time
mac_lomac(4)Low-Watermark MAC policyyesboot only
mac_mls(4)Confidentiality policyyesboot only
mac_ntpd(4)Non-root NTP Daemon policynoany time
mac_partition(4)Process partition policyyesany time
mac_portacl(4)Port bind(2) access controlnoany time
mac_priority(4)Scheduling priority policynoany time
mac_seeotheruids(4)See-other-UIDs policynoany time
mac_test(4)MAC testing policynoany time
-
-
-

-

Each system subject (processes, sockets, etc.) and each system - object (file system objects, jails, sockets, etc.) can carry with it a MAC - label. MAC labels contain data in an arbitrary format taken into - consideration in making access control decisions for a given operation. Most - MAC labels on system subjects and objects can be modified directly or - indirectly by the system administrator. The format for a given policy's - label may vary depending on the type of object or subject being labeled. - More information on the format for MAC labels can be found in the - maclabel(7) man page.

-
-
-

-

By default, file system enforcement of labeled MAC policies relies - on a single file system label (see MAC - Labels) in order to make access control decisions for all the files in a - particular file system. With some policies, this configuration may not allow - administrators to take full advantage of features. In order to enable - support for labeling files on an individual basis for a particular file - system, the “multilabel” flag must be enabled on the file - system. To set the “multilabel” flag, drop to single-user mode - and unmount the file system, then execute the following command:

-

-
tunefs -l enable - filesystem
-

where filesystem is either the mount point - (in fstab(5)) or the special file (in - /dev) corresponding to the file system on which to - enable multilabel support.

-
-
-

-

Policy enforcement is divided into the following areas of the - system:

-
-
-
File system mounts, modifying directories, modifying files, etc.
-
-
Creating, modifying, removing, and attaching to jails
-
-
Loading, unloading, and retrieving statistics on loaded kernel - modules
-
-
Network interfaces, bpf(4), packet delivery and - transmission, interface configuration (ioctl(2), - ifconfig(8))
-
-
Creation of and operation on pipe(2) objects
-
-
Debugging (e.g. ktrace(2)), process visibility - (ps(1)), process execution - (execve(2)), signalling (kill(2))
-
-
Creation of and operation on socket(2) objects
-
-
Kernel environment (kenv(1)), system accounting - (acct(2)), reboot(2), - settimeofday(2), swapon(2), - sysctl(3), nfsd(8)-related - operations
-
-
mmap(2)-ed files
-
-
-
-

-

From the command line, each type of system object has its own - means for setting and modifying its MAC policy label.

- - - - - - - - - - - - - - - - - - - - - - - - - -
File system objectsetfmac(8), setfsmac(8)
Jailjail(8)
Network interfaceifconfig(8)
TTY (by login class)login.conf(5)
User (by login class)login.conf(5)
-

Additionally, the su(1) and - setpmac(8) utilities can be used to run a command with a - different process label than the shell's current label.

-
-
-

-

MAC security enforcement itself is transparent to application - programs, with the exception that some programs may need to be aware of - additional errno(2) returns from various system calls.

-

The interface for retrieving, handling, and setting policy labels - is documented in the mac(3) man page.

-
-
-
-

-

mac(3), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_do(4), mac_ifoff(4), - mac_ipacl(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_ntpd(4), mac_partition(4), - mac_portacl(4), mac_priority(4), - mac_seeotheruids(4), mac_stub(4), - mac_test(4), login.conf(5), - maclabel(7), jail(8), - getfmac(8), getpmac(8), - setfmac(8), setpmac(8), - mac(9)

-

Mandatory Access - Control, The FreeBSD Handbook, - https://docs.FreeBSD.org/en/books/handbook/mac/.

-
-
-

-

The mac implementation first appeared in - FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
January 16, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_biba.4 3.html b/static/freebsd/man4/mac_biba.4 3.html deleted file mode 100644 index 2c1611ce..00000000 --- a/static/freebsd/man4/mac_biba.4 3.html +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - -
MAC_BIBA(4)Device Drivers ManualMAC_BIBA(4)
-
-
-

-

mac_biba — Biba - data integrity policy

-
-
-

-

To compile Biba into your kernel, place the following lines in - your kernel configuration file:

-
options MAC -
-options MAC_BIBA
-

Alternately, to load the Biba module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_biba_load="YES"
-
-
-
-

-

The mac_biba policy module implements the - Biba integrity model, which protects the integrity of system objects and - subjects by means of a strict information flow policy. In Biba, all system - subjects and objects are assigned integrity labels, made up of hierarchal - grades, and non-hierarchal components. Together, these label elements permit - all labels to be placed in a partial order, with information flow - protections based on a dominance operator describing the order. The - hierarchal grade field is expressed as a value between 0 and 65535, with - higher values reflecting higher integrity. The non-hierarchal compartment - field is expressed as a set of up to 256 components, numbered from 0 to 255. - A complete label consists of both hierarchal and non-hierarchal - elements.

-

Three special label values exist:

- - - - - - - - - - - - - - - - - -
lower than all other labels
equal to all other labels
higher than all other labels
-

The “biba/high” label is - assigned to system objects which affect the integrity of the system as a - whole. The “biba/equal” label may be - used to indicate that a particular subject or object is exempt from the Biba - protections. These special label values are not specified as containing any - compartments, although in a label comparison, - “biba/high” appears to contain all - compartments, “biba/equal” the same - compartments as the other label to which it is being compared, and - “biba/low” none.

-

In general, Biba access control takes the following model:

-
    -
  • A subject at the same integrity level as an object may both read from and - write to the object as though Biba protections were not in place.
    • -
  • A subject at a higher integrity level than an object may write to the - object, but not read the object.
    • -
  • A subject at a lower integrity level than an object may read the object, - but not write to the object.
    • -
  • If the subject and object labels may not be compared in the partial order, - all access is restricted.
    • -
-

These rules prevent subjects of lower integrity from influencing - the behavior of higher integrity subjects by preventing the flow of - information, and hence control, from allowing low integrity subjects to - modify either a high integrity object or high integrity subjects acting on - those objects. Biba integrity policies may be appropriate in a number of - environments, both from the perspective of preventing corruption of the - operating system, and corruption of user data if marked as higher integrity - than the attacker. In traditional trusted operating systems, the Biba - integrity model is used to protect the Trusted Code Base (TCB).

-

The Biba integrity model is similar to - mac_lomac(4), with the exception that LOMAC permits access - by a higher integrity subject to a lower integrity object, but downgrades - the integrity level of the subject to prevent integrity rules from being - violated. Biba is a fixed label policy in that all subject and object label - changes are explicit, whereas LOMAC is a floating label policy.

-

The Biba integrity model is also similar to - mac_mls(4), with the exception that the dominance operator - and access rules are reversed, preventing the downward flow of information - rather than the upward flow of information. Multi-Level Security (MLS) - protects the confidentiality, rather than the integrity, of subjects and - objects.

-
-

-

Almost all system objects are tagged with an effective, active - label element, reflecting the integrity of the object, or integrity of the - data contained in the object. In general, objects labels are represented in - the following form:

-

-
biba/grade:compartments
-

For example:

-
-
biba/10:2+3+6
-biba/low
-
-

Subject labels consist of three label elements: an effective - (active) label, as well as a range of available labels. This range is - represented using two ordered Biba label elements, and when set on a - process, permits the process to change its active label to any label of - greater or equal integrity to the low end of the range, and lesser or equal - integrity to the high end of the range. In general, subject labels are - represented in the following form:

-

-
biba/effectivegrade:effectivecompartments(lograde:locompartments-
-
higrade:hicompartments
-) -

For example:

-
-
biba/10:2+3+6(5:2+3-20:2+3+4+5+6)
-biba/high(low-high)
-
-

Valid ranged labels must meet the following requirement regarding - their elements:

-

-
rangehigh - ≥ effective - ≥ rangelow
-

One class of objects with ranges currently exists, the network - interface. In the case of the network interface, the effective label element - references the default label for packets received over the interface, and - the range represents the range of acceptable labels of packets to be - transmitted over the interface.

-
-
-

-

The following sysctl(8) MIBs are available for - fine-tuning the enforcement of this MAC policy.

-
-
security.mac.biba.enabled
-
Enables enforcement of the Biba integrity policy. (Default: 1).
-
security.mac.biba.ptys_equal
-
Label pty(4)s as - “biba/equal” upon creation. - (Default: 0).
-
security.mac.biba.revocation_enabled
-
Revoke access to objects if the label is changed to dominate the subject. - (Default: 0).
-
-
-
-
-

-

mac(4), mac_bsdextended(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_partition(4), mac_portacl(4), - mac_seeotheruids(4), mac_test(4), - maclabel(7), mac(9)

-
-
-

-

The mac_biba policy module first appeared - in FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
- - - - - -
November 18, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_bsdextended.4 3.html b/static/freebsd/man4/mac_bsdextended.4 3.html deleted file mode 100644 index 9a9a1b2c..00000000 --- a/static/freebsd/man4/mac_bsdextended.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
MAC_BSDEXTENDED(4)Device Drivers ManualMAC_BSDEXTENDED(4)
-
-
-

-

mac_bsdextended — - file system firewall policy

-
-
-

-

To compile the file system firewall policy into your kernel, place - the following lines in your kernel configuration file:

-
options MAC -
-options MAC_BSDEXTENDED
-

Alternately, to load the file system firewall policy module at - boot time, place the following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_bsdextended_load="YES"
-
-
-
-

-

The mac_bsdextended security policy module - provides an interface for the system administrator to impose mandatory rules - regarding users and some system objects. Rules are uploaded to the module - (typically using ugidfw(8), or some other tool utilizing - libugidfw(3)) where they are stored internally and used to - determine whether to allow or deny specific accesses (see - ugidfw(8)).

-
-
-

-

While the traditional mac(9) entry points are - implemented, policy labels are not used; instead, access control decisions - are made by iterating through the internal list of rules until a rule which - denies the particular access is found, or the end of the list is reached. - The mac_bsdextended policy works similar to - ipfw(8) or by using a - . This means that not all rules are applied, only the first - matched rule; thus if Rule A allows access and Rule B blocks access, Rule B - will never be applied.

-
-
-

-

The following sysctls may be used to tweak the behavior of - mac_bsdextended:

-
-
security.mac.bsdextended.enabled
-
Set to zero or one to toggle the policy off or on.
-
security.mac.bsdextended.rule_count
-
List the number of defined rules, the maximum rule count is current set at - 256.
-
security.mac.bsdextended.rule_slots
-
List the number of rule slots currently being used.
-
security.mac.bsdextended.firstmatch_enabled
-
Toggle between the old all rules match functionality and the new first - rule matches functionality. This is enabled by default.
-
security.mac.bsdextended.logging
-
Log all access violations via the AUTHPRIV - syslog(3) facility.
-
security.mac.bsdextended.rules
-
Currently does nothing interesting.
-
-
-
-

-

libugidfw(3), syslog(3), - mac(4), mac_biba(4), - mac_ddb(4), mac_ifoff(4), - mac_lomac(4), mac_mls(4), - mac_none(4), mac_partition(4), - mac_portacl(4), mac_seeotheruids(4), - mac_test(4), ipfw(8), - ugidfw(8), mac(9)

-
-
-

-

The mac_bsdextended policy module first - appeared in FreeBSD 5.0 and was developed by the - TrustedBSD Project.

-

The "match first case" and logging capabilities were - later added by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
-

-

This software was contributed to the - FreeBSD Project by NAI Labs, the Security Research - Division of Network Associates Inc. under DARPA/SPAWAR contract - N66001-01-C-8035 (“CBOSS”), as part of the DARPA CHATS - research program.

-
-
- - - - - -
October 11, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_ddb.4 3.html b/static/freebsd/man4/mac_ddb.4 3.html deleted file mode 100644 index 14261b03..00000000 --- a/static/freebsd/man4/mac_ddb.4 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
MAC_DDB(4)Device Drivers ManualMAC_DDB(4)
-
-
-

-

mac_ddb — - Restricted kernel debugger interface policy

-
-
-

-

To compile the ddb policy into your kernel, place the following - lines in your kernel configuration file:

-
options MAC -
-options MAC_DDB
-

Alternately, to load the ddb module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_ddb_load="YES"
-
-
-
-

-

The mac_ddb policy module implements a MAC - policy which restricts the set of commands that can be used at the - ddb(4) command prompt. The subset of permitted commands is - limited to those which do not read or write to arbitrary memory locations. - This is done to deter the possible extraction of system secrets while still - allowing enough debugger functionality to diagnose a kernel panic. For - example, the trace or show - registers commands are allowed by this policy, but - show buffer - addr is not.

-

All debugger commands that are declared with the - DB_CMD_MEMSAFE flag are allowed by - mac_ddb. The policy provides validation functions to - conditionally allow some additional commands, based on the user provided - arguments.

-

When loaded, the mac_ddb policy also - ensures that only the ddb(4) debugger backend may be - executed; gdb(4) may not.

-
-

-

No labels are defined for mac_ddb.

-
-
-
-

-

ddb(4), mac(4), - mac_biba(4), mac_bsdextended(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_partition(4), mac_portacl(4), - mac_seeotheruids(4), mac_test(4), - mac(9)

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
June 29, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_do.4 3.html b/static/freebsd/man4/mac_do.4 3.html deleted file mode 100644 index 90ecc0ad..00000000 --- a/static/freebsd/man4/mac_do.4 3.html +++ /dev/null @@ -1,380 +0,0 @@ - - - - - - -
MAC_DO(4)Device Drivers ManualMAC_DO(4)
-
-
-

-

mac_do — policy - allowing unprivileged users to change process credentials

-
-
-

-

To compile the - - policy into your kernel, place the following lines in your kernel - configuration file:

-
options MAC -
-options MAC_DO
-

Alternately, to load this policy module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_do_load="YES"
-
-
-
-

-

The mac_do policy module allows - unprivileged users to change process credentials according to rules - configured by the administrator. It supports per-jail configuration.

-

Currently, the mac_do policy module only - produces effects to processes spawned from the - /usr/bin/mdo executable, please see - mdo(1) for more details on this program.

-
-
-

-

Rules specify which transitions of process credentials - mac_do will allow, based on current process - credentials and the desired final ones. They are passed by an administrator - in the form of a string having the specific syntax described below in a - top-bottom manner. They have been designed to be able to finely describe the - desired target credentials in a safe and compact way.

-
-

-

At the top, rules are a possibly empty list of individual rules - separated by a semi-colon (‘;’):

-
⟨rules⟩ -  ⟶  [⟨rule⟩ [‘;’ - ⟨rule⟩]*]
-They form a disjunction, i.e., mac_do authorizes a - credentials transition as soon as at least one rule in the list matches. -

One rule is composed of a ⟨from⟩ part (also called - “match”) and a ⟨to⟩ part (also called - “target”), in this order, separated by a greater-than sign - (‘>’):

-
⟨rule⟩ -  ⟶  ⟨from⟩ ‘>’ - ⟨to⟩
-
-
-

-

The first part of a rule, ⟨from⟩, is matched against - the credentials of the process requesting some credentials transition. It - has the form:

-
⟨from⟩ -  ⟶  ⟨type⟩ ‘=’ - ⟨id⟩
-

⟨type⟩ must be:

-
⟨type⟩ -  ⟶  [‘uid’ | - ‘gid’]
-i.e., one of the literal strings ‘uid’ or - ‘gid’. ⟨id⟩ must be the - numerical ID of a user or group and is matched against the current process - real ID of the corresponding type, and on type - ‘gid’ additionally against the - supplementary groups. -
-
-

-

The second part of a rule, ⟨to⟩, is a - comma-separated (‘,’) non-empty list - of target clauses:

-
⟨to⟩ -  ⟶  ⟨target_clause⟩ [‘,’ - ⟨target_clause⟩]*
-Target clauses of a given rule also form a disjunction, i.e., the IDs they - specify are alternatives for the target credentials, except in some cases - described below. -

The next subsections describe the syntax of target clauses, the - defaults that apply and the principle of non-redundancy and - non-contradiction in each rule's ⟨to⟩ part.

-
-
-

-

A target clause in a rule's ⟨to⟩ part must be of one - of the following forms:

-
⟨target_clause⟩ -  ⟶  ‘any’
-
⟨target_clause⟩ -  ⟶  ⟨flags⟩ ⟨type⟩ - ‘=’ ⟨id⟩
-The first form is a compact way to specify that any target credentials are - allowed. The second form is similar to that of ⟨from⟩ clauses, - with the following extensions: -
    -
  • ⟨id⟩ may also be a literal - ‘*’ or - ‘any’ or - ‘.’. - ‘*’ and - ‘any’ both designate any ID for the - specified ⟨type⟩, and are treated identically. - ‘.’ designates the process' current - IDs for the specified ⟨type⟩, as explained below.
    • -
  • ⟨flags⟩ may contain at most one of the - ‘+’, - ‘-’ and - ‘!’ characters, and may be non-empty - only when ⟨type⟩ is - ‘gid’. Additionally, if - ⟨id⟩ is ‘*’ or - ‘any’, only the - ‘+’ flag may appear.
    • -
-

For target clauses of ‘gid’ - type, an absence of flag indicates that the specified group ID is allowed as - the real, effective and/or saved group IDs (the “primary” - groups). Conversely, the presence of any allowed flag indicates that the - specification concerns supplementary groups. Each flag has a specific - meaning:

-
    -
  • ‘+’ indicates that the group ID is - allowed as a supplementary group.
    • -
  • ‘!’ indicates that the group ID is - mandatory, i.e., it must be listed in the supplementary groups.
    • -
  • ‘-’ indicates that the group ID must - not be listed in the supplementary groups.
    • -
-A specification with ‘-’ is only useful in - conjunction with a ‘+’-tagged - specification where only one of them has - ‘.’ as its ⟨id⟩. Target - clauses having the ‘!’ or - ‘-’ flag are “forcing” - clauses, and as such do not take part in the disjunction of the other target - clauses but rather unconditionally apply in their rule. -

‘.’ is a placeholder for IDs - that the calling process already has on privilege check. For type - ‘uid’, it designates any of the - process' real, effective or saved user IDs. For type - ‘gid’, its effect depends on whether - flags are present. If none is present, it designates any of the process' - real, effective or saved group IDs. If one is present, it designates any of - the process' supplementary groups.

-
-
-

-

If the ⟨to⟩ part does not list a target clause with - type ‘uid’, any of the current user - IDs of the calling process is accepted. In other words, in this case, - mac_do behaves as if a target clause of:

-
uid=.
-had been listed. -

Similarly, if the ⟨to⟩ part does not list a target - clause with type ‘gid’, all the groups - of the calling process are assumed to be required. More precisely, each of - the desired real, effective and saved group IDs must be one of the current - real, effective or saved group ID, and all supplementary groups must be the - same as those that are current. It is as if the ⟨to⟩ part had - contained the following two clauses:

-
gid=.,!gid=.
-
-
-

-

No two target clauses of a single rule may express the exact same - logical intent nor contradictory ones.

-

In practice, no two clauses may display the same ID except for - group IDs but only if, each time the same ID appears, it does so with a - different flag, or no flags only once. Additionally, the specified flags in - multiple occurrences must not be contradictory. For example, the same group - ID appearing with both ‘+’ and - ‘-’ will cause rejection of the - rule.

-
-
-

-

Any amount of whitespace is allowed around tokens of the above - grammar, except that there may be no spaces between ⟨flags⟩ - and ⟨id⟩ in target clauses.

-

For convenience, numerical IDs may be specified as negative - integers, which are then converted to unsigned ones as specified in the C - standard for the uid_t and gid_t - types, which are both 64-bit unsigned integers.

-
-
-
-

-

The following sysctl(8) knobs are available:

-
-
security.mac.do.enabled
-
Enable the mac_do policy. (Default: 1).
-
security.mac.do.rules
-
The list of credential rules, whose syntax is described in the - CREDENTIALS RULES section - above. This list is specific to each jail. Please see the - JAIL SUPPORT section below for more - details on the interaction of mac_do with - jails.
-
security.mac.do.print_parse_error
-
Logs a message on trying to set incorrect rules via the - security.mac.do.rules sysctl(8) - knob.
-
-
-
-

-

mac_do supports per-jail configuration of - rules.

-

By default, at creation, a new jail has no credentials rules, - effectively disabling mac_do for its processes.

-

The following jail parameters are defined:

-
-
mac.do
-
Possible values are: -
-
‘enable’
-
mac_do will enforce specific credential rules - in the jail. The mac.do.rules jail parameter - must also be set in this case.
-
‘disable’
-
Disables mac_do in the jail. Strictly - equivalent to jail creation's default behavior and to setting the - rules to an empty string.
-
‘inherit’
-
The jail's credentials rules are inherited from the jail's parent - (which may themselves have been inherited). Modified rules propagate - to all children jails configured for inheritance.
-
-
-
mac.do.rules
-
The credentials rules for the jail. It is always equal to the value that - can be retrieved by the sysctl(8) knob - security.mac.do.rules described in section - RUNTIME CONFIGURATION. If - set, and the jail parameter mac.do is not so - explicitly, the value of the latter will default to - ‘disable’ if empty, else to - ‘enable’.
-
-

Each jail must have mdo(1) installed at path - /usr/bin/mdo, as this path is currently not - configurable.

-
-
-

-

Here are several examples of single rules matching processes - having a real user ID of 10001:

-
-
-
Allows the process to switch all of its real, effective or saved user ID - to 10002, but keeping the groups it is already in, and with the same - primary/supplementary groups split.
-
-
Same as the first example, but also allows to switch to UID 10003 instead - of 10002, or possibly having both in different user IDs.
-
-
Same as the first example, but the new primary groups must be set to 10002 - and no supplementary groups should be set.
-
-
Same as the previous example, but in addition allowing to retain any - current supplementary groups.
-
-
Same as the previous example, but with the additional constraint that all - current supplementary groups must be kept.
-
-
Same as - ‘uid=10001>uid=10002,gid=10002,+gid=.’ - above, but 10001 cannot be retained as a supplementary group.
-
-
Same as - ‘uid=10001>uid=10002,gid=10002,+gid=.’ - above, with the additional constraint that 10003 must appear in the - supplementary groups.
-
-
Same as the first example, but lifting any constraints on groups, allowing - the process to become part of any groups it sees fit.
-
-

Here are several examples of single rules matching processes - having 10001 as their real group IDs or in their supplementary groups:

-
-
-
Makes 10001 a more powerful ‘wheel’ - group, allowing its members to switch to root without password.
-
-
Allows the process to enter GID 10002 as a primary group, but only if - giving up all its supplementary groups.
-
-
Same as the previous example, but allows to retain any current - supplementary groups.
-
-
Same as the previous example, but with the additional constraint that all - current supplementary groups must be kept.
-
-
-
-

-

mdo(1), setcred(2), - mac(4), jail(8), - sysctl(8)

-
-
-

-

Olivier Certner - <olce@FreeBSD.org> -
- Baptiste Daroussin - <bapt@FreeBSD.org>

-
-
-

-

Currently, mac_do considers only - credentials transitions requested through the setcred(2) - system call. This system call was in large part created so that - mac_do can see whole credentials transitions to - decide whether to authorize them, which the traditional UNIX's piecewise - approach of successively changing different parts of them cannot allow.

-

However, calls to traditional or standard credentials-changing - functions can be considered as full transitions on their own, however - limited, and as such should be equally monitored by - mac_do. Future work will lift this restriction.

-
-
-

-

The threat model for mac_do is to consider - userland programs as generally untrustable to decide upon which credentials - changes are acceptable. It is in contrast with the traditional UNIX way to - change credentials, in which specialized programs are installed with the - setuid bit, giving them full administrator privileges so that they are - effectively able to establish new ones. Vulnerabilities in such - credentials-changing programs can have catastrophic consequences on the - integrity of the system.

-

Consequently, mac_do does not rely on - companion userland programs to decide whether some credentials transition is - acceptable. Instead, it maintains its own configuration independently from - the userland password and group databases. Establishing this configuration - currently itself relies on userland programs issuing calls to - sysctl(3) or jail(2). It should thus be - established near system boot or jail start, before any possible attacks - could happen on the system, and further measures should be taken to ensure - that potential corruptions does not affect the configuration in subsequent - restarts, such as re-establishing pristine state or ensuring that the boot - procedure up to the configuration of mac_do can be - trusted.

-
-
- - - - - -
June 11, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_ifoff.4 3.html b/static/freebsd/man4/mac_ifoff.4 3.html deleted file mode 100644 index 119b4f53..00000000 --- a/static/freebsd/man4/mac_ifoff.4 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
MAC_IFOFF(4)Device Drivers ManualMAC_IFOFF(4)
-
-
-

-

mac_ifoff — - interface silencing policy

-
-
-

-

To compile the interface silencing policy into your kernel, place - the following lines in your kernel configuration file:

-
options MAC -
-options MAC_IFOFF
-

Alternately, to load the interface silencing policy module at boot - time, place the following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_ifoff_load="YES"
-
-
-
-

-

The mac_ifoff interface silencing module - allows administrators to enable and disable incoming and outgoing data flow - on system network interfaces via the sysctl(8) - interface.

-

To disable network traffic over the loopback - (lo(4)) interface, set the sysctl(8) OID - security.mac.ifoff.lo_enabled to 0 (default 1).

-

To enable network traffic over other interfaces, set the - sysctl(8) OID - security.mac.ifoff.other_enabled to 1 (default 0).

-

To allow BPF traffic to be received, even while other traffic is - disabled, set the sysctl(8) OID - security.mac.ifoff.bpfrecv_enabled to 1 (default - 0).

-
-

-

No labels are defined.

-
-
-
-

-

mac(4), mac_bsdextended(4), - mac_lomac(4), mac_mls(4), - mac_none(4), mac_partition(4), - mac_portacl(4), mac_seeotheruids(4), - mac_test(4), mac(9)

-
-
-

-

The mac_ifoff policy module first appeared - in FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
July 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_ipacl.4 3.html b/static/freebsd/man4/mac_ipacl.4 3.html deleted file mode 100644 index 6a52119a..00000000 --- a/static/freebsd/man4/mac_ipacl.4 3.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - -
MAC_IPACL(4)Device Drivers ManualMAC_IPACL(4)
-
-
-

-

mac_ipacl — IP - Address access control policy

-
-
-

-

Add the following lines in your kernel configuration file to - compile the IP address access control policy into your kernel:

-
options MAC -
-options MAC_IPACL
-

To load the mac_ipacl policy module at boot time, add the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5) add:

-

-
mac_ipacl_load="YES"
-
-
-

-

The mac_ipacl policy allows the root of - the host to use the sysctl(8) interface to limit the - VNET(9) jail's ability to set IPv4 and IPv6 addresses. So, - the host can define rules for jails and their interfaces about IP addresses - with sysctl(8) MIBs.

-

Its default behavior is to deny all IP addresses for the jail if - mac_ipacl policy is enforced and allow/deny IP (or - subnets) according to the security.mac.ipacl.rules - string specified with sysctl(8)

-
-

-

The following sysctl(8) MIBs are used to control - enforcement and behavior of this MAC Policy.

-
-
security.mac.ipacl.ipv4
-
Enforce mac_ipacl for IPv4 addresses. (Default: - 1).
-
security.mac.ipacl.ipv6
-
Enforce mac_ipacl for IPv6 addresses. (Default: - 1).
-
security.mac.ipacl.rules
-
The IP address access control list is specified in the following format: -

-
jid,allow,interface,addr_family,IP_addr/prefix[@jid,...]
-
-
jid
-
Describe the jail id of the jail for which the rule is written.
-
allow
-
1 for allow and 0 for deny. Decides action performed for the - rule.
-
interface
-
Name of the interface the rule is enforced for. If the interface is - left empty then it is a wildcard to enforce the rule for all - interfaces.
-
addr_family
-
Address family of the IP_addr. The input to be given as AF_INET or - AF_INET6 string only.
-
IP_addr
-
IP address (or subnet) to be allowed/denied. Action depends on the - prefix length.
-
prefix
-
Prefix length of the subnet to be enforced by the policy. -1 implies - the policy is enforced for the individual IP address. For a - non-negative value, a range of IP addresses (present in subnet) which - is calculated as subnet = IP_addr & mask.
-
-
-
-
-
-
-

-

Behavior of the mac_ipacl policy module - for different inputs of sysctl variable:

-
-
1.
-
Assign ipv4=1, ipv6=0 and - rules="1,1,,AF_INET,169.254.123.123/-1" -

It allow only 169.254.123.123 IPv4 address for all interfaces - (wildcard) of jail 1. It allows all IPv6 addresses since the policy is - not enforced for IPv6.

-
-
2.
-
Assign ipv4=1, ipv6=1 and - rules="1,1,epair0b,AF_INET6,fe80::/32@1,0,epair0b,AF_INET6,fe80::abcd/-1" -

It denies all IPv4 addresses as the policy is enforced but no - rules are specified about it. It allows all IPv6 addresses in subnet - fe80::/32 except fe80::abcd for interface epair0b only.

-
-
3.
-
Assign ipv4=1, ipv6=1, - rules="2,1,,AF_INET6,fc00::/7@2,0,,AF_INET6,fc00::1111:2200/120@2,1,,AF_INET6,fc00::1111:2299/-1@1,1,,AF_INET,198.51.100.0/24" -

It allows IPv4 in subnet 198.51.100.0/24 for jail 2 and all - interfaces. It allows IPv6 addresses in subnet fc00::/7 but denies - subnet fc00::1111:2200/120, and allows individual IP fc00::1111:2299 - from the denied subnet for all interfaces in jail 2.

-
-
-Please refer to mac/ipacl tests-framework for wide variety of examples on using - the ipacl module. -
-
-

-

In the case where multiple rules are applicable to an IP address - or a set of IP addresses, the rule that is defined later in the list - determines the outcome, disregarding any previous rule for that IP - address.

-
-
-

-

Rules are given with sysctl interface which gets very complex to - give them all in command line. It has to be simplified with a better way to - input those rules.

-
-
-

-

mac(4), mac(9)

-
-
-

-

The mac_ipacl policy module was developed - as a Google Summer of Code Project in 2019 by Shivank - Garg - <shivank@FreeBSD.org> - under the guidance of Bjoern A. Zeeb - <bz@FreeBSD.org>.

-
-
- - - - - -
July 25, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_lomac.4 3.html b/static/freebsd/man4/mac_lomac.4 3.html deleted file mode 100644 index 276778db..00000000 --- a/static/freebsd/man4/mac_lomac.4 3.html +++ /dev/null @@ -1,177 +0,0 @@ - - - - - - -
MAC_LOMAC(4)Device Drivers ManualMAC_LOMAC(4)
-
-
-

-

mac_lomac — - Low-watermark Mandatory Access Control data integrity - policy

-
-
-

-

To compile LOMAC into your kernel, place the following lines in - your kernel configuration file:

-
options MAC -
-options MAC_LOMAC
-

Alternately, to load the LOMAC module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_lomac_load="YES"
-
-
-
-

-

The mac_lomac policy module implements the - LOMAC integrity model, which protects the integrity of system objects and - subjects by means of an information flow policy coupled with the subject - demotion via floating labels. In LOMAC, all system subjects and objects are - assigned integrity labels, made up of one or more hierarchical grades, - depending on their types. Together, these label elements permit all labels - to be placed in a partial order, with information flow protections and - demotion decisions based on a dominance operator describing the order. The - hierarchal grade field or fields are expressed as a value between 0 and - 65535, with higher values reflecting higher integrity.

-

Three special label component values exist:

- - - - - - - - - - - - - - - - - -
dominated by all other labels
equal to all other labels
dominates all other labels
-

The “high” label is assigned - to system objects which affect the integrity of the system as a whole. The - “equal” label may be used to indicate - that a particular subject or object is exempt from the LOMAC protections. - For example, a label of - “lomac/equal(equal-equal)” might be - used on a subject which is to be used to administratively relabel anything - on the system.

-

Almost all system objects are tagged with a single, active label - element, reflecting the integrity of the object, or integrity of the data - contained in the object. File system objects may contain an additional - auxiliary label which determines the inherited integrity level for new files - created in a directory or the alternate label assumed by the subject upon - execution of an executable. In general, objects labels are represented in - the following form:

-

-
lomac/grade[auxgrade]
-

For example:

-
-
lomac/10[2]
-lomac/low
-
-

Subject labels consist of three label elements: a single (active) - label, as well as a range of available labels. This range is represented - using two ordered LOMAC label elements, and when set on a process, permits - the process to change its active label to any label of greater or equal - integrity to the low end of the range, and lesser or equal integrity to the - high end of the range. In general, subject labels are represented in the - following form:

-

-
lomac/singlegrade(lograde-higrade
-) -

Modification of objects is restricted to access via the following - comparison:

-

-
subject::higrade - ≥ - target-object::grade
-

Modification of subjects is the same, as the target subject's - single grade is the only element taken into comparison.

-

Demotion of a subject occurs when the following comparison is - true:

-

-
subject::singlegrade - > - object::grade
-

When demotion occurs, the subject's - singlegrade and higrade are - reduced to the object's grade, as well as the lograde - if necessary. When the demotion occurs, in addition to the permission of the - subject being reduced, shared mmap(2) objects which it has - opened in its memory space may be revoked according to the following - sysctl(3) variables:

-

-
    -
  • security.mac.lomac.revocation_enabled
    • -
  • security.mac.enforce_vm
    • -
  • security.mac.mmap_revocation
    • -
  • security.mac.mmap_revocation_via_cow
    • -
-

Upon execution of a file, if the executable has an auxiliary - label, and that label is within the current range of - lograde-higrade, it will be - assumed by the subject immediately. After this, demotion is performed just - as with any other read operation, with the executable as the target. Through - the use of auxiliary labels, programs may be initially executed at a lower - effective integrity level, while retaining the ability to raise it - again.

-

These rules prevent subjects of lower integrity from influencing - the behavior of higher integrity subjects by preventing the flow of - information, and hence control, from allowing low integrity subjects to - modify either a high integrity object or high integrity subjects acting on - those objects. LOMAC integrity policies may be appropriate in a number of - environments, both from the perspective of preventing corruption of the - operating system, and corruption of user data if marked as higher integrity - than the attacker.

-

The LOMAC security model is quite similar to that of - mac_biba(4) and mac_mls(4) in various - ways. More background information on this can be found in their respective - man pages.

-
-
-

-

mmap(2), sysctl(3), - mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_mls(4), - mac_none(4), mac_partition(4), - mac_portacl(4), mac_seeotheruids(4), - mac_test(4), mac(9)

-
-
-

-

The mac_lomac policy module first appeared - in FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
- - - - - -
February 25, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_mls.4 3.html b/static/freebsd/man4/mac_mls.4 3.html deleted file mode 100644 index 490713e0..00000000 --- a/static/freebsd/man4/mac_mls.4 3.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - -
MAC_MLS(4)Device Drivers ManualMAC_MLS(4)
-
-
-

-

mac_mls — - Multi-Level Security confidentiality policy

-
-
-

-

To compile MLS into your kernel, place the following lines in your - kernel configuration file:

-
options MAC -
-options MAC_MLS
-

Alternately, to load the MLS module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_mls_load="YES"
-
-
-
-

-

The mac_mls policy module implements the - Multi-Level Security, or MLS model, which controls access between subjects - and objects based on their confidentiality by means of a strict information - flow policy. Each subject and object in the system has an MLS label - associated with it; each subject's MLS label contains information on its - clearance level, and each object's MLS label contains information on its - classification.

-

In MLS, all system subjects and objects are assigned - confidentiality labels, made up of a sensitivity level and zero or more - compartments. Together, these label elements permit all labels to be placed - in a partial order, with confidentiality protections based on a dominance - operator describing the order. The sensitivity level is expressed as a value - between 0 and 65535, with higher values reflecting higher sensitivity - levels. The compartment field is expressed as a set of up to 256 components, - numbered from 1 to 256. A complete label consists of both sensitivity and - compartment elements.

-

With normal labels, dominance is defined as a label having a - higher or equal active sensitivity level, and having at least all of the - same compartments as the label to which it is being compared. With respect - to label comparisons, “lower” is - defined as being dominated by the label to which it is being compared, and - “higher” is defined as dominating the - label to which it is being compared, and - “equal” is defined as both labels - being able to satisfy the dominance requirements over one another.

-

Three special label values exist:

- - - - - - - - - - - - - - - - - -
dominated by all other labels
equal to all other labels
dominates all other labels
-

The “mls/equal” label may be - applied to subjects and objects for which no enforcement of the MLS security - policy is desired.

-

The MLS model enforces the following basic restrictions:

-
    -
  • Subjects may not observe the processes of another subject if its clearance - level is lower than the clearance level of the object it is attempting to - observe.
    • -
  • Subjects may not read, write, or otherwise observe objects without proper - clearance (e.g. subjects may not observe objects whose classification - label dominates its own clearance label)
    • -
  • Subjects may not write to objects with a lower classification level than - its own clearance level.
    • -
  • A subject may read and write to an object if its clearance level is equal - to the object's classification level as though MLS protections were not in - place.
    • -
-

These rules prevent subjects of lower clearance from gaining - access information classified beyond its clearance level in order to protect - the confidentiality of classified information, subjects of higher clearance - from writing to objects of lower classification in order to prevent the - accidental or malicious leaking of information, and subjects of lower - clearance from observing subjects of higher clearance altogether. In - traditional trusted operating systems, the MLS confidentiality model is used - in concert with the Biba integrity model (mac_biba(4)) in - order to protect the Trusted Code Base (TCB).

-
-

-

Almost all system objects are tagged with an effective, active - label element, reflecting the classification of the object, or - classification of the data contained in the object. In general, object - labels are represented in the following form:

-

-
mls/grade:compartments
-

For example:

-
-
mls/10:2+3+6
-mls/low
-
-

Subject labels consist of three label elements: an effective - (active) label, as well as a range of available labels. This range is - represented using two ordered MLS label elements, and when set on a process, - permits the process to change its active label to any label of greater or - equal integrity to the low end of the range, and lesser or equal integrity - to the high end of the range. In general, subject labels are represented in - the following form:

-

-
mls/effectivegrade:effectivecompartments(lograde:locompartments-
-
higrade:hicompartments
-) -

For example:

-
-
mls/10:2+3+6(5:2+3-20:2+3+4+5+6)
-mls/high(low-high)
-
-

Valid ranged labels must meet the following requirement regarding - their elements:

-

-
rangehigh - ≥ effective - ≥ rangelow
-

One class of objects with ranges currently exists, the network - interface. In the case of the network interface, the effective label element - references the default label for packets received over the interface, and - the range represents the range of acceptable labels of packets to be - transmitted over the interface.

-
-
-

-

The following sysctl(8) MIBs are available for - fine-tuning the enforcement of this MAC policy.

-
-
security.mac.mls.enabled
-
Enables the enforcement of the MLS confidentiality policy. (Default: - 1).
-
security.mac.mls.ptys_equal
-
Label pty(4)s as - “mls/equal” upon creation. (Default: - 0).
-
security.mac.mls.revocation_enabled
-
Revoke access to objects if the label is changed to a more sensitive level - than the subject. (Default: 0).
-
-
-
-
-

-

Currently, the mac_mls policy relies on - superuser status (suser(9)) in order to change network - interface MLS labels. This will eventually go away, but it is currently a - liability and may allow the superuser to bypass MLS protections.

-
-
-

-

mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_lomac(4), - mac_none(4), mac_partition(4), - mac_portacl(4), mac_seeotheruids(4), - mac_test(4), maclabel(7), - mac(9)

-
-
-

-

The mac_mls policy module first appeared - in FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Laboratories, - the Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
July 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_none.4 4.html b/static/freebsd/man4/mac_none.4 4.html deleted file mode 100644 index e1ac7440..00000000 --- a/static/freebsd/man4/mac_none.4 4.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
MAC_NONE(4)Device Drivers ManualMAC_NONE(4)
-
-
-

-

mac_none — null - MAC policy module

-
-
-

-

To compile the null policy into your kernel, place the following - lines in your kernel configuration file:

-
options MAC -
-options MAC_NONE
-

Alternately, to load the none module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_none_load="YES"
-
-
-
-

-

The mac_none policy module implements a - none MAC policy that has no effect on access control in the system. Unlike - mac_stub(4), none of the MAC entry points are defined.

-
-

-

No labels are defined for mac_none.

-
-
-
-

-

mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_partition(4), - mac_portacl(4), mac_seeotheruids(4), - mac_stub(4), mac_test(4), - mac(9)

-
-
-

-

The mac_none policy module first appeared - in FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
July 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_ntpd.4 3.html b/static/freebsd/man4/mac_ntpd.4 3.html deleted file mode 100644 index 56746190..00000000 --- a/static/freebsd/man4/mac_ntpd.4 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
MAC_NTPD(4)Device Drivers ManualMAC_NTPD(4)
-
-
-

-

mac_ntpd — policy - allowing ntpd to run as non-root user

-
-
-

-

To compile the ntpd policy into your kernel, place the following - lines in your kernel configuration file:

-
options MAC -
-options MAC_NTPD
-

Alternately, to load the ntpd policy module at boot time, place - the following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_ntpd_load="YES"
-
-
-
-

-

The mac_ntpd policy grants any process - running as user ‘ntpd’ (uid 123) the privileges needed to - manipulate system time, and to (re-)bind to the privileged NTP port.

-

When ntpd(8) is started with - ‘-u - <user>[:group]’ on the command line, it - performs all initializations requiring root privileges, then drops root - privileges by switching to the given user id. From that point on, the only - privileges it requires are the ability to manipulate system time, and the - ability to re-bind a UDP socket to the NTP port (port 123) after a network - interface change.

-

With the mac_ntpd policy active, it may - also be possible to start ntpd as a non-root user, because the default ntpd - options don't require any additional root privileges beyond those granted by - the policy.

-
-

-

The exact set of kernel privileges granted to any process running - with the configured uid is:

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

-

The following sysctl(8) MIBs are available for - fine-tuning this MAC policy. All sysctl(8) variables can - also be set as loader(8) tunables in - loader.conf(5).

-
-
security.mac.ntpd.enabled
-
Enable the mac_ntpd policy. (Default: 1).
-
security.mac.ntpd.uid
-
The numeric uid of the ntpd user. (Default: 123).
-
-
-
-
-

-

mac(4), ntpd(8)

-
-
-

-

MAC first appeared in FreeBSD 5.0 and - mac_ntpd first appeared in FreeBSD - 12.0.

-
-
- - - - - -
July 20, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_partition.4 3.html b/static/freebsd/man4/mac_partition.4 3.html deleted file mode 100644 index a287bc55..00000000 --- a/static/freebsd/man4/mac_partition.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
MAC_PARTITION(4)Device Drivers ManualMAC_PARTITION(4)
-
-
-

-

mac_partition — - process partition policy

-
-
-

-

To compile the process partition policy into your kernel, place - the following lines in your kernel configuration file:

-
options MAC -
-options MAC_PARTITION
-

Alternately, to load the process partition module at boot time, - place the following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_partition_load="YES"
-
-
-
-

-

The mac_partition policy module implements - a process partition policy, which allows administrators to place running - processes into “partitions”, based on their numeric process - partition (specified in the process's MAC label). Processes with a specified - partition can only see processes that are in the same partition. If no - partition is specified for a process, it can see all other processes in the - system (subject to other MAC policy restrictions not defined in this man - page). No provisions for placing processes into multiple partitions are - available.

-
-

-

Partition labels take on the following format:

-

-
partition/value
-

Where value can be any integer value or - “none”. For example:

-
-
partition/1
-partition/20
-partition/none
-
-
-
-
-

-

mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_portacl(4), mac_seeotheruids(4), - mac_test(4), maclabel(7), - mac(9)

-
-
-

-

The mac_partition policy module first - appeared in FreeBSD 5.0 and was developed by the - TrustedBSD Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
July 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_portacl.4 3.html b/static/freebsd/man4/mac_portacl.4 3.html deleted file mode 100644 index f197a0e9..00000000 --- a/static/freebsd/man4/mac_portacl.4 3.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - -
MAC_PORTACL(4)Device Drivers ManualMAC_PORTACL(4)
-
-
-

-

mac_portacl — - network port access control policy

-
-
-

-

To compile the port access control policy into your kernel, place - the following lines in your kernel configuration file:

-
options MAC -
-options MAC_PORTACL
-

Alternately, to load the port access control policy module at boot - time, place the following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-

-
mac_portacl_load="YES"
-
-
-

-

The mac_portacl policy allows - administrators to administratively limit binding to local UDP and TCP ports - via the sysctl(8) interface.

-

In order to enable the mac_portacl policy, - MAC policy must be enforced on sockets (see mac(4)), and - the port(s) protected by mac_portacl must not be - included in the range specified by the - net.inet.ip.portrange.reservedlow and - net.inet.ip.portrange.reservedhigh - sysctl(8) MIBs.

-

The mac_portacl policy only affects ports - explicitly bound by a user process (either for a listen/outgoing TCP socket, - or a send/receive UDP socket). This policy will not limit ports bound - implicitly for outgoing connections where the process has not explicitly - selected a port: these are automatically selected by the IP stack.

-

When mac_portacl is enabled, it will - control binding access to ports up to the port number set in the - security.mac.portacl.port_high - sysctl(8) variable. By default, all attempts to bind to - mac_portacl controlled ports will fail if not - explicitly allowed by the port access control list, though binding by the - superuser will be allowed, if the sysctl(8) variable - security.mac.portacl.suser_exempt is set to a non-zero - value.

-
-

-

The following sysctl(8) MIBs are available for - fine-tuning the enforcement of this MAC policy. All - sysctl(8) variables, except - security.mac.portacl.rules, can also be set as - loader(8) tunables in - loader.conf(5).

-
-
security.mac.portacl.enabled
-
Enforce the mac_portacl policy. (Default: 1).
-
security.mac.portacl.port_high
-
The highest port number mac_portacl will enforce - rules for. (Default: 1023).
-
security.mac.portacl.rules
-
The port access control list is specified in the following format: -

-
idtype:id:protocol:port[,idtype:id:protocol:port,...]
-
-
idtype
-
Describes the type of subject match to be performed. Either - uid for user ID matching, or - gid for group ID matching.
-
id
-
The user or group ID (depending on idtype) - allowed to bind to the specified port. -
NOTE: User and group names are not valid; only the - actual ID numbers may be used.
-
-
protocol
-
Describes which protocol this entry applies to. Either - tcp or udp are - supported.
-
port
-
Describes which port this entry applies to. -
NOTE: MAC security policies may not override other - security system policies by allowing accesses that they may deny, such - as net.inet.ip.portrange.reservedlow / - net.inet.ip.portrange.reservedhigh.
- If the specified port falls within the range specified, the - mac_portacl entry will not function (i.e., - even the specified user/group may not be able to bind to the specified - port).
-
-
-
security.mac.portacl.suser_exempt
-
Allow superuser (i.e., root) to bind to all - mac_portacl protected ports, even if the port - access control list does not explicitly allow this. (Default: 1).
-
security.mac.portacl.autoport_exempt
-
Allow applications to use automatic binding to port 0. Applications use - port 0 as a request for automatic port allocation when binding an IP - address to a socket. This tunable will exempt port 0 allocation from rule - checking. (Default: 1).
-
-
-
-
-

-

mac(3), ip(4), - mac_biba(4), mac_bsdextended(4), - mac_ddb(4), mac_ifoff(4), - mac_mls(4), mac_none(4), - mac_partition(4), mac_seeotheruids(4), - mac_test(4), mac(9)

-
-
-

-

MAC first appeared in FreeBSD 5.0 and - mac_portacl first appeared in - FreeBSD 5.1.

-
-
-

-

This software was contributed to the - FreeBSD Project by NAI Labs, the Security Research - Division of Network Associates Inc. under DARPA/SPAWAR contract - N66001-01-C-8035 (“CBOSS”), as part of the DARPA CHATS - research program.

-
-
- - - - - -
December 9, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_priority.4 3.html b/static/freebsd/man4/mac_priority.4 3.html deleted file mode 100644 index 13bf80f9..00000000 --- a/static/freebsd/man4/mac_priority.4 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
MAC_PRIORITY(4)Device Drivers ManualMAC_PRIORITY(4)
-
-
-

-

mac_priority — - policy for scheduling privileges of non-root - users

-
-
-

-

To compile the mac_priority policy into your kernel, place the - following lines in your kernel configuration file:

-
options MAC -
-options MAC_PRIORITY
-

Alternately, to load the mac_priority policy module at boot time, - place the following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_priority_load="YES"
-
-
-
-

-

The mac_priority policy grants scheduling - privileges based on group(5) membership. Users or - processes in the group ‘realtime’ (gid 47) are allowed to run - threads and processes with realtime scheduling priority. Users or processes - in the group ‘idletime’ (gid 48) are allowed to run threads - and processes with idle scheduling priority.

-

With the mac_priority realtime policy - active, privileged users may use the rtprio(1) utility to - start processes with realtime priority. Privileged applications can promote - threads and processes to realtime priority through the - rtprio(2) system calls.

-

When the idletime policy is active, privileged users may use the - idprio(1) utility to start processes with idle priority. - Privileged applications can demote threads and processes to idle priority - through the rtprio(2) system calls.

-
-

-

The realtime policy grants the following kernel privileges to any - process running with the realtime group id:

-
-
-
-
-
-
-

The kernel privilege granted by the idletime policy is:

-
-
-
-
-
-
-

-

The following sysctl(8) MIBs are available for - fine-tuning this MAC policy. All sysctl(8) variables can - also be set as loader(8) tunables in - loader.conf(5).

-
-
security.mac.priority.realtime
-
Enable the realtime policy. (Default: 1).
-
security.mac.priority.realtime_gid
-
The numeric gid of the realtime group. (Default: 47).
-
security.mac.priority.idletime
-
Enable the idletime policy. (Default: 1).
-
security.mac.priority.idletime_gid
-
The numeric gid of the idletime group. (Default: 48).
-
-
-
-
-

-

idprio(1), rtprio(1), - rtprio(2), mac(4)

-
-
-

-

MAC first appeared in FreeBSD 5.0 and - mac_priority first appeared in - FreeBSD 13.1.

-
-
- - - - - -
December 14, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_seeotheruids.4 3.html b/static/freebsd/man4/mac_seeotheruids.4 3.html deleted file mode 100644 index 746ec17e..00000000 --- a/static/freebsd/man4/mac_seeotheruids.4 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
MAC_SEEOTHERUIDS(4)Device Drivers ManualMAC_SEEOTHERUIDS(4)
-
-
-

-

mac_seeotheruids — - simple policy controlling whether users see other - users

-
-
-

-

To compile the policy into your kernel, place the following lines - in your kernel configuration file:

-
options MAC -
-options MAC_SEEOTHERUIDS
-

Alternately, to load the module at boot time, place the following - line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_seeotheruids_load="YES"
-
-
-
-

-

The mac_seeotheruids policy module, when - enabled, denies users to see processes or sockets owned by other users.

-

To enable mac_seeotheruids, set the sysctl - OID security.mac.seeotheruids.enabled to 1. To permit - superuser awareness of other credentials by virtue of privilege, set the - sysctl OID security.mac.seeotheruids.suser_privileged - to 1.

-

To allow users to see processes and sockets owned by the same - primary group, set the sysctl OID - security.mac.seeotheruids.primarygroup_enabled to - 1.

-

To allow processes with a specific group ID to be exempt from the - policy, set the sysctl OID - security.mac.seeotheruids.specificgid_enabled to 1, - and security.mac.seeotheruids.specificgid to the list - of group IDs to be exempted.

-
-

-

No labels are defined for - mac_seeotheruids.

-
-
-
-

-

mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_partition(4), mac_portacl(4), - mac_test(4), mac(9)

-
-
-

-

The mac_seeotheruids policy module first - appeared in FreeBSD 5.0 and was developed by the - TrustedBSD Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
Februrary 26, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_stub.4 3.html b/static/freebsd/man4/mac_stub.4 3.html deleted file mode 100644 index 0b9117a2..00000000 --- a/static/freebsd/man4/mac_stub.4 3.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
MAC_STUB(4)Device Drivers ManualMAC_STUB(4)
-
-
-

-

mac_stub — MAC - policy stub module

-
-
-

-

To compile the stub policy into your kernel, place the following - lines in your kernel configuration file:

-
options MAC -
-options MAC_STUB
-

Alternately, to load the stub module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_stub_load="YES"
-
-
-
-

-

The mac_stub policy module implements a - stub MAC policy that has no effect on access control in the system. Unlike - mac_none(4), each MAC entry point is defined as a - “no-op”, so the policy module will be entered for each event, - but no change in system behavior should result.

-
-

-

No labels are defined for mac_stub.

-
-
-
-

-

mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_partition(4), mac_portacl(4), - mac_seeotheruids(4), mac_test(4), - mac(9)

-
-
-

-

The mac_stub policy module first appeared - in FreeBSD 5.1 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
July 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mac_test.4 3.html b/static/freebsd/man4/mac_test.4 3.html deleted file mode 100644 index 0760a489..00000000 --- a/static/freebsd/man4/mac_test.4 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
MAC_TEST(4)Device Drivers ManualMAC_TEST(4)
-
-
-

-

mac_test — MAC - framework testing policy

-
-
-

-

To compile the testing policy into your kernel, place the - following lines in your kernel configuration file:

-
options MAC -
-options MAC_TEST
-

Alternately, to load the testing module at boot time, place the - following line in your kernel configuration file:

-
options MAC
-

and in loader.conf(5):

-
-
mac_test_load="YES"
-
-
-
-

-

The mac_test policy module implements a - testing facility for the MAC framework. Among other things, - mac_test will try to catch corrupt labels the system - is attempting to destroy and drop to the debugger. Additionally, a set of - statistics regarding the number of times various MAC framework entry points - have been called is stored in the security.mac.test - sysctl(8) tree.

-
-

-

No labels are defined for mac_test.

-
-
-
-

-

mac(4), mac_biba(4), - mac_bsdextended(4), mac_ddb(4), - mac_ifoff(4), mac_lomac(4), - mac_mls(4), mac_none(4), - mac_partition(4), mac_portacl(4), - mac_seeotheruids(4), mac(9)

-
-
-

-

The mac_test policy module first appeared - in FreeBSD 5.0 and was developed by the TrustedBSD - Project.

-
-
-

-

This software was contributed to the - FreeBSD Project by Network Associates Labs, the - Security Research Division of Network Associates Inc. under DARPA/SPAWAR - contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA - CHATS research program.

-
-
-

-

While the MAC Framework design is intended to support the - containment of the root user, not all attack channels are currently - protected by entry point checks. As such, MAC Framework policies should not - be relied on, in isolation, to protect against a malicious privileged - user.

-
-
- - - - - -
July 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/malo.4 3.html b/static/freebsd/man4/malo.4 3.html deleted file mode 100644 index 15c401d9..00000000 --- a/static/freebsd/man4/malo.4 3.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - -
MALO(4)Device Drivers ManualMALO(4)
-
-
-

-

malo — Marvell - Libertas IEEE 802.11b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device malo -
-device pci -
-device wlan -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_malo_load="YES"
-
-
-
-

-

The malo driver provides support for - Marvell Libertas 88W8335 based PCI and Cardbus network adapters. - malo supports station and - monitor mode operation. Only one virtual interface - may be configured at any time. For more information on configuring this - device, see ifconfig(8).

-

This driver requires firmware to be loaded before it will work. - The ports/net/malo-firmware-kmod port needs to be - installed before ifconfig(8) will work.

-
-
-

-

The following cards are among those supported by the - malo driver:

- - - - - - - - - - - - - - - - - - - - - - - - - -
Netgear WG311v388W8335PCIb/g
Tenda TWL542P88W8335PCIb/g
U-Khan UW-2054i88W8335PCIb/g
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
ifconfig wlan create wlandev malo0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - “my_net”:

-

-
ifconfig wlan create wlandev malo0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev malo0 ssid my_net \
-	wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-

cardbus(4), pci(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

The malo device driver first appeared in - FreeBSD 7.1.

-
-
- - - - - -
June 24, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/armv8crypto.4 3.html b/static/freebsd/man4/man4.aarch64/armv8crypto.4 3.html deleted file mode 100644 index 8a5f19dd..00000000 --- a/static/freebsd/man4/man4.aarch64/armv8crypto.4 3.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
ARMV8CRYPTO(4)Device Drivers Manual (aarch64)ARMV8CRYPTO(4)
-
-
-

-

armv8crypto — - driver for the AES accelerator on ARM CPUs

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device armv8crypto
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
armv8crypto_load="YES"
-
-
-
-

-

Starting with the ARMv8 architecture ARM Limited has added - optional cryptography instructions to accelerate AES, SHA-1, SHA-2, and - finite field arithmetic.

-

The processor capability is reported as AES in the Instruction Set - Attributes 0 line at boot. The armv8crypto driver - does not attach on systems that lack the required CPU capability.

-

The armv8crypto driver registers itself to - accelerate AES operations for crypto(4).

-
-
-

-

crypt(3), crypto(4), - intro(4), ipsec(4), - random(4), crypto(7), - crypto(9)

-
-
-

-

The armv8crypto driver first appeared in - FreeBSD 11.0.

-
-
-

-

The armv8crypto driver was written by - Andrew Turner - <andrew@FreeBSD.org>.

-
-
- - - - - -
July 29, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/enetc.4 3.html b/static/freebsd/man4/man4.aarch64/enetc.4 3.html deleted file mode 100644 index 4e564c46..00000000 --- a/static/freebsd/man4/man4.aarch64/enetc.4 3.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
ENETC(4)Device Drivers Manual (aarch64)ENETC(4)
-
-
-

-

enetc — Freescale - ENETC PCIe Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel the following lines must be - present in the kernel configuration file:

-

-
- options SOC_NXP_LS -
- device pci -
- device fdt -
- device iflib -
- device enetc

-
-
-

-

The enetc driver provides support for - ENETC Gigabit Ethernet NIC found in LS1028A SoC. iflib(9) - is used to communicate with the rest of kernel. Both physical ports, as well - as virtual interfaces connected to the internal switch are supported.

-

The following hardware offloads have been implemented in this - version of the driver:

-
-
- Receive IP checksum validation.
-- VLAN tag insertion and extraction.
-- VLAN tag based packet filtering.
-
-

For more information about configuring this device refer to - ifconfig(8).

-
-
-

-

vlan(4), ifconfig(8), - iflib(9)

-
-
-

-

The enetc driver first appeared in - FreeBSD 14.0.

-
-
- - - - - -
June 11, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/felix.4 3.html b/static/freebsd/man4/man4.aarch64/felix.4 3.html deleted file mode 100644 index bf51409c..00000000 --- a/static/freebsd/man4/man4.aarch64/felix.4 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
FELIX(4)Device Drivers Manual (aarch64)FELIX(4)
-
-
-

-

felix — driver for - Microchip Ocelot Felix switch

-
-
-

-

To compile this driver into the kernel the following lines must be - present in the kernel configuration file:

-

-
- options SOC_NXP_LS -
- device pci -
- device fdt -
- device mdio -
- device enetc -
- device etherswitch -
- device felix

-
-
-

-

The felix driver provides a management - interface to Microchip Ocelot Felix switch (VSC9959) found in NXP LS1028A - SoC. It is a PCI device, part of the larger ENETC root complex. The driver - is using etherswitch(4) framework.

-

This driver supports only dot1q vlan. dot1q support port base - addtag, striptag, dropuntagged, dropuntagged.

-
-
-

-

Configure dot1q vlan by etherswitchcfg command.

-

-
# etherswitchcfg config vlan_mode - dot1q
-

Configure port 5 is tagging port.

-

-
# etherswitchcfg port5 - addtag
-

Disable port 5 is tagging port.

-

-
# etherswitchcfg port5 - -addtag
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The felix device driver first appeared in - FreeBSD 14.0.

-
-
-

-

The felix driver was written by - Kornel Duleba (mindal@semihalf.com) and -
- Lukasz Hajec (lha@semihalf.com)

-

-
-
- - - - - -
June 21, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/rk_gpio.4 3.html b/static/freebsd/man4/man4.aarch64/rk_gpio.4 3.html deleted file mode 100644 index b6c4e443..00000000 --- a/static/freebsd/man4/man4.aarch64/rk_gpio.4 3.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
RK_GPIO(4)Device Drivers Manual (aarch64)RK_GPIO(4)
-
-
-

-

rk_gpio — driver - for the gpio controller on RockChip SoCs

-
-
-

-

options SOC_ROCKCHIP_RK3328

-
-
-

-

The rk_gpio device driver provides support - for the gpio controller device present on RockChip SoC.

-
-
-

-

The current version of the rk_gpio driver - supports the gpio banks with one of the following compatible strings :

-

-
    -
  • rockchip,gpio-bank
    • -
-
-
-

-

gpiobus(4), gpioctl(8)

-
-
-

-

The rk_gpio device driver first appeared - in FreeBSD 12.0.

-
-
-

-

The rk_gpio device driver and manpage was - written by Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
April 26, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/rk_grf.4 3.html b/static/freebsd/man4/man4.aarch64/rk_grf.4 3.html deleted file mode 100644 index 5e03afec..00000000 --- a/static/freebsd/man4/man4.aarch64/rk_grf.4 3.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
RK_GRF(4)Device Drivers Manual (aarch64)RK_GRF(4)
-
-
-

-

rk_grf — driver - for the General Register Files controller on RockChip SoCs

-
-
-

-

options SOC_ROCKCHIP_rk3328

-
-
-

-

The rk_grf device driver provides support - for the RockChip General Register Files system controller.

-
-
-

-

The current version of the rk_grf driver - supports the GRF controller with one of the following compatible strings - :

-

-
    -
  • rockchip,rk3328-grf
    • -
-
-
-

-

The rk_grf device driver first appeared in - FreeBSD 12.0.

-
-
-

-

The rk_grf device driver and manpage was - written by Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
April 26, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/rk_grf_gpio.4 3.html b/static/freebsd/man4/man4.aarch64/rk_grf_gpio.4 3.html deleted file mode 100644 index 3e81aa1e..00000000 --- a/static/freebsd/man4/man4.aarch64/rk_grf_gpio.4 3.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -
RK_GRF_GPIO(4)Device Drivers Manual (aarch64)RK_GRF_GPIO(4)
-
-
-

-

rk_grf_gpio — - RockChip GPIO_MUTE pin driver

-
-
-

-

options SOC_ROCKCHIP_rk3328

-
-
-

-

The rk_grf_gpio driver provides a - single-pin, output-only gpio(3) unit whose single pin is - named GPIO_MUTE. This controls the output of the GPIO_MUTE pin on the - SoC.

-

This gpio is usually used to control another device on the board, - so is not usually available for user software.

-
-
-

-

The rk_grf_gpio driver supports the - following GRF GPIO controller:

-

-
    -
  • rockchip,rk3328-grf-gpio
    • -
-
-
-

-

The rk_grf_gpio driver first appeared in - FreeBSD 15.0.

-
-
-

-

The rk_grf_gpio driver and manual were - written by Stephen Hurd - <shurd@freebsd.org>.

-
-
- - - - - -
March 18, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/rk_i2c.4 3.html b/static/freebsd/man4/man4.aarch64/rk_i2c.4 3.html deleted file mode 100644 index 13228766..00000000 --- a/static/freebsd/man4/man4.aarch64/rk_i2c.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
RK_I2C(4)Device Drivers Manual (aarch64)RK_I2C(4)
-
-
-

-

rk_i2c — driver - for the i2c controller on RockChip SoCs

-
-
-

-

options SOC_ROCKCHIP_RK3328

-
-
-

-

The rk_i2c device driver provides support - for the i2c controller device present on RockChip SoC.

-
-
-

-

The current version of the rk_i2c driver - supports the i2c controller with one of the following compatible strings - :

-

-
    -
  • rockchip,rk3328-i2c
    • -
-
-
-

-

iic(4), iicbus(4)

-
-
-

-

The rk_i2c device driver first appeared in - FreeBSD 12.0.

-
-
-

-

The rk_i2c device driver and manpage was - written by Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
June 14, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.aarch64/rk_pinctrl.4 3.html b/static/freebsd/man4/man4.aarch64/rk_pinctrl.4 3.html deleted file mode 100644 index 6530aed1..00000000 --- a/static/freebsd/man4/man4.aarch64/rk_pinctrl.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
RK_PINCTRL(4)Device Drivers Manual (aarch64)RK_PINCTRL(4)
-
-
-

-

rk_pinctrl — - driver for the pin multiplexing on RockChip SoCs

-
-
-

-

options SOC_ROCKCHIP_RK3328

-
-
-

-

The rk_pinctrl device driver provides - support for the pin multiplexing device present on RockChip SoC.

-
-
-

-

The current version of the rk_pinctrl - driver supports the pin controller with one of the following compatible - strings :

-

-
    -
  • rockchip,rk3328-pinctrl
    • -
-
-
-

-

fdt_pinctrl(4)

-
-
-

-

The rk_pinctrl device driver first - appeared in FreeBSD 12.0.

-
-
-

-

The rk_pinctrl device driver and manpage - was written by Emmanuel Vadot - <manu@freebsd.org>.

-
-
- - - - - -
April 26, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/am335x_dmtpps.4 3.html b/static/freebsd/man4/man4.arm/am335x_dmtpps.4 3.html deleted file mode 100644 index 3873fce7..00000000 --- a/static/freebsd/man4/man4.arm/am335x_dmtpps.4 3.html +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - -
AM335X_DMTPPS(4)Device Drivers Manual (arm)AM335X_DMTPPS(4)
-
-
-

-

am335x_dmtpps — - RFC 2783 Pulse Per Second API driver for AM335x - systems

-
-
-

-

device am335x_dmtpps

-

Optional in /boot/loader.conf: -
- hw.am335x_dmtpps.input="pin name"

-
-
-

-

The am335x_dmtpps device driver provides a - system time counter that includes precise capture of Pulse Per Second (PPS) - signals emitted by GPS receivers and other timing devices. The - am335x_dmtpps driver may be compiled into the kernel - or loaded as a module.

-

The AM335x timer hardware captures the value of the system time - counter on the leading edge of the PPS pulse. Because the capture is done by - the hardware there is no interrupt latency in the measurement. The time - counter runs at 24Mhz, providing a measurement resolution of 42 - nanoseconds.

-

To use the PPS timing information provided by this driver with - ntpd(8), symlink the /dev/dmtpps - device to /dev/pps0 and configure server - 127.127.22.0 in ntp.conf(5) to - configure a type 22 (ATOM) refclock.

-
-
-

-

The AM335x hardware provides four timer devices with a capture - input pin, DMTimer4 through DMTimer7. Because it also provides the active - system time counter, only one instance of the - am335x_dmtpps driver can be active at a time. The - driver uses system pin configuration to determine which hardware timer - device to use. Configure the timer input pin in the system's FDT data, or by - supplying the pin name using a tunable variable in - loader.conf(5).

-

To use a standard kernel and FDT data, use - loader.conf(5) to load the - am335x_dmtpps module and set the - hw.am335x_dmtpps.input tunable variable to the name of - the input pin, one of the following:

-

-
-
-
-
-
P8-7
-
DMTimer4; Beaglebone P8 header pin 7.
-
P8-8
-
DMTimer7; Beaglebone P8 header pin 8.
-
P8-9
-
DMTimer5; Beaglebone P8 header pin 9.
-
P8-10
-
DMTimer6; Beaglebone P8 header pin 10.
-
GPMC_ADVn_ALE
-
DMTimer4.
-
GPMC_BEn0_CLE
-
DMTimer5.
-
GPMC_WEn
-
DMTimer6.
-
GPMC_OEn_REn
-
DMTimer7.
-
-
-

To configure the am335x_dmtpps driver - using FDT data, create a new pinctrl node by referencing the standard - am33xx_pinmux driver node (which is defined in - am33xx.dtsi) in your dts file. For example:

-
-
   &am33xx_pinmux {
-      timer4_pins: timer4_pins {
-         pinctrl-single,pins = <0x90 (PIN_INPUT | MUX_MODE2)>;
-      };
-   };
-
-

Add pinctrl properties referencing - timer4_pins to the standard - timer4 device node (also defined in am33xx.dtsi) by - referencing it in your dts file as follows:

-
-
   &timer4 {
-      pinctrl-names = "default";
-      pinctrl-0 = <&timer4_pins>;
-   };
-
-
-
-

-
-
/dev/dmtpps
-
The device providing ioctl(2) access to the RFC 2783 - API.
-
-
-
-

-

timecounters(4), - loader.conf(5), ntp.conf(5), - ntpd(8)

-
-
-

-

The am335x_dmtpps device driver first - appeared in FreeBSD 11.0.

-
-
-

-

The am335x_dmtpps device driver and this - manual page were written by Ian Lepore - <ian@FreeBSD.org>.

-
-
- - - - - -
August 12, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/ar40xx.4 3.html b/static/freebsd/man4/man4.arm/ar40xx.4 3.html deleted file mode 100644 index e886672b..00000000 --- a/static/freebsd/man4/man4.arm/ar40xx.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
AR40XX(4)Device Drivers Manual (arm)AR40XX(4)
-
-
-

-

ar40xx_switch — - Qualcomm IPQ4018/IPQ4019 Gigabit Ethernet switch - driver

-
-
-

-

device mdio -
- etherswitch -
- ar40xx_switch

-
-
-

-

The ar40xx_switch driver supports the - Gigabit Ethernet switch inside the Qualcomm IPQ4018/IPQ4019 SoC.

-
-
-

-

The ar40xx_switch driver supports the - following Gigabit Ethernet switch controllers:

-

-
    -
  • Qualcomm IPQ 4019 Five-port Gigabit Ethernet Switch
    • -
  • Qualcomm IPQ 4018 Five-port Gigabit Ethernet Switch
    • -
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

This driver currently only supports L2 port/VLAN mapping - modes.

-
-
- - - - - -
May 10, 2025
diff --git a/static/freebsd/man4/man4.arm/bcm283x_pwm.4 3.html b/static/freebsd/man4/man4.arm/bcm283x_pwm.4 3.html deleted file mode 100644 index 9e103fdd..00000000 --- a/static/freebsd/man4/man4.arm/bcm283x_pwm.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
BCM283X_PWM(4)Device Drivers Manual (arm)BCM283X_PWM(4)
-
-
-

-

bcm283x_pwm — - bcm283x_pwm - driver for Raspberry Pi 2/3 PWM

-
-
-

-

kldload bcm283x_clkman -
- kldload bcm283x_pwm

-
-
-

-

The bcm283x_pwm driver provides access to - the PWM engine on GPIO12 of Raspberry Pi 2 and 3 hardware.

-

The PWM hardware is controlled via the sysctl(8) - interface:

-
-
dev.pwm.0.mode: 1
-dev.pwm.0.mode2: 1
-dev.pwm.0.freq: 125000000
-dev.pwm.0.ratio: 2500
-dev.pwm.0.ratio2: 2500
-dev.pwm.0.period: 10000
-dev.pwm.0.period2: 10000
-dev.pwm.0.pwm_freq: 12500
-dev.pwm.0.pwm_freq2: 12500
-
-
-
dev.pwm.0.mode, - dev.pwm.0.mode2
-
PWM Mode for channels 1 and 2. Three modes exist, 0=off, 1=PWM, 2=N/M. The - N/M mode is a first order delta-sigma mode, which makes a quite handy DAC - output with a trivial RC lowpass filter.
-
dev.pwm.0.freq
-
The input frequency to the PWM hardware in Hz. Applies to both channels 1 - and 2. Minimum frequency is 123 kHz, maximum frequency is 125 MHz.
-
dev.pwm.0.period, - dev.pwm.0.period2
-
The period length in cycles. In PWM mode, the output frequencies will be ( - dev.pwm.0.freq / - dev.pwm.period ) and ( - dev.pwm.0.freq2 / - dev.pwm.0.period2 ). In N/M mode this is the - 'M'.
-
dev.pwm.0.ratio, - dev.pwm.0.ratio2
-
The "on" period in cycles for PWM channels 1 and 2. In PWM mode, - to get a 25% dutycycle, set this to 25% of - dev.pwm.0.period or - dev.pwm.0.period2, as appropriate. In N/M mode this - is the 'N'.
-
dev.pwm.0.pwm_freq, - dev.pwm.0.pwm_freq2
-
The calculated PWM output frequencies in PWM mode, for channels 1 and - 2.
-
-
-
-

-

Currently the bcm283x_pwm driver ignores - the 'status="disabled"' flag in the DTB, assuming that if you load - the driver, you want it to work.

-
-
-

-

sysctl(8)

-
-
-

-

The bcm283x_pwm driver first appeared in - FreeBSD 12.0.

-
-
-

-

The bcm283x_pwm driver and this manual - page were written by Poul-Henning Kamp - <phk@FreeBSD.org>.

-
-
- - - - - -
September 10, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/devcfg.4 3.html b/static/freebsd/man4/man4.arm/devcfg.4 3.html deleted file mode 100644 index c3a218c6..00000000 --- a/static/freebsd/man4/man4.arm/devcfg.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
DEVCFG(4)Device Drivers Manual (arm)DEVCFG(4)
-
-
-

-

devcfg — Zynq PL - device config interface

-
-
-

-

device devcfg

-
-
-

-

The special file /dev/devcfg can be used - to configure the PL (FPGA) section of the Xilinx Zynq-7000.

-

On the first write to the character device at file offset 0, the - devcfg driver asserts the top-level PL reset - signals, disables the PS-PL level shifters, and clears the PL configuration. - Write data is sent to the PCAP (processor configuration access port). When - the PL asserts the DONE signal, the devcfg driver will enable the level - shifters and release the top-level PL reset signals.

-

The PL (FPGA) can be configured by writing the bitstream to the - character device like this:

-
-
cat design.bit.bin > /dev/devcfg
-
-

The file should not be confused with the .bit file output by the - FPGA design tools. It is the binary form of the configuration bitstream. The - Xilinx promgen tool can do the conversion:

-
-
promgen -b -w -p bin -data_width 32 -u 0 design.bit -o design.bit.bin
-
-
-
-

-

The devcfg driver provides the following - sysctl(8) variables:

-
-
hw.fpga.pl_done
-
-

This variable always reflects the status of the PL's DONE - signal. A 1 means the PL section has been properly programmed.

-
-
hw.fpga.en_level_shifters
-
-

This variable controls if the PS-PL level shifters are enabled - after the PL section has been reconfigured. This variable is 1 by - default but setting it to 0 allows the PL section to be programmed with - configurations that do not interface to the PS section of the part. - Changing this value has no effect on the level shifters until the next - device reconfiguration.

-
-
-
-
-

-
-
/dev/devcfg
-
Character device for the devcfg driver.
-
-
-
-

-

Zynq-7000 SoC Technical Reference Manual (Xilinx doc UG585)

-
-
-

-

Thomas Skibo

-
-
- - - - - -
February 28, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/dwcotg.4 3.html b/static/freebsd/man4/man4.arm/dwcotg.4 3.html deleted file mode 100644 index e8ab0a51..00000000 --- a/static/freebsd/man4/man4.arm/dwcotg.4 3.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - -
DWCOTG(4)Device Drivers Manual (arm)DWCOTG(4)
-
-
-

-

dwcotg — Synopsys - DesignWare USB controller driver

-
-
-

-

device acpi -
- device fdt -
- device dwcotg

-
-
-

-

The dwcotg driver supports the Synopsys - DesignWare USB controller found in many embedded devices.

-
-
-

-

usb_template(4)

-
-
-

-

The dwcotg driver appeared in - FreeBSD 10.0.

-
-
-

-

Hans Petter Selasky

-
-
- - - - - -
November 5, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/imx6_ahci.4 3.html b/static/freebsd/man4/man4.arm/imx6_ahci.4 3.html deleted file mode 100644 index 4e688371..00000000 --- a/static/freebsd/man4/man4.arm/imx6_ahci.4 3.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - -
IMX6_AHCI(4)Device Drivers Manual (arm)IMX6_AHCI(4)
-
-
-

-

imx6_ahci — device - driver for the NXP i.MX6 on-chip SATA controller

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ahci
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
imx6_ahci_load="YES"
-
-
-
-

-

The imx6_ahci driver provides support for - the on-chip SATA controller found on some models of the NXP i.MX6 chip. The - driver is a thin glue layer to interpret the platform's FDT data and - marshall resources for the standard ahci(4) driver.

-
-
-

-

ahci(4), fdt(4)

-
-
-

-

The imx6_ahci driver first appeared in - FreeBSD 12.0.

-
-
- - - - - -
July 7, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/imx6_snvs.4 3.html b/static/freebsd/man4/man4.arm/imx6_snvs.4 3.html deleted file mode 100644 index c3763862..00000000 --- a/static/freebsd/man4/man4.arm/imx6_snvs.4 3.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
IMX6_SNVS(4)Device Drivers Manual (arm)IMX6_SNVS(4)
-
-
-

-

imx6_snvs — device - driver for the NXP i.MX6 on-chip Realtime Clock

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device imx6_snvs
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
imx6_snvs_load="YES"
-
-
-
-

-

The imx6_snvs driver provides support for - the i.MX6 on-chip realtime clock. It provides the time of day with a - resolution of approximately 30 microseconds.

-

‘SNVS’ stands for Secure Non-Volatile Storage, and - refers to the subsystem within the chip that (optionally) remains powered by - a battery when the rest of the system is powered down. The on-chip realtime - clock is part of that subsystem. Other features of the SNVS subsystem are - related to security, tamper monitoring, and power control; the - imx6_snvs driver does not currently support those - features.

-

Many i.MX6 systems do not use a battery to provide power to the - SNVS due to its relatively high power draw. In such systems, this driver is - able to provide a very accurate time following a reboot, but cannot provide - time at all if the power is cycled. If the system provides an i2c or other - type of alternate realtime clock with lower resolution, there is value in - configuring both clock drivers. Doing so allows SNVS to provide accurate - time after a reboot, while the external clock provides approximate time - after power cycling.

-
-
-

-

The imx6_snvs driver first appeared in - FreeBSD 12.0.

-
-
- - - - - -
July 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/imx_spi.4 3.html b/static/freebsd/man4/man4.arm/imx_spi.4 3.html deleted file mode 100644 index 308f2fdc..00000000 --- a/static/freebsd/man4/man4.arm/imx_spi.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
IMX_SPI(4)Device Drivers Manual (arm)IMX_SPI(4)
-
-
-

-

imx_spi — device - driver for the NXP i.MX family Serial Peripheral Interface (SPI)

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device imx_spi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
imx_spi_load="YES"
-
-
-
-

-

The imx_spi driver provides support for - the ‘ECSPI’ (Enhanced Configurable SPI) hardware present on - the NXP i.MX family of processors. While the ECSPI hardware supports both - master and slave mode, this driver currently operates only in master - mode.

-

Due to hardware quirks, the imx_spi driver - requires that all chip select pins be configured as GPIO pins. Use the FDT - property ‘cs-gpios’ to specify which pins to use as chip - selects. You may use any GPIO pins, including the ones that the hardware - would normally use as SPI select pins; just configure them as GPIO in the - fdt_pinctrl(4) data.

-
-
-

-

The following variables are available via - sysctl(8), and as loader(8) - tunables:

-
-
dev.imx_spi.%d.debug
-
Output debugging info when non-zero. A value of 1 displays information - about bus transfers, 2 adds information about bus clock frequency and chip - select activity, and 3 adds information about interrupt handling.
-
-
-
-

-

fdt(4), fdt_pinctrl(4), - sysctl(8)

-
-
-

-

The imx_spi driver first appeared in - FreeBSD 12.0.

-
-
- - - - - -
July 9, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/imx_wdog.4 3.html b/static/freebsd/man4/man4.arm/imx_wdog.4 3.html deleted file mode 100644 index 7756d9c8..00000000 --- a/static/freebsd/man4/man4.arm/imx_wdog.4 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
IMX_WDOG(4)Device Drivers Manual (arm)IMX_WDOG(4)
-
-
-

-

imx_wdog — device - driver for the NXP i.MX5 and i.MX6 watchdog timer

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device imxwdt
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
imx_wdog_load="YES"
-
-
-
-

-

The imx_wdog driver provides - watchdog(4) support for the watchdog timer present on NXP - i.MX5 and i.MX6 processors. The i.MX watchdog hardware supports programmable - timeouts ranging from 0.5 to 128 seconds, in half-second increments. Once - activated, the watchdog hardware cannot be deactivated, but the timeout - period can be changed to any valid non-zero value.

-

At power-on, a special 16-second ‘power-down timer’ - mode is automatically enabled by the hardware. It will assert the external - WDOG_B signal, which may be connected to external hardware that causes the - system to reset or power-down. The power-down timer is often reset by the - boot loader (typically U-Boot). If the power-down timer is still active at - the time when the normal watchdog is first enabled, the - imx_wdog driver automatically disables it.

-

The imx_wdog driver supports the FDT - fsl,external-reset property by enabling the assertion - of the WDOG_B external timeout signal when the property is present. When - running this way, the need to reset the system due to watchdog timeout is - signaled by driving the WDOG_B line low; some external entity is expected to - assert the chip's POR pin in response. The imx_wdog - driver attempts to backstop this external reset by scheduling an interrupt - to occur as well. The interrupt handler waits 1 second for the external - reset to occur, then it triggers a normal software reset. Note that the - WDOG_B signal can be configured to use a variety of pins on the chip. For - the fsl,external-reset property to be effective, the - signal must be connected to an appropriate pin by the system's FDT pinctrl - data.

-

The imx_wdog driver supports the FDT - timeout-secs property by enabling the watchdog as soon - as the driver attaches, using the given timeout value. This extends watchdog - protection to much of the system startup process, but it still requires that - watchdogd(4) be configured to service the watchdog.

-
-
-

-

fdt(4), watchdog(4), - watchdog(8), watchdogd(8), - watchdog(9)

-
-
-

-

The imx_wdog driver first appeared in - FreeBSD 10.0.

-
-
- - - - - -
July 7, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/mge.4 3.html b/static/freebsd/man4/man4.arm/mge.4 3.html deleted file mode 100644 index e9a5086a..00000000 --- a/static/freebsd/man4/man4.arm/mge.4 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
MGE(4)Device Drivers Manual (arm)MGE(4)
-
-
-

-

mge — Marvell - Gigabit Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device mge -
-device miibus
-
-
-

-

The mge driver provides support for - gigabit Ethernet controller integrated in Marvell system-on-chip - devices.

-

The mge driver supports the following - media types:

-
-
autoselect
-
Enable autoselection of the media type and options
-
10baseT/UTP
-
Set 10Mbps operation
-
100baseTX
-
Set 100Mbps operation
-
1000baseT
-
Set 1000baseT operation
-
-

The mge driver supports the following - media options:

-
-
full-duplex
-
Set full duplex operation
-
-

The mge driver supports polled operation - when the system is configured with DEVICE_POLLING kernel option, see - polling(4) for more details.

-

The mge driver supports reception and - transmission of extended frames for vlan(4). This - capability of mge can be controlled by means of the - vlanmtu parameter to - ifconfig(8).

-

The mge driver supports interrupts - coalescing (IC) so that raising a transmit/receive frame interrupt is - delayed, if possible, until a threshold-defined period of time has elapsed. - The following sysctls regulate this behaviour (separately for each - path):

-
-
dev.mge.X.int_coal.rx_time
-
 
-
dev.mge.X.int_coal.tx_time
-
-

Value of 0 disables IC on the given path, value greater than - zero corresponds to a real time period and is expressed in units - equivalent to 64 ticks of the MGE clock. Maximum allowed value depends - on MGE hardware revision. User provided values larger than supported - will be trimmed to the maximum supported. More details are available in - the reference manual of the device.

-
-
-
-
-

-

Gigabit Ethernet controllers built into the following Marvell - systems-on-chip are known to work with the mge - driver:

-

-
    -
  • Orion 88F5182
    • -
  • Orion 88F5281
    • -
  • Kirkwood 88F6281 (MGE V2)
    • -
  • Discovery MV78100 (MGE V2)
    • -
-

There are also Marvell system controllers for PowerPC processors, - which include a variation of this gigabit Ethernet module integrated on - chip, and they should also work with the mge driver, - but this wasn't tested:

-

-
    -
  • MV64430
    • -
  • MV64460, MV64461, MV64462
    • -
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-
-
-

-

The mge device driver first appeared in - FreeBSD 8.0.

-
-
-

-

The base version of mge device driver was - written by Grzegorz Bernacki. It has been extended - with advanced features (polling, interrupt coalescing, multicast, h/w - checksum calculation etc.) by Piotr Ziecik. This - manual page was written by Rafal Jaworowski.

-
-
- - - - - -
November 27, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.arm/ti_adc.4 3.html b/static/freebsd/man4/man4.arm/ti_adc.4 3.html deleted file mode 100644 index 70f4bada..00000000 --- a/static/freebsd/man4/man4.arm/ti_adc.4 3.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - -
TI_ADC(4)Device Drivers Manual (arm)TI_ADC(4)
-
-
-

-

ti_adc — TI AM3XXX - analog to digital converter driver

-
-
-

-

device ti_adc

-
-
-

-

The ti_adc driver provides access to the - AIN (analog inputs) on am3xxx SoCs.

-

It provides raw readings of the converted values for each analog - inputs.

-

The access to ti_adc data is made via the - sysctl(8) interface:

-
-
dev.ti_adc.0.%desc: TI ADC controller
-dev.ti_adc.0.%driver: ti_adc
-dev.ti_adc.0.%pnpinfo: name=adc@44E0D000 compat=ti,adc
-dev.ti_adc.0.%parent: simplebus0
-dev.ti_adc.0.clockdiv: 2400
-dev.ti_adc.0.ain.0.enable: 0
-dev.ti_adc.0.ain.0.open_delay: 0
-dev.ti_adc.0.ain.0.samples_avg: 0
-dev.ti_adc.0.ain.0.input: 0
-dev.ti_adc.0.ain.1.enable: 0
-dev.ti_adc.0.ain.1.open_delay: 0
-dev.ti_adc.0.ain.1.samples_avg: 0
-dev.ti_adc.0.ain.1.input: 0
-dev.ti_adc.0.ain.2.enable: 0
-dev.ti_adc.0.ain.2.open_delay: 0
-dev.ti_adc.0.ain.2.samples_avg: 0
-dev.ti_adc.0.ain.2.input: 0
-dev.ti_adc.0.ain.3.enable: 0
-dev.ti_adc.0.ain.3.open_delay: 0
-dev.ti_adc.0.ain.3.samples_avg: 0
-dev.ti_adc.0.ain.3.input: 0
-dev.ti_adc.0.ain.4.enable: 0
-dev.ti_adc.0.ain.4.open_delay: 0
-dev.ti_adc.0.ain.4.samples_avg: 0
-dev.ti_adc.0.ain.4.input: 0
-dev.ti_adc.0.ain.5.enable: 0
-dev.ti_adc.0.ain.5.open_delay: 0
-dev.ti_adc.0.ain.5.samples_avg: 0
-dev.ti_adc.0.ain.5.input: 0
-dev.ti_adc.0.ain.6.enable: 1
-dev.ti_adc.0.ain.6.open_delay: 0
-dev.ti_adc.0.ain.6.samples_avg: 4
-dev.ti_adc.0.ain.6.input: 2308
-dev.ti_adc.0.ain.7.enable: 1
-dev.ti_adc.0.ain.7.open_delay: 0
-dev.ti_adc.0.ain.7.samples_avg: 0
-dev.ti_adc.0.ain.7.input: 3812
-
-

On Beaglebone-black the analog input 7 is connected to the 3V3B - rail through a voltage divisor (2:1). The 3V3B voltage rail comes from the - TL5209 LDO regulator which is limited to 500mA maximum.

-

Global settings:

-
-
dev.ti_adc.0.clockdiv
-
Sets the ADC clock prescaler. The minimum value is 10 and the maximum is - 65535. The ADC clock is based on CLK_M_OSC (24Mhz) / clockdiv. This gives - a maximum of ~2.4Mhz for the ADC clock and ~10Khz for the default setting - (clockdiv = 2400).
-
-

Settings per input:

-
-
dev.ti_adc.0.ain.%d.enable
-
Enable the conversion for the input. Each input should be individually - enabled before it can be used. When all the inputs are disabled, the ADC - is turned off.
-
dev.ti_adc.0.ain.%d.open_delay
-
Sets the number of ADC clock cycles to wait after applying the input - configuration and before start the ADC conversion.
-
dev.ti_adc.0.ain.%d.samples_avg
-
Sets the number of samples average used on each input, it can be set to 0 - (no samples average), 2, 4, 8, or 16.
-
dev.ti_adc.0.ain.%d.input
-
Is the converted raw value of the voltage applied on the analog input. It - is made of a 12 bit value (0 ~ 4095).
-
-
-
-

-

sysctl(8)

-
-
-

-

The ti_adc driver first appeared in - FreeBSD 10.1.

-
-
-

-

The driver and this manual page was written by - Luiz Otavio O Souza - <loos@FreeBSD.org>.

-
-
- - - - - -
June 1, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/CPU_ELAN.4 3.html b/static/freebsd/man4/man4.i386/CPU_ELAN.4 3.html deleted file mode 100644 index bc72e512..00000000 --- a/static/freebsd/man4/man4.i386/CPU_ELAN.4 3.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - -
CPU_ELAN(4)Device Drivers Manual (i386)CPU_ELAN(4)
-
-
-

-

CPU_ELAN — AMD - Elan 520 CPU support

-
-
-

-

options CPU_ELAN -
- options CPU_ELAN_PPS -
- options CPU_ELAN_XTAL

-
    -
  • machdep.elan_gpio_config
    • -
  • machdep.elan_freq
    • -
-
-options CPU_SOEKRIS -
-
-

-

The options CPU_ELAN enables support for - the AMD Elan 520 CPU.

-

A device /dev/elan-mmcr exports the MMCR - register bank to userland using mmap(2).

-

The i8254 timer will be adjusted to the slightly unorthodox - frequency 1189161 Hz (32768 * 45 * 25 / 31) employed by the Elan.

-

A timecounter named “ELAN” - is implemented using the general purpose timer 2, but it will not be usable - unless HZ is configured at 150 or higher. This timecounter is much better - than the “i8254” timecounter and - should be used at all times.

-

The machdep.elan_gpio_config - sysctl(8) variable enables configuration of the GPIO pins - of the CPU. The string must be exactly 32 characters long. A - ‘-’ means the GPIO is unavailable. A - ‘l’ (lower-case ell) configures a - led(4) device (active low). A - ‘L’ configures a - led(4) device (active high). A - ‘.’ means no configuration for this - GPIO. These led(4) devices will be named - /dev/led/gpio%d. For meaning of - ‘P’, - ‘e’ and - ‘E’, see under - options CPU_ELAN_PPS.

-

The options CPU_ELAN_XTAL and the - machdep.elan_freq sysctl(8) variable - can be used to set the CPU clock crystal frequency in Hz. The default is - 33333333 Hz.

-

The options CPU_ELAN_PPS enables precision - timestamping using the RFC2783 PPS-API via the - /dev/elan-mmcr device. The resolution will be - approximately 125 nsec and the precision ± 125 nsec. (For 125 nsec - read “4 / CPU clock crystal frequency”.)

-

The input signal must be connected to the TMR1IN pin and a GPIO - pin. The GPIO pin must be configured with a - ‘P’ in - machdep.elan_gpio_config.

-

In addition, one GPIO pin can be configured with either - ‘e’ (active low) or - ‘E’ (active high) to become a - “echo” output of the input signal. Please notice that this - signal is not suitable for calibration.

-

If the options CPU_SOEKRIS is given, the - support will additionally be tailored to the Soekris Engineering 45xx series - of embedded computers. The “error” led will be configured (as - /dev/led/error) and the GPIO pins which are not - available will be disabled.

-
-
-

-

led(4), timecounters(4), - sysctl(8)

-
-
-

-

The CPU_ELAN code first appeared in - FreeBSD 4.7.

-
-
-

-

Poul-Henning Kamp - <phk@FreeBSD.org>

-
-
- - - - - -
November 23, 2003FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/apm.4 3.html b/static/freebsd/man4/man4.i386/apm.4 3.html deleted file mode 100644 index c92c4fbb..00000000 --- a/static/freebsd/man4/man4.i386/apm.4 3.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - -
APM(4)Device Drivers Manual (i386)APM(4)
-
-
-

-

apm — APM BIOS - interface

-
-
-

-

device apm

-
-
-

-

This driver is scheduled for removal prior to the release of - FreeBSD 13.0.

-
-
-

-

apm is an interface to the Intel / - Microsoft APM (Advanced Power Management) BIOS on laptop PCs.

-

apm provides the following power - management functions.

-
    -
  1. When the system wakes up from suspended mode, apm - adjusts the system clock to RTC.
    2. -
  2. When the system wakes up from suspended mode, apm - passes a message to syslogd(8) comprising of system - wakeup time and elapsed time during suspended mode.
    3. -
  3. apm slows CPU clock when there are no system - activities (runnable processes, interrupts, etc.). This function is - available only on systems whose APM supports CPU idling.
    4. -
  4. apm exports an application interface as a - character device. Applications can control APM, or retrieve APM status - information via this interface. apm exports the - following interfaces. These symbols are defined in - <machine/apm_bios.h>. -
    -
    -
    -
    Suspend system.
    -
    -
    Get power management information.
    -
    -
     
    -
    -
    Enable / Disable power management.
    -
    -
     
    -
    -
    Control execution of HLT in the kernel context switch routine.
    -
    -
    Get per battery information. -

    Some APM implementations execute the HLT (Halt CPU until - an interrupt occurs) instruction in the “Idle - CPU” call, while others do not. Thus enabling this may - result in redundant HLT executions because - “Idle CPU” is called from the kernel - context switch routine that inherently executes HLT. This may reduce - peak system performance.

    -

    Also the system hangs up if HLT instruction is disabled in - the kernel context switch routine, and if the APM implementation of - the machine does not execute HLT in “Idle - CPU”. On some implementations that do not support CPU - clock slowdown, APM might not execute HLT. - apm disables - APMIO_NOTHALTCPU operation on such machines.

    -

    The current version of apm does - not call “Idle CPU” from the kernel - context switch routine if clock slowdown is not supported, and it - executes HLT instruction by default. Therefore, there is no need to - use these two operations in most cases.

    -
    -
    -
    -

    These interfaces are used by apm(8).

    -
    5. -
  5. apm polls APM events and handles the following - events. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    standby request
    suspend request
    user suspend request
    critical suspend request
    normal resume
    critical resume
    standby resume
    battery low
    update time
    -
    6. -
-
-
-

-

apm(8), zzz(8)

-
-
-

-

Tatsumi Hosokawa - <hosokawa@jp.FreeBSD.org>

-
-
-

-

WARNING! Many, if not most, of the implementations of APM-bios in - laptops today are buggy. You may be putting your LCD-display and batteries - at a risk by using this interface. (The reason this is not a problem for - MS-Windows is that they use the real-mode interface.) If you see any weird - behavior from your system with this code in use, unplug the power and - batteries ASAP, if not immediately, and disable this code.

-

We are very interested in getting this code working, so please - send your observations of any anomalous behavior to us.

-

When apm is active, calling the BIOS setup - routine by using hot-keys, may cause serious trouble when resuming the - system. BIOS setup programs should be called during bootstrap, or from - DOS.

-

Some APM implementations cannot handle events such as pushing the - power button or closing the cover. On such implementations, the system - must be suspended only by using - apm(8) or zzz(8).

-

Disk spin-down, LCD backlight control, and power on demand have - not been supported on the current version.

-
-
- - - - - -
November 1, 1994FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/glxiic.4 3.html b/static/freebsd/man4/man4.i386/glxiic.4 3.html deleted file mode 100644 index 015909cc..00000000 --- a/static/freebsd/man4/man4.i386/glxiic.4 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
GLXIIC(4)Device Drivers Manual (i386)GLXIIC(4)
-
-
-

-

glxiic — Geode LX - CS5536 I2C controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device isa -
-device glxiic -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
glxiic_load="YES"
-
-
-
-

-

The glxiic driver supports the System - Management Bus controller of the Geode LX series CS5536 Companion Device. - The Geode LX is a member of the AMD Geode family of integrated x86 system - chips.

-

Although AMD refers to this device as a System Management Bus - (SMBus) controller, it is really an I2C controller (it lacks SMBus ALERT# - and Alert Response support).

-

The glxiic driver supports both I2C master - and slave mode.

-
-
-

-

The glxiic driver supports the following - variable as both sysctl(8) and loader(8) - tunable:

-
-
dev.glxiic.0.timeout
-
This variable controls the I2C bus timeout in milliseconds. The default - timeout is 35 milliseconds. A value of zero disables the timeout.
-
-
-
-

-

The glxiic driver uses the interrupt line - number configured by the board firmware by default. If no interrupt line - number has been configured by the board firmware (or to override the - interrupt line number configured by board firmware), place the following - line in device.hints(5):

-
hint.glxiic.0.irq="10"
-

The interrupt line number must be between 1 and 15.

-
-
-

-

iicbus(4), device.hints(5), - loader.conf(5), loader(8), - sysctl(8)

-
-
-

-

The glxiic device driver and manual page - first appeared in FreeBSD 9.0.

-
-
-

-

The glxiic device driver and manual page - were written by Henrik Brix Andersen - <brix@FreeBSD.org>.

-
-
- - - - - -
May 15, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/glxsb.4 3.html b/static/freebsd/man4/man4.i386/glxsb.4 3.html deleted file mode 100644 index b6449f5b..00000000 --- a/static/freebsd/man4/man4.i386/glxsb.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
GLXSB(4)Device Drivers Manual (i386)GLXSB(4)
-
-
-

-

glxsb — Geode LX - Security Block crypto accelerator

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device glxsb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
glxsb_load="YES"
-
-
-
-

-

The glxsb driver supports the security - block of the Geode LX series processors. The Geode LX is a member of the AMD - Geode family of integrated x86 system chips.

-

Driven by periodic checks for available data from the generator, - glxsb supplies entropy to the - random(4) driver for common usage.

-

glxsb also supports acceleration of - AES-128-CBC operations for crypto(4). It also registers - itself to accelerate other HMAC algorithms, although there is no hardware - acceleration for those algorithms. This is only needed so - glxsb can work with ipsec(4).

-
-
-

-

The crypto(9) framework will fail to open the - crypto session on the device if the AES key's length is != 128 bits. This - prevents the use of the glxsb device driver with AES - keys of length != 128 bits.

-
-
-

-

crypto(4), intro(4), - ipsec(4), pci(4), - random(4), crypto(7), - crypto(9)

-
-
-

-

The glxsb device driver first appeared in - OpenBSD 4.1. The glxsb - device driver was imported into FreeBSD 7.1.

-
-
-

-

The glxsb device driver was written for - OpenBSD by Tom Cosgrove. It - was ported to FreeBSD by Patrick - Lamaiziere - <patfbsd@davenulle.org>.

-
-
- - - - - -
July 29, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/longrun.4 3.html b/static/freebsd/man4/man4.i386/longrun.4 3.html deleted file mode 100644 index 11e7155f..00000000 --- a/static/freebsd/man4/man4.i386/longrun.4 3.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - -
LONGRUN(4)Device Drivers Manual (i386)LONGRUN(4)
-
-
-

-

longrun — - Transmeta(TM) Crusoe(TM) LongRun(TM) support

-
-
-

-

LongRun support is a collection of power saving modes for the - Transmeta Crusoe chips, similar in scope to Intel's SpeedStep. The following - sysctl(8) MIBs control the different CPU modes:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeChangeableDescription
hw.crusoe.longrunintegeryesLongRun mode:
0: minimum frequency mode
1: power-saving mode
2: performance mode
3: maximum frequency mode
hw.crusoe.frequencyintegernoCurrent frequency (MHz).
hw.crusoe.voltageintegernoCurrent voltage (mV).
hw.crusoe.percentageintegernoProcessing performance (%).
-
-
-

-

Print the current status:

-

-
% sysctl hw.crusoe
-

To set LongRun mode to performance oriented variable frequency - mode (less power savings):

-

-
# sysctl - hw.crusoe.longrun=2
-
-
-

-

The Transmeta(TM) Crusoe(TM) LongRun(TM) support first appeared in - FreeBSD 4.4.

-
-
-

-

LongRun support and this manual page were written by - Tamotsu HATTORI - <athlete@kta.att.ne.jp> - and Mitsuru IWASAKI - <iwasaki@FreeBSD.org>.

-
-
- - - - - -
June 30, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/npx.4 3.html b/static/freebsd/man4/man4.i386/npx.4 3.html deleted file mode 100644 index 2035cd5f..00000000 --- a/static/freebsd/man4/man4.i386/npx.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
NPX(4)Device Drivers Manual (i386)NPX(4)
-
-
-

-

npx — Numeric - Processing Extension coprocessor

-
-
-

-

device npx -
- hint.npx.0.at="nexus" -
- hint.npx.0.port="0x0F0" -
- hint.npx.0.flags="0x0" -
- hint.npx.0.irq="13"

-
-
-

-

The npx driver enables the use of the - system's Numeric Processing Extension coprocessor. Numeric processing - extensions are present in systems with 486DX CPUs and in systems with 387 or - 487SX coprocessors. The npx driver is required for - proper system functioning. If there is no NPX in the system, the system will - not boot.

-

The flags for npx0 are:

-

-
-
0x01
-
do not use the NPX registers to optimize bcopy.
-
0x02
-
do not use the NPX registers to optimize bzero.
-
0x04
-
do not use the NPX registers to optimize copyin or copyout.
-
-

The NPX registers are normally used to optimize copying and - zeroing when all of the following conditions are satisfied:

-

-
    -
  1. cpu I586_CPU is an option
    2. -
  2. the CPU is an i586 (perhaps not a Pentium)
    3. -
  3. the probe for npx0 succeeds
    4. -
  4. INT 16 exception handling works.
    5. -
-

Then copying and zeroing using the NPX registers is normally - 30-100% faster.

-

The flags can be used to control cases where it does not work or - is slower. Setting them at boot time using hints works correctly (the - optimizations are not used until later in the bootstrap when - npx0 is attached).

-
-
-

-

There are lots of them, especially on old cheap motherboards. In - particular, some motherboards do not have the interrupt lines from the NPX - to the CPU wired properly.

-
-
- - - - - -
August 28, 1993FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/pae.4 3.html b/static/freebsd/man4/man4.i386/pae.4 3.html deleted file mode 100644 index 2fc54c8a..00000000 --- a/static/freebsd/man4/man4.i386/pae.4 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
PAE(4)Device Drivers Manual (i386)PAE(4)
-
-
-

-

PAE — Physical - Address Extensions

-
-
-

-

options PAE

-
-
-

-

The PAE option provides support for the - physical address extensions capability of the Intel Pentium Pro and above - CPUs, and allows for up to 64 gigabytes of memory to be used in systems - capable of supporting it. With the PAE option, - memory above 4 gigabytes is simply added to the general page pool. The - system makes no distinction between memory above or below 4 gigabytes, and - no specific facility is provided for a process or the kernel to access more - memory than they would otherwise be able to access, through a sliding window - or otherwise.

-
-
-

-

smp(4), tuning(7), - config(8), bus_dma(9)

-
-
-

-

The PAE option first appeared in - FreeBSD 4.9 and FreeBSD - 5.1.

-
-
-

-

Jake Burkholder - <jake@FreeBSD.org>

-
-
-

-

Since KLD modules are not compiled with the same options headers - that the kernel is compiled with, they must not be loaded into a kernel - compiled with the PAE option.

-

Many devices or their device drivers are not capable of direct - memory access to physical addresses above 4 gigabytes. In order to make use - of direct memory access IO in a system with more than 4 gigabytes of memory - when the PAE option is used, these drivers must use - a facility for remapping or substituting physical memory which is not - accessible to the device. One such facility is provided by the - busdma interface. Device drivers which do not - account for such devices will not work reliably in a system with more than 4 - gigabytes of memory when the PAE option is used, and - may cause data corruption. The PAE kernel - configuration file includes the PAE option, and - explicitly excludes all device drivers which are known to not work or have - not been tested in a system with the PAE option and - more than 4 gigabytes of memory.

-

Many parameters which determine how memory is used in the kernel - are based on the amount of physical memory. The formulas used to determine - the values of these parameters for specific memory configurations may not - take into account the fact there may be more than 4 gigabytes of memory, and - may not scale well to these memory configurations. In particular, it may be - necessary to increase the amount of virtual address space available to the - kernel, or to reduce the amount of a specific resource that is heavily used, - in order to avoid running out of virtual address space. The - KVA_PAGES option may be used to increase the kernel - virtual address space, and the kern.maxvnodes - sysctl(8) may be used to decrease the number of vnodes - allowed, an example of a resource that the kernel is likely to overallocate - in large memory configurations. For optimal performance and stability it may - be necessary to consult the tuning(7) manual page, and - make adjustments to the parameters documented there.

-
-
- - - - - -
April 8, 2003FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/pbio.4 3.html b/static/freebsd/man4/man4.i386/pbio.4 3.html deleted file mode 100644 index 975cad88..00000000 --- a/static/freebsd/man4/man4.i386/pbio.4 3.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - -
PBIO(4)Device Drivers Manual (i386)PBIO(4)
-
-
-

-

pbio — 8255 - parallel peripheral interface basic I/O driver

-
-
-

-

device pbio

-

In /boot/device.hints: -
- hint.pbio.0.at="isa" -
- hint.pbio.0.port="0x360"

-

-
- #include - <dev/pbio/pbioio.h>

-
-
-

-

The pbio driver supports direct access to - the Intel 8255A programmable peripheral interface (PPI) chip running in mode - 0 (simple I/O). Such an interface provides 24 digital I/O lines. The driver - is designed for performing I/O under program control using peripherals such - as the Advantech PCL-724 card, which emulates the Intel 8255A PPI in mode 0. - Other 8255A-based peripherals such as the BMC Messsysteme PIO24II card have - also been reported to work.

-

The PPI provides two 8-bit ports (port A and port B) and two 4-bit - ports (port C upper, port C lower). Each port can be individually programmed - for input and (latched) output, and appears at a different offset of the - device's base I/O address.

-

A separate register allows the configuration of ports for input or - output. The device is so simple, that reliably probing for it when input - data arrives at its terminals is impossible; therefore the kernel - configuration has to specify the device's base address. The device driver - provides four character devices that correspond to the peripheral's I/O - ports. Opening a device for read or write automatically configures the - corresponding hardware port for input or output. At boot time all ports are - set configured for input to avoid damaging external circuitry.

-

A set of ioctl(2) requests allow polled input - and paced output to be efficiently performed at the driver level without - expensive user/kernel context switching. The driver can perform I/O in three - different ways:

-
-
Basic
-
The read or write operation returns immediately after reading or writing - the data to the port at bus speed.
-
Paced
-
Data is transferred from or to the port at intervals specified by a - separate ioctl(2) call.
-
Differential
-
(Input only.) Only port values that differ from the previous port value - are returned.
-
-

The pacing interval is specified in - unit increments. - Setting a pace of n seconds will result in no more - than one value being read or written every n seconds. - Single byte read/write operations will take at least n - seconds to complete.

-

The following ioctl(2) calls are supported:

-
-
-
accepts a pointer to an integer as the third argument, and sets the driver - for differential input if the integer is non-zero. The input pace speed - determines the periodic interval the driver will use to examine the port - for a changed value.
-
-
accepts a pointer to an integer as the third argument, and sets the - integer to the last set value for differential input.
-
-
accepts a pointer to an integer as the third argument, and sets the - driver's input pacing speed to the value of that integer.
-
-
accepts a pointer to an integer as the third argument, and sets the - integer to the last set value for the input pace.
-
-
accepts a pointer to an integer as the third argument, and sets the - driver's output pacing speed to the value of that integer.
-
-
accepts a pointer to an integer as the third argument, and sets the - integer to the last set value for the output pace.
-
-
-
-

-
-
/dev/pbio0a
-
Port A (8 bit I/O).
-
/dev/pbio0b
-
Port B (8 bit I/O).
-
/dev/pbio0ch
-
Port C upper (4 bit I/O).
-
/dev/pbio0cl
-
Port C lower (4 bit I/O).
-
-
-
-

-

Diomidis Spinellis, - The information furnace: Consolidated home control, - Personal and Ubiquitous Computing, - 1, 7, - 53-69, 2003.

-
-
-

-

The pbio device was first used under - FreeBSD 4.1.

-
-
-

-

Diomidis D. Spinellis - <dds@aueb.gr>

-
-
-

-

One of the PCL-724 card's inputs can optionally be wired to - generate an interrupt. This feature is not supported.

-
-
- - - - - -
January 14, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/pnp.4 3.html b/static/freebsd/man4/man4.i386/pnp.4 3.html deleted file mode 100644 index 76754e94..00000000 --- a/static/freebsd/man4/man4.i386/pnp.4 3.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
PNP(4)Device Drivers Manual (i386)PNP(4)
-
-
-

-

pnp — support for - “Plug and Play” (PnP) ISA devices

-
-
-

-

The pnp driver enumerates ISA devices - which support “Plug and Play ISA Specification” in the system. - It assigns ISA bus resources (interrupt line, DMA channel, I/O ports, and - memory region) to each device and activates it.

-

If it cannot assign necessary resources to a PnP ISA device - without causing conflict with other devices in the system, the device will - not be activated and will be unavailable to programs.

-
-
-

-

pnpbios(4)

-
-
-

-

Intel and - Microsoft, Plug and Play ISA - Specification, Version 1.0a, May 5, - 1994.

-

Clarifications to the Plug and - Play ISA Specification, Version 1.0a, December 10, - 1994.

-
-
-

-

The pnp driver first appeared in - FreeBSD 2.2.5. It has been substantially updated in - subsequent versions.

-
-
-

-

PnP support was originally written for FreeBSD - 2.2.5 by Luigi Rizzo, based on initial work - done by Sujal Patel.

-
-
-

-

It is not possible to disable individual PnP ISA devices. The - pnp driver will find all devices conforming the PnP - ISA specification and try to activate them all.

-

There is no way to explicitly assign particular resource to the - PnP ISA device. The resource assignment is fully automatic and there is no - provision for manual override.

-
-
- - - - - -
September 20, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/pnpbios.4 3.html b/static/freebsd/man4/man4.i386/pnpbios.4 3.html deleted file mode 100644 index fc89ab57..00000000 --- a/static/freebsd/man4/man4.i386/pnpbios.4 3.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
PNPBIOS(4)Device Drivers Manual (i386)PNPBIOS(4)
-
-
-

-

pnpbios — support - for embedded devices on the motherboard

-
-
-

-

The pnpbios driver enumerates embedded ISA - devices on the motherboard whose BIOS supports “Plug and Play BIOS - Specification”. It assigns ISA bus resources (interrupt line, DMA - channel, I/O ports, and memory region) to each device and activates it.

-

If it cannot assign necessary resources to a device without - causing conflict with other devices in the system, the device will not be - activated and will be unavailable to programs.

-
-
-

-

pnp(4)

-
-
-

-

Compaq, - Phenix, and Intel, - Plug and Play BIOS Specification Version 1.0A, - May 5, 1994.

-

Compaq, - Phenix, and Intel, - Plug and Play BIOS CLARIFICATION Paper for Plug and Play - BIOS Specification Version 1.0A, October 6, - 1994.

-
-
-

-

The pnpbios driver first appeared in - FreeBSD 4.0.

-
-
-

-

The pnpbios driver was written by - Mike Smith.

-
-
-

-

There is no explicit way to disable individual embedded devices. - The pnpbios driver will find all devices reported by - the “Plug and Play (PnP)” BIOS and try to activate them - all.

-

There is no way to explicitly assign particular resource to a - device. The resource assignment is fully automatic and there is no provision - for manual override.

-
-
- - - - - -
September 20, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/sbni.4 3.html b/static/freebsd/man4/man4.i386/sbni.4 3.html deleted file mode 100644 index 750369e9..00000000 --- a/static/freebsd/man4/man4.i386/sbni.4 3.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
SBNI(4)Device Drivers Manual (i386)SBNI(4)
-
-
-

-

sbni — Granch - SBNI12 leased line modem driver

-
-
-

-

device sbni

-
-
-

-

The sbni driver provides support for - leased line modems of following models:

-

-
    -
  • SBNI12-02, SBNI12D-02
    • -
  • SBNI12-04, SBNI12D-04
    • -
  • SBNI12-05, SBNI12D-05, ISA and PCI
    • -
  • SBNI12-10, SBNI12D-10, ISA and PCI
    • -
-

and a kit for data link over a voice band:

-
    -
  • SBNI12-11, SBNI12D-11, ISA and PCI.
    • -
-

In addition to the standard port and IRQ specifications, the - sbni driver also supports a number of - flags which can set baud rate, receive level, and low - three bytes of Ethernet MAC-address (high three are always - 00:ff:01), because Granch modems are presented to - the system as Ethernet-like network cards.

-

The high byte of the flags is a bit field, - it is used to specify SBNI adapter receive level/baud rate:

-
-
-
Bits 0-3:
-
receive level (0x00..0x0f)
-
Bits 4-5:
-
baud rate number: -

-
-
00 -
-
0 baud rate (2Mb in fast mode/500kb in slow)
-
01 -
-
1 baud rate (1Mb/250kb)
-
10 -
-
2 baud rate (500kb/125kb)
-
11 -
-
3 baud rate (250kb/62.5kb)
-
-
-
Bit 6:
-
use fixed receive level -

if bit 6 is set then receive level will be set according to - bits 0-3 value, otherwise receive level will be autodetected

-
-
Bit 7:
-
use fixed baud rate -

if bit 7 is set then baud rate will be set according to bits - 4-5 value, otherwise baud rate is set to 2Mb

-
-
-
-
-
-

-

The sources for the driver reside in:

-

-
-
/sys/dev/sbni/if_sbni.c
-
 
-
/sys/dev/sbni/if_sbnireg.h
-
 
-
/sys/dev/sbni/if_sbnivar.h
-
 
-
-
-
-

-

arp(4), netintro(4), - ifconfig(8)

-
-
-

-

The sbni device driver first appeared in - FreeBSD 4.6.

-
-
-

-

The sbni device driver for - FreeBSD 4.x was written by Denis I. - Timofeev, partially based on David Greenman's - ed(4) driver. Earlier versions (available on - ftp.granch.com) were written by - Alexey V. Zverev.

-

SBNI12 hardware was designed by Alexey V. - Chirkov.

-
-
- - - - - -
January 8, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/smapi.4 3.html b/static/freebsd/man4/man4.i386/smapi.4 3.html deleted file mode 100644 index f7a17564..00000000 --- a/static/freebsd/man4/man4.i386/smapi.4 3.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
SMAPI(4)Device Drivers Manual (i386)SMAPI(4)
-
-
-

-

smapi — System - Management Application Program Interface driver

-
-
-

-

Many IBM Thinkpad laptops utilize a special software interface - known as SMAPI (System Management Application Program Interface). This - interface controls various aspects of the system including:

-
    -
  • System Interface (the BIOS can store system information such as the system - identifier),
    • -
  • System Configuration (where devices such as the display can be - configured),
    • -
  • Power Management (software can interact with the SMAPI BIOS for Power - Management control).
    • -
-

Client software must locate a “header image” stored - in the F000 segment in the Thinkpad ROM (read-only - memory), which resides at the 16-byte boundary. This is considered the - “Entry Point” for the service.

-

The “header image” stores information like:

-
    -
  • signature,
    • -
  • SMAPI version (major and minor),
    • -
  • header image length,
    • -
  • checksum information (which verifies the image),
    • -
  • an Information Word (used to identify the BIOS service level),
    • -
  • Real Mode Entry Point (where clients using the Real/V86 mode for the - far-call value),
    • -
  • and finally a 16-bit/32-bit Protected Mode Entry Point: base code address - which specifies the BIOS physical address. The client must prepare a 64 - kilobyte selector for this BIOS).
    • -
-

To invoke the SMAPI BIOS, a far-call must be used on the entry - point specified in the header file. All other information should be stored - in the client data area. The client is required to prepare both an input and - output parameter in a data area of its own. This area can be - “informed” by pushing those pointers into its stack before the - far-calls.

-

The SMAPI BIOS uses the stack and data areas with the selector - during a BIOS invocation, thus the caller must define the same privilege - area as the BIOS.

-

The parameter structure will be made up by using the input and - output fields prepared by the caller. The input field will specify the - function request to the BIOS. The BIOS will then drop a return value into - the output field. These fields are made up of three parts. The first holds - parameters, function numbers, and return codes. The next will contain an - offset in hexadecimal. Finally a length field which is comprised of Byte, - Word, or Double Word.

-
-
-

-

IBM Thinkpad 560/560E Technical - Reference, 06J0536 S76H-7587-01.

-

IBM Thinkpad 560Z Technical - Reference, xxxxxxx xxxx-xxxx-xx.

-

IBM Thinkpad 600 Technical - Reference, xxxxxxx xxxx-xxxx-xx.

-

IBM Thinkpad 760XD/760XL/765D/765L - Technical Reference, 06J0537 - S30H-2433-02.

-

IBM Thinkpad 770 Technical - Reference, 05L1739 S05L-1739-00.

-
-
-

-

The smapi driver was written by - Matthew N. Dodd - <mdodd@FreeBSD.org>. - This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org> - and Matthew N. Dodd - <mdodd@FreeBSD.org>.

-
-
- - - - - -
April 1, 2003FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.i386/vpd.4 3.html b/static/freebsd/man4/man4.i386/vpd.4 3.html deleted file mode 100644 index fd31fead..00000000 --- a/static/freebsd/man4/man4.i386/vpd.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
VPD(4)Device Drivers Manual (i386)VPD(4)
-
-
-

-

vpd — Vital - Product Data kernel interface

-
-
-

-

device vpd

-
-
-

-

IBM ThinkPad notebooks (and most IBM desktop PCs) have a 48-byte - Vital Product Data (VPD) structure located in the BIOS Shadow RAM.

-

The VPD provides machine type and model information, the build ID - (this is roughly the BIOS version) and serial number information.

-

The vpd driver scans the BIOS area and - claims the memory used by the VPD structure. It provides the - sysctl(3) branch hw.vpd to allow - this information to be accessed by the userland. The following variables are - provided, one per VPD attachment (there should only be one):

-

-
-
-
(machine.type) Machine type.
-
-
(machine.model) Machine model.
-
-
(build.id) BIOS Build ID.
-
-
(serial.box) Box Serial Number.
-
-
(serial.planar) Motherboard Serial Number.
-
-
-
-

-

TP General - Using the BIOS - Build ID to identify IBM ThinkPad systems, - Reference #: MIGR-45120, - http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45120, - November 22, 2002.

-
-
-

-

The vpd driver first appeared in - FreeBSD 5.1.

-
-
-

-

The vpd driver and this manual page were - written by Matthew N. Dodd - <mdodd@FreeBSD.org>.

-
-
- - - - - -
August 31, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/abtn.4 3.html b/static/freebsd/man4/man4.powerpc/abtn.4 3.html deleted file mode 100644 index 3d82d392..00000000 --- a/static/freebsd/man4/man4.powerpc/abtn.4 3.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
ABTN(4)Device Drivers Manual (powerpc)ABTN(4)
-
-
-

-

abtn — ADB - Keyboard Special Keys Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device adb
-
-
-

-

The abtn driver provides support for the - extended Fn keys on Apple notebooks with an ADB interface.

-
-
-

-

The abtn driver supports extended keyboard - keys (special F-keys) on the following devices:

-

-
    -
  • Apple iBook Keyboard
    • -
  • Apple PowerBook Keyboard
    • -
-
-
-

-

The abtn driver sends events to - devd(8) for the following events under the - PMU system, and keys - subsystem:

-

-
    -
  • brightness - Generates up - and down notify types matching the pressed - key.
    • -
  • mute
    • -
  • volume - Generates up and - down notify types matching the pressed key.
    • -
  • eject
    • -
-

Examples are included in /etc/devd/apple.conf.

-
-
-

-

adb(4), akbd(4), - cuda(4), pmu(4), - devd(8)

-
-
-

-

The abtn device driver first appeared in - NetBSD 5.0 and was ported to - FreeBSD 10.0.

-
-
-

-

The abtn driver was written by - Tsubai Masanari for NetBSD - and ported to FreeBSD by Justin - Hibbits.

-
-
- - - - - -
October 16, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/adb.4 3.html b/static/freebsd/man4/man4.powerpc/adb.4 3.html deleted file mode 100644 index 3aa139c1..00000000 --- a/static/freebsd/man4/man4.powerpc/adb.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
ADB(4)Device Drivers Manual (powerpc)ADB(4)
-
-
-

-

adb — Apple - Desktop Bus

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device adb
-
-
-

-

The adb driver provides support for the - Apple Desktop Bus, which is a simple multi-drop bus used in general for - input peripherals in older Apple Macintosh hardware.

-

The Apple Desktop Bus provides attachment for up to 16 devices, - including multiple devices of a single type, but not does support - hot-plugging.

-
-
-

-

Apple Tech Note HW01: ADB - The Untold Story: Space Aliens Ate My - Mouse: - http://developer.apple.com/legacy/mac/library/technotes/hw/hw_01.html

-

akbd(4), ams(4), - cuda(4), pmu(4)

-
-
-

-

The adb device driver appeared in - FreeBSD 8.0.

-
-
-

-

The adb driver was written by - Nathan Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
December 3, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/akbd.4 3.html b/static/freebsd/man4/man4.powerpc/akbd.4 3.html deleted file mode 100644 index 39ba2130..00000000 --- a/static/freebsd/man4/man4.powerpc/akbd.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
AKBD(4)Device Drivers Manual (powerpc)AKBD(4)
-
-
-

-

akbd — ADB - Keyboard Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device adb
-
-
-

-

The akbd driver provides support for all - keyboards attached to the Apple Desktop Bus (ADB).

-
-
-

-

Devices supported by the akbd driver - include:

-

-
    -
  • Apple Extended Keyboard
    • -
  • Apple Keyboard II
    • -
  • Apple iBook Keyboard
    • -
  • Apple PowerBook Keyboard
    • -
-
-
-

-

The akbd driver sends events to - devd(8) for the following events under the - PMU system:

-

-
    -
  • Power button - Button subsystem, - pressed type.
    • -
-
-
-

-

The akbd driver supports the following - sysctl variable for configuring the Fn keys:

-
-
dev.akbd.%d.fn_keys_function_as_primary
-
Set the Fn keys to be their F-key type as default. A value of 0 causes the - F-keys keys to work as special keys by default ( - abtn(4)) and a value of 1 sets them to behave as F-keys - by default.
-
-
-
-

-

abtn(4), adb(4), - cuda(4), pmu(4)

-
-
-

-

The akbd device driver appeared in - FreeBSD 8.0.

-
-
-

-

The akbd driver was written by - Nathan Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
December 3, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/ams.4 3.html b/static/freebsd/man4/man4.powerpc/ams.4 3.html deleted file mode 100644 index 6fe0fa87..00000000 --- a/static/freebsd/man4/man4.powerpc/ams.4 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
AMS(4)Device Drivers Manual (powerpc)AMS(4)
-
-
-

-

ams — ADB Mouse - Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device adb
-
-
-

-

The ams driver provides support for mice - and trackpads attached to the Apple Desktop Bus (ADB) implementing both the - base and extended ADB mouse protocols.

-
-
-

-

Devices supported by the ams driver - include:

-

-
    -
  • Apple Mouse
    • -
  • ADB Extended Mouse
    • -
  • MacAlly 2-Button Mouse
    • -
  • Apple iBook Trackpad
    • -
  • Apple PowerBook Trackpad
    • -
-
-
-

-
-
dev.ams.%d.tapping
-
On ADB trackpads, setting this sysctl to 1 causes taps on the trackpad to - be interpreted as button clicks.
-
-
-
-

-

Apple Tech Note HW01: ADB - The Untold Story: Space Aliens Ate My - Mouse: - http://developer.apple.com/legacy/mac/library/technotes/hw/hw_01.html

-

adb(4), cuda(4), - pmu(4)

-
-
-

-

The ams device driver appeared in - FreeBSD 8.0.

-
-
-

-

The ams driver was written by - Nathan Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
December 3, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/cuda.4 3.html b/static/freebsd/man4/man4.powerpc/cuda.4 3.html deleted file mode 100644 index a3bb0c73..00000000 --- a/static/freebsd/man4/man4.powerpc/cuda.4 3.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
CUDA(4)Device Drivers Manual (powerpc)CUDA(4)
-
-
-

-

cuda — Apple CUDA - I/O Controller Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device adb -
-device cuda
-
-
-

-

The cuda driver provides support for the - CUDA VIA (Versatile Interface Attachment) chip found in pre-Core99 Apple - hardware, such as the Power Macintosh G3.

-

The Apple CUDA controller is a multi-purpose ASIC that provides - power control and an adb(4) interface.

-
-
-

-

Chips supported by the cuda driver - include:

-

-
    -
  • Apple CUDA I/O Controller
    • -
-
-
-

-

adb(4)

-
-
-

-

The cuda device driver appeared in - NetBSD 4.0, and then in FreeBSD - 8.0.

-
-
-

-

The cuda driver was written by - Michael Lorenz - <macallan@NetBSD.org> - and ported to FreeBSD by Nathan - Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
December 3, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/dtsec.4 3.html b/static/freebsd/man4/man4.powerpc/dtsec.4 3.html deleted file mode 100644 index 58890d72..00000000 --- a/static/freebsd/man4/man4.powerpc/dtsec.4 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
DTSEC(4)Device Drivers Manual (powerpc)DTSEC(4)
-
-
-

-

dtsec — Freescale - Datapath Acceleration Architecture-based Three-Speed Ethernet Controller - device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
include - "dpaa/config.dpaa" -
-device dpaa -
-device miibus
-
-
-

-

The dtsec driver provides support for the - DPAA-based gigabit Ethernet controller integrated in some of the Freescale - system-on-chip devices.

-

The dtsec driver supports the following - media types:

-
-
autoselect
-
Enable autoselection of the media type and options
-
10baseT/UTP
-
Set 10Mbps operation
-
100baseTX
-
Set 100Mbps operation
-
1000baseT
-
Set 1000baseT operation
-
-

The dtsec driver supports the following - media options:

-
-
full-duplex
-
Set full duplex operation
-
-

The dtsec driver supports two operating - modes:

-
-
Regular
-
Normal mode, utilizing the full datapath acceleration, Buffer Manager, and - Queue Manager.
-
Independent
-
Runs disconnected from the Buffer Manager and Queue Manager.
-
-
-
-

-

Gigabit Ethernet controllers built into the following Freescale - system-on-chip devices are known to work with the - dtsec driver:

-

-
    -
  • P2041, P3041
    • -
  • P5010, P5020
    • -
-

Additionally, the following devices are expected to work, but are - untested:

-
    -
  • P4080, P4040
    • -
  • P5040
    • -
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), ifconfig(8)

-
-
-

-

The dtsec device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The base version of dtsec device driver - was written by Semihalf. This manual page was - written by Justin Hibbits.

-
-
- - - - - -
October 31, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/llan.4 3.html b/static/freebsd/man4/man4.powerpc/llan.4 3.html deleted file mode 100644 index d61be691..00000000 --- a/static/freebsd/man4/man4.powerpc/llan.4 3.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
LLAN(4)Device Drivers Manual (powerpc)LLAN(4)
-
-
-

-

llan — POWER - Logical Lan

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device llan
-
-
-

-

The llan driver provides support for the - inter-partition logical LAN controller provided by PAPR-compliant POWER - hypervisors (such as PowerVM and PowerKVM). On some firmwares, advanced - offload features are supported by the hypervisor, but these are not - currently supported by the driver.

-
-
-

-

vtnet(4), ifconfig(8)

-
-
-

-

The llan device driver appeared in - FreeBSD 10.0.

-
-
-

-

The llan driver was written by - Nathan Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
February 19, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/ofw_console.4 3.html b/static/freebsd/man4/man4.powerpc/ofw_console.4 3.html deleted file mode 100644 index c373b786..00000000 --- a/static/freebsd/man4/man4.powerpc/ofw_console.4 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
OFW_CONSOLE(4)Device Drivers Manual (powerpc)OFW_CONSOLE(4)
-
-
-

-

ofw_console — Open - Firmware console

-
-
-

-

cpu AIM -
- options OFWCONS_POLL_HZ=N

-

-
- options KDB -
- options DDB -
- options ALT_BREAK_TO_DEBUGGER

-
-
-

-

The ofw_console driver provides a simple - text console, using the Open Firmware services for input and output. It will - use the Open Firmware console devices set via the - input-device and output-device - variables.

-

This driver is deprecated and only provided as a fallback console - mechanism if the real console hardware can not be driven by - FreeBSD.

-

In case the ofw_console console appears to - work too slowly, its responsiveness probably can be improved by including - options OFWCONS_POLL_HZ=N. When omitted, - OFWCONS_POLL_HZ defaults to 4. For example, on Sun - Ultra 2 a value of 20 or higher works best. Too high values, on the other - hand, can cause ofw_console to unnecessarily consume - CPU.

-
-
-

-
-
/dev/console
-
 
-
/dev/keyboard
-
terminal input device in case the console input device is the - keyboard
-
/dev/screen
-
terminal output device in case the console output device is the - screen
-
/dev/tty[a-z]
-
terminal device in case both the console input and output device is - tty[a-z]
-
-
-
-

-

akbd(4), powermac_nvram(4), - vt(4)

-
-
-

-

The ofw_console driver first appeared in - FreeBSD 5.0.

-
-
-

-

The ofw_console driver was written by - Benno Rice - <benno@FreeBSD.org>.

-
-
-

-

Since the Open Firmware will handle BREAK (or Stop-A) sequences - before ofw_console, the preferred way to enter - ddb(4) when using ofw_console is - to include options ALT_BREAK_TO_DEBUGGER in a - ddb-enabled kernel, and enter the alternate BREAK sequence (RETURN TILDE - CTRL-b).

-
-
-

-

The ofw_console driver also not attach to - the hardware resources it actually talks to.

-
-
- - - - - -
January 16, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/pmu.4 3.html b/static/freebsd/man4/man4.powerpc/pmu.4 3.html deleted file mode 100644 index 1c9b90ea..00000000 --- a/static/freebsd/man4/man4.powerpc/pmu.4 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
PMU(4)Device Drivers Manual (powerpc)PMU(4)
-
-
-

-

pmu — Apple PMU99 - Power Management Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device adb -
-device pmu
-
-
-

-

The pmu driver provides support for the - Power Management Unit (PMU) found in Apple Core99 hardware. This includes - late G3 laptops, all G4 machines, early G5 desktops and all G5 XServes.

-

The Apple PMU controller is a multi-purpose ASIC that provides - power management and thermal control, as well as an ADB bus for the internal - keyboard and mouse on laptops.

-
-
-

-

Chips supported by the pmu driver - include:

-

-
    -
  • Apple KeyLargo PMU
    • -
  • Apple K2-KeyLargo PMU
    • -
-
-
-

-

The pmu driver provides power management - services in addition to an adb(4) interface. The following - sysctls can be used to control the power management behavior and to examine - current system power and thermal conditions.

-
-
dev.pmu.%d.server_mode
-
Restart after power failure behavior (1 causes system to reboot after - power cut, 0 causes system to remain off).
-
dev.pmu.%d.batteries.%d.present
-
Indicates whether the relevant battery is inserted.
-
dev.pmu.%d.batteries.%d.charging
-
Indicates whether the battery is currently charging.
-
dev.pmu.%d.batteries.%d.charge
-
The current battery charge, in milliamp hours.
-
dev.pmu.%d.batteries.%d.maxcharge
-
The battery's self-reported maximum charge, in milliamp hours.
-
dev.pmu.%d.batteries.%d.rate
-
The current into the battery, in milliamps. While the battery is - discharging, this will be negative.
-
dev.pmu.%d.batteries.%d.voltage
-
Battery voltage, in millivolts.
-
dev.pmu.%d.batteries.%d.time
-
Estimated time until full battery charge (or discharge), in minutes.
-
dev.pmu.%d.batteries.%d.life
-
Current fraction of the battery's maximum charge, in percent.
-
-
-
-

-

acpi(4), adb(4), - led(4)

-
-
-

-

The pmu device driver appeared in - NetBSD 4.0, and then in FreeBSD - 8.0.

-
-
-

-

The pmu driver was written by - Michael Lorenz - <macallan@NetBSD.org> - and ported to FreeBSD by Nathan - Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
December 6, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/powermac_nvram.4 3.html b/static/freebsd/man4/man4.powerpc/powermac_nvram.4 3.html deleted file mode 100644 index 664e53af..00000000 --- a/static/freebsd/man4/man4.powerpc/powermac_nvram.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
POWERMAC_NVRAM(4)Device Drivers Manual (powerpc)POWERMAC_NVRAM(4)
-
-
-

-

powermac_nvram — - non-volatile RAM

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device powermac_nvram
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
powermac_nvram_load="YES"
-
-
-
-

-

The powermac_nvram driver provides access - to the Open Firmware configuration NVRAM available on the Apple - PowerPC-based machines.

-

This driver currently supports "Core99" machines - containing a Sharp, Micron, or AMD NVRAM.

-
-
-

-

nvram(8)

-
-
-

-

The powermac_nvram driver first appeared - in FreeBSD 7.0.

-
-
-

-

The powermac_nvram driver was written by - Maxim Sobolev - <sobomax@FreeBSD.org>.

-
-
- - - - - -
June 19, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/smu.4 3.html b/static/freebsd/man4/man4.powerpc/smu.4 3.html deleted file mode 100644 index 09c9d88c..00000000 --- a/static/freebsd/man4/man4.powerpc/smu.4 3.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - -
SMU(4)Device Drivers Manual (powerpc)SMU(4)
-
-
-

-

smu — Apple System - Management Unit Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device smu
-
-
-

-

The smu driver provides support for the - System Management Unit (SMU) found in many Apple G5 systems. This includes - most Power Macintosh G5 and all iMac G5 systems.

-

The Apple SMU controller provides software power management and - thermal control functionality, and is responsible for managing system - cooling devices.

-
-
-

-

Chips supported by the smu driver - include:

-

-
    -
  • Apple System Management Unit
    • -
-
-
-

-

The smu driver provides basic automatic - thermal management. Without a userspace daemon providing more advanced - control, the driver will attempt to maintain system temperatures in a - conservative range through coarse-grained control of system cooling devices - (see below). Automatic kernel-level thermal control will take over if more - than 3 seconds elapses between userspace cooling setting adjustments.

-
-
-

-

The smu driver provides power management - services and thermal readout through a sysctl interface. The following - sysctls can be used to control the power management behavior and to examine - current system power and thermal conditions.

-
-
dev.smu.%d.server_mode
-
Restart after power failure behavior (1 causes system to reboot after - power cut, 0 causes system to remain off).
-
dev.smu.%d.target_temp
-
Target system temperature, in degrees Celsius. The - smu driver will attempt to adjust fans to maintain - the temperature of the warmest component in the system at or below this - level.
-
dev.smu.%d.critical_temp
-
System critical temperature, in degrees Celsius. If any component in the - system exceeds this temperature, the machine will be shut down within 500 - ms.
-
dev.smu.%d.fans.%s.minrpm
-
Minimum allowed speed for this fan.
-
dev.smu.%d.fans.%s.maxrpm
-
Maximum allowed speed for this fan.
-
dev.smu.%d.fans.%s.rpm
-
Current speed for this fan. The fan speed can be adjusted by changing this - sysctl. If more than 3 seconds elapses between fan speed adjustments, the - kernel will resume automatic control of the fan.
-
dev.smu.%d.sensors.%s
-
Current reading from this sensor. Four sensor types are supported. - Temperature sensors are in units of degrees Celsius, current sensors in - milliamps, voltage sensors in millivolts, and power sensors in - milliwatts.
-
-
-
-

-

The smu driver provides an - led(4) annunciator interface at - /dev/led/sleepled.

-
-
-

-

acpi(4), led(4), - pmu(4)

-
-
-

-

The smu device driver appeared in - FreeBSD 8.0.

-
-
-

-

The smu driver was written by - Nathan Whitehorn - <nwhitehorn@FreeBSD.org>.

-
-
- - - - - -
February 22, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/snd_ai2s.4 3.html b/static/freebsd/man4/man4.powerpc/snd_ai2s.4 3.html deleted file mode 100644 index 8279fde3..00000000 --- a/static/freebsd/man4/man4.powerpc/snd_ai2s.4 3.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
SND_AI2S(4)Device Drivers Manual (powerpc)SND_AI2S(4)
-
-
-

-

snd_ai2s — Apple - I2S audio device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_ai2s
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_ai2s_load="YES"
-
-
-
-

-

The snd_ai2s driver provides support for - the Apple I2S audio controllers found predominantly in G4 and G5 machines, - along with the snapper and tumbler codecs. Some machines (e.g. the Mac Mini) - do not have configurable codecs and so lack hardware volume control.

-
-
-

-

Chips supported by the snd_ai2s driver - include:

-

-
    -
  • Apple Tumbler Audio
    • -
  • Apple Snapper Audio
    • -
-
-
-

-

snd_davbus(4), sound(4)

-
-
-

-

The snd_ai2s device driver appeared in - NetBSD 2.0 and then in FreeBSD - 8.0.

-
-
-

-

The snd_ai2s driver was written by - Tsubai Masanari - <tsubai@netbsd.org>, - and ported to FreeBSD by Marco - Trillo - <marcotrillo@gmail.com>.

-
-
-

-

Recording and operation with non-44.1 Khz audio are not currently - supported.

-
-
- - - - - -
January 20, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/snd_davbus.4 3.html b/static/freebsd/man4/man4.powerpc/snd_davbus.4 3.html deleted file mode 100644 index ff0a6769..00000000 --- a/static/freebsd/man4/man4.powerpc/snd_davbus.4 3.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
SND_DAVBUS(4)Device Drivers Manual (powerpc)SND_DAVBUS(4)
-
-
-

-

snd_davbus — Apple - Davbus audio device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_davbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_davbus_load="YES"
-
-
-
-

-

The snd_davbus driver provides support for - the Apple Davbus audio controllers found in many G3-era Apple machines.

-
-
-

-

Chips supported by the snd_davbus driver - include:

-

-
    -
  • Apple Burgundy Audio
    • -
  • Apple Screamer Audio
    • -
-
-
-

-

snd_ai2s(4), sound(4)

-
-
-

-

The snd_davbus device driver appeared in - FreeBSD 8.0.

-
-
-

-

The snd_davbus driver was written by - Marco Trillo - <marcotrillo@gmail.com>.

-
-
-

-

Recording is not currently supported.

-
-
- - - - - -
January 20, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/man4.powerpc/tsec.4 3.html b/static/freebsd/man4/man4.powerpc/tsec.4 3.html deleted file mode 100644 index 94b6d452..00000000 --- a/static/freebsd/man4/man4.powerpc/tsec.4 3.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - -
TSEC(4)Device Drivers Manual (powerpc)TSEC(4)
-
-
-

-

tsec — Freescale - Three-Speed Ethernet Controller device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device tsec -
-device miibus
-
-
-

-

The tsec driver provides support for the - gigabit Ethernet controller integrated in some of the Freescale - system-on-chip devices.

-

The tsec driver supports the following - media types:

-
-
autoselect
-
Enable autoselection of the media type and options
-
10baseT/UTP
-
Set 10Mbps operation
-
100baseTX
-
Set 100Mbps operation
-
1000baseT
-
Set 1000baseT operation
-
-

The tsec driver supports the following - media options:

-
-
full-duplex
-
Set full duplex operation
-
-

The tsec driver supports polled operation - when the system is configured with DEVICE_POLLING kernel option, see - polling(4) for more details.

-

The tsec driver supports reception and - transmission of extended frames for vlan(4). This - capability of tsec can be controlled by means of the - vlanmtu parameter to - ifconfig(8).

-

The tsec driver supports interrupts - coalescing (IC) so that raising a transmit/receive frame interrupt is - delayed, if possible, until a threshold-defined period of time has elapsed, - or a threshold-defined frame counter has been reached (whichever occurs - first). The following sysctls regulate this behaviour:

-
-
dev.tsec.X.int_coal.rx_time
-
 
-
dev.tsec.X.int_coal.rx_count
-
 
-
dev.tsec.X.int_coal.tx_time
-
 
-
dev.tsec.X.int_coal.tx_count
-
-

Value of 0 for either time or count disables IC on the given - path. Time value 1-65535 corresponds to a real time period and is - expressed in units equivalent to 64 ticks of the TSEC clock. Count 1-255 - represents the number of frames (note that value of 1 is equivalent to - IC disabled). User provided values larger than supported will be trimmed - to the maximum supported. More details are available in the reference - manual of the device.

-
-
-
-
-

-

Gigabit Ethernet controllers built into the following Freescale - system-on-chip devices are known to work with the - tsec driver:

-

-
    -
  • MPC8349
    • -
  • MPC8533, MPC8541, MPC8555
    • -
-

The enhanced version of the controller (eTSEC), integrated in the - following devices, is also supported by this driver:

-

-
    -
  • MPC8548, MPC8572
    • -
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-
-
-

-

The tsec device driver first appeared in - FreeBSD 8.0.

-
-
-

-

The base version of tsec device driver was - written by Piotr Kruszynski. It has been extended - with polling and interrupt coalescing support by Rafal - Jaworowski. It has been further enhanced with multicast, h/w checksum - calculation and vlan support by Piotr Ziecik. This - manual page was written by Rafal Jaworowski.

-
-
- - - - - -
February 20, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/max44009.4 4.html b/static/freebsd/man4/max44009.4 4.html deleted file mode 100644 index 12c291e7..00000000 --- a/static/freebsd/man4/max44009.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
MAX44009(4)Device Drivers ManualMAX44009(4)
-
-
-

-

max44009 — driver - for MAX44009 Ambient Light Sensor

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device max44009 -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
max44009_load="YES"
-
-
-
-

-

The max44009 driver reports illuminance - data from MAX44009 Ambient Light Sensor.

-

The max44009 driver reports data via - sysctl(8) entry in the device's node in the - sysctl(8) tree:

-
-
illuminance
-
The illuminance, in lux units.
-
-

On an FDT(4) based system the following - properties must be set:

-
-
compatible
-
Must be set to "maxim,max44009".
-
reg
-
The I2C address of max44009 which can be either - 0x4a or 0x4b.
-
-
-
-

-

fdt(4), iicbus(4), - sysctl(8)

-
-
-

-

The max44009 driver and this manual page - was written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
-

-

The max44009 driver does not support - illuminance thresholds and the corresponding interrupt.

-
-
- - - - - -
November 6, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/mca.4 3.html b/static/freebsd/man4/mca.4 3.html deleted file mode 100644 index 91d3b190..00000000 --- a/static/freebsd/man4/mca.4 3.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - -
MCA(4)Device Drivers Manual (amd64)MCA(4)
-
-
-

-

mca — Machine - Check Architecture

-
-
-

-

The mca subsystem provides support for the - x86 Machine Check Architecture. The CPU uses this architecture to report - various hardware problems, ranging from correctible errors to uncorrectible - fatal errors. The mca subsystem processes the errors - reported by the CPU and logs them according to the user-supplied - configuration.

-

The mca subsystem is automatically - compiled into every x86 kernel.

-
-
-

-

By default, every message is logged to four locations:

-
    -
  • The console
    • -
  • The system log (using the LOG_KERN - syslog(3) facility)
    • -
  • An in-kernel cache of event records
    • -
  • A statistics array
    • -
-

An administrator can disable console logging of non-fatal errors - using the hw.mca.uselog sysctl(8) or - tunable setting. Fatal errors are always logged to the console.

-

The in-kernel cache of event records can be accessed from - userspace using the hw.mca.records - sysctl(8) node. By default, the in-kernel cache of event - records grows without bound and contains records for all - mca events received since system boot. The cache can - be limited (in which case it turns into a ring buffer) or disabled - altogether using the hw.mca.maxcount - sysctl(8) or tunable setting.

-

The statistics array can be retrieved using the - hw.mca.stats sysctl(8) node.

-
-
-

-

The subsystem has a number of configuration options to control the - way events are processed and logged. These options are configured via - sysctl(8) variables or tunables. These settings control - things such as log destination, event limiting, and sampling. These settings - directly impact both the completeness of logs and the performance impact of - processing mca events. A system administrator may - want to review these and modify them to obtain the appropriate behavior in - their environment.

-
-
hw.mca.enabled
-
(Only settable as a tunable.) -

If set to 0, the CPU is not configured to send - mca messages to the kernel.

-

Default is 1 (enabled).

-
-
hw.mca.log_corrected
-
(Settable as a tunable or sysctl.) -

If enabled, corrected messages are logged to console, syslog, - the in-kernel event cache, and the statistics array (subject to separate - configuration controlling those facilities). If disabled, corrected - messages are only logged to the in-kernel event cache (subject to - separate configuration controlling that facility).

-

Default is 1 (enabled).

-
-
hw.mca.intel6h_HSD131
-
(Only settable as a tunable.) -

This setting enables a workaround for benign corrected parity - errors which may be reported by certain Intel desktop Haswell CPUs. (The - name "HSD131" comes from the name of the Intel erratum report - about this issue.)

-

Default is 0 (disabled).

-
-
hw.mca.amd10h_L1TP
-
(Only settable as a tunable.) -

Enable logging of level one TLB parity errors on certain AMD - CPUs. This option has no impact on other CPUs.

-

Default is 1 (enabled).

-
-
hw.mca.erratum383
-
(Only settable as a tunable.) -

This setting enables a workaround for Erratum 383 on AMD - Family 10h CPUs. The erratum changes the way pages are promoted to or - demoted from being super-pages. On affected AMD CPUs, either - hw.mca.amd10h_L1TP or - hw.mca.erratum383 must be on. If both are off, the - system will dynamically enable hw.mca.erratum383 - at boot time.

-

Default is 0 (disabled).

-
-
hw.mca.uselog
-
(Settable as a tunable or sysctl.) -

If enabled, the system will send messages about non-fatal - mca events to syslog and not to the console. If - disabled, the system will send messages about non-fatal - mca events to both syslog and the console. Fatal - events are always logged to the console.

-

Default is false (disabled).

-
-
hw.mca.stats
-
(Read-only sysctl.) -

This returns an array of MCA_T_COUNT - uint64_t values. The enum mca_stat_types - definition in - <x86/mca.h> provides the - value of MCA_T_COUNT and the index values for - various event types.

-
-
hw.mca.log_interval
-
(Settable as a tunable or sysctl.) -

This sets the minimum time (in seconds) between logging - correctible errors. The rate limit is only applied after the system - records a reasonable number of errors of the same type. The goal is to - reduce the impact of the system seeing and attempting to log a burst of - similar errors, which can be expensive (especially when printed to the - console). If this setting is 0, no rate limit is applied.

-

Default is 0 (no rate limit).

-
-
hw.mca.cmc_throttle
-
(Settable as a tunable or sysctl. Only available if - apic(4) support is enabled and the hardware supports CMC - interrupt throttling.) -

This sets the maximum time (in seconds) to throttle CMC - interrupts. In normal operation, the system attempts to receive CMC - interrupts as soon as an event occurs. However, if a high rate of events - occurs in a short time, the system will begin throttling the CMC - interrupts. While the events continue to occur at a high rate, the - system will gradually increase the throttling interval until it reaches - the hw.mca.cmc_throttle setting.

-

Default is 60 seconds.

-
-
hw.mca.count
-
(Read-only sysctl.) -

This returns the current number of mca - records in the in-kernel cache. This can be used to determine how many - records are available to read with the - hw.mca.records sysctl(8) - interface. It can also be used to monitor the amount of memory used by - the in-kernel record cache.

-
-
hw.mca.maxcount
-
(Settable as a tunable or sysctl.) -

This setting controls the size and behavior of the in-kernel - cache of mca records. If the setting is -1, the - in-kernel cache grows without bounds and contains a complete record - events since boot or the last time the - hw.mca.maxcount setting was changed. If the - setting is 0, the in-kernel cache is disabled. If the setting is a - positive integer, the in-kernel cache functions as a ring buffer with - the number of entries defined by the setting.

-

Default is -1 (unlimited).

-
-
hw.mca.interval
-
(Settable as a tunable or sysctl.) -

This setting controls how often (in seconds) the kernel should - proactively scan for new mca events. In many - circumstances, the CPU will send an interrupt to signal new events. - However, there are cases where the periodic scan for events will - discover new events.

-

Default is 300 seconds.

-
-
hw.mca.force_scan
-
(Settable only as a sysctl.) -

Setting this to any non-zero value will force an immediate - scan for mca events. Setting this to zero has no - effect. This is functionally a write-only setting. The current value is - always 0, even when a scan is running.

-

Default is 0 (no scan requested).

-
-
hw.mca.records.n
-
(Read-only sysctl.) -

This is used to copy mca records from - the in-kernel cache to a user space process. The n - value in the sysctl(8) node is an integer index into - the in-kernel cache. (Or, put differently, the "new" value - describes how many records the kernel should skip to find the desired - record.) The return value is a struct mca_record, - which is defined in - <x86/mca.h>.

-
-
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in - /boot/loader.conf. The tunables all have - corresponding sysctl(8) entries. The tunables are listed - above in the SYSCTL VARIABLES - section.

-
-
-

-

mca is only available on x86 systems.

-
-
-

-

loader.conf(5), sysctl(8), - syslogd(8)

-
-
-

-

The mca subsystem was originally written - by John Baldwin - <jhb@FreeBSD.org>.

-

This manual page was written by -
- Jonathan Looney - <jtl@FreeBSD.org>.

-
-
- - - - - -
January 14, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/md.4 3.html b/static/freebsd/man4/md.4 3.html deleted file mode 100644 index bc3401aa..00000000 --- a/static/freebsd/man4/md.4 3.html +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - -
MD(4)Device Drivers ManualMD(4)
-
-
-

-

md — memory - disk

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device md
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
geom_md_load="YES"
-
-
-
-

-

The md driver provides support for four - kinds of memory backed virtual disks:

-
-
-
Backing store is allocated using malloc(9). Only one - malloc-bucket is used, which means that all md - devices with malloc backing must share the - malloc-per-bucket-quota. The exact size of this quota varies, in - particular with the amount of RAM in the system. The exact value can be - determined with vmstat(8).
-
-
A module loaded by loader(8) with type - ‘md_image’ is used for backing store. For backwards - compatibility the type ‘mfs_root’ is also recognized. See - the description of module loading directives in - loader.conf(5) and note that the module name will either - be an absolute path to the image file or the name of a file in the - module_path. -

If the kernel is created with option - MD_ROOT the first preloaded image found will - become the root file system.

-
-
-
A regular file is used as backing store. This allows for mounting ISO - images without the tedious detour over actual physical media.
-
-
Backing store is allocated from buffer memory. Pages get pushed out to the - swap when the system is under memory pressure, otherwise they stay in the - operating memory. Using swap backing is generally - preferable over malloc backing.
-
-

For more information, please see - mdconfig(8).

-
-
-

-

To create a kernel with a ramdisk or MD file system, your kernel - config needs the following options:

-
-
options 	MD_ROOT			# MD is a potential root device
-options 	MD_ROOT_READONLY	# disallow mounting root writeable
-options 	MD_ROOT_SIZE=8192	# 8MB ram disk
-makeoptions	MFS_IMAGE=/h/foo/ARM-MD
-options 	ROOTDEVNAME=\"ufs:md0\"
-
-

The image in /h/foo/ARM-MD will be loaded - as the initial image each boot. To create the image to use, please follow - the steps to create a file-backed disk found in the - mdconfig(8) man page. Other tools will also create these - images, such as NanoBSD.

-
-
-

-

On the armv7 architecture, an MD_ROOT image larger than - approximately 55 MiB may require building a custom kernel using several - tuning options related to kernel memory usage.

-
-
options LOCORE_MAP_MB=<num>
-
This configures how much memory is mapped for the kernel during the early - initialization stages. The value must be at least as large as the kernel - plus all preloaded modules, including the root image. There is no downside - to setting this value too large, as long as it does not exceed the amount - of physical memory. The default is 64 MiB.
-
options NKPT2PG=<num>
-
This configures the number of kernel L2 page table pages to preallocate - during kernel initialization. Each L2 page can map 4 MiB of kernel space. - The value must be large enough to map the kernel plus all preloaded - modules, including the root image. The default value is 32, which is - sufficient to map 128 MiB.
-
options VM_KMEM_SIZE_SCALE=<num>
-
This configures the amount of kernel virtual address (KVA) space to - dedicate to the kmem_arena map. The scale value is the ratio of physical - to virtual pages. The default value of 3 allocates a page of KVA for each - 3 pages of physical ram in the system. The kernel and modules, including - the root image, also consume KVA. The combination of a large root image - and the default scaling may preallocate so much KVA that there is not - enough remaining address space to allocate kernel stacks, IO buffers, and - other resources that are not part of kmem_arena. Overallocating kmem_arena - space is likely to manifest as failure to launch userland processes with - "cannot allocate kernel stack" messages. Setting the scale value - too high may result in kernel failure to allocate memory because - kmem_arena is too small, and the failure may require significant runtime - to manifest. Empirically, a value of 5 works well for a 200 MiB root image - on a system with 2 GiB of physical ram.
-
-
-
-

-

gpart(8), loader(8), - mdconfig(8), mdmfs(8), - newfs(8), vmstat(8)

-
-
-

-

The md driver first appeared in - FreeBSD 4.0 as a cleaner replacement for the MFS - functionality previously used in PicoBSD and in the - FreeBSD installation process.

-

The md driver did a hostile - takeover of the - driver in FreeBSD 5.0.

-
-
-

-

The md driver was written by - Poul-Henning Kamp - <phk@FreeBSD.org>.

-
-
- - - - - -
July 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/mdio.4 4.html b/static/freebsd/man4/mdio.4 4.html deleted file mode 100644 index 8449ed53..00000000 --- a/static/freebsd/man4/mdio.4 4.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
MDIO(4)Device Drivers ManualMDIO(4)
-
-
-

-

mdio — IEEE 802.3 - Management Data Input/Output interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device mdio
-
-
-

-

The mdio driver provides an - interconnection between the Media Access Control (MAC) sublayer and Physical - Layer (PHY) entities' control and status registers, as defined by the IEEE - 802.3 Standard.

-

The mdio layer allows device drivers to - share common support code for various external PHY devices.

-

MDIO is one of two signal interfaces that comprise the Media - Independent Interface (MII) defined by the IEEE 802.3 Standard. The - miibus(4) driver provides support for devices that require - full MII support.

-
-
-

-

miibus(4)

-
-
-

-

More information on MDIO can be found in the IEEE 802.3 - Standard.

-
-
-

-

The mdio driver first appeared in - FreeBSD 10.0.

-
-
-

-

The driver was written by Stefan Bethke - <stb@lassitu.de>.

-
-
- - - - - -
December 17, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/me.4 4.html b/static/freebsd/man4/me.4 4.html deleted file mode 100644 index 85d40ef7..00000000 --- a/static/freebsd/man4/me.4 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
ME(4)Device Drivers ManualME(4)
-
-
-

-

me — encapsulating - network device

-
-
-

-

To compile the driver into the kernel, place the following line in - the kernel configuration file:

-
device me
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_me_load="YES"
-
-
-
-

-

The me network interface is a - point-to-point pseudo device encapsulating datagrams into IP. These - encapsulated datagrams are routed to a destination host, where they are - decapsulated and further routed to their final destination.

-

me interfaces are dynamically created and - destroyed with the ifconfig(8) - create and destroy - subcommands.

-

This driver corresponds to RFC 2004. Datagrams are encapsulated - into IP with a shorter encapsulation. The original IP header is modified and - the modifications are inserted between the so modified header and the - original payload. The protocol number 55 is used for outer header.

-
-
-

-

For correct operation, the me device needs - a route to the decapsulating host that does not run over the tunnel, as this - would be a loop.

-
-
-

-

gif(4), gre(4), - inet(4), ip(4), - netintro(4), protocols(5), - ifconfig(8), sysctl(8)

-
-
-

-

Andrey V. Elsukov - <ae@FreeBSD.org>

-
-
- - - - - -
March 4, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/mem.4 3.html b/static/freebsd/man4/mem.4 3.html deleted file mode 100644 index eec983b3..00000000 --- a/static/freebsd/man4/mem.4 3.html +++ /dev/null @@ -1,270 +0,0 @@ - - - - - - -
MEM(4)Device Drivers ManualMEM(4)
-
-
-

-

mem, kmem — - memory files

-
-
-

-

device mem

-
-
-

-

The special file /dev/mem is an interface - to the physical memory of the computer. Byte offsets in this file are - interpreted as physical memory addresses. Reading and writing this file is - equivalent to reading and writing memory itself. Only offsets within the - bounds of /dev/mem are allowed.

-

Kernel virtual memory is accessed through the interface - /dev/kmem in the same manner as - /dev/mem. Only kernel virtual addresses that are - currently mapped to memory are allowed.

-

On ISA the I/O memory space begins at physical address 0x000a0000 - and runs to 0x00100000. The per-process data size for the current process is - UPAGES long, and ends at virtual address - 0xf0000000.

-
-
-

-
-

-

The MEM_EXTRACT_PADDR ioctl can be used to - look up the physical address and NUMA domain of a given virtual address in - the calling process' address space. The request is described by

-
-
struct mem_extract {
-	uint64_t	me_vaddr;	/* input */
-	uint64_t	me_paddr;	/* output */
-	int		me_domain;	/* output */
-	int		me_state;	/* output */
-};
-
-

The ioctl returns an error if the address is not valid. The - information returned by MEM_EXTRACT_PADDR may be out - of date by the time that the ioctl call returns. Specifically, concurrent - system calls, page faults, or system page reclamation activity may have - unmapped the virtual page or replaced the backing physical page before the - ioctl call returns. Wired pages, e.g., those locked by - mlock(2), will not be reclaimed by the system.

-

The me_state field provides information - about the state of the virtual page:

-
-
-
The virtual address is invalid.
-
-
The virtual address is valid but is not mapped at the time of the ioctl - call.
-
-
The virtual address corresponds to a physical page mapping, and the - me_paddr and me_domain fields - are valid.
-
-
-
-

-

Several architectures allow attributes to be associated with - ranges of physical memory. These attributes can be manipulated via - () - calls performed on /dev/mem. Declarations and data - types are to be found in - <sys/memrange.h>.

-

The specific attributes, and number of programmable ranges may - vary between architectures. The full set of supported attributes is:

-
-
-
The region is not cached.
-
-
Writes to the region may be combined or performed out of order.
-
-
Writes to the region are committed synchronously.
-
-
Writes to the region are committed asynchronously.
-
-
The region cannot be written to.
-
-

Memory ranges are described by

-
-
struct mem_range_desc {
-	uint64_t	mr_base;	/* physical base address */
-	uint64_t	mr_len;		/* physical length of region */
-	int		mr_flags;	/* attributes of region */
-	char		mr_owner[8];
-};
-
-

In addition to the region attributes listed above, the following - flags may also be set in the mr_flags field:

-
-
MDF_FIXBASE
-
The region's base address cannot be changed.
-
MDF_FIXLEN
-
The region's length cannot be changed.
-
MDF_FIRMWARE
-
The region is believed to have been established by the system - firmware.
-
MDF_ACTIVE
-
The region is currently active.
-
MDF_BOGUS
-
We believe the region to be invalid or otherwise erroneous.
-
MDF_FIXACTIVE
-
The region cannot be disabled.
-
MDF_BUSY
-
The region is currently owned by another process and may not be - altered.
-
-

Operations are performed using

-
-
struct mem_range_op {
-	struct mem_range_desc	*mo_desc;
-	int			mo_arg[2];
-};
-
-

The MEMRANGE_GET ioctl is used to retrieve - current memory range attributes. If mo_arg[0] is set - to 0, it will be updated with the total number of memory range descriptors. - If greater than 0, the array at mo_desc will be filled - with a corresponding number of descriptor structures, or the maximum, - whichever is less.

-

The MEMRANGE_SET ioctl is used to add, - alter and remove memory range attributes. A range with the - MDF_FIXACTIVE flag may not be removed; a range with - the MDF_BUSY flag may not be removed or updated.

-

mo_arg[0] should be set to - MEMRANGE_SET_UPDATE to update an existing or - establish a new range, or to MEMRANGE_SET_REMOVE to - remove a range.

-
-
-

-

The MEM_KERNELDUMP ioctl will initiate a - kernel dump against the running system, the contents of which will be - written to a process-owned file descriptor. The resulting dump output will - be in minidump format. The request is described by

-
-
struct mem_livedump_arg {
-	int	fd;		/* input */
-	int	flags		/* input */
-	uint8_t	compression	/* input */
-};
-
-

The fd field is used to pass the file - descriptor.

-

The flags field is currently unused and must - be set to zero.

-

The compression field can be used to specify - the desired compression to be applied to the dump output. The supported - values are defined in - <sys/kerneldump.h>; that is, - KERNELDUMP_COMP_NONE, - KERNELDUMP_COMP_GZIP, or - KERNELDUMP_COMP_ZSTD.

-

Kernel dumps taken against the running system may have - inconsistent kernel data structures due to allocation, deallocation, or - modification of memory concurrent to the dump procedure. Thus, the resulting - core dump is not guaranteed to be usable. A system under load is more likely - to produce an inconsistent result. Despite this, live kernel dumps can be - useful for offline debugging of certain types of kernel bugs, such as - deadlocks, or in inspecting a particular part of the system's state.

-
-
-
-

-
-

-

The MEM_EXTRACT_PADDR ioctl always returns - a value of zero.

-
-
-

-
-
[EOPNOTSUPP]
-
Memory range operations are not supported on this architecture.
-
[ENXIO]
-
No memory range descriptors are available (e.g., firmware has not enabled - any).
-
[EINVAL]
-
The memory range supplied as an argument is invalid or overlaps another - range in a fashion not supported by this architecture.
-
[EBUSY]
-
An attempt to remove or update a range failed because the range is - busy.
-
[ENOSPC]
-
An attempt to create a new range failed due to a shortage of hardware - resources (e.g., descriptor slots).
-
[ENOENT]
-
An attempt to remove a range failed because no range matches the - descriptor base/length supplied.
-
[EPERM]
-
An attempt to remove a range failed because the range is permanently - enabled.
-
-
-
-

-
-
[EOPNOTSUPP]
-
Kernel minidumps are not supported on this architecture.
-
[EPERM]
-
An attempt to begin the kernel dump failed because the calling thread - lacks the
-
[EBADF]
-
The supplied file descriptor was invalid, or does not have write - permission.
-
[EBUSY]
-
An attempt to begin the kernel dump failed because one is already in - progress.
-
[EINVAL]
-
An invalid or unsupported value was specified in - flags.
-
[EINVAL]
-
An invalid or unsupported compression type was specified. - PRIV_KMEM_READ privilege.
-
-
-
-
-

-
-
/dev/mem
-
 
-
/dev/kmem
-
 
-
-
-
-

-

kvm(3), memcontrol(8)

-
-
-

-

The /dev/mem file appeared in - Version 1 AT&T UNIX and - /dev/kmem in Version 5 - AT&T UNIX. The ioctl interface for memory range attributes was - added in FreeBSD 3.2.

-
-
-

-

Busy range attributes are not yet managed correctly.

-

This device is required for all users of kvm(3) - to operate.

-
-
- - - - - -
March 24, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/mfi.4 3.html b/static/freebsd/man4/mfi.4 3.html deleted file mode 100644 index 82a738f6..00000000 --- a/static/freebsd/man4/mfi.4 3.html +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - -
MFI(4)Device Drivers ManualMFI(4)
-
-
-

-

mfi — LSI MegaRAID - SAS driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device mfi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
mfi_load="YES"
-
-
-
-

-

This driver is for LSI's next generation PCI Express SAS RAID - controllers. Access to RAID arrays (logical disks) from this driver is - provided via /dev/mfid? device nodes. A simple - management interface is also provided on a per-controller basis via the - /dev/mfi? device node.

-

The mfi name is derived from the phrase - "MegaRAID Firmware Interface", which is substantially different - than the old "MegaRAID" interface and thus requires a new driver. - Older SCSI and SATA MegaRAID cards are supported by amr(4) - and will not work with this driver.

-

Two sysctls are provided to tune the mfi - driver's behavior when a request is made to remove a mounted volume. By - default the driver will disallow any requests to remove a mounted volume. If - the sysctl dev.mfi.%d.delete_busy_volumes is set to 1, - then the driver will allow mounted volumes to be removed.

-

A tunable is provided to adjust the mfi - driver's behaviour when attaching to a card. By default the driver will - attach to all known cards with high probe priority. If the tunable - hw.mfi.mrsas_enable is set to 1, then the driver will - reduce its probe priority to allow mrsas(4) to attach to - the card instead of mfi.

-

mfi does not provide ATA TRIM support. - Refer to mrsas(4) if TRIM support is required.

-
-
-

-

The mfi driver supports the following - hardware:

-

-
    -
  • LSI MegaRAID SAS 1078
    • -
  • LSI MegaRAID SAS 8408E
    • -
  • LSI MegaRAID SAS 8480E
    • -
  • LSI MegaRAID SAS 9240
    • -
  • LSI MegaRAID SAS 9260
    • -
  • Dell PERC5
    • -
  • Dell PERC6
    • -
  • Fujitsu RAID Controller SAS 6Gbit/s 1GB (D3116)
    • -
  • IBM ServeRAID M1015 SAS/SATA
    • -
  • IBM ServeRAID M1115 SAS/SATA
    • -
  • IBM ServeRAID M5015 SAS/SATA
    • -
  • IBM ServeRAID M5110 SAS/SATA
    • -
  • IBM ServeRAID-MR10i
    • -
  • Intel RAID Controller SRCSAS18E
    • -
  • Intel RAID Controller SROMBSAS18E
    • -
-
-
-

-
-
/dev/mfid?
-
array/logical disk interface
-
/dev/mfi?
-
management interface
-
-
-
-

-
-
mfid%d: Unable to delete busy device
-
An attempt was made to remove a mounted volume.
-
-
-
-

-

amr(4), pci(4), - mfiutil(8)

-
-
-

-

The mfi driver first appeared in - FreeBSD 6.1.

-
-
-

-

The mfi driver and this manual page were - written by Scott Long - <scottl@FreeBSD.org>.

-
-
-

-

The driver does not support big-endian architectures at this - time.

-
-
- - - - - -
April 19, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/mgb.4 4.html b/static/freebsd/man4/mgb.4 4.html deleted file mode 100644 index ec9c3d50..00000000 --- a/static/freebsd/man4/mgb.4 4.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - -
MGB(4)Device Drivers ManualMGB(4)
-
-
-

-

mgb — Microchip - LAN743x PCIe Gigabit Ethernet driver

-
-
-

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_mgb_load="YES"
-
-
-
-

-

The mgb driver is experimental, and has a - number of caveats and limitations. It is currently available only as a - kernel module.

-

The mgb device driver provides support for - PCIe Gigabit Ethernet adapters based on Microchip's LAN7430 and LAN7431.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The mgb driver supports Microchip PCIe - Gigabit Ethernet interfaces, including:

-

-
    -
  • Microchip LAN7430 PCIe Gigabit Ethernet controller with PHY
    • -
  • Microchip LAN7431 PCIe Gigabit Ethernet controller with RGMII - interface
    • -
-
-
-

-

arp(4), miibus(4), - ifconfig(8)

-
-
-

-

The driver does not yet implement support for many hardware - features, including:

-
    -
  • Multiple RX queue support
    • -
  • RX and TX checksum offload
    • -
  • Hardware VLAN tagging or untagging
    • -
  • Multicast receive packet filtering
    • -
  • Wake on LAN (WoL)
    • -
  • LSO
    • -
  • RSS
    • -
-

LAN7431 support is completely untested.

-
-
- - - - - -
September 28, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/miibus.4 3.html b/static/freebsd/man4/miibus.4 3.html deleted file mode 100644 index 8504228e..00000000 --- a/static/freebsd/man4/miibus.4 3.html +++ /dev/null @@ -1,163 +0,0 @@ - - - - - - -
MIIBUS(4)Device Drivers ManualMIIBUS(4)
-
-
-

-

miibus — IEEE - 802.3 Media Independent Interface network bus

-
-
-

-

For most network interface cards (NIC): -
- device miibus

-
-
-

-

The miibus driver provides an - interconnection between the Media Access Control (MAC) sublayer, the - Physical Layer entities (PHY), Station Management (STA) entities, and the - PHY Layer as defined by the IEEE 802.3 Standard.

-

The miibus layer allows network device - drivers to share common support code for various external PHY devices. Most - 10/100 network interface cards either use an MII transceiver or have - built-in transceivers that can be programmed using an MII interface. The - miibus driver currently handles all of the media - detection, selection, and reporting using the ifmedia interface. A generic - driver has been included for all PHYs that are not handled by a specific - driver, this is possible because all 10/100 PHYs implement the same general - register set along with their vendor specific register set.

-

The following network device drivers use the - miibus interface:

-

-
-
ae(4)
-
Attansic/Atheros L2 Fast Ethernet
-
age(4)
-
Attansic/Atheros L1 Gigabit Ethernet
-
alc(4)
-
Atheros AR8131/AR8132 PCIe Ethernet
-
ale(4)
-
Atheros AR8121/AR8113/AR8114 PCIe Ethernet
-
aue(4)
-
ADMtek USB Ethernet
-
axe(4)
-
ASIX Electronics AX88172 USB Ethernet
-
axge(4)
-
ASIX Electronics AX88178A/AX88179 USB Ethernet
-
bce(4)
-
Broadcom NetXtreme II Gigabit Ethernet
-
bfe(4)
-
Broadcom BCM4401 Ethernet
-
bge(4)
-
Broadcom BCM570xx Gigabit Ethernet
-
cas(4)
-
Sun Cassini/Cassini+ and National Semiconductor DP83065 Saturn
-
dc(4)
-
DEC/Intel 21143 and various workalikes
-
ed(4)
-
NE[12]000, SMC Ultra, 3c503, DS8390 cards
-
et(4)
-
Agere ET1310 Gigabit Ethernet
-
fxp(4)
-
Intel EtherExpress PRO/100B
-
gem(4)
-
Sun ERI, Sun GEM and Apple GMAC Ethernet
-
jme(4)
-
JMicron JMC250 Gigabit/JMC260 Fast Ethernet
-
lge(4)
-
Level 1 LXT1001 NetCellerator Gigabit Ethernet
-
msk(4)
-
Marvell/SysKonnect Yukon II Gigabit Ethernet
-
nfe(4)
-
NVIDIA nForce MCP Networking Adapter
-
nge(4)
-
National Semiconductor DP83820/DP83821 Gigabit Ethernet
-
re(4)
-
Realtek 8139C+/8169/8169S/8110S
-
rl(4)
-
Realtek 8129/8139
-
rue(4)
-
Realtek RTL8150 USB To Fast Ethernet
-
sge(4)
-
Silicon Integrated Systems SiS190/191 Ethernet
-
sis(4)
-
Silicon Integrated Systems SiS 900/SiS 7016
-
sk(4)
-
SysKonnect SK-984x and SK-982x Gigabit Ethernet
-
smsc(4)
-
SMSC LAN9xxx USB Fast Ethernet
-
ste(4)
-
Sundance ST201 (D-Link DFE-550TX)
-
stge(4)
-
Sundance/Tamarack TC9021 Gigabit Ethernet
-
udav(4)
-
Davicom DM9601 USB Ethernet
-
ure(4)
-
Realtek RTL8152 USB To Fast Ethernet
-
vge(4)
-
VIA VT612x PCI Gigabit Ethernet
-
vr(4)
-
VIA Rhine, Rhine II
-
vte(4)
-
DM&P Vortex86 RDC R6040 Fast Ethernet
-
xl(4)
-
3Com 3c90x
-
-
-
-

-

The implementation of miibus was - originally intended to have similar API interfaces to - BSD/OS 3.0 and NetBSD, but - as a result are not well behaved newbus device drivers.

-
-
-

-

ae(4), age(4), - alc(4), ale(4), - arp(4), aue(4), - axe(4), axge(4), - bce(4), bfe(4), - bge(4), cas(4), dc(4), - ed(4), et(4), fxp(4), - gem(4), jme(4), - lge(4), msk(4), - netintro(4), nfe(4), - nge(4), re(4), - rgephy(4), rl(4), - rue(4), sge(4), - sis(4), sk(4), - smsc(4), ste(4), - stge(4), udav(4), - ure(4), vge(4), vr(4), - vte(4), xl(4)

-
-
-

-

More information on MII can be found in the IEEE 802.3 - Standard.

-
-
-

-

The miibus driver first appeared in - FreeBSD 3.3.

-
-
-

-

This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/mld.4 3.html b/static/freebsd/man4/mld.4 3.html deleted file mode 100644 index e084e9d0..00000000 --- a/static/freebsd/man4/mld.4 3.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - -
MLD(4)Device Drivers ManualMLD(4)
-
-
-

-

mld — Multicast - Listener Discovery Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet/in_systm.h> -
- #include <netinet/ip6.h> -
- #include <netinet/icmp6.h> -
- #include <netinet6/mld6.h>

-

int -
- socket(AF_INET6, - SOCK_RAW, - IPPROTO_ICMPV6);

-
-
-

-

MLD is a control plane protocol used by IPv6 hosts and routers to - propagate multicast group membership information. Normally this protocol is - not used directly, except by the kernel itself, in response to multicast - membership requests by user applications. Multicast routing protocol daemons - may open a raw socket to directly interact with mld - and receive membership reports.

-

As of FreeBSD 8.0, MLD version 2 is - implemented. This adds support for Source-Specific Multicast (SSM), whereby - applications may communicate to upstream multicast routers that they are - only interested in receiving multicast streams from particular sources. The - retransmission of state-change reports adds some robustness to the - protocol.

-
-
-

-
-
net.inet6.mld.ifinfo
-
This opaque read-only variable exposes the per-link MLDv2 status to - ifmcstat(8).
-
net.inet6.mld.gsrdelay
-
This variable specifies the time threshold, in seconds, for processing - Group-and-Source Specific Queries (GSR). As GSR query processing requires - maintaining state on the host, it may cause memory to be allocated, and is - therefore a potential attack point for Denial-of-Service (DoS). If more - than one GSR query is received within this threshold, it will be dropped, - to mitigate the potential for DoS.
-
net.inet6.mld.v1enable
-
If this variable is non-zero, then MLDv1 membership queries (and host - reports) will be processed by this host, and backwards compatibility will - be enabled until the v1 'Older Version Querier Present' timer expires. - This sysctl is normally enabled by default.
-
-
-
-

-

netstat(1), sourcefilter(3), - icmp6(4), inet(4), - multicast(4), ifmcstat(8)

-
-
-

-

The mld manual page appeared in - FreeBSD 8.0.

-
-
- - - - - -
April 8, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/mlx.4 3.html b/static/freebsd/man4/mlx.4 3.html deleted file mode 100644 index a57ecd58..00000000 --- a/static/freebsd/man4/mlx.4 3.html +++ /dev/null @@ -1,305 +0,0 @@ - - - - - - -
MLX(4)Device Drivers ManualMLX(4)
-
-
-

-

mlx — Mylex - DAC-family Parallel SCSI RAID driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device mlx
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
mlx_load="YES"
-
-
-
-

-

The mlx driver provides support for Mylex - DAC-family PCI to SCSI RAID controllers, including versions relabeled by - Digital/Compaq.

-
-
-

-

The mlx driver supports the following - Parallel SCSI RAID controllers:

-

-
    -
  • Mylex DAC960P (Wide Fast SCSI-2)
    • -
  • Mylex DAC960PD / DEC KZPSC (Wide Fast SCSI-2)
    • -
  • Mylex DAC960PDU (Ultra SCSI-3)
    • -
  • Mylex DAC960PL (Wide Fast SCSI-2)
    • -
  • Mylex DAC960PJ (Wide Ultra SCSI-3)
    • -
  • Mylex DAC960PG (Wide Ultra SCSI-3)
    • -
  • Mylex DAC960PU / DEC PZPAC (Wide Ultra SCSI-3)
    • -
  • Mylex AcceleRAID 150 (DAC960PRL) (Wide Ultra2 SCSI)
    • -
  • Mylex AcceleRAID 250 (DAC960PTL1) (Wide Ultra2 SCSI)
    • -
  • Mylex eXtremeRAID 1100 (DAC1164P) (Wide Ultra2 SCSI)
    • -
  • RAIDarray 230 controllers, aka the Ultra-SCSI DEC KZPAC-AA (1-ch, 4MB - cache), KZPAC-CA (3-ch, 4MB), KZPAC-CB (3-ch, 8MB cache)
    • -
-
-
-

-
-

-
-
mlx%d: controller initialisation in progress...
-
-
mlx%d: initialisation complete
-
-

The controller firmware is performing/has completed - initialisation.

-
-
mlx%d: physical drive %d:%d not responding
-
-

The drive at channel:target is not responding; it may have - failed or been removed.

-
-
mlx%d: spinning up drives...
-
-

Drive startup is in progress; this may take several - minutes.

-
-
mlx%d: configuration checksum error
-
-

The array configuration has become corrupted.

-
-
mlx%d: mirror race recovery in progress
-
-
mlx%d: mirror race on a critical system drive
-
-
mlx%d: mirror race recovery failed
-
-

These error codes are undocumented.

-
-
mlx%d: physical drive %d:%d COD mismatch
-
-

Configuration data on the drive at channel:target does not - match the rest of the array.

-
-
mlx%d: system drive installation aborted
-
-

Errors occurred preventing one or more system drives from - being configured.

-
-
mlx%d: new controller configuration found
-
-

The controller has detected a configuration on disk which - supersedes the configuration in its nonvolatile memory. It will reset - and come up with the new configuration.

-
-
mlx%d: FATAL MEMORY PARITY ERROR
-
-

Firmware detected a fatal memory error; the driver will not - attempt to attach to this controller.

-
-
mlx%d: unknown firmware initialisation error %x:%x:%x
-
-

An unknown error occurred during initialisation; it will be - ignored.

-
-
-
-
-

-
-
mlx%d: can't allocate scatter/gather DMA tag
-
-
mlx%d: can't allocate buffer DMA tag
-
-
mlx%d: can't allocate s/g table
-
-
mlx%d: can't make initial s/g list mapping
-
-
mlx%d: can't make permanent s/g list mapping
-
-
mlx%d: can't allocate interrupt
-
-
mlx%d: can't set up interrupt
-
-

A resource allocation error occurred while initialising the - driver; initialisation has failed and the driver will not attach to this - controller.

-
-
mlx%d: error fetching drive status
-
-

The current status of all system drives could not be fetched; - attachment of system drives will be aborted.

-
-
mlx%d: device_add_child failed
-
-

Creation of the system drive instances failed; attachment of - one or more system drives may have been aborted.

-
-
mlxd%d: detaching...
-
-

The indicated system drive is being detached.

-
-
mlxd%d: still open, can't detach
-
-

The indicated system drive is still open or mounted; the - controller cannot be detached.

-
-
mlx%d: flushing cache...
-
-

The controller cache is being flushed prior to detach or - shutdown.

-
-
-
-
-

-
-
mlx%d: ENQUIRY failed - %s
-
-
mlx%d: ENQUIRY2 failed
-
-
mlx%d: ENQUIRY_OLD failed
-
-
mlx%d: FLUSH failed - %s
-
-
mlx%d: CHECK ASYNC failed - %s
-
-
mlx%d: REBUILD ASYNC failed - %s
-
-
mlx%d: command failed - %s
-
-

The controller rejected a command for the reason given.

-
-
mlx%d: I/O beyond end of unit (%u,%d > %u)
-
-
mlx%d: I/O error - %s
-
-

An I/O error was reported by the controller.

-
-
mlx%d: periodic enquiry failed - %s
-
-

An attempt to poll the controller for status failed for the - reason given.

-
-
mlx%d: mlx_periodic_enquiry: unknown command %x
-
-

The periodic status poll has issued a command which has become - corrupted.

-
-
mlxd%d: drive offline
-
-
mlxd%d: drive online
-
-
mlxd%d: drive critical
-
-

The system disk indicated has changed state.

-
-
mlx%d: physical drive %d:%d reset
-
-
mlx%d: physical drive %d:%d killed %s
-
-
mlx%d: physical drive %d:%d error log: sense = %d asc = %x asq = %x
-
-
mlx%d: info %4D csi %4D
-
-

The drive at channel:target has been reset, killed for the - given reason, or experienced a SCSI error.

-
-
mlx%d: unknown log message type %x
-
-
mlx%d: error reading message log - %s
-
-

An error occurred while trying to read the controller's - message log.

-
-
mlxd%d: consistency check started
-
-
mlx%d: consistency check completed
-
-

A user-initiated consistency check has started/completed.

-
-
mlx%d: drive rebuild started for %d:%d
-
-
mlx%d: drive rebuild completed
-
-

A user-initiated physical drive rebuild has - started/completed.

-
-
mlx%d: background check/rebuild operation started
-
-
mlx%d: background check/rebuild operation completed
-
-

An automatic system drive consistency check or physical drive - rebuild has started/completed.

-
-
mlx%d: channel %d pausing for %d seconds
-
-
mlx%d: channel %d resuming
-
-
mlx%d: pause command failed - %s
-
-
mlx%d: pause failed for channel %d
-
-
mlx%d: resume command failed - %s
-
-
mlx%d: resume failed for channel %d
-
-

Controller/channel pause operation notification. (Channel - pause is not currently supported on any controller.)

-
-
mlx%d: controller wedged (not taking commands)
-
-

The controller is not responding to attempts to submit new - commands.

-
-
mlx%d: duplicate done event for slot %d
-
-
mlx%d: done event for nonbusy slot %d
-
-

Corruption has occurred in either the controller's onboard - list of commands or in the driver.

-
-
-
-
-
-

-

mlxcontrol(8)

-
-
-

-

The mlx driver was written by - Michael Smith - <msmith@FreeBSD.org>.

-

This manual page was written by Jeroen Ruigrok - van der Werven - <asmodai@FreeBSD.org> - and Michael Smith - <msmith@FreeBSD.org>.

-
-
-

-

The DEC KZPSC has insufficient flash ROM to hold any reasonably - recent firmware. This has caused problems for this driver.

-

The driver does not yet support the version 6.x firmware as found - in the AcceleRAID 352 and eXtremeRAID 2000 and 3000 products.

-
-
- - - - - -
May 27, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/mlx4en.4 4.html b/static/freebsd/man4/mlx4en.4 4.html deleted file mode 100644 index ebb21b9c..00000000 --- a/static/freebsd/man4/mlx4en.4 4.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
MLX4EN(4)Device Drivers ManualMLX4EN(4)
-
-
-

-

mlx4en — Mellanox - ConnectX-3 10GbE/40GbE network adapter driver

-
-
-

-

To compile this driver into the kernel, place these lines in your - kernel configuration file:

-
options COMPAT_LINUXKPI -
-device mlx4 -
-device mlx4en
-

To load the driver as a module at run-time, run this command as - root:

-
-
kldload mlx4en
-
-

To load the driver as a module at boot time, place this line in - loader.conf(5):

-
-
mlx4en_load="YES"
-
-
-
-

-

Mellanox ConnectX adapter cards with Virtual Protocol Interconnect - (VPI) provide the highest performing and most flexible interconnect solution - for Enterprise Data Centers, High-Performance Computing, and Embedded - environments. Clustered data bases, parallelized applications, transactional - services and high-performance embedded I/O applications will achieve - significant performance improvements resulting in reduced completion time - and lower cost per operation.

-
-
-

-

The mlx4en driver supports the following - network adapters:

-

-
    -
  • Mellanox ConnectX-2 (ETH)
    • -
  • Mellanox ConnectX-3 (ETH)
    • -
-
-
-

-

For general information and support, go to the Mellanox support - website at: - http://www.mellanox.com/.

-

If an issue is identified with this driver and a supported network - adapter, please email the specific information to - <freebsd-drivers@mellanox.com>.

-
-
-

-

mlx4ib(4), ifconfig(8)

-
-
-

-

The mlx4en device driver first appeared in - FreeBSD 9.0.

-
-
-

-

The mlx4en driver was written by - Mellanox Technologies - <freebsd-drivers@mellanox.com>.

-
-
- - - - - -
March 1, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/mlx4ib.4 3.html b/static/freebsd/man4/mlx4ib.4 3.html deleted file mode 100644 index cd6a27ce..00000000 --- a/static/freebsd/man4/mlx4ib.4 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
MLX4IB(4)Device Drivers ManualMLX4IB(4)
-
-
-

-

mlx4ib — Mellanox - ConnectX-3 10GbE/40GbE network adapter driver

-
-
-

-

To compile this driver into the kernel, place these lines in your - kernel configuration file:

-
options COMPAT_LINUXKPI -
-device mlx4 -
-device mlx4ib
-

To load the driver as a module at run-time, run this command as - root:

-
-
kldload mlx4ib
-
-

To load the driver as a module at boot time, place this line in - loader.conf(5):

-
-
mlx4ib_load="YES"
-
-
-
-

-

Mellanox ConnectX adapter cards with Virtual Protocol Interconnect - (VPI) provide the highest performing and most flexible interconnect solution - for Enterprise Data Centers, High-Performance Computing, and Embedded - environments. Clustered data bases, parallelized applications, transactional - services and high-performance embedded I/O applications will achieve - significant performance improvements resulting in reduced completion time - and lower cost per operation.

-
-
-

-

The mlx4ib driver supports the following - network adapters:

-

-
    -
  • Mellanox ConnectX-2 (IB)
    • -
  • Mellanox ConnectX-3 (IB)
    • -
-
-
-

-

For general information and support, go to the Mellanox support - website at: - http://www.mellanox.com/.

-

If an issue is identified with this driver and a supported network - adapter, please email the specific information to - <freebsd-drivers@mellanox.com>.

-
-
-

-

mlx4en(4), ifconfig(8)

-
-
-

-

The mlx4ib device driver first appeared in - FreeBSD 9.0.

-
-
-

-

The mlx4ib driver was written by - Mellanox Technologies - <freebsd-drivers@mellanox.com>.

-
-
- - - - - -
March 1, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/mlx5en.4 3.html b/static/freebsd/man4/mlx5en.4 3.html deleted file mode 100644 index 0b4b19e5..00000000 --- a/static/freebsd/man4/mlx5en.4 3.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - -
MLX5EN(4)Device Drivers ManualMLX5EN(4)
-
-
-

-

mlx5en — NVIDIA - Mellanox ConnectX-4/5/6 [Dx/Ex/Lx] based 200Gb, 100Gb, 50Gb, 40Gb, 25Gb and - 10Gb ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
options COMPAT_LINUXKPI -
-options RATELIMIT -
-options KERN_TLS -
-device xz -
-device mlxfw -
-device firmware -
-device mlx5 -
-device mlx5en
-

To load the driver as a module at run-time, run the following - command as root:

-
-
kldload mlx5en
-
-

To load the driver as a module at boot time, place the following - lines in loader.conf(5):

-
-
mlx5en_load="YES"
-
-
-
-

-

The mlx5en driver provides support for PCI - Express Ethernet adapters based on ConnectX-4/5/6 [Dx, Ex and Lx variants]. - The driver supports Jumbo Frames, Transmit and Receive checksum offload, TCP - segmentation offload (TSO), Large Receive Offload (LRO), HW Large Receive - Offload (HW LRO), VLAN tag insertion and extraction, VLAN checksum offload, - VLAN TSO, hardware rate limiting (TXRTLMT), stateless VxLAN hardware offload - for receive and transmit, HW TLS offload for transmit, Receive Side Steering - (RSS) and numa(4) awareness.

-

The network interface name is mce<N> - which corresponds to a PCI function, - mlx_core<N>, where - <N> is a number starting at zero. There is at - most one network interface per PCI function.

-

For further information and questions related to hardware - requirements, see https://www.mellanox.com.

-
-
-

-

The mlx5en driver supports 200Gb, 100Gb, - 50Gb, 40Gb, 25Gb and 10Gb ethernet adapters.

-

-
    -
  • ConnectX-6 supports 10/20/25/40/50/56/100Gb/200Gb/s speeds.
    • -
  • ConnectX-5 supports 10/20/25/40/50/56/100Gb/s speeds.
    • -
  • ConnectX-4 supports 10/20/25/40/50/56/100Gb/s speeds.
    • -
  • ConnectX-4 LX supports 10/25/40/50Gb/s speeds and reduced power - consumption.
    • -
-
-
-

-

The mlx5en network interface is configured - using ifconfig(8) and the sysctl(8) tree - at dev.mce.<N>. All configurable entries are - also tunables, and can be put directly into the - loader.conf(5) for persistent configuration.

-
-
-

-

For general information and support, go to the NVIDIA Mellanox - networking support website at: - https://www.mellanox.com.

-

If an issue is identified with this driver using a supported - adapter, e-mail all the specific information related to the issue to - <nbu-freebsd-drivers@nvidia.com>.

-
-
-

-

ifconfig(8)

-
-
-

-

The mlx5en device driver first appeared in - FreeBSD 11.0.

-
-
-

-

The mlx5en driver was written by - NVIDIA Mellanox networking - <nbu-freebsd-drivers@nvidia.com>.

-
-
- - - - - -
July 20, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/mlx5ib.4 3.html b/static/freebsd/man4/mlx5ib.4 3.html deleted file mode 100644 index 79109e60..00000000 --- a/static/freebsd/man4/mlx5ib.4 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
MLX5IB(4)Device Drivers ManualMLX5IB(4)
-
-
-

-

mlx5ib — Mellanox - ConnectX-4 and ConnectX-4 LX based 100Gb, 50Gb, 40Gb, 25Gb and 10Gb network - adapter driver

-
-
-

-

To compile this driver into the kernel, place these lines in your - kernel configuration file:

-
options COMPAT_LINUXKPI -
-device mlx5 -
-device mlx5ib
-

To load the driver as a module at run-time, run this command as - root:

-
-
kldload mlx5ib
-
-

To load the driver as a module at boot time, place this line in - loader.conf(5):

-
-
mlx5ib_load="YES"
-
-
-
-

-

The mlx5ib driver provides support for - infiniband and Remote DMA over Converged Ethernet, RoCE, for PCI Express - network adapters based on ConnectX-4 and ConnectX-4 LX. -
- For further hardware information and questions related to hardware - requirements, see http://www.mellanox.com/.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The mlx5ib driver supports 100Gb, 50Gb, - 40Gb, 25Gb and 10Gb network adapters. ConnectX-4 supports: - 10/20/25/40/50/56/100Gb/s speeds. ConnectX-4 LX supports: 10/25/40/50Gb/s - speeds (and reduced power consumption):

-

-
    -
  • Mellanox MCX455A-ECAT
    • -
  • Mellanox MCX456A-ECAT
    • -
  • Mellanox MCX415A-CCAT
    • -
  • Mellanox MCX416A-CCAT
    • -
  • Mellanox MCX455A-FCAT
    • -
  • Mellanox MCX456A-FCAT
    • -
  • Mellanox MCX415A-BCAT
    • -
  • Mellanox MCX416A-BCAT
    • -
  • Mellanox MCX4131A-GCAT
    • -
  • Mellanox MCX4131A-BCAT
    • -
  • Mellanox MCX4121A-ACAT
    • -
  • Mellanox MCX4111A-ACAT
    • -
  • Mellanox MCX4121A-XCAT
    • -
  • Mellanox MCX4111A-XCAT
    • -
-
-
-

-

For general information and support, go to the Mellanox support - website at: http://www.mellanox.com/.

-

If an issue is identified with this driver with a supported - adapter, email all the specific information related to the issue to - <freebsd-drivers@mellanox.com>.

-
-
-

-

mlx5en(4), ifconfig(8)

-
-
-

-

The mlx5ib device driver first appeared in - FreeBSD 12.0.

-
-
-

-

The mlx5ib driver was written by - Mellanox Technologies - <freebsd-drivers@mellanox.com>.

-
-
- - - - - -
August 23, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/mlx5io.4 3.html b/static/freebsd/man4/mlx5io.4 3.html deleted file mode 100644 index bac13d1c..00000000 --- a/static/freebsd/man4/mlx5io.4 3.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - -
mlx5io(4)Device Drivers Manualmlx5io(4)
-
-
-

-

mlx5io — IOCTL - interface to manage Connect-X 4/5/6 Mellanox network adapters

-
-
-

-

#include - <dev/mlx5/mlx5io.h>

-
-
-

-

The mlx5io interface is provided for - management of the Connect-X4, 5 and 6 network adapters in the aspects not - covered by the generic network configuration, mostly related to the PCIe - attachment and internal card working. Interface consists of the commands, - which are passed by means of ioctl(2) on the file - descriptor, opened from the /dev/mlx5ctl device - node.

-

The following commands are implemented:

-
-
-
Take the snapshot of the firmware registers state and store it in the - kernel buffer. The buffer must be empty, in other words, no dumps should - be written so far, or existing dump cleared with the - MLX5_FWDUMP_RESET command for the specified - device. The argument for the command should point to the - struct mlx5_tool_addr structure, containing the PCIe - bus address of the device. -
- 
struct mlx5_tool_addr {
-	uint32_t domain;
-	uint8_t bus;
-	uint8_t slot;
-	uint8_t func;
-};
-
-
-
-
Clear the stored firmware dump, preparing the kernel buffer for the next - dump. The argument for the command should point to the - struct mlx5_tool_addr structure, containing the PCIe - bus address of the device.
-
-
Fetch the stored firmware dump into the user memory. The argument to the - command should point to the input/output struct - mlx5_fwdump_get structure. Its devaddr field - specifies the address of the device, the buf - fields points to the array of struct mlx5_fwdump_reg - of records of the registers values, the size of the array is specified in - the reg_cnt field. -
- 
struct mlx5_fwdump_get {
-	struct mlx5_tool_addr devaddr;
-	struct mlx5_fwdump_reg *buf;
-	size_t reg_cnt;
-	size_t reg_filled; /* out */
-};
-
-

On successful return, the reg_filled - field reports the number of the buf array - elements actually filled with the registers values. If - buf contains the NULL - pointer, no registers are filled, but reg_filled - still contains the number of registers that should be passed for the - complete dump.

-

The struct mlx5_fwdump_reg element - contains the address of the register in the field - addr, and its value in the field - val.

-
- 
struct mlx5_fwdump_reg {
-	uint32_t addr;
-	uint32_t val;
-};
-
-
-
-
Requests firmware update (flash) on the adapter specified by the - devaddr using the firmware image in - MFA2 format. The argument for the ioctl command is - the struct mlx5_fw_update with the following - definition. -
- 
struct mlx5_fw_update {
-	struct mlx5_tool_addr devaddr;
-	void *img_fw_data;
-	size_t img_fw_data_len;
-};
-
- Image address in memory is passed in img_fw_data, - the length of the image is specified in - img_fw_data_len field.
-
-
Requests PCIe link-level reset on the device. The address of the device is - specified by the struct mlx5_tool_addr structure, - which should be passed as an argument.
-
-
Fetch EEPROM information. The argument to the command should point to the - input/output struct mlx5_eeprom_get structure where, - the devaddr field specifies the address of the - device. -
- 
struct mlx5_eeprom_get {
-        struct mlx5_tool_addr devaddr;
-        size_t eeprom_info_page_valid;
-        uint32_t *eeprom_info_buf;
-        size_t eeprom_info_out_len;
-};
-
-

On successful return, the - eeprom_info_out_len field reports the length of - the EEPROM information. eeprom_info_buf field - contains the actual EEPROM information. - eeprom_info_page_valid field reports the third - page validity.

-
-
-
-
-

-

The /dev/mlx5ctl - devfs(4) node is used to pass commands to the driver.

-
-
-

-

If successful, the IOCTL returns zero. Otherwise, -1 is returned - and the global variable errno is set to indicate the - error.

-
-
-

-

errno(2), ioctl(2), - mlx5en(4), mlx5ib(4), - mlx5tool(8) and pci(9).

-
-
- - - - - -
October 2, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/mmc.4 4.html b/static/freebsd/man4/mmc.4 4.html deleted file mode 100644 index 1bbaee9c..00000000 --- a/static/freebsd/man4/mmc.4 4.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - -
MMC(4)Device Drivers ManualMMC(4)
-
-
-

-

mmc — - MultiMediaCard and SD Card bus driver

-
-
-

-

device mmc

-
-
-

-

The mmc driver implements the MMC and SD - Card bus. The mmc driver supports all MMC and SD - bridges in the system. All SD or MMC cards in the system attach to an - instance of mmc. The mmc bus - typically has only one slot, and only memory cards. MultiMediaCards exist - only in memory. SD Cards exist as memory, I/O, or combination cards.

-
-
-

-

mmcsd(4), sdhci(4)

-

SD Specifications, Part 1, - Physical Layer, Simplified Specification.

-

The MultiMediaCard System - Specification.

-
-
-

-

SDIO cards currently do not work.

-
-
- - - - - -
June 10, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/mmcsd.4 4.html b/static/freebsd/man4/mmcsd.4 4.html deleted file mode 100644 index 4d216e43..00000000 --- a/static/freebsd/man4/mmcsd.4 4.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - -
MMCSD(4)Device Drivers ManualMMCSD(4)
-
-
-

-

mmcsd — MMC and SD - memory card driver

-
-
-

-

device mmcsd

-
-
-

-

The mmcsd driver implements direct access - block device for MMC and SD memory cards.

-
-
-

-

mmc(4), sdhci(4)

-

SD Specifications, Part 1, - Physical Layer, Simplified Specification.

-

The MultiMediaCard System - Specification.

-
-
-

-

The mmcsd driver appeared in - FreeBSD 7.0.

-
-
- - - - - -
October 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/mod_cc.4 3.html b/static/freebsd/man4/mod_cc.4 3.html deleted file mode 100644 index 86d19cdf..00000000 --- a/static/freebsd/man4/mod_cc.4 3.html +++ /dev/null @@ -1,182 +0,0 @@ - - - - - - -
MOD_CC(4)Device Drivers ManualMOD_CC(4)
-
-
-

-

mod_cc — Modular - congestion control

-
-
-

-

The modular congestion control framework allows the TCP - implementation to dynamically change the congestion control algorithm used - by new and existing connections. Algorithms are identified by a unique - ascii(7) name. Algorithm modules can be compiled into the - kernel or loaded as kernel modules using the kld(4) - facility.

-

The default algorithm is CUBIC, and all connections use the - default unless explicitly overridden using the - TCP_CONGESTION socket option (see - tcp(4) for details). The default can be changed using a - sysctl(3) MIB variable detailed in the - MIB Variables section below.

-

Algorithm specific parameters can be set or queried using the - TCP_CCALGOOPT socket option (see - tcp(4) for details). Callers must pass a pointer to an - algorithm specific data, and specify its size.

-

Unloading a congestion control module will fail if it is used as a - default by any Vnet. When unloading a module, the Vnet default is used to - switch a connection to an alternate congestion control. Note that the new - congestion control module may fail to initialize its internal memory, if so - it will fail the module unload. If this occurs often times retrying the - unload will succeed since the temporary memory shortage as the new CC module - malloc's memory, that prevented the switch is often transient.

-
-
-

-

The framework exposes the following variables in the - net.inet.tcp.cc branch of the - sysctl(3) MIB:

-
-
available
-
Read-only list of currently available congestion control algorithms by - name.
-
algorithm
-
Returns the current default congestion control algorithm when read, and - changes the default when set. When attempting to change the default - algorithm, this variable should be set to one of the names listed by the - net.inet.tcp.cc.available MIB variable.
-
abe
-
Enable support for RFC 8511, which alters the window decrease factor - applied to the congestion window in response to an ECN congestion signal. - Refer to individual congestion control man pages to determine if they - implement support for ABE and for configuration details.
-
abe_frlossreduce
-
If non-zero, apply standard beta instead of ABE-beta during ECN-signalled - congestion recovery episodes if loss also needs to be repaired.
-
hystartplusplus.bblogs
-
This boolean controls if black box logging will be done for hystart++ - events. If set to zero (the default) no logging is performed. If set to - one then black box logs will be generated on all hystart++ events.
-
hystartplusplus.css_rounds
-
This value controls the number of rounds that CSS runs for. The default - value matches the current internet-draft of 5.
-
hystartplusplus.css_growth_div
-
This value controls the divisor applied to slowstart during CSS. The - default value matches the current internet-draft of 4.
-
hystartplusplus.n_rttsamples
-
This value controls how many rtt samples must be collected in each round - for hystart++ to be active. The default value matches the current - internet-draft of 8.
-
hystartplusplus.maxrtt_thresh
-
This value controls the maximum rtt variance clamp when considering if CSS - is needed. The default value matches the current internet-draft of 16000 - (in microseconds). For further explanation please see the - internet-draft.
-
hystartplusplus.minrtt_thresh
-
This value controls the minimum rtt variance clamp when considering if CSS - is needed. The default value matches the current internet-draft of 4000 - (in microseconds). For further explanation please see the - internet-draft.
-
-

Each congestion control module may also expose other MIB variables - to control their behaviour. Note that both NewReno and CUBIC now support - Hystart++ based on the version 3 of the internet-draft.

-
-
-

-

All of the available congestion control modules may also be loaded - via kernel configuration options. A kernel configuration is required to have - at least one congestion control algorithm built into it via kernel option - and a system default specified. Compilation of the kernel will fail if these - two conditions are not met.

-
-
-

-

The framework exposes the following kernel configuration - options.

-
-
CC_NEWRENO
-
This directive loads the NewReno congestion control algorithm.
-
CC_CUBIC
-
This directive loads the CUBIC congestion control algorithm and is - included in GENERIC by default.
-
CC_VEGAS
-
This directive loads the vegas congestion control algorithm, note that - this algorithm also requires the TCP_HHOOK option as well.
-
CC_CDG
-
This directive loads the cdg congestion control algorithm, note that this - algorithm also requires the TCP_HHOOK option as well.
-
CC_DCTCP
-
This directive loads the dctcp congestion control algorithm.
-
CC_HD
-
This directive loads the hd congestion control algorithm, note that this - algorithm also requires the TCP_HHOOK option as well.
-
CC_CHD
-
This directive loads the chd congestion control algorithm, note that this - algorithm also requires the TCP_HHOOK option as well.
-
CC_HTCP
-
This directive loads the htcp congestion control algorithm.
-
CC_DEFAULT
-
This directive specifies the string that represents the name of the system - default algorithm, the GENERIC kernel defaults this to CUBIC.
-
-
-
-

-

cc_cdg(4), cc_chd(4), - cc_cubic(4), cc_dctcp(4), - cc_hd(4), cc_htcp(4), - cc_newreno(4), cc_vegas(4), - tcp(4), config(5), - config(8), mod_cc(9)

-
-
-

-

Development and testing of this software were made possible in - part by grants from the FreeBSD Foundation and Cisco University Research - Program Fund at Community Foundation Silicon Valley.

-
-
-

-

The mod_cc modular congestion control - framework first appeared in FreeBSD 9.0.

-

The framework was first released in 2007 by James Healy and - Lawrence Stewart whilst working on the NewTCP research project at Swinburne - University of Technology's Centre for Advanced Internet Architectures, - Melbourne, Australia, which was made possible in part by a grant from the - Cisco University Research Program Fund at Community Foundation Silicon - Valley. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-
-
-

-

The mod_cc facility was written by - Lawrence Stewart - <lstewart@FreeBSD.org>, - James Healy - <jimmy@deefa.com> and - David Hayes - <david.hayes@ieee.org>.

-

This manual page was written by David - Hayes - <david.hayes@ieee.org> - and Lawrence Stewart - <lstewart@FreeBSD.org>.

-
-
- - - - - -
September 13, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/mos.4 3.html b/static/freebsd/man4/mos.4 3.html deleted file mode 100644 index 7468c6bf..00000000 --- a/static/freebsd/man4/mos.4 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
MOS(4)Device Drivers ManualMOS(4)
-
-
-

-

mos — Moschip - MCS7730/MCS7830/MCS7832 USB Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device ehci -
-device usb -
-device miibus -
-device uether -
-device mos
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_mos_load="YES"
-
-
-
-

-

The mos driver provides support for USB - Ethernet adapters based on the Moschip MCS7730/MCS7830/MCS7832 chipset.

-

The adapters that contain the Moschip MCS7730/MCS7830/MCS7832 - chipset will operate at 100Base-TX and full-duplex.

-

The Moschip contains a 10/100 Ethernet MAC with MII interface and - is designed to work with both Ethernet and HomePNA transceivers. Although - designed to interface with 100Mbps peripherals, this only works with USB - 2.0. The existing USB 1.0 standard specifies a maximum transfer speed of - 12Mbps. USB 1.0 Users should therefore not expect to actually achieve - 100Mbps speeds with these devices.

-

The Moschip supports a 64-bit multicast hash table, single perfect - filter entry for the station address and promiscuous mode. Packets are - received and transmitted over separate USB bulk transfer endpoints.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

Adapters supported by the mos driver - include:

-

-
    -
  • Sitecom LN030
    • -
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), ifconfig(8)

-

ADMtek AN986 data sheet, - http://www.moschip.com/data/products/MCS7830/Data%20Sheet_7830.pdf.

-
-
-

-

The mos device driver first appeared in - FreeBSD 8.2.

-
-
-

-

The mos driver was written by - Rick van der Zwet info@rickvanderzwet.nl.

-
-
- - - - - -
November 24, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mouse.4 3.html b/static/freebsd/man4/mouse.4 3.html deleted file mode 100644 index e1da5124..00000000 --- a/static/freebsd/man4/mouse.4 3.html +++ /dev/null @@ -1,292 +0,0 @@ - - - - - - -
MOUSE(4)Device Drivers ManualMOUSE(4)
-
-
-

-

mouse — mouse and - pointing device drivers

-
-
-

-

#include - <sys/mouse.h>

-
-
-

-

The mouse drivers psm(4), - ums(4) and sysmouse(4) provide user - programs with movement and button state information of the mouse. Currently - there are specific device drivers for bus, InPort, PS/2, and USB mice. The - serial mouse is not directly supported by a dedicated driver, but it is - accessible via the serial device driver or via moused(8) - and sysmouse(4).

-

The user program simply opens a mouse device with a - open(2) call and reads mouse data from the device via - read(2). Movement and button states are usually encoded in - fixed-length data packets. Some mouse devices may send data in variable - length of packets. Actual protocol (data format) used by each driver differs - widely.

-

The mouse drivers may have ``non-blocking'' attribute which will - make the driver return immediately if mouse data is not available.

-

Mouse device drivers often offer several levels of operation. The - current operation level can be examined and changed via - ioctl(2) commands. The level zero is the lowest level at - which the driver offers the basic service to user programs. Most drivers - provide horizontal and vertical movement of the mouse and state of up to - three buttons at this level. At the level one, if supported by the driver, - mouse data is encoded in the standard format - MOUSE_PROTO_SYSMOUSE as follows:

-

-
-
Byte 1
-
-
-
bit 7
-
Always one.
-
bit 6..3
-
Always zero.
-
bit 2
-
Left button status; cleared if pressed, otherwise set.
-
bit 1
-
Middle button status; cleared if pressed, otherwise set. Always one, - if the device does not have the middle button.
-
bit 0
-
Right button status; cleared if pressed, otherwise set.
-
-
-
Byte 2
-
The first half of horizontal movement count in two's complement; -128 - through 127.
-
Byte 3
-
The first half of vertical movement count in two's complement; -128 - through 127.
-
Byte 4
-
The second half of the horizontal movement count in two's complement; -128 - through 127. To obtain the full horizontal movement count, add the byte 2 - and 4.
-
Byte 5
-
The second half of the vertical movement count in two's complement; -128 - through 127. To obtain the full vertical movement count, add the byte 3 - and 5.
-
Byte 6
-
The bit 7 is always zero. The lower 7 bits encode the first half of Z axis - movement count in two's complement; -64 through 63.
-
Byte 7
-
The bit 7 is always zero. The lower 7 bits encode the second half of the Z - axis movement count in two's complement; -64 through 63. To obtain the - full Z axis movement count, add the byte 6 and 7.
-
Byte 8
-
The bit 7 is always zero. The bits 0 through 6 reflect the state of the - buttons 4 through 10. If a button is pressed, the corresponding bit is - cleared. Otherwise the bit is set.
-
-

The first 5 bytes of this format is compatible with the - MouseSystems format. The additional 3 bytes have their MSBs always set to - zero. Thus, if the user program can interpret the MouseSystems data format - and tries to find the first byte of the format by detecting the bit pattern - 10000xxxb, it will discard the additional bytes, thus, be able to decode x, - y and states of 3 buttons correctly.

-

Device drivers may offer operation levels higher than one. Refer - to manual pages of individual drivers for details.

-
-
-

-

The following ioctl(2) commands are defined for - the mouse drivers. The degree of support varies from one driver to another. - This section gives general description of the commands. Refer to manual - pages of individual drivers for specific details.

-

-
-
- int *level
-
 
-
- int *level
-
These commands manipulate the operation level of the mouse driver. -

-
-
- mousehw_t *hw
-
Returns the hardware information of the attached device in the following - Except for the iftype field, the device driver may - not always fill the structure with correct values. Consult manual pages of - individual drivers for details of support. -
- 
typedef struct mousehw {
-    int buttons;    /* number of buttons */
-    int iftype;     /* I/F type */
-    int type;       /* mouse/track ball/pad... */
-    int model;      /* I/F dependent model ID */
-    int hwid;       /* I/F dependent hardware ID */
-} mousehw_t;
-
-

The buttons field holds the number of - buttons detected by the driver. The driver may put an arbitrary value, - such as two, in this field, if it cannot determine the exact number.

-

The iftype is the type of interface: - MOUSE_IF_SERIAL, - MOUSE_IF_BUS, - MOUSE_IF_INPORT, - MOUSE_IF_PS2, - MOUSE_IF_USB, - MOUSE_IF_SYSMOUSE or - MOUSE_IF_UNKNOWN.

-

The type tells the device type: - MOUSE_MOUSE, - MOUSE_TRACKBALL, - MOUSE_STICK, MOUSE_PAD, - or MOUSE_UNKNOWN.

-

The model may be - MOUSE_MODEL_GENERIC or one of - MOUSE_MODEL_XXX constants.

-

The hwid is the ID value returned by - the pointing device. It depend on the interface type; refer to the - manual page of specific mouse drivers for possible values.

-

-
-
- mousemode_t *mode
-
The command reports the current operation parameters of the mouse driver. -
- 
typedef struct mousemode {
-    int protocol;    /* MOUSE_PROTO_XXX */
-    int rate;        /* report rate (per sec) */
-    int resolution;  /* MOUSE_RES_XXX, -1 if unknown */
-    int accelfactor; /* acceleration factor */
-    int level;       /* driver operation level */
-    int packetsize;  /* the length of the data packet */
-    unsigned char syncmask[2]; /* sync. bits */
-} mousemode_t;
-
-

The protocol field tells the format in - which the device status is returned when the mouse data is read by the - user program. It is one of MOUSE_PROTO_XXX - constants.

-

The rate field is the status report - rate (reports/sec) at which the device will send movement reports to the - host computer. -1 if unknown or not applicable.

-

The resolution field holds a value - specifying resolution of the pointing device. It is a positive value or - one of MOUSE_RES_XXX constants.

-

The accelfactor field holds a value to - control acceleration feature. It must be zero or greater. If it is zero, - acceleration is disabled.

-

The packetsize field tells the length - of the fixed-size data packet or the length of the fixed part of the - variable-length packet. The size depends on the interface type, the - device type and model, the protocol and the operation level of the - driver.

-

The array syncmask holds a bit mask - and pattern to detect the first byte of the data packet. - syncmask[0] is the bit mask to be ANDed with a - byte. If the result is equal to syncmask[1], the - byte is likely to be the first byte of the data packet. Note that this - method of detecting the first byte is not 100% reliable, thus, should be - taken only as an advisory measure.

-

-
-
- mousemode_t *mode
-
The command changes the current operation parameters of the mouse driver - as specified in mode. Only - rate, resolution, - level and accelfactor may - be modifiable. Setting values in the other field does not generate error - and has no effect. -

If you do not want to change the current setting of a field, - put -1 there. You may also put zero in - resolution and rate, and - the default value for the fields will be selected.

-

-
-
- mousedata_t *data
-
The command reads the raw data from the device. -
- 
typedef struct mousedata {
-    int len;        /* # of data in the buffer */
-    int buf[16];    /* data buffer */
-} mousedata_t;
-
-

The calling process must fill the len - field with the number of bytes to be read into the buffer. This command - may not be supported by all drivers.

-

-
-
- mousedata_t *state
-
The command reads the raw state data from the device. It uses the same - structure as above. This command may not be supported by all drivers. -

-
-
- mousestatus_t *status
-
The command returns the current state of buttons and movement counts in - the following structure. -
- 
typedef struct mousestatus {
-    int flags;      /* state change flags */
-    int button;     /* button status */
-    int obutton;    /* previous button status */
-    int dx;         /* x movement */
-    int dy;         /* y movement */
-    int dz;         /* z movement */
-} mousestatus_t;
-
-

The button and - obutton fields hold the current and the previous - state of the mouse buttons. When a button is pressed, the corresponding - bit is set. The mouse drivers may support up to 31 buttons with the bit - 0 through 31. Few button bits are defined as - MOUSE_BUTTON1DOWN through - MOUSE_BUTTON8DOWN. The first three buttons - correspond to left, middle and right buttons.

-

If the state of the button has changed since the last - MOUSE_GETSTATUS call, the corresponding bit in - the flags field will be set. If the mouse has - moved since the last call, the MOUSE_POSCHANGED - bit in the flags field will also be set.

-

The other fields hold movement counts since the last - MOUSE_GETSTATUS call. The internal counters will - be reset after every call to this command.

-
-
-
-
-

-
-
/dev/cuau%d
-
serial ports
-
/dev/psm%d
-
PS/2 mouse device
-
/dev/sysmouse
-
virtual mouse device
-
/dev/ums%d
-
USB mouse device
-
-
-
-

-

ioctl(2), psm(4), - sysmouse(4), ums(4), - moused(8)

-
-
-

-

This manual page was written by Kazutaka - Yokota - <yokota@FreeBSD.org>.

-
-
- - - - - -
December 3, 1997FreeBSD 15.0
diff --git a/static/freebsd/man4/mpi3mr.4 3.html b/static/freebsd/man4/mpi3mr.4 3.html deleted file mode 100644 index 0845c900..00000000 --- a/static/freebsd/man4/mpi3mr.4 3.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
MPI3MR(4)Device Drivers ManualMPI3MR(4)
-
-
-

-

mpi3mr — Broadcom - MPIMR 3.0 IT/IR 24Gb/s SAS Tri-Mode RAID PCIe 4.0 driver

-
-
-

-

The driver can be loaded as a module at boot time by placing this - line in loader.conf(5):

-
-
mpi3mr_load="YES"
-
-
-
-

-

The mpi3mr driver provides support for - Broadcom Ltd. MPIMR 3.0 IT/IR PCIe 4 controller.

-
-
-

-

These controllers are supported by the - mpi3mr driver:

-

-
    -
  • Broadcom Ltd. SAS 4116 Tri-Mode RAID Adapter
    • -
  • Broadcom Ltd. 9670W-16i 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9670-24i 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9660-16i 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9620-16i 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9600-24i 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9600-16i 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9600W-16e 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9600-16e 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
  • Broadcom Ltd. 9600-8i8e 24G PCIe 4.0 Tri-Mode RAID Adapters
    • -
-
-
-

-

cam(4), cd(4), - ch(4), da(4), mpr(4), - pci(4), sa(4), - scsi(4)

-
-
-

-

The mpi3mr driver first appeared in - FreeBSD 14.0.

-
-
-

-

The mpi3mr driver was written by - Sumit Saxena - <sumit.saxena@broadcom.com>, - and -
- Chandrakanth Patil - <chandrakanth.patil@broadcom.com>. - This manual page was written by -
- Warner Losh - <imp@FreeBSD.org>.

-
-
- - - - - -
June 14, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/mpr.4 3.html b/static/freebsd/man4/mpr.4 3.html deleted file mode 100644 index b545c3ae..00000000 --- a/static/freebsd/man4/mpr.4 3.html +++ /dev/null @@ -1,351 +0,0 @@ - - - - - - -
MPR(4)Device Drivers ManualMPR(4)
-
-
-

-

mpr — LSI - Fusion-MPT 3/3.5 IT/IR 12Gb/s Serial Attached SCSI/SATA/PCIe - driver

-
-
-

-

To compile this driver into the kernel, place these lines in the - kernel configuration file:

-
device pci -
-device scbus -
-device mpr
-

The driver can be loaded as a module at boot time by placing this - line in loader.conf(5):

-
-
mpr_load="YES"
-
-
-
-

-

The mpr driver provides support for - Broadcom Ltd./Avago Tech (LSI) Fusion-MPT 3/3.5 IT/IR SAS/PCIe - controllers.

-
-
-

-

The mpr driver supports the following - SATA/SAS/NVMe RAID controllers:

-

-
    -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3004 (4 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3008 (8 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3108 (8 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3216 (16 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3224 (24 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3316 (16 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3324 (24 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3408 (8 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3416 (16 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3508 (8 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3516 (16 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3616 (16 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3708 (8 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3716 (16 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3808 (8 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3816 (16 Port SAS/PCIe)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 3916 (16 Port SAS/PCIe)
    • -
-
-
-

-

In all tunable descriptions below, X represents the adapter - number.

-

To disable MSI interrupts for all mpr - driver instances, set this tunable value in - loader.conf(5):

-
-
hw.mpr.disable_msi=1
-
-

To disable MSI interrupts for a specific - mpr driver instance, set this tunable value in - loader.conf(5):

-
-
dev.mpr.X.disable_msi=1
-
-

To disable MSI-X interrupts for all mpr - driver instances, set this tunable value in - loader.conf(5):

-
-
hw.mpr.disable_msix=1
-
-

To disable MSI-X interrupts for a specific - mpr driver instance, set this tunable value in - loader.conf(5):

-
-
dev.mpr.X.disable_msix=1
-
-

To set the maximum number of DMA chains allocated for all - adapters, set this tunable in loader.conf(5):

-
-
hw.mpr.max_chains=NNNN
-
-

To set the maximum number of DMA chains allocated for a specific - adapter, set this tunable in loader.conf(5):

-
-
dev.mpr.X.max_chains=NNNN
-
-

The default max_chains value is 16384.

-

The current number of free chain frames is stored in the - dev.mpr.X.chain_free sysctl(8) variable.

-

The lowest number of free chain frames seen since boot is stored - in the dev.mpr.X.chain_free_lowwater sysctl(8) - variable.

-

The number of times that chain frame allocations have failed since - boot is stored in the dev.mpr.X.chain_alloc_fail sysctl(8) - variable. This can be used to determine whether the max_chains tunable - should be increased to help performance.

-

The current number of active I/O commands is shown in the - dev.mpr.X.io_cmds_active sysctl(8) variable.

-

The current number of free PRP pages is stored in the - dev.mpr.X.prp_pages_free sysctl(8) variable. PRP pages are - used by NVMe devices for I/O transfers, much like Scatter/Gather lists.

-

The lowest number of free PRP pages seen since boot is stored in - the dev.mpr.X.prp_pages_free_lowwater sysctl(8) - variable.

-

The number of times that PRP page allocations have failed since - boot is stored in the dev.mpr.X.prp_page_alloc_fail - sysctl(8) variable.

-

To set the maximum number of pages that will be used per I/O for - all adapters, set this tunable in loader.conf(5):

-
-
hw.mpr.max_io_pages=NNNN
-
-

To set the maximum number of pages that will be used per I/O for a - specific adapter, set this tunable in loader.conf(5):

-
-
dev.mpr.X.max_io_pages=NNNN
-
-

The default max_io_pages value is -1, meaning that the maximum I/O - size that will be used per I/O will be calculated using the IOCFacts values - stored in the controller. The lowest value that the driver will use for - max_io_pages is 1, otherwise IOCFacts will be used to calculate the maximum - I/O size. The smaller I/O size calculated from either max_io_pages or - IOCFacts will be the maximum I/O size used by the driver.

-

The highest number of active I/O commands seen since boot is - stored in the dev.mpr.X.io_cmds_highwater sysctl(8) - variable.

-

Devices can be excluded from mpr control - for all adapters by setting this tunable in - loader.conf(5):

-
-
hw.mpr.exclude_ids=Y
-
-

Y represents the target ID of the device. If more than one device - is to be excluded, target IDs are separated by commas.

-

Devices can be excluded from mpr control - for a specific adapter by setting this tunable in - loader.conf(5):

-
-
dev.mpr.X.exclude_ids=Y
-
-

Y represents the target ID of the device. If more than one device - is to be excluded, target IDs are separated by commas.

-

The adapter can issue the - - SCSI command to SATA direct-access devices during shutdown. This allows the - device to quiesce powering down. To control this feature for all adapters, - set the

-
-
hw.mpr.enable_ssu
-
-

tunable in loader.conf(5) to one of these - values:

-
-
-
0
-
Do not send SSU to either HDDs or SSDs.
-
1
-
Send SSU to SSDs, but not to HDDs. This is the default value.
-
2
-
Send SSU to HDDs, but not to SSDs.
-
3
-
Send SSU to both HDDs and SSDs.
-
-
-

To control this feature for a specific adapter, set this tunable - value in loader.conf(5):

-
-
dev.mpr.X.enable_ssu
-
-

The same set of values are valid as when setting this tunable for - all adapters.

-

SATA disks that take several seconds to spin up and fail the SATA - Identify command might not be discovered by the driver. This problem can - sometimes be overcome by increasing the value of the spinup wait time in - loader.conf(5) with the

-
-
hw.mpr.spinup_wait_time=NNNN
-
-

tunable. NNNN represents the number of seconds to wait for SATA - devices to spin up when the device fails the initial SATA Identify - command.

-

Spinup wait times can be set for specific adapters in - loader.conf(5): with the

-
-
dev.mpr.X.spinup_wait_time=NNNN
-
-

tunable. NNNN is the number of seconds to wait for SATA devices to - spin up when they fail the initial SATA Identify command.

-

The driver can map devices discovered by the adapter so that - target IDs corresponding to a specific device persist across resets and - reboots. In some cases it is possible for devices to lose their mapped IDs - due to unexpected behavior from certain hardware, such as some types of - enclosures. To overcome this problem, a tunable is provided that will force - the driver to map devices using the Phy number associated with the device. - This feature is not recommended if the topology includes multiple - enclosures/expanders. If multiple enclosures/expanders are present in the - topology, Phy numbers are repeated, causing all devices at these Phy numbers - except the first device to fail enumeration. To control this feature for all - adapters, set the

-
-
hw.mpr.use_phy_num
-
-

tunable in loader.conf(5) to one of these - values:

-
-
-
-1
-
Only use Phy numbers to map devices and bypass the driver's mapping - logic.
-
0
-
Never use Phy numbers to map devices.
-
1
-
Use Phy numbers to map devices, but only if the driver's mapping logic - fails to map the device that is being enumerated. This is the default - value.
-
-
-

To control this feature for a specific adapter, set this tunable - value in loader.conf(5):

-
-
dev.mpr.X.use_phy_num
-
-

The same set of values are valid as when setting this tunable for - all adapters.

-
-
-

-

Driver diagnostic printing is controlled in - loader.conf(5) by using the global - hw.mpr.debug_level and per-device - dev.mpr.X.debug_level tunables. One can alter the - debug level for any adapter at run-time using the - sysctl(8) variable - dev.mpr.X.debug_level.

-

All debug_level variables can be named by - either an integer value or a text string. Multiple values can be specified - together by either ORing the integer values or by providing a - comma-separated list of names. A text string prefixed by "+" adds - the specified debug levels to the existing set, while the prefix - "-" removes them from the existing set. The current - debug_level status is reported in both formats for - convenience. The following levels are available:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x0001infoBasic information (enabled by default)
0x0002faultDriver faults (enabled by default)
0x0004eventController events
0x0008logLogging data from controller
0x0010recoveryTracing of recovery operations
0x0020errorParameter errors and programming bugs
0x0040initSystem initialization operations
0x0080xinfoMore detailed information
0x0100userTracing of user-generated commands (IOCTL)
0x0200mappingTracing of device mapping
0x0400traceTracing through driver functions
-
-
-

-

cam(4), cd(4), - ch(4), da(4), mps(4), - mpt(4), pci(4), sa(4), - scsi(4), targ(4), - loader.conf(5), mprutil(8), - sysctl(8)

-
-
-

-

The mpr driver first appeared in - FreeBSD 9.3.

-
-
-

-

The mpr driver was originally written by - Scott Long - <scottl@FreeBSD.org>. - It has been improved and tested by LSI Corporation, Avago Technologies - (formerly LSI), and Broadcom Ltd. (formerly Avago).

-

This manual page was written by Ken Merry - <ken@FreeBSD.org> with - additional input from Stephen McConnell - <slm@FreeBSD.org>.

-
-
- - - - - -
September 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/mps.4 3.html b/static/freebsd/man4/mps.4 3.html deleted file mode 100644 index 504ec660..00000000 --- a/static/freebsd/man4/mps.4 3.html +++ /dev/null @@ -1,335 +0,0 @@ - - - - - - -
MPS(4)Device Drivers ManualMPS(4)
-
-
-

-

mps — LSI - Fusion-MPT 2 IT/IR 6Gb/s Serial Attached SCSI/SATA driver

-
-
-

-

To compile this driver into the kernel, place these lines in the - kernel configuration file:

-
device pci -
-device scbus -
-device mps
-

The driver can be loaded as a module at boot time by placing this - line in loader.conf(5):

-
-
mps_load="YES"
-
-
-
-

-

The mps driver provides support for - Broadcom Ltd./Avago Tech (LSI) Fusion-MPT 2 IT/IR SAS controllers and - WarpDrive solid state storage cards.

-
-
-

-

These controllers are supported by the mps - driver:

-

-
    -
  • Broadcom Ltd./Avago Tech (LSI) SAS 2004 (4 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 2008 (8 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 2108 (8 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 2116 (16 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 2208 (8 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SAS 2308 (8 Port SAS)
    • -
  • Broadcom Ltd./Avago Tech (LSI) SSS6200 Solid State Storage
    • -
  • Intel Integrated RAID Module RMS25JB040
    • -
  • Intel Integrated RAID Module RMS25JB080
    • -
  • Intel Integrated RAID Module RMS25KB040
    • -
  • Intel Integrated RAID Module RMS25KB080
    • -
-
-
-

-

In all tunable descriptions below, X represents the adapter - number.

-

To disable MSI interrupts for all mps - driver instances, set this tunable value in - loader.conf(5):

-
-
hw.mps.disable_msi=1
-
-

To disable MSI interrupts for a specific - mps driver instance, set this tunable value in - loader.conf(5):

-
-
dev.mps.X.disable_msi=1
-
-

To disable MSI-X interrupts for all mps - driver instances, set this tunable value in - loader.conf(5):

-
-
hw.mps.disable_msix=1
-
-

To disable MSI-X interrupts for a specific - mps driver instance, set this tunable value in - loader.conf(5):

-
-
dev.mps.X.disable_msix=1
-
-

To set the maximum number of DMA chains allocated for all - adapters, set this tunable in loader.conf(5):

-
-
hw.mps.max_chains=NNNN
-
-

To set the maximum number of DMA chains allocated for a specific - adapter, set this tunable in loader.conf(5):

-
-
dev.mps.X.max_chains=NNNN
-
-

The default max_chains value is 16384.

-

The current number of free chain frames is stored in the - dev.mps.X.chain_free sysctl(8) variable.

-

The lowest number of free chain frames seen since boot is stored - in the dev.mps.X.chain_free_lowwater sysctl(8) - variable.

-

The number of times that chain frame allocations have failed since - boot is stored in the dev.mps.X.chain_alloc_fail sysctl(8) - variable. This can be used to determine whether the max_chains tunable - should be increased to help performance.

-

The current number of active I/O commands is shown in the - dev.mps.X.io_cmds_active sysctl(8) variable.

-

To set the maximum number of pages that will be used per I/O for - all adapters, set this tunable in loader.conf(5):

-
-
hw.mps.max_io_pages=NNNN
-
-

To set the maximum number of pages that will be used per I/O for a - specific adapter, set this tunable in loader.conf(5):

-
-
dev.mps.X.max_io_pages=NNNN
-
-

The default max_io_pages value is -1, meaning that the maximum I/O - size that will be used per I/O will be calculated using the IOCFacts values - stored in the controller. The lowest value that the driver will use for - max_io_pages is 1, otherwise IOCFacts will be used to calculate the maximum - I/O size. The smaller I/O size calculated from either max_io_pages or - IOCFacts will be the maximum I/O size used by the driver.

-

The highest number of active I/O commands seen since boot is - stored in the dev.mps.X.io_cmds_highwater sysctl(8) - variable.

-

Devices can be excluded from mps control - for all adapters by setting this tunable in - loader.conf(5):

-
-
hw.mps.exclude_ids=Y
-
-

Y represents the target ID of the device. If more than one device - is to be excluded, target IDs are separated by commas.

-

Devices can be excluded from mps control - for a specific adapter by setting this tunable in - loader.conf(5):

-
-
dev.mps.X.exclude_ids=Y
-
-

Y represents the target ID of the device. If more than one device - is to be excluded, target IDs are separated by commas.

-

The adapter can issue the - - SCSI command to SATA direct-access devices during shutdown. This allows the - device to quiesce powering down. To control this feature for all adapters, - set the

-
-
hw.mps.enable_ssu
-
-

tunable in loader.conf(5) to one of these - values:

-
-
-
0
-
Do not send SSU to either HDDs or SSDs.
-
1
-
Send SSU to SSDs, but not to HDDs. This is the default value.
-
2
-
Send SSU to HDDs, but not to SSDs.
-
3
-
Send SSU to both HDDs and SSDs.
-
-
-

To control this feature for a specific adapter, set this tunable - value in loader.conf(5):

-
-
dev.mps.X.enable_ssu
-
-

The same set of values are valid as when setting this tunable for - all adapters.

-

SATA disks that take several seconds to spin up and fail the SATA - Identify command might not be discovered by the driver. This problem can - sometimes be overcome by increasing the value of the spinup wait time in - loader.conf(5) with the

-
-
hw.mps.spinup_wait_time=NNNN
-
-

tunable. NNNN represents the number of seconds to wait for SATA - devices to spin up when the device fails the initial SATA Identify - command.

-

Spinup wait times can be set for specific adapters in - loader.conf(5): with the

-
-
dev.mps.X.spinup_wait_time=NNNN
-
-

tunable. NNNN is the number of seconds to wait for SATA devices to - spin up when they fail the initial SATA Identify command.

-

The driver can map devices discovered by the adapter so that - target IDs corresponding to a specific device persist across resets and - reboots. In some cases it is possible for devices to lose their mapped IDs - due to unexpected behavior from certain hardware, such as some types of - enclosures. To overcome this problem, a tunable is provided that will force - the driver to map devices using the Phy number associated with the device. - This feature is not recommended if the topology includes multiple - enclosures/expanders. If multiple enclosures/expanders are present in the - topology, Phy numbers are repeated, causing all devices at these Phy numbers - except the first device to fail enumeration. To control this feature for all - adapters, set the

-
-
hw.mps.use_phy_num
-
-

tunable in loader.conf(5) to one of these - values:

-
-
-
-1
-
Only use Phy numbers to map devices and bypass the driver's mapping - logic.
-
0
-
Never use Phy numbers to map devices.
-
1
-
Use Phy numbers to map devices, but only if the driver's mapping logic - fails to map the device that is being enumerated. This is the default - value.
-
-
-

To control this feature for a specific adapter, set this tunable - value in loader.conf(5):

-
-
dev.mps.X.use_phy_num
-
-

The same set of values are valid as when setting this tunable for - all adapters.

-
-
-

-

Driver diagnostic printing is controlled in - loader.conf(5) by using the global - hw.mps.debug_level and per-device - dev.mps.X.debug_level tunables. One can alter the - debug level for any adapter at run-time using the - sysctl(8) variable - dev.mps.X.debug_level.

-

All debug_level variables can be named by - either an integer value or a text string. Multiple values can be specified - together by either ORing the integer values or by providing a - comma-separated list of names. A text string prefixed by "+" adds - the specified debug levels to the existing set, while the prefix - "-" removes them from the existing set. The current - debug_level status is reported in both formats for - convenience. The following levels are available:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x0001infoBasic information (enabled by default)
0x0002faultDriver faults (enabled by default)
0x0004eventController events
0x0008logLogging data from controller
0x0010recoveryTracing of recovery operations
0x0020errorParameter errors and programming bugs
0x0040initSystem initialization operations
0x0080xinfoMore detailed information
0x0100userTracing of user-generated commands (IOCTL)
0x0200mappingTracing of device mapping
0x0400traceTracing through driver functions
-
-
-

-

cam(4), cd(4), - ch(4), da(4), mpr(4), - mpt(4), pci(4), sa(4), - scsi(4), targ(4), - loader.conf(5), mpsutil(8), - sysctl(8)

-
-
-

-

The mps driver first appeared in - FreeBSD 9.0.

-
-
-

-

The mps driver was originally written by - Scott Long - <scottl@FreeBSD.org>. - It has been improved and tested by LSI Corporation, Avago Technologies - (formerly LSI), and Broadcom Ltd. (formerly Avago).

-

This manual page was written by Ken Merry - <ken@FreeBSD.org> with - additional input from Stephen McConnell - <slm@FreeBSD.org>.

-
-
- - - - - -
June 1, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/mpt.4 3.html b/static/freebsd/man4/mpt.4 3.html deleted file mode 100644 index f97e36c9..00000000 --- a/static/freebsd/man4/mpt.4 3.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - -
MPT(4)Device Drivers ManualMPT(4)
-
-
-

-

mpt — LSI - Fusion-MPT SCSI/Fibre Channel driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device mpt
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
mpt_load="YES"
-
-
-
-

-

The mpt driver provides support for the - LSI Logic Fusion-MPT family of SCSI, Fibre Channel and SAS controllers.

-
-
-

-

The following controllers are supported by the - mpt driver:

-

-
    -
  • LSI Logic 53c1030, LSI Logic LSI2x320-X (Single and Dual Ultra320 - SCSI)
    • -
  • LSI Logic AS1064, LSI Logic AS1068 (SAS/SATA)
    • -
  • LSI Logic FC909 (1Gb/s Fibre Channel)
    • -
  • LSI Logic FC909A (Dual 1Gb/s Fibre Channel)
    • -
  • LSI Logic FC919, LSI Logic 7102XP-LC (Single 2Gb/s Fibre Channel)
    • -
  • LSI Logic FC929, LSI Logic FC929X, LSI Logic 7202XP-LC (Dual 2Gb/s Fibre - Channel)
    • -
  • LSI Logic FC949X (Dual 4Gb/s Fibre Channel)
    • -
  • LSI Logic FC949E, LSI Logic FC949ES (Dual 4Gb/s Fibre Channel - PCI-Express)
    • -
-

The Ultra 320 SCSI controller chips supported by the - mpt driver can be found onboard on many systems - including:

-

-
    -
  • Dell PowerEdge 1750 through 2850
    • -
  • IBM eServer xSeries 335
    • -
-

These systems also contain Integrated RAID Mirroring and - Integrated RAID Mirroring Enhanced which this driver also supports.

-

The SAS controller chips are also present on many new AMD/Opteron - based systems, like the Sun 4100. Note that this controller can drive both - SAS and SATA drives or a mix of them at the same time. The Integrated RAID - Mirroring available for these controllers is poorly supported at best.

-

The Fibre Channel controller chipset are supported by a broad - variety of speeds and systems. The Apple Fibre Channel HBA is in fact the - FC949ES card.

-

This driver also supports target mode for Fibre Channel cards. - This support may be enabled by setting the desired role of the core via the - LSI Logic firmware utility that establishes what roles the card can take on - - no separate compilation is required.

-
-
-

-

Most controllers supported by the mpt - driver suffer from limitations on supported disk size (mostly <2TB). - While most controllers will truncate usable disk size, others might behave - unexpectedly and can cause severe data loss. Refer to the datasheet of the - chipset and firmware version for information about supported disk size and - limitations.

-
-
-

-

cd(4), ch(4), - da(4), mps(4), pci(4), - sa(4), scsi(4), - targ(4), gmultipath(8), - mptutil(8)

-

LSI Logic Website, - http://www.lsi.com/.

-
-
-

-

The mpt driver first appeared in - FreeBSD 4.6.

-
-
-

-

The mpt driver was originally written for - FreeBSD by Greg Ansley and - marginally improved upon by Matt Jacob - <mjacob@FreeBSD.org>.

-

Justin Gibbs - <gibbs@FreeBSD.org> - and Scott Long - <scottl@FreeBSD.org> - have made more substantial improvements.

-
-
- - - - - -
January 16, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/mqueuefs.4 3.html b/static/freebsd/man4/mqueuefs.4 3.html deleted file mode 100644 index 458fb4be..00000000 --- a/static/freebsd/man4/mqueuefs.4 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
MQUEUEFS(4)Device Drivers ManualMQUEUEFS(4)
-
-
-

-

mqueuefs — POSIX - message queue file system

-
-
-

-

To link into kernel:

-

-
- options P1003_1B_MQUEUE

-

To load as a kernel loadable module:

-

-
kldload mqueuefs
-
-
-

-

The mqueuefs module will permit the - FreeBSD kernel to support POSIX message queue. The - module contains system calls to manipulate POSIX message queues. It also - contains a file system to implement a view for all message queues of the - system. This helps users to keep track of their message queues and make it - more easily usable without having to invent additional tools.

-

The most common usage is as follows:

-

-
mount -t mqueuefs null - /mnt/mqueue
-

where /mnt/mqueue is a mount point.

-

It is possible to define an entry in - /etc/fstab that looks similar to:

-
-
null	/mnt/mqueue	mqueuefs	rw	0	0
-
-

This will mount mqueuefs at the - /mnt/mqueue mount point during system boot. Using - /mnt/mqueue as a permanent mount point is not - advised as its intention has always been to be a temporary mount point. See - hier(7) for more information on - FreeBSD directory layout.

-

Some common tools can be used on the file system, e.g.: - cat(1), chmod(1), - chown(8), ls(1), - rm(1), etc. To use only the message queue system calls, it - is not necessary for user to mount the file system, just load the module or - compile it into the kernel. Manually creating a file, for example, - “touch /mnt/mqueue/myqueue”, will - create a message queue named myqueue in the kernel, - default message queue attributes will be applied to the queue. It is not - advised to use this method to create a queue; it is better to use the - mq_open(2) system call to create a queue as it allows the - user to specify different attributes.

-

To see the queue's attributes, just read the file:

-

-
cat /mnt/mqueue/myqueue
-
-
-

-

mq_open(2), nmount(2), - unmount(2), mount(8), - umount(8)

-
-
-

-

This manual page was written by David Xu - <davidxu@FreeBSD.org>.

-
-
- - - - - -
November 30, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/mrsas.4 3.html b/static/freebsd/man4/mrsas.4 3.html deleted file mode 100644 index 18eca667..00000000 --- a/static/freebsd/man4/mrsas.4 3.html +++ /dev/null @@ -1,365 +0,0 @@ - - - - - - -
MRSAS(4)Device Drivers ManualMRSAS(4)
-
-
-

-

mrsas — - Broadcom/LSI MegaRAID 6/12Gb/s SAS+SATA RAID controller - driver

-
-
-

-

device pci -
- device mrsas

-

In loader.conf(5): -
- mrsas_load="YES"

-

In sysctl.conf(5): -
- dev.mrsas.X.disable_ocr -
- dev.mrsas.X.fw_outstanding -
- dev.mrsas.X.mrsas_fw_fault_check_delay -
- dev.mrsas.X.mrsas_io_timeout -
- hw.mrsas.X.debug_level

-
-
-

-

The mrsas driver will detect - Broadcom/LSI's 6Gb/s and 12Gb/s PCI Express SAS/SATA/NVMe RAID controllers. - A disk (virtual disk/physical disk) attached to the - mrsas driver will be visible to the user through - camcontrol(8) as /dev/da? device - nodes. A simple management interface is also provided per-controller via the - /dev/mrsas? device node.

-

The mrsas name is derived from the phrase - "MegaRAID SAS HBA", which is substantially different than the old - "MegaRAID" Driver mfi(4) which does not connect - targets to the cam(4) layer and thus requires a new driver - which attaches targets to the cam(4) layer. Older MegaRAID - controllers are supported by mfi(4) and will not work with - mrsas, but both the mfi(4) and - mrsas drivers can detect and manage the Broadcom/LSI - MegaRAID SAS 2208/2308/3008/3108 series of controllers.

-

The device.hints(5) option is provided to tune - the mrsas driver's behavior for LSI MegaRAID SAS - 2208/2308/3008/3108 controllers. By default, the mfi(4) - driver will detect these controllers. See the - PRIORITY section to know more about - driver priority for MR-Fusion devices.

-

mrsas will provide a priority of (-30) - (between BUS_PROBE_DEFAULT and - BUS_PROBE_LOW_PRIORITY) at probe call for device - id's 0x005B, 0x005D, and 0x005F so that mrsas does - not take control of these devices without user intervention.

-

Solid-state drives (SSD) get ATA TRIM support with - mrsas if underlying adapter allows it. This may - require configuring SSD as Non-RAID drive rather then JBOD virtual mode.

-
-
-

-

The mrsas driver supports the following - LSI/Broadcom SATA/SAS RAID controllers:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ControllerChipSpeed
Broadcom SAS3916Aero12Gb/s
Broadcom SAS3908Aero12Gb/s
LSI MegaRAID SAS 9380Invader/Fury12Gb/s
LSI MegaRAID SAS 9361Invader/Fury12Gb/s
LSI MegaRAID SAS 9341Invader/Fury12Gb/s
LSI MegaRAID SAS 9286Thunderbolt6Gb/s
LSI MegaRAID SAS 9285Thunderbolt6Gb/s
LSI MegaRAID SAS 9272Thunderbolt6Gb/s
LSI MegaRAID SAS 9271Thunderbolt6Gb/s
LSI MegaRAID SAS 9270Thunderbolt6Gb/s
LSI MegaRAID SAS 9267Thunderbolt6Gb/s
LSI MegaRAID SAS 9266Thunderbolt6Gb/s
LSI MegaRAID SAS 9265Thunderbolt6Gb/s
LSI SAS 310812Gb/s
LSI SAS 300812Gb/s
LSI SAS 23086Gb/s
LSI SAS 22086Gb/s
DELL PERC H830Invader/Fury12Gb/s
DELL PERC H810Thunderbolt6Gb/s
DELL PERC H730/PInvader/Fury12Gb/s
DELL PERC H710/PThunderbolt6Gb/s
DELL PERC H330Invader/Fury12Gb/s
Fujitsu D3116Thunderbolt6Gb/s
-
-
-

-

To disable Online Controller Reset(OCR) for a specific - mrsas driver instance, set the following tunable - value in loader.conf(5):

-

-
dev.mrsas.X.disable_ocr=1
-

where X is the adapter number.

-

To change the I/O timeout value for a specific - mrsas driver instance, set the following tunable - value in loader.conf(5):

-

-
dev.mrsas.X.mrsas_io_timeout=NNNNNN
-

where NNNNNN is the timeout value in milli-seconds.

-

To change the firmware fault check timer value for a specific - mrsas driver instance, set the following tunable - value in loader.conf(5):

-

-
dev.mrsas.X.mrsas_fw_fault_check_delay=NN
-

where NN is the fault check delay value in seconds.

-

The current number of active I/O commands is shown in the - dev.mrsas.X.fw_outstanding sysctl(8) - variable.

-
-
-

-

To enable debugging prints from the mrsas - driver, set the hw.mrsas.X.debug_level variable, where - X is the adapter number, either in loader.conf(5) or via - sysctl(8). The following bits have the described - effects:

-
-
-
0x01
-
Enable informational prints.
-
0x02
-
Enable tracing prints.
-
0x04
-
Enable prints for driver faults.
-
0x08
-
Enable prints for OCR and I/O timeout.
-
0x10
-
Enable prints for AEN events.
-
-
-
-
-

-

The mrsas driver will always set a default - (-30) priority in the PCI subsystem for selection of MR-Fusion cards. (It is - between BUS_PROBE_DEFAULT and - BUS_PROBE_LOW_PRIORITY). MR-Fusion Controllers - include all cards with the Device IDs - 0x005B, 0x005D, 0x005F.

-

The mfi(4) driver will set a priority of either - BUS_PROBE_DEFAULT or - BUS_PROBE_LOW_PRIORITY (depending on the - device.hints setting) in the PCI subsystem for selection of MR-Fusion cards. - With the above design in place, the mfi(4) driver will - attach to a MR-Fusion card given that it has a higher priority than - mrsas.

-

Using /boot/device.hints (as mentioned - below), the user can provide a preference for the - mrsas driver to detect a MR-Fusion card instead of - the mfi(4) driver.

-
hw.mfi.mrsas_enable="1"
-

At boot time, the mfi(4) driver will get - priority to detect MR-Fusion controllers by default. Before changing this - default driver selection policy, LSI advises users to understand how the - driver selection policy works. LSI's policy is to provide priority to the - mfi(4) driver to detect MR-Fusion cards, but allow for the - ability to choose the mrsas driver to detect - MR-Fusion cards.

-

LSI recommends setting - hw.mfi.mrsas_enable="0" for customers who - are using the older mfi(4) driver and do not want to - switch to mrsas. For those using a MR-Fusion - controller for the first time, LSI recommends using the - mrsas driver and setting - hw.mfi.mrsas_enable="1".

-

Changing the default behavior is well tested under most - conditions, but unexpected behavior may pop up if more complex and - unrealistic operations are executed by switching between the - mfi(4) and mrsas drivers for - MR-Fusion. Switching drivers is designed to happen only one time. Although - multiple switching is possible, it is not recommended. The user should - decide from - which driver they want to use for the MR-Fusion card.

-

The user may see different device names when switching - from mfi(4) to mrsas. This - behavior and the user needs to change the fstab(5) - entry manually if they are doing any experiments with - mfi(4) and mrsas - interoperability.

-
-
-

-
-
/dev/da?
-
array/logical disk interface
-
/dev/mrsas?
-
management interface
-
-
-
-

-

cam(4), mfi(4), - pci(4), device.hints(5), - camcontrol(8)

-
-
-

-

The mrsas driver first appeared in - FreeBSD 10.1.

-
mfi Driver: mfi(4) - is the old FreeBSD driver which started with support - for Gen-1 Controllers and was extended to support up to MR-Fusion (Device ID = - 0x005B, 0x005D, 0x005F).
-
mrsas Driver: - mrsas is the new driver reworked by LSI which supports - Thunderbolt and onward products. The SAS+SATA RAID controller with device id - 0x005B is referred to as the Thunderbolt controller throughout this man - page.
-
FreeBSD has a - cam(4) layer which attaches storage devices and provides a - common access mechanism to storage controllers and attached devices. The - mrsas driver is cam(4) aware and - devices associated with mrsas can be seen using - camcontrol(8). The mfi(4) driver does not - understand the cam(4) layer and it directly associates - storage disks to the block layer. -

This is the 6Gb/s MegaRAID HBA card which has device id - 0x005B.

-

This is 12Gb/s MegaRAID HBA card which has device id - 0x005D.

-

This is the 12Gb/s MegaRAID HBA card which has device id - 0x005F.

-
-
-
-

-

The mrsas driver and this manual page were - written by Kashyap Desai - <Kashyap.Desai@lsi.com>.

-
-
-

-

The mrsas driver exposes devices as - /dev/da?, whereas mfi(4) exposes - devices as /dev/mfid?.

-

mrsas does not support the Linux Emulator - Interface, mfiutil(8), or device name aliases for - switching drivers without editing fstab(5).

-
-
- - - - - -
January 6, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/msdosfs.4 3.html b/static/freebsd/man4/msdosfs.4 3.html deleted file mode 100644 index 1ea9f53c..00000000 --- a/static/freebsd/man4/msdosfs.4 3.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
MSDOSFS(4)Device Drivers ManualMSDOSFS(4)
-
-
-

-

msdosfs — MS-DOS - (FAT) file system

-
-
-

-

options MSDOSFS

-
-
-

-

The msdosfs driver will permit the - FreeBSD kernel to read and write MS-DOS based file - systems.

-

The most common usage follows:

-

-
mount -t msdosfs /dev/ada0sN - /mnt
-

where N is the partition number and - /mnt is a mount point. Some users tend to create a - /dos directory for msdosfs - mount points. This helps to keep better track of the file system, and make - it more easily accessible.

-

It is possible to define an entry in - /etc/fstab that looks similar to:

-
-
/dev/ada0sN		/dos	msdosfs		rw	0	0
-
-

This will mount an MS-DOS based partition at the - /dos mount point during system boot. Using - /mnt as a permanent mount point is not advised as - its intention has always been to be a temporary mount point for floppy and - ZIP disks. See hier(7) for more information on - FreeBSD directory layout.

-
-
-

-

Determine which FAT file system version (e.g, FAT16, FAT32) is a - partition formatted with:

-
-
file -s /dev/da0s1
-
-

gpart(8) may also be used to extract this - information.

-
-
-

-

mount(2), unmount(2), - fsck_msdosfs(8), mount(8), - mount_msdosfs(8), newfs_msdos(8), - umount(8)

-
-
-

-

This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
September 27, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/msk.4 3.html b/static/freebsd/man4/msk.4 3.html deleted file mode 100644 index 84b5f9ee..00000000 --- a/static/freebsd/man4/msk.4 3.html +++ /dev/null @@ -1,177 +0,0 @@ - - - - - - -
MSK(4)Device Drivers ManualMSK(4)
-
-
-

-

msk — - Marvell/SysKonnect Yukon II Gigabit Ethernet adapter - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device msk
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_msk_load="YES"
-
-
-
-

-

The msk device driver provides support for - various NICs based on the Marvell/SysKonnect Yukon II Gigabit Ethernet - controller chip.

-

All NICs supported by the msk driver have - TCP/UDP/IP checksum offload for transmit, TCP segmentation offload (TSO), - hardware VLAN tag stripping/insertion features and an interrupt moderation - mechanism as well as a 64-bit multicast hash filter. The Yukon II supports - TBI (ten bit interface) and GMII transceivers, which means it can be used - with either copper or 1000baseX fiber applications.

-

The Yukon II also supports Jumbo Frames (up to 9022 bytes), which - can be configured via the interface MTU setting. Selecting an MTU larger - than 1500 bytes with the ifconfig(8) utility configures - the adapter to receive and transmit Jumbo Frames.

-

The msk driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX operation over twisted pair. The - ifconfig(8) mediaopt option can - also be used to select either full-duplex or - half-duplex modes.
-
-
Set 1000Mbps (Gigabit Ethernet) operation. Both - full-duplex and - half-duplex modes are supported.
-
-

The msk driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The msk driver provides support for - various NICs based on the Marvell/SysKonnect Yukon II based Gigabit Ethernet - controller chips, including:

-

-
    -
  • D-Link 550SX Gigabit Ethernet
    • -
  • D-Link 560SX Gigabit Ethernet
    • -
  • D-Link 560T Gigabit Ethernet
    • -
  • Marvell Yukon 88E8021CU Gigabit Ethernet
    • -
  • Marvell Yukon 88E8021 SX/LX Gigabit Ethernet
    • -
  • Marvell Yukon 88E8022CU Gigabit Ethernet
    • -
  • Marvell Yukon 88E8022 SX/LX Gigabit Ethernet
    • -
  • Marvell Yukon 88E8061CU Gigabit Ethernet
    • -
  • Marvell Yukon 88E8061 SX/LX Gigabit Ethernet
    • -
  • Marvell Yukon 88E8062CU Gigabit Ethernet
    • -
  • Marvell Yukon 88E8062 SX/LX Gigabit Ethernet
    • -
  • Marvell Yukon 88E8035 Fast Ethernet
    • -
  • Marvell Yukon 88E8036 Fast Ethernet
    • -
  • Marvell Yukon 88E8038 Fast Ethernet
    • -
  • Marvell Yukon 88E8039 Fast Ethernet
    • -
  • Marvell Yukon 88E8040 Fast Ethernet
    • -
  • Marvell Yukon 88E8040T Fast Ethernet
    • -
  • Marvell Yukon 88E8042 Fast Ethernet
    • -
  • Marvell Yukon 88E8048 Fast Ethernet
    • -
  • Marvell Yukon 88E8050 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8052 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8053 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8055 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8056 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8057 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8058 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8059 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8070 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8071 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8072 Gigabit Ethernet
    • -
  • Marvell Yukon 88E8075 Gigabit Ethernet
    • -
  • SysKonnect SK-9Sxx Gigabit Ethernet
    • -
  • SysKonnect SK-9Exx Gigabit Ethernet
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.msk.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.mskc.%d.int_holdoff
-
Maximum number of time to delay interrupts. The valid range is 0 to - 34359738 for 125MHz clock in units of 1us, the default is 100 (100us). The - interface need to be brought down and up again before a change takes - effect.
-
dev.mskc.%d.process_limit
-
Maximum amount of Rx events to be processed in the event loop before - rescheduling a taskqueue. The accepted range is 30 to 256, the default - value is 128 events. The interface does not need to be brought down and up - again before a change takes effect.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The msk driver was written by - Pyun YongHyeon - <yongari@FreeBSD.org> - and it is based on sk(4) and Marvell's - FreeBSD driver. It first appeared in - FreeBSD 7.0 and FreeBSD - 6.3.

-
-
- - - - - -
May 23, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/mt7915.4 3.html b/static/freebsd/man4/mt7915.4 3.html deleted file mode 100644 index 068c1a03..00000000 --- a/static/freebsd/man4/mt7915.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
MT7915(4)Device Drivers ManualMT7915(4)
-
-
-

-

mt7915 — MediaTek - IEEE 802.11ax wireless network driver

-
-
-

-

The driver will auto-load without any user interaction using - devmatch(8) if enabled in - rc.conf(5).

-

Only if auto-loading is explicitly disabled, place the following - lines in rc.conf(5) to manually load the driver as a - module at boot time:

-
-
kld_list="${kld_list} if_mt7915"
-
-

The driver should automatically load any firmware needed for the - particular chipset.

-

It is discouraged to load the driver from - loader(8).

-
-
-

-

The mt7915 driver provides support for - MediaTek MT7915E wireless network devices. mt7915 is - derived from MediaTek's Linux mt76 driver.

-

This driver requires firmware to be loaded before it will work. - The package wifi-firmware-mt76-kmod from the - ports/net/wifi-firmware-mt76-kmod port needs to be - installed before the driver is loaded. Otherwise no - wlan(4) interface can be created using - ifconfig(8). One can use fwget(8) to - install the correct firmware package.

-

The driver uses the - - and - - compat framework to bridge between the Linux and native - FreeBSD driver code as well as to the native - net80211(4) wireless stack.

-
-
-

-

The mt7915 driver supports PCIe devices - with the following chipsets:

-

-
    -
  • MediaTek MT7915E
    • -
-
-
-

-

wlan(4), networking(7), - fwget(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The mt7915 driver first appeared in - FreeBSD 14.0.

-
-
-

-

Certainly.

-

While mt7915 supports 802.11a/b/g/n/ac/ax - modes, the compatibility code currently only supports 802.11a/b/g modes. - Support for 802.11n/ac/ax is yet to come.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/mt7921.4 3.html b/static/freebsd/man4/mt7921.4 3.html deleted file mode 100644 index 9d848979..00000000 --- a/static/freebsd/man4/mt7921.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
MT7921(4)Device Drivers ManualMT7921(4)
-
-
-

-

mt7921 — MediaTek - IEEE 802.11ax wireless network driver

-
-
-

-

The driver will auto-load without any user interaction using - devmatch(8) if enabled in - rc.conf(5).

-

Only if auto-loading is explicitly disabled, place the following - lines in rc.conf(5) to manually load the driver as a - module at boot time:

-
-
kld_list="${kld_list} if_mt7921"
-
-

The driver should automatically load any firmware needed for the - particular chipset.

-

It is discouraged to load the driver from - loader(8).

-
-
-

-

The mt7921 driver provides support for - MediaTek MT7921E wireless network devices. mt7921 is - derived from MediaTek's Linux mt76 driver.

-

This driver requires firmware to be loaded before it will work. - The package wifi-firmware-mt76-kmod from the - ports/net/wifi-firmware-mt76-kmod port needs to be - installed before the driver is loaded. Otherwise no - wlan(4) interface can be created using - ifconfig(8). One can use fwget(8) to - install the correct firmware package.

-

The driver uses the - - and - - compat framework to bridge between the Linux and native - FreeBSD driver code as well as to the native - net80211(4) wireless stack.

-
-
-

-

The mt7921 driver supports PCIe devices - with the following chipsets:

-

-
    -
  • MediaTek MT7921E
    • -
-
-
-

-

wlan(4), networking(7), - fwget(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The mt7921 driver first appeared in - FreeBSD 14.0.

-
-
-

-

Certainly.

-

While mt7921 supports 802.11a/b/g/n/ac/ax - modes, the compatibility code currently only supports 802.11a/b/g modes. - Support for 802.11n/ac/ax is to come.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/mtio.4 3.html b/static/freebsd/man4/mtio.4 3.html deleted file mode 100644 index 2cc4e494..00000000 --- a/static/freebsd/man4/mtio.4 3.html +++ /dev/null @@ -1,381 +0,0 @@ - - - - - - -
MTIO(4)Device Drivers ManualMTIO(4)
-
-
-

-

mtio — FreeBSD - magtape interface

-
-
-

-

The special files named /dev/[en]sa* refer - to SCSI tape drives, which may be attached to the system. - /dev/sa*.ctl are control devices that can be used to - issue ioctls to the SCSI tape driver to set parameters that are required to - last beyond the unmounting of a tape.

-

The rewind devices automatically rewind when the last requested - read, write or seek has finished, or the end of the tape has been reached. - The letter ‘n’ is prepended to the - name of the no-rewind devices. The letter - ‘e’ is prepended to the name of the - eject devices.

-

Tapes can be written with either fixed length records or variable - length records. See sa(4) for more information. Two - filemarks mark the end of a tape, and one filemark marks the end of a tape - file. If the tape is not to be rewound it is positioned with the head in - between the two tape marks, where the next write will over write the second - end-of-file marker.

-

All of the magtape devices may be manipulated with the - mt(1) command.

-

A number of ioctl(2) operations are available on - raw magnetic tape. The following definitions are from - <sys/mtio.h>:

-
-
#ifndef	_SYS_MTIO_H_
-#define	_SYS_MTIO_H_
-
-#ifndef _KERNEL
-#include <sys/types.h>
-#endif
-#include <sys/ioccom.h>
-
-/*
- * Structures and definitions for mag tape io control commands
- */
-
-/* structure for MTIOCTOP - mag tape op command */
-struct mtop {
-	short	mt_op;		/* operations defined below */
-	int32_t	mt_count;	/* how many of them */
-};
-
-/* operations */
-#define MTWEOF		0	/* write an end-of-file record */
-#define MTFSF		1	/* forward space file */
-#define MTBSF		2	/* backward space file */
-#define MTFSR		3	/* forward space record */
-#define MTBSR		4	/* backward space record */
-#define MTREW		5	/* rewind */
-#define MTOFFL		6	/* rewind and put the drive offline */
-#define MTNOP		7	/* no operation, sets status only */
-#define MTCACHE		8	/* enable controller cache */
-#define MTNOCACHE	9	/* disable controller cache */
-
-#if defined(__FreeBSD__)
-/* Set block size for device. If device is a variable size dev		*/
-/* a non zero parameter will change the device to a fixed block size	*/
-/* device with block size set to that of the parameter passed in.	*/
-/* Resetting the block size to 0 will restore the device to a variable	*/
-/* block size device. */
-
-#define MTSETBSIZ	10
-
-/* Set density values for device. Sets the value for the opened mode only. */
-
-#define MTSETDNSTY	11
-
-#define MTERASE		12	/* erase to EOM */
-#define MTEOD		13	/* Space to EOM */
-#define MTCOMP		14	/* select compression mode 0=off, 1=def */
-#define MTRETENS	15	/* re-tension tape */
-#define MTWSS		16	/* write setmark(s) */
-#define MTFSS		17	/* forward space setmark */
-#define MTBSS		18	/* backward space setmark */
-#define MTLOAD		19	/* load tape in drive */
-#define MTWEOFI		20	/* write an end-of-file record without waiting*/
-
-#define MT_COMP_ENABLE		0xffffffff
-#define MT_COMP_DISABLED	0xfffffffe
-#define MT_COMP_UNSUPP		0xfffffffd
-
-/*
- * Values in mt_dsreg that say what the device is doing
- */
-#define	MTIO_DSREG_NIL	0	/* Unknown */
-#define	MTIO_DSREG_REST	1	/* Doing Nothing */
-#define	MTIO_DSREG_RBSY	2	/* Communicating with tape (but no motion) */
-#define	MTIO_DSREG_WR	20	/* Writing */
-#define	MTIO_DSREG_FMK	21	/* Writing Filemarks */
-#define	MTIO_DSREG_ZER	22	/* Erasing */
-#define	MTIO_DSREG_RD	30	/* Reading */
-#define	MTIO_DSREG_FWD	40	/* Spacing Forward */
-#define	MTIO_DSREG_REV	41	/* Spacing Reverse */
-#define	MTIO_DSREG_POS	42	/* Hardware Positioning (direction unknown) */
-#define	MTIO_DSREG_REW	43	/* Rewinding */
-#define	MTIO_DSREG_TEN	44	/* Retensioning */
-#define	MTIO_DSREG_UNL	45	/* Unloading */
-#define	MTIO_DSREG_LD	46	/* Loading */
-
-#endif	/* __FreeBSD__ */
-
-/* structure for MTIOCGET - mag tape get status command */
-
-struct mtget {
-	short	mt_type;	/* type of magtape device */
-/* the following two registers are grossly device dependent */
-	short	mt_dsreg;	/* ``drive status'' register */
-	short	mt_erreg;	/* ``error'' register */
-/* end device-dependent registers */
-	/*
-	 * Note that the residual count, while maintained, may be
-	 * be nonsense because the size of the residual may (greatly)
-	 * exceed 32 K-bytes. Use the MTIOCERRSTAT ioctl to get a
-	 * more accurate count.
-	 */
-	short	mt_resid;	/* residual count */
-#if defined (__FreeBSD__)
-	int32_t mt_blksiz;	/* presently operating blocksize */
-	int32_t mt_density;	/* presently operating density */
-	uint32_t mt_comp;	/* presently operating compression */
-	int32_t mt_blksiz0;	/* blocksize for mode 0 */
-	int32_t mt_blksiz1;	/* blocksize for mode 1 */
-	int32_t mt_blksiz2;	/* blocksize for mode 2 */
-	int32_t mt_blksiz3;	/* blocksize for mode 3 */
-	int32_t mt_density0;	/* density for mode 0 */
-	int32_t mt_density1;	/* density for mode 1 */
-	int32_t mt_density2;	/* density for mode 2 */
-	int32_t mt_density3;	/* density for mode 3 */
-/* the following are not yet implemented */
-	uint32_t mt_comp0;	/* compression type for mode 0 */
-	uint32_t mt_comp1;	/* compression type for mode 1 */
-	uint32_t mt_comp2;	/* compression type for mode 2 */
-	uint32_t mt_comp3;	/* compression type for mode 3 */
-/* end not yet implemented */
-#endif
-	int32_t	mt_fileno;	/* relative file number of current position */
-	int32_t	mt_blkno;	/* relative block number of current position */
-};
-
-/* structure for MTIOCERRSTAT - tape get error status command */
-/* really only supported for SCSI tapes right now */
-struct scsi_tape_errors {
-	/*
-	 * These are latched from the last command that had a SCSI
-	 * Check Condition noted for these operations. The act
-	 * of issuing an MTIOCERRSTAT unlatches and clears them.
-	 */
-	uint8_t io_sense[32];	/* Last Sense Data For Data I/O */
-	int32_t io_resid;	/* residual count from last Data I/O */
-	uint8_t io_cdb[16];	/* Command that Caused the Last Data Sense */
-	uint8_t ctl_sense[32];	/* Last Sense Data For Control I/O */
-	int32_t ctl_resid;	/* residual count from last Control I/O */
-	uint8_t ctl_cdb[16];	/* Command that Caused the Last Control Sense */
-	/*
-	 * These are the read and write cumulative error counters.
-	 * (how to reset cumulative error counters is not yet defined).
-	 * (not implemented as yet but space is being reserved for them)
-	 */
-	struct {
-		uint32_t retries;	/* total # retries performed */
-		uint32_t corrected;	/* total # corrections performed */
-		uint32_t processed;	/* total # corrections successful */
-		uint32_t failures;	/* total # corrections/retries failed */
-		uint64_t nbytes;	/* total # bytes processed */
-	} wterr, rderr;
-};
-
-union mterrstat {
-	struct scsi_tape_errors scsi_errstat;
-	char _reserved_padding[256];
-};
-
-struct mtrblim {
-	uint32_t granularity;
-	uint32_t min_block_length;
-	uint32_t max_block_length;
-};
-
-typedef enum {
-	MT_LOCATE_DEST_OBJECT	= 0x00,
-	MT_LOCATE_DEST_FILE	= 0x01,
-	MT_LOCATE_DEST_SET	= 0x02,
-	MT_LOCATE_DEST_EOD	= 0x03
-} mt_locate_dest_type;
-
-typedef enum {
-	MT_LOCATE_BAM_IMPLICIT	= 0x00,
-	MT_LOCATE_BAM_EXPLICIT	= 0x01
-} mt_locate_bam;
-
-typedef enum {
-	MT_LOCATE_FLAG_IMMED		= 0x01,
-	MT_LOCATE_FLAG_CHANGE_PART	= 0x02
-} mt_locate_flags;
-
-struct mtlocate {
-	mt_locate_flags		flags;
-	mt_locate_dest_type 	dest_type;
-	mt_locate_bam		block_address_mode;
-	int64_t			partition;
-	uint64_t		logical_id;
-	uint8_t			reserved[64];
-};
-
-typedef enum {
-	MT_EXT_GET_NONE,
-	MT_EXT_GET_OK,
-	MT_EXT_GET_NEED_MORE_SPACE,
-	MT_EXT_GET_ERROR
-} mt_ext_get_status;
-
-struct mtextget {
-	uint32_t		alloc_len;
-	char			*status_xml;
-	uint32_t		fill_len;
-	mt_ext_get_status	status;
-	char			error_str[128];
-	uint8_t			reserved[64];
-};
-
-#define	MT_EXT_GET_ROOT_NAME		"mtextget"
-#define	MT_DENSITY_ROOT_NAME		"mtdensity"
-#define	MT_MEDIA_DENSITY_NAME		"media_density"
-#define	MT_DENSITY_REPORT_NAME		"density_report"
-#define	MT_MEDIUM_TYPE_REPORT_NAME	"medium_type_report"
-#define	MT_MEDIA_REPORT_NAME		"media_report"
-#define	MT_DENSITY_ENTRY_NAME		"density_entry"
-
-#define	MT_DENS_WRITE_OK		0x80
-#define	MT_DENS_DUP			0x40
-#define	MT_DENS_DEFLT			0x20
-
-
-#define	MT_PARAM_FIXED_STR_LEN	32
-union mt_param_value {
-	int64_t		value_signed;
-	uint64_t	value_unsigned;
-	char		*value_var_str;
-	char		value_fixed_str[MT_PARAM_FIXED_STR_LEN];
-	uint8_t		reserved[64];
-};
-
-typedef enum {
-	MT_PARAM_SET_NONE,
-	MT_PARAM_SET_SIGNED,
-	MT_PARAM_SET_UNSIGNED,
-	MT_PARAM_SET_VAR_STR,
-	MT_PARAM_SET_FIXED_STR
-} mt_param_set_type;
-
-typedef enum {
-	MT_PARAM_STATUS_NONE,
-	MT_PARAM_STATUS_OK,
-	MT_PARAM_STATUS_ERROR
-} mt_param_set_status;
-
-#define	MT_PARAM_VALUE_NAME_LEN	64
-struct mtparamset {
-	char			value_name[MT_PARAM_VALUE_NAME_LEN];
-	mt_param_set_type	value_type;
-	int			value_len;
-	union mt_param_value	value;
-	mt_param_set_status	status;
-	char			error_str[128];
-};
-
-#define	MT_PARAM_ROOT_NAME	"mtparamget"
-#define	MT_PROTECTION_NAME	"protection"
-
-/*
- * Set a list of parameters.
- */
-struct mtsetlist {
-	int num_params;
-	int param_len;
-	struct mtparamset *params;
-};
-
-/*
- * Constants for mt_type byte.  These are the same
- * for controllers compatible with the types listed.
- */
-#define	MT_ISTS		0x01		/* TS-11 */
-#define	MT_ISHT		0x02		/* TM03 Massbus: TE16, TU45, TU77 */
-#define	MT_ISTM		0x03		/* TM11/TE10 Unibus */
-#define	MT_ISMT		0x04		/* TM78/TU78 Massbus */
-#define	MT_ISUT		0x05		/* SI TU-45 emulation on Unibus */
-#define	MT_ISCPC	0x06		/* SUN */
-#define	MT_ISAR		0x07		/* SUN */
-#define	MT_ISTMSCP	0x08		/* DEC TMSCP protocol (TU81, TK50) */
-#define MT_ISCY		0x09		/* CCI Cipher */
-#define MT_ISCT		0x0a		/* HP 1/4 tape */
-#define MT_ISFHP	0x0b		/* HP 7980 1/2 tape */
-#define MT_ISEXABYTE	0x0c		/* Exabyte */
-#define MT_ISEXA8200	0x0c		/* Exabyte EXB-8200 */
-#define MT_ISEXA8500	0x0d		/* Exabyte EXB-8500 */
-#define MT_ISVIPER1	0x0e		/* Archive Viper-150 */
-#define MT_ISPYTHON	0x0f		/* Archive Python (DAT) */
-#define MT_ISHPDAT	0x10		/* HP 35450A DAT drive */
-#define MT_ISMFOUR	0x11		/* M4 Data 1/2 9track drive */
-#define MT_ISTK50	0x12		/* DEC SCSI TK50 */
-#define MT_ISMT02	0x13		/* Emulex MT02 SCSI tape controller */
-
-/* mag tape io control commands */
-#define	MTIOCTOP	_IOW('m', 1, struct mtop)	/* do a mag tape op */
-#define	MTIOCGET	_IOR('m', 2, struct mtget)	/* get tape status */
-/* these two do not appear to be used anywhere */
-#define MTIOCIEOT	_IO('m', 3)			/* ignore EOT error */
-#define MTIOCEEOT	_IO('m', 4)			/* enable EOT error */
-/*
- * When more SCSI-3 SSC (streaming device) devices are out there
- * that support the full 32 byte type 2 structure, we'll have to
- * rethink these ioctls to support all the entities they haul into
- * the picture (64 bit blocks, logical file record numbers, etc..).
- */
-#define	MTIOCRDSPOS	_IOR('m', 5, uint32_t)	/* get logical blk addr */
-#define	MTIOCRDHPOS	_IOR('m', 6, uint32_t)	/* get hardware blk addr */
-#define	MTIOCSLOCATE	_IOW('m', 5, uint32_t)	/* seek to logical blk addr */
-#define	MTIOCHLOCATE	_IOW('m', 6, uint32_t)	/* seek to hardware blk addr */
-#define	MTIOCERRSTAT	_IOR('m', 7, union mterrstat)	/* get tape errors */
-/*
- * Set EOT model- argument is number of filemarks to end a tape with.
- * Note that not all possible values will be accepted.
- */
-#define	MTIOCSETEOTMODEL	_IOW('m', 8, uint32_t)
-/* Get current EOT model */
-#define	MTIOCGETEOTMODEL	_IOR('m', 8, uint32_t)
-#define	MTIOCRBLIM	_IOR('m', 9, struct mtrblim)    /* get block limits */
-#define	MTIOCEXTLOCATE	_IOW('m', 10, struct mtlocate)  /* seek to position */
-#define	MTIOCEXTGET	_IOWR('m', 11, struct mtextget) /* get tape status */
-#define	MTIOCPARAMGET	_IOWR('m', 12, struct mtextget) /* get tape params */
-#define	MTIOCPARAMSET	_IOWR('m', 13, struct mtparamset) /* set tape params */
-#define	MTIOCSETLIST	_IOWR('m', 14, struct mtsetlist) /* set N params */
-
-#ifndef _KERNEL
-#define	DEFTAPE	"/dev/nsa0"
-#endif
-
-#endif /* !_SYS_MTIO_H_ */
-
-
-
-

-
-
/dev/[en]sa*
-
 
-
-
-
-

-

mt(1), tar(1), - sa(4)

-
-
-

-

The mtio manual appeared in - 4.2BSD. An i386 version first appeared in - FreeBSD 2.2.

-
-
- - - - - -
February 12, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mtkswitch.4 4.html b/static/freebsd/man4/mtkswitch.4 4.html deleted file mode 100644 index 22df022d..00000000 --- a/static/freebsd/man4/mtkswitch.4 4.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - -
MTKSWITCH(4)Device Drivers ManualMTKSWITCH(4)
-
-
-

-

mtkswitch — - MediaTek/Ralink Ethernet switch driver

-
-
-

-

device mdio -
- device etherswitch -
- device mtkswitch

-
-
-

-

The mtkswitch driver supports - MediaTek/Ralink Ethernet switch controllers.

-
-
-

-

The mtkswitch driver supports the - following Ethernet switch controllers:

-

-
    -
  • MediaTek MT7628 (5 port Fast Ethernet)
    • -
  • MediaTek MT7621 (5 port Gigabit Ethernet)
    • -
  • MediaTek MT7620 (5 port Fast Ethernet)
    • -
  • Ralink RT5350 (5 port Fast Ethernet)
    • -
  • Ralink RT3352 (5 port Fast Ethernet)
    • -
  • Ralink RT3050 (5 port Fast Ethernet)
    • -
-
-
-

-

etherswitch(4), - etherswitchcfg(8)

-
-
-

-

The mtkswitch driver appeared in - FreeBSD 11.0.

-
-
- - - - - -
May 19, 2025
diff --git a/static/freebsd/man4/mtw.4 4.html b/static/freebsd/man4/mtw.4 4.html deleted file mode 100644 index f7ff86a6..00000000 --- a/static/freebsd/man4/mtw.4 4.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
MTW(4)Device Drivers ManualMTW(4)
-
-
-

-

mtw — MediaTek - MT7601U USB IEEE 802.11n wireless network driver

-
-
-

-

device usb -
- device mtw -
- device wlan

-

In rc.conf(5): -
- kld_list="if_mtw"

-
-
-

-

This module provides support for MediaTek MT7601U USB wireless - network adapters. If the appropriate hardware is detected, the driver will - be automatically loaded with devmatch(8). If driver - autoloading is explicitly disabled, enable the module in - rc.conf(5). The mtw driver can be - configured at runtime with ifconfig(8) or at boot with - rc.conf(5).

-
-
-

-

The mtw driver supports MediaTek MT7601U - based USB wireless network adapters including (but not all of them - tested):

-

-
    -
  • ASUS USB-N10 v2
    • -
  • D-Link DWA-127 rev B1
    • -
  • Edimax EW-7711UAn v2
    • -
  • Foxconn WFU03
    • -
  • Tenda U2
    • -
  • Tenda W311MI v2
    • -
  • TP-LINK TL-WN727N v4 (tested working)
    • -
  • Yealink WF40
    • -
-
-
-

-

The mtw driver requires firmware from - ports/net/wifi-firmware-mt7601u-kmod. This firmware - package will be installed automatically with fwget(8) if - the appropriate hardware is detected at installation or runtime.

-
-
-

-

usb(4), wlan(4), - networking(7), fwget(8), - wpa_supplicant(8)

-
-
-

-

The mtw driver first appeared in - OpenBSD 7.1 and FreeBSD - 15.0.

-
-
-

-

The mtw driver was written by - James Hastings - <hastings@openbsd.org> - and ported to FreeBSD by Jesper - Schmitz Mouridsen - <jsm@FreeBSD.org>.

-
-
-

-

mtw only works in - station mode and monitor - mode. The firmware does not always reinitialize when reloading the module, - or when rebooting, without first unplugging the device.

-
-
- - - - - -
May 3, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/muge.4 4.html b/static/freebsd/man4/muge.4 4.html deleted file mode 100644 index 1ce48837..00000000 --- a/static/freebsd/man4/muge.4 4.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - -
MUGE(4)Device Drivers ManualMUGE(4)
-
-
-

-

muge — Microchip - LAN78xx USB Gigabit Ethernet driver

-
-
-

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_muge_load="YES"
-
-
-
-

-

The muge device driver provides support - for USB Gigabit Ethernet adapters based on Microchip's LAN78xx and LAN7515 - chipsets.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The muge driver supports Microchip USB - Gigabit Ethernet interfaces, including:

-

-
    -
  • Microchip LAN7800 USB 3.1 Gigabit Ethernet controller with PHY
    • -
  • Microchip LAN7850 USB 2.0 Gigabit Ethernet controller with PHY
    • -
  • Microchip LAN7515 USB 2 hub and Gigabit Ethernet controller with PHY
    • -
-
-
-

-

arp(4), miibus(4), - usb(4), ifconfig(8)

-
-
-

-

The muge device driver first appeared in - FreeBSD 12.0.

-
-
- - - - - -
June 11, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/multicast.4 3.html b/static/freebsd/man4/multicast.4 3.html deleted file mode 100644 index b47b6143..00000000 --- a/static/freebsd/man4/multicast.4 3.html +++ /dev/null @@ -1,750 +0,0 @@ - - - - - - -
MULTICAST(4)Device Drivers ManualMULTICAST(4)
-
-
-

-

multicast — - Multicast Routing

-
-
-

-

options MROUTING

-

-
- #include <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet/ip_mroute.h> -
- #include - <netinet6/ip6_mroute.h>

-

int -
- getsockopt(int - s, IPPROTO_IP, - MRT_INIT, - void *optval, - socklen_t *optlen);

-

int -
- setsockopt(int - s, IPPROTO_IP, - MRT_INIT, - const void *optval, - socklen_t optlen);

-

int -
- getsockopt(int - s, IPPROTO_IPV6, - MRT6_INIT, - void *optval, - socklen_t *optlen);

-

int -
- setsockopt(int - s, IPPROTO_IPV6, - MRT6_INIT, - const void *optval, - socklen_t optlen);

-
-
-

-

Multicast routing is used to efficiently propagate data packets to - a set of multicast listeners in multipoint networks. If unicast is used to - replicate the data to all listeners, then some of the network links may - carry multiple copies of the same data packets. With multicast routing, the - overhead is reduced to one copy (at most) per network link.

-

All multicast-capable routers must run a common multicast routing - protocol. It is recommended that either Protocol Independent Multicast - - Sparse Mode (PIM-SM), or Protocol Independent Multicast - Dense Mode - (PIM-DM) are used, as these are now the generally accepted protocols in the - Internet community. The HISTORY section - discusses previous multicast routing protocols.

-

To start multicast routing, the user must enable multicast - forwarding in the kernel (see SYNOPSIS - about the kernel configuration options), and must run a multicast routing - capable user-level process. From developer's point of view, the programming - guide described in the Programming - Guide section should be used to control the multicast forwarding in the - kernel.

-
-

-

This section provides information about the basic multicast - routing API. The so-called “advanced multicast API” is - described in the - Advanced - Multicast API Programming Guide section.

-

First, a multicast routing socket must be open. That socket would - be used to control the multicast forwarding in the kernel. Note that most - operations below require certain privilege (i.e., root privilege):

-
-
/* IPv4 */
-int mrouter_s4;
-mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);
-
-
-
int mrouter_s6;
-mrouter_s6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
-
-

Note that if the router needs to open an IGMP or ICMPv6 socket (in - case of IPv4 and IPv6 respectively) for sending or receiving of IGMP or MLD - multicast group membership messages, then the same - mrouter_s4 or mrouter_s6 sockets - should be used for sending and receiving respectively IGMP or MLD messages. - In case of BSD-derived kernel, it may be possible to - open separate sockets for IGMP or MLD messages only. However, some other - kernels (e.g., Linux) require that the multicast routing socket must be used - for sending and receiving of IGMP or MLD messages. Therefore, for - portability reason the multicast routing socket should be reused for IGMP - and MLD messages as well.

-

After the multicast routing socket is open, it can be used to - enable multicast forwarding in the kernel:

-
-
/* IPv4 */
-int v = 1;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, (void *)&v, sizeof(v));
-
-
-
/* IPv6 */
-int v = 1;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_INIT, (void *)&v, sizeof(v));
-...
-/* If necessary, filter all ICMPv6 messages */
-struct icmp6_filter filter;
-ICMP6_FILTER_SETBLOCKALL(&filter);
-setsockopt(mrouter_s6, IPPROTO_ICMPV6, ICMP6_FILTER, (void *)&filter,
-           sizeof(filter));
-
-

When applied to the multicast routing socket, the - MRT_DONE and MRT6_DONE - socket options disable multicast forwarding in the kernel:

-
-
/* IPv4 */
-int v = 1;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_DONE, (void *)&v, sizeof(v));
-
-
-
/* IPv6 */
-int v = 1;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DONE, (void *)&v, sizeof(v));
-
-

Closing the socket has the same effect.

-

After multicast forwarding is enabled, the multicast routing - socket can be used to enable PIM processing in the kernel if we are running - PIM-SM or PIM-DM (see pim(4)).

-

For each network interface (e.g., physical or a virtual tunnel) - that would be used for multicast forwarding, a corresponding multicast - interface must be added to the kernel:

-
-
/* IPv4 */
-struct vifctl vc;
-memset(&vc, 0, sizeof(vc));
-/* Assign all vifctl fields as appropriate */
-vc.vifc_vifi = vif_index;
-vc.vifc_flags = vif_flags;
-vc.vifc_threshold = min_ttl_threshold;
-vc.vifc_rate_limit = 0;
-memcpy(&vc.vifc_lcl_addr, &vif_local_address, sizeof(vc.vifc_lcl_addr));
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc,
-           sizeof(vc));
-
-

The vif_index must be unique per vif. The - vif_flags contains the VIFF_* - flags as defined in - <netinet/ip_mroute.h>. The - VIFF_TUNNEL flag is no longer supported by - FreeBSD. Users who wish to forward multicast - datagrams over a tunnel should consider configuring a - gif(4) or gre(4) tunnel and using it as - a physical interface.

-

The min_ttl_threshold contains the minimum - TTL a multicast data packet must have to be forwarded on that vif. - Typically, it would have value of 1.

-

The max_rate_limit argument is no longer - supported in FreeBSD and should be set to 0. Users - who wish to rate-limit multicast datagrams should consider the use of - dummynet(4) or altq(4).

-

The vif_local_address contains the local IP - address of the corresponding local interface. The - vif_remote_address contains the remote IP address in - case of DVMRP multicast tunnels.

-
-
/* IPv6 */
-struct mif6ctl mc;
-memset(&mc, 0, sizeof(mc));
-/* Assign all mif6ctl fields as appropriate */
-mc.mif6c_mifi = mif_index;
-mc.mif6c_flags = mif_flags;
-mc.mif6c_pifi = pif_index;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MIF, (void *)&mc,
-           sizeof(mc));
-
-

The mif_index must be unique per vif. The - mif_flags contains the MIFF_* - flags as defined in - <netinet6/ip6_mroute.h>. The - pif_index is the physical interface index of the - corresponding local interface.

-

A multicast interface is deleted by:

-
-
/* IPv4 */
-vifi_t vifi = vif_index;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_VIF, (void *)&vifi,
-           sizeof(vifi));
-
-
-
/* IPv6 */
-mifi_t mifi = mif_index;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DEL_MIF, (void *)&mifi,
-           sizeof(mifi));
-
-

After the multicast forwarding is enabled, and the multicast - virtual interfaces are added, the kernel may deliver upcall messages (also - called signals later in this text) on the multicast routing socket that was - open earlier with MRT_INIT or - MRT6_INIT. The IPv4 upcalls have - struct igmpmsg header (see - <netinet/ip_mroute.h>) with - field im_mbz set to zero. Note that this header - follows the structure of struct ip with the protocol - field ip_p set to zero. The IPv6 upcalls have - struct mrt6msg header (see - <netinet6/ip6_mroute.h>) - with field im6_mbz set to zero. Note that this header - follows the structure of struct ip6_hdr with the next - header field ip6_nxt set to zero.

-

The upcall header contains field im_msgtype - and im6_msgtype with the type of the upcall - IGMPMSG_* and MRT6MSG_* for - IPv4 and IPv6 respectively. The values of the rest of the upcall header - fields and the body of the upcall message depend on the particular upcall - type.

-

If the upcall message type is - IGMPMSG_NOCACHE or - MRT6MSG_NOCACHE, this is an indication that a - multicast packet has reached the multicast router, but the router has no - forwarding state for that packet. Typically, the upcall would be a signal - for the multicast routing user-level process to install the appropriate - Multicast Forwarding Cache (MFC) entry in the kernel.

-

An MFC entry is added by:

-
-
/* IPv4 */
-struct mfcctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mfcc_origin, &source_addr, sizeof(mc.mfcc_origin));
-memcpy(&mc.mfcc_mcastgrp, &group_addr, sizeof(mc.mfcc_mcastgrp));
-mc.mfcc_parent = iif_index;
-for (i = 0; i < maxvifs; i++)
-    mc.mfcc_ttls[i] = oifs_ttl[i];
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_MFC,
-           (void *)&mc, sizeof(mc));
-
-
-
/* IPv6 */
-struct mf6cctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mf6cc_origin, &source_addr, sizeof(mc.mf6cc_origin));
-memcpy(&mc.mf6cc_mcastgrp, &group_addr, sizeof(mf6cc_mcastgrp));
-mc.mf6cc_parent = iif_index;
-for (i = 0; i < maxvifs; i++)
-    if (oifs_ttl[i] > 0)
-        IF_SET(i, &mc.mf6cc_ifset);
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MFC,
-           (void *)&mc, sizeof(mc));
-
-

The source_addr and - group_addr are the source and group address of the - multicast packet (as set in the upcall message). The - iif_index is the virtual interface index of the - multicast interface the multicast packets for this specific source and group - address should be received on. The oifs_ttl[] array - contains the minimum TTL (per interface) a multicast packet should have to - be forwarded on an outgoing interface. If the TTL value is zero, the - corresponding interface is not included in the set of outgoing interfaces. - Note that in case of IPv6 only the set of outgoing interfaces can be - specified.

-

An MFC entry is deleted by:

-
-
/* IPv4 */
-struct mfcctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mfcc_origin, &source_addr, sizeof(mc.mfcc_origin));
-memcpy(&mc.mfcc_mcastgrp, &group_addr, sizeof(mc.mfcc_mcastgrp));
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_MFC,
-           (void *)&mc, sizeof(mc));
-
-
-
/* IPv6 */
-struct mf6cctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mf6cc_origin, &source_addr, sizeof(mc.mf6cc_origin));
-memcpy(&mc.mf6cc_mcastgrp, &group_addr, sizeof(mf6cc_mcastgrp));
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DEL_MFC,
-           (void *)&mc, sizeof(mc));
-
-

The following method can be used to get various statistics per - installed MFC entry in the kernel (e.g., the number of forwarded packets per - source and group address):

-
-
/* IPv4 */
-struct sioc_sg_req sgreq;
-memset(&sgreq, 0, sizeof(sgreq));
-memcpy(&sgreq.src, &source_addr, sizeof(sgreq.src));
-memcpy(&sgreq.grp, &group_addr, sizeof(sgreq.grp));
-ioctl(mrouter_s4, SIOCGETSGCNT, &sgreq);
-
-
-
/* IPv6 */
-struct sioc_sg_req6 sgreq;
-memset(&sgreq, 0, sizeof(sgreq));
-memcpy(&sgreq.src, &source_addr, sizeof(sgreq.src));
-memcpy(&sgreq.grp, &group_addr, sizeof(sgreq.grp));
-ioctl(mrouter_s6, SIOCGETSGCNT_IN6, &sgreq);
-
-

The following method can be used to get various statistics per - multicast virtual interface in the kernel (e.g., the number of forwarded - packets per interface):

-
-
/* IPv4 */
-struct sioc_vif_req vreq;
-memset(&vreq, 0, sizeof(vreq));
-vreq.vifi = vif_index;
-ioctl(mrouter_s4, SIOCGETVIFCNT, &vreq);
-
-
-
/* IPv6 */
-struct sioc_mif_req6 mreq;
-memset(&mreq, 0, sizeof(mreq));
-mreq.mifi = vif_index;
-ioctl(mrouter_s6, SIOCGETMIFCNT_IN6, &mreq);
-
-
-
-

-

If we want to add new features in the kernel, it becomes difficult - to preserve backward compatibility (binary and API), and at the same time to - allow user-level processes to take advantage of the new features (if the - kernel supports them).

-

One of the mechanisms that allows us to preserve the backward - compatibility is a sort of negotiation between the user-level process and - the kernel:

-
    -
  1. The user-level process tries to enable in the kernel the set of new - features (and the corresponding API) it would like to use.
    2. -
  2. The kernel returns the (sub)set of features it knows about and is willing - to be enabled.
    3. -
  3. The user-level process uses only that set of features the kernel has - agreed on.
    4. -
-

To support backward compatibility, if the user-level process does - not ask for any new features, the kernel defaults to the basic multicast API - (see the Programming Guide - section). Currently, the advanced multicast API exists only for IPv4; in the - future there will be IPv6 support as well.

-

Below is a summary of the expandable API solution. Note that all - new options and structures are defined in - <netinet/ip_mroute.h> and - <netinet6/ip6_mroute.h>, - unless stated otherwise.

-

The user-level process uses new - ()/setsockopt() - options to perform the API features negotiation with the kernel. This - negotiation must be performed right after the multicast routing socket is - open. The set of desired/allowed features is stored in a bitset (currently, - in uint32_t; i.e., maximum of 32 new features). The - new - getsockopt()/setsockopt() - options are MRT_API_SUPPORT and - MRT_API_CONFIG. Example:

-
-
uint32_t v;
-getsockopt(sock, IPPROTO_IP, MRT_API_SUPPORT, (void *)&v, sizeof(v));
-
-

would set in v the - pre-defined bits that the kernel API supports. The eight least significant - bits in uint32_t are same as the eight possible flags - MRT_MFC_FLAGS_* that can be used in - mfcc_flags as part of the new definition of - struct mfcctl (see below about those flags), which - leaves 24 flags for other new features. The value returned by - (MRT_API_SUPPORT) - is read-only; in other words, - setsockopt(MRT_API_SUPPORT) - would fail.

-

To modify the API, and to set some specific feature in the kernel, - then:

-
-
uint32_t v = MRT_MFC_FLAGS_DISABLE_WRONGVIF;
-if (setsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)&v, sizeof(v))
-    != 0) {
-    return (ERROR);
-}
-if (v & MRT_MFC_FLAGS_DISABLE_WRONGVIF)
-    return (OK);	/* Success */
-else
-    return (ERROR);
-
-

In other words, when - (MRT_API_CONFIG) - is called, the argument to it specifies the desired set of features to be - enabled in the API and the kernel. The return value in - v is the actual (sub)set of features that were enabled - in the kernel. To obtain later the same set of features that were enabled, - then:

-
-
getsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)&v, sizeof(v));
-
-

The set of enabled features is global. In other - words, - (MRT_API_CONFIG) - should be called right after - setsockopt(MRT_INIT).

-

Currently, the following set of new features is defined:

-
-
#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 << 0) /* disable WRONGVIF signals */
-#define	MRT_MFC_FLAGS_BORDER_VIF   (1 << 1)  /* border vif              */
-#define MRT_MFC_RP                 (1 << 8)  /* enable RP address	*/
-#define MRT_MFC_BW_UPCALL          (1 << 9)  /* enable bw upcalls	*/
-
-

The advanced multicast API uses a newly defined - struct mfcctl2 instead of the traditional - struct mfcctl. The original struct - mfcctl is kept as is. The new struct mfcctl2 - is:

-
-
/*
- * The new argument structure for MRT_ADD_MFC and MRT_DEL_MFC overlays
- * and extends the old struct mfcctl.
- */
-struct mfcctl2 {
-        /* the mfcctl fields */
-        struct in_addr  mfcc_origin;       /* ip origin of mcasts       */
-        struct in_addr  mfcc_mcastgrp;     /* multicast group associated*/
-        vifi_t          mfcc_parent;       /* incoming vif              */
-        u_char          mfcc_ttls[MAXVIFS];/* forwarding ttls on vifs   */
-
-        /* extension fields */
-        uint8_t         mfcc_flags[MAXVIFS];/* the MRT_MFC_FLAGS_* flags*/
-        struct in_addr  mfcc_rp;            /* the RP address           */
-};
-
-

The new fields are mfcc_flags[MAXVIFS] and - mfcc_rp. Note that for compatibility reasons they are - added at the end.

-

The mfcc_flags[MAXVIFS] field is used to set - various flags per interface per (S,G) entry. Currently, the defined flags - are:

-
-
#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 << 0) /* disable WRONGVIF signals */
-#define	MRT_MFC_FLAGS_BORDER_VIF       (1 << 1) /* border vif          */
-
-

The MRT_MFC_FLAGS_DISABLE_WRONGVIF flag is - used to explicitly disable the IGMPMSG_WRONGVIF - kernel signal at the (S,G) granularity if a multicast data packet arrives on - the wrong interface. Usually, this signal is used to complete the - shortest-path switch in case of PIM-SM multicast routing, or to trigger a - PIM assert message. However, it should not be delivered for interfaces that - are not in the outgoing interface set, and that are not expecting to become - an incoming interface. Hence, if the - MRT_MFC_FLAGS_DISABLE_WRONGVIF flag is set for some - of the interfaces, then a data packet that arrives on that interface for - that MFC entry will NOT trigger a WRONGVIF signal. If that flag is not set, - then a signal is triggered (the default action).

-

The MRT_MFC_FLAGS_BORDER_VIF flag is used - to specify whether the Border-bit in PIM Register messages should be set (in - case when the Register encapsulation is performed inside the kernel). If it - is set for the special PIM Register kernel virtual interface (see - pim(4)), the Border-bit in the Register messages sent to - the RP will be set.

-

The remaining six bits are reserved for future usage.

-

The mfcc_rp field is used - to specify the RP address (in case of PIM-SM multicast routing) for a - multicast group G if we want to perform kernel-level PIM Register - encapsulation. The mfcc_rp field is used only if the - MRT_MFC_RP advanced API flag/capability has been - successfully set by - (MRT_API_CONFIG).

-

If the MRT_MFC_RP flag - was successfully set by - (MRT_API_CONFIG), - then the kernel will attempt to perform the PIM Register encapsulation - itself instead of sending the multicast data packets to user level (inside - IGMPMSG_WHOLEPKT upcalls) for user-level - encapsulation. The RP address would be taken from the - mfcc_rp field inside the new struct - mfcctl2. However, even if the MRT_MFC_RP flag - was successfully set, if the mfcc_rp field was set to - INADDR_ANY, then the kernel will still deliver an - IGMPMSG_WHOLEPKT upcall with the multicast data - packet to the user-level process.

-

In addition, if the multicast data packet is too large to fit - within a single IP packet after the PIM Register encapsulation (e.g., if its - size was on the order of 65500 bytes), the data packet will be fragmented, - and then each of the fragments will be encapsulated separately. Note that - typically a multicast data packet can be that large only if it was - originated locally from the same hosts that performs the encapsulation; - otherwise the transmission of the multicast data packet over Ethernet for - example would have fragmented it into much smaller pieces.

-

Typically, a multicast routing user-level process would need to - know the forwarding bandwidth for some data flow. For example, the multicast - routing process may want to timeout idle MFC entries, or in case of PIM-SM - it can initiate (S,G) shortest-path switch if the bandwidth rate is above a - threshold for example.

-

The original solution for measuring the bandwidth of a dataflow - was that a user-level process would periodically query the kernel about the - number of forwarded packets/bytes per (S,G), and then based on those numbers - it would estimate whether a source has been idle, or whether the source's - transmission bandwidth is above a threshold. That solution is far from being - scalable, hence the need for a new mechanism for bandwidth monitoring.

-

Below is a description of the bandwidth monitoring mechanism.

-
    -
  • If the bandwidth of a data flow satisfies some pre-defined filter, the - kernel delivers an upcall on the multicast routing socket to the multicast - routing process that has installed that filter.
    • -
  • The bandwidth-upcall filters are installed per (S,G). There can be more - than one filter per (S,G).
    • -
  • Instead of supporting all possible comparison operations (i.e., < <= - == != > >= ), there is support only for the <= and >= - operations, because this makes the kernel-level implementation simpler, - and because practically we need only those two. Further, the missing - operations can be simulated by secondary user-level filtering of those - <= and >= filters. For example, to simulate !=, then we need to - install filter “bw <= 0xffffffff”, and after an upcall is - received, we need to check whether “measured_bw != - expected_bw”.
    • -
  • The bandwidth-upcall mechanism is enabled by - (MRT_API_CONFIG) - for the MRT_MFC_BW_UPCALL flag.
    • -
  • The bandwidth-upcall filters are added/deleted by the new - setsockopt(MRT_ADD_BW_UPCALL) - and - setsockopt(MRT_DEL_BW_UPCALL) - respectively (with the appropriate struct bw_upcall - argument of course).
    • -
-

From application point of view, a developer needs to know about - the following:

-
-
/*
- * Structure for installing or delivering an upcall if the
- * measured bandwidth is above or below a threshold.
- *
- * User programs (e.g. daemons) may have a need to know when the
- * bandwidth used by some data flow is above or below some threshold.
- * This interface allows the userland to specify the threshold (in
- * bytes and/or packets) and the measurement interval. Flows are
- * all packet with the same source and destination IP address.
- * At the moment the code is only used for multicast destinations
- * but there is nothing that prevents its use for unicast.
- *
- * The measurement interval cannot be shorter than some Tmin (currently, 3s).
- * The threshold is set in packets and/or bytes per_interval.
- *
- * Measurement works as follows:
- *
- * For >= measurements:
- * The first packet marks the start of a measurement interval.
- * During an interval we count packets and bytes, and when we
- * pass the threshold we deliver an upcall and we are done.
- * The first packet after the end of the interval resets the
- * count and restarts the measurement.
- *
- * For <= measurement:
- * We start a timer to fire at the end of the interval, and
- * then for each incoming packet we count packets and bytes.
- * When the timer fires, we compare the value with the threshold,
- * schedule an upcall if we are below, and restart the measurement
- * (reschedule timer and zero counters).
- */
-
-struct bw_data {
-        struct timeval  b_time;
-        uint64_t        b_packets;
-        uint64_t        b_bytes;
-};
-
-struct bw_upcall {
-        struct in_addr  bu_src;         /* source address            */
-        struct in_addr  bu_dst;         /* destination address       */
-        uint32_t        bu_flags;       /* misc flags (see below)    */
-#define BW_UPCALL_UNIT_PACKETS (1 << 0) /* threshold (in packets)    */
-#define BW_UPCALL_UNIT_BYTES   (1 << 1) /* threshold (in bytes)      */
-#define BW_UPCALL_GEQ          (1 << 2) /* upcall if bw >= threshold */
-#define BW_UPCALL_LEQ          (1 << 3) /* upcall if bw <= threshold */
-#define BW_UPCALL_DELETE_ALL   (1 << 4) /* delete all upcalls for s,d*/
-        struct bw_data  bu_threshold;   /* the bw threshold          */
-        struct bw_data  bu_measured;    /* the measured bw           */
-};
-
-/* max. number of upcalls to deliver together */
-#define BW_UPCALLS_MAX				128
-/* min. threshold time interval for bandwidth measurement */
-#define BW_UPCALL_THRESHOLD_INTERVAL_MIN_SEC	3
-#define BW_UPCALL_THRESHOLD_INTERVAL_MIN_USEC	0
-
-

The bw_upcall structure is - used as an argument to - (MRT_ADD_BW_UPCALL) - and - setsockopt(MRT_DEL_BW_UPCALL). - Each - setsockopt(MRT_ADD_BW_UPCALL) - installs a filter in the kernel for the source and destination address in - the bw_upcall argument, and that filter will trigger - an upcall according to the following pseudo-algorithm:

-
-
 if (bw_upcall_oper IS ">=") {
-    if (((bw_upcall_unit & PACKETS == PACKETS) &&
-         (measured_packets >= threshold_packets)) ||
-        ((bw_upcall_unit & BYTES == BYTES) &&
-         (measured_bytes >= threshold_bytes)))
-       SEND_UPCALL("measured bandwidth is >= threshold");
-  }
-  if (bw_upcall_oper IS "<=" && measured_interval >= threshold_interval) {
-    if (((bw_upcall_unit & PACKETS == PACKETS) &&
-         (measured_packets <= threshold_packets)) ||
-        ((bw_upcall_unit & BYTES == BYTES) &&
-         (measured_bytes <= threshold_bytes)))
-       SEND_UPCALL("measured bandwidth is <= threshold");
-  }
-
-

In the same bw_upcall the unit can be - specified in both BYTES and PACKETS. However, the GEQ and LEQ flags are - mutually exclusive.

-

Basically, an upcall is delivered if the measured bandwidth is - >= or <= the threshold bandwidth (within the specified measurement - interval). For practical reasons, the smallest value for the measurement - interval is 3 seconds. If smaller values are allowed, then the bandwidth - estimation may be less accurate, or the potentially very high frequency of - the generated upcalls may introduce too much overhead. For the >= - operation, the answer may be known before the end of - threshold_interval, therefore the upcall may be - delivered earlier. For the <= operation however, we must wait until the - threshold interval has expired to know the answer.

-

Example of usage:

-
-
struct bw_upcall bw_upcall;
-/* Assign all bw_upcall fields as appropriate */
-memset(&bw_upcall, 0, sizeof(bw_upcall));
-memcpy(&bw_upcall.bu_src, &source, sizeof(bw_upcall.bu_src));
-memcpy(&bw_upcall.bu_dst, &group, sizeof(bw_upcall.bu_dst));
-bw_upcall.bu_threshold.b_data = threshold_interval;
-bw_upcall.bu_threshold.b_packets = threshold_packets;
-bw_upcall.bu_threshold.b_bytes = threshold_bytes;
-if (is_threshold_in_packets)
-    bw_upcall.bu_flags |= BW_UPCALL_UNIT_PACKETS;
-if (is_threshold_in_bytes)
-    bw_upcall.bu_flags |= BW_UPCALL_UNIT_BYTES;
-do {
-    if (is_geq_upcall) {
-        bw_upcall.bu_flags |= BW_UPCALL_GEQ;
-        break;
-    }
-    if (is_leq_upcall) {
-        bw_upcall.bu_flags |= BW_UPCALL_LEQ;
-        break;
-    }
-    return (ERROR);
-} while (0);
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_BW_UPCALL,
-          (void *)&bw_upcall, sizeof(bw_upcall));
-
-

To delete a single filter, then use - MRT_DEL_BW_UPCALL, and the fields of bw_upcall must - be set exactly same as when MRT_ADD_BW_UPCALL was - called.

-

To delete all bandwidth filters for a given (S,G), then only the - bu_src and bu_dst fields in - struct bw_upcall need to be set, and then just set - only the BW_UPCALL_DELETE_ALL flag inside field - bw_upcall.bu_flags.

-

The bandwidth upcalls are received by aggregating them in the new - upcall message:

-
-
#define IGMPMSG_BW_UPCALL  4  /* BW monitoring upcall */
-
-

This message is an array of struct - bw_upcall elements (up to BW_UPCALLS_MAX = - 128). The upcalls are delivered when there are 128 pending upcalls, or when - 1 second has expired since the previous upcall (whichever comes first). In - an struct upcall element, the - bu_measured field is filled-in to indicate the - particular measured values. However, because of the way the particular - intervals are measured, the user should be careful how - bu_measured.b_time is used. For example, if the filter - is installed to trigger an upcall if the number of packets is >= 1, then - bu_measured may have a value of zero in the upcalls - after the first one, because the measured interval for >= filters is - “clocked” by the forwarded packets. Hence, this upcall - mechanism should not be used for measuring the exact value of the bandwidth - of the forwarded data. To measure the exact bandwidth, the user would need - to get the forwarded packets statistics with the - (SIOCGETSGCNT) - mechanism (see the Programming - Guide section) .

-

Note that the upcalls for a filter are delivered until the - specific filter is deleted, but no more frequently than once per - bu_threshold.b_time. For example, if the filter is - specified to deliver a signal if bw >= 1 packet, the first packet will - trigger a signal, but the next upcall will be triggered no earlier than - bu_threshold.b_time after the previous upcall.

-
-
-
-

-

getsockopt(2), recvfrom(2), - recvmsg(2), setsockopt(2), - socket(2), sourcefilter(3), - altq(4), dummynet(4), - gif(4), gre(4), - icmp6(4), igmp(4), - inet(4), inet6(4), - intro(4), ip(4), - ip6(4), mld(4), - pim(4)

-
-
-

-

The Distance Vector Multicast Routing Protocol (DVMRP) was the - first developed multicast routing protocol. Later, other protocols such as - Multicast Extensions to OSPF (MOSPF) and Core Based Trees (CBT), were - developed as well. Routers at autonomous system boundaries may now exchange - multicast routes with peers via the Border Gateway Protocol (BGP). Many - other routing protocols are able to redistribute multicast routes for use - with PIM-SM and PIM-DM.

-
-
-

-

The original multicast code was written by David - Waitzman (BBN Labs), and later modified by the following individuals: - Steve Deering (Stanford), Mark J. - Steiglitz (Stanford), Van Jacobson (LBL), - Ajit Thyagarajan (PARC), Bill - Fenner (PARC). The IPv6 multicast support was implemented by the KAME - project (https://www.kame.net), and was based on the - IPv4 multicast code. The advanced multicast API and the multicast bandwidth - monitoring were implemented by Pavlin Radoslavov - (ICSI) in collaboration with Chris Brown (NextHop). - The IGMPv3 and MLDv2 multicast support was implemented by - Bruce Simpson.

-

This manual page was written by Pavlin - Radoslavov (ICSI).

-
-
- - - - - -
February 13, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/mvs.4 3.html b/static/freebsd/man4/mvs.4 3.html deleted file mode 100644 index e7aadf71..00000000 --- a/static/freebsd/man4/mvs.4 3.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - -
MVS(4)Device Drivers ManualMVS(4)
-
-
-

-

mvs — Marvell - Serial ATA Host Controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device mvs
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
mvs_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hint.mvs.X.msi
-
controls Message Signaled Interrupts (MSI) usage by the specified - controller.
-
hint.mvs.X.ccc
-
controls Command Completion Coalescing (CCC) usage by the specified - controller. Non-zero value enables CCC and defines maximum time (in us), - request can wait for interrupt. CCC reduces number of context switches on - systems with many parallel requests, but it can decrease disk performance - on some workloads due to additional command latency.
-
hint.mvs.X.cccc
-
defines number of completed commands for CCC, which trigger interrupt - without waiting for specified coalescing timeout.
-
hint.mvsch.X.pm_level
-
controls SATA interface Power Management for the specified channel, - allowing some power to be saved at the cost of additional command latency. - Possible values: -

-
-
-
0
-
interface Power Management is disabled (default);
-
1
-
device is allowed to initiate PM state change, host is passive;
-
4
-
driver initiates PARTIAL PM state transition 1ms after port becomes - idle;
-
5
-
driver initiates SLUMBER PM state transition 125ms after port becomes - idle.
-
-
-

Note that interface Power Management is not compatible with - device presence detection. A manual bus reset is needed on device - hot-plug.

-
-
hint.mvsch.X.sata_rev
-
setting to nonzero value limits maximum SATA revision (speed). Values 1, 2 - and 3 are respectively 1.5, 3 and 6Gbps.
-
-
-
-

-

This driver provides the CAM(4) subsystem with - native access to the SATA ports of several generations (Gen-I/II/IIe) of - Marvell SATA controllers. Each SATA port found is represented to CAM as a - separate bus with one target, or, if HBA supports Port Multipliers - (Gen-II/IIe), 16 targets. Most of the bus-management details are handled by - the SATA-specific transport of CAM. Connected ATA disks are handled by the - ATA protocol disk peripheral driver ada(4). ATAPI devices - are handled by the SCSI protocol peripheral drivers cd(4), - da(4), sa(4), etc.

-

Driver features include support for Serial ATA and ATAPI devices, - Port Multipliers (including FIS-based switching, when supported), hardware - command queues (up to 31 command per port), Native Command Queuing, SATA - interface Power Management, device hot-plug and Message Signaled - Interrupts.

-
-
-

-

The mvs driver supports the following - controllers:

-

Gen-I (SATA 1.5Gbps):

-
    -
  • 88SX5040
    • -
  • 88SX5041
    • -
  • 88SX5080
    • -
  • 88SX5081
    • -
-

Gen-II (SATA 3Gbps, NCQ, PMP):

-
    -
  • 88SX6040
    • -
  • 88SX6041 (including Adaptec 1420SA)
    • -
  • 88SX6080
    • -
  • 88SX6081
    • -
-

Gen-IIe (SATA 3Gbps, NCQ, PMP with FBS):

-
    -
  • 88SX6042
    • -
  • 88SX7042 (including Adaptec 1430SA)
    • -
  • 88F5182 SoC
    • -
  • 88F6281 SoC
    • -
  • MV78100 SoC
    • -
-

Note, that this hardware supports command queueing and FIS-based - switching only for ATA DMA commands. ATAPI and non-DMA ATA commands executed - one by one for each port.

-
-
-

-

ada(4), ata(4), - cam(4), cd(4), da(4), - sa(4)

-
-
-

-

The mvs driver first appeared in - FreeBSD 8.1.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org>

-
-
- - - - - -
March 23, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/mwl.4 3.html b/static/freebsd/man4/mwl.4 3.html deleted file mode 100644 index 4c593605..00000000 --- a/static/freebsd/man4/mwl.4 3.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - -
MWL(4)Device Drivers ManualMWL(4)
-
-
-

-

mwl — Marvell - 88W8363 IEEE 802.11n wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device mwl -
-device mwlfw -
-device wlan -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_mwl_load="YES"
-
-
-
-

-

The mwl driver provides support for IEEE - 802.11n wireless network adapters based on Marvell 88W8363 parts. PCI and/or - CardBus interfaces are supported.

-

This driver requires the firmware built with the - mwlfw module to work. Normally this module is loaded - on demand by the driver but it may also be compiled into the kernel.

-

Supported features include 802.11n, power management, BSS, MBSS, - and host-based access point operation modes. All host/device interaction is - via DMA.

-

The mwl driver encapsulates IP and ARP - traffic as 802.11 frames, however it can receive either 802.11 or 802.3 - frames. Devices support 802.11n, 802.11a, 802.11g, and 802.11b operation - with transmit speeds appropriate to each. The actual transmit speed used is - dependent on signal quality and the “rate control” algorithm - implemented in the firmware. All chips have hardware support for WEP, - AES-CCM, TKIP, and Michael cryptographic operations.

-

The driver supports station, - hostap, mesh, and - wds mode operation. Multiple - hostap virtual interfaces may be configured for - simultaneous use. When multiple interfaces are configured each may have a - separate mac address that is formed by setting the U/L bits in the mac - address assigned to the underlying device. Any number of - wds virtual interfaces may be configured together - with hostap interfaces. Multiple - station interfaces may be operated together with - hostap interfaces to construct a wireless repeater - device. For more information on configuring this device, see - ifconfig(8).

-

Devices supported by the mwl driver come - in either Cardbus or mini-PCI packages. Wireless cards in Cardbus slots may - be inserted and ejected on the fly.

-
-
-

-

Join an existing BSS network (ie: connect to an access point):

-
-
ifconfig wlan create wlandev mwl0 inet 192.168.0.20 \
-	netmask 0xffffff00"
-
-

Join a specific BSS network with network name - “my_net”:

-
-
ifconfig wlan create wlandev mwl0 inet 192.168.0.20 \
-	netmask 0xffffff00 ssid my_net"
-
-

Join a specific BSS network with WEP encryption:

-
-
ifconfig wlan0 create wlandev mwl0
-ifconfig wlan0 inet 192.168.0.20 netmask 0xffffff00 ssid my_net \
-	wepmode on wepkey 0x8736639624
-
-

Create an 802.11g host-based access point:

-
-
ifconfig wlan0 create wlandev mwl0 wlanmode hostap
-ifconfig wlan0 inet 192.168.0.10 netmask 0xffffff00 ssid my_ap \
-	mode 11g
-
-

Create an 802.11a mesh station:

-
-
ifconfig wlan0 create wlandev mwl0 wlanmode mesh
-ifconfig wlan0 meshid my_mesh mode 11a inet 192.168.0.10/24
-
-

Create two virtual 802.11a host-based access points, one with WEP - enabled and one with no security, and bridge them to the fxp0 (wired) - device:

-
-
ifconfig wlan0 create wlandev mwl0 wlanmode hostap \
-	ssid paying-customers wepmode on wepkey 0x1234567890 \
-	mode 11a up
-ifconfig wlan1 create wlandev mwl0 wlanmode hostap bssid \
-	ssid freeloaders up
-ifconfig bridge0 create addm wlan0 addm wlan1 addm fxp0 up
-
-
-
-

-
-
mwl%d: unable to setup builtin firmware
-
There was a problem downloading and/or setting up the firmware. The device - is not usable.
-
mwl%d: failed to setup descriptors: %d
-
There was a problem setting up the DMA data structures. This typically is - caused by not being able to allocate contiguous memory.
-
mwl%d: transmit timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. This should not happen.
-
mwl%d: device not present
-
A cardbus device was ejected while active; the request to the firmware was - not completed.
-
-
-
-

-

cardbus(4), intro(4), - mwlfw(4), pci(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - wlan_xauth(4), hostapd(8), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

The mwl device driver first appeared in - FreeBSD 8.0.

-
-
-

-

The driver does not support power-save operation in station mode; - consequently power use is suboptimal (e.g. on a laptop).

-
-
- - - - - -
July 8, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/mwlfw.4 4.html b/static/freebsd/man4/mwlfw.4 4.html deleted file mode 100644 index 7d146f52..00000000 --- a/static/freebsd/man4/mwlfw.4 4.html +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - -
MWLFW(4)Device Drivers ManualMWLFW(4)
-
-
-

-

mwlfw — Firmware - Module for Marvell 88W8363 Wireless driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device mwlfw
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
mwlfw_load="YES"
-
-
-
-

-

This module provides access to firmware sets for the Marvell - 88W8363 IEEE 802.11n wireless adapters. It may be statically linked into the - kernel, or loaded as a module.

-
-
-

-

mwl(4), firmware(9)

-
-
- - - - - -
June 9, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/mx25l.4 4.html b/static/freebsd/man4/mx25l.4 4.html deleted file mode 100644 index 5fe86c5b..00000000 --- a/static/freebsd/man4/mx25l.4 4.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - -
MX25L(4)Device Drivers ManualMX25L(4)
-
-
-

-

mx25l — SpiFlash - compatible non-volatile storage devices driver

-
-
-

-

device mx25l

-

In loader.conf(5): -
- mx25l_load="YES"

-
-
-

-

The mx25l driver provides support for the - family of non-volatile storage devices known collectively as SpiFlash(tm). - SpiFlash chips typically have part numbers beginning with EN25, IS25, MX25, - S25, SST25, or W25.

-

The mx25l driver uses opcode 0x9f to read - the manufacturer and device ID data to determine whether the device is - supported. The device ID is looked up using a table of data within the - driver which describes the attributes of each supported device, such as - block size, sector size, and device capacity. When a supported device is - found, the mx25l driver creates a disk device and - makes it accessible at /dev/flash/spi?. The new disk - device is then tasted by the available geom(4) modules as - with any disk device.

-
-
-

-

The mx25l driver supports the following - spi flash memory devices:

-

-
    -
  • AT25DF641
    • -
  • EN25F32
    • -
  • EN25P32
    • -
  • EN25P64
    • -
  • EN25Q32
    • -
  • EN25Q64
    • -
  • GD25Q64
    • -
  • M25P32
    • -
  • M25P64
    • -
  • MX25L1606E
    • -
  • MX25LL128
    • -
  • MX25LL256
    • -
  • MX25LL32
    • -
  • MX25LL64
    • -
  • N25Q64
    • -
  • S25FL032
    • -
  • S25FL064
    • -
  • S25FL128
    • -
  • S25FL256S
    • -
  • SST25VF010A
    • -
  • SST25VF032B
    • -
  • W25Q128
    • -
  • W25Q256
    • -
  • W25Q32
    • -
  • W25Q64
    • -
  • W25Q64BV
    • -
  • W25X32
    • -
  • W25X64
    • -
-
-
-

-

On an fdt(4) based system, the - mx25l device is defined as a slave device subnode of - the SPI bus controller node. All properties documented in the - spibus.txt bindings document can be used with the - mx25l device. The most commonly-used ones are - documented below.

-

The following properties are required in the - mx25l device subnode:

-
-
compatible
-
Must be the string "jedec,spi-nor".
-
reg
-
Chip select address of device.
-
spi-max-frequency
-
The maximum bus frequency to use when communicating with this slave - device. Actual bus speed may be lower, depending on the capabilities of - the SPI bus controller hardware.
-
-

The following properties are optional for the - mx25l device subnode:

-
-
spi-cpha
-
Empty property indicating the slave device requires shifted clock phase - (CPHA) mode.
-
spi-cpol
-
Empty property indicating the slave device requires inverse clock polarity - (CPOL) mode.
-
spi-cs-high
-
Empty property indicating the slave device requires chip select active - high.
-
-
-
-

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - mx25l:

-
-
hint.mx25l.%d.at
-
The spibus the mx25l instance is attached to.
-
hint.mx25l.%d.clock
-
The maximum bus frequency to use when communicating with this device. - Actual bus speed may be lower, depending on the capabilities of the SPI - bus controller hardware.
-
hint.mx25l.%d.cs
-
The chip-select number to assert when performing I/O for this device. Set - the high bit (1 << 31) to invert the logic level of the chip select - line.
-
hint.mx25l.%d.mode
-
The SPI mode (0-3) to use when communicating with this device.
-
-
-
-

-
-
/dev/flash/spi?
-
Provides read/write access to the storage device.
-
-
-
-

-

fdt(4), geom(4)

-
-
-

-

The mx25l driver first appeared in - FreeBSD 8.0.

-
-
- - - - - -
November 11, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/mxge.4 3.html b/static/freebsd/man4/mxge.4 3.html deleted file mode 100644 index 771031e5..00000000 --- a/static/freebsd/man4/mxge.4 3.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - -
MXGE(4)Device Drivers ManualMXGE(4)
-
-
-

-

mxge — Myricom - Myri10GE 10 Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device firmware -
-device mxge
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_mxge_load="YES"
-mxge_ethp_z8e_load="YES"
-mxge_eth_z8e_load="YES"
-mxge_rss_ethp_z8e_load="YES"
-mxge_rss_eth_z8e_load="YES"
-
-
-
-

-

The mxge driver provides support for PCI - Express 10 Gigabit Ethernet adapters based on the Myricom LANai Z8E chip. - The driver supports Transmit/Receive checksum offload, Jumbo Frames, TCP - segmentation offload (TSO) as well as Large Receive Offload (LRO). For - further hardware information, see - http://www.myri.com/.

-

For questions related to hardware requirements, refer to the - documentation supplied with your Myri10GE adapter. All hardware requirements - listed apply to use with FreeBSD.

-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames. The maximum MTU size for Jumbo Frames is 9000.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The mxge driver supports 10 Gigabit - Ethernet adapters based on the Myricom LANai Z8E chips:

-

-
    -
  • Myricom 10GBase-CX4 (10G-PCIE-8A-C, 10G-PCIE-8AL-C)
    • -
  • Myricom 10GBase-R (10G-PCIE-8A-R, 10G-PCIE-8AL-R)
    • -
  • Myricom 10G XAUI over ribbon fiber (10G-PCIE-8A-Q, 10G-PCIE-8AL-Q)
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.mxge.flow_control_enabled
-
Whether or not hardware flow control is enabled on the adapter. The - default value is 1.
-
hw.mxge.intr_coal_delay
-
This value delays the generation of all interrupts in units of 1 - microsecond. The default value is 30.
-
hw.mxge.skip_pio_read
-
This value determines whether or not the driver may omit doing a PIO read - in the interrupt handler which ensures that the interrupt line has been - deasserted when using xPIC interrupts. A non-zero value may result in - lower CPU overhead, however it may also result in spurious interrupts. The - default value is 0. This tunable has no effect when the device is using - MSI or MSI-X interrupts.
-
hw.mxge.max_slices
-
This value determines the maximum number of slices the driver will attempt - to use. The default value is 1. A slice is comprised of a set of receive - queues and an associated interrupt thread. When using multiple slices, the - NIC hashes traffic to different slices based on the value of - hw.mxge.rss_hashtype. Using multiple slices requires - that your motherboard and Myri10GE NIC both be capable of MSI-X. Older - Myri10GE NICs can be field upgraded to add MSI-X using the "10G NIC - Tool Kit" for FreeBSD which is available from - http://www.myri.com/scs/download-10g-tools.html.
-
hw.mxge.rss_hashtype
-
This value determines how incoming traffic is steered to different slices. - This tunable is ignored when using just a single slice. The legal values - for this tunable are: -
-
1
-
Hash on the source and destination IPv4 addresses.
-
2
-
Hash on source and destination IPv4 addresses and if the packet is - TCP, then also hash on the TCP source and destination ports.
-
4
-
Hash on the TCP or UDP source ports. This is the default value.
-
-
-
-
-
-

-
-
mxge%d: Unable to allocate bus resource: memory
-
A fatal initialization error has occurred.
-
mxge%d: Unable to allocate bus resource: interrupt
-
A fatal initialization error has occurred.
-
mxge%d: Could not find firmware image %s
-
The appropriate firmware kld module was not installed. This is a non-fatal - initialization error, but will result in running in a reduced performance - mode.
-
-
-
-

-

For general information and support, go to the Myricom support - website at: http://www.myri.com/scs/.

-

If an issue is identified with the released source code on the - supported kernel with a supported adapter, email the specific information - related to the issue to - <help@myri.com>.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The mxge device driver first appeared in - FreeBSD 6.3.

-
-
-

-

The mxge driver was written by - Andrew Gallatin - <gallatin@FreeBSD.org>.

-
-
- - - - - -
February 13, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/my.4 4.html b/static/freebsd/man4/my.4 4.html deleted file mode 100644 index 725f1189..00000000 --- a/static/freebsd/man4/my.4 4.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
MY(4)Device Drivers ManualMY(4)
-
-
-

-

my — Myson - Technology Ethernet PCI driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device my
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_my_load="YES"
-
-
-
-

-

The my driver provides support for various - NICs based on the Myson chipset. The Myson chipset is a variant of the DEC - Tulip NIC chipset.

-

The driver will work with almost any MII-compliant PHY, thus - failure to positively identify the chip is not a fatal error.

-
-
-

-

The my driver provides support for various - NICs based on the Myson chipset. Supported models include:

-

-
    -
  • Myson MTD800 PCI Fast Ethernet chip
    • -
  • Myson MTD803 PCI Fast Ethernet chip
    • -
  • Myson MTD89X PCI Gigabit Ethernet chip
    • -
-
-
-

-

altq(4), netintro(4), - pci(4), ifconfig(8)

-
-
-

-

The my driver first appeared in - FreeBSD 4.6.

-
-
-

-

The my driver was written by Myson - Technology Inc.

-

This manual page was written by Hiten M. - Pandya - <hmp@FreeBSD.org>.

-
-
-

-

The my driver does not support Power - Management Events (PME).

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/nctgpio.4 4.html b/static/freebsd/man4/nctgpio.4 4.html deleted file mode 100644 index 848c2e3d..00000000 --- a/static/freebsd/man4/nctgpio.4 4.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
NCTGPIO(4)Device Drivers ManualNCTGPIO(4)
-
-
-

-

nctgpio — GPIO - controller on Nuvoton and Winbond Super I/Os

-
-
-

-

device gpio -
- device nctgpio -
- device superio

-
-
-

-

The nctgpio is a driver for GPIO - controller that can be found in Nuvoton and Winbond Super I/O chips.

-

The nctgpio driver supports the following - chips:

-

-
    -
  • Nuvoton NCT5104D
    • -
  • Nuvoton NCT5104D (PC-Engines APU)
    • -
  • Nuvoton NCT5104D (PC-Engines APU3)
    • -
  • Nuvoton NCT5585D
    • -
  • Nuvoton NCT6116D
    • -
  • Nuvoton NCT6779
    • -
  • Nuvoton NCT6796D-E
    • -
  • Winbond 83627DHG
    • -
-

-
-
-

-

gpio(3), gpio(4), - gpioctl(8)

-
-
-

-

The driver first appeared in FreeBSD 11.0. - And the manual page first appeared in FreeBSD - 14.0.

-
-
-

-

The driver was initially written by Daniel - Wyatt - <daniel@dewyatt.com>. - This man page was written by -
- Stéphane Rochoy - <stephane.rochoy@stormshield.eu>.

-
-
- - - - - -
April 18, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/ncthwm.4 4.html b/static/freebsd/man4/ncthwm.4 4.html deleted file mode 100644 index 3293e99d..00000000 --- a/static/freebsd/man4/ncthwm.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
NCTHWM(4)Device Drivers ManualNCTHWM(4)
-
-
-

-

ncthwm — Hardware - monitoring controller on Nuvoton Super I/Os

-
-
-

-

device ncthwm -
- device superio

-
-
-

-

The ncthwm is a driver for hardware - monitoring controller that can be found in Nuvoton Super I/O chips. It - expose fan speed via sysctl(8).

-

-

The ncthwm driver supports the following - chips:

-

-
    -
  • Nuvoton NCT6779
    • -
  • Nuvoton NCT6796D-E
    • -
-

-
-
-

-

These variables are available as read-only - sysctl(8) variables:

-
-
dev.ncthwm.0.CPUFAN
-
CPU fan speed in RPM.
-
dev.ncthwm.0.SYSFAN
-
System fan speed in RPM.
-
dev.ncthwm.0.AUXFAN0
-
AUX0 fan speed in RPM.
-
dev.ncthwm.0.AUXFAN1
-
AUX1 fan speed in RPM.
-
dev.ncthwm.0.AUXFAN2
-
AUX2 fan speed in RPM.
-
-

-
-
-

-

The driver first appeared in FreeBSD - 14.0.

-
-
-

-

The driver was initially written by - Stéphane Rochoy - <stephane.rochoy@stormshield.eu>.

-
-
- - - - - -
April 18, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/nda.4 3.html b/static/freebsd/man4/nda.4 3.html deleted file mode 100644 index 5c44e4ce..00000000 --- a/static/freebsd/man4/nda.4 3.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - -
NDA(4)Device Drivers ManualNDA(4)
-
-
-

-

nda — NVMe Direct - Access device driver

-
-
-

-

device nvme -
- device scbus

-
-
-

-

The nda driver provides support for direct - access devices, implementing the NVMe command protocol, that are attached to - the system through a host adapter supported by the CAM subsystem.

-
-
-

-

The nda driver supports NVMe (Non-Volatile - Memory Express) storage devices connected via PCIe or over NVMF (NVMe over - Fabric) via the CAM subsystem.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.nvme.use_nvd
-
The nvme(4) driver will create - nda device nodes for block storage when set to 0. - Create nvd(4) device nodes for block storage when set to - 1. See nvd(4) when set to 1.
-
kern.cam.nda.nvd_compat
-
When set to 1, nvd(4) aliases will be created for all - nda devices, including partitions and other - geom(4) providers that take their names from the disk's - name. nvd(4) devices will not, however, be reported in - the kern.disks sysctl(8).
-
kern.cam.nda.sort_io_queue
-
This variable determines whether the software queued entries are sorted in - LBA order or not. Sorting is almost always a waste of time. The default is - to not sort.
-
kern.cam.nda.enable_biospeedup
-
This variable determines if the nda devices - participate in the speedup protocol. When the device participates in the - speedup, then when the upper layers send a - BIO_SPEEDUP, all current - BIO_DELETE requests not yet sent to the hardware are - completed successfully immediate without sending them to the hardware. - Used in low disk space scenarios when the filesystem encounters a critical - shortage and needs blocks immediately. Since trims have maximum benefit - when the LBA is unused for a long time, skipping the trim when space is - needed for immediate writes results in little to no excess wear. When - participation is disabled, BIO_SPEEDUP requests are - ignored.
-
kern.cam.nda.max_trim
-
The maximum number of LBA ranges to be collected together for each DSM - trims send to the hardware. Defaults to 256, which is the maximum number - of ranges the protocol supports. Sometimes poor trim performance can be - mitigated by limiting the number of ranges sent to the device. This value - must be between 1 and 256 inclusive.
-
-

The following report per-device settings, and are read-only unless - otherwise indicated. Replace N with the device unit - number.

-
-
kern.cam.nda.N.rotating
-
This variable reports whether the storage volume is spinning or flash. Its - value is hard coded to 0 indicating flash.
-
kern.cam.nda.N.unmapped_io
-
This variable reports whether the nda driver - accepts unmapped I/O for this unit.
-
kern.cam.nda.N.flags
-
This variable reports the current flags. -
-
OPEN
-
The device is open.
-
DIRTY
-
Set when a write to the drive is scheduled. Cleared after flush - commands.
-
SCTX_INIT
-
Internal flag set after sysctl(8) nodes have been - created.
-
-
-
kern.cam.nda.N.sort_io_queue
-
Same as the kern.cam.nda.sort_io_queue tunable.
-
kern.cam.nda.N.trim_ticks
-
Writable. When greater than zero, hold trims for up to this many ticks - before sending to the drive. Sometimes waiting a little bit to collect - more trims to send at one time improves trim performance. When 0, no - delaying of trims are done.
-
kern.cam.nda.N.trim_goal
-
Writable. When delaying a bit to collect multiple trims, send the - accumulated DSM TRIM to the drive.
-
kern.cam.nda.N.trim_lbas
-
Total number of LBAs that have been trimmed.
-
kern.cam.nda.N.trim_ranges
-
Total number of LBA ranges that have been trimmed.
-
kern.cam.nda.N.trim_count
-
Total number of trims sent to the hardware.
-
kern.cam.nda.N.deletes
-
Total number of BIO_DELETE requests queued to the - device.
-
-
-
-

-

Each nvme(4) drive has one or more namespaces - associated with it. One instance of the nda driver - will be created for each of the namespaces on the drive. All the - nda nodes for a nvme(4) device are - at target 0. However, the namespace ID maps to the CAM lun, as reported in - kernel messages and in the devlist sub command of - camcontrol(8).

-

Namespaces are managed with the ns sub - command of nvmecontrol(8). Not all drives support - namespace management, but all drives support at least one namespace. Device - nodes for nda will be created and destroyed - dynamically as namespaces are activated or detached.

-
-
-

-
-
/dev/nda*
-
NVMe storage device nodes
-
-
-
-

-

cam(4), geom(4), - nvd(4), nvme(4), - gpart(8)

-
-
-

-

The nda driver first appeared in - FreeBSD 12.0.

-
-
-

-

Warner Losh - <imp@FreeBSD.org>

-
-
- - - - - -
October 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/net80211.4 3.html b/static/freebsd/man4/net80211.4 3.html deleted file mode 100644 index d5a68a24..00000000 --- a/static/freebsd/man4/net80211.4 3.html +++ /dev/null @@ -1,987 +0,0 @@ - - - - - - -
NET80211(4)Device Drivers ManualNET80211(4)
-
-
-

-

net80211 — - standard interface to IEEE 802.11 devices

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <net/if.h> -
- #include <net/ethernet.h> -
- #include - <net80211/ieee80211_ioctl.h>

-
-
-

-

This section describes the standard programming interface to - configure and retrieve status information for IEEE 802.11 devices that - depend on the wlan(4) module for operation. The interface - is via one of the following ioctl(2) calls on a - socket:

-
-
-
Get configuration or status information.
-
-
Set configuration information.
-
-

These requests are made via a modified ifreq - structure. This structure is defined as follows:

-
-
struct ieee80211req {
-	char		i_name[IFNAMSIZ];	/* if_name, e.g. "wi0" */
-	uint16_t	i_type;			/* req type */
-	int16_t		i_val;			/* Index or simple value */
-	int16_t		i_len;			/* Index or simple value */
-	void		*i_data;		/* Extra data */
-};
-
-

Requests that are not supported by the underlying device return -1 - and set the global variable errno to EOPNOTSUPP. - SIOCG80211 requests that return data to an - application place small values in i_val or in a - user-specified buffer pointed to by i_data. When an - indirect buffer is used i_len specifies how large the - indirect buffer is and on return it is set by the system to the actual - amount of data returned. SIOCS80211 requests use a - similar scheme with data passed to the system taken either from - i_val or an indirect buffer pointed to by - i_data.

-

For SIOCG80211 the following values of - i_type are valid:

-
-
-
Return whether or not AMPDU is enabled in i_val. - AMPDU is an aggregation scheme that is part of the 802.11n specification - and is used only when operating on an HT channel. The value returned is - one of: 0 (AMPDU disabled), 1 (AMPDU enabled for transmit), 2 (AMPDU - enabled for receive), and 3 (AMPDU enabled for transmit and receive). The - 802.11n specification says a compliant station must receive AMPDU but may - not support transmitting AMPDU frames. Disabling AMPDU receive is mainly - useful for testing and working around bugs.
-
-
Return the minimum density for bursting AMPDU frames in - i_val. The value returned is one of: 0 (no time - restriction), 1 (1/4 usec), 2 (1/2 usec), 3 (1 usec), 4 (2 usec), 5 (4 - usec), 6 (8 usec), and 7 (16 usec).
-
-
Return the limit on the size of AMPDU frames in - i_val. The value returned is one of: 0 (8 - kilobytes), 1 (16 kilobytes), 2 (32 kilobytes), and 3 (64 kilobytes).
-
-
Return whether or not AMSDU is enabled in i_val. - AMSDU is an aggregation scheme that is part of the 802.11n specification - and is used only when operating on an HT channel. The value returned is - one of: 0 (AMSDU disabled), 1 (AMSDU enabled for transmit), 2 (AMSDU - enabled for receive), and 3 (AMSDU enabled for transmit and receive). The - 802.11n specification says a compliant station must receive AMSDU but may - not support transmitting AMSDU frames. Disabling AMSDU receive is mainly - useful for testing and working around bugs.
-
-
Return the limit on the size of AMSDU frames in - i_val. The value returned is one of: 3839 (bytes) - and 7935 (bytes). Note these values are specified by 802.11n; arbitrary - values are not allowed.
-
-
Return whether AP bridging is enabled in i_val. - Normally packets sent between stations associated to the same access point - are delivered without going through system layers that do packet - filtering; when AP bridging is disabled packets are passed up the system - to be forwarded using some other mechanism. This value will be non-zero - when AP bridging is enabled and otherwise zero.
-
-
Return an application information element via - i_data. Application IE's are maintained for many - 802.11 frames; the request must identify the frame to return an IE for in - i_val. For example, to retrieve the IE sent in each - Beacon frame i_val would be set to - IEEE80211_FC0_SUBTYPE_BEACON | - IEEE80211_FC0_TYPE_MGT. If no information element is - installed then EINVAL is returned. If the data - buffer for returning data is too small to hold the information element the - value is truncated; this permits querying the presence of data by - requesting zero bytes of data be returned.
-
-
Return the current authentication mode in i_val. - Valid values are IEEE80211_AUTH_NONE (no - authentication), IEEE80211_AUTH_OPEN (open - authentication), IEEE80211_AUTH_SHARED (shared key - authentication), IEEE80211_AUTH_8021X (802.1x only - authentication), and IEEE80211_AUTH_WPA - (WPA/802.11i/802.1x authentication).
-
-
Return the time between Beacon frames (in TU) in - i_val.
-
-
Return whether background scanning is enabled in - i_val. When this value is non-zero and operating in - station mode the station will periodically leave the current channel and - scan for neighboring stations. See also - IEEE80211_IOC_BGSCAN_IDLE and - IEEE80211_IOC_BGSCAN_INTERVAL.
-
-
Return in i_val the minimum time (msecs) a station - must be idle (i.e. not transmitting or receiving frames) before it will do - a background scan. See also - IEEE80211_IOC_BGSCAN_INTERVAL.
-
-
Return in i_val the minimum time (seconds) between - background scan operations. See also - IEEE80211_IOC_BGSCAN_IDLE.
-
-
Return in i_val the number of consecutive missed - Beacon frames before the system will attempt to roam to a different/better - access point.
-
-
Return the MAC address for the current BSS identifier via - i_data. When the interface is running, the bssid is - either the value configured locally (e.g. for an IBSS network started by - the local station) or the value adopted when joining an existing network. - For WDS interfaces this value is the address of the remote station. When - the interface is not running, the bssid returned is the desired bssid, if - any, that has been configured.
-
-
Return whether or not packet bursting is enabled in - i_val. If this value is non-zero then the system - will try to send packets closely spaced to improve throughput.
-
-
Return the set of available channels via i_data. - Note this data should be used by user applications to map between channel - specifications (frequency and attributes) and IEEE channel numbers as user - applications may not have the necessary information to do this directly - (e.g. for 900MHz radios, operation in the Public Safety Band).
-
-
Return the current list of usable channels via - i_data. The channel list is returned as a bit vector - with bit N set to 1 if IEEE channel number N is available for use.
-
-
Return the IEEE channel number of the current channel in - i_val. Note this request is deprecated; use - IEEE80211_IOC_CURCHAN instead.
-
-
Return whether TKIP Countermeasures are enabled in - i_val. This value will be non-zero when - Countermeasures are enabled and otherwise zero.
-
-
Return information for the current channel via - i_data. This information includes the IEEE channel - number, the frequency, and attributes that describe the operating - constraints (e.g. Passive Scan, DFS, usage restrictions).
-
-
Return device capabilities in the data buffer pointed at by - i_data. The buffer must be large enough to return - the number of available channels but otherwise may be made small to limit - how much information is returned.
-
-
Return whether or not Dynamic Frequency Selection (DFS) is enabled in - i_val. DFS embodies several facilities including - detection of overlapping radar signals, dynamic transmit power control, - and channel selection according to a least-congested criteria. DFS support - is mandatory for some 5GHz frequencies in certain locales (e.g. ETSI). By - default DFS is enabled according to the regulatory definitions and the - current country code, regdomain, and channel.
-
-
Return whether or not 802.11d support is enabled in - i_val. When 802.11d is enabled in station mode, - Beacon frames that advertise a country code different than the currently - configured country code will cause an event to be dispatched to user - applications. This event can be used by the station to adopt that country - code and operate according to the associated regulatory constraints. When - operating as an access point with 802.11d enabled the Beacon and - ProbeResponse frames transmitted will advertise the current regulatory - domain settings.
-
-
Return whether 802.11h support is enabled in i_val. - When 802.11h is enabled Beacon and ProbeResponse frames will have the - SpectrumMgt bit set in the capabilities field and country and power - constraint information elements will be present. 802.11h support also - includes handling Channel Switch Announcements (CSA) which are a mechanism - to coordinate channel changes by an access point. By default 802.11h is - enabled if the device is capable.
-
-
Return, in i_val, whether unencrypted packets - transmit/received should be discarded. This value will be zero if - unencrypted packets will be accepted and non-zero if they are to be - discarded.
-
-
Return the period (in beacon intervals) between DTIM events in - i_val.
-
-
Return, in i_val, whether or not Dynamic WDS support - is enabled. Dynamic WDS is a facility by which packets may be tunneled - over normal Infrastructure BSS associations using 4-address (WDS) - frames.
-
-
Return, in i_val, whether Atheros fast-frames - support is enabled. Fast-frames is a non-standard protocol extension that - aggregates multiple frames to improve throughput. Note that enabling - fast-frames support does not guarantee use; the client and access point - must negotiate its use.
-
-
Return, in i_val, the threshold (in bytes) for - enabling fragmentation frames. Packets larger than this value will - automatically be split into multiple fragmented frames that are sent one - after the other.
-
-
Return, in i_val, whether or not Greenfield preamble - use is enabled. This setting is meaningful only when operating with - 802.11n on an HT channel.
-
-
Return, in i_val, whether SSID hiding/cloaking is - enabled. SSID hiding is only meaningful when operating as an access point. - When this is enabled Beacon frames do not include the SSID and - ProbeRequest frames are not answered unless they include the AP's SSID. - This value will be non-zero when SSID hiding is enabled and otherwise - zero.
-
-
Return, in i_val, whether or not 802.11n - compatibility support is enabled. The 802.11n protocol specification went - through several incompatible iterations. Some vendors implemented 11n - support to older specifications that will not interoperate with a purely - 11n-compliant station. In particular the information elements included in - management frames for old devices are different. When compatibility - support is enabled both standard and compatible data will be provided - and/or accepted.
-
-
Return the setting for automatic promotion of HT channels in - i_val. Promotion happens when the system must select - a channel and may choose between legacy, HT20, and HT40 operation (e.g. - when scanning). Valid values are: 0 (do not promote, use legacy), 1 - (promote to HT20), and 2 (promote to HT40).
-
-
Return, in i_val, the technique used to protect HT - frames in a mixed 802.11n network. Valid values are: - IEEE80211_PROTMODE_OFF (no protection enabled) and - IEEE80211_PROTMODE_RTSCTS (send RTS and wait for - CTS).
-
-
Return the maximum acceptable hop count in an HWMP path in - i_val.
-
-
Return the setting for Mesh root mode operation in - i_val. Valid values are: - IEEE80211_HWMP_ROOTMODE_DISABLED (root mode is - disabled), IEEE80211_HWMP_ROOTMODE_NORMAL (send - broadcast Path Request frames), - IEEE80211_HWMP_ROOTMODE_PROACTIVE (send broadcast - Path Request frames and force replies) and - IEEE80211_HWMP_ROOTMODE_RANN (send broadcast Root - Announcement (RANN) frames).
-
-
Return the underlying hardware device(9) name in the - buffer pointed to by i_data and the name length - including terminating NUL character in i_len. If the - buffer length is too small to hold the full name - EINVAL will be returned.
-
-
Return whether or not the system handles inactivity processing in - i_val. When inactivity processing is enabled the - system will track stations that have not transmitted frames and - periodically probe them to check if they are still present. Stations that - are inactive and do not respond to probes are dropped.
-
-
Return information about the state of the MAC address access control list - (ACL) system. There are two requests supported: - IEEE80211_MACCMD_POLICY (to retrieve the current - policy in i_val ), and - IEEE80211_MACCMD_LIST to retrieve the list - installed/active ACL's via i_data. The - wlan_acl(4) module must be installed and enabled or - EINVAL will be returned.
-
-
Return whether or not Mesh AP support is enabled in - i_val.
-
-
Return the Mesh ID in the buffer pointed to by - i_data.
-
-
Return whether or not packet forwarding support is enabled in - i_val.
-
-
Return the link metric protocol in the buffer pointed to by - i_data.
-
-
Return the path selection protocol in the buffer pointed to by - i_data.
-
-
Return information about the state of the Mesh routing tables. One request - is supported: IEEE80211_MESH_RTCMD_LIST to - retrieve the contents of the routing table in the buffer pointed to by - i_data.
-
-
Return, in i_val, the Mesh Time To Live (TTL) - setting installed in packets transmitted by this mesh node.
-
-
Return the number of SSIDs supported in i_val.
-
-
Return the number of WEP keys supported in - i_val.
-
-
Return the current powersaving mode in i_val. Valid - values are IEEE80211_POWERSAVE_OFF (power save - operation is disabled) and IEEE80211_POWERSAVE_ON - (power save operation is enabled).
-
-
Return the powersave sleep time in TU in i_val. This - value is also termed the listen interval and represents the maximum time a - station will sleep before waking to retrieve packets buffered by an access - point.
-
-
Return the current MLME setting for PRIVACY in - i_val. When PRIVACY is enabled all data packets must - be encrypted. This value will be zero if PRIVACY is disabled and non-zero - when PRIVACY is enabled.
-
-
Return the current 802.11g protection mode in i_val. - Protection is the mechanism used to safeguard 802.11b stations operating - on an 802.11g network. Valid values are - IEEE80211_PROTMODE_OFF (no protection enabled), - IEEE80211_PROTMODE_CTS (send CTS to yourself), and - IEEE80211_PROTMODE_RTSCTS (send RTS and wait for - CTS).
-
-
Return whether ``pure 11g'' mode is enabled in - i_val. This setting is meaningful only for access - point operation; when non-zero, 802.11b stations will not be allowed to - associate.
-
-
Return whether ``pure 11n'' mode is enabled in - i_val. This setting is meaningful only for access - point operation; when non-zero, legacy (non-11n capable) stations will not - be allowed to associate.
-
-
Return the regulatory state in the buffer pointed to by - i_data.
-
-
Return whether or not Reduced InterFrame Spacing (RIFS) is enabled in - i_val. This setting is meaningful only when - operating with 802.11n on an HT channel.
-
-
Return station roaming parameters in the buffer pointed to by - i_data.
-
-
Return the current roaming mode in i_val. Roaming - mode specifies which entity controls operation of the MLME state machine - when operating as a station in an Infrastructure BSS. Valid values are: - IEEE80211_ROAMING_DEVICE (driver/firmware is in - control), IEEE80211_ROAMING_AUTO (host 802.11 - layer is in control), and IEEE80211_ROAMING_MANUAL - (application is in control).
-
-
Return the threshold (in bytes) for enabling transmission of RTS frames in - i_val. Packets larger than this value will - automatically have an RTS frame sent preceding it to reduce the likelihood - of packet loss.
-
-
Return the current contents of the scan cache in the data area pointed to - by i_data.
-
-
Return in i_val how long (in seconds) results from a - scan operation will be considered valid. When scan results are no longer - valid and they are needed (e.g. to roam) the system will initiate a scan - operation to replenish the scan cache.
-
-
Return whether or not Short Guard Interval (SGI) is enabled in - i_val. Note SGI is only used when operating with - 802.11n on an HT channel.
-
-
Return the Spatial Multiplexing Power Save (SMPS) setting in - i_val. This setting is meaningful only when - operating with 802.11n on an HT channel. Valid values are: - IEEE80211_HTCAP_SMPS_DYNAMIC (Dynamic SMPS is - enabled), IEEE80211_HTCAP_SMPS_ENA (Static SMPS is - enabled), and IEEE80211_HTCAP_SMPS_OFF (SMPS is - disabled).
-
-
Return the requested SSID in the buffer pointed to by - i_data. If i_val is ≥ 0 - then the request refers to the configured value for that slot. Generally, - 0 is the only valid value, but some interfaces support more SSIDs.
-
-
Return information about the current state of the specified station(s) via - i_data. The MAC address of a single station may be - passed in or, if the broadcast address is supplied, information about all - stations will be returned. If a single station is requested and the MAC - address is unknown then ENOENT will be - returned.
-
-
Return collected statistics for the specified station via - i_data. The MAC address of the desired station is - passed in; if it is unknown ENOENT will be - returned.
-
-
Return any VLAN tag assigned to a station via - i_data.
-
-
Return the slot number for the station in i_val. - Slot number zero is the master station in a TDMA network.
-
-
Return the count of slots in the TDMA network in - i_val.
-
-
Return the length (in usecs) of the TDMA slot assigned to each station in - the network in i_val.
-
-
Return the number of superframes between Beacon frames in - i_val. A TDMA network with N slots and slot length T - has a superframe of NxT.
-
-
Return whether or not Transitional Security Network (TSN) is enabled in - i_val.
-
-
Return whether Atheros Dynamic Turbo mode is enabled in - i_val. Dynamic Turbo mode is a non-standard protocol - extension available only on Atheros devices where channel width is - dynamically changed between 20MHz and 40MHz. Note that enabling Dynamic - Turbo mode support does not guarantee use; both client and access point - must use Atheros devices and support must be enabled on both sides.
-
-
Return transmit parameters in the buffer pointed to by - i_data.
-
-
Return the transmit power limit in .5 dBm units in - i_val. This value represents the effective maximum - and is calculated according to the maximum power allowed by local - regulations, any user-specified power limit, and the maximum power the - device is capable of.
-
-
Return the user-specified maximum transmit power in .5 dBm units in - i_val. The maximum setting is applied after any - regulatory cap.
-
-
Return the current WEP status in i_val. Valid values - are: IEEE80211_WEP_ON (enabled for all packets - sent and received), IEEE80211_WEP_OFF (disabled), - and IEEE80211_WEP_MIXED (enabled for transmit and - receive but also willing to receive unencrypted frames). This request is - deprecated; use IEEE80211_IOC_PRIVACY and - IEEE80211_IOC_UNENCRYPTED instead.
-
-
Return the requested WEP key via i_data. The key - number is specified in i_val and may be 0-3. If the - device does not support returning the WEP key or the user is not root then - the key may be returned as all zeros. This request is deprecated in favor - of IEEE80211_IOC_WPAKEY.
-
-
Return the number of the WEP key used for transmission in - i_val.
-
-
Return whether 802.11e/WME/WMM support is enabled in - i_val. This value will be non-zero when support is - enabled and otherwise zero.
-
-
Return the WME CWmin setting (log2) for the specified Access Class (AC) in - i_val. The AC is passed in through - i_len together with an optional - IEEE80211_WMEPARAM_BSS flag to indicate if the parameter for the BSS or - the channel is desired. If WME is not supported then - EINVAL will be returned.
-
-
Return the WME CWmax setting (log2) for the specified Access Class (AC) in - i_val. See - IEEE80211_IOC_WME_CWMIN above for more - details.
-
-
Return the WME AIFS setting for the specified Access Class (AC) in - i_val. See - IEEE80211_IOC_WME_CWMIN above for more - details.
-
-
Return the WME TxOpLimit (msec) for the specified Access Class (AC) in - i_val. See - IEEE80211_IOC_WME_CWMIN above for more - details.
-
-
Return the WME Admission Control Mechanism (ACM) setting for the specified - Access Class (AC) in i_val. This value is meaningful - only for the BSS (not channel). See - IEEE80211_IOC_WME_CWMIN above for more - details.
-
-
Return the WME ACK Policy setting for the specified Access Class (AC) in - i_val. When this value is zero frames will be - transmitted without waiting for an Acknowledgement. This value is - meaningful only for the channel (not BSS). See - IEEE80211_IOC_WME_CWMIN above for more - details.
-
-
Return the WPA configuration in i_val. Valid values - are 0 (WPA is not enabled), 1 (WPA1 is enabled), 2 (WPA2/802.11i is - enabled), and 3 (WPA1 and WPA2/802.11i are both enabled).
-
-
Return any WPA information element for an associated station via - i_data. The request passed in through - i_data identifies the MAC address of the desired - station. If an RSN (802.11i) element is present it is returned; otherwise - any WPA element is returned. Note this request is deprecated; use - IEEE80211_IOC_WPAIE2 instead.
-
-
Return any WPA information elements for an associated station via - i_data. The request passed in through - i_data identifies the MAC address of the desired - station. One or both of RSN (802.11i) and WPA elements may be - returned.
-
-
Return the requested cryptographic key in the buffer pointed to by - i_data. The key number is specified in - i_val and may be 0-3. A key number of zero is used - to retrieve a station's unicast cipher key when operating with WPA - enabled. If the user is not root then the key data returned is all - zeros.
-
-
Return whether or not Wi-FI Protected Setup (WPS) is enabled in - i_val.
-
-

For SIOCS80211 the following values of - i_type are valid. Note that changing a value on an - interface that is running may cause the interface to be - ‘reset’. Resets may be handled without altering the state if - the parameter does not affect the MLME state (e.g. RTS threshold), but in - some cases the interface may need to scan for a new network or clear state - (including any associated stations); in that case the interface is said to - be ‘restarted’ (it is equivalent to marking the interface down - and back up). The information below identifies whether changing a value - affects the state of a running interface.

-
-
-
Add an entry to the MAC address Access Control List (ACL) database using - the value pointed to by i_data. The - wlan_acl(4) module must be installed and enabled or - EINVAL will be returned.
-
-
Set whether or not AMPDU is enabled for transmit and/or receive using the - value in i_val. This request causes a running - interface operating on an HT channel to be reset. See - IEEE80211_IOC_AMPDU above for details.
-
-
Set the minimum density for bursting AMPDU frames to the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_AMPDU_DENSITY above for - details.
-
-
Set the limit on the size of AMPDU frames to the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_AMPDU_LIMIT above for - details.
-
-
Set whether or not AMSDU is enabled for transmit and/or receive using the - value in i_val. This request causes a running - interface operating on an HT channel to be reset. See - IEEE80211_IOC_AMSDU above for details.
-
-
Set the limit on the size of AMSDU frames to the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_AMSDU_LIMIT above for - details.
-
-
Set whether AP bridging is enabled using the value in - i_val. See - IEEE80211_IOC_APBRIDGE above for details.
-
-
Set an application information element using the data pointed to by - i_data. This request causes a running interface to - be restarted if the WPA information element is changed. See - IEEE80211_IOC_APPIE above for details.
-
-
Set the current authentication mode using the value in - i_val. This request causes a running interface to be - restarted. See IEEE80211_IOC_AUTHMODE above for - details. This request causes a running interface to be restarted.
-
-
Set the time between Beacon frames (in TU) to the value in - i_val. This request causes a running interface to be - restarted.
-
-
Set whether background scanning is enabled using the value in - i_val.
-
-
Set the minimum time (in msecs) a station must be idle before it will do a - background scan to the value in i_val.
-
-
Set the minimum time (seconds) between background scan operations to the - value in i_val.
-
-
Set the number of consecutive missed Beacon frames before the system will - attempt to roam to the value in i_val. This request - causes a running interface to be reset.
-
-
Set the 802.11 MAC address for the desired BSS identifier according to - i_data. This request causes a running interface to - be restarted.
-
-
Set whether or not packet bursting is enabled using the value in - i_val. This request causes a running interface to be - reset.
-
-
Set the desired/current channel to the value given by - i_val. This request causes a running interface to - immediately change to the specified channel if possible; otherwise the - interface will be restarted. Note this request is deprecated; use - IEEE80211_IOC_CURCHAN instead.
-
-
Set the list of available channels using the channel list pointed to by - i_data. The channel list is a bit vector with bit N - set to 1 if IEEE channel number N is available for use. The specified - channel list is checked against the set of supported channels and any - channels not supported are silently ignored. If the intersection of the - channel list and the supported channels is empty - EINVAL is returned. Note the current channel may - be marked invalid after installing a new channel list. This request causes - a running interface to be restarted.
-
-
Set whether TKIP Countermeasures are enabled using the value in - i_val. This request can only be used when the - authentication mode is set WPA; otherwise - EOPNOTSUPP will be returned.
-
-
Set the current channel using the information referenced by - i_data. This request causes a running interface to - immediately change to the specified channel if possible; otherwise the - interface will be restarted.
-
-
Delete the key specified by the information referenced by - i_data.
-
-
Remove an entry in the MAC address Access Control List (ACL) database - using the value pointed to by i_data. The - wlan_acl(4) module must be installed and enabled or - EINVAL will be returned.
-
-
Set whether or not Dynamic Frequency Selection (DFS) is enabled using the - value in i_val. This request will fail with - EINVAL if 802.11h support is not enabled. See - IEEE80211_IOC_DFS above for details.
-
-
Set whether or not 802.11d support is enabled using the value in - i_val. This request causes a running interface to be - restarted. See IEEE80211_IOC_DOTD above for - details.
-
-
Return whether 802.11h support is enabled using the value in - i_val. See - IEEE80211_IOC_DOTH above for details.
-
-
Set whether unencrypted packets transmit/received should be discarded - using the value in i_val.
-
-
Set the period (in beacon intervals) between DTIM events to the value in - i_val. This request causes a running interface to be - restarted.
-
-
Set whether or not Dynamic WDS support is enabled using the value in - i_val. See - IEEE80211_IOC_DWDS above for details.
-
-
Set whether Atheros fast-frames support is enabled using the value in - i_val. This request causes a running interface to be - restarted. See IEEE80211_IOC_FF above for - details.
-
-
Set the threshold (in bytes) for enabling fragmentation frames using the - value in i_val. This request causes a running - interface to be reset. See - IEEE80211_IOC_FRAGTHRESHOLD above for - details.
-
-
Set whether or not Greenfield preamble use is enabled using the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_GREENFIELD above for - details.
-
-
Set whether SSID hiding/cloaking is enabled using the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_HIDESSID above for - details.
-
-
Set whether or not 802.11n compatibility support is enabled using the - value in i_val. This request causes a running - interface to be reset if operating on HT channel. See - IEEE80211_IOC_HTCOMPAT above for details.
-
-
Set automatic promotion of HT channels using the value in - i_val. This request causes a running interface to be - restarted. See IEEE80211_IOC_HTCONF above for - details.
-
-
Set the technique used to protect HT frames in a mixed 802.11n network - using the value in i_val. This request causes a - running interface to be reset. See - IEEE80211_IOC_HTPROTMODE above for details.
-
-
Set the maximum acceptable hop count in an HWMP path according to - i_val. Values must be in the range [0-255].
-
-
Set the Mesh root mode operation according to i_val. - Valid values are IEEE80211_HWMP_ROOTMODE_DISABLED - (root mode is disabled), - IEEE80211_HWMP_ROOTMODE_NORMAL (send broadcast - Path Request frames), - IEEE80211_HWMP_ROOTMODE_PROACTIVE (send broadcast - Path Request frames and force replies) and - IEEE80211_HWMP_ROOTMODE_RANN (send broadcast Root - Announcement (RANN) frames).
-
-
Set whether or not the system handles inactivity processing using the - value in i_val. When inactivity processing is - enabled the system will track stations that have not transmitted frames - and periodically probe them to check if they are still present. Stations - that are inactive and do not respond to probes are dropped.
-
-
Change the state of the MAC address Access Control List (ACL) system. - There are several requests supported: - IEEE80211_MACCMD_POLICY_OPEN (set the current - policy to disable ACL use), - IEEE80211_MACCMD_POLICY_ALLOW (set the current - policy to allow only addresses listed in the database), - IEEE80211_MACCMD_POLICY_DENY (set the current - policy to deny addresses listed in the database), - IEEE80211_MACCMD_POLICY_RADUS (set the current - policy to enable use of a RADIUS backend), - IEEE80211_MACCMD_FLUSH (flush all addresses from - the database), and IEEE80211_MACCMD_DETACH (detach - the ACL subsystem, disabling it). The wlan_acl(4) module - must be installed or EINVAL will be returned.
-
-
Set whether or not Mesh AP support is enabled using - i_val.
-
-
Set whether or not packet forwarding support is enabled using - i_val.
-
-
Set the Mesh ID using the value pointed to by - i_data. A Mesh ID can be up to - IEEE80211_MESHID_LEN bytes long.
-
-
Set the link metric protocol using the value pointed to by - i_data.
-
-
Set the path selection protocol using the value pointed to by - i_data.
-
-
Manipulate the state of the Mesh routing tables. Several requests are - supported: IEEE80211_MESH_RTCMD_FLUSH (flush the - contents of the routing table), - IEEE80211_MESH_RTCMD_ADD (add an entry for the MAC - address specified in i_data and start the Peer - discovery process), and - IEEE80211_MESH_RTCMD_DELETE (delete the entry - corresponding to the MAC address specified in i_data - ).
-
-
Set the Mesh Time To Live (TTL) setting installed in packets transmitted - by this mesh node using i_val.
-
-
Explicitly control the MLME state machine for a station using the MLME - request pointed to by i_data. There are several MLME - operations supported: IEEE80211_MLME_ASSOC - (request association to an access point), - IEEE80211_MLME_DIASSOC (diassociate the specified - station), IEEE80211_MLME_DEAUTH (deauthenticate - the specified station), IEEE80211_MLME_AUHORIZE - (mark the specified station authorized to pass data frames), - IEEE80211_MLME_UNAUTHORIZE (revoke the specified - station's ability to pass data frames), and - IEEE80211_MLME_AUTH (request authentication to an - access point). Note when this facility is used for stations operating in - infrastructure mode the roaming mode should be set to manual.
-
-
Set the current powersaving mode to the value in - i_val. See - IEEE80211_IOC_POWERSAVE above for valid values. - This request causes a running interface to be reset.
-
-
Set the powersave sleep time in TU to the value in - i_val. This request causes a running interface to be - reset.
-
-
Set the current MLME setting for PRIVACY using the value in - i_val. See - IEEE80211_IOC_PRIVACY above for details.
-
-
Set the current 802.11g protection mode to the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_PROTMODE above for - details. This request causes a running interface to be reset.
-
-
Set whether ``pure 11g'' mode is enabled using the value in - i_val. This request causes a running interface to be - restarted. See IEEE80211_IOC_PUREG above for - details.
-
-
Set whether ``pure 11n'' mode is enabled using the value in - i_val. This request causes a running interface to be - restarted. See IEEE80211_IOC_PUREN above for - details.
-
-
Set the regulatory state using the data referenced by - i_data. This request can only be issued when all - interfaces cloned from the underlying physical device are marked down; - otherwise EBUSY is returned. Note the new - regulatory data may invalidate any desired channel.
-
-
Set whether or not Reduced InterFrame Spacing (RIFS) is enabled using the - value in i_val. This setting is meaningful only when - operating with 802.11n on an HT channel. This request causes a running - interface to be reset.
-
-
Set station roaming parameters using the data pointed to by - i_data.
-
-
Set the current roaming mode to the value in i_val. - See IEEE80211_IOC_ROAMING above for details.
-
-
Set the threshold (in bytes) for enabling transmission of RTS frames to - the value in i_val. This request causes a running - interface to be reset. See - IEEE80211_IOC_RTSTHRESHOLD above for details.
-
-
Set the age (in seconds) that results from a scan operation will be - considered valid. When scan results are no longer valid and they are - needed (e.g. to roam) the system will initiate a scan operation to - replenish the scan cache.
-
-
Request a scan operation using the parameters pointed to by - i_val. The underlying device must be running or - ENXIO will be returned. Values for - sr_duration, sr_mindwell, and - sr_maxdwell shorter than 1 clock tick are rounded up - to a tick. If more SSID's are supplied than the system is capable of - handling the extra ones are silently ignored. If a scan operation is - already in progress the request will be (silently) ignored.
-
-
Cancel any pending/active scan operation.
-
-
Set whether or not Short Guard Interval (SGI) is enabled using the value - in i_val. Note SGI is only used when operating on an - HT (802.11n) channel. This request causes a running interface to be - reset.
-
-
Set the Spatial Multiplexing Power Save (SMPS) setting to the value in - i_val. This request causes a running interface to be - reset. See IEEE80211_IOC_SMPS above for - details.
-
-
Set the desired SSID using the value pointed to by - i_data. The string may be at most IEEE80211_NWID_LEN - bytes. This request causes a running interface to be restarted.
-
-
Clear accumulated statistics for the specified station.
-
-
Set the VLAN tag for the specified station using the information pointed - to by i_data.
-
-
Set the interval between Beacon frames to the value in - i_val. Values must be positive. This request causes - a running interface to be reset.
-
-
Set the current TDMA slot to the value in i_val. - Values must be in the range [0-slotcnt]. Slot 0 identifies the master in - the TDMA network; if it running it will immediately start sending Beacon - frames.
-
-
Set the number of slots in the TDMA network to the value in - i_val. This request causes a running interface to be - reset.
-
-
Set the length of the TDMA slot assigned to each station in the network to - the value in i_val. Slot lengths must be in the - range 200 usecs to 1024 milliseconds (though values outside the range - 1-200ms are unlikely to work well). This request causes a running - interface to be reset.
-
-
Set whether or not Transitional Security Network (TSN) is enabled using - the value in i_val.
-
-
Set whether Atheros Dynamic Turbo mode is enabled using the value in - i_val. This request causes a running interface to be - restarted.
-
-
Set transmit parameters using the data pointed to be - i_data. This request causes a running interface to - be restarted.
-
-
Set the maximum transmit power limit in .5 dBm units to the value in - i_val. This request causes a running interface to be - reset.
-
-
Set the current WEP mode to the value in i_val. See - IEEE80211_IOC_WEP above for valid values. This - request causes a running interface to be restarted. Note this request is - deprecated; use IEEE80211_IOC_PRIVACY and - IEEE80211_IOC_DROPUNENCRYPTED instead.
-
-
Set the WEP key indicated by i_val using the data - pointed to by i_data. Note this request is - deprecated; use IEEE80211_IOC_WPAKEY instead.
-
-
Set the default transmit key used for transmission to the value in - i_val.
-
-
Set whether or not WME/WMM support is enabled using the value in - i_val. This request causes a running interface to be - reset.
-
-
Set the WME ACK Policy for the Access Class (AC) specified in - i_len using the value in - i_val.
-
-
Set the WME Admission Control Mechanism for the Access Class (AC) - specified in i_len using the value in - i_val.
-
-
Set the WME AIFS parameter for the Access Class (AC) specified in - i_len using the value in - i_val.
-
-
Set the WME CWmax parameter for the Access Class (AC) specified in - i_len using the value in - i_val.
-
-
Set the WME CWmin parameter for the Access Class (AC) specified in - i_len using the value in - i_val.
-
-
Set the WME TxOpLimit parameter for the Access Class (AC) specified in - i_len using the value in - i_val.
-
-
Set the WPA configuration using the value in i_val. - This request causes a running interface to be reset. See - IEEE80211_IOC_WPA above for details.
-
-
Set the requested cryptographic key using data in the buffer pointed to by - i_data. See - IEEE80211_IOC_WPAKEY for details.
-
-
Set whether or not Wi-FI Protected Setup (WPS) is enabled using the value - in i_val.
-
-
-
-

-

ioctl(2), wlan(4), - wlan_acl(4), wlan_xauth(4), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
- - - - - -
August 7, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/netdump.4 3.html b/static/freebsd/man4/netdump.4 3.html deleted file mode 100644 index 4e1edece..00000000 --- a/static/freebsd/man4/netdump.4 3.html +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - -
NETDUMP(4)Device Drivers ManualNETDUMP(4)
-
-
-

-

netdump — protocol - for transmitting kernel dumps to a remote server

-
-
-

-

To compile netdump client support into the kernel, place the - following lines in your kernel configuration file:

-
options INET -
-options DEBUGNET -
-options NETDUMP
-
-
-

-

netdump is a UDP-based protocol for transmitting kernel dumps to a - remote host. A netdump client is a panicking kernel, and a netdump server is - a host running the netdump daemon, available in - ports as ports/ftp/netdumpd. - netdump clients are configured using the - dumpon(8) utility or the netdump - command in ddb(4).

-

netdump client messages consist of a - fixed-size header followed by a variable-sized payload. The header contains - the message type, a sequence number, the offset of the payload data in the - kernel dump, and the length of the payload data (not including the header). - The message types are HERALD, - FINISHED, KDH, - VMCORE, and EKCD_KEY. - netdump server messages have a fixed size and - contain only the sequence number of the client message. These messages - indicate that the server has successfully processed the client message with - the corresponding sequence number. All client messages are acknowledged this - way. Server messages are always sent to port 20024 of the client.

-

To initiate a netdump, the client sends a - HERALD message to the server at port 20023. The - client may include a relative path in its payload, in which case the - netdump server should attempt to save the dump at - that path relative to its configured dump directory. The server will - acknowledge the HERALD using a random source port, - and the client must send all subsequent messages to that port.

-

The KDH, VMCORE, - and EKCD_KEY message payloads contain the kernel - dump header, dump contents, and dump encryption key respectively. The offset - in the message header should be treated as a seek offset in the - corresponding file. There are no ordering requirements for these - messages.

-

A netdump is completed by sending the - FINISHED message to the server.

-

The following network drivers support netdump: - alc(4), bge(4), - bnxt(4), bxe(4), - cxgb(4), em(4), - igb(4), ix(4), ixl(4), - mlx4en(4), mlx5en(4), - re(4), vtnet(4).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - variables:

-
-
net.netdump.debug
-
Control debug message verbosity. Debug messages are disabled by default, - but are useful when troubleshooting or when developing driver - support.
-
net.netdump.path
-
Specify a path relative to the server's dump directory in which to store - the dump. For example, if the netdump server is - configured to store dumps in /var/crash, a path of - “foo” will cause the server to attempt to store dumps from - the client in /var/crash/foo. The server will not - automatically create the relative directory.
-
net.netdump.polls
-
The client will poll the configured network interface while waiting for - acknowledgements. This parameter controls the maximum number of poll - attempts before giving up, which typically results in a re-transmit. Each - poll attempt takes 0.5ms.
-
net.netdump.retries
-
The number of times the client will re-transmit a packet before aborting a - dump due to a lack of acknowledgement. The default may be too small in - environments with lots of packet loss.
-
net.netdump.arp_retries
-
The number of times the client will attempt to learn the MAC address of - the configured gateway or server before giving up and aborting the - dump.
-
-
-
-

-

decryptcore(8), dumpon(8), - savecore(8)

-
-
-

-

netdump client support first appeared in - FreeBSD 12.0.

-
-
-

-

Only IPv4 is supported.

-

netdump may only be used after the kernel - has panicked.

-
-
- - - - - -
November 10, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/netfpga10g_nf10bmac.4 4.html b/static/freebsd/man4/netfpga10g_nf10bmac.4 4.html deleted file mode 100644 index 0fdfdb1c..00000000 --- a/static/freebsd/man4/netfpga10g_nf10bmac.4 4.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - -
NETFPGA10G_NF10BMAC(4)Device Drivers ManualNETFPGA10G_NF10BMAC(4)
-
-
-

-

netfpga10g_nf10bmac — - driver for the NetFPGA-10G Embedded CPU Ethernet - Core

-
-
-

-

device netfpga10g_nf10bmac

-
-
-

-

The netfpga10g_nf10bmac device driver - provides support for the NetFPGA-10G Embedded CPU Ethernet Core.

-
-
-

-

The current version of the - netfpga10g_nf10bmac driver works with one PIO mode - interface of the NetFPGA-10G Embedded CPU Ethernet Core version 1.00a.

-
-
-

-

netintro(4), ifconfig(8)

-

NetFPGA-10G Wiki, - https://github.com/NetFPGA/NetFPGA-public/wiki.

-
-
-

-

The netfpga10g_nf10bmac device driver - first appeared in FreeBSD 11.0.

-
-
-

-

This software and this manual page were developed by SRI - International and the University of Cambridge Computer Laboratory under - DARPA/AFRL contract (FA8750-11-C-0249) (“MRC2”), as part of - the DARPA MRC research programme. The device driver was written by - Bjoern A. Zeeb.

-
-
- - - - - -
April 17, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/netgdb.4 3.html b/static/freebsd/man4/netgdb.4 3.html deleted file mode 100644 index fc77e133..00000000 --- a/static/freebsd/man4/netgdb.4 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
NETGDB(4)Device Drivers ManualNETGDB(4)
-
-
-

-

netgdb — protocol - for debugging the kernel with GDB over the network

-
-
-

-

To compile NetGDB support into the kernel, place the following - lines in your kernel configuration file:

-
options DDB -
-options GDB -
-options INET -
-options DEBUGNET -
-options NETGDB
-
-
-

-

netgdb is a UDP-based protocol for - communicating with a remote GDB client via an intermediary proxy.

-

A netgdb session is started by using the - netgdb -s - server [-g - gateway -c - client -i - iface] command in ddb(4) to connect - to a proxy server. When the connection is made, the proxy server logs a - message that a netgdb client has connected. It - subsequently establishes a TCP listening socket and logs a message - specifying which port it is listening on. Then it waits for a GDB client to - connect. The GDB command to connect is:

-
target remote - ⟨proxyip:proxyport⟩
-

At this point, the server proxies traffic back and forth between - netgdb and the ordinary GDB client, speaking the - ordinary GDB remote protocol. The netgdb session is - identical to any other kernel GDB session from the perspective of the GDB - debugger.

-
-
-

-

The UDP protocol is based on the same packet structure and a - subset of the exact same message types as netdump(4). It - uses the HERALD, DATA - (née VMCORE), and - FINISHED message types. Like - netdump(4), the client's initial - HERALD message is acknowledged from a random source - port, and the client sends subsequent communication to that port.

-

Unlike netdump(4), the initial - HERALD port is 20025. Additionally, the proxy server - sends responses to the source port of the client's initial - HERALD, rather than a separate reserved port. - netgdb message and acknowledgements are - bidirectional. The sequence number and acknowledgement protocol is otherwise - identical to the unidirectional version used by netdump; it just runs in - both directions. Acknowledgements are sent to and from the same addresses - and ports as regular messages.

-

The first version of the netgdb protocol - uses the protocol number ‘0x2515f095’ in the 32-bit - aux2 parameter of the initial - HERALD message.

-

The list of supported network drivers and protocol families is - identical to that of netdump(4).

-
-
-

-

The following variable is available via both - sysctl(8) and loader(8) (as a - tunable):

-
-
debug.gdb.netgdb.debug
-
Control debug message verbosity. Debug messages are disabled by default. - They may be enabled by setting the variable to a non-zero value.
-
-
-
-

-

ddb(4), gdb(4), - netdump(4)

-
-
-

-

netgdb first appeared in - FreeBSD 13.0.

-
-
-

-

netgdb may only be used after the kernel - has panicked, due to limitations in the treatment of locking primitives - under ddb(4).

-
-
-

-

Version 1 of the netgdb protocol has no - security properties whatsoever. All messages are sent and acknowledged in - cleartext, and no message authentication codes are used to prevent attackers - from forging messages. It is absolutely inappropriate for use across the - public internet.

-
-
- - - - - -
November 10, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/netgraph.4 3.html b/static/freebsd/man4/netgraph.4 3.html deleted file mode 100644 index c3d615fa..00000000 --- a/static/freebsd/man4/netgraph.4 3.html +++ /dev/null @@ -1,1023 +0,0 @@ - - - - - - -
NETGRAPH(4)Device Drivers ManualNETGRAPH(4)
-
-
-

-

netgraph — graph - based kernel networking subsystem

-
-
-

-

The netgraph system provides a uniform and - modular system for the implementation of kernel objects which perform - various networking functions. The objects, known as nodes, - can be arranged into arbitrarily complicated graphs. Nodes have - hooks which are used to connect two nodes together, - forming the edges in the graph. Nodes communicate along the edges to process - data, implement protocols, etc.

-

The aim of netgraph is to supplement - rather than replace the existing kernel networking infrastructure. It - provides:

-

-
    -
  • A flexible way of combining protocol and link level drivers.
    • -
  • A modular way to implement new protocols.
    • -
  • A common framework for kernel entities to inter-communicate.
    • -
  • A reasonably fast, kernel-based implementation.
    • -
-
-

-

The most fundamental concept in netgraph - is that of a - . All - nodes implement a number of predefined methods which allow them to interact - with other nodes in a well defined manner.

-

Each node has a - , which is a - static property of the node determined at node creation time. A node's type - is described by a unique ASCII type name. The type implies what the node - does and how it may be connected to other nodes.

-

In object-oriented language, types are classes, and nodes are - instances of their respective class. All node types are subclasses of the - generic node type, and hence inherit certain common functionality and - capabilities (e.g., the ability to have an ASCII name).

-

Nodes may be assigned a globally unique ASCII name which can be - used to refer to the node. The name must not contain the characters - ‘.’ or - ‘:’, and is limited to - NG_NODESIZ characters (including the terminating - NUL character).

-

Each node instance has a unique - which is - expressed as a 32-bit hexadecimal value. This value may be used to refer to - a node when there is no ASCII name assigned to it.

-
-
-

-

Nodes are connected to other nodes by connecting a pair of - hooks, one from each node. Data flows bidirectionally - between nodes along connected pairs of hooks. A node may have as many hooks - as it needs, and may assign whatever meaning it wants to a hook.

-

Hooks have these properties:

-
    -
  • A hook has an ASCII name which is unique among all hooks on that node - (other hooks on other nodes may have the same name). The name must not - contain the characters ‘.’ or - ‘:’, and is limited to - NG_HOOKSIZ characters (including the terminating - NUL character).
    • -
  • A hook is always connected to another hook. That is, hooks are created at - the time they are connected, and breaking an edge by removing either hook - destroys both hooks.
    • -
  • A hook can be set into a state where incoming packets are always queued by - the input queueing system, rather than being delivered directly. This can - be used when the data is sent from an interrupt handler, and processing - must be quick so as not to block other interrupts.
    • -
  • A hook may supply overriding receive data and receive message functions, - which should be used for data and messages received through that hook in - preference to the general node-wide methods.
    • -
-

A node may decide to assign special meaning to some hooks. For - example, connecting to the hook named debug might - trigger the node to start sending debugging information to that hook.

-
-
-

-

Two types of information flow between nodes: data messages and - control messages. Data messages are passed in mbuf - chains along the edges in the graph, one edge at a time. The first - mbuf in a chain must have the - M_PKTHDR flag set. Each node decides how to handle - data received through one of its hooks.

-

Along with data, nodes can also receive control messages. There - are generic and type-specific control messages. Control messages have a - common header format, followed by type-specific data, and are binary - structures for efficiency. However, node types may also support conversion - of the type-specific data between binary and ASCII formats, for debugging - and human interface purposes (see the - NGM_ASCII2BINARY and - NGM_BINARY2ASCII generic control messages below). - Nodes are not required to support these conversions.

-

There are three ways to address a control message. If there is a - sequence of edges connecting the two nodes, the message may be - “source routed” by specifying the corresponding sequence of - ASCII hook names as the destination address for the message (relative - addressing). If the destination is adjacent to the source, then the source - node may simply specify (as a pointer in the code) the hook across which the - message should be sent. Otherwise, the recipient node's global ASCII name - (or equivalent ID-based name) is used as the destination address for the - message (absolute addressing). The two types of ASCII addressing may be - combined, by specifying an absolute start node and a sequence of hooks. Only - the ASCII addressing modes are available to control programs outside the - kernel; use of direct pointers is limited to kernel modules.

-

Messages often represent commands that are followed by a reply - message in the reverse direction. To facilitate this, the recipient of a - control message is supplied with a “return address” that is - suitable for addressing a reply.

-

Each control message contains a 32-bit value, called a - “typecookie”, indicating the type of the message, i.e. how to - interpret it. Typically each type defines a unique typecookie for the - messages that it understands. However, a node may choose to recognize and - implement more than one type of messages.

-

If a message is delivered to an address that implies that it - arrived at that node through a particular hook (as opposed to having been - directly addressed using its ID or global name) then that hook is identified - to the receiving node. This allows a message to be re-routed or passed on, - should a node decide that this is required, in much the same way that data - packets are passed around between nodes. A set of standard messages for flow - control and link management purposes are defined by the base system that are - usually passed around in this manner. Flow control message would usually - travel in the opposite direction to the data to which they pertain.

-
-
-

-

In order to minimize latency, most - netgraph operations are functional. That is, data - and control messages are delivered by making function calls rather than by - using queues and mailboxes. For example, if node A wishes to send a data - mbuf to neighboring node B, it calls the generic - netgraph data delivery function. This function in - turn locates node B and calls B's “receive data” method. There - are exceptions to this.

-

Each node has an input queue, and some operations can - be considered to be - in that - they alter the state of the node. Obviously, in an SMP world it would be bad - if the state of a node were changed while another data packet were - transiting the node. For this purpose, the input queue implements a - - semantic so that when there is a writer in the node, all other requests are - queued, and while there are readers, a writer, and any following packets are - queued. In the case where there is no reason to queue the data, the input - method is called directly, as mentioned above.

-

A node may declare that all requests should be considered as - writers, or that requests coming in over a particular hook should be - considered to be a writer, or even that packets leaving or entering across a - particular hook should always be queued, rather than delivered directly - (often useful for interrupt routines who want to get back to the hardware - quickly). By default, all control message packets are considered to be - writers unless specifically declared to be a reader in their definition. - (See NGM_READONLY in - <netgraph/ng_message.h>.)

-

While this mode of operation results in good performance, it has a - few implications for node developers:

-
    -
  • Whenever a node delivers a data or control message, the node may need to - allow for the possibility of receiving a returning message before the - original delivery function call returns.
    • -
  • Netgraph provides internal synchronization between - nodes. Data always enters a “graph” at an edge - node. An edge node is a node that interfaces between - netgraph and some other part of the system. - Examples of “edge nodes” include device drivers, the - socket, ether, - tty, and ksocket node type. In - these edge nodes, the calling thread directly executes - code in the node, and from that code calls upon the - netgraph framework to deliver data across some - edge in the graph. From an execution point of view, the calling thread - will execute the netgraph framework methods, and - if it can acquire a lock to do so, the input methods of the next node. - This continues until either the data is discarded or queued for some - device or system entity, or the thread is unable to acquire a lock on the - next node. In that case, the data is queued for the node, and execution - rewinds back to the original calling entity. The queued data will be - picked up and processed by either the current holder of the lock when they - have completed their operations, or by a special - netgraph thread that is activated when there are - such items queued.
    • -
  • It is possible for an infinite loop to occur if the graph contains - cycles.
    • -
-

So far, these issues have not proven problematical in - practice.

-
-
-

-

A node may have a hidden interaction with other components of the - kernel outside of the netgraph subsystem, such as - device hardware, kernel protocol stacks, etc. In fact, one of the benefits - of netgraph is the ability to join disparate kernel - networking entities together in a consistent communication framework.

-

An example is the socket node type which is - both a netgraph node and a - socket(2) in the protocol family - PF_NETGRAPH. Socket nodes allow user processes to - participate in netgraph. Other nodes communicate - with socket nodes using the usual methods, and the node hides the fact that - it is also passing information to and from a cooperating user process.

-

Another example is a device driver that presents a node interface - to the hardware.

-
-
-

-

Nodes are notified of the following actions via function calls to - the following node methods, and may accept or reject that action (by - returning the appropriate error code):

-
-
Creation of a new node
-
The constructor for the type is called. If creation of a new node is - allowed, constructor method may allocate any special resources it needs. - For nodes that correspond to hardware, this is typically done during the - device attach routine. Often a global ASCII name corresponding to the - device name is assigned here as well.
-
Creation of a new hook
-
The hook is created and tentatively linked to the node, and the node is - told about the name that will be used to describe this hook. The node sets - up any special data structures it needs, or may reject the connection, - based on the name of the hook.
-
Successful connection of two hooks
-
After both ends have accepted their hooks, and the links have been made, - the nodes get a chance to find out who their peer is across the link, and - can then decide to reject the connection. Tear-down is automatic. This is - also the time at which a node may decide whether to set a particular hook - (or its peer) into the - - mode.
-
Destruction of a hook
-
The node is notified of a broken connection. The node may consider some - hooks to be critical to operation and others to be expendable: the - disconnection of one hook may be an acceptable event while for another it - may effect a total shutdown for the node.
-
Preshutdown of a node
-
This method is called before real shutdown, which is discussed below. - While in this method, the node is fully operational and can send a - “goodbye” message to its peers, or it can exclude itself - from the chain and reconnect its peers together, like the - ng_tee(4) node type does.
-
Shutdown of a node
-
This method allows a node to clean up and to ensure that any actions that - need to be performed at this time are taken. The method is called by the - generic (i.e., superclass) node destructor which will get rid of the - generic components of the node. Some nodes (usually associated with a - piece of hardware) may be - - in that a shutdown breaks all edges and resets the node, but does not - remove it. In this case, the shutdown method should not free its - resources, but rather, clean up and then call the - () - macro to signal the generic code that the shutdown is aborted. In the case - where the shutdown is started by the node itself due to hardware removal - or unloading (via - ()), - it should set the NGF_REALLY_DIE flag to signal to - its own shutdown method that it is not to persist.
-
-
-
-

-

Two other methods are also supported by all nodes:

-
-
Receive data message
-
A netgraph - , usually referred to as an item, is - received by this function. The item contains a pointer to an - mbuf. -

The node is notified on which hook the item has - arrived, and can use this information in its processing decision. The - receiving node must always - () - the mbuf chain on completion or error, or pass it - on to another node (or kernel module) which will then be responsible for - freeing it. Similarly, the item must be freed if it is - not to be passed on to another node, by using the - () - macro. If the item still holds references to mbufs - at the time of freeing then they will also be appropriately freed. - Therefore, if there is any chance that the mbuf - will be changed or freed separately from the item, it is very important - that it be retrieved using the - () - macro that also removes the reference within the item. (Or multiple - frees of the same object will occur.)

-

If it is only required to examine the contents of - the mbufs, then it is possible to use the - () - macro to both read and rewrite mbuf pointer inside - the item.

-

If developer needs to pass any meta information along with the - mbuf chain, he should use - mbuf_tags(9) framework.

-
Note that old netgraph specific - meta-data format is obsoleted now.
-

The receiving node may decide to defer the data by - queueing it in the netgraph NETISR system (see - below). It achieves this by setting the HK_QUEUE - flag in the flags word of the hook on which that data will arrive. The - infrastructure will respect that bit and queue the data for delivery at - a later time, rather than deliver it directly. A node may decide to set - the bit on the - node, so - that its own output packets are queued.

-

The node may elect to nominate a - different receive data function for data received on a particular hook, - to simplify coding. It uses the - (hook, - fn) macro to do this. The function receives the - same arguments in every way other than it will receive all (and only) - packets from that hook.

-
-
Receive control message
-
This method is called when a control message is addressed to the node. As - with the received data, an item is received, with a - pointer to the control message. The message can be examined using the - () - macro, or completely extracted from the item using the - () - which also removes the reference within the item. If the item still holds - a reference to the message when it is freed (using the - NG_FREE_ITEM() macro), then the message will also - be freed appropriately. If the reference has been removed, the node must - free the message itself using the - () - macro. A return address is always supplied, giving the address of the node - that originated the message so a reply message can be sent anytime later. - The return address is retrieved from the item using the - () - macro and is of type ng_ID_t. All control messages - and replies are allocated with the malloc(9) type - M_NETGRAPH_MSG, however it is more convenient to - use the - () - and - () - macros to allocate and fill out a message. Messages must be freed using - the NG_FREE_MSG() macro. -

If the message was delivered via a specific hook, that hook - will also be made known, which allows the use of such things as - flow-control messages, and status change messages, where the node may - want to forward the message out another hook to that on which it - arrived.

-

The node may elect to nominate a - different receive message function for messages received on a particular - hook, to simplify coding. It uses the - (hook, - fn) macro to do this. The function receives the - same arguments in every way other than it will receive all (and only) - messages from that hook.

-
-
-

Much use has been made of reference counts, so that nodes being - freed of all references are automatically freed, and this behaviour has been - tested and debugged to present a consistent and trustworthy framework for - the “type module” writer to use.

-
-
-

-

The netgraph framework provides an - unambiguous and simple to use method of specifically addressing any single - node in the graph. The naming of a node is independent of its type, in that - another node, or external component need not know anything about the node's - type in order to address it so as to send it a generic message type. Node - and hook names should be chosen so as to make addresses meaningful.

-

Addresses are either absolute or relative. An absolute address - begins with a node name or ID, followed by a colon, followed by a sequence - of hook names separated by periods. This addresses the node reached by - starting at the named node and following the specified sequence of hooks. A - relative address includes only the sequence of hook names, implicitly - starting hook traversal at the local node.

-

There are a couple of special possibilities for the node name. The - name ‘.’ (referred to as - ‘.:’) always refers to the local node. - Also, nodes that have no global name may be addressed by their ID numbers, - by enclosing the hexadecimal representation of the ID number within the - square brackets. Here are some examples of valid - netgraph addresses:

-
-
.:
-[3f]:
-foo:
-.:hook1
-foo:hook1.hook2
-[d80]:hook1
-
-

The following set of nodes might be created for a site with a - single physical frame relay line having two active logical DLCI channels, - with RFC 1490 frames on DLCI 16 and PPP frames over DLCI 20:

-
-
[type SYNC ]                  [type FRAME]                 [type RFC1490]
-[ "Frame1" ](uplink)<-->(data)[<un-named>](dlci16)<-->(mux)[<un-named>  ]
-[    A     ]                  [    B     ](dlci20)<---+    [     C      ]
-                                                      |
-                                                      |      [ type PPP ]
-                                                      +>(mux)[<un-named>]
-                                                             [    D     ]
-
-

One could always send a control message to node C from anywhere by - using the name “Frame1:uplink.dlci16”. - In this case, node C would also be notified that the message reached it via - its hook mux. Similarly, - “Frame1:uplink.dlci20” could reliably - be used to reach node D, and node A could refer to node B as - “.:uplink”, or simply - “uplink”. Conversely, B can refer to A - as “data”. The address - “mux.data” could be used by both nodes - C and D to address a message to node A.

-

Note that this is only for - . - In each of these cases, where a relative addressing mode is used, the - recipient is notified of the hook on which the message arrived, as well as - the originating node. This allows the option of hop-by-hop distribution of - messages and state information. Data messages are - - routed one hop at a time, by specifying the departing hook, with each node - making the next routing decision. So when B receives a frame on hook - data, it decodes the frame relay header to determine - the DLCI, and then forwards the unwrapped frame to either C or D.

-

In a similar way, flow control messages may be routed - in the reverse direction to outgoing data. For example a “buffer - nearly full” message from - “Frame1:” would be passed to node B - which might decide to send similar messages to both nodes C and D. The nodes - would use addressing to route the messages. The message may have - travelled from “Frame1:” to B as a - synchronous reply, saving time and cycles.

-
-
-

-

Structures are defined in - <netgraph/netgraph.h> (for - kernel structures only of interest to nodes) and - <netgraph/ng_message.h> (for - message definitions also of interest to user programs).

-

The two basic object types that are of interest to node authors - are nodes and hooks. These two objects - have the following properties that are also of interest to the node - writers.

-
-
struct ng_node
-
Node authors should always use the following - typedef to declare their pointers, and should - never actually declare the structure. -

typedef struct ng_node *node_p;

-

The following properties are associated with a node, and can - be accessed in the following manner:

-
-
Validity
-
A driver or interrupt routine may want to check whether the node is - still valid. It is assumed that the caller holds a reference on the - node so it will not have been freed, however it may have been disabled - or otherwise shut down. Using the - (node) - macro will return this state. Eventually it should be almost - impossible for code to run in an invalid node but at this time that - work has not been completed.
-
Node ID (ng_ID_t)
-
This property can be retrieved using the macro - (node).
-
Node name
-
Optional globally unique name, NUL terminated - string. If there is a value in here, it is the name of the node. -
- 
if (NG_NODE_NAME(node)[0] != '\0') ...
-
-if (strcmp(NG_NODE_NAME(node), "fred") == 0) ...
-
-
-
A node dependent opaque cookie
-
Anything of the pointer type can be placed here. The macros - (node, - value) and - (node) - set and retrieve this property, respectively.
-
Number of hooks
-
The - (node) - macro is used to retrieve this value.
-
Hooks
-
The node may have a number of hooks. A traversal method is provided to - allow all the hooks to be tested for some condition. - (node, - fn, arg, - rethook) where fn is a - function that will be called for each hook with the form - (hook, - arg) and returning 0 to terminate the search. If - the search is terminated, then rethook will be - set to the hook at which the search was terminated.
-
-
-
struct ng_hook
-
Node authors should always use the following - typedef to declare their hook pointers. -

typedef struct ng_hook *hook_p;

-

The following properties are associated with a hook, and can - be accessed in the following manner:

-
-
A hook dependent opaque cookie
-
Anything of the pointer type can be placed here. The macros - (hook, - value) and - (hook) - set and retrieve this property, respectively.
-
An associate node
-
The macro - (hook) - finds the associated node.
-
A peer hook (hook_p)
-
The other hook in this connected pair. The - (hook) - macro finds the peer.
-
References
-
The - (hook) - and - (hook) - macros increment and decrement the hook reference count accordingly. - After decrement you should always assume the hook has been freed - unless you have another reference still valid.
-
Override receive functions
-
The - NG_HOOK_SET_RCVDATA(hook, - fn) and - NG_HOOK_SET_RCVMSG(hook, - fn) macros can be used to set override methods - that will be used in preference to the generic receive data and - receive message functions. To unset these, use the macros to set them - to NULL. They will only be used for data and - messages received on the hook on which they are set.
-
-

The maintenance of the names, reference - counts, and linked list of hooks for each node is handled automatically - by the netgraph subsystem. Typically a node's - private info contains a back-pointer to the node or hook structure, - which counts as a new reference that must be included in the reference - count for the node. When the node constructor is called, there is - already a reference for this calculated in, so that when the node is - destroyed, it should remember to do a - () - on the node.

-

From a hook you can obtain the corresponding node, and from a - node, it is possible to traverse all the active hooks.

-

A current example of how to define a node can always be seen - in src/sys/netgraph/ng_sample.c and should be - used as a starting point for new node writers.

-
-
-
-
-

-

Control messages have the following structure:

-
-
#define NG_CMDSTRSIZ    32      /* Max command string (including null) */
-
-struct ng_mesg {
-  struct ng_msghdr {
-    u_char      version;        /* Must equal NG_VERSION */
-    u_char      spare;          /* Pad to 4 bytes */
-    uint16_t    spare2;
-    uint32_t    arglen;         /* Length of cmd/resp data */
-    uint32_t    cmd;            /* Command identifier */
-    uint32_t    flags;          /* Message status flags */
-    uint32_t    token;          /* Reply should have the same token */
-    uint32_t    typecookie;     /* Node type understanding this message */
-    u_char      cmdstr[NG_CMDSTRSIZ];  /* cmd string +   */
-  } header;
-  char  data[];                 /* placeholder for actual data */
-};
-
-#define NG_ABI_VERSION  12              /* Netgraph kernel ABI version */
-#define NG_VERSION      8               /* Netgraph message version */
-#define NGF_ORIG        0x00000000      /* The msg is the original request */
-#define NGF_RESP        0x00000001      /* The message is a response */
-
-

Control messages have the fixed header shown above, followed by a - variable length data section which depends on the type cookie and the - command. Each field is explained below:

-
-
version
-
Indicates the version of the netgraph message - protocol itself. The current version is - NG_VERSION.
-
arglen
-
This is the length of any extra arguments, which begin at - data.
-
flags
-
Indicates whether this is a command or a response control message.
-
token
-
The token is a means by which a sender can match a - reply message to the corresponding command message; the reply always has - the same token.
-
typecookie
-
The corresponding node type's unique 32-bit value. If a node does not - recognize the type cookie it must reject the message by returning - EINVAL. -

Each type should have an include file that defines - the commands, argument format, and cookie for its own messages. The - typecookie ensures that the same header file was included by both sender - and receiver; when an incompatible change in the header file is made, - the typecookie - be changed. - The de-facto method for generating unique type cookies is to take the - seconds from the Epoch at the time the header file is written (i.e., the - output of “date - -u +%s”).

-

There is a predefined typecookie - NGM_GENERIC_COOKIE for the - generic node type, and a corresponding set of - generic messages which all nodes understand. The handling of these - messages is automatic.

-
-
cmd
-
The identifier for the message command. This is type specific, and is - defined in the same header file as the typecookie.
-
cmdstr
-
Room for a short human readable version of command - (for debugging purposes only).
-
-

Some modules may choose to implement messages from more than one - of the header files and thus recognize more than one type cookie.

-
-
-

-

Control messages are in binary format for efficiency. However, for - debugging and human interface purposes, and if the node type supports it, - control messages may be converted to and from an equivalent ASCII form. The - ASCII form is similar to the binary form, with two exceptions:

-
    -
  1. The cmdstr header field must contain the ASCII name - of the command, corresponding to the cmd header - field.
    2. -
  2. The arguments field contains a NUL-terminated - ASCII string version of the message arguments.
    3. -
-

In general, the arguments field of a control message can be any - arbitrary C data type. Netgraph includes parsing - routines to support some pre-defined datatypes in ASCII with this simple - syntax:

-
    -
  • Integer types are represented by base 8, 10, or 16 numbers.
    • -
  • Strings are enclosed in double quotes and respect the normal C language - backslash escapes.
    • -
  • IP addresses have the obvious form.
    • -
  • Arrays are enclosed in square brackets, with the elements listed - consecutively starting at index zero. An element may have an optional - index and equals sign (‘=’) - preceding it. Whenever an element does not have an explicit index, the - index is implicitly the previous element's index plus one.
    • -
  • Structures are enclosed in curly braces, and each field is specified in - the form fieldname=value.
    • -
  • Any array element or structure field whose value is equal to its - “default value” may be omitted. For integer types, the - default value is usually zero; for string types, the empty string.
    • -
  • Array elements and structure fields may be specified in any order.
    • -
-

Each node type may define its own arbitrary types by providing the - necessary routines to parse and unparse. ASCII forms defined for a specific - node type are documented in the corresponding man page.

-
-
-

-

There are a number of standard predefined messages that will work - for any node, as they are supported directly by the framework itself. These - are defined in - <netgraph/ng_message.h> - along with the basic layout of messages and other similar information.

-
-
-
Connect to another node, using the supplied hook names on either end.
-
-
Construct a node of the given type and then connect to it using the - supplied hook names.
-
-
The target node should disconnect from all its neighbours and shut down. - Persistent nodes such as those representing physical hardware might not - disappear from the node namespace, but only reset themselves. The node - must disconnect all of its hooks. This may result in neighbors shutting - themselves down, and possibly a cascading shutdown of the entire connected - graph.
-
-
Assign a name to a node. Nodes can exist without having a name, and this - is the default for nodes created using the - NGM_MKPEER method. Such nodes can only be - addressed relatively or by their ID number.
-
-
Ask the node to break a hook connection to one of its neighbours. Both - nodes will have their “disconnect” method invoked. Either - node may elect to totally shut down as a result.
-
-
Asks the target node to describe itself. The four returned fields are the - node name (if named), the node type, the node ID and the number of hooks - attached. The ID is an internal number unique to that node.
-
-
This returns the information given by - NGM_NODEINFO, but in addition includes an array of - fields describing each link, and the description for the node at the far - end of that link.
-
-
This returns an array of node descriptions (as for - NGM_NODEINFO) where each entry of the array - describes a named node. All named nodes will be described.
-
-
This is the same as NGM_LISTNAMES except that all - nodes are listed regardless of whether they have a name or not.
-
-
This returns a list of all currently installed - netgraph types.
-
-
The node may return a text formatted status message. The status - information is determined entirely by the node type. It is the only - “generic” message that requires any support within the node - itself and as such the node may elect to not support this message. The - text response must be less than NG_TEXTRESPONSE - bytes in length (presently 1024). This can be used to return general - status information in human readable form.
-
-
This message converts a binary control message to its ASCII form. The - entire control message to be converted is contained within the arguments - field of the NGM_BINARY2ASCII message itself. If - successful, the reply will contain the same control message in ASCII form. - A node will typically only know how to translate messages that it itself - understands, so the target node of the - NGM_BINARY2ASCII is often the same node that would - actually receive that message.
-
-
The opposite of NGM_BINARY2ASCII. The entire - control message to be converted, in ASCII form, is contained in the - arguments section of the NGM_ASCII2BINARY and need - only have the flags, cmdstr, - and arglen header fields filled in, plus the - NUL-terminated string version of the arguments in - the arguments field. If successful, the reply contains the binary version - of the control message.
-
-
-
-

-

In addition to the control messages that affect nodes with respect - to the graph, there are also a number of - messages defined. At present these are - handled - automatically by the system, so nodes need to handle them if they are going - to be used in a graph utilising flow control, and will be in the likely path - of these messages. The default action of a node that does not understand - these messages should be to pass them onto the next node. Hopefully some - helper functions will assist in this eventually. These messages are also - defined in - <netgraph/ng_message.h> and - have a separate cookie NG_FLOW_COOKIE to help - identify them. They will not be covered in depth here.

-
-
-
-

-

The base netgraph code may either be - statically compiled into the kernel or else loaded dynamically as a KLD via - kldload(8). In the former case, include

-

-
options NETGRAPH
-

in your kernel configuration file. You may also include selected - node types in the kernel compilation, for example:

-

-
options NETGRAPH
-
options NETGRAPH_SOCKET
-
options NETGRAPH_ECHO
-

Once the netgraph subsystem is loaded, - individual node types may be loaded at any time as KLD modules via - kldload(8). Moreover, netgraph - knows how to automatically do this; when a request to create a new node of - unknown type type is made, - netgraph will attempt to load the KLD module - ng_⟨type⟩.ko.

-

Types can also be installed at boot time, as certain device - drivers may want to export each instance of the device as a - netgraph node.

-

In general, new types can be installed at any time - from within the kernel by calling - (), - supplying a pointer to the type's struct ng_type - structure.

-

The - () - macro automates this process by using a linker set.

-
-
-

-

Several node types currently exist. Each is fully documented in - its own man page:

-
-
SOCKET
-
The socket type implements two new sockets in the new protocol domain - PF_NETGRAPH. The new sockets protocols are - NG_DATA and NG_CONTROL, - both of type SOCK_DGRAM. Typically one of each is - associated with a socket node. When both sockets have closed, the node - will shut down. The NG_DATA socket is used for - sending and receiving data, while the NG_CONTROL - socket is used for sending and receiving control messages. Data and - control messages are passed using the sendto(2) and - recvfrom(2) system calls, using a struct - sockaddr_ng socket address.
-
HOLE
-
Responds only to generic messages and is a “black hole” for - data. Useful for testing. Always accepts new hooks.
-
ECHO
-
Responds only to generic messages and always echoes data back through the - hook from which it arrived. Returns any non-generic messages as their own - response. Useful for testing. Always accepts new hooks.
-
TEE
-
This node is useful for “snooping”. It has 4 hooks: - left, right, - left2right, and right2left. - Data entering from the right is passed to the - left and duplicated on - right2left, and data entering from the - left is passed to the right - and duplicated on left2right. Data entering from - left2right is sent to the - right and data from right2left - to left.
-
RFC1490 MUX
-
Encapsulates/de-encapsulates frames encoded according to RFC 1490. Has a - hook for the encapsulated packets (downstream) and - one hook for each protocol (i.e., IP, PPP, etc.).
-
FRAME RELAY MUX
-
Encapsulates/de-encapsulates Frame Relay frames. Has a hook for the - encapsulated packets (downstream) and one hook for - each DLCI.
-
FRAME RELAY LMI
-
Automatically handles frame relay “LMI” (link management - interface) operations and packets. Automatically probes and detects which - of several LMI standards is in use at the exchange.
-
TTY
-
This node is also a line discipline. It simply converts between - mbuf frames and sequential serial data, allowing a - TTY to appear as a netgraph node. It has a - programmable “hotkey” character.
-
ASYNC
-
This node encapsulates and de-encapsulates asynchronous frames according - to RFC 1662. This is used in conjunction with the TTY node type for - supporting PPP links over asynchronous serial lines.
-
ETHERNET
-
This node is attached to every Ethernet interface in the system. It allows - capturing raw Ethernet frames from the network, as well as sending frames - out of the interface.
-
INTERFACE
-
This node is also a system networking interface. It has hooks representing - each protocol family (IP, IPv6) and appears in the output of - ifconfig(8). The interfaces are named - “ng0”, - “ng1”, etc.
-
ONE2MANY
-
This node implements a simple round-robin multiplexer. It can be used for - example to make several LAN ports act together to get a higher speed link - between two machines.
-
Various PPP related nodes
-
There is a full multilink PPP implementation that runs in - netgraph. The net/mpd5 - port can use these modules to make a very low latency high capacity PPP - system. It also supports PPTP VPNs using the PPTP node.
-
PPPOE
-
A server and client side implementation of PPPoE. Used in conjunction with - either ppp(8) or the net/mpd5 - port.
-
BRIDGE
-
This node, together with the Ethernet nodes, allows a very flexible - bridging system to be implemented.
-
KSOCKET
-
This intriguing node looks like a socket to the system but diverts all - data to and from the netgraph system for further - processing. This allows such things as UDP tunnels to be almost trivially - implemented from the command line.
-
-

Refer to the section at the end of this man page for more nodes - types.

-
-
-

-

Whether a named node exists can be checked by trying to send a - control message to it (e.g., NGM_NODEINFO). If it - does not exist, ENOENT will be returned.

-

All data messages are mbuf chains with the - M_PKTHDR flag set.

-

Nodes are responsible for freeing what they allocate. There are - three exceptions:

-
    -
  1. Mbufs sent across a data link are never to be freed - by the sender. In the case of error, they should be considered freed.
    2. -
  2. Messages sent using one of - () - family macros are freed by the recipient. As in the case above, the - addresses associated with the message are freed by whatever allocated them - so the recipient should copy them if it wants to keep that - information.
    3. -
  3. Both control messages and data are delivered and - queued with a netgraph item. The - item must be freed using - (item) - or passed on to another node.
    4. -
-
-
-

-
-
<netgraph/netgraph.h>
-
Definitions for use solely within the kernel by - netgraph nodes.
-
<netgraph/ng_message.h>
-
Definitions needed by any file that needs to deal with - netgraph messages.
-
<netgraph/ng_socket.h>
-
Definitions needed to use netgraph - socket type nodes.
-
<netgraph/ng_>⟨type⟩.h
-
Definitions needed to use netgraph - type nodes, including the type cookie - definition.
-
/boot/kernel/netgraph.ko
-
The netgraph subsystem loadable KLD module.
-
/boot/kernel/ng_⟨type⟩.ko
-
Loadable KLD module for node type type.
-
src/sys/netgraph/ng_sample.c
-
Skeleton netgraph node. Use this as a starting - point for new node types.
-
-
-
-

-

There is a library for supporting user-mode programs that wish to - interact with the netgraph system. See - netgraph(3) for details.

-

Two user-mode support programs, ngctl(8) and - nghook(8), are available to assist manual configuration - and debugging.

-

There are a few useful techniques for debugging new node types. - First, implementing new node types in user-mode first makes debugging - easier. The tee node type is also useful for - debugging, especially in conjunction with ngctl(8) and - nghook(8).

-

Also look in /usr/share/examples/netgraph - for solutions to several common networking problems, solved using - netgraph.

-
-
-

-

socket(2), netgraph(3), - ng_async(4), ng_bluetooth(4), - ng_bpf(4), ng_bridge(4), - ng_btsocket(4), ng_car(4), - ng_cisco(4), ng_device(4), - ng_echo(4), ng_eiface(4), - ng_etf(4), ng_ether(4), - ng_frame_relay(4), ng_gif(4), - ng_gif_demux(4), ng_hci(4), - ng_hole(4), ng_hub(4), - ng_iface(4), ng_ip_input(4), - ng_ipfw(4), ng_ksocket(4), - ng_l2cap(4), ng_l2tp(4), - ng_lmi(4), ng_mppc(4), - ng_nat(4), ng_netflow(4), - ng_one2many(4), ng_patch(4), - ng_ppp(4), ng_pppoe(4), - ng_pptpgre(4), ng_rfc1490(4), - ng_socket(4), ng_split(4), - ng_tee(4), ng_tty(4), - ng_ubt(4), ng_UI(4), - ng_vjc(4), ng_vlan(4), - ngctl(8), nghook(8)

-
-
-

-

The netgraph system was designed and first - implemented at Whistle Communications, Inc. in a version of - FreeBSD 2.2 customized for the Whistle InterJet. It - first made its debut in the main tree in FreeBSD - 3.4.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>, - with contributions by Archie Cobbs - <archie@FreeBSD.org>.

-
-
- - - - - -
September 29, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/netintro.4 3.html b/static/freebsd/man4/netintro.4 3.html deleted file mode 100644 index d81157ce..00000000 --- a/static/freebsd/man4/netintro.4 3.html +++ /dev/null @@ -1,334 +0,0 @@ - - - - - - -
NETINTRO(4)Device Drivers ManualNETINTRO(4)
-
-
-

-

networking — - introduction to networking facilities

-
-
-

-

#include - <sys/types.h> -
- #include <sys/time.h> -
- #include <sys/socket.h> -
- #include <net/if.h> -
- #include <net/route.h>

-
-
-

-

This section is a general introduction to the networking - facilities available in the system. Documentation in this part of section 4 - is broken up into three areas: protocol families - (domains), - , - and .

-

All network protocols are associated with a specific - protocol family. A protocol family provides basic services - to the protocol implementation to allow it to function within a specific - network environment. These services may include packet fragmentation and - reassembly, routing, addressing, and basic transport. A protocol family may - support multiple methods of addressing, though the current protocol - implementations do not. A protocol family is normally comprised of a number - of protocols, one per socket(2) type. It is not required - that a protocol family support all socket types. A protocol family may - contain multiple protocols supporting the same socket abstraction.

-

A protocol supports one of the socket abstractions detailed in - socket(2). A specific protocol may be accessed either by - creating a socket of the appropriate type and protocol family, or by - requesting the protocol explicitly when creating a socket. Protocols - normally accept only one type of address format, usually determined by the - addressing structure inherent in the design of the protocol family/network - architecture. Certain semantics of the basic socket abstractions are - protocol specific. All protocols are expected to support the basic model for - their particular socket type, but may, in addition, provide non-standard - facilities or extensions to a mechanism. For example, a protocol supporting - the SOCK_STREAM abstraction may allow more than one - byte of out-of-band data to be transmitted per out-of-band message.

-

A network interface is similar to a device interface. Network - interfaces comprise the lowest layer of the networking subsystem, - interacting with the actual transport hardware. An interface may support one - or more protocol families and/or address formats. The SYNOPSIS section of - each network interface entry gives a sample specification of the related - drivers for use in providing a system description to the - config(8) program. The DIAGNOSTICS section lists messages - which may appear on the console and/or in the system error log, - /var/log/messages (see - syslogd(8)), due to errors in device operation.

-
-
-

-

The system currently supports the Internet protocols, the Xerox - Network Systems(tm) protocols, and some of the ISO OSI protocols. Raw socket - interfaces are provided to the IP protocol layer of the Internet, and to the - IDP protocol of Xerox NS. Consult the appropriate manual pages in this - section for more information regarding the support for each protocol - family.

-
-
-

-

Associated with each protocol family is an address format. All - network addresses adhere to a general structure, called a sockaddr, - described below. However, each protocol imposes finer and more specific - structure, generally renaming the variant, which is discussed in the - protocol family manual page alluded to above.

-
-
struct sockaddr {
-    u_char	sa_len;
-    u_char	sa_family;
-    char	sa_data[14];
-};
-
-

The field sa_len contains the total length - of the structure, which may exceed 16 bytes. The following address values - for sa_family are known to the system (and additional - formats are defined for possible future implementation):

-
-
#define    AF_UNIX      1    /* local to host (pipes, portals) */
-#define    AF_INET      2    /* internetwork: UDP, TCP, etc. */
-#define    AF_NS        6    /* Xerox NS protocols */
-#define    AF_CCITT     10   /* CCITT protocols, X.25 etc */
-#define    AF_HYLINK    15   /* NSC Hyperchannel */
-#define    AF_ISO       18   /* ISO protocols */
-
-
-
-

-

FreeBSD provides some packet routing - facilities. The kernel maintains a routing information database, which is - used in selecting the appropriate network interface when transmitting - packets.

-

A user process (or possibly multiple co-operating processes) - maintains this database by sending messages over a special kind of socket. - This supplants fixed size ioctl(2) used in earlier - releases.

-

This facility is described in route(4).

-
-
-

-

Each network interface in a system corresponds to a path through - which messages may be sent and received. A network interface usually has a - hardware device associated with it, though certain interfaces such as the - loopback interface, lo(4), do not.

-

The following ioctl(2) calls may be - used to manipulate network interfaces. The - () is - made on a socket (typically of type SOCK_DGRAM) in - the desired domain. Most of the requests supported in earlier releases take - an ifreq structure as its parameter. This structure - has the form

-
-
struct	ifreq {
-#define    IFNAMSIZ    16
-    char    ifr_name[IFNAMSIZ];        /* if name, e.g. "en0" */
-    union {
-        struct    sockaddr ifru_addr;
-        struct    sockaddr ifru_dstaddr;
-        struct    sockaddr ifru_broadaddr;
-        struct    ifreq_buffer ifru_buffer;
-        short     ifru_flags[2];
-        short     ifru_index;
-        int       ifru_metric;
-        int       ifru_mtu;
-        int       ifru_phys;
-        int       ifru_media;
-        caddr_t   ifru_data;
-        int       ifru_cap[2];
-    } ifr_ifru;
-#define ifr_addr      ifr_ifru.ifru_addr      /* address */
-#define ifr_dstaddr   ifr_ifru.ifru_dstaddr   /* other end of p-to-p link */
-#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
-#define ifr_buffer    ifr_ifru.ifru_buffer    /* user supplied buffer with its length */
-#define ifr_flags     ifr_ifru.ifru_flags[0]  /* flags (low 16 bits) */
-#define ifr_flagshigh ifr_ifru.ifru_flags[1]  /* flags (high 16 bits) */
-#define ifr_metric    ifr_ifru.ifru_metric    /* metric */
-#define ifr_mtu       ifr_ifru.ifru_mtu       /* mtu */
-#define ifr_phys      ifr_ifru.ifru_phys      /* physical wire */
-#define ifr_media     ifr_ifru.ifru_media     /* physical media */
-#define ifr_data      ifr_ifru.ifru_data      /* for use by interface */
-#define ifr_reqcap    ifr_ifru.ifru_cap[0]    /* requested capabilities */
-#define ifr_curcap    ifr_ifru.ifru_cap[1]    /* current capabilities */
-#define ifr_index     ifr_ifru.ifru_index     /* interface index */
-};
-
-

() - requests to obtain addresses and requests both to set and retrieve other - data are still fully supported and use the ifreq - structure:

-
-
-
Get interface address for protocol family.
-
-
Get point to point address for protocol family and interface.
-
-
Get broadcast address for protocol family and interface.
-
-
Attempt to set the enabled capabilities field for the interface to the - value of the ifr_reqcap field of the - ifreq structure. Note that, depending on the - particular interface features, some capabilities may appear hard-coded to - enabled, or toggling a capability may affect the status of other ones. The - supported capabilities field is read-only, and the - ifr_curcap field is unused by this call.
-
-
Get the interface capabilities fields. The values for supported and - enabled capabilities will be returned in the - ifr_reqcap and ifr_curcap - fields of the ifreq structure, respectively.
-
-
Get the interface description, returned in the - buffer field of ifru_buffer - struct. The user supplied buffer length should be defined in the - length field of ifru_buffer - struct passed in as parameter, and the length would include the - terminating nul character. If there is not enough space to hold the - interface length, no copy would be done and the - buffer field of ifru_buffer - would be set to NULL. The kernel will store the buffer length in the - length field upon return, regardless whether the - buffer itself is sufficient to hold the data.
-
-
Set the interface description to the value of the - buffer field of ifru_buffer - struct, with length field specifying its length - (counting the terminating nul).
-
-
Set interface flags field. If the interface is marked down, any processes - currently routing packets through the interface are notified; some - interfaces may be reset so that incoming packets are no longer received. - When marked up again, the interface is reinitialized.
-
-
Get interface flags.
-
-
Set interface routing metric. The metric is used only by user-level - routers.
-
-
Get interface metric.
-
-
Attempt to create the specified interface. If the interface name is given - without a unit number the system will attempt to create a new interface - with an arbitrary unit number. On successful return the - ifr_name field will contain the new interface - name.
-
-
Attempt to destroy the specified interface.
-
-

There are two requests that make use of a new structure:

-
-
-
An interface may have more than one address associated with it in some - protocols. This request provides a means to add additional addresses (or - modify characteristics of the primary address if the default address for - the address family is specified). Rather than making separate calls to set - destination or broadcast addresses, or network masks (now an integral - feature of multiple protocols) a separate structure is used to specify all - three facets simultaneously (see below). One would use a slightly tailored - version of this struct specific to each family (replacing each sockaddr by - one of the family-specific type). Where the sockaddr itself is larger than - the default size, one needs to modify the - () - identifier itself to include the total size, as described in - ioctl().
-
-
This requests deletes the specified address from the list associated with - an interface. It also uses the ifaliasreq structure - to allow for the possibility of protocols allowing multiple masks or - destination addresses, and also adopts the convention that specification - of the default address means to delete the first address for the interface - belonging to the address family in which the original socket was - opened.
-
-
This request provides means to get additional addresses together with - netmask and broadcast/destination from an interface. It also uses the - ifaliasreq structure.
-
-
Get interface configuration list. This request takes an - ifconf structure (see below) as a value-result - parameter. The ifc_len field should be initially set - to the size of the buffer pointed to by ifc_buf. On - return it will contain the length, in bytes, of the configuration - list.
-
-
Get list of clonable interfaces. This request takes an - if_clonereq structure (see below) as a value-result - parameter. The ifcr_count field should be set to the - number of IFNAMSIZ sized strings that can be fit - in the buffer pointed to by ifcr_buffer. On return, - ifcr_total will be set to the number of clonable - interfaces and the buffer pointed to by ifcr_buffer - will be filled with the names of clonable interfaces aligned on - IFNAMSIZ boundaries.
-
-
-
/*
-* Structure used in SIOCAIFADDR request.
-*/
-struct ifaliasreq {
-        char    ifra_name[IFNAMSIZ];   /* if name, e.g. "en0" */
-        struct  sockaddr        ifra_addr;
-        struct  sockaddr        ifra_broadaddr;
-        struct  sockaddr        ifra_mask;
-};
-
-
-
/*
-* Structure used in SIOCGIFCONF request.
-* Used to retrieve interface configuration
-* for machine (useful for programs which
-* must know all networks accessible).
-*/
-struct ifconf {
-    int   ifc_len;		/* size of associated buffer */
-    union {
-        caddr_t    ifcu_buf;
-        struct     ifreq *ifcu_req;
-    } ifc_ifcu;
-#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
-#define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
-};
-
-
-
/* Structure used in SIOCIFGCLONERS request. */
-struct if_clonereq {
-        int     ifcr_total;     /* total cloners (out) */
-        int     ifcr_count;     /* room for this many in user buffer */
-        char    *ifcr_buffer;   /* buffer for cloner names */
-};
-
-
-
/* Structure used in SIOCGIFDESCR and SIOCSIFDESCR requests */
-struct ifreq_buffer {
-        size_t  length;         /* length of the buffer */
-        void   *buffer;         /* pointer to userland space buffer */
-};
-
-
-
-

-

ioctl(2), socket(2), - intro(4), config(8), - routed(8), ifnet(9)

-
-
-

-

The netintro manual appeared in - 4.3BSD-Tahoe.

-
-
- - - - - -
October 14, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/netlink.4 3.html b/static/freebsd/man4/netlink.4 3.html deleted file mode 100644 index dbfb5498..00000000 --- a/static/freebsd/man4/netlink.4 3.html +++ /dev/null @@ -1,307 +0,0 @@ - - - - - - -
NETLINK(4)Device Drivers ManualNETLINK(4)
-
-
-

-

Netlink — Kernel - network configuration protocol

-
-
-

-

#include - <netlink/netlink.h> -
- #include - <netlink/netlink_route.h>

-

int -
- socket(AF_NETLINK, - SOCK_RAW, - int family);

-
-
-

-

Netlink is a user-kernel message-based communication protocol - primarily used for network stack configuration. Netlink is easily extendable - and supports large dumps and event notifications, all via a single socket. - The protocol is fully asynchronous, allowing one to issue and track multiple - requests at once. Netlink consists of multiple families, which commonly - group the commands belonging to the particular kernel subsystem. Currently, - the supported families are:

-

-
-
NETLINK_ROUTE	network configuration,
-NETLINK_GENERIC	"container" family
-
-

The NETLINK_ROUTE family handles all - interfaces, addresses, neighbors, routes, and VNETs configuration. More - details can be found in rtnetlink(4). The - NETLINK_GENERIC family serves as a - “container”, allowing registering other families under the - NETLINK_GENERIC umbrella. This approach allows using - a single netlink socket to interact with multiple netlink families at once. - More details can be found in genetlink(4).

-

Netlink has its own sockaddr structure:

-
-
struct sockaddr_nl {
-	uint8_t		nl_len;		/* sizeof(sockaddr_nl) */
-	sa_family_t	nl_family;	/* netlink family */
-	uint16_t	nl_pad;		/* reserved, set to 0 */
-	uint32_t	nl_pid;		/* automatically selected, set to 0 */
-	uint32_t	nl_groups;	/* multicast groups mask to bind to */
-};
-
-

Typically, filling this structure is not required for socket - operations. It is presented here for completeness.

-
-
-

-

The protocol is message-based. Each message starts with the - mandatory nlmsghdr header, followed by the - family-specific header and the list of type-length-value pairs (TLVs). TLVs - can be nested. All headers and TLVS are padded to 4-byte boundaries. Each - send(2) or recv(2) system call may - contain multiple messages.

-
-

-
-
struct nlmsghdr {
-	uint32_t nlmsg_len;   /* Length of message including header */
-	uint16_t nlmsg_type;  /* Message type identifier */
-	uint16_t nlmsg_flags; /* Flags (NLM_F_) */
-	uint32_t nlmsg_seq;   /* Sequence number */
-	uint32_t nlmsg_pid;   /* Sending process port ID */
-};
-
-

The nlmsg_len field stores the whole message - length, in bytes, including the header. This length has to be rounded up to - the nearest 4-byte boundary when iterating over messages. The - nlmsg_type field represents the command/request type. - This value is family-specific. The list of supported commands can be found - in the relevant family header file. nlmsg_seq is a - user-provided request identifier. An application can track the operation - result using the NLMSG_ERROR messages and matching - the nlmsg_seq The nlmsg_pid - field is the message sender id. This field is optional for userland. The - kernel sender id is zero. The nlmsg_flags field - contains the message-specific flags. The following generic flags are - defined:

-

-
-
NLM_F_REQUEST	Indicates that the message is an actual request to the kernel
-NLM_F_ACK	Request an explicit ACK message with an operation result
-
-

The following generic flags are defined for the "GET" - request types:

-

-
-
NLM_F_ROOT	Return the whole dataset
-NLM_F_MATCH	Return all entries matching the criteria
-
-These two flags are typically used together, aliased to - NLM_F_DUMP -

The following generic flags are defined for the "NEW" - request types:

-

-
-
NLM_F_CREATE	Create an object if none exists
-NLM_F_EXCL	Don't replace an object if it exists
-NLM_F_REPLACE	Replace an existing matching object
-NLM_F_APPEND	Append to an existing object
-
-

The following generic flags are defined for the replies:

-

-
-
NLM_F_MULTI	Indicates that the message is part of the message group
-NLM_F_DUMP_INTR	Indicates that the state dump was not completed
-NLM_F_DUMP_FILTERED	Indicates that the dump was filtered per request
-NLM_F_CAPPED	Indicates the original message was capped to its header
-NLM_F_ACK_TLVS	Indicates that extended ACK TLVs were included
-
-
-
-

-

Most messages encode their attributes as type-length-value pairs - (TLVs). The base TLV header:

-
-
struct nlattr {
-	uint16_t nla_len;	/* Total attribute length */
-	uint16_t nla_type;	/* Attribute type */
-};
-
-The TLV type (nla_type) scope is typically the message - type or group within a family. For example, the - RTN_MULTICAST type value is only valid for - RTM_NEWROUTE , RTM_DELROUTE - and RTM_GETROUTE messages. TLVs can be nested; in that - case internal TLVs may have their own sub-types. All TLVs are packed with - 4-byte padding. -
-
-

-

A number of generic control messages are reserved in each - family.

-

NLMSG_ERROR reports the operation result - if requested, optionally followed by the metadata TLVs. The value of - nlmsg_seq is set to its value in the original - messages, while nlmsg_pid is set to the socket pid of - the original socket. The operation result is reported via - struct nlmsgerr:

-
-
struct nlmsgerr {
-	int	error;		/* Standard errno */
-	struct	nlmsghdr msg;	/* Original message header */
-};
-
-If the NETLINK_CAP_ACK socket option is not set, the - remainder of the original message will follow. If the - NETLINK_EXT_ACK socket option is set, the kernel may - add a NLMSGERR_ATTR_MSG string TLV with the textual - error description, optionally followed by the - NLMSGERR_ATTR_OFFS TLV, indicating the offset from the - message start that triggered an error. Some operations may return additional - metadata encapsulated in the NLMSGERR_ATTR_COOKIE TLV. - The metadata format is specific to the operation. If the operation reply is a - multipart message, then no NLMSG_ERROR reply is - generated, only a NLMSG_DONE message, closing - multipart sequence. -

NLMSG_DONE indicates the end of the - message group: typically, the end of the dump. It contains a single - int field, describing the dump result as a standard - errno value.

-
-
-
-

-

Netlink supports a number of custom socket options, which can be - set with setsockopt(2) with the - SOL_NETLINK level:

-
- -
Subscribes to the notifications for the specific group (int).
- -
Unsubscribes from the notifications for the specific group (int).
- -
Lists the memberships as a bitmask.
- -
Instructs the kernel to send the original message header in the reply - without the message body.
- -
Acknowledges ability to receive additional TLVs in the ACK message.
-
-

Additionally, netlink overrides the following socket options from - the SOL_SOCKET level:

-
-
-
Sets the maximum size of the socket receive buffer. If the caller has - PRIV_NET_ROUTE permission, the value can exceed - the currently-set kern.ipc.maxsockbuf value.
-
-
-
-

-

A set of sysctl(8) variables is available to - tweak run-time parameters:

-
-
net.netlink.sendspace
-
Default send buffer for the netlink socket. Note that the socket sendspace - has to be at least as long as the longest message that can be transmitted - via this socket.
-
-
-
net.netlink.recvspace
-
Default receive buffer for the netlink socket. Note that the socket - recvspace has to be least as long as the longest message that can be - received from this socket.
-
-
-
net.netlink.nl_maxsockbuf
-
Maximum receive buffer for the netlink socket that can be set via - SO_RCVBUF socket option.
-
-
-
-

-

Netlink implements per-functional-unit debugging, with different - severities controllable via the net.netlink.debug - branch. These messages are logged in the kernel message buffer and can be - seen in dmesg(8) The following severity levels are - defined:

-
-
-
Rare events or per-socket errors are reported here. This is the default - level, not impacting production performance.
-
-
Socket events such as groups memberships, privilege checks, commands and - dumps are logged. This level does not incur significant performance - overhead.
-
-
All socket events, each dumped or modified entities are logged. Turning it - on may result in significant performance overhead.
-
-
-
-

-

Netlink reports operation results, including errors and error - metadata, by sending a NLMSG_ERROR message for each - request message. The following errors can be returned:

-
-
[]
-
when the current privileges are insufficient to perform the required - operation;
-
[ENOBUFS] or [ENOMEM]
-
when the system runs out of memory for an internal data structure;
-
[]
-
when the requested command is not supported by the family or the family is - not supported;
-
[]
-
when some necessary TLVs are missing or invalid, detailed info may be - provided in NLMSGERR_ATTR_MSG and NLMSGERR_ATTR_OFFS TLVs;
-
[]
-
when trying to delete a non-existent object. -

Additionally, a socket operation itself may fail with one of - the errors specified in socket(2) , - recv(2) or send(2)

-
-
-
-
-

-

snl(3), genetlink(4), - rtnetlink(4)

-

J. Salim, - H. Khosravi, A. Kleen, and - A. Kuznetsov, Linux Netlink as an - IP Services Protocol, RFC 3549.

-
-
-

-

The netlink protocol appeared in FreeBSD - 13.2.

-
-
-

-

The netlink was implemented by Alexander - Chernikov - <melifaro@FreeBSD.org>. - It was derived from the Google Summer of Code 2021 project by - Ng Peng Nam Sean.

-
-
- - - - - -
November 30, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/netmap.4 3.html b/static/freebsd/man4/netmap.4 3.html deleted file mode 100644 index e0cbff0e..00000000 --- a/static/freebsd/man4/netmap.4 3.html +++ /dev/null @@ -1,1015 +0,0 @@ - - - - - - -
NETMAP(4)Device Drivers ManualNETMAP(4)
-
-
-

-

netmap — a - framework for fast packet I/O

-
-
-

-

device netmap

-
-
-

-

netmap is a framework for extremely fast - and efficient packet I/O for userspace and kernel clients, and for Virtual - Machines. It runs on FreeBSD, Linux and some - versions of Windows, and supports a variety of netmap - ports, including

-
-
physical NIC ports
-
to access individual queues of network interfaces;
-
host ports
-
to inject packets into the host stack;
-
VALE ports
-
implementing a very fast and modular in-kernel software - switch/dataplane;
-
netmap pipes
-
a shared memory packet transport channel;
-
netmap monitors
-
a mechanism similar to bpf(4) to capture traffic
-
-

All these netmap ports are accessed - interchangeably with the same API, and are at least one order of magnitude - faster than standard OS mechanisms (sockets, bpf, tun/tap interfaces, native - switches, pipes). With suitably fast hardware (NICs, PCIe buses, CPUs), - packet I/O using netmap on supported NICs reaches - 14.88 million packets per second (Mpps) with much less than one core on 10 - Gbit/s NICs; 35-40 Mpps on 40 Gbit/s NICs (limited by the hardware); about - 20 Mpps per core for VALE ports; and over 100 Mpps for - netmap pipes. NICs without native - netmap support can still use the API in emulated - mode, which uses unmodified device drivers and is 3-5 times faster than - bpf(4) or raw sockets.

-

Userspace clients can dynamically switch NICs into - netmap mode and send and receive raw packets through - memory mapped buffers. Similarly, VALE switch - instances and ports, netmap pipes and - netmap monitors can be created dynamically, - providing high speed packet I/O between processes, virtual machines, NICs - and the host stack.

-

netmap supports both non-blocking I/O - through ioctl(2), synchronization and blocking I/O through - a file descriptor and standard OS mechanisms such as - select(2), poll(2), - kqueue(2) and epoll(7). All types of - netmap ports and the VALE - switch are implemented by a single kernel module, which also emulates - the netmap API over standard drivers. For best - performance, netmap requires native support in - device drivers. A list of such devices is at the end of this document.

-

In the rest of this (long) manual page we document various aspects - of the netmap and VALE - architecture, features and usage.

-
-
-

-

netmap supports raw packet I/O through a - , - which can be connected to a physical interface - (), to - the host stack, or to a VALE switch. Ports use - preallocated circular queues of buffers - () - residing in an mmapped region. There is one ring for each transmit/receive - queue of a NIC or virtual port. An additional ring pair connects to the host - stack.

-

After binding a file descriptor to a port, a - netmap client can send or receive packets in batches - through the rings, and possibly implement zero-copy forwarding between - ports.

-

All NICs operating in netmap mode use the - same memory region, accessible to all processes who own - /dev/netmap file descriptors bound to NICs. - Independent VALE and netmap - pipe ports by default use separate memory regions, but can be - independently configured to share memory.

-
-
-

-

The following section describes the system calls to create and - control netmap ports (including - VALE and netmap pipe ports). - Simpler, higher level functions are described in the - LIBRARIES section.

-

Ports and rings are created and controlled through a file - descriptor, created by opening a special device

-
fd = - open("/dev/netmap");
-and then bound to a specific port with an -
ioctl(fd, NIOCREGIF, (struct nmreq - *)arg);
-

netmap has multiple modes of operation - controlled by the struct nmreq argument. - arg.nr_name specifies the netmap port name, as - follows:

-
-
)
-
the data path of the NIC is disconnected from the host stack, and the file - descriptor is bound to the NIC (one or all queues), or to the host - stack;
-
-
the file descriptor is bound to port PPP of VALE switch SSS. Switch - instances and ports are dynamically created if necessary. -

Both SSS and PPP have the form [0-9a-zA-Z_]+ , the string - cannot exceed IFNAMSIZ characters, and PPP cannot be the name of any - existing OS network interface.

-
-
-

On return, arg indicates the size of the - shared memory region, and the number, size and location of all the - netmap data structures, which can be accessed by - mmapping the memory

-
char *mem = mmap(0, arg.nr_memsize, - fd);
-

Non-blocking I/O is done with special ioctl(2) - select(2) and poll(2) on the file - descriptor permit blocking I/O.

-

While a NIC is in netmap mode, the OS will - still believe the interface is up and running. OS-generated packets for that - NIC end up into a netmap ring, and another ring is - used to send packets into the OS network stack. A close(2) - on the file descriptor removes the binding, and returns the NIC to normal - mode (reconnecting the data path to the host stack), or destroys the virtual - port.

-
-
-

-

The data structures in the mmapped memory region are detailed in - <sys/net/netmap.h>, which is - the ultimate reference for the netmap API. The main - structures and fields are indicated below:

-
-
)
-
-
- 
struct netmap_if {
-    ...
-    const uint32_t   ni_flags;      /* properties              */
-    ...
-    const uint32_t   ni_tx_rings;   /* NIC tx rings            */
-    const uint32_t   ni_rx_rings;   /* NIC rx rings            */
-    uint32_t         ni_bufs_head;  /* head of extra bufs list */
-    ...
-};
-
-

Indicates the number of available rings - (struct netmap_rings) and their position in the - mmapped region. The number of tx and rx rings - (ni_tx_rings, - ni_rx_rings) normally depends on the hardware. - NICs also have an extra tx/rx ring pair connected to the host stack. - NIOCREGIF can also request additional unbound buffers - in the same memory space, to be used as temporary storage for packets. - The number of extra buffers is specified in the - arg.nr_arg3 field. On success, the kernel writes - back to arg.nr_arg3 the number of extra buffers - actually allocated (they may be less than the amount requested if the - memory space ran out of buffers). ni_bufs_head - contains the index of the first of these extra buffers, which are - connected in a list (the first uint32_t of each buffer being the index - of the next buffer in the list). A 0 indicates - the end of the list. The application is free to modify this list and use - the buffers (i.e., binding them to the slots of a netmap ring). When - closing the netmap file descriptor, the kernel frees the buffers - contained in the list pointed by ni_bufs_head , - irrespectively of the buffers originally provided by the kernel on - NIOCREGIF.

-
-
)
-
-
- 
struct netmap_ring {
-    ...
-    const uint32_t num_slots;   /* slots in each ring            */
-    const uint32_t nr_buf_size; /* size of each buffer           */
-    ...
-    uint32_t       head;        /* (u) first buf owned by user   */
-    uint32_t       cur;         /* (u) wakeup position           */
-    const uint32_t tail;        /* (k) first buf owned by kernel */
-    ...
-    uint32_t       flags;
-    struct timeval ts;          /* (k) time of last rxsync()     */
-    ...
-    struct netmap_slot slot[0]; /* array of slots                */
-}
-
-

Implements transmit and receive rings, with - read/write pointers, metadata and an array of - - describing the buffers.

-
-
)
-
-
- 
struct netmap_slot {
-    uint32_t buf_idx;           /* buffer index                 */
-    uint16_t len;               /* packet length                */
-    uint16_t flags;             /* buf changed, etc.            */
-    uint64_t ptr;               /* address for indirect buffers */
-};
-
-

Describes a packet buffer, which normally is identified by an - index and resides in the mmapped region.

-
-
-
Fixed size (normally 2 KB) packet buffers allocated by the kernel.
-
-

The offset of the struct netmap_if in the - mmapped region is indicated by the nr_offset field - in the structure returned by NIOCREGIF. From there, - all other objects are reachable through relative references (offsets or - indexes). Macros and functions in - <net/netmap_user.h> help - converting them into actual pointers:

-

-
struct netmap_if *nifp = - NETMAP_IF(mem, arg.nr_offset);
-
struct netmap_ring *txr = - NETMAP_TXRING(nifp, ring_index);
-
struct netmap_ring *rxr = - NETMAP_RXRING(nifp, ring_index);
-

-
char *buf = NETMAP_BUF(ring, - buffer_index);
-
-
-

-

Rings are circular queues of packets with - three indexes/pointers (head, - cur, tail); one slot is always - kept empty. The ring size (num_slots) should not be - assumed to be a power of two.

-

head is the first slot available to - userspace;

-

cur is the wakeup point: select/poll will - unblock when tail passes - cur;

-

tail is the first slot reserved to the - kernel.

-

Slot indexes must only move forward; for - convenience, the function

-
nm_ring_next(ring, - index)
-returns the next index modulo the ring size. -

head and cur are only - modified by the user program; tail is only modified by - the kernel. The kernel only reads/writes the struct - netmap_ring slots and buffers during the execution of a netmap-related - system call. The only exception are slots (and buffers) in the range - tail ... head-1, that are - explicitly assigned to the kernel.

-
-

-

On transmit rings, after a netmap system - call, slots in the range head ... - tail-1 are available for transmission. User code - should fill the slots sequentially and advance head - and cur past slots ready to transmit. - cur may be moved further ahead if the user code needs - more slots before further transmissions (see - SCATTER GATHER I/O).

-

At the next NIOCTXSYNC/select()/poll(), slots up to - head-1 are pushed to the port, and - tail may advance if further slots have become - available. Below is an example of the evolution of a TX ring:

-
-
    after the syscall, slots between cur and tail are (a)vailable
-              head=cur   tail
-               |          |
-               v          v
-     TX  [.....aaaaaaaaaaa.............]
-
-    user creates new packets to (T)ransmit
-                head=cur tail
-                    |     |
-                    v     v
-     TX  [.....TTTTTaaaaaa.............]
-
-    NIOCTXSYNC/poll()/select() sends packets and reports new slots
-                head=cur      tail
-                    |          |
-                    v          v
-     TX  [..........aaaaaaaaaaa........]
-
-

() - and - () - will block if there is no space in the ring, i.e.,

-
ring->cur == - ring->tail
-and return when new slots have become available. -

High speed applications may want to amortize the cost of system - calls by preparing as many packets as possible before issuing them.

-

A transmit ring with pending transmissions has

-
ring->head != ring->tail + 1 - (modulo the ring size).
-The function int nm_tx_pending(ring) implements this test. -
-
-

-

On receive rings, after a netmap system - call, the slots in the range head... - tail-1 contain received packets. User code should - process them and advance head and - cur past slots it wants to return to the kernel. - cur may be moved further ahead if the user code wants - to wait for more packets without returning all the previous slots to the - kernel.

-

At the next NIOCRXSYNC/select()/poll(), slots up to - head-1 are returned to the kernel for further - receives, and tail may advance to report new incoming - packets.

-

Below is an example of the evolution of an RX ring:

-
-
    after the syscall, there are some (h)eld and some (R)eceived slots
-           head  cur     tail
-            |     |       |
-            v     v       v
-     RX  [..hhhhhhRRRRRRRR..........]
-
-    user advances head and cur, releasing some slots and holding others
-               head cur  tail
-                 |  |     |
-                 v  v     v
-     RX  [..*****hhhRRRRRR...........]
-
-    NICRXSYNC/poll()/select() recovers slots and reports new packets
-               head cur        tail
-                 |  |           |
-                 v  v           v
-     RX  [.......hhhRRRRRRRRRRRR....]
-
-
-
-
-

-

Normally, packets should be stored in the netmap-allocated buffers - assigned to slots when ports are bound to a file descriptor. One packet is - fully contained in a single buffer.

-

The following flags affect slot and buffer processing:

-
-
NS_BUF_CHANGED
-
be used when - the buf_idx in the slot is changed. This can be used - to implement zero-copy forwarding, see - ZERO-COPY FORWARDING.
-
NS_REPORT
-
reports when this buffer has been transmitted. Normally, - netmap notifies transmit completions in batches, - hence signals can be delayed indefinitely. This flag helps detect when - packets have been sent and a file descriptor can be closed.
-
NS_FORWARD
-
When a ring is in 'transparent' mode, packets marked with this flag by the - user application are forwarded to the other endpoint at the next system - call, thus restoring (in a selective way) the connection between a NIC and - the host stack.
-
NS_NO_LEARN
-
tells the forwarding code that the source MAC address for this packet must - not be used in the learning bridge code.
-
NS_INDIRECT
-
indicates that the packet's payload is in a user-supplied buffer whose - user virtual address is in the 'ptr' field of the slot. The size can reach - 65535 bytes. -

This is only supported on the transmit ring of - VALE ports, and it helps reducing data copies in - the interconnection of virtual machines.

-
-
NS_MOREFRAG
-
indicates that the packet continues with subsequent buffers; the last - buffer in a packet must have the flag clear.
-
-
-
-

-

Packets can span multiple slots if the - NS_MOREFRAG flag is set in all but the last slot. The - maximum length of a chain is 64 buffers. This is normally used with - VALE ports when connecting virtual machines, as they - generate large TSO segments that are not split unless they reach a physical - device.

-

NOTE: The length field always refers to the individual fragment; - there is no place with the total length of a packet.

-

On receive rings the macro NS_RFRAGS(slot) - indicates the remaining number of slots for this packet, including the - current one. Slots with a value greater than 1 also have NS_MOREFRAG - set.

-
-
-

-

netmap uses two ioctls (NIOCTXSYNC, - NIOCRXSYNC) for non-blocking I/O. They take no argument. Two more ioctls - (NIOCGINFO, NIOCREGIF) are used to query and configure ports, with the - following argument:

-
-
struct nmreq {
-    char      nr_name[IFNAMSIZ]; /* (i) port name                  */
-    uint32_t  nr_version;        /* (i) API version                */
-    uint32_t  nr_offset;         /* (o) nifp offset in mmap region */
-    uint32_t  nr_memsize;        /* (o) size of the mmap region    */
-    uint32_t  nr_tx_slots;       /* (i/o) slots in tx rings        */
-    uint32_t  nr_rx_slots;       /* (i/o) slots in rx rings        */
-    uint16_t  nr_tx_rings;       /* (i/o) number of tx rings       */
-    uint16_t  nr_rx_rings;       /* (i/o) number of rx rings       */
-    uint16_t  nr_ringid;         /* (i/o) ring(s) we care about    */
-    uint16_t  nr_cmd;            /* (i) special command            */
-    uint16_t  nr_arg1;           /* (i/o) extra arguments          */
-    uint16_t  nr_arg2;           /* (i/o) extra arguments          */
-    uint32_t  nr_arg3;           /* (i/o) extra arguments          */
-    uint32_t  nr_flags           /* (i/o) open mode                */
-    ...
-};
-
-

A file descriptor obtained through - /dev/netmap also supports the ioctl supported by - network devices, see netintro(4).

-
-
-
returns EINVAL if the named port does not support netmap. Otherwise, it - returns 0 and (advisory) information about the port. Note that all the - information below can change before the interface is actually put in - netmap mode. -
-
nr_memsize
-
indicates the size of the netmap memory - region. NICs in netmap mode all share the same - memory region, whereas VALE ports have - independent regions for each port.
-
nr_tx_slots, - nr_rx_slots
-
indicate the size of transmit and receive rings.
-
nr_tx_rings, - nr_rx_rings
-
indicate the number of transmit and receive rings. Both ring number - and sizes may be configured at runtime using interface-specific - functions (e.g., ethtool(8) ).
-
-
-
-
binds the port named in nr_name to the file - descriptor. For a physical device this also switches it into - netmap mode, disconnecting it from the host stack. - Multiple file descriptors can be bound to the same port, with proper - synchronization left to the user. -

The recommended way to bind a file descriptor to a port is to - use function nm_open(..) (see - LIBRARIES) which parses names to - access specific port types and enable features. In the following we - document the main features.

-

NIOCREGIF can also bind a file - descriptor to one endpoint of a - , - consisting of two netmap ports with a crossover connection. A netmap - pipe share the same memory space of the parent port, and is meant to - enable configuration where a master process acts as a dispatcher towards - slave processes.

-

To enable this function, the nr_arg1 - field of the structure can be used as a hint to the kernel to indicate - how many pipes we expect to use, and reserve extra space in the memory - region.

-

On return, it gives the same info as NIOCGINFO, with - nr_ringid and nr_flags - indicating the identity of the rings controlled through the file - descriptor.

-

nr_flags nr_ringid - selects which rings are controlled through this file descriptor. - Possible values of nr_flags are indicated below, - together with the naming schemes that application libraries (such as the - nm_open indicated below) can use to indicate the - specific set of rings. In the example below, "netmap:foo" is - any valid netmap port name.

-
-
NR_REG_ALL_NIC netmap:foo
-
(default) all hardware ring pairs
-
NR_REG_SW netmap:foo^
-
the ``host rings'', connecting to the host stack.
-
NR_REG_NIC_SW netmap:foo*
-
all hardware rings and the host rings
-
NR_REG_ONE_NIC netmap:foo-i
-
only the i-th hardware ring pair, where the number is in - nr_ringid;
-
NR_REG_PIPE_MASTER netmap:foo{i
-
the master side of the netmap pipe whose identifier (i) is in - nr_ringid;
-
NR_REG_PIPE_SLAVE netmap:foo}i
-
the slave side of the netmap pipe whose identifier (i) is in - nr_ringid. -

The identifier of a pipe must be thought as part of the - pipe name, and does not need to be sequential. On return the pipe - will only have a single ring pair with index 0, irrespective of the - value of i.

-
-
-

By default, a poll(2) or - select(2) call pushes out any pending packets on the - transmit ring, even if no write events are specified. The feature can be - disabled by or-ing NETMAP_NO_TX_POLL to the value - written to nr_ringid. When this feature is used, - packets are transmitted only on ioctl(NIOCTXSYNC) - or select() / poll() are - called with a write event (POLLOUT/wfdset) or a full ring.

-

When registering a virtual interface that is dynamically - created to a VALE switch, we can specify the - desired number of rings (1 by default, and currently up to 16) on it - using nr_tx_rings and nr_rx_rings fields.

-
-
-
tells the hardware of new packets to transmit, and updates the number of - slots available for transmission.
-
-
tells the hardware of consumed packets, and asks for newly available - packets.
-
-
-
-

-

select(2) and poll(2) on a - netmap file descriptor process rings as indicated in - TRANSMIT RINGS and - RECEIVE RINGS, respectively when - write (POLLOUT) and read (POLLIN) events are requested. Both block if no - slots are available in the ring (ring->cur == - ring->tail). Depending on the platform, epoll(7) - and kqueue(2) are supported too.

-

Packets in transmit rings are normally pushed out (and buffers - reclaimed) even without requesting write events. Passing the - NETMAP_NO_TX_POLL flag to - NIOCREGIF disables this feature. By default, receive rings - are processed only if read events are requested. Passing the - NETMAP_DO_RX_POLL flag to NIOCREGIF - updates receive rings even without read events. Note that on - epoll(7) and kqueue(2), - NETMAP_NO_TX_POLL and - NETMAP_DO_RX_POLL only have an effect when some - event is posted for the file descriptor.

-
-
-

-

The netmap API is supposed to be used - directly, both because of its simplicity and for efficient integration with - applications.

-

For convenience, the - <net/netmap_user.h> header - provides a few macros and functions to ease creating a file descriptor and - doing I/O with a netmap port. These are loosely - modeled after the pcap(3) API, to ease porting of - libpcap-based applications to netmap. To use these - extra functions, programs should

-
#define NETMAP_WITH_LIBS
-before -
#include - <net/netmap_user.h>
-

The following functions are available:

-
-
struct nm_desc * nm_open(const char *ifname, - const struct nmreq *req, uint64_t flags, const struct nm_desc - *arg)
-
similar to pcap_open_live(3), binds a file descriptor to - a port. -
-
ifname
-
is a port name, in the form "netmap:PPP" for a NIC and - "valeSSS:PPP" for a VALE port.
-
req
-
provides the initial values for the argument to the NIOCREGIF ioctl. - The nm_flags and nm_ringid values are overwritten by parsing ifname - and flags, and other fields can be overridden through the other two - arguments.
-
arg
-
points to a struct nm_desc containing arguments (e.g., from a - previously open file descriptor) that should override the defaults. - The fields are used as described below
-
flags
-
can be set to a combination of the following flags: - NETMAP_NO_TX_POLL, - NETMAP_DO_RX_POLL (copied into nr_ringid); - NM_OPEN_NO_MMAP (if arg points to the same - memory region, avoids the mmap and uses the values from it); - NM_OPEN_IFNAME (ignores ifname and uses the - values in arg); NM_OPEN_ARG1, - NM_OPEN_ARG2, NM_OPEN_ARG3 - (uses the fields from arg); NM_OPEN_RING_CFG - (uses the ring number and sizes from arg).
-
-
-
int nm_close(struct nm_desc *d)
-
closes the file descriptor, unmaps memory, frees resources.
-
int nm_inject(struct nm_desc *d, const void - *buf, size_t size)
-
similar to pcap_inject(), pushes a packet to a ring, - returns the size of the packet is successful, or 0 on error;
-
int nm_dispatch(struct nm_desc *d, int cnt, - nm_cb_t cb, u_char *arg)
-
similar to pcap_dispatch(), applies a callback to - incoming packets
-
u_char * nm_nextpkt(struct nm_desc *d, struct - nm_pkthdr *hdr)
-
similar to pcap_next(), fetches the next packet
-
-
-
-

-

netmap natively supports the following - devices:

-

On FreeBSD: cxgbe(4), - em(4), iflib(4) (providing - igb(4) and em(4)), - ix(4), ixl(4), re(4), - vtnet(4).

-

On Linux e1000, e1000e, i40e, igb, ixgbe, ixgbevf, r8169, - virtio_net, vmxnet3.

-

NICs without native support can still be used in - netmap mode through emulation. Performance is - inferior to native netmap mode but still significantly higher than various - raw socket types (bpf, PF_PACKET, etc.). Note that for slow devices (such as - 1 Gbit/s and slower NICs, or several 10 Gbit/s NICs whose hardware is unable - to sustain line rate), emulated and native mode will likely have similar or - same throughput.

-

When emulation is in use, packet sniffer programs such as tcpdump - could see received packets before they are diverted by netmap. This - behaviour is not intentional, being just an artifact of the implementation - of emulation. Note that in case the netmap application subsequently moves - packets received from the emulated adapter onto the host RX ring, the - sniffer will intercept those packets again, since the packets are injected - to the host stack as they were received by the network interface.

-

Emulation is also available for devices with native netmap - support, which can be used for testing or performance comparison. The sysctl - variable dev.netmap.admode globally controls how - netmap mode is implemented.

-
-
-

-

Some aspects of the operation of netmap - and VALE are controlled through sysctl variables on - FreeBSD - () - and module parameters on Linux - ():

-
-
dev.netmap.admode: 0
-
Controls the use of native or emulated adapter mode. -

0 uses the best available option;

-

1 forces native mode and fails if not available;

-

2 forces emulated hence never fails.

-
-
dev.netmap.generic_rings: - 1
-
Number of rings used for emulated netmap mode
-
dev.netmap.generic_ringsize: - 1024
-
Ring size used for emulated netmap mode
-
dev.netmap.generic_mit: - 100000
-
Controls interrupt moderation for emulated mode
-
dev.netmap.fwd: 0
-
Forces NS_FORWARD mode
-
dev.netmap.txsync_retry: - 2
-
Number of txsync loops in the VALE flush - function
-
dev.netmap.no_pendintr: - 1
-
Forces recovery of transmit buffers on system calls
-
dev.netmap.no_timestamp: - 0
-
Disables the update of the timestamp in the netmap ring
-
dev.netmap.verbose: 0
-
Verbose kernel messages
-
dev.netmap.buf_num: - 163840
-
 
-
dev.netmap.buf_size: - 2048
-
 
-
dev.netmap.ring_num: - 200
-
 
-
dev.netmap.ring_size: - 36864
-
 
-
dev.netmap.if_num: 100
-
 
-
dev.netmap.if_size: - 1024
-
Sizes and number of objects (netmap_if, netmap_ring, buffers) for the - global memory region. The only parameter worth modifying is - dev.netmap.buf_num as it impacts the total amount of - memory used by netmap.
-
dev.netmap.buf_curr_num: - 0
-
 
-
dev.netmap.buf_curr_size: - 0
-
 
-
dev.netmap.ring_curr_num: - 0
-
 
-
dev.netmap.ring_curr_size: - 0
-
 
-
dev.netmap.if_curr_num: - 0
-
 
-
dev.netmap.if_curr_size: - 0
-
Actual values in use.
-
dev.netmap.priv_buf_num: - 4098
-
 
-
dev.netmap.priv_buf_size: - 2048
-
 
-
dev.netmap.priv_ring_num: - 4
-
 
-
dev.netmap.priv_ring_size: - 20480
-
 
-
dev.netmap.priv_if_num: - 2
-
 
-
dev.netmap.priv_if_size: - 1024
-
Sizes and number of objects (netmap_if, netmap_ring, buffers) for private - memory regions. A separate memory region is used for each - VALE port and each pair of netmap - pipes.
-
dev.netmap.bridge_batch: - 1024
-
Batch size used when moving packets across a VALE - switch. Values above 64 generally guarantee good performance.
-
dev.netmap.max_bridges: - 8
-
Max number of VALE switches that can be created. - This tunable can be specified at loader time.
-
dev.netmap.ptnet_vnet_hdr: - 1
-
Allow ptnet devices to use virtio-net headers
-
dev.netmap.port_numa_affinity: - 0
-
On numa(4) systems, allocate memory for netmap ports - from the local NUMA domain when possible. This can improve performance by - reducing the number of remote memory accesses. However, when forwarding - packets between ports attached to different NUMA domains, this will - prevent zero-copy forwarding optimizations and thus may hurt performance. - Note that this setting must be specified as a loader tunable at boot - time.
-
-
-
-

-

netmap uses select(2), - poll(2), epoll(7) and - kqueue(2) to wake up processes when significant events - occur, and mmap(2) to map memory. - ioctl(2) is used to configure ports and - VALE switches.

-

Applications may need to create threads and bind them to specific - cores to improve performance, using standard OS primitives, see - pthread(3). In particular, - pthread_setaffinity_np(3) may be of use.

-
-
-

-
-

-

netmap comes with a few programs that can - be used for testing or simple applications. See the - examples/ directory in - netmap distributions, or - tools/tools/netmap/ directory in - FreeBSD distributions.

-

pkt-gen(8) is a general purpose traffic - source/sink.

-

As an example

-
pkt-gen -i ix0 -f tx -l - 60
-can generate an infinite stream of minimum size packets, and -
pkt-gen -i ix0 -f rx
-is a traffic sink. Both print traffic statistics, to help monitor how the system - performs. -

pkt-gen(8) has many options can be uses to set - packet sizes, addresses, rates, and use multiple send/receive threads and - cores.

-

bridge(4) is another test program which - interconnects two netmap ports. It can be used for - transparent forwarding between interfaces, as in

-
bridge -i netmap:ix0 -i - netmap:ix1
-or even connect the NIC to the host stack using netmap -
bridge -i netmap:ix0
-
-
-

-

The following code implements a traffic generator:

-

-
-
#include <net/netmap_user.h>
-...
-void sender(void)
-{
-    struct netmap_if *nifp;
-    struct netmap_ring *ring;
-    struct nmreq nmr;
-    struct pollfd fds;
-
-    fd = open("/dev/netmap", O_RDWR);
-    bzero(&nmr, sizeof(nmr));
-    strcpy(nmr.nr_name, "ix0");
-    nmr.nm_version = NETMAP_API;
-    ioctl(fd, NIOCREGIF, &nmr);
-    p = mmap(0, nmr.nr_memsize, fd);
-    nifp = NETMAP_IF(p, nmr.nr_offset);
-    ring = NETMAP_TXRING(nifp, 0);
-    fds.fd = fd;
-    fds.events = POLLOUT;
-    for (;;) {
-	poll(&fds, 1, -1);
-	while (!nm_ring_empty(ring)) {
-	    i = ring->cur;
-	    buf = NETMAP_BUF(ring, ring->slot[i].buf_index);
-	    ... prepare packet in buf ...
-	    ring->slot[i].len = ... packet length ...
-	    ring->head = ring->cur = nm_ring_next(ring, i);
-	}
-    }
-}
-
-
-
-

-

A simple receiver can be implemented using the helper - functions:

-

-
-
#define NETMAP_WITH_LIBS
-#include <net/netmap_user.h>
-...
-void receiver(void)
-{
-    struct nm_desc *d;
-    struct pollfd fds;
-    u_char *buf;
-    struct nm_pkthdr h;
-    ...
-    d = nm_open("netmap:ix0", NULL, 0, 0);
-    fds.fd = NETMAP_FD(d);
-    fds.events = POLLIN;
-    for (;;) {
-	poll(&fds, 1, -1);
-        while ( (buf = nm_nextpkt(d, &h)) )
-	    consume_pkt(buf, h.len);
-    }
-    nm_close(d);
-}
-
-
-
-

-

Since physical interfaces share the same memory region, it is - possible to do packet forwarding between ports swapping buffers. The buffer - from the transmit ring is used to replenish the receive ring:

-

-
-
    uint32_t tmp;
-    struct netmap_slot *src, *dst;
-    ...
-    src = &src_ring->slot[rxr->cur];
-    dst = &dst_ring->slot[txr->cur];
-    tmp = dst->buf_idx;
-    dst->buf_idx = src->buf_idx;
-    dst->len = src->len;
-    dst->flags = NS_BUF_CHANGED;
-    src->buf_idx = tmp;
-    src->flags = NS_BUF_CHANGED;
-    rxr->head = rxr->cur = nm_ring_next(rxr, rxr->cur);
-    txr->head = txr->cur = nm_ring_next(txr, txr->cur);
-    ...
-
-
-
-

-

The host stack is for all practical purposes just a regular ring - pair, which you can access with the netmap API (e.g., with

-
nm_open("netmap:eth0^", - ...
-); All packets that the host would send to an interface in - netmap mode end up into the RX ring, whereas all - packets queued to the TX ring are send up to the host stack. -
-
-

-

A simple way to test the performance of a - VALE switch is to attach a sender and a receiver to - it, e.g., running the following in two different terminals:

-
pkt-gen -i vale1:a -f rx # - receiver
-
pkt-gen -i vale1:b -f tx # - sender
-The same example can be used to test netmap pipes, by simply changing port - names, e.g., -
pkt-gen -i vale2:x{3 -f rx # receiver - on the master side
-
pkt-gen -i vale2:x}3 -f tx # sender - on the slave side
-

The following command attaches an interface and the host stack to - a switch:

-
valectl -h vale2:em0
-Other netmap clients attached to the same switch can now - communicate with the network card or the host. -
-
-
-

-

vale(4), bridge(8), - lb(8), nmreplay(8), - pkt-gen(8), valectl(8)

-

http://info.iet.unipi.it/~luigi/netmap/

-

Luigi Rizzo, Revisiting network I/O APIs: the netmap framework, - Communications of the ACM, 55 (3), pp.45-51, March 2012

-

Luigi Rizzo, netmap: a novel framework for fast packet I/O, Usenix - ATC'12, June 2012, Boston

-

Luigi Rizzo, Giuseppe Lettieri, VALE, a switched ethernet for - virtual machines, ACM CoNEXT'12, December 2012, Nice

-

Luigi Rizzo, Giuseppe Lettieri, Vincenzo Maffione, Speeding up - packet I/O in virtual machines, ACM/IEEE ANCS'13, October 2013, San Jose

-
-
-

-

The netmap framework has been originally - designed and implemented at the Universita` di Pisa in 2011 by - Luigi Rizzo, and further extended with help from - Matteo Landi, Gaetano - Catalli, Giuseppe Lettieri, and - Vincenzo Maffione.

-

netmap and VALE - have been funded by the European Commission within FP7 Projects CHANGE - (257422) and OPENLAB (287581).

-
-
-

-

No matter how fast the CPU and OS are, achieving line rate on 10G - and faster interfaces requires hardware with sufficient performance. Several - NICs are unable to sustain line rate with small packet sizes. Insufficient - PCIe or memory bandwidth can also cause reduced performance.

-

Another frequent reason for low performance is the use of flow - control on the link: a slow receiver can limit the transmit speed. Be sure - to disable flow control when running high speed experiments.

-
-

-

netmap is orthogonal to some NIC features - such as multiqueue, schedulers, packet filters.

-

Multiple transmit and receive rings are supported natively and can - be configured with ordinary OS tools, such as ethtool(8) - or device-specific sysctl variables. The same goes for Receive Packet - Steering (RPS) and filtering of incoming traffic.

-

netmap - - features such as - , - , - , - , etc. When using netmap to exchange - packets with the host stack, make sure to disable these features.

-
-
-
- - - - - -
October 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/nfe.4 3.html b/static/freebsd/man4/nfe.4 3.html deleted file mode 100644 index e395583e..00000000 --- a/static/freebsd/man4/nfe.4 3.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - -
NFE(4)Device Drivers ManualNFE(4)
-
-
-

-

nfe — NVIDIA - nForce MCP Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device nfe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_nfe_load="YES"
-
-
-
-

-

The nfe driver supports PCI Ethernet - adapters based on the NVIDIA nForce Media and Communications Processors - (MCP), such as the nForce, nForce 2, nForce 3, CK804, MCP04, MCP51, MCP55, - MCP61, MCP65, MCP67, MCP73, MCP77 and MCP79 Ethernet controller chips.

-

Supported features include (hardware support provided):

-

-
    -
  • Receive/Transmit IP/TCP/UDP checksum offload
    • -
  • Hardware VLAN tag insertion/stripping
    • -
  • TCP segmentation offload (TSO)
    • -
  • MSI/MSI-X
    • -
  • Jumbo Frames
    • -
-

Support for Jumbo Frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit Jumbo Frames.

-

The nfe driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options.
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-
Set 1000Mbps (Gigabit Ethernet) operation (recent models only).
-
-

The nfe driver supports the following - media options:

-
-
-
Force half duplex operation.
-
-
Force full duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The nfe driver supports the following - NVIDIA MCP onboard adapters:

-

-
    -
  • NVIDIA nForce MCP Networking Adapter
    • -
  • NVIDIA nForce MCP04 Networking Adapter
    • -
  • NVIDIA nForce 430 MCP12 Networking Adapter
    • -
  • NVIDIA nForce 430 MCP13 Networking Adapter
    • -
  • NVIDIA nForce MCP51 Networking Adapter
    • -
  • NVIDIA nForce MCP55 Networking Adapter
    • -
  • NVIDIA nForce MCP61 Networking Adapter
    • -
  • NVIDIA nForce MCP65 Networking Adapter
    • -
  • NVIDIA nForce MCP67 Networking Adapter
    • -
  • NVIDIA nForce MCP73 Networking Adapter
    • -
  • NVIDIA nForce MCP77 Networking Adapter
    • -
  • NVIDIA nForce MCP79 Networking Adapter
    • -
  • NVIDIA nForce2 MCP2 Networking Adapter
    • -
  • NVIDIA nForce2 400 MCP4 Networking Adapter
    • -
  • NVIDIA nForce2 400 MCP5 Networking Adapter
    • -
  • NVIDIA nForce3 MCP3 Networking Adapter
    • -
  • NVIDIA nForce3 250 MCP6 Networking Adapter
    • -
  • NVIDIA nForce3 MCP7 Networking Adapter
    • -
  • NVIDIA nForce4 CK804 MCP8 Networking Adapter
    • -
  • NVIDIA nForce4 CK804 MCP9 Networking Adapter
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.nfe.msi_disable
-
Whether or not MSI support is enabled in the driver. The default value is - 0.
-
hw.nfe.msix_disable
-
Whether or not MSI-X support is enabled in the driver. The default value - is 0.
-
-
-
-

-

The following sysctl(8) variables can be used to - modify or monitor nfe behavior.

-
-
dev.nfe.%d.process_limit
-
Maximum number of Rx events to be processed in the event loop before - rescheduling a taskqueue. The accepted range is 50 to 255, the default - value is 192. The interface does not need to be brought down and up again - before a change takes effect.
-
-
-
-

-

altq(4), arp(4), - intro(4), miibus(4), - netintro(4), pci(4), - polling(4), rgephy(4), - ifconfig(8), sysctl(8)

-
-
-

-

The nfe device driver first appeared in - OpenBSD 3.9, and then in FreeBSD - 7.0.

-
-
-

-

The nfe driver was written by - Jonathan Gray - <jsg@openbsd.org> and - Damien Bergamini - <damien@openbsd.org>. - The nfe driver was ported to - FreeBSD by Shigeaki - Tagashira - <shigeaki@se.hiroshima-u.ac.jp>.

-
-
- - - - - -
January 15, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/nfslockd.4 4.html b/static/freebsd/man4/nfslockd.4 4.html deleted file mode 100644 index 74a4e248..00000000 --- a/static/freebsd/man4/nfslockd.4 4.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
NFSLOCKD(4)Device Drivers ManualNFSLOCKD(4)
-
-
-

-

nfslockd — NFS - advisory locking

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
options NFSLOCKD
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
nfslockd_load="YES"
-
-
-
-

-

The nfslockd driver provides kernel - support for NFSv3 advisory locking. It works in tandem with - rpc.lockd(8), which will normally load it on startup if it - is not already loaded or compiled-in.

-
-
-

-

rpc.lockd(8)

-
-
-

-

The nfslockd driver first appeared in - FreeBSD 6.4.

-
-
-

-

The nfslockd driver was written by - Doug Rabson - <dfr@FreeBSD.org>.

-
-
- - - - - -
May 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/nfsmb.4 4.html b/static/freebsd/man4/nfsmb.4 4.html deleted file mode 100644 index 9e49d265..00000000 --- a/static/freebsd/man4/nfsmb.4 4.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
NFSMB(4)Device Drivers ManualNFSMB(4)
-
-
-

-

nfsmb — NVIDIA - nForce2/3/4 SMBus 2.0 controller driver

-
-
-

-

device smbus -
- device smb -
- device nfsmb

-
-
-

-

The nfsmb driver provides access to NVIDIA - nForce2/3/4 SMBus 2.0 controllers.

-
-
-

-

smb(4), smbus(4)

-
-
-

-

The nfsmb driver first appeared in - FreeBSD 6.2.

-
-
-

-

The nfsmb driver was written by - Ruslan Ermilov - <ru@FreeBSD.org>.

-
-
- - - - - -
December 31, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_UI.4 4.html b/static/freebsd/man4/ng_UI.4 4.html deleted file mode 100644 index 8c280c39..00000000 --- a/static/freebsd/man4/ng_UI.4 4.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
NG_UI(4)Device Drivers ManualNG_UI(4)
-
-
-

-

ng_UI — UI - netgraph node type

-
-
-

-

#include - <netgraph/ng_UI.h>

-
-
-

-

The UI node type has two hooks, - upstream and downstream. - Packets received on downstream must have 0x03 - (indicating unnumbered information) as their first byte; if not the packet - is dropped. This byte is then stripped and the remainder of the packet sent - out on upstream.

-

Conversely, packets received on upstream - will have a 0x03 byte prepended to them before being forwarded out on the - downstream hook.

-
-
-

-

This node type supports the following hooks:

-
-
downstream
-
Downstream connection. Packets on this side of the node have a 0x03 as - their first byte.
-
upstream
-
Upstream connection. Packets on this side of the node have the initial - 0x03 byte stripped off.
-
-
-
-

-

This node type supports only the generic control messages.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when both hooks - have been disconnected.

-
-
-

-

netgraph(4), ngctl(8)

-
-
-

-

The ng_UI node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_async.4 3.html b/static/freebsd/man4/ng_async.4 3.html deleted file mode 100644 index f2f373fe..00000000 --- a/static/freebsd/man4/ng_async.4 3.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - -
NG_ASYNC(4)Device Drivers ManualNG_ASYNC(4)
-
-
-

-

ng_async — - asynchronous framing netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_async.h>

-
-
-

-

The async node type performs conversion - between synchronous frames and asynchronous frames, as defined for the PPP - protocol in RFC 1662. Asynchronous framing uses flag bytes and - octet-stuffing to simulate a frame oriented connection over an - octet-oriented asynchronous serial line.

-

The node transmits and receives asynchronous data on the - async hook. Mbuf boundaries of incoming data are - ignored. Once a complete packet has been received, it is decoded and - stripped of all framing bytes, and transmitted out the - sync hook as a single frame.

-

Synchronous frames are transmitted and received on the - sync hook. Packets received on this hook are encoded - as asynchronous frames and sent out on async. - Received packets should start with the address and control fields, or the - PPP protocol field if address and control field compression is employed, and - contain no checksum field. If the first four bytes are 0xff - 0x03 0xc0 0x21 (an LCP protocol frame) then complete control - character escaping is enabled for that frame (in PPP, LCP packets are always - sent with no address and control field compression and all control - characters escaped).

-

This node supports “flag sharing” for packets - transmitted on async. This is an optimization where - the trailing flag byte of one frame is shared with the opening flag byte of - the next. Flag sharing between frames is disabled after one second of - transmit idle time.

-
-
-

-

This node type supports the following hooks:

-
-
async
-
Asynchronous connection. Typically this hook would be connected to a - ng_tty(4) node, which handles transmission of serial - data over a tty device.
-
sync
-
Synchronous connection. This hook sends and receives synchronous frames. - For PPP, these frames should contain address, control, and protocol - fields, but no checksum field. Typically this hook would be connected to - an individual link hook of a ng_ppp(4) type node.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
Sets the node configuration, which is described by a - struct ng_async_cfg: -
- 
struct ng_async_cfg {
-	u_char    enabled;  /* Turn encoding on/off */
-	uint16_t  amru;     /* Max receive async frame length */
-	uint16_t  smru;     /* Max receive sync frame length */
-	uint32_t  accm;     /* ACCM encoding */
-};
-
- The enabled field enables or disables all - encoding/decoding functions (default disabled). When disabled, the node - operates in simple “pass through” mode. The - amru and smru fields are - the asynchronous and synchronous MRU (maximum receive unit) values, - respectively. These both default to 1600; note that the async MRU applies - to the incoming frame length after asynchronous decoding. The - accm field is the asynchronous character control - map, which controls the escaping of characters 0x00 thorough 0x1f (default - 0xffffffff).
-
- (getconfig)
-
This command returns the current configuration structure.
-
- (getstats)
-
This command returns a struct ng_async_stat - containing node statistics for packet, octet, and error counts.
-
- (clrstats)
-
Clears the node statistics.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_ppp(4), - ng_tty(4), ngctl(8)

-

W. Simpson, - PPP in HDLC-link Framing, RFC - 1662.

-

W. Simpson, - The Point-to-Point Protocol (PPP), - RFC 1661.

-
-
-

-

The ng_async node type was implemented in - FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_bluetooth.4 3.html b/static/freebsd/man4/ng_bluetooth.4 3.html deleted file mode 100644 index bb4b6b05..00000000 --- a/static/freebsd/man4/ng_bluetooth.4 3.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - -
NG_BLUETOOTH(4)Device Drivers ManualNG_BLUETOOTH(4)
-
-
-

-

ng_bluetooth — - placeholder for global Bluetooth variables

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/bluetooth/include/ng_bluetooth.h>

-
-
-

-

The ng_bluetooth module is a placeholder - for global Bluetooth variables. All Bluetooth variables can be examined and - changed via sysctl(8).

-
-

-

Below is the description of default variables. Each Bluetooth - module might add its own variables to the tree.

-
-
net.bluetooth.version
-
A read-only integer variable that shows the current version of the - Bluetooth stack.
-
net.bluetooth.hci.command_timeout
-
A read-write integer variable that controls the Host Controller Interface - (HCI) command timeout (in seconds), i.e., how long the HCI layer will wait - for the Command_Complete or - Command_Status event from a Bluetooth device.
-
net.bluetooth.hci.connection_timeout
-
A read-write integer variable that controls the HCI connection timeout, - i.e. how long the HCI layer will wait for the - Connection_Complete event. Normally this should - not be required as Bluetooth devices have connection timeout of their own - and will send event back. This timeout is required to ensure that no - connection will stall in case when the HCI transport layer is broken. Be - careful when changing this variable. Make sure you understand what you are - doing.
-
net.bluetooth.hci.max_neighbor_age
-
A read-write integer variable that controls time-to-live (in seconds) for - entries in the HCI neighbor cache. Every time a Bluetooth device performs - an Inquiry operation, the results will be put in - cache. Later when a Bluetooth device establishes a baseband connection, it - will try to find the matching entry in the cache and use it. This might - speed up establishment of the baseband connection.
-
net.bluetooth.l2cap.rtx_timeout
-
A read-write integer variable that controls the Link Layer Control and - Adaptation Protocol (L2CAP) Retransmission Timeout (RTX) (in seconds). - Every time the L2CAP layer submits a control command, the RTX timeout is - set. The value of the RTX timeout should be greater or equal to the value - of the HCI connection timeout. Be careful when changing this variable. - Make sure you understand what you are doing.
-
net.bluetooth.l2cap.ertx_timeout
-
A read-write integer variable that controls the L2CAP Extended - Retransmission Timeout (ERTX) (in seconds). In some cases remote peer may - respond with PENDING status to the L2CAP control - command. In this case the L2CAP command timeout is reset to the ERTX - timeout value. The value of the ERTX timeout should be greater or equal to - the value of the RTX timeout. Be careful when changing this variable. Make - sure you understand what you are doing.
-
-
-
-
-

-

ng_btsocket(4), ng_hci(4), - ng_l2cap(4), sysctl(8)

-
-
-

-

The ng_bluetooth module was implemented in - FreeBSD 5.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
- - - - - -
November 9, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_bpf.4 3.html b/static/freebsd/man4/ng_bpf.4 3.html deleted file mode 100644 index d9e08f5d..00000000 --- a/static/freebsd/man4/ng_bpf.4 3.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - -
NG_BPF(4)Device Drivers ManualNG_BPF(4)
-
-
-

-

ng_bpf — Berkeley - packet filter netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include <net/bpf.h> -
- #include <netgraph.h> -
- #include - <netgraph/ng_bpf.h>

-
-
-

-

The bpf node type allows Berkeley Packet - Filter (see bpf(4)) filters to be applied to data - travelling through a Netgraph network. Each node allows an arbitrary number - of connections to arbitrarily named hooks. With each hook is associated a - bpf(4) filter program which is applied to incoming data - only, a destination hook for matching packets, a destination hook for - non-matching packets, and various statistics counters.

-

A bpf(4) program returns an unsigned integer, - which is normally interpreted as the length of the prefix of the packet to - return. In the context of this node type, returning zero is considered a - non-match, in which case the entire packet is delivered out the non-match - destination hook. Returning a value greater than zero causes the packet to - be truncated to that length and delivered out the match destination hook. - Either or both destination hooks may be the empty string, or may not exist, - in which case the packet is dropped.

-

New hooks are initially configured to drop all packets. A new - filter program may be installed using the - NGM_BPF_SET_PROGRAM control message.

-
-
-

-

This node type supports any number of hooks having arbitrary - names.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setprogram)
-
This command sets the filter program that will be applied to incoming data - on a hook. The following structure must be supplied as an argument: -
- 
struct ng_bpf_hookprog {
-  char            thisHook[NG_HOOKSIZ];     /* name of hook */
-  char            ifMatch[NG_HOOKSIZ];      /* match dest hook */
-  char            ifNotMatch[NG_HOOKSIZ];   /* !match dest hook */
-  int32_t         bpf_prog_len;             /* #insns in program */
-  struct bpf_insn bpf_prog[];               /* bpf program */
-};
-
-

The hook to be updated is specified in - thisHook. The BPF program is the sequence of - instructions in the bpf_prog array; there must - be bpf_prog_len of them. Matching and - non-matching incoming packets are delivered out the hooks named - ifMatch and ifNotMatch, - respectively. The program must be a valid bpf(4) - program or else EINVAL is returned.

-
-
- (getprogram)
-
This command takes an ASCII string argument, the hook name, and returns - the corresponding struct ng_bpf_hookprog as shown - above.
-
- (getstats)
-
This command takes an ASCII string argument, the hook name, and returns - the statistics associated with the hook as a struct - ng_bpf_hookstat.
-
- (clrstats)
-
This command takes an ASCII string argument, the hook name, and clears the - statistics associated with the hook.
-
- (getclrstats)
-
This command is identical to NGM_BPF_GET_STATS, - except that the statistics are also atomically cleared.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

It is possible to configure a node from the command line, using - tcpdump(1) to generate raw BPF instructions which are then - transformed into the ASCII form of a - NGM_BPF_SET_PROGRAM control message, as demonstrated - here:

-
-
#!/bin/sh
-
-PATTERN="tcp dst port 80"
-NODEPATH="my_node:"
-INHOOK="hook1"
-MATCHHOOK="hook2"
-NOTMATCHHOOK="hook3"
-
-BPFPROG=$( tcpdump -s 8192 -p -ddd ${PATTERN} | \
-           ( read len ; \
-             echo -n "bpf_prog_len=$len " ; \
-             echo -n "bpf_prog=[" ; \
-             while read code jt jf k ; do \
-                 echo -n " { code=$code jt=$jt jf=$jf k=$k }" ; \
-             done ; \
-             echo " ]" ) )
-
-ngctl msg ${NODEPATH} setprogram { thisHook=\"${INHOOK}\" \
-  ifMatch=\"${MATCHHOOK}\" \
-  ifNotMatch=\"${NOTMATCHHOOK}\" \
-  ${BPFPROG} }
-
-

Based on the previous example, it is possible to prevent a jail - (or a VM) from spoofing by allowing only traffic that has the expected - ethernet and IP addresses:

-
-
#!/bin/sh
-
-NODEPATH="my_node:"
-JAIL_MAC="0a:00:de:ad:be:ef"
-JAIL_IP="128.66.1.42"
-JAIL_HOOK="jail"
-HOST_HOOK="host"
-DEBUG_HOOK="nomatch"
-
-bpf_prog() {
-    local PATTERN=$1
-
-    tcpdump -s 8192 -p -ddd ${PATTERN} | (
-        read len
-        echo -n "bpf_prog_len=$len "
-        echo -n "bpf_prog=["
-        while read code jt jf k ; do
-            echo -n " { code=$code jt=$jt jf=$jf k=$k }"
-        done
-        echo " ]"
-    )
-}
-
-# Prevent jail from spoofing (filter packets coming from jail)
-ngctl msg ${NODEPATH} setprogram {                        \
-    thisHook=\"${JAIL_HOOK}\"                             \
-    ifMatch=\"${HOST_HOOK}\"                              \
-    ifNotMatch=\"${DEBUG_HOOK}\"                          \
-    $(bpf_prog "ether src ${JAIL_MAC} && src ${JAIL_IP}") \
-}
-
-# Prevent jail from receiving spoofed packets (filter packets
-# coming from host)
-ngctl msg ${NODEPATH} setprogram {                        \
-    thisHook=\"${HOST_HOOK}\"                             \
-    ifMatch=\"${JAIL_HOOK}\"                              \
-    ifNotMatch=\"${DEBUG_HOOK}\"                          \
-    $(bpf_prog "ether dst ${JAIL_MAC} && dst ${JAIL_IP}") \
-}
-
-
-
-

-

bpf(4), netgraph(4), - ngctl(8)

-
-
-

-

The ng_bpf node type was implemented in - FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

When built as a loadable kernel module, this module includes the - file net/bpf_filter.c. Although loading the module - should fail if net/bpf_filter.c already exists in - the kernel, currently it does not, and the duplicate copies of the file do - not interfere. However, this may change in the future.

-
-
- - - - - -
September 20, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_bridge.4 3.html b/static/freebsd/man4/ng_bridge.4 3.html deleted file mode 100644 index 4aa25e0b..00000000 --- a/static/freebsd/man4/ng_bridge.4 3.html +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - -
NG_BRIDGE(4)Device Drivers ManualNG_BRIDGE(4)
-
-
-

-

ng_bridge — - Ethernet bridging netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_bridge.h>

-
-
-

-

The bridge node type performs Ethernet - bridging over one or more links. Each link (represented by a connected hook) - is used to transmit and receive raw Ethernet frames. As packets are - received, the node learns which link each host resides on. Packets unicast - to a known host are directed out the appropriate link only, and other links - are spared the traffic. This behavior is in contrast to a hub, which always - forwards every received packet to every other link.

-
-
-

-

The bridge node incorporates a simple loop - detection algorithm. A loop is when two ports are connected to the same - physical medium. Loops are important to avoid because of packet storms, - which severely degrade performance. A packet storm results when the same - packet is sent and received over and over again. If a host is detected on - link A, and is then detected on link B within a certain time period after - first being detected on link A, then link B is considered to be a looped - back link. The time period is called the minimum stable time.

-

A looped back link will be temporarily muted, i.e., all traffic - received on that link is ignored.

-
-
-

-

Processing of IP packets via the ipfirewall(4) - mechanism on a per-link basis is not yet implemented.

-
-
-

-

This node type supports an unlimited number of hooks. Each - connected hook represents a bridged link. The hooks are named - link0, link1, etc. Typically - these hooks are connected to the lower hooks of one or - more ng_ether(4) nodes. To connect the host machine to a - bridged network, simply connect the upper hook of an - ng_ether(4) node to the bridge node.

-

Instead of naming a hook linkX the hook - might be also named uplinkX. The node does not learn - MAC addresses on uplink hooks, which keeps the internal address table small. - This way it is desirable to connect the lower hook of - an ng_ether(4) node to an uplink - hook of the bridge, and ignore the complexity of the outside world. Frames - with unknown MACs are always sent out to uplink hooks, - so no functionality is lost. The uplink0 hook is not - allowed.

-

The linkX and uplinkX - hook numbers can be autoassigned. If a new hook name was specified as - link or uplink the node will - append lowest available valid number to the name of the new hook.

-

Frames with unknown destination MAC addresses are replicated to - any available hook, unless the first connected hook is an - uplink hook. In this case the node assumes, that all - unknown MAC addresses are located solely on the uplink - hooks and only those hooks will be used to send out frames with unknown - destination MACs. If the first connected hook is an - link hook, the node will replicate such frames to all - types of hooks, even if uplink hooks are connected - later.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
Set the node configuration. This command takes a struct - ng_bridge_config as an argument: -
- 
/* Node configuration structure */
-struct ng_bridge_config {
-  u_char      debugLevel;           /* debug level */
-  uint32_t    loopTimeout;          /* link loopback mute time */
-  uint32_t    maxStaleness;         /* max host age before nuking */
-  uint32_t    minStableAge;         /* min time for a stable host */
-};
-
-

The debugLevel field sets the debug - level on the node. At level of 2 or greater, detected loops are logged. - The default level is 1.

-

The loopTimeout determines how long (in - seconds) a looped link is muted. The default is 60 seconds. The - maxStaleness parameter determines how long a - period of inactivity before a host's entry is forgotten. The default is - 15 minutes. The minStableAge determines how - quickly a host must jump from one link to another before we declare a - loopback condition. The default is one second.

-
-
- (getconfig)
-
Returns the current configuration as a struct - ng_bridge_config.
-
- (reset)
-
Causes the node to forget all hosts and unmute all links. The node - configuration is not changed.
-
- (getstats)
-
This command takes a four byte link number as an argument and returns a - struct ng_bridge_link_stats containing statistics - for the corresponding link, which must be currently - connected: -
- 
/* Statistics structure (one for each link) */
-struct ng_bridge_link_stats {
-  uint64_t   recvOctets;     /* total octets rec'd on link */
-  uint64_t   recvPackets;    /* total pkts rec'd on link */
-  uint64_t   recvMulticasts; /* multicast pkts rec'd on link */
-  uint64_t   recvBroadcasts; /* broadcast pkts rec'd on link */
-  uint64_t   recvUnknown;    /* pkts rec'd with unknown dest addr */
-  uint64_t   recvRunts;      /* pkts rec'd less than 14 bytes */
-  uint64_t   recvInvalid;    /* pkts rec'd with bogus source addr */
-  uint64_t   xmitOctets;     /* total octets xmit'd on link */
-  uint64_t   xmitPackets;    /* total pkts xmit'd on link */
-  uint64_t   xmitMulticasts; /* multicast pkts xmit'd on link */
-  uint64_t   xmitBroadcasts; /* broadcast pkts xmit'd on link */
-  uint64_t   loopDrops;      /* pkts dropped due to loopback */
-  uint64_t   loopDetects;    /* number of loop detections */
-  uint64_t   memoryFailures; /* times couldn't get mem or mbuf */
-};
-
-

Negative numbers refer to the uplink - hooks. So querying for -7 will get the statistics for hook - uplink7.

-
-
- (clrstats)
-
This command takes a four byte link number as an argument and clears the - statistics for that link.
-
- (getclrstats)
-
Same as NGM_BRIDGE_GET_STATS, but also atomically - clears the statistics as well.
-
- (gettable)
-
Returns the current host mapping table used to direct packets, in a - struct ng_bridge_host_ary.
-
- (setpersistent)
-
This command sets the persistent flag on the node, and takes no - arguments.
-
- (movehost)
-
This command takes a struct ng_bridge_move_host as - an argument. It assigns the MAC addr to the - hook. If the hook is the empty - string, the incoming hook of the control message is used as fallback. -

If necessary, the MAC is removed from the currently assigned - hook and moved to the new one. If the MAC is moved faster than - minStableAge, the hook is considered as a loop and - will block traffic for loopTimeout seconds.

-
- 
struct ng_bridge_move_host {
-  u_char  addr[ETHER_ADDR_LEN];	/* ethernet address */
-  char    hook[NG_HOOKSIZ];	/* link where addr can be found */
-};
-
-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected. Setting the persistent flag via a - NGM_BRIDGE_SET_PERSISTENT control message disables - automatic node shutdown when the last hook gets disconnected.

-
-
-

-
-
/usr/share/examples/netgraph/ether.bridge
-
Example script showing how to set up a bridging network
-
-
-
-

-

if_bridge(4), netgraph(4), - ng_ether(4), ng_hub(4), - ng_one2many(4), ngctl(8)

-
-
-

-

The ng_bridge node type was implemented in - FreeBSD 4.2.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

The ng_bridge node refuses to create the - uplink0 hook to avoid later ambiguity with the - NGM_BRIDGE_GET_STATS message.

-
-
- - - - - -
April 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_btsocket.4 3.html b/static/freebsd/man4/ng_btsocket.4 3.html deleted file mode 100644 index cdc90d68..00000000 --- a/static/freebsd/man4/ng_btsocket.4 3.html +++ /dev/null @@ -1,313 +0,0 @@ - - - - - - -
NG_BTSOCKET(4)Device Drivers ManualNG_BTSOCKET(4)
-
-
-

-

ng_btsocket — - Bluetooth sockets layer

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <sys/bitstring.h> -
- #include - <netgraph/bluetooth/include/ng_hci.h> -
- #include - <netgraph/bluetooth/include/ng_l2cap.h> -
- #include - <netgraph/bluetooth/include/ng_btsocket.h>

-
-
-

-

The ng_btsocket module implements three - Netgraph node types. Each type in its turn implements one protocol within - PF_BLUETOOTH domain.

-
-
-

-
-

-

Implemented by btsock_hci_raw Netgraph - type. Raw HCI sockets allow sending of raw HCI command datagrams only to - correspondents named in send(2) calls. Raw HCI datagrams - (HCI commands, events and data) are generally received with - recvfrom(2), which returns the next datagram with its - return address. Raw HCI sockets can also be used to control HCI nodes.

-

The Bluetooth raw HCI socket address is defined as follows:

-
-
/* Bluetooth version of struct sockaddr for raw HCI sockets */
-struct sockaddr_hci {
-        u_char	hci_len;      /* total length */
-        u_char	hci_family;   /* address family */
-	char	hci_node[32]; /* address (size == NG_NODESIZ ) */
-};
-
-

Raw HCI sockets support a number of ioctl(2) - requests such as:

-
-
-
Returns current state for the HCI node.
-
-
Turn on “inited” bit for the HCI node.
-
-
Returns current debug level for the HCI node.
-
-
Sets current debug level for the HCI node.
-
-
Returns current state of data buffers for the HCI node.
-
-
Returns BD_ADDR for the HCI node.
-
-
Returns the list of features supported by hardware for the HCI node.
-
-
Returns various statistic counters for the HCI node.
-
-
Resets all statistic counters for the HCI node to zero.
-
-
Remove all neighbor cache entries for the HCI node.
-
-
Returns content of the neighbor cache for the HCI node.
-
-
Returns list of active baseband connections (i.e., ACL and SCO links) for - the HCI node.
-
SIOC_HCI_RAW_NODE_GET_LINK_POLICY_MASK
-
Returns current link policy settings mask for the HCI node.
-
SIOC_HCI_RAW_NODE_SET_LINK_POLICY_MASK
-
Sets current link policy settings mask for the HCI node.
-
SIOC_HCI_RAW_NODE_GET_PACKET_MASK
-
Returns current packet mask for the HCI node.
-
SIOC_HCI_RAW_NODE_SET_PACKET_MASK
-
Sets current packet mask for the HCI node.
-
SIOC_HCI_RAW_NODE_GET_ROLE_SWITCH
-
Returns current value of the role switch parameter for the HCI node.
-
SIOC_HCI_RAW_NODE_SET_ROLE_SWITCH
-
Sets new value of the role switch parameter for the HCI node.
-
-

The - net.bluetooth.hci.sockets.raw.ioctl_timeout variable, - that can be examined and set via sysctl(8), controls the - control request timeout (in seconds) for raw HCI sockets.

-

Raw HCI sockets support filters. The application can filter - certain HCI datagram types. For HCI event datagrams the application can set - additional filter. The raw HCI socket filter defined as follows:

-
-
/*
- * Raw HCI socket filter.
- *
- * For packet mask use (1 << (HCI packet indicator - 1))
- * For event mask use (1 << (Event - 1))
- */
-
-struct ng_btsocket_hci_raw_filter {
-        bitstr_t bit_decl(packet_mask, 32);
-        bitstr_t bit_decl(event_mask, (NG_HCI_EVENT_MASK_SIZE * 8));
-};
-
-

The SO_HCI_RAW_FILTER option defined at - SOL_HCI_RAW level can be used to obtain via - getsockopt(2) or change via - setsockopt(2) raw HCI socket's filter.

-
-
-
-

-

The Bluetooth L2CAP socket address is defined as follows:

-
-
/* Bluetooth version of struct sockaddr for L2CAP sockets */
-struct sockaddr_l2cap {
-        u_char    l2cap_len;    /* total length */
-        u_char    l2cap_family; /* address family */
-        uint16_t  l2cap_psm;    /* Protocol/Service Multiplexor */
-        bdaddr_t  l2cap_bdaddr; /* address */
-};
-
-
-

-

Implemented by btsock_l2c_raw Netgraph - type. Raw L2CAP sockets do not provide access to raw L2CAP datagrams. These - sockets used to control L2CAP nodes and to issue special L2CAP requests such - as ECHO_REQUEST and GET_INFO - request.

-

Raw L2CAP sockets support number of ioctl(2) - requests such as:

-
-
-
Returns current state for the L2CAP node.
-
-
Returns current debug level for the L2CAP node.
-
-
Sets current debug level for the L2CAP node.
-
-
Returns list of active baseband connections (i.e., ACL links) for the - L2CAP node.
-
-
Returns list of active channels for the L2CAP node.
-
-
Returns current value of the auto disconnect timeout for the L2CAP - node.
-
-
Sets current value of the auto disconnect timeout for the L2CAP node.
-
-
Issues L2CAP ECHO_REQUEST.
-
-
Issues L2CAP GET_INFO request.
-
-

The - net.bluetooth.l2cap.sockets.raw.ioctl_timeout - variable, that can be examined and set via sysctl(8), - controls the control request timeout (in seconds) for raw L2CAP sockets.

-
-
-

-

Implemented by btsock_l2c Netgraph type. - L2CAP sockets are either “active” or “passive”. - Active sockets initiate connections to passive sockets. By default, L2CAP - sockets are created active; to create a passive socket, the - listen(2) system call must be used after binding the - socket with the bind(2) system call. Only passive sockets - may use the accept(2) call to accept incoming connections. - Only active sockets may use the connect(2) call to - initiate connections.

-

L2CAP sockets support “wildcard addressing”. In this - case, socket must be bound to NG_HCI_BDADDR_ANY - address. Note that PSM (Protocol/Service Multiplexor) field is always - required. Once a connection has been established, the socket's address is - fixed by the peer entity's location. The address assigned to the socket is - the address associated with the Bluetooth device through which packets are - being transmitted and received, and PSM (Protocol/Service Multiplexor).

-

L2CAP sockets support number of options defined at - SOL_L2CAP level which can be set with - setsockopt(2) and tested with - getsockopt(2):

-
-
-
Get (set) maximum payload size the local socket is capable of - accepting.
-
-
Get maximum payload size the remote socket is capable of accepting.
-
-
Get incoming flow specification for the socket. -
Not implemented.
-
-
-
Get (set) outgoing flow specification for the socket. -
Not implemented.
-
-
-
Get (set) value of the flush timeout. -
Not implemented.
-
-
-
-
-
-

-

The Bluetooth RFCOMM socket address is defined as follows:

-
-
/* Bluetooth version of struct sockaddr for RFCOMM sockets */
-struct sockaddr_rfcomm {
-        u_char   rfcomm_len;     /* total length */
-        u_char   rfcomm_family;  /* address family */
-        bdaddr_t rfcomm_bdaddr;  /* address */
-        uint8_t  rfcomm_channel; /* channel */
-};
-
-
-

-

Note that RFCOMM sockets do not have associated Netgraph node - type. RFCOMM sockets are implemented as additional layer on top of L2CAP - sockets. RFCOMM sockets are either “active” or - “passive”. Active sockets initiate connections to passive - sockets. By default, RFCOMM sockets are created active; to create a passive - socket, the listen(2) system call must be used after - binding the socket with the bind(2) system call. Only - passive sockets may use the accept(2) call to accept - incoming connections. Only active sockets may use the - connect(2) call to initiate connections.

-

RFCOMM sockets support “wildcard addressing”. In - this case, socket must be bound to NG_HCI_BDADDR_ANY - address. Note that RFCOMM channel field is always required. Once a - connection has been established, the socket's address is fixed by the peer - entity's location. The address assigned to the socket is the address - associated with the Bluetooth device through which packets are being - transmitted and received, and RFCOMM channel.

-

The following options, which can be tested with - getsockopt(2) call, are defined at - SOL_RFCOMM level for RFCOMM sockets:

-
-
-
Returns the maximum transfer unit size (in bytes) for the underlying - RFCOMM channel. Note that application still can write/read bigger chunks - to/from the socket.
-
-
Return the flow control information for the underlying RFCOMM - channel.
-
-

The - net.bluetooth.rfcomm.sockets.stream.timeout variable, - that can be examined and set via sysctl(8), controls the - connection timeout (in seconds) for RFCOMM sockets.

-
-
-
-

-

These node types support hooks with arbitrary names (as long as - they are unique) and always accept hook connection requests.

-
-
-

-

These node types support the generic control messages.

-
-
-

-

These nodes are persistent and cannot be shut down.

-
-
-

-

btsockstat(1), socket(2), - netgraph(4), ng_bluetooth(4), - ng_hci(4), ng_l2cap(4), - ngctl(8), sysctl(8)

-
-
-

-

The ng_btsocket module was implemented in - FreeBSD 5.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

Most likely. Please report if found.

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_car.4 3.html b/static/freebsd/man4/ng_car.4 3.html deleted file mode 100644 index c6828e7e..00000000 --- a/static/freebsd/man4/ng_car.4 3.html +++ /dev/null @@ -1,218 +0,0 @@ - - - - - - -
NG_CAR(4)Device Drivers ManualNG_CAR(4)
-
-
-

-

ng_car — Committed - Access Rate netgraph node type

-
-
-

-

#include - <netgraph/ng_car.h>

-
-
-

-

The car node type limits traffic flowing - through it using:

-

-
    -
  • Single rate three color marker as described in RFC 2697,
    • -
  • Two rate three color marker as described in RFC 2698,
    • -
  • RED-like rate limit algorithm used by Cisco,
    • -
  • Traffic shaping with RED.
    • -
-
-
-

-

This node type supports the following hooks:

-
-
upper
-
Hook leading to upper layer protocols.
-
lower
-
Hook leading to lower layer protocols.
-
-

Traffic flowing from upper - to lower is considered - - traffic. Traffic flowing from lower to - upper is considered - - traffic.

-
-
-

-

Each hook can operate in one of the following modes:

-
-
-
Single rate three color marker as described in RFC 2697. Committed burst - packets are counted as green, extended burst packets are counted as yellow - and exceeding packets are counted as red. Committed burst getting refilled - with CIR (Committed Information Rate) speed. When it is full, exceeded - burst getting refilled.
-
-
Two rate three color marker as described in RFC 2698. Committed burst - packets are counted as green, peak burst packets are counted as yellow and - exceeding packets are counted as red. Committed burst getting refilled - with CIR speed. Peak burst getting refilled with PIR (Peak Information - Rate) speed at the same time.
-
-
Similar to NG_CAR_SINGLE_RATE, but with different - understanding of extended burst. When normal burst exceeded and extended - burst is used, packets are counted red with probability equal to part of - extended burst consumed. Extended burst getting refilled first. When it is - full, committed burst getting refilled. This behavior is similar to RED - active queue management algorithm. -

This algorithm is more polite to the TCP traffic than - NG_CAR_SINGLE_RATE.

-
-
-
Committed burst packets are counted as green, exceeding packets are - delayed by queue with RED management and counted as yellow. Packets - dropped by queue counted as red. Queue parameters are hardcoded: length 99 - packets, min_th 8 packets, max_p 100%. -

Traffic shaping is much more polite to the TCP traffic than - rate limit on links with bandwidth * delay product less than 6-8 TCP - segments, but it consumes additional system resources for queue - processing.

-
-
-

By default, all information rates are measured in bits per second - and bursts are measured in bytes. But when NG_CAR_COUNT_PACKETS option is - enabled, rates are measured in packets per second and bursts are in - packets.

-
-
-

-

This node type supports the generic control messages and the - following specific messages.

-
-
- (setconf)
-
Set node configuration to the specified at struct - ng_car_bulkconf
-
- (getconf)
-
Return current node configuration as struct - ng_car_bulkconf -
- 
struct ng_car_hookconf {
-	uint64_t cbs;		/* Committed burst size (bytes) */
-	uint64_t ebs;		/* Exceeded/Peak burst size (bytes) */
-	uint64_t cir;		/* Committed information rate (bits/s) */
-	uint64_t pir;		/* Peak information rate (bits/s) */
-	uint8_t  green_action;	/* Action for green packets */
-	uint8_t  yellow_action;	/* Action for yellow packets */
-	uint8_t  red_action;	/* Action for red packets */
-	uint8_t  mode;		/* single/double rate, ... */
-	uint8_t  opt;		/* color-aware or color-blind */
-};
-
-/* possible actions (..._action) */
-enum {
-    NG_CAR_ACTION_FORWARD = 1,
-    NG_CAR_ACTION_DROP,
-    NG_CAR_ACTION_MARK
-};
-
-/* operation modes (mode) */
-enum {
-    NG_CAR_SINGLE_RATE = 0,
-    NG_CAR_DOUBLE_RATE,
-    NG_CAR_RED,
-    NG_CAR_SHAPE
-};
-
-/* mode options (bits for opt) */
-#define NG_CAR_COLOR_AWARE	1
-#define NG_CAR_COUNT_PACKETS	2
-
-struct ng_car_bulkconf {
-	struct ng_car_hookconf upstream;
-	struct ng_car_hookconf downstream;
-};
-
-
-
- (getstats)
-
Return node statistics as struct ng_car_bulkstats -
- 
struct ng_car_hookstats {
-	uint64_t passed_pkts;	/* Counter for passed packets */
-	uint64_t dropped_pkts;	/* Counter for dropped packets */
-	uint64_t green_pkts;	/* Counter for green packets */
-	uint64_t yellow_pkts;	/* Counter for yellow packets */
-	uint64_t red_pkts;	/* Counter for red packets */
-	uint64_t errors;	/* Counter for operation errors */
-};
-
-struct ng_car_bulkstats {
-	struct ng_car_hookstats upstream;
-	struct ng_car_hookstats downstream;
-};
-
-
-
- (clrstats)
-
Clear node statistics.
-
- (getclrstats)
-
Atomically return and clear node statistics.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

Limit outgoing data rate over fxp0 Ethernet interface to 20Mbit/s - and incoming packet rate to 5000pps.

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	mkpeer fxp0: car lower lower
-	name fxp0:lower fxp0_car
-	connect fxp0: fxp0_car: upper upper
-	msg fxp0_car: setconf { downstream={ cir=20000000 cbs=2500000 ebs=2500000 greenAction=1 yellowAction=1 redAction=2 mode=2 } upstream={ cir=5000 cbs=100 ebs=100 greenAction=1 yellowAction=1 redAction=2 mode=2 opt=2 } }
-SEQ
-
-
-
-

-

netgraph(4), ngctl(8)

-

J. Heinanen, - A Single Rate Three Color Marker, - RFC 2697.

-

J. Heinanen, - A Two Rate Three Color Marker, - RFC 2698.

-
-
-

-

Nuno Antunes - <nuno.antunes@gmail.com> -
- Alexander Motin - <mav@FreeBSD.org>

-
-
-

-

At this moment only DROP and FORWARD actions are implemented.

-
-
- - - - - -
January 27, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_checksum.4 3.html b/static/freebsd/man4/ng_checksum.4 3.html deleted file mode 100644 index 4507013c..00000000 --- a/static/freebsd/man4/ng_checksum.4 3.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - -
NG_CHECKSUM(4)Device Drivers ManualNG_CHECKSUM(4)
-
-
-

-

ng_checksum — - reconstructing IP checksums node type

-
-
-

-

#include - <netgraph/ng_checksum.h>

-
-
-

-

The checksum node can calculate, or - prepare for calculation in hardware, IPv4 header, TCP and UDP checksums.

-
-
-

-

This node type has two hooks:

-
-
in
-
Packets received on this hook are processed according to settings - specified in config and then forwarded to the out - hook, if it exists and is connected. Otherwise they are reflected back to - the in hook.
-
out
-
Packets received on this hook are forwarded to the - in hook without any changes.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setdlt)
-
Sets the data link type on the in hook. Currently, - supported types are DLT_RAW (raw IP datagrams) and - DLT_EN10MB (Ethernet). DLT_ definitions can be - found in the <net/bpf.h> - header. Currently used values are DLT_EN10MB = 1 - and DLT_RAW = 12.
-
- (getdlt)
-
This control message obtains the data link type on the - in hook.
-
- (setconfig)
-
Sets the node configuration. The following struct - ng_checksum_config must be supplied as an argument: -
- 
struct ng_checksum_config {
-	uint64_t	csum_flags;
-	uint64_t	csum_offload;
-};
-
-

The csum_flags can be set to any - combination of CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_TCP_IPV6 and - CSUM_UDP_IPV6 (other values are ignored) for instructing the node to - calculate the corresponding checksum.

-

The csum_offload value can be set to any - combination of CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_TCP_IPV6 and - CSUM_UDP_IPV6 (other values are ignored) for instructing the node what - checksums should be requested from the hardware.

-

The node also takes into account any combination of CSUM_IP, - CSUM_TCP, CSUM_UDP, CSUM_TCP_IPV6 and CSUM_UDP_IPV6 already flagged on - the mbuf.

-
-
- (getconfig)
-
This control message obtains the current node configuration returned as a - struct ng_checksum_config.
-
- (getstats)
-
Returns node statistics as a struct - ng_checksum_stats.
-
- (clrstats)
-
Clear the node statistics.
-
- (getclrstats)
-
This command is identical to - NGM_CHECKSUM_GET_STATS, except that the statistics - are also atomically cleared.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

ngctl(8) script:

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	msg checksum-1: setdlt 1
-	msg checksum-1: setconfig { csum_flags=0 csum_offload=6 }
-SEQ
-
-

Set the data link type to DLT_EN10MB - (Ethernet), do not set additional checksum flags and request that the - hardware calculate CSUM_IP_UDP|CSUM_IP_TCP.

-
-
-

-

netgraph(4), ng_patch(4), - ngctl(8)

-
-
-

-

The ng_checksum node type was implemented - in FreeBSD 10.2 and first submitted in - FreeBSD 12.0.

-
-
-

-

Dmitry Vagin - ⟨daemon.hammer@ya.ru⟩.

-
-
- - - - - -
October 29, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_cisco.4 3.html b/static/freebsd/man4/ng_cisco.4 3.html deleted file mode 100644 index c7eb8078..00000000 --- a/static/freebsd/man4/ng_cisco.4 3.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - -
NG_CISCO(4)Device Drivers ManualNG_CISCO(4)
-
-
-

-

ng_cisco — Cisco - HDLC protocol netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include <netinet/in.h> -
- #include - <netgraph/ng_cisco.h>

-
-
-

-

The cisco node type performs encapsulation - and de-encapsulation of packets using the Cisco HDLC protocol. This is a - fairly simple protocol for the transmission of packets across high speed - synchronous lines. Each packet is prepended with an Ethertype, indicating - the protocol. There is also a “keep alive” and an - “inquire” capability.

-

The downstream hook should connect to the - synchronous line. On the other side of the node are the - inet, inet6, - atalk, and ipx hooks, which - transmit and receive raw IP, IPv6, AppleTalk, and IPX packets, respectively. - Typically these hooks would connect to the corresponding hooks on an - ng_iface(4) type node.

-
-
-

-

In order to function properly for IP traffic, the node must be - informed of the local IP address and netmask setting. This is because the - protocol includes an “inquire” packet which we must be - prepared to answer. There are two ways to accomplish this, manually and - automatically.

-

Whenever such an inquire packet is received, the node sends a - NGM_CISCO_GET_IPADDR control message to the peer - node connected to the inet hook (if any). If the - peer responds, then that response is used. This is the automatic method.

-

If the peer does not respond, the node falls back on its cached - value for the IP address and netmask. This cached value can be set at any - time with a NGM_CISCO_SET_IPADDR message, and this - is the manual method.

-

If the inet hook is connected to the - inet hook of an ng_iface(4) node, - as is usually the case, then configuration is automatic as the - ng_iface(4) understands the - NGM_CISCO_GET_IPADDR message.

-
-
-

-

This node type supports the following hooks:

-
-
downstream
-
The connection to the synchronous line.
-
inet
-
IP hook.
-
inet6
-
IPv6 hook.
-
atalk
-
AppleTalk hook.
-
ipx
-
IPX hook.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setipaddr)
-
This command takes an array of two struct in_addr - arguments. The first is the IP address of the corresponding interface and - the second is the netmask.
-
- (getipaddr)
-
This command returns the IP configuration in the same format used by - NGM_CISCO_SET_IPADDR. This command is also - by - this node type to the inet peer whenever an IP - address inquiry packet is received.
-
- (getstats)
-
Returns a struct ngciscostat: -
- 
struct ngciscostat {
-  uint32_t   seqRetries;	/* # unack'd retries */
-  uint32_t   keepAlivePeriod;	/* in seconds */
-};
-
-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_iface(4), - ngctl(8)

-

D. Perkins, - Requirements for an Internet Standard Point-to-Point - Protocol, RFC 1547.

-
-
-

-

Cisco is a trademark of Cisco Systems, Inc.

-
-
-

-

The ng_cisco node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org> -
- Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

Not all of the functionality has been implemented. For example, - the node does not support querying the remote end for its IP address and - netmask.

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_deflate.4 3.html b/static/freebsd/man4/ng_deflate.4 3.html deleted file mode 100644 index 0a86e525..00000000 --- a/static/freebsd/man4/ng_deflate.4 3.html +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - -
NG_DEFLATE(4)Device Drivers ManualNG_DEFLATE(4)
-
-
-

-

ng_deflate — - Deflate PPP compression (RFC 1979) netgraph node - type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_deflate.h>

-
-
-

-

The deflate node type implements the - Deflate sub-protocols of the Compression Control Protocol (CCP).

-

The node has two hooks, comp for compression - and decomp for decompression. Only one of them can be - connected at the same time, specifying node's operation mode. Typically that - hooks would be connected to the ng_ppp(4) node type hook - of the same name. Corresponding ng_ppp(4) node hook must - be switched to NG_PPP_DECOMPRESS_FULL mode to permit - sending uncompressed frames.

-
-
-

-

This node type supports the following hooks:

-

-
-
comp
-
Connection to ng_ppp(4) comp hook. - Incoming frames are compressed (if possible) and sent back out the same - hook.
-
decomp
-
Connection to ng_ppp(4) decomp - hook. Incoming frames are decompressed (if they are compressed), and sent - back out the same hook.
-
-

Only one hook can be connected at the same time, specifying node's - operation mode.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (config)
-
This command resets and configures the node for a session (i.e., for - compression or decompression). This command takes a struct - ng_deflate_config as an argument: -
- 
struct ng_deflate_config {
-	u_char	enable;			/* node enabled */
-	u_char	windowBits;		/* log2(Window size) */
-};
-
- The enabled field enables traffic flow through the - node. The windowBits specify compression windows - size as negotiated by the Compression Control Protocol (CCP) in PPP.
-
- (resetreq)
-
This message contains no arguments, and is bi-directional. If an error is - detected during decompression, this message is sent by the node to the - originator of the NGM_DEFLATE_CONFIG message that - initiated the session. The receiver should respond by sending a PPP CCP - Reset-Request to the peer. -

This message may also be received by this node type when a CCP - Reset-Request or Reset-Ack is received by the local PPP entity. The node - will respond by flushing its compression state so the sides can - resynchronize.

-
-
- (getstats)
-
This control message obtains statistics for a given hook. The statistics - are returned in struct ng_deflate_stats: -
- 
struct ng_deflate_stats {
-	uint64_t	FramesPlain;
-	uint64_t	FramesComp;
-	uint64_t	FramesUncomp;
-	uint64_t	InOctets;
-	uint64_t	OutOctets;
-	uint64_t	Errors;
-};
-
-
-
- (clrstats)
-
This control message clears statistics for a given hook.
-
- (getclrstats)
-
This control message obtains and clears statistics for a given hook.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when hook have been - disconnected.

-
-
-

-

netgraph(4), ng_ppp(4), - ngctl(8)

-

J. Woods, - PPP Deflate Protocol, RFC - 1979.

-

W. Simpson, - The Point-to-Point Protocol (PPP), - RFC 1661.

-
-
-

-

Alexander Motin - <mav@alkar.net>

-
-
-

-

Due to nature of netgraph PPP implementation there are possible - race conditions between data packet and ResetAck CCP packet in case of - packet loss. As result, packet loss can produce bigger performance - degradation than supposed by protocol.

-
-
- - - - - -
December 23, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_device.4 3.html b/static/freebsd/man4/ng_device.4 3.html deleted file mode 100644 index f9478a2b..00000000 --- a/static/freebsd/man4/ng_device.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
NG_DEVICE(4)Device Drivers ManualNG_DEVICE(4)
-
-
-

-

ng_device — device - netgraph node type

-
-
-

-

#include - <netgraph/ng_device.h>

-
-
-

-

A device node is both a netgraph node and - a system device interface. When a device node is - created, a new device entry appears which is accessible via the regular file - operators such as open(2), close(2), - read(2), write(2), etc.

-

The first node is created as /dev/ngd0, - subsequent nodes are /dev/ngd1, - /dev/ngd2, etc.

-
-
-

-

A device node has a single hook with an - arbitrary name. All data coming in over the hook will be presented to the - device for read(2). All data coming in from the device - entry by write(2) will be forwarded to the hook.

-
-
-

-

The device node supports the generic - control messages, plus the following:

-
-
-
Returns the device name corresponding to the node.
-
-
Apply the system ETHER_ALIGN offset to mbufs sent out the node's hook, if - running on an architecture that requires strict alignment. Use this option - when the data being injected via the device node ultimately ends up being - fed into the protocol stack as ethernet packets (e.g., via an - ng_eiface(4) node).
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or upon hook - disconnection. The associated device entry is removed and becomes available - for use by future device nodes.

-
-
-

-

netgraph(4), ngctl(8)

-
-
-

-

The device node type was first implemented - in FreeBSD 5.0.

-
-
-

-

Mark Santcroos - <marks@ripe.net> -
- Gleb Smirnoff - <glebius@FreeBSD.org>

-
-
- - - - - -
November 8, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_echo.4 4.html b/static/freebsd/man4/ng_echo.4 4.html deleted file mode 100644 index 88712cc4..00000000 --- a/static/freebsd/man4/ng_echo.4 4.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
NG_ECHO(4)Device Drivers ManualNG_ECHO(4)
-
-
-

-

ng_echo — netgraph - echo node type

-
-
-

-

#include - <netgraph/ng_echo.h>

-
-
-

-

The echo node type reflects all data and - control messages back to the sender. This node type is used for testing and - debugging.

-
-
-

-

A echo node accepts any request to - connect, regardless of the hook name, as long as the name is unique.

-
-
-

-

This node type supports only the generic control messages. Any - other control messages are reflected back to the sender.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_hole(4), - ngctl(8)

-
-
-

-

The ng_echo node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_eiface.4 3.html b/static/freebsd/man4/ng_eiface.4 3.html deleted file mode 100644 index e33b63c3..00000000 --- a/static/freebsd/man4/ng_eiface.4 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
NG_EIFACE(4)Device Drivers ManualNG_EIFACE(4)
-
-
-

-

ng_eiface — - generic Ethernet interface netgraph node type

-
-
-

-

#include - <netgraph/ng_eiface.h>

-
-
-

-

The eiface netgraph node implements the - generic Ethernet interface. When an eiface node is - created, a new interface appears which is accessible via - ifconfig(8). These interfaces are named - “ngeth0”, - “ngeth1”, etc. When a node is shut - down, the corresponding interface is removed, and the interface name becomes - available for reuse by future eiface nodes. New nodes - always take the first unused interface.

-
-
-

-

An eiface node has a single hook named - ether, which should be connected to the Ethernet - downstream, for example, to the ng_vlan(4) node. Packets - transmitted via the interface flow out this hook. Similarly, packets - received on the hook go to the protocol stack as packets received by any - real Ethernet interface.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (set)
-
Set link-level address of the interface. Requires struct - ether_addr as an argument. This message also has an ASCII version, - called “set”, which requires as an - argument an ASCII string consisting of 6 colon-separated hex digits.
-
- (getifname)
-
Return the name of the associated interface as a - NULL-terminated ASCII string.
-
-
Return the list of link-level addresses associated with the node.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message. The associated - interface is removed and its name becomes available for reuse by future - eiface nodes.

-

Unlike most other node types, an - eiface node does - go away when all - hooks have been disconnected; rather, an explicit - NGM_SHUTDOWN control message is required.

-
-
-

-

netgraph(4), ng_ether(4), - ng_iface(4), ng_vlan(4), - ifconfig(8), ngctl(8)

-
-
-

-

The eiface node type was implemented in - FreeBSD 4.6.

-
-
-

-

The eiface node type was written by - Vitaly V Belekhov. This manual page was written by - Gleb Smirnoff.

-
-
- - - - - -
May 14, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_etf.4 3.html b/static/freebsd/man4/ng_etf.4 3.html deleted file mode 100644 index 901ddd73..00000000 --- a/static/freebsd/man4/ng_etf.4 3.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - -
NG_ETF(4)Device Drivers ManualNG_ETF(4)
-
-
-

-

ng_etf — Ethertype - filtering netgraph node type

-
-
-

-

#include - <netgraph.h> -
- #include - <netgraph/ng_etf.h>

-
-
-

-

The etf node type multiplexes and filters - data between hooks on the basis of the ethertype found in an Ethernet - header, presumed to be in the first 14 bytes of the data. Incoming Ethernet - frames are accepted on the downstream hook and if the - ethertype matches a value which the node has been configured to filter, the - packet is forwarded out the hook which was identified at the time that value - was configured. If it does not match a configured value, it is passed to the - nomatch hook. If the nomatch hook is not - connected, the packet is dropped.

-

Packets travelling in the other direction (towards the - downstream hook) are also examined and filtered. If a - packet has an ethertype that matches one of the values configured into the - node, it must have arrived in on the hook for which that value was - configured, otherwise it will be discarded. Ethertypes of values other than - those configured by the control messages must have arrived via the - nomatch hook.

-
-
-

-

This node type supports the following hooks:

-
-
-
Typically this hook would be connected to a ng_ether(4) - node, using the - - hook.
-
-
Typically this hook would also be connected to an - ng_ether(4) type node using the - - hook.
-
⟨⟩
-
Any other hook name will be accepted and can be used as the match target - of an ethertype. Typically this hook would be attached to a protocol - handling node that requires and generates packets with a particular set of - ethertypes.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (getstatus)
-
This command returns a struct ng_etfstat containing - node statistics for packet counts.
-
- (setfilter)
-
Sets the a new ethertype filter into the node and specifies the hook to - and from which packets of that type should use. The hook and ethertype are - specified in a structure of type struct - ng_etffilter: -
- 
struct ng_etffilter {
-    char	matchhook[NG_HOOKSIZ];	/* hook name */
-    uint16_t	ethertype;		/* this ethertype to this hook */
-};
-
-
-
-
-
-

-

Using ngctl(8) it is possible to set a filter in - place from the command line as follows:

-
-
#!/bin/sh
-ETHER_IF=fxp0
-MATCH1=0x834
-MATCH2=0x835
-cat <<DONE >/tmp/xwert
-# Make a new ethertype filter and attach to the Ethernet lower hook.
-# first remove left over bits from last time.
-shutdown ${ETHER_IF}:lower
-mkpeer ${ETHER_IF}: etf lower downstream
-# Give it a name to easily refer to it.
-name ${ETHER_IF}:lower etf
-# Connect the nomatch hook to the upper part of the same interface.
-# All unmatched packets will act as if the filter is not present.
-connect ${ETHER_IF}: etf: upper nomatch
-DONE
-ngctl -f /tmp/xwert
-
-# something to set a hook to catch packets and show them.
-echo "Unrecognised packets:"
-nghook -a etf: newproto &
-# Filter two random ethertypes to that hook.
-ngctl 'msg etf: setfilter { matchhook="newproto" ethertype=${MATCH1} }
-ngctl 'msg etf: setfilter { matchhook="newproto" ethertype=${MATCH2} }
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_ether(4), - ngctl(8), nghook(8)

-
-
-

-

The ng_etf node type was implemented in - FreeBSD 5.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ether.4 3.html b/static/freebsd/man4/ng_ether.4 3.html deleted file mode 100644 index a5e1ec66..00000000 --- a/static/freebsd/man4/ng_ether.4 3.html +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - -
NG_ETHER(4)Device Drivers ManualNG_ETHER(4)
-
-
-

-

ng_ether — - Ethernet netgraph node type

-
-
-

-

#include - <netgraph/ng_ether.h>

-
-
-

-

The ether netgraph node type allows - Ethernet interfaces to interact with the netgraph(4) - networking subsystem. Once the ng_ether module is - loaded into the kernel, a node is automatically created for each Ethernet - interface in the system. Each node will attempt to name itself with the same - name as the associated interface.

-

Three hooks are supported: lower, - upper, and orphans. The hook - name divert may be used as an alias for - lower, and is provided for backward compatibility. In - reality, the two names represent the same hook.

-

The lower hook is a connection to the raw - Ethernet device. When connected, all incoming packets are forwarded to this - hook, instead of being passed to the kernel for upper layer processing. - Writing to this hook results in a raw Ethernet frame being transmitted by - the device. Normal outgoing packets are not affected by - lower being connected.

-

The upper hook is a connection to the upper - protocol layers. When connected, all outgoing packets are forwarded to this - hook, instead of being transmitted by the device. Writing to this hook - results in a raw Ethernet frame being received by the kernel just as if it - had come in over the wire. Normal incoming packets are not affected by - upper being connected.

-

The orphans hook is equivalent to - lower, except that only unrecognized packets (that - would otherwise be discarded) are written to the hook, while other normal - incoming traffic is unaffected. Unrecognized packets written to - upper will be forwarded back out to - orphans if connected.

-

In all cases, frames are raw Ethernet frames with the standard 14 - byte Ethernet header (but no checksum).

-

When no hooks are connected, upper and - lower are in effect connected together, so that - packets flow normally upwards and downwards.

-
-
-

-

This node type supports the following hooks:

-
-
lower
-
Connection to the lower device link layer.
-
upper
-
Connection to the upper protocol layers.
-
orphans
-
Like lower, but only receives unrecognized - packets.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (getifname)
-
Returns the name of the associated interface as a - NUL-terminated ASCII string. Normally this is the - same as the name of the node.
-
- (getifindex)
-
Returns the global index of the associated interface as a 32 bit - integer.
-
- (getenaddr)
-
Returns the device's unique six byte Ethernet address.
-
- (setenaddr)
-
Sets the device's unique six byte Ethernet address. This control message - is equivalent to using the SIOCSIFLLADDR - ioctl(2) system call.
-
- (setpromisc)
-
Enable or disable promiscuous mode. This message includes a single 32 bit - integer flag that enables or disables promiscuous mode on the interface. - Any non-zero value enables promiscuous mode.
-
- (getpromisc)
-
Get the current value of the node's promiscuous flag. The returned value - is always either one or zero. Note that this flag reflects the node's own - promiscuous setting and does not necessarily reflect the promiscuous state - of the actual interface, which can be affected by other means (e.g., - bpf(4)).
-
- (setautosrc)
-
Sets the automatic source address override flag. This message includes a - single 32 bit integer flag that causes all outgoing packets to have their - source Ethernet address field overwritten with the device's unique - Ethernet address. If this flag is set to zero, the source address in - outgoing packets is not modified. The default setting for this flag is - disabled.
-
- (getautosrc)
-
Get the current value of the node's source address override flag. The - returned value is always either one or zero.
-
- (addmulti)
-
Join Ethernet multicast group. This control message is equivalent to using - the SIOCADDMULTI ioctl(2) system - call.
-
- (delmulti)
-
Leave Ethernet multicast group. This control message is equivalent to - using the SIOCDELMULTI ioctl(2) - system call.
-
- (detach)
-
Detach from underlying Ethernet interface and shut down node.
-
-
-
-

-

Upon receipt of the NGM_SHUTDOWN control - message, all hooks are disconnected, promiscuous mode is disabled, but the - node is not removed. Node can be shut down only using - NGM_ETHER_DETACH control message. If the interface - itself is detached (e.g., because of PC Card removal), the node disappears - as well.

-
-
-

-

This command dumps all unrecognized packets received by the - “fxp0” interface to standard output - decoded in hex and ASCII:

-

-
nghook -a fxp0: orphans
-

This command sends the contents of - sample.pkt out the interface - “fxp0”:

-

-
cat sample.pkt | nghook fxp0: - orphans
-

These commands insert an ng_tee(4) node between - the lower and upper protocol - layers, which can be used for tracing packet flow, statistics, etc.:

-
-
ngctl mkpeer fxp0: tee lower right
-ngctl connect fxp0: lower upper left
-
-
-
-

-

arp(4), netgraph(4), - netintro(4), ifconfig(8), - ngctl(8), nghook(8)

-
-
-

-

Julian Elischer - <julian@FreeBSD.org> -
- Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

The automatic KLD module loading mechanism that works for most - other Netgraph node types does not work for the - ether node type, because - ether nodes are not created on demand; instead, they - are created when Ethernet interfaces are attached or when the KLD is first - loaded. Therefore, if the KLD is not statically compiled into the kernel, it - is necessary to load the KLD manually in order to bring the - ether nodes into existence.

-
-
- - - - - -
June 23, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ether_echo.4 4.html b/static/freebsd/man4/ng_ether_echo.4 4.html deleted file mode 100644 index d9182754..00000000 --- a/static/freebsd/man4/ng_ether_echo.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
NG_ETHER_ECHO(4)Device Drivers ManualNG_ETHER_ECHO(4)
-
-
-

-

ng_ether_echo — - netgraph ether_echo node type

-
-
-

-

#include - <netgraph/ng_ether_echo.h>

-
-
-

-

The ether_echo node type reflects all data - and control messages back to the sender. It assumes (and does not check) - that the packet is an ethernet frame, and swaps the source and destination - addresses before echoing it. This node type is used for testing and - debugging.

-
-
-

-

A ether_echo node accepts any request to - connect, regardless of the hook name, as long as the name is unique.

-
-
-

-

This node type supports only the generic control messages. Any - other control messages are reflected back to the sender.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_echo(4), - ng_ether(4), ng_hole(4), - ngctl(8)

-
-
-

-

The ng_ether_echo node type was - implemented in FreeBSD 8.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
December 24, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_frame_relay.4 3.html b/static/freebsd/man4/ng_frame_relay.4 3.html deleted file mode 100644 index f7c541f8..00000000 --- a/static/freebsd/man4/ng_frame_relay.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
NG_FRAME_RELAY(4)Device Drivers ManualNG_FRAME_RELAY(4)
-
-
-

-

ng_frame_relay — - frame relay netgraph node type

-
-
-

-

#include - <netgraph/ng_frame_relay.h>

-
-
-

-

The frame_relay node type performs - encapsulation, de-encapsulation, and multiplexing of packets using the frame - relay protocol. It supports up to 1024 DLCI's. The LMI protocol is handled - by a separate node type (see ng_lmi(4)).

-

The downstream hook should be connected to - the synchronous line, i.e., the switch. Then hooks - dlci0, dlci1, through - dlci1023 are available to connect to each of the - DLCI channels.

-
-
-

-

This node type supports the following hooks:

-
-
downstream
-
The connection to the synchronous line.
-
dlciX
-
Here X is a decimal number from 0 to 1023. This hook corresponds to the - DLCI X frame relay virtual channel.
-
-
-
-

-

This node type supports only the generic control messages.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_lmi(4), - ngctl(8)

-
-
-

-

The ng_frame_relay node type was - implemented in FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
-

-

Technically, frames on DLCI X should not be transmitted to the - switch until the LMI protocol entity on both ends has configured DLCI X as - active. The ng_frame_relay node type ignores this - restriction, and will always pass data received on a DLCI hook to - downstream. Instead, it should query the LMI node - first.

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_gif.4 3.html b/static/freebsd/man4/ng_gif.4 3.html deleted file mode 100644 index e8a9c6b1..00000000 --- a/static/freebsd/man4/ng_gif.4 3.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
NG_GIF(4)Device Drivers ManualNG_GIF(4)
-
-
-

-

ng_gif — generic - tunnel interface netgraph node type

-
-
-

-

#include - <netgraph/ng_gif.h>

-
-
-

-

The ng_gif netgraph node type allows - gif(4) interfaces to interact with the - netgraph(4) networking subsystem. Once the - ng_gif module is loaded in the kernel, a node is - automatically created for each gif(4) interface in the - system. Each node will attempt to name itself with the same name as the - associated interface. All ng_gif nodes are - persistent for as long as the interface itself exists.

-

Two hooks are supported: lower and - orphans. The hook name - divert may be used as an alias for - lower, and is provided for compatibility with - ng_ether(4). In reality the two names represent the same - hook.

-

The lower hook is a connection to the raw - gif(4) device. When connected, all incoming packets are - diverted out this hook. Writing to this hook results in a raw encapsulated - packet being transmitted by the device. Normal outgoing packets are not - affected by lower being connected.

-

The orphans hook is equivalent to - lower, except that only unrecognized packets (that - would otherwise be discarded) are written to the hook, and normal incoming - traffic is unaffected. At most one of orphans and - lower may be connected at any time.

-

In all cases, frames are raw packets with the address family of - the packet attached to the front.

-

When no hooks are connected, packets flow normally upwards and - downwards.

-
-
-

-

This node type supports the following hooks:

-
-
lower
-
Connection to the lower device link layer.
-
orphans
-
Like lower, but only receives unrecognized - packets.
-
-
-
-

-

This node type supports only the generic control messages.

-
-
-

-

This command dumps all unrecognized packets received by the - gif0 interface to standard output decoded in hex and - ASCII:

-

-
nghook -a gif0: orphans
-
-
-

-

gif(4), netgraph(4), - netintro(4), ifconfig(8), - ngctl(8), nghook(8)

-
-
-

-

Brooks Davis - <brooks@FreeBSD.org>

-
-
- - - - - -
September 18, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_gif_demux.4 4.html b/static/freebsd/man4/ng_gif_demux.4 4.html deleted file mode 100644 index 3757f155..00000000 --- a/static/freebsd/man4/ng_gif_demux.4 4.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
NG_GIF_DEMUX(4)Device Drivers ManualNG_GIF_DEMUX(4)
-
-
-

-

ng_gif_demux — - demultiplexer for packets from ng_gif(4) - nodes

-
-
-

-

#include - <netgraph/ng_gif_demux.h>

-
-
-

-

The ng_gif_demux netgraph node type - demultiplexes the output from ng_gif(4) nodes in the - netgraph(4) networking subsystem.

-

The gif hook is meant to be connected to - the lower or orphans hook of - an ng_gif(4) node. The inet, - inet6, atalk, - ipx, atm, - natm, and ns hooks output - frames of the given type when they are received on the - gif hook. When a frame is received on one of these - hooks, it is encapsulated and sent out the gif - hook.

-
-
-

-

This node type supports the following hooks:

-
-
gif
-
Connection to the lower or - orphans hook of an ng_gif(4) - node.
-
inet
-
Hook for input and output of IP frames.
-
inet6
-
Hook for input and output of IPv6 frames.
-
atalk
-
Hook for input and output of AppleTalk frames.
-
ipx
-
Hook for input and output of IPX frames.
-
atm
-
Hook for input and output of ATM frames.
-
natm
-
Hook for input and output of NATM frames.
-
ns
-
Hook for input and output of NS frames.
-
-
-
-

-

This node type supports only the generic control messages.

-
-
-

-

gif(4), netgraph(4), - netintro(4), ng_gif(4), - ifconfig(8), ngctl(8), - nghook(8)

-
-
-

-

Brooks Davis - <brooks@FreeBSD.org>

-
-
- - - - - -
September 18, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_hci.4 3.html b/static/freebsd/man4/ng_hci.4 3.html deleted file mode 100644 index a8d31ef5..00000000 --- a/static/freebsd/man4/ng_hci.4 3.html +++ /dev/null @@ -1,370 +0,0 @@ - - - - - - -
NG_HCI(4)Device Drivers ManualNG_HCI(4)
-
-
-

-

ng_hci — Netgraph - node type that is also a Bluetooth Host Controller Interface (HCI) - layer

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/bluetooth/include/ng_hci.h>

-
-
-

-

The hci node type is a Netgraph node type - that implements Bluetooth Host Controller Interface (HCI) layer as per - chapter H1 of the Bluetooth Specification Book v1.1.

-
-
-

-

Bluetooth is a short-range radio link intended to replace the - cable(s) connecting portable and/or fixed electronic devices. Bluetooth - operates in the unlicensed ISM band at 2.4 GHz. The Bluetooth protocol uses - a combination of circuit and packet switching. Bluetooth can support an - asynchronous data channel, up to three simultaneous synchronous voice - channels, or a channel which simultaneously supports asynchronous data and - synchronous voice. Each voice channel supports a 64 kb/s synchronous (voice) - channel in each direction. The asynchronous channel can support maximal - 723.2 kb/s asymmetric (and still up to 57.6 kb/s in the return direction), - or 433.9 kb/s symmetric.

-

The Bluetooth system provides a point-to-point connection (only - two Bluetooth units involved), or a point-to-multipoint connection. In the - point-to-multipoint connection, the channel is shared among several - Bluetooth units. Two or more units sharing the same channel form a - “piconet”. One Bluetooth unit acts as the master of the - piconet, whereas the other unit(s) acts as slave(s). Up to seven slaves can - be active in the piconet. In addition, many more slaves can remain locked to - the master in a so-called parked state. These parked slaves cannot be active - on the channel, but remain synchronized to the master. Both for active and - parked slaves, the channel access is controlled by the master.

-

Multiple piconets with overlapping coverage areas form a - “scatternet”. Each piconet can only have a single master. - However, slaves can participate in different piconets on a time-division - multiplex basis. In addition, a master in one piconet can be a slave in - another piconet. The piconets shall not be frequency-synchronized. Each - piconet has its own hopping channel.

-
-

-

The channel is divided into time slots, each 625 usec in length. - The time slots are numbered according to the Bluetooth clock of the piconet - master. The slot numbering ranges from 0 to 2^27 -1 and is cyclic with a - cycle length of 2^27. In the time slots, master and slave can transmit - packets.

-
-
- -

The SCO link is a symmetric, point-to-point link between the - master and a specific slave. The SCO link reserves slots and can therefore - be considered as a circuit-switched connection between the master and the - slave. The SCO link typically supports time-bounded information like voice. - The master can support up to three SCO links to the same slave or to - different slaves. A slave can support up to three SCO links from the same - master, or two SCO links if the links originate from different masters. SCO - packets are never retransmitted.

-
-
- -

In the slots not reserved for SCO links, the master can exchange - packets with any slave on a per-slot basis. The ACL link provides a - packet-switched connection between the master and all active slaves - participating in the piconet. Both asynchronous and isochronous services are - supported. Between a master and a slave only a single ACL link can exist. - For most ACL packets, packet retransmission is applied to assure data - integrity.

-
-
-
-

-

The HCI provides a command interface to the baseband controller - and link manager, and access to hardware status and control registers. This - interface provides a uniform method of accessing the Bluetooth baseband - capabilities.

-

The HCI layer on the Host exchanges data and commands with the HCI - firmware on the Bluetooth hardware. The Host Controller Transport Layer - (i.e., physical bus) driver provides both HCI layers with the ability to - exchange information with each other.

-

The Host will receive asynchronous notifications of HCI events - independent of which Host Controller Transport Layer is used. HCI events are - used for notifying the Host when something occurs. When the Host discovers - that an event has occurred it will then parse the received event packet to - determine which event occurred. The next sections specify the HCI packet - formats.

-
-

-
-
#define NG_HCI_CMD_PKT 0x01
-typedef struct {
-        uint8_t  type;   /* MUST be 0x1 */
-        uint16_t opcode; /* OpCode */
-        uint8_t  length; /* parameter(s) length in bytes */
-} __attribute__ ((packed)) ng_hci_cmd_pkt_t;
-
-

The HCI command packet is used to send commands to the Host - Controller from the Host. When the Host Controller completes most of the - commands, a Command Complete event is sent to the Host. Some commands do not - receive a Command Complete event when they have been completed. Instead, - when the Host Controller receives one of these commands the Host Controller - sends a Command Status event back to the Host when it has begun to execute - the command. Later on, when the actions associated with the command have - finished, an event that is associated with the sent command will be sent by - the Host Controller to the Host.

-
-
-

-
-
#define NG_HCI_EVENT_PKT 0x04
-typedef struct {
-        uint8_t type;   /* MUST be 0x4 */
-        uint8_t event;  /* event */
-        uint8_t length; /* parameter(s) length in bytes */
-} __attribute__ ((packed)) ng_hci_event_pkt_t;
-
-

The HCI event packet is used by the Host Controller to notify the - Host when events occur.

-
-
-

-
-
#define NG_HCI_ACL_DATA_PKT 0x02
-typedef struct {
-        uint8_t  type;       /* MUST be 0x2 */
-        uint16_t con_handle; /* connection handle + PB + BC flags */
-        uint16_t length;     /* payload length in bytes */
-} __attribute__ ((packed)) ng_hci_acldata_pkt_t;
-
-

HCI ACL data packets are used to exchange ACL data between the - Host and Host Controller.

-
-
-

-
-
#define NG_HCI_SCO_DATA_PKT 0x03
-typedef struct {
-        uint8_t  type;       /* MUST be 0x3 */
-        uint16_t con_handle; /* connection handle + reserved bits */
-        uint8_t  length;     /* payload length in bytes */
-} __attribute__ ((packed)) ng_hci_scodata_pkt_t;
-
-

HCI SCO data packets are used to exchange SCO data between the - Host and Host Controller.

-
-
-
-

-

On initialization, HCI control application must issue the - following HCI commands (in any order).

-
-
-
To obtain BD_ADDR of the Bluetooth unit.
-
-
To obtain the list of features supported by Bluetooth unit.
-
-
To determine the maximum size of HCI ACL and SCO HCI data packets - (excluding header) that can be sent from the Host to the Host Controller. - There are also two additional return parameters that specify the total - number of HCI ACL and SCO data packets that the Host Controller can have - waiting for transmission in its buffers.
-
-

As soon as HCI initialization has been successfully performed, HCI - control application must turn on “inited” bit for the node. - Once HCI node has been initialized all upstream hooks will receive a - NGM_HCI_NODE_UP Netgraph message defined as - follows.

-
-
#define NGM_HCI_NODE_UP 112 /* HCI -> Upper */
-typedef struct {
-        uint16_t  pkt_size; /* max. ACL/SCO packet size (w/o hdr) */
-        uint16_t  num_pkts; /* ACL/SCO packet queue size */
-        uint16_t  reserved; /* place holder */
-        bdaddr_t  bdaddr;   /* bdaddr */
-} ng_hci_node_up_ep;
-
-
-
-

-

HCI layer performs flow control on baseband connection basis - (i.e., ACL and SCO link). Each baseband connection has “connection - handle” and queue of outgoing data packets. Upper layers protocols - are allowed to send up to (num_pkts - - pending) packets at one time. HCI layer will send - NGM_HCI_SYNC_CON_QUEUE Netgraph messages to inform - upper layers about current queue state for each connection handle. The - NGM_HCI_SYNC_CON_QUEUE Netgraph message is defined - as follows.

-
-
#define NGM_HCI_SYNC_CON_QUEUE 113 /* HCI -> Upper */
-typedef struct {
-        uint16_t con_handle; /* connection handle */
-        uint16_t completed;  /* number of completed packets */
-} ng_hci_sync_con_queue_ep;
-
-
-
-

-

This node type supports the following hooks:

-
-
drv
-
Bluetooth Host Controller Transport Layer hook. Single HCI packet - contained in single mbuf structure.
-
acl
-
Upper layer protocol/node is connected to the hook. Single HCI ACL data - packet contained in single mbuf structure.
-
sco
-
Upper layer protocol/node is connected to the hook. Single HCI SCO data - packet contained in single mbuf structure.
-
raw
-
Raw hook. Every HCI frame (including HCI command frame) that goes in or - out will be delivered to the hook. Usually the Bluetooth raw HCI socket - layer is connected to the hook. Single HCI frame contained in single - mbuf structure.
-
-
-
-

-
-
-
Requests the lower protocol to create a connection. If a physical link to - the remote device does not exist, this message must be sent to the lower - protocol (baseband) to establish the physical connection.
-
-
Requests the lower protocol (baseband) to terminate a connection.
-
-
Confirms success or failure of the - NGM_HCI_LP_CON_REQ request to establish a lower - layer (baseband) connection. This includes passing the authentication - challenge if authentication is required to establish the physical - link.
-
-
Indicates the lower protocol (baseband) has successfully established - incoming connection.
-
-
A response accepting or rejecting the previous connection indication - request.
-
-
Indicates the lower protocol (baseband) has terminated connection. This - could be a response to NGM_HCI_LP_DISCON_REQ or a - timeout event.
-
-
Requests the lower protocol (baseband) to accommodate a particular QoS - parameter set.
-
-
Confirms success or failure of the request for a given quality of - service.
-
-
Indicates the lower protocol (baseband) has detected a violation of the - QoS agreement.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
Returns current state for the node.
-
-
Turn on “inited” bit for the node.
-
-
Returns an integer containing the current debug level for the node.
-
-
This command takes an integer argument and sets current debug level for - the node.
-
-
Returns current state of data buffers.
-
-
Returns BD_ADDR as cached in the node.
-
-
Returns the list of features supported by hardware (as cached by the - node).
-
-
Returns content of the neighbor cache.
-
-
Remove all neighbor cache entries.
-
-
Returns list of active baseband connections (i.e., ACL and SCO - links).
-
-
Returns various statistic counters.
-
-
Resets all statistic counters to zero.
-
NGM_HCI_NODE_SET_LINK_POLICY_SETTINGS_MASK
-
Sets current link policy settings mask. After the new ACL connection is - created the HCI node will try set link policy for the ACL connection. By - default, every supported Link Manager (LM) mode will be enabled. User can - override this by setting link policy settings mask which specifies LM - modes to be enabled.
-
NGM_HCI_NODE_GET_LINK_POLICY_SETTINGS_MASK
-
Returns current link policy settings mask.
-
NGM_HCI_NODE_SET_PACKET_MASK
-
Sets current packet mask. When new baseband (ACL or SCO) connection is - created the HCI node will specify every packet type supported by the - device. User can override this by setting packet mask which specifies - packet types to be used for new baseband connections.
-
NGM_HCI_NODE_GET_PACKET_MASK
-
Returns current packet mask.
-
NGM_HCI_NODE_SET_ROLE_SWITCH
-
Sets the value of the role switch. Role switch is enabled when this value - is not zero. This is the default state. Note that actual role switch at - Bluetooth link level will only be performed if hardware supports role - switch and it was enabled.
-
NGM_HCI_NODE_GET_ROLE_SWITCH
-
Returns the value of the role switch for the node.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), hccontrol(8), - ngctl(8)

-
-
-

-

The hci node type was implemented in - FreeBSD 5.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

Most likely. Please report if found.

-
-
- - - - - -
June 25, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_hole.4 3.html b/static/freebsd/man4/ng_hole.4 3.html deleted file mode 100644 index 150fc6ce..00000000 --- a/static/freebsd/man4/ng_hole.4 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
NG_HOLE(4)Device Drivers ManualNG_HOLE(4)
-
-
-

-

ng_hole — netgraph - discard node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_hole.h>

-
-
-

-

The hole node type silently discards all - data and control messages it receives. This type is used for testing and - debugging.

-
-
-

-

A ng_hole node accepts any request to - connect, regardless of the hook name, as long as the name is unique.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (getstats)
-
This command takes an ASCII string argument, the hook name, and returns - the statistics associated with the hook as a struct - ng_hole_hookstat.
-
- (clrstats)
-
This command takes an ASCII string argument, the hook name, and clears the - statistics associated with the hook.
-
- (getclrstats)
-
This command is identical to NGM_HOLE_GET_STATS, - except that the statistics are also atomically cleared.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_echo(4), - ngctl(8)

-
-
-

-

The ng_hole node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
May 19, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_hub.4 3.html b/static/freebsd/man4/ng_hub.4 3.html deleted file mode 100644 index 387f3e10..00000000 --- a/static/freebsd/man4/ng_hub.4 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
NG_HUB(4)Device Drivers ManualNG_HUB(4)
-
-
-

-

ng_hub — packet - distribution netgraph node type

-
-
-

-

#include - <netgraph/ng_hub.h>

-
-
-

-

The hub node type provides a simple - mechanism for distributing packets over several links. Packets received on - any of the hooks are forwarded out the other hooks. Packets are not altered - in any way.

-
-
-

-

A hub node accepts any request to connect, - regardless of the hook name, as long as the name is unique.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setpersistent)
-
This command sets the persistent flag on the node, and takes no - arguments.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected. Setting the persistent flag via a - NGM_HUB_SET_PERSISTENT control message disables - automatic node shutdown when the last hook gets disconnected.

-
-
-

-

netgraph(4), ng_bridge(4), - ng_ether(4), ng_one2many(4), - ngctl(8), nghook(8)

-
-
-

-

The ng_hub node type appeared in - FreeBSD 5.3.

-
-
-

-

Ruslan Ermilov - <ru@FreeBSD.org>

-
-
- - - - - -
May 5, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_iface.4 3.html b/static/freebsd/man4/ng_iface.4 3.html deleted file mode 100644 index 7e39da9b..00000000 --- a/static/freebsd/man4/ng_iface.4 3.html +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - -
NG_IFACE(4)Device Drivers ManualNG_IFACE(4)
-
-
-

-

ng_iface — - interface netgraph node type

-
-
-

-

#include - <netgraph/ng_iface.h>

-
-
-

-

An iface node is both a netgraph node and - a system networking interface. When an iface node is - created, a new interface appears which is accessible via - ifconfig(8). Iface node interfaces - are named ng0, ng1, etc. - When a node is shutdown, the corresponding interface is removed and the - interface name becomes available for reuse by future - iface nodes; new nodes always take the first unused - interface. The node itself is assigned the same name as its interface, - unless the name already exists, in which case the node remains unnamed.

-

An iface node has a single hook - corresponding to each supported protocol. Packets transmitted via the - interface flow out the corresponding protocol-specific hook. Similarly, - packets received on a hook appear on the interface as packets received into - the corresponding protocol stack. The currently supported protocols are IP - and IPv6.

-

An iface node can be configured as a - point-to-point interface or a broadcast interface. The configuration can - only be changed when the interface is down. The default mode is - point-to-point.

-

Iface nodes support the Berkeley Packet - Filter (BPF).

-
-
-

-

This node type supports the following hooks:

-
-
inet
-
Transmission and reception of IP packets.
-
inet6
-
Transmission and reception of IPv6 packets.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (getifname)
-
Returns the name of the associated interface as a - NUL-terminated ASCII string. Normally this is the - same as the name of the node.
-
- (getifindex)
-
Returns the global index of the associated interface as a 32 bit - integer.
-
- (point2point)
-
Set the interface to point-to-point mode. The interface must not currently - be up.
-
- (broadcast)
-
Set the interface to broadcast mode. The interface must not currently be - up.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message. The associated - interface is removed and becomes available for use by future - iface nodes.

-

Unlike most other node types, an - iface node does - go away when all - hooks have been disconnected; rather, and explicit - NGM_SHUTDOWN control message is required.

-
-
-

-

The ng_iface interface supports ALTQ - bandwidth management feature. However, ng_iface is a - special case, since it is not a physical interface with limited bandwidth. - One should not turn ALTQ on ng_iface if the latter - corresponds to some tunneled connection, e.g. PPPoE or PPTP. In this case, - ALTQ should be configured on the interface that is used to transmit the - encapsulated packets. In case when your graph ends up with some kind of - serial line, either synchronous or modem, the - ng_iface is the right place to turn ALTQ on.

-
-
-

-

ng_iface supports nesting, a configuration - when traffic of one ng_iface interface flows through - the other. The default maximum allowed nesting level is 2. It can be changed - at runtime setting sysctl(8) variable - net.graph.iface.max_nesting to the desired level of - nesting.

-
-
-

-

altq(4), bpf(4), - netgraph(4), ng_cisco(4), - ifconfig(8), ngctl(8), - sysctl(8)

-
-
-

-

The iface node type was implemented in - FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
- - - - - -
July 31, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ip_input.4 4.html b/static/freebsd/man4/ng_ip_input.4 4.html deleted file mode 100644 index 74dc50f5..00000000 --- a/static/freebsd/man4/ng_ip_input.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
NG_IP_INPUT(4)Device Drivers ManualNG_IP_INPUT(4)
-
-
-

-

ng_ip_input — - netgraph IP input node type

-
-
-

-

#include - <netgraph/ng_ip_input.h>

-
-
-

-

The ip_input node type takes all received - packets and queues them into the IP in input processing subsystem.

-
-
-

-

An ng_ip_input node accepts any request to - connect, regardless of the hook name, as long as the name is unique.

-
-
-

-

This node type supports only the generic control messages. Other - control messages are silently discarded.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ngctl(8)

-
-
-

-

The ng_ip_input node type was implemented - in FreeBSD 5.0.

-
-
-

-

Brooks Davis - <brooks@FreeBSD.org>

-
-
-

-

The ng_ip_input node type should probably - keep some sort of statistics.

-
-
- - - - - -
September 27, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ipfw.4 3.html b/static/freebsd/man4/ng_ipfw.4 3.html deleted file mode 100644 index d11fb748..00000000 --- a/static/freebsd/man4/ng_ipfw.4 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
NG_IPFW(4)Device Drivers ManualNG_IPFW(4)
-
-
-

-

ng_ipfw — - interface between netgraph and IP firewall

-
-
-

-

#include - <netinet/ip_var.h> -
- #include - <netgraph/ng_ipfw.h>

-
-
-

-

The ipfw node implements interface between - ipfw(4) and netgraph(4) subsystems.

-
-
-

-

The ipfw node supports an arbitrary number - of hooks, which must be named using only numeric characters.

-
-
-

-

Once the ng_ipfw module is loaded into the - kernel, a single node named ipfw is automatically - created. No more ipfw nodes can be created. Once - destroyed, the only way to recreate the node is to reload the - ng_ipfw module.

-

Packets can be injected into netgraph(4) using - either the netgraph or ngtee - commands of the ipfw(8) utility. These commands require a - numeric cookie to be supplied as an argument. Packets are sent out of the - hook whose name equals the cookie value. If no hook matches, packets are - discarded. Packets injected via the netgraph command - are tagged with struct ipfw_rule_ref. This tag - contains information that helps the packet to re-enter - ipfw(4) processing, should the packet come back from - netgraph(4) to ipfw(4).

-

Packets received by a node from netgraph(4) - subsystem must be tagged with struct ipfw_rule_ref - tag. Packets re-enter IP firewall processing at the next rule. If no tag is - supplied, packets are discarded.

-
-
-

-

This node type supports only the generic control messages.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message. Do not do this, since - the new ipfw node can only be created by reloading - the ng_ipfw module.

-
-
-

-

ipfw(4), netgraph(4), - ipfw(8), mbuf_tags(9)

-
-
-

-

The ipfw node type was implemented in - FreeBSD 6.0.

-
-
-

-

The ipfw node was written by - Gleb Smirnoff - <glebius@FreeBSD.org>.

-
-
- - - - - -
March 2, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ksocket.4 3.html b/static/freebsd/man4/ng_ksocket.4 3.html deleted file mode 100644 index 4aa1b0e9..00000000 --- a/static/freebsd/man4/ng_ksocket.4 3.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - -
NG_KSOCKET(4)Device Drivers ManualNG_KSOCKET(4)
-
-
-

-

ng_ksocket — - kernel socket netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_ksocket.h>

-
-
-

-

A ksocket node is both a netgraph node and - a BSD socket. The ng_ksocket - node type allows one to open a socket inside the kernel and have it appear - as a Netgraph node. The ng_ksocket node type is the - reverse of the socket node type (see ng_socket(4)): - whereas the socket node type enables the user-level manipulation (via a - socket) of what is normally a kernel-level entity (the associated Netgraph - node), the ng_ksocket node type enables the - kernel-level manipulation (via a Netgraph node) of what is normally a - user-level entity (the associated socket).

-

A ng_ksocket node allows at most one hook - connection. Connecting to the node is equivalent to opening the associated - socket. The name given to the hook determines what kind of socket the node - will open (see below). When the hook is disconnected and/or the node is - shutdown, the associated socket is closed.

-
-
-

-

This node type supports a single hook connection at a time. The - name of the hook must be of the form - , - where the - , - , and - - are the decimal equivalent of the same arguments to - socket(2). Alternately, aliases for the commonly used - values are accepted as well. For example - inet/dgram/udp is a more readable but equivalent - version of 2/2/17.

-

Data received into socket is sent out via hook. Data received on - hook is sent out from socket, if the latter is connected (an - NGM_KSOCKET_CONNECT was sent to node before). If - socket is not connected, destination struct sockaddr - must be supplied in an mbuf tag with cookie - NGM_KSOCKET_COOKIE and type - NG_KSOCKET_TAG_SOCKADDR attached to data. Otherwise - ng_ksocket will return - ENOTCONN to sender.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (bind)
-
This functions exactly like the bind(2) system call. The - struct sockaddr socket address parameter should be - supplied as an argument.
-
- (listen)
-
This functions exactly like the listen(2) system call. - The backlog parameter (a single 32 bit int) should - be supplied as an argument.
-
- (connect)
-
This functions exactly like the connect(2) system call. - The struct sockaddr destination address parameter - should be supplied as an argument.
-
- (accept)
-
Equivalent to the accept(2) system call on a - non-blocking socket. If there is a pending connection on the queue, a new - socket and a corresponding cloned node are created. Returned are the - cloned node's ID and a peer name (as struct - sockaddr). If there are no pending connections, this control message - returns nothing, and a connected node will receive the above message - asynchronously, when a connection is established. -

A cloned node supports a single hook with an arbitrary name. - If not connected, a node disappears when its parent node is destroyed. - Once connected, it becomes an independent node.

-
-
- (getname)
-
Equivalent to the getsockname(2) system call. The name - is returned as a struct sockaddr in the arguments - field of the reply.
-
- (getpeername)
-
Equivalent to the getpeername(2) system call. The name - is returned as a struct sockaddr in the arguments - field of the reply.
-
- (setopt)
-
Equivalent to the setsockopt(2) system call, except that - the option name, level, and value are passed in a struct - ng_ksocket_sockopt.
-
- (getopt)
-
Equivalent to the getsockopt(2) system call, except that - the option is passed in a struct ng_ksocket_sockopt. - When sending this command, the value field should - be empty; upon return, it will contain the retrieved value.
-
-
-
-

-

For control messages that pass a struct - sockaddr in the argument field, the normal ASCII equivalent of the C - structure is an acceptable form. For the PF_INET, - PF_INET6 and PF_LOCAL - address families, a more convenient form is also used, which is the protocol - family name, followed by a slash, followed by the actual address. For - PF_INET, the address is an IPv4 address followed by - an optional colon and port number. For PF_INET6, the - address is an IPv6 address enclosed in square brackets followed by an - optional colon and port number. For PF_LOCAL, the - address is the pathname as a doubly quoted string.

-

Examples:

-
-
-
local/"/tmp/foo.socket"
-
-
inet/192.168.1.1:1234
-
-
inet6/[2001::1]:1234
-
Other
-
-
-

For control messages that pass a struct - ng_ksocket_sockopt, the normal ASCII form for that structure is used. - In the future, more convenient encoding of the more common socket options - may be supported.

-

Setting socket options example:

-
-
Set FIB 2 for a socket (SOL_SOCKET, SO_SETFIB):
-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when the hook is - disconnected. Shutdown of the node closes the associated socket.

-
-
-

-

socket(2), netgraph(4), - ng_socket(4), ngctl(8), - mbuf_tags(9), socket(9)

-
-
-

-

The ng_ksocket node type was implemented - in FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
- - - - - -
January 9, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_l2cap.4 3.html b/static/freebsd/man4/ng_l2cap.4 3.html deleted file mode 100644 index 01162c9c..00000000 --- a/static/freebsd/man4/ng_l2cap.4 3.html +++ /dev/null @@ -1,378 +0,0 @@ - - - - - - -
NG_L2CAP(4)Device Drivers ManualNG_L2CAP(4)
-
-
-

-

ng_l2cap — - Netgraph node type that implements Bluetooth Logical Link - Control and Adaptation Protocol (L2CAP)

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/bluetooth/include/ng_hci.h> -
- #include - <netgraph/bluetooth/include/ng_l2cap.h>

-
-
-

-

The l2cap node type is a Netgraph node - type that implements Bluetooth Logical Link Control and Adaptation Protocol - as per chapter D of the Bluetooth Specification Book v1.1.

-

L2CAP provides connection-oriented and connectionless data - services to upper layer protocols with protocol multiplexing capability, - segmentation and reassembly operation, and group abstractions. L2CAP permits - higher level protocols and applications to transmit and receive L2CAP data - packets up to 64 kilobytes in length.

-
-

-
    -
  1. The ACL link between two units is set up. The Baseband provides orderly - delivery of data packets, although there might be individual packet - corruption and duplicates. No more than one ACL link exists between any - two devices.
    2. -
  2. The Baseband always provides the impression of full-duplex communication - channels. This does not imply that all L2CAP communications are - bi-directional. Multicasts and unidirectional traffic (e.g., video) do not - require duplex channels.
    3. -
  3. L2CAP provides a reliable channel using the mechanisms available at the - Baseband layer. The Baseband always performs data integrity checks when - requested and resends data until it has been successfully acknowledged or - a timeout occurs. As acknowledgements may be lost, timeouts may occur even - after the data has been successfully sent.
    4. -
-
-
-
-

-

The Logical Link Control and Adaptation Protocol (L2CAP) is based - around the concept of “channels”. Each channel is bound to a - single protocol in a many-to-one fashion. Multiple channels can be bound to - the same protocol, but a channel cannot be bound to multiple protocols. Each - L2CAP packet received on a channel is directed to the appropriate higher - level protocol.

-

Each one of the end-points of an L2CAP channel is referred to by a - channel identifier. Channel identifiers (CIDs) are local names representing - a logical channel end-point on the device. Identifiers from 0x0001 to 0x003F - are reserved for specific L2CAP functions. The null identifier (0x0000) is - defined as an illegal identifier and must never be used as a destination - end-point. All L2CAP signalling commands are sent to CID 0x0001. CID 0x0002 - is reserved for group-oriented channel. The same CID must not be reused as a - local L2CAP channel endpoint for multiple simultaneous L2CAP channels - between a local device and some remote device.

-

CID assignment is relative to a particular device and a device can - assign CIDs independently from other devices. Thus, even if the same CID - value has been assigned to (remote) channel endpoints by several remote - devices connected to a single local device, the local device can still - uniquely associate each remote CID with a different device.

-
-

-
-
-
In this state, there is no channel associated with this CID. This is the - only state when a link level connection (Baseband) may not exist. Link - disconnection forces all other states into the - NG_L2CAP_CLOSED state.
-
-
In this state, the CID represents a local end-point and an L2CAP Connect - Request message has been sent referencing this endpoint and it is now - waiting for the corresponding L2CAP Connect Response message.
-
-
In this state, the remote end-point exists and an L2CAP Connect Request - has been received by the local L2CAP entity. An L2CA Connect Indication - has been sent to the upper layer and the part of the local L2CAP entity - processing the received L2CAP Connect Request waits for the corresponding - response. The response may require a security check to be performed.
-
-
In this state, the connection has been established but both sides are - still negotiating the channel parameters. The Configuration state may also - be entered when the channel parameters are being renegotiated. Prior to - entering the NG_L2CAP_CONFIG state, all outgoing - data traffic is suspended since the traffic parameters of the data traffic - are to be renegotiated. Incoming data traffic is accepted until the remote - channel endpoint has entered the NG_L2CAP_CONFIG - state. In the NG_L2CAP_CONFIG state, both sides - will issue L2CAP Configuration Request messages if only defaults are being - used, a null message will be sent. If a large amount of parameters need to - be negotiated, multiple messages will be sent to avoid any MTU limitations - and negotiate incrementally. Moving from the - NG_L2CAP_CONFIG state to the - NG_L2CAP_OPEN state requires both sides to be - ready. An L2CAP entity is ready when it has received a positive response - to its final request and it has positively responded to the final request - from the remote device.
-
-
In this state, the connection has been established and configured, and - data flow may proceed.
-
-
In this state, the connection is shutting down and an L2CAP Disconnect - Request message has been sent. This state is now waiting for the - corresponding response.
-
-
In this state, the connection on the remote endpoint is shutting down and - an L2CAP Disconnect Request message has been received. An L2CA Disconnect - Indication has been sent to the upper layer to notify the owner of the CID - that the remote endpoint is being closed. This state is now waiting for - the corresponding response from the upper layer before responding to the - remote endpoint.
-
-
-
-

-

L2CAP supports protocol multiplexing because the Baseband Protocol - does not support any “type” field identifying the higher layer - protocol being multiplexed above it. L2CAP is able to distinguish between - upper layer protocols such as the Service Discovery Protocol, RFCOMM and - Telephony Control.

-
-
-

-

The data packets defined by the Baseband Protocol are limited in - size. Large L2CAP packets must be segmented into multiple smaller Baseband - packets prior to their transmission over the air. Similarly, multiple - received Baseband packets may be reassembled into a single larger L2CAP - packet.

-
-
-

-

The L2CAP connection establishment process allows the exchange of - information regarding the quality of service (QoS) expected between two - Bluetooth units.

-
-
-

-

The Baseband Protocol supports the concept of a piconet, a group - of devices synchronously hopping together using the same clock. The L2CAP - group abstraction permits implementations to efficiently map protocol groups - on to piconets.

-

The following features are outside the scope of L2CAP - responsibilities:

-
    -
  • L2CAP does not transport audio designated for SCO links.
    • -
  • L2CAP does not enforce a reliable channel or ensure data integrity, that - is, L2CAP performs no retransmissions or checksum calculations.
    • -
  • L2CAP does not support a reliable multicast channel.
    • -
  • L2CAP does not support the concept of a global group name.
    • -
-
-
-
-

-

This node type supports the following hooks:

-
-
hci
-
Bluetooth Host Controller Interface downstream hook.
-
l2c
-
Upper layer protocol upstream hook. Usually the Bluetooth L2CAP socket - layer is connected to the hook.
-
ctl
-
Control hook. Usually the Bluetooth raw L2CAP sockets layer is connected - to the hook.
-
-
-
-

-

Bluetooth specification says that L2CA request must block until - response is ready. L2CAP node uses token field from - Netgraph message header to match L2CA request and response. The upper layer - protocol must populate token. L2CAP node will queue - request and start processing. Later, when response is ready or timeout has - occurred, L2CAP node will create new Netgraph message, set - token and NFG_RESP flag and - send message to the upper layer. Note that L2CA indication messages will not - populate token and will not set - NGF_RESP flag. There is no reason for this, because - they are just notifications and do not require acknowledgment.

-
-
-
Requests the creation of a channel representing a logical connection to a - physical address. Input parameters are the target protocol (PSM) and - remote device's 48-bit address (BD_ADDR). Output parameters are the local - CID (LCID) allocated by the local L2CAP entity, and Result of the request. - If Result indicates a pending notification, the Status value may contain - more information of what processing is delaying the establishment of the - connection.
-
-
This message includes the parameters for the address of the remote device - that issued the connection request, the local CID representing the channel - being requested, the Identifier contained in the request, and the PSM - value the request is targeting.
-
-
Issues a response to a connection request event indication. Input - parameters are the remote device's 48-bit address, Identifier sent in the - request, local CID, the Response code, and the Status attached to the - Response code. The output parameter is the Result of the service request. - This primitive must be called no more than once after receiving the - indication.
-
-
Requests the initial configuration (or reconfiguration) of a channel to a - new set of channel parameters. Input parameters are the local CID - endpoint, new incoming receivable MTU (InMTU), new outgoing flow - spec-ification, and flush and link timeouts. Output parameters are the - Result, accepted incoming MTU (InMTU), the remote side's flow requests, - and flush and link timeouts.
-
-
This message includes the parameters indicating the local CID of the - channel the request has been sent to, the outgoing MTU size (maximum - packet that can be sent across the channel) and the flowspec describing - the characteristics of the incoming data. All other channel parameters are - set to their default values if not provided by the remote device.
-
-
Issues a response to a configuration request event indication. Input - parameters include the local CID of the endpoint being configured, - outgoing transmit MTU (which may be equal or less to the OutMTU parameter - in the configuration indication event) and the accepted flowspec for - incoming traffic. The output parameter is the Result value.
-
-
This message includes the parameter indicating the address of the remote - Bluetooth device where the QoS contract has been violated.
-
-
Requests the disconnection of the channel. Input parameter is the CID - representing the local channel endpoint. Output parameter is Result. - Result is zero if an L2CAP Disconnect Response is received, otherwise a - non-zero value is returned. Once disconnection has been requested, no - process will be able to successfully read or write from the CID.
-
-
This message includes the parameter indicating the local CID the request - has been sent to.
-
-
Response to transfer of data request. Actual data must be received from - appropriate upstream hook and must be prepended with header defined as - follows. -
- 
/* L2CA data packet header */
-typedef struct {
-        uint32_t token;  /* token to use in L2CAP_L2CA_WRITE */
-        uint16_t length; /* length of the data */
-        uint16_t lcid;   /* local channel ID */
-} __attribute__ ((packed)) ng_l2cap_l2ca_hdr_t;
-
-

The output parameters are Result and Length of data - written.

-
-
-
Requests the creation of a CID to represent a logical connection to - multiple devices. Input parameter is the PSM value that the outgoing - connectionless traffic is labelled with, and the filter used for incoming - traffic. Output parameter is the CID representing the local endpoint. On - creation, the group is empty but incoming traffic destined for the PSM - value is readable. -
This request has not been implemented.
-
-
-
The use of this message closes down a Group. -
This request has not been implemented.
-
-
-
Requests the addition of a member to a group. The input parameter includes - the CID representing the group and the BD_ADDR of the group member to be - added. The output parameter Result confirms the success or failure of the - request. -
This request has not been implemented.
-
-
-
Requests the removal of a member from a group. The input parameters - include the CID representing the group and BD_ADDR of the group member to - be removed. The output parameter Result confirms the success or failure of - the request. -
This request has not been implemented.
-
-
-
Requests a report of the members of a group. The input parameter CID - represents the group being queried. The output parameter Result confirms - the success or failure of the operation. If the Result is successful, - BD_ADDR_Lst is a list of the Bluetooth addresses of the N members of the - group. -
This request has not been implemented.
-
-
-
Initiates an L2CA Echo Request message and the reception of the - corresponding L2CAP Echo Response message. The input parameters are remote - Bluetooth device BD_ADDR, Echo Data and Length of the echo data. The - output parameters are Result, Echo Data and Length of the echo data.
-
-
Initiates an L2CA Information Request message and the reception of the - corresponding L2CAP Info Response message. The input parameters are remote - Bluetooth device BD_ADDR and Information Type. The output parameters are - Result, Information Data and Size of the information data.
-
-
Request to disable (enable) the reception of connectionless packets. The - input parameter is the PSM value indicating service that should be blocked - (unblocked) and Enable flag.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
Returns current state for the node.
-
-
Returns an integer containing the current debug level for the node.
-
-
This command takes an integer argument and sets current debug level for - the node.
-
-
Returns list of active baseband connections (i.e., ACL links).
-
-
Returns list of active L2CAP channels.
-
-
Returns an integer containing the current value of the auto disconnect - timeout (in sec).
-
-
This command accepts an integer and sets the value of the auto disconnect - timeout (in sec). The special value of 0 (zero) disables auto disconnect - timeout.
-
-
-
-

-

This node shuts down upon receipt of an - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), l2control(8), - l2ping(8), ngctl(8)

-
-
-

-

The l2cap node type was implemented in - FreeBSD 5.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

Most likely. Please report if found.

-
-
- - - - - -
July 4, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_l2tp.4 3.html b/static/freebsd/man4/ng_l2tp.4 3.html deleted file mode 100644 index ec4706da..00000000 --- a/static/freebsd/man4/ng_l2tp.4 3.html +++ /dev/null @@ -1,246 +0,0 @@ - - - - - - -
NG_L2TP(4)Device Drivers ManualNG_L2TP(4)
-
-
-

-

ng_l2tp — L2TP - protocol netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_l2tp.h>

-
-
-

-

The l2tp node type implements the - encapsulation layer of the L2TP protocol as described in RFC 2661. This - includes adding the L2TP packet header for outgoing packets and verifying - and removing it for incoming packets. The node maintains the L2TP sequence - number state and handles control session packet acknowledgment and - retransmission.

-
-
-

-

The l2tp node type supports the following - hooks:

-
-
lower
-
L2TP frames.
-
ctrl
-
Control packets.
-
session_hhhh
-
Session 0xhhhh data packets.
-
-

L2TP control and data packets are transmitted to, and received - from, the L2TP peer via the lower hook. Typically - this hook would be connected to the inet/dgram/udp - hook of an ng_ksocket(4) node for L2TP over UDP.

-

The ctrl hook connects to the local L2TP - management entity. L2TP control messages (without any L2TP headers) are - transmitted and received on this hook. Messages written to this hook are - guaranteed to be delivered to the peer reliably, in order, and without - duplicates.

-

Packets written to the ctrl hook must - contain a two byte session ID prepended to the frame (in network order). - This session ID is copied to the outgoing L2TP header. Similarly, packets - read from the ctrl hook will have the received - session ID prepended.

-

Once an L2TP session has been created, the corresponding session - hook may be used to transmit and receive the session's data frames: for the - session with session ID 0xabcd, the hook is named - session_abcd.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
This command updates the configuration of the node. It takes a - struct ng_l2tp_config as an argument: -
- 
/* Configuration for a node */
-struct ng_l2tp_config {
-    u_char      enabled;        /* enables traffic flow */
-    u_char      match_id;       /* tunnel id must match 'tunnel_id' */
-    uint16_t    tunnel_id;      /* local tunnel id */
-    uint16_t    peer_id;        /* peer's tunnel id */
-    uint16_t    peer_win;       /* peer's max recv window size */
-    uint16_t    rexmit_max;     /* max retransmits before failure */
-    uint16_t    rexmit_max_to;  /* max delay between retransmits */
-};
-
-

The enabled field enables packet - processing. Each time this field is changed back to zero the sequence - number state is reset. In this way, reuse of a node is possible.

-

The tunnel_id field configures the local - tunnel ID for the control connection. The match_id - field determines how incoming L2TP packets with a tunnel ID field - different from tunnel_id are handled. If - match_id is non-zero, they will be dropped; - otherwise, they will be dropped only if the tunnel ID is non-zero. - Typically tunnel_id is set to the local tunnel ID - as soon as it is known and match_id is set to - non-zero after receipt of the SCCRP or SCCCN control message.

-

The peer's tunnel ID should be set in - peer_id as soon as it is learned, typically after - receipt of a SCCRQ or SCCRP control message. This value is copied into - the L2TP header for outgoing packets.

-

The peer_win field should be set from - the “Receive Window Size” AVP received from the peer. The - default value for this field is one; zero is an invalid value. As long - as enabled is non-zero, this value may not be - decreased.

-

The rexmit_max and - rexmit_max_to fields configure packet - retransmission. rexmit_max_to is the maximum - retransmission delay between packets, in seconds. The retransmit delay - will start at a small value and increase exponentially up to this limit. - The rexmit_max sets the maximum number of times a - packet will be retransmitted without being acknowledged before a failure - condition is declared. Once a failure condition is declared, each - additional retransmission will cause the l2tp - node to send a NGM_L2TP_ACK_FAILURE - (ackfailure) control message back to the node - that sent the last NGM_L2TP_SET_CONFIG. - Appropriate action should then be taken to shutdown the control - connection.

-
-
- (getconfig)
-
Returns the current configuration as a struct - ng_l2tp_config.
-
- (setsessconfig)
-
This control message configures a single data session. The corresponding - hook must already be connected before sending this command. The argument - is a struct ng_l2tp_sess_config: -
- 
/* Configuration for a session hook */
-struct ng_l2tp_sess_config {
-    uint16_t    session_id;     /* local session id */
-    uint16_t    peer_id;        /* peer's session id */
-    u_char      control_dseq;   /* whether we control data sequencing */
-    u_char      enable_dseq;    /* whether to enable data sequencing */
-    u_char      include_length; /* whether to include length field */
-};
-
-

The session_id and - peer_id fields configure the local and remote - session IDs, respectively.

-

The control_dseq and - enable_dseq fields determine whether sequence - numbers are used with L2TP data packets. If - enable_dseq is zero, then no sequence numbers are - sent and incoming sequence numbers are ignored. Otherwise, sequence - numbers are included on outgoing packets and checked on incoming - packets.

-

If control_dseq is non-zero, then the - setting of enable_dseq will never change except by - another NGM_L2TP_SET_SESS_CONFIG control - message. If control_dseq is zero, then the peer - controls whether sequence numbers are used: if an incoming L2TP data - packet contains sequence numbers, enable_dseq is - set to one, and conversely if an incoming L2TP data packet does not - contain sequence numbers, enable_dseq is set to - zero. The current value of enable_dseq is always - accessible via the NGM_L2TP_GET_SESS_CONFIG - control message (see below). Typically an LNS would set - control_dseq to one while a LAC would set - control_dseq to zero (if the Sequencing Required - AVP were not sent), thus giving control of data packet sequencing to the - LNS.

-

The include_length field determines - whether the L2TP header length field is included in outgoing L2TP data - packets. For incoming packets, the L2TP length field is always checked - when present.

-
-
- (getsessconfig)
-
This command takes a two byte session ID as an argument and returns the - current configuration for the corresponding data session as a - struct ng_l2tp_sess_config. The corresponding - session hook must be connected.
-
- (getstats)
-
This command returns a struct ng_l2tp_stats - containing statistics of the L2TP tunnel.
-
- (clrstats)
-
This command clears the statistics for the L2TP tunnel.
-
- (getclrstats)
-
Same as NGM_L2TP_GET_STATS, but also atomically - clears the statistics as well.
-
- (getsessstats)
-
This command takes a two byte session ID as an argument and returns a - struct ng_l2tp_session_stats containing statistics - for the corresponding data session. The corresponding session hook must be - connected.
-
- (clrsessstats)
-
This command takes a two byte session ID as an argument and clears the - statistics for that data session. The corresponding session hook must be - connected.
-
- (getclrsessstats)
-
Same as NGM_L2TP_GET_SESSION_STATS, but also - atomically clears the statistics as well.
-
- (setsequence)
-
This command sets the sequence numbers of a not yet enabled node. It takes - a struct ng_l2tp_seq_config as argument, where - xack and nr respectively - ns and rack must be the same. - This option is particularly useful if one receives and processes the first - packet entirely in userspace and wants to hand over further processing to - the node.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_ksocket(4), - ng_ppp(4), ng_pptpgre(4), - ngctl(8)

-

W. Townsley, - A. Valencia, A. Rubens, - G. Pall, G. Zorn, and - B. Palter, Layer Two Tunneling - Protocol L2TP, RFC 2661.

-
-
-

-

The l2tp node type was developed at Packet - Design, LLC, http://www.packetdesign.com/.

-
-
-

-

Archie Cobbs - <archie@packetdesign.com>

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_lmi.4 3.html b/static/freebsd/man4/ng_lmi.4 3.html deleted file mode 100644 index 16ccdd64..00000000 --- a/static/freebsd/man4/ng_lmi.4 3.html +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - -
NG_LMI(4)Device Drivers ManualNG_LMI(4)
-
-
-

-

ng_lmi — frame - relay LMI protocol netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_lmi.h>

-
-
-

-

The lmi node type performs the frame relay - LMI protocol. It supports the ITU Annex A, ANSI Annex D, and Group-of-four - LMI types. It also supports auto-detection of the LMI type.

-

To enable a specific LMI type, connect the corresponding hook - (annexA, annexD, or - group4) to DLCI 0 or 1023 of a - ng_frame_relay(4) node. Typically, Annex A and Annex D - live on DLCI 0 while Group-of-four lives on DLCI 1023.

-

To enable LMI type auto-detection, connect the - auto0 hook to DLCI 0 and the - auto1023 hook to DLCI 1023. The node will attempt to - automatically determine which LMI type is running at the switch, and go into - that mode.

-

Only one fixed LMI type, or auto-detection, can be active at any - given time.

-

The NGM_LMI_GET_STATUS control message can - be used at any time to query the current status of the LMI protocol and each - DLCI channel. This node also supports the - NGM_TEXT_STATUS control message.

-
-
-

-

This node type supports the following hooks:

-
-
annexA
-
ITU Annex A LMI hook.
-
annexD
-
ANSI Annex D LMI hook.
-
group4
-
Group-of-four LMI hook.
-
auto0
-
Auto-detection hook for DLCI 0.
-
auto1023
-
Auto-detection hook for DLCI 1023.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
This command returns status information in a struct - nglmistat: -
- 
#define NGM_LMI_STAT_ARYSIZE   (1024/8)
-
-struct nglmistat {
-  u_char  proto[12];	/* Active proto (same as hook name) */
-  u_char  hook[12];	/* Active hook */
-  u_char  fixed;	/* If set to fixed LMI mode */
-  u_char  autod;	/* If currently auto-detecting */
-  u_char  seen[NGM_LMI_STAT_ARYSIZE];	/* DLCIs ever seen */
-  u_char  up[NGM_LMI_STAT_ARYSIZE];	/* DLCIs currently up */
-};
-
-
-
-
This generic message returns is a human-readable version of the node - status.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), - ng_frame_relay(4), ngctl(8)

-

ANSI T1.617-1991 Annex - D.

-

ITU-T Q.933 Digital Subscriber - Signaling System No. 1 - Signaling Specification for Frame Mode Basic Call - Control, Annex A.

-
-
-

-

The ng_lmi node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_macfilter.4 3.html b/static/freebsd/man4/ng_macfilter.4 3.html deleted file mode 100644 index 2bb8f73a..00000000 --- a/static/freebsd/man4/ng_macfilter.4 3.html +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - -
NG_MACFILTER(4)Device Drivers ManualNG_MACFILTER(4)
-
-
-

-

ng_macfilter — - packet filtering netgraph node using ethernet MAC - addresses

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_macfilter.h>

-
-
-

-

The macfilter allows routing ethernet - packets over different hooks based on the sender MAC address.

-

This processing is done when traffic flows from the - “ether” hook through macfilter to one - of the outgoing hooks. Outbound hooks can be added to and remove from - macfilter and arbitrarily named. By default one hook - called “default” is present and used for all packets which - have no MAC address in the MAC table. By adding MAC addresses to the MAC - table traffic coming from this host can be directed out other hooks. - macfilter keeps track of packets and bytes from and - to this MAC address in the MAC table.

-

Packets are not altered in any way. If hooks are not connected, - packets are dropped.

-
-
-

-

This node type by default has an ether - hook, to be connected to the lower hook of the NIC, - and a default hook where packets are sent if the MAC - address is not found in the table. macfilter - supports up to NG_MACFILTER_UPPER_NUM hooks to be - connected to the NIC's upper hook. Other nodes can be inserted to provide - additional processing. All outbound can be combined back into one by using - ng_one2many.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (reset)
-
Resets the MAC table in the node.
-
- (direct)
-
Takes the following argument struct: -
- 
struct ngm_macfilter_direct {
-    u_char	ether[ETHER_ADDR_LEN];  	/* MAC address */
-    u_char	hookname[NG_HOOKSIZ];   	/* Upper hook name*/
-};
-
- The given ethernet MAC address will be forwarded out the named hook.
-
- (directi)
-
Takes the following argument struct: -
- 
struct ngm_macfilter_direct_hookid {
-    u_char	ether[ETHER_ADDR_LEN];  	/* MAC address */
-    u_int16_t	hookid;		        	/* Upper hook hookid */
-};
-
- The given ethernet MAC address will be forwarded out the hook at id - hookid.
-
- (getmacs)
-
Returns the list of MAC addresses in the node in the following structure: -
- 
struct ngm_macfilter_mac {
-    u_char	ether[ETHER_ADDR_LEN];  	/* MAC address */
-    u_int16_t	hookid;		        	/* Upper hook hookid */
-    u_int64_t	packets_in;			/* packets in from downstream */
-    u_int64_t	bytes_in;			/* bytes in from upstream */
-    u_int64_t	packets_out;			/* packets out towards downstream */
-    u_int64_t	bytes_out;			/* bytes out towards downstream */
-};
-struct ngm_macfilter_macs {
-    u_int32_t   n;                              /* Number of entries in macs */
-    struct ngm_macfilter_mac macs[];            /* Macs table */
-};
-
-
-
- (getclrmacs)
-
Same as above, but will also atomically clear the - packets_in, bytes_in, - packets_out, and - bytes_out fields in the table.
-
- (clrmacs)
-
Will clear the per MAC address packet and byte counters.
-
- (gethooks)
-
Will return a list of hooks and their hookids in an array of the following - struct's: -
- 
struct ngm_macfilter_hook {
-    u_char	hookname[NG_HOOKSIZ];   	/* Upper hook name*/
-    u_int16_t	hookid;		        	/* Upper hook hookid */
-    u_int32_t   maccnt;                         /* Number of mac addresses associated with hook */
-};
-
-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message or when all have been - disconnected.

-
-
-

-

The following netgraph configuration will apply - ipfw(8) tag 42 to each packet that is routed over the - “accepted” hook. The graph looks like the following:

-
-
    /------<one>-[combiner]-<many1>--------\
-<upper>               |                    <out>
-  /                <many0>                    \
-[em0]                 |                    [tagger]
-  \               <default>                   /
-<lower>               |                     <in>
-    \----<ether>-[macfilter]-<accepted>-----/
-
-

Commands:

-
-
  ngctl mkpeer em0: macfilter lower ether
-  ngctl name em0:lower macfilter
-
-  # Funnel both streams back into ether:upper
-  ngctl mkpeer em0: one2many upper one
-  ngctl name em0:upper recombiner
-  # Connect macfilter:default to recombiner:many0
-  ngctl connect macfilter: recombiner: default many0
-  # Connect macfilter:accepted to tagger:in
-  ngctl mkpeer macfilter: tag accepted in
-  ngctl name macfilter:accepted tagger
-  # Connect tagger:out to recombiner:many1
-  ngctl connect tagger: recombiner: out many1
-
-  # Mark tag all traffic through tagger in -> out with an ipfw tag 42
-  ngctl msg tagger: sethookin '{ thisHook="in" ifNotMatch="out" }'
-  ngctl msg tagger: sethookout '{ thisHook="out" tag_cookie=1148380143 tag_id=42 }'
-
-  # Pass traffic from ether:upper / combiner:one via combiner:many0 on to
-  # macfilter:default and on to ether:lower.
-  ngctl msg recombiner: setconfig '{ xmitAlg=3 failAlg=1 enabledLinks=[ 1 1 ] }'
-
-

: - The tag_cookie 1148380143 was retrieved from - MTAG_IPFW in - /usr/include/netinet/ip_var.h.

-

The following command can be used to add a MAC address to be - output via macfilter:accepted:

-
-
  ngctl msg macfilter: direct '{ hookname="known" ether=08:00:27:92:eb:aa }'
-
-

The following command can be used to retrieve the packet and byte - counters :

-
-
  ngctl msg macfilter: getmacs
-
-

It will return the contents of the MAC table:

-
-
  Rec'd response "getmacs" (4) from "[54]:":
-  Args:	{ n=1 macs=[ { ether=08:00:27:92:eb:aa hookid=1 packets_in=3571 bytes_in=592631 packets_out=3437 bytes_out=777142 } ] }
-
-
-
-

-

divert(4), ipfw(4), - netgraph(4), ng_ether(4), - ng_one2many(4), ng_tag(4), - ngctl(8)

-
-
-

-

The original version of this code was written by Pekka Nikander, - and subsequently modified heavily by Nick Hibma - <n_hibma@FreeBSD.org>.

-
-
-

-

None known.

-
-
- - - - - -
December 10, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_mppc.4 3.html b/static/freebsd/man4/ng_mppc.4 3.html deleted file mode 100644 index eb35d3cd..00000000 --- a/static/freebsd/man4/ng_mppc.4 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
NG_MPPC(4)Device Drivers ManualNG_MPPC(4)
-
-
-

-

ng_mppc — - Microsoft MPPC/MPPE compression and encryption netgraph - node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_mppc.h>

-
-
-

-

The mppc node type implements the - Microsoft Point-to-Point Compression (MPPC) and Microsoft Point-to-Point - Encryption (MPPE) sub-protocols of the PPP protocol. These protocols are - often used in conjunction with the Point-to-Point Tunneling Protocol - (PPTP).

-

The node has two hooks, comp for - compression and decomp for decompression. Typically - one or both of these hooks would be connected to the - ng_ppp(4) node type hook of the same name. Each direction - of traffic flow is independent of the other.

-
-
-

-

This node type supports the following hooks:

-
-
comp
-
Connection to ng_ppp(4) comp - hook. Incoming frames are compressed and/or encrypted, and sent back out - the same hook.
-
decomp
-
Connection to ng_ppp(4) decomp - hook. Incoming frames are decompressed and/or decrypted, and sent back out - the same hook.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
This command resets and configures the node for a session in the outgoing - traffic direction (i.e., for compression and/or encryption). This command - takes a struct ng_mppc_config as an argument: -
- 
/* Length of MPPE key */
-#define MPPE_KEY_LEN      16
-
-/* MPPC/MPPE PPP negotiation bits */
-#define MPPC_BIT          0x00000001      /* mppc compression bits */
-#define MPPE_40           0x00000020      /* use 40 bit key */
-#define MPPE_56           0x00000080      /* use 56 bit key */
-#define MPPE_128          0x00000040      /* use 128 bit key */
-#define MPPE_BITS         0x000000e0      /* mppe encryption bits */
-#define MPPE_STATELESS    0x01000000      /* use stateless mode */
-#define MPPC_VALID_BITS   0x010000e1      /* possibly valid bits */
-
-/* Configuration for a session */
-struct ng_mppc_config {
-    u_char    enable;                 /* enable */
-    uint32_t  bits;                   /* config bits */
-    u_char    startkey[MPPE_KEY_LEN]; /* start key */
-};
-
-
-
- The enabled field enables traffic flow through the - node. The bits field contains the bits as - negotiated by the Compression Control Protocol (CCP) in PPP. The - startkey is only necessary if MPPE was negotiated, - and must be equal to the session start key as defined for MPPE. This key - is based on the MS-CHAP credentials used at link authentication time.
-
-
This command resets and configures the node for a session in the incoming - traffic direction (i.e., for decompression and/or decryption). This - command takes a struct ng_mppc_config as an - argument.
-
-
This message contains no arguments, and is bi-directional. If an error is - detected during decompression, this message is sent by the node to the - originator of the NGM_MPPC_CONFIG_DECOMP message - that initiated the session. The receiver should respond by sending a PPP - CCP Reset-Request to the peer. -

This message may also be received by this node type when a CCP - Reset-Request is received by the local PPP entity. The node will respond - by flushing its outgoing compression and encryption state so the remote - side can resynchronize.

-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when both hooks - have been disconnected.

-
-
-

-

The kernel options - NETGRAPH_MPPC_COMPRESSION and - NETGRAPH_MPPC_ENCRYPTION are supplied to selectively - compile in either or both capabilities. At least one of these must be - defined, or else this node type is useless.

-
-
-

-

netgraph(4), ng_ppp(4), - ngctl(8)

-

G. Pall, - Microsoft Point-To-Point Compression (MPPC) - Protocol, RFC 2118.

-

G. S. Pall and - G. Zorn, Microsoft Point-To-Point - Encryption (MPPE) Protocol, - draft-ietf-pppext-mppe-04.txt.

-

K. Hamzeh, - G. Pall, W. Verthein, - J. Taarud, W. Little, and - G. Zorn, Point-to-Point Tunneling - Protocol (PPTP), RFC 2637.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

In PPP, encryption should be handled by the Encryption Control - Protocol (ECP) rather than CCP. However, Microsoft combined both compression - and encryption into their ``compression'' algorithm, which is confusing.

-
-
- - - - - -
June 7, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_nat.4 3.html b/static/freebsd/man4/ng_nat.4 3.html deleted file mode 100644 index 37b61c0f..00000000 --- a/static/freebsd/man4/ng_nat.4 3.html +++ /dev/null @@ -1,348 +0,0 @@ - - - - - - -
NG_NAT(4)Device Drivers ManualNG_NAT(4)
-
-
-

-

ng_nat — NAT - netgraph node type

-
-
-

-

#include - <netgraph/ng_nat.h>

-
-
-

-

An ng_nat node performs network address - translation (NAT) of IPv4 packets passing through it. A - nat node uses libalias(3) engine - for packet aliasing.

-
-
-

-

This node type has two hooks:

-
-
out
-
Packets received on this hook are considered outgoing and will be - masqueraded to a configured address.
-
in
-
Packets coming on this hook are considered incoming and will be - dealiased.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setaliasaddr)
-
Configure aliasing address for a node. After both hooks have been - connected and aliasing address was configured, a node is ready for - aliasing operation.
-
- (setmode)
-
Set node's operation mode using supplied struct - ng_nat_mode. -
- 
struct ng_nat_mode {
-	uint32_t	flags;
-	uint32_t	mask;
-};
-/* Supported flags: */
-#define NG_NAT_LOG			0x01
-#define NG_NAT_DENY_INCOMING		0x02
-#define NG_NAT_SAME_PORTS		0x04
-#define NG_NAT_UNREGISTERED_ONLY	0x10
-#define NG_NAT_RESET_ON_ADDR_CHANGE	0x20
-#define NG_NAT_PROXY_ONLY		0x40
-#define NG_NAT_REVERSE			0x80
-#define NG_NAT_UNREGISTERED_CGN		0x100
-#define NG_NAT_UDP_EIM			0x200
-
-

The corresponding libalias flags can be found by replacing the - NG_NAT prefix with - PKT_ALIAS.

-
-
- (settarget)
-
Configure target address for a node. When an incoming packet not - associated with any pre-existing aliasing link arrives at the host - machine, it will be sent to the specified address.
-
- (redirectport)
-
Redirect incoming connections arriving to given port(s) to another host - and port(s). The following struct - ng_nat_redirect_port must be supplied as argument. -
- 
#define NG_NAT_DESC_LENGTH	64
-struct ng_nat_redirect_port {
-	struct in_addr	local_addr;
-	struct in_addr	alias_addr;
-	struct in_addr	remote_addr;
-	uint16_t	local_port;
-	uint16_t	alias_port;
-	uint16_t	remote_port;
-	uint8_t		proto;
-	char		description[NG_NAT_DESC_LENGTH];
-};
-
-

Redirection is assigned an unique ID which is returned as - response to this message, and information about redirection added to - list of static redirects which later can be retrieved by - NGM_NAT_LIST_REDIRECTS message.

-
-
- (redirectaddr)
-
Redirect traffic for public IP address to a machine on the local network. - This function is known as static NAT. The following - struct ng_nat_redirect_addr must be supplied as - argument. -
- 
struct ng_nat_redirect_addr {
-	struct in_addr	local_addr;
-	struct in_addr	alias_addr;
-	char		description[NG_NAT_DESC_LENGTH];
-};
-
-

Unique ID for this redirection is returned as response to this - message.

-
-
- (redirectproto)
-
Redirect incoming IP packets of protocol proto (see - protocols(5)) to a machine on the local network. The - following struct ng_nat_redirect_proto must be - supplied as argument. -
- 
struct ng_nat_redirect_proto {
-	struct in_addr	local_addr;
-	struct in_addr	alias_addr;
-	struct in_addr	remote_addr;
-	uint8_t		proto;
-	char		description[NG_NAT_DESC_LENGTH];
-};
-
-

Unique ID for this redirection is returned as response to this - message.

-
-
- (redirectdynamic)
-
Mark redirection with specified ID as dynamic, i.e., it will serve for - exactly one next connection and then will be automatically deleted from - internal links table. Only fully specified links can be made dynamic. The - redirection with this ID is also immediately deleted from user-visible - list of static redirects (available through - NGM_NAT_LIST_REDIRECTS message).
-
- (redirectdelete)
-
Delete redirection with specified ID (currently active connections are not - affected).
-
- (addserver)
-
Add another server to a pool. This is used to transparently offload - network load on a single server and distribute the load across a pool of - servers, also known as - - (RFC 2391). The following struct ng_nat_add_server - must be supplied as argument. -
- 
struct ng_nat_add_server {
-	uint32_t	id;
-	struct in_addr	addr;
-	uint16_t	port;
-};
-
-

First, the redirection is set up by - NGM_NAT_REDIRECT_PORT or - NGM_NAT_REDIRECT_ADDR. Then, ID of that - redirection is used in multiple - NGM_NAT_ADD_SERVER messages to add necessary - number of servers. For redirections created by - NGM_NAT_REDIRECT_ADDR, the - port is ignored and could have any value. Original - redirection's parameters local_addr and - local_port are also ignored after - NGM_NAT_ADD_SERVER was used (they are - effectively replaced by server pool).

-
-
- (listredirects)
-
Return list of configured static redirects as struct - ng_nat_list_redirects. -
- 
struct ng_nat_listrdrs_entry {
-	uint32_t	id;		/* Anything except zero */
-	struct in_addr	local_addr;
-	struct in_addr	alias_addr;
-	struct in_addr	remote_addr;
-	uint16_t	local_port;
-	uint16_t	alias_port;
-	uint16_t	remote_port;
-	uint16_t	proto;		/* Valid proto or NG_NAT_REDIRPROTO_ADDR */
-	uint16_t	lsnat;		/* LSNAT servers count */
-	char		description[NG_NAT_DESC_LENGTH];
-};
-struct ng_nat_list_redirects {
-	uint32_t		total_count;
-	struct ng_nat_listrdrs_entry redirects[];
-};
-#define NG_NAT_REDIRPROTO_ADDR	(IPPROTO_MAX + 3)
-
-

Entries of the redirects array returned - in the unified format for all redirect types. Ports are meaningful only - if protocol is either TCP or UDP and static NAT - redirection (created by NGM_NAT_REDIRECT_ADDR) - is indicated by proto set to - NG_NAT_REDIRPROTO_ADDR. If - lsnat servers counter is greater than zero, then - local_addr and local_port - are also meaningless.

-
-
- (proxyrule)
-
Specify a transparent proxying rule (string must be supplied as argument). - See libalias(3) for details.
-
- (libaliasinfo)
-
Return internal statistics of libalias(3) instance as - struct ng_nat_libalias_info. -
- 
struct ng_nat_libalias_info {
-	uint32_t	icmpLinkCount;
-	uint32_t	udpLinkCount;
-	uint32_t	tcpLinkCount;
-	uint32_t	sctpLinkCount;
-	uint32_t	pptpLinkCount;
-	uint32_t	protoLinkCount;
-	uint32_t	fragmentIdLinkCount;
-	uint32_t	fragmentPtrLinkCount;
-	uint32_t	sockCount;
-};
-
- In case of ng_nat failed to retrieve a certain - counter from its libalias(3) instance, the corresponding - field is returned as UINT32_MAX.
-
- (setdlt)
-
Sets the data link type on the in and - out hooks. Currently, supported types are - DLT_RAW (raw IP datagrams , no offset applied, the - default) and DLT_EN10MB (Ethernet). DLT_ - definitions can be found in - <net/bpf.h>. If you want - to work on the ipfw(8) level you must use no additional - offset by specifying DLT_RAW. If, however, you - attach ng_nat to a network interface directly and - EN10MB is specified, then the extra offset will be - applied to take into account link-level header. In this mode the - ng_nat would also inspect appropriate type field - in the Ethernet header and pass-through any datagrams that are not IP - packets.
-
- (getdlt)
-
This control message returns the current data link type of the - in and out hooks.
-
-

In all redirection messages local_addr and - local_port mean address and port of target machine in - the internal network, respectively. If alias_addr is - zero, then default aliasing address (set by - NGM_NAT_SET_IPADDR) is used. Connections can also be - restricted to be accepted only from specific external machines by using - non-zero remote_addr and/or - remote_port. Each redirection assigned an ID which can - be later used for redirection manipulation on individual basis (e.g., - removal). This ID guaranteed to be unique until the node shuts down (it will - not be reused after deletion), and is returned to user after making each new - redirection or can be found in the stored list of all redirections. The - description passed to and from node unchanged, - together with ID providing a way for several entities to concurrently - manipulate redirections in automated way.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when both hooks are - disconnected.

-
-
-

-

In the following example, the packets are injected into a - nat node using the ng_ipfw(4) - node.

-
-
# Create NAT node
-ngctl mkpeer ipfw: nat 60 out
-ngctl name ipfw:60 nat
-ngctl connect ipfw: nat: 61 in
-ngctl msg nat: setaliasaddr x.y.35.8
-
-# Divert traffic into NAT node
-ipfw add 300 netgraph 61 all from any to any in via fxp0
-ipfw add 400 netgraph 60 all from any to any out via fxp0
-
-# Let packets continue with after being (de)aliased
-sysctl net.inet.ip.fw.one_pass=0
-
-

The ng_nat node can be inserted right - after the ng_iface(4) node in the graph. In the following - example, we perform masquerading on a serial line with HDLC - encapsulation.

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	mkpeer cp0: cisco rawdata downstream
-	name cp0:rawdata hdlc
-	mkpeer hdlc: nat inet in
-	name hdlc:inet nat
-	mkpeer nat: iface out inet
-	msg nat: setaliasaddr x.y.8.35
-SEQ
-ifconfig ng0 x.y.8.35 x.y.8.1
-
-

The ng_nat node can also be attached - directly to the physical interface via ng_ether(4) node in - the graph. In the following example, we perform masquerading on a Ethernet - interface connected to a public network.

-
-
ifconfig igb0 inet x.y.8.35 netmask 0xfffff000
-route add default x.y.0.1
-/usr/sbin/ngctl -f- <<-SEQ
-        mkpeer igb0: nat lower in
-        name igb0:lower igb0_NAT
-        connect igb0: igb0_NAT: upper out
-        msg igb0_NAT: setdlt 1
-        msg igb0_NAT: setaliasaddr x.y.8.35
-SEQ
-
-
-
-

-

libalias(3), ng_ipfw(4), - natd(8), ng_ether(8), - ngctl(8)

-
-
-

-

The ng_nat node type was implemented in - FreeBSD 6.0.

-
-
-

-

Gleb Smirnoff - <glebius@FreeBSD.org>

-
-
- - - - - -
December 6, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_netflow.4 3.html b/static/freebsd/man4/ng_netflow.4 3.html deleted file mode 100644 index e2f9e217..00000000 --- a/static/freebsd/man4/ng_netflow.4 3.html +++ /dev/null @@ -1,304 +0,0 @@ - - - - - - -
NG_NETFLOW(4)Device Drivers ManualNG_NETFLOW(4)
-
-
-

-

ng_netflow — - Cisco's NetFlow implementation

-
-
-

-

#include - <sys/types.h> -
- #include <netinet/in.h> -
- #include - <netgraph/netflow/ng_netflow.h>

-
-
-

-

The ng_netflow node implements Cisco's - NetFlow export protocol on a router running FreeBSD. - The ng_netflow node listens for incoming traffic and - identifies unique flows in it. Flows are distinguished by endpoint IP - addresses, TCP/UDP port numbers, ToS and input interface. Expired flows are - exported out of the node in NetFlow version 5/9 UDP datagrams. Expiration - reason can be one of the following:

-
    -
  • RST or FIN TCP segment.
    • -
  • Active timeout. Flows cannot live more than the specified period of time. - The default is 1800 seconds (30 minutes).
    • -
  • Inactive timeout. A flow was inactive for the specified period of time. - The default is 15 seconds.
    • -
-

Node supports IPv6 accounting (NetFlow v9 only) and is aware of - multiple fibs. Different fibs are mapped to different domain_id in NetFlow - V9 and different engine_id in NetFlow V5.

-
-
-

-

This node type supports up to - NG_NETFLOW_MAXIFACES (default 65536) hooks named - iface0, iface1, etc., and the - same number of hooks named out0, - out1, etc., plus two export hooks: - export (for NetFlow version 5) and - export9 (for NetFlow version 9). Export can be done - simultaneously for all supported export hooks. By default (ingress NetFlow - enabled) node does NetFlow accounting of data received on - iface* hooks. If corresponding - out hook is connected, unmodified data is bypassed to - it, otherwise data is freed. If data is received on - out hook, it is bypassed to corresponding - iface hook without any processing (egress NetFlow - disabled by default). When full export datagram for an export protocol is - built it is sent to the export or - export9 hook. In normal operation, one (or more) - export hook is connected to the inet/dgram/udp hook of - the ng_ksocket(4) node.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (info)
-
Returns some node statistics and the current timeout values in a - struct ng_netflow_info.
-
- (ifinfo)
-
Returns information about the - ifaceN hook. The hook number - is passed as an argument.
-
- (setdlt)
-
Sets data link type on the - ifaceN hook. Currently, - supported types are DLT_RAW (raw IP datagrams) and - DLT_EN10MB (Ethernet). DLT_ definitions can be - found in <net/bpf.h> - header. Currently used values are 1 for DLT_EN10MB - and 12 for DLT_RAW. This message type uses - struct ng_netflow_setdlt as an argument: -
- 
struct ng_netflow_setdlt {
-	uint16_t iface;		/* which iface dlt change */
-	uint8_t  dlt;		/* DLT_XXX from bpf.h */
-};
-
-

The requested - ifaceN hook must already be - connected, otherwise message send operation will return an error.

-
-
- (setifindex)
-
In some cases, ng_netflow may be unable to - determine the input interface index of a packet. This can happen if - traffic enters the ng_netflow node before it comes - to the system interface's input queue. An example of such a setup is - capturing a traffic - - synchronous data line and ng_iface(4). In this case, the - input index should be associated with a given hook. The interface's index - can be determined via if_nametoindex(3) from userland. - This message requires struct ng_netflow_setifindex - as an argument: -
- 
struct ng_netflow_setifindex {
-	uint16_t iface;		/* which iface index change */
-	uint16_t index;		/* new index */
-};
-
-

The requested - ifaceN hook must already be - connected, otherwise the message send operation will return an - error.

-
-
- (settimeouts)
-
Sets values in seconds for NetFlow active/inactive timeouts. This message - requires struct ng_netflow_settimeouts as an - argument: -
- 
struct ng_netflow_settimeouts {
-	uint32_t inactive_timeout;	/* flow inactive timeout */
-	uint32_t active_timeout;	/* flow active timeout */
-};
-
-
-
- (setconfig)
-
Sets configuration for the specified interface. This message requires - struct ng_netflow_setconfig as an argument: -
- 
struct ng_netflow_setconfig {
-	uint16_t iface;		/* which iface config change */
-	uint32_t conf;		/* new config */
-#define NG_NETFLOW_CONF_INGRESS		1
-#define NG_NETFLOW_CONF_EGRESS		2
-#define NG_NETFLOW_CONF_ONCE		4
-#define NG_NETFLOW_CONF_THISONCE	8
-#define NG_NETFLOW_CONF_NOSRCLOOKUP	16
-#define NG_NETFLOW_CONF_NODSTLOOKUP	32
-};
-
-

Configuration is a bitmask of several options. Option - NG_NETFLOW_CONF_INGRESS enabled by default enables ingress NetFlow - generation (for data coming from ifaceX hook). Option - NG_NETFLOW_CONF_EGRESS enables egress NetFlow (for - data coming from outX hook). Option - NG_NETFLOW_CONF_ONCE defines that packet should be - accounted only once if it several times passes via netflow node. Option - NG_NETFLOW_CONF_THISONCE defines that packet - should be accounted only once if it several times passes via exactly - this netflow node. These two options are important to avoid duplicate - accounting when both ingress and egress NetFlow are enabled. Option - NG_NETFLOW_CONF_NOSRCLOOKUP skips radix lookup on - flow source address used to fill in network mask. Option - NG_NETFLOW_CONF_NODSTLOOKUP skips radix lookup on - destination (which fills egress interface id, destination mask and - gateway). If one doesn't need data provided by lookups, he/she can - disable them, to reduce load on routers.

-
-
- (settemplate)
-
Sets various timeouts to announce data flow templates (NetFlow - v9-specific). This message requires struct - ng_netflow_settemplate as an argument: -
- 
struct ng_netflow_settemplate {
-	uint16_t time;		/* max time between announce */
-	uint16_t packets;	/* max packets between announce */
-};
-
-

Value of time field represents time in seconds to re-announce - data templates. Value of packets field represents maximum packets count - between re-announcing data templates.

-
-
- (setmtu)
-
Sets export interface MTU to build packets of specified size (NetFlow - v9-specific). This message requires struct - ng_netflow_setmtu as an argument: -
- 
struct ng_netflow_setemtu {
-	uint16_t mtu;		/* MTU for packet */
-};
-
-

Default is 1500 bytes.

-
-
-
This control message asks a node to dump the entire contents of the flow - cache. It is called from flowctl(8), not directly from - ngctl(8).
-
- (v9info)
-
Returns some NetFlow v9 related values in a -
- 
struct ng_netflow_v9info {
-    uint16_t        templ_packets;  /* v9 template packets */
-    uint16_t        templ_time;     /* v9 template time */
-    uint16_t        mtu;            /* v9 MTU */
-};
-
-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

The simplest possible configuration is one Ethernet interface, - where flow collecting is enabled.

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	mkpeer fxp0: netflow lower iface0
-	name fxp0:lower netflow
-	connect fxp0: netflow: upper out0
-	mkpeer netflow: ksocket export inet/dgram/udp
-	msg netflow:export connect inet/10.0.0.1:4444
-SEQ
-
-

This is a more complicated example of a router with 2 - NetFlow-enabled interfaces fxp0 and - ng0. Note that the ng0: node - in this example is connected to ng_tee(4). The latter - sends us a copy of IP packets, which we analyze and free. On - fxp0: we do not use tee, but send packets back to - either node.

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	# connect ng0's tee to iface0 hook
-	mkpeer ng0:inet netflow right2left iface0
-	name ng0:inet.right2left netflow
-	# set DLT to raw mode
-	msg netflow: setdlt { iface=0 dlt=12 }
-	# set interface index (5 in this example)
-	msg netflow: setifindex { iface=0 index=5 }
-
-	# Connect fxp0: to iface1 and out1 hook
-	connect fxp0: netflow: lower iface1
-	connect fxp0: netflow: upper out1
-
-	# Create ksocket node on export hook, and configure it
-	# to send exports to proper destination
-	mkpeer netflow: ksocket export inet/dgram/udp
-	msg netflow:export connect inet/10.0.0.1:4444
-SEQ
-
-
-
-

-

setfib(2), netgraph(4), - ng_ether(4), ng_iface(4), - ng_ksocket(4), ng_tee(4), - flowctl(8), ngctl(8)

-

B. Claise, Ed, - Cisco Systems NetFlow Services Export Version 9, - RFC 3954.

-

http://www.cisco.com/en/US/docs/ios/solutions_docs/netflow/nfwhite.html

-
-
-

-

The ng_netflow node type was written by - Gleb Smirnoff - <glebius@FreeBSD.org>, - Alexander Motin - <mav@FreeBSD.org>, - Alexander Chernikov - <melifaro@ipfw.ru>. - The initial code was based on ng_ipacct written by - Roman V. Palagin - <romanp@unshadow.net>.

-
-
-

-

Cache snapshot obtained via - NGM_NETFLOW_SHOW command may lack some percentage of - entries under severe load.

-

The ng_netflow node type does not fill in - AS numbers. This is due to the lack of necessary information in the kernel - routing table. However, this information can be injected into the kernel - from a routing daemon such as GNU Zebra. This functionality may become - available in future releases.

-
-
- - - - - -
December 10, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_one2many.4 3.html b/static/freebsd/man4/ng_one2many.4 3.html deleted file mode 100644 index f5591a2c..00000000 --- a/static/freebsd/man4/ng_one2many.4 3.html +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -
NG_ONE2MANY(4)Device Drivers ManualNG_ONE2MANY(4)
-
-
-

-

ng_one2many — - packet multiplexing netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_one2many.h>

-
-
-

-

The one2many provides a simple mechanism - for routing packets over several links in a one-to-many (and in the reverse - direction, many-to-one) fashion. There is a single hook named - one, and multiple hooks named - many0, many1, etc. Packets - received on any of the many hooks are forwarded out - the one hook. Packets received on the - one hook are forwarded out one or more of the - many hooks; which hook(s) is determined by the - node's configured transmit algorithm. Packets are not altered in any - way.

-

Each of the connected many links may be considered to be up or - down. Packets are never delivered out a many hook that is down. How a link - is determined to be up or down depends on the node's configured link failure - detection algorithm.

-

Before an interface or link can be plumbed into a group, its - status must be marked as being “up”. This is normally setup - during the initial boot stages by rc.conf(5). It is also - possible to change an interface's status to “up” by using the - ifconfig(8) utility.

-
-
-

-
-
-
Packets are delivered out the many hooks in sequential order. Each packet - goes out on a different many hook.
-
-
Packets are delivered out all the many hooks. Each - packet goes out each many hook.
-
-
Packets are delivered out the first active many - hook.
-
-

In the future other algorithms may be added as well.

-
-
-

-

The node distinguishes between active and failed links. Data is - sent only to active links. The following link failure detection algorithms - are available:

-
-
-
The node is explicitly told which of the links are up via the - NGM_ONE2MANY_SET_CONFIG control message (see - below). Newly connected links are down until configured otherwise.
-
-
The node listens to flow control message from many - hooks, and considers link failed if - NGM_LINK_IS_DOWN is received. If the - NGM_LINK_IS_UP message is received, node considers - link active.
-
-

In the future other algorithms may be added as well.

-

When all links are considered failed, node sends the - NGM_LINK_IS_DOWN message towards the - one hook. When at least one link comes up, node sends - the NGM_LINK_IS_UP message towards the - one hook.

-
-
-

-

This node type supports up to - NG_ONE2MANY_MAX_LINKS hooks named - many0, many1, etc., plus a - single hook named one.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
Sets the node configuration using a struct - ng_one2many_link_config as the control message argument: -
- 
/* Node configuration structure */
-struct ng_one2many_config {
-  uint32_t    xmitAlg;        /* how to distribute packets */
-  uint32_t    failAlg;        /* how to detect link failure */
-  u_char      enabledLinks[NG_ONE2MANY_MAX_LINKS];
-};
-
-

Currently, the valid settings for the - xmitAlg field are - NG_ONE2MANY_XMIT_ROUNDROBIN (default) or - NG_ONE2MANY_XMIT_ALL. The valid settings for - failAlg are - NG_ONE2MANY_FAIL_MANUAL (default) or - NG_ONE2MANY_FAIL_NOTIFY.

-
-
- (getconfig)
-
Returns the current node configuration in a struct - ng_one2many_link_config.
-
- (getstats)
-
This command takes a 32 bit link number as an argument and returns a - struct ng_one2many_link_stats containing - statistics for the corresponding many link, which - may or may not be currently connected: -
- 
/* Statistics structure (one for each link) */
-struct ng_one2many_link_stats {
-  uint64_t   recvOctets;     /* total octets rec'd on link */
-  uint64_t   recvPackets;    /* total pkts rec'd on link */
-  uint64_t   xmitOctets;     /* total octets xmit'd on link */
-  uint64_t   xmitPackets;    /* total pkts xmit'd on link */
-  uint64_t   memoryFailures; /* times couldn't get mem or mbuf */
-};
-
-

To access statistics for the one link, - use the link number -1.

-
-
- (clrstats)
-
This command takes a 32 bit link number as an argument and clears the - statistics for that link.
-
- (getclrstats)
-
Same as NGM_ONE2MANY_GET_STATS, but also - atomically clears the statistics for the link as well.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

The following commands will set up Ethernet interfaces - fxp0 to deliver packets alternating over the - physical interfaces corresponding to networking interfaces - fxp0 through fxp3:

-
-
  # Plumb nodes together
-
-  ngctl mkpeer fxp0: one2many upper one
-  ngctl connect fxp0: fxp0:upper lower many0
-  ngctl connect fxp1: fxp0:upper lower many1
-  ngctl connect fxp2: fxp0:upper lower many2
-  ngctl connect fxp3: fxp0:upper lower many3
-
-  # Allow fxp1 through fxp3 to xmit/recv fxp0 frames
-
-  ngctl msg fxp1: setpromisc 1
-  ngctl msg fxp2: setpromisc 1
-  ngctl msg fxp3: setpromisc 1
-  ngctl msg fxp1: setautosrc 0
-  ngctl msg fxp2: setautosrc 0
-  ngctl msg fxp3: setautosrc 0
-
-  # Configure all four links as up
-
-  ngctl msg fxp0:upper \
-    setconfig "{ xmitAlg=1 failAlg=1 enabledLinks=[ 1 1 1 1 ] }"
-
-  # Bring up interface
-
-  ifconfig fxp0 192.168.1.1 netmask 0xfffffffc
-
-

With a similar setup on a peer machine (using the address - 192.168.1.2), a point-to-point Ethernet connection with four times normal - bandwidth is achieved.

-
-
-

-

lagg(4), netgraph(4), - ng_bridge(4), ng_ether(4), - ng_hub(4), ifconfig(8), - ngctl(8)

-
-
-

-

The ng_one2many node type was implemented - in FreeBSD 4.2.

-
-
-

-

The one2many netgraph node (with - round-robin algorithm) was written by Archie Cobbs - <archie@FreeBSD.org>. - The all algorithm was added by Rogier R. Mulhuijzen - <drwilco@drwilco.net>.

-
-
-

-

More transmit and link failure algorithms should be supported. A - good candidate is Cisco's Etherchannel.

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_patch.4 3.html b/static/freebsd/man4/ng_patch.4 3.html deleted file mode 100644 index 1490fef3..00000000 --- a/static/freebsd/man4/ng_patch.4 3.html +++ /dev/null @@ -1,237 +0,0 @@ - - - - - - -
NG_PATCH(4)Device Drivers ManualNG_PATCH(4)
-
-
-

-

ng_patch — trivial - mbuf data modifying netgraph node type

-
-
-

-

#include - <netgraph/ng_patch.h>

-
-
-

-

The patch node performs data modification - of packets passing through it. Modifications are restricted to a subset of C - language operations on unsigned integers of 8, 16, 32 or 64 bit size. These - are: set to new value (=), addition (+=), subtraction (-=), multiplication - (*=), division (/=), negation (= -), bitwise AND (&=), bitwise OR (|=), - bitwise eXclusive OR (^=), shift left (<<=), shift right (>>=). - A negation operation is the one exception: integer is treated as signed and - second operand (the value) is not used. If there is - more than one modification operation, they are applied to packets - sequentially in the order they were specified by the user. The data payload - of a packet is viewed as an array of bytes, with a zero offset corresponding - to the very first byte of packet headers, and the - length bytes beginning from - offset as a single integer in network byte order. An - additional offset can be optionally requested at configuration time to - account for packet type.

-
-
-

-

This node type has two hooks:

-
-
in
-
Packets received on this hook are modified according to rules specified in - the configuration and then forwarded to the out - hook, if it exists. Otherwise they are reflected back to the - in hook.
-
out
-
Packets received on this hook are forwarded to the - in hook without any changes.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setdlt)
-
Sets the data link type on the in hook (to help - calculate relative offset). Currently, supported types are - DLT_RAW (raw IP datagrams, no offset applied, the - default) and DLT_EN10MB (Ethernet). DLT_ - definitions can be found in - <net/bpf.h>. If you want - to work on the link layer header you must use no additional offset by - specifying DLT_RAW. If - EN10MB is specified, then the optional additional - offset will take into account the Ethernet header and a QinQ header if - present.
-
- (getdlt)
-
This control message returns the data link type of the - in hook.
-
- (setconfig)
-
This command sets the sequence of modify operations that will be applied - to incoming data on a hook. The following struct - ng_patch_config must be supplied as an argument: -
- 
struct ng_patch_op {
-	uint32_t	offset;
-	uint16_t	length; /* 1,2,4 or 8 bytes */
-	uint16_t	mode;
-	uint64_t	value;
-};
-/* Patching modes */
-#define NG_PATCH_MODE_SET	1
-#define NG_PATCH_MODE_ADD	2
-#define NG_PATCH_MODE_SUB	3
-#define NG_PATCH_MODE_MUL	4
-#define NG_PATCH_MODE_DIV	5
-#define NG_PATCH_MODE_NEG	6
-#define NG_PATCH_MODE_AND	7
-#define NG_PATCH_MODE_OR	8
-#define NG_PATCH_MODE_XOR	9
-#define NG_PATCH_MODE_SHL	10
-#define NG_PATCH_MODE_SHR	11
-
-struct ng_patch_config {
-	uint32_t	count;
-	uint32_t	csum_flags;
-	uint32_t	relative_offset;
-	struct ng_patch_op ops[];
-};
-
-

The csum_flags can be set to any - combination of CSUM_IP, CSUM_TCP, CSUM_SCTP and CSUM_UDP (other values - are ignored) for instructing the IP stack to recalculate the - corresponding checksum before transmitting packet on output interface. - The ng_patch node does not do any checksum - correction by itself.

-

The offset value for the - ng_patch_op structure is calculated from zero by - default (the first byte of packet headers). If - relative_offset is enabled (set to 1) during - configuration, the operation will have an additional amount added to the - offset based on the data link type.

-
-
- (getconfig)
-
This control message returns the current set of modify operations, in the - form of a struct ng_patch_config.
-
- (getstats)
-
Returns the node's statistics as a struct - ng_patch_stats.
-
- (clrstats)
-
Clears the node's statistics.
-
- (getclrstats)
-
This command is identical to NGM_PATCH_GET_STATS, - except that the statistics are also atomically cleared.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

This ng_patch node was designed to modify - TTL and TOS/DSCP fields in IP packets. As an example, suppose you have two - adjacent simplex links to a remote network (e.g. satellite), so that the - packets expiring in between will generate unwanted ICMP-replies which have - to go forth, not back. Thus you need to raise TTL of every packet entering - link by 2 to ensure the TTL will not reach zero there. To achieve this you - can set an ipfw(8) rule to use the - netgraph action to inject packets which are going to - the simplex link into the patch node, by using the following - ngctl(8) script:

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	mkpeer ipfw: patch 200 in
-	name ipfw:200 ttl_add
-	msg ttl_add: setconfig { count=1 csum_flags=1 ops=[	\
-		{ mode=2 value=3 length=1 offset=8 } ] }
-SEQ
-/sbin/ipfw add 150 netgraph 200 ip from any to simplex.remote.net
-
-

Here the “ttl_add” node of - type ng_patch is configured to add (mode - NG_PATCH_MODE_ADD) a value of - 3 to a one-byte TTL field, which is 9th byte of IP packet header.

-

Another example would be two consecutive modifications of packet - TOS field: say, you need to clear the - IPTOS_THROUGHPUT bit and set the - IPTOS_MINCOST bit. So you do:

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	mkpeer ipfw: patch 300 in
-	name ipfw:300 tos_chg
-	msg tos_chg: setconfig { count=2 csum_flags=1 ops=[	\
-		{ mode=7 value=0xf7 length=1 offset=1 }		\
-		{ mode=8 value=0x02 length=1 offset=1 } ] }
-SEQ
-/sbin/ipfw add 160 netgraph 300 ip from any to any not dst-port 80
-
-

This first does NG_PATCH_MODE_AND clearing - the fourth bit and then NG_PATCH_MODE_OR setting the - third bit.

-

In both examples the csum_flags field - indicates that IP checksum (but not TCP or UDP checksum) should be - recalculated before transmit.

-

Note: one should ensure that packets are returned to ipfw after - processing inside netgraph(4), by setting appropriate - sysctl(8) variable:

-
-
sysctl net.inet.ip.fw.one_pass=0
-
-
-
-

-

netgraph(4), ng_ipfw(4), - ngctl(8)

-
-
-

-

The ng_patch node type was implemented in - FreeBSD 8.1.

-
-
-

-

Maxim Ignatenko - ⟨gelraen.ua@gmail.com⟩.

-

Relative offset code by -
- DMitry Vagin

-

This manual page was written by -
- Vadim Goncharov - ⟨vadimnuclight@tpu.ru⟩.

-
-
-

-

The node blindly tries to apply every patching operation to each - packet (except those which offset if greater than length of the packet), so - be sure that you supply only the right packets to it (e.g. changing bytes in - the ARP packets meant to be in IP header could corrupt them and make your - machine unreachable from the network).

-

-

The output path of the IP stack assumes correct fields and lengths - in the packets - changing them by to incorrect values can cause - unpredictable results including kernel panics.

-
-
- - - - - -
November 17, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_pipe.4 3.html b/static/freebsd/man4/ng_pipe.4 3.html deleted file mode 100644 index 4033ae93..00000000 --- a/static/freebsd/man4/ng_pipe.4 3.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - -
NG_PIPE(4)Device Drivers ManualNG_PIPE(4)
-
-
-

-

ng_pipe — Traffic - manipulating netgraph node type

-
-
-

-

#include - <netgraph/ng_pipe.h>

-
-
-

-

The pipe node type manipulates traffic by - emulating bandwidth and delay, as well as random packet losses.

-
-
-

-

This node type supports the following hooks:

-
-
upper
-
Hook leading to upper layer protocols.
-
lower
-
Hook leading to lower layer protocols.
-
-

Traffic flowing from upper - to lower is considered - - traffic. Traffic flowing from lower to - upper is considered - - traffic.

-
-
-

-

Data received on a hook - both in upstream and downstream - direction - is put into an inbound queue. If inbound queue is full, discard - one frame depending on dropping policy (from the head or from the tail of - the queue).

-

There are three mutually exclusive modes for the input queue:

-
-
-
A single queue holds packets in chronological order.
-
-
There are multiple queues for different traffic flows (based on IPv4 IPs). - The longest queue is truncated if necessary. This approach assumes that - the stalling flow is the flow with the most packets currently on - hold.
-
-
This mode is similar to WFQ, but packets are not taken out in strict - chronological order. In principle oldest packets come first, but not too - many packets from the same flow.
-
-

It is possible to configure a duplication probability. As the dice - decides, the currently active packet stays in the queue while a copy of the - packet is sent out. Nothing prevents a packet from being duplicated multiple - times.

-

Packets are dropped with an increasing probability depending on - the size of the packet, if a ber (bit error rate) is - configured.

-

Surviving packets are delayed by the time the packet would need to - travel through a link of the configured bandwidth. If this outbound queue is - full, the packet is dropped.

-
-
-

-

This node type supports the generic control messages and the - following specific messages.

-
-
- (setcfg)
-
Set node configuration to the one specified in struct - ng_pipe_cfg -

Note: To set a value to zero, specify -1 instead. This allows - omitting configuration values, which should not be modified.

-
-
- (getcfg)
-
Return current node configuration as struct - ng_pipe_cfg -
- 
struct ng_pipe_cfg {
-  u_int64_t  bandwidth;     /* bits per second */
-  u_int64_t  delay;         /* additional delay, usec */
-  u_int32_t  header_offset; /* offset of IP header in bytes */
-  u_int32_t  overhead;      /* assumed L2 overhead in bytes */
-  struct ng_pipe_hookcfg  downstream;
-  struct ng_pipe_hookcfg  upstream;
-};
-
-/* Config structure for one hook */
-struct ng_pipe_hookcfg {
-  u_int64_t  bandwidth;       /* bits per second */
-  u_int64_t  ber;             /* avg. interval between bit errors (1 / BER) */
-  u_int32_t  qin_size_limit;  /* number of queue items */
-  u_int32_t  qout_size_limit; /* number of queue items */
-  u_int32_t  duplicate;       /* probability in % */
-  u_int32_t  fifo;            /* 0 = off, 1 = on */
-  u_int32_t  drr;             /* 0 = off, 1 = 2048 bytes, or x bytes */
-  u_int32_t  wfq;             /* 0 = off, 1 = on */
-  u_int32_t  droptail;        /* 0 = off, 1 = on */
-  u_int32_t  drophead;        /* 0 = off, 1 = on */
-};
-
-
-
- (getstats)
-
Return node statistics as struct ng_pipe_stats -
- 
/* Statistics structure for one hook */
-struct ng_pipe_hookstat {
-  u_int64_t  fwd_octets;
-  u_int64_t  fwd_frames;
-  u_int64_t  in_disc_octets;
-  u_int64_t  in_disc_frames;
-  u_int64_t  out_disc_octets;
-  u_int64_t  out_disc_frames;
-};
-
-/* Statistics structure returned by NGM_PIPE_GET_STATS */
-struct ng_pipe_stats {
-  struct ng_pipe_hookstat  downstream;
-  struct ng_pipe_hookstat  upstream;
-};
-
-
-
- (clrstats)
-
Clear node statistics.
-
- (getclrstats)
-
Atomically return and clear node statistics.
-
- (getrun)
-
Return node statistics as struct ng_pipe_run -
- 
/* Runtime structure for one hook */
-struct ng_pipe_hookrun {
-  u_int32_t  fifo_queues;
-  u_int32_t  qin_octets;
-  u_int32_t  qin_frames;
-  u_int32_t  qout_octets;
-  u_int32_t  qout_frames;
-};
-
-/* Runtime structure returned by NGM_PIPE_GET_RUN */
-struct ng_pipe_run {
-  struct ng_pipe_hookrun  downstream;
-  struct ng_pipe_hookrun  upstream;
-};
-
-
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

Limit outgoing data rate over fxp0 Ethernet interface to 20Mbps in - fifo mode and incoming to 50kbps in drr mode and 2% duplicate - probability.

-
-
/usr/sbin/ngctl -f- <<-SEQ
-  mkpeer fxp0: pipe lower lower
-  name fxp0:lower fxp0_pipe
-  connect fxp0: fxp0_pipe: upper upper
-  msg fxp0_pipe: setcfg { downstream={ bandwidth=20000000 fifo=1 } }
-  msg fxp0_pipe: setcfg { upstream={ bandwidth=500000 drr=1 duplicate=2 } }
-SEQ
-
-
-
-

-

netgraph(4), ngctl(8)

-
-
-

-

Lutz Donnerhacke - <lutz@donnerhacke.de> - (man page)

-
-
-

-

Error handling for memory issues is missing. If kernel memory - cannot be allocated immediately, a kernel panic will be triggered. Same - happens if an mbuf is fragmented within the transport headers.

-
-
- - - - - -
October 17, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ppp.4 3.html b/static/freebsd/man4/ng_ppp.4 3.html deleted file mode 100644 index 56c18b90..00000000 --- a/static/freebsd/man4/ng_ppp.4 3.html +++ /dev/null @@ -1,358 +0,0 @@ - - - - - - -
NG_PPP(4)Device Drivers ManualNG_PPP(4)
-
-
-

-

ng_ppp — PPP - protocol netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_ppp.h>

-
-
-

-

The ppp node type performs multiplexing - for the PPP protocol. It handles only packets that contain data, and - forwards protocol negotiation and control packets to a separate controlling - entity (e.g., a user-land daemon). This approach combines the fast dispatch - of kernel implementations with the configuration flexibility of a user-land - implementations. The PPP node type directly supports multi-link PPP, Van - Jacobson compression, PPP compression, PPP encryption, and the IP, IPX, and - AppleTalk protocols. A single PPP node corresponds to one PPP multi-link - bundle.

-

There is a separate hook for each PPP link in the bundle, plus - several hooks corresponding to the directly supported protocols. For - compression and encryption, separate attached nodes are required to do the - actual work. The node type used will of course depend on the algorithm - negotiated. There is also a bypass hook which is - used to handle any protocol not directly supported by the node. This - includes all of the control protocols: LCP, IPCP, CCP, etc. Typically this - node is connected to a user-land daemon via a ng_socket(4) - type node.

-
-
-

-

In general, the PPP node enables a specific link or functionality - when (a) a NGM_PPP_SET_CONFIG message has been - received which enables it, and (b) the corresponding hook(s) are connected. - This allows the controlling entity to use either method (a) or (b) (or both) - to control the node's behavior. When a link is connected but disabled, - traffic can still flow on the link via the bypass - hook (see below).

-
-
-

-

During normal operation, the individual PPP links are connected to - hooks link0, link1, etc. Up - to NG_PPP_MAX_LINKS links are supported. These - device-independent hooks transmit and receive full PPP frames, which include - the PPP protocol, address, control, and information fields, but no checksum - or other link-specific fields.

-

On outgoing frames, when protocol compression has been enabled and - the protocol number is suitable for compression, the protocol field will be - compressed (i.e., sent as one byte instead of two). Either compressed or - uncompressed protocol fields are accepted on incoming frames. Similarly, if - address and control field compression has been enabled for the link, the - address and control fields will be omitted (except for LCP frames as - required by the standards). Incoming frames have the address and control - fields stripped automatically if present.

-

Since all negotiation is handled outside the PPP node, the links - should not be connected and enabled until the corresponding link has reached - the network phase (i.e., LCP negotiation and authentication have completed - successfully) and the PPP node has been informed of the link parameters via - the NGM_PPP_LINK_CONFIG message.

-

When a link is connected but disabled, all received frames are - forwarded directly out the bypass hook, and - conversely, frames may be transmitted via the bypass - hook as well. This mode is appropriate for the link authentication phase. As - soon as the link is enabled, the PPP node will begin processing frames - received on the link.

-
-
-

-

Compression is supported via two hooks, - compress and decompress. - Compression and decompression can be enabled by toggling the - enableCompression and - enableDecompression fields of the node configuration - structure. (See below.) If enableCompression is set to - NG_PPP_COMPRESS_SIMPLE, then all outgoing frames are - sent to the compress hook and all packets received - on this hook are expected to be compressed, so the COMPD tag is put on them - unconditionally. If enableCompression is set to - NG_PPP_COMPRESS_FULL, then packets received on the - compress hook are resent as is. The compressor node - should put the tag, if the packet was compressed. If - enableDecompression is set to - NG_PPP_DECOMPRESS_SIMPLE, then the node will sent to - the decompress hook only those frames, that are - marked with the COMPD tag. If enableDecompression is - set to NG_PPP_DECOMPRESS_FULL, then the node will - sent all incoming packets to the decompress hook. - Compression and decompression can be completely disabled by setting the - enableCompression and - enableDecompression fields to the - NG_PPP_COMPRESS_NONE and - NG_PPP_DECOMPRESS_NONE, respectively.

-

Encryption works exactly analogously via the - encrypt and decrypt nodes. - Data is always compressed before being encrypted, and decrypted before being - decompressed.

-

Only bundle-level compression and encryption is directly - supported; link-level compression and encryption can be handled - transparently by downstream nodes.

-
-
-

-

When all of the vjc_ip, - vjc_vjcomp, vjc_vjuncomp, - and vjc_vjip hooks are connected, and the - corresponding configuration flag is enabled, Van Jacobson compression and/or - decompression will become active. Normally these hooks connect to the - corresponding hooks of a single ng_vjc(4) node. The PPP - node is compatible with the “pass through” modes of the - ng_vjc(4) node type.

-
-
-

-

When a frame is received on a link with an unsupported protocol, - or a protocol which is disabled or for which the corresponding hook is - unconnected, the PPP node forwards the frame out the - bypass hook, prepended with a four byte prefix. This - first two bytes of the prefix indicate the link number on which the frame - was received (in network order). For such frames received over the bundle - (i.e., encapsulated in the multi-link protocol), the special link number - NG_PPP_BUNDLE_LINKNUM is used. After the two byte - link number is the two byte PPP protocol number (also in network order). The - PPP protocol number is two bytes long even if the original frame was - protocol compressed.

-

Conversely, any data written to the bypass - hook is assumed to be in this same format. The four byte header is stripped - off, the PPP protocol number is prepended (possibly compressed), and the - frame is delivered over the desired link. If the link number is - NG_PPP_BUNDLE_LINKNUM the frame will be delivered - over the multi-link bundle; or, if multi-link is disabled, over the (single) - PPP link.

-

Typically when the controlling entity receives an unexpected - packet on the bypass hook it responds either by - dropping the frame (if it is not ready for the protocol) or with an LCP - protocol reject (if it does not recognize or expect the protocol).

-
-
-

-

To enable multi-link PPP, the corresponding configuration flag - must be set and at least one link connected. The PPP node will not allow - more than one link to be connected if multi-link is not enabled, nor will it - allow certain multi-link settings to be changed while multi-link operation - is active (e.g., short sequence number header format).

-

Since packets are sent as fragments across multiple individual - links, it is important that when a link goes down the PPP node is notified - immediately, either by disconnecting the corresponding hook or disabling the - link via the NGM_PPP_SET_CONFIG control message.

-

Each link has configuration parameters for - latency (specified in milliseconds) and bandwidth (specified in tens of - bytes per second). The PPP node can be configured for - - or - - packet delivery.

-

When configured for round-robin delivery, the latency and - bandwidth values are ignored and the PPP node simply sends each frame as a - single fragment, alternating frames across all the links in the bundle. This - scheme has the advantage that even if one link fails silently, some packets - will still get through. It has the disadvantage of sub-optimal overall - bundle latency, which is important for interactive response time, and - sub-optimal overall bundle bandwidth when links with different bandwidths - exist in the same bundle.

-

When configured for optimal delivery, the PPP node distributes the - packet across the links in a way that minimizes the time it takes for the - completed packet to be received by the far end. This involves taking into - account each link's latency, bandwidth, and current queue length. Therefore - these numbers should be configured as accurately as possible. The algorithm - does require some computation, so may not be appropriate for very slow - machines and/or very fast links.

-

As a special case, if all links have identical latency and - bandwidth, then the above algorithm is disabled (because it is unnecessary) - and the PPP node simply fragments frames into equal sized portions across - all of the links.

-
-
-

-

This node type supports the following hooks:

-
-
link<N>
-
Individual PPP link number <N>
-
compress
-
Connection to compression engine
-
decompress
-
Connection to decompression engine
-
encrypt
-
Connection to encryption engine
-
decrypt
-
Connection to decryption engine
-
vjc_ip
-
Connection to ng_vjc(4) ip - hook
-
vjc_vjcomp
-
Connection to ng_vjc(4) vjcomp - hook
-
vjc_vjuncomp
-
Connection to ng_vjc(4) vjuncomp - hook
-
vjc_vjip
-
Connection to ng_vjc(4) vjip - hook
-
inet
-
IP packet data
-
ipv6
-
IPv6 packet data
-
atalk
-
AppleTalk packet data
-
ipx
-
IPX packet data
-
bypass
-
Bypass hook; frames have a four byte header consisting of a link number - and a PPP protocol number.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
This command configures all aspects of the node. This includes enabling - multi-link PPP, encryption, compression, Van Jacobson compression, and IP, - IPv6, AppleTalk, and IPX packet delivery. It includes per-link - configuration, including enabling the link, setting latency and bandwidth - parameters, and enabling protocol field compression. Note that no link or - functionality is active until the corresponding hook is also connected. - This command takes a struct ng_ppp_node_conf as an - argument: -
- 
/* Per-link config structure */
-struct ng_ppp_link_conf {
-  u_char    enableLink;     /* enable this link */
-  u_char    enableProtoComp;/* enable protocol field compression */
-  u_char    enableACFComp;  /* enable addr/ctrl field compression */
-  uint16_t  mru;            /* peer MRU */
-  uint32_t  latency;        /* link latency (in milliseconds) */
-  uint32_t  bandwidth;      /* link bandwidth (in bytes/sec/10) */
-};
-
-/* Bundle config structure */
-struct ng_ppp_bund_conf {
-  uint16_t  mrru;                   /* multilink peer MRRU */
-  u_char    enableMultilink;        /* enable multilink */
-  u_char    recvShortSeq;           /* recv multilink short seq # */
-  u_char    xmitShortSeq;           /* xmit multilink short seq # */
-  u_char    enableRoundRobin;       /* xmit whole packets */
-  u_char    enableIP;               /* enable IP data flow */
-  u_char    enableIPv6;             /* enable IPv6 data flow */
-  u_char    enableAtalk;            /* enable AppleTalk data flow */
-  u_char    enableIPX;              /* enable IPX data flow */
-  u_char    enableCompression;      /* enable PPP compression */
-  u_char    enableDecompression;    /* enable PPP decompression */
-  u_char    enableEncryption;       /* enable PPP encryption */
-  u_char    enableDecryption;       /* enable PPP decryption */
-  u_char    enableVJCompression;    /* enable VJ compression */
-  u_char    enableVJDecompression;  /* enable VJ decompression */
-};
-
-struct ng_ppp_node_conf {
-  struct ng_ppp_bund_conf   bund;
-  struct ng_ppp_link_conf   links[NG_PPP_MAX_LINKS];
-};
-
-
-
- (getconfig)
-
Returns the current configuration as a struct - ng_ppp_node_conf.
- -
This command takes a two byte link number as an argument and returns a - struct ng_ppp_link_stat containing statistics for - the corresponding link. Here NG_PPP_BUNDLE_LINKNUM - is a valid link number corresponding to the multi-link bundle.
- -
Same as NGM_PPP_GET_LINK_STATS but returns struct - ng_ppp_link_stat64 containing 64bit counters.
- -
This command takes a two byte link number as an argument and clears the - statistics for that link.
- -
Same as NGM_PPP_GET_LINK_STATS, but also - atomically clears the statistics as well.
- -
Same as NGM_PPP_GETCLR_LINK_STATS but returns struct - ng_ppp_link_stat64 containing 64bit counters.
-
-

This node type also accepts the control messages accepted by the - ng_vjc(4) node type. When received, these messages are - simply forwarded to the adjacent ng_vjc(4) node, if any. - This is particularly useful when the individual PPP links are able to - generate NGM_VJC_RECV_ERROR messages (see - ng_vjc(4) for a description).

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_async(4), - ng_iface(4), ng_mppc(4), - ng_pppoe(4), ng_vjc(4), - ngctl(8)

-

W. Simpson, - The Point-to-Point Protocol (PPP), - RFC 1661.

-

K. Sklower, - B. Lloyd, G. McGregor, - D. Carr, and T. Coradetti, - The PPP Multilink Protocol (MP), - RFC 1990.

-
-
-

-

The ng_ppp node type was implemented in - FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
- - - - - -
November 13, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_pppoe.4 3.html b/static/freebsd/man4/ng_pppoe.4 3.html deleted file mode 100644 index ed731f33..00000000 --- a/static/freebsd/man4/ng_pppoe.4 3.html +++ /dev/null @@ -1,533 +0,0 @@ - - - - - - -
NG_PPPOE(4)Device Drivers ManualNG_PPPOE(4)
-
-
-

-

ng_pppoe — RFC - 2516 PPPoE protocol netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include <net/ethernet.h> -
- #include <netgraph.h> -
- #include - <netgraph/ng_pppoe.h>

-
-
-

-

The pppoe node type performs the PPPoE - protocol. It is used in conjunction with the netgraph(4) - extensions to the Ethernet framework to divert and inject Ethernet packets - to and from a PPP agent (which is not specified).

-

The NGM_PPPOE_GET_STATUS control message - can be used at any time to query the current status of the PPPoE module. The - only statistics presently available are the total packet counts for input - and output. This node does not yet support the - NGM_TEXT_STATUS control message.

-
-
-

-

This node type supports the following hooks:

-
-
ethernet
-
The hook that should normally be connected to an - ng_ether(4) node. Once connected, - ng_pppoe will send a message down this hook to - determine Ethernet address of the underlying node. Obtained address will - be stored and then used for outgoing datagrams.
-
debug
-
Presently no use.
-
[unspecified]
-
Any other name is assumed to be a session hook that will be connected to a - PPP client agent, or a PPP server agent.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
This command returns status information in a struct - ngpppoestat: -
- 
struct ngpppoestat {
-    u_int   packets_in;     /* packets in from Ethernet */
-    u_int   packets_out;    /* packets out towards Ethernet */
-};
-
-
-
-
This generic message returns a human-readable version of the node status. - (not yet)
-
- (pppoe_connect)
-
Tell a nominated newly created hook that its session should enter the - state machine as a client. It must be newly created and a service name can - be given as an argument. It is legal to specify a zero-length service - name, this is common on some DSL setups. It is possible to request a - connection to a specific access concentrator, and/or set a specific - Host-Uniq tag, required by some Internet providers, using the - "[AC-Name][Host-Uniq|]Service-Name" - syntax. To set a binary Host-Uniq, it must be encoded as a hexadecimal - lowercase string and prefixed with "0x", - for example "0x6d792d746167" is - equivalent to "my-tag". A session - request packet will be broadcast on the Ethernet. This command uses the - ngpppoe_init_data structure shown below. For - example, this init data argument can be used to connect to - "my-isp" service with - "my-host" uniq tag, accepting only - "remote-ac" as access concentrator: -
- 
"remote-ac\my-host|my-isp"
-
-
-
- (pppoe_listen)
-
Tell a nominated newly created hook that its session should enter the - state machine as a server listener. The argument given is the name of the - service to listen for. A zero-length service name will match all requests - for service. A matching service request packet will be passed unmodified - back to the process responsible for starting the service. It can then - examine it and pass it on to the session that is started to answer the - request. This command uses the ngpppoe_init_data - structure shown below.
-
- (pppoe_offer)
-
Tell a nominated newly created hook that its session should enter the - state machine as a server. The argument given is the name of the service - to offer. A zero-length service is legal. The State machine will progress - to a state where it will await a request packet to be forwarded to it from - the startup server, which in turn probably received it from a LISTEN mode - hook (see above). This is so that information that is required for the - session that is embedded in the original session request packet, is made - available to the state machine that eventually answers the request. When - the Session request packet is received, the session negotiation will - proceed. This command uses the ngpppoe_init_data - structure shown below.
-
-

The three commands above use a common data structure:

-
-
struct ngpppoe_init_data {
-    char       hook[NG_HOOKSIZ];       /* hook to monitor on */
-    uint16_t   data_len;               /* length of the service name */
-    char       data[0];                /* init data goes here */
-};
-
-
-
- (pppoe_success)
-
This command is sent to the node that started this session with one of the - above messages, and reports a state change. This message reports - successful Session negotiation. It uses the structure shown below, and - reports back the hook name corresponding to the successful session.
-
- (pppoe_fail)
-
This command is sent to the node that started this session with one of the - above messages, and reports a state change. This message reports failed - Session negotiation. It uses the structure shown below, and reports back - the hook name corresponding to the failed session. The hook will probably - have been removed immediately after sending this message.
-
- (pppoe_close)
-
This command is sent to the node that started this session with one of the - above messages, and reports a state change. This message reports a request - to close a session. It uses the structure shown below, and reports back - the hook name corresponding to the closed session. The hook will probably - have been removed immediately after sending this message. At present this - message is not yet used and a NGM_PPPOE_FAIL - message will be received at closure instead.
-
-
This command is sent to the node that started this session with one of the - above messages, and reports the Access Concentrator Name.
-
-

The four commands above use a common data structure:

-
-
struct ngpppoe_sts {
-    char    hook[NG_HOOKSIZ];
-};
-
-
-
- (pppoe_getmode)
-
This command returns the current compatibility mode of the node as a - string. ASCII form of this message is - "pppoe_getmode". The following keywords - can be returned: -
-
"standard"
-
The node operates according to RFC 2516.
-
"3Com"
-
When ng_pppoe is a PPPoE client, it initiates - a session encapsulating packets into incorrect 3Com ethertypes. This - compatibility option does not affect server mode. In server mode - ng_pppoe supports both modes simultaneously, - depending on the ethertype, the client used when connecting.
-
"D-Link"
-
When ng_pppoe is a PPPoE server serving only - specific Service-Name(s), it will respond to a PADI requests with - empty Service-Name tag, returning all available Service-Name(s) on - node. This option is necessary for compatibility with D-Link DI-614+ - and DI-624+ SOHO routers as clients, when serving only specific - Service-Name. This compatibility option does not affect client - mode.
-
-
-
- (pppoe_setmode)
-
Configure node to the specified mode. The string argument is required. - This command understands the same keywords that are returned by the - NGM_PPPOE_GETMODE command. ASCII form of this - message is "pppoe_setmode". For example, - the following command will configure the node to initiate the next session - in the proprietary 3Com mode: -
- 
ngctl msg fxp0:orphans pppoe_setmode '"3Com"'
-
-
-
- (setenaddr)
-
Set the node Ethernet address for outgoing datagrams. This message is - important when a node has failed to obtain an Ethernet address from its - peer on the ethernet hook, or when user wants to - override this address with another one. ASCII form of this message is - "setenaddr".
-
- (setmaxp)
-
Set the node PPP-Max-Payload value as described in RFC 4638. This message - applies only to a client configuration. ASCII form of this message is - "setmaxp". -

Data structure returned to client is:

-
- 
struct ngpppoe_maxp {
-    char     hook[NG_HOOKSIZ];
-    uint16_t data;
-};
-
-
-
- (send_hurl)
-
Tell a nominated hook with an active session to send a PADM message with a - HURL tag. The argument is the URL to be delivered to the client: -
- 
ngctl msg fxp0:orphans send_hurl '{ hook="myHook" data="http://example.net/cpe" }'
-
-
-
- (send_motm)
-
Tell a nominated hook with an active session to send a PADM message with a - MOTM tag. The argument is the message to be delivered to the client: -
- 
ngctl msg fxp0:orphans send_motm '{ hook="myHook" data="Welcome aboard" }'
-
-
-
-

The two commands above use the same ngpppoe_init_data structure - described above.

-
-
-
This command is sent to the node that started this session when a PADM - message with a HURL tag is received, and contains a URL that the host can - pass to a web browser for presentation to the user.
-
-
This command is sent to the node that started this session when a PADM - message with a MOTM tag is received, and contains a Message Of The Minute - that the host can display to the user.
-
-

The two commands above use a common data structure:

-
-
struct ngpppoe_padm {
-    char    msg[PPPOE_PADM_VALUE_SIZE];
-};
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, when all session have - been disconnected or when the ethernet hook is - disconnected.

-
-
-

-

The node can mark transmitted LCP Ethernet packets (protocol - 0xc021) with 3-bit Priority Code Point (PCP) referring to IEEE 802.1p class - of service with following sysctl(8) variable.

-
-
net.graph.pppoe.lcp_pcp: - 0..7 (default: 0)
-
Set it to non-zero value to be used by parent network interface driver - like vlan(4)
-
-
-
-

-

The following code uses libnetgraph to set - up a ng_pppoe node and connect it to both a socket - node and an Ethernet node. It can handle the case of when a - ng_pppoe node is already attached to the Ethernet. - It then starts a client session.

-
-
#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <ctype.h>
-#include <unistd.h>
-#include <sysexits.h>
-#include <errno.h>
-#include <err.h>
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/select.h>
-#include <net/ethernet.h>
-
-#include <netgraph.h>
-#include <netgraph/ng_ether.h>
-#include <netgraph/ng_pppoe.h>
-#include <netgraph/ng_socket.h>
-static int setup(char *ethername, char *service, char *sessname,
-				int *dfd, int *cfd);
-
-int
-main()
-{
-	int  fd1, fd2;
-	setup("xl0", NULL, "fred", &fd1, &fd2);
-	sleep (30);
-}
-
-static int
-setup(char *ethername, char *service, char *sessname,
-			int *dfd, int *cfd)
-{
-	struct ngm_connect ngc;	/* connect */
-	struct ngm_mkpeer mkp;	/* mkpeer */
-	/******** nodeinfo stuff **********/
-	u_char          rbuf[2 * 1024];
-	struct ng_mesg *const resp = (struct ng_mesg *) rbuf;
-	struct hooklist *const hlist
-			= (struct hooklist *) resp->data;
-	struct nodeinfo *const ninfo = &hlist->nodeinfo;
-	int             ch, no_hooks = 0;
-	struct linkinfo *link;
-	struct nodeinfo *peer;
-	/****message to connect PPPoE session*****/
-	struct {
-		struct ngpppoe_init_data idata;
-		char            service[100];
-	}               message;
-	/********tracking our little graph ********/
-	char            path[100];
-	char            source_ID[NG_NODESIZ];
-	char            pppoe_node_name[100];
-	int             k;
-
-	/*
-	 * Create the data and control sockets
-	 */
-	if (NgMkSockNode(NULL, cfd, dfd) < 0) {
-		return (errno);
-	}
-	/*
-	 * find the ether node of the name requested by asking it for
-	 * it's inquiry information.
-	 */
-	if (strlen(ethername) > 16)
-		return (EINVAL);
-	sprintf(path, "%s:", ethername);
-	if (NgSendMsg(*cfd, path, NGM_GENERIC_COOKIE,
-		      NGM_LISTHOOKS, NULL, 0) < 0) {
-		return (errno);
-	}
-	/*
-	 * the command was accepted so it exists. Await the reply (It's
-	 * almost certainly already waiting).
-	 */
-	if (NgRecvMsg(*cfd, resp, sizeof(rbuf), NULL) < 0) {
-		return (errno);
-	}
-	/**
-	 * The following is available about the node:
-	 * ninfo->name		(string)
-	 * ninfo->type		(string)
-	 * ninfo->id		(uint32_t)
-	 * ninfo->hooks		(uint32_t) (count of hooks)
-	 * check it is the correct type. and get it's ID for use
-	 * with mkpeer later.
-	 */
-	if (strncmp(ninfo->type, NG_ETHER_NODE_TYPE,
-		    strlen(NG_ETHER_NODE_TYPE)) != 0) {
-		return (EPROTOTYPE);
-	}
-	sprintf(source_ID, "[%08x]:", ninfo->id);
-
-	/*
-	 * look for a hook already attached.
-	 */
-	for (k = 0; k < ninfo->hooks; k++) {
-		/**
-		 * The following are available about each hook.
-		 * link->ourhook	(string)
-		 * link->peerhook	(string)
-		 * peer->name		(string)
-		 * peer->type		(string)
-		 * peer->id		(uint32_t)
-		 * peer->hooks		(uint32_t)
-		 */
-		link = &hlist->link[k];
-		peer = &hlist->link[k].nodeinfo;
-
-		/* Ignore debug hooks */
-		if (strcmp("debug", link->ourhook) == 0)
-			continue;
-
-		/* If the orphans hook is attached, use that */
-		if (strcmp(NG_ETHER_HOOK_ORPHAN,
-		    link->ourhook) == 0) {
-			break;
-		}
-		/* the other option is the 'divert' hook */
-		if (strcmp("NG_ETHER_HOOK_DIVERT",
-		    link->ourhook) == 0) {
-			break;
-		}
-	}
-
-	/*
-	 * See if we found a hook there.
-	 */
-	if (k < ninfo->hooks) {
-		if (strcmp(peer->type, NG_PPPOE_NODE_TYPE) == 0) {
-			/*
-			 * If it's a type PPPoE, we skip making one
-			 * ourself, but we continue, using
-			 * the existing one.
-			 */
-			sprintf(pppoe_node_name, "[%08x]:", peer->id);
-		} else {
-			/*
-			 * There is already someone hogging the data,
-			 * return an error. Some day we'll try
-			 * daisy-chaining..
-			 */
-			return (EBUSY);
-		}
-	} else {
-
-		/*
-		 * Try make a node of type PPPoE against node "ID"
-		 * On hook NG_ETHER_HOOK_ORPHAN.
-		 */
-		snprintf(mkp.type, sizeof(mkp.type),
-			 "%s", NG_PPPOE_NODE_TYPE);
-		snprintf(mkp.ourhook, sizeof(mkp.ourhook),
-			 "%s", NG_ETHER_HOOK_ORPHAN);
-		snprintf(mkp.peerhook, sizeof(mkp.peerhook),
-			 "%s", NG_PPPOE_HOOK_ETHERNET);
-		/* Send message */
-		if (NgSendMsg(*cfd, source_ID, NGM_GENERIC_COOKIE,
-			      NGM_MKPEER, &mkp, sizeof(mkp)) < 0) {
-			return (errno);
-		}
-		/*
-		 * Work out a name for the new node.
-		 */
-		sprintf(pppoe_node_name, "%s:%s",
-			source_ID, NG_ETHER_HOOK_ORPHAN);
-	}
-	/*
-	 * We now have a PPPoE node attached to the Ethernet
-	 * card. The Ethernet is addressed as ethername: The PPPoE
-	 * node is addressed as pppoe_node_name: attach to it.
-	 * Connect socket node to specified node Use the same hook
-	 * name on both ends of the link.
-	 */
-	snprintf(ngc.path, sizeof(ngc.path), "%s", pppoe_node_name);
-	snprintf(ngc.ourhook, sizeof(ngc.ourhook), "%s", sessname);
-	snprintf(ngc.peerhook, sizeof(ngc.peerhook), "%s", sessname);
-
-	if (NgSendMsg(*cfd, ".:", NGM_GENERIC_COOKIE,
-		      NGM_CONNECT, &ngc, sizeof(ngc)) < 0) {
-		return (errno);
-	}
-
-#ifdef	NONSTANDARD
-	/*
-	 * In some cases we are speaking to 3Com hardware, so
-	 * configure node to non-standard mode.
-	 */
-	if (NgSendMsg(*cfd, ngc.path, NGM_PPPOE_COOKIE,
-			NGM_PPPOE_SETMODE, NG_PPPOE_NONSTANDARD,
-			strlen(NG_PPPOE_NONSTANDARD) + 1) == -1) {
-		return (errno);
-	}
-#endif
-
-	/*
-	 * Send it a message telling it to start up.
-	 */
-	bzero(&message, sizeof(message));
-	snprintf(message.idata.hook, sizeof(message.idata.hook),
-				"%s", sessname);
-	if (service == NULL) {
-		message.idata.data_len = 0;
-	} else {
-		snprintf(message.idata.data,
-			 sizeof(message.idata.data), "%s", service);
-		message.idata.data_len = strlen(service);
-	}
-	/* Tell session/hook to start up as a client */
-	if (NgSendMsg(*cfd, ngc.path,
-		      NGM_PPPOE_COOKIE, NGM_PPPOE_CONNECT, &message.idata,
-		      sizeof(message.idata) + message.idata.data_len) < 0) {
-		return (errno);
-	}
-	return (0);
-}
-
-
-
-

-

netgraph(3), netgraph(4), - ng_ether(4), ng_ppp(4), - ng_socket(4), vlan(4), - ngctl(8), ppp(8)

-

L. Mamakos, - K. Lidl, J. Evarts, - D. Carrel, D. Simone, and - R. Wheeler, A Method for - transmitting PPP over Ethernet (PPPoE), RFC - 2516.

-
-
-

-

The ng_pppoe node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
May 1, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_pptpgre.4 3.html b/static/freebsd/man4/ng_pptpgre.4 3.html deleted file mode 100644 index 486ce1a0..00000000 --- a/static/freebsd/man4/ng_pptpgre.4 3.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
NG_PPTPGRE(4)Device Drivers ManualNG_PPTPGRE(4)
-
-
-

-

ng_pptpgre — PPTP - GRE protocol netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_pptpgre.h>

-
-
-

-

The pptpgre node type performs Generic - Routing Encapsulation (GRE) over IP for the PPTP protocol as specified by - RFC 2637. This involves packet encapsulation, sequencing, acknowledgement, - and an adaptive timeout sliding window mechanism. This node type does not - handle any of the TCP control protocol or call negotiation defined by - PPTP.

-

This node type expects to receive complete IP packets, including - the IP header, on the “lower” hook, - but it transmits outgoing frames without any IP header. The typical use for - this node type would be to connect the - “upper” hook to one of the link hooks - of a ng_ppp(4) node, and the - “lower” hook to the - “inet/raw/gre” hook of a - ng_ksocket(4) node.

-
-
-

-

This node type supports the following hooks:

-
-
session_hhhh
-
Session 0xhhhh data packets to the upper protocol layers
-
upper
-
Same as session_hhhh, but for single session with configurable cid - (legacy)
-
lower
-
Connection to the lower protocol layers
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
This command resets and configures hook for a session. If corresponding - session_hhhh hook is not connected, upper hook will be configured. This - command takes a struct ng_pptpgre_conf as an - argument: -
- 
/* Configuration for a session */
-struct ng_pptpgre_conf {
-    u_char      enabled;          /* enables traffic flow */
-    u_char      enableDelayedAck; /* enables delayed acks */
-    u_char      enableAlwaysAck;  /* always include ack with data */
-    u_char      enableWindowing;  /* enable windowing algorithm */
-    uint16_t    cid;              /* my call id */
-    uint16_t    peerCid;          /* peer call id */
-    uint16_t    recvWin;          /* peer recv window size */
-    uint16_t    peerPpd;          /* peer packet processing delay
-                                     (in 1/10 of a second) */
-};
-
-

The enabled field enables traffic flow - through the node. The enableDelayedAck field - enables delayed acknowledgement (maximum 250 milliseconds), which is a - useful optimization and should generally be turned on. - enableAlwaysAck field enables sending - acknowledgements with every data packet, which is probably helpful as - well.

-

enableWindowing enables the PPTP packet - windowing mechanism specified by the protocol. Disabling this will cause - the node to violate the protocol, possibly confusing other PPTP peers, - but often results in better performance. The windowing mechanism is a - design error in the PPTP protocol; L2TP, the successor to PPTP, removes - it.

-

The remaining fields are as supplied by the PPTP virtual call - setup process.

-
-
- (getconfig)
-
Takes two byte argument as cid and returns the current configuration as a - struct ng_pptpgre_conf.
-
- (getstats)
-
This command returns a struct ng_pptpgre_stats - containing various node statistics.
-
- (clrstats)
-
This command resets the node statistics.
-
- (getclrstats)
-
This command atomically gets and resets the node statistics, returning a - struct ng_pptpgre_stats.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when both hooks - have been disconnected.

-
-
-

-

A set of sysctl(8) variables controls ability of - this node to deal with some amount of packet reorder that sometimes happens - in transit. Packet reorder results in packet drops (unless the order is - restored) as PPP protocol can not deliver reordered data. These variables - are shown below together with their default value and meaning:

-
-
net.graph.pptpgre.reorder_max: - 1
-
Defines maximum length of node's private reorder queue used to keep data - waiting for late packets. Zero value disables reordering. Default value - allows the node to restore the order for two packets swapped in transit. - Greater values allow the node to deliver packets being late after more - packets in sequence at cost of increased kernel memory usage.
-
net.graph.pptpgre.reorder_timeout: - 1
-
Defines time value in milliseconds used to wait for late packets.
-
-
-
-

-

netgraph(4), ng_ksocket(4), - ng_ppp(4), ngctl(8), - sysctl(8)

-

K. Hamzeh, - G. Pall, W. Verthein, - J. Taarud, W. Little, and - G. Zorn, Point-to-Point Tunneling - Protocol (PPTP), RFC 2637.

-

S. Hanks, - T. Li, D. Farinacci, and - P. Traina, Generic Routing - Encapsulation over IPv4 networks, RFC - 1702.

-
-
-

-

The ng_pptpgre node type was implemented - in FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

The node should not expect incoming GRE packets to have an IP - header. This behavior is inherited from the (converse) behavior of raw IP - sockets. An intermediate node that strips IP headers in one direction should - be used instead.

-
-
- - - - - -
November 4, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_pred1.4 3.html b/static/freebsd/man4/ng_pred1.4 3.html deleted file mode 100644 index 97cf0874..00000000 --- a/static/freebsd/man4/ng_pred1.4 3.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - -
NG_PRED1(4)Device Drivers ManualNG_PRED1(4)
-
-
-

-

ng_pred1 — - Predictor-1 PPP compression (RFC 1978) netgraph node - type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_pred1.h>

-
-
-

-

The pred1 node type implements the - Predictor-1 sub-protocols of the Compression Control Protocol (CCP).

-

The node has two hooks, comp for compression - and decomp for decompression. Only one of them can be - connected at the same time, specifying node's operation mode. Typically that - hooks would be connected to the ng_ppp(4) node type hook - of the same name.

-
-
-

-

This node type supports the following hooks:

-

-
-
comp
-
Connection to ng_ppp(4) compress - hook. Incoming frames are compressed and sent back out the same hook.
-
decomp
-
Connection to ng_ppp(4) decompress - hook. Incoming frames are decompressed and sent back out the same - hook.
-
-

Only one hook can be connected at the same time, specifying node's - operation mode.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (config)
-
This command resets and configures the node for a session (i.e., for - compression or decompression). This command takes a struct - ng_pred1_config as an argument: -
- 
struct ng_pred1_config {
-	u_char		enable;			/* node enabled */
-};
-
- The enable field enables traffic flow through the - node.
-
- (resetreq)
-
This message contains no arguments, and is bi-directional. If an error is - detected during decompression, this message is sent by the node to the - originator of the NGM_PRED1_CONFIG message that - initiated the session. The receiver should respond by sending a PPP CCP - Reset-Request to the peer. -

This message may also be received by this node type when a CCP - Reset-Request or Reset-Ack is received by the local PPP entity. The node - will respond by flushing its compression state so the sides can - resynchronize.

-
-
- (getstats)
-
This control message obtains statistics for a given hook. The statistics - are returned in struct ng_pred1_stats: -
- 
struct ng_pred1_stats {
-	uint64_t	FramesPlain;
-	uint64_t	FramesComp;
-	uint64_t	FramesUncomp;
-	uint64_t	InOctets;
-	uint64_t	OutOctets;
-	uint64_t	Errors;
-};
-
-
-
- (clrstats)
-
This control message clears statistics for a given hook.
-
- (getclrstats)
-
This control message obtains and clears statistics for a given hook.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when hook have been - disconnected.

-
-
-

-

netgraph(4), ng_ppp(4), - ngctl(8)

-

D. Rand, - PPP Predictor Compression Protocol, - RFC 1978.

-

W. Simpson, - The Point-to-Point Protocol (PPP), - RFC 1661.

-
-
-

-

Alexander Motin - <mav@alkar.net>

-
-
-

-

Due to nature of netgraph PPP implementation there are possible - race conditions between data packet and ResetAck CCP packet in case of - packet loss. As result, packet loss can produce bigger performance - degradation than supposed by protocol.

-
-
- - - - - -
December 24, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_rfc1490.4 3.html b/static/freebsd/man4/ng_rfc1490.4 3.html deleted file mode 100644 index b109b3f1..00000000 --- a/static/freebsd/man4/ng_rfc1490.4 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
NG_RFC1490(4)Device Drivers ManualNG_RFC1490(4)
-
-
-

-

ng_rfc1490 — RFC - 1490 netgraph node type

-
-
-

-

#include - <netgraph/ng_rfc1490.h>

-
-
-

-

The rfc1490 node type performs protocol - encapsulation, de-encapsulation, and multiplexing according to RFC 1490 - (which has since been updated by RFC 2427). This particular type of - encapsulation is often used on top of frame relay DLCI channels.

-

The downstream hook is used to transmit - and receive encapsulated frames. On the other side of the node, the - inet and ppp hooks are used - to transmit and receive raw IP frames and PPP frames, respectively. PPP - frames are transmitted and received according to RFC 1973; in particular, - frames appearing on the ppp hook begin with the PPP - protocol number. The ethernet hook can be used to - transmit and receive Ethernet frames (without a checksum) in RFC 1490's - bridging format.

-

Typically the inet hook is connected to - the inet hook of an ng_iface(4) - node.

-
-
-

-

This node type supports the following hooks:

-
-
downstream
-
Connects to the RFC 1490 peer entity.
-
ethernet
-
Transmits and receives bridged raw Ethernet frames, without a - checksum.
-
inet
-
Transmits and receives raw IP frames.
-
ppp
-
Transmits and receives PPP frames.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setencap)
-
This command sets encapsulation method for the node. The desired method - must be passed as a string message argument, and must be one of the - following supported encapsulation modes: -
-
"ietf-ip"
-
IP packets are sent using simple RFC1490/2427 encapsulation.
-
"ietf-snap"
-
IP packets are sent inside SNAP frames. Also conforms to - RFC1490/2427.
-
"cisco"
-
IP packets are sent and received using proprietary Cisco encapsulation - method.
-
-
-
- (getencap)
-
This command returns current encapsulation method on the node.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), - ng_frame_relay(4), ng_iface(4), - ngctl(8)

-

C. Brown and - A. Malis, Multiprotocol - Interconnect over Frame Relay, RFC - 2427.

-

W. Simpson, - PPP in Frame Relay, RFC - 1973.

-

http://www.cisco.com/warp/public/121/frf8modes.pdf

-
-
-

-

The ng_rfc1490 node type was implemented - in FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
-

-

Not all of RFC 1490 is implemented.

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_socket.4 3.html b/static/freebsd/man4/ng_socket.4 3.html deleted file mode 100644 index c086bc6b..00000000 --- a/static/freebsd/man4/ng_socket.4 3.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - -
NG_SOCKET(4)Device Drivers ManualNG_SOCKET(4)
-
-
-

-

ng_socket — - netgraph socket node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_socket.h>

-
-
-

-

A socket node is both a - BSD socket and a netgraph node. The - ng_socket node type allows user-mode processes to - participate in the kernel netgraph(4) networking subsystem - using the BSD socket interface. The process must - have root privileges to be able to create netgraph sockets however once - created, any process that has one may use it.

-

A new ng_socket node is created by - creating a new socket of type NG_CONTROL in the - protocol family PF_NETGRAPH, using the - socket(2) system call. Any control messages received by - the node and not having a cookie value of - NGM_SOCKET_COOKIE are received by the process, using - recvfrom(2); the socket address argument is a - struct sockaddr_ng containing the sender's netgraph - address. Conversely, control messages can be sent to any node by calling - sendto(2), supplying the recipient's address in a - struct sockaddr_ng. The bind(2) - system call may be used to assign a global netgraph name to the node.

-

To transmit and receive netgraph data packets, a - NG_DATA socket must also be created using - socket(2) and associated with a - ng_socket node. NG_DATA - sockets do not automatically have nodes associated with them; they are bound - to a specific node via the connect(2) system call. The - address argument is the netgraph address of the - ng_socket node already created. Once a data socket - is associated with a node, any data packets received by the node are read - using recvfrom(2) and any packets to be sent out from the - node are written using sendto(2). In the case of data - sockets, the struct sockaddr_ng contains the name of - the on which - the data was received or should be sent.

-

As a special case, to allow netgraph data sockets to be used as - stdin or stdout on naive programs, a sendto(2) with a NULL - sockaddr pointer, a send(2) or a - write(2) will succeed in the case where there is exactly - ONE hook attached to the socket node, (and thus the path is - unambiguous).

-

There is a user library that simplifies using netgraph sockets; - see netgraph(3).

-
-
-

-

This node type supports hooks with arbitrary names (as long as - they are unique) and always accepts hook connection requests.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
When the last hook is removed from this node, it will shut down as if it - had received a NGM_SHUTDOWN message. Attempts to - access the sockets associated will return - ENOTCONN.
-
-
This is the default mode. When the last hook is removed, the node will - continue to exist, ready to accept new hooks until it is explicitly shut - down.
-
-

All other messages with neither the - NGM_SOCKET_COOKIE or - NGM_GENERIC_COOKIE will be passed unaltered up the - NG_CONTROL socket.

-
-
-

-

This node type shuts down and disappears when both the associated - NG_CONTROL and NG_DATA - sockets have been closed, or a NGM_SHUTDOWN control - message is received. In the latter case, attempts to write to the still-open - sockets will return ENOTCONN. If the - NGM_SOCK_CMD_NOLINGER message has been received, - closure of the last hook will also initiate a shutdown of the node.

-
-
-

-

socket(2), netgraph(3), - netgraph(4), ng_ksocket(4), - ngctl(8)

-
-
-

-

The ng_socket node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
-

-

It is not possible to reject the connection of a hook, though any - data received on that hook can certainly be ignored.

-

The controlling process is not notified of all events that an - in-kernel node would be notified of, e.g. a new hook, or hook removal. Some - node-initiated messages should be defined for this purpose (to be sent up - the control socket).

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_source.4 3.html b/static/freebsd/man4/ng_source.4 3.html deleted file mode 100644 index d7298def..00000000 --- a/static/freebsd/man4/ng_source.4 3.html +++ /dev/null @@ -1,281 +0,0 @@ - - - - - - -
NG_SOURCE(4)Device Drivers ManualNG_SOURCE(4)
-
-
-

-

ng_source — - netgraph node for traffic generation

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_source.h>

-
-
-

-

The source node acts as a source of - packets according to the parameters set up using control messages and input - packets. The ng_source node type is used primarily - for testing and benchmarking.

-
-
-

-

The source node has two hooks: - input and output. The - output hook must remain connected, its disconnection - will shutdown the node.

-
-
-

-

The operation of the node is as follows. Packets received on the - input hook are queued internally. When - output hook is connected, - ng_source node assumes that its neighbour node is of - ng_ether(4) node type. The neighbour is queried for its - interface name. The ng_source node then uses queue - of the interface for its evil purposes. The - ng_source node also disables - autosrc option on neighbour - ng_ether(4) node. If interface name cannot be obtained - automatically, it should be configured explicitly with the - NGM_SOURCE_SETIFACE control message, and - autosrc should be turned off on - ng_ether(4) node manually.

-

If the node is connected to a netgraph network, which does not - terminate in a real ng_ether(4) interface, limit the - packet injection rate explicitly with the - NGM_SOURCE_SETPPS control message.

-

Upon receipt of a NGM_SOURCE_START control - message the node starts sending the previously queued packets out the - output hook on every clock tick as fast as the - connected interface will take them. While active, on every clock tick the - node checks the available space in the interface queue and sends that many - packets out its output hook. Once the number of - packets indicated in the start message has been sent, or upon receipt of a - NGM_SOURCE_STOP message, the node stops sending - data.

-
-
-

-

This node type supports the generic control messages as well as - the following, which must be sent with the - NGM_SOURCE_COOKIE attached.

-
-
- (getstats)
-
Returns a structure containing the following fields: -
-
outOctets
-
The number of octets/bytes sent out the output - hook.
-
outFrames
-
The number of frames/packets sent out the output - hook.
-
queueOctets
-
The number of octets queued from the input - hook.
-
queueFrames
-
The number of frames queued from the input - hook.
-
startTime
-
The time the last start message was received.
-
endTime
-
The time the last end message was received or the output packet count - was reached.
-
elapsedTime
-
Either endTime - - startTime or current time - - startTime.
-
-
-
- (clrstats)
-
Clears and resets the statistics returned by - getstats (except queueOctets - and queueFrames).
-
- (getclrstats)
-
As getstats but clears the statistics at the same - time.
-
- (start)
-
This message requires a single uint64_t parameter - which is the number of packets to send before stopping. Node starts - sending the queued packets out the output hook. The - output hook must be connected and node must have - interface configured.
-
- (stop)
-
Stops the node if it is active.
-
- (clrdata)
-
Clears the packets queued from the input hook.
-
- (setiface)
-
This message requires the name of the interface to be configured as an - argument.
-
- (setpps)
-
This message requires a single uint32_t parameter - which puts upper limit on the amount of packets sent per second.
-
- (settimestamp)
-
This message specifies that a timestamp (in the format of a - struct timeval) should be inserted in the - transmitted packets. This message requires a structure containing the - following fields: -
-
offset
-
The offset from the beginning of the packet at which the timestamp is - to be inserted.
-
flags
-
Set to 1 to enable the timestamp.
-
-
-
- (gettimestamp)
-
Returns the current timestamp settings in the form of the structure - described above.
-
- (setcounter)
-
This message specifies that a counter should be embedded in transmitted - packets. Up to four counters may be independently configured. This message - requires a structure containing the following fields: -
-
offset
-
The offset from the beginning of the packet at which the counter is to - be inserted.
-
flags
-
Set to 1 to enable the counter.
-
width
-
The byte width of the counter. It may be 1, 2, or 4.
-
next_val
-
The value for the next insertion of the counter.
-
min_val
-
The minimum value to be used by the counter.
-
max_val
-
The maximum value to be used by the counter.
-
increment
-
The value to be added to the counter after each insertion. It may be - negative.
-
index
-
The counter to be configured, from 0 to 3.
-
-
-
- (getcounter)
-
This message requires a single uint8_t parameter - which specifies the counter to query. Returns the current counter settings - in the form of the structure described above.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, when all hooks have - been disconnected, or when the output hook has been - disconnected.

-
-
-

-

Attach the node to an ng_ether(4) node for an - interface. If ng_ether is not already loaded you - will need to do so. For example, these commands load the - ng_ether module and attach the - output hook of a new source - node to orphans hook of the - bge0: ng_ether node.

-
-
kldload ng_ether
-ngctl mkpeer bge0: source orphans output
-
-

At this point the new node can be referred to as - “bge0:orphans”. The node can be given - its own name like this:

-

-
ngctl name bge0:orphans - src0
-

After which it can be referred to as - “src0:”.

-

Once created, packets can be sent to the node as raw binary data. - Each packet must be delivered in a separate netgraph message.

-

The following example uses a short Perl script to convert the hex - representation of an ICMP packet to binary and deliver it to the - source node's input hook via - nghook(8):

-
-
perl -pe 's/(..)[ \t\n]*/chr(hex($1))/ge' <<EOF | nghook src0: input
-ff ff ff ff ff ff 00 00 00 00 00 00 08 00 45 00
-00 54 cb 13 00 00 40 01 b9 87 c0 a8 2b 65 0a 00
-00 01 08 00 f8 d0 c9 76 00 00 45 37 01 73 00 01
-04 0a 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
-16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
-26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
-36 37
-EOF
-
-

To check that the node has queued these packets you can get the - node statistics:

-
-
ngctl msg bge0:orphans getstats
-Args:   { queueOctets=64 queueFrames=1 }
-
-

Send as many packets as required out the - output hook:

-

-
ngctl msg bge0:orphans start - 16
-

Either wait for them to be sent (periodically fetching stats if - desired) or send the stop message:

-

-
ngctl msg bge0:orphans - stop
-

Check the statistics (here we use - getclrstats to also clear the statistics):

-
-
ngctl msg bge0:orphans getclrstats
-Args:   { outOctets=1024 outFrames=16 queueOctets=64 queueFrames=1
-startTime={ tv_sec=1035305880 tv_usec=758036 } endTime={ tv_sec=1035305880
-tv_usec=759041 } elapsedTime={ tv_usec=1005 } }
-
-

The times are from struct timevals, the - tv_sec field is seconds since the Epoch and can be - converted into a date string via TCL's [clock format] or via the - date(1) command:

-
-
date -r 1035305880
-Tue Oct 22 12:58:00 EDT 2002
-
-
-
-

-

netgraph(4), ng_echo(4), - ng_hole(4), ng_tee(4), - ngctl(8), nghook(8)

-
-
-

-

The ng_source node type was implemented in - FreeBSD 4.8.

-
-
-

-

Dave Chapeskie

-
-
- - - - - -
January 18, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_split.4 4.html b/static/freebsd/man4/ng_split.4 4.html deleted file mode 100644 index e2e859da..00000000 --- a/static/freebsd/man4/ng_split.4 4.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
NG_SPLIT(4)Device Drivers ManualNG_SPLIT(4)
-
-
-

-

ng_split — - netgraph node to separate incoming and outgoing - flows

-
-
-

-

#include - <netgraph/ng_split.h>

-
-
-

-

The split node type is used to split a - bidirectional stream of packets into two separate unidirectional streams of - packets.

-
-
-

-

This node type supports the following three hooks:

-
-
in
-
Packets received on in are forwarded to - mixed.
-
out
-
Packets received on out will be discarded as - illegal.
-
mixed
-
Packets received on mixed are forwarded to - out.
-
-
-
-

-

This node type supports only the generic control messages.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ngctl(8)

-
-
-

-

The ng_split node type was implemented in - FreeBSD 3.5 but incorporated into - FreeBSD in FreeBSD 5.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org> -
- Vitaly V. Belekhov - <vitaly@riss-telecom.ru>

-
-
- - - - - -
February 19, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_tag.4 3.html b/static/freebsd/man4/ng_tag.4 3.html deleted file mode 100644 index e5661726..00000000 --- a/static/freebsd/man4/ng_tag.4 3.html +++ /dev/null @@ -1,260 +0,0 @@ - - - - - - -
NG_TAG(4)Device Drivers ManualNG_TAG(4)
-
-
-

-

ng_tag — mbuf tags - manipulating netgraph node type

-
-
-

-

#include - <netgraph/ng_tag.h>

-
-
-

-

The tag node type allows mbuf packet tags - (see mbuf_tags(9)) to be examined, stripped or applied to - data travelling through a Netgraph network. Mbuf tags are used in many parts - of the FreeBSD kernel network subsystem, including - the storage of VLAN tags as described in vlan(4), - Mandatory Access Control (MAC) labels as described in - mac(9), IPsec policy information as described in - ipsec(4), and packet filter tags used by - pf(4). One should also consider useful setting or checking - ipfw(8) tags, which are implemented as mbuf tags, too.

-

Each node allows an arbitrary number of connections to arbitrarily - named hooks. With each hook is associated a tag which will be searched in - the list of all tags attached to a packet incoming to this hook, a - destination hook for matching packets, a destination hook for non-matching - packets, a tag which will be appended to data leaving node through this - hook, and various statistics counters.

-

The list of incoming packet's tags is traversed to find a tag with - specified type and cookie - values. Upon match, if specified tag_len is non-zero, - tag_data of tag is checked to be identical to that - specified in the hook structure. Packets with matched tags are forwarded to - “match” destination hook, or forwarded to - “non-match” hook otherwise. Either or both destination hooks - can be an empty string, or may not exist, in which case the packet is - dropped.

-

Tag list of packets leaving the node is extended with a new tag - specified in outgoing hook structure (it is possible to avoid appending a - new tag to pass packet completely unchanged by specifying zero - type and cookie values in the - structure of the corresponding outgoing hook). Additionally, a tag can be - stripped from incoming packet after match if strip - flag is set. This can be used for simple tag removal or tag replacement, if - combined with tag addition on outgoing matching hook. Note that new tag is - appended unconditionally, without checking if such a tag is already present - in the list (it is up to user to check if this is a concern).

-

New hooks are initially configured to drop all incoming packets - (as all hook names are empty strings; zero values can be specified to - forward all packets to non-matching hook), and to forward all outgoing - packets without any tag appending.

-

Data payload of packets passing through the node is completely - unchanged, all operations can affect tag list only.

-
-
-

-

This node type supports any number of hooks having arbitrary - names. In order to allow internal optimizations, user should never try to - configure a hook with a structure pointing to hooks which do not exist yet. - The safe way is to create all hooks first, then begin to configure them.

-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (sethookin)
-
This command sets tag values which will be searched in the tag list of - incoming packets on a hook. The following structure must be supplied as an - argument: -
- 
struct ng_tag_hookin {
-  char		  thisHook[NG_HOOKSIZ];     /* name of hook */
-  char		  ifMatch[NG_HOOKSIZ];	    /* match dest hook */
-  char		  ifNotMatch[NG_HOOKSIZ];   /* !match dest hook */
-  uint8_t	  strip;		    /* strip tag if found */
-  uint32_t	  tag_cookie;		    /* ABI/Module ID */
-  uint16_t	  tag_id;		    /* tag ID */
-  uint16_t	  tag_len;		    /* length of data */
-  uint8_t	  tag_data[0];		    /* tag data */
-};
-
-

The hook to be updated is specified in - thisHook. Data bytes of tag corresponding to - specified tag_id (type) and - tag_cookie are placed in the - tag_data array; there must be - tag_len of them. Matching and non-matching - incoming packets are delivered out the hooks named - ifMatch and ifNotMatch, - respectively. If strip flag is non-zero, then - found tag is deleted from list of packet tags.

-
-
- (gethookin)
-
This command takes an ASCII string argument, the hook name, and returns - the corresponding struct ng_tag_hookin as shown - above.
-
- (sethookout)
-
This command sets tags values which will be applied to outgoing packets. - The following structure must be supplied as an argument: -
- 
struct ng_tag_hookout {
-  char		  thisHook[NG_HOOKSIZ];     /* name of hook */
-  uint32_t	  tag_cookie;		    /* ABI/Module ID */
-  uint16_t	  tag_id;		    /* tag ID */
-  uint16_t	  tag_len;		    /* length of data */
-  uint8_t	  tag_data[0];		    /* tag data */
-};
-
-

The hook to be updated is specified in - thisHook. Other variables mean basically the same - as in struct ng_tag_hookin shown above, except - used for setting values in a new tag.

-
-
- (gethookout)
-
This command takes an ASCII string argument, the hook name, and returns - the corresponding struct ng_tag_hookout as shown - above.
-
- (getstats)
-
This command takes an ASCII string argument, the hook name, and returns - the statistics associated with the hook as a struct - ng_tag_hookstat.
-
- (clrstats)
-
This command takes an ASCII string argument, the hook name, and clears the - statistics associated with the hook.
-
- (getclrstats)
-
This command is identical to NGM_TAG_GET_STATS, - except that the statistics are also atomically cleared.
-
-

: - statistics counters as well as three statistics messages above work only if - code was compiled with the NG_TAG_DEBUG option. The - reason for this is that statistics is rarely used in practice, but still - consumes CPU cycles for every packet. Moreover, it is even not accurate on - SMP systems due to lack of synchronization between threads, as this is very - expensive.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

It is possible to do a simple L7 filtering by using - ipfw(8) tags in conjunction with - ng_bpf(4) traffic analyzer. Example below explains how to - filter DirectConnect P2P network data traffic, which cannot be done by usual - means as it uses random ports. It is known that such data connection always - contains a TCP packet with 6-byte payload string "$Send|". So - ipfw's netgraph action will be used to divert all - TCP packets to an ng_bpf(4) node which will check for the - specified string and return non-matching packets to - ipfw(8). Matching packets are passed to - ng_tag node, which will set a tag and pass them back - to ng_bpf(4) node on a hook programmed to accept all - packets and pass them back to ipfw(8). A script provided - in ng_bpf(4) manual page will be used for programming - node. Note that packets diverted from ipfw(8) to Netgraph - have no link-level header, so offsets in tcpdump(1) - expressions must be altered accordingly. Thus, there will be expression - “ether[40:2]=0x244c && - ether[42:4]=0x6f636b20” on incoming hook and empty expression - to match all packets from ng_tag.

-

So, this is ngctl(8) script for nodes creating - and naming for easier access:

-
-
/usr/sbin/ngctl -f- <<-SEQ
-	mkpeer ipfw: bpf 41 ipfw
-	name ipfw:41 dcbpf
-	mkpeer dcbpf: tag matched th1
-	name dcbpf:matched ngdc
-SEQ
-
-

Now “ngdc” node (which is of - type ng_tag) must be programmed to echo all packets - received on the “th1” hook back, with - the ipfw(8) tag 412 attached. - MTAG_IPFW value for tag_cookie - was taken from file - <netinet/ip_fw.h> and value - for tag_id is tag number (412), with zero tag - length:

-
-
ngctl msg ngdc: sethookin { thisHook=\"th1\" ifNotMatch=\"th1\" }
-ngctl msg ngdc: sethookout { thisHook=\"th1\" \
-  tag_cookie=1148380143 \
-  tag_id=412 }
-
-

Do not forget to program ng_bpf(4) - “ipfw” hook with the above expression - (see ng_bpf(4) for script doing this) and - “matched” hook with an empty - expression:

-
-
ngctl msg dcbpf: setprogram { thisHook=\"matched\" ifMatch=\"ipfw\" \
-  bpf_prog_len=1 bpf_prog=[ { code=6 k=8192 } ] }
-
-

After finishing with netgraph(4) nodes, - ipfw(8) rules must be added to enable packet flow:

-
-
ipfw add 100 netgraph 41 tcp from any to any iplen 46
-ipfw add 110 reset tcp from any to any tagged 412
-
-

Note: one should ensure that packets are returned to ipfw after - processing inside netgraph(4), by setting appropriate - sysctl(8) variable:

-
-
sysctl net.inet.ip.fw.one_pass=0
-
-
-
-

-

netgraph(4), ng_bpf(4), - ng_ipfw(4), ipfw(8), - ngctl(8), mbuf_tags(9)

-
-
-

-

The ng_tag node type was implemented in - FreeBSD 6.2.

-
-
-

-

Vadim Goncharov - <vadimnuclight@tpu.ru>

-
-
-

-

For manipulating any tags with data payload (that is, all tags - with non-zero tag_len) one should care about - non-portable machine-dependent representation of tags on the low level as - byte stream. Perhaps this should be done by another program rather than - manually.

-
-
- - - - - -
June 10, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_tcpmss.4 3.html b/static/freebsd/man4/ng_tcpmss.4 3.html deleted file mode 100644 index 60cfadfa..00000000 --- a/static/freebsd/man4/ng_tcpmss.4 3.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - -
NG_TCPMSS(4)Device Drivers ManualNG_TCPMSS(4)
-
-
-

-

ng_tcpmss — - netgraph node to adjust TCP MSS option

-
-
-

-

#include - <netgraph.h> -
- #include - <netgraph/ng_tcpmss.h>

-
-
-

-

The tcpmss node type is designed to alter - the Maximum Segment Size option of TCP packets. This node accepts an - arbitrary number of hooks. Initially a new hook is considered unconfigured. - The NG_TCPMSS_CONFIG control message is used to - configure a hook.

-
-
-

-

This node type supports the generic control messages, plus the - following.

-
-
- (config)
-
This control message configures node to do given MSS adjusting on a - particular hook. It requires the struct - ng_tcpmss_config to be supplied as an argument: -
- 
struct ng_tcpmss_config {
-	char		inHook[NG_HOOKSIZ];
-	char		outHook[NG_HOOKSIZ];
-	uint16_t	maxMSS;
-}
-
-

This means: packets received on inHook - would be checked for TCP MSS option and the latter would be reduced down - to maxMSS if it exceeds - maxMSS. After that, packets would be sent to hook - outHook.

-
-
- (getstats)
-
This control message obtains statistics for a given hook. The statistics - are returned in struct ng_tcpmss_hookstat: -
- 
struct ng_tcpmss_hookstat {
-	uint64_t	Octets;		/* total bytes */
-	uint64_t	Packets;	/* total packets */
-	uint16_t	maxMSS;		/* maximum MSS */
-	uint64_t	SYNPkts;	/* TCP SYN packets */
-	uint64_t	FixedPkts;	/* changed packets */
-};
-
-
-
- (clrstats)
-
This control message clears statistics for a given hook.
-
- (getclrstats)
-
This control message obtains and clears statistics for a given hook.
-
-
-
-

-

In the following example, packets are injected into the - tcpmss node using the ng_ipfw(4) - node.

-
-
# Create tcpmss node and connect it to ng_ipfw node
-ngctl mkpeer ipfw: tcpmss 100 qqq
-
-# Adjust MSS to 1452
-ngctl msg ipfw:100 config '{ inHook="qqq" outHook="qqq" maxMSS=1452 }'
-
-# Divert traffic into tcpmss node
-ipfw add 300 netgraph 100 tcp from any to any tcpflags syn out via fxp0
-
-# Let packets continue with ipfw after being hacked
-sysctl net.inet.ip.fw.one_pass=0
-
-
-
-

-

This node shuts down upon receipt of an - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_ipfw(4)

-
-
-

-

The ng_tcpmss node type was implemented in - FreeBSD 6.0.

-
-
-

-

Alexey Popov - <lollypop@flexuser.ru> -
- Gleb Smirnoff - <glebius@FreeBSD.org>

-
-
-

-

When running on SMP, system statistics may be broken.

-
-
- - - - - -
June 9, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_tee.4 3.html b/static/freebsd/man4/ng_tee.4 3.html deleted file mode 100644 index 69fb71a9..00000000 --- a/static/freebsd/man4/ng_tee.4 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
NG_TEE(4)Device Drivers ManualNG_TEE(4)
-
-
-

-

ng_tee — netgraph - ``tee'' node type

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/ng_tee.h>

-
-
-

-

The tee node type has a purpose similar to - the tee(1) command. Tee nodes are - useful for debugging or “snooping” on a connection between two - netgraph nodes. Tee nodes have four hooks, - right, left, - right2left, and left2right. - All data received on right is sent unmodified to - hooks - left and right2left. - Similarly, all data received on left is sent - unmodified to both right and - left2right.

-

Packets may also be received on right2left - and left2right; if so, they are forwarded unchanged - out hooks right and left, - respectively.

-
-
-

-

This node type supports the following hooks:

-
- -
The connection to the node on the right.
-
left
-
The connection to the node on the left.
-
right2left
-
Tap for right to left traffic.
-
left2right
-
Tap for left to right traffic.
-
-
-
-

-

This node type supports the generic control messages, plus the - following.

-
-
- (getstats)
-
Get statistics, returned as a struct - ng_tee_stats.
-
- (clrstats)
-
Clear statistics.
-
-
-
-

-

This node shuts down upon receipt of an - NGM_SHUTDOWN control message, or when all hooks have - been disconnected. If both right and - left hooks are present, node removes itself from the - chain gently, connecting right and - left together.

-
-
-

-

tee(1), netgraph(4), - ngctl(8)

-
-
-

-

The ng_tee node type was implemented in - FreeBSD 4.0.

-
-
-

-

Julian Elischer - <julian@FreeBSD.org>

-
-
- - - - - -
May 28, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_tty.4 3.html b/static/freebsd/man4/ng_tty.4 3.html deleted file mode 100644 index 4e8294cc..00000000 --- a/static/freebsd/man4/ng_tty.4 3.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - -
NG_TTY(4)Device Drivers ManualNG_TTY(4)
-
-
-

-

ng_tty — netgraph - node type that is also a TTY hook

-
-
-

-

#include - <sys/types.h> -
- #include <sys/ttycom.h> -
- #include - <netgraph/ng_tty.h>

-
-
-

-

The tty node type is both a netgraph node - type and a TTY hook.

-

The node has a single hook called hook. - Incoming bytes received on the tty device are sent out on this hook, and - frames received on hook are transmitted out on the - tty device. No modification to the data is performed in either direction. - While the hook is installed on a tty, the normal read and write operations - are unavailable, returning EIO.

-

Incoming data is delivered directly to ng_tty via the tty bypass - hook as a buffer pointer and length, this is converted to a mbuf and passed - to the peer.

-

The node supports an optional “hot character”. If - the driver can not deliver data directly to the tty bypass hook then each - character is input one at a time. If set to non-zero and bypass mode is - unavailable, incoming data from the tty device is queued until this - character is seen. This avoids sending lots of mbufs containing a small - number of bytes, but introduces potentially infinite latency. The default - hot character is 0x7e, consistent with hook being - connected to a ng_async(4) type node. The hot character - has no effect on the transmission of data.

-
-
-

-

This node type supports the following hooks:

-
-
hook
-
tty(4) serial data contained in - mbuf structures, with arbitrary inter-frame - boundaries.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
-
This command takes an integer argument and sets the hot character from the - lower 8 bits. A hot character of zero disables queueing, so that all - received data is forwarded immediately.
-
-
Returns an integer containing the current hot character in the lower eight - bits.
-
-
This command takes integer process ID and file descriptor of open tty and - registers the tty hooks.
-
-
-
-

-

This node shuts down when the corresponding device is closed.

-
-
-

-

ioctl(2), netgraph(4), - ng_async(4), tty(4), - ngctl(8)

-
-
-

-

The ng_tty node type was implemented in - FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org> -
- Andrew Thompson - <thompsa@FreeBSD.org>

-
-
-

-

The serial driver code also has a notion of a “hot - character”. Unfortunately, this value is statically defined in terms - of the line discipline and cannot be changed. Therefore, if a hot character - other than 0x7e (the default) is set for the ng_tty - node, the node has no way to convey this information to the serial driver, - and sub-optimal performance may result.

-
-
- - - - - -
December 25, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_ubt.4 3.html b/static/freebsd/man4/ng_ubt.4 3.html deleted file mode 100644 index a0f58215..00000000 --- a/static/freebsd/man4/ng_ubt.4 3.html +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - -
NG_UBT(4)Device Drivers ManualNG_UBT(4)
-
-
-

-

ng_ubt — Netgraph - node type that is also a driver for Bluetooth USB devices

-
-
-

-

#include - <sys/types.h> -
- #include - <netgraph/bluetooth/include/ng_ubt.h>

-
-
-

-

The ubt node type is both a persistent - Netgraph node type and a driver for Bluetooth USB devices. It implements a - Bluetooth USB transport layer as per chapter H2 of the Bluetooth - Specification Book v1.1. A new node is created when a supported USB device - is plugged in.

-

The node has a single hook called hook. - Incoming bytes received on the device are re-assembled into HCI frames - (according to the length). Full HCI frames are sent out on the hook. The - node will add a HCI frame indicator if the device did not send it. HCI - frames received on hook are transmitted out. The - node will drop the HCI frame indicator unless the device requires it to be - present.

-
-
-

-

The ng_ubt driver supports all Bluetooth - USB devices that conform with the Bluetooth specification v1.1, - including:

-

-
    -
  • 3Com 3CREB96
    • -
  • AIPTEK BR0R02
    • -
  • EPoX BT-DG02
    • -
  • Mitsumi Bluetooth USB adapter
    • -
  • MSI MS-6967
    • -
  • TDK Bluetooth USB adapter
    • -
  • Broadcom Bluetooth USB adapter
    • -
-
-
-

-

This node type supports the following hooks:

-
-
hook
-
single HCI frame contained in a single mbuf - structure.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (get_debug)
-
Returns an integer containing the current debug level for the node.
-
- (set_debug)
-
This command takes an integer argument and sets the current debug level - for the node.
-
- (get_qlen)
-
This command takes a parameter that specifies the queue number and returns - the current maximal length of the queue for the node.
-
- (set_qlen)
-
This command takes two parameters that specify the queue number and the - maximum length of the queue and sets the maximal length of the queue for - the node.
-
- (get_stat)
-
Returns various statistic information for the node, such as: number of - bytes (frames) sent, number of bytes (frames) received and number of input - (output) errors.
-
- (reset_stat)
-
Reset all statistic counters to zero.
-
-
-
-

-

This node shuts down when the corresponding USB device is - un-plugged.

-
-
-

-

netgraph(4), ugen(4), - usb(4), ngctl(8)

-
-
-

-

The ubt node type was implemented in - FreeBSD 5.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

Isochronous USB transfers are broken. This means that the USB - device will not be able to transfer SCO data (voice). USB interrupt - transfers are implemented as bulk-in transfers (not really a bug).

-
-
- - - - - -
December 26, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_vjc.4 3.html b/static/freebsd/man4/ng_vjc.4 3.html deleted file mode 100644 index b5fe1671..00000000 --- a/static/freebsd/man4/ng_vjc.4 3.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
NG_VJC(4)Device Drivers ManualNG_VJC(4)
-
-
-

-

ng_vjc — Van - Jacobson compression netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include <netinet/in.h> -
- #include <netinet/in_systm.h> -
- #include <netinet/ip.h> -
- #include <net/slcompress.h> -
- #include - <netgraph/ng_vjc.h>

-
-
-

-

The vjc node type performs Van Jacobson - compression, which is used over PPP, SLIP, and other point-to-point IP - connections to compress TCP packet headers. The ip - hook represents the uncompressed side of the node, while the - vjcomp, vjuncomp, and - vjip hooks represent the compressed side of the - node. Packets received on the ip will be compressed - or passed through as appropriate. Packets received on the other three hooks - will be uncompressed as appropriate. This node also supports “always - pass through” mode in either direction.

-

Van Jacobson compression only applies to TCP packets. Only - “normal” (i.e., common case) TCP packets are actually - compressed. These are output on the vjcomp hook. - Other TCP packets are run through the state machine but not compressed; - these appear on the vjuncomp hook. Other non-TCP IP - packets are forwarded unchanged to vjip.

-

When connecting to a ng_ppp(4) node, the - ip, vjuncomp, - vjcomp, and vjip hooks - should be connected to the ng_ppp(4) node's - vjc_ip, vjc_vjcomp, - vjc_vjuncomp, and vjc_ip - hooks, respectively.

-
-
-

-

This node type supports the following hooks:

-
-
ip
-
Upstream (uncompressed) IP packets.
-
vjcomp
-
Downstream compressed TCP packets.
-
vjuncomp
-
Downstream uncompressed TCP packets.
-
vjip
-
Downstream uncompressed IP packets.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (setconfig)
-
This command resets the compression state and configures it according to - the supplied struct ngm_vjc_config argument. This - structure contains the following fields: -
- 
struct ngm_vjc_config {
-  u_char   enableComp;    /* Enable compression */
-  u_char   enableDecomp;  /* Enable decompression */
-  u_char   maxChannel;    /* Number of outgoing channels - 1 */
-  u_char   compressCID;   /* OK to compress outgoing CID's */
-};
-
-

When enableComp is set to zero, all - packets received on the ip hook are forwarded - unchanged out the vjip hook. Similarly, when - enableDecomp is set to zero, all packets - received on the vjip hook are forwarded - unchanged out the ip hook, and packets are not - accepted on the vjcomp and - vjuncomp hooks. When a node is first created, - both compression and decompression are disabled and the node is - therefore operating in bi-directional “pass through” - mode.

-

When enabling compression, maxChannel - should be set to the number of outgoing compression channels minus one, - and is a value between 3 and 15, inclusive. The - compressCID field indicates whether it is OK to - compress the CID header field for outgoing compressed TCP packets. This - value should be zero unless either (a) it is not possible for an - outgoing frame to be lost, or (b) lost frames can be reliably detected - and immediately reported to the peer's decompression engine (see - NGM_VJC_RECV_ERROR below).

-
-
- (getstate)
-
This command returns the node's current state described by the - struct slcompress structure, which is defined in - <net/slcompress.h>.
-
- (clrstats)
-
Clears the node statistics counters. Statistics are also cleared whenever - the enableComp or - enableDecomp fields are changed from zero to one - by a NGM_VJC_SET_CONFIG control message.
-
- (recverror)
-
When the peer has CID header field compression enabled, this message must - be sent to the local vjc node immediately after - detecting that a received frame has been lost, due to a bad checksum or - for any other reason. Failing to do this can result in corrupted TCP - stream data.
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_iface(4), - ng_ppp(4), ngctl(8)

-

V. Jacobson, - Compressing TCP/IP Headers, RFC - 1144.

-

G. McGregor, - The PPP Internet Control Protocol (IPCP), - RFC 1332.

-
-
-

-

The ng_vjc node type was implemented in - FreeBSD 4.0.

-
-
-

-

Archie Cobbs - <archie@FreeBSD.org>

-
-
-

-

As the initialization routine in the kernel implementation of Van - Jacobson compression initializes both compression and decompression at once, - this node does not allow compression and decompression to be enabled in - separate operations. In order to enable one when the other is already - enabled, first both must be disabled, then both enabled. This of course - resets the node state. This restriction may be lifted in a later - version.

-

When built as a loadable kernel module, this module includes the - file net/slcompress.c. Although loading the module - should fail if net/slcompress.c already exists in - the kernel, currently it does not, and the duplicate copies of the file do - not interfere. However, this may change in the future.

-
-
- - - - - -
January 19, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_vlan.4 3.html b/static/freebsd/man4/ng_vlan.4 3.html deleted file mode 100644 index df328b81..00000000 --- a/static/freebsd/man4/ng_vlan.4 3.html +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - -
NG_VLAN(4)Device Drivers ManualNG_VLAN(4)
-
-
-

-

ng_vlan — IEEE - 802.1Q VLAN tagging netgraph node type

-
-
-

-

#include - <sys/types.h> -
- #include <netgraph.h> -
- #include - <netgraph/ng_vlan.h>

-
-
-

-

The vlan node type multiplexes frames - tagged according to the IEEE 802.1Q standard between different hooks.

-

Each node has two special hooks, downstream - and nomatch, and an arbitrary number of - “vlan” hooks, each associated with a particular VLAN tag.

-

An ETHERTYPE_VLAN frame received on the - downstream hook with a tag that the node has been - configured to filter is sent out the corresponding “vlan” - hook. If it does not match any of the configured tags, or is not of a type - ETHERTYPE_VLAN, it is sent out the - nomatch hook. If the nomatch - hook is not connected, the packet is dropped.

-

An Ethernet frame received on the nomatch - hook is passed unmodified to the downstream hook.

-

An Ethernet frame received on any of the “vlan” - hooks is tagged accordingly and sent out the - downstream hook.

-
-
-

-

This node type supports the following hooks:

-
-
downstream
-
Typically this hook would be connected to a ng_ether(4) - node, using the lower hook.
-
nomatch
-
Typically this hook would also be connected to an - ng_ether(4) type node using the - upper hook.
-
⟨⟩
-
Any other hook name will be accepted and should later be associated with a - particular tag. Typically this hook would be attached to an - ng_eiface(4) type node using the - ether hook.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (addfilter)
-
Associates a hook with the tag.
-
- (delfilter)
-
Disassociates a hook from the tag.
-
- (gettable)
-
Returns a table of all hook/tag associations.
-
-
-
-

-
-
#!/bin/sh
-
-ETHER_IF=rl0
-
-ngctl -f- <<EOF
-shutdown ${ETHER_IF}:
-mkpeer ${ETHER_IF}: vlan lower downstream
-name ${ETHER_IF}:lower vlan
-connect ${ETHER_IF}: vlan: upper nomatch
-EOF
-
-ngctl mkpeer vlan: eiface vlan123 ether
-ngctl msg vlan: addfilter '{ vlan=123 hook="vlan123" }'
-
-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_eiface(4), - ng_ether(4), ngctl(8), - nghook(8)

-
-
-

-

The ng_vlan node type appeared in - FreeBSD 4.10.

-
-
-

-

Ruslan Ermilov - <ru@FreeBSD.org>

-
-
- - - - - -
March 1, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/ng_vlan_rotate.4 3.html b/static/freebsd/man4/ng_vlan_rotate.4 3.html deleted file mode 100644 index fcf4fb79..00000000 --- a/static/freebsd/man4/ng_vlan_rotate.4 3.html +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - -
NG_VLAN_ROTATE(4)Device Drivers ManualNG_VLAN_ROTATE(4)
-
-
-

-

ng_vlan_rotate — - IEEE 802.1ad VLAN manipulation netgraph node - type

-
-
-

-

#include - <sys/types.h> -
- #include <netgraph.h> -
- #include - <netgraph/ng_vlan_rotate.h>

-
-
-

-

The ng_vlan_rotate node type manipulates - the order of VLAN tags of frames tagged according to the IEEE 802.1ad (an - extension of IEEE 802.1Q) standard between different hooks.

-

Each node has four special hooks, original, - ordered, excessive, and - incomplete.

-

A frame tagged with an arbitrary number of - ETHERTYPE_VLAN, - ETHERTYPE_QINQ, and 0x9100 - tags received on the original hook will be rearranged - to a new order of those tags and is sent out the “ordered” - hook. After successful processing the histogram - counter for the observed stack size increments.

-

If it contains fewer VLANs in the stack than the configured - min limit, the frame is sent out to the - incomplete hook and the - incomplete counter increments.

-

If there are more VLANs in the stack than the configured - max limit, the frame is sent out to the - excessive hook and the excessive - counter increments.

-

If the destination hook is not connected, the frame is dropped and - the drops counter increments.

-

For Ethernet frames received on the ordered - hook, the transformation is reversed and is passed to the - original hook. Please note that this process is - identical to the one described above, besides the ordered/original hooks are - swapped and the transformation is reversed.

-

An Ethernet frame received on the incomplete - or excessive hook is forwarded to the - original hook without any modification.

-

This node supports only one operation at the moment: Rotation of - the VLANs in the stack. Setting the configuration parameter - rot to a positive value, the stack will roll up by - this amount. Negative values will roll down. A typical scenario is setting - the value to 1 in order to bring the innermost VLAN tag to the outmost - level. Rotation includes the VLAN id, the ether type, and the QOS parameters - pcp and cfi. Typical QOS handling refers to the outmost setting, so be - careful to keep your QOS intact.

-
-
-

-

This node type supports the following hooks:

-
-
original
-
Typically this hook would be connected to a ng_ether(4) - node, using the lower hook connected to a carrier - network.
-
ordered
-
Typically this hook would be connected to a ng_vlan(4) - type node using the downstream hook in order to - separate services.
-
excessive
-
see below.
-
incomplete
-
Typically those hooks would be attached to a - ng_eiface(4) type node using the - ether hook for anomaly monitoring purposes.
-
-
-
-

-

This node type supports the generic control messages, plus the - following:

-
-
- (getconf)
-
Read the current configuration.
-
- (setconf)
-
Set the current configuration.
-
- (getstat)
-
Read the current statistics.
-
- (clrstat)
-
Zeroize the statistics.
-
- (getclrstat)
-
Read the current statistics and zeroize it in one step.
-
-
-
-

-

The first example demonstrates how to rotate double or triple - tagged frames so that the innermost C-VLAN can be used as service - discriminator. The single or double tagged frames (C-VLAN removed) are sent - out to an interface pointing to different infrastructure.

-
-
#!/bin/sh
-
-BNG_IF=ixl3
-VOIP_IF=bge2
-
-ngctl -f- <<EOF
-mkpeer ${BNG_IF}: vlan_rotate lower original
-name ${BNG_IF}:lower rotate
-msg rotate: setconf { min=2 max=3 rot=1 }
-mkpeer rotate: vlan ordered downstream
-name rotate:ordered services
-connect services: ${VOIP_IF} voip lower
-msg services: addfilter { vlan=123 hook="voip" }
-EOF
-
-

Now inject the following sample frame on the - BNG_IF interface:

-
-
00:00:00:00:01:01 > 00:01:02:03:04:05,
- ethertype 802.1Q-9100 (0x9100), length 110: vlan 2, p 1,
- ethertype 802.1Q-QinQ, vlan 101, p 0,
- ethertype 802.1Q, vlan 123, p 7,
- ethertype IPv4, (tos 0x0, ttl 64, id 15994, offset 0, flags [none],
-  proto ICMP (1), length 84) 192.168.140.101 > 192.168.140.1:
-  ICMP echo request, id 40234, seq 0, length 64
-
-

The frame ejected on the ordered hook will - look like this:

-
-
00:00:00:00:01:01 > 00:01:02:03:04:05,
- ethertype 802.1Q (0x8100), length 110: vlan 123, p 7,
- ethertype 802.1Q-9100, vlan 2, p 1,
- ethertype 802.1Q-QinQ, vlan 101, p 0,
- ethertype IPv4, (tos 0x0, ttl 64, id 15994, offset 0, flags [none],
-  proto ICMP (1), length 84) 192.168.140.101 > 192.168.140.1:
-  ICMP echo request, id 40234, seq 0, length 64
-
-

Hence, the frame pushed out to the VOIP_IF - will have this form:

-
-
00:00:00:00:01:01 > 00:01:02:03:04:05,
- ethertype 802.1Q-9100, vlan 2, p 1,
- ethertype 802.1Q-QinQ, vlan 101, p 0,
- ethertype IPv4, (tos 0x0, ttl 64, id 15994, offset 0, flags [none],
-  proto ICMP (1), length 84) 192.168.140.101 > 192.168.140.1:
-  ICMP echo request, id 40234, seq 0, length 64
-
-

The second example distinguishes between double tagged and single - tagged frames.

-
-
#!/bin/sh
-
-IN_IF=bge1
-
-ngctl -f- <<EOF
-mkpeer ${IN_IF}: vlan_rotate lower original
-name ${IN_IF}:lower separate
-msg separate: setconf { min=1 max=1 rot=0 }
-mkpeer separate: eiface incomplete ether
-name separate:incomplete untagged
-mkpeer separate: eiface ordered ether
-name separate:ordered tagged
-EOF
-
-

Setting the rot parameter to zero (or - omitting it) does not change the order of the tags within the frame. Frames - with more VLAN tags are dropped.

-
-
-

-

This node shuts down upon receipt of a - NGM_SHUTDOWN control message, or when all hooks have - been disconnected.

-
-
-

-

netgraph(4), ng_eiface(4), - ng_ether(4), ng_vlan(4), - ngctl(8)

-
-
-

-

Lutz Donnerhacke - <lutz@donnerhacke.de>

-
-
- - - - - -
January 26, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/nge.4 3.html b/static/freebsd/man4/nge.4 3.html deleted file mode 100644 index e9858a29..00000000 --- a/static/freebsd/man4/nge.4 3.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
NGE(4)Device Drivers ManualNGE(4)
-
-
-

-

nge — National - Semiconductor PCI Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device nge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_nge_load="YES"
-
-
-
-

-

The nge driver provides support for - various NICs based on the National Semiconductor DP83820 and DP83821 Gigabit - Ethernet controller chips.

-

The DP83820 supports TBI (ten bit interface) and GMII - transceivers, which means it can be used with either copper or 1000baseX - fiber applications. The DP83820 supports TCP/IP checksum offload and VLAN - tagging/insertion as well as a 2048-bit multicast hash filter and up to 4 - pattern match buffers.

-

Most cards also use the DP83861 10/100/1000 copper gigabit - transceiver chip, which supports autonegotiation of 10, 100 and 1000Mbps - modes in full or half duplex.

-

The DP83820 and DP83821 also support jumbo frames, which can be - configured via the interface MTU setting. Selecting an MTU larger than 1500 - bytes with the ifconfig(8) utility configures the adapter - to receive and transmit jumbo frames. Using jumbo frames can greatly improve - performance for certain tasks, such as file transfers and data - streaming.

-

The nge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX operation over twisted pair. - full-duplex and - half-duplex modes are supported.
-
-
Set 1000Mbps (Gigabit Ethernet) operation. Both - full-duplex and - half-duplex modes are supported.
-
-

The nge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The nge driver supports National - Semiconductor DP83820 and DP83821 based Gigabit Ethernet adapters - including:

-

-
    -
  • Addtron AEG320T
    • -
  • Ark PC SOHO-GA2500T (32-bit PCI) and SOHO-GA2000T (64-bit PCI)
    • -
  • Asante FriendlyNet GigaNIX 1000TA and 1000TPC
    • -
  • D-Link DGE-500T
    • -
  • Linksys EG1032, revision 1
    • -
  • Netgear GA621
    • -
  • Netgear GA622T
    • -
  • SMC EZ Card 1000 (SMC9462TX)
    • -
  • Surecom Technology EP-320G-TX
    • -
  • Trendware TEG-PCITX (32-bit PCI) and TEG-PCITX2 (64-bit PCI)
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.nge.%d.int_holdoff
-
Maximum amount of time to delay interrupt processing in units of 100us. - The accepted range is 0 to 255, the default is 1(100us). Value 0 - completely disables the interrupt moderation. The interface has to be - brought down and up again before a change takes effect.
-
-
-
-

-
-
nge%d: couldn't map memory
-
A fatal initialization error has occurred.
-
nge%d: couldn't map ports
-
A fatal initialization error has occurred.
-
nge%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
nge%d: no memory for softc struct!
-
The driver failed to allocate memory for per-device instance information - during initialization.
-
nge%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
nge%d: no memory for jumbo buffers!
-
The driver failed to allocate memory for jumbo frames during - initialization.
-
nge%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-

National Semiconductor DP83820 - datasheet.

-

National Semiconductor DP83861 - datasheet.

-
-
-

-

The nge device driver first appeared in - FreeBSD 4.4.

-
-
-

-

The nge driver was written by - Bill Paul - <wpaul@bsdi.com>.

-
-
- - - - - -
November 23, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/nlsysevent.4 3.html b/static/freebsd/man4/nlsysevent.4 3.html deleted file mode 100644 index 02fa82ae..00000000 --- a/static/freebsd/man4/nlsysevent.4 3.html +++ /dev/null @@ -1,184 +0,0 @@ - - - - - - -
NLSYSEVENT(4)Device Drivers ManualNLSYSEVENT(4)
-
-
-

-

nlsysevent — - Netlink-based kernel event notification module

-
-
-

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
nlsysevent_load="YES"
-
-

Alternatively, to load the module at runtime:

-
-
kldload nlsysevent
-
-
-
-

-

The nlsysevent kernel module provides a - netlink(4) Generic Netlink interface for receiving kernel - device events. It hooks into the devctl(4) notification - system and re-publishes all kernel events as Generic Netlink multicast - messages under the NETLINK_GENERIC protocol - family.

-

This provides an alternative to reading events from - /dev/devctl (used by devd(8)), - with the advantage that multiple consumers can subscribe to events - simultaneously, and consumers can selectively subscribe to specific event - groups.

-
- -

The module registers a Generic Netlink family named - “nlsysevent”. The dynamically-assigned - family identifier can be resolved using the standard - CTRL_CMD_GETFAMILY request as described in - genetlink(4).

-
-
-

-

The following command is defined:

-
-
-
Sent when a kernel event occurs. This message is never solicited by - userland; it is only delivered to sockets that have subscribed to one or - more multicast groups.
-
-
-
-

-

Each NLSE_CMD_NEWEVENT message contains - the following TLV attributes:

-
-
-
(string) The system name that generated the event (e.g., - “ACPI, - “IFNET, - “USB”””).
-
-
(string) The subsystem name within the system.
-
-
(string) The type of the event.
-
-
(string) Optional extra data associated with the event. This attribute may - be absent if no extra data was provided.
-
-
-
-

-

The module creates one multicast group per system name. The - following groups are pre-registered when the module is loaded:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Additional groups are created dynamically as new system names - appear in kernel events, up to a maximum of 64 groups.

-

The group identifier for a given system name can be resolved via - CTRL_CMD_GETFAMILY and then subscribed to using the - NETLINK_ADD_MEMBERSHIP socket option.

-
-
-
-

-

The genl(1) utility can be used to monitor - events:

-
-
genl monitor nlsysevent
-
-
-
-

-

genl(1), snl(3), - devctl(4), genetlink(4), - netlink(4), devd(8)

-
-
-

-

The nlsysevent module first appeared in - FreeBSD 15.0.

-
-
-

-

The nlsysevent kernel module and this - manual page were written by Baptiste Daroussin - <bapt@FreeBSD.org>.

-
-
- - - - - -
April 9, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/nmdm.4 4.html b/static/freebsd/man4/nmdm.4 4.html deleted file mode 100644 index 05cd54dd..00000000 --- a/static/freebsd/man4/nmdm.4 4.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
NMDM(4)Device Drivers ManualNMDM(4)
-
-
-

-

nmdm — nullmodem - terminal driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device nmdm
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
nmdm_load="YES"
-
-
-
-

-

The nmdm driver provides two - tty(4) devices connected by a virtual “null - modem” cable.

-

If either of the two tty devices have the - CDSR_OFLOW bit (“stty - dsrflow”) set in their line discipline, the - nmdm device will emulate the speed configured in the - termios(4) settings. The speed emulation works - independently in the two directions, controlled by the slower end's termios - settings (c_ispeed, c_ospeed, - CS5 ... CS8, CSTOPB and - PARENB).

-
-
-

-
-
/dev/nmdmN[AB]
-
nullmodem device nodes. Where the A node has a - matching B node.
-
-

The nmdm driver implements - “on-demand device creation” so simply accessing a given - instance in /dev will create it.

-
-
-

-

None.

-
-
-

-

stty(1), termios(4), - tty(4), ttys(5)

-
-
-

-

The nmdm driver first appeared in - FreeBSD 4.4.

-
-
- - - - - -
July 11, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ntb.4 3.html b/static/freebsd/man4/ntb.4 3.html deleted file mode 100644 index c6bbe407..00000000 --- a/static/freebsd/man4/ntb.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
NTB(4)Device Drivers ManualNTB(4)
-
-
-

-

ntb — - Non-Transparent Bridge subsystem

-
-
-

-

To compile it into your kernel, place the following lines in your - kernel configuration file:

-
device ntb
-

Or, to load it as a module at boot, place the following line in - loader.conf(5):

-
-
ntb_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hw.ntb.debug_level
-
Driver debug level. The default value is 0, higher means more - verbose.
-
hint.ntb_hw.X.config
-
Configures a set of NTB functions, separated by commas, and their resource - allocation. Each function can be configured as: - "[<name>][:<mw>[:<spad>[:<db>]]]", - where: name is a name of the driver to attach (empty - means any), mw is a number of memory windows to - allocate (empty means all available), spad is a - number of scratchpad registers to allocate (empty means all available), - db is a number of doorbells to allocate (empty means - all available). The default configuration is empty string, which means - single function with all available resources, allowing any driver to - attach.
-
-
-
-

-

Non-Transparent Bridges connect two computer systems with PCIe - link(s), providing each of them limited access to others memory space, - scratchpad registers and interrupts. The ntb - subsystem uses those resources provided in generic way by hardware drivers - and splits them between several functions, according to specified - configuration.

-
-
-

-

if_ntb(4), ntb_hw_amd(4), - ntb_hw_intel(4), ntb_hw_plx(4), - ntb_transport(4)

-
-
-

-

The ntb subsystem was developed by Intel - and originally written by Carl Delsey - <carl@FreeBSD.org>. - Later improvements were done by Conrad E. Meyer - <cem@FreeBSD.org> and - Alexander Motin - <mav@FreeBSD.org>.

-
-
- - - - - -
August 29, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ntb_hw_amd.4 3.html b/static/freebsd/man4/ntb_hw_amd.4 3.html deleted file mode 100644 index 490b3aeb..00000000 --- a/static/freebsd/man4/ntb_hw_amd.4 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
NTB_HW_AMD(4)Device Drivers ManualNTB_HW_AMD(4)
-
-
-

-

ntb_hw_amd — AMD - Non-Transparent Bridge driver

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device ntb -
-device ntb_hw_amd
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
ntb_hw_amd_load="YES"
-
-

The following sysctls are supported in this driver

-
-
dev.ntb_hw.X.info
-
Reading this sysctl will give the basic details like the number of memory - windows, scratchpads and doorbells exposed by the NTB on the local host to - access the devices beyond the bridge. It also provides details about the - masked doorbells, translation address and size limit of each exposed - memory window and link status information.
-
-
-
-

-

The ntb_hw_amd driver provides support for - the Non-Transparent Bridge (NTB) hardware in AMD EPYC processor family. The - Non-Transparent Bridge does not look as a regular PCI bridge, but as PCI - endpoint device, hiding the devices behind it. The driver hides details of - hardware on the other side, but exposes memory windows, scratchpads and - doorbells to access the other side via hardware independent KPI to - ntb(4) subsystem.

-

The hardware provides 2 (both 64-bit) or 3 (one 32-bit and two - 64-bit) memory windows to the other system's memory, up to 16 scratchpad - registers and 16 doorbells to communicate with and interrupt the other - system respectively.

-
-
-

-

The NTB configuration should be set by BIOS. This includes - enabling NTB, choosing topology (only NTB-to-Root Port mode is supported - now), role of the host in the topology. This needs to be done on both - systems.

-

The BAR size for memory windows is configured to 1 MiB by - default.

-
-
-

-

if_ntb(4), ntb(4), - ntb_transport(4)

-
-
-

-

The ntb_hw_amd driver was developed by AMD - and originally written by Rajesh Kumar - <rajesh1.kumar@amd.com>. - Reviewed by Alexander Motin - <mav@FreeBSD.org>, - Conrad E. Meyer - <cem@FreeBSD.org> and - Warner Losh - <imp@FreeBSD.org>.

-
-
- - - - - -
August 29, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ntb_hw_intel.4 3.html b/static/freebsd/man4/ntb_hw_intel.4 3.html deleted file mode 100644 index 7d2863f7..00000000 --- a/static/freebsd/man4/ntb_hw_intel.4 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
NTB_HW_INTEL(4)Device Drivers ManualNTB_HW_INTEL(4)
-
-
-

-

ntb_hw_intel — - Intel(R) Non-Transparent Bridge driver

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device ntb -
-device ntb_hw_intel
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
ntb_hw_intel_load="YES"
-
-
-
-

-

The ntb_hw_intel driver provides support - for the Non-Transparent Bridge (NTB) hardware in Intel Xeon E3/E5 and S1200 - processor families, which allow one of their PCIe ports to be switched from - transparent to non-transparent bridge mode. In this mode the bridge looks - not like a PCI bridge, but like a PCI endpoint device. The driver hides - hardware details, exposing memory windows, scratchpads and doorbells of the - other side via a hardware independent KPI to the ntb(4) - subsystem.

-

The hardware provides 2 or 3 memory windows to the other system's - memory, 16 scratchpad registers and 14, 31 or 34 doorbells to interrupt the - other system, depending on the platform. On Xeon processors one of the - memory windows is typically consumed by the driver itself to work around - multiple hardware errata.

-
-
-

-

The NTB configuration should be set by BIOS. It includes enabling - NTB, choosing between NTB-to-NTB (back-to-back) or NTB-to-Root Port mode, - enabling split BAR mode (one of two 64-bit BARs can be split into two 32-bit - ones) and configuring BAR sizes in bits (from 12 to 29/39) for both NTB - sides.

-

The recommended configuration is NTB-to-NTB mode, split bar - enabled and all BAR sizes set to 20 (1 MiB). This needs to be done on both - systems. Note, on Xeon SkyLake and newer platforms, split bar mode is not - available.

-
-
-

-

if_ntb(4), ntb(4), - ntb_transport(4)

-
-
-

-

The ntb_hw_intel driver was developed by - Intel and originally written by Carl Delsey - <carl@FreeBSD.org>. - Later improvements were done by Conrad E. Meyer - <cem@FreeBSD.org> and - Alexander Motin - <mav@FreeBSD.org>.

-
-
-

-

NTB-to-Root Port mode is not yet supported, but it doesn't look - very useful.

-

On Xeon v2/v3/v4 processors split BAR mode should be enabled to - allow SB01BASE_LOCKUP errata workaround to be applied by the driver.

-

There is no way to protect your system from malicious behavior on - the other system once the link is brought up. Anyone with root or kernel - access on the other system can read or write to any location on your system. - In other words, only connect two systems that completely trust each - other.

-
-
- - - - - -
October 11, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ntb_hw_plx.4 3.html b/static/freebsd/man4/ntb_hw_plx.4 3.html deleted file mode 100644 index e82de212..00000000 --- a/static/freebsd/man4/ntb_hw_plx.4 3.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - -
NTB_HW_PLX(4)Device Drivers ManualNTB_HW_PLX(4)
-
-
-

-

ntb_hw_plx — - PLX/Avago/Broadcom Non-Transparent Bridge driver

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device ntb -
-device ntb_hw_plx
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
ntb_hw_plx_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hint.ntb_hw.X.b2b
-
Being set to 1 (default) tells the driver attached to Virtual Interface of - the NTB that it works in NTB-to-NTB (back-to-back) mode, 0 -- NTB-to-Root - Port. Driver attached to Link Interface (visible from Root Port side) - switches to NTB-to-Root Port mode automatically, but one attached to - Virtual Interface can't detect what is on the other side and require - external knowledge.
-
hint.ntb_hw.X.split
-
Being set above zero splits BAR2 into 2^x memory windows using Address - Lookup Table (A-LUT).
-
-
-
-

-

The ntb_hw_plx driver provides support for - the Non-Transparent Bridge (NTB) hardware in PLX PCIe bridge chips, which - allow up to two of their PCIe ports to be switched from transparent to - non-transparent bridge mode. In this mode bridge looks not as a PCI bridge, - but as PCI endpoint device. The driver hides hardware details, exposing - memory windows, scratchpads and doorbells of the other side via hardware - independent KPI to ntb(4) subsystem.

-

Each PLX NTB provides up to 2 64-bit or 4 32-bit memory windows to - the other system's memory, 6 or 12 scratchpad registers and 16 doorbells to - interrupt the other system. If Address Lookup Table (A-LUT) is enabled, BAR2 - can be split into several (up to 128) memory windows. In NTB-to-NTB mode one - of memory windows (or half of it, if bigger then 1MB) is consumed by the - driver itself to access scratchpad and doorbell registers of the other - side.

-
-
-

-

The following PLX/Avago/Broadcom chips are supported by the - ntb_hw_plx driver:

-

-
    -
  • PEX 8713
    • -
  • PEX 8717
    • -
  • PEX 8725
    • -
  • PEX 8733
    • -
  • PEX 8749
    • -
-

, but it may also work with other compatible ones.

-
-
-

-

The basic chip configuration should be done by serial EEPROM or - via i2c. It includes enabling NTB on one or both sides (choosing between - NTB-to-NTB (back-to-back) and NTB-to-Root Port modes) and configuring BARs - sizes.

-

The recommended mode is NTB-to-NTB mode, since while NTB-to-Root - Port is generally supported by the driver, it require PCI hotplug handling - on the Root Port, that may be difficult or cause different kinds of - problems.

-
-
-

-

if_ntb(4), ntb(4), - ntb_transport(4)

-
-
-

-

The ntb_hw_plx driver was written by - Alexander Motin - <mav@FreeBSD.org>.

-
-
-

-

There is no way to protect your system from malicious behavior on - the other system once the link is brought up. Anyone with root or kernel - access on the other system can read or write to any location on your system. - In other words, only connect two systems that completely trust each - other.

-
-
- - - - - -
November 9, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/ntb_transport.4 3.html b/static/freebsd/man4/ntb_transport.4 3.html deleted file mode 100644 index b16784a8..00000000 --- a/static/freebsd/man4/ntb_transport.4 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
NTB_TRANSPORT(4)Device Drivers ManualNTB_TRANSPORT(4)
-
-
-

-

ntb_transport — - Packet-oriented transport for Non-Transparent - Bridges

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device ntb -
-device ntb_transport
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
ntb_transport_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hw.ntb_transport.debug_level
-
Driver debug level. The default value is 0, higher means more - verbose.
-
hw.ntb_transport.max_mw_size
-
Limits maximum memory window usage. Allocation of big physically - contiguous memory buffer may be a problem, while too big buffers makes no - much sense for low latency network interface.
-
hint.ntb_transport.X.config
-
Configures a set of the transport consumers, separated by commas. Each - consumer can be configured as: - "[<name>][:<queues>]", where: - name is a name of the driver to attach (empty means - any), queues is a number of queues to allocate - (empty means automatic). The default configuration is empty string, which - means single consumer with one queue per memory window, allowing any - driver to attach.
-
hint.ntb_transport.X.compact
-
Non-zero value enables compact version of scratchpad protocol, using half - as many registers. Enabled automatically if there is not enough registers - to negotiate all available memory windows. The compact version does not - support memory windows of 4GB and above.
-
-
-
-

-

The ntb_transport driver attaches on top - of the ntb driver to utilize its resources to create - a set of bidirectional queues, delivering packets between the systems. The - primary purpose of this driver is to be used by - if_ntb network interface, but other consumers may - also be developed using KPI.

-

Each ntb_transport require from underlying - ntb instance:

-
    -
  • 1 or more memory windows;
    • -
  • 6 scratchpads, plus 2 more for each additional memory window, or 3 plus 1 - in case of compact protocol;
    • -
  • 1 doorbell for each memory window or configured queue.
    • -
-
-
-

-

if_ntb(4), ntb(4), - ntb_hw_amd(4), ntb_hw_intel(4), - ntb_hw_plx(4)

-
-
-

-

The ntb_transport driver was developed by - Intel and originally written by Carl Delsey - <carl@FreeBSD.org>. - Later improvements were done by Conrad E. Meyer - <cem@FreeBSD.org> and - Alexander Motin - <mav@FreeBSD.org>.

-
-
- - - - - -
November 9, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/null.4 4.html b/static/freebsd/man4/null.4 4.html deleted file mode 100644 index 100c35ee..00000000 --- a/static/freebsd/man4/null.4 4.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - -
NULL(4)Device Drivers ManualNULL(4)
-
-
-

-

null — the null - device

-
-
-

-

The null device accepts and reads data as - any ordinary (and willing) file - but throws it away. The length of the - null device is always zero.

-
-
-

-
-
/dev/null
-
 
-
-
-
-

-

full(4), zero(4)

-
-
-

-

A null device appeared in - Version 4 AT&T UNIX.

-
-
- - - - - -
August 30, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/nullfs.4 4.html b/static/freebsd/man4/nullfs.4 4.html deleted file mode 100644 index 459f204d..00000000 --- a/static/freebsd/man4/nullfs.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
NULLFS(4)Device Drivers ManualNULLFS(4)
-
-
-

-

nullfs — null file - system

-
-
-

-

To enable support for this driver, place the following line in the - kernel configuration file:

-
options NULLFS
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
nullfs_load="YES"
-
-
-
-

-

The nullfs driver will permit the - FreeBSD kernel to mount a loopback file system - sub-tree.

-
-
-

-

To mount a nullfs file system:

-

-
mount_nullfs /usr/ports - /home/devel/ports
-

It is also possible to define an entry in - fstab(5) that looks similar to:

-
-
/usr/ports	/home/devel/ports	nullfs		rw	0	0
-
-
-
-

-

fstab(5), mount_nullfs(8)

-
-
-

-

The nullfs layer first appeared in - 4.4BSD.

-
-
-

-

The nullfs kernel implementation was - written by John Heideman.

-

This manual page was written by Daniel - Gerzo - <danger@FreeBSD.org>.

-
-
- - - - - -
March 15, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/numa.4 3.html b/static/freebsd/man4/numa.4 3.html deleted file mode 100644 index 0dbba782..00000000 --- a/static/freebsd/man4/numa.4 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
NUMA(4)Device Drivers ManualNUMA(4)
-
-
-

-

NUMA — Non-Uniform - Memory Access

-
-
-

-

options MAXMEMDOM -
- options NUMA

-
-
-

-

Non-Uniform Memory Access is a computer architecture design which - involves unequal costs between processors, memory and IO devices in a given - system.

-

In a NUMA architecture, the latency to - access specific memory or IO devices depends upon which processor the memory - or device is attached to. Accessing memory local to a processor is faster - than accessing memory that is connected to one of the other processors. - FreeBSD implements NUMA-aware memory allocation - policies. By default it attempts to ensure that allocations are balanced - across each domain. Users may override the default domain selection policy - using cpuset(1).

-

NUMA support is enabled when the - NUMA option is specified in the kernel configuration - file. Each platform defines the MAXMEMDOM constant, - which specifies the maximum number of supported NUMA domains. This constant - may be specified in the kernel configuration file. - NUMA support can be disabled at boot time by setting - the vm.numa.disabled tunable to 1. Other values for - this tunable are currently ignored.

-

Thread and process NUMA policies are - controlled with the cpuset_getdomain(2) and - cpuset_setdomain(2) syscalls. The - cpuset(1) tool is available for starting processes with a - non-default policy, or to change the policy of an existing thread or - process. See SMP(4) for information about CPU to domain - mapping.

-

Systems with non-uniform access to I/O devices may mark those - devices with the local VM domain identifier. Drivers can find out their - local domain information by calling bus_get_domain(9).

-
-

-

The operation of NUMA is controlled and - exposes information with these sysctl(8) MIB - variables:

-

-
-
vm.ndomains
-
The number of VM domains which have been detected. -

-
-
vm.phys_locality
-
A table indicating the relative cost of each VM domain to each other. A - value of 10 indicates equal cost. A value of -1 means the locality map is - not available or no locality information is available. -

-
-
vm.phys_segs
-
The map of physical memory, grouped by VM domain.
-
-
-
-
-

-

The current NUMA implementation is - VM-focused. The hardware NUMA domains are mapped - into a contiguous, non-sparse VM domain space, starting from 0. Thus, VM - domain information (for example, the domain identifier) is not necessarily - the same as is found in the hardware specific information. Policy - information is available in both struct thread and struct proc.

-
-
-

-

cpuset(1), - cpuset_getaffinity(2), - cpuset_setaffinity(2), SMP(4), - bus_get_domain(9)

-
-
-

-

NUMA first appeared in - FreeBSD 9.0 as a first-touch allocation policy with - a fail-over to round-robin allocation and was not configurable. It was then - modified in FreeBSD 10.0 to implement a round-robin - allocation policy and was also not configurable.

-

The numa_getaffinity(2) and - numa_setaffinity(2) syscalls and the - numactl(1) tool first appeared in FreeBSD - 11.0 and were removed in FreeBSD 12.0. The - current implementation appeared in FreeBSD 12.0.

-
-
-

-

This manual page written by Adrian Chadd - <adrian@FreeBSD.org>.

-
-
-

-

No statistics are kept to indicate how often - NUMA allocation policies succeed or fail.

-
-
- - - - - -
October 22, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/nvd.4 3.html b/static/freebsd/man4/nvd.4 3.html deleted file mode 100644 index 3cfb1f79..00000000 --- a/static/freebsd/man4/nvd.4 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
NVD(4)Device Drivers ManualNVD(4)
-
-
-

-

nvd — NVM Express - disk driver

-
-
-

-

To compile this driver into your kernel, place the following lines - in your kernel configuration file:

-
device nvme -
-device nvd
-

Or, to load the driver as a module at boot, place the following - lines in loader.conf(5):

-
-
nvme_load="YES"
-nvd_load="YES"
-
-
-
-

-

The nvd driver exposes NVM Express (NVMe) - namespaces as disks to the kernel disk storage API. It depends on the - nvme(4) driver for notification of existing NVMe - namespaces and submission of NVM I/O commands.

-

Device nodes from the nvd driver will have - the format /dev/nvdX and are GEOM(4) disks which can be - partitioned by geom(8). Note that device nodes from the - nvme(4) driver are not GEOM(4) disks and - cannot be partitioned.

-
-
-

-

The nvd driver supports NVMe storage - devices using NVMe namespaces.

-
-
-

-

The nvd driver defines a system-wide - maximum delete size for NVMe devices. The default is 1GB. To select a - different value, set the following tunable in - loader.conf(5):

-
-
hw.nvd.delete_max=<delete size in bytes>
-
-
-
-

-

GEOM(4), nda(4), - nvme(4), geom(8), - nvmecontrol(8), disk(9)

-
-
-

-

The nvd driver first appeared in - FreeBSD 9.2.

-
-
-

-

The nvd driver was developed by Intel and - originally written by Jim Harris - <jimharris@FreeBSD.org>, - with contributions from Joe Golio at EMC.

-

This man page was written by Jim Harris - <jimharris@FreeBSD.org>.

-
-
- - - - - -
October 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/nvdimm.4 3.html b/static/freebsd/man4/nvdimm.4 3.html deleted file mode 100644 index a3400a78..00000000 --- a/static/freebsd/man4/nvdimm.4 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
NVDIMM(4)Device Drivers Manual (amd64)NVDIMM(4)
-
-
-

-

nvdimm — ACPI - NVDIMM driver

-
-
-

-

To load the driver as a module at boot, place the following line - in loader.conf(5):

-
-
nvdimm_load="YES"
-
-
-
-

-
Note: The nvdimm driver is under - development and has some important limitations described below.
-

The nvdimm driver provides access to - Non-Volatile DIMM (NVDIMM) persistent memory devices, which are - ACPI-enumerated under the root NVDIMM device with a - _HID of ACPI0012 and in the - NFIT table.

-

For each System Physical Address (SPA) Range described by NFIT, a - device node /dev/nvdimm_spaNNN is created, where - NNN is the SPA position in the table. The node can - be used to read(2), write(2), or - mmap(2) the device.

-

Also, for each SPA, the geom provider - spaNNN is created, which can be used to create a - conventional filesystem (e.g., by newfs(8)) and - mount(8) it as any storage volume. Content accessible by - /dev/nvdimm_spaNNN and - /dev/spaNNN is coherent.

-

The nvdimm driver has support for reading - NVDIMM namespaces (if supported by your hardware and already configured by - some other mechanism, e.g., a BIOS configuration screen). The driver will - provide a /dev/nvdimm_spaNNNnsMMM device node and - spaNNNnsMMM geom provider for each namespace in a - SPA, which behave analogously to their full-SPA cousins described above.

-
-
-

-

acpi(4), GEOM(4), - geom(8), mount(8), - newfs(8), disk(9)

-
-
-

-

The nvdimm driver first appeared in - FreeBSD 12.0.

-
-
-

-

The nvdimm driver was originally written - by Konstantin Belousov - <kib@FreeBSD.org>, and - then updated by D. Scott Phillips - <scottph@FreeBSD.org>.

-
-
-

-

The nvdimm driver does not utilize the - Block Window interface, so if a write to an NVDIMM is interrupted due to a - system crash or power outage, the corresponding page might be left in a - partially updated state.

-

There is no support for Device-Specific Methods (DSM), used to - report and control device health and wearing.

-

The driver depends on the pmap_largemap(9) pmap - interface, which is currently only implemented on amd64. The interface can - be only reasonable implemented on 64bit architectures.

-
-
- - - - - -
September 5, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/nvme.4 3.html b/static/freebsd/man4/nvme.4 3.html deleted file mode 100644 index e189e085..00000000 --- a/static/freebsd/man4/nvme.4 3.html +++ /dev/null @@ -1,220 +0,0 @@ - - - - - - -
NVME(4)Device Drivers ManualNVME(4)
-
-
-

-

nvme — NVM Express - core driver

-
-
-

-

To compile this driver into your kernel, place the following line - in your kernel configuration file:

-
device nvme
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
nvme_load="YES"
-
-

Most users will also want to enable nvd(4) or - nda(4) to expose NVM Express namespaces as disk devices - which can be partitioned. Note that in NVM Express terms, a namespace is - roughly equivalent to a SCSI LUN.

-
-
-

-

The nvme driver provides support for NVM - Express (NVMe) controllers, such as:

-
    -
  • Hardware initialization
    • -
  • Per-CPU IO queue pairs
    • -
  • API for registering NVMe namespace consumers such as - nvd(4) or nda(4)
    • -
  • API for submitting NVM commands to namespaces
    • -
  • Ioctls for controller and namespace configuration and management
    • -
-

The nvme driver creates controller device - nodes in the format /dev/nvmeX and namespace device - nodes in the format /dev/nvmeXnsY. Note that the NVM - Express specification starts numbering namespaces at 1, not 0, and this - driver follows that convention.

-
-
-

-

By default, nvme will create an I/O queue - pair for each CPU, provided enough MSI-X vectors and NVMe queue pairs can be - allocated. If not enough vectors or queue pairs are available, nvme(4) will - use a smaller number of queue pairs and assign multiple CPUs per queue - pair.

-

To force a single I/O queue pair shared by all CPUs, set the - following tunable value in loader.conf(5):

-
-
hw.nvme.per_cpu_io_queues=0
-
-

To assign more than one CPU per I/O queue pair, thereby reducing - the number of MSI-X vectors consumed by the device, set the following - tunable value in loader.conf(5):

-
-
hw.nvme.min_cpus_per_ioq=X
-
-

To force legacy interrupts for all nvme - driver instances, set the following tunable value in - loader.conf(5):

-
-
hw.nvme.force_intx=1
-
-

Note that use of INTx implies disabling of per-CPU I/O queue - pairs.

-

To control maximum amount of system RAM in bytes to use as Host - Memory Buffer for capable devices, set the following tunable:

-
-
hw.nvme.hmb_max
-
-

The default value is 5% of physical memory size per device.

-

To enable Autonomous Power State Transition (APST), set the - following tunable value in loader.conf(5):

-
-
hw.nvme.apst_enable=1
-
-

The default vendor-provided settings, if any, will be applied. To - override this, set the following tunable:

-
-
hw.nvme.apst_data
-
-

The string must contain up to 32 encoded integers, e.g. - "0x6418 0 0 0x3e820". Each value corresponds to a specific - available power state starting from the lowest, and defines the target state - (bits 3..7) to transition to, as well as the idle time in milliseconds (bits - 8..31) to wait before that transition. Bits 0..2 must be zero.

-

The nvd(4) driver is used to provide a disk - driver to the system by default. The nda(4) driver can - also be used instead. The nvd(4) driver performs better - with smaller transactions and few TRIM commands. It sends all commands - directly to the drive immediately. The nda(4) driver - performs better with larger transactions and also collapses TRIM commands - giving better performance. It can queue commands to the drive; combine - BIO_DELETE commands into a single trip; and use the - CAM I/O scheduler to bias one type of operation over another. To select the - nda(4) driver, set the following tunable value in - loader.conf(5):

-
-
hw.nvme.use_nvd=0
-
-

This value may also be set in the kernel config file with

-
-
options NVME_USE_NVD=0
-
-

When there is an error, nvme prints only - the most relevant information about the command by default. To enable - dumping of all information about the command, set the following tunable - value in loader.conf(5):

-
-
hw.nvme.verbose_cmd_dump=1
-
-

Prior versions of the driver reset the card twice on boot. This - proved to be unnecessary and inefficient, so the driver now resets drive - controller only once. The old behavior may be restored in the kernel config - file with

-
-
options NVME_2X_RESET
-
-
-
-

-

The following controller-level sysctls are currently - implemented:

-
-
dev.nvme.0.num_cpus_per_ioq
-
(R) Number of CPUs associated with each I/O queue pair.
-
dev.nvme.0.int_coal_time
-
(R/W) Interrupt coalescing timer period in microseconds. Set to 0 to - disable.
-
dev.nvme.0.int_coal_threshold
-
(R/W) Interrupt coalescing threshold in number of command completions. Set - to 0 to disable.
-
-

The following queue pair-level sysctls are currently implemented. - Admin queue sysctls take the format of dev.nvme.0.adminq and I/O queue - sysctls take the format of dev.nvme.0.ioq0.

-
-
dev.nvme.0.ioq0.num_entries
-
(R) Number of entries in this queue pair's command and completion - queue.
-
dev.nvme.0.ioq0.num_tr
-
(R) Number of nvme_tracker structures currently allocated for this queue - pair.
-
dev.nvme.0.ioq0.num_prp_list
-
(R) Number of nvme_prp_list structures currently allocated for this queue - pair.
-
dev.nvme.0.ioq0.sq_head
-
(R) Current location of the submission queue head pointer as observed by - the driver. The head pointer is incremented by the controller as it takes - commands off of the submission queue.
-
dev.nvme.0.ioq0.sq_tail
-
(R) Current location of the submission queue tail pointer as observed by - the driver. The driver increments the tail pointer after writing a command - into the submission queue to signal that a new command is ready to be - processed.
-
dev.nvme.0.ioq0.cq_head
-
(R) Current location of the completion queue head pointer as observed by - the driver. The driver increments the head pointer after finishing with a - completion entry that was posted by the controller.
-
dev.nvme.0.ioq0.num_cmds
-
(R) Number of commands that have been submitted on this queue pair.
-
dev.nvme.0.ioq0.dump_debug
-
(W) Writing 1 to this sysctl will dump the full contents of the submission - and completion queues to the console.
-
-

In addition to the typical pci attachment, the - nvme driver supports attaching to a - ahci(4) device. Intel's Rapid Storage Technology (RST) - hides the nvme device behind the AHCI device due to limitations in Windows. - However, this effectively hides it from the FreeBSD - kernel. To work around this limitation, FreeBSD - detects that the AHCI device supports RST and when it is enabled. See - ahci(4) for more details.

-
-
-

-
-
nvme%d: System interrupt issues?
-
The driver found a timed-out transaction had a pending completion record, - indicating an interrupt had not been delivered. The system is either not - configuring interrupts properly, or the system drops them under load. This - message will appear at most once per boot per controller.
-
-
-
-

-

nda(4), nvd(4), - pci(4), nvmecontrol(8), - disk(9)

-
-
-

-

The nvme driver first appeared in - FreeBSD 9.2.

-
-
-

-

The nvme driver was developed by Intel and - originally written by Jim Harris - <jimharris@FreeBSD.org>, - with contributions from Joe Golio at EMC.

-

This man page was written by Jim Harris - <jimharris@FreeBSD.org>.

-
-
- - - - - -
June 6, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/nvmf.4 3.html b/static/freebsd/man4/nvmf.4 3.html deleted file mode 100644 index 2a89420d..00000000 --- a/static/freebsd/man4/nvmf.4 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
NVMF(4)Device Drivers ManualNVMF(4)
-
-
-

-

nvmf — NVM Express - over Fabrics host driver

-
-
-

-

To compile the driver into the kernel, place the following line in - the kernel configuration file:

-
device nvmf
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
nvmf_load="YES"
-
-
-
-

-

The nvmf driver provides the kernel - component of an NVM Express over Fabrics host. The NVMeoF host is the client - which provides local access to namespaces exported by a remote - controller.

-

Associations between the local host and remote controllers are - managed using nvmecontrol(8). New associations are created - via the connect command and destroyed via the - disconnect command. If an association's connection - is interrupted, the reconnect command creates a new - association to replace the interrupted association.

-

Similar to nvme(4), nvmf - creates controller device nodes using the format - /dev/nvmeX and namespace device nodes using the - format /dev/nvmeXnsY. nvmf - also exports remote namespaces via the CAM nda(4) - peripheral driver. Unlike nvme(4), - nvmf does not support the nvd(4) - disk driver.

-

Associations require a supported transport such as - nvmf_tcp(4) for associations using TCP/IP.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.nvmf.fail_on_disconnection
-
Determines the behavior when an association's connection is interrupted. - By default, input/output operations are suspended while a host is - disconnected. This includes operations pending at the time the - association's connection was interrupted as well as new requests submitted - while the host is disconnected. Once a new association is established, - suspended I/O requests are retried. When set to 1, input/output operations - fail with EIO while a host is disconnected and - nda(4) peripherals are destroyed after the first failed - I/O request. Note that any destroyed nda(4) peripherals - will be recreated after a new association is established.
-
-
-
-

-

nda(4), nvme(4), - nvmf_tcp(4), nvmft(4), - nvmecontrol(8)

-
-
-

-

The nvmf module first appeared in - FreeBSD 15.0.

-
-
-

-

The nvmf driver was developed by - John Baldwin - <jhb@FreeBSD.org> - under sponsorship from Chelsio Communications, Inc.

-
-
- - - - - -
May 7, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/nvmf_che.4 3.html b/static/freebsd/man4/nvmf_che.4 3.html deleted file mode 100644 index 01ff64f1..00000000 --- a/static/freebsd/man4/nvmf_che.4 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
NVMF_CHE(4)Device Drivers ManualNVMF_CHE(4)
-
-
-

-

nvmf_che — TCP - transport for NVM Express over Fabrics on Chelsio NICs

-
-
-

-

In loader.conf(5):

-
-
nvmf_che_load="YES"
-
-
-
-

-

The nvmf_che module implements the a - TCP/IP transport for NVM Express over Fabrics using PDU offload on Chelsio - T7 adapters. It can be used by either the in-kernel NVMeoF host driver or - controller. In order to use PDU offload, the initial socket connection must - be using the TCP offload engine (TOE) on a supported network interface. In - addition, controller connections must negotiate a suitable - MAXH2CDATA limit to ensure that received PDUs do not - exceeed the maximum size supported by the adapter.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.nvmf.che.max_transmit_pdu
-
The maximum size of a transmitted PDU including all headers, payload, and - checksums. This is an upper limit enforced when queues are created. - Individual adapters may empose a smaller limit. The default size is 32 - kilobytes.
-
kern.nvmf.che.max_receive_pdu
-
As above, but for received PDUs.
-
kern.nvmf.che.use_dsgl
-
Enable the use of a S/G list for large writes into adapter memory when - writing control structures for DDP (not used for PDU payload data). S/G - lists are enabled by default.
-
kern.nvmf.che.inline_threshold
-
Writes of control structures into adapter memory use a S/G list instead of - immediate data placed in work requests. The default threshold is 256 - bytes.
-
kern.nvmf.che.ddp_tags_per_qp
-
The number of STAGs reserved for use by DDP buffers for each queue pair. - Each command sent on a queue that requests data from the remote peer can - use DDP to place received data directly into the associated data buffer. - Each buffer requires a STAG to enable DDP. If an STAG is not available - when command requesting remote data is sent, the data will be received in - free list buffers and copied into the data buffer by the driver instead. - The default size is 256 kilobytes.
-
-
-
-

-

cxgbe(4), nvmf(4), - nvmf_tcp(4), nvmft(4)

-
-
-

-

The nvmf_che module first appeared in - FreeBSD 16.0.

-
-
-

-

The nvmf_che module was developed by - John Baldwin - <jhb@FreeBSD.org> - under sponsorship from Chelsio Communications, Inc.

-
-
- - - - - -
November 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/nvmf_tcp.4 3.html b/static/freebsd/man4/nvmf_tcp.4 3.html deleted file mode 100644 index 7b8508ad..00000000 --- a/static/freebsd/man4/nvmf_tcp.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
NVMF_TCP(4)Device Drivers ManualNVMF_TCP(4)
-
-
-

-

nvmf_tcp — TCP - transport for NVM Express over Fabrics

-
-
-

-

To compile the module into the kernel, place the following line in - the kernel configuration file:

-
device nvmf_tcp
-

Alternatively, to load the module at boot time, place the - following line in loader.conf(5):

-
-
nvmf_tcp_load="YES"
-
-
-
-

-

The nvmf_tcp module implements the - software TCP/IP transport for NVM Express over Fabrics. It can be used by - either the in-kernel NVMeoF host driver or controller.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.nvmf.tcp.max_transmit_data
-
The maximum data payload size of C2H_DATA and - H2C_DATA PDUs. A remote controller may enforce a - lower limit on the size of H2C_DATA PDUs via the - MAXH2CDATA parameter. The default size is 256 - kilobytes.
-
-
-
-

-

nvmf(4), nvmft(4)

-
-
-

-

The nvmf_tcp module first appeared in - FreeBSD 15.0.

-
-
-

-

The nvmf_tcp module was developed by - John Baldwin - <jhb@FreeBSD.org> - under sponsorship from Chelsio Communications, Inc.

-
-
- - - - - -
July 25, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/nvmft.4 3.html b/static/freebsd/man4/nvmft.4 3.html deleted file mode 100644 index 06f69290..00000000 --- a/static/freebsd/man4/nvmft.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
NVMFT(4)Device Drivers ManualNVMFT(4)
-
-
-

-

nvmft — NVM - Express over Fabrics CAM Target Layer frontend

-
-
-

-

To compile the subsystem into the kernel, place the following - lines in the kernel configuration file:

-
device nvmft -
-device ctl
-

Alternatively, to load the subsystem as a module at boot time, - place the following line in loader.conf(5):

-
-
nvmft_load="YES"
-
-
-
-

-

The nvmft driver provides the kernel - component of an NVM Express over Fabrics controller. The NVMeoF controller - is the server exporting namespaces backed by local files and volumes to - remote hosts. nvmft follows the dynamic controller - model and creates a new dynamic controller for each association.

-

nvmft is implemented as a - ctl(4) frontend and exports CAM Target Layer LUNs as - namespaces to remote hosts. LUNs can be configured via - ctladm(8).

-

Associations between the local controller and remote hosts are - managed using both the nvmfd(8) daemon and the - ctladm(8) utility. The nvmfd(8) daemon - listens for new associations and handles transport-specific negotiation - before handing off connected queue pairs to nvmft - which associates queue pairs with a suitable controller instance. The - nvlist ctladm(8) command lists - active controllers. The nvterminate command - terminates one or more associations between a local controller and a remote - host.

-

Associations require a supported transport such as - nvmf_tcp(4) for associations using TCP/IP.

-
-
-

-

ctl(4), nvmf(4), - nvmf_tcp(4), ctladm(8), - nvmfd(8)

-
-
-

-

The nvmft module first appeared in - FreeBSD 15.0.

-
-
-

-

The nvmft subsystem was developed by - John Baldwin - <jhb@FreeBSD.org> - under sponsorship from Chelsio Communications, Inc.

-
-
- - - - - -
May 2, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/nvram.4 3.html b/static/freebsd/man4/nvram.4 3.html deleted file mode 100644 index c75c0be5..00000000 --- a/static/freebsd/man4/nvram.4 3.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
NVRAM(4)Device Drivers ManualNVRAM(4)
-
-
-

-

nvram — - non-volatile RAM

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device nvram
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
nvram_load="YES"
-
-
-
-

-

The nvram driver provides access to BIOS - configuration NVRAM on i386 and amd64 systems.

-

PC motherboard uses a small non-volatile memory to store BIOS - settings which is usually part of its clock chip and sometimes referred as - “CMOS SRAM”. This driver exposes bytes 14 through 128 of the - NVRAM, or a total of 114 bytes, at offset zero of the device file - /dev/nvram.

-

This driver is useful for cloning machines that shares the same - hardware configuration and need same BIOS setting tweaks.

-
-
-

-

The BIOS NVRAM's bytes 16 through 31 are checksummed at byte 32. - This driver take care for these checksums.

-
-
-

-

Backup existing BIOS NVRAM to - nvram.bin:

-

-
dd if=/dev/nvram - of=nvram.bin
-

Restore BIOS NVRAM from nvram.bin:

-

-
dd if=nvram.bin - of=/dev/nvram
-
-
-

-

dd(1)

-
-
-

-

The nvram device driver first appeared in - FreeBSD 6.4.

-
-
-

-

The nvram device driver was written by - Peter Wemm. This manual page was written by - Xin LI.

-
-
- - - - - -
February 8, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/oce.4 3.html b/static/freebsd/man4/oce.4 3.html deleted file mode 100644 index c33aa18e..00000000 --- a/static/freebsd/man4/oce.4 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
OCE(4)Device Drivers ManualOCE(4)
-
-
-

-

oce — Device - driver for Emulex OneConnect 10Gb network adapters

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device oce
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_oce_load="YES"
-
-
-
-

-

Emulex OneConnect adapters come in various skews and with - different combinations of NIC, FCoE and iSCSI functions. The - oce driver claims the NIC functions in all these - adapters.

-

The oce driver supports VLAN Hardware - offload, TCP checksum offload, TCP segmentation offload (TSO), Large receive - offload (LRO), Bonding, Jumbo frames (from 1500 - 9000), Multiple TX queues, - Receive-Side Scaling (RSS) and MSI-X interrupts.

-
-
-

-

The oce driver supports the following - network adapters:

-

-
    -
  • Emulex BladeEngine 2
    • -
  • Emulex BladeEngine 3
    • -
  • Emulex Lancer
    • -
-
-
-

-

Adapter firmware updates are persistent.

-

Firmware can be updated by following the steps below:

-
    -
  1. Copy the below code to a Makefile: -
    - 
    KMOD=elxflash
-FIRMWS=imagename.ufi:elxflash
-.include <bsd.kmod.mk>
    -
    -
    2. -
  2. Replace imagename in above with UFI file name
    3. -
  3. Copy Makefile and UFI file to a directory
    4. -
  4. Execute make & copy generated elxflash.ko to - /lib/modules
    5. -
  5. sysctl dev.oce.<if_id>.fw_upgrade=elxflash
    6. -
  6. Reboot the machine
    7. -
-

In case of issues with supplied UFI, flashing fails with one of - the following errors.

-

-
    -
  1. "Invalid BE3 firmware image"
    2. -
  2. "Invalid Cookie. Firmware image corrupted ?"
    3. -
  3. "cmd to write to flash rom failed."
    4. -
-
-
-

-

For general information and support, go to the Emulex website at: - http://www.Emulex.com/ or E-Mail at - freebsd-drivers@emulex.com.

-
-
-

-

ifconfig(8)

-
-
-

-

The oce driver was written by - freebsd-drivers@emulex.com.

-
-
- - - - - -
January 27, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ocs_fc.4 3.html b/static/freebsd/man4/ocs_fc.4 3.html deleted file mode 100644 index 30f03b66..00000000 --- a/static/freebsd/man4/ocs_fc.4 3.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
OCS_FC(4)Device Drivers ManualOCS_FC(4)
-
-
-

-

ocs_fc — Device - driver for Emulex Fibre Channel Host Adapters

-
-
-

-

To compile this driver into the kernel, add this line to the - kernel configuration file:

-
device ocs_fc
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
ocs_fc_load="YES"
-
-
-
-

-

The ocs_fc driver provides access to Fibre - Channel SCSI devices.

-

The ocs_fc driver supports initiator and - target modes. Support is available for Arbitrated loops, Point-to-Point, and - Fabric connections. FC-Tape is highly recommended for connections to tape - drives that support it. FC-Tape includes four elements from the T-10 FCP-4 - specification:

-
    -
  • Precise Delivery of Commands
    • -
  • Confirmed Completion of FCP I/O Operations
    • -
  • Retransmission of Unsuccessfully Transmitted IUs
    • -
  • Task Retry Identification
    • -
-

Together these features allow for link level error recovery with - tape devices. Without link level error recovery, an initiator cannot, for - instance, tell whether a tape write command that has timed out resulted in - all, part, or none of the data going to the tape drive. FC-Tape is - automatically enabled when both the controller and target support it.

-
-
-

-

The ocs_fc driver supports these Fibre - Channel adapters:

-
-
-
Emulex 16/8G FC GEN 5 HBAS
-
-
- 
LPe15004 FC Host Bus Adapters
-LPe160XX FC Host Bus Adapters
-
-
-
Emulex 32/16G FC GEN 6 HBAS
-
-
- 
LPe3100X FC Host Bus Adapters
-LPe3200X FC Host Bus Adapters
-
-
-
Emulex 64/32G FC GEN 7 HBAS
-
-
- 
LPe3500X FC Host Bus Adapters
-
-
-
-
-
-
-

-

Adapter firmware updates are persistent.

-

Firmware can be updated by following these steps:

-
    -
  1. Copy this code to a Makefile: -
    - 
    KMOD=ocsflash
-FIRMWS=imagename.grp:ocsflash
-.include <bsd.kmod.mk>
    -
    -
    2. -
  2. Replace imagename with the name of the GRP - file.
    3. -
  3. Copy the Makefile and GRP file to a local - directory
    4. -
  4. Execute make and copy the generated - ocsflash.ko file to - /lib/modules
    5. -
    6. -
  6. Check kernel messages regarding status of the operation
    7. -
  7. Reboot the machine
    8. -
-
-
-

-

Options are controlled by setting values in - /boot/device.hints.

-

They are:

-
-
hint.ocs_fc.N.initiator
-
Enable initiator functionality. Default 1 (enabled), 0 to disable.
-
hint.ocs_fc.N.target
-
Enable target functionality. Default 1 (enabled), 0 to disable.
-
hint.ocs_fc.N.topology
-
Topology: 0 for Auto, 1 for NPort only, 2 for Loop only.
-
hint.ocs_fc.N.speed
-
Link speed in megabits per second. Possible values include: 0 Auto-speed - negotiation (default), 4000 (4GFC), 8000 (8GFC), 16000 (16GFC).
-
-
-
-

-
-
dev.ocs_fc.N.port_state
-
Port state (read/write). Valid values are online - and offline.
-
dev.ocs_fc.N.wwpn
-
World Wide Port Name (read/write).
-
dev.ocs_fc.N.wwnn
-
World Wide Node Name (read/write).
-
dev.ocs_fc.N.fwrev
-
Firmware revision (read-only).
-
dev.ocs_fc.N.sn
-
Adapter serial number (read-only).
-
dev.ocs_fc.N.configured_speed
-
Configured Port Speed (read/write). Valid values are: 0 Auto-speed - negotiation (default), 4000 (4GFC), 8000 (8GFC), 16000 (16GFC).
-
dev.ocs_fc.N.configured_topology
-
Configured Port Topology (read/write). Valid values are: 0-Auto; 1-NPort; - 2-Loop.
-
dev.ocs_fc.N.current_speed
-
Current Port Speed (read-only).
-
dev.ocs_fc.N.current_topology
-
Current Port Topology (read-only).
-
-
-
-

-

For general information and support, go to the Broadcom website - at: http://www.broadcom.com/ or E-Mail at - ocs-driver-team.pdl@broadcom.com.

-
-
-

-

ifconfig(8)

-
-
-

-

The ocs_fc driver was written by - Broadcom.

-
-
- - - - - -
December 29, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ohci.4 4.html b/static/freebsd/man4/ohci.4 4.html deleted file mode 100644 index d60fd20e..00000000 --- a/static/freebsd/man4/ohci.4 4.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
OHCI(4)Device Drivers ManualOHCI(4)
-
-
-

-

ohci — OHCI USB - Host Controller driver

-
-
-

-

device ohci

-
-
-

-

The ohci driver provides support for - OHCI-type PCI based USB controllers.

-
-
-

-

The ohci driver supports all OHCI v1.0 - compliant controllers including:

-

-
    -
  • AcerLabs M5237 (Aladdin-V)
    • -
  • AMD-756
    • -
  • OPTi 82C861 (FireLink)
    • -
  • NEC uPD 9210
    • -
  • CMD Tech 670 (USB0670)
    • -
  • CMD Tech 673 (USB0673)
    • -
  • NVIDIA nForce3
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.ohci.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

ehci(4), uhci(4), - xhci(4)

-
-
-

-

The ohci device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The ohci driver was written by - Lennart Augustsson - <augustss@carlstedt.se> - for the NetBSD project.

-
-
- - - - - -
December 24, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/openfirm.4 3.html b/static/freebsd/man4/openfirm.4 3.html deleted file mode 100644 index b868db43..00000000 --- a/static/freebsd/man4/openfirm.4 3.html +++ /dev/null @@ -1,178 +0,0 @@ - - - - - - -
OPENFIRM(4)Device Drivers ManualOPENFIRM(4)
-
-
-

-

openfirm — Open - Firmware interface

-
-
-

-

#include - <sys/types.h> -
- #include <sys/ioctl.h> -
- #include - <dev/ofw/openfirmio.h>

-
-
-

-

The /dev/openfirm device is an interface - to the Open Firmware device tree. This interface is highly stylized. It uses - ioctl(2) calls for all operations. These calls refer to - the nodes in the Open Firmware device tree. The nodes are represented by - package handles, which are simply integer values describing data areas. - Occasionally a package handle of 0 may be used or returned instead, as - described below.

-

The calls that only take and/or return the package handle of a - node use a pointer to a phandle_t for this purpose. - The others use a pointer to a struct ofiocdesc - descriptor, which has the following definition:

-
-
struct ofiocdesc {
-	phandle_t	of_nodeid;
-	int		of_namelen;
-	const char	*of_name;
-	int		of_buflen;
-	char		*of_buf;
-};
-
-

The of_nodeid member is the package handle - of the node that is passed in or returned. Strings are passed in via the - of_name member of of_namelen - length. The maximum accepted length of of_name is - OFIOCMAXNAME. The of_buf - member is used to return strings except for the - OFIOCSET call where it is also used to pass in a - string. In the latter case the maximum accepted length of - of_buf is OFIOCMAXVALUE. - Generally, of_buf works in a value-result fashion. At - entry to the ioctl(2) call, - of_buflen is expected to reflect the buffer size. On - return, of_buflen is updated to reflect the buffer - contents.

-

The following ioctl(2) calls are supported:

-
-
-
Uses a phandle_t. Takes nothing and returns the - package handle of the /options node.
-
-
Uses a phandle_t. Takes the package handle of a node - and returns the package handle of the next node in the Open Firmware - device tree. The node following the last node has a package handle of 0. - The node following the node with the package handle of 0 is the first - node.
-
-
Uses a phandle_t. Takes the package handle of a node - and returns the package handle of the first child of that node. This child - may have siblings. These can be determined by using - OFIOCGETNEXT. If the node does not have a child, a - package handle of 0 is returned.
-
-
Uses a struct ofiocdesc. Takes the package handle of - a node and the name of a property. Returns the property value and its - length. If no such property is associated with that node, the length of - the value is set to -1. If the named property exists but has no value, the - length of the value is set to 0.
-
-
Uses a struct ofiocdesc. Takes the package handle of - a node and the name of a property. Returns the length of the property - value. This call is the same as OFIOCGET except - that only the length of the property value is returned. It can be used to - determine whether a node has a particular property or whether a property - has a value without the need to provide memory for storing the value.
-
-
Uses a struct ofiocdesc. Takes the package handle of - a node, the name of a property and a property value. Returns the property - value and the length that actually have been written. The Open Firmware - may choose to truncate the value if it is too long or write a valid value - instead if the given value is invalid for the particular property. - Therefore the returned value should be checked. The Open Firmware may also - completely refuse to write the given value to the property. In this case - EINVAL is returned.
-
-
Uses a struct ofiocdesc. Takes the package handle of - a node and the name of a property. Returns the name and the length of the - next property of the node. If the property referenced by the given name is - the last property of the node, ENOENT is - returned.
-
-
Uses a struct ofiocdesc. Takes the name or alias - name of a device node. Returns package handle of the node. If no matching - node is found, ENOENT is returned.
-
-
-
-

-
-
/dev/openfirm
-
Open Firmware interface node
-
-
-
-

-

The following may result in rejection of an operation:

-
-
[EBADF]
-
The requested operation requires permissions not specified at the call to - open().
-
[EINVAL]
-
The given package handle is not 0 and does not correspond to any valid - node, or the given package handle is 0 where 0 is not allowed.
-
[ENAMETOOLONG]
-
The given name or value exceeds the maximum allowed length of - OFIOCMAXNAME and - OFIOCMAXVALUE bytes respectively.
-
-
-
-

-

ioctl(2), ofwdump(8)

-

IEEE Std 1275-1994:, - IEEE Standard for Boot Firmware (Initialization - Configuration) Firmware:, Core Requirements and - Practices", IEEE Standards Organization, - ISBN 1-55937-426-8.

-
-
-

-

The openfirm interface first appeared in - NetBSD 1.6. The first - FreeBSD version to include it was - FreeBSD 5.0.

-
-
-

-

The openfirm interface was ported to - FreeBSD by Thomas Moestl - <tmm@FreeBSD.org>. - This manual page was written by Marius Strobl - <marius@FreeBSD.org> - based on the OpenBSD manual page for - openprom(4).

-
-
-

-

Due to limitations within Open Firmware itself, these functions - run at elevated priority and may adversely affect system performance.

-

For at least the /options node the - property value passed in to the OFIOCSET call has to - be null-terminated and the value length passed in has to include the - terminating ‘\0’. However, as with the - OFIOCGET call, the returned value length does not - include the terminating ‘\0’.

-
-
- - - - - -
January 16, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/orm.4 4.html b/static/freebsd/man4/orm.4 4.html deleted file mode 100644 index c4d67509..00000000 --- a/static/freebsd/man4/orm.4 4.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - -
ORM(4)Device Drivers ManualORM(4)
-
-
-

-

orm — ISA I/O - space option ROM(s) driver

-
-
-

- - - - - -
ormis automatically included on all systems that have an ISA bus.
-
-
-

-

The driver scans at boot time the ISA I/O memory space for option - ROM(s) and claims them. Other drivers are thus precluded from using ISA I/O - memory that is on top of an option ROM.

-
-
-

-

This manual page was written by Nikolai - Saoukh - <nms@otdel-1.org>.

-
-
-

-

Due to the implementation of the resource manager, other drivers - cannot attach to the option ROM address range.

-
-
- - - - - -
December 15, 2000FreeBSD 15.0
diff --git a/static/freebsd/man4/ossl.4 4.html b/static/freebsd/man4/ossl.4 4.html deleted file mode 100644 index 8fdf2341..00000000 --- a/static/freebsd/man4/ossl.4 4.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
OSSL(4)Device Drivers ManualOSSL(4)
-
-
-

-

ossl — driver - using OpenSSL assembly routines

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device cryptodev -
-device ossl
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ossl_load="YES"
-
-
-
-

-

The OpenSSL distribution includes architecture-specific - implementations for some commonly used cryptographic algorithms. This driver - adds a wrapper around these routines permitting them to be used by in-kernel - cryptography consumers such as kernel TLS and IPsec.

-

The ossl driver includes - architecture-specific implementations for the following architectures:

-

-
    -
  • arm64
    • -
  • amd64
    • -
  • i386
    • -
-

The ossl driver includes support for the - following algorithms:

-

-
    -
  • AES-CBC
    • -
  • AES-GCM (amd64 only)
    • -
  • ChaCha20
    • -
  • ChaCha20-Poly1305 (RFC 8439)
    • -
  • Poly1305
    • -
  • SHA1
    • -
  • SHA1-HMAC
    • -
  • SHA2-224
    • -
  • SHA2-224-HMAC
    • -
  • SHA2-256
    • -
  • SHA2-256-HMAC
    • -
  • SHA2-384
    • -
  • SHA2-384-HMAC
    • -
  • SHA2-512
    • -
  • SHA2-512-HMAC
    • -
-
-
-

-

crypto(4), intro(4), - ipsec(4), crypto(7), - crypto(9)

-
-
-

-

The ossl driver first appeared in - FreeBSD 13.0.

-
-
- - - - - -
May 4, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/otus.4 3.html b/static/freebsd/man4/otus.4 3.html deleted file mode 100644 index 255bec88..00000000 --- a/static/freebsd/man4/otus.4 3.html +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - -
OTUS(4)Device Drivers ManualOTUS(4)
-
-
-

-

otus — Atheros - AR9170 USB IEEE 802.11a/b/g/n wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device otus -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_otus_load="YES"
-
-
-
-

-

The otus driver supports USB 2.0 wireless - network devices based on the Atheros AR9170 chipset.

-

The Atheros AR9170 is a draft-802.11n adapter that uses an - external radio to operate in either 2.4GHz only or 2.4GHz and 5GHz.

-

The AR9101 radio supports 1T1R operation in 2GHz only.

-

The AR9102 radio supports 2T2R operation in 2GHz only.

-

The AR9104 radio supports 2T2R operation both 2GHz and 5GHz.

-

These are the modes the otus driver can - operate in:

-
-
BSS mode
-
Also known as - - mode, this is used when associating with an access point, through which - all traffic passes. This mode is the default.
-
-

The otus driver can be configured to use - Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and - WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It - is strongly recommended that WEP not be used as the sole mechanism to secure - wireless communication, due to serious weaknesses in it.

-

The otus driver can be configured at - runtime with ifconfig(8).

-
-
-

-

The otus driver provides support for - Atheros AR9170 USB IEEE 802.11b/g/n wireless network adapters, - including:

-

-
    -
  • 3Com 3CRUSBN275
    • -
  • Arcadyan WN7512
    • -
  • CACE AirPcap Nx
    • -
  • D-Link DWA-130 rev D1
    • -
  • D-Link DWA-160 rev A1
    • -
  • D-Link DWA-160 rev A2
    • -
  • IO-Data WN-GDN/US2
    • -
  • NEC Aterm WL300NU-G
    • -
  • Netgear WNDA3100
    • -
  • Netgear WN111 v2
    • -
  • Planex GW-US300
    • -
  • SMC Networks SMCWUSB-N2
    • -
  • TP-Link TL-WN821N v1, v2
    • -
  • Ubiquiti SR71 USB
    • -
  • Unex DNUA-81
    • -
  • Z-Com UB81
    • -
  • Z-Com UB82
    • -
  • ZyXEL NWD-271N
    • -
-
-
-

-

The driver needs at least version 1.0 of the following firmware - files, which is loaded when an interface is attached:

-

-
-
-
/boot/kernel/otusfw-init.ko
-
 
-
/boot/kernel/otusfw-main.ko
-
 
-
-
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev otus0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev otus0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev otus0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-
-
%s: failed load firmware of file otusfw-main
-
For some reason, the driver was unable to read the microcode file from the - filesystem. The file might be missing or corrupted.
-
-
-
-

-

intro(1), netintro(4), - otusfw(4), usb(4), - wlan(4), arp(8), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The otus driver first appeared in - OpenBSD 4.6 and FreeBSD - 11.

-
-
-

-

The otus driver was written by - Damien Bergamini - <damien@openbsd.org> - and ported by Adrian Chadd - <adrian@freebsd.org>.

-
-
-

-

The otus driver only supports 802.11a/b/g - operations. 802.11n operation is not supported at this time.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/otusfw.4 4.html b/static/freebsd/man4/otusfw.4 4.html deleted file mode 100644 index 3ec9d2b5..00000000 --- a/static/freebsd/man4/otusfw.4 4.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - -
OTUSFW(4)Device Drivers ManualOTUSFW(4)
-
-
-

-

otusfw — Firmware - Module for AR9170 driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device otusfw
-

This will include the firmware image, AR9170, inside the kernel. - otus(4) will load the image into the chip.

-

Alternatively, to load the firmware images as a module at boot - time, place the following line in loader.conf(5):

-
-
otusfw_init_load="YES"
-otusfw_main_load="YES"
-
-
-
-

-

This module provides the firmware for the Atheros AR9170 based USB - WiFi adapters.

-
-
-

-

otus(4), firmware(9)

-
-
- - - - - -
September 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/ovpn.4 4.html b/static/freebsd/man4/ovpn.4 4.html deleted file mode 100644 index 71e2dd25..00000000 --- a/static/freebsd/man4/ovpn.4 4.html +++ /dev/null @@ -1,40 +0,0 @@ - - - - - - -
OVPN(4)Device Drivers ManualOVPN(4)
-
-
-

-

ovpn — OpenVPN DCO - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ovpn
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ovpn_load="YES"
-
-
-
-

-

The ovpn device driver provides support - for OpenVPN DCO. DCO, or Data Channel Offload, moves the OpenVPN data path - into the kernel. This can improve performance.

-

The ovpn interface is created - automatically by the OpenVPN daemon. It requires no configuration other than - that done by OpenVPN.

-
-
- - - - - -
April 22, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/ow.4 4.html b/static/freebsd/man4/ow.4 4.html deleted file mode 100644 index 0759cd1d..00000000 --- a/static/freebsd/man4/ow.4 4.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
OW(4)Device Drivers ManualOW(4)
-
-
-

-

ow — Dallas - Semiconductor 1-Wire bus

-
-
-

-

device ow

-
-
-

-

The ow module implements the Dallas - Semiconductor 1-Wire bus. It attaches to the owc(4) - driver, which implements the low-level signaling of the 1-Wire bus.

-
-
-

-

ow_temp(4), owc(4), - owll(9), own(9)

-
-
-

-

1-Wire is a registered trademark of Maxim Integrated Products, - Inc.

-
-
-

-

The ow driver first appeared in - FreeBSD 11.0.

-
-
-

-

The ow device driver and this manual page - were written by Warner Losh.

-
-
- - - - - -
July 20, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/ow_temp.4 3.html b/static/freebsd/man4/ow_temp.4 3.html deleted file mode 100644 index 2c32b344..00000000 --- a/static/freebsd/man4/ow_temp.4 3.html +++ /dev/null @@ -1,140 +0,0 @@ - - - - - - -
OW_TEMP(4)Device Drivers ManualOW_TEMP(4)
-
-
-

-

ow_temp — Dallas - Semiconductor 1-Wire Temperature sensor

-
-
-

-

device ow_temp

-
-
-

-

The ow_temp module supports many of the - 1-Wire temperature sensors.

-

The sensor is read periodically and the results returned via a - sysctl(3) as described below.

-
-
-

-

The ow_temp driver supports the following - temperature sensors:

-

- - - - - - - - - - - - - - - - - - - - - - - - - -
DS18201-Wire Digital Thermometer
DS18S20High-Precision 1-Wire Digital Thermometer
DS18B20Programmable Resolution 1-Wire Digital Thermometer
DS1822Econo 1-Wire Digital Thermometer
DS1825Programmable Resolution 1-Wire Digital Thermometer with 4-bit ID
MAX318201-Wire, Parasite-Power, Ambient Temperature Sensor
-

The driver supports Family codes 0x10, 0x22, 0x28, and 0x3b.

-
-
-

-

The ow_temp driver reports data via - sysctl(8) entries in the device's node in the - sysctl(8) tree:

-
-
temperature
-
The last temperature read, in milli-Kelvin.
-
badcrc
-
The number of CRC errors in reading the temperature from the device. Some - CRC errors are to be expected. High rates of CRC errors, however, - generally indicate a noisy environment, cabling issues, or too many - devices on the bus.
-
badread
-
The number of times a non-CRC error was encountered reading the - temperature from the card. This type of error is very rare.
-
reading_interval
-
The time, in ticks, between successive reads of the sensor.
-
parasite
-
This item is non-zero when the device is connected using its parasitic - power mode. It can also indicate a wiring error.
-
-

Temperatures are reported in milli-Kelvin, even though the - absolute accuracy is around 0.2 degrees for the good devices and around 1 - degree for cheaper devices. The devices report in steps of 0.0625 degrees. - The driver preserves the precision of the device's measurements in its - sysctl(8) reports. These devices often have a much higher - relative accuracy and repeatability than their absolute accuracy. This makes - them well suited for control loops that strive for stability and become - possible if the full precision is preserved.

-
-
-

-

ow(4), owc(4), - sysctl(8), owll(9), - own(9)

-
-
-

-

1-Wire is a registered trademark of Maxim Integrated Products, - Inc.

-
-
-

-

The ow_temp driver first appeared in - FreeBSD 11.0.

-
-
-

-

The ow_temp device driver and this manual - page were written by Warner Losh.

-
-
-

-

The parasitic mode of the devices does not work. It requires - support from the owc(4) driver that is unimplemented.

-

The ID bits from the - are not - recognized or reported.

-

The type of the device is not reported via - sysctl(8).

-

Alarm mode is not supported. It is not possible to set the low and - high alarm temperatures.

-

There is no way to write to the EEPROM.

-

“Convert Temperature” requests are sent directly to - the device. There is no way to use the broadcast ability of the 1-Wire bus - to do all the conversions in parallel.

-

It is not possible to set the precision on those devices that - support it.

-

The time to convert is fixed at 1 second, even though some devices - are faster.

-

There is no character device to supply a stream of readings to a - program. Programs interested in the temperature must poll the sysctl to get - the temperature.

-
-
- - - - - -
November 22, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/owc.4 3.html b/static/freebsd/man4/owc.4 3.html deleted file mode 100644 index 48cf8754..00000000 --- a/static/freebsd/man4/owc.4 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
OWC(4)Device Drivers ManualOWC(4)
-
-
-

-

owc — Dallas - Semiconductor 1-Wire Controller

-
-
-

-

device owc

-
-
-

-

The owc module implements Dallas - Semiconductor 1-Wire signaling. It attaches the ow(4) - driver 1-Wire bus protocol. The owc device - implements the Link Layer of the 1-Wire bus protocol stack.

-

Bit banging a pin on a gpiobus(4) is the only - supported controller. Both standard and overdrive transfer timings are - implemented. Strong pull-up functionality needed to support parasitic mode - is not implemented.

-

To enable 1-Wire for FDT systems requires modifying the DTS for - your board to add something like:

-
-
/ {
-	...
-	onewire {
-		compatible = "w1-gpio";
-		gpios = <&gpio 4 1>;
-	};
-	...
-};
-
-

The gpios property describes the GPIO pin the 1-Wire bus is - connected to. For more details about the gpios - property, please consult - /usr/src/sys/dts/bindings-gpio.txt.

-

On a device.hints(5) based system these values - are required for the owc:

-
-
hint.owc.%d.at
-
The gpiobus you are attaching to.
-
hint.owc.%d.pins
-
This is a bitmask that defines a pin on the - gpiobus that is to be used for the 1-Wire bus. For - instance, to configure pin 10, use the bitmask of 0x400. Please note that - this mask should have only one bit set (any other bits - i.e., pins - will - be ignored).
-
-
-
-

-

gpiobus(4), ow(4), - ow_temp(4), owll(9), - own(9)

-
-
-

-

1-Wire is a registered trademark of Maxim Integrated Products, - Inc.

-
-
-

-

The owc driver first appeared in - FreeBSD 11.0.

-
-
-

-

The owc device driver and this manual page - were written by Warner Losh.

-
-
-

-

The gpio driver implements timing by busy waiting, which can cause - a high load on slower systems.

-
-
-

-

Overdrive mode has not actually been tested.

-
-
- - - - - -
June 26, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/p9fs.4 3.html b/static/freebsd/man4/p9fs.4 3.html deleted file mode 100644 index 9048b593..00000000 --- a/static/freebsd/man4/p9fs.4 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
P9FS(4)Device Drivers ManualP9FS(4)
-
-
-

-

p9fs — 9P file - system

-
-
-

-

To use this filesystem, either add the following to the kernel - config:

-
options P9FS -
-device virtio_p9fs
-

Alternatively, load the driver as a kernel module, either at boot - time by adding the following to loader.conf(5):

-
-
virtio_p9fs_load="YES"
-
-

or on system startup using the command:

-

-
# sysrc - kld_list+=virtio_p9fs
-
-
-

-

The p9fs filesystem uses the 9P protocol - to mount a host file system directory into a bhyve(8) - guest. Multiple host directories can be accessed using the - bhyve(8) virtio-9p virtual PCI device. Each device is - configured with a share name and a host directory path. The share name can - be used with mount(8) to mount the host directory in the - guest:

-

-
# mount -t p9fs mysharename - /mnt
-

Host directories can be mounted on system startup using - fstab(5) like this:

-
-
mysharename	/mnt	p9fs	rw	0	0
-
-

Using p9fs as a root file system is - supported by adding the following to loader.conf(5):

-
-
vfs.root.mountfrom="p9fs:mysharename"
-
-
-
-

-

The 9P protocol relies on stateful file opens which map - protocol-level FIDs to host file descriptors. The FreeBSD vnode interface - doesn't support this and p9fs uses heuristics to - guess the right FID to use for file operations.

-

This can be confused by privilege lowering and does not guarantee - that the FID created for a given file open is always used, even if the - calling process is using the file descriptor from the original open - call.

-

In particular, accessing unlinked files using open file descriptor - may not work correctly. If p9fs is the root - filesystem, it is recommended to use with tmpfs(5) to - ensure that temporary files created in /tmp or - /var/tmp have the expected semantics.

-
-
-

-

fstab(5)

-
-
-

-

The 9P protocol first appeared in the Plan 9 operating system. - More recently, the protocol has been widely used with virtual machines to - allow the use of host file resources inside a guest VM.

-
-
-

-

This is derived from software released by Juniper Networks, Inc. - with many improvements and fixes from Steve - Wills.

-

This manual page was written by Doug - Rabson - <dfr@FreeBSD.org>.

-
-
-

-

A better name for this filesystem would be - 9pfs but for technical reasons, the names of - filesystems must be valid C identifiers. As a compromise, the filesystem is - named p9fs.

-
-
- - - - - -
November 7, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/padlock.4 3.html b/static/freebsd/man4/padlock.4 3.html deleted file mode 100644 index 42727371..00000000 --- a/static/freebsd/man4/padlock.4 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
PADLOCK(4)Device Drivers ManualPADLOCK(4)
-
-
-

-

padlock — driver - for the cryptographic functions and RNG in VIA C3, C7 and Eden - processors

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device padlock
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
padlock_load="YES"
-
-
-
-

-

The C3 and Eden processor series from VIA include hardware - acceleration for AES. The C7 series includes hardware acceleration for AES, - SHA1, SHA256 and RSA. All of the above processor series include a hardware - random number generator.

-

The padlock driver registers itself to - accelerate AES operations and, if available, HMAC/SHA1 and HMAC/SHA256 for - crypto(4). It also registers itself to accelerate other - HMAC algorithms, although there is no hardware acceleration for those - algorithms. This is only needed so padlock can work - with ipsec(4).

-

The hardware random number generator supplies data for the kernel - random(4) subsystem.

-
-
-

-

crypt(3), crypto(4), - intro(4), ipsec(4), - random(4), crypto(7), - crypto(9)

-
-
-

-

The padlock driver first appeared in - OpenBSD. The first FreeBSD - release to include it was FreeBSD 6.0.

-
-
-

-

The padlock driver with AES encryption - support was written by Jason Wright - <jason@OpenBSD.org>. - It was ported to FreeBSD and then extended to - support SHA1 and SHA256 by Pawel Jakub Dawidek - <pjd@FreeBSD.org>. - This manual page was written by Christian Brueffer - <brueffer@FreeBSD.org>.

-
-
- - - - - -
July 29, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/pass.4 3.html b/static/freebsd/man4/pass.4 3.html deleted file mode 100644 index c2a062ec..00000000 --- a/static/freebsd/man4/pass.4 3.html +++ /dev/null @@ -1,167 +0,0 @@ - - - - - - -
PASS(4)Device Drivers ManualPASS(4)
-
-
-

-

pass — CAM - application passthrough driver

-
-
-

-

device pass

-
-
-

-

The pass driver provides a way for - userland applications to issue CAM CCBs to the kernel.

-

Since the pass driver allows direct access - to the CAM subsystem, system administrators should exercise caution when - granting access to this driver. If used improperly, this driver can allow - userland applications to crash a machine or cause data loss.

-

The pass driver attaches to every SCSI and - ATA device found in the system. Since it attaches to every device, it - provides a generic means of accessing SCSI and ATA devices, and allows the - user to access devices which have no "standard" peripheral driver - associated with them.

-
-
-

-

It is only necessary to configure one pass - device in the kernel; pass devices are automatically - allocated as SCSI and ATA devices are found.

-
-
-

-
-
CAMIOCOMMAND union ccb *
-
This ioctl takes most kinds of CAM CCBs and passes them through to the CAM - transport layer for action. Note that some CCB types are not allowed - through the passthrough device, and must be sent through the - xpt(4) device instead. Some examples of xpt-only CCBs - are XPT_SCAN_BUS, XPT_DEV_MATCH, XPT_RESET_BUS, XPT_SCAN_LUN, XPT_ENG_INQ, - and XPT_ENG_EXEC. These CCB types have various attributes that make it - illogical or impossible to service them through the passthrough interface. -

If the user would like the kernel to do error recovery, the - CAM_PASS_ERR_RECOVER flag must be set on the - CCB, and the retry_count field set to the number of retries.

-
-
CAMGETPASSTHRU union ccb *
-
This ioctl takes an XPT_GDEVLIST CCB, and returns the passthrough device - corresponding to the device in question. Although this ioctl is available - through the pass driver, it is of limited use, - since the caller must already know that the device in question is a - passthrough device if they are issuing this ioctl. It is probably more - useful to issue this ioctl through the xpt(4) - device.
-
CAMIOQUEUE union ccb *
-
Queue a CCB to the pass driver to be executed - asynchronously. The caller may use select(2), - poll(2) or kevent(2) to receive - notification when the CCB has completed. -

This ioctl takes most CAM CCBs, but some CCB types are not - allowed through the pass device, and must be sent through the - xpt(4) device instead. Some examples of xpt-only CCBs - are XPT_SCAN_BUS, XPT_DEV_MATCH, XPT_RESET_BUS, XPT_SCAN_LUN, - XPT_ENG_INQ, and XPT_ENG_EXEC. These CCB types have various attributes - that make it illogical or impossible to service them through the - passthrough interface.

-

Although the CAMIOQUEUE ioctl is not - defined to take an argument, it does require a pointer to a union ccb. - It is not defined to take an argument to avoid an extra malloc and copy - inside the generic ioctl(2) handler.

-

The completed CCB will be returned via the - CAMIOGET ioctl. An error will only be returned - from the CAMIOQUEUE ioctl if there is an error - allocating memory for the request or copying memory from userland. All - other errors will be reported as standard CAM CCB status errors. Since - the CCB is not copied back to the user process from the pass driver in - the CAMIOQUEUE ioctl, the user's passed-in CCB - will not be modified. This is the case even with immediate CCBs. - Instead, the completed CCB must be retrieved via the - CAMIOGET ioctl and the status examined.

-

Multiple CCBs may be queued via the - CAMIOQUEUE ioctl at any given time, and they may - complete in a different order than the order that they were submitted. - The caller must take steps to identify CCBs that are queued and - completed. The periph_priv structure inside - struct ccb_hdr is available for userland use with the - CAMIOQUEUE and CAMIOGET - ioctls, and will be preserved across calls. Also, the periph_links - linked list pointers inside struct ccb_hdr are available for userland - use with the CAMIOQUEUE and - CAMIOGET ioctls and will be preserved across - calls.

-

If the user would like the kernel to do error recovery, the - CAM_PASS_ERR_RECOVER flag must be set on the - CCB, and the retry_count field set to the number of retries.

-
-
CAMIOGET union ccb *
-
Retrieve completed CAM CCBs queued via the - CAMIOQUEUE ioctl. An error will only be returned - from the CAMIOGET ioctl if the - pass driver fails to copy data to the user process - or if there are no completed CCBs available to retrieve. If no CCBs are - available to retrieve, errno will be set to - ENOENT. -

All other errors will be reported as standard CAM CCB status - errors.

-

Although the CAMIOGET ioctl is not - defined to take an argument, it does require a pointer to a union ccb. - It is not defined to take an argument to avoid an extra malloc and copy - inside the generic ioctl(2) handler.

-

The pass driver will report via select(2), - poll(2) or kevent(2) when a CCB has - completed. One CCB may be retrieved per CAMIOGET - call. CCBs may be returned in an order different than the order they - were submitted. So the caller should use the - periph_priv area inside the CCB header to store - pointers to identifying information.

-
-
-
-
-

-
-
/dev/passn
-
Character device nodes for the pass driver. There - should be one of these for each device accessed through the CAM - subsystem.
-
-
-
-

-

None.

-
-
-

-

kqueue(2), poll(2), - select(2), cam(3), - cam_cdbparse(3), cam(4), - cd(4), ctl(4), da(4), - sa(4), xpt(4), - camcontrol(8), camdd(8)

-
-
-

-

The CAM passthrough driver first appeared in - FreeBSD 3.0.

-
-
-

-

Kenneth Merry - <ken@FreeBSD.org>

-
-
- - - - - -
May 3, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/pca954x.4 3.html b/static/freebsd/man4/pca954x.4 3.html deleted file mode 100644 index 9872d842..00000000 --- a/static/freebsd/man4/pca954x.4 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
PCA954X(4)Device Drivers ManualPCA954X(4)
-
-
-

-

pca954x — driver - for PCA9548A I2C switch

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device pca954x -
-device iicmux -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pca954x_load="YES"
-
-
-
-

-

The pca954x driver supports the PCA9548A - I2C bus switch and compatible chips such as TCA9548A. It automatically - connects an upstream I2C bus to one of several downstream buses as needed - when slave devices on the downstream buses initiate I/O. More information on - the automatic switching behavior is available in - iicmux(4).

-
-
-

-

On an FDT(4) based system, an - pca954x device node is defined as a child node of - its upstream I2C bus. The children of the pca954x - node are additional I2C buses, which will have their own I2C slave devices - described in their child nodes.

-

The pca954x driver attaches to nodes where - the compatible property is set to one of

-
    -
  • "nxp,pca9548"
    • -
-

The pca954x driver supports the following - optional properties in addition to the standard I2C mux properties:

-
-
i2c-mux-idle-disconnect
-
if defined, forces the switch to disconnect all children in idle - state.
-
-
-
-

-

On a device.hints(5) based system, these values - are configurable for pca954x:

-
-
hint.pca954x.<unit>.at
-
The upstream iicbus(4) the - pca954x instance is attached to.
-
hint.pca954x.<unit>.chip_type
-
The type of the chip. At present, only "pca9548" is - supported.
-
-

When configured via hints, the driver automatically adds an - iicbus(4) instance for every downstream bus supported by - the chip. There is currently no way to indicate used versus unused - channels.

-
-
-

-

iicbus(4), iicmux(4)

-
-
-

-

The pca954x driver and this manual page - was written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
November 13, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/pccbb.4 4.html b/static/freebsd/man4/pccbb.4 4.html deleted file mode 100644 index 167d54cf..00000000 --- a/static/freebsd/man4/pccbb.4 4.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
PCCBB(4)Device Drivers ManualPCCBB(4)
-
-
-

-

pccbb — cardbus - bridge driver

-
-
-

-

device cbb -
- device pccard -
- device cardbus -
- device exca

-
-
-

-

The pccbb driver implements the Yenta - specification for CardBus bridges.

-

The following PCI cardbus and pcmcia bridges are supported:

-

-
    -
  • Cirrus Logic PD6832
    • -
  • Cirrus Logic PD6833
    • -
  • Cirrus Logic PD6834 -

    -
    • -
  • O2micro OZ6812
    • -
  • O2micro OZ6832
    • -
  • O2micro OZ6833
    • -
  • O2micro OZ6836
    • -
  • O2micro OZ6860
    • -
  • O2micro OZ6872
    • -
  • O2micro OZ6912
    • -
  • O2micro OZ6922
    • -
  • O2micro OZ6933
    • -
  • O2micro OZ6972
    • -
  • O2Micro OZ711E1
    • -
  • O2Micro OZ711M1
    • -
-
    -
  • Ricoh RL4C475
    • -
  • Ricoh RL4C476
    • -
  • Ricoh RL4C477
    • -
  • Ricoh RL4C478 -

    -
    • -
  • TI PCI-1031
    • -
  • TI PCI-1130
    • -
  • TI PCI-1131
    • -
  • TI PCI-1210
    • -
  • TI PCI-1211
    • -
  • TI PCI-1220
    • -
  • TI PCI-1221
    • -
  • TI PCI-1225
    • -
  • TI PCI-1250
    • -
  • TI PCI-1251
    • -
  • TI PCI-1251B
    • -
  • TI PCI-1260
    • -
  • TI PCI-1260B
    • -
  • TI PCI-1410
    • -
  • TI PCI-1420
    • -
  • TI PCI-1450
    • -
  • TI PCI-1451
    • -
  • TI PCI-1510
    • -
  • TI PCI-1515
    • -
  • TI PCI-1520
    • -
  • TI PCI-1530
    • -
  • TI PCI-1620
    • -
  • TI PCI-4410
    • -
  • TI PCI-4450
    • -
  • TI PCI-4451
    • -
  • TI PCI-4510
    • -
  • TI PCI-4520
    • -
  • TI PCI-[67]x[12]1
    • -
  • TI PCI-[67]x20
    • -
  • ENE CB710
    • -
  • ENE CB720
    • -
  • ENE CB1211
    • -
  • ENE CB1255
    • -
  • ENE CB1410
    • -
  • ENE CB1420 -

    -
    • -
  • Toshiba ToPIC95
    • -
  • Toshiba ToPIC95B
    • -
  • Toshiba ToPIC97
    • -
  • Toshiba ToPIC100
    • -
-
-
-

-

The driver supports the following tunable parameters, which may be - added to /boot/loader.conf or set via the - sysctl(8) command:

-
-
-
Non-zero values cause more verbose information to be printed to aid in - debugging problems with the bridge chipset.
-
-
-
-

-

cardbus(4), exca(4)

-
-
- - - - - -
July 21, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/pcf.4 4.html b/static/freebsd/man4/pcf.4 4.html deleted file mode 100644 index 02289f71..00000000 --- a/static/freebsd/man4/pcf.4 4.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
PCF(4)Device Drivers ManualPCF(4)
-
-
-

-

pcf — Philips I2C - bus controller

-
-
-

-

device pcf

-

In /boot/device.hints: -
- hint.pcf.0.at="isa" -
- hint.pcf.0.port="0x320" -
- hint.pcf.0.irq="5"

-

For one or more iicbus busses: -
- device iicbus

-
-
-

-

The - driver - provides support to the Philips PCF8584 I2C controller for the - iicbus(4) system.

-

The PCF8584 is an integrated circuit designed in CMOS technology - which serves as an interface between most standard parallel-bus - microcontrollers/microprocessors and the serial I2C-bus. The PCF8584 - provides both master and slave functions. Communication with I2C-bus is - carried out on a byte-wise basis using interrupt or polled handshake. It - controls all the I2C-bus specific sequences, protocol, arbitration and - timing. The PCF8584 allows parallel-bus systems to communicate - bidirectionally with the I2C-bus.

-
-
-

-

iicbus(4)

-
-
-

-

The pcf manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
August 6, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/pcf8574.4 3.html b/static/freebsd/man4/pcf8574.4 3.html deleted file mode 100644 index 0aea0ef5..00000000 --- a/static/freebsd/man4/pcf8574.4 3.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
PCF8574(4)Device Drivers ManualPCF8574(4)
-
-
-

-

pcf8574 — driver - for the PCF8574 8-bit I2C IO expander

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pcf8574 -
-device gpio -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pcf8574_load="YES"
-
-
-
-

-

The pcf8574 driver provides - gpiobus(4) control over 8 GPIO pins. The pins are - quasi-bidirectional. Only low output can be actively driven. High output is - equivalent to input.

-

On an FDT(4) based system the following - properties must be set:

-
-
compatible
-
Must be set to "nxp,pcf8574".
-
reg
-
The I2C address of pcf8574.
-
-

The DTS part for a pcf8574 device usually - looks like:

-
-
/ {
-
-	...
-	pcf8574@27 {
-		compatible = "nxp,pcf8574";
-		reg = <0x27>;
-	};
-};
-
-
-
-

-

fdt(4), gpiobus(4), - iicbus(4)

-
-
-

-

The pcf8574 driver and this manual page - was written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
-

-

The pcf8574 driver does not support the - input change interrupt that the hardware provides.

-
-
- - - - - -
November 6, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/pcf8591.4 4.html b/static/freebsd/man4/pcf8591.4 4.html deleted file mode 100644 index 4f76bd28..00000000 --- a/static/freebsd/man4/pcf8591.4 4.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
PCF8591(4)Device Drivers ManualPCF8591(4)
-
-
-

-

pcf8591 — driver - for the PCF8591 8-bit A/D and D/A converter

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pcf8591 -
-device iicbus
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pcf8591_load="YES"
-
-
-
-

-

The pcf8591 driver supports reading four - inputs and setting one output over I2C. The hardware supports configuring - the input lines as:

-
    -
  • four single-ended inputs
    • -
  • three differential inputs (one input line is shared between all three - inputs)
    • -
  • two single-ended inputs and one differential input
    • -
  • two differential inputs.
    • -
-

The pcf8591 driver reports data via - sysctl(8) entries in the device's node in the - sysctl(8) tree:

-
-
inputs.%d
-
The input level of the corresponding input in steps between 0 and 255. - Absolute voltage depends on an actual reference voltage.
-
-

On an FDT(4) based system the following - properties must be set:

-
-
compatible
-
Must be set to "nxp,pcf8591".
-
reg
-
The I2C address of pcf8591. It should be in the - range from 0x40 to 0x4f (7-bit).
-
-

The DTS part for a pcf8591 device usually - looks like:

-
-
/ {
-
-	...
-	pcf8591adc {
-		compatible = "nxp,pcf8591";
-		reg = <0x48>;
-	};
-};
-
-
-
-

-

fdt(4), iicbus(4), - sysctl(8)

-
-
-

-

The pcf8591 driver and this manual page - was written by Andriy Gapon - <avg@FreeBSD.org>.

-
-
-

-

The pcf8591 driver does not support - changing the input configuration. All input lines are configured as - single-ended inputs.

-

The pcf8591 driver does not support - setting the output. It is always disabled (tri-state).

-
-
- - - - - -
November 6, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/pchtherm.4 3.html b/static/freebsd/man4/pchtherm.4 3.html deleted file mode 100644 index 0e356d72..00000000 --- a/static/freebsd/man4/pchtherm.4 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
pchtherm(4)Device Drivers Manualpchtherm(4)
-
-
-

-

pchtherm — Intel - PCH thermal subsystem

-
-
-

-

device pci -
- device pchtherm

-
-
-

-

The pchtherm driver provides access to - sensor data and configuration installed in Intel PCH chipset. - pchtherm configuration register.

-

The access to pchtherm data is made via - the sysctl(8) interface:

-
-
dev.pchtherm.0.ctt: 115.0C
-dev.pchtherm.0.temperature: 28.5C
-dev.pchtherm.0.t2temp: 91.0C
-dev.pchtherm.0.t1temp: 86.0C
-dev.pchtherm.0.t0temp: 81.0C
-dev.pchtherm.0.tahv: 83.0C
-dev.pchtherm.0.talv: 30.0C
-dev.pchtherm.0.pmtime: 32
-dev.pchtherm.0.pmtemp: 50.0C
-dev.pchtherm.0.%parent: pci0
-dev.pchtherm.0.%pnpinfo: vendor=0x8086 device=0x9d31 subvendor=0x17aa subdevice=0x2256 class=0x118000
-dev.pchtherm.0.%location: slot=20 function=2 dbsf=pci0:0:20:2
-dev.pchtherm.0.%driver: pchtherm
-dev.pchtherm.0.%desc: Skylake PCH Thermal Subsystem
-dev.pchtherm.%parent:
-
-
-
dev.pchtherm.%d.temperature
-
Is the read-only value of the current temperature read by the sensor.
-
dev.pchtherm.%d.ctt
-
When the system reaches this temperature, it will shut down. This will not - appear when this feature is disabled and locked down.
-
dev.pchtherm.%d.t0temp
-
When temperature is under this value, system will be in T0 state.
-
dev.pchtherm.%d.t1temp
-
When temperature is over t0temp and under this - value, system will be in T1 state.
-
dev.pchtherm.%d.t2temp
-
When temperature is over t1temp and under this - value, system will be in T2 state. Over this value, system will be in T3 - state.
-
dev.pchtherm.%d.talv
-
Lower alart value. This will not appear when sensor enable bit is locked - down and the value is zero(which will show -50.0C).
-
dev.pchtherm.%d.tahv
-
High alart value. This will not appear when sensor enable bit is locked - down and the value is zero(which will show -50.0C).
-
dev.pchtherm.%d.pmtemp
-
Sensor Power management temperature. Under this temperature, sensor will - idle during pmtime second.
-
dev.pchtherm.%d.pmtime
-
Sensor idle duration when low temperature.
-
dev.pchtherm.%d.pch_hot_level
-
When temperature is higher than this value, PCHHOT# pin will assert. This - value is not appear when this feature is disabled and locked down.
-
-

Please check the PCH datasheets for more details.

-
-
-

-

All values are read-only. And it do not support event interrupt - for now.

-
-
-

-

sysctl(8)

-
-
-

-

The pchtherm driver first appeared in - FreeBSD 13.0.

-
-
-

-

The pchtherm driver and this manual page - were written by Takanori Watanabe - <takawata@FreeBSD.org>.

-
-
- - - - - -
March 15, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/pci.4 3.html b/static/freebsd/man4/pci.4 3.html deleted file mode 100644 index a892e232..00000000 --- a/static/freebsd/man4/pci.4 3.html +++ /dev/null @@ -1,580 +0,0 @@ - - - - - - -
PCI(4)Device Drivers ManualPCI(4)
-
-
-

-

pci — generic - PCI/PCIe bus driver

-
-
-

-

To compile the PCI bus driver into the kernel, place the following - line in your kernel configuration file:

-
device pci
-

To compile in support for Single Root I/O Virtualization - (SR-IOV):

-
options PCI_IOV
-

To compile in support for native PCI-express HotPlug:

-
options PCI_HP
-
-
-

-

The pci driver provides support for PCI - and PCIe devices in the kernel and limited access to PCI devices for - userland.

-

The pci driver provides a - /dev/pci character device that can be used by - userland programs to read and write PCI configuration registers. Programs - can also use this device to get a list of all PCI devices, or all PCI - devices that match various patterns.

-

Since the pci driver provides a write - interface for PCI configuration registers, system administrators should - exercise caution when granting access to the pci - device. If used improperly, this driver can allow userland applications to - crash a machine or cause data loss. In particular, driver only allows - operations on the opened /dev/pci to modify system - state if the file descriptor was opened for writing. For instance, the - PCIOCREAD and PCIOCBARMMAP - operations require a writeable descriptor, because reading a config register - or a BAR read access could have function-specific side-effects.

-

The pci driver implements the PCI bus in - the kernel. It enumerates any devices on the PCI bus and gives PCI client - drivers the chance to attach to them. It assigns resources to children, when - the BIOS does not. It takes care of routing interrupts when necessary. It - reprobes the unattached PCI children when PCI client drivers are dynamically - loaded at runtime. The pci driver also includes - support for PCI-PCI bridges, various platform-specific Host-PCI bridges, and - basic support for PCI VGA adapters.

-
-
-

-

The following ioctl(2) calls are supported by - the pci driver. They are defined in the header file - <sys/pciio.h>.

-
-
PCIOCGETCONF
-
This ioctl(2) takes a pci_conf_io - structure. It allows the user to retrieve information on all PCI devices - in the system, or on PCI devices matching patterns supplied by the user. - The call may set errno to any value specified in - either copyin(9) or copyout(9). The - pci_conf_io structure consists of a number of - fields: -
-
pat_buf_len
-
The length, in bytes, of the buffer filled with user-supplied - patterns.
-
num_patterns
-
The number of user-supplied patterns.
-
patterns
-
Pointer to a buffer filled with user-supplied patterns. - patterns is a pointer to - num_patterns - pci_match_conf structures. The - pci_match_conf structure consists of the - following elements: -
-
pc_sel
-
PCI domain, bus, slot and function.
-
pd_name
-
PCI device driver name.
-
pd_unit
-
PCI device driver unit number.
-
pc_vendor
-
PCI vendor ID.
-
pc_device
-
PCI device ID.
-
pc_class
-
PCI device class.
-
flags
-
The flags describe which of the fields the kernel should match - against. A device must match all specified fields in order to be - returned. The match flags are enumerated in the - pci_getconf_flags structure. Hopefully the - flag values are obvious enough that they do not need to described - in detail.
-
-
-
match_buf_len
-
Length of the matches buffer allocated by the - user to hold the results of the PCIOCGETCONF - query.
-
num_matches
-
Number of matches returned by the kernel.
-
matches
-
Buffer containing matching devices returned by the kernel. The items - in this buffer are of type pci_conf, which - consists of the following items: -
-
pc_sel
-
PCI domain, bus, slot and function.
-
pc_hdr
-
PCI header type.
-
pc_subvendor
-
PCI subvendor ID.
-
pc_subdevice
-
PCI subdevice ID.
-
pc_vendor
-
PCI vendor ID.
-
pc_device
-
PCI device ID.
-
pc_class
-
PCI device class.
-
pc_subclass
-
PCI device subclass.
-
pc_progif
-
PCI device programming interface.
-
pc_revid
-
PCI revision ID.
-
pd_name
-
Driver name.
-
pd_unit
-
Driver unit number.
-
pd_numa_domain
-
Device NUMA domain.
-
pc_reported_len
-
Length of the valid portion of the encompassing - pci_conf structure. This should always be - equivalent to the offset of the pc_spare - member.
-
pc_secbus
-
Secondary PCI bus number. (Only valid for bridge devices)
-
pc_subbus
-
Subordinate PCI bus number. (Only valid for bridge devices)
-
pc_spare
-
Reserved for future use.
-
-
-
offset
-
The offset is passed in by the user to tell the kernel where it should - start traversing the device list. The value passed out by the kernel - points to the record immediately after the last one returned. The user - may pass the value returned by the kernel in subsequent calls to the - PCIOCGETCONF ioctl. If the user does not - intend to use the offset, it must be set to zero.
-
generation
-
PCI configuration generation. This value only needs to be set if the - offset is set. The kernel will compare the current generation number - of its internal device list to the generation passed in by the user to - determine whether its device list has changed since the user last - called the PCIOCGETCONF ioctl. If the device - list has changed, a status of - PCI_GETCONF_LIST_CHANGED will be passed - back.
-
status
-
The status tells the user the disposition of his request for a device - list. The possible status values are: -
-
PCI_GETCONF_LAST_DEVICE
-
This means that there are no more devices in the PCI device list - matching the specified criteria after the ones returned in the - matches buffer.
-
PCI_GETCONF_LIST_CHANGED
-
This status tells the user that the PCI device list has changed - since his last call to the PCIOCGETCONF - ioctl and he must reset the offset and - generation to zero to start over at the - beginning of the list.
-
PCI_GETCONF_MORE_DEVS
-
This tells the user that his buffer was not large enough to hold - all of the remaining devices in the device list that match his - criteria.
-
PCI_GETCONF_ERROR
-
This indicates a general error while servicing the user's request. - If the pat_buf_len is not equal to - num_patterns times - (struct - pci_match_conf), errno will be set to - EINVAL.
-
-
-
-
-
PCIOCREAD
-
This ioctl(2) reads the PCI configuration registers - specified by the passed-in pci_io structure. The - pci_io structure consists of the following fields: -
-
pi_sel
-
A pcisel structure which specifies the domain, - bus, slot and function the user would like to query. If the specific - bus is not found, errno will be set to ENODEV and -1 returned from the - ioctl.
-
pi_reg
-
The PCI configuration registers the user would like to access.
-
pi_width
-
The width, in bytes, of the data the user would like to read. This - value may be either 1, 2, or 4. 3-byte reads and reads larger than 4 - bytes are not supported. If an invalid width is passed, errno will be - set to EINVAL.
-
pi_data
-
The data returned by the kernel.
-
-
-
PCIOCWRITE
-
This ioctl(2) allows users to write to the PCI - configuration registers specified in the passed-in - pci_io structure. The pci_io - structure is described above. The limitations on data width described for - reading registers, above, also apply to writing PCI configuration - registers.
-
PCIOCATTACHED
-
This ioctl(2) allows users to query if a driver is - attached to the PCI device specified in the passed-in - pci_io structure. The pci_io - structure is described above, however, the pi_reg - and pi_width fields are not used. The status of the - device is stored in the pi_data field. A value of 0 - indicates no driver is attached, while a value larger than 0 indicates - that a driver is attached.
-
PCIOCBARMMAP
-
This ioctl(2) command allows userspace processes to - mmap(2) the memory-mapped PCI BAR into its address - space. The input parameters and results are passed in the - pci_bar_mmap structure, which has the following - fields: -
-
void *pbm_map_base
-
Reports the established mapping base to the caller. If - PCIIO_BAR_MMAP_FIXED flag was specified, then - this field must be filled before the call with the desired address for - the mapping.
-
size_t pbm_map_length
-
Reports the mapped length of the BAR, in bytes. Its - size_t value is always multiple of machine - pages.
-
uint64_t pbm_bar_length
-
Reports length of the bar as exposed by the device.
-
int pbm_bar_off
-
Reports offset from the mapped base to the start of the first register - in the bar.
-
struct pcisel pbm_sel
-
Should be filled before the call. Describes the device to operate - on.
-
int pbm_reg
-
The BAR index to mmap.
-
int pbm_flags
-
Flags which augments the operation. See below.
-
int pbm_memattr
-
The caching attribute for the mapping. Typical values are - VM_MEMATTR_UNCACHEABLE for control registers - BARs, and VM_MEMATTR_WRITE_COMBINING for frame - buffers. Regular memory-like BAR should be mapped with - VM_MEMATTR_DEFAULT attribute.
-
-

Currently defined flags are:

-
-
PCIIO_BAR_MMAP_FIXED
-
The resulted mappings should be established at the address specified - by the pbm_map_base member, otherwise fail.
-
PCIIO_BAR_MMAP_EXCL
-
Must be used together with - PCIIO_BAR_MMAP_FIXED If the specified base - contains already established mappings, the operation fails instead of - implicitly unmapping them.
-
PCIIO_BAR_MMAP_RW
-
The requested mapping allows both reading and writing. Without the - flag, read-only mapping is established. Note that it is common for the - device registers to have side-effects even on reads.
-
PCIIO_BAR_MMAP_ACTIVATE
-
(Unimplemented) If the BAR is not activated, activate it in the course - of mapping. Currently attempt to mmap an inactive BAR results in - error.
-
-
-
PCIOCBARIO
-
This ioctl(2) command allows users to read from and - write to BARs. The I/O request parameters are passed in a - struct pci_bar_ioreq structure, which has the - following fields: -
-
struct pcisel pbi_sel
-
Describes the device to operate on.
-
int pbi_op
-
The operation to perform. Currently supported values are - PCIBARIO_READ and - PCIBARIO_WRITE.
-
uint32_t pbi_bar
-
The index of the BAR on which to operate.
-
uint32_t pbi_offset
-
The offset into the BAR at which to operate.
-
uint32_t pbi_width
-
The size, in bytes, of the I/O operation. 1-byte, 2-byte, 4-byte and - 8-byte perations are supported.
-
uint32_t pbi_value
-
For reads, the value is returned in this field. For writes, the caller - specifies the value to be written in this field. -

Note that this operation maps and unmaps the corresponding - resource and so is relatively expensive for memory BARs. The - PCIOCBARMMAP ioctl(2) can be - used to create a persistent userspace mapping for such BARs - instead.

-
-
-
-
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel, or stored in loader.conf(5). - The current value of these tunables can be examined at runtime via - sysctl(8) nodes of the same name. Unless otherwise - specified, each of these tunables is a boolean that can be enabled by - setting the tunable to a non-zero value.

-
-
hw.pci.clear_bars (Defaults - to 0)
-
Ignore any firmware-assigned memory and I/O port resources. This forces - the PCI bus driver to allocate resource ranges for memory and I/O port - resources from scratch.
-
hw.pci.clear_buses (Defaults - to 0)
-
Ignore any firmware-assigned bus number registers in PCI-PCI bridges. This - forces the PCI bus driver and PCI-PCI bridge driver to allocate bus - numbers for secondary buses behind PCI-PCI bridges.
-
hw.pci.clear_pcib (Defaults - to 0)
-
Ignore any firmware-assigned memory and I/O port resource windows in - PCI-PCI bridges. This forces the PCI-PCI bridge driver to allocate memory - and I/O port resources for resource windows from scratch. -

By default the PCI-PCI bridge driver will allocate windows - that contain the firmware-assigned resources devices behind the bridge. - In addition, the PCI-PCI bridge driver will suballocate from existing - window regions when possible to satisfy a resource request. As a result, - both hw.pci.clear_bars and - hw.pci.clear_pcib must be enabled to fully ignore - firmware-supplied resource assignments.

-
-
hw.pci.default_vgapci_unit - (Defaults to -1)
-
By default, the first PCI VGA adapter encountered by the system is assumed - to be the boot display device. This tunable can be set to choose a - specific VGA adapter by specifying the unit number of the associated - vgapciX device.
-
hw.pci.do_power_nodriver - (Defaults to 0)
-
Place devices into a low power state (D3) when a suitable device driver is - not found. Can be set to one of the following values: -
-
3
-
Powers down all PCI devices without a device driver.
-
2
-
Powers down most devices without a device driver. PCI devices with the - display, memory, and base peripheral device classes are not powered - down.
-
1
-
Similar to a setting of 2 except that storage controllers are also not - powered down.
-
0
-
All devices are left fully powered.
-
-

A PCI device must support power management to be powered down. - Placing a device into a low power state may not reduce power - consumption.

-
-
hw.pci.do_power_resume - (Defaults to 1)
-
Place PCI devices into the fully powered state when resuming either the - system or an individual device. Setting this to zero is discouraged as the - system will not attempt to power up non-powered PCI devices after a - suspend.
-
hw.pci.do_power_suspend - (Defaults to 1)
-
Place PCI devices into a low power state when suspending either the system - or individual devices. Normally the D3 state is used as the low power - state, but firmware may override the desired power state during a system - suspend.
-
hw.pci.enable_ari (Defaults - to 1)
-
Enable support for PCI-express Alternative RID Interpretation. This is - often used in conjunction with SR-IOV.
-
hw.pci.enable_io_modes - (Defaults to 1)
-
Enable memory or I/O port decoding in a PCI device's command register if - it has firmware-assigned memory or I/O port resources. The firmware (BIOS) - in some systems does not enable memory or I/O port decoding for some - devices even when it has assigned resources to the device. This enables - decoding for such resources during bus probe.
-
hw.pci.enable_msi (Defaults - to 1)
-
Enable support for Message Signalled Interrupts (MSI). MSI interrupts can - be disabled by setting this tunable to 0.
-
hw.pci.enable_msix (Defaults - to 1)
-
Enable support for extended Message Signalled Interrupts (MSI-X). MSI-X - interrupts can be disabled by setting this tunable to 0.
-
hw.pci.enable_pcie_ei - (Defaults to 0)
-
Enable support for PCI-express Electromechanical Interlock.
-
hw.pci.enable_pcie_hp - (Defaults to 1)
-
Enable support for native PCI-express HotPlug.
-
hw.pci.honor_msi_blacklist - (Defaults to 1)
-
MSI and MSI-X interrupts are disabled for certain chipsets known to have - broken MSI and MSI-X implementations when this tunable is set. It can be - set to zero to permit use of MSI and MSI-X interrupts if the chipset match - is a false positive.
-
hw.pci.iov_max_config - (Defaults to 1MB)
-
The maximum amount of memory permitted for the configuration parameters - used when creating Virtual Functions via SR-IOV. This tunable can also be - changed at runtime via sysctl(8).
-
hw.pci.realloc_bars - (Defaults to 0)
-
Attempt to allocate a new resource range during the initial device scan - for any memory or I/O port resources with firmware-assigned ranges that - conflict with another active resource.
-
hw.pci.usb_early_takeover - (Defaults to 1 on amd64 and i386)
-
Disable legacy device emulation of USB devices during the initial device - scan. Set this tunable to zero to use USB devices via legacy emulation - when using a custom kernel without USB controller drivers.
-
hw.pci<D>.<B>.<S>.INT<P>.irq
-
These tunables can be used to override the interrupt routing for legacy - PCI INTx interrupts. Unlike other tunables in this list, these do not have - corresponding sysctl nodes. The tunable name includes the address of the - PCI device as well as the pin of the desired INTx IRQ to override: -
-
<D>
-
The domain (or segment) of the PCI device in decimal.
-
<B>
-
The bus address of the PCI device in decimal.
-
<S>
-
The slot of the PCI device in decimal.
-
<P>
-
The interrupt pin of the PCI slot to override. One of - ‘A’, - ‘B’, - ‘C’, or - ‘D’.
-
-

The value of the tunable is the raw IRQ value to use for the - INTx interrupt pin identified by the tunable name. Mapping of IRQ values - to platform interrupt sources is machine dependent.

-
-
-
-
-

-

You can wire the device unit at a given location with - device.hints(5).

-
-

-

Devices may be wired to a Bus / Slot / Function (BSF) address. - This is the form reported by pciconf(8) Entries of the - form - hints.<name>.<unit>.at="pci<B>:<S>:<F>" - or - hints.<name>.<unit>.at="pci<D>:<B>:<S>:<F>" - will force the driver name to probe and attach at unit - unit for any PCI device found to match the - specification, where:

-
-
<D>
-
The domain (or segment) of the PCI device in decimal. Defaults to 0 if - unspecified.
-
<B>
-
The bus address of the PCI device in decimal.
-
<S>
-
The slot of the PCI device in decimal.
-
<F>
-
The function of the PCI device in decimal.
-
-

The code to do the matching requires an exact string match. Do not - specify the angle brackets (< >) in the hints file. Wiring multiple - devices to the same name and - unit produces undefined results.

-
-
-

-

Given the following lines in - /boot/device.hints:

-
-
hint.nvme.3.at="pci6:0:0"
-hint.igb.8.at="pci14:0:0"
-
-

If there is a device that supports igb(4) at PCI - bus 14 slot 0 function 0, then it will be assigned igb8 for probe and - attach. Likewise, if there is an nvme(4) device at PCI bus - 6 slot 0 function 0, then it will be assigned nvme3 for probe and attach. If - another type of card is in either of these locations, the name and unit of - that card will be the default names and will be unaffected by these hints. - If other igb or nvme cards are located elsewhere, they will be assigned - their unit numbers sequentially, skipping the unit numbers that have 'at' - hints.

-
-
-

-

While simple to locate where to place a device for BSF wiring, the - bus number of that is not invariant. Any number of changes to the devices - within the system can cause this value to vary from boot to boot. The UEFI - Standard defines a device path that's based only on the invariant parts of - the address: The root complex (domain), the slot number and the function. - These paths are hard to construct by hand, please see - devctl(8) ‘getpath’ - command with a ‘UEFI’ locator. The above - example could also be expressed as

-
-
hint.nvme.3.at="PciRoot(0x2)/Pci(0x1,0x3)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)"
-hint.nvme.8.at="PciRoot(0x1)/Pci(0x2,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)"
-
-

The advantage of this notation is that you can specify the exact - location a device will be at. For deployments of multiple systems with the - same configuration, this can be helpful in managing the devices. However, - even slight variation in motherboards can cause the path to change - substantially. It is also less natural to think of the UEFI Device Paths - since little else will report it.

-
-
-
-

-
-
/dev/pci
-
Character device for the pci driver.
-
-
-
-

-

device.hints(5) pciconf(8)

-
-
-

-

The pci driver (not the kernel's PCI - support code) first appeared in FreeBSD 2.2, and was - written by Stefan Esser and Garrett Wollman. Support for device listing and - matching was re-implemented by Kenneth Merry, and first appeared in - FreeBSD 3.0.

-
-
-

-

Kenneth Merry - <ken@FreeBSD.org>

-
-
-

-

It is not possible for users to specify an accurate offset into - the device list without calling the PCIOCGETCONF at - least once, since they have no way of knowing the current generation number - otherwise. This probably is not a serious problem, though, since users can - easily narrow their search by specifying a pattern or patterns for the - kernel to match against.

-
-
- - - - - -
March 10, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/pcib.4 3.html b/static/freebsd/man4/pcib.4 3.html deleted file mode 100644 index f9c52ba7..00000000 --- a/static/freebsd/man4/pcib.4 3.html +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - -
PCIB(4)Device Drivers ManualPCIB(4)
-
-
-

-

pcib — PCI bridge - driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device pci
-
-
-

-

The pcib driver provides for host and PCI - bridges in a PCI system.

-
-
-

-

This man page is too short.

-
-
- - - - - -
January 18, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/pcm.4 3.html b/static/freebsd/man4/pcm.4 3.html deleted file mode 100644 index 839d7ab8..00000000 --- a/static/freebsd/man4/pcm.4 3.html +++ /dev/null @@ -1,541 +0,0 @@ - - - - - - -
SOUND(4)Device Drivers ManualSOUND(4)
-
-
-

-

sound, pcm, - snd — - FreeBSD PCM audio device - infrastructure

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device sound
-
-
-

-

The sound driver is the main component of - the FreeBSD sound system. It works in conjunction - with a bridge device driver on supported devices and provides PCM audio - record and playback once it attaches. Each bridge device driver supports a - specific set of audio chipsets and needs to be enabled together with the - sound driver. PCI and ISA PnP audio devices identify - themselves so users are usually not required to add anything to - /boot/device.hints.

-

Some of the main features of the sound - driver are: multichannel audio, per-application volume control, dynamic - mixing through virtual sound channels, true full duplex operation, bit - perfect audio, rate conversion and low latency modes.

-

The sound driver is enabled by default, - along with several bridge device drivers. Those not enabled by default can - be loaded during runtime with kldload(8) or during boot - via loader.conf(5). The following bridge device drivers - are available:

-

- -

Refer to the manual page for each bridge device driver for driver - specific settings and information.

-
-

-

In general, the module snd_foo corresponds - to device snd_foo and can be loaded by the boot - loader(8) via loader.conf(5) or from the - command line using the kldload(8) utility. Options which - can be specified in /boot/loader.conf include:

-
-
-
snd_driver_load
-
(“NO”) If set to - “YES”, this option loads all - available drivers.
-
snd_hda_load
-
(“NO”) If set to - “YES”, only the Intel High - Definition Audio bridge device driver and dependent modules will be - loaded.
-
snd_foo_load
-
(“NO”) If set to - “YES”, load driver for card/chipset - foo.
-
-
-

To define default values for the different mixer channels, set the - channel to the preferred value using hints, e.g.: - hint.pcm.0.line="0". - This will mute the input channel per default.

-
-
-

-

Multichannel audio, popularly referred to as “surround - sound” is supported and enabled by default. The - FreeBSD multichannel matrix processor supports up to - 18 interleaved channels, but the limit is currently set to 8 channels (as - commonly used for 7.1 surround sound). The internal matrix mapping can - handle reduction, expansion or re-routing of channels. This provides a base - interface for related multichannel - () - support. Multichannel audio works both with and without VCHANs.

-

Most bridge device drivers are still missing multichannel - matrixing support, but in most cases this should be trivial to implement. - Use the dev.pcm.%d.[play|rec].vchanformat - sysctl(8) to adjust the number of channels used. The - current multichannel interleaved structure and arrangement was implemented - by inspecting various popular UNIX applications. There were no single - standard, so much care has been taken to try to satisfy each possible - scenario, despite the fact that each application has its own conflicting - standard.

-
-
-

-

The Parametric Software Equalizer (EQ) enables the use of - “tone” controls (bass and treble). Commonly used for ear-candy - or frequency compensation due to the vast difference in hardware quality. EQ - is disabled by default, but can be enabled with the - hint.pcm.%d.eq tunable.

-
-
-

-

Each device can optionally support more playback and recording - channels than physical hardware provides by using “virtual - channels” or VCHANs. VCHAN options can be configured via the - sysctl(8) interface but can only be manipulated while the - device is inactive.

-
-
-

-

FreeBSD supports independent and - individual volume controls for each active application, without touching the - master sound volume. This is sometimes referred to - as Volume Per Channel (VPC). The VPC feature is enabled by default.

-
-
-

-

The following loader tunables are used to set driver configuration - at the loader(8) prompt before booting the kernel, or they - can be stored in /boot/loader.conf in order to - automatically set them before booting the kernel. It is also possible to use - kenv(1) to change these tunables before loading the - sound driver. The following tunables can not be - changed during runtime using sysctl(8).

-
-
hint.pcm.%d.eq
-
Set to 1 or 0 to explicitly enable (1) or disable (0) the equalizer. - Requires a driver reload if changed. Enabling this will make bass and - treble controls appear in mixer applications. This tunable is undefined by - default. Equalizing is disabled by default.
-
hint.pcm.%d.vpc
-
Set to 1 or 0 to explicitly enable (1) or disable (0) the VPC feature. - This tunable is undefined by default. VPC is however enabled by - default.
-
-
-
-

-

There are a number of sysctl(8) variables - available which can be modified during runtime. These values can also be - stored in /etc/sysctl.conf in order to automatically - set them during the boot process. hw.snd.* are global - settings and dev.pcm.* are device specific.

-
-
hw.snd.compat_linux_mmap
-
Linux mmap(2) compatibility. The following values are - supported (default is 0): -
-
-1
-
Force disabling/denying PROT_EXEC mmap(2) - requests.
-
0
-
Auto detect proc/ABI type, allow mmap(2) for Linux - applications, and deny for everything else.
-
1
-
Always allow PROT_EXEC page mappings.
-
-
-
hw.snd.default_auto
-
Automatically assign the default sound unit. The following values are - supported (default is 1): -
-
0
-
Do not assign the default sound unit automatically.
-
1
-
Use the best available sound device based on playing and recording - capabilities of the device.
-
2
-
Use the most recently attached device.
-
-
-
hw.snd.default_unit
-
Default sound card for systems with multiple sound cards. When using - devfs(4), the default device for - /dev/dsp. Equivalent to a symlink from - /dev/dsp to - /dev/dsp${hw.snd.default_unit}.
-
hw.snd.feeder_eq_exact_rate
-
Only certain rates are allowed for precise processing. The default - behavior is however to allow sloppy processing for all rates, even the - unsupported ones. Enable to toggle this requirement and only allow - processing for supported rates.
-
hw.snd.feeder_rate_max
-
Maximum allowable sample rate.
-
hw.snd.feeder_rate_min
-
Minimum allowable sample rate.
-
hw.snd.feeder_rate_polyphase_max
-
Adjust to set the maximum number of allowed polyphase entries during the - process of building resampling filters. Disabling polyphase resampling has - the benefit of reducing memory usage, at the expense of slower and lower - quality conversion. Only applicable when the SINC interpolator is used. - Default value is 183040. Set to 0 to disable polyphase resampling.
-
hw.snd.feeder_rate_quality
-
Sample rate converter quality. Default value is 1, linear interpolation. - Available options include: -
-
0
-
Zero Order Hold, ZOH. Very fast, but with poor quality.
-
1
-
Linear interpolation. Fast, quality is subject to personal preference. - Technically the quality is poor however, due to the lack of - anti-aliasing filtering.
-
2
-
Bandlimited SINC interpolator. Implements polyphase banking to boost - the conversion speed, at the cost of memory usage, with multiple high - quality polynomial interpolators to improve the conversion accuracy. - 100% fixed point, 64bit accumulator with 32bit coefficients and high - precision sample buffering. Quality values are 100dB stopband, 8 taps - and 85% bandwidth.
-
3
-
Continuation of the bandlimited SINC interpolator, with 100dB - stopband, 36 taps and 90% bandwidth as quality values.
-
4
-
Continuation of the bandlimited SINC interprolator, with 100dB - stopband, 164 taps and 97% bandwidth as quality values.
-
-
-
hw.snd.feeder_rate_round
-
Sample rate rounding threshold, to avoid large prime division at the cost - of accuracy. All requested sample rates will be rounded to the nearest - threshold value. Possible values range between 0 (disabled) and 500. - Default is 25.
-
hw.snd.latency
-
Configure the buffering latency. Only affects applications that do not - explicitly request blocksize / fragments. This tunable provides finer - granularity than the hw.snd.latency_profile tunable. - Possible values range between 0 (lowest latency) and 10 (highest - latency).
-
hw.snd.latency_profile
-
Define sets of buffering latency conversion tables for the - hw.snd.latency tunable. A value of 0 will use a low - and aggressive latency profile which can result in possible underruns if - the application cannot keep up with a rapid irq rate, especially during - high workload. The default value is 1, which is considered a moderate/safe - latency profile.
-
hw.snd.vchans_enable
-
Global VCHAN setting to enable (1) or disable (0) VCHANs. This setting can - be overridden for an individual device by using the - dev.pcm.%d.[play|rec].vchans tunables. Default is - enabled.
-
hw.snd.report_soft_formats
-
Controls the internal format conversion if it is available transparently - to the application software. When disabled or not available, the - application will only be able to select formats the device natively - supports.
-
hw.snd.report_soft_matrix
-
Enable seamless channel matrixing even if the hardware does not support - it. Makes it possible to play multichannel streams even with a simple - stereo sound card.
-
hw.snd.verbose
-
Level of verbosity for the /dev/sndstat device. - Higher values include more output and the highest level, four, should be - used when reporting problems. Other options include: -
-
0
-
Installed devices and their allocated bus resources.
-
1
-
The number of playback, record, virtual channels, and flags per - device.
-
2
-
Channel information per device including the channel's current format, - speed, and pseudo device statistics such as buffer overruns and buffer - underruns.
-
3
-
File names and versions of the currently loaded sound modules.
-
4
-
Various messages intended for debugging.
-
-
-
hw.snd.vpc_0db
-
Default value for sound volume. Increase to give - more room for attenuation control. Decrease for more amplification, with - the possible cost of sound clipping.
-
hw.snd.vpc_autoreset
-
When a channel is closed the channel volume will be reset to 0db. This - means that any changes to the volume will be lost. Enabling this will - preserve the volume, at the cost of possible confusion when applications - tries to re-open the same device.
-
hw.snd.vpc_mixer_bypass
-
The recommended way to use the VPC feature is to teach applications to use - the correct - (): - SNDCTL_DSP_GETPLAYVOL, - SNDCTL_DSP_SETPLAYVOL, - SNDCTL_DSP_SETRECVOL, - SNDCTL_DSP_SETRECVOL. This is however not always - possible. Enable this to allow applications to use their own existing - mixer logic to control their own channel volume.
-
hw.snd.vpc_reset
-
Enable to restore all channel volumes back to the default value of - 0db.
-
dev.pcm.%d.bitperfect
-
Enable or disable bitperfect mode. When enabled, channels will skip all - dsp processing, such as channel matrixing, rate converting and equalizing. - The pure sound stream will be fed directly to the - hardware. If VCHANs are enabled, the bitperfect mode will use the VCHAN - format/rate as the definitive format/rate target. The recommended way to - use bitperfect mode is to disable VCHANs and enable this sysctl. Default - is disabled.
-
dev.pcm.%d.[play|rec].vchans
-
Enable (1) or disable (0) VCHANs. Default is enabled.
-
dev.pcm.%d.[play|rec].vchanformat
-
Format for VCHAN mixing. All playback paths will be converted to this - format before the mixing process begins. By default only 2 channels are - enabled. Available options include: -
-
s16le:1.0
-
Mono.
-
s16le:2.0
-
Stereo, 2 channels (left, right).
-
s16le:2.1
-
3 channels (left, right, LFE).
-
s16le:3.0
-
3 channels (left, right, rear center).
-
s16le:4.0
-
Quadraphonic, 4 channels (front/rear left and right).
-
s16le:4.1
-
5 channels (4.0 + LFE).
-
s16le:5.0
-
5 channels (4.0 + center).
-
s16le:5.1
-
6 channels (4.0 + center + LFE).
-
s16le:6.0
-
6 channels (4.0 + front/rear center).
-
s16le:6.1
-
7 channels (6.0 + LFE).
-
s16le:7.1
-
8 channels (4.0 + center + LFE + left and right side).
-
-
-
dev.pcm.%d.[play|rec].vchanmode
-
VCHAN format/rate selection. Available options include: -
-
fixed
-
Channel mixing is done using fixed format/rate. Advanced operations - such as digital passthrough will not work. Can be considered as a - “legacy” mode. This is the default mode for hardware - channels which lack support for digital formats.
-
passthrough
-
Channel mixing is done using fixed format/rate, but advanced - operations such as digital passthrough also work. All channels will - produce sound as usual until a digital format playback is requested. - When this happens all other channels will be muted and the latest - incoming digital format will be allowed to pass through undisturbed. - Multiple concurrent digital streams are supported, but the latest - stream will take precedence and mute all other streams.
-
adaptive
-
Works like the “passthrough” mode, but is a bit smarter, - especially for multiple sound channels with - different format/rate. When a new channel is about to start, the - entire list of virtual channels will be scanned, and the channel with - the best format/rate (usually the highest/biggest) will be selected. - This ensures that mixing quality depends on the best channel. The - downside is that the hardware DMA mode needs to be restarted, which - may cause annoying pops or clicks.
-
-
-
dev.pcm.%d.[play|rec].vchanrate
-
Sample rate speed for VCHAN mixing. All playback paths will be converted - to this sample rate before the mixing process begins.
-
dev.pcm.%d.polling
-
Experimental polling mode support where the driver operates by querying - the device state on each tick using a callout(9) - mechanism. Disabled by default and currently only available for a few - device drivers.
-
-
-
-

-

Channel statistics are only kept while the device is open. So with - situations involving overruns and underruns, consider the output while the - errant application is open and running.

-
-
-

-

The driver supports most of the OSS - ioctl() functions, and most applications work - unmodified. A few differences exist, while memory mapped playback is - supported natively and in Linux emulation, memory mapped recording is not - due to VM system design. As a consequence, some applications may need to be - recompiled with a slightly modified audio module. See - <sys/soundcard.h> for a - complete list of the supported ioctl() - functions.

-
-
-
-

-

The sound drivers may create the following - device nodes:

-

-
-
/dev/dsp%d
-
Audio device. The number represents the unit number of the device.
-
/dev/dsp
-
Alias of /dev/dsp${hw.snd.default_unit}. Available - only if hw.snd.basename_clone is set.
-
/dev/sndstat
-
Current sound status, including all channels and - drivers.
-
-

All sound devices are listed in - /dev/sndstat. Additional messages are sometimes - recorded when the device is probed and attached, these messages can be - viewed with the dmesg(8) utility.

-
-
-

-

Use the sound metadriver to load all sound - bridge device drivers at once (for example if it is unclear which the - correct driver to use is):

-

-
kldload snd_driver
-

Load a specific bridge device driver, in this case the Intel High - Definition Audio driver:

-

-
kldload snd_hda
-

Check the status of all detected sound - devices:

-

-
cat /dev/sndstat
-

Change the default sound device, in this case to the second - device. This is handy if there are multiple sound - devices available:

-

-
mixer -d pcm1
-
-
-

-
-
pcm%d:play:%d:dsp%d.p%d: play interrupt timeout, channel dead
-
The hardware does not generate interrupts to serve incoming (play) or - outgoing (record) data.
-
unsupported subdevice XX
-
A device node is not created properly.
-
-
-
-

-

devfs(4), snd_ai2s(4), - snd_als4000(4), snd_atiixp(4), - snd_cmi(4), snd_cs4281(4), - snd_csa(4), snd_davbus(4), - snd_emu10k1(4), snd_emu10kx(4), - snd_envy24(4), snd_envy24ht(4), - snd_es137x(4), snd_fm801(4), - snd_hda(4), snd_hdsp(4), - snd_hdspe(4), snd_ich(4), - snd_maestro3(4), snd_neomagic(4), - snd_solo(4), snd_spicds(4), - snd_t4dwave(4), snd_uaudio(4), - snd_via8233(4), snd_via82c686(4), - snd_vibes(4), device.hints(5), - loader.conf(5), dmesg(8), - kldload(8), mixer(8), - sysctl(8)

-

Cookbook formulae for audio EQ - biquad filter coefficients (Audio-EQ-Cookbook.txt), by Robert - Bristow-Johnson, - https://www.musicdsp.org/en/latest/Filters/197-rbj-audio-eq-cookbook.html.

-

Julius O'Smith's Digital Audio - Resampling, - http://ccrma.stanford.edu/~jos/resample/.

-

Polynomial Interpolators for - High-Quality Resampling of Oversampled Audio, by Olli Niemitalo, - http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf.

-

The OSS API, - http://www.opensound.com/pguide/oss.pdf.

-
-
-

-

The sound device driver first appeared in - FreeBSD 2.2.6 as pcm, - written by Luigi Rizzo. It was later rewritten in - FreeBSD 4.0 by Cameron - Grant. The API evolved from the VOXWARE standard which later became - OSS standard.

-
-
-

-

Luigi Rizzo - <luigi@iet.unipi.it> - initially wrote the pcm device driver and this - manual page. Cameron Grant - <gandalf@vilnya.demon.co.uk> - later revised the device driver for FreeBSD 4.0. - Seigo Tanimura - <tanimura@r.dl.itc.u-tokyo.ac.jp> - revised this manual page. It was then rewritten for FreeBSD - 5.2.

-
-
-

-

Some features of your sound card (e.g., global volume control) - might not be supported on all devices.

-

Some audio devices might refuse to work properly unless the sample - rate is configured the same for both recording and playback, even if only - simplex is used. See the - dev.pcm.%d.[play|rec].vchanrate sysctls.

-
-
- - - - - -
February 15, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/pf.4 3.html b/static/freebsd/man4/pf.4 3.html deleted file mode 100644 index f9e8f3ee..00000000 --- a/static/freebsd/man4/pf.4 3.html +++ /dev/null @@ -1,1055 +0,0 @@ - - - - - - -
PF(4)Device Drivers ManualPF(4)
-
-
-

-

pf — packet - filter

-
-
-

-

device pf -
- options PF_DEFAULT_TO_DROP

-

In rc.conf(5): -
- pf_enable="YES"

-

In loader.conf(5): -
- net.pf.states_hashsize -
- net.pf.source_nodes_hashsize -
- net.pf.rule_tag_hashsize -
- net.pf.udpendpoint_hashsize -
- net.pf.default_to_drop

-

In sysctl.conf(5): -
- net.pf.request_maxcount -
- net.pf.filter_local

-
-
-

-

Packet filtering takes place in the kernel. A pseudo-device, - /dev/pf, allows userland processes to control the - behavior of the packet filter through an ioctl(2) - interface. There are commands to enable and disable the filter, load - rulesets, add and remove individual rules or state table entries, and - retrieve statistics. The most commonly used functions are covered by - pfctl(8).

-

Manipulations like loading a ruleset that involve more - than a single ioctl(2) call require a so-called - , which - prevents the occurrence of multiple concurrent manipulations.

-

Fields of ioctl(2) parameter structures that - refer to packet data (like addresses and ports) are generally expected in - network byte-order.

-

Rules and address tables are contained in so-called - . When - servicing an ioctl(2) request, if the anchor field of the - argument structure is empty, the kernel will use the default anchor (i.e., - the main ruleset) in operations. Anchors are specified by name and may be - nested, with components separated by ‘/’ characters, similar - to how file system hierarchies are laid out. The final component of the - anchor path is the anchor under which operations will be performed.

-
-
-

-

The following variables can be entered at the - loader(8) prompt, set in loader.conf(5), - sysctl.conf(5), or changed at runtime with - sysctl(8):

-
-
net.pf.filter_local
-
This tells pf to also filter on the loopback - output hook. This is typically used to allow redirect rules to adjust the - source address.
-
net.pf.request_maxcount
-
The maximum number of items in a single ioctl call.
-
-
-
-

-

The following tunables can be entered at the - loader(8) prompt, or set in - loader.conf(5):

-
-
net.pf.states_hashsize
-
Size of hash table that stores states. Should be power of 2. Default value - is 131072.
-
net.pf.source_nodes_hashsize
-
Size of hash table that stores source nodes. Should be power of 2. Default - value is 32768.
-
net.pf.rule_tag_hashsize
-
Size of the hash table that stores tags.
-
net.pf.udpendpoint_hashsize
-
Size of hash table that store UDP endpoint mappings. Should be power of 2. - Default value is 32768.
-
net.pf.default_to_drop
-
This value overrides options PF_DEFAULT_TO_DROP - from kernel configuration file.
-
net.pf.filter_local
-
This tells pf to also filter on the loopback - output hook. This is typically used to allow redirect rules to adjust the - source address.
-
net.pf.request_maxcount
-
The maximum number of items in a single ioctl call.
-
-

Read only sysctl(8) variables with matching - names are provided to obtain current values at runtime.

-
-
-

-

The following options in the kernel configuration file are related - to pf operation:

-

-
-
-
Change default policy to drop by default
-
-
-
-

-

pf supports the following - ioctl(2) commands, available through - ⟨net/pfvar.h⟩:

-
-
-
Start the packet filter.
-
-
Stop the packet filter.
-
-
Start the ALTQ bandwidth control system (see - altq(9)).
-
-
Stop the ALTQ bandwidth control system.
-
- struct pfioc_pooladdr *pp
-
-
- 
struct pfioc_pooladdr {
-	u_int32_t		action;
-	u_int32_t		ticket;
-	u_int32_t		nr;
-	u_int32_t		r_num;
-	u_int8_t		r_action;
-	u_int8_t		r_last;
-	u_int8_t		af;
-	char			anchor[MAXPATHLEN];
-	struct pf_pooladdr	addr;
-};
-
-

Clear the buffer address pool and get a - ticket for subsequent - DIOCADDADDR, - DIOCADDRULE, and - DIOCCHANGERULE calls.

-
-
- struct pfioc_pooladdr *pp
-
-

Add the pool address addr to the buffer - address pool to be used in the following - DIOCADDRULE or - DIOCCHANGERULE call. All other members of the - structure are ignored.

-
-
- struct pfioc_rule *pr
-
-
- 
struct pfioc_rule {
-	u_int32_t	action;
-	u_int32_t	ticket;
-	u_int32_t	pool_ticket;
-	u_int32_t	nr;
-	char		anchor[MAXPATHLEN];
-	char		anchor_call[MAXPATHLEN];
-	struct pf_rule	rule;
-};
-
-

Add rule at the end of the inactive - ruleset. This call requires a ticket obtained - through a preceding DIOCXBEGIN call and a - pool_ticket obtained through a - DIOCBEGINADDRS call. - DIOCADDADDR must also be called if any pool - addresses are required. The optional anchor name - indicates the anchor in which to append the rule. - nr and action are - ignored.

-
-
- struct pfioc_altq *pa
-
Add an ALTQ discipline or queue. -
- 
struct pfioc_altq {
-	u_int32_t	action;
-	u_int32_t	ticket;
-	u_int32_t	nr;
-	struct pf_altq  altq;
-};
-
-
-
- struct pfioc_rule *pr
-
Get a ticket for subsequent - DIOCGETRULE calls and the number - nr of rules in the active ruleset.
-
- struct pfioc_rule *pr
-
Get a rule by its number nr - using the ticket obtained through a preceding - DIOCGETRULES call. If action - is set to PF_GET_CLR_CNTR, the per-rule statistics - on the requested rule are cleared.
-
- struct pfioc_pooladdr *pp
-
Get a ticket for subsequent - DIOCGETADDR calls and the number - nr of pool addresses in the rule specified with - r_action, r_num, and - anchor.
-
- struct pfioc_pooladdr *pp
-
Get the pool address addr by its number - nr from the rule specified with - r_action, r_num, and - anchor using the ticket - obtained through a preceding DIOCGETADDRS - call.
-
- struct pfioc_altq *pa
-
Get a ticket for subsequent - DIOCGETALTQ calls and the number - nr of queues in the active list.
-
- struct pfioc_altq *pa
-
Get the queueing discipline altq by its number - nr using the ticket obtained - through a preceding DIOCGETALTQS call.
-
- struct pfioc_qstats *pq
-
Get the statistics on a queue. -
- 
struct pfioc_qstats {
-	u_int32_t	 ticket;
-	u_int32_t	 nr;
-	void		*buf;
-	int		 nbytes;
-	u_int8_t	 scheduler;
-};
-
-

This call fills in a pointer to the buffer of statistics - buf, of length nbytes, for - the queue specified by nr.

-
-
- struct pfioc_ruleset *pr
-
-
- 
struct pfioc_ruleset {
-	u_int32_t	 nr;
-	char		 path[MAXPATHLEN];
-	char		 name[PF_ANCHOR_NAME_SIZE];
-};
-
-

Get the number nr of rulesets (i.e., - anchors) directly attached to the anchor named by - path for use in subsequent - DIOCGETRULESET calls. Nested anchors, since they - are not directly attached to the given anchor, will not be included. - This ioctl returns ENOENT if the parent anchor - given at path does not exist.

-
-
- struct pfioc_ruleset *pr
-
Get a ruleset (i.e., an anchor) name by its number - nr from the given anchor path, - the maximum number of which can be obtained from a preceding - DIOCGETRULESETS call. This ioctl returns - ENOENT if the parent anchor given by - path does not exist or EBUSY - if the index passed in by nr is greater than the - number of anchors.
-
- struct pfioc_state *ps
-
Add a state entry. -
- 
struct pfioc_state {
-	struct pfsync_state	state;
-};
-
-
-
- struct pfioc_nv *nv
-
Extract the entry identified by the id and - creatorid fields of the state - nvlist from the state table.
-
- struct pfioc_nv nv
-
Remove matching entries from the state table. This ioctl returns the - number of killed states in killed. -
- 
nvlist pf_state_cmp {
-	number			id;
-	number			creatorid;
-	number			direction;
-};
-
-nvlist pf_kill {
-	nvlist pf_state_cmp	cmp;
-	number			af;
-	number			proto;
-	nvlist pf_rule_addr	src;
-	nvlist pf_rule_addr	dst;
-	string			ifname[IFNAMSIZ];
-	string			label[PF_RULE_LABEL_SIZE];
-};
-
-
-
- struct pfioc_nv nv
-
Clear all states. It works like DIOCKILLSTATESNV, - but ignores the af, proto, - src, and dst fields of the - pf_kill nvlist.
-
- struct pfioc_if *pi
-
Specify the interface for which statistics are accumulated. -
- 
struct pfioc_if {
-	char		 ifname[IFNAMSIZ];
-};
-
-
-
- struct pf_status *s
-
Get the internal packet filter statistics. -
- 
struct pf_status {
-	u_int64_t	counters[PFRES_MAX];
-	u_int64_t	lcounters[LCNT_MAX];
-	u_int64_t	fcounters[FCNT_MAX];
-	u_int64_t	scounters[SCNT_MAX];
-	u_int64_t	pcounters[2][2][3];
-	u_int64_t	bcounters[2][2];
-	u_int32_t	running;
-	u_int32_t	states;
-	u_int32_t	src_nodes;
-	u_int32_t	since;
-	u_int32_t	debug;
-	u_int32_t	hostid;
-	char		ifname[IFNAMSIZ];
-	u_int8_t	pf_chksum[MD5_DIGEST_LENGTH];
-};
-
-
-
-
Clear the internal packet filter statistics.
-
- struct pfioc_natlook *pnl
-
Look up a state table entry by source and destination addresses and ports. -
- 
struct pfioc_natlook {
-	struct pf_addr	 saddr;
-	struct pf_addr	 daddr;
-	struct pf_addr	 rsaddr;
-	struct pf_addr	 rdaddr;
-	u_int16_t	 sport;
-	u_int16_t	 dport;
-	u_int16_t	 rsport;
-	u_int16_t	 rdport;
-	sa_family_t	 af;
-	u_int8_t	 proto;
-	u_int8_t	 direction;
-};
-
-
-
- u_int32_t *level
-
Set the debug level. -
- 
enum	{ PF_DEBUG_NONE, PF_DEBUG_URGENT, PF_DEBUG_MISC,
-	  PF_DEBUG_NOISY };
-
-
-
- struct pfioc_states_v2 *ps
-
Get state table entries. -
- 
struct pfioc_states_v2 {
-	int		ps_len;
-	uint64_t	ps_req_version;
-	union {
-		void			*ps_buf;
-		struct pf_state_export	*ps_states;
-	};
-};
-
-struct pf_state_export {
-	uint64_t	 version;
-	uint64_t	 id;
-	char		 ifname[IFNAMSIZ];
-	char		 orig_ifname[IFNAMSIZ];
-	struct pf_state_key_export	 key[2];
-	struct pf_state_peer_export	 src;
-	struct pf_state_peer_export	 dst;
-	struct pf_addr	 rt_addr;
-	uint32_t	 rule;
-	uint32_t	 anchor;
-	uint32_t	 nat_rule;
-	uint32_t	 creation;
-	uint32_t	 expire;
-	uint32_t	 spare0;
-	uint64_t	 packets[2];
-	uint64_t	 bytes[2];
-	uint32_t	 creatorid;
-	uint32_t	 spare1;
-	sa_family_t	 af;
-	uint8_t		 proto;
-	uint8_t		 direction;
-	uint8_t		 log;
-	uint8_t		 state_flags_compat;
-	uint8_t		 timeout;
-	uint8_t		 sync_flags;
-	uint8_t		 updates;
-	uint16_t	 state_flags;
-	uint16_t	 qid;
-	uint16_t	 pqid;
-	uint16_t	 dnpipe;
-	uint16_t	 dnrpipe;
-	int32_t		 rtableid;
-	uint8_t		 min_ttl;
-	uint8_t		 set_tos;
-	uint16_t	 max_mss;
-	uint8_t		 set_prio[2];
-	uint8_t		 rt;
-	char		 rt_ifname[IFNAMSIZ];
-	uint8_t		 spare[72];
-};
-
-
-
- struct pfioc_rule *pcr
-
Add or remove the rule in the ruleset specified by - rule.action. -

The type of operation to be performed is indicated by - action, which can be any of the following:

-
- 
enum	{ PF_CHANGE_NONE, PF_CHANGE_ADD_HEAD, PF_CHANGE_ADD_TAIL,
-	  PF_CHANGE_ADD_BEFORE, PF_CHANGE_ADD_AFTER,
-	  PF_CHANGE_REMOVE, PF_CHANGE_GET_TICKET };
-
-

ticket must be set to the value obtained - with PF_CHANGE_GET_TICKET for all actions except - PF_CHANGE_GET_TICKET. - pool_ticket must be set to the value obtained with - the DIOCBEGINADDRS call for all actions except - PF_CHANGE_REMOVE and - PF_CHANGE_GET_TICKET. - anchor indicates to which anchor the operation - applies. nr indicates the rule number against - which PF_CHANGE_ADD_BEFORE, - PF_CHANGE_ADD_AFTER, or - PF_CHANGE_REMOVE actions are applied.

-
-
- struct pfioc_pooladdr *pca
-
Add or remove the pool address addr from the rule - specified by r_action, r_num, - and anchor.
-
- struct pfioc_tm *pt
-
-
- 
struct pfioc_tm {
-	int		 timeout;
-	int		 seconds;
-};
-
-

Set the state timeout of timeout to - seconds. The old value will be placed into - seconds. For possible values of - timeout, consult the - PFTM_* values in - ⟨net/pfvar.h⟩.

-
-
- struct pfioc_tm *pt
-
Get the state timeout of timeout. The value will be - placed into the seconds field.
-
-
Clear per-rule statistics.
-
- struct pfioc_limit *pl
-
Set the hard limits on the memory pools used by the packet filter. -
- 
struct pfioc_limit {
-	int		index;
-	unsigned	limit;
-};
-
-enum	{ PF_LIMIT_STATES, PF_LIMIT_SRC_NODES, PF_LIMIT_FRAGS,
-	  PF_LIMIT_TABLE_ENTRIES, PF_LIMIT_MAX };
-
-
-
- struct pfioc_limit *pl
-
Get the hard limit for the memory pool indicated by - index.
-
- struct pfioc_table *io
-
Clear all tables. All the ioctls that manipulate radix tables use the same - structure described below. For DIOCRCLRTABLES, - pfrio_ndel contains on exit the number of tables - deleted. -
- 
struct pfioc_table {
-	struct pfr_table	 pfrio_table;
-	void			*pfrio_buffer;
-	int			 pfrio_esize;
-	int			 pfrio_size;
-	int			 pfrio_size2;
-	int			 pfrio_nadd;
-	int			 pfrio_ndel;
-	int			 pfrio_nchange;
-	int			 pfrio_flags;
-	u_int32_t		 pfrio_ticket;
-};
-#define pfrio_exists    pfrio_nadd
-#define pfrio_nzero     pfrio_nadd
-#define pfrio_nmatch    pfrio_nadd
-#define pfrio_naddr     pfrio_size2
-#define pfrio_setflag   pfrio_size2
-#define pfrio_clrflag   pfrio_nadd
-
-
-
- struct pfioc_table *io
-
Create one or more tables. On entry, pfrio_buffer - must point to an array of struct pfr_table - containing at least pfrio_size elements. - pfrio_esize must be the size of - struct pfr_table. On exit, - pfrio_nadd contains the number of tables effectively - created. -
- 
struct pfr_table {
-	char		pfrt_anchor[MAXPATHLEN];
-	char		pfrt_name[PF_TABLE_NAME_SIZE];
-	u_int32_t	pfrt_flags;
-	u_int8_t	pfrt_fback;
-};
-
-
-
- struct pfioc_table *io
-
Delete one or more tables. On entry, pfrio_buffer - must point to an array of struct pfr_table - containing at least pfrio_size elements. - pfrio_esize must be the size of - struct pfr_table. On exit, - pfrio_ndel contains the number of tables effectively - deleted.
-
- struct pfioc_table *io
-
Get the list of all tables. On entry, - pfrio_buffer[pfrio_size] contains a valid writeable - buffer for pfr_table structures. On exit, - pfrio_size contains the number of tables written - into the buffer. If the buffer is too small, the kernel does not store - anything but just returns the required buffer size, without error.
-
- struct pfioc_table *io
-
This call is like DIOCRGETTABLES but is used to - get an array of pfr_tstats structures. -
- 
struct pfr_tstats {
-	struct pfr_table pfrts_t;
-	u_int64_t	 pfrts_packets
-			     [PFR_DIR_MAX][PFR_OP_TABLE_MAX];
-	u_int64_t	 pfrts_bytes
-			     [PFR_DIR_MAX][PFR_OP_TABLE_MAX];
-	u_int64_t	 pfrts_match;
-	u_int64_t	 pfrts_nomatch;
-	time_t		 pfrts_tzero;
-	int		 pfrts_cnt;
-	int		 pfrts_refcnt[PFR_REFCNT_MAX];
-};
-#define pfrts_name	 pfrts_t.pfrt_name
-#define pfrts_flags	 pfrts_t.pfrt_flags
-
-
-
- struct pfioc_table *io
-
Clear the statistics of one or more tables. On entry, - pfrio_buffer must point to an array of - struct pfr_table containing at least - pfrio_size elements. - pfrio_esize must be the size of - struct pfr_table. On exit, - pfrio_nzero contains the number of tables - effectively cleared.
-
- struct pfioc_table *io
-
Clear all addresses in a table. On entry, - pfrio_table contains the table to clear. On exit, - pfrio_ndel contains the number of addresses - removed.
-
- struct pfioc_table *io
-
Add one or more addresses to a table. On entry, - pfrio_table contains the table ID and - pfrio_buffer must point to an array of - struct pfr_addr containing at least - pfrio_size elements to add to the table. - pfrio_esize must be the size of - struct pfr_addr. On exit, - pfrio_nadd contains the number of addresses - effectively added. -
- 
struct pfr_addr {
-	union {
-		struct in_addr	 _pfra_ip4addr;
-		struct in6_addr	 _pfra_ip6addr;
-	}		 pfra_u;
-	u_int8_t	 pfra_af;
-	u_int8_t	 pfra_net;
-	u_int8_t	 pfra_not;
-	u_int8_t	 pfra_fback;
-};
-#define pfra_ip4addr    pfra_u._pfra_ip4addr
-#define pfra_ip6addr    pfra_u._pfra_ip6addr
-
-
-
- struct pfioc_table *io
-
Delete one or more addresses from a table. On entry, - pfrio_table contains the table ID and - pfrio_buffer must point to an array of - struct pfr_addr containing at least - pfrio_size elements to delete from the table. - pfrio_esize must be the size of - struct pfr_addr. On exit, - pfrio_ndel contains the number of addresses - effectively deleted.
-
- struct pfioc_table *io
-
Replace the content of a table by a new address list. This is the most - complicated command, which uses all the structure members. -

On entry, pfrio_table contains the table - ID and pfrio_buffer must point to an array of - struct pfr_addr containing at least - pfrio_size elements which become the new contents - of the table. pfrio_esize must be the size of - struct pfr_addr. Additionally, if - pfrio_size2 is non-zero, - pfrio_buffer[pfrio_size..pfrio_size2] must be a - writeable buffer, into which the kernel can copy the addresses that have - been deleted during the replace operation. On exit, - pfrio_ndel, pfrio_nadd, and - pfrio_nchange contain the number of addresses - deleted, added, and changed by the kernel. If - pfrio_size2 was set on entry, - pfrio_size2 will point to the size of the buffer - used, exactly like DIOCRGETADDRS.

-
-
- struct pfioc_table *io
-
Get all the addresses of a table. On entry, - pfrio_table contains the table ID and - pfrio_buffer[pfrio_size] contains a valid writeable - buffer for pfr_addr structures. On exit, - pfrio_size contains the number of addresses written - into the buffer. If the buffer was too small, the kernel does not store - anything but just returns the required buffer size, without returning an - error.
-
- struct pfioc_table *io
-
This call is like DIOCRGETADDRS but is used to get - an array of pfr_astats structures. -
- 
struct pfr_astats {
-	struct pfr_addr	 pfras_a;
-	u_int64_t	 pfras_packets
-			     [PFR_DIR_MAX][PFR_OP_ADDR_MAX];
-	u_int64_t	 pfras_bytes
-			     [PFR_DIR_MAX][PFR_OP_ADDR_MAX];
-	time_t		 pfras_tzero;
-};
-
-
-
- struct pfioc_table *io
-
Clear the statistics of one or more addresses. On entry, - pfrio_table contains the table ID and - pfrio_buffer must point to an array of - struct pfr_addr containing at least - pfrio_size elements to be cleared from the table. - pfrio_esize must be the size of - struct pfr_addr. On exit, - pfrio_nzero contains the number of addresses - effectively cleared.
-
- struct pfioc_table *io
-
Test if the given addresses match a table. On entry, - pfrio_table contains the table ID and - pfrio_buffer must point to an array of - struct pfr_addr containing at least - pfrio_size elements, each of which will be tested - for a match in the table. pfrio_esize must be the - size of struct pfr_addr. On exit, the kernel updates - the pfr_addr array by setting the - pfra_fback member appropriately.
-
- struct pfioc_table *io
-
Change the PFR_TFLAG_CONST or - PFR_TFLAG_PERSIST flags of a table. On entry, - pfrio_buffer must point to an array of - struct pfr_table containing at least - pfrio_size elements. - pfrio_esize must be the size of - struct pfr_table. - pfrio_setflag must contain the flags to add, while - pfrio_clrflag must contain the flags to remove. On - exit, pfrio_nchange and - pfrio_ndel contain the number of tables altered or - deleted by the kernel. Yes, tables can be deleted if one removes the - PFR_TFLAG_PERSIST flag of an unreferenced - table.
-
- struct pfioc_table *io
-
Defines a table in the inactive set. On entry, - pfrio_table contains the table ID and - pfrio_buffer[pfrio_size] contains an array of - pfr_addr structures to put in the table. A valid - ticket must also be supplied to pfrio_ticket. On - exit, pfrio_nadd contains 0 if the table was already - defined in the inactive list or 1 if a new table has been created. - pfrio_naddr contains the number of addresses - effectively put in the table.
-
- struct pfioc_trans *io
-
-
- 
struct pfioc_trans {
-	int		 size;	/* number of elements */
-	int		 esize;	/* size of each element in bytes */
-	struct pfioc_trans_e {
-		int		rs_num;
-		char		anchor[MAXPATHLEN];
-		u_int32_t	ticket;
-	}		*array;
-};
-
-

Clear all the inactive rulesets specified in the - pfioc_trans_e array. For each ruleset, a ticket is - returned for subsequent "add rule" ioctls, as well as for the - DIOCXCOMMIT and - DIOCXROLLBACK calls.

-

Ruleset types, identified by rs_num, - include the following:

-

-
-
-
-
Scrub (packet normalization) rules.
-
-
Filter rules.
-
-
NAT (Network Address Translation) rules.
-
-
Bidirectional NAT rules.
-
-
Redirect rules.
-
-
ALTQ disciplines.
-
-
Address tables.
-
-
-
-
- struct pfioc_trans *io
-
Atomically switch a vector of inactive rulesets to the active rulesets. - This call is implemented as a standard two-phase commit, which will either - fail for all rulesets or completely succeed. All tickets need to be valid. - This ioctl returns EBUSY if another process is - concurrently updating some of the same rulesets.
-
- struct pfioc_trans *io
-
Clean up the kernel by undoing all changes that have taken place on the - inactive rulesets since the last DIOCXBEGIN. - DIOCXROLLBACK will silently ignore rulesets for - which the ticket is invalid.
-
- u_int32_t *hostid
-
Set the host ID, which is used by pfsync(4) to identify - which host created state table entries.
-
-
Flush the passive OS fingerprint table.
-
- struct pf_osfp_ioctl *io
-
-
- 
struct pf_osfp_ioctl {
-	struct pf_osfp_entry {
-		SLIST_ENTRY(pf_osfp_entry) fp_entry;
-		pf_osfp_t		fp_os;
-		char			fp_class_nm[PF_OSFP_LEN];
-		char			fp_version_nm[PF_OSFP_LEN];
-		char			fp_subtype_nm[PF_OSFP_LEN];
-	} 			fp_os;
-	pf_tcpopts_t		fp_tcpopts;
-	u_int16_t		fp_wsize;
-	u_int16_t		fp_psize;
-	u_int16_t		fp_mss;
-	u_int16_t		fp_flags;
-	u_int8_t		fp_optcnt;
-	u_int8_t		fp_wscale;
-	u_int8_t		fp_ttl;
-	int			fp_getnum;
-};
-
-

Add a passive OS fingerprint to the table. Set - fp_os.fp_os to the packed fingerprint, - fp_os.fp_class_nm to the name of the class (Linux, - Windows, etc), fp_os.fp_version_nm to the name of - the version (NT, 95, 98), and fp_os.fp_subtype_nm - to the name of the subtype or patchlevel. The members - fp_mss, fp_wsize, - fp_psize, fp_ttl, - fp_optcnt, and fp_wscale are - set to the TCP MSS, the TCP window size, the IP length, the IP TTL, the - number of TCP options, and the TCP window scaling constant of the TCP - SYN packet, respectively.

-

The fp_flags member is filled according - to the ⟨net/pfvar.h⟩ include file - PF_OSFP_* defines. The - fp_tcpopts member contains packed TCP options. - Each option uses PF_OSFP_TCPOPT_BITS bits in the - packed value. Options include any of - PF_OSFP_TCPOPT_NOP, - PF_OSFP_TCPOPT_SACK, - PF_OSFP_TCPOPT_WSCALE, - PF_OSFP_TCPOPT_MSS, or - PF_OSFP_TCPOPT_TS.

-

The fp_getnum member is not used with - this ioctl.

-

The structure's slack space must be zeroed for correct - operation; memset(3) the whole structure to zero - before filling and sending to the kernel.

-
-
- struct pf_osfp_ioctl *io
-
Get the passive OS fingerprint number fp_getnum from - the kernel's fingerprint list. The rest of the structure members will come - back filled. Get the whole list by repeatedly incrementing the - fp_getnum number until the ioctl returns - EBUSY.
-
- struct pfioc_src_nodes *psn
-
-
- 
struct pfioc_src_nodes {
-	int	psn_len;
-	union {
-		caddr_t		psu_buf;
-		struct pf_src_node	*psu_src_nodes;
-	} psn_u;
-#define psn_buf		psn_u.psu_buf
-#define psn_src_nodes	psn_u.psu_src_nodes
-};
-
-

Get the list of source nodes kept by sticky addresses and - source tracking. The ioctl must be called once with - psn_len set to 0. If the ioctl returns without - error, psn_len will be set to the size of the - buffer required to hold all the pf_src_node - structures held in the table. A buffer of this size should then be - allocated, and a pointer to this buffer placed in - psn_buf. The ioctl must then be called again to - fill this buffer with the actual source node data. After that call, - psn_len will be set to the length of the buffer - actually used.

-
-
-
Clear the tree of source tracking nodes.
-
- struct pfioc_iface *io
-
Get the list of interfaces and interface groups known to - pf. All the ioctls that manipulate interfaces use - the same structure described below: -
- 
struct pfioc_iface {
-	char			 pfiio_name[IFNAMSIZ];
-	void			*pfiio_buffer;
-	int			 pfiio_esize;
-	int			 pfiio_size;
-	int			 pfiio_nzero;
-	int			 pfiio_flags;
-};
-
-

If not empty, pfiio_name can be used to - restrict the search to a specific interface or group. - pfiio_buffer[pfiio_size] is the user-supplied - buffer for returning the data. On entry, - pfiio_size contains the number of - pfi_kif entries that can fit into the buffer. The - kernel will replace this value by the real number of entries it wants to - return. pfiio_esize should be set to - sizeof(struct pfi_kif).

-

The data is returned in the pfi_kif - structure described below:

-
- 
struct pfi_kif {
-	char				 pfik_name[IFNAMSIZ];
-	union {
-		RB_ENTRY(pfi_kif)	 pfik_tree;
-		LIST_ENTRY(pfi_kif)	 pfik_list;
-	};
-	u_int64_t			 pfik_packets[2][2][2];
-	u_int64_t			 pfik_bytes[2][2][2];
-	u_int32_t			 pfik_tzero;
-	u_int				 pfik_flags;
-	struct ifnet			*pfik_ifp;
-	struct ifg_group		*pfik_group;
-	u_int				 pfik_rulerefs;
-	TAILQ_HEAD(, pfi_dynaddr)	 pfik_dynaddrs;
-};
-
-
-
- struct pfioc_iface *io
-
Set the user settable flags (described above) of the - pf internal interface description. The filtering - process is the same as for DIOCIGETIFACES. -
- 
#define PFI_IFLAG_SKIP	0x0100	/* skip filtering on interface */
-
-
-
- struct pfioc_iface *io
-
Works as DIOCSETIFFLAG above but clears the - flags.
-
- struct pfioc_iface *io
-
Explicitly remove source tracking nodes.
-
-
-
-

-
-
/dev/pf
-
packet filtering device.
-
-
-
-

-

The following example demonstrates how to use the - DIOCNATLOOK command to find the internal host/port - of a NATed connection:

-
-
#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/ioctl.h>
-#include <sys/fcntl.h>
-#include <net/if.h>
-#include <netinet/in.h>
-#include <net/pfvar.h>
-#include <err.h>
-#include <stdio.h>
-#include <stdlib.h>
-
-u_int32_t
-read_address(const char *s)
-{
-	int a, b, c, d;
-
-	sscanf(s, "%i.%i.%i.%i", &a, &b, &c, &d);
-	return htonl(a << 24 | b << 16 | c << 8 | d);
-}
-
-void
-print_address(u_int32_t a)
-{
-	a = ntohl(a);
-	printf("%d.%d.%d.%d", a >> 24 & 255, a >> 16 & 255,
-	    a >> 8 & 255, a & 255);
-}
-
-int
-main(int argc, char *argv[])
-{
-	struct pfioc_natlook nl;
-	int dev;
-
-	if (argc != 5) {
-		printf("%s <gwy addr> <gwy port> <ext addr> <ext port>\n",
-		    argv[0]);
-		return 1;
-	}
-
-	dev = open("/dev/pf", O_RDWR);
-	if (dev == -1)
-		err(1, "open(\"/dev/pf\") failed");
-
-	memset(&nl, 0, sizeof(struct pfioc_natlook));
-	nl.saddr.v4.s_addr	= read_address(argv[1]);
-	nl.sport		= htons(atoi(argv[2]));
-	nl.daddr.v4.s_addr	= read_address(argv[3]);
-	nl.dport		= htons(atoi(argv[4]));
-	nl.af			= AF_INET;
-	nl.proto		= IPPROTO_TCP;
-	nl.direction		= PF_IN;
-
-	if (ioctl(dev, DIOCNATLOOK, &nl))
-		err(1, "DIOCNATLOOK");
-
-	printf("internal host ");
-	print_address(nl.rsaddr.v4.s_addr);
-	printf(":%u\n", ntohs(nl.rsport));
-	return 0;
-}
-
-
-
-

-

ioctl(2), altq(4), - if_bridge(4), pflog(4), - pfsync(4), pfctl(8), - altq(9)

-
-
-

-

The pf packet filtering mechanism first - appeared in OpenBSD 3.0 and then - FreeBSD 5.2.

-

This implementation is derived from OpenBSD - 4.5. A number of individual features, improvements, bug fixes and - security fixes have been ported from later versions of - OpenBSD. It has been heavily modified to be capable - of running in multithreaded FreeBSD kernel and scale - its performance on multiple CPUs.

-
-
- - - - - -
July 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/pflog.4 3.html b/static/freebsd/man4/pflog.4 3.html deleted file mode 100644 index ad5eef40..00000000 --- a/static/freebsd/man4/pflog.4 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
PFLOG(4)Device Drivers ManualPFLOG(4)
-
-
-

-

pflog — packet - filter logging interface

-
-
-

-

device pflog

-
-
-

-

The pflog interface is a device which - makes visible all packets logged by the packet filter, - pf(4). Logged packets can easily be monitored in real time - by invoking tcpdump(1) on the - pflog interface, or stored to disk using - pflogd(8).

-

The pflog0 interface is created when the - pflog module is loaded; further instances can be - created using ifconfig(8). The - pflog module is loaded automatically if both - pf(4) and pflogd(8) are enabled.

-

Each packet retrieved on this interface has a header associated - with it of length PFLOG_HDRLEN. This header - documents the address family, interface name, rule number, reason, action, - and direction of the packet that was logged. This structure, defined in - ⟨net/if_pflog.h⟩ looks like

-
-
struct pfloghdr {
-	u_int8_t	length;
-	sa_family_t	af;
-	u_int8_t	action;
-	u_int8_t	reason;
-	char		ifname[IFNAMSIZ];
-	char		ruleset[PF_RULESET_NAME_SIZE];
-	u_int32_t	rulenr;
-	u_int32_t	subrulenr;
-	uid_t		uid;
-	pid_t		pid;
-	uid_t		rule_uid;
-	pid_t		rule_pid;
-	u_int8_t	dir;
-	u_int8_t	pad[3];
-	u_int32_t	ridentifier;
-};
-
-
-
-

-

Create a pflog interface and monitor all - packets logged on it:

-
-
# ifconfig pflog create
-pflog1
-# ifconfig pflog1 up
-# tcpdump -n -e -ttt -i pflog1
-
-
-
-

-

tcpdump(1), inet(4), - inet6(4), netintro(4), - pf(4), ifconfig(8), - pflogd(8)

-
-
-

-

The pflog device first appeared in - OpenBSD 3.0.

-
-
-

-

FreeBSD does not set a process id in the pid - field in pfloghdr.

-
-
- - - - - -
October 29, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/pflow.4 3.html b/static/freebsd/man4/pflow.4 3.html deleted file mode 100644 index d63d6f82..00000000 --- a/static/freebsd/man4/pflow.4 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
PFLOW(4)Device Drivers ManualPFLOW(4)
-
-
-

-

pflow — kernel - interface for pflow data export

-
-
-

-

pseudo-device pflow

-
-
-

-

The pflow subsystem exports - pflow accounting data from the kernel using - udp(4) packets. pflow is - compatible with netflow version 5 and IPFIX (10). The data is extracted from - the pf(4) state table.

-

Multiple pflow interfaces can be created - at runtime using the pflowctlN - -c command. Each interface must be configured with a - flow receiver IP address and a flow receiver port number.

-

Only states created by a rule marked with the - pflow keyword are exported by - pflow.

-

pflow will attempt to export multiple - pflow records in one UDP packet, but will not hold a - record for longer than 30 seconds.

-

Each packet seen on this interface has one header and a variable - number of flows. The header indicates the version of the protocol, number of - flows in the packet, a unique sequence number, system time, and an engine ID - and type. Header and flow structs are defined in - <net/pflow.h>.

-

The pflow source and destination addresses - are controlled by pflowctl(8). src - is the sender IP address of the UDP packet which can be used to identify the - source of the data on the pflow collector. - dst defines the collector IP address and the port. - The dst IP address and port must be defined to - enable the export of flows.

-

For example, the following command sets 10.0.0.1 as the source and - 10.0.0.2:1234 as destination:

-
-
# pflowctl -s pflow0 src 10.0.0.1 dst 10.0.0.2:1234
-
-

The protocol is set to IPFIX with the following command:

-
-
# pflowctl -s pflow0 proto 10
-
-
-
-

-

netintro(4), pf(4), - udp(4), pf.conf(5), - pflowctl(8), tcpdump(8)

-
-
-

-

B. Claise, - Specification of the IP Flow Information Export (IPFIX) - Protocol for the Exchange of IP Traffic Flow Information, - RFC 5101, January - 2008.

-
-
-

-

The pflow device first appeared in - OpenBSD 4.5 and was imported into FreeBSD 15.0 .

-
-
-

-

A state created by pfsync(4) can have a creation - or expiration time before the machine came up. In this case, - pflow pretends such flows were created or expired - when the machine came up.

-

The IPFIX implementation is incomplete: The required transport - protocol SCTP is not supported. Transport over TCP and DTLS protected flow - export is also not supported.

-
-
- - - - - -
January 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/pfsync.4 3.html b/static/freebsd/man4/pfsync.4 3.html deleted file mode 100644 index fe429d7b..00000000 --- a/static/freebsd/man4/pfsync.4 3.html +++ /dev/null @@ -1,208 +0,0 @@ - - - - - - -
PFSYNC(4)Device Drivers ManualPFSYNC(4)
-
-
-

-

pfsync — packet - filter state table synchronisation interface

-
-
-

-

device pfsync

-

In loader.conf(5): -
- net.pfsync.pfsync_buckets

-

In sysctl.conf(5): -
- net.pfsync.carp_demotion_factor

-
-
-

-

The pfsync interface is a pseudo-device - which exposes certain changes to the state table used by - pf(4). State changes can be viewed by invoking - tcpdump(1) on the pfsync - interface. If configured with a physical synchronisation interface, - pfsync will also send state changes out on that - interface, and insert state changes received on that interface from other - systems into the state table.

-

By default, all local changes to the state table are exposed via - pfsync. State changes from packets received by - pfsync over the network are not rebroadcast. Updates - to states created by a rule marked with the no-sync - keyword are ignored by the pfsync interface (see - pf.conf(5) for details).

-

The pfsync interface will attempt to - collapse multiple state updates into a single packet where possible. The - maximum number of times a single state can be updated before a - pfsync packet will be sent out is controlled by the - maxupd parameter to ifconfig (see - ifconfig(8) and the example below for more details). The - sending out of a pfsync packet will be delayed by a - maximum of one second.

-
-
-

-

States can be synchronised between two or more firewalls using - this interface, by specifying a synchronisation interface using - ifconfig(8). For example, the following command sets fxp0 - as the synchronisation interface:

-
-
# ifconfig pfsync0 syncdev fxp0
-
-

By default, state change messages are sent out on the - synchronisation interface using IP multicast packets to the 224.0.0.240 - group address. An alternative destination address for - pfsync packets can be specified using the - syncpeer keyword. This can be used in combination - with ipsec(4) to protect the synchronisation traffic. In - such a configuration, the syncdev should be set to the - enc(4) interface, as this is where the traffic arrives - when it is decapsulated, e.g.:

-
-
# ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0
-
-

It is important that the pfsync traffic be well secured as there - is no authentication on the protocol and it would be trivial to spoof - packets which create states, bypassing the pf ruleset. Either run the pfsync - protocol on a trusted network - ideally a network dedicated to pfsync - messages such as a crossover cable between two firewalls, or specify a peer - address and protect the traffic with ipsec(4).

-

Support for pfsync transport over IPv6 was - introduced in FreeBSD 14.0. To set up - pfsync using multicast with IPv6 link-local - addresses, the syncpeer must be set to the - pfsync multicast address and the - syncdev to the interface where - pfsync traffic is expected.

-
-
# ifconfig pfsync0 syncpeer ff12::f0 syncdev vtnet0
-
-

When new features are introduced to pf(4) the - format of messages used by pfsync might change. - pfsync will by default use the latest format. If - synchronization with a peer running an older version of FreeBSD is needed - the version parameter can be used. E.g.:

-
-
# ifconfig pfsync0 version 1301
-
-

Currently the following versions are supported:

-
-
-
FreeBSD releases 13.2 and older. Compatibility with FreeBSD 13.1 has been - verified.
-
-
FreeBSD release 14.0.
-
-
FreeBSD release 15.0.
-
-
-
-

-

The following variables can be entered at the - loader(8) prompt, set in loader.conf(5), - or changed at runtime with sysctl(8):

-
-
net.pfsync.carp_demotion_factor
-
Value added to net.inet.carp.demotion while - pfsync tries to perform its bulk update. See - carp(4) for more information. Default value is 240.
-
-
-
-

-

The following tunable may be set in - loader.conf(5) or at the loader(8) - prompt:

-
-
net.pfsync.pfsync_buckets
-
The number of pfsync buckets. This affects the - performance and memory tradeoff. Defaults to twice the number of CPUs. - Change only if benchmarks show this helps on your workload.
-
-
-
-

-

pfsync and carp(4) can - be used together to provide automatic failover of a pair of firewalls - configured in parallel. One firewall will handle all traffic until it dies, - is shut down, or is manually demoted, at which point the second firewall - will take over automatically.

-

Both firewalls in this example have three sis(4) - interfaces. sis0 is the external interface, on the 10.0.0.0/24 subnet; sis1 - is the internal interface, on the 192.168.0.0/24 subnet; and sis2 is the - pfsync interface, using the 192.168.254.0/24 subnet. - A crossover cable connects the two firewalls via their sis2 interfaces. On - all three interfaces, firewall A uses the .254 address, while firewall B - uses .253. The interfaces are configured as follows (firewall A unless - otherwise indicated):

-

Interfaces configuration in - /etc/rc.conf:

-
-
network_interfaces="lo0 sis0 sis1 sis2"
-ifconfig_sis0="10.0.0.254/24"
-ifconfig_sis0_alias0="inet 10.0.0.1/24 vhid 1 pass foo"
-ifconfig_sis1="192.168.0.254/24"
-ifconfig_sis1_alias0="inet 192.168.0.1/24 vhid 2 pass bar"
-ifconfig_sis2="192.168.254.254/24"
-pfsync_enable="YES"
-pfsync_syncdev="sis2"
-
-

pf(4) must also be configured to allow - pfsync and carp(4) traffic - through. The following should be added to the top of - /etc/pf.conf:

-
-
pass quick on { sis2 } proto pfsync keep state (no-sync)
-pass on { sis0 sis1 } proto carp keep state (no-sync)
-
-

It is preferable that one firewall handle the forwarding of all - the traffic, therefore the advskew on the backup - firewall's carp(4) vhids should be set to something higher - than the primary's. For example, if firewall B is the backup, its carp1 - configuration would look like this:

-
-
ifconfig_sis1_alias0="inet 192.168.0.1/24 vhid 2 pass bar advskew 100"
-
-

The following must also be added to - /etc/sysctl.conf:

-
-
net.inet.carp.preempt=1
-
-
-
-

-

tcpdump(1), bpf(4), - carp(4), enc(4), - inet(4), inet6(4), - ipsec(4), netintro(4), - pf(4), pf.conf(5), - protocols(5), rc.conf(5), - ifconfig(8)

-
-
-

-

The pfsync device first appeared in - OpenBSD 3.3. It was first imported to - FreeBSD 5.3.

-

The pfsync protocol and kernel - implementation were significantly modified in FreeBSD - 9.0. The newer protocol is not compatible with older one and will not - interoperate with it.

-
-
- - - - - -
November 8, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/pim.4 3.html b/static/freebsd/man4/pim.4 3.html deleted file mode 100644 index a4f0d123..00000000 --- a/static/freebsd/man4/pim.4 3.html +++ /dev/null @@ -1,177 +0,0 @@ - - - - - - -
PIM(4)Device Drivers ManualPIM(4)
-
-
-

-

pim — Protocol - Independent Multicast

-
-
-

-

options MROUTING

-

-
- #include <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet/ip_mroute.h> -
- #include <netinet/pim.h>

-

int -
- getsockopt(int - s, IPPROTO_IP, - MRT_PIM, - void *optval, - socklen_t *optlen);

-

int -
- setsockopt(int - s, IPPROTO_IP, - MRT_PIM, - const void *optval, - socklen_t optlen);

-

int -
- getsockopt(int - s, IPPROTO_IPV6, - MRT6_PIM, - void *optval, - socklen_t *optlen);

-

int -
- setsockopt(int - s, IPPROTO_IPV6, - MRT6_PIM, - const void *optval, - socklen_t optlen);

-
-
-

-

PIM is the common name for two multicast routing protocols: - Protocol Independent Multicast - Sparse Mode (PIM-SM) and Protocol - Independent Multicast - Dense Mode (PIM-DM).

-

PIM-SM is a multicast routing protocol that can use the underlying - unicast routing information base or a separate multicast-capable routing - information base. It builds unidirectional shared trees rooted at a - Rendezvous Point (RP) per group, and optionally creates shortest-path trees - per source.

-

PIM-DM is a multicast routing protocol that uses the underlying - unicast routing information base to flood multicast datagrams to all - multicast routers. Prune messages are used to prevent future datagrams from - propagating to routers with no group membership information.

-

Both PIM-SM and PIM-DM are fairly complex protocols, though PIM-SM - is much more complex. To enable PIM-SM or PIM-DM multicast routing in a - router, the user must enable multicast routing and PIM processing in the - kernel (see SYNOPSIS about the kernel - configuration options), and must run a PIM-SM or PIM-DM capable user-level - process. From developer's point of view, the programming guide described in - the Programming Guide section - should be used to control the PIM processing in the kernel.

-
-

-

After a multicast routing socket is open and multicast forwarding - is enabled in the kernel (see multicast(4)), one of the - following socket options should be used to enable or disable PIM processing - in the kernel. Note that those options require certain privilege (i.e., root - privilege):

-
-
/* IPv4 */
-int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_PIM, (void *)&v, sizeof(v));
-
-
-
/* IPv6 */
-int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_PIM, (void *)&v, sizeof(v));
-
-

After PIM processing is enabled, the multicast-capable interfaces - should be added (see multicast(4)). In case of PIM-SM, the - PIM-Register virtual interface must be added as well. This can be - accomplished by using the following options:

-
-
/* IPv4 */
-struct vifctl vc;
-memset(&vc, 0, sizeof(vc));
-/* Assign all vifctl fields as appropriate */
-...
-if (is_pim_register_vif)
-    vc.vifc_flags |= VIFF_REGISTER;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc,
-           sizeof(vc));
-
-
-
/* IPv6 */
-struct mif6ctl mc;
-memset(&mc, 0, sizeof(mc));
-/* Assign all mif6ctl fields as appropriate */
-...
-if (is_pim_register_vif)
-    mc.mif6c_flags |= MIFF_REGISTER;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MIF, (void *)&mc,
-           sizeof(mc));
-
-

Sending or receiving of PIM packets can be accomplished by opening - first a “raw socket” (see socket(2)), with - protocol value of IPPROTO_PIM:

-
-
/* IPv4 */
-int pim_s4;
-pim_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_PIM);
-
-
-
/* IPv6 */
-int pim_s6;
-pim_s6 = socket(AF_INET6, SOCK_RAW, IPPROTO_PIM);
-
-

Then, the following system calls can be used to send or receive - PIM packets: sendto(2), sendmsg(2), - recvfrom(2), recvmsg(2).

-
-
-
-

-

getsockopt(2), recvfrom(2), - recvmsg(2), sendmsg(2), - sendto(2), setsockopt(2), - socket(2), inet(4), - intro(4), ip(4), - multicast(4)

-
-
-

-

The PIM-SM protocol is specified in RFC 2362 (to be replaced by - draft-ietf-pim-sm-v2-new-*). The PIM-DM protocol is - specified in draft-ietf-pim-dm-new-v2-*).

-
-
-

-

The original IPv4 PIM kernel support for IRIX and SunOS-4.x was - implemented by Ahmed Helmy (USC and SGI). Later the - code was ported to various BSD flavors and modified - by George Edmond Eddy (Rusty) (ISI), - Hitoshi Asaeda (WIDE Project), and - Pavlin Radoslavov (USC/ISI and ICSI). The IPv6 PIM - kernel support was implemented by the KAME project - (https://www.kame.net), and was based on the IPv4 - PIM kernel support.

-

This manual page was written by Pavlin - Radoslavov (ICSI).

-
-
- - - - - -
February 12, 2007FreeBSD 15.0
diff --git a/static/freebsd/man4/pms.4 3.html b/static/freebsd/man4/pms.4 3.html deleted file mode 100644 index 514b163a..00000000 --- a/static/freebsd/man4/pms.4 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
PMS(4)Device Drivers ManualPMS(4)
-
-
-

-

pms — PMC-Sierra - PM8001/8081/8088/8089/8074/8076/8077 SAS/SATA HBA Controller - driver

-
-
-

-

To compile the driver into the kernel, place the following line in - the kernel configuration file:

-
device pmspcv
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pmspcv_load="YES"
-
-
-
-

-

The pms driver provides support for the - PMC-Sierra PM8001/8081/8088/8089/8074/8076/8077 range of SAS/SATA HBA - controllers.

-
-
-

-

The pms driver supports the following - hardware:

-

-
    -
  • Tachyon TS Fibre Channel Card
    • -
  • Tachyon TL Fibre Channel Card
    • -
  • Tachyon XL2 Fibre Channel Card
    • -
  • Tachyon DX2 Fibre Channel Card
    • -
  • Tachyon DX2+ Fibre Channel Card
    • -
  • Tachyon DX4+ Fibre Channel Card
    • -
  • Tachyon QX2 Fibre Channel Card
    • -
  • Tachyon QX4 Fibre Channel Card
    • -
  • Tachyon DE4 Fibre Channel Card
    • -
  • Tachyon QE4 Fibre Channel Card
    • -
  • Tachyon XL10 Fibre Channel Card
    • -
  • PMC Sierra SPC SAS-SATA Card
    • -
  • PMC Sierra SPC-V SAS-SATA Card
    • -
  • PMC Sierra SPC-VE SAS-SATA Card
    • -
  • PMC Sierra SPC-V 16 Port SAS-SATA Card
    • -
  • PMC Sierra SPC-VE 16 Port SAS-SATA Card
    • -
  • PMC Sierra SPC-V SAS-SATA Card 12Gig
    • -
  • PMC Sierra SPC-VE SAS-SATA Card 12Gig
    • -
  • PMC Sierra SPC-V 16 Port SAS-SATA Card 12Gig
    • -
  • PMC Sierra SPC-VE 16 Port SAS-SATA Card 12Gig
    • -
  • Adaptec Hialeah 4/8 Port SAS-SATA HBA Card 6Gig
    • -
  • Adaptec Hialeah 4/8 Port SAS-SATA RAID Card 6Gig
    • -
  • Adaptec Hialeah 8/16 Port SAS-SATA HBA Card 6Gig
    • -
  • Adaptec Hialeah 8/16 Port SAS-SATA RAID Card 6Gig
    • -
  • Adaptec Hialeah 8/16 Port SAS-SATA HBA Encryption Card 6Gig
    • -
  • Adaptec Hialeah 8/16 Port SAS-SATA RAID Encryption Card 6Gig
    • -
  • Adaptec Delray 8 Port SAS-SATA HBA Card 12Gig
    • -
  • Adaptec Delray 8 Port SAS-SATA HBA Encryption Card 12Gig
    • -
  • Adaptec Delray 16 Port SAS-SATA HBA Card 12Gig
    • -
  • Adaptec Delray 16 Port SAS-SATA HBA Encryption Card 12Gig
    • -
-
-
-

-

cam(4), camcontrol(8)

-
-
-

-

The pms device driver first appeared in - FreeBSD 10.2.

-
-
- - - - - -
July 30, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/polling.4 3.html b/static/freebsd/man4/polling.4 3.html deleted file mode 100644 index 1dc51bd1..00000000 --- a/static/freebsd/man4/polling.4 3.html +++ /dev/null @@ -1,184 +0,0 @@ - - - - - - -
POLLING(4)Device Drivers ManualPOLLING(4)
-
-
-

-

polling — device - polling support

-
-
-

-

options DEVICE_POLLING

-
-
-

-

Device polling ( polling for brevity) - refers to a technique that lets the operating system periodically poll - devices, instead of relying on the devices to generate interrupts when they - need attention. This might seem inefficient and counterintuitive, but when - done properly, polling gives more control to the - operating system on when and how to handle devices, with a number of - advantages in terms of system responsiveness and performance.

-

In particular, polling reduces the - overhead for context switches which is incurred when servicing interrupts, - and gives more control on the scheduling of the CPU between various tasks - (user processes, software interrupts, device handling) which ultimately - reduces the chances of livelock in the system.

-
-

-

In the normal, interrupt-based mode, devices generate an interrupt - whenever they need attention. This in turn causes a context switch and the - execution of an interrupt handler which performs whatever processing is - needed by the device. The duration of the interrupt handler is potentially - unbounded unless the device driver has been programmed with real-time - concerns in mind (which is generally not the case for - FreeBSD drivers). Furthermore, under heavy traffic - load, the system might be persistently processing interrupts without being - able to complete other work, either in the kernel or in userland.

-

Device polling disables interrupts by polling devices at - appropriate times, i.e., on clock interrupts and within the idle loop. This - way, the context switch overhead is removed. Furthermore, the operating - system can control accurately how much work to spend in handling device - events, and thus prevent livelock by reserving some amount of CPU to other - tasks.

-

Enabling polling also changes the way - software network interrupts are scheduled, so there is never the risk of - livelock because packets are not processed to completion.

-
-
-

-

Currently only network interface drivers support the - polling feature. It is turned on and off with help - of ifconfig(8) command.

-

The historic kern.polling.enable, which - enabled polling for all interfaces, can be replaced with the following - code:

-
-
for i in `ifconfig -l` ;
-  do ifconfig $i polling; # use -polling to disable
-done
-
-
-
-

-

The operation of polling is controlled by - the following sysctl(8) MIB variables:

-

-
-
kern.polling.user_frac
-
When polling is enabled, and provided that there - is some work to do, up to this percent of the CPU cycles is reserved to - userland tasks, the remaining fraction being available for - polling processing. Default is 50. -

-
-
kern.polling.burst
-
Maximum number of packets grabbed from each network interface in each - timer tick. This number is dynamically adjusted by the kernel, according - to the programmed user_frac, - burst_max, CPU speed, and system load. -

-
-
kern.polling.each_burst
-
The burst above is split into smaller chunks of this number of packets, - going round-robin among all interfaces registered for - polling. This prevents the case that a large burst - from a single interface can saturate the IP interrupt queue - (net.inet.ip.intr_queue_maxlen). Default is 5. -

-
-
kern.polling.burst_max
-
Upper bound for kern.polling.burst. Note that when - polling is enabled, each interface can receive at - most (HZ * - burst_max) packets per second unless there are spare - CPU cycles available for polling in the idle loop. - This number should be tuned to match the expected load (which can be quite - high with GigE cards). Default is 150 which is adequate for 100Mbit - network and HZ=1000. -

-
-
kern.polling.idle_poll
-
Controls if polling is enabled in the idle loop. - There are no reasons (other than power saving or bugs in the scheduler's - handling of idle priority kernel threads) to disable this. -

-
-
kern.polling.reg_frac
-
Controls how often (every reg_frac - / HZ seconds) the status - registers of the device are checked for error conditions and the like. - Increasing this value reduces the load on the bus, but also delays the - error detection. Default is 20. -

-
-
kern.polling.handlers
-
How many active devices have registered for - polling. -

-
-
kern.polling.short_ticks
-
 
-
kern.polling.lost_polls
-
 
-
kern.polling.pending_polls
-
 
-
kern.polling.residual_burst
-
 
-
kern.polling.phase
-
 
-
kern.polling.suspect
-
 
-
kern.polling.stalled
-
Debugging variables.
-
-
-
-
-

-

Device polling requires explicit modifications to the device - drivers. As of this writing, the bge(4), - dc(4), em(4), fwe(4), - fwip(4), fxp(4), - igb(4), nfe(4), - nge(4), re(4), rl(4), - sis(4), ste(4), - stge(4), vge(4), - vr(4), and xl(4) devices are supported, - with others in the works. The modifications are rather straightforward, - consisting in the extraction of the inner part of the interrupt service - routine and writing a callback function, - (), - which is invoked to probe the device for events and process them. (See the - conditionally compiled sections of the devices mentioned above for more - details.)

-

As in the worst case the devices are only polled on clock - interrupts, in order to reduce the latency in processing packets, it is not - advisable to decrease the frequency of the clock below 1000 Hz.

-
-
-

-

Device polling first appeared in FreeBSD - 4.6 and FreeBSD 5.0.

-
-
-

-

Device polling was written by Luigi Rizzo - <luigi@iet.unipi.it>.

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ppbus.4 3.html b/static/freebsd/man4/ppbus.4 3.html deleted file mode 100644 index bdc642ad..00000000 --- a/static/freebsd/man4/ppbus.4 3.html +++ /dev/null @@ -1,355 +0,0 @@ - - - - - - -
PPBUS(4)Device Drivers ManualPPBUS(4)
-
-
-

-

ppbus — Parallel - Port Bus system

-
-
-

-

device ppbus

-

-
- device lpt -
- device plip -
- device ppi -
- device pps -
- device lpbb

-
-
-

-

The ppbus system provides a uniform, modular and - architecture-independent system for the implementation of drivers to control - various parallel devices, and to utilize different parallel port - chipsets.

-
-
-

-

In order to write new drivers or port existing drivers, the ppbus - system provides the following facilities:

-
    -
  • architecture-independent macros or functions to access parallel ports
    • -
  • mechanism to allow various devices to share the same parallel port
    • -
  • a user interface named ppi(4) that allows parallel port - access from outside the kernel without conflicting with kernel-in - drivers.
    • -
-
-

-

The ppbus system has been designed to support the development of - standard and non-standard software:

-

- - - - - - - - - - - - - - - - - -
Parallel port interface for general I/O
Pulse per second Timing Interface
Philips official parallel port I2C bit-banging interface
-
-
-

-

Another approach to the ppbus system is to port existing drivers. - Various drivers have already been ported:

-

- - - - - - - - - - - - - -
lpt printer driver
lp parallel network interface driver
-

ppbus should let you port any other software even from other - operating systems that provide similar services.

-
-
-
-

-

Parallel port chipset support is provided by - ppc(4).

-

The ppbus system provides functions and macros to allocate a new - parallel port bus, then initialize it and upper peripheral device - drivers.

-

ppc makes chipset detection and initialization and then calls - ppbus attach functions to initialize the ppbus system.

-
-
-

-

The logical parallel port model chosen for the ppbus system is the - PC's parallel port model. Consequently, for the i386 implementation of - ppbus, most of the services provided by ppc are macros for inb() and outb() - calls. But, for another architecture, accesses to one of our logical - registers (data, status, control...) may require more than one I/O - access.

-
-

-

The parallel port may operate in the following modes:

-
    -
  • compatible mode, also called Centronics mode
    • -
  • bidirectional 8/4-bits mode, also called NIBBLE mode
    • -
  • byte mode, also called PS/2 mode
    • -
  • Extended Capability Port mode, ECP
    • -
  • Enhanced Parallel Port mode, EPP
    • -
  • mixed ECP+EPP or ECP+PS/2 modes
    • -
-
-
-

-

This mode defines the protocol used by most PCs to transfer data - to a printer. In this mode, data is placed on the port's data lines, the - printer status is checked for no errors and that it is not busy, and then a - data Strobe is generated by the software to clock the data to the - printer.

-

Many I/O controllers have implemented a mode that uses a FIFO - buffer to transfer data with the Compatibility mode protocol. This mode is - referred to as "Fast Centronics" or "Parallel Port FIFO - mode".

-
-
-

-

The NIBBLE mode is the most common way to get reverse channel data - from a printer or peripheral. Combined with the standard host to printer - mode, it provides a complete bidirectional channel.

-

In this mode, outputs are 8-bits long. Inputs are accomplished by - reading 4 of the 8 bits of the status register.

-
-
-

-

In this mode, the data register is used either for outputs and - inputs. Then, any transfer is 8-bits long.

-
-
-

-

The ECP protocol was proposed as an advanced mode for - communication with printer and scanner type peripherals. Like the EPP - protocol, ECP mode provides for a high performance bidirectional - communication path between the host adapter and the peripheral.

-

ECP protocol features include:

-
    -
  • Run_Length_Encoding (RLE) data compression for host adapters
    • -
  • FIFOs for both the forward and reverse channels
    • -
  • DMA as well as programmed I/O for the host register interface.
    • -
-
-
-

-

The EPP protocol was originally developed as a means to provide a - high performance parallel port link that would still be compatible with the - standard parallel port.

-

The EPP mode has two types of cycle: address and data. What makes - the difference at hardware level is the strobe of the byte placed on the - data lines. Data are strobed with nAutofeed, addresses are strobed with - nSelectin signals.

-

A particularity of the ISA implementation of the EPP protocol is - that an EPP cycle fits in an ISA cycle. In this fashion, parallel port - peripherals can operate at close to the same performance levels as an - equivalent ISA plug-in card.

-

At software level, you may implement the protocol you wish, using - data and address cycles as you want. This is for the IEEE1284 compatible - part. Then, peripheral vendors may implement protocol handshake with the - following status lines: PError, nFault and Select. Try to know how these - lines toggle with your peripheral, allowing the peripheral to request more - data, stop the transfer and so on.

-

At any time, the peripheral may interrupt the host with the nAck - signal without disturbing the current transfer.

-
-
-

-

Some manufacturers, like SMC, have implemented chipsets that - support mixed modes. With such chipsets, mode switching is available at any - time by accessing the extended control register.

-
-
-
-

-
-

-

This standard is also named "IEEE Standard Signaling Method - for a Bidirectional Parallel Peripheral Interface for Personal - Computers". It defines a signaling method for asynchronous, fully - interlocked, bidirectional parallel communications between hosts and - printers or other peripherals. It also specifies a format for a peripheral - identification string and a method of returning this string to the host - outside of the bidirectional data stream.

-

This standard is architecture independent and only specifies - dialog handshake at signal level. One should refer to architecture specific - documentation in order to manipulate machine dependent registers, mapped - memory or other methods to control these signals.

-

The IEEE1284 protocol is fully oriented with all supported - parallel port modes. The computer acts as master and the peripheral as - slave.

-

Any transfer is defined as a finite state automaton. It allows - software to properly manage the fully interlocked scheme of the signaling - method. The compatible mode is supported "as is" without any - negotiation because it is compatible. Any other mode must be firstly - negotiated by the host to check it is supported by the peripheral, then to - enter one of the forward idle states.

-

At any time, the slave may want to send data to the host. This is - only possible from forward idle states (nibble, byte, ecp...). So, the host - must have previously negotiated to permit the peripheral to request - transfer. Interrupt lines may be dedicated to the requesting signals to - prevent time consuming polling methods.

-

But peripheral requests are only a hint to the master host. If the - host accepts the transfer, it must firstly negotiate the reverse mode and - then starts the transfer. At any time during reverse transfer, the host may - terminate the transfer or the slave may drive wires to signal that no more - data is available.

-
-
-

-

IEEE1284 Standard support has been implemented at the top of the - ppbus system as a set of procedures that perform high level functions like - negotiation, termination, transfer in any mode without bothering you with - low level characteristics of the standard.

-

IEEE1284 interacts with the ppbus system as little as possible. - That means you still have to request the ppbus when you want to access it, - the negotiate function does not do it for you. And of course, release it - later.

-
-
-
-

-
-

-

First, there is the - - layer, the lowest of the ppbus system. It provides chipset abstraction throw - a set of low level functions that maps the logical model to the underlying - hardware.

-

Secondly, there is the ppbus layer that provides - functions to:

-
    -
  1. share the parallel port bus among the daisy-chain like connected - devices
    2. -
  2. manage devices linked to ppbus
    3. -
  3. propose an arch-independent interface to access the hardware layer.
    4. -
-

Finally, the - layer - gathers the parallel peripheral device drivers.

-
-
-

-

We have to differentiate operating modes at various ppbus system - layers. Actually, ppbus and adapter operating modes on one hands and for - each one, current and available modes are separated.

-

With this level of abstraction a particular chipset may commute - from any native mode to any other mode emulated with extended modes without - disturbing upper layers. For example, most chipsets support NIBBLE mode as - native and emulated with ECP and/or EPP.

-

This architecture should support IEEE1284-1994 modes.

-
-
-
-

-
-

-

The boot process starts with the probe stage of the - ppc(4) driver during ISA bus (PC architecture) - initialization. During attachment of the ppc driver, a new ppbus structure - is allocated, then probe and attachment for this new bus node are - called.

-

ppbus attachment tries to detect any PnP parallel peripheral - (according to Plug and Play Parallel Port Devices - draft from (c)1993-4 Microsoft Corporation) then probes and attaches known - device drivers.

-

During probe, device drivers are supposed to request the ppbus and - try to set their operating mode. This mode will be saved in the context - structure and returned each time the driver requests the ppbus.

-
-
-

-

ppbus allocation is mandatory not to corrupt I/O of other devices. - Another usage of ppbus allocation is to reserve the port and receive - incoming interrupts.

-

High level interrupt handlers are connected to - the ppbus system thanks to the newbus - () - and - () - functions. But, in order to attach a handler, drivers must own the bus. - Consequently, a ppbus request is mandatory in order to call the above - functions (see existing drivers for more info). Note that the interrupt - handler is automatically released when the ppbus is released.

-
-
-

-

Microsequences is a general purpose mechanism to - allow fast low-level manipulation of the parallel port. Microsequences may - be used to do either standard (in IEEE1284 modes) or non-standard transfers. - The philosophy of microsequences is to avoid the overhead of the ppbus layer - and do most of the job at adapter level.

-

A microsequence is an array of opcodes and parameters. Each opcode - codes an operation (opcodes are described in microseq(9)). - Standard I/O operations are implemented at ppbus level whereas basic I/O - operations and microseq language are coded at adapter level for - efficiency.

-
-
-
-

-

lpt(4), plip(4), - ppc(4), ppi(4)

-
-
-

-

The ppbus manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
March 1, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/ppc.4 3.html b/static/freebsd/man4/ppc.4 3.html deleted file mode 100644 index 8b1368a2..00000000 --- a/static/freebsd/man4/ppc.4 3.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - -
PPC(4)Device Drivers ManualPPC(4)
-
-
-

-

ppc — Parallel - Port Chipset driver

-
-
-

-

device ppc

-

In /boot/device.hints: -
- hint.ppc.0.at="isa" -
- hint.ppc.0.irq="7"

-

For one or more PPBUS busses: -
- device ppbus

-
-
-

-

The ppc driver provides low level support - to various parallel port chipsets for the ppbus(4) - system.

-

During the probe phase, ppc detects - parallel port chipsets and initializes private data according to their - operating mode: COMPATIBLE, NIBBLE, PS/2, EPP, ECP and other mixed modes. If - a mode is provided at startup through the flags - variable of the boot interface, the operating mode of the chipset is forced - according to flags and the hardware supported - modes.

-

During the attach phase, ppc allocates a - ppbus structure, initializes it and calls the ppbus attach function.

-
-

-
    -
  • bits 0-3: chipset forced mode(s) -
    - 
    PPB_COMPATIBLE  0x0     /* Centronics compatible mode */
-PPB_NIBBLE      0x1     /* reverse 4 bit mode */
-PPB_PS2         0x2     /* PS/2 byte mode */
-PPB_EPP         0x4     /* EPP mode, 32 bit */
-PPB_ECP         0x8     /* ECP mode */
    -
    -

    And any mixed values.

    -
    • -
  • bit 4: EPP protocol (0 EPP 1.9, 1 EPP 1.7)
    • -
  • bit 5: activate IRQ (1 IRQ disabled, 0 IRQ enabled)
    • -
  • bit 6: disable chipset specific detection
    • -
  • bit 7: disable FIFO detection
    • -
-
-
-

-

Some parallel port chipsets are explicitly supported: detection - and initialisation code has been written according to their datasheets.

-
    -
  • SMC FDC37C665GT and FDC37C666GT chipsets
    • -
  • Natsemi PC873xx-family (PC87332 and PC87306)
    • -
  • Winbond W83877xx-family (W83877F and W83877AF)
    • -
  • SMC-like chipsets with mixed modes (see ppbus(4))
    • -
-
-
-

-

You may want to add support for the newest chipset your - motherboard was sold with. For the ISA bus, just retrieve the specs of the - chipset and write the corresponding - () - function. Then add an entry to the general purpose - () - function.

-

Your - () - function should ensure that if the mode field of the - flags boot variable is not null, then the operating - mode is forced to the given mode and no other mode is available and - ppb->ppb_avm field contains the available modes of the chipset.

-
-
-
-

-

ppbus(4), ppi(4), - device.hints(5)

-
-
-

-

The ppc manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
-

-

The chipset detection process may corrupt your chipset - configuration. You may disable chipset specific detection by using the above - flags.

-
-
- - - - - -
March 5, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/ppi.4 4.html b/static/freebsd/man4/ppi.4 4.html deleted file mode 100644 index ed868513..00000000 --- a/static/freebsd/man4/ppi.4 4.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
PPI(4)Device Drivers ManualPPI(4)
-
-
-

-

ppi — user-space - interface to ppbus parallel 'geek' port

-
-
-

-

device ppi

-

Minor numbering: unit numbers correspond directly to ppbus - numbers.

-

-
- #include <dev/ppbus/ppi.h> -
- #include - <dev/ppbus/ppbconf.h>

-
-
-

-

The ppi driver provides a convenient means - for user applications to manipulate the state of the parallel port, enabling - easy low-speed I/O operations without the security problems inherent with - the use of the /dev/io interface.

-
-
-

-

All I/O on the ppi interface is performed - using - () - calls. Each command takes a single uint8_t argument, - transferring one byte of data. The following commands are available:

-
-
, - PPISDATA
-
Get and set the contents of the data register.
-
, - PPISSTATUS
-
Get and set the contents of the status register.
-
, - PPISCTRL
-
Get and set the contents of the control register. The following defines - correspond to bits in this register. Setting a bit in the control register - drives the corresponding output low. -
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
-
, - PPISEPP
-
Get and set the contents of the EPP control register.
-
, - PPISECR
-
Get and set the contents of the ECP control register.
-
, - PPISFIFO
-
Read and write the ECP FIFO (8-bit operations only).
-
-
-
-

-

To present the value 0x5a to the data port, drive STROBE low and - then high again, the following code fragment can be used:

-
-
-	int		fd;
-	uint8_t		val;
-
-	val = 0x5a;
-	ioctl(fd, PPISDATA, &val);
-	ioctl(fd, PPIGCTRL, &val);
-	val |= STROBE;
-	ioctl(fd, PPISCTRL, &val);
-	val &= ~STROBE;
-	ioctl(fd, PPISCTRL, &val);
-
-
-
-
-
-

-

The inverse sense of signals is confusing.

-

The ioctl() interface is slow, and there - is no way (yet) to chain multiple operations together.

-

The headers required for user applications are not installed as - part of the standard system.

-
-
- - - - - -
January 2, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/procdesc.4 3.html b/static/freebsd/man4/procdesc.4 3.html deleted file mode 100644 index c27ae1ff..00000000 --- a/static/freebsd/man4/procdesc.4 3.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - -
PROCDESC(4)Device Drivers ManualPROCDESC(4)
-
-
-

-

procdesc — process - descriptor facility

-
-
-

-

procdesc is a file-descriptor-oriented - interface to process signalling and control, which supplements historic - UNIX fork(2) and - kill(2), primitives with new system calls such as - pdfork(2) and pdkill(2), - procdesc is designed for use with - capsicum(4), replacing process identifiers with - capability-oriented references. However, it can also be used independently - of capsicum(4), displacing PIDs, which may otherwise - suffer from race conditions. Given a process descriptor, it is possible to - query its conventional PID using pdgetpid(2).

-
-
-

-

fork(2), kill(2), - kqueue(2), pdfork(2), - pdgetpid(2), pdkill(2), - wait4(2), capsicum(4)

-
-
-

-

procdesc first appeared in - FreeBSD 9.0, and was developed at the University of - Cambridge.

-
-
-

-

procdesc was developed by - Robert Watson - <rwatson@FreeBSD.org> - and Jonathan Anderson - <jonathan@FreeBSD.org> - at the University of Cambridge, and Ben Laurie - <benl@FreeBSD.org> - and Kris Kennaway - <kris@FreeBSD.org> at - Google, Inc.

-
-
- - - - - -
May 15, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/procfs.4 3.html b/static/freebsd/man4/procfs.4 3.html deleted file mode 100644 index 8d08ccc5..00000000 --- a/static/freebsd/man4/procfs.4 3.html +++ /dev/null @@ -1,266 +0,0 @@ - - - - - - -
PROCFS(4)Device Drivers ManualPROCFS(4)
-
-
-

-

procfs — process - file system

-
-
-

-
-
proc		/proc	procfs	rw 0 0
-
-
-
-

-
This functionality is deprecated. Users are advised to use - libprocstat(3) and kvm(3) instead.
-

The process file system, or procfs, - implements a view of the system process table inside the file system. It is - normally mounted on /proc.

-

The procfs provides a two-level view of - process space, unlike the previous FreeBSD 1.1 - procfs implementation. At the highest level, - processes themselves are named, according to their process ids in decimal, - with no leading zeros. There is also a special node called - curproc which always refers to the process making - the lookup request.

-

Each node is a directory which contains the following entries:

-
-
dbregs
-
The debug registers as defined by struct dbregs in - <machine/reg.h>. - dbregs is currently only implemented on the i386 - architecture.
-
etype
-
The type of the executable referenced by the file - entry.
-
file
-
A symbolic link to the file from which the process text was read. This can - be used to gain access to the process' symbol table, or to start another - copy of the process. If the file cannot be found, the link target is - ‘unknown’.
-
fpregs
-
The floating point registers as defined by struct - fpregs in - <machine/reg.h>. - fpregs is only implemented on machines which have - distinct general purpose and floating point register sets.
-
map
-
A collection of lines describing the memory regions of the process, where - each line contains the following fields: -
-
start-address
-
The starting address for the region (inclusive).
-
end-address
-
The ending address for the region (exclusive).
-
resident
-
The number of resident pages.
-
private-resident
-
The number of resident pages that were private to the process.
-
obj
-
The virtual address of the struct vm_object - kernel data structure describing the memory region.
-
access
-
A three character string comprising the characters ‘r’, - ‘w’ and ‘x’, denoting read, write, and - execute permissions respectively. The lack of a permission is - represented by ‘-’.
-
ref_count
-
The number of references to the region.
-
shadow_count
-
The number of VM objects that this region is a shadow for.
-
flags
-
The flags for the object, see the flags named - in - <vm/vm_object.h>.
-
copy-on-write
-
Whether the region is copy-on-write. One of: -
-
COW
-
A copy-on-write region.
-
NCOW
-
A non-copy-on-write region.
-
-
-
needs-copy
-
Whether the region needs a copy. One of: -
-
NC
-
The region needs a copy.
-
NNC
-
The region does not need a copy.
-
-
-
type
-
The type of the region. One of: -
-
dead
-
A region associated with a dead VM object.
-
device
-
A region backed by device memory.
-
none
-
A region not backed by anything.
-
phys
-
A region backed by physical memory.
-
swap
-
A region backed by swap.
-
unknown
-
A region of unknown type.
-
vnode
-
A region backed by a file.
-
-
-
fullpath
-
The path to the file backing the memory region, or ‘-’ - if there is no such file.
-
cred
-
One of: -
-
CH
-
The region is being charged to the user specified in the - ‘charged-uid’ field.
-
NCH
-
The region is not being charged to any user.
-
-
-
charged-uid
-
The UID of the user being charged, or -1 if no user is being - charged.
-
-
-
mem
-
The complete virtual memory image of the process. Only those address which - exist in the process can be accessed. Reads and writes to this file modify - the process. Writes to the text segment remain private to the - process.
-
note
-
Used for sending signals to the process. Not implemented.
-
notepg
-
Used for sending signal to the process group. Not implemented.
-
osrel
-
Allows read and write of the kernel osrel value assigned to the process. - It affects the compatibility shims that are turned on and off depending on - the value. Initial process value is read from the ABI note tag in the - executed ELF image, and is zero if the tag not supported by binary format - or was not found.
-
regs
-
Allows read and write access to the process' register set. This file - contains a binary data structure struct regs - defined in - <machine/reg.h>. - regs can only be written when the process is - stopped.
-
rlimit
-
This is a read-only file containing the process current and maximum - limits. Each line is of the format rlimit current - max, with -1 indicating infinity.
-
status
-
The process status. This file is read-only and returns a single line - containing multiple space-separated fields as follows: -

-
    -
  • command name
    • -
  • process id
    • -
  • parent process id
    • -
  • process group id
    • -
  • session id
    • -
  • device name of the controlling terminal, or a minus sign - (“-”) if there is no controlling terminal.
    • -
  • a list of process flags: ctty if there is a - controlling terminal, sldr if the process is a - session leader, noflags if neither of the - other two flags are set.
    • -
  • the process start time in seconds and microseconds, comma - separated.
    • -
  • the user time in seconds and microseconds, comma separated.
    • -
  • the system time in seconds and microseconds, comma separated.
    • -
  • the wait channel message
    • -
  • the process effective UID
    • -
  • the process real UID
    • -
  • group list, starting with the effective GID, comma-separated
    • -
  • the hostname of the jail in which the process runs, or - ‘-’ to indicate that the process - is not running within a jail.
    • -
-
-
-

Each node is owned by the process's user, and belongs to that - user's primary group.

-
-
-

-
-
/proc
-
normal mount point for the procfs.
-
/proc/pid
-
directory containing process information for process - pid.
-
/proc/curproc
-
directory containing process information for the current process
-
/proc/self
-
directory containing process information for the current process
-
/proc/curproc/cmdline
-
the process executable name
-
/proc/curproc/etype
-
executable type
-
/proc/curproc/exe
-
executable image
-
/proc/curproc/file
-
executable image
-
/proc/curproc/fpregs
-
the process floating point register set
-
/proc/curproc/map
-
virtual memory map of the process
-
/proc/curproc/mem
-
the complete virtual address space of the process
-
/proc/curproc/note
-
used for signaling the process
-
/proc/curproc/notepg
-
used for signaling the process group
-
/proc/curproc/osrel
-
the process osrel value
-
/proc/curproc/regs
-
the process register set
-
/proc/curproc/rlimit
-
the process current and maximum rlimit
-
/proc/curproc/status
-
the process' current status
-
-
-
-

-

To mount a procfs file system on - /proc:

-

-
mount -t procfs proc - /proc
-
-
-

-

procstat(1), mount(2), - sigaction(2), unmount(2), - kvm(3), libprocstat(3), - pseudofs(9)

-
-
-

-

This manual page written by Garrett - Wollman, based on the description provided by - Jan-Simon Pendry, and revamped later by - Mike Pritchard.

-
-
- - - - - -
June 23, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/proto.4 3.html b/static/freebsd/man4/proto.4 3.html deleted file mode 100644 index c4eb5aed..00000000 --- a/static/freebsd/man4/proto.4 3.html +++ /dev/null @@ -1,349 +0,0 @@ - - - - - - -
PROTO(4)Device Drivers ManualPROTO(4)
-
-
-

-

proto — Generic - prototyping and diagnostics driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device proto
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
proto_load="YES"
-
-

To have the driver attach to a device instead of its regular - driver, mention it in the list of devices assigned to the following loader - variable:

-
hw.proto.attach="desc[,desc]"
-
-
-

-

The proto device driver attaches to PCI or - ISA devices when no other device drivers are present for those devices and - it creates device special files for all resources associated with the - device. The driver itself has no knowledge of the device it attaches to. - Programs can open these device special files and perform register-level - reads and writes. As such, the proto device driver - is nothing but a conduit or gateway between user space programs and the - hardware device.

-

Examples for why this is useful include hardware diagnostics and - prototyping. In both these use cases, it is far more convenient to develop - and run the logic in user space. Especially hardware diagnostics requires a - somewhat user-friendly interface and adequate reporting. Neither is done - easily as kernel code.

-
-

-

Device special files created for I/O port resources allow - lseek(2), read(2), - write(2) and ioctl(2) operations to be - performed on them. The read(2) and - write(2) system calls are used to perform input and output - (resp.) on the port. The amount of data that can be read or written at any - single time is either 1, 2 or 4 bytes. While the - proto driver does not prevent reading or writing 8 - bytes at a time for some architectures, it should not be assumed that such - actually produces correct results. The lseek(2) system - call is used to select the port number, relative to the I/O port region - being represented by the device special file. If, for example, the device - special file corresponds to an I/O port region from 0x3f8 to 0x3ff - inclusive, then an offset of 4 given to lseek with a whence value of - SEEK_SET will target port 0x3fc on the next read or write operation. The - ioctl(2) system call can be used for the - PROTO_IOC_REGION request. This ioctl request returns - the extend of the resource covered by this device special file. The extend - is returned in the following structure:

-
-
struct proto_ioc_region {
-        unsigned long   address;
-        unsigned long   size;
-};
-
-
-
-

-

The device special files created for memory mapped I/O resources - behave in the same way as those created for I/O port resources. - Additionally, device special files for memory mapped I/O resources allow the - memory to be mapped into the process' address space using - mmap(2). Reads and writes to the memory address returned - by mmap(2) go directly to the hardware. As such the use of - read(2) and write(2) can be avoided, - reducing the access overhead significantly. Alignment and access width - constraints put forth by the underlying device apply. Also, make sure the - compiler does not optimize memory accesses away or has them coalesced into - bigger accesses.

-
-
-

-

A device special file named busdma is - created for the purpose of doing DMA. It only supports - ioctl(2) and only for the - PROTO_IOC_BUSDMA request. This device special file - does not support read(2) nor write(2). - The PROTO_IOC_BUSDMA request has an argument that is - both in and out and is defined as follows:

-
-
struct proto_ioc_busdma {
-        unsigned int    request;
-        unsigned long   key;
-        union {
-                struct {
-                        unsigned long   align;
-                        unsigned long   bndry;
-                        unsigned long   maxaddr;
-                        unsigned long   maxsz;
-                        unsigned long   maxsegsz;
-                        unsigned int    nsegs;
-                        unsigned int    datarate;
-                        unsigned int    flags;
-                } tag;
-                struct {
-                        unsigned long   tag;
-                        unsigned int    flags;
-                        unsigned long   virt_addr;
-                        unsigned long   virt_size;
-                        unsigned int    phys_nsegs;
-                        unsigned long   phys_addr;
-                        unsigned long   bus_addr;
-                        unsigned int    bus_nsegs;
-                } md;
-                struct {
-                        unsigned int    op;
-                        unsigned long   base;
-                        unsigned long   size;
-                } sync;
-        } u;
-        unsigned long   result;
-};
-
-The request field is used to specify which DMA operation - is to be performed. The key field is used to specify - which object the operation applies to. An object is either a tag or a memory - descriptor (md). The following DMA operations are defined: -
-
PROTO_IOC_BUSDMA_TAG_CREATE
-
Create a root tag. The result field is set on output - with the key of the DMA tag. The tag is created with the constraints given - by the tag sub-structure. These constraints - correspond roughly to those that can be given to the - bus_dma_tag_create(9) function.
-
PROTO_IOC_BUSDMA_TAG_DERIVE
-
Create a derived tag. The key field is used to - identify the parent tag from which to derive the new tag. The key of the - derived tag is returned in the result field. The - derived tag combines the constraints of the parent tag with those given by - the tag sub-structure. The combined constraints are - written back to the tag sub-structure on - return.
-
PROTO_IOC_BUSDMA_TAG_DESTROY
-
Destroy a root or derived tag previously created. The - key field specifies the tag to destroy. A tag can - only be destroyed when not referenced anymore. This means that derived - tags that have this tag as a parent and memory descriptors created from - this tag must be destroyed first.
-
PROTO_IOC_BUSDMA_MEM_ALLOC
-
Allocate memory that satisfies the constraints put forth by the tag given - in the tag field of the md - sub-structure. The key of the memory descriptor for this memory is - returned in the result field. The - md sub-structure is filled on return with details of - the allocation. The kernel virtual address and the size of the allocated - memory are returned in the virt_addr and - virt_size fields. The number of contiguous physical - memory segments and the address of the first segment are returned in the - phys_nsegs and phys_addr - fields. Allocated memory is automatically loaded and thus mapped into bus - space. The number of bus segments and the address of the first segment are - returned in the bus_nsegs and - bus_addr fields. The behaviour of this operation - banks heavily on how bus_dmamem_alloc(9) is implemented, - which means that memory is currently always allocated as a single - contiguous region of physical memory. In practice this also tends to give - a single contiguous region in bus space. This may change over time.
-
PROTO_IOC_BUSDMA_MEM_FREE
-
Free previously allocated memory and destroy the memory descriptor. The - proto driver is not in a position to track whether - the memory has been mapped in the process' address space, so the - application is responsible for unmapping the memory before it is freed. - The proto driver also cannot protect against the - hardware writing to or reading from the memory, even after it has been - freed. When the memory is reused for other purposes it can be corrupted or - cause the hardware to behave in unpredictable ways when DMA has not - stopped completely before freeing.
-
PROTO_IOC_BUSDMA_MD_CREATE
-
Create an empty memory descriptor with the tag specified in the - tag field of the md - sub-structure. The key of the memory descriptor is returned in the - result field.
-
PROTO_IOC_BUSDMA_MD_DESTROY
-
Destroy the previously created memory descriptor specified by the - key field. When the memory descriptor is still - loaded, it is unloaded first.
-
PROTO_IOC_BUSDMA_MD_LOAD
-
Load a contiguous region of memory in the memory descriptor specified by - the key field. The size and address in the process' - virtual address space are specified by the virt_size - and virt_addr fields. On return, the - md sub-structure contains the result of the - operation. The number of physical segments and the address of the first - segment is returned in the phys_nsegs and - phys_addr fields. The number of bus space segments - and the address of the first segment in bus space is returned in the - bus_nsegs and bus_addr - fields.
-
PROTO_IOC_BUSDMA_MD_UNLOAD
-
Unload the memory descriptor specified by the key - field.
-
PROTO_IOC_BUSDMA_SYNC
-
Guarantee that all hardware components have a coherent view of the memory - tracked by the memory descriptor, specified by the - key field. A sub-section of the memory can be - targeted by specifying the relative offset and size of the memory to make - coherent. The offset and size are given by the base - and size fields of the sync - sub-structure. The op field holds the sync operation - to be performed. This is similar to the - bus_dmamap_sync(9) function.
-
-
-
-

-

Access to PCI configuration space is possible through the - pcicfg device special file. The device special file - supports lseek(2), read(2) and - write(2). Usage is the asme as for I/O port resources.

-
-
-
-

-

All device special files corresponding to a PCI device are located - under - /dev/proto/pci<d>:<b>:<s>:<f> - with pci<d>:<b>:<s>:<f> - representing the location of the PCI device in the PCI hierarchy. A PCI - location includes:

-

-
-
-
<d>
-
The PCI domain number
-
<b>
-
The PCI bus number
-
<s>
-
The PCI slot or device number
-
<f>
-
The PCI function number
-
-
-

Every PCI device has a device special file called - pcicfg. This device special file gives access to the - PCI configuration space. A device special file called - busdma is also created. This device special file - provides the interfaces needed for doing DMA. For each valid base address - register (BAR), a device special file is created that contains the BAR - offset and the resource type. A resource type can be either - io or mem representing I/O - port or memory mapped I/O space (resp.)

-

ISA devices do not have a location. Instead, they are identified - by the first I/O port address or first memory mapped I/O address. - Consequently, all device special files corresponding to an ISA device are - located under /dev/proto/isa:<addr> with - addr the address in hexadecimal notation. For each - I/O port or memory mapped I/O address, a device special file is created that - contains the resource identification used by the kernel and the resource - type. The resource type can be either io or - mem representing I/O port or memory mapped I/O space - (resp.) When the device has a DMA channel assigned to it, a device special - file with the name busdma is created as well. This - device special file provides the interfaces needed for doing DMA.

-

If the ISA device is not a Plug-and-Play device nor present in the - ACPI device tree, it must have the appropriate hints so that the kernel can - reserve the resources for it.

-
-
-

-

A single function PCI device in domain 0, on bus 1, in slot 2 and - having a single memory mapped I/O region will have the following device - special files:

-

-
-
-
/dev/proto/pci0:1:2:0/10.mem
-
 
-
/dev/proto/pci0:1:2:0/pcicfg
-
 
-
-
-

A legacy floppy controller will have the following device - files:

-

-
-
-
/dev/proto/isa:0x3f0/00.io
-
 
-
/dev/proto/isa:0x3f0/01.io
-
 
-
/dev/proto/isa:0x3f0/busdma
-
 
-
-
-
-
-

-

ioctl(2), lseek(2), - mmap(2), read(2), - write(2), bus_dma_tag_create(9), - bus_dmamap_sync(9), - bus_dmamem_alloc(9)

-
-
-

-

The proto device driver and this manual - page were written by Marcel Moolenaar - <marcel@xcllnt.net>.

-
-
-

-

Because programs have direct access to the hardware, the - proto driver is inherently insecure. It is not - advisable to use this driver on a production machine.

-
-
-

-

The proto driver does not fully support - memory descriptors that need multiple physical memory segments or multiple - bus space segments. At the very least, an operation is needed on the DMA - pseudo resource for the application to obtain all segments.

-

The proto driver does not yet support - interrupts. Since interrupts cannot be handled by the driver itself, they - must be converted into signals and delivered to the program that has - registered for interrupts. A satisfactory mechanism for keeping the - interrupt masked during the signal handling is still being worked out.

-

DMA support for devices other than busmaster devices is not - present yet. The details of how a program is to interact with the DMA - controller still need to be fleshed out.

-
-
- - - - - -
August 7, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/ps4dshock.4 3.html b/static/freebsd/man4/ps4dshock.4 3.html deleted file mode 100644 index 7fb52435..00000000 --- a/static/freebsd/man4/ps4dshock.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
PS4DSHOCK(4)Device Drivers ManualPS4DSHOCK(4)
-
-
-

-

ps4dshock — Sony - PlayStation 4 Dualshock 4 gamepad driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ps4dshock -
-device hid -
-device hidbus -
-device hidmap -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ps4dshock_load="YES"
-
-
-
-

-

The ps4dshock driver provides support for - Sony PlayStation 4 Dualshock 4 gamepad driver.

-

The /dev/input/event* device - presents the game controller as a evdev type device. - It is accessible to members of the - group.

-
-
-

-

Next parameters are available as sysctl(8) - variables. Debug parameter is available as loader(8) - tunable as well.

-
-
dev.p4dshock.*.led_state
-
LED state: 0 - off, 1 - on, 2 - blinking.
-
dev.p4dshock.*.led_color_r
-
LED color. Red component.
-
dev.p4dshock.*.led_color_g
-
LED color. Green component.
-
dev.p4dshock.*.led_color_b
-
LED color. Blue component.
-
dev.p4dshock.*.led_delay_on
-
LED blink. On delay, msecs.
-
dev.p4dshock.*.led_delay_off
-
LED blink. Off delay, msecs.
-
hw.hid.ps4dshock.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/input/event*
-
input event device node.
-
-
-
-

-

The ps4dshock does not support - force-feedback events.

-
-
-

-

The ps4dshock driver first appeared in - FreeBSD 13.0.

-
-
-

-

The ps4dshock driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
November 30, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/psm.4 3.html b/static/freebsd/man4/psm.4 3.html deleted file mode 100644 index f3e8781e..00000000 --- a/static/freebsd/man4/psm.4 3.html +++ /dev/null @@ -1,663 +0,0 @@ - - - - - - -
PSM(4)Device Drivers ManualPSM(4)
-
-
-

-

psm — PS/2 mouse - style pointing device driver

-
-
-

-

options KBD_RESETDELAY=N -
- options KBD_MAXWAIT=N -
- options PSM_DEBUG=N -
- options KBDIO_DEBUG=N -
- device psm

-

In /boot/device.hints: -
- hint.psm.0.at="atkbdc" -
- hint.psm.0.irq="12"

-
-
-

-

The psm driver provides support for the - PS/2 mouse style pointing device. Currently there can be only one - psm device node in the system. As the PS/2 mouse - port is located at the auxiliary port of the keyboard controller, the - keyboard controller driver, atkbdc, must also be - configured in the kernel. Note that there is currently no provision of - changing the - - number.

-

Basic PS/2 style pointing device has two or three buttons. Some - devices may have a roller or a wheel and/or additional buttons.

-
-

-

The PS/2 style pointing device usually has several grades of - resolution, that is, sensitivity of movement. They are typically 25, 50, 100 - and 200 pulse per inch. Some devices may have finer resolution. The current - resolution can be changed at runtime. The psm driver - allows the user to initially set the resolution via the driver flag (see - DRIVER CONFIGURATION) or - change it later via the ioctl(2) command - MOUSE_SETMODE (see - IOCTLS).

-
-
-

-

Frequency, or report rate, at which the device sends movement and - button state reports to the host system is also configurable. The PS/2 style - pointing device typically supports 10, 20, 40, 60, 80, 100 and 200 reports - per second. 60 or 100 appears to be the default value for many devices. Note - that when there is no movement and no button has changed its state, the - device will not send anything to the host system. The report rate can be - changed via an ioctl call.

-
-
-

-

The psm driver has three levels of - operation. The current operation level can be set via an ioctl call.

-

At the level zero the basic support is provided; the device driver - will report horizontal and vertical movement of the attached device and - state of up to three buttons. The movement and status are encoded in a - series of fixed-length data packets (see - Data Packet Format). This is - the default level of operation and the driver is initially at this level - when opened by the user program.

-

The operation level one, the `extended' level, supports a roller - (or wheel), if any, and up to 11 buttons. The movement of the roller is - reported as movement along the Z axis. 8 byte data packets are sent to the - user program at this level.

-

At the operation level two, data from the pointing device is - passed to the user program as is. Conversely, command from the user program - is passed to the pointing device as is and the user program is responsible - for status validation and error recovery. Modern PS/2 type pointing devices - often use proprietary data format. Therefore, the user program is expected - to have intimate knowledge about the format from a particular device when - operating the driver at this level. This level is called `native' level.

-
-
-

-

Data packets read from the psm driver are - formatted differently at each operation level.

-

A data packet from the PS/2 mouse style pointing device is three - bytes long at the operation level zero:

-

-
-
Byte 1
-
-
-
bit 7
-
One indicates overflow in the vertical movement count.
-
bit 6
-
One indicates overflow in the horizontal movement count.
-
bit 5
-
Set if the vertical movement count is negative.
-
bit 4
-
Set if the horizontal movement count is negative.
-
bit 3
-
Always one.
-
bit 2
-
Middle button status; set if pressed. For devices without the middle - button, this bit is always zero.
-
bit 1
-
Right button status; set if pressed.
-
bit 0
-
Left button status; set if pressed.
-
-
-
Byte 2
-
Horizontal movement count in two's complement; -256 through 255. Note that - the sign bit is in the first byte.
-
Byte 3
-
Vertical movement count in two's complement; -256 through 255. Note that - the sign bit is in the first byte.
-
-

At the level one, a data packet is encoded in the standard format - MOUSE_PROTO_SYSMOUSE as defined in - mouse(4).

-

At the level two, native level, there is no standard on the size - and format of the data packet.

-
-
-

-

The psm driver can somewhat `accelerate' - the movement of the pointing device. The faster you move the device, the - further the pointer travels on the screen. The driver has an internal - variable which governs the effect of the acceleration. Its value can be - modified via the driver flag or via an ioctl call.

-
-
-
-

-
-

-

There are following kernel configuration options to control the - psm driver. They may be set in the kernel - configuration file (see config(8)).

-
-
, -
-
The psm driver will attempt to reset the pointing - device during the boot process. It sometimes takes a long while before the - device will respond after reset. These options control how long the driver - should wait before it eventually gives up waiting. The driver will wait - X * Y msecs at most. If the - driver seems unable to detect your pointing device, you may want to - increase these values. The default values are 200 msec for - X and 5 for Y.
-
, -
-
Sets the debug level to N. The default debug level - is zero. See DIAGNOSTICS for debug - logging.
-
-
-
-

-

The psm driver accepts the following - driver flags. Set them in /boot/device.hints (see - EXAMPLES below).

-
-
bit 0..3 RESOLUTION
-
This flag specifies the resolution of the pointing device. It must be zero - through four. The greater the value is, the finer resolution the device - will select. Actual resolution selected by this field varies according to - the model of the device. Typical resolutions are: -

-
-
-
25 pulse per inch (ppi)
-
2 (medium low)
-
50 ppi
-
3 (medium high)
-
100 ppi
-
-
200 ppi
-
-

Leaving this flag zero will selects the default resolution for - the device (whatever it is).

-
-
bit 4..7 ACCELERATION
-
This flag controls the amount of acceleration effect. The smaller the - value of this flag is, more sensitive the movement becomes. The minimum - value allowed, thus the value for the most sensitive setting, is one. - Setting this flag to zero will completely disables the acceleration - effect.
-
bit 8 NOCHECKSYNC
-
The psm driver tries to detect the first byte of - the data packet by checking the bit pattern of that byte. Although this - method should work with most PS/2 pointing devices, it may interfere with - some devices which are not so compatible with known devices. If you think - your pointing device is not functioning as expected, and the kernel - frequently prints the following message to the console, -
- 
psmintr: out of sync (xxxx != yyyy).
-
-

set this flag to disable synchronization check and see if it - helps.

-
-
bit 9 NOIDPROBE
-
The psm driver will not try to identify the model - of the pointing device and will not carry out model-specific - initialization. The device should always act like a standard PS/2 mouse - without such initialization. Extra features, such as wheels and additional - buttons, will not be recognized by the psm - driver.
-
bit 10 NORESET
-
When this flag is set, the psm driver will not - reset the pointing device when initializing the device. If the - FreeBSD kernel is started after another OS has - run, the pointing device will inherit settings from the previous OS. - However, because there is no way for the psm - driver to know the settings, the device and the driver may not work - correctly. The flag should never be necessary under normal - circumstances.
-
bit 11 FORCETAP
-
Some pad devices report as if the fourth button is pressed when the user - `taps' the surface of the device (see - CAVEATS). This flag will make the - psm driver assume that the device behaves this - way. Without the flag, the driver will assume this behavior for ALPS - GlidePoint models only.
-
bit 12 IGNOREPORTERROR
-
This flag makes psm driver ignore certain error - conditions when probing the PS/2 mouse port. It should never be necessary - under normal circumstances.
-
bit 13 HOOKRESUME
-
The built-in PS/2 pointing device of some laptop computers is somehow not - operable immediately after the system `resumes' from the power saving - mode, though it will eventually become available. There are reports that - stimulating the device by performing I/O will help waking up the device - quickly. This flag will enable a piece of code in the - psm driver to hook the `resume' event and exercise - some harmless I/O operations on the device.
-
bit 14 INITAFTERSUSPEND
-
This flag adds more drastic action for the above problem. It will cause - the psm driver to reset and re-initialize the - pointing device after the `resume' event.
-
-
-
-
-

-

Extended support for Synaptics touchpads can be enabled by setting - hw.psm.synaptics_support to 1 at - boot-time. This will enable psm to handle packets - from guest devices (sticks) and extra buttons. Similarly, extended support - for IBM/Lenovo TrackPoint and Elantech touchpads can be enabled by setting - hw.psm.trackpoint_support or - hw.psm.elantech_support, respectively, to - 1 at boot-time.

-

Tap and drag gestures can be disabled by setting - hw.psm.tap_enabled to 0 at - boot-time. Currently, this is supported on Synaptics touchpads regardless of - Extended support state and on Elantech touchpads with Extended support - enabled. The behaviour may be changed after boot by setting the sysctl with - the same name and by restarting moused(8) using - /etc/rc.d/moused.

-

Active multiplexing support can be disabled by setting - hw.psm.mux_disabled to 1 at - boot-time. This will prevent psm from enabling - active multiplexing mode needed for some Synaptics touchpads.

-
-
-

-

There are a few ioctl(2) commands for mouse - drivers. These commands and related structures and constants are defined in - <sys/mouse.h>. General - description of the commands is given in mouse(4). This - section explains the features specific to the psm - driver.

-

-
-
- int *level
-
 
-
- int *level
-
These commands manipulate the operation level of the - psm driver. -

-
-
- mousehw_t *hw
-
Returns the hardware information of the attached device in the following - structure. -
- 
typedef struct mousehw {
-    int buttons;    /* number of buttons */
-    int iftype;     /* I/F type */
-    int type;       /* mouse/track ball/pad... */
-    int model;      /* I/F dependent model ID */
-    int hwid;       /* I/F dependent hardware ID */
-} mousehw_t;
-
-

The buttons field holds the number of - buttons on the device. The psm driver currently - can detect the 3 button mouse from Logitech and report accordingly. The - 3 button mouse from the other manufacturer may or may not be reported - correctly. However, it will not affect the operation of the driver.

-

The iftype is always - MOUSE_IF_PS2.

-

The type tells the device type: - MOUSE_MOUSE, - MOUSE_TRACKBALL, - MOUSE_STICK, MOUSE_PAD, - or MOUSE_UNKNOWN. The user should not heavily - rely on this field, as the driver may not always, in fact it is very - rarely able to, identify the device type.

-

The model is always - MOUSE_MODEL_GENERIC at the operation level 0. It - may be MOUSE_MODEL_GENERIC or one of - MOUSE_MODEL_XXX constants at higher operation - levels. Again the psm driver may or may not set - an appropriate value in this field.

-

The hwid is the ID value returned by - the device. Known IDs include:

-

-
-
-
Mouse (Microsoft, Logitech and many other manufacturers)
-
-
Microsoft Ballpoint mouse
-
-
Microsoft IntelliMouse
-
-

-
-
- synapticshw_t *synhw
-
Retrieves extra information associated with Synaptics Touchpad. Only - available when a supported device has been detected. -
- 
typedef struct synapticshw {
-    int infoMajor;	/* major hardware revision */
-    int infoMinor;	/* minor hardware revision */
-    int infoRot180;	/* touchpad is rotated */
-    int infoPortrait;	/* touchpad is a portrait */
-    int infoSensor;	/* sensor model */
-    int infoHardware;	/* hardware model */
-    int infoNewAbs;	/* supports the newabs format */
-    int capPen;		/* can detect a pen */
-    int infoSimplC;	/* supports simple commands */
-    int infoGeometry;	/* touchpad dimensions */
-    int capExtended;	/* supports extended packets */
-    int capSleep;	/* can be suspended/resumed */
-    int capFourButtons;	/* has four buttons */
-    int capMultiFinger;	/* can detect multiple fingers */
-    int capPalmDetect;	/* can detect a palm */
-    int capPassthrough;	/* can passthrough guest packets */
-    int capMiddle;	/* has a physical middle button */
-    int nExtendedButtons; /* has N additional buttons */
-    int nExtendedQueries; /* supports N extended queries */
-} synapticshw_t;
-
-

See the - for more information about the fields in this - structure.

-

-
-
- mousemode_t *mode
-
The command gets the current operation parameters of the mouse driver. -
- 
typedef struct mousemode {
-    int protocol;    /* MOUSE_PROTO_XXX */
-    int rate;        /* report rate (per sec), -1 if unknown */
-    int resolution;  /* MOUSE_RES_XXX, -1 if unknown */
-    int accelfactor; /* acceleration factor */
-    int level;       /* driver operation level */
-    int packetsize;  /* the length of the data packet */
-    unsigned char syncmask[2]; /* sync. bits */
-} mousemode_t;
-
-

The protocol is - MOUSE_PROTO_PS2 at the operation level zero and - two. MOUSE_PROTO_SYSMOUSE at the operation level - one.

-

The rate is the status report rate - (reports/sec) at which the device will send movement report to the host - computer. Typical supported values are 10, 20, 40, 60, 80, 100 and 200. - Some mice may accept other arbitrary values too.

-

The resolution of the pointing device - must be one of MOUSE_RES_XXX constants or a - positive value. The greater the value is, the finer resolution the mouse - will select. Actual resolution selected by the - MOUSE_RES_XXX constant varies according to the - model of mouse. Typical resolutions are:

-

-
-
-
25 ppi
-
-
50 ppi
-
-
100 ppi
-
-
200 ppi
-
-

The accelfactor field holds a value to - control acceleration feature (see - Acceleration). It must be zero or - greater. If it is zero, acceleration is disabled.

-

The packetsize field specifies the - length of the data packet. It depends on the operation level and the - model of the pointing device.

-

-
-
-
3 bytes
-
-
8 bytes
-
-
Depends on the model of the device
-
-

The array syncmask holds a bit mask - and pattern to detect the first byte of the data packet. - syncmask[0] is the bit mask to be ANDed with a - byte. If the result is equal to syncmask[1], the - byte is likely to be the first byte of the data packet. Note that this - detection method is not 100% reliable, thus, should be taken only as an - advisory measure.

-

-
-
- mousemode_t *mode
-
The command changes the current operation parameters of the mouse driver - as specified in mode. Only - rate, resolution, - level and accelfactor may - be modifiable. Setting values in the other field does not generate error - and has no effect. -

If you do not want to change the current setting of a field, - put -1 there. You may also put zero in - resolution and rate, and - the default value for the fields will be selected.

-

-
-
- mousedata_t *data
-
 
-
- mousedata_t *state
-
These commands are not currently supported by the - psm driver. -

-
-
- mousestatus_t *status
-
The command returns the current state of buttons and movement counts as - described in mouse(4).
-
-
-
-

-
-
/dev/psm0
-
`non-blocking' device node
-
/dev/bpsm0
-
`blocking' device node
-
-
-
-

-

In order to install the psm driver, you - need to add

-

-
device atkbdc
-
device psm
-

to your kernel configuration file, and put the following lines to - /boot/device.hints.

-

-
hint.atkbdc.0.at="isa"
-
hint.atkbdc.0.port="0x060"
-
hint.psm.0.at="atkbdc"
-
hint.psm.0.irq="12"
-

If you add the following statement to - /boot/device.hints,

-

-
hint.psm.0.flags="0x2000"
-

you will add the optional code to stimulate the pointing device - after the `resume' event.

-

-
hint.psm.0.flags="0x24"
-

The above line will set the device resolution high (4) and the - acceleration factor to 2.

-
-
-

-

At debug level 0, little information is logged except for the - following line during boot process:

-
-
psm0: device ID X
-
-

where X the device ID code returned by the - found pointing device. See MOUSE_GETINFO for known - IDs.

-

At debug level 1 more information will be logged while the driver - probes the auxiliary port (mouse port). Messages are logged with the - LOG_KERN facility at the LOG_DEBUG level (see - syslogd(8)).

-
-
psm0: current command byte:xxxx
-kbdio: TEST_AUX_PORT status:0000
-kbdio: RESET_AUX return code:00fa
-kbdio: RESET_AUX status:00aa
-kbdio: RESET_AUX ID:0000
-[...]
-psm: status 00 02 64
-psm0 irq 12 on isa
-psm0: model AAAA, device ID X, N buttons
-psm0: config:00000www, flags:0000uuuu, packet size:M
-psm0: syncmask:xx, syncbits:yy
-
-

The first line shows the command byte value of the keyboard - controller just before the auxiliary port is probed. It usually is 40, 45, - 47 or 65, depending on how the motherboard BIOS initialized the keyboard - controller upon power-up.

-

The second line shows the result of the keyboard controller's test - on the auxiliary port interface, with zero indicating no error; note that - some controllers report no error even if the port does not exist in the - system, however.

-

The third through fifth lines show the reset status of the - pointing device. The functioning device should return the sequence of FA AA - <ID>. The ID code is described above.

-

The seventh line shows the current hardware settings. These bytes - are formatted as follows:

-

-
-
Byte 1
-
-
-
bit 7
-
Reserved.
-
bit 6
-
0 - stream mode, 1 - remote mode. In the stream mode, the pointing - device sends the device status whenever its state changes. In the - remote mode, the host computer must request the status to be sent. The - psm driver puts the device in the stream - mode.
-
bit 5
-
Set if the pointing device is currently enabled. Otherwise zero.
-
bit 4
-
0 - 1:1 scaling, 1 - 2:1 scaling. 1:1 scaling is the default.
-
bit 3
-
Reserved.
-
bit 2
-
Left button status; set if pressed.
-
bit 1
-
Middle button status; set if pressed.
-
bit 0
-
Right button status; set if pressed.
-
-
-
Byte 2
-
-
-
bit 7
-
Reserved.
-
bit 6..0
-
Resolution code: zero through three. Actual resolution for the - resolution code varies from one device to another.
-
-
-
Byte 3
-
The status report rate (reports/sec) at which the device will send - movement report to the host computer.
-
-

Note that the pointing device will not be enabled until the - psm driver is opened by the user program.

-

The rest of the lines show the device ID code, the number of - detected buttons and internal variables.

-

At debug level 2, much more detailed information is logged.

-
-
-

-

ioctl(2), syslog(3), - atkbdc(4), mouse(4), - sysmouse(4), moused(8), - syslogd(8)

-

Synaptics TouchPad Interfacing - Guide, - http://www.synaptics.com/.

-
-
-

-

The psm driver is based on the work done - by quite a number of people, including Eric - Forsberg, Sandi Donno, Rick - Macklem, Andrew Herbert, - Charles Hannum, Shoji Yuen - and Kazutaka Yokota to name the few.

-

This manual page was written by Kazutaka - Yokota - <yokota@FreeBSD.org>.

-
-
-

-

Many pad devices behave as if the first (left) button were pressed - if the user `taps' the surface of the pad. In contrast, some pad products, - e.g. some versions of ALPS GlidePoint and Interlink VersaPad, treat the - tapping action as fourth button events.

-

It is reported that ALPS GlidePoint, - Synaptics Touchpad, IBM/Lenovo TrackPoint, and Interlink VersaPad require - - flag in order to recover from suspended state. This flag is automatically - set when one of these devices is detected by the psm - driver.

-

Some PS/2 mouse models from MouseSystems require to be put in the - high resolution mode to work properly. Use the driver flag to set - resolution.

-

There is not a guaranteed way to re-synchronize with the first - byte of the packet once we are out of synchronization with the data stream. - However, if you are using the XFree86 server and experiencing the - problem, you may be able to make the X server synchronize with the mouse by - switching away to a virtual terminal and getting back to the X server, - unless the X server is accessing the mouse via moused(8). - Clicking any button without moving the mouse may also work.

-
-
-

-

Enabling the extended support for Synaptics touchpads has been - reported to cause problems with responsivity on some (newer) models of - Synaptics hardware, particularly those with guest devices.

-
-
- - - - - -
June 2, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/pst.4 3.html b/static/freebsd/man4/pst.4 3.html deleted file mode 100644 index df60cb4f..00000000 --- a/static/freebsd/man4/pst.4 3.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
PST(4)Device Drivers ManualPST(4)
-
-
-

-

pst — device - driver for Promise Supertrak SX6000

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device pst
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pst_load="YES"
-
-
-
-

-

This driver is for the Promise Supertrak SX6000 ATA hardware RAID - controller. It supports (in hardware) RAID levels 0, 1, 0+1, 3, 5 and JBOD - on up to 6 ATA disk drives, including automatic rebuild and hotswap, and - supports signalling disk status on LEDs on Promise Superswap disk - enclosures. The Supertrak line of controllers does not support non-disk - devices.

-
-
-

-

The pst driver supports the Promise - Supertrak SX6000 ATA hardware RAID controller.

-
-
-

-

The pst driver does not support - manipulating the RAID from the OS, RAIDs need to be set up from the onboard - BIOS. However, hot swap, hot spare, and automatic rebuilds are supported - without a reboot.

-
-
-

-

The pst driver first appeared in - FreeBSD 4.7.

-
-
-

-

The pst driver and man page was written by - Søren Schmidt - <sos@FreeBSD.org>.

-
-
- - - - - -
December 14, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/pt.4 3.html b/static/freebsd/man4/pt.4 3.html deleted file mode 100644 index a96bf14f..00000000 --- a/static/freebsd/man4/pt.4 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
PT(4)Device Drivers ManualPT(4)
-
-
-

-

pt — SCSI - processor type driver

-
-
-

-

device pt

-
-
-

-

The pt driver provides support for a SCSI - processor type device. These are usually scanners and other devices using - the SCSI link as a communication interface with device specific commands - embedded in the data stream.

-

A SCSI adapter must be separately configured into the system - before this driver can be used.

-

This device supports read(2) and - write(2), and the ioctl(2) calls - described below.

-
-
-

-

The following ioctl(2) calls are supported by - the pt driver. They are defined in the header file - <sys/ptio.h>.

-
-
PTIOCGETTIMEOUT
-
This ioctl allows userland applications to fetch the current - pt driver read and write timeout. The value - returned is in seconds.
-
PTIOCSETTIMEOUT
-
This ioctl allows userland applications to set the current - pt driver read and write timeouts. The value - should be in seconds.
-
-
-
-

-
-
/dev/ptN
-
the Nth processor device.
-
-
-
-

-

cam(4)

-
-
-

-

The pt driver appeared in - FreeBSD 2.1.

-
-
- - - - - -
March 2, 1995FreeBSD 15.0
diff --git a/static/freebsd/man4/ptnet.4 3.html b/static/freebsd/man4/ptnet.4 3.html deleted file mode 100644 index 52c179f1..00000000 --- a/static/freebsd/man4/ptnet.4 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
PTNET(4)Device Drivers ManualPTNET(4)
-
-
-

-

ptnet — Ethernet - driver for passed-through netmap ports

-
-
-

-

This network driver is included in netmap(4), - and it can be compiled into the kernel by adding the following line in your - kernel configuration file:

-
device netmap
-
-
-

-

The ptnet device driver provides direct - access to host netmap ports, from within a Virtual Machine (VM). - Applications running inside the VM can access the TX/RX rings and buffers of - a netmap port that the hypervisor has passed-through to the VM. Hypervisor - support for ptnet is currently available for - QEMU/KVM. Any netmap(4) port can be passed-through, - including physical NICs, vale(4) ports, netmap pipes, - etc.

-

The main use-case for netmap passthrough is Network Function - Virtualization (NFV), where middlebox applications running within VMs may - want to process very high packet rates (e.g., 1-10 millions packets per - second or more). Note, however, that those applications must use the device - in netmap mode in order to achieve such rates. In addition to the general - advantages of netmap, the improved performance of - ptnet when compared to hypervisor device emulation - or paravirtualization (e.g., vtnet(4), - vmx(4)) comes from the hypervisor being completely - bypassed in the data-path. For example, when using - vtnet(4) the VM has to convert each - mbuf(9) to a VirtIO-specific packet representation and - publish that to a VirtIO queue; on the hypervisor side, the packet is - extracted from the VirtIO queue and converted to a hypervisor-specific - packet representation. The overhead of format conversions (and packet - copies, in same cases) is not incured by ptnet in - netmap mode, because mbufs are not used at all, and the packet format is the - one defined by netmap (e.g., struct netmap_slot) along - the whole data-path. No format conversions or copies happen.

-

It is also possible to use a ptnet device - like a regular network interface, which interacts with the - FreeBSD network stack (i.e., not in netmap mode). - However, in that case it is necessary to pay the cost of data copies between - mbufs and netmap buffers, which generally results in lower TCP/UDP - performance than vtnet(4) or other paravirtualized network - devices. If the passed-through netmap port supports the VirtIO network - header, ptnet is able to use it, and support TCP/UDP - checksum offload (for both transmit and receive), TCP segmentation offload - (TSO) and TCP large receive offload (LRO). Currently, - vale(4) ports support the header. Note that the VirtIO - network header is generally not used in NFV use-cases, because middleboxes - are not endpoints of TCP/UDP connections.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
dev.netmap.ptnet_vnet_hdr
-
This tunable enables (1) or disables (0) the VirtIO network header. If - enabled, ptnet uses the same header used by - vtnet(4) to exchange offload metadata with the - hypervisor. If disabled, no header is prepended to transmitted and - received packets. The metadata is necessary to support TCP/UDP checksum - offloads, TSO, and LRO. The default value is 1.
-
-
-
-

-

netintro(4), netmap(4), - vale(4), virtio(4), - vmx(4), ifconfig(8)

-
-
-

-

The ptnet driver was written by - Vincenzo Maffione - <vmaffione@FreeBSD.org>. - It first appeared in FreeBSD 12.0.

-
-
- - - - - -
December 11, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/pts.4 3.html b/static/freebsd/man4/pts.4 3.html deleted file mode 100644 index 15cfbbf9..00000000 --- a/static/freebsd/man4/pts.4 3.html +++ /dev/null @@ -1,116 +0,0 @@ - - - - - - -
PTS(4)Device Drivers ManualPTS(4)
-
-
-

-

pts — - pseudo-terminal driver

-
-
-

-

The pts driver provides support for a - device-pair termed a - . - A pseudo-terminal is a pair of character devices, a - - device and a - - device. The slave device provides to a process an interface identical to - that described in tty(4). However, whereas all other - devices which provide the interface described in tty(4) - have a hardware device of some sort behind them, the slave device has, - instead, another process manipulating it through the master half of the - pseudo-terminal. That is, anything written on the master device is given to - the slave device as input and anything written on the slave device is - presented as input on the master device.

-

The following ioctl(2) calls apply only to - pseudo-terminals:

-
-
-
Enable/disable - - mode. Packet mode is enabled by specifying (by reference) a nonzero - parameter and disabled by specifying (by reference) a zero parameter. When - applied to the master side of a pseudo-terminal, each subsequent - read(2) from the terminal will return data written on - the slave part of the pseudo-terminal preceded by a zero byte - (symbolically defined as TIOCPKT_DATA), or a - single byte reflecting control status information. In the latter case, the - byte is an inclusive-or of zero or more of the bits: -
-
-
whenever the read queue for the terminal is flushed.
-
-
whenever the write queue for the terminal is flushed.
-
-
whenever output to the terminal is stopped a la - ‘^S’.
-
-
whenever output to the terminal is restarted.
-
-
whenever VSTOP is - ‘^S’ and - VSTART is - ‘^Q’.
-
-
whenever the start and stop characters are not - ‘^S/^Q’.
-
-

While this mode is in use, the presence of control status - information to be read from the master side may be detected by a - select(2) for exceptional conditions.

-

This mode is used by rlogin(1) and - rlogind(8) to implement a remote-echoed, locally - ‘^S/^Q’ flow-controlled remote - login with proper back-flushing of output; it can be used by other - similar programs.

-
-
-
Obtain device unit number, which can be used to generate the filename of - the pseudo-terminal slave device. This ioctl(2) should - not be used directly. Instead, the ptsname(3) function - should be used.
-
-
Determine whether the file descriptor is pointing to a pseudo-terminal - master device. This ioctl(2) should not be used - directly. It is used to implement routines like - grantpt(3).
-
-
-
-

-

The files used by this pseudo-terminals implementation are:

-
-
/dev/pts/[num]
-
Pseudo-terminal slave devices.
-
-
-
-

-

None.

-
-
-

-

posix_openpt(2), grantpt(3), - ptsname(3), pty(4), - tty(4)

-
-
-

-

A pseudo-terminal driver appeared in - 4.2BSD. In FreeBSD 8.0, it - was replaced with the pts driver.

-
-
- - - - - -
August 20, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/pty.4 3.html b/static/freebsd/man4/pty.4 3.html deleted file mode 100644 index d97572d6..00000000 --- a/static/freebsd/man4/pty.4 3.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
PTY(4)Device Drivers ManualPTY(4)
-
-
-

-

pty — old-style - compatibility pseudo-terminal driver

-
-
-

-

device pty

-
-
-

-

The pty driver provides support for the - traditional BSD naming scheme that was used for accessing pseudo-terminals - before it was replaced by pts(4). This traditional naming - is still used in Linux. When the device /dev/ptyXX - is being opened, a new terminal shall be created with the - pts(4) driver. A device node for this terminal shall be - created, which has the name /dev/ttyXX.

-

The pty driver also provides a cloning - System V /dev/ptmx device.

-

New code should not try to allocate pseudo-terminals using this - interface. It is only provided for compatibility with older C libraries that - tried to open such devices when posix_openpt(2) was being - called, and for running Linux binaries.

-
-
-

-

The BSD-style compatibility pseudo-terminal driver uses the - following device names:

-
-
/dev/pty[l-sL-S][0-9a-v]
-
Pseudo-terminal master devices.
-
/dev/tty[l-sL-S][0-9a-v]
-
Pseudo-terminal slave devices.
-
/dev/ptmx
-
Control device, returns a file descriptor to a new master pseudo-terminal - when opened.
-
-
-
-

-

None.

-
-
-

-

posix_openpt(2), pts(4), - tty(4)

-
-
-

-

A pseudo-terminal driver appeared in - 4.2BSD.

-
-
-

-

Unlike previous implementations, the master and slave device nodes - are destroyed when the PTY becomes unused. A call to - stat(2) on a nonexistent master device will already cause - a new master device node to be created. The master device can only be - destroyed by opening and closing it.

-

The pty driver cannot be unloaded, because - it cannot determine if it is being used.

-
-
- - - - - -
October 28, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/puc.4 4.html b/static/freebsd/man4/puc.4 4.html deleted file mode 100644 index f4e70e11..00000000 --- a/static/freebsd/man4/puc.4 4.html +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - -
PUC(4)Device Drivers ManualPUC(4)
-
-
-

-

puc — PCI - “Universal” Communications driver

-
-
-

-

device pci -
- device puc -
- device uart -
- device ppc

-
-
-

-

The puc driver acts as a shim to connect - PCI multi-port serial and parallel adapters to the uart(4) - and ppc(4) driver.

-
-
-

-

The puc driver supports the following - PCI/PCIe multi-port serial and parallel adapters:

-

-
    -
  • Advantech 2-port PCI PCI-1602/1603 Rev A/B1
    • -
  • Applied Micro Circuits PCI 8 Port UART
    • -
  • Avlab Technology PCI IO 2S
    • -
  • Avlab Low Profile PCI 4 Serial
    • -
  • Boca Research PCI Turbo Serial 658/654
    • -
  • Brainboxes: -
      -
    • Instashield PCIe IX-400, IX-200, IX-100
      • -
    • Instashield PCI IS-400, IS-200
      • -
    • PX Series PCIe RS232/RS422/RS485/LPT
      • -
    • UC Series Universal PCI RS232/RS422/RS485/LPT
      • -
    • UP Series PCI Dual RS232
      • -
    -
    • -
  • Comtrol RocketPort 550 PCI 16/8/4 port
    • -
  • Decision Computer PCCOM PCI 8/4/2 port
    • -
  • Digi Neo PCIe 4 and 8 Port (with and without RJ45)
    • -
  • Digi Neo PCI 4 and 8 Port
    • -
  • Dolphin Peripherals PCI 4035/4014
    • -
  • Exar: -
      -
    • XR17C/D152
      • -
    • XR17C154
      • -
    • XR17C158
      • -
    • XR17V258IV
      • -
    • XR17V352
      • -
    • XR17V354
      • -
    • XR17V358
      • -
    -
    • -
  • Feasso PCI FPP-02 2S1P
    • -
  • HP Diva Serial [GSP] Multiport UART: -
      -
    • Tosca Console
      • -
    • Tosca Secondary
      • -
    • Maestro SP2
      • -
    • Superdome Console
      • -
    • Keystone SP2
      • -
    • Everest SP2
      • -
    -
    • -
  • I-O DATA RSA-PCI2/R
    • -
  • IBM SurePOS 300 Series (481033H) serial ports
    • -
  • IC Book Labs: -
      -
    • Dreadnought x16 Pro/Lite
      • -
    • Ironclad x8 Pro
      • -
    • Gunboat x4 Pro/Lite/Low Profile
      • -
    • Gunboat x2 Low Profile
      • -
    -
    • -
  • Kuroutoshikou SERIAL4P-LPPCI2
    • -
  • Lava Computers: -
      -
    • Dual Serial PCI
      • -
    • Quattro-PCIe
      • -
    • Quattro-PCI
      • -
    • Octopus-550 PCI
      • -
    -
    • -
  • Moxa Technologies: -
      -
    • Smartio CP-102E/PCIe
      • -
    • Smartio CP-102EL/PCIe
      • -
    • Smartio C104H/PCI
      • -
    • Smartio CP-104UL/PCI
      • -
    • Smartio CP-104JU/PCI
      • -
    • Smartio CP-104EL/PCIe
      • -
    • Smartio CP-104EL-A/PCIe
      • -
    • CP-112UL PCI
      • -
    • Industio CP-114
      • -
    • Smartio CP-114EL/PCIe
      • -
    • Smartio CP-118EL-A/PCIe
      • -
    • C168H/PCI
      • -
    • C168U/PCI
      • -
    • CP-168EL/PCIe
      • -
    • Smartio CP-168EL-A/PCIe
      • -
    -
    • -
  • NetMos NM9815 Dual 1284 Printer port PCI
    • -
  • NetMos NM9835 2/1 port UART + 1284 Printer PCI
    • -
  • NetMos NM9845 4/6 port UART + 1284 Printer PCI
    • -
  • NetMos NM9865 4/3/2 port UART + 1/2 port 1284 Printer PCI
    • -
  • Oxford Semiconductor based boards: -
      -
    • OX16PCI952 UART (with and without Parallel port)
      • -
    • OX16PCI954 UART
      • -
    • OX9160/OX16PCI954 UARTs
      • -
    • OX16PCI958 UART
      • -
    -
    • -
  • Perle Ultraport4 Express PCIe Serial
    • -
  • Perle Speed8/Speed4/Speed2 LE PCI Serial
    • -
  • Quatech: -
      -
    • DSC-300/200/100 PCI
      • -
    • DSCLP-300/200/100 PCI
      • -
    • ESC-100/100D/100M PCI
      • -
    • QSC-300/200/100 PCI
      • -
    • QSCLP-100 PCI
      • -
    -
    • -
  • SIIG Cyber Series of UART and parallel port boards: -
      -
    • Cyber 2S and 2SP1 PCI 16550
      • -
    • Cyber 4 and 4S PCI 16C650 (10x family and 20x family)
      • -
    • Cyber I/O PCI (10x family and 20x family)
      • -
    • Cyber Parallel Dual PCI (10x family and 20x family)
      • -
    • Cyber Serial Dual PCI (10x family and 20x family)
      • -
    • Cyber 2S1P PCI (10x family and 20x family)
      • -
    • PS8000 8S PCI 16C650 (20x family)
      • -
    • Quartet Serial 850 PCI
      • -
    -
    • -
  • Sun 1040 PCI Quad Serial
    • -
  • Sunix MIO5xxxx 4/2/1 port UART and 1284 Printer
    • -
  • Sunix SUN1889/1888 PCI dual port serial
    • -
  • Sunix SER5xxxx 8/4/2 port serial
    • -
  • Syba Tech Ltd PCI-4S2P-550-ECP
    • -
  • Systembase SB16C1054/8 4/8 port serial
    • -
  • Titan PCI-800H/PCI-200H
    • -
  • VScom: -
      -
    • PCIex-800H
      • -
    • PCI-200HV2
      • -
    • 200Li uPCI
      • -
    • PCI-800L, PCI-200L, and PCI-100L
      • -
    • PCI-800, PCI-400, and PCI-200
      • -
    -
    • -
-
-
-

-
-
sys/dev/puc/pucdata.c
-
list of supported devices
-
-
-
-

-

ppc(4), uart(4)

-
-
-

-

This driver took the idea from the NetBSD - puc driver. It uses a substantial amount of the same - data.

-
-
- - - - - -
June 11, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/pvscsi.4 3.html b/static/freebsd/man4/pvscsi.4 3.html deleted file mode 100644 index f8c8baaa..00000000 --- a/static/freebsd/man4/pvscsi.4 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
PVSCSI(4)Device Drivers ManualPVSCSI(4)
-
-
-

-

pvscsi — VMware - Paravirtual SCSI Controller

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device pci -
-device scbus -
-device pvscsi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pvscsi_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hw.pvscsi.request_ring_pages
-
controls how many pages are allocated for the device request ring. A - non-positive value will cause the driver to choose the value based on - device capabilities. A non-zero value will use that many number of pages - up to a maximum of 32. The default setting is 0.
-
hw.pvscsi.max_queue_depth
-
controls the queue size for the adapter. A non-positive value will cause - the driver to choose the value based on number of request ring pages. A - non-zero value will set the queue size up to a maximum allowed by the - number of request ring pages. Default is 0.
-
hw.pvscsi.use_msg
-
setting to nonzero value enables the use of the PVSCSI message queue - allowing for disk hot-add and remove without manual rescan needed. Default - is 1.
-
hw.pvscsi.use_msi
-
setting to nonzero value enables the use of MSI interrupts. Default is - 1.
-
hw.pvscsi.use_msix
-
setting to nonzero value enables the use of MSI-X interrupts. Default is - 1.
-
hw.pvscsi.use_req_call_threshold
-
setting to nonzero value enables the request call threshold functionality. - TODO. Default is 1.
-
-
-
-

-

The pvscsi driver provides support for the - VMware Paravirtual SCSI Controller (PVSCSI) in virtual machines by - VMware.

-
-
-

-

cam(4), da(4)

-
-
-

-

The pvscsi driver first appeared in - FreeBSD 13.0.

-
-
-

-

Vishal Bhakta - <vbhakta@vmware.com>.

-
-
- - - - - -
December 5, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/pwmc.4 3.html b/static/freebsd/man4/pwmc.4 3.html deleted file mode 100644 index ab8587a2..00000000 --- a/static/freebsd/man4/pwmc.4 3.html +++ /dev/null @@ -1,176 +0,0 @@ - - - - - - -
PWMC(4)Device Drivers ManualPWMC(4)
-
-
-

-

pwmc — PWM (Pulse - Width Modulation) control device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pwmbus -
-device pwmc
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
pwmc_load="YES"
-
-
-
-

-

The pwmc driver provides device-control - access to a channel of PWM hardware. Each instance of a - pwmc device is associated with a single PWM output - channel.

-

Some PWM hardware is organized with multiple channels sharing a - common clock or other resources. In such cases, a separate - pwmc instance will exist for each channel, but - changing the period or duty cycle of any one channel may affect other - channels within the hardware which share the same resources. Consult the - documentation for the underlying PWM hardware device driver for details on - channels that share resources.

-

An instance of pwmc creates a character - device named /dev/pwm/pwmcX.Y where - X is a sequential number assigned to each PWM hardware - controller as it is discovered by the system, and Y is - the channel number within that hardware controller. The driver can be - configured to create aliases that point to the - pwmcX.Y entries, in effect creating named - channels.

-

The pwmc driver provides control of a PWM - channel with the following ioctl(2) calls and data - structures, defined in - <dev/pwm/pwmc.h>:

-
-
- (struct pwm_state)
-
Retrieve the current state of the channel.
-
- (struct pwm_state)
-
Set the current state of the channel. All parameters are updated on every - call. To change just one of the values, use - PWMGETSTATE to get the current state and then - submit the same data back with just the appropriate value changed.
-
-

The pwm_state structure is defined as - follows:

-
-
struct pwm_state {
-	u_int		period;
-	u_int		duty;
-	uint32_t	flags;
-	bool		enable;
-};
-
-
-
period
-
The duration, in nanoseconds, of one complete on-off cycle.
-
duty
-
The duration, in nanoseconds, of the on portion of one cycle.
-
flags
-
Flags that affect the output signal can be bitwise-ORed together. The - following flags are currently defined: -

-
-
-
Invert the signal polarity.
-
-
-
enable
-
False to disable the output signal or true to enable it.
-
-
-
-

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - pwmc:

-
-
hint.pwmc.%d.at
-
The pwmbus instance the pwmc instance is attached - to.
-
hint.pwmc.%d.channel
-
The hardware channel number the instance is attached to. Channel numbers - count up from zero.
-
hint.pwmc.%d.label
-
If this optional hint is set, the driver creates an alias in - /dev/pwm with the given name, which points to the - instance.
-
-
-
-

-

On an fdt(4) based system, a - pwmc device is described with a child node of the - pwm hardware controller node. When the hardware supports multiple channels - within the controller, it is not necessary to include a - pwmc child node for every channel the hardware - supports. Define only the channels you need to control.

-

The following properties are required for a - pwmc device node:

-
-
compatible
-
Must be the string "freebsd,pwmc".
-
reg
-
The hardware channel number.
-
-

The following properties are optional for the - pwmc device node:

-
-
label
-
A string containing only characters legal in a file name. The driver - creates an alias with the given name in /dev/pwm - which points to the instance's /dev/pwm/pwmcX.Y - device entry.
-
-

Example of a PWM hardware node containing one - pwmc child node:

-
-
&ehrpwm0 {
-    status = "okay";
-    pinctrl-names = "default";
-    pinctrl-0 = <&ehrpwm0_AB_pins>;
-
-    pwmcontrol@0 {
-        compatible = "freebsd,pwmc";
-        reg = <0>;
-        label = "backlight";
-    };
-};
-
-
-
-

-
-
/dev/pwm/pwmc*
-
 
-
-
-
-

-

fdt(4), device.hints(5), - pwm(8), pwm(9)

-
-
-

-

The pwmc driver appeared in - FreeBSD 13.0.

-
-
- - - - - -
June 17, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/qat.4 3.html b/static/freebsd/man4/qat.4 3.html deleted file mode 100644 index 5d4a0a9f..00000000 --- a/static/freebsd/man4/qat.4 3.html +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - -
QAT(4)Device Drivers ManualQAT(4)
-
-
-

-

qat — Intel - QuickAssist Technology driver

-
-
-

-

To load the driver call:

-

-
    -
  • kldload qat
    • -
-

In order to load the driver on boot add these lines to - loader.conf(5) selecting firmware(s) suitable for - installed device(s)

-

-
    -
  • qat_200xx_fw_load="YES"
    • -
  • qat_c3xxx_fw_load="YES"
    • -
  • qat_c4xxx_fw_load="YES"
    • -
  • qat_c62x_fw_load="YES"
    • -
  • qat_dh895xcc_fw_load="YES"
    • -
  • qat_4xxx_fw_load="YES"
    • -
  • qat_load="YES"
    • -
-
-
-

-

The qat driver supports cryptography and - compression acceleration of the Intel (R) QuickAssist Technology (QAT) - devices.

-

A complete API for offloading these operations is exposed in the - kernel and may be used by any other entity directly. In addition to exposing - a complete kernel API for offloading cryptography and compression - operations, the qat driver also integrates with - crypto(4), allowing offloading supported operations to - Intel QuickAssist Technology devices.

-
-
-

-

The qat driver supports the following - Intel QuickAssist Technology Engines:

-

-
    -
  • Intel (R) C62x Chipset
    • -
  • Intel (R) Atom C3000 processor product family
    • -
  • Intel (R) QuickAssist Adapter 8960/Intel (R) QuickAssist Adapter 8970 - (formerly known as "Lewis Hill")
    • -
  • Intel (R) Communications Chipset 8925 to 8955 Series
    • -
  • Intel (R) Atom P5300 processor product family
    • -
  • Intel (R) QAT 4xxx Series
    • -
-
-
-

-

The following sysctl(8) variables may be used to - reconfigure the qat device. For configuration - persistence those variables may be set before loading the driver, either via - kenv(1) or loader.conf(5).

-

The specific device needs to be in the "down" state - before changing the configuration.

-
-
dev.qat.X.state
-
Show or set current state of the device. Possible values: - "down", "up". -

NOTE: If the symmetric services are used for - device the - - driver needs to be disabled prior the device reconfiguration.

-
-
dev.qat_ocf.0.enable
-
Enable/disable the QAT cryptographic framework connectivity. Enabled by - default.
-
dev.qat.X.cfg_services
-
Override the device services enabled, may be one of: symmetric, - asymmetric, data compression. Possible values: "sym", - "asym", "dc", "sym;dc", "asym;dc", - "sym;asym". Default services configured are "sym;asym" - for even and "dc" for odd devices.
-
dev.qat.X.cfg_mode
-
Override the device mode configuration for kernel space and user space - instances. Possible values: "ks", "us", - "ks;us". Default value "ks;us".
-
dev.qat.X.num_user_processes
-
Override the number of uio user space processes that can connect to the - QAT device. Default: 2
-
dev.qat.X.disable_safe_dc_mode
-
Override history buffer mitigation. Disabled by default. If enabled, - decompression throughput increases but may result in a data leak if - dev.qat.X.num_user_processes is more than 1. Enable - this option only if your system is not prone to user data leaks.
-
-

The following sysctl(8) variables are - read-only:

-
-
dev.qat.X.frequency
-
QAT device frequency value.
-
dev.qat.X.mmp_version
-
QAT MMP Library revision number.
-
dev.qat.X.hw_version
-
QAT hardware revision number.
-
dev.qat.X.fw_version
-
QAT firmware revision number.
-
dev.qat.X.dev_cfg
-
Summary of device specific configuration.
-
dev.qat.X.heartbeat
-
QAT device heartbeat status. Value '1' indicates that the device is - operational. Value '0' means that the device is not responsive. Device - requires restart.
-
dev.qat.X.heartbeat_failed
-
Number of QAT heartbeat failures received.
-
dev.qat.X.heartbeat_sent
-
Number of QAT heartbeat requests sent.
-
-
-
-

-

crypto(4), ipsec(4), - pci(4), crypto(7), - crypto(9)

-

For details of usage and supported operations and algorithms refer - to the following documentation available from Intel Download Center - https://downloadcenter.intel.com:

-

-
    -
  • -

    Intel (R), - QuickAssist Technology API Programmer's - Guide.

    -
    • -
  • -

    Intel (R), - QuickAssist Technology Cryptographic API Reference - Manual.

    -
    • -
  • -

    Intel (R), - QuickAssist Technology Data Compression API Reference - Manual.

    -
    • -
  • -

    Intel (R), - QuickAssist Technology Performance Optimization - Guide.

    -
    • -
-
-
-

-

A qat driver appeared in - FreeBSD 13.0. It was superseded in - FreeBSD 14.0 by the upstream driver.

-
-
-

-

The qat driver was written by - Intel (R) Corporation.

-
-
- - - - - -
June 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/qat_c2xxx.4 3.html b/static/freebsd/man4/qat_c2xxx.4 3.html deleted file mode 100644 index 8b9d4b38..00000000 --- a/static/freebsd/man4/qat_c2xxx.4 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
QAT_C2XXX(4)Device Drivers ManualQAT_C2XXX(4)
-
-
-

-

qat_c2xxx — Intel - QuickAssist Technology (QAT) driver for Atom C2000 chipsets

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device cryptodev -
-device qat
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
qat_c2xxx_load="YES"
-qat_c2xxxfw_load="YES"
-
-
-
-

-

The qat_c2xxx driver implements - crypto(4) support for some of the cryptographic - acceleration functions of the Intel QuickAssist (QAT) device found on Atom - C2000 devices. QAT devices are enumerated through PCIe and are thus visible - in pciconf(8) output.

-

The qat_c2xxx driver can accelerate AES in - CBC, CTR, and GCM modes, and can perform authenticated encryption combining - the CBC, and CTR modes with SHA1-HMAC and SHA2-HMAC. The - qat_c2xxx driver can also compute SHA1 and SHA2 - digests. The implementation of AES-GCM has a firmware-imposed constraint - that the length of any additional authenticated data (AAD) must not exceed - 240 bytes. The driver thus rejects crypto(9) requests that - do not satisfy this constraint.

-
-
-

-

crypto(4), ipsec(4), - pci(4), qat(4), - random(4), crypto(7), - crypto(9)

-
-
-

-

The qat_c2xxx driver first appeared in - FreeBSD 13.0.

-
-
-

-

The qat_c2xxx driver was written for - NetBSD by Hikaru Abe - <hikaru@iij.ad.jp>. -
- Mark Johnston - <markj@FreeBSD.org> - ported the driver to FreeBSD.

-
-
-

-

Some Atom C2000 QAT devices have two acceleration engines instead - of one. The qat_c2xxx driver currently misbehaves - when both are enabled and thus does not enable the second acceleration - engine if one is present.

-
-
- - - - - -
July 21, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/qlnxe.4 3.html b/static/freebsd/man4/qlnxe.4 3.html deleted file mode 100644 index a2ab2658..00000000 --- a/static/freebsd/man4/qlnxe.4 3.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
QLNXE(4)Device Drivers Manual (amd64)QLNXE(4)
-
-
-

-

qlnxe — Cavium - 25/40/100 Gigabit Ethernet & CNA Adapter Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device qlnxe
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_qlnxe_load="YES"
-
-
-
-

-

The qlnxe driver supports IPv4 checksum - offload, TCP and UDP checksum offload for both IPv4 and IPv6, Large Segment - Offload for both IPv4 and IPv6, Jumbo frames, VLAN Tag, Receive Side - scaling, HW and Soft LRO. For further hardware information, see - http://www.qlogic.com/.

-
-
-

-

The qlnxe driver supports 25/40/100 - Gigabit Ethernet & CNA Adapter based on the following chipsets:

-

-
    -
  • QLogic 45000 series
    • -
  • QLogic 41000 series
    • -
-
-
-

-

For support questions please contact your Cavium approved reseller - or Cavium Technical Support at - http://support.qlogic.com, or by E-mail at - <support@qlogic.com>.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The qlnxe device driver first appeared in - FreeBSD 11.1.

-
-
-

-

The qlnxe driver was written by - David C Somayajulu at Cavium Inc.

-
-
- - - - - -
May 9, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/qlxgb.4 3.html b/static/freebsd/man4/qlxgb.4 3.html deleted file mode 100644 index c3e6876e..00000000 --- a/static/freebsd/man4/qlxgb.4 3.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
QLXGB(4)Device Drivers Manual (amd64)QLXGB(4)
-
-
-

-

qlxgb — QLogic 10 - Gigabit Ethernet & CNA Adapter Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device qlxgb
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_qlxgb_load="YES"
-
-
-
-

-

The qlxgb driver supports IPv4 checksum - offload, TCP and UDP checksum offload for both IPv4 and IPv6, Large Segment - Offload for both IPv4 and IPv6, Jumbo frames, VLAN Tag, and Receive Side - scaling. For further hardware information, see - http://www.qlogic.com/.

-
-
-

-

The qlxgb driver supports 10 Gigabit - Ethernet & CNA Adapter based on the following chipsets:

-

-
    -
  • QLogic 3200 series
    • -
  • QLogic 8200 series
    • -
-
-
-

-

For support questions please contact your QLogic approved reseller - or QLogic Technical Support at - http://support.qlogic.com, or by E-mail at - <support@qlogic.com>.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The qlxgb device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The qlxgb driver was written by - David C Somayajulu at QLogic Corporation.

-
-
- - - - - -
November 3, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/qlxgbe.4 3.html b/static/freebsd/man4/qlxgbe.4 3.html deleted file mode 100644 index 26009cc4..00000000 --- a/static/freebsd/man4/qlxgbe.4 3.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
QLXGBE(4)Device Drivers Manual (amd64)QLXGBE(4)
-
-
-

-

qlxgbe — QLogic 10 - Gigabit Ethernet & CNA Adapter Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device qlxgbe
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_qlxgbe_load="YES"
-
-
-
-

-

The qlxgbe driver supports IPv4 checksum - offload, TCP and UDP checksum offload for both IPv4 and IPv6, Large Segment - Offload for both IPv4 and IPv6, Jumbo frames, VLAN Tag, and Receive Side - scaling, ability to select either HW or Software LRO, when LRO is enabled - (default HW LRO). For further hardware information, see - http://www.qlogic.com/.

-
-
-

-

The qlxgbe driver supports 10 Gigabit - Ethernet & CNA Adapter based on the following chipsets:

-

-
    -
  • QLogic 8300 series
    • -
-
-
-

-

For support questions please contact your QLogic approved reseller - or QLogic Technical Support at - http://support.qlogic.com, or by E-mail at - <support@qlogic.com>.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The qlxgbe device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The qlxgbe driver was written by - David C Somayajulu at QLogic Corporation.

-
-
- - - - - -
April 1, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/qlxge.4 3.html b/static/freebsd/man4/qlxge.4 3.html deleted file mode 100644 index 9766da10..00000000 --- a/static/freebsd/man4/qlxge.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
QLXGE(4)Device Drivers Manual (amd64)QLXGE(4)
-
-
-

-

qlxge — QLogic - 8100 Series 10 Gigabit Ethernet Adapter Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device qlxge
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_qlxge_load="YES"
-
-
-
-

-

The qlxge driver supports IPv4 checksum - offload, TCP and UDP checksum offload for both IPv4 and IPv6, Large Segment - Offload for both IPv4 and IPv6, Jumbo frames, VLAN Tag, and Receive Side - scaling. For further hardware information, see - http://www.qlogic.com/.

-
-
-

-

The qlxge driver supports 10 Gigabit - Ethernet & CNA Adapter based on the following chipsets:

-

-
    -
  • QLogic 8100 series
    • -
-
-
-

-

For support questions please contact your QLogic approved reseller - or QLogic Technical Support at - http://support.qlogic.com, or by E-mail at - <support@qlogic.com>.

-
-
-

-

altq(4), arp(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The qlxge device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The qlxge driver was written by - David C Somayajulu at QLogic Corporation.

-
-
- - - - - -
June 21, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/ral.4 3.html b/static/freebsd/man4/ral.4 3.html deleted file mode 100644 index 3e5114dc..00000000 --- a/static/freebsd/man4/ral.4 3.html +++ /dev/null @@ -1,616 +0,0 @@ - - - - - - -
RAL(4)Device Drivers ManualRAL(4)
-
-
-

-

ral — Ralink - Technology IEEE 802.11a/g/n wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ral -
-device ralfw -
-device wlan -
-device wlan_amrr -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ral_load="YES"
-
-
-
-

-

The ral driver supports PCI/PCIe/CardBus - wireless adapters based on the Ralink RT2500, RT2501, RT2600, RT2700, - RT2800, RT3090 and RT3900E chipsets.

-

The RT2500 chipset is the first generation of 802.11b/g adapters - from Ralink. It consists of two integrated chips, an RT2560 MAC/BBP and an - RT2525 radio transceiver.

-

The RT2501 chipset is the second generation of 802.11a/b/g - adapters from Ralink. It consists of two integrated chips, an RT2561 MAC/BBP - and an RT2527 radio transceiver. This chipset provides support for the IEEE - 802.11e standard with multiple hardware transmission queues and allows - scatter/gather for efficient DMA operations.

-

The RT2600 chipset consists of two integrated chips, an RT2661 - MAC/BBP and an RT2529 radio transceiver. This chipset uses the MIMO - (multiple-input multiple-output) technology with multiple radio transceivers - to extend the operating range of the adapter and to achieve higher - throughput. However, the RT2600 chipset does not support any of the 802.11n - features.

-

The RT2700 chipset is a low-cost version of the RT2800 chipset. It - supports a single transmit path and two receiver paths (1T2R). It consists - of two integrated chips, an RT2760 or RT2790 (PCIe) MAC/BBP and an RT2720 - (2.4GHz) or RT2750 (2.4GHz/5GHz) radio transceiver.

-

The RT2800 chipset is the first generation of 802.11n adapters - from Ralink. It consists of two integrated chips, an RT2860 or RT2890 (PCIe) - MAC/BBP and an RT2820 (2.4GHz) or RT2850 (2.4GHz/5GHz) radio transceiver. - The RT2800 chipset supports two transmit paths and up to three receiver - paths (2T2R/2T3R). It can achieve speeds up to 144Mbps (20MHz bandwidth) and - 300Mbps (40MHz bandwidth.)

-

The RT3090 chipset is the first generation of single-chip 802.11n - adapters from Ralink. ral supports - station, adhoc, - hostap, mesh, - wds, and monitor mode - operation. Only one hostap or - mesh virtual interface may be configured at a time. - Any number of wds virtual interfaces may be - configured together with a hostap interface. - Multiple station interfaces may be operated together - with a hostap interface to construct a wireless - repeater device.

-

The RT3900E chipset is a single-chip 802.11n adapters from Ralink. - The MAC/Baseband Processor can be an RT5390 or RT5392. The RT5390 chip - operates in the 2GHz spectrum and supports 1 transmit path and 1 receiver - path (1T1R). The RT5392 chip operates in the 2GHz spectrum and supports up - to 2 transmit paths and 2 receiver paths (2T2R).

-

The transmit speed is user-selectable or can be adapted - automatically by the driver depending on the number of hardware transmission - retries. For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ral driver supports PCI/PCIe/CardBus - wireless adapters based on Ralink Technology chipsets, including:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A-Link WL54HRT2560PCI
A-Link WL54PCRT2560CardBus
AirLink101 AWLC5025RT2661CardBus
AirLink101 AWLH5025RT2661PCI
Amigo AWI-914WRT2560CardBus
Amigo AWI-922WRT2560mini-PCI
Amigo AWI-926WRT2560PCI
AMIT WL531CRT2560CardBus
AMIT WL531PRT2560PCI
AOpen AOI-831RT2560PCI
ASUS WL-107GRT2560CardBus
ASUS WL-130gRT2560PCI
Atlantis Land A02-PCI-W54RT2560PCI
Atlantis Land A02-PCM-W54RT2560CardBus
Belkin F5D7000 v3RT2560PCI
Belkin F5D7010 v2RT2560CardBus
Billionton MIWLGRLRT2560mini-PCI
Canyon CN-WF511RT2560PCI
Canyon CN-WF513RT2560CardBus
CC&C WL-2102RT2560CardBus
CNet CWC-854RT2560CardBus
CNet CWP-854RT2560PCI
Compex WL54GRT2560CardBus
Compex WLP54GRT2560PCI
Conceptronic C54RCRT2560CardBus
Conceptronic C54RiRT2560PCI
D-Link DWA-525 rev A2RT5392PCI
Digitus DN-7001G-RART2560CardBus
Digitus DN-7006G-RART2560PCI
E-Tech WGPC02RT2560CardBus
E-Tech WGPI02RT2560PCI
Edimax EW-7108PCgRT2560CardBus
Edimax EW-7128gRT2560PCI
Eminent EM3036RT2560CardBus
Eminent EM3037RT2560PCI
Encore ENLWI-G-RLAMRT2560PCI
Encore ENPWI-G-RLAMRT2560CardBus
Fiberline WL-400PRT2560PCI
Fibreline WL-400XRT2560CardBus
Gigabyte GN-WI01GSRT2561Smini-PCI
Gigabyte GN-WIKGRT2560mini-PCI
Gigabyte GN-WMKGRT2560CardBus
Gigabyte GN-WP01GSRT2561SPCI
Gigabyte GN-WPKGRT2560PCI
Hawking HWC54GRRT2560CardBus
Hawking HWP54GRRT2560PCI
iNexQ CR054g-009 (R03)RT2560PCI
JAHT WN-4054PRT2560CardBus
JAHT WN-4054PCIRT2560PCI
LevelOne WNC-0301 v2RT2560PCI
LevelOne WPC-0301 v2RT2560CardBus
Linksys WMP54G v4RT2560PCI
Micronet SP906GKRT2560PCI
Micronet SP908GK V3RT2560CardBus
Minitar MN54GCB-RRT2560CardBus
Minitar MN54GPC-RRT2560PCI
MSI CB54G2RT2560CardBus
MSI MP54G2RT2560mini-PCI
MSI PC54G2RT2560PCI
OvisLink EVO-W54PCIRT2560PCI
PheeNet HWL-PCIG/RART2560PCI
Planex GW-NS300NRT2860CardBus
Pro-Nets CB80211GRT2560CardBus
Pro-Nets PC80211GRT2560PCI
Repotec RP-WB7108RT2560CardBus
Repotec RP-WP0854RT2560PCI
SATech SN-54CRT2560CardBus
SATech SN-54PRT2560PCI
Sitecom WL-112RT2560CardBus
Sitecom WL-115RT2560PCI
SMC SMCWCB-GMRT2661CardBus
SMC SMCWPCI-GMRT2661PCI
SparkLAN WL-685RRT2560CardBus
Surecom EP-9321-gRT2560PCI
Surecom EP-9321-g1RT2560PCI
Surecom EP-9428-gRT2560CardBus
Sweex LC500050RT2560CardBus
Sweex LC700030RT2560PCI
TekComm NE-9321-gRT2560PCI
TekComm NE-9428-gRT2560CardBus
Unex CR054g-R02RT2560PCI
Unex MR054g-R02RT2560CardBus
Zinwell ZWX-G160RT2560CardBus
Zinwell ZWX-G360RT2560mini-PCI
Zinwell ZWX-G361RT2560PCI
Zonet ZEW1500RT2560CardBus
Zonet ZEW1600RT2560PCI
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev ral0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-
-
ifconfig wlan create wlandev ral0 inet 192.0.2.20/24 \
-    ssid my_net
-
-

Join a specific BSS network with 40-bit WEP encryption:

-
-
ifconfig wlan create wlandev ral0 inet 192.0.2.20/24 \
-    ssid my_net wepmode on wepkey 0x1234567890 weptxkey 1
-
-

Join a specific BSS network with 104-bit WEP encryption:

-
-
ifconfig wlan create wlandev ral0 inet 192.0.2.20/24 \
-    ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
ral%d: could not load 8051 microcode
-
An error occurred while attempting to upload the microcode to the onboard - 8051 microcontroller unit.
-
ral%d: timeout waiting for MCU to initialize
-
The onboard 8051 microcontroller unit failed to initialize in time.
-
ral%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
-
-
-

-

cardbus(4), intro(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - wlan_xauth(4), networking(7), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The ral driver first appeared in - OpenBSD 3.7. Support for the RT2501 and RT2600 - chipsets was added in OpenBSD 3.9. Support for the - RT2800 chipset was added in OpenBSD 4.3. Support for - the RT2700 chipset was added in OpenBSD 4.4. Support - for the RT3090 chipset was added in OpenBSD 4.9.

-
-
-

-

The original ral driver was written by - Damien Bergamini - <damien@openbsd.org>.

-
-
-

-

The ral driver does not make use of the - hardware cryptographic engine.

-

The ral driver does not support any of the - 802.11n capabilities offered by the RT2700 and RT2800 chipsets. Additional - work is required in before those features can be supported.

-

Host AP mode does not support power saving. Clients attempting to - use power saving mode may experience significant packet loss (disabling - power saving on the client will fix this).

-

Some PCI ral adapters strictly require a - system supporting PCI 2.2 or greater. Check the board's PCI version before - purchasing the card as it is likely these adapters will not work in systems - based on older revisions of the PCI specification.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/random.4 3.html b/static/freebsd/man4/random.4 3.html deleted file mode 100644 index 58dfa2bf..00000000 --- a/static/freebsd/man4/random.4 3.html +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - -
RANDOM(4)Device Drivers ManualRANDOM(4)
-
-
-

-

random — the - entropy device

-
-
-

-

options RANDOM_LOADABLE -
- options RANDOM_ENABLE_ETHER -
- options RANDOM_ENABLE_TPM -
- options RANDOM_ENABLE_UMA

-
-
-

-

The random device returns an endless - supply of random bytes when read.

-

The generator will start in an - state, - and will block reads until it is seeded for the first time.

-

To provide prompt access to the random device at boot time, - FreeBSD automatically saves some entropy data in - /boot/entropy for the loader(8) to - provide to the kernel. Additional entropy is regularly saved in - /var/db/entropy. This saved entropy is sufficient to - unblock the random device on devices with writeable media.

-

Embedded applications without writable media must determine their - own scheme for re-seeding the random device on boot, or accept that the - device will remain unseeded and block reads indefinitely. See - SECURITY CONSIDERATIONS - for more detail.

-

In addition to read(2), the direct output of the - abstract kernel entropy device can be read with - getrandom(2), getentropy(3), or the - sysctl(8) pseudo-variable - kern.arandom.

-

To see the current settings of the software - random device, use the command line:

-

-
sysctl kern.random
-

which results in something like:

-
-
kern.random.block_seeded_status: 0
-kern.random.fortuna.minpoolsize: 64
-kern.random.harvest.mask_symbolic: ENABLEDSOURCE,[DISABLEDSOURCE],...,CACHED
-kern.random.harvest.mask_bin: 00000010000000111011111
-kern.random.harvest.mask: 66015
-kern.random.use_chacha20_cipher: 0
-kern.random.random_sources: 'Intel Secure Key RNG'
-kern.random.initial_seeding.bypass_before_seeding: 1
-kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
-kern.random.initial_seeding.arc4random_bypassed_before_seeding: 0
-kern.random.initial_seeding.disable_bypass_warnings: 0
-
-

Other than kern.random.block_seeded_status, - kern.random.fortuna.minpoolsize, and - kern.random.harvest.mask, all settings are read-only - via sysctl(8).

-

The kern.random.fortuna.minpoolsize sysctl - is used to set the seed threshold. A smaller number gives a faster seed, but - a less secure one. In practice, values between 64 and 256 are - acceptable.

-

The kern.random.harvest.mask bitmask is used - to select the possible entropy sources. A 0 (zero) value means the - corresponding source is not considered as an entropy source. Set the bit to - 1 (one) if you wish to use that source. The - kern.random.harvest.mask_bin and - kern.random.harvest.mask_symbolic sysctls can be used - to confirm settings in a human readable form. Disabled items in the latter - are listed in square brackets. See random_harvest(9) for - more on the harvesting of entropy.

-

The kern.random.nist_healthtest_enabled - tunable can be used to enable the entropy source health tests outlined in - section 4 of NIST Special Publication 800-90B. When enabled, all entropy - sources will be subject to the repetition count and adaptive proportion - tests described in that document. If one of the tests fails, the source will - be disabled, i.e., all subsequent entropy samples from that source will be - discarded. The implementation performs startup testing, during which entropy - sources are discarded.

-
-
-

-
-
/dev/random
-
 
-
/dev/urandom
-
 
-
-
-
-

-

The following tunables are related to initial seeding of the - random device:

-
-
kern.random.initial_seeding.bypass_before_seeding
-
Defaults to 1 (on). When set, the system will bypass the - random device prior to initial seeding. On is - , - but provides availability on many systems that lack early sources of - entropy, or cannot load /boot/entropy sufficiently - early in boot for random consumers. When unset - (0), the system will block read_random(9) and - arc4random(9) requests if and until the - random device is initially seeded.
-
kern.random.initial_seeding.disable_bypass_warnings
-
Defaults to 0 (off). When set non-zero, disables warnings in dmesg when - the random device is bypassed.
-
-

The following read-only sysctl(8) variables - allow programmatic diagnostic of whether random - device bypass occurred during boot. If they are set (non-zero), the specific - functional unit bypassed the strong random device - output and either produced no output (read_random(9)) or - seeded itself with minimal, non-cryptographic entropy - (arc4random(9)).

-
    -
  • kern.random.initial_seeding.read_random_bypassed_before_seeding
    • -
  • kern.random.initial_seeding.arc4random_bypassed_before_seeding
    • -
-
-
-

-

getrandom(2), arc4random(3), - getentropy(3), random(3), - sysctl(8), random(9)

-

Ferguson, - Schneier, and Kohno, - Cryptography Engineering, Wiley, - ISBN 978-0-470-47424-2.

-
-
-

-

A random device appeared in - FreeBSD 2.2. The implementation was changed to the - FreeBSD 5.0. In - FreeBSD 11.0, the Fortuna algorithm was introduced - as the default. In FreeBSD 12.0, Yarrow was removed - entirely.

-
-
-

-

The current random code was authored by - Mark R V Murray, with significant contributions from - many people.

-

The Fortuna algorithm was designed by - Niels Ferguson, Bruce - Schneier, and Tadayoshi Kohno.

-
-
-

-

When options RANDOM_LOADABLE is enabled, - the /dev/random device is not created until an - "algorithm module" is loaded. The only module built by default is - . - Loadable random modules are less efficient than their compiled-in - equivalents. This is because some functions must be locked against load and - unload events, and also must be indirect calls to allow for removal.

-

When options RANDOM_ENABLE_UMA is enabled, - the /dev/random device will obtain entropy from the - zone allocator. This is a very high rate source with significant performance - impact. Therefore, it is disabled by default.

-

When options RANDOM_ENABLE_ETHER is - enabled, the random device will obtain entropy from - mbuf structures passing through the network stack. - This source is both extremely expensive and a poor source of entropy, so it - is disabled by default.

-
-
-

-

The initial seeding of random number generators is a bootstrapping - problem that needs very careful attention. When writable media is available, - the Fortuna paper describes a robust system for rapidly - reseeding the device.

-

In some embedded cases, it may be difficult to find enough - randomness to seed a random number generator until a system is fully - operational. In these cases, is the responsibility of the system architect - to ensure that blocking is acceptable, or that the random device is seeded. - (This advice does not apply to typical consumer systems.)

-

To emulate embedded systems, developers may set the - kern.random.block_seeded_status tunable to 1 to verify - boot does not require early availability of the - random device.

-
-
- - - - - -
August 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/rccgpio.4 4.html b/static/freebsd/man4/rccgpio.4 4.html deleted file mode 100644 index 705bc7ee..00000000 --- a/static/freebsd/man4/rccgpio.4 4.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
RCCGPIO(4)Device Drivers ManualRCCGPIO(4)
-
-
-

-

rccgpio — ADI - Engineering RCC-VE and RCC-DFF/DFFv2 GPIO controller

-
-
-

-

device rccgpio -
- device gpio -
- device gpioled

-
-
-

-

The rccgpio provides a simple interface to - read the reset switch state and control the status LEDs.

-

The software controlled reset switch is known to be available on - boards from Netgate. Most people get a button that is a hardware reset.

-

All the GPIO pins are locked in their intended setup to disallow - any harmful settings (the ones that can cause short circuits).

-
-
-

-

gpio(3), gpio(4), - gpioled(4), gpioctl(8)

-
-
-

-

The rccgpio manual page first appeared in - FreeBSD 11.0.

-
-
-

-

The rccgpio driver was written by - Luiz Otavio O Souza - <loos@FreeBSD.org>.

-
-
- - - - - -
August 18, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/rctl.4 3.html b/static/freebsd/man4/rctl.4 3.html deleted file mode 100644 index 08fb4eb9..00000000 --- a/static/freebsd/man4/rctl.4 3.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
RCTL(4)Device Drivers ManualRCTL(4)
-
-
-

-

rctl — resource - limits

-
-
-

-

To compile this driver into the kernel, place the following line - in the kernel configuration file:

-
options RACCT -
-options RCTL
-
-
-

-

The rctl subsystem provides a flexible - resource limits mechanism, controlled by a set of rules that can be added or - removed at runtime using the rctl(8) management - utility.

-
-
-

-

Tunables can be set at the loader(8) prompt, or - loader.conf(5).

-
-
kern.racct.enable: - 1
-
Enable rctl. This defaults to 1, unless - options RACCT_DEFAULT_TO_DISABLED is set in the - kernel configuration file.
-
-
-
-

-

rctl.conf(5), rctl(8)

-
-
-

-

The rctl subsystem first appeared in - FreeBSD 9.0.

-
-
-

-

The rctl subsystem was developed by - Edward Tomasz Napierala - <trasz@FreeBSD.org> - under sponsorship from the FreeBSD Foundation.

-
-
- - - - - -
May 28, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/re.4 3.html b/static/freebsd/man4/re.4 3.html deleted file mode 100644 index 0fabc88d..00000000 --- a/static/freebsd/man4/re.4 3.html +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - -
RE(4)Device Drivers ManualRE(4)
-
-
-

-

re — Realtek - 8139C+/8169/816xS/811xS/8168/810xE/8111 PCI/PCIe Ethernet adapter - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device re
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_re_load="YES"
-
-
-
-

-

The re driver provides support for various - NICs based on the Realtek RTL8139C+, RTL8169, RTL816xS, RTL811xS, RTL8168, - RTL810xE and RTL8111 PCI and PCIe Ethernet controllers.

-

NICs based on the 8139C+ and 810xE are capable of 10 and 100Mbps - speeds over CAT5 cable. NICs based on the 8169, 816xS, 811xS, 8168 and 8111 - are capable of 10, 100 and 1000Mbps operation.

-

All NICs supported by the re driver have - TCP/IP checksum offload and hardware VLAN tagging/insertion features, and - use a descriptor-based DMA mechanism. They are also capable of TCP large - send (TCP segmentation offload).

-

The 8139C+ is a single-chip solution combining both a 10/100 MAC - and PHY. The 8169 is a 10/100/1000 MAC only, requiring a GMII or TBI - external PHY. The 816xS, 811xS, 8168 and 8111 are single-chip devices - containing both a 10/100/1000 MAC and 10/100/1000 copper PHY. Standalone - 10/100/1000 cards are available in both 32-bit PCI and 64-bit PCI models. - The 8110S is designed for embedded LAN-on-motherboard applications.

-

The 8169, 8169S and 8110S also support jumbo frames, which can be - configured via the interface MTU setting. The MTU is limited to 7422, since - the chip cannot transmit larger frames. Selecting an MTU larger than 1500 - bytes with the ifconfig(8) utility configures the adapter - to receive and transmit jumbo frames.

-

The re driver supports the following media - types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX operation over twisted pair. The Realtek gigE chips support - 1000Mbps in full-duplex mode only.
-
-

The re driver supports the following media - options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The re driver supports Realtek RTL8139C+, - RTL8169, RTL816xS, RTL811xS, RTL8168, RTL810xE and RTL8111 based Fast - Ethernet and Gigabit Ethernet adapters including:

-

-
    -
  • Alloy Computer Products EtherGOLD 1439E 10/100 (8139C+)
    • -
  • Compaq Evo N1015v Integrated Ethernet (8139C+)
    • -
  • Corega CG-LAPCIGT Gigabit Ethernet (8169S)
    • -
  • D-Link DGE-528(T) Gigabit Ethernet (8169S)
    • -
  • D-Link DGE-530(T) Gigabit Ethernet (8169S)
    • -
  • Killer E2600 Gigabit Ethernet (8168)
    • -
  • Gigabyte 7N400 Pro2 Integrated Gigabit Ethernet (8110S)
    • -
  • LevelOne GNC-0105T (8169S)
    • -
  • LinkSys EG1032 (32-bit PCI)
    • -
  • PLANEX COMMUNICATIONS Inc. GN-1200TC (8169S)
    • -
  • TP-Link TG-3468 v2 Gigabit Ethernet (8168)
    • -
  • USRobotics USR997902 Gigabit Ethernet (8169S)
    • -
  • Xterasys XN-152 10/100/1000 NIC (8169)
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.re.intr_filter
-
This tunable makes driver use interrupt filter handler on controllers that - support MSI/MSI-X capability. If MSI/MSI-X is disabled by administrator - this tunable has no effect and driver will use interrupt filter handler. - The default value is 0 to use interrupt thread handler.
-
hw.re.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
hw.re.msix_disable
-
This tunable disables MSI-X support on the Ethernet hardware. The default - value is 0.
-
hw.re.prefer_iomap
-
This tunable controls which register mapping should be used on the - specified device. A non-zero value enables I/O space register mapping. The - default value is 0 to use memory space register mapping.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.re.%d.int_rx_mod
-
Maximum amount of time to delay receive interrupt processing in units of - 1us. The accepted range is 0 to 65, the default is 65(65us). Value 0 - completely disables the interrupt moderation. The interface need to be - brought down and up again before a change takes effect.
-
-
-
-

-
-
re%d: couldn't map memory
-
A fatal initialization error has occurred.
-
re%d: couldn't map ports
-
A fatal initialization error has occurred.
-
re%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
re%d: no memory for softc struct!
-
The driver failed to allocate memory for per-device instance information - during initialization.
-
re%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
re%d: no memory for jumbo buffers!
-
The driver failed to allocate memory for jumbo frames during - initialization.
-
re%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - rge(4), rgephy(4), - vlan(4), ifconfig(8)

-

Realtek Semiconductor - RTL8139C+, RTL8169, RTL8169S and RTL8110S datasheets, - https://www.realtek.com.

-
-
-

-

The re device driver first appeared in - FreeBSD 5.2.

-
-
-

-

The re driver was written by - Bill Paul - <wpaul@windriver.com>.

-
-
-

-

The Xterasys XN-152 32-bit PCI NIC, which uses the RTL8169 MAC and - Marvell 88E1000 PHY, has a defect that causes DMA corruption if the board is - plugged into a 64-bit PCI slot. The defect lies in the board design, not the - chip itself: the PCI REQ64# and ACK64# lines should be pulled high, but they - are not. The result is that the 8169 chip is tricked into performing 64-bit - DMA transfers even though a 64-bit data path between the NIC and the bus - does not actually exist.

-

Unfortunately, it is not possible to correct this problem in - software, however it is possible to detect it. When the - re driver is loaded, it will run a diagnostic - routine designed to validate DMA operation by placing the chip in digital - loopback mode and initiating a packet transmission. If the card functions - properly, the transmitted data will be echoed back unmodified. If the echoed - data is corrupt, the driver will print an error message on the console and - abort the device attach. The user should ensure the NIC is installed in a - 32-bit PCI slot to avoid this problem.

-

The Realtek 8169, 8169S and 8110S chips appear to only be capable - of transmitting jumbo frames up to 7.5K in size.

-

If this driver is causing problems then an updated driver from the - vendor can be found in ports under net/realtek-re-kmod.

-
-
- - - - - -
November 7, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/rge.4 3.html b/static/freebsd/man4/rge.4 3.html deleted file mode 100644 index 90b19039..00000000 --- a/static/freebsd/man4/rge.4 3.html +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - -
RGE(4)Device Drivers ManualRGE(4)
-
-
-

-

rge — RealTek - RTL8125/RTL8126/RTL8127/Killer E3000 PCIe Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device rge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_rge_load="YES"
-
-
-
-

-

The rge driver provides support for - various NICs based on the RealTek RTL8125, RTL8126 and RTL8127 PCIe Ethernet - controllers.

-

All of the NICs supported by this driver support 10, 100 and - 1000Mbit over CAT5 cable. NICs based on the RTL8125 additionally support - 2.5Gbit over CAT6 cable. NICs based on the RTL8126 additionally support - 2.5Gbit and 5Gbit over CAT6 cable. NICs based on the RTL8127 additionally - support 2.5Gbit, 5Gbit and 10Gbit over CAT6 cable.

-

All NICs supported by the rge driver have - TCP/IP checksum offload, hardware VLAN tagging/insertion features, Wake On - Lan (WOL), and use a descriptor-based DMA mechanism. They are also capable - of TCP large send (TCP segmentation offload).

-

The RTL8125, RTL8126 and RTL8127 devices are single-chip solutions - combining both a MAC and PHY. The rge driver manages - the PHY directly rather than using the miibus(4) - interface. Standalone cards are available in 1x PCIe models.

-

The RTL8125, RTL8126 and RTL8127 also support jumbo frames, which - can be configured via the interface MTU setting. The MTU is limited to 9126. - Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit jumbo frames.

-

The rge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseT operation over twisted pair. The RealTek gigE chips support - 1000Mbps in full-duplex mode only.
-
-
Set 2500Base-T operation over twisted pair. The RealTek devices support - 2.5Gbit in full-duplex mode only.
-
-
Set 5000Base-T operation over twisted pair. The RealTek devices support - 5Gbit in full-duplex mode only.
-
-
Set 10Gbase-T operation over twisted pair. The RealTek devices support - 10Gbit in full-duplex mode only.
-
-

The rge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The rge driver supports the following PCIe - Ethernet adapters:

-

-
    -
  • RealTek RTL8125 (up to 2.5 Gbps)
    • -
  • RealTek RTL8126 (up to 5 Gbps)
    • -
  • RealTek RTL8127 (up to 10 Gbps)
    • -
  • Killer E3000 (up to 2.5 Gbps)
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.rge.%d.debug
-
Configure runtime debug output. This is a 32 bit bitmask.
-
dev.rge.%d.rx_process_limit
-
Maximum number of RX packets to process per interrupt. The default value - is 16. Increasing this value may improve throughput on high-speed links at - the cost of increased interrupt latency.
-
dev.rge.%d.disable_aspm
-
Disable PCIe Active State Power Management (ASPM) and Extended - Configuration Power Management (ECPM). The default value is 0 (leave ASPM - enabled). Setting this to 1 reduces latency at the cost of increased power - consumption. This tunable can only be set in - loader.conf(5) and requires a reboot to take - effect.
-
-
-
-

-
-
rge%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - re(4), vlan(4), - ifconfig(8)

-

https://www.realtek.com/.

-
-
-

-

The rge device driver first appeared in - FreeBSD 16.0.

-
-
-

-

The rge driver was written by - Kevin Lo - <kevlo@openbsd.org> - and ported to FreeBSD by -
- Adrian Chadd - <adrian@freebsd.org>.

-
-
- - - - - -
April 5, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/rgephy.4 3.html b/static/freebsd/man4/rgephy.4 3.html deleted file mode 100644 index fe08af8d..00000000 --- a/static/freebsd/man4/rgephy.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
RGEPHY(4)Device Drivers ManualRGEPHY(4)
-
-
-

-

rgephy — Realtek - RTL8168/8169/8110/8211 series 10/100/1000 Gigabit Ethernet PHY - driver

-
-
-

-

To compile all available PHY drivers into the kernel, place the - following line in your kernel configuration file:

-
device miibus
-

Alternatively, to selectively compile this driver into the kernel, - place the following lines in your kernel configuration file instead:

-
device mii -
-device rgephy
-
-
-

-

The rgephy driver supports the Realtek - RTL8168, RTL8169, RTL8110 and RTL8211 series integrated 10/100/1000 Gigabit - Ethernet PHYs.

-

In order to get a list of media types and options supported by a - specific instance of the rgephy driver, run - ifconfig -m on the instance of its parent MAC - driver.

-

Additionally, the rgephy driver supports - the following special media option:

-
-
-
When manually setting media type and options via - ifconfig(8), the rgephy driver - by default also triggers an autonegotiation advertising the selected - media. This is done in order to work around hardware issues in certain - scenarios. It is believed that this behavior does not cause harm in - general but in fact can have an adverse effect in edge cases. In order to - manually set the media type and options without also triggering an - autonegotiation, the rgephy driver allows to turn - this behavior off via the flag0 media option.
-
-

Note that this special media option will not show up in the output - of ifconfig(8), even when set.

-
-
-

-

Manually set 100BASE-TX full-duplex without also triggering an - autonegotiation:

-

-
ifconfig re0 media 100baseTX mediaopt - full-duplex,flag0
-
-
-

-

intro(4), miibus(4), - ifconfig(8)

-
-
- - - - - -
January 16, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/rights.4 3.html b/static/freebsd/man4/rights.4 3.html deleted file mode 100644 index f422f1b6..00000000 --- a/static/freebsd/man4/rights.4 3.html +++ /dev/null @@ -1,411 +0,0 @@ - - - - - - -
RIGHTS(4)Device Drivers ManualRIGHTS(4)
-
-
-

-

Capability rights — - Capsicum capability rights for file descriptors

-
-
-

-

When a file descriptor is created by a function such as - fhopen(2), kqueue(2), - mq_open(2), open(2), - pdfork(2), pipe(2), - shm_open(2), socket(2) or - socketpair(2), it is assigned all capability rights; for - accept(2), accept4(2) or - openat(2), it inherits capability rights from the - "parent" file descriptor. Those rights can be reduced (but never - expanded) by using the cap_rights_limit(2), - cap_fcntls_limit(2) and - cap_ioctls_limit(2) system calls. Once capability rights - are reduced, operations on the file descriptor will be limited to those - permitted by rights.

-

The complete list of capability rights is provided below. The - cap_rights_t type is used to store list of capability - rights. The cap_rights_init(3) family of functions should - be used to manage the structure.

-
-
-

-

Note that rights are not simple bitmasks (and cannot be - bitwise-ORed together). See cap_rights_init(3) for - details.

-

The following rights are available:

-
-
-
Permit accept(2) and accept4(2).
-
-
Permit acl_valid_fd_np(3).
-
-
Permit acl_delete_fd_np(3).
-
-
Permit acl_get_fd(3) and - acl_get_fd_np(3).
-
-
Permit acl_set_fd(3) and - acl_set_fd_np(3).
-
-
When not in capabilities mode, permit bind(2) and - bindat(2) with special value - AT_FDCWD in the fd - parameter. Note that sockets can also become bound implicitly as a result - of connect(2) or send(2), and that - socket options set with setsockopt(2) may also affect - binding behavior.
-
-
Permit bindat(2). This right has to be present on the - directory descriptor. This right includes the - CAP_LOOKUP right.
-
-
An alias to CAP_FCHFLAGS and - CAP_LOOKUP.
-
-
When not in capabilities mode, permit connect(2) and - connectat(2) with special value - AT_FDCWD in the fd - parameter. This right is also required for sendto(2) - with a non-NULL destination address.
-
-
Permit connectat(2). This right has to be present on the - directory descriptor. This right includes the - CAP_LOOKUP right.
-
-
Permit openat(2) with the - O_CREAT flag.
-
-
Permit select(2), poll(2), and - kevent(2) to be used in monitoring the file descriptor - for events.
-
-
Permit extattr_delete_fd(2).
-
-
Permit extattr_get_fd(2).
-
-
Permit extattr_list_fd(2).
-
-
Permit extattr_set_fd(2).
-
-
Permit fchdir(2).
-
-
Permit fchflags(2) and chflagsat(2) if - the CAP_LOOKUP right is also present.
-
-
Permit fchmod(2) and fchmodat(2) if - the CAP_LOOKUP right is also present.
-
-
An alias to CAP_FCHMOD and - CAP_LOOKUP.
-
-
Permit fchown(2) and fchownat(2) if - the CAP_LOOKUP right is also present.
-
-
An alias to CAP_FCHOWN and - CAP_LOOKUP.
-
-
Permit fchroot(2).
-
-
Permit fcntl(2). Note that only the - F_GETFL, F_SETFL, - F_GETOWN and F_SETOWN - commands require this capability right. Also note that the list of - permitted commands can be further limited with the - cap_fcntls_limit(2) system call.
-
-
Permit fexecve(2) and openat(2) with - the O_EXEC flag; CAP_READ - is also required.
-
-
Permit flock(2), fcntl(2) (with - F_GETLK, F_SETLK, - F_SETLKW or F_SETLK_REMOTE - flag) and openat(2) (with - O_EXLOCK or O_SHLOCK - flag).
-
-
Permit fpathconf(2).
-
-
Permit UFS background-fsck operations on the descriptor.
-
-
Permit fstat(2) and fstatat(2) if the - CAP_LOOKUP right is also present.
-
-
An alias to CAP_FSTAT and - CAP_LOOKUP.
-
-
Permit fstatfs(2).
-
-
Permit aio_fsync(2), fdatasync(2), - fsync(2) and openat(2) with - O_DSYNC, O_FSYNC, or - O_SYNC flag.
-
-
Permit ftruncate(2) and openat(2) with - the O_TRUNC flag.
-
-
Permit futimens(2) and futimes(2), and - permit futimesat(2) and utimensat(2) - if the CAP_LOOKUP right is also present.
-
-
An alias to CAP_FUTIMES and - CAP_LOOKUP.
-
-
Permit getpeername(2).
-
-
Permit getsockname(2).
-
-
Permit getsockopt(2).
-
-
Permit inotify_add_watch(2) and - inotify_add_watch_at(2).
-
-
Permit inotify_rm_watch(2).
-
-
Permit ioctl(2). Be aware that this system call has - enormous scope, including potentially global scope for some objects. The - list of permitted ioctl commands can be further limited with the - cap_ioctls_limit(2) system call.
-
-
An alias to CAP_KQUEUE_CHANGE and - CAP_KQUEUE_EVENT.
-
-
Permit kevent(2) on a kqueue(2) - descriptor that modifies list of monitored events (the - changelist argument is non-NULL).
-
-
Permit kevent(2) on a kqueue(2) - descriptor that monitors events (the eventlist - argument is non-NULL). CAP_EVENT is also required - on file descriptors that will be monitored using - kevent(2).
-
-
Permit linkat(2) on the source directory descriptor. - This right includes the CAP_LOOKUP right. -

Warning: CAP_LINKAT_SOURCE makes it - possible to link files in a directory for which file descriptors exist - that have additional rights. For example, a file stored in a directory - that does not allow CAP_READ may be linked in - another directory that does allow CAP_READ, - thereby granting read access to a file that is otherwise unreadable.

-
-
-
Permit linkat(2) on the target directory descriptor. - This right includes the CAP_LOOKUP right.
-
-
Permit listen(2); not much use (generally) without - CAP_BIND.
-
-
Permit the file descriptor to be used as a starting directory for calls - such as linkat(2), openat(2), and - unlinkat(2).
-
-
Permit mac_get_fd(3).
-
-
Permit mac_set_fd(3).
-
-
Permit mkdirat(2). This right includes the - CAP_LOOKUP right.
-
-
Permit mkfifoat(2). This right includes the - CAP_LOOKUP right.
-
-
Permit mknodat(2). This right includes the - CAP_LOOKUP right.
-
-
Permit mmap(2) with the - PROT_NONE protection.
-
-
Permit mmap(2) with the - PROT_READ protection. This right includes the - CAP_READ and CAP_SEEK - rights.
-
-
An alias to CAP_MMAP_R and - CAP_MMAP_W.
-
-
An alias to CAP_MMAP_R, - CAP_MMAP_W and - CAP_MMAP_X.
-
-
An alias to CAP_MMAP_R and - CAP_MMAP_X.
-
-
Permit mmap(2) with the - PROT_WRITE protection. This right includes the - CAP_WRITE and CAP_SEEK - rights.
-
-
An alias to CAP_MMAP_W and - CAP_MMAP_X.
-
-
Permit mmap(2) with the - PROT_EXEC protection. This right includes the - CAP_SEEK right.
-
-
Permit pdgetpid(2).
-
-
Permit pdkill(2).
-
-
Permit pdwait(2).
-
-
Permit sctp_peeloff(2).
-
-
An alias to CAP_READ and - CAP_SEEK.
-
-
An alias to CAP_SEEK and - CAP_WRITE.
-
-
Permit aio_read(2) (CAP_SEEK is - also required), openat(2) with the - O_RDONLY flag, read(2), - readv(2), recv(2), - recvfrom(2), recvmsg(2), - pread(2) (CAP_SEEK is also - required), preadv(2) (CAP_SEEK - is also required), getdents(2), - getdirentries(2), and related system calls.
-
-
An alias to CAP_READ.
-
-
Permit renameat(2) on the source directory descriptor. - This right includes the CAP_LOOKUP right. -

Warning: CAP_RENAMEAT_SOURCE makes it - possible to move files to a directory for which file descriptors exist - that have additional rights. For example, a file stored in a directory - that does not allow CAP_READ may be moved to - another directory that does allow CAP_READ, - thereby granting read access to a file that is otherwise unreadable.

-
-
-
Permit renameat(2) on the target directory descriptor. - This right includes the CAP_LOOKUP right.
-
-
Permit operations that seek on the file descriptor, such as - lseek(2), but also required for I/O system calls that - can read or write at any position in the file, such as - pread(2) and pwrite(2).
-
-
Permit sem_getvalue(3).
-
-
Permit sem_post(3).
-
-
Permit sem_wait(3) and - sem_trywait(3).
-
-
An alias to CAP_WRITE.
-
-
Permit setsockopt(2); this controls various aspects of - socket behavior and may affect binding, connecting, and other behaviors - with global scope.
-
-
Permit explicit shutdown(2); closing the socket will - also generally shut down any connections on it.
-
-
Permit symlinkat(2). This right includes the - CAP_LOOKUP right.
-
-
Allow configuration of TTY hooks, such as snp(4), on the - file descriptor.
-
-
Permit unlinkat(2) and renameat(2). - This right is only required for renameat(2) on the - destination directory descriptor if the destination object already exists - and will be removed by the rename. This right includes the - CAP_LOOKUP right.
-
-
Allow aio_write(2), openat(2) with - O_WRONLY and O_APPEND - flags set, send(2), sendmsg(2), - sendto(2), write(2), - writev(2), pwrite(2), - pwritev(2) and related system calls. For - sendto(2) with a non-NULL connection address, - CAP_CONNECT is also required. For - openat(2) with the O_WRONLY - flag, but without the O_APPEND or - O_TRUNC flag, CAP_SEEK is - also required. For aio_write(2), - pwrite(2) and pwritev(2) - CAP_SEEK is also required.
-
-
-
-

-

accept(2), accept4(2), - aio_fsync(2), aio_read(2), - aio_write(2), bind(2), - bindat(2), cap_enter(2), - cap_fcntls_limit(2), - cap_ioctls_limit(2), - cap_rights_limit(2), chflagsat(2), - connect(2), connectat(2), - extattr_delete_fd(2), extattr_get_fd(2), - extattr_list_fd(2), extattr_set_fd(2), - fchflags(2), fchmod(2), - fchmodat(2), fchown(2), - fchownat(2), fcntl(2), - fexecve(2), fhopen(2), - flock(2), fpathconf(2), - fstat(2), fstatat(2), - fstatfs(2), fsync(2), - ftruncate(2), futimes(2), - getdents(2), getdirentries(2), - getpeername(2), getsockname(2), - getsockopt(2), ioctl(2), - kevent(2), kqueue(2), - linkat(2), listen(2), - mmap(2), mq_open(2), - open(2), openat(2), - pdfork(2), pdgetpid(2), - pdkill(2), pdwait4(2), - pipe(2), poll(2), - pread(2), preadv(2), - pwrite(2), pwritev(2), - read(2), readv(2), - recv(2), recvfrom(2), - recvmsg(2), renameat(2), - sctp_peeloff(2), select(2), - send(2), sendmsg(2), - sendto(2), setsockopt(2), - shm_open(2), shutdown(2), - socket(2), socketpair(2), - symlinkat(2), unlinkat(2), - write(2), writev(2), - acl_delete_fd_np(3), acl_get_fd(3), - acl_get_fd_np(3), acl_set_fd(3), - acl_set_fd_np(3), acl_valid_fd_np(3), - mac_get_fd(3), mac_set_fd(3), - sem_getvalue(3), sem_post(3), - sem_trywait(3), sem_wait(3), - capsicum(4), snp(4)

-
-
-

-

Support for capabilities and capabilities mode was developed as - part of the TrustedBSD Project.

-
-
-

-

This manual page was created by Pawel Jakub - Dawidek - <pawel@dawidek.net> - under sponsorship from the FreeBSD Foundation based on the - cap_new(2) manual page by Robert - Watson - <rwatson@FreeBSD.org>.

-
-
- - - - - -
May 22, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/rl.4 3.html b/static/freebsd/man4/rl.4 3.html deleted file mode 100644 index 96a9ccb6..00000000 --- a/static/freebsd/man4/rl.4 3.html +++ /dev/null @@ -1,221 +0,0 @@ - - - - - - -
RL(4)Device Drivers ManualRL(4)
-
-
-

-

rl — Realtek - 8129/8139 Fast Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device rl
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_rl_load="YES"
-
-
-
-

-

The rl driver provides support for PCI - Ethernet adapters and embedded controllers based on the Realtek 8129 and - 8139 Fast Ethernet controller chips.

-

The Realtek 8129/8139 series controllers use bus master DMA but do - not use a descriptor-based data transfer mechanism. The receiver uses a - single fixed size ring buffer from which packets must be copied into mbufs. - For transmission, there are only four outbound packet address registers - which require all outgoing packets to be stored as contiguous buffers. - Furthermore, outbound packet buffers must be longword aligned or else - transmission will fail.

-

The 8129 differs from the 8139 in that the 8139 has an internal - PHY which is controlled through special direct access registers whereas the - 8129 uses an external PHY via an MII bus. The 8139 supports both 10 and - 100Mbps speeds in either full or half duplex. The 8129 can support the same - speeds and modes given an appropriate PHY chip.

-

Note: support for the 8139C+ chip is provided by the - re(4) driver.

-

The rl driver supports the following media - types:

-
-
autoselect
-
Enable autoselection of the media type and options. This is only supported - if the PHY chip attached to the Realtek controller supports NWAY - autonegotiation. The user can manually override the autoselected mode by - adding media options to the /etc/rc.conf - file.
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to select either full-duplex - or half-duplex modes.
-
-

The rl driver supports the following media - options:

-
-
full-duplex
-
Force full duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

Note that the 100baseTX media type is only available if supported - by the adapter. For more information on configuring this device, see - ifconfig(8).

-
-
-

-

Adapters supported by the rl driver - include:

-

-
    -
  • Accton “Cheetah” EN1207D (MPX 5030/5038; Realtek 8139 - clone)
    • -
  • Allied Telesyn AT2550
    • -
  • Allied Telesyn AT2500TX
    • -
  • Belkin F5D5000
    • -
  • BUFFALO (Melco INC.) LPC-CB-CLX (CardBus)
    • -
  • Compaq HNE-300
    • -
  • CompUSA no-name 10/100 PCI Ethernet NIC
    • -
  • Corega FEther CB-TXD
    • -
  • Corega FEtherII CB-TXD
    • -
  • D-Link DFE-520TX (rev. C1)
    • -
  • D-Link DFE-528TX
    • -
  • D-Link DFE-530TX+
    • -
  • D-Link DFE-538TX
    • -
  • D-Link DFE-690TXD
    • -
  • Edimax EP-4103DL CardBus
    • -
  • Encore ENL832-TX 10/100 M PCI
    • -
  • Farallon NetLINE 10/100 PCI
    • -
  • Genius GF100TXR
    • -
  • GigaFast Ethernet EE100-AXP
    • -
  • KTX-9130TX 10/100 Fast Ethernet
    • -
  • LevelOne FPC-0106TX
    • -
  • Longshine LCS-8038TX-R
    • -
  • NDC Communications NE100TX-E
    • -
  • Netronix Inc. EA-1210 NetEther 10/100
    • -
  • Nortel Networks 10/100BaseTX
    • -
  • OvisLink LEF-8129TX
    • -
  • OvisLink LEF-8139TX
    • -
  • Peppercon AG ROL-F
    • -
  • Planex FNW-3603-TX
    • -
  • Planex FNW-3800-TX
    • -
  • SMC EZ Card 10/100 PCI 1211-TX
    • -
  • SOHO (PRAGMATIC) UE-1211C
    • -
-
-
-

-
-
dev.rl.%unit.prefer_iomap
-
This tunable controls which register mapping should be used on the - specified device. A non-zero value enables I/O space register mapping. For - controllers that have no I/O space register mapping this tunable should be - set to 0 to use memory space register mapping. The default value is 1 to - use I/O space register mapping.
-
dev.rl.%unit.twister_enable
-
Non-zero value enables the long cable tuning on the specified device. - Disabled by default.
-
-
-
-

-
-
rl%d: couldn't map memory
-
A fatal initialization error has occurred.
-
rl%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
rl%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
rl%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
rl%d: no memory for tx list
-
The driver failed to allocate an mbuf for the transmitter ring when - allocating a pad buffer or collapsing an mbuf chain into a cluster.
-
rl%d: chip is in D3 power state -- setting to D0
-
This message applies only to adapters which support power management. Some - operating systems place the controller in low power mode when shutting - down, and some PCI BIOSes fail to bring the chip out of this state before - configuring it. The controller loses all of its PCI configuration in the - D3 state, so if the BIOS does not set it back to full power mode in time, - it will not be able to configure it correctly. The driver tries to detect - this condition and bring the adapter back to the D0 (full power) state, - but this may not be enough to return the driver to a fully operational - condition. If you see this message at boot time and the driver fails to - attach the device as a network interface, you will have to perform second - warm boot to have the device properly configured. -

Note that this condition only occurs when warm booting from - another operating system. If you power down your system prior to booting - FreeBSD, the card should be configured - correctly.

-
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - ifconfig(8)

-

The Realtek 8129, 8139 and 8139C+ - datasheets, - https://www.realtek.com.

-
-
-

-

The rl device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The rl driver was written by - Bill Paul - <wpaul@ctr.columbia.edu>.

-
-
-

-

Since outbound packets must be longword aligned, the transmit - routine has to copy an unaligned packet into an mbuf cluster buffer before - transmission. The driver abuses the fact that the cluster buffer pool is - allocated at system startup time in a contiguous region starting at a page - boundary. Since cluster buffers are 2048 bytes, they are longword aligned by - definition. The driver probably should not be depending on this - characteristic.

-

The Realtek data sheets are of especially poor quality, and there - is a lot of information missing particularly concerning the receiver - operation. One particularly important fact that the data sheets fail to - mention relates to the way in which the chip fills in the receive buffer. - When an interrupt is posted to signal that a frame has been received, it is - possible that another frame might be in the process of being copied into the - receive buffer while the driver is busy handling the first one. If the - driver manages to finish processing the first frame before the chip is done - DMAing the rest of the next frame, the driver may attempt to process the - next frame in the buffer before the chip has had a chance to finish DMAing - all of it.

-

The driver can check for an incomplete frame by inspecting the - frame length in the header preceding the actual packet data: an incomplete - frame will have the magic length of 0xFFF0. When the driver encounters this - value, it knows that it has finished processing all currently available - packets. Neither this magic value nor its significance are documented - anywhere in the Realtek data sheets.

-
-
- - - - - -
January 16, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/rndtest.4 4.html b/static/freebsd/man4/rndtest.4 4.html deleted file mode 100644 index 4ee2c10c..00000000 --- a/static/freebsd/man4/rndtest.4 4.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -
RNDTEST(4)Device Drivers ManualRNDTEST(4)
-
-
-

-

rndtest — FIPS - 140-2 random number generator test monitor

-
-
-

-

device rndtest

-
-
-

-

The rndtest driver “hooks - up” to hardware crypto devices to monitor the entropy data passed to - the random(4) subsystem. This data is periodically tested - for FIPS 140-2 compliance and statistics are collected. If the harvested - entropy fails any of the FIPS test suite, then it is discarded and testing - is continuously applied until “good data” is received from the - device. Failures are optionally reported on the console.

-
-
-

-

crypto(4), random(4), - safe(4), crypto(9)

-
-
-

-

The idea for this and the original code came from - Jason L. Wright. The rndtest - device driver first appeared in FreeBSD 5.0.

-
-
-

-

Crypto device drivers must be compiled specially to make use of - this driver; this should not be necessary. This feature might better be - integrated into the random(4) subsystem where it can be - applied to devices that claim to supply “pure entropy”.

-
-
- - - - - -
May 11, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/route.4 3.html b/static/freebsd/man4/route.4 3.html deleted file mode 100644 index 656dc63b..00000000 --- a/static/freebsd/man4/route.4 3.html +++ /dev/null @@ -1,246 +0,0 @@ - - - - - - -
ROUTE(4)Device Drivers ManualROUTE(4)
-
-
-

-

route — kernel - packet forwarding database

-
-
-

-

#include - <sys/types.h> -
- #include <sys/time.h> -
- #include <sys/socket.h> -
- #include <net/if.h> -
- #include <net/route.h>

-

int -
- socket(PF_ROUTE, - SOCK_RAW, - int family);

-
-
-

-

FreeBSD provides some packet routing - facilities. The kernel maintains a routing information database, which is - used in selecting the appropriate network interface when transmitting - packets.

-

A user process (or possibly multiple co-operating processes) - maintains this database by sending messages over a special kind of socket. - This supplants fixed size ioctl(2)'s used in earlier - releases. Routing table changes may only be carried out by the super - user.

-

The operating system may spontaneously emit routing messages in - response to external events, such as receipt of a re-direct, or failure to - locate a suitable route for a request. The message types are described in - greater detail below.

-

Routing database entries come in two flavors: for a specific host, - or for all hosts on a generic subnetwork (as specified by a bit mask and - value under the mask. The effect of wildcard or default route may be - achieved by using a mask of all zeros, and there may be hierarchical - routes.

-

When the system is booted and addresses are assigned to the - network interfaces, each protocol family installs a routing table entry for - each interface when it is ready for traffic. Normally the protocol specifies - the route through each interface as a “direct” connection to - the destination host or network. If the route is direct, the transport layer - of a protocol family usually requests the packet be sent to the same host - specified in the packet. Otherwise, the interface is requested to address - the packet to the gateway listed in the routing entry (i.e., the packet is - forwarded).

-

When routing a packet, the kernel will attempt to find the most - specific route matching the destination. (If there are two different mask - and value-under-the-mask pairs that match, the more specific is the one with - more bits in the mask. A route to a host is regarded as being supplied with - a mask of as many ones as there are bits in the destination). If no entry is - found, the destination is declared to be unreachable, and a routing-miss - message is generated if there are any listeners on the routing control - socket described below.

-

A wildcard routing entry is specified with a zero destination - address value, and a mask of all zeroes. Wildcard routes will be used when - the system fails to find other routes matching the destination. The - combination of wildcard routes and routing redirects can provide an - economical mechanism for routing traffic.

-

One opens the channel for passing routing control messages by - using the socket call shown in the synopsis above:

-

The family parameter may be - AF_UNSPEC which will provide routing information for - all address families, or can be restricted to a specific address family by - specifying which one is desired. There can be more than one routing socket - open per system.

-

Messages are formed by a header followed by a small number of - sockaddrs (now variable length particularly in the ISO case), interpreted by - position, and delimited by the new length entry in the sockaddr. An example - of a message with four addresses might be an ISO redirect: Destination, - Netmask, Gateway, and Author of the redirect. The interpretation of which - address are present is given by a bit mask within the header, and the - sequence is least significant to most significant bit within the vector.

-

Any messages sent to the kernel are returned, and copies are sent - to all interested listeners. The kernel will provide the process ID for the - sender, and the sender may use an additional sequence field to distinguish - between outstanding messages. However, message replies may be lost when - kernel buffers are exhausted.

-

The kernel may reject certain messages, and will - indicate this by filling in the rtm_errno field. The - routing code returns EEXIST if requested to - duplicate an existing entry, ESRCH if requested to - delete a non-existent entry, or ENOBUFS if - insufficient resources were available to install a new route. In the current - implementation, all routing processes run locally, and the values for - rtm_errno are available through the normal - mechanism, - even if the routing reply message is lost.

-

A process may avoid the expense of reading replies to its own - messages by issuing a setsockopt(2) call indicating that - the SO_USELOOPBACK option at the - SOL_SOCKET level is to be turned off. A process may - ignore all messages from the routing socket by doing a - shutdown(2) system call for further input.

-

If a route is in use when it is deleted, the routing entry will be - marked down and removed from the routing table, but the resources associated - with it will not be reclaimed until all references to it are released. User - processes can obtain information about the routing entry to a specific - destination by using a RTM_GET message, or by - calling sysctl(3).

-

Messages include:

-
-
#define	RTM_ADD		0x1    /* Add Route */
-#define	RTM_DELETE	0x2    /* Delete Route */
-#define	RTM_CHANGE	0x3    /* Change Metrics, Flags, or Gateway */
-#define	RTM_GET		0x4    /* Report Information */
-#define	RTM_LOSING	0x5    /* Kernel Suspects Partitioning */
-#define	RTM_REDIRECT	0x6    /* Told to use different route */
-#define	RTM_MISS	0x7    /* Lookup failed on this address */
-#define	RTM_LOCK	0x8    /* fix specified metrics */
-#define	RTM_RESOLVE	0xb    /* request to resolve dst to LL addr - unused */
-#define	RTM_NEWADDR	0xc    /* address being added to iface */
-#define	RTM_DELADDR	0xd    /* address being removed from iface */
-#define	RTM_IFINFO	0xe    /* iface going up/down etc. */
-#define	RTM_NEWMADDR	0xf    /* mcast group membership being added to if */
-#define	RTM_DELMADDR	0x10   /* mcast group membership being deleted */
-#define	RTM_IFANNOUNCE	0x11   /* iface arrival/departure */
-#define	RTM_IEEE80211	0x12   /* IEEE80211 wireless event */
-
-

A message header consists of one of the following:

-
-
struct rt_msghdr {
-    u_short rtm_msglen;         /* to skip over non-understood messages */
-    u_char  rtm_version;        /* future binary compatibility */
-    u_char  rtm_type;           /* message type */
-    u_short rtm_index;          /* index for associated ifp */
-    int     rtm_flags;          /* flags, incl. kern & message, e.g. DONE */
-    int     rtm_addrs;          /* bitmask identifying sockaddrs in msg */
-    pid_t   rtm_pid;            /* identify sender */
-    int     rtm_seq;            /* for sender to identify action */
-    int     rtm_errno;          /* why failed */
-    int     rtm_fmask;          /* bitmask used in RTM_CHANGE message */
-    u_long  rtm_inits;          /* which metrics we are initializing */
-    struct  rt_metrics rtm_rmx;	/* metrics themselves */
-};
-
-struct if_msghdr {
-    u_short ifm_msglen;         /* to skip over non-understood messages */
-    u_char  ifm_version;        /* future binary compatibility */
-    u_char  ifm_type;           /* message type */
-    int     ifm_addrs;          /* like rtm_addrs */
-    int     ifm_flags;          /* value of if_flags */
-    u_short ifm_index;          /* index for associated ifp */
-    struct  if_data ifm_data;   /* statistics and other data about if */
-};
-
-struct ifa_msghdr {
-    u_short ifam_msglen;        /* to skip over non-understood messages */
-    u_char  ifam_version;       /* future binary compatibility */
-    u_char  ifam_type;          /* message type */
-    int     ifam_addrs;         /* like rtm_addrs */
-    int     ifam_flags;         /* value of ifa_flags */
-    u_short ifam_index;         /* index for associated ifp */
-    int     ifam_metric;        /* value of ifa_metric */
-};
-
-struct ifma_msghdr {
-    u_short ifmam_msglen;       /* to skip over non-understood messages */
-    u_char  ifmam_version;      /* future binary compatibility */
-    u_char  ifmam_type;         /* message type */
-    int     ifmam_addrs;        /* like rtm_addrs */
-    int     ifmam_flags;        /* value of ifa_flags */
-    u_short ifmam_index;        /* index for associated ifp */
-};
-
-struct if_announcemsghdr {
-	u_short	ifan_msglen;	/* to skip over non-understood messages */
-	u_char	ifan_version;	/* future binary compatibility */
-	u_char	ifan_type;	/* message type */
-	u_short	ifan_index;	/* index for associated ifp */
-	char	ifan_name[IFNAMSIZ]; /* if name, e.g. "en0" */
-	u_short	ifan_what;	/* what type of announcement */
-};
-
-

The RTM_IFINFO message uses a - if_msghdr header, the - RTM_NEWADDR and RTM_DELADDR - messages use a ifa_msghdr header, the - RTM_NEWMADDR and - RTM_DELMADDR messages use a - ifma_msghdr header, the - RTM_IFANNOUNCE message uses a - if_announcemsghdr header, and all other messages use - the rt_msghdr header.

-

The “struct rt_metrics” and - the flag bits are as defined in rtentry(9).

-

Specifiers for metric values in rmx_locks and rtm_inits are:

-
-
#define	RTV_MTU       0x1    /* init or lock _mtu */
-#define	RTV_HOPCOUNT  0x2    /* init or lock _hopcount */
-#define	RTV_EXPIRE    0x4    /* init or lock _expire */
-#define	RTV_RPIPE     0x8    /* init or lock _recvpipe */
-#define	RTV_SPIPE     0x10   /* init or lock _sendpipe */
-#define	RTV_SSTHRESH  0x20   /* init or lock _ssthresh */
-#define	RTV_RTT       0x40   /* init or lock _rtt */
-#define	RTV_RTTVAR    0x80   /* init or lock _rttvar */
-#define	RTV_WEIGHT    0x100  /* init or lock _weight */
-
-

Specifiers for which addresses are present in the messages - are:

-
-
#define RTA_DST       0x1    /* destination sockaddr present */
-#define RTA_GATEWAY   0x2    /* gateway sockaddr present */
-#define RTA_NETMASK   0x4    /* netmask sockaddr present */
-#define RTA_GENMASK   0x8    /* cloning mask sockaddr present - unused */
-#define RTA_IFP       0x10   /* interface name sockaddr present */
-#define RTA_IFA       0x20   /* interface addr sockaddr present */
-#define RTA_AUTHOR    0x40   /* sockaddr for author of redirect */
-#define RTA_BRD       0x80   /* for NEWADDR, broadcast or p-p dest addr */
-
-
-
-

-

sysctl(3), route(8), - rtentry(9)

-

The constants for the rtm_flags field are - documented in the manual page for the route(8) - utility.

-
-
-

-

A PF_ROUTE protocol family first appeared - in 4.3BSD-Reno.

-
-
- - - - - -
November 4, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/rsu.4 3.html b/static/freebsd/man4/rsu.4 3.html deleted file mode 100644 index ac00c4fb..00000000 --- a/static/freebsd/man4/rsu.4 3.html +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - -
RSU(4)Device Drivers ManualRSU(4)
-
-
-

-

rsu — Realtek - RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device rsu -
-device rsufw -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_rsu_load="YES"
-rsu-rtl8712fw_load="YES"
-
-
-
-

-

The rsu driver supports USB 2.0 wireless - network devices based on Realtek RTL8188SU, RTL8191SU and RTL8192SU - chipsets.

-

The RTL8188SU is a highly integrated 802.11n adapter that combines - a MAC, a 1T1R capable baseband and an RF in a single chip. It operates in - the 2GHz spectrum only.

-

The RTL8191SU is a highly integrated multiple-in, single-out - (MISO) 802.11n adapter that combines a MAC, a 1T2R capable baseband and an - RF in a single chip. It operates in the 2GHz spectrum only.

-

The RTL8192SU is a highly integrated multiple-in, multiple-out - (MIMO) 802.11n adapter that combines a MAC, a 2T2R capable baseband and an - RF in a single chip. It operates in the 2GHz spectrum only.

-

These are the modes the rsu driver can - operate in:

-
-
BSS mode
-
Also known as - - mode, this is used when associating with an access point, through which - all traffic passes. This mode is the default.
-
monitor mode
-
In this mode the driver is able to receive packets without associating - with an access point. This disables the internal receive filter and - enables the card to capture packets from networks which it wouldn't - normally have access to, or to scan for access points.
-
-

The rsu driver can be configured to use - Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and - WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It - is strongly recommended that WEP not be used as the sole mechanism to secure - wireless communication, due to serious weaknesses in it.

-

The rsu driver can be configured at - runtime with ifconfig(8).

-
-
-

-

The rsu driver provides support for - Realtek RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network adapters, - including:

-

-
    -
  • ASUS USB-N10
    • -
  • ASUS WL-167G V3
    • -
  • Belkin F7D1101 v1
    • -
  • D-Link DWA-131 A1
    • -
  • EDUP EP-MS150N(W)
    • -
  • Edimax EW-7622UMN
    • -
  • Hercules HWGUn-54
    • -
  • Hercules HWNUm-300
    • -
  • Planex GW-USNano
    • -
  • Sitecom WL-349 v1
    • -
  • Sitecom WL-353
    • -
  • Sitecom WLA-1100 v1001
    • -
  • Sweex LW154
    • -
  • TRENDnet TEW-646UBH
    • -
  • TRENDnet TEW-648UB
    • -
  • TRENDnet TEW-649UB
    • -
-
-
-

-
-
/usr/share/doc/legal/realtek.LICENSE
-
rsu firmware license
-
-

The driver needs at least version 1.2 of the following firmware - file, which is loaded when an interface is attached:

-

-
-
-
/boot/kernel/rsu-rtl8712fw.ko
-
 
-
-
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev rsu0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev rsu0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev rsu0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-
-
%s: failed load firmware of file rsu-rtl8712fw
-
For some reason, the driver was unable to read the microcode file from the - filesystem. The file might be missing or corrupted.
-
device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
-
-
-

-

intro(1), netintro(4), - rsufw(4), usb(4), - wlan(4), networking(7), - arp(8), hostapd(8), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

The rsu driver first appeared in - OpenBSD 4.9 and FreeBSD - 10.0.

-
-
-

-

The rsu driver was written by - Damien Bergamini - <damien@openbsd.org> - and ported by Rui Paulo - <rpaulo@freebsd.org>. - The 802.11n support was added by Adrian Chadd - <adrian@freebsd.org>.

-
-
-

-

The rsu driver currently does not support - 802.11n transmit aggregation, either A-MSDU or A-MPDU.

-

The rsu driver does not capture management - frames in non-monitor modes; without this limitation some firmware functions - (e.g., 'join bss') will not work properly.

-
-
- - - - - -
April 1, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/rsufw.4 4.html b/static/freebsd/man4/rsufw.4 4.html deleted file mode 100644 index 33bc9eed..00000000 --- a/static/freebsd/man4/rsufw.4 4.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - -
RSUFW(4)Device Drivers ManualRSUFW(4)
-
-
-

-

rsufw — Firmware - Module for Realtek driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device rsufw
-

This will include the firmware image, RTL8712, inside the kernel. - rsu(4) will load the image into the chip.

-

Alternatively, to load the firmware images as a module at boot - time, place the following line in loader.conf(5):

-
-
rsu-rtl8712fw_load="YES"
-
-
-
-

-

This module provides the firmware for the Realtek RTL8188SU and - RTL8192SU chip based USB WiFi adapters. Please read Realtek's license, - /usr/share/doc/legal/realtek.LICENSE.

-
-
-

-

rsu(4), firmware(9)

-
-
- - - - - -
April 4, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/rtnetlink.4 3.html b/static/freebsd/man4/rtnetlink.4 3.html deleted file mode 100644 index a0379396..00000000 --- a/static/freebsd/man4/rtnetlink.4 3.html +++ /dev/null @@ -1,540 +0,0 @@ - - - - - - -
RTNETLINK(4)Device Drivers ManualRTNETLINK(4)
-
-
-

-

RTNetlink — - Network configuration-specific Netlink family

-
-
-

-

#include - <netlink/netlink.h> -
- #include - <netlink/netlink_route.h>

-

int -
- socket(AF_NETLINK, - SOCK_RAW, - NETLINK_ROUTE);

-
-
-

-

The NETLINK_ROUTE family aims to be the - primary configuration mechanism for all network-related tasks. Currently it - supports configuring interfaces, interface addresses, routes, nexthops and - arp/ndp neighbors.

-
-
-

-

All route configuration messages share the common header:

-
-
struct rtmsg {
-	unsigned char	rtm_family;	/* address family */
-	unsigned char	rtm_dst_len;	/* Prefix length */
-	unsigned char	rtm_src_len;	/* Deprecated, set to 0 */
-	unsigned char	rtm_tos;	/* Type of service (not used) */
-	unsigned char	rtm_table;	/* deprecated, set to 0 */
-	unsigned char	rtm_protocol;	/* Routing protocol id (RTPROT_) */
-	unsigned char	rtm_scope;	/* Route distance (RT_SCOPE_) */
-	unsigned char	rtm_type;	/* Route type (RTN_) */
-	unsigned 	rtm_flags;	/* Route flags (not supported) */
-};
-
-

The rtm_family specifies the route family to - be operated on. Currently, AF_INET6 and - AF_INET are the only supported families. The route - prefix length is stored in rtm_dst_len The caller - should set the originator identity (one of the - RTPROT_ values) in - rtm_protocol It is useful for users and for the - application itself, allowing for easy identification of self-originated - routes. The route scope has to be set via rtm_scope - field. The supported values are:

-
-
RT_SCOPE_UNIVERSE	Global scope
-RT_SCOPE_LINK		Link scope
-
-

Route type needs to be set. The defined values are:

-
-
RTN_UNICAST	Unicast route
-RTN_MULTICAST	Multicast route
-RTN_BLACKHOLE	Drops traffic towards destination
-RTN_PROHIBIT	Drops traffic and sends reject
-
-

The following messages are supported:

-
-

-

Adds a new route. All NL flags are supported. Extending a - multipath route requires NLM_F_APPEND flag.

-
-
-

-

Tries to delete a route. The route is specified using a - combination of RTA_DST TLV and - rtm_dst_len.

-
-
-

-

Fetches a single route or all routes in the current VNET, - depending on the NLM_F_DUMP flag. Each route is - reported as RTM_NEWROUTE message. The following - filters are recognised by the kernel:

-

-
-
rtm_family	required family or AF_UNSPEC
-RTA_TABLE	fib number or RT_TABLE_UNSPEC to return all fibs
-
-
-
-

-
-
-
(binary) IPv4/IPv6 address, depending on the - rtm_family.
-
-
(uint32_t) transmit interface index.
-
-
(binary) IPv4/IPv6 gateway address, depending on the - rtm_family.
-
-
(nested) Container attribute, listing route properties. The only supported - sub-attribute is RTAX_MTU, which stores path MTU - as uint32_t.
-
-
This attribute contains multipath route nexthops with their weights. These - nexthops are represented as a sequence of rtnexthop - structures, each followed by RTA_GATEWAY or - RTA_VIA attributes. -
- 
struct rtnexthop {
-	unsigned short		rtnh_len;
-	unsigned char		rtnh_flags;
-	unsigned char		rtnh_hops;	/* nexthop weight */
-	int			rtnh_ifindex;
-};
-
-

The rtnh_len field specifies the total - nexthop info length, including both struct - rtnexthop and the following TLVs. The - rtnh_hops field stores relative nexthop weight, - used for load balancing between group members. The - rtnh_ifindex field contains the index of the - transmit interface.

-

The following TLVs can follow the structure:

-
- 
RTA_GATEWAY	IPv4/IPv6 nexthop address of the gateway
-RTA_VIA		IPv6 nexthop address for IPv4 route
-RTA_KNH_ID	Kernel-specific index of the nexthop
-
-
-
-
(uint32_t) (FreeBSD-specific) Auto-allocated kernel index of the - nexthop.
-
-
(uint32_t) (FreeBSD-specific) rtsock route flags.
-
-
(uint32_t) Fib number of the route. Default route table is - RT_TABLE_MAIN. To explicitly specify "all - tables" one needs to set the value to - RT_TABLE_UNSPEC.
-
-
(uint32_t) seconds till path expiration.
-
-
(uint32_t) useland nexthop or nexthop group index.
-
-
-
-

-

The following groups are defined:

-
-
RTNLGRP_IPV4_ROUTE	Notifies on IPv4 route arrival/removal/change
-RTNLGRP_IPV6_ROUTE	Notifies on IPv6 route arrival/removal/change
-
-
-
-
-

-

All nexthop/nexthop group configuration messages share the common - header:

-
-
struct nhmsg {
-        unsigned char	nh_family;	/* transport family */
-	unsigned char	nh_scope;	/* ignored on RX, filled by kernel */
-	unsigned char	nh_protocol;	/* Routing protocol that installed nh */
-	unsigned char	resvd;
-	unsigned int	nh_flags;	/* RTNH_F_* flags from route.h */
-};
-
-The nh_family specifies the gateway address family. It can - be different from route address family for IPv4 routes with IPv6 nexthops. The - nh_protocol is similar to - rtm_protocol field, which designates originator - application identity. -

The following messages are supported:

-
-

-

Creates a new nexthop or nexthop group.

-
-
-

-

Deletes nexthop or nexthhop group. The required object is - specified by the RTA_NH_ID attribute.

-
-
-

-

Fetches a single nexthop or all nexthops/nexthop groups, depending - on the NLM_F_DUMP flag. The following filters are - recognised by the kernel:

-

-
-
RTA_NH_ID	nexthop or nexthtop group id
-NHA_GROUPS	match only nexthtop groups
-
-
-
-

-
-
-
(uint32_t) Nexthhop index used to identify particular nexthop or nexthop - group. Should be provided by userland at the nexthtop creation time.
-
-
This attribute designates the nexthtop group and contains all of its - nexthtops and their relative weights. The attribute consists of a list of - nexthop_grp structures: -
- 
struct nexthop_grp {
-	uint32_t	id;		/* nexhop userland index */
-	uint8_t		weight;         /* weight of this nexthop */
-	uint8_t		resvd1;
-	uint16_t	resvd2;
-};
-
-
-
-
(uint16_t) Nexthtop group type, set to one of the following types: -
- 
NEXTHOP_GRP_TYPE_MPATH	default multipath group
-
-
-
-
(flag) Marks the nexthtop as blackhole.
-
-
(uint32_t) Transmit interface index of the nexthtop.
-
-
(binary) IPv4/IPv6 gateway address
-
-
(flag) Matches nexthtop groups during dump.
-
-
-
-

-

The following groups are defined:

-
-
RTNLGRP_NEXTHOP		Notifies on nexthop/groups arrival/removal/change
-
-
-
-
-

-

All interface configuration messages share the common header:

-
-
struct ifinfomsg {
-	unsigned char	ifi_family;	/* not used, set to 0 */
-	unsigned char	__ifi_pad;
-	unsigned short	ifi_type;	/* ARPHRD_* */
-	int		ifi_index;	/* Interface index */
-	unsigned	ifi_flags;	/* IFF_* flags */
-	unsigned	ifi_change;	/* IFF_* change mask */
-};
-
-
- -

Creates a new interface. The only mandatory TLV is - IFLA_IFNAME. The following attributes are returned - inside the nested NLMSGERR_ATTR_COOKIE:

-

-
-
IFLA_NEW_IFINDEX	(uint32) created interface index
-IFLA_IFNAME		(string) created interface name
-
-
-
- -

Deletes the interface specified by - IFLA_IFNAME.

-
-
- -

Fetches a single interface or all interfaces in the current VNET, - depending on the NLM_F_DUMP flag. Each interface is - reported as a RTM_NEWLINK message. The following - filters are recognised by the kernel:

-

-
-
ifi_index	interface index
-IFLA_IFNAME	interface name
-IFLA_ALT_IFNAME	interface name
-
-
-
-

-
-
-
(binary) Llink-level interface address (MAC).
-
-
(binary) (readonly) Link-level broadcast address.
-
-
(string) New interface name.
-
-
(string) Interface description.
- -
(uint32_t) (readonly) Interface index.
-
-
(uint32_t) Parent interface index.
-
-
(nested) Interface type-specific attributes: -
- 
IFLA_INFO_KIND		(string) interface type ("vlan")
-IFLA_INFO_DATA		(nested) custom attributes
-
- The following types and attributes are supported: -
-
-
-
- 
IFLA_VLAN_ID		(uint16_t) 802.1Q vlan id
-IFLA_VLAN_PROTOCOL	(uint16_t) Protocol: ETHERTYPE_VLAN or ETHERTYPE_QINQ
-
-
-
-
-
-
(uint8_t) Interface operational state per RFC 2863. Can be one of the - following: -
- 
IF_OPER_UNKNOWN		status can not be determined
-IF_OPER_NOTPRESENT	some (hardware) component not present
-IF_OPER_DOWN		down
-IF_OPER_LOWERLAYERDOWN	some lower-level interface is down
-IF_OPER_TESTING		in some test mode
-IF_OPER_DORMANT		"up" but waiting for some condition (802.1X)
-IF_OPER_UP		ready to pass packets
-
-
-
-
(readonly) Consists of the following 64-bit counters structure: -
- 
struct rtnl_link_stats64 {
-	uint64_t rx_packets;	/* total RX packets (IFCOUNTER_IPACKETS) */
-	uint64_t tx_packets;	/* total TX packets (IFCOUNTER_OPACKETS) */
-	uint64_t rx_bytes;	/* total RX bytes (IFCOUNTER_IBYTES) */
-	uint64_t tx_bytes;	/* total TX bytes (IFCOUNTER_OBYTES) */
-	uint64_t rx_errors;	/* RX errors (IFCOUNTER_IERRORS) */
-	uint64_t tx_errors;	/* RX errors (IFCOUNTER_OERRORS) */
-	uint64_t rx_dropped;	/* RX drop (no space in ring/no bufs) (IFCOUNTER_IQDROPS) */
-	uint64_t tx_dropped;	/* TX drop (IFCOUNTER_OQDROPS) */
-	uint64_t multicast;	/* RX multicast packets (IFCOUNTER_IMCASTS) */
-	uint64_t collisions;	/* not supported */
-	uint64_t rx_length_errors;	/* not supported */
-	uint64_t rx_over_errors;	/* not supported */
-	uint64_t rx_crc_errors;		/* not supported */
-	uint64_t rx_frame_errors;	/* not supported */
-	uint64_t rx_fifo_errors;	/* not supported */
-	uint64_t rx_missed_errors;	/* not supported */
-	uint64_t tx_aborted_errors;	/* not supported */
-	uint64_t tx_carrier_errors;	/* not supported */
-	uint64_t tx_fifo_errors;	/* not supported */
-	uint64_t tx_heartbeat_errors;	/* not supported */
-	uint64_t tx_window_errors;	/* not supported */
-	uint64_t rx_compressed;		/* not supported */
-	uint64_t tx_compressed;		/* not supported */
-	uint64_t rx_nohandler;	/* dropped due to no proto handler (IFCOUNTER_NOPROTO) */
-};
-
-
-
-
-
-

-

The following groups are defined:

-
-
RTNLGRP_LINK		Notifies on interface arrival/removal/change
-
-
-
-
-

-

All interface address configuration messages share the common - header:

-
-
struct ifaddrmsg {
-	uint8_t		ifa_family;	/* Address family */
-	uint8_t		ifa_prefixlen;	/* Prefix length */
-	uint8_t		ifa_flags;	/* Address-specific flags */
-	uint8_t		ifa_scope;	/* Address scope */
-	uint32_t	ifa_index;	/* Link ifindex */
-};
-
-

The ifa_family specifies the address family - of the interface address. The ifa_prefixlen specifies - the prefix length if applicable for the address family. The - ifa_index specifies the interface index of the target - interface.

-
-

-

Not supported

-
-
-

-

Not supported

-
-
-

-

Fetches interface addresses in the current VNET matching - conditions. Each address is reported as a - RTM_NEWADDR message. The following filters are - recognised by the kernel:

-

-
-
ifa_family	required family or AF_UNSPEC
-ifa_index	matching interface index or 0
-
-
-
-

-
-
-
(binary) masked interface address or destination address for p2p - interfaces.
-
-
(binary) local interface address. Set for IPv4 and p2p addresses.
-
-
(string) interface name.
-
-
(binary) broadcast interface address.
-
-
-
-

-

The following groups are defined:

-
-
RTNLGRP_IPV4_IFADDR	Notifies on IPv4 ifaddr arrival/removal/change
-RTNLGRP_IPV6_IFADDR	Notifies on IPv6 ifaddr arrival/removal/change
-
-
-
-
-

-

All neighbor configuration messages share the common header:

-
-
struct ndmsg {
-	uint8_t		ndm_family;
-	uint8_t		ndm_pad1;
-	uint16_t	ndm_pad2;
-	int32_t		ndm_ifindex;
-	uint16_t	ndm_state;
-	uint8_t		ndm_flags;
-	uint8_t		ndm_type;
-};
-
-

The ndm_family field specifies the address - family (IPv4 or IPv6) of the neighbor. The ndm_ifindex - specifies the interface to operate on. The ndm_state - represents the entry state according to the neighbor model. The state can be - one of the following:

-
-
NUD_INCOMPLETE		No lladdr, address resolution in progress
-NUD_REACHABLE		reachable & recently resolved
-NUD_STALE		has lladdr but it's stale
-NUD_DELAY		has lladdr, is stale, probes delayed
-NUD_PROBE		has lladdr, is stale, probes sent
-NUD_FAILED		unused
-
-

The ndm_flags field stores the options - specific to this entry. Available flags:

-
-
NTF_SELF		local station (LLE_IFADDR)
-NTF_PROXY		proxy entry (LLE_PUB)
-NTF_STICKY		permanent entry (LLE_STATIC)
-NTF_ROUTER		dst indicated itself as a router
-
-
-

-

Creates new neighbor entry. The mandatory options are - NDA_DST, NDA_LLADDR and - NDA_IFINDEX.

-
-
-

-

Deletes the neighbor entry. The entry is specified by the - combination of NDA_DST and - NDA_IFINDEX.

-
-
-

-

Fetches a single neighbor or all neighbors in the current VNET, - depending on the NLM_F_DUMP flag. Each entry is - reported as RTM_NEWNEIGH message. The following - filters are recognised by the kernel:

-

-
-
ndm_family	required family or AF_UNSPEC
-ndm_ifindex	target ifindex
-NDA_IFINDEX	target ifindex
-
-
-
-

-
-
-
(binary) neighbor IPv4/IPv6 address.
-
-
(binary) neighbor link-level address.
-
-
(uint32_t) interface index.
-
-
(uint32_t) extended version of ndm_flags.
-
-
-
-

-

The following groups are defined:

-
-
RTNLGRP_NEIGH	Notifies on ARP/NDP neighbor  arrival/removal/change
-
-
-
-
-

-

snl(3), netlink(4), - route(4)

-
-
-

-

The NETLINK_ROUTE protocol family appeared - in FreeBSD 13.2.

-
-
-

-

The netlink was implemented by Alexander - Chernikov - <melifaro@FreeBSD.org>. - It was derived from the Google Summer of Code 2021 project by - Ng Peng Nam Sean.

-
-
- - - - - -
November 1, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/rtsx.4 3.html b/static/freebsd/man4/rtsx.4 3.html deleted file mode 100644 index 37a6ef48..00000000 --- a/static/freebsd/man4/rtsx.4 3.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - -
RTSX(4)Device Drivers ManualRTSX(4)
-
-
-

-

rtsx — Realtek SD - card reader

-
-
-

-

To compile this driver into the kernel, place the following lines - in the kernel configuration file:

-
device mmc -
-device mmcsd -
-device rtsx
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
mmc_load="YES"
-

-mmcsd_load="YES"
-

-rtsx_load="YES"
-
-
-
-

-

The rtsx driver provides support for - Realtek SD card reader. Driver attaches mmc bus on card insertion and - detaches it on card removing.

-
-
-

-

The rtsx driver supports the following - Realtek SD card readers:

-

-
    -
  • RTS5209
    • -
  • RTS5227
    • -
  • RTS5229
    • -
  • RTS522A
    • -
  • RTS525A
    • -
  • RTS5260
    • -
  • RTL8411B
    • -
  • RTS5249 (unverified)
    • -
  • RTL8402 (unverified)
    • -
  • RTL8411 (unverified)
    • -
-
-
-

-

mmc(4), mmcsd(4)

-

SD Specifications, Part 2, SD - Host Controller, Simplified Specification, SanDisk - Secure Digital Card.

-
-
-

-

The rtsx driver appeared in - FreeBSD 13.0 and was ported from - OpenBSD with modifications found in Linux and - NetBSD.

-
-
-

-

Henri Hennebert - <hlh@restart.be> -
- Gary Jennejohn - <gj@freebsd.org> -
- Jesper Schmitz Mouridsen - <jsm@FreeBSD.org>

-
-
-

-
-

Lutz Bichler - <Lutz.Bichler@gmail.com>

-
-
-

-

- can be set with the following masks:

-
    -
  • 0x01 - to show the basic flow of the driver,
    • -
  • 0x02 - to trace the SD commands,
    • -
  • 0x04 - to trace the tuning phase.
    • -
-
-
-

-
    -
  • RTS522A on Lenovo T470p, card detection and read-only switch are reversed. - This is solved by adding in loader.conf(5): -
    dev.rtsx.0.inversion=1
    -

    The driver tries to automate those exceptions. If this - automation is wrong, it can be avoided by adding in - loader.conf(5):

    -
    dev.rtsx.0.inversion=0
    -
    • -
  • Mounting a filesystem with write access on a card write protected may - involve a kernel crash.
    • -
  • Suspend/Resume do not work under MMCCAM.
    • -
  • For some chips (e.g. RTS5260) after devctl - disable/enable or kldunload/kldload the - driver can't detect a card correctly.
    • -
-
-
- - - - - -
May 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/rtw88.4 3.html b/static/freebsd/man4/rtw88.4 3.html deleted file mode 100644 index 470ff5c3..00000000 --- a/static/freebsd/man4/rtw88.4 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
RTW88(4)Device Drivers ManualRTW88(4)
-
-
-

-

rtw88 — Realtek - IEEE 802.11n/ac wireless network driver

-
-
-

-

The driver will auto-load without any user interaction using - devmatch(8) if enabled in - rc.conf(5).

-

Only if auto-loading is explicitly disabled, place the following - lines in rc.conf(5) to manually load the driver as a - module at boot time:

-
-
kld_list="${kld_list} if_rtw88"
-
-

It is not possible to load the driver from - loader(8).

-
-
-

-

The rtw88 driver is derived from Realtek's - Linux rtw88 driver.

-

This driver requires firmware to be loaded before it will work. - The package wifi-firmware-rtw88-kmod from the - ports/net/wifi-firmware-rtw88-kmod port needs to be - installed before the driver is loaded. Otherwise no - wlan(4) interface can be created using - ifconfig(8). One can use fwget(8) to - install the correct firmware package.

-

The driver uses the - - and - - compat framework to bridge between the Linux and native - FreeBSD driver code as well as to the native - net80211(4) wireless stack.

-
-
-

-

The rtw88 driver supports PCIe devices - with the following chipsets:

-

-
    -
  • Realtek 802.11n wireless 8723de (RTL8723DE)
    • -
  • Realtek 802.11ac wireless 8821ce (RTL8821CE)
    • -
  • Realtek 802.11ac wireless 8822be (RTL8822BE)
    • -
  • Realtek 802.11ac wireless 8822ce (RTL8822CE)
    • -
-
-
-

-
-
compat.linuxkpi.skb.mem_limit
-
If you are running a 64bit system with more than 4GB of main memory you - need to set this tunable to - in - loader.conf(5) and reboot once to make it effective. - This tunable will work around a problem with DMA and limit allocations for - network buffer memory to the lower 32bit of physical memory and make the - driver work.
-
-
-
-

-

wlan(4), networking(7), - fwget(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The rtw88 driver first appeared in - FreeBSD 13.2.

-
-
-

-

Certainly.

-

Does not seem to work (reliably) on machines with more than 4GB of - main memory. See in the LOADER - TUNABLES section above.

-

While rtw88 supports 802.11a/b/g/n/ac - modes, the compatibility code currently only supports 802.11a/b/g modes. - Support for 802.11n/ac is yet to come.

-
-
- - - - - -
February 10, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/rtw89.4 3.html b/static/freebsd/man4/rtw89.4 3.html deleted file mode 100644 index a4a74d16..00000000 --- a/static/freebsd/man4/rtw89.4 3.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - -
RTW89(4)Device Drivers ManualRTW89(4)
-
-
-

-

rtw89 — Realtek - IEEE 802.11ax wireless network driver

-
-
-

-

The driver will auto-load without any user interaction using - devmatch(8) if enabled in - rc.conf(5).

-

Only if auto-loading is explicitly disabled, place the following - lines in rc.conf(5) to manually load the driver as a - module at boot time:

-
-
kld_list="${kld_list} if_rtw89"
-
-

It is not possible to load the driver from - loader(8).

-
-
-

-

The rtw89 driver is derived from Realtek's - Linux rtw89 driver.

-

This driver requires firmware to be loaded before it will work. - The package wifi-firmware-rtw89-kmod from the - ports/net/wifi-firmware-rtw89-kmod port needs to be - installed before the driver is loaded. Otherwise no - wlan(4) interface can be created using - ifconfig(8). One should use fwget(8) to - install the correct firmware package.

-

The driver uses the - - and - - compat framework to bridge between the Linux and native - FreeBSD driver code as well as to the native - net80211(4) wireless stack.

-
-
-

-

The rtw89 driver supports PCIe devices - with the following chipsets:

-

-
    -
  • Realtek 8851BE Wi-Fi 6 (RTL8851BE)
    • -
  • Realtek 8852AE Wi-Fi 6 (RTL8852AE)
    • -
  • Realtek 8852BE Wi-Fi 6 (RTL8852BE)
    • -
  • Realtek 8852CE Wi-Fi 6E (RTL8852CE)
    • -
  • Realtek 8922AE Wi-Fi 7 (RTL8922AE)
    • -
-
-
-

-
-
compat.linuxkpi.skb.mem_limit
-
If you are running a 64bit system with more than 4GB of main memory you - need to set this tunable to - in - loader.conf(5) and reboot once to make it effective. - This tunable will work around a problem with DMA and limit allocations for - network buffer memory to the lower 32bit of physical memory and make the - driver work.
-
-
-
-

-

wlan(4), networking(7), - fwget(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The rtw89 driver first appeared in - FreeBSD 14.2.

-
-
-

-

Certainly.

-

Does not seem to work (reliably) on machines with more than 4GB of - main memory. See in the LOADER - TUNABLES section above.

-

While rtw89 supports 802.11a/b/g/n/ac/ax - modes, the compatibility code currently only supports 802.11a/b/g modes. - Support for 802.11n/ac/ax is yet to come.

-
-
- - - - - -
June 13, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/rtwn.4 3.html b/static/freebsd/man4/rtwn.4 3.html deleted file mode 100644 index 089c2f0a..00000000 --- a/static/freebsd/man4/rtwn.4 3.html +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - -
RTWN(4)Device Drivers ManualRTWN(4)
-
-
-

-

rtwn — Realtek - IEEE 802.11n/ac wireless network driver

-
-
-

-

options RTWN_DEBUG -
- options RTWN_WITHOUT_UCODE

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device rtwn -
-device rtwnfw -
-device rtwn_usb -
-device rtwn_pci -
-device wlan -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - following lines in loader.conf(5):

-
-
if_rtwn_pci_load="YES"
-if_rtwn_usb_load="YES"
-
-
-
-

-

The rtwn driver provides support for - 802.11n/ac wireless network PHYs supplied by rtwn_pci(4) - and rtwn_usb(4).

-

The rtwn driver supports - station, adhoc, - hostap and monitor mode - operation. There are no limitations for number of - monitor mode virtual interfaces; in addition to any - other virtual interface one station interface can be - added (Note: RTL8821AU supports two non-monitor mode interfaces at the same - time).

-

All chips have hardware support for WEP, AES-CCM and TKIP - encryption.

-

The rtwn driver can be configured at - runtime with ifconfig(8).

-
-
-

-

The rtwn driver supports USB and PCI - devices with the following chipsets:

-

-
    -
  • Realtek 802.11n wireless 8188e (RTL8188E)
    • -
  • Realtek 802.11n wireless 8192c (RTL8192C)
    • -
  • Realtek 802.11n wireless 8192e (RTL8192E)
    • -
  • Realtek 802.11ac wireless 8812a (RTL8812A)
    • -
  • Realtek 802.11ac wireless 8821a (RTL8821A)
    • -
-

For specific devices, see rtwn_pci(4) and - rtwn_usb(4).

-
-
-

-
-
/usr/share/doc/legal/realtek.LICENSE
-
rtwn firmware license
-
-

The driver (if not compiled with options - RTWN_WITHOUT_UCODE) may use following firmware files, which are - loaded when an interface is brought up:

-

-
-
-
/boot/kernel/rtwn-rtl8188eefw.ko
-
 
-
/boot/kernel/rtwn-rtl8188eufw.ko
-
 
-
/boot/kernel/rtwn-rtl8192cfwE_B.ko
-
 
-
/boot/kernel/rtwn-rtl8192cfwE.ko
-
 
-
/boot/kernel/rtwn-rtl8192cfwT.ko
-
 
-
/boot/kernel/rtwn-rtl8192cfwU.ko
-
 
-
/boot/kernel/rtwn-rtl8192eufw.ko
-
 
-
/boot/kernel/rtwn-rtl8812aufw.ko
-
 
-
/boot/kernel/rtwn-rtl8821aufw.ko
-
 
-
-
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev rtwn0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev rtwn0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev rtwn0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Create an IBSS network with 128-bit WEP encryption on the channel - 4:

-
-
ifconfig wlan create wlandev rtwn0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1 \
-    channel 4
-
-

Join/create an 802.11b IBSS network with network name - my_net:

-
-
ifconfig wlan0 create wlandev rtwn0 wlanmode adhoc
-ifconfig wlan0 inet 192.0.2.20/24 ssid my_net mode 11b
-
-

Create a host-based access point:

-
-
ifconfig wlan0 create wlandev rtwn0 wlanmode hostap
-ifconfig wlan0 inet 192.0.2.20/24 ssid my_ap
-
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
dev.rtwn.%d.hwcrypto
-
This tunable controls how key slots are assigned: -

0 - disable h/w crypto support. Features that require access - to frame contents (e.g., TCP/UDP/IP Rx checksum validation) will not - work;

-

1 - use h/w crypto support for pairwise keys only;

-

2 - use h/w crypto support for all keys; may not work for - multi-vap configurations.

-

By default it is set to 1.

-
-
dev.rtwn.%d.ratectl
-
This tunable switches between rate control implementations: -

0 - no rate control;

-

1 - driver sends 'tx complete' reports to net80211; algorithm - is controlled via net80211;

-

2 - firmware-based rate control.

-

By default it is set to 1; however driver may choose another - algorithm in case if it is not implemented

-

Currently selected algorithm is reported via - dev.rtwn.%d.ratectl_selected read-only OID.

-
-
dev.rtwn.%d.rx_buf_size
-
(USB only) Controls size of temporary Rx buffer; smaller buffer size may - increase number of interrupts.
-
-
-
-

-
-
rtwn%d: could not read efuse byte at address 0x%x
-
-
rtwn%d: %s: cannot read rom, error %d
-
There was an error while reading ROM; device attach will be aborted. This - should not happen.
-
rtwn%d: failed loadfirmware of file %s
-
For some reason, the driver was unable to read the microcode file from the - filesystem. The file might be missing or corrupted. The driver will - disable firmware-dependent features.
-
rtwn%d: wrong firmware size (%zu)
-
-
rtwn%d: %s: failed to upload firmware %s (error %d)
-
-
rtwn%d: timeout waiting for firmware readiness
-
Firmware upload failed; the file might be corrupted. The driver will - disable firmware-dependent features. This should not happen.
-
rtwn%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
-
-
-

-

intro(4), netintro(4), - rtwn_pci(4), rtwn_usb(4), - rtwnfw(4), wlan(4), - wlan_amrr(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - wlan_xauth(4), networking(7), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The urtwn driver first appeared in - OpenBSD 4.9 and FreeBSD - 10.0; the rtwn driver first appeared in - OpenBSD 5.8 and FreeBSD - 11.0.

-
-
-

-

The rtwn driver was initially written by - Stefan Sperling - <stsp@openbsd.org> - and ported by Kevin Lo - <kevlo@freebsd.org>. - It was based on the urtwn driver written by - Damien Bergamini - <damien.bergamini@free.fr>.

-
-
-

-

The rtwn driver currently does not - implement firmware-based rate control.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/rtwn_pci.4 4.html b/static/freebsd/man4/rtwn_pci.4 4.html deleted file mode 100644 index dab3d13b..00000000 --- a/static/freebsd/man4/rtwn_pci.4 4.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - -
RTWN_PCI(4)Device Drivers ManualRTWN_PCI(4)
-
-
-

-

rtwn_pci — Realtek - wireless rtwn network driver PCI/PCIe support

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device rtwn -
-device rtwn_pci -
-device pci -
-device wlan
-
-
-

-

The rtwn_pci driver provides support for - PCIe wireless network devices to the rtwn(4) driver.

-

Both RTL8188CE and RTL8188EE are highly integrated 802.11n - adapters that combines a MAC, a 1T1R capable baseband and an RF in a single - chip. They are operate in the 2GHz spectrum only.

-
-
-

-

The rtwn_pci driver supports the following - PCIe Wi-Fi devices:

-

-
    -
  • Realtek 802.11n wireless 8188 (RTL8188EE)
    • -
  • Realtek 802.11n wireless 8192 (RTL8192CE)
    • -
-
-
-

-

pci(4), rtwn(4), - rtwn_usb(4), rtwnfw(4)

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/rtwn_usb.4 3.html b/static/freebsd/man4/rtwn_usb.4 3.html deleted file mode 100644 index f83938ab..00000000 --- a/static/freebsd/man4/rtwn_usb.4 3.html +++ /dev/null @@ -1,347 +0,0 @@ - - - - - - -
RTWN_USB(4)Device Drivers ManualRTWN_USB(4)
-
-
-

-

rtwn_usb — Realtek - wireless rtwn network driver USB support

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device xhci -
-device ehci -
-device uhci -
-device ohci -
-device usb -
-device rtwn -
-device rtwn_usb -
-device wlan
-
-
-

-

The rtwn_usb driver provides support for - USB wireless network devices to the rtwn(4) driver.

-
-
-

-

The rtwn_usb driver supports USB wireless - network adapters based on certain Realtek RTL 8188/8192/8812 and 8821 - chipsets, including:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Alfa AWUS036NHR v2RTL8188RUUSB 2.0
ASUS USB-AC56RTL8812AUUSB 3.0
ASUS USB-N10 NANORTL8188CUSUSB 2.0
ASUS USB-N10 NANO rev B1RTL8188EUSUSB 2.0
Asus USB-N13, rev. B1RTL8192CUUSB 2.0
Belkin F7D1102 Surf Wireless MicroRTL8188CUSUSB 2.0
Buffalo WI-U2-433DHPRTL8821AUUSB 2.0
Buffalo WI-U2-433DMRTL8821AUUSB 2.0
Buffalo WI-U3-866DRTL8812AUUSB 3.0
D-Link DWA-121 rev C1A (N150 Nano)RTL8188EUUSB 2.0
D-Link DWA-123 rev D1RTL8188EUUSB 2.0
D-Link DWA-125 rev D1RTL8188EUUSB 2.0
D-Link DWA-131RTL8192CUUSB 2.0
D-Link DWA-131 rev E1RTL8192EUUSB 2.0
D-Link DWA-171 rev A1RTL8821AUUSB 2.0
D-Link DWA-172 rev A1RTL8821AUUSB 2.0
D-Link DWA-180 rev A1RTL8812AUUSB 2.0
D-Link DWA-182 rev C1RTL8812AUUSB 3.0
Edimax EW-7811UnRTL8188CUSUSB 2.0
Edimax EW-7811UTCRTL8821AUUSB 2.0
Edimax EW-7822UACRTL8812AUUSB 3.0
EDUP EP-AC1620RTL8821AUUSB 2.0
Elecom WDC-150SU2MRTL8188EUUSB 2.0
EnGenius EUB1200ACRTL8812AUUSB 3.0
Foxconn WFUR6RTL8812AUUSB 2.0
Hawking HD65URTL8821AUUSB 2.0
Hercules Wireless N USB PicoRTL8188CUSUSB 2.0
I-O Data WN-AC867URTL8812AUUSB 3.0
Linksys WUSB6300RTL8812AUUSB 3.0
NEC AtermWL900U PA-WL900URTL8812AUUSB 3.0
Netgear A6100RTL8821AUUSB 2.0
Netgear WNA1000MRTL8188CUSUSB 2.0
Mercusys MW150USRTL8188EUUSB 2.0
Planex GW-900DRTL8812AUUSB 3.0
Realtek RTL8192CURTL8192CUUSB 2.0
Realtek RTL8188CUSRTL8188CUSUSB 2.0
Sitecom WLA-7100RTL8812AUUSB 3.0
TP-Link Archer T2U NanoRTL8821AUUSB 2.0
TP-Link Archer T2U PlusRTL8821AUUSB 2.0
TP-Link Archer T2U v3RTL8821AUUSB 2.0
TP-Link Archer T4URTL8812AUUSB 3.0
TP-Link Archer T4U v2RTL8812AUUSB 3.0
TP-Link Archer T4UH v1RTL8812AUUSB 3.0
TP-Link Archer T4UH v2RTL8812AUUSB 3.0
TP-Link TL-WN722N v2RTL8188EUUSB 2.0
TP-LINK TL-WN723N v3RTL8188EUUSB 2.0
TP-LINK TL-WN725N v2RTL8188EUUSB 2.0
TP-LINK TL-WN727N v5RTL8188EUUSB 2.0
TP-LINK TL-WN821N v4RTL8192CUUSB 2.0
TP-LINK TL-WN821N v5RTL8192EUUSB 2.0
TP-LINK TL-WN822N v4RTL8192EUUSB 2.0
TP-LINK TL-WN823N v1RTL8192CUUSB 2.0
TP-LINK TL-WN823N v2RTL8192EUUSB 2.0
TRENDnet TEW-805UBRTL8812AUUSB 3.0
ZyXEL NWD6605RTL8812AUUSB 3.0
-
-
-

-

rtwn(4), rtwn_pci(4), - rtwnfw(4), usb(4)

-
-
-

-

The rtwn_usb driver does not support any - of the 802.11ac capabilities offered by the adapters. Additional work is - required in ieee80211(9) before those features can be - supported.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/rtwnfw.4 3.html b/static/freebsd/man4/rtwnfw.4 3.html deleted file mode 100644 index 75e752eb..00000000 --- a/static/freebsd/man4/rtwnfw.4 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
RTWNFW(4)Device Drivers ManualRTWNFW(4)
-
-
-

-

rtwnfw — Firmware - Module for Realtek Wireless driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device rtwnfw
-

This will include all firmware images inside the kernel. If you - want to pick only the firmware image for your network adapter choose one of - the following:

-
device rtwn-rtl8188eefw -
-device rtwn-rtl8188eufw -
-device rtwn-rtl8192cfwE_B -
-device rtwn-rtl8192cfwE -
-device rtwn-rtl8192cfwT -
-device rtwn-rtl8192cfwU -
-device rtwn-rtl8192eufw -
-device rtwn-rtl8812aufw -
-device rtwn-rtl8821aufw
-

Alternatively, to load all firmware images as a module at boot - time, place the following line in loader.conf(5):

-
-
rtwn-rtl8188eefw_load="YES"
-rtwn-rtl8188eufw_load="YES"
-rtwn-rtl8192cfwE_B_load="YES"
-rtwn-rtl8192cfwE_load="YES"
-rtwn-rtl8192cfwT_load="YES"
-rtwn-rtl8192cfwU_load="YES"
-rtwn-rtl8192eufw_load="YES"
-rtwn-rtl8812aufw_load="YES"
-rtwn-rtl8821aufw_load="YES"
-
-
-
-

-

rtwn-rtl8192cfwE and rtl8192cfwE_B modules provide access to - firmware sets for the Realtek RTL8188CE chip based PCIe adapters. - rtwn-rtl8188ee module provides access to firmware sets for the Realtek - RTL8188EE chip based PCIe adapters. Other modules provide access to firmware - sets for the Realtek RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU, - RTL8192CU, RTL8192EU, RTL8812AU and RTL8821AU chip based USB WiFi adapters. - They may be statically linked into the kernel, or loaded as a modules.

-

For the loaded firmware to be enabled for use the license at - /usr/share/doc/legal/realtek.LICENSE must be agreed - to by adding the following line to loader.conf(5):

-

-
legal.realtek.license_ack=1
-
-
-

-
-
/usr/share/doc/legal/realtek.LICENSE
-
rtwnfw firmware license
-
-
-
-

-

rtwn(4), firmware(9)

-
-
- - - - - -
January 3, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/rue.4 3.html b/static/freebsd/man4/rue.4 3.html deleted file mode 100644 index 4987f526..00000000 --- a/static/freebsd/man4/rue.4 3.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - -
RUE(4)Device Drivers ManualRUE(4)
-
-
-

-

rue — Realtek - RTL8150 USB to Fast Ethernet controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device rue
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_rue_load="YES"
-
-
-
-

-

The rue driver provides support for USB - Ethernet adapters based on the Realtek RTL8150 USB to Fast Ethernet - controller chip.

-

The RTL8150 contains an integrated Fast Ethernet MAC, which - supports both 10 and 100Mbps speeds in either full or half duplex. Although - designed to interface with 100Mbps peripheral, the existing USB standard - specifies a maximum transfer speed of 12Mbps. Users should therefore not - expect to actually achieve 100Mbps speeds with this device.

-

The rue driver supports the following - media types:

-
-
-
Enable auto selection of the media type and options. The user can manually - override the auto selected mode by adding media options to the - /etc/rc.conf file.
-
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-

The rue driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The rue driver supports Realtek RTL8150 - based USB Ethernet adapters including:

-

-
    -
  • Buffalo (Melco Inc.) LUA-KTX
    • -
  • Green House GH-USB100B
    • -
  • LinkSys USB100M
    • -
  • Billionton 10/100 FastEthernet USBKR2
    • -
-
-
-

-
-
rue%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
rue%d: rx list init failed
-
The driver failed to allocate an mbuf for the transmitter ring.
-
rue%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
-
-
-

-

arp(4), miibus(4), - netintro(4), ng_ether(4), - ifconfig(8)

-

Realtek RTL8150 data - sheet, - http://pdf.seekdatasheet.com/2008714/200807142333305235.pdf.

-
-
-

-

The rue device driver first appeared in - FreeBSD 5.1.

-
-
-

-

The rue driver was written by - Shunsuke Akiyama - <akiyama@FreeBSD.org>.

-
-
- - - - - -
November 24, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/rum.4 3.html b/static/freebsd/man4/rum.4 3.html deleted file mode 100644 index f35c192b..00000000 --- a/static/freebsd/man4/rum.4 3.html +++ /dev/null @@ -1,281 +0,0 @@ - - - - - - -
RUM(4)Device Drivers ManualRUM(4)
-
-
-

-

rum — Ralink - Technology USB IEEE 802.11a/b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device rum -
-device wlan -
-device wlan_amrr
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_rum_load="YES"
-
-
-
-

-

The rum driver supports USB 2.0 and PCI - Express Mini Card wireless adapters based on the Ralink RT2501USB and - RT2601USB chipsets.

-

Ralink PCI Express Mini Card adapters show up as normal USB 2.0 - devices and are thus handled by the rum driver.

-

The RT2501USB chipset is the second generation of 802.11a/b/g - adapters from Ralink. It consists of two integrated chips, an RT2571W - MAC/BBP and an RT2528 or RT5226 radio transceiver.

-

The RT2601USB chipset consists of two integrated chips, an RT2671 - MAC/BBP and an RT2527 or RT5225 radio transceiver. This chipset uses the - MIMO (multiple-input multiple-output) technology with multiple antennas to - extend the operating range of the adapter and to achieve higher - throughput.

-

All chips have hardware support for WEP, AES-CCM, TKIP, and - Michael cryptographic operations.

-

rum supports - station, adhoc, - adhoc-demo, hostap, and - monitor mode operation. Only one virtual interface - may be configured at any time. For more information on configuring this - device, see ifconfig(8).

-
-
-

-

The rum driver supports USB 2.0 wireless - adapters based on the Ralink RT2501USB and RT2601USB chipsets, - including:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3Com Aolynk WUB320gUSB
Abocom WUG2700 TaUSB
Airlink101 AWLL5025USB
ASUS WL-167g ver 2USB
Belkin F5D7050 ver 3USB
Belkin F5D9050 ver 3USB
Buffalo WLI-U2-SG54HPUSB
Buffalo WLI-U2-SG54HGUSB
Buffalo WLI-U2-G54HPUSB
Buffalo WLI-UC-GUSB
CNet CWD-854 ver FUSB
Conceptronic C54RU ver 2USB
Corega CG-WLUSB2GOUSB
D-Link DWA-110USB
D-Link DWA-111USB
D-Link DWL-G122 rev C1USB
D-Link WUA-1340USB
Digitus DN-7003GRUSB
Edimax EW-7318USGUSB
Gigabyte GN-WB01GSUSB
Gigabyte GN-WI05GSUSB
Hawking HWUG1USB
Hawking HWU54DMUSB
Hercules HWGUSB2-54-LBUSB
Hercules HWGUSB2-54V2-APUSB
LevelOne WNC-0301USB v3USB
Linksys WUSB54G rev CUSB
Linksys WUSB54GRUSB
Planex GW-US54HPUSB
Planex GW-US54Mini2USB
Planex GW-USMMUSB
Senao NUB-3701USB
Sitecom WL-113 ver 2USB
Sitecom WL-172USB
Sweex LW053USB
TP-LINK TL-WN321G v1/v2/v3USB
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev rum0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev rum0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev rum0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev rum0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
rum%d: could not load 8051 microcode
-
An error occurred while attempting to upload the microcode to the onboard - 8051 microcontroller unit. The driver will reset the hardware. This should - not happen.
-
-
-
-

-

intro(4), netintro(4), - usb(4), wlan(4), - wlan_amrr(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - wlan_xauth(4), networking(7), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The rum driver first appeared in - OpenBSD 4.0 and FreeBSD - 7.0.

-
-
-

-

The original rum driver was written by - Niall O'Higgins - <niallo@openbsd.org> - and Damien Bergamini - <damien@openbsd.org>.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/run.4 3.html b/static/freebsd/man4/run.4 3.html deleted file mode 100644 index 3d23fe58..00000000 --- a/static/freebsd/man4/run.4 3.html +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - -
RUN(4)Device Drivers ManualRUN(4)
-
-
-

-

run — Ralink - Technology USB IEEE 802.11a/g/n wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device run -
-device wlan -
-device wlan_amrr
-

Firmware is also needed, and provided by:

-
device runfw
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_run_load="YES"
-runfw_load="YES"
-
-
-
-

-

The run driver supports USB 2.0 wireless - adapters based on the Ralink RT2700U, RT2800U, RT3000U and RT3900E - chipsets.

-

The RT2700U chipset consists of two integrated chips, an RT2770 - MAC/BBP and an RT2720 (1T2R) or RT2750 (dual-band 1T2R) radio - transceiver.

-

The RT2800U chipset consists of two integrated chips, an RT2870 - MAC/BBP and an RT2820 (2T3R) or RT2850 (dual-band 2T3R) radio - transceiver.

-

The RT3000U is a single-chip solution based on an RT3070 MAC/BBP - and an RT3020 (1T1R), RT3021 (1T2R) or RT3022 (2T2R) single-band radio - transceiver.

-

The RT3900E is a single-chip USB 2.0 802.11n solution. The - MAC/Baseband Processor can be an RT3593, RT5390, RT5392 or an RT5592. The - radio can be an RT3053, RT5370, RT5372 or an RT5572. The RT3053 chip - operates in the 2GHz and 5GHz spectra and supports up to 3 transmit paths - and 3 receiver paths (3T3R). The RT5370 chip operates in the 2GHz spectrum - and supports 1 transmit path and 1 receiver path (1T1R). The RT5372 chip - operates in the 2GHz spectrum and supports up to 2 transmit paths and 2 - receiver paths (2T2R). The RT5572 chip operates in the 2GHz and 5GHz spectra - and supports up to 2 transmit paths and 2 receiver paths (2T2R).

-

These are the modes the run driver can - operate in:

-
-
BSS mode
-
Also known as - - mode, this is used when associating with an access point, through which - all traffic passes. This mode is the default.
-
Host AP mode
-
In this mode the driver acts as an access point (base station) for other - cards.
-
monitor mode
-
In this mode the driver is able to receive packets without associating - with an access point. This disables the internal receive filter and - enables the card to capture packets from networks which it wouldn't - normally have access to, or to scan for access points.
-
-

The run driver can be configured to use - Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and - WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It - is strongly recommended that WEP not be used as the sole mechanism to secure - wireless communication, due to serious weaknesses in it. The - run driver offloads both encryption and decryption - of data frames to the hardware for the WEP40, WEP104, TKIP(+MIC) and CCMP - ciphers.

-

The run driver can be configured at - runtime with ifconfig(8).

-
-
-

-

The run driver supports the following - wireless adapters:

-

-
    -
  • Airlink101 AWLL6090
    • -
  • ASUS USB-N11
    • -
  • ASUS USB-N13 ver. A1
    • -
  • ASUS USB-N14
    • -
  • ASUS USB-N66
    • -
  • ASUS WL-160N
    • -
  • Belkin F5D8051 ver 3000
    • -
  • Belkin F5D8053
    • -
  • Belkin F5D8055
    • -
  • Belkin F6D4050 ver 1
    • -
  • Belkin F9L1103
    • -
  • Buffalo WLI-UC-AG300N
    • -
  • Buffalo WLI-UC-G300HP
    • -
  • Buffalo WLI-UC-G300N
    • -
  • Buffalo WLI-UC-G301N
    • -
  • Buffalo WLI-UC-GN
    • -
  • Buffalo WLI-UC-GNM
    • -
  • Buffalo WLI-UC-GNM2
    • -
  • Corega CG-WLUSB2GNL
    • -
  • Corega CG-WLUSB2GNR
    • -
  • Corega CG-WLUSB300AGN
    • -
  • Corega CG-WLUSB300GNM
    • -
  • D-Link DWA-130 rev B1
    • -
  • D-Link DWA-130 rev F1
    • -
  • D-Link DWA-140 rev B1, B2, B3, D1
    • -
  • D-Link DWA-160 rev B2
    • -
  • D-Link DWA-162
    • -
  • DrayTek Vigor N61
    • -
  • Edimax EW-7711UAn
    • -
  • Edimax EW-7711UTn
    • -
  • Edimax EW-7717Un
    • -
  • Edimax EW-7718Un
    • -
  • Edimax EW-7733UnD
    • -
  • Gigabyte GN-WB30N
    • -
  • Gigabyte GN-WB31N
    • -
  • Gigabyte GN-WB32L
    • -
  • Hawking HWDN1
    • -
  • Hawking HWUN1
    • -
  • Hawking HWUN2
    • -
  • Hercules HWNU-300
    • -
  • Linksys WUSB54GC v3
    • -
  • Linksys WUSB600N
    • -
  • Logitec LAN-W150N/U2
    • -
  • Mvix Nubbin MS-811N
    • -
  • Panda Wireless PAU06
    • -
  • Planex GW-USMicroN
    • -
  • Planex GW-US300MiniS
    • -
  • Sitecom WL-182
    • -
  • Sitecom WL-188
    • -
  • Sitecom WL-301
    • -
  • Sitecom WL-302
    • -
  • Sitecom WL-315
    • -
  • Sitecom WL-364
    • -
  • SMC SMCWUSBS-N2
    • -
  • Sweex LW303
    • -
  • Sweex LW313
    • -
  • TP-LINK TL-WDN3200
    • -
  • TP-LINK TL-WN321G v4
    • -
  • TP-LINK TL-WN727N v3
    • -
  • Unex DNUR-81
    • -
  • Unex DNUR-82
    • -
  • ZyXEL NWD2705
    • -
  • ZyXEL NWD210N
    • -
  • ZyXEL NWD270N
    • -
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev run0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev run0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev run0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev run0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
run%d: failed load firmware of file runfw
-
For some reason, the driver was unable to read the microcode file from the - filesystem. The file might be missing or corrupted.
-
run%d: could not load 8051 microcode
-
An error occurred while attempting to upload the microcode to the onboard - 8051 microcontroller unit.
-
run%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
-
-
-

-

intro(4), netintro(4), - runfw(4), usb(4), - wlan(4), wlan_amrr(4), - wlan_ccmp(4), wlan_tkip(4), - wlan_wep(4), wlan_xauth(4), - networking(7), hostapd(8), - ifconfig(8), wpa_supplicant(8)

-
-
-

-

The run driver first appeared in - OpenBSD 4.5.

-
-
-

-

The run driver was written by - Damien Bergamini - <damien@openbsd.org>.

-
-
-

-

The run driver supports some of the 11n - capabilities found in the RT2800, RT3000 and RT3900 chipsets.

-
-
- - - - - -
April 1, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/runfw.4 4.html b/static/freebsd/man4/runfw.4 4.html deleted file mode 100644 index b8d7d2e2..00000000 --- a/static/freebsd/man4/runfw.4 4.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - -
RUNFW(4)Device Drivers ManualRUNFW(4)
-
-
-

-

runfw — Firmware - Module for Ralink driver

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device runfw
-

This will include two firmware images, RT2870 and RT3071, inside - the kernel. run(4) will load the appropriate image into - the chip.

-

Alternatively, to load the firmware images as a module at boot - time, place the following line in loader.conf(5):

-
-
runfw_load="YES"
-
-
-
-

-

This module provides firmware sets for the Ralink RT2700U, - RT2800U, RT3000U and RT3900E chip based USB WiFi adapters. Please read - Ralink's license, src/sys/contrib/dev/run/LICENSE.

-
-
-

-

run(4), firmware(9)

-
-
- - - - - -
November 11, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/sa.4 3.html b/static/freebsd/man4/sa.4 3.html deleted file mode 100644 index 326ad744..00000000 --- a/static/freebsd/man4/sa.4 3.html +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - -
SA(4)Device Drivers ManualSA(4)
-
-
-

-

sa — SCSI - Sequential Access device driver

-
-
-

-

device sa

-
-
-

-

The sa driver provides support for all - SCSI devices of the sequential access class that are attached to the system - through a supported SCSI Host Adapter. The sequential access class includes - tape and other linear access devices.

-

A SCSI Host adapter must also be separately configured into the - system before a SCSI sequential access device can be configured.

-
-
-

-

The sa driver is based around the concept - of a - “”, which is defined as the period between the time - that a tape is mounted, and the time when it is unmounted. Any parameters - set during a mount session remain in effect for the remainder of the session - or until replaced. The tape can be unmounted, bringing the session to a - close in several ways. These include:

-
    -
  1. Closing a `rewind device', referred to as sub-mode 00 below. An example is - /dev/sa0.
    2. -
  2. Using the MTOFFL ioctl(2) command, reachable through the - ‘offline’ command of - mt(1).
    3. -
-

It should be noted that tape devices are exclusive open devices, - except in the case where a control mode device is opened. In the latter - case, exclusive access is only sought when needed (e.g., to set - parameters).

-
-
-

-

The sub-modes differ in the action taken when the device is - closed:

-
-
/dev/sa*
-
A close will rewind the device; if the tape has been written, then a file - mark will be written before the rewind is requested. The device is - unmounted.
-
/dev/nsa*
-
A close will leave the tape mounted. If the tape was written to, a file - mark will be written. No other head positioning takes place. Any further - reads or writes will occur directly after the last read, or the written - file mark.
-
/dev/esa*
-
A close will rewind the device. If the tape has been written, then a file - mark will be written before the rewind is requested. On completion of the - rewind an unload command will be issued. The device is unmounted.
-
-
-
-

-

SCSI tapes may run in either - ‘’ - or - ‘’ - block-size modes. Most QIC-type devices run in fixed block-size mode, where - most nine-track tapes and many new cartridge formats allow variable - block-size. The difference between the two is as follows:

-
-
Variable block-size:
-
Each write made to the device results in a single logical record written - to the tape. One can never read or write - of a record - from tape (though you may request a larger block and read a smaller - record); nor can one read multiple blocks. Data from a single write is - therefore read by a single read. The block size used may be any value - supported by the device, the SCSI adapter and the system (usually between - 1 byte and 64 Kbytes, sometimes more). -

When reading a variable record/block from the tape, the head - is logically considered to be immediately after the last item read, and - before the next item after that. If the next item is a file mark, but it - was never read, then the next process to read will immediately hit the - file mark and receive an end-of-file notification.

-
-
Fixed block-size:
-
Data written by the user is passed to the tape as a succession of fixed - size blocks. It may be contiguous in memory, but it is considered to be a - series of independent blocks. One may never write an amount of data that - is not an exact multiple of the blocksize. One may read and write the same - data as a different set of records. In other words, blocks that were - written together may be read separately, and vice-versa. -

If one requests more blocks than remain in the file, the drive - will encounter the file mark. As there is some data to return (unless - there were no records before the file mark), the read will succeed, - returning that data. The next read will return immediately with a value - of 0. (As above, if the file mark is never read, it remains for the next - process to read if in no-rewind mode.)

-
-
-
-
-

-

By default, the driver will NOT accept reads or writes to a tape - device that are larger than may be written to or read from the mounted tape - using a single write or read request. Because of this, the application - author may have confidence that his wishes are respected in terms of the - block size written to tape. For example, if the user tries to write a 256KB - block to the tape, but the controller can handle no more than 128KB, the - write will fail. The previous FreeBSD behavior, - prior to FreeBSD 10.0, was to break up large reads - or writes into smaller blocks when going to the tape. The problem with that - behavior, though, is that it hides the actual on-tape block size from the - application writer, at least in variable block mode.

-

If the user would like his large reads and writes broken up into - separate pieces, he may set the following loader tunables. Note that these - tunables WILL GO AWAY in FreeBSD 11.0. They are - provided for transition purposes only.

-
-
kern.cam.sa.allow_io_split
-
-

This variable, when set to 1, will configure all - sa devices to split large buffers into smaller - pieces when needed.

-
-
kern.cam.sa.%d.allow_io_split
-
-

This variable, when set to 1, will configure the given - sa unit to split large buffers into multiple - pieces. This will override the global setting, if it exists.

-
-
-

There are several sysctl(8) variables available - to view block handling parameters:

-
-
kern.cam.sa.%d.allow_io_split
-
-

This variable allows the user to see, but not modify, the - current I/O split setting. The user is not permitted to modify this - setting so that there is no chance of behavior changing for the - application while a tape is mounted.

-
-
kern.cam.sa.%d.maxio
-
-

This variable shows the maximum I/O size in bytes that is - allowed by the combination of kernel tuning parameters (MAXPHYS, - DFLTPHYS) and the capabilities of the controller that is attached to the - tape drive. Applications may look at this value for a guide on how large - an I/O may be permitted, but should keep in mind that the actual maximum - may be restricted further by the tape drive via the SCSI READ BLOCK - LIMITS command.

-
-
kern.cam.sa.%d.cpi_maxio
-
-

This variable shows the maximum I/O size supported by the - controller, in bytes, that is reported via the CAM Path Inquiry CCB - (XPT_PATH_INQ). If this is 0, that means that the controller has not - reported a maximum I/O size.

-
-
-
-
-

-

The handling of file marks on write is automatic. If the user has - written to the tape, and has not done a read since the last write, then a - file mark will be written to the tape when the device is closed. If a rewind - is requested after a write, then the driver assumes that the last file on - the tape has been written, and ensures that there are two file marks written - to the tape. The exception to this is that there seems to be a standard - (which we follow, but do not understand why) that certain types of tape do - not actually write two file marks to tape, but when read, report a `phantom' - file mark when the last file is read. These devices include the QIC family - of devices. (It might be that this set of devices is the same set as that of - fixed block devices. This has not been determined yet, and they are treated - as separate behaviors by the driver at this time.)

-
-
-

-

The sa driver supports a number of - parameters. The user can query parameters using “mt param -l” - (which uses the MTIOCPARAMGET ioctl) and the user - can set parameters using “mt param -s” (which uses the - MTIOCPARAMSET ioctl). See mt(1) - and mtio(4) for more details on the interface.

-

Supported parameters:

-
-
sili
-
The default is 0. When set to 1, it sets the Suppress Incorrect Length - Indicator (SILI) bit on tape reads. Tape drives normally return sense data - (which contains the residual) when the application reads a block that is - not the same length as the amount of data requested. The SILI bit - suppresses that notification in most cases. See the SSC-5 spec (available - at t10.org), specifically the section on the READ(6) command, for more - information.
-
eot_warn
-
The default is 0. By default, the sa driver - reports entering Programmable Early Warning, Early Warning and End of - Media conditions by returning a write with 0 bytes written, and - errno set to 0. If eot_warn - is set to 1, the sa driver will set - errno to ENOSPC when it - enters any of the out of space conditions.
-
protection.protection_supported
-
This is a read-only parameter, and is set to 1 if the tape drive supports - protection information.
-
protection.prot_method
-
If protection is supported, set this to the desired protection method - supported by the tape drive. As of SSC-5r03 (available at t10.org), the - protection method values are: -
-
0
-
No protection.
-
1
-
Reed-Solomon CRC, 4 bytes in length.
-
2
-
CRC32C, 4 bytes in length.
-
-
-
protection.pi_length
-
Length of the protection information, see above for lengths.
-
protection.lbp_w
-
If set to 1, enable logical block protection on writes. The CRC must be - appended to the end of the block written to the tape driver. The tape - drive will verify the CRC when it receives the block.
-
protection.lbp_r
-
If set to 1, enable logical block protection on reads. The CRC will be - appended to the end of the block read from the tape driver. The - application should verify the CRC when it receives the block.
-
protection.rdbp
-
If set to 1, enable logical block protection on the RECOVER BUFFERED DATA - command. The sa driver does not currently use the - RECOVER BUFFERED DATA command.
-
-
-
-

-

The sa driver has a set of default - timeouts for SCSI commands (READ, WRITE, TEST UNIT READY, etc.) that will - likely work in most cases for many tape drives.

-

For newer tape drives that claim to support the SPC-4 standard - (SCSI Primary Commands 4) or later standards, the sa - driver will attempt to use the REPORT SUPPORTED OPERATION CODES command to - fetch timeout descriptors from the drive. If the drive does report timeout - descriptors, the sa driver will use the drive's - recommended timeouts for commands.

-

The timeouts in use are reported in units of - thousandths of a second via the - kern.cam.sa.%d.timeout.* sysctl(8) - variables.

-

To override either the default timeouts, or the timeouts - recommended by the drive, you can set one of two sets of loader tunable - values. If you have a drive that supports the REPORT SUPPORTED OPERATION - CODES timeout descriptors (see the camcontrol(8) - opcodes subcommand) it is generally best to use those - values. The global kern.cam.sa.timeout.* values will - override the timeouts for all sa driver instances. - If there are 5 tape drives in the system, they'll all get the same timeouts. - The kern.cam.sa.%d.timeout.* values (where %d is the - numeric sa instance number) will override the global - timeouts as well as either the default timeouts or the timeouts recommended - by the drive.

-

To set timeouts after boot, the per-instance timeout values, for - example: kern.cam.sa.0.timeout.read, are available as - sysctl variables.

-

If a tape drive arrives after boot, the global tunables or - per-instance tunables that apply to the newly arrived drive will be - used.

-

Loader tunables:

-

-
-
kern.cam.sa.timeout.erase
-
 
-
kern.cam.sa.timeout.locate
-
 
-
kern.cam.sa.timeout.mode_select
-
 
-
kern.cam.sa.timeout.mode_sense
-
 
-
kern.cam.sa.timeout.prevent
-
 
-
kern.cam.sa.timeout.read
-
 
-
kern.cam.sa.timeout.read_position
-
 
-
kern.cam.sa.timeout.read_block_limits
-
 
-
kern.cam.sa.timeout.report_density
-
 
-
kern.cam.sa.timeout.reserve
-
 
-
kern.cam.sa.timeout.rewind
-
 
-
kern.cam.sa.timeout.space
-
 
-
kern.cam.sa.timeout.tur
-
 
-
kern.cam.sa.timeout.write
-
 
-
kern.cam.sa.timeout.write_filemarks
-
 
-
-

Loader tunable values and sysctl(8) values:

-

-
-
kern.cam.sa.%d.timeout.erase
-
 
-
kern.cam.sa.%d.timeout.locate
-
 
-
kern.cam.sa.%d.timeout.mode_select
-
 
-
kern.cam.sa.%d.timeout.mode_sense
-
 
-
kern.cam.sa.%d.timeout.prevent
-
 
-
kern.cam.sa.%d.timeout.read
-
 
-
kern.cam.sa.%d.timeout.read_position
-
 
-
kern.cam.sa.%d.timeout.read_block_limits
-
 
-
kern.cam.sa.%d.timeout.report_density
-
 
-
kern.cam.sa.%d.timeout.reserve
-
 
-
kern.cam.sa.%d.timeout.rewind
-
 
-
kern.cam.sa.%d.timeout.space
-
 
-
kern.cam.sa.%d.timeout.tur
-
 
-
kern.cam.sa.%d.timeout.write
-
 
-
kern.cam.sa.%d.timeout.write_filemarks
-
 
-
-

As mentioned above, the timeouts are set and reported in - thousandths of a second, so be sure to account for that - when setting them.

-
-
-

-

The sa driver supports all of the ioctls - of mtio(4).

-
-
-

-
-
/dev/[n][e]sa[0-9]
-
general form:
-
/dev/sa0
-
Rewind on close
-
/dev/nsa0
-
No rewind on close
-
/dev/esa0
-
Eject on close (if capable)
-
/dev/sa0.ctl
-
Control mode device (to examine state while another program is accessing - the device, e.g.).
-
-
-
-

-

The sa driver supports injecting End Of - Media (EOM) notification to aid application development and testing. EOM is - indicated to the application by returning the read or write with 0 bytes - written. In addition, when EOM is injected, the tape position status will be - updated to temporarily show Beyond of the Programmable Early Warning (BPEW) - status. To see BPEW status, use the MTIOCEXTGET - ioctl, which is used by the “mt status” command. To inject an - EOM notification, set the

-

kern.cam.sa.%d.inject_eom

-

sysctl variable to 1. One EOM notification will be sent, BPEW - status will be set for one position query, and then the driver state will be - reset to normal.

-
-
-

-

mt(1), cam(4), - mtio(4)

-
-
-

-

The sa driver was written for the CAM SCSI - subsystem by Justin T. Gibbs and - Kenneth Merry. Many ideas were gleaned from the - st device driver written and ported from Mach 2.5 by - Julian Elischer.

-

The owner of record for many years was Matthew - Jacob. The current maintainer is Kenneth - Merry

-
-
-

-

This driver lacks many of the hacks required to deal with older - devices. Many older SCSI-1 devices may not work properly with this driver - yet.

-

Additionally, certain tapes (QIC tapes mostly) that were written - under FreeBSD 2.X are not automatically read - correctly with this driver: you may need to explicitly set variable block - mode or set to the blocksize that works best for your device in order to - read tapes written under FreeBSD 2.X.

-

Partitions are only supported for status information and location. - It would be nice to add support for creating and editing tape - partitions.

-
-
- - - - - -
January 18, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/safe.4 3.html b/static/freebsd/man4/safe.4 3.html deleted file mode 100644 index 914126c8..00000000 --- a/static/freebsd/man4/safe.4 3.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - -
SAFE(4)Device Drivers ManualSAFE(4)
-
-
-

-

safe — SafeNet - SafeXcel 1141/1741 crypto accelerator

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device cryptodev -
-device safe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
safe_load="YES"
-
-

In sysctl.conf(5):

-
hw.safe.debug -
-hw.safe.dump -
-hw.safe.rnginterval -
-hw.safe.rngbufsize -
-hw.safe.rngmaxalarm
-
-
-

-

The safe driver is deprecated and is - scheduled for removal in FreeBSD 16.0.

-
-
-

-

The safe driver supports cards containing - SafeNet crypto accelerator chips.

-

The safe driver registers itself to - accelerate AES, SHA1-HMAC, and NULL operations for - ipsec(4) and crypto(4).

-

On all models, the driver registers itself to provide random data - to the random(4) subsystem. Periodically the driver will - poll the hardware RNG and retrieve data for use by the system. If the driver - detects that the hardware RNG is resonating with any local signal, it will - reset the oscillators that generate random data. Three - sysctl(8) settings control this procedure: - hw.safe.rnginterval specifies the time, in seconds, - between polling operations, hw.safe.rngbufsize - specifies the number of 32-bit words to retrieve on each poll, and - hw.safe.rngmaxalarm specifies the threshold for - resetting the oscillators.

-

When the driver is compiled with - SAFE_DEBUG defined, two sysctl(8) - variables are provided for debugging purposes: - hw.safe.debug can be set to a non-zero value to enable - debugging messages to be sent to the console for each cryptographic - operation, hw.safe.dump is a write-only variable that - can be used to force driver state to be sent to the console. Set this - variable to “ring” to dump the current - state of the descriptor ring, to “dma” - to dump the hardware DMA registers, or to - “int” to dump the hardware interrupt - registers.

-
-
-

-

The safe driver supports the following - SafeXcel chips:

- - - - - - - - - -
SafeNet 1141The original chipset. Supports DES, Triple-DES, AES, MD5, and SHA-1 - symmetric crypto operations, RNG, public key operations, and full IPsec - packet processing.
SafeNet 1741A faster version of the 1141.
-
-
-

-

crypt(3), crypto(4), - intro(4), ipsec(4), - random(4), crypto(7), - crypto(9)

-
-
-

-

The safe driver first appeared in - FreeBSD 5.2. It is deprecated in - FreeBSD 15.0 and removed in FreeBSD - 16.0.

-
-
-

-

Public key support is not implemented.

-
-
- - - - - -
October 31, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/safexcel.4 4.html b/static/freebsd/man4/safexcel.4 4.html deleted file mode 100644 index ba00008b..00000000 --- a/static/freebsd/man4/safexcel.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
SAFEXCEL(4)Device Drivers ManualSAFEXCEL(4)
-
-
-

-

safexcel — Inside - Secure SafeXcel-IP-97 cryptographic offload engine

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device crypto -
-device cryptodev -
-device safexcel
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
safexcel_load="YES"
-
-
-
-

-

The safexcel driver implements - crypto(4) support for the cryptographic acceleration - functions of the EIP-97 device found on some Marvell systems-on-chip. The - driver can accelerate the following AES modes:

-

-
    -
  • AES-CBC
    • -
  • AES-CTR
    • -
  • AES-XTS
    • -
  • AES-GCM
    • -
  • AES-CCM
    • -
-

safexcel also implements SHA1 and SHA2 - transforms, and can combine AES-CBC and AES-CTR with SHA1-HMAC and SHA2-HMAC - for encrypt-then-authenticate operations.

-
-
-

-

The safexcel driver supports the - cryptographic acceleration functions of the Inside Secure EIP-97 device - found on some Marvell systems-on-chip.

-
-
-

-

crypto(4), ipsec(4), - random(4), crypto(7), - geli(8), crypto(9)

-
-
-

-

The safexcel driver first appeared in - FreeBSD 13.0.

-
-
- - - - - -
November 22, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/sbp.4 3.html b/static/freebsd/man4/sbp.4 3.html deleted file mode 100644 index 0e6c5f28..00000000 --- a/static/freebsd/man4/sbp.4 3.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
SBP(4)Device Drivers ManualSBP(4)
-
-
-

-

sbp — Serial Bus - Protocol 2 (SBP-2) Mass Storage Devices driver

-
-
-

-

kldload firewire -
- kldload cam -
- kldload sbp

-

or

-

-
- device sbp -
- device firewire -
- device scbus -
- device da -
- device cd -
- device pass

-
-
-

-

The sbp driver provides support for SBP-2 - devices that attach to the FireWire (IEEE 1394) port. It should work with - SBP-2 devices which the CAM layer supports, for example, HDDs, CDROM drives - and DVD drives.

-

Some users familiar with umass(4) might wonder - why the device is not detached at the CAM layer when the device is - unplugged. It is detached only if the device has not been plugged again - during several bus resets. This is for preventing to detach an active file - system even when the device cannot be probed correctly for some reason after - a bus reset or when the device is temporary disconnected because the user - changes the bus topology. If you want to force to detach the device, run - ‘fwcontrol -r’ several times or set - hw.firewire.hold_count=0 by - sysctl(8).

-

Some (broken) HDDs do not work well with tagged queuing. If you - have problems with such drives, try ‘camcontrol - [device id] tags -N 1’ to disable tagged queuing.

-
-
-

-

The sbp driver supports FireWire Serial - Bus Protocol 2 (SBP-2) storage devices.

-
-
-

-

cam(4), firewire(4), - camcontrol(8), fwcontrol(8), - kldload(8), sysctl(8)

-
-
-

-

The sbp driver was written by - Katsushi Kobayashi and Hidetoshi - Shimokawa.

-

This manual page was written by Katsushi - Kobayashi.

-
-
- - - - - -
November 11, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/sbp_targ.4 4.html b/static/freebsd/man4/sbp_targ.4 4.html deleted file mode 100644 index 2e89a44b..00000000 --- a/static/freebsd/man4/sbp_targ.4 4.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
SBP_TARG(4)Device Drivers ManualSBP_TARG(4)
-
-
-

-

sbp_targ — Serial - Bus Protocol 2 (SBP-2) Target Mode devices driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sbp_targ -
-device firewire -
-device scbus -
-device targ
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
firewire_load="YES"
-cam_load="YES"
-sbp_targ_load"YES"
-
-
-
-

-

The sbp_targ driver provides support for - SBP-2 target mode. This driver is supposed to work with - cam(4), targ(4) and - firewire(4). You also need to use - scsi_target(8), which can be found in - /usr/share/examples/scsi_target, to provide actual - devices.

-
-
-

-
-
# mdconfig -a -t malloc -s 10m
-md0
-# scsi_target 0:0:0 /dev/md0
-(Assuming sbp_targ0 on scbus0)
-
-
-
-

-

cam(4), firewire(4), - targ(4), camcontrol(8), - fwcontrol(8), kldload(8), - scsi_target(8)

-
-
-

-

The sbp_targ driver was written by - Hidetoshi Shimokawa.

-
-
-

-

This driver is currently under development. It does not work - correctly in multi-initiator environments or after the bus topology has been - changed.

-
-
- - - - - -
November 7, 2003FreeBSD 15.0
diff --git a/static/freebsd/man4/scc.4 4.html b/static/freebsd/man4/scc.4 4.html deleted file mode 100644 index fe7c3577..00000000 --- a/static/freebsd/man4/scc.4 4.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - -
SCC(4)Device Drivers ManualSCC(4)
-
-
-

-

scc — Serial - Communications Controller driver

-
-
-

-

device scc -
- device uart

-
-
-

-

The scc device driver provides support for - various classes of SCCs. It is an umbrella driver that delegates control of - each independent communication channel to subordinate drivers. These - subordinate drivers, like uart(4), take care of the - details of the communication itself.

-
-
-

-

The scc driver supports the following - classes of Serial Communications Controllers:

-

-
    -
  • QUICC: Freescale/NXP QUad Integrated Communications Controllers.
    • -
  • Z8530: Zilog 8530 based serial communications controllers.
    • -
-
-
-

-

puc(4), uart(4)

-
-
-

-

The scc device driver first appeared in - FreeBSD 7.0.

-
-
-

-

The scc driver and this manual page were - written by Marcel Moolenaar - <marcel@xcllnt.net>.

-
-
- - - - - -
May 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/sched_4bsd.4 3.html b/static/freebsd/man4/sched_4bsd.4 3.html deleted file mode 100644 index 6ed98a79..00000000 --- a/static/freebsd/man4/sched_4bsd.4 3.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
SCHED_4BSD(4)Device Drivers ManualSCHED_4BSD(4)
-
-
-

-

sched_4bsd — - 4.4BSD scheduler

-
-
-

-

options SCHED_4BSD

-
-
-

-

The sched_4bsd scheduler is the - traditional system scheduler, providing both high throughput and solid - interactive response in the presence of load.

-

The following sysctls are relevant to the operation of - sched_4bsd:

-
-
kern.sched.name
-
This read-only sysctl reports the name of the active scheduler.
-
kern.sched.quantum
-
This read-write sysctl reports or sets the length of the quantum (in - micro-seconds) granted to a thread.
-
kern.sched.ipiwakeup.enabled
-
This read-write sysctl sets whether or not the scheduler will generate an - inter-processor interrupt (IPI) to an idle CPU when a thread is woken up. - Otherwise, idle CPUs will wait until the next clock tick before looking - for new work.
-
kern.sched.preemption
-
This read-only sysctl reports whether or not the kernel is configured to - support preemption, which reduces the latency to run lower priority - threads on wakeup.
-
-

Some sysctls will be available only on systems supporting SMP.

-
-
-

-

sched_ule(4), sysctl(8)

-
-
-

-

The sched_4bsd scheduler has been present, - in various forms, since the inception of BSD.

-
-
-

-

While a highly robust and time-tested scheduler, - sched_4bsd lacks specific knowledge of how to - schedule advantageously in non-symmetric processor configurations, such as - hyper-threading.

-
-
- - - - - -
January 21, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/sched_ule.4 4.html b/static/freebsd/man4/sched_ule.4 4.html deleted file mode 100644 index c9cd9cf0..00000000 --- a/static/freebsd/man4/sched_ule.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
SCHED_ULE(4)Device Drivers ManualSCHED_ULE(4)
-
-
-

-

sched_ule — ULE - scheduler

-
-
-

-

options SCHED_ULE

-
-
-

-

The sched_ule scheduler provides a number - of advanced scheduler features not present in - sched_4bsd(4), the traditional system scheduler. These - features address SMP and interactivity and include:

-

-
    -
  • Thread CPU affinity.
    • -
  • CPU topology awareness, including for hyper-threading.
    • -
  • Per-CPU run queues.
    • -
  • Interactivity heuristics that detect interactive applications and - schedules them preferentially under high load.
    • -
-

The following sysctls are relevant to the operation of - sched_ule:

-
-
kern.sched.name
-
This read-only sysctl reports the name of the active scheduler.
-
kern.sched.quantum
-
This read-write sysctl reports or sets the length of the quantum (in - micro-seconds) granted to a thread.
-
-
-
-

-

sched_4bsd(4), sysctl(8)

-
-
-

-

The sched_ule scheduler first appeared in - FreeBSD 5.1.

-
-
-

-

Jeff Roberson - <jeff@FreeBSD.org>

-
-
- - - - - -
August 10, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/screen.4 3.html b/static/freebsd/man4/screen.4 3.html deleted file mode 100644 index 6314e91e..00000000 --- a/static/freebsd/man4/screen.4 3.html +++ /dev/null @@ -1,238 +0,0 @@ - - - - - - -
SCREEN(4)Device Drivers ManualSCREEN(4)
-
-
-

-

screen — pc - display interface

-
-
-

-

Access to the - are obtained through the device files - /dev/ttyv0 - /dev/ttyvb. - Each of these files correspond to a separate virtual console. All virtual - console devices can be open at once, but only one is active at a time. The - active virtual console "owns" the keyboard and display screen.

-

Output to a virtual console that not currently is on the display - is saved in a buffer that holds a "screenfull" (normally 25) - lines. Any output written to /dev/console (the - original console device) is echoed to - /dev/ttyv0.

-

To switch between the virtual consoles one uses the - sequence , - which means hold down ALT and press one of the function keys. The virtual - console with the same number as the function key is then selected as the - current virtual console, and given exclusive use of the keyboard and - display. This switch sequence can be changed via the keyboard mapping ioctl - call (see keyboard(4)).

-

The console allows entering values that are not physically present - on the keyboard via a special keysequence. To use this facility press and - hold down ALT, then enter a decimal number from 0-255 via the numerical - keypad, then release ALT. The entered value is then used as the ASCII value - for one character. This way it is possible to enter any ASCII value. The - console driver also includes a history function. It is activated by pressing - the scroll-lock key. This holds the display, and enables the cursor arrows - for scrolling up and down through the last scrolled out lines.

-

The console understands a subset of the ANSI x3.64 character - sequences. For compatibility with the old pccons, the PC3 character - sequences are also supported.

-
-
ANSI	Seq	Function				Termcap entry
-======= ======= =====================================   ==============
-
---	E7	Save cursor position			sc
-
---	E8	Restore	saved cursor position		rc
-
---	Ec	Reset					rs
-
---	EM	move cursor up 1 line,			--
-		scroll if at top
-
-CUU     E[nA    move cursor up n lines                  up/UP (ku)
-
-CUD     E[nB    move cursor down n lines                do/DO (kd)
-
-CUF     E[nC    move cursor right n characters          nd/RI (kr)
-
-CUB     E[nD    move cursor left n characters           --/LE (kl)
-
-HPA     E[n`    move cursor to character position n     ch
-
-HPR	E[na	move cursor right n characters 		--
-
-VPA     E[nd    move cursor to line n                   cv
-
-VPR	E[ne	move cursor down n lines		--
-
-CPL     E[nF    move cursor to start of line,           -- (@7)
-		n lines up
-
-CNL     E[nE    move cursor to start of line,           nw
-		n lines down
-
-CUP	E[y;xH	Move cursor to x, y			cm
-
-HVP	E[y;xf	Move cursor to x, y			--
-
-CBT     E[nZ    Move cursor back n tab stops            bt (kB)
-
-IL      E[nL    Insert n blank lines                    al/AL
-
-ICH     E[n@    Insert n blank characters               ic/IC
-
-DL      E[nM    Delete n lines                          dl/DL
-
-DCH     E[nP    Delete n characters                     dc/DC
-
-ED	E[nJ	Erase part or all of display:		cd
-		n=0 from cursor to end of display,
-		n=1 from begin of display to cursor,
-		n=2 entire display.
-
-EL	E[nK	Erase part or all of line:		ce
-		n=0 from cursor to end of line,
-		n=1 from begin of line to cursor,
-		n=2 entire line.
-
-ECH     E[nX    Erase n characters                      ec
-
-SU      E[nS    Scroll display n lines up (forward)     sf/SF
-
-SD      E[nT    Scroll display n lines down (reverse)   sr/SR
-
-
-SGR	E[nm	Set character attributes:		--
-		n= 0  normal attribute (all off)
-		n= 1  bold (highlight)
-		n= 4  underscore (if supported by HW)
-		n= 5  blink (if supported by HW)
-		n= 7  reverse
-		n= 22 remove bold
-		n= 24 remove underscore
-		n= 25 remove blink
-		n= 27 remove reverse
-		n= 3X set ANSI foreground color
-		      (see table)
-		n= 4X set ANSI background color
-		      (see table)
-
-		   X=0 black 	X=1 red
-		   X=2 green	X=3 brown
-		   X=4 blue	X=5 magenta
-		   X=6 cyan	X=7 light grey
-		   X=9 reset to the normal color
-
---	E[s	Save cursor position			sc
-
---	E[u	Restore	saved cursor position		rc
-
---      E[x     Reset normal colors and attributes      --
-		to their default values
-
---	E[nz	Switch to virtual console n		--
-
---      E[1;nx  Set normal ANSI background color        --
-		to n (see table)
-
---      E[2;nx  Set normal ANSI foreground color        --
-		to n (see table)
-
---      E[3;nx  Set normal video attribute directly     --
-		to n (n	from 0 to 255)
-
---      E[5;nx  Set normal ANSI reverse background      --
-		color to n (see	table)
-
---      E[6;nx  Set normal ANSI reverse foreground      --
-		color to n (see	table)
-
-		   n= 0	black	   n= 8	dark grey
-		   n= 1	red	   n= 9	light red
-		   n= 2	green	   n=10	light green
-		   n= 3	brown	   n=11	yellow
-		   n= 4	blue	   n=12	light blue
-		   n= 5	magenta	   n=13	light magenta
-		   n= 6	cyan	   n=14	light cyan
-		   n= 7	light grey n=15	white
-
---      E[7;nx  Set normal reverse video attribute      --
-		directly to n (n from 0	to 255)
-
---	E[=p;dB	Set bell pitch (p) and duration (d),	--
-			pitch is in units of 840 nS,
-			duration is units of 0,1 S.
-
---	E[=tC	Set global cursor type (see table)	--
-
-		   t=0 normal non-blinking
-		   t=1 normal blinking
-		   t=2 custom non-blinking
-		   t=3 custom blinking
-		   t=4 reset cursor (resets custom
-		       cursor shape and sets current
-		       cursor type to 0)
-		   t=5 hide cursor
-
---	E[=s;eC	Set custom cursor shape, where		--
-		s is the starting and e is the ending
-		scanlines of the cursor.
-
---	E[=s;e;dC					--
-		Same as above, except d specifies the
-		direction.  If 0, scanlines are counted
-		from the top to the bottom.  If 1, from
-		the bottom to the top.
-
---	E[=tS	Set local cursor type (see table)	--
-
-		   t=0 normal (global)			ve
-		   t=1 invisible			vi
-		   t=2 very visible			vs
-
---      E[=nA   Set the border color to n               --
-		(see table) (if supported by HW)
-
---      E[=nF   Set normal foreground color to n        --
-		(see table)
-
---      E[=nG   Set normal background color to n        --
-		(see table)
-
---      E[=nH   Set normal reverse foreground color     --
-		to n (see table)
-
---      E[=nI   Set normal reverse background color     --
-		to n (see table)
-
-		   n= 0	black	   n= 8	dark grey
-		   n= 1	blue	   n= 9	light blue
-		   n= 2	green	   n=10	light green
-		   n= 3	cyan	   n=11	light cyan
-		   n= 4	red	   n=12	light red
-		   n= 5	magenta	   n=13	light magenta
-		   n= 6	brown	   n=14	yellow
-		   n= 7	light grey n=15	white
-
-note: the first E in the sequences stands for ESC (0x1b)
-
-
-
-

-

Søren Schmidt - <sos@FreeBSD.org>

-
-
- - - - - -
October 6, 2000FreeBSD 15.0
diff --git a/static/freebsd/man4/scsi.4 3.html b/static/freebsd/man4/scsi.4 3.html deleted file mode 100644 index e4f4923e..00000000 --- a/static/freebsd/man4/scsi.4 3.html +++ /dev/null @@ -1,436 +0,0 @@ - - - - - - -
CAM(4)Device Drivers ManualCAM(4)
-
-
-

-

CAM — Common - Access Method Storage subsystem

-
-
-

-

device scbus -
- device ada -
- device cd -
- device ch -
- device da -
- device pass -
- device pt -
- device sa -
- options CAMDEBUG -
- options CAM_DEBUG_BUS=-1 -
- options CAM_DEBUG_TARGET=-1 -
- options CAM_DEBUG_LUN=-1 -
- options - CAM_DEBUG_COMPILE=CAM_DEBUG_INFO|CAM_DEBUG_CDB|CAM_DEBUG_PROBE -
- options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_CDB -
- options CAM_MAX_HIGHPOWER=4 -
- options SCSI_NO_SENSE_STRINGS -
- options SCSI_NO_OP_STRINGS -
- options SCSI_DELAY=8000

-
-
-

-

The CAM subsystem provides a uniform and - modular system for the implementation of drivers to control various SCSI, - ATA, NVMe, and MMC / SD devices, and to utilize different SCSI, ATA, NVMe, - and MMC / SD host adapters through host adapter drivers. When the system - probes buses, it attaches any devices it finds to the appropriate drivers. - The pass(4) driver, if it is configured in the kernel, - will attach to all devices.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
kern.cam.cam_srch_hi
-
Search above LUN 7 for SCSI3 and greater devices.
-
kern.cam.tur_timeout
-
Timeout, in ms, for the initial TESTUNITREADY command we send to the - devices during their initial probing. Defaults to 1s. - FreeBSD 15 and earlier set this to 60s.
-
kern.cam.inquiry_timeout
-
Timeout, in ms, for the initial INQUIRY command we send to the devices - during their initial probing. Defaults to 1s. FreeBSD - 15 and earlier set this to 60s.
-
kern.cam.reportluns_timeout
-
Timeout, in ms, for the initial REPORTLUNS command we send to the devices - during their initial probing. Defaults to 50s.
-
kern.cam.max_high_power
-
The maximum number high power commands, like START UNIT, to issue at the - same time. Defaults to 4.
-
kern.cam.modesense_timeout
-
Timeout, in ms, for the initial MODESENSE command we send to the devices - during their initial probing. Defaults to 1s. FreeBSD - 15 and earlier set this to 60s.
-
-
-
-

-

There are a number of generic kernel configuration options for the - CAM subsystem:

-
-
-
Additional time to wait after the static parts of the kernel have run to - allow for discovery of additional devices which may take time to connect, - such as USB attached storage.
-
-
Enable dynamic decisions in the I/O scheduler based on hints and the - current performance of the storage devices.
-
-
Enable collection of statistics for periph devices.
-
-
Enable ability to simulate I/O failures.
-
-
This option compiles in all the CAM debugging - printf code. This will not actually cause any debugging information to be - printed out when included by itself. See below for details.
-
-
This sets the maximum allowable number of concurrent "high - power" commands. A "high power" command is a command that - takes more electrical power than most to complete. An example of this is - the SCSI START UNIT command. Starting a disk often takes significantly - more electrical power than normal operation. This option allows the user - to specify how many concurrent high power commands may be outstanding - without overloading the power supply on his computer.
-
-
This eliminates text descriptions of each SCSI Additional Sense Code and - Additional Sense Code Qualifier pair. Since this is a fairly large text - database, eliminating it reduces the size of the kernel somewhat. This is - primarily necessary for boot floppies and other low disk space or low - memory space environments. In most cases, though, this should be enabled, - since it speeds the interpretation of SCSI error messages. Do not let the - "kernel bloat" zealots get to you -- leave the sense - descriptions in your kernel!
-
-
This disables text descriptions of each SCSI opcode. This option, like the - sense string option above, is primarily useful for environments like a - boot floppy where kernel size is critical. Enabling this option for normal - use is not recommended, since it slows debugging of SCSI problems.
-
-
This is the SCSI "bus settle delay." In - CAM, it is specified in - , - not seconds like the old SCSI layer used to do. When the kernel boots, it - sends a bus reset to each SCSI bus to tell each device to reset itself to - a default set of transfer negotiations and other settings. Most SCSI - devices need some amount of time to recover from a bus reset. Newer disks - may need as little as 100ms, while old, slow devices may need much longer. - If the SCSI_DELAY is not specified, it defaults to - 2 seconds. The minimum allowable value for - SCSI_DELAY is "100", or 100ms. One - special case is that if the SCSI_DELAY is set to - 0, that will be taken to mean the "lowest possible value." In - that case, the SCSI_DELAY will be reset to - 100ms.
-
-

All devices and buses support dynamic allocation so that an upper - number of devices and controllers does not need to be configured; - device da will suffice for any number of disk - drivers.

-

The devices are either - so they - appear as a particular device unit or - - so that they appear as the next available unused unit.

-

Units are wired down by setting kernel environment hints. This is - usually done either interactively from the loader(8), or - automatically via the /boot/device.hints file. The - basic syntax is:

-
-
hint.device.unit.property="value"
-
-

Individual CAM bus numbers can be wired - down to specific controllers with a config line similar to the - following:

-
-
hint.scbus.0.at="mpr1"
-
-

This assigns CAM bus number 0 to - the driver - instance. For controllers supporting more than one bus, a particular bus can - be assigned as follows:

-
-
hint.scbus.0.at="ahci1"
-hint.scbus.0.bus="1"
-
-

This assigns CAM bus 0 to the - bus 1 instance on - . Peripheral - drivers can be wired to a specific bus, target, and lun as so:

-
-
hint.da.0.at="scbus0"
-hint.da.0.target="0"
-hint.da.0.lun="0"
-
-

This assigns - to target 0, unit - (lun) 0 of scbus 0. Omitting the target or unit hints will instruct - CAM to treat them as wildcards and use the first - respective counted instances. These examples can be combined together to - allow a peripheral device to be wired to any particular controller, bus, - target, and/or unit instance.

-

This also works with nvme(4) drives.

-
-
hint.nvme.4.at="pci7:0:0"
-hint.scbus.10.at="nvme4"
-hint.nda.10.at="scbus10"
-hint.nda.10.target="1"
-hint.nda.10.lun="12"
-hint.nda.11.at="scbus10"
-hint.nda.11.target="1"
-hint.nda.11.lun="2"
-
-

This assigns the NVMe card at PCI bus 7 slot 0 function - 1 to scbus 10. The target for nda(4) devices is always 1. - The unit is the namespace identifier from the drive. The namespace id 1 is - exported as - and namespace id 2 is exported as - .

-

For devices that provide a serial number, units may be wired to - that serial number without regard where the drive is attached:

-
-
hint.nda.3.sn="CY0AN07101120B12P"
-hint.da.44.sn="143282400011"
-hint.ada.2.sn="A065D591"
-
-wires , - , and - to - drives with the specified serial numbers. One need not specify an - line when - serial numbers are used. -
-
-

-

The system allows common device drivers to work through many - different types of adapters. The adapters take requests from the upper - layers and do all IO between the SCSI, ATA, NVMe, or MMC / SD bus and the - system. The maximum size of a transfer is governed by the adapter. Most - adapters can transfer 1MB in a single operation, however many can transfer - larger amounts.

-
-
-

-

Some adapters support - in which the system is capable of operating as a device, - responding to operations initiated by another system. Target mode is - supported for some adapters, but is not yet complete for this version of the - CAM SCSI subsystem.

-
-
-

-

The CAM subsystem glues together the upper - layers of the system to the storage devices. PERIPH devices accept storage - requests from GEOM and other upper layers of the system and translates them - into protocol requests. XPT (transport) dispatches these protocol requests - to a SIM driver. A SIM driver takes protocol requests and translates them - into hardware commands the host adapter understands to transfer the protocol - requests, and data (if any) to the storage device. The CCB transports these - requests around as messages.

-
-

-

The Common Access Method was a standard defined in the 1990s to - talk to disk drives. FreeBSD is one of the few - operating systems to fully implement this model. The interface between - different parts of CAM is the CCB (or CAM Control Block). Each CCB has a - standard header, which contains the type of request and dispatch - information, and a command specific portion. A CAM Periph generates - requests. The XPT layer dispatches these requests to the appropriate SIM. - Some CCBs are sent directly to the SIM for immediate processing, while - others are queued and complete when the I/O has finished. A SIM takes CCBs - and translates them into hardware specific commands to push the SCSI CDB or - other protocol control block to the peripheral, along with setting up the - DMA for the associated data.

-
-
-

-

A periph driver knows how to translate standard requests into - protocol messages that a SIM can deliver to hardware. These requests can - come from any upper layer source, but primarily come in via GEOM as a bio - request. They can also come in directly from character device requests for - tapes and pass through commands.

-

Disk devices, or direct access (da) in CAM, are one type of - peripheral. These devices present themselves to the kernel a device ending - in “da”. Each protocol has a unique device name:

-
-
da(4)
-
SCSI or SAS device, or devices that accept SCSI CDBs for I/O.
-
ada(4)
-
ATA or SATA device
-
nda(4)
-
NVME device
-
sdda(4)
-
An SD or MMC block storage device.
-
-

Tape devices are called serial access (sa(4)) in - CAM. They interface to the system via a character device and provide - ioctl(2) control for tape drives.

-

The pass(4) device will pass through CCB - requests from userland to the SIM directly. The device is used to send - commands other than read, write, trim or flush to a device. The - camcontrol(8) command uses this device.

-
-
-

-

The transport driver connects the periph to the SIM. It is not - configured separately. It is also responsible for device discovery for those - SIM drivers that do not enumerate themselves.

-
-
-

-

SIM used to stand for SCSI Interface Module. Now it is just SIM - because it understands protocols other than SCSI. There are two types of SIM - drivers: virtual and physical. Physical SIMs are typically called host bus - adapters (HBA), but not universally. Virtual SIM drivers are for - communicating with network or virtual machine hosts.

-
-
-
-

-

see other CAM device entries.

-
-
-

-

An XPT_DEBUG CCB can be used to enable various amounts of tracing - information on any specific bus/device from the list of options compiled - into the kernel. There are currently seven debugging flags that may be - compiled in and used:

-
-
-
This flag enables general informational printfs for the device or devices - in question.
-
-
This flag enables function-level command flow tracing i.e., kernel printfs - will happen at the entrance and exit of various functions.
-
-
This flag enables debugging output internal to various functions.
-
-
This flag will cause the kernel to print out all ATA and SCSI commands - sent to a particular device or devices.
-
-
This flag will enable command scheduler tracing.
-
-
This flag will enable peripheral drivers messages.
-
-
This flag will enable devices probe process tracing.
-
-

Some of these flags, most notably - CAM_DEBUG_TRACE and - CAM_DEBUG_SUBTRACE, will produce kernel printfs in - EXTREME numbers.

-

Users can enable debugging from their kernel config file, by using - the following kernel config options:

-
-
-
This builds into the kernel all possible CAM - debugging.
-
-
This specifies support for which debugging flags described above should be - built into the kernel. Flags may be ORed together if the user wishes to - see printfs for multiple debugging levels.
-
-
This sets the various debugging flags from a kernel config file.
-
-
Specify a bus to debug. To debug all buses, set this to -1.
-
-
Specify a target to debug. To debug all targets, set this to -1.
-
-
Specify a lun to debug. To debug all luns, set this to -1.
-
-

Users may also enable debugging on the fly by using the - camcontrol(8) utility, if wanted options built into the - kernel. See camcontrol(8) for details.

-
-
-

-
-
-
camcontrol(8), camdd(8)
-
-
cam(3)
-
-
ada(4), da(4), - nda(4), pass(4), - sa(4)
-
-
aac(4), aacraid(4), - ahc(4), ahci(4), - ata(4), aw_mmc(4), - ciss(4), hv_storvsc(4), - isci(4), iscsi(4), - isp(4), mpr(4), - mps(4), mpt(4), - mrsas(4), mvs(4), - nvme(4), pms(4), - pvscsi(4), sdhci(4), - smartpqi(4), sym(4), - tws(4), umass(4), - virtio_scsi(4)
-
-
ahd(4), amr(4), - arcmsr(4), esp(4), - hpt27xx(4), hptiop(4), - hptmv(4), hptnr(4), - iir(4) mfi(4), - sbp(4), twa(4)
-
-
-
-

-

The CAM SCSI subsystem first appeared in - FreeBSD 3.0. The CAM ATA - support was added in FreeBSD 8.0.

-
-
-

-

The CAM SCSI subsystem was written by - Justin Gibbs and Kenneth - Merry. The CAM ATA support was added by - Alexander Motin - <mav@FreeBSD.org>. The - CAM NVMe support was added by - Warner Losh - <imp@FreeBSD.org>.

-
-
- - - - - -
December 11, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/sctp.4 3.html b/static/freebsd/man4/sctp.4 3.html deleted file mode 100644 index ad1dcf06..00000000 --- a/static/freebsd/man4/sctp.4 3.html +++ /dev/null @@ -1,497 +0,0 @@ - - - - - - -
SCTP(4)Device Drivers ManualSCTP(4)
-
-
-

-

sctp — Internet - Stream Control Transmission Protocol

-
-
-

-

options SCTP -
- options SCTP_SUPPORT

-

-
- #include <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/sctp.h>

-

int -
- socket(AF_INET, - SOCK_STREAM, - IPPROTO_SCTP);

-

int -
- socket(AF_INET, - SOCK_SEQPACKET, - IPPROTO_SCTP);

-
-
-

-

The SCTP protocol provides reliable, flow-controlled, two-way - transmission of data. It is a message oriented protocol and can support the - SOCK_STREAM and - SOCK_SEQPACKET abstractions. SCTP uses the standard - Internet address format and, in addition, provides a per-host collection of - “port addresses”. Thus, each address is composed of an - Internet address specifying the host and network, with a specific SCTP port - on the host identifying the peer entity.

-

There are two models of programming in SCTP. The first uses the - SOCK_STREAM abstraction. In this abstraction sockets - utilizing the SCTP protocol are either “active” or - “passive”. Active sockets initiate connections to passive - sockets. By default, SCTP sockets are created active; to create a passive - socket, the listen(2) system call must be used after - binding the socket with the bind(2) or - sctp_bindx(3) system calls. Only passive sockets may use - the accept(2) call to accept incoming connections. Only - active sockets may use the connect(2) call to initiate - connections.

-

The other abstraction SOCK_SEQPACKET - provides a “connectionless” mode of operation in that the user - may send to an address (using any of the valid send calls that carry a - socket address) and an association will be setup implicitly by the - underlying SCTP transport stack. This abstraction is the only one capable of - sending data on the third leg of the four-way handshake. A user must still - call listen(2) to allow the socket to accept connections. - Calling listen(2) however does not restrict the user from - still initiating implicit connections to other peers.

-

The SCTP protocol directly supports multi-homing. So when binding - a socket with the “wildcard” address - INADDR_ANY, the SCTP stack will inform the peer - about all of the local addresses that are deemed in scope of the peer. The - peer will then possibly have multiple paths to reach the local host.

-

The SCTP transport protocol is also multi-streamed. - Multi-streaming refers to the ability to send sub-ordered flows of messages. - A user performs this by specifying a specific stream in one of the extended - send calls such as the sctp_send(3) function call. Sending - messages on different streams will allow parallel delivery of data i.e., a - message loss in stream 1 will not block the delivery of messages sent in - stream 2.

-

The SCTP transport protocol also provides a unordered service as - well. The unordered service allows a message to be sent and delivered with - no regard to the ordering of any other message.

-

The SCTP kernel implementation may either be compiled into the - kernel, or loaded dynamically as a module. To support dynamic loading of the - stack, the kernel must be compiled with options - SCTP_SUPPORT.

-
-

-

The FreeBSD implementation of SCTP also - supports the following extensions:

-
-
sctp partial reliability
-
This extension allows one to have message be skipped and not delivered - based on some user specified parameters.
-
sctp dynamic addressing
-
This extension allows addresses to be added and deleted dynamically from - an existing association.
-
sctp authentication
-
This extension allows the user to authenticate specific peer chunks - (including data) to validate that the peer who sent the message is in fact - the peer who setup the association. A shared key option is also provided - for so that two stacks can pre-share keys.
-
packet drop
-
Some routers support a special satellite protocol that will report losses - due to corruption. This allows retransmissions without subsequent loss in - bandwidth utilization.
-
stream reset
-
This extension allows a user on either side to reset the stream sequence - numbers used by any or all streams.
-
-
-
-

-

SCTP supports a number of socket options which can be set with - setsockopt(2) and tested with - getsockopt(2) or sctp_opt_info(3):

-
-
-
Under most circumstances, SCTP sends data when it is presented; when - outstanding data has not yet been acknowledged, it gathers small amounts - of output to be sent in a single packet once an acknowledgement is - received. For some clients, such as window systems that send a stream of - mouse events which receive no replies, this packetization may cause - significant delays. The boolean option - SCTP_NODELAY defeats this algorithm.
-
-
This option returns specific information about an associations - “Retransmission Time Out”. It can also be used to change the - default values.
-
-
This option returns specific information about the requested - association.
-
-
This option allows you to get or set the default sending parameters when - an association is implicitly setup. It allows you to change such things as - the maximum number of streams allowed inbound and the number of streams - requested of the peer.
-
-
For the one-to-many model (SOCK_SEQPACKET) - associations are setup implicitly. This option allows the user to specify - a default number of idle seconds to allow the association be maintained. - After the idle timer (where no user message have been sent or have been - received from the peer) the association will be gracefully closed. The - default for this value is 0, or unlimited (i.e., no automatic close).
-
-
The dynamic address extension allows a peer to also request a particular - address of its be made into the primary address. This option allows the - caller to make such a request to a peer. Note that if the peer does not - also support the dynamic address extension, this call will fail. Note the - caller must provide a valid local address that the peer has been told - about during association setup or dynamically.
-
-
This option allows the setting of the primary address that the caller - wishes to send to. The caller provides the address of a peer that is to be - made primary.
-
-
The dynamic address extension also allows a user to pass a 32 bit opaque - value upon association setup. This option allows a user to set or get this - value.
-
-
By default SCTP will fragment user messages into multiple pieces that will - fit on the network and then later, upon reception, reassemble the pieces - into a single user message. If this option is enabled instead, any send - that exceeds the path maximum transfer unit (P-MTU) will fail and the - message will NOT be sent.
-
-
This option will allow a user to set or get specific peer address - parameters.
-
-
When a user does not use one of the extended send calls (e.g., - sctp_sendmsg(3)) a set of default values apply to each - send. These values include things like the stream number to send to as - well as the per-protocol id. This option lets a caller both get and set - these values. If the user changes these default values, then these new - values will be used as the default whenever no information is provided by - the sender (i.e., the non-extended API is used).
-
-
SCTP has non-data events that it can communicate to its application. By - default these are all disabled since they arrive in the data path with a - special flag MSG_NOTIFICATION set upon the - received message. This option lets a caller both get what events are - current being received as well as set different events that they may be - interested in receiving.
-
-
SCTP supports both IPV4 and IPV6. An association may span both IPV4 and - IPV6 addresses since SCTP is multi-homed. By default, when opening an IPV6 - socket, when data arrives on the socket from a peer's V4 address the V4 - address will be presented with an address family of AF_INET. If this is - undesirable, then this option can be enabled which will then convert all - V4 addresses into mapped V6 representations.
-
-
By default SCTP chooses its message fragmentation point based upon the - smallest P-MTU of the peer. This option lets the caller set it to a - smaller value. Note that while the user can change this value, if the - P-MTU is smaller than the value set by the user, then the P-MTU value will - override any user setting.
-
-
This option lets the user both set and get the delayed ack time (in - milliseconds) and the ack frequency that SCTP is using. The default - delayed ack time is 200 milliseconds and the default ack frequency is - 2.
-
-
SCTP at times may need to start delivery of a very large message before - the entire message has arrived. By default SCTP waits until the incoming - message is larger than one fourth of the receive buffer. This option - allows the stacks value to be overridden with a smaller value.
-
-
SCTP at times will start partial delivery (as mentioned above). In the - normal case successive reads will continue to return the rest of the - message, blocking if needed, until all of that message is read. However - this means other messages may have arrived and be ready for delivery and - be blocked behind the message being partially delivered. If this option is - enabled, when a partial delivery message has no more data to be received, - then a subsequent read may return a different message that is ready for - delivery. By default this option is off since the user must be using the - extended API's to be able to tell the difference between messages (via the - stream and stream sequence number).
-
-
By default only the dynamic addressing chunks are authenticated. This - option lets a user request an additional chunk be authenticated as well. - Note that successive calls to this option will work and continue to add - more chunks that require authentication. Note that this option only - effects future associations and not existing ones.
-
-
This option allows a user to specify a shared key that can be later used - to authenticate a peer.
-
-
This option will let you get or set the list of HMAC algorithms used to - authenticate peers. Note that the HMAC values are in priority order where - the first HMAC identifier is the most preferred and the last is the least - preferred.
-
-
This option allows you to make a key active for the generation of - authentication information. Note that the peer must have the same key or - else the data will be discarded.
-
-
This option allows you to delete an old key.
-
-
The sockets api document allows an extended send/receive information - structure to be used. The extended structure includes additional fields - related to the next message to be received (after the current receive - completes) if such information is known. By default the system will not - pass this information. This option allows the user to request this - information.
-
-
By default when bound to all address and the system administrator has - enables automatic dynamic addresses, the SCTP stack will automatically - generate address changes into add and delete requests to any peers by - setting this option to true. This option allows an endpoint to disable - that behavior.
-
-
By default SCTP implements micro-burst control so that as the congestion - window opens up no large burst of packets can be generated. The default - burst limit is four. This option lets the user change this value.
-
-
Many sctp extended calls have a context field. The context field is a 32 - bit opaque value that will be returned in send failures. This option lets - the caller set the default context value to use when none is provided by - the user.
-
-
By default, a single send is a complete message. SCTP generates an implied - record boundary. If this option is enabled, then all sends are part of the - same message until the user indicates an end of record with the special - flag SCTP_EOR passed in the sctp_sndrcvinfo flags - field. This effectively makes all sends part of the same message until the - user specifies differently. This means that a caller must NOT change the - stream number until after the SCTP_EOR is passed - to SCTP else an error will be returned.
-
-
This option is a read-only option that returns various status information - about the specified association.
-
-
This read-only option returns information about a peer address.
-
-
This read-only option returns a list of the chunks the peer requires to be - authenticated.
-
-
This read-only option returns a list of the locally required chunks that - must be authenticated.
-
-
This socket option is used to cause a stream sequence number or all stream - sequence numbers to be reset. Note that the peer SCTP endpoint must also - support the stream reset extension as well.
-
-
-
-

-

The SCTP protocol implements a number of variables in the - net.inet.sctp branch of the - sysctl(3) MIB.

-
-
-
-
-
default_cc_module
-
Default congestion control module. Default value is 0. The minimum is - 0, and the maximum is 3. A value of 0 enables the default congestion - control algorithm. A value of 1 enables the High Speed congestion - control algorithm. A value of 2 enables the HTCP congestion control - algorithm. A value of 3 enables the data center congestion control - (DCCC) algorithm.
-
initial_cwnd
-
Defines the initial congestion window size in MTUs.
-
cwnd_maxburst
-
Use congestion control instead of 'blind' logic to limit maximum burst - when sending. Default value is 1. May be set to 0 or 1.
-
ecn_enable
-
Enable Explicit Congestion Notification (ECN). Default value is 1. May - be set to 0 or 1.
-
rttvar_steady_step
-
Number of identical bandwidth measurements DCCC takes to try step down - the congestion window. Default value is 20. The minimum is 0, and the - maximum is 65535.
-
rttvar_eqret
-
Whether DCCC reduces the congestion window size when round-trip time - and bandwidth remain unchanged. Default value is 0. May be set to 0 or - 1.
-
rttvar_bw
-
Shift amount DCCC uses for bandwidth smoothing on round-trip-time - calculation. Default value is 4. The minimum is 0, and the maximum is - 32.
-
rttvar_rtt
-
Shift amount DCCC uses for round-trip-time smoothing on - round-trip-time calculation. Default value is 5. The minimum is 0, and - the maximum is 32.
-
use_dcccecn
-
Enable ECN when using DCCC. Default value is 1. May be set to 0 or - 1.
-
-
-
-
-
-
getcred
-
Get the ucred of a SCTP connection.
-
assoclist
-
List of active SCTP associations.
-
stats
-
SCTP statistics (struct sctp_stat).
-
diag_info_code
-
Diagnostic information error cause code.
-
blackhole
-
Enable SCTP blackholing. See blackhole(4) for more - details.
-
sendall_limit
-
Maximum message size (in bytes) that can be transmitted with - SCTP_SENDALL flags set.
-
buffer_splitting
-
Enable send/receive buffer splitting.
-
vtag_time_wait
-
Vtag wait time in seconds, 0 to disable.
-
nat_friendly_init
-
Enable sending of the NAT-friendly SCTP option on INITs.
-
enable_sack_immediately
-
Enable sending of the SACK-IMMEDIATELY bit.
-
udp_tunneling_port
-
Set the SCTP/UDP tunneling port.
-
mobility_fasthandoff
-
Enable SCTP fast handoff.
-
mobility_base
-
Enable SCTP base mobility
-
default_frag_interleave
-
Default fragment interleave level.
-
default_ss_module
-
Default stream scheduling module.
-
log_level
-
Ltrace/KTR trace logging level.
-
max_retran_chunk
-
Number of retransmissions of a DATA chunk before an association is - aborted.
-
min_residual
-
Minimum residual data chunk in second part of split.
-
strict_data_order
-
Enforce strict data ordering, abort if control inside data.
-
abort_at_limit
-
Abort when one-to-one hits qlimit.
-
hb_max_burst
-
Confirmation heartbeat max burst.
-
do_sctp_drain
-
Flush chunks in receive queues with TSN higher than the cumulative TSN - if the system is low on mbufs.
-
max_chained_mbufs
-
Default max number of small mbufs on a chain.
-
abc_l_var
-
SCTP ABC max increase per SACK (L).
-
nat_friendly
-
SCTP NAT friendly operation.
-
cmt_use_dac
-
CMT DAC on/off flag.
-
cmt_on_off
-
CMT settings.
-
outgoing_streams
-
Default number of outgoing streams.
-
incoming_streams
-
Default number of incoming streams.
-
add_more_on_output
-
When space-wise is it worthwhile to try to add more to a socket send - buffer.
-
path_pf_threshold
-
Default potentially failed threshold.
-
path_rtx_max
-
Default maximum of retransmissions per path.
-
assoc_rtx_max
-
Default maximum number of retransmissions per association.
-
init_rtx_max
-
Default maximum number of retransmissions for INIT chunks.
- -
Default cookie lifetime in seconds.
-
init_rto_max
-
Default maximum retransmission timeout during association setup in - ms.
-
rto_initial
-
Default initial retransmission timeout in ms.
-
rto_min
-
Default minimum retransmission timeout in ms.
-
rto_max
-
Default maximum retransmission timeout in ms.
-
secret_lifetime
-
Default secret lifetime in seconds.
-
shutdown_guard_time
-
Shutdown guard timer in seconds (0 means 5 times RTO.Max).
-
pmtu_raise_time
-
Default PMTU raise timer in seconds.
-
heartbeat_interval
-
Default heartbeat interval in ms.
-
asoc_resource
-
Max number of cached resources in an association.
-
sys_resource
-
Max number of cached resources in the system.
-
sack_freq
-
Default SACK frequency.
-
delayed_sack_time
-
Default delayed SACK timer in ms.
-
chunkscale
-
Tunable for scaling of number of chunks and messages.
-
min_split_point
-
Minimum size when splitting a chunk.
-
pcbhashsize
-
Tunable for PCB hash table sizes.
-
tcbhashsize
-
Tunable for TCB hash table sizes.
-
maxchunks
-
Default max chunks on queue per association.
-
fr_maxburst
-
Default max burst for SCTP endpoints when fast retransmitting.
-
maxburst
-
Default max burst for SCTP endpoints.
-
peer_chkoh
-
Amount to debit peers rwnd per chunk sent.
-
strict_sacks
-
Enable SCTP Strict SACK checking.
-
pktdrop_enable
-
Enable SCTP PKTDROP.
-
nrsack_enable
-
Enable SCTP NR-SACK.
-
reconfig_enable
-
Enable SCTP RE-CONFIG.
-
asconf_enable
-
Enable SCTP ASCONF.
-
auth_enable
-
Enable SCTP AUTH.
-
pr_enable
-
Enable PR-SCTP.
-
auto_asconf
-
Enable SCTP Auto-ASCONF.
-
recvspace
-
Maximum incoming SCTP buffer size.
-
sendspace
-
Maximum outgoing SCTP buffer size.
-
-
-
-
-
-
-

-

accept(2), bind(2), - connect(2), listen(2), - sctp_bindx(3), sctp_connectx(3), - sctp_opt_info(3), sctp_recvmsg(3), - sctp_sendmsg(3), blackhole(4)

-
-
-

-

The sctp kernel module cannot be - unloaded.

-
-
- - - - - -
June 21, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/sdhci.4 3.html b/static/freebsd/man4/sdhci.4 3.html deleted file mode 100644 index 7a0a1fc7..00000000 --- a/static/freebsd/man4/sdhci.4 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
SDHCI(4)Device Drivers ManualSDHCI(4)
-
-
-

-

sdhci — PCI SD - Host Controller bridge driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device mmc -
-device mmcsd -
-device sdhci
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
mmc_load="YES"
-mmcsd_load="YES"
-sdhci_load="YES"
-
-
-
-

-

The sdhci driver supports PCI devices with - class 8 and subclass 5 according to SD Host Controller Specification. Driver - supports up to six high speed 4bit MMC/SD slots per controller. Driver - attaches mmc bus to the respective slot on card insertion and detaches it on - card removing.

-
-
-

-

The sdhci driver supports the SD Host - Controller Specification. When attaching via the PCI bus, the controller is - automatically configured. Many SoC chips provide a SDHCI controller directly - mapped to I/O memory. For those, the controller may be configured using - fdt(4) or acpi(4) methods, supplied by - your board's vendor.

-

Unlike most other drivers that support a generic standard, - sdhci requires a large number of quirks to cope with - hardware bugs, proprietary registers and poorly specified power management. - While many chipsets from Intel, Xilinx, Rockchip, Frescale, Ricoh, and TI - have these entries, suboptimal performance may result when using some - controllers. Quirks and custom configuration are most often required when - the device is configured via fdt(4) or - acpi(4).

-
-
-

-

mmc(4), mmcsd(4)

-

SD Specifications, Part 2, SD - Host Controller, Simplified Specification.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org>

-
-
- - - - - -
October 3, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/sem.4 3.html b/static/freebsd/man4/sem.4 3.html deleted file mode 100644 index d1861ce6..00000000 --- a/static/freebsd/man4/sem.4 3.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - -
SEM(4)Device Drivers ManualSEM(4)
-
-
-

-

sem — POSIX - semaphores

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
options - P1003_1B_SEMAPHORES
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
sem_load="YES"
-
-

To load the driver as a module at run-time, run the following - command as root:

-
kldload sem
-
-
-

-

The sem facility provides system calls - used by the standard C library (libc) to implement - POSIX semaphores. This facility offers support for such functions as - () - and - (). - It is available both as a kernel option for static inclusion and as a - dynamic kernel module.

-
-
-

-

sem_destroy(3), - sem_getvalue(3), sem_init(3), - sem_open(3), sem_post(3), - sem_wait(3), config(8), - kldload(8), kldunload(8)

-
-
-

-

The sem facility appeared in - FreeBSD 5.0.

-
-
- - - - - -
February 7, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/send.4 3.html b/static/freebsd/man4/send.4 3.html deleted file mode 100644 index d166f2e1..00000000 --- a/static/freebsd/man4/send.4 3.html +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - -
SEND(4)Device Drivers ManualSEND(4)
-
-
-

-

send — Kernel side - support for Secure Neighbor Discovery (SeND)

-
-
-

-

#include - <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet6/send.h>

-

int -
- socket(PF_INET6, - SOCK_RAW, - IPPROTO_SEND);

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
send_load="YES"
-
-
-
-

-

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover - other nodes on the link, to determine their link-layer addresses to find - routers, and to maintain reachability information about the paths to active - members. NDP is vulnerable to various attacks [RFC3756]. Secure Neighbor - Discovery is a set of extensions to NDP that counter threats to NDP - [RFC3971].

-

Kernel side support for SeND consists of a kernel module with - hooks that divert relevant packets (Neighbor Solicitations, Neighbor - Advertisements, Router Solicitations, Router Advertisements and Redirects) - from the NDP stack, send them to user space on a dedicated socket and - reinject them back for further processing. Hooks are triggered only if the - send module is loaded.

-

The native SeND socket is similar to a raw IP socket, but with its - own, internal pseudo-protocol (IPPROTO_SEND). Struct sockaddr_send is - defined in - <netinet6/send.h>. It - defines the total length of the structure, the address family, packet's - incoming or outgoing direction from the interface's point of view, and the - interface index.

-
-
struct sockaddr_send {
-        unsigned char           send_len;       /* total length */
-        sa_family_t             send_family;    /* address family */
-        int                     send_direction;
-        int                     send_ifidx;
-        char                    send_zero[8];
-};
-
-

The address family is always AF_INET6. The - send_direction variable denotes the direction of the - packet from the interface's point of view and has either the value - SND_IN or SND_OUT. The - send_ifidx variable is the interface index of the - receiving or sending interface. The send_zero variable - is padding and must always be zero.

-

In case that no user space application is connected to the send - socket, processing continues normally as if the module was not loaded.

-
-
-

-

The input hook is named after the input path of the incoming or - outgoing NDP packets, on the way from the wire, through the nd6 stack, to - user space. Relevant packets are identified by adding an mbuf_tag (see - mbuf_tags(9)) to the mbuf(9), if the - send module is loaded. It is then passed on to the - kernel-userland interface for either cryptographic protection or validation - by the SeND application. The hook takes an argument that describes the - direction of the packet, both in case of incoming and outgoing packets. - SND_IN is the direction of the incoming packets that - are usually protected by the SeND options and then sent to user space for - cryptographic validation. SND_OUT is the outgoing - direction. It describes both reply and locally originated outgoing packets - that are sent to user space for the addition of SeND options.

-
-
-

-

The incoming ND packet from the wire:

-
-
                                        kernelspace ( userspace
-                                                    )
- incoming SeND/ND packet                            (
-            |                                       )
-            v                 ( SND_IN )            (
-           icmp6_input() -> send_input_hook ---> send socket ----+
-            :                                       )            |
-            :             #                 #       (            |
-   normal   :             #                 #       )            v
- processing :             #     send.ko     #       (    SeND application
-    path    :             #                 #       )            |
-            :             #                 #       (            |
-            v                                       )            |
-   icmp6/nd6_??_input() <- protocol switch  <--- send socket <---+
-            |         structure (IPPPROTO_SEND)     )
-            |                ( SND_IN )             (
-            v                                       )
- continue normal ND processing                      (
-
-
-
-

-

Outgoing ND packet (reply or locally triggered):

-
-
                                        kernelspace ( userspace
-                                                    )
- nd6_na_input()                                     (
- +PACKET_TAG_ND_OUTGOING                            )
- |                                                  )
- |   outgoing packet                                (
- |          |                                       )
- |          v                                       (
- |   icmp6_redirect_output()                        )
- |   nd6_ns_output()                                (
- |   nd6_na_output()                                )
- |   +PACKET_TAG_ND_OUTGOING                        (
- |          |                                       )
- |          +-----------<- rip6_output() <----------)----- rtsol/rtadvd/..
- |          |              +PACKET_TAG_ND_OUTGOING  (
- |          v                                       )
- |       ip6_output()                               (
- |          |                                       )
- +-------->-+                                       (
-            |                                       )
-            v                ( SND_OUT )            (
-        nd6_output_lle() -> send_input_hook ---> send socket ----+
- -PACKET_TAG_ND_OUTGOING                            )            |
-            :             #                 #       (            |
-   normal   :             #                 #       )            v
- processing :             #     send.ko     #       (    SeND application
-    path    :             #                 #       )            |
-            :             #                 #       (            |
-            v                                       )            |
-    (*ifp->if_output)() <- protocol switch  <--- send socket <---+
-            |         structure (IPPPROTO_SEND)     )
-            |                ( SND_OUT )            (
-            v                                       )
- continue with normal packet output                 (
-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[]
-
Another user space SeND application is bound to the socket.
-
[]
-
Shortage of space to receive the incoming (SeND-protected) or outgoing - (SeND-validated) packet from the SeND application.
-
[]
-
A packet received from user space and passed to the NDP stack for further - processing is neither Neighbor Solicitation, Neighbor Advertisement, - Router Solicitation, Router Advertisement nor Redirect.
-
[]
-
Occurs if interface output routines fail to send the packet out of the - interface.
-
-
-
-

-

recvfrom(2), sendto(2), - socket(2), loader.conf(5)

-
-
-

-

The send module first appeared in - FreeBSD 9.0.

-
-
-

-

Ana Kukec - <anchie@FreeBSD.org>, - University of Zagreb

-
-
-

-

Due to the lack of NDP locking, it is currently not possible to - unload the send module.

-
-
- - - - - -
September 19, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/ses.4 3.html b/static/freebsd/man4/ses.4 3.html deleted file mode 100644 index c2aad7c5..00000000 --- a/static/freebsd/man4/ses.4 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
SES(4)Device Drivers ManualSES(4)
-
-
-

-

ses — SCSI - Environmental Services driver

-
-
-

-

device ses

-
-
-

-

The ses driver provides support for all - SCSI devices of the environmental services class that are attached to the - system through a supported SCSI Host Adapter, as well as emulated support - for SAF-TE (SCSI Accessible Fault Tolerant Enclosures). The environmental - services class generally are enclosure devices that provide environmental - information such as number of power supplies (and state), temperature, - device slots, and so on.

-

A SCSI Host adapter must also be separately configured into the - system before a SCSI Environmental Services device can be configured.

-
-
-

-

It is only necessary to explicitly configure one - ses device; data structures are dynamically - allocated as devices are found on the SCSI bus.

-

A separate option, SES_ENABLE_PASSTHROUGH, - may be specified to allow the ses driver to perform - functions on devices of other classes that claim to also support - ses functionality.

-
-
-

-

The following ioctl(2) calls apply to - ses devices. They are defined in the header file - <cam/scsi/scsi_enc.h> - (q.v.).

-
-
-
Used to find out how many ses elements are driven - by this particular device instance.
-
-
Read, from the kernel, an array of SES elements which contains the element - identifier, which subenclosure it is in, and the - ses type of the element.
-
-
Get the overall enclosure status.
-
-
Set the overall enclosure status.
-
-
Get the status of a particular element.
-
-
Set the status of a particular element.
-
-
Get the associated help text for an element (not yet implemented). - ses devices often have descriptive text for an - element which can tell you things like location (e.g., "left power - supply").
-
-
Initialize the enclosure.
-
-
Get the element's descriptor string.
-
-
Get the device names, if any, associated with this element.
-
-
Used to read the SES String In Diagnostic Page. The contents of this page - are device-specific.
-
-
Used to set the SES String Out Diagnostic Page. The contents of this page - are device-specific.
-
-
Used to get the name of the enclosure.
-
-
Used to get the Enclosure Logical Identifier.
-
-
-
-

-

The files contained in - </usr/share/examples/ses> - show simple mechanisms for how to use these interfaces, as well as a very - stupid simple monitoring daemon.

-
-
-

-
-
/dev/sesN
-
The - SES device.
-
-
-
-

-

When the kernel is configured with DEBUG enabled, the first open - to an SES device will spit out overall enclosure parameters to the - console.

-
-
-

-

sesutil(8)

-
-
-

-

The ses driver was originally written for - the CAM SCSI subsystem by Matthew Jacob and first released in - FreeBSD 4.3. It was a functional equivalent of a - similar driver available in Solaris, Release 7. It was largely rewritten by - Alexander Motin, Justin Gibbs, and Will Andrews for FreeBSD - 9.2.

-
-
- - - - - -
November 12, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/sfxge.4 3.html b/static/freebsd/man4/sfxge.4 3.html deleted file mode 100644 index caafc59a..00000000 --- a/static/freebsd/man4/sfxge.4 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
SFXGE(4)Device Drivers Manual (amd64)SFXGE(4)
-
-
-

-

sfxge — Solarflare - 10Gb Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sfxge
-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
sfxge_load="YES"
-
-
-
-

-

The sfxge driver provides support for 10Gb - Ethernet adapters based on Solarflare SFC9000 and XtremeScale X2 family - controllers. The driver supports jumbo frames, transmit/receive checksum - offload, TCP Segmentation Offload (TSO), Large Receive Offload (LRO), VLAN - checksum offload, VLAN TSO, and Receive Side Scaling (RSS) using MSI-X - interrupts.

-

The driver allocates 1 receive queue, transmit queue, event queue - and IRQ per CPU up to a maximum of 64. IRQ affinities should be spread out - using cpuset(1). Interrupt moderation may be controlled - through the sysctl dev.sfxge.%d.int_mod (units are - microseconds).

-

For more information on configuring this device, see - ifconfig(8).

-

A large number of MAC, PHY and data path statistics are available - under the sysctl dev.sfxge.%d.stats. The adapter's VPD - fields including its serial number are available under the sysctl - dev.sfxge.%d.vpd.

-
-
-

-

The sfxge driver supports all 10Gb - Ethernet adapters based on Solarflare SFC9000 family controllers.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5). - Actual values can be obtained using sysctl(8).

-
-
hw.sfxge.rx_ring
-
The maximum number of descriptors in a receive queue ring. Supported - values are: 512, 1024, 2048 and 4096.
-
hw.sfxge.tx_ring
-
The maximum number of descriptors in a transmit queue ring. Supported - values are: 512, 1024, 2048 and 4096.
-
hw.sfxge.tx_dpl_get_max
-
The maximum length of the deferred packet “get-list” for - queued transmit packets (TCP and non-TCP), used only if the transmit queue - lock can be acquired. If a packet is dropped, the - tx_get_overflow counter is incremented and the local - sender receives ENOBUFS. The value must be greater than 0.
-
hw.sfxge.tx_dpl_get_non_tcp_max
-
The maximum number of non-TCP packets in the deferred packet - “get-list” , used only if the transmit queue lock can be - acquired. If a packet is dropped, the - tx_get_non_tcp_overflow counter is incremented and - the local sender receives ENOBUFS. The value must be greater than 0.
-
hw.sfxge.tx_dpl_put_max
-
The maximum length of the deferred packet “put-list” for - queued transmit packets, used if the transmit queue lock cannot be - acquired. If a packet is dropped, the - tx_put_overflow counter is incremented and the local - sender receives ENOBUFS. The value must be greater than or equal to - 0.
-
hw.sfxge.tso_fw_assisted
-
Bitmask to enable/disable usage of FW-assisted TSO version if supported by - NIC firmware. FATSOv1 (bit 0) and FATSOv2 (bit 1) are supported. All - enabled by default.
-
hw.sfxge.N.max_rss_channels
-
The maximum number of allocated RSS channels for the Nth adapter. If set - to 0 or unset, the number of channels is determined by the number of CPU - cores.
-
hw.sfxge.lro.table_size
-
Size of the LRO hash table. Must be a power of 2. A larger table means we - can accelerate a larger number of streams.
-
hw.sfxge.lro.chain_max
-
The maximum length of a hash chain. If chains get too long then the lookup - time increases and may exceed the benefit of LRO.
-
hw.sfxge.lro.idle_ticks
-
The maximum time (in ticks) that a connection can be idle before it's LRO - state is discarded.
-
hw.sfxge.lro.slow_start_packets
-
Number of packets with payload that must arrive in-order before a - connection is eligible for LRO. The idea is we should avoid coalescing - segments when the sender is in slow-start because reducing the ACK rate - can damage performance.
-
hw.sfxge.lro.loss_packets
-
Number of packets with payload that must arrive in-order following loss - before a connection is eligible for LRO. The idea is we should avoid - coalescing segments when the sender is recovering from loss, because - reducing the ACK rate can damage performance.
-
hw.sfxge.mcdi_logging
-
Enable logging of MCDI protocol messages (only available if enabled at - compile-time).
-
hw.sfxge.N.mcdi_logging
-
Enable or disable logging of MCDI protocol messages on a per-port basis. - The default for each port will be the value of - hw.sfxge.mcdi_logging. The logging may also be - enabled or disabled after the driver is loaded using the sysctl - dev.sfxge.%d.mcdi_logging.
-
hw.sfxge.stats_update_period_ms
-
Period in milliseconds to refresh interface statistics from hardware. The - accepted range is 0 to 65535, the default is 1000 (1 second). Use zero - value to disable periodic statistics update. Supported on SFN8xxx series - adapters with firmware v6.2.1.1033 and later and SFN5xxx, SFN6xxx and - XtremeScale X2xxx series adapters. SFN7xxx series adapters and sfN8xxx - series with earlier firmware use a fixed 1000 milliseconds statistics - update period. The period may also be changed after the driver is loaded - using the sysctl - dev.sfxge.%d.stats_update_period_ms.
-
-
-
-

-

For general information and support, go to the Solarflare support - website at: https://support.solarflare.com.

-
-
-

-

cpuset(1), arp(4), - netintro(4), ng_ether(4), - vlan(4), ifconfig(8)

-
-
-

-

The sfxge driver was written by - Philip Paeps and -
- Solarflare Communications, Inc.

-
-
- - - - - -
February 22, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/sg.4 4.html b/static/freebsd/man4/sg.4 4.html deleted file mode 100644 index f672cfe2..00000000 --- a/static/freebsd/man4/sg.4 4.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
SG(4)Device Drivers ManualSG(4)
-
-
-

-

sg — Linux - ioctl-compatible SCSI passthru device

-
-
-

-

device sg -
- device scbus

-
-
-

-

The sg driver provides a Linux compatible - scsi passthru device. This driver attaches to all cam(4) - peripheral devices. It is similar to the pass(4) device, - but uses the Linux interfaces, rather than the FreeBSD CAM interfaces.

-
-
-

-

The following subset of the Linux sg ioctl interfaces are - implemented:

-
-
SG_SET_TIMEOUT
-
u_int to Set the timeout in milliseconds.
-
SG_GET_TIMEOUT
-
Get the timeout in milliseconds
-
SG_GET_RESERVED_SIZE
-
u_int Returns the size of the I/O one can do this - device.
-
SG_GET_SCSI_ID
-
struct sg_scsi_id Returns the bus number, channel, - scsi bus ID number, lun and other information about the SCSI device.
-
SG_GET_SG_TABLESIZE
-
u_int Returns the table size, though hard wired to - 0.
-
SG_GET_VERSION_NUM
-
u_int Return the version number that is - implemented.
-
SG_IO
-
struct sg_io_hdr
-
-All other ioctl interfaces return ENODEV. -
-
-

-
-
/dev/sg*
-
Passthru devices.
-
-
-
-

-

cam(4), pass(4)

-
-
-

-

The sg driver first appeared in - FreeBSD 7.0.

-
-
- - - - - -
May 6, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/sge.4 3.html b/static/freebsd/man4/sge.4 3.html deleted file mode 100644 index f1f47eec..00000000 --- a/static/freebsd/man4/sge.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
SGE(4)Device Drivers ManualSGE(4)
-
-
-

-

sge — Silicon - Integrated Systems SiS190/191 Fast/Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device sge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_sge_load="YES"
-
-
-
-

-

The sge device driver provides support for - SiS190 Fast Ethernet controllers and SiS191 Fast/Gigabit Ethernet - controllers.

-

All LOMs supported by the sge driver have - TCP/UDP/IP checksum offload for transmit and receive, TCP segmentation - offload (TSO), hardware VLAN tag stripping/insertion features. Due to lack - of documentation Wake On Lan (WOL), Jumbo frame and an interrupt moderation - mechanism are not supported yet.

-

The sge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-
Set 1000baseTX operation over twisted pair.
-
-

The sge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The sge device driver provides support for - the following Ethernet controllers:

-

-
    -
  • SiS190 Fast Ethernet controller
    • -
  • SiS191 Fast/Gigabit Ethernet controller
    • -
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), rgephy(4), - vlan(4), ifconfig(8)

-
-
-

-

The sge driver was written by - Alexander Pohoyda - <alexander.pohoyda@gmx.net>. - And enhanced by Nikolay Denev - <ndenev@gmail.com>. - It first appeared in FreeBSD 8.1.

-
-
- - - - - -
January 16, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/siba.4 3.html b/static/freebsd/man4/siba.4 3.html deleted file mode 100644 index a5d85b7c..00000000 --- a/static/freebsd/man4/siba.4 3.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
SIBA(4)Device Drivers ManualSIBA(4)
-
-
-

-

siba — Sonic Inc. - Silicon Backplane driver

-
-
-

-

To compile this driver into the kernel, add the following lines to - the kernel configuration file:

-
device bhnd -
-device siba
-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
siba_load="YES"
-
-
-
-

-

The siba driver provides - bhnd(4) support for devices based on the Sonic Inc. - Silicon Backplane, an interblock communications architecture found in - earlier Broadcom Home Networking Division wireless chipsets and embedded - systems.

-

A common interconnect connects all of the Silicon Backplane's - functional blocks. These functional blocks, known as cores, use the Open - Core Protocol (OCP) interface to communicate with agents attached to the - Silicon Backplane.

-

Each core can have an initiator agent that passes read and write - requests onto the system backplane and a target agent that returns responses - to those requests. Not all cores contain both an initiator and a target - agent. Initiator agents are present in cores that contain host interfaces - (PCI, PCMCIA), embedded processors (MIPS), or DMA processors associated with - communications cores.

-
-
-

-

bcma(4), bhnd(4), - intro(4)

-
-
-

-

The siba device driver first appeared in - FreeBSD 8.0. The driver was rewritten for - FreeBSD 11.0 to support the common Broadcom - bhnd(4) bus interface.

-
-
-

-

The siba driver was originally written by - Bruce M. Simpson - <bms@FreeBSD.org> and - Weongyo Jeong - <weongyo@FreeBSD.org>. - The driver was rewritten for FreeBSD 11.0 by - Landon Fuller - <landonf@FreeBSD.org>.

-
-
- - - - - -
September 13, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/siftr.4 3.html b/static/freebsd/man4/siftr.4 3.html deleted file mode 100644 index 804c2bbf..00000000 --- a/static/freebsd/man4/siftr.4 3.html +++ /dev/null @@ -1,717 +0,0 @@ - - - - - - -
SIFTR(4)Device Drivers ManualSIFTR(4)
-
-
-

-

SIFTR — - Statistical Information For TCP Research

-
-
-

-

To load the driver as a module at run-time, run the following - command as root:

-
-
kldload siftr
-
-

Alternatively, to load the driver as a module at boot time, add - the following line into the loader.conf(5) file:

-
-
siftr_load="YES"
-
-
-
-

-

The SIFTR - (tatistical - nformation - or - CP - esearch) kernel - module logs a range of statistics on active TCP connections to a log file. - It provides the ability to make highly granular measurements of TCP - connection state, aimed at system administrators, developers and - researchers.

-
-

-

The default operation of SIFTR is to - capture IPv4 TCP/IP packets. SIFTR can be configured - to support IPv4 and IPv6 by uncommenting:

-
-
CFLAGS+=-DSIFTR_IPV6
-
-

in ⟨sys/modules/siftr/Makefile⟩ and recompiling.

-

In the IPv4-only (default) mode, standard dotted decimal notation - (e.g. "136.186.229.95") is used to format IPv4 addresses for - logging. In IPv6 mode, standard dotted decimal notation is used to format - IPv4 addresses, and standard colon-separated hex notation (see RFC 4291) is - used to format IPv6 addresses (e.g. "fd00::2") for logging.

-
-
-

-

SIFTR utilises the - sysctl(8) interface to export its configuration variables - to user-space. The following variables are available:

-
-
-
net.inet.siftr.enabled
-
controls whether the module performs its measurements or not. By default, - the value is set to 0, which means the module will not be taking any - measurements. Having the module loaded with - net.inet.siftr.enabled set to 0 will have no impact - on the performance of the network stack, as the packet filtering hooks are - only inserted when net.inet.siftr.enabled is set to - 1.
-
-
-
-
-
net.inet.siftr.ppl
-
controls how many inbound/outbound packets for a given TCP connection will - cause a log message to be generated for the connection. By default, the - value is set to 1, which means the module will log a message for every - packet of every TCP connection. The value can be set to any integer in the - range [1,2^32], and can be changed at any time, even while the module is - enabled.
-
-
-
-
-
net.inet.siftr.logfile
-
controls the path to the file that the module writes its log messages to. - By default, the file /var/log/siftr.log is used. The path can be changed - at any time, even while the module is enabled.
-
-
-
-
-
net.inet.siftr.port_filter
-
controls on which source or destination port SIFTR - should capture. By default, the value is set to 0, which means all ports - are eligible for logging. Set to any other value, only packets where - either the source or destination port is equal to this number are - logged.
-
-
-
-
-

-

A typical SIFTR log file will contain 3 - different types of log message. All messages are written in plain ASCII - text.

-

Note: The "\" present in the example log messages in - this section indicates a line continuation and is not part of the actual log - message.

-

The first type of log message is written to the file when the - module is enabled and starts collecting data from the running kernel. The - text below shows an example module enable log. The fields are tab delimited - key-value pairs which describe some basic information about the system.

-
-
enable_time_secs=1685191807    enable_time_usecs=160752 \
-siftrver=1.3.0    sysname=FreeBSD    sysver=1400089    ipmode=4
-
-

Field descriptions are as follows:

-
-
-
enable_time_secs
-
time at which the module was enabled, in seconds since the UNIX - epoch.
-
-
-
-
-
enable_time_usecs
-
time at which the module was enabled, in microseconds since - enable_time_secs.
-
-
-
-
-
siftrver
-
version of SIFTR.
-
-
-
-
-
sysname
-
operating system name.
-
-
-
-
-
sysver
-
operating system version.
-
-
-
-
-
ipmode
-
IP mode as defined at compile time. An ipmode of "4" means IPv6 - is not supported and IP addresses are logged in regular dotted quad - format. An ipmode of "6" means IPv6 is supported, and IP - addresses are logged in dotted quad or hex format, as described in the - "Compile-time Configuration" subsection.
-
-
-

The second type of log message is written to the file when a data - log message is generated. The text below shows an example data log triggered - by an IPv4 TCP/IP packet. The data is CSV formatted.

-
-
o,1685191814.185109,10.1.1.2,32291,10.1.1.3,5001,1073725440, \
-14480,2,65160,65700,7,9,4,1460,1000,1,16778209,230000,33580,0, \
-65700,0,0,0,86707916,130
-
-

Field descriptions are as follows:

-
-
-
1
-
Direction of packet that triggered the log message. Either "i" - for in, or "o" for out.
-
-
-
-
-
2
-
Time at which the packet that triggered the log message was processed by - the pfil(9) hook function, in seconds and microseconds - since the UNIX epoch.
-
-
-
-
-
3
-
The IPv4 or IPv6 address of the local host, in dotted quad (IPv4 packet) - or colon-separated hex (IPv6 packet) notation.
-
-
-
-
-
4
-
The TCP port that the local host is communicating via.
-
-
-
-
-
5
-
The IPv4 or IPv6 address of the foreign host, in dotted quad (IPv4 packet) - or colon-separated hex (IPv6 packet) notation.
-
-
-
-
-
6
-
The TCP port that the foreign host is communicating via.
-
-
-
-
-
7
-
The slow start threshold for the flow, in bytes.
-
-
-
-
-
8
-
The current congestion window for the flow, in bytes.
-
-
-
-
-
9
-
The current state of the t_flags2 field for the flow.
-
-
-
-
-
10
-
The current sending window for the flow, in bytes. The post scaled value - is reported.
-
-
-
-
-
11
-
The current receive window for the flow, in bytes. The post scaled value - is always reported.
-
-
-
-
-
12
-
The current window scaling factor for the sending window.
-
-
-
-
-
13
-
The current window scaling factor for the receiving window.
-
-
-
-
-
14
-
The current state of the TCP finite state machine, as defined in - ⟨netinet/tcp_fsm.h⟩.
-
-
-
-
-
15
-
The maximum segment size for the flow, in bytes.
-
-
-
-
-
16
-
The current smoothed RTT estimate for the flow, in units of - microsecond.
-
-
-
-
-
17
-
SACK enabled indicator. 1 if SACK enabled, 0 otherwise.
-
-
-
-
-
18
-
The current state of the TCP flags for the flow. See - ⟨netinet/tcp_var.h⟩ for information - about the various flags.
-
-
-
-
-
19
-
The current retransmission timeout length for the flow, in units - microsecond.
-
-
-
-
-
20
-
The current size of the socket send buffer in bytes.
-
-
-
-
-
21
-
The current number of bytes in the socket send buffer.
-
-
-
-
-
22
-
The current size of the socket receive buffer in bytes.
-
-
-
-
-
23
-
The current number of bytes in the socket receive buffer.
-
-
-
-
-
24
-
The current number of unacknowledged bytes in-flight. Bytes acknowledged - via SACK are not excluded from this count.
-
-
-
-
-
25
-
The current number of segments in the reassembly queue.
-
-
-
-
-
26
-
Flowid for the connection. A caveat: Zero '0' either represents a valid - flowid or a default value when it's not being set. There is no easy way to - differentiate without looking at actual network interface card and drivers - being used.
-
-
-
-
-
27
-
Flow type for the connection. Flowtype defines which protocol fields are - hashed to produce the flowid. A complete listing is available in - sys/mbuf.h under - M_HASHTYPE_*.
-
-
-

The third type of log message is written to the file when the - module is disabled and ceases collecting data from the running kernel. The - text below shows an example module disable log. The fields are tab delimited - key-value pairs which provide statistics about operations since the module - was most recently enabled.

-
-
disable_time_secs=1685191816    disable_time_usecs=629397 \
-num_inbound_tcp_pkts=10    num_outbound_tcp_pkts=10 \
-total_tcp_pkts=20    num_inbound_skipped_pkts_malloc=0 \
-num_outbound_skipped_pkts_malloc=0    num_inbound_skipped_pkts_tcpcb=2 \
-num_outbound_skipped_pkts_tcpcb=2    num_inbound_skipped_pkts_inpcb=0 \
-num_outbound_skipped_pkts_inpcb=0    total_skipped_tcp_pkts=4 \
-flow_list=10.1.1.2;32291-10.1.1.3;5001,10.1.1.2;58544-10.1.1.3;5001,
-
-

Field descriptions are as follows:

-
-
-
disable_time_secs
-
Time at which the module was disabled, in seconds since the UNIX - epoch.
-
-
-
-
-
disable_time_usecs
-
Time at which the module was disabled, in microseconds since - disable_time_secs.
-
-
-
-
-
num_inbound_tcp_pkts
-
Number of TCP packets that traversed up the network stack. This only - includes inbound TCP packets during the periods when - SIFTR was enabled.
-
-
-
-
-
num_outbound_tcp_pkts
-
Number of TCP packets that traversed down the network stack. This only - includes outbound TCP packets during the periods when - SIFTR was enabled.
-
-
-
-
-
total_tcp_pkts
-
The summation of num_inbound_tcp_pkts and num_outbound_tcp_pkts.
-
-
-
-
-
num_inbound_skipped_pkts_malloc
-
Number of inbound packets that were not processed because of failed - () - calls.
-
-
-
-
-
num_outbound_skipped_pkts_malloc
-
Number of outbound packets that were not processed because of failed - malloc() calls.
-
-
-
-
-
num_inbound_skipped_pkts_tcpcb
-
Number of inbound packets that were not processed because of failure to - find the TCP control block associated with the packet.
-
-
-
-
-
num_outbound_skipped_pkts_tcpcb
-
Number of outbound packets that were not processed because of failure to - find the TCP control block associated with the packet.
-
-
-
-
-
num_inbound_skipped_pkts_inpcb
-
Number of inbound packets that were not processed because of failure to - find the IP control block associated with the packet.
-
-
-
-
-
num_outbound_skipped_pkts_inpcb
-
Number of outbound packets that were not processed because of failure to - find the IP control block associated with the packet.
-
-
-
-
-
total_skipped_tcp_pkts
-
The summation of all skipped packet counters.
-
-
-
-
-
flow_list
-
A CSV list of TCP flows that triggered data log messages to be generated - since the module was loaded. Each flow entry in the CSV list is formatted - as "local_ip;local_port-foreign_ip;foreign_port". If there are - no entries in the list (i.e., no data log messages were generated), the - value will be blank. If there is at least one entry in the list, a - trailing comma will always be present.
-
-
-

The total number of data log messages found in the log file for a - module enable/disable cycle should equate to total_tcp_pkts - - total_skipped_tcp_pkts.

-
-
-
-

-

SIFTR hooks into the network stack using - the pfil(9) interface. In its current incarnation, it - hooks into the AF_INET/AF_INET6 (IPv4/IPv6) pfil(9) - filtering points, which means it sees packets at the IP layer of the network - stack. This means that TCP packets inbound to the stack are intercepted - before they have been processed by the TCP layer. Packets outbound from the - stack are intercepted after they have been processed by the TCP layer.

-

The diagram below illustrates how SIFTR - inserts itself into the stack.

-
-
----------------------------------
-           Upper Layers
-----------------------------------
-    ^                       |
-    |                       |
-    |                       |
-    |                       v
- TCP in                  TCP out
-----------------------------------
-    ^                      |
-    |________     _________|
-            |     |
-            |     v
-           ---------
-           | SIFTR |
-           ---------
-            ^     |
-    ________|     |__________
-    |                       |
-    |                       v
-IPv{4/6} in            IPv{4/6} out
-----------------------------------
-    ^                       |
-    |                       |
-    |                       v
-Layer 2 in             Layer 2 out
-----------------------------------
-          Physical Layer
-----------------------------------
-
-

SIFTR uses the alq(9) - interface to manage writing data to disk.

-

At first glance, you might mistakenly think that - SIFTR extracts information from individual TCP - packets. This is not the case. SIFTR uses TCP packet - events (inbound and outbound) for each TCP flow originating from the system - to trigger a dump of the state of the TCP control block for that flow. With - the PPL set to 1, we are in effect sampling each TCP flow's control block - state as frequently as flow packets enter/leave the system. For example, - setting PPL to 2 halves the sampling rate i.e., every second flow packet - (inbound OR outbound) causes a dump of the control block state.

-

The distinction between interrogating individual packets versus - interrogating the control block is important, because - SIFTR does not remove the need for packet capturing - tools like tcpdump(1). SIFTR - allows you to correlate and observe the cause-and-affect relationship - between what you see on the wire (captured using a tool like - tcpdump(1)) and changes in the TCP control block - corresponding to the flow of interest. It is therefore useful to use - SIFTR and a tool like tcpdump(1) - to gather the necessary data to piece together the complete picture. Use of - either tool on its own will not be able to provide all of the necessary - data.

-

As a result of needing to interrogate the TCP control block, - certain packets during the lifecycle of a connection are unable to trigger a - SIFTR log message. The initial handshake takes place - without the existence of a control block or the complete initialization of - the control block, and the final ACK is exchanged when the connection is in - the TIMEWAIT state.

-

SIFTR was designed to minimise the delay - introduced to packets traversing the network stack. This design called for a - highly optimised and minimal hook function that extracted the minimal - details necessary whilst holding the packet up, and passing these details to - another thread for actual processing and logging.

-

This multithreaded design does introduce some contention issues - when accessing the data structure shared between the threads of operation. - When the hook function tries to place details in the structure, it must - first acquire an exclusive lock. Likewise, when the processing thread tries - to read details from the structure, it must also acquire an exclusive lock - to do so. If one thread holds the lock, the other must wait before it can - obtain it. This does introduce some additional bounded delay into the - kernel's packet processing code path.

-

In some cases (e.g., low memory, connection termination), TCP - packets that enter the SIFTR - pfil(9) hook function will not trigger a log message to be - generated. SIFTR refers to this outcome as a - "skipped packet". Note that SIFTR always - ensures that packets are allowed to continue through the stack, even if they - could not successfully trigger a data log message. - SIFTR will therefore not introduce any packet loss - for TCP/IP packets traversing the network stack.

-
-

-

The behaviour of a log file path change whilst the module is - enabled is as follows:

-
    -
  1. Attempt to open the new file path for writing. If this fails, the path - change will fail and the existing path will continue to be used.
    2. -
  2. Assuming the new path is valid and opened successfully: -
      -
    • Flush all pending log messages to the old file path.
      • -
    • Close the old file path.
      • -
    • Switch the active log file pointer to point at the new file path.
      • -
    • Commence logging to the new file.
      • -
    -
    3. -
-

During the time between the flush of pending log messages to the - old file and commencing logging to the new file, new log messages will still - be generated and buffered. As soon as the new file path is ready for - writing, the accumulated log messages will be written out to the file.

-
-
-
-

-

To enable the module's operations, run the following command as - root: sysctl net.inet.siftr.enabled=1

-

To change the granularity of log messages such that 1 log message - is generated for every 10 TCP packets per connection, run the following - command as root: sysctl net.inet.siftr.ppl=10

-

To change the log file location to /tmp/siftr.log, run the - following command as root: sysctl net.inet.siftr.logfile=/tmp/siftr.log

-
-
-

-

tcpdump(1), tcp(4), - sysctl(8), alq(9), - pfil(9)

-
-
-

-

Development of this software was made possible in part by grants - from the Cisco University Research Program Fund at Community Foundation - Silicon Valley, and the FreeBSD Foundation.

-
-
-

-

SIFTR first appeared in - FreeBSD 7.4 and FreeBSD - 8.2.

-

SIFTR was first released in 2007 by - Lawrence Stewart and James Healy whilst working on the NewTCP research - project at Swinburne University of Technology's Centre for Advanced Internet - Architectures, Melbourne, Australia, which was made possible in part by a - grant from the Cisco University Research Program Fund at Community - Foundation Silicon Valley. More details are available at:

-

http://caia.swin.edu.au/urp/newtcp/

-

Work on SIFTR v1.2.x was sponsored by the - FreeBSD Foundation as part of the "Enhancing the FreeBSD TCP - Implementation" project 2008-2009. More details are available at:

-

https://www.freebsdfoundation.org/

-

http://caia.swin.edu.au/freebsd/etcp09/

-
-
-

-

SIFTR was written by - Lawrence Stewart - <lstewart@FreeBSD.org> - and James Healy - <jimmy@deefa.com>.

-

This manual page was written by Lawrence - Stewart - <lstewart@FreeBSD.org>.

-
-
-

-

Current known limitations and any relevant workarounds are - outlined below:

-
    -
  • The internal queue used to pass information between the threads of - operation is currently unbounded. This allows - SIFTR to cope with bursty network traffic, but - sustained high packet-per-second traffic can cause exhaustion of kernel - memory if the processing thread cannot keep up with the packet rate.
    • -
  • If using SIFTR on a machine that is also running - other modules utilising the pfil(9) framework e.g. - dummynet(4), ipfw(8), - pf(4), the order in which you load the modules is - important. You should kldload the other modules first, as this will ensure - TCP packets undergo any necessary manipulations before - SIFTR "sees" and processes them.
    • -
  • There is a known, harmless lock order reversal warning between the - pfil(9) mutex and tcbinfo TCP lock reported by - witness(4) when SIFTR is enabled - in a kernel compiled with witness(4) support.
    • -
  • There is no way to filter which TCP flows you wish to capture data for. - Post processing is required to separate out data belonging to particular - flows of interest.
    • -
  • The module does not detect deletion of the log file path. New log messages - will simply be lost if the log file being used by - SIFTR is deleted whilst the module is set to use - the file. Switching to a new log file using the - net.inet.siftr.logfile variable will create the new file - and allow log messages to begin being written to disk again. The new log - file path must differ from the path to the deleted file.
    • -
  • The hash table used within the code is sized to hold 65536 flows. This is - not a hard limit, because chaining is used to handle collisions within the - hash table structure. However, we suspect (based on analogies with other - hash table performance data) that the hash table look up performance (and - therefore the module's packet processing performance) will degrade in an - exponential manner as the number of unique flows handled in a module - enable/disable cycle approaches and surpasses 65536.
    • -
  • There is no garbage collection performed on the flow hash table. The only - way currently to flush it is to disable - SIFTR.
    • -
  • The PPL variable applies to packets that make it into the processing - thread, not total packets received in the hook function. Packets are - skipped before the PPL variable is applied, which means there may be a - slight discrepancy in the triggering of log messages. For example, if PPL - was set to 10, and the 8th packet since the last log message is skipped, - the 11th packet will actually trigger the log message to be generated. - This is discussed in greater depth in CAIA technical report 070824A.
    • -
  • At the time of writing, there was no simple way to hook into the TCP layer - to intercept packets. SIFTR's use of IP layer hook - points means all IP traffic will be processed by the - SIFTR pfil(9) hook function, - which introduces minor, but nonetheless unnecessary packet delay and - processing overhead on the system for non-TCP packets as well. Hooking in - at the IP layer is also not ideal from the data gathering point of view. - Packets traversing up the stack will be intercepted and cause a log - message generation BEFORE they have been processed by the TCP layer, which - means we cannot observe the cause-and-affect relationship between inbound - events and the corresponding TCP control block as precisely as could be. - Ideally, SIFTR should intercept packets after they - have been processed by the TCP layer i.e. intercept packets coming up the - stack after they have been processed by - tcp_input(), and intercept packets coming down the - stack after they have been processed by - tcp_output(). The current code still gives - satisfactory granularity though, as inbound events tend to trigger - outbound events, allowing the cause-and-effect to be observed indirectly - by capturing the state on outbound events as well.
    • -
  • The "inflight bytes" value logged by - SIFTR does not take into account bytes that have - been SACK'ed by the receiving host.
    • -
-
-
- - - - - -
May 29, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/siis.4 3.html b/static/freebsd/man4/siis.4 3.html deleted file mode 100644 index 47115bd0..00000000 --- a/static/freebsd/man4/siis.4 3.html +++ /dev/null @@ -1,116 +0,0 @@ - - - - - - -
SIIS(4)Device Drivers ManualSIIS(4)
-
-
-

-

siis — - SiliconImage Serial ATA Host Controller driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device siis
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
siis_load="YES"
-
-

The following tunables are settable from the - loader(8):

-
-
hint.siis.X.msi
-
controls Message Signaled Interrupts (MSI) usage by the specified - controller.
-
hint.siisch.X.pm_level
-
controls SATA interface Power Management for the specified channel, - allowing some power to be saved at the cost of additional command latency. - Possible values: -
-
-
0
-
interface Power Management is disabled (default);
-
1
-
device is allowed to initiate PM state change, host is passive.
-
-
-

Note that interface Power Management is not compatible with - device presence detection. A manual bus reset is needed on device - hot-plug.

-
-
hint.siisch.X.sata_rev
-
setting to nonzero value limits maximum SATA revision (speed). Values 1, 2 - and 3 are respectively 1.5, 3 and 6Gbps.
-
-
-
-

-

This driver provides the CAM(4) subsystem with - native access to the SATA ports of controller. Each SATA port is represented - to CAM as a separate bus with 16 targets. Most of the bus-management details - are handled by the SATA-specific transport of CAM. Connected ATA disks are - handled by the ATA protocol disk peripheral driver ada(4). - ATAPI devices are handled by the SCSI protocol peripheral drivers - cd(4), da(4), sa(4), - etc.

-

Driver features include support for Serial ATA and ATAPI devices, - Port Multipliers (including FIS-based switching), hardware command queues - (31 command per port), Native Command Queuing, SATA interface Power - Management, device hot-plug and Message Signaled Interrupts.

-

The activity LEDs of the adapters supported by the - siis driver can be controlled via the - led(4) API for localization or status reporting - purposes.

-
-
-

-

The siis driver supports the following - controller chips:

-

-
    -
  • SiI3124 (PCI-X 133MHz/64bit, 4 ports)
    • -
  • SiI3131 (PCIe 1.0 x1, 1 port)
    • -
  • SiI3132 (PCIe 1.0 x1, 2 ports)
    • -
  • SiI3531 (PCIe 1.0 x1, 1 port)
    • -
-
-
-

-
-
/dev/led/siisch*
-
identification LED device nodes
-
-
-
-

-

ada(4), ata(4), - cam(4), cd(4), da(4), - led(4), sa(4)

-
-
-

-

The siis driver first appeared in - FreeBSD 8.0.

-
-
-

-

Alexander Motin - <mav@FreeBSD.org>

-
-
- - - - - -
March 23, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/simplebus.4 4.html b/static/freebsd/man4/simplebus.4 4.html deleted file mode 100644 index 0d4395c0..00000000 --- a/static/freebsd/man4/simplebus.4 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
SIMPLEBUS(4)Device Drivers ManualSIMPLEBUS(4)
-
-
-

-

simplebus — ePAPR - simple-bus driver

-
-
-

-

options FDT

-
-
-

-

This bus driver is dedicated for the - simple-bus node of a flattened device tree compliant - with the ePAPR specification.

-

The simplebus entity does not represent - any physical element by itself, it is rather an umbrella node grouping - integrated on-chip peripherals like interrupt controller, connectivity - controllers, accelerating engines and so on.

-

The driver is generic and common for all flattened device tree - nodes claiming simple-bus compatibility. It iterates - over direct descendants of the simple-bus node, - instantiates newbus children and assigns resources to them, based on the - configuration data retrieved from the nodes properties in - fdt(4).

-

Note the simplebus does not manage device - resources and passes through any requests to the fdtbus(4) - layer.

-
-
-

-

fdt(4), fdtbus(4), - openfirm(4)

-
-
-

-

Power.org Standard for Embedded Power Architecture Platform - Requirements (ePAPR).

-
-
-

-

The simplebus support first appeared in - FreeBSD 9.0.

-
-
-

-

The simplebus support was developed by - Semihalf under sponsorship from the FreeBSD Foundation. This manual page was - written by Rafal Jaworowski.

-
-
- - - - - -
July 12, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/sis.4 3.html b/static/freebsd/man4/sis.4 3.html deleted file mode 100644 index a40d90ad..00000000 --- a/static/freebsd/man4/sis.4 3.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - -
SIS(4)Device Drivers ManualSIS(4)
-
-
-

-

sis — SiS 900, SiS - 7016 and NS DP83815/DP83816 Fast Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device sis
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_sis_load="YES"
-
-
-
-

-

The sis driver provides support for PCI - Ethernet adapters and embedded controllers based on the Silicon Integrated - Systems SiS 900 and SiS 7016 Fast Ethernet controller chips.

-

This driver also supports adapters based on the National - Semiconductor DP83815 (MacPhyter) and DP83816 PCI Ethernet controller - chip.

-

The SiS 900 is a 100Mbps Ethernet MAC and MII-compliant - transceiver in a single package. It uses a bus master DMA and a - scatter/gather descriptor scheme. The SiS 7016 is similar to the SiS 900 - except that it has no internal PHY, requiring instead an external - transceiver to be attached to its MII interface. The SiS 900 and SiS 7016 - both have a 128-bit multicast hash filter and a single perfect filter entry - for the station address.

-

The NS DP83815 is also a 100Mbps Ethernet MAC with integrated PHY. - The NatSemi chip and the SiS 900 share many of the same features and a - fairly similar programming interface, hence both chips are supported by the - same driver.

-

The sis driver supports the following - media types:

-
-
autoselect
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
10baseT/UTP
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - ‘full-duplex’ or ‘half-duplex’ modes.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - ‘full-duplex’ or ‘half-duplex’ modes.
-
-

The sis driver supports the following - media options:

-
-
full-duplex
-
Force full duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The sis driver supports Silicon Integrated - Systems SiS 900 and SiS 7016 based Fast Ethernet adapters and embedded - controllers, as well as Fast Ethernet adapters based on the National - Semiconductor DP83815 (MacPhyter) and DP83816 chips. Supported adapters - include:

-

-
    -
  • @Nifty FNECHARD IFC USUP-TX
    • -
  • MELCO LGY-PCI-TXC
    • -
  • Netgear FA311-TX (DP83815)
    • -
  • Netgear FA312-TX (DP83815)
    • -
  • SiS 630, 635, and 735 motherboard chipsets
    • -
  • Soekris Engineering net45xx, net48xx, lan1621, and lan1641
    • -
-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.sis.%unit.manual_pad
-
This variable controls how to pad short frames for DP83815/DP83816 - controllers on the specified device. DP83815/DP83816 controllers are known - to pad 0xFF for short frames which is violation of RFC 1042. Set this - variable to a non-zero value to let driver manually pad each short frame - with zeros at the cost of extra CPU cycles. The default value is 0 to let - hardware perform automatic padding.
-
-
-
-

-
-
sis%d: couldn't map ports/memory
-
A fatal initialization error has occurred.
-
sis%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
sis%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (e.g. a cable fault).
-
sis%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
sis%d: no memory for tx list
-
The driver failed to allocate an mbuf for the transmitter ring when - allocating a pad buffer or collapsing an mbuf chain into a cluster.
-
sis%d: chip is in D3 power state -- setting to D0
-
This message applies only to adapters which support power management. Some - operating systems place the controller in low power mode when shutting - down, and some PCI BIOSes fail to bring the chip out of this state before - configuring it. The controller loses all of its PCI configuration in the - D3 state, so if the BIOS does not set it back to full power mode in time, - it will not be able to configure it correctly. The driver tries to detect - this condition and bring the adapter back to the D0 (full power) state, - but this may not be enough to return the driver to a fully operational - condition. If you see this message at boot time and the driver fails to - attach the device as a network interface, you will have to perform a warm - boot to have the device properly configured. -

Note that this condition only occurs when warm booting from - another operating system. If you power down your system prior to booting - FreeBSD, the card should be configured - correctly.

-
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-

SiS 900 and SiS 7016 - datasheets, - https://www.sis.com.tw.

-

NatSemi DP83815 - datasheet.

-
-
-

-

The sis device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The sis driver was written by - Bill Paul - <wpaul@ee.columbia.edu>.

-
-
- - - - - -
September 2, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/sk.4 3.html b/static/freebsd/man4/sk.4 3.html deleted file mode 100644 index 82135abd..00000000 --- a/static/freebsd/man4/sk.4 3.html +++ /dev/null @@ -1,182 +0,0 @@ - - - - - - -
SK(4)Device Drivers ManualSK(4)
-
-
-

-

sk — SysKonnect - SK-984x and SK-982x PCI Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device sk
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_sk_load="YES"
-
-
-
-

-

The sk driver provides support for the - SysKonnect SK-984x and SK-982x series PCI Gigabit Ethernet adapters.

-

The SysKonnect adapters consist of two main components: the XaQti - Corp. XMAC II gigabit MAC and the SysKonnect GEnesis controller ASIC. The - XMAC provides the gigabit MAC and PHY support while the GEnesis provides an - interface to the PCI bus, DMA support, packet buffering and arbitration. The - GEnesis can control up to two XMACs simultaneously, allowing dual-port NIC - configurations.

-

The SK-982x 1000baseT adapters also include a Broadcom BCM5400 - 1000baseTX PHY which is used in place of the XMAC's internal PHY. The - Broadcom PHY is connected to the XMAC via its GMII port.

-

The sk driver configures dual port - SysKonnect adapters such that each XMAC is treated as a separate logical - network interface. Both ports can operate independently of each other and - can be connected to separate networks. The SysKonnect driver software - currently only uses the second port on dual port adapters for failover - purposes: if the link on the primary port fails, the SysKonnect driver will - automatically switch traffic onto the second port.

-

Also supported is the Marvell Semiconductor 88E100* gigabit - PHY.

-

The XaQti XMAC II supports full and half duplex operation with - autonegotiation. The XMAC also supports unlimited frame sizes. Support for - jumbo frames is provided via the interface MTU setting. Selecting an MTU - larger than 1500 bytes with the ifconfig(8) utility - configures the adapter to receive and transmit jumbo frames. Using jumbo - frames can greatly improve performance for certain tasks, such as file - transfers and data streaming.

-

The sk driver supports the following media - types:

-
-
autoselect
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file.
-
1000baseTX
-
Set 1000baseTX operation over twisted pair. This is only available for - SK-982x series adapters with 1000baseT ports. Both - full-duplex and half-duplex - modes are supported.
-
1000baseSX
-
Set 1000Mbps (Gigabit Ethernet) operation. Both - full-duplex and half-duplex - modes are supported.
-
-

The sk driver supports the following media - options:

-
-
full-duplex
-
Force full duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

Adapters supported by the sk driver - include:

-

-
    -
  • 3Com 3C940 single port, 1000baseT adapter
    • -
  • 3Com 3C2000-T single port, 1000baseT adapter
    • -
  • Belkin F5D5005 single port, 1000baseT adapter
    • -
  • D-Link DGE-530T single port, 1000baseT adapter
    • -
  • Linksys (revision 2) single port, 1000baseT adapter
    • -
  • SK-9521 SK-NET GE-T single port, 1000baseT adapter
    • -
  • SK-9821 SK-NET GE-T single port, 1000baseT adapter
    • -
  • SK-9822 SK-NET GE-T dual port, 1000baseT adapter
    • -
  • SK-9841 SK-NET GE-LX single port, single mode fiber adapter
    • -
  • SK-9842 SK-NET GE-LX dual port, single mode fiber adapter
    • -
  • SK-9843 SK-NET GE-SX single port, multimode fiber adapter
    • -
  • SK-9844 SK-NET GE-SX dual port, multimode fiber adapter
    • -
  • SMC 9452TX single port, 1000baseT adapter
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.skc.jumbo_disable
-
Disable jumbo frame support. Systems with less memory can set it to a - non-zero value to save memory. The default value is 0.
-
-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.skc.%d.int_mod
-
This variable controls interrupt moderation. The accepted range is 10 to - 10000. The default value is 100 microseconds. The interface has to be - brought down and up again before a change takes effect.
-
-
-
-

-
-
sk%d: couldn't map memory
-
A fatal initialization error has occurred.
-
sk%d: couldn't map ports
-
A fatal initialization error has occurred.
-
sk%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
sk%d: no memory for softc struct!
-
The driver failed to allocate memory for per-device instance information - during initialization.
-
sk%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
sk%d: no memory for jumbo buffers!
-
The driver failed to allocate memory for jumbo frames during - initialization.
-
sk%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-

XaQti XMAC II datasheet, - https://people.freebsd.org/~wpaul/SysKonnect/xmacii_datasheet_rev_c_9-29.pdf.

-

SysKonnect GEnesis programming - manual, - http://www.syskonnect.com.

-
-
-

-

The sk device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The sk driver was written by - Bill Paul - <wpaul@ctr.columbia.edu>.

-
-
- - - - - -
August 29, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/smartpqi.4 3.html b/static/freebsd/man4/smartpqi.4 3.html deleted file mode 100644 index b0649796..00000000 --- a/static/freebsd/man4/smartpqi.4 3.html +++ /dev/null @@ -1,198 +0,0 @@ - - - - - - -
SMARTPQI(4)Device Drivers Manual (amd64)SMARTPQI(4)
-
-
-

-

smartpqi — - Microchip Smart Storage SCSI driver

-
-
-

-

To compile this driver into the kernel, place these lines in the - kernel configuration file:

-
device pci -
-device scbus -
-device smartpqi
-

The driver can be loaded as a module at boot time by placing this - line in loader.conf(5):

-
-
smartpqi_load="YES"
-
-
-
-

-

The smartpqi driver provides support for - Microchip Technology Inc. / Adaptec SmartRaid and SmartHBA SATA/SAS/NVMe - PCIe controllers

-
-
-

-

Controllers supported by the smartpqi - driver include, but not limited to:

-

-
    -
  • HPE Gen10 Smart Array Controller Family
    • -
  • Adaptec SmartRaid and SmartHBA Controllers
    • -
  • OEM Controllers based on the Microchip Technology Inc. SmartROC and - SmartIOC Chipsets
    • -
-
-
-

-

Driver diagnostic printing is controlled in - loader.conf(5) by using the global - hw.smartpqi.debug_level tunable.

-

The debug_level variable is set with an - integer value. The default value is 0x0060 (warn && error).

-

The following levels are available:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x0001initSystem initialization operations
0x0002infoBasic information
0x0004functionUsed to show function entry and exit
0x0008ioLogging data from controller
0x0010discoveryDevice discovery
0x0020warningOperational warnings
0x0040errorParameter errors and programming bugs
0x0080noteMore detailed information
-
-
-

-

The following tunable values can be set in - /boot/device.hints to control the behavior of the - smartpqi driver. These hints are specified as:

-
-
hint.smartpqi.<unit>.<variable>=<value>
-
-

The supported variables are:

-
-
stream_disable
-
If set to 0, disables Stream Detection. -

Default is (enabled).

-
-
sata_unique_wwn_disable
-
If set to 0, disables SATA Unique World Wide Number. -

Default is (enabled).

-
-
aio_raid1_write_disable
-
If set to 0, disables acceleration of RAID1 writes -

Default is (enabled).

-
-
aio_raid5_write_disable
-
If set to 0, disables acceleration of RAID5 writes -

Default is (enabled).

-
-
aio_raid6_write_disable
-
If set to 0, disables acceleration of RAID6 writes -

Default is (enabled).

-
-
queue_depth
-
Sets queue depth for the controller. If the queue depth value is greater - than the maximum supported queue size of the driver or controller, it will - be set to the lowest size. If the queue depth value is lower than the - minimum queue depth then this will be set to the minimum queue depth. -

Default is driver-determined.

-
-
sg_count
-
Sets the scatter gather (sg) count. If this sg count is greater than - maximum sg count it will be set to the maximum sg count. If this sg count - is less than minimum sg count it will be set to the minimum sg count. -

Default is driver-determined.

-
-
-

For example, to disable Stream Detection on the first controller, - add the following line to /boot/device.hints:

-
-
hint.smartpqi.0.stream_disable="0"
-
-
-
-

-
-
/dev/smartpqi?
-
smartpqi management interface
-
-
-
-

-
-

-

To configure a Microchip Smart Storage controller, refer to the - User Guide for the controller, which can be found by searching for the - specific controller at https://www.microchip.com/design-centers/storage

-
-
-
-

-

kld(4), linux(4), - pass(4), scsi(4), - xpt(4), loader.conf(5), - camcontrol(8), kldload(8)

-
-
-

-

The smartpqi driver first appeared in - FreeBSD 11.1.

-
-
-

-

John Hall - ⟨john.hall@microchip.com⟩

-
-
-

-

The controller is not actually paused on suspend/resume.

-
-
- - - - - -
August 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/smb.4 3.html b/static/freebsd/man4/smb.4 3.html deleted file mode 100644 index de9aba1e..00000000 --- a/static/freebsd/man4/smb.4 3.html +++ /dev/null @@ -1,185 +0,0 @@ - - - - - - -
SMB(4)Device Drivers ManualSMB(4)
-
-
-

-

smb — System - Management Bus (SMBus) generic I/O device driver

-
-
-

-

device smb

-
-
-

-

The - - character device driver provides generic I/O to any - smbus(4) instance. To control SMB devices, use - /dev/smb? with the ioctls described below. Any of - these ioctl commands takes a pointer to struct smbcmd - as its argument.

-
-
#include <sys/types.h>
-
-struct smbcmd {
-	u_char cmd;
-	u_char reserved;
-	u_short op;
-	union {
-		char    byte;
-		char    buf[2];
-		short   word;
-	} wdata;
-	union {
-		char    byte;
-		char    buf[2];
-		short   word;
-	} rdata;
-	int  slave;
-	char *wbuf;     /* use wdata if NULL */
-	int  wcount;
-	char *rbuf;     /* use rdata if NULL */
-	int  rcount;
-};
-
-

The slave field is always used, and provides - the address of the SMBus slave device. The slave address is specified in the - seven most significant bits (i.e., “left-justified”). The - least significant bit of the slave address must be zero.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-
- does not transfer any data. It just issues the device address with write - intent to the bus.
- does not transfer any data. It just issues the device address with read - intent to the bus.
- sends the byte provided in cmd to the device.
- reads a single byte from the device which is returned in - cmd.
- first sends the byte from cmd to the device, - followed by the byte given in wdata.byte.
- first sends the byte from cmd to the device, - followed by the word given in wdata.word. Note that - the SMBus byte-order is little-endian by definition.
- first sends the byte from cmd to the device, then - reads one byte of data from the device. Returned data is stored in - rdata.byte.
- first sends the byte from cmd to the device, then - reads one word of data from the device. Returned data is stored in - rdata.word.
- first sends the byte from cmd to the device, - followed by the word provided in wdata.word. It then - reads one word of data from the device and returns it in - rdata.word.
- first sends the byte from cmd to the device, then - the byte from wcount followed by - wcount bytes of data that are taken from the buffer - pointed to by wbuf. The SMBus specification mandates - that no more than 32 bytes of data can be transferred in a single block - read or write command. This value can be read from the constant - SMB_MAXBLOCKSIZE.
- first sends the byte from cmd to the device, then - reads a count of data bytes that the device is going to provide and then - reads that many bytes. The count is returned in - rcount. The data is returned in the buffer pointed - to by rbuf.
-

The read(2) and write(2) - system calls are not implemented by this driver.

-
-
-

-

The ioctl(2) commands can cause the following - driver-specific errors:

-
-
[]
-
Device did not respond to selection.
-
[]
-
Device still in use.
-
[]
-
Operation not supported by device (not supposed to happen).
-
[]
-
General argument error.
-
[]
-
SMBus transaction timed out.
-
-
-
-

-

ioctl(2), smbus(4)

-
-
-

-

The smb manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu and extended by -
- Michael Gmelin ⟨freebsd@grem.de⟩.

-
-
- - - - - -
April 25, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/smbfs.4 3.html b/static/freebsd/man4/smbfs.4 3.html deleted file mode 100644 index 706bf4e3..00000000 --- a/static/freebsd/man4/smbfs.4 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
SMBFS(4)Device Drivers ManualSMBFS(4)
-
-
-

-

smbfs — server - message block (SMB1/CIFS) file system

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
option NETSMB
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
smbfs_load="YES"
-
-
-
-

-

The SMB driver is an implementation of the CIFS (Common Internet - Filesystem) network protocol.

-

-
The smbfs filesystem driver supports - only the obsolete SMBv1 protocol. smbfs has known bugs - and likely has security vulnerabilities. smbfs and - userspace counterparts smbutil(1) and - mount_smbfs(8) may be removed from a future version of - FreeBSD. Users are advised to evaluate the - filesystems/smbnetfs port instead.
-
-
-

-

smbutil(1), mount_smbfs(8)

-
-
-

-

Common Internet File System - (CIFS) Protocol, MS-CIFS, - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/, - December 2018.

-

I. Heizer, - P. Leach, and D. Perry, - Common Internet File System Protocol (CIFS/1.0), - https://tools.ietf.org/html/draft-heizer-cifs-v1-spec-00, - June 13, 1996.

-
-
-

-

The smbfs device driver first appeared in - FreeBSD 4.4.

-
-
-

-

The smbfs device driver was written by - Boris Popov - <bp@FreeBSD.org>. The - manual page was contributed by Gordon Bergling - <gbe@FreeBSD.org>.

-
-
- - - - - -
April 6, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/smbios.4 4.html b/static/freebsd/man4/smbios.4 4.html deleted file mode 100644 index a6f3510e..00000000 --- a/static/freebsd/man4/smbios.4 4.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
SMBIOS(4)Device Drivers ManualSMBIOS(4)
-
-
-

-

smbios — System - Management BIOS

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device smbios
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
smbios_load="YES"
-
-
-
-

-

The System Management BIOS (SMBIOS) describes hardware - components.

-
-
-

-

efi(8)

-

System Management BIOS (SMBIOS) - Reference Specification, DMTF - DSP0134.

-
-
-

-

The smbios device driver first appeared in - FreeBSD 4.8.

-
-
-

-

The smbios device driver was written by - Matthew N. Dodd - <winter@jurai.net>. - This manual page was written by -
- Gordon Bergling - <gbe@FreeBSD.org>.

-
-
- - - - - -
April 22, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/smbus.4 3.html b/static/freebsd/man4/smbus.4 3.html deleted file mode 100644 index 5a2484a5..00000000 --- a/static/freebsd/man4/smbus.4 3.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
SMBUS(4)Device Drivers ManualSMBUS(4)
-
-
-

-

smbus — System - Management Bus

-
-
-

-

device smbus

-

-
- device iicsmb

-
-
-

-

The - - system provides a uniform, modular and architecture-independent system for - the implementation of drivers to control various SMB devices and to utilize - different SMB controllers (I2C, PIIX4, vm86...).

-
-
-

-

The - is a two-wire interface through which simple - power-related chips can communicate with rest of the system. It uses I2C as - its backbone (see iicbus(4)).

-

A system using SMB passes messages to and from devices instead of - tripping individual control lines.

-

With the SMBus, a device can provide manufacturer information, - tell the system what its model/part number is, save its state for a suspend - event, report different types of errors, accept control parameters, and - return its status.

-

The SMBus may share the same host device and physical bus as - ACCESS bus components provided that an appropriate electrical bridge is - provided between the internal SMB devices and external ACCESS bus - devices.

-
-
-

-

iicbus(4), iicsmb(4), - smb(4), smbmsg(8)

-

The SMBus specification, - http://www.smbus.org/specs/.

-
-
-

-

The smbus manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page was written by Nicolas - Souchu.

-
-
- - - - - -
March 7, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/smp.4 3.html b/static/freebsd/man4/smp.4 3.html deleted file mode 100644 index 9fdd1f8b..00000000 --- a/static/freebsd/man4/smp.4 3.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - -
SMP(4)Device Drivers ManualSMP(4)
-
-
-

-

SMP — description - of the FreeBSD Symmetric Multi-Processor kernel

-
-
-

-

options SMP

-
-
-

-

The SMP kernel implements symmetric - multi-processor support.

-

SMP support can be disabled by setting the - loader tunable kern.smp.disabled to 1.

-

The number of CPUs detected by the system is available in the - read-only sysctl variable hw.ncpu.

-

The number of online threads per CPU core is available in the - read-only sysctl variable kern.smp.threads_per_core. - The number of physical CPU cores detected by the system is available in the - read-only sysctl variable kern.smp.cores.

-

FreeBSD allows specific CPUs on a - multi-processor system to be disabled. This can be done using the - hint.lapic.X.disabled tunable, where X is the APIC ID - of a CPU. Setting this tunable to 1 will result in the corresponding CPU - being disabled.

-

FreeBSD supports simultaneous - multithreading on x86 and powerpc platforms. On x86, the logical CPUs can be - disabled by setting the machdep.hyperthreading_allowed - tunable to zero.

-

The sched_ule(4) scheduler implements CPU - topology detection and adjusts the scheduling algorithms to make better use - of modern multi-core CPUs. The sysctl variable - kern.sched.topology_spec reflects the detected CPU - hardware in a parsable XML format. The top level XML tag is <groups>, - which encloses one or more <group> tags containing data about - individual CPU groups. A CPU group contains CPUs that are detected to be - "close" together, usually by being cores in a single multi-core - processor. Attributes available in a <group> tag are - "level", corresponding to the nesting level of the CPU group and - "cache-level", corresponding to the level of CPU caches shared by - the CPUs in the group. The <group> tag contains the <cpu> and - <flags> tags. The <cpu> tag describes CPUs in the group. Its - attributes are "count", corresponding to the number of CPUs in the - group and "mask", corresponding to the integer binary mask in - which each bit position set to 1 signifies a CPU belonging to the group. The - contents (CDATA) of the <cpu> tag is the comma-delimited list of CPU - indexes (derived from the "mask" attribute). The <flags> tag - contains special tags (if any) describing the relation of the CPUs in the - group. The possible flags are currently "HTT" and "SMT", - corresponding to the various implementations of hardware multithreading. An - example topology_spec output for a system consisting of two quad-core - processors is:

-
-
<groups>
-  <group level="1" cache-level="0">
-    <cpu count="8" mask="0xff">0, 1, 2, 3, 4, 5, 6, 7</cpu>
-    <flags></flags>
-    <children>
-      <group level="2" cache-level="0">
-        <cpu count="4" mask="0xf">0, 1, 2, 3</cpu>
-        <flags></flags>
-      </group>
-      <group level="2" cache-level="0">
-        <cpu count="4" mask="0xf0">4, 5, 6, 7</cpu>
-        <flags></flags>
-      </group>
-    </children>
-  </group>
-</groups>
-
-

This information is used internally by the kernel to schedule - related tasks on CPUs that are closely grouped together.

-
-
-

-

Support for multi-processor systems is present for all Tier-1 and - Tier-2 architectures on FreeBSD. Currently, this - includes x86, powerpc, mips, arm and arm64. Support is enabled using - options SMP. It is permissible to use the SMP kernel - configuration on non-SMP hardware.

-
-
-

-

For i386 systems, the SMP kernel supports - motherboards that follow the Intel MP specification, version 1.4. In - addition to options SMP, i386 also requires - device apic. The mptable(1) - command may be used to view the status of multi-processor support.

-
-
-

-

cpuset(1), mptable(1), - sched_4bsd(4), sched_ule(4), - loader(8), sysctl(8), - condvar(9), msleep(9), - mtx_pool(9), mutex(9), - rwlock(9), sema(9), - sx(9)

-
-
-

-

The SMP kernel's early history is not - (properly) recorded. It was developed in a separate CVS branch until April - 26, 1997, at which point it was merged into 3.0-current. By this date - 3.0-current had already been merged with Lite2 kernel code.

-

FreeBSD 5.0 introduced support for a host - of new synchronization primitives, and a move towards fine-grained kernel - locking rather than reliance on a Giant kernel lock. The SMPng Project - relied heavily on the support of BSDi, who provided reference source code - from the fine-grained SMP implementation found in - BSD/OS.

-

FreeBSD 5.0 also introduced support for - SMP on the sparc64 architecture.

-
-
-

-

Steve Passe - <fsmp@FreeBSD.org>

-
-
-

-

The kern.smp.threads_per_core and - kern.smp.cores sysctl variables are provided as a - best-effort guess. If an architecture or platform adds SMT and - FreeBSD has not yet implemented detection, the - reported values may be inaccurate. In this case, - kern.smp.threads_per_core will report - 1 and kern.smp.cores will - report the same value as hw.ncpu.

-
-
- - - - - -
January 4, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/smsc.4 4.html b/static/freebsd/man4/smsc.4 4.html deleted file mode 100644 index 043ffcf8..00000000 --- a/static/freebsd/man4/smsc.4 4.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
SMSC(4)Device Drivers ManualSMSC(4)
-
-
-

-

smsc — USB - Microchip LAN9xxx Fast Ethernet driver

-
-
-

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
if_smsc_load="YES"
-
-

Alternatively, to compile this driver into the kernel, place the - following lines in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device smsc
-
-
-

-

The smsc device driver provides support - for USB Fast Ethernet adapters based on the Microchip (formerly SMSC) - LAN9xxx chipsets.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The following devices are supported by the - smsc driver:

-

-
    -
  • LAN9500, LAN9500A, LAN9505 and LAN9505A based Ethernet adapters
    • -
  • LAN89530, LAN9530 and LAN9730 based Ethernet adapters
    • -
  • LAN951x Ethernet adapters with integrated USB hub
    • -
-
-
-

-

arp(4), intro(4), - miibus(4), netintro(4), - usb(4), ifconfig(8)

-
-
-

-

The smsc device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The smsc driver was written by - Ben Gray - <bgray@FreeBSD.org>.

-
-
- - - - - -
May 7, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_als4000.4 4.html b/static/freebsd/man4/snd_als4000.4 4.html deleted file mode 100644 index 989647bb..00000000 --- a/static/freebsd/man4/snd_als4000.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
SND_ALS4000(4)Device Drivers ManualSND_ALS4000(4)
-
-
-

-

snd_als4000 — - Avance Logic ALS4000 PCI bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_als4000
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_als4000_load="YES"
-
-
-
-

-

The snd_als4000 bridge driver allows the - generic audio driver sound(4) to attach to the ALS4000 - sound card.

-
-
-

-

The snd_als4000 driver supports the - following sound cards:

-

-
    -
  • Avance Logic ALS4000
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_als4000 device driver first - appeared in FreeBSD 4.4.

-
-
-

-

Orion Hodson - <oho@acm.org>

-
-
- - - - - -
December 15, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_atiixp.4 3.html b/static/freebsd/man4/snd_atiixp.4 3.html deleted file mode 100644 index 91a67355..00000000 --- a/static/freebsd/man4/snd_atiixp.4 3.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - -
SND_ATIIXP(4)Device Drivers ManualSND_ATIIXP(4)
-
-
-

-

snd_atiixp — ATI - IXP bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_atiixp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_atiixp_load="YES"
-
-
-
-

-

The snd_atiixp bridge driver allows the - generic audio driver, sound(4), to attach to ATI IXP audio - devices. This driver supports 16bit playback and recording, and 32bit native - playback and recording.

-
-

-

The following sysctl(8) variables are available - in addition to those available to all sound(4) - devices:

-
-
-
dev.pcm.%d.polling
-
Experimental polling mode, where the driver operates by querying the - device state on each tick using callout(9). Polling is - disabled by default. Do not enable it unless you are facing weird - interrupt problems or if the device cannot generate interrupts at - all.
-
-
-
-
-
-

-

The snd_atiixp driver supports the - following audio chipsets:

-

-
    -
  • ATI IXP 200
    • -
  • ATI IXP 300
    • -
  • ATI IXP 400
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_atiixp device driver first - appeared in FreeBSD 6.1.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
-

-

The snd_atiixp driver does not support - S/PDIF, but implementing it should be fairly easy if the right hardware is - available.

-

32bit native recording is broken on some hardware.

-
-
- - - - - -
November 29, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_cmi.4 4.html b/static/freebsd/man4/snd_cmi.4 4.html deleted file mode 100644 index 93362d49..00000000 --- a/static/freebsd/man4/snd_cmi.4 4.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
SND_CMI(4)Device Drivers ManualSND_CMI(4)
-
-
-

-

snd_cmi — CMedia - CMI8338/CMI8738 PCI bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_cmi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_cmi_load="YES"
-
-
-
-

-

The snd_cmi bridge driver allows the - generic audio driver sound(4) to attach to the CMedia - CMI8338/CMI8738 audio cards.

-
-
-

-

The snd_cmi driver supports the following - sound cards:

-

-
    -
  • CMedia CMI8338A
    • -
  • CMedia CMI8338B
    • -
  • CMedia CMI8738
    • -
  • CMedia CMI8738B
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_cmi device driver first appeared - in FreeBSD 4.3.

-
-
-

-

Orion Hodson - <O.Hodson@cs.ucl.ac.uk>

-
-
- - - - - -
December 15, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_cs4281.4 4.html b/static/freebsd/man4/snd_cs4281.4 4.html deleted file mode 100644 index abe1650b..00000000 --- a/static/freebsd/man4/snd_cs4281.4 4.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
SND_CS4281(4)Device Drivers ManualSND_CS4281(4)
-
-
-

-

snd_cs4281 — - Crystal Semiconductor CS4281 PCI bridge device - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_cs4281
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_cs4281_load="YES"
-
-
-
-

-

The snd_cs4281 bridge driver allows the - generic audio driver sound(4) to attach to the CS4281 - sound card.

-
-
-

-

The snd_cs4281 driver supports the - following sound cards:

-

-
    -
  • Crystal Semiconductor CS4281
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_cs4281 device driver first - appeared in FreeBSD 4.3.

-
-
-

-

Orion Hodson - <O.Hodson@cs.ucl.ac.uk>

-
-
- - - - - -
December 15, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_csa.4 4.html b/static/freebsd/man4/snd_csa.4 4.html deleted file mode 100644 index 879c364e..00000000 --- a/static/freebsd/man4/snd_csa.4 4.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
SND_CSA(4)Device Drivers ManualSND_CSA(4)
-
-
-

-

snd_csa — Crystal - Semiconductor CS461x/462x/4280 PCI bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_csa
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_csa_load="YES"
-
-
-
-

-

The snd_csa bridge driver allows the - generic audio driver sound(4) to attach to Crystal - Semiconductor CS461x/462x/4280 based sound cards.

-
-
-

-

The snd_csa driver supports the following - sound cards:

-

-
    -
  • Crystal Semiconductor CS4280
    • -
  • Crystal Semiconductor CS4610
    • -
  • Crystal Semiconductor CS4611
    • -
  • Crystal Semiconductor CS4614
    • -
  • Crystal Semiconductor CS4615
    • -
  • Crystal Semiconductor CS4622
    • -
  • Crystal Semiconductor CS4624
    • -
  • Crystal Semiconductor CS4630
    • -
  • Genius Soundmaker 128 Value
    • -
  • Hercules Game Theatre XP
    • -
  • Turtle Beach Santa Cruz
    • -
-

Some onboard CS4610 chips are accompanied by the CS423x ISA codec - instead of the CS4297 AC97 codec. Such configurations are not supported by - the snd_csa driver yet.

-
-
-

-

sound(4)

-
-
-

-

The snd_csa device driver first appeared - in FreeBSD 4.0.

-
-
-

-

Seigo Tanimura - <tanimura@r.dl.itc.u-tokyo.ac.jp>

-
-
- - - - - -
December 15, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_dummy.4 4.html b/static/freebsd/man4/snd_dummy.4 4.html deleted file mode 100644 index 70a600b2..00000000 --- a/static/freebsd/man4/snd_dummy.4 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
SND_DUMMY(4)Device Drivers ManualSND_DUMMY(4)
-
-
-

-

snd_dummy — Dummy - audio driver

-
-
-

-

To load the driver at boot time, place the following line in - loader.conf(5):

-
-
snd_dummy_load="YES"
-
-
-
-

-

The snd_dummy driver implements a virtual - testing device, meaning it does not correspond to a physical sound card. It - is intended for testing, so that test programs do not need to rely on - hardware being present in the machine in order to run.

-

The driver attaches as a regular sound(4) - device, with two channels (one playback and one recording), as well as a - mixer.

-

Playback works by discarding all input, and recording by returning - silence (zeros).

-
-
-

-
-
/dev/dsp.dummy
-
Alias to the device's /dev/dsp%d file created by - sound(4). This makes it easy for tests to open the dummy - device when there are more devices present in the system.
-
-
-
-

-

sound(4), loader.conf(5), - loader(8)

-
-
-

-

The snd_dummy driver was implemented by - Christos Margiolis - <christos@FreeBSD.org> - under sponsorship from the FreeBSD Foundation.

-
-
-

-

Because the driver automatically attaches once the module is - loaded, it can only be attached once.

-
-
- - - - - -
October 22, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_emu10k1.4 3.html b/static/freebsd/man4/snd_emu10k1.4 3.html deleted file mode 100644 index 70e9a514..00000000 --- a/static/freebsd/man4/snd_emu10k1.4 3.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
SND_EMU10K1(4)Device Drivers ManualSND_EMU10K1(4)
-
-
-

-

snd_emu10k1 — - SoundBlaster Live! and Audigy PCI bridge device - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_emu10k1
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_emu10k1_load="YES"
-
-
-
-

-

The snd_emu10k1 bridge driver allows the - generic audio driver sound(4) to attach to the - SoundBlaster Live! and Audigy audio cards.

-

Digital output is supported by default.

-
-
-

-

The snd_emu10k1 driver supports the - following sound cards:

-

-
    -
  • Creative SoundBlaster Live! (EMU10K1 Chipset)
    • -
  • Creative SoundBlaster Audigy (EMU10K2 Chipset)
    • -
  • Creative SoundBlaster Audigy 2 (EMU10K2 Chipset)
    • -
  • Creative SoundBlaster Audigy 2 (EMU10K3 Chipset)
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_emu10k1 device driver first - appeared in FreeBSD 4.1.

-
-
-

-

David O'Brien - <obrien@FreeBSD.org> -
- Orlando Bassotto - <orlando.bassotto@ieo-research.it> -
- Cameron Grant - <cg@FreeBSD.org>

-
-
-

-

Fancy features like DD5.1 output are not supported.

-
-
- - - - - -
December 15, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_emu10kx.4 3.html b/static/freebsd/man4/snd_emu10kx.4 3.html deleted file mode 100644 index 20f9eb64..00000000 --- a/static/freebsd/man4/snd_emu10kx.4 3.html +++ /dev/null @@ -1,267 +0,0 @@ - - - - - - -
SND_EMU10KX(4)Device Drivers ManualSND_EMU10KX(4)
-
-
-

-

snd_emu10kx — - Creative SoundBlaster Live! and Audigy sound cards device - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_emu10kx
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_emu10kx_load="YES"
-
-
-
-

-

The snd_emu10kx bridge driver allows the - generic audio driver sound(4) to attach to Creative sound - cards based on the EMU10K1, CA0100, CA0101, CA0102 and CA0108 DSPs.

-

The snd_emu10kx sound cards have a PCM - part, which is accessible through one to five pcm(4) - devices (see MULTICHANNEL - PLAYBACK for details), and MPU401-compatible MIDI I/O controller, which - is accessible through the midi device. Wave table synthesizer support is not - available.

-
-
-

-

The snd_emu10kx driver supports the - following sound cards:

-

-
    -
  • Creative Sound Blaster Live! (EMU10K1 Chipset). Both PCM and MIDI - interfaces are available.
    • -
  • Creative Sound Blaster Audigy (CA0100 and CA0101 Chipset). PCM and two - MIDI interfaces available.
    • -
  • Creative Sound Blaster Audigy 2 and Creative Sound Blaster Audigy 4 - (CA0102 Chipset). PCM support is limited to 48kHz/16 bit stereo (192kHz/24 - bit part of this chipset is not supported).
    • -
  • Creative Sound Blaster Audigy 2 Value (CA0108 Chipset). PCM support is - limited to 48kHz/16 bit stereo (192kHz/24 bit part of this chipset is not - supported). There is no MIDI support for this card.
    • -
-

The snd_emu10kx driver does - support the - following sound cards (although they have names similar to some supported - ones):

-

-
    -
  • Creative Sound Blaster Live! 24-Bit, identified by - FreeBSD as "emu10k1x - Soundblaster Live! 5.1".
    • -
  • Creative Sound Blaster Audigy LS / ES, identified by - FreeBSD as "CA0106-DAT - Audigy LS".
    • -
  • All other Creative sound cards with -DAT chipsets.
    • -
  • All Creative X-Fi series sound cards.
    • -
-
-
-

-

By default the snd_emu10kx driver is - loaded with multichannel playback capabilities enabled. If you do not set - the hint.emu10kx.0.multichannel_disabled option in - your loader.conf(5) configuration file you will get up to - five DSP devices, one for each sound card output. You can use additional - software (like - - from ) to do sound stream demultiplexing. Only - “FRONT” output can play and record sound from external sources - (like line or S/PDIF inputs).

-
-
-

-

By default multichannel recording capabilities are not enabled - when you load the snd_emu10kx driver. If you enable - the hint.emu10kx.0.multichannel_recording option in - loader.conf(5) you will get one more DSP device that is - rate-locked to 48kHz/16bit/mono. This is actually 48kHz/16bit/32 channels on - SB Live! cards and 48kHz/16bit/64channels on Audigy cards, but the current - implementation of the sound subsystem does not support such an amount of PCM - channels. This device can not be opened for read, thus confusing many - applications.

-

Within a multichannel stream, the first half (0-15 or 0-31) is a - copy of all DSP outputs, the second half (15-30 or 32-63) is a copy of some - DSP inputs. On Live! cards the last substream (31) is used as a sync stream - and is always set to 0xc0de. Audigy cards do not need such sync data, - because a stream always starts with substream 0.

-
-

-
-
-
Substream
-
+0x00..+0x1E
-
PCM streams 0..15
-
+0x20, +0x22
-
Empty
-
+0x24..+0x2A
-
PCM inputs: front left, front right, rear left, rear right, center, - sub
-
+0x2C..+0x3C
-
DSP inputs 0..8:
-
+0x3E
-
sync substream (0xc0de)
-
-
-
-

-
-
-
Substream
-
+0x00..+0x3E
-
PCM streams 0..31
-
+0x40..+0x5E
-
PCM inputs: front LR, rear LR, center, sub, ...
-
+0x60..+0x7E
-
DSP inputs 0..16
-
-
-
-
-

-

These are the controls available through the standard OSS - programming interface. You can use mixer(8) to change - them.

-

On EMU10K1-based cards the OSS mixer directly controls the AC97 - codec. On newer cards the OSS mixer controls some parameters of the AC97 - codec and some DSP-based mixer controls.

-
-
"vol"
-
mixer control for the overall sound volume.
-
"pcm"
-
mixer control for the PCM playback volume. It controls only front output - volume in multichannel mode and all output volume in single channel - mode.
-
"rec"
-
mixer control acts very differently on EMU10K1 and other cards. On EMU10K1 - cards it controls the AC97 codec recording level. On non-EMU10K1 cards it - controls the amount of AC97 “stereo mix” -
- entering the DSP. AC97 recording level and AC97 recording source are fixed - on CA0100, CA0101, CA0102 and CA0108 cards. The AC97 recording levels are - always set to maximum and recording source is always - “stereo mix”.
-
"dig1"
-
is a CD S/PDIF (on-card) volume control
-
"dig2"
-
is an AudigyDrive S/PDIF (Audigy series) or TOSLink (SB Live! series) - volume control
-
"dig3"
-
is an on-card S/PDIF volume control
-
"line2"
-
is AudigyDrive "Line In 2" volume control
-
"line3"
-
is AudigyDrive "AUX In 2" volume control
-
-

Other OSS mixer controls control the inputs of the AC97 codec.

-
-
-

-

You can control some of EMU10Kx's operation and configuration - parameters through - dev.emu10kx.⟨X⟩ - sysctls. These sysctl(8) values are temporary and should - not be relied upon.

-
-
-

-

Loader tunables are used to set driver configuration. Tunables can - be set at the loader(8) prompt before booting the kernel - or they can be stored in /boot/loader.conf. These - tunables cannot be changed from a machine sysctl(8) entry - after boot, but you can change them using kenv(1) before - loading the snd_emu10kx driver.

-
-
hint.emu10kx.⟨X⟩.disabled
-
Disables loading a driver instance.
-
hint.emu10kx.⟨X⟩.multichannel_disabled
-
Disables multichannel playback support, when one card is represented as - several PCM devices.
-
hint.emu10kx.⟨X⟩.multichannel_recording
-
Enables experimental multichannel recording support.
-
hint.emu10kx.⟨X⟩.debug
-
Set debug output level. -
-
0
-
No additional debug options enabled
-
1
-
Enables all DSP outputs to be connected, even those that are known to - be unused on a particular card.
-
2
-
Additional debug messages about in-driver events will be printed.
-
2
-
Additional debug messages will be printed when memory allocation - fails.
-
-
-
-
-
-

-
-
/dev/emu10kx?
-
snd_emu10kx management interface
-
-
-
-

-

sound(4)

-
-
-

-

The snd_emu10kx device driver first - appeared in FreeBSD 7.0.

-
-
-

-

The PCM part of the driver is based on the - snd_emu10k1(4) SB Live! driver by Cameron - Grant - <cg@FreeBSD.org>. The - MIDI interface is based on the snd_emu10k1(4) MIDI - interface code by Mathew Kanner - <matk@FreeBSD.org>. - The snd_emu10kx device driver and this manual page - were written by Yuriy Tsibizov.

-
-
-

-

The driver does not detect lost S/PDIF signals and produces noise - when S/PDIF is not connected and S/PDIF volume is not zero.

-

The PCM driver cannot detect the presence of Live!Drive or - AudigyDrive breakout boxes and tries to use them (and list their connectors - in the mixer).

-

The MIDI driver cannot detect the presence of Live!Drive or - AudigyDrive breakout boxes and tries to enable the IR receiver on them - anyway.

-
-
- - - - - -
May 28, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_envy24.4 4.html b/static/freebsd/man4/snd_envy24.4 4.html deleted file mode 100644 index b6a214c3..00000000 --- a/static/freebsd/man4/snd_envy24.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
SND_ENVY24(4)Device Drivers ManualSND_ENVY24(4)
-
-
-

-

snd_envy24 — VIA - Envy24 and compatible bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_envy24 -
-device snd_spicds
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_envy24_load="YES"
-
-
-
-

-

The snd_envy24 bridge driver allows the - generic audio driver sound(4) to attach to VIA Envy24 - (ICE1724 or VT1724 chipset) and compatible audio devices.

-
-
-

-

The snd_envy24 driver supports the - following audio devices:

-

-
    -
  • M-Audio Audiophile 2496
    • -
  • M-Audio Delta Dio 2496
    • -
  • Terratec DMX 6fire
    • -
-Only analog playback is supported. Recording and other features of these cards - are not supported. -
-
-

-

sound(4)

-
-
-

-

The snd_envy24 device driver first - appeared in FreeBSD 6.3.

-
-
-

-

The snd_envy24 driver was written by - Katsurajima Naoto. This manual page was written by - Alexander Leidinger - <netchild@FreeBSD.org>.

-
-
- - - - - -
June 1, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_envy24ht.4 4.html b/static/freebsd/man4/snd_envy24ht.4 4.html deleted file mode 100644 index 8ce0ed7e..00000000 --- a/static/freebsd/man4/snd_envy24ht.4 4.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
SND_ENVY24HT(4)Device Drivers ManualSND_ENVY24HT(4)
-
-
-

-

snd_envy24ht — VIA - Envy24HT and compatible bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_envy24ht -
-device snd_spicds
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_envy24ht_load="YES"
-
-
-
-

-

The snd_envy24ht bridge driver allows the - generic audio driver sound(4) to attach to VIA Envy24HT - (ICE1724 or VT1724 chipset) and compatible audio devices.

-
-
-

-

The snd_envy24ht driver supports the - following audio devices:

-

-
    -
  • Audiotrak Prodigy 7.1
    • -
  • Audiotrak Prodigy 7.1 LT
    • -
  • Audiotrak Prodigy 7.1 XT
    • -
  • Audiotrak Prodigy HD2
    • -
  • ESI Juli@
    • -
  • ESI Juli@ XTe
    • -
  • M-Audio Audiophile 192
    • -
  • M-Audio Revolution 5.1
    • -
  • M-Audio Revolution 7.1
    • -
  • Terratec Aureon 5.1 Sky
    • -
  • Terratec Aureon 7.1 Space
    • -
  • Terratec Aureon 7.1 Universe
    • -
  • Terratec PHASE 22
    • -
  • Terratec PHASE 28
    • -
-Only analog playback is supported. Recording and other features of these cards - are not supported. -
-
-

-

sound(4)

-
-
-

-

The snd_envy24ht device driver first - appeared in FreeBSD 6.3.

-
-
-

-

The snd_envy24ht driver was written by - Konstantin Dimitrov based upon the - snd_envy24(4) driver. This manual page was written by - Alexander Leidinger - <netchild@FreeBSD.org>.

-
-
- - - - - -
August 11, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_es137x.4 3.html b/static/freebsd/man4/snd_es137x.4 3.html deleted file mode 100644 index e00bdf2d..00000000 --- a/static/freebsd/man4/snd_es137x.4 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
SND_ES137X(4)Device Drivers ManualSND_ES137X(4)
-
-
-

-

snd_es137x — - Ensoniq AudioPCI ES137x bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_es137x
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_es137x_load="YES"
-
-
-
-

-

The snd_es137x bridge driver allows the - generic audio driver sound(4) to attach to the Ensoniq - 137x audio cards.

-
-

-

The following sysctl(8) variables are available - in addition to those available to all sound(4) - devices:

-
-
-
hw.snd.pcm%d.latency_timer
-
Controls the PCI latency timer setting. Increasing this value will solve - most popping and crackling issues (especially on VIA motherboards).
-
hw.snd.pcm%d.spdif_enabled
-
Enables S/PDIF output on the primary playback channel. This - sysctl(8) variable is available only if the device is - known to support S/PDIF output.
-
dev.pcm.%d.polling
-
Experimental polling mode, where the driver operates by querying the - device state on each tick using callout(9). Polling is - disabled by default. Do not enable it unless you are facing weird - interrupt problems or if the device cannot generate interrupts at - all.
-
-
-
-
-
-

-

The snd_es137x driver supports the - following sound cards:

-

-
    -
  • Creative CT5880-A
    • -
  • Creative CT5880-C
    • -
  • Creative CT5880-D
    • -
  • Creative CT5880-E
    • -
  • Creative SB AudioPCI CT4730
    • -
  • Ensoniq AudioPCI ES1370
    • -
  • Ensoniq AudioPCI ES1371-A
    • -
  • Ensoniq AudioPCI ES1371-B
    • -
  • Ensoniq AudioPCI ES1373-A
    • -
  • Ensoniq AudioPCI ES1373-B
    • -
  • Ensoniq AudioPCI ES1373-8
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_es137x device driver first - appeared in FreeBSD 4.0.

-
-
-

-

Russell Cattelan - <cattelan@thebarn.com> -
- Cameron Grant - <cg@FreeBSD.org> -
- Joachim Kuebart -
- Jonathan Noack - <noackjr@alumni.rice.edu>

-
-
- - - - - -
November 29, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_fm801.4 4.html b/static/freebsd/man4/snd_fm801.4 4.html deleted file mode 100644 index b39dfd13..00000000 --- a/static/freebsd/man4/snd_fm801.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
SND_FM801(4)Device Drivers ManualSND_FM801(4)
-
-
-

-

snd_fm801 — Forte - Media FM801 bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_fm801
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_fm801_load="YES"
-
-
-
-

-

The snd_fm801 bridge driver allows the - generic audio driver, sound(4), to attach audio devices - based on the Forte Media FM801 chipset. This is a common chipset found in - various parts used by OEM manufacturers.

-
-
-

-

The snd_fm801 driver supports audio - devices based on the following chipset:

-

-
    -
  • Forte Media FM801
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_fm801 device driver first appeared - in FreeBSD 4.2.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
-

-

The Forte Media FM801 chipset is a sort of PCI bridge, not an - actual sound controller, making it possible to have soundless support. One - problem is that both chipsets, with and without sound support, use the same - PCI ID. This makes it impossible to determine which one is installed.

-
-
- - - - - -
December 1, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_hda.4 3.html b/static/freebsd/man4/snd_hda.4 3.html deleted file mode 100644 index bf9d6b35..00000000 --- a/static/freebsd/man4/snd_hda.4 3.html +++ /dev/null @@ -1,532 +0,0 @@ - - - - - - -
SND_HDA(4)Device Drivers ManualSND_HDA(4)
-
-
-

-

snd_hda — Intel - High Definition Audio bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_hda
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_hda_load="YES"
-
-
-
-

-

The High Definition (HD) Audio specification was developed by - Intel as the logical successor of the old AC'97 specification and has - several advantages, such as higher bandwidth which allows more channels and - more detailed formats, support for several logical audio devices, and - general purpose DMA channels.

-

The snd_hda driver includes HDA bus - controller driver (hdac), HDA codec driver (hdacc) and HDA codecs audio - functions bridge driver (hdaa) that allows the generic audio driver, - sound(4), to be used with this hardware. Only audio - functions are supported by snd_hda. Modem and other - possible functions are not implemented.

-

The snd_hda driver supports hardware that - conforms with revision 1.0 of the Intel High Definition Audio specification - and tries to behave much like the Microsoft Universal Audio Architecture - (UAA) draft (revision 0.7b) for handling audio devices.

-

According to HDA and UAA specifications, depending on the number - of HDA buses and codecs present in system, their audio capabilities and BIOS - provided configuration, the snd_hda driver often - provides several PCM audio devices. For example, one device for main rear - 7.1 output and inputs, one device for independent headset connectors at - front and one device for SPDIF or HDMI audio input/output. The assignment of - audio inputs and outputs may be tuned with device.hints(5) - or sysctl(8). The driver's verbose boot messages provide a - lot of information about the operation of the driver and present audio - setup.

-

The default audio device may be tuned by setting the - hw.snd.default_unit sysctl, as described in - sound(4), or explicitly specified in application - settings.

-
-

-

The following variables are available at boot-time through the - device.hints(5) file:

-
-
-
hint.hdac.%d.config
-
Configures a range of possible controller options. Possible values are: - “64bit”, - “dmapos”, - “msi”. An option prefixed with - “no”, such as - “nomsi”, will do the opposite and - takes precedence. Options can be separated by whitespace and commas.
-
hint.hdac.%d.msi
-
Controls MSI (Message Signaled Interrupts) support.
-
hint.hdac.%d.cad%d.nid%d.config
-
Same as hint.hdaa.%d.nid%d.config
-
hint.hdaa.%d.config
-
Configures a range of possible audio function options. Possible values - are: “eapdinv”, - “ivref”, - “ivref50”, - “ivref80”, - “ivref100”, - “fixedrate”, - “forcestereo”, - “ovref”, - “ovref50”, - “ovref80”, - “ovref100”, - “senseinv”, - “softpcmvol”, and - “vref”. An option prefixed with - “no”, such as - “nofixedrate”, will do the opposite - and takes precedence. Options can be separated by whitespace and commas. -

The “eapdinv” option - inverts External Amplifier Power Down signal. The - “fixedrate” denies all sampling - rates except 48KHz. The - “forcestereo” denies mono - playback/recording. The “senseinv” - option inverts jack sensing logic. The - “ivrefX” and - “ovrefX” - options control the voltage used to power external microphones.

-
-
dev.hdaa.%d.init_clear
-
Zero out the pin widget config setup by the system. Some systems seem to - have unusable audio devices if the pin widget configuration is cleared. - Set this value to 0 to accept the default configuration values setup by - the BIOS.
-
hint.hdaa.%d.gpio_config
-
Overrides audio function GPIO pins configuration set by BIOS. May be - specified as a set of space-separated - “num=value” - pairs, where num is GPIO line number, and - value is one of: - “keep”, - “set”, - “clear”, - “disable” and - “input”. -

“GPIOs” are a codec's - General Purpose I/O pins which system integrators sometimes use to - control external muters, amplifiers and so on. If you have no sound, or - sound volume is not adequate, you may have to experiment a bit with the - GPIO setup to find the optimal setup for your system.

-
-
hint.hdaa.%d.nid%d.config
-
Overrides audio function pin configuration set by BIOS. May be specified - as a 32-bit hexadecimal value with a leading “0x”, or as a - set of space-separated - “option=value” - pairs.
-
hint.pcm.%d.rec.autosrc
-
Controls automatic recording source feature: -
-
0
-
disabled,
-
1
-
once on attach,
-
2
-
enabled.
-
- When enabled, driver will automatically set recording source of the mixer to - connected input using jack presence detection statuses.
-
-
-

Pin configuration is the UAA driver's main source of information - about codec usage. This information is usually provided by the codec - manufacturer and tuned by system integrators for specific system - requirements. The snd_hda driver allows users to - override it to fix integrator mistakes or to use the available codec in - alternative ways (for example to get stereo output and 2 inputs instead of a - single 5.1 output).

-

The following options are supported:

-
-
-
as
-
Association number. Associations are used to group individual pins to form - a complex multi-pin device. For example, to group 4 connectors for 7.1 - input/output, or to treat several input connectors as sources for the same - input device. Association numbers can be specified as numeric values from - 0 to 15. A value of 0 means disabled pin. A value of 15 is a set of - independent unassociated pins. Each association includes only pins of the - same direction (in/out) and is detected atomically (all pins or none). A - separate PCM audio device is created for every pair of input and output - associations.
-
seq
-
Sequence number. A unique, per-association number used to order pins - inside the particular association. Sequence numbers can be specified as - numeric values from 0 to 15. -

The sequence number 15 has a special meaning for output - associations. Output pins with this number and device type - “Headphones” will duplicate (with - automatic mute if jack detection is supported) the first pin in that - association.

-

The sequence numbers 14 and 15 has a special meaning for input - associations. Their presence in association defines it as multiplexed or - mixed respectively. If none of them are present and there are more than - one pin in association, the association will provide multichannel - input.

-

For multichannel input/output associations sequence numbers - encode channel pairs positions: 0 - Front, 1 - Center/LFE, 2 - Back, 3 - - Front Wide Center, 4 - Side. Standard combinations are: (0) - Stereo; - (0, 2), (0, 4) - Quadro; (0, 1, 2), (0, 1, 4) - 5.1; (0, 1, 2, 4) - - 7.1.

-
-
device
-
Device type. Can be specified as a number from 0 to 15 or as a name: - “Line-out”, - “Speaker”, - “Headphones,” - “CD”, - “SPDIF-out”, - “Digital-out”, - “Modem-line”, - “Modem-handset”, - “Line-in”, - “AUX”, - “Mic”, - “Telephony”, - “SPDIF-in”, - “Digital-in”, - “Res.E”, or - “Other”. The device type also - describes the pin direction (in/out). For example, - “CD” always means an input pin, - while “Headphones” always means an - output.
-
conn
-
Connection type. Can be specified as a number from 0 to 3. The connection - type can also be specified as one of the special names - “Jack”, - “None”, - “Fixed”, or - “Both”. Pins with a connection type - of “None” are disabled.
-
ctype
-
Connector physical type. Can be specified as a number from 0 to 15. This - is a reference only value. It is ignored by the - snd_hda driver.
-
color
-
Connector color. Can be specified as a number from 0 to 15 or as one of - the names “Unknown”, - “Black”, - “Grey”, - “Blue”, - “Green”, - “Red”, - “Orange”, - “Yellow”, - “Purple”, - “Pink”, - “Res.A”, - “Res.B”, - “Res.C”, - “Res.D”, - “White”, or - “Other”. This is a reference only - value. It is ignored by the snd_hda driver.
-
loc
-
Connector physical location. Can be specified as a number from 0 to 63. - This is a reference only value. It is ignored by the - snd_hda driver.
-
misc
-
Misc bits. Can be specified as a number from 0 to 15. Bit 0 has a special - meaning. When set it means that jack detection is not implemented in - hardware.
-
-
-
-
-

-

The following sysctl(8) variables are available - in addition to those available to all sound(4) - devices:

-
-
-
dev.hdac.%d.pindump
-
Setting this to a non-zero value dumps the current pin configuration, main - capabilities and jack sense status of all audio functions on the - controller to console and syslog.
-
dev.hdac.%d.polling
-
Enables polling mode. In this mode the driver operates by querying the - device state on timer ticks using callout(9) instead of - interrupts. Polling is disabled by default. Do not enable it unless you - are facing weird interrupt problems or if the device cannot generate - interrupts at all.
-
dev.hdaa.%d.config
-
Run-time equivalent of the hint.hdaa.%d.config - tunable.
-
dev.hdaa.%d.gpi_state
-
Current state of GPI lines.
-
dev.hdaa.%d.gpio_state
-
Current state of GPIO lines.
-
dev.hdaa.%d.gpio_config
-
Run-time equivalent of the hint.hdaa.%d.gpio.config - tunable.
-
dev.hdaa.%d.gpo_state
-
Current state of GPO lines.
-
dev.hdaa.%d.nid%d_config
-
Run-time equivalent of the hint.hdaa.%d.nid%d.config - tunable.
-
dev.hdaa.%d.nid%d_original
-
Original pin configuration written by BIOS.
-
dev.hdaa.%d.reconfig
-
Setting this to a non-zero value makes driver to destroy existing pcm - devices and process new pins configuration set via - dev.hdaa.%d.nid%d_config.
-
dev.pcm.%d.play.32bit, - dev.pcm.%d.rec.32bit
-
HDA controller uses 32bit representation for all samples of more then 16 - bits. These variables allow to specify how many bits of these 32 should be - used by CODEC. Depending on codec capabilities, possible values are 20, 24 - and 32 bit. The default value is 24.
-
dev.pcm.%d.rec.autosrc
-
Run-time equivalent of the hint.pcm.%d.rec.autosrc - tunable.
-
-
-
-
-
-

-

The snd_hda driver supports PCI class 04h - (multimedia), subclass 03h (HDA) audio controllers and codecs compatible - with the Intel High Definition Audio 1.0 specification.

-
-
-

-

Taking HP Compaq DX2300 with Realtek ALC888 HDA codec for example. - This system has two audio connectors on a front side, three audio connectors - on a rear side and one internal speaker. According to verbose driver output - and the codec datasheet, this codec has five stereo DACs and two stereo - ADCs, all of them are routable to any codec pin (external connector). All - codec pins are reversible (could be configured either as input or - output).

-

So high codec uniformity and flexibility allow driver to configure - it in many different ways, depending on requested pins usage described by - pins configuration. The driver reports such default pin configuration when - verbose messages enabled:

-
-
hdaa0: nid   0x    as seq device       conn  jack    loc        color   misc
-hdaa0: 20 01014020 2  0  Line-out      Jack  1/8     Rear       Green   0
-hdaa0: 21 99130110 1  0  Speaker       Fixed ATAPI   Onboard    Unknown 1
-hdaa0: 22 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
-hdaa0: 23 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
-hdaa0: 24 01a19830 3  0  Mic           Jack  1/8     Rear       Pink    8
-hdaa0: 25 02a1983f 3  15 Mic           Jack  1/8     Front      Pink    8
-hdaa0: 26 01813031 3  1  Line-in       Jack  1/8     Rear       Blue    0
-hdaa0: 27 0221401f 1  15 Headphones    Jack  1/8     Front      Green   0
-hdaa0: 28 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
-hdaa0: 30 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
-hdaa0: 31 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
-
-

Here we can see, that the nodes with ID (nid) 25 and 27 are front - panel connectors (Jack, Front), nids 20, 24 and 26 are rear panel connectors - (Jack, Rear) and nid 21 is a built-in speaker (Fixed, Onboard). Pins with - nids 22, 23, 28, 30 and 31 will be disabled by driver due to - "None" connectivity. So the pin count and description matches to - connectors that we have.

-

Using association (as) and sequence (seq) fields values pins are - grouped into 3 associations:

-
-
hdaa0: Association 0 (1) out:
-hdaa0:   Pin nid=21 seq=0
-hdaa0:   Pin nid=27 seq=15
-hdaa0: Association 1 (2) out:
-hdaa0:   Pin nid=20 seq=0
-hdaa0: Association 2 (3) in:
-hdaa0:   Pin nid=24 seq=0
-hdaa0:   Pin nid=26 seq=1
-hdaa0:   Pin nid=25 seq=15
-
-

Each pcm(4) device uses two associations: one - for playback and one for recording. Associations processed and assigned to - pcm(4) devices in increasing numerical order. In this case - association #0 (1) will become pcm0 device playback, - using the internal speakers and Headphones jack with - speaker automute on the headphones jack connection. Association #1 (2) will - become pcm1 playback, using the - Line-out jack. Association #2 (3) will become - pcm0 recording, using the external microphones and - the Line-in jack.

-

The snd_hda driver provides extensive - verbose messages to diagnose its operation logic and describe its current - codec configuration.

-

Using device.hints(5) it is possible to modify - the configuration of the existing pins, allowing a broad range of different - audio setups. Here are a few examples of some setups possible for this - particular hardware:

-
-

-

Setting the device.hints(5) options

-
-
hint.hdac.0.cad0.nid20.config="as=1"
-hint.hdac.0.cad0.nid21.config="as=2"
-
-

will swap line-out and speaker functions. So the - pcm0 device will play to the line-out and headphones - jacks. Line-out will be muted on the headphones jack connection. Recording - on pcm0 will go from two external microphones and - line-in jacks. pcm1 playback will go to the internal - speaker.

-
-
-

-

Setting the device.hints(5) options

-
-
hint.hdac.0.cad0.nid20.config="as=1 seq=15 device=Headphones"
-hint.hdac.0.cad0.nid27.config="as=2 seq=0"
-hint.hdac.0.cad0.nid25.config="as=4 seq=0"
-
-

will split the headphones and one of the microphones to a separate - device. The pcm0 device will play to the internal - speaker and to the line-out jack, with speaker automute on the line-out jack - connection. Recording on pcm0 will use input from - one external microphone and the line-in jacks. The - pcm1 device will be completely dedicated to a - headset (headphones and mic) connected to the front connectors.

-
-
-

-

Setting the device.hints(5) options

-
-
hint.hdac.0.cad0.nid20.config="as=1 seq=0"
-hint.hdac.0.cad0.nid26.config="as=2 seq=0"
-hint.hdac.0.cad0.nid27.config="as=3 seq=0"
-hint.hdac.0.cad0.nid25.config="as=4 seq=0"
-hint.hdac.0.cad0.nid24.config="as=5 seq=0 device=Line-out"
-hint.hdac.0.cad0.nid21.config="as=6 seq=0"
-
-

will give 4 independent devices: pcm0 - (line-out and line-in), pcm1 (headphones and mic), - pcm2 (additional line-out via retasked rear mic - jack), and pcm3 (internal speaker).

-
-
-

-

Setting the device.hints(5) options

-
-
hint.hdac.0.cad0.nid20.config="as=1 seq=0"
-hint.hdac.0.cad0.nid24.config="as=1 seq=1 device=Line-out"
-hint.hdac.0.cad0.nid26.config="as=1 seq=2 device=Line-out"
-hint.hdac.0.cad0.nid21.config="as=2 seq=0"
-
-

will give 2 devices: pcm0 for 5.1 playback - via 3 rear connectors (line-out and retasked mic and line-in) and headset - (headphones and mic) at front connectors. pcm1 for - internal speaker playback. On headphones connection rear connectors will be - muted.

-
-
-
-

-

Depending on codec configuration, these controls and signal - sources could be reported to sound(4):

-
-
-
vol
-
overall output level (volume)
-
rec
-
overall recording level
-
igain
-
input-to-output monitoring loopback level
-
ogain
-
external amplifier control
-
pcm
-
PCM playback
-
mix
-
input mix
-
mic
-
first external or second internal microphone input
-
monitor
-
first internal or second external microphone input
-
line, line1, - line2, line3
-
analog (line) inputs
-
dig1, dig2, - dig3
-
digital (S/PDIF, HDMI or DisplayPort) inputs
-
cd
-
CD input
-
speaker
-
PC speaker input
-
phin, phout, - radio, video
-
other random inputs
-
-
-

Controls have different precision. Some could be just an on/off - triggers. Most of controls use logarithmic scale.

-
-
-

-

snd_ich(4), sound(4), - device.hints(5), loader.conf(5), - sysctl(8)

-
-
-

-

The snd_hda device driver first appeared - in FreeBSD 6.3.

-
-
-

-

The snd_hda driver was written by - Stephane E. Potvin - <sepotvin@videotron.ca>, - Ariff Abdullah - <ariff@FreeBSD.org> - and Alexander Motin - <mav@FreeBSD.org>. - This manual page was written by Joel Dahl - <joel@FreeBSD.org>, - Alexander Motin - <mav@FreeBSD.org> and - Giorgos Keramidas - <keramida@FreeBSD.org>.

-
-
-

-

Some Hardware/OEM vendors tend to screw up BIOS settings or use - custom unusual CODEC wiring that create problems to the driver. This may - result in missing pcm devices, or a state where the - snd_hda driver seems to attach and work, but no - sound is played. Some cases can be solved by tuning - loader.conf variables. But before trying to fix - problem that way, make sure that there really is a problem and that the PCM - audio device in use really corresponds to the expected audio connector.

-

Some vendors use non-standardized General Purpose I/O (GPIO) pins - of the codec to control external amplifiers. In some cases setting a - combination of GPIO bits may be needed to make sound work on a specific - device.

-

HDMI and DisplayPort audio may also require support from video - driver.

-
-
- - - - - -
January 20, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_hdsp.4 3.html b/static/freebsd/man4/snd_hdsp.4 3.html deleted file mode 100644 index 47c90f9b..00000000 --- a/static/freebsd/man4/snd_hdsp.4 3.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
SND_HDSP(4)Device Drivers ManualSND_HDSP(4)
-
-
-

-

snd_hdsp — RME - HDSP bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_hdsp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_hdsp_load="YES"
-
-
-
-

-

The snd_hdsp bridge driver allows the - generic audio driver sound(4) to attach to RME HDSP audio - devices.

-
-
-

-

The snd_hdsp driver supports the following - audio devices:

-

-
    -
  • RME HDSP 9632 (optional AO4S-192 and AIS-192 extension boards)
    • -
  • RME HDSP 9652
    • -
-

By default, each pcm(4) device corresponds to a - physical port on the sound card. For ADAT ports, 8 channel, 4 channel and 2 - channel formats are supported. The effective number of ADAT channels is 8 - channels at single speed (32kHz-48kHz) and 4 channels at double speed - (64kHz-96kHz). Only the HDSP 9632 can operate at quad speed (128kHz-192kHz), - ADAT is disabled in this mode. Depending on sample rate and channel format - selected, not all pcm channels can be mapped to ADAT channels and vice - versa.

-
-
-

-

These settings can be entered at the loader(8) - prompt or in loader.conf(5).

-
-
hw.hdsp.unified_pcm
-
If set to 1, all physical ports are combined into one unified pcm device. - When opened in multi-channel audio software, this makes all ports - available at the same time, and fully synchronized. For resulting channel - numbers consult the following table:
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Play | RecPlay | RecPlay | Rec
HDSP 9632 16 | 16 12 | 12 8 | 8
HDSP 9652 26 | 26 14 | 14 - | -
-
-
-

-

These settings and informational values can be accessed at runtime - with the sysctl(8) command. If multiple RME HDSP sound - cards are installed, each device has a separate configuration. To adjust the - following sysctl identifiers for a specific sound card, insert the - respective device number in place of - ‘0’.

-
-
dev.hdsp.0.sample_rate
-
Set a fixed sample rate from 32000, 44100, 48000, up to 192000. This is - usually required for digital connections (AES, S/PDIF, ADAT). The default - value of 0 adjusts the sample rate according to pcm device settings.
-
dev.hdsp.0.period
-
The number of samples processed per interrupt, from 32, 64, 128, up to - 4096. Setting a lower value here results in less latency, but increases - system load due to frequent interrupt processing. Extreme values may cause - audio gaps and glitches.
-
dev.hdsp.0.clock_list
-
Lists possible clock sources to sync with, depending on the hardware - model. This includes internal and external master clocks as well as - incoming digital audio signals like AES, S/PDIF and ADAT.
-
dev.hdsp.0.clock_preference
-
Select a preferred clock source from the clock list. HDSP cards will sync - to this clock source when available, but fall back to auto-sync with any - other digital clock signal they receive. Set this to - ‘internal’ if the HDSP card should - act as master clock.
-
dev.hdsp.0.clock_source
-
Shows the actual clock source in use (read only). This differs from what - is set as clock preference when in auto-sync mode.
-
dev.hdsp.0.sync_status
-
Display the current sync status of all external clock sources. Status - indications are ‘none’ for no signal - at all, ‘lock’ for when a valid - signal is present, and ‘sync’ for - accurately synchronized signals (required for recording digital - audio).
-
-

The following tunables are applicable to HDSP 9632 devices - only:

-
-
dev.hdsp.0.input_level
-
Select the sensitivity of the analog line input. Available reference - levels for the input signal are - ‘LowGain’, - ‘+4dBu’ and - ‘-10dBV’.
-
dev.hdsp.0.output_level
-
Select the gain level of the analog line output. Available reference - levels for the output signal are - ‘HighGain’, - ‘+4dBu’ and - ‘-10dBV’.
-
dev.hdsp.0.phones_level
-
Adjust the gain level of the phones output, separately from the analog - line output. The signal can be lowered by 6 or 12 dB.
-
-

Where appropriate these sysctl values are modeled after official - RME software on other platforms, and adopt their terminology. Consult the - RME user manuals for additional information.

-
-
-

-

sound(4)

-
-
-

-

The snd_hdsp device driver first appeared - in FreeBSD 15.0.

-
-
-

-

Based on snd_hdspe(4) originally written by - Ruslan Bukin <br@bsdpad.com>. All adaptation - to HDSP cards by Florian Walpen - <dev@submerge.ch>.

-
-
- - - - - -
October 28, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_hdspe.4 3.html b/static/freebsd/man4/snd_hdspe.4 3.html deleted file mode 100644 index adfb9cb7..00000000 --- a/static/freebsd/man4/snd_hdspe.4 3.html +++ /dev/null @@ -1,181 +0,0 @@ - - - - - - -
SND_HDSPE(4)Device Drivers ManualSND_HDSPE(4)
-
-
-

-

snd_hdspe — RME - HDSPe bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_hdspe
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_hdspe_load="YES"
-
-
-
-

-

The snd_hdspe bridge driver allows the - generic audio driver sound(4) to attach to RME HDSPe audio - devices.

-
-
-

-

The snd_hdspe driver supports the - following audio devices:

-

-
    -
  • RME HDSPe AIO (optional AO4S-192 and AI4S-192 extension boards)
    • -
  • RME HDSPe RayDAT
    • -
-

By default, each pcm(4) device corresponds to a - physical port on the sound card. For ADAT ports, 8 channel, 4 channel and 2 - channel formats are supported. The effective number of ADAT channels is 8 - channels at single speed (32kHz-48kHz), 4 channels at double speed - (64kHz-96kHz), and 2 channels at quad speed (128kHz-192kHz). Depending on - sample rate and channel format selected, not all pcm channels can be mapped - to ADAT channels and vice versa.

-
-
-

-

These settings can be entered at the loader(8) - prompt or in loader.conf(5).

-
-
hw.hdspe.unified_pcm
-
If set to 1, all physical ports are combined into one unified pcm device. - When opened in multi-channel audio software, this makes all ports - available at the same time, and fully synchronized. For resulting channel - numbers consult the following table:
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Play | RecPlay | RecPlay | Rec
HDSPe AIO 20 | 18 16 | 14 14 | 12
HDSPe RayDAT 36 | 36 20 | 20 12 | 12
-
-
-

-

These settings and informational values can be accessed at runtime - with the sysctl(8) command. If multiple RME HDSPe sound - cards are installed, each device has a separate configuration. To adjust the - following sysctl identifiers for a specific sound card, insert the - respective device number in place of - ‘0’.

-
-
dev.hdspe.0.sample_rate
-
Set a fixed sample rate from 32000, 44100, 48000, up to 192000. This is - usually required for digital connections (AES, S/PDIF, ADAT). The default - value of 0 adjusts the sample rate according to pcm device settings.
-
dev.hdspe.0.period
-
The number of samples processed per interrupt, from 32, 64, 128, up to - 4096. Setting a lower value here results in less latency, but increases - system load due to frequent interrupt processing. Extreme values may cause - audio gaps and glitches.
-
dev.hdspe.0.clock_list
-
Lists possible clock sources to sync with, depending on the hardware - model. This includes internal and external master clocks as well as - incoming digital audio signals like AES, S/PDIF and ADAT.
-
dev.hdspe.0.clock_preference
-
Select a preferred clock source from the clock list. HDSPe cards will sync - to this clock source when available, but fall back to auto-sync with any - other digital clock signal they receive. Set this to - ‘internal’ if the HDSPe card should - act as master clock.
-
dev.hdspe.0.clock_source
-
Shows the actual clock source in use (read only). This differs from what - is set as clock preference when in auto-sync mode.
-
dev.hdspe.0.sync_status
-
Display the current sync status of all external clock sources. Status - indications are ‘none’ for no signal - at all, ‘lock’ for when a valid - signal is present, and ‘sync’ for - accurately synchronized signals (required for recording digital - audio).
-
-

The following tunables are applicable to HDSPe AIO devices - only:

-
-
dev.hdspe.0.input_level
-
Select the sensitivity of the analog line input. Available reference - levels for the input signal are - ‘LowGain’, - ‘+4dBu’ and - ‘-10dBV’.
-
dev.hdspe.0.output_level
-
Select the gain level of the analog line output. Available reference - levels for the output signal are - ‘HighGain’, - ‘+4dBu’ and - ‘-10dBV’.
-
dev.hdspe.0.phones_level
-
Adjust the gain level of the phones output, separately from the analog - line output. Available reference levels for the output signal are - ‘HighGain’, - ‘+4dBu’ and - ‘-10dBV’.
-
-

Where appropriate these sysctl values are modeled after official - RME software on other platforms, and adopt their terminology. Consult the - RME user manuals for additional information.

-
-
-

-

sound(4)

-
-
-

-

The snd_hdspe device driver first appeared - in FreeBSD 10.0.

-
-
-

-

The snd_hdspe driver was written by - Ruslan Bukin <br@bsdpad.com>. - Florian Walpen <dev@submerge.ch> contributed - clock source settings and restructured the pcm device mapping.

-
-
- - - - - -
November 2, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_ich.4 4.html b/static/freebsd/man4/snd_ich.4 4.html deleted file mode 100644 index 7f05cb94..00000000 --- a/static/freebsd/man4/snd_ich.4 4.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
SND_ICH(4)Device Drivers ManualSND_ICH(4)
-
-
-

-

snd_ich — Intel - ICH AC'97 and compatible bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_ich
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_ich_load="YES"
-
-
-
-

-

The snd_ich bridge driver allows the - generic audio driver sound(4) to attach to Intel ICH AC'97 - and compatible audio devices.

-

Some later chips, like ICH6/ICH7, depending on wiring can instead - implement newer Intel HD Audio specification, which is supported by - snd_hda(4) driver.

-
-
-

-

The snd_ich driver supports the following - audio devices:

-

-
    -
  • AMD 768
    • -
  • AMD 8111
    • -
  • Intel 443MX
    • -
  • Intel ICH
    • -
  • Intel ICH revision 1
    • -
  • Intel ICH2
    • -
  • Intel ICH3
    • -
  • Intel ICH4
    • -
  • Intel ICH5
    • -
  • Intel ICH6
    • -
  • Intel ICH7
    • -
  • NVIDIA nForce
    • -
  • NVIDIA nForce2
    • -
  • NVIDIA nForce2 400
    • -
  • NVIDIA nForce3
    • -
  • NVIDIA nForce3 250
    • -
  • NVIDIA nForce4
    • -
  • SiS 7012
    • -
-
-
-

-

snd_hda(4), sound(4)

-
-
-

-

The snd_ich device driver first appeared - in FreeBSD 4.2.

-
-
-

-

This manual page was written by Jorge Mario G. - Mazo - <jgutie11@eafit.edu.co>.

-
-
- - - - - -
January 6, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_maestro3.4 3.html b/static/freebsd/man4/snd_maestro3.4 3.html deleted file mode 100644 index a0fbfec1..00000000 --- a/static/freebsd/man4/snd_maestro3.4 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
SND_MAESTRO3(4)Device Drivers ManualSND_MAESTRO3(4)
-
-
-

-

snd_maestro3 — ESS - Maestro3/Allegro-1 bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_maestro3
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_maestro3_load="YES"
-
-
-
-

-

The snd_maestro3 driver provides support - for the ESS Maestro3 and Allegro-1 sound chips under the PCM framework. - These chips are mostly found in laptop computers and feature an AC97 mixer, - a multi-channel sample rate converter that can mix up to four digital audio - streams in hardware, recording support, and external volume control - buttons.

-

The firmware for the sound processor is licensed under the GNU - Public License, and thus this driver is not included in the default - GENERIC kernel.

-
-
-

-

The snd_maestro3 driver supports the - following audio devices:

-

-
    -
  • ESS Technology Allegro-1
    • -
  • ESS Technology Maestro3
    • -
-
-
-

-

The hardware volume control buttons can be connected to two - different pin sets (GPIO or GD) on the chip, depending on the manufacturer. - The driver has no way of determining this configuration, so a hint may be - used to override the default guess. The default setting for hardware volume - control assumes that GD pins are wired to control the hardware volume. For - systems that have the GPIO pins wired to the hardware volume control - buttons, add the line - “hint.pcm.0.hwvol_config="0"” - to the file /boot/device.hints to override the - default setting.

-
-
-

-

sound(4), loader.conf(5)

-
-
-

-

The snd_maestro3 driver first appeared in - FreeBSD 4.3.

-
-
-

-

Scott Long - <scottl@FreeBSD.org> -
- Darrel Anderson - <anderson@cs.duke.edu>

-
-
- - - - - -
December 15, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_neomagic.4 4.html b/static/freebsd/man4/snd_neomagic.4 4.html deleted file mode 100644 index 3eb44c6c..00000000 --- a/static/freebsd/man4/snd_neomagic.4 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
SND_NEOMAGIC(4)Device Drivers ManualSND_NEOMAGIC(4)
-
-
-

-

snd_neomagic — - NeoMagic 256AV/ZX bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_neomagic
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_neomagic_load="YES"
-
-
-
-

-

The snd_neomagic bridge driver allows the - generic audio driver, sound(4), to attach to the NeoMagic - 256AV/ZX audio devices. These chips are mostly found in laptop - computers.

-
-
-

-

The snd_neomagic driver supports the - following audio devices:

-

-
    -
  • NeoMagic 256AV
    • -
  • NeoMagic 256ZX
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_neomagic device driver first - appeared in FreeBSD 4.0.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
- - - - - -
December 1, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_solo.4 4.html b/static/freebsd/man4/snd_solo.4 4.html deleted file mode 100644 index 96d6821f..00000000 --- a/static/freebsd/man4/snd_solo.4 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
SND_SOLO(4)Device Drivers ManualSND_SOLO(4)
-
-
-

-

snd_solo — ESS - Solo-1/1E PCI bridge device driver

-
-
-

-

device sound -
- device snd_solo

-
-
-

-

The snd_solo bridge driver allows the - generic audio driver sound(4) to attach to the ESS Solo-1x - PCI cards.

-
-
-

-

The snd_solo driver supports the following - sound cards:

-

-
    -
  • ESS Solo-1 (ES1938 Chipset)
    • -
  • ESS Solo-1E (ES1946 Chipset)
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_solo device driver first appeared - in FreeBSD 4.1.

-
-
-

-

Cameron Grant - <cg@FreeBSD.org>

-
-
- - - - - -
November 28, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_spicds.4 3.html b/static/freebsd/man4/snd_spicds.4 3.html deleted file mode 100644 index 8e8d4c5c..00000000 --- a/static/freebsd/man4/snd_spicds.4 3.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - -
SND_SPICDS(4)Device Drivers ManualSND_SPICDS(4)
-
-
-

-

snd_spicds — I2S - SPI audio codec driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device snd_spicds
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_spicds_load="YES"
-
-
-
-

-

The snd_spicds I2S codec driver is used by - several sound drivers for soundcards which use the supported codec - chips.

-
-
-

-

The snd_spicds driver supports the - following codecs:

-

-
    -
  • AK4358
    • -
  • AK4381
    • -
  • AK4396
    • -
  • AK4524
    • -
  • AK4528
    • -
  • WM8770
    • -
-
-
-

-

snd_envy24(4), - snd_envy24ht(4), sound(4)

-
-
-

-

The snd_spicds device driver first - appeared in FreeBSD 6.3.

-
-
-

-

The snd_spicds driver was written by - Konstantin Dimitrov based upon the - snd_envy24(4) driver. This manual page was written by - Alexander Leidinger - <netchild@FreeBSD.org>.

-
-
- - - - - -
May 28, 2007FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_t4dwave.4 3.html b/static/freebsd/man4/snd_t4dwave.4 3.html deleted file mode 100644 index 7c897125..00000000 --- a/static/freebsd/man4/snd_t4dwave.4 3.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
SND_T4DWAVE(4)Device Drivers ManualSND_T4DWAVE(4)
-
-
-

-

snd_t4dwave — - Trident 4DWave bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_t4dwave
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_t4dwave_load="YES"
-
-
-
-

-

The snd_t4dwave bridge driver allows the - generic audio driver, sound(4), to attach to Trident - 4DWave audio devices.

-
-
-

-

The snd_t4dwave driver supports the - following audio devices:

-

-
    -
  • Acer Labs M5451
    • -
  • SIS 7018
    • -
  • Trident 4DWave DX
    • -
  • Trident 4DWave NX
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_t4dwave device driver first - appeared in FreeBSD 4.0.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
- - - - - -
December 1, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_uaudio.4 3.html b/static/freebsd/man4/snd_uaudio.4 3.html deleted file mode 100644 index 7f37619b..00000000 --- a/static/freebsd/man4/snd_uaudio.4 3.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - -
SND_UAUDIO(4)Device Drivers ManualSND_UAUDIO(4)
-
-
-

-

snd_uaudio — USB - audio and MIDI device driver

-
-
-

-

device sound -
- device usb -
- device snd_uaudio

-

In rc.conf(5): -
- kld_list="snd_uaudio"

-

In sysctl.conf(5): -
- hw.usb.uaudio.buffer_ms -
- hw.usb.uaudio.default_bits -
- hw.usb.uaudio.default_channels -
- hw.usb.uaudio.default_rate -
- hw.usb.uaudio.handle_hid -
- hw.usb.uaudio.debug

-
-
-

-

A USB audio device consists of a number of components: input - terminals (e.g. USB digital input), output terminals (e.g. speakers), and a - number of units in between (e.g. volume control).

-

If the device supports multiple configurations, and there have - been no user-supplied values specified through the - sysctl(8) interface, the driver will select the best - matching configuration supported by the device during attach. - "Best" means the configuration with the most channels and highest - quality in sample rate and sample size.

-

Refer to the ‘USB Audio Class - Specification’ for more information.

-
-
-

-

The snd_uaudio driver provides support for - USB audio class devices and USB MIDI class devices.

-
-
-

-

The following settings can be entered at the - loader(8) prompt or in loader.conf(5) - and can also be changed at runtime with the sysctl(8) - command. For a change to take effect during runtime, the device has to be - re-attached.

-
-
hw.usb.uaudio.buffer_ms
-
Period of audio data processed at once, in milliseconds, from 1 to 8 - (default is 4). Lower values mean less latency, but this can result in - audible gaps due to frequent CPU wakeups.
-
hw.usb.uaudio.default_bits
-
Preferred sample size in bits, from 0 to 32 (default is 0). A value of 0 - sets the sample size to the maximum supported sample size. -

Set this to select a smaller sample size if the device - supports multiple sample sizes.

-
-
hw.usb.uaudio.default_channels
-
Preferred number of sample channels, from 0 to 64 (default is 0). USB 1.1 - devices are limited to 4 channels due to bandwidth constraints, unless a - higher value is explicitly requested. A value of 0 sets the sample - channels to the maximum supported channel number. -

Set this to select a smaller channel number if the device - supports multiple channel configurations.

-
-
hw.usb.uaudio.default_rate
-
Preferred sample rate in Hz (default is 0). If set to 0, the device's - highest supported sample rate will be used. -

Note that if VCHANs are enabled, the sample rate will be - overridden by dev.pcm.%d.[play|rec].vchanrate - (see sound(4)), which can also be used to adjust the - sample rate during runtime.

-

If hw.usb.uaudio.default_rate is - non-zero, dev.pcm.%d.[play|rec].vchanrate will - use it as its maximum allowed value.

-
-
hw.usb.uaudio.handle_hid
-
Let snd_uaudio handle HID volume keys, if any - (default is 1). -
-
0
-
Disabled.
-
1
-
Enabled.
-
-
-
-

If usb(4) has been compiled with - USB_DEBUG on, the following setting is also - available:

-
-
hw.usb.uaudio.debug
-
Debug output level (default is 0).
-
-
-
-

-

sound(4), usb(4), - loader.conf(5), loader(8), - sysctl(8)

-

USB Audio Class - Specifications, - http://www.usb.org/developers/docs/devclass_docs/.

-
-
-

-

The snd_uaudio driver first appeared in - FreeBSD 4.7.

-
-
-

-

This manual page was adopted from NetBSD - 1.6 and modified for FreeBSD by - Hiten Pandya - <hmp@FreeBSD.org>.

-
-
-

-

The PCM framework in FreeBSD currently - does not support the full set of USB audio mixer controls. Some mixer - controls are only available as dev.pcm.%d.mixer - sysctls.

-
-
- - - - - -
July 17, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_via8233.4 4.html b/static/freebsd/man4/snd_via8233.4 4.html deleted file mode 100644 index 85699976..00000000 --- a/static/freebsd/man4/snd_via8233.4 4.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
SND_VIA8233(4)Device Drivers ManualSND_VIA8233(4)
-
-
-

-

snd_via8233 — VIA - Technologies VT8233 bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_via8233
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_via8233_load="YES"
-
-
-
-

-

The snd_via8233 bridge driver allows the - generic audio driver, sound(4), to attach to the VIA - VT8233 audio devices. These audio chipsets are integrated in the southbridge - on many VIA based motherboards.

-
-

-

The following sysctl(8) variables are available - in addition to those available to all sound(4) - devices:

-
-
-
dev.pcm.%d.polling
-
Experimental polling mode, where the driver operates by querying the - device state on each tick using callout(9). Polling is - disabled by default. Do not enable it unless you are facing weird - interrupt problems or if the device cannot generate interrupts at - all.
-
-
-
-
-
-

-

The snd_via8233 driver supports the - following audio chipsets:

-

-
    -
  • VIA VT8233
    • -
  • VIA VT8233A
    • -
  • VIA VT8233C
    • -
  • VIA VT8235
    • -
  • VIA VT8237
    • -
  • VIA VT8251
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_via8233 device driver first - appeared in FreeBSD 4.7.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
-

-

The snd_via8233 driver does not support - S/PDIF. There is partial support in the code, so implementing it should be - fairly easy if the right hardware is available.

-
-
- - - - - -
November 29, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_via82c686.4 3.html b/static/freebsd/man4/snd_via82c686.4 3.html deleted file mode 100644 index 72451c18..00000000 --- a/static/freebsd/man4/snd_via82c686.4 3.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
SND_VIA82C686(4)Device Drivers ManualSND_VIA82C686(4)
-
-
-

-

snd_via82c686 — - VIA Technologies 82C686A bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_via82c686
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_via82c686_load="YES"
-
-
-
-

-

The snd_via82c686 bridge driver allows the - generic audio driver, sound(4), to attach audio devices - based on the VIA 82C686A chipset.

-
-
-

-

The snd_via82c686 driver supports audio - devices based on the following chipset:

-

-
    -
  • VIA 82C686A
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_via82c686 device driver first - appeared in FreeBSD 4.2.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
- - - - - -
December 1, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/snd_vibes.4 4.html b/static/freebsd/man4/snd_vibes.4 4.html deleted file mode 100644 index b6e8df63..00000000 --- a/static/freebsd/man4/snd_vibes.4 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
SND_VIBES(4)Device Drivers ManualSND_VIBES(4)
-
-
-

-

snd_vibes — S3 - SonicVibes bridge device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sound -
-device snd_vibes
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
snd_vibes_load="YES"
-
-
-
-

-

The snd_vibes bridge driver allows the - generic audio driver, sound(4), to attach audio devices - based on the S3 SonicVibes chipset.

-
-
-

-

The snd_vibes driver supports audio - devices based on the following chipset:

-

-
    -
  • S3 SonicVibes
    • -
-
-
-

-

sound(4)

-
-
-

-

The snd_vibes device driver first appeared - in FreeBSD 4.4.

-
-
-

-

This manual page was written by Joel Dahl - <joel@FreeBSD.org>.

-
-
- - - - - -
December 1, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/sndstat.4 3.html b/static/freebsd/man4/sndstat.4 3.html deleted file mode 100644 index 30f37c7f..00000000 --- a/static/freebsd/man4/sndstat.4 3.html +++ /dev/null @@ -1,382 +0,0 @@ - - - - - - -
SNDSTAT(4)Device Drivers ManualSNDSTAT(4)
-
-
-

-

sndstat — - nvlist-based PCM audio device enumeration - interface

-
-
-

-

To compile the driver into the kernel, place the following lines - in the kernel configuration file:

-
device sound
-
-
-

-

The ioctl interface provided by - /dev/sndstat device allows callers to enumerate PCM - audio devices available for use. In other words, it provides means to get - the list of all audio devices available to the system.

-
-
-

-

For ioctl calls that take an argument, the following structure is - used:

-
-
struct sndstioc_nv_arg {
-	size_t nbytes;
-	void *buf;
-};
-
-

Here is an example of an nvlist object with explanations of the - common fields:

-
-
dsps (NVLIST ARRAY): 1
-	from_user (BOOL): FALSE
-	nameunit (STRING): [pcm0]
-	devnode (STRING): [dsp0]
-	desc (STRING): [Generic (0x8086) (Analog Line-out)]
-	pchan (NUMBER): 1
-	rchan (NUMBER): 0
-	info_play (NVLIST):
-		min_rate (NUMBER): 48000
-		max_rate (NUMBER): 48000
-		formats (NUMBER): 16
-		min_chn (NUMBER): 2
-		max_chn (NUMBER): 2
-	provider_info (NVLIST):
-		unit (NUMBER): 0
-		status (STRING): on hdaa0
-		bitperfect (BOOL): FALSE
-		pvchan (BOOL): TRUE
-		pvchanrate (NUMBER): 48000
-		pvchanformat (NUMBER): 0x00000010
-		rvchan (BOOL): TRUE
-		rvchanrate (NUMBER): 48000
-		rvchanformat (NUMBER): 0x00000010
-		channel_info (NVLIST_ARRAY): 1
-			name (STRING): dsp0.virtual_play.0
-			parentchan (STRING): dsp0.play.0
-			unit (NUMBER): 1
-			caps (NUMBER): 0x073200
-			latency (NUMBER): 2
-			rate (NUMBER): 48000
-			format (NUMBER): 0x201000
-			pid (NUMBER): 1234
-			comm (STRING): mpv
-			interrupts (NUMBER): 0
-			feedcount (NUMBER): 0
-			xruns (NUMBER): 0
-			left_volume (NUMBER): 45
-			right_volume (NUMBER): 45
-			hwbuf_fmt (NUMBER): 0x200010
-			hwbuf_rate (NUMBER): 48000
-			hwbuf_size (NUMBER): 0
-			hwbuf_blksz (NUMBER): 0
-			hwbuf_blkcnt (NUMBER): 0
-			hwbuf_free (NUMBER): 0
-			hwbuf_ready (NUMBER): 0
-			swbuf_fmt (NUMBER): 0x201000
-			swbuf_rate (NUMBER): 48000
-			swbuf_size (NUMBER): 16384
-			swbuf_blksz (NUMBER): 2048
-			swbuf_blkcnt (NUMBER): 8
-			swbuf_free (NUMBER): 16384
-			swbuf_ready (NUMBER): 0
-			feederchain (STRING):
-				[userland ->
-				feeder_root(0x00201000) ->
-				feeder_format(0x00201000 -> 0x00200010) ->
-				feeder_volume(0x00200010) -> hardware]
-	provider (STRING): [sound(4)]
-
-
-
-
Whether the PCM audio device node is created by in-kernel audio subsystem - or userspace providers.
-
-
The device identification in the form of subsystem plus a unit - number.
-
-
The PCM audio device node relative path in devfs.
-
-
The description of the PCM audio device.
-
-
The number of playback channels supported by hardware. This can be 0 if - this PCM audio device does not support playback at all.
-
-
The number of recording channels supported by hardware. This can be 0 if - this PCM audio device does not support recording at all.
-
-
Supported configurations in playback direction. This exists only if this - PCM audio device supports playback. There are a number of name/value pairs - inside this field: -
-
-
Minimum supported sampling rate.
-
-
Maximum supported sampling rate.
-
-
Supported sample formats.
-
-
Minimum supported number of channels in channel layout
-
-
Maximum supported number of channels in channel layout
-
-
-
-
Supported configurations in recording direction. This exists only if this - PCM audio device supports recording. There are a number of name/value - pairs inside this field: -
-
-
Minimum supported sampling rate.
-
-
Maximum supported sampling rate.
-
-
Supported sample formats.
-
-
Minimum supported number of channels in channel layout
-
-
Maximum supported number of channels in channel layout
-
-
-
-
Provider-specific fields. This field may not exist if the PCM audio device - is not provided by in-kernel interface. This field will not exist if the - provider field is an empty string. For the sound(4) - provider, there are a number of name/value pairs inside this field: -
-
-
Sound card unit.
-
-
Status string. Usually reports the driver the device is attached - on.
-
-
Whether the sound card has bit-perfect mode enabled.
-
-
Playback virtual channels enabled.
-
-
Playback virtual channel sample rate.
-
-
Playback virtual channel format.
-
-
Recording virtual channels enabled.
-
-
Recording virtual channel sample rate.
-
-
Recording virtual channel format.
-
-
Channel information. There are a number of name/value pairs inside - this field: -
-
-
Channel name.
-
-
Parent channel name (e.g., in the case of virtual channels).
-
-
Channel unit.
-
-
OSS capabilities.
-
-
Latency.
-
-
Sampling rate.
-
-
Sampling format.
-
-
PID of the process consuming the channel.
-
-
Name of the process consuming the channel.
-
-
Number of interrupts since the channel has been opened.
-
-
Number of overruns/underruns, depending on channel direction.
-
-
Number of read/written bytes since the channel has been - opened.
-
-
Left volume.
-
-
Right volume.
-
-
Hardware buffer format.
-
-
Hardware buffer sample rate;
-
-
Hardware buffer size.
-
-
Hardware buffer block size.
-
-
Hardware buffer block count.
-
-
Free space in hardware buffer (in bytes).
-
-
Number of bytes ready to be read/written from hardware - buffer.
-
-
Software buffer format.
-
-
Software buffer sample rate;
-
-
Software buffer size.
-
-
Software buffer block size.
-
-
Software buffer block count.
-
-
Free space in software buffer (in bytes).
-
-
Number of bytes ready to be read/written from software - buffer.
-
-
Channel feeder chain.
-
-
-
-
-
-
A string specifying the provider of the PCm audio device.
-
-

The following ioctls are provided for use:

-
-
-
Drop any previously fetched PCM audio devices list snapshots. This ioctl - takes no arguments.
-
-
Generate and/or return PCM audio devices list snapshots to callers. This - ioctl takes a pointer to struct sndstioc_nv_arg as - the first and the only argument. Callers need to provide a sufficiently - large buffer to hold a serialized nvlist. If there is no existing PCM - audio device list snapshot available in the internal structure of the - opened sndstat. fd, a new PCM audio device list - snapshot will be automatically generated. Callers have to set - nbytes to either 0 or the size of buffer provided. - In case nbytes is 0, the buffer size required to - hold a serialized nvlist stream of current snapshot will be returned in - nbytes, and buf will be - ignored. Otherwise, if the buffer is not sufficiently large, the ioctl - returns success, and nbytes will be set to 0. If the - buffer provided is sufficiently large, nbytes will - be set to the size of the serialized nvlist written to the provided - buffer. Once a PCM audio device list snapshot is returned to user-space - successfully, the snapshot stored in the subsystem's internal structure of - the given fd will be freed.
-
-
Add a list of PCM audio devices provided by callers to - /dev/sndstat device. This ioctl takes a pointer to - struct sndstioc_nv_arg as the first and the only - argument. Callers have to provide a buffer holding a serialized nvlist. - nbytes should be set to the length in bytes of the - serialized nvlist. buf should be pointed to a buffer - storing the serialized nvlist. Userspace-backed PCM audio device nodes - should be listed inside the serialized nvlist.
-
-
Flush any PCM audio devices previously added by callers. This ioctl takes - no arguments.
-
-
-
-

-
-
/dev/sndstat
-
 
-
-
-
-

-

The following code enumerates all available PCM audio devices:

-
-
#include <sys/types.h>
-#include <err.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <sys/nv.h>
-#include <sys/sndstat.h>
-#include <sysexits.h>
-#include <unistd.h>
-
-int
-main()
-{
-	int fd;
-	struct sndstioc_nv_arg arg;
-	const nvlist_t * const *di;
-	size_t i, nitems;
-	nvlist_t *nvl;
-
-	/* Open sndstat node in read-only first */
-	fd = open("/dev/sndstat", O_RDONLY);
-
-	if (ioctl(fd, SNDSTIOC_REFRESH_DEVS, NULL))
-		err(1, "ioctl(fd, SNDSTIOC_REFRESH_DEVS, NULL)");
-
-	/* Get the size of snapshot, when nbytes = 0 */
-	arg.nbytes = 0;
-	arg.buf = NULL;
-	if (ioctl(fd, SNDSTIOC_GET_DEVS, &arg))
-		err(1, "ioctl(fd, SNDSTIOC_GET_DEVS, &arg)");
-
-	/* Get snapshot data */
-	arg.buf = malloc(arg.nbytes);
-	if (arg.buf == NULL)
-		err(EX_OSERR, "malloc");
-	if (ioctl(fd, SNDSTIOC_GET_DEVS, &arg))
-		err(1, "ioctl(fd, SNDSTIOC_GET_DEVS, &arg)");
-
-	/* Deserialize the nvlist stream */
-	nvl = nvlist_unpack(arg.buf, arg.nbytes, 0);
-	free(arg.buf);
-
-	/* Get DSPs array */
-	di = nvlist_get_nvlist_array(nvl, SNDST_DSPS, &nitems);
-	for (i = 0; i < nitems; i++) {
-		const char *nameunit, *devnode, *desc;
-
-		/*
-		 * Examine each device nvlist item
-		 */
-
-		nameunit = nvlist_get_string(di[i], SNDST_DSPS_NAMEUNIT);
-		devnode = nvlist_get_string(di[i], SNDST_DSPS_DEVNODE);
-		desc = nvlist_get_string(di[i], SNDST_DSPS_DESC);
-		printf("Name unit: `%s`, Device node: `%s`, Description: `%s`0,
-		    nameunit, devnode, desc);
-	}
-
-	nvlist_destroy(nvl);
-	return (0);
-}
-
-
-
-

-

sound(4), nv(9)

-
-
-

-

The nvlist-based ioctls support for - sndstat device first appeared in - FreeBSD 13.0.

-
-
-

-

This manual page was written by Ka Ho Ng - <khng@FreeBSD.org>.

-
-
- - - - - -
July 26, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/snp.4 3.html b/static/freebsd/man4/snp.4 3.html deleted file mode 100644 index 13a40d86..00000000 --- a/static/freebsd/man4/snp.4 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
SNP(4)Device Drivers ManualSNP(4)
-
-
-

-

snp — tty snoop - interface

-
-
-

-

#include - <sys/snoop.h>

-

int -
- ioctl(fd, - SNPSTTY, - &dev);

-

int -
- ioctl(fd, - SNPGTTY, - &dev);

-

int -
- ioctl(fd, - FIONREAD, - &result);

-
-
-

-

/dev/snp is a snoop device which allows - users to attach to any tty and watch activities on it. The kernel must be - compiled with device snp, or the - snp module must be loaded, for these devices to be - available.

-

To associate a given snp device with a tty - to be observed, open the snp device and a tty - device, and then issue the SNPSTTY ioctl on - snp device. The argument passed to the - ioctl(2) is the address of a variable of type - int, holding the file descriptor of a tty device. To - detach the snp device from a tty use a pointer to a - value of -1.

-

The SNPGTTY ioctl returns information - about the current tty attached to the open snp - device.

-

The FIONREAD ioctl returns a positive - value equal to the number of characters in a read buffer. Special values - defined are:

-
-
-
tty not attached.
-
-
snp device has been detached by user or tty device - has been closed and detached.
-
-
-
-

-

pty(4), kldload(8), - watch(8)

-
-
-

-

The snp device first appeared in - FreeBSD 2.1. In FreeBSD 8.0 - the snp driver was rewritten to work with the - replaced TTY subsystem.

-
-
-

-

The author of the current implementation is Ed - Schouten - <ed@FreeBSD.org>. - Previous versions of snp were based on code written - by Ugen J.S. Antsilevich - <ugen@NetVision.net.il>.

-
-
- - - - - -
September 24, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/spigen.4 3.html b/static/freebsd/man4/spigen.4 3.html deleted file mode 100644 index 4ef64742..00000000 --- a/static/freebsd/man4/spigen.4 3.html +++ /dev/null @@ -1,186 +0,0 @@ - - - - - - -
SPIGEN(4)Device Drivers ManualSPIGEN(4)
-
-
-

-

spigen — SPI - generic I/O device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device spi -
-device spibus -
-device spigen
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
spigen_load="YES"
-
-
-
-

-

The spigen driver provides direct access - to a slave device on the SPI bus. Each instance of a - spigen device is associated with a single - chip-select line on the bus, and all I/O performed through that instance is - done with that chip-select line asserted.

-

SPI data transfers are inherently bi-directional; there are no - separate read and write operations. When commands and data are sent to a - device, data also comes back from the device, although in some cases the - data may not be useful (or even documented or predictable for some devices). - Likewise on a read operation, whatever data is in the buffer at the start of - the operation is sent to (and typically ignored by) the device, with each - outgoing byte then replaced in the buffer by the corresponding incoming - byte. Thus, all buffers passed to the transfer functions are both input and - output buffers.

-

The spigen driver provides access to the - SPI slave device with the following ioctl(2) calls, - defined in - <sys/spigenio.h>:

-
-
- (struct spigen_transfer)
-
Transfer a command and optional associated data to/from the device, using - the buffers described by the st_command and st_data fields in the - spigen_transfer. Set - st_data.iov_len to zero if there is no data - associated with the command. -
- 
struct spigen_transfer {
-	struct iovec st_command;
-	struct iovec st_data;
-};
-
-
-
- (spigen_transfer_mmapped)
-
Transfer a command and optional associated data to/from the device. The - buffers for the transfer are a previously-mmap'd region. The length of the - command and data within that region are described by the - stm_command_length and - stm_data_length fields of - spigen_transfer_mmapped. If - stm_data_length is non-zero, the data appears in the - memory region immediately following the command (that is, at offset - stm_command_length from the start of the mapped - region). -
- 
struct spigen_transfer_mmapped {
-	size_t stm_command_length;
-	size_t stm_data_length;
-};
-
-
-
- (uint32_t)
-
Get the maximum clock speed (bus frequency in Hertz) to be used when - communicating with this slave device.
-
- (uint32_t)
-
Set the maximum clock speed (bus frequency in Hertz) to be used when - communicating with this slave device. The setting remains in effect for - subsequent transfers; it is not necessary to reset this before each - transfer. The actual bus frequency may be lower due to hardware - limitations of the SPI bus controller device.
-
- (uint32_t)
-
Get the SPI mode (clock polarity and phase) to be used when communicating - with this device.
-
- (uint32_t)
-
Set the SPI mode (clock polarity and phase) to be used when communicating - with this device. The setting remains in effect for subsequent transfers; - it is not necessary to reset this before each transfer.
-
-
-
-

-

On a device.hints(5) based system, such as - MIPS, these values are configurable for - spigen:

-
-
hint.spigen.%d.at
-
The spibus the spigen instance is attached - to.
-
hint.spigen.%d.clock
-
The maximum bus frequency to use when communicating with this device. - Actual bus speed may be lower, depending on the capabilities of the SPI - bus controller hardware.
-
hint.spigen.%d.cs
-
The chip-select number to assert when performing I/O for this device. Set - the high bit (1 << 31) to invert the logic level of the chip select - line.
-
hint.spigen.%d.mode
-
The SPI mode (0-3) to use when communicating with this device.
-
-
-
-

-

On an fdt(4) based system, the spigen device is - defined as a slave device subnode of the SPI bus controller node. All - properties documented in the spibus.txt bindings - document can be used with the spigen device. The - most commonly-used ones are documented below.

-

The following properties are required in the - spigen device subnode:

-
-
compatible
-
Must be the string "freebsd,spigen".
-
reg
-
Chip select address of device.
-
spi-max-frequency
-
The maximum bus frequency to use when communicating with this slave - device. Actual bus speed may be lower, depending on the capabilities of - the SPI bus controller hardware.
-
-

The following properties are optional for the - spigen device subnode:

-
-
spi-cpha
-
Empty property indicating the slave device requires shifted clock phase - (CPHA) mode.
-
spi-cpol
-
Empty property indicating the slave device requires inverse clock polarity - (CPOL) mode.
-
spi-cs-high
-
Empty property indicating the slave device requires chip select active - high.
-
-
-
-

-
-
/dev/spigen*
-
 
-
-
-
-

-

fdt(4), device.hints(5), - spi(8)

-
-
-

-

The spigen driver appeared in - FreeBSD 11.0. FDT support appeared in - FreeBSD 11.2.

-
-
- - - - - -
August 21, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/spkr.4 3.html b/static/freebsd/man4/spkr.4 3.html deleted file mode 100644 index 08556eba..00000000 --- a/static/freebsd/man4/spkr.4 3.html +++ /dev/null @@ -1,191 +0,0 @@ - - - - - - -
SPKR(4)Device Drivers ManualSPKR(4)
-
-
-

-

speaker, spkr - — console speaker device driver

-
-
-

-

device speaker -
- #include - <dev/speaker/speaker.h>

-
-
-

-

The speaker device driver allows applications to control the PC - console speaker on an IBM-PC--compatible machine running - FreeBSD.

-

Only one process may have this device open at any given time; - open(2) and close(2) are used to lock - and relinquish it. An attempt to open when another process has the device - locked will return -1 with an EBUSY error - indication. Writes to the device are interpreted as `play strings' in a - simple ASCII melody notation. An ioctl(2) request for tone - generation at arbitrary frequencies is also supported.

-

Sound-generation does not monopolize the processor; in fact, the - driver spends most of its time sleeping while the PC hardware is emitting - tones. Other processes may emit beeps while the driver is running.

-

Applications may call ioctl(2) on a speaker file - descriptor to control the speaker driver directly; definitions for the - ioctl(2) interface are in - <dev/speaker/speaker.h>. The - tone_t structure used in these calls has two fields, - specifying a frequency (in Hz) and a duration (in 1/100ths of a second). A - frequency of zero is interpreted as a rest.

-

At present there are two such ioctl(2) calls. - SPKRTONE accepts a pointer to a single tone - structure as third argument and plays it. SPKRTUNE - accepts a pointer to the first of an array of tone structures and plays them - in continuous sequence; this array must be terminated by a final member with - a zero duration.

-

The play-string language is modeled on the PLAY statement - conventions of IBM Advanced BASIC 2.0. The MB, - MF, and X primitives of PLAY - are not useful in a timesharing environment and are omitted. The - `octave-tracking' feature and the slur mark are new.

-

There are 84 accessible notes numbered 1-84 in 7 octaves, each - running from C to B, numbered 0-6; the scale is equal-tempered A440 and - octave 3 starts with middle C. By default, the play function emits - half-second notes with the last 1/16th second being `rest time'.

-

Play strings are interpreted left to right as a series of play - command groups; letter case is ignored. Play command groups are as - follows:

-
-
-
Letters A through G cause the corresponding note to be played in the - current octave. A note letter may optionally be followed by an - “”, one of # + or -; the first two of these cause it to - be sharped one half-tone, the last causes it to be flatted one half-tone. - It may also be followed by a time value number and by sustain dots (see - below). Time values are interpreted as for the L command below.
-
O n
-
If n is numeric, this sets the current octave. - n may also be one of L or - N to enable or disable octave-tracking (it is - disabled by default). When octave-tracking is on, interpretation of a pair - of letter notes will change octaves if necessary in order to make the - smallest possible jump between notes. Thus ``olbc'' will be played as - ``olb>c'', and ``olcb'' as ``olc<b''. Octave locking is disabled for - one letter note following >, < and O[0123456]. (The octave-locking - feature is not supported in IBM BASIC.)
-
-
Bump the current octave up one.
-
-
Drop the current octave down one.
-
N n
-
Play note n, n being 1 to 84 or 0 for - a rest of current time value. May be followed by sustain dots.
-
L n
-
Sets the current time value for notes. The default is - L4, quarter or crotchet notes. The lowest possible - value is 1; values up to 64 are accepted. L1 sets - whole notes, L2 sets half notes, - L4 sets quarter notes, etc.
-
P n
-
Pause (rest), with n interpreted as for - L n. May be followed by sustain - dots. May also be written ~.
-
T n
-
Sets the number of quarter notes per minute; default is 120. Musical names - for common tempi are: -
- 
        	Tempo    	Beats Per Minute
-very slow	Larghissimo
-        	Largo    	40-60
-         	Larghetto    	60-66
-        	Grave
-        	Lento
-        	Adagio       	66-76
-slow    	Adagietto
-        	Andante   	76-108
-medium   	Andantino
-        	Moderato	108-120
-fast    	Allegretto
-        	Allegro   	120-168
-        	Vivace
-        	Veloce
-        	Presto    	168-208
-very fast	Prestissimo
-
-
-
-
Set articulation. MN (N - for normal) is the default; the last 1/8th of the note's value is rest - time. You can set ML for legato (no rest space) or - MS for staccato (1/4 rest space).
-
-

Notes (that is, CDEFGAB or - N command character groups) may be followed by - sustain dots. Each dot causes the note's value to be lengthened by one-half - for each one. Thus, a note dotted once is held for 3/2 of its undotted - value; dotted twice, it is held 9/4, and three times would give 27/8.

-

A note and its sustain dots may also be followed by a slur mark - (underscore). This causes the normal micro-rest after the note to be filled - in, slurring it to the next one. (The slur feature is not supported in IBM - BASIC.)

-

Whitespace in play strings is simply skipped and may be used to - separate melody sections.

-
-
-

-
-
/dev/speaker
-
speaker device file
-
-
-
-

-

spkrtest(8)

-
-
-

-

The speaker device appeared in - FreeBSD 1.0.

-
-
-

-

Eric S. Raymond - <esr@snark.thyrsus.com>, - June 1990

-
-
-

-
-

Andrew A. Chernov - <ache@astral.msk.su>

-
-
-

-

Due to roundoff in the pitch tables and slop in the - tone-generation and timer hardware (neither of which was designed for - precision), neither pitch accuracy nor timings will be mathematically exact. - There is no volume control.

-

The action of two or more sustain dots does not reflect standard - musical notation, in which each dot adds half the value of the previous dot - modifier, not half the value of the note as modified. Thus, a note dotted - once is held for 3/2 of its undotted value; dotted twice, it is held 7/4, - and three times would give 15/8. The multiply-by-3/2 interpretation, - however, is specified in the IBM BASIC manual and has been retained for - compatibility.

-

In play strings which are very long (longer than your system's - physical I/O blocks) note suffixes or numbers may occasionally be parsed - incorrectly due to crossing a block boundary.

-
-
- - - - - -
November 10, 2005FreeBSD 15.0
diff --git a/static/freebsd/man4/splash.4 3.html b/static/freebsd/man4/splash.4 3.html deleted file mode 100644 index ed33cd45..00000000 --- a/static/freebsd/man4/splash.4 3.html +++ /dev/null @@ -1,260 +0,0 @@ - - - - - - -
SPLASH(4)Device Drivers ManualSPLASH(4)
-
-
-

-

splash — splash - screen / screen saver interface

-
-
-

-

device splash

-
-
-

-

The splash pseudo device driver adds - support for the splash screen and screen savers to the kernel. This driver - is required if the splash bitmap image is to be loaded or any screen saver - is to be used.

-
-

-

You can load and display an arbitrary bitmap image file as a - welcome banner on the screen when the system is about to start. This image - will remain on the screen during kernel initialization process until the - login prompt appears on the screen or until a screen saver is loaded and - initialized. The image will also disappear if you hit any key, although this - may not work immediately if the kernel is still probing devices.

-

If you specify the -c or - -v boot option when loading the kernel, the splash - image will not appear. However, it is still loaded and can be used as a - screen saver later: see below.

-

In order to display the bitmap, the bitmap file itself and the - matching splash image decoder module must be loaded by the boot loader. - Currently the following decoder modules are available:

-

-
-
splash_bmp.ko
-
Windows BMP file decoder. While the BMP file format allows images of - various color depths, this decoder currently only handles 256 color - bitmaps. Bitmaps of other color depths will not be displayed.
-
splash_pcx.ko
-
ZSoft PCX decoder. This decoder currently only supports version 5 8-bpp - single-plane images.
-
splash_txt.ko
-
TheDraw binary ASCII drawing file decoder. Displays a text-mode 80x25 - ASCII drawing, such as that produced by the Binary save format in TheDraw. - This format consists of a sequence of two byte pairs representing the - 80x25 display, where the first byte is the ASCII character to draw and the - second byte indicates the colors/attributes to use when drawing the - character.
-
-

The EXAMPLES section - illustrates how to set up the splash screen.

-

If the standard VGA video mode is used, the size of the bitmap - must be 320x200 or less. If you enable the VESA mode support in the kernel, - either by statically linking the VESA module or by loading the VESA module - (see vga(4)), you can load bitmaps up to a resolution of - 1024x768, depending on the VESA BIOS and the amount of video memory on the - video card.

-
-
-

-

The screen saver will activate when the system is considered idle: - i.e. when the user has not typed a key or moved the mouse for a specified - period of time. As the screen saver is an optional module, it must be - explicitly loaded into memory. Currently the following screen saver modules - are available:

-

-
-
blank_saver.ko
-
This screen saver simply blanks the screen.
-
beastie_saver.ko
-
Animated graphical BSD Daemon.
-
daemon_saver.ko
-
Animated BSD Daemon screen saver.
-
dragon_saver.ko
-
Draws a random dragon curve.
-
fade_saver.ko
-
The screen will gradually fade away.
-
fire_saver.ko
-
A fire which becomes higher as load increases.
-
green_saver.ko
-
The screen will be blanked, similar to - blank_saver.ko. If the monitor and the video - card's BIOS support it the screen will also be powered off.
-
logo_saver.ko
-
Animated graphical FreeBSD logo.
-
plasma_saver.ko
-
Draws an animated interference pattern.
-
rain_saver.ko
-
Draws a shower on the screen.
-
snake_saver.ko
-
Draws a snake of string.
-
star_saver.ko
-
Twinkling stars.
-
warp_saver.ko
-
Streaking stars.
-
-

Screen saver modules can be loaded using - kldload(8):

-

-
kldload logo_saver
-

The timeout value in seconds can be specified as follows:

-

-
vidcontrol -t N
-

Alternatively, you can set the saver - variable in the /etc/rc.conf to the screen saver of - your choice and the timeout value to the blanktime - variable so that the screen saver is automatically loaded and the timeout - value is set when the system starts.

-

The screen saver may be instantly activated by - hitting the saver key: the defaults are - - on the AT enhanced keyboard and - - on the AT 84 keyboard. You can change the saver key by - modifying the keymap (see kbdcontrol(1), - keymap(5)), and assign the saver - function to a key of your preference.

-

The screen saver will not run if the screen is not in text - mode.

-
-
-

-

If you load a splash image but do not load a screen saver, you can - continue using the splash module as a screen saver. The screen blanking - interval can be specified as described in the - Screen saver section above.

-
-
-
-

-
-
/boot/defaults/loader.conf
-
boot loader configuration defaults
-
/etc/rc.conf
-
system configuration information
-
/boot/kernel/splash_*.ko
-
splash image decoder modules
-
/boot/kernel/*_saver.ko
-
screen saver modules
-
/boot/kernel/vesa.ko
-
the VESA support module
-
-
-
-

-

In order to load the splash screen or the screen saver, you must - have the following line in the kernel configuration file.

-

-
device splash
-

Next for syscons(4), edit - /boot/loader.conf (see - loader.conf(5)) and include the following lines:

-
-
splash_bmp_load="YES"
-bitmap_load="YES"
-bitmap_name="/boot/chuck.bmp"
-
-

In the above example, the file - /boot/chuck.bmp is loaded. In the following example, - the VESA module is loaded so that a bitmap file which cannot be displayed in - standard VGA modes may be shown using one of the VESA video modes.

-
-
splash_pcx_load="YES"
-vesa_load="YES"
-bitmap_load="YES"
-bitmap_name="/boot/chuck.pcx"
-
-

If the VESA support is statically linked to the kernel, it is not - necessary to load the VESA module. Just load the bitmap file and the splash - decoder module as in the first example above.

-

To load a binary ASCII drawing and display this while booting, - include the following into your - /boot/loader.conf:

-
-
splash_txt_load="YES"
-bitmap_load="YES"
-bitmap_name="/boot/splash.bin"
-
-

For vt(4), edit - /boot/loader.conf (see - loader.conf(5)) and include the following lines:

-
-
splash="/boot/images/freebsd-logo-rev.png"
-boot_mute="YES"
-
-

A splash screen to be displayed at shutdown time can be specified - with:

-
-
shutdown_splash="/boot/images/freebsd-logo-rev.png"
-boot_mute="YES"
-
-
-
-

-

vidcontrol(1), syscons(4), - vga(4), loader.conf(5), - rc.conf(5), kldload(8), - kldunload(8)

-
-
-

-

The splash driver first appeared in - FreeBSD 3.1.

-
-
-

-

The splash driver and this manual page - were written by Kazutaka Yokota - <yokota@FreeBSD.org>. - The splash_bmp module was written by - Michael Smith - <msmith@FreeBSD.org> - and Kazutaka Yokota. The - splash_pcx module was written by - Dag-Erling Smørgrav - <des@FreeBSD.org> - based on the splash_bmp code. The - splash_txt module was written by - Antony Mawer - <antony@mawer.org> - based on the splash_bmp code, with some additional - inspiration from the daemon_saver code. The - logo_saver, plasma_saver, - rain_saver and warp_saver - modules were written by Dag-Erling Smørgrav - <des@FreeBSD.org>. - splash png support for vt(4) was - written by Emmanuel Vadot - <manu@FreeBSD.org> - and extended for shutdown by Quentin Thébault - <quentin.thebault@defenso.fr>.

-
-
-

-

The screen saver works with syscons(4) only.

-

For vt splash screen, only RGBA png are supported.

-
-
-

-

If you load a screen saver while another screen saver has already - been loaded, the first screen saver will not be automatically unloaded and - will remain in memory, wasting kernel memory space.

-
-
- - - - - -
April 3, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/ste.4 3.html b/static/freebsd/man4/ste.4 3.html deleted file mode 100644 index 615e008f..00000000 --- a/static/freebsd/man4/ste.4 3.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - -
STE(4)Device Drivers ManualSTE(4)
-
-
-

-

ste — Sundance - Technologies ST201 Fast Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device ste
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ste_load="YES"
-
-
-
-

-

The ste driver provides support for PCI - Ethernet adapters and embedded controllers based on the Sundance - Technologies ST201 PCI Fast Ethernet controller chip.

-

The Sundance ST201 uses bus master DMA and is designed to be a - 3Com Etherlink XL workalike. It uses the same DMA descriptor structure and - is very similar in operation, however its register layout is different. The - ST201 has a 64-bit multicast hash filter and a single perfect filter entry - for the station address. It supports both 10 and 100Mbps speeds in either - full or half duplex using an MII transceiver.

-

The ste driver supports the following - media types:

-
-
autoselect
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file.
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to select either full-duplex - or half-duplex modes.
-
-

The ste driver supports the following - media options:

-
-
full-duplex
-
Force full duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ste driver supports Sundance - Technologies ST201 based Fast Ethernet adapters and embedded controllers - including:

-

-
    -
  • D-Link DFE-530TXS
    • -
  • D-Link DFE-550TX
    • -
  • D-Link DFE-580TX
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.ste.%d.int_rx_mod
-
Maximum number of time to delay RX interrupts. The valid range is 0 to - 209712 in units of 1us, the default is 150 (150us). The value 0 - effectively disables the RX interrupt moderation. The resolution of timer - is about 3.2us so finer tuning than 3.2us wouldn't be available. The - interface does not need to be brought down and up again before a change - takes effect.
-
-
-
-

-
-
ste%d: couldn't map ports/memory
-
A fatal initialization error has occurred.
-
ste%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
ste%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
ste%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
ste%d: no memory for tx list
-
The driver failed to allocate an mbuf for the transmitter ring when - allocating a pad buffer or collapsing an mbuf chain into a cluster.
-
ste%d: chip is in D3 power state -- setting to D0
-
This message applies only to adapters which support power management. Some - operating systems place the controller in low power mode when shutting - down, and some PCI BIOSes fail to bring the chip out of this state before - configuring it. The controller loses all of its PCI configuration in the - D3 state, so if the BIOS does not set it back to full power mode in time, - it will not be able to configure it correctly. The driver tries to detect - this condition and bring the adapter back to the D0 (full power) state, - but this may not be enough to return the driver to a fully operational - condition. If you see this message at boot time and the driver fails to - attach the device as a network interface, you will have to perform a - second warm boot to have the device properly configured. -

Note that this condition only occurs when warm booting from - another operating system. If you power down your system prior to booting - FreeBSD, the card should be configured - correctly.

-
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-

Sundance ST201 data - sheet.

-
-
-

-

The ste device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The ste driver was written by - Bill Paul - <wpaul@ee.columbia.edu>.

-
-
- - - - - -
December 24, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/stf.4 3.html b/static/freebsd/man4/stf.4 3.html deleted file mode 100644 index 6dd421ff..00000000 --- a/static/freebsd/man4/stf.4 3.html +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - -
STF(4)Device Drivers ManualSTF(4)
-
-
-

-

stf — 6to4 tunnel - interface

-
-
-

-

device stf

-
-
-

-

The stf interface supports - “6to4” and “6rd” IPv6 in IPv4 encapsulation. It - can tunnel IPv6 traffic over IPv4, as specified in - RFC3056 or RFC5969.

-

For ordinary nodes in a 6to4 or 6RD site, you do not need - stf interface. The stf - interface is necessary for site border routers (called “6to4 - routers” or “6rd Customer Edge (CE)” in the - specification).

-

Each stf interface is created at runtime - using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5).

-
-
-

-

Due to the way 6to4 protocol is specified, - stf interface requires certain configuration to work - properly. Single (no more than 1) valid 6to4 address needs to be configured - to the interface. “A valid 6to4 address” is an address which - has the following properties. If any of the following properties are not - satisfied, stf raises runtime error on packet - transmission. Read the specification for more details.

-
    -
  • matches 2002:xxyy:zzuu::/48 where - xxyy:zzuu is a hexadecimal notation of an IPv4 - address for the node. IPv4 address can be taken from any of interfaces - your node has. Since the specification forbids the use of IPv4 private - address, the address needs to be a global IPv4 address.
    • -
  • Subnet identifier portion (48th to 63rd bit) and interface identifier - portion (lower 64 bits) are properly filled to avoid address - collisions.
    • -
-

If you would like the node to behave as a relay router, the prefix - length for the IPv6 interface address needs to be 16 so that the node would - consider any 6to4 destination as “on-link”. If you would like - to restrict 6to4 peers to be inside certain IPv4 prefix, you may want to - configure IPv6 prefix length as “16 + IPv4 prefix length”. - stf interface will check the IPv4 source address on - packets, if the IPv6 prefix length is larger than 16.

-

stf can be configured to be ECN friendly. - This can be configured by IFF_LINK1. See - gif(4) for details.

-

Please note that 6to4 specification is written as “accept - tunnelled packet from everyone” tunnelling device. By enabling - stf device, you are making it much easier for - malicious parties to inject fabricated IPv6 packet to your node. Also, - malicious party can inject an IPv6 packet with fabricated source address to - make your node generate improper tunnelled packet. Administrators must take - caution when enabling the interface. To prevent possible attacks, - stf interface filters out the following packets. - Note that the checks are no way complete:

-
    -
  • Packets with IPv4 unspecified address as outer IPv4 source/destination - (0.0.0.0/8)
    • -
  • Packets with loopback address as outer IPv4 source/destination - (127.0.0.0/8)
    • -
  • Packets with IPv4 multicast address as outer IPv4 source/destination - (224.0.0.0/4)
    • -
  • Packets with limited broadcast address as outer IPv4 source/destination - (255.0.0.0/8)
    • -
  • Packets with private address as outer IPv4 source/destination - (10.0.0.0/8, - 172.16.0.0/12, - 192.168.0.0/16)
    • -
  • Packets with subnet broadcast address as outer IPv4 source/destination. - The check is made against subnet broadcast addresses for all of the - directly connected subnets.
    • -
  • Packets that does not pass ingress filtering. Outer IPv4 source address - must meet the IPv4 topology on the routing table. Ingress filter can be - turned off by IFF_LINK2 bit.
    • -
  • The same set of rules are applied against the IPv4 address embedded into - inner IPv6 address, if the IPv6 address matches 6to4 prefix.
    • -
-

It is recommended to filter/audit incoming IPv4 packet with IP - protocol number 41, as necessary. It is also recommended to filter/audit - encapsulated IPv6 packets as well. You may also want to run normal ingress - filter against inner IPv6 address to avoid spoofing.

-

By setting the IFF_LINK0 flag on the - stf interface, it is possible to disable the input - path, making the direct attacks from the outside impossible. Note, however, - there are other security risks exist. If you wish to use the configuration, - you must not advertise your 6to4 address to others.

-
-
-

-

Like “6to4” “6rd” also requires - configuration before it can be used. The required configuration parameters - are:

-
    -
  • The IPv6 address and prefix length.
    • -
  • The border router IPv4 address.
    • -
  • The IPv4 WAN address.
    • -
  • The prefix length of the IPv4 WAN address.
    • -
-

These parameters are all configured through - ifconfig(8).

-

The IPv6 address and prefix length can be configured like any - other IPv6 address. Note that the prefix length is the IPv6 prefix length - excluding the embedded IPv4 address bits. The prefix length of the delegated - network is the sum of the IPv6 prefix length and the IPv4 prefix length.

-

The border router IPv4 address is configured with the - ifconfig(8) stfv4br command.

-

The IPv4 WAN address and IPv4 prefix length are configured using - the ifconfig(8) stfv4net - command.

-
-
-

-

The following sysctl(8) variables can be used to - control the behavior of the stf. The default value - is shown next to each variable.

-
-
net.link.stf.permit_rfc1918: - 0
-
The RFC3056 requires the use of globally unique 32-bit IPv4 addresses. - This sysctl variable controls the behaviour of this requirement. When it - set to not 0, stf allows the use of private IPv4 - addresses described in the RFC1918. This may be useful for an Intranet - environment or when some mechanisms of network address translation (NAT) - are used.
-
-
-
-

-

Note that 8504:0506 is equal to - 133.4.5.6, written in hexadecimals.

-
-
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
-# ifconfig stf0 inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
-	prefixlen 16 alias
-
-

The following configuration accepts packets from IPv4 source - 9.1.0.0/16 only. It emits 6to4 packet only for IPv6 - destination 2002:0901::/32 (IPv4 destination will match - 9.1.0.0/16).

-
-
# ifconfig ne0 inet 9.1.2.3 netmask 0xffff0000
-# ifconfig stf0 inet6 2002:0901:0203:0000:a00:5aff:fe38:6f86 \
-	prefixlen 32 alias
-
-

The following configuration uses the stf - interface as an output-only device. You need to have alternative IPv6 - connectivity (other than 6to4) to use this configuration. For outbound - traffic, you can reach other 6to4 networks efficiently via - stf. For inbound traffic, you will not receive any - 6to4-tunneled packets (less security drawbacks). Be careful not to advertise - your 6to4 prefix to others (2002:8504:0506::/48), - and not to use your 6to4 prefix as a source.

-
-
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
-# ifconfig stf0 inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
-	prefixlen 16 alias deprecated link0
-# route add -inet6 2002:: -prefixlen 16 ::1
-# route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
-
-

The following example configures a “6rd” tunnel on a - “6rd CE” where the ISP's “6rd” IPv6 prefix is - 2001:db8::/32. The border router is 192.0.2.1. The “6rd CE” - has a WAN address of 192.0.2.2 and the full IPv4 address is embedded in the - “6rd IPv6 address:”

-
-
# ifconfig stf0 inet6 2001:db8:c000:0202:: prefixlen 32 up
-# ifconfig stf0 stfv4br 192.0.2.1
-# ifconfig stf0 stfv4net 192.0.2.2/32
-
-
-
-

-

gif(4), inet(4), - inet6(4)

-

Brian Carpenter and - Keith Moore, Connection of IPv6 - Domains via IPv4 Clouds, RFC, - 3056, February - 2001.

-

Jun-ichiro itojun - Hagino, Possible abuse against IPv6 transition - technologies, - draft-itojun-ipv6-transition-abuse-01.txt, - July 2000, work in - progress.

-
-
-

-

The stf device first appeared in WIDE/KAME - IPv6 stack.

-
-
-

-

No more than one stf interface is allowed - for a node, and no more than one IPv6 interface address is allowed for an - stf interface. It is to avoid source address - selection conflicts between IPv6 layer and IPv4 layer, and to cope with - ingress filtering rule on the other side. This is a feature to make - stf work right for all occasions.

-
-
- - - - - -
November 16, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/stge.4 3.html b/static/freebsd/man4/stge.4 3.html deleted file mode 100644 index 9c16dd3e..00000000 --- a/static/freebsd/man4/stge.4 3.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - -
STGE(4)Device Drivers ManualSTGE(4)
-
-
-

-

stge — - Sundance/Tamarack TC9021 Gigabit Ethernet adapter - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device stge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_stge_load="YES"
-
-
-
-

-

The stge device driver provides support - for various NICs based on the Sundance/Tamarack TC9021 Gigabit Ethernet - controller chip.

-

The Sundance/Tamarack TC9021 is found on the D-Link DGE-550T and - the Antares Microsystems Gigabit Ethernet board. It uses an external PHY or - an external 10-bit interface.

-

All NICs supported by the stge driver have - TCP/UDP/IP checksum offload for both receive and transmit, hardware VLAN tag - stripping/insertion features, and receive interrupt moderation mechanism as - well as a 64-bit multicast hash filter. The Sundance/Tamarack TC9021 - supports TBI (ten bit interface) and GMII transceivers, which means it can - be used with either copper or 1000baseX fiber applications.

-

The Sundance/Tamarack TC9021 also supports jumbo frames, which can - be configured via the interface MTU setting. Selecting an MTU larger than - 1500 bytes with the ifconfig(8) utility configures the - adapter to receive and transmit jumbo frames.

-

The stge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX operation over twisted pair. The Sundance/Tamarack supports - 1000Mbps in autoselect mode only.
-
-

The stge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The stge driver provides support for - various NICs based on the Sundance/Tamarack TC9021 based Gigabit Ethernet - controller chips, including:

-

-
    -
  • Antares Microsystems Gigabit Ethernet
    • -
  • ASUS NX1101 Gigabit Ethernet
    • -
  • D-Link DL-4000 Gigabit Ethernet
    • -
  • IC Plus IP1000A Gigabit Ethernet
    • -
  • Sundance ST-2021 Gigabit Ethernet
    • -
  • Sundance ST-2023 Gigabit Ethernet
    • -
  • Sundance TC9021 Gigabit Ethernet
    • -
  • Tamarack TC9021 Gigabit Ethernet
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.stge.%d.rxint_nframe
-
Number of frames between RxDMAComplete interrupts. The accepted range is 1 - to 255, default value is 8 frames. The interface has to be brought down - and up again before a change takes effect.
-
dev.stge.%d.rxint_dmawait
-
Maximum amount of time to wait in 1us increments before issuing an Rx - interrupt if the number of frames received is less than - rxint_nframe. The accepted range is 0 to 4194, - default value is 30 microseconds. The interface has to be brought down and - up again before a change takes effect.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-
-
-

-

The stge driver was ported from - NetBSD and first appeared in - FreeBSD 6.2. The NetBSD - version was written by Jason R. Thorpe - <thorpej@NetBSD.org>.

-
-
-

-

The stge driver was ported by - Pyun YongHyeon - <yongari@FreeBSD.org>.

-
-
- - - - - -
November 23, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/sume.4 3.html b/static/freebsd/man4/sume.4 3.html deleted file mode 100644 index 30a974eb..00000000 --- a/static/freebsd/man4/sume.4 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
SUME(4)Device Drivers Manual (amd64)SUME(4)
-
-
-

-

sume — NetFPGA - SUME 4x10Gb Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device sume
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_sume_load="YES"
-
-
-
-

-

The sume driver provides support for - NetFPGA SUME Virtex-7 FPGA Development Board with the reference NIC - bitstream loaded onto it. The HDL design for the reference NIC project uses - the RIFFA based DMA engine to communicate with the host machine over PCIe. - Every packet is transmitted to / from the board via a single DMA - transaction, taking up to two or three interrupts per one transaction which - yields low performance.

-

There is no support for Jumbo frames as the hardware is capable of - dealing only with frames with maximum size of 1514 bytes. The hardware does - not support multicast filtering, provides no checksums, and offers no other - offloading.

-
-
-

-

arp(4), netgraph(4), - netintro(4), ng_ether(4), - vlan(4), ifconfig(8)

-
-
-

-

The Linux sume driver was originally - written by Bjoern A. Zeeb. The - FreeBSD version and this manual page were written by - Denis Salopek as a GSoC project. More information - about the project can be found here: - https://wiki.freebsd.org/SummerOfCode2020Projects/NetFPGA_SUME_Driver

-
-
-

-

The reference NIC hardware design provides no mechanism for - quiescing inbound traffic from interfaces configured as DOWN. All packets - from administratively disabled interfaces are transferred to main memory, - leaving the driver with the task of dropping such packets, thus consuming - PCI bandwidth, interrupts and CPU cycles in vain.

-

Pre-built FPGA bitstream from the NetFPGA project may not work - correctly. At higher RX packet rates, the newly incoming packets can - overwrite the ones in an internal FIFO so the packets would arrive in main - memory corrupted, until a physical reset of the board.

-

Occasionally, the driver can get stuck in a non-IDLE TX state due - to a missed interrupt. The driver includes a watchdog function which - monitors for such a condition and resets the board automatically. For more - details, visit the NetFPGA SUME project site.

-
-
- - - - - -
August 30, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/superio.4 3.html b/static/freebsd/man4/superio.4 3.html deleted file mode 100644 index afe273ca..00000000 --- a/static/freebsd/man4/superio.4 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
SUPERIO(4)Device Drivers ManualSUPERIO(4)
-
-
-

-

superio — Super - I/O controller and bus driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device superio
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
superio_load="YES"
-
-
-
-

-

Super I/O is an I/O controller that combines various low-bandwidth - devices that can be functionally unrelated otherwise. A typical Super I/O - can contain devices such as

-

-
    -
  • a floppy disk controller
    • -
  • a parallel port
    • -
  • a serial port
    • -
  • a PS/2 mouse and keyboard controller
    • -
  • a hardware monitoring controller
    • -
  • a watchdog timer
    • -
  • a controller for general purpose input-output
    • -
-

The superio driver provides support for - devices residing in the Super I/O controller that can only be accessed or - discovered using the controller's interface. Some of the Super I/O devices - have standardized interfaces. Such devices either use well-known legacy - resources or they are advertised via ACPI or both. They can be configured - either using ISA bus hints or they are auto-configured by - acpi(4). The superio driver is not - designed to interact with that kind of devices. They can be handled by their - respective drivers without any knowledge of the Super I/O specifics. For - instance, fdc(4) provides access to the floppy disk - controller.

-

There are other Super I/O devices that do not have any - standardized interface. Drivers for those devices can be written using - facilities of the superio driver.

-

The driver itself attaches to the ISA bus as all supported - controllers are accessed via LPC I/O ports.

-

The superio driver is unusual as it is - both a controller driver for a variety of Super I/O controllers and a bus - driver for supported devices in those controllers.

-
-
-

-

The superio driver supports a multitude of - Super I/O controllers produced by Nuvoton, formerly known as Winbond, and - ITE, namely:

-

-
    -
  • Fintek F81803
    • -
  • Fintek F81865
    • -
  • Nuvoton NCT5104D/NCT6102D/NCT6106D rev. A and B+
    • -
  • Nuvoton NCT5585D
    • -
  • Nuvoton NCT6116D
    • -
  • Nuvoton NCT6775
    • -
  • Nuvoton NCT6776
    • -
  • Nuvoton NCT6779
    • -
  • Nuvoton NCT6791
    • -
  • Nuvoton NCT6792
    • -
  • Nuvoton NCT6793
    • -
  • Nuvoton NCT6795
    • -
  • Nuvoton NCT6796D-E
    • -
  • Winbond 83627HF/F/HG/G/S/THF/EHF/DHG/UHG/DHG-P
    • -
  • Winbond 83637HF
    • -
  • Winbond 83667HG/HG-B
    • -
  • Winbond 83687THF
    • -
  • Winbond 83697HF/UG
    • -
-
-
-

-

superio(9)

-
-
-

-

The superio driver was written by - Andriy Gapon - <avg@FreeBSD.org>.

-
-
- - - - - -
October 11, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/sym.4 3.html b/static/freebsd/man4/sym.4 3.html deleted file mode 100644 index d673ed29..00000000 --- a/static/freebsd/man4/sym.4 3.html +++ /dev/null @@ -1,389 +0,0 @@ - - - - - - -
SYM(4)Device Drivers ManualSYM(4)
-
-
-

-

sym — - NCR/Symbios/LSI Logic 53C8XX PCI SCSI host adapter - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device pci -
-device scbus -
-device sym
-

To disable PCI parity checking (needed for broken bridges): -
- options SYM_SETUP_PCI_PARITY=<boolean>

-

To control driver probing against HVD buses: -
- options SYM_SETUP_SCSI_DIFF=<bit - combination>

-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
sym_load="YES"
-
-
-
-

-

This driver provides support for the Symbios/LSI Logic 53C8XX PCI - SCSI controllers.

-

Driver features include support for wide SCSI busses and fast10, - fast20, fast40 and fast80-dt synchronous data transfers depending on - controller capabilities. It also provides generic SCSI features such as - tagged command queueing and auto-request sense. This driver is configured by - default for a maximum of 446 outstanding commands per bus, 8 LUNs per target - and 64 tagged tasks per LUN. These numbers are not so much limited by design - as they are considered reasonable values for current SCSI technology. These - values can be increased by changing appropriate constants in driver header - files (not recommended).

-

This driver supports the entire Symbios 53C8XX family of PCI SCSI - controllers. It also offers the advantage of architectural improvements - available only with newer chips.

-

sym notably handles phase mismatch from - SCRIPTS for the 53C896, 53C895A, and 53C1010 cores. As a result, it - guarantees that no more than 1 interrupt per IO completion is delivered to - the CPU, and that the SCRIPTS processor is never stalled waiting for CPU - attention in normal situations.

-

sym also uses LOAD/STORE SCRIPTS - instructions for chips that support it. Only the early 810, 815 and 825 NCR - chips do not support LOAD/STORE. Use of LOAD/STORE instead of MEMORY MOVE - allows SCRIPTS to access IO registers internal to the chip (no external PCI - cycles). As a result, the driver guarantees that no PCI self-mastering will - occur for chips that support LOAD/STORE.

-

LOAD/STORE instructions are also faster than MEMORY MOVE because - they do not involve the chip DMA FIFO and are coded on 2 DWORDs instead of - 3.

-

For the early NCR 810, 815 and 825 chips, the driver uses a - separate SCRIPTS set that uses MEMORY MOVE instructions for data movements. - This is because LOAD/STORE are not supported by these chips.

-

HVD/LVD capable controllers (895, 895A, 896, and 897) report the - actual bus mode in the STEST4 chip IO registers. This feature allows the - driver to safely probe against bus mode and to set up the chip accordingly. - By default the driver only supports HVD for these chips. For other chips - that can support HVD but not LVD, the driver has to probe implementation - dependent registers (GPIO) in order to detect HVD bus mode. Only HVD - implementations that conform with Symbios Logic recommendations can be - detected by the driver. When the SYM_SETUP_SCSI_DIFF - kernel option is assigned a value of 1, the driver will also probe against - HVD for 825a, 875, 876 and 885 chips, assuming Symbios Logic compatible - implementation of HVD.

-

When the SYM_SETUP_PCI_PARITY is assigned a - value of 0, the driver will not enable PCI parity checking for 53C8XX - devices. PCI parity checking should not be an option for PCI SCSI - controllers, but some systems have been reported to fail using 53C8XX chips, - due to spurious or permanent PCI parity errors detected. This option is - supplied for convenience but it is neither recommended nor supported.

-

This driver offers other options that are not currently exported - to the user. They are defined and documented in the - sym_conf.h driver file. Changing these options is - not recommended unless absolutely necessary. Some of these options are - planned to be exported through sysctl(3) or an equivalent - mechanism in a future driver releases and therefore, no compatibility is - guaranteed.

-

At initialization, the driver tries to detect and read user - settings from controller NVRAM. The Symbios/Logic NVRAM layout and the - Tekram NVRAM layout are currently supported. If the reading of the NVRAM - succeeds, the following settings are taken into account and reported to - CAM:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SymbiosTekram
SCSI parity checkingYN
Host SCSI identYY
Verbose messagesYN
Scan targets hi-loYN
Avoid SCSI bus resetYN
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SymbiosTekram
Synchronous periodYY
SCSI bus widthYY
Queue tag enableYY
Number of tagsNAY
Disconnect enableYY
Scan at boot timeYN
Scan LUNYN
-

Devices that are configured as disabled for 'scan' in the NVRAM - are not reported to CAM at system start-up. They can be discovered later - using the ‘camcontrol rescan’ - command.

-

The table below summarizes the main features and capabilities of - the NCR/Symbios/LSI Logic 53C8XX family of PCI SCSI controllers.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SyncWidthSRAMPCI64Supported
sym53c81010MHz8BitNNY
sym53c810a10MHz8BitNNY
sym53c81510MHz8BitNNY
sym53c82510MHz16BitNNY
sym53c825a10MHz16Bit4KBNY
sym53c86020MHz8BitNNY
sym53c87520MHz16Bit4KBNY
sym53c87620MHz16Bit4KBNY
sym53c88520MHz16Bit4KBNY
sym53c89540MHz16Bit4KBNY
sym53c895A40MHz16Bit8KBNY
sym53c89640MHz16Bit8KBYY
sym53c89740MHz16Bit8KBYY
sym53c1510D40MHz16Bit4KBYY
sym53c101080MHz16Bit8KBYY
-
-
-

-

The sym driver provides support for the - following Symbios/LSI Logic PCI SCSI controllers:

-

-
    -
  • 53C810
    • -
  • 53C810A
    • -
  • 53C815
    • -
  • 53C825
    • -
  • 53C825A
    • -
  • 53C860
    • -
  • 53C875
    • -
  • 53C876
    • -
  • 53C895
    • -
  • 53C895A
    • -
  • 53C896
    • -
  • 53C897
    • -
  • 53C1000
    • -
  • 53C1000R
    • -
  • 53C1010-33
    • -
  • 53C1010-66
    • -
  • 53C1510D
    • -
-

The SCSI controllers supported by sym can - be either embedded on a motherboard, or on one of the following add-on - boards:

-

-
    -
  • ASUS SC-200, SC-896
    • -
  • Data Technology DTC3130 (all variants)
    • -
  • DawiControl DC2976UW
    • -
  • Diamond FirePort (all)
    • -
  • NCR cards (all)
    • -
  • Symbios cards (all)
    • -
  • Tekram DC390W, 390U, 390F, 390U2B, 390U2W, 390U3D, and 390U3W
    • -
  • Tyan S1365
    • -
-
-
-

-

The DEC KZPCA-AA is a rebadged SYM8952U.

-
-
-

-

cd(4), da(4), - sa(4), scsi(4), - camcontrol(8)

-
-
-

-

The sym driver appeared in - FreeBSD 4.0.

-
-
-

-

The sym driver was written by - Gerard Roudier and is derived from the Linux - sym53c8xx driver from the same author. The sym53c8xx driver is derived from - the ncr53c8xx driver, which was ported from the - FreeBSD ncr(4) driver to - Linux-1.2.13. The original ncr(4) driver was written for - 386BSD and FreeBSD by - Wolfgang Stanglmeier and Stefan - Esser.

-
-
-

-

No known bugs.

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/syncache.4 3.html b/static/freebsd/man4/syncache.4 3.html deleted file mode 100644 index 04750601..00000000 --- a/static/freebsd/man4/syncache.4 3.html +++ /dev/null @@ -1,268 +0,0 @@ - - - - - - -
SYNCACHE(4)Device Drivers ManualSYNCACHE(4)
-
-
-

-

syncache, - syncookies — - sysctl(8) MIBs for controlling TCP SYN - caching

-
-
-

-
    -
  • - - - - - -
    sysctl - net.inet.tcp.syncookies
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncookies_only
    -
    • -
-

-
    -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.hashsize
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.bucketlimit
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.cachelimit
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.rexmtlimit
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.count
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.see_other
    -
    • -
  • - - - - - -
    sysctl - net.inet.tcp.syncache.rst_on_sock_fail
    -
    • -
-
-
-

-

The syncache sysctl(8) - MIB is used to control the TCP SYN caching in the system, which is intended - to handle SYN flood Denial of Service attacks.

-

When a TCP SYN segment is received on a port corresponding to a - listen socket, an entry is made in the syncache, and - a SYN,ACK segment is returned to the peer. The - syncache entry holds the TCP options from the - initial SYN, enough state to perform a SYN,ACK retransmission, and takes up - less space than a TCP control block endpoint. An incoming segment which - contains an ACK for the SYN,ACK and matches a - syncache entry will cause the system to create a TCP - control block with the options stored in the - syncache entry, which is then released.

-

The syncache protects the system from SYN - flood DoS attacks by minimizing the amount of state kept on the server, and - by limiting the overall size of the syncache.

-

Syncookies provides a way to virtually - expand the size of the syncache by keeping state - regarding the initial SYN in the network. Enabling - syncookies sends a cryptographic value in the - SYN,ACK reply to the client machine, which is then returned in the client's - ACK. If the corresponding entry is not found in the - syncache, but the value passes specific security - checks, the connection will be accepted. This is only used if the - syncache is unable to handle the volume of incoming - connections, and a prior entry has been evicted from the cache.

-

Syncookies have a certain number of - disadvantages that a paranoid administrator may wish to take note of. Since - the TCP options from the initial SYN are not saved, they are not applied to - the connection, precluding use of features like window scale, timestamps, or - exact MSS sizing. As the returning ACK establishes the connection, it may be - possible for an attacker to ACK flood a machine in an attempt to create a - connection. While steps have been taken to mitigate this risk, this may - provide a way to bypass firewalls which filter incoming segments with the - SYN bit set.

-

To disable the syncache and run only with - syncookies, set - net.inet.tcp.syncookies_only to 1. To use - syncookies to handle bucket overflows in the - syncache set - net.inet.tcp.syncookies to 1. The default value for - net.inet.tcp.syncookies_only is 0 and the default - value for net.inet.tcp.syncookies is 1.

-

The syncache implements a number of - variables in the net.inet.tcp.syncache branch of the - sysctl(3) MIB. Several of these may be tuned by setting - the corresponding variable in the loader(8).

-
-
hashsize
-
Size of the syncache hash table, must be a power - of 2. Read-only, tunable via loader(8).
-
bucketlimit
-
Limit on the number of entries permitted in each bucket of the hash table. - This should be left at a low value to minimize search time. Read-only, - tunable via loader(8).
-
cachelimit
-
Limit on the total number of entries in the - syncache. Defaults to - (hashsize × - bucketlimit), may be set lower to minimize memory - consumption. Read-only, tunable via loader(8).
-
rexmtlimit
-
Maximum number of times a SYN,ACK is retransmitted before being discarded. - The default of 3 retransmits corresponds to a 45 second timeout, this - value may be increased depending on the RTT to client machines. Tunable - via sysctl(3).
-
count
-
Number of entries present in the syncache - (read-only).
-
see_other
-
If set to true value, all syncache entries will be - visible via net.inet.tcp.pcblist sysctl, or via - netstat(1), ignoring all of - security(7) UID/GID, jail(2) and - mac(4) checks. If turned off, the visibility checks are - enforced. However, extra ucred(9) referencing is - required on every incoming SYN packet processed. The default is off.
-
rst_on_sock_fail
-
Send a TCP RST segment if the socket allocation fails. The default is - on.
-
-

Statistics on the performance of the - syncache may be obtained via - netstat(1), which provides the following counts:

-
-
-
Entries successfully inserted in the - syncache.
-
-
SYN,ACK retransmissions due to a timeout expiring.
-
-
Incoming SYN segment matching an existing entry.
-
-
SYNs dropped because SYN,ACK could not be sent.
-
-
Successfully completed connections.
-
-
Entries dropped for exceeding per-bucket size.
-
-
Entries dropped for exceeding overall cache size.
-
-
RST segment received.
-
-
Entries dropped due to maximum retransmissions or listen socket - disappearance.
-
-
New socket allocation failures.
-
-
Entries dropped due to bad ACK reply.
-
-
Entries dropped due to ICMP unreachable messages.
-
-
Failures to allocate new syncache entry.
-
-
SYN cookies sent in SYN ACK segments.
-
-
ACK segments with valid syncookies which resulted in TCP connection - establishment.
-
-
Received ACKs, for which the syncache lookup failed and also no syncookie - was recently sent.
-
-
Received ACKs for which the syncookie validation failed.
-
-
-
-

-

netstat(1), jail(2), - mac(4), tcp(4), - security(7), loader(8), - sysctl(8), ucred(9)

-
-
-

-

The existing syncache implementation first - appeared in FreeBSD 4.5. The original concept of a - syncache originally appeared in - BSD/OS, and was later modified by - NetBSD, then further extended here.

-
-
-

-

The syncache code and manual page were - written by Jonathan Lemon - <jlemon@FreeBSD.org>.

-
-
- - - - - -
August 30, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/syncer.4 3.html b/static/freebsd/man4/syncer.4 3.html deleted file mode 100644 index 36473d32..00000000 --- a/static/freebsd/man4/syncer.4 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
SYNCER(4)Device Drivers ManualSYNCER(4)
-
-
-

-

syncer — file - system synchronizer kernel process

-
-
-

- - - - - -
syncer
-
-
-

-

The syncer kernel process helps protect - the integrity of disk volumes by flushing volatile cached file system data - to disk.

-

The kernel places all vnode(9)'s in a number of - queues. The syncer process works through the queues - in a round-robin fashion, usually processing one queue per second. For each - vnode(9) on that queue, the syncer - process forces a write out to disk of its dirty buffers.

-

The usual delay between the time buffers are dirtied and the time - they are synced is controlled by the following sysctl(8) - tunable variables:

- - - - - - - - - - - - - - - - - - - - - -
kern.filedelay30time to delay syncing files
kern.dirdelay29time to delay syncing directories
kern.metadelay28time to delay syncing metadata
-
-
-

-

sync(2), fsck(8), - sync(8), sysctl(8)

-
-
-

-

The syncer process is a descendant of the - ‘update’ command, which appeared in - Version 6 AT&T UNIX, and was usually - started by /etc/rc when the system went multi-user. - A kernel initiated ‘update’ process first appeared in - FreeBSD 2.0.

-
-
-

-

It is possible on some systems that a sync(2) - occurring simultaneously with a crash may cause file system damage. See - fsck(8).

-
-
- - - - - -
July 14, 2000FreeBSD 15.0
diff --git a/static/freebsd/man4/syscons.4 3.html b/static/freebsd/man4/syscons.4 3.html deleted file mode 100644 index 7d000095..00000000 --- a/static/freebsd/man4/syscons.4 3.html +++ /dev/null @@ -1,519 +0,0 @@ - - - - - - -
SYSCONS(4)Device Drivers ManualSYSCONS(4)
-
-
-

-

syscons, sc - — the legacy console driver

-
-
-

-

options MAXCONS=N -
- options SC_ALT_MOUSE_IMAGE -
- options SC_CUT_SEPCHARS=_characters_ -
- options SC_CUT_SPACES2TABS -
- options SC_DFLT_TERM -
- options SC_DISABLE_KDBKEY -
- options SC_DISABLE_REBOOT -
- options SC_HISTORY_SIZE=N -
- options SC_MOUSE_CHAR=C -
- options SC_NO_CUTPASTE -
- options SC_NO_FONT_LOADING -
- options SC_NO_HISTORY -
- options SC_NO_PALETTE_LOADING -
- options SC_NO_SUSPEND_VTYSWITCH -
- options SC_NO_SYSMOUSE -
- options SC_NO_TERM_DUMB -
- options SC_NO_TERM_SC -
- options SC_NO_TERM_SCTEKEN -
- options SC_PIXEL_MODE -
- options SC_TWOBUTTON_MOUSE -
- options SC_NORM_ATTR=_attribute_ -
- options SC_NORM_REV_ATTR=_attribute_ -
- options SC_KERNEL_CONS_ATTR=_attribute_ -
- options SC_KERNEL_CONS_ATTRS=_attributes_ -
- options SC_KERNEL_CONS_REV_ATTR=_attribute_ -
- options SC_DFLT_FONT -
- makeoptions SC_DFLT_FONT=_font_name_ -
- device sc

-

In /boot/device.hints: -
- hint.sc.0.at="isa" -
- hint.sc.0.vesa_mode=0x103

-

In /boot/loader.conf: -
- kern.vty=sc

-
-
-

-

The syscons console is deprecated, and - will be removed in a future version of FreeBSD. - Users are advised to migrate to the vt(4) console - instead.

-
-
-

-

The syscons driver provides multiple - virtual terminals. It resembles the SCO color console driver.

-

Note that the syscons driver is not - compatible with systems booted via UEFI(8). Forcing use of - syscons on such systems will result in no usable - console.

-

The syscons driver is implemented on top - of the keyboard driver (atkbd(4)) and the video card - driver (vga(4)) and so requires both of them to be - configured in the system.

-

There can be only one syscons device - defined in the system.

-
-

-

The syscons driver provides multiple - virtual terminals which appear as if they were separate terminals. One - virtual terminal is considered current and exclusively occupies the screen - and the keyboard; the other virtual terminals are placed in the - background.

-

In order to use virtual terminals, they must be individually - marked ``on'' in /etc/ttys so that - getty(8) will recognize them to be active and run - login(1) to let the user log in to the system. By default, - only the first eight virtual terminals are activated in - /etc/ttys.

-

You press the Alt key and a switch key to - switch between virtual terminals. The following table summarizes the - correspondence between the switch key and the virtual terminal.

-
-
Alt-F1   ttyv0      Alt-F7   ttyv6      Shift-Alt-F1   ttyva
-Alt-F2   ttyv1      Alt-F8   ttyv7      Shift-Alt-F2   ttyvb
-Alt-F3   ttyv2      Alt-F9   ttyv8      Shift-Alt-F3   ttyvc
-Alt-F4   ttyv3      Alt-F10  ttyv9      Shift-Alt-F4   ttyvd
-Alt-F5   ttyv4      Alt-F11  ttyva      Shift-Alt-F5   ttyve
-Alt-F6   ttyv5      Alt-F12  ttyvb      Shift-Alt-F6   ttyvf
-
-

You can also use the ``nscr'' key (usually the - PrintScreen key on the AT Enhanced keyboard) to - cycle available virtual terminals.

-

The default number of available virtual terminals is 16. This can - be changed with the kernel configuration option - MAXCONS (see below).

-

Note that the X server usually requires a virtual terminal for - display purposes, so at least one terminal must be left unused by - getty(8) so that it can be used by the X server.

-
-
-

-

The syscons driver, in conjunction with - the keyboard driver, allows the user to change key definitions and function - key strings. The kbdcontrol(1) command will load a key - definition file (known as ``keymap'' file), dump the current keymap, and - assign a string to a function key. See keyboard(4) and - kbdmap(5) for the keymap file.

-

You may want to set the keymap variable in - /etc/rc.conf.local to the desired keymap file so - that it will be automatically loaded when the system starts up.

-
-
-

-

For most modern video cards, e.g., VGA, the - syscons driver and the video card driver allow the - user to change the font used on the screen. The - vidcontrol(1) command can be used to load a font file from - /usr/share/syscons/fonts.

-

The font comes in various sizes: 8x8, 8x14 and 8x16. The 8x16 font - is typically used for the VGA card in the 80-column-by-25-line mode. Other - video modes may require different font sizes. It is better to always load - all three sizes of the same font.

-

You may set font8x8, - font8x14 and font8x16 variables - in /etc/rc.conf to the desired font files so that - they will be automatically loaded when the system starts up.

-

Optionally you can specify a particular font file as the default. - See the SC_DFLT_FONT option below.

-
-
-

-

If your video card does not support software fonts, you may still - be able to achieve a similar effect by re-mapping the font built into your - video card. Use vidcontrol(1) to load a screen map file - which defines the mapping between character codes.

-
-
-

-

You can use your mouse to copy text on the screen and paste it as - if it was typed by hand. You must be running the mouse daemon - moused(8) and enable the mouse cursor in the virtual - terminal via vidcontrol(1).

-

Pressing mouse button 1 (usually the left button) will start - selection. Releasing button 1 will end the selection process. The selected - text will be marked by inverting foreground and background colors. You can - press button 3 (usually the right button) to extend the selected region. The - selected text is placed in the copy buffer and can be pasted at the cursor - position by pressing button 2 (usually the middle button) as many times as - you like.

-

If your mouse has only two buttons, you may want to use the - SC_TWOBUTTON_MOUSE option below to make the right - button to paste the text. Alternatively you can make the mouse daemon - emulate the middle button. See the man page for moused(8) - for more details.

-
-
-

-

The syscons driver allows the user to - browse the output which has ``scrolled off'' the top of the screen.

-

Press the ``slock'' key (usually ScrllLock - / Scroll Lock or Pause on - many keyboards) and the terminal is in the ``scrollback'' mode. It is - indicated by the Scroll Lock LED. Use the arrow - keys, the Page Up/Down keys and the - Home/End keys to scroll buffered terminal output. - Press the ``slock'' key again to get back to the normal terminal mode.

-

The size of the scrollback buffer can be set by the - SC_HISTORY_SIZE option described below.

-
-
-

-

The syscons driver can be made to put up - the screen saver if the current virtual terminal is idle, that is, the user - is not typing on the keyboard nor moving the mouse. See - splash(4) and vidcontrol(1) for more - details.

-
-
-
-

-
-

-

The following kernel configuration options control the - syscons driver.

-
-
-
This option sets the number of virtual terminals to - N. The default value is 16.
-
-
This option selects the alternative way of displaying the mouse cursor in - the virtual terminal. It may be expensive for some video cards to draw the - arrow-shaped cursor, and you may want to try this option. However, the - appearance of the alternative mouse cursor may not be very appealing. Note - that if you use the SC_NO_FONT_LOADING option then - you must also use this option if you wish to be able to use the - mouse.
-
-
This options specifies characters that will be looked for when the driver - searches for words boundaries when doing cut operation. By default, its - value is "\x20" — a space - character.
-
-
This options instructs the driver to convert leading spaces into tabs when - copying data into cut buffer. This might be useful to preserve indentation - when copying tab-indented text.
-
-
This option specifies the name of the preferred terminal emulator.
-
-
This option disables the ``debug'' key combination (by default, it is - Alt-Esc, or - Ctl-PrintScreen). It will prevent users from - entering the kernel debugger (KDB) by pressing the key combination. KDB - will still be invoked when the kernel panics or hits a break point if it - is included in the kernel. If this option is not defined, this behavior - may be controlled at runtime by the sysctl(8) variable - hw.syscons.kbd_debug.
-
-
This option disables the ``reboot'' key (by default, it is - Ctl-Alt-Del), so that the casual user may not - accidentally reboot the system. If this option is not defined, this - behavior may be controlled at runtime by the sysctl(8) - variable hw.syscons.kbd_reboot.
-
-
Sets the size of back scroll buffer to N lines. The - default value is 100.
-
-
Unless the SC_ALT_MOUSE_IMAGE option above is - specified, the syscons driver reserves four - consecutive character codes in order to display the mouse cursor in the - virtual terminals in some systems. This option specifies the first - character code to C to be used for this purpose. The - default value is 0xd0. A good candidate is 0x03.
-
-
Adds support for pixel (raster) mode console. This mode is useful on some - laptop computers, but less so on most other systems, and it adds - substantial amount of code to syscons. If this option is NOT defined, you - can reduce the kernel size a lot. See the VESAMODE - flag below.
-
-
If you have a two button mouse, you may want to add this option to use the - right button of the mouse to paste text. See - Mouse Support and - Copy-and-Paste above.
-
-
 
-
-
 
-
-
 
-
-
 
-
-
These options will set the default colors. Available colors are defined in - <machine/pc/display.h>. - See EXAMPLES below. - SC_KERNEL_CONS_ATTRS is a character string giving - a sequence of attributes in binary format. The sequence will be repeated - up to the number of CPUs. Beware that the string must not be null, since - the kernel divides by its length.
-
-
This option will specify the default font. Available fonts are: iso, iso2, - koi8-r, koi8-u, cp437, cp850, cp865, cp866 and cp866u. 16-line, 14-line - and 8-line font data will be compiled in. Without this option, the - syscons driver will use whatever font is already - loaded in the video card, unless you explicitly load a software font at - startup. See EXAMPLES below.
-
-
This option, which is also available as loader(8) - tunable and sysctl(8) variable - hw.syscons.sc_no_suspend_vtswitch, disables - switching between virtual terminals (graphics <-> text) during - suspend/resume (ACPI and APM). Use this option if your system is freezing - when you are running X and trying to suspend.
-
-

The following options will remove some features from the - syscons driver and save kernel memory.

-
-
-
This option disables ``copy and paste'' operation in virtual - terminals.
-
-
The syscons driver can load software fonts on some - video cards. This option removes this feature. Note that if you still wish - to use the mouse with this option then you must also use the - SC_ALT_MOUSE_IMAGE option.
-
-
This option disables back-scrolling in virtual terminals.
-
-
This option removes mouse support in the syscons - driver. The mouse daemon moused(8) will fail if this - option is defined. This option implies the - SC_NO_CUTPASTE option too.
-
-
 
-
-
 
-
-
These options remove the "dumb", "sc", and - "scteken" terminal emulators, respectively.
-
-
-
-

-

The following driver flags can be used to control the - syscons driver. Driver flags can be set with the - hint.sc.0.flags tunable, either in - /boot/device.hints, or else at the loader prompt - (see loader(8)).

-
-
0x0080 (VESAMODE)
-
This option puts the video card in the VESA mode specified by - /boot/device.hints variable - vesa_mode during kernel initialization. Note that in - order for this flag to work, the kernel must be compiled with the - SC_PIXEL_MODE option explained above. A list of - the available mode can be obtained via - vidcontrol(1).
-
0x0100 (AUTODETECT_KBD)
-
This option instructs the syscons driver to periodically scan for a - keyboard device if it is not currently attached to one. Otherwise, the - driver only probes for a keyboard once during bootup.
-
-
-
-

-

These settings can be entered at the loader(8) - prompt or in loader.conf(5).

-
-
kern.vty
-
When both syscons and vt(4) have - been compiled into the kernel, the one to use for the system console can - be selected by setting this variable to - ‘sc’ or - ‘vt’. The - GENERIC kernel uses vt(4) when - this value is not set.
-
-
-
-
-

-
-
/dev/console
-
 
-
/dev/consolectl
-
 
-
/dev/ttyv?
-
virtual terminals
-
/etc/ttys
-
terminal initialization information
-
/usr/share/syscons/fonts/*
-
font files
-
/usr/share/syscons/keymaps/*
-
key map files
-
/usr/share/syscons/scrmaps/*
-
screen map files
-
-
-
-

-

As the syscons driver requires the - keyboard driver and the video card driver, the kernel configuration file - should contain the following lines.

-
-
device atkbdc
-device atkbd
-device vga
-device sc
-device splash
-
-

You also need the following lines in - /boot/device.hints for these drivers.

-
-
hint.atkbdc.0.at="isa"
-hint.atkbdc.0.port="0x060"
-hint.atkbd.0.at="atkbdc"
-hint.atkbd.0.irq="1"
-hint.vga.0.at="isa"
-hint.sc.0.at="isa"
-
-

If you do not intend to load the splash image or use the screen - saver, the last line is not necessary, and can be omitted.

-

Note that the keyboard controller driver - atkbdc is required by the keyboard driver - atkbd.

-

The following lines will set the default colors. The normal text - will be green on black background. The reversed text will be yellow on green - background. Note that you cannot put any white space inside the quoted - string, because of the current implementation of - config(8).

-

-
options - SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
-
options - SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
-

The following lines will set the default colors of the kernel - message. The kernel message will be printed bright red on black background. - The reversed message will be black on red background.

-

-
options - SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK)
-
options - SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
-

Provided SC_KERNEL_CONS_ATTR is not set, - or is set to its default of bright white on black, the following line will - set 4 red-ish colors for printing kernel messages in colors depending on the - CPU.

-

-
options - SC_KERNEL_CONS_ATTRS=\"\x0c\x04\x40\x0e\"
-

The default scheme is probably better for up to 8 CPUs. Use a long - string to get unique colors for more than 8 CPUs.

-

To turn off all per-CPU coloring of kernel messages, set - SC_KERNEL_CONS_ATTR to a non-default value, or use the default in a pattern - of length 1.

-

-
options - SC_KERNEL_CONS_ATTRS=\"\x0f\"
-

The following example adds the font files - cp850-8x16.fnt, - cp850-8x14.font and - cp850-8x8.font to the kernel.

-

-
options SC_DFLT_FONT
-
makeoptions - SC_DFLT_FONT=cp850
-
device sc
-
-
-

-

kbdcontrol(1), login(1), - vidcontrol(1), atkbd(4), - atkbdc(4), keyboard(4), - screen(4), splash(4), - ukbd(4), vga(4), - vt(4), kbdmap(5), - rc.conf(5), ttys(5), - config(8), getty(8), - kldload(8), moused(8)

-
-
-

-

The syscons driver first appeared in - FreeBSD 1.0.

-
-
-

-

The syscons driver was written by - Søren Schmidt - <sos@FreeBSD.org>. - This manual page was written by Kazutaka Yokota - <yokota@FreeBSD.org>.

-
-
-

-

The amount of data that is possible to insert from the cut buffer - is limited by the {MAX_INPUT}, a system limit on the - number of bytes that may be stored in the terminal input queue - usually - 1024 bytes (see termios(4)).

-
-
-

-

This manual page is incomplete and urgently needs revision.

-
-
- - - - - -
November 2, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/sysmouse.4 3.html b/static/freebsd/man4/sysmouse.4 3.html deleted file mode 100644 index 9f2c9cee..00000000 --- a/static/freebsd/man4/sysmouse.4 3.html +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - -
SYSMOUSE(4)Device Drivers ManualSYSMOUSE(4)
-
-
-

-

sysmouse — - virtualized mouse driver

-
-
-

-

#include - <sys/mouse.h> -
- #include <sys/consio.h>

-
-
-

-

The console driver, in conjunction with the mouse daemon - moused(8), supplies mouse data to the user process in the - standardized way via the sysmouse driver. This - arrangement makes it possible for the console and the user process (such as - the X Window System) to share the mouse.

-

The user process which wants to utilize mouse operation simply - opens /dev/sysmouse with a open(2) - call and reads mouse data from the device via read(2). - Make sure that moused(8) is running, otherwise the user - process will not see any data coming from the mouse.

-
-

-

The sysmouse driver has two levels of - operation. The current operation level can be referred to and changed via - ioctl calls.

-

The level zero, the basic level, is the lowest level at which the - driver offers the basic service to user programs. The - sysmouse driver provides horizontal and vertical - movement of the mouse and state of up to three buttons in the MouseSystems - format as follows.

-

-
-
Byte 1
-
-
-
bit 7
-
Always one.
-
bit 6..3
-
Always zero.
-
bit 2
-
Left button status; cleared if pressed, otherwise set.
-
bit 1
-
Middle button status; cleared if pressed, otherwise set. Always one, - if the device does not have the middle button.
-
bit 0
-
Right button status; cleared if pressed, otherwise set.
-
-
-
Byte 2
-
The first half of horizontal movement count in two's complement; -128 - through 127.
-
Byte 3
-
The first half of vertical movement count in two's complement; -128 - through 127.
-
Byte 4
-
The second half of the horizontal movement count in two's complement; -128 - through 127. To obtain the full horizontal movement count, add the byte 2 - and 4.
-
Byte 5
-
The second half of the vertical movement count in two's complement; -128 - through 127. To obtain the full vertical movement count, add the byte 3 - and 5.
-
-

At the level one, the extended level, mouse data is encoded in the - standard format MOUSE_PROTO_SYSMOUSE as defined in - mouse(4).

-
-
-
-

-

This section describes two classes of ioctl(2) - commands: commands for the sysmouse driver itself, - and commands for the console and the console control drivers.

-
-

-

There are a few commands for mouse drivers. General description of - the commands is given in mouse(4). Following are the - features specific to the sysmouse driver.

-

-
-
- int *level
-
 
-
- int *level
-
These commands manipulate the operation level of the mouse driver. -

-
-
- mousehw_t *hw
-
Returns the hardware information of the attached device in the following - structure. Only the iftype field is guaranteed to be - filled with the correct value in the current version of the - sysmouse driver. -
- 
typedef struct mousehw {
-    int buttons;    /* number of buttons */
-    int iftype;     /* I/F type */
-    int type;       /* mouse/track ball/pad... */
-    int model;      /* I/F dependent model ID */
-    int hwid;       /* I/F dependent hardware ID */
-} mousehw_t;
-
-

The buttons field holds the number of - buttons detected by the driver.

-

The iftype is always - MOUSE_IF_SYSMOUSE.

-

The type tells the device type: - MOUSE_MOUSE, - MOUSE_TRACKBALL, - MOUSE_STICK, MOUSE_PAD, - or MOUSE_UNKNOWN.

-

The model is always - MOUSE_MODEL_GENERIC at the operation level 0. It - may be MOUSE_MODEL_GENERIC or one of - MOUSE_MODEL_XXX constants at higher operation - levels.

-

The hwid is always zero.

-

-
-
- mousemode_t *mode
-
The command gets the current operation parameters of the mouse driver. -
- 
typedef struct mousemode {
-    int protocol;    /* MOUSE_PROTO_XXX */
-    int rate;        /* report rate (per sec) */
-    int resolution;  /* MOUSE_RES_XXX, -1 if unknown */
-    int accelfactor; /* acceleration factor */
-    int level;       /* driver operation level */
-    int packetsize;  /* the length of the data packet */
-    unsigned char syncmask[2]; /* sync. bits */
-} mousemode_t;
-
-

The protocol field tells the format in - which the device status is returned when the mouse data is read by the - user program. It is MOUSE_PROTO_MSC at the - operation level zero. MOUSE_PROTO_SYSMOUSE at - the operation level one.

-

The rate is always set to -1.

-

The resolution is always set to -1.

-

The accelfactor is always 0.

-

The packetsize field specifies the - length of the data packet. It depends on the operation level.

-

-
-
-
5 bytes
-
-
8 bytes
-
-

The array syncmask holds a bit mask and - pattern to detect the first byte of the data packet. - syncmask[0] is the bit mask to be ANDed with a - byte. If the result is equal to syncmask[1], the - byte is likely to be the first byte of the data packet. Note that this - method of detecting the first byte is not 100% reliable; thus, it should - be taken only as an advisory measure.

-

-
-
- mousemode_t *mode
-
The command changes the current operation parameters of the mouse driver - as specified in mode. Only - level may be modifiable. Setting values in the other - field does not generate error and has no effect. -

-
-
- mousedata_t *data
-
 
-
- mousedata_t *state
-
These commands are not supported by the sysmouse - driver. -

-
-
- mousestatus_t *status
-
The command returns the current state of buttons and movement counts in - the structure as defined in mouse(4).
-
-
-
-

-

The user process issues console - () - calls to the current virtual console in order to control the mouse pointer. - The console ioctl() also provides a method for the - user process to receive a signal(3) when a button is - pressed.

-

The mouse daemon moused(8) uses - () - calls to the console control device /dev/consolectl - to inform the console of mouse actions including mouse movement and button - status.

-

Both classes of - () - commands are defined as CONS_MOUSECTL which takes - the following argument.

-
-
struct mouse_info {
-    int operation;
-    union {
-        struct mouse_data data;
-        struct mouse_mode mode;
-        struct mouse_event event;
-    } u;
-};
-
-

-
-
operation
-
This can be one of -

-
-
-
Enables and displays mouse cursor.
-
-
Disables and hides mouse cursor.
-
-
Moves mouse cursor to position supplied in - u.data.
-
-
Adds position supplied in u.data to current - position.
-
-
Returns current mouse position in the current virtual console and - button status in u.data.
-
-
This sets the signal(3) to be delivered to the - current process when a button is pressed. The signal to be delivered - is set in u.mode.
-
-

The above operations are for virtual consoles. The operations - defined below are for the console control device and are used by - moused(8) to pass mouse data to the console - driver.

-

-
-
-
 
-
-
These operations take the information in u.data - and act upon it. Mouse data will be sent to the - sysmouse driver if it is open. - MOUSE_ACTION also processes button press - actions and sends signal to the process if requested or performs cut - and paste operations if the current console is a text interface.
-
-
u.data specifies a button and its click count. - The console driver will use this information for signal delivery if - requested or for cut and paste operations if the console is in text - mode.
-
-

MOUSE_MOTION_EVENT and - MOUSE_BUTTON_EVENT are newer interface and are - designed to be used together. They are intended to replace functions - performed by MOUSE_ACTION alone.

-

-
-
u
-
This union is one of -

-
-
data
-
-
- 
struct mouse_data {
-    int x;
-    int y;
-    int z;
-    int buttons;
-};
-
-

x, y and - z represent movement of the mouse along - respective directions. buttons tells the state - of buttons. It encodes up to 31 buttons in the bit 0 though the bit - 30. If a button is held down, the corresponding bit is set.

-

-
-
mode
-
-
- 
struct mouse_mode {
-    int mode;
-    int signal;
-};
-
-

The signal field specifies the - signal to be delivered to the process. It must be one of the values - defined in - <signal.h>. The - mode field is currently unused.

-

-
-
event
-
-
- 
struct mouse_event {
-    int id;
-    int value;
-};
-
-

The id field specifies a button - number as in u.data.buttons. Only one - bit/button is set. The value field holds the - click count: the number of times the user has clicked the button - successively.

-
-
-
-
-
-
-
-

-
-
/dev/consolectl
-
device to control the console
-
/dev/sysmouse
-
virtualized mouse driver
-
/dev/ttyv%d
-
virtual consoles
-
-
-
-

-

vidcontrol(1), ioctl(2), - signal(3), mouse(4), - moused(8)

-
-
-

-

The sysmouse driver first appeared in - FreeBSD 2.2.

-
-
-

-

This manual page was written by John-Mark - Gurney - <jmg@FreeBSD.org> and - Kazutaka Yokota - <yokota@FreeBSD.org>.

-
-
- - - - - -
March 25, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/tap.4 3.html b/static/freebsd/man4/tap.4 3.html deleted file mode 100644 index a3a4b9f2..00000000 --- a/static/freebsd/man4/tap.4 3.html +++ /dev/null @@ -1,201 +0,0 @@ - - - - - - -
TAP(4)Device Drivers ManualTAP(4)
-
-
-

-

tap, vmnet - — Ethernet tunnel software network - interface

-
-
-

-

device tuntap

-
-
-

-

The tap interface is a software loopback - mechanism that can be loosely described as the network interface analog of - the pty(4), that is, tap does for - network interfaces what the pty(4) driver does for - terminals.

-

The tap driver, like the - pty(4) driver, provides two interfaces: an interface like - the usual facility it is simulating (an Ethernet network interface in the - case of tap, or a terminal for - pty(4)), and a character-special device - “control” interface. A client program transfers Ethernet - frames to or from the tap “control” - interface. The tun(4) interface provides similar - functionality at the network layer: a client will transfer IP (by default) - packets to or from a tun(4) “control” - interface.

-

The network interfaces are named - “tap0”, - “tap1”, etc., one for each control - device that has been opened. These Ethernet network interfaces persist until - if_tuntap.ko module is unloaded, or until removed - with "ifconfig destroy" (see below).

-

tap devices are created using interface - cloning. This is done using the “ifconfig tapN - create” command. This is the preferred method - of creating tap devices. The same method allows - removal of interfaces. For this, use the “ifconfig - tapN destroy” command.

-

If the sysctl(8) variable - net.link.tap.devfs_cloning is non-zero, the - tap interface permits opens on the special control - device /dev/tap. When this device is opened, - tap will return a handle for the lowest unused - tap device (use devname(3) to - determine which).

-

-
Disabling the legacy devfs cloning functionality may break - existing applications which use tap, such as VMware - and ssh(1). It therefore defaults to being enabled until - further notice.
-

Control devices (once successfully opened) persist until - if_tuntap.ko is unloaded or the interface is - destroyed.

-

Each interface supports the usual Ethernet network interface - ioctl(2)s and thus can be used with - ifconfig(8) like any other Ethernet interface. When the - system chooses to transmit an Ethernet frame on the network interface, the - frame can be read from the control device (it appears as - “input” there); writing an Ethernet frame to the control - device generates an input frame on the network interface, as if the - (non-existent) hardware had just received it.

-

The Ethernet tunnel device, normally - /dev/tapN, is exclusive-open (it - cannot be opened if it is already open) and is restricted to the super-user, - unless the sysctl(8) variable - net.link.tap.user_open is non-zero. If the - sysctl(8) variable - net.link.tap.up_on_open is non-zero, the tunnel device - will be marked “up” when the control device is opened. A - () call - will return an error (EHOSTDOWN) if the interface is - not “ready”. Once the interface is ready, - read() will return an Ethernet frame if one is - available; if not, it will either block until one is or return - EWOULDBLOCK, depending on whether non-blocking I/O - has been enabled. If the frame is longer than is allowed for in the buffer - passed to read(), the extra data will be silently - dropped.

-

A write(2) call passes an Ethernet - frame in to be “received” on the pseudo-interface. Each - () call - supplies exactly one frame; the frame length is taken from the amount of - data provided to write(). Writes will not block; if - the frame cannot be accepted for a transient reason (e.g., no buffer space - available), it is silently dropped; if the reason is not transient (e.g., - frame too large), an error is returned. The following - ioctl(2) calls are supported (defined in - <net/if_tap.h>):

-
-
-
Set network interface information (line speed and MTU). The type must be - the same as returned by TAPGIFINFO or set to - IFT_ETHER else the ioctl(2) call - will fail. The argument should be a pointer to a struct - tapinfo.
-
-
Retrieve network interface information (line speed, MTU and type). The - argument should be a pointer to a struct - tapinfo.
-
-
The argument should be a pointer to an int; this - sets the internal debugging variable to that value. What, if anything, - this variable controls is not documented here; see the source code.
-
-
The argument should be a pointer to an int; this - stores the internal debugging variable's value into it.
-
-
Retrieve network interface name. The argument should be a pointer to a - struct ifreq. The interface name will be returned in - the ifr_name field.
-
-
The argument should be a pointer to an int; this - sets the transient flag on the tap device. A - transient tap will be destroyed upon last - close.
-
-
The argument should be a pointer to an int; this - stores the current state (enabled or disabled) of the transient flag into - it.
-
-
Turn non-blocking I/O for reads off or on, according as the argument - int's value is or is not zero (Writes are always - nonblocking).
-
-
Turn asynchronous I/O for reads (i.e., generation of - SIGIO when data is available to be read) off or - on, according as the argument int's value is or is - not zero.
-
-
If any frames are queued to be read, store the size of the first one into - the argument int; otherwise, store zero.
-
-
Set the process group to receive SIGIO signals, - when asynchronous I/O is enabled, to the argument - int value.
-
-
Retrieve the process group value for SIGIO signals - into the argument int value.
-
-
Retrieve the Media Access Control (MAC) address of - the “remote” side. This command is used by the VMware port - and expected to be executed on descriptor, associated with control device - (usually /dev/vmnetN or - /dev/tapN). The - buffer, which is passed as the argument, is expected - to have enough space to store the MAC address. At - the open time both “local” and “remote” - MAC addresses are the same, so this command could - be used to retrieve the “local” MAC - address.
-
-
Set the Media Access Control (MAC) address of the - “remote” side. This command is used by VMware port and - expected to be executed on a descriptor, associated with control device - (usually /dev/vmnetN).
-
-

The control device also supports select(2) for - read; selecting for write is pointless, and always succeeds, since writes - are always non-blocking.

-

On the last close of the data device, the interface is brought - down (as if with “ifconfig tapN - down”) and has all of its configured - addresses deleted unless the device is a VMnet device, or - has IFF_LINK0 flag set. All queued frames are thrown - away. If the interface is up when the data device is not open, output frames - are thrown away rather than letting them pile up.

-

The tap device can also be used with the - VMware port as a replacement for the old VMnet device - driver. VMnet devices do not ifconfig(8) - themselves down when the control device is closed. Everything else is the - same.

-

In addition to the above mentioned ioctl(2) - calls, there is an additional one for the VMware port.

-
-
-
VMware SIOCSIFFLAGS.
-
-
-
-

-

inet(4), intro(4), - tun(4)

-
-
- - - - - -
January 13, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/tarfs.4 3.html b/static/freebsd/man4/tarfs.4 3.html deleted file mode 100644 index b58665ca..00000000 --- a/static/freebsd/man4/tarfs.4 3.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - -
TARFS(4)Device Drivers ManualTARFS(4)
-
-
-

-

tarfs — tarball - filesystem

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
options TARFS
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
tarfs_load="YES"
-
-
-
-

-

The tarfs driver implements a read-only - filesystem backed by a tar(5) file. Currently, only POSIX - archives, optionally compressed with zstd(1), are - supported.

-

The preferred I/O size for tarfs - filesystems can be adjusted using the - vfs.tarfs.ioshift sysctl setting and tunable. Setting - it to 0 will reset it to its default value. Note that changes to this - setting only apply to filesystems mounted after the change.

-

When the backing tar file is compressed with - zstd(1), I/O performance can be improved by ensuring that - compressed data is broken up into multiple frames. This helps minimize - unnecessary decompression work. When using bsdtar(1) to - create the tar file, this can be achieved using the - zstd:max-frame-size and - zstd:frame-per-file options. Sensible frame sizes - are powers of 2 between the system's base page size (see - arch(7)) and the value of the - - sysctl. Smaller frames will generally yield a worse compression ratio and - require extra kernel memory to maintain an index, and larger frames will on - average require more CPU time to access data when performing random I/O.

-
-
-

-

If enabled by the TARFS_DEBUG kernel - option, the vfs.tarfs.debug sysctl setting can be used - to control debugging output from the tarfs driver. - Debugging output for individual sections of the driver can be enabled by - adding together the relevant values from the table below.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x01Memory allocations
0x02Checksum calculations
0x04Filesystem operations (vfsops)
0x08Path lookups
0x10File operations (vnops)
0x20General I/O
0x40Decompression
0x80Decompression index
0x100Sparse file mapping
0x200Bounce buffer usage
-
-
-

-

tar(1), zstd(1), - fstab(5), tar(5), - mount(8), sysctl(8)

-
-
-

-

The tarfs driver was developed by - Stephen J. Kiernan - <stevek@FreeBSD.org> - and Dag-Erling Smørgrav - <des@FreeBSD.org> for - Juniper Networks and Klara Systems. This manual page was written by - Dag-Erling Smørgrav - <des@FreeBSD.org> for - Juniper Networks and Klara Systems.

-
-
- - - - - -
February 14, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/targ.4 3.html b/static/freebsd/man4/targ.4 3.html deleted file mode 100644 index 1d303661..00000000 --- a/static/freebsd/man4/targ.4 3.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - -
TARG(4)Device Drivers ManualTARG(4)
-
-
-

-

targ — SCSI target - emulator driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device targ
-
-
-

-

The targ driver provides an interface for - usermode programs to emulate SCSI target devices. A sample program that - emulates a disk drive (similar to da(4)) can be found in - /usr/share/examples/scsi_target.

-

The targ driver supplies the control - device /dev/targ. After opening the device, the file - descriptor must be bound to a specific bus/target/LUN and enabled to process - CCBs using the TARGIOCENABLE ioctl. The process then - uses write(2) to send CCBs to the SIM and - poll(2) or kqueue(2) to see if responses - are ready. Pointers to completed CCBs are returned via - read(2). Any data transfers requested by the user CCBs are - done via zero-copy IO.

-
-
-

-

The following ioctl(2) calls are defined in the - header file - <cam/scsi/scsi_targetio.h>.

-
-
-
(struct ioc_enable_lun) Enable target mode on the - LUN specified by the following structure: -
- 
struct ioc_enable_lun {
-	path_id_t	path_id;
-	target_id_t	target_id;
-	lun_id_t	lun_id;
-	int		grp6_len;
-	int		grp7_len;
-};
-
-

The selected path (bus), target, and LUN must not already be - in use or EADDRINUSE is returned. If - grp6_len or grp7_len are - non-zero, reception of vendor-specific commands is enabled.

-
-
-
Disable target mode and abort all pending CCBs. The CCBs may optionally be - read as they complete. TARGIOCENABLE can then be - called to activate a different LUN. Multiple disable calls have no effect. - The close(2) system call automatically disables target - mode if enabled.
-
-
(int) Enables CAM_PERIPH - debugging if the argument is non-zero, otherwise disables it.
-
-
-
-

-
-
<cam/scsi/scsi_targetio.h>
-
describes the usermode interface.
-
/sys/cam/scsi/scsi_target.c
-
is the driver source file.
-
/dev/targ
-
is the control device.
-
-
-
-

-

/usr/share/examples/scsi_target, - ahc(4), isp(4), - scsi(4)

-

FreeBSD Target - Information, - http://www.root.org/~nate/freebsd/.

-
-
-

-

The targ driver first appeared in - FreeBSD 3.0 and was written by - Justin T. Gibbs. It was rewritten for - FreeBSD 5.0 by Nate Lawson - <nate@root.org>.

-
-
-

-

Currently, only the ahc(4) and - isp(4) drivers fully support target mode.

-

The ahc(4) driver does not support tagged - queuing in target mode.

-
-
- - - - - -
December 13, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/tcp.4 3.html b/static/freebsd/man4/tcp.4 3.html deleted file mode 100644 index f8bc1dd1..00000000 --- a/static/freebsd/man4/tcp.4 3.html +++ /dev/null @@ -1,837 +0,0 @@ - - - - - - -
TCP(4)Device Drivers ManualTCP(4)
-
-
-

-

tcp — Internet - Transmission Control Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h> -
- #include <netinet/tcp.h>

-

int -
- socket(AF_INET, - SOCK_STREAM, - 0);

-
-
-

-

The TCP protocol provides reliable, flow-controlled, two-way - transmission of data. It is a byte-stream protocol used to support the - SOCK_STREAM abstraction. TCP uses the standard - Internet address format and, in addition, provides a per-host collection of - “port addresses”. Thus, each address is composed of an - Internet address specifying the host and network, with a specific TCP port - on the host identifying the peer entity.

-

Sockets utilizing the TCP protocol are either - “active” or “passive”. Active sockets initiate - connections to passive sockets. By default, TCP sockets are created active; - to create a passive socket, the listen(2) system call must - be used after binding the socket with the bind(2) system - call. Only passive sockets may use the accept(2) call to - accept incoming connections. Only active sockets may use the - connect(2) call to initiate connections.

-

Passive sockets may “underspecify” their location to - match incoming connection requests from multiple networks. This technique, - termed “wildcard addressing”, allows a single server to - provide service to clients on multiple networks. To create a socket which - listens on all networks, the Internet address - INADDR_ANY must be bound. The TCP port may still be - specified at this time; if the port is not specified, the system will assign - one. Once a connection has been established, the socket's address is fixed - by the peer entity's location. The address assigned to the socket is the - address associated with the network interface through which packets are - being transmitted and received. Normally, this address corresponds to the - peer entity's network.

-

TCP supports a number of socket options which can be set with - setsockopt(2) and tested with - getsockopt(2):

-
-
-
Information about a socket's underlying TCP session may be retrieved by - passing the read-only option TCP_INFO to - getsockopt(2). It accepts a single argument: a pointer - to an instance of struct tcp_info. -

This API is subject to change; consult the source to determine - which fields are currently filled out by this option. - FreeBSD specific additions include send window - size, receive window size, and bandwidth-controlled window space.

-
-
-
Set or query congestion control algorithm specific parameters. See - mod_cc(4) for details.
-
-
Select or query the congestion control algorithm that TCP will use for the - connection. See mod_cc(4) for details.
-
-
Enable or disable TCP Fast Open (TFO). To use this option, the kernel must - be built with the TCP_RFC7413 option. -

This option can be set on the socket either before or after - the listen(2) is invoked. Clearing this option on a - listen socket after it has been set has no effect on existing TFO - connections or TFO connections in progress; it only prevents new TFO - connections from being established.

-

For passively-created sockets, the - TCP_FASTOPEN socket option can be queried to - determine whether the connection was established using TFO. Note that - connections that are established via a TFO SYN, but that fall back to - using a non-TFO SYN|ACK will have the - TCP_FASTOPEN socket option set.

-

In addition to the facilities defined in RFC7413, this - implementation supports a pre-shared key (PSK) mode of operation in - which the TFO server requires the client to be in possession of a shared - secret in order for the client to be able to successfully open TFO - connections with the server. This is useful, for example, in - environments where TFO servers are exposed to both internal and external - clients and only wish to allow TFO connections from internal - clients.

-

In the PSK mode of operation, the server generates and sends - TFO cookies to requesting clients as usual. However, when validating - cookies received in TFO SYNs from clients, the server requires the - client-supplied cookie to equal

-
- 
SipHash24(key=16-byte-psk, msg=cookie-sent-to-client)
-
-

Multiple concurrent valid pre-shared keys are supported so - that time-based rolling PSK invalidation policies can be implemented in - the system. The default number of concurrent pre-shared keys is 2.

-

This can be adjusted with the - TCP_RFC7413_MAX_PSKS kernel option.

-
-
-
Select or query the set of functions that TCP will use for this - connection. This allows a user to select an alternate TCP stack. The - alternate TCP stack must already be loaded in the kernel. To list the - available TCP stacks, see functions_available in the - FIB support TCP sockets are - FIB-aware. They inherit the FIB of the process which created the socket, - or that of the listening socket for sockets created by - accept(2). In particular, the FIB is not inherited from - that of the interface where the initiating SYN packet was received. When - an incoming connection request arrives to a listening socket, the initial - handshake also occurs in the FIB of the listening socket, not that of the - received packet. -

By default, a TCP listening socket can accept connections - originating from any FIB. If the - net.inet.tcp.bind_all_fibs tunable is set to 0, a - listening socket will only accept connections originating from the FIB's - listening socket. Connection requests from other FIBs will be treated as - though there is no listening socket for the destination address and - port. In this mode, multiple listening sockets owned by the same user - can listen on the same address and port so long as they belong to - different FIBs, similar to the behavior of the - SO_REUSEPORT socket option. If the tunable is - set to 0, all sockets added to a load-balancing group created with the - SO_REUSEPORT_LB socket option must belong to the - same FIB. MIB (sysctl) - Variables section further down. To list the default TCP stack, see - functions_default in the - MIB (sysctl) Variables - section.

-
-
-
This setsockopt(2) option accepts a per-socket timeout - argument of u_int in seconds, for new, - non-established TCP connections. For the global default in milliseconds - see keepinit in the - MIB (sysctl) Variables - section further down.
-
-
This setsockopt(2) option accepts an argument of - u_int for the amount of time, in seconds, that the - connection must be idle before keepalive probes (if enabled) are sent for - the connection of this socket. If set on a listening socket, the value is - inherited by the newly created socket upon accept(2). - For the global default in milliseconds see keepidle - in the MIB (sysctl) - Variables section further down.
-
-
This setsockopt(2) option accepts an argument of - u_int to set the per-socket interval, in seconds, - between keepalive probes sent to a peer. If set on a listening socket, the - value is inherited by the newly created socket upon - accept(2). For the global default in milliseconds see - keepintvl in the - MIB (sysctl) Variables - section further down.
-
-
This setsockopt(2) option accepts an argument of - u_int and allows a per-socket tuning of the number - of probes sent, with no response, before the connection will be dropped. - If set on a listening socket, the value is inherited by the newly created - socket upon accept(2). For the global default see the - keepcnt in the - MIB (sysctl) Variables - section further down.
-
-
Under most circumstances, TCP sends data when it is presented; when - outstanding data has not yet been acknowledged, it gathers small amounts - of output to be sent in a single packet once an acknowledgement is - received. For a small number of clients, such as window systems that send - a stream of mouse events which receive no replies, this packetization may - cause significant delays. The boolean option - TCP_NODELAY defeats this algorithm. -

-
-
-
By default, a sender- and receiver-TCP will - negotiate among themselves to determine the maximum segment size to be - used for each connection. The TCP_MAXSEG option - allows the user to determine the result of this negotiation, and to reduce - it if desired.
-
-
This setsockopt(2) option accepts an argument of - u_int to set the per-socket interval, in seconds, in - which the connection must make progress. Progress is defined by at least 1 - byte being acknowledged within the set time period. If a connection fails - to make progress, then the TCP stack will terminate the connection with a - reset. Note that the default value for this is zero which indicates no - progress checks should be made.
-
-
TCP usually sends a number of options in each packet, corresponding to - various TCP extensions which are provided in this implementation. The - boolean option TCP_NOOPT is provided to disable - TCP option use on a per-connection basis.
-
-
By convention, the sender-TCP will set the - “push” bit, and begin transmission immediately (if - permitted) at the end of every user call to write(2) or - writev(2). When this option is set to a non-zero value, - TCP will delay sending any data at all until either the socket is closed, - or the internal send buffer is filled.
-
-
This option enables the use of MD5 digests (also known as TCP-MD5) on - writes to the specified socket. Outgoing traffic is digested; digests on - incoming traffic are verified. When this option is enabled on a socket, - all inbound and outgoing TCP segments must be signed with MD5 digests. -

One common use for this in a FreeBSD - router deployment is to enable based routers to interwork with Cisco - equipment at peering points. Support for this feature conforms to RFC - 2385.

-

In order for this option to function correctly, it is - necessary for the administrator to add a tcp-md5 key entry to the - system's security associations database (SADB) using the - setkey(8) utility. This entry can only be specified on - a per-host basis at this time.

-

If an SADB entry cannot be found for the destination, the - system does not send any outgoing segments and drops any inbound - segments. However, during connection negotiation, a non-signed segment - will be accepted if an SADB entry does not exist between hosts. When a - non-signed segment is accepted, the established connection is not - protected with MD5 digests.

-
-
-
Manage collection of connection level statistics using the - stats(3) framework. -

Each dropped segment is taken into account in the TCP protocol - statistics.

-
-
-
Enable in-kernel Transport Layer Security (TLS) for data written to this - socket. See ktls(4) for more details.
-
-
The integer argument can be used to get or set the current TLS transmit - mode of a socket. See ktls(4) for more details.
-
-
Enable in-kernel TLS for data read from this socket. See - ktls(4) for more details.
-
-
Changes NUMA affinity filtering for an established TCP listen socket. This - option takes a single integer argument which specifies the NUMA domain to - filter on for this listen socket. The argument can also have the following - special values: -
-
-
Remove NUMA filtering for this listen socket.
-
-
Filter traffic associated with the domain where the calling thread is - currently executing. This is typically used after a process or thread - inherits a listen socket from its parent, and sets its CPU affinity to - a particular core.
-
-
-
-
Set and get the remote UDP encapsulation port. It can only be set on a - closed TCP socket.
-
-

The option level for the setsockopt(2) call is - the protocol number for TCP, available from - getprotobyname(3), or IPPROTO_TCP. - All options are declared in - <netinet/tcp.h>.

-

Options at the IP transport level may be used with TCP; see - ip(4). Incoming connection requests that are source-routed - are noted, and the reverse source route is used in responding.

-

The default congestion control algorithm for TCP is - cc_cubic(4). Other congestion control algorithms can be - made available using the mod_cc(4) framework.

-
-

-

The TCP protocol implements a number of variables in the - net.inet.tcp branch of the sysctl(3) - MIB, which can also be read or modified with - sysctl(8).

-
-
ack_war_timewindow, - ack_war_cnt
-
The challenge ACK throttling algorithm defined in RFC 5961 limits the - number of challenge ACKs sent per TCP connection to - ack_war_cnt during the time interval specified in - milliseconds by ack_war_timewindow. Setting - ack_war_timewindow or - ack_war_cnt to zero disables challenge ACK - throttling.
-
always_keepalive
-
Assume that SO_KEEPALIVE is set on all TCP - connections, the kernel will periodically send a packet to the remote host - to verify the connection is still up.
-
blackhole
-
If enabled, disable sending of RST when a connection is attempted to a - port where there is no socket accepting connections. See - blackhole(4).
-
blackhole_local
-
See blackhole(4).
-
cc
-
A number of variables for congestion control are under the - net.inet.tcp.cc node. See - mod_cc(4).
-
cc.newreno
-
Variables for NewReno congestion control are under the - net.inet.tcp.cc.newreno node. See - cc_newreno(4).
-
delacktime
-
Maximum amount of time, in milliseconds, before a delayed ACK is - sent.
-
delayed_ack
-
Delay ACK to try and piggyback it onto a data packet or another ACK.
-
do_prr
-
Perform SACK loss recovery using the Proportional Rate Reduction (PRR) - algorithm described in RFC6937. This improves the effectiveness of - retransmissions particular in environments with ACK thinning or burst loss - events, as chances to run out of the ACK clock are reduced, preventing - lengthy and performance reducing RTO based loss recovery (default is - true).
-
do_tcpdrain
-
Flush packets in the TCP reassembly queue if the system is low on - mbufs.
-
drop_synfin
-
Drop TCP packets with both SYN and FIN set.
-
ecn.enable
-
Enable support for TCP Explicit Congestion Notification (ECN). ECN allows - a TCP sender to reduce the transmission rate in order to avoid packet - drops. -
-
0
-
Disable ECN.
-
1
-
Allow incoming connections to request ECN. Outgoing connections will - request ECN.
-
2
-
Allow incoming connections to request ECN. Outgoing connections will - not request ECN. (default)
-
3
-
Negotiate on incoming connection for Accurate ECN, ECN, or no ECN. - Outgoing connections will request Accurate ECN and fall back to ECN - depending on the capabilities of the server.
-
4
-
Negotiate on incoming connection for Accurate ECN, ECN, or no ECN. - Outgoing connections will not request ECN.
-
-
-
ecn.maxretries
-
Number of retries (SYN or SYN/ACK retransmits) before disabling ECN on a - specific connection. This is needed to help with connection establishment - when a broken firewall is in the network path.
-
fast_finwait2_recycle
-
Recycle TCP FIN_WAIT_2 connections faster when the - socket is marked as SBS_CANTRCVMORE (no user - process has the socket open, data received on the socket cannot be read). - The timeout used here is finwait2_timeout.
-
fastopen.acceptany
-
When non-zero, all client-supplied TFO cookies will be considered to be - valid. The default is 0.
-
fastopen.autokey
-
When this and net.inet.tcp.fastopen.server_enable - are non-zero, a new key will be automatically generated after this - specified seconds. The default is 120.
-
fastopen.ccache_bucket_limit
-
The maximum number of entries in a client cookie cache bucket. The default - value can be tuned with the - TCP_FASTOPEN_CCACHE_BUCKET_LIMIT_DEFAULT kernel - option or by setting - net.inet.tcp.fastopen_ccache_bucket_limit in the - loader(8).
-
fastopen.ccache_buckets
-
The number of client cookie cache buckets. Read-only. The value can be - tuned with the TCP_FASTOPEN_CCACHE_BUCKETS_DEFAULT - kernel option or by setting fastopen.ccache_buckets - in the loader(8).
-
fastopen.ccache_list
-
Print the client cookie cache. Read-only.
-
fastopen.client_enable
-
When zero, no new active (i.e., client) TFO connections can be created. On - the transition from enabled to disabled, the client cookie cache is - cleared and disabled. The transition from enabled to disabled does not - affect any active TFO connections in progress; it only prevents new ones - from being established. The default is 0.
-
fastopen.keylen
-
The key length in bytes. Read-only.
-
fastopen.maxkeys
-
The maximum number of keys supported. Read-only,
-
fastopen.maxpsks
-
The maximum number of pre-shared keys supported. Read-only.
-
fastopen.numkeys
-
The current number of keys installed. Read-only.
-
fastopen.numpsks
-
The current number of pre-shared keys installed. Read-only.
-
fastopen.path_disable_time
-
When a failure occurs while trying to create a new active (i.e., client) - TFO connection, new active connections on the same path, as determined by - the tuple {client_ip, server_ip, server_port}, will be forced to be - non-TFO for this many seconds. Note that the path disable mechanism relies - on state stored in client cookie cache entries, so it is possible for the - disable time for a given path to be reduced if the corresponding client - cookie cache entry is reused due to resource pressure before the disable - period has elapsed. The default is - TCP_FASTOPEN_PATH_DISABLE_TIME_DEFAULT.
-
fastopen.psk_enable
-
When non-zero, pre-shared key (PSK) mode is enabled for all TFO servers. - On the transition from enabled to disabled, all installed pre-shared keys - are removed. The default is 0.
-
fastopen.server_enable
-
When zero, no new passive (i.e., server) TFO connections can be created. - On the transition from enabled to disabled, all installed keys and - pre-shared keys are removed. On the transition from disabled to enabled, - if fastopen.autokey is non-zero and there are no - keys installed, a new key will be generated immediately. The transition - from enabled to disabled does not affect any passive TFO connections in - progress; it only prevents new ones from being established. The default is - 0.
-
fastopen.setkey
-
Install a new key by writing - net.inet.tcp.fastopen.keylen bytes to this - sysctl.
-
fastopen.setpsk
-
Install a new pre-shared key by writing - net.inet.tcp.fastopen.keylen bytes to this - sysctl.
-
finwait2_timeout
-
Timeout to use for fast recycling of TCP - FIN_WAIT_2 connections - (fast_finwait2_recycle). Defaults to 60 - seconds.
-
functions_available
-
List of available TCP function blocks (TCP stacks).
-
functions_default
-
The default TCP function block (TCP stack).
-
hostcache
-
The TCP host cache is used to cache connection details and metrics to - improve future performance of connections between the same hosts. At the - completion of a TCP connection, a host will cache information for the - connection for some defined period of time. There are a number of - hostcache variables under this node. See - hostcache.enable.
-
hostcache.bucketlimit
-
The maximum number of entries for the same hash. Defaults to 30.
-
hostcache.cachelimit
-
Overall entry limit for hostcache. Defaults to - hashsize * bucketlimit.
-
hostcache.count
-
The current number of entries in the host cache.
-
hostcache.enable
-
Enable/disable the host cache: -
-
0
-
Disable the host cache.
-
1
-
Enable the host cache. (default)
-
-
-
hostcache.expire
-
Time in seconds, how long a entry should be kept in the host cache since - last accessed. Defaults to 3600 (1 hour).
-
hostcache.hashsize
-
Size of TCP hostcache hashtable. This number has to be a power of two, or - will be rejected. Defaults to 512.
-
hostcache.histo
-
Provide a Histogram of the hostcache hash utilization.
-
hostcache.list
-
Provide a complete list of all current entries in the host cache.
-
hostcache.prune
-
Time in seconds between pruning expired host cache entries. Defaults to - 300 (5 minutes).
-
hostcache.purge
-
Expire all entries on next pruning of host cache entries. Any non-zero - setting will be reset to zero, once the purge is running. -
-
0
-
Do not purge all entries when pruning the host cache (default).
-
1
-
Purge all entries when doing the next pruning.
-
2
-
Purge all entries and also reseed the hash salt.
-
-
-
hostcache.purgenow
-
Immediately purge all entries once set to any value. Setting this to 2 - will also reseed the hash salt.
-
icmp_may_rst
-
Certain ICMP unreachable messages may abort connections in SYN-SENT - state.
-
initcwnd_segments
-
Enable the ability to specify initial congestion window in number of - segments. The default value is 10 as suggested by RFC 6928. Changing the - value on the fly would not affect connections using congestion window from - the hostcache. Caution: This regulates the burst of packets allowed to be - sent in the first RTT. The value should be relative to the link capacity. - Start with small values for lower-capacity links. Large bursts can cause - buffer overruns and packet drops if routers have small buffers or the link - is experiencing congestion.
-
insecure_rst
-
Use criteria defined in RFC793 instead of RFC5961 for accepting RST - segments. Default is false.
-
insecure_syn
-
Use criteria defined in RFC793 instead of RFC5961 for accepting SYN - segments. Default is false.
-
insecure_ack
-
Use criteria defined in RFC793 for validating SEG.ACK. Default is - false.
-
isn_reseed_interval
-
The interval (in seconds) specifying how often the secret data used in RFC - 1948 initial sequence number calculations should be reseeded. By default, - this variable is set to zero, indicating that no reseeding will occur. - Reseeding should not be necessary, and will break - TIME_WAIT recycling for a few minutes.
-
keepcnt
-
Number of keepalive probes sent, with no response, before a connection is - dropped. The default is 8 packets.
-
keepidle
-
Amount of time, in milliseconds, that the connection must be idle before - sending keepalive probes (if enabled). The default is 7200000 msec (7.2M - msec, 2 hours).
-
keepinit
-
Timeout, in milliseconds, for new, non-established TCP connections. The - default is 75000 msec (75K msec, 75 sec).
-
keepintvl
-
The interval, in milliseconds, between keepalive probes sent to remote - machines, when no response is received on a keepidle - probe. The default is 75000 msec (75K msec, 75 sec).
-
log_in_vain
-
Log any connection attempts to ports where there is no socket accepting - connections. The value of 1 limits the logging to SYN (connection - establishment) packets only. A value of 2 results in any TCP packets to - closed ports being logged. Any value not listed above disables the logging - (default is 0, i.e., the logging is disabled).
-
minmss
-
Minimum TCP Maximum Segment Size; used to prevent a denial of service - attack from an unreasonably low MSS.
-
msl
-
The Maximum Segment Lifetime, in milliseconds, for a packet.
-
msl_local
-
The Maximum Segment Lifetime, in milliseconds, for a packet when both - endpoints are local. msl_local is only used if - nolocaltimewait, which is deprecated, is zero.
-
mssdflt
-
The default value used for the TCP Maximum Segment Size - (“MSS”) for IPv4 when no advice to the contrary is received - from MSS negotiation.
-
newcwv
-
Enable the New Congestion Window Validation mechanism as described in RFC - 7661. This gently reduces the congestion window during periods, where TCP - is application limited and the network bandwidth is not utilized - completely. That prevents self-inflicted packet losses once the - application starts to transmit data at a higher speed.
-
nolocaltimewait
-
Suppress the creation of TCP TIME_WAIT states for - connections in which both endpoints are local. The default is 0. - nolocaltimewait is deprecated and will be removed in - FreeBSD 16. msl_local can be - used instead.
-
path_mtu_discovery
-
Enable Path MTU Discovery.
-
pcbcount
-
Number of active protocol control blocks (read-only).
-
perconn_stats_enable
-
Controls the default collection of statistics for all connections using - the stats(3) framework. 0 disables, 1 enables, 2 enables - random sampling across log id connection groups with all connections in a - group receiving the same setting.
-
perconn_stats_sample_rates
-
A CSV list of template_spec=percent key-value pairs which controls the per - template sampling rates when stats(3) sampling is - enabled.
-
persmax
-
Maximum persistence interval, msec.
-
persmin
-
Minimum persistence interval, msec.
-
pmtud_blackhole_detection
-
Enable automatic path MTU blackhole detection. In case of retransmits of - MSS sized segments, the OS will lower the MSS to check if it's an MTU - problem. If the current MSS is greater than the configured value to try - (net.inet.tcp.pmtud_blackhole_mss and - net.inet.tcp.v6pmtud_blackhole_mss), it will be set - to this value, otherwise, the MSS will be set to the default values - (net.inet.tcp.mssdflt and - net.inet.tcp.v6mssdflt). Settings: -
-
0
-
Disable path MTU blackhole detection.
-
1
-
Enable path MTU blackhole detection for IPv4 and IPv6.
-
2
-
Enable path MTU blackhole detection only for IPv4.
-
3
-
Enable path MTU blackhole detection only for IPv6.
-
-
-
pmtud_blackhole_mss
-
MSS to try for IPv4 if PMTU blackhole detection is turned on.
-
reass.cursegments
-
The current total number of segments present in all reassembly - queues.
-
reass.maxqueuelen
-
The maximum number of segments allowed in each reassembly queue. By - default, the system chooses a limit based on each TCP connection's receive - buffer size and maximum segment size (MSS). The actual limit applied to a - session's reassembly queue will be the lower of the system-calculated - automatic limit and the user-specified - reass.maxqueuelen limit.
-
reass.maxsegments
-
The maximum limit on the total number of segments across all reassembly - queues. The limit can be adjusted as a tunable.
-
recvbuf_auto
-
Enable automatic receive buffer sizing as a connection progresses.
-
recvbuf_max
-
Maximum size of automatic receive buffer.
-
recvspace
-
Initial TCP receive window (buffer size).
-
retries
-
Maximum number of consecutive timer based retransmits sent after a data - segment is lost (default and maximum is 12).
-
rexmit_drop_options
-
Drop TCP options from third and later retransmitted SYN segments of a - connection.
-
rexmit_initial, - rexmit_min, rexmit_slop, - rexmit_max
-
Adjust the retransmit timer calculation for TCP. A new connection starts - with timer set to rexmit_initial. The - rexmit_slop typically added to the raw calculation - to take into account occasional variances that the SRTT (smoothed - round-trip time) is unable to accommodate, while the minimum specifies an - absolute minimum. While a number of TCP RFCs suggest a 1 second minimum, - these RFCs tend to focus on streaming behavior, and fail to deal with the - fact that a 1 second minimum has severe detrimental effects over lossy - interactive connections, such as a 802.11b wireless link, and over very - fast but lossy connections for those cases not covered by the fast - retransmit code. For this reason, we use 200ms of slop and a near-0 - minimum, which gives us an effective minimum of 200ms (similar to Linux). - The initial value is used before an RTT measurement has been performed. - The rexmit_min and rexmit_max - set minimum and maximum timer values that a connection may have.
-
rfc1323
-
Implement the window scaling and timestamp options of RFC 1323/RFC 7323 - (default is 1). Settings: -
-
0
-
Disable window scaling and timestamp option.
-
1
-
Enable window scaling and timestamp option.
-
2
-
Enable only window scaling.
-
3
-
Enable only timestamp option.
-
-
-
rfc3042
-
Enable the Limited Transmit algorithm as described in RFC 3042. It helps - avoid timeouts on lossy links and also when the congestion window is - small, as happens on short transfers.
-
rfc3390
-
Enable support for RFC 3390, which allows for a variable-sized starting - congestion window on new connections, depending on the maximum segment - size. This helps throughput in general, but particularly affects short - transfers and high-bandwidth large propagation-delay connections.
-
sack.enable
-
Enable support for RFC 2018, TCP Selective Acknowledgment option, which - allows the receiver to inform the sender about all successfully arrived - segments, allowing the sender to retransmit the missing segments - only.
-
sack.globalholes
-
Global number of TCP SACK holes currently allocated.
-
sack.globalmaxholes
-
Maximum number of SACK holes per system, across all connections. Defaults - to 65536.
-
sack.lrd
-
Enable Lost Retransmission Detection for SACK-enabled sessions, enabled by - default. Under severe congestion, a retransmission can be lost which then - leads to a mandatory Retransmission Timeout (RTO), followed by slow-start. - LRD will try to resend the repeatedly lost packet, preventing the - time-consuming RTO and performance reducing slow-start or purge of the - SACK scoreboard.
-
sack.maxholes
-
Maximum number of SACK holes per connection. Defaults to 128.
-
sack.revised
-
Enables three updated mechanisms from RFC6675 (default is true). Calculate - the bytes in flight using the algorithm described in RFC 6675, and is also - an improvement when Proportional Rate Reduction is enabled. Next, Rescue - Retransmission helps timely loss recovery, when the trailing segments of a - transmission are lost, while no additional data is ready to be sent. In - case a partial ACK without a SACK block is received during SACK loss - recovery, the trailing segment is immediately resent, rather than waiting - for a Retransmission timeout. Finally, SACK loss recovery is also engaged, - once two segments plus one byte are SACKed - even if no traditional - duplicate ACKs were observed. sack.revised is - deprecated and will be removed in FreeBSD 16. - sack.enable will always follow RFC6675.
-
sendbuf_auto
-
Enable automatic send buffer sizing.
-
sendbuf_auto_lowat
-
Modify threshold for auto send buffer growth to account for - SO_SNDLOWAT.
-
sendbuf_inc
-
Incrementor step size of automatic send buffer.
-
sendbuf_max
-
Maximum size of automatic send buffer.
-
sendspace
-
Initial TCP send window (buffer size).
-
syncache
-
Variables under the net.inet.tcp.syncache node are - documented in syncache(4).
-
syncookies
-
Determines whether or not SYN cookies should be generated for outbound - SYN-ACK packets. SYN cookies are a great help during SYN flood attacks, - and are enabled by default. (See syncookies(4).)
-
syncookies_only
-
See syncookies(4).
-
tcbhashsize
-
Size of the TCP control-block hash table (read-only). This is tuned using - the kernel option TCBHASHSIZE or by setting - net.inet.tcp.tcbhashsize in the - loader(8).
-
tolerate_missing_ts
-
Tolerate the missing of timestamps (RFC 1323/RFC 7323) for TCP segments - belonging to TCP connections for which support of TCP timestamps has been - negotiated. As of June 2021, several TCP stacks are known to violate RFC - 7323, including modern widely deployed ones. Therefore the default is 1, - i.e., the missing of timestamps is tolerated.
-
ts_offset_per_conn
-
When initializing the TCP timestamps, use a per connection offset instead - of a per host pair offset. Default is to use per connection offsets as - recommended in RFC 7323.
-
tso
-
Enable TCP Segmentation Offload.
-
udp_tunneling_overhead
-
The overhead taken into account when using UDP encapsulation. Since MSS - clamping by middleboxes will most likely not work, values larger than 8 - (the size of the UDP header) are also supported. Supported values are - between 8 and 1024. The default is 8.
-
udp_tunneling_port
-
The local UDP encapsulation port. A value of 0 indicates that UDP - encapsulation is disabled. The default is 0.
-
v6mssdflt
-
The default value used for the TCP Maximum Segment Size - (“MSS”) for IPv6 when no advice to the contrary is received - from MSS negotiation.
-
v6pmtud_blackhole_mss
-
MSS to try for IPv6 if PMTU blackhole detection is turned on. See - pmtud_blackhole_detection.
-
-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[]
-
when trying to establish a connection on a socket which already has - one;
-
[ENOBUFS] or [ENOMEM]
-
when the system runs out of memory for an internal data structure;
-
[]
-
when a connection was dropped due to excessive retransmissions;
-
[]
-
when the remote peer forces the connection to be closed;
-
[]
-
when the remote peer actively refuses connection establishment (usually - because no process is listening to the port);
-
[]
-
when an attempt is made to create a socket with a port which has already - been allocated;
-
[]
-
when an attempt is made to create a socket with a network address for - which no network interface exists;
-
[]
-
when an attempt is made to bind or connect a socket to a multicast - address.
-
[]
-
when trying to change TCP function blocks at an invalid point in the - session;
-
[]
-
when trying to use a TCP function block that is not available;
-
-
-
-

-

getsockopt(2), setfib(2), - socket(2), stats(3), - sysctl(3), blackhole(4), - inet(4), intro(4), - ip(4), ktls(4), - mod_cc(4), siftr(4), - syncache(4), tcp_bbr(4), - tcp_rack(4), setkey(8), - sysctl(8), tcp_functions(9)

-

V. Jacobson, - B. Braden, and D. Borman, - TCP Extensions for High Performance, - RFC 1323.

-

D. Borman, - B. Braden, V. Jacobson, - and R. Scheffenegger, TCP - Extensions for High Performance, RFC - 7323.

-

A. Heffernan, - Protection of BGP Sessions via the TCP MD5 Signature - Option, RFC 2385.

-

K. Ramakrishnan, - S. Floyd, and D. Black, - The Addition of Explicit Congestion Notification (ECN) to - IP, RFC 3168.

-

A. Ramaiah, - R. Stewart, and M. Dalal, - Improving TCP's Robustness to Blind In-Window - Attacks, RFC 5961.

-
-
-

-

The TCP protocol appeared in 4.2BSD. The - RFC 1323 extensions for window scaling and timestamps were added in - 4.4BSD. The TCP_INFO option - was introduced in Linux 2.6 and is - .

-
-
- - - - - -
September 5, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/tcp_bbr.4 3.html b/static/freebsd/man4/tcp_bbr.4 3.html deleted file mode 100644 index cff25686..00000000 --- a/static/freebsd/man4/tcp_bbr.4 3.html +++ /dev/null @@ -1,145 +0,0 @@ - - - - - - -
TCP_BBR(4)Device Drivers ManualTCP_BBR(4)
-
-
-

-

tcp_bbr — TCP - Bottleneck Bandwidth and Round-Trip Time Algorithm

-
-
-

-

To load the driver as a module at boot time, place the following - line in loader.conf(5):

-
-
tcp_bbr_load="YES"
-
-

To enable the TCP stack you must place the following line in the - sysctl.conf(5):

-
-
net.inet.tcp.functions_default=bbr
-
-
-
-

-

Bottleneck bandwidth and round-trip time (BBR) is a congestion - control algorithm which seeks high throughput with a small queue by probing - BW and RTT. It is a round-up redesign of congestion control, which is not - loss-based, delay-based, ECN-based or AIMD-based.

-

The core design of BBR is about creating a model graph of the - network path by estimating the maximum BW and minimum RTT on each ACK.

-
-
-

-

The algorithm exposes the following scopes in the - net.inet.tcp.bbr branch of the - sysctl(3) MIB:

-
-
cwnd
-
Cwnd controls, for example "target cwnd rtt measurement" and - "BBR initial window".
-
measure
-
Measurement controls.
-
pacing
-
Connection pacing controls.
-
policer
-
Policer controls, for example "false detection threshold" and - "loss threshold".
-
probertt
-
Probe RTT controls.
-
startup
-
Startup controls.
-
states
-
State controls.
-
timeout
-
Time out controls.
-
-

Besides the variables within the above scopes the following - variables are also exposed in the net.inet.tcp.bbr - branch:

-
-
clrlost
-
Clear lost counters.
-
software_pacing
-
Total number of software paced flows.
-
hdwr_pacing
-
Total number of hardware paced flows.
-
enob_no_hdwr_pacing
-
Total number of enobufs for non-hardware paced flows.
-
enob_hdwr_pacing
-
Total number of enobufs for hardware paced flows.
-
rtt_tlp_thresh
-
What divisor for TLP rtt/retran will be added (1=rtt, 2=1/2 rtt etc).
-
reorder_fade
-
Does reorder detection fade, if so how many ms (0 means never).
-
reorder_thresh
-
What factor for rack will be added when seeing reordering (shift - right).
-
bb_verbose
-
Should BBR black box logging be verbose.
-
sblklimit
-
When do we start ignoring small sack blocks.
-
resend_use_tso
-
Can resends use TSO?
-
data_after_close
-
Do we hold off sending a RST until all pending data is ack'd.
-
kill_paceout
-
When we hit this many errors in a row, kill the session?
-
error_paceout
-
When we hit an error what is the min to pace out in usec's?
-
cheat_rxt
-
Do we burst 1ms between sends on retransmissions (like rack)?
-
minrto
-
Minimum RTO in ms.
-
-
-
-

-

cc_chd(4), cc_cubic(4), - cc_hd(4), cc_htcp(4), - cc_newreno(4), cc_vegas(4), - h_ertt(4), mod_cc(4), - tcp(4), tcp_rack(4), - mod_cc(9)

-

Neal Cardwell, - Yuchung Cheng, Stephen - Gunn, Soheil Hassas Yeganeh, and - Van Jacobson, BBR: - Congestion-Based Congestion Control, ACM Queue, Vol. - 14, September / October 2016.

-

Dominik Scholz, - Benedikt Jaeger, Lukas - Schwaighofer, Daniel Raumer, - Fabien Geyer, and Georg - Carle, Towards a Deeper Understanding of TCP BBR - Congestion Control, IFIP Networking 2018, - http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/IFIP-Networking-2018-TCP-BBR.pdf, - May 2018.

-
-
-

-

The tcp_bbr congestion control module - first appeared in FreeBSD 13.0.

-
-
-

-

The tcp_bbr congestion control module was - written by Randall Stewart - <rrs@FreeBSD.org> and - sponsored by Netflix, Inc. This manual page was written by - Gordon Bergling - <gbe@FreeBSD.org>.

-
-
- - - - - -
December 17, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/tcp_rack.4 3.html b/static/freebsd/man4/tcp_rack.4 3.html deleted file mode 100644 index 86d73f08..00000000 --- a/static/freebsd/man4/tcp_rack.4 3.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - -
TCP_RACK(4)Device Drivers ManualTCP_RACK(4)
-
-
-

-

tcp_rack — TCP - RACK-TLP Loss Detection Algorithm for TCP

-
-
-

-

To load the TCP stack as a module at boot time, place the - following line in loader.conf(5):

-
-
tcp_rack_load="YES"
-
-

To enable the TCP stack, place the following line in the - sysctl.conf(5):

-
-
net.inet.tcp.functions_default=rack
-
-
-
-

-

RACK-TLP uses per-segment transmit timestamps and selective - acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) - starts fast recovery quickly using time-based inferences derived from - acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and - sends a probe packet to trigger ACK feedback to avoid retransmission timeout - (RTO) events.

-

Compared to the widely used duplicate acknowledgment (DupAck) - threshold approach, RACK-TLP detects losses more efficiently when there are - application-limited flights of data, lost retransmissions, or data packet - reordering events.

-

It is intended to be an alternative to the DupAck threshold - approach.

-
-
-

-

The algorithm exposes the following scopes in the - net.inet.tcp.rack branch of the - sysctl(3) MIB:

-
-
net.inet.tcp.rack.misc
-
Misc related controls
-
net.inet.tcp.rack.features
-
Feature controls
-
net.inet.tcp.rack.measure
-
Measure related controls
-
net.inet.tcp.rack.timers
-
Timer related controls
-
net.inet.tcp.rack.tlp
-
TLP and Rack related Controls
-
net.inet.tcp.rack.timely
-
Rack Timely RTT Controls
-
net.inet.tcp.rack.hdwr_pacing
-
Pacing related Controls
-
net.inet.tcp.rack.pacing
-
Pacing related Controls
-
net.inet.tcp.rack.tp
-
Rack tracepoint facility
-
net.inet.tcp.rack.probertt
-
ProbeRTT related Controls
-
net.inet.tcp.rack.stats
-
Rack Counters
-
net.inet.tcp.rack.sack_attack
-
Rack Sack Attack Counters and Controls
-
-

Besides the variables within the above scopes the following - variables are also exposed in the net.inet.tcp.rack - branch:

-
-
net.inet.tcp.rack.clear
-
Clear counters
-
net.inet.tcp.rack.opts
-
RACK Option Stats
-
net.inet.tcp.rack.outsize
-
MSS send sizes
-
net.inet.tcp.rack.req_measure_cnt
-
If doing dynamic pacing, how many measurements must be in before we start - pacing?
-
net.inet.tcp.rack.use_pacing
-
If set we use pacing, if clear we use only the original burst - mitigation
-
net.inet.tcp.rack.rate_sample_method
-
What method should we use for rate sampling 0=high, 1=low
-
-
-
-

-

cc_chd(4), cc_cubic(4), - cc_hd(4), cc_htcp(4), - cc_newreno(4), cc_vegas(4), - h_ertt(4), mod_cc(4), - tcp(4), tcp_bbr(4), - mod_cc(9)

-

Neal Cardwell, - Yuchung Cheng, Nandita - Dukkipati, and Priyaranjan Jha, - The RACK-TLP Loss Detection Algorithm for TCP, - February 2021, RFC - 8985.

-

M. Allman, - V. Paxson, and E. Blanton, - TCP Congestion Control, September - 2009, RFC 5681.

-

M. Mathis, - Nandita Dukkipati, and Yuchung - Cheng, Proportional Rate Reduction for TCP, - May 2013, RFC - 6937.

-
-
-

-

The tcp_rack congestion control module - first appeared in FreeBSD 13.0.

-
-
-

-

The tcp_rack congestion control module was - written by Randall Stewart - <rrs@FreeBSD.org> and - sponsored by Netflix, Inc. This manual page was written by - Gordon Bergling - <gbe@FreeBSD.org>.

-
-
- - - - - -
March 18, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/tdfx.4 3.html b/static/freebsd/man4/tdfx.4 3.html deleted file mode 100644 index 679f262f..00000000 --- a/static/freebsd/man4/tdfx.4 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
TDFX(4)Device Drivers ManualTDFX(4)
-
-
-

-

tdfx — Voodoo - Graphics and VoodooII Memory Access GLIDE device driver

-
-
-

-

device tdfx

-
-
-

-

This driver creates an entry in /dev that - allows programs (mostly - ) to access the device memory of the Voodoo Graphics and - VoodooII 3D accelerators created by - . This provides an interface for applications based on the - or that simply use the API provided by the linux - /dev/3dfx device to use the video device.

-

Supports all cards based on the following chipsets:

-

- -

Specifically, the following cards should work:

-

- -

Note that this driver does not currently have support for the - Voodoo Banshee, Voodoo3, Voodoo5, or Voodoo6 based cards. It also does not - currently support the Voodoo Rush. It also does not yet handle the SLI - feature of the Voodoo II boards. You can only use each of them - separately.

-

By loading the tdfx_linux.ko and - linux.ko modules, you can enable the linux ioctl - code for this driver, where the only supported applications currently - reside.

-
-
-

-
-
/dev/3dfx
-
Symlinked to default - board
-
/dev/3dfx*
-
programming interface -

-
-
/dev/voodoo
-
Mirrors of above interfaces
-
/dev/voodoo*
-
(Some apps use /dev/voodoo)
-
-
-
-

-

kld(4), linux(4), - kldload(8)

-
-
-

-

The tdfx driver appeared in - FreeBSD 5.0, and was originally developed for Linux - kernel 2.0.x, later written for 2.2.x and 2.4.x.

-
-
-

-

The driver was developed by Coleman Kane - <cokane@micro.ti.com> - after the linux version of this driver by Darryll - Straus, John Taylor, Jens - Axboe, Carlo Wood - <carlo@alinoe.com> - and Joseph Kain - <joseph@3dfx.com> to - be directly compatible with it and support the many GLIDE based games - available for Linux and UNIX.

-
-
- - - - - -
February 19, 2001FreeBSD 15.0
diff --git a/static/freebsd/man4/termios.4 3.html b/static/freebsd/man4/termios.4 3.html deleted file mode 100644 index d3827e1e..00000000 --- a/static/freebsd/man4/termios.4 3.html +++ /dev/null @@ -1,1050 +0,0 @@ - - - - - - -
TERMIOS(4)Device Drivers ManualTERMIOS(4)
-
-
-

-

termios — general - terminal line discipline

-
-
-

-

#include - <termios.h>

-
-
-

-

This describes a general terminal line discipline that is - supported on tty asynchronous communication ports.

-
-

-

When a terminal file is opened, it normally causes the process to - wait until a connection is established. For most hardware, the presence of a - connection is indicated by the assertion of the hardware - CARRIER line. If the termios structure associated - with the terminal file has the CLOCAL flag set in - the cflag, or if the O_NONBLOCK flag is set in the - open(2) call, then the open will succeed even without a - connection being present. In practice, applications seldom open these files; - they are opened by special programs, such as getty(8), and - become an application's standard input, output, and error files.

-
-
-

-

Every process is associated with a particular process group and - session. The grouping is hierarchical: every member of a particular process - group is a member of the same session. This structuring is used in managing - groups of related processes for purposes of - ; - that is, the ability from the keyboard (or from program control) to - simultaneously stop or restart a complex command (a command composed of one - or more related processes). The grouping into process groups allows - delivering of signals that stop or start the group as a whole, along with - arbitrating which process group has access to the single controlling - terminal. The grouping at a higher layer into sessions is to restrict the - job control related signals and system calls to within processes resulting - from a particular instance of a “login”. Typically, a session - is created when a user logs in, and the login terminal is setup to be the - controlling terminal; all processes spawned from that login shell are in the - same session, and inherit the controlling terminal.

-

A job control shell operating interactively (that is, reading - commands from a terminal) normally groups related processes together by - placing them into the same process group. A set of processes in the same - process group is collectively referred to as a “job”. When the - foreground process group of the terminal is the same as the process group of - a particular job, that job is said to be in the “foreground”. - When the process group of the terminal is different from the process group - of a job (but is still the controlling terminal), that job is said to be in - the “background”. Normally the shell reads a command and - starts the job that implements that command. If the command is to be started - in the foreground (typical), it sets the process group of the terminal to - the process group of the started job, waits for the job to complete, and - then sets the process group of the terminal back to its own process group - (it puts itself into the foreground). If the job is to be started in the - background (as denoted by the shell operator "&"), it never - changes the process group of the terminal and does not wait for the job to - complete (that is, it immediately attempts to read the next command). If the - job is started in the foreground, the user may type a key (usually - ‘^Z’) which generates the terminal - stop signal (SIGTSTP) and has the effect of stopping - the entire job. The shell will notice that the job stopped, and will resume - running after placing itself in the foreground. The shell also has commands - for placing stopped jobs in the background, and for placing stopped or - background jobs into the foreground.

-
-
-

-

An orphaned process group is a process group that has no process - whose parent is in a different process group, yet is in the same session. - Conceptually it means a process group that does not have a parent that could - do anything if it were to be stopped. For example, the initial login shell - is typically in an orphaned process group. Orphaned process groups are - immune to keyboard generated stop signals and job control signals resulting - from reads or writes to the controlling terminal.

-
-
-

-

A terminal may belong to a process as its controlling terminal. - Each process of a session that has a controlling terminal has the same - controlling terminal. A terminal may be the controlling terminal for at most - one session. The controlling terminal for a session is allocated by the - session leader by issuing the TIOCSCTTY ioctl. A - controlling terminal is never acquired by merely opening a terminal device - file. When a controlling terminal becomes associated with a session, its - foreground process group is set to the process group of the session - leader.

-

The controlling terminal is inherited by a child process during a - fork(2) function call. A process relinquishes its - controlling terminal when it creates a new session with the - setsid(2) function; other processes remaining in the old - session that had this terminal as their controlling terminal continue to - have it. A process does not relinquish its controlling terminal simply by - closing all of its file descriptors associated with the controlling terminal - if other processes continue to have it open.

-

When a controlling process terminates, the controlling terminal is - disassociated from the current session, allowing it to be acquired by a new - session leader. Subsequent access to the terminal by other processes in the - earlier session will be denied, with attempts to access the terminal treated - as if modem disconnect had been sensed.

-
-
-

-

If a process is in the foreground process group of its controlling - terminal, read operations are allowed. Any attempts by a process in a - background process group to read from its controlling terminal causes a - SIGTTIN signal to be sent to the process's group - unless one of the following special cases apply: if the reading process is - ignoring or blocking the SIGTTIN signal, or if the - process group of the reading process is orphaned, the - read(2) returns -1 with errno set to - EIO and no signal is sent. The default action of the - SIGTTIN signal is to stop the process to which it is - sent.

-

If a process is in the foreground process group of its controlling - terminal, write operations are allowed. Attempts by a process in a - background process group to write to its controlling terminal will cause the - process group to be sent a SIGTTOU signal unless one - of the following special cases apply: if TOSTOP is - not set, or if TOSTOP is set and the process is - ignoring or blocking the SIGTTOU signal, the process - is allowed to write to the terminal and the SIGTTOU - signal is not sent. If TOSTOP is set, and the - process group of the writing process is orphaned, and the writing process is - not ignoring or blocking SIGTTOU, the - write(2) returns -1 with errno set to - EIO and no signal is sent.

-

Certain calls that set terminal parameters are treated in the same - fashion as write, except that TOSTOP is ignored; - that is, the effect is identical to that of terminal writes when - TOSTOP is set.

-
-
-

-

A terminal device associated with a terminal device file may - operate in full-duplex mode, so that data may arrive even while output is - occurring. Each terminal device file has associated with it an input queue, - into which incoming data is stored by the system before being read by a - process. The system imposes a limit, {MAX_INPUT}, on - the number of bytes that may be stored in the input queue. The behavior of - the system when this limit is exceeded depends on the setting of the - IMAXBEL flag in the termios - c_iflag. If this flag is set, the terminal is sent an - ASCII BEL character each time a character is - received while the input queue is full. Otherwise, the input queue is - flushed upon receiving the character.

-

Two general kinds of input processing are available, determined by - whether the terminal device file is in canonical mode or noncanonical mode. - Additionally, input characters are processed according to the - c_iflag and c_lflag fields. Such - processing can include echoing, which in general means transmitting input - characters immediately back to the terminal when they are received from the - terminal. This is useful for terminals that can operate in full-duplex - mode.

-

The manner in which data is provided to a process reading from a - terminal device file is dependent on whether the terminal device file is in - canonical or noncanonical mode.

-

Another dependency is whether the - O_NONBLOCK flag is set by open(2) - or fcntl(2). If the O_NONBLOCK - flag is clear, then the read request is blocked until data is available or a - signal has been received. If the O_NONBLOCK flag is - set, then the read request is completed, without blocking, in one of three - ways:

-
    -
  1. If there is enough data available to satisfy the entire request, and the - read completes successfully the number of bytes read is returned.
    2. -
  2. If there is not enough data available to satisfy the entire request, and - the read completes successfully, having read as much data as possible, the - number of bytes read is returned.
    3. -
  3. If there is no data available, the read returns -1, with errno set to - EAGAIN.
    4. -
-

When data is available depends on whether the input processing - mode is canonical or noncanonical.

-
-
-

-

In canonical mode input processing, terminal input is processed in - units of lines. A line is delimited by a newline - ‘\n’ character, an end-of-file - (EOF) character, or an end-of-line - (EOL) character. See the - Special Characters section for - more information on EOF and - EOL. This means that a read request will not return - until an entire line has been typed, or a signal has been received. Also, no - matter how many bytes are requested in the read call, at most one line is - returned. It is not, however, necessary to read a whole line at once; any - number of bytes, even one, may be requested in a read without losing - information.

-

{MAX_CANON} is a limit on the number of - bytes in a line. The behavior of the system when this limit is exceeded is - the same as when the input queue limit {MAX_INPUT}, - is exceeded.

-

Erase and kill processing occur when either of two special - characters, the ERASE and - KILL characters (see the - Special Characters section), is - received. This processing affects data in the input queue that has not yet - been delimited by a newline NL, - EOF, or EOL character. This - un-delimited data makes up the current line. The - ERASE character deletes the last character in the - current line, if there is any. The KILL character - deletes all data in the current line, if there is any. The - ERASE and KILL characters - have no effect if there is no data in the current line. The - ERASE and KILL characters - themselves are not placed in the input queue.

-
-
-

-

In noncanonical mode input processing, input bytes are not - assembled into lines, and erase and kill processing does not occur. The - values of the VMIN and VTIME - members of the c_cc array are used to determine how to - process the bytes received.

-

MIN represents the minimum number of bytes - that should be received when the read(2) function - successfully returns. TIME is a timer of 0.1 second - granularity that is used to time out bursty and short term data - transmissions. If MIN is greater than - { MAX_INPUT}, the response - to the request is undefined. The four possible values for - MIN and TIME and their - interactions are described below.

-
-
-

-

In this case TIME serves as an inter-byte - timer and is activated after the first byte is received. Since it is an - inter-byte timer, it is reset after a byte is received. The interaction - between MIN and TIME is as - follows: as soon as one byte is received, the inter-byte timer is started. - If MIN bytes are received before the inter-byte - timer expires (remember that the timer is reset upon receipt of each byte), - the read is satisfied. If the timer expires before - MIN bytes are received, the characters received to - that point are returned to the user. Note that if - TIME expires at least one byte is returned because - the timer would not have been enabled unless a byte was received. In this - case (MIN > 0, TIME > - 0) the read blocks until the MIN and - TIME mechanisms are activated by the receipt of the - first byte, or a signal is received. If data is in the buffer at the time of - the - (), - the result is as if data had been received immediately after the - read().

-
-
-

-

In this case, since the value of TIME is - zero, the timer plays no role and only MIN is - significant. A pending read is not satisfied until - MIN bytes are received (i.e., the pending read - blocks until MIN bytes are received), or a signal is - received. A program that uses this case to read record-based terminal - I/O may block indefinitely in the read - operation.

-
-
-

-

In this case, since MIN = 0, - TIME no longer represents an inter-byte timer. It - now serves as a read timer that is activated as soon as the read function is - processed. A read is satisfied as soon as a single byte is received or the - read timer expires. Note that in this case if the timer expires, no bytes - are returned. If the timer does not expire, the only way the read can be - satisfied is if a byte is received. In this case the read will not block - indefinitely waiting for a byte; if no byte is received within - TIME*0.1 seconds after the read is initiated, the - read returns a value of zero, having read no data. If data is in the buffer - at the time of the read, the timer is started as if data had been received - immediately after the read.

-
-
-

-

The minimum of either the number of bytes requested or the number - of bytes currently available is returned without waiting for more bytes to - be input. If no characters are available, read returns a value of zero, - having read no data.

-
-
-

-

When a process writes one or more bytes to a terminal device file, - they are processed according to the c_oflag field (see - the Output Modes section). The - implementation may provide a buffering mechanism; as such, when a call to - write() completes, all of the bytes written have - been scheduled for transmission to the device, but the transmission will not - necessarily have been completed.

-
-
-

-

Certain characters have special functions on input or output or - both. These functions are summarized as follows:

-
-
-
Special character on input and is recognized if the - ISIG flag (see the - Local Modes section) is enabled. - Generates a SIGINT signal which is sent to all - processes in the foreground process group for which the terminal is the - controlling terminal. If ISIG is set, the - INTR character is discarded when processed.
-
-
Special character on input and is recognized if the - ISIG flag is enabled. Generates a - SIGQUIT signal which is sent to all processes in - the foreground process group for which the terminal is the controlling - terminal. If ISIG is set, the - QUIT character is discarded when processed.
-
-
Special character on input and is recognized if the - ICANON flag is set. Erases the last character in - the current line; see - Canonical Mode Input - Processing. It does not erase beyond the start of a line, as delimited - by an NL, EOF, or - EOL character. If ICANON - is set, the ERASE character is discarded when - processed.
-
-
Special character on input and is recognized if the - ICANON flag is set. Deletes the entire line, as - delimited by a NL, EOF, or - EOL character. If ICANON - is set, the KILL character is discarded when - processed.
-
-
Special character on input and is recognized if the - ICANON flag is set. When received, all the bytes - waiting to be read are immediately passed to the process, without waiting - for a newline, and the EOF is discarded. Thus, if - there are no bytes waiting (that is, the EOF - occurred at the beginning of a line), a byte count of zero is returned - from the read(), representing an end-of-file - indication. If ICANON is set, the - EOF character is discarded when processed.
-
-
Special character on input and is recognized if the - ICANON flag is set. It is the line delimiter - ‘\n’.
-
-
Special character on input and is recognized if the - ICANON flag is set. Is an additional line - delimiter, like NL.
-
-
If the ISIG flag is enabled, receipt of the - SUSP character causes a - SIGTSTP signal to be sent to all processes in the - foreground process group for which the terminal is the controlling - terminal, and the SUSP character is discarded when - processed.
-
-
Special character on both input and output and is recognized if the - IXON (output control) or - IXOFF (input control) flag is set. Can be used to - temporarily suspend output. It is useful with fast terminals to prevent - output from disappearing before it can be read. If - IXON is set, the STOP - character is discarded when processed.
-
-
Special character on both input and output and is recognized if the - IXON (output control) or - IXOFF (input control) flag is set. Can be used to - resume output that has been suspended by a STOP - character. If IXON is set, the - START character is discarded when processed.
-
-
Special character on input and is recognized if the - ICANON flag is set; it is the - ‘\r’, as denoted in the C Standard - {2}. When ICANON and ICRNL - are set and IGNCR is not set, this character is - translated into a NL, and has the same effect as a - NL character.
-
-

The following special characters are extensions defined by this - system and are not a part of IEEE Std 1003.1 - (“POSIX.1”) termios.

-
-
-
Secondary EOL character. Same function as - EOL.
-
-
Special character on input and is recognized if the - ICANON flag is set. Erases the last word in the - current line according to one of two algorithms. If the - ALTWERASE flag is not set, first any preceding - whitespace is erased, and then the maximal sequence of non-whitespace - characters. If ALTWERASE is set, first any - preceding whitespace is erased, and then the maximal sequence of - alphabetic/underscores or non alphabetic/underscores. As a special case in - this second algorithm, the first previous non-whitespace character is - skipped in determining whether the preceding word is a sequence of - alphabetic/underscores. This sounds confusing but turns out to be quite - practical.
-
-
Special character on input and is recognized if the - ICANON flag is set. Causes the current input edit - line to be retyped.
-
-
Has similar actions to the SUSP character, except - that the SIGTSTP signal is delivered when one of - the processes in the foreground process group issues a - () - to the controlling terminal.
-
-
Special character on input and is recognized if the - IEXTEN flag is set. Receipt of this character - causes the next character to be taken literally.
-
-
Special character on input and is recognized if the - IEXTEN flag is set. Receipt of this character - toggles the flushing of terminal output.
-
-
Special character on input and is recognized if the - ICANON flag is set. Receipt of this character - causes a SIGINFO signal to be sent to the - foreground process group of the terminal. Also, if the - NOKERNINFO flag is not set, it causes the kernel - to write a status message to the terminal that displays the current load - average, the name of the command in the foreground, its process ID, the - symbolic wait channel, the number of user and system seconds used, the - percentage of cpu the process is getting, and the resident set size of the - process. -

In case the kernel has stack(9) support - configured and the sysctl(8) variable - kern.tty_info_kstacks is set to a non-zero value, - the running thread's kernel stack is written to the terminal (e.g., for - debugging purposes).

-
-
-

The NL and CR - characters cannot be changed. The values for all the remaining characters - can be set and are described later in the document under Special Control - Characters.

-

Special character functions associated with changeable special - control characters can be disabled individually by setting their value to - {_POSIX_VDISABLE}; see - Special Control - Characters.

-

If two or more special characters have the same value, the - function performed when that character is received is undefined.

-
-
-

-

If a modem disconnect is detected by the terminal interface for a - controlling terminal, and if CLOCAL is not set in - the c_cflag field for the terminal, the - SIGHUP signal is sent to the controlling process - associated with the terminal. Unless other arrangements have been made, this - causes the controlling process to terminate. Any subsequent call to the - () - function returns the value zero, indicating end of file. Thus, processes - that read a terminal file and test for end-of-file can terminate - appropriately after a disconnect. Any subsequent - () - to the terminal device returns -1, with errno set to - EIO, until the device is closed.

-
-
-
-

-
-

-

The last process to close a terminal device file causes any output - to be sent to the device and any input to be discarded. Then, if - HUPCL is set in the control modes, and the - communications port supports a disconnect function, the terminal device - performs a disconnect.

-
-
-

-

Routines that need to control certain terminal I/O characteristics - do so by using the termios structure as defined in the header - <termios.h>. This structure - contains minimally four scalar elements of bit flags and one array of - special characters. The scalar flag elements are named: - c_iflag, c_oflag, - c_cflag, and c_lflag. The - character array is named c_cc, and its maximum index - is NCCS.

-
-
-

-

Values of the c_iflag field describe the - basic terminal input control, and are composed of following masks:

-

-
-
-
-
/* ignore BREAK condition */
-
-
/* map BREAK to SIGINTR */
-
-
/* ignore (discard) parity errors */
-
-
/* mark parity and framing errors */
-
-
/* enable checking of parity errors */
-
-
/* strip 8th bit off chars */
-
-
/* map NL into CR */
-
-
/* ignore CR */
-
-
/* map CR to NL (ala CRMOD) */
-
-
/* enable output flow control */
-
-
/* enable input flow control */
-
-
/* any char will restart after stop */
-
-
/* ring bell on input queue full */
-
-
/* assume input is UTF-8 encoded */
-
-
-

In the context of asynchronous serial data transmission, a break - condition is defined as a sequence of zero-valued bits that continues for - more than the time to send one byte. The entire sequence of zero-valued bits - is interpreted as a single break condition, even if it continues for a time - equivalent to more than one byte. In contexts other than asynchronous serial - data transmission the definition of a break condition is implementation - defined.

-

If IGNBRK is set, a break condition - detected on input is ignored, that is, not put on the input queue and - therefore not read by any process. If IGNBRK is not - set and BRKINT is set, the break condition flushes - the input and output queues and if the terminal is the controlling terminal - of a foreground process group, the break condition generates a single - SIGINT signal to that foreground process group. If - neither IGNBRK nor BRKINT is - set, a break condition is read as a single - ‘\0’, or if - PARMRK is set, as - ‘\377’, - ‘\0’, - ‘\0’.

-

If IGNPAR is set, a byte with a framing or - parity error (other than break) is ignored.

-

If PARMRK is set, and - IGNPAR is not set, a byte with a framing or parity - error (other than break) is given to the application as the three-character - sequence ‘\377’, - ‘\0’, X, where - ‘\377’, - ‘\0’ is a two-character flag preceding - each sequence and X is the data of the character received in error. To avoid - ambiguity in this case, if ISTRIP is not set, a - valid character of ‘\377’ is given to - the application as ‘\377’, - ‘\377’. If neither - PARMRK nor IGNPAR is set, a - framing or parity error (other than break) is given to the application as a - single character ‘\0’.

-

If INPCK is set, input parity checking is - enabled. If INPCK is not set, input parity checking - is disabled, allowing output parity generation without input parity errors. - Note that whether input parity checking is enabled or disabled is - independent of whether parity detection is enabled or disabled (see - Control Modes). If parity detection - is enabled but input parity checking is disabled, the hardware to which the - terminal is connected recognizes the parity bit, but the terminal special - file does not check whether this bit is set correctly or not.

-

If ISTRIP is set, valid input bytes are - first stripped to seven bits, otherwise all eight bits are processed.

-

If INLCR is set, a received - NL character is translated into a - CR character. If IGNCR is - set, a received CR character is ignored (not read). - If IGNCR is not set and - ICRNL is set, a received CR - character is translated into a NL character.

-

If IXON is set, start/stop output control - is enabled. A received STOP character suspends - output and a received START character restarts - output. If IXANY is also set, then any character may - restart output. When IXON is set, - START and STOP characters - are not read, but merely perform flow control functions. When - IXON is not set, the START - and STOP characters are read.

-

If IXOFF is set, start/stop input control - is enabled. The system shall transmit one or more - STOP characters, which are intended to cause the - terminal device to stop transmitting data, as needed to prevent the input - queue from overflowing and causing the undefined behavior described in - Input Processing and - Reading Data, and shall transmit one or more - START characters, which are intended to cause the - terminal device to resume transmitting data, as soon as the device can - continue transmitting data without risk of overflowing the input queue. The - precise conditions under which STOP and - START characters are transmitted are implementation - defined.

-

If IMAXBEL is set and the input queue is - full, subsequent input shall cause an ASCII BEL - character to be transmitted to the output queue.

-

The initial input control value after - () is - implementation defined.

-
-
-

-

Values of the c_oflag field describe the - basic terminal output control, and are composed of the following masks:

-

-
-
-
-
/* enable following output processing */
-
-
/* map NL to CR-NL (ala CRMOD) */
-
-
/* map CR to NL */
-
-
/* tab delay mask */
-
-
/* no tab delay and expansion */
-
-
/* expand tabs to spaces */
-
-
/* discard EOT's - ‘^D’ on output) */
-
-
/* do not transmit CRs on column 0 */
-
-
/* on the terminal NL performs the CR function */
-
-
-

If OPOST is set, the remaining flag masks - are interpreted as follows; otherwise characters are transmitted without - change.

-

If ONLCR is set, newlines are translated - to carriage return, linefeeds.

-

If OCRNL is set, carriage returns are - translated to newlines.

-

The TABDLY bits specify the tab delay. The - c_oflag is masked with TABDLY - and compared with the values TAB0 or - TAB3. If TAB3 is set, tabs - are expanded to the appropriate number of spaces (assuming 8 column tab - stops).

-

If ONOEOT is set, ASCII - EOT's are discarded on output.

-

If ONOCR is set, no CR character is - transmitted when at column 0 (first position).

-

If ONLRET is set, the NL character is - assumed to do the carriage-return function; the column pointer will be set - to 0.

-
-
-

-

Values of the c_cflag field describe the - basic terminal hardware control, and are composed of the following masks. - Not all values specified are supported by all hardware.

-

-
-
-
-
/* character size mask */
-
-
/* 5 bits (pseudo) */
-
-
/* 6 bits */
-
-
/* 7 bits */
-
-
/* 8 bits */
-
-
/* send 2 stop bits */
-
-
/* enable receiver */
-
-
/* parity enable */
-
-
/* odd parity, else even */
-
-
/* hang up on last close */
-
-
/* ignore modem status lines */
-
-
/* CTS flow control of output */
-
-
/* same as CCTS_OFLOW */
-
-
/* RTS flow control of input */
-
-
/* flow control output via Carrier */
-
-
/* Do not assert RTS or DTR automatically */
-
-
-

The CSIZE bits specify the byte size in - bits for both transmission and reception. The c_cflag - is masked with CSIZE and compared with the values - CS5, CS6, - CS7, or CS8. This size does - not include the parity bit, if any. If CSTOPB is - set, two stop bits are used, otherwise one stop bit. For example, at 110 - baud, two stop bits are normally used.

-

If CREAD is set, the receiver is enabled. - Otherwise, no character is received. Not all hardware supports this bit. In - fact, this flag is pretty silly and if it were not part of the - termios specification it would be omitted.

-

If PARENB is set, parity generation and - detection are enabled and a parity bit is added to each character. If parity - is enabled, PARODD specifies odd parity if set, - otherwise even parity is used.

-

If HUPCL is set, the modem control lines - for the port are lowered when the last process with the port open closes the - port or the process terminates. The modem connection is broken.

-

If CLOCAL is set, a connection does not - depend on the state of the modem status lines. If - CLOCAL is clear, the modem status lines are - monitored.

-

Under normal circumstances, a call to the - () - function waits for the modem connection to complete. However, if the - O_NONBLOCK flag is set or if - CLOCAL has been set, the - open() function returns immediately without waiting - for the connection.

-

The CCTS_OFLOW - (CRTSCTS) flag is currently unused.

-

If MDMBUF is set then output flow control - is controlled by the state of Carrier Detect.

-

If CNO_RTSDTR is set then the RTS and DTR - lines will not be asserted when the device is opened. As a result, this flag - is only useful on initial-state devices.

-

If the object for which the control modes are set is not an - asynchronous serial connection, some of the modes may be ignored; for - example, if an attempt is made to set the baud rate on a network connection - to a terminal on another host, the baud rate may or may not be set on the - connection between that terminal and the machine it is directly connected - to.

-
-
-

-

Values of the c_lflag field describe the - control of various functions, and are composed of the following masks.

-

-
-
-
-
/* visual erase for line kill */
-
-
/* visually erase chars */
-
-
/* enable echoing */
-
-
/* echo NL even if ECHO is - off */
-
-
/* visual erase mode for hardcopy */
-
-
/* echo control chars as ^(Char) */
-
-
/* enable signals INTR, - QUIT, [D]SUSP */
-
-
/* canonicalize input lines */
-
-
/* use alternate WERASE algorithm */
-
-
/* enable DISCARD and - LNEXT */
-
-
/* external processing */
-
-
/* stop background jobs from output */
-
-
/* output being flushed (state) */
-
-
/* no kernel output from VSTATUS */
-
-
/* XXX retype pending input (state) */
-
-
/* don't flush after interrupt */
-
-
-

If ECHO is set, input characters are - echoed back to the terminal. If ECHO is not set, - input characters are not echoed.

-

If ECHOE and - ICANON are set, the ERASE - character causes the terminal to erase the last character in the current - line from the display, if possible. If there is no character to erase, an - implementation may echo an indication that this was the case or do - nothing.

-

If ECHOK and - ICANON are set, the KILL - character causes the current line to be discarded and the system echoes the - ‘\n’ character after the - KILL character.

-

If ECHOKE and - ICANON are set, the KILL - character causes the current line to be discarded and the system causes the - terminal to erase the line from the display.

-

If ECHOPRT and - ICANON are set, the system assumes that the display - is a printing device and prints a backslash and the erased characters when - processing ERASE characters, followed by a forward - slash.

-

If ECHOCTL is set, the system echoes - control characters in a visible fashion using a caret followed by the - control character.

-

If ALTWERASE is set, the system uses an - alternative algorithm for determining what constitutes a word when - processing WERASE characters (see - WERASE).

-

If ECHONL and - ICANON are set, the - ‘\n’ character echoes even if - ECHO is not set.

-

If ICANON is set, canonical processing is - enabled. This enables the erase and kill edit functions, and the assembly of - input characters into lines delimited by NL, - EOF, and EOL, as described - in Canonical Mode - Input Processing.

-

If ICANON is not set, read requests are - satisfied directly from the input queue. A read is not satisfied until at - least MIN bytes have been received or the timeout - value TIME expired between bytes. The time value - represents tenths of seconds. See - Noncanonical Mode - Input Processing for more details.

-

If ISIG is set, each input character is - checked against the special control characters INTR, - QUIT, and SUSP (job control - only). If an input character matches one of these control characters, the - function associated with that character is performed. If - ISIG is not set, no checking is done. Thus these - special input functions are possible only if ISIG is - set.

-

If IEXTEN is set, implementation-defined - functions are recognized from the input data. How - IEXTEN being set interacts with - ICANON, ISIG, - IXON, or IXOFF is - implementation defined. If IEXTEN is not set, then - implementation-defined functions are not recognized, and the corresponding - input characters are not processed as described for - ICANON, ISIG, - IXON, and IXOFF.

-

If NOFLSH is set, the normal flush of the - input and output queues associated with the INTR, - QUIT, and SUSP characters - are not be done.

-

If TOSTOP is set, the signal - SIGTTOU is sent to the process group of a process - that tries to write to its controlling terminal if it is not in the - foreground process group for that terminal. This signal, by default, stops - the members of the process group. Otherwise, the output generated by that - process is output to the current output stream. Processes that are blocking - or ignoring SIGTTOU signals are excepted and allowed - to produce output and the SIGTTOU signal is not - sent.

-

If NOKERNINFO is set, the kernel does not - produce a status message when processing STATUS - characters (see STATUS).

-
-
-

-

The special control characters values are defined by the array - c_cc. This table lists the array index, the - corresponding special character, and the system default value. For an - accurate list of the system defaults, consult the header file - <sys/ttydefaults.h>.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Special CharacterDefault Value
EOF^D
EOL_POSIX_VDISABLE
EOL2_POSIX_VDISABLE
ERASE^? ‘\177’
WERASE^W
KILL^U
REPRINT^R
INTR^C
QUIT^\\ ‘\34’
SUSP^Z
DSUSP^Y
START^Q
STOP^S
LNEXT^V
DISCARD^O
---1
---0
STATUS^T
-

If the value of one of the changeable special control characters - (see Special Characters) is - {_POSIX_VDISABLE}, that function is disabled; that - is, no input data is recognized as the disabled special character. If - ICANON is not set, the value of - {_POSIX_VDISABLE} has no special meaning for the - VMIN and VTIME entries of - the c_cc array.

-

The initial values of the flags and control characters - after () - is set according to the values in the header - <sys/ttydefaults.h>.

-
-
-
-

-

stty(1), tcgetsid(3), - tcgetwinsize(3), tcsendbreak(3), - tcsetattr(3), tcsetsid(3), - tty(4), uart(4), - stack(9)

-
-
-

-

Before the Internet, serial ports were primarily used for inbound - connections from terminals, either directly or through modems, these days - serial ports are primarily used for outbound connections to devices, an - evolution which unfortunately has spread the relevant documentation over - three different manual pages: termios(4), - uart(4) and tty(4).

-

-
-
- - - - - -
January 14, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/textdump.4 3.html b/static/freebsd/man4/textdump.4 3.html deleted file mode 100644 index 58a452ad..00000000 --- a/static/freebsd/man4/textdump.4 3.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - -
TEXTDUMP(4)Device Drivers ManualTEXTDUMP(4)
-
-
-

-

textdump — - textdump kernel dumping facility

-
-
-

-

options DDB -
- options KDB

-

-
- options TEXTDUMP_PREFERRED -
- options TEXTDUMP_VERBOSE

-
-
-

-

The textdump facility allows the capture - of kernel debugging information to disk in a human-readable rather than the - machine-readable form normally used with kernel memory dumps and minidumps. - This representation, while less complete in that it does not capture full - kernel state, can provide debugging information in a more compact, portable, - and persistent form than a traditional dump. By combining - textdump with other ddb(4) - facilities, such as scripting and output capture, detailed bug information - can be captured in a fully automated manner.

-
-
-

-

textdump data is stored in a dump - partition in the same style as a regular memory dump, and will be - automatically extracted by savecore(8) if present on - boot.

-

textdump files are stored in the - tar(5) format, and consist of one or more text files, each - storing a particular type of debugging output. The following parts may be - present:

-
-
ddb.txt
-
Captured ddb(4) output, if the capture facility has been - used. May be disabled by clearing the - debug.ddb.textdump.do_ddb sysctl.
-
config.txt
-
Kernel configuration, if options - INCLUDE_CONFIG_FILE has been compiled into the kernel. May be - disabled by clearing the - debug.ddb.textdump.do_config sysctl.
-
msgbuf.txt
-
Kernel message buffer, including recent console output if the capture - facility has been used. May be disabled by clearing the - debug.ddb.textdump.do_msgbuf sysctl.
-
panic.txt
-
Kernel panic string, if the kernel panicked before the dump was generated. - May be disabled by clearing the - debug.ddb.textdump.do_panic sysctl.
-
version.txt
-
Kernel version string. My be disabled by clearing the - debug.ddb.textdump.do_version sysctl.
-
-

Kernel textdumps may be extracted using - tar(1).

-
-
-

-

The textdump facility is enabled as part - of the kernel debugger using options KDB and - options DDB. By default, kernel dumps generated on - panic or via explicit requests for a dump will be regular memory dumps; - however, by using the textdump set command in - ddb(4), or by setting the - debug.ddb.textdump.pending sysctl to 1 using - sysctl(8), it is possible to request that the next dump be - a textdump. One may also directly trigger a textdump in - ddb(4) by running the command textdump - dump.

-

If at the ddb(4) command line, the commands - textdump set, textdump - status, and textdump unset may be used to - set, query, and clear the textdump pending flag.

-

As with regular kernel dumps, a dump partition must be - automatically or manually configured using dumpon(8).

-

Additional kernel config(8) options:

-
-
TEXTDUMP_PREFERRED
-
sets textdumps to be the default manner of doing dumps. This means there - will be no need to sysctl(8) or use the - textdump set ddb(8) - commands.
-
TEXTDUMP_VERBOSE
-
will have the textdump facility be more verbose about each file it is - emitting as well as other diagnostics useful to debug the textdump - facility itself.
-
-
-
-

-

In the following example, the script - kdb.enter.panic will run when the kernel debugger is - entered as a result of a panic, enable output capture, dump several useful - pieces of debugging information, and then invoke panic in order to force a - kernel dump to be written out followed by a reboot:

-
-
script kdb.enter.panic=textdump set; capture on; show allpcpu; bt;
-  ps; alltrace; show alllocks; textdump dump; reset
-
-

In the following example, the script - kdb.enter.witness will run when the kernel debugger is - entered as a result of a witness violation, printing lock-related - information for the user:

-
-
script kdb.enter.witness=show locks
-
-

These scripts may also be configured using the - ddb(8) utility.

-
-
-

-

tar(1), ddb(4), - tar(5), ddb(8), - dumpon(8), savecore(8), - sysctl(8)

-
-
-

-

The textdump facility first appeared in - FreeBSD 7.1.

-
-
-

-

The textdump facility was created by - Robert N. M. Watson.

-
-
- - - - - -
October 18, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/thunderbolt.4 4.html b/static/freebsd/man4/thunderbolt.4 4.html deleted file mode 100644 index 9967a981..00000000 --- a/static/freebsd/man4/thunderbolt.4 4.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - -
THUNDERBOLT(4)Device Drivers ManualTHUNDERBOLT(4)
-
-
-

-

thunderbolt — USB4 - controller driver

-
-
-

-

device thunderbolt

-
-
-

-

The thunderbolt driver supports - Thunderbolt 3 and USB4 controllers.

-
-
-

-

The thunderbolt driver appeared in - FreeBSD 15.0.

-
-
- - - - - -
October 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ti.4 3.html b/static/freebsd/man4/ti.4 3.html deleted file mode 100644 index 59ec6a4d..00000000 --- a/static/freebsd/man4/ti.4 3.html +++ /dev/null @@ -1,317 +0,0 @@ - - - - - - -
TI(4)Device Drivers ManualTI(4)
-
-
-

-

ti — Alteon - Networks Tigon I and Tigon II Gigabit Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ti -
-options TI_SF_BUF_JUMBO -
-options TI_JUMBO_HDRSPLIT
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ti_load="YES"
-
-
-
-

-

The ti driver provides support for PCI - Gigabit Ethernet adapters based on the Alteon Networks Tigon Gigabit - Ethernet controller chip. The Tigon contains an embedded R4000 CPU, gigabit - MAC, dual DMA channels and a PCI interface unit. The Tigon II contains two - R4000 CPUs and other refinements. Either chip can be used in either a 32-bit - or 64-bit PCI slot. Communication with the chip is achieved via PCI shared - memory and bus master DMA. The Tigon I and II support hardware multicast - address filtering, VLAN tag extraction and insertion, and jumbo Ethernet - frames sizes up to 9000 bytes. Note that the Tigon I chipset is no longer in - active production: all new adapters should come equipped with Tigon II - chipsets.

-

While the Tigon chipset supports 10, 100 and 1000Mbps speeds, - support for 10 and 100Mbps speeds is only available on boards with the - proper transceivers. Most adapters are only designed to work at 1000Mbps, - however the driver should support those NICs that work at lower speeds as - well.

-

Support for jumbo frames is provided via the interface MTU - setting. Selecting an MTU larger than 1500 bytes with the - ifconfig(8) utility configures the adapter to receive and - transmit jumbo frames. Using jumbo frames can greatly improve performance - for certain tasks, such as file transfers and data streaming.

-

Header splitting support for Tigon 2 boards (this option has no - effect for the Tigon 1) can be turned on with the - TI_JUMBO_HDRSPLIT option. See - zero_copy(9) for more discussion on zero copy receive and - header splitting.

-

The ti driver uses UMA backed jumbo - receive buffers, but can be configured to use sendfile(2) - buffer allocator. To turn on sendfile(2) buffer allocator, - use the TI_SF_BUF_JUMBO option.

-

Support for vlans is also available using the - vlan(4) mechanism. See the vlan(4) man - page for more details.

-

The ti driver supports the following media - types:

-
-
autoselect
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file.
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to select either full-duplex - or half-duplex modes.
-
1000baseSX
-
Set 1000Mbps (Gigabit Ethernet) operation. Only - full-duplex mode is supported at this speed.
-
-

The ti driver supports the following media - options:

-
-
full-duplex
-
Force full-duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ti driver supports Gigabit Ethernet - adapters based on the Alteon Tigon I and II chips. The - ti driver has been tested with the following - adapters:

-

-
    -
  • 3Com 3c985-SX Gigabit Ethernet adapter (Tigon 1)
    • -
  • 3Com 3c985B-SX Gigabit Ethernet adapter (Tigon 2)
    • -
  • Alteon AceNIC V Gigabit Ethernet adapter (1000baseSX)
    • -
  • Alteon AceNIC V Gigabit Ethernet adapter (1000baseT)
    • -
  • Digital EtherWORKS 1000SX PCI Gigabit adapter
    • -
  • Netgear GA620 Gigabit Ethernet adapter (1000baseSX)
    • -
  • Netgear GA620T Gigabit Ethernet adapter (1000baseT)
    • -
-

The following adapters should also be supported but have not yet - been tested:

-

-
    -
  • Asante GigaNIX1000T Gigabit Ethernet adapter
    • -
  • Asante PCI 1000BASE-SX Gigabit Ethernet adapter
    • -
  • Farallon PN9000SX Gigabit Ethernet adapter
    • -
  • NEC Gigabit Ethernet
    • -
  • Silicon Graphics PCI Gigabit Ethernet adapter
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.ti.%d.dac
-
If this tunable is set to 0 it will disable DAC (Dual Address Cycle). The - default value is 1 which means driver will use full 64bit DMA - addressing.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables. The interface has to be brought down and up again before a change - takes effect when any of the following tunables are changed. The one - microsecond clock tick referenced below is a nominal time and the actual - hardware may not provide granularity to this level. For example, on Tigon 2 - (revision 6) cards with release 12.0 the clock granularity is 5 - microseconds.

-
-
dev.ti.%d.rx_coal_ticks
-
This value, receive coalesced ticks, controls the number of clock ticks - (of 1 microseconds each) that must elapse before the NIC DMAs the receive - return producer pointer to the Host and generates an interrupt. This - parameter works in conjunction with the rx_max_coal_bds, receive max - coalesced BDs, tunable parameter. The NIC will return the receive return - producer pointer to the Host when either of the thresholds is exceeded. A - value of 0 means that this parameter is ignored and receive BDs will only - be returned when the receive max coalesced BDs value is reached. The - default value is 170.
-
dev.ti.%d.rx_max_coal_bds
-
This value, receive max coalesced BDs, controls the number of receive - buffer descriptors that will be coalesced before the NIC updates the - receive return ring producer index. If this value is set to 0 it will - disable receive buffer descriptor coalescing. The default value is - 64.
-
dev.ti.%d.ti_tx_coal_ticks
-
This value, send coalesced ticks, controls the number of clock ticks (of 1 - microseconds each) that must elapse before the NIC DMAs the send consumer - pointer to the Host and generates an interrupt. This parameter works in - conjunction with the tx_max_coal_bds, send max coalesced BDs, tunable - parameter. The NIC will return the send consumer pointer to the Host when - either of the thresholds is exceeded. A value of 0 means that this - parameter is ignored and send BDs will only be returned when the send max - coalesced BDs value is reached. The default value is 2000.
-
dev.ti.%d.tx_max_coal_bds
-
This value, send max coalesced BDs, controls the number of send buffer - descriptors that will be coalesced before the NIC updates the send - consumer index. If this value is set to 0 it will disable send buffer - descriptor coalescing. The default value is 32.
-
dev.ti.%d.tx_buf_ratio
-
This value controls the ratio of the remaining memory in the NIC that - should be devoted to transmit buffer vs. receive buffer. The lower 7 bits - are used to indicate the ratio in 1/64th increments. For example, setting - this value to 16 will set the transmit buffer to 1/4 of the remaining - buffer space. In no cases will the transmit or receive buffer be reduced - below 68 KB. For a 1 MB NIC the approximate total space for data buffers - is 800 KB. For a 512 KB NIC that number is 300 KB. The default value is - 21.
-
dev.ti.%d.stat_ticks
-
The value, stat ticks, controls the number of clock ticks (of 1 - microseconds each) that must elapse before the NIC DMAs the statistics - block to the Host and generates a STATS_UPDATED event. If set to zero then - statistics are never DMAed to the Host. It is recommended that this value - be set to a high enough frequency to not mislead someone reading - statistics refreshes. Several times a second is enough. The default value - is 2000000 (2 seconds).
-
-
-
-

-

In addition to the standard socket(2) - ioctl(2) calls implemented by most network drivers, the - ti driver also includes a character device interface - that can be used for additional diagnostics, configuration and debugging. - With this character device interface, and a specially patched version of - gdb(1) (ports/devel/gdb), the user - can debug firmware running on the Tigon board.

-

These ioctls and their arguments are defined in the - <sys/tiio.h> header - file.

-
-
-
Return card statistics DMAed from the card into kernel memory - approximately every 2 seconds. (That time interval can be changed via the - TIIOCSETPARAMS ioctl.) The argument is - struct ti_stats.
-
-
Get various performance-related firmware parameters that largely affect - how interrupts are coalesced. The argument is struct - ti_params.
-
-
Set various performance-related firmware parameters that largely affect - how interrupts are coalesced. The argument is struct - ti_params.
-
-
Tell the NIC to trace the requested types of information. The argument is - ti_trace_type.
-
-
Dump the trace buffer from the card. The argument is - struct ti_trace_buf.
-
-
This ioctl is used for compatibility with Alteon's Solaris driver. They - apparently only have one character interface for debugging, so they have - to tell it which Tigon instance they want to debug. This ioctl is a noop - for FreeBSD.
-
-
Read the requested memory region from the Tigon board. The argument is - struct tg_mem.
-
-
Write to the requested memory region on the Tigon board. The argument is - struct tg_mem.
-
-
Read the requested register from the Tigon board. The argument is - struct tg_reg.
-
-
Write to the requested register on the Tigon board. The argument is - struct tg_reg.
-
-
-
-

-
-
/dev/ti[0-255]
-
Tigon driver character interface.
-
-
-
-

-
-
ti%d: couldn't map memory
-
A fatal initialization error has occurred.
-
ti%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
ti%d: no memory for softc struct!
-
The driver failed to allocate memory for per-device instance information - during initialization.
-
ti%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
ti%d: no memory for jumbo buffers!
-
The driver failed to allocate memory for jumbo frames during - initialization.
-
ti%d: bios thinks we're in a 64 bit slot, but we aren't
-
The BIOS has programmed the NIC as though it had been installed in a - 64-bit PCI slot, but in fact the NIC is in a 32-bit slot. This happens as - a result of a bug in some BIOSes. This can be worked around on the Tigon - II, but on the Tigon I initialization will fail.
-
ti%d: board self-diagnostics failed!
-
The ROMFAIL bit in the CPU state register was set after system startup, - indicating that the on-board NIC diagnostics failed.
-
ti%d: unknown hwrev
-
The driver detected a board with an unsupported hardware revision. The - ti driver supports revision 4 (Tigon 1) and - revision 6 (Tigon 2) chips and has firmware only for those devices.
-
ti%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

sendfile(2), altq(4), - arp(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8), zero_copy(9)

-
-
-

-

The ti device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The ti driver was written by - Bill Paul - <wpaul@bsdi.com>. The - header splitting firmware modifications, character - ioctl(2) interface and debugging support were written by - Kenneth Merry - <ken@FreeBSD.org>. - Initial zero copy support was written by Andrew - Gallatin - <gallatin@FreeBSD.org>.

-
-
- - - - - -
November 14, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/timecounters.4 3.html b/static/freebsd/man4/timecounters.4 3.html deleted file mode 100644 index 66eedb55..00000000 --- a/static/freebsd/man4/timecounters.4 3.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - -
TIMECOUNTERS(4)Device Drivers ManualTIMECOUNTERS(4)
-
-
-

-

timecounters — - kernel time counters subsystem

-
-
-

-

The kernel uses several types of time-related devices, such as: - real time clocks, time counters and event timers. Real time clocks are - responsible for tracking real world time, mostly when the system is down. - Time counters are responsible for tracking purposes, when the system is - running. Event timers are responsible for generating interrupts at a - specified time or periodically, to run different time-based events. This - page is about the second.

-
-
-

-

Time counters are the lowest level of time tracking in the kernel. - They provide monotonically increasing timestamps with known width and update - frequency. They can overflow, drift, etc and so in raw form can be used only - in very limited performance-critical places like the process scheduler.

-

More usable time is created by scaling the values - read from the selected time counter and combining it with some offset, - regularly updated by - () - on - () - invocation.

-

Different platforms provide different kinds of timer hardware. The - goal of the time counters subsystem is to provide a unified way to access - that hardware.

-

Each driver implementing time counters registers them with the - subsystem. It is possible to see the list of present time counters, via the - kern.timecounter sysctl(8) - variable:

-
-
kern.timecounter.choice: TSC-low(-100) HPET(950) i8254(0) ACPI-fast(900) dummy(-1000000)
-kern.timecounter.tc.ACPI-fast.mask: 16777215
-kern.timecounter.tc.ACPI-fast.counter: 13467909
-kern.timecounter.tc.ACPI-fast.frequency: 3579545
-kern.timecounter.tc.ACPI-fast.quality: 900
-kern.timecounter.tc.i8254.mask: 65535
-kern.timecounter.tc.i8254.counter: 62692
-kern.timecounter.tc.i8254.frequency: 1193182
-kern.timecounter.tc.i8254.quality: 0
-kern.timecounter.tc.HPET.mask: 4294967295
-kern.timecounter.tc.HPET.counter: 3013495652
-kern.timecounter.tc.HPET.frequency: 14318180
-kern.timecounter.tc.HPET.quality: 950
-kern.timecounter.tc.TSC-low.mask: 4294967295
-kern.timecounter.tc.TSC-low.counter: 4067509463
-kern.timecounter.tc.TSC-low.frequency: 11458556
-kern.timecounter.tc.TSC-low.quality: -100
-
-

The output nodes are defined as follows:

-
-
kern.timecounter.tc.X.mask
-
is a bitmask, defining valid counter bits,
-
kern.timecounter.tc.X.counter
-
is a present counter value,
-
kern.timecounter.tc.X.frequency
-
is a counter update frequency,
-
kern.timecounter.tc.X.quality
-
is an integral value, defining the quality of this time counter compared - to others. A negative value means this time counter is broken and should - not be used.
-
-

The time management code of the kernel automatically switches to a - higher-quality time counter when it registers, unless the - kern.timecounter.hardware sysctl has been used to - choose a specific device.

-

There is no way to unregister a time counter once it has - registered with the kernel. If a dynamically loaded module contains a time - counter you will not be able to unload that module, even if the time counter - it contains is not the one currently in use.

-
-
-

-

attimer(4), eventtimers(4), - ffclock(4), hpet(4)

-
-
- - - - - -
August 12, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/tmpfs.4 3.html b/static/freebsd/man4/tmpfs.4 3.html deleted file mode 100644 index dbb7fc9d..00000000 --- a/static/freebsd/man4/tmpfs.4 3.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - -
TMPFS(4)Device Drivers ManualTMPFS(4)
-
-
-

-

tmpfs — in-memory - file system

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
options TMPFS
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
tmpfs_load="YES"
-
-
-
-

-

The tmpfs driver implements an in-memory, - or tmpfs file system. The filesystem stores both - file metadata and data in main memory. This allows very fast and low latency - accesses to the data. The data is volatile. An umount or system reboot - invalidates it. These properties make the filesystem's mounts suitable for - fast scratch storage, like /tmp.

-

If the system becomes low on memory and swap is configured (see - swapon(8)), the system can transfer file data to swap - space, freeing memory for other needs. Metadata, including the directory - content, is never swapped out by the current implementation. Keep this in - mind when planning the mount limits, especially when expecting to place many - small files on a tmpfs mount.

-

When mmap(2) is used on a file from a tmpfs - mount, the swap VM object managing the file pages is used to implement - mapping and avoid double-copying of the file data. This quirk causes process - inspection tools, like procstat(1), to report anonymous - memory mappings instead of file mappings.

-
-
-

-

The following options are available when mounting - tmpfs file systems:

-
-
-
Set the maximum memory size used by extended attributes in bytes. The - default is 16 megabytes.
-
-
Accept the export option for compatibility with - nfsv4(4). This option does nothing.
-
-
Set the group ID of the root inode of the file system. The default is the - mount point's GID.
-
-
Set the maximum number of nodes available to the file system. If not - specified, the file system chooses a reasonable maximum based on the file - system size, which can be limited with the size - option.
-
-
Set the maximum file size in bytes. The default is the maximum possible - value.
-
-
Set the mode (in octal notation) of the root inode of the file system. The - default is the mount point's mode.
-
-
Disable the tracking of mtime updates caused by writes to the shared - mapped areas backed by tmpfs files. This option - removes periodic scans, which downgrade read-write-mapped pages to - read-only to note the writes.
-
-
Do not use namecache to resolve names to files for the created mount. This - saves memory, but currently might impair scalability for highly used - mounts on large machines.
-
-
Do not follow symlink(7)'s on the mounted file - system.
-
-
Enable pgcache read for the mount.
-
-
Set the total file system size in bytes, unless suffixed with one of k, m, - g, t, or p, which denote byte, kilobyte, megabyte, gigabyte, terabyte and - petabyte respectively. If zero (the default) or a value larger than - SIZE_MAX - PAGE_SIZE is given, the available amount of memory (including - main memory and swap space) will be used.
-
-
Set the user ID of the root inode of the file system. The default is the - mount point's UID.
-
-
Refer to mount(8).
-
-
-
-

-

The following sysctl(8) variables are - available:

-
-
vfs.tmpfs.memory_percent
-
The percentage of memory plus swap space available at kernel file system - initialization that can be used by a file system with a size of 0. When - this amount of space in use is reached, new files cannot be created and - files cannot be extended. The default is 95%. Changing this value also - changes vfs.tmpfs.memory_reserved.
-
vfs.tmpfs.memory_reserved
-
The currently-reserved amount of memory plus swap space based on the - memory percentage. The minimum is compiled into the system, and defaults - to 4 MB.
-
-
-
-

-

Mount a tmpfs memory file system:

-

-
mount -t tmpfs tmpfs - /tmp
-

Configure a tmpfs mount via - fstab(5):

-
-
tmpfs /tmp tmpfs rw 0 0
-
-
-
-

-

procstat(1), mmap(2), - nmount(2), unmount(2), - fstab(5), mdmfs(8), - mount(8), swapinfo(8), - swapon(8)

-
-
-

-

The tmpfs driver first appeared in - FreeBSD 7.0.

-
-
-

-

The tmpfs kernel implementation was - written by Julio M. Merino Vidal - <jmmv@NetBSD.org> as a - Google Summer of Code project.

-

Rohit Jalan and others ported it from - NetBSD to FreeBSD.

-

This manual page was written by Xin LI - <delphij@FreeBSD.org>.

-
-
- - - - - -
September 18, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/tpm.4 4.html b/static/freebsd/man4/tpm.4 4.html deleted file mode 100644 index 0b6549bd..00000000 --- a/static/freebsd/man4/tpm.4 4.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
TPM(4)Device Drivers ManualTPM(4)
-
-
-

-

tpm — Trusted - Platform Module

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device tpm
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
tpm_load="YES"
-
-

In /boot/device.hints: -
- hint.tpm.0.at="isa" -
- hint.tpm.0.maddr="0xfed40000" -
- hint.tpm.0.msize="0x5000" -
- hint.tpm.1.at="isa" -
- hint.tpm.1.maddr="0xfed40000" -
- hint.tpm.1.msize="0x1000"

-
-
-

-

The tpm driver provides support for - various trusted platform modules (TPM) that can store cryptographic - keys.

-

Supported modules:

-

-
    -
  • Atmel 97SC3203
    • -
  • Broadcom BCM0102
    • -
  • Infineon IFX SLD 9630 TT 1.1 and IFX SLB 9635 TT 1.2
    • -
  • Intel INTC0102
    • -
  • Sinosun SNS SSX35
    • -
  • STM ST19WP18
    • -
  • Winbond WEC WPCT200
    • -
-

The driver can be configured to use an IRQ by providing a free ISA - interrupt vector in /boot/device.hints.

-
-
-

-

intro(4), device.hints(5), - config(8)

-

The homepage of the BSSSD project, which developed the original - tpm driver: - http://bsssd.sourceforge.net/.

-

TPM main specification can be found at: - https://trustedcomputinggroup.org/resource/tpm-main-specification/.

-
-
-

-

TPM Main Specification Level 2 Version 1.2:

- -
-
-

-

The tpm driver first appeared in - FreeBSD 8.2 and was later added to - OpenBSD 6.1.

-
-
-

-

The tpm driver was written by - Michael Shalayeff and Hans-Joerg - Hoexer.

-
-
- - - - - -
October 31, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/tslog.4 3.html b/static/freebsd/man4/tslog.4 3.html deleted file mode 100644 index 71931c3b..00000000 --- a/static/freebsd/man4/tslog.4 3.html +++ /dev/null @@ -1,116 +0,0 @@ - - - - - - -
TSLOG(4)Device Drivers ManualTSLOG(4)
-
-
-

-

tslog — Boot-time - event tracing facility

-
-
-

-

To compile this boot-time event tracing facility into the kernel, - place the following line in the kernel configuration file:

-
option TSLOG
-
-
-

-

tslog is a boot-time event tracing - facility. It is suitable for tracing recursive events based on function - entries and exits. Its purpose is to ease pinpointing and reducing the - overall FreeBSD boot time by generating detailed - timing information.

-

tslog is able to trace the boot loader, - kernel initialization, and userland processes.

-

In userland, it records the following details for each process - ID:

-
    -
  • The timestamp of the fork(2) which creates the given - process ID and the parent process ID.
    • -
  • The path passed to execve(2), if any.
    • -
  • The first path resolved by namei(9), if any.
    • -
  • The timestamp of the exit(3) which terminates the - process.
    • -
-
-
-

-

The following sysctl(8) variables are - available:

-
-
debug.tslog
-
Dump the tslog buffer of recorded loader and - kernel event timestamps.
-
debug.tslog_user
-
Dump the tslog buffer of recorded userland event - timestamps.
-
-
-
-

-

The tslog buffer dumps can be used to - generate flamegraphs of the FreeBSD boot process for - visual analysis. See - https://github.com/cperciva/freebsd-boot-profiling - for more information.

-
-
-

-

dtrace(1), boottrace(4), - ktr(4)

-
-
-

-

tslog first appeared in - FreeBSD 12.0. Support for tracing boot loaders and - userland process was added in FreeBSD 13.2.

-
-

-

tslog is oriented towards system - developers while boottrace(4) is meant to be easy to use - by system administrators. Both facilities provide an overview of timing and - resource usage of the boot process.

-
-
-

-

dtrace(1) is not always the right tool for - profiling early kernel initialization. The reason is it requires some kernel - subroutines which are not yet available early in the boot process, e.g.: - traps, memory allocation, or thread scheduling. - tslog depends on fewer kernel subroutines than - dtrace(1) and because of that can trace early kernel - initialization.

-
-
-

-

ktr(4) has a couple of limitations which prevent - it from being able to run at the start of the boot process. In contrast, - tslog is designed for logging timestamped events for - boot profiling.

-
-
-
-

-

tslog was written by - Colin Percival - <cperciva@FreeBSD.org>.

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
June 1, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/tty.4 3.html b/static/freebsd/man4/tty.4 3.html deleted file mode 100644 index 0145d281..00000000 --- a/static/freebsd/man4/tty.4 3.html +++ /dev/null @@ -1,337 +0,0 @@ - - - - - - -
TTY(4)Device Drivers ManualTTY(4)
-
-
-

-

tty — general - terminal interface

-
-
-

-

#include - <sys/ioctl.h>

-
-
-

-

This section describes the interface to the terminal drivers in - the system.

-
-

-

Each hardware terminal port on the system has several terminal - special device files associated with it in the directory ``/dev/'' (for - example, ``/dev/tty03'' and ``/dev/cua03''). When a user logs into the - system on one of these hardware terminal ports, the system has already - opened the associated device and prepared the line for normal interactive - use (see getty(8).) There is also a special case of a - terminal file that connects not to a hardware terminal port, but to another - program on the other side. These special terminal devices are called - and - provide the mechanism necessary to give users the same interface to the - system when logging in over a network (using telnet(1) for - example). Even in these cases the details of how the terminal file was - opened and set up is already handled by special software in the system. - Thus, users do not normally need to worry about the details of how these - lines are opened or used. Also, these lines are often used for dialing out - of a system (through an out-calling modem), but again the system provides - programs that hide the details of accessing these terminal special files - (see tip(1)).

-

When an interactive user logs in, the system prepares - the line to behave in a certain way (called a - ), - the particular details of which is described in stty(1) at - the command level, and in termios(4) at the programming - level. A user may be concerned with changing settings associated with his - particular login terminal and should refer to the preceding man pages for - the common cases. The remainder of this man page is concerned with - describing details of using and controlling terminal devices at a low level, - such as that possibly required by a program wishing to provide features - similar to those provided by the system.

-
-
-

-

All of the following operations are invoked using the - ioctl(2) system call. Refer to that man page for a - description of the - - and argp parameters. In addition to the ioctl - requests defined here, the specific line discipline in - effect will define other requests specific to it (actually - termios(4) defines them as function calls, not ioctl - requests.) The following section lists the available ioctl - requests. The name of the request, a description of its purpose, and the - typed argp parameter (if any) are listed. For example, the - first entry says

-

-
TIOCSPGRP int *tpgrp
-

and would be called on the terminal associated with file - descriptor zero by the following code fragment:

-
-
	int pgrp;
-
-	pgrp = getpgrp();
-	ioctl(0, TIOCSPGRP, &pgrp);
-
-
-
-

-
-
- int *ldisc
-
This call is obsolete but left for compatibility. Before - FreeBSD 8.0, it would change to the new line - discipline pointed to by ldisc.
-
- int *ldisc
-
Return the current line discipline in the integer pointed to by - ldisc.
-
- void
-
Set the terminal hardware into BREAK condition.
-
- void
-
Clear the terminal hardware BREAK condition.
-
- void
-
Assert data terminal ready (DTR).
-
- void
-
Clear data terminal ready (DTR).
-
- int *tpgrp
-
Return the current process group with which the terminal is associated in - the integer pointed to by tpgrp. This is the - underlying call that implements the termios(4) - () - call.
-
- int *tpgrp
-
Associate the terminal with the process group (as an integer) pointed to - by tpgrp. This is the underlying call that - implements the termios(4) - () - call.
-
- struct termios *term
-
Place the current value of the termios state associated with the device in - the termios structure pointed to by term. This is - the underlying call that implements the termios(4) - tcgetattr() call.
-
- struct termios *term
-
Set the termios state associated with the device immediately. This is the - underlying call that implements the termios(4) - tcsetattr() call with the - TCSANOW option.
-
- struct termios *term
-
First wait for any output to complete, then set the termios state - associated with the device. This is the underlying call that implements - the termios(4) tcsetattr() call - with the TCSADRAIN option.
-
- struct termios *term
-
First wait for any output to complete, clear any pending input, then set - the termios state associated with the device. This is the underlying call - that implements the termios(4) - tcsetattr() call with the - TCSAFLUSH option.
-
- int *num
-
Place the current number of characters in the output queue in the integer - pointed to by num.
-
- char *cp
-
Simulate typed input. Pretend as if the terminal received the character - pointed to by cp.
-
- void
-
In the past, when a process that did not have a controlling terminal (see - in termios(4)) first opened a terminal - device, it acquired that terminal as its controlling terminal. For some - programs this was a hazard as they did not want a controlling terminal in - the first place, and this provides a mechanism to disassociate the - controlling terminal from the calling process. It - be - called by opening the file /dev/tty and calling - TIOCNOTTY on that file descriptor. -

The current system does not allocate a controlling - terminal to a process on an - () - call: there is a specific ioctl called TIOCSCTTY - to make a terminal the controlling terminal. In addition, a program can - fork() and call the - setsid() system call which will place the - process into its own session - which has the effect of disassociating it - from the controlling terminal. This is the new and preferred method for - programs to lose their controlling terminal.

-

However, environmental restrictions may prohibit the - process from being able to - () and - call the - () - system call to disassociate it from the controlling terminal. In this - case, it must use TIOCNOTTY.

-
-
- void
-
Stop output on the terminal (like typing ^S at the keyboard).
-
- void
-
Start output on the terminal (like typing ^Q at the keyboard).
-
- void
-
Make the terminal the controlling terminal for the process (the process - must not currently have a controlling terminal).
-
- void
-
Wait until all output is drained, or until the drain wait timeout - expires.
-
- int *timeout
-
Return the current drain wait timeout in seconds.
-
- int *timeout
-
Set the drain wait timeout in seconds. A value of zero disables timeouts. - The default drain wait timeout is controlled by the tunable - sysctl(8) OID - kern.tty_drainwait.
-
- void
-
Set exclusive use on the terminal. No further opens are permitted except - by root. Of course, this means that programs that are run by root (or - setuid) will not obey the exclusive setting - which limits the usefulness - of this feature.
-
- void
-
Clear exclusive use of the terminal. Further opens are permitted.
-
- int *what
-
If the value of the int pointed to by what contains - the FREAD bit as defined in - <sys/file.h>, then all - characters in the input queue are cleared. If it contains the - FWRITE bit, then all characters in the output - queue are cleared. If the value of the integer is zero, then it behaves as - if both the FREAD and - FWRITE bits were set (i.e., clears both - queues).
-
- struct winsize *ws
-
Put the window size information associated with the terminal in the - winsize structure pointed to by - ws. The window size structure contains the number of - rows and columns (and pixels if appropriate) of the devices attached to - the terminal. It is set by user software and is the means by which most - full-screen oriented programs determine the screen size. The - winsize structure is provided by - <sys/ioctl.h>.
-
- struct winsize *ws
-
Set the window size associated with the terminal to be the value in the - winsize structure pointed to by - ws (see above).
-
- int *on
-
If on points to a non-zero integer, redirect kernel - console output (kernel printf's) to this terminal. If - on points to a zero integer, redirect kernel console - output back to the normal console. This is usually used on workstations to - redirect kernel messages to a particular window.
-
- int *state
-
The integer pointed to by state contains bits that - correspond to modem state. Following is a list of defined variables and - the modem state they represent: -

-
-
TIOCM_LE
-
Line Enable.
-
TIOCM_DTR
-
Data Terminal Ready.
-
TIOCM_RTS
-
Request To Send.
-
TIOCM_ST
-
Secondary Transmit.
-
TIOCM_SR
-
Secondary Receive.
-
TIOCM_CTS
-
Clear To Send.
-
TIOCM_CAR
-
Carrier Detect.
-
TIOCM_CD
-
Carrier Detect (synonym).
-
TIOCM_RNG
-
Ring Indication.
-
TIOCM_RI
-
Ring Indication (synonym).
-
TIOCM_DSR
-
Data Set Ready.
-
-

This call sets the terminal modem state to that represented by - state. Not all terminals may support this.

-
-
- int *state
-
Return the current state of the terminal modem lines as represented above - in the integer pointed to by state.
-
- int *state
-
The bits in the integer pointed to by state - represent modem state as described above, however the state is OR-ed in - with the current state.
-
- int *state
-
The bits in the integer pointed to by state - represent modem state as described above, however each bit which is on in - state is cleared in the terminal.
-
-
-
-
-

-

The total number of input and output bytes through all terminal - devices are available via the kern.tty_nin and - kern.tty_nout read-only sysctl(8) - variables.

-
-
-

-

stty(1), ioctl(2), - ng_tty(4), pts(4), - pty(4), termios(4), - uart(4), getty(8)

-
-
-

-

A console typewriter device /dev/tty and - asynchronous communication interfaces /dev/tty[0-5] - first appeared in Version 1 AT&T - UNIX.

-
-
-

-

Before the Internet, serial ports were primarily used for inbound - connections from terminals, either directly or through modems, these days - serial ports are primarily used for outbound connections to devices, an - evolution which unfortunately has spread the relevant documentation over - three different manual pages: termios(4), - uart(4) and tty(4).

-
-
- - - - - -
April 3, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/tun.4 3.html b/static/freebsd/man4/tun.4 3.html deleted file mode 100644 index 3d05a7a4..00000000 --- a/static/freebsd/man4/tun.4 3.html +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - -
TUN(4)Device Drivers ManualTUN(4)
-
-
-

-

tun — tunnel - software network interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device tuntap
-

Alternatively, to load the driver as a module at boot time, place - the following lines in loader.conf(5):

-
-
if_tuntap_load="YES"
-
-
-
-

-

The tun interface is a software loopback - mechanism that can be loosely described as the network interface analog of - the pty(4), that is, tun does for - network interfaces what the pty(4) driver does for - terminals.

-

The tun driver, like the - pty(4) driver, provides two interfaces: an interface like - the usual facility it is simulating (a network interface in the case of - tun, or a terminal for pty(4)), - and a character-special device “control” interface. A client - program transfers IP (by default) packets to or from the - tun “control” interface. The - tap(4) interface provides similar functionality at the - Ethernet layer: a client will transfer Ethernet frames to or from a - tap(4) “control” interface.

-

The network interfaces are named - “tun0”, - “tun1”, etc., one for each control - device that has been opened. These network interfaces persist until the - if_tuntap.ko module is unloaded, or until removed - with the ifconfig(8) command.

-

tun devices are created using interface - cloning. This is done using the “ifconfig tunN - create” command. This is the preferred method - of creating tun devices. The same method allows - removal of interfaces. For this, use the “ifconfig - tunN destroy” command.

-

If the sysctl(8) variable - net.link.tun.devfs_cloning is non-zero, the - tun interface permits opens on the special control - device /dev/tun. When this device is opened, - tun will return a handle for the lowest unused - tun device (use devname(3) to - determine which).

-

-
Disabling the legacy devfs cloning functionality may break - existing applications which use tun, such as - ppp(8) and ssh(1). It therefore defaults - to being enabled until further notice.
-

Control devices (once successfully opened) persist until - if_tuntap.ko is unloaded in the same way that - network interfaces persist (see above).

-

Each interface supports the usual network-interface - ioctl(2)s, such as SIOCAIFADDR and - thus can be used with ifconfig(8) like any other - interface. At boot time, they are POINTOPOINT - interfaces, but this can be changed; see the description of the control - device, below. When the system chooses to transmit a packet on the network - interface, the packet can be read from the control device (it appears as - “input” there); writing a packet to the control device - generates an input packet on the network interface, as if the (non-existent) - hardware had just received it.

-

The tunnel device - (/dev/tunN) is exclusive-open - (it cannot be opened if it is already open). A read(2) - call will return an error (EHOSTDOWN) if the - interface is not “ready” (which means that the control device - is open and the interface's address has been set).

-

Once the interface is ready, read(2) will return - a packet if one is available; if not, it will either block until one is or - return EWOULDBLOCK, depending on whether - non-blocking I/O has been enabled. If the packet is longer than is allowed - for in the buffer passed to read(2), the extra data will - be silently dropped.

-

If the TUNSLMODE ioctl has - been set, packets read from the control device will be prepended with the - destination address as presented to the network interface output routine, - (). - The destination address is in struct sockaddr format. - The actual length of the prepended address is in the member - sa_len. If the TUNSIFHEAD - ioctl has been set, packets will be prepended with a four byte address - family in network byte order. TUNSLMODE and - TUNSIFHEAD are mutually exclusive. In any case, the - packet data follows immediately.

-

A write(2) call passes a packet in to be - “received” on the pseudo-interface. If the - TUNSIFHEAD ioctl has been set, the address family - must be prepended, otherwise the packet is assumed to be of type - AF_INET. Each write(2) call - supplies exactly one packet; the packet length is taken from the amount of - data provided to write(2) (minus any supplied address - family). Writes will not block; if the packet cannot be accepted for a - transient reason (e.g., no buffer space available), it is silently dropped; - if the reason is not transient (e.g., packet too large), an error is - returned.

-

The following ioctl(2) calls are supported - (defined in - <net/if_tun.h>):

-
-
-
The argument should be a pointer to an int; this - sets the internal debugging variable to that value. What, if anything, - this variable controls is not documented here; see the source code.
-
-
The argument should be a pointer to an int; this - stores the internal debugging variable's value into it.
-
-
The argument should be a pointer to an struct - tuninfo and allows setting the MTU and the baudrate of the tunnel - device. The type must be the same as returned by - TUNGIFINFO or set to - IFT_PPP else the ioctl(2) call - will fail. The struct tuninfo is declared in - <net/if_tun.h>. -

The use of this ioctl is restricted to the super-user.

-
-
-
The argument should be a pointer to an struct - tuninfo, where the current MTU, type, and baudrate will be - stored.
-
-
The argument should be a pointer to an int; its - value must be either IFF_POINTOPOINT or - IFF_BROADCAST and should have - IFF_MULTICAST OR'd into the value if multicast - support is required. The type of the corresponding - “tunN” - interface is set to the supplied type. If the value is outside the above - range, an EINVAL error is returned. The interface - must be down at the time; if it is up, an EBUSY - error is returned.
-
-
The argument should be a pointer to an int; a - non-zero value turns off “multi-af” mode and turns on - “link-layer” mode, causing packets read from the tunnel - device to be prepended with the network destination address (see - above).
-
-
Will set the pid owning the tunnel device to the current process's - pid.
-
-
The argument should be a pointer to an int; a - non-zero value turns off “link-layer” mode, and enables - “multi-af” mode, where every packet is preceded with a four - byte address family.
-
-
The argument should be a pointer to an int; the - ioctl sets the value to one if the device is in “multi-af” - mode, and zero otherwise.
-
-
The argument should be a pointer to an int; this - sets the transient flag on the tun device. A - transient tun will be destroyed upon last - close.
-
-
The argument should be a pointer to an int; this - stores the current state (enabled or disabled) of the transient flag into - it.
-
-
Turn non-blocking I/O for reads off or on, according as the argument - int's value is or is not zero. (Writes are always - non-blocking.)
-
-
Turn asynchronous I/O for reads (i.e., generation of - SIGIO when data is available to be read) off or - on, according as the argument int's value is or is - not zero.
-
-
If any packets are queued to be read, store the size of the first one into - the argument int; otherwise, store zero.
-
-
Set the process group to receive SIGIO signals, - when asynchronous I/O is enabled, to the argument - int value.
-
-
Retrieve the process group value for SIGIO signals - into the argument int value.
-
-

The control device also supports select(2) for - read; selecting for write is pointless, and always succeeds, since writes - are always non-blocking.

-

On the last close of the data device, by default, the interface is - brought down (as if with ifconfig - tunN down). All queued packets - are thrown away. If the interface is up when the data device is not open - output packets are always thrown away rather than letting them pile up.

-
-
-

-

ioctl(2), read(2), - select(2), write(2), - devname(3), inet(4), - intro(4), pty(4), - tap(4), ifconfig(8)

-
-
-

-

This manual page was originally obtained from - NetBSD.

-
-
- - - - - -
March 17, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/tws.4 3.html b/static/freebsd/man4/tws.4 3.html deleted file mode 100644 index 77952b5f..00000000 --- a/static/freebsd/man4/tws.4 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
TWS(4)Device Drivers ManualTWS(4)
-
-
-

-

tws — 3ware 9750 - SATA+SAS 6Gb/s RAID controller card driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device scbus -
-device tws
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
tws_load="YES"
-
-
-
-

-

The tws driver provides support for LSI's - 3ware 9750 SATA+SAS 6Gb/s RAID controller cards.

-

These controllers feature the LSISAS2108 6Gb/s SAS RAID-on-Chip - (ROC) and are available in 4- and 8-port configurations, supports RAID - levels 0, 1, 5, 6, 10, 50 and single disk, with 96 SATA and/or SAS hard - drives and SSDs.

-

For further hardware information, see - http://www.lsi.com/.

-
-
-

-

The tws driver supports the following - SATA/SAS RAID controller:

-

-
    -
  • LSI's 3ware SAS 9750 series
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.tws.cam_depth
-
The maximum queued CAM SIM requests for one controller. The default value - is 256.
-
hw.tws.enable_msi
-
This tunable enables MSI support on the controller if set to a non-zero - value. The default value is 0.
-
hw.tws.queue_depth
-
The maximum queued requests for one controller.
-
hw.tws.use_32bit_sgls
-
Limit the driver to use only 32-bit SG elements regardless whether the - operating system is running in 64-bit mode. The default value is 0.
-
-
-
-

-
-
/dev/da?
-
array/logical disk interface
-
/dev/tws?
-
management interface
-
-
-
-

-

Whenever the driver encounters a command failure, it prints out an - error code in the format: "ERROR: (<error - source>: <error code>):", followed by a text - description of the error. There are other error messages and warnings that - the driver prints out, depending on the kinds of errors that it encounters. - If the driver is compiled with TWS_DEBUG defined, it - prints out a whole bunch of debug messages.

-
-
-

-

da(4), scsi(4)

-
-
-

-

The tws driver was written by - Manjunath Ranganathaiah for LSI and this manual page - was written by Xin LI - <delphij@FreeBSD.org> - for iXsystems, Inc.

-
-
- - - - - -
October 4, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/u2f.4 4.html b/static/freebsd/man4/u2f.4 4.html deleted file mode 100644 index 7e26f655..00000000 --- a/static/freebsd/man4/u2f.4 4.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
U2F(4)Device Drivers ManualU2F(4)
-
-
-

-

u2f — FIDO/U2F USB - security keys

-
-
-

-

device u2f

-

In loader.conf(5): -
- u2f_load="YES"

-

In sysctl.conf(5): -
- hw.hid.u2f.debug

-
-
-

-

The u2f driver provides support for - FIDO/U2F-compatible USB security keys. They are Human Interface Devices - (HID) which can be accessed via the /dev/u2f/N - interface.

-

The driver is compatible with the read(2), - write(2), and ioctl(2) operations of the - generic uhid(4) device but only accepts the optional HID - ioctl(2) calls from u2f group users.

-
-
-

-

The u2f driver supports - FIDO/U2F-compatible USB security keys.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.hid.u2f.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/u2f/*
-
 
-
-
-
-

-

uhid(4), usbhid(4), - usb(4)

-
-
-

-

The u2f driver first appeared in - FreeBSD 15.0.

-
-
-

-

The u2f driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-

This manual page was written by Vladimir - Kondratyev - <wulf@FreeBSD.org> - based on the OpenBSD fido(4) - manual page.

-
-
- - - - - -
August 21, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/u3g.4 3.html b/static/freebsd/man4/u3g.4 3.html deleted file mode 100644 index 04fc26ea..00000000 --- a/static/freebsd/man4/u3g.4 3.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - -
U3G(4)Device Drivers ManualU3G(4)
-
-
-

-

u3g — USB support - for 3G and 4G cellular modems

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device u3g
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
u3g_load="YES"
-
-

If neither of the above is done, the driver will be automatically - loaded by devd(8) when the device is connected.

-
-
-

-

The u3g driver provides support for - USB-to-serial interfaces exposed by many 3G and 4G modems. The supported - adapters provide the necessary modem port for ppp(8), or - net/mpd5 connections. Depending on the specific - device, extra ports provide other functions such as an additional command - port, diagnostic port, GPS receiver port, or SIM toolkit port.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-

In some adapters a mass storage device supported by the - umass(4) driver is present which contains Windows and Mac - OS X drivers. The device starts up in disk mode (TruInstall, ZeroCD, etc.) - and requires additional commands to switch it to modem mode. If your device - is not switching automatically, please try to add quirks. See - usbconfig(8) and usb_quirk(4).

-
-
-

-

The u3g driver supports the following - cellular modems:

-

-
    -
  • Option GT 3G Fusion, GT Fusion Quad, etc. (3G only, not WLAN)
    • -
  • Option GT 3G, GT 3G Quad, etc.
    • -
  • Vodafone Mobile Connect Card 3G
    • -
  • Vodafone Mobile Broadband K3772-Z
    • -
  • Qualcomm Inc. CDMA MSM
    • -
  • Qualcomm Inc. GOBI 1000, 2000 and 3000 devices with MDM1000 or MDM2000 - chipsets
    • -
  • QUECTEL BGX, ECX, EGX, EMX, EPX, RGX series
    • -
  • Quectel EM160R, EM060K (see - CAVEATS)
    • -
  • Huawei B190, E180v, E220, E3372, E3372v153, E5573Cs322, ('<Huawei - Mobile>')
    • -
  • Novatel U740, MC950D, X950D, etc.
    • -
  • Sierra MC875U, MC8775U, EM7590, etc.
    • -
  • Panasonic CF-F9 GOBI
    • -
-

Many more are supported, see - /sys/dev/usb/serial/u3g.c for the complete list.

-
-
-

-
-
/dev/ttyU*.*
-
for callin ports
-
/dev/ttyU*.*.init
-
 
-
/dev/ttyU*.*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*.*
-
for callout ports
-
/dev/cuaU*.*.init
-
 
-
/dev/cuaU*.*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

Connect to the Internet using the default configuration:

-
-
ppp -background u3g
-
-
-
-

-

tty(4), ucom(4), - usb(4), usb_quirk(4), - devd(8), ppp(8), - usbconfig(8)

-
-
-

-

The u3g driver appeared in - FreeBSD 7.2, is based on the - uark(4) driver, and written by Andrea - Guzzo - <aguzzo@anywi.com> in - September 2008.

-
-
-

-

The u3g driver was written by - Andrea Guzzo - <aguzzo@anywi.com> - and Nick Hibma - <n_hibma@FreeBSD.org>. - Hardware for testing was provided by AnyWi Technologies, Leiden, NL.

-
-
-

-

The Quectel EM160R is not officially supported in PPP mode. In - order to use it in PPP mode, the ctsrts option needs to be turned off, for - example, by adding:

-

-
set ctsrts off
-

to /etc/ppp/ppp.conf in the correct - section.

-
-
-

-

The automatic mode switch from disk mode to modem mode does not - work unless the driver is either built into the kernel or loaded before the - device is connected.

-

The GOBI-based devices require the gobi loader available from the - sysutils/gobi_loader port.

-
-
- - - - - -
December 5, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/uark.4 3.html b/static/freebsd/man4/uark.4 3.html deleted file mode 100644 index bb5f018c..00000000 --- a/static/freebsd/man4/uark.4 3.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - -
UARK(4)Device Drivers ManualUARK(4)
-
-
-

-

uark — Arkmicro - Technologies ARK3116 based USB serial adapter

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device uark
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uark_load="YES"
-
-
-
-

-

The uark driver supports Arkmicro - Technologies ARK3116 based serial adapters.

-
-
-

-

The uark driver supports the following - adapters:

-

-
    -
  • HL USB-RS232
    • -
  • HugePine USB-UART
    • -
  • KQ-U8A Data Cable
    • -
  • Skymaster USB to RS232
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The uark device driver first appeared in - OpenBSD 4.0. The first - FreeBSD release to include it was - FreeBSD 7.0.

-
-
-

-

The uark driver was written by - Jonathan Gray - <jsg@openbsd.org>.

-
-
-

-

Setting hardware flow control is not currently supported. It is - not yet known how to ask the hardware to send a break.

-

Arkmicro Technologies do not reply to requests of documentation - for their products.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/uart.4 3.html b/static/freebsd/man4/uart.4 3.html deleted file mode 100644 index 61242738..00000000 --- a/static/freebsd/man4/uart.4 3.html +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - -
UART(4)Device Drivers ManualUART(4)
-
-
-

-

uart — Universal - Asynchronous Receiver/Transmitter serial driver

-
-
-

-

device uart

-

-
- device puc -
- device uart

-

-
- device scc -
- device uart

-

In /boot/device.hints: -
- hint.uart.0.disabled="1" -
- hint.uart.0.baud="38400" -
- hint.uart.0.port="0x3f8" -
- hint.uart.0.flags="0x10"

-

With flags encoded as:

-
-
0x00010
-
device is potential system console
-
0x00080
-
use this port for remote kernel debugging
-
0x00100
-
set RX FIFO trigger level to ``low'' (NS8250 only)
-
0x00200
-
set RX FIFO trigger level to ``medium low'' (NS8250 only)
-
0x00400
-
set RX FIFO trigger level to ``medium high'' (default, NS8250 only)
-
0x00800
-
set RX FIFO trigger level to ``high'' (NS8250 only)
-
-
-
-

-

The uart device driver provides support - for various classes of UARTs implementing the EIA RS-232C (CCITT V.24) - serial communications interface. Each such interface is controlled by a - separate and independent instance of the uart - driver. The primary support for devices that contain multiple serial - interfaces or that contain other functionality besides one or more serial - interfaces is provided by the puc(4), or - scc(4) device drivers. However, the serial interfaces of - those devices that are managed by the puc(4), or - scc(4) driver are each independently controlled by the - uart driver. As such, the puc(4), - or scc(4) driver provides umbrella functionality for the - uart driver and hides the complexities that are - inherent when elementary components are packaged together.

-

The uart driver has a modular design to - allow it to be used on differing hardware and for various purposes. In the - following sections the components are discussed in detail. Options are - described in the section that covers the component to which each option - applies.

-
-

-

At the heart of the uart driver is the - core component. It contains the bus attachments and the low-level interrupt - handler.

-
-
-

-

The core component and the kernel interfaces talk to the hardware - through the hardware interface. This interface serves as an abstraction of - the hardware and allows varying UARTs to be used for serial - communications.

-
-
-

-

System devices are UARTs that have a special purpose by way of - hardware design or software setup. For example, Sun UltraSparc machines use - UARTs as their keyboard interface. Such an UART cannot be used for general - purpose communications. Likewise, when the kernel is configured for a serial - console, the corresponding UART will in turn be a system device so that the - kernel can output boot messages early on in the boot process.

-
-
-

-

The last but not least of the components is the kernel interface. - This component ultimately determines how the UART is made visible to the - kernel in particular and to users in general. The default kernel interface - is the TTY interface. This allows the UART to be used for terminals, modems - and serial line IP applications. System devices, with the notable exception - of serial consoles, generally have specialized kernel interfaces.

-
-
-
-

-

The uart driver supports the following - classes of UARTs:

-

-
    -
  • NS8250: standard hardware based on the 8250, 16450, 16550, 16650, 16750 or - the 16950 UARTs.
    • -
  • SCC: serial communications controllers supported by the - scc(4) device driver.
    • -
-
-
-

-

The uart driver can capture PPS timing - information as defined in RFC 2783. The API, accessed via - ioctl(2), is available on the tty device. To use the PPS - capture feature with ntpd(8), symlink the tty callout - device /dev/cuau? to - /dev/pps0.

-

The hw.uart.pps_mode tunable configures the - PPS capture mode for all uart devices; it can be set in - loader.conf(5). The - dev.uart.0.pps_mode sysctl configures the PPS capture - mode for a specific uart device; it can be set in - loader.conf(5) or sysctl.conf(5).

-

The following capture modes are available:

-
-
-
0x00
-
Capture disabled.
-
0x01
-
Capture pulses on the CTS line.
-
0x02
-
Capture pulses on the DCD line.
-
-
-

The following values may be ORed with the capture mode to - configure capture processing options:

-
-
-
0x10
-
Invert the pulse (RS-232 logic low = ASSERT, high = CLEAR).
-
0x20
-
Attempt to capture narrow pulses.
-
-
-

Add the narrow pulse option when the incoming PPS pulse width is - small enough to prevent reliable capture in normal mode. In narrow mode the - driver uses the hardware's ability to latch a line state change; not all - hardware has this capability. The hardware latch provides a reliable - indication that a pulse occurred, but prevents distinguishing between the - CLEAR and ASSERT edges of the pulse. For each detected pulse, the driver - synthesizes both an ASSERT and a CLEAR event, using the same timestamp for - each. To prevent spurious events when the hardware is intermittently able to - see both edges of a pulse, the driver will not generate a new pair of events - within a half second of the prior pair. Both normal and narrow pulse modes - work with ntpd(8).

-

Add the invert option when the connection to the uart device uses - TTL level signals, or when the PPS source emits inverted pulses. RFC 2783 - defines an ASSERT event as a higher-voltage line level, and a CLEAR event as - a lower-voltage line level, in the context of the RS-232 protocol. The modem - control signals on a TTL-level connection are typically inverted from the - RS-232 levels. For example, carrier presence is indicated by a high signal - on an RS-232 DCD line, and by a low signal on a TTL DCD line. This is due to - the use of inverting line driver buffers to convert between TTL and RS-232 - line levels in most hardware designs. Generally speaking, a connection to a - DB-9 style connector is an RS-232 level signal at up to 12 volts. A - connection to header pins or an edge-connector on an embedded board is - typically a TTL signal at 3.3 or 5 volts.

-
-
-

-

The uart driver also supports an - initial-state and a lock-state control device for each of the callin and the - callout "data" devices. The termios settings of a data device are - copied from those of the corresponding initial-state device on first opens - and are not inherited from previous opens. Use stty(1) in - the normal way on the initial-state devices to program initial termios - states suitable for your setup.

-

The lock termios state acts as flags to disable changing - the termios state. E.g., to lock a flag variable such as CRTSCTS, use - on the - lock-state device. Speeds and special characters may be locked by setting - the corresponding value in the lock-state device to any nonzero value. E.g., - to lock a speed to 115200, use “stty - 115200” on the initial-state device and - “stty 1” on the lock-state device.

-

Correct programs talking to correctly wired external devices work - with almost arbitrary initial states and almost no locking, but other setups - may benefit from changing some of the default initial state and locking the - state. In particular, the initial states for non (POSIX) standard flags - should be set to suit the devices attached and may need to be locked to - prevent buggy programs from changing them. E.g., CRTSCTS should be locked on - for devices that support RTS/CTS handshaking at all times and off for - devices that do not support it at all. CLOCAL should be locked on for - devices that do not support carrier. HUPCL may be locked off if you do not - want to hang up for some reason. In general, very bad things happen if - something is locked to the wrong state, and things should not be locked for - devices that support more than one setting. The CLOCAL flag on callin ports - should be locked off for logins to avoid certain security holes, but this - needs to be done by getty if the callin port is used for anything else.

-
-
-

-

The uart driver can be designated as a - system console.

-
-
hw.uart.console
-
Contains a number of /etc/remote like tag:value - pairs, separated by commas. -
-
-
Busy Detect. Enable the so-called “Busy Detect” quirk - for the device. For NS 16550-compatible devices, this will use - heuristics to ensure that the UART is no longer busy before - manipulating line control. DesignWare-based UARTs need this due to a - design flaw in the UART.
-
-
Baudrate. The data rate (bits per second) used for communications on - the serial port. When the device clock rate (see below) is set to 0, - then the baud rate will be used with the divisor to compute the device - clock rate the first time the device is initialized. Only the - traditional baud rates are allowed. Rates larger than 19200 must be a - multiple of 19200. Baud rates between 1200 and 19200 must be a - multiple of 1200. Otherwise the baud rate must be a multiple of 75. A - value of '0' instructs the uart driver to not - program the baud rate divisor and use the hardware as-is.
-
-
Channel. Defaults to 0. Has no effect on UARTs with only one - channel.
-
-
Data bits. Defaults to 8.
-
-
Device type. Specify the uart class to use for this device. -
-
ns8250
-
Traditional PC UART National Semiconductor 16550 and compatible - devices.
-
pl011
-
Common ARM UART, based on ARM Limited designs.
-
-
-
-
I/O port address. Specifies the address of a UART in an Intel - processor's I/O space. Mutually exclusive with - ‘mm’.
-
-
Memory mapped I/O address. Specifies the physical address of a - memory-mapped UART. Mutually exclusive with ‘io’.
-
-
Parity. The type of parity to use when sending data to the host. This - may be one of ``even'', ``odd'', ``none'', ``zero'' (always set bit 8 - to zero), ``one'' (always set bit 8 to 1). The default is even - parity.
-
-
Register shift. Number of bits to shift left the base register - offset.
-
-
Register width. Size of operations to read and write the registers of - the device.
-
-
Stopbits. Defaults to 1.
-
-
Device clock (xtal oscillator). Base frequency of the oscillator to - use for the device. When set to 0, and the baud rate is also set, the - UART's initialization code will compute this the first time and use - that after. Automatically computed values can be as large as 5% when - the base frequency is a poor match to the traditional baud rates.
-
-
-
-
-
-

-
-
/dev/ttyu?
-
for callin ports
-
/dev/ttyu?.init
-
 
-
/dev/ttyu?.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuau?
-
for callout ports
-
/dev/cuau?.init
-
 
-
/dev/cuau?.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-
hw.uart.console="io:0x2f8,br=115200"
-

When the kernel is using a serial console port, it should use COM2 - instead of COM1 and set the baud rate to 115200.

-
-
-

-

cu(1), puc(4), - scc(4), termios(4), - tty(4), ttys(5)

-
-
-

-

The uart device driver first appeared in - FreeBSD 5.2.

-
-
-

-

The uart device driver and this manual - page were written by Marcel Moolenaar - <marcel@xcllnt.net>.

-
-
-

-

Before the Internet, serial ports were primarily used for inbound - connections from terminals, either directly or through modems, these days - serial ports are primarily used for outbound connections to devices, an - evolution which unfortunately has spread the relevant documentation over - three different manual pages: termios(4), - uart(4) and tty(4).

-

-
-
- - - - - -
December 5, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/uath.4 3.html b/static/freebsd/man4/uath.4 3.html deleted file mode 100644 index a5322cb4..00000000 --- a/static/freebsd/man4/uath.4 3.html +++ /dev/null @@ -1,247 +0,0 @@ - - - - - - -
UATH(4)Device Drivers ManualUATH(4)
-
-
-

-

uath — Atheros USB - IEEE 802.11a/b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device uath -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_uath_load="YES"
-
-
-
-

-

The uath driver supports USB 2.0 wireless - network devices based on Atheros Communications fifth generation AR5005UG - and AR5005UX chipsets.

-

The AR5005UG chipset is made of an AR5523 multiprotocol - MAC/baseband processor and an AR2112 Radio-on-a-Chip that can operate - between 2300 and 2500 MHz (802.11b/g).

-

The AR5005UX chipset is made of an AR5523 multiprotocol - MAC/baseband processor and an AR5112 dual band Radio-on-a-Chip that can - operate between 2300 and 2500 MHz (802.11b/g) or 4900 and 5850 MHz - (802.11a).

-

The AR5005UG and AR5005UX chipsets both have an integrated 32-bit - MIPS R4000-class processor that runs a firmware and manages, among other - things, the automatic control of the transmit rate and the calibration of - the radio.

-

uath supports - station, and monitor mode - operation. Only one virtual interface may be configured at any time. For - more information on configuring this device, see - ifconfig(8).

-
-
-

-

uath requires firmware that is downloaded - to the device. This is normally done by the uathload(8) - utility that is launched by devd(8) when the device is - inserted. uathload(8) includes the firmware in the binary - program. This firmware is licensed for general use and is included in the - base system.

-
-
-

-

The uath driver should work with the - following adapters:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AR5005UX
AR5005UG
AR5005UG
AR5005UX
AR5005UG
AR5005UX
AR5005UG
AR5005UG
AR5005UX
AR5005UG
AR5005UG
AR5005UG
AR5005UX
AR5005UG
AR5005UX
AR5005UX
AR5005UX
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
ifconfig wlan create wlandev uath0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - “my_net”:

-

-
ifconfig wlan create wlandev uath0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev uath0 ssid my_net \
-	wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev uath0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
uath%d: could not send command (error=%s)
-
An attempt to send a command to the firmware failed.
-
uath%d: timeout waiting for command reply
-
A read command was sent to the firmware but the firmware failed to reply - in time.
-
uath%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
-
-
-

-

netintro(4), usb(4), - wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - devd(8), ifconfig(8), - uathload(8), wpa_supplicant(8)

-
-
-

-

The uath driver first appeared in - OpenBSD 4.0.

-
-
-

-

The uath driver was written by - Weongyo Jeong - <weongyo@FreeBSD.org> - and Sam Leffler - <sam@FreeBSD.org>. It - is distantly related to a driver written by Damien - Bergamini - <damien@openbsd.org>.

-
-
-

-

Atheros proprietary 108 Mbps mode (aka Super AG mode) is not - supported.

-

Dual-band adapters are presently not working; to workaround, - restriction operation to 2.4GHz channels.

-
-
- - - - - -
April 7, 2009FreeBSD 15.0
diff --git a/static/freebsd/man4/ubsa.4 4.html b/static/freebsd/man4/ubsa.4 4.html deleted file mode 100644 index ff64ba1b..00000000 --- a/static/freebsd/man4/ubsa.4 4.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
UBSA(4)Device Drivers ManualUBSA(4)
-
-
-

-

ubsa — USB support - for Belkin serial adapters

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device ubsa
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ubsa_load="YES"
-
-
-
-

-

The ubsa driver provides support for the - USB-to-RS232 Bridge chip used by a variety of serial adapters from Belkin - and other vendors.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-

The ubsa driver supports the following - adapters:

-

-
    -
  • AnyData ADU-500A EV-DO modem
    • -
  • AnyData ADU-E100A (no EV-DO mode support)
    • -
  • Belkin F5U103
    • -
  • Belkin F5U120
    • -
  • e-Tek Labs Kwik232
    • -
  • GoHubs GoCOM232
    • -
  • Peracom single port serial adapter
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The ubsa driver appeared in - FreeBSD 5.0. The uplcom(4) manual - page was adopted from NetBSD by Tom - Rhodes - <trhodes@FreeBSD.org> - in April 2002 and modified for the ubsa driver by - Alexander Kabaev - <kan@FreeBSD.org> in - October 2002.

-
-
-

-

The ubsa driver was written by - Alexander Kabaev - <kan@FreeBSD.org>.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ubser.4 4.html b/static/freebsd/man4/ubser.4 4.html deleted file mode 100644 index 22ec1e66..00000000 --- a/static/freebsd/man4/ubser.4 4.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - -
UBSER(4)Device Drivers ManualUBSER(4)
-
-
-

-

ubser — USB - support for BWCT console serial adapters

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device usb -
-device ucom -
-device ubser
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ubser_load="YES"
-
-
-
-

-

The ubser driver provides support for the - BWCT console management serial adapters.

-
-
-

-
-
/dev/ttyU*.*
-
for callin ports
-
/dev/ttyU*.*.init
-
 
-
/dev/ttyU*.*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*.*
-
for callout ports
-
/dev/cuaU*.*.init
-
 
-
/dev/cuaU*.*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The ubser driver appeared in - FreeBSD 5.2.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ubtbcmfw.4 3.html b/static/freebsd/man4/ubtbcmfw.4 3.html deleted file mode 100644 index 8c8d6892..00000000 --- a/static/freebsd/man4/ubtbcmfw.4 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
UBTBCMFW(4)Device Drivers ManualUBTBCMFW(4)
-
-
-

-

ubtbcmfw — - Firmware driver for Broadcom BCM2033 chip based Bluetooth - USB devices

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ubtbcmfw
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ubtbcmfw_load="YES"
-
-
-
-

-

The ubtbcmfw is a firmware driver for - Broadcom BCM2033 chip based Bluetooth USB devices. It provides minimal - access to the parts of the device required to download firmware.

-

The ubtbcmfw driver creates three fixed - endpoint device nodes.

-

The control transfers can only happen on the control endpoint - which is always endpoint 0. Control requests are issued by - ioctl(2) calls.

-

Only incoming transfers are supported on an interrupt endpoint. To - perform I/O on an interrupt endpoint, read(2) should be - used. All I/O operations on an interrupt endpoint are unbuffered. Interrupt - endpoint is always endpoint 1.

-

Only outgoing bulk transfers are supported on a bulk endpoint. To - perform I/O on a bulk endpoint, write(2) should be used. - All I/O operations on a bulk endpoint are unbuffered. Outgoing bulk endpoint - is always endpoint 2.

-

The control endpoint (endpoint 0) handles the following - ioctl(2) calls:

-
-
- (usb_device_descriptor_t)
-
Return the device descriptor.
-
-
-
-

-
-
/dev/ubtbcmfwN.EE
-
Endpoint EE of device N.
-
-
-
-

-

ng_ubt(4), ugen(4), - usb(4), bcmfw(8)

-
-
-

-

The ubtbcmfw driver was implemented in - FreeBSD 5.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

Most likely. Please report if found.

-
-
- - - - - -
November 22, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/uchcom.4 4.html b/static/freebsd/man4/uchcom.4 4.html deleted file mode 100644 index e335630d..00000000 --- a/static/freebsd/man4/uchcom.4 4.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
UCHCOM(4)Device Drivers ManualUCHCOM(4)
-
-
-

-

uchcom — - WinChipHead CH9102/CH343/CH341/CH340 USB to serial UART - driver

-
-
-

-

device usb -
- device ucom -
- device uchcom

-

In rc.conf(5): -
- kld_list="uchcom"

-

In sysctl.conf(5): -
- hw.usb.uchcom.debug=1

-
-
-

-

The uchcom driver provides support for the - WinChipHead USB to serial UART adapters. If the appropriate hardware is - detected, the driver will be loaded automatically by - devmatch(8). To load the driver manually, add it to the - kld_list in rc.conf(5), or use - kldload(8) at runtime. The device is accessed through the - ucom(4) driver, which makes it behave like a - tty(4).

-

Call out through this interface with applications like - cu(1) or tip(1).

-
-
-

-

The uchcom driver supports the following - USB to serial UART controllers:

-

-
    -
  • WinChipHead CH9102 (max 6Mbps)
    • -
  • WinChipHead CH343 (max 6Mbps)
    • -
  • WinChipHead CH341 (max 2Mbps)
    • -
  • WinChipHead CH340 (max 2Mbps)
    • -
-
-
-

-

These settings can be entered in the loader(8) - prompt, set in loader.conf(5), - sysctl.conf(5), or changed at runtime with - sysctl(8):

-
-
hw.usb.uchcom.debug
-
Enable debugging messages, default - ‘0’
-
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

cu(1), tty(4), - ucom(4), usb(4)

-
-
-

-

The uchcom driver appeared in - FreeBSD 8.0 from NetBSD - 5.0.

-
-
- - - - - -
June 25, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ucom.4 3.html b/static/freebsd/man4/ucom.4 3.html deleted file mode 100644 index 5dd9680e..00000000 --- a/static/freebsd/man4/ucom.4 3.html +++ /dev/null @@ -1,130 +0,0 @@ - - - - - - -
UCOM(4)Device Drivers ManualUCOM(4)
-
-
-

-

ucom — USB tty - support

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ucom
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ucom_load="YES"
-
-
-
-

-

The ucom driver attaches to USB modems, - serial ports, and other devices that need to look like a tty. The - ucom driver shows a behavior like a - tty(4). This means that normal programs such as - tip(1) or ppp(8) can be used to access - the device.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.ucom.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
hw.usb.ucom.device_mode_console
-
When set to 1, the ucom driver will mark terminals - as console devices when operating in device mode. Default is 1.
-
hw.usb.ucom.pps_mode
-
Enables and configure PPS capture mode as described below.
-
-
-
-

-

The ucom driver can capture PPS timing - information as defined in RFC 2783. The API, accessed via - ioctl(2), is available on the tty device. To use the PPS - capture feature with ntpd(8), symlink the tty device to - /dev/pps0.

-

The hw.usb.ucom.pps_mode sysctl configures - the PPS capture mode. It can be set in loader.conf(5) or - sysctl.conf(5). The following capture modes are - available:

-
-
-
0
-
Capture disabled (default).
-
1
-
Capture pulses on the CTS line.
-
2
-
Capture pulses on the DCD line.
-
-
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

cu(1), tty(4), - uark(4), ubsa(4), - ubser(4), uchcom(4), - ucycom(4), ufoma(4), - uftdi(4), uhso(4), - uipaq(4), umcs(4), - umct(4), umodem(4), - umoscom(4), uplcom(4), - usb(4), uslcom(4), - uvisor(4), uvscom(4), - ttys(5)

-
-
-

-

The ucom driver was adopted from - NetBSD in March of 2002. This manual page was - adopted from NetBSD by Tom - Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
-

-

Prior to FreeBSD 6.0 - ucom created /dev/ucom? - rather than the uniform device names created today. Old scripts must be - adjusted accordingly.

-
-
- - - - - -
July 11, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/ucycom.4 4.html b/static/freebsd/man4/ucycom.4 4.html deleted file mode 100644 index bc532ba3..00000000 --- a/static/freebsd/man4/ucycom.4 4.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
UCYCOM(4)Device Drivers ManualUCYCOM(4)
-
-
-

-

ucycom — device - driver for Cypress CY7C63743 and CY7C64013 USB to RS232 bridges

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device usb -
-device hid -
-device ucom -
-device ucycom
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ucycom_load="YES"
-
-
-
-

-

The ucycom driver provides support for the - Cypress CY7C63743 and CY7C64013 bridge chips. These chips were designed to - provide a low-cost transition path to USB for existing RS232 devices, and - have fairly limited capabilities.

-

The ucycom driver behaves like a - tty(4).

-
-
-

-

The ucycom driver currently supports the - following devices which incorporate Cypress USB to RS232 bridge chips:

-

-
    -
  • DeLorme Earthmate USB GPS receiver
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The ucycom driver first appeared in - FreeBSD 5.3.

-
-
-

-

The ucycom driver and this manual page - were written by Dag-Erling Smørgrav - <des@FreeBSD.org>.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/udav.4 4.html b/static/freebsd/man4/udav.4 4.html deleted file mode 100644 index 4ebe61b0..00000000 --- a/static/freebsd/man4/udav.4 4.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
UDAV(4)Device Drivers ManualUDAV(4)
-
-
-

-

udav — Davicom - DM9601 USB Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device udav
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_udav_load="YES"
-
-
-
-

-

The udav driver supports the following - adapters:

-

-
    -
  • Corega FEther USB-TXC
    • -
  • ShanTou ST268 USB NIC
    • -
-
-
-

-

The udav driver provides support for USB - Ethernet adapters based on the Davicom DM9601 chipset.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), usb(4), - ifconfig(8)

-

Davicom DM9601 data - sheet, - http://ptm2.cc.utu.fi/ftp/network/cards/DM9601/From_NET/DM9601-DS-P01-930914.pdf.

-
-
-

-

The udav device driver first appeared in - NetBSD 2.0.

-
-
-

-

The udav driver was written by - Shingo WATANABE - <nabe@nabechan.org>.

-
-
- - - - - -
November 24, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/udbc.4 3.html b/static/freebsd/man4/udbc.4 3.html deleted file mode 100644 index ea4b74a1..00000000 --- a/static/freebsd/man4/udbc.4 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
UDBC(4)Device Drivers ManualUDBC(4)
-
-
-

-

udbc — USB Debug - Class device driver

-
-
-

-

device usb -
- device ucom -
- device udbc

-

In rc.conf(5): -
- kld_list="udbc"

-
-
-

-

The udbc driver provides support for USB - Debug Class devices whose interface class is Diagnostic Class and the - subclass is DbC.GP.

-

The USB Debug Class is defined in the USB 3.1 Device Class - Specification for Debug Devices. This is designed to provide a - general-purpose communication channel for debugging. It has also been widely - implemented in USB xHCs (USB eXtensible Host Controllers), which can be - found on many commodity computers, as an optional feature. Once this feature - is enabled on a USB xHC, one of the USB ports will behave as a USB Debug - Class device, not a host port, when a USB debug cable is connected. The - supported class in USB xHCs is typically DbC.GP, while the specification - defines several types of Debug Class devices. The DbC.GP uses IN and OUT - endpoint pairs and realizes a single bidirectional serial communication - channel. On most systems, including FreeBSD, the - DbC.GP is seen as a simple serial device.

-

Most systems with USB xHC can be configured to provide DbC.GP - access. The udbc is a driver that connects to - DbC.GP-supported devices, offering tty(4) devices to - connect to them via the ucom(4) device driver.

-
-
-

-

A native DbC.GP device can be attached using the - udbc driver in a straightforward way.

-

A USB xHC DbC.GP device on a target system needs a special - hardware configuration because all of the ports are supposed to be a USB - Host. There is one method to expose DbC.GP is to use a USB 3.1 A-to-A cable - (section 5.5.2 in USB 3.1 Legacy Cable and Connector Specification). When - this cable is connected to a USB 3.1 port on the target system, the - DbC-enabled USB xHC automatically switches the port as a USB Device. The - udbc driver can find a DbC.GP device on that - port.

-

Note that a USB xHC with USB 3.2 support (USB Type-C connectors) - is not compatible with the USB 3.1 A-to-A cable. Connecting a USB 3.2 C-to-C - cable or A-to-C cable does not automatically work, either, because it needs - role configuration of the port, which is not supported on - FreeBSD yet.

-
-
-

-
-
/dev/ttyU*.*
-
for callin ports
-
/dev/ttyU*.*.init
-
 
-
/dev/ttyU*.*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*.*
-
for callout ports
-
/dev/cuaU*.*.init
-
 
-
/dev/cuaU*.*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4), xhci(4)

-
-
-

-

eXtensible Host Controller - Interface for Universal Serial Bus (XHCI), - https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf. - USB 3.1 Device Class Specification for - Debug Devices, - https://www.usb.org/sites/default/files/documents/usb_debug_class_rev_1_0_final_0.pdf. - USB 3.1 Legacy Cable and Connector - Specification, - https://www.usb.org/document-library/usb-31-legacy-cable-and-connector-revision-10.

-
-
-

-

The udbc driver first appeared - FreeBSD 15.0.

-
-
-

-

The udbc driver was written by - Hiroki Sato - <hrs@FreeBSD.org>.

-
-
-

-

According to the XHCI specification the host side of USB Debug - should work with any USB 3.0 port, whether connected directly to a - controller or with a hub in between. Testing on some controllers has - encountered issues when using a hub rather than a directly connected port on - the controller.

-
-
- - - - - -
September 3, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/udbp.4 3.html b/static/freebsd/man4/udbp.4 3.html deleted file mode 100644 index 6422babf..00000000 --- a/static/freebsd/man4/udbp.4 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
UDBP(4)Device Drivers ManualUDBP(4)
-
-
-

-

udbp — USB Double - Bulk Pipe driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device udbp
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
udbp_load="YES"
-
-
-
-

-

The udbp driver provides support for - host-to-host cables that contain at least two bulk pipes (one for each - direction). This typically includes cables branded for use with - , and many cables based on the Prolific PL2xx1 series - of USB bridge chips. A useful (but non-comprehensive) list of compatible USB - host cables is listed in the SEE ALSO - section below.

-

It requires netgraph(4) to be available. This - can be done either by adding options NETGRAPH to - your kernel configuration file, or alternatively loading - netgraph(4) as a module, either from - /boot/loader.conf or from the command line, before - the udbp module.

-
-
-

-
options NETGRAPH
-
device udbp
-

Add the udbp driver to the kernel.

-

-
kldload netgraph
-
kldload udbp
-

Load the netgraph(4) module and then the - udbp driver.

-

-
ngctl mkpeer udbp0: eiface data - ether
-
ifconfig ngeth0 ether - aa:dd:xx:xx:xx
-
ifconfig ngeth0 inet - 169.254.x.x/16
-

Create a new Ethernet network interface node and connect its ether - hook to the data hook of the udbp driver.

-

This enables FreeBSD to communicate with a Linux peer - (e.g. using the - driver). The - Linux node should be configured to prefer link-local IPv4 addresses (e.g. - using Network Manager in Debian and Red Hat derived distributions).

-

Whilst both FreeBSD and Linux are able to interoperate by loosely - following CDC EEM 1.0 in their behaviour, neither implementation has been - expressly designed to follow its specification.

-
-
-

-

netgraph(4), ng_eiface(4), - ohci(4), uhci(4), - usb(4), ngctl(8)

-

Universal Serial Bus: - Communications Class Subclass Specification for Ethernet Emulation Model - Devices, USB Implementers Forum, Inc., - Revision 1.0, - http://www.usb.org/developers/docs/devclass_docs/CDC_EEM10.pdf, - February 2, 2005.

-

Total Commander: Supported cables - for USB cable connection, Ghisler Software GmbH., - https://www.ghisler.com/cables/index.htm.

-
-
-

-

The point-to-point nature and additional latency of USB host-host - links makes them unsuitable as a "drop-in" replacement for an - Ethernet LAN; for a USB 3.0 SuperSpeed cable, latency is comparable to - 100BaseTX Ethernet (but often worse), with throughput comparable to - 2.5GBASE-T.

-

However, their energy efficiency makes them attractive for - embedded applications. A Plugable PL27A1 cable claims 24mA of USB3 bus - power, as compared to 150mA for a typical USB 3.0 to Gigabit Ethernet - interface.

-
-
-

-

The udbp driver first appeared in - FreeBSD 5.0.

-
-
-

-

The udbp driver does not support the - special packets described in section 5.1 of the CDC EEM specification.

-
-
-

-

The udbp driver was written by - Doug Ambrisko - <ambrisko@whistle.com>, - Julian Elischer - <julian@FreeBSD.org> - and Nick Hibma - <n_hibma@FreeBSD.org>.

-

This manual page was written by Nick Hibma - <n_hibma@FreeBSD.org> - and updated by Bruce Simpson - <bms@FreeBSD.org>.

-
-
- - - - - -
October 20, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/udl.4 4.html b/static/freebsd/man4/udl.4 4.html deleted file mode 100644 index 573e6b3a..00000000 --- a/static/freebsd/man4/udl.4 4.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
UDL(4)Device Drivers ManualUDL(4)
-
-
-

-

udl — DisplayLink - DL-120 / DL-160 USB display device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device udl -
-device videomode
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
udl_load="YES"
-
-
-
-

-

The udl driver supports USB display - devices based on the DisplayLink DL-120 and DL-160 graphic chips, - including:

-

-
    -
  • Century Corp. Japan Plus One LCD-8000U
    • -
  • Century Corp. Japan Plus One LCD-4300U
    • -
  • DisplayLink USB to DVI
    • -
  • ForwardVideo EasyCAP008 USB to DVI
    • -
  • HP USB 2.0 Docking Station (FQ834)
    • -
  • HP USB Graphics Adapter (NL571)
    • -
  • IOGEAR USB 2.0 External DVI (GUC2020)
    • -
  • Koenig CMP-USBVGA10 and CMP-USBVGA11
    • -
  • Lenovo 45K5296 USB to DVI
    • -
  • Lenovo ThinkVision LT1421
    • -
  • Lilliput UM-70
    • -
  • Nanovision MiMo UM-710 and UM-740
    • -
  • Rextron VCUD60 USB to DVI
    • -
  • Samsung LD220
    • -
  • StarTech CONV-USB2DVI
    • -
  • Sunweit USB to DVI
    • -
  • Unitek Y-2240 USB to DVI
    • -
  • VideoHome NBdock1920
    • -
  • i-tec USB 2.0 Docking Station (USBDVIDOCK)
    • -
-
-
-

-

usb(4)

-
-
-

-

The udl driver appeared in - OpenBSD 4.6 and FreeBSD - 11.0.

-
-
- - - - - -
December 23, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/udp.4 3.html b/static/freebsd/man4/udp.4 3.html deleted file mode 100644 index dfe33785..00000000 --- a/static/freebsd/man4/udp.4 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
UDP(4)Device Drivers ManualUDP(4)
-
-
-

-

udp — Internet - User Datagram Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include <netinet/in.h>

-

int -
- socket(AF_INET, - SOCK_DGRAM, - 0);

-
-
-

-

UDP is a simple, unreliable datagram protocol which is used to - support the SOCK_DGRAM abstraction for the Internet - protocol family. UDP sockets are connectionless, and are normally used with - the sendto(2) and recvfrom(2) calls, - though the connect(2) call may also be used to fix the - destination for future packets (in which case the recv(2) - or read(2) and send(2) or - write(2) system calls may be used).

-

UDP address formats are identical to those used by TCP. In - particular UDP provides a port identifier in addition to the normal Internet - address format. Note that the UDP port space is separate from the TCP port - space (i.e., a UDP port may not be “connected” to a TCP port). - In addition broadcast packets may be sent (assuming the underlying network - supports this) by using a reserved “broadcast address”; this - address is network interface dependent.

-

Options at the IP transport level may be used with UDP; see - ip(4). UDP_ENCAP socket option may be used at the - IPPROTO_UDP level to encapsulate ESP packets in UDP. Only one value is - supported for this option: UDP_ENCAP_ESPINUDP from RFC 3948, defined in - <netinet/udp.h>.

-
-
-

-

UDP sockets are FIB-aware. They inherit the FIB of the process - which created the socket. By default, a UDP socket bound to an address can - receive datagrams originating from any FIB. If the - net.inet.udp.bind_all_fibs tunable is set to 0, all - UDP sockets will receive only datagrams originating from the same FIB as the - socket. In this mode, multiple sockets can be bound to the same address, so - long as each socket belongs to a different FIB, similar to the behavior of - the SO_REUSEPORT option.

-
-
-

-

The udp protocol implements a number of - variables in the net.inet.udp branch of the - sysctl(3) MIB, which can be also read or modified with - sysctl(8):

-
-
blackhole
-
When a datagram is received on a port where there is no socket listening, - do not return an ICMP port unreachable message. (Disabled by default. See - blackhole(4).)
-
checksum
-
Enable UDP checksums (enabled by default).
-
log_in_vain
-
For all UDP datagrams, to ports on which there is no socket listening, log - the connection attempt (disabled by default).
-
maxdgram
-
Maximum outgoing UDP datagram size
-
recvspace
-
Maximum space for incoming UDP datagrams
-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[]
-
when trying to establish a connection on a socket which already has one, - or when trying to send a datagram with the destination address specified - and the socket is already connected;
-
[]
-
when trying to send a datagram, but no destination address is specified, - and the socket has not been connected;
-
[]
-
when the system runs out of memory for an internal data structure;
-
[]
-
when an attempt is made to create a socket with a port which has already - been allocated;
-
[]
-
when an attempt is made to create a socket with a network address for - which no network interface exists.
-
-
-
-

-

getsockopt(2), recv(2), - send(2), socket(2), - blackhole(4), inet(4), - intro(4), ip(4), - udplite(4)

-
-
-

-

The udp protocol appeared in - 4.2BSD.

-
-
- - - - - -
January 20, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/udplite.4 3.html b/static/freebsd/man4/udplite.4 3.html deleted file mode 100644 index b65b1db4..00000000 --- a/static/freebsd/man4/udplite.4 3.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - -
UDPLITE(4)Device Drivers ManualUDPLITE(4)
-
-
-

-

udplite — - Lightweight User Datagram Protocol

-
-
-

-

#include - <sys/types.h> -
- #include <sys/socket.h> -
- #include - <netinet/udplite.h>

-

int -
- socket(AF_INET, - SOCK_DGRAM, - IPPROTO_UDPLITE);

-
-
-

-

The UDP-Lite protocol provides a partial checksum which allows - corrupted packets to be transmitted to the receiving application. This has - advantages for some types of multimedia transport that may be able to make - use of slightly damaged datagrams, rather than having them discarded by - lower-layer protocols.

-

UDP-Lite supports a number of socket options which can be set with - setsockopt(2) and tested with - getsockopt(2):

-
-
-
This option sets the sender checksum coverage. A value of zero indicates - that all sent packets will have full checksum coverage. A value of 8 to - 65535 limits the checksum coverage of all sent packets to the value - given.
-
-
This option is the receiver-side analogue. A value of zero instructs the - kernel to drop all received packets not having full checksum coverage. A - value of 8 to 65535 instructs the kernel to drop all received packets with - a partial checksum coverage smaller than the value specified.
-
-
-
-

-

A socket operation may fail with one of the following errors - returned:

-
-
[]
-
when trying to establish a connection on a socket which already has one, - or when trying to send a datagram with the destination address specified - and the socket is already connected;
-
[]
-
when trying to send a datagram, but no destination address is specified, - and the socket has not been connected;
-
[]
-
when the system runs out of memory for an internal data structure;
-
[]
-
when an attempt is made to create a socket with a port which has already - been allocated;
-
[]
-
when an attempt is made to create a socket with a network address for - which no network interface exists.
-
-
-
-

-

getsockopt(2), recv(2), - send(2), socket(2)

-
-
- - - - - -
October 1, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/uep.4 3.html b/static/freebsd/man4/uep.4 3.html deleted file mode 100644 index a0211a96..00000000 --- a/static/freebsd/man4/uep.4 3.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
UEP(4)Device Drivers ManualUEP(4)
-
-
-

-

uep — eGalax - touchscreen driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device uep -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uep_load="YES"
-
-

To compile this driver with evdev support enabled, place the - following lines into the kernel configuration file:

-
options EVDEV_SUPPORT -
-device evdev
-
-
-

-

The uep driver provides support for the - eGalax onscreen touch panels.

-

The driver is a stub. It just probes and attaches to USB device, - creates a device entry and feeds reassembled packets from the hardware to - it. Depending on compile-time kernel options it supports either native or - evdev operation modes.

-

To get the mouse working in X(7) - (ports/x11/xorg-docs) in native mode, install - ports/x11-drivers/xf86-input-egalax.

-

To get the mouse working in X(7) - (ports/x11/xorg-docs) in evdev mode, install - ports/x11-drivers/xf86-input-evdev.

-
-
-

-

uep creates a blocking pseudo-device file, - /dev/uep0 in native mode or - /dev/input/eventN in evdev mode.

-
-
-

-

usb(4), loader.conf(5), - xorg.conf(5) (ports/x11/xorg), - egalax(4) - (ports/x11-drivers/xf86-input-egalax), - evdev(4) - (ports/x11-drivers/xf86-input-evdev).

-
-
-

-

The uep driver was written by - Gleb Smirnoff - <glebius@FreeBSD.org>.

-
-
-

-

uep cannot act like - sysmouse(4), as sysmouse(4) does not - support absolute motion events.

-
-
- - - - - -
August 5, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/ufintek.4 4.html b/static/freebsd/man4/ufintek.4 4.html deleted file mode 100644 index 492f9fae..00000000 --- a/static/freebsd/man4/ufintek.4 4.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
UFINTEK(4)Device Drivers ManualUFINTEK(4)
-
-
-

-

ufintek — Fintek - F81232 USB to serial UART driver

-
-
-

-

device usb -
- device ucom -
- device ufintek

-

In rc.conf(5): -
- kld_list="ufintek"

-

In sysctl.conf(5): -
- hw.usb.ufintek.debug=1

-
-
-

-

The ufintek driver provides support for - the F81232 serial adapter from FINTEK. If the appropriate hardware is - detected, the driver will be loaded automatically by - devmatch(8). To load the driver manually, add it to the - kld_list in rc.conf(5), or use - kldload(8) at runtime. The device is accessed through the - ucom(4) driver which makes it behave like a - tty(4).

-

Call out through this interface with applications like - cu(1) or tip(1).

-
-
-

-

The ufintek driver supports the following - USB to serial UART controllers:

-

-
    -
  • FT82332
    • -
-
-
-

-

These settings can be entered in the loader(8) - prompt, set in loader.conf(5), - sysctl.conf(5), or changed at runtime with - sysctl(8):

-
-
hw.usb.uftdi.debug
-
Enable debugging messages, default - ‘0’ - ‘1’
-
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

cu(1), tty(4), - ucom(4), usb(4)

-
-
-

-

The ufintek driver appeared in - FreeBSD 16.0

-
-
-

-

This driver is limited to 9600 baud.

-

-
-
- - - - - -
November, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ufoma.4 3.html b/static/freebsd/man4/ufoma.4 3.html deleted file mode 100644 index f9993978..00000000 --- a/static/freebsd/man4/ufoma.4 3.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - -
UFOMA(4)Device Drivers ManualUFOMA(4)
-
-
-

-

ufoma — USB mobile - phone support

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device ufoma
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ufoma_load="YES"
-
-
-
-

-

The ufoma driver provides support for USB - mobile phone terminals in the subset of the Mobile Computing Promotion - Consortium USB Implementation Guideline, which is adopted by FOMA, the NTT - DoCoMo 3G system, terminal. These are partly like CDC ACM model based - modems, which are supported by umodem(4), but the - ufoma driver recognizes a specific USB descriptor - that describes its role and interface structure, and it will negotiate its - role when the device is open. They support a regular AT command set and the - commands can either be multiplexed with the data stream or handled through - separate pipes. In the latter case the AT commands have to be given on a - device separate from the data device.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-

These devices often have a few interface sets and these interfaces - have their role, sometimes multiplexed. These roles are identified with the - following sysctl MIBs:

-
-
dev.ucom.%d.supportmode
-
The modes which are supported by the interface.
-
dev.ucom.%d.currentmode
-
Current mode of the interface.
-
dev.ucom.%d.openmode
-
Mode to transit when the device is open next.
-
-The modes are as follows: -
-
-
Accepts AT commands and go and pass packet communication data.
-
-
Accepts AT commands but it does not pass data.
-
-
Accepts OBEX frame which is used to exchange telephone book, etc.
-
, - vendor2
-
Vendor specific data may be passed.
-
-
When an interface is recognized by the system but not used, the interface - will be set to this mode.
-
-
When an interface is not yet negotiated, the interface is in this - mode.
-
-
-
-

-

Devices supported by the ufoma driver - include:

-

-
    -
  • SHARP FOMA SH902i
    • -
  • KYOCERA PHS AH-K3001V (a.k.a Kyopon)
    • -
  • SANYO Vodafone3G V801SA
    • -
-
-
-

-

Specification can be found at:

-

-
    -
  • http://www.nttdocomo.co.jp/corporate/technology/document/foma/index.html
    • -
  • http://www.mcpc-jp.org/doclist.htm
    • -
-

tty(4), ucom(4), - umodem(4), usb(4)

-
-
-

-

The ufoma driver appeared in - FreeBSD 7.0, partly derived from the - umodem(4) code.

-
-
-

-

Interfaces with multiplexed commands and data and interfaces with - commands only are supported.

-
-
- - - - - -
November 20, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/ufshci.4 3.html b/static/freebsd/man4/ufshci.4 3.html deleted file mode 100644 index a781c93a..00000000 --- a/static/freebsd/man4/ufshci.4 3.html +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - -
UFSHCI(4)Device Drivers ManualUFSHCI(4)
-
-
-

-

ufshci — Universal - Flash Storage Host Controller Interface driver

-
-
-

-

To compile this driver into the kernel, place the following line - in the kernel configuration file:

-
device ufshci
-

Or, to load the driver as a module at boot, place the following - line in loader.conf(5):

-
-
ufshci_load="YES"
-
-
-
-

-

Universal Flash Storage (UFS) is a low-power, high-performance - storage standard composed of a host controller and a single target - device.

-

The driver currently provides:

-
    -
  • Initialization of the host controller and the target device
    • -
  • Handling of UFS Interconnect (UIC) commands
    • -
  • Support for UTP Transfer Requests (UTR) and UTP Task Management Requests - (UTMR)
    • -
  • Support for the SCSI command set
    • -
  • Operation in the legacy single-doorbell queue mode
    • -
  • Support for the PCI Express bus
    • -
-

After initialization, the controller is registered with the - cam(4) subsystem and its logical unit appears as the - device node /dev/daX.

-

The driver is under active development; upcoming work includes - full UFS 4.1 feature coverage, additional power-management modes, and - ACPI/FDT-based attach support.

-
-
-

-

The ufshci driver supports both host - controllers and devices implementing the Universal Flash Storage Host - Controller Interface 4.1 and earlier.

-
-
-

-

The ufshci driver currently operates with - a single doorbell (one I/O-queue), so any tunables that change the queue - count are ignored. When Multi-Circular Queue (MCQ) support is added and - multiple queues become available, the following queue count tunable values - will take effect:

-

To force a single I/O queue pair shared by all CPUs, set the - following tunable value in loader.conf(5):

-
-
hw.ufshci.per_cpu_io_queues=0
-
-

To assign more than one CPU per I/O queue pair, thereby reducing - the number of MSI-X vectors consumed by the device, set the following - tunable value in loader.conf(5):

-
-
hw.ufshci.min_cpus_per_ioq=X
-
-

To change the I/O command timeout value (in seconds), set the - following tunable value in loader.conf(5):

-
-
hw.ufshci.timeout_period=X
-
-

To change the I/O command retry count, set the following tunable - value in loader.conf(5):

-
-
hw.ufshci.retry_count=X
-
-

To force the driver to use legacy INTx interrupts, set the - following tunable value in loader.conf(5): -
- (Note: until MCQ support is available the driver always uses legacy INTx, so - this value effectively remains 1)

-
-
hw.ufshci.force_intx=1
-
-
-
-

-

The following controller-level sysctl(8) nodes - are currently implemented:

-
-
dev.ufshci.0.num_failures
-
(R) Number of command failures for the entire controller.
-
dev.ufshci.0.num_retries
-
(R) Number of command retries for the entire controller.
-
dev.ufshci.0.num_intr_handler_calls
-
(R) Number of times the interrupt handler has been called.
-
dev.ufshci.0.num_cmds
-
(R) Total number of commands issued by the controller.
-
dev.ufshci.0.timeout_period
-
(RW) Configured timeout period (in seconds).
-
dev.ufshci.0.cap
-
(R) Host controller capabilities register value.
-
dev.ufshci.0.num_io_queues
-
(R) Number of I/O-queue pairs.
-
dev.ufshci.0.io_queue_mode
-
(R) Indicates single doorbell mode or multi circular queue mode.
-
dev.ufshci.0.minor_version
-
(R) Host controller minor version.
-
dev.ufshci.0.major_version
-
(R) Host controller major version.
-
dev.ufshci.0.wb_enabled
-
(R) WriteBooster enable/disable.
-
dev.ufshci.0.wb_flush_enabled
-
(R) WriteBooster flush enable/disable.
-
dev.ufshci.0.wb_buffer_type
-
(R) WriteBooster type.
-
dev.ufshci.0.wb_buffer_size_mb
-
(R) WriteBooster buffer size in MB.
-
dev.ufshci.0.wb_user_space_config_option
-
(R) WriteBooster preserve user space mode.
-
dev.ufshci.0.auto_hibernation_supported
-
(R) Device auto hibernation support.
-
dev.ufshci.0.auto_hibernate_idle_timer_value
-
(R) Auto-Hibernate Idle Timer Value (in microseconds).
-
dev.ufshci.0.power_mode_supported
-
(R) Device power mode support.
-
dev.ufshci.0.power_mode
-
(R) Current device power mode.
-
dev.ufshci.0.tx_rx_power_mode
-
(R) Current TX/RX PA_PWRMode value.
-
dev.ufshci.0.max_tx_lanes
-
(R) Maximum available TX data lanes.
-
dev.ufshci.0.max_rx_lanes
-
(R) Maximum available RX data lanes.
-
dev.ufshci.0.tx_lanes
-
(R) Active TX data lanes.
-
dev.ufshci.0.rx_lanes
-
(R) Active RX data lanes.
-
dev.ufshci.0.max_rx_hs_gear
-
(R) Maximum available RX HS gear.
-
dev.ufshci.0.hs_gear
-
(R) Active HS gear.
-
dev.ufshci.0.utmrq.num_failures
-
(R) Number of failed UTP task-management requests.
-
dev.ufshci.0.utmrq.num_retries
-
(R) Number of retried UTP task-management requests.
-
dev.ufshci.0.utmrq.num_intr_handler_calls
-
(R) Number of interrupt handler calls caused by UTP task-management - requests.
-
dev.ufshci.0.utmrq.num_cmds
-
(R) Number of UTP task-management requests issued.
-
dev.ufshci.0.utmrq.cq_head
-
(R) Current location of the UTP task-management completion queue - head.
-
dev.ufshci.0.utmrq.sq_tail
-
(R) Current location of the UTP task-management submission queue - tail.
-
dev.ufshci.0.utmrq.sq_head
-
(R) Current location of the UTP task-management submission queue - head.
-
dev.ufshci.0.utmrq.num_trackers
-
(R) Number of trackers in the UTP task-management queue.
-
dev.ufshci.0.utmrq.num_entries
-
(R) Number of entries in the UTP task-management queue.
-
dev.ufshci.0.ioq.0.num_failures
-
(R) Number of failed UTP transfer requests.
-
dev.ufshci.0.ioq.0.num_retries
-
(R) Number of retried UTP transfer requests.
-
dev.ufshci.0.ioq.0.num_intr_handler_calls
-
(R) Number of interrupt-handler calls caused by UTP transfer - requests.
-
dev.ufshci.0.ioq.0.num_cmds
-
(R) Number of UTP transfer requests issued.
-
dev.ufshci.0.ioq.0.cq_head
-
(R) Current location of the UTP transfer completion queue head.
-
dev.ufshci.0.ioq.0.sq_tail
-
(R) Current location of the UTP transfer submission queue tail.
-
dev.ufshci.0.ioq.0.sq_head
-
(R) Current location of the UTP transfer submission queue head.
-
dev.ufshci.0.ioq.0.num_trackers
-
(R) Number of trackers in the UTP transfer queue.
-
dev.ufshci.0.ioq.0.num_entries
-
(R) Number of entries in the UTP transfer queue.
-
-
-
-

-

cam(4), pci(4), - disk(9)

-
-
-

-

The ufshci driver first appeared in - FreeBSD 15.0.

-
-
-

-

The ufshci driver was developed by Samsung - Electronics and originally written by Jaeyoon Choi - <j_yoon.choi@samsung.com>.

-

This manual page was written by Jaeyoon - Choi - <j_yoon.choi@samsung.com>.

-
-
- - - - - -
July 17, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/uftdi.4 4.html b/static/freebsd/man4/uftdi.4 4.html deleted file mode 100644 index 606decd2..00000000 --- a/static/freebsd/man4/uftdi.4 4.html +++ /dev/null @@ -1,234 +0,0 @@ - - - - - - -
UFTDI(4)Device Drivers ManualUFTDI(4)
-
-
-

-

uftdi — Future - Technology Devices International USB to serial UART driver

-
-
-

-

device usb -
- device ucom -
- device uftdi

-

In rc.conf(5): -
- kld_list="uftdi"

-

In sysctl.conf(5): -
- hw.usb.uftdi.debug=1 -
- hw.usb.uftdi.skip_jtag_interfaces=0

-
-
-

-

The uftdi driver supports FTDI USB to - serial UART devices. If the appropriate hardware is detected, the driver - will be loaded automatically by devmatch(8). To load the - driver manually, add it to the kld_list in - rc.conf(5), or use kldload(8) at - runtime. The device is accessed through the ucom(4) driver - which makes it behave like a tty(4).

-

Call out through this interface with applications like - cu(1) or tip(1).

-
-
-

-

The uftdi driver supports the following - USB to serial UART controllers:

-

-
    -
  • FTDI FT4232H
    • -
  • FTDI FT232R
    • -
  • FTDI FT230X
    • -
  • FTDI FT2232H
    • -
  • FTDI FT2232D
    • -
  • FTDI FT2232C
    • -
  • FTDI FT8U232BM
    • -
  • FTDI FT8U232AM
    • -
  • FTDI FT8U100AX
    • -
-
-
-

-

These settings can be entered in the loader(8) - prompt, set in loader.conf(5), - sysctl.conf(5), or changed at runtime with - sysctl(8):

-
-
hw.usb.uftdi.debug
-
Enable debugging messages, default - ‘0’
-
hw.usb.uftdi.skip_jtag_interfaces
-
Ignore JTAG interfaces, default - ‘1’
-
-
-
-

-

Many of the supported chips provide additional functionality such - as bitbang mode and the MPSSE engine for serial bus emulation. The - uftdi driver provides access to that functionality - with the following ioctl(2) calls, defined in - <dev/usb/uftdiio.h>:

-
-
- (int)
-
Reset the channel to its default configuration, flush RX and TX - FIFOs.
-
- (int)
-
Flush the RX FIFO.
-
- (int)
-
Flush the TX FIFO.
-
- (struct uftdi_bitmode)
-
Put the channel into the operating mode specified in - mode, and set the pins indicated by ones in - iomask to output mode. The - mode must be one of the - uftdi_bitmodes values. Setting - mode to UFTDI_BITMODE_NONE - returns the channel to standard UART mode. -
- 
enum uftdi_bitmodes
-{
-	UFTDI_BITMODE_ASYNC = 0,
-	UFTDI_BITMODE_MPSSE = 1,
-	UFTDI_BITMODE_SYNC = 2,
-	UFTDI_BITMODE_CPU_EMUL = 3,
-	UFTDI_BITMODE_FAST_SERIAL = 4,
-	UFTDI_BITMODE_CBUS = 5,
-	UFTDI_BITMODE_NONE = 0xff,
-};
-
-struct uftdi_bitmode
-{
-	uint8_t mode;
-	uint8_t iomask;
-};
-
-

Manuals and application notes published by FTDI describe these - modes in detail. To use most of these modes, you first put the channel - into the desired mode, then you read(2) and - write(2) data which either reflects pin state or is - interpreted as MPSSE commands and parameters, depending on the mode.

-
-
- (struct uftdi_bitmode)
-
Return the current bitbang mode in the mode member, - and the state of the DBUS0..DBUS7 pins at the time of the call in the - iomask member. The pin state can be read while the - chip is in any mode, including UFTDI_BITMODE_NONE - (UART) mode.
-
- (int)
-
Set the character which is inserted into the buffer to mark the point of - an error such as FIFO overflow.
-
- (int)
-
Set the character which causes a partial FIFO full of data to be returned - immediately even if the FIFO is not full.
-
- (int)
-
Set the amount of time to wait for a full FIFO, in milliseconds. If more - than this much time elapses without receiving a new character, any - characters in the FIFO are returned.
-
- (int)
-
Get the current value of the latency timer.
-
- (int)
-
Get the hardware revision number. This is the - bcdDevice value from the - usb_device_descriptor.
-
- (struct uftdi_eeio)
-
Read one or more words from the configuration eeprom. The FTDI chip - performs eeprom I/O in 16-bit words. Set offset and - length to values evenly divisible by two before the - call, and the data array will contain the requested - values from eeprom after the call. -
- 
struct uftdi_eeio
-{
-	uint16_t offset;
-	uint16_t length;
-	uint16_t data[64];
-};
-
-

The FT232R chip has an internal eeprom. An external serial - eeprom is optional on other FTDI chips. The eeprom may contain 64, 128, - or 256 words, depending on the part used. Multiple calls may be needed - to read or write the larger parts. When no eeprom is present, all words - in the returned data are 0xffff. An erased eeprom also reads as all - 0xffff.

-
-
- (struct uftdi_eeio)
-
Write one or more words to the configuration eeprom. The - uftdi_eeio values are as described for - UFTDIIOC_READ_EEPROM. -

The FTDI chip does a blind write to the eeprom, and - it will appear to succeed even when no eeprom is present. To ensure a - good write you must read back and verify the data. It is - necessary to - erase before writing. Any position within the eeprom can be overwritten - at any time.

-
-
- (int)
-
Erase the entire eeprom. This is useful primarily for test and debugging, - as there is no need to erase before writing. To help prevent accidental - erasure caused by calling the wrong ioctl, you must pass the special value - UFTDI_CONFIRM_ERASE as the argument to this - ioctl.
-
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

cu(1), tty(4), - ucom(4), usb(4)

-
-
-

-

The uftdi driver appeared in - FreeBSD 4.8 from NetBSD - 1.5.

-
-
- - - - - -
June 25, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ugen.4 3.html b/static/freebsd/man4/ugen.4 3.html deleted file mode 100644 index ad797d0f..00000000 --- a/static/freebsd/man4/ugen.4 3.html +++ /dev/null @@ -1,258 +0,0 @@ - - - - - - -
UGEN(4)Device Drivers ManualUGEN(4)
-
-
-

-

ugen — USB generic - device support

-
-
-

- - - - - -
ugenis integrated into the usb(4) kernel module.
-
-
-

-

The ugen driver provides support for all - USB devices that do not have a special driver. It supports access to all - parts of the device, but not in a way that is as convenient as a special - purpose driver.

-

There can be up to 127 USB devices connected to a USB bus. Each - USB device can have up to 16 endpoints. Each of these endpoints will - communicate in one of four different modes: control, isochronous, bulk, or - interrupt. Each of the endpoints will have a different device node. The four - least significant bits in the minor device number determine which endpoint - the device accesses, and the rest of the bits determine which USB - device.

-

If an endpoint address is used both for input and output, the - device can be opened for both read or write.

-

To find out which endpoints exist, there are a series of - ioctl(2) operations on the control endpoint that return - the USB descriptors of the device, configurations, interfaces, and - endpoints.

-

The control transfer mode can only happen on the control endpoint - which is always endpoint 0. The control endpoint accepts a request and may - respond with an answer to such a request. Control requests are issued by - ioctl(2) calls.

-

The bulk transfer mode can be in or out depending on the endpoint. - To perform I/O on a bulk endpoint read(2) and - write(2) should be used. All I/O operations on a bulk - endpoint are unbuffered.

-

The interrupt transfer mode can be in or out depending on the - endpoint. To perform I/O on an interrupt endpoint read(2) - and write(2) should be used. A moderate amount of - buffering is done by the driver.

-

All endpoints handle the following ioctl(2) - calls:

-
-
- (int)
-
Allow short read transfer. Normally a transfer from the device which is - shorter than the request specified is reported as an error.
-
- (int)
-
Set the timeout on the device operations The time is specified in - milliseconds. The value 0 is used to indicate that there is no - timeout.
-
-

The control endpoint (endpoint 0) handles the following - ioctl(2) calls:

-
-
- (int)
-
Get the device configuration number.
-
- (int)
-
Set the device into the given configuration number. -

This operation can only be performed when the control endpoint - is the sole open endpoint.

-
-
- (struct usb_alt_interface)
-
Get the alternative setting number for the interface with the given index. - The uai_config_index is ignored in this call. -
- 
struct usb_alt_interface {
-	int	uai_config_index;
-	int	uai_interface_index;
-	int	uai_alt_no;
-};
-
-
-
- (struct usb_alt_interface)
-
Set the alternative setting to the given number in the interface with the - given index. The uai_config_index is ignored in this - call. -

This operation can only be performed when no endpoints for the - interface are open.

-
-
- (struct usb_alt_interface)
-
Return the number of different alternate settings in the - uai_alt_no field.
-
- (usb_device_descriptor_t)
-
Return the device descriptor.
-
- (struct usb_config_desc)
-
Return the descriptor for the configuration with the given index. For - convenience, the current configuration can be specified by - USB_CURRENT_CONFIG_INDEX. -
- 
struct usb_config_desc {
-	int	ucd_config_index;
-	usb_config_descriptor_t ucd_desc;
-};
-
-
-
- (struct usb_interface_desc)
-
Return the interface descriptor for an interface specified by its - configuration index, interface index, and alternative index. For - convenience, the current alternative can be specified by - USB_CURRENT_ALT_INDEX. -
- 
struct usb_interface_desc {
-	int	uid_config_index;
-	int	uid_interface_index;
-	int	uid_alt_index;
-	usb_interface_descriptor_t uid_desc;
-};
-
-
-
- (struct usb_endpoint_desc)
-
Return the endpoint descriptor for the endpoint specified by its - configuration index, interface index, alternative index, and endpoint - index. -
- 
struct usb_endpoint_desc {
-	int	ued_config_index;
-	int	ued_interface_index;
-	int	ued_alt_index;
-	int	ued_endpoint_index;
-	usb_endpoint_descriptor_t ued_desc;
-};
-
-
-
- (struct usb_full_desc)
-
Return all the descriptors for the given configuration. -
- 
struct usb_full_desc {
-	int	ufd_config_index;
-	u_int	ufd_size;
-	u_char	*ufd_data;
-};
-
- The ufd_data field should point to a memory area of - the size given in the ufd_size field. The proper - size can be determined by first issuing a - USB_GET_CONFIG_DESC and inspecting the - wTotalLength field.
-
- (struct usb_string_desc)
-
Get a string descriptor for the given language ID and string index. -
- 
struct usb_string_desc {
-	int	usd_string_index;
-	int	usd_language_id;
-	usb_string_descriptor_t usd_desc;
-};
-
-
-
- (struct usb_ctl_request)
-
Send a USB request to the device on the control endpoint. Any data sent - to/from the device is located at ucr_data. The size - of the transferred data is determined from the - ucr_request. The ucr_addr - field is ignored in this call. The ucr_flags field - can be used to flag that the request is allowed to be shorter than the - requested size, and ucr_actlen will contain the - actual size on completion. -
- 
struct usb_ctl_request {
-	int	ucr_addr;
-	usb_device_request_t ucr_request;
-	void	*ucr_data;
-	int	ucr_flags;
-#define USBD_SHORT_XFER_OK	0x04	/* allow short reads */
-	int	ucr_actlen;		/* actual length transferred */
-};
-
- This is a dangerous operation in that it can perform arbitrary operations on - the device. Some of the most dangerous (e.g., changing the device address) - are not allowed.
-
- (struct usb_device_info)
-
Get an information summary for the device. This call will not issue any - USB transactions.
-
-

Note that there are two different ways of addressing - configurations, interfaces, alternatives, and endpoints: by index or by - number. The index is the ordinal number (starting from 0) of the descriptor - as presented by the device. The number is the respective number of the - entity as found in its descriptor. Enumeration of descriptors uses the - index, getting and setting typically uses numbers.

-

Example: all endpoints (except the control endpoint) for the - current configuration can be found by iterating the - interface_index from 0 to - config_desc->bNumInterface-1 and for each of these, - iterating the endpoint_index from 0 to - interface_desc->bNumEndpoints. The - config_index should be set to - USB_CURRENT_CONFIG_INDEX and - alt_index should be set to - USB_CURRENT_ALT_INDEX.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.ugen.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/usb/B.D.E
-
Endpoint E of device D at bus - B.
-
/dev/ugenB.D
-
Control endpoint, 0, of device D at bus - B.
-
-
-
-

-

usb(4)

-
-
-

-

The ugen driver appeared in - NetBSD 1.4.

-
-
- - - - - -
May 14, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ugold.4 3.html b/static/freebsd/man4/ugold.4 3.html deleted file mode 100644 index 22eb29f7..00000000 --- a/static/freebsd/man4/ugold.4 3.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - -
UGOLD(4)Device Drivers ManualUGOLD(4)
-
-
-

-

ugold — TEMPer - gold HID thermometer

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device usb -
-device hid -
-device ugold
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ugold_load="YES"
-
-
-
-

-

The ugold driver provides support for - pcsensors TEMPer gold devices.

-

The driver possesses a collection of sensor values which are made - available through the sysctl(8) interface.

-
-
-

-

The following devices are supported by the - ugold driver:

-

-
    -
  • RDing TEMPer1V1.2
    • -
-
-
-

-

usb(4), sysctl(8)

-
-
- - - - - -
June 11, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/uhci.4 4.html b/static/freebsd/man4/uhci.4 4.html deleted file mode 100644 index 0c1c65e0..00000000 --- a/static/freebsd/man4/uhci.4 4.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - -
UHCI(4)Device Drivers ManualUHCI(4)
-
-
-

-

uhci — UHCI USB - Host Controller driver

-
-
-

-

device uhci

-
-
-

-

The uhci driver provides support for - UHCI-type PCI based USB controllers.

-
-
-

-

The uhci driver supports all UHCI v1.1 - compliant controllers including:

-

-
    -
  • Intel 82371AB/EB (PIIX4)
    • -
  • Intel 82371SB (PIIX3)
    • -
  • VIA 83C572
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.uhci.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

ehci(4), ohci(4), - xhci(4)

-
-
-

-

The uhci device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The uhci driver was written by - Lennart Augustsson - <augustss@carlstedt.se> - for the NetBSD project.

-
-
- - - - - -
April 24, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/uhid.4 3.html b/static/freebsd/man4/uhid.4 3.html deleted file mode 100644 index 59f5ad9d..00000000 --- a/static/freebsd/man4/uhid.4 3.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - -
UHID(4)Device Drivers ManualUHID(4)
-
-
-

-

uhid — USB generic - HID support

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device uhid -
-device hid -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uhid_load="YES"
-
-
-
-

-

The uhid driver provides support for all - HID (Human Interface Device) interfaces in USB devices that do not have a - special driver.

-

The device handles the following ioctl(2) - calls:

-
-
- (int)
-
Get the report identifier used by this HID report.
-
- (struct usb_gen_descriptor)
-
Get the HID report descriptor. Copies a maximum of - ugd_maxlen bytes of the report descriptor data into - the memory specified by ugd_data. Upon return - ugd_actlen is set to the number of bytes copied. - Using this descriptor the exact layout and meaning of data to/from the - device can be found. The report descriptor is delivered without any - processing. -
- 
struct usb_gen_descriptor {
-	void   *ugd_data;
-	uint16_t ugd_maxlen;
-	uint16_t ugd_actlen;
-	uint8_t	ugd_report_type;
-	...
-};
-
-
-
- (int)
-
Sets the device in a mode where each read(2) will return - the current value of the input report. Normally a - read(2) will only return the data that the device - reports on its interrupt pipe. This call may fail if the device does not - support this feature.
-
- (struct usb_gen_descriptor)
-
Get a report from the device without waiting for data on the interrupt - pipe. Copies a maximum of ugd_maxlen bytes of the - report data into the memory specified by ugd_data. - Upon return ugd_actlen is set to the number of bytes - copied. The ugd_report_type field indicates which - report is requested. It should be - UHID_INPUT_REPORT, - UHID_OUTPUT_REPORT, or - UHID_FEATURE_REPORT. This call may fail if the - device does not support this feature.
-
- (struct usb_gen_descriptor)
-
Set a report in the device. The ugd_report_type - field indicates which report is to be set. It should be - UHID_INPUT_REPORT, - UHID_OUTPUT_REPORT, or - UHID_FEATURE_REPORT. The value of the report is - specified by the ugd_data and the - ugd_maxlen fields. This call may fail if the device - does not support this feature.
-
- (struct usb_device_info)
-
Returns information about the device, like USB vendor ID and USB product - ID. This call will not issue any USB transactions. Also refer to - ugen(4).
-
-

Use read(2) to get data from the device. Data - should be read in chunks of the size prescribed by the report - descriptor.

-

Use write(2) to send data to the device. Data - should be written in chunks of the size prescribed by the report - descriptor.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.uhid.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/uhid?
-
 
-
-
-
-

-

usbhidctl(1), usb(4)

-
-
-

-

The uhid driver appeared in - NetBSD 1.4. This manual page was adopted from - NetBSD by Tom Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
- - - - - -
October 31, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/uhso.4 3.html b/static/freebsd/man4/uhso.4 3.html deleted file mode 100644 index 743700f5..00000000 --- a/static/freebsd/man4/uhso.4 3.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - -
UHSO(4)Device Drivers ManualUHSO(4)
-
-
-

-

uhso — support for - several HSxPA devices from Option N.V.

-
-
-

-

The module can be loaded at boot time by placing the following - line in loader.conf(5):

-
-
uhso_load="YES"
-
-
-
-

-

The uhso driver provides support for - several HSxPA devices from Option N.V. that are based on their packet - interface. Each device has a set of serial ports and a raw IP packet - interface. The serial ports of the device are accessed through the - ucom(4) driver which makes them behave like - tty(4) devices. The packet interface is exposed as a - network interface.

-

Establishing a connection on the packet interface is achieved by - using the proprietary AT commands - “AT_OWANCALL” and - “AT_OWANDATA” on any of the available - serial ports.

-

The network interface must be configured manually using the data - obtain from these calls.

-

Each device usually have at least two or more serial ports, their - individual purpose can be identified through sysctl(8). - Ports identified as “Modem” features a normal modem interface - that can be used with PPP. Ports identified as “Diagnostic” - uses a proprietary binary interface used for firmware upgrades, this port - does not have a AT command interface and can not be used to control the - device. Other ports features an AT command interface that can be used for - normal device control.

-
-
-

-

The uhso driver should work with most - devices from Option. The following devices have been verified to work

-

-
    -
  • Option GlobeSurfer iCON 7.2 (new firmware)
    • -
  • Option GlobeTrotter Max 7.2 (new firmware)
    • -
  • Option iCON 225
    • -
  • Option iCON 452
    • -
  • Option iCON 505
    • -
-

The device features a mass storage device referred to as - “Zero-CD” which contains drivers for Microsoft Windows; this - is the default mode for the device. The uhso driver - automatically switches the device from “Zero-CD” mode to modem - mode. This behavior can be disabled by setting - hw.usb.uhso.auto_switch to 0 using - sysctl(8).

-
-
-

-
-
/dev/cuaU?.?
-
 
-
-
-
-

-

Establishing a packet interface connection using the AT command - interface available at one of the serial ports

-
-
AT+CGDCONT=1,,"apn.provider"
-AT_OWANCALL=1,1,1
-OK
-_OWANCALL=1,1
-
-AT_OWANDATA=1
-_OWANDATA: 1, 10.11.12.13, 0.0.0.0, 10.2.3.4, 10.2.3.5, \
-	0.0.0.0, 0.0.0.0, 72000
-
-

Configuring the interface

-
-
ifconfig uhso0 10.11.12.13 up
-route add default -interface uhso0
-echo "nameserver 10.2.3.4" > /etc/resolv.conf
-echo "nameserver 10.2.3.5" >> /etc/resolv.conf
-
-

The connection can be terminated with

-
-
AT_OWANCALL=1,0,1
-
-
-
-

-

uhsoctl(1), ucom(4), - usb(4)

-
-
-

-

The uhso driver was written by - Fredrik Lindberg - <fli@shapeshifter.se>.

-
-
- - - - - -
July 20, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/uipaq.4 4.html b/static/freebsd/man4/uipaq.4 4.html deleted file mode 100644 index 74edbace..00000000 --- a/static/freebsd/man4/uipaq.4 4.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
UIPAQ(4)Device Drivers ManualUIPAQ(4)
-
-
-

-

uipaq — USB - support for iPAQ units

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device uipaq
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uipaq_load="YES"
-
-
-
-

-

The uipaq driver provides support for the - USB serial emulation provided by the iPAQ devices.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-

The uipaq driver supports the following - iPAQ devices:

-

-
    -
  • ASUS P535 PDA
    • -
  • Casio BE300 PDA
    • -
  • Compaq IPaq PocketPC
    • -
  • HP Jornada 568
    • -
  • HP iPAQ 22xx/Jornada 548
    • -
  • HTC PPC6700 Modem
    • -
  • HTC Smart Phone
    • -
  • HTC Winmobile
    • -
  • Sharp W-ZERO3 ES Spart Phone
    • -
  • Most Windows CE based phones
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The FreeBSD support was imported from - NetBSD for FreeBSD 7.0. - NetBSD added support in NetBSD - 4.0 and it was imported from OpenBSD 3.8.

-
-
- - - - - -
April 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/ukbd.4 3.html b/static/freebsd/man4/ukbd.4 3.html deleted file mode 100644 index e1346353..00000000 --- a/static/freebsd/man4/ukbd.4 3.html +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - -
UKBD(4)Device Drivers ManualUKBD(4)
-
-
-

-

ukbd — USB - keyboard driver

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ukbd -
-device hid -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ukbd_load="YES"
-
-
-
-

-

The ukbd driver provides support for - keyboards that attach to the USB port. usb(4) and one of - uhci(4) or ohci(4) must be configured in - the kernel as well.

-
-
-

-

By default, the keyboard subsystem does not create the appropriate - devices yet. Make sure you reconfigure your kernel with the following option - in the kernel config file:

-

-
options KBD_INSTALL_CDEV
-

If both an AT keyboard USB keyboards are used at the same time, - the AT keyboard will appear as kbd0 in - /dev. The USB keyboards will be - kbd1, kbd2, etc. You can see - some information about the keyboard with the following command:

-

-
kbdcontrol -i < - /dev/kbd1
-

or load a keymap with

-

-
kbdcontrol -l keymaps/pt.iso < - /dev/kbd1
-

See kbdcontrol(1) for more possible options.

-

You can swap console keyboards by using the command

-

-
kbdcontrol -k /dev/kbd1
-

From this point on, the first USB keyboard will be the keyboard to - be used by the console.

-

If you want to use a USB keyboard as your default and - not use an AT keyboard at all, you will have to remove the - device atkbd line from the kernel configuration - file. Because of the device initialization order, the USB keyboard will be - detected the - console driver initializes itself and you have to explicitly tell the - console driver to use the existence of the USB keyboard. This can be done in - one of the following two ways.

-

Run the following command as a part of system initialization:

-

-
kbdcontrol -k /dev/kbd0 < - /dev/ttyv0 > /dev/null
-

(Note that as the USB keyboard is the only keyboard, it is - accessed as /dev/kbd0) or otherwise tell the console - driver to periodically look for a keyboard by setting a flag in the kernel - configuration file:

-

-
device sc0 at isa? flags - 0x100
-

With the above flag, the console driver will try to detect any - keyboard in the system if it did not detect one while it was initialized at - boot time.

-
-
-

-
options KBD_INSTALL_CDEV
-

Make the keyboards available through a character device in - /dev.

-

-
options UKBD_DFLT_KEYMAP
-
makeoptions - UKBD_DFLT_KEYMAP=fr.iso
-

The above lines will put the French ISO keymap in the ukbd driver. - You can specify any keymap in - /usr/share/syscons/keymaps or - /usr/share/vt/keymaps (depending on the console - driver being used) with this option.

-

-
options - KBD_DISABLE_KEYMAP_LOADING
-

Do not allow the user to change the keymap.

-

-
options KBD_DELAY1=200
-

Set the keyboard initial key repeat delay.

-

-
options KBD_DELAY2=15
-

Set the keyboard key repeat delay.

-

Note that these options also affect the AT keyboard driver, - atkbd(4).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.ukbd.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
hw.usb.ukbd.apple_swap_cmd_opt
-
Swap the Command & Option keys on Apple keyboards if set to 1. Default - is 0.
-
hw.usb.ukbd.apple_swap_cmd_ctl
-
Swap the Command & Control keys on Apple keyboards if set to 1. - Default is 0.
-
hw.usb.ukbd.apple_fn_mode
-
Direct access to media keys without holding Fn if set to 1. Default is - 0.
-
hw.usb.ukbd.no_leds
-
Disables setting of keyboard LEDs if set to 1. Default is 0.
-
-
-
-

-
-
/dev/kbd*
-
blocking device nodes
-
-
-
-

-
device ukbd
-

Add the ukbd driver to the kernel.

-
-
-

-

kbdcontrol(1), ohci(4), - syscons(4), uhci(4), - usb(4), vt(4), - config(8)

-
-
-

-

The ukbd driver was written by - Lennart Augustsson - <augustss@cs.chalmers.se> - for NetBSD and was substantially rewritten for - FreeBSD by Kazutaka YOKOTA - <yokota@zodiac.mech.utsunomiya-u.ac.jp>.

-

This manual page was written by Nick Hibma - <n_hibma@FreeBSD.org> - with a large amount of input from Kazutaka YOKOTA - <yokota@zodiac.mech.utsunomiya-u.ac.jp>.

-
-
- - - - - -
April 23, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/uled.4 4.html b/static/freebsd/man4/uled.4 4.html deleted file mode 100644 index aba838b7..00000000 --- a/static/freebsd/man4/uled.4 4.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - -
ULED(4)Device Drivers ManualULED(4)
-
-
-

-

uled — USB LED - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device uled -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uled_load="YES"
-
-
-
-

-

The uled driver provides support for Dream - Cheeky WebMail Notifier and ThingM blink(1) notification LED.

-

Subsequently, the /dev/uled0 device can be - used by userland applications.

-
-
-

-

The following ioctl(2) commands can be performed - on /dev/uled0, which are defined in - <dev/usb/uled_ioctl.h>:

-
-
-
The command returns LED colors with values for RGB. This - ioctl(2) takes the following structure: -
- 
struct uled_color {
-	uint8_t	red;
-	uint8_t	green;
-	uint8_t	blue;
-};
-
-
-
-
The command sets LED colors with values for RGB. It uses the same - structure as above.
-
-
-
-

-
-
/dev/uled0
-
blocking device node
-
-
-
-

-

ohci(4), uhci(4), - usb(4)

-
-
-

-

The uled driver was written by - Kevin Lo - <kevlo@FreeBSD.org>.

-
-
- - - - - -
March 31, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ulpt.4 3.html b/static/freebsd/man4/ulpt.4 3.html deleted file mode 100644 index 1be25e34..00000000 --- a/static/freebsd/man4/ulpt.4 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
ULPT(4)Device Drivers ManualULPT(4)
-
-
-

-

ulpt — USB printer - support

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device ulpt
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ulpt_load="YES"
-
-
-
-

-

The ulpt driver provides support for USB - printers that follow the printer bi- or uni-directional protocol. The bits - in the minor number select various features of the driver.

- - - - - - - - - -
64Do not initialize (reset) the device on the port.
-

Some printers cannot handle the reset on open; in case of problems - try the unlpt device.

-
-
-

-

The ulpt driver provides support for USB - printers and parallel printer conversion cables, including the - following:

-

-
    -
  • ATen parallel printer adapter
    • -
  • Belkin F5U002 parallel printer adapter
    • -
  • Canon BJ F850, S600
    • -
  • Canon LBP-1310, 350
    • -
  • Entrega USB-to-parallel printer adapter
    • -
  • Hewlett-Packard HP Deskjet 3420 (P/N: C8947A #ABJ)
    • -
  • Oki Data MICROLINE ML660PS
    • -
  • Seiko Epson PM-900C, 880C, 820C, 730C
    • -
-
-
-

-
-
/dev/ulpt?
-
device with reset
-
/dev/unlpt?
-
device without reset
-
-
-
-

-

lpt(4), usb(4)

-
-
-

-

The ulpt driver appeared in - NetBSD 1.4. This manual page was adopted from - NetBSD by Tom Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
- - - - - -
November 22, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/umass.4 3.html b/static/freebsd/man4/umass.4 3.html deleted file mode 100644 index 89a51751..00000000 --- a/static/freebsd/man4/umass.4 3.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - -
UMASS(4)Device Drivers ManualUMASS(4)
-
-
-

-

umass — USB Mass - Storage Devices driver

-
-
-

-

device da -
- device scbus -
- device pass -
- device usb -
- device umass

-

In loader.conf(5): -
- umass_load

-
-
-

-

The umass driver provides support for Mass - Storage devices that attach to the USB interface.

-

If the appropriate hardware is detected, the driver will be loaded - automatically by devmatch(8). To load the driver manually - at boot time, use the umass_load command at the - loader(8) prompt, or add it to - loader.conf(5).

-

To use the driver in a custom kernel, usb(4) and - at least one of uhci(4), ohci(4), - ehci(4), or xhci(4) must be configured - in the kernel. Additionally, since umass uses the - SCSI subsystem and sometimes acts as a SCSI device, it requires - da(4) and scbus(4) to be included in the - kernel.

-
-
-

-

The umass driver supports USB Mass Storage - devices such as:

-

-
    -
  • USB thumb drives
    • -
  • USB hard disk drives
    • -
  • USB floppy drives
    • -
-

The umass driver tries its best - to avoid issues with the drives, not all issues can be handled - automatically, so quirks may be necessary. See the - section of usb_quirk(4) for quirks for the - drives. The add_dev_quirk_vplh and - add_quirk commands of usbconfig(8) - can manage these dynamically. Quirks can be specified via tuables, as - described in usb_quirk(4).

-
-
-

-

Rescan all slots on a multi-slot flash reader, where the slots map - to separate LUNs on a single SCSI ID:

-
-
camcontrol rescan 0:0:0
-camcontrol rescan 0:0:1
-camcontrol rescan 0:0:2
-camcontrol rescan 0:0:3
-
-

Typically only the first slot will be enabled at boot time. This - assumes that the flash reader is the first SCSI bus in the system and has 4 - slots.

-
-
-

-

cfumass(4), ehci(4), - ohci(4), uhci(4), - usb(4), usb_quirk(4), - xhci(4), camcontrol(8), - usbconfig(8).

-
-
-

-

The umass driver appeared in - FreeBSD 4.3.

-
-
-

-

The umass driver was written by - MAEKAWA Masahide - <bishop@rr.iij4u.or.jp> - and Nick Hibma - <n_hibma@FreeBSD.org>.

-

This manual page was written by Nick Hibma - <n_hibma@FreeBSD.org>.

-
-
- - - - - -
November 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/umb.4 3.html b/static/freebsd/man4/umb.4 3.html deleted file mode 100644 index d064c898..00000000 --- a/static/freebsd/man4/umb.4 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
UMB(4)Device Drivers ManualUMB(4)
-
-
-

-

umb — USB Mobile - Broadband Interface Model (MBIM) cellular modem driver

-
-
-

-

device usb -
- device umb

-

In loader.conf(5): -
- umb_load="YES"

-
-
-

-

The umb driver provides support for USB - MBIM devices. If the appropriate hardware is detected, the driver will be - loaded automatically by devmatch(8). To load the driver - manually, load it in - loader.conf(5) or at the loader(8) - prompt.

-

MBIM devices establish connections via cellular networks such as - GPRS, UMTS, and LTE. They appear as a regular point-to-point network - interface, transporting raw IP frames.

-

Required configuration parameters like PIN and APN have to be set - with umbctl(8). Once the SIM card has been unlocked with - the correct PIN, it will remain in this state until the MBIM device is - power-cycled. In case the device is connected to an "always-on" - USB port, it may be possible to connect to a provider without entering the - PIN again even if the system was rebooted.

-
-
-

-

The umb driver should support any USB - device implementing MBIM, including the following cellular modems:

-

-
    -
  • Ericsson H5321gw and N5321gw
    • -
  • Fibocom L831-EAU
    • -
  • Medion Mobile S4222 (MediaTek OEM)
    • -
  • Sierra Wireless EM7345
    • -
  • Sierra Wireless EM7455
    • -
  • Sierra Wireless EM8805
    • -
  • Sierra Wireless MC8305
    • -
-
-
-

-

intro(4), netintro(4), - usb(4), ifconfig(8), - umbctl(8)

-

Universal Serial Bus - Communications Class Subclass Specification for Mobile Broadband Interface - Model, - http://www.usb.org/developers/docs/devclass_docs/MBIM10Errata1_073013.zip.

-
-
-

-

The umb device driver first appeared in - OpenBSD 6.0, NetBSD 9.0, and - FreeBSD 15.0.

-
-
-

-

The umb driver was written by - Gerhard Roth - <gerhard@openbsd.org> - and ported from OpenBSD by Pierre - Pronchery - <khorben@defora.org>.

-
-
-

-

The umb driver does not support IPv6.

-

Devices which fail to provide a conforming MBIM implementation - will probably be attached as some other driver, such as - u3g(4).

-
-
- - - - - -
September 3, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/umcs.4 4.html b/static/freebsd/man4/umcs.4 4.html deleted file mode 100644 index 625676b1..00000000 --- a/static/freebsd/man4/umcs.4 4.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - -
UMCS(4)Device Drivers ManualUMCS(4)
-
-
-

-

umcs — USB support - for serial adapters based on the MCS7820 and MCS7840 chips

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device umcs
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
umcs_load="YES"
-
-
-
-

-

The umcs driver provides support for - various multiport serial adapters based on the MosCom MCS7820 and MCS7840 - chips. They are 2- or 4-port adapters with full-featured 16550-compatible - UARTs and very flexible baud generators. Also, these chips support - RS422/RS485 and IrDA operations.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-

Different ports on device are presented as sub-units, like - /dev/ttyU0.1 and - /dev/ttyU0.2.

-
-
-

-

The umcs driver was tested on the - following adapters:

-

-
    -
  • ST Lab U-360 two-port serial USB adapter
    • -
  • ST Lab U-400 four-port serial USB adapter
    • -
-
-
-

-
-
/dev/ttyU*.*
-
for callin ports
-
/dev/ttyU*.*.init
-
 
-
/dev/ttyU*.*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*.*
-
for callout ports
-
/dev/cuaU*.*.init
-
 
-
/dev/cuaU*.*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The umcs driver appeared in ports since - December of 2010.

-
-
-

-

The umcs driver was written by - Lev Serebryakov - <lev@FreeBSD.org>.

-
-
-

-

This driver doesn't support access to any fine tunes of chip, like - RS522/RS485 mode, non-standard baudrates, etc.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/umct.4 4.html b/static/freebsd/man4/umct.4 4.html deleted file mode 100644 index 7fc42826..00000000 --- a/static/freebsd/man4/umct.4 4.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
UMCT(4)Device Drivers ManualUMCT(4)
-
-
-

-

umct — Magic - Control Technology USB-RS232 converter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device umct
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
umct_load="YES"
-
-
-
-

-

The umct driver provides support for USB - to RS-232 converters based on the Magic Control Technology USB-232 design. - These devices support most of the standard RS-232 features including baud - rates ranging from 300 to 115200 bits per second. However, neither hardware - nor software flow control seems to be supported.

-

Access to devices under this driver is via the - ucom(4) framework and device nodes.

-
-
-

-

The umct driver supports the following - adapters:

-

-
    -
  • Belkin F5U109
    • -
  • Belkin F5U409
    • -
  • D-Link DU-H3SP USB BAY Hub
    • -
  • Magic Control Technology USB-232
    • -
  • Sitecom USB-232
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The umct driver appeared in - FreeBSD 5.2. It is loosely based on the - ubsa(4) driver by Alexander Kabaev - <kan@FreeBSD.org> with - documentation from Wolfgang Grandeggar - <wolfgang@cec.ch>.

-
-
-

-

The umct driver was written by - Scott Long - <scottl@FreeBSD.org>.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/umodem.4 3.html b/static/freebsd/man4/umodem.4 3.html deleted file mode 100644 index f17a8b6a..00000000 --- a/static/freebsd/man4/umodem.4 3.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
UMODEM(4)Device Drivers ManualUMODEM(4)
-
-
-

-

umodem — USB - Communication Device Class serial (CDC ACM) driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device umodem
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
umodem_load="YES"
-
-
-
-

-

The umodem driver provides support for USB - modems and serial devices that implement the Communication Device Class - Abstract Control Model (CDC ACM). It also provides device-side CDC ACM - support. Supported modems are basically standard serial line modems, but - they are accessed via USB instead. They support a regular AT command set. - The commands can either be multiplexed with the data stream or handled - through separate pipes. In the latter case the AT commands have to be given - on a device separate from the data device.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-

Devices supported by the umodem driver - include:

-

-
    -
  • 3Com 5605
    • -
  • Curitel PC5740 Wireless Modem
    • -
  • Kyocera AH-K3001V Mobile Phone(WILLCOM)
    • -
  • Kyocera WX320K Mobile Phone(WILLCOM)
    • -
  • Metricom Ricochet GS USB wireless modem
    • -
  • Sierra MC5720 Wireless Modem
    • -
  • Yamaha Broadband Wireless Router RTW65b
    • -
  • ELSA MicroLink 56k USB modem
    • -
  • Sony Ericsson W810i phone
    • -
  • Sonim XP5300 Force
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The umodem driver appeared in - NetBSD 1.5. This manual page was adopted from - NetBSD by Tom Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
-

-

Only modems with multiplexed commands and data are supported at - the moment.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/umoscom.4 4.html b/static/freebsd/man4/umoscom.4 4.html deleted file mode 100644 index 077958af..00000000 --- a/static/freebsd/man4/umoscom.4 4.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
UMOSCOM(4)Device Drivers ManualUMOSCOM(4)
-
-
-

-

umoscom — USB - support for serial adapters based on chips made by MOSCHIP

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device umoscom
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
umoscom_load="YES"
-
-
-
-

-

The umoscom driver provides support for - various serial adapters based on chips from MOSCHIP.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The umoscom driver appeared in - OpenBSD and was ported to - FreeBSD.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/ums.4 4.html b/static/freebsd/man4/ums.4 4.html deleted file mode 100644 index 84e0014b..00000000 --- a/static/freebsd/man4/ums.4 4.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - -
UMS(4)Device Drivers ManualUMS(4)
-
-
-

-

ums — USB mouse - driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ums -
-device hid -
-device uhci -
-device ohci -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
ums_load="YES"
-
-
-
-

-

The ums driver provides support for mice - that attach to the USB port. Supported are mice with any number of buttons - and mice with a wheel.

-

The /dev/ums0 device presents the mouse as - a sysmouse or mousesystems type - device. See moused(8) for an explanation of these mouse - types.

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.ums.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/ums0
-
blocking device node
-
-
-
-

-

Use the first USB mouse on the system as your console mouse:

-

-
moused -p /dev/ums0 -t - auto
-

To be able to use the USB mouse under X, change the - "Pointer" section in xorg.conf to the - following:

-

-
Device /dev/ums0
-
Protocol Auto
-

If you want to be able to use the mouse in both virtual consoles - as well as in X change it to:

-

-
Device /dev/sysmouse
-
Protocol Auto
-
-
-

-

ohci(4), sysmouse(4), - uhci(4), usb(4), - xorg.conf(5) (ports/x11/xorg), - moused(8)

-
-
-

-

The ums driver was written by - Lennart Augustsson - <augustss@cs.chalmers.se> - for NetBSD and was adopted for - FreeBSD by MAEKAWA Masahide - <bishop@rr.iij4u.or.jp>.

-

This manual page was written by Nick Hibma - <n_hibma@FreeBSD.org> - with input from Kazutaka YOKOTA - <yokota@zodiac.mech.utsunomiya-u.ac.jp>.

-
-
- - - - - -
April 24, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/unionfs.4 3.html b/static/freebsd/man4/unionfs.4 3.html deleted file mode 100644 index 5e0ac5e7..00000000 --- a/static/freebsd/man4/unionfs.4 3.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
UNIONFS(4)Device Drivers ManualUNIONFS(4)
-
-
-

-

unionfs — union - mount file system

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
option UNIONFS
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
unionfs_load="YES"
-
-
-
-

-

The UNIONFS driver is an implementation of a stackable unification - filesystem.

-
-
-

-

mount_unionfs(8)

-
-
-

-

J. S. Pendry and - M. K. McKusick, Union mounts in - 4.4BSD-Lite, Proceedings of the USENIX Technical - Conference on UNIX and Advanced Computing Systems, - December 1995.

-

P. H. Kamp and - R. N. M. Watson, Jails: Confining - the omnipotent root, Proceedings of the Second - International System Administration and Networking Conference - (SANE2000), May 2000.

-
-
-

-

The unionfs device driver first appeared - in FreeBSD 5.0.

-
-
-

-

The unionfs device driver was written by - Jan-Simon Pendry for 4.4BSD and - Masanori OZAWA - <ozawa@ongs.co.jp> - reimplemented the handling of the locking for FreeBSD - 7.0. The manual page was written by Gordon - Bergling - <gbe@FreeBSD.org>.

-
-
-

-

Please see the mount_unionfs(8) manual page for - a list of bugs regarding the unionfs filesystem.

-
-
- - - - - -
April 27, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/unix.4 3.html b/static/freebsd/man4/unix.4 3.html deleted file mode 100644 index 7da9cc5b..00000000 --- a/static/freebsd/man4/unix.4 3.html +++ /dev/null @@ -1,302 +0,0 @@ - - - - - - -
UNIX(4)Device Drivers ManualUNIX(4)
-
-
-

-

unix — UNIX-domain - protocol family

-
-
-

-

#include - <sys/types.h> -
- #include <sys/un.h>

-
-
-

-

The UNIX-domain protocol family is a - collection of protocols that provides local (on-machine) interprocess - communication through the normal socket(2) mechanisms. The - UNIX-domain family supports the - SOCK_STREAM, SOCK_SEQPACKET, - and SOCK_DGRAM socket types and uses file system - pathnames for addressing.

-
-
-

-

UNIX-domain addresses are variable-length - file system pathnames of at most 104 characters. The include file - <sys/un.h> defines this - address:

-
-
struct sockaddr_un {
-	u_char	sun_len;
-	u_char	sun_family;
-	char	sun_path[104];
-};
-
-

Binding a name to a UNIX-domain socket - with bind(2) causes a socket file to be created in the - file system. This file is not removed when the socket is - closed — unlink(2) must be used to remove the - file.

-

Prior to binding a socket, fchmod(2) can be used - to set the permissions of the socket file. This avoids the race that would - otherwise occur between creation of the file and a subsequent call to - chmod(2). Once the socket is bound to a file name, the - permissions of the file can not be changed this way.

-

The length of UNIX-domain - address, required by bind(2) and - connect(2), can be calculated by the macro - () - defined in <sys/un.h>. The - sun_path field must be terminated by a - NUL character to be used with - SUN_LEN(), but the terminating - NUL is not part of the - address.

-

The UNIX-domain protocol family does not - support broadcast addressing or any form of “wildcard” - matching on incoming messages. All addresses are absolute- or - relative-pathnames of other UNIX-domain sockets. - Normal file system access-control mechanisms are also applied when - referencing pathnames; e.g., the destination of a - connect(2) or sendto(2) must be - writable.

-
-
-

-

The UNIX-domain sockets support the - communication of UNIX file descriptors and process - credentials through the use of the msg_control field - in the msg argument to sendmsg(2) - and recvmsg(2). The items to be passed are described using - a struct cmsghdr that is defined in the include file - <sys/socket.h>.

-

To send file descriptors, the type of the message is - SCM_RIGHTS, and the data portion of the messages is - an array of integers representing the file descriptors to be passed. The - number of descriptors being passed is defined by the length field of the - message; the length field is the sum of the size of the header plus the size - of the array of file descriptors.

-

The received descriptor is a - of - the sender's descriptor, as if it were created via - dup(fd) or fcntl(fd, - F_DUPFD_CLOEXEC, 0) depending on whether - MSG_CMSG_CLOEXEC is passed in the - recvmsg(2) call. Descriptors that are awaiting delivery, - or that are purposely not received, are automatically closed by the system - when the destination socket is closed.

-

Credentials of the sending process can be transmitted explicitly - using a control message of type SCM_CREDS with a - data portion of type struct cmsgcred, defined in - <sys/socket.h> as - follows:

-
-
struct cmsgcred {
-  pid_t	cmcred_pid;		/* PID of sending process */
-  uid_t	cmcred_uid;		/* real UID of sending process */
-  uid_t	cmcred_euid;		/* effective UID of sending process */
-  gid_t	cmcred_gid;		/* real GID of sending process */
-  short	cmcred_ngroups;		/* number of groups */
-  gid_t	cmcred_groups[CMGROUP_MAX];	/* groups */
-};
-
-

The sender should pass a zeroed buffer which will be filled in by - the system.

-

The group list is truncated to at most - CMGROUP_MAX GIDs.

-

The process ID cmcred_pid should not be - looked up (such as via the KERN_PROC_PID sysctl) for - making security decisions. The sending process could have exited and its - process ID already been reused for a new process.

-
-
-

-

UNIX domain sockets support a number of socket options for the - options level SOL_LOCAL, which can be set with - setsockopt(2) and tested with - getsockopt(2):

-
-
-
This option may be enabled on SOCK_DGRAM, - SOCK_SEQPACKET, or a - SOCK_STREAM socket. This option provides a - mechanism for the receiver to receive the credentials of the process - calling write(2), send(2), - sendto(2) or sendmsg(2) as a - recvmsg(2) control message. The - msg_control field in the - msghdr structure points to a buffer that contains a - cmsghdr structure followed by a variable length - sockcred structure, defined in - <sys/socket.h> as follows: -
- 
struct sockcred {
-  uid_t	sc_uid;		/* real user id */
-  uid_t	sc_euid;	/* effective user id */
-  gid_t	sc_gid;		/* real group id */
-  gid_t	sc_egid;	/* effective group id */
-  int	sc_ngroups;	/* number of supplemental groups */
-  gid_t	sc_groups[1];	/* variable length */
-};
-
-

The current implementation truncates the group list to at most - CMGROUP_MAX groups.

-

The - () - macro computes the size of the sockcred structure - for a specified number of groups. The cmsghdr - fields have the following values:

-
- 
cmsg_len = CMSG_LEN(SOCKCREDSIZE(ngroups))
-cmsg_level = SOL_SOCKET
-cmsg_type = SCM_CREDS
-
-

On SOCK_STREAM and - SOCK_SEQPACKET sockets credentials are passed - only on the first read from a socket, then the system clears the option - on the socket.

-

This option and the above explicit struct - cmsgcred both use the same value SCM_CREDS - but incompatible control messages. If this option is enabled and the - sender attached a SCM_CREDS control message with - a struct cmsgcred, it will be discarded and a - struct sockcred will be included.

-

Many setuid programs will write(2) data at - least partially controlled by the invoker, such as error messages. - Therefore, a message accompanied by a particular - sc_euid value should not be trusted as being from - that user.

-
-
-
This option is similar to LOCAL_CREDS, except that - socket credentials are passed on every read from a - SOCK_STREAM or - SOCK_SEQPACKET socket, instead of just the first - read. Additionally, the msg_control field in the - msghdr structure points to a buffer that contains a - cmsghdr structure followed by a variable length - sockcred2 structure, defined in - <sys/socket.h> as follows: -
- 
struct sockcred2 {
-  int	sc_version;	/* version of this structure */
-  pid_t	sc_pid;		/* PID of sending process */
-  uid_t	sc_uid;		/* real user id */
-  uid_t	sc_euid;	/* effective user id */
-  gid_t	sc_gid;		/* real group id */
-  gid_t	sc_egid;	/* effective group id */
-  int	sc_ngroups;	/* number of supplemental groups */
-  gid_t	sc_groups[1];	/* variable length */
-};
-
-

The current version is zero.

-

The cmsghdr fields have the following - values:

-
- 
cmsg_len = CMSG_LEN(SOCKCRED2SIZE(ngroups))
-cmsg_level = SOL_SOCKET
-cmsg_type = SCM_CREDS2
-
-

The LOCAL_CREDS and - LOCAL_CREDS_PERSISTENT options are mutually - exclusive.

-
-
-
Requested via getsockopt(2) on a - SOCK_STREAM or - SOCK_SEQPACKET socket returns credentials of the - remote side. These will arrive in the form of a filled in - xucred structure, defined in - <sys/ucred.h> as follows: -
- 
struct xucred {
-  u_int	cr_version;		/* structure layout version */
-  uid_t	cr_uid;			/* effective user id */
-  short	cr_ngroups;		/* number of groups */
-  gid_t	cr_groups[XU_NGROUPS];	/* groups */
-  pid_t	cr_pid;			/* process id of the sending process */
-};
-
- The cr_version fields should be checked against - XUCRED_VERSION define. -

The credentials presented to the server (the - listen(2) caller) are those of the client when it - called connect(2); the credentials presented to the - client (the connect(2) caller) are those of the server - when it called listen(2). This mechanism is reliable; - there is no way for either party to influence the credentials presented - to its peer except by calling the appropriate system call (e.g., - connect(2) or listen(2)) under - different effective credentials.

-

To reliably obtain peer credentials on a - SOCK_DGRAM socket refer to the - LOCAL_CREDS socket option.

-
-
-
-
-

-

Due to the local nature of the UNIX-domain - sockets, they do not implement send buffers. The send(2) - and write(2) families of system calls attempt to write - data to the receive buffer of the destination socket.

-

The default buffer sizes for SOCK_STREAM - and SOCK_SEQPACKET - UNIX-domain sockets can be configured with - net.local.stream and - net.local.seqpacket branches of - sysctl(3) MIB respectively. Note that setting the send - buffer size (sendspace) affects only the maximum write size.

-

The UNIX-domain sockets of type - SOCK_DGRAM are unreliable and always non-blocking - for write operations. The default receive buffer can be configured with - net.local.dgram.recvspace. The maximum allowed - datagram size is limited by net.local.dgram.maxdgram. - A SOCK_DGRAM socket that has been bound with - bind(2) can have multiple peers connected at the same - time. The modern FreeBSD implementation will - allocate net.local.dgram.recvspace sized private - buffers in the receive buffer of the bound socket for every connected - socket, preventing a situation when a single writer can exhaust all of - buffer space. Messages coming from unconnected sends using - sendto(2) land on the shared buffer of the receiving - socket, which has the same size limit. A side effect of the implementation - is that it doesn't guarantee that writes from different senders will arrive - at the receiver in the same chronological order they were sent. The order is - preserved for writes coming through a particular connection.

-
-
-

-

connect(2), dup(2), - fchmod(2), fcntl(2), - getsockopt(2), listen(2), - recvmsg(2), sendto(2), - setsockopt(2), socket(2), - CMSG_DATA(3), intro(4), - sysctl(8)

-

An Introductory 4.3 BSD - Interprocess Communication Tutorial, PS1, - 7.

-

An Advanced 4.3 BSD - Interprocess Communication Tutorial, PS1, - 8.

-
-
- - - - - -
October 31, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/upgt.4 3.html b/static/freebsd/man4/upgt.4 3.html deleted file mode 100644 index 5804e4a0..00000000 --- a/static/freebsd/man4/upgt.4 3.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - -
UPGT(4)Device Drivers ManualUPGT(4)
-
-
-

-

upgt — - Conexant/Intersil PrismGT SoftMAC USB IEEE 802.11b/g - wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device upgt -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_upgt_load="YES"
-
-
-
-

-

The upgt driver is slated to be removed in - FreeBSD 16.0.

-
-
-

-

The upgt driver supports the USB 2.0 - Conexant/Intersil PrismGT series wireless adapters based on the GW3887 - chipset.

-

These are the modes the upgt driver can - operate in:

-
-
BSS mode
-
Also known as - - mode, this is used when associating with an access point, through which - all traffic passes. This mode is the default.
-
monitor mode
-
In this mode the driver is able to receive packets without associating - with an access point. This disables the internal receive filter and - enables the card to capture packets from networks which it wouldn't - normally have access to, or to scan for access points.
-
-

upgt supports software WEP. Wired - Equivalent Privacy (WEP) is the de facto encryption standard for wireless - networks. It can be typically configured in one of three modes: no - encryption; 40-bit encryption; or 104-bit encryption. Unfortunately, due to - serious weaknesses in WEP protocol it is strongly recommended that it not be - used as the sole mechanism to secure wireless communication. WEP is not - enabled by default.

-

The upgt driver can be configured at - runtime with ifconfig(8).

-
-
-

-

This driver requires the upgtfw firmware - to be installed before it will work. The firmware files are not publicly - available. A package of the firmware which can be installed via - pkg_add(1) is available:

-
-
http://weongyo.org/project/upgt/upgt-firmware-2.13.1.0.tar.gz
-
-
-
-

-

The upgt driver supports USB 2.0 - Conexant/Intersil PrismGT series wireless adapters based on the GW3887 - chipset, among them:

-

-
    -
  • Belkin F5D7050 (version 1000)
    • -
  • Cohiba Proto Board
    • -
  • D-Link DWL-G120 Cohiba
    • -
  • FSC Connect2Air E-5400 USB D1700
    • -
  • Gigaset USB Adapter 54
    • -
  • Inventel UR045G
    • -
  • Netgear WG111v1 (rev2)
    • -
  • SMC EZ ConnectG SMC2862W-G
    • -
  • Sagem XG703A
    • -
  • Spinnaker DUT
    • -
  • Spinnaker Proto Board
    • -
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
ifconfig wlan create wlandev upgt0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - “my_net”:

-

-
ifconfig wlan create wlandev upgt0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev upgt0 ssid my_net \
-        wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-

arp(4), netintro(4), - usb(4), wlan(4), - ifconfig(8)

-
-
-

-

The upgt driver first appeared in - OpenBSD 4.3.

-
-
-

-

The upgt driver was written by - Marcus Glocker - <mglocker@openbsd.org>.

-

The hardware specification was reverse engineered by the people at - http://www.prism54.org.

-
-
-

-

The upgt driver just supports the USB 2.0 - devices (GW3887 chipset) but not the USB 1.0 devices containing the NET2280, - ISL3880, and ISL3886 chipsets. Some further efforts would be necessary to - add USB 1.0 support to the driver.

-
-
- - - - - -
October 24, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/uplcom.4 3.html b/static/freebsd/man4/uplcom.4 3.html deleted file mode 100644 index bb28034d..00000000 --- a/static/freebsd/man4/uplcom.4 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
UPLCOM(4)Device Drivers ManualUPLCOM(4)
-
-
-

-

uplcom — USB - support for Prolific PL-2303/2303X/2303HX serial adapters driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device uplcom
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uplcom_load="YES"
-
-
-
-

-

The uplcom driver provides support for - various serial adapters based on the Prolific PL-2303, PL-2303X and - PL-2303HX USB-to-RS232 Bridge chips.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-

The uplcom driver supports the following - devices and adapters:

-

-
    -
  • ADLINK ND-6530 USB-Serial Adapter
    • -
  • Alcatel One Touch 535/735 Phone
    • -
  • Alcor AU9720 USB-RS232 Serial Adapter
    • -
  • AlDiga AL-11U Modem
    • -
  • Alltronix ACM003U00 Modem
    • -
  • Anchor Serial adapter
    • -
  • ATEN UC-232A
    • -
  • ATEN UC-232B
    • -
  • BAFO BF-800 and BF-810
    • -
  • Belkin F5U257
    • -
  • BenQ S81 Phone
    • -
  • Corega CG-USBRS232R Serial Adapter
    • -
  • Cressi Edy (Seiko) Diving Computer
    • -
  • ELECOM UC-SGT Serial Adapter
    • -
  • HAL Corporation Crossam2+USB IR commander
    • -
  • Hama USB RS-232 Serial Adapter
    • -
  • Hamlet exaggerate XURS232
    • -
  • HP LD220 Point-Of-Sale (POS) Display
    • -
  • IOGEAR UC-232A
    • -
  • I/O DATA USB-RSAQ, USB-RSAQ2, USB-RSAQ3 and USB-RSAQ5
    • -
  • iTegno WM1080A GSM/GFPRS Modem
    • -
  • iTegno WM2080A CDMA Modem
    • -
  • Leadtek 9531 GPS
    • -
  • Micromax 610U Modem
    • -
  • Microsoft Palm 700WX
    • -
  • Mobile Action MA-620 Infrared Adapter
    • -
  • Motorola Cables
    • -
  • Nokia CA-42 Cable
    • -
  • OTI DKU-5 cable
    • -
  • Panasonic TY-TP50P6-S flat screen
    • -
  • PLX CA-42 Phone Cable
    • -
  • PLANEX USB-RS232 URS-03
    • -
  • Prolific Generic USB-Serial Adapters
    • -
  • Prolific Generic USB-Serial Adapters (HXN)
    • -
  • Prolific Pharos USB-Serial Adapter
    • -
  • Prolific USB-Serial Controller D
    • -
  • RATOC REX-USB60
    • -
  • Radio Shack USB Serial Cable
    • -
  • Sagem USB-Serial Adapter
    • -
  • Samsung I330 Phone Cradle
    • -
  • Sandberg USB to Serial Link (model number 133-08)
    • -
  • Sanwa KB-USB2 Multimeter cable
    • -
  • Siemens/BenQ EF81, SX1, X65 and X75 Mobile Phones
    • -
  • Sitecom USB-Serial Adapter
    • -
  • SMART Technologies USB-Serial Adapter
    • -
  • Sony QN3 Phone Cable
    • -
  • Sony Ericsson Datapilot
    • -
  • Sony Ericsson DCU-10 and DCU-11 (Susteen) USB Cables
    • -
  • SOURCENEXT KeikaiDenwa 8 (with and without charger)
    • -
  • Speed Dragon USB-Serial Cable
    • -
  • Syntech CPT-8001C Barcode Scanner
    • -
  • TDK UHA6400 and UPA9664 USB-PHS Adapters
    • -
  • TRENDnet USB to Serial Converter (TU-S9)
    • -
  • Tripp-Lite U209-000-R USB-Serial Adapter
    • -
  • UIC HCR331 Magnetic Stripe Card Reader
    • -
  • UIC MSR206 Magnetic Stripe Card Reader
    • -
  • Willcom W-SIM DD PHS terminal.(WS002IN)
    • -
  • YC-Cable USB-Serial Adapter
    • -
  • Zeagle N2iTion3 Diving Computer
    • -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.uplcom.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The uplcom driver appeared in - NetBSD 1.6. This manual page was adopted from - NetBSD by Tom Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
- - - - - -
January 7, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/ural.4 3.html b/static/freebsd/man4/ural.4 3.html deleted file mode 100644 index 3bc744ca..00000000 --- a/static/freebsd/man4/ural.4 3.html +++ /dev/null @@ -1,242 +0,0 @@ - - - - - - -
URAL(4)Device Drivers ManualURAL(4)
-
-
-

-

ural — Ralink - RT2500USB IEEE 802.11a/b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device ural -
-device wlan -
-device wlan_amrr
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ural_load="YES"
-
-
-
-

-

The ural driver supports USB 2.0 wireless - adapters based on the RT2500USB chipset.

-

The RT2500USB chipset consists of two integrated chips, a RT2570 - MAC/BBP and a radio transceiver (the model of which depends on the card - revision).

-

The RT2522, RT2523, RT2524, RT2525, RT2525e and RT2526 radio - transceivers operate in the 2.4GHz band (802.11b/g) whereas the RT5222 is a - dual-band radio transceiver that can operate in the 2.4GHz and 5.2GHz bands - (802.11a).

-

ural supports - station, adhoc, - hostap, and monitor mode - operation. Only one virtual interface may be configured at any time. For - more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ural driver supports USB 2.0 wireless - adapters based on the Ralink Technology RT2500USB chipset, including:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AMIT WL532UUSB
ASUS WL-167gUSB
Belkin F5D7050 v2000USB
Buffalo WLI-U2-KG54-AIUSB
CNet CWD-854USB
Compex WLU54G 2A1100USB
Conceptronic C54RUUSB
D-Link DWL-G122 b1USB
Dynalink WLG25USBUSB
E-Tech WGUS02USB
Gigabyte GN-WBKGUSB
Hercules HWGUSB2-54USB
KCORP LifeStyle KLS-685USB
Linksys WUSB54G v4USB
Linksys WUSB54GP v4USB
MSI MS-6861USB
MSI MS-6865USB
MSI MS-6869USB
NovaTech NV-902USB
OvisLink Evo-W54USBUSB
SerComm UB801RUSB
SparkLAN WL-685RUSB
Surecom EP-9001-gUSB
Sweex LC100060USB
Tonze UW-6200CUSB
Zinwell ZWX-G261USB
Zonet ZEW2500PUSB
-

An up to date list can be found at - http://ralink.rapla.net/.

-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev ural0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev ural0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev ural0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Join a specific BSS network with 128-bit WEP encryption:

-
-
ifconfig wlan create wlandev ural0 wlanmode adhoc ssid my_net \
-    wepmode on wepkey 0x01020304050607080910111213 weptxkey 1
-
-
-
-

-
-
ural%d: device timeout
-
The driver will reset the hardware. This should not happen.
-
-
-
-

-

intro(4), netintro(4), - usb(4), wlan(4), - wlan_amrr(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - wlan_xauth(4), networking(7), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The ural driver first appeared in - OpenBSD 3.7 and FreeBSD - 6.0.

-
-
-

-

The original ural driver was written by - Damien Bergamini - <damien.bergamini@free.fr>.

-
-
-

-

Host AP mode doesn't support client power save. Clients using - power save mode will experience packet loss (disabling power saving on the - client will fix this).

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/ure.4 3.html b/static/freebsd/man4/ure.4 3.html deleted file mode 100644 index 9fa8a76f..00000000 --- a/static/freebsd/man4/ure.4 3.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - -
URE(4)Device Drivers ManualURE(4)
-
-
-

-

ure — Realtek - RTL8152/RTL8153/RTL8156 USB Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device uhci -
-device ohci -
-device usb -
-device miibus -
-device uether -
-device ure
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_ure_load="YES"
-
-
-
-

-

The ure driver supports the Realtek USB - Ethernet Controller family.

-

The ure driver supports the following - media types:

-
-
-
Enable auto selection of the media type and options. The user can manually - override the auto selected mode by adding media options to the - /etc/rc.conf file.
-
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX (Gigabit Ethernet) operation over twisted pair. The Realtek - gigE chips support 1000Mbps in full-duplex mode - only.
-
-
Set 2500Base-T operation over twisted pair. The Realtek 8156/8156B chips - support 2500Mbps in full-duplex mode only.
-
-

The ure driver supports the following - media options for 10/100 operation:

-
-
-
Force full-duplex operation.
-
-
Force half-duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The ure driver supports the following USB - Ethernet controllers:

- - - - - - - - - - - - - - - - - - - - - -
Model:Speed (Mbps):
Realtek RTL8156/RTL8156B/RTL8156BG10, 100, 1000, and 2500
Realtek RTL8153/RTL8153B10, 100, and 1000
Realtek RTL815210 and 100
Realtek RTL8168/8169/8110/8211 via rgephy(4)10, 100, and 1000
-
-
-

-
-
ure%d: watchdog timeout
-
A packet was queued for transmission and a transmit command was issued, - however the device failed to acknowledge the transmission before a timeout - expired.
-
-
-
-

-

arp(4), miibus(4), - netintro(4), ng_ether(4), - ifconfig(8)

-
-
-

-

The ure driver was written by - Kevin Lo - <kevlo@FreeBSD.org>.

-
-
- - - - - -
April 8, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/urio.4 4.html b/static/freebsd/man4/urio.4 4.html deleted file mode 100644 index 5d501b5d..00000000 --- a/static/freebsd/man4/urio.4 4.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
URIO(4)Device Drivers ManualURIO(4)
-
-
-

-

urio — USB driver - for the Rio MP3 players

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device urio
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
urio_load="YES"
-
-
-
-

-

The urio driver provides support for Rio - MP3 players from Diamond MultiMedia which attaches to the USB port. The - urio device must be configured in the kernel, along - with and - one of the - or - - controllers.

-

Subsequently, the /dev/urio0 device can be - used by the Rio userland applications.

-
-
-

-

The following devices are supported by the - urio driver:

-

-
    -
  • Diamond MultiMedia Rio 500
    • -
  • Diamond MultiMedia Rio 600
    • -
  • Diamond MultiMedia Rio 800
    • -
-
-
-

-
-
/dev/urio0
-
blocking device node
-
-
-
-

-

The following line in the kernel configuration file adds the - urio driver to the kernel:

-
device urio
-

To download a song over the USB connection into the Rio using the - rio_add_song(1) utility (see the - SEE ALSO section):

-
rio_add_song - /usr/local/MP3/TracyChapman/02-Fast-Car.mp3
-
-
-

-

ohci(4), uhci(4), - usb(4)

-

The Rio 500 SourceForge Project - Web Page, - http://rio500.sourceforge.net/.

-

The Rio500 tools from SourceForge are the actual userland tools - used to download, format or rename songs on players. When compiling these - tools, the following pre-build configuration command will ensure that - rio_usb.h is available in the include path and that - the device used is /dev/urio0:

-
-
CFLAGS="-I/usr/include/dev/usb" ./configure \
-    --with-devicepath='/dev' --with-deviceentry='urio0'
-
-
-
-

-

The urio driver was written by - Iwasa Kazmi - <kzmi@ca2.so-net.ne.jp> - for FreeBSD.

-

This manual page was written by Dirk-Willem van - Gulik - <dirkx@webweaving.org>.

-
-
- - - - - -
November 22, 2006FreeBSD 15.0
diff --git a/static/freebsd/man4/urndis.4 3.html b/static/freebsd/man4/urndis.4 3.html deleted file mode 100644 index e04288ba..00000000 --- a/static/freebsd/man4/urndis.4 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
URNDIS(4)Device Drivers ManualURNDIS(4)
-
-
-

-

urndis — USB - Remote NDIS Ethernet device

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device xhci -
-device usb -
-device miibus -
-device uether -
-device urndis
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_urndis_load="YES"
-
-
-
-

-

The urndis driver provides Ethernet access - over Remote NDIS (RNDIS), allowing mobile devices such as phones and tablets - to provide network access. It is often referred to as USB tethering, and in - most cases must be explicitly enabled on the device.

-

urndis should work with any USB RNDIS - devices, such as those commonly found on Android devices. It does not - support different media types or options. For more information on - configuring this device, see ifconfig(8).

-
-
-

-

The urndis driver supports the - "tethering" functionality of many Android devices.

-
-
-

-

arp(4), cdce(4), - cdceem(4), ipheth(4), - netintro(4), usb(4), - ifconfig(8)

-
-
-

-

The urndis device driver first appeared in - OpenBSD 4.7. The first - FreeBSD release to include it was - FreeBSD 9.3.

-
-
-

-

The urndis driver was written by - Jonathan Armani - <armani@openbsd.org>, - Michael Knudsen - <mk@openbsd.org>, and - Fabien Romano - <fabien@openbsd.org>. - It was ported to FreeBSD by Hans - Petter Selasky - <hselasky@FreeBSD.org>.

-
-
- - - - - -
November 24, 2015FreeBSD 15.0
diff --git a/static/freebsd/man4/urtw.4 3.html b/static/freebsd/man4/urtw.4 3.html deleted file mode 100644 index 8425abad..00000000 --- a/static/freebsd/man4/urtw.4 3.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - -
URTW(4)Device Drivers ManualURTW(4)
-
-
-

-

urtw — Realtek - RTL8187B/L USB IEEE 802.11b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device urtw -
-device wlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_urtw_load="YES"
-
-
-
-

-

The urtw driver supports USB 802.11b/g - wireless adapters based on the Realtek RTL8187B/L.

-

urtw supports - station and monitor mode - operation. Only one virtual interface may be configured at any time.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The urtw driver supports Realtek - RTL8187B/L based wireless network devices, including:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Belkin F5D7050ERTL8225USB
Linksys WUSB54GCv2RTL8225USB
Netgear WG111v2RTL8225USB
Netgear WG111v3RTL8225USB
Safehome WLG-1500SMA5RTL8225USB
Shuttle XPC Accessory PN20RTL8225USB
Sitecom WL168v1RTL8225USB
Sitecom WL168v4RTL8225USB
SureCom EP-9001-g(2A)RTL8225USB
TRENDnet TEW-424UB V3.xRRTL8225USB
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-

-
ifconfig wlan create wlandev urtw0 - inet 192.0.2.20/24
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan create wlandev urtw0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan create wlandev urtw0 ssid my_net \
-    wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-
-
-

-

intro(4), netintro(4), - usb(4), wlan(4), - wlan_ccmp(4), wlan_tkip(4), - wlan_wep(4), ifconfig(8), - wpa_supplicant(8)

-

Realtek, - https://www.realtek.com.

-
-
-

-

The urtw device driver first appeared in - FreeBSD 8.0.

-
-
-

-

The urtw driver was written by - Weongyo Jeong - <weongyo@FreeBSD.org>.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/usb.4 4.html b/static/freebsd/man4/usb.4 4.html deleted file mode 100644 index 01eebc48..00000000 --- a/static/freebsd/man4/usb.4 4.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - -
USB(4)Device Drivers ManualUSB(4)
-
-
-

-

usb — Universal - Serial Bus

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
usb_load="YES"
-
-
-
-

-

USB functions can be accessed from userland through the libusb - library. See libusb(3) for more information.

-
-
-

-

FreeBSD provides machine-independent bus - support and drivers for USB devices in host and device side mode.

-

The usb driver has three layers:

-
-
-
USB Controller (Bus)
-
 
-
USB Device
-
 
-
USB Driver
-
 
-
-
-

The controller attaches to a physical bus like - pci(4). The USB bus attaches to the controller, and the - root hub attaches to the controller. Any devices attached to the bus will - attach to the root hub or another hub attached to the USB bus.

-

The uhub device will always be present as - it is needed for the root hub.

-
-
-

-

The USB is a system where external devices can be connected to a - PC. The most common USB speeds are:

-
-
-
Low Speed (1.5 MBit/sec)
-
 
-
Full Speed (12 MBit/sec)
-
 
-
High Speed (480 MBit/sec)
-
 
-
SuperSpeed (5 GBit/sec)
-
 
-
-
-

Each USB has a USB controller that is the master of the bus. The - physical communication is simplex which means the host controller only - communicates with one USB device at a time.

-

There can be up to 127 devices connected to an USB HUB tree. The - addresses are assigned dynamically by the host when each device is attached - to the bus.

-

Within each device there can be up to 16 endpoints. - Each endpoint is individually addressed and the addresses are static. Each - of these endpoints will communicate in one of four different modes: - , - , - , or - . - A device always has at least one endpoint. This endpoint has address 0 and - is a control endpoint and is used to give commands to and extract basic - data, such as descriptors, from the device. Each endpoint, except the - control endpoint, is unidirectional.

-

The endpoints in a device are grouped into interfaces. An - interface is a logical unit within a device, e.g., a compound device with - both a keyboard and a trackball, would present one interface for each. An - interface can sometimes be set into different modes, called alternate - settings, which affects how it operates. Different alternate settings can - have different endpoints within it.

-

A device may operate in different configurations. Depending on the - configuration, the device may present different sets of endpoints and - interfaces.

-

The bus enumeration of the USB bus proceeds in several steps:

-
    -
  1. Any interface specific driver can attach to the device.
    2. -
  2. If none is found, generic interface class drivers can attach.
    3. -
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-
-
-

-

The USB specifications can be found at:

-

-
https://www.usb.org/documents
-

libusb(3), aue(4), - axe(4), axge(4), - cue(4), ehci(4), - kue(4), mos(4), - ohci(4), pci(4), - rue(4), ucom(4), - udav(4), uhci(4), - uhid(4), ukbd(4), - ulpt(4), umass(4), - ums(4), uplcom(4), - urio(4), uvscom(4), - xhci(4) usbconfig(8), - usbdi(9)

-
-
-

-

The usb module complies with the USB 3.0 - standard.

-
-
-

-

The usb module has been inspired by the - NetBSD USB stack initially written by - Lennart Augustsson. The usb - module was written by Hans Petter Selasky - <hselasky@FreeBSD.org>.

-
-
- - - - - -
September 7, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/usb_quirk.4 3.html b/static/freebsd/man4/usb_quirk.4 3.html deleted file mode 100644 index e1db8515..00000000 --- a/static/freebsd/man4/usb_quirk.4 3.html +++ /dev/null @@ -1,255 +0,0 @@ - - - - - - -
USB_QUIRK(4)Device Drivers ManualUSB_QUIRK(4)
-
-
-

-

usb_quirk — USB - quirks module

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device usb
-

Alternatively, to load the module at boot time, place the - following line in loader.conf(5):

-
-
usb_quirk_load="YES"
-
-
-
-

-

The usb_quirk module provides support for - dynamically adding and removing quirks for USB devices with - usbconfig(8).

-
-
-

-
-
UQ_AUDIO_SWAP_LR
-
swap left and right channels
-
UQ_AU_INP_ASYNC
-
input is async despite claim of adaptive
-
UQ_AU_NO_FRAC
-
do not adjust for fractional samples
-
UQ_AU_NO_XU
-
audio device has broken extension unit
-
UQ_AU_VENDOR_CLASS
-
audio device uses vendor class to identify itself
-
UQ_AU_SET_SPDIF_CM6206
-
audio device needs special programming to enable S/PDIF audio output
-
UQ_BAD_ADC
-
bad audio spec version number
-
UQ_BAD_AUDIO
-
device claims audio class, but is not
-
UQ_BROKEN_BIDIR
-
printer has broken bidir mode
-
UQ_BUS_POWERED
-
device is bus powered, despite claim
-
UQ_HID_IGNORE
-
device should be ignored by hid class
-
UQ_KBD_IGNORE
-
device should be ignored by kbd class
-
UQ_KBD_BOOTPROTO
-
device should set the boot protocol
-
UQ_UMS_IGNORE
-
device should be ignored by ums class
-
UQ_MS_BAD_CLASS
-
does not identify properly
-
UQ_MS_LEADING_BYTE
-
mouse sends an unknown leading byte
-
UQ_MS_REVZ
-
mouse has Z-axis reversed
-
UQ_MS_VENDOR_BTN
-
mouse has buttons in vendor usage page
-
UQ_NO_STRINGS
-
string descriptors are broken
-
UQ_POWER_CLAIM
-
hub lies about power status
-
UQ_SPUR_BUT_UP
-
spurious mouse button up events
-
UQ_SWAP_UNICODE
-
has some Unicode strings swapped
-
UQ_CFG_INDEX_1
-
select configuration index 1 by default
-
UQ_CFG_INDEX_2
-
select configuration index 2 by default
-
UQ_CFG_INDEX_3
-
select configuration index 3 by default
-
UQ_CFG_INDEX_4
-
select configuration index 4 by default
-
UQ_CFG_INDEX_0
-
select configuration index 0 by default
-
UQ_ASSUME_CM_OVER_DATA
-
assume cm over data feature
-
UQ_IGNORE_CDC_CM
-
ignore cm descriptor
-
UQ_WMT_IGNORE
-
device should be ignored by wmt driver
-
-
-
-

-
-
UQ_MSC_NO_TEST_UNIT_READY
-
send start/stop instead of TUR
-
UQ_MSC_NO_RS_CLEAR_UA
-
does not reset Unit Att.
-
UQ_MSC_NO_START_STOP
-
does not support start/stop
-
UQ_MSC_NO_GETMAXLUN
-
does not support get max LUN
-
UQ_MSC_NO_INQUIRY
-
fake generic inq response
-
UQ_MSC_NO_INQUIRY_EVPD
-
does not support inq EVPD
-
UQ_MSC_NO_SYNC_CACHE
-
does not support sync cache
-
UQ_MSC_SHUTTLE_INIT
-
requires Shuttle init sequence
-
UQ_MSC_ALT_IFACE_1
-
switch to alternate interface 1
-
UQ_MSC_FLOPPY_SPEED
-
does floppy speeds (20kb/s)
-
UQ_MSC_IGNORE_RESIDUE
-
gets residue wrong
-
UQ_MSC_WRONG_CSWSIG
-
uses wrong CSW signature
-
UQ_MSC_RBC_PAD_TO_12
-
pad RBC requests to 12 bytes
-
UQ_MSC_READ_CAP_OFFBY1
-
reports sector count, not max sec.
-
UQ_MSC_FORCE_SHORT_INQ
-
does not support full inq.
-
UQ_MSC_FORCE_WIRE_BBB
-
force BBB wire protocol
-
UQ_MSC_FORCE_WIRE_CBI
-
force CBI wire protocol
-
UQ_MSC_FORCE_WIRE_CBI_I
-
force CBI with int. wire protocol
-
UQ_MSC_FORCE_PROTO_SCSI
-
force SCSI command protocol
-
UQ_MSC_FORCE_PROTO_ATAPI
-
force ATAPI command protocol
-
UQ_MSC_FORCE_PROTO_UFI
-
force UFI command protocol
-
UQ_MSC_FORCE_PROTO_RBC
-
force RBC command protocol
-
-
-
-

-
-
UQ_MSC_EJECT_HUAWEI
-
ejects after Huawei USB command
-
UQ_MSC_EJECT_SIERRA
-
ejects after Sierra USB command
-
UQ_MSC_EJECT_SCSIEJECT
-
ejects after SCSI eject command - 0x1b0000000200
-
UQ_MSC_EJECT_REZERO
-
ejects after SCSI rezero command - 0x010000000000
-
UQ_MSC_EJECT_ZTESTOR
-
ejects after ZTE SCSI command - 0x850101011801010101010000
-
UQ_MSC_EJECT_CMOTECH
-
ejects after C-motech SCSI command - 0xff52444556434847
-
UQ_MSC_EJECT_WAIT
-
wait for the device to eject
-
UQ_MSC_EJECT_SAEL_M460
-
ejects after Sael USB commands
-
UQ_MSC_EJECT_HUAWEISCSI
-
ejects after Huawei SCSI command - 0x11060000000000000000000000000000
-
UQ_MSC_EJECT_TCT
-
ejects after TCT SCSI command 0x06f504025270
-
UQ_MSC_DYMO_EJECT
-
ejects after HID command 0x1b5a01
-
-

See /sys/dev/usb/quirk/usb_quirk.h or run - "usbconfig dump_quirk_names" for the complete list of supported - quirks.

-
-
-

-

The following tunable can be set at the - loader(8) prompt before booting the kernel, or stored in - loader.conf(5).

-
-
hw.usb.quirk.%d
-
The value is a string whose format is: -
- 
"VendorId ProductId LowRevision HighRevision UQ_QUIRK,..."
-
-

Installs the quirks UQ_QUIRK,... for - all USB devices matching VendorId and - ProductId which have a hardware revision between - and including LowRevision and - HighRevision.

-

VendorId, - ProductId, LowRevision - and HighRevision are all 16 bits numbers which - can be decimal or hexadecimal based.

-

A maximum of 100 variables hw.usb.quirk.0, - .1, ..., .99 can be defined.

-

If a matching entry is found in the kernel's internal quirks - table, it is replaced by the new definition.

-

Else a new entry is created given that the quirk table is not - full.

-

The kernel iterates over the - hw.usb.quirk.N variables starting at - N = 0 and stops at N = - 99 or the first non-existing one.

-
-
-
-
-

-

After attaching a u3g device which appears - as a USB device on ugen0.3:

-
-
usbconfig -d ugen0.3 add_quirk UQ_MSC_EJECT_WAIT
-
-

Enable a Holtec/Keep Out F85 gaming keyboard on - ugen1.4:

-
-
usbconfig -d ugen1.4 add_quirk UQ_KBD_BOOTPROTO
-
-

To install a quirk at boot time, place one or several lines like - the following in loader.conf(5):

-
-
hw.usb.quirk.0="0x04d9 0xfa50 0 0xffff UQ_KBD_IGNORE"
-
-
-
-

-

usbconfig(8)

-
-
-

-

The usb_quirk module appeared in - FreeBSD 8.0, and was written by - Hans Petter Selasky - <hselasky@FreeBSD.org>. - This manual page was written by Nick Hibma - <n_hibma@FreeBSD.org>.

-
-
- - - - - -
August 19, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/usb_template.4 3.html b/static/freebsd/man4/usb_template.4 3.html deleted file mode 100644 index caa96d4b..00000000 --- a/static/freebsd/man4/usb_template.4 3.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - -
USB_TEMPLATE(4)Device Drivers ManualUSB_TEMPLATE(4)
-
-
-

-

usb_template — USB - device side templates

-
-
-

-

To compile this module into the kernel, place the following line - in your kernel configuration file:

-
device usb_template
-

To load the module at boot time, place the following line in - loader.conf(5):

-
-
usb_template_load="YES"
-
-
-
-

-

The usb_template module implements various - USB templates that are needed when programming an USB device side driver. A - USB template consists of an USB device descriptor, one or more USB - configuration descriptors, one or more USB interface descriptors, one or - more USB endpoint descriptors, USB strings and additional USB descriptors. - USB templates are selected using the hw.usb.template - sysctl and tunable, or by using the usbconfig(8) - set_template subcommand. Changing the - hw.usb.template sysctl triggers reenumeration by the - USB host; changes to other sysctls may not be visible to the host until - reenumeration is performed.

-

Available templates are:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
USB Mass Storage, see cfumass(4)
CDC Ethernet, see cdce(4)
Media Transfer Protocol (MTP)
USB serial port, see umodem(4)
USB audio
USB keyboard
USB mouse
USB phone
CDC Ethernet and serial port
USB MIDI
CDC Ethernet, serial port, and storage
CDC Ethernet Emulation Model, see cdceem(4)
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.template
-
Currently selected template. Set to -1 to make the device disappear from - the USB host point of view.
-
hw.usb.template_power
-
USB bus power consumption in mA at 5V. Must be between 0 and 500. Setting - to 0 marks the device as self-powered. Defaults to 500mA.
-
hw.usb.templates.N
-
Configuration for template number N.
-
hw.usb.templates.N.vendor_id
-
16-bit vendor identifier (VID), usually assigned by USB-IF.
-
hw.usb.templates.N.product_id
-
16-bit product identifier (PID).
-
hw.usb.templates.N.manufacturer
-
String containing human-readable manufacturer name.
-
hw.usb.templates.N.product
-
String containing human-readable product name.
-
-
-
-

-

cfumass(4), usb(4), - usfs(4), usbconfig(8)

-
-
-

-

The usb_template module complies to the - USB 1.0, 2.0 and 3.0 standard.

-
-
-

-

The usb_template module was written by - Hans Petter Selasky - <hselasky@FreeBSD.org>.

-
-
- - - - - -
August 7, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/usbhid.4 3.html b/static/freebsd/man4/usbhid.4 3.html deleted file mode 100644 index 8ae69d10..00000000 --- a/static/freebsd/man4/usbhid.4 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
USBHID(4)Device Drivers ManualUSBHID(4)
-
-
-

-

usbhid — USB HID - transport driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usbhid
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
usbhid_load="YES"
-
-
-
-

-

The usbhid driver provides a interface to - USB Human Interface Devices (HIDs).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.usbhid.enable
-
Enable usbhid and make its priority greater than - other USB HID drivers, such as ukbd(4), - ums(4), and uhid(4). Default is - 1.
-
-
-
hw.usb.usbhid.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0. Debug messages are printed - on the system console and can be viewed using - dmesg(8).
-
-
-
-

-

ehci(4), hkbd(4), - hms(4), ohci(4), - uhci(4), usb(4), - xhci(4), usbconfig(8)

-
-
-

-

The usbhid driver first appeared in - FreeBSD 13.0. It was enabled by default in - FreeBSD 15.0.

-
-
-

-

The usbhid driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
October 2, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/usfs.4 3.html b/static/freebsd/man4/usfs.4 3.html deleted file mode 100644 index 67ad2d8d..00000000 --- a/static/freebsd/man4/usfs.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
USFS(4)Device Drivers ManualUSFS(4)
-
-
-

-

usfs — USB device - side support for bulk only transport mass storage

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device usfs
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
usfs_load="YES"
-
-
-
-

-
This driver is obsolete. Users are advised to use - cfumass(4) instead.
-

The usfs driver provides support for - emulating an USB mass storage device when the USB stack is activated in USB - device side mode (the usb_template(4) module is loaded and - the hw.usb.template sysctl is set to 0).

-

Upon attach the driver creates a RAM disk which can be read and - written.

-
-
-

-

cfumass(4), umass(4), - usb(4), usb_template(4)

-
-
-

-

The usfs driver appeared in - FreeBSD 8.0.

-
-
- - - - - -
May 17, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/uslcom.4 3.html b/static/freebsd/man4/uslcom.4 3.html deleted file mode 100644 index 52c7dbfb..00000000 --- a/static/freebsd/man4/uslcom.4 3.html +++ /dev/null @@ -1,165 +0,0 @@ - - - - - - -
USLCOM(4)Device Drivers ManualUSLCOM(4)
-
-
-

-

uslcom — Silicon - Laboratories CP2101/CP2102/CP2103/CP2104/CP2105 based USB serial - adapter

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device uslcom
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uslcom_load="YES"
-
-
-
-

-

The uslcom driver supports Silicon - Laboratories CP2101/CP2102/CP2103/CP2104/CP2105 based USB serial - adapters.

-

The datasheets for the CP2101/CP2102/CP2103 list the maximum - supported baud rate as 921,600. Empirical testing has shown that the rates - 1,228,800 and 1,843,200 also work, at least on some hardware, so the driver - allows setting those rates.

-
-
-

-

The following devices should work with the - uslcom driver:

-

-
    -
  • AC-Services CAN, CIS-IBUS, IBUS and OBD interfaces
    • -
  • Aerocomm Radio
    • -
  • AKTACOM ACE-1001 cable
    • -
  • AMBER Wireless AMB2560
    • -
  • Arkham DS-101 Adapter
    • -
  • Argussoft ISP
    • -
  • Arygon Technologies Mifare RFID Reader
    • -
  • AVIT Research USB-TTL interface
    • -
  • B&G H3000 Data Cable
    • -
  • Balluff RFID reader
    • -
  • Baltech card reader
    • -
  • BEI USB VCP Sensor
    • -
  • Burnside Telecom Desktop Mobile
    • -
  • chip45.com Crumb128 module
    • -
  • Clipsal 5000CT2, 5500PACA, 5500PCU, 560884, 5800PC, C5000CT2 and L51xx - C-Bus Home Automation products
    • -
  • Commander 2 EDGE(GSM) Modem
    • -
  • Cygnal Fasttrax GPS and Debug adapter
    • -
  • DataApex MultiCOM USB to RS232 converter
    • -
  • Degree Controls USB adapter
    • -
  • DekTec DTA Plus VHF/UHF Booster
    • -
  • Dell DW700 GPS Receiver
    • -
  • Digianswer ZigBee/802.15.4 MAC
    • -
  • Dynastream ANT Development kits
    • -
  • Elan USBcount50, USBscope50, USBpulse100 and USBwave12
    • -
  • ELV USB-I2C interface
    • -
  • EMS C1007 HF RFID controller
    • -
  • Festo CPX-USB and CMSP interfaces
    • -
  • Gemalto Prox-PU/CU contactless card reader
    • -
  • Helicomm IP-Link 1220-DVM
    • -
  • IMS USB-RS422 adapter
    • -
  • Infinity GPS-MIC-1 Radio Monophone
    • -
  • INSYS Modem
    • -
  • IRZ SG-10 and MC35pu GSM/GPRS Modems
    • -
  • Jablotron PC-60B
    • -
  • Kamstrup M-Bus Master MultiPort 250D and Optical Eye/3 wire utility meter - interfaces
    • -
  • Kyocera GPS
    • -
  • Link Instruments MS-019 and MS-028 Oscilloscope/Logic Analyzer/Pattern - Generators
    • -
  • Lipowsky Baby-JTAG, Baby-LIN and HARP-1
    • -
  • MEI CashFlow SC and Series 2000 cash acceptors
    • -
  • MJS USB-TOSLINK Adapter
    • -
  • MobiData GPRS USB Modems
    • -
  • MSD DashHawk
    • -
  • Multiplex RC adapter
    • -
  • Optris MSpro LT Thermometer
    • -
  • Owen AC4 USB-RS485 converter
    • -
  • Pirelli DP-L10 SIP phone
    • -
  • PLX CA-42 Phone cable
    • -
  • Pololu USB to Serial
    • -
  • Procyon AVS Mind Machine
    • -
  • Renesas RX-Stick for RX610
    • -
  • Siemens MC60 Cable
    • -
  • Silicon Laboratories generic CP2101/CP2102/CP2103/CP2104/CP2105 chips
    • -
  • Software Bisque Paramount ME
    • -
  • SPORTident BSM7-D USB
    • -
  • Suunto Sports Instrument
    • -
  • Syntech CipherLab USB Barcode Scanner
    • -
  • T-Com TC 300 SIP phone
    • -
  • Tams Master Easy Control
    • -
  • Telegesis ETRX2USB
    • -
  • Timewave HamLinkUSB
    • -
  • Tracient RFID Reader
    • -
  • Track Systems Traqmate
    • -
  • Vaisala USB Instrument cable
    • -
  • VStabi Controller
    • -
  • WAGO 750-923 USB Service Cable
    • -
  • WaveSense Jazz Blood Glucose Meter
    • -
  • WIENER Plein & Baus CML Data Logger, RCM Remote, and PL512 and MPOD - PSUs
    • -
  • WMR RIGblaster Plug&Play and RIGtalk RT1
    • -
  • Zephyr Bioharness
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The uslcom device driver first appeared in - OpenBSD 4.0. The first - FreeBSD release to include it was - FreeBSD 7.1.

-
-
-

-

The uslcom driver was written by - Jonathan Gray - <jsg@openbsd.org>.

-
-
- - - - - -
December 9, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/uvisor.4 4.html b/static/freebsd/man4/uvisor.4 4.html deleted file mode 100644 index f4ec87fd..00000000 --- a/static/freebsd/man4/uvisor.4 4.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - -
UVISOR(4)Device Drivers ManualUVISOR(4)
-
-
-

-

uvisor — USB - support for the PalmOS based PDAs

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device uvisor
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uvisor_load="YES"
-
-
-
-

-

The uvisor driver provides support for USB - based PalmOS PDAs, like Handspring Visor, Palm Mxxx series, and Sony - Clie.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4). The device has - several ports for different purposes, each of them gets its own - ucom(4) device. The attach message describes the purpose - of each port.

-

The usual Pilot tools can be used to access the attached device on - the HotSync port.

-
-
-

-

The uvisor driver supports the following - devices:

-

-
    -
  • Aceeca Mez1000 RDA
    • -
  • Handspring Treo
    • -
  • Handspring Treo 600
    • -
  • Handspring Visor
    • -
  • Palm I705
    • -
  • Palm M125
    • -
  • Palm M130
    • -
  • Palm M500
    • -
  • Palm M505
    • -
  • Palm M515
    • -
  • Palm Tungsten T
    • -
  • Palm Tungsten Z
    • -
  • Palm Zire
    • -
  • Palm Zire 31
    • -
  • Sony Clie 4.0
    • -
  • Sony Clie 4.1
    • -
  • Sony Clie 5.0
    • -
  • Sony Clie PEG-S500C
    • -
  • Sony Clie NX60
    • -
  • Sony Clie S360
    • -
  • Sony Clie TJ37
    • -
-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The uvisor driver was adopted from - NetBSD 1.5 in August 2002. This manual page was - adopted from NetBSD by Tom - Rhodes - <trhodes@FreeBSD.org> - at that time.

-
-
-

-

The code to provide multiple ucom(4) instances - has not yet been ported from NetBSD. It is unclear - whether this driver works in its current state.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/uvscom.4 4.html b/static/freebsd/man4/uvscom.4 4.html deleted file mode 100644 index 79302469..00000000 --- a/static/freebsd/man4/uvscom.4 4.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
UVSCOM(4)Device Drivers ManualUVSCOM(4)
-
-
-

-

uvscom — USB - support for SUNTAC Slipper U VS-10U serial adapters driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device usb -
-device ucom -
-device uvscom
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
uvscom_load="YES"
-
-
-
-

-

The uvscom driver supports the following - adapters:

-

-
    -
  • DDI Pocket Air H" C@rd
    • -
  • DDI Pocket Air H" C@rd 64
    • -
  • NTT P-in
    • -
  • NTT P-in m@ster
    • -
-
-
-

-

The uvscom driver provides support for the - SUNTAC Slipper U VS-10U chip. Slipper U is a PC Card to USB converter for - data communication card adapters.

-

The device is accessed through the ucom(4) - driver which makes it behave like a tty(4).

-
-
-

-
-
/dev/ttyU*
-
for callin ports
-
/dev/ttyU*.init
-
 
-
/dev/ttyU*.lock
-
corresponding callin initial-state and lock-state devices -

-
-
/dev/cuaU*
-
for callout ports
-
/dev/cuaU*.init
-
 
-
/dev/cuaU*.lock
-
corresponding callout initial-state and lock-state devices
-
-
-
-

-

tty(4), ucom(4), - usb(4)

-
-
-

-

The uvscom driver first appeared in - FreeBSD and later in NetBSD - 1.6. This manual page was adopted from NetBSD - by Tom Rhodes - <trhodes@FreeBSD.org> - in April 2002.

-
-
- - - - - -
April 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/vale.4 3.html b/static/freebsd/man4/vale.4 3.html deleted file mode 100644 index 661c948c..00000000 --- a/static/freebsd/man4/vale.4 3.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - -
VALE(4)Device Drivers ManualVALE(4)
-
-
-

-

vale — a very fast - Virtual Local Ethernet using the netmap API

-
-
-

-

device netmap

-
-
-

-

vale is a feature of the - netmap(4) module that implements multiple Virtual switches - that can be used to interconnect netmap clients, including traffic sources - and sinks, packet forwarders, userspace firewalls, and so on.

-

vale is implemented completely in - software, and is extremely fast. On a modern machine it can move almost 20 - Million packets per second (Mpps) per core with small frames, and about 70 - Gbit/s with 1500 byte frames.

-
-
-

-

vale dynamically creates switches and - ports as clients connect to it using the netmap(4) - API.

-

vale ports are named - valeSSS:PPP where vale is - the prefix indicating a VALE switch rather than a standard interface, - SSS indicates a specific switch (the colon is a - separator), and PPP indicates a port within the - switch. Both SSS and PPP have the form [0-9a-zA-Z_]+ , the string cannot - exceed IFNAMSIZ characters, and PPP cannot be the name of any existing OS - network interface.

-

See netmap(4) for details on the API.

-
-

-

vale currently supports up to 254 ports - per switch. The maximum number of switches is provided by the max_bridges - sysctl variable.

-
-
-
-

-

See netmap(4) for a list of sysctl variables - that affect vale bridges.

-
-
-

-

Create one switch, with a traffic generator connected to one port, - and a netmap-enabled tcpdump instance on another port:

-
-
tcpdump -ni valea:1 &
-pkt-gen  -i valea:0 -f tx &
-
-

Create two switches, each connected to two qemu machines on - different ports.

-
-
qemu -net nic -net netmap,ifname=vale1:a ... &
-qemu -net nic -net netmap,ifname=vale1:b ... &
-qemu -net nic -net netmap,ifname=vale2:c ... &
-qemu -net nic -net netmap,ifname=vale2:d ... &
-
-
-
-

-

netmap(4), valectl(8)

-

Luigi Rizzo, Giuseppe Lettieri: VALE, a switched ethernet for - virtual machines, June 2012, http://info.iet.unipi.it/~luigi/vale/

-
-
-

-

The vale switch was designed and - implemented in 2012 by Luigi Rizzo and - Giuseppe Lettieri at the Universita` di Pisa.

-

vale was funded by the European Commission - within FP7 Projects CHANGE (257422) and OPENLAB (287581).

-
-
- - - - - -
August 30, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/veriexec.4 4.html b/static/freebsd/man4/veriexec.4 4.html deleted file mode 100644 index 80cabd7d..00000000 --- a/static/freebsd/man4/veriexec.4 4.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
VERIEXEC(4)Device Drivers ManualVERIEXEC(4)
-
-
-

-

veriexec — the - veriexec device

-
-
-

-

#include - <dev/veriexec/veriexec_ioctl.h>

-
-
-

-

The veriexec device is used by - veriexec(8) to query and modify the state of - mac_veriexec(4).

-

Once mac_veriexec(4) is active, only a process - which is marked as ‘trusted’ (normally - only veriexec(8)) is able to more than the - VERIEXEC_GETSTATE ioctl.

-
-
-

-

The supported ioctls are described below.

-
-
- struct verified_exec_params
-
Pass file information to mac_veriexec(4). -
- 
struct verified_exec_params  {
-	unsigned char flags;
-	char fp_type[VERIEXEC_FPTYPELEN];	/* type of fingerprint */
-	char file[MAXPATHLEN];
-	unsigned char fingerprint[MAXFINGERPRINTLEN];
-};
-
-
-
- struct verified_exec_label_params
-
Pass file information and a label to mac_veriexec(4). -
- 
struct verified_exec_label_params  {
-	struct verified_exec_params params;
-	char label[MAXLABELLEN];
-};
-
-
-
-
 
-
-
 
-
- int level
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
- int fd
-
Rarely needed. Tells mac_veriexec(4) that the file - associated with fd is verified.
-
-
-
-

-

A veriexec device first appeared in - NetBSD. It was added to FreeBSD - 13.1.

-
-
- - - - - -
August 1, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/vga.4 3.html b/static/freebsd/man4/vga.4 3.html deleted file mode 100644 index 562edcc0..00000000 --- a/static/freebsd/man4/vga.4 3.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - -
VGA(4)Device Drivers ManualVGA(4)
-
-
-

-

vga — generic - video card interface

-
-
-

-

options VESA -
- options VESA_DEBUG=N -
- options VGA_ALT_SEQACCESS -
- options VGA_NO_FONT_LOADING -
- options VGA_NO_MODE_CHANGE -
- options VGA_SLOW_IOACCESS -
- options VGA_WIDTH90 -
- device vga

-

In /boot/device.hints: -
- hint.vga.0.at="isa"

-
-
-

-

The vga driver is a generic video card - driver which provides access to video cards. This driver is required for the - console driver syscons(4). The console driver will call - the vga driver to manipulate video hardware - (changing video modes, loading font, etc).

-

The vga driver supports the standard video - cards: MDA, CGA, EGA and VGA. In addition, the driver can utilize VESA BIOS - extensions if the video card supports them. VESA support can either be - statically included in the kernel or can be loaded as a separate module.

-

In order to statically link the VESA support to the kernel, the - VESA option (see below) must be defined in the - kernel configuration file.

-

The vesa module can be dynamically loaded - into the kernel using kldload(8).

-
-
-

-
-

-

The following kernel configuration options (see - config(8)) can be used to control the - vga driver. These options provide compatibility with - certain VGA cards.

-
-
-
You may want to try this option if the mouse pointer is not drawn - correctly or the font does not seem to be loaded properly on the VGA card. - However, it may cause flicker on some systems.
-
-
Older VGA cards may require this option for proper operation. It makes the - driver perform byte-wide I/O to VGA registers and slow down a little.
-
-
This option enables 90 column modes: 90x25, 90x30, 90x43, 90x50, 90x60. - These modes are not always supported by the video card and the display. It - is highly likely that LCD display cannot work with these modes.
-
-

The following options add optional features to the driver.

-
-
-
Add VESA BIOS support to the driver. If the VGA card has the VESA BIOS - extension 1.2 or later, this option will utilize the VESA BIOS service to - switch to high resolution modes.
-
-
Set the VESA support debug level to N. The default - value is zero, which suppresses all debugging output.
-
-

The following options will remove some features from the - vga driver and save kernel memory.

-
-
-
The vga driver can load software font to EGA and - VGA cards. This option removes this feature. Note that if you use this - option and still wish to use the mouse on the console then you must also - use the SC_ALT_MOUSE_IMAGE option. See - syscons(4).
-
-
This option prevents the driver from changing video modes.
-
-
-
-
-

-

Your kernel configuration should normally have:

-

-
device vga
-

And you need the following line in - /boot/device.hints.

-

-
hint.vga.0.at="isa"
-

The following lines should be included in the kernel configuration - file in order to enable the VESA BIOS Extension support.

-

-
options VESA
-
device vga
-

If you do not want VESA support included in the kernel, but want - to use occasionally, do not add the VESA option. And - load the vesa module as desired:

-

-
kldload vesa
-
-
-

-

vgl(3), syscons(4), - config(8), kldload(8), - kldunload(8)

-
-
-

-

Video Electronics Standards - Association, VESA BIOS Extension - (VBE).

-
-
-

-

The vga driver first appeared in - FreeBSD 3.1.

-
-
-

-

The vga driver was written by - Søren Schmidt - <sos@FreeBSD.org> and - Kazutaka Yokota - <yokota@FreeBSD.org>. - This manual page was written by Kazutaka Yokota.

-
-
- - - - - -
June 30, 1999FreeBSD 15.0
diff --git a/static/freebsd/man4/vge.4 3.html b/static/freebsd/man4/vge.4 3.html deleted file mode 100644 index 4cc2bdf2..00000000 --- a/static/freebsd/man4/vge.4 3.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - -
VGE(4)Device Drivers ManualVGE(4)
-
-
-

-

vge — VIA - Networking Technologies Velocity Gigabit Ethernet adapter driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device vge
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vge_load="YES"
-
-
-
-

-

The vge driver provides support for - various NICs and embedded Ethernet interfaces based on the VIA Technologies - VT6120, VT6122, VT6130 and VT6132 Velocity Family Gigabit Ethernet - controller chips.

-

The VT6120/VT6122 is a 33/66MHz 64-bit PCI device which combines a - tri-speed MAC with an integrated 10/100/1000 copper PHY. (Some older cards - use an external PHY.) The VT6130/VT6132 is the PCI express version of - Velocity family. The MAC supports TCP/IP hardware checksums (IPv4 only), TCP - large send, VLAN tag insertion and stripping, as well as VLAN filtering, a - 64-entry CAM filter and a 64-entry VLAN filter, 64-bit multicast hash - filter, 4 separate transmit DMA queues, flow control and jumbo frames (not - on VT6130/VT6132) up to 16K in size. The Velocity family controllers have a - 16K receive FIFO and 48K transmit FIFO.

-

The vge driver takes advantage of the - controller's checksum offload and VLAN tagging features, as well as the - jumbo frame (except VT6130/VT6132) and CAM filter support. The CAM filter is - used for multicast address filtering to provide 64 perfect multicast address - filter support. If it is necessary for the interface to join more than 64 - multicast groups, the driver will switch over to using the hash filter.

-

The jumbo frame support can be enabled by setting the interface - MTU to any value larger than the default of 1500 bytes, up to a maximum of - 9000 bytes. Jumbo frames are disabled on the VT6130/VT6132 controllers - because the TX MAC will hang when trying to send a frame that is larger than - 4K. The receive and transmit checksum offload support can be toggled on and - off using the ifconfig(8) utility.

-

The vge driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8) - mediaopt option can also be used to select either - full-duplex or half-duplex - modes.
-
-
Set 1000baseTX operation over twisted pair. The - ifconfig(8) mediaopt option can - also be used to select either full-duplex or - half-duplex modes.
-
-

The vge driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The vge driver supports VIA Networking - VT6120, VT6122, VT6130 and VT6132 based Gigabit Ethernet adapters - including:

-

-
    -
  • VIA Networking LAN-on-motherboard Gigabit Ethernet
    • -
  • ZyXEL GN650-T 64-bit PCI Gigabit Ethernet NIC (ZX1701)
    • -
  • ZyXEL GN670-T 32-bit PCI Gigabit Ethernet NIC (ZX1702)
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vge.msi_disable
-
This tunable disables MSI support on the Ethernet hardware. The default - value is 0.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.vge.%d.int_holdoff
-
Maximum number of time to delay interrupts. The valid range is 0 to 5100 - in units of 1us, the default is 150 (150us). The resolution of timer is - about 20us so finer tuning than 20us wouldn't be available. The interface - should be brought down and up again before a change takes effect.
-
dev.vge.%d.rx_coal_pkt
-
Maximum number of packets to fire Rx completion interrupt. The valid range - is 1 to 255, the default is 64.
-
dev.vge.%d.tx_coal_pkt
-
Maximum number of packets to fire Tx completion interrupt. The valid range - is 1 to 255, the default is 128.
-
-
-
-

-
-
vge%d: couldn't map memory
-
A fatal initialization error has occurred.
-
vge%d: couldn't map ports
-
A fatal initialization error has occurred.
-
vge%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
vge%d: failed to enable memory mapping!
-
The driver failed to initialize PCI shared memory mapping. This might - happen if the card is not in a bus-master slot.
-
vge%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - vlan(4), ifconfig(8)

-
-
-

-

The vge device driver first appeared in - FreeBSD 5.3.

-
-
-

-

The vge driver was written by - Bill Paul - <wpaul@windriver.com>.

-
-
- - - - - -
May 29, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/viapm.4 3.html b/static/freebsd/man4/viapm.4 3.html deleted file mode 100644 index f0ba098c..00000000 --- a/static/freebsd/man4/viapm.4 3.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
VIAPM(4)Device Drivers ManualVIAPM(4)
-
-
-

-

viapm — VIA - chipsets Power Management controller driver

-
-
-

-

device iicbb -
- device iicbus -
- device iicsmb -
- device smbus -
- device smb -
- device viapm

-
-
-

-

This driver provides access to the VIA chipset Power Management - Unit family. They are VT82C586B, VT82C596A, VT82C596B, VT82C686A and - VT8233.

-

The embedded controller of the VIA chipset may give you access to - the monitoring facilities of your mainboard.

-

The 586B support is made by software whereas other controllers - support the SMBus protocol by hardware. See smb(4) for - writing user code to fetch voltages, temperature and so on from the - monitoring chip of your mainboard.

-
-
-

-

iicbb(4), iicbus(4), - iicsmb(4), smb(4), - smbus(4)

-
-
-

-

The viapm manual page first appeared in - FreeBSD 4.5.

-
-
-

-

This manual page was written by Nicolas - Souchu - <nsouch@FreeBSD.org>.

-
-
-

-

Only polling mode is supported.

-
-
- - - - - -
April 20, 2002FreeBSD 15.0
diff --git a/static/freebsd/man4/viawd.4 3.html b/static/freebsd/man4/viawd.4 3.html deleted file mode 100644 index ef4e4053..00000000 --- a/static/freebsd/man4/viawd.4 3.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - -
VIAWD(4)Device Drivers ManualVIAWD(4)
-
-
-

-

viawd — device - driver for VIA south bridge watchdog timer

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device viawd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
viawd_load="YES"
-
-
-
-

-

The viawd driver provides - watchdog(4) support for the watchdog interrupt timer - present on VIA south bridge chipset (VT8251, CX700, VX800, VX855, - VX900).

-

The VIA south bridge have a built-in watchdog timer, which can be - enabled and disabled by user's program and set between 1 to 1023 - seconds.

-

The viawd driver when unloaded with - running watchdog will reschedule the watchdog to 5 minutes.

-
-
-

-

watchdog(4), watchdog(8), - watchdogd(8), watchdog(9)

-
-
-

-

The viawd driver first appeared in - FreeBSD 10.0.

-
-
-

-

The viawd driver and this manual page were - written by Fabien Thomas - <fabient@FreeBSD.org>.

-
-
- - - - - -
December 7, 2011FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio.4 3.html b/static/freebsd/man4/virtio.4 3.html deleted file mode 100644 index 9a232398..00000000 --- a/static/freebsd/man4/virtio.4 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
VIRTIO(4)Device Drivers ManualVIRTIO(4)
-
-
-

-

virtio — VirtIO - Device Support

-
-
-

-

To compile VirtIO device support into the kernel, place the - following lines in your kernel configuration file:

-
device virtio -
-device virtio_pci
-

Alternatively, to load VirtIO support as modules at boot time, - place the following lines in loader.conf(5):

-
-
virtio_load="YES"
-virtio_pci_load="YES"
-
-
-
-

-

VirtIO is a specification for para-virtualized I/O in a virtual - machine (VM). Traditionally, the hypervisor emulated real devices such as an - Ethernet interface or disk controller to provide the VM with I/O. This - emulation is often inefficient.

-

VirtIO defines an interface for efficient I/O - between the hypervisor and VM. The virtio module - provides a shared memory transport called a virtqueue. The - - device driver represents an emulated PCI device that the hypervisor makes - available to the VM. This device provides the probing, configuration, and - interrupt notifications needed to interact with the hypervisor. - FreeBSD supports the following VirtIO devices:

-
-
-
An emulated Ethernet device is provided by the vtnet(4) - device driver.
-
-
An emulated disk controller is provided by the - virtio_blk(4) device driver.
-
-
Provided by the virtio_console(4) driver.
-
-
Provided by the virtio_random(4) driver.
-
-
A pseudo-device to allow the VM to release memory back to the hypervisor - is provided by the virtio_balloon(4) device driver.
-
-
Graphics support is provided by the virtio_gpu(4) device - driver.
-
-
An emulated SCSI HBA is provided by the virtio_scsi(4) - device driver.
-
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.virtio.pci.disable_msix
-
If set to 1, disables MSI-X. The default value is 0.
-
hw.virtio.pci.transitional
-
For a transitional virtio device, this tunable - specifies whether to negotiate modern mode and use the modern - virtio driver (1) or to negotiate legacy mode and - use the legacy virtio driver (0). The default - value is 1.
-
-
-
-

-

virtio_balloon(4), - virtio_blk(4), virtio_console(4), - virtio_gpu(4), virtio_random(4), - virtio_scsi(4), vtnet(4)

-
-
-

-

Support for VirtIO first appeared in FreeBSD - 9.0.

-
-
-

-

FreeBSD support for VirtIO was first added - by Bryan Venteicher - <bryanv@FreeBSD.org>.

-
-
- - - - - -
April 4, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio_balloon.4 4.html b/static/freebsd/man4/virtio_balloon.4 4.html deleted file mode 100644 index 7fc7027d..00000000 --- a/static/freebsd/man4/virtio_balloon.4 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
VIRTIO_BALLOON(4)Device Drivers ManualVIRTIO_BALLOON(4)
-
-
-

-

virtio_balloon — - VirtIO Memory Balloon driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device virtio_balloon
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
virtio_balloon_load="YES"
-
-
-
-

-

The virtio_balloon device driver provides - support for VirtIO memory balloon devices.

-

The memory balloon allows the guest to, at the request of the - hypervisor, return memory allocated to the hypervisor so it can be made - available to other guests. The hypervisor can later signal the balloon to - return the memory.

-
-
-

-

virtio(4)

-
-
-

-

The virtio_balloon driver was written by - Bryan Venteicher - <bryanv@FreeBSD.org>. - It first appeared in FreeBSD 9.0.

-
-
- - - - - -
January 22, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio_blk.4 3.html b/static/freebsd/man4/virtio_blk.4 3.html deleted file mode 100644 index a3f7d5ba..00000000 --- a/static/freebsd/man4/virtio_blk.4 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
VIRTIO_BLK(4)Device Drivers ManualVIRTIO_BLK(4)
-
-
-

-

virtio_blk — - VirtIO Block driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device virtio_blk
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
virtio_blk_load="YES"
-
-
-
-

-

The virtio_blk device driver provides - support for VirtIO block devices.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vtblk.no_ident
-
 
-
hw.vtblk.X.no_ident
-
-

These tunables disable retrieving the device identification - string from the hypervisor either globally or per-device. The default - value is 0.

-
-
hw.vtblk.writecache_mode
-
 
-
hw.vtblk.X.writecache_mode
-
-

These tunables determine the write cache mode globally or - per-device. The mode can changed only if the ConfigWCE feature is - negotiated. Set to 0 for writethrough mode, 1 for writeback mode, and -1 - to leave it as-is. The default value is to leave as-is.

-
-
-
-
-

-

The following variables are available as - sysctl(8) variables.

-
-
dev.vtblk.X.writecache_mode
-
-

The write cache mode of the device can be either writethrough - (0) or writeback (1). If the ConfigWCE feature is negotiated, the write - cache mode can be toggled between writethrough and writeback.

-
-
-
-
-

-

virtio(4)

-
-
-

-

The virtio_blk driver was written by - Bryan Venteicher - <bryanv@FreeBSD.org>. - It first appeared in FreeBSD 9.0.

-
-
- - - - - -
July 2, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio_console.4 4.html b/static/freebsd/man4/virtio_console.4 4.html deleted file mode 100644 index 61e791b3..00000000 --- a/static/freebsd/man4/virtio_console.4 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
VIRTIO_CONSOLE(4)Device Drivers ManualVIRTIO_CONSOLE(4)
-
-
-

-

virtio_console — - VirtIO Console driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device virtio_console
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
virtio_console_load="YES"
-
-
-
-

-

The virtio_console device driver provides - support for VirtIO console devices.

-

The console device may have one or more ports. Each port is - similar to a simple serial interface, and each port is accessible through - tty(4).

-
-
-

-
-
/dev/ttyV?.??
-
 
-
-
-
-

-

tty(4), virtio(4)

-
-
-

-

The virtio_console driver was written by - Bryan Venteicher - ⟨bryanv@FreeBSD.org⟩.

-
-
- - - - - -
October 22, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio_gpu.4 4.html b/static/freebsd/man4/virtio_gpu.4 4.html deleted file mode 100644 index ad0af229..00000000 --- a/static/freebsd/man4/virtio_gpu.4 4.html +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - -
VIRTIO_GPU(4)Device Drivers ManualVIRTIO_GPU(4)
-
-
-

-

virtio_gpu — - VirtIO GPU driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device virtio_gpu
-
-
-

-

The virtio_gpu device driver provides - support for VirtIO gpu devices to create a vt(4) - console.

-
-
-

-

virtio(4), vt(4)

-
-
-

-

The virtio_gpu driver first appeared in - FreeBSD 14.0.

-
-
- - - - - -
August 14, 2023FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio_random.4 4.html b/static/freebsd/man4/virtio_random.4 4.html deleted file mode 100644 index 9ab422a1..00000000 --- a/static/freebsd/man4/virtio_random.4 4.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
VIRTIO_RANDOM(4)Device Drivers ManualVIRTIO_RANDOM(4)
-
-
-

-

virtio_random — - VirtIO Entropy driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device virtio_random
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
virtio_random_load="YES"
-
-
-
-

-

The virtio_random device driver provides - support for VirtIO entropy devices.

-

The entropy device supplies high-quality randomness from the - hypervisor to the guest.

-
-
-

-

random(4), virtio(4)

-
-
-

-

The virtio_random driver was written by - Bryan Venteicher - <bryanv@FreeBSD.org>.

-
-
- - - - - -
December 28, 2013FreeBSD 15.0
diff --git a/static/freebsd/man4/virtio_scsi.4 4.html b/static/freebsd/man4/virtio_scsi.4 4.html deleted file mode 100644 index 155ff395..00000000 --- a/static/freebsd/man4/virtio_scsi.4 4.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - -
VIRTIO_SCSI(4)Device Drivers ManualVIRTIO_SCSI(4)
-
-
-

-

virtio_scsi — - VirtIO SCSI driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device virtio_scsi
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
virtio_scsi_load="YES"
-
-
-
-

-

The virtio_scsi device driver provides - support for VirtIO SCSI devices.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vtscsi.bus_reset_disable
-
In the initial QEMU release with VirtIO SCSI support, in-flight operations - were not aborted when stopping the device, rendering bus reset - ineffective. This tunable disables attempts to issue reset bus commands. - The default value is 1.
-
-
-
-

-

To enable debugging prints from the - virtio_scsi driver, set the

-
-
hw.vtscsi.X.debug_level
-
-

variable, where X is the adapter number, either in - loader.conf(5) or via sysctl(8). The - following bits have the described effects:

-
-
-
0x01
-
Enable informational prints.
-
0x02
-
Enable prints for driver errors.
-
0x04
-
Enable tracing prints.
-
-
-
-
-

-

virtio(4)

-
-
-

-

The virtio_scsi driver was written by - Bryan Venteicher - <bryanv@FreeBSD.org>. - It first appeared in FreeBSD 10.0.

-
-
- - - - - -
June 24, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/vkbd.4 3.html b/static/freebsd/man4/vkbd.4 3.html deleted file mode 100644 index ed21f7a7..00000000 --- a/static/freebsd/man4/vkbd.4 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
VKBD(4)Device Drivers ManualVKBD(4)
-
-
-

-

vkbd — the virtual - AT keyboard interface

-
-
-

-

device vkbd

-
-
-

-

The vkbd interface is a software loopback - mechanism that can be loosely described as the virtual AT keyboard analog of - the pty(4), that is, vkbd does for - virtual AT keyboards what the pty(4) driver does for - terminals.

-

The vkbd driver, like the - pty(4) driver, provides two interfaces: a keyboard - interface like the usual facility it is simulating (a virtual AT keyboard in - the case of vkbd, or a terminal for - pty(4)), and a character-special device - “control” interface.

-

The virtual AT keyboards are named vkbd0, - vkbd1, etc., one for each control device that has - been opened.

-

The vkbd interface permits opens on the - special control device /dev/vkbdctl. When this - device is opened, vkbd will return a handle for the - lowest unused vkbdctl device (use - devname(3) to determine which).

-

Each virtual AT keyboard supports the usual keyboard interface - ioctl(2)s, and thus can be used with - kbdcontrol(1) like any other keyboard. The control device - supports exactly the same ioctl(2)s as the virtual AT - keyboard device. Writing AT scan codes to the control device generates an - input on the virtual AT keyboard, as if the (non-existent) hardware had just - received it.

-

The virtual AT keyboard control device, normally - /dev/vkbdctl⟨N⟩, - is exclusive-open (it cannot be opened if it is already open) and is - restricted to the super-user. A read(2) call will return - the virtual AT keyboard status structure (defined in - <dev/vkbd/vkbd_var.h>) if - one is available; if not, it will either block until one is or return - EWOULDBLOCK, depending on whether non-blocking I/O - has been enabled.

-

A write(2) call passes AT scan codes to be - “received” from the virtual AT keyboard. Each AT scan code - must be passed as unsigned int. Although AT scan codes - must be passes as unsigned ints, the size of the - buffer passed to write(2) still should be in bytes, - i.e.,

-
-
static unsigned int     codes[] =
-{
-/*      Make    Break */
-        0x1e,   0x9e
-};
-
-int
-main(void)
-{
-        int     fd, len;
-
-        fd = open("/dev/vkbdctl0", O_RDWR);
-        if (fd < 0)
-                err(1, "open");
-
-        /* Note sizeof(codes) - not 2! */
-        len = write(fd, codes, sizeof(codes));
-        if (len < 0)
-                err(1, "write");
-
-        close(fd);
-
-        return (0);
-}
-
-

Write will block if there is not enough space in the input - queue.

-

The control device also supports select(2) for - read and write.

-

On the last close of the control device, the virtual AT keyboard - is removed. All queued scan codes are thrown away.

-
-
-

-

kbdcontrol(1), atkbdc(4), - psm(4), syscons(4), - vt(4)

-
-
-

-

The vkbd module was implemented in - FreeBSD 6.0.

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
-

-

The vkbd interface is a software loopback - mechanism, and, thus ddb(4) will not work with it. Current - implementation of the syscons(4) driver can accept input - from only one keyboard, even if it is virtual. Thus it is not possible to - have both wired and virtual keyboard to be active at the same time. It is, - however, in principal possible to obtain AT scan codes from the different - sources and write them into the same virtual keyboard. The virtual keyboard - state synchronization is the user's responsibility.

-
-
- - - - - -
August 12, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/vlan.4 3.html b/static/freebsd/man4/vlan.4 3.html deleted file mode 100644 index 21d529ed..00000000 --- a/static/freebsd/man4/vlan.4 3.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - -
VLAN(4)Device Drivers ManualVLAN(4)
-
-
-

-

vlan — IEEE 802.1Q - VLAN network interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device vlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vlan_load="YES"
-
-
-
-

-

The vlan driver demultiplexes frames - tagged according to the IEEE 802.1Q standard into logical - vlan network interfaces, which allows - routing/bridging between multiple VLANs through a single switch trunk - port.

-

Each vlan interface is created at runtime - using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5).

-

To function, a vlan interface must be - assigned a parent interface and numeric VLAN tag using - ifconfig(8). A single parent can be assigned to multiple - vlan interfaces provided they have different tags. - The parent interface is likely to be an Ethernet card connected to a - properly configured switch port. The VLAN tag should match one of those set - up in the switched network.

-

vlan initially assumes the same minimum - length for tagged and untagged frames. This mode is selected by setting the - sysctl(8) variable - net.link.vlan.soft_pad to 0 (default). However, there - are network devices that fail to adjust frame length when it falls below the - allowed minimum due to untagging. Such devices should be able to - interoperate with vlan after changing the value of - net.link.vlan.soft_pad to 1. In the latter mode, - vlan will pad short frames before tagging them so - that their length is not less than the minimum value after untagging by the - non-compliant devices.

-
-
-

-

The vlan driver supports efficient - operation over parent interfaces that can provide help in processing VLANs. - Such interfaces are automatically recognized by their capabilities. - Depending on the level of sophistication found in a physical interface, it - may do full VLAN processing or just be able to receive and transmit long - frames (up to 1522 bytes including an Ethernet header and FCS). The - capabilities may be user-controlled by the respective parameters to - ifconfig(8), vlanhwtag, and - vlanmtu. However, a physical interface is not - obliged to react to them: It may have either capability enabled permanently - without a way to turn it off. The whole issue is very specific to a - particular device and its driver.

-

At present, these devices are capable of full VLAN processing in - hardware: ae(4), age(4), - alc(4), ale(4), - bce(4), bge(4), - bxe(4), cxgb(4), - cxgbe(4), em(4), - igb(4), ix(4), jme(4), - liquidio(4), msk(4), - mxge(4), nge(4), - re(4), sge(4), - stge(4), ti(4), and - vge(4).

-

Other Ethernet interfaces can run VLANs using software emulation - in the vlan driver. However, some lack the - capability of transmitting and receiving long frames. Assigning such an - interface as the parent to vlan will result in a - reduced MTU on the corresponding vlan interfaces. In - the modern Internet, this is likely to cause tcp(4) - connectivity problems due to massive, inadequate icmp(4) - filtering that breaks the Path MTU Discovery mechanism.

-

These interfaces natively support long frames for - vlan: axe(4), - bfe(4), cas(4), dc(4), - et(4), fwe(4), fxp(4), - gem(4), le(4), nfe(4), - rl(4), sis(4), sk(4), - ste(4), vr(4), vte(4), - and xl(4).

-

The vlan driver automatically recognizes - devices that natively support long frames for vlan - use and calculates the appropriate frame MTU based on the capabilities of - the parent interface. Some other interfaces not listed above may handle long - frames, but they do not advertise this ability. The MTU setting on - vlan can be corrected manually if used in - conjunction with such a parent interface.

-
-
-

-

ifconfig(8), sysctl(8)

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/vmci.4 3.html b/static/freebsd/man4/vmci.4 3.html deleted file mode 100644 index f81c2ce8..00000000 --- a/static/freebsd/man4/vmci.4 3.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - -
VMCI(4)Device Drivers ManualVMCI(4)
-
-
-

-

vmci — VMware - Virtual Machine Communication Interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device vmci
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vmci_load="YES"
-
-
-
-

-

The vmci driver provides support for the - VMware Virtual Machine Communication Interface (VMCI) in virtual machines by - VMware.

-

VMCI allows virtual machines to communicate with host kernel - modules and the VMware hypervisors. User level applications in a virtual - machine can use VMCI through vSockets (also known as VMCI Sockets and not - included in this kernel module), a socket address family designed to be - compatible with UDP and TCP at the interface level. Today, VMCI and vSockets - are used by various VMware Tools components inside the guest for - zero-config, network-less access to VMware host services. In addition to - this, VMware's users are using vSockets for various applications, where - network access of the virtual machine is restricted or non-existent. - Examples of this are VMs communicating with device proxies for proprietary - hardware running as host applications and automated testing of applications - running within virtual machines.

-

In a virtual machine, VMCI is exposed as a regular PCI device. The - primary communication mechanisms supported are a point-to-point - bidirectional transport based on a pair of memory-mapped queues, and - asynchronous notifications in the form of datagrams and doorbells. These - features are available to kernel level components such as vSockets through - the VMCI kernel API. In addition to this, the VMCI kernel API provides - support for receiving events related to the state of the VMCI communication - channels, and the virtual machine itself.

-
-
-

-

socket(2), pci(9)

-

VMware vSockets - Documentation, - https://www.vmware.com/support/developer/vmci-sdk/.

-
-
-

-

The vmci driver first appeared in - FreeBSD 12.0.

-
-
-

-

The vmci driver and man page were written - by Vishnu Dasa - <vdasahar@gmail.com>.

-
-
- - - - - -
February 10, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/vmd.4 4.html b/static/freebsd/man4/vmd.4 4.html deleted file mode 100644 index 2d2a699c..00000000 --- a/static/freebsd/man4/vmd.4 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
VMD(4)Device Drivers ManualVMD(4)
-
-
-

-

vmd — Intel Volume - Management Device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device vmd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
vmd_load="YES"
-
-
-
-

-

This driver attaches to Intel VMD devices, representing them as - PCI-to-PCI bridges and providing access to children PCI devices via new PCI - domains. Intel VMD is used by Intel's VROC (Virtual RAID on chip) to manage - NVMe drives.

-
-
-

-

The following tunables are settable via - loader(8) or sysctl(8):

-
-
hw.vmd.bypass_msi
-
By default all VMD devices remap children MSI/MSI-X interrupts into their - own. It creates additional isolation, but also complicates things due to - sharing, etc. Fortunately some VMD devices can bypass the remapping. - Defaults to 1.
-
hw.vmd.max_msi
-
Limits number of Message Signaled Interrupt (MSI) vectors allowed to each - child device. VMD can't distinguish MSI vectors of the same device, so - there are no benefits to have more than one, unless it is required by - specific device driver. Defaults to 1.
-
hw.vmd.max_msix
-
Limits number of Extended Message Signaled Interrupt (MSI-X) vectors - allowed to each child device. VMD has limited number of interrupt vectors - to map children interrupts into, so to avoid/reduce sharing children - devices/drivers need to be constrained. Defaults to 3.
-
-
-
-

-

graid(8)

-
-
-

-

The vmd driver first appeared in - FreeBSD 13.0.

-
-
- - - - - -
October 6, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/vmgenc.4 3.html b/static/freebsd/man4/vmgenc.4 3.html deleted file mode 100644 index 69cf01a3..00000000 --- a/static/freebsd/man4/vmgenc.4 3.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - -
VMGENC(4)Device Drivers ManualVMGENC(4)
-
-
-

-

vmgenc — ACPI - virtual machine generation ID counter

-
-
-

-

device vmgenc

-

In loader.conf(5): -
- vmgenc_load="YES"

-
-
-

-

The vmgenc driver provides support for the - Virtual Machine Generation ID, a 128-bit unique identifier exposed by the - hypervisor via ACPI. The hypervisor changes this identifier whenever the - virtual machine is cloned, restored from a snapshot, or otherwise - duplicated.

-

When a generation ID change is detected, the - vmgenc driver feeds the new identifier into the - kernel entropy pool via random(4), ensuring that - duplicated virtual machines do not share cryptographic state. The driver - also sends a devctl(4) event and an internal kernel - notification so that other subsystems can respond to the duplication.

-

The Virtual Machine Generation ID specification is supported by - QEMU, VMware ESXi, Microsoft Hyper-V, and Xen.

-
-
-

-

The following variable is available:

-
-
dev.vmgenc.%d.guid
-
The current cached VM generation counter as a 128-bit value. This value is - updated each time the hypervisor signals a generation change.
-
-
-
-

-

acpi(4), random(4)

-
-
-

-

The vmgenc driver first appeared in - FreeBSD 13.0.

-
-
-

-

The vmgenc driver was written by - Conrad Meyer - <cem@FreeBSD.org>.

-

This manual page was written by -
- Christos Longros - <chris.longros@gmail.com>.

-
-
- - - - - -
March 21, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/vmm.4 3.html b/static/freebsd/man4/vmm.4 3.html deleted file mode 100644 index 12cb9dcf..00000000 --- a/static/freebsd/man4/vmm.4 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
VMM(4)Device Drivers ManualVMM(4)
-
-
-

-

vmm.ko — bhyve - virtual machine monitor

-
-
-

-

To load the driver as a module at boot, add this line to - loader.conf(5):

-
-
vmm_load="YES"
-
-

The module can also be loaded manually with - kldload(8):

-
-
kldload vmm
-
-
-
-

-

vmm.ko provides the kernel portion of the - bhyve(4) hypervisor. The following platforms are - supported:

-
    -
  • amd64: An Intel CPU with VT-x/EPT or AMD CPU with SVM support is - required.
    • -
  • arm64: The boot CPU must start in EL2 and the system must have a GICv3 - interrupt controller. VHE support will be used if available.
    • -
  • riscv: The CPUs must implement the H (hypervisor) RISC-V ISA - extension.
    • -
-

PCI device passthrough to a virtual machine requires hardware with - VT-d support and is available only on amd64.

-
-
-

-

Only the super-user and processes with write access to the - /dev/vmmctl device file may create and destroy - virtual machines. By default, members of the vmm group - have such access. Once created, a virtual machine may be destroyed only by - that user or the super-user.

-

Unprivileged users must use “monitor mode” to run - the virtual machine; in this mode, the virtual machine is automatically - destroyed when its device file is closed. When running - bhyve(8), this mode can be selected by specifying the - -M flag.

-

Virtual machines can be created in a jail if the jail has the - allow.vmm flag set.

-
-
-

-

On amd64 where the hardware supports VT-d, PCI devices can be - reserved for use by the hypervisor. Entries consisting of the PCI - bus/slot/function - are added to the pptdevs - loader.conf(5) variable. Additional entries are separated - by spaces. Host PCI devices that match an entry will be assigned to the - hypervisor and will not be probed by FreeBSD device - drivers. See the EXAMPLES section below - for sample usage.

-

Note that vmm must be given first the - right of refusal to all pci(4) devices it may need to - claim. As a result, the vmm kernel module almost - certainly needs to be loaded from loader.conf(5) rather - than by adding it to kld_list in - rc.conf(5).

-

A large number of PCI device entries may require a string longer - than the 128-character limit of loader.conf(5) variables. - The pptdevs2 and pptdevs3 - variables can be used for additional entries.

-

In general, PCI passthrough cannot be used when running - bhyve(8) as an unprivileged user or in a jail, as this - feature requires write access to /dev/pci.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vmm.maxcpu
-
Maximum number of virtual CPUs. The default is the number of physical CPUs - in the system.
-
-
-
-

-
-
/dev/vmmctl
-
control interface for creating and destroying virtual machines.
-
/dev/vmm/*
-
device interface for individual virtual machines.
-
/dev/vmm.io/*
-
device interface for device memory mapped into virtual machines.
-
-
-
-

-

Reserve three PCI devices for use by the hypervisor: bus 10 slot 0 - function 0, bus 6 slot 5 function 0, and bus 6 slot 5 function 1.

-
-
pptdevs="10/0/0 6/5/0 6/5/1"
-
-

It is possible to detach ppt from a PCI - device without rebooting the host machine and then attach a host driver, - using the devctl(8) utility. Suppose - ppt is currently attached to - pci0:0:1:0 and we want the host's - xhci(4) driver to be attached instead:

-
-
# devctl set driver -f pci0:0:1:0 xhci
-
-

The same can be applied to attach ppt - back:

-
-
# devctl set driver -f pci0:0:1:0 ppt
-
-
-
-

-

bhyve(4), loader.conf(5), - bhyve(8), bhyvectl(8), - bhyveload(8), devctl(8), - jail(8), kldload(8)

-
-
-

-

vmm.ko first appeared in - FreeBSD 10.0. arm64 and riscv support first appeared - in FreeBSD 15.0.

-
-
-

-

Neel Natu ⟨neel@freebsd.org⟩ -
- Peter Grehan ⟨grehan@freebsd.org⟩

-
-
- - - - - -
December 30, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/vmx.4 3.html b/static/freebsd/man4/vmx.4 3.html deleted file mode 100644 index 18a5a466..00000000 --- a/static/freebsd/man4/vmx.4 3.html +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - -
VMX(4)Device Drivers ManualVMX(4)
-
-
-

-

vmx — VMware - VMXNET3 Virtual Interface Controller device

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device iflib -
-device vmx
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vmx_load="YES"
-
-
-
-

-

The vmx driver provides support for the - VMXNET3 virtual NIC available in virtual machines by VMware. It appears as a - simple Ethernet device but is actually a virtual network interface to the - underlying host operating system.

-

This driver supports the VMXNET3 driver - protocol, as an alternative to the emulated le(4), - em(4) interfaces also available in the VMware environment. - The vmx driver is optimized for the virtual machine, - it can provide advanced capabilities depending on the underlying host - operating system and the physical network interface controller of the host. - The vmx driver supports features like multiqueue - support, IPv6 checksum offloading, MSI/MSI-X support and hardware VLAN - tagging in VMware's VLAN Guest Tagging (VGT) mode.

-

The vmx driver supports VMXNET3 VMware - virtual NICs provided by the virtual machine hardware version 7 or newer, as - provided by the following products:

-

-
    -
  • VMware ESX/ESXi 4.0 and newer
    • -
  • VMware Server 2.0 and newer
    • -
  • VMware Workstation 6.5 and newer
    • -
  • VMware Fusion 2.0 and newer
    • -
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The vmx driver supports multiple transmit - and receive queues. Multiple queues are only supported by certain VMware - products, such as ESXi. The number of queues allocated depends on the - presence of MSI-X, the number of configured CPUs, and the tunables listed - below. FreeBSD does not enable MSI-X support on - VMware by default. The hw.pci.honor_msi_blacklist - tunable must be disabled to enable MSI-X support.

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vmx.txnqueue
-
 
-
hw.vmx.X.txnqueue
-
Maximum number of transmit queues allocated by default by the driver. The - default value is 8. The maximum supported by the VMXNET3 virtual NIC is - 8.
-
hw.vmx.rxnqueue
-
 
-
hw.vmx.X.rxnqueue
-
Maximum number of receive queues allocated by default by the driver. The - default value is 8. The maximum supported by the VMXNET3 virtual NIC is - 16.
-
hw.vmx.txndesc
-
 
-
hw.vmx.X.txndesc
-
-

Number of transmit descriptors allocated by the driver. The - default value is 512. The value must be a multiple of 32, and the - maximum is 4096.

-
-
hw.vmx.rxndesc
-
 
-
hw.vmx.X.rxndesc
-
-

Number of receive descriptors per ring allocated by the - driver. The default value is 256. The value must be a multiple of 32, - and the maximum is 2048. There are two rings so the actual usage is - doubled.

-
-
-
-
-

-

The following entry must be added to the VMware configuration file - to provide the vmx device:

-
-
ethernet0.virtualDev = "vmxnet3"
-
-
-
-

-

altq(4), arp(4), - em(4), iflib(4), - le(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-
-
-

-

The vmx driver was ported from - OpenBSD and significantly rewritten by - Bryan Venteicher - <bryanv@freebsd.org>. - The OpenBSD driver was written by - Tsubai Masanari.

-
-
- - - - - -
December 26, 2020FreeBSD 15.0
diff --git a/static/freebsd/man4/vr.4 3.html b/static/freebsd/man4/vr.4 3.html deleted file mode 100644 index 3ed5ab38..00000000 --- a/static/freebsd/man4/vr.4 3.html +++ /dev/null @@ -1,165 +0,0 @@ - - - - - - -
VR(4)Device Drivers ManualVR(4)
-
-
-

-

vr — VIA - Technologies Rhine I/II/III Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device vr
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vr_load="YES"
-
-
-
-

-

The vr driver provides support for PCI - Ethernet adapters and embedded controllers based on the VIA Technologies - VT3043 Rhine I, VT86C100A Rhine II, and VT6105/VT6105M Rhine III Fast - Ethernet controller chips.

-

The VIA Rhine chips use bus master DMA and have a descriptor - layout designed to resemble that of the DEC 21x4x “tulip” - chips. The register layout is different however and the receive filter in - the Rhine chips is much simpler and is programmed through registers rather - than by downloading a special setup frame through the transmit DMA engine. - Transmit and receive DMA buffers must be longword aligned. The Rhine chips - are meant to be interfaced with external physical layer devices via an MII - bus. They support both 10 and 100Mbps speeds in either full or half - duplex.

-

The vr driver supports the following media - types:

-
-
autoselect
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to the - /etc/rc.conf file.
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to select either full-duplex - or half-duplex modes.
-
-

The vr driver supports the following media - options:

-
-
full-duplex
-
Force full duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

Note that the 100baseTX media type is only available if supported - by the adapter. For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The vr driver supports VIA Technologies - Rhine I, Rhine II, and Rhine III based Fast Ethernet adapters including:

-

-
    -
  • AOpen/Acer ALN-320
    • -
  • D-Link DFE520-TX
    • -
  • D-Link DFE530-TX
    • -
  • Hawking Technologies PN102TX
    • -
  • Soekris Engineering net5501
    • -
-
-
-

-

The following variables are available as - sysctl(8) variables:

-
-
dev.vr.%d.stats
-
Display lots of useful MAC counters maintained in the driver.
-
-
-
-

-
-
vr%d: couldn't map memory
-
A fatal initialization error has occurred.
-
vr%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
vr%d: watchdog timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
vr%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
vr%d: no memory for tx list
-
The driver failed to allocate an mbuf for the transmitter ring when - allocating a pad buffer or collapsing an mbuf chain into a cluster.
-
vr%d: chip is in D3 power state -- setting to D0
-
This message applies only to adapters which support power management. Some - operating systems place the controller in low power mode when shutting - down, and some PCI BIOSes fail to bring the chip out of this state before - configuring it. The controller loses all of its PCI configuration in the - D3 state, so if the BIOS does not set it back to full power mode in time, - it will not be able to configure it correctly. The driver tries to detect - this condition and bring the adapter back to the D0 (full power) state, - but this may not be enough to return the driver to a fully operational - condition. If you see this message at boot time and the driver fails to - attach the device as a network interface, you will have to perform second - warm boot to have the device properly configured. -

Note that this condition only occurs when warm booting from - another operating system. If you power down your system prior to booting - FreeBSD, the card should be configured - correctly.

-
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), polling(4), - ifconfig(8)

-

The VIA Technologies VT86C100A - data sheet, - http://www.via.com.tw.

-
-
-

-

The vr device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The vr driver was written by - Bill Paul - <wpaul@ctr.columbia.edu>.

-
-
-

-

The vr driver always copies transmit mbuf - chains into longword-aligned buffers prior to transmission in order to - pacify the Rhine chips. If buffers are not aligned correctly, the chip will - round the supplied buffer address and begin DMAing from the wrong location. - This buffer copying impairs transmit performance on slower systems but - cannot be avoided. On faster machines (e.g. a Pentium II), the performance - impact is much less noticeable.

-
-
- - - - - -
February 25, 2012FreeBSD 15.0
diff --git a/static/freebsd/man4/vt.4 3.html b/static/freebsd/man4/vt.4 3.html deleted file mode 100644 index ea8187d9..00000000 --- a/static/freebsd/man4/vt.4 3.html +++ /dev/null @@ -1,465 +0,0 @@ - - - - - - -
VT(4)Device Drivers ManualVT(4)
-
-
-

-

vt — virtual - terminal system video console driver

-
-
-

-

options - TERMINAL_KERN_ATTR=⟨attribute⟩ -
- options - TERMINAL_NORM_ATTR=⟨attribute⟩ -
- options - VT_MAXWINDOWS=⟨N⟩ -
- options VT_ALT_TO_ESC_HACK=1 -
- options VT_TWOBUTTON_MOUSE -
- options - VT_FB_MAX_WIDTH=⟨X⟩ -
- options - VT_FB_MAX_HEIGHT=⟨Y⟩ -
- options SC_NO_CUTPASTE -
- device vt

-

In loader.conf(5): -
- hw.vga.textmode=1 -
- hw.vga.acpi_ignore_no_vga=1 -
- kern.vty=vt -
- kern.vt.color.⟨colornum⟩.rgb=⟨colorspec⟩ -
- kern.vt.fb.default_mode=⟨X⟩x⟨Y⟩ -
- kern.vt.fb.modes.⟨connector⟩=⟨X⟩x⟨Y⟩ -
- kern.vt.slow_down=⟨delay⟩ -
- screen.font=⟨X⟩x⟨Y⟩

-

In loader.conf(5) or - sysctl.conf(5): -
- kern.consmute=1 -
- kern.vt.kbd_halt=1 -
- kern.vt.kbd_poweroff=1 -
- kern.vt.kbd_reboot=1 -
- kern.vt.kbd_debug=1 -
- kern.vt.kbd_panic=0 -
- kern.vt.enable_altgr=0 -
- kern.vt.enable_bell=1

-
-
-

-

The vt device provides multiple virtual - terminals with an extensive feature set:

-
    -
  • Unicode UTF-8 text with double-width characters.
    • -
  • Large font maps in graphics mode, including support for Asian character - sets.
    • -
  • Graphics-mode consoles.
    • -
  • Integration with KMS (Kernel Mode Setting) video drivers for - switching between the and virtual terminals.
    • -
-
-

-

Multiple virtual terminals are provided on a single computer. Up - to sixteen virtual terminals can be defined. A single virtual terminal is - connected to the screen and keyboard at a time. Key combinations are used to - select a virtual terminal. Alt-F1 through Alt-F12 correspond to the first - twelve virtual terminals. If more than twelve virtual terminals are created, - Shift-Alt-F1 through Shift-Alt-F4 are used to switch to the additional - terminals.

-
-
-

-

Copying and pasting text from the screen with a mouse is - supported. Press and hold down mouse button 1, usually the left button, - while moving the mouse to select text. Selected text is highlighted with - reversed foreground and background colors. To select more text after - releasing mouse button 1, press mouse button 3, usually the right button. To - paste text that has been selected, press mouse button 2, usually the middle - button. The text is entered as if it were typed at the keyboard. The - VT_TWOBUTTON_MOUSE kernel option can be used with - mice that only have two buttons. Setting this option makes the second mouse - button into the paste button. See moused(8) for more - information.

-
-
-

-

Output that has scrolled off the screen can be reviewed by - pressing the Scroll Lock key, then scrolling up and down with the arrow - keys. The Page Up and Page Down keys scroll up or down a full screen at a - time. The Home and End keys jump to the beginning or end of the scrollback - buffer. When finished reviewing, press the Scroll Lock key again to return - to normal use. Some laptop keyboards lack a Scroll Lock key, and use a - special function key sequence (such as Fn + K) to access Scroll Lock.

-
-
-
-

-
-

-

These kernel options control the vt - driver.

-
-
⟨attribute⟩
-
 
-
⟨attribute⟩
-
These options change the default colors used for normal and kernel text. - Available colors are defined in - <sys/terminal.h>. See - EXAMPLES below.
-
⟨N⟩
-
Set the number of virtual terminals to be created to - N. The value defaults to 12.
-
1
-
When the Alt key is held down while pressing another key, send an ESC - sequence instead of the Alt key.
-
-
If defined, swap the functions of mouse buttons 2 and 3. In effect, this - makes the right-hand mouse button perform a paste. These options are - checked in the order shown.
-
-
Disable mouse support.
-
VT_FB_MAX_WIDTH=⟨X⟩
-
Set the maximum width to X.
-
VT_FB_MAX_HEIGHT=⟨Y⟩
-
Set the maximum height to Y.
-
-
-
-
-

-

Several options are provided for compatibility with the previous - console device, sc(4). These options will be removed in a - future FreeBSD version.

- - - - - - - - - - - - - - - - - - - - - - - - - -
none
-
-
-

-

The computer BIOS starts in text mode, and the - FreeBSD loader(8) runs, loading - the kernel. If hw.vga.textmode is set, the system - remains in text mode. Otherwise, vt switches to - 640x480x16 VGA mode using vt_vga. If a KMS (Kernel - Mode Setting) video driver is available, the display is switched to high - resolution and the KMS driver takes over. When a KMS driver is not - available, vt_vga remains active.

-
-
-

-

These settings can be entered at the loader(8) - prompt or in loader.conf(5).

-
-
hw.vga.textmode
-
Set to 1 to use virtual terminals in text mode instead of graphics mode on - BIOS boot. Features that require graphics mode, like loadable fonts, will - be disabled. -

If a KMS driver is loaded the console will switch to, and - remain in, graphics mode. Moreover this tunable has no effect with - UEFI(8) boot because it does not use VGA mode.

-
-
hw.vga.acpi_ignore_no_vga
-
Set to 1 to force the usage of the VGA driver regardless of whether ACPI - IAPC_BOOT_ARCH signals no VGA support. Can be used to workaround firmware - bugs in the ACPI tables. Note no VGA support is only acknowledged when - running virtualized. There is too many broken firmware that wrongly - reports no VGA support on physical hardware.
-
kern.vty
-
Set this value to ‘vt’ or - ‘sc’ to choose a specific system - console, overriding the default. The GENERIC - kernel uses vt when this value is not set. Note - that ‘sc’ is not compatible with - UEFI(8) boot.
-
kern.vt.color.colornum.rgb
-
Set this value to override default palette entry for color - colornum which should be in a range from 0 to 15 - inclusive. The value should be either a comma-separated triplet of red, - green, and blue values in a range from 0 to 255 or HTML-like hex triplet. - See EXAMPLES below. -

Note: The vt VGA hardware driver does - not support palette configuration.

-
-
kern.vt.fb.default_mode
-
Set this value to a graphic mode to override the default picked by the - vt backend. The mode is applied to all output - connectors. This is currently only supported by the - vt_fb backend when it is paired with a KMS video - driver.
-
kern.vt.fb.modes.⟨connector_name⟩
-
Set this value to a graphic mode to override the default picked by the - vt backend. This mode is applied to the output - connector connector_name only. It has precedence - over kern.vt.fb.default_mode. The names of available - connector names can be found in dmesg(8) after loading - the KMS driver. It will contain a list of connectors and their associated - tunables. This is currently only supported by the - vt_fb backend when it is paired with a KMS video - driver.
-
kern.vt.slow_down
-
When debugging the kernel on modern laptops, the screen is often the only - available console, and relevant information will scroll out of view before - it can be captured by eye or camera. -

Setting kern.vt.slow_down to a non-zero - number will make console output synchronous (ie: not dependent on timers - and interrupts) and slow it down in proportion to the number.

-
-
screen.font
-
Set this value to the base name of the desired font file located in - /boot/fonts. The font must be specified in the - INDEX.fonts file located there. Fonts can be - converted for use with vtfontcvt(8).
-
-
-
-

-

These settings control whether certain special key combinations - are enabled or ignored. The specific key combinations can be configured by - using a keymap(5) file.

-

These settings can be entered at the loader(8) - prompt or in loader.conf(5) and can also be changed at - runtime with the sysctl(8) command.

-
-
kern.vt.enable_altgr
-
Enable AltGr key (do not assume right Alt key as Alt).
-
kern.vt.kbd_halt
-
Enable halt keyboard combination.
-
kern.vt.kbd_poweroff
-
Enable power off key combination.
-
kern.vt.kbd_reboot
-
Enable reboot key combination, usually Ctrl+Alt+Del.
-
kern.vt.kbd_debug
-
Enable debug request key combination, usually Ctrl+Alt+Esc.
-
kern.vt.kbd_panic
-
Enable panic key combination.
-
-
-
-

-

These settings can be entered at the loader(8) - prompt, set in loader.conf(5), or changed at runtime with - sysctl(8).

-
-
kern.consmute
-
Disable printing kernel messages to the system console.
-
kern.vt.enable_bell
-
Enable the terminal bell.
-
-
-
-

-
-
/dev/console
-
 
-
/dev/consolectl
-
 
-
/dev/ttyv*
-
virtual terminals
-
/etc/ttys
-
terminal initialization information
-
/usr/share/vt/fonts/*.fnt
-
console fonts
-
/usr/share/vt/keymaps/*.kbd
-
keyboard layouts
-
-
-
-

- - - - - - - - - - - - - -
BELLRINGNotification that the console bell has rung.
- - - - - - - - - - - - - - - - - - - - - -
Length of time the bell was requested to ring in milliseconds.
true or false indicating whether or not the bell was administratively - enabled when rung.
true or false indicating whether or not the bell was quieted by the user - when rung.
Tone that was requested in Hz.
-
-
-

-

To increase the scrollback buffer size to 22500 lines, add the - following line to /etc/rc.conf:

-

-
allscreens_flags="-h - 22500"
-

This example changes the default color of normal text to green on - a black background, or black on a green background when reversed. Note that - white space cannot be used inside the attribute string because of the - current implementation of config(8).

-

-
options - TERMINAL_NORM_ATTR=(FG_GREEN|BG_BLACK)
-

This line changes the default color of kernel messages to be - bright red on a black background, or black on a bright red background when - reversed.

-

-
options - TERMINAL_KERN_ATTR=(FG_LIGHTRED|BG_BLACK)
-

To set a 1024x768 mode on all output connectors, put the following - line in /boot/loader.conf:

-

-
kern.vt.fb.default_mode="1024x768"
-

To set a 800x600 only on a laptop builtin screen, use the - following line instead:

-

-
kern.vt.fb.modes.LVDS-1="800x600"
-

The connector name was found in dmesg(8):

-

-
info: [drm] Connector LVDS-1: get - mode from tunables:
-
info: [drm] - - kern.vt.fb.modes.LVDS-1
-
info: [drm] - - kern.vt.fb.default_mode
-

To set black and white colors of console palette

-

-
kern.vt.color.0.rgb="10,10,10"
-
kern.vt.color.15.rgb="#f0f0f0"
-

Load the 8x16 font in loader.conf(5) from - /boot/fonts/*.fnt[.gz] at boot:

-

-
screen.font="8x16"
-
-
-

-

kbdcontrol(1), login(1), - vidcontrol(1), atkbd(4), - atkbdc(4), kbdmux(4), - keyboard(4), screen(4), - splash(4), syscons(4), - ukbd(4), kbdmap(5), - loader.conf(5), rc.conf(5), - ttys(5), config(8), - getty(8), kldload(8), - moused(8), vtfontcvt(8)

-
-
-

-

The vt driver first appeared in - FreeBSD 9.3.

-
-
-

-

The vt device driver was developed by - Ed Schouten - <ed@FreeBSD.org>, - Ed Maste - <emaste@FreeBSD.org>, - and Aleksandr Rybalko - <ray@FreeBSD.org>, - with sponsorship provided by the FreeBSD Foundation. - This manual page was written by Warren Block - <wblock@FreeBSD.org>.

-
-
-

-

Paste buffer size is limited by the system value - {MAX_INPUT}, the number of bytes that can be stored - in the terminal input queue, usually 1024 bytes (see - termios(4)).

-
-
- - - - - -
November 21, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/vte.4 3.html b/static/freebsd/man4/vte.4 3.html deleted file mode 100644 index 822d3535..00000000 --- a/static/freebsd/man4/vte.4 3.html +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - -
VTE(4)Device Drivers ManualVTE(4)
-
-
-

-

vte — Vortex86 RDC - R6040 Fast Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device vte
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vte_load="YES"
-
-
-
-

-

The vte device driver provides support for - RDC R6040 Fast Ethernet controller which is commonly found on Vortex86 - System On a Chip (SoC).

-

The RDC R6040 has integrated 10/100 PHY for 10/100Mbps support in - full or half-duplex. The controller supports interrupt moderation mechanism, - a 64-bit multicast hash filter, VLAN over-size frame and four station - addresses. The vte device driver uses three station - addresses out of four as perfect multicast filter.

-

The vte driver supports the following - media types:

-
-
-
Enable autoselection of the media type and options. The user can manually - override the autoselected mode by adding media options to - rc.conf(5).
-
-
Set 10Mbps operation.
-
-
Set 100Mbps (Fast Ethernet) operation.
-
-

The vte driver supports the following - media options:

-
-
-
Force full duplex operation.
-
-
Force half duplex operation.
-
-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The vte device driver provides support for - the following Ethernet controllers:

-

-
    -
  • DM&P Vortex86 RDC R6040 Fast Ethernet controller
    • -
-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vte.tx_deep_copy
-
The RDC R6040 controller has no auto-padding support for short frames and - the controller's DMA engine does not have capability to handle multiple - buffers for a TX frame such that driver has to create a single contiguous - TX buffer. This hardware limitation leads to poor TX performance since - most of CPU cycles are wasted on both de-fragmenting mbuf chains and - padding. This tunable enables deep copy operation for TX frames such that - driver will spend less CPU cycles in de-fragmentation with the cost of - extra TX buffer memory. The default value is 1 to use deep copy.
-
-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
dev.vte.%d.rx_mod
-
Maximum number of packets to fire RX completion interrupt. The accepted - range is 0 to 15, the default is 15.
-
dev.vte.%d.tx_mod
-
Maximum number of packets to fire TX completion interrupt. The accepted - range is 0 to 15, the default is 15.
-
dev.vte.%d.stats
-
Show hardware MAC statistics maintained in driver.
-
-
-
-

-

altq(4), arp(4), - miibus(4), netintro(4), - ng_ether(4), vlan(4), - ifconfig(8)

-

DM&P Electronics Inc. - Vortex86, - http://www.dmp.com.tw.

-
-
-

-

The vte driver was written by - Pyun YongHyeon - <yongari@FreeBSD.org>. - It first appeared in FreeBSD 8.3.

-
-
- - - - - -
December 30, 2010FreeBSD 15.0
diff --git a/static/freebsd/man4/vtnet.4 3.html b/static/freebsd/man4/vtnet.4 3.html deleted file mode 100644 index a77e5aab..00000000 --- a/static/freebsd/man4/vtnet.4 3.html +++ /dev/null @@ -1,305 +0,0 @@ - - - - - - -
VTNET(4)Device Drivers ManualVTNET(4)
-
-
-

-

vtnet — VirtIO - Ethernet driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device vtnet
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vtnet_load="YES"
-
-
-
-

-

The vtnet device driver provides support - for VirtIO Ethernet devices.

-

If the hypervisor advertises the appropriate features, the - vtnet driver supports TCP/UDP checksum offload for - both transmit and receive, TCP segmentation offload (TSO), TCP large receive - offload (LRO), hardware VLAN tag stripping/insertion features, a multicast - hash filter, as well as Jumbo Frames (up to 9216 bytes), which can be - configured via the interface MTU setting.

-

Two flavors of TCP LRO are supported: Hardware TCP LRO, which is - performed by the host providing TCP segments larger than the MTU to the - guest, and Software TCP LRO, which is performed by the network stack of the - guest processing TCP segments in an optimized way. Only one flavour of TCP - LRO should be used. Since hardware TCP LRO can have bad interactions with IP - forwarding and software TCP LRO mitigates several drawbacks of hardware TCP - LRO, the default setting is to disable hardware TCP LRO. See the loader - tunable - hw.vtnet.X.lro_disable.

-

TCP/UDP receive checksum offload cannot be configured - independently for IPv4 and IPv6. Selecting an MTU larger than 1500 bytes - with the ifconfig(8) utility configures the adapter to - receive and transmit Jumbo Frames.

-

For more information on configuring this device, see - ifconfig(8).

-
-
-

-

Tunables can be set at the loader(8) prompt - before booting the kernel or stored in loader.conf(5).

-
-
hw.vtnet.csum_disable
-
 
-
hw.vtnet.X.csum_disable
-
This tunable disables receive and transmit checksum offloading for TCP and - UDP. This also implies that TCP segmentation offloading and large receive - offload are disabled. The default value is 0.
-
hw.vtnet.fixup_needs_csum
-
 
-
hw.vtnet.X.fixup_needs_csum
-
This tunable enforces the calculation of a valid TCP or UDP checksum for - packets received with VIRTIO_NET_HDR_F_NEEDS_CSUM - being set in the flags field of the structure - struct virtio_net_hdr. It also marks the checksum as - being correct in the mbuf packet header. The default value is 0. This - tunable is deprecated and will be removed in FreeBSD - 16.
-
hw.vtnet.tso_disable
-
 
-
hw.vtnet.X.tso_disable
-
This tunable disables TCP segmentation offloading. The default value is - 0.
-
hw.vtnet.lro_disable
-
 
-
hw.vtnet.X.lro_disable
-
This tunable disables hardware TCP LRO. The default value is 1.
-
hw.vtnet.mq_disable
-
 
-
hw.vtnet.X.mq_disable
-
This tunable disables multiqueue. The default value is 0.
-
hw.vtnet.mq_max_pairs
-
 
-
hw.vtnet.X.mq_max_pairs
-
This tunable sets the maximum number of transmit and receive queue pairs. - Multiple queues are only supported when the Multiqueue feature is - negotiated. This driver supports a maximum of 8 queue pairs. The number of - queue pairs used is the lesser of the maximum supported by the driver and - the hypervisor, the number of CPUs present in the guest, and this tunable - if not zero. The default value is 0.
-
hw.vtnet.tso_maxlen
-
 
-
hw.vtnet.X.tso_maxlen
-
This tunable sets the TSO burst limit. The default value is 65535.
-
hw.vtnet.rx_process_limit
-
 
-
hw.vtnet.X.rx_process_limit
-
This tunable sets the number of RX segments processed in one pass. The - default value is 1024.
-
hw.vtnet.lro_entry_count
-
 
-
hw.vtnet.X.lro_entry_count
-
This tunable sets the software TCP LRO entry count. The default value is - 128, the minimum value is 8.
-
hw.vtnet.lro_mbufq_depth
-
 
-
hw.vtnet.X.lro_mbufq_depth
-
This tunable sets the depth of the software TCP LRO mbuf queue. The - default value is 0.
-
hw.vtnet.altq_disable
-
This tunable disables ALTQ support, allowing the use of multiqueue - instead. This option applies to all interfaces. The default value is - 0.
-
-
-
-

-

For each transmit queue of each interface the following read-only - statistics are provided:

-
-
dev.vtnet.X.txqY.rescheduled
-
The number of times the transmit interrupt handler was rescheduled.
-
dev.vtnet.X.txqY.tso
-
The number of times TCP segment offloading was performed.
-
dev.vtnet.X.txqY.csum
-
The number of times transmit checksum offloading for UDP or TCP was - performed.
-
dev.vtnet.X.txqY.omcasts
-
The number of multicast packets that were transmitted.
-
dev.vtnet.X.txqY.obytes
-
The number of bytes that were transmitted (based on Ethernet frames).
-
dev.vtnet.X.txqY.opackets
-
The number of packets that were transmitted (Ethernet frames).
-
-
-
-

-

For each receive queue of each interface the following read-only - statistics are provided:

-
-
dev.vtnet.X.rxqY.rescheduled
-
The number of times the receive interrupt handler was rescheduled.
-
dev.vtnet.X.rxqY.host_lro
-
The number of times TCP large receive offload was performed.
-
dev.vtnet.X.rxqY.csum_failed
-
The number of times a packet with a request for receive or transmit - checksum offloading was received and this request failed. The different - reasons for the failure are counted by - dev.vtnet.X.rx_csum_inaccessible_ipproto, - dev.vtnet.X.rx_csum_bad_ipproto, - dev.vtnet.X.rx_csum_bad_ethtype, - and - dev.vtnet.X.rx_csum_bad_offset.
-
dev.vtnet.X.rxqY.csum
-
The number of times receive checksum offloading for UDP or TCP was - performed.
-
dev.vtnet.X.rxqY.ierrors
-
The number of times an error occurred during input processing.
-
dev.vtnet.X.rxqY.iqdrops
-
The number of times a packet was dropped during input processing.
-
dev.vtnet.X.rxqY.ibytes
-
The number of bytes that were received (based on Ethernet frames).
-
dev.vtnet.X.rxqY.ipackets
-
The number of packets that were received (Ethernet frames).
-
-
-
-

-

For each interface the following read-only transmit statistics are - provided:

-
-
dev.vtnet.X.tx_task_rescheduled
-
The sum of - dev.vtnet.X.txqY.rescheduled - over all transmit queues of the interface.
-
dev.vtnet.X.tx_tso_offloaded
-
The sum of - dev.vtnet.X.txqY.tso - over all transmit queues of the interface.
-
dev.vtnet.X.tx_csum_offloaded
-
The sum of - dev.vtnet.X.txqY.csum - over all transmit queues of the interface.
-
dev.vtnet.X.tx_defrag_failed
-
The number of times an attempt to defragment an mbuf chain failed during a - transmit operation.
-
dev.vtnet.X.tx_defragged
-
The number of times an mbuf chain was defragmented during a transmit - operation.
-
dev.vtnet.X.tx_tso_without_csum
-
The number of times TCP segment offloading was attempted without transmit - checksum offloading.
-
dev.vtnet.X.tx_tso_not_tcp
-
The number of times TCP segment offloading was attempted for a non-TCP - packet.
-
dev.vtnet.X.tx_csum_proto_mismatch
-
The number of times the IP protocol version of the transmit checksum - offloading request did not match the IP protocol version of the - packet.
-
dev.vtnet.X.tx_csum_unknown_ethtype
-
The number of times a transmit offload operation was requested for an - ethernet frame for which the EtherType was neither IPv4 nor IPv6 - (considering simple VLAN tagging).
-
-
-
-

-

For each interface the following read-only receive statistics are - provided:

-
-
dev.vtnet.X.rx_task_rescheduled
-
The sum of - dev.vtnet.X.rxqY.rescheduled - over all receive queues of the interface.
-
dev.vtnet.X.rx_csum_offloaded
-
The sum of - dev.vtnet.X.rxqY.csum - over all receive queues of the interface.
-
dev.vtnet.X.rx_csum_failed
-
The sum of - dev.vtnet.X.rxqY.csum_failed - over all receive queues of the interface.
-
dev.vtnet.X.rx_csum_inaccessible_ipproto
-
The number of times a packet with a request for receive or transmit - checksum offloading was received where the IP protocol was not - accessible.
-
dev.vtnet.X.rx_csum_bad_offset
-
The number of times fixing the checksum required by - hw.vtnet.fixup_needs_csum or - hw.vtnet.X.fixup_needs_csum - was attempted for a packet where the csum is not located in the first - mbuf.
-
dev.vtnet.X.rx_csum_bad_ipproto
-
The number of times a packet with a request for receive or transmit - checksum offloading was received where the IP protocol was neither TCP nor - UDP.
-
dev.vtnet.X.rx_csum_bad_ethtype
-
The number of times a packet with a request for receive or transmit - checksum offloading was received where the EtherType was neither IPv4 nor - IPv6.
-
dev.vtnet.X.rx_mergeable_failed
-
The number of times receiving a mergable buffer failed.
-
dev.vtnet.X.rx_enq_replacement_failed
-
The number of times the enqueuing the replacement receive mbuf chain - failed.
-
dev.vtnet.X.rx_frame_too_large
-
The number of times the frame was loger than the mbuf chain during large - receive offload without mergeable buffers.
-
dev.vtnet.X.mbuf_alloc_failed
-
The number of times an mbuf cluster allocation for the receive buffer - failed.
-
-
-
-

-

For each interface the following read-only configuration - parameters are provided:

-
-
dev.vtnet.X.act_vq_pairs
-
The number of active virtqueue pairs.
-
dev.vtnet.X.req_vq_pairs
-
The number of requested virtqueue pairs.
-
dev.vtnet.X.max_vq_pairs
-
The maximum number of supported virtqueue pairs.
-
dev.vtnet.X.flags
-
The flags of the interface. Mostly for debugging purposes.
-
dev.vtnet.X.features
-
The features of the interface as defined by the virtio specification.
-
-
-
-

-

arp(4), netintro(4), - ng_ether(4), virtio(4), - vlan(4), ifconfig(8)

-
-
-

-

The vtnet driver was written by - Bryan Venteicher - <bryanv@FreeBSD.org>. - It first appeared in FreeBSD 9.0.

-
-
-

-

The vtnet driver only supports LRO when - the hypervisor advertises the mergeable buffer feature.

-
-
- - - - - -
December 19, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/vxlan.4 3.html b/static/freebsd/man4/vxlan.4 3.html deleted file mode 100644 index 7c0dfb8d..00000000 --- a/static/freebsd/man4/vxlan.4 3.html +++ /dev/null @@ -1,180 +0,0 @@ - - - - - - -
VXLAN(4)Device Drivers ManualVXLAN(4)
-
-
-

-

vxlan — Virtual - eXtensible LAN interface

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device vxlan
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_vxlan_load="YES"
-
-
-
-

-

The vxlan driver creates a virtual tunnel - endpoint in a vxlan segment. A - vxlan segment is a virtual Layer 2 (Ethernet) - network that is overlaid in a Layer 3 (IP/UDP) network. - vxlan is analogous to vlan(4) but - is designed to be better suited for large, multiple tenant data center - environments.

-

Each vxlan interface is created at runtime - using interface cloning. This is most easily done with the - ifconfig(8) create command or - using the cloned_interfaces variable in - rc.conf(5). The interface may be removed with the - ifconfig(8) destroy command.

-

The vxlan driver creates a pseudo Ethernet - network interface that supports the usual network - ioctl(2)s and thus can be used with - ifconfig(8) like any other Ethernet interface. The - vxlan interface encapsulates the Ethernet frame by - prepending IP/UDP and vxlan headers. Thus, the - encapsulated (inner) frame is able to be transmitted over a routed, Layer 3 - network to the remote host.

-

The vxlan interface may be configured in - either unicast or multicast mode. When in unicast mode, the interface - creates a tunnel to a single remote host, and all traffic is transmitted to - that host. When in multicast mode, the interface joins an IP multicast - group, and receives packets sent to the group address, and transmits packets - to either the multicast group address, or directly to the remote host if - there is an appropriate forwarding table entry.

-

When the vxlan interface is brought up, a - udp(4) socket(9) is created based on the - configuration, such as the local address for unicast mode or the group - address for multicast mode, and the listening (local) port number. Since - multiple vxlan interfaces may be created that either - use the same local address or join the same group address, and use the same - port, the driver may share a socket among multiple interfaces. However, each - interface within a socket must belong to a unique - vxlan segment. The analogous - vlan(4) configuration would be a physical interface - configured as the parent device for multiple VLAN interfaces, each with a - unique VLAN tag. Each vxlan segment is identified by - a 24-bit value in the vxlan header called the - “VXLAN Network Identifier”, or VNI.

-

When configured with the ifconfig(8) - vxlanlearn parameter, the interface dynamically - creates forwarding table entries from received packets. An entry in the - forwarding table maps the inner source MAC address to the outer remote IP - address. During transmit, the interface attempts to lookup an entry for the - encapsulated destination MAC address. If an entry is found, the IP address - in the entry is used to directly transmit the encapsulated frame to the - destination. Otherwise, when configured in multicast mode, the interface - must flood the frame to all hosts in the group. The maximum number of - entries in the table is configurable with the ifconfig(8) - vxlanmaxaddr command. Stale entries in the table are - periodically pruned. The timeout is configurable with the - ifconfig(8) vxlantimeout command. - The table may be viewed with the sysctl(8) - net.link.vxlan.N.ftable.dump command.

-
-
-

-

Since the vxlan interface encapsulates the - Ethernet frame with an IP, UDP, and vxlan header, - the resulting frame may be larger than the MTU of the physical network. The - vxlan specification recommends the physical network - MTU be configured to use jumbo frames to accommodate the encapsulated frame - size.

-

By default, the vxlan driver sets its MTU - to usual ethernet MTU of 1500 bytes, reduced by the size of vxlan headers - prepended to the encapsulated packets.

-

Alternatively, the ifconfig(8) - mtu command may be used to set the fixed MTU size on - the vxlan interface to allow the encapsulated frame - to fit in the current MTU of the physical network. If the - mtu command was used, system no longer adjust the - vxlan interface MTU on routing or address - changes.

-
-
-

-

The vxlan driver supports hardware - checksum offload (receive and transmit) and TSO on the encapsulated traffic - over physical interfaces that support these features. The - vxlan interface examines the - vxlandev interface, if one is specified, or the - interface hosting the vxlanlocal address, and - configures its capabilities based on the hardware offload capabilities of - that physical interface. If multiple physical interfaces will transmit or - receive traffic for the vxlan then they all must - have the same hardware capabilities. The transmit routine of a - vxlan interface may fail with - ENXIO if an outbound physical interface does not - support an offload that the vxlan interface is - requesting. This can happen if there are multiple physical interfaces - involved, with different hardware capabilities, or an interface capability - was disabled after the vxlan interface had already - started.

-

At present, these devices are capable of generating checksums and - performing TSO on the inner frames in hardware: - cxgbe(4).

-
-
-

-

Create a vxlan interface in unicast mode - with the vxlanlocal tunnel address of 192.168.100.1, - and the vxlanremote tunnel address of - 192.168.100.2.

-
-
ifconfig vxlan create vxlanid 108 vxlanlocal 192.168.100.1 vxlanremote 192.168.100.2
-
-

Create a vxlan interface in multicast - mode, with the local address of 192.168.10.95, and - the group address of 224.0.2.6. The em0 interface - will be used to transmit multicast packets.

-
-
ifconfig vxlan create vxlanid 42 vxlanlocal 192.168.10.95 vxlangroup 224.0.2.6 vxlandev em0
-
-

Once created, the vxlan interface can be - configured with ifconfig(8).

-

The following when placed in the file - /etc/rc.conf will cause a vxlan interface called - “vxlan0” to be created, and will - configure the interface in unicast mode.

-
-
cloned_interfaces="vxlan0"
-create_args_vxlan0="vxlanid 108 vxlanlocal 192.168.100.1 vxlanremote 192.168.100.2"
-
-
-
-

-

inet(4), inet6(4), - vlan(4), rc.conf(5), - ifconfig(8), sysctl(8)

-

M. Mahalingam and - et al, Virtual eXtensible Local - Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 - Networks over Layer 3 Networks, August 2014, - RFC 7348.

-
-
-

-

The vxlan driver was written by - Bryan Venteicher ⟨bryanv@freebsd.org⟩. - Support for stateless hardware offloads was added by - Navdeep Parhar ⟨np@freebsd.org⟩ in - FreeBSD 13.0.

-
-
- - - - - -
March 30, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/watchdog.4 3.html b/static/freebsd/man4/watchdog.4 3.html deleted file mode 100644 index 4449d3c3..00000000 --- a/static/freebsd/man4/watchdog.4 3.html +++ /dev/null @@ -1,186 +0,0 @@ - - - - - - -
WATCHDOG(4)Device Drivers ManualWATCHDOG(4)
-
-
-

-

watchdog — - hardware and software watchdog

-
-
-

-

#include - <sys/watchdog.h>

-
-
-

-

The watchdog facility is used for - controlling hardware and software watchdogs.

-

The device /dev/fido supports several - optional ioctl(2) calls for configuration, and responds to - a set of operational ioctl(2) calls:

-
-
-
Pat the watchdog.
-
-
Enable, disable, or reset the watchdog.
-
-

The WDIOCPATPAT ioctl(2) - call takes a single argument which represents a timeout value specified as a - sbintime_t of the timeout period for the watchdog.

-

The WDIOCPATPAT ioctl(2) - call will return success if just one of the available - watchdog(9) implementations supports setting the timeout - to the specified timeout. This means that at least one watchdog is armed. By - default, this will be a hardware watchdog if one is present, but if no - hardware watchdog is able to process the request, a default software - watchdog is enabled. If the call fails, for instance if none of - watchdog(9) implementations support the timeout length, - all watchdogs are disabled and must be explicitly re-enabled.

-

To disable the watchdogs use the - WDIOC_CONTROL ioctl(2) call with - the WD_CTRL_DISABLE flag. If disarming the - watchdog(s) failed an error is returned. The watchdog might still be armed! - To reenable the watchdogs use the WDIOC_CONTROL - ioctl(2) call with the - WD_CTRL_ENABLE flag. Another way to pat the watchdog - is with the WDIOC_CONTROL ioctl(2) - call passing the WDIOC_CTRL_RESET flag.

-

The optional configuration ioctl(2) commands are - listed here, along with the type of the parameter used. Examples of their - use can be found in watchdogd(8).

-
-
- sbintime_t
-
set/reset the timer
-
- sbintime_t
-
get total timeout
-
- sbintime_t
-
get time left
-
- sbintime_t
-
get the pre-timeout
-
- sbintime_t
-
set the pre-timeout
-
- int
-
Set the action when a pre-timeout occurs (see - WD_SOFT_* below).
-
- int
-
Use an internal software watchdog instead of hardware. There is also an - external software watchdog, which is used by default if no hardware - watchdog was attached.
-
- int
-
Set the action when a soft timeout occurs.
-
-

The actions that may be specified for the pre-timeout or the - internal software watchdog are listed here. Multiple actions can be - specified by ORing values together.

-
-
-
panic
-
-
enter debugger
-
-
log(9)
-
-
printf(9)
-
-
-
-

-

The WDIOCPATPAT ioctl(2) - returns zero on success and non-zero on failure.

-
-
[EOPNOTSUPP]
-
No watchdog present in the kernel or none of the watchdogs supports the - requested timeout value (timeout value other than 0).
-
[EOPNOTSUPP]
-
Watchdog could not be disabled (timeout value of 0).
-
[EINVAL]
-
Invalid flag combination passed.
-
-

The configuration ioctl(2) operations return - zero on success and non-zero on failure.

-
-
-

-
-
#include <paths.h>
-#include <sys/watchdog.h>
-
-#define WDPATH	"/dev/" _PATH_WATCHDOG
-int wdfd = -1;
-
-static void
-wd_init(void)
-{
-	wdfd = open(WDPATH, O_RDWR);
-	if (wdfd == -1)
-		err(1, WDPATH);
-}
-static void
-wd_reset(u_int timeout)
-{
-	if (ioctl(wdfd, WDIOCPATPAT, &timeout) == -1)
-		err(1, "WDIOCPATPAT");
-}
-
-/* in main() */
-wd_init();
-wd_reset(WD_ACTIVE|WD_TO_8SEC);
-/* potential freeze point */
-wd_reset(WD_TO_NEVER);
-
-

Enables a watchdog to recover from a potentially freezing piece of - code.

-

-
options SW_WATCHDOG
-

in your kernel config forces a software watchdog in the kernel to - be configured even if a hardware watchdog is configured, dropping to KDB or - panicking when firing, depending on the KDB and KDB_UNATTENDED kernel - configuration options.

-
-
-

-

watchdogd(8), watchdog(9)

-
-
-

-

The watchdog code first appeared in - FreeBSD 5.1.

-
-
-

-

The watchdog facility was written by - Poul-Henning Kamp - <phk@FreeBSD.org>. The - software watchdog code and this manual page were written by - Sean Kelly - <smkelly@FreeBSD.org>. - Some contributions were made by Jeff Roberson - <jeff@FreeBSD.org>.

-
-
-

-

The WD_PASSIVE option has not yet been - implemented.

-
-
- - - - - -
January 2, 2018FreeBSD 15.0
diff --git a/static/freebsd/man4/wbwd.4 3.html b/static/freebsd/man4/wbwd.4 3.html deleted file mode 100644 index a601bdc1..00000000 --- a/static/freebsd/man4/wbwd.4 3.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - -
WBWD(4)Device Drivers ManualWBWD(4)
-
-
-

-

wbwd — device - driver for Winbond/Nuvoton Super I/O chips watchdog timer

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device superio -
-device wbwd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
wbwd_load="YES"
-
-
-
-

-

The wbwd driver provides - watchdog(4) support for the watchdog interrupt timer - present on at least the following Super I/O chips:

-
    -
  • Winbond 83627HF/F/HG/G
    • -
  • Winbond 83627S
    • -
  • Winbond 83697HF
    • -
  • Winbond 83697UG
    • -
  • Winbond 83637HF
    • -
  • Winbond 83627THF
    • -
  • Winbond 83687THF
    • -
  • Winbond 83627EHF
    • -
  • Winbond 83627DHG
    • -
  • Winbond 83627UHG
    • -
  • Winbond 83667HG
    • -
  • Winbond 83627DHG-P
    • -
  • Winbond 83667HG-B
    • -
  • Nuvoton NCT6775
    • -
  • Nuvoton NCT6776
    • -
  • Nuvoton NCT6102
    • -
  • Nuvoton NCT6779
    • -
  • Nuvoton NCT6791
    • -
  • Nuvoton NCT6792
    • -
-
-
-

-

The wbwd driver provides the following - options as sysctl(8) variables.

-
-
dev.wbwd.0.timeout_override
-
This variable allows to program the timer to a value independent on the - one provided by the watchdog(4) framework while still - relying on the regular updates from e.g. watchdogd(8). - This is particularly useful if your system provides multiple watchdogs and - you want them to fire in a special sequence to trigger an NMI after a - shorter period than the reset timeout for example. The value set must not - be lower than the sleep time of watchdogd(8). A value of - 0 disables this feature and the timeout value provided by - watchdog(4) will be used.
-
dev.wbwd.0.debug_verbose
-
If set this sysctl will tell the driver to log its current state before - and after the timer reset on each invocation from - watchdog(9) to the kernel message buffer for - debugging.
-
dev.wbwd.0.debug
-
This read-only value gives the state of some registers on last - update.
-
-

The wbwd driver also provides further - sysctl options that are hidden by default. See the source code for more - information.

-
-
-

-

superio(4), watchdog(4), - device.hints(5), watchdog(8), - watchdogd(8), watchdog(9)

-
-
-

-

The wbwd driver first appeared in - FreeBSD 10.0.

-
-
-

-

This manual page was written by Bjoern A. - Zeeb - <bz@FreeBSD.org>.

-
-
- - - - - -
October 16, 2019FreeBSD 15.0
diff --git a/static/freebsd/man4/wdatwd.4 3.html b/static/freebsd/man4/wdatwd.4 3.html deleted file mode 100644 index ed86f137..00000000 --- a/static/freebsd/man4/wdatwd.4 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
WDATWD(4)Device Drivers ManualWDATWD(4)
-
-
-

-

wdatwd — device - driver for the ACPI WDAT based watchdog interrupt timer

-
-
-

-

To compile this driver into the kernel, place the following line - in your kernel configuration file:

-
device wdatwd
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
wdatwd_load="YES"
-
-
-
-

-

The wdatwd driver provides - watchdog(4) support for the watchdog interrupt timer in - ACPI WDAT (Watchdog Action Table).

-

Since WDAT itself is an abstraction for the real hardware such as - ICH WDT, it must be noted that only one driver can be used at a time, either - the real hardware specific driver or this driver.

-
-
-

-

The following read-only sysctl(8) variables are - available:

-
-
dev.wdatwd.%d.running
-
The status of the watchdog timer. 0 if not running, or 1 if running.
-
dev.wdatwd.%d.timeout
-
The current value of the watchdog timeout in millisecond. This can be 0 on - some systems, and the zero value means that the default timeout is - used.
-
dev.wdatwd.%d.timeout_configurable
-
Whether the timeout is configurable or not. It is 0 if configurable or any - positive value if not.
-
dev.wdatwd.%d.timeout_default
-
The default value of the watchdog timeout in millisecond if any.
-
-
-
-

-

ichwd(4), watchdog(4), - watchdog(8), watchdogd(8), - watchdog(9)

-

Microsoft Corporation, - Hardware Watchdog Timers Design Specification, - Requirements for Hardware Watchdog Timers Supported by - Microsoft(R) Windows Vista(R) and Microsoft Windows Server(R) 2008 Operating - Systems, - http://msdn.microsoft.com/en-us/windows/hardware/gg463320.aspx, - 2006.

-
-
-

-

The wdatwd driver was written by - Tetsuya Uemura - <t_uemura@macome.co.jp> - of MACOME, Corporation.

-
-
- - - - - -
November 18, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/wg.4 3.html b/static/freebsd/man4/wg.4 3.html deleted file mode 100644 index ae3f6a5b..00000000 --- a/static/freebsd/man4/wg.4 3.html +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - -
WG(4)Device Drivers ManualWG(4)
-
-
-

-

wg — WireGuard - protocol driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device wg
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_wg_load="YES"
-
-
-
-

-

The wg driver provides Virtual Private - Network (VPN) interfaces for the secure exchange of layer 3 traffic with - other WireGuard peers using the WireGuard protocol.

-

A wg interface recognizes one or more - peers, establishes a secure tunnel with each on demand, and tracks each - peer's UDP endpoint for exchanging encrypted traffic with.

-

The interfaces can be created at runtime using the - ifconfig - wgN - create command. The interface itself can be - configured with wg(8).

-

The following glossary provides a brief overview of WireGuard - terminology:

-
-
-
Peer
-
Peers exchange IPv4 or IPv6 traffic over secure tunnels. Each - wg interface may be configured to recognize one or - more peers.
-
Key
-
Each peer uses its private key and corresponding public key to identify - itself to others. A peer configures a wg interface - with its own private key and with the public keys of its peers.
-
Pre-shared key
-
In addition to the public keys, each peer pair may be configured with a - unique pre-shared symmetric key. This is used in their handshake to guard - against future compromise of the peers' encrypted tunnel if an attack on - their Diffie-Hellman exchange becomes feasible. It is optional, but - recommended.
-
Allowed IP addresses
-
A single wg interface may maintain concurrent - tunnels connecting diverse networks. The interface therefore implements - rudimentary routing and reverse-path filtering functions for its tunneled - traffic. These functions reference a set of allowed IP address ranges - configured against each peer. -

The interface will route outbound tunneled traffic to the peer - configured with the most specific matching allowed IP address range, or - drop it if no such match exists.

-

The interface will accept tunneled traffic only from the peer - configured with the most specific matching allowed IP address range for - the incoming traffic, or drop it if no such match exists. That is, - tunneled traffic routed to a given peer cannot return through another - peer of the same wg interface. This ensures that - peers cannot spoof one another's traffic.

-
-
Handshake
-
Two peers handshake to mutually authenticate each other and to establish a - shared series of secret ephemeral encryption keys. Either peer may - initiate a handshake. Handshakes occur only when there is traffic to send, - and recur every two minutes during transfers.
-
Connectionless
-
Due to the handshake behavior, there is no connected or disconnected - state.
-
-
-
-

-

Private keys for WireGuard can be generated from any sufficiently - secure random source. The Curve25519 keys and the pre-shared keys are both - 32 bytes long and are commonly encoded in base64 for ease of use.

-

Keys can be generated with wg(8) as follows:

-

-
$ wg genkey
-

Although a valid Curve25519 key must have 5 bits set to specific - values, this is done by the interface and so it will accept any random - 32-byte base64 string.

-
-
-
-

-

netmap(4) applications may open a WireGuard - interface in emulated mode. The netmap application will receive decrypted, - unencapsulated packets prepended by a dummy Ethernet header. The Ethertype - field will be one of ETHERTYPE_IP or - ETHERTYPE_IPV6 depending on the address family of - the packet. Packets transmitted by the application should similarly begin - with a dummy Ethernet header; this header will be stripped before the packet - is encrypted and tunneled.

-
-
-

-

Create a wg interface and set random - private key.

-
-
# ifconfig wg0 create
-# wg genkey | wg set wg0 listen-port 54321 private-key /dev/stdin
-
-

Retrieve the associated public key from a - wg interface.

-
-
$ wg show wg0 public-key
-
-

Connect to a specific endpoint using its public-key and set the - allowed IP address

-
-
# wg set wg0 peer '7lWtsDdqaGB3EY9WNxRN3hVaHMtu1zXw71+bOjNOVUw=' endpoint 10.0.1.100:54321 allowed-ips 192.168.2.100/32
-
-

Remove a peer

-
-
# wg set wg0 peer '7lWtsDdqaGB3EY9WNxRN3hVaHMtu1zXw71+bOjNOVUw=' remove
-
-
-
-

-

The wg interface supports runtime - debugging, which can be enabled with:

-

-
ifconfig - wgN - debug
-

Some common error messages include:

-
-
Handshake for peer X did not complete after 5 seconds, retrying
-
Peer X did not reply to our initiation packet, for example because: -
    -
  • The peer does not have the local interface configured as a peer. Peers - must be able to mutually authenticate each other.
    • -
  • The peer endpoint IP address is incorrectly configured.
    • -
  • There are firewall rules preventing communication between hosts.
    • -
-
-
Invalid handshake initiation
-
The incoming handshake packet could not be processed. This is likely due - to the local interface not containing the correct public key for the - peer.
-
Invalid initiation MAC
-
The incoming handshake initiation packet had an invalid MAC. This is - likely because the initiation sender has the wrong public key for the - handshake receiver.
-
Packet has unallowed src IP from peer X
-
After decryption, an incoming data packet has a source IP address that is - not assigned to the allowed IPs of Peer X.
-
-
-
-

-

inet(4), ip(4), - ipsec(4), netintro(4), - netmap(4), ovpn(4), - ipf(5), pf.conf(5), - ifconfig(8), ipfw(8), - wg(8)

-

WireGuard whitepaper, - https://www.wireguard.com/papers/wireguard.pdf.

-
-
-

-

The wg device driver first appeared in - FreeBSD 13.2.

-
-
-

-

The wg device driver was written by - Jason A. Donenfeld - <Jason@zx2c4.com>, - Matt Dunwoodie - <ncon@nconroy.net>, - Kyle Evans - <kevans@FreeBSD.org>, - and Matt Macy - <mmacy@FreeBSD.org>.

-

This manual page was written by Gordon - Bergling - <gbe@FreeBSD.org> and - is based on the OpenBSD manual page written by - David Gwynne - <dlg@openbsd.org>.

-
-
- - - - - -
February 12, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/witness.4 3.html b/static/freebsd/man4/witness.4 3.html deleted file mode 100644 index 2b2d1e5d..00000000 --- a/static/freebsd/man4/witness.4 3.html +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - -
WITNESS(4)Device Drivers ManualWITNESS(4)
-
-
-

-

witness — lock - validation facility

-
-
-

-

options WITNESS -
- options WITNESS_COUNT -
- options WITNESS_KDB -
- options WITNESS_NO_VNODE -
- options WITNESS_SKIPSPIN

-
-
-

-

The witness module keeps track of the - locks acquired and released by each thread. It also keeps track of the order - in which locks are acquired with respect to each other. Each time a lock is - acquired, witness uses these two lists to verify - that a lock is not being acquired in the wrong order. If a lock order - violation is detected, then a message is output to the kernel console or log - detailing the locks involved and the locations in question. Witness can also - be configured to drop into the kernel debugger when an order violation - occurs.

-

The witness code also checks various other - conditions such as verifying that one does not recurse on a non-recursive - lock, or attempt an upgrade on a shared lock held by another thread. If any - of these checks fail, then the kernel will panic.

-

The WITNESS_COUNT kernel option controls - the maximum number of witness entries that are - tracked in the kernel. The maximum number of entries can be queried via the - debug.witness.witness_count sysctl. It can also be set - from the loader(8) via the - debug.witness.witness_count environment variable.

-

The WITNESS_NO_VNODE kernel option tells - witness to ignore locking issues between - vnode(9) objects.

-

The flag that controls whether or not the kernel debugger is - entered when a lock order violation is detected can be set in a variety of - ways. By default, the flag is off, but if the - WITNESS_KDB kernel option is specified, then the - flag will default to on. It can also be set from the - loader(8) via the debug.witness.kdb - environment variable or after the kernel has booted via the - debug.witness.kdb sysctl. If the flag is set to zero, - then the debugger will not be entered. If the flag is non-zero, then the - debugger will be entered.

-

The witness code can also be configured to - skip all checks on spin mutexes. By default, this flag defaults to off, but - it can be turned on by specifying the - WITNESS_SKIPSPIN kernel option. The flag can also be - set via the loader(8) environment variable - debug.witness.skipspin. If the variable is set to a - non-zero value, then spin mutexes are skipped. Once the kernel has booted, - the status of this flag can be examined but not set via the read-only sysctl - debug.witness.skipspin.

-

The sysctl debug.witness.watch specifies the - level of witness involvement in the system. A value of 1 specifies that - witness is enabled. A value of 0 specifies that witness is disabled, but - that can be enabled again. This will maintain a small amount of overhead in - the system. A value of -1 specifies that witness is disabled permanently and - cannot be enabled again. The sysctl - debug.witness.watch can be set via - loader(8).

-

The sysctl debug.witness.trace controls - whether witness prints stack traces when it detects - lock violations. A value of 0 disables stack printing. A value of 1 - specifies that witness should print a stack trace - when a lock hierarchy violation occurs or non-sleepable locks are held when - going to sleep or acquiring a sleepable lock. A value of 2 specifies that - witness should attempt to display all observed lock - chains that contribute to the established lock order, along with stack - traces for when those locks were first acquired. The sysctl - debug.witness.trace can be set via - loader(8).

-

The sysctl debug.witness.output_channel - specifies the output channel used to display warnings emitted by - witness. The possible values are - ‘console’, indicating that warnings - are to be printed to the system console, - ‘log’, indicating that warnings are to - be logged via log(9), and - ‘none’. This sysctl can be set via - loader(8).

-

The sysctl debug.witness.badstacks displays - a listing of detected lock order violations cached in the - witness module's current view of the lock hierarchy. - (This means that it may not display information for locks which have been - destroyed.) It displays a similar level of detail to the messages produced - by the run-time checks. However, it always tries to show all observed lock - chains that contribute to the established lock order. (In other words, it - acts like debug.witness.trace was set to 2.) It uses - '**' to mark lock orders which were attempted but not added to the hierarchy - because they violated the hierarchy the witness code - had previously observed.

-

The witness code also provides a few extra - ddb(4) commands if both witness - and ddb(4) are compiled into the kernel:

-
-
[thread]
-
Outputs the list of locks held by a thread to the kernel console along - with the filename and line number at which each lock was last acquired by - the thread. The optional thread argument may be - either a TID, PID, or pointer to a thread structure. If - thread is not specified, then the locks held by the - current thread are displayed.
-
-
Outputs the list of locks held by all threads in the system to the kernel - console.
-
-
Dumps the current order list to the kernel console. The code first - displays the lock order tree for all of the sleep locks. Then it displays - the lock order tree for all of the spin locks. Finally, it displays a list - of locks that have not yet been acquired.
-
-
Displays a listing of all WITNESS lock order violations. This listing is - identical to that produced by the - debug.witness.badstacks sysctl.
-
-
-
-

-

ddb(4), loader(8), - sysctl(8), mutex(9)

-
-
-

-

The witness code first appeared in - BSD/OS 5.0 and was imported from there into - FreeBSD 5.0.

-
-
- - - - - -
January 26, 2026FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan.4 3.html b/static/freebsd/man4/wlan.4 3.html deleted file mode 100644 index 25fd44be..00000000 --- a/static/freebsd/man4/wlan.4 3.html +++ /dev/null @@ -1,163 +0,0 @@ - - - - - - -
WLAN(4)Device Drivers ManualWLAN(4)
-
-
-

-

wlan — generic - WiFi 802.11 link-layer support

-
-
-

-

device wlan

-
-
-

-

The wlan module provides generic code to - support 802.11 drivers. Where a device does not directly support 802.11 - functionality this layer fills in. The wlan module - is required by all native 802.11 drivers.

-

wlan supports multi-mode devices capable - of operating in both 2.4GHz and 5GHz bands and supports numerous 802.11 - standards: 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, and 802.11s (Draft - 3.0). The WPA, 802.11i, and 802.1x security protocols are supported through - a combination of in-kernel code and user-mode applications. The WME/WMM - multi-media protocols are supported entirely within the - wlan module but require a suitably capable hardware - device. Likewise the 802.11h specification is supported only by suitably - capable devices.

-

Drivers provide 802.11 functionality through - wlan interfaces that are created at runtime using - interface cloning. This is done with the ifconfig(8) - create command or using the - wlans_IFX variable in rc.conf(5). - Some drivers support the creation of multiple wlan - interfaces that share the same underlying device; this is the way by which - ``multi-bss support'' is provided but it can also be used to create WDS - links and other interesting applications.

-

There are several types of wlan interfaces - that may be created:

-
-
-
A client station in an infrastructure bss (i.e. one that associates to an - access point).
-
-
An access point in an infrastructure bss.
-
-
A mesh station in an MBSS network.
-
-
A station in an IBSS network.
-
-
A station operating in ``adhoc demo mode''. This is essentially an IBSS - station that does not use management frames (e.g. no beacons are - transmitted). An ahdemo interface is especially - useful for applications that want to transmit and receive raw 802.11 - packets.
-
-
An interface used exclusively for capturing 802.11 frames. In particular - this specified to have read-only properties which enables it to be - operated on frequencies where one would otherwise not be allowed.
-
-
A station that passes 4-address 802.11 traffic for the purpose of - tunneling traffic over a wireless link. Typically this station would share - the same MAC address as a hostap interface. It may - be possible to create wds interfaces without a - companion hostap interface but that is not - guaranteed; one may need to create a hostap - interface that does not send beacon frames before - wds interfaces may be created.
-
-

Note that an interface's type cannot be changed once it is - created.

-

wlan defines several mechanisms by which - plugin modules may be used to extend its functionality. Cryptographic - support such as WEP, TKIP, and AES-CCMP are implemented as standalone - modules (if not statically configured into a system) that register with - wlan. Similarly there is an authenticator framework - for defining 802.11 authentication services and a framework for integrating - access control mechanisms specific to the 802.11 protocol.

-
-
-

-

If the IEEE80211_DEBUG option is included - in the kernel configuration, debugging controls are available using:

-

-
sysctl - net.wlan.X.debug=mask
-

where X is the number of the - wlan instance and mask is a bit-or of control bits - that determine which debugging messages to enable. For example,

-

-
sysctl - net.wlan.0.debug=0x00200000
-

enables debugging messages related to scanning for an access - point, adhoc neighbor, or an unoccupied channel when operation as an access - point. The wlandebug(8) tool provides a more user-friendly - mechanism for doing the same thing. Note that

-

-
sysctl - net.wlan.debug=mask
-

defines the initial value of the debugging flags for each cloned - wlan interface; this is useful to enable debug - messages during interface creation.

-
-
-

-

The module name of wlan was used to be - compatible with NetBSD.

-

Mesh stations follow the 802.11s Draft 3.0 specification which is - not ratified and subject to change. Be aware that this specification is - incompatible with earlier drafts. Stations implementing earlier drafts - (e.g., Linux) may be incompatible.

-
-
-

-

ath(4), bwi(4), - bwn(4), ipw(4), - iwi(4), iwlwifi(4), - iwm(4), iwn(4), - iwx(4), malo(4), - mwl(4), netintro(4), - otus(4), ral(4), - rsu(4), rtw88(4), - rtw89(4), rtwn(4), - rum(4), run(4), - uath(4), upgt(4), - ural(4), urtw(4), - wlan_acl(4), wlan_ccmp(4), - wlan_gcmp(4), wlan_tkip(4), - wlan_wep(4), wlan_xauth(4), - wpi(4), zyd(4)

-
-
-

-

More information can be found in the IEEE 802.11 Standards.

-
-
-

-

The wlan driver first appeared in - FreeBSD 5.0.

-
-
-

-

Atsushi Onoe is the author of original - NetBSD software from which this work began. - Sam Leffler brought the code into - FreeBSD and then rewrote it to support multi-mode - devices, 802.11g, 802.11n, WPA/802.11i, WME, multi-bss, and add the - extensible frameworks for cryptographic, authentication, and access control - plugins. This manual page was written by Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
June 13, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_acl.4 4.html b/static/freebsd/man4/wlan_acl.4 4.html deleted file mode 100644 index b76d7075..00000000 --- a/static/freebsd/man4/wlan_acl.4 4.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - -
WLAN_ACL(4)Device Drivers ManualWLAN_ACL(4)
-
-
-

-

wlan_acl — - MAC-based ACL support for 802.11 devices

-
-
-

-

device wlan_acl

-
-
-

-

The wlan_acl module implements a MAC-based - access control plugin for use with 802.11 devices operating as an access - point. The wlan_acl must be loaded for - ifconfig(8) to handle the mac:* - requests.

-
-
-

-

wlan(4), ifconfig(8)

-
-
-

-

More information can be found in the IEEE 802.11 Standard.

-
-
-

-

The wlan_acl driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
December 7, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_amrr.4 4.html b/static/freebsd/man4/wlan_amrr.4 4.html deleted file mode 100644 index 9a643a5c..00000000 --- a/static/freebsd/man4/wlan_amrr.4 4.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
WLAN_AMRR(4)Device Drivers ManualWLAN_AMRR(4)
-
-
-

-

wlan_amrr — AMRR - rate adaptation algorithm support for 802.11 devices

-
-
-

-

device wlan_amrr

-
-
-

-

The wlan_amrr module implements the - Adaptive Multi-Rate Retry tx rate control algorithm for use by 802.11 device - drivers.

-
-
-

-

bwi(4), iwn(4), - ral(4), rum(4), - ural(4), wlan(4), - wpi(4), zyd(4)

-
-
-

-

More information can be found in the paper describing the - - algorithm at - http://hal.inria.fr/inria-00070784/en/.

-
-
-

-

The wlan_amrr driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
April 13, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_ccmp.4 4.html b/static/freebsd/man4/wlan_ccmp.4 4.html deleted file mode 100644 index b0ff9458..00000000 --- a/static/freebsd/man4/wlan_ccmp.4 4.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
WLAN_CCMP(4)Device Drivers ManualWLAN_CCMP(4)
-
-
-

-

wlan_ccmp — - AES-CCMP crypto support for 802.11 devices

-
-
-

-

device wlan_ccmp

-
-
-

-

The wlan_ccmp module handles the AES-CCMP - cryptographic requirements of the WPA and 802.11i protocols. It does - encapsulation and decapsulation of CCMP-encoded 802.11 frames and optionally - calculates the AES-CCMP cipher. The wlan_ccmp module - is an 802.11 cryptographic plugin module for use by the - wlan(4) module. This module is automatically loaded if an - AES-CCMP key is configured; typically by a WPA supplicant program such as - wpa_supplicant, or a WPA authenticator program such as - hostapd. Should the underlying network device not be - capable of doing the AES-CCMP calculations in hardware, the - wlan_ccmp module will do the work.

-
-
-

-

wlan(4), wlan_gcmp(4), - wlan_tkip(4), wlan_wep(4)

-
-
-

-

More information can be found in the IEEE 802.11, WPA, and 802.11i - Standards.

-
-
-

-

The wlan_ccmp driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
December 7, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_gcmp.4 3.html b/static/freebsd/man4/wlan_gcmp.4 3.html deleted file mode 100644 index 4d6b3104..00000000 --- a/static/freebsd/man4/wlan_gcmp.4 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
WLAN_GCMP(4)Device Drivers ManualWLAN_GCMP(4)
-
-
-

-

wlan_gcmp — - AES-GCMP crypto support for 802.11 devices

-
-
-

-

device wlan_gcmp

-
-
-

-

The wlan_gcmp module handles the - cryptographic requirements of the IEEE 802.11ad and - WPA2/WPA3 protocols. It does encapsulation and decapsulation of GCMP-encoded - 802.11 frames and optionally calculates the AES-GCMP cipher. The - wlan_gcmp module is an 802.11 cryptographic plugin - module for use by the wlan(4) module. This module is - automatically loaded if an AES-GCMP key is configured; typically by a WPA - supplicant program such as wpa_supplicant, or a WPA authenticator program - such as hostapd. Should the underlying network - device not be capable of doing the AES-GCMP calculations in hardware, the - wlan_gcmp module will do the work.

-
-
-

-

wlan(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4)

-
-
-

-

More information can be found in the IEEE 802.11, and WPA - Standards.

-
-
-

-

The wlan_gcmp driver first appeared in - FreeBSD 15.0.

-
-
- - - - - -
June 13, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_tkip.4 4.html b/static/freebsd/man4/wlan_tkip.4 4.html deleted file mode 100644 index 469ec9d5..00000000 --- a/static/freebsd/man4/wlan_tkip.4 4.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
WLAN_TKIP(4)Device Drivers ManualWLAN_TKIP(4)
-
-
-

-

wlan_tkip — TKIP - and Michael crypto support for 802.11 devices

-
-
-

-

device wlan_tkip

-
-
-

-

The wlan_tkip module handles the TKIP and - Michael cryptographic requirements of the WPA and 802.11i protocols. It does - encapsulation and decapsulation of TKIP-encoded 802.11 frames and optionally - calculates the TKIP cipher and Michael MIC. The - wlan_tkip module is an 802.11 cryptographic plugin - module for use by the wlan(4) module. This module is - automatically loaded if a TKIP key is configured; typically by a WPA - supplicant program such as wpa_supplicant, or a WPA authenticator program - such as hostapd. Should the underlying network - device not be capable of doing the TKIP and/or Michael calculations in - hardware, the wlan_tkip module will do the work.

-
-
-

-

wlan(4), wlan_ccmp(4), - wlan_gcmp(4), wlan_wep(4)

-
-
-

-

More information can be found in the IEEE 802.11, WPA, and 802.11i - Standards.

-
-
-

-

The wlan_tkip driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
December 7, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_wep.4 3.html b/static/freebsd/man4/wlan_wep.4 3.html deleted file mode 100644 index c4522680..00000000 --- a/static/freebsd/man4/wlan_wep.4 3.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
WLAN_WEP(4)Device Drivers ManualWLAN_WEP(4)
-
-
-

-

wlan_wep — WEP - crypto support for 802.11 devices

-
-
-

-

device wlan_wep

-
-
-

-

The wlan_wep module handles the WEP - cryptographic requirements of the 802.11 protocol. It does encapsulation and - decapsulation of WEP-encoded 802.11 frames and optionally calculates the WEP - cipher. The wlan_wep module is an 802.11 - cryptographic plugin module for use by the wlan(4) module. - This module is automatically loaded if a WEP key is configured with - ifconfig(8). Should the underlying network device not be - capable of doing the WEP calculations in hardware, the - wlan_wep module will do the work.

-
-
-

-

wlan(4), wlan_ccmp(4), - wlan_gcmp(4), wlan_tkip(4)

-
-
-

-

More information can be found in the IEEE 802.11 Standard.

-
-
-

-

The wlan_wep driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
December 7, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/wlan_xauth.4 3.html b/static/freebsd/man4/wlan_xauth.4 3.html deleted file mode 100644 index 7ebb59b7..00000000 --- a/static/freebsd/man4/wlan_xauth.4 3.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
WLAN_XAUTH(4)Device Drivers ManualWLAN_XAUTH(4)
-
-
-

-

wlan_xauth — - External authenticator support for 802.11 - devices

-
-
-

-

device wlan_xauth

-
-
-

-

The wlan_xauth module is a - wlan(4) authenticator plugin for use with user-mode - authentication implementations such as hostapd. It - hooks into the 802.11 layer and does nothing. As a result, 802.11 stations - that associate are not authorized to send or receive frames until they are - authorized by an external agent; typically using a protocol such as WPA, - 802.1x, or 802.11i.

-

This module is automatically loaded by the rc script that normally - starts hostapd(8).

-
-
-

-

wlan(4)

-
-
-

-

More information can be found in the IEEE 802.11, WPA, and 802.11i - Standards.

-
-
-

-

The wlan_xauth driver first appeared in - FreeBSD 6.0.

-
-
- - - - - -
December 7, 2004FreeBSD 15.0
diff --git a/static/freebsd/man4/wmt.4 4.html b/static/freebsd/man4/wmt.4 4.html deleted file mode 100644 index 83cf809a..00000000 --- a/static/freebsd/man4/wmt.4 4.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - -
WMT(4)Device Drivers ManualWMT(4)
-
-
-

-

wmt — MS Windows - 7/8/10 - compatible USB HID multi-touch device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device wmt -
-device usb -
-device hid -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
wmt_load="YES"
-
-
-
-

-

The wmt driver provides support for the MS - Windows 7/8/10 - compatible USB HID multi-touch devices found in many - laptops.

-

To get multi-touch device working in X(7) - (ports/x11/xorg-docs), install - ports/x11-drivers/xf86-input-evdev.

-
-
-

-

wmt creates a pseudo-device file, - /dev/input/eventX which presents the multi-touch - device as an input event device.

-
-
-

-

usb(4), loader.conf(5), - xorg.conf(5) (ports/x11/xorg), - evdev(4) - (ports/x11-drivers/xf86-input-evdev).

-
-
-

-

The wmt driver was written by - Vladimir Kondratyev - <wulf@FreeBSD.org>.

-
-
-

-

wmt cannot act like - sysmouse(4), as sysmouse(4) does not - support absolute motion events.

-
-
- - - - - -
August 19, 2017FreeBSD 15.0
diff --git a/static/freebsd/man4/wpi.4 3.html b/static/freebsd/man4/wpi.4 3.html deleted file mode 100644 index 18fdcc9f..00000000 --- a/static/freebsd/man4/wpi.4 3.html +++ /dev/null @@ -1,180 +0,0 @@ - - - - - - -
WPI(4)Device Drivers ManualWPI(4)
-
-
-

-

wpi — Intel - PRO/Wireless 3945ABG IEEE 802.11a/b/g network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device wpi -
-device wpifw -
-device pci -
-device wlan -
-device wlan_amrr -
-device firmware
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-

-
if_wpi_load="YES"
-
-
-

-

The wpi driver supports running the Intel - PRO/Wireless 3945ABG network adapter in station, - adhoc, adhoc-demo, - hostap, and monitor mode - operation. This driver requires the wpifw firmware module and can be - configured at runtime with ifconfig(8) or at boot in - rc.conf(5). Only one virtual interface may be configured - at any time.

-

The wpi driver can be configured to use - Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and - WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It - is strongly recommended that WEP not be used as the sole mechanism to secure - wireless communication, due to serious weaknesses in it. The - wpi driver offloads both encryption and decryption - of data frames to the hardware for the CCMP cipher.

-
-
-

-

The wpi driver provides support for the - Intel PRO/Wireless 3945ABG Mini PCIe network adapter.

-
-
-

-
-
/usr/share/doc/legal/intel_wpi.LICENSE
-
wpi firmware license
-
-
-
-

-

Join an existing BSS network (i.e., connect to an access - point):

-
-
ifconfig wlan0 create wlandev wpi0 inet 192.168.0.20 \
-    netmask 0xffffff00
-
-

Join a specific BSS network with network name - my_net:

-

-
ifconfig wlan0 create wlandev wpi0 - ssid my_net up
-

Join a specific BSS network with 64-bit WEP encryption:

-
-
ifconfig wlan0 create wlandev wpi0 ssid my_net \
-	wepmode on wepkey 0x1234567890 weptxkey 1 up
-
-

Create an IBSS network with 128-bit WEP encryption on the channel - 4:

-
-
ifconfig wlan0 create wlandev wpi0 wlanmode adhoc ssid my_net \
-	wepmode on wepkey 0x01020304050607080910111213 weptxkey 1 \
-	channel 4
-
-

Join/create an 802.11b IBSS network with network name - my_net:

-
-
ifconfig wlan0 create wlandev wpi0 wlanmode adhoc
-ifconfig wlan0 inet 192.168.0.22 netmask 0xffffff00 ssid my_net \
-	mode 11b
-
-

Create an 802.11g host-based access point:

-
-
ifconfig wlan0 create wlandev wpi0 wlanmode hostap
-ifconfig wlan0 inet 192.168.0.10 netmask 0xffffff00 ssid my_ap \
-	mode 11g
-
-
-
-

-
-
wpi%d: could not load firmware image '%s'
-
The driver failed to load the firmware image using the - firmware(9) subsystem. Verify the wpifw firmware module - is installed.
-
wpi%d: %s: timeout waiting for adapter to initialize, error %d
-
The onboard microcontroller failed to initialize in time. This should not - happen.
-
wpi%d: %s: could not load boot firmware
-
An attempt to upload the boot firmware image to the onboard - microcontroller failed. This should not happen.
-
wpi%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware and continue. This should not - happen.
-
wpi%d: scan timeout
-
Firmware scan command response was not received in time. The driver will - reset the hardware and continue. This should not happen.
-
wpi%d: fatal firmware error
-
The onboard microcontroller crashed for some reason. The driver will reset - the hardware and continue. This should not happen.
-
wpi%d: RF switch: radio disabled
-
The hardware switch controlling the radio is currently turned off. Data - transmission is not possible in this state.
-
wpi%d: can't map mem space
-
The driver was unable to map the device registers into the host address - space. This should not happen.
-
wpi%d: can't map interrupt
-
The driver was unable to allocate an IRQ for the device interrupt. This - should not happen.
-
wpi%d: can't establish interrupt, error %d
-
The driver was unable to install the device interrupt handler. This should - not happen.
-
wpi%d: %s: bus_dmamap_load failed, error %d
-
The driver was unable to map newly allocated mbuf to device visible - address space. Contents of currently received frame will be lost. This - should not happen.
-
-
-
-

-

pci(4), wlan(4), - wlan_amrr(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - wlan_xauth(4), networking(7), - hostapd(8), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The original wpi driver was written for - OpenBSD by Damien Bergamini - <damien.bergamini@free.fr>. - Benjamin Close - <benjsc@FreeBSD.org> - ported wpi to FreeBSD.

-
-
-

-

Hostap mode is not directly supported by - the device; it is implemented through IBSS mode (as a result, DFS/passive - channels are not available in this mode).

-

Powersave may be unstable on some networks (results - in occasional messages); you can try to - disable it to improve device stability.

-
-
- - - - - -
October 17, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/wsp.4 3.html b/static/freebsd/man4/wsp.4 3.html deleted file mode 100644 index d8e6acd3..00000000 --- a/static/freebsd/man4/wsp.4 3.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
WSP(4)Device Drivers ManualWSP(4)
-
-
-

-

wsp — Wellspring - touchpad driver

-
-
-

-

To compile this driver into the kernel, place the following lines - into your kernel configuration file:

-
device wsp -
-device hid -
-device usb
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
wsp_load="YES"
-
-
-
-

-

The wsp driver provides support for the - Apple Internal Trackpad device found in many Apple laptops.

-

The driver simulates a three-button mouse using multi-finger - press/tap detection. A single-finger press generates a left button click. A - two-finger press maps to the right button; whereas a three-finger press gets - treated as a middle button click.

-

The trackpad functions with presses and taps. A press is a - full-forced press which causes a physical lowering of the trackpad. A tap is - a touch of the trackpad which does not depress the physical trackpad.

-

The wsp driver supports receiving evdev - input device data if enabled. This data is used for extended usage of the - touchpad like multi-finger support, pressure detection, tap support, and - gestures. At least the second bit of the sysctl(8) tunable - kern.evdev.rcpt_mask must be set. This can be enabled - with kern.evdev.rcpt_mask=3.

-

Vertical scrolling (z-axis) is enabled by default with a - two-finger tap and the movement of a finger up and down. Horizontal - scrolling (t-axis) is not natively supported by the sysmouse protocol, - therefore must be enabled with evdev data. This can be enabled with the - sysctl(8) tunable - kern.evdev.sysmouse_t_axis=3. Horizontal scrolling can - be used with a two-finger tap and the movement of a finger from side to - side. The sysctl(8) tunable - hw.usb.wsp.t_factor must be greater than 0 for - horizontal scrolling to be enabled, too.

-

Horizontal swiping with a three-finger tap is registered as mouse - buttons 8 and 9, depending on the direction. These buttons default to - backwards and forwards keyboard events.

-
-
-

-

The following variables are available as - sysctl(8) tunables:

-
-
hw.usb.wsp.scale_factor
-
Controls the pointer sensitivity. Default is 12.
-
-
-
hw.usb.wsp.enable_single_tap_clicks
-
Enables single-tap to register as a left-click. Default is 1 - (enabled).
-
-
-
hw.usb.wsp.enable_single_tap_movement
-
Enables movement on the trackpad follow a partially-released left-click. - Default is 1 (enabled).
-
-
-
hw.usb.wsp.max_finger_diameter
-
Specifies the maximum finger diameter on the trackpad that is registered - as a finger (a lower value is used for palm detection). Default is - 1900.
-
-
-
max_scroll_finger_distance
-
Specifies the maximum distance between two fingers where z-axis and t-axis - movements are registered. Z-axis and T-axis movements are vertical and - horizontal movements with more than one finger tapped (not clicked), - respectively. Default is 8192.
-
-
-
hw.usb.wsp.max_double_tap_distance
-
Specifies the maximum distance between two fingers that a two-finger click - will be registered as a right-click. Default is 2500.
-
-
-
hw.usb.wsp.scr_threshold
-
Specifies the minimum horizontal or vertical distance required to register - as a scrolling gesture. Default is 20.
-
-
-
hw.usb.wsp.z_factor
-
Z-axis sensitivity. Default is 5.
-
-
-
hw.usb.wsp.z_invert
-
Z-axis inversion. Default is 0 (disabled).
-
-
-
hw.usb.wsp.t_factor
-
T-axis sensitivity. Default is 0 (disabled).
-
-
-
hw.usb.wsp.t_invert
-
T-axis inversion. Default is 0 (disabled).
-
-
-
hw.usb.wsp.scroll_finger_count
-
Specifies the number of tapped fingers which registers as a scrolling - movement. Default is 2.
-
-
-
hw.usb.wsp.horizontal_swipe_finger_count
-
Speifies the number of tapped fingers which registers as a swipe gesture. - Default is 3.
-
-
-
hw.usb.wsp.pressure_touch_threshold
-
Specifies the threshold for a finger to be registered as a click. Default - is 50.
-
-
-
hw.usb.wsp.pressure_untouch_threshold
-
Specifies the threshold for a finger to be registered as an unclick. - Default is 10.
-
-
-
hw.usb.wsp.pressure_tap_threshold
-
Specifies the threadhold for a finger to be registered as a tap. Default - is 120.
-
-
-
hw.usb.wsp.debug
-
Specifies the wsp driver debugging level (0-3). - Default is 1.
-
-
-
-

-

wsp creates a blocking pseudo-device file, - /dev/wsp0, which presents the mouse as a - - or - - type device--see moused(8) for an explanation of these - mouse types.

-
-
-

-

sysmouse(4), usb(4), - loader.conf(5), xorg.conf(5) - (ports/x11/xorg), moused(8), - sysctl(8)

-
-
-

-

The wsp driver was written by - Huang Wen Hui - <huanghwh@gmail.com>.

-
-
- - - - - -
February 9, 2021FreeBSD 15.0
diff --git a/static/freebsd/man4/xb360gp.4 4.html b/static/freebsd/man4/xb360gp.4 4.html deleted file mode 100644 index 22f00213..00000000 --- a/static/freebsd/man4/xb360gp.4 4.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
XB360GP(4)Device Drivers ManualXB360GP(4)
-
-
-

-

xb360gp — XBox 360 - gamepad driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device xb360gp -
-device hgame -
-device hid -
-device hidbus -
-device hidmap -
-device evdev
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
xb360gp_load="YES"
-
-
-
-

-

The xb360gp driver provides support for - XBox 360 gamepad driver.

-

The /dev/input/event* device - presents the game controller as a evdev type device. - It is accessible to members of the - group.

-
-
-

-

The following variable is available as both - sysctl(8) variable and loader(8) - tunable:

-
-
dev.xb360gp.X.debug
-
Debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. Default is 0.
-
-

It's default value is set with loader(8) - tunable:

-
-
hw.hid.xb360gp.debug
-
 
-
-
-
-

-
-
/dev/input/event*
-
input event device node.
-
-
-
-

-

The xb360gp driver first appeared in - FreeBSD 13.0.

-
-
-

-

The xb360gp driver was written by - Val Packett - <val@packett.cool>.

-

This manual page was written by Vladimir - Kondratyev - <wulf@FreeBSD.org>.

-
-
- - - - - -
November 30, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/xdma.4 3.html b/static/freebsd/man4/xdma.4 3.html deleted file mode 100644 index 4f11bd07..00000000 --- a/static/freebsd/man4/xdma.4 3.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
XDMA(4)Device Drivers ManualXDMA(4)
-
-
-

-

xdma — DMA - abstraction layer

-
-
-

-

To compile xDMA device support into the kernel, place the - following line in your kernel configuration file:

-
device xdma
-

To compile xDMA FDT-based test driver, place the following line as - well:

-
-
device xdma_test
-
-
-
-

-

xDMA is a DMA framework designed to abstract the interaction - between device drivers and DMA engines.

-

xDMA defines an interface for efficient interaction between the - device driver and DMA controller. The xdma device - provides a virtual DMA controller and virtual channels called xchans. The - controller provides virtual channels management (allocation, deallocation, - configuration) and interrupt notification esteblishment needed to receive - events from the hardware DMA controller. xdma - supports the following transfer types:

-
-
Cyclic
-
A non-stop periodic transfer designed for applications like audio.
-
Memcpy
-
A memory-to-memory transfer.
-
-
-
-

-

bus_dma(9)

-
-
-

-

Support for xDMA first appeared in FreeBSD - 12.0.

-
-
-

-

FreeBSD xDMA framework was first added by - Ruslan Bukin - <br@FreeBSD.org>.

-
-
- - - - - -
December 12, 2016FreeBSD 15.0
diff --git a/static/freebsd/man4/xen.4 3.html b/static/freebsd/man4/xen.4 3.html deleted file mode 100644 index 9c05924e..00000000 --- a/static/freebsd/man4/xen.4 3.html +++ /dev/null @@ -1,126 +0,0 @@ - - - - - - -
XEN(4)Device Drivers ManualXEN(4)
-
-
-

-

xen — Xen - Hypervisor Support

-
-
-

-

FreeBSD supports running both as a Xen guest and host on amd64 - hardware. Guest support is limited to HVM and PVH modes, while host support - is limited to PVH mode only.

-

Xen support is built by default in the i386 and amd64 GENERIC - kernels; note however that host mode is only available on amd64.

-
-
-

-

The Xen Hypervisor allows multiple virtual machines to be run on a - single computer system. When first released, Xen required that i386 kernels - be compiled "para-virtualized" as the x86 instruction set was not - fully virtualizable. Primarily, para-virtualization modifies the virtual - memory system to use hypervisor calls (hypercalls) rather than direct - hardware instructions to modify the TLB, although para-virtualized device - drivers were also required to access resources such as virtual network - interfaces and disk devices.

-

With later instruction set extensions from AMD and Intel to - support fully virtualizable instructions, unmodified virtual memory systems - can also be supported; this is referred to as hardware-assisted - virtualization (HVM and PVH). HVM configurations may either rely on - transparently emulated hardware peripherals, or para-virtualized drivers, - which are aware of virtualization, and hence able to optimize certain - behaviors to improve performance or semantics. PVH configurations rely on - para-virtualized drivers exclusively for IO.

-

FreeBSD Para-virtualized device drivers - are required in order to support certain functionality, such as processing - management requests, returning idle physical memory pages to the hypervisor, - etc.

-
-

-

These para-virtualized drivers are supported:

-
-
balloon
-
Allow physical memory pages to be returned to the hypervisor as a result - of manual tuning or automatic policy.
-
blkback
-
Exports local block devices or files to other Xen domains where they can - then be imported via blkfront.
-
blkfront
-
Import block devices from other Xen domains as local block devices, to be - used for file systems, swap, etc.
-
console
-
Export the low-level system console via the Xen console service.
-
control
-
Process management operations from Domain 0, including power off, reboot, - suspend, crash, and halt requests.
-
evtchn
-
Expose Xen events via the /dev/xen/evtchn special - device.
-
gntdev
-
Allow access to the grant table interface via the - /dev/xen/gntdev special device.
-
netback
-
Export local network interfaces to other Xen domains where they can be - imported via netfront.
-
netfront
-
Import network interfaces from other Xen domains as local network - interfaces, which may be used for IPv4, IPv6, etc.
-
privcmd
-
Allow issuing hypercalls via the /dev/xen/privcmd - special device.
-
timer
-
Implementation of a one-shot high resolution per-CPU timer using the - hypercall interface.
-
acpi cpu
-
When running as a host forwards power management related information from - ACPI to the hypervisor for better performance management.
-
xenpci
-
Represents the Xen PCI device, an emulated PCI device that is exposed to - HVM domains. This device allows detection of the Xen hypervisor, and - provides interrupt and shared memory services required to interact with - the hypervisor.
-
xenstore
-
Information storage space shared between domains.
-
-
-
-
-

-

Support for xen first appeared in - FreeBSD 8.1. Support for host mode was added in 11.0 - .

-
-
-

-

FreeBSD support for Xen was first added by - Kip Macy - <kmacy@FreeBSD.org> - and Doug Rabson - <dfr@FreeBSD.org>. - Further refinements were made by Justin Gibbs - <gibbs@FreeBSD.org>, - Adrian Chadd - <adrian@FreeBSD.org>, - Colin Percival - <cperciva@FreeBSD.org>, - and Roger Pau Monné - <royger@FreeBSD.org>. - This manual page was written by Robert Watson - <rwatson@FreeBSD.org>, - and Roger Pau Monné - <royger@FreeBSD.org>.

-
-
- - - - - -
January 8, 2024FreeBSD 15.0
diff --git a/static/freebsd/man4/xhci.4 3.html b/static/freebsd/man4/xhci.4 3.html deleted file mode 100644 index 0ed1eb09..00000000 --- a/static/freebsd/man4/xhci.4 3.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
XHCI(4)Device Drivers ManualXHCI(4)
-
-
-

-

xhci — USB - eXtensible Host Controller driver

-
-
-

-

options USB_DEBUG -
- device xhci

-
-
-

-

The xhci driver provides support for the - USB eXtensible Host Controller Interface, which allows use of USB 1.0, 2.0 - and 3.0 devices on the same USB port.

-

The XHCI controller supports USB connection speeds from 5.0Gbps - and above when using USB 3.x compliant devices.

-
-
-

-

The xhci driver supports XHCI compatible - controllers having PCI class 12 (serial bus), subclass 3 (USB) and - programming interface 48 (XHCI).

-
-
-

-

The following variables are available as both - sysctl(8) variables and loader(8) - tunables:

-
-
hw.usb.xhci.debug
-
Set debug output level, where 0 is debugging disabled and larger values - increase debug message verbosity. The default value is 0.
-
hw.usb.xhci.dcepquirk
-
Set to enable quirk for deconfiguration of endpoints. The default value is - 0.
-
hw.usb.xhci.ctlquirk
-
Set to submit full USB control request as one job, up to 64kBytes. Else - the USB control request will be split into multiple smaller requests. The - default value is 1.
-
hw.usb.xhci.streams
-
Set to enable USB streams support. The default value is 0.
-
hw.usb.xhci.route
-
Set bitmap for switching EHCI ports to the XHCI controller. The default - value is 0.
-
hw.usb.xhci.polling
-
Set to use a timer to poll the interrupt handler. The default value is - 0.
-
hw.usb.xhci.dma32
-
Set to only use 32-bit DMA for the XHCI controller. The default value is - 0.
-
hw.usb.xhci.ctlstep
-
Set to enable control endpoint status state stepping. The default value is - 0.
-
-
-
-

-

ehci(4), ohci(4), - uhci(4) and usb(4)

-
-
-

-

The xhci device driver first appeared in - FreeBSD 8.2.

-
-
- - - - - -
October 21, 2022FreeBSD 15.0
diff --git a/static/freebsd/man4/xl.4 3.html b/static/freebsd/man4/xl.4 3.html deleted file mode 100644 index 690c101e..00000000 --- a/static/freebsd/man4/xl.4 3.html +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - -
XL(4)Device Drivers ManualXL(4)
-
-
-

-

xl — 3Com - Etherlink XL and Fast Etherlink XL Ethernet device driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device miibus -
-device xl
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_xl_load="YES"
-
-
-
-

-

The xl driver provides support for PCI - Ethernet adapters and embedded controllers based on the 3Com - "boomerang," "cyclone," "hurricane" and - "tornado" bus-master Etherlink XL chips.

-

The Etherlink XL chips support built-in 10baseT, 10base2 and - 10base5 transceivers as well as an MII bus for externally attached PHY - transceivers. The 3c905 series typically uses a National Semiconductor NS - 83840A 10/100 PHY for 10/100 Mbps support in full or half-duplex. The 3c905B - adapters have built-in autonegotiation logic mapped onto the MII for - compatibility with previous drivers. Fast Etherlink XL adapters such as the - 3c905-TX and 3c905B-TX are capable of 10 or 100Mbps data rates in either - full or half duplex and can be manually configured for any supported mode or - automatically negotiate the highest possible mode with a link partner.

-

The xl driver supports the following media - types:

-
-
autoselect
-
Enable autoselection of the media type and options. Note that this option - is only available with the 3c905 and 3c905B adapters with external PHYs or - built-in autonegotiation logic. For 3c900 adapters, the driver will choose - the mode specified in the EEPROM. The user can change this by adding media - options to the /etc/rc.conf file.
-
10baseT/UTP
-
Set 10Mbps operation. The mediaopt option can also - be used to select either full-duplex or - half-duplex modes.
-
100baseTX
-
Set 100Mbps (Fast Ethernet) operation. The mediaopt - option can also be used to select either full-duplex - or half-duplex modes.
-
10base5/AUI
-
Enable AUI transceiver (available only on COMBO cards).
-
10base2/BNC
-
Enable BNC coax transceiver (available only on COMBO cards).
-
-

The xl driver supports the following media - options:

-
-
full-duplex
-
Force full duplex operation.
-
half-duplex
-
Force half duplex operation.
-
-

Note that the 100baseTX media type is only available if supported - by the adapter. For more information on configuring this device, see - ifconfig(8).

-
-
-

-

The xl driver supports the following - hardware:

-

-
    -
  • 3Com 3c900-TPO
    • -
  • 3Com 3c900-COMBO
    • -
  • 3Com 3c905-TX
    • -
  • 3Com 3c905-T4
    • -
  • 3Com 3c900B-TPO
    • -
  • 3Com 3c900B-TPC
    • -
  • 3Com 3c900B-FL
    • -
  • 3Com 3c900B-COMBO
    • -
  • 3Com 3c905B-T4
    • -
  • 3Com 3c905B-TX
    • -
  • 3Com 3c905B-FX
    • -
  • 3Com 3c905B-COMBO
    • -
  • 3Com 3c905C-TX
    • -
  • 3Com 3c980, 3c980B, and 3c980C server adapters
    • -
  • 3Com 3cSOHO100-TX OfficeConnect adapters
    • -
  • 3Com 3c450 HomeConnect adapters
    • -
  • 3Com 3c555, 3c556 and 3c556B mini-PCI adapters
    • -
  • 3Com 3C3SH573BT, 3C575TX, 3CCFE575BT, 3CXFE575BT, 3CCFE575CT, 3CXFE575CT, - 3CCFEM656, 3CCFEM656B, and 3CCFEM656C, 3CXFEM656, 3CXFEM656B, and - 3CXFEM656C CardBus adapters
    • -
  • 3Com 3c905-TX, 3c905B-TX 3c905C-TX, 3c920B-EMB, and 3c920B-EMB-WNM - embedded adapters
    • -
-

Both the 3C656 family of CardBus cards and the 3C556 family of - MiniPCI cards have a built-in proprietary modem. Neither the - xl driver nor any other - FreeBSD driver supports this modem.

-
-
-

-
-
xl%d: couldn't map memory
-
A fatal initialization error has occurred.
-
xl%d: couldn't map interrupt
-
A fatal initialization error has occurred.
-
xl%d: device timeout
-
The device has stopped responding to the network, or there is a problem - with the network connection (cable).
-
xl%d: no memory for rx list
-
The driver failed to allocate an mbuf for the receiver ring.
-
xl%d: no memory for tx list
-
The driver failed to allocate an mbuf for the transmitter ring when - allocating a pad buffer or collapsing an mbuf chain into a cluster.
-
xl%d: command never completed!
-
Some commands issued to the 3c90x ASIC take time to complete: the driver - is supposed to wait until the 'command in progress' bit in the status - register clears before continuing. In rare instances, this bit may not - clear. To avoid getting caught in an infinite wait loop, the driver only - polls the bit for a finite number of times before giving up, at which - point it issues this message. This message may be printed during driver - initialization on slower machines. If you see this message but the driver - continues to function normally, the message can probably be ignored.
-
xl%d: chip is in D3 power state -- setting to D0
-
This message applies only to 3c905B adapters, which support power - management. Some operating systems place the 3c905B in low power mode when - shutting down, and some PCI BIOSes fail to bring the chip out of this - state before configuring it. The 3c905B loses all of its PCI configuration - in the D3 state, so if the BIOS does not set it back to full power mode in - time, it will not be able to configure it correctly. The driver tries to - detect this condition and bring the adapter back to the D0 (full power) - state, but this may not be enough to return the driver to a fully - operational condition. If you see this message at boot time and the driver - fails to attach the device as a network interface, you will have to - perform second warm boot to have the device properly configured. -

Note that this condition only occurs when warm booting from - another operating system. If you power down your system prior to booting - FreeBSD, the card should be configured - correctly.

-
-
xl%d: WARNING: no media options bits set in the media options - register!
-
This warning may appear when using the driver on some Dell Latitude - docking stations with built-in 3c905-TX adapters. For whatever the reason, - the 'MII available' bit in the media options register on this particular - equipment is not set, even though it should be (the 3c905-TX always uses - an external PHY transceiver). The driver will attempt to guess the proper - media type based on the PCI device ID word. The driver makes a lot of - noise about this condition because the author considers it a manufacturing - defect.
-
xl%d: transmission error: %d
-
-
xl%d: tx underrun, increasing tx start threshold to %d bytes
-
This message may appear while the adapter tunes its transmission buffers - under various load amounts and are mostly harmless. It is probably safe to - ignore them.
-
-
-
-

-

altq(4), arp(4), - cardbus(4), miibus(4), - netintro(4), ng_ether(4), - polling(4), ifconfig(8)

-
-
-

-

The xl device driver first appeared in - FreeBSD 3.0.

-
-
-

-

The xl driver was written by - Bill Paul - <wpaul@ctr.columbia.edu>.

-
-
- - - - - -
January 23, 2008FreeBSD 15.0
diff --git a/static/freebsd/man4/xnb.4 3.html b/static/freebsd/man4/xnb.4 3.html deleted file mode 100644 index 0b35e750..00000000 --- a/static/freebsd/man4/xnb.4 3.html +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - -
XNB(4)Device Drivers ManualXNB(4)
-
-
-

-

xnb — Xen - Paravirtualized Backend Ethernet Driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
options XENHVM -
-device xenpci
-
-
-

-

The xnb driver provides the back half of a - paravirtualized xen(4) network connection. The netback and - netfront drivers appear to their respective operating systems as Ethernet - devices linked by a crossover cable. Typically, xnb - will run on Domain 0 and the netfront driver will run on a guest domain. - However, it is also possible to run xnb on a guest - domain. It may be bridged or routed to provide the netfront domain access to - other guest domains or to a physical network.

-

In most respects, the xnb device appears - to the OS as any other Ethernet device. It can be configured at runtime - entirely with ifconfig(8). In particular, it supports MAC - changing, arbitrary MTU sizes, checksum offload for IP, UDP, and TCP for - both receive and transmit, and TSO. However, see - CAVEATS before enabling txcsum, rxcsum, or - tso.

-
-
-

-

The following read-only variables are available via - sysctl(8):

-
-
dev.xnb.%d.dump_rings
-
Displays information about the ring buffers used to pass requests between - the netfront and netback. Mostly useful for debugging, but can also be - used to get traffic statistics.
-
dev.xnb.%d.unit_test_results
-
Runs a builtin suite of unit tests and displays the results. Does not - affect the operation of the driver in any way. Note that the test suite - simulates error conditions; this will result in error messages being - printed to the system log.
-
-
-
-

-

arp(4), netintro(4), - ng_ether(4), xen(4), - ifconfig(8)

-
-
-

-

The xnb device driver first appeared in - FreeBSD 10.0.

-
-
-

-

The xnb driver was written by - Alan Somers - <asomers@FreeBSD.org> - and John Suykerbuyk.

-
-
-

-

Packets sent through Xennet pass over shared memory, so the - protocol includes no form of link-layer checksum or CRC. Furthermore, Xennet - drivers always report to their hosts that they support receive and transmit - checksum offloading. They "offload" the checksum calculation by - simply skipping it. That works fine for packets that are exchanged between - two domains on the same machine. However, when a Xennet interface is bridged - to a physical interface, a correct checksum must be attached to any packets - bound for that physical interface. Currently, - FreeBSD lacks any mechanism for an Ethernet device - to inform the OS that newly received packets are valid even though their - checksums are not. So if the netfront driver is configured to offload - checksum calculations, it will pass non-checksumed packets to - xnb, which must then calculate the checksum in - software before passing the packet to the OS.

-

For this reason, it is recommended that if - xnb is bridged to a physical interface, then - transmit checksum offloading should be disabled on the netfront. The Xennet - protocol does not have any mechanism for the netback to request the netfront - to do this; the operator must do it manually.

-
-
-

-

The xnb driver does not properly checksum - UDP datagrams that span more than one Ethernet frame. Nor does it correctly - checksum IPv6 packets. To workaround that bug, disable transmit checksum - offloading on the netfront driver.

-
-
- - - - - -
June 6, 2014FreeBSD 15.0
diff --git a/static/freebsd/man4/xpt.4 4.html b/static/freebsd/man4/xpt.4 4.html deleted file mode 100644 index 289e163a..00000000 --- a/static/freebsd/man4/xpt.4 4.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - -
XPT(4)Device Drivers ManualXPT(4)
-
-
-

-

xpt — CAM - transport layer interface

-
-
-

-

None.

-
-
-

-

The xpt driver provides a way for userland - applications to issue certain CAM CCBs to the kernel.

-

Since the xpt driver allows direct access - to the CAM subsystem, system administrators should exercise caution when - granting access to this driver. If used improperly, this driver can allow - userland applications to crash a machine or cause data loss.

-
-
-

-

There is no kernel configuration required for the - xpt driver. It is enabled when SCSI support is - enabled in the kernel. There is one instance of the xpt driver per CAM - transport layer instance. Since there is currently only one CAM transport - layer, there will only be one instance of this driver.

-
-
-

-
-
CAMIOCOMMAND
-
This ioctl takes certain kinds of CAM CCBs and passes them through to the - CAM transport layer for action. Only the following CCB types are - supported: -

-
-
XPT_SCAN_BUS
-
 
-
XPT_RESET_BUS
-
 
-
XPT_SCAN_LUN
-
 
-
XPT_ENG_INQ
-
 
-
XPT_ENG_EXEC
-
 
-
XPT_DEBUG
-
 
-
XPT_DEV_MATCH
-
 
-
XPT_PATH_INQ
-
 
-
-

The above CCBs are the only ones supported since it makes more - sense to send them through a generic passthrough device rather than a - passthrough device tied to a particular underlying SCSI device.

-
-
CAMGETPASSTHRU
-
This ioctl takes an XPT_GDEVLIST CCB, and returns the passthrough device - corresponding to the device in question.
-
-
-
-

-
-
/dev/xpt0
-
Character device node for the xpt driver.
-
-
-
-

-

None.

-
-
-

-

cam(3), cam_cdbparse(3), - pass(4), camcontrol(8)

-
-
-

-

The CAM transport layer driver first appeared in - FreeBSD 3.0.

-
-
-

-

Kenneth Merry - <ken@FreeBSD.org>

-
-
- - - - - -
October 10, 1998FreeBSD 15.0
diff --git a/static/freebsd/man4/zero.4 3.html b/static/freebsd/man4/zero.4 3.html deleted file mode 100644 index 101ac328..00000000 --- a/static/freebsd/man4/zero.4 3.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - -
ZERO(4)Device Drivers ManualZERO(4)
-
-
-

-

zero — the zero - device

-
-
-

-

The zero device accepts and reads data as - any ordinary (and willing) file, but throws away any data written to it, and - returns an endless supply of null bytes when read.

-
-
-

-
-
/dev/zero
-
 
-
-
-
-

-

full(4), gzero(4), - null(4)

-
-
-

-

A zero device appeared in - 4.4BSD.

-
-
- - - - - -
November 9, 2025FreeBSD 15.0
diff --git a/static/freebsd/man4/zyd.4 4.html b/static/freebsd/man4/zyd.4 4.html deleted file mode 100644 index 5cd12d86..00000000 --- a/static/freebsd/man4/zyd.4 4.html +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - -
ZYD(4)Device Drivers ManualZYD(4)
-
-
-

-

zyd — ZyDAS - ZD1211/ZD1211B USB IEEE 802.11b/g wireless network driver

-
-
-

-

To compile this driver into the kernel, place the following lines - in your kernel configuration file:

-
device ehci -
-device uhci -
-device ohci -
-device usb -
-device zyd -
-device wlan -
-device wlan_amrr
-

Alternatively, to load the driver as a module at boot time, place - the following line in loader.conf(5):

-
-
if_zyd_load="YES"
-
-
-
-

-

The zyd driver provides support for - wireless network adapters based around the ZyDAS ZD1211 and ZD1211B USB - chips.

-

zyd supports - station and monitor mode - operation. Only one virtual interface may be configured at any time. For - more information on configuring this device, see - ifconfig(8).

-
-
-

-

The following devices are known to be supported by the - zyd driver:

-

-
    -
  • 3COM 3CRUSB10075
    • -
  • Acer WLAN-G-US1
    • -
  • Airlink+ AWLL3025
    • -
  • Airlink 101 AWLL3026
    • -
  • AOpen 802.11g WL54
    • -
  • Asus A9T integrated wireless
    • -
  • Asus WL-159g
    • -
  • Belkin F5D7050 v.4000
    • -
  • Billion BiPAC 3011G
    • -
  • Buffalo WLI-U2-KG54L
    • -
  • CC&C WL-2203B
    • -
  • DrayTek Vigor 550
    • -
  • Edimax EW-7317UG
    • -
  • Edimax EW-7317LDG
    • -
  • Fiberline Networks WL-43OU
    • -
  • iNexQ UR055g
    • -
  • Linksys WUSBF54G
    • -
  • Longshine LCS-8131G3
    • -
  • MSI US54SE
    • -
  • MyTek MWU-201 USB adapter
    • -
  • Philips SNU5600
    • -
  • Planet WL-U356
    • -
  • Planex GW-US54GZ
    • -
  • Planex GW-US54GZL
    • -
  • Planex GW-US54Mini
    • -
  • Safecom SWMULZ-5400
    • -
  • Sagem XG 760A
    • -
  • Sagem XG 76NA
    • -
  • Sandberg Wireless G54 USB
    • -
  • Sitecom WL-113
    • -
  • SMC SMCWUSB-G
    • -
  • Sweex wireless USB 54 Mbps
    • -
  • Tekram/Siemens USB adapter
    • -
  • Telegent TG54USB
    • -
  • Trendnet TEW-424UB rev A
    • -
  • Trendnet TEW-429UB
    • -
  • TwinMOS G240
    • -
  • Unicorn WL-54G
    • -
  • US Robotics 5423
    • -
  • X-Micro XWL-11GUZX
    • -
  • Yakumo QuickWLAN USB
    • -
  • Zonet ZEW2501
    • -
  • ZyXEL ZyAIR G-202
    • -
  • ZyXEL ZyAIR G-220
    • -
-
-
-

-

The following example configures zyd0 to join any BSS network - using WEP key “0x1deadbeef1”, channel 11:

-
-
ifconfig wlan create wlandev zyd0 channel 11 \
-    wepmode on wepkey 0x1deadbeef1 weptxkey 1 \
-    inet 192.0.2.20/24
-
-

Join an existing BSS network, my_net:

-
-
ifconfig wlan create wlandev zyd0 192.0.2.20/24 \
-    ssid my_net
-
-
-
-

-
-
zyd%d: could not load firmware (error=%d)
-
An error occurred while attempting to upload the firmware to the onboard - microcontroller unit.
-
zyd%d: could not send command (error=%s)
-
An attempt to send a command to the firmware failed.
-
zyd%d: sorry, radio %s is not supported yet
-
Support for the specified radio chip is not yet implemented in the driver. - The device will not attach.
-
zyd%d: device version mismatch: 0x%x (only >= 43.30 supported)
-
Early revisions of the ZD1211 chipset are not supported by this driver. - The device will not attach.
-
zyd%d: device timeout
-
A frame dispatched to the hardware for transmission did not complete in - time. The driver will reset the hardware. This should not happen.
-
-
-
-

-

intro(4), netintro(4), - usb(4), wlan(4), - wlan_amrr(4), wlan_ccmp(4), - wlan_tkip(4), wlan_wep(4), - networking(7), ifconfig(8), - wpa_supplicant(8)

-
-
-

-

The original zyd driver was written by - Florian Stoehr - <ich@florian-stoehr.de>, - Damien Bergamini - <damien@openbsd.org>, - and Jonathan Gray - <jsg@openbsd.org>.

-
-
-

-

The zyd driver does not support a lot of - the functionality available in the hardware. More work is required to - properly support the IBSS and power management features.

-
-
- - - - - -
November 10, 2024FreeBSD 15.0
diff --git a/static/freebsd/man5/a.out.5 3.html b/static/freebsd/man5/a.out.5 3.html deleted file mode 100644 index f4fb643b..00000000 --- a/static/freebsd/man5/a.out.5 3.html +++ /dev/null @@ -1,354 +0,0 @@ - - - - - - -
A.OUT(5)File Formats ManualA.OUT(5)
-
-
-

-

a.out — format of - executable binary files

-
-
-

-

#include - <a.out.h>

-
-
-

-

The include file - <a.out.h> declares three - structures and several macros. The structures describe the format of - executable machine code files (‘binaries’) on the system.

-

A binary file consists of up to 7 sections. In order, these - sections are:

-
-
exec header
-
Contains parameters used by the kernel to load a binary file into memory - and execute it, and by the link editor ld(1) to combine - a binary file with other binary files. This section is the only mandatory - one.
-
text segment
-
Contains machine code and related data that are loaded into memory when a - program executes. May be loaded read-only.
-
data segment
-
Contains initialized data; always loaded into writable memory.
-
text relocations
-
Contains records used by the link editor to update pointers in the text - segment when combining binary files.
-
data relocations
-
Like the text relocation section, but for data segment pointers.
-
symbol table
-
Contains records used by the link editor to cross reference the addresses - of named variables and functions (‘symbols’) between binary - files.
-
string table
-
Contains the character strings corresponding to the symbol names.
-
-

Every binary file begins with an exec - structure:

-
-
struct exec {
-	unsigned long	a_midmag;
-	unsigned long	a_text;
-	unsigned long	a_data;
-	unsigned long	a_bss;
-	unsigned long	a_syms;
-	unsigned long	a_entry;
-	unsigned long	a_trsize;
-	unsigned long	a_drsize;
-};
-
-

The fields have the following functions:

-
-
a_midmag
-
This field is stored in host byte-order. It has a number of sub-components - accessed by the macros - (), - N_GETMID(), and - N_GETMAGIC(), and set by the macro - (). -

The macro - () - returns a few flags:

-
-
-
indicates that the executable requires the services of the run-time - link editor.
-
-
indicates that the object contains position independent code. This - flag is set by as(1) when given the - ‘-k’ flag and is preserved by ld(1) if - necessary.
-
-

If both EX_DYNAMIC and EX_PIC are set, the object file is a - position independent executable image (e.g. a shared library), which is - to be loaded into the process address space by the run-time link - editor.

-

The macro - () - returns the machine-id. This indicates which machine(s) the binary is - intended to run on.

-

() - specifies the magic number, which uniquely identifies binary files and - distinguishes different loading conventions. The field must contain one - of the following values:

-
-
-
The text and data segments immediately follow the header and are - contiguous. The kernel loads both text and data segments into writable - memory.
-
-
As with OMAGIC, text and data segments - immediately follow the header and are contiguous. However, the kernel - loads the text into read-only memory and loads the data into writable - memory at the next page boundary after the text.
-
-
The kernel loads individual pages on demand from the binary. The - header, text segment and data segment are all padded by the link - editor to a multiple of the page size. Pages that the kernel loads - from the text segment are read-only, while pages from the data segment - are writable.
-
-
-
a_text
-
Contains the size of the text segment in bytes.
-
a_data
-
Contains the size of the data segment in bytes.
-
a_bss
-
Contains the number of bytes in the ‘bss segment’ and is - used by the kernel to set the initial break (brk(2)) - after the data segment. The kernel loads the program so that this amount - of writable memory appears to follow the data segment and initially reads - as zeroes. ( = - block started by symbol)
-
a_syms
-
Contains the size in bytes of the symbol table section.
-
a_entry
-
Contains the address in memory of the entry point of the program after the - kernel has loaded it; the kernel starts the execution of the program from - the machine instruction at this address.
-
a_trsize
-
Contains the size in bytes of the text relocation table.
-
a_drsize
-
Contains the size in bytes of the data relocation table.
-
-

The <a.out.h> - include file defines several macros which use an exec - structure to test consistency or to locate section offsets in the binary - file.

-
-
(exec)
-
Nonzero if the a_magic field does not contain a - recognized value.
-
(exec)
-
The byte offset in the binary file of the beginning of the text - segment.
-
(exec)
-
The byte offset of the beginning of the symbol table.
-
(exec)
-
The byte offset of the beginning of the string table.
-
-

Relocation records have a standard format which is described by - the relocation_info structure:

-
-
struct relocation_info {
-	int		r_address;
-	unsigned int	r_symbolnum : 24,
-			r_pcrel : 1,
-			r_length : 2,
-			r_extern : 1,
-			r_baserel : 1,
-			r_jmptable : 1,
-			r_relative : 1,
-			r_copy : 1;
-};
-
-

The relocation_info fields are used as - follows:

-
-
r_address
-
Contains the byte offset of a pointer that needs to be link-edited. Text - relocation offsets are reckoned from the start of the text segment, and - data relocation offsets from the start of the data segment. The link - editor adds the value that is already stored at this offset into the new - value that it computes using this relocation record.
-
r_symbolnum
-
Contains the ordinal number of a symbol structure in the symbol table (it - is a byte - offset). After the link editor resolves the absolute address for this - symbol, it adds that address to the pointer that is undergoing relocation. - (If the r_extern bit is clear, the situation is - different; see below.)
-
r_pcrel
-
If this is set, the link editor assumes that it is updating a pointer that - is part of a machine code instruction using pc-relative addressing. The - address of the relocated pointer is implicitly added to its value when the - running program uses it.
-
r_length
-
Contains the log base 2 of the length of the pointer in bytes; 0 for - 1-byte displacements, 1 for 2-byte displacements, 2 for 4-byte - displacements.
-
r_extern
-
Set if this relocation requires an external reference; the link editor - must use a symbol address to update the pointer. When the - r_extern bit is clear, the relocation is - ‘local’; the link editor updates the pointer to reflect - changes in the load addresses of the various segments, rather than changes - in the value of a symbol (except when r_baserel is - also set (see below). In this case, the content of the - r_symbolnum field is an n_type - value (see below); this type field tells the link editor what segment the - relocated pointer points into.
-
r_baserel
-
If set, the symbol, as identified by the r_symbolnum - field, is to be relocated to an offset into the Global Offset Table. At - run-time, the entry in the Global Offset Table at this offset is set to be - the address of the symbol.
-
r_jmptable
-
If set, the symbol, as identified by the r_symbolnum - field, is to be relocated to an offset into the Procedure Linkage - Table.
-
r_relative
-
If set, this relocation is relative to the (run-time) load address of the - image this object file is going to be a part of. This type of relocation - only occurs in shared objects.
-
r_copy
-
If set, this relocation record identifies a symbol whose contents should - be copied to the location given in r_address. The - copying is done by the run-time link-editor from a suitable data item in a - shared object.
-
-

Symbols map names to addresses (or more generally, strings to - values). Since the link-editor adjusts addresses, a symbol's name must be - used to stand for its address until an absolute value has been assigned. - Symbols consist of a fixed-length record in the symbol table and a - variable-length name in the string table. The symbol table is an array of - nlist structures:

-
-
struct nlist {
-	union {
-		const char	*n_name;
-		long		n_strx;
-	} n_un;
-	unsigned char		n_type;
-	char			n_other;
-	short			n_desc;
-	unsigned long		n_value;
-};
-
-

The fields are used as follows:

-
-
n_un.n_strx
-
Contains a byte offset into the string table for the name of this symbol. - When a program accesses a symbol table with the nlist(3) - function, this field is replaced with the - n_un.n_name field, which is a pointer to the string - in memory.
-
n_type
-
Used by the link editor to determine how to update the symbol's value. The - n_type field is broken down into three sub-fields - using bitmasks. The link editor treats symbols with the - N_EXT type bit set as ‘external’ - symbols and permits references to them from other binary files. The - N_TYPE mask selects bits of interest to the link - editor: -
-
-
An undefined symbol. The link editor must locate an external symbol - with the same name in another binary file to determine the absolute - value of this symbol. As a special case, if the - n_value field is nonzero and no binary file in - the link-edit defines this symbol, the link-editor will resolve this - symbol to an address in the bss segment, reserving an amount of bytes - equal to n_value. If this symbol is undefined in - more than one binary file and the binary files do not agree on the - size, the link editor chooses the greatest size found across all - binaries.
-
-
An absolute symbol. The link editor does not update an absolute - symbol.
-
-
A text symbol. This symbol's value is a text address and the link - editor will update it when it merges binary files.
-
-
A data symbol; similar to N_TEXT but for data - addresses. The values for text and data symbols are not file offsets - but addresses; to recover the file offsets, it is necessary to - identify the loaded address of the beginning of the corresponding - section and subtract it, then add the offset of the section.
-
-
A bss symbol; like text or data symbols but has no corresponding - offset in the binary file.
-
-
A filename symbol. The link editor inserts this symbol before the - other symbols from a binary file when merging binary files. The name - of the symbol is the filename given to the link editor, and its value - is the first text address from that binary file. Filename symbols are - not needed for link-editing or loading, but are useful for - debuggers.
-
-

The N_STAB mask selects bits of - interest to symbolic debuggers such as gdb(1) - (ports/devel/gdb); the values are described in - stab(5).

-
-
n_other
-
This field provides information on the nature of the symbol independent of - the symbol's location in terms of segments as determined by the - n_type field. Currently, the lower 4 bits of the - n_other field hold one of two values: - AUX_FUNC and AUX_OBJECT - (see <link.h> for their - definitions). AUX_FUNC associates the symbol with - a callable function, while AUX_OBJECT associates - the symbol with data, irrespective of their locations in either the text - or the data segment. This field is intended to be used by - ld(1) for the construction of dynamic executables.
-
n_desc
-
Reserved for use by debuggers; passed untouched by the link editor. - Different debuggers use this field for different purposes.
-
n_value
-
Contains the value of the symbol. For text, data and bss symbols, this is - an address; for other symbols (such as debugger symbols), the value may be - arbitrary.
-
-

The string table consists of an - - length followed by null-terminated symbol strings. The length represents the - size of the entire table in bytes, so its minimum value (or the offset of - the first string) is always 4 on 32-bit machines.

-
-
-

-

as(1), gdb(1) - (ports/devel/gdb), ld(1), - brk(2), execve(2), - nlist(3), core(5), - elf(5), link(5), - stab(5)

-
-
-

-

The <a.out.h> - include file appeared in Version 7 AT&T - UNIX.

-
-
-

-

Since not all of the supported architectures use the - a_midmag field, it can be difficult to determine what - architecture a binary will execute on without examining its actual machine - code. Even with a machine identifier, the byte order of the - exec header is machine-dependent.

-
-
- - - - - -
June 10, 2010FreeBSD 15.0
diff --git a/static/freebsd/man5/acct.5 3.html b/static/freebsd/man5/acct.5 3.html deleted file mode 100644 index a898191a..00000000 --- a/static/freebsd/man5/acct.5 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
ACCT(5)File Formats ManualACCT(5)
-
-
-

-

acct — execution - accounting file

-
-
-

-

#include - <sys/types.h> -
- #include <sys/acct.h>

-
-
-

-

The kernel maintains the following acct - information structure for all processes. If a process terminates, and - accounting is enabled, the kernel calls the acct(2) - function call to prepare and append the record to the accounting file.

-
-
#define AC_COMM_LEN 16
-
-/*
- * Accounting structure version 3 (current).
- * The first byte is always zero.
- * Time units are microseconds.
- */
-
-struct acctv3 {
-	uint8_t  ac_zero;		/* zero identifies new version */
-	uint8_t  ac_version;		/* record version number */
-	uint16_t ac_len;		/* record length */
-
-	char	  ac_comm[AC_COMM_LEN];	/* command name */
-	float	  ac_utime;		/* user time */
-	float	  ac_stime;		/* system time */
-	float	  ac_etime;		/* elapsed time */
-	time_t	  ac_btime;		/* starting time */
-	uid_t	  ac_uid;		/* user id */
-	gid_t	  ac_gid;		/* group id */
-	float	  ac_mem;		/* average memory usage */
-	float	  ac_io;		/* count of IO blocks */
-	__dev_t   ac_tty;		/* controlling tty */
-
-	uint16_t ac_len2;		/* record length */
-	union {
-		uint32_t  ac_align;	/* force v1 compatible alignment */
-
-#define	AFORK	0x01			/* forked but not exec'ed */
-/* ASU is no longer supported */
-#define	ASU	0x02			/* used super-user permissions */
-#define	ACOMPAT	0x04			/* used compatibility mode */
-#define	ACORE	0x08			/* dumped core */
-#define	AXSIG	0x10			/* killed by a signal */
-#define ANVER	0x20			/* new record version */
-
-		uint8_t  ac_flag;	/* accounting flags */
-	} ac_trailer;
-
-#define ac_flagx ac_trailer.ac_flag
-};
-
-

If a terminated process was created by an - execve(2), the name of the executed file (at most ten - characters of it) is saved in the field ac_comm and - its status is saved by setting one of more of the following flags in - ac_flag: AFORK, - ACOMPAT, ACORE and - ASIG. ASU is no longer - supported. ANVER is always set in the above - structure.

-
-
-

-

lastcomm(1), acct(2), - execve(2), sa(8)

-
-
-

-

A acct file format appeared in - Version 7 AT&T UNIX. The current record - format was introduced on May 2007. It is backwards compatible with the - previous format, which is still documented in - <sys/acct.h> and supported - by lastcomm(1) and sa(8).

-
-
- - - - - -
February 13, 2017FreeBSD 15.0
diff --git a/static/freebsd/man5/ar.5 3.html b/static/freebsd/man5/ar.5 3.html deleted file mode 100644 index 2f734903..00000000 --- a/static/freebsd/man5/ar.5 3.html +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - -
AR(5)File Formats ManualAR(5)
-
-
-

-

ar — archive file - format for ar(1) and - ranlib(1)

-
-
-

-

#include - <ar.h>

-
-
-

-

ar(1) archives are created and managed by the - ar(1) and ranlib(1) utilities. These - archives are typically used during program development to hold libraries of - program objects. An ar(1) archive is contained in a single - operating system file.

-

This manual page documents two variants of the - ar(1) archive format: the BSD archive format, and the - SVR4/GNU archive format.

-

In both variants the archive file starts with an identifying byte - sequence of the seven ASCII characters - ‘!<arch>’ followed by a ASCII - linefeed character (see the constant “ARMAG” in the header - file <ar.h>).

-

Archive members follow the initial identifying byte sequence. Each - archive member is prefixed by a fixed size header describing the file - attributes associated with the member.

-
-

-

An archive header describes the file attributes for the archive - member that follows it. The ar format only supports - a limited number of attributes: the file name, the file creation time stamp, - the uid and gid of the creator, the file mode and the file size.

-

Archive headers are placed at an even byte offset in the archive - file. If the data for an archive member ends at an odd byte offset, then a - padding byte with value 0x0A is used to position the next archive header on - an even byte offset.

-

An archive header comprises the following fixed sized fields:

-
-
ar_name
-
(16 bytes) The file name of the archive member. The format of this field - varies between the BSD and SVR4/GNU formats and is described in more - detail in the section - Representing File Names - below.
-
ar_date
-
(12 bytes) The file modification time for the member in seconds since the - epoch, encoded as a decimal number.
-
ar_uid
-
(6 bytes) The uid associated with the archive member, encoded as a decimal - number.
-
ar_gid
-
(6 bytes) The gid associated with the archive member, encoded as a decimal - number.
-
ar_mode
-
(8 bytes) The file mode for the archive member, encoded as an octal - number.
-
ar_size
-
(10 bytes) In the SVR4/GNU archive format this field holds the size in - bytes of the archive member, encoded as a decimal number. In the BSD - archive format, for short file names, this field holds the size in bytes - of the archive member, encoded as a decimal number. For long file names - (see Representing File - Names below), the field contains the combined size of the archive - member and its file name, encoded as a decimal number.
-
ar_fmag
-
(2 bytes) This field holds 2 bytes with values 0x96 and 0x0A respectively, - marking the end of the header.
-
-

Unused bytes in the fields of an archive header are set to the - value 0x20.

-
-
-

-

The BSD and SVR4/GNU variants use different schemes for encoding - file names for members.

-
-
BSD
-
File names that are up to 16 bytes long and which do not contain embedded - spaces are stored directly in the ar_name field of - the archive header. File names that are either longer than 16 bytes or - which contain embedded spaces are stored immediately after the archive - header and the ar_name field of the archive header - is set to the string “#1/” followed by a decimal - representation of the number of bytes needed for the file name. In - addition, the ar_size field of the archive header is - set to the decimal representation of the combined sizes of the archive - member and the file name. The file contents of the member follows the file - name without further padding. -

As an example, if the file name for a member was “A - B” and its contents was the string “C D”, then the - ar_name field of the header would contain - “#1/3”, the - ar_size field of the header would contain - “6”, and the bytes immediately - following the header would be 0x41, 0x20, 0x42, 0x43, 0x20 and 0x44 - (ASCII “A BC D”).

-
-
SVR4/GNU
-
File names that are up to 15 characters long are stored directly in the - ar_name field of the header, terminated by a - “/” character. -

If the file name is larger than would fit in space for the - ar_name field, then the actual file name is kept - in the archive string table (see - Archive String Tables - below), and the decimal offset of the file name in the string table is - stored in the ar_name field, prefixed by a - “/” character.

-

As an example, if the real file name has been stored at offset - 768 in the archive string table, the ar_name field - of the header will contain the string “/768”.

-
-
-
-
-

-

The following archive members are special.

-
-
“/”
-
In the SVR4/GNU variant of the archive format, the archive member with - name “/” denotes an archive symbol - table. If present, this member will be the very first member in the - archive.
-
“//”
-
In the SVR4/GNU variant of the archive format, the archive member with - name “//” denotes the archive string - table. This special member is used to hold filenames that do not fit in - the file name field of the header (see - Representing File Names - above). If present, this member immediately follows the archive symbol - table if an archive symbol table is present, or is the first member - otherwise.
-
“__.SYMDEF”
-
This special member contains the archive symbol table in the BSD variant - of the archive format. If present, this member will be the very first - member in the archive.
-
-
-
-

-

An archive string table is used in the SVR4/GNU archive format to - hold file names that are too large to fit into the constraints of the - ar_name field of the archive header. An archive string - table contains a sequence of file names. Each file name in the archive - string table is terminated by the byte sequence 0x2F, 0x0A (the ASCII string - “/\n”). No padding is used to separate adjacent file - names.

-
-
-

-

Archive symbol tables are used to speed up link editing by - providing a mapping between the program symbols defined in the archive and - the corresponding archive members. Archive symbol tables are managed by the - ranlib(1) utility.

-

The format of archive symbol tables is as follows:

-
-
BSD
-
In the BSD archive format, the archive symbol table comprises of two - parts: a part containing an array of struct ranlib - descriptors, followed by a part containing a symbol string table. The - sizes and layout of the structures that make up a BSD format archive - symbol table are machine dependent. -

The part containing struct ranlib - descriptors begins with a field containing the size in bytes of the - array of struct ranlib descriptors encoded as a C - long value.

-

The array of struct ranlib descriptors - follows the size field. Each struct ranlib - descriptor describes one symbol.

-

A struct ranlib descriptor comprises two - fields:

-
-
ran_strx
-
(C long) This field contains the zero-based - offset of the symbol name in the symbol string table.
-
ran_off
-
(C long) This field is the file offset to the - archive header for the archive member defining the symbol.
-
-

The part containing the symbol string table begins with a - field containing the size in bytes of the string table, encoded as a C - long value. This string table follows the size - field, and contains NUL-terminated strings for the symbols in the symbol - table.

-
-
SVR4/GNU
-
In the SVR4/GNU archive format, the archive symbol table starts with a - 4-byte binary value containing the number of entries contained in the - archive symbol table. This count of entries is stored most significant - byte first. -

Next, there are count 4-byte numbers, - each stored most significant byte first. Each number is a binary offset - to the archive header for the member in the archive file for the - corresponding symbol table entry.

-

After the binary offset values, there are - count NUL-terminated strings in sequence, holding - the symbol names for the corresponding symbol table entries.

-
-
-
-
-
-

-

The ar(1) archive format is not currently - specified by a standard.

-

This manual page documents the ar(1) archive - formats used by the 4.4BSD and - UNIX SVR4 operating system releases.

-
-
-

-

ar(1), ld(1), - ranlib(1), elf(3), - elf_getarsym(3), elf_rand(3)

-
-
- - - - - -
November 28, 2010FreeBSD 15.0
diff --git a/static/freebsd/man5/bluetooth.device.conf.5 3.html b/static/freebsd/man5/bluetooth.device.conf.5 3.html deleted file mode 100644 index d0e3544c..00000000 --- a/static/freebsd/man5/bluetooth.device.conf.5 3.html +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - -
BLUETOOTH.DEVICE.CONF(5)File Formats ManualBLUETOOTH.DEVICE.CONF(5)
-
-
-

-

bluetooth.device.conf — - Bluetooth device configuration file

-
-
-

-

Bluetooth device configuration framework provides ability to - adjust certain Bluetooth device parameters on per-device basis.

-

Bluetooth device configuration files are plain text files that - should conform to basic sh(1) syntax. Even though - Bluetooth device are not exactly shell scripts, they are parsed and passed - through shell eval command. This makes it possible - to use various shell tricks in the Bluetooth device configuration files.

-

The /etc/rc.d/bluetooth script is used to - start and stop Bluetooth devices. This script is not executed by default - when system boots. It is called by devd(8) in response to - Bluetooth device arrival and departure events. It is possible to execute - this script by hand if required. The script accepts Bluetooth device driver - name as an extra parameter.

-

The system wide Bluetooth device configuration file is called - /etc/defaults/bluetooth.device.conf. Configuration - parameters set in the system wide Bluetooth device configuration file apply - to every Bluetooth device connected to the system.

-

Configuration parameters overrides for the specific Bluetooth - device should be placed in the - /etc/bluetooth/DEVICE_DRIVER_NAME.conf - file. Where DEVICE_DRIVER_NAME is the device driver - name of the Bluetooth device.

-

The following list provides a name and short description for each - variable that can be set in a Bluetooth device configuration file.

-
-
authentication_enable
-
(bool) The - authentication_enable parameter controls if the - device requires to authenticate the remote device at connection setup. If - set to “YES”, the device will try to - authenticate the other device at connection setup. Bluetooth - authentication requests are handled by hcsecd(8) - daemon.
-
class
-
(str) The class parameter is - used to indicate the capabilities of the device to other devices. For more - details see “Assigned Numbers - Bluetooth Baseband” - document.
-
connectable
-
(bool) The connectable - parameter controls whether or not the device should periodically scan for - page attempts from other devices. If set to - “YES”, the device will periodically - scan for page attempts from other devices.
-
discoverable
-
(bool) The discoverable - parameter controls whether or not the device should periodically scan for - inquiry requests from other devices. If set to - “YES”, the device will periodically - scan for inquiry requests from other devices.
-
encryption_mode
-
(str) The encryption_mode - parameter controls if the device requires encryption to the remote device - at connection setup. At connection setup, only the devices with the - authentication_enable parameter enabled and - encryption_mode parameter enabled will try to - encrypt the connection to the other device. Possible values are - “NONE” encryption disabled, - “P2P” encryption for only - point-to-point packets, or “ALL” - encryption for both point-to-point and broadcast packets.
-
hci_debug_level
-
(int) HCI node debug level. Higher values mean more - verbose output.
-
l2cap_debug_level
-
(int) L2CAP node debug level. Higher values mean - more verbose output.
-
local_name
-
(str) The local_name parameter - provides the ability to modify the user friendly name for the device.
-
role_switch
-
(bool) The role_switch - parameter controls whether the local device should perform role switch. By - default, if role switch is supported, the local device will try to perform - role switch and become Master on incoming connection. Some devices do not - support role switch and thus incoming connections from such devices will - fail. If role switch is disabled then accepting - device will remain Slave.
-
-
-
-

-
-
/etc/defaults/bluetooth.device.conf
-
 
-
/etc/rc.d/bluetooth
-
 
-
-
-
-

-

The /etc/bluetooth/ubt0.conf file should - be used to specify configuration parameters overrides for the first USB - Bluetooth device (device driver name is ubt0).

-

The /etc/bluetooth/ubt1.conf file should - be used to specify configuration parameters overrides for the second USB - Bluetooth device.

-
-
-

-

ng_hci(4), ng_l2cap(4), - ng_ubt(4), devd(8), - hccontrol(8), hcsecd(8), - l2control(8)

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
- - - - - -
September 29, 2021FreeBSD 15.0
diff --git a/static/freebsd/man5/bluetooth.hosts.5 4.html b/static/freebsd/man5/bluetooth.hosts.5 4.html deleted file mode 100644 index 3e008a3a..00000000 --- a/static/freebsd/man5/bluetooth.hosts.5 4.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
BLUETOOTH.HOSTS(5)File Formats ManualBLUETOOTH.HOSTS(5)
-
-
-

-

bluetooth.hosts — - Bluetooth host name database

-
-
-

-

The /etc/bluetooth/hosts file contains - information regarding the known Bluetooth hosts. For each Bluetooth host a - single line should be present with the following information:

-
-
Bluetooth address
-official host name
-aliases
-
-

Items are separated by any number of blanks and/or tab characters. - A ‘#’ indicates the beginning of a - comment; characters up to the end of the line are not interpreted by - routines which search the file.

-

Bluetooth addresses are specified as six hex bytes separated by - columns (BD_ADDR). Host names may contain any printable character other than - a field delimiter, newline, or comment character.

-
-
-

-
-
/etc/bluetooth/hosts
-
 
-
-
-
-

-

bluetooth(3)

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
- - - - - -
May 8, 2003FreeBSD 15.0
diff --git a/static/freebsd/man5/bluetooth.protocols.5 4.html b/static/freebsd/man5/bluetooth.protocols.5 4.html deleted file mode 100644 index e4c9cc72..00000000 --- a/static/freebsd/man5/bluetooth.protocols.5 4.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - -
BLUETOOTH.PROTOCOLS(5)File Formats ManualBLUETOOTH.PROTOCOLS(5)
-
-
-

-

bluetooth.protocols — - Bluetooth Protocol Service Multiplexor database

-
-
-

-

The /etc/bluetooth/protocols file contains - information regarding the known Bluetooth Protocol Service Multiplexor - values. For each Bluetooth Protocol Service Multiplexor a single line should - be present with the following information:

-
-
official Protocol Service Multiplexor name
-official Protocol Service Multiplexor value
-aliases
-
-

Items are separated by any number of blanks and/or tab characters. - A ‘#’ indicates the beginning of a - comment; characters up to the end of the line are not interpreted by - routines which search the file.

-

Bluetooth Protocol Service Multiplexor names may contain any - printable character other than a field delimiter, newline, or comment - character.

-
-
-

-
-
/etc/bluetooth/protocols
-
 
-
-
-
-

-

bluetooth(3)

-
-
-

-

Maksim Yevmenkin - <m_evmenkin@yahoo.com>

-
-
- - - - - -
May 8, 2003FreeBSD 15.0
diff --git a/static/freebsd/man5/boot.config.5 3.html b/static/freebsd/man5/boot.config.5 3.html deleted file mode 100644 index 4a9ec4ec..00000000 --- a/static/freebsd/man5/boot.config.5 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
BOOT.CONFIG(5)File Formats ManualBOOT.CONFIG(5)
-
-
-

-

boot.config — - Configuration file for the legacy boot blocks

-
-
-

-

The boot.config file contains options for - the FreeBSD boot block code.

-

When the first- and second-stage FreeBSD - boot loaders run, they search the “a” - slice of the boot partition for a boot.config file - (as a result, slices which are missing an - “a” partition require user - intervention during the boot process). If the - boot.config file is found, its contents are used as - the default configuration options for the boot block code and are echoed to - the system console.

-

A valid format of this file is to put BIOS drive number, a - controller type, a unit number, a partition, a kernel file name, and any - other valid boot(8) option on a single line, as it is done - at the “boot:” prompt.

-

The options related to the boot image selection described below - and all the other options available for boot.config - are documented in detail in the boot(8) manual page.

-
-
-

-
-
/boot.config
-
parameters for the boot blocks (optional)
-
/boot/config
-
alternate location for boot config information
-
-
-
-

-

The command:

-
-
# echo "-P" > /boot.config
-
-

will activate the serial console of - FreeBSD if no keyboard is present, otherwise video - console will be used.

-

The command:

-
-
# echo "1:ad(1,a)/boot/loader" > /boot.config
-
-

will instruct the second stage of boot(8) on the - first disk to boot with the third boot(8) stage from the - second disk.

-

The command:

-
-
# echo "1:ad(1,a)/boot/loader -P" > /boot.config
-
-

will do both of the above.

-
-
-

-

boot(8), loader(8)

-
-
-

-

This manual page was written by Daniel - Gerzo - <danger@FreeBSD.org>.

-
-
- - - - - -
November 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man5/core.5 3.html b/static/freebsd/man5/core.5 3.html deleted file mode 100644 index 167df948..00000000 --- a/static/freebsd/man5/core.5 3.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - -
CORE(5)File Formats ManualCORE(5)
-
-
-

-

core — memory - image file format

-
-
-

-

#include - <sys/param.h>

-
-
-

-

A small number of signals which cause abnormal termination of a - process also cause a record of the process's in-core state to be written to - disk for later examination by one of the available debuggers. (See - sigaction(2).) This memory image is written to a file - named by default programname.core in the working - directory; provided the terminated process had write permission in the - directory, and provided the abnormality did not cause a system crash. (In - this event, the decision to save the core file is arbitrary, see - savecore(8).)

-

The name of the file is controlled via the - sysctl(8) variable kern.corefile. - The contents of this variable describes a filename to store the core image - to. This filename can be absolute, or relative (which will resolve to the - current working directory of the program generating it).

-

The following format specifiers may be used in the - kern.corefile sysctl to insert additional information - into the resulting core filename:

-
-
-
-
Machine hostname.
-
-
An index starting at zero until the sysctl - - is reached. This can be useful for limiting the number of corefiles - generated by a particular process.
-
-
process name.
-
-
processes PID.
-
-
signal during core.
-
-
process UID.
-
-
-

The name defaults to - , yielding - the traditional FreeBSD behaviour.

-

The maximum size of a core file is limited by the - RLIMIT_CORE setrlimit(2) limit. - Files which would be larger than the limit are not created.

-

With a large limit, a process that had mapped a very large, and - perhaps sparsely populated, virtual memory region, could take a very long - time to create core dumps. The system ignores all signals sent to a process - writing a core file, except SIGKILL which terminates - the writing and causes immediate exit of the process. The behavior of - SIGKILL can be disabled by setting tunable - sysctl(8) variable - kern.core_dump_can_intr to zero.

-

By default, a process that changes user or group credentials - whether real or effective will not create a corefile. This behaviour can be - changed to generate a core dump by setting the sysctl(8) - variable kern.sugid_coredump to 1.

-

Corefiles can be compressed by the kernel if one of the following - items are included in the kernel configuration file:

-
-
-
options
-
GZIO
-
options
-
ZSTDIO
-
-
-

The following sysctl control core file compression:

-
-
-
-
Enable compression of user cores. A value of 1 configures - gzip(1) compression, and a value of 2 configures - zstd(1) compression. Compressed core files will have a - suffix of ‘.gz’ or - ‘.zst’ appended to their filenames - depending on the selected format.
-
-
Compression level. Defaults to 6.
-
-
-
-
-

-

Corefiles are written with open file descriptor information as an - ELF note. By default, file paths are packed to only use as much space as - needed. However, file paths can change at any time, including during core - dump, and this can result in truncated file descriptor data.

-

All file descriptor information can be preserved by disabling - packing. This potentially wastes up to PATH_MAX bytes per open fd. Packing - is disabled with

-
sysctl - kern.coredump_pack_fileinfo=0
-. -

Similarly, corefiles are written with vmmap information as an ELF - note, which contains file paths. By default, they are packed to only use as - much space as needed. By the same mechanism as for the open files note, - these paths can also change at any time and result in a truncated note.

-

All vmmap information can be preserved by disabling packing. Like - the file information, this potentially wastes up to PATH_MAX bytes per - mapped object. Packing is disabled with

-
sysctl - kern.coredump_pack_vmmapinfo=0
-. -
-
-

-

In order to store all core images in per-user private areas under - /var/coredumps (assuming the appropriate - subdirectories exist and are writable by users), the following - sysctl(8) command can be used:

-

-
sysctl - kern.corefile=/var/coredumps/%U/%N.core
-
-
-

-

gdb(1) - (ports/devel/gdb), gzip(1), - kgdb(1) (ports/devel/gdb), - setrlimit(2), sigaction(2), - sysctl(8)

-
-
-

-

A core file format appeared in - Version 1 AT&T UNIX.

-
-
- - - - - -
July 17, 2025FreeBSD 15.0
diff --git a/static/freebsd/man5/devfs.conf.5 3.html b/static/freebsd/man5/devfs.conf.5 3.html deleted file mode 100644 index d0871cd2..00000000 --- a/static/freebsd/man5/devfs.conf.5 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
DEVFS.CONF(5)File Formats ManualDEVFS.CONF(5)
-
-
-

-

devfs.conf — - boot-time devfs configuration information

-
-
-

-

The devfs.conf file provides an easy way - to set ownership and permissions, or create links for devices available at - boot.

-

It does not work for devices plugged in and out after the system - is up and running, e.g. USB devices. See devfs.rules(5) - for setting ownership and permissions for all device nodes, and - devd.conf(5) for actions to be taken when devices are - attached or detached.

-

Lines starting with a hash sign - (‘#’) and empty lines are ignored. The - lines that specify devfs.conf rules consist of three - parameters separated by whitespace:

-
-
action
-
The action to take for the device. The action names are only significant - to the first unique character.
-
devname
-
The name of the device created by devfs(4).
-
arg
-
The argument of the action.
-
-

The actions currently supported are:

-
- -
This action creates a symbolic link named arg that - points to devname, the name of the device created by - devfs(4).
-
-
This action changes the ownership of devname. The - arg parameter must be in the form of an - owner:group pair, in the same - format used by chown(8).
-
-
This action changes the permissions of devname. The - arg parameter must be a mode - as explained in chmod(1).
-
-
-
-

-
-
/etc/devfs.conf
-
 
-
/usr/share/examples/etc/devfs.conf
-
 
-
-
-
-

-

To create a /dev/cdrom link that points to - the first CD-ROM, the following may be added to - devfs.conf:

-
-
link	cd0	cdrom
-
-

To set the owner of a device, the own - action may be specified:

-
-
own	cd0	root:cdrom
-
-

To set the permissions of a device, a perm - action should be used:

-
-
perm	cd0	0660
-
-
-
-

-

chmod(1), devfs(4), - devd.conf(5), devfs.rules(5), - chown(8)

-
-
-

-

This manual page was written by Roland - Smith - <rsmith@xs4all.nl>.

-
-
- - - - - -
May 25, 2019FreeBSD 15.0
diff --git a/static/freebsd/man5/devfs.rules.5 3.html b/static/freebsd/man5/devfs.rules.5 3.html deleted file mode 100644 index e494c989..00000000 --- a/static/freebsd/man5/devfs.rules.5 3.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - -
DEVFS.RULES(5)File Formats ManualDEVFS.RULES(5)
-
-
-

-

devfs.rules — - devfs configuration information

-
-
-

-

The devfs.rules file provides an easy way - to create and apply devfs(8) rules, even for devices that - are not available at boot.

-

For devices available at boot, see - devfs.conf(5).

-

The format of this file is simple. Empty lines and lines beginning - with a hash sign (‘#’) are ignored. A - line between brackets denotes the start of a ruleset. In the brackets should - be the name of the ruleset and its number, separated by an equal sign.

-

Other lines are rule specifications as documented in - devfs(8), in the section - Rule Specification. These lines - are prepended with “rule” and are - passed to devfs(8) by the startup scripts of the system. - It is important to put path elements that contain glob(3) - special characters between quotes.

-

Rulesets should have a unique name and number.

-

All rules that follow a ruleset declaration belong to that - ruleset, until a new ruleset is started.

-

One custom ruleset has to be enabled in - /etc/rc.conf, otherwise it will not be applied to - the /dev file system by the default system startup - process. For example, to enable a - “localrules” ruleset for the - /dev file system, you would have to use something - like this in your rc.conf file:

-
-
devfs_system_ruleset="localrules"
-
-

The rules are loaded at boot via the devfs service. To load - modified rules after the system has booted, run the command:

-
-
service devfs restart
-
-
-
-

-
-
/etc/defaults/devfs.rules
-
Default devfs.rules configuration file.
-
/etc/devfs.rules
-
Local devfs.rules configuration file. Rulesets in - here override those in /etc/defaults/devfs.rules - with the same ruleset number, otherwise the two files are effectively - merged.
-
-
-
-

-

To make all the partitions of da(4) devices - readable and writable by their owner and the - “usb” group, the following rule may be - used:

-

-
[localrules=10]
-
add path 'da*s*' mode 0660 group - usb
-

The first line declares and starts a new ruleset, with the name - localrules and the number 10.

-

To give usbconfig(8) and - libusb(3) enabled applications permission to all usb - devices for their owner and the “usb” - group, a similar rule may be used:

-

-
add path 'usb/*' mode 0660 group - usb
-
-
-

-

glob(3), devfs(4), - devfs.conf(5), devfs(8), - service(8)

-
-
-

-

This manual page was written by Roland - Smith - <rsmith@xs4all.nl>.

-
-
- - - - - -
December 1, 2020FreeBSD 15.0
diff --git a/static/freebsd/man5/device.hints.5 3.html b/static/freebsd/man5/device.hints.5 3.html deleted file mode 100644 index 7f5bf403..00000000 --- a/static/freebsd/man5/device.hints.5 3.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - -
DEVICE.HINTS(5)File Formats ManualDEVICE.HINTS(5)
-
-
-

-

device.hints — - device resource hints

-
-
-

-

The device.hints file is read in by the - boot loader(8) when the system is about to start, and its - contents are passed to the kernel. It contains various variables to control - the boot behavior of the kernel. These variables are typically - “device hints”, but can include any kernel tunable values.

-

The file contains one variable per line. Lines starting with the - ‘#’ character are comments and are - ignored by the boot loader.

-

After the file is read by the boot loader, you may examine the - variables with the show command, and may add a new - variable, modify an existing one, or delete a variable with the - set and unset commands of - the boot loader (see loader(8)).

-

After the system has started, you can dump these variables with - the kenv(1) command.

-
-
-

-

Device hint variables are used by device drivers to set up the - device. They are most often used by ISA device drivers to specify where the - driver will probe for the relevant devices, and what resources it will - attempt to use.

-

A device hint line looks like:

-

-
hint.driver.unit.keyword="value"
-

where driver is the name of a device driver, - unit is the unit number, and - keyword is the keyword of the hint. The keyword may - be:

-

-
-
-
-
specifies a bus to which the device is attached.
-
-
specifies the start address of I/O ports to be used by the device.
-
-
specifies the number of ports used by the device.
-
-
is the interrupt line number to be used.
-
-
is the DMA channel number.
-
-
specifies the physical memory address used by the device.
-
-
specifies the physical memory size used by the device.
-
-
sets various flag bits for the device.
-
-
can be set to "1" to disable the device.
-
-
-

A device driver may require one or more hint lines with these - keywords, and may accept other keywords not listed here, through - resource_int_value(9). Consult individual device drivers' - manual pages for available keywords and their possible values.

-
-
-

-
-
/boot/device.hints
-
Device resource hints file.
-
/sys/ARCH/conf/GENERIC.hints
-
Sample resource hints for the GENERIC kernel.
-
/sys/ARCH/conf/NOTES
-
Notes on the kernel configuration file and device resource hints.
-
-
-
-

-

The following example sets up resources for the - uart(4) driver on the ISA bus:

-
-
hint.uart.0.at="isa"
-hint.uart.0.port="0x3F8"
-hint.uart.0.flags="0x10"
-hint.uart.0.irq="4"
-
-

The following example disables the ACPI driver:

-
-
hint.acpi.0.disabled="1"
-
-

Setting a tunable variable:

-
-
vm.pmap.pg_ps_enabled=1
-
-
-
-

-

kenv(1), loader.conf(5), - loader(8), resource_int_value(9)

-
-
-

-

The device.hints file first appeared in - FreeBSD 5.0.

-
-
- - - - - -
November 19, 2019FreeBSD 15.0
diff --git a/static/freebsd/man5/dir.5 3.html b/static/freebsd/man5/dir.5 3.html deleted file mode 100644 index 26114da9..00000000 --- a/static/freebsd/man5/dir.5 3.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - -
DIR(5)File Formats ManualDIR(5)
-
-
-

-

dir, dirent - — directory file format

-
-
-

-

#include - <dirent.h>

-
-
-

-

Directories provide a convenient hierarchical method of grouping - files while obscuring the underlying details of the storage medium. A - directory file is differentiated from a plain file by a flag in its - inode(5) entry. It consists of records (directory entries) - each of which contains information about a file and a pointer to the file - itself. Directory entries may contain other directories as well as plain - files; such nested directories are referred to as subdirectories. A - hierarchy of directories and files is formed in this manner and is called a - file system (or referred to as a file system tree).

-

Each directory file contains two special directory entries; one is - a pointer to the directory itself called dot - ‘.’ and the other a pointer to its - parent directory called dot-dot ‘..’. - Dot and dot-dot are valid pathnames, however, the system root directory - ‘/’, has no parent and dot-dot points - to itself like dot.

-

File system nodes are ordinary directory files on which has been - grafted a file system object, such as a physical disk or a partitioned area - of such a disk. (See mount(2) and - mount(8).)

-

The directory entry format is defined in the file - <sys/dirent.h> (which should - not be included directly by applications):

-
-
#ifndef	_SYS_DIRENT_H_
-#define	_SYS_DIRENT_H_
-
-#include <machine/ansi.h>
-
-/*
- * The dirent structure defines the format of directory entries returned by
- * the getdirentries(2) system call.
- *
- * A directory entry has a struct dirent at the front of it, containing its
- * inode number, the length of the entry, and the length of the name
- * contained in the entry.  These are followed by the name padded to a 8
- * byte boundary with null bytes.  All names are guaranteed null terminated.
- * The maximum length of a name in a directory is MAXNAMLEN.
- * Explicit pad is added between the last member of the header and
- * d_name, to avoid having the ABI padding in the end of dirent on
- * LP64 arches.  There is code depending on d_name being last.  Also,
- * keeping this pad for ILP32 architectures simplifies compat32 layer.
- */
-
-struct dirent {
-	ino_t      d_fileno;		/* file number of entry */
-	off_t      d_off;		/* directory offset of the next entry */
-	__uint16_t d_reclen;		/* length of this record */
-	__uint8_t  d_type;		/* file type, see below */
-	__uint8_t  d_namlen;		/* length of string in d_name */
-	__uint32_t d_pad0;
-#if __BSD_VISIBLE
-#define	MAXNAMLEN	255
-	char	d_name[MAXNAMLEN + 1];	/* name must be no longer than this */
-#else
-	char	d_name[255 + 1];	/* name must be no longer than this */
-#endif
-};
-
-/*
- * File types
- */
-#define	DT_UNKNOWN	 0
-#define	DT_FIFO		 1
-#define	DT_CHR		 2
-#define	DT_DIR		 4
-#define	DT_BLK		 6
-#define	DT_REG		 8
-#define	DT_LNK		10
-#define	DT_SOCK		12
-#define	DT_WHT		14
-
-/*
- * Convert between stat structure types and directory types.
- */
-#define	IFTODT(mode)	(((mode) & 0170000) >> 12)
-#define	DTTOIF(dirtype)	((dirtype) << 12)
-
-/*
- * The _GENERIC_DIRSIZ macro gives the minimum record length which will hold
- * the directory entry.  This returns the amount of space in struct direct
- * without the d_name field, plus enough space for the name with a terminating
- * null byte (dp->d_namlen+1), rounded up to a 8 byte boundary.
- *
- * XXX although this macro is in the implementation namespace, it requires
- * a manifest constant that is not.
- */
-#define	_GENERIC_DIRLEN(namlen)						((__offsetof(struct dirent, d_name) + (namlen) + 1 + 7) & ~7)
-#define	_GENERIC_DIRSIZ(dp)	_GENERIC_DIRLEN((dp)->d_namlen)
-#endif /* __BSD_VISIBLE */
-
-#ifdef _KERNEL
-#define	GENERIC_DIRSIZ(dp)	_GENERIC_DIRSIZ(dp)
-#endif
-
-#endif /* !_SYS_DIRENT_H_ */
-
-
-
-

-

fs(5), inode(5)

-
-
-

-

A dir file format appeared in - Version 7 AT&T UNIX.

-
-
-

-

The usage of the member d_type of struct dirent is unportable as - it is FreeBSD-specific. It also may fail on certain - file systems, for example the cd9660 file system.

-
-
- - - - - -
November 14, 2018FreeBSD 15.0
diff --git a/static/freebsd/man5/disktab.5 3.html b/static/freebsd/man5/disktab.5 3.html deleted file mode 100644 index 7370497d..00000000 --- a/static/freebsd/man5/disktab.5 3.html +++ /dev/null @@ -1,333 +0,0 @@ - - - - - - -
DISKTAB(5)File Formats ManualDISKTAB(5)
-
-
-

-

disktab — disk - description file

-
-
-

-

#include - <disklabel.h>

-
-
-

-

Disktab is a simple database which - describes disk geometries and disk partition characteristics. It is used to - initialize the disk label on the disk. The format is patterned after the - termcap(5) terminal data base. Entries in - disktab consist of a number of `:'-separated fields. - The first field for each entry gives the names by which a disk's entry may - be selected, separated by `|' characters. The last name given should be a - long name fully identifying the disk.

-

The optional fields for each entry are:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeDescription
tystrType of disk (e.g. removable, winchester)
dtstrType of controller (e.g. SMD, ESDI, floppy)
nsnumNumber of sectors per track
ntnumNumber of tracks per cylinder
ncnumTotal number of cylinders on the disk
scnumNumber of sectors per cylinder, ns*nt default
sunumNumber of sectors per unit, sc*nc default
senumSector size in bytes, DEV_BSIZE default
sfboolController supports bad144-style bad sector forwarding
rmnumRotation speed, rpm, 3600 default
sknumSector skew per track, default 0
csnumSector skew per cylinder, default 0
hsnumHeadswitch time, usec, default 0
tsnumOne-cylinder seek time, usec, default 0
ilnumSector interleave (n:1), 1 default
d[0-4]numDrive-type-dependent parameters
bsnumBoot block size, default BBSIZE
sbnumSuperblock size, default 0
banumBlock size for partition `a' (bytes)
bdnumBlock size for partition `d' (bytes)
benumBlock size for partition `e' (bytes)
bfnumBlock size for partition `f' (bytes)
bgnumBlock size for partition `g' (bytes)
bhnumBlock size for partition `h' (bytes)
fanumFragment size for partition `a' (bytes)
fdnumFragment size for partition `d' (bytes)
fenumFragment size for partition `e' (bytes)
ffnumFragment size for partition `f' (bytes)
fgnumFragment size for partition `g' (bytes)
fhnumFragment size for partition `h' (bytes)
oanumOffset of partition `a' in sectors
obnumOffset of partition `b' in sectors
ocnumOffset of partition `c' in sectors
odnumOffset of partition `d' in sectors
oenumOffset of partition `e' in sectors
ofnumOffset of partition `f' in sectors
ognumOffset of partition `g' in sectors
ohnumOffset of partition `h' in sectors
panumSize of partition `a' in sectors
pbnumSize of partition `b' in sectors
pcnumSize of partition `c' in sectors
pdnumSize of partition `d' in sectors
penumSize of partition `e' in sectors
pfnumSize of partition `f' in sectors
pgnumSize of partition `g' in sectors
phnumSize of partition `h' in sectors
tastrPartition type of partition `a' (4.2BSD file - system, swap, etc)
tbstrPartition type of partition `b'
tcstrPartition type of partition `c'
tdstrPartition type of partition `d'
testrPartition type of partition `e'
tfstrPartition type of partition `f'
tgstrPartition type of partition `g'
thstrPartition type of partition `h'
-
-
-

-
-
/etc/disktab
-
 
-
-
-
-

-

getdiskbyname(3), bsdlabel(8), - newfs(8)

-
-
-

-

The disktab description file appeared in - 4.2BSD.

-
-
- - - - - -
October 14, 2006FreeBSD 15.0
diff --git a/static/freebsd/man5/elf.5 3.html b/static/freebsd/man5/elf.5 3.html deleted file mode 100644 index 195189f0..00000000 --- a/static/freebsd/man5/elf.5 3.html +++ /dev/null @@ -1,1172 +0,0 @@ - - - - - - -
ELF(5)File Formats ManualELF(5)
-
-
-

-

elf — format of - ELF executable binary files

-
-
-

-

#include - <elf.h>

-
-
-

-

The header file - <elf.h> defines the format - of ELF executable binary files. Amongst these files are normal executable - files, relocatable object files, core files and shared libraries.

-

An executable file using the ELF file format consists of an ELF - header, followed by a program header table or a section header table, or - both. The ELF header is always at offset zero of the file. The program - header table and the section header table's offset in the file are defined - in the ELF header. The two tables describe the rest of the particularities - of the file.

-

Applications which wish to process ELF binary files for their - native architecture only should include - <elf.h> in their source - code. These applications should need to refer to all the types and - structures by their generic names “Elf_xxx” and to the macros - by “ELF_xxx”. Applications written this way can be compiled on - any architecture, regardless whether the host is 32-bit or 64-bit.

-

Should an application need to process ELF files of an unknown - architecture then the application needs to include both - <sys/elf32.h> and - <sys/elf64.h> instead of - <elf.h>. Furthermore, all - types and structures need to be identified by either - “Elf32_xxx” or “Elf64_xxx”. The macros need to - be identified by “ELF32_xxx” or “ELF64_xxx”.

-

Whatever the system's architecture is, it will always include - <sys/elf_common.h> as well - as <sys/elf_generic.h>.

-

These header files describe the above mentioned headers as C - structures and also include structures for dynamic sections, relocation - sections and symbol tables.

-

The following types are being used for 32-bit architectures:

-
-
Elf32_Addr	Unsigned 32-bit program address
-Elf32_Half	Unsigned 16-bit field
-Elf32_Lword	Unsigned 64-bit field
-Elf32_Off	Unsigned 32-bit file offset
-Elf32_Sword	Signed 32-bit field or integer
-Elf32_Word	Unsigned 32-bit field or integer
-
-

For 64-bit architectures we have the following types:

-
-
Elf64_Addr	Unsigned 64-bit program address
-Elf64_Half	Unsigned 16-bit field
-Elf64_Lword	Unsigned 64-bit field
-Elf64_Off	Unsigned 64-bit file offset
-Elf64_Sword	Signed 32-bit field
-Elf64_Sxword	Signed 64-bit field or integer
-Elf64_Word	Unsigned 32-bit field
-Elf64_Xword	Unsigned 64-bit field or integer
-
-

All data structures that the file format defines follow the - “natural” size and alignment guidelines for the relevant - class. If necessary, data structures contain explicit padding to ensure - 4-byte alignment for 4-byte objects, to force structure sizes to a multiple - of 4, etc.

-

The ELF header is described by the type Elf32_Ehdr or - Elf64_Ehdr:

-
-
typedef struct {
-        unsigned char   e_ident[EI_NIDENT];
-        Elf32_Half      e_type;
-        Elf32_Half      e_machine;
-        Elf32_Word      e_version;
-        Elf32_Addr      e_entry;
-        Elf32_Off       e_phoff;
-        Elf32_Off       e_shoff;
-        Elf32_Word      e_flags;
-        Elf32_Half      e_ehsize;
-        Elf32_Half      e_phentsize;
-        Elf32_Half      e_phnum;
-        Elf32_Half      e_shentsize;
-        Elf32_Half      e_shnum;
-        Elf32_Half      e_shstrndx;
-} Elf32_Ehdr;
-
-
-
typedef struct {
-	unsigned char   e_ident[EI_NIDENT];
-	Elf64_Half      e_type;
-	Elf64_Half      e_machine;
-	Elf64_Word      e_version;
-	Elf64_Addr      e_entry;
-	Elf64_Off       e_phoff;
-	Elf64_Off       e_shoff;
-	Elf64_Word      e_flags;
-	Elf64_Half      e_ehsize;
-	Elf64_Half      e_phentsize;
-	Elf64_Half      e_phnum;
-	Elf64_Half      e_shentsize;
-	Elf64_Half      e_shnum;
-	Elf64_Half      e_shstrndx;
-} Elf64_Ehdr;
-
-

The fields have the following meanings:

-

-
-
-
-
This array of bytes specifies to interpret the file, independent of the - processor or the file's remaining contents. Within this array everything - is named by macros, which start with the prefix - and - may contain values which start with the prefix - . The - following macros are defined: -

-
-
-
The first byte of the magic number. It must be filled with - .
-
-
The second byte of the magic number. It must be filled with - .
-
-
The third byte of the magic number. It must be filled with - .
-
-
The fourth byte of the magic number. It must be filled with - .
-
-
The fifth byte identifies the architecture for this binary: -

-
-
-
This class is invalid.
-
-
This defines the 32-bit architecture. It supports machines with - files and virtual address spaces up to 4 Gigabytes.
-
-
This defines the 64-bit architecture.
-
-
-
-
The sixth byte specifies the data encoding of the processor-specific - data in the file. Currently these encodings are supported: -

-
-
-
Unknown data format.
-
-
Two's complement, little-endian.
-
-
Two's complement, big-endian.
-
-
-
-
The version number of the ELF specification: -

-
-
-
Invalid version.
-
-
Current version.
-
-
-
-
This byte identifies the operating system and ABI to which the object - is targeted. Some fields in other ELF structures have flags and values - that have platform specific meanings; the interpretation of those - fields is determined by the value of this byte. The following values - are currently defined: -

-
-
-
UNIX System V ABI.
-
-
HP-UX operating system ABI.
-
-
NetBSD operating system ABI.
-
-
GNU/Linux operating system ABI.
-
-
GNU/Hurd operating system ABI.
-
-
86Open Common IA32 ABI.
-
-
Solaris operating system ABI.
-
-
Monterey project ABI.
-
-
IRIX operating system ABI.
-
-
FreeBSD operating system ABI.
-
-
TRU64 UNIX operating system ABI.
-
-
ARM architecture ABI.
-
-
Standalone (embedded) ABI.
-
-
-
-
This byte identifies the version of the ABI to which the object is - targeted. This field is used to distinguish among incompatible - versions of an ABI. The interpretation of this version number is - dependent on the ABI identified by the EI_OSABI field. Applications - conforming to this specification use the value 0.
-
-
Start of padding. These bytes are reserved and set to zero. Programs - which read them should ignore them. The value for EI_PAD will change - in the future if currently unused bytes are given meanings.
-
-
Start of architecture identification.
-
-
The size of the e_ident array.
-
-

-
-
-
This member of the structure identifies the object file type: -

-
-
-
An unknown type.
-
-
A relocatable file.
-
-
An executable file.
-
-
A shared object.
-
-
A core file.
-
-

-
-
-
This member specifies the required architecture for an individual file: -

-
-
-
An unknown machine.
-
-
AT&T WE 32100.
-
-
Sun Microsystems SPARC.
-
-
Intel 80386.
-
-
Motorola 68000.
-
-
Motorola 88000.
-
-
Intel 80486.
-
-
Intel 80860.
-
-
MIPS RS3000 (big-endian only).
-
-
MIPS RS4000 (big-endian only).
-
-
SPARC v9 64-bit unofficial.
-
-
HPPA.
-
-
PowerPC.
-
-
Compaq [DEC] Alpha.
-
-

-
-
-
This member identifies the file version: -

-
-
-
Invalid version
-
-
Current version
-
-
-
-
This member gives the virtual address to which the system first transfers - control, thus starting the process. If the file has no associated entry - point, this member holds zero.
-
-
This member holds the program header table's file offset in bytes. If the - file has no program header table, this member holds zero.
-
-
This member holds the section header table's file offset in bytes. If the - file has no section header table this member holds zero.
-
-
This member holds processor-specific flags associated with the file. Flag - names take the form EF_`machine_flag'. Currently no flags have been - defined.
-
-
This member holds the ELF header's size in bytes.
-
-
This member holds the size in bytes of one entry in the file's program - header table; all entries are the same size.
-
-
This member holds the number of entries in the program header table. If - the file is using extended program header numbering, then the - e_phnum member will contain the value - PN_XNUM and the actual number of program header - table entries will be stored in the sh_info member of - the section header at index SHN_UNDEF. The product - of e_phentsize and the number of program header table - entries gives the program header table's size in bytes. If a file has no - program header, e_phnum holds the value zero.
-
-
This member holds a sections header's size in bytes. A section header is - one entry in the section header table; all entries are the same size.
-
-
This member holds the number of entries in the section header table. If - the file is using extended section numbering, then the - e_shnum member will be zero and the actual section - number will be stored in the sh_size member of the - section header at index SHN_UNDEF. If a file has - no section header table, both the e_shnum and the - e_shoff fields of the ELF header will be zero. The - product of e_shentsize and the number of sections in the - file gives the section header table's size in bytes.
-
-
This member holds the section header table index of the entry associated - with the section name string table. If extended section numbering is being - used, this field will hold the value - , - and the actual section header table index will be present in the - sh_link field of the section header entry at index - SHN_UNDEF. If the file has no section name string - table, this member holds the value SHN_UNDEF.
-
-
-

An executable or shared object file's program header - table is an array of structures, each describing a segment or other - information the system needs to prepare the program for execution. An object - file - contains one or more - . - Program headers are meaningful only for executable and shared object files. - A file specifies its own program header size with the ELF header's - e_phentsize and e_phnum members. As with - the Elf executable header, the program header also has different versions - depending on the architecture:

-
-
typedef struct {
-        Elf32_Word      p_type;
-        Elf32_Off       p_offset;
-        Elf32_Addr      p_vaddr;
-        Elf32_Addr      p_paddr;
-        Elf32_Word      p_filesz;
-        Elf32_Word      p_memsz;
-        Elf32_Word      p_flags;
-        Elf32_Word      p_align;
-} Elf32_Phdr;
-
-
-
typedef struct {
-        Elf64_Word      p_type;
-        Elf64_Word      p_flags;
-        Elf64_Off       p_offset;
-        Elf64_Addr      p_vaddr;
-        Elf64_Addr      p_paddr;
-        Elf64_Xword     p_filesz;
-        Elf64_Xword     p_memsz;
-        Elf64_Xword     p_align;
-} Elf64_Phdr;
-
-

The main difference between the 32-bit and the 64-bit program - header lies only in the location of a p_flags member in - the total struct.

-

-
-
-
-
This member of the Phdr struct tells what kind of segment this array - element describes or how to interpret the array element's information. -

-
-
-
The array element is unused and the other members' values are - undefined. This lets the program header have ignored entries.
-
-
The array element specifies a loadable segment, described by - p_filesz and p_memsz. The bytes - from the file are mapped to the beginning of the memory segment. If - the segment's memory size (p_memsz) is larger than - the file size (p_filesz), the “extra” - bytes are defined to hold the value 0 and to follow the segment's - initialized area. The file size may not be larger than the memory - size. Loadable segment entries in the program header table appear in - ascending order, sorted on the p_vaddr member.
-
-
The array element specifies dynamic linking information.
-
-
The array element specifies the location and size of a null-terminated - path name to invoke as an interpreter. This segment type is meaningful - only for executable files (though it may occur for shared objects). - However it may not occur more than once in a file. If it is present it - must precede any loadable segment entry.
-
-
The array element specifies the location and size for auxiliary - information.
-
-
This segment type is reserved but has unspecified semantics. Programs - that contain an array element of this type do not conform to the - ABI.
-
-
The array element, if present, specifies the location and size of the - program header table itself, both in the file and in the memory image - of the program. This segment type may not occur more than once in a - file. Moreover, it may only occur if the program header table is part - of the memory image of the program. If it is present it must precede - any loadable segment entry.
-
-
This value up to and including PT_HIPROC are - reserved for processor-specific semantics.
-
-
This value down to and including PT_LOPROC are - reserved for processor-specific semantics.
-
-

-
-
-
This member holds the offset from the beginning of the file at which the - first byte of the segment resides.
-
-
This member holds the virtual address at which the first byte of the - segment resides in memory.
-
-
On systems for which physical addressing is relevant, this member is - reserved for the segment's physical address. Under - BSD this member is not used and must be zero.
-
-
This member holds the number of bytes in the file image of the segment. It - may be zero.
-
-
This member holds the number of bytes in the memory image of the segment. - It may be zero.
-
-
This member holds flags relevant to the segment: -

-
-
-
An executable segment.
-
-
A writable segment.
-
-
A readable segment.
-
-

A text segment commonly has the flags PF_X - and PF_R. A data segment commonly has - PF_X, PF_W and - PF_R.

-
-
-
This member holds the value to which the segments are aligned in memory - and in the file. Loadable process segments must have congruent values for - p_vaddr and p_offset, modulo the page - size. Values of zero and one mean no alignment is required. Otherwise, - p_align should be a positive, integral power of two, and - p_vaddr should equal p_offset, modulo - p_align.
-
-
-

An file's section header table lets one locate all the file's - sections. The section header table is an array of Elf32_Shdr or Elf64_Shdr - structures. The ELF header's e_shoff member gives the byte - offset from the beginning of the file to the section header table. - e_shnum holds the number of entries the section header - table contains. e_shentsize holds the size in bytes of - each entry.

-

A section header table index is a subscript into this array. Some - section header table indices are reserved. An object file does not have - sections for these special indices:

-

-
-
-
This value marks an undefined, missing, irrelevant, or otherwise - meaningless section reference. For example, a symbol - “defined” relative to section number - SHN_UNDEF is an undefined symbol.
-
-
This value specifies the lower bound of the range of reserved - indices.
-
-
This value up to and including SHN_HIPROC are reserved - for processor-specific semantics.
-
-
This value down to and including SHN_LOPROC are reserved - for processor-specific semantics.
-
-
This value specifies absolute values for the corresponding reference. For - example, symbols defined relative to section number - SHN_ABS have absolute values and are not affected by - relocation.
-
-
Symbols defined relative to this section are common symbols, such as - FORTRAN COMMON or unallocated C external variables.
-
-
This value specifies the upper bound of the range of reserved indices. The - system reserves indices between SHN_LORESERVE and - SHN_HIRESERVE, inclusive. The section header table does - not contain entries for the reserved indices.
-
-

The section header has the following structure:

-
-
typedef struct {
-	Elf32_Word      sh_name;
-	Elf32_Word      sh_type;
-	Elf32_Word      sh_flags;
-	Elf32_Addr      sh_addr;
-	Elf32_Off       sh_offset;
-	Elf32_Word      sh_size;
-	Elf32_Word      sh_link;
-	Elf32_Word      sh_info;
-	Elf32_Word      sh_addralign;
-	Elf32_Word      sh_entsize;
-} Elf32_Shdr;
-
-
-
typedef struct {
-	Elf64_Word      sh_name;
-	Elf64_Word      sh_type;
-	Elf64_Xword     sh_flags;
-	Elf64_Addr      sh_addr;
-	Elf64_Off       sh_offset;
-	Elf64_Xword     sh_size;
-	Elf64_Word      sh_link;
-	Elf64_Word      sh_info;
-	Elf64_Xword     sh_addralign;
-	Elf64_Xword     sh_entsize;
-} Elf64_Shdr;
-
-

-
-
-
This member specifies the name of the section. Its value is an index into - the section header string table section, giving the location of a - null-terminated string.
-
-
This member categorizes the section's contents and semantics. -

-
-
-
This value marks the section header as inactive. It does not have an - associated section. Other members of the section header have undefined - values.
-
-
The section holds information defined by the program, whose format and - meaning are determined solely by the program.
-
-
This section holds a symbol table. Typically, - SHT_SYMTAB provides symbols for link editing, though - it may also be used for dynamic linking. As a complete symbol table, - it may contain many symbols unnecessary for dynamic linking. An object - file can also contain a - - section.
-
-
This section holds a string table. An object file may have multiple - string table sections.
-
-
This section holds relocation entries with explicit addends, such as - type - - for the 32-bit class of object files. An object may have multiple - relocation sections.
-
-
This section holds a symbol hash table. All object participating in - dynamic linking must contain a symbol hash table. An object file may - have only one hash table.
-
-
This section holds information for dynamic linking. An object file may - have only one dynamic section.
-
-
This section holds information that marks the file in some way.
-
-
A section of this type occupies no space in the file but otherwise - resembles - . - Although this section contains no bytes, the - sh_offset member contains the conceptual file - offset.
-
-
This section holds relocation offsets without explicit addends, such - as type - - for the 32-bit class of object files. An object file may have multiple - relocation sections.
-
-
This section is reserved but has unspecified semantics.
-
-
This section holds a minimal set of dynamic linking symbols. An object - file can also contain a - - section.
-
-
This value up to and including SHT_HIPROC are - reserved for processor-specific semantics.
-
-
This value down to and including SHT_LOPROC are - reserved for processor-specific semantics.
-
-
This value specifies the lower bound of the range of indices reserved - for application programs.
-
-
This value specifies the upper bound of the range of indices reserved - for application programs. Section types between - SHT_LOUSER and SHT_HIUSER may be - used by the application, without conflicting with current or future - system-defined section types.
-
-

-
-
-
Sections support one-bit flags that describe miscellaneous attributes. If - a flag bit is set in sh_flags, the attribute is - “on” for the section. Otherwise, the attribute is - “off” or does not apply. Undefined attributes are set to - zero. -

-
-
-
This section contains data that should be writable during process - execution.
-
-
The section occupies memory during process execution. Some control - sections do not reside in the memory image of an object file. This - attribute is off for those sections.
-
-
The section contains executable machine instructions.
-
-
All bits included in this mask are reserved for processor-specific - semantics.
-
-
The section data is compressed.
-
-

-
-
-
If the section will appear in the memory image of a process, this member - holds the address at which the section's first byte should reside. - Otherwise, the member contains zero.
-
-
This member's value holds the byte offset from the beginning of the file - to the first byte in the section. One section type, - SHT_NOBITS, occupies no space in the file, and its - sh_offset member locates the conceptual placement in the - file.
-
-
This member holds the section's size in bytes. Unless the section type is - SHT_NOBITS, the section occupies - sh_size bytes in the file. A section of type - SHT_NOBITS may have a non-zero size, but it occupies no - space in the file.
- -
This member holds a section header table index link, whose interpretation - depends on the section type.
-
-
This member holds extra information, whose interpretation depends on the - section type.
-
-
Some sections have address alignment constraints. If a section holds a - doubleword, the system must ensure doubleword alignment for the entire - section. That is, the value of sh_addr must be congruent - to zero, modulo the value of sh_addralign. Only zero and - positive integral powers of two are allowed. Values of zero or one mean - the section has no alignment constraints.
-
-
Some sections hold a table of fixed-sized entries, such as a symbol table. - For such a section, this member gives the size in bytes for each entry. - This member contains zero if the section does not hold a table of - fixed-size entries.
-
-

Various sections hold program and control information:

-
-
.bss
-
(Block Started by Symbol) This section holds uninitialized data that - contributes to the program's memory image. By definition, the system - initializes the data with zeros when the program begins to run. This - section is of type SHT_NOBITS. The attributes types are - SHF_ALLOC and SHF_WRITE.
-
.comment
-
This section holds version control information. This section is of type - SHT_PROGBITS. No attribute types are used.
-
.ctors
-
This legacy section holds pointers to initialization routines, executed - before calling the main program entry point. This section is of type - SHT_PROGBITS. The attributes used are - SHF_ALLOC.
-
.data
-
This section holds initialized data that contribute to the program's - memory image. This section is of type SHT_PROGBITS. The - attribute types are SHF_ALLOC and - SHF_WRITE.
-
.data1
-
This section holds initialized data that contribute to the program's - memory image. This section is of type SHT_PROGBITS. The - attribute types are SHF_ALLOC and - SHF_WRITE.
-
.debug
-
This section holds information for symbolic debugging. The contents are - unspecified. This section is of type SHT_PROGBITS. No - attribute types are used.
-
.dtors
-
This legacy section holds pointers to finalization routines, executed when - the program exits normally. This section is of type - SHT_PROGBITS. The attributes used are - SHF_ALLOC.
-
.dynamic
-
This section holds dynamic linking information. The section's attributes - will include the SHF_ALLOC bit. Whether the - SHF_WRITE bit is set is processor-specific. This section - is of type SHT_DYNAMIC. See the attributes above.
-
.dynstr
-
This section holds strings needed for dynamic linking, most commonly the - strings that represent the names associated with symbol table entries. - This section is of type SHT_STRTAB. The attribute type - used is SHF_ALLOC.
-
.dynsym
-
This section holds the dynamic linking symbol table. This section is of - type SHT_DYNSYM. The attribute used is - SHF_ALLOC.
-
.fini
-
This legacy section holds executable instructions that contribute to the - process termination code. When a program exits normally the system - arranges to execute the code in this section. This section is of type - SHT_PROGBITS. The attributes used are - SHF_ALLOC and SHF_EXECINSTR.
-
.fini_array
-
This section holds pointers to finalization routines. When a program exits - normally rtld(1) executes the code referenced by this - section. This section is of type - . - The attributes used are SHF_ALLOC. Refer to - NT_FREEBSD_NOINIT_TAG (below) for a description of - how initialization and finalization code is invoked.
-
.got
-
This section holds the global offset table. This section is of type - SHT_PROGBITS. The attributes are - processor-specific.
-
.hash
-
This section holds a symbol hash table. This section is of type - SHT_HASH. The attribute used is - SHF_ALLOC.
-
.init
-
This legacy section holds executable instructions that contribute to the - process initialization code. When a program starts to run the system - arranges to execute the code in this section before calling the main - program entry point. This section is of type - SHT_PROGBITS. The attributes used are - SHF_ALLOC and SHF_EXECINSTR.
-
.init_array
-
This section holds pointers to initialization routines. When a program - starts to run rtld(1) executes the code referenced by - this section before calling the program entry point. This section is of - type - . - The attributes used are SHF_ALLOC. Refer to - NT_FREEBSD_NOINIT_TAG (below) for a description of - how initialization and finalization code is invoked.
-
.interp
-
This section holds the pathname of a program interpreter. If the file has - a loadable segment that includes the section, the section's attributes - will include the SHF_ALLOC bit. Otherwise, that bit will - be off. This section is of type SHT_PROGBITS.
-
.line
-
This section holds line number information for symbolic debugging, which - describes the correspondence between the program source and the machine - code. The contents are unspecified. This section is of type - SHT_PROGBITS. No attribute types are used.
-
.note
-
This section holds information in the “Note Section” format - described below. This section is of type SHT_NOTE. No - attribute types are used.
-
.plt
-
This section holds the procedure linkage table. This section is of type - SHT_PROGBITS. The attributes are - processor-specific.
-
.relNAME
-
This section holds relocation information as described below. If the file - has a loadable segment that includes relocation, the section's attributes - will include the SHF_ALLOC bit. Otherwise the bit will - be off. By convention, “NAME” is supplied by the section to - which the relocations apply. Thus a relocation section for - .text normally would have the name - . - This section is of type SHT_REL.
-
.relaNAME
-
This section holds relocation information as described below. If the file - has a loadable segment that includes relocation, the section's attributes - will include the SHF_ALLOC bit. Otherwise the bit will - be off. By convention, “NAME” is supplied by the section to - which the relocations apply. Thus a relocation section for - .text normally would have the name - . - This section is of type SHT_RELA.
-
.rodata
-
This section holds read-only data that typically contributes to a - non-writable segment in the process image. This section is of type - SHT_PROGBITS. The attribute used is - SHF_ALLOC.
-
.rodata1
-
This section holds read-only data that typically contributes to a - non-writable segment in the process image. This section is of type - SHT_PROGBITS. The attribute used is - SHF_ALLOC.
-
.shstrtab
-
This section holds section names. This section is of type - SHT_STRTAB. No attribute types are used.
-
.strtab
-
This section holds strings, most commonly the strings that represent the - names associated with symbol table entries. If the file has a loadable - segment that includes the symbol string table, the section's attributes - will include the SHF_ALLOC bit. Otherwise the bit will - be off. This section is of type SHT_STRTAB.
-
.symtab
-
This section holds a symbol table. If the file has a loadable segment that - includes the symbol table, the section's attributes will include the - SHF_ALLOC bit. Otherwise the bit will be off. This - section is of type SHT_SYMTAB.
-
.text
-
This section holds the “text”, or executable instructions, - of a program. This section is of type SHT_PROGBITS. The - attributes used are SHF_ALLOC and - SHF_EXECINSTR.
-
.jcr
-
This section holds information about Java classes that must be registered. - It is obsolete and binaries created for FreeBSD 15 - or later do not process it.
-
.eh_frame
-
This section holds information used for C++ exception-handling.
-
-

A section with the SHF_COMPRESSED flag set - contains a compressed copy of the section data. Compressed section data - begins with an Elf64_Chdr or - Elf32_Chdr structure which encodes the compression - algorithm and some characteristics of the uncompressed data.

-
-
typedef struct {
-	Elf32_Word    ch_type;
-	Elf32_Word    ch_size;
-	Elf32_Word    ch_addralign;
-} Elf32_Chdr;
-
-
-
typedef struct {
-	Elf64_Word    ch_type;
-	Elf64_Word    ch_reserved;
-	Elf64_Xword   ch_size;
-	Elf64_Xword   ch_addralign;
-} Elf64_Chdr;
-
-

-
-
-
The compression algorithm used. A value of - ELFCOMPRESS_ZLIB indicates that the data is - compressed using zlib(3). A value of - ELFCOMPRESS_ZSTD indicates that the data is - compressed using Zstandard.
-
-
The size, in bytes, of the uncompressed section data. This corresponds to - the sh_size field of a section header containing - uncompressed data.
-
-
The address alignment of the uncompressed section data. This corresponds - to the sh_addralign field of a section header containing - uncompressed data.
-
-

String table sections hold null-terminated character sequences, - commonly called strings. The object file uses these strings to represent - symbol and section names. One references a string as an index into the - string table section. The first byte, which is index zero, is defined to - hold a null character. Similarly, a string table's last byte is defined to - hold a null character, ensuring null termination for all strings.

-

An object file's symbol table holds information needed to locate - and relocate a program's symbolic definitions and references. A symbol table - index is a subscript into this array.

-
-
typedef struct {
-	Elf32_Word      st_name;
-	Elf32_Addr      st_value;
-	Elf32_Word      st_size;
-	unsigned char   st_info;
-	unsigned char   st_other;
-	Elf32_Half      st_shndx;
-} Elf32_Sym;
-
-
-
typedef struct {
-	Elf64_Word      st_name;
-	unsigned char   st_info;
-	unsigned char   st_other;
-	Elf64_Half      st_shndx;
-	Elf64_Addr      st_value;
-	Elf64_Xword     st_size;
-} Elf64_Sym;
-
-

-
-
-
This member holds an index into the object file's symbol string table, - which holds character representations of the symbol names. If the value is - non-zero, it represents a string table index that gives the symbol name. - Otherwise, the symbol table has no name.
-
-
This member gives the value of the associated symbol.
-
-
Many symbols have associated sizes. This member holds zero if the symbol - has no size or an unknown size.
-
-
This member specifies the symbol's type and binding attributes: -

-
-
-
The symbol's type is not defined.
-
-
The symbol is associated with a data object.
-
-
The symbol is associated with a function or other executable - code.
-
-
The symbol is associated with a section. Symbol table entries of this - type exist primarily for relocation and normally have - STB_LOCAL bindings.
-
-
By convention the symbol's name gives the name of the source file - associated with the object file. A file symbol has - STB_LOCAL bindings, its section index is - SHN_ABS, and it precedes the other - STB_LOCAL symbols of the file, if it is - present.
-
-
This value up to and including STT_HIPROC are - reserved for processor-specific semantics.
-
-
This value down to and including STT_LOPROC are - reserved for processor-specific semantics.
-
-

-
-
-
Local symbols are not visible outside the object file containing their - definition. Local symbols of the same name may exist in multiple file - without interfering with each other.
-
-
Global symbols are visible to all object files being combined. One - file's definition of a global symbol will satisfy another file's - undefined reference to the same symbol.
-
-
Weak symbols resemble global symbols, but their definitions have lower - precedence.
-
-
This value up to and including STB_HIPROC are - reserved for processor-specific semantics.
-
-
This value down to and including STB_LOPROC are - reserved for processor-specific semantics. -

There are macros for packing and unpacking the binding and - type fields:

-

-
-
(info)
-
or - (info) - extract a binding from an st_info value.
-
(info)
-
or - (info) - extract a type from an st_info value.
-
(bind, - type)
-
or - (bind, - type) convert a binding and a type into an - st_info value.
-
-
-
-

-
-
-
This member currently holds zero and has no defined meaning.
-
-
Every symbol table entry is “defined” in relation to some - section. This member holds the relevant section header table index.
-
-

Relocation is the process of connecting symbolic references with - symbolic definitions. Relocatable files must have information that describes - how to modify their section contents, thus allowing executable and shared - object files to hold the right information for a process' program image. - Relocation entries are these data.

-

Relocation structures that do not need an addend:

-
-
typedef struct {
-	Elf32_Addr      r_offset;
-	Elf32_Word      r_info;
-} Elf32_Rel;
-
-
-
typedef struct {
-	Elf64_Addr      r_offset;
-	Elf64_Xword     r_info;
-} Elf64_Rel;
-
-

Relocation structures that need an addend:

-
-
typedef struct {
-	Elf32_Addr      r_offset;
-	Elf32_Word      r_info;
-	Elf32_Sword     r_addend;
-} Elf32_Rela;
-
-
-
typedef struct {
-	Elf64_Addr      r_offset;
-	Elf64_Xword     r_info;
-	Elf64_Sxword    r_addend;
-} Elf64_Rela;
-
-

-
-
-
This member gives the location at which to apply the relocation action. - For a relocatable file, the value is the byte offset from the beginning of - the section to the storage unit affected by the relocation. For an - executable file or shared object, the value is the virtual address of the - storage unit affected by the relocation.
-
-
This member gives both the symbol table index with respect to which the - relocation must be made and the type of relocation to apply. Relocation - types are processor-specific. When the text refers to a relocation entry's - relocation type or symbol table index, it means the result of applying - - or - , - respectively to the entry's r_info member.
-
-
This member specifies a constant addend used to compute the value to be - stored into the relocatable field.
-
-
-

-

ELF note sections consist of entries with the following - format:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
namesz32 bitsSize of name
descsz32 bitsSize of desc
type32 bitsOS-dependent note type
namenameszNull-terminated originator name
descdescszOS-dependent note data
-

The name and desc - fields are padded to ensure 4-byte alignment. namesz - and descsz specify the unpadded length.

-

FreeBSD defines the following ELF note - types (with corresponding interpretation of desc):

-
-
- (Value: 1)
-
Indicates the OS ABI version in a form of a 32-bit integer containing - expected ABI version (i.e., - __FreeBSD_version).
-
- (Value: 2)
-
Indicates that the C startup does not call initialization routines, and - thus rtld(1) must do so. desc is - ignored.
-
- (Value: 3)
-
Contains the MACHINE_ARCH that the executable was built for.
-
- (Value: 4)
-
Contains a bitmask of mitigations and features to enable: -
-
NT_FREEBSD_FCTL_ASLR_DISABLE (Value: 0x01)
-
Request that address randomization (ASLR) not be performed. See - security(7).
-
NT_FREEBSD_FCTL_PROTMAX_DISABLE (Value: 0x02)
-
Request that mmap(2) calls not set PROT_MAX to the - initial value of the prot argument.
-
NT_FREEBSD_FCTL_STKGAP_DISABLE (Value: 0x04)
-
Disable stack gap.
-
NT_FREEBSD_FCTL_WXNEEDED (Value: 0x08)
-
Indicate that the binary requires mappings that are simultaneously - writeable and executable.
-
NT_FREEBSD_FCTL_LA48 (Value: 0x10)
-
Request 48-bit linear address space on amd64.
-
NT_FREEBSD_FCTL_LA57 (Value: 0x40)
-
Accept 57-bit linear address space on amd64.
-
-
-
-
-
-
-

-

as(1), gdb(1) - (ports/devel/gdb), ld(1), - objdump(1), readelf(1), - execve(2), zlib(3), - ar(5), core(5)

-

Hewlett Packard, - Elf-64 Object File Format.

-

Santa Cruz Operation, - System V Application Binary Interface.

-

Unix System - Laboratories, Object Files, - Executable and Linking Format (ELF).

-
-
-

-

The ELF header files made their appearance in - FreeBSD 2.2.6. ELF in itself first appeared in - AT&T System V UNIX. The ELF format is an - adopted standard.

-
-
-

-

This manual page was written by Jeroen Ruigrok - van der Werven - <asmodai@FreeBSD.org> - with inspiration from BSDi's BSD/OS - elf manpage.

-
-
- - - - - -
May 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man5/ethers.5 4.html b/static/freebsd/man5/ethers.5 4.html deleted file mode 100644 index 63f2c7cf..00000000 --- a/static/freebsd/man5/ethers.5 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
ETHERS(5)File Formats ManualETHERS(5)
-
-
-

-

ethers — ethernet - address database

-
-
-

-

The ethers database contains information - regarding known 48-bit ethernet addresses of hosts on an Internetwork. The - data is stored in a file called /etc/ethers in the - following format:

-

-
ethernet-address - fully-qualified-host-name
-

Items are separated by any number of blanks and/or tab characters. - A ``#'' at the start of a line indicates the beginning of a comment that - extends to the end of the line. A ``+'' at the start of a line will cause - the ethers(3) library functions to use data stored in the - NIS ethers.byname and - ethers.byaddr maps in addition to the data in the - /etc/ethers file.

-

An ethernet address is expressed in ASCII form as - "x:x:x:x:x:x" where x is a hexadecimal value - between 0x00 and 0xFF. The address values should be in network order. - Hostnames specified in the /etc/ethers database - should correspond to entries in the hosts(5) file.

-

The - () - function in the standard C library can be used to break individual lines in - the /etc/ethers database into their individual - components: a binary Ethernet address stored as an - ether_addr structure, and a hostname stored as a - character string.

-
-
-

-
-
/etc/ethers
-
The ethers file resides in - /etc.
-
-
-
-

-

ethers(3), yp(8)

-
-
-

-

The ethers format is based on the format - used in SunOS 4.1.x.

-
-
- - - - - -
April 12, 1995FreeBSD 15.0
diff --git a/static/freebsd/man5/eui64.5 4.html b/static/freebsd/man5/eui64.5 4.html deleted file mode 100644 index ee689d30..00000000 --- a/static/freebsd/man5/eui64.5 4.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - -
EUI64(5)File Formats ManualEUI64(5)
-
-
-

-

eui64 — IEEE - EUI-64 address database

-
-
-

-

The eui64 database contains information - regarding known IEEE EUI-64s of hosts. The data is stored in a file called - /etc/eui64 in the following format:

-
-

Items are separated by any number of blanks and/or tab characters. - A ‘#’ at the start of a line indicates - the beginning of a comment that extends to the end of the line. Valid lines - may also contain comments. A ‘+’ at - the start of a line will cause the eui64(3) library - functions to use data stored in the NIS eui64.byname - and eui64.byid maps in addition to the data in the - /etc/eui64 file.

-

An EUI-64 is expressed in ASCII form as - "x-x-x-x-x-x-x-x" where x is a hexadecimal - value between 0x00 and 0xFF. The address values should be in network order. - Hostnames specified in the /etc/eui64 database - should correspond to entries in the hosts(5) file.

-
-
-

-
-
/etc/eui64
-
The eui64 file resides in - /etc.
-
-
-
-

-

eui64(3), yp(8)

-
-
-

-

The eui64 format is based on the - ethers(5) format.

-
-
- - - - - -
May 11, 2004FreeBSD 15.0
diff --git a/static/freebsd/man5/fbtab.5 4.html b/static/freebsd/man5/fbtab.5 4.html deleted file mode 100644 index c60a8edd..00000000 --- a/static/freebsd/man5/fbtab.5 4.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
FBTAB(5)File Formats ManualFBTAB(5)
-
-
-

-

fbtab — change - device protection upon login

-
-
-

-

The fbtab file contains a number of lines - specifying a device together with a list of devices with associated - protections. Comments start with a ‘#’ - and extend to the end of the line.

-

Blank lines or lines with only a comment are ignored.

-

All other lines consist of three fields delimited by whitespace: a - login device (/dev/ttyv0), an octal permission - number (0600), and a colon (‘:’) - delimited list of device patterns (/dev/console, - /dev/dsp*). All device patterns are absolute - paths.

-

If the tty argument (relative path) matches a login device name - (absolute path), the permissions of the devices in the colon-delimited list - are set as specified in the second field, and their ownership is changed to - that of the UID and GID arguments.

-
-
-

-
-
/etc/fbtab
-
The fbtab file resides in - /etc.
-
-
-
-

-

login(1), getty(8)

-
-
-

-

Guido van Rooij

-
-
- - - - - -
August 22, 1994FreeBSD 15.0
diff --git a/static/freebsd/man5/forward.5 4.html b/static/freebsd/man5/forward.5 4.html deleted file mode 100644 index 0a492aed..00000000 --- a/static/freebsd/man5/forward.5 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
FORWARD(5)File Formats ManualFORWARD(5)
-
-
-

-

forward — mail - forwarding instructions

-
-
-

-

The .forward file contains a list of mail - addresses or programs that the user's mail should be redirected to. If the - file is not present, then no mail forwarding will be done. Mail may also be - forwarded as the standard input to a program by prefixing the line with the - normal shell pipe symbol (|). If arguments are to be passed to the command, - then the entire line should be enclosed in quotes. For security reasons, the - .forward file must be owned by the user the mail is - being sent to, or by root, and the user's shell must be listed in - /etc/shells.

-

For example, if a .forward file contained - the following lines:

-
-
nobody@FreeBSD.org
-"|/usr/bin/vacation nobody"
-
-

Mail would be forwarded to ⟨nobody@FreeBSD.org⟩ and - to the program /usr/bin/vacation with the single - argument nobody.

-

If a local user address is prefixed with a backslash character, - mail is delivered directly to the user's mail spool file, bypassing further - redirection.

-

For example, if user chris had a .forward - file containing the following lines:

-
-
chris@otherhost
-\chris
-
-

One copy of mail would be forwarded to - chris@otherhost and another copy would be retained as - mail for local user chris.

-
-
-

-
-
$HOME/.forward
-
The user's forwarding instructions.
-
-
-
-

-

aliases(5), sendmail(8)

-
-
- - - - - -
July 2, 1996FreeBSD 15.0
diff --git a/static/freebsd/man5/freebsd-update.conf.5 3.html b/static/freebsd/man5/freebsd-update.conf.5 3.html deleted file mode 100644 index 99427e01..00000000 --- a/static/freebsd/man5/freebsd-update.conf.5 3.html +++ /dev/null @@ -1,198 +0,0 @@ - - - - - - -
FREEBSD-UPDATE.CONF(5)File Formats ManualFREEBSD-UPDATE.CONF(5)
-
-
-

-

freebsd-update.conf — - configuration file for - freebsd-update(8)

-
-
-

-

The freebsd-update.conf file controls the - behaviour of the freebsd-update(8) utility. The file - contains lines consisting of a case-sensitive option name and zero or more - parameters. Empty lines and any part of a line following a - ‘#’ character are ignored. Unless - stated otherwise, specifying an option multiple times is an error.

-

The possible options and their meanings are as follows:

-
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) is allowed to create new files, - directories, and symlinks if these are part of updates downloaded. Note - that freebsd-update(8) will not re-add files which have - been deleted from a FreeBSD installation unless - those files were previously added as part of an update.
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) is allowed to delete files, - directories, and symlinks as part of updates downloaded.
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) will create a backup of the old kernel - before installing a new kernel. This backup kernel can be used to recover - a system where the newly installed kernel somehow did not work. Note that - the backup kernel is not reverted to its original state by the - freebsd-update(8) rollback command.
-
-
This keyword sets the directory which is used to store a backup kernel, if - the BackupKernel feature is enabled. If the directory already exist, and - it was not created by freebsd-update(8), the directory - is skipped. In the case of the primary directory name not being usable, a - number starting with ‘1’ is appended to the directory name. - Like with the primary directory name, the constructed directory name is - only used if the path name does not exist, or if the directory was - previously created by freebsd-update(8). If the - constructed directory still exist the appended number is incremented with - 1 and the directory search process restarted. Should the number increment - go above 9, freebsd-update(8) will abort.
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) will also backup kernel symbol files, - if they exist. The kernel symbol files takes up a lot of disk space and - are not needed for recovery purposes. If the symbol files are needed, - after recovering a system using the backup kernel, the - freebsd-update(8) rollback command will recreate the - symbol files along with the old kernel.
-
-
The parameters following this keyword are the components or sub-components - of FreeBSD which will be updated. The components - are “src” (source code), “world” (non-kernel - binaries), and “kernel”; the sub-components are the - individual distribution sets generated as part of the release process - (e.g., “src/base”, “src/sys”, - “world/base”, “world/catpages”, - “kernel/smp”). Note that prior to FreeBSD - 6.1, the “kernel” component was distributed as part - of “world/base”. -

This option can be specified multiple times, and the - parameters accumulate.

-
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) will create a new boot environment - using bectl(8) when installing patches. -

The name of the new boot environment consists of the current - FreeBSD version:

-
- 
freebsd-version -ku | sort -V | tail -n 1
-
-

and a timestamp:

-
- 
date +"%Y-%m-%d_%H%M%S"
-
-

separated by a single dash, e.g.:

-
- 
13.0-RELEASE-p7_2022-02-16_141502
-
-

freebsd-update(8) does not attempt to create - a boot environment if any of the following applies:

-

-
    -
  • ZFS is not used.
    • -
  • The ZFS root is not set up for boot environments (see the check - command of bectl(8) for details).
    • -
  • freebsd-update(8) is running in a - jail(8).
    • -
  • freebsd-update(8) is updating a root directory - selected via the basedir (-b) or jail - (-j) flags.
    • -
-
-
-
The parameters following this keyword are regular expressions; paths which - start with a string matching one of these regular expressions will be - ignored by freebsd-update(8) IDS. -

This option can be specified multiple times, and the - parameters accumulate.

-
-
-
The parameters following this keyword are regular expressions; updates to - paths which start with a string matching one of these regular expressions - will be ignored. -

This option can be specified multiple times, and the - parameters accumulate.

-
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) should keep existing file ownership, - permissions, and flags when installing updates if these have been modified - locally.
-
-
The single parameter following this keyword is the SHA256 hash of the RSA - key which will be trusted to sign updates.
-
-
The single parameter following this keyword is the address to which - cron(8) output will be mailed.
-
-
The parameters following this keyword are regular expressions; updates to - paths which start with a string matching one of these regular expressions - will be merged with local modifications. -

This option can be specified multiple times, and the - parameters accumulate.

-
-
-
The single parameter following this keyword is the name of the server or - server pool from which updates will be downloaded.
-
-
The single parameter following this keyword must be “yes” or - “no” and specifies whether - freebsd-update(8) should interpret the list of - components of FreeBSD specified via the - Components option strictly as a list of components - installed which should be upgraded when the - upgrade command is used ("yes"), or - merely as a list of components which might be installed, of which - freebsd-update(8) should identify which in fact are - present ("no").
-
-
The parameters following this keyword are regular expressions; updates to - paths which start with a string matching one of these regular expressions - will be ignored if the files have been modified locally (unless they are - merged — see the MergeChanges option). -

This option can be specified multiple times, and the - parameters accumulate.

-
-
-
The single parameter following this keyword is the directory in which - temporary files and downloaded updates will be stored.
-
-
-
-

-
-
/etc/freebsd-update.conf
-
Default location of the freebsd-update(8) configuration - file.
-
-
-
-

-

sha256(1), bectl(8), - freebsd-update(8)

-
-
-

-

Colin Percival - <cperciva@FreeBSD.org>

-
-
- - - - - -
February 17, 2022FreeBSD 15.0
diff --git a/static/freebsd/man5/fs.5 3.html b/static/freebsd/man5/fs.5 3.html deleted file mode 100644 index 239ca996..00000000 --- a/static/freebsd/man5/fs.5 3.html +++ /dev/null @@ -1,336 +0,0 @@ - - - - - - -
FS(5)File Formats ManualFS(5)
-
-
-

-

fs, inode — - format of file system volume

-
-
-

-

#include - <sys/param.h> -
- #include <ufs/ffs/fs.h>

-

-
- #include <sys/types.h> -
- #include <sys/lock.h> -
- #include <sys/extattr.h> -
- #include <sys/acl.h> -
- #include <ufs/ufs/quota.h> -
- #include <ufs/ufs/dinode.h> -
- #include - <ufs/ufs/extattr.h>

-
-
-

-

The files <fs.h> - and <inode.h> declare - several structures, defined variables and macros which are used to create - and manage the underlying format of file system objects on random access - devices (disks).

-

The block size and number of blocks which comprise a file system - are parameters of the file system. Sectors beginning at - BBLOCK and continuing for - BBSIZE are used for a disklabel and for some - hardware primary and secondary bootstrapping programs.

-

The actual file system begins at sector - SBLOCK with the - - that is of size SBLOCKSIZE. The following structure - describes the super-block and is from the file - <ufs/ffs/fs.h>:

-
-
/*
- * Super block for an FFS filesystem.
- */
-struct fs {
-	int32_t	 fs_firstfield;	   /* historic filesystem linked list, */
-	int32_t	 fs_unused_1;      /*     used for incore super blocks */
-	int32_t	 fs_sblkno;        /* offset of super-block in filesys */
-	int32_t	 fs_cblkno;        /* offset of cyl-block in filesys */
-	int32_t	 fs_iblkno;        /* offset of inode-blocks in filesys */
-	int32_t	 fs_dblkno;        /* offset of first data after cg */
-	int32_t	 fs_old_cgoffset;  /* cylinder group offset in cylinder */
-	int32_t	 fs_old_cgmask;    /* used to calc mod fs_ntrak */
-	int32_t  fs_old_time;      /* last time written */
-	int32_t	 fs_old_size;      /* number of blocks in fs */
-	int32_t	 fs_old_dsize;     /* number of data blocks in fs */
-	int32_t	 fs_ncg;           /* number of cylinder groups */
-	int32_t	 fs_bsize;         /* size of basic blocks in fs */
-	int32_t	 fs_fsize;         /* size of frag blocks in fs */
-	int32_t	 fs_frag;          /* number of frags in a block in fs */
-/* these are configuration parameters */
-	int32_t	 fs_minfree;       /* minimum percentage of free blocks */
-	int32_t	 fs_old_rotdelay;  /* num of ms for optimal next block */
-	int32_t	 fs_old_rps;       /* disk revolutions per second */
-/* these fields can be computed from the others */
-	int32_t	 fs_bmask;         /* ``blkoff'' calc of blk offsets */
-	int32_t	 fs_fmask;         /* ``fragoff'' calc of frag offsets */
-	int32_t	 fs_bshift;        /* ``lblkno'' calc of logical blkno */
-	int32_t	 fs_fshift;        /* ``numfrags'' calc number of frags */
-/* these are configuration parameters */
-	int32_t	 fs_maxcontig;     /* max number of contiguous blks */
-	int32_t	 fs_maxbpg;        /* max number of blks per cyl group */
-/* these fields can be computed from the others */
-	int32_t	 fs_fragshift;     /* block to frag shift */
-	int32_t	 fs_fsbtodb;       /* fsbtodb and dbtofsb shift constant */
-	int32_t	 fs_sbsize;        /* actual size of super block */
-	int32_t	 fs_spare1[2];     /* old fs_csmask */
-	                           /* old fs_csshift */
-	int32_t	 fs_nindir;        /* value of NINDIR */
-	int32_t	 fs_inopb;         /* value of INOPB */
-	int32_t	 fs_old_nspf;      /* value of NSPF */
-/* yet another configuration parameter */
-	int32_t	 fs_optim;         /* optimization preference, see below */
-	int32_t	 fs_old_npsect;    /* # sectors/track including spares */
-	int32_t	 fs_old_interleave; /* hardware sector interleave */
-	int32_t	 fs_old_trackskew; /* sector 0 skew, per track */
-	int32_t	 fs_id[2];         /* unique filesystem id */
-/* sizes determined by number of cylinder groups and their sizes */
-	int32_t	 fs_old_csaddr;	   /* blk addr of cyl grp summary area */
-	int32_t	 fs_cssize;        /* size of cyl grp summary area */
-	int32_t	 fs_cgsize;        /* cylinder group size */
-	int32_t	 fs_spare2;        /* old fs_ntrak */
-	int32_t	 fs_old_nsect;     /* sectors per track */
-	int32_t  fs_old_spc;       /* sectors per cylinder */
-	int32_t	 fs_old_ncyl;      /* cylinders in filesystem */
-	int32_t	 fs_old_cpg;       /* cylinders per group */
-	int32_t	 fs_ipg;           /* inodes per group */
-	int32_t	 fs_fpg;           /* blocks per group * fs_frag */
-/* this data must be re-computed after crashes */
-	struct	csum fs_old_cstotal; /* cylinder summary information */
-/* these fields are cleared at mount time */
-	int8_t   fs_fmod;          /* super block modified flag */
-	int8_t   fs_clean;         /* filesystem is clean flag */
-	int8_t 	 fs_ronly;         /* mounted read-only flag */
-	int8_t   fs_old_flags;     /* old FS_ flags */
-	u_char	 fs_fsmnt[MAXMNTLEN]; /* name mounted on */
-	u_char	 fs_volname[MAXVOLLEN]; /* volume name */
-	uint64_t fs_swuid;         /* system-wide uid */
-	int32_t  fs_pad;           /* due to alignment of fs_swuid */
-/* these fields retain the current block allocation info */
-	int32_t	 fs_cgrotor;       /* last cg searched */
-	void 	*fs_ocsp[NOCSPTRS]; /* padding; was list of fs_cs buffers */
-	uint8_t *fs_contigdirs;    /* # of contiguously allocated dirs */
-	struct	csum *fs_csp;      /* cg summary info buffer for fs_cs */
-	int32_t	*fs_maxcluster;    /* max cluster in each cyl group */
-	u_int	*fs_active;        /* used by snapshots to track fs */
-	int32_t	 fs_old_cpc;       /* cyl per cycle in postbl */
-	int32_t	 fs_maxbsize;      /* maximum blocking factor permitted */
-	int64_t	 fs_unrefs;        /* number of unreferenced inodes */
-	int64_t	 fs_sparecon64[16]; /* old rotation block list head */
-	int64_t	 fs_sblockloc;     /* byte offset of standard superblock */
-	struct	csum_total fs_cstotal;  /* cylinder summary information */
-	ufs_time_t fs_time;        /* last time written */
-	int64_t	 fs_size;          /* number of blocks in fs */
-	int64_t	 fs_dsize;         /* number of data blocks in fs */
-	ufs2_daddr_t fs_csaddr;    /* blk addr of cyl grp summary area */
-	int64_t	 fs_pendingblocks; /* blocks in process of being freed */
-	int32_t	 fs_pendinginodes; /* inodes in process of being freed */
-	int32_t	 fs_snapinum[FSMAXSNAP]; /* list of snapshot inode numbers */
-	int32_t	 fs_avgfilesize;   /* expected average file size */
-	int32_t	 fs_avgfpdir;      /* expected # of files per directory */
-	int32_t	 fs_save_cgsize;   /* save real cg size to use fs_bsize */
-	int32_t	 fs_sparecon32[26]; /* reserved for future constants */
-	int32_t  fs_flags;         /* see FS_ flags below */
-	int32_t	 fs_contigsumsize; /* size of cluster summary array */
-	int32_t	 fs_maxsymlinklen; /* max length of an internal symlink */
-	int32_t	 fs_old_inodefmt;  /* format of on-disk inodes */
-	uint64_t fs_maxfilesize;   /* maximum representable file size */
-	int64_t	 fs_qbmask;        /* ~fs_bmask for use with 64-bit size */
-	int64_t	 fs_qfmask;        /* ~fs_fmask for use with 64-bit size */
-	int32_t	 fs_state;         /* validate fs_clean field */
-	int32_t	 fs_old_postblformat; /* format of positional layout tables */
-	int32_t	 fs_old_nrpos;     /* number of rotational positions */
-	int32_t	 fs_spare5[2];     /* old fs_postbloff */
-	                           /* old fs_rotbloff */
-	int32_t	 fs_magic;         /* magic number */
-};
-
-/*
- * Filesystem identification
- */
-#define	FS_UFS1_MAGIC	0x011954    /* UFS1 fast filesystem magic number */
-#define	FS_UFS2_MAGIC	0x19540119  /* UFS2 fast filesystem magic number */
-#define	FS_OKAY		0x7c269d38  /* superblock checksum */
-#define FS_42INODEFMT	-1      /* 4.2BSD inode format */
-#define FS_44INODEFMT	2       /* 4.4BSD inode format */
-
-/*
- * Preference for optimization.
- */
-#define FS_OPTTIME	0	/* minimize allocation time */
-#define FS_OPTSPACE	1	/* minimize disk fragmentation */
-
-

Each disk drive contains some number of file systems. A file - system consists of a number of cylinder groups. Each cylinder group has - inodes and data.

-

A file system is described by its super-block, which in turn - describes the cylinder groups. The super-block is critical data and is - replicated in each cylinder group to protect against catastrophic loss. This - is done at file system creation time and the critical super-block data does - not change, so the copies need not be referenced further unless disaster - strikes.

-

Addresses stored in inodes are capable of addressing fragments of - `blocks'. File system blocks of at most size - MAXBSIZE can be optionally broken into 2, 4, or 8 - pieces, each of which is addressable; these pieces may be - DEV_BSIZE, or some multiple of a - DEV_BSIZE unit.

-

Large files consist of exclusively large data blocks. - To avoid undue wasted disk space, the last data block of a small file is - allocated as only as many fragments of a large block as are necessary. The - file system format retains only a single pointer to such a fragment, which - is a piece of a single large block that has been divided. The size of such a - fragment is determinable from information in the inode, using the - (fs, - ip, lbn) macro.

-

The file system records space availability at the fragment level; - to determine block availability, aligned fragments are examined.

-

The root inode is the root of the file system. Inode 0 cannot be - used for normal purposes and historically bad blocks were linked to inode 1, - thus the root inode is 2 (inode 1 is no longer used for this purpose, - however numerous dump tapes make this assumption, so we are stuck with - it).

-

The fs_minfree element gives the minimum - acceptable percentage of file system blocks that may be free. If the - freelist drops below this level only the super-user may continue to allocate - blocks. The fs_minfree element may be set to 0 if no - reserve of free blocks is deemed necessary, however severe performance - degradations will be observed if the file system is run at greater than 90% - full; thus the default value of fs_minfree is 8%.

-

Empirically the best trade-off between block fragmentation and - overall disk utilization at a loading of 90% comes with a fragmentation of - 8, thus the default fragment size is an eighth of the block size.

-

The element fs_optim specifies whether the - file system should try to minimize the time spent allocating blocks, or if - it should attempt to minimize the space fragmentation on the disk. If the - value of fs_minfree (see above) is less than 8%, then the file system - defaults to optimizing for space to avoid running out of full sized blocks. - If the value of minfree is greater than or equal to 8%, fragmentation is - unlikely to be problematical, and the file system defaults to optimizing for - time.

-

: Each cylinder keeps track of the availability - of blocks at different rotational positions, so that sequential blocks can - be laid out with minimum rotational latency. With the default of 8 - distinguished rotational positions, the resolution of the summary - information is 2ms for a typical 3600 rpm drive.

-

The element fs_old_rotdelay gives the - minimum number of milliseconds to initiate another disk transfer on the same - cylinder. It is used in determining the rotationally optimal layout for disk - blocks within a file; the default value for - fs_old_rotdelay is 2ms.

-

Each file system has a statically allocated number of inodes. An - inode is allocated for each NBPI bytes of disk - space. The inode allocation strategy is extremely conservative.

-

MINBSIZE is the smallest allowable block - size. With a MINBSIZE of 4096 it is possible to - create files of size 2^32 with only two levels of indirection. - MINBSIZE must be big enough to hold a cylinder group - block, thus changes to (struct cg) must keep its size - within MINBSIZE. Note that super-blocks are never - more than size SBLOCKSIZE.

-

The path name on which the file system is mounted is maintained in - fs_fsmnt. MAXMNTLEN defines - the amount of space allocated in the super-block for this name. The limit on - the amount of summary information per file system is defined by - MAXCSBUFS. For a 4096 byte block size, it is - currently parameterized for a maximum of two million cylinders.

-

Per cylinder group information is summarized in blocks allocated - from the first cylinder group's data blocks. These blocks are read in from - fs_csaddr (size fs_cssize) in - addition to the super-block.

-

: - (struct - csum) must be a power of two in order for the - () - macro to work.

-

The - : The size of the rotational layout tables is limited by - the fact that the super-block is of size SBLOCKSIZE. - The size of these tables is - - proportional to the block size of the file system. The size of the tables is - increased when sector sizes are not powers of two, as this increases the - number of cylinders included before the rotational pattern repeats - (fs_cpc). The size of the rotational layout tables is - derived from the number of bytes remaining in (struct - fs).

-

The number of blocks of data per cylinder group is limited because - cylinder groups are at most one block. The inode and free block tables must - fit into a single block after deducting space for the cylinder group - structure (struct cg).

-

The - : The inode is - the focus of all file activity in the UNIX file - system. There is a unique inode allocated for each active file, each current - directory, each mounted-on file, text file, and the root. An inode is - `named' by its device/i-number pair. For further information, see the - include file - <ufs/ufs/inode.h>.

-

The format of an external attribute is defined by the extattr - structure:

-
-
struct extattr {
-	uint32_t ea_length;	    /* length of this attribute */
-	uint8_t	ea_namespace;	    /* name space of this attribute */
-	uint8_t	ea_contentpadlen;   /* bytes of padding at end of attribute */
-	uint8_t	ea_namelength;	    /* length of attribute name */
-	char	ea_name[1];	    /* attribute name (NOT nul-terminated) */
-	/* padding, if any, to align attribute content to 8 byte boundary */
-	/* extended attribute content follows */
-};
-
-

Several macros are defined to manipulate these structures. Each - macro takes a pointer to an extattr structure.

-
-
-
Returns a pointer to the next extended attribute following - eap.
-
-
Returns a pointer to the extended attribute content referenced by - eap.
-
-
Returns the size of the extended attribute content referenced by - eap.
-
-

The following code identifies an ACL:

-
-
	if (eap->ea_namespace == EXTATTR_NAMESPACE_SYSTEM &&
-            eap->ea_namelength == sizeof(POSIX1E_ACL_ACCESS_EXTATTR_NAME) - 1 &&
-	    strncmp(eap->ea_name, POSIX1E_ACL_ACCESS_EXTATTR_NAME,
-             sizeof(POSIX1E_ACL_ACCESS_EXTATTR_NAME) - 1) == 0) {
-		aclp = EXTATTR_CONTENT(eap);
-		acllen = EXTATTR_CONTENT_SIZE(eap);
-		...
-	}
-
-
-
-

-

A super-block structure named filsys appeared in - Version 6 AT&T UNIX. The file system - described in this manual appeared in 4.2BSD.

-
-
- - - - - -
January 16, 2017FreeBSD 15.0
diff --git a/static/freebsd/man5/fstab.5 3.html b/static/freebsd/man5/fstab.5 3.html deleted file mode 100644 index d5f862a0..00000000 --- a/static/freebsd/man5/fstab.5 3.html +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - -
FSTAB(5)File Formats ManualFSTAB(5)
-
-
-

-

fstab — static - information about the file systems

-
-
-

-

#include - <fstab.h>

-
-
-

-

The file fstab contains descriptive - information about the various file systems. fstab is - only read by programs, and not written; it is the duty of the system - administrator to properly create and maintain this file. Each file system is - described on a separate line; fields on each line are separated by tabs or - spaces. The order of records in fstab is important - because fsck(8), mount(8), and - umount(8) sequentially iterate through - fstab doing their thing.

-

The first field, (fs_spec), describes the - special device or remote file system to be mounted. The contents are decoded - by the strunvis(3) function. This allows using spaces or - tabs in the device name which would be interpreted as field separators - otherwise.

-

The second field, (fs_file), describes the - mount point for the file system. For swap partitions, this field should be - specified as “none”. The contents are decoded by the - strunvis(3) function, as above.

-

The third field, (fs_vfstype), describes the - type of the file system. The system can support various file system types. - Only the root, /usr, and /tmp file systems need be statically compiled into - the kernel; everything else will be automatically loaded at mount time. - (Exception: the FFS cannot currently be demand-loaded.) Some people still - prefer to statically compile other file systems as well.

-

The fourth field, (fs_mntops), describes the - mount options associated with the file system. It is formatted as a comma - separated list of options. It contains at least the type of mount (see - fs_type below) plus any additional options appropriate - to the file system type. See the options flag (-o) - in the mount(8) page and the file system specific page, - such as mount_nfs(8), for additional options that may be - specified. All options that can be given to the file system specific mount - commands can be used in fstab as well. They just - need to be formatted a bit differently. The arguments of the - -o option can be used without the preceding - -o flag. Other options need both the file system - specific flag and its argument, separated by an equal sign. For example, - mounting an msdosfs(4) filesystem, the options

-
-
-o sync -o noatime -m 644 -M 755 -u foo -g bar
-
-

should be written as

-
-
sync,noatime,-m=644,-M=755,-u=foo,-g=bar
-
-

in the option field of fstab.

-

If the options “userquota” and/or - “groupquota” are specified, the file system is automatically - processed by the quotacheck(8) command, and user and/or - group disk quotas are enabled with quotaon(8). By default, - file system quotas are maintained in files named - quota.user and quota.group - which are located at the root of the associated file system. These defaults - may be overridden by putting an equal sign and an alternative absolute - pathname following the quota option. Thus, if the user quota file for - /tmp is stored in - /var/quotas/tmp.user, this location can be specified - as:

-
-
userquota=/var/quotas/tmp.user
-
-

If the option “failok” is specified, the system will - ignore any error which happens during the mount of that filesystem, which - would otherwise cause the system to drop into single user mode. This option - is implemented by the mount(8) command and will not be - passed to the kernel.

-

If the option “noauto” is specified, the file system - will not be automatically mounted at system startup. Note that, for network - file systems of third party types (i.e., types supported by additional - software not included in the base system) to be automatically mounted at - system startup, the extra_netfs_types - rc.conf(5) variable must be used to extend the - rc(8) startup script's list of network file system - types.

-

If the option “late” is specified, the file system - will be automatically mounted at a stage of system startup after remote - mount points are mounted. For more detail about this option, see the - mount(8) manual page.

-

If the option “update” is specified, it indicates - that the status of an already mounted file system should be changed - accordingly. This allows, for example, file systems mounted read-only to be - upgraded read-write and vice-versa. By default, an entry corresponding to a - file systems that is already mounted is going to be skipped over when - processing fstab, unless it's a root file system, in - which case logic similar to “update” is applied - automatically.

-

The “update” option is typically used in conjunction - with two fstab files. The first - fstab file is used to set up the initial set of file - systems. The second fstab file is then run to update - the initial set of file systems and to add additional file systems.

-

The type of the mount is extracted from the - fs_mntops field and stored separately in the - fs_type field (it is not deleted from the - fs_mntops field). If fs_type is - “rw” or “ro” then the file system whose name is - given in the fs_file field is normally mounted - read-write or read-only on the specified special file.

-

If fs_type is “sw” then the - special file is made available as a piece of swap space by the - swapon(8) command at the end of the system reboot - procedure. For swap devices, the keyword “trimonce” triggers - the delivery of a BIO_DELETE command to the device. - This command marks the device's blocks as unused, except those that might - store a disk label. This marking can erase a crash dump. To delay - swapon for a device until after - savecore has copied the crash dump to another - location, use the “late” option. For vnode-backed swap spaces, - “file” is supported in the fs_mntops - field. When fs_spec is an md(4) - device file (“md” or “md[0-9]*”) and - “file” is specified in fs_mntopts, an - md(4) device is created with the specified file used as - backing store, and then the new device is used as swap space. Swap entries - on .eli devices will cause automatic creation of - encrypted devices. The “ealgo”, “aalgo”, - “keylen”, “notrim”, and - “sectorsize” options may be passed to control those - geli(8) parameters. The fields other than - fs_spec and fs_type are unused. - If fs_type is specified as “xx” the - entry is ignored. This is useful to show disk partitions which are currently - unused.

-

The fifth field, (fs_freq), is used for - these file systems by the dump(8) command to determine - which file systems need to be dumped. If the fifth field is not present, a - value of zero is returned and dump will assume that - the file system does not need to be dumped. If the fifth field is greater - than 0, then it specifies the number of days between dumps for this file - system.

-

The sixth field, (fs_passno), is used by the - fsck(8) and quotacheck(8) programs to - determine the order in which file system and quota checks are done at reboot - time. The fs_passno field can be any value between 0 - and ‘INT_MAX-1’.

-

The root file system should be specified with a - fs_passno of 1, and other file systems should have a - fs_passno of 2 or greater. A file system with a - fs_passno value of 1 is always checked sequentially - and be completed before another file system is processed, and it will be - processed before all file systems with a larger - fs_passno.

-

For any given value of fs_passno, file - systems within a drive will be checked sequentially, but file systems on - different drives will be checked at the same time to utilize parallelism - available in the hardware. Once all file system checks are complete for the - current fs_passno, the same process will start over - for the next fs_passno.

-

If the sixth field is not present or is zero, a value of zero is - returned and fsck(8) and quotacheck(8) - will assume that the file system does not need to be checked.

-

The fs_passno field can be used to implement - finer control when the system utilities may determine that the file system - resides on a different physical device, when it actually does not, as with a - ccd(4) device. All file systems with a lower - fs_passno value will be completed before starting on - file systems with a higher fs_passno value. E.g. all - file systems with a fs_passno of 2 will be completed - before any file systems with a fs_passno of 3 or - greater are started. Gaps are allowed between the different - fs_passno values. E.g. file systems listed in - /etc/fstab may have fs_passno - values such as 0, 1, 2, 15, 100, 200, 300, and may appear in any order - within /etc/fstab.

-
-
#define	FSTAB_RW	"rw"	/* read/write device */
-#define	FSTAB_RQ	"rq"	/* read/write with quotas */
-#define	FSTAB_RO	"ro"	/* read-only device */
-#define	FSTAB_SW	"sw"	/* swap device */
-#define	FSTAB_XX	"xx"	/* ignore totally */
-
-struct fstab {
-	char	*fs_spec;	/* block special device name */
-	char	*fs_file;	/* file system path prefix */
-	char	*fs_vfstype;	/* File system type, ufs, nfs */
-	char	*fs_mntops;	/* Mount options ala -o */
-	char	*fs_type;	/* FSTAB_* from fs_mntops */
-	int	fs_freq;	/* dump frequency, in days */
-	int	fs_passno;	/* pass number on parallel fsck */
-};
-
-

The proper way to read records from fstab - is to use the routines getfsent(3), - getfsspec(3), getfstype(3), and - getfsfile(3).

-
-
-

-
-
/etc/fstab
-
The file fstab resides in - /etc.
-
-
-
-

-
-
# Device	Mountpoint	FStype	Options		Dump	Pass#
-#
-# UFS file system.
-/dev/da0p2	/		ufs	rw		1	1
-#
-# Swap space on a block device.
-/dev/da0p1	none		swap	sw		0	0
-#
-# Swap space using a block device with GELI encryption.
-# aalgo, ealgo, keylen, sectorsize options are available
-# for .eli devices.
-/dev/da1p2.eli	none		swap	sw		0	0
-#
-# tmpfs.
-tmpfs		/tmp		tmpfs	rw,size=1g,mode=1777	0 0
-#
-# UFS file system on a swap-backed md(4).  /dev/md10 is
-# automatically created.  If it is "md", a unit number
-# will be automatically selected.
-md10		/scratch	mfs	rw,-s1g		0	0
-#
-# Swap space on a vnode-backed md(4).
-md11		none		swap	sw,file=/swapfile	0 0
-#
-# CDROM.  "noauto" option is typically used because the
-# media is removable.
-/dev/cd0	/cdrom		cd9660	ro,noauto	0	0
-#
-# NFS-exported file system.  "serv" is an NFS server name
-# or IP address.
-serv:/export	/nfs		nfs	rw,noinet6	0	0
-
-
-
-

-

getfsent(3), getvfsbyname(3), - strunvis(3), ccd(4), - dump(8), fsck(8), - geli(8), mount(8), - quotacheck(8), quotaon(8), - swapon(8), umount(8)

-
-
-

-

The fstab file format appeared in - 4.0BSD.

-
-
- - - - - -
April 14, 2014FreeBSD 15.0
diff --git a/static/freebsd/man5/group.5 3.html b/static/freebsd/man5/group.5 3.html deleted file mode 100644 index 1cf3cefd..00000000 --- a/static/freebsd/man5/group.5 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
GROUP(5)File Formats ManualGROUP(5)
-
-
-

-

group — format of - the group permissions file

-
-
-

-

The group file is the local source of - group information. It can be used in conjunction with the Hesiod domain - `group', and the NIS maps `group.byname' and `group.bygid', as controlled by - nsswitch.conf(5).

-

The file group consists of newline - separated ASCII records, one per group, containing four colon - ‘:’ separated fields. These fields are - as follows:

-
-
-
group
-
Name of the group.
-
passwd
-
Group's encrypted password.
-
gid
-
The group's decimal ID.
-
member
-
Group members.
-
-
-

Lines whose first non-whitespace character is a pound-sign (#) are - comments, and are ignored. Blank lines that consist only of spaces, tabs or - newlines are also ignored.

-

The group field is the group name used for - granting file access to users who are members of the group. The - gid field is the number associated with the group - name. They should both be unique across the system (and often across a group - of systems) since they control file access. The passwd - field is an optional encrypted password. This field is - rarely used and an asterisk is normally placed in it rather than leaving it - blank. The member field contains the names of users - granted the privileges of group. The member names are - separated by commas without spaces or newlines. A user is automatically in a - group if that group was specified in their - /etc/passwd entry and does not need to be added to - that group in the group file.

-
-
-

-

The passwd(1) command does not change the - group passwords. The pw(8) - utility's groupmod command should be used - instead.

-
-
-

-

There are various limitations which are explained in the function - where they occur; see section SEE - ALSO.

-

In older implementations, a group cannot have more than 200 - members. The maximum line length of /etc/group is - 1024 characters. Longer lines will be skipped. This limitation disappeared - in FreeBSD 3.0. Older binaries that are statically - linked, depend on old shared libraries, or - non-FreeBSD binaries in - compatibility mode may still have this limit.

-
-
-

-
-
/etc/group
-
 
-
-
-
-

-

newgrp(1), passwd(1), - setcred(2), setgroups(2), - crypt(3), getgrent(3), - initgroups(3), nsswitch.conf(5), - passwd(5), chkgrp(8), - pw(8), yp(8)

-
-
-

-

A group file format appeared in - Version 6 AT&T UNIX. Support for comments - first appeared in FreeBSD 3.0.

-
-
- - - - - -
August 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man5/hesiod.conf.5 4.html b/static/freebsd/man5/hesiod.conf.5 4.html deleted file mode 100644 index 8cbb9ca6..00000000 --- a/static/freebsd/man5/hesiod.conf.5 4.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
HESIOD.CONF(5)File Formats ManualHESIOD.CONF(5)
-
-
-

-

hesiod.conf — - configuration file for the Hesiod library

-
-
-

-

The file hesiod.conf determines the - behavior of the Hesiod library. Blank lines and lines beginning with a - ‘#’ character are ignored. All other - lines should be of the form variable = - value, where the value should be - a single word. Possible variables and - values are:

-
-
-
Specifies the domain prefix used for Hesiod queries. In almost all cases, - you should specify “lhs=.ns”. The - default value if you do not specify an lhs value is no domain prefix, - which is not compatible with most Hesiod domains.
-
-
Specifies the default Hesiod domain; this value may be overridden by the - HES_DOMAIN environment variable. You must specify - an rhs line for the Hesiod library to work properly.
-
-
Specifies which DNS classes Hesiod should do lookups in. Possible values - are IN (the preferred class) and - HS (the deprecated class, still used by some - sites). You may specify both classes separated by a comma to try one class - first and then the other if no entry is available in the first class. The - default value of the classes variable is - “IN,HS”.
-
-
-
-

-

hesiod(3)

-
-
-

-

The default value for lhs should probably - be more reasonable.

-
-
- - - - - -
November 30, 1996FreeBSD 15.0
diff --git a/static/freebsd/man5/hosts.5 3.html b/static/freebsd/man5/hosts.5 3.html deleted file mode 100644 index 2e4a7b96..00000000 --- a/static/freebsd/man5/hosts.5 3.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
HOSTS(5)File Formats ManualHOSTS(5)
-
-
-

-

hosts — host name - data base

-
-
-

-

The hosts file contains information - regarding the known hosts on the network. It can be used in conjunction with - DNS, and the NIS maps `hosts.byaddr' and `hosts.byname', as controlled by - nsswitch.conf(5). For each host a single line should be - present with the following information:

-
-
Internet address
-official host name
-aliases
-
-

Items are separated by any number of blanks and/or tab characters. - A ``#'' indicates the beginning of a comment; characters up to the end of - the line are not interpreted by routines which search the file.

-

This file provides a backup used when the name server is not - running. For the name server, it is suggested that only a few addresses be - included in this file. These include addresses for the local interfaces that - ifconfig(8) needs at boot time and a few machines on the - local network.

-

Network addresses are specified in either the conventional ``.'' - (dot) notation for IPv4 or colon hexadecimal notation for IPv6, as - understood by the inet_pton(3) routine from the Internet - address manipulation library, inet(3). Host names may - contain any printable character other than a field delimiter, newline, or - comment character.

-
-
-

-
-
/etc/hosts
-
The hosts file resides in - /etc.
-
-
-
-

-

gethostbyname(3), inet(3), - nsswitch.conf(5), ifconfig(8)

-
-
-

-

The hosts file format appeared in - 4.1cBSD.

-
-
- - - - - -
September 15, 2022FreeBSD 15.0
diff --git a/static/freebsd/man5/hosts.equiv.5 3.html b/static/freebsd/man5/hosts.equiv.5 3.html deleted file mode 100644 index 74ecd989..00000000 --- a/static/freebsd/man5/hosts.equiv.5 3.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - -
HOSTS.EQUIV(5)File Formats ManualHOSTS.EQUIV(5)
-
-
-

-

hosts.equiv, - rhosts — trusted remote host - and user name data base

-
-
-

-

The hosts.equiv and - .rhosts files contain information regarding trusted - hosts and users on the network. For each host a single line should be - present with the following information:

-

simple

-
-
hostname [username]
-
-

or the more verbose

-
-
[+-][hostname|@netgroup] [[+-][username|@netgroup]]
-
-

A “@” indicates a host by netgroup or user by - netgroup. A single “+” matches all hosts or users. A host name - with a leading “-” will reject all matching hosts and all - their users. A user name with leading “-” will reject all - matching users from matching hosts.

-

Items are separated by any number of blanks and/or tab characters. - A “#” indicates the beginning of a comment; characters up to - the end of the line are not interpreted by routines which search the - file.

-

Host names are specified in the conventional Internet DNS - dotted-domains “.” (dot) notation using the - inet_addr(3) routine from the Internet address - manipulation library, inet(3). Host names may contain any - printable character other than a field delimiter, newline, or comment - character.

-

For security reasons, a user's .rhosts - file will be ignored if it is not a regular file, or if it is not owned by - the user, or if it is writable by anyone other than the user.

-
-
-

-
-
/etc/hosts.equiv
-
The hosts.equiv file resides in - /etc.
-
$HOME/.rhosts
-
.rhosts file resides in - $HOME.
-
-
-
-

-
bar.com foo
-

Trust user “foo” from host - “bar.com”.

-

-
+@allclient
-

Trust all hosts from netgroup “allclient”.

-

-
+@allclient -@dau
-

Trust all hosts from netgroup “allclient” and their - users except users from netgroup “dau”.

-
-
-

-

gethostbyname(3), inet(3), - innetgr(3), ruserok(3), - netgroup(5), ifconfig(8), - yp(8)

-
-
-

-

This manual page is incomplete. For more information read the - source in src/lib/libc/net/rcmd.c or the SunOS - manual page.

-
-
- - - - - -
April 23, 2026FreeBSD 15.0
diff --git a/static/freebsd/man5/hosts.lpd.5 4.html b/static/freebsd/man5/hosts.lpd.5 4.html deleted file mode 100644 index 953da126..00000000 --- a/static/freebsd/man5/hosts.lpd.5 4.html +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - -
HOSTS.LPD(5)File Formats ManualHOSTS.LPD(5)
-
-
-

-

hosts.lpd — - trusted hosts that may use local print services

-
-
-

-

The hosts.lpd file contains a list of - hostnames or IP addresses that are allowed to use your local print services. - List every hostname or IP address on a line itself.

-

If you want to allow access for any and all host, you can usually - use the NIS netgroups feature to do this by adding a line with a single - ‘+’ character.

-
-
-

-
-
/etc/hosts.lpd
-
The hosts.lpd file resides in - /etc.
-
-
-
-

-

printcap(5), lpd(8)

-
-
- - - - - -
June 1, 1996FreeBSD 15.0
diff --git a/static/freebsd/man5/intro.5 4.html b/static/freebsd/man5/intro.5 4.html deleted file mode 100644 index 13d27fd1..00000000 --- a/static/freebsd/man5/intro.5 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
INTRO(5)File Formats ManualINTRO(5)
-
-
-

-

intro — - introduction to file formats

-
-
-

-

This section contains information about the file formats which - comprise most data structures in the BSD - environment, including:

-

-
    -
  • ascii(7) configuration and resource files
    • -
  • system binary file and stream structures
    • -
  • composition of database files
    • -
-
-
-

-
-
/etc/
-
base system software configuration files
-
/usr/local/etc/
-
locally installed software configuration files
-
-
-
-

-

apropos(1), intro(1), - hier(7), intro(8)

-
-
-

-

The intro(5) manual page first appeared in - FreeBSD 2.2.

-
-
- - - - - -
November 17, 2024FreeBSD 15.0
diff --git a/static/freebsd/man5/libmap.conf.5 3.html b/static/freebsd/man5/libmap.conf.5 3.html deleted file mode 100644 index 3b0b78b8..00000000 --- a/static/freebsd/man5/libmap.conf.5 3.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - -
LIBMAP.CONF(5)File Formats ManualLIBMAP.CONF(5)
-
-
-

-

libmap.conf — - configuration file for dynamic object dependency - mapping

-
-
-

-

The libmap functionality of - ld-elf.so.1(1) allows dynamic object dependencies to be - mapped to arbitrary names.

-

Each line in /etc/libmap.conf can have one - of five forms:

-
-
origin target
-
Whenever a dependency on origin is encountered while - loading a dynamic object, use target instead of - searching for origin in the normal library search - paths.
-
path1 path2
-
When iterating through a library search path, replace any element that - matches path1 exactly with - path2.
-
[constraint]
-
Apply constraint to all subsequent mappings until - the next constraint line or the end of the file. See the - Constraints section for - details.
-
- file
-
Parse the contents of file before continuing with - the current file. Nesting depth is limited only by available memory, but - each file encountered is processed only once, and loops are silently - ignored.
-
- dir
-
Recurse through dir and parse the contents of any - file that ends in .conf before continuing with the - current file. Nesting depth is limited only by available memory, but each - directory or file encountered is processed only once, and loops are - silently ignored.
-
-
-

-

Constrained mappings only apply when processing binaries or - libraries that satisfy the constraint. There are three types of - constraints:

-
-
Exact
-
The constraint is matched literally so that only an executable with an - identical fully qualified pathname will satisfy the constraint. This means - that the executable /usr/bin/foo will not satisfy - the constraint [/usr/bin/./foo], and vice-versa. - This is the default constraint type.
-
Basename
-
A constraint with no path is matched against the basename of the - executable. For instance, the constraint [foo] - will match /bin/foo, - /usr/local/sbin/foo, or any other executable named - foo, no matter what directory it is in.
-
Directory
-
A constraint with a trailing slash is satisfied if the full pathname - begins with the constraint string. For instance, the constraint - [/usr/bin/] will match any executable with a path - starting with /usr/bin/.
-
-

Note that the constraints are matched against the path that was - passed as the first argument to whichever exec(3) function - was used to execute the binary in question. Most programs executed from a - shell are run without a full path, via execvp(3) or - similar, so the basename constraint type is the most useful.

-

-
WARNING! Constraints apply to all mappings until the next - constraint or the end of the file. Hence, unconstrained mappings must be - placed at the top of the file.
-
-
-

-

On 64-bit architectures that provide 32-bit binary compatibility, - the mappings in /etc/libmap.conf apply only to - 64-bit binaries. Mappings for 32-bit binaries must be placed in - /etc/libmap32.conf.

-
-
-
-

-
-
/etc/libmap.conf
-
The libmap configuration file.
-
/etc/libmap32.conf
-
The libmap configuration file for 32-bit binaries on 64-bit system.
-
-
-
-

-
-
#
-# origin		target
-#
-libc_r.so.6		libpthread.so.2	# Everything that uses 'libc_r'
-libc_r.so		libpthread.so	# now uses 'libpthread'
-
-[/tmp/mplayer]		# Test version of mplayer uses libc_r
-libpthread.so.2		libc_r.so.6
-libpthread.so		libc_r.so
-
-[/usr/local/jdk1.4.1/]	# All Java 1.4.1 programs use libthr
-			# This works because "javavms" executes
-			# programs with the full pathname
-libpthread.so.2		libthr.so.2
-libpthread.so		libthr.so
-
-# Glue for Linux-only EPSON printer .so to be loaded into cups, etc.
-[/usr/local/lib/pips/libsc80c.so]
-libc.so.6		pluginwrapper/pips.so
-libdl.so.2		pluginwrapper/pips.so
-
-
-
-

-

ldd(1), rtld(1)

-
-
-

-

The libmap mechanism first appeared in - FreeBSD 5.1.

-
-
-

-

This manual page was written by Matthew N. - Dodd - <winter@jurai.net> - and extensively rewritten by Dag-Erling - Smørgrav - <des@FreeBSD.org>.

-
-
- - - - - -
September 16, 2013FreeBSD 15.0
diff --git a/static/freebsd/man5/link.5 3.html b/static/freebsd/man5/link.5 3.html deleted file mode 100644 index 8155158a..00000000 --- a/static/freebsd/man5/link.5 3.html +++ /dev/null @@ -1,493 +0,0 @@ - - - - - - -
LINK(5)File Formats ManualLINK(5)
-
-
-

-

link — dynamic - loader and link editor interface

-
-
-

-

#include - <sys/types.h> -
- #include <nlist.h> -
- #include <link.h>

-
-
-

-

The include file - <link.h> declares several - structures that are present in dynamically linked programs and libraries. - The structures define the interface between several components of the - link-editor and loader mechanism. The layout of a number of these structures - within the binaries resembles the a.out format in many places as it serves - such similar functions as symbol definitions (including the accompanying - string table) and relocation records needed to resolve references to - external entities. It also records a number of data structures unique to the - dynamic loading and linking process. These include references to other - objects that are required to complete the link-editing process and - indirection tables to facilitate - (PIC for short) to improve sharing of code pages - among different processes. The collection of data structures described here - will be referred to as the - and is embedded in the standard text and - data segments of the dynamically linked program or shared object image as - the existing a.out(5) format offers no room for it - elsewhere.

-

Several utilities cooperate to ensure that the task of getting a - program ready to run can complete successfully in a way that optimizes the - use of system resources. The compiler emits PIC code from which shared - libraries can be built by ld(1). The compiler also - includes size information of any initialized data items through the .size - assembler directive. PIC code differs from conventional code in that it - accesses data variables through an indirection table, the Global Offset - Table, by convention accessible by the reserved name - _GLOBAL_OFFSET_TABLE_. The exact mechanism used for - this is machine dependent, usually a machine register is reserved for the - purpose. The rational behind this construct is to generate code that is - independent of the actual load address. Only the values contained in the - Global Offset Table may need updating at run-time depending on the load - addresses of the various shared objects in the address space.

-

Likewise, procedure calls to globally defined functions are - redirected through the Procedure Linkage Table (PLT) residing in the data - segment of the core image. Again, this is done to avoid run-time - modifications to the text segment.

-

The linker-editor allocates the Global Offset Table - and Procedure Linkage Table when combining PIC object files into an image - suitable for mapping into the process address space. It also collects all - symbols that may be needed by the run-time link-editor and stores these - along with the image's text and data bits. Another reserved symbol, - is used - to indicate the presence of the run-time linker structures. Whenever - _DYNAMIC is relocated to 0, there is no need to invoke the run-time - link-editor. If this symbol is non-zero, it points at a data structure from - which the location of the necessary relocation- and symbol information can - be derived. This is most notably used by the start-up module, - . The - _DYNAMIC structure is conventionally located at the start of the data - segment of the image to which it pertains.

-
-
-

-

The data structures supporting dynamic linking and run-time - relocation reside both in the text and data segments of the image they apply - to. The text segments contain read-only data such as symbols descriptions - and names, while the data segments contain the tables that need to be - modified by during the relocation process.

-

The _DYNAMIC symbol references a _dynamic - structure:

-
-
struct	_dynamic {
-	int	d_version;
-	struct 	so_debug *d_debug;
-	union {
-		struct section_dispatch_table *d_sdt;
-	} d_un;
-	struct  ld_entry *d_entry;
-};
-
-
-
d_version
-
This field provides for different versions of the dynamic linking - implementation. The current version numbers understood by - ld(1) and ld.so(1) are - , which is used by the SunOS 4.x releases, and - , which has been in use since FreeBSD - 1.1.
-
d_un
-
Refers to a - - dependent data structure.
-
so_debug
-
this field provides debuggers with a hook to access symbol tables of - shared objects loaded as a result of the actions of the run-time - link-editor.
-
-

The section_dispatch_table structure is the - main “dispatcher” table, containing offsets into the image's - segments where various symbol and relocation information is located.

-
-
struct section_dispatch_table {
-	struct	so_map *sdt_loaded;
-	long	sdt_sods;
-	long	sdt_filler1;
-	long	sdt_got;
-	long	sdt_plt;
-	long	sdt_rel;
-	long	sdt_hash;
-	long	sdt_nzlist;
-	long	sdt_filler2;
-	long	sdt_buckets;
-	long	sdt_strings;
-	long	sdt_str_sz;
-	long	sdt_text_sz;
-	long	sdt_plt_sz;
-};
-
-
-
sdt_loaded
-
A pointer to the first link map loaded (see below). This field is set by - ld.so
-
sdt_sods
-
The start of a (linked) list of shared object descriptors needed by - object.
-
sdt_filler1
-
Deprecated (used by SunOS to specify library search rules).
-
sdt_got
-
The location of the Global Offset Table within this image.
-
sdt_plt
-
The location of the Procedure Linkage Table within this image.
-
sdt_rel
-
The location of an array of relocation_info - structures (see a.out(5)) specifying run-time - relocations.
-
sdt_hash
-
The location of the hash table for fast symbol lookup in this object's - symbol table.
-
sdt_nzlist
-
The location of the symbol table.
-
sdt_filler2
-
Currently unused.
-
sdt_buckets
-
The number of buckets in sdt_hash
-
sdt_strings
-
The location of the symbol string table that goes with - sdt_nzlist.
-
sdt_str_sz
-
The size of the string table.
-
sdt_text_sz
-
The size of the object's text segment.
-
sdt_plt_sz
-
The size of the Procedure Linkage Table.
-
-

A sod structure describes a shared object - that is needed to complete the link edit process of the object containing - it. A list of such objects (chained through sod_next) - is pointed at by the sdt_sods in the - section_dispatch_table structure.

-
-
struct sod {
-	long	sod_name;
-	u_int	sod_library : 1,
-		sod_reserved : 31;
-	short	sod_major;
-	short	sod_minor;
-	long	sod_next;
-};
-
-
-
sod_name
-
The offset in the text segment of a string describing this link - object.
-
sod_library
-
If set, sod_name specifies a library that is to be - searched for by ld.so. The path name is obtained - by searching a set of directories (see also ldconfig(8)) - for a shared object matching - . - If not set, sod_name should point at a full path - name for the desired shared object.
-
sod_major
-
Specifies the major version number of the shared object to load.
-
sod_minor
-
Specifies the preferred minor version number of the shared object to - load.
-
- -
-
struct so_map {
-	caddr_t	som_addr;
-	char 	*som_path;
-	struct	so_map *som_next;
-	struct	sod *som_sod;
-	caddr_t som_sodbase;
-	u_int	som_write : 1;
-	struct	_dynamic *som_dynamic;
-	caddr_t	som_spd;
-};
-
-
-
som_addr
-
The address at which the shared object associated with this link map has - been loaded.
-
som_path
-
The full path name of the loaded object.
-
som_next
-
Pointer to the next link map.
-
som_sod
-
The sod structure that was responsible for loading - this shared object.
-
som_sodbase
-
Tossed out in later versions of the run-time linker.
-
som_write
-
Set if (some portion of) this object's text segment is currently - writable.
-
som_dynamic
-
Pointer to this object's _dynamic structure.
-
som_spd
-
Hook for attaching private data maintained by the run-time - link-editor.
-
-

Symbol description with size. This is simply an - nlist structure with one field - (nz_size) added. Used to convey size information on - items in the data segment of shared objects. An array of these lives in the - shared object's text segment and is addressed by the - sdt_nzlist field of - section_dispatch_table.

-
-
struct nzlist {
-	struct nlist	nlist;
-	u_long		nz_size;
-#define nz_un		nlist.n_un
-#define nz_strx		nlist.n_un.n_strx
-#define nz_name		nlist.n_un.n_name
-#define nz_type		nlist.n_type
-#define nz_value	nlist.n_value
-#define nz_desc		nlist.n_desc
-#define nz_other	nlist.n_other
-};
-
-
-
nlist
-
(see nlist(3)).
-
nz_size
-
The size of the data represented by this symbol.
-
-

A hash table is included within the text segment of shared object - to facilitate quick lookup of symbols during run-time link-editing. The - sdt_hash field of the - section_dispatch_table structure points at an array of - rrs_hash structures:

-
-
struct rrs_hash {
-	int	rh_symbolnum;		/* symbol number */
-	int	rh_next;		/* next hash entry */
-};
-
-
-
rh_symbolnum
-
The index of the symbol in the shared object's symbol table (as given by - the ld_symbols field).
-
rh_next
-
In case of collisions, this field is the offset of the next entry in this - hash table bucket. It is zero for the last bucket element.
-
-The rt_symbol structure is used to keep track of run-time - allocated commons and data items copied from shared objects. These items are - kept on linked list and is exported through the dd_cc - field in the so_debug structure (see below) for use by - debuggers. -
-
struct rt_symbol {
-	struct nzlist		*rt_sp;
-	struct rt_symbol	*rt_next;
-	struct rt_symbol	*rt_link;
-	caddr_t			rt_srcaddr;
-	struct so_map		*rt_smp;
-};
-
-
-
rt_sp
-
The symbol description.
-
rt_next
-
Virtual address of next rt_symbol.
-
rt_link
-
Next in hash bucket. Used internally by - ld.so.
-
rt_srcaddr
-
Location of the source of initialized data within a shared object.
-
rt_smp
-
The shared object which is the original source of the data that this - run-time symbol describes.
-
-

The so_debug structure is used by debuggers - to gain knowledge of any shared objects that have been loaded in the - process's address space as a result of run-time link-editing. Since the - run-time link-editor runs as a part of process initialization, a debugger - that wishes to access symbols from shared objects can only do so after the - link-editor has been called from crt0. A dynamically linked binary contains - a so_debug structure which can be located by means of - the d_debug field in - _dynamic.

-
-
struct 	so_debug {
-	int	dd_version;
-	int	dd_in_debugger;
-	int	dd_sym_loaded;
-	char    *dd_bpt_addr;
-	int	dd_bpt_shadow;
-	struct rt_symbol *dd_cc;
-};
-
-
-
dd_version
-
Version number of this interface.
-
dd_in_debugger
-
Set by the debugger to indicate to the run-time linker that the program is - run under control of a debugger.
-
dd_sym_loaded
-
Set by the run-time linker whenever it adds symbols by loading shared - objects.
-
dd_bpt_addr
-
The address where a breakpoint will be set by the run-time linker to - divert control to the debugger. This address is determined by the start-up - module, crt0.o, to be some convenient place before - the call to _main.
-
dd_bpt_shadow
-
Contains the original instruction that was at - dd_bpt_addr. The debugger is expected to put this - instruction back before continuing the program.
-
dd_cc
-
A pointer to the linked list of run-time allocated symbols that the - debugger may be interested in.
-
-

The - - structure defines a set of service routines within - ld.so.

-
-
struct ld_entry {
-	void	*(*dlopen)(char *, int);
-	int	(*dlclose)(void *);
-	void	*(*dlsym)(void *, char *);
-	char	*(*dlerror)(void);
-};
-
-

The crt_ldso structure defines the interface - between the start-up code in crt0 and ld.so.

-
-
struct crt_ldso {
-	int		crt_ba;
-	int		crt_dzfd;
-	int		crt_ldfd;
-	struct _dynamic	*crt_dp;
-	char		**crt_ep;
-	caddr_t		crt_bp;
-	char		*crt_prog;
-	char		*crt_ldso;
-	struct ld_entry	*crt_ldentry;
-};
-#define CRT_VERSION_SUN		1
-#define CRT_VERSION_BSD_2	2
-#define CRT_VERSION_BSD_3	3
-#define	CRT_VERSION_BSD_4	4
-
-
-
crt_ba
-
The virtual address at which ld.so was loaded by - crt0.
-
crt_dzfd
-
On SunOS systems, this field contains an open file descriptor to - “/dev/zero” used to get demand paged - zeroed pages. On FreeBSD systems it contains - -1.
-
crt_ldfd
-
Contains an open file descriptor that was used by crt0 to load - ld.so.
-
crt_dp
-
A pointer to main's _dynamic structure.
-
crt_ep
-
A pointer to the environment strings.
-
crt_bp
-
The address at which a breakpoint will be placed by the run-time linker if - the main program is run by a debugger. See - so_debug
-
crt_prog
-
The name of the main program as determined by crt0 (CRT_VERSION_BSD3 - only).
-
crt_ldso
-
The path of the run-time linker as mapped by crt0 (CRT_VERSION_BSD4 - only).
-
-

The hints_header and - hints_bucket structures define the layout of the - library hints, normally found in - “/var/run/ld.so.hints”, which is used - by ld.so to quickly locate the shared object images - in the file system. The organization of the hints file is not unlike that of - an “a.out” object file, in that it contains a header - determining the offset and size of a table of fixed sized hash buckets and a - common string pool.

-
-
struct hints_header {
-	long		hh_magic;
-#define HH_MAGIC	011421044151
-	long		hh_version;
-#define LD_HINTS_VERSION_1	1
-	long		hh_hashtab;
-	long		hh_nbucket;
-	long		hh_strtab;
-	long		hh_strtab_sz;
-	long		hh_ehints;
-};
-
-
-
hh_magic
-
Hints file magic number.
-
hh_version
-
Interface version number.
-
hh_hashtab
-
Offset of hash table.
-
hh_strtab
-
Offset of string table.
-
hh_strtab_sz
-
Size of strings.
-
hh_ehints
-
Maximum usable offset in hints file.
-
-
-
/*
- * Hash table element in hints file.
- */
-struct hints_bucket {
-	int		hi_namex;
-	int		hi_pathx;
-	int		hi_dewey[MAXDEWEY];
-	int		hi_ndewey;
-#define hi_major hi_dewey[0]
-#define hi_minor hi_dewey[1]
-	int		hi_next;
-};
-
-
-
hi_namex
-
Index of the string identifying the library.
-
hi_pathx
-
Index of the string representing the full path name of the library.
-
hi_dewey
-
The version numbers of the shared library.
-
hi_ndewey
-
The number of valid entries in hi_dewey.
-
hi_next
-
Next bucket in case of hashing collisions.
-
-
-
-

-

Only the (GNU) C compiler currently supports the creation of - shared libraries. Other programming languages cannot be used.

-
-
- - - - - -
October 23, 1993FreeBSD 15.0
diff --git a/static/freebsd/man5/mailer.conf.5 3.html b/static/freebsd/man5/mailer.conf.5 3.html deleted file mode 100644 index 3957d277..00000000 --- a/static/freebsd/man5/mailer.conf.5 3.html +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - -
MAILER.CONF(5)File Formats ManualMAILER.CONF(5)
-
-
-

-

mailer.conf — - configuration file for - mailwrapper(8)

-
-
-

-

The file /etc/mail/mailer.conf contains a - series of lines of the form

-

name program - [arguments ...]

-

The first word of each line is the name of a - program invoking mailwrapper(8). (For example, on a - typical system /usr/sbin/sendmail would be a - symbolic link to mailwrapper(8), as would - newaliases(1) and mailq(1). Thus, - name might be - “sendmail” or - “newaliases” etc.)

-

The second word of each line is the name of the - program to actually execute when the first name is - invoked.

-

The further arguments, if any, are passed to - the program, followed by the arguments - mailwrapper(8) was called with.

-

The file may also contain comment lines, denoted by a - ‘#’ mark in the first column of any - line.

-
-
-

-
-
/etc/mail/mailer.conf
-
 
-
-
-
-

-

This example shows how to set up - mailer.conf to invoke the traditional - sendmail(8) program:

-
-
# Execute the "real" sendmail program located in
-# /usr/libexec/sendmail/sendmail
-sendmail	/usr/libexec/sendmail/sendmail
-mailq		/usr/libexec/sendmail/sendmail
-newaliases	/usr/libexec/sendmail/sendmail
-
-

Using Postfix (from ports) to replace - sendmail(8):

-
-
# Emulate sendmail using postfix
-sendmail	/usr/local/sbin/sendmail
-mailq		/usr/local/sbin/sendmail
-newaliases	/usr/local/sbin/sendmail
-
-

Using Exim (from ports) to replace - sendmail(8):

-
-
# Emulate sendmail using exim
-sendmail	/usr/local/sbin/exim
-mailq		/usr/local/sbin/exim -bp
-newaliases	/usr/bin/true
-rmail		/usr/local/sbin/exim -i -oee
-
-

Using mini_sendmail (from ports) to - replace sendmail(8):

-
-
# Send outgoing mail to a smart relay using mini_sendmail
-sendmail	/usr/local/bin/mini_sendmail -srelayhost
-
-

Using dma(8) to replace - sendmail(8):

-
-
# Execute dma instead of sendmail
-sendmail	/usr/libexec/dma
-mailq		/usr/libexec/dma
-newaliases	/usr/libexec/dma
-rmail		/usr/libexec/dma
-
-
-
-

-

mail(1), mailq(1), - newaliases(1), dma(8), - mailwrapper(8), sendmail(8)

-

postfix(1) - (ports/mail/postfix), dma(8) - (ports/mail/dma), exim(8) - (ports/mail/exim), - mini_sendmail(8) - (ports/mail/mini_sendmail)

-
-
-

-

mailer.conf appeared in - NetBSD 1.4.

-
-
-

-

Perry E. Metzger - <perry@piermont.com>

-
-
-

-

The entire reason this program exists is a crock. Instead, a - command for how to submit mail should be standardized, and all the - "behave differently if invoked with a different name" behavior of - things like mailq(1) should go away.

-
-
- - - - - -
December 26, 2017FreeBSD 15.0
diff --git a/static/freebsd/man5/make.conf.5 3.html b/static/freebsd/man5/make.conf.5 3.html deleted file mode 100644 index 1e631072..00000000 --- a/static/freebsd/man5/make.conf.5 3.html +++ /dev/null @@ -1,468 +0,0 @@ - - - - - - -
MAKE.CONF(5)File Formats ManualMAKE.CONF(5)
-
-
-

-

make.conf — system - build information

-
-
-

-

The file make.conf contains system-wide - settings that will apply to every build using make(1) and - the standard sys.mk file. This is achieved as - follows: make(1) processes the system makefile - sys.mk before any other file by default, and - sys.mk includes - make.conf.

-

The file make.conf uses the standard - makefile syntax. However, make.conf should not - specify any dependencies to make(1). Instead, - make.conf is to set make(1) - variables that control the actions of other makefiles.

-

The default location of make.conf is - /etc/make.conf, though an alternative location can - be specified in the make(1) variable - __MAKE_CONF. You may need to override the location of - make.conf if the system-wide settings are not - suitable for a particular build. For instance, setting - __MAKE_CONF to /dev/null - effectively resets all build controls to their defaults.

-

The primary purpose of make.conf is to - control the compilation of the FreeBSD sources, - documentation, and ported applications, which are usually found in - /usr/src, /usr/doc, and - /usr/ports. As a rule, the system administrator - creates make.conf when the values of certain control - variables need to be changed from their defaults.

-

The system build procedures occur in four broad areas: the world, - the kernel, documentation and ports. Variables set in - make.conf may be applicable in one, two, or all four - of these areas. In addition, control variables can be specified for a - particular build via the -D option of - make(1) or in environ(7). In the case of - world and kernel builds it is possible to put these variables into - src.conf(5) instead of make.conf. - This way the environment for documentation and ports builds is not polluted - by unrelated variables.

-

The following lists provide a name and short description for each - variable you can use during the indicated builds. The values of variables - flagged as bool are ignored; the variable being set at - all (even to “FALSE” or - “NO”) causes it to be treated as if it - were set.

-

The following list provides a name and short description for - variables that are used for all builds, or are used by the - makefiles for things other than builds.

-
-
ALWAYS_CHECK_MAKE
-
(bool) Instructs the top-level makefile in the - source tree (normally /usr/src) to always check if - make(1) is up-to-date. Normally this is only done for - the world and buildworld targets to handle upgrades from older versions of - FreeBSD.
-
CFLAGS
-
(str) Controls the compiler setting when compiling C - code. Optimization levels other than -O and - -O2 are not supported.
-
CPUTYPE
-
(str) Controls which processor should be targeted - for generated code. This controls processor-specific optimizations in - certain code (currently only OpenSSL) as well as modifying the value of - CFLAGS and COPTFLAGS to - contain the appropriate optimization directive to cc(1). - To set the CPUTYPE value, use - “?=” instead of - “=” so that it can be overridden by - make(1) targets. The automatic setting of - CFLAGS may be overridden using the - NO_CPU_CFLAGS variable. Refer to - /usr/share/examples/etc/make.conf for a list of - recognized CPUTYPE options.
-
CXXFLAGS
-
(str) Controls the compiler settings when compiling - C++ code. CXXFLAGS is initially set to the value of - CFLAGS. If you want to add to the - CXXFLAGS value, use - “+=” instead of - “=”.
-
DTC
-
(str) Select the compiler for DTS (Device Tree - Syntax) file. DTC is initially set to the value of - dtc
-
INSTALL
-
(str) the default install command. To install only - files for which the target differs or does not exist, use -
- 
INSTALL+= -C
-
- Note that some makefiles (including those in - /usr/share/mk) may hardcode options for the - supplied install command.
-
LOCAL_DIRS
-
(str) List any directories that should be entered - when doing make's in /usr/src in this - variable.
-
MAKE_SHELL
-
(str) Controls the shell used internally by - make(1) to process the command scripts in makefiles. - sh(1), ksh(1), and - csh(1) all currently supported. -

-
MAKE_SHELL?=sh
-
- -
(str) Set this to - “-L” to cause - mtree(8) to follow symlinks.
-
NO_CPU_CFLAGS
-
(str) Setting this variable will prevent CPU - specific compiler flags from being automatically added to - CFLAGS during compile time.
-
-
-

-

The following list provides a name and short description for - variables that are only used doing a kernel build:

-
-
BOOTWAIT
-
(int) Controls the amount of time the kernel waits - for a console keypress before booting the default kernel. The value is - approximately milliseconds. Keypresses are accepted by the BIOS before - booting from disk, making it possible to give custom boot parameters even - when this is set to 0.
-
COPTFLAGS
-
(str) Controls the compiler settings when building - the kernel. Optimization levels above [-O - (-O2, ...)] are not - guaranteed to work.
-
KERNCONF
-
(str) Controls which kernel configurations will be - built by “${MAKE} buildkernel” and - installed by “${MAKE} - installkernel”. For example, -
- 
KERNCONF=MINE DEBUG GENERIC OTHERMACHINE
-
-

will build the kernels specified by the config files - MINE, DEBUG, - GENERIC, and - OTHERMACHINE, and install the kernel specified - by the config file MINE. It defaults to - GENERIC.

-
-
MODULES_OVERRIDE
-
(str) Set to a list of modules to build instead of - all of them.
-
NO_KERNELCLEAN
-
(bool) Set this to skip running - “${MAKE} clean” during - “${MAKE} buildkernel”.
-
NO_KERNELCONFIG
-
(bool) Set this to skip running - config(8) during “${MAKE} - buildkernel”.
-
NO_KERNELOBJ
-
(bool) Set this to skip running - “${MAKE} obj” during - “${MAKE} buildkernel”.
-
NO_MODULES
-
(bool) Set to not build modules with the - kernel.
-
PORTS_MODULES
-
Set this to the list of ports you wish to rebuild every time the kernel is - built.
-
WITHOUT_MODULES
-
(str) Set to a list of modules to exclude from the - build. This provides a somewhat easier way to exclude modules you are - certain you will never need than specifying - MODULES_OVERRIDE. This is applied - - MODULES_OVERRIDE.
-
-
-
-

-

The following list provides a name and short description for - variables that are used during the world build:

-
-
BOOT_COMCONSOLE_PORT
-
(str) The port address to use for the console if the - boot blocks have been configured to use a serial console instead of the - keyboard/video card.
-
BOOT_COMCONSOLE_SPEED
-
(int) The baud rate to use for the console if the - boot blocks have been configured to use a serial console instead of the - keyboard/video card.
-
BOOT_PXELDR_ALWAYS_SERIAL
-
(bool) Compile in the code into - pxeboot(8) that forces the use of a serial console. This - is analogous to the -h option in - boot(8) blocks.
-
BOOT_PXELDR_PROBE_KEYBOARD
-
(bool) Compile in the code into - pxeboot(8) that probes the keyboard. If no keyboard is - found, boot with the dual console configuration. This is analogous to the - -D option in boot(8) - blocks.
-
ENABLE_SUID_K5SU
-
(bool) Set this if you wish to use the ksu utility. - Otherwise, it will be installed without the set-user-ID bit set.
-
ENABLE_SUID_NEWGRP
-
(bool) Set this to install - newgrp(1) with the set-user-ID bit set. Otherwise, - newgrp(1) will not be able to change users' groups.
-
LOADER_TFTP_SUPPORT
-
(bool) By default the pxeboot(8) - loader retrieves the kernel via NFS. Defining this and recompiling - /usr/src/stand will cause it to retrieve the - kernel via TFTP. This allows pxeboot(8) to load a custom - BOOTP diskless kernel yet still mount the server's - / rather than load the server's kernel.
-
LOADER_FIREWIRE_SUPPORT
-
(bool) Defining this and recompiling - /usr/src/stand/i386 will add - dcons(4) console driver to loader(8) - and allow access over FireWire(IEEE1394) using - dconschat(8). Currently, only i386 and amd64 are - supported.
-
MAN_ARCH
-
(str) Space-delimited list of one or more MACHINE - and/or MACHINE_ARCH values for which section 4 man pages will be - installed. The special value ‘all’ installs all available - architectures. It is also the default value.
-
MODULES_WITH_WORLD
-
(bool) Set to build modules with the system instead - of the kernel.
-
NO_CLEAN
-
(bool) Set this to disable cleaning during - “make buildworld”. This should not - be set unless you know what you are doing.
-
NO_CLEANDIR
-
(bool) Set this to run - “${MAKE} clean” instead of - “${MAKE} cleandir”.
-
WITH_MANCOMPRESS
-
(defined) Set to install manual pages - compressed.
-
WITHOUT_MANCOMPRESS
-
(defined) Set to install manual pages - uncompressed.
-
NO_SHARE
-
(bool) Set to not build in the - share subdir.
-
NO_SHARED
-
(bool) Set to build /bin and - /sbin statically linked, this can be bad. If set, - every utility that uses bsd.prog.mk will be linked - statically.
-
PKG_REPO_SIGNING_KEY
-
(str) Path to rsa private key passed to - pkg-repo(8) to sign packages created when building the - packages target, i.e.: pkgbase. The variable is - named the same in poudriere(8) so it will automatically - be picked up when building pkgbase with poudriere.
-
PPP_NO_NAT
-
(bool) Build ppp(8) without - support for network address translation (NAT).
-
PPP_NO_NETGRAPH
-
(bool) Set to build ppp(8) without - support for Netgraph.
-
PPP_NO_RADIUS
-
(bool) Set to build ppp(8) without - support for RADIUS.
-
PPP_NO_SUID
-
(bool) Set to disable the installation of - ppp(8) as a set-user-ID root program.
-
SENDMAIL_ADDITIONAL_MC
-
(str) Additional .mc files - which should be built into .cf files at build - time. The value should include the full path to the - .mc file(s), e.g., - /etc/mail/foo.mc, - /etc/mail/bar.mc.
-
SENDMAIL_ALIASES
-
(str) List of aliases(5) files to - rebuild when using /etc/mail/Makefile. The default - value is /etc/mail/aliases.
-
SENDMAIL_CFLAGS
-
(str) Flags to pass to the compile command when - building sendmail(8). The - SENDMAIL_* flags can be used to provide SASL support - with setting such as: -
- 
SENDMAIL_CFLAGS=-I/usr/local/include -DSASL
-SENDMAIL_LDFLAGS=-L/usr/local/lib
-SENDMAIL_LDADD=-lsasl
-
-
-
SENDMAIL_CF_DIR
-
(str) Override the default location for the - m4(1) configuration files used to build a - .cf file from a .mc - file.
-
SENDMAIL_DPADD
-
(str) Extra dependencies to add when building - sendmail(8).
-
SENDMAIL_LDADD
-
(str) Flags to add to the end of the - ld(1) command when building - sendmail(8).
-
SENDMAIL_LDFLAGS
-
(str) Flags to pass to the ld(1) - command when building sendmail(8).
-
SENDMAIL_M4_FLAGS
-
(str) Flags passed to m4(1) when - building a .cf file from a - .mc file.
-
SENDMAIL_MAP_PERMS
-
(str) Mode to use when generating alias and map - database files using /etc/mail/Makefile. The - default value is 0640.
-
SENDMAIL_MAP_SRC
-
(str) Additional maps to rebuild when using - /etc/mail/Makefile. The - access, bitdomain, - domaintable, - genericstable, - mailertable, uucpdomain, - and virtusertable maps are always rebuilt if they - exist.
-
SENDMAIL_MAP_TYPE
-
(str) Database map type to use when generating map - database files using /etc/mail/Makefile. The - default value is hash. The alternative is btree.
-
SENDMAIL_MC
-
(str) The default m4(1) - configuration file to use at install time. The value should include the - full path to the .mc file, e.g., - /etc/mail/myconfig.mc. Use with caution as a make - install will overwrite any existing - /etc/mail/sendmail.cf. Note that - SENDMAIL_CF is deprecated.
-
SENDMAIL_SET_USER_ID
-
(bool) If set, install sendmail(8) - as a set-user-ID root binary instead of a set-group-ID binary and do not - install /etc/mail/submit.{cf,mc}. Use of this flag - is not recommended and the alternative advice in - /etc/mail/README should be followed instead if at - all possible.
-
SENDMAIL_START_SCRIPT
-
(str) The script used by - /etc/mail/Makefile to start, stop, and restart - sendmail(8). The default value is - /etc/rc.d/sendmail.
-
SENDMAIL_SUBMIT_MC
-
(str) The default m4(1) - configuration file for mail submission to use at install time. The value - should include the full path to the .mc file, - e.g., /etc/mail/mysubmit.mc. Use with caution as a - make install will overwrite any existing - /etc/mail/submit.cf.
-
TOP_TABLE_SIZE
-
(int) top(1) uses a hash table for - the user names. The size of this hash can be tuned to match the number of - local users. The table size should be a prime number approximately twice - as large as the number of lines in /etc/passwd. - The default number is 20011.
-
WANT_FORCE_OPTIMIZATION_DOWNGRADE
-
(int) Causes the system compiler to be built such - that it forces high optimization levels to a lower one. - cc(1) -O2 and above is known to - trigger known optimizer bugs at various times. The value assigned is the - highest optimization value used.
-
-
-
-

-

The following list provides a name and short description for - variables that are used when building documentation.

-
-
DOC_LANG
-
(str) The list of languages to build and install - when building documentation in /usr/doc.
-
PRINTERDEVICE
-
(str) The default format for system documentation in - /usr/src/share/doc, depends on your printer. This - can be set to “ascii” for simple - printers, or “ps” for postscript or - graphics printers with a ghostscript filter, or both.
-
-
-
-

-

Several make variables can be set that affect the building of - ports. These variables and their effects are documented in - ports(7), ${PORTSDIR}/Mk/* and the - FreeBSD Porter's Handbook.

-
-
-
-

-
-
/etc/make.conf
-
 
-
/usr/doc/Makefile
-
 
-
/usr/ports/Makefile
-
 
-
/usr/share/examples/etc/make.conf
-
 
-
/usr/share/mk/sys.mk
-
 
-
/usr/src/Makefile
-
 
-
/usr/src/Makefile.inc1
-
 
-
-
-
-

-

cc(1), install(1), - make(1), src.conf(5), - style.Makefile(5), environ(7), - ports(7), sendmail(8)

-
-
-

-

The make.conf file appeared sometime - before FreeBSD 4.0.

-
-
-

-

This manual page was written by Mike W. - Meyer - <mwm@mired.org>.

-
-
-

-

Note, that MAKEOBJDIRPREFIX and - MAKEOBJDIR are environment variables and should not - be set in make.conf or as command line arguments to - make(1), but in make's environment.

-
-
-

-

This manual page may occasionally be out of date with respect to - the options currently available for use in - make.conf. Please check the - /usr/share/examples/etc/make.conf file for the - latest options which are available.

-
-
- - - - - -
November 15, 2022FreeBSD 15.0
diff --git a/static/freebsd/man5/moduli.5 3.html b/static/freebsd/man5/moduli.5 3.html deleted file mode 100644 index 75c76048..00000000 --- a/static/freebsd/man5/moduli.5 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
MODULI(5)File Formats ManualMODULI(5)
-
-
-

-

moduli — - Diffie-Hellman moduli

-
-
-

-

The /etc/ssh/moduli file contains prime - numbers and generators for use by sshd(8) in the - Diffie-Hellman Group Exchange key exchange method.

-

New moduli may be generated with - ssh-keygen(1) using a two-step process. An initial - pass, using ssh-keygen -G, - calculates numbers that are likely to be useful. A second - pass, using ssh-keygen -T, provides - a high degree of assurance that the numbers are prime and are safe for use - in Diffie-Hellman operations by sshd(8). This - moduli format is used as the output from each - pass.

-

The file consists of newline-separated records, one per modulus, - containing seven space-separated fields. These fields are as follows:

-
-
-
timestamp
-
The time that the modulus was last processed as YYYYMMDDHHMMSS.
-
type
-
Decimal number specifying the internal structure of the prime modulus. - Supported types are: -

-
-
0
-
Unknown, not tested.
-
2
-
"Safe" prime; (p-1)/2 is also prime.
-
4
-
Sophie Germain; 2p+1 is also prime.
-
-

Moduli candidates initially produced by - ssh-keygen(1) are Sophie Germain primes (type 4). - Further primality testing with ssh-keygen(1) produces - safe prime moduli (type 2) that are ready for use in - sshd(8). Other types are not used by OpenSSH.

-
-
tests
-
Decimal number indicating the type of primality tests that the number has - been subjected to represented as a bitmask of the following values: -

-
-
0x00
-
Not tested.
-
0x01
-
Composite number – not prime.
-
0x02
-
Sieve of Eratosthenes.
-
0x04
-
Probabilistic Miller-Rabin primality tests.
-
-

The ssh-keygen(1) moduli candidate - generation uses the Sieve of Eratosthenes (flag 0x02). Subsequent - ssh-keygen(1) primality tests are Miller-Rabin tests - (flag 0x04).

-
-
trials
-
Decimal number indicating the number of primality trials that have been - performed on the modulus.
-
size
-
Decimal number indicating the size of the prime in bits.
-
generator
-
The recommended generator for use with this modulus (hexadecimal).
-
modulus
-
The modulus itself in hexadecimal.
-
-
-

When performing Diffie-Hellman Group Exchange, - sshd(8) first estimates the size of the modulus required - to produce enough Diffie-Hellman output to sufficiently key the selected - symmetric cipher. sshd(8) then randomly selects a modulus - from /etc/ssh/moduli that best meets the size - requirement.

-
-
-

-

ssh-keygen(1), sshd(8)

-

Diffie-Hellman Group Exchange - for the Secure Shell (SSH) Transport Layer Protocol, - RFC 4419, 2006.

-
-
- - - - - -
July 19, 2012FreeBSD 15.0
diff --git a/static/freebsd/man5/motd.5 4.html b/static/freebsd/man5/motd.5 4.html deleted file mode 100644 index 0f47d19a..00000000 --- a/static/freebsd/man5/motd.5 4.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
MOTD(5)File Formats ManualMOTD(5)
-
-
-

-

motd — file - containing message(s) of the day

-
-
-

-

The file /var/run/motd is normally - displayed by login(1) after a user has logged in but - before the shell is run. It is generally used for important system-wide - announcements. During system startup, a line containing the kernel version - string is prepended to /etc/motd.template and the - contents are written to /var/run/motd.

-

/var/run/motd can be updated without a - system reboot by manually restarting the motd service after updating - /etc/motd.template:

-

-
service motd restart
-

Individual users may suppress the display of this file by creating - a file named “.hushlogin” in their - home directories or through login.conf(5).

-
-
-

-
-
/etc/motd
-
Symbolic link to /var/run/motd.
-
/etc/motd.template
-
The template file that system administrators can edit.
-
/var/run/motd
-
The message of the day.
-
$HOME/.hushlogin
-
Suppresses output of /var/run/motd.
-
-
-
-

-
-
FreeBSD 12.1-RELEASE (GENERIC) #0: Sun Dec 29 03:08:31 PST 2019
-
-/home is full.  Please cleanup your directories.
-
-
-
-

-

login(1), login.conf(5)

-
-
-

-

Prior to FreeBSD 13.0, - motd lived in /etc.

-
-
- - - - - -
December 14, 2024FreeBSD 15.0
diff --git a/static/freebsd/man5/mount.conf.5 3.html b/static/freebsd/man5/mount.conf.5 3.html deleted file mode 100644 index f1004644..00000000 --- a/static/freebsd/man5/mount.conf.5 3.html +++ /dev/null @@ -1,185 +0,0 @@ - - - - - - -
MOUNT.CONF(5)File Formats ManualMOUNT.CONF(5)
-
-
-

-

mount.conf — root - file system mount configuration file

-
-
-

-

/.mount.conf

-
-
-

-

During the bootup process, the FreeBSD - kernel will try to mount the root file system using the logic in the - () - function in src/sys/kern/vfs_mountroot.c. The root - mount logic can be described as follows:

-
    -
  1. The kernel will synthesize in memory a config - file with default directives for mounting the root file system. The logic - for this is in - ().
    2. -
  2. The kernel will first mount devfs(4) as the root file - system.
    3. -
  3. Next, the kernel will parse the in-memory config file created in step 1 - and try to mount the actual root file system. See - FILE FORMAT for the format of the - config file.
    4. -
  4. When the actual root file system is mounted, devfs(4) - will be re-mounted on the /dev directory.
    5. -
  5. If a /.mount.conf file does not exist in the root - file system which was just mounted, the root mount logic stops here.
    6. -
  6. If a /.mount.conf file exists in the root file - system which was just mounted, this file will be parsed, and the kernel - will use this new config file to try to re-mount the root file system. See - FILE FORMAT for the format of the - config file.
    7. -
  7. If the new root file system has a /.mount - directory, the old root file system will be re-mounted on - /.mount.
    8. -
  8. The root mount logic will go back to step 4.
    9. -
-

The root mount logic is recursive, and step 8 will be repeated as - long as each new root file system which is mounted has a - /.mount.conf file.

-
-
-

-

The kernel parses each line in .mount.conf - and then tries to perform the action specified on that line as soon as it is - parsed.

-
-
-
A line beginning with a # is a comment and is ignored.
-
-
The kernel will try to mount this in an operation equivalent to: -
- 
mount -t {FS} -o {OPTIONS} {MOUNTPOINT} /
-
-

If this is successfully mounted, further lines in - .mount.conf are ignored. If all lines in - .mount.conf have been processed and no root file - system has been successfully mounted, then the action specified by - .onfail is performed.

-
-
-
When the kernel processes this line, a - mountroot> command-line prompt is displayed. At - this prompt, the operator can enter the root mount.
-
- file
-
Create a memory backed md(4) virtual disk, using - file as the backing store.
-
- [panic|reboot|retry|continue]
-
If after parsing all the lines in .mount.conf the - kernel is unable to mount a root file system, the - .onfail directive tells the kernel what action to - perform.
-
- N
-
Before trying to mount a root file system, if the root mount device does - not exist, wait at most N seconds for the device to - appear before trying to mount it. If .timeout is - not specified, the default timeout is 3 seconds.
-
-
-
-

-

The following example .mount.conf will - direct the kernel to try mounting the root file system first as an ISO - CD9660 file system on /dev/cd0, then if that does - not work, as an ISO CD9660 file system on /dev/cd1, - and then if that does not work, as a UFS file system on - /dev/ada0s1a. If that does not work, a - mountroot> command-line prompt will be displayed - where the operator can manually enter the root file system to mount. Finally - if that does not work, the kernel will panic.

-
-
.onfail panic
-.timeout 3
-cd9660:/dev/cd0 ro
-.timeout 0
-cd9660:/dev/cd1 ro
-.timeout 3
-ufs:/dev/ada0s1a
-.ask
-
-

The following example .mount.conf will - direct the kernel to create a md(4) memory disk attached - to the file /data/OS-1.0.iso and then mount the ISO - CD9660 file system on the md device which was just created. The last line is - a comment which is ignored.

-
-
.timeout 3
-.md /data/OS-1.0.iso
-cd9600:/dev/md# ro
-# Can also use cd9660:/dev/md0 ro
-
-

The following example .mount.conf will - direct the kernel to create a md(4) memory disk attached - to the file /data/base.ufs.uzip and then mount the - UFS file system on the md uzip device which was just created by the - geom_uzip(4) driver.

-
-
.md /data/base.ufs.uzip
-ufs:/dev/md#.uzip ro
-# Can also use ufs:/dev/md0.uzip ro
-
-

The following example .mount.conf will - direct the kernel to do a unionfs mount on a directory - /jail/freebsd-8-stable which has a - chroot(2) environment.

-
-
.timeout 3
-unionfs:/jail/freebsd-8-stable
-
-
-
-

-

For each root file system which is mounted, a - /dev directory - exist - so that the root mount logic can properly re-mount - devfs(4). If this directory does not exist, the system may - hang during the bootup process.

-
-
-

-

nmount(2), md(4), - boot.config(5), fstab(5), - boot(8), loader(8), - mount(8)

-
-
-

-

The mount.conf file first appeared in - FreeBSD 9.0.

-
-
-

-

The root mount logic in the FreeBSD kernel - which parses /.mount.conf was written by - Marcel Moolenaar - <marcel@FreeBSD.org>. - This man page was written by Craig Rodrigues - <rodrigc@FreeBSD.org>.

-
-
- - - - - -
October 17, 2013FreeBSD 15.0
diff --git a/static/freebsd/man5/networks.5 4.html b/static/freebsd/man5/networks.5 4.html deleted file mode 100644 index 329d1a20..00000000 --- a/static/freebsd/man5/networks.5 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
NETWORKS(5)File Formats ManualNETWORKS(5)
-
-
-

-

networks — network - name data base

-
-
-

-

The networks file contains information - regarding the known networks which comprise the DARPA Internet. For each - network a single line should be present with the following information:

-
-
official network name
-network number
-aliases
-
-

Items are separated by any number of blanks and/or tab characters. - A ``#'' indicates the beginning of a comment; characters up to the end of - the line are not interpreted by routines which search the file. This file is - normally created from the official network data base maintained at the - Network Information Control Center (NIC), though local changes may be - required to bring it up to date regarding unofficial aliases and/or unknown - networks.

-

Network numbers may be specified in the conventional ``.'' (dot) - notation using the inet_network(3) routine from the - Internet address manipulation library, inet(3). Network - names may contain any printable character other than a field delimiter, - newline, or comment character.

-
-
-

-
-
/etc/networks
-
The networks file resides in - /etc.
-
-
-
-

-

getnetent(3)

-
-
-

-

The networks file format appeared in - 4.2BSD.

-
-
-

-

A name server should be used instead of a static file.

-
-
- - - - - -
June 5, 1993FreeBSD 15.0
diff --git a/static/freebsd/man5/nsmb.conf.5 3.html b/static/freebsd/man5/nsmb.conf.5 3.html deleted file mode 100644 index 9a525ae5..00000000 --- a/static/freebsd/man5/nsmb.conf.5 3.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - -
NSMB.CONF(5)File Formats ManualNSMB.CONF(5)
-
-
-

-

nsmb.conf — - configuration file for server message block (SMB1/CIFS) - requests

-
-
-

-

The nsmb.conf file contains information - about the computers, users, and shares or mount points for the SMB network - protocol.

-

The configuration files are loaded in the following order:

-

-
    -
  1. ~/.nsmbrc
    2. -
  2. /etc/nsmb.conf
    3. -
-

As a result, /etc/nsmb.conf settings - override those in ~/.nsmbrc.

-

The configuration hierarchy is made up of several sections, each - section containing a few or several lines of parameters and their assigned - values. Each of these sections must begin with a section name enclosed - within square brackets, similar to:

-

-
[section_name]
-

The end of each section is marked by either the start of a new - section, or by the abrupt ending of the file, commonly referred to as the - EOF. Each section may contain zero or more parameters such as:

-

-
[section_name]
-
key=value
-

where key represents a parameter name, and - value would be the parameter's assigned value.

-

The SMB library uses the following information for section - names:

-

-
-
-
[default]
-
-
[SERVER]
-
-
[SERVER:USER]
-
-
[SERVER:USER:SHARE]
-
-

Possible keywords may include:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SectionComment
A B C D
addr- + - -IP address of SMB server
charsets- + + +local:remote charset pair
nbns+ + - -address of NetBIOS name server (WINS)
nbscope+ + - -NetBIOS scope
nbtimeout+ + - -timeout for NetBIOS name servers
password- - + +plain text or simple encrypted password used to access the given - share
retry_count+ + - -number of retries before connection is marked as broken
timeout+ + - -SMB request timeout
workgroup+ + + +workgroup name
-
-
-

-
-
/etc/nsmb.conf
-
The default remote mount-point configuration file.
-
~/.nsmbrc
-
The user specific remote mount-point configuration file.
-
-
-
-

-

What follows is a sample configuration file which may, or may not - match your environment:

-
-
# Configuration file for example.com
-[default]
-workgroup=SALES
-# The 'FSERVER' is an NT server.
-[FSERVER]
-charsets=koi8-r:cp866
-addr=fserv.example.com
-# User specific data for FSERVER
-[FSERVER:MYUSER]
-password=$$16144562c293a0314e6e1
-
-

All lines which begin with the - ‘#’ character are comments and will - not be parsed. The “default” section - describes the default workgroup or domain, in this case - “SALES”. The next section depicted - here as “FSERVER”, defines a server - section and then assigns it a charset which is only required when Cyrillic - characters are not used. The hostname value, - “fserv.example.com”, is also assigned - in this section. “FSERVER:USER”, - defines the user settings and is useful for saving the password used during - a specific connection. The password may be plaintext or obfuscated using - simple encryption. The simple encrypted password starts with the `$$1' - symbols. Warning: the encryption function is very weak and intended only to - hide clear text passwords. If the use of simple encryption is desired, the - following command may be used on a password:

-
-
smbutil crypt
-
-
-
-

-

smbutil(1), mount_smbfs(8)

-
-
-

-

This manual page was written by Sergey - Osokin - <osa@FreeBSD.org> and - Tom Rhodes - <trhodes@FreeBSD.org>.

-
-
- - - - - -
November 2, 2018FreeBSD 15.0
diff --git a/static/freebsd/man5/nsswitch.conf.5 3.html b/static/freebsd/man5/nsswitch.conf.5 3.html deleted file mode 100644 index db072fdf..00000000 --- a/static/freebsd/man5/nsswitch.conf.5 3.html +++ /dev/null @@ -1,306 +0,0 @@ - - - - - - -
NSSWITCH.CONF(5)File Formats ManualNSSWITCH.CONF(5)
-
-
-

-

nsswitch.conf — - name-service switch configuration file

-
-
-

-

The nsswitch.conf file specifies how the - nsdispatch(3) (name-service switch dispatcher) routines in - the C library should operate.

-

The configuration file controls how a process looks up various - databases containing information regarding hosts, users (passwords), groups, - etc. Each database comes from a source (such as local files, DNS, NIS , and - cache), and the order to look up the sources is specified in - nsswitch.conf.

-

Each entry in nsswitch.conf consists of a - database name, and a space separated list of sources. Each source can have - an optional trailing criterion that determines whether the next listed - source is used, or the search terminates at the current source. Each - criterion consists of one or more status codes, and actions to take if that - status code occurs.

-
-

-

The following sources are implemented as part of the base - system:

-

-
-
-
-
files
-
Local files, such as /etc/hosts, and - /etc/passwd.
-
db
-
Local database.
-
dns
-
Internet Domain Name System. “hosts” and - ‘networks’ use - class entries, - all other databases use - class - (Hesiod) entries.
-
nis
-
NIS (formerly YP)
-
compat
-
support ‘+/-’ in the “passwd” and - “group” databases. If this is present, it must be the only - source for that entry.
-
cache
-
makes use of the nscd(8) daemon.
-
-

Additional sources might be provided by third party software.

-
-
-

-

The following databases are used by the following C library - functions:

-

-
-
-
-
group
-
getgrent(3), getgrent_r(3), - getgrgid_r(3), getgrnam_r(3), - setgrent(3), endgrent(3)
-
hosts
-
getaddrinfo(3), gethostbyaddr(3), - gethostbyaddr_r(3), gethostbyname(3), - gethostbyname2(3), gethostbyname_r(3), - getipnodebyaddr(3), - getipnodebyname(3)
-
networks
-
getnetbyaddr(3), getnetbyaddr_r(3), - getnetbyname(3), - getnetbyname_r(3)
-
passwd
-
getpwent(3), getpwent_r(3), - getpwnam_r(3), getpwuid_r(3), - setpwent(3), endpwent(3)
-
shells
-
getusershell(3)
-
services
-
getservent(3)
-
rpc
-
getrpcbyname(3), getrpcbynumber(3), - getrpcent(3)
-
proto
-
getprotobyname(3), - getprotobynumber(3), - getprotoent(3)
-
netgroup
-
getnetgrent(3), getnetgrent_r(3), - setnetgrent(3), endnetgrent(3), - innetgr(3)
-
-
-
-

-

The following status codes are available:

-

-
-
-
-
success
-
The requested entry was found.
-
notfound
-
The entry is not present at this source.
-
tryagain
-
The source is busy, and may respond to retries.
-
unavail
-
The source is not responding, or entry is corrupt.
-
-
-
-

-

For each of the status codes, one of two actions is possible:

-

-
-
-
-
continue
-
Try the next source
-
return
-
Return with the current result
-
-
-
-

-

A BNF description of the syntax of - nsswitch.conf is:

-

-
-
<entry>
-
::= <database> ":" [<source> - [<criteria>]]*
-
<criteria>
-
::= "[" <criterion>+ "]"
-
<criterion>
-
::= <status> "=" <action>
-
<status>
-
::= "success" | "notfound" | "unavail" | - "tryagain"
-
<action>
-
::= "return" | "continue"
-
-

Each entry starts on a new line in the file. A ‘#’ - delimits a comment to end of line. Blank lines are ignored. A - ‘\’ at the end of a line escapes the newline, and causes the - next line to be a continuation of the current line. All entries are - case-insensitive.

-

The default criteria is to return on “success”, and - continue on anything else (i.e, [success=return - notfound=continue unavail=continue tryagain=continue]).

-
-
-

-

You can enable caching for the particular database by specifying - “cache” in the nsswitch.conf file. It - should come after “files”, but before remote sources like - “nis”. You should also enable caching for this database in - nscd.conf(5). If for a particular query - “cache” source returns success, then no further sources are - queried. On the other hand, if there are no previously cached data, the - query result will be placed into the cache right after all other sources are - processed. Note that “cache” requires the - nscd(8) daemon to be running.

-
-
-

-

In historical multi-source implementations, the ‘+’ - and ‘-’ characters are used to specify the importing of user - password and group information from NIS . Although - nsswitch.conf provides alternative methods of - accessing distributed sources such as NIS , specifying a sole source of - “compat” will provide the historical behaviour.

-

An alternative source for the information accessed via - ‘+/-’ can be used by specifying “passwd_compat: - source”. “source” in this case can be - ‘dns’, ‘nis’, or any other source except for - ‘files’ and ‘compat’.

-
-
-

-

Historically, many of the databases had enumeration functions, - often of the form - (). - These made sense when the databases were in local files, but do not make - sense or have lesser relevance when there are possibly multiple sources, - each of an unknown size. The interfaces are still provided for - compatibility, but the source may not be able to provide complete entries, - or duplicate entries may be retrieved if multiple sources that contain - similar information are specified.

-

To ensure compatibility with previous and current implementations, - the “compat” source must appear alone for a given - database.

-
-
-

-

If, for any reason, nsswitch.conf does not - exist, or it has missing or corrupt entries, nsdispatch(3) - will default to an entry of “files” for the requested - database. Exceptions are:

-

-
-
-
-
group
-
compat
-
group_compat
-
nis
-
hosts
-
files dns
-
passwd
-
compat
-
passwd_compat
-
nis
-
services
-
compat
-
services_compat
-
nis
-
-
-
-
-

-
-
/etc/nsswitch.conf
-
The file nsswitch.conf resides in - /etc.
-
-
-
-

-

To lookup hosts in /etc/hosts , then in - cache, and then from the DNS, and lookup user information from NIS then - files, use:

-

-
-
hosts:
-
files cache dns
-
passwd:
-
nis [notfound=return] files
-
group:
-
nis [notfound=return] files
-
-

The criteria “[notfound=return]” sets a policy of - "if the user is notfound in nis, do not try files." This treats - nis as the authoritative source of information, except when the server is - down.

-
-
-

-

The nsswitch.conf file is parsed by each - program only once. Subsequent changes will not be applied until the program - is restarted.

-

If system got compiled with WITHOUT_NIS you - have to remove ‘nis’ entries.

-

FreeBSD's Standard - C Library (libc, -lc) provides stubs for compatibility with - NSS modules written for the GNU C Library nsswitch - interface. However, these stubs only support the use of the - “passwd” and - “group” databases.

-
-
-

-

nsdispatch(3), nscd.conf(5), - resolv.conf(5), nscd(8), - ypbind(8)

-
-
-

-

The nsswitch.conf file format first - appeared in FreeBSD 5.0. It was imported from the - NetBSD Project, where it appeared first in - NetBSD 1.4.

-
-
-

-

Luke Mewburn - <lukem@netbsd.org> - wrote this freely distributable name-service switch implementation, using - ideas from the ULTRIX svc.conf(5) and Solaris - nsswitch.conf(4) manual pages.

-
-
- - - - - -
September 6, 2020FreeBSD 15.0
diff --git a/static/freebsd/man5/os-release.5 3.html b/static/freebsd/man5/os-release.5 3.html deleted file mode 100644 index be3bfd31..00000000 --- a/static/freebsd/man5/os-release.5 3.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - -
OS-RELEASE(5)File Formats ManualOS-RELEASE(5)
-
-
-

-

os-release — file - describing the current OS and some of its attributes

-
-
-

-

The os-release file is a new-line - separated list of key value pairs. The syntax of this file is a reduced - sh(1) variable assignment with the following - restrictions:

-
    -
  • Strings cannot be concatenated together
    • -
  • No variable expansion is done
    • -
  • All shell special characters must be quoted as documented in - sh(1)
    • -
  • Variable assignments must be included inside of double quotes if they - contain characters outside of A-Z, a-z and 0-9
    • -
  • All strings should be UTF-8 format
    • -
  • Non-printable characters should not be used in the strings
    • -
-

Lines starting with the character - ‘#’ are ignored as comments.

-
-
-

-

The following variables are defined by the standard.

-
-
-
A string describing the preferred OS name.
-
-
Version string for the OS, in its usual and customary format.
-
-
Lower case version of the name with only a-z, 0-9, - ‘.’, - ‘-’, and - ‘_’.
-
-
Lower case version of the version with only a-z, 0-9, - ‘.’, - ‘-’, and - ‘_’.
-
-
A pretty version of the name presented to the user. May contain release - information.
-
-
Suggested color presentation for the OS. This string should be suitable - for inclusion within an ESC [ m ANSI/ECMA-48 escape sequence to render the - OS in its preferred color. This variable is optional.
-
-
A CPE name for the operating system. This field shall follow the NIST - Common Platform Enumeration specification.
-
-
 
-
-
 
-
-
 
-
-
Links on the internet, in RFC 3986 format for different aspects of this - OS. These variables are optional.
-
-
A string identifying the build. This variable is optional.
-
-
A string describing the variant of this operating system. This variable is - optional.
-
-
Lower case version of the variant with only a-z, 0-9, - ‘.’, - ‘-’, and - ‘_’. This variable is optional.
-
-

All other variables have no standard-defined meaning.

-
-
-

-
-
/etc/os-release
-
Symbolic link to actual os-release file.
-
/var/run/os-release
-
Generated os-release file describing the currently running system.
-
-
-
-

-
-
CPE Specification
-
https://csrc.nist.gov/projects/security-content-automation-protocol/scap-specifications/cpe
-
RFC 3986
-
https://tools.ietf.org/html/rfc3986
-
os-release Specification
-
https://www.linux.org/docs/man5/os-release.html
-
-
-
-

-

This file first appeared in FreeBSD - 13.0.

-
-
- - - - - -
November 23, 2021FreeBSD 15.0
diff --git a/static/freebsd/man5/passwd.5 3.html b/static/freebsd/man5/passwd.5 3.html deleted file mode 100644 index 713b1d4e..00000000 --- a/static/freebsd/man5/passwd.5 3.html +++ /dev/null @@ -1,282 +0,0 @@ - - - - - - -
PASSWD(5)File Formats ManualPASSWD(5)
-
-
-

-

passwd, - master.passwd, pwd.db, - spwd.db — format of the - password file

-
-
-

-

The passwd files are the local source of - password information. They can be used in conjunction with the Hesiod - domains ‘passwd’ and - ‘uid’, and the NIS maps - ‘passwd.byname’, - ‘passwd.byuid’, - ‘master.passwd.byname’, and - ‘master.passwd.byuid’, as controlled - by nsswitch.conf(5).

-

For consistency, none of these files should ever be modified - manually.

-

The master.passwd file is readable only by - root, and consists of newline separated records, one per user, containing - ten colon (‘:’) separated fields. - These fields are as follows:

-
-
-
name
-
User's login name.
-
password
-
User's encrypted password.
-
uid
-
User's id.
-
gid
-
User's login group id.
-
class
-
User's login class.
-
change
-
Password change time.
-
expire
-
Account expiration time.
-
gecos
-
General information about the user.
-
home_dir
-
User's home directory.
-
shell
-
User's login shell.
-
-
-

The passwd file is generated from the - master.passwd file by pwd_mkdb(8), - has the class, change, and - expire fields removed, and the - password field replaced by a - ‘*’ character.

-

The name field is the login used to access - the computer account, and the uid field is the number - associated with it. They should both be unique across the system (and often - across a group of systems) since they control file access.

-

While it is possible to have multiple entries with identical login - names and/or identical user id's, it is usually a mistake to do so. Routines - that manipulate these files will often return only one of the multiple - entries, and that one by random selection.

-

The login name must not begin with a hyphen - (‘-’), and cannot contain 8-bit - characters, tabs or spaces, or any of these symbols: - ‘,:+&#%^()!@~*?<>=|\/";’. - The dollar symbol (‘$’) is allowed - only as the last character for use with Samba. No field may contain a colon - (‘:’) as this has been used - historically to separate the fields in the user database.

-

Case is significant. Login names - ‘Lrrr’ and - ‘lrrr’ represent different users. Be - aware of this when interoperating with systems that do not have - case-sensitive login names.

-

In the master.passwd file, the - password field is the encrypted form - of the password, see crypt(3). If the - password field is empty, no password will be required - to gain access to the machine. This is almost invariably a mistake, so - authentication components such as PAM can forcibly disallow remote access to - passwordless accounts. Because this file contains the encrypted user - passwords, it should not be readable by anyone without appropriate - privileges.

-

A password of ‘*’ indicates - that password authentication is disabled for that account (logins through - other forms of authentication, e.g., using ssh(1) keys, - will still work). The field only contains encrypted passwords, and - ‘*’ can never be the result of - encrypting a password.

-

An encrypted password prefixed by - ‘*LOCKED*’ means that the account is - temporarily locked out and no one can log into it using any authentication. - For a convenient command-line interface to account locking, see - pw(8).

-

The group field is the group that the user - will be placed in upon login. Since this system supports multiple groups - (see groups(1)) this field currently has little special - meaning.

-

The class field is a key for a user's login - class. Login classes are defined in login.conf(5), which - is a termcap(5) style database of user attributes, - accounting, resource, and environment settings.

-

The change field is the number of seconds - from the epoch, UTC, until the password for the - account must be changed. This field may be left empty to turn off the - password aging feature; a value of zero is equivalent to leaving the field - empty.

-

The expire field is the number of seconds - from the epoch, UTC, until the account expires. This - field may be left empty to turn off the account aging feature; a value of - zero is equivalent to leaving the field empty.

-

The gecos field normally contains comma - (‘,’) separated subfields as - follows:

-

-
-
-
name
-
user's full name
-
office
-
user's office number
-
wphone
-
user's work phone number
-
hphone
-
user's home phone number
-
-
-

The full name may contain an ampersand - (‘&’) which will be replaced by - the capitalized login name when the - gecos field is displayed or used by various programs - such as finger(1), sendmail(8), etc.

-

The office and phone number subfields are - used by the finger(1) program, and possibly other - applications.

-

The user's home directory, home_dir, is the - full UNIX path name where the user will be placed on - login.

-

The shell field is the command interpreter - the user prefers. If there is nothing in the shell - field, the Bourne shell (/bin/sh) is assumed. The - conventional way to disable logging into an account once and for all, as it - is done for system accounts, is to set its shell to - /sbin/nologin (see - nologin(8)).

-
-
-

-

If ‘dns’ is specified for - the ‘passwd’ database in - nsswitch.conf(5), then passwd - lookups occur from the ‘passwd’ Hesiod - domain.

-
-
-

-

If ‘nis’ is specified for - the ‘passwd’ database in - nsswitch.conf(5), then passwd - lookups occur from the - ‘passwd.byname’, - ‘passwd.byuid’, - ‘master.passwd.byname’, and - ‘master.passwd.byuid’ NIS maps.

-
-
-

-

If ‘compat’ is specified for - the ‘passwd’ database, and either - ‘dns’ or - ‘nis’ is specified for the - ‘passwd_compat’ database in - nsswitch.conf(5), then the passwd - file also supports standard - ‘+/-’ - exclusions and inclusions, based on user names and netgroups.

-

Lines beginning with a ‘-’ - (minus sign) are entries marked as being excluded from any following - inclusions, which are marked with a - ‘+’ (plus sign).

-

If the second character of the line is a - ‘@’ (at sign), the operation involves - the user fields of all entries in the netgroup specified by the remaining - characters of the name field. Otherwise, the remainder - of the name field is assumed to be a specific user - name.

-

The ‘+’ token may also be - alone in the name field, which causes all users from - either the Hesiod domain passwd (with - ‘passwd_compat: dns’) or - ‘passwd.byname’ and - ‘passwd.byuid’ NIS maps (with - ‘passwd_compat: nis’) to be - included.

-

If the entry contains non-empty uid or - gid fields, the specified numbers will override the - information retrieved from the Hesiod domain or the NIS maps. Likewise, if - the gecos, dir or - shell entries contain text, it will override the - information included via Hesiod or NIS . On some systems, the - passwd field may also be overridden.

-
-
-

-
-
/etc/passwd
-
ASCII password file, with passwords removed
-
/etc/pwd.db
-
db(3)-format password database, with passwords - removed
-
/etc/master.passwd
-
ASCII password file, with passwords intact
-
/etc/spwd.db
-
db(3)-format password database, with passwords - intact
-
-
-
-

-

The password file format has changed since - 4.3BSD. The following awk script can be used to - convert your old-style password file into a new style password file. The - additional fields class, change - and expire are added, but are turned off by default - (setting these fields to zero is equivalent to leaving them blank). Class is - currently not implemented, but change and expire are; to set them, use the - current day in seconds from the epoch + whatever number of seconds of offset - you want.

-
-
BEGIN { FS = ":"}
-{ print $1 ":" $2 ":" $3 ":" $4 "::0:0:" $5 ":" $6 ":" $7 }
-
-
-
-

-

chpass(1), login(1), - passwd(1), crypt(3), - getpwent(3), login.conf(5), - netgroup(5), nsswitch.conf(5), - adduser(8), nologin(8), - pw(8), pwd_mkdb(8), - vipw(8), yp(8)

-

Managing NFS and NIS (O'Reilly & - Associates)

-
-
-

-

A passwd file format first appeared in - Version 1 AT&T UNIX.

-

The NIS passwd file format first appeared - in SunOS.

-

The Hesiod support first appeared in FreeBSD - 4.1. It was imported from the NetBSD Project, - where it first appeared in NetBSD 1.4.

-
-
-

-

User information should (and eventually will) be stored - elsewhere.

-

Placing ‘compat’ exclusions - in the file after any inclusions will have unexpected results.

-
-
- - - - - -
May 16, 2023FreeBSD 15.0
diff --git a/static/freebsd/man5/pbm.5 3.html b/static/freebsd/man5/pbm.5 3.html deleted file mode 100644 index 25d01fce..00000000 --- a/static/freebsd/man5/pbm.5 3.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - -
PBM(5)File Formats ManualPBM(5)
-
-
-

-

pbm — portable - bitmap file format

-
-
-

-

The portable bitmap format is a lowest common denominator - monochrome file format. It was originally designed to make it reasonable to - mail bitmaps between different types of machines using the typical stupid - network mailers we have today. Now it serves as the common language of a - large family of bitmap conversion filters. The definition is as follows:

-

-
    -
  • A "magic number" for identifying the file type. A pbm file's - magic number is the two characters "P1".
    • -
  • Whitespace (blanks, TABs, CRs, LFs).
    • -
  • A width, formatted as ASCII characters in decimal.
    • -
  • Whitespace.
    • -
  • A height, again in ASCII decimal.
    • -
  • Whitespace.
    • -
  • Width * height bits, each either '1' or '0', starting at the top-left - corner of the bitmap, proceeding in normal English reading order.
    • -
  • The character '1' means black, '0' means white.
    • -
  • Whitespace in the bits section is ignored.
    • -
  • Characters from a "#" to the next end-of-line are ignored - (comments).
    • -
  • No line should be longer than 70 characters.
    • -
-

Here is an example of a small bitmap in this format:

-
-
P1
-# feep.pbm
-24 7
-0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
-0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0
-0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0
-0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 1 0
-0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0
-0 1 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0
-0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
-
-

Programs that read this format should be as lenient as possible, - accepting anything that looks remotely like a bitmap.

-

There is also a variant on the format, available by setting the - RAWBITS option at compile time. This variant is different in the following - ways:

-

-
    -
  • The "magic number" is "P4" instead of - "P1".
    • -
  • The bits are stored eight per byte, high bit first low bit last.
    • -
  • No whitespace is allowed in the bits section, and only a single character - of whitespace (typically a newline) is allowed after the height.
    • -
  • The files are eight times smaller and many times faster to read and - write.
    • -
-
-
-

-

Copyright (C) 1989, 1991 by Jef - Poskanzer.

-
-
- - - - - -
September 27, 1991FreeBSD 15.0
diff --git a/static/freebsd/man5/periodic.conf.5 3.html b/static/freebsd/man5/periodic.conf.5 3.html deleted file mode 100644 index 351533f1..00000000 --- a/static/freebsd/man5/periodic.conf.5 3.html +++ /dev/null @@ -1,744 +0,0 @@ - - - - - - -
PERIODIC.CONF(5)File Formats ManualPERIODIC.CONF(5)
-
-
-

-

periodic.conf — - periodic job configuration information

-
-
-

-

The file periodic.conf contains a - description of how daily, weekly and monthly system maintenance jobs should - run. It resides in the /etc/defaults directory and - parts may be overridden by a file of the same name in - /etc, which itself may be overridden by the - /etc/periodic.conf.local file.

-

The periodic.conf file is actually sourced - as a shell script from each of the periodic scripts and is intended to - simply provide default configuration variables.

-

The following variables are used by periodic(8) - itself:

-
-
-
local_periodic
-
(str) List of directories to search for periodic - scripts. This list is always prefixed with - /etc/periodic, and is only used when an argument - to periodic(8) is not an absolute directory name.
-
⟨dir⟩_output
-
(path or - list) What to do with the output of the scripts - executed from the directory dir. If this variable is - set to an absolute path name, output is logged to that file, otherwise it - is taken as one or more space separated email addresses and mailed to - those users. If this variable is not set or is empty, output is sent to - standard output. -

For an unattended machine, suitable values for - daily_output, weekly_output, - and monthly_output might be - “/var/log/daily.log”, - “/var/log/weekly.log”, and - “/var/log/monthly.log” - respectively, as newsyslog(8) will rotate these files - (if they exists) at the appropriate times.

-
-
⟨dir⟩_show_success
-
 
-
⟨dir⟩_show_info
-
 
-
⟨dir⟩_show_badconfig
-
(bool) These variables control whether - periodic(8) will mask the output of the executed scripts - based on their return code (where dir is the base - directory name in which each script resides). If the return code of a - script is ‘0’ and - ⟨dir⟩_show_success - is set to “NO”, - periodic(8) will mask the script's output. If the return - code of a script is ‘1’ and - ⟨dir⟩_show_info - is set to “NO”, - periodic(8) will mask the script's output. If the return - code of a script is ‘2’ and - ⟨dir⟩_show_badconfig - is set to “NO”, - periodic(8) will mask the script's output. If these - variables are set to neither “YES” - nor “NO”, they default to - “YES”, - “YES” and - “NO” respectively. -

Refer to the periodic(8) manual page for how - script return codes are interpreted.

-
-
anticongestion_sleeptime
-
(int) The maximum number of seconds to randomly - sleep in order to smooth bursty loads on a shared resource, such as a - download mirror.
-
-
-

The following variables are used by the standard scripts that - reside in /etc/periodic/daily:

-
-
-
daily_clean_disks_enable
-
(bool) Set to - “YES” if you want to remove all - files matching daily_clean_disks_files daily.
-
daily_clean_disks_files
-
(str) Set to a list of file names to match. Wild - cards are permitted.
-
daily_clean_disks_days
-
(num) When - daily_clean_disks_enable is set to - “YES”, this must also be set to the - number of days old that a file's access and modification times must be - before it is deleted.
-
daily_clean_disks_verbose
-
(bool) Set to - “YES” if you want the removed files - to be reported in your daily output.
-
daily_clean_tmps_enable
-
(bool) Set to - “YES” if you want to clear temporary - directories daily.
-
daily_clean_tmps_dirs
-
(str) Set to the list of directories to clear if - daily_clean_tmps_enable is set to - “YES”.
-
daily_clean_tmps_days
-
(num) When - daily_clean_tmps_enable is set, this must also be - set to the number of days old that a file's access and modification times - must be before it is deleted.
-
daily_clean_tmps_ignore
-
(str) Set to the list of files that should not be - deleted when daily_clean_tmps_enable is set to - “YES”. Wild card characters are - permitted.
-
daily_clean_tmps_verbose
-
(bool) Set to - “YES” if you want the removed files - to be reported in your daily output.
-
daily_clean_preserve_enable
-
(bool) Set to - “YES” if you wish to remove old - files from /var/preserve.
-
daily_clean_preserve_days
-
(num) Set to the number of days that files must not - have been modified before they are deleted.
-
daily_clean_preserve_verbose
-
(bool) Set to - “YES” if you want the removed files - to be reported in your daily output.
-
daily_clean_msgs_enable
-
(bool) Set to - “YES” if you wish old system - messages to be purged.
-
daily_clean_msgs_days
-
(num) Set to the number of days that files must not - have been modified before they are deleted. If this variable is left - blank, the msgs(1) default is used.
-
daily_clean_rwho_enable
-
(bool) Set to - “YES” if you wish old files in - /var/who to be purged.
-
daily_clean_rwho_days
-
(num) Set to the number of days that files must not - have been modified before they are deleted.
-
daily_clean_rwho_verbose
-
(bool) Set to - “YES” if you want the removed files - to be reported in your daily output.
-
daily_clean_hoststat_enable
-
(bool) Set to - “YES” to run - sendmail -bH to - automatically purge stale entries from sendmail(8)'s - host status cache. Files will be deleted using the same criteria as - sendmail(8) would normally use when determining whether - to believe the cached information, as configured in - /etc/mail/sendmail.cf.
-
daily_backup_efi_enable
-
(bool) Set to - “YES” to create backup of EFI System - Partition (ESP).
-
daily_backup_gmirror_enable
-
(bool) Set to - “YES” to create backup of gmirror - information (i.e., output of gmirror - list), see gmirror(8).
-
daily_backup_gmirror_verbose
-
(bool) Set to - “YES” to report a diff between the - new backup and the existing backup in the daily output.
-
daily_backup_gpart_enable
-
(bool) Set to - “YES” to create backups of partition - tables, and bootcode partition contents.
-
daily_backup_gpart_verbose
-
(bool) Set to - “YES” to be verbose if existing - backups for kern.geom.conftxt or the partition tables differ from the new - backups.
-
daily_backup_passwd_enable
-
(bool) Set to - “YES” if you want the - /etc/master.passwd and - /etc/group files backed up and reported on. - Reporting consists of checking both files for modifications and running - chkgrp(8) on the group - file.
-
daily_backup_aliases_enable
-
(bool) Set to - “YES” if you want the - /etc/mail/aliases file backed up and modifications - to be displayed in your daily output.
-
daily_backup_zfs_enable
-
(bool) Set to - “YES” to create backup of the output - generated from the zfs-list(8) and - zpool-list(8) utilities.
-
daily_backup_zfs_list_flags
-
(str) Set to the arguments for the - zfs-list(8) utility. The default is standard - behavior.
-
daily_backup_zpool_list_flags
-
(str) Set to the arguments for the - zpool-list(8) utility. The default is - -v.
-
daily_backup_zfs_props_enable
-
(bool) Set to - “YES” to create backup of the output - generated from the zfs-get(8) and - zpool-get(8) utilities.
-
daily_backup_zfs_get_flags
-
(str) Set to the arguments for the - zfs-get(8) utility. The default is - all.
-
daily_backup_zpool_get_flags
-
(str) Set to the arguments for the - zpool-get(8) utility. The default is - all.
-
daily_backup_zfs_verbose
-
(bool) Set to - “YES” to report a diff between the - new backup and the existing backup in the daily output.
-
daily_calendar_enable
-
(bool) Set to - “YES” if you want to run - calendar -a daily.
-
daily_accounting_enable
-
(bool) Set to - “YES” if you want to rotate your - daily process accounting files. No rotations are necessary unless - accounting_enable is enabled in - rc.conf(5).
-
daily_accounting_compress
-
(bool) Set to - “YES” if you want your daily - accounting files to be compressed using gzip(1).
-
daily_accounting_save
-
(num) When - daily_accounting_enable is set, this may also be set - to the number of daily accounting files that are to be saved. The default - is “3”.
-
daily_accounting_flags
-
(str) Set to the arguments to pass to the - sa(8) utility (in addition to - -s) when - daily_accounting_enable is set to - “YES”. The default is - -q.
-
daily_status_disks_enable
-
(bool) Set to - “YES” if you want to run - df(1) (with the arguments supplied in - daily_status_disks_df_flags) and - dump -W.
-
daily_status_disks_df_flags
-
(str) Set to the arguments for the - df(1) utility when - daily_status_disks_enable is set to - “YES”. The default is - -l -h.
-
daily_status_zfs_enable
-
(bool) Set to - “YES” if you want to run - zpool status on your - zfs(8) pools.
-
daily_status_zfs_zpool_list_enable
-
(bool) Set to - “YES” if you want to run - zpool list on your - zfs(8) pools. Requires - daily_status_zfs_enable to be set to - YES.
-
daily_status_gmirror_enable
-
(bool) Set to - “YES” if you want to run - gmirror status on your - gmirror(8) devices.
-
daily_status_graid3_enable
-
(bool) Set to - “YES” if you want to run - graid3 status on your - graid3(8) devices.
-
daily_status_gstripe_enable
-
(bool) Set to - “YES” if you want to run - gstripe status on your - gstripe(8) devices.
-
daily_status_gconcat_enable
-
(bool) Set to - “YES” if you want to run - gconcat status on your - gconcat(8) devices.
-
daily_status_mfi_enable
-
(bool) Set to - “YES” if you want to run - mfiutil status on your - mfi(4) devices.
-
daily_status_network_enable
-
(bool) Set to - “YES” if you want to run - netstat -i.
-
daily_status_network_netstat_flags
-
(str) Set to additional arguments for the - netstat(1) utility when - daily_status_network_enable is set to - “YES”. The default is - -d -W.
-
daily_status_network_usedns
-
(bool) Set to - “YES” if you want to run - netstat(1) without the -n option - (to do DNS lookups).
-
daily_status_uptime_enable
-
(bool) Set to - “YES” if you want to run - uptime(1) (or ruptime(1) if - rwhod_enable is set to - “YES” in - /etc/rc.conf).
-
daily_status_mailq_enable
-
(bool) Set to - “YES” if you want to run - mailq(1).
-
daily_status_mailq_shorten
-
(bool) Set to - “YES” if you want to shorten the - mailq(1) output when - daily_status_mailq_enable is set to - “YES”.
-
daily_status_include_submit_mailq
-
(bool) Set to - “YES” if you also want to run - mailq(1) on the submit mail queue when - daily_status_mailq_enable is set to - “YES”. This may not work with MTAs - other than sendmail(8).
-
daily_status_security_enable
-
(bool) Set to - “YES” if you want to run the - security check. The security check is another set of - periodic(8) scripts. The system defaults are in - /etc/periodic/security. Local scripts should be - placed in /usr/local/etc/periodic/security. See - the periodic(8) manual page for more information.
-
daily_status_security_inline
-
(bool) Set to - “YES” if you want the security check - output inline. The default is to either mail or log the output according - to the value of daily_status_security_output.
-
daily_status_security_output
-
(str) Where to send the output of the security check - if daily_status_security_inline is set to - “NO”. This variable behaves in the - same way as the *_output variables above, namely it - can be set either to one or more email addresses or to an absolute file - name.
-
daily_status_mail_rejects_enable
-
(bool) Set to - “YES” if you want to summarise mail - rejections logged to /var/log/maillog for the - previous day.
-
daily_status_mail_rejects_logs
-
(num) Set to the number of maillog files that should - be checked for yesterday's mail rejects.
-
daily_status_ntpd_enable
-
(bool) Set to - “YES” if you want to enable NTP - status check.
-
daily_status_world_kernel
-
(bool) Set to - “YES” to check the running userland - and kernel are in sync.
-
daily_queuerun_enable
-
(bool) Set to - “YES” if you want to manually run - the mail queue at least once a day.
-
daily_submit_queuerun
-
(bool) Set to - “YES” if you also want to manually - run the submit mail queue at least once a day when - daily_queuerun_enable is set to - “YES”.
-
daily_scrub_zfs_enable
-
(bool) Set to - “YES” if you want to run a zfs scrub - periodically.
-
daily_scrub_zfs_pools
-
(str) A space separated list of names of zfs pools - to scrub. If the list is empty or not set, all zfs pools are - scrubbed.
-
daily_scrub_zfs_default_threshold
-
(int) Number of days between a scrub if no - pool-specific threshold is set. If not set, the default value is 35, - corresponding to 5 weeks.
-
daily_scrub_zfs_⟨poolname⟩_threshold
-
(int) The same as - daily_scrub_zfs_default_threshold but specific to - the pool ⟨poolname⟩.
-
daily_trim_zfs_enable
-
(bool) Set to - “YES” if you want to run a zfs trim - daily.
-
daily_trim_zfs_pools
-
(str) A space separated list of names of zfs pools - to trim. If the list is empty or not set, all zfs pools are trimmed.
-
daily_local
-
(str) Set to a list of extra scripts that should be - run after all other daily scripts. All scripts must be absolute path - names.
-
daily_diff_flags
-
(str) Set to the arguments to pass to the - diff(1) utility when generating differences. The default - is -b -U - 0.
-
-
-

The following variables are used by the standard scripts that - reside in /etc/periodic/weekly:

-
-
-
weekly_locate_enable
-
(bool) Set to - “YES” if you want to run - /usr/libexec/locate.updatedb. This script is run - using nice -5 as user - “nobody”, and generates the table - used by the locate(1) command.
-
weekly_whatis_enable
-
(bool) Set to - “YES” if you want to run - /usr/libexec/makewhatis.local. This script - regenerates the database used by the apropos(1) - command.
-
weekly_noid_enable
-
(bool) Set to - “YES” if you want to locate orphaned - files on the system. An orphaned file is one with an invalid owner or - group.
-
weekly_noid_dirs
-
(str) A list of directories under which orphaned - files are searched for. This would usually be set to - /.
-
weekly_status_security_enable
-
(bool) Weekly counterpart of - daily_status_security_enable.
-
weekly_status_security_inline
-
(bool) Weekly counterpart of - daily_status_security_inline.
-
weekly_status_security_output
-
(str) Weekly counterpart of - daily_status_security_output.
-
weekly_status_pkg_enable
-
(bool) Set to - “YES” if you want to use - pkg-version(8) to list installed packages which are out - of date.
-
pkg_version
-
(str) When - weekly_status_pkg_enable is set to - “YES”, this variable specifies the - program that is used to determine the out of date packages. If unset, the - pkg-version(8) program is used. As an example, this - variable might be set to - “portversion” if the - ports/sysutils/portupgrade port has been - installed.
-
pkg_version_index
-
(str) This variable specifies the - INDEX file from /usr/ports - that should be used by pkg-version(8). Because the - dependency tree may be substantially different between versions of - FreeBSD, there may be more than one - INDEX file in /usr/ports. -

Note, if the pkg_version variable is set - to “portversion”, it will also be - necessary to arrange that the correct INDEX file - is specified using environment variables and that - pkg_version_index is cleared in - /etc/periodic.conf - (“pkg_version_index=”).

-
-
weekly_local
-
(str) Set to a list of extra scripts that should be - run after all other weekly scripts. All scripts must be absolute path - names.
-
-
-

The following variables are used by the standard scripts that - reside in /etc/periodic/monthly:

-
-
-
monthly_accounting_enable
-
(bool) Set to - “YES” if you want to do login - accounting using the ac(8) command.
-
monthly_status_security_enable
-
(bool) Monthly counterpart of - daily_status_security_enable.
-
monthly_status_security_inline
-
(bool) Monthly counterpart of - daily_status_security_inline.
-
monthly_status_security_output
-
(str) Monthly counterpart of - daily_status_security_output.
-
monthly_local
-
(str) Set to a list of extra scripts that should be - run after all other monthly scripts. All scripts must be absolute path - names.
-
-
-

The following variables are used by the standard scripts that - reside in /etc/periodic/security. Those scripts are - usually run from daily (daily_status_security_enable), - weekly (weekly_status_security_enable), and monthly - (monthly_status_security_enable) periodic hooks. The - ..._period of each script can be configured as - “daily”, “weekly”, “monthly” or - “NO”. Note that when periodic security scripts are run from - crontab(5), they will be always run unless their - ..._enable or ..._period - variable is set to “NO”.

-
-
-
security_status_diff_flags
-
(str) Set to the arguments to pass to the - diff(1) utility when generating differences. The default - is -b -U - 0.
-
security_status_chksetuid_enable
-
(bool) Set to - “YES” to compare the modes and - modification times of setuid executables with the previous day's - values.
-
security_status_chksetuid_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_chkportsum_enable
-
(bool) Set to - “YES” to verify checksums of all - installed packages against the known checksums in - /var/db/pkg.
-
security_status_chkportsum_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_neggrpperm_enable
-
(bool) Set to - “YES” to check for files where the - group of a file has less permissions than the world at large. When users - are in more than 14 supplemental groups these negative permissions may not - be enforced via NFS shares.
-
security_status_neggrpperm_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_chkmounts_enable
-
(bool) Set to - “YES” to check for changes mounted - file systems to the previous day's values.
-
security_status_chkmounts_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_noamd
-
(bool) Set to - “YES” if you want to ignore - amd(8) mounts when comparing against yesterday's file - system mounts in the - security_status_chkmounts_enable check.
-
security_status_chkuid0_enable
-
(bool) Set to - “YES” to check - /etc/master.passwd for accounts with UID 0.
-
security_status_chkuid0_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_passwdless_enable
-
(bool) Set to - “YES” to check - /etc/master.passwd for accounts with empty - passwords.
-
security_status_passwdless_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_logincheck_enable
-
(bool) Set to - “YES” to check - /etc/login.conf ownership, see - login.conf(5) for more information.
-
security_status_logincheck_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_ipfwdenied_enable
-
(bool) Set to - “YES” to show log entries for - packets denied by ipfw(8) since yesterday's check.
-
security_status_ipfwdenied_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_ipfdenied_enable
-
(bool) Set to - “YES” to show log entries for - packets denied by ipf(8) since yesterday's check.
-
security_status_ipfdenied_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_pfdenied_enable
-
(bool) Set to - “YES” to show log entries for - packets denied by pf(4) since yesterday's check.
-
security_status_pfdenied_additionalanchors
-
(str) Space-separated list of additional anchors - whose denied packets log entries to show. The main ruleset (i.e., the - empty-string anchor) and any blocklistd(8) anchors, if - present, are always shown.
-
security_status_pfdenied_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_ipfwlimit_enable
-
(bool) Set to - “YES” to display - ipfw(8) rules that have reached their verbosity - limit.
-
security_status_ipfwlimit_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_kernelmsg_enable
-
(bool) Set to - “YES” to show new - dmesg(8) entries since yesterday's check.
-
security_status_kernelmsg_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_loginfail_enable
-
(bool) Set to - “YES” to display failed logins from - /var/log/messages in the previous day.
-
security_status_loginfail_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
security_status_tcpwrap_enable
-
(bool) Set to - “YES” to display connections denied - by tcpwrappers (see hosts_access(5)) from - /var/log/messages during the previous day.
-
security_status_tcpwrap_period
-
(str) Set to either - “daily”, - “weekly”, - “monthly” or - “NO”.
-
-
-
-
-

-
-
/etc/defaults/periodic.conf
-
The default configuration file. This file contains all default variables - and values.
-
/etc/periodic.conf
-
The usual system specific variable override file.
-
/etc/periodic.conf.local
-
An additional override file, useful when - /etc/periodic.conf is shared or distributed.
-
-
-
-

-

apropos(1), calendar(1), - df(1), diff(1), - gzip(1), locate(1), - man(1), msgs(1), - netstat(1), nice(1), - login.conf(5), rc.conf(5), - ac(8), chkgrp(8), - dump(8), newsyslog(8), - periodic(8), pkg-version(8), - sendmail(8)

-
-
-

-

The periodic.conf file appeared in - FreeBSD 4.1.

-
-
-

-

Brian Somers - <brian@Awfulhak.org>

-
-
- - - - - -
April 9, 2024FreeBSD 15.0
diff --git a/static/freebsd/man5/pf.conf.5 3.html b/static/freebsd/man5/pf.conf.5 3.html deleted file mode 100644 index dfa40f42..00000000 --- a/static/freebsd/man5/pf.conf.5 3.html +++ /dev/null @@ -1,3028 +0,0 @@ - - - - - - -
PF.CONF(5)File Formats ManualPF.CONF(5)
-
-
-

-

pf.conf — packet - filter configuration file

-
-
-

-

The pf(4) packet filter modifies, drops or - passes packets according to rules or definitions specified in - pf.conf.

-
-
-

-

There are eight types of statements in - pf.conf:

-
-
-
User-defined variables may be defined and used later, simplifying the - configuration file. Macros must be defined before they are referenced in - pf.conf.
-
-
Tables provide a mechanism for increasing the performance and flexibility - of rules with large numbers of source or destination addresses.
-
-
Options tune the behaviour of the packet filtering engine.
-
-
Ethernet filtering provides rule-based blocking or passing of Ethernet - packets.
-
(e.g. - )
-
Traffic normalization protects internal machines against inconsistencies - in Internet protocols and implementations.
-
-
Queueing provides rule-based bandwidth control.
-
- (Various forms of NAT)
-
Translation rules specify how addresses are to be mapped or redirected to - other addresses.
-
-
Packet filtering provides rule-based blocking or passing of packets.
-
-

With the exception of macros and - tables, the types of statements should be grouped - and appear in pf.conf in the order shown above, as - this matches the operation of the underlying packet filtering engine. By - default pfctl(8) enforces this order (see - set require-order below).

-

Comments can be put anywhere in the file using a hash mark - (‘#’), and extend to the end of the current line.

-

Additional configuration files can be included with the - include keyword, for example:

-
-
include "/etc/pf/sub.filter.conf"
-
-
-
-

-

A macro is defined with a command of the form - name=value. The macro - name can contain letters, digits, and underscores and - cannot be a reserved word (for example, pass, - in, or out). Within unquoted - arguments, the string $name is later expanded to - value. Ranges of network addresses used in macros that - will be expanded in lists later on must be quoted with additional simple - quotes.

-

For example,

-
-
ext_if = "kue0"
-all_ifs = "{" $ext_if lo0 "}"
-pass out on $ext_if from any to any
-pass in  on $ext_if proto tcp from any to any port 25
-
-usr_lan_range = "'192.0.2.0/24'"
-srv_lan_range = "'198.51.100.0 - 198.51.100.255'"
-nat_ranges = "{" $usr_lan_range $srv_lan_range "}"
-nat on $ext_if from $nat_ranges to any -> ($ext_if)
-
-
-
-

-

Tables are named structures which can hold a collection of - addresses and networks. Lookups against tables in pf(4) - are relatively fast, making a single rule with tables much more efficient, - in terms of processor usage and memory consumption, than a large number of - rules which differ only in IP address (either created explicitly or - automatically by rule expansion).

-

Tables can be used as the source or destination of filter rules, - scrub rules or translation rules such as - nat or rdr (see below for - details on the various rule types). Tables can also be used for the redirect - address of nat and rdr and in - the routing options of filter rules, but not for - bitmask pools.

-

Tables can be defined with any of the following - pfctl(8) mechanisms. As with macros, reserved words may - not be used as table names.

-
-
manually
-
Persistent tables can be manually created with the - add or replace option of - pfctl(8), before or after the ruleset has been - loaded.
-
pf.conf
-
Table definitions can be placed directly in this file, and loaded at the - same time as other rules are loaded, atomically. Table definitions inside - pf.conf use the table - statement, and are especially useful to define non-persistent tables. The - contents of a pre-existing table defined without a list of addresses to - initialize it is not altered when pf.conf is - loaded. A table initialized with the empty list, { - }, will be cleared on load.
-
-

Tables may be defined with the following attributes:

-
-
persist
-
The persist flag forces the kernel to keep the table - even when no rules refer to it. If the flag is not set, the kernel will - automatically remove the table when the last rule referring to it is - flushed.
-
const
-
The const flag prevents the user from altering the - contents of the table once it has been created. Without that flag, - pfctl(8) can be used to add or remove addresses from the - table at any time, even when running with securelevel(7) - = 2.
-
counters
-
The counters flag enables per-address packet and - byte counters which can be displayed with pfctl(8). Note - that this feature carries significant memory overhead for large - tables.
-
-

For example,

-
-
table <private> const { 10/8, 172.16/12, 192.168/16 }
-table <badhosts> persist
-block on fxp0 from { <private>, <badhosts> } to any
-
-

creates a table called private, to hold RFC 1918 private network - blocks, and a table called badhosts, which is initially empty. A filter rule - is set up to block all traffic coming from addresses listed in either table. - The private table cannot have its contents changed and the badhosts table - will exist even when no active filter rules reference it. Addresses may - later be added to the badhosts table, so that traffic from these hosts can - be blocked by using

-
-
# pfctl -t badhosts -Tadd 204.92.77.111
-
-

A table can also be initialized with an address list specified in - one or more external files, using the following syntax:

-
-
table <spam> persist file "/etc/spammers" file "/etc/openrelays"
-block on fxp0 from <spam> to any
-
-

The files /etc/spammers and - /etc/openrelays list IP addresses, one per line. Any - lines beginning with a # are treated as comments and ignored. In addition to - being specified by IP address, hosts may also be specified by their - hostname. When the resolver is called to add a hostname to a table, - resulting IPv4 - and IPv6 addresses are placed into the table. IP addresses can also be - entered in a table by specifying a valid interface name, a valid interface - group or the - - keyword, in which case all addresses assigned to the interface(s) will be - added to the table.

-
-
-

-

pf(4) may be tuned for various situations using - the set command.

-
-
set timeout
-
-

-
-
interval
-
Interval between purging expired states and fragments.
-
frag
-
Seconds before an unassembled fragment is expired.
-
src.track
-
Length of time to retain a source tracking entry after the last state - expires.
-
-

When a packet matches a stateful connection, the seconds to - live for the connection will be updated to that of the - proto.modifier which corresponds to the connection - state. Each packet which matches this state will reset the TTL. Tuning - these values may improve the performance of the firewall at the risk of - dropping valid idle connections. Alternatively, these values may be - adjusted collectively in a manner suitable for a specific environment - using set optimization (see above).

-

-
-
tcp.first
-
The state after the first packet.
-
tcp.opening
-
The state after the second packet but before both endpoints have - acknowledged the connection.
-
tcp.tsdiff
-
Maximum allowed time difference between RFC 1323 compliant packet - timestamps. 30 seconds by default.
-
tcp.established
-
The fully established state.
-
tcp.closing
-
The state after the first FIN has been sent.
-
tcp.finwait
-
The state after both FINs have been exchanged and the connection is - closed. Some hosts (notably web servers on Solaris) send TCP packets - even after closing the connection. Increasing - tcp.finwait (and possibly - tcp.closing) can prevent blocking of such - packets.
-
tcp.closed
-
The state after one endpoint sends an RST.
-
-

SCTP timeout are handled similar to TCP, but with its own set - of states:

-

-
-
sctp.first
-
The state after the first packet.
-
sctp.opening
-
The state before the destination host ever sends a packet.
-
sctp.established
-
The fully established state.
-
sctp.closing
-
The state after the first SHUTDOWN chunk has been sent.
-
sctp.closed
-
The state after SHUTDOWN_ACK has been exchanged and the connection is - closed.
-
-

ICMP and UDP are handled in a fashion similar to TCP, but with - a much more limited set of states:

-

-
-
udp.first
-
The state after the first packet.
-
udp.single
-
The state if the source host sends more than one packet but the - destination host has never sent one back.
-
udp.multiple
-
The state if both hosts have sent packets.
-
icmp.first
-
The state after the first packet.
-
icmp.error
-
The state after an ICMP error came back in response to an ICMP - packet.
-
-

Other protocols are handled similarly to UDP:

-

-
-
other.first
-
 
-
other.single
-
 
-
other.multiple
-
 
-
-

Timeout values can be reduced adaptively as the number of - state table entries grows.

-

-
-
adaptive.start
-
When the number of state entries exceeds this value, adaptive scaling - begins. All timeout values are scaled linearly with factor - (adaptive.end - number of states) / (adaptive.end - - adaptive.start).
-
adaptive.end
-
When reaching this number of state entries, all timeout values become - zero, effectively purging all state entries immediately. This value is - used to define the scale factor, it should not actually be reached - (set a lower state limit, see below).
-
-

Adaptive timeouts are enabled by default, with an - adaptive.start value equal to 60% of the state limit, and an - adaptive.end value equal to 120% of the state limit. They can be - disabled by setting both adaptive.start and adaptive.end to 0.

-

The adaptive timeout values can be defined both globally and - for each rule. When used on a per-rule basis, the values relate to the - number of states created by the rule, otherwise to the total number of - states.

-

For example:

-
- 
set timeout tcp.first 120
-set timeout tcp.established 86400
-set timeout { adaptive.start 60000, adaptive.end 120000 }
-set limit states 100000
-
-

With 90000 state table entries, the timeout values are scaled - to 50% (tcp.first 60, tcp.established 43200).

-
-
set loginterface
-
Enable collection of packet and byte count statistics for the given - interface or interface group. These statistics can be viewed using -
- 
# pfctl -s info
-
-

In this example pf(4) collects statistics on - the interface named dc0:

-
- 
set loginterface dc0
-
-

One can disable the loginterface using:

-
- 
set loginterface none
-
-
-
set limit
-
Sets hard limits on the memory pools used by the packet filter. See - zone(9) for an explanation of memory pools. -

Limits can be set on the following:

-
-
-
Set the maximum number of entries in the memory pool used by state - table entries (those generated by pass rules - which do not specify no state). The default is - 100000.
-
-
Set the maximum number of entries in the memory pool used for tracking - source IP addresses (generated by the - sticky-address and - src.track options). The default is 10000.
-
-
Set the number of addresses that can be stored in tables. The default - is 200000.
-
-
Set the number of anchors that can exist. The default is 512.
-
-
Set the number of anchors that can exist. The default is 512.
-
-

Multiple limits can be combined on a single line:

-
- 
set limit { states 20000, frags 2000, src-nodes 2000 }
-
-
-
set ruleset-optimization
-
-
-
none
-
Disable the ruleset optimizer.
-
basic
-
Enable basic ruleset optimization. This is the default behaviour. - Basic ruleset optimization does four things to improve the performance - of ruleset evaluations: -

-
    -
  1. remove duplicate rules
    2. -
  2. remove rules that are a subset of another rule
    3. -
  3. combine multiple rules into a table when advantageous
    4. -
  4. re-order the rules to improve evaluation performance
    5. -
-

-
-
profile
-
Uses the currently loaded ruleset as a feedback profile to tailor the - ordering of quick rules to actual network traffic.
-
-

It is important to note that the ruleset optimizer will modify - the ruleset to improve performance. A side effect of the ruleset - modification is that per-rule accounting statistics will have different - meanings than before. If per-rule accounting is important for billing - purposes or whatnot, either the ruleset optimizer should not be used or - a label field should be added to all of the accounting rules to act as - optimization barriers.

-

Optimization can also be set as a command-line argument to - pfctl(8), overriding the settings in - pf.conf.

-
-
set optimization
-
Optimize state timeouts for one of the following network environments: -

-
-
normal
-
A normal network environment. Suitable for almost all networks.
-
high-latency
-
A high-latency environment (such as a satellite connection).
-
satellite
-
Alias for high-latency.
-
aggressive
-
Aggressively expire connections. This can greatly reduce the memory - usage of the firewall at the cost of dropping idle connections - early.
-
conservative
-
Extremely conservative settings. Avoid dropping legitimate connections - at the expense of greater memory utilization (possibly much greater on - a busy network) and slightly increased processor utilization.
-
-

For example:

-
- 
set optimization aggressive
-
-
-
set reassemble yes | no - [no-df]
-
The reassemble option is used to enable or disable - the reassembly of fragmented packets, and can be set to - yes or no. If - no-df is also specified, fragments with the - “dont-fragment” bit set are reassembled too, instead of - being dropped; the reassembled packet will have the - “dont-fragment” bit cleared. The default value is - no. -

This option is ignored if there are pre-FreeBSD 14 - scrub rules present.

-
-
set block-policy
-
The block-policy option sets the default behaviour - for the packet block action: -

-
-
drop
-
Packet is silently dropped.
-
return
-
A TCP RST is returned for blocked TCP packets, an SCTP ABORT chunk is - returned for blocked SCTP packets, an ICMP UNREACHABLE is returned for - blocked UDP packets, and all other packets are silently dropped.
-
-

The default value is drop.

-

For example:

-
- 
set block-policy return
-
-
-
set fail-policy
-
The fail-policy option sets the behaviour of rules - which should pass a packet but were unable to do so. This might happen - when a nat or route-to rule uses an empty table as list of targets or if a - rule fails to create state or source node. The following - block actions are possible: -

-
-
drop
-
Incoming packet is silently dropped.
-
return
-
Incoming packet is dropped and TCP RST is returned for TCP packets, an - SCTP ABORT chunk is returned for blocked SCTP packets, an ICMP - UNREACHABLE is returned for UDP packets, and no response is sent for - other packets.
-
-

For example:

-
- 
set fail-policy return
-
-
-
set state-policy
-
The state-policy option sets the default behaviour - for states: -

-
-
if-bound
-
States are bound to interface.
-
floating
-
States can match packets on any interfaces (the default).
-
-

For example:

-
- 
set state-policy if-bound
-
-
-
set syncookies never | always - | adaptive
-
When syncookies are active, pf will answer each - incoming TCP SYN with a syncookie SYNACK, without allocating any - resources. Upon reception of the client's ACK in response to the syncookie - SYNACK, pf will evaluate the ruleset and create state if the ruleset - permits it, complete the three way handshake with the target host and - continue the connection with synproxy in place. This allows pf to be - resilient against large synflood attacks which would run the state table - against its limits otherwise. Due to the blind answers to every incoming - SYN syncookies share the caveats of synproxy, namely seemingly accepting - connections that will be dropped later on. -

-
-
-
pf will never send syncookie SYNACKs (the default).
-
-
pf will always send syncookie SYNACKs.
-
-
pf will enable syncookie mode when a given percentage of the state - table is used up by half-open TCP connections, as in, those that saw - the initial SYN but didn't finish the three way handshake. The - thresholds for entering and leaving syncookie mode can be specified - using -
- 
set syncookies adaptive (start 25%, end 12%)
-
-
-
-
-
set state-defaults
-
The state-defaults option sets the state options for - states created from rules without an explicit keep - state. For example: -
- 
set state-defaults no-sync
-
-
-
set hostid
-
The 32-bit hostid identifies this firewall's state - table entries to other firewalls in a pfsync(4) failover - cluster. By default the hostid is set to a pseudo-random value, however it - may be desirable to manually configure it, for example to more easily - identify the source of state table entries. -
- 
set hostid 1
-
-

The hostid may be specified in either decimal or - hexadecimal.

-
-
set require-order
-
By default pfctl(8) enforces an ordering of the - statement types in the ruleset to: - , - , - , - , - . - Setting this option to no disables this enforcement. - There may be non-trivial and non-obvious implications to an out of order - ruleset. Consider carefully before disabling the order enforcement.
-
set fingerprints
-
Load fingerprints of known operating systems from the given filename. By - default fingerprints of known operating systems are automatically loaded - from pf.os(5) in /etc but can be - overridden via this option. Setting this option may leave a small period - of time where the fingerprints referenced by the currently active ruleset - are inconsistent until the new ruleset finishes loading. The default - location for fingerprints is /etc/pf.os. -

For example:

-

-
set fingerprints - "/etc/pf.os.devel"
-
-
set skip on - ⟨ifspec⟩
-
List interfaces for which packets should not be filtered. Packets passing - in or out on such interfaces are passed as if pf was disabled, i.e. pf - does not process them in any way. This can be useful on loopback and other - virtual interfaces, when packet filtering is not desired and can have - unexpected effects. For example: -

-
set skip on lo0
-
-
set debug
-
Set the debug level to one of the following: -

-
-
none
-
Don't generate debug messages.
-
urgent
-
Generate debug messages only for serious errors.
-
misc
-
Generate debug messages for various errors.
-
loud
-
Generate debug messages for common conditions.
-
-
-
set keepcounters
-
Preserve rule counters across rule updates. Usually rule counters are - reset to zero on every update of the ruleset. With - keepcounters set pf will attempt to find matching - rules between old and new rulesets and preserve the rule counters.
-
-
-
-

-

pf(4) has the ability to - block and pass packets based on - attributes of their Ethernet (layer 2) header.

-

Each time a packet processed by the packet filter comes in on or - goes out through an interface, the filter rules are evaluated in sequential - order, from first to last. The last matching rule decides what action is - taken. If no rule matches the packet, the default action is to pass the - packet without creating a state.

-

The following actions can be used in the filter:

-
-
block
-
The packet is blocked. Unlike for layer 3 traffic the packet is always - silently dropped.
-
pass
-
The packet is passed; no state is created for layer 2 traffic.
-
-
-

-

The rule parameters specify the packets to which a rule applies. A - packet always comes in on, or goes out through, one interface. Most - parameters are optional. If a parameter is specified, the rule only applies - to packets with matching attributes. The matching for some parameters can be - inverted with the ! operator. Certain parameters can - be expressed as lists, in which case pfctl(8) generates - all needed rule combinations.

-
-
in or - out
-
This rule applies to incoming or outgoing packets. If neither - in nor out are specified, the - rule will match packets in both directions.
-
quick
-
If a packet matches a rule which has the quick - option set, this rule is considered the last matching rule, and evaluation - of subsequent rules is skipped.
-
on ⟨ifspec⟩
-
This rule applies only to packets coming in on, or going out through, this - particular interface or interface group. For more information on interface - groups, see the group keyword in - ifconfig(8). any will match any - existing interface except loopback ones.
-
bridge-to ⟨interface⟩
-
Packets matching this rule will be sent out of the specified interface - without further processing.
-
proto - ⟨protocol⟩
-
This rule applies only to packets of this protocol. Note that Ethernet - protocol numbers are different from those used in ip(4) - and ip6(4).
-
from ⟨source⟩ - to ⟨dest⟩
-
This rule applies only to packets with the specified source and - destination MAC addresses.
-
queue - ⟨queue⟩
-
Packets matching this rule will be assigned to the specified queue. See - QUEUEING for setup details.
-
tag - ⟨string⟩
-
Packets matching this rule will be tagged with the specified string. The - tag acts as an internal marker that can be used to identify these packets - later on. This can be used, for example, to provide trust between - interfaces and to determine if packets have been processed by translation - rules. Tags are "sticky", meaning that the packet will be tagged - even if the rule is not the last matching rule. Further matching rules can - replace the tag with a new one but will not remove a previously applied - tag. A packet is only ever assigned one tag at a time.
-
tagged - ⟨string⟩
-
Used to specify that packets must already be tagged with the given tag in - order to match the rule. Inverse tag matching can also be done by - specifying the ! operator before the tagged keyword.
-
-
-
-
-

-

Traffic normalization is a broad umbrella term for aspects of the - packet filter which deal with verifying packets, packet fragments, spoofed - traffic, and other irregularities.

-
-

-

Scrub involves sanitising packet content in such a way that there - are no ambiguities in packet interpretation on the receiving side. It is - invoked with the scrub option, added to filter - rules.

-

Parameters are specified enclosed in parentheses. At least one of - the following parameters must be specified:

-
-
no-df
-
Clears the dont-fragment bit from a matching IP - packet. Some operating systems are known to generate fragmented packets - with the dont-fragment bit set. This is particularly - true with NFS. Scrub will drop such fragmented - dont-fragment packets unless - no-df is specified. -

Unfortunately some operating systems also generate their - dont-fragment packets with a zero IP - identification field. Clearing the dont-fragment - bit on packets with a zero IP ID may cause deleterious results if an - upstream router later fragments the packet. Using the - random-id modifier (see below) is recommended in - combination with the no-df modifier to ensure - unique IP identifiers.

-
-
min-ttl - ⟨number⟩
-
Enforces a minimum TTL for matching IP packets.
-
max-mss - ⟨number⟩
-
Reduces the maximum segment size (MSS) on TCP SYN packets to be no greater - than number. This is sometimes required in scenarios - where the two endpoints of a TCP connection are not able to carry similar - sized packets and the resulting mismatch can lead to packet fragmentation - or loss. Note that setting the MSS this way can have undesirable effects, - such as interfering with the OS detection features of - pf(4).
-
set-tos ⟨string⟩ - | ⟨number⟩
-
Enforces a TOS for matching IP packets. - TOS may be given as one of - critical, inetcontrol, - lowdelay, netcontrol, - throughput, reliability, or - one of the DiffServ Code Points: ef, - va, af11 - ... af43, - cs0 ... - cs7; or as either hex or decimal.
-
random-id
-
Replaces the IP identification field with random values to compensate for - predictable values generated by many hosts. This option only applies to - packets that are not fragmented after the optional fragment - reassembly.
-
reassemble tcp
-
Statefully normalizes TCP connections. reassemble - tcp performs the following normalizations: -

-
-
ttl
-
Neither side of the connection is allowed to reduce their IP TTL. An - attacker may send a packet such that it reaches the firewall, affects - the firewall state, and expires before reaching the destination host. - reassemble tcp will raise the TTL of all packets - back up to the highest value seen on the connection.
-
timestamp modulation
-
Modern TCP stacks will send a timestamp on every TCP packet and echo - the other endpoint's timestamp back to them. Many operating systems - will merely start the timestamp at zero when first booted, and - increment it several times a second. The uptime of the host can be - deduced by reading the timestamp and multiplying by a constant. Also - observing several different timestamps can be used to count hosts - behind a NAT device. And spoofing TCP packets into a connection - requires knowing or guessing valid timestamps. Timestamps merely need - to be monotonically increasing and not derived off a guessable base - time. reassemble tcp will cause - scrub to modulate the TCP timestamps with a - random number.
-
extended PAWS checks
-
There is a problem with TCP on long fat pipes, in that a packet might - get delayed for longer than it takes the connection to wrap its 32-bit - sequence space. In such an occurrence, the old packet would be - indistinguishable from a new packet and would be accepted as such. The - solution to this is called PAWS: Protection Against Wrapped Sequence - numbers. It protects against it by making sure the timestamp on each - packet does not go backwards. reassemble tcp - also makes sure the timestamp on the packet does not go forward more - than the RFC allows. By doing this, pf(4) - artificially extends the security of TCP sequence numbers by 10 to 18 - bits when the host uses appropriately randomized timestamps, since a - blind attacker would have to guess the timestamp as well.
-
-
-
-

For example,

-
-
match in all scrub (no-df random-id max-mss 1440)
-
-
-
-

-

In order to maintain compatibility with older releases of FreeBSD - scrub rules can also be specified in their own - ruleset. In such case they are invoked with the scrub - directive. If there are such rules present they determine packet reassembly - behaviour. When no such rules are present the option set - reassembly takes precedence. The scrub rules can - take all parameters specified above for a scrub option - of filter rules and 2 more parameters controlling fragment reassembly:

-
-
fragment reassemble
-
Using scrub rules, fragments can be reassembled by - normalization. In this case, fragments are buffered until they form a - complete packet, and only the completed packet is passed on to the filter. - The advantage is that filter rules have to deal only with complete - packets, and can ignore fragments. The drawback of caching fragments is - the additional memory cost. This is the default behaviour unless no - fragment reassemble is specified.
-
no fragment reassemble
-
Do not reassemble fragments.
-
-

For example,

-
-
scrub in on $ext_if all fragment reassemble
-
-

The no option prefixed to a scrub rule - causes matching packets to remain unscrubbed, much in the same way as - drop quick works in the packet filter (see below). - This mechanism should be used when it is necessary to exclude specific - packets from broader scrub rules.

-

scrub rules in the - scrub ruleset are evaluated for every packet before - stateful filtering. This means excessive usage of them will cause - performance penalty. scrub reassemble tcp rules must - not have the direction (in/out) specified.

-
-
-
-

-

The ALTQ system is currently not available in the GENERIC kernel - nor as loadable modules. In order to use the herein after called queueing - options one has to use a custom built kernel. Please refer to - altq(4) to learn about the related kernel options.

-

Packets can be assigned to queues for the purpose of bandwidth - control. At least two declarations are required to configure queues, and - later any packet filtering rule can reference the defined queues by name. - During the filtering component of pf.conf, the last - referenced queue name is where any packets from - pass rules will be queued, while for - block rules it specifies where any resulting ICMP or - TCP RST packets should be queued. The scheduler - defines the algorithm used to decide which packets get delayed, dropped, or - sent out immediately. There are three schedulers - currently supported.

-
-
cbq
-
Class Based Queueing. Queues attached to an - interface build a tree, thus each queue can have - further child queues. Each queue can have a - priority and a bandwidth - assigned. Priority mainly controls the time packets - take to get sent out, while bandwidth has primarily - effects on throughput. cbq achieves both - partitioning and sharing of link bandwidth by hierarchically structured - classes. Each class has its own queue and is - assigned its share of bandwidth. A child class can - borrow bandwidth from its parent class as long as excess bandwidth is - available (see the option borrow, below).
-
priq
-
Priority Queueing. Queues are flat attached to the - interface, thus, queues cannot have further child - queues. Each queue has a - unique priority assigned, ranging from 0 to 15. - Packets in the queue with the highest - priority are processed first.
-
hfsc
-
Hierarchical Fair Service Curve. Queues attached to - an interface build a tree, thus each queue can have - further child queues. Each queue can have a - priority and a bandwidth - assigned. Priority mainly controls the time packets - take to get sent out, while bandwidth primarily - affects throughput. hfsc supports both link-sharing - and guaranteed real-time services. It employs a service curve based QoS - model, and its unique feature is an ability to decouple - delay and bandwidth - allocation.
-
-

The interfaces on which queueing should be activated are declared - using the altq on declaration. altq - on has the following keywords:

-
-
⟨interface⟩
-
Queueing is enabled on the named interface.
-
⟨scheduler⟩
-
Specifies which queueing scheduler to use. Currently supported values are - cbq for Class Based Queueing, - priq for Priority Queueing and - hfsc for the Hierarchical Fair Service Curve - scheduler.
-
bandwidth - ⟨bw⟩
-
The maximum bitrate for all queues on an interface may be specified using - the bandwidth keyword. The value can be specified as - an absolute value or as a percentage of the interface bandwidth. When - using an absolute value, the suffixes b, - Kb, Mb, and - Gb are used to represent bits, kilobits, megabits, - and gigabits per second, respectively. The value must not exceed the - interface bandwidth. If bandwidth is not specified, - the interface bandwidth is used (but take note that some interfaces do not - know their bandwidth, or can adapt their bandwidth rates).
-
qlimit - ⟨limit⟩
-
The maximum number of packets held in the queue. The default is 50.
-
tbrsize - ⟨size⟩
-
Adjusts the size, in bytes, of the token bucket regulator. If not - specified, heuristics based on the interface bandwidth are used to - determine the size.
-
queue - ⟨list⟩
-
Defines a list of subqueues to create on an interface.
-
-

In the following example, the interface dc0 should queue up to - 5Mbps in four second-level queues using Class Based Queueing. Those four - queues will be shown in a later example.

-
-
altq on dc0 cbq bandwidth 5Mb queue { std, http, mail, ssh }
-
-

Once interfaces are activated for queueing using the - altq directive, a sequence of - queue directives may be defined. The name associated - with a queue must match a queue defined in the - altq directive (e.g. mail), or, except for the - priq scheduler, in a parent - queue declaration. The following keywords can be - used:

-
-
on - ⟨interface⟩
-
Specifies the interface the queue operates on. If not given, it operates - on all matching interfaces.
-
bandwidth - ⟨bw⟩
-
Specifies the maximum bitrate to be processed by the queue. This value - must not exceed the value of the parent queue and - can be specified as an absolute value or a percentage of the parent - queue's bandwidth. If not specified, defaults to 100% of the parent - queue's bandwidth. The priq scheduler does not - support bandwidth specification.
-
priority - ⟨level⟩
-
Between queues a priority level can be set. For cbq - and hfsc, the range is 0 to 7 and for - priq, the range is 0 to 15. The default for all is - 1. Priq queues with a higher priority are always - served first. Cbq and Hfsc - queues with a higher priority are preferred in the case of overload.
-
qlimit - ⟨limit⟩
-
The maximum number of packets held in the queue. The default is 50.
-
-

The scheduler can get additional parameters - with ⟨scheduler⟩ - (⟨parameters⟩). Parameters are as - follows:

-
-
default
-
Packets not matched by another queue are assigned to this one. Exactly one - default queue is required.
-
red
-
Enable RED (Random Early Detection) on this queue. RED drops packets with - a probability proportional to the average queue length.
-
rio
-
Enables RIO on this queue. RIO is RED with IN/OUT, thus running RED two - times more than RIO would achieve the same effect. RIO is currently not - supported in the GENERIC kernel.
-
ecn
-
Enables ECN (Explicit Congestion Notification) on this queue. ECN implies - RED.
-
-

The cbq scheduler - supports an additional option:

-
-
borrow
-
The queue can borrow bandwidth from the parent.
-
-

The hfsc scheduler - supports some additional options:

-
-
realtime - ⟨sc⟩
-
The minimum required bandwidth for the queue.
-
upperlimit - ⟨sc⟩
-
The maximum allowed bandwidth for the queue.
-
linkshare - ⟨sc⟩
-
The bandwidth share of a backlogged queue.
-
-

⟨sc⟩ is an acronym for - service curve.

-

The format for service curve specifications is - (m1, d, - m2). m2 controls the bandwidth - assigned to the queue. m1 and d - are optional and can be used to control the initial bandwidth assignment. - For the first d milliseconds the queue gets the - bandwidth given as m1, afterwards the value given in - m2.

-

Furthermore, with cbq and - hfsc, child queues can be specified as in an - altq declaration, thus building a tree of queues using - a part of their parent's bandwidth.

-

Packets can be assigned to queues based on filter rules by using - the queue keyword. Normally only one - queue is specified; when a second one is specified it - will instead be used for packets which have a TOS of - lowdelay and for TCP ACKs with no data payload.

-

To continue the previous example, the examples below would specify - the four referenced queues, plus a few child queues. Interactive - ssh(1) sessions get priority over bulk transfers like - scp(1) and sftp(1). The queues may then - be referenced by filtering rules (see - PACKET FILTERING below).

-
-
queue std bandwidth 10% cbq(default)
-queue http bandwidth 60% priority 2 cbq(borrow red) \
-      { employees, developers }
-queue  developers bandwidth 75% cbq(borrow)
-queue  employees bandwidth 15%
-queue mail bandwidth 10% priority 0 cbq(borrow ecn)
-queue ssh bandwidth 20% cbq(borrow) { ssh_interactive, ssh_bulk }
-queue  ssh_interactive bandwidth 50% priority 7 cbq(borrow)
-queue  ssh_bulk bandwidth 50% priority 0 cbq(borrow)
-
-block return out on dc0 inet all queue std
-pass out on dc0 inet proto tcp from $developerhosts to any port 80 \
-      queue developers
-pass out on dc0 inet proto tcp from $employeehosts to any port 80 \
-      queue employees
-pass out on dc0 inet proto tcp from any to any port 22 \
-      queue(ssh_bulk, ssh_interactive)
-pass out on dc0 inet proto tcp from any to any port 25 \
-      queue mail
-
-
-
-

-

Queueing can also be done with dummynet(4). - Queues and pipes can be created with dnctl(8).

-

Packets can be assigned to queues and pipes using - dnqueue and dnpipe - respectively.

-

Both dnqueue and - dnpipe take either a single pipe or queue number or - two numbers as arguments. The first pipe or queue number will be used to - shape the traffic in the rule direction, the second will be used to shape - the traffic in the reverse direction. If the rule does not specify a - direction the first packet to create state will be shaped according to the - first number, and the response traffic according to the second.

-

If the dummynet(4) module is not loaded any - traffic sent into a queue or pipe will be dropped.

-
-
-

-

Translation options modify either the source or destination - address and port of the packets associated with a stateful connection. - pf(4) modifies the specified address and/or port in the - packet and recalculates IP, TCP, and UDP checksums as necessary.

-

If specified on a match rule, subsequent - rules will see packets as they look after any addresses and ports have been - translated. These rules will therefore have to filter based on the - translated address and port number.

-

The state entry created permits pf(4) to keep - track of the original address for traffic associated with that state and - correctly direct return traffic for that connection.

-

Various types of translation are possible with pf:

-
-
af-to
-
Translation between different address families (NAT64) is handled using - af-to rules. Because address family translation - overrides the routing table, it's only possible to use - af-to on inbound rules, and a source address of the - resulting translation must always be specified. -

The optional second argument is the host or subnet the - original addresses are translated into for the destination. The lowest - bits of the original destination address form the host part of the new - destination address according to the specified subnet. It is possible to - embed a complete IPv4 address into an IPv6 address using a network - prefix of /96 or smaller.

-

When a destination address is not specified, it is assumed - that the host part is 32-bit long. For IPv6 to IPv4 translation this - would mean using only the lower 32 bits of the original IPv6 destination - address. For IPv4 to IPv6 translation the destination subnet defaults to - the subnet of the new IPv6 source address with a prefix length of /96. - See RFC 6052 Section 2.2 for details on how the prefix determines the - destination address encoding.

-

For example, the following rules are identical:

-
- 
pass in inet af-to inet6 from 2001:db8::1 to 2001:db8::/96
-pass in inet af-to inet6 from 2001:db8::1
-
-

In the above example the matching IPv4 packets will be - modified to have a source address of 2001:db8::1 and a destination - address will get prefixed with 2001:db8::/96, e.g. 198.51.100.100 will - be translated to 2001:db8::c633:6464.

-

In the reverse case the following rules are identical:

-
- 
pass in inet6 from any to 64:ff9b::/96 af-to inet \
-       from 198.51.100.1 to 0.0.0.0/0
-pass in inet6 from any to 64:ff9b::/96 af-to inet \
-       from 198.51.100.1
-
-

The destination IPv4 address is assumed to be embedded inside - the original IPv6 destination address, e.g. 64:ff9b::c633:6464 will be - translated to 198.51.100.100.

-

The current implementation will only extract IPv4 addresses - from the IPv6 addresses with a prefix length of /96 and greater.

-
-
binat-to
-
A binat-to rule specifies a bidirectional mapping - between an external IP netblock and an internal IP netblock. It expands to - an outbound nat-to rule and an inbound - rdr-to rule.
-
nat-to
-
A nat-to option specifies that IP addresses are to - be changed as the packet traverses the given interface. This technique - allows one or more IP addresses on the translating host to support network - traffic for a larger range of machines on an "inside" network. - Although in theory any IP address can be used on the inside, it is - strongly recommended that one of the address ranges defined by RFC 1918 be - used. These netblocks are: -
- 
10.0.0.0 - 10.255.255.255 (all of net 10.0.0.0, i.e., 10.0.0.0/8)
-172.16.0.0 - 172.31.255.255 (i.e., 172.16.0.0/12)
-192.168.0.0 - 192.168.255.255 (i.e., 192.168.0.0/16)
-
-

nat-to is usually applied outbound. If - applied inbound, nat-to to a local IP address is not supported.

-
-
rdr-to
-
The packet is redirected to another destination and possibly a different - port. rdr-to can optionally specify port ranges - instead of single ports. For instance: -
- 
match in ... port 2000:2999 rdr-to ... port 4000
-
- redirects ports 2000 to 2999 (inclusive) to port 4000. -
- 
qmatch in ... port 2000:2999 rdr-to ... port 4000:*
-
- redirects port 2000 to 4000, 2001 to 4001, ..., 2999 to 4999.
-
-

rdr-to is usually applied inbound. If - applied outbound, rdr-to to a local IP address is not supported. In addition - to modifying the address, some translation rules may modify source or - destination ports for tcp(4) or udp(4) - connections; implicitly in the case of nat-to options - and both implicitly and explicitly in the case of - rdr-to ones. A rdr-to option may - cause the source port to be modified if doing so avoids a conflict with an - existing connection. A random source port in the range 50001-65535 is chosen - in this case. Port numbers are never translated with a - binat-to option.

-

Note that redirecting external incoming connections to the - loopback address, as in

-
-
pass in on egress proto tcp from any to any port smtp \
-      rdr-to 127.0.0.1 port spamd
-
-

will effectively allow an external host to connect to daemons - bound solely to the loopback address, circumventing the traditional blocking - of such connections on a real interface. Unless this effect is desired, any - of the local non-loopback addresses should be used as redirection target - instead, which allows external connections only to daemons bound to this - address or not bound to any address.

-

See TRANSLATION - EXAMPLES below.

-
-

-

In order to maintain compatibility with older releases of FreeBSD - NAT rules can also be specified in their own ruleset. - A stateful connection is automatically created to track packets matching - such a rule as long as they are not blocked by the filtering section of - pf.conf. Since translation occurs before filtering - the filter engine will see packets as they look after any addresses and - ports have been translated. Filter rules will therefore have to filter based - on the translated address and port number. Packets that match a translation - rule are only automatically passed if the pass - modifier is given, otherwise they are still subject to - block and pass rules.

-

The following rules can be defined in the NAT ruleset: - binat, nat, and - rdr. They have the same effect as - binat-to, nat-to and - rdr-to options for filter rules.

-

The no option prefixed to a translation rule - causes packets to remain untranslated, much in the same way as - drop quick works in the packet filter. If no rule - matches the packet it is passed to the filter engine unmodified.

-

Evaluation order of the translation rules is dependent on the type - of the translation rules and of the direction of a packet. - binat rules are always evaluated first. Then either - the rdr rules are evaluated on an inbound packet or - the nat rules on an outbound packet. Rules of the same - type are evaluated in the same order in which they appear in the ruleset. - The first matching rule decides what action is taken.

-

Translation rules apply only to packets that pass through the - specified interface, and if no interface is specified, translation is - applied to packets on all interfaces. For instance, redirecting port 80 on - an external interface to an internal web server will only work for - connections originating from the outside. Connections to the address of the - external interface from local hosts will not be redirected, since such - packets do not actually pass through the external interface. Redirections - cannot reflect packets back through the interface they arrive on, they can - only be redirected to hosts connected to different interfaces or to the - firewall itself.

-

See - COMPATIBILITY - TRANSLATION EXAMPLES below.

-
-
-
-

-

pf(4) has the ability to - block , pass and - match packets based on attributes of their layer 3 - (see ip(4) and ip6(4)) and layer 4 (see - icmp(4), icmp6(4), - tcp(4), sctp(4), - udp(4)) headers. In addition, packets may also be assigned - to queues for the purpose of bandwidth control.

-

For each packet processed by the packet filter, the filter rules - are evaluated in sequential order, from first to last. For - block and pass , the last - matching rule decides what action is taken. For match - , rules are evaluated every time they match; the pass/block state of a - packet remains unchanged. If no rule matches the packet, the default action - is to pass the packet.

-

The following actions can be used in the filter:

-
-
block
-
The packet is blocked. There are a number of ways in which a - block rule can behave when blocking a packet. The - default behaviour is to drop packets silently, - however this can be overridden or made explicit either globally, by - setting the block-policy option, or on a per-rule - basis with one of the following options: -

-
-
drop
-
The packet is silently dropped.
-
return-rst
-
This applies only to tcp(4) packets, and issues a - TCP RST which closes the connection.
-
return-icmp
-
 
-
return-icmp6
-
This causes ICMP messages to be returned for packets which match the - rule. By default this is an ICMP UNREACHABLE message, however this can - be overridden by specifying a message as a code or number.
-
return
-
This causes a TCP RST to be returned for tcp(4) - packets, an SCTP ABORT for SCTP and an ICMP UNREACHABLE for UDP and - other packets.
-
-

Options returning ICMP packets currently have no effect if - pf(4) operates on a if_bridge(4), as - the code to support this feature has not yet been implemented.

-

The simplest mechanism to block everything by default and only - pass packets that match explicit rules is specify a first filter rule - of:

-
- 
block all
-
-
-
match
-
The packet is matched. This mechanism is used to provide fine grained - filtering without altering the block/pass state of a packet. - match rules differ from block - and pass rules in that parameters are set for every - rule a packet matches, not only on the last matching rule. For the - following parameters, this means that the parameter effectively becomes - "sticky" until explicitly overridden: - nat-to, binat-to, - rdr-to, queue, - dnpipe, dnqueue, - rtable, scrub
-
pass
-
The packet is passed; state is created unless the no - state option is specified.
-
-

By default pf(4) filters packets statefully; the - first time a packet matches a pass rule, a state entry - is created; for subsequent packets the filter checks whether the packet - matches any state. If it does, the packet is passed without evaluation of - any rules. After the connection is closed or times out, the state entry is - automatically removed.

-

This has several advantages. For TCP connections, comparing a - packet to a state involves checking its sequence numbers, as well as TCP - timestamps if a scrub reassemble tcp rule applies to - the connection. If these values are outside the narrow windows of expected - values, the packet is dropped. This prevents spoofing attacks, such as when - an attacker sends packets with a fake source address/port but does not know - the connection's sequence numbers. Similarly, pf(4) knows - how to match ICMP replies to states. For example,

-
-
pass out inet proto icmp all icmp-type echoreq
-
-

allows echo requests (such as those created by - ping(8)) out statefully, and matches incoming echo replies - correctly to states.

-

Also, looking up states is usually faster than evaluating - rules.

-

Furthermore, correct handling of ICMP error messages is critical - to many protocols, particularly TCP. pf(4) matches ICMP - error messages to the correct connection, checks them against connection - parameters, and passes them if appropriate. For example if an ICMP source - quench message referring to a stateful TCP connection arrives, it will be - matched to the state and get passed.

-

Finally, state tracking is required for nat, - binat and - rdr rules, in order to track address and port - translations and reverse the translation on returning packets.

-

pf(4) will also create state for other protocols - which are effectively stateless by nature. UDP packets are matched to states - using only host addresses and ports, and other protocols are matched to - states using only the host addresses.

-

If stateless filtering of individual packets is desired, the - no state keyword can be used to specify that state - will not be created if this is the last matching rule. A number of - parameters can also be set to affect how pf(4) handles - state tracking. See STATEFUL - TRACKING OPTIONS below for further details.

-
-

-

The rule parameters specify the packets to which a rule applies. A - packet always comes in on, or goes out through, one interface. Most - parameters are optional. If a parameter is specified, the rule only applies - to packets with matching attributes. Certain parameters can be expressed as - lists, in which case pfctl(8) generates all needed rule - combinations.

-
-
in or - out
-
This rule applies to incoming or outgoing packets. If neither - in nor out are specified, the - rule will match packets in both directions.
-
log (all | - matches | to - ⟨interface⟩ | - user)
-
In addition to any action specified, log the packet. Only the packet that - establishes the state is logged, unless the no state - option is specified. The logged packets are sent to a - pflog(4) interface, by default pflog0; pflog0 is - monitored by the pflogd(8) logging daemon which logs to - the file /var/log/pflog in - pcap(3) binary format. -

The keywords all, - matches, to, and - user are optional and can be combined using - commas, but must be enclosed in parentheses if given.

-

Use all to force logging of all - packets for a connection. This is not necessary when no - state is explicitly specified.

-

If matches is specified, it logs the - packet on all subsequent matching rules. It is often combined with - to - ⟨interface⟩ to avoid adding noise to - the default log file.

-

The keyword user logs the - UNIX user ID of the user that owns the socket - and the PID of the process that has the socket open where the packet is - sourced from or destined to (depending on which socket is local). This - is in addition to the normal information logged.

-

Only the first packet logged via log (all, - user) will have the user credentials logged when using stateful - matching.

-

To specify a logging interface other than pflog0, use the - syntax to - ⟨interface⟩.

-
-
quick
-
If a packet matches a rule which has the quick - option set, this rule is considered the last matching rule, and evaluation - of subsequent rules is skipped.
-
on - ⟨interface⟩
-
This rule applies only to packets coming in on, or going out through, this - particular interface or interface group. For more information on interface - groups, see the group keyword in - ifconfig(8). any will match any - existing interface except loopback ones.
-
⟨af⟩
-
This rule applies only to packets of this address family. Supported values - are inet and inet6.
-
proto - ⟨protocol⟩
-
This rule applies only to packets of this protocol. Common protocols are - icmp(4), icmp6(4), - tcp(4), sctp(4), and - udp(4). For a list of all the protocol name to number - mappings used by pfctl(8), see the file - /etc/protocols.
-
from ⟨source⟩ - port ⟨source⟩ - os ⟨source⟩ - to ⟨dest⟩ - port ⟨dest⟩
-
This rule applies only to packets with the specified source and - destination addresses and ports. -

Addresses can be specified in CIDR notation (matching - netblocks), as symbolic host names, interface names or interface group - names, or as any of the following keywords:

-

-
-
any
-
Any address.
-
no-route
-
Any address which is not currently routable.
-
urpf-failed
-
Any source address that fails a unicast reverse path forwarding (URPF) - check, i.e. packets coming in on an interface other than that which - holds the route back to the packet's source address.
-
self
-
Expands to all addresses assigned to all interfaces.
-
⟨table⟩
-
Any address that matches the given table.
-
-

Ranges of addresses are specified by using the - ‘-’ operator. For instance: “10.1.1.10 - - 10.1.1.12” means all addresses from 10.1.1.10 to 10.1.1.12, hence - addresses 10.1.1.10, 10.1.1.11, and 10.1.1.12.

-

Interface names and interface group names, and - self can have modifiers appended:

-

-
-
:network
-
Translates to the network(s) attached to the interface.
-
:broadcast
-
Translates to the interface's broadcast address(es).
-
:peer
-
Translates to the point-to-point interface's peer address(es).
-
:0
-
Do not include interface aliases.
-
-

Host names may also have the :0 option - appended to restrict the name resolution to the first of each v4 and - non-link-local v6 address found.

-

Host name resolution and interface to address translation are - done at ruleset load-time. When the address of an interface (or host - name) changes (under DHCP or PPP, for instance), the ruleset must be - reloaded for the change to be reflected in the kernel. Surrounding the - interface name (and optional modifiers) in parentheses changes this - behaviour. When the interface name is surrounded by parentheses, the - rule is automatically updated whenever the interface changes its - address. The ruleset does not need to be reloaded. This is especially - useful with nat.

-

Ports can be specified either by number or by name. - For example, port 80 can be specified as - . For a list - of all port name to number mappings used by pfctl(8), - see the file /etc/services.

-

Ports and ranges of ports are specified by using these - operators:

-
- 
=	(equal)
-!=	(unequal)
-<	(less than)
-<=	(less than or equal)
->	(greater than)
->=	(greater than or equal)
-:	(range including boundaries)
-><	(range excluding boundaries)
-<>	(except range)
-
-

‘><’, ‘<>’ and - ‘:’ are binary operators (they take two arguments). For - instance:

-
-
port 2000:2004
-
means ‘all ports >= 2000 and <= 2004’, hence ports - 2000, 2001, 2002, 2003 and 2004.
-
port 2000 >< 2004
-
means ‘all ports > 2000 and < 2004’, hence ports - 2001, 2002 and 2003.
-
port 2000 <> 2004
-
means ‘all ports < 2000 or > 2004’, hence ports - 1-1999 and 2005-65535.
-
-

The operating system of the source host can be specified in - the case of TCP rules with the OS modifier. See - the OPERATING - SYSTEM FINGERPRINTING section for more information.

-

The host, port and OS specifications are optional, as in the - following examples:

-
- 
pass in all
-pass in from any to any
-pass in proto tcp from any port < 1024 to any
-pass in proto tcp from any to any port 25
-pass in proto tcp from 10.0.0.0/8 port >= 1024 \
-      to ! 10.1.2.3 port != ssh
-pass in proto tcp from any os "OpenBSD"
-
-
-
all
-
This is equivalent to "from any to any".
-
group - ⟨group⟩
-
Similar to user, this rule only applies to packets - of sockets owned by the specified group.
-
user ⟨user⟩
-
This rule only applies to packets of sockets owned by the specified user. - For outgoing connections initiated from the firewall, this is the user - that opened the connection. For incoming connections to the firewall - itself, this is the user that listens on the destination port. For - forwarded connections, where the firewall is not a connection endpoint, - the user and group are unknown. -

All packets, both outgoing and incoming, of one connection are - associated with the same user and group. Only TCP and UDP packets can be - associated with users; for other protocols these parameters are - ignored.

-

User and group refer to the effective (as opposed to the real) - IDs, in case the socket is created by a setuid/setgid process. User and - group IDs are stored when a socket is created; when a process creates a - listening socket as root (for instance, by binding to a privileged port) - and subsequently changes to another user ID (to drop privileges), the - credentials will remain root.

-

User and group IDs can be specified as either numbers or - names. The syntax is similar to the one for ports. The value - unknown matches packets of forwarded connections. - unknown can only be used with the operators - = and !=. Other - constructs like user ≥ unknown are - invalid. Forwarded packets with unknown user and group ID match only - rules that explicitly compare against unknown with the - operators = or !=. For - instance user ≥ 0 does not match - forwarded packets. The following example allows only selected users to - open outgoing connections:

-
- 
block out proto { tcp, udp } all
-pass  out proto { tcp, udp } all user { < 1000, dhartmei }
-
-

The example below permits users with uid between 1000 and 1500 - to open connections:

-
- 
block out proto tcp all
-pass  out proto tcp from self user { 999 >< 1501 }
-
-

The ‘:’ operator, which works for port number - matching, does not work for user and - group match.

-
-
flags ⟨a⟩ - /⟨b⟩ | - /⟨b⟩ | - any
-
This rule only applies to TCP packets that have the flags - ⟨a⟩ set out of set - ⟨b⟩. Flags not specified in - ⟨b⟩ are ignored. For stateful - connections, the default is flags S/SA. To indicate - that flags should not be checked at all, specify flags - any. The flags are: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK, (U)RG, - (E)CE, and C(W)R. -
-
flags S/S
-
Flag SYN is set. The other flags are ignored.
-
flags S/SA
-
This is the default setting for stateful connections. Out of SYN and - ACK, exactly SYN may be set. SYN, SYN+PSH and SYN+RST match, but - SYN+ACK, ACK and ACK+RST do not. This is more restrictive than the - previous example.
-
flags /SFRA
-
If the first set is not specified, it defaults to none. All of SYN, - FIN, RST and ACK must be unset.
-
-

Because flags S/SA is applied by default - (unless no state is specified), only the initial - SYN packet of a TCP handshake will create a state for a TCP connection. - It is possible to be less restrictive, and allow state creation from - intermediate (non-SYN) packets, by specifying flags - any. This will cause pf(4) to synchronize to - existing connections, for instance if one flushes the state table. - However, states created from such intermediate packets may be missing - connection details such as the TCP window scaling factor. States which - modify the packet flow, such as those affected by - af-to, nat, - binat or rdr rules, - modulate or - synproxy state options, or scrubbed with - reassemble tcp will also not be recoverable from - intermediate packets. Such connections will stall and time out.

-
-
icmp-type ⟨type⟩ - file ... [code - ⟨code⟩]
-
 
-
icmp6-type - ⟨type⟩ file ... - [code ⟨code⟩]
-
This rule only applies to ICMP or ICMPv6 packets with the specified type - and code. Text names for ICMP types and codes are listed in - icmp(4) and icmp6(4). This parameter - is only valid for rules that cover protocols ICMP or ICMP6. The protocol - and the ICMP type indicator (icmp-type or - icmp6-type) must match.
-
tos ⟨string⟩ | - ⟨number⟩
-
This rule applies to packets with the specified TOS bits - set. TOS may be given as one of - critical, inetcontrol, - lowdelay, netcontrol, - throughput, reliability, or - one of the DiffServ Code Points: ef, - va, af11 - ... af43, - cs0 ... - cs7; or as either hex or decimal. -

For example, the following rules are identical:

-
- 
pass all tos lowdelay
-pass all tos 0x10
-pass all tos 16
-
-
-
allow-opts
-
By default, packets with IPv4 options or IPv6 hop-by-hop or destination - options header are blocked. When allow-opts is - specified for a pass rule, packets that pass the - filter based on that rule (last matching) do so even if they contain - options. For packets that match state, the rule that initially created the - state is used. The implicit pass rule, that is used - when a packet does not match any rules, does not allow IP options or - option headers. Note that IPv6 packets with type 0 routing headers are - always dropped.
-
label - ⟨string⟩
-
Adds a label (name) to the rule, which can be used to identify the rule. - For instance, pfctl -s labels shows per-rule statistics for rules that - have labels. -

The following macros can be used in labels:

-

-
-
-
$if
-
The interface.
-
$srcaddr
-
The source IP address.
-
$dstaddr
-
The destination IP address.
-
$srcport
-
The source port specification.
-
$dstport
-
The destination port specification.
-
$proto
-
The protocol name.
-
$nr
-
The rule number.
-
-
-

For example:

-
- 
ips = "{ 1.2.3.4, 1.2.3.5 }"
-pass in proto tcp from any to $ips \
-      port > 1023 label "$dstaddr:$dstport"
-
-

expands to

-
- 
pass in inet proto tcp from any to 1.2.3.4 \
-      port > 1023 label "1.2.3.4:>1023"
-pass in inet proto tcp from any to 1.2.3.5 \
-      port > 1023 label "1.2.3.5:>1023"
-
-

The macro expansion for the label - directive occurs only at configuration file parse time, not during - runtime.

-
-
ridentifier - ⟨number⟩
-
Add an identifier (number) to the rule, which can be used to correlate the - rule to pflog entries, even after ruleset updates.
-
- number/seconds
-
Measure the rate of packets matching the rule and states created by it. - When the specified rate is exceeded, the rule stops matching. Only packets - in the direction in which the state was created are considered, so that - typically requests are counted and replies are not. For example, to pass - up to 100 ICMP packets per 10 seconds: -
- 
block in proto icmp
-pass in proto icmp max-pkt-rate 100/10
-
-

When the rate is exceeded, all ICMP is blocked until the rate - falls below 100 per 10 seconds again.

-
-
max-pkt-size - ⟨number⟩
-
Limit each packet to be no more than the specified number of bytes. This - includes the IP header, but not any layer 2 header.
-
once
-
Create a one shot rule. The first matching packet marks the rule as - expired. Expired rules are skipped and hidden, unless - pfctl(8) is used in debug or verbose mode.
-
queue ⟨queue⟩ | - (⟨queue⟩, - ⟨queue⟩)
-
Packets matching this rule will be assigned to the specified queue. If two - queues are given, packets which have a TOS of - lowdelay and TCP ACKs with no data payload will be - assigned to the second one. See - QUEUEING for setup details. -

For example:

-
- 
pass in proto tcp to port 25 queue mail
-pass in proto tcp to port 22 queue(ssh_bulk, ssh_prio)
-
-
-
priority | - (priority, priority)
-
Packets matching this rule will be assigned a specific queueing priority. - Priorities are assigned as integers 0 through 7. If the packet is - transmitted on a vlan(4) interface, the queueing - priority will be written as the priority code point in the 802.1Q VLAN - header. If two priorities are given, TCP ACKs with no data payload and - packets which have a TOS of lowdelay will be - assigned to the second one. -

For example:

-
- 
pass in proto tcp to port 25 set prio 2
-pass in proto tcp to port 22 set prio (2, 5)
-
-
-
[!]received-on - interface
-
Only match packets which were received on the specified - interface (or interface group). - any will match any existing interface except - loopback ones.
-
tag - ⟨string⟩
-
Packets matching this rule will be tagged with the specified string. The - tag acts as an internal marker that can be used to identify these packets - later on. This can be used, for example, to provide trust between - interfaces and to determine if packets have been processed by translation - rules. Tags are "sticky", meaning that the packet will be tagged - even if the rule is not the last matching rule. Further matching rules can - replace the tag with a new one but will not remove a previously applied - tag. A packet is only ever assigned one tag at a time. Packet tagging can - be done during nat, rdr, - binat or ether rules in - addition to filter rules. Tags take the same macros as labels (see - above).
-
tagged - ⟨string⟩
-
Used with filter, translation or scrub rules to specify that packets must - already be tagged with the given tag in order to match the rule.
-
rtable - ⟨number⟩
-
Used to select an alternate routing table for the routing lookup. Only - effective before the route lookup happened, i.e. when filtering - inbound.
-
divert-to ⟨host⟩ - port ⟨port⟩
-
Used to divert(4) packets to the given divert - port. Historically OpenBSD - pf has another meaning for this, and FreeBSD - pf uses this syntax to support divert(4) instead. - Hence, host has no meaning and can be set to - anything like 127.0.0.1. If a packet is re-injected and does not change - direction then it will not be re-diverted.
-
divert-reply
-
It has no meaning in FreeBSD pf.
-
probability - ⟨number⟩
-
A probability attribute can be attached to a rule, with a value set - between 0 and 1, bounds not included. In that case, the rule will be - honoured using the given probability value only. For example, the - following rule will drop 20% of incoming ICMP packets: -
- 
block in proto icmp probability 20%
-
-
-
name [(limiter - options)]
-
Use the specified state limiter to restrict the creation of states by this - rule. By default if capacity is not available, the packet gets blocked and - ruleset evaluation stops. Use no-match option to - change default behavior such rule is ignored and ruleset evaluation - continues with next rule. See the - State Limiters section for more - information.
-
name [(limiter - options)]
-
Use the specified source limiter to restrict the creation of states by - this rule. By default if capacity is not available, the packet gets - blocked and ruleset evaluation stops. Use no-match - option to change default behavior such rule is ignored and ruleset - evaluation continues with next rule. See the - Source Limiters section for more - information.
-
prio - ⟨number⟩
-
Only match packets which have the given queueing priority assigned.
-
-
-
-
-

-

If a packet matches a rule with a route option set, the packet - filter will route the packet according to the type of route option. When - such a rule creates state, the route option is also applied to all packets - matching the same connection.

-
-
route-to
-
The route-to option routes the packet to the - specified interface with an address for the next hop. When a - route-to rule creates state, only packets that pass - in the same direction as the filter rule specifies will be routed in this - way. Packets passing in the opposite direction (replies) are not affected - and are routed normally.
-
reply-to
-
The reply-to option is similar to - route-to, but routes packets that pass in the - opposite direction (replies) to the specified interface. Opposite - direction is only defined in the context of a state entry, and - reply-to is useful only in rules that create state. - It can be used on systems with multiple external connections to route all - outgoing packets of a connection through the interface the incoming - connection arrived through (symmetric routing enforcement).
-
dup-to
-
The dup-to option creates a duplicate of the packet - and routes it like route-to. The original packet - gets routed as it normally would.
-
-

Unlike the kernel's normal forwarding path, the route option - forwarding path does not drop broadcast or multicast traffic when the output - interface has been overridden by a route option. If a - route-to, reply-to, or - dup-to rule matches traffic destined to a broadcast - address (either the limited broadcast or a subnet-directed broadcast) or to - an IPv4/IPv6 multicast address, the packet is forwarded out the specified - interface, which may cross broadcast domains.

-

Rulesets that use route-to, - reply-to, or dup-to with a - permissive destination (e.g. from any to any) can - plug this leak with explicit block out rules on the - route option's target interface. To avoid blocking the router's own - broadcast or multicast traffic, scope the block rules to forwarded packets - with the received-on any qualifier. For example, - assuming $wan is the route-to - target interface:

-
-
block out quick on $wan inet  from any to 255.255.255.255  received-on any
-block out quick on $wan inet  from any to ($wan:broadcast) received-on any
-block out quick on $wan inet  from any to 224.0.0.0/4      received-on any
-block out quick on $wan inet6 from any to ff00::/8         received-on any
-
-

One block-out rule set is needed per interface that may be used as - a route option target.

-
-
-

-

For nat and rdr rules, - (as well as for the route-to, - reply-to and dup-to rule - options) for which there is a single redirection address which has a subnet - mask smaller than 32 for IPv4 or 128 for IPv6 (more than one IP address), a - variety of different methods for assigning this address can be used:

-
-
bitmask
-
The bitmask option applies the network portion of - the redirection address to the address to be modified (source with - nat, destination with - rdr).
-
random
-
The random option selects an address at random - within the defined block of addresses.
-
source-hash
-
The source-hash option uses a hash of the source - address to determine the redirection address, ensuring that the - redirection address is always the same for a given source. An optional key - can be specified after this keyword either in hex or as a string; by - default pfctl(8) randomly generates a key for - source-hash every time the ruleset is reloaded.
-
round-robin
-
The round-robin option loops through the redirection - address(es). -

When more than one redirection address is specified, - bitmask is not permitted as a pool type.

-
-
static-port
-
With nat rules, the - static-port option prevents pf(4) - from modifying the source port on TCP and UDP packets.
-
map-e-portset - ⟨psid-offset⟩ / - ⟨psid-len⟩ / - ⟨psid⟩
-
With nat rules, the - map-e-portset option enables the source port - translation of MAP-E (RFC 7597) Customer Edge. In order to make the host - act as a MAP-E Customer Edge, setting up a tunneling interface and pass - rules for encapsulated packets are required in addition to the - map-e-portset nat rule. -

For example:

-
- 
nat on $gif_mape_if from $int_if:network to any \
-      -> $ipv4_mape_src map-e-portset 6/8/0x34
-
-

sets PSID offset 6, PSID length 8, PSID 0x34.

-
-
endpoint-independent
-
With nat rules, the - endpoint-independent option caues - pf(4) to always map connections from a UDP source - address and port to the same NAT address and port. This feature implements - "full-cone" NAT behavior.
-
-

Additionally, options sticky-address and - prefer-ipv6-nexthop can be specified to influence how - IP addresses selected from pools.

-

The sticky-address option can be specified - to help ensure that multiple connections from the same source are mapped to - the same redirection address. This option can be used with the - random and round-robin pool - options. Note that by default these associations are destroyed as soon as - there are no longer states which refer to them; in order to make the - mappings last beyond the lifetime of the states, increase the global options - with set timeout src.track. See - STATEFUL TRACKING - OPTIONS for more ways to control the source tracking.

-

The prefer-ipv6-nexthop option allows for - IPv6 addresses to be used as the nexthop for IPv4 packets routed with the - route-to rule option. If a table is used with IPv4 and - IPv6 addresses, first the IPv6 addresses will be used in round-robin - fashion, then IPv4 addresses.

-
-
-

-

Much of the security derived from TCP is attributable to how well - the initial sequence numbers (ISNs) are chosen. Some popular stack - implementations choose - poor - ISNs and thus are normally susceptible to ISN prediction exploits. By - applying a modulate state rule to a TCP connection, - pf(4) will create a high quality random sequence number - for each connection endpoint.

-

The modulate state directive implicitly - keeps state on the rule and is only applicable to TCP connections.

-

For instance:

-
-
block all
-pass out proto tcp from any to any modulate state
-pass in  proto tcp from any to any port 25 flags S/SFRA modulate state
-
-

Note that modulated connections will not recover when the state - table is lost (firewall reboot, flushing the state table, etc...). - pf(4) will not be able to infer a connection again after - the state table flushes the connection's modulator. When the state is lost, - the connection may be left dangling until the respective endpoints time out - the connection. It is possible on a fast local network for the endpoints to - start an ACK storm while trying to resynchronize after the loss of the - modulator. The default flags settings (or a more - strict equivalent) should be used on modulate state - rules to prevent ACK storms.

-

Note that alternative methods are available to prevent loss of the - state table and allow for firewall failover. See carp(4) - and pfsync(4) for further information.

-
-
-

-

By default, pf(4) passes packets that are part - of a tcp(4) handshake between the endpoints. The - synproxy state option can be used to cause - pf(4) itself to complete the handshake with the active - endpoint, perform a handshake with the passive endpoint, and then forward - packets between the endpoints.

-

No packets are sent to the passive endpoint before the active - endpoint has completed the handshake, hence so-called SYN floods with - spoofed source addresses will not reach the passive endpoint, as the sender - can't complete the handshake.

-

The proxy is transparent to both endpoints, they each see a single - connection from/to the other endpoint. pf(4) chooses - random initial sequence numbers for both handshakes. Once the handshakes are - completed, the sequence number modulators (see previous section) are used to - translate further packets of the connection. synproxy - state includes modulate state.

-

Rules with synproxy will not work if - pf(4) operates on a bridge(4). Also they - act on incoming SYN packets only.

-

Example:

-
-
pass in proto tcp from any to any port www synproxy state
-
-
-

-

State limiters provide a mechanism to limit the number of states - created, or the rate of state creation, by a set of rules. State limiters - are configured and loaded with the main ruleset, but can be used by rules in - any anchor. The overall number of states is still subject to the limit set - with set limit states, but the number of states - created by a subset of rules can be provided by a state limiter.

-

A state limiter is configured with the following statement:

-

-
-
name
-
Each state limiter is identified by a unique name.
-
-

State limiters support the following configuration:

-

-
-
- number
-
A unique identifier between 1 and 255. This configuration is - required.
-
- number
-
Specify the maximum number of states. This configuration is required.
-
- number/seconds
-
Limit the rate at which states can be created over a time interval. The - connection rate is an approximation calculated as a moving average.
-
-

Pass rules can specify a state limiter using the - state limiter name option. If - the number of states allowed has hit the limit, the pass rule does not match - and ruleset evaluation continues past it.

-

An example use case for a state limiter is to restrict the number - of connections allowed to a service that is accessible via multiple - protocols, e.g. a DNS server that can be accessed by both TCP and UDP on - port 53, DNS-over-TLS on TCP port 853, and DNS-over-HTTPS on TCP port 443 - can be limited to 1000 concurrent connections:

-

-
-
state limiter "dns-server" id 1 limit 1000
-
-pass in proto { tcp udp } to port domain state limiter "dns-server"
-pass in proto tcp to port { 853 443 } state limiter "dns-server"
-
-
-
-

-

Source limiters apply limits on the number of states, or the rate - of state creation, for connections coming from a source address or network - for a set of rules. Source limiters are configured and loaded with the main - ruleset, but can be used by rules in any anchor. The overall number of - states is still subject to the limit set with set limit - states, but limits on states for a subset of source addresses and - rules can be provided with source limiters.

-

Source address entries in source pools are created on demand, and - are used to account for the states created for each source address or - network. A source limiter specifies the maximum number of source address - entries it will track, and can be configured to mask bits in network - prefixes to have source entries cover larger portions of the address space - if needed.

-

A source limiter is configured with the following statement:

-

-
-
name
-
Each source limiter is uniquely identified by the specified name.
-
-

Source limiter support the following configuration:

-

-
-
- number
-
A unique identifier between 1 and 255. This configuration is - required.
-
- number
-
Specify the maximum number of source address entries. This configuration - is required.
-
- number
-
Specify the maximum number of states for each source address entry. This - configuration is required.
-
- number/seconds
-
Limit the rate at which states can be created by each source address entry - over a time interval. The connection rate is an approximation calculated - as a moving average.
-
prefixlen
-
Mask IPv4 source addresses using the prefix length specified with - prefixlen when creating an address entry. The - default IPv4 prefix length is 32 bits.
-
prefixlen
-
Mask IPv6 source addresses using the prefix length specified with - prefixlen when creating an address entry. The - default IPv6 prefix length is 128 bits.
-
table> above - hwm [below - lwm]
-
Add the address to the specified table when the - number of states goes above the hwm high water mark. - The address will be removed from the table when the number of states drops - below the lwm low water mark. The default low water - mark is 0.
-
-

Pass rules can specify a source limiter using the - source limiter name - option.

-

An example use for a source limiter is the mitigation of denial of - service caused by the exhaustion of firewall resources by network or port - scans from outside the network. The states created by any one scanner from - any one source address can be limited to avoid impacting other sources. - Below, up to 10000 IPv4 hosts and IPv6 /64 networks from the external - network are each limited to a maximum of 1000 connections, and are rate - limited to creating 100 states over a 10 second interval:

-

-
-
source limiter "internet" id 1 entries 10000 \
-       limit 1000 rate 100/10 \
-       inet6 mask 64
-
-block in on egress
-pass in on egress source limiter "internet"
-
-
-
-
-

-

A number of options related to stateful tracking can be applied on - a per-rule basis. keep state, modulate - state and synproxy state support these options, - and keep state must be specified explicitly to apply - options to a rule.

-

-
-
max - ⟨number⟩
-
Limits the number of concurrent states the rule may create. When this - limit is reached, further packets that would create state are dropped - until existing states time out.
-
no-sync
-
Prevent state changes for states created by this rule from appearing on - the pfsync(4) interface.
-
⟨timeout⟩ - ⟨seconds⟩
-
Changes the timeout values used for states created by this rule. For a - list of all valid timeout names, see - OPTIONS above.
-
sloppy
-
Uses a sloppy TCP connection tracker that does not check sequence numbers - at all, which makes insertion and ICMP teardown attacks way easier. This - is intended to be used in situations where one does not see all packets of - a connection, e.g. in asymmetric routing situations. Cannot be used with - modulate or synproxy state.
-
pflow
-
States created by this rule are exported on the pflow(4) - interface.
-
allow-related
-
Automatically allow connections related to this one, regardless of rules - that might otherwise affect them. This currently only applies to SCTP - multihomed connection.
-
-

Multiple options can be specified, separated by commas:

-
-
pass in proto tcp from any to any \
-      port www keep state \
-      (max 100, source-track rule, max-src-nodes 75, \
-      max-src-states 3, tcp.established 60, tcp.closing 5)
-
-

When the source-track keyword is specified, - the number of states per source IP is tracked.

-

-
-
source-track rule
-
The maximum number of states created by this rule is limited by the rule's - max-src-nodes and - max-src-states options. Only state entries created - by this particular rule count toward the rule's limits.
-
source-track global
-
The number of states created by all rules that use this option is limited. - Each rule can specify different max-src-nodes and - max-src-states options, however state entries - created by any participating rule count towards each individual rule's - limits.
-
-

The following limits can be set:

-

-
-
max-src-nodes - ⟨number⟩
-
Limits the maximum number of source addresses which can simultaneously - have state table entries.
-
max-src-states - ⟨number⟩
-
Limits the maximum number of simultaneous state entries that a single - source address can create with this rule.
-
-

For stateful TCP connections, limits on established connections - (connections which have completed the TCP 3-way handshake) can also be - enforced per source IP.

-

-
-
max-src-conn - ⟨number⟩
-
Limits the maximum number of simultaneous TCP connections which have - completed the 3-way handshake that a single host can make.
-
max-src-conn-rate - ⟨number⟩ / - ⟨seconds⟩
-
Limit the rate of new connections over a time interval. The connection - rate is an approximation calculated as a moving average.
-
-

When one of these limits is reached, further packets that would - create state are dropped until existing states time out.

-

Because the 3-way handshake ensures that the source address is not - being spoofed, more aggressive action can be taken based on these limits. - With the overload - ⟨table⟩ state option, source IP - addresses which hit either of the limits on established connections will be - added to the named table. This table can be used in the ruleset to block - further activity from the offending host, redirect it to a tarpit process, - or restrict its bandwidth.

-

The optional flush keyword kills all states - created by the matching rule which originate from the host which exceeds - these limits. The global modifier to the flush command - kills all states originating from the offending host, regardless of which - rule created the state.

-

For example, the following rules will protect the webserver - against hosts making more than 100 connections in 10 seconds. Any host which - connects faster than this rate will have its address added to the - ⟨bad_hosts⟩ table and have all states originating from it - flushed. Any new packets arriving from this host will be dropped - unconditionally by the block rule.

-
-
block quick from <bad_hosts>
-pass in on $ext_if proto tcp to $webserver port www keep state \
-	(max-src-conn-rate 100/10, overload <bad_hosts> flush global)
-
-
-
-

-

Passive OS Fingerprinting is a mechanism to inspect nuances of a - TCP connection's initial SYN packet and guess at the host's operating - system. Unfortunately these nuances are easily spoofed by an attacker so the - fingerprint is not useful in making security decisions. But the fingerprint - is typically accurate enough to make policy decisions upon.

-

The fingerprints may be specified by operating system class, by - version, or by subtype/patchlevel. The class of an operating system is - typically the vendor or genre and would be OpenBSD - for the pf(4) firewall itself. The version of the oldest - available OpenBSD release on the main FTP site would - be 2.6 and the fingerprint would be written

-

-
"OpenBSD 2.6"
-

The subtype of an operating system is typically used to describe - the patchlevel if that patch led to changes in the TCP stack behavior. In - the case of OpenBSD, the only subtype is for a - fingerprint that was normalized by the no-df scrub - option and would be specified as

-

-
"OpenBSD 3.3 - no-df"
-

Fingerprints for most popular operating systems are provided by - pf.os(5). Once pf(4) is running, a - complete list of known operating system fingerprints may be listed by - running:

-

-
# pfctl -so
-

Filter rules can enforce policy at any level of operating system - specification assuming a fingerprint is present. Policy could limit traffic - to approved operating systems or even ban traffic from hosts that aren't at - the latest service pack.

-

The unknown class can also be used as the - fingerprint which will match packets for which no operating system - fingerprint is known.

-

Examples:

-
-
pass  out proto tcp from any os OpenBSD
-block out proto tcp from any os Doors
-block out proto tcp from any os "Doors PT"
-block out proto tcp from any os "Doors PT SP3"
-block out from any os "unknown"
-pass on lo0 proto tcp from any os "OpenBSD 3.3 lo0"
-
-

Operating system fingerprinting is limited only to the TCP SYN - packet. This means that it will not work on other protocols and will not - match a currently established connection.

-

Caveat: operating system fingerprints are occasionally wrong. - There are three problems: an attacker can trivially craft packets to appear - as any operating system; an operating system patch could change the stack - behavior and no fingerprints will match it until the database is updated; - and multiple operating systems may have the same fingerprint.

-
-
-

-

"Spoofing" is the faking of IP addresses, typically for - malicious purposes. The antispoof directive expands to - a set of filter rules which will block all traffic with a source IP from the - network(s) directly connected to the specified interface(s) from entering - the system through any other interface.

-

For example, the line

-
-
antispoof for lo0
-
-

expands to

-
-
block drop in on ! lo0 inet from 127.0.0.1/8 to any
-block drop in on ! lo0 inet6 from ::1 to any
-
-

For non-loopback interfaces, there are additional rules to block - incoming packets with a source IP address identical to the interface's - IP(s). For example, assuming the interface wi0 had an IP address of 10.0.0.1 - and a netmask of 255.255.255.0, the line

-
-
antispoof for wi0 inet
-
-

expands to

-
-
block drop in on ! wi0 inet from 10.0.0.0/24 to any
-block drop in inet from 10.0.0.1 to any
-
-

Caveat: Rules created by the antispoof - directive interfere with packets sent over loopback interfaces to local - addresses. One should pass these explicitly.

-
-
-

-

The size of IP datagrams (packets) can be significantly larger - than the maximum transmission unit (MTU) of the network. In cases when it is - necessary or more efficient to send such large packets, the large packet - will be fragmented into many smaller packets that will each fit onto the - wire. Unfortunately for a firewalling device, only the first logical - fragment will contain the necessary header information for the subprotocol - that allows pf(4) to filter on things such as TCP ports or - to perform NAT.

-

Besides the use of set reassemble option or - scrub rules as described in - TRAFFIC NORMALIZATION above, - there are three options for handling fragments in the packet filter.

-

One alternative is to filter individual fragments with filter - rules. If no scrub rule applies to a fragment or - set reassemble is set to no , - it is passed to the filter. Filter rules with matching IP header parameters - decide whether the fragment is passed or blocked, in the same way as - complete packets are filtered. Without reassembly, fragments can only be - filtered based on IP header fields (source/destination address, protocol), - since subprotocol header fields are not available (TCP/UDP port numbers, - ICMP code/type). The fragment option can be used to - restrict filter rules to apply only to fragments, but not complete packets. - Filter rules without the fragment option still apply - to fragments, if they only specify IP header fields. For instance, the - rule

-
-
pass in proto tcp from any to any port 80
-
-

never applies to a fragment, even if the fragment is part of a TCP - packet with destination port 80, because without reassembly this information - is not available for each fragment. This also means that fragments cannot - create new or match existing state table entries, which makes stateful - filtering and address translation (NAT, redirection) for fragments - impossible.

-

It's also possible to reassemble only certain fragments by - specifying source or destination addresses or protocols as parameters in - scrub rules.

-

In most cases, the benefits of reassembly outweigh the additional - memory cost, and it's recommended to use set - reassemble option or scrub rules with the - fragment reassemble modifier to reassemble all - fragments.

-

The memory allocated for fragment caching can be limited using - pfctl(8). Once this limit is reached, fragments that would - have to be cached are dropped until other entries time out. The timeout - value can also be adjusted.

-

When forwarding reassembled IPv6 packets, pf refragments them with - the original maximum fragment size. This allows the sender to determine the - optimal fragment size by path MTU discovery.

-
-
-

-

Besides the main ruleset, pfctl(8) can load - rulesets into anchor attachment points. An - anchor is a container that can hold rules, address - tables, and other anchors.

-

An anchor has a name which specifies the - path where pfctl(8) can be used to access the anchor to - perform operations on it, such as attaching child anchors to it or loading - rules into it. Anchors may be nested, with components separated by - ‘/’ characters, similar to how file system hierarchies are - laid out. The main ruleset is actually the default anchor, so filter and - translation rules, for example, may also be contained in any anchor.

-

An anchor can reference another anchor - attachment point using the following kinds of rules:

-
-
nat-anchor - ⟨name⟩
-
Evaluates the nat rules in the specified - anchor.
-
rdr-anchor - ⟨name⟩
-
Evaluates the rdr rules in the specified - anchor.
-
binat-anchor - ⟨name⟩
-
Evaluates the binat rules in the specified - anchor.
-
anchor - ⟨name⟩
-
Evaluates the filter rules in the specified - anchor.
-
load anchor - ⟨name⟩ from - ⟨file⟩
-
Loads the rules from the specified file into the anchor - name.
-
-

When evaluation of the main ruleset reaches an - anchor rule, pf(4) will proceed to - evaluate all rules specified in that anchor.

-

Matching filter and translation rules marked with the - quick option are final and abort the evaluation of the - rules in other anchors and the main ruleset. If the - anchor itself is marked with the - quick option, ruleset evaluation will terminate when - the anchor is exited if the packet is matched by any rule within the - anchor.

-

anchor rules are evaluated relative to the - anchor in which they are contained. For example, all - anchor rules specified in the main ruleset will - reference anchor attachment points underneath the main ruleset, and - anchor rules specified in a file loaded from a - load anchor rule will be attached under that anchor - point.

-

Rules may be contained in anchor attachment - points which do not contain any rules when the main ruleset is loaded, and - later such anchors can be manipulated through pfctl(8) - without reloading the main ruleset or other anchors. For example,

-
-
ext_if = "kue0"
-block on $ext_if all
-anchor spam
-pass out on $ext_if all
-pass in on $ext_if proto tcp from any \
-      to $ext_if port smtp
-
-

blocks all packets on the external interface by default, then - evaluates all rules in the anchor named - "spam", and finally passes all outgoing connections and incoming - connections to port 25.

-
-
# echo "block in quick from 1.2.3.4 to any" | \
-      pfctl -a spam -f -
-
-

This loads a single rule into the anchor, - which blocks all packets from a specific address.

-

The anchor can also be populated by adding a load - anchor rule after the anchor rule:

-
-
anchor spam
-load anchor spam from "/etc/pf-spam.conf"
-
-

When pfctl(8) loads - pf.conf, it will also load all the rules from the - file /etc/pf-spam.conf into the anchor.

-

Optionally, anchor rules can specify packet - filtering parameters using the same syntax as filter rules. When parameters - are used, the anchor rule is only evaluated for - matching packets. This allows conditional evaluation of anchors, like:

-
-
block on $ext_if all
-anchor spam proto tcp from any to any port smtp
-pass out on $ext_if all
-pass in on $ext_if proto tcp from any to $ext_if port smtp
-
-

The rules inside anchor spam are only - evaluated for tcp packets with destination port 25. - Hence,

-
-
# echo "block in quick from 1.2.3.4 to any" | \
-      pfctl -a spam -f -
-
-

will only block connections from 1.2.3.4 to port 25.

-

Anchors may end with the asterisk (‘*’) character, - which signifies that all anchors attached at that point should be evaluated - in the alphabetical ordering of their anchor name. For example,

-
-
anchor "spam/*"
-
-

will evaluate each rule in each anchor attached to the - spam anchor. Note that it will only evaluate anchors - that are directly attached to the spam anchor, and - will not descend to evaluate anchors recursively.

-

Since anchors are evaluated relative to the anchor in which they - are contained, there is a mechanism for accessing the parent and ancestor - anchors of a given anchor. Similar to file system path name resolution, if - the sequence “..” appears as an anchor path component, the - parent anchor of the current anchor in the path evaluation at that point - will become the new current anchor. As an example, consider the - following:

-
-
# echo ' anchor "spam/allowed" ' | pfctl -f -
-# echo -e ' anchor "../banned" \n pass' | \
-      pfctl -a spam/allowed -f -
-
-

Evaluation of the main ruleset will lead into the - spam/allowed anchor, which will evaluate the rules - in the spam/banned anchor, if any, before finally - evaluating the pass rule.

-

An anchor rule can also contain a filter - ruleset in a brace-delimited block. In that case, no separate loading of - rules into the anchor is required. Brace delimited blocks may contain rules - or other brace-delimited blocks. When an anchor is populated this way, the - anchor name becomes optional.

-
-
anchor "external" on $ext_if {
-	block
-	anchor out {
-		pass proto tcp from any to port { 25, 80, 443 }
-	}
-	pass in proto tcp to any port 22
-}
-
-

Since the parser specification for anchor names is a string, any - reference to an anchor name containing ‘/’ characters will - require double quote (‘"’) characters around the anchor - name.

-
-
-

-

pf(4) supports sctp(4) - connections. It can match ports, track state and NAT SCTP traffic. However, - it will not alter port numbers during nat or rdr translations. Doing so - would break SCTP multihoming.

-
-
-

-

This example maps incoming requests on port 80 to port 8080, on - which a daemon is running (because, for example, it is not run as root, and - therefore lacks permission to bind to port 80).

-
-
# use a macro for the interface name, so it can be changed easily
-ext_if = "ne3"
-
-# map daemon on 8080 to appear to be on 80
-match in on $ext_if proto tcp from any to any port 80 \
-      rdr-to 127.0.0.1 port 8080
-
-

If a pass rule is used with the - quick modifier, packets matching the translation rule - are passed without inspecting subsequent filter rules:

-
-
pass in quick on $ext_if proto tcp from any to any port 80 \
-      rdr-to 127.0.0.1 port 8080
-
-

In the example below, vlan12 is configured as 192.168.168.1; the - machine translates all packets coming from 192.168.168.0/24 to 204.92.77.111 - when they are going out any interface except vlan12. This has the net effect - of making traffic from the 192.168.168.0/24 network appear as though it is - the Internet routable address 204.92.77.111 to nodes behind any interface on - the router except for the nodes on vlan12. (Thus, 192.168.168.1 can talk to - the 192.168.168.0/24 nodes.)

-
-
match out on ! vlan12 from 192.168.168.0/24 to any nat-to 204.92.77.111
-
-

This longer example uses both a NAT and a redirection. The - external interface has the address 157.161.48.183. On localhost, we are - running ftp-proxy(8), waiting for FTP sessions to be - redirected to it. The three mandatory anchors for - ftp-proxy(8) are omitted from this example; see the - ftp-proxy(8) manpage.

-
-
# NAT
-# Translate outgoing packets' source addresses (any protocol).
-# In this case, any address but the gateway's external address is mapped.
-pass out on $ext_if inet from ! ($ext_if) to any nat-to ($ext_if)
-
-# NAT PROXYING
-# Map outgoing packets' source port to an assigned proxy port instead of
-# an arbitrary port.
-# In this case, proxy outgoing isakmp with port 500 on the gateway.
-pass out on $ext_if inet proto udp from any port = isakmp to any \
-      nat-to ($ext_if) port 500
-
-# BINAT
-# Translate outgoing packets' source address (any protocol).
-# Translate incoming packets' destination address to an internal machine
-# (bidirectional).
-pass on $ext_if from 10.1.2.150 to any binat-to $ext_if
-
-# Translate packets arriving on $peer_if addressed to 172.22.16.0/20
-# to the corresponding address in 172.21.16.0/20 (bidirectional).
-pass on $peer_if from 172.21.16.0/20 to any binat-to 172.22.16.0/20
-
-# RDR
-# Translate incoming packets' destination addresses.
-# As an example, redirect a TCP and UDP port to an internal machine.
-pass in on $ext_if inet proto tcp from any to ($ext_if) port 8080 \
-      rdr-to 10.1.2.151 port 22
-pass in on $ext_if inet proto udp from any to ($ext_if) port 8080 \
-      rdr-to 10.1.2.151 port 53
-
-# RDR
-# Translate outgoing ftp control connections to send them to localhost
-# for proxying with ftp-proxy(8) running on port 8021.
-pass in on $int_if proto tcp from any to any port 21 \
-      rdr-to 127.0.0.1 port 8021
-
-

In this example, a NAT gateway is set up to translate internal - addresses using a pool of public addresses (192.0.2.16/28) and to redirect - incoming web server connections to a group of web servers on the internal - network.

-
-
# NAT LOAD BALANCE
-# Translate outgoing packets' source addresses using an address pool.
-# A given source address is always translated to the same pool address by
-# using the source-hash keyword.
-pass out on $ext_if inet from any to any nat-to 192.0.2.16/28 source-hash
-
-# RDR ROUND ROBIN
-# Translate incoming web server connections to a group of web servers on
-# the internal network.
-pass in on $ext_if proto tcp from any to any port 80 \
-      rdr-to { 10.1.2.155, 10.1.2.160, 10.1.2.161 } round-robin
-
-
-
-

-

In the example below, the machine sits between a fake internal - 144.19.74.* network, and a routable external IP of 204.92.77.100. The - no nat rule excludes protocol AH from being - translated.

-
-
# NAT
-no nat on $ext_if proto ah from 144.19.74.0/24 to any
-nat on $ext_if from 144.19.74.0/24 to any -> 204.92.77.100
-
-

In the example below, packets bound for one specific server, as - well as those generated by the sysadmins are not proxied; all other - connections are.

-
-
# RDR
-no rdr on $int_if proto { tcp, udp } from any to $server port 80
-no rdr on $int_if proto { tcp, udp } from $sysadmins to any port 80
-rdr on $int_if proto { tcp, udp } from any to any port 80 \
-      -> 127.0.0.1 port 80
-
-
-
-

-
-
# The external interface is kue0
-# (157.161.48.183, the only routable address)
-# and the private network is 10.0.0.0/8, for which we are doing NAT.
-
-# Reassemble incoming traffic
-set reassemble yes
-
-# use a macro for the interface name, so it can be changed easily
-ext_if = "kue0"
-
-# block and log everything by default
-block return log on $ext_if all
-
-# block anything coming from source we have no back routes for
-block in from no-route to any
-
-# block packets whose ingress interface does not match the one in
-# the route back to their source address
-block in from urpf-failed to any
-
-# block and log outgoing packets that do not have our address as source,
-# they are either spoofed or something is misconfigured (NAT disabled,
-# for instance), we want to be nice and do not send out garbage.
-block out log quick on $ext_if from ! 157.161.48.183 to any
-
-# silently drop broadcasts (cable modem noise)
-block in quick on $ext_if from any to 255.255.255.255
-
-# block and log incoming packets from reserved address space and invalid
-# addresses, they are either spoofed or misconfigured, we cannot reply to
-# them anyway (hence, no return-rst).
-block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, \
-      192.168.0.0/16, 255.255.255.255/32 } to any
-
-# ICMP
-
-# pass out/in certain ICMP queries and keep state (ping)
-# state matching is done on host addresses and ICMP id (not type/code),
-# so replies (like 0/0 for 8/0) will match queries
-# ICMP error messages (which always refer to a TCP/UDP packet) are
-# handled by the TCP/UDP states
-pass on $ext_if inet proto icmp all icmp-type 8 code 0
-
-# UDP
-
-# pass out all UDP connections and keep state
-pass out on $ext_if proto udp all
-
-# pass in certain UDP connections and keep state (DNS)
-pass in on $ext_if proto udp from any to any port domain
-
-# TCP
-
-# pass out all TCP connections and modulate state
-pass out on $ext_if proto tcp all modulate state
-
-# pass in certain TCP connections and keep state (SSH, SMTP, DNS, IDENT)
-pass in on $ext_if proto tcp from any to any port { ssh, smtp, domain, \
-      auth }
-
-# Do not allow Windows 9x SMTP connections since they are typically
-# a viral worm. Alternately we could limit these OSes to 1 connection each.
-block in on $ext_if proto tcp from any os {"Windows 95", "Windows 98"} \
-      to any port smtp
-
-# IPv6
-# pass in/out all IPv6 traffic: note that we have to enable this in two
-# different ways, on both our physical interface and our tunnel
-pass quick on gif0 inet6
-pass quick on $ext_if proto ipv6
-
-# Packet Tagging
-
-# three interfaces: $int_if, $ext_if, and $wifi_if (wireless). NAT is
-# being done on $ext_if for all outgoing packets. tag packets in on
-# $int_if and pass those tagged packets out on $ext_if.  all other
-# outgoing packets (i.e., packets from the wireless network) are only
-# permitted to access port 80.
-
-pass in on $int_if from any to any tag INTNET
-pass in on $wifi_if from any to any
-
-block out on $ext_if from any to any
-pass out quick on $ext_if tagged INTNET
-pass out on $ext_if proto tcp from any to any port 80
-
-# tag incoming packets as they are redirected to spamd(8). use the tag
-# to pass those packets through the packet filter.
-
-rdr on $ext_if inet proto tcp from <spammers> to port smtp \
-	tag SPAMD -> 127.0.0.1 port spamd
-
-block in on $ext_if
-pass in on $ext_if inet proto tcp tagged SPAMD
-
-

In the example below, a router handling both address families - translates an internal IPv4 subnet to IPv6 using the well-known 64:ff9b::/96 - prefix:

-
-
pass in on $v4_if inet af-to inet6 from ($v6_if) to 64:ff9b::/96
-
-

Paired with the example above, the example below can be used on - another router handling both address families to translate back to IPv4:

-
-
pass in on $v6_if inet6 to 64:ff9b::/96 af-to inet from ($v4_if)
-
-
-
-

-

Syntax for pf.conf in BNF:

-
-
line           = ( option | ether-rule | pf-rule | nat-rule | binat-rule |
-                 rdr-rule | antispoof-rule | altq-rule | queue-rule |
-                 trans-anchors | anchor-rule | anchor-close | load-anchor |
-                 table-rule | include )
-
-option         = "set" ( [ "timeout" ( timeout | "{" timeout-list "}" ) ] |
-                 [ "ruleset-optimization" [ "none" | "basic" | "profile" ]] |
-                 [ "optimization" [ "default" | "normal" |
-                 "high-latency" | "satellite" |
-                 "aggressive" | "conservative" ] ]
-                 [ "limit" ( limit-item | "{" limit-list "}" ) ] |
-                 [ "loginterface" ( interface-name | "none" ) ] |
-                 [ "block-policy" ( "drop" | "return" ) ] |
-                 [ "state-policy" ( "if-bound" | "floating" ) ]
-                 [ "state-defaults" state-opts ]
-                 [ "require-order" ( "yes" | "no" ) ]
-                 [ "fingerprints" filename ] |
-                 [ "skip on" ifspec ] |
-                 [ "debug" ( "none" | "urgent" | "misc" | "loud" ) ]
-                 [ "keepcounters" ] )
-
-ether-rule     = "ether" etheraction [ ( "in" | "out" ) ]
-                 [ "quick" ] [ "on" ifspec ] [ "bridge-to" interface-name ]
-                 [ etherprotospec ] [ etherhosts ] [ "l3" hosts ]
-                 [ etherfilteropt-list ]
-
-pf-rule        = action [ ( "in" | "out" ) ]
-                 [ "log" [ "(" logopts ")"] ] [ "quick" ]
-                 [ "on" ifspec ] [ route ] [ af ] [ protospec ]
-                 [ hosts ] [ filteropt-list ]
-
-logopts        = logopt [ "," logopts ]
-logopt         = "all" | "matches" | "user" | "to" interface-name
-
-etherfilteropt-list = etherfilteropt-list etherfilteropt | etherfilteropt
-etherfilteropt = "tag" string | "tagged" string | "queue" ( string ) |
-                 "ridentifier" number | "label" string
-
-filteropt-list = filteropt-list filteropt | filteropt
-filteropt      = user | group | flags | icmp-type | icmp6-type | "tos" tos |
-                 "af-to" af "from" ( redirhost | "{" redirhost-list "}" )
-                 [ "to" ( redirhost | "{" redirhost-list "}" ) ] |
-                 ( "no" | "keep" | "modulate" | "synproxy" ) "state"
-                 [ "(" state-opts ")" ] |
-                 "fragment" | "no-df" | "min-ttl" number | "set-tos" tos |
-                 "max-mss" number | "random-id" | "reassemble tcp" |
-                 fragmentation | "allow-opts" | "once" |
-                 "label" string | "tag" string | [ "!" ] "tagged" string |
-                 "max-pkt-rate" number "/" seconds |
-                 "set prio" ( number | "(" number [ [ "," ] number ] ")" ) |
-                 "max-pkt-size" number |
-                 "queue" ( string | "(" string [ [ "," ] string ] ")" ) |
-                 "rtable" number | "probability" number"%" | "prio" number |
-                 "state limiter" name |
-                 "state limiter" name "(" limiter-opts ")" |
-                 "source limiter" name |
-                 "source limiter" name "(" limiter-opts ")" | "prio" number |
-                 "dnpipe" ( number | "(" number "," number ")" ) |
-                 "dnqueue" ( number | "(" number "," number ")" ) |
-                 "ridentifier" number |
-                 "binat-to" ( redirhost | "{" redirhost-list "}" )
-                 [ portspec ] [ pooltype ] |
-                 "rdr-to" ( redirhost | "{" redirhost-list "}" )
-                 [ portspec ] [ pooltype ] |
-                 "nat-to" ( redirhost | "{" redirhost-list "}" )
-                 [ portspec ] [ pooltype ] [ "static-port" ] |
-                 [ ! ] "received-on" ( interface-name | interface-group )
-
-nat-rule       = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
-                 [ "on" ifspec ] [ af ]
-                 [ protospec ] hosts [ "tag" string ] [ "tagged" string ]
-                 [ "->" ( redirhost | "{" redirhost-list "}" )
-                 [ portspec ] [ pooltype ] [ "static-port" ]
-                 [ "map-e-portset" number "/" number "/" number ] ]
-
-binat-rule     = [ "no" ] "binat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
-                 [ "on" interface-name ] [ af ]
-                 [ "proto" ( proto-name | proto-number ) ]
-                 "from" address [ "/" mask-bits ] "to" ipspec
-                 [ "tag" string ] [ "tagged" string ]
-                 [ "->" address [ "/" mask-bits ] ]
-
-rdr-rule       = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
-                 [ "on" ifspec ] [ af ]
-                 [ protospec ] hosts [ "tag" string ] [ "tagged" string ]
-                 [ "->" ( redirhost | "{" redirhost-list "}" )
-                 [ portspec ] [ pooltype ] ]
-
-antispoof-rule = "antispoof" [ "log" ] [ "quick" ]
-                 "for" ifspec [ af ] [ "label" string ]
-                 [ "ridentifier" number ]
-
-table-rule     = "table" "<" string ">" [ tableopts-list ]
-tableopts-list = tableopts-list tableopts | tableopts
-tableopts      = "persist" | "const" | "counters" | "file" string |
-                 "{" [ tableaddr-list ] "}"
-tableaddr-list = tableaddr-list [ "," ] tableaddr-spec | tableaddr-spec
-tableaddr-spec = [ "!" ] tableaddr [ "/" mask-bits ]
-tableaddr      = hostname | ifspec | "self" |
-                 ipv4-dotted-quad | ipv6-coloned-hex
-
-altq-rule      = "altq on" interface-name queueopts-list
-                 "queue" subqueue
-queue-rule     = "queue" string [ "on" interface-name ] queueopts-list
-                 subqueue
-
-anchor-rule    = "anchor" [ string ] [ ( "in" | "out" ) ] [ "on" ifspec ]
-                 [ af ] [ protospec ] [ hosts ] [ filteropt-list ] [ "{" ]
-
-anchor-close   = "}"
-
-trans-anchors  = ( "nat-anchor" | "rdr-anchor" | "binat-anchor" ) string
-                 [ "on" ifspec ] [ af ] [ "proto" ] [ protospec ] [ hosts ]
-
-load-anchor    = "load anchor" string "from" filename
-
-queueopts-list = queueopts-list queueopts | queueopts
-queueopts      = [ "bandwidth" bandwidth-spec ] |
-                 [ "qlimit" number ] | [ "tbrsize" number ] |
-                 [ "priority" number ] | [ schedulers ]
-schedulers     = ( cbq-def | priq-def | hfsc-def )
-bandwidth-spec = "number" ( "b" | "Kb" | "Mb" | "Gb" | "%" )
-
-etheraction    = "pass" | "block"
-action         = "pass" | "match" | "block" [ return ] | [ "no" ] "scrub"
-return         = "drop" | "return" | "return-rst" [ "( ttl" number ")" ] |
-                 "return-icmp" [ "(" icmpcode [ [ "," ] icmp6code ] ")" ] |
-                 "return-icmp6" [ "(" icmp6code ")" ]
-icmpcode       = ( icmp-code-name | icmp-code-number )
-icmp6code      = ( icmp6-code-name | icmp6-code-number )
-
-ifspec         = ( [ "!" ] ( interface-name | interface-group ) ) |
-                 "{" interface-list "}"
-interface-list = [ "!" ] ( interface-name | interface-group )
-                 [ [ "," ] interface-list ]
-route          = ( "route-to" | "reply-to" | "dup-to" )
-                 ( routehost | "{" routehost-list "}" )
-                 [ pooltype ]
-af             = "inet" | "inet6"
-
-etherprotospec = "proto" ( proto-number | "{" etherproto-list "}" )
-etherproto-list	= proto-number [ [ "," ] etherproto-list ]
-protospec      = "proto" ( proto-name | proto-number |
-                 "{" proto-list "}" )
-proto-list     = ( proto-name | proto-number ) [ [ "," ] proto-list ]
-
-etherhosts     = "from" macaddress "to" macaddress
-macaddress     = mac | mac "/" masklen | mac "&" mask
-
-hosts          = "all" |
-                 "from" ( "any" | "no-route" | "urpf-failed" | "self" | host |
-                 "{" host-list "}" ) [ port ] [ os ]
-                 "to"   ( "any" | "no-route" | "self" | host |
-                 "{" host-list "}" ) [ port ]
-
-ipspec         = "any" | host | "{" host-list "}"
-host           = [ "!" ] ( address [ "/" mask-bits ] | "<" string ">" )
-redirhost      = address [ "/" mask-bits ]
-routehost      = "(" interface-name address [ "/" mask-bits ] ")"
-address        = ( interface-name | interface-group |
-                 "(" ( interface-name | interface-group ) ")" |
-                 hostname | ipv4-dotted-quad | ipv6-coloned-hex )
-host-list      = host [ [ "," ] host-list ]
-redirhost-list = redirhost [ [ "," ] redirhost-list ]
-routehost-list = routehost [ [ "," ] routehost-list ]
-
-port           = "port" ( unary-op | binary-op | "{" op-list "}" )
-portspec       = "port" ( number | name ) [ ":" ( "*" | number | name ) ]
-os             = "os"  ( os-name | "{" os-list "}" )
-user           = "user" ( unary-op | binary-op | "{" op-list "}" )
-group          = "group" ( unary-op | binary-op | "{" op-list "}" )
-
-unary-op       = [ "=" | "!=" | "<" | "<=" | ">" | ">=" ]
-                 ( name | number )
-binary-op      = number ( "<>" | "><" | ":" ) number
-op-list        = ( unary-op | binary-op ) [ [ "," ] op-list ]
-
-os-name        = operating-system-name
-os-list        = os-name [ [ "," ] os-list ]
-
-flags          = "flags" ( [ flag-set ] "/"  flag-set | "any" )
-flag-set       = [ "F" ] [ "S" ] [ "R" ] [ "P" ] [ "A" ] [ "U" ] [ "E" ]
-                 [ "W" ]
-
-icmp-type      = "icmp-type" ( icmp-type-code | "{" icmp-list "}" )
-icmp6-type     = "icmp6-type" ( icmp-type-code | "{" icmp-list "}" )
-icmp-type-code = ( icmp-type-name | icmp-type-number )
-                 [ "code" ( icmp-code-name | icmp-code-number ) ]
-icmp-list      = icmp-type-code [ [ "," ] icmp-list ]
-
-tos            = ( "lowdelay" | "throughput" | "reliability" |
-                 [ "0x" ] number )
-
-state-opts     = state-opt [ [ "," ] state-opts ]
-state-opt      = ( "max" number | "no-sync" | timeout | "sloppy" |
-                 "source-track" [ ( "rule" | "global" ) ] |
-                 "max-src-nodes" number | "max-src-states" number |
-                 "max-src-conn" number |
-                 "max-src-conn-rate" number "/" number |
-                 "overload" "<" string ">" [ "flush" ] |
-                 "if-bound" | "floating" | "pflow" )
-
-fragmentation  = [ "fragment reassemble" ]
-
-timeout-list   = timeout [ [ "," ] timeout-list ]
-timeout        = ( "tcp.first" | "tcp.opening" | "tcp.established" |
-                 "tcp.closing" | "tcp.finwait" | "tcp.closed" | "tcp.tsdiff" |
-                 "sctp.first" | "sctp.opening" | "sctp.established" |
-                 "sctp.closing" | "sctp.closed" |
-                 "udp.first" | "udp.single" | "udp.multiple" |
-                 "icmp.first" | "icmp.error" |
-                 "other.first" | "other.single" | "other.multiple" |
-                 "frag" | "interval" | "src.track" |
-                 "adaptive.start" | "adaptive.end" ) number
-
-limit-list     = limit-item [ [ "," ] limit-list ]
-limit-item     = ( "states" | "frags" | "src-nodes" ) number
-
-pooltype       = ( "bitmask" | "random" |
-                 "source-hash" [ ( hex-key | string-key ) ] |
-                 "round-robin" ) [ sticky-address | prefer-ipv6-nexthop ]
-
-subqueue       = string | "{" queue-list "}"
-queue-list     = string [ [ "," ] string ]
-cbq-def        = "cbq" [ "(" cbq-opt [ [ "," ] cbq-opt ] ")" ]
-priq-def       = "priq" [ "(" priq-opt [ [ "," ] priq-opt ] ")" ]
-hfsc-def       = "hfsc" [ "(" hfsc-opt [ [ "," ] hfsc-opt ] ")" ]
-cbq-opt        = ( "default" | "borrow" | "red" | "ecn" | "rio" )
-priq-opt       = ( "default" | "red" | "ecn" | "rio" )
-hfsc-opt       = ( "default" | "red" | "ecn" | "rio" |
-                 linkshare-sc | realtime-sc | upperlimit-sc )
-linkshare-sc   = "linkshare" sc-spec
-realtime-sc    = "realtime" sc-spec
-upperlimit-sc  = "upperlimit" sc-spec
-sc-spec        = ( bandwidth-spec |
-                 "(" bandwidth-spec number bandwidth-spec ")" )
-limiter-opts   = "block" | "no-match"
-include        = "include" filename
-
-
-
-

-
-
/etc/hosts
-
Host name database.
-
/etc/pf.conf
-
Default location of the ruleset file. The file has to be created manually - as it is not installed with a standard installation.
-
/etc/pf.os
-
Default location of OS fingerprints.
-
/etc/protocols
-
Protocol name database.
-
/etc/services
-
Service name database.
-
-
-
-

-

altq(4), carp(4), - icmp(4), icmp6(4), - ip(4), ip6(4), pf(4), - pflow(4), pfsync(4), - sctp(4), tcp(4), - udp(4), hosts(5), - pf.os(5), protocols(5), - services(5), ftp-proxy(8), - pfctl(8), pflogd(8)

-
-
-

-

The pf.conf file format first appeared in - OpenBSD 3.0.

-
-
- - - - - -
April 22, 2026FreeBSD 15.0
diff --git a/static/freebsd/man5/pf.os.5 3.html b/static/freebsd/man5/pf.os.5 3.html deleted file mode 100644 index d3edd8b3..00000000 --- a/static/freebsd/man5/pf.os.5 3.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
PF.OS(5)File Formats ManualPF.OS(5)
-
-
-

-

pf.os — format of - the operating system fingerprints file

-
-
-

-

The pf(4) firewall and the - tcpdump(1) program can both fingerprint the operating - system of hosts that originate an IPv4 TCP connection. The file consists of - newline-separated records, one per fingerprint, containing nine colon - (‘:’) separated fields. These fields - are as follows:

-

-
-
-
window
-
The TCP window size.
-
TTL
-
The IP time to live.
-
df
-
The presence of the IPv4 don't fragment bit.
-
packet size
-
The size of the initial TCP packet.
-
TCP options
-
An ordered list of the TCP options.
-
class
-
The class of operating system.
-
version
-
The version of the operating system.
-
subtype
-
The subtype of patchlevel of the operating system.
-
description
-
The overall textual description of the operating system, version and - subtype.
-
-
-

The window field corresponds to the - th->th_win field in the TCP header and is the source host's advertised - TCP window size. It may be between zero and 65,535 inclusive. The window - size may be given as a multiple of a constant by prepending the size with a - percent sign ‘%’ and the value will be used as a modulus. - Three special values may be used for the window size:

-

-
-
-
*
-
An asterisk will wildcard the value so any window size will match.
-
S
-
Allow any window size which is a multiple of the maximum segment size - (MSS).
-
T
-
Allow any window size which is a multiple of the maximum transmission unit - (MTU).
-
-
-

The ttl value is the initial time to live in - the IP header. The fingerprint code will account for the volatility of the - packet's TTL as it traverses a network.

-

The df bit corresponds to the Don't Fragment - bit in an IPv4 header. It tells intermediate routers not to fragment the - packet and is used for path MTU discovery. It may be either a zero or a - one.

-

The packet size is the literal size of the - full IP packet and is a function of all of the IP and TCP options.

-

The TCP options field is an ordered list of - the individual TCP options that appear in the SYN packet. Each option is - described by a single character separated by a comma and certain ones may - include a value. The options are:

-

-
-
-
Mnnn
-
maximum segment size (MSS) option. The value is the maximum packet size of - the network link which may include the ‘%’ modulus or match - all MSSes with the ‘*’ value.
-
N
-
the NOP option (NO Operation).
-
T[0]
-
the timestamp option. Certain operating systems always start with a zero - timestamp in which case a zero value is added to the option; otherwise no - value is appended.
-
S
-
the Selective ACKnowledgement OK (SACKOK) option.
-
Wnnn
-
window scaling option. The value is the size of the window scaling which - may include the ‘%’ modulus or match all window scalings - with the ‘*’ value.
-
-
-

No TCP options in the fingerprint may be given with a single dot - ‘.’.

-

An example of OpenBSD's TCP options are:

-

-
M*,N,N,S,N,W0,N,N,T
-

The first option M* is the MSS option and - will match all values. The second and third options N - will match two NOPs. The fourth option S will match - the SACKOK option. The fifth N will match another NOP. - The sixth W0 will match a window scaling option with a - zero scaling size. The seventh and eighth N options - will match two NOPs. And the ninth and final option T - will match the timestamp option with any time value.

-

The TCP options in a fingerprint will only match packets with the - exact same TCP options in the same order.

-

The class field is the class, genre or - vendor of the operating system.

-

The version is the version of the operating - system. It is used to distinguish between different fingerprints of - operating systems of the same class but different versions.

-

The subtype is the subtype or patch level of - the operating system version. It is used to distinguish between different - fingerprints of operating systems of the same class and same version but - slightly different patches or tweaking.

-

The description is a general description of - the operating system, its version, patchlevel and any further useful - details.

-
-
-

-

The fingerprint of a plain OpenBSD 3.3 - host is:

-
-
  16384:64:1:64:M*,N,N,S,N,W0,N,N,T:OpenBSD:3.3::OpenBSD 3.3
-
-

The fingerprint of an OpenBSD 3.3 host - behind a PF scrubbing firewall with a no-df rule would be:

-
-
  16384:64:0:64:M*,N,N,S,N,W0,N,N,T:OpenBSD:3.3:!df:OpenBSD 3.3 scrub no-df
-
-

An absolutely braindead embedded operating system fingerprint - could be:

-
-
  65535:255:0:40:.:DUMMY:1.1:p3:Dummy embedded OS v1.1p3
-
-

The tcpdump(1) output of

-
-
  # tcpdump -s128 -c1 -nv 'tcp[13] == 2'
-  03:13:48.118526 10.0.0.1.3377 > 10.0.0.2.80: S [tcp sum ok] \
-      534596083:534596083(0) win 57344 <mss 1460> (DF) [tos 0x10] \
-      (ttl 64, id 11315, len 44)
-
-

almost translates into the following fingerprint

-
-
  57344:64:1:44:M1460:	exampleOS:1.0::exampleOS 1.0
-
-
-
-

-

tcpdump(1), pf(4), - pf.conf(5), pfctl(8)

-
-
- - - - - -
May 31, 2007FreeBSD 15.0
diff --git a/static/freebsd/man5/phones.5 4.html b/static/freebsd/man5/phones.5 4.html deleted file mode 100644 index e0a46d28..00000000 --- a/static/freebsd/man5/phones.5 4.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
PHONES(5)File Formats ManualPHONES(5)
-
-
-

-

phones — remote - host phone number data base

-
-
-

-

The file /etc/phones contains the - system-wide private phone numbers for the tip(1) program. - This file is normally unreadable, and so may contain privileged information. - The format of the file is a series of lines of the form: - <system-name>[ \t]*<phone-number>. The system name is one - of those defined in the remote(5) file and the phone - number is constructed from any sequence of characters terminated only by - ``,'' or the end of the line. The ``='' and ``*'' characters are indicators - to the auto call units to pause and wait for a second dial tone (when going - through an exchange). The ``='' is required by the DF02-AC and the ``*'' is - required by the BIZCOMP 1030.

-

Only one phone number per line is permitted. However, if more than - one line in the file contains the same system name tip(1) - will attempt to dial each one in turn, until it establishes a - connection.

-
-
-

-
-
/etc/phones
-
 
-
-
-
-

-

tip(1), remote(5)

-
-
-

-

The phones file appeared in - 4.2BSD.

-
-
- - - - - -
June 5, 1993FreeBSD 15.0
diff --git a/static/freebsd/man5/portindex.5 3.html b/static/freebsd/man5/portindex.5 3.html deleted file mode 100644 index 15319e1a..00000000 --- a/static/freebsd/man5/portindex.5 3.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - -
PORTINDEX(5)File Formats ManualPORTINDEX(5)
-
-
-

-

INDEX — File - containing information about the state of the ports tree

-
-
-

-

The port index file in /usr/ports contains - various bits of information about the ports tree. Each major branch of - FreeBSD has a separate index file, named - “INDEX-N”, where N - is the major version number of the FreeBSD branch, - i.e.: INDEX-7, or - INDEX-8.

-
-
-
The name of the package.
-
-
The path to the port directory.
-
-
The default install prefix.
-
-
A short description.
-
-
The path to the full description.
-
-
The email address of the maintainer.
-
-
The categories this port is part of.
-
-
Ports required to be installed prior to building this port.
-
-
Ports required to be installed for this port to run.
-
-
The project website for the port.
-
-
Ports that may be required to extract this port.
-
-
Ports that may be required to patch this port.
-
-
Ports that may be required to fetch this port.
-
-
-
-

-
-
/usr/ports/INDEX-N
-
where N is the major version number of the - FreeBSD branch.
-
-
-
-

-
-
vim-6.3.15|/usr/ports/editors/vim|/usr/local|Vi "workalike", with many additional features|/usr/ports/editors/vim/pkg-descr|obrien@FreeBSD.org|editors|libiconv-1.9.2_1|libiconv-1.9.2_1|http://www.vim.org/|||
-
-
-
-

-

build(7), ports(7)

-
-
-

-

This manual page was written by Paul - Armstrong and Thomas Abthorpe - <tabthorpe@FreeBSD.org>.

-
-
- - - - - -
October 14, 2012FreeBSD 15.0
diff --git a/static/freebsd/man5/protocols.5 4.html b/static/freebsd/man5/protocols.5 4.html deleted file mode 100644 index 88e9deb4..00000000 --- a/static/freebsd/man5/protocols.5 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
PROTOCOLS(5)File Formats ManualPROTOCOLS(5)
-
-
-

-

protocols — - protocol name data base

-
-
-

-

The protocols file contains information - regarding the assigned protocol numbers used by IPv4 and IPv6 to identify - the next level protocol. For each protocol a single line should be present - with the following information:

-
-
official protocol name
-protocol number
-aliases
-
-

Items are separated by any number of blanks and/or tab characters. - A ``#'' indicates the beginning of a comment; characters up to the end of - the line are not interpreted by routines which search the file.

-

Protocol names may contain any printable character other than a - field delimiter, newline, or comment character.

-
-
-

-
-
/etc/protocols
-
The protocols file resides in - /etc.
-
-
-
-

-

getprotoent(3)

-

IANA Allocation Guidelines For - Values In the Internet Protocol and Related Headers, - RFC 2780, March - 2000.

-

IANA Allocation Guidelines for - the Protocol Field, RFC 5237, - February 2008.

-
-
-

-

The protocols file format appeared in - 4.2BSD, describing the "known protocols used in - the DARPA Internet".

-
-
-

-

A name server should be used instead of a static file.

-
-
- - - - - -
December 7, 2020FreeBSD 15.0
diff --git a/static/freebsd/man5/quota.user.5 3.html b/static/freebsd/man5/quota.user.5 3.html deleted file mode 100644 index da3d0d45..00000000 --- a/static/freebsd/man5/quota.user.5 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
QUOTA.USER(5)File Formats ManualQUOTA.USER(5)
-
-
-

-

quota.user, - quota.group — per file - system quota database

-
-
-

-

Each file system with active quotas should contain a - quota.user and quota.group - file in the file system root. These files are created by - quotacheck(8), and should be edited with - edquota(8). It is possible to specify a different location - and file name with the “userquota” and - “groupquota” options in the - fstab(5) file.

-

The data files contain the following information:

-

-
    -
  • Current block usage
    • -
  • Current number of files
    • -
  • Soft block limit
    • -
  • Soft file limit
    • -
  • Hard block limit
    • -
  • Hard file limit
    • -
  • Block grace time remaining if over the soft limit
    • -
  • File grace time remaining if over the soft limit
    • -
-

See edquota(8) for an explanation on the various - limits and grace periods.

-

During normal quota operations the quotactl(2) - interface is used to query or set quota information and the kernel will - maintain the data files as needed. If quotas are disabled on a file system, - but marked as having quotas enabled in fstab(5), then the - quota data files will be used directly.

-

The data files are stored as an array of - “struct dqblk” structures, as defined - in <ufs/ufs/quota.h>, and - indexed by UID or GID. The data files will be written as a sparse file if - possible. Data is only maintained for ids that have either non-zero usage or - non-zero quota limits. If an attempt is made to access data for an id that - would exist past the end of the current data file, a quota structure with - all values set to zero will be created, and the data file extended as - needed. The quotacheck(8) utility will truncate the data - files to the minimum size needed to store the highest id with either - non-zero file usage or non-zero quota limits.

-

The data record for id 0 has special meaning. If the - “dqb_btime” or - “dbq_itime” fields are non-zero, they - are used to indicate the grace period on that file system for users who have - exceeded their soft limit. These times can be set by - edquota(8) with the -t flag. If no - explicit grace period has been set with edquota(8), then - the default value of 7 days will be used. The default values are defined by - MAX_DQ_TIME and MAX_IQ_TIME - in <ufs/ufs/quota.h>.

-
-
-

-

quota(1), quotactl(2), - fstab(5), edquota(8), - quotacheck(8), quotaoff(8), - quotaon(8), repquota(8)

-
-
- - - - - -
October 30, 2007FreeBSD 15.0
diff --git a/static/freebsd/man5/rc.conf.5 3.html b/static/freebsd/man5/rc.conf.5 3.html deleted file mode 100644 index 90b6a018..00000000 --- a/static/freebsd/man5/rc.conf.5 3.html +++ /dev/null @@ -1,3187 +0,0 @@ - - - - - - -
RC.CONF(5)File Formats ManualRC.CONF(5)
-
-
-

-

rc.conf — system - configuration information

-
-
-

-

The file rc.conf contains descriptive - information about the local host name, configuration details for any - potential network interfaces and which services should be started up at - system initial boot time. In new installations, the - rc.conf file is generally initialized by the system - installation utility.

-

The purpose of rc.conf is not to run - commands or perform system startup actions directly. Instead, it is included - by the various generic startup scripts in /etc which - conditionalize their internal actions according to the settings found - there.

-

The /etc/rc.conf file is included from the - file /etc/defaults/rc.conf, which specifies the - default settings for all the available options. Options need only be - specified in /etc/rc.conf when the system - administrator wishes to override these defaults. The file - /etc/defaults/vendor.conf allows vendors to override - FreeBSD defaults. The file - /etc/rc.conf.local is used to override settings in - /etc/rc.conf for historical reasons.

-

The sysrc(8) command provides a scripting interface to modify - system config files.

-

In addition to /etc/rc.conf.local you can - also place smaller configuration files for each rc(8) - script in the /etc/rc.conf.d directory or - ⟨dir⟩/rc.conf.d - directories (where ⟨dir⟩ is each entry - specified in local_startup, but with any trailing - /rc.d stripped), which will be included by the - load_rc_config function. For jail configurations you - could use the file /etc/rc.conf.d/jail to store - jail-specific configuration options. If local_startup - contains /usr/local/etc/rc.d and - /opt/conf, - /usr/local/etc/rc.conf.d/jail and - /opt/conf/rc.conf.d/jail will be loaded. If - ⟨dir⟩/rc.conf.d/⟨name⟩ - is a directory then all of the files in the directory will be loaded. See - also the rc_conf_files variable below.

-

Options are set with - “name=value” - assignments that use sh(1) syntax. The following list - provides a name and short description for each variable that can be set in - the rc.conf file:

-
-
rc_debug
-
(bool) If set to - “YES”, enable output of debug - messages from rc scripts. This variable can be helpful in diagnosing - mistakes when editing or integrating new scripts. Beware that this - produces copious output to the terminal and - syslog(3).
-
rc_info
-
(bool) If set to - “NO”, disable informational messages - from the rc scripts. Informational messages are displayed when a condition - that is not serious enough to warrant a warning or an error occurs.
-
rc_startmsgs
-
(bool) If set to - “YES”, show “Starting - foo:” when faststart is used (e.g., at boot time).
-
early_late_divider
-
(str) The name of the script that should be used as - the delimiter between the “early” and “late” - stages of the boot process. The early stage should contain all the - services needed to get the disks (local or remote) mounted so that the - late stage can include scripts contained in the directories listed in the - local_startup variable (see below). Thus, the two - likely candidates for this value are - mountcritlocal for the typical system, and - mountcritremote if the system needs remote file - systems mounted to get access to the local_startup - directories; for example when /usr/local is NFS - mounted. For rc.conf within a - jail(8) NETWORKING is likely to - be an appropriate value. Extreme care should be taken when changing this - value, and before changing it one should ensure that there are adequate - provisions to recover from a failed boot (such as physical contact with - the machine, or reliable remote console access).
-
always_force_depends
-
(bool) Various rc.d scripts - use the force_depend function to check whether required services are - already running, and to start them if necessary. By default during boot - time this check is bypassed if the required service is enabled in - /etc/rc.conf[.local]. Setting this option will - bypass that check at boot time and always test whether or not the service - is actually running. Enabling this option is likely to increase your boot - time if services are enabled that utilize the force_depend check.
-
⟨name⟩_audit_user
-
(str) A user name or UID to use as the - audit(4) user for the service. Run the chrooted service - under this system group. By default, when an unprvileged user restarts a - service using a utility such as sudo or doas, the service's will audit - session will point to the unprivileged user, which may be undesirable. In - that case, this variable can be used to override the audit user using - setaudit(8).
-
⟨name⟩_chroot
-
(str) chroot(8) to this directory - before running the service.
-
⟨name⟩_cpuset
-
(str) A list of CPUs to run the service on. Passed - to cpuset(1) using the -l - flag.
-
⟨name⟩_fib
-
(int) The setfib(1) value to run - the service under.
-
⟨name⟩_group
-
(str) Unlike the - ⟨name⟩_user - setting, this setting has no effect if the service is not chrooted.
-
⟨name⟩_limits
-
(str) Resource limits to apply to the service using - limits(1). By default, resource limits are based on the - login class defined in - ⟨name⟩_login_class.
-
⟨name⟩_login_class
-
(str) Login class to be used with - ⟨name⟩_limits. - Defaults to “daemon”.
-
⟨name⟩_nice
-
(int) The nice(1) value to run the - service under.
-
⟨name⟩_oomprotect
-
(str) Use protect(1) to prevent - the service from being killed when swap space is exhausted. Use - “YES” to protect only the service - itself, and “ALL” to protect the - service and all its child processes. -

Please note that rc scripts which redefine

-
${argument}_cmd
- (see rc.subr(8)) such as PostgreSQL will not inherit the - OOM killer protection. -

This variable has no effect on services running within a - jail(8).

-
-
⟨name⟩_setup
-
(str) Run the specified setup script right before - starting the actual service command. Useful for automatic configuration - file generation.
-
⟨name⟩_umask
-
(int) Run the service using this - umask(1) value.
-
⟨name⟩_user
-
(str) Run the service under this user account.
-
⟨name⟩_svcj
-
(bool) If set to - “YES”, auto-jail the service with - inherited filesystem and other jail properties depending on - ⟨name⟩_svcj_options.
-
⟨name⟩_svcj_ipaddrs
-
(str) A list of IP addresses that the service jail - will be permitted to use. If this is not specified, the service jail will - be permitted to use all assigned IP addresses if networking is enabled in - the jail.
-
⟨name⟩_svcj_options
-
(str) A list of jail properties for the service. See - SERVICE JAILS for a list of valid - properties.
-
apm_enable
-
(bool) If set to - “YES”, enable support for Automatic - Power Management with the apm(8) command.
-
apmd_enable
-
(bool) Run apmd(8) to handle APM - event from userland. This also enables support for APM.
-
apmd_flags
-
(str) If apmd_enable is set to - “YES”, these are the flags to pass - to the apmd(8) daemon.
-
devd_enable
-
(bool) Run devd(8) to handle - device added, removed or unknown events from the kernel.
-
ddb_enable
-
(bool) Run ddb(8) to install - ddb(4) scripts at boot time.
-
ddb_config
-
(str) Configuration file for - ddb(8). Default - /etc/ddb.conf.
-
devmatch_enable
-
(bool) If set to - “NO”, disable auto-loading of kernel - modules with devmatch(8).
-
devmatch_blocklist
-
(str) A whitespace-separated list of kernel modules - to be ignored by devmatch(8). In addition, the - kenv(1) devmatch_blocklist is - appended to this variable to allow disabling of - devmatch(8) loaded modules from the boot loader.
-
devmatch_blacklist
-
(str) This variable is deprecated. Use - devmatch_blocklist instead. A whitespace-separated - list of kernel modules to be ignored by - devmatch(8).
-
kld_list
-
(str) A whitespace-separated list of kernel modules - to load right after the local disks are mounted, without any - .ko extension or path.
-
kldxref_enable
-
(bool) Set to - “NO” by default. Set to - “YES” to automatically rebuild - linker.hints files with - kldxref(8) at boot time.
-
kldxref_clobber
-
(bool) Set to - “NO” by default. If - kldxref_enable is true, setting to - “YES” will overwrite existing - linker.hints files at boot time. Otherwise, only - missing linker.hints files are generated.
-
kldxref_module_path
-
(str) Empty by default. A semi-colon - (‘;’) delimited list of paths - containing kld(4) modules. If empty, the contents of the - kern.module_path sysctl(8) are - used.
-
powerd_enable
-
(bool) If set to - “YES”, enable the system power - control facility with the powerd(8) daemon.
-
powerd_flags
-
(str) If powerd_enable is set - to “YES”, these are the flags to - pass to the powerd(8) daemon.
-
svcj_all_enable
-
Enable auto-jailing of all services which are not explicitly excluded. See - SERVICE JAILS for more info.
-
tmpmfs
-
Controls the creation of a /tmp memory file - system. Always happens if set to - “YES” and never happens if set to - “NO”. If set to anything else, a - memory file system is created if /tmp is not - writable.
-
tmpsize
-
Controls the size of a created /tmp memory file - system.
-
tmpmfs_flags
-
Extra options passed to the mdmfs(8) utility when the - memory file system for /tmp is created. The - default is “-S”, which inhibits the - use of softupdates on /tmp so that file system - space is freed without delay after file truncation or deletion. See - mdmfs(8) for other options you can use in - tmpmfs_flags.
-
varmfs
-
Controls the creation of a /var memory file - system. Always happens if set to - “YES” and never happens if set to - “NO”. If set to anything else, a - memory file system is created if /var is not - writable.
-
varsize
-
Controls the size of a created /var memory file - system.
-
varmfs_flags
-
Extra options passed to the mdmfs(8) utility when the - memory file system for /var is created. The - default is “-S”, which inhibits the - use of softupdates on /var so that file system - space is freed without delay after file truncation or deletion. See - mdmfs(8) for other options you can use in - varmfs_flags.
-
populate_var
-
Controls the automatic population of the /var file - system. Always happens if set to - “YES” and never happens if set to - “NO”. If set to anything else, a - memory file system is created if /var is not - writable. Note that this process requires access to certain commands in - /usr before /usr is - mounted on normal systems.
-
cleanvar_enable
-
(bool) Clean the /var - directory.
-
var_run_enable
-
(bool) Set to "YES" to enable saving of - the /var/run directory structure into an mtree - file at shutdown and the reload of the /var/run - directory structure at boot.
-
var_run_autosave
-
(bool) In some cases it may be undesirable to save - /var/run at shutdown. When set to "NO" - /var/run is loaded at reboot but not saved at - shutdown. Typically in this scenario ‘service - var_run save’ would be performed to save a copy of the - /var/run directory structure once, to be reloaded - during all subsequent reboots.
-
var_run_mtree
-
(str) Where to save the - /var/run mtree. The default location is - /var/db/mtree/BSD.var-run.mtree.
-
local_startup
-
(str) List of directories to search for startup - script files.
-
script_name_sep
-
(str) The field separator to use for breaking down - the list of startup script files into individual filenames. The default is - a space. It is not necessary to change this unless there are startup - scripts with names containing spaces.
-
hostapd_enable
-
(bool) Set to - “YES” to start - hostapd(8) at system boot time.
-
hostname
-
(str) The fully qualified domain name (FQDN) of this - host on the network. This should almost certainly be set to something - meaningful, even if there is no network connection. If - dhclient(8) is used to set the hostname via DHCP, this - variable should be set to an empty string. Within a - jail(8) the hostname is generally already set and this - variable may be absent. If this value remains unset when the system is - done booting your console login will display the default hostname of - “Amnesiac”.
-
nisdomainname
-
(str) The NIS domain name of this host, or - “NO” if NIS is not used.
-
hostid_enable
-
(bool) If set to - “NO”, disable the generation or - saving of the hostid and - machine-id files at system boot and shutdown.
-
hostid_file
-
(str) Path to the hostid - file, default /etc/hostid.
-
hostid_uuidgen_flags
-
(str) Flags passed to uuidgen(1) - when generating a software host UUID. This is used only if the system - cannot determine a hardware UUID. Set to - “-r” by default.
-
machine_id_file
-
(str) Path to the machine-id - file, default /etc/machine-id.
-
dhclient_program
-
(str) Path to the DHCP client program, defaulting to - /sbin/dhclient.
-
dhclient_flags
-
(str) Additional flags to pass to the DHCP client - program. See the dhclient(8) manpage for a description - of the command line options available.
-
dhclient_flags_⟨iface⟩
-
Additional flags to pass to the DHCP client program running on - iface only. When specified, this variable overrides - dhclient_flags.
-
background_dhclient
-
(bool) Set to - “YES” to start the DHCP client in - background. This can cause trouble with applications depending on a - working network, but it will provide a faster startup in many cases.
-
background_dhclient_⟨iface⟩
-
When specified, this variable overrides the - background_dhclient variable for interface - iface only.
-
dhclient_arpwait
-
(bool) Set to - “NO” to stop - dhclient(8) from waiting for ARP resolution, to make the - system boot faster. This may be done on networks where the DHCP server is - certain to know whether an address is available.
-
synchronous_dhclient
-
(bool) Set to - “YES” to start - dhclient(8) synchronously at startup. This behavior can - be overridden on a per-interface basis by replacing the - “DHCP” keyword in the - ifconfig_⟨interface⟩ - variable with “SYNCDHCP” or - “NOSYNCDHCP”.
-
defaultroute_delay
-
(int) When set to a positive value, wait up to this - long after configuring DHCP interfaces at startup to give the interfaces - time to receive a lease.
-
firewall_enable
-
(bool) Set to - “YES” to load firewall rules at - startup. If the kernel was not built with options - IPFIREWALL, the ipfw.ko kernel module will - be loaded. See also ipfilter_enable.
-
firewall_script
-
(str) This variable specifies the full path to the - firewall script to run. The default is - /etc/rc.firewall.
-
firewall_type
-
(str) Names the firewall type from the selection in - /etc/rc.firewall, or the file which contains the - local firewall ruleset. Valid selections from - /etc/rc.firewall are: -

-
-
-
unrestricted IP access
-
-
all IP services disabled, except via - “lo0”
-
-
basic protection for a workstation
-
-
basic protection for a workstation using stateful firewalling
-
-
basic protection for a LAN.
-
-

If a filename is specified, the full path must be given.

-

Most of the predefined rulesets define additional - configuration variables. These are documented in - /etc/rc.firewall.

-
-
firewall_quiet
-
(bool) Set to - “YES” to disable the display of - firewall rules on the console during boot.
-
firewall_logging
-
(bool) Set to - “YES” to enable firewall event - logging. This is equivalent to the - IPFIREWALL_VERBOSE kernel option.
-
firewall_logif
-
(bool) Set to - “YES” to create pseudo interface - ipfw0 for logging. For more details, see - ipfw(8) manual page.
-
firewall_flags
-
(str) Flags passed to ipfw(8) if - firewall_type specifies a filename.
-
firewall_coscripts
-
(str) List of executables and/or rc scripts to run - after firewall starts/stops. Default is empty.
-
firewall_nat_enable
-
(bool) The ipfw(8) equivalent of - natd_enable. Setting this to - “YES” will automatically load the - ipfw(8) NAT kernel module if - firewall_enable is also set to - “YES”.
-
firewall_nat_interface
-
(str) The ipfw(8) equivalent of - natd_interface. This is the name of the public - interface or IP address on which kernel NAT should run.
-
firewall_nat_flags
-
(str) Additional configuration parameters for kernel - NAT should be placed here.
-
firewall_nat64_enable
-
(bool) Setting this to - “YES” will automatically load the - ipfw(8) NAT64 kernel module if - firewall_enable is also set to - “YES”.
-
firewall_nptv6_enable
-
(bool) Setting this to - “YES” will automatically load the - ipfw(8) NPTv6 kernel module if - firewall_enable is also set to - “YES”.
-
firewall_pmod_enable
-
(bool) Setting this to - “YES” will automatically load the - ipfw(8) pmod kernel module if - firewall_enable is also set to - “YES”.
-
dummynet_enable
-
(bool) Setting this to - “YES” will automatically load the - dummynet(4) module if - firewall_enable is also set to - “YES”.
-
ipfw_netflow_enable
-
(bool) Setting this to - “YES” will enable netflow logging - via ng_netflow(4). -

By default a ipfw rule is inserted and all packets are - duplicated with the ngtee command and netflow packets are sent to - 127.0.0.1 on the netflow port using protocol version 5.

-
-
ipfw_netflow_hook
-
(int) netflow hook name, must be numerical (default - 9995).
-
ipfw_netflow_rule
-
(int) ipfw rule number (default - 1000).
-
ipfw_netflow_ip
-
(str) Destination server ip for receiving netflow - data (default 127.0.0.1).
-
ipfw_netflow_port
-
(int) Destination server port for receiving netflow - data (default 9995).
-
ipfw_netflow_version
-
(int) Do not set for using version 5 of the netflow - protocol, set it to 9 for using version 9.
-
ipfw_netflow_fib
-
(int) Only match packet in FIB - ipfw_netflow_fib (default is undefined meaning all - FIBs).
-
natd_program
-
(str) Path to natd(8).
-
natd_enable
-
(bool) Set to - “YES” to enable - natd(8). firewall_enable must also - be set to “YES”, and - divert(4) sockets must be enabled in the kernel. If the - kernel was not built with options IPDIVERT, the - ipdivert.ko kernel module will be loaded.
-
natd_interface
-
(str) This is the name of the public interface on - which natd(8) should run. The interface may be given as - an interface name or as an IP address.
-
natd_flags
-
(str) Additional natd(8) flags - should be placed here. The -n or - -a flag is automatically added with the above - natd_interface as an argument.
-
ipfilter_enable
-
(bool) Set to - “NO” by default. Setting this to - “YES” enables - ipf(8) packet filtering. -

Typical usage will require putting

-
- 
ipfilter_enable="YES"
-ipnat_enable="YES"
-ipmon_enable="YES"
-ipfs_enable="YES"
-
-

into /etc/rc.conf and editing - /etc/ipf.rules and - /etc/ipnat.rules appropriately.

-

Note that ipfilter_enable and - ipnat_enable can be enabled independently. - ipmon_enable and ipfs_enable - both require at least one of ipfilter_enable and - ipnat_enable to be enabled.

-

Having

-
- 
options IPFILTER
-options IPFILTER_LOG
-options IPFILTER_DEFAULT_BLOCK
-
-

in the kernel configuration file is a good idea, too.

-
-
ipfilter_program
-
(str) Path to ipf(8) (default - /sbin/ipf).
-
ipfilter_rules
-
(str) Set to /etc/ipf.rules - by default. This variable contains the name of the filter rule definition - file. The file is expected to be readable for the ipf(8) - command to execute.
-
ipfilter_flags
-
(str) Empty by default. This variable contains flags - passed to the ipf(8) program.
-
ipnat_enable
-
(bool) Set to - “NO” by default. Set it to - “YES” to enable - ipnat(8) network address translation. See - ipfilter_enable for a detailed discussion.
-
ipnat_program
-
(str) Path to ipnat(8) (default - /sbin/ipnat).
-
ipnat_rules
-
(str) Set to - /etc/ipnat.rules by default. This variable - contains the name of the file holding the network address translation - definition. This file is expected to be readable for the - ipnat(8) command to execute.
-
ipnat_flags
-
(str) Empty by default. This variable contains flags - passed to the ipnat(8) program.
-
ipmon_enable
-
(bool) Set to - “NO” by default. Set it to - “YES” to enable - ipmon(8) monitoring (logging ipf(8) - and ipnat(8) events). Setting this variable needs - setting ipfilter_enable or - ipnat_enable too. See - ipfilter_enable for a detailed discussion.
-
ipmon_program
-
(str) Path to ipmon(8) (default - /sbin/ipmon).
-
ipmon_flags
-
(str) Set to - “-Ds” by default. This variable - contains flags passed to the ipmon(8) program. Another - typical example would be “-D - /var/log/ipflog” to have - ipmon(8) log directly to a file bypassing - syslogd(8). Make sure to adjust - /etc/newsyslog.conf in such case like this: -
- 
/var/log/ipflog  640  10  100  *  Z  /var/run/ipmon.pid
-
-
-
ipfs_enable
-
(bool) Set to - “NO” by default. Set it to - “YES” to enable - ipfs(8) saving the filter and NAT state tables during - shutdown and reloading them during startup again. Setting this variable - needs setting ipfilter_enable or - ipnat_enable to - “YES” too. See - ipfilter_enable for a detailed discussion. Note that - if kern_securelevel is set to 3, - ipfs_enable cannot be used because the raised - securelevel will prevent ipfs(8) from saving the state - tables at shutdown time.
-
ipfs_program
-
(str) Path to ipfs(8) (default - /sbin/ipfs).
-
ipfs_flags
-
(str) Empty by default. This variable contains flags - passed to the ipfs(8) program.
-
pf_enable
-
(bool) Set to - “NO” by default. Setting this to - “YES” enables - pf(4) packet filtering. -

Typical usage will require putting

-

-
pf_enable="YES"
-

into /etc/rc.conf and editing - /etc/pf.conf appropriately. Adding

-

-
device pf
-

builds support for pf(4) into the kernel, - otherwise the kernel module will be loaded.

-
-
pf_rules
-
(str) Path to pf(4) ruleset - configuration file (default /etc/pf.conf).
-
pf_program
-
(str) Path to pfctl(8) (default - /sbin/pfctl).
-
pf_flags
-
(str) If pf_enable is set to - “YES”, these flags are passed to the - pfctl(8) program when loading the ruleset.
-
pf_fallback_rules_enable
-
(bool) Set to - “NO” by default. Setting this to - “YES” enables loading - pf_fallback_rules_file or - pf_fallback_rules in case of a problem when loading - the ruleset in pf_rules.
-
pf_fallback_rules_file
-
(str) Path to a pf ruleset to load in case of - failure when loading the ruleset in pf_rules - (default /etc/pf-fallback.conf).
-
pf_fallback_rules
-
(str) A pf ruleset to load in case of failure when - loading the ruleset in pf_rules and - pf_fallback_rules_file is not found. Multiple rules - can be set as follows: -
- 
pf_fallback_rules="
-	block drop log all
-	pass in quick on em0"
-
-
-
- The default fallback rule is “block drop log all”
-
pflog_enable
-
(bool) Set to - “NO” by default. Setting this to - “YES” enables - pflogd(8) which logs packets from the - pf(4) packet filter.
-
pflog_logfile
-
(str) If pflog_enable is set - to “YES” this controls where - pflogd(8) stores the logfile (default - /var/log/pflog). Check - /etc/newsyslog.conf to adjust logfile rotation for - this.
-
pflog_program
-
(str) Path to pflogd(8) (default - /sbin/pflogd).
-
pflog_flags
-
(str) Empty by default. This variable contains - additional flags passed to the pflogd(8) program.
-
pflog_instances
-
(str) If logging to more than one - pflog(4) interface is desired, - pflog_instances is set to the list of - pflogd(8) instances that should be started at system - boot time. If pflog_instances is set, for each - whitespace-separated element in the list, - ⟨element⟩_dev - and - ⟨element⟩_logfile - elements are assumed to exist. - ⟨element⟩_dev - must contain the pflog(4) interface to be watched by the - named pflogd(8) instance. - ⟨element⟩_logfile - must contain the name of the logfile that will be used by the - pflogd(8) instance.
-
ftpproxy_enable
-
(bool) Set to - “NO” by default. Setting this to - “YES” enables - ftp-proxy(8) which supports the pf(4) - packet filter in translating ftp connections.
-
ftpproxy_flags
-
(str) Empty by default. This variable contains - additional flags passed to the ftp-proxy(8) - program.
-
ftpproxy_instances
-
(str) Empty by default. If multiple instances of - ftp-proxy(8) are desired at boot time, - ftpproxy_instances should contain a - whitespace-separated list of instance names. For each - element in the list, a variable named - ⟨element⟩_flags - should be defined, containing the command-line flags to be passed to the - ftp-proxy(8) instance.
-
pfsync_enable
-
(bool) Set to - “NO” by default. Setting this to - “YES” enables exposing - pf(4) state changes to other hosts over the network by - means of pfsync(4). The - pfsync_syncdev variable must also be set then.
-
pfsync_syncdev
-
(str) Empty by default. This variable specifies the - name of the network interface pfsync(4) should operate - through. It must be set accordingly if pfsync_enable - is set to “YES”.
-
pfsync_syncpeer
-
(str) Empty by default. This variable is optional. - By default, state change messages are sent out on the synchronisation - interface using IP multicast packets. The protocol is IP protocol 240, - PFSYNC, and the multicast group used is 224.0.0.240. When a peer address - is specified using the pfsync_syncpeer option, the - peer address is used as a destination for the pfsync traffic, and the - traffic can then be protected using ipsec(4). See the - pfsync(4) manpage for more details about using - ipsec(4) with pfsync(4) - interfaces.
-
pfsync_ifconfig
-
(str) Empty by default. This variable can contain - additional options to be passed to the ifconfig(8) - command used to set up pfsync(4).
-
tcp_extensions
-
(bool) Set to - “YES” by default. Setting this to - “NO” disables certain TCP options as - described by RFC 1323. - Setting this to “NO” might help - remedy such problems with connections as randomly hanging or other weird - behavior. Some network devices are known to be broken with respect to - these options.
-
log_in_vain
-
(int) Set to 0 by default. The - sysctl(8) variables, - net.inet.tcp.log_in_vain and - net.inet.udp.log_in_vain, as described in - tcp(4) and udp(4), are set to the - given value.
-
tcp_keepalive
-
(bool) Set to - “YES” by default. Setting to - “NO” will disable probing idle TCP - connections to verify that the peer is still up and reachable.
-
tcp_drop_synfin
-
(bool) Set to - “NO” by default. Setting to - “YES” will cause the kernel to - ignore TCP frames that have both the SYN and FIN flags set. This prevents - OS fingerprinting, but may break some legitimate applications.
-
icmp_drop_redirect
-
(bool) Set to - “AUTO” by default. This setting will - be identical to “YES”, if a dynamic - routing daemon is enabled, because redirect processing may cause - performance issues for large routing tables. If no such service is - enabled, this setting behaves like a - “NO”. Setting to - “YES” will cause the kernel to - ignore ICMP REDIRECT packets. Setting to - “NO” will cause the kernel to - process ICMP REDIRECT packets. Refer to icmp(4) for more - information.
-
icmp_log_redirect
-
(bool) Set to - “NO” by default. Setting to - “YES” will cause the kernel to log - ICMP REDIRECT packets. Note that the log messages are not rate-limited, so - this option should only be used for troubleshooting networks. Refer to - icmp(4) for more information.
-
icmp_bmcastecho
-
(bool) Set to - “YES” to respond to broadcast or - multicast ICMP ping packets. Refer to icmp(4) for more - information.
-
ip_portrange_first
-
(int) If not set to - “NO”, this is the first port in the - default portrange. Refer to ip(4) for more - information.
-
ip_portrange_last
-
(int) If not set to - “NO”, this is the last port in the - default portrange. Refer to ip(4) for more - information.
-
network_interfaces
-
(str) Set to the list of network interfaces to - configure on this host or “AUTO” - (the default) for all current interfaces. Setting the - network_interfaces variable to anything other than - the default is deprecated. Interfaces that the administrator wishes to - store configuration for, but not start at boot should be configured with - the “NOAUTO” keyword in their - ifconfig_⟨interface⟩ - variables as described below. -

An - ifconfig_⟨interface⟩ - variable is assumed to exist for each value of - interface. When an interface name contains any of - the characters “.-/+” they are - translated to “_” before lookup. - For example, the interface em0.102 would be - configured using the variable - ifconfig_em0_102.

-

The variable can contain arguments to - ifconfig(8), as well as special case-insensitive - keywords described below. Such keywords are removed before passing the - value to ifconfig(8) while the order of the other - arguments is preserved.

-

For example, to assign the IPv4 address 192.0.2.1/24 to the - interface em0:

-
- 
ifconfig_em0="inet 192.0.2.1/24 up"
-
-

If the variable - ifconfig_⟨interface⟩_ipv6 - is set, then - ifconfig_⟨interface⟩ - does not need to be set unless an IPv4 address should also be assigned - to the interface.

-

It is possible to add IP alias entries using - ifconfig(8) syntax with the address family keyword - such as inet. Assuming that the interface in - question was em0, it might look something like - this:

-
- 
ifconfig_em0_alias0="inet 127.0.0.253/32"
-ifconfig_em0_alias1="inet 127.0.0.254/32"
-
-

It also possible to configure multiple IP addresses in - Classless Inter-Domain Routing (CIDR) address notation, whose each - address component can be a range like inet - 192.0.2.5-23/24 or inet6 - 2001:db8:1-f::1/64. This notation allows address and prefix - length part only, not the other address modifiers. Note that the maximum - number of the generated addresses from a range specification is limited - to an integer value specified in - netif_ipexpand_max in - rc.conf because a small typo can unexpectedly - generate a large number of addresses. The default value is - 2048. It can be increased by adding the - following line into rc.conf:

-
- 
netif_ipexpand_max="4096"
-
-

In the case of 192.0.2.5-23/24, the - address 192.0.2.5 will be configured with the prefix length /24 and the - addresses 192.0.2.6 to 192.0.2.23 with the non-conflicting prefix length - /32 as explained in the ifconfig(8) alias section. - Note that this special CIDR handling is only for - inet, not for the other address families such as - inet6.

-

With the interface in question being - em0, an example could look like:

-
- 
ifconfig_em0_alias2="inet 192.0.2.129/27"
-ifconfig_em0_alias3="inet 192.0.2.1-5/28"
-
-

and so on.

-

Note that deprecated - ipv4_addrs_⟨interface⟩ - variable was supported for IPv4 CIDR address notation. The - ifconfig_⟨interface⟩_alias⟨n⟩ - variable replaces it, though - ipv4_addrs_⟨interface⟩ - is still supported for backward compatibility.

-

For each - ifconfig_⟨interface⟩_alias⟨n⟩ - entry with an address family keyword, its contents are passed to - ifconfig(8). Execution stops at the first unsuccessful - access, so if something like this is present:

-
- 
ifconfig_em0_alias0="inet 127.0.0.251/32"
-ifconfig_em0_alias1="inet 127.0.0.252/32"
-ifconfig_em0_alias2="inet 127.0.0.253/32"
-ifconfig_em0_alias4="inet 127.0.0.254/32"
-
-

Then note that alias4 would - be added - since the search would stop with the missing - “alias3” entry. Because of this - difficult to manage behavior, there is - ifconfig_⟨interface⟩_aliases - variable, which has the same functionality as - ifconfig_⟨interface⟩_alias⟨n⟩ - and can have all of the entries in a variable like the following:

-
- 
ifconfig_em0_aliases="\
-	inet 127.0.0.251/32 \
-	inet 127.0.0.252/32 \
-	inet 127.0.0.253/32 \
-	inet 127.0.0.254/32"
-
-

It also supports netmask notation for backward - compatibility.

-

If the - /etc/start_if.⟨interface⟩ - file is present, it is read and executed by the sh(1) - interpreter before configuring the interface as specified in the - ifconfig_⟨interface⟩ - and - ifconfig_⟨interface⟩_alias⟨n⟩ - variables.

-

If a - vlans_⟨interface⟩ - variable is set, a vlan(4) interface will be created - for each item in the list with the vlandev - argument set to interface. If a vlan interface's - name is a number, then that number is used as the vlan tag and the new - vlan interface is named - interface.tag. Otherwise, - the vlan tag must be specified via a vlan - parameter in the - create_args_⟨interface⟩ - variable.

-

To create a vlan device named em0.101 - on em0 with the vlan tag 101 and the optional - IPv4 address 192.0.2.1/24:

-
- 
vlans_em0="101"
-ifconfig_em0_101="inet 192.0.2.1/24"
-
-

To create a vlan device named myvlan - on em0 with the vlan tag 102:

-
- 
vlans_em0="myvlan"
-create_args_myvlan="vlan 102"
-
-

If a - wlans_⟨interface⟩ - variable is set, an wlan(4) interface will be created - for each item in the list with the wlandev - argument set to interface. Further wlan cloning - arguments may be passed to the ifconfig(8) - create command by setting the - create_args_⟨interface⟩ - variable. One or more wlan(4) devices must be created - for each wireless device as of FreeBSD 8.0. - Debugging flags for wlan(4) devices as set by - wlandebug(8) may be specified with an - wlandebug_⟨interface⟩ - variable. The contents of this variable will be passed directly to - wlandebug(8).

-

If the - ifconfig_⟨interface⟩ - contains the keyword “NOAUTO” then - the interface will not be configured at boot or by - /etc/pccard_ether when - network_interfaces is set to - “AUTO”.

-

It is possible to bring up an interface with DHCP by adding - “DHCP” to the - ifconfig_⟨interface⟩ - variable. For instance, to initialize the em0 - device via DHCP, it is possible to use something like:

-
- 
ifconfig_em0="DHCP"
-
-

If you want to configure your wireless interface with - wpa_supplicant(8) for use with WPA, EAP/LEAP or WEP, - you need to add “WPA” to the - ifconfig_⟨interface⟩ - variable.

-

On the other hand, if you want to configure your wireless - interface with hostapd(8), you need to add - “HOSTAP” to the - ifconfig_⟨interface⟩ - variable. hostapd(8) will use the settings from - /etc/hostapd-⟨interface⟩.conf

-

Finally, you can add ifconfig(8) options in - this variable, in addition to the - /etc/start_if.⟨interface⟩ - file. For instance, to configure an ath(4) wireless - device in station mode with an address obtained via DHCP, using WPA - authentication and 802.11b mode, it is possible to use something - like:

-
- 
wlans_ath0="wlan0"
-ifconfig_wlan0="DHCP WPA mode 11b"
-
-

In addition to the - ifconfig_⟨interface⟩ - form, a fallback variable ifconfig_DEFAULT may be - configured. It will be used for all interfaces with no - ifconfig_⟨interface⟩ - variable.

-

It is also possible to rename an interface by doing:

-
- 
ifconfig_em0_name="net0"
-ifconfig_net0="inet 192.0.2.1/24"
-
-
-
ipv6_enable
-
(bool) This variable is deprecated. Use - ifconfig_⟨interface⟩_ipv6 - and ipv6_activate_all_interfaces if necessary. -

If the variable is - “YES”, - “inet6 accept_rtadv” is added to - all of - ifconfig_⟨interface⟩_ipv6 - and the ipv6_activate_all_interfaces variable is - defined as “YES”.

-
-
ipv6_prefer
-
(bool) This variable is deprecated. Use - ip6addrctl_policy instead. -

If the variable is - “YES”, the default address - selection policy table set by ip6addrctl(8) will be - IPv6-preferred.

-

If the variable is “NO”, - the default address selection policy table set by - ip6addrctl(8) will be IPv4-preferred.

-
-
ipv6_activate_all_interfaces
-
(bool) This controls initial configuration on - IPv6-capable interfaces with no corresponding - ifconfig_⟨interface⟩_ipv6 - variable. Note that it is not always necessary to set this variable to - “YES” to use IPv6 functionality on - FreeBSD. In most cases, just configuring - ifconfig_⟨interface⟩_ipv6 - variables works. -

If the variable is “NO”, - all interfaces which do not have a corresponding - ifconfig_⟨interface⟩_ipv6 - variable will be marked as - “IFDISABLED” at creation. This - means that all IPv6 functionality on that interface is completely - disabled to enforce a security policy. If the variable is set to - “YES”, the flag will be cleared on all of the - interfaces.

-

In most cases, just defining an - ifconfig_⟨interface⟩_ipv6 - for an IPv6-capable interface should be sufficient. However, if an - interface is added dynamically (by some tunneling protocols such as PPP, - for example), it is often difficult to define the variable in advance. - In such a case, configuring the - “IFDISABLED” flag can be disabled - by setting this variable to “YES”.

-

For more details of the - “IFDISABLED” flag and keywords - “inet6 ifdisabled”, see - ifconfig(8).

-

Default is “NO”.

-
-
ipv6_privacy
-
(bool) If the variable is - “YES” privacy addresses will be - generated for each IPv6 interface as described in RFC 4941.
-
ipv6_network_interfaces
-
(str) This is the IPv6 equivalent of - network_interfaces. Normally manual configuration of - this variable is not needed.
-
ipv6_cpe_wanif
-
(str) If the variable is set to an interface name, - the ifconfig(8) options “inet6 -no_radr - accept_rtadv” will be added to the specified interface - automatically before evaluating - ifconfig_⟨interface⟩_ipv6, - and two sysctl(8) variables - net.inet6.ip6.rfc6204w3 and - net.inet6.ip6.no_radr will be set to 1. -

This means the specified interface will accept ICMPv6 Router - Advertisement messages on that link and add the discovered routers into - the Default Router List. While the other interfaces can still accept RA - messages if the “inet6 accept_rtadv” option is specified, - adding routes into the Default Router List will be disabled by - “inet6 no_radr” option by default. See - ifconfig(8) for more details.

-

Note that ICMPv6 Router Advertisement messages will be - accepted even when net.inet6.ip6.forwarding is 1 - (packet forwarding is enabled) when - net.inet6.ip6.rfc6204w3 is set to 1.

-

Default is “NO”.

-
-
ifconfig_⟨interface⟩_descr
-
(str) This assigns arbitrary description to an - interface. The sysctl(8) variable - net.ifdescr_maxlen limits its length. This static - setting may be overridden by commands started with dynamic interface - configuration utilities like dhclient(8) hooks. The - description can be seen with ifconfig(8) command and it - may be exported with bsnmpd(1) daemon using its MIB-2 - module.
-
ifconfig_⟨interface⟩_ipv6
-
(str) IPv6 functionality on an interface should be - configured by - ifconfig_⟨interface⟩_ipv6, - instead of setting ifconfig parameters in - ifconfig_⟨interface⟩. - If this variable is empty, all IPv6 configurations on the specified - interface by other variables such as - ipv6_prefix_⟨interface⟩ - will be ignored. -

Aliases should be set by - ifconfig_⟨interface⟩_alias⟨n⟩ - with “inet6” keyword. For - example:

-
- 
ifconfig_em0_ipv6="inet6 2001:db8:1::1 prefixlen 64"
-ifconfig_em0_alias0="inet6 2001:db8:2::1 prefixlen 64"
-
-

Interfaces that have an “inet6 - accept_rtadv” keyword in - ifconfig_⟨interface⟩_ipv6 - setting will be automatically configured by SLAAC (StateLess Address - AutoConfiguration) described in RFC - 4862.

-

Note that a link-local address will be automatically - configured in addition to the configured global-scope addresses because - the IPv6 specifications require it on each link. The address is - calculated from the MAC address by using an algorithm defined in - RFC 4862, - Section 5.3.

-

If only a link-local address is needed on the interface, the - following configuration can be used:

-
- 
ifconfig_em0_ipv6="inet6 auto_linklocal"
-
-

A link-local address can also be configured manually. This is - useful for the default router address of an IPv6 router so that it does - not change when the network interface card is replaced. For example:

-
- 
ifconfig_em0_ipv6="inet6 fe80::1 prefixlen 64"
-
-
-
ipv6_prefix_⟨interface⟩
-
(str) If one or more prefixes are defined in - ipv6_prefix_⟨interface⟩ - addresses based on each prefix and the EUI-64 interface index will be - configured on that interface. Note that this variable will be ignored when - ifconfig_⟨interface⟩_ipv6 - is empty. -

For example, the following configuration

-
- 
ipv6_prefix_em0="2001:db8:1:0 2001:db8:2:0"
-
-

is equivalent to the following:

-
- 
ifconfig_em0_alias0="inet6 2001:db8:1:: eui64 prefixlen 64"
-ifconfig_em0_alias1="inet6 2001:db8:1:: prefixlen 64 anycast"
-ifconfig_em0_alias2="inet6 2001:db8:2:: eui64 prefixlen 64"
-ifconfig_em0_alias3="inet6 2001:db8:2:: prefixlen 64 anycast"
-
-

These Subnet-Router anycast addresses will be added only when - ipv6_gateway_enable is YES.

-
-
ipv6_default_interface
-
(str) If not set to - “NO”, this is the default output - interface for scoped addresses. This works only with - ipv6_gateway_enable="NO".
-
ip6addrctl_enable
-
(bool) This variable is to enable configuring - default address selection policy table (RFC 3484). The table can be - specified in another variable ip6addrctl_policy. For - ip6addrctl_policy the following keywords can be - specified: “ipv4_prefer”, - “ipv6_prefer”, or - “AUTO”. -

If “ipv4_prefer” or - “ipv6_prefer” is specified, - ip6addrctl(8) installs a pre-defined policy table - described in Section 10.3 (IPv4-preferred) or 2.1 (IPv6-preferred) of - RFC 3484.

-

If “AUTO” is specified, - it attempts to read a file /etc/ip6addrctl.conf - first. If this file is found, ip6addrctl(8) reads and - installs it. If not found, a policy is automatically set according to - ipv6_activate_all_interfaces variable; if the - variable is set to “YES” the - IPv6-preferred one is used. Otherwise IPv4-preferred.

-

The default value of ip6addrctl_enable - and ip6addrctl_policy are - “YES” and - “AUTO”, respectively.

-
-
cloned_interfaces
-
(str) Set to the list of clonable network interfaces - to create on this host. Further cloning arguments may be passed to the - ifconfig(8) create command for - each interface by setting the - create_args_⟨interface⟩ - variable. If an interface name is specified with “:sticky” - keyword, the interface will not be destroyed even when - rc.d/netif script is invoked with - “stop” argument. This is useful when reconfiguring the - interface without destroying it. Entries in - cloned_interfaces are automatically appended to - network_interfaces for configuration.
-
cloned_interfaces_sticky
-
(bool) This variable is to globally enable - functionality of “:sticky” keyword in - cloned_interfaces for all interfaces. The default - value is “NO”. Even if this variable is specified to - “YES”, “:nosticky” keyword can be used to - override it on per interface basis.
-
gif_interfaces
-
Set to the list of gif(4) tunnel interfaces to configure - on this host. A - gifconfig_⟨interface⟩ - variable is assumed to exist for each value of - interface. The value of this variable is used to - configure the link layer of the tunnel using the - tunnel option to ifconfig(8). - Additionally, this option ensures that each listed interface is created - via the create option to - ifconfig(8) before attempting to configure it. -

For example, configure two gif(4) interfaces - with:

-
- 
gif_interfaces="gif0 gif1"
-gifconfig_gif0="100.64.0.1 100.64.0.2"
-ifconfig_gif0="inet 10.0.0.1/30 10.0.0.2"
-gifconfig_gif1="inet6 2a00::1 2a01::1"
-ifconfig_gif1="inet 10.1.0.1/30 10.1.0.2"
-
-
-
ppp_enable
-
(bool) If set to - “YES”, run the - ppp(8) daemon.
-
ppp_profile
-
(str) The name of the profile to use from - /etc/ppp/ppp.conf. Also used for per-profile - overrides of ppp_mode and - ppp_nat, and - ppp_⟨profile⟩_unit. - When the profile name contains any of the characters - “.-/+” they are translated to - “_” for the proposes of the override - variable names.
-
ppp_mode
-
(str) Mode in which to run the - ppp(8) daemon.
-
ppp_⟨profile⟩_mode
-
(str) Overrides the global - ppp_mode for profile. Accepted - modes are “auto”, - “ddial”, - “direct” and - “dedicated”. See the manual for a - full description.
-
ppp_nat
-
(bool) If set to - “YES”, enables network address - translation. Used in conjunction with gateway_enable - allows hosts on private network addresses access to the Internet using - this host as a network address translating router. Default is - “YES”.
-
ppp_⟨profile⟩_nat
-
(str) Overrides the global - ppp_nat for profile.
-
ppp_⟨profile⟩_unit
-
(int) Set the unit number to be used for this - profile. See the manual description of - -unitN for details.
-
ppp_user
-
(str) The name of the user under which - ppp(8) should be started. By default, - ppp(8) is started as - “root”.
-
rc_conf_files
-
(str) This option is used to specify a list of files - that will override the settings in - /etc/defaults/rc.conf. The files will be read in - the order in which they are specified and should include the full path to - the file. By default, the files specified are - /etc/rc.conf and - /etc/rc.conf.local.
-
zfs_enable
-
(bool) If set to - “YES”, - /etc/rc.d/zfs will attempt to automatically mount - ZFS file systems and initialize ZFS volumes (ZVOLs).
-
zpool_reguid
-
(str) A space-separated list of ZFS pool names for - which new pool GUIDs should be assigned upon first boot. This is useful - when using a ZFS pool copied from a template, such as a virtual machine - image.
-
zpool_upgrade
-
(str) A space-separated list of ZFS pool names for - which the version should be upgraded upon first boot. This is useful when - using a ZFS pool generated by the makefs(8) - utility.
-
gptboot_enable
-
(bool) If set to - “YES”, - /etc/rc.d/gptboot will log if the system - successfully (or not) booted from a GPT partition, which had the - bootonce attribute set using - gpart(8) utility.
-
geli_devices
-
(str) List of devices to automatically attach on - boot. Note that .eli devices from /etc/fstab are - automatically appended to this list.
-
geli_groups
-
(str) List of groups containing devices to - automatically attach on boot with the same keyfiles and passphrase. This - must be accompanied with a corresponding - geli_⟨group⟩_devices - variable.
-
geli_tries
-
(int) Number of times user is asked for the - pass-phrase. If empty, it will be taken from - kern.geom.eli.tries sysctl variable.
-
geli_default_flags
-
(str) Default flags to use by - geli(8) when configuring disk encryption. Flags can be - configured for every device separately by defining the - geli_⟨device⟩_flags - variable, and for every group separately by defining the - geli_⟨group⟩_flags - variable.
-
geli_autodetach
-
(str) Specifies if GELI devices should be marked for - detach on last close after file systems are mounted. Default is - “YES”. This can be changed for every - device separately by defining the - geli_⟨device⟩_autodetach - variable.
-
root_rw_mount
-
(bool) Set to - “YES” by default. After the file - systems are checked at boot time, the root file system is remounted as - read-write if this is set to “YES”. - Diskless systems that mount their root file system from a read-only remote - NFS share should set this to “NO” in - their rc.conf.
-
fsck_y_enable
-
(bool) If set to - “YES”, fsck(8) - will be run with the -y flag if the initial preen - of the file systems fails.
-
background_fsck
-
(bool) If set to - “NO”, the system will not attempt to - run fsck(8) in the background where possible.
-
background_fsck_delay
-
(int) The amount of time in seconds to sleep before - starting a background fsck(8). It defaults to sixty - seconds to allow large applications such as the X server to start before - disk I/O bandwidth is monopolized by fsck(8). If set to - a negative number, the background file system check will be delayed - indefinitely to allow the administrator to run it at a more convenient - time. For example it may be run from cron(8) by adding a - line like -

-
0 4 * * * root /etc/rc.d/bgfsck - forcestart
-

to /etc/crontab.

-
-
netfs_types
-
(str) List of file system types that are - network-based. This list should generally not be modified by end users. - Use extra_netfs_types instead.
-
extra_netfs_types
-
(str) If set to something other than - “NO” (the default), this variable - extends the list of file system types for which automatic mounting at - startup by rc(8) should be delayed until the network is - initialized. It should contain a whitespace-separated list of network file - system descriptor pairs, each consisting of a file system type as passed - to mount(8) and a human-readable, one-word description, - joined with a colon (‘:’). Extending - the default list in this way is only necessary when third party file - system types are used.
-
syslogd_enable
-
(bool) If set to - “YES”, run the - syslogd(8) daemon. Note, the - syslogd_oomprotect variable is set to - “YES” by default in - /etc/defaults/rc.conf.
-
syslogd_program
-
(str) Path to syslogd(8) (default - /usr/sbin/syslogd).
-
syslogd_flags
-
(str) If syslogd_enable is set - to “YES”, these are the flags to - pass to syslogd(8).
-
inetd_enable
-
(bool) If set to - “YES”, run the - inetd(8) daemon.
-
inetd_program
-
(str) Path to inetd(8) (default - /usr/sbin/inetd).
-
inetd_flags
-
(str) If inetd_enable is set - to “YES”, these are the flags to - pass to inetd(8).
-
hastd_enable
-
(bool) If set to - “YES”, run the - hastd(8) daemon.
-
hastd_program
-
(str) Path to hastd(8) (default - /sbin/hastd).
-
hastd_flags
-
(str) If hastd_enable is set - to “YES”, these are the flags to - pass to hastd(8).
-
local_unbound_enable
-
(bool) If set to - “YES”, run the - unbound(8) daemon as a local caching DNS resolver. Note, - the local_unbound_oomprotect variable is set to - “YES” by default in - /etc/defaults/rc.conf.
-
nscd_enable
-
(bool) Set to - “YES” to start the - nscd(8) caching daemon for the - nsswitch subsystem.
-
nscd_flags
-
(str) If nscd_enable is set to - “YES”, these flags are passed to - nscd(8).
-
kdc_enable
-
(bool) Set to - “YES” to start a Kerberos 5 - authentication server at boot time.
-
kdc_program
-
(str) If kdc_enable is set to - “YES” this is the path to Kerberos 5 - Authentication Server.
-
kdc_flags
-
(str) Empty by default. This variable contains - additional flags to be passed to the Kerberos 5 authentication - server.
-
kadmind_enable
-
(bool) Set to - “YES” to start - kadmind(8), the Kerberos 5 Administration Daemon; set to - “NO” on a slave server.
-
kadmind_program
-
(str) If kadmind_enable is set - to “YES” this is the path to - Kerberos 5 Administration Daemon.
-
kpasswdd_enable
-
(bool) Set to - “YES” to start - kpasswdd(8), the Kerberos 5 Password-Changing Daemon; - set to “NO” on a slave server.
-
kpasswdd_program
-
(str) If kpasswdd_enable is - set to “YES” this is the path to - Kerberos 5 Password-Changing Daemon.
-
kfd_enable
-
(bool) Set to - “YES” to start - kfd(8), the Kerberos 5 ticket forwarding daemon, at the - boot time.
-
kfd_program
-
(str) Path to kfd(8) (default - /usr/libexec/kfd).
-
rwhod_enable
-
(bool) If set to - “YES”, run the - rwhod(8) daemon at boot time.
-
rwhod_flags
-
(str) If rwhod_enable is set - to “YES”, these are the flags to - pass to it.
-
update_motd
-
(bool) If set to - “YES”, - /var/run/motd will be updated at boot time to - reflect the kernel release being run. If set to - “NO”, - /var/run/motd will not be updated.
-
nfs_client_enable
-
(bool) If set to - “YES”, run the NFS client daemons at - boot time.
-
nfs_access_cache
-
(int) If nfs_client_enable is - set to “YES”, this can be set to - “0” to disable NFS ACCESS RPC - caching, or to the number of seconds for which NFS ACCESS results should - be cached. A value of 2-10 seconds will substantially reduce network - traffic for many NFS operations.
-
nfs_server_enable
-
(bool) If set to - “YES”, run the NFS server daemons at - boot time.
-
nfs_server_flags
-
(str) If nfs_server_enable is - set to “YES”, these are the flags to - pass to the nfsd(8) daemon.
-
nfsv4_server_enable
-
(bool) If nfs_server_enable is - set to “YES” and - nfsv4_server_enable is set to - “YES”, enable the server for NFSv4 - as well as NFSv2 and NFSv3.
-
nfsv4_server_only
-
(bool) If nfs_server_enable is - set to “YES” and - nfsv4_server_only is set to - “YES”, enable the NFS server for - NFSv4 only.
-
nfs_server_maxio
-
(int) value to set vfs.nfsd.srvmaxio to, which is - the maximum I/O size for the NFS server.
-
tlsclntd_enable
-
(bool) If set to - “YES”, run the - rpc.tlsclntd(8) daemon, which is needed for NFS-over-TLS - NFS mounts.
-
tlsservd_enable
-
(bool) If set to - “YES”, run the - rpc.tlsservd(8) daemon, which is needed for the - nfsd(8) to support NFS-over-TLS NFS mounts.
-
nfsuserd_enable
-
(bool) If nfsuserd_enable is - set to “YES”, run the nfsuserd - daemon, which is needed for NFSv4 in order to map between user/group names - vs uid/gid numbers. If nfsv4_server_enable is set to - “YES”, this will be forced - enabled.
-
nfsuserd_flags
-
(str) If nfsuserd_enable is - set to “YES”, these are the flags to - pass to the nfsuserd(8) daemon.
-
nfscbd_enable
-
(bool) If nfscbd_enable is set - to “YES”, run the nfscbd daemon, - which enables callbacks/delegations for the NFSv4 client.
-
nfscbd_flags
-
(str) If nfscbd_enable is set - to “YES”, these are the flags to - pass to the nfscbd(8) daemon.
-
mountd_enable
-
(bool) If set to - “YES”, and no - nfs_server_enable is set, start - mountd(8), but not nfsd(8) daemon. It - is commonly needed to run CFS without real NFS used.
-
mountd_flags
-
(str) If mountd_enable is set - to “YES”, these are the flags to - pass to the mountd(8) daemon.
-
weak_mountd_authentication
-
(bool) If set to - “YES”, allow services like PCNFSD to - make non-privileged mount requests.
-
nfs_reserved_port_only
-
(bool) If set to - “YES”, provide NFS services only on - a secure port.
-
nfs_bufpackets
-
(int) If set to a number, indicates the number of - packets worth of socket buffer space to reserve on an NFS client. The - kernel default is typically 4. Using a higher number may be useful on - gigabit networks to improve performance. The minimum value is 2 and the - maximum is 64.
-
rpc_lockd_enable
-
(bool) If set to - “YES” and also an NFS server or - client, run rpc.lockd(8) at boot time.
-
rpc_lockd_flags
-
(str) If rpc_lockd_enable is - set to “YES”, these are the flags to - pass to the rpc.lockd(8) daemon.
-
rpc_statd_enable
-
(bool) If set to - “YES” and also an NFS server or - client, run rpc.statd(8) at boot time.
-
rpc_statd_flags
-
(str) If rpc_statd_enable is - set to “YES”, these are the flags to - pass to the rpc.statd(8) daemon.
-
rpcbind_program
-
(str) Path to rpcbind(8) (default - /usr/sbin/rpcbind).
-
rpcbind_enable
-
(bool) If set to - “YES”, run the - rpcbind(8) service at boot time.
-
rpcbind_flags
-
(str) If rpcbind_enable is set - to “YES”, these are the flags to - pass to the rpcbind(8) daemon.
-
pppoed_enable
-
(bool) If set to - “YES”, run the - pppoed(8) daemon at boot time to provide PPP over - Ethernet services.
-
pppoed_⟨provider⟩
-
(str) pppoed(8) listens to - requests to this provider and ultimately runs - ppp(8) with a system argument of - the same name.
-
pppoed_flags
-
(str) Additional flags to pass to - pppoed(8).
-
pppoed_interface
-
(str) The network interface to run - pppoed(8) on. This is mandatory when - pppoed_enable is set to - “YES”.
-
ntpdate_enable
-
(bool) If set to - “YES”, run - ntpdate(8) at system startup. This command is intended - to synchronize the system clock only - - from some standard reference. -

Note that the use of the - ntpd_sync_on_start variable is a preferred - alternative to the ntpdate(8) utility as - ntpdate(8) is to be retired from the NTP - distribution.

-
-
ntpdate_config
-
(str) Configuration file for - ntpdate(8). Default - /etc/ntp.conf.
-
ntpdate_hosts
-
(str) A whitespace-separated list of NTP servers to - synchronize with at startup. The default is to use the servers listed in - ntpdate_config, if that file exists.
-
ntpdate_program
-
(str) Path to ntpdate(8) (default - /usr/sbin/ntpdate).
-
ntpdate_flags
-
(str) If ntpdate_enable is set - to “YES”, these are the flags to - pass to the ntpdate(8) command (typically a - hostname).
-
ntpd_enable
-
(bool) If set to - “YES”, run the - ntpd(8) command at boot time.
-
ntpd_program
-
(str) Path to ntpd(8) (default - /usr/sbin/ntpd).
-
ntpd_config
-
(str) Path to ntpd(8) - configuration file. Default /etc/ntp.conf.
-
ntpd_flags
-
(str) If ntpd_enable is set to - “YES”, these are the flags to pass - to the ntpd(8) daemon.
-
ntpd_sync_on_start
-
(bool) If set to - “YES”, ntpd(8) is - run with the -g flag, which syncs the system's - clock on startup. See ntpd(8) for more information - regarding the -g option. This is a preferred - alternative to using ntpdate(8) or specifying the - ntpdate_enable variable.
-
nis_client_enable
-
(bool) If set to - “YES”, run the - ypbind(8) service at system boot time.
-
nis_client_flags
-
(str) If nis_client_enable is - set to “YES”, these are the flags to - pass to the ypbind(8) service.
-
nis_ypldap_enable
-
(bool) If set to - “YES”, run the - ypldap(8) daemon at system boot time.
-
nis_ypldap_flags
-
(str) If nis.ypldap_enable is - set to “YES”, these are the flags to - pass to the ypldap(8) daemon.
-
nis_ypset_enable
-
(bool) If set to - “YES”, run the - ypset(8) daemon at system boot time.
-
nis_ypset_flags
-
(str) If nis_ypset_enable is - set to “YES”, these are the flags to - pass to the ypset(8) daemon.
-
nis_server_enable
-
(bool) If set to - “YES”, run the - ypserv(8) daemon at system boot time.
-
nis_server_flags
-
(str) If nis_server_enable is - set to “YES”, these are the flags to - pass to the ypserv(8) daemon.
-
nis_ypxfrd_enable
-
(bool) If set to - “YES”, run the - rpc.ypxfrd(8) daemon at system boot time.
-
nis_ypxfrd_flags
-
(str) If nis_ypxfrd_enable is - set to “YES”, these are the flags to - pass to the rpc.ypxfrd(8) daemon.
-
nis_yppasswdd_enable
-
(bool) If set to - “YES”, run the - rpc.yppasswdd(8) daemon at system boot time.
-
nis_yppasswdd_flags
-
(str) If nis_yppasswdd_enable - is set to “YES”, these are the flags - to pass to the rpc.yppasswdd(8) daemon.
-
rpc_ypupdated_enable
-
(bool) If set to - “YES”, run the - rpc.ypupdated daemon at system boot time.
-
bsnmpd_enable
-
(bool) If set to - “YES”, run the - bsnmpd(1) daemon at system boot time. Be sure to - understand the security implications of running an SNMP daemon on your - host.
-
bsnmpd_flags
-
(str) If bsnmpd_enable is set - to “YES”, these are the flags to - pass to the bsnmpd(1) daemon.
-
defaultrouter
-
(str) If not set to - “NO”, create a default route to this - host name or IP address (use an IP address if this router is also required - to get to the name server!).
-
defaultrouter_fibN
-
(str) If not set to - “NO”, create a default route in FIB - N to this host name or IP address.
-
ipv6_defaultrouter
-
(str) The IPv6 equivalent of - defaultrouter.
-
ipv6_defaultrouter_fibN
-
(str) The IPv6 equivalent of - defaultrouter_fibN.
-
static_arp_pairs
-
(str) Set to the list of static ARP pairs that are - to be added at system boot time. For each whitespace separated - element in the value, a - static_arp_⟨element⟩ - variable is assumed to exist whose contents will later be passed to a - “arp -S” - operation. For example -
- 
static_arp_pairs="gw"
-static_arp_gw="192.168.1.1 00:01:02:03:04:05"
-
-
-
static_ndp_pairs
-
(str) Set to the list of static NDP pairs that are - to be added at system boot time. For each whitespace separated - element in the value, a - static_ndp_⟨element⟩ - variable is assumed to exist whose contents will later be passed to a - “ndp -s” - operation. For example -
- 
static_ndp_pairs="gw"
-static_ndp_gw="2001:db8:3::1 00:01:02:03:04:05"
-
-
-
static_routes
-
(str) Set to the list of static routes that are to - be added at system boot time. If not set to - “NO” then for each whitespace - separated element in the value, a - route_⟨element⟩ - variable is assumed to exist whose contents will later be passed to a - “route add” - operation. For example: -
- 
static_routes="ext mcast:gif0 gif0local:gif0"
-route_ext="-net 10.0.0.0/24 -gateway 192.168.0.1"
-route_mcast="-net 224.0.0.0/4 -iface gif0"
-route_gif0local="-host 169.254.1.1 -iface lo0"
-
-

When an element is in the form of - name:ifname, the route is specific to the - interface ifname.

-
-
ipv6_static_routes
-
(str) The IPv6 equivalent of - static_routes. If not set to - “NO” then for each whitespace - separated element in the value, a - ipv6_route_⟨element⟩ - variable is assumed to exist whose contents will later be passed to a - “route add - -inet6” operation.
-
gateway_enable
-
(bool) If set to - “YES”, configure host to act as an - IP router, e.g. to forward packets between interfaces.
-
ipv6_gateway_enable
-
(bool) The IPv6 equivalent of - gateway_enable.
-
routed_enable
-
(bool) If set to - “YES”, run a routing daemon of some - sort, based on the settings of routed_program and - routed_flags.
-
route6d_enable
-
(bool) The IPv6 equivalent of - routed_enable. If set to - “YES”, run a routing daemon of some - sort, based on the settings of route6d_program and - route6d_flags.
-
routed_program
-
(str) If routed_enable is set - to “YES”, this is the name of the - routing daemon to use. The default is routed(8).
-
route6d_program
-
(str) The IPv6 equivalent of - routed_program. The default is - route6d(8).
-
routed_flags
-
(str) If routed_enable is set - to “YES”, these are the flags to - pass to the routing daemon.
-
route6d_flags
-
(str) The IPv6 equivalent of - routed_flags.
-
rtadvd_enable
-
(bool) If set to - “YES”, run the - rtadvd(8) daemon at boot time. The - rtadvd(8) utility sends ICMPv6 Router Advertisement - messages to the interfaces specified in - rtadvd_interfaces. This should only be enabled with - great care. You may want to fine-tune - rtadvd.conf(5).
-
rtadvd_flags
-
(str) If rtadvd_enable is set - to “YES”, these are the flags to - pass to rtadvd(8).
-
rtadvd_interfaces
-
(str) If rtadvd_enable is set - to “YES” this is the list of - interfaces to use.
-
arpproxy_all
-
(bool) If set to - “YES”, enable global proxy ARP.
-
forward_sourceroute
-
(bool) If set to - “YES” and - gateway_enable is also set to - “YES”, source-routed packets are - forwarded.
-
accept_sourceroute
-
(bool) If set to - “YES”, the system will accept - source-routed packets directed at it.
-
rarpd_enable
-
(bool) If set to - “YES”, run the - rarpd(8) daemon at system boot time.
-
rarpd_flags
-
(str) If rarpd_enable is set - to “YES”, these are the flags to - pass to the rarpd(8) daemon.
-
bootparamd_enable
-
(bool) If set to - “YES”, run the - bootparamd(8) daemon at system boot time.
-
bootparamd_flags
-
(str) If bootparamd_enable is - set to “YES”, these are the flags to - pass to the bootparamd(8) daemon.
-
stf_interface_ipv4addr
-
(str) If not set to - “NO”, this is the local IPv4 address - for 6to4 (IPv6 over IPv4 tunneling interface). Specify this entry to - enable the 6to4 interface.
-
stf_interface_ipv4plen
-
(int) Prefix length for 6to4 IPv4 addresses, to - limit peer address range. An effective value is 0-31.
-
stf_interface_ipv6_ifid
-
(str) IPv6 interface ID for - stf(4). This can be set to - “AUTO”.
-
stf_interface_ipv6_slaid
-
(str) IPv6 Site Level Aggregator for - stf(4).
-
ipv6_ipv4mapping
-
(bool) If set to - “YES” this enables IPv4 mapped IPv6 - address communication (like ::ffff:a.b.c.d).
-
rtsold_enable
-
(bool) Set to - “YES” to enable the - rtsold(8) daemon to send ICMPv6 Router Solicitation - messages.
-
rtsold_flags
-
(str) If rtsold_enable is set - to “YES”, these are the flags to - pass to rtsold(8).
-
rtsol_flags
-
(str) For interfaces configured with the - “inet6 accept_rtadv” keyword, these - are the flags to pass to rtsol(8). -

Note that rtsold_enable is mutually - exclusive to rtsol_flags; - rtsold_enable takes precedence.

-
-
keybell
-
(str) The keyboard bell sound. Set to - “normal”, - “visual”, - “off”, or - “NO” if the default behavior is - desired. For details, refer to the kbdcontrol(1) - manpage.
-
keyboard
-
(str) If set to a non-null string, the virtual - console's keyboard input is set to this device.
-
keymap
-
(str) If set to - “NO”, no keymap is installed, - otherwise the value is used to install the keymap file found in - /usr/share/syscons/keymaps/⟨value⟩.kbd - (if using syscons(4)) or - /usr/share/vt/keymaps/⟨value⟩.kbd - (if using vt(4)).
-
keyrate
-
(str) The keyboard repeat speed. Set to - “slow”, - “normal”, - “fast”, or - “NO” if the default behavior is - desired.
-
keychange
-
(str) If not set to - “NO”, attempt to program the - function keys with the value. The value should be a single string of the - form: “funkey_number new_value - [funkey_number new_value ...]”.
-
cursor
-
(str) Can be set to the value of - “normal”, - “blink”, - “destructive”, or - “NO” to set the cursor behavior - explicitly or choose the default behavior.
-
scrnmap
-
(str) If set to - “NO”, no screen map is installed, - otherwise the value is used to install the screen map file in - /usr/share/syscons/scrnmaps/⟨value⟩. - This parameter is ignored when using vt(4) as the - console driver.
-
font8x16
-
(str) If set to - “NO”, the default 8x16 font value is - used for screen size requests, otherwise the value in - /usr/share/syscons/fonts/⟨value⟩ - or - /usr/share/vt/fonts/⟨value⟩ - is used (depending on the console driver being used).
-
font8x14
-
(str) If set to - “NO”, the default 8x14 font value is - used for screen size requests, otherwise the value in - /usr/share/syscons/fonts/⟨value⟩ - or - /usr/share/vt/fonts/⟨value⟩ - is used (depending on the console driver being used).
-
font8x8
-
(str) If set to - “NO”, the default 8x8 font value is - used for screen size requests, otherwise the value in - /usr/share/syscons/fonts/⟨value⟩ - or - /usr/share/vt/fonts/⟨value⟩ - is used (depending on the console driver being used).
-
blanktime
-
(int) If set to - “NO”, the default screen blanking - interval is used, otherwise it is set to value - seconds.
-
saver
-
(str) If not set to - “NO”, this is the actual screen - saver to use (blank, - snake, daemon, etc).
-
moused_nondefault_enable
-
(str) If set to - “NO”, the mouse device specified on - the command line is not automatically treated as enabled by the - /etc/rc.d/moused script. Having this variable set - to “YES” allows a - usb(4) mouse, for example, to be enabled as soon as it - is plugged in.
-
moused_enable
-
(str) If set to - “YES”, the - moused(8) daemon is started for doing cut/paste - selection on the console.
-
moused_type
-
(str) This is the protocol type of the mouse - connected to this host. This variable must be set if - moused_enable is set to - “YES”, but defaults to - “auto” as the - moused(8) daemon is able to detect the appropriate mouse - type automatically in many cases. Set this variable to one from the - following list if the automatic detection fails. -

If the mouse is attached to the PS/2 mouse port, choose - “auto” or - “ps/2”, regardless of the brand - and model of the mouse. Likewise, if the mouse is attached to the bus - mouse port, choose “auto” or - “busmouse”. All other protocols - are for serial mice and will not work with the PS/2 and bus mice. If - this is a USB mouse, “auto” is the - only protocol type which will work.

-

-
-
-
Microsoft mouse (serial)
-
-
Microsoft IntelliMouse (serial)
-
-
Mouse systems Corp. mouse (serial)
-
-
MM Series mouse (serial)
-
-
Logitech mouse (serial)
-
-
A bus mouse
-
-
Logitech MouseMan and TrackMan (serial)
-
-
ALPS GlidePoint (serial)
-
-
Kensington ThinkingMouse (serial)
-
-
PS/2 mouse
-
-
MM HitTablet (serial)
-
-
X10 MouseRemote (serial)
-
-
Interlink VersaPad (serial)
-
-

Even if the mouse is not in the above list, it may be - compatible with one in the list. Refer to the manual page for - moused(8) for compatibility information.

-

It should also be noted that while this is enabled, any other - client of the mouse (such as an X server) should access the mouse - through the virtual mouse device, /dev/sysmouse, - and configure it as a “sysmouse” - type mouse, since all mouse data is converted to this single canonical - format when using moused(8). If the client program - does not support the “sysmouse” - type, specify the “mousesystems” - type. It is the second preferred type.

-
-
moused_port
-
(str) If moused_enable is set - to “YES”, this is the actual port - the mouse is on. It might be /dev/cuau0 for a COM1 - serial mouse, or /dev/psm0 for a PS/2 mouse, for - example.
-
moused_flags
-
(str) If moused_flags is set, - its value is used as an additional set of flags to pass to the - moused(8) daemon.
-
moused_XXX_flags
-
When moused_nondefault_enable is enabled, and a - moused(8) daemon is started for a non-default port, the - moused_XXX_flags - set of options has precedence over and replaces the default - moused_flags (where XXX is the - name of the non-default port, i.e., ums0). By - setting - moused_XXX_flags - it is possible to set up a different set of default flags for each - moused(8) instance. For example, you can use - “-3” for the default - moused_flags to make your laptop's touchpad more - comfortable to use, but an empty set of options for - moused_ums0_flags when your usb(4) - mouse has three or more buttons.
-
mousechar_start
-
(int) If set to - “NO”, the default mouse cursor - character range 0xd0-0xd3 - is used, otherwise the range start is set to value - character, see vidcontrol(1). Use if the default range - is occupied in the language code table.
-
allscreens_flags
-
(str) If set, vidcontrol(1) is run - with these options for each of the virtual terminals - (/dev/ttyv*). For example, - “-m on” will - enable the mouse pointer on all virtual terminals if - moused_enable is set to - “YES”.
-
allscreens_kbdflags
-
(str) If set, kbdcontrol(1) is run - with these options for each of the virtual terminals - (/dev/ttyv*). For example, - “-h 200” - will set the syscons(4) or vt(4) - scrollback (history) buffer to 200 lines.
-
cron_enable
-
(bool) If set to - “YES”, run the - cron(8) daemon at system boot time.
-
cron_program
-
(str) Path to cron(8) (default - /usr/sbin/cron).
-
cron_flags
-
(str) If cron_enable is set to - “YES”, these are the flags to pass - to cron(8).
-
cron_dst
-
(bool) If set to - “YES”, enable the special handling - of transitions to and from the Daylight Saving Time in - cron(8) (equivalent to using the flag - -s).
-
lpd_program
-
(str) Path to lpd(8) (default - /usr/sbin/lpd).
-
lpd_enable
-
(bool) If set to - “YES”, run the - lpd(8) daemon at system boot time.
-
lpd_flags
-
(str) If lpd_enable is set to - “YES”, these are the flags to pass - to the lpd(8) daemon.
-
chkprintcap_enable
-
(bool) If set to - “YES”, run the - chkprintcap(8) command before starting the - lpd(8) daemon.
-
chkprintcap_flags
-
(str) If lpd_enable and - chkprintcap_enable are set to - “YES”, these are the flags to pass - to the chkprintcap(8) program. The default is - “-d”, which causes missing - directories to be created.
-
dumpdev
-
(str) Indicates the device (usually a swap - partition) to which a crash dump should be written in the event of a - system crash. If the value of this variable is - “AUTO”, the first suitable swap - device listed in /etc/fstab will be used as dump - device. Otherwise, the value of this variable is passed as the argument to - dumpon(8) and savecore(8). To disable - crash dumps, set this variable to - “NO”.
-
dumpon_flags
-
(str) Flags to pass to dumpon(8) - when configuring dumpdev as the system dump - device.
-
dumpdir
-
(str) When the system reboots after a crash and a - crash dump is found on the device specified by the - dumpdev variable, savecore(8) will - save that crash dump and a copy of the kernel to the directory specified - by the dumpdir variable. The default value is - /var/crash. Set to - “NO” to not run - savecore(8) at boot time when - dumpdir is set.
-
savecore_enable
-
(bool) If set to - “NO”, disable automatic extraction - of the crash dump from the dumpdev.
-
savecore_flags
-
(str) If crash dumps are enabled, these are the - flags to pass to the savecore(8) utility.
-
quota_enable
-
(bool) Set to - “YES” to turn on user and group disk - quotas on system startup via the quotaon(8) command for - all file systems marked as having quotas enabled in - /etc/fstab. The kernel must be built with - options QUOTA for disk quotas to function.
-
check_quotas
-
(bool) Set to - “YES” to enable user and group disk - quota checking via the quotacheck(8) command.
-
quotacheck_flags
-
(str) If quota_enable is set - to “YES”, and - check_quotas is set to - “YES”, these are the flags to pass - to the quotacheck(8) utility. The default is - “-a”, which checks quotas for all - file systems with quotas enabled in - /etc/fstab.
-
quotaon_flags
-
(str) If quota_enable is set - to “YES”, these are the flags to - pass to the quotaon(8) utility. The default is - “-a”, which enables quotas for all - file systems with quotas enabled in - /etc/fstab.
-
quotaoff_flags
-
(str) If quota_enable is set - to “YES”, these are the flags to - pass to the quotaoff(8) utility when shutting down the - quota system. The default is “-a”, - which disables quotas for all file systems with quotas enabled in - /etc/fstab.
-
accounting_enable
-
(bool) Set to - “YES” to enable system accounting - through the accton(8) facility.
-
firstboot_sentinel
-
(str) This variable specifies the full path to a - “first boot” sentinel file. If a file exists with this path, - rc.d scripts with the “firstboot” - keyword will be run on startup and the sentinel file will be deleted after - the boot process completes. The sentinel file must be located on a - writable file system which is mounted no later than - early_late_divider to function properly. The default - is /firstboot.
-
linux_enable
-
(bool) Set to - “YES” to enable Linux/ELF binary - emulation at system initial boot time.
-
sysvipc_enable
-
(bool) If set to - “YES”, load System V IPC primitives - at boot time.
-
clear_tmp_enable
-
(bool) Set to - “YES” to have - /tmp cleaned at startup.
-
clear_tmp_X
-
(bool) Set to - “NO” to disable removing of X11 lock - files, and the removal and (secure) recreation of the various socket - directories for X11 related programs.
-
ldconfig_paths
-
(str) Set to the list of shared library paths to use - with ldconfig(8). NOTE: /lib and - /usr/lib will always be added first, so they need - not appear in this list.
-
ldconfig32_paths
-
(str) Set to the list of 32-bit compatibility shared - library paths to use with ldconfig(8).
-
ldconfig_insecure
-
(bool) The ldconfig(8) utility - normally refuses to use directories which are writable by anyone except - root. Set this variable to “YES” to - disable that security check during system startup.
-
ldconfig_local_dirs
-
(str) Set to the list of local - ldconfig(8) directories. The names of all files in the - directories listed will be passed as arguments to - ldconfig(8).
-
ldconfig_local32_dirs
-
(str) Set to the list of local 32-bit compatibility - ldconfig(8) directories. The names of all files in the - directories listed will be passed as arguments to - “ldconfig - -32”.
-
kern_securelevel_enable
-
(bool) Set to - “YES” to set the kernel security - level at system startup.
-
kern_securelevel
-
(int) The kernel security level to set at startup. - The allowed range of value ranges from -1 (the - compile time default) to 3 (the most secure). See - security(7) for the list of possible security levels and - their effect on system operation.
-
sshd_program
-
(str) Path to the SSH server program - (/usr/sbin/sshd is the default).
-
sshd_enable
-
(bool) Set to - “YES” to start - sshd(8) at system boot time. Note, the - sshd_oomprotect variable is set to - “YES” by default in - /etc/defaults/rc.conf.
-
sshd_flags
-
(str) If sshd_enable is set to - “YES”, these are the flags to pass - to the sshd(8) daemon.
-
watchdogd_enable
-
(bool) If set to - “YES”, start the - watchdogd(8) daemon at boot time. This requires that the - kernel have been compiled with a watchdog(4) compatible - device.
-
watchdogd_flags
-
(str) If watchdogd_enable is - set to “YES”, these are the flags - passed to the watchdogd(8) daemon.
-
watchdogd_timeout
-
(int) If watchdogd_enable is - set to “YES”, this is a timeout that - will be used by the watchdogd(8) daemon. If this option - is set, it overrides -t in - watchdogd_flags.
-
watchdogd_shutdown_timeout
-
(int) If watchdogd_enable is - set to “YES”, this is a timeout that - will be set by the watchdogd(8) daemon when it exits - during the system shutdown. This timeout will not be set when returning to - the single-user mode or when the watchdogd service is stopped individually - using the service(8) command or the rc.d script. Note - that the timeout will be applied if watchdogd(8) is - stopped outside of rc(8) framework. If this option is - set, it overrides -x in - watchdogd_flags.
-
devfs_rulesets
-
(str) List of files containing sets of rules for - devfs(8).
-
devfs_system_ruleset
-
(str) Rule name(s) to apply to the system - /dev itself.
-
devfs_set_rulesets
-
(str) Pairs of already-mounted - dev directories and rulesets that should be - applied to them. For example: /mount/dev=ruleset_name
-
devfs_load_rulesets
-
(bool) If set, always load the default rulesets - listed in devfs_rulesets.
-
performance_cx_lowest
-
(str) CPU idle state to use while on AC power. The - string “LOW” indicates that - acpi(4) should use the lowest power state available - while “HIGH” indicates that the - lowest latency state (less power savings) should be used.
-
performance_cpu_freq
-
(str) CPU clock frequency to use while on AC power. - The string “LOW” indicates that - cpufreq(4) should use the lowest frequency available - while “HIGH” indicates that the - highest frequency (less power savings) should be used.
-
economy_cx_lowest
-
(str) CPU idle state to use when off AC power. The - string “LOW” indicates that - acpi(4) should use the lowest power state available - while “HIGH” indicates that the - lowest latency state (less power savings) should be used.
-
economy_cpu_freq
-
(str) CPU clock frequency to use when off AC power. - The string “LOW” indicates that - cpufreq(4) should use the lowest frequency available - while “HIGH” indicates that the - highest frequency (less power savings) should be used.
-
jail_enable
-
(bool) If set to - “NO”, any configured jails will not - be started.
-
jail_conf
-
(str) The configuration filename used by - jail(8) utility. The default value is - /etc/jail.conf. - /etc/jail.⟨jname⟩.conf - and - /etc/jail.conf.d/⟨jname⟩.conf - will also be used if ⟨jname⟩ is set in - jail_list.
-
jail_parallel_start
-
(bool) If set to - “YES”, all configured jails will be - started in the background (in parallel).
-
jail_flags
-
(str) Unset by default. When set, use as default - value for - jail_⟨jname⟩_flags - for every jail in jail_list.
-
jail_list
-
(str) A space-delimited list of jail names. When - left empty, all of the jail(8) instances defined in the - configuration file are started. The names specified in this list control - the jail startup order. jail(8) instances missing from - jail_list must be started manually. Note that a - jail's depend parameter in the configuration file - may override this list.
-
jail_reverse_stop
-
(bool) When set to - “YES”, all configured jails in - jail_list are stopped in reverse order.
-
jail_* variables
-
Note that older releases supported per-jail configuration via - rc.conf variables. For example, hostname of a jail - named vjail was able to be set by - jail_vjail_hostname. These per-jail configuration - variables are now obsolete in favor of jail(8) - configuration file. For backward compatibility, when per-jail - configuration variables are defined, jail(8) - configuration files are created as - /var/run/jail.⟨jname⟩.conf - and used. -

The following per-jail parameters are handled by - rc.d/jail script out of their corresponding - rc.conf variables. In addition to them, - parameters in - jail_⟨jname⟩_parameters - will be added to the configuration file. They must be a semi-colon - (‘;’) delimited list of - “key=value”. For more details, see - jail(8) manual page.

-
-
-
-
set from - jail_⟨jname⟩_rootdir
-
-
set from - jail_⟨jname⟩_hostname
-
-
set from - jail_⟨jname⟩_consolelog. - The default value is - /var/log/jail_⟨jname⟩_console.log.
-
-
set from - jail_⟨jname⟩_interface.
-
-
set from - jail_⟨jname⟩_vnet_interface. - This implies vnet parameter will be enabled - and cannot be specified with - jail_⟨jname⟩_interface, - jail_⟨jname⟩_ip - and/or - jail_⟨jname⟩_ip_multi⟨n⟩ - at the same time.
-
-
set from - jail_⟨jname⟩_fstab
-
-
set from - jail_⟨jname⟩_procfs_enable.
-
-
set from - jail_⟨jname⟩_fib
-
-
set from - jail_⟨jname⟩_exec_start. - The parameter name was command in some older - releases.
-
-
set from - jail_⟨jname⟩_exec_prestart
-
-
set from - jail_⟨jname⟩_exec_poststart
-
-
set from - jail_⟨jname⟩_exec_stop
-
-
set from - jail_⟨jname⟩_exec_prestop
-
-
set from - jail_⟨jname⟩_exec_poststop
-
-
set if - jail_⟨jname⟩_ip - or - jail_⟨jname⟩_ip_multi⟨n⟩ - contain IPv4 addresses
-
-
set if - jail_⟨jname⟩_ip - or - jail_⟨jname⟩_ip_multi⟨n⟩ - contain IPv6 addresses
-
-
set from - jail_⟨jname⟩_mount_enable
-
-
set from - jail_⟨jname⟩_devfs_enable
-
-
set from - jail_⟨jname⟩_devfs_ruleset. - This must be an integer, not a string.
-
-
set from - jail_⟨jname⟩_fdescfs_enable
-
-
set from - jail_⟨jname⟩_set_hostname_allow
-
-
set from - jail_⟨jname⟩_socket_unixiproute_only
-
-
set from - jail_⟨jname⟩_sysvipc_allow
-
-
-
-
harvest_mask
-
(int) Set to a bit-mask representing the entropy - sources you wish to harvest. Refer to random(4) for more - information.
-
entropy_dir
-
(str) Set to - “NO” to disable caching entropy via - cron(8). Otherwise set to the directory in which the - entropy files are stored. To be useful, there must be a system cron job - that regularly writes and rotates files here. All files found will be used - at boot time. The default is /var/db/entropy.
-
entropy_file
-
(str) Set to - “NO” to disable caching entropy - through reboots. Otherwise set to the name of a file used to store cached - entropy. This file should be located on a file system that is readable - before all the volumes specified in fstab(5) are - mounted. By default, /entropy is used, but if - /var/db/entropy-file is found it will also be - used. This will be of some use to bsdinstall(8).
-
entropy_boot_file
-
(str) Set to - “NO” to disable very early caching - entropy through reboots. Otherwise set to the filename used to read very - early reboot cached entropy. This file should be located where - loader(8) can read it. See also - loader.conf(5). The default location is - /boot/entropy.
-
entropy_save_sz
-
(int) Size of the entropy cache files saved by - save-entropy periodically.
-
entropy_save_num
-
(int) Number of entropy cache files to save by - save-entropy periodically.
-
ipsec_enable
-
(bool) Set to - “YES” to run - setkey(8) on ipsec_file at boot - time.
-
ipsec_file
-
(str) Configuration file for - setkey(8).
-
dmesg_enable
-
(bool) Set to - “YES” to save - dmesg(8) to /var/run/dmesg.boot - on boot.
-
rcshutdown_timeout
-
(int) If set, start a watchdog timer in the - background which will terminate rc.shutdown if - shutdown(8) has not completed within the specified time - (in seconds). Notice that in addition to this soft timeout, - init(8) also applies a hard timeout for the execution of - rc.shutdown. This is configured via - sysctl(8) variable - kern.init_shutdown_timeout and defaults to 120 - seconds. Setting the value of rcshutdown_timeout to - more than 120 seconds will have no effect until the - sysctl(8) variable - kern.init_shutdown_timeout is also increased.
-
virecover_enable
-
(bool) Set to - “NO” to prevent the system from - trying to recover prematurely terminated vi(1) - sessions.
-
ugidfw_enable
-
(bool) Set to - “YES” to load the - mac_bsdextended(4) module upon system initialization and - load a default ruleset file.
-
bsdextended_script
-
(str) The default - mac_bsdextended(4) ruleset file to load. The default - value of this variable is - /etc/rc.bsdextended.
-
newsyslog_enable
-
(bool) If set to - “YES”, run - newsyslog(8) command at startup.
-
newsyslog_flags
-
(str) If newsyslog_enable is - set to “YES”, these are the flags to - pass to the newsyslog(8) program. The default is - “-CN”, which causes log files - flagged with a C to be created.
-
mdconfig_md⟨X⟩
-
(str) Arguments to mdconfig(8) for - md(4) device X. At minimum a - -t type must be specified - and either a -s size for - malloc or swap backed md(4) devices or a - -f file for vnode backed - md(4) devices. Note that - mdconfig_md⟨X⟩ - variables are evaluated until one variable is unset or null.
-
mdconfig_md⟨X⟩_newfs
-
(str) Optional arguments passed to - newfs(8) to initialize md(4) device - X.
-
mdconfig_md⟨X⟩_owner
-
(str) An ownership specification passed to - chown(8) after the specified md(4) - device X has been mounted. Both the - md(4) device and the mount point will be changed.
-
mdconfig_md⟨X⟩_perms
-
(str) A mode string passed to - chmod(1) after the specified md(4) - device X has been mounted. Both the - md(4) device and the mount point will be changed.
-
mdconfig_md⟨X⟩_files
-
(str) Files to be copied to the mount point of the - md(4) device X after it has been - mounted.
-
mdconfig_md⟨X⟩_cmd
-
(str) Command to execute after the specified - md(4) device X has been mounted. - Note that the command is passed to eval and that - both _dev and _mp variables - can be used to reference respectively the md(4) device - and the mount point. Assuming that the md(4) device is - md0, one could set the following: -
- 
mdconfig_md0_cmd="tar xfzC /var/file.tgz \${_mp}"
-
-
-
autobridge_interfaces
-
(str) Set to the list of bridge interfaces that will - have newly arriving interfaces checked against to be automatically added. - If not set to “NO” then for each - whitespace separated element in the value, a - autobridge_⟨element⟩ - variable is assumed to exist which has a whitespace separated list of - interface names to match, these names can use wildcards. For example: -
- 
autobridge_interfaces="bridge0"
-autobridge_bridge0="tap* dc0 vlan[345]"
-
-
-
mixer_enable
-
(bool) If set to - “YES”, enable support for sound - mixer.
-
hcsecd_enable
-
(bool) If set to - “YES”, enable Bluetooth security - daemon.
-
hcsecd_config
-
(str) Configuration file for - hcsecd(8). Default - /etc/bluetooth/hcsecd.conf.
-
sdpd_enable
-
(bool) If set to - “YES”, enable Bluetooth Service - Discovery Protocol daemon.
-
sdpd_control
-
(str) Path to sdpd(8) control - socket. Default /var/run/sdp.
-
sdpd_groupname
-
(str) Sets sdpd(8) group to run as - after it initializes. Default - “nobody”.
-
sdpd_username
-
(str) Sets sdpd(8) user to run as - after it initializes. Default - “nobody”.
-
bthidd_enable
-
(bool) If set to - “YES”, enable Bluetooth Human - Interface Device daemon.
-
bthidd_config
-
(str) Configuration file for - bthidd(8). Default - /etc/bluetooth/bthidd.conf.
-
bthidd_hids
-
(str) Path to a file, where - bthidd(8) will store information about known HID - devices. Default /var/db/bthidd.hids.
-
rfcomm_pppd_server_enable
-
(bool) If set to - “YES”, enable Bluetooth RFCOMM PPP - wrapper daemon.
-
rfcomm_pppd_server_profile
-
(str) The name of the profile to use from - /etc/ppp/ppp.conf. Multiple profiles can be - specified here. Also used to specify per-profile overrides. When the - profile name contains any of the characters - “.-/+” they are translated to - “_” for the proposes of the override - variable names.
-
rfcomm_pppd_server_⟨profile⟩_bdaddr
-
(str) Overrides local address to listen on. By - default rfcomm_pppd(8) will listen on - “ANY” address. The address can be - specified as BD_ADDR or name.
-
rfcomm_pppd_server_⟨profile⟩_channel
-
(str) Overrides local RFCOMM channel to listen on. - By default rfcomm_pppd(8) will listen on RFCOMM channel - 1. Must set properly if multiple profiles used in the same time.
-
rfcomm_pppd_server_⟨profile⟩_register_sp
-
(bool) Tells rfcomm_pppd(8) if it - should register Serial Port service on the specified RFCOMM channel. - Default “NO”.
-
rfcomm_pppd_server_⟨profile⟩_register_dun
-
(bool) Tells rfcomm_pppd(8) if it - should register Dial-Up Networking service on the specified RFCOMM - channel. Default “NO”.
-
ubthidhci_enable
-
(bool) If set to - “YES”, change the USB Bluetooth - controller from HID mode to HCI mode. You also need to specify the - location of USB Bluetooth controller with the - ubthidhci_busnum and - ubthidhci_addr variables.
-
ubthidhci_busnum
-
Bus number where the USB Bluetooth controller is located. Check the output - of usbconfig(8) on your system to find this - information.
-
ubthidhci_addr
-
Bus address of the USB Bluetooth controller. Check the output of - usbconfig(8) on your system to find this - information.
-
utx_enable
-
(bool) Set to - “YES” to enable user accounting - through the utx(8) facility.
-
netwait_enable
-
(bool) If set to - “YES”, delays the start of - network-reliant services until netwait_if is up, - duplicate address discovery (DAD) has completed, and ICMP packets to a - destination defined in netwait_ip are flowing. Link - state is examined first, followed by DAD, then - “pinging” an IP address to verify - network usability. If no destination can be reached or timeouts are - exceeded, network services are started anyway with no guarantee that the - network is usable.
-
netwait_ip
-
(str) Empty by default. This variable contains a - space-delimited list of IP addresses to ping(8). DNS - hostnames should not be used as resolution is not guaranteed to be - functional at this point. If multiple IP addresses are specified, each - will be tried until one is successful or the list is exhausted.
-
netwait_timeout
-
(int) Indicates the total number of seconds to - perform a “ping” against each IP - address in netwait_ip, at a rate of one ping per - second. If any of the pings are successful, full network connectivity is - considered reliable. The default is 60.
-
netwait_if
-
(str) Empty by default. Defines the name of the - network interface on which watch for link. ifconfig(8) - is used to monitor the interface, looking for - “status: no carrier”. Once gone, the - link is considered up. This can be a vlan(4) interface - if desired.
-
netwait_if_timeout
-
(int) Defines the total number of seconds to wait - for link to become usable, polled at a 1-second interval. The default is - 30.
-
netwait_dad
-
(str) Set to - “NO” by default. Set to - “YES” to enable waiting for DAD to - complete.
-
netwait_dad_timeout
-
(int) Unset by default. Indicates the maximum number - of seconds to wait for DAD to complete. If zero or unset, the timeout will - be one more than the value of the - net.inet6.ip6.dad_count sysctl variable.
-
rctl_enable
-
(bool) If set to - “YES”, load - rctl(8) rules from the defined ruleset. The kernel must - be built with options RACCT and - options RCTL.
-
rctl_rules
-
(str) Set to /etc/rctl.conf - by default. This variables contains the rctl.conf(5) - ruleset to load for rctl(8).
-
iovctl_files
-
(str) A space-separated list of configuration files - used by iovctl(8). The default value is an empty - string.
-
autofs_enable
-
(bool) If set to - “YES”, start the - automount(8) utility and the - automountd(8) and autounmountd(8) - daemons at boot time.
-
automount_flags
-
(str) If autofs_enable is set - to “YES”, these are the flags to - pass to the automount(8) program. By default no flags - are passed.
-
automountd_flags
-
(str) If autofs_enable is set - to “YES”, these are the flags to - pass to the automountd(8) daemon. By default no flags - are passed.
-
autounmountd_flags
-
(str) If autofs_enable is set - to “YES”, these are the flags to - pass to the autounmountd(8) daemon. By default no flags - are passed.
-
ctld_enable
-
(bool) If set to - “YES”, start the - ctld(8) daemon at boot time.
-
iscsid_enable
-
(bool) If set to - “YES”, start the - iscsid(8) daemon at boot time.
-
iscsictl_enable
-
(bool) If set to - “YES”, start the - iscsictl(8) utility at boot time.
-
iscsictl_flags
-
(str) If iscsictl_enable is - set to “YES”, these are the flags to - pass to the iscsictl(8) program. The default is - “-Aa”, which configures sessions - based on the /etc/iscsi.conf configuration - file.
-
cfumass_enable
-
(bool) If set to - “YES”, create and export an USB LUN - using cfumass(4) at boot time.
-
cfumass_dir
-
(str) The directory where the files exported by USB - LUN are located. The default directory is - /var/cfumass.
-
service_delete_empty
-
(bool) If set to - “YES”, - ‘service - delete’ removes empty - “rc.conf.d” files.
-
zfs_bootonce_activate
-
(bool) If set to - “YES”, and a boot environment marked - bootonce is successfully booted, it will be made permanently active.
-
zfskeys_enable
-
(bool) If set to - “YES”, enable auto-loading of - encryption keys for encrypted ZFS datasets. For every dataset the script - will first load the appropriate encryption key and then attempt to unlock - the dataset. -

The script operates only on datasets which are encrypted with - ZFS native encryption and have a ZFS - “keylocation” dataset property - beginning with “file://”.

-
-
zfskeys_datasets
-
(str) A whitespace-separated list of ZFS datasets to - unlock. The list is empty by default, which means that the script will - attempt to unlock all datasets.
-
zfskeys_timeout
-
(int) Define the total number of seconds to wait for - the zfskeys script to unlock an encrypted dataset. The default is 10.
-
sendmail_enable
-
(str) If set to - “YES”, run the - sendmail(8) daemon at system boot time. If set to - “NO”, do not run a - sendmail(8) daemon to listen for incoming network mail. - This does not preclude a sendmail(8) daemon listening on - the SMTP port of the loopback interface. The - “NONE” option sets each - sendmail_enable, - sendmail_submit_enable, - sendmail_outbound_enable, - sendmail_msp_queue_enable to - “NO”.
-
sendmail_cert_create
-
(str) If sendmail_enable is - set to “YES”, create a signed - certificate /etc/mail/certs/host.cert representing - /etc/mail/certs/host.key by the CA certificate in - /etc/mail/certs/cacert.pem. This will enable - connecting hosts to negotiate STARTTLS allowing incoming email to be - encrypted in transit. sendmail(8) needs to be configured - to use these generated files. The default configuration in - /etc/mail/freebsd.mc has the required options in - it.
-
sendmail_cert_cn
-
(str) If sendmail_enable is - set to “YES” and - sendmail_cert_create is set to - “YES”, this is the Common Name (CN) - of the certificate that will be created. If - sendmail_cert_cn is not set, the system's hostname - will be used. If there is no hostname set, - “amnesiac” will be used.
-
sendmail_flags
-
(str) If sendmail_enable is - set to “YES”, these are the flags to - pass to the sendmail(8) daemon.
-
sendmail_submit_enable
-
(bool) If set to - “YES” and - sendmail_enable is set to - “NO”, run - sendmail(8) using - sendmail_submit_flags instead of - sendmail_flags. This is intended to allow local mail - submission via a localhost-only listening SMTP service required for - running sendmail(8) as a non-set-user-ID binary. Note - that this does not work inside jail(2) systems, as jails - do not allow binding to just the localhost interface.
-
sendmail_submit_flags
-
(str) If sendmail_enable is - set to “NO” and - sendmail_submit_enable is set to - “YES”, these are the flags to pass - to the sendmail(8) daemon.
-
sendmail_outbound_enable
-
(bool) If set to - “YES” and both - sendmail_enable and - sendmail_submit_enable are set to - “NO”, run - sendmail(8) using - sendmail_outbound_flags instead of - sendmail_flags. This is intended to allow local mail - queue management for systems that do not offer a listening SMTP - service.
-
sendmail_outbound_flags
-
(str) If both sendmail_enable - and sendmail_submit_enable are set to - “NO” and - sendmail_outbound_enable is set to - “YES”, these are the flags to pass - to the sendmail(8) daemon.
-
sendmail_msp_queue_enable
-
(bool) If set to - “YES”, start a client (MSP) queue - runner sendmail(8) daemon at system boot time. As of - sendmail 8.12, a separate queue is used for command line submissions. The - client queue runner ensures that nothing is left behind in the submission - queue.
-
sendmail_msp_queue_flags
-
(str) If - sendmail_msp_queue_enable is set to daemon. - “YES”, these are the flags to pass - to the sendmail(8)
-
precious_machine
-
If set to “YES”, some destructive - actions require removal of the action-specific safe-belts before being - allowed. For instance, the file - /var/run/noshutdown is created to prevent - shutdown(8) targeted at the wrong machine.
-
virtual_oss_enable
-
(bool) If set to - “YES”, run one - virtual_oss(8) instance for each configuration defined - in virtual_oss_configs.
-
virtual_oss_configs
-
(str) Space-separated list of - virtual_oss(8) configurations. For example: -
- 
virtual_oss_configs="foo bar"
-
-

Configurations need to be defined in - virtual_oss_⟨config_name⟩. - By default, there is a dsp configuration which - replaces the /dev/dsp device created by - sound(4) with a virtual_oss(8) one. - It can be redefined by setting the - virtual_oss_dsp variable.

-
-
virtual_oss_⟨config_name⟩
-
(str) virtual_oss(8) argument list - for configuration ⟨config_name⟩.
-
virtual_oss_default_control_device
-
(str) The virtual_oss(8) control - device's name corresponding to the default configuration, - virtual_oss_dsp. This is set by default to - vdsp.ctl. When - virtual_oss_dsp is set, it is strongly encouraged - to set this variable as well, and use it as the -t - option's argument in virtual_oss_dsp, because it - is used by other programs and scripts, such as - /etc/devd/snd.conf.
-
-
-
-

-

The service jails part of the rc system automatically puts a - service into a jail. This jail inherits the filesystem and various other - parts of the parent (if you allow child-jails in your jails, service jails - can be used in jails) depending on the content of the - ⟨name⟩_svcj_options - variable. Typically this variable is set inside rc scripts, but it can be - overridden in the rc config. Valid options for - ⟨name⟩_svcj_options - are:

-
-
mlock
-
Allows to lock memory pages into the physical memory.
-
netv4
-
Allows IPv4 network access and the ability to bind to reserved ports. If - ⟨name⟩_svcj_ipaddrs - is set, only the IPv4 addresses listed there will be visible to the jail, - otherwise all assigned IPv4 addresses will be visible. This can not be - combined with netv6.
-
netv6
-
Allows IPv6 network access and the ability to bind to reserved ports. If - ⟨name⟩_svcj_ipaddrs - is set, only the IPv6 addresses listed there will be visible to the jail, - otherwise all assigned IPv6 addresses will be visible. This can not be - combined with netv4.
-
net_basic
-
Equivalent to enabling both netv6 and - netv4.
-
net_raw
-
Allow to open raw sockets. This option can be combined with - netv4, netv6, - net_basic.
-
net_all
-
Allows IPv6 and IPv4 network access as for netv4 - and netv6, allows to open raw sockets, and allows - to open sockets of protocol stacks that have not had jail functionality - added to them.
-
nfsd
-
Allows to run nfsd and affiliated daemons.
-
routing
-
Allows to modify the system routing table.
-
settime
-
Allows to set and slew the system time.
-
sysvipc
-
Inherits the SysV semaphores, SysV shared memory and SysV messages from - the host or the parent jail.
-
sysvipcnew
-
Creates a new namespace for SysV semaphores, SysV shared memory and SysV - messages for this particular service jail.
-
vmm
-
Allows access to vmm(4). This option is only available - when vmm(4) is enabled in the kernel.
-
-

All non-network options can be combined with all other options. - From the SysV options only one option can be specified.

-

If the - ⟨name⟩_svcj - variable is set to “YES”, this - particular service is started in a service jail named - svcj-name.

-

The svcj_all_enable variable allows to - enable service jails for all services of the system at once. Services which - have ⟨name⟩_svcj - set to “NO” are excluded. Some - services may set - ⟨name⟩_svcj to - “NO” in the script to either prevent - service jails for this service at all, or may set it to - “NO” if it is not set in the rc - config, to exclude it from svcj_all_enable but allow - to explicitly enable it. The sshd service for example would not see other - jails, if it would run as a service jail. This may or may not be what is - needed, and as such it is excluded from - svcj_all_enable but can be enabled via setting - sshd_svcj to - “YES”.

-
-
-

-
-
/etc/defaults/rc.conf
-
 
-
/etc/defaults/vendor.conf
-
 
-
/etc/rc.conf
-
 
-
/etc/rc.conf.local
-
 
-
/etc/rc.conf.d/
-
 
-
-
-
-

-

chmod(1), cpuset(1), - gdb(1) (ports/devel/gdb), - kbdcontrol(1), limits(1), - protect(1), sh(1), - umask(1), uuidgen(1), - vi(1), vidcontrol(1), - bridge(4), dummynet(4), - ip(4), ipf(4), - ipfw(4), ipnat(4), - kld(4), pf(4), - pflog(4), pfsync(4), - tcp(4), udp(4), - exports(5), fstab(5), - ipf(5), ipnat(5), - jail.conf(5), loader.conf(5), - login.conf(5), motd(5), - newsyslog.conf(5), pf.conf(5), - firewall(7), growfs(7), - security(7), tuning(7), - accton(8), apm(8), - bsdinstall(8), bthidd(8), - chkprintcap(8), chown(8), - cron(8), devfs(8), - dhclient(8), geli(8), - hcsecd(8), ifconfig(8), - inetd(8), iovctl(8), - ipf(8), ipfw(8), - ipnat(8), jail(8), - kldxref(8), loader(8), - lpd(8), makewhatis(8), - mdconfig(8), mdmfs(8), - mixer(8), mountd(8), - moused(8), newfs(8), - newsyslog(8), nfsd(8), - ntpd(8), ntpdate(8), - pfctl(8), pflogd(8), - ping(8), powerd(8), - quotacheck(8), quotaon(8), - rc(8), rc.subr(8), - rcorder(8), rfcomm_pppd(8), - route(8), route6d(8), - routed(8), rpc.lockd(8), - rpc.statd(8), rpc.tlsclntd(8), - rpc.tlsservd(8), rpcbind(8), - rwhod(8), savecore(8), - sdpd(8), sendmail(8), - service(8), sshd(8), - swapon(8), sysctl(8), - syslogd(8), sysrc(8), - unbound(8), usbconfig(8), - utx(8), virtual_oss(8), - wlandebug(8), yp(8), - ypbind(8), ypserv(8), - ypset(8)

-
-
-

-

The rc.conf file appeared in - FreeBSD 2.2.2.

-
-
-

-

Jordan K. Hubbard.

-
-
- - - - - -
April 2, 2026FreeBSD 15.0
diff --git a/static/freebsd/man5/rctl.conf.5 4.html b/static/freebsd/man5/rctl.conf.5 4.html deleted file mode 100644 index 8e70342e..00000000 --- a/static/freebsd/man5/rctl.conf.5 4.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
RCTL.CONF(5)File Formats ManualRCTL.CONF(5)
-
-
-

-

rctl.conf — - resource limits database defaults

-
-
-

-

The /etc/rctl.conf file is read in when - the system goes into multi-user mode to set default contents of the RCTL - database. The /etc/rctl.conf is in the format of the - rctl(8) command, i.e.

-
-
subject:subject-id:resource:action=amount/per
-
-

Comments are denoted by a “#” at the beginning of a - line. Comments can also exist at the end of a line, as seen in the - EXAMPLES section, below.

-
-
-

-
-
/etc/rctl.conf
-
Initial settings for rctl(8).
-
-
-
-

-

To limit the number of processes for users in login class - "testing", use a rule like

-
-
# Resource limits for the "testing" class.
-loginclass:testing:maxproc:deny=100/user # At most 100 processes per user
-
-
-
-

-

rctl(8)

-
-
-

-

The rctl.conf file appeared in - FreeBSD 9.0.

-
-
- - - - - -
October 6, 2023FreeBSD 15.0
diff --git a/static/freebsd/man5/regdomain.5 4.html b/static/freebsd/man5/regdomain.5 4.html deleted file mode 100644 index ba75d887..00000000 --- a/static/freebsd/man5/regdomain.5 4.html +++ /dev/null @@ -1,40 +0,0 @@ - - - - - - -
REGDOMAIN(5)File Formats ManualREGDOMAIN(5)
-
-
-

-

regdomain.xml — - 802.11 wireless regulatory definitions

-
-
-

-

The regdomain.xml file describes - regulations for the operation of IEEE 802.11 wireless radios.

-

This information is used by the ifconfig(8) - program to construct regulatory state for download to the system. This file - should be changed only to reflect changes in regulations.

-
-
-

-
-
/etc/regdomain.xml
-
XML database of 802.11 regulatory constraints
-
-
-
-

-

wlan(4), ifconfig(8)

-
-
- - - - - -
April 13, 2008FreeBSD 15.0
diff --git a/static/freebsd/man5/remote.5 3.html b/static/freebsd/man5/remote.5 3.html deleted file mode 100644 index 1af768cb..00000000 --- a/static/freebsd/man5/remote.5 3.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - -
REMOTE(5)File Formats ManualREMOTE(5)
-
-
-

-

remote — remote - host description file

-
-
-

-

The systems known by tip(1) and their attributes - are stored in an ASCII file which is structured somewhat like the - termcap(5) file. Each line in the file provides a - description for a single - . - Fields are separated by a colon (``:''). Lines ending in a \ character with - an immediately following newline are continued on the next line.

-

The first entry is the name(s) of the host system. If there is - more than one name for a system, the names are separated by vertical bars. - After the name of the system comes the fields of the description. A field - name followed by an `=' sign indicates a string value. A field name followed - by a `#' sign indicates a numeric value.

-

Entries named ``tip*'' and ``cu*'' are used as default entries by - tip(1), and the cu(1) interface to - tip, as follows. When tip is - invoked with only a phone number, it looks for an entry of the form - ``tip300'', where 300 is the data rate with which the connection is to be - made. When the cu interface is used, entries of the - form ``cu300'' are used.

-
-
-

-

Capabilities are either strings (str), numbers (num), or boolean - flags (bool). A string capability is specified by - capability=value; - for example, ``dv=/dev/harris''. A numeric capability is specified by - capability#value; - for example, ``xa#99''. A boolean capability is specified by simply listing - the capability.

-
-
-
(str) Auto call unit type.
-
-
(num) The data rate (bits per second) used for communications on the - serial port. When a modem is used, the data rate used to communicate with - the remote modem may be different than this rate. This is a decimal - number. The default rate is 115200 bits per second.
-
-
(str) An initial connection message to be sent to the remote host. For - example, if a host is reached through a port selector, this might be set - to the appropriate sequence required to switch to the host.
-
-
(str) Call unit if making a phone call. Default is the same as the `dv' - field.
-
-
(str) Disconnect message sent to the host when a disconnect is requested - by the user.
-
-
(bool) This host is on a dial-up line.
-
-
(str) UNIX device(s) to open to establish a - connection. If this file refers to a terminal line, - tip(1) attempts to perform an exclusive open on the - device to ensure only one user at a time has access to the port.
-
-
(str) Characters marking an end-of-line. The default is - NULL. `~' escapes are only recognized by - tip after one of the characters in `el', or after - a carriage-return.
-
-
(str) Frame size for transfers. The default frame size is equal to - BUFSIZ.
-
-
(bool) The host uses half-duplex communication, local echo should be - performed.
-
-
(str) Input end-of-file marks. The default is - NULL.
-
-
(str) Output end-of-file string. The default is - NULL. When tip is - transferring a file, this string is sent at end-of-file.
-
-
(str) The type of parity to use when sending data to the host. This may be - one of ``even'', ``odd'', ``none'', ``zero'' (always set bit 8 to zero), - ``one'' (always set bit 8 to 1). The default is even parity.
-
-
(str) Telephone number(s) for this host. If the telephone number field - contains an @ sign, tip searches the file - /etc/phones file for a list of telephone numbers - (see phones(5)).
-
-
(str) Indicates that the list of capabilities is continued in the named - description. This is used primarily to share common capability - information.
-
-
-
-

-
-
/etc/remote
-
The remote host description file resides in - /etc.
-
-
-
-

-

Here is a short example showing the use of the capability - continuation feature. It defines a 56k modem connection on the first serial - port at 115200 bits per second, no parity using the Hayes command set with - standard line editing and end of file characters. The arpavax entry includes - everything in the UNIX-57600 entry plus the phone number for arpavax (in - this case an @ character so that it is retrieved from the environment).

-
-
UNIX-57600:\
-:dv=/dev/cuau0:el=^D^U^C^S^Q^O@:oe=^D:du:at=hayes:br#115200:pa=none:
-arpavax|ax:\
-:pn=\@:tc=UNIX-57600
-
-
-
-

-

cu(1), tip(1), - phones(5)

-
-
-

-

The remote file format appeared in - 4.2BSD.

-
-
-

-

The tip(1) utility uses its own notion of the - serial ports data rate rather than the system default for a serial port.

-
-
- - - - - -
October 20, 2003FreeBSD 15.0
diff --git a/static/freebsd/man5/resolver.5 3.html b/static/freebsd/man5/resolver.5 3.html deleted file mode 100644 index 3f32c857..00000000 --- a/static/freebsd/man5/resolver.5 3.html +++ /dev/null @@ -1,218 +0,0 @@ - - - - - - -
RESOLVER(5)File Formats ManualRESOLVER(5)
-
-
-

-

resolver — - resolver configuration file

-
-
-

- - - - - -
resolv.conf
-
-
-

-

The resolver(3) is a set of routines in the C - library which provide access to the Internet Domain Name System. The - resolver configuration file contains information that is read by the - resolver routines the first time they are invoked by a process. The file is - designed to be human readable and contains a list of keywords with values - that provide various types of resolver information.

-

On a normally configured system, setting this file manually should - not be necessary. The only name server(s) to be queried will be on the local - machine or automatically configured using DHCP or a similar mechanism, the - domain name is determined from the host name, and the domain search path is - constructed from the domain name.

-

The different configuration options are:

-
-
-
IPv4 or IPv6 address of a name server that the resolver should query. Up - to MAXNS (currently 3) name servers may be listed, - one per keyword. If there are multiple servers, the resolver library - queries them in the order listed. If no nameserver - entries are present, the default is to use the name server on the local - machine. (The algorithm used is to try a name server, and if the query - times out, try the next, until out of name servers, then repeat trying all - the name servers until a maximum number of retries are made).
-
-
Local domain name. Most queries for names within this domain can use short - names relative to the local domain. If no domain entry - is present, the domain is determined from the local host name returned by - gethostname(3); the domain part is taken to be - everything after the first ‘.’. - Finally, if the host name does not contain a domain part, the root domain - is assumed.
- -
Search list for host-name lookup. The search list is normally determined - from the local domain name; by default, it contains only the local domain - name. This may be changed by listing the desired domain search path - following the search keyword with spaces or tabs - separating the names. Most resolver queries will be attempted using each - component of the search path in turn until a match is found. Note that - this process may be slow and will generate a lot of network traffic if the - servers for the listed domains are not local, and that queries will time - out if no server is available for one of the domains. -

The search list is currently limited to six domains with a - total of 256 characters.

-
-
-
Sortlist allows addresses returned by gethostbyname to be sorted. A - sortlist is specified by IP address netmask pairs. If the netmask is not - specified, it defaults to the historical Class A/B/C netmask of the net; - this usage is deprecated. The IP address and network pairs are separated - by slashes. Up to 10 pairs may be specified. E.g., -

-
sortlist 10.9.1.0/255.255.240.0 - 10.9.0.0/255.255.0.0
-
-
-
Options allows certain internal resolver variables to be modified. The - syntax is -

options option ...

-

where - is one - of the following:

-
-
-
sets RES_DEBUG in _res.options.
-
-
sets RES_USEVC to use TCP instead of UDP for - queries.
-
:n
-
sets a threshold for the number of dots which must appear in a name - given to - () - (see resolver(3)) before an - will be made. The default for - is - “1”, meaning that if there are any dots in a name, the - name will be tried first as an absolute name before any - search list elements are appended to it.
-
:n
-
sets the initial amount of time the resolver will wait for a response - from a remote name server before retrying the query via a different - name server. The resolver may wait longer during subsequent retries of - the current query since an exponential back-off is applied to the - timeout value. Measured in seconds, the default is - RES_TIMEOUT, the allowed maximum is - RES_MAXRETRANS (see - <resolv.h>).
-
:n
-
sets the number of times the resolver will send a query to each of its - name servers before giving up and returning an error to the calling - application. The default is RES_DFLRETRY, the - allowed maximum is RES_MAXRETRY (see - <resolv.h>).
-
-
Sets RES_USE_EDNS0. Attach an OPT pseudo-RR - for the EDNS0 extension, as specified in RFC 2671. This allows the - resolver to advertise a larger UDP receive buffer size, permitting - responses larger than the original 512-byte limit.
-
-
Sets RES_USE_INET6. Causes - gethostbyname(3) to look up AAAA records before A - records and to map IPv4 responses into IPv6 addresses. The use of this - option is discouraged.
-
-
Sets RES_INSECURE1. Disables the check that - the response was received from the same server to which the query was - sent. Use of this option is a security risk and is not - recommended.
-
-
Sets RES_INSECURE2. Disables the check that - the response contains a query matching the one that was sent. Use of - this option is a security risk and is not recommended.
-
-
Sets RES_NOCHECKNAME. Disables the check of - incoming host names for invalid characters such as underscore, - non-ASCII, or control characters.
-
-
tells the resolver not to attempt to resolve a top level domain name, - that is, a name that contains no dots. Use of this option does not - prevent the resolver from obeying the standard - domain and search rules with the - given name.
-
-
Sets RES_ROTATE. Causes the resolver to - round-robin among the configured name servers, distributing the query - load instead of always trying the first listed server.
-
:n
-
The resolver checks the modification time of - /etc/resolv.conf every n - seconds. If /etc/resolv.conf has changed, it - is automatically reloaded. The default for n is - two seconds. Setting it to zero disables the file check.
-
-

Options may also be specified as a space or tab separated list - using the RES_OPTIONS environment variable.

-
-
-

The domain and search keywords - are mutually exclusive. If more than one instance of these keywords is - present, the last instance will override.

-

The keyword and value must appear on a single line, and the - keyword (for example, nameserver) must start the line. The - value follows the keyword, separated by white space.

-
-
-

-
-
/etc/resolv.conf
-
The file resolv.conf resides in - /etc.
-
-
-
-

-

A basic resolv.conf file could be in the following form.

-
-
# The domain directive is only necessary, if your local
-# router advertises something like localdomain and you have
-# set up your hostnames via an external domain.
-domain localdomain.tld
-
-# In case you a running a local dns server or caching name server
-# like local-unbound(8) for example.
-nameserver 127.0.0.1
-
-# IP address of the local or ISP name service
-nameserver 192.168.2.1
-
-# Fallback nameservers, in this case these from Google.
-nameserver 8.8.8.8
-nameserver 8.8.4.4
-
-# Attach an OPT pseudo-RR for the EDNS0 extension,
-# as specified in RFC 2671.
-options edns0
-
-
-
-

-

gethostbyname(3), resolver(3), - hostname(7), resolvconf(8)

-
-
-

-

The resolv.conf file format appeared in - 4.3BSD.

-
-
- - - - - -
March 15, 2026FreeBSD 15.0
diff --git a/static/freebsd/man5/services.5 3.html b/static/freebsd/man5/services.5 3.html deleted file mode 100644 index 78fb12d9..00000000 --- a/static/freebsd/man5/services.5 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
SERVICES(5)File Formats ManualSERVICES(5)
-
-
-

-

services — - internet service name and port number data base

-
-
-

-

The services file contains information - regarding the known services available in the Internet. For each service a - single line should be present with the following information:

-
-
official service name
-port number
-protocol name
-aliases
-
-

Items are separated by any number of blanks and/or tab - characters. The port number and protocol name are considered a single - ; a ``/'' is - used to separate the port and protocol (e.g. ``512/tcp''). A ``#'' indicates - the beginning of a comment; subsequent characters up to the end of the line - are not interpreted by the routines which search the file.

-

Service names may contain any printable character other than a - field delimiter, newline, or comment character.

-

If “db” is specified as source in the - nsswitch.conf(5), - /var/db/services.db is searched. The database in - /var/db/services.db needs to be updated with - services_mkdb(8) after changes to the services file have - been applied.

-
-
-

-

Access to the NIS services.byname map can - be enabled by adding a single ``+'' on a line by itself in the - /etc/services file. This causes the contents of the - NIS services map to be inserted at the location where the ``+'' appears.

-
-
-

-
-
/etc/services
-
The services file resides in - /etc.
-
-
-
-

-

getservent(3), - nsswitch.conf(5), services_mkdb(8)

-
-
-

-

The services file format appeared in - 4.2BSD.

-
-
-

-

A name server should be used instead of a static file.

-
-
- - - - - -
April 29, 2024FreeBSD 15.0
diff --git a/static/freebsd/man5/shells.5 4.html b/static/freebsd/man5/shells.5 4.html deleted file mode 100644 index 414f831d..00000000 --- a/static/freebsd/man5/shells.5 4.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - -
SHELLS(5)File Formats ManualSHELLS(5)
-
-
-

-

shells — shell - database

-
-
-

-

The shells file contains a list of the - shells on the system. For each shell a single line should be present, - consisting of the shell's path, relative to root.

-

A hash mark (``#'') indicates the beginning of a comment; - subsequent characters up to the end of the line are not interpreted by the - routines which search the file. Blank lines are also ignored.

-
-
-

-
-
/etc/shells
-
The shells file resides in - /etc.
-
-
-
-

-

getusershell(3)

-
-
-

-

The shells file format appeared in - 4.3BSD-Tahoe.

-
-
- - - - - -
June 5, 1993FreeBSD 15.0
diff --git a/static/freebsd/man5/src.conf.5 3.html b/static/freebsd/man5/src.conf.5 3.html deleted file mode 100644 index 02e1e0b3..00000000 --- a/static/freebsd/man5/src.conf.5 3.html +++ /dev/null @@ -1,1550 +0,0 @@ - - - - - - -
SRC.CONF(5)File Formats ManualSRC.CONF(5)
-
-
-

-

src.conf — source - build options

-
-
-

-

The src.conf file contains variables that - control what components will be generated during the build process of the - FreeBSD source tree; see - build(7).

-

The src.conf file uses the standard - makefile syntax. However, src.conf should not - specify any dependencies to make(1). Instead, - src.conf is to set make(1) - variables that control the aspects of how the system builds.

-

The default location of src.conf is the - top level of the source tree, or /etc/src.conf if no - src.conf is found in the source tree itself, though - an alternative location can be specified in the make(1) - variable SRCCONF. Overriding the location of - src.conf may be necessary if the system-wide - settings are not suitable for a particular build. For instance, setting - SRCCONF to /dev/null - effectively resets all build controls to their defaults.

-

The only purpose of src.conf is to control - the compilation of the FreeBSD source code, which is - usually located in /usr/src. As a rule, the system - administrator creates src.conf when the values of - certain control variables need to be changed from their defaults.

-

In addition, control variables can be specified for a particular - build via the -D option of make(1) - or in its environment; see environ(7).

-

The environment of make(1) for the build can be - controlled via the SRC_ENV_CONF variable, which - defaults to /etc/src-env.conf. Some examples that - may only be set in this file are WITH_DIRDEPS_BUILD, - and WITH_META_MODE, and - MAKEOBJDIRPREFIX as they are environment-only - variables.

-

The values of WITH_ and - WITHOUT_ variables are ignored regardless of their - setting; even if they would be set to - “FALSE” or - “NO”. The presence of an option causes - it to be honored by make(1).

-

This list provides a name and short description for variables that - can be used for source builds.

-
-
WITHOUT_ACCT
-
Do not build process accounting tools such as accton(8) - and sa(8).
-
WITHOUT_ACPI
-
Do not build acpiconf(8), acpidump(8) - and related programs.
-
WITHOUT_APM
-
Do not build apm(8), apmd(8) and - related programs.
-
WITH_ASAN
-
Build the base system with Address Sanitizer (ASan) to detect memory - corruption bugs such as buffer overflows or use-after-free. Requires that - Clang be used as the base system compiler and that the runtime support - library is available. When set, it enforces these options: -

-
    -
  • WITH_LLVM_BINUTILS
    • -
-
-
WITHOUT_ASSERT_DEBUG
-
Compile programs and libraries without the assert(3) - checks.
-
WITHOUT_AT
-
Do not build at(1) and related utilities.
-
WITHOUT_AUDIT
-
Do not build audit support into system programs.
-
WITHOUT_AUTHPF
-
Do not build authpf(8).
-
WITHOUT_AUTOFS
-
Do not build autofs(4) related programs, libraries, and - kernel modules.
-
WITHOUT_AUTO_OBJ
-
Disable automatic creation of objdirs. This is enabled by default if the - wanted OBJDIR is writable by the current user. -

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITH_BEARSSL
-
Build the BearSSL library. -

BearSSL is a tiny SSL library suitable for embedded - environments. For details see - https://www.BearSSL.org/

-

This library is currently only used to perform signature - verification and related operations for Verified Exec and - loader(8).

-

Due to size constraints in the BIOS environment on x86, one - may need to set LOADERSIZE larger than the default - 500000, although often loader is under the 500k limit even with this - option. Setting LOADERSIZE larger than 500000 may - cause pxeboot(8) to be too large to work. Careful - testing of the loader in the target environment when built with a larger - limit to establish safe limits is critical because different BIOS - environments reserve differing amounts of the low 640k space, making a - precise limit for everybody impossible.

-

See also WITH_LOADER_PXEBOOT for other - considerations. When set, these options are also in effect:

-

-
-
WITH_LOADER_EFI_SECUREBOOT
-
(unless WITHOUT_LOADER_EFI_SECUREBOOT is set - explicitly)
-
WITH_LOADER_VERIEXEC
-
(unless WITHOUT_LOADER_VERIEXEC is set - explicitly)
-
WITH_LOADER_VERIEXEC_VECTX
-
(unless WITHOUT_LOADER_VERIEXEC_VECTX is set - explicitly)
-
WITH_VERIEXEC
-
(unless WITHOUT_VERIEXEC is set explicitly)
-
-
-
WITHOUT_BHYVE
-
Do not build or install bhyve(8), associated utilities, - and examples. -

This option only affects amd64/amd64 and arm64/aarch64.

-
-
WITH_BHYVE_SNAPSHOT
-
Include support for save and restore (snapshots) in - bhyve(8) and bhyvectl(8). -

This option only affects amd64/amd64.

-
-
WITH_BIND_NOW
-
Build all binaries with the DF_BIND_NOW flag set - to indicate that the run-time loader should perform all relocation - processing at process startup rather than on demand. The combination of - the BIND_NOW and RELRO options - provide "full" Relocation Read-Only (RELRO) support. With full - RELRO the entire GOT is made read-only after performing relocation at - startup, avoiding GOT overwrite attacks.
-
WITHOUT_BLACKLIST
-
This option has been renamed to WITHOUT_BLOCKLIST. - When set, it enforces these options: -

-
    -
  • WITHOUT_BLOCKLIST
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_BLACKLIST_SUPPORT
-
(unless WITH_BLACKLIST_SUPPORT is set - explicitly)
-
WITHOUT_BLOCKLIST_SUPPORT
-
(unless WITH_BLOCKLIST_SUPPORT is set - explicitly)
-
-
-
WITHOUT_BLACKLIST_SUPPORT
-
This option has been renamed to - WITHOUT_BLOCKLIST_SUPPORT. When set, it enforces - these options: -

-
    -
  • WITHOUT_BLOCKLIST_SUPPORT
    • -
-
-
WITHOUT_BLOCKLIST
-
Set this if you do not want to build blocklistd(8) and - blocklistctl(8). When set, it enforces these options: -

-
    -
  • WITHOUT_BLACKLIST
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_BLACKLIST_SUPPORT
-
(unless WITH_BLACKLIST_SUPPORT is set - explicitly)
-
WITHOUT_BLOCKLIST_SUPPORT
-
(unless WITH_BLOCKLIST_SUPPORT is set - explicitly)
-
-
-
WITHOUT_BLOCKLIST_SUPPORT
-
Build some programs without libblocklist(3) support, - like fingerd(8) and sshd(8). When set, - it enforces these options: -

-
    -
  • WITHOUT_BLACKLIST_SUPPORT
    • -
-
-
WITHOUT_BLUETOOTH
-
Do not build Bluetooth related kernel modules, programs and - libraries.
-
WITHOUT_BOOT
-
Do not build the boot blocks and loader.
-
WITHOUT_BOOTPARAMD
-
Do not build or install bootparamd(8).
-
WITHOUT_BOOTPD
-
Do not build or install bootpd(8).
-
WITH_BRANCH_PROTECTION
-
Build with branch protection enabled. On arm64 enable the use of pointer - authentication and branch target identification instructions on arm64. - These can be used to help mitigate some exploit techniques.
-
WITHOUT_BSDINSTALL
-
Do not build bsdinstall(8), sade(8), - and related programs.
-
WITHOUT_BSNMP
-
Do not build or install bsnmpd(1) and related libraries - and data files.
-
WITHOUT_CALENDAR
-
Do not build calendar(1).
-
WITHOUT_CAROOT
-
Do not add the trusted certificates from the Mozilla NSS bundle to - base.
-
WITHOUT_CASPER
-
This option has no effect.
-
WITH_CCACHE_BUILD
-
Use ccache(1) for the build. No configuration is - required except to install the - - or - - package. When using with distcc(1), set - . - When using with sccache set - - in src.conf(5). The default cache directory of - $HOME/.ccache will be used, which can be - overridden by setting - . - The - - option defaults to - - when using the in-tree bootstrap compiler, and - - when using an external compiler. The - - option is used for Clang but not GCC. -

Sharing a cache between multiple work directories requires - using a layout similar to /some/prefix/src - /some/prefix/obj and an environment such as:

-
- 
CCACHE_BASEDIR='${SRCTOP:H}' MAKEOBJDIRPREFIX='${SRCTOP:H}/obj'
-
-

See ccache(1) for more configuration - options.

-
-
WITHOUT_CCD
-
Do not build geom_ccd(4) and related utilities.
-
WITHOUT_CDDL
-
Do not build code licensed under Sun's CDDL. When set, it enforces these - options: -

-
    -
  • WITHOUT_CTF
    • -
  • WITHOUT_DTRACE
    • -
  • WITHOUT_LOADER_ZFS
    • -
  • WITHOUT_ZFS
    • -
  • WITHOUT_ZFS_TESTS
    • -
-
-
WITHOUT_CLANG
-
Do not build the Clang C/C++ compiler during the regular phase of the - build. When set, it enforces these options: -

-
    -
  • WITHOUT_CLANG_EXTRAS
    • -
  • WITHOUT_CLANG_FORMAT
    • -
  • WITHOUT_CLANG_FULL
    • -
  • WITHOUT_LLVM_COV
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_LLVM_TARGET_AARCH64
-
(unless WITH_LLVM_TARGET_AARCH64 is set - explicitly)
-
WITHOUT_LLVM_TARGET_ALL
-
(unless WITH_LLVM_TARGET_ALL is set - explicitly)
-
WITHOUT_LLVM_TARGET_ARM
-
(unless WITH_LLVM_TARGET_ARM is set - explicitly)
-
WITHOUT_LLVM_TARGET_POWERPC
-
(unless WITH_LLVM_TARGET_POWERPC is set - explicitly)
-
WITHOUT_LLVM_TARGET_RISCV
-
(unless WITH_LLVM_TARGET_RISCV is set - explicitly)
-
-
-
WITHOUT_CLANG_BOOTSTRAP
-
Do not build the Clang C/C++ compiler during the bootstrap phase of the - build. To be able to build the system, either gcc or clang bootstrap must - be enabled unless an alternate compiler is provided via XCC.
-
WITH_CLANG_EXTRAS
-
Build additional clang and llvm tools, such as bugpoint and - clang-format.
-
WITH_CLANG_FORMAT
-
Build clang-format.
-
WITHOUT_CLANG_FULL
-
Avoid building the ARCMigrate, Rewriter and StaticAnalyzer components of - the Clang C/C++ compiler.
-
WITH_CLEAN
-
Clean before building world and/or kernel. Note that recording a new epoch - in .clean_build_epoch in the root of the source - tree will also force a clean world build. When set, these options are also - in effect: -

-
-
WITHOUT_DEPEND_CLEANUP
-
(unless WITH_DEPEND_CLEANUP is set - explicitly)
-
-
-
WITHOUT_CPP
-
Do not build cpp(1).
-
WITHOUT_CROSS_COMPILER
-
Do not build any cross compiler in the cross-tools stage of buildworld. - When compiling a different version of FreeBSD than - what is installed on the system, provide an alternate compiler with XCC to - ensure success. When compiling with an identical version of - FreeBSD to the host, this option may be safely - used. This option may also be safe when the host version of - FreeBSD is close to the sources being built, but - all bets are off if there have been any changes to the toolchain between - the versions. When set, it enforces these options: -

-
    -
  • WITHOUT_CLANG_BOOTSTRAP
    • -
  • WITHOUT_ELFTOOLCHAIN_BOOTSTRAP
    • -
  • WITHOUT_LLD_BOOTSTRAP
    • -
  • WITHOUT_LLVM_BINUTILS_BOOTSTRAP
    • -
-
-
WITHOUT_CRYPT
-
Do not build any crypto code. When set, it enforces these options: -

-
    -
  • WITHOUT_DMAGENT
    • -
  • WITHOUT_KERBEROS
    • -
  • WITHOUT_LDNS
    • -
  • WITHOUT_LDNS_UTILS
    • -
  • WITHOUT_LOADER_ZFS
    • -
  • WITHOUT_MITKRB5
    • -
  • WITHOUT_OPENSSH
    • -
  • WITHOUT_OPENSSL
    • -
  • WITHOUT_OPENSSL_KTLS
    • -
  • WITHOUT_PKGBOOTSTRAP
    • -
  • WITHOUT_UNBOUND
    • -
  • WITHOUT_ZFS
    • -
  • WITHOUT_ZFS_TESTS
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_KERBEROS_SUPPORT
-
(unless WITH_KERBEROS_SUPPORT is set - explicitly)
-
-
-
WITH_CTF
-
Compile with CTF (Compact C Type Format) data. CTF data encapsulates a - reduced form of debugging information similar to DWARF and the venerable - stabs and is required for DTrace.
-
WITHOUT_CUSE
-
Do not build CUSE-related programs and libraries.
-
WITHOUT_CXGBETOOL
-
Do not build cxgbetool(8) -

This is a default setting on arm/armv7 and riscv/riscv64.

-
-
WITH_CXGBETOOL
-
Build cxgbetool(8) -

This is a default setting on amd64/amd64, arm64/aarch64, - i386/i386, powerpc/powerpc64 and powerpc/powerpc64le.

-
-
WITHOUT_DEBUG_FILES
-
Avoid building or installing standalone debug files for each executable - binary and shared library.
-
WITHOUT_DEPEND_CLEANUP
-
Do not attempt to detect if the object tree needs cleaning in part or in - whole before building. This speeds up incremental builds, especially when - experimenting with build options, but may cause the build to inexplicably - fail or produce non-functioning binaries.
-
WITH_DETECT_TZ_CHANGES
-
Make the time handling code detect changes to the timezone files.
-
WITH_DIALOG
-
Do build dialog(1), dialog(3), - dpv(1), and dpv(3).
-
WITHOUT_DICT
-
Do not build the Webster dictionary files.
-
WITH_DIRDEPS_BUILD
-
This is an alternate build system. For details see - https://www.crufty.net/sjg/docs/freebsd-meta-mode.htm. Build commands can - be seen from the top-level with: -
make - show-valid-targets
- The build is driven by dirdeps.mk using DIRDEPS stored - in Makefile.depend files found in each directory. -

The build can be started from anywhere, and behaves the same. - The initial instance of make(1) recursively reads - DIRDEPS from - Makefile.depend, computing a graph of tree - dependencies from the current origin. Setting - NO_DIRDEPS skips checking dirdep dependencies and - will only build in the current and child directories. - NO_DIRDEPS_BELOW skips building any dirdeps and - only build the current directory.

-

This also utilizes the WITH_META_MODE - logic for incremental builds.

-

The build hides commands executed unless - NO_SILENT is defined.

-

Note that there is currently no mass install feature for this. - This build is designed for producing packages, that can then be - installed on a target system.

-

The implementation in FreeBSD is - incomplete. Completion would require leaf directories for building each - kernel and package so that their dependencies can be tracked. When set, - it enforces these options:

-

-
    -
  • WITH_INSTALL_AS_USER
    • -
-

When set, these options are also in effect:

-

-
-
WITH_META_ERROR_TARGET
-
(unless WITHOUT_META_ERROR_TARGET is set - explicitly)
-
WITH_META_MODE
-
(unless WITHOUT_META_MODE is set - explicitly)
-
WITH_STAGING
-
(unless WITHOUT_STAGING is set explicitly)
-
WITH_STAGING_MAN
-
(unless WITHOUT_STAGING_MAN is set - explicitly)
-
WITH_STAGING_PROG
-
(unless WITHOUT_STAGING_PROG is set - explicitly)
-
WITH_SYSROOT
-
(unless WITHOUT_SYSROOT is set explicitly)
-
-

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITH_DIRDEPS_CACHE
-
Cache result of dirdeps.mk which can save significant time for subsequent - builds. Depends on WITH_DIRDEPS_BUILD. -

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITH_DISK_IMAGE_TOOLS_BOOTSTRAP
-
Build etdump(1), makefs(8) and - mkimg(1) as bootstrap tools.
-
WITHOUT_DMAGENT
-
Do not build dma Mail Transport Agent.
-
WITHOUT_DOCCOMPRESS
-
Do not install compressed system documentation. Only the uncompressed - version will be installed.
-
WITHOUT_DTRACE
-
Do not build DTrace framework kernel modules, libraries, and user - commands. When set, it enforces these options: -

-
    -
  • WITHOUT_CTF
    • -
-
-
WITH_DTRACE_ASAN
-
Compile userspace DTrace code (libdtrace, dtrace(1), lockstat(1), - plockstat(1)) with address and undefined behavior sanitizers. Requires - that Clang be used as the base system compiler and that the runtime - support library is available.
-
WITH_DTRACE_TESTS
-
Build and install the DTrace test suite in - /usr/tests/cddl/usr.sbin/dtrace. This test suite - is considered experimental on architectures other than amd64/amd64 and - running it may cause system instability.
-
WITHOUT_DYNAMICROOT
-
Set this if you do not want to link /bin and - /sbin dynamically.
-
WITHOUT_EE
-
Do not build and install edit(1), - ee(1), and related programs.
-
WITHOUT_EFI
-
Set not to build efivar(3) and - efivar(8). -

This is a default setting on i386/i386, powerpc/powerpc64 and - powerpc/powerpc64le.

-
-
WITH_EFI
-
Build efivar(3) and efivar(8). -

This is a default setting on amd64/amd64, arm/armv7, - arm64/aarch64 and riscv/riscv64.

-
-
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP
-
Do not build ELF Tool Chain tools (addr2line, nm, size, strings and strip) - as part of the bootstrap process. -
An alternate bootstrap tool chain must be provided.
-
-
WITHOUT_EXAMPLES
-
Avoid installing examples to - /usr/share/examples/.
-
WITHOUT_FDT
-
Do not build Flattened Device Tree support as part of the base system. - This includes the device tree compiler (dtc) and libfdt support library. -

This is a default setting on amd64/amd64 and i386/i386.

-
-
WITH_FDT
-
Build Flattened Device Tree support as part of the base system. This - includes the device tree compiler (dtc) and libfdt support library. -

This is a default setting on arm/armv7, arm64/aarch64, - powerpc/powerpc64, powerpc/powerpc64le and riscv/riscv64.

-
-
WITHOUT_FILE
-
Do not build file(1) and related programs.
-
WITHOUT_FINGER
-
Do not build or install finger(1) and - fingerd(8).
-
WITHOUT_FLOPPY
-
Do not build or install programs for operating floppy disk driver.
-
WITHOUT_FORMAT_EXTENSIONS
-
Do not enable -fformat-extensions when compiling - the kernel. Also disables all format checking.
-
WITHOUT_FORTH
-
Build bootloaders without Forth support.
-
WITHOUT_FREEBSD_UPDATE
-
Do not build freebsd-update(8).
-
WITHOUT_FTP
-
Do not build or install ftp(1).
-
WITHOUT_GAMES
-
Do not build games.
-
WITHOUT_GOOGLETEST
-
Neither build nor install library - “libgmock”, library - “libgtest”, and dependent tests.
-
WITHOUT_GPIO
-
Do not build gpioctl(8) as part of the base system.
-
WITHOUT_HAST
-
Do not build hastd(8) and related utilities.
-
WITH_HESIOD
-
Build Hesiod support.
-
WITHOUT_HTML
-
Do not build HTML docs.
-
WITHOUT_HYPERV
-
Do not build or install HyperV utilities. -

This is a default setting on arm/armv7, powerpc/powerpc64, - powerpc/powerpc64le and riscv/riscv64.

-
-
WITH_HYPERV
-
Build or install HyperV utilities. -

This is a default setting on amd64/amd64, arm64/aarch64 and - i386/i386.

-
-
WITHOUT_ICONV
-
Do not build iconv as part of libc.
-
WITHOUT_INCLUDES
-
Do not install header files. This option used to be spelled - NO_INCS. -
The option does not work for build targets.
-
-
WITHOUT_INET
-
Do not build programs and libraries related to IPv4 networking. When set, - it enforces these options: -

-
    -
  • WITHOUT_INET_SUPPORT
    • -
-
-
WITHOUT_INET6
-
Do not build programs and libraries related to IPv6 networking. When set, - it enforces these options: -

-
    -
  • WITHOUT_INET6_SUPPORT
    • -
-
-
WITHOUT_INET6_SUPPORT
-
Build libraries, programs, and kernel modules without IPv6 support.
-
WITHOUT_INETD
-
Do not build inetd(8).
-
WITHOUT_INET_SUPPORT
-
Build libraries, programs, and kernel modules without IPv4 support.
-
WITHOUT_INSTALLLIB
-
Set this to not install optional libraries. For example, when creating a - nanobsd(8) image. -
The option does not work for build targets.
-
-
WITH_INSTALL_AS_USER
-
Make install targets succeed for non-root users by installing files with - owner and group attributes set to that of the user running the - make(1) command. The user still must set the - DESTDIR variable to point to a directory where the - user has write permissions.
-
WITHOUT_IPFILTER
-
Do not build IP Filter package.
-
WITH_IPFILTER_IPFS
-
Enable building the ipfs(8) tool to save and restore - IPFilter state tables.
-
WITHOUT_IPFW
-
Do not build IPFW tools.
-
WITHOUT_IPSEC_SUPPORT
-
Do not build the kernel with ipsec(4) support. This - option is needed for ipsec(4) and - tcpmd5(4).
-
WITHOUT_ISCSI
-
Do not build iscsid(8) and related utilities.
-
WITHOUT_JAIL
-
Do not build tools for the support of jails; e.g., - jail(8).
-
WITHOUT_JEMALLOC_LG_VADDR_WIDE
-
Disallow programs to use more than 48 address bits on amd64. Incompatible - with LA57 mode. Enabling this option might result in a slight reduction in - memory consumption for jemalloc metadata, but also requires disabling LA57 - (if hardware supports it).
-
WITHOUT_KDUMP
-
Do not build kdump(1) and - truss(1).
-
WITHOUT_KERBEROS
-
Set this to not build Kerberos. When set, these options are also in - effect: -

-
-
WITHOUT_KERBEROS_SUPPORT
-
(unless WITH_KERBEROS_SUPPORT is set - explicitly)
-
-
-
WITHOUT_KERBEROS_SUPPORT
-
Build some programs without Kerberos support, like - ssh(1), telnet(1), and - sshd(8).
-
WITH_KERNEL_BIN
-
Generate and install kernel.bin from kernel as part of the normal build - and install processes for the kernel. Available only on arm and arm64. -

Usually this will be added to the kernel config file with:

-

makeoptions WITH_KERNEL_BIN=1

-

though it can also be used on the command line.

-
-
WITH_KERNEL_RETPOLINE
-
Enable the "retpoline" mitigation for CVE-2017-5715 in the - kernel build.
-
WITHOUT_KERNEL_SYMBOLS
-
Do not install standalone kernel debug symbol files. This option has no - effect at build time.
-
WITHOUT_KVM
-
Do not build the libkvm library as a part of the - base system. -
The option has no effect yet.
- When set, these options are also in effect: -

-
-
WITHOUT_KVM_SUPPORT
-
(unless WITH_KVM_SUPPORT is set explicitly)
-
-
-
WITHOUT_KVM_SUPPORT
-
Build some programs without optional libkvm - support.
-
WITHOUT_LDNS
-
Setting this variable will prevent the LDNS library from being built. When - set, it enforces these options: -

-
    -
  • WITHOUT_LDNS_UTILS
    • -
  • WITHOUT_UNBOUND
    • -
-
-
WITHOUT_LDNS_UTILS
-
Setting this variable will prevent building the LDNS utilities - drill(1) and host(1).
-
WITHOUT_LEGACY_CONSOLE
-
Do not build programs that support a legacy PC console; e.g., - kbdcontrol(1) and vidcontrol(1).
-
WITHOUT_LIB32
-
On 64-bit platforms, do not build 32-bit library set and a - ld-elf32.so.1 runtime linker. -

This is a default setting on arm/armv7, i386/i386, - powerpc/powerpc64le and riscv/riscv64.

-
-
WITH_LIB32
-
On 64-bit platforms, build the 32-bit library set and a - ld-elf32.so.1 runtime linker. -

This is a default setting on amd64/amd64, arm64/aarch64 and - powerpc/powerpc64.

-
-
WITHOUT_LLD
-
Do not build LLVM's lld linker.
-
WITHOUT_LLDB
-
Do not build the LLDB debugger. -

This is a default setting on riscv/riscv64.

-
-
WITH_LLDB
-
Build the LLDB debugger. -

This is a default setting on amd64/amd64, arm/armv7, - arm64/aarch64, i386/i386, powerpc/powerpc64 and powerpc/powerpc64le.

-
-
WITHOUT_LLD_BOOTSTRAP
-
Do not build the LLD linker during the bootstrap phase of the build. To be - able to build the system an alternate linker must be provided via - XLD.
-
WITHOUT_LLVM_ASSERTIONS
-
Disable debugging assertions in LLVM.
-
WITHOUT_LLVM_BINUTILS
-
Install ELF Tool Chain's binary utilities instead of LLVM's. This includes - addr2line(1), ar(1), - nm(1), objcopy(1), - ranlib(1), readelf(1), - size(1), and strip(1). Regardless of - this setting, LLVM tools are used for c++filt(1) and - objdump(1). strings(1) is always - provided by ELF Tool Chain.
-
WITHOUT_LLVM_BINUTILS_BOOTSTRAP
-
Do not build LLVM binary utilities during the bootstrap phase of the - build. To be able to build the system alternate binary utilities must be - provided via XAR, XNM, - XOBJCOPY, XSIZE, - XSTRINGS, and XSTRIPBIN. -

-
-
WITHOUT_LLVM_COV
-
Do not build the llvm-cov(1) tool.
-
WITH_LLVM_FULL_DEBUGINFO
-
Generate full debug information for LLVM libraries and tools, which uses - more disk space and build resources, but allows for easier debugging.
- -
Link LLVM libraries (libllvm, libclang, liblldb) statically into each of - the binaries that use them. -

This means that binaries linked against these libraries, such - as clang, ld.lld and lldb will be much larger and position dependent, - but will start more quickly.

-
-
WITHOUT_LLVM_TARGET_AARCH64
-
Do not build LLVM target support for AArch64. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITHOUT_LLVM_TARGET_ALL
-
Only build the required LLVM target support. This option is preferred to - specific target support options. When set, these options are also in - effect: -

-
-
WITHOUT_LLVM_TARGET_AARCH64
-
(unless WITH_LLVM_TARGET_AARCH64 is set - explicitly)
-
WITHOUT_LLVM_TARGET_ARM
-
(unless WITH_LLVM_TARGET_ARM is set - explicitly)
-
WITHOUT_LLVM_TARGET_POWERPC
-
(unless WITH_LLVM_TARGET_POWERPC is set - explicitly)
-
WITHOUT_LLVM_TARGET_RISCV
-
(unless WITH_LLVM_TARGET_RISCV is set - explicitly)
-
-
-
WITHOUT_LLVM_TARGET_ARM
-
Do not build LLVM target support for ARM. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITH_LLVM_TARGET_BPF
-
Build LLVM target support for BPF. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITH_LLVM_TARGET_MIPS
-
Build LLVM target support for MIPS. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITHOUT_LLVM_TARGET_POWERPC
-
Do not build LLVM target support for PowerPC. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITHOUT_LLVM_TARGET_RISCV
-
Do not build LLVM target support for RISC-V. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITHOUT_LLVM_TARGET_X86
-
Do not build LLVM target support for X86. The - LLVM_TARGET_ALL option should be used rather than - this in most cases.
-
WITHOUT_LOADER_BIOS_TEXTONLY
-
Include graphics, font and video mode support in the i386 and amd64 BIOS - boot loader.
-
WITH_LOADER_EFI_SECUREBOOT
-
Enable building loader(8) with support for verification - based on certificates obtained from UEFI.
-
WITHOUT_LOADER_GELI
-
Disable inclusion of GELI crypto support in the boot chain binaries. -

This is a default setting on powerpc/powerpc64 and - powerpc/powerpc64le.

-
-
WITH_LOADER_GELI
-
Build GELI bootloader support. -

This is a default setting on amd64/amd64, arm/armv7, - arm64/aarch64, i386/i386 and riscv/riscv64.

-
-
WITHOUT_LOADER_IA32
-
Do not build the 32-bit UEFI loader. -

This is a default setting on arm/armv7, arm64/aarch64, - i386/i386, powerpc/powerpc64, powerpc/powerpc64le and riscv/riscv64.

-
-
WITH_LOADER_IA32
-
Build the 32-bit UEFI loader. -

This is a default setting on amd64/amd64.

-
-
WITHOUT_LOADER_KBOOT
-
Do not build kboot, a linuxboot environment loader -

This is a default setting on arm/armv7, i386/i386, - powerpc/powerpc64le and riscv/riscv64.

-
-
WITH_LOADER_KBOOT
-
Build kboot, a linuxboot environment loader -

This is a default setting on amd64/amd64, arm64/aarch64 and - powerpc/powerpc64.

-
-
WITHOUT_LOADER_LUA
-
Do not build LUA bindings for the boot loader. -

This is a default setting on powerpc/powerpc64 and - powerpc/powerpc64le.

-
-
WITH_LOADER_LUA
-
Build LUA bindings for the boot loader. -

This is a default setting on amd64/amd64, arm/armv7, - arm64/aarch64, i386/i386 and riscv/riscv64.

-
-
WITHOUT_LOADER_OFW
-
Disable building of openfirmware bootloader components. -

This is a default setting on amd64/amd64, arm/armv7, - arm64/aarch64, i386/i386 and riscv/riscv64.

-
-
WITH_LOADER_OFW
-
Build openfirmware bootloader components. -

This is a default setting on powerpc/powerpc64 and - powerpc/powerpc64le.

-
-
WITHOUT_LOADER_PXEBOOT
-
Do not build pxeboot on i386/amd64. When the pxeboot is too large, or - unneeded, it may be disabled with this option. See - WITH_LOADER_PXEBOOT for how to adjust the defaults - when you need both a larger /boot/loader and - /boot/pxeboot -

This option only has an effect on x86.

-
-
WITHOUT_LOADER_UBOOT
-
Disable building of ubldr. -

This is a default setting on amd64/amd64, arm64/aarch64, - i386/i386, powerpc/powerpc64le and riscv/riscv64.

-
-
WITH_LOADER_UBOOT
-
Build ubldr. -

This is a default setting on arm/armv7 and - powerpc/powerpc64.

-
-
WITH_LOADER_USB
-
Build the usb/kshim library -

-
-
WITH_LOADER_VERBOSE
-
Build with extra verbose debugging in the loader. May explode already - nearly too large loader over the limit. Use with care.
-
WITH_LOADER_VERIEXEC
-
Enable building loader(8) with support for verification - similar to Verified Exec. -

Depends on WITH_BEARSSL. May require a - larger LOADERSIZE. When set, these options are - also in effect:

-

-
-
WITH_LOADER_EFI_SECUREBOOT
-
(unless WITHOUT_LOADER_EFI_SECUREBOOT is set - explicitly)
-
WITH_LOADER_VERIEXEC_VECTX
-
(unless WITHOUT_LOADER_VERIEXEC_VECTX is set - explicitly)
-
-
-
WITH_LOADER_VERIEXEC_PASS_MANIFEST
-
Enable building loader(8) with support to pass a - verified manifest to the kernel. The kernel has to be built with a module - to parse the manifest. -

Depends on WITH_LOADER_VERIEXEC.

-
-
WITH_LOADER_VERIEXEC_VECTX
-
Enable building loader(8) with support for hashing and - verifying kernel and modules as a side effect of loading. -

Depends on WITH_LOADER_VERIEXEC.

-
-
WITHOUT_LOADER_ZFS
-
Do not build ZFS file system boot loader support.
-
WITHOUT_LOCALES
-
Do not build localization files; see locale(1).
-
WITHOUT_LOCATE
-
Do not build locate(1) and related programs.
-
WITHOUT_LPR
-
Do not build lpr(1) and related programs.
-
WITHOUT_LS_COLORS
-
Build ls(1) without support for colors to distinguish - file types.
-
WITHOUT_MACHDEP_OPTIMIZATIONS
-
Prefer machine-independent non-assembler code in libc and libm.
-
WITHOUT_MAIL
-
Do not build any mail support (MUA or MTA). When set, it enforces these - options: -

-
    -
  • WITHOUT_DMAGENT
    • -
  • WITHOUT_MAILWRAPPER
    • -
  • WITHOUT_SENDMAIL
    • -
-
-
WITHOUT_MAILWRAPPER
-
Do not build the mailwrapper(8) MTA selector.
-
WITHOUT_MAKE
-
Do not install make(1) and related support files.
-
WITHOUT_MAKE_CHECK_USE_SANDBOX
-
Do not execute “make check” in - limited sandbox mode. This option should be paired with - WITH_INSTALL_AS_USER if executed as an unprivileged - user. See tests(7) for more details.
-
WITH_MALLOC_PRODUCTION
-
Disable assertions and statistics gathering in - malloc(3). The run-time options - opt.abort, opt.abort_conf, - and opt.junk also default to false.
-
WITHOUT_MAN
-
Do not build manual pages. When set, these options are also in effect: -

-
-
WITHOUT_MAN_UTILS
-
(unless WITH_MAN_UTILS is set explicitly)
-
-
-
WITHOUT_MANCOMPRESS
-
Do not install compressed man pages. Only the uncompressed versions will - be installed.
-
WITH_MANSPLITPKG
-
Split man pages into their own packages during make package.
-
WITHOUT_MAN_UTILS
-
Do not build utilities for manual pages, apropos(1), - makewhatis(1), man(1), - whatis(1), manctl(8), and related - support files.
-
WITH_META_ERROR_TARGET
-
Enable the META_MODE .ERROR target. -

This target will copy the meta file of a failed target to - ERROR_LOGDIR (default is - ‘${SRCTOP:H}/error’) to help with - failure analysis. Depends on WITH_META_MODE. This - default when WITH_DIRDEPS_BUILD is set.

-

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITH_META_MODE
-
Create make(1) meta files when building, which can - provide a reliable incremental build when using - filemon(4). The meta file is created in OBJDIR as - target.meta. These meta files track the command - that was executed, its output, and the current directory. The - filemon(4) module is required unless - NO_FILEMON is defined. When the module is loaded, - any files used by the commands executed are tracked as dependencies for - the target in its meta file. The target is considered out-of-date and - rebuilt if any of these conditions are true compared to the last build: -
    -
  • The command to execute changes.
    • -
  • The current working directory changes.
    • -
  • The target's meta file is missing.
    • -
  • The target's meta file is missing filemon data when filemon is loaded - and a previous run did not have it loaded.
    • -
  • [requires filemon(4)] Files read, executed or linked - to are newer than the target.
    • -
  • [requires filemon(4)] Files read, written, executed - or linked are missing.
    • -
- The meta files can also be useful for debugging. -

The build hides commands that are executed unless - NO_SILENT is defined. Errors cause - make(1) to show some of its environment for further - debugging.

-

The build operates as it normally would otherwise. This option - originally invoked a different build system but that was renamed to - WITH_DIRDEPS_BUILD.

-

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITHOUT_MITKRB5
-
Set this to build KTH Heimdal instead of MIT Kerberos 5.
-
WITHOUT_MLX5TOOL
-
Do not build mlx5tool(8) -

This is a default setting on arm/armv7 and riscv/riscv64.

-
-
WITH_MLX5TOOL
-
Build mlx5tool(8) -

This is a default setting on amd64/amd64, arm64/aarch64, - i386/i386, powerpc/powerpc64 and powerpc/powerpc64le.

-
-
WITHOUT_NETCAT
-
Do not build nc(1) utility.
-
WITHOUT_NETGRAPH
-
Do not build applications to support netgraph(4). When - set, it enforces these options: -

-
    -
  • WITHOUT_BLUETOOTH
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_NETGRAPH_SUPPORT
-
(unless WITH_NETGRAPH_SUPPORT is set - explicitly)
-
-
-
WITHOUT_NETGRAPH_SUPPORT
-
Build libraries, programs, and kernel modules without netgraph - support.
- -
Do not build genl(1) utility.
- -
Make libraries and programs use rtsock and sysctl(3) - interfaces instead of snl(3).
-
WITHOUT_NIS
-
Do not build NIS(8) support and related programs. If - set, you might need to adopt your nsswitch.conf(5) and - remove ‘nis’ entries.
-
WITHOUT_NLS
-
Do not build NLS catalogs. When set, it enforces these options: -

-
    -
  • WITHOUT_NLS_CATALOGS
    • -
-
-
WITHOUT_NLS_CATALOGS
-
Do not build NLS catalog support for csh(1).
-
WITHOUT_NS_CACHING
-
Disable name caching in the nsswitch subsystem. - The generic caching daemon, nscd(8), will not be built - either if this option is set.
-
WITHOUT_NTP
-
Do not build ntpd(8) and related programs.
-
WITHOUT_NUAGEINIT
-
Do not install the limited cloud init support scripts.
-
WITHOUT_OFED
-
Do not build the “OpenFabrics Enterprise Distribution” - InfiniBand software stack, including kernel modules and userspace - libraries. -

This is a default setting on arm/armv7. When set, it enforces - these options:

-

-
    -
  • WITHOUT_OFED_EXTRA
    • -
-
-
WITH_OFED
-
Build the “OpenFabrics Enterprise Distribution” InfiniBand - software stack, including kernel modules and userspace libraries. -

This is a default setting on amd64/amd64, arm64/aarch64, - i386/i386, powerpc/powerpc64, powerpc/powerpc64le and riscv/riscv64.

-
-
WITH_OFED_EXTRA
-
Build the non-essential components of the “OpenFabrics Enterprise - Distribution” Infiniband software stack, mostly examples.
-
WITH_OPENLDAP
-
Enable building LDAP support for kerberos using an openldap client from - ports.
-
WITHOUT_OPENMP
-
Do not build LLVM's OpenMP runtime. -

This is a default setting on arm/armv7.

-
-
WITH_OPENMP
-
Build LLVM's OpenMP runtime. -

This is a default setting on amd64/amd64, arm64/aarch64, - i386/i386, powerpc/powerpc64, powerpc/powerpc64le and riscv/riscv64.

-
-
WITHOUT_OPENSSH
-
Do not build OpenSSH.
-
WITHOUT_OPENSSL
-
Do not build OpenSSL. When set, it enforces these options: -

-
    -
  • WITHOUT_DMAGENT
    • -
  • WITHOUT_KERBEROS
    • -
  • WITHOUT_LDNS
    • -
  • WITHOUT_LDNS_UTILS
    • -
  • WITHOUT_LOADER_ZFS
    • -
  • WITHOUT_MITKRB5
    • -
  • WITHOUT_OPENSSH
    • -
  • WITHOUT_OPENSSL_KTLS
    • -
  • WITHOUT_PKGBOOTSTRAP
    • -
  • WITHOUT_UNBOUND
    • -
  • WITHOUT_ZFS
    • -
  • WITHOUT_ZFS_TESTS
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_KERBEROS_SUPPORT
-
(unless WITH_KERBEROS_SUPPORT is set - explicitly)
-
-
-
WITHOUT_OPENSSL_KTLS
-
Do not include kernel TLS support in OpenSSL. -

This is a default setting on arm/armv7, i386/i386 and - riscv/riscv64.

-
-
WITH_OPENSSL_KTLS
-
Include kernel TLS support in OpenSSL. -

This is a default setting on amd64/amd64, arm64/aarch64, - powerpc/powerpc64 and powerpc/powerpc64le.

-
-
WITHOUT_PAM
-
Do not build PAM library and modules. -
This option is deprecated and does nothing.
- When set, these options are also in effect: -

-
-
WITHOUT_PAM_SUPPORT
-
(unless WITH_PAM_SUPPORT is set explicitly)
-
-
-
WITHOUT_PAM_SUPPORT
-
Build ppp(8) without PAM support.
-
WITHOUT_PF
-
Do not build PF firewall package. When set, it enforces these options: -

-
    -
  • WITHOUT_AUTHPF
    • -
-
-
WITHOUT_PIE
-
Do not build dynamically linked binaries as Position-Independent - Executable (PIE). -

This is a default setting on arm/armv7 and i386/i386.

-
-
WITH_PIE
-
Build dynamically linked binaries as Position-Independent Executable - (PIE). -

This is a default setting on amd64/amd64, arm64/aarch64, - powerpc/powerpc64, powerpc/powerpc64le and riscv/riscv64.

-
-
WITHOUT_PKGBOOTSTRAP
-
Do not build pkg(7) bootstrap tool.
-
WITHOUT_PKGCONF
-
Do not build the pkgconf binaries nor the libpkgconf library.
-
WITHOUT_PKGSERVE
-
Do not build or install pkg-serve(8).
-
WITHOUT_PMC
-
Do not build pmccontrol(8) and related programs.
-
WITHOUT_PPP
-
Do not build ppp(8) and related programs.
-
WITHOUT_PTHREADS_ASSERTIONS
-
Disable debugging assertions in pthreads library.
-
WITHOUT_QUOTAS
-
Do not build quota(1) and related programs.
-
WITHOUT_RADIUS_SUPPORT
-
Do not build radius support into various applications, like - pam_radius(8) and ppp(8).
-
WITH_RATELIMIT
-
Build the system with rate limit support. -

This makes SO_MAX_PACING_RATE - effective in getsockopt(2), and - txrlimit support in ifconfig(8), - by proxy.

-
-
WITHOUT_RBOOTD
-
Do not build or install rbootd(8).
-
WITHOUT_RELRO
-
Do not apply the Relocation Read-Only (RELRO) vulnerability mitigation. - See also the BIND_NOW option.
-
WITH_REPRODUCIBLE_BUILD
-
Exclude build metadata (such as the build time, user, or host) from the - kernel, boot loaders, and uname(1) output, so that - builds produce bit-for-bit identical output.
-
WITH_REPRODUCIBLE_PATHS
-
Modify the paths encoded in binary artifacts to be standard path -

Normally, the actual path is encoded in the binary. However, - this makes the build differ depending on the path it was built from. - With this option enabled, the paths recorded are /usr/src, regardless of - the actual path. With this option disabled, the actual paths are - recorded.

-
-
WITHOUT_RESCUE
-
Do not build rescue(8).
-
WITH_RETPOLINE
-
Build the base system with the retpoline speculative execution - vulnerability mitigation for CVE-2017-5715.
-
WITHOUT_ROUTED
-
Do not build routed(8) utility.
-
WITH_RPCBIND_WARMSTART_SUPPORT
-
Build rpcbind(8) with warmstart support.
-
WITH_RUN_TESTS
-
Run tests as part of the build.
-
WITHOUT_SCTP_SUPPORT
-
Disable support in the kernel for the sctp(4) Stream - Control Transmission Protocol loadable kernel module.
-
WITHOUT_SENDMAIL
-
Do not build sendmail(8) and related programs.
-
WITHOUT_SERVICESDB
-
Do not install /var/db/services.db.
-
WITHOUT_SETUID_LOGIN
-
Set this to disable the installation of login(1) as a - set-user-ID root program.
-
WITHOUT_SHAREDOCS
-
Do not build the 4.4BSD legacy docs.
-
WITH_SORT_THREADS
-
Enable threads in sort(1).
-
WITHOUT_SOUND
-
Do not build userland sound utilities such as beep(1) - and mixer(8).
-
WITHOUT_SOURCELESS
-
Do not build kernel modules that include sourceless code (either microcode - or native code for host CPU). When set, it enforces these options: -

-
    -
  • WITHOUT_SOURCELESS_HOST
    • -
  • WITHOUT_SOURCELESS_UCODE
    • -
-
-
WITHOUT_SOURCELESS_HOST
-
Do not build kernel modules that include sourceless native code for host - CPU.
-
WITHOUT_SOURCELESS_UCODE
-
Do not build kernel modules that include sourceless microcode.
-
WITHOUT_SPLIT_KERNEL_DEBUG
-
Do not build standalone kernel debug files. Debug data (if enabled by the - kernel configuration file) will be included in the kernel and modules. - When set, it enforces these options: -

-
    -
  • WITHOUT_KERNEL_SYMBOLS
    • -
-
-
WITHOUT_SSP
-
Do not build world with stack smashing protection. See - mitigations(7) for more information.
-
WITH_STAGING
-
Enable staging of files to a stage tree. This can be best thought of as - auto-install to DESTDIR with some extra meta data to - ensure dependencies can be tracked. Depends on - WITH_DIRDEPS_BUILD. When set, these options are also - in effect: -

-
-
WITH_STAGING_MAN
-
(unless WITHOUT_STAGING_MAN is set - explicitly)
-
WITH_STAGING_PROG
-
(unless WITHOUT_STAGING_PROG is set - explicitly)
-
-

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITH_STAGING_MAN
-
Enable staging of man pages to stage tree.
-
WITH_STAGING_PROG
-
Enable staging of PROGs to stage tree.
-
WITH_STALE_STAGED
-
Check staged files are not stale.
-
WITHOUT_STATS
-
Neither build nor install library - “libstats” and dependent binaries.
-
WITHOUT_SYSCONS
-
Do not build syscons(4) support files such as keyboard - maps, fonts, and screen output maps.
-
WITH_SYSROOT
-
Enable use of sysroot during build. Depends on - WITH_DIRDEPS_BUILD. -

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITHOUT_SYSTEM_COMPILER
-
Do not opportunistically skip building a cross-compiler during the - bootstrap phase of the build. Normally, if the currently installed - compiler matches the planned bootstrap compiler type and revision, then it - will not be built. This does not prevent a compiler from being built for - installation though, only for building one for the build itself. The - WITHOUT_CLANG option controls that.
-
WITHOUT_SYSTEM_LINKER
-
Do not opportunistically skip building a cross-linker during the bootstrap - phase of the build. Normally, if the currently installed linker matches - the planned bootstrap linker type and revision, then it will not be built. - This does not prevent a linker from being built for installation though, - only for building one for the build itself. The - WITHOUT_LLD option controls that. -

This option is only relevant when - WITH_LLD_BOOTSTRAP is set.

-
-
WITHOUT_TALK
-
Do not build or install talk(1) and - talkd(8).
-
WITHOUT_TCP_WRAPPERS
-
Do not build or install tcpd(8), and related - utilities.
-
WITHOUT_TCSH
-
Do not build and install /bin/csh (which is - tcsh(1)).
-
WITHOUT_TELNET
-
Do not build telnet(1) and related programs.
-
WITHOUT_TESTS
-
Do not build nor install the FreeBSD Test Suite in - /usr/tests/. See tests(7) for - more details. This also disables the build of all test-related - dependencies, including ATF. When set, it enforces these options: -

-
    -
  • WITHOUT_DTRACE_TESTS
    • -
  • WITHOUT_ZFS_TESTS
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_GOOGLETEST
-
(unless WITH_GOOGLETEST is set explicitly)
-
WITHOUT_TESTS_SUPPORT
-
(unless WITH_TESTS_SUPPORT is set - explicitly)
-
-
-
WITHOUT_TESTS_SUPPORT
-
Disable the build of all test-related dependencies, including ATF. When - set, it enforces these options: -

-
    -
  • WITHOUT_GOOGLETEST
    • -
-
-
WITHOUT_TEXTPROC
-
Do not build programs used for text processing.
-
WITHOUT_TFTP
-
Do not build or install tftp(1) and - tftpd(8).
-
WITHOUT_TOOLCHAIN
-
Do not install programs used for program development, compilers, debuggers - etc. When set, it enforces these options: -

-
    -
  • WITHOUT_CLANG
    • -
  • WITHOUT_CLANG_EXTRAS
    • -
  • WITHOUT_CLANG_FORMAT
    • -
  • WITHOUT_CLANG_FULL
    • -
  • WITHOUT_LLD
    • -
  • WITHOUT_LLDB
    • -
  • WITHOUT_LLVM_COV
    • -
-

When set, these options are also in effect:

-

-
-
WITHOUT_LLVM_BINUTILS
-
(unless WITH_LLVM_BINUTILS is set - explicitly)
-
-
-
WITH_UBSAN
-
Build the base system with Undefined Behavior Sanitizer (UBSan) to detect - various kinds of undefined behavior at runtime. Requires that Clang be - used as the base system compiler and that the runtime support library is - available
-
WITHOUT_UNBOUND
-
Do not build unbound(8) and related programs.
-
WITH_UNDEFINED_VERSION
-
Link libraries with --undefined-version which permits version maps to - contain symbols that are not present in the library. If this is necessary - to build a particular configuration, a bug is present and the - configuration should be reported.
-
WITHOUT_UNIFIED_OBJDIR
-
Use the historical object directory format for build(7) - targets. For native-builds and builds done directly in sub-directories the - format of ${MAKEOBJDIRPREFIX}/${.CURDIR} is used, - while for cross-builds - ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/${.CURDIR} - is used. -

This option is transitional and will be removed in a future - version of FreeBSD, at which time - WITH_UNIFIED_OBJDIR will be enabled - permanently.

-

This must be set in the environment, make command line, or - /etc/src-env.conf, not - /etc/src.conf.

-
-
WITHOUT_USB
-
Do not build USB-related programs and libraries. When set, it enforces - these options: -

-
    -
  • WITHOUT_USB_GADGET_EXAMPLES
    • -
-
-
WITHOUT_USB_GADGET_EXAMPLES
-
Do not build USB gadget kernel modules.
-
WITHOUT_UTMPX
-
Do not build user accounting tools such as last(1), - users(1), who(1), - ac(8), lastlogin(8) and - utx(8).
-
WITH_VERIEXEC
-
Enable building veriexec(8) which loads the contents of - verified manifests into the kernel for use by - mac_veriexec(4) -

Depends on WITH_BEARSSL.

-
-
WITHOUT_VI
-
Do not build and install vi, view, ex and related programs.
-
WITHOUT_VT
-
Do not build vt(4) support files (fonts and - keymaps).
-
WITHOUT_WARNS
-
Set this to not add warning flags to the compiler invocations. Useful as a - temporary workaround when code enters the tree which triggers warnings in - environments that differ from the original developer.
-
WITHOUT_WERROR
-
Set this to not treat compiler warnings as errors. Useful as a temporary - workaround when working on fixing compiler warnings. When set, warnings - are still printed in the build log but do not fail the build.
-
WITHOUT_WIRELESS
-
Do not build programs used for 802.11 wireless networks; especially - wpa_supplicant(8) and hostapd(8). When - set, these options are also in effect: -

-
-
WITHOUT_WIRELESS_SUPPORT
-
(unless WITH_WIRELESS_SUPPORT is set - explicitly)
-
-
-
WITHOUT_WIRELESS_SUPPORT
-
Build libraries, programs, and kernel modules without 802.11 wireless - support.
-
WITHOUT_WPA_SUPPLICANT_EAPOL
-
Build wpa_supplicant(8) without support for the IEEE - 802.1X protocol and without support for EAP-PEAP, EAP-TLS, EAP-LEAP, and - EAP-TTLS protocols (usable only via 802.1X).
-
WITH_ZEROREGS
-
Build the basesystem with code to zero caller-used register contents on - function return. This prevents leaking temporary values for side channel - attacks. Additionally this reduces the number of usable ROP gadgets for - attackers.
-
WITHOUT_ZFS
-
Do not build the ZFS file system kernel module, libraries such as - libbe(3), and user commands such as - zpool(8) or zfs(8). Also disable ZFS - support in utilities and libraries which implement ZFS-specific - functionality. When set, it enforces these options: -

-
    -
  • WITHOUT_ZFS_TESTS
    • -
-
-
WITHOUT_ZFS_TESTS
-
Do not build and install the legacy ZFS test suite.
-
WITHOUT_ZONEINFO
-
Do not build the timezone database. When set, it enforces these options: -

-
    -
  • WITHOUT_ZONEINFO_LEAPSECONDS_SUPPORT
    • -
-
-
WITH_ZONEINFO_LEAPSECONDS_SUPPORT
-
Build leapsecond information in to the timezone database. This option - violates IEEE Std 1003.1 (“POSIX.1”) - and all other applicable standards, and is known to cause unexpected - issues with date/time handling in many applications and programming - languages.
-
-

The following options accept a single value from a list of valid - values.

-
-
INIT_ALL
-
Control default initialization of stack variables in C and C++ code. - Options other than none require the Clang compiler - or GCC 12.0 or later. The default value is none. - Valid values are: -
-
-
Do not initialize stack variables (standard C/C++ behavior).
-
-
Build the base system or kernel with stack variables initialized to - (compiler defined) debugging patterns on function entry.
-
-
Build the base system or kernel with stack variables initialized to - zero on function entry. This value is converted to - none for amd64 kernel builds due to - incompatibility with ifunc memset.
-
-
-
LIBC_MALLOC
-
Specify the malloc(3) implementation used by libc. The - default value is jemalloc. Valid values are: -
-
-
 
-
-

Other implementations are expected in the future in both - FreeBSD and downstream consumers.

-
-
-
-
-

-
-
/etc/src.conf
-
 
-
/etc/src-env.conf
-
 
-
/usr/share/mk/bsd.own.mk
-
 
-
-
-
-

-

make(1), make.conf(5), - build(7), ports(7)

-
-
-

-

The src.conf file appeared in - FreeBSD 7.0.

-
-
-

-

This manual page was autogenerated by - tools/build/options/makeman.

-
-
- - - - - -
April 22, 2026FreeBSD 15.0
diff --git a/static/freebsd/man5/stab.5 3.html b/static/freebsd/man5/stab.5 3.html deleted file mode 100644 index 2e5d2d2d..00000000 --- a/static/freebsd/man5/stab.5 3.html +++ /dev/null @@ -1,163 +0,0 @@ - - - - - - -
STAB(5)File Formats ManualSTAB(5)
-
-
-

-

stab — symbol - table types

-
-
-

-

#include - <stab.h>

-
-
-

-

The file <stab.h> - defines some of the symbol table n_type field values - for a.out files. These are the types for permanent symbols (i.e., not local - labels, etc.) used by the old debugger sdb and the - Berkeley Pascal compiler pc(1). Symbol table entries can - be produced by the .stabs assembler directive. This - allows one to specify a double-quote delimited name, a symbol type, one char - and one short of information about the symbol, and an unsigned long (usually - an address). To avoid having to produce an explicit label for the address - field, the .stabd directive can be used to - implicitly address the current location. If no name is needed, symbol table - entries can be generated using the .stabn directive. - The loader promises to preserve the order of symbol table entries produced - by .stab directives. As described in - a.out(5), an element of the symbol table consists of the - following structure:

-
-
/*
-* Format of a symbol table entry.
-*/
-
-struct nlist {
-	union {
-		const char *n_name;	/* for use when in-core */
-		long	n_strx;		/* index into file string table */
-	} n_un;
-	unsigned char	n_type;		/* type flag */
-	char		n_other;	/* unused */
-	short		n_desc;		/* see struct desc, below */
-	unsigned	n_value;	/* address or offset or line */
-};
-
-

The low bits of the n_type field are used to - place a symbol into at most one segment, according to the following masks, - defined in <a.out.h>. A - symbol can be in none of these segments by having none of these segment bits - set.

-
-
/*
-* Simple values for n_type.
-*/
-
-#define	N_UNDF	0x0	/* undefined */
-#define	N_ABS	0x2	/* absolute */
-#define	N_TEXT	0x4	/* text */
-#define	N_DATA	0x6	/* data */
-#define	N_BSS	0x8	/* bss */
-
-#define	N_EXT	01	/* external bit, or'ed in */
-
-

The n_value field of a symbol is relocated - by the linker, ld(1) as an address within the appropriate - segment. N_value fields of symbols not in any segment - are unchanged by the linker. In addition, the linker will discard certain - symbols, according to rules of its own, unless the - n_type field has one of the following bits set:

-
-
/*
-* Other permanent symbol table entries have some of the N_STAB bits set.
-* These are given in <stab.h>
-*/
-
-#define	N_STAB	0xe0	/* if any of these bits set, don't discard */
-
-

This allows up to 112 (7 ∗ 16) symbol types, split between - the various segments. Some of these have already been claimed. The old - symbolic debugger, sdb, uses the following n_type - values:

-
-
#define	N_GSYM	0x20	/* global symbol: name,,0,type,0 */
-#define	N_FNAME	0x22	/* procedure name (f77 kludge): name,,0 */
-#define	N_FUN	0x24	/* procedure: name,,0,linenumber,address */
-#define	N_STSYM	0x26	/* static symbol: name,,0,type,address */
-#define	N_LCSYM	0x28	/* .lcomm symbol: name,,0,type,address */
-#define	N_RSYM	0x40	/* register sym: name,,0,type,register */
-#define	N_SLINE	0x44	/* src line: 0,,0,linenumber,address */
-#define	N_SSYM	0x60	/* structure elt: name,,0,type,struct_offset */
-#define	N_SO	0x64	/* source file name: name,,0,0,address */
-#define	N_LSYM	0x80	/* local sym: name,,0,type,offset */
-#define	N_SOL	0x84	/* #included file name: name,,0,0,address */
-#define	N_PSYM	0xa0	/* parameter: name,,0,type,offset */
-#define	N_ENTRY	0xa4	/* alternate entry: name,linenumber,address */
-#define	N_LBRAC	0xc0	/* left bracket: 0,,0,nesting level,address */
-#define	N_RBRAC	0xe0	/* right bracket: 0,,0,nesting level,address */
-#define	N_BCOMM	0xe2	/* begin common: name,, */
-#define	N_ECOMM	0xe4	/* end common: name,, */
-#define	N_ECOML	0xe8	/* end common (local name): ,,address */
-#define	N_LENG	0xfe	/* second stab entry with length information */
-
-

where the comments give sdb - conventional use for .stab s - and the n_name, n_other, - n_desc, and n_value fields of - the given n_type. - uses the - n_desc field to hold a type specifier in the form used - by the Portable C Compiler, cc(1); see the header file - pcc.h for details on the format of these type - values.

-

The Berkeley Pascal compiler, pc(1), uses the - following n_type value:

-
-
#define	N_PC	0x30	/* global pascal symbol: name,,0,subtype,line */
-
-

and uses the following subtypes to do type checking across - separately compiled files:

-
-
1	source file name
-2	included file name
-3	global label
-4	global constant
-5	global type
-6	global variable
-7	global function
-8	global procedure
-9	external function
-10	external procedure
-11	library variable
-12	library routine
-
-
-
-

-

as(1), ld(1), - a.out(5)

-
-
-

-

The stab file appeared in - 4.0BSD.

-
-
-

-

More basic types are needed.

-
-
- - - - - -
June 10, 2010FreeBSD 15.0
diff --git a/static/freebsd/man5/style.Makefile.5 3.html b/static/freebsd/man5/style.Makefile.5 3.html deleted file mode 100644 index 6d8336bc..00000000 --- a/static/freebsd/man5/style.Makefile.5 3.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
STYLE.MAKEFILE(5)File Formats ManualSTYLE.MAKEFILE(5)
-
-
-

-

style.Makefile — - FreeBSD Makefile style guide

-
-
-

-

This file specifies the preferred style for makefiles in the - FreeBSD source tree.

-
    -
  • : - comes first if needed, and is spelled “.PATH: - ”, with a single ASCII space after a colon. Do not use the - VPATH variable.
    • -
  • Special variables (i.e., LIB, - SRCS, MLINKS, etc.) are listed - in order of “product”, then building and installing a - binary. Special variables may also be listed in “build” - order: i.e., ones for the primary program (or library) first. The general - “product” order is: - PROG/[SH]LIB/SCRIPTS - FILES LINKS - MAN MLINKS - INCS SRCS - WARNS CSTD - CFLAGS DPADD - LDADD. The general “build” order is: - PROG/[SH]LIB/SCRIPTS - SRCS WARNS - CSTD CFLAGS - DPADD LDADD - INCS FILES - LINKS MAN - MLINKS.
    • -
  • Omit SRCS when using - <bsd.prog.mk> and there is - a single source file named the same as the - PROG.
    • -
  • Omit MAN when using - <bsd.prog.mk> and the - manual page is named the same as the PROG, and is in - section 1.
    • -
  • All variable assignments are spelled - “VAR=”, i.e., - no space between the variable name and the =. Keep - values sorted alphabetically, if possible.
    • -
  • Variables are expanded with - , not - . Such as - ${VARIABLE}.
    • -
  • Do not use += to set variables that are only set - once (or to set variables for the first time).
    • -
  • Do not use vertical whitespace in simple makefiles, but do use it to group - locally related things in more complex/longer ones.
    • -
  • WARNS comes before - CFLAGS, as it is basically a - CFLAGS modifier. It comes before - CFLAGS rather than after - CFLAGS so it does not get lost in a sea of - CFLAGS statements as WARNS is - an important thing. The usage of WARNS is spelled - “WARNS?= ”, so that it may be - overridden on the command line or in make.conf(5).
    • -
  • “MK_WERROR=no” should not be used, - it defeats the purpose of WARNS. It should only be - used on the command line and in special circumstances.
    • -
  • CFLAGS is spelled - “CFLAGS+= ”.
    • -
  • Listing -D's before -I's - in CFLAGS is preferred for alphabetical ordering and - to make -D's easier to see. The - -D's often affect conditional compilation, and - -I's tend to be quite long. Split long - CFLAGS settings between the - -D's and -I's.
    • -
  • Lists that span more than one line should be formatted as follows: -
    - 
    SRCS+=<SP>\
-<TAB>main.c<SP>\
-<TAB>trace.c<SP>\
-<TAB>zoo.c \
-
    -
    - Specifically, the last item in the list should have a trailing '\'. This is - to avoid causing a "false diff" or "false blame" when - a new item is appended at the end. In general the list should be English - language alphabetized. A list of libraries or header inclusion paths are - notable exceptions if needed for proper building.
    • -
  • Do not use GCCisms (such as -g and - -Wall) in CFLAGS.
    • -
  • Typically, there is one ASCII tab between - VAR= and the value in order - to start the value in column 9. An ASCII space is allowed for variable - names that extend beyond column 9. A lack of whitespace is also allowed - for very long variable names.
    • -
  • - <bsd.*.mk> goes last.
    • -
  • Do not use anachronisms like $< and - $@. Instead use ${.IMPSRC} or - ${.ALLSRC} and - ${.TARGET}.
    • -
  • To not build the “foo” part of the base system, use - NO_FOO, not NOFOO.
    • -
  • To optionally build something in the base system, spell the knob - WITH_FOO not WANT_FOO or - USE_FOO. The latter are reserved for the - FreeBSD Ports Collection.
    • -
  • For variables that are only checked with - (), - do not provide any fake value.
    • -
-
-
-

-

The simplest program Makefile is:

-
-
PROG=	foo
-
-.include <bsd.prog.mk>
-
-

The simplest library Makefile is:

-
-
LIB=	foo
-SHLIB_MAJOR= 1
-MAN=	libfoo.3
-SRCS=	foo.c
-
-.include <bsd.lib.mk>
-
-
-
-

-

make(1), make.conf(5), - style(9)

-
-
-

-

This manual page is inspired from the style(9) - manual page and first appeared in FreeBSD 5.1.

-
-
-

-

David O'Brien - ⟨deo@NUXI.org⟩

-
-
-

-

There are few hard and fast style rules here. The desire to - express a logical grouping sometimes means not obeying some of the above. - The style of many things is too dependent on the context of the whole - makefile, or the lines surrounding it.

-
-
- - - - - -
October 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man5/style.mdoc.5 3.html b/static/freebsd/man5/style.mdoc.5 3.html deleted file mode 100644 index c03dfb18..00000000 --- a/static/freebsd/man5/style.mdoc.5 3.html +++ /dev/null @@ -1,224 +0,0 @@ - - - - - - -
STYLE.MDOC(5)File Formats ManualSTYLE.MDOC(5)
-
-
-

-

style.mdoc — - FreeBSD manual page style guide

-
-
-

-

This file specifies the preferred style for manual pages in the - FreeBSD source tree.

-
-

-
    -
  • Use literal formatting for examples and literal shell commands, e.g.: -
    - 
    Then run
-.Ql make install clean .
    -
    -

    which renders as:

    -
    Then run ‘make install - clean’.
    -

    The incorrect way would be to use macros like - to stylize the - command invocation:

    -
    - 
    Then run
-.Ql Nm make Cm install Cm clean .
    -
    -

    which renders as:

    -
    Then run - ‘make - install - clean’.
    -
    • -
-
-
- -

Refer to style(9).

-
-
-

-

Driver manuals in section four should have a - HARDWARE section describing hardware - known to work with the driver. This section is drawn verbatim into the - Release Hardware Notes, therefore there are several things to note:

-
    -
  • The introductory sentence should be in the form: -
    - 
    The
-.Nm
-driver supports the following $device_class:
    -
    -

    Followed by the list of supported hardware.

    -

    This defines what driver the subsection is referring to, and - allows the reader to search through the Hardware Notes not only for the - device models they have, but also for the device type they are looking - to acquire.

    -
    • -
  • The supported hardware should be listed as a bullet list, or if complexity - requires, a column list. These two list types create very neat subsections - with clean starting and stopping points.
    • -
-
-
-

-
    -
  • Format the EXAMPLES section in the - following way: -
    - 
    .Bl -tag -width 0n
-.It Sy Example 1\&: Doing Something
-.Pp
-The following command does something.
-.Bd -literal -offset 2n
-.Ic # make -VLEGAL
-.Ed
-.It Sy Example 2\&: Doing Something Different
-.Pp
-The following command does something different.
-.Bd -literal -offset 2n
-.Ic # bectl list
-.Ed
-.Pp
-It is good to know this command.
-.El
    -
    -

    which renders as:

    -
    -
    -
    -

    The following command does something.

    -
    - 
    # make -VLEGAL
    -
    -
    -
    -
    -

    The following command does something different.

    -
    - 
    # bectl list
    -
    -

    It is good to know this command.

    -
    -
    -
    • -
-
-
-

-
    -
  • The -width argument to the - macro should - match the length of the longest rendered item in the list, e.g.: -
    - 
    .Bl -tag -width "-a address"
-.It Fl a Ar address
-Set the address.
-.It Fl v
-Print the version.
-.El
    -
    -

    In case the longest item is too long and hurts readability, - the recommendation is to set the -width argument - to ‘indent’, e.g.:

    -
    - 
    .Bl -tag -width "indent"
-.It Cm build
-Build the port.
-.It Cm install
-Install the port.
-.It Fl install-missing-packages
-Install the missing packages.
-.El
    -
    -
    • -
-
-
-

-
    -
  • Use the - (“”) macro for quoting. Use the - - (‘’) macro for quoting inside quotes. The use of the - - ("") macro is usually not necessary.
    • -
-
-
-

-
    -
  • Use Va instead of - for - sysctl(8) variables like - kdb.enter.panic.
    • -
  • Use the angle brackets - - (“⟨⟩”) macro for arguments - () when - they are mixed with similarly stylized macros like - or - Va, e.g.: -
    - 
    .Va critical_filesystems_ Ns Aq Ar type
    -
    -

    which renders as:

    -
    critical_filesystems_⟨type⟩
    -

    instead of:

    -
    - 
    .Va critical_filesystems_ Ns Ar type
    -
    -

    that would be rendered as:

    -
    critical_filesystems_type
    -
    • -
-
-
-
-

-
-
/usr/share/examples/mdoc/
-
Examples for writing manual pages.
-
-
-
-

-

man(1), mandoc(1), - mdoc(7), roff(7), - style(9)

-
-
-

-

This manual page first appeared in FreeBSD - 13.0.

-
-
-

-

Mateusz Piotrowski - <0mp@FreeBSD.org>

-
-
- - - - - -
February 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man5/sysctl.conf.5 4.html b/static/freebsd/man5/sysctl.conf.5 4.html deleted file mode 100644 index e4e4d498..00000000 --- a/static/freebsd/man5/sysctl.conf.5 4.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
SYSCTL.CONF(5)File Formats ManualSYSCTL.CONF(5)
-
-
-

-

sysctl.conf — - kernel state defaults

-
-
-

-

The /etc/sysctl.conf file is read in when - the system goes into multi-user mode to set default settings for the kernel. - The /etc/sysctl.conf file is in the format of the - sysctl(8) command, i.e.,

-
-
sysctl_mib=value
-
-

Comments are denoted by a “#” at the beginning of a - line. Comments can also exist at the end of a line, as seen in the - EXAMPLES section, below.

-

For kernel modules loaded via rc.subr(8) system, - additional module-specific settings can be applied by adding a file in the - same format named /etc/sysctl.kld.d/<modulename>.conf.

-
-
-

-
-
/etc/rc.d/sysctl
-
rc(8) script which processes - sysctl.conf early on in the process of - transitioning to multi-user mode.
-
/etc/rc.d/sysctl_lastload
-
rc(8) script which processes - sysctl.conf shortly before the system reaches the - multi-user mode.
-
/etc/sysctl.conf
-
Initial settings for sysctl(8).
-
/etc/sysctl.conf.local
-
Machine-specific settings for sites with a common - /etc/sysctl.conf.
-
/etc/sysctl.kld.d
-
Module specific settings for kernel modules loaded via - rc.subr(8).
-
-
-
-

-

To turn off logging of programs that exit due to fatal signals you - may use a configuration like

-
-
# Configure logging.
-kern.logsigexit=0	# Do not log fatal signal exits (e.g., sig 11)
-
-
-
-

-

rc.conf(5), rc(8), - sysctl(8)

-
-
-

-

The sysctl.conf file appeared in - FreeBSD 4.0.

-
-
-

-

If loadable kernel modules are used to introduce additional kernel - functionality and sysctls to manage that functionality, - sysctl.conf may be processed too early in the boot - process to set those sysctls. Please consult rcorder(8) to - learn more about the ordering of rc(8) scripts.

-
-
- - - - - -
June 30, 2022FreeBSD 15.0
diff --git a/static/freebsd/man6/intro.6 4.html b/static/freebsd/man6/intro.6 4.html deleted file mode 100644 index a4132734..00000000 --- a/static/freebsd/man6/intro.6 4.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
INTRO(6)Games ManualINTRO(6)
-
-
-

-

intro — - introduction to games

-
-
-

-

This section contains information about the traditional BSD games. - The games are located in /usr/bin if installed.

-
-
-

-
-
/usr/bin
-
location of games
-
-
-
-

-

intro(1), banner(6), - caesar(6), fortune(6), - grdc(6), morse(6), - number(6), pom(6), - random(6)

-
-
-

-

In earlier versions of FreeBSD, games were - located in /usr/games.

-

The intro section manual page appeared in - FreeBSD 2.2. Most of the games were moved into the - bsdgames port in FreeBSD 5.0.

-
-
- - - - - -
November 27, 2017FreeBSD 15.0
diff --git a/static/freebsd/man7/arch.7 3.html b/static/freebsd/man7/arch.7 3.html deleted file mode 100644 index 8172456e..00000000 --- a/static/freebsd/man7/arch.7 3.html +++ /dev/null @@ -1,967 +0,0 @@ - - - - - - -
ARCH(7)Miscellaneous Information ManualARCH(7)
-
-
-

-

arch — - Architecture-specific details

-
-
-

-

Differences between CPU architectures and platforms supported by - FreeBSD.

-
-

-

This document is a quick reference of key ABI details of - FreeBSD architecture ports. For full details consult - the processor-specific ABI supplement documentation.

-

If not explicitly mentioned, sizes are in bytes. The architecture - details in this document apply to FreeBSD 13.0 and - later, unless otherwise noted.

-

FreeBSD uses a flat address space. - Variables of types unsigned long, - ptraddr_t, and size_t have the - same representation.

-

In order to maximize compatibility with future pointer integrity - mechanisms, manipulations of pointers as integers should be performed via - uintptr_t or intptr_t and no - other types as these types are the only integer types where the C standard - guarantees that a pointer may be cast to it and then cast back to the - original type. On CHERI systems, uintptr_t and - intptr_t are defined as - __uintcap_t and __intcap_t which - represent capabilities that can be manipulated by integer operations. - Pointers should not be cast to long, - ptrdiff_t, or size_t if they - will later be cast back to a pointer that is expected to be dereferenceable - as they remain bare integer types on all architectures.

-

On some architectures, e.g., AIM variants of - powerpc64, the kernel uses a separate address space. - On other architectures, kernel and a user mode process share a single - address space. The kernel is located at the highest addresses.

-

On each architecture, the main user mode thread's stack starts - near the highest user address and grows down.

-

FreeBSD architecture support varies by - release. This table shows currently supported CPU architectures along with - the first FreeBSD release to support each - architecture.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
aarch6411.0
aarch64c16.0 (planned)
amd645.1
armv712.0
powerpc649.0
powerpc64le13.0
riscv6412.0
riscv64c16.0 (planned)
-

Discontinued architectures are shown in the following table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
alpha3.26.4
arm6.012.4
armeb8.011.4
armv610.014.x
ia645.010.4
i3861.014.x
mips8.013.5
mipsel9.013.5
mipselhf12.013.5
mipshf12.013.5
mipsn329.013.5
mips649.013.5
mips64el9.013.5
mips64elhf12.013.5
mips64hf12.013.5
pc982.211.4
powerpc6.014.x
powerpcspe12.014.x
riscv64sf12.013.5
sparc645.012.4
-
-
-

-

All FreeBSD architectures use some variant - of the ELF (see elf(5)) - (ABI) for the machine processor. Supported ABIs can - be divided into three main groups:

-
-
-
int, intptr_t, - long, and void * types machine - representations all have 4-byte size.
-
-
int type machine representation uses 4 bytes, while - intptr_t, long, and - void * are 8 bytes.
-
-
int type machine representation uses 4 bytes. - long type machine representation uses 8 bytes. - intptr_t and void * are 16 - byte capabilities.
-
-

Some machines support more than one - FreeBSD ABI. Typically these are 64-bit machines, - where the “native” LP64 execution - environment is accompanied by the “legacy” - ILP32 environment, which was the historical 32-bit - predecessor for 64-bit evolution. Examples are:

- - - - - - - - - - - - - - - - - -
ILP32 counterpart
-

aarch64 will support execution of - armv7 binaries if the CPU implements - AArch32 execution state. Binaries targeting - armv6 and earlier are no longer supported by - FreeBSD.

-

Architectures with 128-bit capabilities support both a - “native” L64PC128 execution - environment and a LP64 environment:

- - - - - - - - - - - - - -
LP64 counterpart
-

On all supported architectures:

- - - - - - - - - - - - - - - - - - - - - - - - - -
short2
int4
long long8
float4
double8
-

Integers are represented in two's complement. Alignment of integer - and pointer types is natural, that is, the address of the variable must be - congruent to zero modulo the type size. The sole exception is that - i386 requires only 4-byte alignment for 64-bit - integers.

-

Machine-dependent type sizes:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
long double
aarch6488168
aarch64c816168
amd6488168
armv74488
i38644124
powerpc4488
powerpcspe4488
powerpc648888
powerpc64le8888
riscv6488168
riscv64c816168
-

time_t is 8 bytes on all supported architectures - except i386.

-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
aarch64littleunsigned
aarch64clittleunsigned
amd64littlesigned
armv7littleunsigned
i386littlesigned
powerpcbigunsigned
powerpcspebigunsigned
powerpc64bigunsigned
powerpc64lelittleunsigned
riscv64littlesigned
riscv64clittlesigned
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
aarch644K, 64K, 2M, 1G
aarch64c4K, 64K, 2M, 1G
amd644K, 2M, 1G
armv74K, 1M
i3864K, 2M (PAE), 4M
powerpc4K
powerpcspe4K
powerpc644K
powerpc64le4K
riscv644K, 2M, 1G
riscv64c4K, 2M, 1G
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
aarch640x0001000000000000256TiB
aarch64c0x0001000000000000256TiB
amd64 (LA48)0x0000800000000000128TiB
amd64 (LA57)0x010000000000000064PiB
armv70xbfc000003GiB
i3860xffc000004GiB
powerpc0xfffff0004GiB
powerpcspe0x7ffff0002GiB
powerpc640x000fffffc00000004PiB
powerpc64le0x000fffffc00000004PiB
riscv64 (Sv39)0x0000004000000000256GiB
riscv64c (Sv39)0x0000004000000000256GiB
riscv64 (Sv48)0x0000800000000000128TiB
riscv64c (Sv48)0x0000800000000000128TiB
-

The layout of a process' address space can be queried via the - KERN_PROC_VM_LAYOUT sysctl(3) - MIB.

-

Historically, amd64 CPUs were limited to a - 48-bit virtual address space. Newer CPUs support 5-level page tables, which - extend the significant bits of addresses to 57 bits (LA57 mode). The address - space layout is determined by the CPU's support for LA57. Setting the - - tunable to 0 forces the system into 4-level paging mode, even on hardware - that supports 5-level paging. In this mode, all processes get a 48-bit - address space. The - - tunable determines whether processes running on a LA57 system are limited to - a 48-bit address space by default. Some applications make use of unused - upper bits in pointer values to store information, and thus implicitly - assume they are running in LA48 mode. To avoid breaking compatibility, all - processes run in LA48 mode by default. The elfctl(1) - utility can be used to request LA48 or LA57 mode for specific executables. - Similarly, proccontrol(1) can be used to configure the - address space layout when executing a process.

-

The RISC-V specification permits 3-level (Sv39), - 4-level (Sv48), and 5-level (Sv57) page tables. Hardware is only required to - implement Sv39; implementations which support Sv48 must also support Sv39, - and implementations which support Sv57 must also support Sv48. The - - tunable can be used to select the layout. FreeBSD - currently supports Sv39 and Sv48 and defaults to using Sv39.

-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
long double
aarch64hardsoft, quad precision
aarch64chardsoft, quad precision
amd64hardhard, 80 bit
armv7hardhard, double precision
i386hardhard, 80 bit
powerpchardhard, double precision
powerpcspehardhard, double precision
powerpc64hardhard, double precision
powerpc64lehardhard, double precision
riscv64hardhard, quad precision
riscv64chardhard, quad precision
-
-
-

-

FreeBSD uses clang(1) as - the default compiler on all supported CPU architectures, LLVM's - ld.lld(1) as the default linker, and LLVM binary utilities - such as objcopy(1) and readelf(1).

-
-
-

-

MACHINE_CPUARCH should be preferred in - Makefiles when the generic architecture is being tested. - MACHINE_ARCH should be preferred when there is - something specific to a particular type of architecture where there is a - choice of many, or could be a choice of many. Use - MACHINE when referring to the kernel, interfaces - dependent on a specific type of kernel or similar things like boot - sequences.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
arm64aarch64aarch64, aarch64c
amd64amd64amd64
armarmarmv7
i386i386i386
powerpcpowerpcpowerpc, powerpcspe, powerpc64, powerpc64le
riscvriscvriscv64, riscv64c
-
-
-

-

The compiler provides a number of predefined macros. Some of these - provide architecture-specific details and are explained below. Other macros, - including those required by the language standard, are not included - here.

-

The full set of predefined macros can be obtained with this - command:

-
-
cc -x c -dM -E /dev/null
-
-

Common type size and endianness macros:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
size in bytes of long
size in bytes of intptr_t and pointers
size in bytes of size_t
64-bit (8-byte) long and pointer, 32-bit (4-byte) int
32-bit (4-byte) int, long and pointer
128-bit (16-byte) capability pointer, 64-bit (8-byte) long
Either BIG_ENDIAN or - LITTLE_ENDIAN.
-

Because systems were historically either - __ILP32__ or __LP64__ it has - been common for programmers to test only one and assume the other one in an - else branch. With the arrival of CHERI architectures, this is no longer the - case. __SIZEOF_*__ macros should be used instead. - New uses of __ILP32__ and - __LP64__ should be avoided. Compilers for CHERI - targets do not define __LP64__ as their pointers are - 128-bit capabilities.

-

Architecture-specific macros:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
aarch64
aarch64c, - __CHERI__
amd64, - __x86_64__
armv7, - __ARM_ARCH >= 7
i386
powerpc
powerpcspe, - __SPE__
powerpc64, - __powerpc64__
powerpc64le, - __powerpc64__
riscv64, - __riscv_xlen == 64
riscv64c, - __riscv_xlen == 64, - __CHERI__
-

Compilers may define additional variants of architecture-specific - macros. The macros above are preferred for use in - FreeBSD.

-
-
-

make(1) variables

-

Most of the externally settable variables are defined in the - build(7) man page. These variables are not otherwise - documented and are used extensively in the build system.

-
-
-
Represents the hardware platform. This is the same as the native - platform's uname(1) -m output. - It defines both the userland / kernel interface, as well as the bootloader - / kernel interface. It should only be used in these contexts. Each CPU - architecture may have multiple hardware platforms it supports where - MACHINE differs among them. It is used to collect - together all the files from config(8) to build the - kernel. It is often the same as MACHINE_ARCH just - as one CPU architecture can be implemented by many different hardware - platforms, one hardware platform may support multiple CPU architecture - family members, though with different binaries. For example, - MACHINE of i386 supported the IBM-AT hardware - platform while the MACHINE of pc98 supported the - Japanese company NEC's PC-9801 and PC-9821 hardware platforms. Both of - these hardware platforms supported only the - MACHINE_ARCH of i386 where they shared a common - ABI, except for certain kernel / userland interfaces relating to - underlying hardware platform differences in bus architecture, device - enumeration and boot interface. Generally, MACHINE - should only be used in src/sys and src/stand or in system imagers or - installers.
-
-
Represents the CPU processor architecture. This is the same as the native - platforms uname(1) -p output. It - defines the CPU instruction family supported. It may also encode a - variation in the byte ordering of multi-byte integers (endian). It may - also encode a variation in the size of the integer or pointer. It may also - encode a ISA revision. It may also encode hard versus soft floating point - ABI and usage. It may also encode a variant ABI when the other factors do - not uniquely define the ABI. It, along with - MACHINE, defines the ABI used by the system. - Generally, the plain CPU name specifies the most common (or at least - first) variant of the CPU. This is why powerpc and powerpc64 imply 'big - endian' while armv7 and aarch64 imply little endian. If we ever were to - support the so-called x32 ABI (using 32-bit pointers on the amd64 - architecture), it would most likely be encoded as amd64-x32. It is - unfortunate that amd64 specifies the 64-bit evolution of the x86 platform - (it matches the 'first rule') as almost everybody else uses x86_64. The - FreeBSD port was so early, it predated processor - name standardization after Intel joined the market. At the time, each OS - selected its own conventions. Backwards compatibility means it is not easy - to change to the consensus name.
-
-
Represents the source location for a given - MACHINE_ARCH. It is generally the common prefix - for all the MACHINE_ARCH that share the same implementation, though - 'riscv' breaks this rule. While amd64 and i386 are closely related, - MACHINE_CPUARCH is not x86 for them. The FreeBSD - source base supports amd64 and i386 with two distinct source bases living - in subdirectories named amd64 and i386 (though behind the scenes there's - some sharing that fits into this framework).
-
-
Sets the flavor of MACHINE_ARCH to build. It is - used to optimize the build for a specific CPU / core that the binaries run - on. Generally, this does not change the ABI, though it can be a fine line - between optimization for specific cases.
-
-
Used to set MACHINE in the top level Makefile for - cross building. Unused outside of that scope. It is not passed down to the - rest of the build. Makefiles outside of the top level should not use it at - all (though some have their own private copy for historical reasons).
-
-
Used to set MACHINE_ARCH by the top level Makefile - for cross building. Like TARGET, it is unused - outside of that scope.
-
-
-
-
-

-

elfctl(1), proccontrol(1), - sysctl(3), src.conf(5), - build(7), simd(7)

-
-
-

-

An arch manual page appeared in - FreeBSD 11.1.

-
-
- - - - - -
November 27, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/ascii.7 3.html b/static/freebsd/man7/ascii.7 3.html deleted file mode 100644 index 81a207fc..00000000 --- a/static/freebsd/man7/ascii.7 3.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - -
ASCII(7)Miscellaneous Information ManualASCII(7)
-
-
-

-

ascii — octal, - hexadecimal, decimal and binary ASCII character sets

-
-
-

-

The octal set:

-
-
000 NUL  001 SOH  002 STX  003 ETX  004 EOT  005 ENQ  006 ACK  007 BEL
-010 BS   011 HT   012 LF   013 VT   014 FF   015 CR   016 SO   017 SI
-020 DLE  021 DC1  022 DC2  023 DC3  024 DC4  025 NAK  026 SYN  027 ETB
-030 CAN  031 EM   032 SUB  033 ESC  034 FS   035 GS   036 RS   037 US
-040 SP   041  !   042  "   043  #   044  $   045  %   046  &   047  '
-050  (   051  )   052  *   053  +   054  ,   055  -   056  .   057  /
-060  0   061  1   062  2   063  3   064  4   065  5   066  6   067  7
-070  8   071  9   072  :   073  ;   074  <   075  =   076  >   077  ?
-100  @   101  A   102  B   103  C   104  D   105  E   106  F   107  G
-110  H   111  I   112  J   113  K   114  L   115  M   116  N   117  O
-120  P   121  Q   122  R   123  S   124  T   125  U   126  V   127  W
-130  X   131  Y   132  Z   133  [   134  \   135  ]   136  ^   137  _
-140  `   141  a   142  b   143  c   144  d   145  e   146  f   147  g
-150  h   151  i   152  j   153  k   154  l   155  m   156  n   157  o
-160  p   161  q   162  r   163  s   164  t   165  u   166  v   167  w
-170  x   171  y   172  z   173  {   174  |   175  }   176  ~   177 DEL
-
-

The hexadecimal set:

-
-
00 NUL   01 SOH   02 STX   03 ETX   04 EOT   05 ENQ   06 ACK   07 BEL
-08 BS    09 HT    0a LF    0b VT    0c FF    0d CR    0e SO    0f SI
-10 DLE   11 DC1   12 DC2   13 DC3   14 DC4   15 NAK   16 SYN   17 ETB
-18 CAN   19 EM    1a SUB   1b ESC   1c FS    1d GS    1e RS    1f US
-20 SP    21  !    22  "    23  #    24  $    25  %    26  &    27  '
-28  (    29  )    2a  *    2b  +    2c  ,    2d  -    2e  .    2f  /
-30  0    31  1    32  2    33  3    34  4    35  5    36  6    37  7
-38  8    39  9    3a  :    3b  ;    3c  <    3d  =    3e  >    3f  ?
-40  @    41  A    42  B    43  C    44  D    45  E    46  F    47  G
-48  H    49  I    4a  J    4b  K    4c  L    4d  M    4e  N    4f  O
-50  P    51  Q    52  R    53  S    54  T    55  U    56  V    57  W
-58  X    59  Y    5a  Z    5b  [    5c  \    5d  ]    5e  ^    5f  _
-60  `    61  a    62  b    63  c    64  d    65  e    66  f    67  g
-68  h    69  i    6a  j    6b  k    6c  l    6d  m    6e  n    6f  o
-70  p    71  q    72  r    73  s    74  t    75  u    76  v    77  w
-78  x    79  y    7a  z    7b  {    7c  |    7d  }    7e  ~    7f DEL
-
-

The decimal set:

-
-
  0 NUL    1 SOH    2 STX    3 ETX    4 EOT    5 ENQ    6 ACK    7 BEL
-  8 BS     9 HT    10 LF    11 VT    12 FF    13 CR    14 SO    15 SI
- 16 DLE   17 DC1   18 DC2   19 DC3   20 DC4   21 NAK   22 SYN   23 ETB
- 24 CAN   25 EM    26 SUB   27 ESC   28 FS    29 GS    30 RS    31 US
- 32 SP    33  !    34  "    35  #    36  $    37  %    38  &    39  '
- 40  (    41  )    42  *    43  +    44  ,    45  -    46  .    47  /
- 48  0    49  1    50  2    51  3    52  4    53  5    54  6    55  7
- 56  8    57  9    58  :    59  ;    60  <    61  =    62  >    63  ?
- 64  @    65  A    66  B    67  C    68  D    69  E    70  F    71  G
- 72  H    73  I    74  J    75  K    76  L    77  M    78  N    79  O
- 80  P    81  Q    82  R    83  S    84  T    85  U    86  V    87  W
- 88  X    89  Y    90  Z    91  [    92  \    93  ]    94  ^    95  _
- 96  `    97  a    98  b    99  c   100  d   101  e   102  f   103  g
-104  h   105  i   106  j   107  k   108  l   109  m   110  n   111  o
-112  p   113  q   114  r   115  s   116  t   117  u   118  v   119  w
-120  x   121  y   122  z   123  {   124  |   125  }   126  ~   127 DEL
-
-

The binary set:

-
-
 00     01     10     11
-
-NUL     SP      @      `     00000
-SOH      !      A      a     00001
-STX      "      B      b     00010
-ETX      #      C      c     00011
-EOT      $      D      d     00100
-ENQ      %      E      e     00101
-ACK      &      F      f     00110
-BEL      '      G      g     00111
- BS      (      H      h     01000
- HT      )      I      i     01001
- LF      *      J      j     01010
- VT      +      K      k     01011
- FF      ,      L      l     01100
- CR      -      M      m     01101
- SO      .      N      n     01110
- SI      /      O      o     01111
-DLE      0      P      p     10000
-DC1      1      Q      q     10001
-DC2      2      R      r     10010
-DC3      3      S      s     10011
-DC4      4      T      t     10100
-NAK      5      U      u     10101
-SYN      6      V      v     10110
-ETB      7      W      w     10111
-CAN      8      X      x     11000
- EM      9      Y      y     11001
-SUB      :      Z      z     11010
-ESC      ;      [      {     11011
- FS      <      \      |     11100
- GS      =      ]      }     11101
- RS      >      ^      -     11110
- US      ?      _    DEL     11111
-
-

The full names of the control character - set:

-
-
NUL      NULl
-SOH      Start Of Heading
-STX      Start Of Text
-ETX      End Of Text
-EOT      End Of Transmission
-ENQ      ENQuiry
-ACK      ACKnowledge
-BEL      BELl
- BS      BackSpace
- HT      Horizontal Tab
- LF      Line Feed (new line)
- VT      Vertical Tab
- FF      new page Form Feed
- CR      Carriage Return
- SO      Shift Out
- SI      Shift In
-DLE      Data Link Escape
-DC1      Device Control 1
-DC2      Device Control 2
-DC3      Device Control 3
-DC4      Device Control 4
-NAK      Negative AcKnowledge
-SYN      SYNchronous idle
-ETB      End of Transmission Block
-CAN      CANcel
- EM      End of Medium
-SUB      SUBstitute
-ESC      ESCape
- FS      File Separator
- GS      Group Separator
- RS      Record Separator
- US      Unit Separator
-
-
-
-

-
-
/usr/share/misc/ascii
-
 
-
-
-
-

-

Information Systems - Coded - Character Sets - 7-Bit American National Standard Code for Information - Interchange (7-Bit ASCII), INCITS - 4-1986[R2017], InterNational Committee for - Information Technology Standards.

-
-
-

-

An ascii manual page appeared in - Version 1 AT&T UNIX.

-
-
- - - - - -
January 4, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/bsd.snmpmod.mk.7 3.html b/static/freebsd/man7/bsd.snmpmod.mk.7 3.html deleted file mode 100644 index a7c894d5..00000000 --- a/static/freebsd/man7/bsd.snmpmod.mk.7 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
BSD.SNMPMOD.MK(7)Miscellaneous Information ManualBSD.SNMPMOD.MK(7)
-
-
-

-

bsd.snmpmod.mk — - building modules for bsnmpd(1)

-
-
-

-

.include <bsd.snmpmod.mk>

-
-
-

-

The file - <bsd.snmpmod.mk> simplifies - the building of modules for the Begemot SNMP daemon, - bsnmpd(1). It provides some common functions for building - a module and relies on - <bsd.lib.mk>, which is - included by <bsd.snmpmod.mk> - to actually build the shared library.

-

The following make(1) variables control the - special functions:

-
-
MOD
-
The short name of the module. The name of the shared library will be - snmp_${MOD}.so. There must exist a file - ${MOD}_tree.def for compilation with - gensnmptree(1) which contains the definition of the MIB - tree implemented by the module.
-
EXTRAMIBDEFS
-
A list of extra MIB definition files for gensnmptree(1). - This is optional. This file list is given to both calls to - gensnmptree(1) — the one - that extracts the symbols in XSYM from the MIB - definitions and the one that generates the table with OIDs served by this - module.
-
EXTRAMIBSYMS
-
A list of extra MIB definition files for gensnmptree(1). - This is optional. This file list is given only to the call to - gensnmptree(1) that extracts symbols from MIB definition - files. It is useful if there are dependencies on other MIBs or for - extracting global definitions for enumeration constants.
-
XSYM
-
A list of symbols to be extracted from the MIB definition files by - gensnmptree(1). This is optional.
-
DEFS
-
A list of MIB definition files to be installed. This is optional.
-
BMIBS
-
A list of textual MIBs to be installed. This is optional.
-
-

Three files are automatically created from the MIB definition - files and the XSYM variable:

-
-
${MOD}_tree.c
-
This contains a table with the tree implemented by the module. It is - automatically included into the SRCS variable.
-
${MOD}_tree.h
-
This contains preprocessor defines for all the OIDs defined by the module - and can be included in the module's source code.
-
${MOD}_oid.h
-
OID preprocessor definitions for all the symbols listed in - XSYMS. This is to be included into the module's - source code.
-
-
-
-

-

bsnmpd(1), gensnmptree(1), - snmpmod(3)

-
-
- - - - - -
January 8, 2008FreeBSD 15.0
diff --git a/static/freebsd/man7/build.7 3.html b/static/freebsd/man7/build.7 3.html deleted file mode 100644 index dc1b3a5c..00000000 --- a/static/freebsd/man7/build.7 3.html +++ /dev/null @@ -1,863 +0,0 @@ - - - - - - -
BUILD(7)Miscellaneous Information ManualBUILD(7)
-
-
-

-

build — general - instructions on how to build the FreeBSD - system

-
-
-

-

The sources for the FreeBSD system and its - applications are contained in three directories, normally:

-
-
/usr/src
-
“base system”, loosely defined as everything required to - build the system to a useful state
-
/usr/doc
-
system documentation, excluding manual pages
-
/usr/ports
-
third-party software, with a consistent interface for building and - installing them; see ports(7)
-
-

These directories may be initially empty or non-existent until - updated with Git (devel/git from the - FreeBSD Ports Collection).

-

The make(1) command is used in each of these - directories to build and install the things in that directory. Issuing the - make(1) command in any directory issues the - make(1) command recursively in all subdirectories. With no - target specified, the items in the directories are built and no further - action is taken.

-

A source tree is allowed to be read-only. As described in - make(1), objects are usually built in a separate object - directory hierarchy specified by the environment variable - MAKEOBJDIRPREFIX, or under - /usr/obj if variable - MAKEOBJDIRPREFIX is not set. The canonical object - directory is described in the documentation for the - buildworld target below.

-

The build may be controlled by defining - make(1) variables described in the - ENVIRONMENT section below, and by the - variables documented in make.conf(5).

-

The default components included in the build are specified in the - file /etc/src.conf in the source tree. To override - the default file, include the SRCCONF option in the make steps, pointing to - a custom src.conf file. For more information see - src.conf(5).

-

The following list provides the names and actions for the targets - supported by the build system:

-
-
-
Run Clang static analyzer against all objects and present output on - stdout.
-
-
Run tests for a given subdirectory. The default directory used is - ${.OBJDIR}, but the check directory can be changed - with ${CHECKDIR}.
-
-
Run the FreeBSD test suite on installed - world.
-
-
Remove any files created during the build process.
-
-
Remove the ${.OBJDIR}/${DEPENDFILE}* files - generated by prior “make” and - “make depend” steps.
-
-
Remove the canonical object directory if it exists, or perform actions - equivalent to “make clean - cleandepend” if it does not. This target will also remove an - obj link in ${.CURDIR} if - that exists. -

It is advisable to run “make - cleandir” twice: the first invocation will remove the - canonical object directory and the second one will clean up - ${.CURDIR}.

-
-
-
Generate a list of build dependencies in file - ${.OBJDIR}/${DEPENDFILE}. Per-object dependencies - are generated at build time and stored in - ${.OBJDIR}/${DEPENDFILE}.${OBJ}.
-
-
Install the results of the build to the appropriate location in the - installation directory hierarchy specified in variable - DESTDIR.
-
-
Create the canonical object directory associated with the current - directory.
- -
Create a symbolic link to the canonical object directory in - ${.CURDIR}.
-
-
Generate a tags file using the program specified in the - make(1) variable CTAGS. The build - system supports ctags(1) and GNU - Global.
-
-

The other supported targets under directory - /usr/src are:

-
-
-
Spawn an interactive shell with environment variables set up for building - the system or individual components. For cross-building the target - architecture needs to be specified with make(1) - variables TARGET_ARCH and - TARGET. -

This target is only useful after a complete toolchain - (including the compiler, linker, assembler, headers and libraries) has - been built; see the toolchain target below.

-

BUILDENV_SHELL, which defaults to - /bin/sh, is executed. This can be set to a - command that does something in this build environment, like cross build - an application. If that application has dependencies, though, the - devel/poudriere package or port provides a more - generic solution.

-
-
-
Print the shell variables that are set for a - buildenv environment and exit.
-
-
Build everything but the kernel, configure files in - etc, and release. The - object directory can be changed from the default - /usr/obj by setting the - MAKEOBJDIRPREFIX make(1) - variable. The actual build location prefix used depends on the - WITH_UNIFIED_OBJDIR option from - src.conf(5). If enabled it is - ${MAKEOBJDIRPREFIX}${.CURDIR}/${TARGET}.${TARGET_ARCH} - for all builds. If disabled it is - ${MAKEOBJDIRPREFIX}${.CURDIR} for native builds, - and - ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}${.CURDIR} - for cross builds and native builds with variable - CROSS_BUILD_TESTING set.
-
-
Attempts to clean up targets built by a preceding - buildkernel, or similar step, built from the same - source directory and KERNCONF.
-
-
Attempt to clean up targets built by a preceding - buildworld, or similar step, built from this - source directory.
-
-
When WITH_UNIFIED_OBJDIR is enabled, attempt to - clean up targets built by a preceding buildworld, - universe, or similar step, for any architecture - built from this source directory.
-
-
Distribute everything compiled by a preceding - buildworld step. Files are placed in the directory - hierarchy specified by make(1) variable - DISTDIR. This target is used while building a - release; see release(7).
-
-
This target builds a cross-toolchain for the given - TARGET and TARGET_ARCH, as well as a - select list of static userland tools for the host system. This is intended - to be used in a jail where QEMU is used to improve performance by avoiding - emulating binaries that do not need to be emulated. - TARGET and TARGET_ARCH should be - defined.
-
-
Installs the results to ${DESTDIR}/${NXTP} where - NXTP defaults to nxb-bin. - TARGET and TARGET_ARCH must be - defined.
-
-
Create a freebsd-base(7) package repository containing - packages that can be used to install or upgrade the base system. The - repository is created in the object directory, under - ${REPODIR}/${PKG_ABI} where - REPODIR is the base directory where the repository - will be created, and PKG_ABI is the - pkg(7) ABI for the build target, for example, - /usr/obj/${SRCDIR}/repo/FreeBSD:15:amd64.
-
-
Archive the results of distributeworld, placing - the results in DISTDIR. This target is used while - building a release(7) and is unrelated to building - freebsd-base(7) packages.
-
-
Install everything built by a preceding buildworld - step into the directory hierarchy pointed to by make(1) - variable DESTDIR. -

If installing onto an NFS file system and running - make(1) with the -j option, - make sure that rpc.lockd(8) is running on both client - and server. See rc.conf(5) on how to make it start at - boot time.

-
-
-
Create the build toolchain needed to build the rest of the system. For - cross-architecture builds, this step creates a cross-toolchain.
-
-
For each architecture, execute a buildworld - followed by a buildkernel for all kernels for that - architecture, including LINT. This command takes a - long time.
-
-
Like universe with - WITHOUT_WORLDS defined so only the kernels for each - architecture are built.
-
-
Like universe with - WITHOUT_KERNELS defined so only the worlds for each - architecture are built.
-
-
Print a list of supported TARGET / - TARGET_ARCH pairs for world and kernel targets.
-
-
Execute the same targets as universe. In addition - print a summary of all failed targets at the end and exit with an error if - there were any.
-
-
Create a build toolchain for each architecture supported by the build - system.
-
-
Builds and installs a cross-toolchain and sysroot for the given - TARGET and TARGET_ARCH. The sysroot - contains target library and headers. The target is an alias for - xdev-build and - xdev-install. The location of the files installed - can be controlled with DESTDIR. The target location - in DESTDIR is - ${DESTDIR}/${XDTP} where - XDTP defaults to - /usr/${XDDIR} and XDDIR - defaults to ${TARGET_ARCH}-freebsd.
-
-
Create or update the freebsd-base(7) package repository - for the base system. If an old repository is being updated, then packages - whose contents have not changed since the previous version will be copied - into the new repository to avoid needless updating of the version - number.
-
-
Builds for the xdev target.
-
-
Installs the files for the xdev target.
- -
Installs autoconf-style symlinks to - ${DESTDIR}/usr/bin pointing into the xdev - toolchain in ${DESTDIR}/${XDTP}.
-
-

Kernel specific build targets in /usr/src - are:

-
-
-
Rebuild the kernel and the kernel modules. The object directory can be - changed from the default /usr/obj by setting the - MAKEOBJDIRPREFIX make(1) - variable.
-
-
Install the kernel and the kernel modules to directory - ${DESTDIR}/boot/kernel, renaming any pre-existing - directory with this name to kernel.old if it - contained the currently running kernel. The target directory under - ${DESTDIR} may be modified using the - INSTKERNNAME or KODIR - make(1) variables.
-
-
Install the kernel to the directory - ${DISTDIR}/kernel/boot/kernel. This target is used - while building a release; see release(7).
-
-
Archive the results of distributekernel, placing - the results in DISTDIR. This target is used while - building a release(7) and is unrelated to building - freebsd-base(7) packages.
-
-
Equivalent to buildkernel followed by - installkernel
-
-
Rebuild the tools needed for kernel compilation. Use this if you did not - do a buildworld first.
-
-
Reinstall the kernel and the kernel modules, overwriting the contents of - the target directory. As with the installkernel - target, the target directory can be specified using the - make(1) variable - INSTKERNNAME.
-
-

Convenience targets for cleaning up the install destination - directory denoted by variable DESTDIR include:

-
-
-
Print a list of old files and directories in the system.
-
-
Print a list of obsolete base system libraries.
-
-
Delete obsolete base system files and directories interactively. When - -DBATCH_DELETE_OLD_FILES is specified at the - command line, the delete operation will be non-interactive. The variables - DESTDIR, TARGET_ARCH and - TARGET should be set as with - “make installworld”.
-
-
Delete obsolete base system libraries interactively. This target should - only be used if no third party software uses these libraries. When - -DBATCH_DELETE_OLD_FILES is specified at the - command line, the delete operation will be non-interactive. The variables - DESTDIR, TARGET_ARCH and - TARGET should be set as with - “make installworld”.
-
-
-
-

-

Variables that influence all builds include:

-
-
DEBUG_FLAGS
-
Defines a set of debugging flags that will be used to build all userland - binaries under /usr/src. When - DEBUG_FLAGS is defined, the - install and installworld - targets install binaries from the current - MAKEOBJDIRPREFIX without stripping, so that - debugging information is retained in the installed binaries.
-
DESTDIR
-
The directory hierarchy prefix where built objects will be installed. If - not set, DESTDIR defaults to the empty string. If - set, DESTDIR must specify an absolute path.
-
MAKEOBJDIRPREFIX
-
Defines the prefix for directory names in the tree of built objects. - Defaults to /usr/obj if not defined. This variable - should only be set in the environment or - /etc/src-env.conf and not via - /etc/make.conf or - /etc/src.conf or the command line. - MAKEOBJDIRPREFIX must specify an absolute path.
-
WITHOUT_WERROR
-
If defined, compiler warnings will not cause the build to halt, even if - the makefile says otherwise.
-
WITH_CTF
-
If defined, the build process will run the DTrace CTF conversion tools on - built objects.
-
-

Additionally, builds in /usr/src are - influenced by the following make(1) variables:

-
-
CROSS_TOOLCHAIN
-
Requests use of an external toolchain to build either the world or kernel. - This value of this variable can either be the full path to a file, or the - base name of a file in - ${LOCALBASE}/share/toolchains. The file should be - a make file which sets variables to request an external toolchain such as - XCC. -

External toolchains are available in ports for both LLVM and - GCC/binutils. For external toolchains available in ports, - CROSS_TOOLCHAIN should be set to the name of the - package. LLVM toolchain packages use the name llvm<major version>. - GCC toolchains provide separate packages for each architecture and use - the name ${MACHINE_ARCH}-gcc<major version>.

-
-
INSTKERNNAME
-
If set, specify an alternative name to build and install for the various - kernel make targets. Defaults to - “kernel”.
-
KERNCONF
-
Specify one or more space-separated kernels to build and install for the - various kernel make targets. If multiple kernels are specified, the first - listed kernel installs to /boot/${INSTKERNNAME}, - and subsequent kernels install to - /boot/${INSTKERNNAME}.NAME. -

If unset, it defaults to GENERIC, except on POWER - architectures, where it defaults to GENERIC64 for powerpc64, and - GENERIC64LE for powerpc64le.

-
-
KERNBUILDDIR
-
Overrides the default directory to get all the opt_*.h files for building - a kernel module. Useful for stand-alone modules that depend on - config(8) options. Automatically set for modules built - with a kernel.
-
KERNCONFDIR
-
Overrides the directory in which KERNCONF and any - files included by KERNCONF should be found. Defaults - to sys/${ARCH}/conf.
-
KERNFAST
-
If set, the build target buildkernel defaults to - setting NO_KERNELCLEAN, - NO_KERNELCONFIG, and - NO_KERNELOBJ. When set to a value other than - 1 then KERNCONF is set to - the value of KERNFAST.
-
KODIR
-
If set, this variable specifies an alternative directory to install the - kernel.
-
LOCAL_DIRS
-
If set, this variable supplies a list of additional directories relative - to the root of the source tree to build as part of the - everything target. The directories are built in - parallel with each other, and with the base system directories. Insert a - .WAIT directive at the beginning of the - LOCAL_DIRS list to ensure all base system - directories are built first. .WAIT may also be used - as needed elsewhere within the list.
-
LOCAL_ITOOLS
-
If set, this variable supplies a list of additional tools that are used by - the installworld and - distributeworld targets.
-
LOCAL_LIB_DIRS
-
If set, this variable supplies a list of additional directories relative - to the root of the source tree to build as part of the - libraries target. The directories are built in - parallel with each other, and with the base system libraries. Insert a - .WAIT directive at the beginning of the - LOCAL_DIRS list to ensure all base system libraries - are built first. .WAIT may also be used as needed - elsewhere within the list.
-
LOCAL_MTREE
-
If set, this variable supplies a list of additional mtrees relative to the - root of the source tree to use as part of the - hierarchy target.
-
LOCAL_LEGACY_DIRS
-
If set, this variable supplies a list of additional directories relative - to the root of the source tree to build as part of the - legacy target.
-
LOCAL_BSTOOL_DIRS
-
If set, this variable supplies a list of additional directories relative - to the root of the source tree to build as part of the - bootstrap-tools target.
-
LOCAL_TOOL_DIRS
-
If set, this variable supplies a list of additional directories relative - to the root of the source tree to build as part of the - build-tools target.
-
LOCAL_XTOOL_DIRS
-
If set, this variable supplies a list of additional directories relative - to the root of the source tree to build as part of the - cross-tools target.
-
OBJROOT
-
The object directory root is defined as - ${OBJDIR}/${SRCDIR}/. See - share/mk/src.sys.obj.mk.
-
PKG_FORMAT
-
Specify a package compression format when building - freebsd-base(7) packages. Default: - ‘tzst’. Consider using - ‘tar’ to disable compression. - Accepted options are documented in the -f - description of pkg-create(8).
-
PORTS_MODULES
-
A list of ports with kernel modules that should be built and installed as - part of the buildkernel and - installkernel process. This is currently - incompatible with building freebsd-base(7) packages. - Each port must be specified as - category/port[@flavor], - e.g. -
- 
PORTS_MODULES=graphics/gpu-firmware-intel-kmod@kabylake
-PORTS_MODULES+=graphics/drm-66-kmod
-
-
-
LOCAL_MODULES
-
A list of external kernel modules that should be built and installed as - part of the buildkernel and - installkernel process. Defaults to the list of - sub-directories of LOCAL_MODULES_DIR.
-
LOCAL_MODULES_DIR
-
The directory in which to search for the kernel modules specified by - LOCAL_MODULES. Each kernel module should consist of - a directory containing a makefile. Defaults to - ${LOCALBASE}/sys/modules.
-
SRCCONF
-
Specify a file to override the default - /etc/src.conf. The src.conf file controls the - components to build. See src.conf(5)
-
REPODIR
-
The root directory used to create the package repository for building - packages(7). Defaults to - ${OBJROOT}/repo/. This can also be set in - src-env.conf(5).
-
STRIPBIN
-
Command to use at install time when stripping binaries. Be sure to add any - additional tools required to run STRIPBIN to the - LOCAL_ITOOLS make(1) variable - before running the distributeworld or - installworld targets. See - install(1) for more details.
-
SUBDIR_OVERRIDE
-
Override the default list of sub-directories and only build the - sub-directory named in this variable. If combined with - buildworld then all libraries and includes, and - some of the build tools will still build as well. Specifying - -DNO_LIBS, and -DWORLDFAST - will only build the specified directory as was done historically. When - combined with buildworld it is necessary to - override LOCAL_LIB_DIRS with any custom directories - containing libraries. This allows building a subset of the system in the - same way as buildworld does using its sysroot - handling. This variable can also be useful when debugging failed builds. -
- 
make some-target SUBDIR_OVERRIDE=foo/bar
-
-
-
SYSDIR
-
Specify the location of the kernel source to override the default - /usr/src/sys. The kernel source is located in the - sys subdirectory of the source tree checked out - from the src.git repository.
-
TARGET
-
The target hardware platform. This is analogous to the - “uname -m” - output. This is necessary to cross-build some target architectures. For - example, cross-building for ARM64 machines requires - TARGET_ARCH=aarch64 and - TARGET=arm64. If not set, - TARGET defaults to the current hardware platform, - unless TARGET_ARCH is also set, in which case it - defaults to the appropriate value for that architecture.
-
TARGET_ARCH
-
The target machine processor architecture. This is analogous to the - “uname -p” - output. Set this to cross-build for a different architecture. If not set, - TARGET_ARCH defaults to the current machine - architecture, unless TARGET is also set, in which - case it defaults to the appropriate value for that platform. Typically, - one only needs to set TARGET.
-
-

Builds under directory /usr/src are also - influenced by defining one or more of the following symbols, using the - -D option of make(1):

-
-
LOADER_DEFAULT_INTERP
-
Defines what interpreter the default loader program will have. Valid - values include “4th”, “lua”, and - “simp”. This creates the default link for - /boot/loader to the loader with that interpreter. - It also determines what interpreter is compiled into - userboot.
-
NO_CLEANDIR
-
If set, the build targets that clean parts of the object tree use the - equivalent of “make clean” instead of “make - cleandir”.
-
NO_CLEAN
-
If set, no object tree files are cleaned at all. This is the default when - WITH_META_MODE is used with - filemon(4) loaded. See src.conf(5) for - more details. Setting NO_CLEAN implies - NO_KERNELCLEAN, so when - NO_CLEAN is set no kernel objects are cleaned - either.
-
NO_CTF
-
If set, the build process does not run the DTrace CTF conversion tools on - built objects.
-
NO_SHARE
-
If set, the build does not descend into the - /usr/src/share subdirectory (i.e., manual pages, - locale data files, timezone data files and other - /usr/src/share files will not be rebuild from - their sources).
-
NO_KERNELCLEAN
-
If set, the build process does not run “make clean” as part - of the buildkernel target.
-
NO_KERNELCONFIG
-
If set, the build process does not run config(8) as part - of the buildkernel target.
-
NO_KERNELOBJ
-
If set, the build process does not run “make obj” as part of - the buildkernel target.
-
NO_LIBS
-
If set, the libraries phase will be skipped.
-
NO_OBJWALK
-
If set, no object directories will be created. This should only be used if - object directories were created in a previous build and no new directories - are connected.
-
UNIVERSE_TOOLCHAIN
-
Requests use of the toolchain built as part of the - universe target as an external toolchain.
-
WORLDFAST
-
If set, the build target buildworld defaults to - setting NO_CLEAN, NO_OBJWALK, - and will skip most bootstrap phases. It will only bootstrap libraries and - build all of userland. This option should be used only when it is known - that none of the bootstrap needs changed and that no new directories have - been connected to the build.
-
-

Builds under directory /usr/doc are - influenced by the following make(1) variables:

-
-
DOC_LANG
-
If set, restricts the documentation build to the language subdirectories - specified as its content. The default action is to build documentation for - all languages.
-
-

Builds using the universe and related - targets are influenced by the following make(1) - variables:

-
-
JFLAG
-
Pass the value of this variable to each make(1) - invocation used to build worlds and kernels. This can be used to enable - multiple jobs within a single architecture's build while still building - each architecture serially.
-
MAKE_JUST_KERNELS
-
Only build kernels for each supported architecture.
-
MAKE_JUST_WORLDS
-
Only build worlds for each supported architecture.
-
WITHOUT_WORLDS
-
Only build kernels for each supported architecture.
-
WITHOUT_KERNELS
-
Only build worlds for each supported architecture.
-
UNIVERSE_TARGET
-
Execute the specified make(1) target for each supported - architecture instead of the default action of building a world and one or - more kernels. This variable implies - WITHOUT_KERNELS.
-
USE_GCC_TOOLCHAINS
-
Use external GCC toolchains to build the requested targets. If the - required toolchain package for a supported architecture is not installed, - the build for that architecture is skipped. -

A specific version of GCC can be used by setting the value of - this variable to the desired version (for example, - “gcc14”); otherwise a default version of GCC is used.

-
-
TARGETS
-
Only build the listed targets instead of each supported architecture.
-
EXTRA_TARGETS
-
In addition to the supported architectures, build the semi-supported - architectures. A semi-supported architecture has build support in the - FreeBSD tree, but receives significantly less - testing and is generally for fringe uses that do not have a wide - appeal.
-
-
-
-

-
-
/usr/doc/Makefile
-
 
-
/usr/doc/share/mk/doc.project.mk
-
 
-
/usr/ports/Mk/bsd.port.mk
-
 
-
/usr/ports/Mk/bsd.sites.mk
-
 
-
/usr/src/Makefile
-
 
-
/usr/src/Makefile.inc1
-
make(1) infrastructure for each tree
-
/usr/ports/UPDATING
-
 
-
/usr/src/UPDATING
-
notable changes in each tree
-
/usr/share/examples/etc/make.conf
-
example make.conf(5)
-
/etc/src.conf
-
src build configuration, see src.conf(5)
-
-
-
-

-

This section describes best practices for common situations. When - manual intervention is necessary, it will be mentioned in - UPDATING. Make sure you have full backups before - proceeding!

-
-

-

If using installed drivers such as graphics or virtual machine - guest drivers, check out the ports(7) tree, and specify - the drivers in src.conf(5) so they are built and installed - automatically after the kernel:

-
-
git clone https://git.FreeBSD.org/ports.git /usr/ports
-cat << EOF >> /etc/src.conf
-PORTS_MODULES+=graphics/drm-kmod emulators/virtualbox-ose-kmod
-EOF
-
-

Check out the CURRENT branch, build it, and install, overwriting - the current system:

-
-
git clone https://git.FreeBSD.org/src.git /usr/src
-cd /usr/src
-make buildworld buildkernel
-make installkernel
-shutdown -r now
-
-

For major version upgrades, boot into single-user mode. After - restarting, install userspace, and merge configurations. After verifying - that you do not need them, delete old files:

-
-
cd /usr/src
-etcupdate -p
-make installworld
-etcupdate -B
-make delete-old
-shutdown -r now
-
-

After testing the new system and verifying that your applications - do not depend on them, delete the old libraries:

-

-
make delete-old-libs
-
-
-

-

Create a custom kernel configuration, - MYKERNEL, by including an existing configuration and - using device/nodevice and - options/nooption to select - and configure components:

-
-
cd /usr/src
-cat << EOF > sys/amd64/conf/MYKERNEL
-include GENERIC
-ident MYKERNEL
-nodevice sound
-EOF
-
-

After creating the new kernel configuration, build a fresh - toolchain, build the kernel, and install it directly, moving the old kernel - to /boot/kernel.old/:

-
-
make kernel-toolchain
-make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL
-make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL
-shutdown -r now
-
-

To package the kernel into a freebsd-base(7) - package instead of installing it directly, use - update-packages instead of - installkernel:

-
-
make buildworld buildkernel KERNCONF=MYKERNEL
-make update-packages KERNCONF=MYKERNEL
-
-

To install the kernel directly to an alternate location, use the - INSTKERNNAME variable and boot it once to test via - nextboot(8):

-
-
make installkernel KERNCONF=MYKERNEL INSTKERNNAME=testkernel
-nextboot -k testkernel
-shutdown -r now
-
-
-
-

-

Rebuild and reinstall a single piece of userspace, in this case - ls(1):

-
-
cd /usr/src/bin/ls
-make clean all
-make install
-
-
-
-

-

Rebuild and reinstall a single loadable kernel module, in this - case sound(4):

-
-
cd /usr/src/sys/modules/sound
-make all install clean cleandepend KMODDIR=/boot/kernel
-
-
-
-

-

Quickly rebuild and reinstall the kernel, only recompiling the - files changed since last build; note that this will only work if the full - kernel build has been completed in the past, not on a fresh source tree:

-
-
cd /usr/src
-make kernel KERNFAST=1
-
-
-
-

-

To rebuild parts of FreeBSD for another - CPU architecture, first prepare your source tree by building the - cross-toolchain:

-
-
cd src
-make toolchain TARGET_ARCH=aarch64
-
-

The following sequence of commands can be used to cross-build the - system for the arm64 (aarch64) architecture on a different host - architecture, such as amd64:

-
-
cd /usr/src
-make TARGET_ARCH=aarch64 buildworld buildkernel
-make TARGET_ARCH=aarch64 DESTDIR=/client installworld installkernel
-
-

Afterwards, to build and install a single piece of userspace, - use:

-
-
cd src/bin/ls
-make buildenv TARGET_ARCH=aarch64
-make clean all install DESTDIR=/client
-
-

Likewise, to quickly rebuild and reinstall the kernel, use:

-
-
cd src
-make buildenv TARGET_ARCH=aarch64
-make kernel KERNFAST=1 DESTDIR=/client
-
-
-
-
-

-
-
Bad system call (core dumped)
-
-
rescue/sh check failed, installation aborted
-
-

The kernel was not updated due to incorrect build procedure. - Study the examples above.

-
-
-
-
-

-

cc(1), install(1), - make(1), make.conf(5), - src.conf(5), arch(7), - development(7), freebsd-base(7), - pkg(7), ports(7), - release(7), tests(7), - config(8), etcupdate(8), - nextboot(8), shutdown(8)

-
-
-

-

The build manpage first appeared in - FreeBSD 4.3.

-
-
-

-

Mike W. Meyer - <mwm@mired.org>

-
-
-

-

Old objects can cause obscure build problems; try - ‘make cleandir cleandir’.

-

Environment poisoning can cause obscure build problems; try - prefixing make(1) commands with - ‘env -i’

-

When doing a major release upgrade, booting into single user mode - for installworld is required.

-

Updating the boot loader(8) is architecture - specific. Consult boot(8) for your architecture for more - details.

-
-
- - - - - -
April 22, 2026FreeBSD 15.0
diff --git a/static/freebsd/man7/c.7 3.html b/static/freebsd/man7/c.7 3.html deleted file mode 100644 index 98bbcb70..00000000 --- a/static/freebsd/man7/c.7 3.html +++ /dev/null @@ -1,363 +0,0 @@ - - - - - - -
C(7)Miscellaneous Information ManualC(7)
-
-
-

-

c, c78, - c89, c90, - c95, c99, - c11, c17, - c23, c2y — - The C programming language

-
-
-

-

C is a general purpose programming language, which has a strong - connection with the UNIX operating system and its derivatives, since the - vast majority of those systems were written in the C language. The C - language contains some basic ideas from the BCPL language through the B - language written by Ken Thompson in 1970 for the DEC PDP-7 machines. The - development of the UNIX operating system was started on a PDP-7 machine in - assembly language, but it made very difficult to port the existing code to - other systems.

-

In 1972 Dennis M. Ritchie worked out the C programming language - for further development of the UNIX operating system. The idea was to - implement only the C compiler for different platforms, and implement most - part of the operating system in the new programming language to simplify the - portability between different architectures. It follows that C is very - eligible for (but not limited to) writing operating systems and low-level - applications.

-

The C language did not have a specification or standardized - version for a long time. It went through a lot of changes and improvements - for ages. In 1978, Brian W. Kernighan and Dennis M. Ritchie published the - first book about C under the title "The C Programming Language". - We can think of this book as the first specification of the language. This - version is often referred as K&R C after the names of the authors. - Sometimes it is referred as C78, as well, after the publishing year of the - first edition of the book.

-

It is important to notice, that the instruction set of the - language is limited to the most fundamental elements for simplicity. - Handling of the standard I/O and such common functions are implemented in - the libraries shipped with the compiler. As these functions are also widely - used, it was demanded to include into the description what requisites the - library should conform to, not just strictly the language itself. - Accordingly, the aforementioned standards cover the library elements, as - well. The elements of this standard library is still not enough for more - complicated tasks. In this case the provided system calls of the given - operating system can be used. To not lose the portability by using these - system calls, the POSIX (Portable Operating System Interface) standard - evolved. It describes what functions should be available to keep - portability. Note, that POSIX is not a C standard, but an operating system - standard and thus is beyond the scope of this manual. The standards - discussed below are all C standards and only cover the C programming - language and the accompanying library. All listed improvements for each - standard edition are taken from the official standard drafts. For further - details, check the publicly available drafts or purchase the published - standards — from either ISO or IEC resources.

-

After the publication of the book mentioned before, the American - National Standards Institute (ANSI) started to work on standardizing the - language, and they announced ANSI X3.159-1989 in 1989. It is usually - referred to as ANSI C or C89. The main difference in this standard were the - function prototypes, which is a new way of declaring functions. With the - old-style function declarations, the compiler was unable to check the sanity - of the actual parameters at a function call. The old syntax was highly - error-prone because incompatible parameters were hard to detect in the - program code and the problem only showed up at run-time.

-

In 1990, the International Organization for Standardization (ISO) - adopted the ANSI standard as ISO/IEC 9899:1990 in 1990. This is also - referred to as ISO C or C90. It only contains negligible minor modifications - against ANSI C, so the two standards often considered to be fully - equivalent. This was a very important milestone in the history of the C - language, but the development of the language did not stop.

-

The ISO C standard was later extended with an amendment as ISO/IEC - 9899/AMD1 in 1995. This contained, for example, the wide-character support - in <wchar.h> and - <wctype.h>, and also - restricted character set support via diagraphs and - <iso646.h>. This amendment - is usually referred to as C95. Two technical corrigenda were also published: - Technical Corrigendum 1 as ISO/IEC 9899/COR1 in 1994 and Technical - Corrigendum 2 as ISO/IEC 9899/COR2 in 1996. The continuous development and - growth made it necessary to work out a new standard, which contains the new - features and fixes the known defects and deficiencies of the language. As a - result, ISO/IEC 9899:1999 was born in 1999 as the second edition of the - standard. Similarly to the other standards, this is informally named after - the publication year as C99. The improvements include (but are not limited - to) the following:

-
    -
  • digraphs, trigraphs, and alternative spellings for the operators that use - non-ISO646 characters in - <iso646.h>
    • -
  • extended multibyte and wide character library support in - <wchar.h> and - <wctype.h>
    • -
  • variable length arrays
    • -
  • flexible array members
    • -
  • complex (and imaginary) number arithmetic support in - <complex.h>
    • -
  • type-generic math macros in - <tgmath.h>
    • -
  • the long long int type and library functions
    • -
  • remove implicit int type
    • -
  • universal character names (\u and \U)
    • -
  • compound literals
    • -
  • remove implicit function declaration
    • -
  • BCPL style single-line comments
    • -
  • allow mixed declarations and code
    • -
  • the - () - family of functions in - <stdio.h> and - <wchar.h>
    • -
  • allow trailing comma in enum declaration
    • -
  • inline functions
    • -
  • the - () - family of functions in - <stdio.h>
    • -
  • boolean type and macros in - <stdbool.h>
    • -
  • empty macro arguments
    • -
  • _Pragma preprocessing operator
    • -
  • __func__ predefined identifier
    • -
  • va_copy macro in - <stdarg.h>
    • -
  • additional strftime conversion specifiers
    • -
-

Later in 2011, the third edition of the standard, ISO/IEC - 1989:2011, commonly referred to as C11 (formerly C1x), came out and replaced - the second edition by ISO/IEC 9899:1999/COR1:2001, ISO/IEC - 9899:1999/COR2:2004, and ISO/IEC 9899:1999/COR3:2007. The improvements - include (but are not limited to) the following:

-
    -
  • support for multiple threads of execution and atomic operations in - <threads.h> and - <stdatomic.h>
    • -
  • additional floating-point characteristic macros in - <float.h>
    • -
  • querying and specifying alignment of objects in - <stdalign.h> and - <stdlib.h>
    • -
  • Unicode character types and functions in - <uchar.h>
    • -
  • type-generic expressions
    • -
  • static assertions in - <assert.h>
    • -
  • anonymous structures and unions
    • -
  • remove the gets function from - <stdio.h>
    • -
  • add the aligned_alloc, at_quick_exit, and quick_exit functions in - <stdlib.h>
    • -
-

C11 was later superseded by ISO/IEC 9899:2018, also known as C17 - which was prepared in 2017 and published in June 2018 as the fourth edition. - It incorporates the Technical Corrigendum 1 (ISO/IEC 9899:2011/COR1:2012) - which was published in 2012. It addressed defects and deficiencies in C11 - without introducing new features, only corrections and clarifications.

-

C23, formally ISO/IEC 9899:2024, is the current standard with - significant updates that supersede C17 (ISO/IEC 9899:2018). The - standardization effort began in 2016, informally as C2x, with the first WG14 - meeting in 2019, and was officially published on October 31, 2024. C23 was - originally anticipated for an earlier release, but the timeline was extended - due to COVID-19 pandemic. With C23, the value of __STDC_VERSION__ has been - updated from 201710L to 202311L. Key changes include (but are not limited - to) the following:

-
    -
  • Add null pointer type nullptr_t and the nullptr keyword
    • -
  • Add constexpr keyword as a storage-class specifier for objects
    • -
  • Redefine the usage of the auto keyword to support type inference while - also retaining its previous functionality as a storage-class specifier - when used with a type
    • -
  • Add %b binary conversion specifier to the - () - and - () - function families
    • -
  • Add binary conversion support (0b and 0B) to the - () - and - () - function families
    • -
  • Add the #embed directive for binary resource inclusion and __has_embed to - check resource availability with preprocessor directives
    • -
  • Add the #warning directive for diagnostics
    • -
  • Add the #elifdef and #elifndef directives
    • -
  • Add the u8 prefix for character literals to represent UTF-8 encoding, - compatible with C++17
    • -
  • Add the char8_t type for UTF-8 encoded data and update the types of u8 - character constants and string literals to char8_t
    • -
  • Add functions - () - and - () - to convert between narrow multibyte characters and UTF-8 encoding
    • -
  • Define all char16_t strings and literals as UTF-16 encoded and char32_t - strings and literals as UTF-32 encoded unless specified otherwise
    • -
  • Allow storage-class specifiers within compound literals
    • -
  • Support the latest IEEE 754 standard, ISO/IEC 60559:2020, with binary and - (optional) decimal floating-point arithmetic
    • -
  • Add single-argument _Static_assert for compatibility with C++17
    • -
  • Add _Decimal32, _Decimal64, _Decimal128 keywords for (optional) decimal - floating-point arithmetic
    • -
  • Add digit separator ' (the single quote character) for literals
    • -
  • Enable specification of the underlying type of an enum
    • -
  • Standardize the - () - operator
    • -
  • Add - () - in <string.h> to securely - erase sensitive data regardless of optimizations
    • -
  • Add - () - in <string.h> for - efficient string concatenation
    • -
  • Add - () - in <stdlib.h> to determine - pointer alignment
    • -
  • Add - () - and - () - in <string.h> to allocate - string copies
    • -
  • Introduce bit utility functions, macros, and types in the new header - <stdbit.h>
    • -
  • Add - () - in <time.h> for converting - time structures to calendar time values
    • -
  • Add __has_include for header availability checking via preprocessor - directives
    • -
  • Add __has_c_attribute to check attribute availability via preprocessor - directives
    • -
  • Add _BitInt(N) and unsigned _BitInt(N) for bit-precise integers, and - BITINT_MAXWIDTH for maximum bit width
    • -
  • Elevate true and false to proper keywords (previously macros from - <stdbool.h>)
    • -
  • Add keywords alignas, alignof, bool, static_assert, thread_local; - previously defined keywords remain available as alternative spellings
    • -
  • Enable zero initialization with {} (including initialization of VLAs)
    • -
  • Introduce C++11 style attributes using [[]], with adding [[deprecated]], - [[fallthrough]], [[maybe_unused]], [[nodiscard]], and [[noreturn]]
    • -
  • Deprecate _Noreturn, noreturn, header - <stdnoreturn.h> features - introduced in C11
    • -
  • Remove trigraph support
    • -
  • Remove K&R function definitions and declarations
    • -
  • Remove non-two's-complement representations for signed integers
    • -
-

The next version of the C Standard, informally named C2y, is - anticipated to release within the next six years, targeting 2030 at the - latest. A charter for C2y is still being drafted and discussed, with several - papers under debate from the January 2024 meeting in Strasbourg, France - indicating that this new version may address long-standing requests and - deficiencies noted by the C community, while preserving its core - strengths.

-

ISO/IEC JTC1/SC22/WG14 committee is responsible for the ISO/IEC - 9899, C Standard.

-
-
-

-

c89(1), c99(1), - cc(1)

-
-
-

-

ANSI, - X3.159-1989 (aka C89 or ANSI C).

-

ISO/IEC, - 9899:1990 (aka C90).

-

ISO/IEC, - 9899:1990/AMD 1:1995, Amendment 1: C Integrity (aka - C95).

-

ISO/IEC, - 9899:1990/COR 1:1994, Technical Corrigendum - 1.

-

ISO/IEC, - 9899:1990/COR 2:1996, Technical Corrigendum - 2.

-

ISO/IEC, - 9899:1999 (aka C99).

-

ISO/IEC, - 9899:1999/COR 1:2001, Technical Corrigendum - 1.

-

ISO/IEC, - 9899:1999/COR 2:2004, Technical Corrigendum - 2.

-

ISO/IEC, - 9899:1999/COR 3:2007, Technical Corrigendum - 3.

-

ISO/IEC, - TR 24731-1:2007 (aka bounds-checking - interfaces).

-

ISO/IEC, - TS 18037:2008 (aka, embedded C).

-

ISO/IEC, - TR 24747:2009 (aka mathematical special - functions).

-

ISO/IEC, - TR 24732:2009 (aka decimal - floating-point).

-

ISO/IEC, - TR 24731-2:2010 (aka dynamic allocation - functions).

-

ISO/IEC, - 9899:2011 (aka C11).

-

ISO/IEC, - 9899:2011/COR 1:2012, Technical Corrigendum - 1.

-

ISO/IEC, - TS 17961:2013 (aka C secure coding - rules).

-

ISO/IEC, - TS 18861-1:2014 (aka binary - floating-point).

-

ISO/IEC, - TS 18861-2:2015 (aka decimal - floating-point).

-

ISO/IEC, - TS 18861-3:2015 (aka interchange and extended - types).

-

ISO/IEC, - TS 18861-4:2015 (aka supplementary - functions).

-

ISO/IEC, - TS 17961:2013/COR 1:2016 (aka C secure coding rules - TC1).

-

ISO/IEC, - TS 18861-5:2016 (aka supplementary - attributes).

-

ISO/IEC, - 9899:2018 (aka C17).

-

ISO/IEC, - 9899:2024 (aka C23).

-
-
-

-

This manual page first appeared in FreeBSD - 9.0.

-
-
-

-

This manual page was originally written by Gabor - Kovesdan - <gabor@FreeBSD.org>. - It was updated by Faraz Vahedi - <kfv@kfv.io> with - information about more recent C standards.

-
-
- - - - - -
November 4, 2024FreeBSD 15.0
diff --git a/static/freebsd/man7/clocks.7 3.html b/static/freebsd/man7/clocks.7 3.html deleted file mode 100644 index a984c8b9..00000000 --- a/static/freebsd/man7/clocks.7 3.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - -
CLOCKS(7)Miscellaneous Information ManualCLOCKS(7)
-
-
-

-

clocks — various - system timers

-
-
-

-

#include - <time.h>

-
-
-

-

HZ is not part of the application - interface in BSD.

-

There are many different real and virtual (timekeeping) clocks - with different frequencies:

-
    -
  • The scheduling clock. This is a real clock with frequency that happens to - be 100. It is not available to applications.
    • -
  • The statistics clock. This is a real clock with frequency that happens to - be 128. It is not directly available to applications.
    • -
  • The clock reported by clock(3). This is a virtual clock - with a frequency that happens to be 128. Its actual frequency is given by - the macro CLOCKS_PER_SEC. Note that - CLOCKS_PER_SEC may be floating point. Do not use - clock(3) in new programs under - FreeBSD. It is feeble compared with - getrusage(2). It is provided for ANSI conformance. It is - implemented by calling getrusage(2) and throwing away - information and resolution.
    • -
  • The clock reported by times(3). This is a - virtual clock with a frequency that happens to be 128. Its actual - frequency is given by the macro CLK_TCK - (deprecated; do not use) and by - (_SC_CLK_TCK) - and by sysctl(3). Note that its frequency may be - different from CLOCKS_PER_SEC. Do not use - times(3) in new programs under - FreeBSD. It is feeble compared with - gettimeofday(2) together with - getrusage(2). It is provided for POSIX conformance. It - is implemented by calling gettimeofday(2) and - getrusage(2) and throwing away information and - resolution.
    • -
  • The profiling clock. This is a real clock with frequency 1024. It is used - mainly by moncontrol(3) and gprof(1). - Applications should determine its actual frequency using - sysctl(3) or by reading it from the header in the - profiling data file.
    • -
  • The mc146818a clock. This is a real clock with a nominal frequency of - 32768. It is divided down to give the statistic clock and the profiling - clock. It is not available to applications.
    • -
  • The microseconds clock. This is a virtual clock with frequency 1000000. It - is used for most timekeeping in BSD and is - exported to applications in getrusage(2), - gettimeofday(2), select(2), - getitimer(2), etc. This is the clock that should - normally be used by BSD applications.
    • -
  • The i8254 clock. This is a real clock/timer with a nominal frequency of - 1193182. It has three independent time counters to be used. It is divided - down to give the scheduling clock. It is not available to - applications.
    • -
  • The TSC clock (64-bit register) on fifth-generation or later x86 systems. - This is a real clock with a frequency that is equivalent to the number of - cycles per second of the CPU(s). Its frequency can be found using the - machdep.tsc_freq sysctl, if it is available. It is - used to interpolate between values of the scheduling clock.
    • -
  • The ACPI clock. This is a real clock/timer with a nominal frequency of - 3579545. It is accessed via a 24 or 32 bit register. Unlike the TSC clock, - it maintains a constant tick rate even when the CPU sleeps or its clock - rate changes. It is not available to applications.
    • -
-

Summary: if HZ is not 1000000 then the - application is probably using the wrong clock.

-
-
-

-

gprof(1), clock_gettime(2), - getitimer(2), getrusage(2), - gettimeofday(2), select(2), - clock(3), moncontrol(3), - times(3)

-
-
-

-

This manual page was written by Jörg - Wunsch after a description posted by Bruce - Evans.

-
-
- - - - - -
January 18, 2008FreeBSD 15.0
diff --git a/static/freebsd/man7/crypto.7 3.html b/static/freebsd/man7/crypto.7 3.html deleted file mode 100644 index 5b52df72..00000000 --- a/static/freebsd/man7/crypto.7 3.html +++ /dev/null @@ -1,327 +0,0 @@ - - - - - - -
CRYPTO(7)Miscellaneous Information ManualCRYPTO(7)
-
-
-

-

crypto — - OpenCrypto algorithms

-
-
-

-

The in-kernel OpenCrypto framework supports several different - encryption and authentication algorithms. This document describes the - parameters and requirements of these algorithms. Unless otherwise noted, all - sizes listed below are in bytes.

-
-

-

Authenticators compute a value (also known as a digest, hash, or - tag) over an input of bytes. In-kernel requests can either compute the value - for a given input, or verify if a given tag matches the computed tag for a - given input. The following authentication algorithms are supported:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1216, 24, 3216Authentication-only mode of AES-CCM
1216, 24, 3216Galois message authentication code
0, 6464Blake2b
0, 3232Blake2s
12IPsec NULL HMAC
3216Poly1305 authenticator
20RIPE Message Digest-160
6420RIPE Message Digest-160 HMAC
20SHA-1
6420SHA-1 HMAC
28SHA-2 224
6428SHA-2 224 HMAC
32SHA-2 256
6432SHA-2 256 HMAC
48SHA-2 384
12848SHA-2 384 HMAC
64SHA-2 512
12864SHA-2 512 HMAC
-
-
-

-

Block ciphers in OCF can only operate on messages whose length is - an exact multiple of the cipher's block size. OCF supports the following - block ciphers:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
161616, 24, 32AES-CBC
81632, 64AES-XTS
161616, 24, 32Camellia CBC
040-256IPsec NULL cipher
-

CRYPTO_AES_XTS implements XEX Tweakable - Block Cipher with Ciphertext Stealing as defined in NIST SP 800-38E. OCF - consumers provide the first 8 bytes of the IV. The remaining 8 bytes are - defined to be a block counter beginning at 0.

-

NOTE: The ciphertext stealing part is not implemented in all - backends which is why this cipher requires input that is a multiple of the - block size.

-
-
-

-

Stream ciphers can operate on messages with arbitrary lengths. OCF - supports the following stream ciphers:

- - - - - - - - - - - - - - - - - - - -
1616, 24, 32AES Counter Mode
1616, 32ChaCha20
-

The IV for each request must be provided in - crp_iv via the - CRYPTO_F_IV_SEPARATE flag.

-

CRYPTO_AES_ICM uses the entire IV as a - 128-bit big endian block counter. The IV sets the initial counter value for - a message. If a consumer wishes to use an IV whose value is split into - separate nonce and counter fields (e.g., IPsec), the consumer is responsible - for splitting requests to handle counter rollover.

-

CRYPTO_CHACHA20 accepts a 16 byte IV. The - first 8 bytes are used as a nonce. The last 8 bytes are used as a 64-bit - little-endian block counter.

-
-
-

-

AEAD algorithms in OCF combine a stream cipher with an - authentication algorithm to provide both secrecy and authentication. AEAD - algorithms accept additional authentication data (AAD) in addition to the - ciphertext or plaintext. AAD is passed to the authentication algorithm as - input in a method defined by the specific AEAD algorithm.

-

AEAD algorithms in OCF accept a nonce that is combined with an - algorithm-defined counter to construct the IV for the underlying stream - cipher. This nonce must be provided in crp_iv via the - CRYPTO_F_IV_SEPARATE flag. Some AEAD algorithms - support multiple nonce sizes. The first size listed is the default nonce - size.

-

The following AEAD algorithms are supported:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1216, 24, 3216AES Galois/Counter Mode
12, 7-1316, 24, 3216AES Counter with CBC-MAC
12, 83216ChaCha20-Poly1305
243216XChaCha20-Poly1305
-
-
-
-

-

crypto(4), crypto(9)

-
-
-

-

The crypto manual page first appeared in - FreeBSD 10.1.

-
-
- - - - - -
January 11, 2022FreeBSD 15.0
diff --git a/static/freebsd/man7/d.7 3.html b/static/freebsd/man7/d.7 3.html deleted file mode 100644 index c0b17698..00000000 --- a/static/freebsd/man7/d.7 3.html +++ /dev/null @@ -1,377 +0,0 @@ - - - - - - -
D(7)Miscellaneous Information ManualD(7)
-
-
-

-

D — DTrace - scripting language overview

-
-
-

-

provider:module:function:name - [[/predicate/] - {action}]

-
-
-

-

D is the dtrace(1) - scripting language. This manual provides a brief reference of the - D language and scripting.

-

This manual page serves as a short reference of the language. - Refer to books listed in SEE ALSO for a - complete reference.

-
-
-

-

A probe's description consists of four elements:

-
provider:module:function:name
-

The exact meaning of module, - function, and name depends on - provider.

-
-
-

- - - - - - - - - - - - - - - - - - - - - -
globalvariable_name
aggregatevariable_name
thread-localvariable_name
clause-localvariable_name
-

:

-
    -
  • Always use the variable type with the smallest scope to minimize - processing overhead.
    • -
  • Use aggregate variables instead of global variables when possible. - Aggregate variables are multi-CPU safe in contrast to global - variables.
    • -
-
-
-

-
-

-
-
args[]
-
The array of typed probe arguments.
-
arg0, ..., - arg9
-
The untyped probe arguments represented as 64-bit unsigned integers. Only - the first ten arguments are available this way.
-
-
-
-

-
-
epid
-
The enabled probe ID which uniquely identifies an enabled probe. An - enabled probe is defined by its probe ID, its predicates, and its - actions.
-
id
-
The probe ID which uniquely identifies a probe available to DTrace.
-
probeprov
-
The provider in the probe's description - (provider:module:function:name).
-
probemod
-
The module in the probe's description - (provider:module:function:name).
-
probefunc
-
The function in the probe's description - (provider:module:function:name).
-
probename
-
The name in the probe's description - (provider:module:function:name).
-
-
-
-

-
-
execargs
-
The process arguments. Effectively, - ‘curthread->td_proc->p_args’.
-
execname
-
The name of the current process. Effectively, - ‘curthread->td_proc->p_comm’.
-
gid
-
The group ID of the current process.
-
pid
-
The process ID of the current process.
-
ppid
-
The parent process ID of the current process.
-
uid
-
The user ID of the current process.
-
-
-
-

-
-
uregs[]
-
The saved user-mode register values.
-
cpu
-
The ID of the current CPU.
-
stackdepth
-
The kernel stack frame depth.
-
ustackdepth
-
The userspace counterpart of stackdepth.
-
tid
-
The thread ID. Depending on the context, this can be either the ID of a - kernel thread or a thread in a user process.
-
errno
-
The errno(2) value of the last system call performed by - the current thread.
-
curlwpsinfo
-
A pointer to the lwpsinfo_t representation of the - current thread. Refer to dtrace_proc(4) for more - details.
-
curpsinfo
-
A pointer to the psinfo_t representation of the - current process. Refer to dtrace_proc(4) for more - details.
-
curthread
-
A pointer to the thread struct that is currently on-CPU. E.g., - ‘curthread->td_name’ returns the - thread name. The - <sys/proc.h> header - documents all members of struct thread.
-
caller
-
The address of the kernel thread instruction at the time of execution of - the current probe.
-
ucaller
-
The userspace counterpart of caller.
-
-
-
-

-
-
timestamp
-
The number of nanoseconds since boot. Suitable for calculating relative - time differences of elapsed time and latency.
-
vtimestamp
-
The number of nanoseconds that the current thread spent on CPU. The - counter is not increased during handling of a fired DTrace probe. Suitable - for calculating relative time differences of on-CPU time.
-
walltimestamp
-
The number of nanoseconds since the Epoch (1970-01-01T00+00:00). Suitable - for timestamping logs.
-
-
-
-
-

-
-
string - (string - s, char c)
-
Return a substring of s starting at the first - occurance of c in s. Return - NULL if c does not occur in - s. -

For example,

-
- 
strchr("abc", 'b');
-
- returns ‘bc’ and -
- 
strchr("abc", 'd');
-
- returns NULL.
-
string - (string - s1, string s2)
-
Return a string resulting from concatenating s1 and - s2. -

For example,

-
- 
strjoin("abc", "def")
-
- returns ‘abcdef’.
-
string - (string - s, char c)
-
Return a substring of s starting at the last - occurance of c in s. Similar - to strchr().
-
string - (string - haystack, string needle)
-
Return a substring of haystack starting at the first - occurrence of needle. Return - NULL if needle is not a - substring of haystack. -

For example,

-
- 
strstr("abc1bc2", "bc")
-
- returns ‘bc1bc2’ and -
- 
strstr("abc", "xy")
-
- returns NULL.
-
string - (string - s, string separators)
-
Tokenize s with separators. -

For example,

-
- 
strtok("abcdefg", "xyzd")
-
- returns ‘abc’.
-
size_t - (string - s)
-
Return the length of string s.
-
string - (string - s, int position, [int - length])
-
Return a substring of string s starting at - position. The substring will be at most - length-long. If length is not - specified, use the rest of the string. If position - is greater than the size of s, return an empty - string. -

For example,

-
- 
substr("abcd", 2)
-
- returns ‘cd’, -
- 
substr("abcd", 2, 1)
-
- returns ‘c’, and -
- 
substr("abcd", 99)
-
- returns an empty string.
-
-
-

-
-
(value)
-
Average
-
()
-
Count
-
(value, - factor, low, - high, nsteps)
-
Log-linear quantization
-
(value, - low, high, - nsteps)
-
Linear quantization
-
(value)
-
Maximum
-
(value)
-
Minimum
-
(value)
-
Power-of-two frequency distribution
-
(value)
-
Standard deviation
-
(value)
-
Sum
-
-
-
-

-

By default, dtrace(1) does not permit the use of - destructive actions.

-
-
()
-
Set a kernel breakpoint and transfer control to the - ddb(4) kernel debugger.
-
(nanoseconds)
-
Spin on the CPU for the specified number of - nanoseconds.
-
()
-
Panic the kernel.
-
-
-
-
-

-
-
/usr/share/dtrace
-
DTrace scripts shipped with FreeBSD base.
-
-
-
-

-

awk(1), dtrace(1), - tracing(7)

-

The illumos Dynamic Tracing - Guide, - https://illumos.org/books/dtrace/, - 2008.

-

Brendan Gregg and - Jim Mauro, DTrace: Dynamic Tracing - in Oracle Solaris, Mac OS X and FreeBSD, Prentice - Hall, - https://www.brendangregg.com/dtracebook/, - 2011.

-

George Neville-Neil, - Jonathan Anderson, Graeme - Jenkinson, Brian Kidney, - Domagoj Stolfa, Arun - Thomas, and Robert N. M. Watson, - Univeristy of Cambridge Computer Laboratory, - OpenDTrace Specification version 1.0, - https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-924.pdf, - Cambridge, United Kingdom, August - 2018.

-
-
-

-

This manual page first appeared in FreeBSD - 15.0.

-
-
-

-

This manual page was written by Mateusz - Piotrowski - <0mp@FreeBSD.org>.

-
-
-

-

The cwd variable which typically provides - the current working directory is not supported on - FreeBSD at the moment.

-
-
- - - - - -
October 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/development.7 3.html b/static/freebsd/man7/development.7 3.html deleted file mode 100644 index 34947732..00000000 --- a/static/freebsd/man7/development.7 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
DEVELOPMENT(7)Miscellaneous Information ManualDEVELOPMENT(7)
-
-
-

-

development — - introduction to FreeBSD development - process

-
-
-

-

FreeBSD development is split into three - major subprojects: doc, ports, and src. Doc is the documentation, such as - the FreeBSD Handbook. To read more, see:

-

https://docs.FreeBSD.org/en/books/fdp-primer/

-

Ports, described further in ports(7), are the - way to build, package, and install third party software. To read more, - see:

-

https://docs.FreeBSD.org/en/books/porters-handbook/

-

The last one, src, revolves around the source code for the base - system, consisting of the kernel, and the libraries and utilities commonly - called the world.

-

The Committer's Guide, describing topics relevant to all - committers, can be found at:

-

https://docs.freebsd.org/en/articles/committers-guide/

-

FreeBSD src development takes place in the - project-hosted Git repository, located at:

-

https://git.FreeBSD.org/src.git

-

The push URL is:

-

ssh://git@gitrepo.FreeBSD.org/src.git

-

There is also a list of public, read-only Git mirrors at:

-

https://docs.FreeBSD.org/en/books/handbook/mirrors/#external-mirrors

-

The ‘main’ Git branch - represents CURRENT; all changes are first committed to CURRENT and then - usually cherry-picked back to STABLE, which refers to Git branches such as - ‘stable/14’. Every few years a new - STABLE is branched from CURRENT, with an incremented major version number. - Releases are then branched off STABLE and numbered with consecutive minor - numbers such as ‘releng/14.3’

-

The layout of the source tree is described in its - README.md file. Build instructions can be found in - build(7) and release(7). Kernel - programming interfaces (KPIs) are documented in section 9 manual pages; use - ‘apropos -s 9 .’ for a list. - Regression test suite is described in tests(7). For coding - conventions, see style(9).

-

To ask questions regarding development, use the mailing lists, - such as freebsd-arch@ and freebsd-hackers@:

-

https://lists.FreeBSD.org

-

To get your patches integrated into the main - FreeBSD repository use Phabricator; it is a code - review tool that allows other developers to review the changes, suggest - improvements, and, eventually, allows them to pick up the change and commit - it:

-

https://reviews.FreeBSD.org

-

Or Github:

-

https://github.com/freebsd

-

To check the latest FreeBSD build and test - status of CURRENT and STABLE branches, the continuous integration system is - at:

-

https://ci.FreeBSD.org

-
-
-

-
-
/usr/src/CONTRIBUTING.md
-
FreeBSD contribution guidelines
-
/usr/src/tools/tools/git/git-arc.sh
-
Phabricator review tooling
-
/usr/ports/devel/freebsd-git-arc
-
Phabricator review tooling as a port
-
-
-
-

-

Apply a patch from Github pull #1234, using - devel/gh:

-

-
gh pr checkout 1234
-

Apply a patch from Phabricator review D1234, using - git-arc(1):

-

-
git arc patch -c D1234
-

Apply a manually downloaded git-format-patch(1), - draft.patch, from Bugzilla or mail:

-

-
git am draft.patch
-

Apply a manually downloaded patch, - draft.diff, from Bugzilla or mail:

-

-
git apply draft.diff
-
-
-

-

git(1), git-arc(1), - witness(4), build(7), - hier(7), ports(7), - release(7), tests(7), - locking(9), style(9)

-
-
-

-

The development manual page was originally - written by Matthew Dillon - <dillon@FreeBSD.org> - and first appeared in FreeBSD 5.0, December 2002. It - was since extensively modified by Eitan Adler - <eadler@FreeBSD.org> - to reflect the repository conversion from - CVS to - Subversion. It was - rewritten from scratch by Edward Tomasz Napierala - <trasz@FreeBSD.org> - for FreeBSD 12.0.

-
-
- - - - - -
September 24, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/environ.7 3.html b/static/freebsd/man7/environ.7 3.html deleted file mode 100644 index 4fd735ca..00000000 --- a/static/freebsd/man7/environ.7 3.html +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - -
ENVIRON(7)Miscellaneous Information ManualENVIRON(7)
-
-
-

-

environ — user - environment

-
-
-

-

extern char **environ;

-
-
-

-

An array of strings, called the environment - is made available to each process by execve(2) when a - process begins. By convention these strings have the form - name=value, - and are referred to as “environment variables”. A process can - query, update, and delete these strings using the - getenv(3), setenv(3), and - unsetenv(3) functions, respectively. The shells also - provide commands to manipulate the environment; they are described in the - respective shell manual pages.

-

What follows is a list of environment variables typically seen on - a UNIX system. It includes only those variables that - a user can expect to see during their day-to-day use of the system, and is - far from complete. Environment variables specific to a particular program or - library function are documented in the - ENVIRONMENT section of the appropriate - manual page.

-
-
-

-
-
-
On - , - controls the level of SIMD enhancements used. See - simd(7) for details.
-
-
The size of the block units used by several disk-related commands, most - notably df(1), du(1) and - ls(1). BLOCKSIZE may be - specified in units of a byte by specifying a number, in units of a - kilobyte by specifying a number followed by - ‘K’ or - ‘k’, in units of a megabyte by - specifying a number followed by ‘M’ - or ‘m’, and in units of a gigabyte - by specifying a number followed by - ‘G’ or - ‘g’. Sizes less than 512 bytes or - greater than a gigabyte are ignored. This variable is processed by the - getbsize(3) function.
-
-
The user's preferred width in column positions for the terminal. Utilities - such as ls(1) and who(1) use this to - format output into columns. If unset or empty, utilities will use an - ioctl(2) call to ask the terminal driver for the - width.
-
-
Default editor name.
-
-
A startup list of commands read by ex(1) and - vi(1).
-
-
Request the err(3) and uexterr_gettext - functions to unconditionally report additional information, mostly useful - for the (kernel) developer to diagnose the issue. See - err(3) and exterror(9) for more - details.
-
-
A user's login directory, set by login(1) from the - password file passwd(5).
-
-
This variable configures all programs which use - setlocale(3) to use the specified locale unless the - LC_* variables are set.
-
-
Overrides the values of LC_COLLATE, - LC_CTYPE, LC_MESSAGES, - LC_MONETARY, LC_NUMERIC, - LC_TIME and LANG.
-
-
Locale to be used for ordering of strings.
-
-
Locale to be used for character classification (letter, space, digit, - etc.) and for interpreting byte sequences as multibyte characters.
-
-
Locale to be used for diagnostic messages.
-
-
Locale to be used for interpreting monetary input and formatting - output.
-
-
Locale to be used for interpreting numeric input and formatting - output.
-
-
Locale to be used for interpreting dates input and for formatting - output.
-
-
The location of the user's mailbox instead of the default in /var/mail, - used by mail(1), sh(1), and many other - mail clients.
-
-
The sequence of directories, separated by colons, searched by - man(1) when looking for manual pages.
-
-
List of directories to be searched for the message catalog referred to by - LC_MESSAGES. See - catopen(3).
-
-
Default paginator program. The program specified by this variable is used - by mail(1), man(1), - ftp(1), etc, to display information which is longer than - the current display.
-
-
The sequence of directories, separated by colons, searched by - csh(1), sh(1), - system(3), execvp(3), etc, when - looking for an executable file. PATH is set to - ``/usr/bin:/bin'' initially by login(1).
-
-
When set to any value, this environment variable modifies the behaviour of - certain commands to (mostly) execute in a strictly POSIX-compliant - manner.
-
-
The name of the default printer to be used by lpr(1), - lpq(1), and lprm(1).
-
-
The current directory pathname.
-
-
The full pathname of the user's login shell.
-
-
The kind of terminal for which output is to be prepared. This information - is used by commands, such as nroff(1) - (ports/textproc/groff) or - plot(1) which may exploit special terminal capabilities. - See /usr/share/misc/termcap - (termcap(5)) for a list of terminal types.
-
-
The string describing the terminal in TERM, or, if - it begins with a '/', the name of the termcap file. See - TERMPATH below, and - termcap(5).
-
-
A sequence of pathnames of termcap files, separated by colons or spaces, - which are searched for terminal descriptions in the order listed. Having - no TERMPATH is equivalent to a - TERMPATH of - $HOME/.termcap:/etc/termcap. - TERMPATH is ignored if - TERMCAP contains a full pathname.
-
-
The directory in which to store temporary files. Most applications use - either /tmp or /var/tmp. - Setting this variable will make them use another directory.
-
-
The timezone to use when displaying dates. The normal format is a pathname - relative to /usr/share/zoneinfo. For example, the - command -

-
env TZ=America/Los_Angeles - date
-

displays the current time in California. See - tzset(3) for more information.

-
-
-
The login name of the user. It is recommended that portable applications - use LOGNAME instead.
-
-

Further names may be placed in the environment by the - export command and name=value - arguments in sh(1), or by the - setenv command if you use csh(1). - It is unwise to change certain sh(1) variables that are - frequently exported by .profile files, such as - MAIL, PS1, - PS2, and IFS, unless you - know what you are doing.

-

The current environment variables can be printed with - env(1), set(1) or - printenv(1) in sh(1) and - env(1), printenv(1) or the - printenv built-in command in - csh(1).

-
-
-

-

cd(1), csh(1), - env(1), err(3), ex(1), - login(1), printenv(1), - sh(1), execve(2), - execle(3), getbsize(3), - getenv(3), setenv(3), - setlocale(3), system(3), - termcap(3), termcap(5), - simd(7), exterror(9)

-
-
-

-

The environ manual page appeared in - Version 7 AT&T UNIX.

-
-
- - - - - -
September 3, 2023FreeBSD 15.0
diff --git a/static/freebsd/man7/firewall.7 3.html b/static/freebsd/man7/firewall.7 3.html deleted file mode 100644 index da348df4..00000000 --- a/static/freebsd/man7/firewall.7 3.html +++ /dev/null @@ -1,377 +0,0 @@ - - - - - - -
FIREWALL(7)Miscellaneous Information ManualFIREWALL(7)
-
-
-

-

firewall — simple - firewalls under FreeBSD

-
-
-

-

A Firewall is most commonly used to protect an internal network - from an outside network by preventing the outside network from making - arbitrary connections into the internal network. Firewalls are also used to - prevent outside entities from spoofing internal IP addresses and to isolate - services such as NFS or SMBFS (Windows file sharing) within LAN - segments.

-

The FreeBSD firewalling system also has - the capability to limit bandwidth using dummynet(4). This - feature can be useful when you need to guarantee a certain amount of - bandwidth for a critical purpose. For example, if you are doing video - conferencing over the Internet via your office T1 (1.5 MBits/s), you may - wish to bandwidth-limit all other T1 traffic to 1 MBit/s in order to reserve - at least 0.5 MBits for your video conferencing connections. Similarly if you - are running a popular web or ftp site from a colocation facility you might - want to limit bandwidth to prevent excessive bandwidth charges from your - provider.

-

Finally, FreeBSD firewalls may be used to - divert packets or change the next-hop address for packets to help route them - to the correct destination. Packet diversion is most often used to support - NAT (network address translation), which allows an internal network using a - private IP space to make connections to the outside for browsing or other - purposes.

-

Constructing a firewall may appear to be trivial, but - most people get them wrong. The most common mistake is to create an - exclusive firewall rather than an inclusive firewall. An exclusive firewall - allows all packets through except for those matching a set of rules. An - inclusive firewall allows only packets matching the ruleset through. - Inclusive firewalls are much, much safer than exclusive firewalls but a tad - more difficult to build properly. The second most common mistake is to - blackhole everything except the particular port you want to let through. - TCP/IP needs to be able to get certain types of ICMP errors to function - properly - for example, to implement MTU discovery. Also, a number of common - system daemons make reverse connections to the - service in an - attempt to authenticate the user making a connection. Auth is rather - dangerous but the proper implementation is to return a TCP reset for the - connection attempt rather than simply blackholing the packet. We cover these - and other quirks involved with constructing a firewall in the sample - firewall section below.

-
-
-

-

You do not need to create a custom kernel to use the IP - firewalling features. If you enable firewalling in your - /etc/rc.conf (see below), the ipfw kernel module - will be loaded automatically when necessary. However, if you are paranoid - you can compile IPFW directly into the FreeBSD - kernel by using the - - option set. If compiled in the kernel, ipfw denies all packets by default, - which means that, if you do not load in a permissive ruleset via - /etc/rc.conf, rebooting into your new kernel will - take the network offline. This can prevent you from being able to access - your system if you are not sitting at the console. It is also quite common - to update a kernel to a new release and reboot before updating the binaries. - This can result in an incompatibility between the ipfw(8) - program and the kernel which prevents it from running in the boot sequence, - also resulting in an inaccessible machine. Because of these problems the - - kernel option is also available which changes the default firewall to pass - through all packets. Note, however, that using this option may open a small - window of opportunity during booting where your firewall passes all packets. - Still, it is a good option to use while getting up to speed with - FreeBSD firewalling. Get rid of it once you - understand how it all works to close the loophole, though. There is a third - option called - - which allows you to use the firewall to divert packets to a user program and - is necessary if you wish to use natd(8) to give private - internal networks access to the outside world. If you want to be able to - limit the bandwidth used by certain types of traffic, the - - option must be used to enable - - rules.

-
-
-

-

Here is an example ipfw-based firewall taken from a machine with - three interface cards. fxp0 is connected to the 'exposed' LAN. Machines on - this LAN are dual-homed with both internal 10. IP addresses and - Internet-routed IP addresses. In our example, 192.100.5.x represents the - Internet-routed IP block while 10.x.x.x represents the internal networks. - While it is not relevant to the example, 10.0.1.x is assigned as the - internal address block for the LAN on fxp0, 10.0.2.x for the LAN on fxp1, - and 10.0.3.x for the LAN on fxp2.

-

In this example we want to isolate all three LANs from the - Internet as well as isolate them from each other, and we want to give all - internal addresses access to the Internet through a NAT gateway running on - this machine. To make the NAT gateway work, the firewall machine is given - two Internet-exposed addresses on fxp0 in addition to an internal 10. - address on fxp0: one exposed address (not shown) represents the machine's - official address, and the second exposed address (192.100.5.5 in our - example) represents the NAT gateway rendezvous IP. We make the example more - complex by giving the machines on the exposed LAN internal 10.0.0.x - addresses as well as exposed addresses. The idea here is that you can bind - internal services to internal addresses even on exposed machines and still - protect those services from the Internet. The only services you run on - exposed IP addresses would be the ones you wish to expose to the - Internet.

-

It is important to note that the 10.0.0.x network in our example - is not protected by our firewall. You must make sure that your Internet - router protects this network from outside spoofing. Also, in our example, we - pretty much give the exposed hosts free reign on our internal network when - operating services through internal IP addresses (10.0.0.x). This is - somewhat of security risk: what if an exposed host is compromised? To remove - the risk and force everything coming in via LAN0 to go through the firewall, - remove rules 01010 and 01011.

-

Finally, note that the use of internal addresses represents a big - piece of our firewall protection mechanism. With proper spoofing safeguards - in place, nothing outside can directly access an internal (LAN1 or LAN2) - host.

-
-
# /etc/rc.conf
-#
-firewall_enable="YES"
-firewall_type="/etc/ipfw.conf"
-
-# temporary port binding range let
-# through the firewall.
-#
-# NOTE: heavily loaded services running through the firewall may require
-# a larger port range for local-size binding.  4000-10000 or 4000-30000
-# might be a better choice.
-ip_portrange_first=4000
-ip_portrange_last=5000
-...
-
-
-
# /etc/ipfw.conf
-#
-# FIREWALL: the firewall machine / nat gateway
-# LAN0	    10.0.0.X and 192.100.5.X (dual homed)
-# LAN1	    10.0.1.X
-# LAN2	    10.0.2.X
-# sw:	    ethernet switch (unmanaged)
-#
-# 192.100.5.x represents IP addresses exposed to the Internet
-# (i.e. Internet routeable).  10.x.x.x represent internal IPs
-# (not exposed)
-#
-#   [LAN1]
-#      ^
-#      |
-#   FIREWALL -->[LAN2]
-#      |
-#   [LAN0]
-#      |
-#      +--> exposed host A
-#      +--> exposed host B
-#      +--> exposed host C
-#      |
-#   INTERNET (secondary firewall)
-#    ROUTER
-#      |
-#    [Internet]
-#
-# NOT SHOWN:  The INTERNET ROUTER must contain rules to disallow
-# all packets with source IP addresses in the 10. block in order
-# to protect the dual-homed 10.0.0.x block.  Exposed hosts are
-# not otherwise protected in this example - they should only bind
-# exposed services to exposed IPs but can safely bind internal
-# services to internal IPs.
-#
-# The NAT gateway works by taking packets sent from internal
-# IP addresses to external IP addresses and routing them to natd, which
-# is listening on port 8668.   This is handled by rule 00300.  Data coming
-# back to natd from the outside world must also be routed to natd using
-# rule 00301.  To make the example interesting, we note that we do
-# NOT have to run internal requests to exposed hosts through natd
-# (rule 00290) because those exposed hosts know about our
-# 10. network.  This can reduce the load on natd.  Also note that we
-# of course do not have to route internal<->internal traffic through
-# natd since those hosts know how to route our 10. internal network.
-# The natd command we run from /etc/rc.local is shown below.  See
-# also the in-kernel version of natd, ipnat.
-#
-#	natd -s -u -a 208.161.114.67
-#
-#
-add 00290 skipto 1000 ip from 10.0.0.0/8 to 192.100.5.0/24
-add 00300 divert 8668 ip from 10.0.0.0/8 to not 10.0.0.0/8
-add 00301 divert 8668 ip from not 10.0.0.0/8 to 192.100.5.5
-
-# Short cut the rules to avoid running high bandwidths through
-# the entire rule set.  Allow established tcp connections through,
-# and shortcut all outgoing packets under the assumption that
-# we need only firewall incoming packets.
-#
-# Allowing established tcp connections through creates a small
-# hole but may be necessary to avoid overloading your firewall.
-# If you are worried, you can move the rule to after the spoof
-# checks.
-#
-add 01000 allow tcp from any to any established
-add 01001 allow all from any to any out via fxp0
-add 01001 allow all from any to any out via fxp1
-add 01001 allow all from any to any out via fxp2
-
-# Spoof protection.  This depends on how well you trust your
-# internal networks.  Packets received via fxp1 MUST come from
-# 10.0.1.x.  Packets received via fxp2 MUST come from 10.0.2.x.
-# Packets received via fxp0 cannot come from the LAN1 or LAN2
-# blocks.  We cannot protect 10.0.0.x here, the Internet router
-# must do that for us.
-#
-add 01500 deny all from not 10.0.1.0/24 in via fxp1
-add 01500 deny all from not 10.0.2.0/24 in via fxp2
-add 01501 deny all from 10.0.1.0/24 in via fxp0
-add 01501 deny all from 10.0.2.0/24 in via fxp0
-
-# In this example rule set there are no restrictions between
-# internal hosts, even those on the exposed LAN (as long as
-# they use an internal IP address).  This represents a
-# potential security hole (what if an exposed host is
-# compromised?).  If you want full restrictions to apply
-# between the three LANs, firewalling them off from each
-# other for added security, remove these two rules.
-#
-# If you want to isolate LAN1 and LAN2, but still want
-# to give exposed hosts free reign with each other, get
-# rid of rule 01010 and keep rule 01011.
-#
-# (commented out, uncomment for less restrictive firewall)
-#add 01010 allow all from 10.0.0.0/8 to 10.0.0.0/8
-#add 01011 allow all from 192.100.5.0/24 to 192.100.5.0/24
-#
-
-# SPECIFIC SERVICES ALLOWED FROM SPECIFIC LANS
-#
-# If using a more restrictive firewall, allow specific LANs
-# access to specific services running on the firewall itself.
-# In this case we assume LAN1 needs access to filesharing running
-# on the firewall.  If using a less restrictive firewall
-# (allowing rule 01010), you do not need these rules.
-#
-add 01012 allow tcp from 10.0.1.0/8 to 10.0.1.1 139
-add 01012 allow udp from 10.0.1.0/8 to 10.0.1.1 137,138
-
-# GENERAL SERVICES ALLOWED TO CROSS INTERNAL AND EXPOSED LANS
-#
-# We allow specific UDP services through: DNS lookups, ntalk, and ntp.
-# Note that internal services are protected by virtue of having
-# spoof-proof internal IP addresses (10. net), so these rules
-# really only apply to services bound to exposed IPs.  We have
-# to allow UDP fragments or larger fragmented UDP packets will
-# not survive the firewall.
-#
-# If we want to expose high-numbered temporary service ports
-# for things like DNS lookup responses we can use a port range,
-# in this example 4000-65535, and we set to /etc/rc.conf variables
-# on all exposed machines to make sure they bind temporary ports
-# to the exposed port range (see rc.conf example above)
-#
-add 02000 allow udp from any to any 4000-65535,domain,ntalk,ntp
-add 02500 allow udp from any to any frag
-
-# Allow similar services for TCP.  Again, these only apply to
-# services bound to exposed addresses.  NOTE: we allow 'auth'
-# through but do not actually run an identd server on any exposed
-# port.  This allows the machine being authed to respond with a
-# TCP RESET.  Throwing the packet away would result in delays
-# when connecting to remote services that do reverse ident lookups.
-#
-# Note that we do not allow tcp fragments through, and that we do
-# not allow fragments in general (except for UDP fragments).  We
-# expect the TCP mtu discovery protocol to work properly so there
-# should be no TCP fragments.
-#
-add 03000 allow tcp from any to any http,https
-add 03000 allow tcp from any to any 4000-65535,ssh,smtp,domain,ntalk
-add 03000 allow tcp from any to any auth,pop3,ftp,ftp-data
-
-# It is important to allow certain ICMP types through, here is a list
-# of general ICMP types.  Note that it is important to let ICMP type 3
-# through.
-#
-#	0	Echo Reply
-#	3	Destination Unreachable (used by TCP MTU discovery, aka
-#					packet-too-big)
-#	4	Source Quench (typically not allowed)
-#	5	Redirect (typically not allowed - can be dangerous!)
-#	8	Echo
-#	11	Time Exceeded
-#	12	Parameter Problem
-#	13	Timestamp
-#	14	Timestamp Reply
-#
-# Sometimes people need to allow ICMP REDIRECT packets, which is
-# type 5, but if you allow it make sure that your Internet router
-# disallows it.
-
-add 04000 allow icmp from any to any icmptypes 0,3,8,11,12,13,14
-
-# log any remaining fragments that get through.  Might be useful,
-# otherwise do not bother.  Have a final deny rule as a safety to
-# guarantee that your firewall is inclusive no matter how the kernel
-# is configured.
-#
-add 05000 deny log ip from any to any frag
-add 06000 deny all from any to any
-
-
-
-

-

We have mentioned multi-homing hosts and binding services to - internal or external addresses but we have not really explained it. When you - have a host with multiple IP addresses assigned to it, you can bind services - run on that host to specific IPs or interfaces rather than all IPs. Take the - firewall machine for example: with three interfaces and two exposed IP - addresses on one of those interfaces, the firewall machine is known by 5 - different IP addresses (10.0.0.1, 10.0.1.1, 10.0.2.1, 192.100.5.5, and say - 192.100.5.1). If the firewall is providing file sharing services to the - windows LAN segment (say it is LAN1), you can use samba's 'bind interfaces' - directive to specifically bind it to just the LAN1 IP address. That way the - file sharing services will not be made available to other LAN segments. The - same goes for NFS. If LAN2 has your UNIX engineering workstations, you can - tell nfsd to bind specifically to 10.0.2.1. You can specify how to bind - virtually every service on the machine and you can use a light - jail(8) to indirectly bind services that do not otherwise - give you the option.

-
-
-

-

dummynet(4), ipnat(5), - rc.conf(5), smb.conf(5) - (ports/net/samba), samba(7) - (ports/net/samba), config(8), - ipfw(8), ipnat(8), - jail(8), natd(8), - nfsd(8)

-
-
-

-
-
Ipfilter
-
ipf(5), ipf(8), - ipfstat(8)
-
Packet Filter
-
pf.conf(5), pfctl(8), - pflogd(8)
-
-
-
-

-

The firewall manual page was originally - written by Matthew Dillon and first appeared in - FreeBSD 4.3, May 2001.

-
-
- - - - - -
May 26, 2001FreeBSD 15.0
diff --git a/static/freebsd/man7/freebsd-base.7 3.html b/static/freebsd/man7/freebsd-base.7 3.html deleted file mode 100644 index eebb21cc..00000000 --- a/static/freebsd/man7/freebsd-base.7 3.html +++ /dev/null @@ -1,236 +0,0 @@ - - - - - - -
FREEBSD-BASE(7)Miscellaneous Information ManualFREEBSD-BASE(7)
-
-
-

-

freebsd-base — - base system packages

-
-
-

-

The FreeBSD base system may be installed - as a set of pkg(8) packages, which supersedes the - traditional method of installing using tar(1) - archives.

-

All base packages have names beginning with the string - “FreeBSD-”, and have an origin beginning with - “base/”. In the default system configuration, the repository - containing these packages is called “FreeBSD-base”, but any - name may be used. The repository name can be used with - pkg(8) to restrict package operations to the base system - packages.

-

Packages for all supported FreeBSD - releases as well as active “STABLE” and - “CURRENT” branches are hosted on the Internet at - https://pkg.freebsd.org. - These packages are updated when new errata or security updates are released - (for supported release versions), or twice daily for development - branches.

-

Alternatively, packages may be built from the system source tree - according to the instructions in build(7), allowing the - system to be updated from source code using packages.

-
-
-

-

To allow customisation of the installed system, each package is - split into several subpackages which contain different components of the - package. For the package - , - the following subpackages may be available:

-

-
-
-
-
FreeBSD-foo
-
Base files for the package (typically executables)
-
FreeBSD-foo-lib
-
Native runtime libraries
-
FreeBSD-foo-lib32
-
32-bit compatibility runtime libraries
-
FreeBSD-foo-dev
-
Development files (headers and static libraries)
-
FreeBSD-foo-dev-lib32
-
32-bit development files
-
FreeBSD-foo-dbg
-
Debugging symbols
-
FreeBSD-foo-man
-
Manual pages. Manual pages are only packaged separately if the - - src.conf(5) option was enabled when building the system, - which is not the default.
-
-

The exact set of available subpackages differs for each - individual package. For example, some packages may not provide any - development files, in which case the - subpackage is - not present.

-
-
-

-

Package sets are meta-packages which do not contain any files - themselves, but depend on a selection of other packages, such that each - package set allows the complete set of packages for a supported workload to - be installed.

-

Package sets are provided as packages - named - . - The following package sets are available in the base system:

-
-
minimal
-
The minimal set of packages required to bring up a multi-user - FreeBSD system. This includes the core system, - along with packages required for hardware support (such as - devmatch(8) and downloadable firmware), and basic - networking, including DHCP and IEEE Std 802.11™ wireless - networks.
-
minimal-jail
-
The equivalent of minimal for systems running in a - jail(8) environment. This set excludes hardware support - not typically required for jails.
-
devel
-
Development tools, including C/C++ compilers, the link loader, and other - tools such as ar(1) and nm(1). This - set also includes native development files (headers and static libraries) - for all packages.
-
optional
-
Optional software which is not part of either the devel - or minimal sets.
-
optional-jail
-
The equivalent of optional for systems running in a - jail(8) environment. This set excludes system - functionality which typically does not work or is not useful in a - jail.
-
lib32
-
32-compatibility libraries, for running 32-bit applications on a 64-bit - host system. This set includes both runtime libraries and development - files.
-
base
-
The complete base system, excluding tests, the system source code, and - debugging symbols. Installing the base set is equivalent - to installing minimal, devel and - optional.
-
base-jail
-
The equivalent of base for systems running in a - jail(8) environment. This set excludes system - functionality which typically does not work or is not useful in a jail. - Installing the - set - is equivalent to installing minimal-jail, - devel and - .
-
src
-
The system source tree for the userland and kernel, installed in - /usr/src.
-
tests
-
The system test suite, installed in - /usr/tests.
-
kernels
-
All available system kernels.
-
-
-
-

-
-

-

Install the vi(1) text editor on the running - system:

-
-
pkg install FreeBSD-vi
-
-
-
-

-

Install a new jail(8) system using the - minimal-jail package set:

-
-
pkg -r /jails/myjail install FreeBSD-set-minimal-jail
-
-
-
-

-

Install C/C++ compilers on the running system:

-
-
pkg install FreeBSD-set-devel
-
-
-
-

-

Apply available updates to the running system:

-
-
pkg upgrade -r FreeBSD-base
-
-
-
-

-

Install the development toolchain for FreeBSD/powerpc64le in an - alternate root (for example, to support cross-compiling software for a - different target than the host system):

-
-
pkg -r /ppcdev -oABI=FreeBSD:16:powerpc64le \
-    install FreeBSD-set-devel
-
-
-
-

-

Systems managed through pkg(8) can be - unregistered from the package manager — for example to upgrade - in-place via “make installworld”. See - build(7).

-

To unregister the base system from the package manager:

-
-
pkg unregister -fg 'FreeBSD-\*'
-
-

Then, disable the base system package repository. If a - configuration file was created in - /usr/local/etc/pkg/repos/ to enable base system - packages, remove it:

-
-
rm /usr/local/etc/pkg/repos/FreeBSD-base.conf
-
-

Alternatively, if it is desired to keep it, edit the file and - change “enabled:” to - “no” to disable the entry.

-

: - This is a destructive action which will prevent updating the base system via - pkg(8).

-
-
-
-

-

build(7), pkg(8), - src.conf(5)

-
-
-

-

Support for installing the base system as packages was introduced - in FreeBSD 15.0. Earlier releases supported a subset - of this functionality. Support for unregistering an existing installation - appeared in pkg 2.5.

-
-
-

-

Upgrading from a RELEASE to a STABLE or CURRENT branch requires - “pkg upgrade -f”.

-
-
- - - - - -
April 14, 2026FreeBSD 15.0
diff --git a/static/freebsd/man7/growfs.7 3.html b/static/freebsd/man7/growfs.7 3.html deleted file mode 100644 index 36f73630..00000000 --- a/static/freebsd/man7/growfs.7 3.html +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - -
GROWFS(7)Miscellaneous Information ManualGROWFS(7)
-
-
-

-

growfs, - growfs_fstab — start up - scripts to grow the root file system and add swap

-
-
-

-

The growfs script normally runs at the - first boot after system installation. If the boot disk is larger than the - root file system and boot partitions, and the root file system is in the - last partition, growfs can expand the root file - system. It can also add a swap partition, with a default size of 10% of the - boot disk. Swap is limited to twice the memory size up to 4 GB, 8 GB up to 8 - GB of memory, and memory size over 8 GB. It is also limited to the - sysctl(8) value of - vm.swap_maxpages divided by 2. By default, no swap - partition is created if an existing swap partition is found or is listed in - /etc/fstab, or the disk is under 15 GB. The - growfs_fstab script adds any new swap partition to - /etc/fstab after the root file system is made - writable, and enables its use as a dump partition if the - dumpdev variable from rc.conf(5) is - set to AUTO.

-

The following options in /etc/rc.conf - control the behavior of growfs:

-
-
-
growfs_enable
-
(“NO”) If set to - “YES”, the first time the machine - boots, the root file system will be automatically expanded, if possible, - to fill up all available space after it, after optionally adding a swap - device at the end.
-
growfs_swap_size
-
(“”) If set to - “0”, the addition of a swap - partition is disabled. An empty value - (“”) allows the creation of a swap - partition with the default size. If set to another value, the swap - partition will be created with the specified size in bytes, even if - another swap partition is detected.
-
-
-

A setting for growfs_swap_size can be set in - the kernel environment, in which case it overrides the value from - /etc/rc.conf.

-

To expand the root file system without rebooting, run the - following command:

-
% /etc/rc.d/growfs - onestart
-In addition, if a swap partition is added, run the command: -
% /etc/rc.d/growfs_fstab - onestart
-Note that if a disk is expanded again, and if the root file system had - previously been expanded and a swap partition added, it is necessary to delete - the swap partition before this procedure in order to expand the root file - system to the new size. A new swap partition can be created during the - expansion. -
-
-

-

The growfs script only attempts to expand - the root file system, and free space must be available immediately after the - root partition. It is normally used on images that have a single file - system. The script requires that awk(1) be present and in - the path. This usually means that /usr must be - available prior to running the script.

-
-
-

-
-
/etc/fstab
-
 
-
/etc/rc.conf
-
 
-
-
-
-

-

The growfs utility exits 0 on - success, and >0 if an error occurs.

-
-
-

-

fstab(5), rc.conf(5), - growfs(8), zpool(8)

-
-
-

-

The growfs manual page first appeared in - FreeBSD 10.1. The ability to add a swap partition - was added in FreeBSD 13.2.

-
-
-

-

The man page and script were written by John-Mark - Gurney - <jmg@FreeBSD.org>. The - ability to create a swap partition was added by -
- Michael Karels - <karels@FreeBSD.org>.

-
-
- - - - - -
November 22, 2022FreeBSD 15.0
diff --git a/static/freebsd/man7/hier.7 3.html b/static/freebsd/man7/hier.7 3.html deleted file mode 100644 index d4e024a0..00000000 --- a/static/freebsd/man7/hier.7 3.html +++ /dev/null @@ -1,823 +0,0 @@ - - - - - - -
HIER(7)Miscellaneous Information ManualHIER(7)
-
-
-

-

hier — index of - FreeBSD file system hierarchy

-
-
-

-
-
/
-
root directory of the file system
-
/COPYRIGHT
-
FreeBSD copyright information
-
/bin/
-
fundamental BSD user utilities; see - intro(1)
-
/boot/
-
programs and configurations used during FreeBSD - boot(8) -

-
-
defaults/
-
default boot configuration files; see - loader.conf(5)
-
device.hints
-
kernel variables for controlling drivers; see - device.hints(5)
-
dtb/
-
compiled flattened device tree (FDT) files; see - fdt(4) and dtc(1) -

-
-
overlays/
-
compiled fdt(4) overlays; see - fdt_overlays in - loader.conf(5)
-
-

-
-
efi/
-
the uefi(8) EFI System Partition (ESP) mount - point
-
firmware/
-
loadable binary firmware kernel modules
-
fonts/
-
binary bitmap console fonts; see loader.conf(5) and - vtfontcvt(8)
-
images/
-
beastie boot menu images; see loader_lua(8)
-
kernel/
-
FreeBSD kernel and modules; see - kldstat(8)
-
kernel.old/
-
alternative kernel and modules
-
loader.conf
-
boot loader configuration; see loader.conf(5)
-
loader.conf.d/
-
loader.conf(5) configuration files
-
lua/
-
scripts for the Lua boot loader; see - loader_lua(8)
-
modules/
-
third-party loadable kernel modules, such as those installed with - pkg(8) or from ports(7)
-
zfs/
-
ZFS zpool(8) cache files
-
-
-
/compat/
-
files supporting binary compatibility with other operating systems -

-
-
linux/
-
default location for linux(4) compatibility - run-time
-
-
-
/dev/
-
device nodes and special files; see intro(4) and - devfs(4) -

-
-
ada0
-
first ATA storage device
-
ada0p1
-
first partition on ada0
-
cd0
-
first optical drive
-
cuaU0
-
first USB serial port; see cu(1)
-
da0
-
first SCSI storage device
-
da0s1
-
first partition on da0
-
dri/
-
GPU character device nodes; see drm(7)
-
drm/
-
GPU drm(7) special files
-
fd/
-
file descriptor files; see fd(4)
-
fd0
-
first floppy drive
-
gpt/
-
storage partitions by GPT label
-
mmcsd0
-
first SD storage device
-
mmcsd0s1
-
first partition on mmcsd0
-
nda0
-
first NVMe storage device attached via cam(3)
-
null
-
infinite loop that accepts anything and contains nothing
-
nvd0
-
first NVMe storage device using NVMe namespaces
-
pts/
-
pseudo-terminals; see pts(4)
-
random
-
source of weak randomness; see random(4)
-
sa0
-
first tape drive
-
usb/
-
USB busses
-
vmm/
-
active bhyve(8) virtual machines
-
zvol/
-
zfs(8) volumes
-
-
-
/entropy
-
provides initial state to RNG; see save-entropy(8)
-
/etc/
-
base system configuration files and scripts; see - intro(5) -

-
-
auto_master
-
autofs automount(8) configuration
-
bluetooth/
-
bluetooth configuration files
-
cron.d/
-
tables for driving scheduled tasks; see - crontab(5)
-
crontab
-
root's cron table
-
defaults/
-
default system configuration files; see rc(8)
-
devd/
-
configuration for devd(8), the device state change - daemon
-
devfs.conf
-
boot time device configuration
-
dma/
-
configuration for dma(8)
-
freebsd-update.conf
-
configuration for the base system updater; see - freebsd-update(8)
-
fstab
-
static filesystem configuration; see fstab(5)
-
hosts
-
database of local hosts if no network name server is running
-
inetd.conf
-
configuration for BSD heritage internet - servers; see inetd(8)
-
localtime
-
local timezone information; see ctime(3)
-
jail.conf.d/
-
jail(8) startup scripts
-
login.conf
-
login class capability database; see - login.conf(5)
-
machine-id
-
defines the UUID for the local system, required for dbus
-
mail/
-
sendmail(8) control files -

-
-
aliases
-
addresses to deliver system mail
-
mailer.conf
-
mailwrapper(8) configuration
-
-

-
-
motd.template
-
message displayed upon tty login; see motd(5)
-
mtree/
-
system mapper specification; see mtree(8)
-
newsyslog.conf.d/
-
log rotation configuration files.
-
ntp/
-
stored time for the Network Time Protocol
-
ntp.conf
-
configuration for the NTP client, ntpd(8)
-
pam.d/
-
configuration files for the Pluggable Authentication Modules (PAM) - library; see pam(3)
-
periodic/
-
scripts that are run daily, weekly, or monthly by - cron(8); see periodic(8)
-
pf.conf
-
configuration for the Packet Filter firewall; see - pf(4)
-
pkg/
-
default configuration for the package manager, - pkg(8)
-
ppp/
-
PPP configuration files; see ppp(8)
-
rc.conf
-
system and daemon configuration; see rc.conf(5)
-
rc.d/
-
system and daemon startup/control scripts; see - rc(8)
-
resolv.conf
-
DNS configuration; see resolv.conf(5)
-
resolvconf.conf
-
DNS configuration manager configuration, often generated by - local-unbound; see local-unbound(8) or - resolvconf(8)
-
security/
-
OpenBSM audit configuration files; see audit(8)
-
ssh/
-
OpenSSH configuration files; see ssh(1)
-
ssl/
-
OpenSSL configuration files -

-
-
cert.pem
-
System trust store in bundle form; see - certctl(8).
-
certs/
-
System trust store in OpenSSL hashed-directory form; see - certctl(8).
-
openssl.cnf
-
OpenSSL configuration file; see - openssl.cnf(5).
-
untrusted/
-
Explicitly distrusted certificates; see - certctl(8).
-
-
-
sysctl.conf
-
kernel state defaults; see sysctl.conf(5)
-
syslog.conf
-
system message log configuration
-
ttys
-
tty creation configuration; see getty(8)
-
wpa_supplicant.conf
-
client wifi configuration; see - wpa_supplicant.conf(5)
-
-
-
/home/
-
home directories for users; the typical home for an interactive user - beastie would be - /home/beastie/
-
/lib/
-
system libraries critical to binaries in /bin and - /sbin -

-
-
geom/
-
class-specific libraries for the geom(8) - utility
-
nvmecontrol/
-
vendor-specific libraries to extend the - nvmecontrol(8) utility
-
-
-
/libexec/
-
system utilities critical to binaries in /bin and - /sbin
-
/media/
-
mount points for removable storage media such as CDs, DVDs, and USB - drives; see automount(8), or - bsdisks(8) if a using a desktop environment from - ports(7)
-
/mnt/
-
empty directory commonly used by system administrators as a temporary - mount point
-
/net/
-
automounted NFS shares; see auto_master(5)
-
/nonexistent/
-
a non-existent directory; by convention, it serves as a home directory for - user accounts that need no home directory; see also - /var/empty/
-
/proc/
-
process file system; see procfs(4)
-
/rescue/
-
statically linked programs for emergency recovery; see - rescue(8)
-
/root/
-
home directory of the root user
-
/sbin/
-
fundamental BSD system administration utilities; - see intro(8)
-
/tmp/
-
temporary files commonly removed between system reboots; see - clear_tmp_enable in - rc.conf(5)
-
/usr/
-
contains the majority of user utilities and applications -

-
-
bin/
-
common utilities, programming tools, and applications; see - intro(1)
-
freebsd-dist/
-
distribution files (like base.txz); see release(7) - and bsdinstall(8)
-
include/
-
standard C include header files
-
lib/
-
shared and ar(1)-type libraries; see - intro(3) -

-
-
clang/
-
shared libraries for the system compiler, - clang(1)
-
compat/
-
shared libraries for compatibility
-
debug/
-
standalone debug data for the kernel and base system libraries and - binaries
-
dtrace/
-
dtrace(1) library scripts
-
engines/
-
OpenSSL (Cryptography/SSL toolkit) dynamically loadable - engines
-
flua/
-
FreeBSD Lua shared libraries
-
i18n/
-
shared libraries for internationalization
-
-

-
-
lib32/
-
32-bit compatibility libraries
-
libdata/
-
miscellaneous utility data files -

-
-
ldscripts/
-
linker scripts; see ld(1)
-
pkgconfig/
-
collections of compiler and linker flags for the - pkgconf(1) development tool
-
-

-
-
libexec/
-
system daemons and utilities executed by programs -

-
-
bsdconfig/
-
utilities called by the ncurses FreeBSD - configuration wizard
-
bsdinstall/
-
utilities for bsdinstall(8)
-
dwatch/
-
profiles for dwatch(1)
-
fwget/
-
utilities called by fwget(8)
-
hyperv/
-
scripts for communicating with the Hyper-V hypervisor
-
lpr/
-
utilities and filters for the line printer system; see - lpr(1)
-
sendmail/
-
the sendmail(8) binary; see - mailwrapper(8)
-
sm.bin/
-
restricted shell for sendmail(8); see - smrsh(8)
-
zfs/
-
Z file system utilities
-
-

-
-
local/
-
local executables, libraries, etc, installed by - pkg(7) or ports(7) -

-
-
bin/
-
local user utilities, see intro(1)
-
etc/
-
local program configurations
-
include/
-
local library headers
-
lib/
-
local libraries
-
lib32/
-
local 32-bit compatibility libraries
-
libdata/
-
local utility data files
-
libexec/
-
utilities executed by local utilities
-
sbin/
-
local administration utilities
-
share/
-
local architecture-independent files
-
share/doc/
-
local documentation
-
share/doc/freebsd/
-
articles, books, FAQ, and handbooks available from the - FreeBSD project
-
share/man/
-
local manual pages; see man(1)
-
-

-
-
obj/
-
architecture-specific target tree produced by building - FreeBSD from source; see - build(7)
-
ports/
-
FreeBSD ports collection; see - ports(7)
-
sbin/
-
system daemons and utilities meant for user execution; see - intro(8)
-
share/
-
architecture-independent files -

-
-
atf/
-
scripts for the Automated Testing Framework; see - ATF(7)
-
bhyve/
-
bhyve(8) keyboard mappings
-
calendar/
-
system-wide calendar files; see calendar(1)
-
certs/
-
TLS certificates for openssl(1)
-
dict/
-
word lists; see look(1) -

-
-
freebsd
-
FreeBSD-specific terms, proper names, - and jargon
-
web2
-
words from Webster's Second International
-
-

-
-
doc/
-
miscellaneous documentation
-
dtrace/
-
scripts for the Dynamic Tracing Compiler; see - dtrace(1)
-
examples/
-
various examples for users and programmers
-
firmware/
-
firmware images loaded by userland programs
-
games/
-
ASCII text files used by BSD heritage - games, see intro(6)
-
keys/
-
known trusted and revoked keys -

-
-
pkg/
-
fingerprints for pkg(7) and - pkg(8)
-
-

-
-
locale/
-
localization files; see setlocale(3)
-
man/
-
system manual pages; see man(1)
-
misc/
-
miscellaneous system-wide files -

-
-
ascii
-
chart of the ASCII codepoints
-
flowers
-
the meanings of flowers
-
magic
-
magic numbers used by file(1)
-
termcap
-
terminal characteristics database; see - termcap(5)
-
-

-
-
mk/
-
templates for make; see make(1)
-
nls/
-
national language support files
-
security/
-
data files for security policies such as - mac_lomac(4)
-
sendmail/
-
sendmail(8) configuration files
-
skel/
-
example . (dot) files for new - accounts
-
snmp/
-
MIBs, example files and tree definitions for the SNMP daemon -

-
-
defs/
-
tree definition files for use with - gensnmptree(1)
-
mibs/
-
management Information Base (MIB) files
-
-

-
-
syscons/
-
syscons(4) files -

-
-
fonts/
-
console fonts; see vidcontrol(1) and - vidfont(1)
-
keymaps/
-
console keyboard maps; see kbdcontrol(1) and - kbdmap(1)
-
scrnmaps/
-
console screen maps
-
-

-
-
sysroot/
-
files necessary for the -sysroot compiler/linker argument to build - non-native binaries -

-
-
VERSION/
-
files for FreeBSD release VERSION; by - convention, “VERSION” matches - uname(1) -r
-
VERSION/MACHINE.MACHINE_ARCH/
-
represent the binary ABI for these files; - “MACHINE” matches uname(1) - -m; “MACHINE_ARCH” - matches uname(1) - -p
-
-

-
-
tabset/
-
tab description files for a variety of terminals; used in the - termcap file; see termcap(5)
-
vi/
-
localization support and utilities for the vi(1) - editor
-
vt/
-
files used by the system console; see vt(4) -

-
-
fonts/
-
console fonts; see vidcontrol(1), - vidfont(1), and - vtfontcvt(8)
-
keymaps/
-
console keyboard maps; see kbdcontrol(1) and - kbdmap(1)
-
-

-
-
zoneinfo/
-
timezone configuration information; see - tzfile(5)
-
-

-
-
src/
-
FreeBSD source code; see - development(7); the layout of the source tree is - described by the top-level README.md file -

-
-
tests/
-
the FreeBSD test suite; see - tests(7)
-
-
-
/var/
-
log, temporary, transient, and spool files -

-
-
account/
-
system accounting files -

-
-
acct
-
execution accounting file; see acct(5)
-
-

-
-
at/
-
timed command scheduling files; see at(1) -

-
-
jobs/
-
job files
-
spool/
-
output spool files
-
-

-
-
audit/
-
security event audit trail files; see audit(8)
-
authpf/
-
user shell sessions for authenticating gateways; see - authpf(8)
-
backups/
-
critical system configuration backups
-
cache/
-
miscellaneous cache files -

-
-
pkg/
-
cached packages for pkg(8)
-
cups/
-
cached printers for the Common Unix Prinitng system; see - cups(1)
-
-

-
-
crash/
-
default directory to store kernel crash dumps; see - crash(8) and savecore(8)
-
cron/
-
files used by cron; see cron(8) -

-
-
tabs/
-
crontab files; see crontab(5)
-
-

-
-
db/
-
autogenerated system-specific database files -

-
-
etcupdate/
-
temporary files and log for etcupdate(8)
-
freebsd-update/
-
downloads and temporary files for - freebsd-update(8)
-
pkg/
-
package database
-
-

-
-
empty/
-
for use by programs that require an empty directory, used for instance - by sshd(8) for privilege separation
-
games/
-
status and score files for BSD heritage - games
-
heimdal/
-
Kerberos server databases; see kdc(8)
-
lib/
-
state information for ported Linux applications
-
log/
-
system log files -

-
-
Xorg.0.log
-
Xserver(1) log, if X(7) is - installed rotates to Xorg.0.log.old
-
aculog
-
serial line access log; see cu(1)
-
auth.log
-
system authentication log
-
bsdinstall_log
-
system installation log
-
cron
-
scheduled task log; see cron(8)
-
cups/
-
logs for cups(1)
-
daemon.log
-
default log for system daemons
-
devd.log
-
default log for device state change daemon
-
dmesg.today
-
kernel message buffer log, rotates to - dmesg.yesterday
-
debug.log
-
undiscarded debug syslog messages
-
lpd-errs
-
logs for the line printer spooler daemon; see - lpd(8)
-
maillog
-
sendmail(8) log, rotates and compresses to - maillog.0.bz2
-
messages
-
general system message log; see syslogd(8)
-
mount.today
-
currently loaded fstab(5), rotates to - mount.yesterday
-
pf.today
-
packet filter firewall log; see pf(4)
-
pflog
-
saved packets caught by pflogd(8)
-
ppp.log
-
see ppp(8)
-
security
-
transcript of events marked with the security flag
-
setuid.today
-
listing of executable files which run with elevated permissions, - rotates to setuid.yesterday
-
userlog
-
logs changes in users or groups
-
utx.lastlogin
-
last login log; see getutxent(3)
-
utx.log
-
login/logout log; see getutxent(3)
-
-

-
-
mail/
-
user mailbox files
-
msgs/
-
system messages database; see msgs(1)
-
preserve/
-
unused, present for historical reasons
-
quotas/
-
UFS quota information files
-
run/
-
files containing information about the operating system since it was - booted -

-
-
bhyve/
-
bhyve(8) virtual machine - unix(4)-domain sockets
-
ppp/
-
writable by the “network” group for command - connection sockets; see ppp(8)
-
utx.active
-
database of current users; see getutxent(3)
-
wpa_supplicant/
-
IEEE Std. 802.11 wifi run time files
-
-

-
-
rwho/
-
information about other systems on the local network; see - rwhod(8), rwho(1), and - ruptime(1)
-
spool/
-
printer and mail system spooling directories -

-
-
clientmqueue/
-
undelivered submission mail queue; see - sendmail(8)
-
cups/
-
print jobs and temporary files for cups(1)
-
dma/
-
undelivered mail queue for DragonFly Mail - Agent; see dma(8)
-
lock/
-
serial device locks; see uucplock(3)
-
lpd/
-
line printer spooler daemon spool
-
mqueue/
-
undelivered mail queue for sendmail(8)
-
output/
-
line printer spooling directories
-
-

-
-
tmp/
-
temporary files not removed between system reboots -

-
-
vi.recover/
-
recovery files for the vi(1) editor
-
-

-
-
unbound/
-
files and configuration for unbound(8)
-
yp/
-
the NIS maps; see yp(8)
-
-
-
-
-
-

-

This manual page documents the default - FreeBSD file system layout. The actual hierarchy on - a given system is defined at the system administrator's discretion. A - well-maintained installation will include a customized version of this - document.

-
-
-

-

apropos(1), find(1), - grep(1), ls(1), - whereis(1), which(1)

-
-
-

-

A hier manual page first appeared in 1979 - with Version 7 AT&T UNIX.

-
-
- - - - - -
September 25, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/hostname.7 3.html b/static/freebsd/man7/hostname.7 3.html deleted file mode 100644 index 9249469a..00000000 --- a/static/freebsd/man7/hostname.7 3.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
HOSTNAME(7)Miscellaneous Information ManualHOSTNAME(7)
-
-
-

-

hostname — host - name resolution description

-
-
-

-

Hostnames are domains, where a domain is a hierarchical, - dot-separated list of subdomains; for example, the machine monet, in the - Berkeley subdomain of the EDU subdomain of the Internet would be represented - as

-

-
monet.Berkeley.EDU
-

(with no trailing dot).

-

Hostnames are often used with network client and server programs, - which must generally translate the name to an address for use. (This - function is generally performed by the library routine - gethostbyname(3).) Hostnames are resolved by the Internet - name resolver in the following fashion.

-

If the name consists of a single component, i.e., contains no dot, - and if the environment variable - “HOSTALIASES” is set to the name of a - file, that file is searched for any string matching the input hostname. The - file should consist of lines made up of two white-space separated strings, - the first of which is the hostname alias, and the second of which is the - complete hostname to be substituted for that alias. If a case-insensitive - match is found between the hostname to be resolved and the first field of a - line in the file, the substituted name is looked up with no further - processing.

-

If the input name ends with a trailing dot, the trailing dot is - removed, and the remaining name is looked up with no further processing.

-

If the input name does not end with a trailing dot, it is looked - up by searching through a list of domains until a match is found. The - default search list includes first the local domain, then its parent domains - with at least 2 name components (longest first). For example, in the domain - CS.Berkeley.EDU, the name lithium.CChem will be checked first as - lithium.CChem.CS.Berkeley.EDU and then as lithium.CChem.Berkeley.EDU. - Lithium.CChem.EDU will not be tried, as there is only one component - remaining from the local domain. The search path can be changed from the - default by a system-wide configuration file (see - resolver(5)).

-
-
-

-

gethostbyname(3), - resolver(5)

-
-
-

-

Hostname appeared in - 4.2BSD.

-
-
- - - - - -
December 25, 2013FreeBSD 15.0
diff --git a/static/freebsd/man7/intro.7 4.html b/static/freebsd/man7/intro.7 4.html deleted file mode 100644 index 428df7e3..00000000 --- a/static/freebsd/man7/intro.7 4.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - -
INTRO(7)Miscellaneous Information ManualINTRO(7)
-
-
-

-

intro — - miscellaneous information pages

-
-
-

-

This section contains miscellaneous documentation.

-
-
-
arch(7)
-
supported CPU architectures and platforms
-
ascii(7)
-
map of ASCII character set
-
build(7)
-
build instructions for FreeBSD
-
c(7)
-
the C programming language
-
clocks(7)
-
system timekeeping clocks available in - FreeBSD
-
crypto(7)
-
cryptographic algorithms provided by OpenCrypto in - FreeBSD
-
d(7)
-
dtrace(1) scripting language overview
-
development(7)
-
development introduction to FreeBSD
-
environ(7)
-
user environment
-
firewall(7)
-
simple firewalls under FreeBSD
-
hier(7)
-
file system hierarchy in FreeBSD
-
hostname(7)
-
host name resolution description
-
networking(7)
-
network connection quickstart guide
-
release(7)
-
layout of FreeBSD releases and snapshots
-
ports(7)
-
introduction to the ports infrastructure of - FreeBSD
-
security(7)
-
security features available in FreeBSD
-
stats(7)
-
statistics utilities available in FreeBSD
-
tests(7)
-
introduction to the FreeBSD Test Suite
-
tracing(7)
-
introduction to tracing and performance monitoring facilities
-
tuning(7)
-
general advice on tuning FreeBSD
-
-
-
-
-

-

man(1), intro(2), - intro(3), intro(4), - intro(5), intro(6), - intro(8), intro(9)

-
-
-

-

The intro section manual page appeared in - 4.2BSD.

-
-
- - - - - -
July 14, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/maclabel.7 3.html b/static/freebsd/man7/maclabel.7 3.html deleted file mode 100644 index caf98dc0..00000000 --- a/static/freebsd/man7/maclabel.7 3.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - -
MACLABEL(7)Miscellaneous Information ManualMACLABEL(7)
-
-
-

-

maclabel — - Mandatory Access Control label format

-
-
-

-

If Mandatory Access Control, or MAC, is enabled in the kernel, - then in addition to the traditional credentials, each subject (typically a - user or a socket) and object (file system object, socket, etc.) is given a - . - The MAC label specifies the necessary subject-specific or object-specific - information necessary for a MAC security policy to enforce access control on - the subject/object.

-

The format for a MAC label is defined as follows:

-

-
policy1/qualifier1,policy2/qualifier2,...
-

A MAC label consists of a policy name, followed by a forward - slash, followed by the subject or object's qualifier, optionally followed by - a comma and one or more additional policy labels. For example:

-
-
biba/low(low-low)
-biba/high(low-high),mls/equal(equal-equal),partition/0
-
-
-
-

-

mac(3), posix1e(3), - mac_biba(4), mac_bsdextended(4), - mac_ifoff(4), mac_mls(4), - mac_none(4), mac_partition(4), - mac_seeotheruids(4), mac_test(4), - login.conf(5), getfmac(8), - getpmac(8), ifconfig(8), - setfmac(8), setpmac(8), - mac(9)

-
-
-

-

MAC first appeared in FreeBSD 5.0.

-
-
-

-

This software was contributed to the - FreeBSD Project by NAI Labs, the Security Research - Division of Network Associates Inc. under DARPA/SPAWAR contract - N66001-01-C-8035 (“CBOSS”), as part of the DARPA CHATS - research program.

-
-
- - - - - -
October 25, 2002FreeBSD 15.0
diff --git a/static/freebsd/man7/mitigations.7 3.html b/static/freebsd/man7/mitigations.7 3.html deleted file mode 100644 index c261ebf5..00000000 --- a/static/freebsd/man7/mitigations.7 3.html +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -
MITIGATIONS(7)Miscellaneous Information ManualMITIGATIONS(7)
-
-
-

-

mitigations — - FreeBSD Security Vulnerability Mitigations

-
-
-

-

In FreeBSD, various security mitigations - are employed to limit the impact of vulnerabilities and protect the system - from malicious attacks. Some of these mitigations have run-time controls to - enable them on a global or per-process basis, some are optionally enabled or - disabled at compile time, and some are inherent to the implementation and - have no controls.

-

The following vulnerability mitigations are covered in this - document:

-

-
    -
  • Address Space Layout Randomization (ASLR)
    • -
  • Position Independent Executable (PIE)
    • -
  • Write XOR Execute page protection policy
    • -
    • -
  • Relocation Read-Only (RELRO)
    • -
  • Bind Now
    • -
  • Stack Overflow Protection
    • -
  • Supervisor Mode Memory Protection
    • -
  • Capsicum
    • -
  • Firmware and Microcode
    • -
  • Architectural Vulnerability Mitigations
    • -
-

Please note that the effectiveness and availability of these - mitigations may vary depending on the FreeBSD - version and system configuration.

-
-
-

-

Security vulnerability mitigations are techniques employed in - FreeBSD to limit the potential impact of security - vulnerabilities in software and hardware. It is essential to understand that - mitigations do not directly address the underlying security issues. They are - not a substitute for secure coding practices. Mitigations serve as an - additional layer of defense, helping to reduce the likelihood of a - successful exploitation of vulnerabilities by making it more difficult for - attackers to achieve their objectives.

-

This manual page describes the security mitigations implemented in - FreeBSD to enhance the overall security of the - operating system. Each mitigation is designed to protect against specific - types of attacks and vulnerabilities.

-
-
-

-
-

-

Address Space Layout Randomization (ASLR) is a security mitigation - technique that works by randomizing the memory addresses where system and - application code, data, and libraries are loaded, making it more challenging - for attackers to predict the memory layout and exploit vulnerabilities.

-

ASLR introduces randomness into the memory layout during process - execution, reducing the predictability of memory addresses. ASLR is intended - to make exploitation more difficult in the event that an attacker discovers - a software vulnerability, such as a buffer overflow.

-

ASLR can be enabled on both a global and per-process basis. Global - control is provided by a separate set of sysctl(8) knobs - for 32- and 64-bit processes. It can be or disabled on a per-process basis - via proccontrol(1). Note that an ASLR mode change takes - effect upon address space change, i.e., upon - execve(2).

-

Global controls for 32-bit processes:

-
-
kern.elf32.aslr.enable
-
Enable ASLR for 32-bit ELF binaries, other than Position Independent - Executable (PIE) binaries.
-
kern.elf32.aslr.pie_enable
-
Enable ASLR for 32-bit Position Independent Executable (PIE) ELF - binaries.
-
kern.elf32.aslr.honor_sbrk
-
Reserve the legacy sbrk(2) region for compatibility with - older binaries.
-
kern.elf32.aslr.stack
-
Randomize the stack location for 32-bit ELF binaries.
-
-

Global controls for 64-bit processes:

-
-
kern.elf64.aslr.enable
-
Enable ASLR for 64-bit ELF binaries, other than Position Independent - Executable (PIE) binaries.
-
kern.elf64.aslr.pie_enable
-
Enable ASLR for 64-bit Position Independent Executable (PIE) ELF - binaries.
-
kern.elf64.aslr.honor_sbrk
-
Reserve the legacy sbrk(2) region for compatibility with - older binaries.
-
kern.elf64.aslr.stack
-
Randomize the stack location for 64-bit ELF binaries.
-
-

To execute a command with ASLR enabled or disabled:

-

proccontrol -m aslr - [-s enable | - disable] command

-
-
-

-

PIE binaries are executable files that do not have a fixed load - address. They can be loaded at an arbitrary memory address by the - rtld(1) run-time linker. With ASLR they are loaded at a - random address on each execution.

-
-
-

-

Write XOR Execute (W^X) is a vulnerability mitigation strategy - that strengthens the security of the system by controlling memory access - permissions.

-

Under the W^X mitigation, memory pages may be writable (W) or - executable (E), but not both at the same time. This means that code - execution is prevented in areas of memory that are designated as writable, - and writing or modification of memory is restricted in areas marked for - execution. Applications that perform Just In Time (JIT) compilation need to - be adapted to be compatible with W^X.

-

There are separate sysctl(8) knobs to control - W^X policy enforcement for 32- and 64-bit processes. The W^X policy is - enabled by setting the appropriate allow_wx sysctl - to 0.

-
-
kern.elf32.allow_wx
-
Allow 32-bit processes to map pages simultaneously writable and - executable.
-
kern.elf64.allow_wx
-
Allow 64-bit processes to map pages simultaneously writable and - executable.
-
-
-
-

-

PROT_MAX is a - FreeBSD-specific extension to - mmap(2). PROT_MAX provides the - ability to set the maximum protection of a region allocated by - mmap(2) and later altered by - mprotect(2). For example, memory allocated originally with - an mmap prot argument of PROT_MAX(PROT_READ | PROT_WRITE) | PROT_READ may be - made writable by a future mprotect(2) call, but may not be - made executable.

-
-
-

-

Relocation Read-Only (RELRO) is a mitigation tool that makes - certain portions of a program's address space that contain ELF metadata - read-only, after relocation processing by rtld(1).

-

When enabled in isolation the RELRO option provides - - support. In this case the Procedure Linkage Table (PLT)-related part of the - Global Offset Table (GOT) (in the section typically named .got.plt) remains - writable.

-

RELRO is enabled by default. The src.conf(5) - build-time option WITHOUT_RELRO may be used to disable - it.

-
-
-

-

The WITH_BIND_NOW - src.conf(5) build-time option causes binaries to be built - with the DF_BIND_NOW flag set. The run-time loader - rtld(1) will then perform all relocation processing when - the process starts, instead of on demand (on the first access to each - symbol).

-

When enabled in combination with - RELRO (which is enabled by default) this provides - . The - entire GOT (.got and .got.plt) are made read-only at program startup, - preventing attacks on the relocation table. Note that this results in a - nonstandard Application Binary Interface (ABI), and it is possible that some - applications may not function correctly.

-
-
-

-

FreeBSD supports stack overflow protection - using the Stack Smashing Protector (SSP) compiler feature. Stack clash - protection is also enabled, if supported by the compiler for the given - architecture. In userland, SSP adds a per-process randomized canary at the - end of every stack frame which is checked for corruption upon return from - the function, and stack probing in PAGE_SIZE chunks. - In the kernel, a single randomized canary is used globally except on - aarch64, which has a PERTHREAD_SSP - config(8) option to enable per-thread randomized canaries. - If stack corruption is detected, then the process aborts to avoid - potentially malicious execution as a result of the corruption. SSP may be - enabled or disabled when building FreeBSD base with - the src.conf(5) SSP knob.

-

When WITH_SSP is enabled, which is the - default, world is built with the - -fstack-protector-strong and - -fstack-clash-protection compiler options. The - kernel is built with the -fstack-protector - option.

-

In addition to SSP, a “FORTIFY_SOURCE” - implementation is supported up to level 2 by defining - _FORTIFY_SOURCE to 1 or - 2 before including any - FreeBSD headers. FreeBSD - world builds can set FORTIFY_SOURCE in the environment - or /etc/src-env.conf to provide a default value for - _FORTIFY_SOURCE. When enabled, - “FORTIFY_SOURCE” enables extra bounds checking in various - functions that accept buffers to be written into. These functions currently - have extra bounds checking support:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
()()()()()
()()()()()
()()()()()
()()()()()
-

“FORTIFY_SOURCE” requires compiler support from - clang(1) or gcc(1), which provide the - __builtin_object_size(3) function that is used to - determine the bounds of an object. This feature works best at optimization - levels -O1 and above, as some object sizes may be - less obvious without some data that the compiler would collect in an - optimization pass.

-

Similar to SSP, violating the bounds of an object will cause the - program to abort in an effort to avoid malicious execution. This effectively - provides finer-grained protection than SSP for some class of function and - system calls, along with some protection for buffers allocated as part of - the program data.

-
-
-

-

Certain processors include features that prevent unintended access - to memory pages accessible to userspace (non-privileged) code, while in a - privileged mode. One feature prevents execution, intended to mitigate - exploitation of kernel vulnerabilities from userland. Another feature - prevents unintended reads from or writes to user space memory from the - kernel. This also provides effective protection against NULL pointer - dereferences from kernel. An additional mechanism, Linear Address Space - Separation (LASS), is available on some amd64 machines. LASS prevents - user-mode applications from accessing kernel-mode memory, and the kernel - from unsanctioned access to userspace memory. Unlike page table-based - permission controls, LASS is based only on address values. As a consequence - of enforcing this separation in hardware, LASS also provides mitigation - against certain speculative-execution side-channel attacks.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
amd64LASSAll
amd64SMAPRead / Write
amd64SMEPExecute
arm64PANRead / Write
arm64PXNExecute
riscvSUMRead / Write
riscv-Execute
-

Most of these features are automatically used by the kernel, with - no user-facing configuration. LASS is controlled by the - hw.lass loader tunable. It is enabled by default, when - available.

-
-
-

-

Capsicum is a lightweight OS capability and sandbox framework. See - capsicum(4) for more information.

-
-
-
-

-
-

-

Recent years have seen an unending stream of new hardware - vulnerabilities, notably CPU ones generally caused by detectable - microarchitectural side-effects of speculative execution which leak private - data from some other thread or process or sometimes even internal CPU state - that is normally inaccessible. Hardware vendors usually address these - vulnerabilities as they are discovered by releasing microcode updates, which - may then be bundled into platform firmware updates (historically called BIOS - updates for PCs) or packages to be updated by the operating system at boot - time.

-

Platform firmware updates, if available from the manufacturer, are - the best defense as they provide coverage during early boot. Install them - with sysutils/flashrom from the - FreeBSD Ports Collection.

-

If platform firmware updates are no longer available, packaged - microcode is available for installation at - sysutils/cpu-microcode and can be loaded at runtime - using loader.conf(5), see the package message for more - details.

-

The best defense overall against hardware vulnerabilities is to - timely apply these updates when available, as early as possible in the boot - process, and to disable the affected hardware's problematic functionalities - when possible (e.g., CPU Simultaneous Multi-Threading). Software mitigations - are only partial substitutes for these, but they can be helpful on - out-of-support hardware or as complements for just-discovered - vulnerabilities not yet addressed by vendors. Some software mitigations - depend on hardware capabilities provided by a microcode update.

-
-
-

-

FreeBSD's usual policy is to apply by - default all OS-level mitigations that do not require recompilation, except - those the particular hardware it is running on is known not to be vulnerable - to (which sometimes requires firmware updates), or those that are extremely - detrimental to performance in proportion to the protection they actually - provide. OS-level mitigations generally can have noticeable performance - impacts on specific workloads. If your threat model allows it, you may want - to try disabling some of them in order to possibly get better performance. - Conversely, minimizing the risks may require you to explicitly enable the - most expensive ones. The description of each vulnerability/mitigation - indicates whether it is enabled or disabled by default and under which - conditions. It also lists the knobs to tweak to force a particular - status.

-
-
-

-

The “Zenbleed” vulnerability exclusively affects AMD - processors based on the Zen2 microarchitecture. In contrast with, e.g., - Meltdown and the different variants of Spectre, which leak data by leaving - microarchitectural traces, Zenbleed is a genuine hardware bug affecting the - CPU's architectural state. With particular sequences of instructions whose - last ones are mispredicted by speculative execution, it is possible to make - appear in an XMM register data previously put in some XMM register by some - preceding or concurrent task executing on the same physical core (disabling - Simultaneous Multi-Threading (SMT) is thus not a sufficient protection).

-

According to the vulnerability's discoverer, all Zen2-based - processors are affected (see - https://lock.cmpxchg8b.com/zenbleed.html). - As of August 2023, AMD has not publicly listed any corresponding errata but - has issued a security bulletin (AMD-SB-7008) entitled “Cross-Process - Information Leak” indicating that platform firmware fixing the - vulnerability will be distributed to manufacturers no sooner than the end of - 2023, except for Rome processors for which it is already available. No - standalone CPU microcodes have been announced so far. The only - readily-applicable fix mentioned by the discoverer is to set a bit of an - undocumented MSR, which reportedly completely stops XMM register leaks.

-

FreeBSD currently sets this bit by default - on all Zen2 processors. In the future, it might set it by default only on - those Zen2 processors whose microcode has not been updated to revisions - fixing the vulnerability, once such microcode updates have been actually - released and community-tested. To this mitigation are associated the - following knobs:

-
-
machdep.mitigations.zenbleed.enable
-
A read-write integer tunable and sysctl indicating whether the mitigation - should be forcibly disabled (0), enabled (1) or if it is left to - FreeBSD to selectively apply it (2). Any other - integer value is silently converted to and treated as value 2. Note that - this setting is silently ignored when running on non-Zen2 processors to - ease applying a common configuration to heterogeneous machines.
-
machdep.mitigations.zenbleed.state
-
A read-only string indicating the current mitigation state. It can be - either “Not applicable”, if the processor is not Zen2-based, - “Mitigation enabled” or “Mitigation disabled”. - This state is automatically updated each time the sysctl - machdep.mitigations.zenbleed.enable is written to. - Note that it can become inaccurate if the chicken bit is set or cleared - directly via cpuctl(4) (which includes the - cpucontrol(8) utility).
-
-

The performance impact and threat models related to these - mitigations should be considered when configuring and deploying them in a - FreeBSD system.

-

Additional mitigation knobs are listed in the - KNOBS AND TWEAKS section of - security(7).

-
-
-
-

-

elfctl(1), proccontrol(1), - rtld(1), mmap(2), - src.conf(5), sysctl.conf(5), - security(7), cpucontrol(8), - sysctl(8)

-
-
- - - - - -
January 29, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/named_attribute.7 3.html b/static/freebsd/man7/named_attribute.7 3.html deleted file mode 100644 index 7b958f9e..00000000 --- a/static/freebsd/man7/named_attribute.7 3.html +++ /dev/null @@ -1,220 +0,0 @@ - - - - - - -
NAMED_ATTRIBUTE(7)Miscellaneous Information ManualNAMED_ATTRIBUTE(7)
-
-
-

-

named_attribute — - Solaris-like extended attribute system interface

-
-
-

-

Description of the system interface for named attributes (the NFS - Version 4 terminology).

-
-

-

This document describes an alternate system interface for extended - attributes as compared to extattr(2). It is based on the - interface provided by Solaris and NFS Version 4.

-

This interface associates a directory, known as a named attribute - directory, to a file system object. This directory is read in the same - manner as a normal directory via the getdents(2) or - getdirentries(2) system calls. The - . and .. entries refer to - the directory itself and to the associated file object, respectively. The - other entries in this directory are the names of the extended attributes for - the associated file object and are referred to as named attributes. These - named attributes are regular files used to store the attribute's value.

-

A named attribute directory does not live in the file system's - name space. It is accessed via an open(2) or - openat(2) system call done on a file to query the named - attributes for the file, with the O_NAMEDATTR flag - specified and a path argument of - .. This file descriptor can be used as the - fd argument for a variety of system calls, such as: - fchdir(2), unlinkat(2) and - renameat(2). renameat(2) is only - permitted to rename a named attribute within the same named attribute - directory.

-

When a file descriptor for a file object in the file system's - namespace is used as the fd argument of an - openat(2) along with the flag - O_NAMEDATTR and a path - argument that is the name of a named attribute (not - . or .. ), a file descriptor - for the named attribute is returned. If the flag - O_CREAT is specified, the named attribute will be - created if it does not exist. The path argument must - be a single component name, with no embedded “/” in it. I/O on - these named attribute file descriptors may be performed by standard I/O - system calls such as: read(2), write(2), - lseek(2) and ftruncate(2).

-

The _PC_NAMEDATTR_ENABLED - name argument to pathconf(2) will - return 1 if the file system supports named attributes. The - _PC_HAS_NAMEDATTR name - argument to pathconf(2) will return 1 if there are one or - more named attributes for the file. If an application does a - openat(2) of “.” to open a named attribute - directory when no named attribute directory exists, an empty named attribute - directory will be created. Testing _PC_HAS_NAMEDATTR - can be done to avoid creating these named attribute directories - unnecessarily.

-

The named attribute interface is a different mechanism/system call - interface for manipulating extended attributes compared with - extattr(2). Although the named attribute machanism might - require different internal implementation of extended attributes within a - file system, both ZFS and NFSv4 provide both mechanisms, which can be used - interchangeably to manipulate extended attributes, but with a few - limitations.

-
    -
  • The extattr(2) interface requires that an extended - attribute's value be set or acquired via a single system call using a - single buffer. This limits the size of the attribute's value.
    • -
  • The named attribute interface does not support system namespace extended - attributes and, as such, system namespace extended attributes must be - manipulated via extattr(2).
    • -
  • For ZFS, if an extended attribute with a value that is a small length in - bytes is created when the ZFS xattr property is - set to “sa”, that extended attribute is only visible via - extattr(2) and not as a named attribute. - Archiving/de-archiving the file via tar(1) after setting - the xattr property to “dir” will - make the attribute(s) visible as both named attributes and via - extattr(2).
    • -
  • For ZFS, it is also possible to create two attributes with the same name - by creating one when the ZFS xattr property is set - to “sa” and then creating another one with the same name - after the ZFS property xattr has been changed to - “dir”. The one created when the ZFS - xattr property is set to “sa” may be - removed via rmextattr(8).
    • -
  • To avoid these issues for ZFS, it is strongly recommended that the ZFS - property xattr be set to “dir” as - soon as the file system is created, if named attributes are to be used on - the file system.
    • -
-

The named attribute mechanism/system call interface provides - certain advantages over extattr(2). Since the attribute's - value is updated via read(2) and - write(2) system calls, the attribute's data may be as - large as any regular file and may be partially updated. (Note that this - interface does not provide the atomicity guarantee that - extattr(2) does.) The permission to access a named - attribute directory is determined from the access control information for - the associated file object. However, access control information can be set - on each individual attribute in a manner similar to a regular file. This - provides “per attribute” granular control over attribute - permissions via fchown(2).

-

At this time, the only local file system which supports this - interface is ZFS and only if the xattr property is - set to “dir”. (Note that, even when “zfs get xattr - <file-system>” shows “on” the command “zfs - set xattr=dir <file-system>” must be done, followed by a - remount to make the setting take effect.) A NFSv4 mount will also support - this interface, but only if the NFSv4 server file system supports named - attributes (the openattr operation). The FreeBSD - NFSv4 server supports named attributes only for ZFS exported file systems - where the “xattr” property is set to “dir” for - the file system.

-
-
-
-

-
-
#include <stdio.h>
-#include <dirent.h>
-#include <fcntl.h>
-#include <unistd.h>
-
-...
-
-/* For a file called "myfile". Failure checks removed for brevity. */
-int file_fd, nameddir_fd, namedattr_fd;
-ssize_t siz;
-char buf[DIRBLKSIZ], *cp;
-struct dirent *dp;
-long named_enabled, has_named_attrs;
-
-...
-/* Check to see if named attributes are supported. */
-named_enabled = pathconf("myfile", _PC_NAMEDATTR_ENABLED);
-if (named_enabled <= 0)
-	err(1, "Named attributes not enabled");
-/* Test to see if named attribute(s) exist for the file. */
-has_named_attrs = pathconf("myfile", _PC_HAS_NAMEDATTR);
-if (has_named_attrs == 1)
-	printf("myfile has named attribute(s)\n");
-else
-	printf("myfile does not have any named attributes\n");
-/* Open a named attribute directory. */
-file_fd = open("myfile", O_RDONLY, 0);
-nameddir_fd = openat(file_fd, ".", O_NAMEDATTR, 0);
-...
-/* and read it, assuming it all fits in DIRBLKSIZ for simplicity. */
-siz = getdents(fd, buf, sizeof(buf));
-cp = buf;
-while (cp < &buf[siz]) {
-	dp = (struct dirent *)cp;
-	printf("name=%s\n", dp->d_name);
-	cp += dp->d_reclen;
-}
-...
-/* Open/create a named attribute called "foo". */
-namedattr_fd = openat(file_fd, "foo", O_CREAT | O_RDWR |
-    O_TRUNC | O_NAMEDATTR, 0600);
-...
-/* Write foo's attribute value. */
-write(namedattr_fd, "xxxyyy", 6);
-...
-/* Read foo's attribute value. */
-lseek(namedattr_fd, 0, SEEK_SET);
-siz = read(namedattr_fd, buf, sizeof(buf));
-...
-/* And close "foo". */
-close(namedattr_fd);
-...
-/* Rename "foo" to "oldfoo". */
-renameat(nameddir_fd, "foo", nameddir_fd, "oldfoo");
-/* and delete "oldfoo". */
-unlinkat(nameddir_fd, "oldfoo", AT_RESOLVE_BENEATH);
-
-

The runat(1) command may be used to perform - shell commands on named attributes. For example:

-
-
$ runat myfile cp /etc/hosts attrhosts	# creates attrhosts
-$ runat myfile cat attrhosts		# displays contents of attrhosts
-$ runat myfile ls -l			# lists the attributes for myfile
-
-

If using the bash(1) shell, the command - “cd -@ foo” enters the named attribute directory for the file - object “foo”.

-
-
-

-

bash(1), runat(1), - tar(1), chdir(2), - extattr(2), lseek(2), - open(2), pathconf(2), - read(2), rename(2), - truncate(2), unlinkat(2), - write(2), zfsprops(7), - rmextattr(8)

-
-
-

-

This interface first appeared in FreeBSD - 15.0.

-
-
- - - - - -
August 5, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/networking.7 4.html b/static/freebsd/man7/networking.7 4.html deleted file mode 100644 index 7b0b4464..00000000 --- a/static/freebsd/man7/networking.7 4.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - -
NETWORKING(7)Miscellaneous Information ManualNETWORKING(7)
-
-
-

-

networking, wifi - — quickstart guide to connecting to a - network

-
-
-

-

In the following examples, it is assumed that we are connecting to - Ethernet with the first interface found by the ix(4) - driver, and Wi-Fi with the first interface found by the - iwlwifi(4) driver, though your hardware will vary.

-
-
-

-
-
-
-

Ask for a DHCP lease on the first Intel 10Gb Ethernet - interface:

-
- 
# dhclient ix0
-
-
-
-
-

Ask for a DHCP lease on the first USB tethering interface:

-
- 
# dhclient ue0
-
-
-
-
-

Identify your Wi-Fi hardware:

-
- 
% sysctl net.wlan.devices
-
-

Create the - interface - with the first Intel Wi-Fi adapter:

-
- 
# sysrc wlans_iwlwifi0="wlan0"
-
-

Set that interface to ask for a DHCP lease with - wpa_supplicant(8):

-
- 
# sysrc ifconfig_wlan0="WPA SYNCDHCP"
-
-

Enter the details of the Wi-Fi network:

-
- 
# cd /etc/
-# wpa_passphrase "myssid" "mypassphrase" >> wpa_supplicant.conf
-
-

Restart the network interface daemon:

-
- 
# service netif restart
-
-
-
-
-
- 
% ifconfig wlan0 scan
-
-
-
-
-
- 
# service netif stop
-
-
-
-
-
-

-

bsdconfig(8), dhclient(8), - ifconfig(8), wpa_passphrase(8)

-

The Advanced Networking chapter of the - FreeBSD Handbook.

-
-
-

-

Shell Special Characters in the SSID or - passphrase will need to be escaped for - wpa_passphrase(8), commonly using - ‘\’, see the manual page for your - shell for more details.

-

Stopping the network interface service also stops internal - networking.

-
-
- - - - - -
March 21, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/operator.7 4.html b/static/freebsd/man7/operator.7 4.html deleted file mode 100644 index 8472e641..00000000 --- a/static/freebsd/man7/operator.7 4.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - -
OPERATOR(7)Miscellaneous Information ManualOPERATOR(7)
-
-
-

-

operator — C and - C++ operator precedence and order of evaluation

-
-
-

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Associativity
---------------------
() [] -> .left to right
! ~ ++ -- - (type) * & sizeof new deleteright to left
->* .*left to right
* / %left to right
+ -left to right
<< >>left to right
< <= > >=left to right
== !=left to right
&left to right
^left to right
|left to right
&&left to right
||left to right
?:right to left
= += -= *= /= %= <<= >>= &= ^= |= throwright to left
?: (C++, third operand)right to left
,left to right
-
-
-
-

-
-
/usr/share/misc/operator
-
 
-
-
-
- - - - - -
April 8, 2009FreeBSD 15.0
diff --git a/static/freebsd/man7/orders.7 3.html b/static/freebsd/man7/orders.7 3.html deleted file mode 100644 index 2a4405ea..00000000 --- a/static/freebsd/man7/orders.7 3.html +++ /dev/null @@ -1,370 +0,0 @@ - - - - - - -
ORDERS(7)Miscellaneous Information ManualORDERS(7)
-
-
-

-

orders — orders of - magnitude

-
-
-

-

The following table lists common multiples of bytes.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
KilobytekB2^1010^3
MegabyteMB2^2010^6
GigabyteGB2^3010^9
TerabyteTB2^4010^12
PetabytePB2^5010^15
ExabyteEB2^6010^18
ZettabyteZB2^7010^21
YottabyteYB2^8010^24
RonnabyteRB2^9010^27
QuettabyteQB2^10010^30
-

The following table lists common bit rates as a power of ten.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bit per secondbit/s10.125
Byte per secondB/s81
Kilobit per secondkbit/s10^3125
Kilobyte per secondkB/s8 * 10^31000
Megabit per secondMbit/s10^6125000
Megabyte per secondMB/s8 * 10^61000000
Gigabit per secondGbit/s10^9125000000
Gigabyte per secondGB/s8 * 10^91000000000
Terabit per secondTbit/s10^12125000000000
Terabyte per secondTB/s8 * 10^121000000000000
-

The following table lists common orders of magnitude as a power of - ten.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nonillionth10^-30quectoq0.000000000000000000000000000001
Octillionth10^-27rontor0.000000000000000000000000001
Septillionth10^-24yoctoy0.000000000000000000000001
Sextillionth10^-21zeptoz0.000000000000000000001
Quintillionth10^-18attoa0.000000000000000001
Quadrillionth10^-15femtof0.000000000000001
Trillionth10^-12picop0.000000000001
Billionth10^-9nanon0.000000001
Millionth10^-6micromu0.000001
Thousandth10^-3millim0.001
Hundredth10^-2centic0.01
Tenth10^-1decid0.1
One10^0--1
Ten10^1decada10
Hundred10^2hectoh100
Thousand10^3kilok1000
Million10^6megaM1000000
Billion10^9gigaG1000000000
Trillion10^12teraT1000000000000
Quadrillion10^15petaP1000000000000000
Quintillion10^18exaE1000000000000000000
Sextillion10^21zettaZ1000000000000000000000
Septillion10^24yottaY1000000000000000000000000
Octillion10^27ronnaR1000000000000000000000000000
Nonillion10^30quettaQ1000000000000000000000000000000
-
-
-

-

units(1), number(6)

-
-
-

-

There have been various attempts to standardize the set of binary - prefixes. Organizations such as International Electrotechnical Commission - (IEC) have proposed new prefixes such as “kibi”, - “mebi”, “gibi”, and “yobi”, but - the adoption has been slow at best.

-
-
-

-

This manual page was written by Jukka - Ruohonen - <jruoho@netbsd.org>.

-
-
- - - - - -
November 20, 2022FreeBSD 15.0
diff --git a/static/freebsd/man7/ports.7 3.html b/static/freebsd/man7/ports.7 3.html deleted file mode 100644 index f7e168f4..00000000 --- a/static/freebsd/man7/ports.7 3.html +++ /dev/null @@ -1,585 +0,0 @@ - - - - - - -
PORTS(7)Miscellaneous Information ManualPORTS(7)
-
-
-

-

ports — - contributed applications

-
-
-

-

The FreeBSD Ports Collection offers a - simple way to compile and install third party applications. It is also used - to build packages, to be installed using pkg(8).

-

The ports tree, typically located at - /usr/ports, consists of subdirectories, one for each - category; those in turn contain individual ports. Each port is a directory - with metadata and patches necessary to make the original application source - code compile and run on FreeBSD. Compiling an - application is as simple as typing “make - build” in the port directory. The - Makefile automatically fetches the application - source code, either from a local disk or the network, unpacks it, applies - the patches, and compiles it. It also recursively handles dependencies - — other pieces of software the port depends on in order to build and - work. Afterwards, “make install” - installs the application.

-

The FreeBSD Ports Collection - is maintained in several branches, which differ mostly by versions of - software provided: the main branch contains all the latest - changes and corresponds to the - package - set, while the quarterly branches only provide critical - fixes. The main branch can be cloned and updated from the - Git repository located at:

-

https://git.FreeBSD.org/ports.git

-

so eg:

-

git clone - https://git.FreeBSD.org/ports.git

-

The quarterly branches can be found in - Git as branches like yyyyQn , where - indicates the - year and - indicates the quarter (1 to 4), eg:

-

git clone -b 2021Q2 - https://git.FreeBSD.org/ports.git

-

It is generally a good idea to use the - ports branch that matches the - pkg(8) repository being used. By default, for - FreeBSD CURRENT the pkg(8) is - configured to install packages built from the main branch, - while for FreeBSD STABLE or RELEASE versions it is - configured to install packages built from the latest - quarterly branch. Currently configured - pkg(8) repository can be verified by looking at the - field in - pkg -vv output.

-

For more information about using ports, see the “Packages - and Ports section” in The FreeBSD - Handbook:

-

https://docs.FreeBSD.org/en/books/handbook/ports/

-

For information about creating new ports, see The - Porter's Handbook:

-

https://docs.FreeBSD.org/en/books/porters-handbook/

-
-
-

-

Some of the make(1) targets work recursively - through subdirectories. This lets you, for example, install all of the - “biology” ports with one command. The - targets that do this are build, - checksum, clean, - configure, depends, - extract, fetch, - install, and package.

-

The following targets will be run automatically by each proceeding - target in order. That is, build will be run (if - necessary) by install, and so on all the way to - fetch. Usually, you will only use the - install target.

-
-
-
Configure OPTIONS for this port using - portconfig(1) - (ports/ports-mgmt/portconfig).
-
-
Fetch all of the files needed to build this port from the sites listed in - MASTER_SITES and PATCH_SITES. - See FETCH_CMD, - MASTER_SITE_OVERRIDE and - MASTER_SITE_BACKUP.
-
-
Verify that the fetched distfile's checksum matches the one the port was - tested against. If the distfile's checksum does not match, it also fetches - the distfiles which are missing or failed the checksum calculation. - Defining NO_CHECKSUM will skip this step.
-
-
Install (or compile if only compilation is necessary) any dependencies of - the current port. When called by the extract or - fetch targets, this is run in piecemeal as - fetch-depends, - build-depends, etc. Defining - NO_DEPENDS will skip this step.
-
-
Expand the distfile into a work directory.
-
-
Apply any patches that are necessary for the port.
-
-
Configure the port. Some ports will ask you questions during this stage. - See INTERACTIVE and - BATCH.
-
-
Build the port. This is the same as calling the - all target.
-
-
Install the port and register it with the package system. This is all you - really need to do.
-
-
Install missing dependencies from packages instead of building them.
-
-

The following targets are not run during the normal install - process.

-
-
-
Display OPTIONS config for this port.
-
-
Display OPTIONS config for this port and all its - dependencies.
-
-
Remove OPTIONS config for this port.
-
-
Remove OPTIONS config for this port and all its - dependencies.
-
-
Skip the ports which have already had their OPTIONS - configured.
-
-
Configure OPTIONS for this port and all its - dependencies using portconfig(1) - (ports/ports-mgmt/portconfig).
-
-
Show the list of files to fetch in order to build the port (but not its - dependencies).
-
-
Fetch the distfiles of the port and all its dependencies.
-
-
Show list of files that would be retrieved by - fetch-recursive.
-
, - run-depends-list
-
Print a list of all the direct compile or run dependencies for this - port.
-
-
Print a list of all recursive dependencies for this port.
-
, - pretty-print-run-depends-list
-
Print a list of all the recursive compile or run dependencies for this - port by port name and version.
-
-
Print a list of missing dependencies to be installed for the port.
-
-
Remove the expanded source code. This recurses to dependencies unless - NOCLEANDEPENDS is defined.
-
-
Remove the port's distfiles and perform the clean - target. The clean portion recurses to dependencies - unless NOCLEANDEPENDS is defined, but the - distclean portion never recurses (this is perhaps - a bug).
-
-
Use this to restore a port after using pkg-delete(8) - when you should have used deinstall.
-
-
Remove an installed port from the system, similar to - pkg-delete(8).
-
-
Remove all installed ports with the same PKGORIGIN - from the system.
-
-
Make a binary package for the port. The port will be installed if it has - not already been. The package is a .pkg file that - you can use to install the port on other machines with - pkg-add(8). If the directory specified by - PACKAGES does not exist, the package will be put in - /usr/ports/category/port/work/pkg. See - PKGREPOSITORY and PKGFILE for - more information.
-
-
Like package, but makes a package for each - depending port as well.
-
-
Prints the name with version of the port.
-
-
Create a port's README.html. This can be used from - /usr/ports to create a browsable web of all ports - on your system!
- -
Search the INDEX file for the pattern specified by - the key (searches the port name, comment, and - dependencies), name (searches the port name only), - path (searches the port path), - info (searches the port info), - maint (searches the port maintainer), - cat (searches the port category), - bdeps (searches the port build-time dependency), - rdeps (searches the port run-time dependency), - www (searches the port web site) - make(1) variables, and their exclusion counterparts: - xname, xkey etc. For example, - one would type: -

-
cd /usr/ports && make - search name=query
-

to find all ports whose name matches - “query”. Results include the - matching ports' path, comment, maintainer, build dependencies, and run - dependencies.

-
- 
cd /usr/ports && make search name=pear- \
-    xbdeps=apache
-
-

To find all ports whose names contain - “pear-” and which do not have - apache listed in build-time dependencies.

-
- 
cd /usr/ports && make search name=pear- \
-    xname='ht(tp|ml)'
-
-

To find all ports whose names contain - “pear-”, but not - “html” or - “http”.

-
- 
make search key=apache display=name,path,info keylim=1
-
-

To find ports that contain - “apache” in either of the name, - path, info fields, ignore the rest of the record.

-

By default the search is not case-sensitive. In order to make - it case-sensitive you can use the icase - variable:

-
- 
make search name=p5-R icase=0
-
-
-
-
Reduced search output. Only display name, path and - info.
-
-
Generate a one-line description of each port for use in the - INDEX file.
-
-
Display the port maintainer's email address.
-
-
Create /usr/ports/INDEX, which is used by the - pretty-print-* and search - targets. Running the index target will ensure your - INDEX file is up to date with your ports - tree.
-
-
Fetch the INDEX file from the - FreeBSD cluster.
-
-
-
-

-

You can change all of these.

-
-
PORTSDIR
-
Location of the ports tree. This is /usr/ports by - default.
-
WRKDIRPREFIX
-
Where to create any temporary files. Useful if - PORTSDIR is read-only (perhaps mounted from a - CD-ROM).
-
DISTDIR
-
Where to find/put distfiles, normally distfiles/ - in PORTSDIR.
-
SU_CMD
-
Command used to elevate privilege to configure and install a port. The - unprivileged user must have write access to - WRKDIRPREFIX and DISTDIR. The - default is ‘/usr/bin/su root -c’. - Many users set it to ‘/usr/local/bin/sudo -E sh - -c’ for convenience.
-
PACKAGES
-
Used only for the package target; the base - directory for the packages tree, normally - packages/ in PORTSDIR. If - this directory exists, the package tree will be (partially) constructed. - This directory does not have to exist; if it does not, packages will be - placed into the current directory, or you can define one of -
-
PKGREPOSITORY
-
Directory to put the package in.
-
PKGFILE
-
The full path to the package.
-
-
-
LOCALBASE
-
Where existing things are installed and where to search for files when - resolving dependencies (usually /usr/local).
-
PREFIX
-
Where to install this port (usually set to the same as - LOCALBASE).
-
MASTER_SITES
-
Primary sites for distribution files if not found locally.
-
PATCH_SITES
-
Primary locations for distribution patch files if not found locally.
-
MASTER_SITE_FREEBSD
-
If set, go to the master FreeBSD site for all - files.
-
MASTER_SITE_OVERRIDE
-
Try going to these sites for all files and patches, first.
-
MASTER_SITE_BACKUP
-
Try going to these sites for all files and patches, last.
-
RANDOMIZE_MASTER_SITES
-
Try the download locations in a random order.
-
MASTER_SORT
-
Sort the download locations according to user supplied pattern. Example: -
.dk .sunet.se .se dk.php.net .no - .de heanet.dl.sourceforge.net
-
-
MASTER_SITE_INDEX
-
Where to get INDEX source built on - FreeBSD cluster (for - fetchindex target). Defaults to - https://download.FreeBSD.org/ports/index/.
-
FETCHINDEX
-
Command to get INDEX (for - fetchindex target). Defaults to - “fetch -am”.
-
NOCLEANDEPENDS
-
If defined, do not let clean recurse to - dependencies.
-
FETCH_CMD
-
Command to use to fetch files. Normally fetch(1).
-
FORCE_PKG_REGISTER
-
If set, overwrite any existing package registration on the system.
-
INTERACTIVE
-
If defined, only operate on a port if it requires interaction.
-
BATCH
-
If defined, only operate on a port if it can be installed 100% - automatically.
-
DISABLE_VULNERABILITIES
-
If defined, disable check for security vulnerabilities using - pkg-audit(8) when installing new ports.
-
NO_IGNORE
-
If defined, allow installation of ports marked as - ⟨FORBIDDEN⟩. The default behavior of - the Ports framework is to abort when the installation of a forbidden port - is attempted. Of course, these ports may not work as expected, but if you - really know what you are doing and are sure about installing a forbidden - port, then NO_IGNORE lets you do it.
-
NO_CHECKSUM
-
If defined, skip verifying the port's checksum.
-
TRYBROKEN
-
If defined, attempt to build a port even if it is marked as - ⟨BROKEN⟩.
-
PORT_DBDIR
-
Directory where the results of configuring OPTIONS - are stored. Defaults to /var/db/ports. Each port - where OPTIONS have been configured will have a - uniquely named sub-directory, containing a single file - options.
-
-
-
-

-

The following list provides a name and short description for many - of the variables that are used when building ports. More information on - these and other related variables may be found in - ${PORTSDIR}/Mk/* and the - FreeBSD Porter's Handbook.

-
-
WITH_DEBUG
-
(bool) If set, debugging symbols are installed for - ports binaries.
-
WITH_DEBUG_PORTS
-
A list of origins for which to set WITH_DEBUG.
-
DEBUG_FLAGS
-
(Default: ‘-g’) Additional - CFLAGS to set when WITH_DEBUG - is set.
-
DEFAULT_VERSIONS
-
Override the default variant used for ports with multiple concurrent - versions in the tree, such as database or compiler versions.
-
WITH_CCACHE_BUILD
-
(bool) If set, enables the use of - ccache(1) for building ports.
-
CCACHE_DIR
-
Which directory to use for the ccache(1) data.
-
-
-
-

-
-
/usr/ports/
-
The default ports directory.
-
/usr/ports/Mk/bsd.port.mk
-
The big Kahuna.
-
/var/db/ports/
-
The directory where the results of configuring - OPTIONS are stored.
-
${PORT}/Makefile
-
The specification for building the port.
-
${PORT}/distfiles
-
The directory where fetched files are stored.
-
${PORT}/distinfo
-
The checksums generated with ‘make - makesum’.
-
${PORT}/files/
-
The directory for any patches.
-
${PORT}/pkg-descr
-
The long description of the port.
-
${PORT}/pkg-plist
-
The list of all files installed by the port.
-
${PORT}/work
-
The port's building and staging directory.
-
-
-
-

-
-
Building and Installing a Port
-
-

The following command builds and installs Emacs.

-
- 
# cd /usr/ports/editors/emacs
-# make install
-
-
-
Installing Dependencies with - pkg(8)
-
-

The following example shows how to build and install a port - without having to build its dependencies. Instead, the dependencies are - downloaded via pkg(8).

-
- 
# make install-missing-packages
-# make install
-
-

It is especially useful, when the dependencies are costly in - time and resources to build (like lang/rust). - The drawback is that pkg(8) offers only packages built - with the default set of OPTIONS.

-
-
Building a Non-Default Flavor of a - Port
-
-

The following command builds a non-default flavor of a port. - (In this case devel/py-pip is going to be built - with Python 3.7 support.)

-
- 
# cd /usr/ports/devel/py-pip
-# env FLAVOR=py37 make build
-
-
-
Setting Ports Options via - make.conf(5)
-
-

The following lines present various ways of configuring ports - options via make.conf(5) (as an alternative to, e.g., - running “make config”):

-
- 
# Enable NLS for all ports unless configured otherwise
-# using the options dialog.
-OPTIONS_SET=		NLS
-# Disable DOCS for all ports overriding the options set
-# via the options dialog.
-OPTIONS_UNSET_FORCE=	DOCS
-# Disable DOCS and EXAMPLES for the shells/zsh port.
-shells_zsh_UNSET=	DOCS EXAMPLES
-
-

These and other options-related variables are documented in - /usr/ports/Mk/bsd.options.mk.

-
-
Setting make(1) - Variables for Specific Ports via make.conf(5)
-
-

The following example shows how to set arbitrary - make(1) variables only specific ports:

-
- 
# Set DISABLE_MAKE_JOBS for the lang/rust port:
-.if ${.CURDIR:M*/lang/rust}
-DISABLE_MAKE_JOBS=	yes
-TRYBROKEN=		yes
-.endif
-
-
-
Debugging Ports
-
By default ports are built and packaged without debugging support (e.g., - debugging symbols are stripped from binaries, optimization flags are used - for compiling, verbose logging is disabled). Whether ports are built with - debugging symbols can be controlled by the settings in - make.conf(5), e.g., -
- 
# Enable debugging for all ports.
-WITH_DEBUG=		yes
-# Enable debugging for selected ports.
-WITH_DEBUG_PORTS=	mail/dovecot security/krb5
-
-

It is also possible to use the debug variables on the command - line:

-
- 
# make WITH_DEBUG DEBUG_FLAGS="-g -O0" build
-
-

See the MAKE - VARIABLES section to learn more about the debug variables.

-

To understand the details of what happens when the debug - variables are set it is best to consult the files located at - ${PORTSDIR}/Mk/* - (bsd.port.mk in particular).

-

If debugging is enabled for a specific port, the ports - framework will:

-
    -
  • Add DEBUG_FLAGS (defaults to - ‘-g’) to - CFLAGS.
    • -
  • Try to prevent the binaries from being stripped (including checking - the install target to replace - ‘install-strip’ with - ‘install’). Whether a binary has - been stripped can be checked with file(1).
    • -
  • Try to enable other debugging features like debug build type or - verbose logging. However, this is port-specific and the ports - framework might not be aware of each supported debugging feature a - given piece of software has to offer).
    • -
-
-
-
-
-

-

make(1), make.conf(5), - development(7), pkg(7)

-

Additional developer documentation:

- -

Additional user documentation:

- -
-
-

-

The Ports Collection appeared in FreeBSD - 1.0. It has since spread to NetBSD, - OpenBSD, and macOS.

-
-
-

-

This manual page was originated by David - O'Brien.

-
-
-

-

Ports documentation is split over four places — - /usr/ports/Mk/bsd.port.mk, The - Porter's Handbook, the “Packages and Ports” chapter of - The FreeBSD Handbook, and this manual page.

-
-
- - - - - -
February 21, 2026FreeBSD 15.0
diff --git a/static/freebsd/man7/release.7 3.html b/static/freebsd/man7/release.7 3.html deleted file mode 100644 index ce187867..00000000 --- a/static/freebsd/man7/release.7 3.html +++ /dev/null @@ -1,562 +0,0 @@ - - - - - - -
RELEASE(7)Miscellaneous Information ManualRELEASE(7)
-
-
-

-

release — release - building infrastructure

-
-
-

-

FreeBSD provides a complete build - environment suitable for users to make full releases of the - FreeBSD operating system. All of the tools necessary - to build a release are available from the FreeBSD - source code repository in src/release. A complete - release can be built with only a single command, including the creation of - ISO images suitable for burning to CD-ROM, memory stick images, and a - network install directory. This command is aptly named - “make release”.

-

For some users, it may be desirable to provide an absolutely clean - build environment, with no local modifications to the source tree or to - make.conf(5), and with clean checkouts of specific - versions of the doc, src, and ports trees. For this purpose, a script - (src/release/release.sh) is provided to automate - these checkouts and then execute “make - release” in a clean chroot(8).

-

Before attempting to build a release, the user is expected to be - familiar with the contents of build(7), and should have - experience upgrading systems from source.

-

The release build process requires that - /usr/obj be populated with the output of - “make buildworld” and - “make buildkernel”. This is necessary - to provide the object files for the release or, when using - release.sh, so that the object files for a complete - system can be installed into a clean chroot(8) - environment.

-

If the target release build is for a different architecture or - machine type, the TARGET and - TARGET_ARCH variables must be used. See the supported - release.conf variables for more information.

-

The release procedure on some architectures may also require that - the md(4) (memory disk) device driver be present in the - kernel (either by being compiled in or available as a module).

-

This document does not cover source code management, quality - assurance, or other aspects of the release engineering process.

-
-
-

-

Official releases of FreeBSD are produced - in a clean environment to ensure consistency between the versions of the - src, ports, and doc trees and to avoid contamination from the host system - (such as local patches, changes to make.conf(5), etc.). - This is accomplished using the wrapper script - src/release/release.sh.

-

release.sh [-c - release.conf]

-

release.sh checks out the - src/, ports/, and - doc/ trees to CHROOTDIR, then - calls “make buildworld” and - “make installworld” to generate a - chroot(8) environment. Next, “make - release” is run within the chroot(8) - environment and places the result in - $CHROOTDIR/R.

-

The optional release.conf configuration file - supports the following variables:

-
-
CHROOTDIR
-
The directory within which the release will be built. Defaults to - /scratch.
-
CHROOT_MAKEENV
-
Additional make(1) arguments to pass through, which - directly affect the tuning of the build chroot.
-
NOGIT
-
Do not explicitly require the git(1) port to be - installed.
-
GITROOT
-
The git(1) host used to check out the various trees. - Defaults to https://git.FreeBSD.org.
-
SRCBRANCH
-
The src/ branch to use. Defaults to - -b main.
-
PORTBRANCH
-
The ports/ branch to use. Defaults to - head/@rHEAD.
-
TARGET
-
The target machine type for cross-building a release.
-
TARGET_ARCH
-
The target machine architecture for cross-building a release. -

For the supported list of TARGET and - TARGET_ARCH combinations, consult the output of - “make targets” as documented in - build(7).

-
-
KERNEL
-
The target kernel configuration to use. Defaults to - GENERIC. Multiple KERNEL - entries may be specified.
-
MAKE_CONF
-
The make.conf(5) to use for the release build. Defaults - to /dev/null to prevent polluting the release with - local system changes.
-
SRC_CONF
-
The src.conf(5) to use for the release build. Defaults - to /dev/null to prevent polluting the release with - local system changes.
-
MAKE_FLAGS
-
Additional flags to pass to make(1).
-
WORLD_FLAGS
-
Additional flags to pass to make(1) during the - “buildworld” phase. Defaults to setting the number of - make(1) jobs (-j) to the number of - CPUs available on a SMP-capable system.
-
KERNEL_FLAGS
-
Additional flags to pass to make(1) during the - “buildkernel” phase. Defaults to setting the number of - make(1) jobs (-j) to half the - number of CPUs available on a SMP-capable system.
-
NOPORTS
-
Set to a non-empty value to skip the ports/ tree - checkout. When set, NOPORTS will prevent the - ports.txz distribution package from being - created.
-
WITH_DVD
-
Set to a non-empty value to include the dvdrom - target.
-
WITH_COMPRESSED_IMAGES
-
Set to a non-empty value to compress the release images with - xz(1). The original (uncompressed) images are not - removed.
-
XZ_THREADS - (int)
-
Set to the number of threads xz(1) should use when - compressing images. By default, XZ_THREADS is set to - 0, which uses all available cores on the - system.
-
VCSCMD
-
The command run to obtain the source trees. Defaults to - "git clone - -q".
-
CHROOTBUILD_SKIP
-
If defined, the buildworld, - installworld, and - distribution stages of the - chroot(8) build environment setup are skipped. This is - intended solely for cases where the chroot(8) userland - are provided by alternate means.
-
SRC_UPDATE_SKIP
-
Set to a non-empty value to prevent checkout or update of - /usr/src within the chroot(8). - This is intended for use only when /usr/src is - expected to exist by alternative means.
-
PORTS_UPDATE_SKIP
-
Set to a non-empty value to prevent checkout or update of - /usr/ports within the chroot(8). - This is intended for use only when /usr/ports is - expected to exist by alternative means.
-
NOPKGBASE
-
Include legacy tarball distribution sets for use on the install media, - instead of base system packages.
-
PKG_CMD
-
A path to the pkg(8) executable to use when installing - packages in release images as a non-root user.
-
PKG_REPOS_DIR
-
An optional path to a directory containing pkg(8) - repository configuration files. These configuration files will be used - when installing packages in release images as a non-root user.
-
PKG_REPO_NAME
-
The name of the repository configuration to use when installing packages - in release images as a non-root user.
-
-
-
-

-

The following release.conf variables are - relevant only to release builds for embedded systems:

-
-
EMBEDDEDBUILD
-
Set to a non-null value to enable functionality for embedded device - release builds. -

When set, WITH_DVD is unset. - Additionally, EMBEDDED_TARGET and - EMBEDDED_TARGET_ARCH must also be defined. When - the build environment is created, release.sh runs - a separate build script located in an architecture-specific directory in - src/release/${EMBEDDED_TARGET}/.

-
-
EMBEDDEDPORTS
-
Set to the list of any ports that are required for the target device in - the format of category/port.
-
EMBEDDED_TARGET
-
When set, its value is passed to make(1) to set the - TARGET (value of uname - -m) to cross build the target userland.
-
EMBEDDED_TARGET_ARCH
-
When set, its value is passed to make(1) to set the - TARGET_ARCH (value of uname - -p) to cross build the target userland.
-
-
-
-

-

The following release.conf variables are - relevant only to virtual machine disk image builds:

-
-
WITH_VMIMAGES
-
Set to a non-null value to build virtual machine disk images as part of - the release build. WITH_VMIMAGES may also be - specified as an environment variable passed to - make(1).
-
WITH_COMPRESSED_VMIMAGES
-
Set to a non-null value to compress the virtual machine disk images with - xz(1) as part of the install - make(1) target. Note that compressing virtual machine - disk images may take a very long time on some systems.
-
VMBASE
-
Set to change the name of the resulting virtual machine disk image file. - The default value is vm.
-
VMSIZE
-
Set to change the size of the virtual machine disk capacity. The default - value is 20g. See makefs(8) for - valid values. -

Virtual machine disk images are, by default, created as sparse - images. When WITH_COMPRESSED_VMIMAGES is used, the - resulting files compressed with xz(1) compress to - roughly the same size, regardless of the specified disk image size.

-
-
VMFS
-
(Deprecated.) Set to specify which of the filesystem(s) listed in - VMFSLIST is linked to the historical - non-filesystem-labelled file name. Valid values are - ufs and zfs. The default value - is ufs.
-
VMFSLIST
-
Set to specify the list of file system types to build images for. Valid - values are one or both of ufs and - zfs. The default value is ufs - zfs.
-
VMFORMATS
-
Set to the target virtual disk image format(s) to create. By default, the - vhdf, vmdk, - qcow2, and raw formats are - created. See mkimg(1) for valid format values.
-
-

For a list of supported VMFORMATS values - (including cloud hosting provider formats) along with a brief description, - run:

-
-
cd /usr/src
-make -C release list-vmtargets
-
-
-
-

-

The FreeBSD release build tools support - building virtual machine images for various cloud hosting providers, each - with their own specific configuration to include support for each hosting - provider by default.

-

The following make(1) environment variables are - supported:

-
-
CLOUDWARE
-
Set to a list of one or more cloud hosting providers, enclosed in quotes. - Requires WITH_CLOUDWARE to also be set.
-
WITH_CLOUDWARE
-
Set to a non-empty value to enable building virtual machine images for - various cloud hosting providers. Requires CLOUDWARE - to also be set.
-
-

Additionally, the CLOUDWARE and - WITH_CLOUDWARE variables can be added to - release.conf, and used in conjunction with - release.sh.

-

For a list of supported CLOUDWARE values, - run:

-
-
cd /usr/src
-make -C release list-cloudware
-
-
-
-

-

The FreeBSD release build tools have - experimental support for building Open Container Initiative (OCI) format - container base images. This is enabled using a - release.conf variable:

-
-
WITH_OCIIMAGES
-
Set to a non-null value to build OCI base images.
-
-
-
-

-

The release makefile - (src/release/Makefile) is fairly abstruse. Most - developers will only be concerned with the release - and install targets.

-
-
-
Meta-target to build all release media and distributions applicable to - this platform.
-
-
Copy all produced release media to - ${DESTDIR}.
-
-
Builds installation CD-ROM images. This may require the - md(4) (memory disk) device driver be present in the - kernel (either by being compiled in or available as a module). This target - produces files called disc1.iso and - bootonly.iso as its output.
-
-
Builds installation DVD-ROM images. This may require the - md(4) (memory disk) device driver be present in the - kernel (either by being compiled in or available as a module). This target - produces the dvd1.iso file as its output.
-
-
Builds an installation memory stick image named - memstick.img. Not applicable on all platforms. - Requires that the md(4) (memory disk) device driver be - present in the kernel (either by being compiled in or available as a - module).
-
-
Similar to memstick, with the exception that the - installation distribution sets are not included.
-
-
Creates a directory named ftp containing the - distribution files used in network installations and suitable for upload - to an FTP mirror.
-
-
Creates virtual machine disk images in various formats. The - vm-image target requires the - WITH_VMIMAGES make(1) environment - variable to be set to a non-null value.
-
-
Builds FreeBSD virtual machine images for various - cloud hosting providers. See "CLOUD HOSTING MACHINE IMAGES" for - implementation details.
-
-
Displays the list of valid CLOUDWARE values.
-
-
Displays the list of valid VMFORMATS and - CLOUDWARE values.
-
-

Major subtargets called by targets above:

-
-
-
Generates all the distribution archives (base, kernel, ports, doc) - applicable on this platform.
-
-
Builds a bootable installation system containing all the distribution - files packaged by the packagesystem target, and - suitable for imaging by the cdrom, - dvdrom and memstick - targets.
-
-
Builds the release documentation. This includes the release notes, - hardware guide, and installation instructions. Other documentation, such - as the Handbook, is built during the base.txz - target invoked by packagesystem.
-
-
-
-

-

Optional variables:

-
-
-
Optional base name for generated media images when invoking the - install target (e.g., FreeBSD-12.1-RELEASE-amd64). - Defaults to the output of `uname -s`-`uname -r`-`uname - -p` within the chroot.
-
-
Location of a directory containing the src tree. By default, the directory - above the one containing the makefile (src).
-
-
Location of a directory containing the ports tree. By default, - /usr/ports. If it is unset or cannot be found, - ports will not be included in the release.
-
-
If defined, the Ports Collection will be omitted from the release.
-
-
If set, do not include system source code in the release.
-
-
The target hardware platform. This is analogous to the - “uname -m” - output. This is necessary to cross-build some target architectures. For - example, cross-building for ARM64 machines requires - TARGET_ARCH=aarch64 and - TARGET=arm64. If not set, - TARGET defaults to the current hardware - platform.
-
-
The target machine processor architecture. This is analogous to the - “uname -p” - output. Set this to cross-build for a different architecture. If not set, - TARGET_ARCH defaults to the current machine - architecture, unless TARGET is also set, in which - case it defaults to the appropriate value for that platform. Typically, - one only needs to set TARGET.
-
-
-
-

-
-
/scratch
-
 
-
/usr/doc/Makefile
-
 
-
/usr/doc/share/mk/doc.project.mk
-
 
-
/usr/ports/Mk/bsd.port.mk
-
 
-
/usr/ports/Mk/bsd.sites.mk
-
 
-
/usr/share/examples/etc/make.conf
-
 
-
/usr/src/Makefile
-
 
-
/usr/src/Makefile.inc1
-
 
-
/usr/src/release/Makefile
-
 
-
/usr/src/release/Makefile.vm
-
 
-
/usr/src/release/release.sh
-
 
-
/usr/src/release/release.conf.sample
-
 
-
/usr/src/release/tools/*.conf
-
 
-
/usr/src/release/tools/vmimage.subr
-
 
-
-
-
-

-

The following sequence of commands can be used to build a - “-CURRENT snapshot”:

-
-
cd /usr
-git clone -b main https://git.freebsd.org/src.git src
-cd src
-make buildworld buildkernel
-cd release
-make obj
-make release
-make install DESTDIR=/var/freebsd-snapshot
-
-

After running these commands, all produced distribution files - (tarballs for FTP, CD-ROM images, etc.) are available in the - /var/freebsd-snapshot directory.

-

The following sequence of commands can be used to build a - “-CURRENT snapshot” in a clean environment, including ports - and documentation:

-
-
cd /usr/src/release
-sh release.sh
-
-

Optionally, a configuration file can be used to customize the - release build:

-
-
cd /usr/src/release
-sh release.sh -c $HOME/release.conf
-
-

Configuration files specific to various supported embedded - systems, such as the Raspberry Pi, exist in the directory corresponding to - the TARGET make(1) variable. For - example, to build an image for 64-bit Raspberry Pis:

-
-
cd /usr/src/release
-sh release.sh -c arm64/RPI.conf
-
-

After running these commands, all prepared release files are - available in the /scratch directory. The target - directory can be changed by specifying the CHROOTDIR - variable in release.conf.

-
-
-

-

The reldoc target was removed in commit f61e92ca5a23, and - DOCDIR, DOCBRANCH, - DOC_UPDATE_SKIP, and NODOC - are therefore no longer supported.

-
-
-

-

cc(1), git(1) - (ports/devel/git), install(1), - make(1), mkimg(1), - uname(1), md(4), - make.conf(5), build(7), - ports(7), chroot(8), - mtree(8), sysctl(8)

-

FreeBSD Release - Engineering, - https://docs.freebsd.org/en/articles/freebsd-releng/.

-

FreeBSD Developers' - Handbook, - https://docs.freebsd.org/en/books/developers-handbook/.

-
-
-

-

FreeBSD 1.x used a manual checklist, - compiled by Rod Grimes, to produce a release. Apart - from being incomplete, the list put a lot of specific demands on available - file systems and was quite torturous to execute.

-

As part of the FreeBSD 2.0 release - engineering effort, significant effort was spent getting - src/release/Makefile into a shape where it could at - least automate most of the tediousness of building a release in a sterile - environment.

-

For the FreeBSD 9.0 release, - src/release/Makefile was overhauled and the wrapper - script src/release/generate-release.sh introduced to - support the introduction of a new installer.

-

For the FreeBSD 9.2 release, - src/release/release.sh was introduced to support - per-build configuration files. - src/release/release.sh is heavily based on the - src/release/generate-release.sh script.

-

At near 1000 revisions spread over multiple branches, the - git(1) log of src/release/Makefile - contains a vivid historical record of some of the hardships release - engineers go through.

-
-
-

-

src/release/Makefile was originally - written by Rod Grimes, Jordan - Hubbard, and Poul-Henning Kamp.

-

This manual page was originally written by Murray - Stokely - <murray@FreeBSD.org>.

-

It was updated by Nathan Whitehorn - <nwhitehorn@FreeBSD.org> - to include the generate-release.sh script used for the - FreeBSD 9.0 release cycle.

-

It was later updated by Glen Barber - <gjb@FreeBSD.org> to - include the release.sh script used for the - FreeBSD 9.2 release cycle.

-
-
- - - - - -
October 13, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/sdoc.7 3.html b/static/freebsd/man7/sdoc.7 3.html deleted file mode 100644 index 6b5ac4ff..00000000 --- a/static/freebsd/man7/sdoc.7 3.html +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - -
SDOC(7)Miscellaneous Information ManualSDOC(7)
-
-
-

-

sdoc — guide to - adding security considerations sections to manual pages

-
-
-

-

This document presents guidelines for adding security - considerations sections to manual pages. It provides two typical - examples.

-

The guidelines for writing FreeBSD manual - pages in groff_mdoc(7) mandate that each manual page - describing a feature of the FreeBSD system should - contain a security considerations section describing what security - requirements can be broken through the misuse of that feature. When writing - these sections, authors should attempt to achieve a happy medium between two - conflicting goals: brevity and completeness. On one hand, security - consideration sections must not be too verbose, or busy readers might be - dissuaded from reading them. On the other hand, security consideration - sections must not be incomplete, or they will fail in their purpose of - instructing the reader on how to avoid all insecure uses. This document - provides guidelines for balancing brevity and completeness in the security - consideration section for a given feature of the - FreeBSD system.

-
-

-

Begin by listing those general security requirements that can be - violated through the misuse of the feature. There are four classes of - security requirements:

-
-
-
(example: non-administrators should not modify system binaries),
-
-
(example: non-administrators should not view the shadow password - file),
-
-
(example: the web server should respond to client requests in a timely - fashion), and
-
-
(example: the ps program should provide exactly the process table - information listing functionality described in its documentation - no - more, no less.)
-
-

A good security considerations section should explain how the - feature can be misused to violate each general security requirement in the - list. Each explanation should be accompanied by instructions the reader - should follow in order to avoid a violation. When referencing potential - vulnerabilities described in the Secure Programming Practices manual page, - sprog(7), likewise cross-reference that document rather - than replicating information. Whenever possible, refer to this document - rather than reproducing the material it contains.

-
-
-

-

Security problems are often interrelated; individual problems - often have far-reaching implications. For example, the correctness of - virtually any dynamically-linked program is dependent on the correct - implementation and configuration of the run-time linker. The correctness of - this program, in turn, depends on the correctness of its libraries, the - compiler used to build it, the correctness of the preceding compiler that - was used to build that compiler, and so on, as described by Thompson (see - SEE ALSO, below).

-

Due to the need for brevity, security consideration sections - should describe only those issues directly related to the feature that is - the subject of the manual page. Refer to other manual pages rather than - duplicating the material found there.

-
-
-
-

-

Security considerations sections for most individual functions can - follow this simple formula:

-

-
    -
  1. Provide one or two sentences describing each potential security - problem.
    2. -
  2. Provide one or two sentences describing how to avoid each potential - security problem.
    3. -
  3. Provide a short example in code.
    4. -
-

This is an example security considerations section for the - strcpy(3) manual page:

-

The strcpy() function is easily misused in - a manner which enables malicious users to arbitrarily change a running - program's functionality through a buffer overflow attack.

-

Avoid using strcpy(). Instead, use - strncpy() and ensure that no more characters are - copied to the destination buffer than it can hold. Do not forget to - NUL-terminate the destination buffer, as strncpy() - will not terminate the destination string if it is truncated.

-

Note that strncpy() can also be - problematic. It may be a security concern for a string to be truncated at - all. Since the truncated string will not be as long as the original, it may - refer to a completely different resource and usage of the truncated resource - could result in very incorrect behavior. Example:

-
-
void
-foo(const char *arbitrary_string)
-{
-	char onstack[8];
-
-#if defined(BAD)
-	/*
-	 * This first strcpy is bad behavior.  Do not use strcpy()!
-	 */
-	(void)strcpy(onstack, arbitrary_string);     /* BAD! */
-#elif defined(BETTER)
-	/*
-	 * The following two lines demonstrate better use of
-	 * strncpy().
-	 */
-	(void)strncpy(onstack, arbitrary_string, sizeof(onstack) - 1);
-	onstack[sizeof(onstack - 1)] = '\0';
-#elif defined(BEST)
-	/*
-	 * These lines are even more robust due to testing for
-	 * truncation.
-	 */
-	if (strlen(arbitrary_string) + 1 > sizeof(onstack))
-		err(1, "onstack would be truncated");
-	(void)strncpy(onstack, arbitrary_string, sizeof(onstack));
-#endif
-}
-
-

Security considerations sections for tools and commands are apt to - be less formulaic. Let your list of potentially-violated security - requirements be your guide; explain each one and list a solution in as - concise a manner as possible.

-

This is an example security considerations section for the - rtld(1) manual page:

-

Using the LD_LIBRARY_PATH and LD_PRELOAD environment variables, - malicious users can cause the dynamic linker to link shared libraries of - their own devising into the address space of processes running - non-set-user-ID/group-ID programs. These shared libraries can arbitrarily - change the functionality of the program by replacing calls to standard - library functions with calls to their own. Although this feature is disabled - for set-user-ID and set-group-ID programs, it can still be used to create - Trojan horses in other programs.

-

All users should be aware that the correct operation of non - set-user-ID/group-ID dynamically-linked programs depends on the proper - configuration of these environment variables, and take care to avoid actions - that might set them to values which would cause the run-time linker to link - in shared libraries of unknown pedigree.

-
-
-

-

groff_mdoc(7), security(7), - sprog(7)

-

Edward Amoroso, AT&T Bell - Laboratories, Fundamentals of Computer Security - Technology, P T R Prentice Hall, - 1994.

-

Ken Thompson, - Reflections on Trusting Trust, - Association for Computing Machinery, Inc., - Communications of the ACM, Vol. 27, No. - 8, 761-763, August, - 1984.

-
-
-

-

The sdoc manual page first appeared in - FreeBSD 5.0.

-
-
-

-

Tim Fraser - <tfraser@tislabs.com>, - NAI Labs CBOSS project -
- Brian Feldman - <bfeldman@tislabs.com>, - NAI Labs CBOSS project

-
-
- - - - - -
September 5, 2005FreeBSD 15.0
diff --git a/static/freebsd/man7/security.7 3.html b/static/freebsd/man7/security.7 3.html deleted file mode 100644 index c8fa0338..00000000 --- a/static/freebsd/man7/security.7 3.html +++ /dev/null @@ -1,725 +0,0 @@ - - - - - - -
SECURITY(7)Miscellaneous Information ManualSECURITY(7)
-
-
-

-

security, - securelevel — introduction - to security under FreeBSD

-
-
-

-

See mitigations(7) for a description of - vulnerability mitigations in FreeBSD. This man page - documents other FreeBSD security related topics.

-

Security is a function that begins and ends with the system - administrator. While all BSD multi-user systems have - some inherent security, the job of building and maintaining additional - security mechanisms to keep users “honest” is probably one of - the single largest undertakings of the sysadmin. Machines are only as secure - as you make them, and security concerns are ever competing with the human - necessity for convenience. UNIX systems, in general, - are capable of running a huge number of simultaneous processes and many of - these processes operate as servers — meaning that external entities - can connect and talk to them. As yesterday's mini-computers and mainframes - become today's desktops, and as computers become networked and - internetworked, security becomes an ever bigger issue.

-

Security is best implemented through a layered onion approach. In - a nutshell, what you want to do is to create as many layers of security as - are convenient and then carefully monitor the system for intrusions.

-

System security also pertains to dealing with various forms of - attacks, including attacks that attempt to crash or otherwise make a system - unusable but do not attempt to break root. Security concerns can be split up - into several categories:

-
    -
  1. Denial of Service attacks (DoS)
    2. -
  2. User account compromises
    3. -
  3. Root compromise through accessible servers
    4. -
  4. Root compromise via user accounts
    5. -
  5. Backdoor creation
    6. -
-

A denial of service attack is an action that deprives the machine - of needed resources. Typically, DoS attacks are brute-force mechanisms that - attempt to crash or otherwise make a machine unusable by overwhelming its - servers or network stack. Some DoS attacks try to take advantages of bugs in - the networking stack to crash a machine with a single packet. The latter can - only be fixed by applying a bug fix to the kernel. Attacks on servers can - often be fixed by properly specifying options to limit the load the servers - incur on the system under adverse conditions. Brute-force network attacks - are harder to deal with. A spoofed-packet attack, for example, is nearly - impossible to stop short of cutting your system off from the Internet. It - may not be able to take your machine down, but it can fill up your Internet - pipe.

-

A user account compromise is even more common than a DoS attack. - Some sysadmins still run telnetd and - ftpd(8) servers on their machines. These servers, by - default, do not operate over encrypted connections. The result is that if - you have any moderate-sized user base, one or more of your users logging - into your system from a remote location (which is the most common and - convenient way to log in to a system) will have his or her password sniffed. - The attentive system administrator will analyze his remote access logs - looking for suspicious source addresses even for successful logins.

-

One must always assume that once an attacker has access to a user - account, the attacker can break root. However, the reality is that in a well - secured and maintained system, access to a user account does not necessarily - give the attacker access to root. The distinction is important because - without access to root the attacker cannot generally hide his tracks and - may, at best, be able to do nothing more than mess with the user's files or - crash the machine. User account compromises are very common because users - tend not to take the precautions that sysadmins take.

-

System administrators must keep in mind that there are potentially - many ways to break root on a machine. The attacker may know the root - password, the attacker may find a bug in a root-run server and be able to - break root over a network connection to that server, or the attacker may - know of a bug in an SUID-root program that allows the attacker to break root - once he has broken into a user's account. If an attacker has found a way to - break root on a machine, the attacker may not have a need to install a - backdoor. Many of the root holes found and closed to date involve a - considerable amount of work by the attacker to clean up after himself, so - most attackers do install backdoors. This gives you a convenient way to - detect the attacker. Making it impossible for an attacker to install a - backdoor may actually be detrimental to your security because it will not - close off the hole the attacker used to break in originally.

-

Security remedies should always be implemented with a - multi-layered “onion peel” approach and can be categorized as - follows:

-
    -
  1. Securing root and staff accounts
    2. -
  2. Securing root — root-run servers and SUID/SGID binaries
    3. -
  3. Securing user accounts
    4. -
  4. Securing the password file
    5. -
  5. Securing the kernel core, raw devices, and file systems
    6. -
  6. Quick detection of inappropriate changes made to the system
    7. -
  7. Paranoia
    8. -
-
-
-

-

Do not bother securing staff accounts if you have not secured the - root account. Most systems have a password assigned to the root account. The - first thing you do is assume that the password is - - compromised. This does not mean that you should remove the password. The - password is almost always necessary for console access to the machine. What - it does mean is that you should not make it possible to use the password - outside of the console or possibly even with a su(1) - utility. For example, make sure that your PTYs are specified as being - “insecure” in the - /etc/ttys file so that direct root logins via - telnet(1) are disallowed. If using other login services - such as sshd(8), make sure that direct root logins are - disabled there as well. Consider every access method — services such - as ftp(1) often fall through the cracks. Direct root - logins should only be allowed via the system console.

-

Of course, as a sysadmin you have to be able to get to root, so we - open up a few holes. But we make sure these holes require additional - password verification to operate. One way to make root accessible is to add - appropriate staff accounts to the - “wheel” group (in - /etc/group). The staff members placed in the - wheel group are allowed to su(1) - to root. You should never give staff members native - wheel access by putting them in the - wheel group in their password entry. Staff accounts - should be placed in a “staff” group, - and then added to the wheel group via the - /etc/group file. Only those staff members who - actually need to have root access should be placed in the - wheel group. It is also possible, when using an - authentication method such as Kerberos, to use Kerberos's - .k5login file in the root account to allow a - ksu(1) to root without having to place anyone at all in - the wheel group. This may be the better solution - since the wheel mechanism still allows an intruder - to break root if the intruder has gotten hold of your password file and can - break into a staff account. While having the wheel - mechanism is better than having nothing at all, it is not necessarily the - safest option.

-

An indirect way to secure the root account is to secure - your staff accounts by using an alternative login access method and *'ing - out the crypted password for the staff accounts. This way an intruder may be - able to steal the password file but will not be able to break into any staff - accounts or root, even if root has a crypted password associated with it - (assuming, of course, that you have limited root access to the console). - Staff members get into their staff accounts through a secure login mechanism - such as kerberos(8) or ssh(1) using a - private/public key pair. When you use something like Kerberos you generally - must secure the machines which run the Kerberos servers and your desktop - workstation. When you use a public/private key pair with SSH, you must - generally secure the machine you are logging in - (typically your - workstation), but you can also add an additional layer of protection to the - key pair by password protecting the keypair when you create it with - ssh-keygen(1). Being able to star-out the passwords for - staff accounts also guarantees that staff members can only log in through - secure access methods that you have set up. You can thus force all staff - members to use secure, encrypted connections for all their sessions which - closes an important hole used by many intruders: that of sniffing the - network from an unrelated, less secure machine.

-

The more indirect security mechanisms also assume that you are - logging in from a more restrictive server to a less restrictive server. For - example, if your main box is running all sorts of servers, your workstation - should not be running any. In order for your workstation to be reasonably - secure you should run as few servers as possible, up to and including no - servers at all, and you should run a password-protected screen blanker. Of - course, given physical access to a workstation, an attacker can break any - sort of security you put on it. This is definitely a problem that you should - consider but you should also consider the fact that the vast majority of - break-ins occur remotely, over a network, from people who do not have - physical access to your workstation or servers.

-

Using something like Kerberos also gives you the ability to - disable or change the password for a staff account in one place and have it - immediately affect all the machines the staff member may have an account on. - If a staff member's account gets compromised, the ability to instantly - change his password on all machines should not be underrated. With discrete - passwords, changing a password on N machines can be a mess. You can also - impose re-passwording restrictions with Kerberos: not only can a Kerberos - ticket be made to timeout after a while, but the Kerberos system can require - that the user choose a new password after a certain period of time (say, - once a month).

-
-
-

-

The prudent sysadmin only runs the servers he needs to, no more, - no less. Be aware that third party servers are often the most bug-prone. For - example, running an old version of imapd(8) or - popper(8) (ports/mail/popper) is - like giving a universal root ticket out to the entire world. Never run a - server that you have not checked out carefully. Many servers do not need to - be run as root. For example, the talkd(8), - comsat(8), and fingerd(8) daemons can be - run in special user “sandboxes”. A sandbox is not perfect - unless you go to a large amount of trouble, but the onion approach to - security still stands: if someone is able to break in through a server - running in a sandbox, they still have to break out of the sandbox. The more - layers the attacker must break through, the lower the likelihood of his - success. Root holes have historically been found in virtually every server - ever run as root, including basic system servers. If you are running a - machine through which people only log in via sshd(8) and - never log in via telnetd then turn off this - service!

-

FreeBSD now defaults to running - talkd(8), comsat(8), and - fingerd(8) in a sandbox. Depending on whether you are - installing a new system or upgrading an existing system, the special user - accounts used by these sandboxes may not be installed. The prudent sysadmin - would research and implement sandboxes for servers whenever possible.

-

There are a number of other servers that typically do not run in - sandboxes: sendmail(8), popper(8), - imapd(8), and others. There are alternatives to some of - these, but installing them may require more work than you are willing to put - (the convenience factor strikes again). You may have to run these servers as - root and rely on other mechanisms to detect break-ins that might occur - through them.

-

The other big potential root hole in a system are the SUID-root - and SGID binaries installed on the system. Most of these binaries, such as - su(1), reside in /bin, - /sbin, /usr/bin, or - /usr/sbin. While nothing is 100% safe, the - system-default SUID and SGID binaries can be considered reasonably safe. - Still, root holes are occasionally found in these binaries. A root hole was - found in Xlib in 1998 that made xterm(1) - (ports/x11/xterm) (which is typically SUID) - vulnerable. It is better to be safe than sorry and the prudent sysadmin will - restrict SUID binaries that only staff should run to a special group that - only staff can access, and get rid of (“chmod - 000”) any SUID binaries that nobody uses. A server with no - display generally does not need an xterm(1) - (ports/x11/xterm) binary. SGID binaries can be - almost as dangerous. If an intruder can break an SGID-kmem binary the - intruder might be able to read /dev/kmem and thus - read the crypted password file, potentially compromising any passworded - account. Alternatively an intruder who breaks group - “kmem” can monitor keystrokes sent - through PTYs, including PTYs used by users who log in through secure - methods. An intruder that breaks the - “tty” group can write to almost any - user's TTY. If a user is running a terminal program or emulator with a - keyboard-simulation feature, the intruder can potentially generate a data - stream that causes the user's terminal to echo a command, which is then run - as that user.

-
-
-

-

User accounts are usually the most difficult to secure. While you - can impose draconian access restrictions on your staff and *-out their - passwords, you may not be able to do so with any general user accounts you - might have. If you do have sufficient control then you may win out and be - able to secure the user accounts properly. If not, you simply have to be - more vigilant in your monitoring of those accounts. Use of SSH and Kerberos - for user accounts is more problematic due to the extra administration and - technical support required, but still a very good solution compared to a - crypted password file.

-
-
-

-

The only sure fire way is to *-out as many passwords as you can - and use SSH or Kerberos for access to those accounts. Even though the - crypted password file (/etc/spwd.db) can only be - read by root, it may be possible for an intruder to obtain read access to - that file even if the attacker cannot obtain root-write access.

-

Your security scripts should always check for and report changes - to the password file (see - CHECKING FILE INTEGRITY - below).

-
-
-

-

If an attacker breaks root he can do just about anything, but - there are certain conveniences. For example, most modern kernels have a - packet sniffing device driver built in. Under - FreeBSD it is called the bpf(4) - device. An intruder will commonly attempt to run a packet sniffer on a - compromised machine. You do not need to give the intruder the capability and - most systems should not have the bpf(4) device compiled - in.

-

But even if you turn off the bpf(4) device, you - still have /dev/mem and - /dev/kmem to worry about. For that matter, the - intruder can still write to raw disk devices. Also, there is another kernel - feature called the module loader, kldload(8). An - enterprising intruder can use a KLD module to install his own - bpf(4) device or other sniffing device on a running - kernel. To avoid these problems you have to run the kernel at a higher - security level, at least level 1. The security level can be set with a - sysctl(8) on the kern.securelevel - variable. Once you have set the security level to 1, write access to raw - devices will be denied and special chflags(1) flags, such - as schg, will be enforced. You must also ensure that - the schg flag is set on critical startup binaries, - directories, and script files — everything that gets run up to the - point where the security level is set. This might be overdoing it, and - upgrading the system is much more difficult when you operate at a higher - security level. You may compromise and run the system at a higher security - level but not set the schg flag for every system - file and directory under the sun. Another possibility is to simply mount - / and /usr read-only. It - should be noted that being too draconian in what you attempt to protect may - prevent the all-important detection of an intrusion.

-

The kernel runs with five different security levels. Any - super-user process can raise the level, but no process can lower it. The - security levels are:

-
-
-
Permanently insecure mode - always run the system in insecure mode. This - is the default initial value.
-
-
Insecure mode - immutable and append-only flags may be turned off. All - devices may be read or written subject to their permissions.
-
-
Secure mode - the system immutable and system append-only flags may not be - turned off; disks for mounted file systems, - /dev/mem and /dev/kmem may - not be opened for writing; /dev/io (if your - platform has it) may not be opened at all; kernel modules (see - kld(4)) may not be loaded or unloaded. The kernel - debugger may not be entered using the - debug.kdb.enter sysctl unless a - mac(9) policy grants access, for example using - mac_ddb(4). A panic or trap cannot be forced using the - debug.kdb.panic, - debug.kdb.panic_str and other sysctl's.
-
-
Highly secure mode - same as secure mode, plus disks may not be opened for - writing (except by mount(2)) whether mounted or not. - This level precludes tampering with file systems by unmounting them, but - also inhibits running newfs(8) while the system is - multi-user. -

In addition, kernel time changes are restricted to less than - or equal to one second. Attempts to change the time by more than this - will log the message “Time adjustment clamped to +1 - second”.

-
-
-
Network secure mode - same as highly secure mode, plus IP packet filter - rules (see ipfw(8), ipfirewall(4) and - pfctl(8)) cannot be changed and - dummynet(4) or pf(4) configuration - cannot be adjusted.
-
-

The security level can be configured with variables documented in - rc.conf(5).

-
-
-

-

When it comes right down to it, you can only protect your core - system configuration and control files so much before the convenience factor - rears its ugly head. For example, using chflags(1) to set - the schg bit on most of the files in - / and /usr is probably - counterproductive because while it may protect the files, it also closes a - detection window. The last layer of your security onion is perhaps the most - important — detection. The rest of your security is pretty much - useless (or, worse, presents you with a false sense of safety) if you cannot - detect potential incursions. Half the job of the onion is to slow down the - attacker rather than stop him in order to give the detection layer a chance - to catch him in the act.

-

The best way to detect an incursion is to look for modified, - missing, or unexpected files. The best way to look for modified files is - from another (often centralized) limited-access system. Writing your - security scripts on the extra-secure limited-access system makes them mostly - invisible to potential attackers, and this is important. In order to take - maximum advantage you generally have to give the limited-access box - significant access to the other machines in the business, usually either by - doing a read-only NFS export of the other machines to the limited-access - box, or by setting up SSH keypairs to allow the limit-access box to SSH to - the other machines. Except for its network traffic, NFS is the least visible - method — allowing you to monitor the file systems on each client box - virtually undetected. If your limited-access server is connected to the - client boxes through a switch, the NFS method is often the better choice. If - your limited-access server is connected to the client boxes through a hub or - through several layers of routing, the NFS method may be too insecure - (network-wise) and using SSH may be the better choice even with the - audit-trail tracks that SSH lays.

-

Once you give a limit-access box at least read access to the - client systems it is supposed to monitor, you must write scripts to do the - actual monitoring. Given an NFS mount, you can write scripts out of simple - system utilities such as find(1) and - md5(1). It is best to physically md5(1) - the client-box files boxes at least once a day, and to test control files - such as those found in /etc and - /usr/local/etc even more often. When mismatches are - found relative to the base MD5 information the limited-access machine knows - is valid, it should scream at a sysadmin to go check it out. A good security - script will also check for inappropriate SUID binaries and for new or - deleted files on system partitions such as / and - /usr.

-

When using SSH rather than NFS, writing the security script is - much more difficult. You essentially have to scp(1) the - scripts to the client box in order to run them, making them visible, and for - safety you also need to scp(1) the binaries (such as - find(1)) that those scripts use. The - sshd(8) daemon on the client box may already be - compromised. All in all, using SSH may be necessary when running over - unsecure links, but it is also a lot harder to deal with.

-

A good security script will also check for changes to user and - staff members access configuration files: .rhosts, - .shosts, - .ssh/authorized_keys and so forth, files that might - fall outside the purview of the MD5 check.

-

If you have a huge amount of user disk space it may take too long - to run through every file on those partitions. In this case, setting mount - flags to disallow SUID binaries on those partitions is a good idea. The - nosuid option (see mount(8)) is - what you want to look into. I would scan them anyway at least once a week, - since the object of this layer is to detect a break-in whether or not the - break-in is effective.

-

Process accounting (see accton(8)) is a - relatively low-overhead feature of the operating system which I recommend - using as a post-break-in evaluation mechanism. It is especially useful in - tracking down how an intruder has actually broken into a system, assuming - the file is still intact after the break-in occurs.

-

Finally, security scripts should process the log files and the - logs themselves should be generated in as secure a manner as possible - — remote syslog can be very useful. An intruder tries to cover his - tracks, and log files are critical to the sysadmin trying to track down the - time and method of the initial break-in. One way to keep a permanent record - of the log files is to run the system console to a serial port and collect - the information on a continuing basis through a secure machine monitoring - the consoles.

-
-
-

-

A little paranoia never hurts. As a rule, a sysadmin can add any - number of security features as long as they do not affect convenience, and - can add security features that do affect convenience with some added - thought. Even more importantly, a security administrator should mix it up a - bit — if you use recommendations such as those given by this manual - page verbatim, you give away your methodologies to the prospective attacker - who also has access to this manual page.

-
-
-

-

This section covers Denial of Service attacks. A DoS attack is - typically a packet attack. While there is not much you can do about modern - spoofed packet attacks that saturate your network, you can generally limit - the damage by ensuring that the attacks cannot take down your servers.

-
    -
  1. Limiting server forks
    2. -
  2. Limiting springboard attacks (ICMP response attacks, ping broadcast, - etc.)
    3. -
  3. Kernel Route Cache
    4. -
-

A common DoS attack is against a forking server that attempts to - cause the server to eat processes, file descriptors, and memory until the - machine dies. The inetd(8) server has several options to - limit this sort of attack. It should be noted that while it is possible to - prevent a machine from going down it is not generally possible to prevent a - service from being disrupted by the attack. Read the - inetd(8) manual page carefully and pay specific attention - to the -c, -C, and - -R options. Note that spoofed-IP attacks will - circumvent the -C option to - inetd(8), so typically a combination of options must be - used. Some standalone servers have self-fork-limitation parameters.

-

The sendmail(8) daemon has its - -OMaxDaemonChildren option which tends to work much - better than trying to use sendmail(8)'s load limiting - options due to the load lag. You should specify a - MaxDaemonChildren parameter when you start - sendmail(8) high enough to handle your expected load but - not so high that the computer cannot handle that number of - sendmail's without falling on its face. It is also - prudent to run sendmail(8) in “queued” mode - (-ODeliveryMode=queued) and to run the daemon - (“sendmail - -bd”) separate from the queue-runs - (“sendmail - -q15m”). If you still want real-time delivery - you can run the queue at a much lower interval, such as - -q1m, but be sure to specify a reasonable - MaxDaemonChildren option for that - sendmail(8) to prevent cascade failures.

-

The syslogd(8) daemon can be attacked directly - and it is strongly recommended that you use the -s - option whenever possible, and the -a option - otherwise.

-

You should also be fairly careful with connect-back services such - as tcpwrapper's reverse-identd, which can be attacked directly. You - generally do not want to use the reverse-ident feature of tcpwrappers for - this reason.

-

It is a very good idea to protect internal services - from external access by firewalling them off at your border routers. The - idea here is to prevent saturation attacks from outside your LAN, not so - much to protect internal services from network-based root compromise. Always - configure an exclusive firewall, i.e., ‘firewall everything - ports A, B, - C, D, and M-Z’. This way you can firewall off all of your low ports - except for certain specific services such as talkd(8), - sendmail(8), and other internet-accessible services. If - you try to configure the firewall the other way — as an inclusive or - permissive firewall, there is a good chance that you will forget to - “close” a couple of services or that you will add a new - internal service and forget to update the firewall. You can still open up - the high-numbered port range on the firewall to allow permissive-like - operation without compromising your low ports. Also take note that - FreeBSD allows you to control the range of port - numbers used for dynamic binding via the various - net.inet.ip.portrange sysctl's - (“sysctl net.inet.ip.portrange”), - which can also ease the complexity of your firewall's configuration. I - usually use a normal first/last range of 4000 to 5000, and a hiport range of - 49152 to 65535, then block everything under 4000 off in my firewall (except - for certain specific internet-accessible ports, of course).

-

Another common DoS attack is called a springboard attack — - to attack a server in a manner that causes the server to generate responses - which then overload the server, the local network, or some other machine. - The most common attack of this nature is the ICMP PING BROADCAST attack. The - attacker spoofs ping packets sent to your LAN's broadcast address with the - source IP address set to the actual machine they wish to attack. If your - border routers are not configured to stomp on ping's to broadcast addresses, - your LAN winds up generating sufficient responses to the spoofed source - address to saturate the victim, especially when the attacker uses the same - trick on several dozen broadcast addresses over several dozen different - networks at once. Broadcast attacks of over a hundred and twenty megabits - have been measured. A second common springboard attack is against the ICMP - error reporting system. By constructing packets that generate ICMP error - responses, an attacker can saturate a server's incoming network and cause - the server to saturate its outgoing network with ICMP responses. This type - of attack can also crash the server by running it out of - mbuf's, especially if the server cannot drain the ICMP - responses it generates fast enough. The FreeBSD - kernel has a new kernel compile option called - ICMP_BANDLIM which limits the effectiveness of these - sorts of attacks. The last major class of springboard attacks is related to - certain internal inetd(8) services such as the UDP echo - service. An attacker simply spoofs a UDP packet with the source address - being server A's echo port, and the destination address being server B's - echo port, where server A and B are both on your LAN. The two servers then - bounce this one packet back and forth between each other. The attacker can - overload both servers and their LANs simply by injecting a few packets in - this manner. Similar problems exist with the internal chargen port. A - competent sysadmin will turn off all of these - inetd(8)-internal test services.

-
-
-

-

There are a few issues with both Kerberos and SSH that need to be - addressed if you intend to use them. Kerberos5 is an excellent - authentication protocol but the kerberized telnet(1) suck - rocks. There are bugs that make them unsuitable for dealing with binary - streams. Also, by default Kerberos does not encrypt a session unless you use - the -x option. SSH encrypts everything by - default.

-

SSH works quite well in every respect except when it is set up to - forward encryption keys. What this means is that if you have a secure - workstation holding keys that give you access to the rest of the system, and - you ssh(1) to an unsecure machine, your keys become - exposed. The actual keys themselves are not exposed, but - ssh(1) installs a forwarding port for the duration of your - login and if an attacker has broken root on the unsecure machine he can - utilize that port to use your keys to gain access to any other machine that - your keys unlock.

-

We recommend that you use SSH in combination with Kerberos - whenever possible for staff logins. SSH can be compiled with Kerberos - support. This reduces your reliance on potentially exposable SSH keys while - at the same time protecting passwords via Kerberos. SSH keys should only be - used for automated tasks from secure machines (something that Kerberos is - unsuited to). We also recommend that you either turn off key-forwarding in - the SSH configuration, or that you make use of the - from=IP/DOMAIN option that SSH - allows in its authorized_keys file to make the key - only usable to entities logging in from specific machines.

-
-
-

-

FreeBSD provides several knobs and tweak - handles that make some introspection information access more restricted. - Some people consider this as improving system security, so the knobs are - briefly listed there, together with controls which enable some mitigations - of the hardware state leaks.

-

Hardware mitigation sysctl knobs described below have been moved - under machdep.mitigations, with - backwards-compatibility shims to accept the existing names. A future change - will rationalize the sense of the individual sysctls (so that enabled / true - always indicates that the mitigation is active). For that reason the - previous names remain the canonical way to set the mitigations, and are - documented here. Backwards compatibility shims for the interim sysctls under - machdep.mitigations will not be added.

-
-
security.bsd.see_other_uids
-
Controls visibility and reachability of subjects (e.g., processes) and - objects (e.g., sockets) owned by a different uid. The knob directly - affects the kern.proc sysctls filtering of data, - which results in restricted output from utilities like - ps(1).
-
security.bsd.see_other_gids
-
Same, for subjects and objects owned by a different gid.
-
security.bsd.see_jail_proc
-
Same, for subjects and objects belonging to a different jail, including - sub-jails.
-
security.bsd.conservative_signals
-
When enabled, unprivileged users are only allowed to send job control and - usual termination signals like SIGKILL, - SIGINT, and SIGTERM, to - the processes executing programs with changed uids.
-
security.bsd.unprivileged_proc_debug
-
Controls availability of the process debugging facilities to non-root - users. See also proccontrol(1) mode - trace.
-
vm.pmap.pti
-
Tunable, amd64-only. Enables mode of operation of virtual memory system - where usermode page tables are sanitized to prevent so-called Meltdown - information leak on some Intel CPUs. By default, the system detects - whether the CPU needs the workaround, and enables it automatically. See - also proccontrol(1) mode - kpti.
-
machdep.mitigations.flush_rsb_ctxsw
-
amd64. Controls Return Stack Buffer flush on context switch, to prevent - cross-process ret2spec attacks. Only needed, and only enabled by default, - if the machine supports SMEP, otherwise IBRS would do necessary flushing - on kernel entry anyway.
-
hw.mds_disable
-
amd64 and i386. Controls Microarchitectural Data Sampling hardware - information leak mitigation.
-
hw.spec_store_bypass_disable
-
amd64 and i386. Controls Speculative Store Bypass hardware information - leak mitigation.
-
hw.ibrs_disable
-
amd64 and i386. Controls Indirect Branch Restricted Speculation hardware - information leak mitigation.
-
machdep.syscall_ret_flush_l1d
-
amd64. Controls force-flush of L1D cache on return from syscalls which - report errors other than EEXIST, - EAGAIN, EXDEV, - ENOENT, ENOTCONN, and - EINPROGRESS. This is mostly a paranoid setting - added to prevent hypothetical exploitation of unknown gadgets for unknown - hardware issues. The error codes exclusion list is composed of the most - common errors which typically occurs on normal system operation.
-
machdep.nmi_flush_l1d_sw
-
amd64. Controls force-flush of L1D cache on NMI; this provides software - assist for bhyve mitigation of L1 terminal fault hardware information - leak.
-
hw.vmm.vmx.l1d_flush
-
amd64. Controls the mitigation of L1 Terminal Fault in bhyve - hypervisor.
-
vm.pmap.allow_2m_x_ept
-
amd64. Allows the use of superpages for executable mappings under the EPT - page table format used by hypervisors on Intel CPUs to map the guest - physical address space to machine physical memory. May be disabled to work - around a CPU Erratum called Machine Check Error Avoidance on Page Size - Change.
-
machdep.mitigations.rngds.enable
-
amd64 and i386. Controls mitigation of Special Register Buffer Data - Sampling versus optimization of the MCU access. When set to zero, the - mitigation is disabled, and the RDSEED and RDRAND instructions do not - incur serialization overhead for shared buffer accesses, and do not - serialize off-core memory accesses.
-
kern.elf32.aslr.enable
-
Controls system-global Address Space Layout Randomization (ASLR) for - normal non-PIE (Position Independent Executable) 32-bit ELF binaries. See - also the proccontrol(1) aslr - mode, also affected by the per-image control note flag.
-
kern.elf32.aslr.pie_enable
-
Controls system-global Address Space Layout Randomization for - position-independent (PIE) 32-bit binaries.
-
kern.elf32.aslr.honor_sbrk
-
Makes ASLR less aggressive and more compatible with old binaries relying - on the sbrk area.
-
kern.elf32.aslr.stack
-
Enable randomization of the stack for 32-bit binaries. Otherwise, the - stack is mapped at a fixed location determined by the process ABI.
-
kern.elf64.aslr.enable
-
ASLR control for 64-bit ELF binaries.
-
kern.elf64.aslr.pie_enable
-
ASLR control for 64-bit ELF PIEs.
-
kern.elf64.aslr.honor_sbrk
-
ASLR sbrk compatibility control for 64-bit binaries.
-
kern.elf64.aslr.stack
-
Controls stack address randomization for 64-bit binaries.
-
kern.elf32.nxstack
-
Enables non-executable stack for 32-bit processes. Enabled by default if - supported by hardware and corresponding binary.
-
kern.elf64.nxstack
-
Enables non-executable stack for 64-bit processes.
-
kern.elf32.allow_wx
-
Enables mapping of simultaneously writable and executable pages for 32-bit - processes.
-
kern.elf64.allow_wx
-
Enables mapping of simultaneously writable and executable pages for 64-bit - processes.
-
-
-
-

-

chflags(1), find(1), - md5(1), mdo(1), - netstat(1), openssl(1), - proccontrol(1), ps(1), - ssh(1), xdm(1) - (ports/x11/xorg-clients), - group(5), ttys(5), - mitigations(7), accton(8), - init(8), sshd(8), - sysctl(8), syslogd(8), - vipw(8)

-
-
-

-

The security manual page was originally - written by Matthew Dillon and first appeared in - FreeBSD 3.1, December 1998.

-
-
- - - - - -
March 22, 2026FreeBSD 15.0
diff --git a/static/freebsd/man7/simd.7 4.html b/static/freebsd/man7/simd.7 4.html deleted file mode 100644 index 7ef0f744..00000000 --- a/static/freebsd/man7/simd.7 4.html +++ /dev/null @@ -1,458 +0,0 @@ - - - - - - -
SIMD(7)Miscellaneous Information ManualSIMD(7)
-
-
-

-

simd — SIMD - enhancements

-
-
-

-

On some architectures, the FreeBSD - libc provides enhanced implementations of commonly used - functions, replacing the architecture-independent implementations used - otherwise. Depending on architecture and function, an enhanced - implementation of a function may either always be used or the - libc detects at runtime which SIMD instruction set - extensions are supported and picks the most suitable implementation - automatically. On amd64, the environment variable - ARCHLEVEL can be used to override this - mechanism.

-

Enhanced functions are present for the following - architectures:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
bcmpAS1S
bcopyASSSSVS
bzeroASSSS
divSS
indexAS1S
ldivSS
lldivS
memchrAS1S
memcmpASS1S
memccpyAS1
memcpyAMSSSSVS
memmoveAMSSSSV
memrchrAS1
memsetAMSSSS
rindexAS1SS
stpcpyAS1
stpncpyS1
strcatAS1S
strchrAS1SS
strchrnulAS1S
strcmpASS1S
strcpyAS1SS2
strcspnSS2
strlcatAS1
strlcpyAS1
strlenASS1S
strncatAS1
strncmpASS1S
strncpyS1S2
strnlenAS1S
strrchrAS1SS
strpbrkSS2
strsepSS2
strspnSS2
swabS
timingsafe_bcmpAS1
timingsafe_memcmpSS
wcschrS
wcscmpS
wcslenS
wmemchrS
-

: scalar - (non-SIMD), - : amd64 - baseline, - : x86-64-v2 - or PowerPC 2.05, - : x86-64-v3, - : x86-64-v4, - : PowerPC VSX, - : Arm ASIMD - (NEON), - : Arm MOPS.

-
-
-

-
-
-
On - , - controls the level of SIMD enhancements used. If this variable is set to - an architecture level from the list below and that architecture level is - supported by the processor, SIMD enhancements up to - ARCHLEVEL are used. If - ARCHLEVEL is unset, not recognised, or not - supported by the processor, the highest level of SIMD enhancements - supported by the processor is used. -

A suffix beginning with ‘:’ or ‘+’ - in ARCHLEVEL is ignored and may be used for - future extensions. The architecture level can be prefixed with a - ‘!’ character to force use of the requested architecture - level, even if the processor does not advertise that it is supported. - This usually causes applications to crash and should only be used for - testing purposes or if architecture level detection yields incorrect - results.

-

The architecture levels follow the AMD64 SysV ABI - supplement:

-
-
-
scalar enhancements only (no SIMD)
-
-
cmov, cx8, x87 FPU, fxsr, MMX, osfxsr, SSE, SSE2
-
-
cx16, lahf/sahf, popcnt, SSE3, SSSE3, SSE4.1, SSE4.2
-
-
AVX, AVX2, BMI1, BMI2, F16C, FMA, lzcnt, movbe, osxsave
-
-
AVX-512F/BW/CD/DQ/VL
-
-
-
-
-
-

-
-
Illegal Instruction
-
Printed by sh(1) if a command is terminated through - delivery of a SIGILL signal, see - signal(3). -

Use of an unsupported architecture level was forced by setting - ARCHLEVEL to a string beginning with a - ‘!’ character, causing a process to crash due to use of an - unsupported instruction. Unset ARCHLEVEL, remove - the ‘!’ prefix or select a supported architecture - level.

-

Message may also appear for unrelated reasons.

-
-
-
-
-

-

string(3), arch(7)

-

H. J. Lu, - Michael Matz, Milind - Girkar, Jan Hubička, - Andreas Jaeger, and Mark - Mitchell, AMD64 Architecture Processor - Supplement, System V Application Binary Interface, - May 23, 2023, Version - 1.0.

-
-
-

-

Architecture-specific enhanced libc functions - were added starting with FreeBSD 2.0 for - i386, FreeBSD 6.0 for - arm, FreeBSD 6.1 for - amd64, FreeBSD 11.0 for - aarch64, FreeBSD 12.0 for - powerpc64, and FreeBSD 16.0 - for riscv64. SIMD-enhanced functions were first - added with FreeBSD 13.0 for - powerpc64 and with FreeBSD - 14.1 for amd64.

-

A simd manual page appeared in - FreeBSD 14.1.

-
-
-

-

Robert Clausecker - <fuz@FreeBSD.org>

-
-
-

-

Other parts of FreeBSD such as - cryptographic routines in the kernel or in OpenSSL may also use SIMD - enhancements. These enhancements are not subject to the - ARCHLEVEL variable and may have their own - configuration mechanism.

-
-
-

-

Use of SIMD enhancements cannot be configured on powerpc64.

-
-
- - - - - -
October 21, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/sizeof.7 3.html b/static/freebsd/man7/sizeof.7 3.html deleted file mode 100644 index 5083f3cb..00000000 --- a/static/freebsd/man7/sizeof.7 3.html +++ /dev/null @@ -1,304 +0,0 @@ - - - - - - -
sizeof(7)Miscellaneous Information Manualsizeof(7)
-
-
-

-

sizeof operator — - yield the storage size of the given operand

-
-
-

-

sizeof (type) -
- sizeof expression

-
-
-

-

The sizeof operator yields the size of its - operand. The sizeof operator cannot be applied to - incomplete types and expressions with incomplete types (e.g. - void, or forward-defined struct foo - ), and function types.

-

The size of primitive (non-derived) data types in C may differ - across hardware platforms and implementations. They are defined by - corresponding Application Binary Interface (ABI) specifications, see - arch(7) for details about ABI used by - FreeBSD. It may be necessary or useful for a program - to be able to determine the storage size of a data type or object to account - for the platform specifics.

-

The unary sizeof operator yields - the storage size of an expression or data type in - (C - language bytes). As a result, - ‘sizeof(char)’ is always guaranteed to - be 1. (The number of bits per char is given by the - CHAR_BIT definition in the - <limits.h> header; many - systems also provide the "number of bits per byte" definition as - NBBY in the - <sys/param.h> header.)

-
-
-

-

Different platforms may use different data models. For example, - systems on which integers, longs, and pointers are using 32 bits (e.g., - i386) are referred to as using the "ILP32" data model, systems - using 64 bit longs and pointers (e.g., amd64 / x86_64) as the - "LP64" data model.

-

The following examples illustrate the possible results of calling - sizeof on an ILP32 vs. an LP64 system:

-

When applied to a simple variable or data type, - sizeof returns the storage size of the data type of - the object:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Result (ILP32)Result (LP64)
11
44
48
44
88
48
-

For initialized data or uninitialized arrays of a fixed size known - at compile time, sizeof will return the correct - storage size:

-
-
#define DATA "1234567890"
-char buf1[] = "abc";
-char buf2[1024];
-char buf3[1024] = { 'a', 'b', 'c' };
-
- - - - - - - - - - - - - - - - - - - - - -
11
4
1024
1024
-

The examples above are the same for ILP32 and LP64 platforms, as - they are based on character units.

-

When applied to a struct or union, sizeof - returns the total number of bytes in the object, including any internal or - trailing padding used to align the object in memory. This result may thus be - larger than if the storage size of each individual member had been - added:

-
-
struct s1 {
-        char c;
-};
-
-struct s2 {
-        char *s;
-        int i;
-};
-
-struct s3 {
-        char *s;
-        int i;
-        int j;
-};
-
-struct s4 {
-	int i;
-	uint64_t i64;
-};
-
-struct s5 {
-        struct s1 a;
-        struct s2 b;
-        struct s3 c;
-        struct s4 d;
-};
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Result (ILP32)Result (LP64)
11
816
1216
1216
3656
-

When applied to a struct containing a flexible array - member, sizeof returns the size of the struct - the - array, although again possibly including any padding the compiler deemed - appropriate:

-
-
struct flex {
-        char c;
-        long b;
-        char array[];
-}
-
- - - - - - - - - - - -
Result (ILP32)Result (LP64)
816
-

One of the more common uses of the sizeof - operator is to determine the correct amount of memory to allocate:

-
-
int *nums = calloc(512, sizeof(int));
-
-

The sizeof operator can be used to - calculate the number of elements in an array by dividing the size of the - array by the size of one of its elements:

-
-
int nums[] = { 1, 2, 3, 4, 5 };
-const int howmany = sizeof(nums) / sizeof(nums[0]);
-
-

Many systems provide this shortcut as the macro - ntimes() via the - <sys/param.h> header - file.

-
-
-

-

The result of the sizeof operator is an - unsigned integer type, defined in the stddef.h - header as a size_t.

-
-
-

-

It is a common mistake to apply sizeof to - a dynamically allocated array:

-
-
char *buf;
-if ((buf = malloc(BUFSIZ)) == NULL) {
-        perror("malloc");
-}
-/* Warning: wrong! */
-(void)strncat(buf, input, sizeof(buf) - 1);
-
-

In that case, the operator will return the storage size of the - pointer ( ‘sizeof(char *)’ ), not the - allocated memory.

-

sizeof determines the - size of the result of the expression given, but - evaluate - the expression:

-
-
int a = 42;
-printf("%ld - %d\n", sizeof(a = 10), a); /* Result: "4 - 42" */
-
-

Since it is evaluated by the compiler and not the preprocessor, - the sizeof operator cannot be used in a preprocessor - expression.

-
-
-

-

arch(7), operator(7)

-
-
-

-

The sizeof operator conforms to - ANSI X3.159-1989 - (“ANSI C89”).

-

Handling of flexible array members in structures conforms to - ISO/IEC 9899:1999 - (“ISO C99”).

-
-
-

-

This manual page was written by Jan - Schaumann - <jschauma@netmeister.org>.

-
-
- - - - - -
December 12, 2022FreeBSD 15.0
diff --git a/static/freebsd/man7/sprog.7 3.html b/static/freebsd/man7/sprog.7 3.html deleted file mode 100644 index a5e54763..00000000 --- a/static/freebsd/man7/sprog.7 3.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - -
SPROG(7)Miscellaneous Information ManualSPROG(7)
-
-
-

-

sprog — secure - programming practices

-
-
-

-

Security issues have crept into many systems over the years. This - document is a guide for programming practices that prevent these - problems.

-
-

-

Writing secure applications takes a very scrutinous and - pessimistic outlook. Applications should be run with the principle of - “least privilege” so that no process - is ever running with more than the bare minimum access it needs to - accomplish its function. Previously tested code should be reused whenever - possible. Generally, anything beyond the control of a program should never - be trusted. This includes all forms of user input, system resources, - interprocess communication, and the timing of events.

-
-
-

-

One of the most common types of security problems is the buffer - overflow. In short, if a program is not careful with the data it receives, - it may be possible for this data to be written across memory, overwriting - the return address for a function call, and the program will be forced to - run code that does unfriendly things.

-

A good number of functions in the standard C library make it - difficult or even impossible to prevent buffer overflows when used. These - include fscanf(3), gets(3), - getwd(3), realpath(3), - scanf(3), sprintf(3), - strcat(3), strcpy(3), - vscanf(3), and vsprintf(3).

-

Many other functions that deal with strings can also open up a - potential buffer overflow when not used carefully. For example, - strncat(3) does not go out of its way to provide NUL - character termination. Of course, the proper length must always be - specified. Usage of strlcat(3) and - strlcpy(3) ensure that strings are null terminated and of - the specified length.

-

Functions that receive a string format must also be used - carefully. It is possible for a string to contain additional format - specifiers, which open up another possibility for a buffer overflow. Never - pass a string with untrusted data without using - ‘%s’. Always use the proper secure - idiom:

-

-
function("%s", - string);
-

There are mechanisms that provide a backstop for these problems at - the library and compiler levels, however, there is no substitute for simply - writing good code.

-
-
-

-

In many cases, it may be necessary for a program to operate with - an increased set of permissions. Reasons for this include binding to - protected sockets, reading and writing certain files and directories, and - access to various resources. Using a setuid program is frequently the - solution. However, it is important that programs give up these privileges as - soon as possible. For example, if a program is binding to a protected - socket, it should give up its privileges as soon as it has finished binding - to that socket. This is accomplished with the setuid(2) - family of system calls.

-
-
-

-

The traditional method of restricting a process is with the - chroot(2) system call. This system call changes the root - directory from which all other paths are referenced for a process and any - child processes. Of course, the process must have access to this path to - begin with. The new environment does not actually take effect until - chdir(2) is called to place the process into the new - environment. Unfortunately, a process can break out of this environment if - root access is obtained.

-

Often, jail(2) can be used to create a more - complete and enclosed environment than chroot(2) can - provide. A jail limits all processes inside that environment, including - processes with superuser privileges.

-

Fine grained privileges, as described by POSIX.1e extensions, are - currently a work in progress, and the focus of the TrustedBSD Project. More - information can be found at - http://www.TrustedBSD.org/.

-
-
-

-

Programs should not make assumptions about the environment in - which they are running. This includes user input, signals, environment - variables, system resources, interprocess communications, and shared memory, - amongst other things that are beyond the control of the program. They should - not assume that all forms of invalid data can be detected either. Instead, - they should use positive filtering, and only allow a specific subset of - inputs that are known to be safe. This is the same logic that an - administrator should apply to a firewall, that is, deny by default and - specify what is to be accepted.

-
-
-

-

A race condition is anomalous behavior caused by the relative - timing of events. Programs should not assume that a particular event will - occur before another. The most common causes of race conditions are signals, - access checks, and file reads. Signals are asynchronous by nature, so - special care must be taken while dealing with them. Attempting to check - access with sequential non-atomic operations is a very bad idea, as files - can be moved and changed at any given time. Instead of using a sequence of - access(2) and open(2), use - seteuid(2) and then call open(2) - directly. Set umask(2) properly beforehand.

-
-
-
-

-

jail(2), setuid(2), - strlcat(3), strlcpy(3)

-
-
-

-

Eric Melville - <eric@FreeBSD.org> - originally wrote this document based on a chapter of the - FreeBSD Developer's Handbook written by - Murray Stokely - <murray@FreeBSD.org>.

-
-
- - - - - -
June 3, 2001FreeBSD 15.0
diff --git a/static/freebsd/man7/stats.7 4.html b/static/freebsd/man7/stats.7 4.html deleted file mode 100644 index 2c97e6ca..00000000 --- a/static/freebsd/man7/stats.7 4.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - -
STATS(7)Miscellaneous Information ManualSTATS(7)
-
-
-

-

stats — - information about various and sundry statistics - utilities

-
-
-

-

The FreeBSD userland in part contains a - series of utilities which can be used to ascertain system state at runtime - and optionally from core files.

-
-
-

-

The following commands (sorted alphabetically) are currently - included in the base system, with more appearing periodically.

-
-
btsockstat
-
Show Bluetooth socket information
-
ctlstat
-
CAM Target Layer statistics utility
-
dwatch
-
Watch processes as they trigger a particular DTrace probe
-
fstat
-
Identify active files
-
gstat
-
Print statistics about GEOM disks
-
ibstat
-
Display information from the InfiniBand driver
-
ifmcstat
-
Dump multicast group management statistics per interface
-
iostat
-
Report kernel subsystem I/O statistics
-
ipfstat
-
Display IPF packet filter statistics and filter list
-
kldstat
-
Display status of dynamic kernel linker
-
lockstat
-
Report kernel lock and profiling statistics
-
mailstats
-
Display mail statistics
-
netstat
-
Show network status and statistics
-
nfsstat
-
Display NFS statistics
-
plockstat
-
Trace pthread lock statistics using DTrace
-
pmcstat
-
Performance measurement with performance monitoring hardware
-
procstat
-
Get detailed process information
-
pstat
-
Display system data structures
-
sockstat
-
List open sockets
-
stat
-
Display file status
-
systat
-
Display system statistics
-
vmstat
-
Report virtual memory statistics
-
zpool iostat
-
Report ZFS I/O statistics
-
-
-
-

-

btsockstat(1), dwatch(1), - fstat(1), intro(1), - lockstat(1), netstat(1), - plockstat(1), procstat(1), - sockstat(1), stat(1), - systat(1), intro(7), - tuning(7), ctlstat(8), - gstat(8), ibstat(8), - ifmcstat(8), intro(8), - iostat(8), ipfstat(8), - kldstat(8), mailstats(8), - pmcstat(8), pstat(8), - vmstat(8), zpool(8)

-
-
-

-

The stats manual page first appeared in - FreeBSD 13.0.

-
-
-

-

Daniel Ebdrup Jensen - <debdrup@FreeBSD.org>

-
-
- - - - - -
October 28, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/stdint.7 3.html b/static/freebsd/man7/stdint.7 3.html deleted file mode 100644 index 50558660..00000000 --- a/static/freebsd/man7/stdint.7 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
STDINT(7)Miscellaneous Information ManualSTDINT(7)
-
-
-

-

stdint — standard - integer types

-
-
-

-

#include - <stdint.h>

-
-
-

-

The <stdint.h> - header provides source-portable integer types of a specific size, smallest - memory footprint with a minimum size, fastest access speed with a minimum - size, largest integer size, and those capable of storing pointers.

-

The types int8_t, - int16_t, int32_t, and - int64_t provide a signed integer type of width 8, 16, - 32, or 64 bits, respectively. The types uint8_t, - uint16_t, uint32_t, and - uint64_t provide an unsigned integer type of width 8, - 16, 32, or 64 bits, respectively. These integer types should be used when a - specific size is required.

-

The types int_fast8_t, - int_fast16_t, int_fast32_t, and - int_fast64_t provide the fastest signed integer type - with a width of at least 8, 16, 32, or 64 bits, respectively. The types - uint_fast8_t, uint_fast16_t, - uint_fast32_t, and uint_fast64_t - provide the fastest unsigned integer type with a width of at least 8, 16, - 32, or 64 bits, respectively. These types should be used when access speed - is paramount, and when a specific size is not required.

-

The types int_least8_t, - int_least16_t, int_least32_t, - and int_least64_t provide the smallest memory - footprint signed integer type with a width of at least 8, 16, 32, or 64 - bits, respectively. The types uint_least8_t, - uint_least16_t, uint_least32_t, - and uint_least64_t provide the smallest memory - footprint unsigned integer type with a width of at least 8, 16, 32, or 64 - bits, respectively. These types should be used when memory storage is of - concern, and when a specific size is not required.

-

The type intmax_t provides a signed integer - type large enough to hold any other signed integer. The type - uintmax_t provides an unsigned integer type large - enough to hold any other unsigned integer. These types are generally the - largest signed and unsigned integer types available on a specific - architecture.

-

The type intptr_t provides a signed integer - type with the ability to hold a pointer to void, that - can later be converted back to a pointer to void.

-

The type uintptr_t provides an unsigned - integer type with the ability to hold a pointer to - void, that can later be converted back to a pointer to - void.

-

Additionally, the - <stdint.h> header defines - some macros, but none of them are documented here.

-
-
-

-

The <stdint.h> - header conforms to ISO/IEC 9899:1999 - (“ISO C99”) and IEEE Std - 1003.1-2001 (“POSIX.1”).

-
-
-

-

The <stdint.h> - header was first introduced in FreeBSD 5.0.

-
-
- - - - - -
September 15, 2002FreeBSD 15.0
diff --git a/static/freebsd/man7/sticky.7 4.html b/static/freebsd/man7/sticky.7 4.html deleted file mode 100644 index 0768426d..00000000 --- a/static/freebsd/man7/sticky.7 4.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -
STICKY(7)Miscellaneous Information ManualSTICKY(7)
-
-
-

-

sticky — sticky - text and append-only directories

-
-
-

-

A special file mode, called the - (mode S_ISTXT), is used to indicate special treatment for - directories. It is ignored for regular files. See chmod(2) - or the file <sys/stat.h> for - an explanation of file modes.

-
-
-

-

A directory whose `sticky bit' is set becomes an append-only - directory, or, more accurately, a directory in which the deletion of files - is restricted. A file in a sticky directory may only be removed or renamed - by a user if the user has write permission for the directory and the user is - the owner of the file, the owner of the directory, or the super-user. This - feature is usefully applied to directories such as - /tmp which must be publicly writable but should deny - users the license to arbitrarily delete or rename each others' files.

-

Any user may create a sticky directory. See - chmod(1) for details about modifying file modes.

-
-
-

-

A sticky command appeared in - Version 7 AT&T UNIX/32V.

-
-
-

-

Neither open(2) nor mkdir(2) - will create a file with the sticky bit set.

-
-
- - - - - -
June 5, 1993FreeBSD 15.0
diff --git a/static/freebsd/man7/tests.7 3.html b/static/freebsd/man7/tests.7 3.html deleted file mode 100644 index cd0d4f0e..00000000 --- a/static/freebsd/man7/tests.7 3.html +++ /dev/null @@ -1,258 +0,0 @@ - - - - - - -
TESTS(7)Miscellaneous Information ManualTESTS(7)
-
-
-

-

tests — - introduction to the FreeBSD Test - Suite

-
-
-

-

The FreeBSD Test Suite provides a - collection of automated tests for two major purposes. On one hand, the test - suite aids - - to detect bugs and regressions when they modify the source tree. On the - other hand, it allows - - (and, in particular, system administrators) to verify that fresh - installations of the FreeBSD operating system behave - correctly on their hardware platform and also to ensure that the system does - not suffer from regressions during regular operation and maintenance.

-

The FreeBSD Test Suite can be found in the - /usr/tests hierarchy.

-

This manual page describes how to run the test suite and how to - configure some of its optional features. For information on writing the - tests, see atf(7).

-
-

-

If the /usr/tests directory is missing, - then you will have to enable the build of the test suite, rebuild your - system and install the results. You can do so by setting - ‘WITH_TESTS=yes’ in your /etc/src.conf - file (see src.conf(5) for details) and rebuilding the - system as described in build(7).

-
-
-

-

Before diving into the details of how to run the test suite, here - are some scenarios in which you should run it:

-
    -
  • After a fresh installation of FreeBSD to ensure - that the system works correctly on your hardware platform.
    • -
  • After an upgrade of FreeBSD to a different version - to ensure that the new code works well on your hardware platform and that - the upgrade did not introduce regressions in your configuration.
    • -
  • After modifying the source tree to detect any new bugs and/or - regressions.
    • -
  • Periodically, maybe from a cron(8) job, to ensure that - any changes to the system (such as the installation of third-party - packages or manual modifications to configuration files) do not introduce - unexpected failures.
    • -
-
-
-

-

By default, Kyua looks for tests in the current directory. To run - the whole test suite, either use the -k option to - specify the top-level Kyuafile:

-
-
$ kyua test -k /usr/tests/Kyuafile
-
-

or just change to the test suite root before running Kyua:

-
-
$ cd /usr/tests
-$ kyua test
-
-

The above will iterate through all test programs in - /usr/tests recursively, execute them, store their - results and debugging data in Kyua's database (by default in - ~/.kyua/store/), and print a summary of the results. - This summary includes a brief count of all total tests run and how many of - them failed.

-

It is possible to restrict which tests to run by providing their - names, or a portion of their path, on the command line. For example, this - would execute all of the tests provided for the cp(1) and - stat(1) utilities:

-
-
$ cd /usr/tests
-$ kyua test bin/cp usr.bin/stat
-
-

This would execute only one of the two test programs provided for - stat(1):

-
-
$ cd /usr/tests
-$ kyua test usr.bin/stat/stat_test
-
-

This would execute just a single test case:

-
-
$ cd /usr/tests
-$ kyua test usr.bin/stat/stat_test:t_flag
-
-

Finally, this would execute that test case in debug mode:

-
-
$ cd /usr/tests
-$ kyua debug -p usr.bin/stat/stat_test:t_flag
-
-

The -p option tells Kyua to pause before - cleanup so you can inspect the temporary directory to better understand why - the test failed.

-

Note that some tests may require root privileges to execute:

-
-
$ cd /usr/tests
-$ kyua debug usr.bin/stat/stat_test:h_flag
-usr.bin/stat/stat_test:h_flag  ->  skipped: Requires root privileges
-$ sudo kyua debug usr.bin/stat/stat_test:h_flag
-[...]
-usr.bin/stat/stat_test:h_flag  ->  passed
-
-

Conversely, some tests will only work correctly if run as an - unprivileged user. This will normally be noted in the test's metadata, - causing Kyua to automatically drop privileges before running the test.

-
-
-

-

Additional information about the test results can be retrieved by - using Kyua's various reporting commands. For example, the following would - print a plain-text report of the tests executed in the latest test run and - show which ones failed:

-
-
$ kyua report --verbose
-
-

To show the results of an arbitrary test run, use the - -r option to specify which results file to read:

-
-
$ kyua report --verbose \
-    -r ~/.kyua/store/results.usr_tests.20260417-173009-335060.db
-
-

Keep in mind that if the tests were run as root, the results will - have been stored in root's kyua directory, and the - easiest way to access them will be to run the report - command as root as well:

-
-
$ cd /usr/tests
-$ sudo kyua test usr.bin/stat
-$ sudo kyua report --verbose
-
-

This example would generate an HTML report ready to be published - on a web server:

-
-
$ kyua report-html --output ~/public_html/tests
-
-

For further details on the command-line interface of Kyua, please - refer to its manual page kyua(1).

-
-
-

-

Some test cases in the FreeBSD Test Suite - require manual configuration by the administrator before they can be run. - Unless certain properties are defined, the tests that require them will be - skipped.

-

Test suites are configured by defining their configuration - variables in /etc/kyua/kyua.conf. The format of this - file is detailed in kyua.conf(5).

-

The following configuration variables are available in the - FreeBSD Test Suite:

-
-
allow_devfs_side_effects
-
If defined, enables tests that may destroy and recreate semipermanent - device nodes, like disk devices. Without this variable, tests may still - create and destroy devices nodes that are normally transient, like - /dev/tap* and /dev/pts*, as long as they clean them up afterwards. - However, tests that require this variable have a relaxed cleanup - requirement; they must recreate any devices that they destroyed, but not - necessarily with the same devnames.
-
allow_sysctl_side_effects
-
Enables tests that change globally significant sysctl(8) - variables. The tests will undo any changes in their cleanup phases.
-
allow_network_access
-
Enables tests that need to access the network the test host is connected - to. Such tests may require properly configured Internet access.
-
disks
-
Must be set to a space delimited list of disk device nodes. Tests that - need destructive access to disks must use these devices. Tests are not - required to preserve any data present on these disks.
-
fibs
-
Must be set to a space delimited list of FIBs (routing tables). Tests that - need to modify a routing table may use any of these. Tests will cleanup - any new routes that they create.
-
-
-
-

-

If there is - - during the execution of the test suite, please consider reporting it to the - FreeBSD developers so that the failure can be - analyzed and fixed. To do so, either send a message to the appropriate - mailing list or file a problem report. For more details please refer to:

- -
-
-
-

-
-
/etc/kyua/kyua.conf
-
System-wide configuration file for kyua(1).
-
~/.kyua/kyua.conf
-
User-specific configuration file for kyua(1); overrides - the system file.
-
~/.kyua/logs/
-
Default location of Kyua debug logs (one .log file - per test run).
-
~/.kyua/store/
-
Default location of Kyua test results (one .db - file per test run).
-
/usr/tests/
-
Location of the FreeBSD Test Suite.
-
/usr/tests/Kyuafile
-
Top-level test suite definition file.
-
-
-
-

-

kyua(1), atf(7), - build(7), development(7)

-
-
-

-

The FreeBSD Test Suite first appeared in - FreeBSD 10.1 and was installed by default in - FreeBSD 11.0.

-

The tests manual page first appeared in - NetBSD 6.0 and was later ported to - FreeBSD 10.1.

-

The test driver, kyua(1), was imported as part - of the base system in FreeBSD 13.0, previously being - available only in ports(7).

-
-
-

-

Julio Merino - <jmmv@FreeBSD.org>

-
-
- - - - - -
April 17, 2026FreeBSD 15.0
diff --git a/static/freebsd/man7/tracing.7 3.html b/static/freebsd/man7/tracing.7 3.html deleted file mode 100644 index 9c09f1d3..00000000 --- a/static/freebsd/man7/tracing.7 3.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -
TRACING(7)Miscellaneous Information ManualTRACING(7)
-
-
-

-

tracing — - introduction to FreeBSD tracing and performance - monitoring

-
-
-

-

FreeBSD features a large variety of - tracing and performance monitoring facilities. Use them to measure - performance and troubleshoot kernel and userland problems both during - development(7) and potentially on production systems. The - facilities differ in scope, ease of use, overhead, design, and - limitations.

-
-

-

dtrace(1) is the most versatile tracing - framework available on FreeBSD and is capable of - tracing throughout the FreeBSD software stack from - the kernel to the applications running in userland. Refer to - dtrace(1) and SDT(9) for more - details.

-

dwatch(1) is a user-friendly wrapper for DTrace. - It simplifies common DTrace usage patterns and requires less expert - knowledge to operate.

-
-
-

-

truss(1) traces system calls. It uses - sysdecode(3) to pretty-print system call arguments and - ptrace(2) to trace processes.

-

ktrace(1) is useful for debugging user programs. - It enables kernel trace logging for specified processes. Like - truss(1), it mainly traces system calls, but instead of - using ptrace(2), it asynchronously logs entries to a trace - file configured with ktrace(2) (typically - ktrace.out), and it can log other types of kernel - events, such as page faults and name lookups (refer to - -t in ktrace(1)). Also, programs - can log to a ktrace(1) stream using the - utrace(2) system call.

-
-
-

-

ktr(4) is a facility for logging strings in the - kernel. It comes in handy for some niche purposes during kernel development. - It lets kernel programmers log events to a global ring buffer, which can - later be dumped using ktrdump(8).

-
-
-

-

hwt(4) is a kernel trace framework providing - infrastructure for hardware-assisted tracing.

-
-
-

-

pmcstat(8), and its kernel counterpart, - hwpmc(4), is the FreeBSD facility - for conducting performance measurements with hardware counters.

-
-
-

-

boottrace(4) is a facility for tracing events at - boot and shutdown. Its target audience are system administrators.

-

tslog(4) is a developer-oriented tool for - tracing boot-time events.

-
-
-
-

-

The tracing manual page was written by - Mateusz Piotrowski - <0mp@FreeBSD.org>. It - first appeared in FreeBSD 15.0.

-
-
- - - - - -
July 12, 2025FreeBSD 15.0
diff --git a/static/freebsd/man7/tuning.7 3.html b/static/freebsd/man7/tuning.7 3.html deleted file mode 100644 index 317a2e0d..00000000 --- a/static/freebsd/man7/tuning.7 3.html +++ /dev/null @@ -1,478 +0,0 @@ - - - - - - -
TUNING(7)Miscellaneous Information ManualTUNING(7)
-
-
-

-

tuning — - performance tuning under FreeBSD

-
-
-

-

The swap partition should typically be approximately 2x the size - of main memory for systems with less than 4GB of RAM, or approximately equal - to the size of main memory if you have more. Keep in mind future memory - expansion when sizing the swap partition. Configuring too little swap can - lead to inefficiencies in the VM page scanning code as well as create issues - later on if you add more memory to your machine. On larger systems with - multiple disks, configure swap on each drive. The swap partitions on the - drives should be approximately the same size. The kernel can handle - arbitrary sizes but internal data structures scale to 4 times the largest - swap partition. Keeping the swap partitions near the same size will allow - the kernel to optimally stripe swap space across the N disks. Do not worry - about overdoing it a little, swap space is the saving grace of - UNIX and even if you do not normally use much swap, - it can give you more time to recover from a runaway program before being - forced to reboot.

-

It is not a good idea to make one large partition. First, each - partition has different operational characteristics and separating them - allows the file system to tune itself to those characteristics. For example, - the root and /usr partitions are read-mostly, with - very little writing, while a lot of reading and writing could occur in - /var/tmp. By properly partitioning your system - fragmentation introduced in the smaller more heavily write-loaded partitions - will not bleed over into the mostly-read partitions.

-

Properly partitioning your system also allows you - to tune newfs(8), and tunefs(8) - parameters. The only tunefs(8) option worthwhile turning - on is - - with “tunefs -n enable /filesystem”. - Softupdates drastically improves meta-data performance, mainly file creation - and deletion. We recommend enabling softupdates on most file systems; - however, there are two limitations to softupdates that you should be aware - of when determining whether to use it on a file system. First, softupdates - guarantees file system consistency in the case of a crash but could very - easily be several seconds (even a minute!) behind on pending write to the - physical disk. If you crash you may lose more work than otherwise. Secondly, - softupdates delays the freeing of file system blocks. If you have a file - system (such as the root file system) which is close to full, doing a major - update of it, e.g., “make - installworld”, can run it out of space and cause the update to - fail. For this reason, softupdates will not be enabled on the root file - system during a typical install. There is no loss of performance since the - root file system is rarely written to.

-

A number of run-time mount(8) options exist that - can help you tune the system. The most obvious and most dangerous one is - async. Only use this option in conjunction with - gjournal(8), as it is far too dangerous on a normal file - system. A less dangerous and more useful mount(8) option - is called noatime. UNIX file - systems normally update the last-accessed time of a file or directory - whenever it is accessed. This operation is handled in - FreeBSD with a delayed write and normally does not - create a burden on the system. However, if your system is accessing a huge - number of files on a continuing basis the buffer cache can wind up getting - polluted with atime updates, creating a burden on the system. For example, - if you are running a heavily loaded web site, or a news server with lots of - readers, you might want to consider turning off atime updates on your larger - partitions with this mount(8) option. However, you should - not gratuitously turn off atime updates everywhere. For example, the - /var file system customarily holds mailboxes, and - atime (in combination with mtime) is used to determine whether a mailbox has - new mail. You might as well leave atime turned on for mostly read-only - partitions such as / and - /usr as well. This is especially useful for - / since some system utilities use the atime field - for reporting.

-
-
-

-

In larger systems you can stripe partitions from several drives - together to create a much larger overall partition. Striping can also - improve the performance of a file system by splitting I/O operations across - two or more disks. The gstripe(8) and - ccdconfig(8) utilities may be used to create simple - striped file systems. Generally speaking, striping smaller partitions such - as the root and /var/tmp, or essentially read-only - partitions such as /usr is a complete waste of time. - You should only stripe partitions that require serious I/O performance, - typically /var, /home, or - custom partitions used to hold databases and web pages. Choosing the proper - stripe size is also important. File systems tend to store meta-data on - power-of-2 boundaries and you usually want to reduce seeking rather than - increase seeking. This means you want to use a large off-center stripe size - such as 1152 sectors so sequential I/O does not seek both disks and so - meta-data is distributed across both disks rather than concentrated on a - single disk.

-
-
-

-

sysctl(8) variables permit system behavior to be - monitored and controlled at run-time. Some sysctls simply report on the - behavior of the system; others allow the system behavior to be modified; - some may be set at boot time using rc.conf(5), but most - will be set via sysctl.conf(5). There are several hundred - sysctls in the system, including many that appear to be candidates for - tuning but actually are not. In this document we will only cover the ones - that have the greatest effect on the system.

-

The vm.overcommit sysctl defines the - overcommit behaviour of the vm subsystem. The virtual memory system always - does accounting of the swap space reservation, both total for system and - per-user. Corresponding values are available through sysctl - vm.swap_total, that gives the total bytes available - for swapping, and vm.swap_reserved, that gives number - of bytes that may be needed to back all currently allocated anonymous - memory.

-

Setting bit 0 of the vm.overcommit sysctl - causes the virtual memory system to return failure to the process when - allocation of memory causes vm.swap_reserved to exceed - vm.swap_total. Bit 1 of the sysctl enforces - RLIMIT_SWAP limit (see - getrlimit(2)). Root is exempt from this limit. Bit 2 - allows to count most of the physical memory as allocatable, except wired and - free reserved pages (accounted by - vm.stats.vm.v_free_target and - vm.stats.vm.v_wire_count sysctls, respectively).

-

Due to the architecture of the FreeBSD - virtual memory subsystem, the use of copy on write (CoW) anonymous memory, - e.g. on fork(2), causes swap reservation for all three - regions (VM objects): in the original pre-fork mapping, and its copies in - the parent and child, instead of only two. Eventually the subsystem tries to - optimize the internal layout of the tracking for CoW and often removes - (collapses) no longer needed backing objects, re-assigning its pages and - swap reservations to the copies. Collapsing frees the swap reserve, but it - is not guaranteed to happen.

-

The kern.ipc.maxpipekva loader tunable is - used to set a hard limit on the amount of kernel address space allocated to - mapping of pipe buffers. Use of the mapping allows the kernel to eliminate a - copy of the data from writer address space into the kernel, directly copying - the content of mapped buffer to the reader. Increasing this value to a - higher setting, such as `25165824' might improve performance on systems - where space for mapping pipe buffers is quickly exhausted. This exhaustion - is not fatal; however, and it will only cause pipes to fall back to using - double-copy.

-

The kern.ipc.shm_use_phys sysctl defaults to - 0 (off) and may be set to 0 (off) or 1 (on). Setting this parameter to 1 - will cause all System V shared memory segments to be mapped to unpageable - physical RAM. This feature only has an effect if you are either (A) mapping - small amounts of shared memory across many (hundreds) of processes, or (B) - mapping large amounts of shared memory across any number of processes. This - feature allows the kernel to remove a great deal of internal memory - management page-tracking overhead at the cost of wiring the shared memory - into core, making it unswappable.

-

The vfs.vmiodirenable sysctl defaults to 1 - (on). This parameter controls how directories are cached by the system. Most - directories are small and use but a single fragment (typically 2K) in the - file system and even less (typically 512 bytes) in the buffer cache. - However, when operating in the default mode the buffer cache will only cache - a fixed number of directories even if you have a huge amount of memory. - Turning on this sysctl allows the buffer cache to use the VM Page Cache to - cache the directories. The advantage is that all of memory is now available - for caching directories. The disadvantage is that the minimum in-core memory - used to cache a directory is the physical page size (typically 4K) rather - than 512 bytes. We recommend turning this option off in memory-constrained - environments; however, when on, it will substantially improve the - performance of services that manipulate a large number of files. Such - services can include web caches, large mail systems, and news systems. - Turning on this option will generally not reduce performance even with the - wasted memory but you should experiment to find out.

-

The vfs.write_behind sysctl defaults to 1 - (on). This tells the file system to issue media writes as full clusters are - collected, which typically occurs when writing large sequential files. The - idea is to avoid saturating the buffer cache with dirty buffers when it - would not benefit I/O performance. However, this may stall processes and - under certain circumstances you may wish to turn it off.

-

The vfs.hirunningspace sysctl determines how - much outstanding write I/O may be queued to disk controllers system-wide at - any given time. It is used by the UFS file system. The default is self-tuned - and usually sufficient but on machines with advanced controllers and lots of - disks this may be tuned up to match what the controllers buffer. Configuring - this setting to match tagged queuing capabilities of controllers or drives - with average IO size used in production works best (for example: 16 MiB will - use 128 tags with IO requests of 128 KiB). Note that setting too high a - value (exceeding the buffer cache's write threshold) can lead to extremely - bad clustering performance. Do not set this value arbitrarily high! Higher - write queuing values may also add latency to reads occurring at the same - time.

-

The vfs.read_max sysctl governs VFS - read-ahead and is expressed as the number of blocks to pre-read if the - heuristics algorithm decides that the reads are issued sequentially. It is - used by the UFS, ext2fs and msdosfs file systems. With the default UFS block - size of 32 KiB, a setting of 64 will allow speculatively reading up to 2 - MiB. This setting may be increased to get around disk I/O latencies, - especially where these latencies are large such as in virtual machine - emulated environments. It may be tuned down in specific cases where the I/O - load is such that read-ahead adversely affects performance or where system - memory is really low.

-

The vfs.ncsizefactor sysctl defines how - large VFS namecache may grow. The number of currently allocated entries in - namecache is provided by debug.numcache sysctl and the - condition debug.numcache < kern.maxvnodes * vfs.ncsizefactor is adhered - to.

-

The vfs.ncnegfactor sysctl defines how many - negative entries VFS namecache is allowed to create. The number of currently - allocated negative entries is provided by debug.numneg - sysctl and the condition vfs.ncnegfactor * debug.numneg < debug.numcache - is adhered to.

-

There are various other buffer-cache and VM page cache related - sysctls. We do not recommend modifying these values.

-

The net.inet.tcp.sendspace and - net.inet.tcp.recvspace sysctls are of particular - interest if you are running network intensive applications. They control the - amount of send and receive buffer space allowed for any given TCP - connection. The default sending buffer is 32K; the default receiving buffer - is 64K. You can often improve bandwidth utilization by increasing the - default at the cost of eating up more kernel memory for each connection. We - do not recommend increasing the defaults if you are serving hundreds or - thousands of simultaneous connections because it is possible to quickly run - the system out of memory due to stalled connections building up. But if you - need high bandwidth over a fewer number of connections, especially if you - have gigabit Ethernet, increasing these defaults can make a huge difference. - You can adjust the buffer size for incoming and outgoing data separately. - For example, if your machine is primarily doing web serving you may want to - decrease the recvspace in order to be able to increase the sendspace without - eating too much kernel memory. Note that the routing table (see - route(8)) can be used to introduce route-specific send and - receive buffer size defaults.

-

As an additional management tool you can use pipes in your - firewall rules (see ipfw(8)) to limit the bandwidth going - to or from particular IP blocks or ports. For example, if you have a T1 you - might want to limit your web traffic to 70% of the T1's bandwidth in order - to leave the remainder available for mail and interactive use. Normally a - heavily loaded web server will not introduce significant latencies into - other services even if the network link is maxed out, but enforcing a limit - can smooth things out and lead to longer term stability. Many people also - enforce artificial bandwidth limitations in order to ensure that they are - not charged for using too much bandwidth.

-

Setting the send or receive TCP buffer to values larger than 65535 - will result in a marginal performance improvement unless both hosts support - the window scaling extension of the TCP protocol, which is controlled by the - net.inet.tcp.rfc1323 sysctl. These extensions should - be enabled and the TCP buffer size should be set to a value larger than - 65536 in order to obtain good performance from certain types of network - links; specifically, gigabit WAN links and high-latency satellite links. - RFC1323 support is enabled by default.

-

The net.inet.tcp.always_keepalive sysctl - determines whether or not the TCP implementation should attempt to detect - dead TCP connections by intermittently delivering “keepalives” - on the connection. By default, this is enabled for all applications; by - setting this sysctl to 0, only applications that specifically request - keepalives will use them. In most environments, TCP keepalives will improve - the management of system state by expiring dead TCP connections, - particularly for systems serving dialup users who may not always terminate - individual TCP connections before disconnecting from the network. However, - in some environments, temporary network outages may be incorrectly - identified as dead sessions, resulting in unexpectedly terminated TCP - connections. In such environments, setting the sysctl to 0 may reduce the - occurrence of TCP session disconnections.

-

The net.inet.tcp.delayed_ack TCP feature is - largely misunderstood. Historically speaking, this feature was designed to - allow the acknowledgement to transmitted data to be returned along with the - response. For example, when you type over a remote shell, the - acknowledgement to the character you send can be returned along with the - data representing the echo of the character. With delayed acks turned off, - the acknowledgement may be sent in its own packet, before the remote service - has a chance to echo the data it just received. This same concept also - applies to any interactive protocol (e.g., SMTP, WWW, POP3), and can cut the - number of tiny packets flowing across the network in half. The - FreeBSD delayed ACK implementation also follows the - TCP protocol rule that at least every other packet be acknowledged even if - the standard 40ms timeout has not yet passed. Normally the worst a delayed - ACK can do is slightly delay the teardown of a connection, or slightly delay - the ramp-up of a slow-start TCP connection. While we are not sure we believe - that the several FAQs related to packages such as SAMBA and SQUID which - advise turning off delayed acks may be referring to the slow-start - issue.

-

The net.inet.ip.portrange.* sysctls control - the port number ranges automatically bound to TCP and UDP sockets. There are - three ranges: a low range, a default range, and a high range, selectable via - the IP_PORTRANGE setsockopt(2) - call. Most network programs use the default range which is controlled by - net.inet.ip.portrange.first and - net.inet.ip.portrange.last, which default to 49152 and - 65535, respectively. Bound port ranges are used for outgoing connections, - and it is possible to run the system out of ports under certain - circumstances. This most commonly occurs when you are running a heavily - loaded web proxy. The port range is not an issue when running a server which - handles mainly incoming connections, such as a normal web server, or has a - limited number of outgoing connections, such as a mail relay. For situations - where you may run out of ports, we recommend decreasing - net.inet.ip.portrange.first modestly. A range of 10000 - to 30000 ports may be reasonable. You should also consider firewall effects - when changing the port range. Some firewalls may block large ranges of ports - (usually low-numbered ports) and expect systems to use higher ranges of - ports for outgoing connections. By default - net.inet.ip.portrange.last is set at the maximum - allowable port number.

-

The kern.ipc.soacceptqueue sysctl limits the - size of the listen queue for accepting new TCP connections. The default - value of 128 is typically too low for robust handling of new connections in - a heavily loaded web server environment. For such environments, we recommend - increasing this value to 1024 or higher. The service daemon may itself limit - the listen queue size (e.g., sendmail(8), apache) but will - often have a directive in its configuration file to adjust the queue size - up. Larger listen queues also do a better job of fending off denial of - service attacks.

-

The kern.maxfiles sysctl determines how many - open files the system supports. The default is typically a few thousand but - you may need to bump this up to ten or twenty thousand if you are running - databases or large descriptor-heavy daemons. The read-only - kern.openfiles sysctl may be interrogated to determine - the current number of open files on the system.

-
-
-

-

Some aspects of the system behavior may not be tunable at runtime - because memory allocations they perform must occur early in the boot - process. To change loader tunables, you must set their values in - loader.conf(5) and reboot the system.

-

kern.maxusers controls the scaling of a - number of static system tables, including defaults for the maximum number of - open files, sizing of network memory resources, etc. - kern.maxusers is automatically sized at boot based on - the amount of memory available in the system, and may be determined at - run-time by inspecting the value of the read-only - kern.maxusers sysctl.

-

The kern.dfldsiz and - kern.dflssiz tunables set the default soft limits for - process data and stack size respectively. Processes may increase these up to - the hard limits by calling setrlimit(2). The - kern.maxdsiz, kern.maxssiz, and - kern.maxtsiz tunables set the hard limits for process - data, stack, and text size respectively; processes may not exceed these - limits. The kern.sgrowsiz tunable controls how much - the stack segment will grow when a process needs to allocate more stack.

-

kern.ipc.nmbclusters may be adjusted to - increase the number of network mbufs the system is willing to allocate. Each - cluster represents approximately 2K of memory, so a value of 1024 represents - 2M of kernel memory reserved for network buffers. You can do a simple - calculation to figure out how many you need. If you have a web server which - maxes out at 1000 simultaneous connections, and each connection eats a 16K - receive and 16K send buffer, you need approximately 32MB worth of network - buffers to deal with it. A good rule of thumb is to multiply by 2, so 32MBx2 - = 64MB/2K = 32768. So for this case you would want to set - kern.ipc.nmbclusters to 32768. We recommend values - between 1024 and 4096 for machines with moderates amount of memory, and - between 4096 and 32768 for machines with greater amounts of memory. Under no - circumstances should you specify an arbitrarily high value for this - parameter, it could lead to a boot-time crash. The - -m option to netstat(1) may be - used to observe network cluster use.

-

More and more programs are using the sendfile(2) - system call to transmit files over the network. The - kern.ipc.nsfbufs sysctl controls the number of file - system buffers sendfile(2) is allowed to use to perform - its work. This parameter nominally scales with - kern.maxusers so you should not need to modify this - parameter except under extreme circumstances. See the - TUNING section in the - sendfile(2) manual page for details.

-
-
-

-

FreeBSD allows having more than one - scheduler specified in the kernel config, and the desired scheduler selected - from them at boot time. Right now the options are:

-
-
SCHED_ULE
-
The modern scheduler with O(1) thread selection behavior.
-
SCHED_4BSD
-
Classic scheduler inherited from 4.x BSD.
-
-

At least one option must be specified. - SCHED_ULE is used by default if compiled in.

-

The kern.sched.available sysctl provides the - comma-separated list of available (compiled in) schedulers. The - kern.sched.name loader tunable can be set to select - the desired scheduler at boot time. The - kern.sched.name sysctl reports which scheduler is - used.

-
-
-

-

There are a number of kernel options that you may have to fiddle - with in a large-scale system. In order to change these options you need to - be able to compile a new kernel from source. The config(8) - manual page and the handbook are good starting points for learning how to do - this. Generally the first thing you do when creating your own custom kernel - is to strip out all the drivers and services you do not use. Removing things - like INET6 and drivers you do not have will reduce - the size of your kernel, sometimes by a megabyte or more, leaving more - memory available for applications.

-

SCSI_DELAY may be used to reduce system - boot times. The defaults are fairly high and can be responsible for 5+ - seconds of delay in the boot process. Reducing - SCSI_DELAY to something below 5 seconds could work - (especially with modern drives).

-

There are a number of *_CPU options that - can be commented out. If you only want the kernel to run on a Pentium class - CPU, you can easily remove I486_CPU, but only remove - I586_CPU if you are sure your CPU is being - recognized as a Pentium II or better. Some clones may be recognized as a - Pentium or even a 486 and not be able to boot without those options. If it - works, great! The operating system will be able to better use higher-end CPU - features for MMU, task switching, timebase, and even device operations. - Additionally, higher-end CPUs support 4MB MMU pages, which the kernel uses - to map the kernel itself into memory, increasing its efficiency under heavy - syscall loads.

-
-
-

-

The type of tuning you do depends heavily on where your system - begins to bottleneck as load increases. If your system runs out of CPU (idle - times are perpetually 0%) then you need to consider upgrading the CPU or - perhaps you need to revisit the programs that are causing the load and try - to optimize them. If your system is paging to swap a lot you need to - consider adding more memory. If your system is saturating the disk you - typically see high CPU idle times and total disk saturation. - systat(1) can be used to monitor this. There are many - solutions to saturated disks: increasing memory for caching, mirroring - disks, distributing operations across several machines, and so forth.

-

Finally, you might run out of network resources. Optimize the - network path as much as possible. For example, in - firewall(7) we describe a firewall protecting internal - hosts with a topology where the externally visible hosts are not routed - through it. Most bottlenecks occur at the WAN link. If expanding the link is - not an option it may be possible to use the dummynet(4) - feature to implement peak shaving or other forms of traffic shaping to - prevent the overloaded service (such as web services) from affecting other - services (such as email), or vice versa. In home installations this could be - used to give interactive traffic (your browser, ssh(1) - logins) priority over services you export from your box (web services, - email).

-
-
-

-

netstat(1), systat(1), - sendfile(2), ata(4), - dummynet(4), eventtimers(4), - ffs(4), login.conf(5), - rc.conf(5), sysctl.conf(5), - firewall(7), hier(7), - ports(7), stats(7), - boot(8), bsdinstall(8), - ccdconfig(8), config(8), - fsck(8), gjournal(8), - gpart(8), gstripe(8), - ifconfig(8), ipfw(8), - loader(8), mount(8), - newfs(8), route(8), - sysctl(8), tunefs(8)

-
-
-

-

The tuning manual page was originally - written by Matthew Dillon and first appeared in - FreeBSD 4.3, May 2001. The manual page was greatly - modified by Eitan Adler - <eadler@FreeBSD.org>.

-
-
- - - - - -
April 9, 2026FreeBSD 15.0
diff --git a/static/freebsd/man8/beinstall.8 3.html b/static/freebsd/man8/beinstall.8 3.html deleted file mode 100644 index 701bc380..00000000 --- a/static/freebsd/man8/beinstall.8 3.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - -
BEINSTALL.SH(8)System Manager's ManualBEINSTALL.SH(8)
-
-
-

-

beinstall.sh — - install a boot environment using the current FreeBSD source - tree

-
-
-

- - - - - -
beinstall.sh[options ...]
-
-
-

-

beinstall.sh installs a boot environment - using the current FreeBSD source tree. - beinstall.sh also automatically performs - /etc updates (using etcupdate(8)) - and package updates using pkg-upgrade(8) automatically in - the new boot environment sandbox.

-

Upon successful completion, the system will be ready to boot into - the new boot environment. Upon failure, the target boot environment will be - destroyed. In all cases, the running system is left untouched and a reboot - into a partially updated system (due to install or hardware failure) cannot - happen. Additionally, the full installation process requires only one reboot - as it is performed in a new boot environment.

-

beinstall.sh requires a fully built world - and kernel. It also requires pkg(8), which is not present - in the base system and has to be installed manually.

-

The options provided to - beinstall.sh are world and kernel flags like - KERNCONF as described in - build(7).

-
-
-

-

User modifiable variables. Set these in the environment if - desired:

-
-
- (default: “bectl”)
-
Utility to manage ZFS boot environments. This can be either - bectl(8) from the base system or - beadm(1) from ports (sysutils/beadm).
-
- (default: “etcupdate”)
-
Config updater: etcupdate(8) is supported. Set to an - empty string to skip.
-
- (default: “-F”)
-
Flags for etcupdate(8) if used.
-
- (default: “”)
-
If not empty, “pkg upgrade” will be - skipped.
-
-
-
-

-
-
tools/build/beinstall.sh
-
Place where beinstall.sh lives in the src - tree.
-
-
-
-

-

build(7), development(7), - bectl(8), etcupdate(8), - pkg(8)

-
-
-

-

beinstall.sh is inspired by and similar in - function to Solaris/illumos-style upgrades.

-

The beinstall.sh manual page first - appeared in FreeBSD 12.0.

-
-
-

-

The beinstall.sh script was implemented by - Will Andrews - <will@FreeBSD.org>. - This manual page was written by -
- Mateusz Piotrowski - <0mp@FreeBSD.org>.

-
-
- - - - - -
October 30, 2020FreeBSD 15.0
diff --git a/static/freebsd/man8/crash.8 3.html b/static/freebsd/man8/crash.8 3.html deleted file mode 100644 index c1e0a796..00000000 --- a/static/freebsd/man8/crash.8 3.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - -
CRASH(8)System Manager's ManualCRASH(8)
-
-
-

-

crash — FreeBSD - system failures

-
-
-

-

This section explains a bit about system crashes and (very - briefly) how to analyze crash dumps.

-

When the system crashes voluntarily it prints a message of the - form

-
-
panic: why i gave up the ghost
-
-
-

on the console, and if dumps have been enabled (see - dumpon(8)), takes a dump on a mass storage peripheral, and - then invokes an automatic reboot procedure as described in - reboot(8). Unless some unexpected inconsistency is - encountered in the state of the file systems due to hardware or software - failure, the system will then resume multi-user operations.

-

The system has a large number of internal consistency checks; if - one of these fails, then it will panic with a very short message indicating - which one failed. In many instances, this will be the name of the routine - which detected the error, or a two-word description of the inconsistency. A - full understanding of most panic messages requires perusal of the source - code for the system.

-

The most common cause of system failures is hardware failure, - which can reflect itself in different ways. Here are the messages which are - most likely, with some hints as to causes. Left unstated in all cases is the - possibility that hardware or software error produced the message in some - unexpected way.

-

-
-
Mounting from <device> failed with error <err>
-
The system was unable to mount the configured root filesystem. Either the - root filesystem has been corrupted, or the system is attempting to use the - wrong device as root filesystem. -

This is not a panic message; rather it is - followed by an interactive - - prompt where the operator can list detected devices and filesystems, and - select an alternative root filesystem to mount. Alternatively, the - system can be booted from recovery media to repair the situation. The - system install media provides a live environment which is suitable for - this task.

-

-
-
init: not found
-
This is not a panic message, as reboots are likely to be futile. Late in - the bootstrap procedure, the system was unable to locate and execute the - initialization process, init(8). The root file system is - incorrect or has been corrupted, or the mode or type of - /sbin/init forbids execution or is totally - missing. -

-
-
ffs_realloccg: bad optim
-
-
ffs_valloc: dup alloc
-
-
ffs_alloccgblk: cyl groups corrupted
-
-
ffs_alloccg: map corrupted
-
-
blkfree: freeing free block
-
-
blkfree: freeing free frag
-
-
ifree: freeing free inode
-
These panic messages are among those that may be produced when file system - inconsistencies are detected. The problem generally results from a failure - to repair damaged file systems after a crash, hardware failures, or other - condition that should not normally occur. A file system check will - normally correct the problem. -

-
-
init died (signal #, exit #)
-
The system initialization process has exited with the specified signal - number and exit code. This is bad news, as no new users will then be able - to log in. Rebooting is the only fix, so the system just does it right - away.
-
-

That completes the list of panic types you are likely to see.

-

If the system has been configured to take crash dumps (see - dumpon(8)), then when it crashes it will write (or at - least attempt to write) an image of memory into the back end of the dump - device, usually the same as the primary swap area. After the system is - rebooted, the program savecore(8) runs and preserves a - copy of this core image and the current system in a specified directory for - later perusal. See savecore(8) for details.

-

To analyze a dump you should begin by running - kgdb(1) (ports/devel/gdb) on the - system load image and core dump. If the core image is the result of a panic, - the panic message is printed. For more details consult the chapter on kernel - debugging in the FreeBSD Developers' Handbook - (https://www.freebsd.org/doc/en/books/developers-handbook/).

-
-
-

-

kgdb(1) - (ports/devel/gdb), dumpon(8), - reboot(8), savecore(8)

-
-
-

-

The crash manual page first appeared in - FreeBSD 2.2.

-
-
- - - - - -
July 25, 2025FreeBSD 15.0
diff --git a/static/freebsd/man8/debug.sh.8 3.html b/static/freebsd/man8/debug.sh.8 3.html deleted file mode 100644 index e4157c18..00000000 --- a/static/freebsd/man8/debug.sh.8 3.html +++ /dev/null @@ -1,150 +0,0 @@ - - - - - - -
DEBUG.SH(8)System Manager's ManualDEBUG.SH(8)
-
-
-

-

debug.sh — - selectively debug scripts

-
-
-

- -
-
-

-

debug.sh provides the following functions - to facilitate flexible run-time tracing of complicated shell scripts.

-
-
- [-eo] tag ...
-
turns tracing on if any tag is found in - DEBUG_SH (a comma separated list of tags). -

It turns tracing off if !tag is found in - DEBUG_SH.

-

It sets DEBUG_ON to the - tag that caused tracing to be enabled, or - DEBUG_OFF if we matched - !tag.

-

If -e option is present, returns 1 if - no tag matched.

-

If -o option is present, tracing is - turned off unless there was a matched tag, useful - for functions too noisy to tace.

-
-
- [-eo] - [rc=rc] tag - ...
-
turns tracing on if any tag matches - DEBUG_OFF or off if any tag - matches DEBUG_ON. This allows nested functions to - not interfere with each other. -

The flags -e and - -o are ignored, they just allow for symmetry - with calls to - ().

-

The optional rc value - will be returned rather than the default of 0. Thus if - () - is the last operation in a function, rc will be - the return code of the function.

-
-
-
returns true if tracing is enabled. It is useful for bounding complex - debug actions, rather than using lots of $DEBUG_DO - lines.
-
- tag
-
Add tag to DEBUG_SH to - influence later output, possibly in a child process.
-
-
is just shorthand for: -
- 
$DEBUG_DO echo "$@"
-
-
-
- [message]
-
If debugging is enabled, output message prefixed - with a time-stamp.
-
- tag ...
-
runs an interactive shell if any tag is found in - DEBUG_INTERACTIVE, and there is a tty available. The - shell used is defined by DEBUG_SHELL or - SHELL and defaults to - /bin/sh.
-
- message
-
Debug output can be very noisy, and it can be tricky to align with the - script. This function outputs a very noticeable banner indicating the - value of DEBUG_ON, and message - is passed to DebugLog(), finally the banner is - repeated.
-
- tag ...
-
For backwards compatibility, calls DebugOn() and - if that does not turn tracing on, it calls - DebugOff() to turn it off.
-
-

The variables DEBUG_SKIP and - DEBUG_DO are set so as to enable/disable code that - should be skipped/run when debugging is turned on. - DEBUGGING is the same as - DEBUG_SKIP for backwards compatibility and is only set - by - ().

-

The use of $_DEBUG_SH is to prevent - multiple inclusion, though it does no harm in this case.

-
-
-

-

Does not work with some versions of ksh(1). If a - function turns tracing on, ksh turns it off when the function returns - - useless.

-

PD ksh works ok ;-)

-
-
-

-

debug.sh was written by - Simon J Gerraty - <sjg@crufty.net>.

-

-

-
-
- - - - - -
October 22, 2024FreeBSD 15.0
diff --git a/static/freebsd/man8/diskless.8 3.html b/static/freebsd/man8/diskless.8 3.html deleted file mode 100644 index 9709944a..00000000 --- a/static/freebsd/man8/diskless.8 3.html +++ /dev/null @@ -1,290 +0,0 @@ - - - - - - -
DISKLESS(8)System Manager's ManualDISKLESS(8)
-
-
-

-

diskless — booting - a system over the network with PXE

-
-
-

-

The ability to boot a machine over the network is useful for - - or - - machines, or as a temporary measure while repairing or re-installing file - systems on a local disk. This file provides a general description of the - interactions between a client and its server when a client is booting over - the network.

-
-
-

-

When booting a system over the network, there are three phases of - interaction between client and server:

-
    -
  1. The stage-1 bootstrap, typically PXE built into your Ethernet card, loads - a second-stage boot program.
    2. -
  2. The second-stage boot program, typically pxeboot(8), - loads modules and the kernel, and boots the kernel.
    3. -
  3. The kernel NFS mounts the root directory and continues from there.
    4. -
-

Each of these phases are described in further detail below.

-

First, the stage-1 bootstrap loads the stage-2 boot program over - the network. The stage-1 bootstrap typically uses BOOTP or DHCP to obtain - the filename to load, then uses TFTP to load the file. This file is - typically called pxeboot, and should be copied from - /boot/pxeboot into the TFTP directory on the server, - which is typically /tftpdir.

-

The stage-2 boot program then loads additional modules and the - kernel. These files may not exist on the DHCP or BOOTP server. You can use - the next-server option available in DHCP - configurations to specify the server holding the second stage boot files and - kernel. The stage-2 program uses NFS or TFTP to obtain these files. By - default, NFS is used. If you are using pxeboot(8), you can - install a version that uses TFTP by setting - LOADER_TFTP_SUPPORT=YES in your - make.conf(5), then recompiling and reinstalling - pxeboot(8) via the command listed below. It is often - necessary to use TFTP here so you can place a custom kernel in - /tftpdir/. If you use NFS and do not have a custom - root file system for the diskless client, the - stage-2 boot will load your server's kernel as the kernel for the - diskless machine, which may not be what you want to - have happen.

-
-
cd /usr/src/stand
-make clean; make; make install
-cp /boot/pxeboot /tftpdir/
-
-

In phase 3, the kernel acquires IP networking configuration in one - of two ways, and then proceeds to mount the root file system and start - operation. If the phase 2 loader supports passing network configuration to - the kernel using the kernel environment, then the kernel will configure the - network interface using that information. Otherwise, it must use DHCP or - BOOTP to acquire configuration information. The boot scripts recognize a - diskless startup and perform the actions found in - /etc/rc.d/resolv, - /etc/rc.d/tmp, - /etc/rc.d/var, and - /etc/rc.initdiskless.

-
-
-

-

In order to run a diskless client, you - need the following:

-
    -
  • An NFS server which exports a root and /usr - partitions with appropriate permissions. The - diskless scripts work with read-only partitions, - as long as root is exported with -maproot=0 so - that some system files can be accessed. As an example, - /etc/exports can contain the following lines: -
    - 
    <ROOT> -ro -maproot=0 -alldirs <list of diskless clients>
-/usr -ro -alldirs <list of diskless clients>
    -
    -

    where ⟨ROOT⟩ is the mount point on the server of - the root partition. The script - /usr/share/examples/diskless/clone_root can be - used to create a shared read-only root partition, but in many cases you - may decide to export (again as read-only) the root directory used by the - server itself.

    -
    • -
  • A BOOTP or DHCP server. bootpd(8) can be enabled by - uncommenting the “bootps” line in - /etc/inetd.conf. A sample - /etc/bootptab can be the following: -
    - 
     .default:\
-    hn:ht=1:vm=rfc1048:\
-    :sm=255.255.255.0:\
-    :sa=<SERVER>:\
-    :gw=<GATEWAY>:\
-    :rp="<SERVER>:<ROOT>":
-
-<CLIENT>:ha=0123456789ab:tc=.default
    -
    -

    where ⟨SERVER⟩, ⟨GATEWAY⟩ and - ⟨ROOT⟩ have the obvious meanings.

    -
    • -
  • A properly initialized root partition. The script - /usr/share/examples/diskless/clone_root can help - in creating it, using the server's root partition as a reference. If you - are just starting out, you should simply use the server's own root - directory, /, and not try to clone it. -

    You often do not want to use the same - rc.conf or rc.local - files for the diskless boot as you do on the - server. The diskless boot scripts provide a - mechanism through which you can override various files in - /etc (as well as other subdirectories of - root).

    -

    One difference that you should pay particular attention to is - the value of local_startup in - /etc/defaults/rc.conf. A typical value for a - diskless boot is - mountcritremote, however your needs may be - different.

    -

    The scripts provide four overriding directories situated in - /conf/base, - /conf/default, - /conf/<broadcast-ip>, and - /conf/<machine-ip>. You should always - create /conf/base/etc, which will entirely - replace the server's /etc on the - diskless machine. You can clone the server's - /etc here or you can create a special file which - tells the diskless boot scripts to remount the - server's /etc onto - /conf/base/etc. You do this by creating the file - /conf/base/etc/diskless_remount containing the - mount point to use as a basis of the diskless - machine's /etc. For example, the file might - contain:

    -

    -
    10.0.0.1:/etc
    -

    Alternatively, if the server contains several independent - roots, the file might contain:

    -

    -
    10.0.0.1:/usr/diskless/4.7-RELEASE/etc
    -

    This would work, but if you copied - /usr/diskless/4.7-RELEASE to - /usr/diskless/4.8-RELEASE and upgraded the - installation, you would need to modify the - diskless_remount files to reflect that move. To - avoid that, paths in diskless_remount files - beginning with / have the actual path of the - client's root prepended to them so the file could instead contain:

    -

    -
    /etc
    -

    The diskless scripts create memory - file systems to hold the overridden directories. Only a 5MB partition is - created by default, which may not be sufficient for your purposes. To - override this, you can create the file - /conf/base/etc/md_size containing the size, in - 512 byte sectors, of the memory disk to create for that directory.

    -

    You then typically provide file-by-file overrides in the - /conf/default/etc directory. At a minimum, you - must provide overrides for /etc/fstab, - /etc/rc.conf, and - /etc/rc.local via - /conf/default/etc/fstab, - /conf/default/etc/rc.conf, and - /conf/default/etc/rc.local.

    -

    Overrides are hierarchical. You can supply network-specific - defaults in the - /conf/⟨BROADCASTIP⟩/etc - directory, where ⟨BROADCASTIP⟩ - represents the broadcast IP address of the - diskless system as given to it via BOOTP. The - diskless_remount and - md_size features work in any of these - directories. The configuration feature works on directories other then - /etc, you simply create the directory you wish - to replace or override in - /conf/{base,default,<broadcast>,<ip>}/* - and work it in the same way that you work - /etc.

    -

    Since you normally clone the server's - /etc using the - /conf/base/etc/diskless_remount, you might wish - to remove unneeded files from the memory file system. For example, if - the server has a firewall but you do not, you might wish to remove - /etc/ipfw.conf. You can do this by creating a - /conf/base/⟨DIRECTORY⟩.remove - file. For example, /conf/base/etc.remove, which - contains a list of relative paths that the boot scripts should remove - from the memory file systems.

    -

    As a minimum, you normally need to have the following in - /conf/default/etc/fstab

    -
    - 
    <SERVER>:<ROOT> /     nfs    ro 0 0
-<SERVER>:/usr   /usr  nfs    ro 0 0
    -
    -

    You also need to create a customized version of - /conf/default/etc/rc.conf which should contain - the startup options for the diskless client, and - /conf/default/etc/rc.local which could be empty - but prevents the server's own /etc/rc.local from - leaking onto the diskless system.

    -

    In rc.conf, most likely you will not - need to set hostname and - ifconfig_* because these will be already set by - the startup code. Finally, it might be convenient to use a - case statement using - `hostname` as the switch variable to do - machine-specific configuration in case a number of - diskless clients share the same configuration - files.

    -
    • -
  • The kernel for the diskless clients, which will be - loaded using NFS or TFTP, must include support for the NFS client: -

    -
    options NFSCL
    -
    options NFS_ROOT
    -

    If you are using a boot mechanism that does not pass network - configuration to the kernel using the kernel environment, you will also - need to include the following options:

    -

    -
    options BOOTP
    -
    options - BOOTP_NFSROOT
    -
    options BOOTP_COMPAT
    -

    : - the PXE environment does not require these options.

    -

    The diskless booting environment - relies on memory-backed file systems to support temporary local storage - in the event that the root file system is mounted read-only; as such, it - is necessary to add the following to the device section of the kernel - configuration:

    -

    -
    device md
    -

    If you use the firewall, remember to default to - “open”, or your kernel will not be able to send/receive - the BOOTP packets.

    -
    • -
-
-
-

-

Be warned that using unencrypted NFS to mount root and user - partitions may expose information such as encryption keys.

-
-
-

-

ethers(5), exports(5), - make.conf(5), bootpd(8), - mountd(8), nfsd(8), - pxeboot(8), reboot(8), - tftpd(8)

-

ports/net/etherboot

-
-
-

-

The diskless environment first appeared in - FreeBSD 2.2.5.

-
-
-

-

This manpage is probably incomplete.

-

FreeBSD sometimes requires to write onto - the root partition, so the startup scripts mount MFS file systems on some - locations (e.g. /etc and - /var), while trying to preserve the original - content. The process might not handle all cases.

-
-
- - - - - -
August 11, 2024FreeBSD 15.0
diff --git a/static/freebsd/man8/intro.8 4.html b/static/freebsd/man8/intro.8 4.html deleted file mode 100644 index 9a8fa084..00000000 --- a/static/freebsd/man8/intro.8 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
INTRO(8)System Manager's ManualINTRO(8)
-
-
-

-

intro — - introduction to system maintenance procedures and - commands

-
-
-

-

This section contains information related to system operation and - maintenance.

-

It describes commands used to create new file systems - (newfs(8)), verify the integrity of the file systems - (fsck(8)), control disk usage - (edquota(8)), maintain system backups - (dump(8)), and recover files when disks die an untimely - death (restore(8)). Network related services like - inetd(8) are also described.

-

All commands set an exit status. Its value may be tested to see if - the command completed normally. Unless otherwise noted (rare), the value 0 - signifies successful completion of the command, while a value >0 - indicates an error. Some commands attempt to describe the nature of the - failure by using error codes defined in sysexits(3), or - set the status to arbitrary values >0 (typically 1), but many such values - are not described in the manual.

-

A number of pages in this section describe general system - management topics.

-

For example, the boot(8) manual page describes - the system bootstrapping procedures, and the diskless(8) - manual page describes how to boot a system over a network. The - crash(8) manual page should be consulted to understand how - to interpret system crash dumps.

-
-
-

-

The intro section manual page appeared in - 4.2BSD.

-
-
- - - - - -
October 22, 2006FreeBSD 15.0
diff --git a/static/freebsd/man8/nanobsd.8 3.html b/static/freebsd/man8/nanobsd.8 3.html deleted file mode 100644 index d6ad1f23..00000000 --- a/static/freebsd/man8/nanobsd.8 3.html +++ /dev/null @@ -1,278 +0,0 @@ - - - - - - -
NANOBSD(8)System Manager's ManualNANOBSD(8)
-
-
-

-

nanobsd.sh — - create an embedded FreeBSD system image

-
-
-

- - - - - -
nanobsd.sh[-BbfhIiKknpqvWwX] [-c - config-file]
-
-
-

-

The nanobsd.sh utility is a script which - produces a minimal implementation of FreeBSD (called - NanoBSD), which typically fits on a small media such - as an SD card, or other mass storage medium. It can be used to build - specialized install images, designed for easy installation and - maintenance.

-

The following options are available:

-
-
-
-
Skip the install stages (both for kernel and world).
-
-
Skip the build stages (both for kernel and world).
-
- config-file
-
Specify the configuration file to use.
-
-
Skip the code slice extraction.
-
-
Display usage information.
-
-
Build the disk image from an existing build/install.
-
-
Skip the disk image build stage.
-
-
Skip the installkernel stage of the build.
-
-
Skip the buildkernel stage of the build.
-
-
Do not cleanup before each build stage. This suppresses the normal cleanup - work done before the buildworld stage and adds - -DNO_CLEAN to the make command line used for each build stage (world and - kernel).
-
-
Don't prepare the image. Skip running of the customization and early - customization scripts for incremental image refinement from world, kernel, - or packages.
-
-
Make output more quiet.
-
-
Make output more verbose.
-
-
Skip the installworld stage of the build.
-
-
Skip the buildworld stage of the build.
-
-
Make native-xtools.
-
-
-

The features of NanoBSD include:

-

-
    -
  • Ports and packages work as in FreeBSD. Every - single application can be installed and used in a - NanoBSD image, the same way as in - FreeBSD.
    • -
  • No missing functionality. If it is possible to do something with - FreeBSD, it is possible to do the same thing with - NanoBSD, unless the specific feature or features - were explicitly removed from the NanoBSD image - when it was created.
    • -
  • Everything is read-only at run-time. It is safe to pull the power-plug. - There is no necessity to run fsck(8) after a - non-graceful shutdown of the system.
    • -
  • Easy to build and customize. Making use of just one shell script and one - configuration file it is possible to build reduced and customized images - satisfying any arbitrary set of requirements.
    • -
-
-

-

The mass storage medium is divided into three parts by default - (which are normally mounted read-only):

-

-
    -
  • Two image partitions: code#1 and - code#2.
    • -
  • The configuration file partition, which can be mounted under the - /cfg directory at run time.
    • -
-

The /etc and /var - directories are md(4) (malloc backed) disks.

-

The configuration file partition persists under the - /cfg directory. It contains files for - /etc directory and is briefly mounted read-only - right after the system boot, therefore it is required to copy modified files - from /etc back to the /cfg - directory if changes are expected to persist after the system restarts.

-
-
-
-

-

A NanoBSD image is built using a simple - nanobsd.sh shell script, which can be found in the - src/tools/tools/nanobsd directory. This script - creates a bootable image, which can be copied on the storage medium using - the dd(1) utility.

-

The necessary commands to build and install a - NanoBSD image are:

-
-
cd /usr/src/tools/tools/nanobsd
-sh nanobsd.sh
-cd /usr/obj/nanobsd.full
-dd if=_.disk.full of=/dev/da0 bs=64k
-
-
-
-

-

This is probably the most important and most interesting feature - of NanoBSD. This is also where you will be spending - most of the time when developing with NanoBSD.

-

Customization is done in two ways:

-

-
    -
  • Configuration options.
    • -
  • Custom functions.
    • -
-

With configuration settings, it is possible to configure options - passed to both the buildworld and - installworld stages of the - NanoBSD build process, as well as internal options - passed to the main build process of NanoBSD. Through - these options it is possible to cut the system down, so it will fit on as - little as 64MB. You can use the configuration options to trim down the - system even more, until it will consist of just the kernel and two or three - files in the userland.

-

The configuration file consists of configuration options, which - override the default values. The most important directives are:

-
-
-
NANO_NAME
-
Build name (used to construct the working directory names).
-
NANO_SRC
-
Path to the source tree used to build the image.
-
NANO_KERNEL
-
Name of the kernel configuration file used to build the kernel.
-
NANO_ARCH
-
Machine processor architecture to build. Defaults to output of - uname -p.
-
NANO_BOOT0CFG
-
Controls the options passed to boot0cfg(8); these - dictate boot0's behaviour.
-
NANO_BOOTLOADER
-
The boot0 loader to use relative to the - NANO_WORLDDIR variable. This defaults to - boot/boot0sio and should be overridden to - boot/boot0 to provide a VGA console.
-
CONF_BUILD
-
Options passed to the buildworld stage of the - build.
-
CONF_INSTALL
-
Options passed to the installworld stage of the - build.
-
CONF_WORLD
-
Options passed to both the buildworld and - installworld stages of the build.
-
FlashDevice
-
Defines the type of media to use. Check the - FlashDevice.sub file for more details.
-
-
-

For more configuration options, please check the - nanobsd.sh script.

-

To build NanoBSD image using the - nanobsd.conf configuration file, use the following - command:

-
-
sh nanobsd.sh -c nanobsd.conf
-
-

It is possible to fine-tune NanoBSD using - shell functions in the configuration file. The following example illustrates - the basic model of custom functions:

-
-
cust_foo () (
-	echo "bar=topless" > \
-	     ${NANO_WORLDDIR}/etc/foo
-)
-customize_cmd cust_foo
-
-

There are a few pre-defined customization functions ready for - use:

-
-
-
-
Disables getty(8) on the virtual - syscons(4) or vt(4) terminals - (/dev/ttyv*) and enables the use of the first - serial port as the system console.
-
-
Allow root to log in via sshd(8).
-
-
Installs files from the nanobsd/Files directory, - which contains some useful scripts for system administration.
-
-
-
-
-

-
-
src/tools/tools/nanobsd
-
Base directory of the NanoBSD build script.
-
-
-
-

-

Making persistent changes to - /etc/resolv.conf:

-
-
vi /etc/resolv.conf
-...
-mount /cfg
-cp /etc/resolv.conf /cfg
-umount /cfg
-
-

A more useful example of a customization function is the - following, which changes the default size of the - /etc directory from 5MB to 30MB:

-
-
cust_etc_size () (
-	cd ${NANO_WORLDDIR}/conf
-	echo 30000 > default/etc/md_size
-)
-customize_cmd cust_etc_size
-
-
-
-

-

make.conf(5), boot(8), - boot0cfg(8)

-
-
-

-

The nanobsd.sh utility first appeared in - FreeBSD 6.0.

-
-
-

-

NanoBSD was developed by - Poul-Henning Kamp - <phk@FreeBSD.org>. - This manual page was written by Daniel Gerzo - <danger@FreeBSD.org>.

-
-
- - - - - -
September 9, 2025FreeBSD 15.0
diff --git a/static/freebsd/man8/rc.8 3.html b/static/freebsd/man8/rc.8 3.html deleted file mode 100644 index a5052e3d..00000000 --- a/static/freebsd/man8/rc.8 3.html +++ /dev/null @@ -1,472 +0,0 @@ - - - - - - -
RC(8)System Manager's ManualRC(8)
-
-
-

-

rc — command - scripts for auto-reboot and daemon startup

-
-
-

- - - - - -
rc
-
- - - - - -
rc.conf
-
- - - - - -
rc.conf.local
-
- - - - - -
rc.d/
-
- - - - - -
rc.firewall
-
- - - - - -
rc.local
-
- - - - - -
rc.resume
-
- - - - - -
rc.shutdown
-
- - - - - -
rc.subr
-
- - - - - -
rc.suspend
-
-
-

-

The rc utility is the command script which - controls the automatic boot process after being called by - init(8). The rc.local script - contains commands which are pertinent only to a specific site. Typically, - the /usr/local/etc/rc.d/ mechanism is used instead - of rc.local these days but if you want to use - rc.local, it is still supported. In this case, it - should source /etc/rc.conf and contain additional - custom startup code for your system. The best way to handle - rc.local, however, is to separate it out into - rc.d/ style scripts and place them under - /usr/local/etc/rc.d/. The - rc.conf file contains the global system - configuration information referenced by the startup scripts, while - rc.conf.local contains the local system - configuration. See rc.conf(5) for more information.

-

The rc.d/ directories contain scripts - which will be automatically executed at boot time and shutdown time.

-

The service(8) command provides a convenient - interface to manage rc.d services.

-

The sysrc(8) command provides a scripting - interface to modify system config files.

-
-

-
    -
  1. If autobooting, set - autoboot=yes and enable a - flag (rc_fast=yes), which - prevents the rc.d/ scripts from performing the - check for already running processes (thus speeding up the boot process). - This rc_fast=yes speedup - will not occur when rc is started up after exiting - the single-user shell.
    2. -
  2. Determine whether the system is booting diskless, and if so run the - /etc/rc.initdiskless script.
    3. -
  3. Source /etc/rc.subr to load various - rc.subr(8) shell functions to use.
    4. -
  4. Load the configuration files (see below for reloading).
    5. -
  5. Determine if booting in a jail, and add - “nojail” (no jails allowed) or - “nojailvnet” (only allow - vnet-enabled jails) to the list of KEYWORDS to skip in - rcorder(8).
    6. -
  6. If the file ${firstboot_sentinel} does not exist, - add “firstboot” to the list of - KEYWORDS to skip in rcorder(8).
    7. -
  7. Invoke rcorder(8) to order the files in - /etc/rc.d/ that do not have a - “nostart” KEYWORD (refer to - rcorder(8)'s -s flag).
    8. -
  8. Call - () - with the list of scripts to be run. -

    For each script that will call - () - (both functions are from rc.subr(8)), which sets - $1 to - “start”, and sources the script in - a subshell. Stop processing when the script that is the value of the - $early_late_divider has been run.

    -
    9. -
  9. Check again to see if the file ${firstboot_sentinel} - exists (in case it is located on a newly mounted file system) and adjust - the list of KEYWORDs to skip appropriately.
    10. -
  10. Re-run rcorder(8), this time including the scripts in - the $local_startup directories. Call - run_rc_scripts() again with the new list of - scripts. It will skip any that have already been run and execute the rest - as described above.
    11. -
  11. If the file ${firstboot_sentinel} exists, delete it. - If the file ${firstboot_sentinel}-reboot also exists - (because it was created by a script), then delete it and reboot.
    12. -
-
-
-

-
    -
  1. Set rc_shutdown to the value of the first argument - passed to rc.shutdown or to - “unspecified” if no argument was - passed.
    2. -
  2. Source /etc/rc.subr to load various - rc.subr(8) shell functions to use.
    3. -
  3. Load the configuration files.
    4. -
  4. Invoke rcorder(8) to order the files in - /etc/rc.d/ and the - $local_startup directories that have a - “shutdown” KEYWORD (refer to - rcorder(8)'s -k flag), reverse - that order, and assign the result to a variable.
    5. -
  5. Call each script in turn using run_rc_script() - (from rc.subr(8)), which sets $1 - to “faststop”, and sources the - script in a subshell.
    6. -
-
-
-

-

rc.d/ is located in - /etc/rc.d/. The following file naming conventions - are currently used in rc.d/:

-
-
-
ALLUPPERCASE
-
Scripts that are “placeholders” to ensure that certain - operations are performed before others. In order of startup, these are: -
-
FILESYSTEMS
-
Ensure that root and other critical file systems are mounted. This is - the default $early_late_divider.
-
NETWORKING
-
Ensure basic network services are running, including general network - configuration.
-
SERVERS
-
Ensure basic services exist for services that start early (such as - nisdomain), because they are required by - DAEMON below.
-
DAEMON
-
Check-point before all general purpose daemons such as - lpd and ntpd.
-
LOGIN
-
Check-point before user login services (inetd - and sshd), as well as services which might run - commands as users (cron and - sendmail).
-
-
-
bar
-
Scripts that are sourced in a subshell. The boot does not stop if such a - script terminates with a non-zero status, but a script can stop the boot - if necessary by invoking the - () - function (from rc.subr(8)).
-
-
-

Each script should contain rcorder(8) keywords, - especially an appropriate “PROVIDE” - entry, and if necessary “REQUIRE” and - “BEFORE” keywords.

-

Each script is expected to support at least - the following arguments, which are automatically supported if it uses the - () - function:

-
-
-
-
Start the service. This should check that the service is to be started as - specified by rc.conf(5). Also checks if the service is - already running and refuses to start if it is. This latter check is not - performed by standard FreeBSD scripts if the - system is starting directly to multi-user mode, to speed up the boot - process. If forcestart is given, ignore the - rc.conf(5) check and start anyway.
-
-
If the service is to be started as specified by - rc.conf(5), stop the service. This should check that the - service is running and complain if it is not. If - forcestop is given, ignore the - rc.conf(5) check and attempt to stop.
-
-
Perform a stop then a - start.
-
-
If the script starts a process (rather than performing a one-off - operation), show the status of the process. Otherwise it is not necessary - to support this argument. Defaults to displaying the process ID of the - program (if running).
-
-
Enable the service in rc.conf(5).
-
-
Disable the service in rc.conf(5).
-
-
Remove the service from rc.conf(5). If - ‘service_delete_empty’ - is set to “YES”, - /etc/rc.conf.d/$servicename will be deleted if - empty after modification.
-
-
Print a short description of what the script does.
-
-
Print the script's non-standard commands.
-
-
If the script starts a process (rather than performing a one-off - operation), wait for the command to exit. Otherwise it is not necessary to - support this argument.
-
-
Return 0 if the service is enabled and 1 if it is not. This command does - not print anything.
-
-
Display which rc.conf(5) variables are used to control - the startup of the service (if any).
-
-
-

If a script must implement additional commands it can list them in - the extra_commands variable, and define their actions - in a variable constructed from the command name (see the - EXAMPLES section).

-

The configuration files are normally read only once at the start - of a boot sequence; if a script needs to enable or - disable any other script that would run later in the - sequence, it must send a SIGALRM to the rc process - (identified by $RC_PID) to have it re-read the - files.

-

The following key points apply to old-style scripts in - /usr/local/etc/rc.d/:

-
    -
  • Scripts are only executed if their basename(1) matches - the shell globbing pattern *.sh, and they are - executable. Any other files or directories present within the directory - are silently ignored.
    • -
  • When a script is executed at boot time, it is passed the string - “start” as its first and only - argument. At shutdown time, it is passed the string - “stop” as its first and only - argument. All rc.d/ scripts are expected to handle - these arguments appropriately. If no action needs to be taken at a given - time (either boot time or shutdown time), the script should exit - successfully and without producing an error message.
    • -
  • The scripts within each directory are executed in lexicographical order. - If a specific order is required, numbers may be used as a prefix to the - existing filenames, so for example 100.foo would - be executed before 200.bar; without the numeric - prefixes the opposite would be true.
    • -
  • The output from each script is traditionally a space - character, followed by the name of the software package being started or - shut down, - a - trailing newline character.
    • -
-
-
-
-

-

When an automatic reboot is in progress, - rc is invoked with the argument - autoboot. One of the scripts run from - /etc/rc.d/ is - /etc/rc.d/fsck. This script runs - fsck(8) with option -p and - -F to “preen” all the disks of minor - inconsistencies resulting from the last system shutdown. If this fails, then - checks/repairs of serious inconsistencies caused by hardware or software - failure will be performed in the background at the end of the booting - process. If autoboot is not set, when going from - single-user to multi-user mode for example, the script does not do - anything.

-

The /etc/rc.d/serial script is used to set - any special configurations for serial devices.

-

The rc.firewall script is used to - configure rules for the kernel based firewall service. It has several - possible options:

-

-
-
-
-
will allow anyone in
-
-
will try to protect just this machine
-
-
will try to protect a whole network
-
-
totally disables IP services except via lo0 - interface
-
-
disables the loading of firewall rules
-
filename
-
will load the rules in the given filename (full path required).
-
-
-

Most daemons, including network related daemons, have their own - script in /etc/rc.d/, which can be used to start, - stop, and check the status of the service.

-

Any architecture specific scripts, such as - /etc/rc.d/apm for example, specifically check that - they are on that architecture before starting the daemon.

-

Following tradition, all startup files reside in - /etc.

-
-
-

-
-
/etc/rc
-
 
-
/etc/rc.conf
-
 
-
/etc/rc.conf.local
-
 
-
/etc/rc.d/
-
 
-
/etc/rc.firewall
-
 
-
/etc/rc.local
-
 
-
/etc/rc.shutdown
-
 
-
/etc/rc.subr
-
 
-
/var/run/dmesg.boot
-
dmesg(8) results soon after the - rc process begins. Useful when - dmesg(8) buffer in the kernel no longer has this - information.
-
-
-
-

-

The following is a minimal rc.d/ style - script. Most scripts require little more than the following.

-
-
#!/bin/sh
-#
-
-# PROVIDE: foo
-# REQUIRE: bar_service_required_to_precede_foo
-
-. /etc/rc.subr
-
-name="foo"
-rcvar=foo_enable
-command="/usr/local/bin/foo"
-
-load_rc_config $name
-run_rc_command "$1"
-
-

Certain scripts may want to provide enhanced functionality. The - user may access this functionality through additional commands. The script - may list and define as many commands at it needs.

-
-
#!/bin/sh
-#
-
-# PROVIDE: foo
-# REQUIRE: bar_service_required_to_precede_foo
-# BEFORE:  baz_service_requiring_foo_to_precede_it
-
-. /etc/rc.subr
-
-name="foo"
-rcvar=foo_enable
-command="/usr/local/bin/foo"
-extra_commands="nop hello"
-hello_cmd="echo Hello World."
-nop_cmd="do_nop"
-
-do_nop()
-{
-	echo "I do nothing."
-}
-
-load_rc_config $name
-run_rc_command "$1"
-
-

As all processes are killed by init(8) at - shutdown, the explicit kill(1) is unnecessary, but is - often included.

-
-
-

-

kill(1), rc.conf(5), - init(8), rc.resume(8), - rc.subr(8), rcorder(8), - reboot(8), savecore(8), - service(8), sysrc(8)

-

-

Practical rc.d scripting in - BSD, - <https://docs.freebsd.org/en/articles/rc-scripting/>.

-
-
-

-

The rc utility appeared in - 4.0BSD.

-
-
- - - - - -
September 20, 2024FreeBSD 15.0
diff --git a/static/freebsd/man8/rc.subr.8 3.html b/static/freebsd/man8/rc.subr.8 3.html deleted file mode 100644 index 582ece18..00000000 --- a/static/freebsd/man8/rc.subr.8 3.html +++ /dev/null @@ -1,806 +0,0 @@ - - - - - - -
RC.SUBR(8)System Manager's ManualRC.SUBR(8)
-
-
-

-

rc.subr — - functions used by system shell scripts

-
-
-

- -
-
-

-

The rc.subr script contains commonly used - shell script functions and variable definitions which are used by various - scripts such as rc(8). Scripts required by ports in - /usr/local/etc/rc.d will also eventually be - rewritten to make use of it.

-

The rc.subr functions were mostly imported - from NetBSD.

-

They are accessed by sourcing /etc/rc.subr - into the current shell.

-

The following shell functions are available:

-
-
- action file current backup
-
Make a backup copy of file into - current. Save the previous version of - current as backup. -

The action argument may be one of the - following:

-
-
-
file is now being backed up by or possibly - re-entered into this backup mechanism. current - is created.
-
-
file has changed and needs to be backed up. If - current exists, it is copied to - backup and then file is - copied to current.
-
-
file is no longer being tracked by this backup - mechanism. current is moved to - backup.
-
-
-
- var
-
Return 0 if var is defined to - “YES”, - “TRUE”, - “ON”, or - ‘1’. Return 1 if - var is defined to - “NO”, - “FALSE”, - “OFF”, or - ‘0’. Otherwise, warn that - var is not set correctly. The values are case - insensitive. Note: var should be a - variable name, not its value; checkyesno will - expand the variable by itself.
-
- pidfile procname - [interpreter]
-
Parses the first word of the first line of pidfile - for a PID, and ensures that the process with that PID is running and its - first argument matches procname. Prints the matching - PID if successful, otherwise nothing. If interpreter - is provided, parse the first line of procname, - ensure that the line is of the form: -

-
#! interpreter [...]
-

and use interpreter with its optional - arguments and procname appended as the process - string to search for.

-
-
- procname [interpreter]
-
Prints the PIDs of any processes that are running with a first argument - that matches procname. - interpreter is handled as per - check_pidfile.
-
- tag ...
-
Enable tracing if not already enabled, and any tag - is found in DEBUG_SH (a comma separated list of - tags). -

Record the tag that caused it to be - enabled in DEBUG_ON, set - DEBUG_DO empty and - DEBUG_SKIP to - ‘:’.

-

See debug.sh(8) for more details.

-
-
- tag ...
-
Disable tracing if enabled and any tag matches - DEBUG_ON, which means it was the reason tracing was - enabled. -

Set DEBUG_DO to - ‘:’, and - DEBUG_ON, DEBUG_SKIP - empty.

-
-
- message
-
Display a debugging message to stderr, log it to the - system log using logger(1), and return to the caller. - The error message consists of the script name (from - $0), followed by “: DEBUG: - ”, and then message. This function is - intended to be used by developers as an aid to debugging scripts. It can - be turned on or off by the rc.conf(5) variable - rc_debug.
-
- file ...
-
For reading in unverified files. -

Ensure shell verify option is off. - This option is only meaningful when mac_veriexec(4) is - active.

-

Read each file if it exists.

-

Restore previous state of the verify - option.

-
-
- exitval message
-
Display an error message to stderr, log it to the - system log using logger(1), and - exit with an exit value of - exitval. The error message consists of the script - name (from $0), followed by - “: ERROR: ”, and then - message.
-
- name
-
Output an advisory message and force the name - service to start. The name argument is the - basename(1) component of the path to the script located - at /etc/rc.d (scripts stored in other locations - such as /usr/local/etc/rc.d cannot be controlled - with force_depend currently). If the script fails - for any reason it will output a warning and return with a return value of - 1. If it was successful it will return 0.
-
- file
-
If veriexec(8) does not exist, or - mac_veriexec(4) is not active, just return success. - Otherwise use veriexec(8) to check if - file is verified. If not verified the return code - will be 80 (EAUTH).
-
- message
-
Display an informational message to stdout, and log - it to the system log using logger(1). The message - consists of the script name (from $0), followed by - “: INFO: ”, and then - message. The display of this informational output - can be turned on or off by the rc.conf(5) variable - rc_info.
-
- [-e regex] - [-m module] - file
-
Load file as a kernel module unless it is already - loaded. For the purpose of checking the module status, either the exact - module name can be specified using -m, or an - egrep(1) regular expression matching the module name can - be supplied via -e. By default, the module is - assumed to have the same name as file, which is not - always the case.
-
- [flag] [service]
-
Source in the configuration file(s) for service. If - no service is specified, only the global - configuration file(s) will be loaded. First, - /etc/rc.conf is sourced if it has not yet been - read in. Then, - /etc/rc.conf.d/service is - sourced if it is an existing file. The latter may also contain other - variable assignments to override run_rc_command - arguments defined by the calling script, to provide an easy mechanism for - an administrator to override the behaviour of a given - rc.d(8) script without requiring the editing of that - script. -

The function named by - load_rc_config_reader (default is - dot) is used to read configuration unless - flag is:

-
-
-
use sdot to read configuration, because we - want verified configuration or to use safe_dot - to read an unverified configuration.
-
-
use vdot to read in configuration only if it - is verified.
-
-

DebugOn will be called with tags - derived from name to enable tracing if any appear - in DEBUG_SH.

-
-
- name var
-
Read the rc.conf(5) variable var - for name and set in the current shell, using - load_rc_config in a sub-shell to prevent unwanted - side effects from other variable assignments.
-
- type
-
Go through a list of critical file systems, as found in the - rc.conf(5) variable - critical_filesystems_type, - mounting each one that is not currently mounted.
-
- message
-
Output message with a timestamp, which is both human - readable and easily parsed for post processing, using: -
- 
date "+@ %s [%Y-%m-%d %H:%M:%S %Z] $*"
-
-
-
- level message
-
If the file /etc/rc.conf.d/rc_trace exists and is - not empty attempt to set RC_LEVEL based on its - content. If the file is empty or does not contain a value for - RC_LEVEL, set it to 0. -

If level is greater than or equal to - RC_LEVEL pass message to - rc_log.

-
-
- command ...
-
Print a usage message for $0, with - commands being the list of valid arguments prefixed - by - “[fast|force|one|quiet]”.
-
- item ...
-
Print the list of items in reverse order.
-
- argument
-
Run the argument method for the current - rc.d(8) script, based on the settings of various shell - variables. run_rc_command is extremely flexible, - and allows fully functional rc.d(8) scripts to be - implemented in a small amount of shell code. -

argument is searched for in the list of - supported commands, which may be one of:

-
-
-
-
Start the service. This should check that the service is to be started - as specified by rc.conf(5). Also checks if the - service is already running and refuses to start if it is. This latter - check is not performed by standard FreeBSD - scripts if the system is starting directly to multi-user mode, to - speed up the boot process.
-
-
If the service is to be started as specified by - rc.conf(5), stop the service. This should check that - the service is running and complain if it is not.
-
-
Perform a stop then a - start. Defaults to displaying the process ID - of the program (if running).
-
-
Return 0 if the service is enabled and 1 if it is not. This command - does not print anything.
-
-
Display which rc.conf(5) variables are used to - control the startup of the service (if any).
-
-
-

If pidfile or - procname is set, also support:

-
-
-
-
Wait for the command to exit.
-
-
Show the status of the process.
-
-
-

Other supported commands are listed in the optional variable - extra_commands.

-

argument may have one of the following - prefixes which alters its operation:

-
-
-
-
Skip the check for an existing running process, and sets - rc_fast=YES.
-
-
Skip the checks for rcvar being set to - “YES”, and sets - rc_force=YES. This - ignores argument_precmd - returning non-zero, and ignores any of the - required_* tests failing, and always returns a - zero exit status.
-
-
Skip the checks for rcvar being set to - “YES”, but performs all the - other prerequisite tests.
-
-
Inhibits some verbose diagnostics. Currently, this includes messages - "Starting ${name}" (as checked by - check_startmsgs inside - rc.subr) and errors about usage of services - that are not enabled in rc.conf(5). This prefix also - sets rc_quiet=YES. - Note: rc_quiet is not intended - to completely mask all debug and warning messages, but only certain - small classes of them.
-
-
-

run_rc_command uses the following - shell variables to control its behaviour. Unless otherwise stated, these - are optional.

-
-
-
name
-
The name of this script. This is not optional.
-
rcvar
-
The value of rcvar is checked with - checkyesno to determine if this method should - be run.
-
command
-
Full path to the command. Not required if - argument_cmd is defined - for each supported keyword. Can be overridden by - ${name}_program.
-
command_args
-
Optional arguments and/or shell directives for - command.
-
command_interpreter
-
command is started with: -

-
#! command_interpreter - [...]
-

which results in its ps(1) command - being:

-

-
command_interpreter [...] - command
-

so use that string to find the PID(s) of the running - command rather than command.

-
-
extra_commands
-
Extra commands/keywords/arguments supported.
-
pidfile
-
Path to PID file. Used to determine the PID(s) of the running command. - If pidfile is set, use: -

-
check_pidfile $pidfile - $procname
-

to find the PID. Otherwise, if - command is set, use:

-

-
check_process - $procname
-

to find the PID.

-
-
procname
-
Process name to check for. Defaults to the value of - command.
-
required_dirs
-
Check for the existence of the listed directories before running the - start method. The list is checked before - running start_precmd.
-
required_files
-
Check for the readability of the listed files before running the - start method. The list is checked before - running start_precmd.
-
required_modules
-
Ensure that the listed kernel modules are loaded before running the - start method. The list is checked after - running start_precmd. This is done after - invoking the commands from start_precmd so that - the missing modules are not loaded in vain if the preliminary commands - indicate a error condition. A word in the list can have an optional - “:modname” - or - “~pattern” - suffix. The modname or - pattern parameter is passed to - load_kld through a -m - or -e option, respectively. See the - description of load_kld in this document for - details.
-
required_vars
-
Perform checkyesno on each of the list - variables before running the start method. The - list is checked after running start_precmd.
-
${name}_chdir
-
Directory to cd to before running - command, if ${name}_chroot - is not provided.
-
${name}_chroot
-
Directory to chroot(8) to before running - command. Only supported after - /usr is mounted.
-
${name}_env
-
A list of environment variables to run command - with. Those variables will be passed as arguments to the - env(1) utility unless - argument_cmd is defined. - In that case the contents of ${name}_env will be - exported via the export(1) builtin of - sh(1), which puts some limitations on the names of - variables (e.g., a variable name may not start with a digit).
-
${name}_env_file
-
A file to source for environmental variables to run - command with. Note: all the - variables which are being assigned in this file are going to be - exported into the environment of command.
-
${name}_fib
-
FIB Routing Table number to run - command with. See setfib(1) - for more details.
-
${name}_flags
-
Arguments to call command with. This is usually - set in rc.conf(5), and not in the - rc.d(8) script. The environment variable - ‘flags’ can be used to override - this.
-
${name}_nice
-
nice(1) level to run command - as. Only supported after /usr is mounted.
-
${name}_limits
-
Resource limits to apply to command. This will - be passed as arguments to the limits(1) utility. By - default, the resource limits are based on the login class defined in - ${name}_login_class.
-
${name}_login_class
-
Login class to use with ${name}_limits. Defaults - to “daemon”.
-
${name}_offcmd
-
Shell commands to run during start if a service is not enabled.
-
${name}_oomprotect
-
protect(1) command from being - killed when swap space is exhausted. If - “YES” is used, no child - processes are protected. If - “ALL”, protect all child - processes.
-
${name}_program
-
Full path to the command. Overrides command if - both are set, but has no effect if command is - unset. As a rule, command should be set in the - script while ${name}_program should be set in - rc.conf(5).
-
${name}_user
-
User to run command as, using - chroot(8) if ${name}_chroot is - set, otherwise uses su(1). Only supported after - /usr is mounted.
-
${name}_group
-
Group to run the chrooted command as.
-
${name}_groups
-
Comma separated list of supplementary groups to run the chrooted - command with.
-
${name}_prepend
-
Commands to be prepended to command. This is a - generic version of ${name}_env, - ${name}_fib, or - ${name}_nice.
-
${name}_setup
-
Optional command to be run during start, - restart, and reload - prior to the respective - argument_precmd. If the - command fails for any reason it will output a warning, but execution - will continue.
-
argument_cmd
-
Shell commands which override the default method for - argument.
-
argument_precmd
-
Shell commands to run just before running - argument_cmd or the - default method for argument. If this returns a - non-zero exit code, the main method is not performed. If the default - method is being executed, this check is performed after the - required_* checks and process (non-)existence - checks.
-
argument_postcmd
-
Shell commands to run if running - argument_cmd or the - default method for argument returned a zero exit - code.
-
sig_stop
-
Signal to send the processes to stop in the default - stop method. Defaults to - SIGTERM.
-
sig_reload
-
Signal to send the processes to reload in the default - reload method. Defaults to - SIGHUP.
-
-
-

For a given method argument, if - argument_cmd is not defined, - then a default method is provided by - run_rc_command:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If command is not running and - checkyesno rcvar - succeeds, start command.
Determine the PIDs of command with - check_pidfile or - check_process (as appropriate), - kill sig_stop those - PIDs, and run wait_for_pids on those - PIDs.
Similar to stop, except that it uses - sig_reload instead, and does not run - wait_for_pids. Another difference from - stop is that reload is - not provided by default. It can be enabled via - extra_commands if appropriate: -

-
extra_commands=reload
-
Runs the stop method, then the - start method.
Show the PID of command, or some other script - specific status operation.
Wait for command to exit.
Display which rc.conf(5) variable is used (if - any). This method always works, even if the appropriate - rc.conf(5) variable is set to - “NO”.
-

The following variables are available to the methods (such as - argument_cmd) as well as - after run_rc_command has completed:

-
-
-
rc_arg
-
Argument provided to run_rc_command, after - fast and force processing has been performed.
-
rc_flags
-
Flags to start the default command with. Defaults to - ${name}_flags, unless overridden by the - environment variable ‘flags’. - This variable may be changed by the - argument_precmd - method.
-
rc_service
-
Path to the service script being executed, in case it needs to - re-invoke itself.
-
rc_pid
-
PID of command (if appropriate).
-
rc_fast
-
Not empty if “fast” prefix was - used.
-
rc_force
-
Not empty if “force” prefix was - used.
-
-
-
-
- file argument
-
Start the script file with an argument of - argument, and handle the return value from the - script. -

Various shell variables are unset before - file is started:

-
name, - command, command_args, - command_interpreter, - extra_commands, pidfile, - rcvar, required_dirs, - required_files, required_vars, - argument_cmd, - argument_precmd. - argument_postcmd.
-

Call rc_trace to indicate that - file is to be run.

-

However, if is_verified - file fails, just return.

-

DebugOn will be called with tags - derived from name and rc_arg - to enable tracing if any of those tags appear in - DEBUG_SH.

-

run_rc_script executes - file unless:

-
    -
  1. file ends in .sh and - lives in /etc/rc.d.
    2. -
  2. file appears to be a backup or scratch file - (e.g., with a suffix of ~, - #, .OLD, - ,v, or .orig).
    3. -
  3. file is not executable.
    4. -
-
-
- [options] file ...
-
Call run_rc_script for each - file, unless it is already recorded as having been - run. -

The options are:

-
-
- arg
-
Pass arg to - run_rc_script, default is - _boot set by rc(8).
-
- break
-
Stop processing if any file matches any - break
-
-
-
- file ...
-
Used by sdot when - mac_veriexec(4) is active and file - is not verified. -

This function limits the input from file - to simple variable assignments with any non-alphanumeric characters - replaced with ‘_’.

-
-
- file ...
-
For reading in configuration files. Skip files that do not exist or are - empty. Try using vdot and if that fails (the file - is unverified) fall back to using safe_dot.
-
- [-n] message
-
Display a start message to stdout. It should be used - instead of echo(1). The display of this output can be - turned off if the rc.conf(5) variable - rc_startmsgs is set to - “NO”.
-
- [always]
-
Prevent booting to multiuser mode. If the autoboot - variable is set to ‘yes’ (see - rc(8) to learn more about - autoboot), or checkyesno - always indicates a truth value, then a - SIGTERM signal is sent to the parent process, - which is assumed to be rc(8). Otherwise, the shell exits - with a non-zero status.
-
- file ...
-
For reading in only verified files. -

Ensure shell verify option is on. This - option is only meaningful when mac_veriexec(4) is - active, otherwise this function is effectively the same as - dot.

-

Read in each file if it exists and - is_verfied file is - successful, otherwise set return code to 80 (EAUTH).

-

Restore previous state of the verify - option.

-
-
- [pid ...]
-
Wait until all of the provided pids do not exist any - more, printing the list of outstanding pids every - two seconds.
-
- message
-
Display a warning message to stderr and log it to - the system log using logger(1). The warning message - consists of the script name (from $0), followed by - “: WARNING: ”, and then - message.
-
-
-
-

-
-
/etc/rc.subr
-
The rc.subr file resides in - /etc.
-
-
-
-

-

rc.conf(5), debug.sh(8), - rc(8)

-
-
-

-

The rc.subr script appeared in - NetBSD 1.3. The rc.d(8) support - functions appeared in NetBSD 1.5. The - rc.subr script first appeared in - FreeBSD 5.0.

-
-
- - - - - -
October 23, 2024FreeBSD 15.0
diff --git a/static/freebsd/man8/rescue.8 3.html b/static/freebsd/man8/rescue.8 3.html deleted file mode 100644 index 898dc3a7..00000000 --- a/static/freebsd/man8/rescue.8 3.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - -
RESCUE(8)System Manager's ManualRESCUE(8)
-
-
-

-

rescue — rescue - utilities in /rescue

-
-
-

-

The /rescue directory contains a - collection of common utilities intended for use in recovering a badly - damaged system. With the transition to a dynamically-linked root beginning - with FreeBSD 5.2, there is a real possibility that - the standard tools in /bin and - /sbin may become non-functional due to a failed - upgrade or a disk error. The tools in /rescue are - statically linked and should therefore be more resistant to damage. However, - being statically linked, the tools in /rescue are - also less functional than the standard utilities. In particular, they do not - have full use of the locale, pam(3), and nsswitch - libraries.

-

If your system fails to boot, and it shows a prompt similar - to:

-

-
Enter full pathname of shell or - RETURN for /bin/sh:
-

the first thing to try running is the standard shell, - /bin/sh. If that fails, try running - /rescue/sh, which is the - rescue shell. To repair the system, the root - partition must first be remounted read-write. This can be done with the - following mount(8) command:

-

-
/rescue/mount -uw /
-

The next step is to double-check the contents of - /bin, /sbin, and - /usr/lib, possibly mounting a - FreeBSD rescue or “live file system” - CD-ROM and copying files from there. Once it is possible to successfully run - /bin/sh, /bin/ls, and other - standard utilities, try rebooting back into the standard system.

-

The /rescue tools are compiled using - crunchgen(1), which makes them considerably more compact - than the standard utilities. To build a FreeBSD - system where space is critical, /rescue can be used - as a replacement for the standard /bin and - /sbin directories; simply change - /bin and /sbin to be - symbolic links pointing to /rescue. Since - /rescue is statically linked, it should also be - possible to dispense with much of /usr/lib in such - an environment.

-

In contrast to its predecessor /stand, - /rescue is updated during normal - FreeBSD source and binary upgrades.

-
-
-

-
-
/rescue
-
Root of the rescue hierarchy.
-
-
-
-

-

crunchgen(1), crash(8)

-
-
-

-

The rescue utilities first appeared in - FreeBSD 5.2.

-
-
-

-

The rescue system was written by - Tim Kientzle - <kientzle@FreeBSD.org>, - based on ideas taken from NetBSD. This manual page - was written by Simon L. Nielsen - <simon@FreeBSD.org>, - based on text by Tim Kientzle - <kientzle@FreeBSD.org>.

-
-
-

-

Most of the rescue tools work even in a - fairly crippled system. The most egregious exception is the - rescue version of vi(1), which - currently requires that /usr be mounted so that it - can access the termcap(5) files. Hopefully, a failsafe - termcap(3) entry will eventually be added into the - ncurses(3) library, so that - /rescue/vi can be used even in a system where - /usr cannot immediately be mounted. In the meantime, - the rescue version of the ed(1) - editor can be used from /rescue/ed if you need to - edit files, but cannot mount /usr.

-
-
- - - - - -
June 30, 2022FreeBSD 15.0
diff --git a/static/freebsd/man8/uefi.8 3.html b/static/freebsd/man8/uefi.8 3.html deleted file mode 100644 index 05f980b1..00000000 --- a/static/freebsd/man8/uefi.8 3.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - -
UEFI(8)System Manager's ManualUEFI(8)
-
-
-

-

UEFI — Unified - Extensible Firmware Interface bootstrapping procedures

-
-
-

-

The UEFI Unified Extensible Firmware - Interface provides boot- and run-time services to operating systems. - UEFI is a replacement for the legacy BIOS on the - i386 and amd64 CPU architectures, and is also used on arm, arm64 and riscv - architectures.

-

The UEFI specification is the successor to the Extensible Firmware - Interface (EFI) specification. The terms UEFI and EFI are often used - interchangeably.

-

The UEFI boot process loads system - bootstrap code located in an EFI System Partition (ESP). The ESP is a GPT or - MBR partition with a specific identifier that contains an - msdosfs(4) FAT file system with a specified file - hierarchy.

- - - - - - - - - - - - - -
GPTC12A7328-F81F-11D2-BA4B-00A0C93EC93B
MBR0xEF
-

The UEFI boot process proceeds as - follows:

-
    -
  1. UEFI firmware runs at power up and searches for an - OS loader in the EFI system partition. The path to the loader may be set - by an EFI environment variable managed by efibootmgr(8). - If not set, an architecture-specific default is used. - - - - - - - - - - - - - - - - - - - - - - - - - -
    amd64/EFI/BOOT/BOOTX64.EFI
    arm/EFI/BOOT/BOOTARM.EFI
    arm64/EFI/BOOT/BOOTAA64.EFI
    i386/EFI/BOOT/BOOTIA32.EFI
    riscv/EFI/BOOT/BOOTRISCV64.EFI
    -

    The default UEFI boot configuration - for FreeBSD installs - loader.efi in the default path.

    -
    2. -
  2. loader.efi reads boot configuration from - /boot.config or - /boot/config.
    3. -
  3. loader.efi loads and boots the kernel, as - described in loader.efi(8).
    4. -
-

The vt(4) system console is automatically - selected when booting via UEFI.

-
-
-

-

UEFI bootstrap

-
-
/boot/loader.efi
-
Final stage bootstrap
-
/boot/kernel/kernel
-
Default kernel
-
/boot/kernel.old/kernel
-
Typical non-default kernel (optional)
-
-
-
-

-

msdosfs(4), vt(4), - boot.config(5), boot(8), - efibootmgr(8), efidp(8), - efivar(8), gpart(8), - loader.efi(8), uefisign(8)

-
-
-

-

EFI boot support for the ia64 architecture first appeared in - FreeBSD 5.0. UEFI boot - support for amd64 first appeared in FreeBSD 10.1; - for arm64 in FreeBSD 11.0; for armv7 in - FreeBSD 12.0; and for riscv in - FreeBSD 13.0.

-
-
-

-

There is no support for 32-bit i386 booting via UEFI.

-
-
- - - - - -
August 31, 2023FreeBSD 15.0
diff --git a/static/freebsd/man8/yp.8 3.html b/static/freebsd/man8/yp.8 3.html deleted file mode 100644 index ad1fe51f..00000000 --- a/static/freebsd/man8/yp.8 3.html +++ /dev/null @@ -1,289 +0,0 @@ - - - - - - -
YP(8)System Manager's ManualYP(8)
-
-
-

-

yp — description - of the YP/NIS system

-
-
-

- - - - - -
yp
-
-
-

-

The YP subsystem allows network management - of passwd, group, netgroup, hosts, services, rpc, bootparams and ethers file - entries through the functions getpwent(3), - getgrent(3), getnetgrent(3), - gethostent(3), getnetent(3), - getrpcent(3), and ethers(3). The - bootparamd(8) daemon makes direct NIS library calls since - there are no functions in the standard C library for reading bootparams. NIS - support is enabled in nsswitch.conf(5).

-

The YP subsystem is started automatically - in /etc/rc if it has been initialized in - /etc/rc.conf and if the directory - /var/yp exists (which it does in the default - distribution). The default NIS domain must also be set with the - domainname(1) command, which will happen automatically at - system startup if it is specified in - /etc/rc.conf.

-

NIS is an RPC-based client/server system that allows a group of - machines within an NIS domain to share a common set of configuration files. - This permits a system administrator to set up NIS client systems with only - minimal configuration data and add, remove or modify configuration data from - a single location.

-

The canonical copies of all NIS information are stored - on a single machine called the NIS - . The - databases used to store the information are called NIS - . In - FreeBSD, these maps are stored in - /var/yp/⟨domainname⟩ - where ⟨domainname⟩ is the name of the - NIS domain being served. A single NIS server can support several domains at - once, therefore it is possible to have several such directories, one for - each supported domain. Each domain will have its own independent set of - maps.

-

In FreeBSD, the NIS maps are Berkeley DB - hashed database files (the same format used for the - passwd(5) database files). Other operating systems that - support NIS use old-style ndbm databases instead - (largely because Sun Microsystems originally based their NIS implementation - on ndbm, and other vendors have simply licensed - Sun's code rather than design their own implementation with a different - database format). On these systems, the databases are generally split into - .dir and .pag files which - the ndbm code uses to hold separate parts of the - hash database. The Berkeley DB hash method instead uses a single file for - both pieces of information. This means that while you may have - passwd.byname.dir and - passwd.byname.pag files on other operating systems - (both of which are really parts of the same map), - FreeBSD will have only one file called - passwd.byname. The difference in format is not - significant: only the NIS server, ypserv(8), and related - tools need to know the database format of the NIS maps. Client NIS systems - receive all NIS data in ASCII form.

-

There are three main types of NIS systems:

-
    -
  1. NIS clients, which query NIS servers for information.
    2. -
  2. NIS master servers, which maintain the canonical copies of all NIS - maps.
    3. -
  3. NIS slave servers, which maintain backup copies of NIS maps that are - periodically updated by the master.
    4. -
-

A NIS client establishes what is called a - to a - particular NIS server using the ypbind(8) daemon. The - ypbind(8) utility checks the system's default domain (as - set by the domainname(1) command) and begins broadcasting - RPC requests on the local network. These requests specify the name of the - domain for which ypbind(8) is attempting to establish a - binding. If a server that has been configured to serve the requested domain - receives one of the broadcasts, it will respond to - ypbind(8), which will record the server's address. If - there are several servers available (a master and several slaves, for - example), ypbind(8) will use the address of the first one - to respond. From that point on, the client system will direct all of its NIS - requests to that server. The ypbind(8) utility will - occasionally “ping” the server to make sure it is still up and - running. If it fails to receive a reply to one of its pings within a - reasonable amount of time, ypbind(8) will mark the domain - as unbound and begin broadcasting again in the hopes of locating another - server.

-

NIS master and slave servers handle all NIS requests with the - ypserv(8) daemon. The ypserv(8) utility - is responsible for receiving incoming requests from NIS clients, translating - the requested domain and map name to a path to the corresponding database - file and transmitting data from the database back to the client. There is a - specific set of requests that ypserv(8) is designed to - handle, most of which are implemented as functions within the standard C - library:

-
-
()
-
check the creation date of a particular map
-
()
-
obtain the name of the NIS master server for a given map/domain
-
()
-
lookup the data corresponding to a given in key in a particular - map/domain
-
()
-
obtain the first key/data pair in a particular map/domain
-
()
-
pass ypserv(8) a key in a particular map/domain and have - it return the key/data pair immediately following it (the functions - yp_first() and yp_next() - can be used to do a sequential search of an NIS map)
-
()
-
retrieve the entire contents of a map
-
-

There are a few other requests which ypserv(8) - is capable of handling (i.e., acknowledge whether or not you can handle a - particular domain (YPPROC_DOMAIN), or acknowledge - only if you can handle the domain and be silent otherwise - (YPPROC_DOMAIN_NONACK)) but these requests are - usually generated only by ypbind(8) and are not meant to - be used by standard utilities.

-

On networks with a large number of hosts, it is often a good idea - to use a master server and several slaves rather than just a single master - server. A slave server provides the exact same information as a master - server: whenever the maps on the master server are updated, the new data - should be propagated to the slave systems using the - yppush(8) command. The NIS - Makefile (/var/yp/Makefile) - will do this automatically if the administrator creates - /var/yp/Makefile.local and empties the - NOPUSH variable:

-
-
NOPUSH=
-
-

(NOPUSH is set to true by default because - the default configuration is for a small network with only one NIS server). - The yppush(8) command will initiate a transaction between - the master and slave during which the slave will transfer the specified maps - from the master server using ypxfr(8). (The slave server - calls ypxfr(8) automatically from within - ypserv(8); therefore it is not usually necessary for the - administrator to use it directly. It can be run manually if desired, - however.) Maintaining slave servers helps improve NIS performance on large - networks by:

-
    -
  • Providing backup services in the event that the NIS master crashes or - becomes unreachable
    • -
  • Spreading the client load out over several machines instead of causing the - master to become overloaded
    • -
  • Allowing a single NIS domain to extend beyond a local network (the - ypbind(8) daemon might not be able to locate a server - automatically if it resides on a network outside the reach of its - broadcasts. It is possible to force ypbind(8) to bind to - a particular server with ypset(8) but this is sometimes - inconvenient. This problem can be avoided simply by placing a slave server - on the local network.)
    • -
-

The FreeBSD - ypserv(8) is specially designed to provide enhanced - security (compared to other NIS implementations) when used exclusively with - FreeBSD client systems. The - FreeBSD password database system (which is derived - directly from 4.4BSD) includes support for - . - The standard password database does not contain users' encrypted passwords: - these are instead stored (along with other information) in a separate - database which is accessible only by the super-user. If the encrypted - password database were made available as an NIS map, this security feature - would be totally disabled, since any user is allowed to retrieve NIS - data.

-

To help prevent this, FreeBSD's NIS server - handles the shadow password maps - (master.passwd.byname, - master.passwd.byuid, - shadow.byname and - shadow.byuid) in a special way: the server will only - provide access to these maps in response to requests that originate on - privileged ports. Since only the super-user is allowed to bind to a - privileged port, the server assumes that all such requests come from - privileged users. All other requests are denied: requests from - non-privileged ports will receive only an error code from the server. - Additionally, FreeBSD's ypserv(8) - includes support for Wietse Venema's tcp wrapper - package; with tcp wrapper support enabled, the administrator can configure - ypserv(8) to respond only to selected client machines.

-

While these enhancements provide better security than stock NIS, - they are by no means 100% effective. It is still possible for someone with - access to your network to spoof the server into disclosing the shadow - password maps.

-

On the client side, FreeBSD's - getpwent(3) functions will automatically search for the - master.passwd maps and use them if they exist. If - they do, they will be used, and all fields in these special maps (class, - password age and account expiration) will be decoded. If they are not found, - the standard passwd maps will be used instead.

-
-
-

-

When using a - non-FreeBSD NIS server for - passwd(5) files, it is unlikely that the default MD5-based - format that FreeBSD uses for passwords will be - accepted by it. If this is the case, the value of the - passwd_format setting in - login.conf(5) should be changed to - "des" for compatibility.

-

Some systems, such as SunOS 4.x, need NIS to be running in order - for their hostname resolution functions - (gethostbyname(), - gethostbyaddr(), etc.) to work properly. On these - systems, ypserv(8) performs DNS lookups when asked to - return information about a host that does not exist in its - hosts.byname or hosts.byaddr - maps. FreeBSD's resolver uses DNS by default (it can - be made to use NIS, if desired), therefore its NIS server does not do DNS - lookups by default. However, ypserv(8) can be made to - perform DNS lookups if it is started with a special flag. It can also be - made to register itself as an NIS v1 server in order to placate certain - systems that insist on the presence of a v1 server - (FreeBSD uses only NIS v2, but many other systems, - including SunOS 4.x, search for both a v1 and v2 server when binding). - FreeBSD's ypserv(8) does not - actually handle NIS v1 requests, but this “kludge mode” is - useful for silencing stubborn systems that search for both a v1 and v2 - server.

-

(Please see the ypserv(8) manual page for a - detailed description of these special features and flags.)

-
-
-

-

domainname(1), ypcat(1), - ypmatch(1), ypwhich(1), - nsswitch.conf(5), yp_mkdb(8), - ypbind(8), ypinit(8), - yppoll(8), yppush(8), - ypserv(8), ypset(8), - ypxfr(8)

-
-
-

-

The YP subsystem was written from the - ground up by Theo de Raadt to be compatible to Sun's - implementation. Bug fixes, improvements and NIS server support were later - added by Bill Paul. The server-side code was - originally written by Peter Eriksson and - Tobias Reber and is subject to the GNU Public - License. No Sun code was referenced.

-
-
-

-

While FreeBSD now has both NIS client and - server capabilities, it does not yet have support for - ypupdated(8) or the yp_update() - function. Both of these require secure RPC, which - FreeBSD does not support yet either.

-

The getservent(3) and - getprotoent(3) functions do not yet have NIS support. - Fortunately, these files do not need to be updated that often.

-

Many more manual pages should be written, especially - ypclnt(3). For the time being, seek out a local Sun - machine and read the manuals for there.

-

Neither Sun nor this author have found a clean way to handle the - problems that occur when ypbind cannot find its server upon bootup.

-
-
- - - - - -
December 14, 2011FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_ISLOCKED.9 4.html b/static/freebsd/man9/BUF_ISLOCKED.9 4.html deleted file mode 100644 index d2ed0b6a..00000000 --- a/static/freebsd/man9/BUF_ISLOCKED.9 4.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
BUF_ISLOCKED(9)Kernel Developer's ManualBUF_ISLOCKED(9)
-
-
-

-

BUF_ISLOCKED — - returns the state of the lock linked to the - buffer

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

int -
- BUF_ISLOCKED(struct - buf *bp);

-
-
-

-

The - () - function returns the status of the lock linked to the buffer in relation to - curthread.

-

It can return:

-
-
-
An exclusive lock is held by curthread.
-
-
An exclusive lock is held by someone other than curthread.
-
-
A shared lock is held.
-
-
The lock is not held by anyone.
-
-
-
-

-

buf(9), BUF_LOCK(9), - BUF_UNLOCK(9), lockmgr(9)

-
-
-

-

This manual page was written by Attilio - Rao - <attilio@FreeBSD.org>.

-
-
- - - - - -
September 26, 2025FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_LOCK.9 4.html b/static/freebsd/man9/BUF_LOCK.9 4.html deleted file mode 100644 index 6876648a..00000000 --- a/static/freebsd/man9/BUF_LOCK.9 4.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - -
BUF_LOCK(9)Kernel Developer's ManualBUF_LOCK(9)
-
-
-

-

BUF_LOCK — locks a - buffer

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

int -
- BUF_LOCK(struct - buf *bp, int - locktype);

-
-
-

-

The - () - function locks the given buffer. If the lock is already held this call will - block until it can acquire the lock unless LK_NOWAIT - is set.

-

Its arguments are:

-
-
bp
-
The buffer to lock.
-
locktype
-
Flags controlling the type of lock. See lockmgr(9) for - details.
-
-
-
-

-

A value of 0 is returned upon success. See - lockmgr(9) for information on non-zero return values.

-
-
-

-

buf(9), BUF_TIMELOCK(9), - BUF_UNLOCK(9), lockmgr(9)

-
-
-

-

This manual page was written by Chad David - <davidc@acns.ab.ca>.

-
-
- - - - - -
July 9, 2001FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_LOCKFREE.9 4.html b/static/freebsd/man9/BUF_LOCKFREE.9 4.html deleted file mode 100644 index 5d55fe83..00000000 --- a/static/freebsd/man9/BUF_LOCKFREE.9 4.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - -
BUF_LOCKFREE(9)Kernel Developer's ManualBUF_LOCKFREE(9)
-
-
-

-

BUF_LOCKFREE — - destroys a buffer's lock

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

void -
- BUF_LOCKFREE(struct - buf *bp);

-
-
-

-

The - () - macro destroys the buffer lock. The lock must not be held when this macro is - called or a panic will result.

-

Its argument is:

-
-
bp
-
The buffer whose lock is to be destroyed.
-
-
-
-

-

buf(9), BUF_LOCK(9), - BUF_TIMELOCK(9), BUF_UNLOCK(9), - lockdestroy(9)

-
-
-

-

This manual page was written by Chad David - <davidc@acns.ab.ca>.

-
-
- - - - - -
July 9, 2001FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_LOCKINIT.9 4.html b/static/freebsd/man9/BUF_LOCKINIT.9 4.html deleted file mode 100644 index 1365919a..00000000 --- a/static/freebsd/man9/BUF_LOCKINIT.9 4.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - -
BUF_LOCKINIT(9)Kernel Developer's ManualBUF_LOCKINIT(9)
-
-
-

-

BUF_LOCKINIT — - initializes a buffer lock

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

void -
- BUF_LOCKINIT(struct - buf *bp);

-
-
-

-

The - () - macro initializes a buffer lock.

-

Its argument is:

-
-
bp
-
The buffer whose lock it to be initialized.
-
-
-
-

-

buf(9), BUF_LOCK(9), - BUF_TIMELOCK(9), BUF_UNLOCK(9), - lockinit(9), lockmgr(9)

-
-
-

-

This manual page was written by Chad David - <davidc@acns.ab.ca>.

-
-
- - - - - -
January 6, 2005FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_RECURSED.9 4.html b/static/freebsd/man9/BUF_RECURSED.9 4.html deleted file mode 100644 index 753ddf80..00000000 --- a/static/freebsd/man9/BUF_RECURSED.9 4.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - -
BUF_RECURSED(9)Kernel Developer's ManualBUF_RECURSED(9)
-
-
-

-

BUF_RECURSED — - checks if the lock linked to the buffer is - recursed

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

int -
- BUF_RECURSED(struct - buf *bp);

-
-
-

-

The - () - function checks if the lock linked to the given buffer is recursed and - returns 1 if the condition is true, 0 otherwise.

-

Its argument is:

-
-
bp
-
The buffer linked to the lock. See lockmgr_recursed(9) - for details.
-
-
-
-

-

buf(9), BUF_LOCK(9), - BUF_UNLOCK(9), lockmgr(9)

-
-
-

-

This manual page was written by Attilio - Rao - <attilio@FreeBSD.org>.

-
-
- - - - - -
January 22, 2008FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_TIMELOCK.9 4.html b/static/freebsd/man9/BUF_TIMELOCK.9 4.html deleted file mode 100644 index 24b3f3a9..00000000 --- a/static/freebsd/man9/BUF_TIMELOCK.9 4.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
BUF_TIMELOCK(9)Kernel Developer's ManualBUF_TIMELOCK(9)
-
-
-

-

BUF_TIMELOCK — - locks a buffer

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

int -
- BUF_TIMELOCK(struct - buf *bp, int - locktype, char - *wmesg, int catch, - int timo);

-
-
-

-

The - () - function locks the given buffer, and limits the amount of time it will sleep - to timo and OR's catch into the - sleep's priority. wmesg is the wmesg used in the - sleep.

-

Its arguments are:

-
-
bp
-
The buffer to lock.
-
locktype
-
Flags controlling the type of lock. See lockmgr(9) for - details.
-
wmesg
-
The wmesg used in any sleeps while acquiring the lock.
-
catch
-
Priority OR'd into the sleep's priority.
-
timo
-
The timeout for any sleeps encountered during the lock.
-
-
-
-

-

A value of 0 is returned on success. See - lockmgr(9) for details on non-zero return values.

-
-
-

-

buf(9), BUF_LOCK(9), - BUF_UNLOCK(9), lockmgr(9)

-
-
-

-

This manual page was written by Chad David - <davidc@acns.ab.ca>.

-
-
- - - - - -
July 9, 2001FreeBSD 15.0
diff --git a/static/freebsd/man9/BUF_UNLOCK.9 4.html b/static/freebsd/man9/BUF_UNLOCK.9 4.html deleted file mode 100644 index 370d0fbe..00000000 --- a/static/freebsd/man9/BUF_UNLOCK.9 4.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - -
BUF_UNLOCK(9)Kernel Developer's ManualBUF_UNLOCK(9)
-
-
-

-

BUF_UNLOCK — - unlocks a locked buffer

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h> -
- #include <sys/uio.h> -
- #include <sys/bio.h> -
- #include <sys/buf.h>

-

void -
- BUF_UNLOCK(struct - buf *bp);

-
-
-

-

The - () - function unlocks a buffer that was previously locked with - () - or - ().

-

Its argument is:

-
-
bp
-
The buffer to unlock. The buffer must already be locked.
-
-
-
-

-

buf(9), BUF_LOCK(9), - BUF_TIMELOCK(9), lockmgr(9)

-
-
-

-

This manual page was written by Chad David - <davidc@acns.ab.ca>.

-
-
- - - - - -
July 9, 2001FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_ADD_CHILD.9 3.html b/static/freebsd/man9/BUS_ADD_CHILD.9 3.html deleted file mode 100644 index c64b8b05..00000000 --- a/static/freebsd/man9/BUS_ADD_CHILD.9 3.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - -
BUS_ADD_CHILD(9)Kernel Developer's ManualBUS_ADD_CHILD(9)
-
-
-

-

BUS_ADD_CHILD — - add a device node to the tree with a given - priority

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

device_t -
- BUS_ADD_CHILD(device_t - dev, int order, - const char *name, - int unit);

-
-
-

-

The - () - method is used by the driver identify routine to add devices to the tree. It - can also be used to add children to buses that implement this routine in - other contexts, although the behavior is bus specific. Please see - device_add_child(9) for more details. The interface is the - same as device_add_child(9) however, the bus' - BUS_ADD_CHILD() is called.

-

Buses implementing - () - should insert the device into the tree using - device_add_child(9) before adding things such as their own - ivars and resource lists to the device. - BUS_ADD_CHILD() is not called by - device_add_child(9). - BUS_ADD_CHILD() instead calls - device_add_child(9).

-

A panic will result when called for a bus - that does not implement - (). - Some buses require a special bus-specific routine to be called instead of - BUS_ADD_CHILD().

-
-
-

-

The BUS_ADD_CHILD() method returns - device_t added to the tree, or - NULL to indicate failure.

-
-
-

-

device(9), - device_add_child(9), driver(9)

-
-
-

-

This manual page was written by M. Warner - Losh.

-
-
- - - - - -
April 8, 2018FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_BIND_INTR.9 3.html b/static/freebsd/man9/BUS_BIND_INTR.9 3.html deleted file mode 100644 index f22ffda2..00000000 --- a/static/freebsd/man9/BUS_BIND_INTR.9 3.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - -
BUS_BIND_INTR(9)Kernel Developer's ManualBUS_BIND_INTR(9)
-
-
-

-

BUS_BIND_INTR, - bus_bind_intr — bind an - interrupt resource to a specific CPU

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

int -
- BUS_BIND_INTR(device_t dev, - device_t child, struct resource - *irq, int cpu);

-

int -
- bus_bind_intr(device_t - dev, struct resource - *irq, int cpu);

-
-
-

-

The - () - method allows an interrupt resource to be pinned to a specific CPU. The - interrupt resource must have an interrupt handler attached via - BUS_SETUP_INTR(9). The cpu parameter - corresponds to the ID of a valid CPU in the system. Binding an interrupt - restricts the cpuset(2) of any associated interrupt - threads to only include the specified CPU. It may also direct the low-level - interrupt handling of the interrupt to the specified CPU as well, but this - behavior is platform-dependent. If the value NOCPU - is used for cpu, then the interrupt will be - “unbound” which restores any associated interrupt threads back - to the default cpuset.

-

Non-sleepable locks such as mutexes should not be held across - calls to these functions.

-

The - () - function is a simple wrapper around - BUS_BIND_INTR().

-

Note that currently there is no attempt made - to arbitrate between multiple bind requests for the same interrupt from - either the same device or multiple devices. There is also no arbitration - between interrupt binding requests submitted by userland via - cpuset(2) and - (). - The most recent binding request is the one that will be in effect.

-
-
-

-

Zero is returned on success, otherwise an appropriate error is - returned.

-
-
-

-

cpuset(2), BUS_SETUP_INTR(9), - device(9)

-
-
-

-

The BUS_BIND_INTR() method and - bus_bind_intr() functions first appeared in - FreeBSD 7.2.

-
-
- - - - - -
October 14, 2009FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_CHILD_DELETED.9 4.html b/static/freebsd/man9/BUS_CHILD_DELETED.9 4.html deleted file mode 100644 index 25f74dfd..00000000 --- a/static/freebsd/man9/BUS_CHILD_DELETED.9 4.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - -
BUS_CHILD_DELETED(9)Kernel Developer's ManualBUS_CHILD_DELETED(9)
-
-
-

-

BUS_CHILD_DELETED — - notify a bus device that a child is being - deleted

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

void -
- BUS_CHILD_DELETED(device_t - dev, device_t - child);

-
-
-

-

The - () - method is invoked by the new-bus framework when a device is deleted. A bus - driver can provide an implementation of this method to release bus-specific - resources associated with a device such as instance variables.

-
-
-

-

BUS_ADD_CHILD(9), - device(9)

-
-
-

-

The BUS_CHILD_DELETED() method first - appeared in FreeBSD 10.0.

-
-
- - - - - -
August 21, 2012FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_CHILD_DETACHED.9 4.html b/static/freebsd/man9/BUS_CHILD_DETACHED.9 4.html deleted file mode 100644 index 411252ab..00000000 --- a/static/freebsd/man9/BUS_CHILD_DETACHED.9 4.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - -
BUS_CHILD_DETACHED(9)Kernel Developer's ManualBUS_CHILD_DETACHED(9)
-
-
-

-

BUS_CHILD_DETACHED — - notify a bus device that a child was detached

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

void -
- BUS_CHILD_DETACHED(device_t - dev, device_t - child);

-
-
-

-

The - () - method is invoked by the new-bus framework after a device is detached or if - a driver's attach routine (see DEVICE_ATTACH(9)) fails. A - bus driver can provide an implementation of this method to reclaim any - resources allocated on behalf of the child or to cleanup state not properly - released by a DEVICE_DETACH(9) method.

-
-
-

-

device(9), - DEVICE_DETACH(9)

-
-
- - - - - -
January 9, 2025FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_CHILD_LOCATION.9 4.html b/static/freebsd/man9/BUS_CHILD_LOCATION.9 4.html deleted file mode 100644 index 64f10140..00000000 --- a/static/freebsd/man9/BUS_CHILD_LOCATION.9 4.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
BUS_CHILD_LOCATION(9)Kernel Developer's ManualBUS_CHILD_LOCATION(9)
-
-
-

-

BUS_CHILD_LOCATION — - obtain the location of a child on the bus.

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h> -
- #include <sys/sbuf.h>

-

void -
- BUS_CHILD_LOCATION(device_t - dev, device_t - child, struct sbuf - *sb);

-
-
-

-

The - () - method returns the location of the child device. - This location is a series of key=value pairs. The string must be formatted - as a space-separated list of key=value pairs. Names may only contain - alphanumeric characters, underscores ('_') and hyphens ('-'). Values can - contain any non-whitespace characters. Values containing whitespace can be - quoted with double quotes ('"'). Double quotes and backslashes in - quoted values can be escaped with backslashes ('´).

-

The location is defined as a series of characteristics of the - child device that can be used to locate that device - independent of what drivers are attached. Typically, these are slot numbers, - bus addresses, or some topology formation. Where possible, buses are - encouraged to provide locations that are stable from boot to boot and when - other devices are added or removed. A location is not dependent on the kind - of device at that location.

-
-
-

-

bus(9), device(9)

-
-
- - - - - -
April 22, 2021FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_CHILD_PNPINFO.9 3.html b/static/freebsd/man9/BUS_CHILD_PNPINFO.9 3.html deleted file mode 100644 index 1826608f..00000000 --- a/static/freebsd/man9/BUS_CHILD_PNPINFO.9 3.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - -
BUS_CHILD_PNPINFO(9)Kernel Developer's ManualBUS_CHILD_PNPINFO(9)
-
-
-

-

BUS_CHILD_PNPINFO — - obtain the plug and play information from a - device

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h> -
- #include <sys/sbuf.h>

-

void -
- BUS_CHILD_PNPINFO(device_t - dev, device_t - child, struct sbuf - *sb);

-
-
-

-

The - () - method returns the identifying information about the - child device. This information is called the plug - and play (pnp) details by some buses. This information is a series of - key=value pairs. The string must be formatted as a space-separated list of - key=value pairs. Names may only contain alphanumeric characters, underscores - ('_') and hyphens ('-'). Values can contain any non-whitespace characters. - Values containing whitespace can be quoted with double quotes ('"'). - Double quotes and backslashes in quoted values can be escaped with - backslashes ('´).

-

The pnpinfo is defined as a series of characteristics of the - child device that are independent of which drivers - are attached, but are used to allow drivers to claim a device. Typically, - plug and play information encodes who made the device, what the model number - is, and some generic details about the device. By convention, only the - generic information about the device that's used by drivers on that bus to - decide on accepting the device is reported. Other configuration information - (such as the cache burst size) needed for the operation of the device, but - that doesn't distinguish it broadly from other devices is not reported.

-
-
-

-

bus(9), device(9)

-
-
- - - - - -
April 22, 2021FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_CONFIG_INTR.9 3.html b/static/freebsd/man9/BUS_CONFIG_INTR.9 3.html deleted file mode 100644 index c14f7f36..00000000 --- a/static/freebsd/man9/BUS_CONFIG_INTR.9 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
BUS_CONFIG_INTR(9)Kernel Developer's ManualBUS_CONFIG_INTR(9)
-
-
-

-

BUS_CONFIG_INTR, - bus_config_intr — configure - interrupt polarity and trigger mode

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

int -
- BUS_CONFIG_INTR(device_t bus, - device_t dev, int irq, - enum intr_trigger trig, enum - intr_polarity pol);

-

int -
- bus_config_intr(device_t dev, - int irq, enum intr_trigger trig, - enum intr_polarity pol);

-
-
-

-

The - () - method allows bus or device drivers to provide interrupt polarity and - trigger mode to parent buses. This typically bubbles all the way up to the - root bus (e.g. nexus) where the necessary actions are taken to actually - program the hardware. Since the BUS_CONFIG_INTR() - method takes an interrupt number, it is assumed but not necessarily required - that it is called prior to BUS_SETUP_INTR(9).

-

The - () - function is a simple wrapper around - BUS_CONFIG_INTR().

-

The trig argument can be one of:

-
-
-
The interrupt trigger mode is standard for the bus to which the device is - attached.
-
-
The interrupt is edge triggered. This means that the interrupt is raised - by the rising edge of the signal on the interrupt line. The signal - typically reverts to the original state so as to cause a spike.
-
-
The interrupt is level triggered. This means that the interrupt is raised - when the signal on the interrupt line transitions and remains unchanged - after that until the interrupt has been serviced, after which the signal - transitions back.
-
-

The pol argument can be any one of:

-
-
-
The interrupt polarity is standard for the bus to which the device is - attached.
-
-
The interrupt is activated by a high voltage on the interrupt line.
-
-
The interrupt is activated by a low voltage on the interrupt line.
-
-
-
-

-

Zero is returned on success, otherwise an appropriate error is - returned.

-
-
-

-

BUS_SETUP_INTR(9), - BUS_TEARDOWN_INTR(9), device(9), - driver(9)

-
-
-

-

The BUS_CONFIG_INTR() method first - appeared in FreeBSD 5.2.

-
-
-

-

This manual page was written by Marcel - Moolenaar - <marcel@xcllnt.net>.

-
-
- - - - - -
January 16, 2025FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_DESCRIBE_INTR.9 3.html b/static/freebsd/man9/BUS_DESCRIBE_INTR.9 3.html deleted file mode 100644 index c5a7e073..00000000 --- a/static/freebsd/man9/BUS_DESCRIBE_INTR.9 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
BUS_DESCRIBE_INTR(9)Kernel Developer's ManualBUS_DESCRIBE_INTR(9)
-
-
-

-

BUS_DESCRIBE_INTR, - bus_describe_intr — - associate a description with an active interrupt - handler

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

int -
- BUS_DESCRIBE_INTR(device_t dev, - device_t child, struct resource - *irq, void *cookie, const char - *descr);

-

int -
- bus_describe_intr(device_t dev, - struct resource *irq, void - *cookie, const char *fmt, - ...);

-
-
-

-

The - () - method associates a description with an active interrupt handler. The - cookie parameter must be the value returned by a - successful call to BUS_SETUP_INTR(9) for the interrupt - irq.

-

The - () - function is a simple wrapper around - BUS_DESCRIBE_INTR(). As a convenience, - bus_describe_intr() allows the caller to use - printf(9) style formatting to build the description string - using fmt.

-

When an interrupt handler is established by - BUS_SETUP_INTR(9), the handler is named after the device - the handler is established for. This name is then used in various places - such as interrupt statistics displayed by systat(1) and - vmstat(8). For devices that use a single interrupt, the - device name is sufficiently unique to identify the interrupt handler. - However, for devices that use multiple interrupts it can be useful to - distinguish the interrupt handlers. When a description is set for an active - interrupt handler, a colon followed by the description is appended to the - device name to form the interrupt handler name.

-
-
-

-

Zero is returned on success, otherwise an appropriate error is - returned.

-
-
-

-

systat(1), vmstat(8), - BUS_SETUP_INTR(9), device(9), - printf(9)

-
-
-

-

The BUS_DESCRIBE_INTR() method and - bus_describe_intr() functions first appeared in - FreeBSD 8.1.

-
-
-

-

It is not currently possible to remove a description from an - active interrupt handler.

-
-
- - - - - -
December 9, 2015FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_GET_CPUS.9 3.html b/static/freebsd/man9/BUS_GET_CPUS.9 3.html deleted file mode 100644 index 26bb28ba..00000000 --- a/static/freebsd/man9/BUS_GET_CPUS.9 3.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -
BUS_GET_CPUS(9)Kernel Developer's ManualBUS_GET_CPUS(9)
-
-
-

-

BUS_GET_CPUS, - bus_get_cpus — request a set - of device-specific CPUs

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h> -
- #include <sys/cpuset.h>

-

int -
- BUS_GET_CPUS(device_t dev, - device_t child, enum cpu_sets - op, size_t setsize, cpuset_t - *cpuset);

-

int -
- bus_get_cpus(device_t dev, - enum cpu_sets op, size_t - setsize, cpuset_t *cpuset);

-
-
-

-

The - () - method queries the parent bus device for a set of device-specific CPUs. The - op argument specifies which set of CPUs to retrieve. - If successful, the requested set of CPUs are returned in - cpuset. The setsize argument - specifies the size in bytes of the set passed in - cpuset.

-

() - supports querying different types of CPU sets via the op - argument. Not all set types are supported for every device. If a set - type is not supported, BUS_GET_CPUS() fails with - EINVAL. These set types are supported:

-
-
-
The set of CPUs that are local to the device. If a device is closer to a - specific memory domain in a non-uniform memory architecture system (NUMA), - this will return the set of CPUs in that memory domain.
-
-
The preferred set of CPUs that this device should use for device - interrupts. This set type must be supported by all bus drivers.
-
-

The - () - function is a simple wrapper around - BUS_GET_CPUS().

-
-
-

-

Zero is returned on success, otherwise an appropriate error is - returned.

-
-
-

-

cpuset(2), BUS_BIND_INTR(9), - device(9)

-
-
-

-

The BUS_GET_CPUS() method and - bus_get_cpus() function first appeared in - FreeBSD 11.0.

-
-
- - - - - -
March 1, 2016FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_GET_PROPERTY.9 4.html b/static/freebsd/man9/BUS_GET_PROPERTY.9 4.html deleted file mode 100644 index 0186b0c3..00000000 --- a/static/freebsd/man9/BUS_GET_PROPERTY.9 4.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
BUS_GET_PROPERTY(9)Kernel Developer's ManualBUS_GET_PROPERTY(9)
-
-
-

-

BUS_GET_PROPERTY — - get child's specific property

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

ssize_t -
- BUS_GET_PROPERTY(device_t - dev, device_t - child, const char - *propname, void - *propvalue, size_t - size, - device_property_type_t - type);

-
-
-

-

The - () - method is called from driver code which wants to access a child's specific - data stored on the bus. A property has a name and an associated value. - Implementation shall copy to propvalue at most - size bytes.

-

() - supports different property types specified via the - type argument. The size is - guaranteed to be a multiple of the underlying property type. If a type is - not supported, BUS_GET_PROPERTY() shall return - -1.

-
-
-

-

If propvalue is NULL or - size is zero, the implementation shall return only the - size of the property.

-
-
-

-

The property size if successful, otherwise -1.

-
-
-

-

device(9), - device_get_property(9)

-
-
-

-

This manual page was written by Bartlomiej - Grzesik.

-
-
- - - - - -
February 18, 2022FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_HINTED_CHILD.9 4.html b/static/freebsd/man9/BUS_HINTED_CHILD.9 4.html deleted file mode 100644 index 14ab7284..00000000 --- a/static/freebsd/man9/BUS_HINTED_CHILD.9 4.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - -
BUS_HINTED_CHILD(9)Kernel Developer's ManualBUS_HINTED_CHILD(9)
-
-
-

-

BUS_HINTED_CHILD — - notify a bus device about a potential child device - identified by hints

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

void -
- BUS_HINTED_CHILD(device_t - dev, const char - *dname, int - dunit);

-
-
-

-

The - () - method is invoked by the bus_enumerate_hinted_children(9) - function for each set of named hints whose “at” hint matches - the bus device dev. Typically, this method should - determine if the set of hints for the given device name and unit - sufficiently describe a new device. If so, a new device should be added via - BUS_ADD_CHILD(9).

-
-
-

-

BUS_ADD_CHILD(9), - bus_enumerate_hinted_children(9), - device(9)

-
-
-

-

The BUS_HINTED_CHILD() method first - appeared in FreeBSD 6.2.

-
-
- - - - - -
February 5, 2025FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_NEW_PASS.9 4.html b/static/freebsd/man9/BUS_NEW_PASS.9 4.html deleted file mode 100644 index 9868eff6..00000000 --- a/static/freebsd/man9/BUS_NEW_PASS.9 4.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
BUS_NEW_PASS(9)Kernel Developer's ManualBUS_NEW_PASS(9)
-
-
-

-

BUS_NEW_PASS — - notify a bus that the pass level has been - changed

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

void -
- BUS_NEW_PASS(device_t - dev);

-
-
-

-

The - () - method is called on each bus device to rescan the device tree when the pass - level has been changed. This method is responsible for invoking - BUS_NEW_PASS on child bus devices to propagate the - rescan to child devices. It is also responsible for reprobing any unattached - child devices and allowing drivers for the current pass to identify new - children. A default implementation is provided by - bus_generic_new_pass(9).

-
-
-

-

bus_generic_new_pass(9), - bus_set_pass(9), device(9)

-
-
- - - - - -
June 8, 2009FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_PRINT_CHILD.9 4.html b/static/freebsd/man9/BUS_PRINT_CHILD.9 4.html deleted file mode 100644 index f7c10d60..00000000 --- a/static/freebsd/man9/BUS_PRINT_CHILD.9 4.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - -
BUS_PRINT_CHILD(9)Kernel Developer's ManualBUS_PRINT_CHILD(9)
-
-
-

-

BUS_PRINT_CHILD — - print information about a device

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

int -
- BUS_PRINT_CHILD(device_t - dev, device_t - child);

-
-
-

-

The - () - method is called from system code which prints out a description of a - device. It should describe the attachment that the child has with the - parent. For instance the TurboLaser bus prints which node the device is - attached to. Please see bus_generic_print_child(9) for - more information regarding the proper formatting of the messages printed by - BUS_PRINT_CHILD().

-
-
-

-

The number of characters output.

-
-
-

-

device(9), driver(9)

-
-
-

-

This manual page was written by Doug - Rabson.

-
-
- - - - - -
January 6, 2005FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_READ_IVAR.9 4.html b/static/freebsd/man9/BUS_READ_IVAR.9 4.html deleted file mode 100644 index 85910507..00000000 --- a/static/freebsd/man9/BUS_READ_IVAR.9 4.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - -
BUS_READ_IVAR(9)Kernel Developer's ManualBUS_READ_IVAR(9)
-
-
-

-

BUS_READ_IVAR, - BUS_WRITE_IVAR — manipulate - bus-specific device instance variables

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

int -
- BUS_READ_IVAR(device_t - dev, device_t - child, int index, - uintptr_t *result);

-

int -
- BUS_WRITE_IVAR(device_t - dev, device_t - child, int index, - uintptr_t value);

-
-
-

-

These two methods manage a bus specific set of instance variables - of a child device. The intention is that each different type of bus defines - a set of appropriate instance variables (such as ports and irqs for ISA bus - etc.)

-

This information could be given to the child device as a struct - but that makes it hard for a bus to add or remove variables without forcing - an edit and recompile for all drivers which may not be possible for vendor - supplied binary drivers.

-
-
-

-

Zero is returned on success, otherwise an appropriate error is - returned.

-
-
-

-

device(9), driver(9)

-
-
-

-

This manual page was written by Doug - Rabson.

-
-
- - - - - -
June 16, 1998FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_RESCAN.9 4.html b/static/freebsd/man9/BUS_RESCAN.9 4.html deleted file mode 100644 index 473357cb..00000000 --- a/static/freebsd/man9/BUS_RESCAN.9 4.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - -
BUS_RESCAN(9)Kernel Developer's ManualBUS_RESCAN(9)
-
-
-

-

BUS_RESCAN — - rescan a bus checking for devices that have been added or - removed

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

void -
- BUS_RESCAN(device_t - dev);

-
-
-

-

The - () - method is called to request a rescan of the child devices on a bus device. - The method should add any devices that have been added since the previous - scan and remove devices that have been removed. This method is not required - to re-examine existing devices to determine if their properties have - changed. This method is also not required to propagate the rescan request to - child devices.

-
-
-

-

device(9)

-
-
- - - - - -
April 27, 2016FreeBSD 15.0
diff --git a/static/freebsd/man9/BUS_SETUP_INTR.9 3.html b/static/freebsd/man9/BUS_SETUP_INTR.9 3.html deleted file mode 100644 index f22418fb..00000000 --- a/static/freebsd/man9/BUS_SETUP_INTR.9 3.html +++ /dev/null @@ -1,169 +0,0 @@ - - - - - - -
BUS_SETUP_INTR(9)Kernel Developer's ManualBUS_SETUP_INTR(9)
-
-
-

-

BUS_SETUP_INTR, - bus_setup_intr, - BUS_TEARDOWN_INTR, - bus_teardown_intr — create, - attach and teardown an interrupt handler

-
-
-

-

#include - <sys/param.h> -
- #include <sys/bus.h>

-

int -
- BUS_SETUP_INTR(device_t dev, - device_t child, struct resource - *irq, int flags, driver_filter_t - *filter, driver_intr_t *ithread, - void *arg, void **cookiep);

-

int -
- bus_setup_intr(device_t dev, - struct resource *r, int flags, - driver_filter_t filter, driver_intr_t - ithread, void *arg, void - **cookiep);

-

int -
- BUS_TEARDOWN_INTR(device_t dev, - device_t child, struct resource - *irq, void *cookiep);

-

int -
- bus_teardown_intr(device_t - dev, struct resource - *r, void - *cookiep);

-
-
-

-

The - () - method will create and attach an interrupt handler to an interrupt - previously allocated by the resource manager's - BUS_ALLOC_RESOURCE(9) method. The - flags are found in - <sys/bus.h>, and give the - broad category of interrupt. The flags also tell the - interrupt handlers about certain device driver characteristics. - INTR_EXCL marks the handler as being an exclusive - handler for this interrupt. INTR_MPSAFE tells the - scheduler that the interrupt handler is well behaved in a preemptive - environment (``SMP safe''), and does not need to be protected by the ``Giant - Lock'' mutex. INTR_ENTROPY marks the interrupt as - being a good source of entropy - this may be used by the entropy device - /dev/random.

-

To define a time-critical handler that will not execute any - potentially blocking operation, use the filter - argument. See the Filter Routines - section below for information on writing a filter. Otherwise, use the - ithread argument. The defined handler will be called - with the value arg as its only argument. See the - ithread Routines section below - for more information on writing an interrupt handler.

-

The cookiep argument - is a pointer to a void * that - () - will write a cookie for the parent bus' use to if it is successful in - establishing an interrupt. Driver writers may assume that this cookie will - be non-zero. The nexus driver will write 0 on failure to - cookiep.

-

The interrupt handler will be detached by - (). - The cookie needs to be passed to BUS_TEARDOWN_INTR() - in order to tear down the correct interrupt handler. Once - BUS_TEARDOWN_INTR() returns, it is guaranteed that - the interrupt function is not active and will no longer be called.

-

Mutexes are not allowed to be held across calls to these - functions.

-
-

-

A filter runs in primary interrupt context. In this context, - normal mutexes cannot be used. Only the spin lock version of these can be - used (specified by passing MTX_SPIN to - () - when initializing the mutex). wakeup(9) and similar - routines can be called. Atomic operations from - machine/atomic may be used. Reads and writes to - hardware through bus_space(9) may be used. PCI - configuration registers may be read and written. All other kernel interfaces - cannot be used.

-

In this restricted environment, care must be taken to account for - all races. A careful analysis of races should be done as well. It is - generally cheaper to take an extra interrupt, for example, than to protect - variables with spinlocks. Read, modify, write cycles of hardware registers - need to be carefully analyzed if other threads are accessing the same - registers.

-

Generally, a filter routine will use one of two strategies. The - first strategy is to simply mask the interrupt in hardware and allow the - ithread routine to read the state from the hardware - and then reenable interrupts. The ithread also - acknowledges the interrupt before re-enabling the interrupt source in - hardware. Most PCI hardware can mask its interrupt source.

-

The second common approach is to use a filter with multiple - taskqueue(9) tasks. In this case, the filter acknowledges - the interrupts and queues the work to the appropriate taskqueue. Where one - has to multiplex different kinds of interrupt sources, like a network card's - transmit and receive paths, this can reduce lock contention and increase - performance.

-

You should not malloc(9) from inside a filter. - You may not call anything that uses a normal mutex. Witness may complain - about these.

-
-
-

-

You can do whatever you want in an ithread routine, except sleep. - Care must be taken not to sleep in an ithread. In addition, one should - minimize lock contention in an ithread routine because contested locks - ripple over to all other ithread routines on that interrupt.

-
-
-

-

Sleeping is voluntarily giving up control of your thread. All the - sleep routine found in msleep(9) sleep. Waiting for a - condition variable described in condvar(9) is sleeping. - Calling any function that does any of these things is sleeping.

-
-
-
-

-

Zero is returned on success, otherwise an appropriate error is - returned.

-
-
-

-

random(4), device(9), - driver(9), locking(9)

-
-
-

-

This manual page was written by Jeroen Ruigrok - van der Werven - <asmodai@FreeBSD.org> - based on the manual pages for BUS_CREATE_INTR() and - BUS_CONNECT_INTR() written by Doug - Rabson - <dfr@FreeBSD.org>.

-
-
- - - - - -
November 3, 2010FreeBSD 15.0
diff --git a/static/freebsd/man9/CTASSERT.9 4.html b/static/freebsd/man9/CTASSERT.9 4.html deleted file mode 100644 index 36b11f67..00000000 --- a/static/freebsd/man9/CTASSERT.9 4.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - -
CTASSERT(9)Kernel Developer's ManualCTASSERT(9)
-
-
-

-

CTASSERT — compile - time assertion macro

-
-
-

-

#include - <sys/param.h> -
- #include <sys/systm.h>

-

CTASSERT(expression);

-
-
-

-

The - () - macro is deprecated and the C11 standard - () - should be used instead. The header sys/cdefs.h should - be included to provide compatibility for pre-C11 compilers.

-

The - () - macro evaluates expression at compile time and causes - a compiler error if it is false.

-

The - () - macro is useful for asserting the size or alignment of important data - structures and variables during compilation, which would otherwise cause the - code to fail at run time.

-
-
-

-

Assert that the size of the uuid structure - is 16 bytes.

-

-
CTASSERT(sizeof(struct uuid) == - 16);
-
-
-

-

KASSERT(9)

-
-
-

-

This manual page was written by Hiten M. - Pandya - <hmp@FreeBSD.org>.

-
-
- - - - - -
August 1, 2015FreeBSD 15.0
diff --git a/static/freebsd/man9/DB_COMMAND.9 3.html b/static/freebsd/man9/DB_COMMAND.9 3.html deleted file mode 100644 index d4dcfa7d..00000000 --- a/static/freebsd/man9/DB_COMMAND.9 3.html +++ /dev/null @@ -1,180 +0,0 @@ - - - - - - -
DB_COMMAND(9)Kernel Developer's ManualDB_COMMAND(9)
-
-
-

-

DB_COMMAND, - DB_COMMAND_FLAGS, - DB_SHOW_COMMAND, - DB_SHOW_COMMAND_FLAGS, - DB_SHOW_ALL_COMMAND, - DB_TABLE_COMMAND, - DB_TABLE_COMMAND_FLAGS, - DB_ALIAS, DB_ALIAS_FLAGS, - DB_SHOW_ALIAS, - DB_SHOW_ALIAS_FLAGS, - DB_SHOW_ALL_ALIAS, - DB_TABLE_ALIAS, - DB_TABLE_ALIAS_FLAGS - DB_DECLARE_TABLE, - DB_DEFINE_TABLE, — Extends - the ddb command set

-
-
-

-

#include - <ddb/ddb.h>

-

DB_COMMAND(command_name, - command_function);

-

DB_COMMAND_FLAGS(command_name, - command_function, - flags);

-

DB_SHOW_COMMAND(command_name, - command_function);

-

DB_SHOW_COMMAND_FLAGS(command_name, - command_function, - flags);

-

DB_SHOW_ALL_COMMAND(command_name, - command_function);

-

DB_TABLE_COMMAND(table, - command_name, - command_function);

-

DB_TABLE_COMMAND_FLAGS(table, - command_name, - command_function, - flags);

-

DB_ALIAS(alias_name, - command_function);

-

DB_ALIAS_FLAGS(alias_name, - command_function, - flags);

-

DB_SHOW_ALIAS(alias_name, - command_function);

-

DB_SHOW_ALIAS_FLAGS(alias_name, - command_function, - flags);

-

DB_SHOW_ALL_ALIAS(alias_name, - command_function);

-

DB_TABLE_ALIAS(table, - alias_name, - command_function);

-

DB_TABLE_ALIAS_FLAGS(table, - alias_name, - command_function, - flags);

-

DB_DEFINE_TABLE(parent, - name, - table);

-

DB_DECLARE_TABLE(table);

-
-
-

-

The - () - macro adds command_name to the list of top-level - commands. Invoking command_name from ddb will call - command_function.

-

The - () - and - () - macros are roughly equivalent to DB_COMMAND() but in - these cases, command_name is a sub-command of the ddb - show command and show all command, - respectively.

-

The - () - macro is also similar to DB_COMMAND() but adds the - new command as a sub-command of the ddb command - table.

-

The - (), - (), - (), - and - () - macros register the existing command_function under - the alternative command name alias_name.

-

The _FLAGS variants of these commands allow the programmer to - specify a value for the flag field of the command - structure. The possible flag values are defined alongside - struct db_command in - <ddb/ddb.h>.

-

The general command syntax: - command[/modifier] - address[,count], translates into - the following parameters for command_function:

-
-
-
addr
-
The address passed to the command as an argument.
-
have_addr
-
A boolean value that is true if the addr field is valid.
-
count
-
The number of quad words starting at offset addr - that the command must process.
-
modif
-
A pointer to the string of modifiers. That is, a series of symbols used to - pass some options to the command. For example, the - command - will display words in decimal form if it is passed the modifier - "d".
-
-
-

The - () - macro adds a new command name as a sub-command of the - existing command table parent. The new command defines - a table named table which contains sub-commands. New - commands and aliases can be added to this table by passing - table as the first argument to one of the DB_TABLE_ - macros.

-
-
-

-

In your module, the command is declared as:

-
-
DB_COMMAND(mycmd, my_cmd_func)
-{
-	if (have_addr)
-		db_printf("Calling my command with address %p\n", addr);
-}
-
-

An alias for this command is declared as:

-
-
DB_ALIAS(mycmd2, my_cmd_func);
-
-

Then, when in ddb:

-
-

-

-db> mycmd 0x1000
-Calling my command with address 0x1000
-db> mycmd2 0x2500
-Calling my command with address 0x2500
-db>

-

-

-

-

-
ddb(4)

-

-

-

-
This manual page was written by Guillaume
-    Ballet
-    <gballet@gmail.com>.

-

-

-
-  
-    
-    
-  
-
July 5, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/DECLARE_GEOM_CLASS.9 3.html b/static/freebsd/man9/DECLARE_GEOM_CLASS.9 3.html
deleted file mode 100644
index f78cd7bd..00000000
--- a/static/freebsd/man9/DECLARE_GEOM_CLASS.9 3.html	
+++ /dev/null
@@ -1,167 +0,0 @@
-
-  
-    
-    
-    
-  
-
DECLARE_GEOM_CLASS(9)Kernel Developer's ManualDECLARE_GEOM_CLASS(9)

-

-

-

-
DECLARE_GEOM_CLASS —
-    GEOM class declaration macro

-

-

-

-
#include
-    <geom/geom.h>

-
DECLARE_GEOM_CLASS(class,
-    mod_name);

-

-

-

-
The
-    ()
-    macro registers a GEOM class in GEOM. A GEOM class itself implements one
-    particular kind of transformation. Typical examples are: MBR disk partition,
-    BSD disklabel and RAID5 classes.
-    DECLARE_GEOM_CLASS() can be used both for compiled
-    in and loaded as kld(4) modules GEOM classes and it is the
-    only official way for class registration.

-
The arguments to
-    ()
-    are:

-

-

-  
class

-  
The g_class structure which describes a GEOM
-    class.

-  
mod_name

-  
A kernel module name (not a class name!).

-

-

-
Structure g_class contains data describing
-    the class. They are:

-

-

-  
const char * name

-  
Class name.

-  
g_taste_t * taste

-  
Pointer to function used for taste event handling. If it is
-      non-NULL it is called in three situations:
-    

-    
    
-      
  • On class activation, all existing providers are offered for
-        tasting.
    • 
-      
  • When new provider is created it is offered for tasting.
    • 
-      
  • After last write access to a provider is closed it is offered for
-          retasting (on first write open event “spoil” was
-        sent).
    • 
-    

-  

-  
g_config_t * config

-  
This field is not used anymore, its functionality was replaced by the
-      ctlreq field.

-  
g_ctl_req_t * ctlreq

-  
Pointer to function used for handling events from userland
-    applications.

-  
g_init_t * init

-  
Pointer to function which is called right after class registration.

-  
g_fini_t * fini

-  
Pointer to function which is called right before class
-    deregistration.

-  
g_ctl_destroy_geom_t *
-    destroy_geom

-  
Pointer to a function which is called for every geom on class unload. If
-      this field is not set, the class can not be unloaded.

-

-

-
Only a name field is required; the rest are
-    optional.

-

-

-

-
The fields of g_class should always be
-    initialized using C99-style field naming (see the initialization of
-    example_class below).

-

-

-

-
Example class declaration.

-

-
static struct g_geom *
-g_example_taste(struct g_class *mp, struct g_provider *pp,
-    int flags __unused)
-{
-	g_topology_assert();
-
-	[...]
-}
-
-static void
-g_example_ctlreq(struct gctl_req *req, struct g_class *cp,
-    char const *verb)
-{
-
-	[...]
-}
-
-static int
-g_example_destroy_geom(struct gctl_req *req, struct g_class *cp,
-    struct g_geom *gp)
-{
-
-	g_topology_assert();
-
-	[...]
-}
-
-static void
-g_example_init(struct g_class *mp)
-{
-
-	[...]
-}
-
-static void
-g_example_fini(struct g_class *mp)
-{
-
-	[...]
-}
-
-struct g_class example_class = {
-	.name = "EXAMPLE",
-	.taste = g_example_taste,
-	.ctlreq = g_example_ctlreq,
-	.init = g_example_init,
-	.fini = g_example_fini,
-	.destroy_geom = g_example_destroy_geom
-};
-
-DECLARE_GEOM_CLASS(example_class, g_example);

-

-

-

-

-
geom(4), g_attach(9),
-    g_bio(9), g_consumer(9),
-    g_data(9), g_event(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 13, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/DECLARE_MODULE.9 3.html b/static/freebsd/man9/DECLARE_MODULE.9 3.html
deleted file mode 100644
index f0cd620a..00000000
--- a/static/freebsd/man9/DECLARE_MODULE.9 3.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
DECLARE_MODULE(9)Kernel Developer's ManualDECLARE_MODULE(9)

-

-

-

-
DECLARE_MODULE —
-    kernel module declaration macro

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/module.h>

-
DECLARE_MODULE(name,
-    moduledata_t data,
-    sub,
-    order);

-
DECLARE_MODULE_TIED(name,
-    moduledata_t data,
-    sub,
-    order);

-

-

-

-
The
-    ()
-    macro declares a generic kernel module. It is used to register the module
-    with the system, using the SYSINIT() macro.
-    DECLARE_MODULE() is usually used within other
-    macros, such as DRIVER_MODULE(9),
-    DEV_MODULE(9) and SYSCALL_MODULE(9). Of
-    course, it can also be called directly, for example in order to implement
-    dynamic sysctls.

-
A module declared with
-    ()
-    will load only if the running kernel version (as specified by
-    __FreeBSD_version) is identical to that on which it
-    was built. This declaration should be used by modules which depend on
-    interfaces beyond the stable kernel KBI (such as ABI emulators or
-    hypervisors that rely on internal kernel structures).
-    DECLARE_MODULE() will behave like
-    DECLARE_MODULE_TIED() when compiled with modules
-    built with the kernel. This allows locks and other synchronization
-    primitives to be inlined safely.

-
The arguments are:

-

-  
name

-  
The module name, which will be used in the
-      ()
-      call to identify the module.

-  
data

-  
A moduledata_t structure, which contains two main
-      items, the official name of the module name, which will be used in the
-      module_t structure and a pointer to the event
-      handler function of type modeventhand_t.

-  
sub

-  
An argument directed to the SYSINIT() macro. Valid
-      values for this are contained in the sysinit_sub_id
-      enumeration (see
-      <sys/kernel.h>) and
-      specify the type of system startup interfaces. The
-      DRIVER_MODULE(9) macro uses a value of
-      SI_SUB_DRIVERS here for example, since these
-      modules contain a driver for a device. For kernel modules that are loaded
-      at runtime, a value of SI_SUB_EXEC is common.

-  
order

-  
An argument for SYSINIT(). It represents the KLDs
-      order of initialization within the subsystem. Valid values are defined in
-      the sysinit_elem_order enumeration
-      (<sys/kernel.h>).

-

-

-

-

-
DEV_MODULE(9),
-    DRIVER_MODULE(9), module(9),
-    SYSCALL_MODULE(9)

-
/usr/include/sys/kernel.h,
-    /usr/share/examples/kld

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>,
-    inspired by the KLD Facility Programming Tutorial by Andrew
-    Reiter
-    <arr@watson.org>.

-

-

-
-  
-    
-    
-  
-
February 13, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/DEFINE_IFUNC.9 3.html b/static/freebsd/man9/DEFINE_IFUNC.9 3.html
deleted file mode 100644
index d7bc4b82..00000000
--- a/static/freebsd/man9/DEFINE_IFUNC.9 3.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEFINE_IFUNC(9)Kernel Developer's ManualDEFINE_IFUNC(9)

-

-

-

-
DEFINE_IFUNC —
-    define a kernel function with an implementation selected at
-    run-time

-

-

-

-
#include
-    <machine/ifunc.h>

-
DEFINE_IFUNC(qual,
-    ret_type,
-    name,
-    args);

-

-

-

-
ifuncs are a linker feature which allows the programmer to define
-    functions whose implementation is selected at boot-time or module load-time.
-    The DEFINE_IFUNC macro can be used to define an
-    ifunc. The selection is performed by a resolver function, which returns a
-    pointer to the selected function. ifunc resolvers are invoked very early
-    during the machine-dependent initialization routine, or at load time for
-    dynamically loaded modules. Resolution must occur before the first call to
-    an ifunc. ifunc resolution is performed after CPU features are enumerated
-    and after the kernel's environment is initialized. The typical use-case for
-    an ifunc is a routine whose behavior depends on optional CPU features. For
-    example, newer generations of a given CPU architecture may provide an
-    instruction to optimize a common operation. To avoid the overhead of testing
-    for the CPU feature each time the operation is performed, an ifunc can be
-    used to provide two implementations for the operation: one targeting
-    platforms with the extra instruction, and one for older platforms.

-
Because DEFINE_IFUNC is a macro that
-    defines a dynamically typed function, its usage looks somewhat unusual. The
-    qual parameter is a list of zero or more C function
-    qualifiers to be applied to the ifunc. This parameter is typically empty or
-    the static qualifier. ret_type
-    is the return type of the ifunc. name is the name of
-    the ifunc. args is a parenthesized, comma-separated
-    list of the parameter types of the function, as they would appear in a C
-    function declaration.

-
The DEFINE_IFUNC usage must be followed by
-    the resolver function body. The resolver must return a function with return
-    type ret_type and parameter types
-    args. The resolver function is defined with the
-    ‘resolver’ gcc-style function
-    attribute, causing the corresponding elf(5) function
-    symbol to be of type STT_GNU_IFUNC instead of
-    STT_FUNC. The kernel linker invokes the resolver to
-    process relocations targeting ifunc calls and PLT entries referencing such
-    symbols.

-

-

-

-
ifunc resolvers are executed early during boot, before most kernel
-    facilities are available. They are effectively limited to checking CPU
-    feature flags and tunables.

-

-
static size_t
-fast_strlen(const char *s __unused)
-{
-	size_t len;
-
-	/* Fast, but may not be correct in all cases. */
-	__asm("movq $42,%0\n" : "=r" (len));
-	return (len);
-}
-
-static size_t
-slow_strlen(const char *s)
-{
-	const char *t;
-
-	for (t = s; *t != '\0'; t++);
-	return (t - s);
-}
-
-DEFINE_IFUNC(, size_t, strlen, (const char *))
-{
-	int enabled;
-
-	enabled = 1;
-	TUNABLE_INT_FETCH("debug.use_fast_strlen", &enabled);
-	if (enabled && (cpu_features & CPUID_FAST_STRLEN) != 0)
-		return (fast_strlen);
-	else
-		return (slow_strlen);
-}

-

-
This defines a strlen() function with an
-    optimized implementation for CPUs that advertise support.

-

-

-

-
elf(5)

-

-

-

-
ifuncs require both toolchain support, to emit function symbols of
-    type STT_GNU_IFUNC, and kernel linker support, to
-    invoke ifunc resolvers during boot or during module load.

-

-

-
-  
-    
-    
-  
-
March 10, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/DELAY.9 4.html b/static/freebsd/man9/DELAY.9 4.html
deleted file mode 100644
index 5f6c8921..00000000
--- a/static/freebsd/man9/DELAY.9 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
DELAY(9)Kernel Developer's ManualDELAY(9)

-

-

-

-
DELAY — busy loop
-    for an interval

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  DELAY(int
-    delay);

-

-

-

-
Delay for delay microseconds (1/1000000th of
-    a second).

-

-

-

-
pause(9)

-

-

-

-
This manual page was written by Alfred
-    Perlstein.

-

-

-
-  
-    
-    
-  
-
April 20, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/DEVICE_ATTACH.9 4.html b/static/freebsd/man9/DEVICE_ATTACH.9 4.html
deleted file mode 100644
index 15d2fba7..00000000
--- a/static/freebsd/man9/DEVICE_ATTACH.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_ATTACH(9)Kernel Developer's ManualDEVICE_ATTACH(9)

-

-

-

-
DEVICE_ATTACH —
-    attach a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  DEVICE_ATTACH(device_t
-    dev);

-

-

-

-
Attach a device to the system after the
-    ()
-    method has been called and has indicated that the device exists. The
-    ()
-    method should initialize the hardware and allocate other system resources
-    (such as devfs(4) entries).

-
Devices which implement buses should use this method to probe for
-    the existence of devices attached to the bus and add them as children. If
-    this is combined with the use of bus_attach_children(9)
-    the child devices will be automatically probed and attached.

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned.

-

-

-

-
devfs(4),
-    bus_attach_children(9), device(9),
-    DEVICE_DETACH(9), DEVICE_IDENTIFY(9),
-    DEVICE_PROBE(9), DEVICE_SHUTDOWN(9)

-

-

-

-
This manual page was written by Doug
-    Rabson
-    <dfr@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/DEVICE_DETACH.9 4.html b/static/freebsd/man9/DEVICE_DETACH.9 4.html
deleted file mode 100644
index 8dd091af..00000000
--- a/static/freebsd/man9/DEVICE_DETACH.9 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_DETACH(9)Kernel Developer's ManualDEVICE_DETACH(9)

-

-

-

-
DEVICE_DETACH —
-    detach a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  DEVICE_DETACH(device_t
-    dev);

-

-

-

-
Detach a device. This can be called if the user is replacing the
-    driver software or if a device is about to be physically removed from the
-    system.

-
The method should deallocate any system resources allocated during
-    the DEVICE_ATTACH(9) method and reset the hardware to a
-    sane state (i.e., disable interrupts etc.)

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned.

-

-

-

-
device(9), DEVICE_ATTACH(9),
-    DEVICE_IDENTIFY(9), DEVICE_PROBE(9),
-    DEVICE_SHUTDOWN(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/DEVICE_IDENTIFY.9 3.html b/static/freebsd/man9/DEVICE_IDENTIFY.9 3.html
deleted file mode 100644
index 5134840f..00000000
--- a/static/freebsd/man9/DEVICE_IDENTIFY.9 3.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_IDENTIFY(9)Kernel Developer's ManualDEVICE_IDENTIFY(9)

-

-

-

-
DEVICE_IDENTIFY —
-    identify new child devices and register them

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  DEVICE_IDENTIFY(driver_t
-    *driver, device_t
-    parent);

-

-

-

-
The identify method of a device driver is used to add devices that
-    cannot be enumerated by the standard method on a bus device. Devices can be
-    enumerated in various ways including accessing non-ambiguous device
-    registers and parsing firmware tables. Software-only pseudo devices are also
-    often enumerated via identify methods.

-
For each newly identified device, a new device instance should be
-    created by invoking the BUS_ADD_CHILD(9) method. If the
-    identify method is able to discover other properties about the new device,
-    those should also be set. For example, device resources should be added to
-    the device by calling bus_set_resource(9) for each
-    resource.

-
An identify method might be invoked multiple times. If a device
-    driver is unloaded and loaded, the identify method will be called a second
-    time after being reloaded. As a result, the identify method should avoid
-    duplicate devices. Devices added by identify methods typically use a fixed
-    device name in which case device_find_child(9) can be used
-    to detect existing devices.

-

-

-

-
The following pseudo-code shows an example of a function that
-    probes for a piece of hardware and registers it and its resource (an I/O
-    port) with the parent bus device.

-

-
void
-foo_identify(driver_t *driver, device_t parent)
-{
-	device_t child;
-
-	retrieve_device_information;
-	if (devices matches one of your supported devices &&
-	    device_find_child(parent, "foo", DEVICE_UNIT_ANY) == NULL) {
-		child = BUS_ADD_CHILD(parent, 0, "foo", DEVICE_UNIT_ANY);
-		bus_set_resource(child, SYS_RES_IOPORT, 0, FOO_IOADDR, 1);
-	}
-}

-

-

-

-

-
BUS_ADD_CHILD(9),
-    bus_identify_children(9),
-    bus_set_resource(9), device(9),
-    device_find_child(9)

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/DEVICE_PROBE.9 3.html b/static/freebsd/man9/DEVICE_PROBE.9 3.html
deleted file mode 100644
index 2c5243ce..00000000
--- a/static/freebsd/man9/DEVICE_PROBE.9 3.html	
+++ /dev/null
@@ -1,115 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_PROBE(9)Kernel Developer's ManualDEVICE_PROBE(9)

-

-

-

-
DEVICE_PROBE —
-    probe for device existence

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  DEVICE_PROBE(device_t
-    dev);

-

-

-

-
The
-    ()
-    method should probe to see if the device is present. It should return 0 if
-    the device exists, ENXIO if it cannot be found. If
-    some other error happens during the probe (such as a memory allocation
-    failure), an appropriate error code should be returned. For cases where more
-    than one driver matches a device, a priority value can be returned. In this
-    case, success codes are values less than or equal to zero with the highest
-    value representing the best match. Failure codes are represented by positive
-    values and the regular UNIX error codes should be
-    used for the purpose.

-
If a driver returns a success code which is less than zero, it
-    must not assume that it will be the same driver which is attached to the
-    device. In particular, it must not assume that any values stored in the
-    softc structure will be available for its attach method and any resources
-    allocated during probe must be released and re-allocated if the attach
-    method is called. In addition it is an absolute requirement that the probe
-    routine have no side effects whatsoever. The probe routine may be called
-    more than once before the attach routine is called.

-
If a success code of zero is returned, the driver can assume that
-    it will be the one attached, but must not hold any resources when the probe
-    routine returns. A driver may assume that the softc is preserved when it
-    returns a success code of zero.

-

-

-

-
A value equal to or less than zero indicates success, greater than
-    zero indicates an error (errno). For values equal to or less than zero: zero
-    indicates highest priority, no further probing is done; for a value less
-    than zero, the lower the value the lower the priority, e.g. -100 indicates a
-    lower priority than -50.

-
The following values are used by convention to indicate different
-    strengths of matching in a probe routine. Except as noted, these are just
-    suggested values, and there's nothing magical about them.

-

-  
BUS_PROBE_SPECIFIC

-  
The device that cannot be reprobed, and that no possible other driver may
-      exist (typically legacy drivers who don't follow all the rules, or special
-      needs drivers).

-  
BUS_PROBE_VENDOR

-  
The device is supported by a vendor driver. This is for source or binary
-      drivers that are not yet integrated into the
-      FreeBSD tree. Its use in the base OS is
-      prohibited.

-  
BUS_PROBE_DEFAULT

-  
The device is a normal device matching some plug and play ID. This is the
-      normal return value for drivers to use. It is intended that nearly all of
-      the drivers in the tree should return this value.

-  
BUS_PROBE_LOW_PRIORITY

-  
The driver is a legacy driver, or an otherwise less desirable driver for a
-      given plug and play ID. The driver has special requirements like when
-      there are two drivers that support overlapping series of hardware devices.
-      In this case the one that supports the older part of the line would return
-      this value, while the one that supports the newer ones would return
-      BUS_PROBE_DEFAULT.

-  
BUS_PROBE_GENERIC

-  
The driver matches the type of device generally. This allows drivers to
-      match all serial ports generally, with specialized drivers matching
-      particular types of serial ports that need special treatment for some
-      reason.

-  
BUS_PROBE_HOOVER

-  
The driver matches all unclaimed devices on a bus. The
-      ugen(4) device is one example.

-  
BUS_PROBE_NOWILDCARD

-  
The driver expects its parent to tell it which children to manage and no
-      probing is really done. The device only matches if its parent bus
-      specifically said to use this driver.

-

-

-

-

-
device(9), DEVICE_ATTACH(9),
-    DEVICE_DETACH(9), DEVICE_IDENTIFY(9),
-    DEVICE_SHUTDOWN(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 8, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/DEVICE_SHUTDOWN.9 4.html b/static/freebsd/man9/DEVICE_SHUTDOWN.9 4.html
deleted file mode 100644
index d63b94b0..00000000
--- a/static/freebsd/man9/DEVICE_SHUTDOWN.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_SHUTDOWN(9)Kernel Developer's ManualDEVICE_SHUTDOWN(9)

-

-

-

-
DEVICE_SHUTDOWN —
-    called during system shutdown

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  DEVICE_SHUTDOWN(device_t
-    dev);

-

-

-

-
The
-    ()
-    method is called during system shutdown to allow the driver to put the
-    hardware into a consistent state for rebooting the computer.

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
device(9), DEVICE_ATTACH(9),
-    DEVICE_DETACH(9), DEVICE_IDENTIFY(9),
-    DEVICE_PROBE(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 6, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/DEV_MODULE.9 4.html b/static/freebsd/man9/DEV_MODULE.9 4.html
deleted file mode 100644
index 5acd33df..00000000
--- a/static/freebsd/man9/DEV_MODULE.9 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEV_MODULE(9)Kernel Developer's ManualDEV_MODULE(9)

-

-

-

-
DEV_MODULE —
-    device driver module declaration macro

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/module.h>
-  

-  #include <sys/conf.h>

-
DEV_MODULE(name,
-    modeventhand_t evh,
-    void *arg);

-

-

-

-
The
-    ()
-    macro declares a device driver kernel module. It fills in a
-    moduledata_t structure and then calls
-    ()
-    with the correct args, where name is the name of the
-    module and evh (with its argument
-    arg) is the event handler for the module (refer to
-    DECLARE_MODULE(9) for more information). The event handler
-    is supposed to create the device with
-    ()
-    on load and to destroy it when it is unloaded using
-    ().

-

-

-

-

-
#include <sys/module.h>
-#include <sys/conf.h>
-
-static struct cdevsw foo_devsw = { ... };
-
-static struct cdev *sdev;
-
-static int
-foo_load(module_t mod, int cmd, void *arg)
-{
-    int err = 0;
-
-    switch (cmd) {
-    case MOD_LOAD:
-        sdev = make_dev(&foo_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "foo");
-        break;          /* Success*/
-
-    case MOD_UNLOAD:
-    case MOD_SHUTDOWN:
-        destroy_dev(sdev);
-        break;          /* Success*/
-
-    default:
-        err = EINVAL;
-        break;
-    }
-
-    return(err);
-}
-
-DEV_MODULE(foo, foo_load, NULL);

-

-

-

-

-
DECLARE_MODULE(9),
-    destroy_dev(9), make_dev(9),
-    module(9)

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 19, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/DRIVER_MODULE.9 3.html b/static/freebsd/man9/DRIVER_MODULE.9 3.html
deleted file mode 100644
index c58d4846..00000000
--- a/static/freebsd/man9/DRIVER_MODULE.9 3.html	
+++ /dev/null
@@ -1,139 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRIVER_MODULE(9)Kernel Developer's ManualDRIVER_MODULE(9)

-

-

-

-
DRIVER_MODULE,
-    DRIVER_MODULE_ORDERED,
-    EARLY_DRIVER_MODULE,
-    EARLY_DRIVER_MODULE_ORDERED —
-    kernel driver declaration macro

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/bus.h>
-  

-  #include <sys/module.h>

-
DRIVER_MODULE(name,
-    busname,
-    driver_t driver,
-    modeventhand_t evh,
-    void *arg);

-
DRIVER_MODULE_ORDERED(name,
-    busname,
-    driver_t driver,
-    modeventhand_t evh,
-    void *arg,
-    int order);

-
EARLY_DRIVER_MODULE(name,
-    busname,
-    driver_t driver,
-    modeventhand_t evh,
-    void *arg,
-    int pass);

-
EARLY_DRIVER_MODULE_ORDERED(name,
-    busname,
-    driver_t driver,
-    modeventhand_t evh,
-    void *arg,
-    enum sysinit_elem_order
-    order, int
-  pass);

-

-

-

-
The
-    ()
-    macro declares a kernel driver. DRIVER_MODULE()
-    expands to the real driver declaration, where the phrase
-    name is used as the naming prefix for the driver and
-    its functions. Note that it is supplied as plain text, and not a
-    char or char *.

-
busname is the parent bus of the driver
-    (PCI, ISA, PPBUS and others), e.g.
-    ‘pci’,
-    ‘isa’, or
-    ‘ppbus’.

-
The identifier used in
-    ()
-    can be different from the driver name. Also, the same driver identifier can
-    exist on different buses, which is a pretty clean way of making front ends
-    for different cards using the same driver on the same or different buses.
-    For example, the following is allowed:

-
(foo,
-    isa, foo_driver,
-    NULL, NULL);

-
(foo,
-    pci, foo_driver,
-    NULL, NULL);

-
driver is the driver of
-    type driver_t, which contains the information about
-    the driver and is therefore one of the two most important parts of the call
-    to
-    ().

-
The evh argument is the event handler which
-    is called when the driver (or module) is loaded or unloaded (see
-    module(9)).

-
The arg is unused at this time and should be
-    a NULL pointer.

-
The
-    ()
-    macro allows a driver to be registered in a specific order. This can be
-    useful if a single kernel module contains multiple drivers that are
-    inter-dependent. The order argument should be one of
-    the SYSINIT(9) initialization ordering constants
-    (SI_ORDER_*). The default order for a driver module
-    is SI_ORDER_MIDDLE. Typically a module will specify
-    an order of SI_ORDER_ANY for a single driver to
-    ensure it is registered last.

-
The
-    ()
-    macro allows a driver to be registered for a specific pass level. The boot
-    time probe and attach process makes multiple passes over the device tree.
-    Certain critical drivers that provide basic services needed by other devices
-    are attached during earlier passes. Most drivers are attached in a final
-    general pass. A driver that attaches during an early pass must register for
-    a specific pass level (BUS_PASS_*) via the pass
-    argument. Once a driver is registered it is available to attach to devices
-    for all subsequent passes.

-
The
-    ()
-    macro allows a driver to be registered both in a specific order and for a
-    specific pass level.

-

-

-

-
device(9), driver(9),
-    module(9), MODULE_PNP_INFO(9),
-    SYSINIT(9)

-

-

-

-
Prior to FreeBSD 14.0, these macros
-    accepted an additional devclass_t argument after
-    driver.

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 19, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/EVENTHANDLER.9 3.html b/static/freebsd/man9/EVENTHANDLER.9 3.html
deleted file mode 100644
index c63fa5bf..00000000
--- a/static/freebsd/man9/EVENTHANDLER.9 3.html	
+++ /dev/null
@@ -1,231 +0,0 @@
-
-  
-    
-    
-    
-  
-
EVENTHANDLER(9)Kernel Developer's ManualEVENTHANDLER(9)

-

-

-

-
EVENTHANDLER —
-    kernel event handling functions

-

-

-

-
#include
-    <sys/eventhandler.h>

-
EVENTHANDLER_DECLARE(name,
-    type);

-
EVENTHANDLER_DEFINE(name,
-    func,
-    arg,
-    priority);

-
EVENTHANDLER_INVOKE(name,
-    ...);

-
eventhandler_tag
-  

-  EVENTHANDLER_REGISTER(name,
-    func,
-    arg,
-    priority);

-
EVENTHANDLER_DEREGISTER(name,
-    tag);

-
EVENTHANDLER_DEREGISTER_NOWAIT(name,
-    tag);

-
EVENTHANDLER_LIST_DECLARE(name);

-
EVENTHANDLER_LIST_DEFINE(name);

-
EVENTHANDLER_DIRECT_INVOKE(name);

-
eventhandler_tag
-  

-  eventhandler_register(struct
-    eventhandler_list *list, const char *name,
-    void *func, void *arg,
-    int priority);

-
void
-  

-  eventhandler_deregister(struct
-    eventhandler_list *list, eventhandler_tag
-  tag);

-
void
-  

-  eventhandler_deregister_nowait(struct
-    eventhandler_list *list, eventhandler_tag
-  tag);

-
struct eventhandler_list *
-  

-  eventhandler_find_list(const
-    char *name);

-
void
-  

-  eventhandler_prune_list(struct
-    eventhandler_list *list);

-

-

-

-
The EVENTHANDLER mechanism provides a way
-    for kernel subsystems to register interest in kernel events and have their
-    callback functions invoked when these events occur.

-
Callback functions are invoked in order of priority. The relative
-    priority of each callback among other callbacks associated with an event is
-    given by argument priority, which is an integer
-    ranging from EVENTHANDLER_PRI_FIRST (highest
-    priority), to EVENTHANDLER_PRI_LAST (lowest
-    priority). The symbol EVENTHANDLER_PRI_ANY may be
-    used if the handler does not have a specific priority associated with
-  it.

-
The normal way to use this subsystem
-    is via the macro interface. For events that are high frequency it is
-    suggested that you additionally use
-    ()
-    so that the event handlers can be invoked directly using
-    ()
-    (see below). This saves the invoker from having to do a locked traversal of
-    a global list of event handler lists.

-

-  
()

-  
This macro declares an event handler named by argument
-      name with callback functions of type
-      type.

-  
()

-  
This macro uses SYSINIT(9) to register a callback
-      function func with event handler
-      name. When invoked, function
-      func will be invoked with argument
-      arg as its first parameter along with any additional
-      parameters passed in via macro
-      ()
-      (see below).

-  
()

-  
This macro registers a callback function func with
-      event handler name. When invoked, function
-      func will be invoked with argument
-      arg as its first parameter along with any additional
-      parameters passed in via macro
-      EVENTHANDLER_INVOKE() (see below).
-      EVENTHANDLER_REGISTER() returns a cookie of type
-      eventhandler_tag.

-  
()

-  
This macro removes a previously registered callback associated with tag
-      tag from the event handler named by argument
-      name. It waits until no threads are running handlers
-      for this event before returning, making it safe to unload a module
-      immediately upon return from this function.

-  
()

-  
This macro removes a previously registered callback associated with tag
-      tag from the event handler named by argument
-      name. Upon return, one or more threads could still
-      be running the removed function(s), but no new calls will be made. To
-      remove a handler function from within that function, use this version of
-      deregister, to avoid a deadlock.

-  
EVENTHANDLER_INVOKE()

-  
This macro is used to invoke all the callbacks associated with event
-      handler name. This macro is a variadic one.
-      Additional arguments to the macro after the name
-      parameter are passed as the second and subsequent arguments to each
-      registered callback function.

-  
EVENTHANDLER_LIST_DEFINE()

-  
This macro defines a reference to an event handler list named by argument
-      name. It uses SYSINIT(9) to
-      initialize the reference and the eventhandler list.

-  
()

-  
This macro declares an event handler list named by argument
-      name. This is only needed for users of
-      EVENTHANDLER_DIRECT_INVOKE() which are not in the
-      same compilation unit of that list's definition.

-  
EVENTHANDLER_DIRECT_INVOKE()

-  
This macro invokes the event handlers registered for the list named by
-      argument name. This macro can only be used if the
-      list was defined with EVENTHANDLER_LIST_DEFINE().
-      The macro is variadic with the same semantics as
-      EVENTHANDLER_INVOKE().

-

-
The macros are implemented using the following functions:

-

-  
()

-  
The eventhandler_register() function is used to
-      register a callback with a given event. The arguments expected by this
-      function are:
-    

-      
list

-      
A pointer to an existing event handler list, or
-          NULL. If list is
-          NULL, the event handler list corresponding to
-          argument name is used.

-      
name

-      
The name of the event handler list.

-      
func

-      
A pointer to a callback function. Argument arg
-          is passed to the callback function func as its
-          first argument when it is invoked.

-      
priority

-      
The relative priority of this callback among all the callbacks
-          registered for this event. Valid values are those in the range
-          EVENTHANDLER_PRI_FIRST to
-          EVENTHANDLER_PRI_LAST.

-    

-    
The
-        ()
-        function returns a tag that can later be used with
-        ()
-        to remove the particular callback function.

-  

-  
eventhandler_deregister()

-  
The eventhandler_deregister() function removes the
-      callback associated with tag tag from the event
-      handler list pointed to by list. If
-      tag is NULL, all callback
-      functions for the event are removed. This function will not return until
-      all threads have exited from the removed handler callback function(s).
-      This function is not safe to call from inside an event handler
-    callback.

-  
()

-  
The eventhandler_deregister() function removes the
-      callback associated with tag tag from the event
-      handler list pointed to by list. This function is
-      safe to call from inside an event handler callback.

-  
()

-  
The eventhandler_find_list() function returns a
-      pointer to event handler list structure corresponding to event
-      name.

-  
()

-  
The eventhandler_prune_list() function removes all
-      deregistered callbacks from the event list
-    list.

-

-

-

-

-
The macro EVENTHANDLER_REGISTER() and
-    function eventhandler_register() return a cookie of
-    type eventhandler_tag, which may be used in a
-    subsequent call to EVENTHANDLER_DEREGISTER() or
-    eventhandler_deregister().

-
The eventhandler_find_list() function
-    returns a pointer to an event handler list corresponding to parameter
-    name, or NULL if no such list
-    was found.

-

-

-

-
The EVENTHANDLER facility first appeared
-    in FreeBSD 4.0.

-

-

-

-
This manual page was written by Joseph
-    Koshy
-    <jkoshy@FreeBSD.org>
-    and
-  

-  Matt Joras
-    <mjoras@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 31, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/KASSERT.9 3.html b/static/freebsd/man9/KASSERT.9 3.html
deleted file mode 100644
index 8b96b200..00000000
--- a/static/freebsd/man9/KASSERT.9 3.html	
+++ /dev/null
@@ -1,161 +0,0 @@
-
-  
-    
-    
-    
-  
-
KASSERT(9)Kernel Developer's ManualKASSERT(9)

-

-

-

-
KASSERT — kernel
-    expression verification macros

-

-

-

-
options INVARIANTS

-

-  

-  #include <sys/param.h>
-  

-  #include <sys/systm.h>

-
KASSERT(expression,
-    msg);

-
MPASS(expression);

-

-

-

-
Assertions are widely used within the
-    FreeBSD kernel to verify programmatic assumptions.
-    For violations of run-time assumptions and invariants, it is desirable to
-    fail as soon and as loudly as possible. Assertions are optional code; for
-    non-recoverable error conditions an explicit call to
-    panic(9) is usually preferred.

-
The
-    ()
-    macro tests the given boolean expression. If
-    expression evaluates to false,
-    and the kernel is compiled with options INVARIANTS,
-    the panic(9) function is called. This terminates the
-    running system at the point of the error, possibly dropping into the kernel
-    debugger or initiating a kernel core dump. The second argument,
-    msg, is a printf(9) format string
-    and its arguments, enclosed in parentheses. The formatted string will become
-    the panic string.

-
In a kernel that is built without options
-    INVARIANTS, the assertion macros are defined to be no-ops. This
-    eliminates the runtime overhead of widespread assertions from release builds
-    of the kernel. Therefore, checks which can be performed in a constant amount
-    of time can be added as assertions without concern about their performance
-    impact. More expensive checks, such as those that output to console, or
-    verify the integrity of a chain of objects are generally best hidden behind
-    the DIAGNOSTIC kernel option.

-
The
-    () macro
-    (read as: "must-pass") is a convenience wrapper around
-    KASSERT() that automatically generates a simple
-    assertion message including file and line information.

-

-

-
When adding new assertions, keep in mind their primary purpose: to
-    aid in identifying and debugging of complex error conditions.

-
The panic messages resulting from assertion failures should be
-    useful without the resulting kernel dump; the message may be included in a
-    bug report, and should contain the relevant information needed to discern
-    how the assertion was violated. This is especially important when the error
-    condition is difficult or impossible for the developer to reproduce
-  locally.

-
Therefore, assertions should adhere to the following
-  guidelines:

-
    
-  
  1. Whenever possible, the value of a runtime variable checked by an assertion
-      condition should appear in its message.
    2. 
-  
  2. Unrelated conditions must appear in separate assertions.
    3. 
-  
  3. Multiple related conditions should be distinguishable (e.g. by value), or
-      split into separate assertions.
    4. 
-  
  4. When in doubt, print more information, not less.
    5. 
-

-
Combined, this gives greater clarity into the exact cause of an
-    assertion panic; see EXAMPLES below.

-

-

-

-

-
A hypothetical struct foo object must not
-    have its 'active' flag set when calling
-    foo_dealloc():

-

-
void
-foo_dealloc(struct foo *fp)
-{
-
-	KASSERT((fp->foo_flags & FOO_ACTIVE) == 0,
-	    ("%s: fp %p is still active, flags=%x", __func__, fp,
-	    fp->foo_flags));
-	...
-}

-

-
This assertion provides the full flag set for the object, as well
-    as the memory pointer, which may be used by a debugger to examine the object
-    in detail (for example with a 'show foo' command in
-    ddb(4)).

-
The assertion

-

-
MPASS(td == curthread);

-

-
located on line 87 of a file named foo.c would generate the
-    following panic message:

-

-
panic: Assertion td == curthread failed at foo.c:87

-

-
This is a simple condition, and the message provides enough
-    information to investigate the failure.

-
The assertion

-

-
MPASS(td == curthread && (sz >= SIZE_MIN && sz <= SIZE_MAX));

-

-
is
-     useful enough.
-    The message doesn't indicate which part of the assertion was violated, nor
-    does it report the value of sz, which may be
-    critical to understanding
-     the
-    assertion failed.

-
According to the guidelines above, this would be correctly
-    expressed as:

-

-
MPASS(td == curthread);
-KASSERT(sz >= SIZE_MIN && sz <= SIZE_MAX,
-    ("invalid size argument: %u", sz));

-

-

-

-

-
The MPASS macro first appeared in
-    BSD/OS and was imported into
-    FreeBSD 5.0. The name originates as an acronym of
-    "multi-processor assert", but has evolved to mean "must
-    pass", or "must-pass assert".

-

-

-

-
panic(9)

-

-

-

-
This manual page was written by Jonathan M.
-    Bresler
-    <jmb@FreeBSD.org> and
-  

-  Mitchell Horne
-    <mhorne@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 19, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/LOCK_PROFILING.9 3.html b/static/freebsd/man9/LOCK_PROFILING.9 3.html
deleted file mode 100644
index 996a990b..00000000
--- a/static/freebsd/man9/LOCK_PROFILING.9 3.html	
+++ /dev/null
@@ -1,150 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOCK_PROFILING(9)Kernel Developer's ManualLOCK_PROFILING(9)

-

-

-

-
LOCK_PROFILING —
-    kernel lock profiling support

-

-

-

-
options LOCK_PROFILING

-

-

-

-
The LOCK_PROFILING kernel option adds
-    support for measuring and reporting lock use and contention statistics.
-    These statistics are collated by “acquisition point”.
-    Acquisition points are distinct places in the kernel source code (identified
-    by source file name and line number) where a lock is acquired.

-
For each acquisition point, the following statistics are
-    accumulated:

-
    
-  
  • The longest time the lock was ever continuously held after being acquired
-      at this point.
    • 
-  
  • The total time the lock was held after being acquired at this point.
    • 
-  
  • The total time that threads have spent waiting to acquire the lock.
    • 
-  
  • The total number of non-recursive acquisitions.
    • 
-  
  • The total number of times the lock was already held by another thread when
-      this point was reached, requiring a spin or a sleep.
    • 
-  
  • The total number of times another thread tried to acquire the lock while
-      it was held after having been acquired at this point.
    • 
-

-
In addition, the average hold time and average wait time are
-    derived from the total hold time and total wait time respectively and the
-    number of acquisitions.

-
The LOCK_PROFILING kernel option also adds
-    the following sysctl(8) variables to control and monitor
-    the profiling code:

-

-  
debug.lock.prof.enable

-  
Enable or disable the lock profiling code. This defaults to 0 (off).

-  
debug.lock.prof.reset

-  
Reset the current lock profiling buffers.

-  
debug.lock.prof.stats

-  
The actual profiling statistics in plain text. The columns are as follows,
-      from left to right:
-    

-      
max

-      
The longest continuous hold time in microseconds.

-      
wait_max

-      
The longest continuous wait time in microseconds.

-      
total

-      
The total (accumulated) hold time in microseconds.

-      
wait_total

-      
The total (accumulated) wait time in microseconds.

-      
count

-      
The total number of acquisitions.

-      
avg

-      
The average hold time in microseconds, derived from the total hold
-          time and the number of acquisitions.

-      
wait_avg

-      
The average wait time in microseconds, derived from the total wait
-          time and the number of acquisitions.

-      
cnt_hold

-      
The number of times the lock was held and another thread attempted to
-          acquire the lock.

-      
cnt_lock

-      
The number of times the lock was already held when this point was
-          reached.

-      
name

-      
The name of the acquisition point, derived from the source file name
-          and line number, followed by the name of the lock in parentheses.

-    

-  

-  
debug.lock.prof.rejected

-  
The number of acquisition points that were ignored after the table filled
-      up.

-  
debug.lock.prof.skipspin

-  
Disable or enable the lock profiling code for the spin locks. This
-      defaults to 0 (do profiling for the spin locks).

-  
debug.lock.prof.skipcount

-  
Do sampling approximately every N lock acquisitions.

-

-

-

-

-
sysctl(8), mutex(9)

-

-

-

-
Mutex profiling support appeared in FreeBSD
-    5.0. Generalized lock profiling support appeared in
-    FreeBSD 7.0.

-

-

-

-
The MUTEX_PROFILING code was written by
-    Eivind Eklund
-    <eivind@FreeBSD.org>,
-    Dag-Erling Smørgrav
-    <des@FreeBSD.org> and
-    Robert Watson
-    <rwatson@FreeBSD.org>.
-    The LOCK_PROFILING code was written by
-    Kip Macy
-    <kmacy@FreeBSD.org>.
-    This manual page was written by Dag-Erling
-    Smørgrav
-    <des@FreeBSD.org>.

-

-

-

-
The LOCK_PROFILING option increases the
-    size of struct lock_object, so a kernel built with
-    that option will not work with modules built without it.

-
The LOCK_PROFILING option also prevents
-    inlining of the mutex code, which can result in a fairly severe performance
-    penalty. This is, however, not always the case.
-    LOCK_PROFILING can introduce a substantial
-    performance overhead that is easily monitorable using other profiling tools,
-    so combining profiling tools with LOCK_PROFILING is
-    not recommended.

-
Measurements are made and stored in nanoseconds using
-    nanotime(9), (on architectures without a synchronized TSC)
-    but are presented in microseconds. This should still be sufficient for the
-    locks one would be most interested in profiling (those that are held long
-    and/or acquired often).

-
LOCK_PROFILING should generally not be
-    used in combination with other debugging options, as the results may be
-    strongly affected by interactions between the features. In particular,
-    LOCK_PROFILING will report higher than normal
-    uma(9) lock contention when run with
-    INVARIANTS due to extra locking that occurs when
-    INVARIANTS is present; likewise, using it in
-    combination with WITNESS will lead to much higher
-    lock hold times and contention in profiling output.

-

-

-
-  
-    
-    
-  
-
March 7, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/MODULE_DEPEND.9 4.html b/static/freebsd/man9/MODULE_DEPEND.9 4.html
deleted file mode 100644
index d6ada94a..00000000
--- a/static/freebsd/man9/MODULE_DEPEND.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
MODULE_DEPEND(9)Kernel Developer's ManualMODULE_DEPEND(9)

-

-

-

-
MODULE_DEPEND —
-    set kernel module dependencies

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/module.h>

-
MODULE_DEPEND(name,
-    moddepend,
-    int minversion,
-    int prefversion,
-    int maxversion);

-

-

-

-
The
-    ()
-    macro sets a dependency on another kernel module with name
-    moddepend, which has registered its version with
-    ().

-
The
-    ()
-    macro provides hints to the kernel loader(8) and to the
-    kernel linker to ensure that the named dependency is loaded prior to the
-    existing module. It does not change or dictate the order in which modules
-    are initialized at runtime.

-
Three versions must be specified for
-    moddepend:

-

-  
minversion

-  
The minimum version on which the current module can depend.

-  
maxversion

-  
The maximum version on which the current module can depend.

-  
prefversion

-  
The preferred version on which the current module can depend.

-

-

-

-

-

-
MODULE_DEPEND(foo, bar, 1, 3, 4);

-

-

-

-

-
DECLARE_MODULE(9), module(9),
-    MODULE_VERSION(9)

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 11, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/MODULE_PNP_INFO.9 4.html b/static/freebsd/man9/MODULE_PNP_INFO.9 4.html
deleted file mode 100644
index c8adacb0..00000000
--- a/static/freebsd/man9/MODULE_PNP_INFO.9 4.html	
+++ /dev/null
@@ -1,177 +0,0 @@
-
-  
-    
-    
-    
-  
-
MODULE_PNP_INFO(9)Kernel Developer's ManualMODULE_PNP_INFO(9)

-

-

-

-
MODULE_PNP_INFO —
-    register plug and play information for device
-    matching

-

-

-

-
#include
-    <sys/module.h>

-
MODULE_PNP_INFO(const char
-    *descriptor_string, bus,
-    module, void *table,
-    size_t num_entries);

-

-

-

-
The
-    ()
-    macro registers a table of device-identifying data for
-    use by devmatch(8). Since it is built off module marking
-    macros, it must follow a DRIVER_MODULE(9) line.

-
The macro takes a descriptor_string that
-    describes the memory layout of table entries. The string is a series of
-    members separated by semi-colons. Members are identified by a type and a
-    name. They are encoded in the descriptor string by concatenating the type
-    with a colon, followed by the name. (The special type
-    W32 represents two members. The first name is encoded
-    like any other type. The second name is encoded by appending a forward slash
-    and the second name after the first.)

-
Types are one of the following:

-

-  
“U8”

-  
uint8_t element.

-  
“V8”

-  
Same as U8, except that the sentinel value 0xFF
-      matches any.

-  
“G16”

-  
uint16_t element; any value greater than or equal
-      matches.

-  
“L16”

-  
uint16_t element; any value less than or equal
-      matches.

-  
“M16”

-  
uint16_t element; mask of which of the following
-      fields to use.

-  
“U16”

-  
uint16_t element.

-  
“V16”

-  
Same as U16, except that the sentinel value 0xFFFF
-      matches any.

-  
“U32”

-  
uint32_t element.

-  
“V32”

-  
Same as U32, except that the sentinel value
-      0xFFFFFFFF matches any.

-  
“W32”

-  
Two uint16_t values; the first named member is in
-      the least significant word and the second named member is in the most
-      significant word.

-  
“Z”

-  
A pointer to a string to match exactly.

-  
“D”

-  
A pointer to a human readable description for the device.

-  
“P”

-  
A pointer that should be ignored.

-  
“E”

-  
EISA PNP Identifier.

-  
“T”

-  
PNP info that is true for the whole table. The driver code checks for
-      these condition pragmatically before using this table to match devices.
-      This item must come last in the list.

-

-
The pseudo-name “#” is reserved for fields that
-    should be ignored. Any member that does not match the parent device's
-    pnpinfo output must be ignored.

-
The bus parameter is an unquoted word naming
-    the parent bus of the driver. For example, “pci”.

-
The module parameter is also an unquoted
-    word. It must be unique to the driver. Usually the driver's name is
-  used.

-
The table parameter points to the device
-    matching data with entries matching the
-    descriptor_string.

-
The num_entries parameter is the number of
-    entries in the table, i.e.,
-    ‘nitems(table)’. Note that only valid
-    entries should be included. If the table contains trailing zero or bogus
-    values, they should not be included in
-  num_entries.

-

-

-

-

-  
 Using W32 for vendor/device pair

-  

-    
The following example shows usage of W32
-        type when vendor/device values are combined into single
-        uint32_t value:

-    

-    
#include <sys/param.h>
-#include <sys/module.h>
-
-static struct my_pciids {
-	uint32_t devid;
-	const char *desc;
-} my_ids[] = {
-	{ 0x12345678, "Foo bar" },
-	{ 0x9abcdef0, "Baz fizz" },
-};
-
-MODULE_PNP_INFO("W32:vendor/device;D:#", pci, my_driver, my_ids,
-    nitems(my_ids));

-    

-  

-  
 Using T for common vendor value

-  

-    
The following example shows usage of T
-        type when all entries in the table have the same vendor value:

-    

-    
#include <sys/param.h>
-#include <sys/module.h>
-
-static struct my_pciids {
-	uint16_t device;
-	const char *desc;
-} my_ids[] = {
-	{ 0x9abc, "Foo bar" },
-	{ 0xdef0, "Baz fizz" },
-};
-
-MODULE_PNP_INFO("U16:device;D:#;T:vendor=0x1234", pci, my_driver,
-    my_ids, nitems(my_ids));

-    

-  

-

-

-

-

-
The MODULE_PNP_INFO macro must follow
-    DRIVER_MODULE invocations due to limitations in the
-    linker.hints file format.

-

-

-

-
devmatch(8), DRIVER_MODULE(9),
-    module(9)

-

-

-

-
The macro MODULE_PNP_INFO appeared in
-    FreeBSD 11.0.

-

-

-

-
The PNP framework and devmatch(8) utility were
-    written by Warner Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
May 23, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/MODULE_VERSION.9 4.html b/static/freebsd/man9/MODULE_VERSION.9 4.html
deleted file mode 100644
index 83840d42..00000000
--- a/static/freebsd/man9/MODULE_VERSION.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
MODULE_VERSION(9)Kernel Developer's ManualMODULE_VERSION(9)

-

-

-

-
MODULE_VERSION —
-    set kernel module version

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/module.h>

-
MODULE_VERSION(name,
-    int version);

-

-

-

-
The
-    ()
-    macro sets the version of the module called name.
-    Other kernel modules can then depend on this module (see
-    MODULE_DEPEND(9)).

-

-

-

-

-
MODULE_VERSION(foo, 1);

-

-

-

-

-
DECLARE_MODULE(9), module(9),
-    MODULE_DEPEND(9)

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 11, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/OF_child.9 4.html b/static/freebsd/man9/OF_child.9 4.html
deleted file mode 100644
index 931a95f6..00000000
--- a/static/freebsd/man9/OF_child.9 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
OF_CHILD(9)Kernel Developer's ManualOF_CHILD(9)

-

-

-

-
OF_child,
-    OF_parent, OF_peer —
-    navigate device tree

-

-

-

-
#include
-    <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
phandle_t
-  

-  OF_child(phandle_t
-    node);

-
phandle_t
-  

-  OF_parent(phandle_t
-    node);

-
phandle_t
-  

-  OF_peer(phandle_t
-    node);

-

-

-

-
()
-    returns the phandle value of the first child of the
-    node. Zero is returned if there are no child
-  nodes.

-
()
-    returns the phandle for the parent of the node. Zero
-    is returned if node is the root node.

-
()
-    returns the phandle value of the next sibling of the
-    node. Zero is returned if there is no sibling
-  node.

-

-

-

-

-
phandle_t node, child;
- ...
-for (child = OF_child(node); child != 0; child = OF_peer(child) {
-	...
-}

-

-

-

-

-
OF_finddevice(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko
-    <gonzo@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 9, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/OF_device_from_xref.9 3.html b/static/freebsd/man9/OF_device_from_xref.9 3.html
deleted file mode 100644
index b6a0ec64..00000000
--- a/static/freebsd/man9/OF_device_from_xref.9 3.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
OF_DEVICE_FROM_XREF(9)Kernel Developer's ManualOF_DEVICE_FROM_XREF(9)

-

-

-

-
OF_device_from_xref,
-    OF_xref_from_device,
-    OF_device_register_xref
-    OF_device_unregister_xref —
-    manage mappings between xrefs and devices

-

-

-

-
#include
-    <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
int
-  

-  OF_device_register_xref(phandle_t
-    xref, device_t
-    dev);

-
void
-  

-  OF_device_unregister_xref(phandle_t
-    xref, device_t
-    dev);

-
device_t
-  

-  OF_device_from_xref(phandle_t
-    xref);

-
phandle_t
-  

-  OF_xref_from_device(device_t
-    dev);

-

-

-

-
When a device tree node references another node, the driver may
-    need to get a device_t instance associated with the referenced node. For
-    instance, an Ethernet driver accessing a PHY device. To make this possible,
-    the kernel maintains a table that maps effective handles to device_t
-    instances.

-
()
-    adds a map entry from the effective phandle xref to
-    device dev. If a mapping entry for
-    xref already exists, it is replaced with the new one.
-    The function always returns 0.

-
()
-    removes a map entry from the effective phandle xref to
-    device dev. If a mapping entry for
-    xref does not exists, it silently returns.

-
()
-    returns a device_t instance associated with the effective phandle
-    xref. If no such mapping exists, the function returns
-    NULL.

-
()
-    returns the effective phandle associated with the device
-    dev. If no such mapping exists, the function returns
-    0.

-

-

-

-

-
    static int
-    acmephy_attach(device_t dev)
-    {
-        phandle_t node;
-
-	/* PHY node is referenced from eth device, register it */
-        node = ofw_bus_get_node(dev);
-        OF_device_register_xref(OF_xref_from_node(node), dev);
-
-        return (0);
-    }

-

-

-

-

-
OF_node_to_xref(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko
-    <gonzo@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 3, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/OF_finddevice.9 4.html b/static/freebsd/man9/OF_finddevice.9 4.html
deleted file mode 100644
index 7bc1d29a..00000000
--- a/static/freebsd/man9/OF_finddevice.9 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
OF_FINDDEVICE(9)Kernel Developer's ManualOF_FINDDEVICE(9)

-

-

-

-
OF_finddevice —
-    find node in device tree

-

-

-

-
#include
-    <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
phandle_t
-  

-  OF_finddevice(const
-    char *path);

-

-

-

-
()
-    returns the phandle for the node specified by the
-    path. Returns -1 if the path cannot be found in the
-    tree.

-

-

-

-

-
    phandle_t root, i2c;
-
-    root = OF_finddevice("/");
-    i2c = OF_finddevice("/soc/axi/i2c@a0e0000");
-    if (i2c != -1) {
-        ...
-    }

-

-

-

-

-
OF_child(9), OF_parent(9),
-    OF_peer(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko
-    <gonzo@FreeBSD.org>.

-

-

-

-
The return value should only be checked with equality operators
-    (equal to, not equal to) and not relational comparison (less than, greater
-    than ). There is a discrepancy between IEEE 1275 standard and
-    FreeBSD's internal representation of a phandle: IEEE
-    1275 requires the return value of this function to be -1 if the path is not
-    found. But phandle_t is an unsigned type, so it cannot be relationally
-    compared with -1 or 0, this comparison is always true or always false.

-

-

-
-  
-    
-    
-  
-
April 9, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/OF_getprop.9 4.html b/static/freebsd/man9/OF_getprop.9 4.html
deleted file mode 100644
index 666a3bce..00000000
--- a/static/freebsd/man9/OF_getprop.9 4.html	
+++ /dev/null
@@ -1,293 +0,0 @@
-
-  
-    
-    
-    
-  
-
OF_GETPROP(9)Kernel Developer's ManualOF_GETPROP(9)

-

-

-

-
OF_getprop,
-    OF_getproplen,
-    OF_getencprop, OF_hasprop,
-    OF_searchprop,
-    OF_searchencprop,
-    OF_getprop_alloc,
-    OF_getencprop_alloc,
-    OF_getprop_alloc_multi,
-    OF_getencprop_alloc_multi,
-    OF_prop_free, OF_nextprop,
-    OF_setprop — access
-    properties of device tree node

-

-

-

-
#include
-    <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
ssize_t
-  

-  OF_getproplen(phandle_t
-    node, const char
-    *propname);

-
ssize_t
-  

-  OF_getprop(phandle_t
-    node, const char
-    *propname, void
-    *buf, size_t
-  len);

-
ssize_t
-  

-  OF_getencprop(phandle_t
-    node, const char
-    *prop, pcell_t
-    *buf, size_t
-  len);

-
bool
-  

-  OF_hasprop(phandle_t
-    node, const char
-    *propname);

-
ssize_t
-  

-  OF_searchprop(phandle_t
-    node, const char
-    *propname, void
-    *buf, size_t
-  len);

-
ssize_t
-  

-  OF_searchencprop(phandle_t
-    node, const char
-    *propname, pcell_t
-    *buf, size_t
-  len);

-
ssize_t
-  

-  OF_getprop_alloc(phandle_t
-    node, const char
-    *propname, void
-    **buf);

-
ssize_t
-  

-  OF_getencprop_alloc(phandle_t
-    node, const char
-    *propname, pcell_t
-    **buf);

-
ssize_t
-  

-  OF_getprop_alloc_multi(phandle_t
-    node, const char
-    *propname, int
-    elsz, void
-  **buf);

-
ssize_t
-  

-  OF_getencprop_alloc_multi(phandle_t
-    node, const char
-    *propname, int
-    elsz, pcell_t
-    **buf);

-
void
-  

-  OF_prop_free(void
-    *buf);

-
int
-  

-  OF_nextprop(phandle_t
-    node, const char
-    *propname, char
-    *buf, size_t
-  len);

-
int
-  

-  OF_setprop(phandle_t
-    node, const char
-    *propname, const void
-    *buf, size_t
-  len);

-

-

-

-
Device nodes can have associated properties. Properties consist of
-    a name and a value. A name is a human-readable string from 1 to 31
-    characters long. A value is an array of zero or more bytes that encode
-    certain information. The meaning of that bytes depends on how drivers
-    interpret them. Properties can encode byte arrays, text strings, unsigned
-    32-bit values or any combination of these types.

-
Property with a zero-length value usually represents boolean
-    information. If the property is present, it signifies true, otherwise
-  false.

-
A byte array is encoded as a sequence of bytes and represents
-    values like MAC addresses.

-
A text string is a sequence of n printable characters. It is
-    encoded as a byte array of length n + 1 bytes with characters represented as
-    bytes plus a terminating null character.

-
Unsigned 32-bit values, also sometimes called cells, are encoded
-    as a sequence of 4 bytes in big-endian order.

-
()
-    returns either the length of the value associated with the property
-    propname in the node identified by
-    node, or 0 if the property exists but has no
-    associated value. If propname does not exist, -1 is
-    returned.

-
()
-    copies a maximum of len bytes from the value
-    associated with the property propname of the device
-    node node into the memory specified by
-    buf. Returns the actual size of the value or -1 if the
-    property does not exist.

-
()
-    copies a maximum of len bytes into memory specified by
-    buf, then converts cell values from big-endian to host
-    byte order. Returns the actual size of the value in bytes, or -1 if the
-    property does not exist. len must be a multiple of
-  4.

-
()
-    returns true if the device node
-    node has a property specified by
-    propname, and false if the
-    property does not exist.

-
()
-    recursively looks for the property specified by
-    propname starting with the device node
-    node followed by the parent node and up to the root
-    node. If the property is found, the function copies a maximum of
-    len bytes of the value associated with the property
-    into the memory specified by buf. Returns the actual
-    size in bytes of the value, or -1 if the property does not exist.

-
()
-    recursively looks for the property specified by
-    propname starting with the device node
-    node followed by the parent node and up to the root
-    node. If the property is found, the function copies a maximum of
-    len bytes of the value associated with the property
-    into the memory specified by buf, then converts cell
-    values from big-endian to host byte order. Returns the actual size in bytes
-    of the value, or -1 if the property does not exist.

-
()
-    allocates memory large enough to hold the value associated with the property
-    propname of the device node node
-    and copies the value into the newly allocated memory region. Returns the
-    actual size of the value and stores the address of the allocated memory in
-    *buf. If the property has a zero-sized value
-    *buf is set NULL. Returns -1 if the property does not
-    exist or memory allocation failed. Allocated memory should be released when
-    no longer required by calling OF_prop_free(). The
-    function might sleep when allocating memory.

-
()
-    allocates enough memory to hold the value associated with the property
-    propname of the device node
-    node, copies the value into the newly allocated memory
-    region, and then converts cell values from big-endian to host byte order.
-    The actual size of the value is returned and the address of allocated memory
-    is stored in *buf. If the property has zero-length
-    value, *buf is set to NULL. Returns -1 if the property
-    does not exist or memory allocation failed or the size of the value is not
-    divisible by a cell size (4 bytes). Allocated memory should be released when
-    no longer required by calling OF_prop_free(). The
-    function might sleep when allocating memory.

-
()
-    allocates memory large enough to hold the value associated with the property
-    propname of the device node node
-    and copies the value into the newly allocated memory region. The value is
-    expected to be an array of zero or more elements elsz
-    bytes long. Returns the number of elements in the value and stores the
-    address of the allocated memory in *buf. If the
-    property has a zero-sized value *buf is set NULL.
-    Returns -1 if the property does not exist or memory allocation failed or the
-    size of the value is not divisible by elsz. Allocated
-    memory should be released when no longer required by calling
-    OF_prop_free(). The function might sleep when
-    allocating memory.

-
()
-    allocates memory large enough to hold the value associated with the property
-    propname of the device node node
-    and copies the value into the newly allocated memory region, and then
-    converts cell values from big-endian to host byte order. The value is
-    expected to be an array of zero or more elements elsz
-    bytes long. Returns the number of elements in the value and stores the
-    address of the allocated memory in *buf. If the
-    property has a zero-sized value *buf is set NULL.
-    Returns -1 if the property does not exist or memory allocation failed or the
-    size of the value is not divisible by elsz. Allocated
-    memory should be released when no longer required by calling
-    OF_prop_free(). The function might sleep when
-    allocating memory.

-
()
-    releases memory at buf that was allocated by
-    OF_getprop_alloc(),
-    OF_getencprop_alloc(),
-    OF_getprop_alloc_multi(),
-    OF_getencprop_alloc_multi().

-
()
-    copies a maximum of size bytes of the name of the
-    property following the propname property into
-    buf. If propname is NULL, the
-    function copies the name of the first property of the device node
-    node. OF_nextprop() returns -1
-    if propname is invalid or there is an internal error,
-    0 if there are no more properties after propname, or 1
-    otherwise.

-
()
-    sets the value of the property propname in the device
-    node node to the value beginning at the address
-    specified by buf and running for
-    len bytes. If the property does not exist, the
-    function tries to create it. OF_setprop() returns
-    the actual size of the new value, or -1 if the property value cannot be
-    changed or the new property cannot be created.

-

-

-

-

-
    phandle_t node;
-    phandle_t hdmixref, hdminode;
-    device_t hdmi;
-    uint8_t mac[6];
-    char *model;
-
-    /*
-     * Get a byte array property
-     */
-    if (OF_getprop(node, "eth,hwaddr", mac, sizeof(mac)) != sizeof(mac))
-        return;
-
-    /*
-     * Get internal node reference and device associated with it
-     */
-    if (OF_getencprop(node, "hdmi", &hdmixref) <= 0)
-        return;
-    hdmi = OF_device_from_xref(hdmixref);
-
-    /*
-     * Get string value of model property of HDMI framer node
-     */
-    hdminode = OF_node_from_xref(hdmixref);
-    if (OF_getprop_alloc(hdminode, "model", (void **)&model) <= 0)
-        return;

-

-

-

-

-
OF_device_from_xref(9),
-    OF_node_from_xref(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko
-    <gonzo@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 16, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/OF_node_from_xref.9 3.html b/static/freebsd/man9/OF_node_from_xref.9 3.html
deleted file mode 100644
index 853a528e..00000000
--- a/static/freebsd/man9/OF_node_from_xref.9 3.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
OF_NODE_FROM_XREF(9)Kernel Developer's ManualOF_NODE_FROM_XREF(9)

-

-

-

-
OF_node_from_xref,
-    OF_xref_from_node — convert
-    between kernel phandle and effective phandle

-

-

-

-
#include
-    <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
phandle_t
-  

-  OF_node_from_xref(phandle_t
-    xref);

-
phandle_t
-  

-  OF_xref_from_node(phandle_t
-    node);

-

-

-

-
Some OpenFirmware implementations (FDT, IBM) have a concept of
-    effective phandle or xrefs. They are used to cross-reference device tree
-    nodes. For instance, a framebuffer controller may refer to a GPIO controller
-    and pin that controls the backlight. In this example, the GPIO node would
-    have a cell (32-bit integer) property with a reserved name like
-    "phandle" or "linux,phandle" whose value uniquely
-    identifies the node. The actual name depends on the implementation. The
-    framebuffer node would have a property with the name described by device
-    bindings (device-specific set of properties). It can be a cell property or a
-    combined property with one part of it being a cell. The value of the
-    framebuffer node's property would be the same as the value of the GPIO
-    "phandle" property so it can be said that the framebuffer node
-    refers to the GPIO node. The kernel uses internal logic to assign unique
-    identifiers to the device tree nodes, and these values do not match the
-    values of "phandle" properties.
-    ()
-    and OF_xref_from_node() are used to perform
-    conversion between these two kinds of node identifiers.

-
()
-    returns the kernel phandle for the effective phandle
-    xref. If one cannot be found or the OpenFirmware
-    implementation does not support effective phandles, the function returns the
-    input value.

-
()
-    returns the effective phandle for the kernel phandle
-    node. If one cannot be found or the OpenFirmware
-    implementation does not support effective phandles, the function returns the
-    input value.

-

-

-

-

-
    phandle_t panelnode, panelxref;
-    char *model;
-
-    if (OF_getencprop(node, "lcd-panel", &panelxref) <= 0)
-        return;
-
-    panelnode = OF_node_from_xref(panelxref);
-    if (OF_getprop_alloc(hdminode, "model", (void **)&model) <= 0)
-        return;

-

-

-

-

-
OF_device_from_xref(9),
-    OF_device_register_xref(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko
-    <gonzo@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 9, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/OF_package_to_path.9 4.html b/static/freebsd/man9/OF_package_to_path.9 4.html
deleted file mode 100644
index b4f4f900..00000000
--- a/static/freebsd/man9/OF_package_to_path.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
OF_PACKAGE_TO_PATH(9)Kernel Developer's ManualOF_PACKAGE_TO_PATH(9)

-

-

-

-
OF_package_to_path —
-    get fully qualified path to a device tree node

-

-

-

-
#include
-    <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
ssize_t
-  

-  OF_package_to_path(phandle_t
-    node, char *buf,
-    size_t len);

-

-

-

-
()
-    copies at most len bytes of the fully qualified path
-    to the device tree node node into the memory specified
-    by buf. The function returns the number of bytes
-    copied or -1 in case of the error.

-

-

-

-
OF_finddevice(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko
-    <gonzo@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 9, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/PCI_IOV_ADD_VF.9 3.html b/static/freebsd/man9/PCI_IOV_ADD_VF.9 3.html
deleted file mode 100644
index b12d73ed..00000000
--- a/static/freebsd/man9/PCI_IOV_ADD_VF.9 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_IOV_ADD_VF(9)Kernel Developer's ManualPCI_IOV_ADD_VF(9)

-

-

-

-
PCI_IOV_ADD_VF —
-    inform a PF driver that a VF is being created

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include <sys/stdarg.h>
-  

-  #include <sys/nv.h>
-  

-  #include
-  <dev/pci/pci_iov.h>

-
int
-  

-  PCI_IOV_ADD_VF(device_t
-    dev, uint16_t
-    vfnum, const nvlist_t
-    *vf_config);

-

-

-

-
The
-    ()
-    method is called by the PCI Single-Root I/O Virtualization (SR-IOV)
-    infrastructure when it is initializing a new Virtual Function (VF) as a
-    child of the given Physical Function (PF) device. This method will not be
-    called until a successful call to PCI_IOV_INIT(9) has been
-    made. It is not guaranteed that this method will be called following a
-    successful call to PCI_IOV_INIT(9). If the infrastructure
-    encounters a failure to allocate resources following the call to
-    PCI_IOV_INIT(9), the VF creation will be aborted and
-    PCI_IOV_UNINIT(9) will be called immediately without any
-    preceding calls to PCI_IOV_ADD_VF.

-
The index of the VF being initialized is passed in the
-    vfnum argument. VFs are always numbered sequentially
-    starting at 0.

-
If the driver requested device-specific configuration parameters
-    via a VF schema in its call to pci_iov_attach(9), those
-    parameters will be contained in the vf_config
-    argument. All configuration parameters that were either set as required
-    parameters or that had a default value set in the VF schema are guaranteed
-    to be present in vf_config. Configuration parameters
-    that were neither set as required nor were given a default value are
-    optional and may or may not be present in vf_config.
-    vf_config will not contain any configuration
-    parameters that were not specified in the VF schema. All configuration
-    parameters will have the correct type and will be in the range of valid
-    values specified in the schema.

-
Note that it is possible for the user to set
-    different configuration values on different VF devices that are children of
-    the same PF. The PF driver must not cache configuration parameters passed in
-    previous calls to
-    ()
-    for other VFs and apply those parameters to the current VF.

-
This function will not be called twice for the same
-    vf_num on the same PF device without
-    PCI_IOV_UNINIT(9) and PCI_IOV_INIT(9)
-    first being called, in that order.

-

-

-

-
This method returns 0 on success, otherwise an appropriate error
-    is returned. If this method returns an error then the current VF device will
-    be destroyed but the rest of the VF devices will be created and SR-IOV will
-    be enabled on the PF.

-

-

-

-
nv(9), pci(9),
-    PCI_IOV_INIT(9), pci_iov_schema(9),
-    PCI_IOV_UNINIT(9)

-

-

-

-
This manual page was written by Ryan Stone
-    <rstone@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
May 28, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/PCI_IOV_INIT.9 4.html b/static/freebsd/man9/PCI_IOV_INIT.9 4.html
deleted file mode 100644
index 843fb125..00000000
--- a/static/freebsd/man9/PCI_IOV_INIT.9 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_IOV_INIT(9)Kernel Developer's ManualPCI_IOV_INIT(9)

-

-

-

-
PCI_IOV_INIT —
-    enable SR-IOV on a PF device

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include <sys/stdarg.h>
-  

-  #include <sys/nv.h>
-  

-  #include
-  <dev/pci/pci_iov.h>

-
int
-  

-  PCI_IOV_INIT(device_t
-    dev, uint16_t
-    num_vfs, const nvlist_t
-    *pf_config);

-

-

-

-
The
-    ()
-    method is called by the PCI Single-Root I/O Virtualization (SR-IOV)
-    infrastructure when the user requests that SR-IOV be enabled on a Physical
-    Function (PF). The number of Virtual Functions (VFs) that will be created is
-    passed to this method in the num_vfs argument.

-
If the driver requested device-specific PF configuration
-    parameters via a PF schema in its call to
-    pci_iov_attach(9), those parameters will be available in
-    the pf_config argument. All configuration parameters
-    that were either set as required parameters or that had a default value set
-    in the PF schema are guaranteed to be present in
-    pf_config. Configuration parameters that were neither
-    set as required nor were given a default value are optional and may or may
-    not be present in pf_config.
-    pf_config will not contain any configuration
-    parameters that were not specified in the PF schema. All configuration
-    parameters will have the correct type and are in the range of valid values
-    specified in the schema.

-
If this method returns successfully, then this method will not be
-    called again on the same device until after a call to
-    PCI_IOV_UNINIT(9).

-

-

-

-
Returns 0 on success, otherwise an appropriate error is returned.
-    If this method returns an error then the SR-IOV configuration will be
-    aborted and no VFs will be created.

-

-

-

-
nv(9), pci(9),
-    PCI_IOV_ADD_VF(9), pci_iov_schema(9),
-    PCI_IOV_UNINIT(9)

-

-

-

-
This manual page was written by Ryan Stone
-    <rstone@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
May 28, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/PCI_IOV_UNINIT.9 4.html b/static/freebsd/man9/PCI_IOV_UNINIT.9 4.html
deleted file mode 100644
index fbbfea09..00000000
--- a/static/freebsd/man9/PCI_IOV_UNINIT.9 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_IOV_UNINIT(9)Kernel Developer's ManualPCI_IOV_UNINIT(9)

-

-

-

-
PCI_IOV_UNINIT —
-    disable SR-IOV on a PF device

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include
-  <dev/pci/pci_iov.h>

-
void
-  

-  PCI_IOV_UNINIT(device_t
-    dev);

-

-

-

-
The
-    ()
-    method is called by the PCI Single-Root I/O Virtualization (SR-IOV)
-    infrastructure when the user requests that SR-IOV be disabled on a Physical
-    Function (PF). When this method is called, the PF driver must release any
-    SR-IOV-related resources that it has allocated and disable any
-    device-specific SR-IOV configuration in the device.

-
This method will only be called following a successful call to
-    PCI_IOV_INIT(9). It is not guaranteed that
-    PCI_IOV_ADD_VF(9) will have been called for any Virtual
-    Function (VF) after the call to PCI_IOV_INIT(9) and before
-    the call to PCI_IOV_UNINIT.

-

-

-

-
pci(9), PCI_IOV_ADD_VF(9),
-    PCI_IOV_INIT(9)

-

-

-

-
This manual page was written by Ryan Stone
-    <rstone@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
May 28, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/PHOLD.9 4.html b/static/freebsd/man9/PHOLD.9 4.html
deleted file mode 100644
index 1a3a6496..00000000
--- a/static/freebsd/man9/PHOLD.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
PHOLD(9)Kernel Developer's ManualPHOLD(9)

-

-

-

-
PHOLD — hold a
-    process

-

-

-

-
#include
-    <sys/proc.h>

-
PHOLD(struct
-    proc *p);

-
_PHOLD(struct
-    proc *p);

-
PRELE(struct
-    proc *p);

-
_PRELE(struct
-    proc *p);

-
PROC_ASSERT_HELD(struct
-    proc *p);

-
PROC_ASSERT_NOT_HELD(struct
-    proc *p);

-

-

-

-
The
-    ()
-    macro increments the hold count of a process, and the
-    ()
-    macro decrements the hold count of a process.

-
If a process with a non-zero hold count attempts to exit, it will
-    sleep until its hold count has reached zero before the kernel begins
-    releasing resources associated with the process. Once a process has started
-    exiting, it is invalid to increase its hold count. Thus, callers must not
-    attempt to hold a process that has the P_WEXIT flag
-    set. The VM daemon will not swap out the kernel stack of a thread belonging
-    to a process with a non-zero hold count.

-
The
-    () and
-    ()
-    macros are identical to PHOLD() and
-    PRELE(), except that they must be called with the
-    process lock held.

-

-

-

-
This manual page was written by Mark
-    Johnston
-    <markj@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 7, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/SDT.9 4.html b/static/freebsd/man9/SDT.9 4.html
deleted file mode 100644
index 0136d64e..00000000
--- a/static/freebsd/man9/SDT.9 4.html	
+++ /dev/null
@@ -1,460 +0,0 @@
-
-  
-    
-    
-    
-  
-
SDT(9)Kernel Developer's ManualSDT(9)

-

-

-

-
SDT — a DTrace
-    framework for adding statically-defined tracing probes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/queue.h>
-  

-  #include <sys/sdt.h>

-
SDT_PROVIDER_DECLARE(prov);

-
SDT_PROVIDER_DEFINE(prov);

-
SDT_PROBE_DECLARE(prov,
-    mod,
-    func,
-    name);

-
SDT_PROBE_DEFINE(prov,
-    mod,
-    func,
-    name);

-
SDT_PROBE_DEFINE0(prov,
-    mod,
-    func,
-    name);

-
SDT_PROBE_DEFINE1(prov,
-    mod,
-    func,
-    name,
-    arg0);

-
SDT_PROBE_DEFINE2(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1);

-
SDT_PROBE_DEFINE3(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2);

-
SDT_PROBE_DEFINE4(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3);

-
SDT_PROBE_DEFINE5(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3,
-    arg4);

-
SDT_PROBE_DEFINE6(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3,
-    arg4,
-    arg5);

-
SDT_PROBE_DEFINE7(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3,
-    arg4,
-    arg5,
-    arg6);

-
SDT_PROBE_DEFINE0_XLATE(prov,
-    mod,
-    func,
-    name);

-
SDT_PROBE_DEFINE1_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0);

-
SDT_PROBE_DEFINE2_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0,
-    arg1,
-    xarg1);

-
SDT_PROBE_DEFINE3_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0,
-    arg1,
-    xarg1,
-    arg2,
-    xarg2);

-
SDT_PROBE_DEFINE4_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0,
-    arg1,
-    xarg1,
-    arg2,
-    xarg2,
-    arg3,
-    xarg3);

-
SDT_PROBE_DEFINE5_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0,
-    arg1,
-    xarg1,
-    arg2,
-    xarg2,
-    arg3,
-    xarg3,
-    arg4,
-    xarg4);

-
SDT_PROBE_DEFINE6_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0,
-    arg1,
-    xarg1,
-    arg2,
-    xarg2,
-    arg3,
-    xarg3,
-    arg4,
-    xarg4,
-    arg5,
-    xarg5);

-
SDT_PROBE_DEFINE7_XLATE(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    xarg0,
-    arg1,
-    xarg1,
-    arg2,
-    xarg2,
-    arg3,
-    xarg3,
-    arg4,
-    xarg4,
-    arg5,
-    xarg5,
-    arg6,
-    xarg6);

-
SDT_PROBE0(prov,
-    mod,
-    func,
-    name);

-
SDT_PROBE1(prov,
-    mod,
-    func,
-    name,
-    arg0);

-
SDT_PROBE2(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1);

-
SDT_PROBE3(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2);

-
SDT_PROBE4(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3);

-
SDT_PROBE5(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3,
-    arg4);

-
SDT_PROBE6(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3,
-    arg4,
-    arg5);

-
SDT_PROBE7(prov,
-    mod,
-    func,
-    name,
-    arg0,
-    arg1,
-    arg2,
-    arg3,
-    arg4,
-    arg5,
-    arg6);

-

-

-

-
The SDT macros allow programmers to define
-    static trace points in kernel code. These trace points are used by the
-    SDT framework to create DTrace probes, allowing the
-    code to be instrumented using dtrace(1). By default,
-    SDT trace points are disabled and have no effect on
-    the surrounding code. When a DTrace probe corresponding to a given trace
-    point is enabled, threads that execute the trace point will call a handler
-    and cause the probe to fire. Moreover, trace points can take arguments,
-    making it possible to pass data to the DTrace framework when an enabled
-    probe fires.

-
Multiple trace points may correspond to a single DTrace probe,
-    allowing programmers to create DTrace probes that correspond to logical
-    system events rather than tying probes to specific code execution paths. For
-    instance, a DTrace probe corresponding to the arrival of an IP packet into
-    the network stack may be defined using two SDT trace
-    points: one for IPv4 packets and one for IPv6 packets.

-
In addition to defining DTrace probes, the
-    SDT macros allow programmers to define new DTrace
-    providers, making it possible to namespace logically-related probes. An
-    example is FreeBSD's sctp provider, which contains
-    SDT probes for FreeBSD's sctp(4)
-    implementation.

-
The
-    ()
-    and
-    ()
-    macros are used respectively to declare and define a DTrace provider named
-    prov with the SDT framework. A
-    provider need only be defined once; however, the provider must be declared
-    before defining any SDT probes belonging to that
-    provider.

-
Similarly, the
-    ()
-    and SDT_PROBE_DEFINE*() macros are used to declare
-    and define DTrace probes using the SDT framework.
-    Once a probe has been defined, trace points for that probe may be added to
-    kernel code. DTrace probe identifiers consist of a provider, module,
-    function and name, all of which may be specified in the
-    SDT probe definition. Note that probes should not
-    specify a module name: the module name of a probe is used to determine
-    whether or not it should be destroyed when a kernel module is unloaded. See
-    the BUGS section. Note in particular that
-    probes must not be defined across multiple kernel modules.

-
If ‘-’ character
-    (dash) is wanted in a probe name, then it should be represented as
-    ‘__’ (double underscore) in the probe
-    name parameter passed to various
-    ()
-    macros, because of technical reasons (a dash is not valid in C
-  identifiers).

-
The
-    ()
-    macros also allow programmers to declare the types of the arguments that are
-    passed to probes. This is optional; if the argument types are omitted
-    (through use of the
-    ()
-    macro), users wishing to make use of the arguments will have to manually
-    cast them to the correct types in their D scripts. It is strongly
-    recommended that probe definitions include a declaration of their argument
-    types.

-
The
-    ()
-    macros are used for probes whose argument types are to be dynamically
-    translated to the types specified by the corresponding
-    xarg arguments. This is mainly useful when porting
-    probe definitions from other operating systems. As seen by
-    dtrace(1), the arguments of a probe defined using these
-    macros will have types which match the xarg types in
-    the probe definition. However, the arguments passed in at the trace point
-    will have types matching the native argument types in the probe definition,
-    and thus the native type is dynamically translated to the translated type.
-    So long as an appropriate translator is defined in
-    /usr/lib/dtrace, scripts making use of the probe
-    need not concern themselves with the underlying type of a given
-    SDT probe argument.

-
The
-    ()
-    macros are used to create SDT trace points. They are
-    meant to be added to executable code and can be used to instrument the code
-    in which they are called.

-

-

-

-
A number of kernel DTrace providers are available. In general,
-    these providers define stable interfaces and should be treated as such:
-    existing D scripts may be broken if a probe is renamed or its arguments are
-    modified. However, it is often useful to define ad-hoc
-    SDT probes for debugging a subsystem or driver.
-    Similarly, a developer may wish to provide a group of
-    SDT probes without committing to their future
-    stability. Such probes should be added to the
-    ‘sdt’ provider instead of defining a
-    new provider.

-

-

-

-
The DTrace providers available on the current system can be listed
-    with

-

-
dtrace -l | sed 1d | awk '{print $2}' | sort -u

-

-
A detailed list of the probes offered by a given provider can be
-    obtained by specifying the provider using the -P
-    flag. For example, to view the probes and argument types for the
-    ‘sched’ provider, run

-

-
dtrace -lv -P sched

-

-
The following probe definition will create a DTrace probe called
-    ‘icmp:::receive-unreachable’, which
-    would hypothetically be triggered when the kernel receives an ICMP packet of
-    type Destination Unreachable:

-

-
SDT_PROVIDER_DECLARE(icmp);
-
-SDT_PROBE_DEFINE1(icmp, , , receive__unreachable,
-    "struct icmp *");
-
-

-

-This particular probe would take a single argument: a pointer to the struct
-  containing the ICMP header for the packet. Note that the module name of this
-  probe is not specified.
-
Consider a DTrace probe which fires when the network stack
-    receives an IP packet. Such a probe would be defined by multiple
-    tracepoints:

-

-
SDT_PROBE_DEFINE3(ip, , , receive, "struct ifnet *",
-    "struct ip *", "struct ip6_hdr *");
-
-int
-ip_input(struct mbuf *m)
-{
-	struct ip *ip;
-	...
-	ip = mtod(m, struct ip *);
-	SDT_PROBE3(ip, , , receive, m->m_pkthdr.rcvif, ip, NULL);
-	...
-}
-
-int
-ip6_input(struct mbuf *m)
-{
-	struct ip6_hdr *ip6;
-	...
-	ip6 = mtod(m, struct ip6_hdr *);
-	SDT_PROBE3(ip, , , receive, m->m_pkthdr.rcvif, NULL, ip6);
-	...
-}
-
-

-

-In particular, the probe should fire when the kernel receives either an IPv4
-  packet or an IPv6 packet.
-
Consider the ICMP probe discussed above. We note that its second
-    argument is of type struct icmp, which is a type
-    defined in the FreeBSD kernel to represent the ICMP header of an ICMP
-    packet, defined in RFC 792. Linux has a corresponding type,
-    struct icmphdr, for the same purpose, but its field
-    names differ from FreeBSD's struct icmp. Similarly,
-    illumos defines the icmph_t type, again with different
-    field names. Even with the
-    ‘icmp:::pkt-receive’ probes defined in
-    all three operating systems, one would still have to write OS-specific
-    scripts to extract a given field out of the ICMP header argument.
-    Dynamically-translated types solve this problem: one can define an
-    OS-independent c(7) struct to represent an ICMP header,
-    say struct icmp_hdr_dt, and define translators from
-    each of the three OS-specific types to struct
-    icmp_hdr_dt, all in the dtrace(1) library path. Then
-    the FreeBSD probe above can be defined with:

-

-
SDT_PROBE_DEFINE1_XLATE(ip, , , receive, "struct icmp *",
-    "struct icmp_hdr_dt *");

-

-

-

-

-
dtrace(1), dtrace_io(4),
-    dtrace_ip(4), dtrace_proc(4),
-    dtrace_sched(4), dtrace_tcp(4),
-    dtrace_udp(4)

-

-

-

-
DTrace and the SDT framework were
-    originally ported to FreeBSD from Solaris by John
-    Birrell
-    <jb@FreeBSD.org>. This
-    manual page was written by Mark Johnston
-    <markj@FreeBSD.org>.

-

-

-

-
The SDT macros allow the module and
-    function names of a probe to be specified as part of a probe definition. The
-    DTrace framework uses the module name of probes to determine which probes
-    should be destroyed when a kernel module is unloaded, so the module name of
-    a probe should match the name of the module in which its defined.
-    SDT will set the module name properly if it is left
-    unspecified in the probe definition; see the
-    EXAMPLES section.

-
One of the goals of the original SDT
-    implementation (and by extension, of FreeBSD's port) is that inactive
-    SDT probes should have no performance impact. This
-    is unfortunately not the case; SDT trace points will
-    add a small but non-zero amount of latency to the code in which they are
-    defined. A more sophisticated implementation of the probes will help
-    alleviate this problem.

-

-

-
-  
-    
-    
-  
-
April 18, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/SYSCALL_MODULE.9 4.html b/static/freebsd/man9/SYSCALL_MODULE.9 4.html
deleted file mode 100644
index 5bdef86e..00000000
--- a/static/freebsd/man9/SYSCALL_MODULE.9 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSCALL_MODULE(9)Kernel Developer's ManualSYSCALL_MODULE(9)

-

-

-

-
SYSCALL_MODULE —
-    syscall kernel module declaration macro

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/proc.h>
-  

-  #include <sys/module.h>
-  

-  #include <sys/sysent.h>

-
SYSCALL_MODULE(name,
-    int *offset,
-    struct sysent
-    *new_sysent,
-    modeventhand_t evh,
-    void *arg);

-

-

-

-
The
-    ()
-    macro declares a new syscall. SYSCALL_MODULE()
-    expands into a kernel module declaration with name
-    ‘sys/name’.

-
The rest of the arguments expected by this macro are:

-

-  
offset

-  
A pointer to an int which saves the offset in
-      struct sysent where the syscall is allocated. If the
-      location pointed to by offset holds a non 0 number
-      it will be used if possible. If it holds 0 then one will be assigned.

-  
new_sysent

-  
is a pointer to a structure that specifies the function implementing the
-      syscall and the number of arguments this function needs (see
-      <sys/sysent.h>).

-  
evh

-  
A pointer to the kernel module event handler function with the argument
-      arg. Please refer to module(9) for
-      more information.

-  
arg

-  
The argument passed to the callback functions of the
-      evh event handler when it is called.

-

-
The syscall number assigned to the
-    module can be retrieved using the modstat(2) and
-    modfind(2) system calls. The MACRO
-    ()
-    includes SYSCALL_MODULE() and much of its
-    boilerplate code.

-

-

-

-
A minimal example for a syscall module can be found in
-    /usr/share/examples/kld/syscall/module/syscall.c.

-

-

-

-
module(9)

-
/usr/share/examples/kld/syscall/module/syscall.c

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 15, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/SYSINIT.9 3.html b/static/freebsd/man9/SYSINIT.9 3.html
deleted file mode 100644
index 11f20b24..00000000
--- a/static/freebsd/man9/SYSINIT.9 3.html	
+++ /dev/null
@@ -1,138 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSINIT(9)Kernel Developer's ManualSYSINIT(9)

-

-

-

-
SYSINIT, SYSUNINIT
-    — a framework for dynamic kernel
-    initialization

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>

-
SYSINIT(uniquifier,
-    enum sysinit_sub_id
-    subsystem, enum
-    sysinit_elem_order order,
-    sysinit_cfunc_t func,
-    const void *ident);

-
SYSUNINIT(uniquifier,
-    enum sysinit_sub_id
-    subsystem, enum
-    sysinit_elem_order order,
-    sysinit_cfunc_t func,
-    const void *ident);

-

-

-

-
SYSINIT is a mechanism for scheduling the
-    execution of initialization and teardown routines. This is similar to init
-    and fini routines with the addition of explicit ordering metadata. It allows
-    runtime ordering of subsystem initialization in the kernel as well as kernel
-    modules (KLDs).

-
The
-    ()
-    macro creates a struct sysinit and stores it in a
-    startup linker set. The struct sysinit type as well as
-    the subsystem identifier constants (SI_SUB_*) and
-    initialization ordering constants (SI_ORDER_*) are
-    defined in
-  <sys/kernel.h>:

-

-
struct sysinit {
-	enum sysinit_sub_id subsystem;	/* subsystem identifier*/
-	enum sysinit_elem_order	order;	/* init order within subsystem*/
-	SLIST_ENTRY(sysinit) next;	/* singly-linked list */
-	sysinit_cfunc_t func;		/* function             */
-	const void	*udata;		/* multiplexer/argument */
-};

-

-
The
-    ()
-    macro takes a uniquifier argument to identify the
-    particular function dispatch data, the subsystem type
-    of startup interface, the subsystem element order of
-    initialization within the subsystem, the func function
-    to call, and the data specified in ident argument to
-    pass the function.

-
The
-    ()
-    macro behaves similarly to the SYSINIT() macro
-    except that it adds the data to a shutdown linker set.

-
The startup linker set for the kernel is scanned during boot to
-    build a sorted list of initialization routines. The initialization routines
-    are then executed in the sorted order. The subsystem
-    is used as the primary key and is sorted in ascending order. The
-    order is used as the secondary key and is sorted in
-    ascending order. The relative order of two routines that have the same
-    subsystem and order is
-    undefined.

-
The startup linker sets for modules that are loaded together with
-    the kernel by the boot loader are scanned during the
-    SI_SUB_KLD subsystem initialization. These modules'
-    initialization routines are sorted and merged into the kernel's list of
-    startup routines and are executed during boot along with the kernel's
-    initialization routines. Note that this has the effect that any
-    initialization routines in a kernel module that are scheduled earlier than
-    SI_SUB_KLD are not executed until after
-    SI_SUB_KLD during boot.

-
The startup linker set for a kernel module loaded at runtime via
-    kldload(2) is scanned, sorted, and executed when the
-    module is loaded.

-
The shutdown linker set for a kernel module is scanned,
-    sorted, and executed when a kernel module is unloaded. The teardown routines
-    are sorted in the reverse order of the initialization routines. The teardown
-    routines of the kernel and any loaded modules are
-     executed during
-    shutdown.

-

-

-

-
This example shows the SYSINIT which displays the copyright notice
-    during boot:

-

-
static void
-print_caddr_t(void *data)
-{
-	printf("%s", (char *)data);
-}
-SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t,
-    copyright);

-

-

-

-

-
kld(4), DECLARE_MODULE(9),
-    DEV_MODULE(9), DRIVER_MODULE(9),
-    MTX_SYSINIT(9), SYSCALL_MODULE(9)

-

-

-

-
The SYSINIT framework first appeared in
-    FreeBSD 2.2.

-

-

-

-
The SYSINIT framework was written by
-    Terrence Lambert
-    <terry@FreeBSD.org>.

-
This manual page was written by Hiten
-    Pandya
-    <hmp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 1, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS.9 4.html b/static/freebsd/man9/VFS.9 4.html
deleted file mode 100644
index 34e22d39..00000000
--- a/static/freebsd/man9/VFS.9 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS(9)Kernel Developer's ManualVFS(9)

-

-

-

-
VFS — kernel
-    interface to file systems

-

-

-

-
Calls used to set or query file systems for settings or
-    information.

-
File systems that do not implement a VFS operation should use the
-    appropriate vfs_std function from
-    src/sys/kern/vfs_default.c rather than implementing
-    empty functions or casting to eopnotsupp.

-

-

-

-
dtrace_vfs(4),
-    VFS_CHECKEXP(9), VFS_FHTOVP(9),
-    VFS_MOUNT(9), VFS_QUOTACTL(9),
-    VFS_SET(9), VFS_STATFS(9),
-    VFS_SYNC(9), VFS_UNMOUNT(9),
-    VFS_VGET(9), vnode(9),
-    VOP_VPTOFH(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
November 3, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_CHECKEXP.9 4.html b/static/freebsd/man9/VFS_CHECKEXP.9 4.html
deleted file mode 100644
index 7c2e87d1..00000000
--- a/static/freebsd/man9/VFS_CHECKEXP.9 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_CHECKEXP(9)Kernel Developer's ManualVFS_CHECKEXP(9)

-

-

-

-
VFS_CHECKEXP —
-    check if a file system is exported to a client

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  VFS_CHECKEXP(struct mount *mp,
-    struct sockaddr *nam, uint64_t
-    *exflagsp, struct ucred **credanonp,
-    int *numsecflavor, int
-    *secflavors);

-

-

-

-
The
-    ()
-    macro is used by the NFS server to check if a mount point is exported to a
-    client.

-
The arguments it expects are:

-

-  
mp

-  
The mount point to be checked.

-  
nam

-  
An mbuf containing the network address of the client.

-  
exflagsp

-  
Return parameter for the export flags for this client.

-  
credanonp

-  
Return parameter for the anonymous credentials for this client.

-  
numsecflavors

-  
Return value for the number of security flavors for this client.

-  
secflavors

-  
Must be an array of size MAXSECFLAVORS, in which the security flavors for
-      this client are returned.

-

-
The
-    ()
-    macro should be called on a file system's mount structure to determine if it
-    is exported to a client whose address is contained in
-    nam.

-
It is called in the NFS server once a vnode for a file handle has
-    been acquired, in order to determine what access the client is allowed on
-    the file system the vnode resides in. For NFSv4, it is also called whenever
-    the lookup operation crosses a server file system mount point, to update the
-    access information.

-
The operation is file system specific, but is normally handled by
-    the default ``vfs_stdcheckexp''.

-

-

-

-
The export flags, anonymous credentials and security flavors
-    specific to the client will be returned in *exflagsp,
-    *credanonp, *numsecflavors and
-    *secflavors.

-

-

-

-
VFS(9), VFS_FHTOVP(9),
-    vnode(9), VOP_VPTOFH(9)

-

-

-

-
This manual page was written by Alfred
-    Perlstein.

-

-

-
-  
-    
-    
-  
-
June 17, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_FHTOVP.9 3.html b/static/freebsd/man9/VFS_FHTOVP.9 3.html
deleted file mode 100644
index bfa3ef89..00000000
--- a/static/freebsd/man9/VFS_FHTOVP.9 3.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_FHTOVP(9)Kernel Developer's ManualVFS_FHTOVP(9)

-

-

-

-
VFS_FHTOVP — turn
-    an NFS filehandle into a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_FHTOVP(struct
-    mount *mp, struct fid
-    *fhp, int flags,
-    struct vnode **vpp);

-

-

-

-
The
-    ()
-    macro is used by the NFS server to turn an NFS filehandle into a vnode.

-
The arguments it expects are:

-

-  
mp

-  
The file system.

-  
fhp

-  
The filehandle to convert.

-  
flags

-  
Additional locking flags to pass through to vget(9).
-      File systems are allowed to ignore flags and use
-      LK_EXCLUSIVE instead.

-  
vpp

-  
Return parameter for the new locked vnode.

-

-
The contents of the filehandle are defined by the file system and
-    are not examined by any other part of the system. It should contain enough
-    information to uniquely identify a file within the file system as well as
-    noticing when a file has been removed and the file system resources have
-    been reused for a new file. For instance, UFS file system stores the inode
-    number and inode generation counter in its filehandle.

-
A call to
-    ()
-    should generally be preceded by a call to VFS_CHECKEXP(9)
-    to check if the file is accessible to the client.

-

-

-

-
The locked vnode for the file will be returned in
-    *vpp.

-

-

-

-
VFS(9), VFS_CHECKEXP(9),
-    vnode(9), VOP_VPTOFH(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 19, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_MOUNT.9 4.html b/static/freebsd/man9/VFS_MOUNT.9 4.html
deleted file mode 100644
index 4c126b11..00000000
--- a/static/freebsd/man9/VFS_MOUNT.9 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_MOUNT(9)Kernel Developer's ManualVFS_MOUNT(9)

-

-

-

-
VFS_MOUNT — mount
-    a file system

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_MOUNT(struct
-    mount *mp);

-

-

-

-
The
-    ()
-    macro mounts a file system into the system's namespace or updates the
-    attributes of an already mounted file system.

-
The arguments it expects are:

-

-  
mp

-  
Structure representing the file system.

-

-
The
-    ()
-    macro is called both to mount new file systems and to change the attributes
-    of an existing file system. If the MNT_UPDATE flag
-    is set in mp->mnt_flag then the file system should
-    update its internal state from the value of
-    mp->mnt_flag. This can be used, for instance, to
-    convert a read-only file system to read-write. It is also used by
-    mountd(8) to update the NFS export information for the
-    file system.

-
If the MNT_UPDATE flag is not specified,
-    then this is a newly mounted file system. The file system code should
-    allocate and initialize any private data needed to represent the file system
-    (it can use the mp->mnt_data field to store this
-    information).

-

-

-

-
VFS(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 23, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_QUOTACTL.9 4.html b/static/freebsd/man9/VFS_QUOTACTL.9 4.html
deleted file mode 100644
index cc166046..00000000
--- a/static/freebsd/man9/VFS_QUOTACTL.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_QUOTACTL(9)Kernel Developer's ManualVFS_QUOTACTL(9)

-

-

-

-
VFS_QUOTACTL —
-    manipulate file system quotas

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_QUOTACTL(struct
-    mount *mp, int
-    cmds, uid_t uid,
-    void *arg,
-    bool *mp_busy);

-

-

-

-
Implement file system quotas.

-
The mp_busy argument is an
-    input/output parameter.
-    ()
-    must be called with mp marked busy through
-    vfs_busy(9) and *mp_busy set to
-    true. The filesystem implementation of
-    VFS_QUOTACTL() may then unbusy
-    mp using vfs_unbusy(9) prior to
-    performing quota file I/O. In this case the implementation must set
-    *mp_busy to false to indicate that the caller must not
-    unbusy mp upon completion of
-    VFS_QUOTACTL().

-
See quotactl(2) for a description of the
-    remaining arguments.

-

-

-

-
quotactl(2), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 29, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_ROOT.9 4.html b/static/freebsd/man9/VFS_ROOT.9 4.html
deleted file mode 100644
index a9abbf84..00000000
--- a/static/freebsd/man9/VFS_ROOT.9 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_ROOT(9)Kernel Developer's ManualVFS_ROOT(9)

-

-

-

-
VFS_ROOT — return
-    the root vnode of a file system

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_ROOT(struct
-    mount *mp, int
-    flags, struct vnode
-    **vpp);

-

-

-

-
Return a locked vnode for the root directory of the file
-  system.

-
Its arguments are:

-

-  
mp

-  
The file system.

-  
flags

-  
The lock type. Could be LK_EXCLUSIVE or
-      LK_SHARED. File system is free to ignore the
-      flags argument and instead acquire an exclusive
-      lock.

-  
vpp

-  
Return parameter for the root vnode.

-

-

-

-

-
VFS(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 23, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_SET.9 4.html b/static/freebsd/man9/VFS_SET.9 4.html
deleted file mode 100644
index 99b6181c..00000000
--- a/static/freebsd/man9/VFS_SET.9 4.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_SET(9)Kernel Developer's ManualVFS_SET(9)

-

-

-

-
VFS_SET — set up
-    loadable file system vfsconf

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/module.h>
-  

-  #include <sys/mount.h>

-
void
-  

-  VFS_SET(struct
-    vfsops *vfsops,
-    fsname,
-    int flags);

-

-

-

-
()
-    creates a vfsconf structure for the loadable module
-    with the given vfsops, fsname
-    and flags, and declares it by calling
-    DECLARE_MODULE(9) using
-    ()
-    as the event handler.

-
Possible values for the flags argument
-  are:

-

-  

-  
File system should be statically available in the kernel.

-  

-  
Network exportable file system.

-  

-  
Does not support write operations.

-  

-  
Pseudo file system, data does not represent on-disk files.

-  

-  
Loopback file system layer.

-  

-  
File names are stored as Unicode.

-  

-  
Can be mounted from within a jail if allow.mount and
-      allow.mount.<fsname> jail parameters are
-    set.

-  

-  
Supports delegated administration if vfs.usermount
-      sysctl is set to 1.

-  

-  
When in VFS method, the thread suspension is deferred to the user boundary
-      upon arrival of stop action.

-

-

-

-

-

-
/*
- * Fill in the fields for which we have special methods.
- * The others are initially null.  This tells vfs to change them to
- * pointers to vfs_std* functions during file system registration.
- */
-static struct vfsops myfs_vfsops = {
-        .vfs_mount =    myfs_mount,
-        .vfs_root =     myfs_root,
-        .vfs_statfs =   myfs_statfs,
-        .vfs_unmount =  myfs_unmount,
-};
-
-VFS_SET(myfs_vfsops, myfs, 0);

-

-

-

-

-
jail(2), jail(8),
-    DECLARE_MODULE(9), vfs_modevent(9),
-    vfsconf(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
August 16, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_STATFS.9 4.html b/static/freebsd/man9/VFS_STATFS.9 4.html
deleted file mode 100644
index b83ae5fd..00000000
--- a/static/freebsd/man9/VFS_STATFS.9 4.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_STATFS(9)Kernel Developer's ManualVFS_STATFS(9)

-

-

-

-
VFS_STATFS —
-    return file system status

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_STATFS(struct
-    mount *mp, struct statfs
-    *sbp);

-

-

-

-
The
-    ()
-    macro returns various pieces of information about the file system, including
-    recommended I/O sizes, free space, free inodes, etc.

-
The arguments it expects are:

-

-  
mp

-  
The file system.

-  
sbp

-  
A statfs structure, as defined by
-      <sys/mount.h>, into which
-      information is placed about the file system.

-

-
The fields of struct statfs related to the
-    file system are as follows:

-

-  
f_type

-  
Type of file system.

-  
f_flags

-  
A copy of mount exported flags.

-  
f_bsize

-  
Fragment size.

-  
f_iosize

-  
Optimal transfer block size.

-  
f_blocks

-  
The total number of data blocks in the file system.

-  
f_bfree

-  
The number of free blocks in the file system.

-  
f_bavail

-  
The number of free blocks available to non-superuser processes.

-  
f_files

-  
The total number of file nodes in the file system.

-  
f_ffree

-  
The number of free nodes available to non-superuser processes.

-  
f_syncwrites

-  
The number of synchronous writes since the file system was mounted.

-  
f_asyncwrites

-  
The number of asynchronous writes since the file system was mounted.

-  
f_syncreads

-  
The number of synchronous reads since the file system was mounted.

-  
f_asyncreads

-  
The number of asynchronous reads since the file system was mounted.

-  
f_namemax

-  
The maximum file name length for this file system.

-  
f_owner

-  
The user ID of the user that mounted the file system.

-  
f_fsid

-  
Unique file system ID.

-  
f_fstypename

-  
The file system type name; a string of at most
-      MFSNAMELEN bytes.

-  
f_mntfromname

-  
The device name the file system was mounted from; a string of at most
-      MNAMELEN bytes.

-  
f_mntonname

-  
The name of the directory on which the file system is mounted; a string of
-      at most MNAMELEN bytes.

-

-

-

-

-
VFS(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 23, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_SYNC.9 4.html b/static/freebsd/man9/VFS_SYNC.9 4.html
deleted file mode 100644
index 7d0c105d..00000000
--- a/static/freebsd/man9/VFS_SYNC.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_SYNC(9)Kernel Developer's ManualVFS_SYNC(9)

-

-

-

-
VFS_SYNC — flush
-    unwritten data

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_SYNC(struct
-    mount *mp, int
-    waitfor);

-

-

-

-
The
-    ()
-    macro writes out all unwritten data in the file system mounted as
-    mp.

-
The arguments it expects are:

-

-  
mp

-  
The file system.

-  
waitfor

-  
Whether the function should wait for I/O to complete. Possible values are:
-    

-      

-      
synchronously wait for I/O to complete

-      

-      
start all I/O, but do not wait for it

-      

-      
push data not written by file system syncer

-    

-  

-

-
The
-    ()
-    macro calls the vfs_sync method of the file system,
-    which normally calls VOP_FSYNC(9) for all the vnodes in
-    the file system.

-

-

-

-
fsync(2), sync(2),
-    VFS(9), vnode(9),
-    VOP_FSYNC(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 23, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_UNMOUNT.9 4.html b/static/freebsd/man9/VFS_UNMOUNT.9 4.html
deleted file mode 100644
index da37399b..00000000
--- a/static/freebsd/man9/VFS_UNMOUNT.9 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_UNMOUNT(9)Kernel Developer's ManualVFS_UNMOUNT(9)

-

-

-

-
VFS_UNMOUNT —
-    unmount a file system

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_UNMOUNT(struct
-    mount *mp, int
-    mntflags);

-

-

-

-
The
-    ()
-    macro unmounts a file system.

-
The arguments it expects are:

-

-  
mp

-  
The file system.

-  
mntflags

-  
Bit-mask of flags for the unmount operation. The flags currently supported
-      by
-      ()
-      are:
-    

-      

-      
Open files are forcibly closed before the file system is
-        unmounted.

-    

-  

-

-

-

-

-
vflush(9), VFS(9),
-    vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 23, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/VFS_VGET.9 4.html b/static/freebsd/man9/VFS_VGET.9 4.html
deleted file mode 100644
index 6126a50a..00000000
--- a/static/freebsd/man9/VFS_VGET.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_VGET(9)Kernel Developer's ManualVFS_VGET(9)

-

-

-

-
VFS_VGET — convert
-    an inode number to a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_VGET(struct
-    mount *mp, ino_t
-    ino, int flags,
-    struct vnode **vpp);

-

-

-

-
The
-    ()
-    looks up or creates a vnode from a (mount, inode#) tuple.

-
Its arguments are:

-

-  
mp

-  
The mount point.

-  
ino

-  
The inode representing the file. This is a unique number assigned by the
-      file system when vnodes are first created.

-  
flags

-  
Additional locking flags to pass through to
-    vget(9).

-  
vpp

-  
Return parameter for the vnode.

-

-
This is an optional file system entry-point for file systems
-    mainly intended for NFS server use, but many file systems use it internally
-    in VOP_LOOKUP(9) and similar.

-
If the file system does not support this call, then it should
-    return EOPNOTSUPP.

-
Please see
-    ()
-    in sys/ufs/ffs/ffs_vfsops.c for the canonical
-    example.

-

-

-

-
VFS(9), vget(9),
-    vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 7, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/VNET.9 4.html b/static/freebsd/man9/VNET.9 4.html
deleted file mode 100644
index 2b131ae6..00000000
--- a/static/freebsd/man9/VNET.9 4.html	
+++ /dev/null
@@ -1,353 +0,0 @@
-
-  
-    
-    
-    
-  
-
VNET(9)Kernel Developer's ManualVNET(9)

-

-

-

-
VNET — network
-    subsystem virtualization infrastructure

-

-

-

-
options VIMAGE
-  

-  options VNET_DEBUG

-

-  

-  #include <net/vnet.h>

-

-

-
VNET_SETNAME
-    VNET_SYMPREFIX
-  

-  extern struct vnet *vnet0;

-

-

-
Variable Declaration

-
VNET(name);

-
VNET_NAME(name);

-
VNET_DECLARE(type,
-    name);

-
VNET_DEFINE(type,
-    name);

-
VNET_DEFINE_STATIC(type,
-    name);

-

-
#define	V_name	VNET(name)

-

-

-

-
Virtual Instance Selection

-
CRED_TO_VNET(struct ucred
-    *);

-
TD_TO_VNET(struct thread
-    *);

-
P_TO_VNET(struct proc
-    *);

-
IS_DEFAULT_VNET(struct
-    vnet *);

-
VNET_ASSERT(exp,
-    msg);

-
CURVNET_SET(struct vnet
-    *);

-
CURVNET_SET_QUIET(struct
-    vnet *);

-
CURVNET_RESTORE();

-
VNET_ITERATOR_DECL(struct
-    vnet *);

-
VNET_FOREACH(struct vnet
-    *);

-

-

-

-
VNET_LIST_RLOCK();

-
VNET_LIST_RUNLOCK();

-
VNET_LIST_RLOCK_NOSLEEP();

-
VNET_LIST_RUNLOCK_NOSLEEP();

-

-

-
Startup and Teardown Functions

-
struct vnet *
-  

-  vnet_alloc(void);

-
void
-  

-  vnet_destroy(struct vnet *);

-
VNET_SYSINIT(ident,
-    enum sysinit_sub_id subsystem, enum
-    sysinit_elem_order order, sysinit_cfunc_t func,
-    const void *arg);

-
VNET_SYSUNINIT(ident,
-    enum sysinit_sub_id subsystem, enum
-    sysinit_elem_order order, sysinit_cfunc_t func,
-    const void *arg);

-

-

-

-
VNET_GLOBAL_EVENTHANDLER_REGISTER(const
-    char *name, void *func, void
-    *arg, int priority);

-
VNET_GLOBAL_EVENTHANDLER_REGISTER_TAG(eventhandler_tag
-    tag, const char *name, void
-    *func, void *arg, int
-    priority);

-

-

-

-

-
VNET is the name of a technique to
-    virtualize the network stack. The basic idea is to change global resources
-    most notably variables into per network stack resources and have functions,
-    sysctls, eventhandlers, etc. access and handle them in the context of the
-    correct instance. Each (virtual) network stack is attached to a
-    prison, with vnet0 being the
-    unrestricted default network stack of the base system.

-
The global defines for VNET_SETNAME and
-    VNET_SYMPREFIX are shared with
-    kvm(3) to access internals for debugging reasons.

-

-
Variable Declaration

-
Variables are virtualized by using the
-    ()
-    macro rather than writing them out as
-    .
-    One can still use static initialization, e.g.,

-

-
VNET_DEFINE(int,
-  foo) = 1;

-
Variables declared with the static keyword
-    can use the
-    ()
-    macro, e.g.,

-

-
VNET_DEFINE_STATIC(SLIST_HEAD(,
-  bar), bars);

-
Static initialization is not possible when the
-    virtualized variable would need to be referenced, e.g., with
-    “TAILQ_HEAD_INITIALIZER()”. In that case a
-    ()
-    based initialization function must be used.

-
External variables have to be declared using the
-    ()
-    macro. In either case the convention is to define another macro, that is
-    then used throughout the implementation to access that variable. The
-    variable name is usually prefixed by
-     to express
-    that it is virtualized. The
-    ()
-    macro will then translate accesses to that variable to the copy of the
-    currently selected instance (see the
-    Virtual instance
-    selection section):

-

-
#define	V_name	VNET(name)

-
NOTE: Do not confuse this with the convention
-    used by VFS(9).

-
The
-    ()
-    macro returns the offset within the memory region of the virtual network
-    stack instance.

-

-

-
Virtual Instance Selection

-
There are three different places where the current virtual network
-    stack pointer is stored and can be taken from:

-
    
-  
  1. a prison:
-    
    (struct prison
-      *)->pr_vnet
    
-    
    For convenience the following macros are provided:
    
-    
    
-    
    (struct ucred *)
-(struct thread *)
-(struct proc *)
    
-    
    
-  
    2. 
-  
  2. a
-      :
-    
    (struct socket
-      *)->so_vnet
    
-  
    3. 
-  
  3. an
-      :
-    
    (struct ifnet
-      *)->if_vnet
    
-  
    4. 
-

-
In addition the currently active instance is cached in
-    “curthread->td_vnet” which is usually only accessed through
-    the curvnet macro.

-
To set the correct context of the current virtual
-    network instance, use the
-    ()
-    or
-    ()
-    macros. The CURVNET_SET_QUIET() version will not
-    record vnet recursions in case the kernel was compiled with
-    options VNET_DEBUG and should thus only be used in
-    well known cases, where recursion is unavoidable. Both macros will save the
-    previous state on the stack and it must be restored with the
-    CURVNET_RESTORE() macro.

-
NOTE: As the previous state
-    is saved on the stack, you cannot have multiple
-    ()
-    calls in the same block.

-
NOTE: As the previous state
-    is saved on the stack, a
-    ()
-    call has to be in the same block as the
-    CURVNET_SET() call or in a subblock with the same
-    idea of the saved instances as the outer block.

-
NOTE: As each macro is a set of
-    operations and, as previously explained, cannot be put into its own block
-    when defined, one cannot conditionally set the current vnet context. The
-    following will 
-    work:

-

-
if (condition)
-	CURVNET_SET(vnet);

-

-
nor would this work:

-

-
if (condition) {
-	CURVNET_SET(vnet);
-}
-CURVNET_RESTORE();

-

-
Sometimes one needs to loop over all
-    virtual instances, for example to update virtual from global state, to run a
-    function from a callout(9) for each instance, etc. For
-    those cases the
-    ()
-    and
-    ()
-    macros are provided. The former macro defines the variable that iterates
-    over the loop, and the latter loops over all of the virtual network stack
-    instances. See Locking for how to savely
-    traverse the list of all virtual instances.

-
The
-    ()
-    macro provides a safe way to check whether the currently active instance is
-    the unrestricted default network stack of the base system
-    (vnet0).

-
The
-    ()
-    macro provides a way to conditionally add assertions that are only active
-    with options VIMAGE compiled in and either
-    options VNET_DEBUG or options
-    INVARIANTS enabled as well. It uses the same semantics as
-    KASSERT(9).

-

-

-

-
For public access to the list of virtual network stack instances
-    e.g., by the
-    ()
-    macro, read locks are provided. Macros are used to abstract from the actual
-    type of the locks. If a caller may sleep while traversing the list, it must
-    use the
-    ()
-    and
-    ()
-    macros. Otherwise, the caller can use
-    ()
-    and
-    ().

-

-

-
Startup and Teardown Functions

-
To start or tear down a virtual network stack instance the
-    internal functions
-    ()
-    and
-    ()
-    are provided and called from the jail framework. They run the publicly
-    provided methods to handle network stack startup and teardown.

-
For public control, the system startup
-    interface has been enhanced to not only handle a system boot but to also
-    handle a virtual network stack startup and teardown. To the base system the
-    ()
-    and
-    ()
-    macros look exactly as if there were no virtual network stack. In fact, if
-    options VIMAGE is not compiled in they are compiled
-    to the standard
-    ()
-    macros. In addition to that they are run for each virtual network stack when
-    starting or, in reverse order, when shutting down.

-

-

-

-
Eventhandlers can be handled in two ways:

-

-
    
-  
  1. save the
-       returned in
-      each virtual instance and properly free the eventhandlers on teardown
-      using those, or
    2. 
-  
  2. use one eventhandler that will iterate over all virtual network stack
-      instances.
    3. 
-

-
For the first case one can
-    just use the normal EVENTHANDLER(9) functions, while for
-    the second case the
-    ()
-    and
-    ()
-    macros are provided. These differ in that
-    VNET_GLOBAL_EVENTHANDLER_REGISTER_TAG() takes an
-    extra first argument that will carry the tag upon
-    return. Eventhandlers registered with either of these will not run
-    func directly but func will be
-    called from an internal iterator function for each vnet. Both macros can
-    only be used for eventhandlers that do not take additional arguments, as the
-    variadic arguments from an EVENTHANDLER_INVOKE(9) call
-    will be ignored.

-

-

-

-
A sysctl(9) can be virtualized by adding the
-    CTLFLAG_VNET control flag to the ctlflags bitmask of
-    the macros.

-

-

-

-

-
jail(2), kvm(3),
-    EVENTHANDLER(9), KASSERT(9),
-    sysctl(9)

-
Marko Zec, Implementing a Clonable Network Stack in the FreeBSD
-    Kernel, USENIX ATC'03, June 2003, Boston

-

-

-

-
The virtual network stack implementation first appeared in
-    FreeBSD 8.0.

-

-

-

-
The VNET framework was designed and
-    implemented at the University of Zagreb by Marko Zec
-    under sponsorship of the FreeBSD Foundation and NLnet Foundation, and later
-    extended and refined by Bjoern A. Zeeb (also under
-    FreeBSD Foundation sponsorship), and Robert
-  Watson.

-
This manual page was written by Bjoern A. Zeeb,
-    CK Software GmbH, under sponsorship from the FreeBSD Foundation.

-

-

-
-  
-    
-    
-  
-
September 19, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_ACCESS.9 4.html b/static/freebsd/man9/VOP_ACCESS.9 4.html
deleted file mode 100644
index 482b0ce6..00000000
--- a/static/freebsd/man9/VOP_ACCESS.9 4.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_ACCESS(9)Kernel Developer's ManualVOP_ACCESS(9)

-

-

-

-
VOP_ACCESS,
-    VOP_ACCESSX — check access
-    permissions of a file or Unix domain socket

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_ACCESS(struct
-    vnode *vp, accmode_t
-    accmode, struct ucred
-    *cred, struct thread
-    *td);

-
int
-  

-  VOP_ACCESSX(struct
-    vnode *vp, accmode_t
-    accmode, struct ucred
-    *cred, struct thread
-    *td);

-

-

-

-
This entry point checks the access permissions of the file against
-    the given credentials.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file to check.

-  
accmode

-  
The type of access required.

-  
cred

-  
The user credentials to check.

-  
td

-  
The thread which is checking.

-

-
The accmode is a mask which
-    can contain flags described in <sys/vnode.h>, e.g.
-    VREAD, VWRITE or
-    VEXEC. For
-    (),
-    the only flags that may be set in accmode are
-    VEXEC, VWRITE,
-    VREAD, VADMIN and
-    VAPPEND. To check for other flags, one has to use
-    ()
-    instead.

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
If the file is accessible in the specified way, then zero is
-    returned, otherwise an appropriate error code is returned.

-

-

-

-

-  
[]

-  
An attempt was made to change an immutable file.

-  
[]

-  
The permission bits the file mode or the ACL do not permit the requested
-      access.

-

-

-

-

-
vaccess(9),
-    vaccess_acl_nfs4(9),
-    vaccess_acl_posix1e(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
September 18, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_ACLCHECK.9 4.html b/static/freebsd/man9/VOP_ACLCHECK.9 4.html
deleted file mode 100644
index e13f70f6..00000000
--- a/static/freebsd/man9/VOP_ACLCHECK.9 4.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_ACLCHECK(9)Kernel Developer's ManualVOP_ACLCHECK(9)

-

-

-

-
VOP_ACLCHECK —
-    check an access control list for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/acl.h>

-
int
-  

-  VOP_ACLCHECK(struct
-    vnode *vp, acl_type_t
-    type, struct acl
-    *aclp, struct ucred
-    *cred, struct thread
-    *td);

-

-

-

-
This vnode call may be used to determine the validity of a
-    particular access control list (ACL) for a particular file or directory.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file or directory.

-  
type

-  
The type of ACL to check.

-  
aclp

-  
A pointer to an ACL structure from which to retrieve the ACL data.

-  
cred

-  
The user credentials to use in authorizing the request.

-  
td

-  
The thread checking the ACL.

-

-
The cred pointer may be NULL to indicate
-    that access control checks are not to be performed, if possible. This cred
-    setting might be used to allow the kernel to authorize ACL verification that
-    the active process might not be permitted to do.

-
The vnode ACL interface defines the syntax, and not semantics, of
-    file and directory ACL interfaces. More information about ACL management in
-    kernel may be found in acl(9).

-

-

-

-
No locks are required to call this vnode method, and any locks
-    held on entry will be held on exit.

-

-

-

-
If the aclp pointer points to a valid ACL of
-    type type for the object vp,
-    then zero is returned. Otherwise, an appropriate error code is returned.

-

-

-

-

-  
[]

-  
The ACL type passed is invalid for this vnode, or the ACL data is
-    invalid.

-  
[]

-  
The file or directory ACL does not permit access.

-  
[]

-  
Sufficient memory is not available to fulfill the request.

-  
[]

-  
The file system does not support
-    VOP_ACLCHECK().

-

-

-

-

-
acl(9), vnode(9),
-    VOP_GETACL(9), VOP_SETACL(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
December 23, 1999FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_ADVISE.9 4.html b/static/freebsd/man9/VOP_ADVISE.9 4.html
deleted file mode 100644
index bed12675..00000000
--- a/static/freebsd/man9/VOP_ADVISE.9 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_ADVISE(9)Kernel Developer's ManualVOP_ADVISE(9)

-

-

-

-
VOP_ADVISE — apply
-    advice about use of file data

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_ADVISE(struct
-    vnode *vp, off_t
-    start, off_t end,
-    int advice);

-

-

-

-
This call applies advice for a range of a file's data. It is used
-    to implement the posix_fadvise(2) system call.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file.

-  
start

-  
The start of the range of file data.

-  
end

-  
The end of the range of file data. A value of
-      OFF_MAX indicates that the advice is to be applied
-      up to the end of the file.

-  
advice

-  
The type of operation to apply to the file data. Possible values are:
-    

-      

-      
Initiate an asynchronous read of the file data if it is not already
-          resident.

-      

-      
Decrease the in-memory priority of clean file data or discard clean
-          file data.

-    

-  

-

-
If the start and end
-    offsets are both zero, then the operation should be applied to the entire
-    file. Note that this call is advisory only and may perform the requested
-    operation on a subset of the requested range (including not performing it at
-    all) and still return success.

-

-

-

-
The file should be unlocked on entry.

-

-

-

-
Zero is returned if the call is successful, otherwise an
-    appropriate error code is returned.

-

-

-

-

-  
[]

-  
An invalid value was given for advice.

-

-

-

-

-
vnode(9)

-

-

-
-  
-    
-    
-  
-
September 26, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_ADVLOCK.9 4.html b/static/freebsd/man9/VOP_ADVLOCK.9 4.html
deleted file mode 100644
index 92329ee3..00000000
--- a/static/freebsd/man9/VOP_ADVLOCK.9 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_ADVLOCK(9)Kernel Developer's ManualVOP_ADVLOCK(9)

-

-

-

-
VOP_ADVLOCK —
-    advisory record locking

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/fcntl.h>
-  

-  #include <sys/lockf.h>

-
int
-  

-  VOP_ADVLOCK(struct
-    vnode *vp, caddr_t
-    id, int op,
-    struct flock *fl,
-    int flags);

-

-

-

-
The arguments are:

-

-  
vp

-  
The vnode being manipulated.

-  
id

-  
The id token which is changing the lock.

-  
op

-  
The operation to perform (see fcntl(2)).

-  
fl

-  
Description of the lock.

-  
flags

-  
One or more of the following:
-    

-    

-    

-      

-      
Wait until lock is granted.

-      

-      
Use flock(2) semantics for lock.

-      

-      
Use POSIX semantics for lock.

-      

-      
Lock owner is remote NFS client.

-      

-      
Mask signals while waiting for the lock.

-    

-    

-  

-

-
This entry point manipulates advisory record locks
-    on the file. Most file systems delegate the work for this call to
-    ().

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
fcntl(2), flock(2),
-    vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 10, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_ALLOCATE.9 4.html b/static/freebsd/man9/VOP_ALLOCATE.9 4.html
deleted file mode 100644
index ce6e0bd8..00000000
--- a/static/freebsd/man9/VOP_ALLOCATE.9 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_ALLOCATE(9)Kernel Developer's ManualVOP_ALLOCATE(9)

-

-

-

-
VOP_ALLOCATE —
-    allocate storage for a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_ALLOCATE(struct vnode *vp,
-    off_t *offset, off_t *len,
-    int ioflag, struct ucred
-  *cred);

-

-

-

-
This call allocates storage for a range of offsets in a file. It
-    is used to implement the posix_fallocate(2) system
-  call.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file.

-  
offset

-  
The start of the range to allocate storage for in the file.

-  
len

-  
The length of the range to allocate storage for in the file.

-  
ioflag

-  
Directives and hints to be given to the file system.

-  
cred

-  
The credentials of the caller.

-

-
The offset and len
-    arguments are updated to reflect the portion of the range that still needs
-    to be allocated on return. A partial allocation is considered a successful
-    operation. The file's contents are not changed.

-

-

-

-
The file should be exclusively locked on entry and will still be
-    locked on exit.

-

-

-

-
Zero is returned if the call is successful, otherwise an
-    appropriate error code is returned.

-

-

-

-

-  
[]

-  
An attempt was made to write a file that exceeds the process's file size
-      limit or the maximum file size.

-  
[]

-  
The file system is full.

-  
[]

-  
An append-only flag is set on the file, but the caller is attempting to
-      write before the current end of file.

-

-

-

-

-
vnode(9), VOP_READ(9),
-    VOP_WRITE(9)

-

-

-
-  
-    
-    
-  
-
November 8, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_ATTRIB.9 4.html b/static/freebsd/man9/VOP_ATTRIB.9 4.html
deleted file mode 100644
index 9c813f1c..00000000
--- a/static/freebsd/man9/VOP_ATTRIB.9 4.html	
+++ /dev/null
@@ -1,139 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_ATTRIB(9)Kernel Developer's ManualVOP_ATTRIB(9)

-

-

-

-
VOP_GETATTR,
-    VOP_SETATTR — get and set
-    attributes on a file or directory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_GETATTR(struct,
-    vnode, *vp,
-    flags, struct,
-    vattr, *vap,
-    struct, ucred,
-    *cred);

-
int
-  

-  VOP_SETATTR(struct,
-    vnode, *vp,
-    struct, vattr,
-    *vap, struct,
-    ucred, *cred);

-
int
-  

-  VOP_STAT(struct,
-    vnode, *vp,
-    struct, stat,
-    *sb, flags,
-    struct, ucred,
-    *active_cred, struct,
-    ucred, *file_cred);

-

-

-

-
These entry points manipulate various attributes of a file or
-    directory, including file permissions, owner, group, size, access time and
-    modification time.

-
()
-    returns data in a format suitable for the stat(2) system
-    call and by default is implemented as a wrapper around
-    VOP_GETATTR(). Filesystems may want to implement
-    their own variant for performance reasons.

-
For
-    ()
-    and VOP_SETATTR() the arguments are:

-

-  
vp

-  
The vnode of the file.

-  
vap

-  
The attributes of the file.

-  
cred

-  
The user credentials of the calling thread.

-

-
For
-    ()
-    the arguments are:

-

-  
vp

-  
The vnode of the file.

-  
sb

-  
The attributes of the file.

-  
active_cred

-  
The user credentials of the calling thread.

-  
file_cred

-  
The credentials installed on the file description pointing to the vnode or
-      NOCRED.

-

-
Attributes which are not being modified by
-    ()
-    should be set to the value VNOVAL;
-    ()
-    may be used to clear all the values, and should generally be used to reset
-    the contents of *vap prior to setting specific
-  values.

-

-

-

-
Both VOP_GETATTR() and
-    VOP_STAT() expect the vnode to be locked on entry
-    and will leave the vnode locked on return. The lock type can be either
-    shared or exclusive.

-
()
-    expects the vnode to be locked on entry and will leave the vnode locked on
-    return. The lock type must be exclusive.

-

-

-

-
VOP_GETATTR() returns 0 if it was able to
-    retrieve the attribute data via *vap, otherwise an
-    appropriate error is returned. VOP_SETATTR() returns
-    zero if the attributes were changed successfully, otherwise an appropriate
-    error is returned. VOP_STAT() returns 0 if it was
-    able to retrieve the attribute data *sb, otherwise an
-    appropriate error is returned.

-

-

-

-

-  
[]

-  
The file is immutable.

-  
[]

-  
The caller does not have permission to modify the file or directory
-      attributes.

-  
[]

-  
The file system is read-only.

-

-

-

-

-
VFS(9), vnode(9),
-    VOP_ACCESS(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
October 2, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_BMAP.9 4.html b/static/freebsd/man9/VOP_BMAP.9 4.html
deleted file mode 100644
index f1d7f50e..00000000
--- a/static/freebsd/man9/VOP_BMAP.9 4.html	
+++ /dev/null
@@ -1,90 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_BMAP(9)Kernel Developer's ManualVOP_BMAP(9)

-

-

-

-
VOP_BMAP — Logical
-    to physical block number conversion

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_BMAP(struct
-    vnode *vp, daddr_t
-    bn, struct bufobj
-    **bop, daddr_t
-    *bnp, int *runp,
-    int *runb);

-

-

-

-
This vnode call is used to lookup the physical block number of the
-    file system's underlying device where a given logical block of a file is
-    stored. Its arguments are:

-

-  
vp

-  
The vnode of the file.

-  
bn

-  
Logical block number within the file identified by
-      vp.

-  
bop

-  
Return storage for the buffer object associated with the file system's
-      underlying device.

-  
bnp

-  
Return storage for the physical block number.

-  
runp

-  
Return storage for the number of succeeding logical blocks that may be
-      efficiently read at the same time as the requested block. This will
-      usually be the number of logical blocks whose physical blocks are
-      contiguously allocated. However a file system is free to define
-      "efficient" as it sees fit.

-  
runb

-  
Like runp but for preceding rather than succeeding
-      blocks.

-

-
Any of the return arguments may be NULL to
-    indicate that the caller does not care about that information.

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-
vnode(9)

-

-

-

-
A bmap() function first appeared in
-    4.2BSD.

-

-

-

-
This manual page was written by Alan
-    Somers.

-

-

-
-  
-    
-    
-  
-
June 19, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_BWRITE.9 4.html b/static/freebsd/man9/VOP_BWRITE.9 4.html
deleted file mode 100644
index da1fb6dd..00000000
--- a/static/freebsd/man9/VOP_BWRITE.9 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_BWRITE(9)Kernel Developer's ManualVOP_BWRITE(9)

-

-

-

-
VOP_BWRITE — write
-    a file system buffer

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_BWRITE(struct
-    vnode *vp, struct buf
-    *bp);

-

-

-

-
The arguments are:

-

-  
vp

-  
The vnode of the file being written to.

-  
bp

-  
The buffer to be written.

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_COPY_FILE_RANGE.9 3.html b/static/freebsd/man9/VOP_COPY_FILE_RANGE.9 3.html
deleted file mode 100644
index 8daf6239..00000000
--- a/static/freebsd/man9/VOP_COPY_FILE_RANGE.9 3.html	
+++ /dev/null
@@ -1,115 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_COPY_FILE_RANGE(9)Kernel Developer's ManualVOP_COPY_FILE_RANGE(9)

-

-

-

-
VOP_COPY_FILE_RANGE —
-    copy a byte range within a file or from one file to another
-    in a single file system or between multiple file systems

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_COPY_FILE_RANGE(struct vnode
-    *invp, off_t *inoff, struct
-    vnode *outvp, off_t *outoff,
-    size_t *len, unsigned int flags,
-    struct ucred *incred, struct ucred
-    *outcred, struct thread *fsize_td);

-

-

-

-
This entry point copies a byte range from one regular file to
-    another or within one file in a single file system.
-    invp and outvp can refer to the
-    same file. For this case, the byte ranges defined by
-    *inoff, *outoff and
-    *len will not overlap.

-
The arguments are:

-

-  
invp

-  
The vnode of the input file.

-  
inoff

-  
A pointer to the file offset for the input file.

-  
outvp

-  
The vnode of the output file.

-  
outoff

-  
A pointer to the file offset for the output file.

-  
len

-  
A pointer to the byte count for the copy.

-  
flags

-  
Flags, should be set to 0 for now.

-  
incred

-  
The credentials used to read invp.

-  
outcred

-  
The credentials used to write outvp.

-  
fsize_td

-  
The thread pointer to be passed to vn_rlimit_fsize(). This will be
-      NULL for a server thread without limits, such as
-      for the NFS server or curthread otherwise.

-

-
On entry and on return, the inoff and
-    outoff arguments point to the locations of the file
-    offsets. These file offsets should be updated by the number of bytes copied.
-    The len argument points to the location that stores
-    the number of bytes to be copied. Upon a successful return
-    len will be updated to the number of bytes actually
-    copied. Normally, this will be the number of bytes requested to be copied,
-    however a copy of fewer bytes than requested is permitted. This does not
-    necessarily indicate that the copy reached EOF on the input file. However,
-    if the value pointed to by the len argument is zero
-    upon a successful return, it indicates that the offset pointed to by
-    inoff is at or beyond EOF on the input file.

-

-

-

-
The vnode are unlocked on entry and must be unlocked on return.
-    The byte ranges for both invp and
-    outvp should be range locked when this call is
-  done.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-

-  
[]

-  
If the copy exceeds the process's file size limit or the maximum file size
-      for the file system invp and
-      outvp reside on.

-  
[]

-  
A signal interrupted the VOP call before it could be completed.

-  
[]

-  
An I/O error occurred while reading/writing the files.

-  
[]

-  
Corrupted data was detected while reading/writing the files.

-  
[]

-  
The file system is full.

-

-

-

-

-
vn_rdwr(9), vnode(9)

-

-

-
-  
-    
-    
-  
-
March 30, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_CREATE.9 4.html b/static/freebsd/man9/VOP_CREATE.9 4.html
deleted file mode 100644
index c1f24343..00000000
--- a/static/freebsd/man9/VOP_CREATE.9 4.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_CREATE(9)Kernel Developer's ManualVOP_CREATE(9)

-

-

-

-
VOP_CREATE,
-    VOP_MKNOD, VOP_MKDIR,
-    VOP_SYMLINK — create a file,
-    socket, fifo, device, directory or symlink

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/namei.h>

-
int
-  

-  VOP_CREATE(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap);

-
int
-  

-  VOP_MKNOD(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap);

-
int
-  

-  VOP_MKDIR(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap);

-
int
-  

-  VOP_SYMLINK(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap,
-    const char *target);

-

-

-

-
These entry points create a new file, socket, fifo, device,
-    directory or symlink in a given directory.

-
The arguments are:

-

-  
dvp

-  
The locked vnode of the directory.

-  
vpp

-  
The address of a variable where the resulting locked vnode should be
-      stored.

-  
cnp

-  
The pathname component created.

-  
vap

-  
The attributes that the new object should be created with.

-  
target

-  
The pathname of the target of the symlink.

-

-
These entry points are called after
-    VOP_LOOKUP(9) when an object is being created.

-

-

-

-
The directory, dvp will be locked on entry
-    and must remain locked on return. If the call is successful, the new object
-    will be returned locked.

-

-

-

-
If successful, the vnode for the new object is placed in
-    *vpp and zero is returned. Otherwise, an appropriate
-    error is returned.

-

-

-

-

-  
[]

-  
The file system is full.

-  
[]

-  
The user's file system space or inode quota would be exceeded.

-

-

-

-

-
vnode(9), VOP_LOOKUP(9)

-

-

-

-
The function VOP_CREATE appeared in
-    4.3BSD.

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
November 2, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_DEALLOCATE.9 4.html b/static/freebsd/man9/VOP_DEALLOCATE.9 4.html
deleted file mode 100644
index e4a4b73a..00000000
--- a/static/freebsd/man9/VOP_DEALLOCATE.9 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_DEALLOCATE(9)Kernel Developer's ManualVOP_DEALLOCATE(9)

-

-

-

-
VOP_DEALLOCATE —
-    zero and/or deallocate storage from a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_DEALLOCATE(struct vnode *vp,
-    off_t *offset, off_t *len,
-    int flags, int ioflag,
-    struct ucred *cred);

-

-

-

-
This VOP call zeroes/deallocates storage for an offset range in a
-    file. It is used to implement the fspacectl(2) system
-    call.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file.

-  
offset

-  
The start of the range to deallocate storage in the file.

-  
len

-  
The length of the range to deallocate storage in the file.

-  
flags

-  
The flags of this call. This should be set to 0 for now.

-  
ioflag

-  
Directives and hints to be given to the file system.

-  
cred

-  
The credentials of the caller.

-

-
*offset and *len are
-    updated to reflect the portion of the range that still needs to be
-    zeroed/deallocated on return. Partial result is considered a successful
-    operation. For a non-partial successful completion,
-    *len is updated to be the value 0, and
-    *offset is incremented by the number of bytes zeroed
-    before the end-of-file.

-

-

-

-
The vnode should be locked on entry and will still be locked on
-    exit.

-

-

-

-
Zero is returned if the call is successful, otherwise an
-    appropriate error code is returned.

-

-

-

-

-  
[]

-  
Invalid offset, len or
-      flags parameters are passed into this VOP call.

-  
[]

-  
The vnode type is not supported by this VOP call.

-  
[]

-  
The file system is full.

-  
[]

-  
An append-only flag is set on the file, but the caller is attempting to
-      zero before the current end of file.

-

-

-

-

-
vnode(9)

-

-

-

-
VOP_DEALLOCATE and this manual page was
-    written by Ka Ho Ng
-    <khng@FreeBSD.org>
-    under sponsorship from the FreeBSD Foundation.

-

-

-
-  
-    
-    
-  
-
August 25, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_FSYNC.9 4.html b/static/freebsd/man9/VOP_FSYNC.9 4.html
deleted file mode 100644
index ae6e846b..00000000
--- a/static/freebsd/man9/VOP_FSYNC.9 4.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_FSYNC(9)Kernel Developer's ManualVOP_FSYNC(9)

-

-

-

-
VOP_FDATASYNC,
-    VOP_FSYNC — flush file
-    system buffers for a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_FDATASYNC(struct
-    vnode *vp, struct thread
-    *td);

-
int
-  

-  VOP_FSYNC(struct
-    vnode *vp, int
-    waitfor, struct thread
-    *td);

-

-

-

-
()
-    ensures that a file can be recovered to its current state following a crash.
-    That typically requires flushing the file's dirty buffers, its inode, and
-    possibly other filesystem metadata to persistent media.
-    VOP_FSYNC() is used to implement the
-    sync(2) and fsync(2) system calls.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file.

-  
waitfor

-  
Whether the function should wait for I/O to complete. Possible values are:
-    

-      

-      
Synchronously wait for I/O to complete.

-      

-      
Start all I/O, but do not wait for it.

-      

-      
Push data not written by file system syncer.

-    

-  

-  
td

-  
The calling thread.

-

-
()
-    is similar, but it does not require that all of the file's metadata be
-    flushed. It only requires that the file's data be recoverable after a crash.
-    That implies that the data itself must be flushed to disk, as well as some
-    metadata such as the file's size but not necessarily its attributes.
-    VOP_FDATASYNC() should always wait for I/O to
-    complete, as if called with MNT_WAIT.
-    VOP_FDATASYNC() is used to implement
-    fdatasync(2).

-

-

-

-
The vnode should be exclusively locked on entry, and stays locked
-    on return.

-

-

-

-
Zero is returned if the call is successful, otherwise an
-    appropriate error code is returned.

-

-

-

-

-  
[]

-  
The file system is full.

-  
[]

-  
Quota exceeded.

-

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
March 22, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_GETACL.9 4.html b/static/freebsd/man9/VOP_GETACL.9 4.html
deleted file mode 100644
index 0174986a..00000000
--- a/static/freebsd/man9/VOP_GETACL.9 4.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_GETACL(9)Kernel Developer's ManualVOP_GETACL(9)

-

-

-

-
VOP_GETACL —
-    retrieve access control list for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/acl.h>

-
int
-  

-  VOP_GETACL(struct
-    vnode *vp, acl_type_t
-    type, struct acl
-    *aclp, struct ucred
-    *cred, struct thread
-    *td);

-

-

-

-
This vnode call may be used to retrieve the access control list
-    (ACL) from a file or directory.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file or directory.

-  
type

-  
The type of ACL to retrieve.

-  
aclp

-  
A pointer to an ACL structure to receive the ACL data.

-  
cred

-  
The user credentials to use in authorizing the request.

-  
td

-  
The thread requesting the ACL.

-

-
The cred pointer may be
-    NULL to indicate that access control checks are not
-    to be performed, if possible. This cred setting might be used to allow the
-    kernel to authorize ACL retrieval that the active process might not be
-    permitted to do.

-
The vnode ACL interface defines the syntax, and not semantics, of
-    file and directory ACL interfaces. More information about ACL management in
-    kernel may be found in acl(9).

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
If the aclp pointer will point to a valid
-    ACL, then zero is returned. Otherwise, an appropriate error code is
-    returned.

-

-

-

-

-  
[]

-  
The ACL type passed is invalid for this vnode.

-  
[]

-  
The caller does not have the appropriate privilege.

-  
[]

-  
Sufficient memory is not available to fulfill the request.

-  
[]

-  
The file system does not support
-    VOP_GETACL().

-

-

-

-

-
acl(9), vnode(9),
-    VOP_ACLCHECK(9), VOP_SETACL(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
December 23, 1999FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_GETEXTATTR.9 4.html b/static/freebsd/man9/VOP_GETEXTATTR.9 4.html
deleted file mode 100644
index 0598c752..00000000
--- a/static/freebsd/man9/VOP_GETEXTATTR.9 4.html	
+++ /dev/null
@@ -1,119 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_GETEXTATTR(9)Kernel Developer's ManualVOP_GETEXTATTR(9)

-

-

-

-
VOP_GETEXTATTR —
-    retrieve named extended attribute from a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/extattr.h>

-
int
-  

-  VOP_GETEXTATTR(struct vnode *vp,
-    int attrnamespace, const char
-    *name, struct uio *uio, size_t
-    *size, struct ucred *cred,
-    struct thread *td);

-

-

-

-
This vnode call may be used to retrieve a specific named extended
-    attribute from a file or directory.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file or directory.

-  
attrnamespace

-  
Integer constant indicating which extended attribute namespace the
-      attribute name is present in.

-  
name

-  
Pointer to a null-terminated character string containing the attribute
-      name.

-  
uio

-  
The location of the data to be read.

-  
size

-  
If not NULL, on return it will contain the number
-      of bytes required to read all of the attribute data. In most cases
-      uio will be NULL when
-      size is not, and vice versa.

-  
cred

-  
The user credentials to use in authorizing the request.

-  
td

-  
The thread requesting the extended attribute.

-

-
The cred pointer may be
-    NULL to indicate that access control checks are not
-    to be performed, if possible. This cred setting might
-    be used to allow the kernel to authorize extended attribute retrieval that
-    the active process might not be permitted to do.

-
Extended attribute semantics may vary by file system implementing
-    the call. More information on extended attributes may be found in
-    extattr(9).

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
On success, zero will be returned, and the uio structure will be
-    updated to reflect data read. Otherwise, an appropriate error code is
-    returned.

-

-

-

-

-  
[]

-  
The requested attribute was not defined for this vnode.

-  
[]

-  
The caller does not have the appropriate privilege.

-  
[]

-  
The request was not valid in this file system for the specified vnode and
-      attribute name.

-  
[]

-  
Sufficient memory is not available to fulfill the request.

-  
[]

-  
The uio structure refers to an invalid userspace address.

-  
[]

-  
The name, namespace, or
-      uio argument is invalid.

-  
[]

-  
The file system does not support
-    VOP_GETEXTATTR().

-

-

-

-

-
extattr(9), vnode(9),
-    VOP_LISTEXTATTR(9),
-  VOP_SETEXTATTR(9)

-

-

-

-
By passing in the empty string as the attribute name, some file
-    systems will return a list of defined names on the target vnode for the
-    requested namespace. This is a bad API, and will be replaced by an explicit
-    VOP.

-

-

-
-  
-    
-    
-  
-
December 23, 1999FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_GETPAGES.9 3.html b/static/freebsd/man9/VOP_GETPAGES.9 3.html
deleted file mode 100644
index 80204db4..00000000
--- a/static/freebsd/man9/VOP_GETPAGES.9 3.html	
+++ /dev/null
@@ -1,160 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_GETPAGES(9)Kernel Developer's ManualVOP_GETPAGES(9)

-

-

-

-
VOP_GETPAGES,
-    VOP_PUTPAGES — read or write
-    VM pages from a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <vm/vm.h>

-
int
-  

-  VOP_GETPAGES(struct vnode *vp,
-    vm_page_t *ma, int count,
-    int *rbehind, int *rahead);

-
int
-  

-  VOP_PUTPAGES(struct vnode *vp,
-    vm_page_t *ma, int bytecount,
-    int flags, int *rtvals);

-

-

-

-
The
-    ()
-    method is called to read in pages of virtual memory which are backed by
-    ordinary files. If other adjacent pages are backed by adjacent regions of
-    the same file, VOP_GETPAGES() is requested to read
-    those pages as well, although it is not required to do so. The
-    VOP_PUTPAGES() method does the converse; that is to
-    say, it writes out adjacent dirty pages of virtual memory.

-
On entry, the vnode lock is held but neither the page queue nor VM
-    object locks are held. Both methods return in the same state on both success
-    and error returns.

-
The arguments are:

-

-  
vp

-  
The file to access.

-  
ma

-  
Pointer to the first element of an array of pages representing a
-      contiguous region of the file to be read or written.

-  
count

-  
The length of the ma array.

-  
bytecount

-  
The number of bytes that should be written from the pages of the
-    array.

-  
flags

-  
A bitfield of flags affecting the function operation. If
-      VM_PAGER_PUT_SYNC is set, the write should be
-      synchronous; control must not be returned to the caller until after the
-      write is finished. If VM_PAGER_PUT_INVAL is set,
-      the pages are to be invalidated after being written. If
-      VM_PAGER_PUT_NOREUSE is set, the I/O performed
-      should set the IO_NOREUSE flag, to indicate to the filesystem that pages
-      should be marked for fast reuse if needed. This could occur via a call to
-      vm_page_deactivate_noreuse(9), which puts such pages
-      onto the head of the inactive queue. If
-      VM_PAGER_CLUSTER_OK is set, writes may be delayed,
-      so that related writes can be coalesced for efficiency, e.g., using the
-      clustering mechanism of the buffer cache.

-  
rtvals

-  
An array of VM system result codes indicating the status of each page
-      written by
-      ().

-  
rbehind

-  
Optional pointer to integer specifying number of pages to be read behind,
-      if possible. If the filesystem supports that feature, number of actually
-      read pages is reported back, otherwise zero is returned.

-  
rahead

-  
Optional pointer to integer specifying number of pages to be read ahead,
-      if possible. If the filesystem supports that feature, number of actually
-      read pages is reported back, otherwise zero is returned.

-

-
The status of the
-    ()
-    method is returned on a page-by-page basis in the array
-    rtvals[]. The possible status values are as
-  follows:

-

-  

-  
The page was successfully written. The implementation must call
-      vm_page_undirty(9) to mark the page as clean.

-  

-  
The page was scheduled to be written asynchronously. When the write
-      completes, the completion callback should call
-      vm_object_pip_wakeup(9) and
-      vm_page_sunbusy(9) to clear the busy flag and awaken any
-      other threads waiting for this page, in addition to calling
-      vm_page_undirty(9).

-  

-  
The page was entirely beyond the end of the backing file. This condition
-      should not be possible if the vnode's file system is correctly
-      implemented.

-  

-  
The page could not be written because of an error on the underlying
-      storage medium or protocol.

-  

-  
Treated identically to VM_PAGER_ERROR.

-  

-  
The page was not handled by this request.

-

-
The
-    ()
-    method must populate and validate all requested pages in order to return
-    success. It is expected to release any pages in ma
-    that it does not successfully handle, by calling
-    vm_page_free(9). When it succeeds,
-    VOP_GETPAGES() must set the valid bits
-    appropriately. Upon entry to VOP_GETPAGES(), all
-    pages in ma are busied exclusively. Upon successful
-    return, the pages must all be busied exclusively as well, but pages may be
-    unbusied during processing. The filesystem is responsible for activating
-    paged-out pages, but this does not necessarily need to be done within
-    VOP_GETPAGES() depending on the architecture of the
-    particular filesystem.

-

-

-

-
If it successfully reads all pages in ma,
-    VOP_GETPAGES() returns
-    VM_PAGER_OK; otherwise, it returns
-    VM_PAGER_ERROR. By convention, the return value of
-    VOP_PUTPAGES() is
-  rtvals[0].

-

-

-

-
vm_object_pip_wakeup(9),
-    vm_page_free(9), vm_page_sunbusy(9),
-    vm_page_undirty(9), vm_page_xunbusy(9),
-    vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson and then substantially rewritten by
-  

-  Garrett Wollman.

-

-

-
-  
-    
-    
-  
-
June 29, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_INACTIVE.9 4.html b/static/freebsd/man9/VOP_INACTIVE.9 4.html
deleted file mode 100644
index 033ea412..00000000
--- a/static/freebsd/man9/VOP_INACTIVE.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_INACTIVE(9)Kernel Developer's ManualVOP_INACTIVE(9)

-

-

-

-
VOP_INACTIVE,
-    VOP_RECLAIM — reclaim file
-    system resources for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_INACTIVE(struct
-    vnode *vp, struct thread
-    *td);

-
int
-  

-  VOP_RECLAIM(struct
-    vnode *vp, struct thread
-    *td);

-

-

-

-
The arguments are:

-

-  
vp

-  
The vnode being reclaimed.

-

-
()
-    is usually called when the kernel is no longer using the vnode. However,
-    there is no guarantee that it will be called at all, for example if the last
-    reference was dropped while the vnode lock could not be upgraded to
-    exclusive without sleeping. This may be because the reference count reaches
-    zero or it may be that the file system is being forcibly unmounted while
-    there are open files. It can be used to reclaim space on the last close of
-    an ‘open but deleted’ file.

-
()
-    is called when a vnode is being reused for a different file system. Any file
-    system specific resources associated with the vnode should be freed.

-

-

-

-
For both VOP_INACTIVE() and
-    VOP_RECLAIM(), the vp will be
-    exclusively locked on entry, and must be left exclusively locked on
-  return.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
March 15, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_INOTIFY.9 4.html b/static/freebsd/man9/VOP_INOTIFY.9 4.html
deleted file mode 100644
index a7923e74..00000000
--- a/static/freebsd/man9/VOP_INOTIFY.9 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_INOTIFY(9)Kernel Developer's ManualVOP_INOTIFY(9)

-

-

-

-
VOP_INOTIFY —
-    vnode inotify interface

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_INOTIFY(struct,
-    vnode, *vp,
-    struct, vnode,
-    *dvp, struct,
-    componentname, *cnp,
-    int, event,
-    uint32_t, cookie);

-
int
-  

-  VOP_INOTIFY_ADD_WATCH(struct,
-    vnode, *vp,
-    struct, inotify_softc,
-    *sc, uint32_t,
-    mask, uint32_t,
-    *wdp, struct,
-    thread, *td);

-

-

-

-
The
-    ()
-    operation notifies the inotify(2) subsystem of a file
-    system event on a vnode. The dvp and
-    cnp arguments are optional and are only used to obtain
-    a file name for the event. If they are omitted, the inotify subsystem will
-    use the file name cache to find a name for the vnode, but this is more
-    expensive.

-
The
-    ()
-    operation is for internal use by the inotify subsystem to add a watch to a
-    vnode.

-

-

-

-
The VOP_INOTIFY() operation does not
-    assume any particular vnode lock state. The
-    VOP_INOTIFY_ADD_WATCH() operation should be called
-    with the vnode locked.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-
inotify(2), vnode(9)

-

-

-
-  
-    
-    
-  
-
May 27, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_IOCTL.9 4.html b/static/freebsd/man9/VOP_IOCTL.9 4.html
deleted file mode 100644
index 9af742c8..00000000
--- a/static/freebsd/man9/VOP_IOCTL.9 4.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_IOCTL(9)Kernel Developer's ManualVOP_IOCTL(9)

-

-

-

-
VOP_IOCTL — device
-    specific control

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_IOCTL(struct
-    vnode *vp, u_long
-    command, caddr_t
-    data, int fflag,
-    struct ucred *cred,
-    struct thread *td);

-

-

-

-
Manipulate a file in device dependent ways.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file (normally representing a device).

-  
command

-  
The device specific operation to perform.

-  
data

-  
Extra data for the specified operation.

-  
fflag

-  
Some flags ???

-  
cred

-  
The caller's credentials.

-  
td

-  
The calling thread.

-

-
Most file systems do not implement this entry point.

-

-

-

-
The file should not be locked on entry.

-

-

-

-
If successful, zero is returned, otherwise an appropriate error
-    code.

-
If the ioctl is not recognized or not handled,
-    ENOTTY should be returned.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_LINK.9 4.html b/static/freebsd/man9/VOP_LINK.9 4.html
deleted file mode 100644
index ed5ee46b..00000000
--- a/static/freebsd/man9/VOP_LINK.9 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_LINK(9)Kernel Developer's ManualVOP_LINK(9)

-

-

-

-
VOP_LINK — create
-    a new name for a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_LINK(struct
-    vnode *dvp, struct vnode
-    *vp, struct componentname
-    *cnp);

-

-

-

-
This links a new name in the specified directory to an existing
-    file.

-
Its arguments are:

-

-  
dvp

-  
The vnode of the directory.

-  
vp

-  
The vnode of the file to be linked.

-  
cnp

-  
Pathname information about the file.

-

-
The pathname info should not be released on exit
-    because it is done by the caller. The directory and file vnodes should
-    not be released on exit.

-

-

-

-
()
-    expects the directory and file vnodes to be locked on entry and will leave
-    the vnodes locked on return.

-

-

-

-
Zero is returned if the file was linked successfully, otherwise an
-    error is returned.

-

-

-

-

-  
-  
The file has too many links.

-  
[]

-  
The file is immutable.

-  
[]

-  
A hard link is not possible between different file systems.

-

-

-

-

-
vn_lock(9), vnode(9)

-

-

-

-
This manual page was originally written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_LISTEXTATTR.9 4.html b/static/freebsd/man9/VOP_LISTEXTATTR.9 4.html
deleted file mode 100644
index 9f6bf786..00000000
--- a/static/freebsd/man9/VOP_LISTEXTATTR.9 4.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_LISTEXTATTR(9)Kernel Developer's ManualVOP_LISTEXTATTR(9)

-

-

-

-
VOP_LISTEXTATTR —
-    retrieve a list of named extended attributes from a
-    vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/extattr.h>

-
int
-  

-  VOP_LISTEXTATTR(struct vnode
-    *vp, int attrnamespace, struct
-    uio *uio, size_t *size, struct
-    ucred *cred, struct thread *td);

-

-

-

-
This vnode call may be used to retrieve a list of named extended
-    attributes from a specified namespace on a file or directory.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file or directory.

-  
attrnamespace

-  
Integer constant indicating which extended attribute namespace the
-      attribute name is present in.

-  
uio

-  
The location of the data to be read. The resulting data will be a list of
-      attribute names. Each list entry consists of a single byte containing the
-      length of the attribute name, followed by the attribute name. The
-      attribute name is not terminated by ASCII
-    NUL.

-  
size

-  
If not NULL, on return it will contain the number
-      of bytes required to read the list. In most cases
-      uio will be NULL when
-      size is not, and vice versa.

-  
cred

-  
The user credentials to use in authorizing the request.

-  
td

-  
The thread requesting the extended attribute.

-

-
The cred pointer may be
-    NULL to indicate that access control checks are not
-    to be performed, if possible. This cred setting might
-    be used to allow the kernel to authorize extended attribute retrieval that
-    the active process might not be permitted to do.

-
Extended attribute semantics may vary by file system implementing
-    the call. More information on extended attributes may be found in
-    extattr(9).

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
On success, zero will be returned, and the
-    uio structure will be updated to reflect the list
-    read. Otherwise, an appropriate error code is returned.

-

-

-

-

-  
[]

-  
The caller does not have the appropriate privilege.

-  
[]

-  
The request was not valid in this file system for the specified vnode and
-      attribute name.

-  
[]

-  
Sufficient memory is not available to fulfill the request.

-  
[]

-  
The uio structure refers to an invalid userspace
-      address.

-  
[]

-  
The namespace or uio argument
-      is invalid.

-  
[]

-  
The file system does not support
-      VOP_LISTEXTATTR().

-

-

-

-

-
extattr(9), vnode(9),
-    VOP_GETEXTATTR(9), VOP_SETEXTATTR(9)

-

-

-
-  
-    
-    
-  
-
August 19, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_LOCK.9 4.html b/static/freebsd/man9/VOP_LOCK.9 4.html
deleted file mode 100644
index 1045d3fb..00000000
--- a/static/freebsd/man9/VOP_LOCK.9 4.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_LOCK(9)Kernel Developer's ManualVOP_LOCK(9)

-

-

-

-
VOP_LOCK,
-    VOP_UNLOCK, VOP_ISLOCKED,
-    vn_lock — serialize access
-    to a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_LOCK(struct
-    vnode *vp, int
-    flags);

-
int
-  

-  VOP_UNLOCK(struct
-    vnode *vp);

-
int
-  

-  VOP_ISLOCKED(struct
-    vnode *vp);

-
int
-  

-  vn_lock(struct
-    vnode *vp, int
-    flags);

-

-

-

-
These calls are used to serialize access to the file system, such
-    as to prevent two writes to the same file from happening at the same
-  time.

-
The arguments are:

-

-  
vp

-  
The vnode being locked or unlocked.

-  
flags

-  
One of the lock request types:
-    

-    

-    

-      

-      
Shared lock.

-      

-      
Exclusive lock.

-      

-      
Shared-to-exclusive upgrade.

-      

-      
Exclusive-to-shared downgrade.

-      

-      
Release any type of lock.

-      

-      
Wait for all lock activity to end.

-    

-    

-    
The lock type may be or'ed with these lock
-        flags:

-    

-    

-    

-      

-      
Do not sleep to wait for lock.

-      

-      
Sleep, then return failure.

-      

-      
Allow recursive exclusive lock.

-      

-      
Instruct witness(4) to ignore this instance.

-    

-    

-    
The lock type may be or'ed with these
-        control flags:

-    

-    

-    

-      

-      
Specify when the caller already has a simple lock
-          (()
-          will unlock the simple lock after getting the lock).

-      

-      
Retry until locked.

-    

-    

-    
Kernel code should use
-        ()
-        to lock a vnode rather than calling VOP_LOCK()
-        directly. vn_lock() also does not want a thread
-        specified as argument but it assumes curthread to be used.

-  

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
August 23, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_LOOKUP.9 4.html b/static/freebsd/man9/VOP_LOOKUP.9 4.html
deleted file mode 100644
index 2bc6165b..00000000
--- a/static/freebsd/man9/VOP_LOOKUP.9 4.html	
+++ /dev/null
@@ -1,148 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_LOOKUP(9)Kernel Developer's ManualVOP_LOOKUP(9)

-

-

-

-
VOP_LOOKUP —
-    lookup a component of a pathname

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/namei.h>

-
int
-  

-  VOP_LOOKUP(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp);

-

-

-

-
This entry point looks up a single pathname component in a given
-    directory.

-
Its arguments are:

-

-  
dvp

-  
The locked vnode of the directory to search.

-  
vpp

-  
The address of a variable where the resulting locked vnode should be
-      stored.

-  
cnp

-  
The pathname component to be searched for. It is a pointer to a
-      componentname structure defined as follows:
-    

-    
struct componentname {
-	/*
-	 * Arguments to lookup.
-	 */
-	u_long	cn_nameiop;	/* namei operation */
-	u_long	cn_flags;	/* flags to namei */
-	struct	thread *cn_thread;	/* thread requesting lookup */
-	struct	ucred *cn_cred;	/* credentials */
-	int     cn_lkflags;     /* Lock flags LK_EXCLUSIVE or LK_SHARED */
-	/*
-	 * Shared between lookup and commit routines.
-	 */
-	char	*cn_pnbuf;	/* pathname buffer */
-	char	*cn_nameptr;	/* pointer to looked up name */
-	long	cn_namelen;	/* length of looked up component */
-};

-    

-  

-

-
Convert a component of a pathname into a pointer to a locked
-    vnode. This is a very central and rather complicated routine. If the file
-    system is not maintained in a strict tree hierarchy, this can result in a
-    deadlock situation.

-
The cnp->cn_nameiop argument is
-    LOOKUP, CREATE,
-    RENAME, or DELETE depending
-    on the intended use of the object. When CREATE,
-    RENAME, or DELETE is
-    specified, information usable in creating, renaming, or deleting a directory
-    entry may be calculated.

-
Overall outline of VOP_LOOKUP:

-
Check accessibility of directory. Look for name in
-  cache, if found, then return name. Search for name in directory, goto to found
-  or notfound as appropriate.

-
notfound:

-
If creating or renaming and at end of pathname,
-  return EJUSTRETURN, leaving info on available slots
-  else return ENOENT.

-
found:

-
If at end of path and deleting, return information
-  to allow delete. If at end of path and renaming, lock target inode and return
-  info to allow rename. If not at end, add name to cache; if at end and neither
-  creating nor deleting, add name to cache.

-

-

-

-
The directory dvp should be locked on entry
-    and exit, regardless of error condition. If an entry is found in the
-    directory, it will be returned locked.

-

-

-

-
Zero is returned with *vpp set to the locked
-    vnode of the file if the component is found. If the component being searched
-    for is ".", then the vnode just has an extra reference added to it
-    with vref(9). The caller must take care to release the
-    locks appropriately in this case.

-
If the component is not found and the operation is
-    CREATE or RENAME, the flag
-    ISLASTCN is specified and the operation would
-    succeed, the special return value EJUSTRETURN is
-    returned. Otherwise, an appropriate error code is returned.

-

-

-

-

-  
[]

-  
The vnode dvp does not represent a directory.

-  
[]

-  
The component dvp was not found in this
-    directory.

-  
[]

-  
Access for the specified operation is denied.

-  
[]

-  
A CREATE or RENAME
-      operation would be successful.

-

-

-

-

-
vnode(9), VOP_ACCESS(9),
-    VOP_CREATE(9), VOP_MKDIR(9),
-    VOP_MKNOD(9), VOP_RENAME(9),
-    VOP_SYMLINK(9)

-

-

-

-
The function VOP_LOOKUP appeared in
-    4.3BSD.

-

-

-

-
This manual page was written by Doug
-    Rabson, with some text from comments in
-    ufs_lookup.c.

-

-

-
-  
-    
-    
-  
-
August 8, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_OPENCLOSE.9 4.html b/static/freebsd/man9/VOP_OPENCLOSE.9 4.html
deleted file mode 100644
index 14b421c1..00000000
--- a/static/freebsd/man9/VOP_OPENCLOSE.9 4.html	
+++ /dev/null
@@ -1,108 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_OPEN(9)Kernel Developer's ManualVOP_OPEN(9)

-

-

-

-
VOP_OPEN,
-    VOP_CLOSE — open or close a
-    file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_OPEN(struct
-    vnode *vp, int
-    mode, struct ucred
-    *cred, struct thread
-    *td, struct file
-    *fp);

-
int
-  

-  VOP_CLOSE(struct
-    vnode *vp, int
-    mode, struct ucred
-    *cred, struct thread
-    *td);

-

-

-

-
The
-    ()
-    entry point is called before a file is accessed by a process and the
-    VOP_CLOSE() entry point is called after a file is
-    finished with by the process.

-
The arguments are:

-

-  
vp

-  
The vnode of the file.

-  
mode

-  
The access mode required by the calling process.

-  
cred

-  
The caller's credentials.

-  
td

-  
The thread which is accessing the file.

-  
fp

-  
The file being opened.

-

-
Pointer to the file fp is
-    useful for file systems which require such information, e.g.,
-    fdescfs(5). Use
-    ‘NULL’ as fp
-    argument to
-    ()
-    for in-kernel opens.

-
The access mode is a set of flags, including
-    FREAD, FWRITE,
-    O_NONBLOCK, O_APPEND.

-
The thread td passed to
-    ()
-    may be ‘NULL’ if the last reference to
-    the open file is released from a kernel context, e.g., the destruction of a
-    socket buffer containing the file reference in a
-    SCM_RIGHTS message.

-

-

-

-
VOP_OPEN() expects
-    vp to be locked on entry and will leave it locked on
-    return.

-
()
-    expects at least a reference to be associated with the vnode and does not
-    care whether the vnode is locked or not. The lock and reference state is
-    left unchanged on return. Note that vn_close expects
-    an unlocked, referenced vnode and will dereference the vnode prior to
-    returning.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-
vnode(9), VOP_LOOKUP(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
October 17, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_PATHCONF.9 4.html b/static/freebsd/man9/VOP_PATHCONF.9 4.html
deleted file mode 100644
index 7b56f1fb..00000000
--- a/static/freebsd/man9/VOP_PATHCONF.9 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_PATHCONF(9)Kernel Developer's ManualVOP_PATHCONF(9)

-

-

-

-
VOP_PATHCONF —
-    return POSIX pathconf information

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/unistd.h>

-
int
-  

-  VOP_PATHCONF(struct
-    vnode *vp, int
-    name, long
-    *retval);

-

-

-

-
The arguments are:

-

-  
vp

-  
The vnode to get information about.

-  
name

-  
The type of information to return.

-  
retval

-  
The place to return the information.

-

-
The value of name specifies what should be
-    returned:

-

-  

-  
The maximum number of links to a file.

-  

-  
The maximum number of bytes in a file name.

-  

-  
The maximum number of bytes in a pathname.

-  

-  
The maximum number of bytes which will be written atomically to a
-    pipe.

-  

-  
Return 1 if appropriate privileges are required for the
-      chown(2) system call, otherwise 0.

-  

-  
Return 1 if file names longer than KERN_NAME_MAX
-      are truncated.

-

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
If name is recognized,
-    *retval is set to the specified value and zero is
-    returned, otherwise EINVAL is returned.

-

-

-

-
pathconf(2), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
December 31, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_PRINT.9 4.html b/static/freebsd/man9/VOP_PRINT.9 4.html
deleted file mode 100644
index 5e66657d..00000000
--- a/static/freebsd/man9/VOP_PRINT.9 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_PRINT(9)Kernel Developer's ManualVOP_PRINT(9)

-

-

-

-
VOP_PRINT — print
-    debugging information

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_PRINT(struct
-    vnode *vp);

-

-

-

-
The arguments are:

-

-  
vp

-  
The vnode to print.

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_RDWR.9 4.html b/static/freebsd/man9/VOP_RDWR.9 4.html
deleted file mode 100644
index 9010053b..00000000
--- a/static/freebsd/man9/VOP_RDWR.9 4.html	
+++ /dev/null
@@ -1,112 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_RDWR(9)Kernel Developer's ManualVOP_RDWR(9)

-

-

-

-
VOP_READ,
-    VOP_WRITE — read or write a
-    file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/uio.h>

-
int
-  

-  VOP_READ(struct
-    vnode *vp, struct uio
-    *uio, int ioflag,
-    struct ucred *cred);

-
int
-  

-  VOP_WRITE(struct
-    vnode *vp, struct uio
-    *uio, int ioflag,
-    struct ucred *cred);

-

-

-

-
These entry points read or write the contents of a file.

-
The arguments are:

-

-  
vp

-  
The vnode of the file.

-  
uio

-  
The location of the data to be read or written.

-  
ioflag

-  
Various flags.

-  
cnp

-  
The credentials of the caller.

-

-
The ioflag argument is used to give
-    directives and hints to the file system. When attempting a read, the high 16
-    bits are used to provide a read-ahead hint (in units of file system blocks)
-    that the file system should attempt. The low 16 bits are a bit mask which
-    can contain the following flags:

-

-  

-  
Do I/O as atomic unit.

-  

-  
Append write to end.

-  

-  
Do I/O synchronously.

-  

-  
Underlying node already locked.

-  

-  

-      flag set in file table.

-  

-  
Data already in VMIO space.

-

-

-

-

-
The file should be locked on entry and will still be locked on
-    exit. Rangelock covering the whole i/o range should be owned around the
-    call.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-

-  
[]

-  
An attempt was made to write a file that exceeds the process's file size
-      limit or the maximum file size.

-  
[]

-  
The file system is full.

-  
[]

-  
An append-only flag is set on the file, but the caller is attempting to
-      write before the current end of file.

-

-

-

-

-
uiomove(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_READDIR.9 4.html b/static/freebsd/man9/VOP_READDIR.9 4.html
deleted file mode 100644
index 705579f4..00000000
--- a/static/freebsd/man9/VOP_READDIR.9 4.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_READDIR(9)Kernel Developer's ManualVOP_READDIR(9)

-

-

-

-
VOP_READDIR — read
-    contents of a directory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/dirent.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_READDIR(struct
-    vnode *vp, struct uio
-    *uio, struct ucred
-    *cred, int
-    *eofflag, int
-    *ncookies, uint64_t
-    **cookies);

-

-

-

-
Read directory entries.

-

-  
vp

-  
The vnode of the directory.

-  
uio

-  
Where to read the directory contents.

-  
cred

-  
The caller's credentials.

-  
eofflag

-  
Return end of file status (NULL if not
-    wanted).

-  
ncookies

-  
Number of directory cookies generated for NFS
-      (NULL if not wanted).

-  
cookies

-  
Directory seek cookies generated for NFS (NULL if
-      not wanted).

-

-The directory contents are read into struct dirent
-  structures. If the on-disc data structures differ from this then they should
-  be translated.
-

-

-

-
The directory should be locked on entry and will still be locked
-    on exit.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-
If this is called from the NFS server, the extra arguments
-    eofflag, ncookies and
-    cookies are given. The value of
-    *eofflag should be set to TRUE if the end of the
-    directory is reached while reading. The directory seek cookies are returned
-    to the NFS client and may be used later to restart a directory read part way
-    through the directory. There should be one cookie returned per directory
-    entry. The value of the cookie should be the offset within the directory
-    where the on-disc version of the appropriate directory entry starts. Memory
-    for the cookies should be allocated using:

-

-
	...;
-	*ncookies = number of entries read;
-	*cookies = malloc(*ncookies * sizeof(**cookies), M_TEMP, M_WAITOK);

-

-

-

-

-

-  
[]

-  
An attempt was made to read from an illegal offset in the directory.

-  
[]

-  
A read error occurred while reading the directory.

-  
[]

-  
Corrupted data was detected while reading the directory.

-

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
December 13, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_READLINK.9 4.html b/static/freebsd/man9/VOP_READLINK.9 4.html
deleted file mode 100644
index 7d1fe2ac..00000000
--- a/static/freebsd/man9/VOP_READLINK.9 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_READLINK(9)Kernel Developer's ManualVOP_READLINK(9)

-

-

-

-
VOP_READLINK —
-    read the target of a symbolic link

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/uio.h>

-
int
-  

-  VOP_READLINK(struct
-    vnode *vp, struct uio
-    *uio, struct ucred
-    *cred);

-

-

-

-
This reads the target pathname of a symbolic link

-

-  
vp

-  
The vnode of the symlink.

-  
uio

-  
The location of the data to be read or written.

-  
cred

-  
The credentials of the caller.

-

-

-

-

-
The vnode should be locked on entry and will still be locked on
-    exit.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-

-  
[]

-  
A read error occurred while reading the contents of the symlink.

-  
[]

-  
Corrupted data was detected while reading the contents of the
-    symlink.

-

-

-

-

-
uiomove(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
March 30, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_READ_PGCACHE.9 4.html b/static/freebsd/man9/VOP_READ_PGCACHE.9 4.html
deleted file mode 100644
index 75a1e3d4..00000000
--- a/static/freebsd/man9/VOP_READ_PGCACHE.9 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_READ_PGCACHE(9)Kernel Developer's ManualVOP_READ_PGCACHE(9)

-

-

-

-
VOP_READ_PGCACHE —
-    read a file, fast

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/uio.h>

-
int
-  

-  VOP_READ_PGCACHE(struct vnode
-    *vp, struct uio *uio, int
-    ioflag, struct ucred *cred);

-

-

-

-
This entry point reads the contents of a file. The intent is to
-    provide the data from caches, which do not require expensive operations or
-    any disk IO. For instance, if filesystem uses normal VM page cache and
-    maintains v_object lifetime, it can use
-    vn_read_from_obj(9) helper to return data from the
-    resident vp->v_object pages.

-
The filesystem indicates support for the
-    VOP_READ_PGCACHE on specific vnode by setting the
-    VIRF_PGREAD flag in
-    vp->v_irflag.

-
The function does not need to satisfy the whole request; it also
-    might choose to not provide any data. In these cases, the
-    uio must be advanced by the amount of read data,
-    VOP_READ_PGCACHE should return
-    EJUSTRETURN, and VFS would handle the rest of the
-    read operation using the VOP_READ(9).

-
The VFS layer does the same deadlock avoidance for accessing
-    userspace pages from VOP_READ_PGCACHE as for
-    VOP_READ(9).

-
Vnode is not locked on the call entry and should not be locked on
-    return. For a filesystem that requires vnode lock to return any data, it
-    does not make sense to implement VOP_READ_PGCACHE
-    (and set VIRF_PGREAD flag) since VFS arranges the
-    call to VOP_READ(9) as needed.

-
The arguments are:

-

-  
vp

-  
The vnode of the file.

-  
uio

-  
The location of the data to be read.

-  
ioflag

-  
Various flags, see VOP_READ(9) for the list.

-  
cred

-  
The credentials of the caller.

-

-
VOP_READ_PGCACHE does not handle non-zero
-    ioflag argument.

-

-

-

-
The file should be referenced on entry on entry and will still be
-    referenced on exit. Rangelock covering the whole read range should be owned
-    around the call.

-

-

-

-
Zero is returned on success, when the whole request is satisfied,
-    and no more data cannot be provided for it by any means. If more data can be
-    returned, but VOP_READ_PGCACHE was unable to provide
-    it, EJUSTRETURN must be returned. The
-    uio records should be updated according to the
-    partial operation done.

-
Otherwise an error code is returned, same as from
-    VOP_READ(9)

-

-

-

-
uiomove(9), vnode(9),
-    VOP_READ(9)

-

-

-
-  
-    
-    
-  
-
February 28, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_REALLOCBLKS.9 4.html b/static/freebsd/man9/VOP_REALLOCBLKS.9 4.html
deleted file mode 100644
index 0cedb9d5..00000000
--- a/static/freebsd/man9/VOP_REALLOCBLKS.9 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_REALLOCBLKS(9)Kernel Developer's ManualVOP_REALLOCBLKS(9)

-

-

-

-
VOP_REALLOCBLKS —
-    rearrange blocks in a file to be contiguous

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_REALLOCBLKS(struct
-    vnode *vp, struct
-    cluster_save *buflist);

-

-

-

-
The arguments are:

-

-  
vp

-  
The file to manipulate.

-  
buflist

-  
A list of buffers to rearrange.

-

-
This seems to be part of a work in progress.

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
buf(9), vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_REMOVE.9 4.html b/static/freebsd/man9/VOP_REMOVE.9 4.html
deleted file mode 100644
index 2ed9ccb2..00000000
--- a/static/freebsd/man9/VOP_REMOVE.9 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_REMOVE(9)Kernel Developer's ManualVOP_REMOVE(9)

-

-

-

-
VOP_REMOVE,
-    VOP_RMDIR — remove a file or
-    directory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_REMOVE(struct
-    vnode *dvp, struct vnode
-    *vp, struct componentname
-    *cnp);

-
int
-  

-  VOP_RMDIR(struct
-    vnode *dvp, struct vnode
-    *vp, struct componentname
-    *cnp);

-

-

-

-
These entry points remove files and directories respectively.

-
The arguments are:

-

-  
dvp

-  
The vnode of the directory.

-  
vp

-  
The vnode of the file to be removed.

-  
cnp

-  
Pathname information about the file.

-

-

-

-

-
Both dvp and vp should
-    be locked on entry and remain locked on return.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-

-  
[]

-  
The file is immutable.

-  
[]

-  
An attempt was made to remove a directory which is not empty.

-

-

-

-

-
vnode(9), VOP_LOOKUP(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_RENAME.9 4.html b/static/freebsd/man9/VOP_RENAME.9 4.html
deleted file mode 100644
index aa517908..00000000
--- a/static/freebsd/man9/VOP_RENAME.9 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_RENAME(9)Kernel Developer's ManualVOP_RENAME(9)

-

-

-

-
VOP_RENAME —
-    rename a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_RENAME(struct
-    vnode *fdvp, struct vnode
-    *fvp, struct
-    componentname *fcnp,
-    struct vnode *tdvp,
-    struct vnode *tvp,
-    struct componentname
-    *tcnp);

-

-

-

-
This renames a file and possibly changes its parent directory. If
-    the destination object exists, it will be removed first.

-
Its arguments are:

-

-  
fdvp

-  
The vnode of the old parent directory.

-  
fvp

-  
The vnode of the file to be renamed.

-  
fcnp

-  
Pathname information about the file's current name.

-  
tdvp

-  
The vnode of the new parent directory.

-  
tvp

-  
The vnode of the target file (if it exists).

-  
tcnp

-  
Pathname information about the file's new name.

-

-

-

-

-
The source directory and file are unlocked but are expected to
-    have their ref count bumped on entry. The VOP routine is expected to
-    vrele(9) both prior to returning.

-
The destination directory and file are locked as well as having
-    their ref count bumped. The VOP routine is expected to
-    vput(9) both prior to returning.

-

-

-

-

-  
[]

-  
The file is immutable.

-  
[]

-  
It is not possible to rename a file between different file systems.

-  
[]

-  
An attempt was made to rename . or
-      .., or to perform an operation which would break
-      the directory tree structure.

-  
[]

-  
An attempt was made to rename a directory to a file or vice versa.

-  
[]

-  
An attempt was made to remove a directory which is not empty.

-

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_REVOKE.9 4.html b/static/freebsd/man9/VOP_REVOKE.9 4.html
deleted file mode 100644
index 5044f9af..00000000
--- a/static/freebsd/man9/VOP_REVOKE.9 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_REVOKE(9)Kernel Developer's ManualVOP_REVOKE(9)

-

-

-

-
VOP_REVOKE —
-    revoke access to a device and its aliases

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_REVOKE(struct
-    vnode *vp, int
-    flags);

-

-

-

-
()
-    will administratively revoke access to the device specified by
-    vp, as well as any aliases created via
-    make_dev_alias(9). Further file operations on any of these
-    devices by processes which have them open will nominally fail. The
-    flags must be set to REVOKEALL
-    to signify that all access will be revoked; any other value is invalid.

-

-

-

-
The vp must be exclusively locked on entry,
-    and will remain locked upon return.

-

-

-

-
make_dev_alias(9),
-  vnode(9)

-

-

-

-
This manual page was written by Brian Fundakowski
-    Feldman.

-

-

-
-  
-    
-    
-  
-
June 20, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_SETACL.9 4.html b/static/freebsd/man9/VOP_SETACL.9 4.html
deleted file mode 100644
index 48255ca0..00000000
--- a/static/freebsd/man9/VOP_SETACL.9 4.html	
+++ /dev/null
@@ -1,107 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_SETACL(9)Kernel Developer's ManualVOP_SETACL(9)

-

-

-

-
VOP_SETACL — set
-    the access control list for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/acl.h>

-
int
-  

-  VOP_SETACL(struct
-    vnode *vp, acl_type_t
-    type, struct acl
-    *aclp, struct ucred
-    *cred, struct thread
-    *td);

-

-

-

-
This vnode call may be used to set the access control list (ACL)
-    for a file or directory.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file or directory.

-  
type

-  
The type of ACL to set.

-  
aclp

-  
A pointer to an ACL structure from which to retrieve the ACL data.

-  
cred

-  
The user credentials to use in authorizing the request.

-  
td

-  
The thread setting the ACL.

-

-
The aclp pointer may be
-    NULL to indicate that the specified ACL should be
-    deleted.

-
The cred pointer may be
-    NULL to indicate that access control checks are not
-    to be performed, if possible. This cred setting might be used to allow the
-    kernel to authorize ACL changes that the active process might not be
-    permitted to make.

-
The vnode ACL interface defines the syntax, and not semantics, of
-    file and directory ACL interfaces. More information about ACL management in
-    kernel may be found in acl(9).

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
If the ACL is successfully set, then zero is returned. Otherwise,
-    an appropriate error code is returned.

-

-

-

-

-  
[]

-  
The ACL type passed is invalid for this vnode, or the ACL data is
-    invalid.

-  
[]

-  
The caller does not have the appropriate privilege.

-  
[]

-  
Sufficient memory is not available to fulfill the request.

-  
[]

-  
The file system does not support
-    VOP_SETACL().

-  
[]

-  
The file system is out of space.

-  
[]

-  
The file system is read-only.

-

-

-

-

-
acl(9), vnode(9),
-    VOP_ACLCHECK(9), VOP_GETACL(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
December 23, 1999FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_SETEXTATTR.9 4.html b/static/freebsd/man9/VOP_SETEXTATTR.9 4.html
deleted file mode 100644
index db8e3b4a..00000000
--- a/static/freebsd/man9/VOP_SETEXTATTR.9 4.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_SETEXTATTR(9)Kernel Developer's ManualVOP_SETEXTATTR(9)

-

-

-

-
VOP_SETEXTATTR —
-    set named extended attribute for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/extattr.h>

-
int
-  

-  VOP_SETEXTATTR(struct
-    vnode *vp, int
-    attrnamespace, const char
-    *name, struct uio
-    *uio, struct ucred
-    *cred, struct thread
-    *td);

-

-

-

-
This vnode call may be used to set specific named extended
-    attribute for a file or directory.

-
Its arguments are:

-

-  
vp

-  
The vnode of the file or directory.

-  
attrnamespace

-  
Integer constant indicating which extended attribute namespace the
-      attribute name is present in.

-  
name

-  
Pointer to a null-terminated character string containing the attribute
-      name.

-  
uio

-  
The location of the data to be read or written.

-  
cred

-  
The user credentials to use in authorizing the request.

-  
td

-  
The thread setting the extended attribute.

-

-
The uio structure is used in a manner similar to the argument of
-    the same name in VOP_WRITE(9). However, as extended
-    attributes provide a strict "name=value" semantic, non-zero
-    offsets will be rejected.

-
The uio pointer may be
-    NULL to indicate that the specified extended
-    attribute should be deleted.

-
The cred pointer may be
-    NULL to indicate that access control checks are not
-    to be performed, if possible. This cred setting might
-    be used to allow the kernel to authorize extended attribute changes that the
-    active process might not be permitted to make.

-
Extended attribute semantics may vary by file system implementing
-    the call. More information on extended attributes may be found in
-    extattr(9).

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
If the extended attribute is successfully set, then zero is
-    returned. Otherwise, an appropriate error code is returned.

-

-

-

-

-  
[]

-  
The caller does not have the appropriate privilege.

-  
[]

-  
The request was not valid in this file system for the specified vnode and
-      attribute name.

-  
[]

-  
Insufficient memory available to fulfill the request.

-  
[]

-  
The uio structure refers to an invalid userspace address.

-  
[]

-  
The name, namespace, or uio argument is invalid.

-  
[]

-  
The file system does not support
-    VOP_SETEXTATTR().

-  
[]

-  
The file system is out of space.

-  
[]

-  
The file system is read-only.

-

-

-

-

-
extattr(9), vnode(9),
-    VOP_GETEXTATTR(9),
-  VOP_LISTEXTATTR(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
December 23, 1999FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_SETLABEL.9 3.html b/static/freebsd/man9/VOP_SETLABEL.9 3.html
deleted file mode 100644
index 83f28b88..00000000
--- a/static/freebsd/man9/VOP_SETLABEL.9 3.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_SETLABEL(9)Kernel Developer's ManualVOP_SETLABEL(9)

-

-

-

-
VOP_SETLABEL —
-    persistently store an updated MAC label on a
-  vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <security/mac.h>

-
int
-  

-  VOP_SETLABEL(struct
-    vnode *vp, label
-    *label);

-

-

-

-
This vnode call is made by mac(9) file
-    relabeling operation has been authorized, and the filesystem must now be
-    updated.

-

-

-
Filesystems that do not implement per-file labels -- known as
-    single-label filesystems -- can simply leave the vnode(9)
-    operation undefined. These filesystems must not set the
-    MNT_MULTLABEL flag in their struct
-    mount.

-
Filesystems that do implement per-vnode label storage -- known as
-    multi-label filesystems -- will set the
-    MNT_MULTILABEL flag in their struct
-    mount. The UFS filesystem uses a superblock flag to persisently
-    configure whether a specific filesystem implements a label for each
-    vnode(9), and then keys various behaviors on whether that
-    flag is set.

-

-

-

-
If the filesystem implements extended attributes, then the MAC
-    Framework's
-    ()
-    function can be used, and maps operations into a series of
-    VOP_OPENEXTATTR(9), VOP_WRITEEXTATTR(9),
-    and VOP_CLOSEEXTATTR(9).

-
Filesystems will also need to call
-    ()
-    when a new filesystem object is created, so that suitable extended
-    attributes can be written out, and
-    ()
-    when a vnode(9) is associated with a filesystem object for
-    the first time. These utility functions use
-    VOP_OPENEXTATTR(9), VOP_READEXTATTR(9),
-    VOP_WRITEEXTATTR(9), and
-    VOP_CLOSEEXTATTR(9) as required.

-

-

-

-
In all cases, it is important that exclusive
-    vnode(9) locks be held to prevent concurrent access when a
-    MAC label may not yet be initialized. It is also important that operations
-    are ordered so that a system crash does not leave a file improperly labeled.
-    For example, the extended attribute for a newly created file must be written
-    to disk before the file is linked by its parent directory, so that there is
-    no opportunity for a crash to lead to an unlabeled file.

-

-

-

-

-
The vnode will be locked on entry and should remain locked on
-    return.

-

-

-

-
If the MAC label is successfully set, then zero is returned.
-    Otherwise, an appropriate error code is returned.

-

-

-

-

-  
[]

-  
The file system does not support
-    VOP_SETLABEL().

-  
[]

-  
The file system is out of space.

-  
[]

-  
The file system is read-only.

-

-
Depending on the underlying implementation of
-    VOP_SETLABEL(), other errors may also be
-  possible.

-

-

-

-
mac(9), mount(9),
-    vnode(9), VOP_CLOSEEXTATTR(9),
-    VOP_OPENEXTATTR(9), VOP_READEXTATTR(9),
-    VOP_WRITEXTATTR(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
February 27, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_STRATEGY.9 4.html b/static/freebsd/man9/VOP_STRATEGY.9 4.html
deleted file mode 100644
index 9e3042e1..00000000
--- a/static/freebsd/man9/VOP_STRATEGY.9 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_STRATEGY(9)Kernel Developer's ManualVOP_STRATEGY(9)

-

-

-

-
VOP_STRATEGY —
-    read or write a file system buffer

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/buf.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_STRATEGY(struct
-    vnode *vp, struct buf
-    *bp);

-

-

-

-
The arguments are:

-

-  
vp

-  
The vnode that the buffer is for.

-  
bp

-  
The buffer to be read or written.

-

-
This call either reads or writes data from a file, depending on
-    the value of bp->b_iocmd.

-
The call may block.

-

-

-

-
Always zero. Errors should be signalled by setting the
-    BIO_ERROR bit in
-    bp->b_ioflags and setting
-    bp->b_error to the appropriate
-    errno value.

-

-

-

-
errno(2), buf(9),
-    vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 30, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_VPTOCNP.9 4.html b/static/freebsd/man9/VOP_VPTOCNP.9 4.html
deleted file mode 100644
index b67e5d3b..00000000
--- a/static/freebsd/man9/VOP_VPTOCNP.9 4.html	
+++ /dev/null
@@ -1,97 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_VPTOCNP(9)Kernel Developer's ManualVOP_VPTOCNP(9)

-

-

-

-
VOP_VPTOCNP —
-    translate a vnode to its component name

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/ucred.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_VPTOCNP(struct
-    vnode *vp, struct vnode
-    **dvp, struct ucred
-    *cred, char *buf,
-    int *buflen);

-

-

-

-
This translates a vnode into its component name, and writes that
-    name to the head of the buffer specified by buf.

-

-  
vp

-  
The vnode to translate.

-  
dvp

-  
The vnode of the parent directory of vp.

-  
cred

-  
The caller credentials.

-  
buf

-  
The buffer into which to prepend the component name.

-  
buflen

-  
The remaining size of the buffer.

-

-
The default implementation of VOP_VPTOCNP
-    scans through vp's parent directory looking for a
-    dirent with a matching file number. If vp is not a
-    directory, then VOP_VPTOCNP returns ENOENT.

-

-

-

-
The vnode should be locked on entry and will still be locked on
-    exit. The parent directory vnode will be unlocked on a successful exit.
-    However, it will have its use count incremented.

-

-

-

-
Zero is returned on success, otherwise an error code is
-  returned.

-

-

-

-

-  
[]

-  
The buffer was not large enough to hold the vnode's component name.

-  
[]

-  
The vnode was not found on the file system.

-

-

-

-

-
vnode(9), VOP_LOOKUP(9)

-

-

-

-
This interface is a work in progress.

-

-

-

-
The function VOP_VPTOCNP appeared in
-    FreeBSD 8.0.

-

-

-

-
This manual page was written by Joe Marcus
-    Clarke.

-

-

-
-  
-    
-    
-  
-
March 8, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/VOP_VPTOFH.9 4.html b/static/freebsd/man9/VOP_VPTOFH.9 4.html
deleted file mode 100644
index 64e45583..00000000
--- a/static/freebsd/man9/VOP_VPTOFH.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOP_VPTOFH(9)Kernel Developer's ManualVOP_VPTOFH(9)

-

-

-

-
VOP_VPTOFH — turn
-    a vnode into an NFS filehandle

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VOP_VPTOFH(struct
-    vnode *vp, struct fid
-    *fhp);

-

-

-

-
This is used by the NFS server to create an opaque filehandle
-    which uniquely identifies the file and which can be used by an NFS client to
-    access the file in the future.

-
Its arguments are:

-

-  
vp

-  
The vnode to make a filehandle for.

-  
fhp

-  
Return parameter for the filehandle.

-

-

-

-

-
VFS(9), VFS_FHTOVP(9),
-    vnode(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 16, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/accept_filter.9 3.html b/static/freebsd/man9/accept_filter.9 3.html
deleted file mode 100644
index cdfee16f..00000000
--- a/static/freebsd/man9/accept_filter.9 3.html	
+++ /dev/null
@@ -1,129 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCEPT_FILTER(9)Kernel Developer's ManualACCEPT_FILTER(9)

-

-

-

-
accept_filter,
-    accept_filt_add,
-    accept_filt_del,
-    accept_filt_generic_mod_event,
-    accept_filt_get — filter
-    incoming connections

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/module.h>
-  

-  #include <sys/socket.h>

-
#define ACCEPT_FILTER_MOD

-
#include
-    <sys/socketvar.h>

-
int
-  

-  accept_filt_add(struct
-    accept_filter *filt);

-
int
-  

-  accept_filt_del(char
-    *name);

-
int
-  

-  accept_filt_generic_mod_event(module_t
-    mod, int event,
-    void *data);

-
struct accept_filter *
-  

-  accept_filt_get(char
-    *name);

-

-

-

-
Accept filters allow an application to request that the kernel
-    pre-process incoming connections. An accept filter is requested via the
-    setsockopt(2) system call, passing in an
-    optname of
-  SO_ACCEPTFILTER.

-

-

-

-
A module that wants to be an accept filter must provide a
-    struct accept_filter to the system:

-

-
struct accept_filter {
-	char	accf_name[16];
-	void	(*accf_callback)(struct socket *so, void *arg, int waitflag);
-	void *	(*accf_create)(struct socket *so, char *arg);
-	void	(*accf_destroy)(struct socket *so);
-	SLIST_ENTRY(accept_filter) accf_next;	/* next on the list */
-};

-

-
The module should register it with the function
-    accept_filt_add(), passing a pointer to a
-    struct accept_filter, allocated with
-    malloc(9).

-
The fields of struct accept_filter are as
-    follows:

-

-  
accf_name

-  
Name of the filter; this is how it will be accessed from userland.

-  
accf_callback

-  
The callback that the kernel will do once the connection is established.
-      It is the same as a socket upcall and will be called when the connection
-      is established and whenever new data arrives on the socket, unless the
-      callback modifies the socket's flags.

-  
accf_create

-  
Called whenever a setsockopt(2) installs the filter onto
-      a listening socket.

-  
accf_destroy

-  
Called whenever the user removes the accept filter on the socket.

-

-
The accept_filt_del() function passed the
-    same string used in accept_filter.accf_name during
-    registration with accept_filt_add(), the kernel will
-    then disallow and further userland use of the filter.

-
The accept_filt_get() function is used
-    internally to locate which accept filter to use via the
-    setsockopt(2) system call.

-
The accept_filt_generic_mod_event()
-    function provides a simple way to avoid duplication of code for accept
-    filters which do not use the argument field to load and unload themselves.
-    This function can be used in the moduledata_t struct
-    for the DECLARE_MODULE(9) macro.

-

-

-

-
setsockopt(2), accf_data(9),
-    accf_dns(9), accf_http(9),
-    malloc(9)

-

-

-

-
The accept filter mechanism was introduced in
-    FreeBSD 4.0.

-

-

-

-
This manual page was written by Alfred
-    Perlstein, Sheldon Hearn and
-    Jeroen Ruigrok van der Werven.

-
The accept filter concept was pioneered by David
-    Filo at Yahoo! and refined to be a loadable module system by
-    Alfred Perlstein.

-

-

-
-  
-    
-    
-  
-
June 25, 2000FreeBSD 15.0

diff --git a/static/freebsd/man9/accf_data.9 4.html b/static/freebsd/man9/accf_data.9 4.html
deleted file mode 100644
index 00b1ce1d..00000000
--- a/static/freebsd/man9/accf_data.9 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCF_DATA(9)Kernel Developer's ManualACCF_DATA(9)

-

-

-

-
accf_data — buffer
-    incoming connections until data arrives

-

-

-

-
options INET
-  

-  options ACCEPT_FILTER_DATA

-
In rc.conf(5):
-  

-  kld_list="accf_data"

-

-

-

-
This is a filter to be placed on a socket that will be using
-    ()
-    to receive incoming connections.

-
It prevents the application from receiving the
-    connected descriptor via
-    ()
-    until data arrives on the connection.

-
The ACCEPT_FILTER_DATA kernel option is also
-    a module that can be enabled at runtime via kldload(8) if
-    the INET option has been compiled into the kernel.

-

-

-

-
Assuming ACCEPT_FILTER_DATA has been included in the kernel config
-    file or the accf_data module has been loaded, this
-    will enable the data accept filter on the socket
-  sok.

-

-
	struct accept_filter_arg afa;
-
-	bzero(&afa, sizeof(afa));
-	strcpy(afa.af_name, "dataready");
-	setsockopt(sok, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa));

-

-

-

-

-
setsockopt(2),
-    accept_filter(9), accf_dns(9),
-    accf_http(9)

-

-

-

-
The accept filter mechanism and the accf_data filter were
-    introduced in FreeBSD 4.0.

-

-

-

-
This manual page and the filter were written by
-    Alfred Perlstein.

-

-

-
-  
-    
-    
-  
-
November 15, 2000FreeBSD 15.0

diff --git a/static/freebsd/man9/accf_dns.9 3.html b/static/freebsd/man9/accf_dns.9 3.html
deleted file mode 100644
index 1bbb46fe..00000000
--- a/static/freebsd/man9/accf_dns.9 3.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCF_DNS(9)Kernel Developer's ManualACCF_DNS(9)

-

-

-

-
accf_dns — buffer
-    incoming DNS requests until the whole first request is present

-

-

-

-
options INET
-  

-  options ACCEPT_FILTER_DNS

-
In rc.conf(5):
-  

-  kld_list="accf_dns"

-

-

-

-
This is a filter to be placed on a socket that will be using
-    ()
-    to receive incoming connections.

-
It prevents the application from receiving the
-    connected descriptor via
-    ()
-    until a whole DNS request is available on the socket. It does this by
-    reading the first two bytes of the request, to determine its size, and
-    waiting until the required amount of data is available to be read.

-
The ACCEPT_FILTER_DNS kernel option is also
-    a module that can be enabled at runtime via kldload(8) if
-    the INET option has been compiled into the kernel.

-

-

-

-
If the accf_dns module is available in the
-    kernel, the following code will enable the DNS accept filter on a socket
-    sok.

-

-
	struct accept_filter_arg afa;
-
-	bzero(&afa, sizeof(afa));
-	strcpy(afa.af_name, "dnsready");
-	setsockopt(sok, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa));

-

-

-

-

-
setsockopt(2),
-    accept_filter(9), accf_data(9),
-    accf_http(9)

-

-

-

-
The accept filter mechanism was introduced in
-    FreeBSD 4.0.

-

-

-

-
This manual page and the filter were written by
-    David Malone.

-

-

-
-  
-    
-    
-  
-
July 16, 2008FreeBSD 15.0

diff --git a/static/freebsd/man9/accf_http.9 3.html b/static/freebsd/man9/accf_http.9 3.html
deleted file mode 100644
index f25c2c43..00000000
--- a/static/freebsd/man9/accf_http.9 3.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCF_HTTP(9)Kernel Developer's ManualACCF_HTTP(9)

-

-

-

-
accf_http — buffer
-    incoming connections until a certain complete HTTP request
-  arrives

-

-

-

-
options INET
-  

-  options ACCEPT_FILTER_HTTP

-
In rc.conf(5):
-  

-  kld_list="accf_http"

-

-

-

-
This is a filter to be placed on a socket that will be using
-    ()
-    to receive incoming HTTP connections.

-
It prevents the application from receiving the
-    connected descriptor via
-    ()
-    until either a full HTTP/1.0 or HTTP/1.1 HEAD or GET request has been
-    buffered by the kernel.

-
If something other than a HTTP/1.0 or HTTP/1.1 HEAD
-    or GET request is received the kernel will allow the application to receive
-    the connection descriptor via
-    ().

-
The utility of accf_http is
-    such that a server will not have to context switch several times before
-    performing the initial parsing of the request. This effectively reduces the
-    amount of required CPU utilization to handle incoming requests by keeping
-    active processes in preforking servers such as Apache low and reducing the
-    size of the file descriptor set that needs to be managed by interfaces such
-    as (),
-    ()
-    or
-    ()
-    based servers.

-
The accf_http kernel option is also a
-    module that can be enabled at runtime via kldload(8) if
-    the INET option has been compiled into the kernel.

-

-

-

-
Assuming ACCEPT_FILTER_HTTP has been included in the kernel config
-    file or the accf_http module has been loaded, this
-    will enable the http accept filter on the socket
-  sok.

-

-
	struct accept_filter_arg afa;
-
-	bzero(&afa, sizeof(afa));
-	strcpy(afa.af_name, "httpready");
-	setsockopt(sok, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa));

-

-

-

-

-
setsockopt(2),
-    accept_filter(9)

-

-

-

-
The accept filter mechanism and the accf_http filter were
-    introduced in FreeBSD 4.0.

-

-

-

-
This manual page and the filter were written by
-    Alfred Perlstein.

-

-

-
-  
-    
-    
-  
-
November 15, 2000FreeBSD 15.0

diff --git a/static/freebsd/man9/accf_tls.9 3.html b/static/freebsd/man9/accf_tls.9 3.html
deleted file mode 100644
index 35adbf1e..00000000
--- a/static/freebsd/man9/accf_tls.9 3.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCF_TLS(9)Kernel Developer's ManualACCF_TLS(9)

-

-

-

-
accf_tls — buffer
-    incoming connections until a TLS handshake like request arrives

-

-

-

-
options INET
-  

-  options ACCEPT_FILTER_TLS

-
In rc.conf(5):
-  

-  kld_list="accf_tls"

-

-

-

-
This is a filter to be placed on a socket that will be using
-    (2)
-    to receive incoming HTTPS connections. It prevents the application from
-    receiving the connected descriptor via
-    accept(2) until a full TLS
-    handshake has been buffered by the kernel. The
-    accf_tls will first check that byte at offset 0 is
-    0x16, which matches handshake type. Then it will read
-    2-byte request length value at offset 3 and will continue reading until
-    reading the entire length of the handshake is buffered. If something other
-    than 0x16 is at offset 0, the kernel will allow the
-    application to receive the connection descriptor via
-    accept(2).

-
The utility of accf_tls is
-    such that a server will not have to context switch several times before
-    performing the initial parsing of the request. This effectively reduces the
-    amount of required CPU utilization to handle incoming requests by keeping
-    active processes in preforking servers such as Apache low and reducing the
-    size of the file descriptor set that needs to be managed by interfaces such
-    as (),
-    ()
-    or
-    ()
-    based servers.

-

-

-

-
Assuming ACCEPT_FILTER_TLS has been included in the kernel config
-    file or the accf_tls module has been loaded, this
-    will enable the TLS accept filter on the socket
-  sok.

-

-
	struct accept_filter_arg afa;
-
-	bzero(&afa, sizeof(afa));
-	strcpy(afa.af_name, "tlsready");
-	setsockopt(sok, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa));

-

-

-

-

-
setsockopt(2),
-    accept_filter(9)

-

-

-

-
The accf_tls accept filter was introduced
-    in FreeBSD 15.0.

-

-

-

-
The accf_tls filter was written by
-    Maksim Yevmenkin.

-

-

-
-  
-    
-    
-  
-
April 24, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/acl.9 3.html b/static/freebsd/man9/acl.9 3.html
deleted file mode 100644
index 4e630c5c..00000000
--- a/static/freebsd/man9/acl.9 3.html	
+++ /dev/null
@@ -1,207 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACL(9)Kernel Developer's ManualACL(9)

-

-

-

-
acl — virtual file
-    system access control lists

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/acl.h>

-
In the kernel configuration file:
-  

-  options UFS_ACL

-

-

-

-
Access control lists, or ACLs, allow fine-grained specification of
-    rights for vnodes representing files and directories. However, as there are
-    a plethora of file systems with differing ACL semantics, the vnode interface
-    is aware only of the syntax of ACLs, relying on the underlying file system
-    to implement the details. Depending on the underlying file system, each file
-    or directory may have zero or more ACLs associated with it, named using the
-    type field of the appropriate vnode ACL calls:
-    VOP_ACLCHECK(9), VOP_GETACL(9), and
-    VOP_SETACL(9).

-
Currently, each ACL is represented in-kernel by a fixed-size
-    acl structure, defined as follows:

-

-
struct acl {
-        unsigned int            acl_maxcnt;
-        unsigned int            acl_cnt;
-        int                     acl_spare[4];
-        struct acl_entry        acl_entry[ACL_MAX_ENTRIES];
-};

-

-
An ACL is constructed from a fixed size array of ACL entries, each
-    of which consists of a set of permissions, principal namespace, and
-    principal identifier. In this implementation, the
-    acl_maxcnt field is always set to
-    ACL_MAX_ENTRIES.

-
Each individual ACL entry is of the type
-    acl_entry_t, which is a structure with the following
-    members:

-

-  
acl_tag_t ae_tag

-  
The following is a list of definitions of ACL types to be set in
-      ae_tag:
-    

-    

-    

-      

-      
Undefined ACL type.

-      

-      
Discretionary access rights for processes whose effective user ID
-          matches the user ID of the file's owner.

-      

-      
Discretionary access rights for processes whose effective user ID
-          matches the ACL entry qualifier.

-      

-      
Discretionary access rights for processes whose effective group ID or
-          any supplemental groups match the group ID of the file's owner.

-      

-      
Discretionary access rights for processes whose effective group ID or
-          any supplemental groups match the ACL entry qualifier.

-      

-      
The maximum discretionary access rights that can be granted to a
-          process in the file group class. This is only valid for POSIX.1e
-        ACLs.

-      

-      
Discretionary access rights for processes not covered by any other ACL
-          entry. This is only valid for POSIX.1e ACLs.

-      

-      
Same as ACL_OTHER.

-      

-      
Discretionary access rights for all users. This is only valid for
-          NFSv4 ACLs.

-    

-    

-    
Each POSIX.1e ACL must contain exactly one
-        ACL_USER_OBJ, one
-        ACL_GROUP_OBJ, and one
-        ACL_OTHER. If any of
-        ACL_USER, ACL_GROUP, or
-        ACL_OTHER are present, then exactly one
-        ACL_MASK entry should be present.

-  

-  
uid_t ae_id

-  
The ID of user for whom this ACL describes access permissions. For entries
-      other than ACL_USER and
-      ACL_GROUP, this field should be set to
-      ACL_UNDEFINED_ID.

-  
acl_perm_t ae_perm

-  
This field defines what kind of access the process matching this ACL has
-      for accessing the associated file. For POSIX.1e ACLs, the following are
-      valid:
-    

-      

-      
The process may execute the associated file.

-      

-      
The process may write to the associated file.

-      

-      
The process may read from the associated file.

-      

-      
The process has no read, write or execute permissions to the
-          associated file.

-    

-    
For NFSv4 ACLs, the following are valid:

-    

-      

-      
The process may read from the associated file.

-      

-      
Same as ACL_READ_DATA.

-      

-      
The process may write to the associated file.

-      

-      
Same as ACL_ACL_WRITE_DATA.

-      

-      
 

-      

-      
Same as ACL_APPEND_DATA.

-      

-      
Ignored.

-      

-      
Ignored.

-      

-      
The process may execute the associated file.

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
Ignored.

-    

-  

-  
acl_entry_type_t
-    ae_entry_type

-  
This field defines the type of NFSv4 ACL entry. It is not used with
-      POSIX.1e ACLs. The following values are valid:
-    

-      

-      
 

-      

-      
 

-    

-  

-  
acl_flag_t ae_flags

-  
This field defines the inheritance flags of NFSv4 ACL entry. It is not
-      used with POSIX.1e ACLs. The following values are valid:
-    

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-    

-    The ACL_ENTRY_INHERITED flag is set on an ACE that
-      has been inherited from its parent. It may also be set programmatically,
-      and is valid on both files and directories.

-

-

-

-

-
acl(3), vaccess(9),
-    vaccess_acl_nfs4(9),
-    vaccess_acl_posix1e(9), VFS(9),
-    VOP_ACLCHECK(9), VOP_GETACL(9),
-    VOP_SETACL(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
September 4, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/alq.9 3.html b/static/freebsd/man9/alq.9 3.html
deleted file mode 100644
index 5f249196..00000000
--- a/static/freebsd/man9/alq.9 3.html	
+++ /dev/null
@@ -1,300 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALQ(9)Kernel Developer's ManualALQ(9)

-

-

-

-
alq,
-    alq_open_flags, alq_open,
-    alq_writen, alq_write,
-    alq_flush, alq_close,
-    alq_getn, alq_get,
-    alq_post_flags, alq_post
-    — Asynchronous Logging Queues

-

-

-

-
#include
-    <sys/alq.h>

-
int
-  

-  alq_open_flags(struct alq **app,
-    const char *file, struct ucred
-    *cred, int cmode, int
-    size, int flags);

-
int
-  

-  alq_open(struct alq **app,
-    const char *file, struct ucred
-    *cred, int cmode, int
-    size, int count);

-
int
-  

-  alq_writen(struct
-    alq *alq, void
-    *data, int len,
-    int flags);

-
int
-  

-  alq_write(struct
-    alq *alq, void
-    *data, int
-  flags);

-
void
-  

-  alq_flush(struct
-    alq *alq);

-
void
-  

-  alq_close(struct
-    alq *alq);

-
struct ale *
-  

-  alq_getn(struct
-    alq *alq, int len,
-    int flags);

-
struct ale *
-  

-  alq_get(struct
-    alq *alq, int
-    flags);

-
void
-  

-  alq_post_flags(struct
-    alq *alq, struct ale
-    *ale, int
-  flags);

-
void
-  

-  alq_post(struct
-    alq *alq, struct ale
-    *ale);

-

-

-

-
The alq facility provides an asynchronous
-    fixed or variable length recording mechanism, known as Asynchronous Logging
-    Queues. It can record to any vnode(9), thus providing the
-    ability to journal logs to character devices as well as regular files. All
-    functions accept a struct alq argument, which is an
-    opaque type that maintains state information for an Asynchronous Logging
-    Queue. The logging facility runs in a separate kernel thread, which services
-    all log entry requests.

-
An “asynchronous log entry” is defined as
-    struct ale, which has the following members:

-

-
struct ale {
-	intptr_t	ae_bytesused;	/* # bytes written to ALE. */
-	char		*ae_data;	/* Write ptr. */
-	int		ae_pad;		/* Unused, compat. */
-};

-

-
An alq can be created in
-    either fixed or variable length mode. A variable length
-    alq accommodates writes of varying length using
-    ()
-    and alq_getn(). A fixed length
-    alq accommodates a fixed number of writes using
-    alq_write() and alq_get(),
-    each of fixed size (set at queue creation time). Fixed length mode is
-    deprecated in favour of variable length mode.

-

-

-

-
The alq_open_flags() function creates a
-    new variable length asynchronous logging queue. The
-    file argument is the name of the file to open for
-    logging. If the file does not yet exist, alq_open()
-    will attempt to create it. The cmode argument will be
-    passed to
-    ()
-    as the requested creation mode, to be used if the file will be created by
-    alq_open(). Consumers of this API may wish to pass
-    ALQ_DEFAULT_CMODE, a default creation mode suitable
-    for most applications. The cred argument specifies the
-    credentials to use when opening and performing I/O on the file. The
-    size argument sets the size (in bytes) of the
-    underlying queue. The ALQ_ORDERED flag may be passed in via
-    flags to indicate that the ordering of writer threads
-    waiting for a busy alq to free up resources should
-    be preserved.

-
The deprecated
-    ()
-    function is implemented as a wrapper around
-    ()
-    to provide backwards compatibility to consumers that have not been updated
-    to utilise the newer alq_open_flags() function. It
-    passes all arguments through to alq_open_flags()
-    untouched except for size and
-    count, and sets flags to 0. To
-    create a variable length mode alq, the
-    size argument should be set to the size (in bytes) of
-    the underlying queue and the count argument should be
-    set to 0. To create a fixed length mode alq, the
-    size argument should be set to the size (in bytes) of
-    each write and the count argument should be set to the
-    number of size byte chunks to reserve capacity
-  for.

-
The
-    ()
-    function writes len bytes from
-    data to the designated variable length mode queue
-    alq. If alq_writen() could not
-    write the entry immediately and ALQ_WAITOK is set in
-    flags, the function will be allowed to
-    msleep_spin(9) with the
-    “alqwnord” or
-    “alqwnres” wait message. A write will
-    automatically schedule the queue alq to be flushed to
-    disk. This behaviour can be controlled by passing ALQ_NOACTIVATE via
-    flags to indicate that the write should not schedule
-    alq to be flushed to disk.

-
The deprecated
-    ()
-    function is implemented as a wrapper around
-    alq_writen() to provide backwards compatibility to
-    consumers that have not been updated to utilise variable length mode queues.
-    The function will write size bytes of data (where
-    size was specified at queue creation time) from the
-    data buffer to the alq. Note
-    that it is an error to call alq_write() on a
-    variable length mode queue.

-
The
-    ()
-    function is used for flushing alq to the log medium
-    that was passed to alq_open(). If
-    alq has data to flush and is not already in the
-    process of being flushed, the function will block doing IO. Otherwise, the
-    function will return immediately.

-
The
-    ()
-    function will close the asynchronous logging queue alq
-    and flush all pending write requests to the log medium. It will free all
-    resources that were previously allocated.

-
The
-    ()
-    function returns an asynchronous log entry from alq,
-    initialised to point at a buffer capable of receiving
-    len bytes of data. This function leaves
-    alq in a locked state, until a subsequent
-    alq_post() or
-    alq_post_flags() call is made. If
-    alq_getn() could not obtain
-    len bytes of buffer immediately and
-    ALQ_WAITOK is set in flags,
-    the function will be allowed to msleep_spin(9) with the
-    “alqgnord” or
-    “alqgnres” wait message. The caller
-    can choose to write less than len bytes of data to the
-    returned asynchronous log entry by setting the entry's ae_bytesused field to
-    the number of bytes actually written. This must be done prior to calling
-    alq_post().

-
The deprecated
-    ()
-    function is implemented as a wrapper around
-    alq_getn() to provide backwards compatibility to
-    consumers that have not been updated to utilise variable length mode queues.
-    The asynchronous log entry returned will be initialised to point at a buffer
-    capable of receiving size bytes of data (where
-    size was specified at queue creation time). Note that
-    it is an error to call alq_get() on a variable
-    length mode queue.

-
The
-    ()
-    function schedules the asynchronous log entry ale
-    (obtained from alq_getn() or
-    alq_get()) for writing to alq.
-    The ALQ_NOACTIVATE flag may be passed in via flags to
-    indicate that the queue should not be immediately scheduled to be flushed to
-    disk. This function leaves alq in an unlocked
-  state.

-
The
-    ()
-    function is implemented as a wrapper around
-    alq_post_flags() to provide backwards compatibility
-    to consumers that have not been updated to utilise the newer
-    alq_post_flags() function. It simply passes all
-    arguments through to alq_post_flags() untouched, and
-    sets flags to 0.

-

-

-

-
The alq_writen() and
-    alq_write() functions both perform a
-    bcopy(3) from the supplied data
-    buffer into the underlying alq buffer. Performance
-    critical code paths may wish to consider using
-    alq_getn() (variable length queues) or
-    alq_get() (fixed length queues) to avoid the extra
-    memory copy. Note that a queue remains locked between calls to
-    alq_getn() or alq_get() and
-    alq_post() or
-    alq_post_flags(), so this method of writing to a
-    queue is unsuitable for situations where the time between calls may be
-    substantial.

-

-

-

-
Each asynchronous logging queue is protected by a spin mutex.

-
Functions
-    ()
-    and alq_open() may attempt to acquire an internal
-    sleep mutex, and should consequently not be used in contexts where sleeping
-    is not allowed.

-

-

-

-
The alq_open() function returns one of the
-    error codes listed in open(2), if it fails to open
-    file, or else it returns 0.

-
The alq_writen() and
-    alq_write() functions return
-    EWOULDBLOCK if ALQ_NOWAIT
-    was set in flags and either the queue is full or the
-    system is shutting down.

-
The alq_getn() and
-    alq_get() functions return
-    NULL if ALQ_NOWAIT was set
-    in flags and either the queue is full or the system is
-    shutting down.

-
NOTE: invalid arguments to non-void functions will result in
-    undefined behaviour.

-

-

-

-
syslog(3), kproc(9),
-    ktr(9), msleep_spin(9),
-    vnode(9)

-

-

-

-
The Asynchronous Logging Queues (ALQ) facility first appeared in
-    FreeBSD 5.0.

-

-

-

-
The alq facility was written by
-    Jeffrey Roberson
-    <jeff@FreeBSD.org>
-    and extended by Lawrence Stewart
-    <lstewart@freebsd.org>.

-
This manual page was written by Hiten
-    Pandya
-    <hmp@FreeBSD.org> and
-    revised by Lawrence Stewart
-    <lstewart@freebsd.org>.

-

-

-
-  
-    
-    
-  
-
April 26, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/altq.9 3.html b/static/freebsd/man9/altq.9 3.html
deleted file mode 100644
index bc95d846..00000000
--- a/static/freebsd/man9/altq.9 3.html	
+++ /dev/null
@@ -1,510 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALTQ(9)Kernel Developer's ManualALTQ(9)

-

-

-

-
ALTQ — kernel
-    interfaces for manipulating output queues on network interfaces

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <net/if.h>
-  

-  #include <net/if_var.h>

-

-

-
IFQ_ENQUEUE(struct
-    ifaltq *ifq, struct mbuf
-    *m, int error);

-
IFQ_HANDOFF(struct
-    ifnet *ifp, struct mbuf
-    *m, int error);

-
IFQ_HANDOFF_ADJ(struct
-    ifnet *ifp, struct mbuf *m, int
-    adjust, int error);

-

-

-

-
IFQ_DEQUEUE(struct
-    ifaltq *ifq, struct mbuf
-    *m);

-
IFQ_POLL_NOLOCK(struct
-    ifaltq *ifq, struct mbuf
-    *m);

-
IFQ_PURGE(struct
-    ifaltq *ifq);

-
IFQ_IS_EMPTY(struct
-    ifaltq *ifq);

-

-

-

-
IFQ_DRV_DEQUEUE(struct
-    ifaltq *ifq, struct mbuf
-    *m);

-
IFQ_DRV_PREPEND(struct
-    ifaltq *ifq, struct mbuf
-    *m);

-
IFQ_DRV_PURGE(struct
-    ifaltq *ifq);

-
IFQ_DRV_IS_EMPTY(struct
-    ifaltq *ifq);

-

-

-

-
IFQ_SET_MAXLEN(struct
-    ifaltq *ifq, int
-    len);

-
IFQ_INC_LEN(struct
-    ifaltq *ifq);

-
IFQ_DEC_LEN(struct
-    ifaltq *ifq);

-
IFQ_INC_DROPS(struct
-    ifaltq *ifq);

-
IFQ_SET_READY(struct
-    ifaltq *ifq);

-

-

-

-

-
The ALTQ system is a framework to manage
-    queuing disciplines on network interfaces. ALTQ
-    introduces new macros to manipulate output queues. The output queue macros
-    are used to abstract queue operations and not to touch the internal fields
-    of the output queue structure. The macros are independent from the
-    ALTQ implementation, and compatible with the
-    traditional ifqueue macros for ease of transition.

-
(),
-    ()
-    and
-    ()
-    enqueue a packet m to the queue
-    ifq. The underlying queuing discipline may discard the
-    packet. The error argument is set to 0 on success, or
-    ENOBUFS if the packet is discarded. The packet
-    pointed to by m will be freed by the device driver on
-    success, or by the queuing discipline on failure, so the caller should not
-    touch m after enqueuing.
-    IFQ_HANDOFF() and
-    IFQ_HANDOFF_ADJ() combine the enqueue operation with
-    statistic generation and call
-    ()
-    upon successful enqueue to initiate the actual send.

-
()
-    dequeues a packet from the queue. The dequeued packet is returned in
-    m, or m is set to
-    NULL if no packet is dequeued. The caller must
-    always check m since a non-empty queue could return
-    NULL under rate-limiting.

-
()
-    returns the next packet without removing it from the queue. The caller must
-    hold the queue mutex when calling IFQ_POLL_NOLOCK()
-    in order to guarantee that a subsequent call to
-    ()
-    dequeues the same packet.

-
()
-    variants (if available) always assume that the caller holds the queue mutex.
-    They can be grabbed with
-    ()
-    and released with
-    ().

-
()
-    discards all the packets in the queue. The purge operation is needed since a
-    non-work conserving queue cannot be emptied by a dequeue loop.

-
()
-    can be used to check if the queue is empty. Note that
-    IFQ_DEQUEUE() could still return
-    NULL if the queuing discipline is non-work
-    conserving.

-
()
-    moves up to ifq->ifq_drv_maxlen packets from the
-    queue to the “driver managed” queue and returns the first one
-    via m. As for IFQ_DEQUEUE(),
-    m can be NULL even for a
-    non-empty queue. Subsequent calls to
-    IFQ_DRV_DEQUEUE() pass the packets from the
-    “driver managed” queue without obtaining the queue mutex. It
-    is the responsibility of the caller to protect against concurrent access.
-    Enabling ALTQ for a given queue sets
-    ifq_drv_maxlen to 0 as the “bulk
-    dequeue” performed by IFQ_DRV_DEQUEUE() for
-    higher values of ifq_drv_maxlen is adverse to
-    ALTQ's internal timing. Note that a driver must not
-    mix
-    ()
-    macros with the default dequeue macros as the default macros do not look at
-    the “driver managed” queue which might lead to an mbuf
-  leak.

-
()
-    prepends m to the “driver managed” queue
-    from where it will be obtained with the next call to
-    IFQ_DRV_DEQUEUE().

-
()
-    flushes all packets in the “driver managed” queue and calls to
-    IFQ_PURGE() afterwards.

-
()
-    checks for packets in the “driver managed” part of the queue.
-    If it is empty, it forwards to IFQ_IS_EMPTY().

-
()
-    sets the queue length limit to the default FIFO queue. The
-    ifq_drv_maxlen member of the
-    ifaltq structure controls the length limit of the
-    “driver managed” queue.

-
()
-    and
-    ()
-    increment or decrement the current queue length in packets. This is mostly
-    for internal purposes.

-
()
-    increments the drop counter and is identical to
-    ().
-    It is defined for naming consistency only.

-
()
-    sets a flag to indicate that a driver was converted to use the new macros.
-    ALTQ can be enabled only on interfaces with this
-    flag.

-

-

-

-

-

-
In order to keep compatibility with the existing code, the new
-    output queue structure ifaltq has the same fields. The
-    traditional IF_*() macros and the code directly
-    referencing the fields within if_snd still work with
-    ifaltq.

-

-
            ##old-style##                           ##new-style##
-                                       |
- struct ifqueue {                      | struct ifaltq {
-    struct mbuf *ifq_head;             |    struct mbuf *ifq_head;
-    struct mbuf *ifq_tail;             |    struct mbuf *ifq_tail;
-    int          ifq_len;              |    int          ifq_len;
-    int          ifq_maxlen;           |    int          ifq_maxlen;
- };                                    |    /* driver queue fields */
-                                       |    ......
-                                       |    /* altq related fields */
-                                       |    ......
-                                       | };
-                                       |

-

-The new structure replaces struct ifqueue in
-  struct ifnet.
-

-
            ##old-style##                           ##new-style##
-                                       |
- struct ifnet {                        | struct ifnet {
-     ....                              |     ....
-                                       |
-     struct ifqueue if_snd;            |     struct ifaltq if_snd;
-                                       |
-     ....                              |     ....
- };                                    | };
-                                       |

-

-The (simplified) new IFQ_*() macros look like:
-

-
	#define IFQ_DEQUEUE(ifq, m)			\
-		if (ALTQ_IS_ENABLED((ifq))		\
-			ALTQ_DEQUEUE((ifq), (m));	\
-		else					\
-			IF_DEQUEUE((ifq), (m));

-

-

-

-

-
The semantics of the enqueue operation is changed. In the new
-    style, enqueue and packet drop are combined since they cannot be easily
-    separated in many queuing disciplines. The new enqueue operation corresponds
-    to the following macro that is written with the old macros.

-

-
#define	IFQ_ENQUEUE(ifq, m, error)                      \
-do {                                                    \
-        if (IF_QFULL((ifq))) {                          \
-                m_freem((m));                           \
-                (error) = ENOBUFS;                      \
-                IF_DROP(ifq);                           \
-        } else {                                        \
-                IF_ENQUEUE((ifq), (m));                 \
-                (error) = 0;                            \
-        }                                               \
-} while (0)

-

-
IFQ_ENQUEUE() does the following:

-

-
    
-  
  • queue a packet,
    • 
-  
  • drop (and free) a packet if the enqueue operation fails.
    • 
-

-
If the enqueue operation fails, error is set
-    to ENOBUFS. The m mbuf is
-    freed by the queuing discipline. The caller should not touch mbuf after
-    calling IFQ_ENQUEUE() so that the caller may need to
-    copy m_pkthdr.len or m_flags
-    field beforehand for statistics. IFQ_HANDOFF() and
-    IFQ_HANDOFF_ADJ() can be used if only default
-    interface statistics and an immediate call to
-    if_start() are desired. The caller should not use
-    senderr() since mbuf was already freed.

-
The new style if_output() looks as
-    follows:

-

-
            ##old-style##                           ##new-style##
-                                       |
- int                                   | int
- ether_output(ifp, m0, dst, rt0)       | ether_output(ifp, m0, dst, rt0)
- {                                     | {
-     ......                            |     ......
-                                       |
-                                       |     mflags = m->m_flags;
-                                       |     len = m->m_pkthdr.len;
-     s = splimp();                     |     s = splimp();
-     if (IF_QFULL(&ifp->if_snd)) {     |     IFQ_ENQUEUE(&ifp->if_snd, m,
-                                       |                 error);
-         IF_DROP(&ifp->if_snd);        |     if (error != 0) {
-         splx(s);                      |         splx(s);
-         senderr(ENOBUFS);             |         return (error);
-     }                                 |     }
-     IF_ENQUEUE(&ifp->if_snd, m);      |
-     ifp->if_obytes +=                 |     ifp->if_obytes += len;
-                    m->m_pkthdr.len;   |
-     if (m->m_flags & M_MCAST)         |     if (mflags & M_MCAST)
-         ifp->if_omcasts++;            |         ifp->if_omcasts++;
-                                       |
-     if ((ifp->if_flags & IFF_OACTIVE) |     if ((ifp->if_flags & IFF_OACTIVE)
-         == 0)                         |         == 0)
-         (*ifp->if_start)(ifp);        |         (*ifp->if_start)(ifp);
-     splx(s);                          |     splx(s);
-     return (error);                   |     return (error);
-                                       |
- bad:                                  | bad:
-     if (m)                            |     if (m)
-         m_freem(m);                   |         m_freem(m);
-     return (error);                   |     return (error);
- }                                     | }
-                                       |

-

-

-

-

-

-
First, make sure the corresponding
-    ()
-    is already converted to the new style.

-
Look for if_snd in the driver. Probably, you
-    need to make changes to the lines that include
-  if_snd.

-

-

-
If the code checks ifq_head to see whether
-    the queue is empty or not, use
-    ().

-

-
            ##old-style##                           ##new-style##
-                                       |
- if (ifp->if_snd.ifq_head != NULL)     | if (!IFQ_IS_EMPTY(&ifp->if_snd))
-                                       |

-

-IFQ_IS_EMPTY() only checks if there is any packet stored
-  in the queue. Note that even when IFQ_IS_EMPTY() is
-  FALSE, IFQ_DEQUEUE() could
-  still return NULL if the queue is under rate-limiting.
-

-

-

-
Replace
-    ()
-    by IFQ_DEQUEUE(). Always check whether the dequeued
-    mbuf is NULL or not. Note that even when
-    IFQ_IS_EMPTY() is FALSE,
-    IFQ_DEQUEUE() could return
-    NULL due to rate-limiting.

-

-
            ##old-style##                           ##new-style##
-                                       |
- IF_DEQUEUE(&ifp->if_snd, m);          | IFQ_DEQUEUE(&ifp->if_snd, m);
-                                       | if (m == NULL)
-                                       |     return;
-                                       |

-

-A driver is supposed to call if_start() from
-  transmission complete interrupts in order to trigger the next dequeue.
-

-

-

-
If the code polls the packet at the head of the queue and actually
-    uses the packet before dequeuing it, use
-    IFQ_POLL_NOLOCK() and
-    IFQ_DEQUEUE_NOLOCK().

-

-
            ##old-style##                           ##new-style##
-                                       |
-                                       | IFQ_LOCK(&ifp->if_snd);
- m = ifp->if_snd.ifq_head;             | IFQ_POLL_NOLOCK(&ifp->if_snd, m);
- if (m != NULL) {                      | if (m != NULL) {
-                                       |
-     /* use m to get resources */      |     /* use m to get resources */
-     if (something goes wrong)         |     if (something goes wrong)
-                                       |         IFQ_UNLOCK(&ifp->if_snd);
-         return;                       |         return;
-                                       |
-     IF_DEQUEUE(&ifp->if_snd, m);      |     IFQ_DEQUEUE_NOLOCK(&ifp->if_snd, m);
-                                       |     IFQ_UNLOCK(&ifp->if_snd);
-                                       |
-     /* kick the hardware */           |     /* kick the hardware */
- }                                     | }
-                                       |

-

-It is guaranteed that IFQ_DEQUEUE_NOLOCK() under the
-  same lock as a previous IFQ_POLL_NOLOCK() returns the
-  same packet. Note that they need to be guarded by
-  IFQ_LOCK().
-

-

-
()

-
If the code uses IF_PREPEND(), you have to
-    eliminate it unless you can use a “driver managed” queue which
-    allows the use of IFQ_DRV_PREPEND() as a substitute.
-    A common usage of IF_PREPEND() is to cancel the
-    previous dequeue operation. You have to convert the logic into
-    poll-and-dequeue.

-

-
            ##old-style##                           ##new-style##
-                                       |
-                                       | IFQ_LOCK(&ifp->if_snd);
- IF_DEQUEUE(&ifp->if_snd, m);          | IFQ_POLL_NOLOCK(&ifp->if_snd, m);
- if (m != NULL) {                      | if (m != NULL) {
-                                       |
-     if (something_goes_wrong) {       |     if (something_goes_wrong) {
-         IF_PREPEND(&ifp->if_snd, m);  |         IFQ_UNLOCK(&ifp->if_snd);
-         return;                       |         return;
-     }                                 |     }
-                                       |
-                                       |     /* at this point, the driver
-                                       |      * is committed to send this
-                                       |      * packet.
-                                       |      */
-                                       |     IFQ_DEQUEUE_NOLOCK(&ifp->if_snd, m);
-                                       |     IFQ_UNLOCK(&ifp->if_snd);
-                                       |
-     /* kick the hardware */           |     /* kick the hardware */
- }                                     | }
-                                       |

-

-

-

-

-
Use IFQ_PURGE() to empty the queue. Note
-    that a non-work conserving queue cannot be emptied by a dequeue loop.

-

-
            ##old-style##                           ##new-style##
-                                       |
- while (ifp->if_snd.ifq_head != NULL) {|  IFQ_PURGE(&ifp->if_snd);
-     IF_DEQUEUE(&ifp->if_snd, m);      |
-     m_freem(m);                       |
- }                                     |
-                                       |

-

-

-

-

-
Convert
-    ()
-    macros to their equivalent IFQ_DRV_*() and employ
-    IFQ_DRV_IS_EMPTY() where appropriate.

-

-
            ##old-style##                           ##new-style##
-                                       |
- if (ifp->if_snd.ifq_head != NULL)     | if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
-                                       |

-

-Make sure that calls to IFQ_DRV_DEQUEUE(),
-  IFQ_DRV_PREPEND() and
-  IFQ_DRV_PURGE() are protected with a mutex of some
-  kind.
-

-

-

-
Use IFQ_SET_MAXLEN() to set
-    ifq_maxlen to len. Initialize
-    ifq_drv_maxlen with a sensible value if you plan to
-    use the IFQ_DRV_*() macros. Add
-    IFQ_SET_READY() to show this driver is converted to
-    the new style. (This is used to distinguish new-style drivers.)

-

-
            ##old-style##                           ##new-style##
-                                       |
- ifp->if_snd.ifq_maxlen = qsize;       | IFQ_SET_MAXLEN(&ifp->if_snd, qsize);
-                                       | ifp->if_snd.ifq_drv_maxlen = qsize;
-                                       | IFQ_SET_READY(&ifp->if_snd);
- if_attach(ifp);                       | if_attach(ifp);
-                                       |

-

-

-

-

-
The new macros for statistics:

-

-
            ##old-style##                           ##new-style##
-                                       |
- IF_DROP(&ifp->if_snd);                | IFQ_INC_DROPS(&ifp->if_snd);
-                                       |
- ifp->if_snd.ifq_len++;                | IFQ_INC_LEN(&ifp->if_snd);
-                                       |
- ifp->if_snd.ifq_len--;                | IFQ_DEC_LEN(&ifp->if_snd);
-                                       |

-

-

-

-

-

-
Queuing disciplines need to maintain ifq_len
-    (used by IFQ_IS_EMPTY()). Queuing disciplines also
-    need to guarantee that the same mbuf is returned if
-    IFQ_DEQUEUE() is called immediately after
-    ().

-

-

-

-
pf(4), pf.conf(5),
-    pfctl(8)

-

-

-

-
The ALTQ system first appeared in March
-    1997 and found home in the KAME project (https://www.kame.net). It was
-    imported to FreeBSD in 5.3 .

-

-

-
-  
-    
-    
-  
-
March 20, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/atomic.9 3.html b/static/freebsd/man9/atomic.9 3.html
deleted file mode 100644
index fc10c6fe..00000000
--- a/static/freebsd/man9/atomic.9 3.html	
+++ /dev/null
@@ -1,613 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATOMIC(9)Kernel Developer's ManualATOMIC(9)

-

-

-

-
atomic_add,
-    atomic_clear, atomic_cmpset,
-    atomic_fcmpset,
-    atomic_fetchadd,
-    atomic_interrupt_fence,
-    atomic_load,
-    atomic_readandclear,
-    atomic_set, atomic_subtract,
-    atomic_store,
-    atomic_thread_fence — atomic
-    operations

-

-

-

-
#include
-    <machine/atomic.h>

-
void
-  

-  atomic_add_[acq_|rel_]<type>(volatile
-    <type> *p,
-    <type> v);

-
void
-  

-  atomic_clear_[acq_|rel_]<type>(volatile
-    <type> *p,
-    <type> v);

-
int
-  

-  atomic_cmpset_[acq_|rel_]<type>(volatile
-    <type> *dst, <type> old,
-    <type> new);

-
int
-  

-  atomic_fcmpset_[acq_|rel_]<type>(volatile
-    <type> *dst, <type> *old,
-    <type> new);

-
<type>
-  

-  atomic_fetchadd_<type>(volatile
-    <type> *p,
-    <type> v);

-
void
-  

-  atomic_interrupt_fence(void);

-
<type>
-  

-  atomic_load_[acq_]<type>(const
-    volatile <type> *p);

-
<type>
-  

-  atomic_readandclear_<type>(volatile
-    <type> *p);

-
void
-  

-  atomic_set_[acq_|rel_]<type>(volatile
-    <type> *p,
-    <type> v);

-
void
-  

-  atomic_subtract_[acq_|rel_]<type>(volatile
-    <type> *p,
-    <type> v);

-
void
-  

-  atomic_store_[rel_]<type>(volatile
-    <type> *p,
-    <type> v);

-
<type>
-  

-  atomic_swap_<type>(volatile
-    <type> *p,
-    <type> v);

-
int
-  

-  atomic_testandclear_<type>(volatile
-    <type> *p, u_int
-    v);

-
int
-  

-  atomic_testandset_<type>(volatile
-    <type> *p, u_int
-    v);

-
void
-  

-  atomic_thread_fence_[acq|acq_rel|rel|seq_cst](void);

-

-

-

-
Atomic operations are commonly used to implement reference counts
-    and as building blocks for synchronization primitives, such as mutexes.

-
All of these operations are performed
-    
-    across multiple threads and in the presence of interrupts, meaning that they
-    are performed in an indivisible manner from the perspective of concurrently
-    running threads and interrupt handlers.

-
On all architectures supported by FreeBSD,
-    ordinary loads and stores of integers in cache-coherent memory are
-    inherently atomic if the integer is naturally aligned and its size does not
-    exceed the processor's word size. However, such loads and stores may be
-    elided from the program by the compiler, whereas atomic operations are
-    always performed.

-
When atomic operations are performed on cache-coherent memory, all
-    operations on the same location are totally ordered.

-
When an atomic load is performed on a location in
-    cache-coherent memory, it reads the entire value that was defined by the
-    last atomic store to each byte of the location. An atomic load will never
-    return a value out of thin air. When an atomic store is performed on a
-    location, no other thread or interrupt handler will observe a
-    , or
-    partial modification of the location.

-
Except as noted below, the semantics of these operations are
-    almost identical to the semantics of similarly named C11 atomic
-  operations.

-

-

-
Most atomic operations act upon a specific
-    type. That type is indicated in the function name. In
-    contrast to C11 atomic operations, FreeBSD's atomic
-    operations are performed on ordinary integer types. The available types
-  are:

-

-

-

-  

-  
unsigned integer

-  

-  
unsigned long integer

-  

-  
unsigned integer the size of a pointer

-  

-  
unsigned 32-bit integer

-  

-  
unsigned 64-bit integer

-

-

-
For example, the function to atomically add
-    two integers is called
-    ().

-
Certain architectures also provide operations for types smaller
-    than “int”.

-

-

-

-  

-  
unsigned character

-  

-  
unsigned short integer

-  

-  
unsigned 8-bit integer

-  

-  
unsigned 16-bit integer

-

-

-
These types must not be used in machine-independent code.

-

-

-

-
By default, a thread's accesses to different memory locations
-    might not be performed in
-    , that is, the order in which the accesses appear in the source
-    code. To optimize the program's execution, both the compiler and processor
-    might reorder the thread's accesses. However, both ensure that their
-    reordering of the accesses is not visible to the thread. Otherwise, the
-    traditional memory model that is expected by single-threaded programs would
-    be violated. Nonetheless, other threads in a multithreaded program, such as
-    the FreeBSD kernel, might observe the reordering.
-    Moreover, in some cases, such as the implementation of synchronization
-    between threads, arbitrary reordering might result in the incorrect
-    execution of the program. To constrain the reordering that both the compiler
-    and processor might perform on a thread's accesses, a programmer can use
-    atomic operations with acquire and
-    release semantics.

-
Atomic operations on memory have up to three
-    variants. The first, or
-     variant,
-    performs the operation without imposing any ordering constraints on accesses
-    to other memory locations. This variant is the default. The second variant
-    has acquire semantics, and the third variant has release semantics.

-
An atomic operation can only have
-    acquire semantics if it performs a load from memory. When
-    an atomic operation has acquire semantics, a load performed as part of the
-    operation must have completed before any subsequent load or store (by
-    program order) is performed. Conversely, acquire semantics do not require
-    that prior loads or stores have completed before a load from the atomic
-    operation is performed. To denote acquire semantics, the suffix
-    “_acq” is inserted into the function
-    name immediately prior to the
-    “_⟨type⟩”
-    suffix. For example, to subtract two integers ensuring that the load of the
-    value from memory is completed before any subsequent loads and stores are
-    performed, use
-    ().

-
An atomic operation can only have
-    release semantics if it performs a store to memory. When
-    an atomic operation has release semantics, all prior loads or stores (by
-    program order) must have completed before a store executed as part of the
-    operation that is performed. Conversely, release semantics do not require
-    that a store from the atomic operation must have completed before any
-    subsequent load or store is performed. To denote release semantics, the
-    suffix “_rel” is inserted into the
-    function name immediately prior to the
-    “_⟨type⟩”
-    suffix. For example, to add two long integers ensuring that all prior loads
-    and stores are completed before the store of the result is performed, use
-    ().

-
When a release operation by one thread
-     an acquire operation by another thread, usually meaning that
-    the acquire operation reads the value written by the release operation, then
-    the effects of all prior stores by the releasing thread must become visible
-    to subsequent loads by the acquiring thread. Moreover, the effects of all
-    stores (by other threads) that were visible to the releasing thread must
-    also become visible to the acquiring thread. These rules only apply to the
-    synchronizing threads. Other threads might observe these stores in a
-    different order.

-
In effect, atomic operations with acquire and release semantics
-    establish one-way barriers to reordering that enable the implementations of
-    synchronization primitives to express their ordering requirements without
-    also imposing unnecessary ordering. For example, for a critical section
-    guarded by a mutex, an acquire operation when the mutex is locked and a
-    release operation when the mutex is unlocked will prevent any loads or
-    stores from moving outside of the critical section. However, they will not
-    prevent the compiler or processor from moving loads or stores into the
-    critical section, which does not violate the semantics of a mutex.

-

-

-

-
The
-    ()
-    operations, specifically those without explicitly specified memory ordering,
-    are defined as relaxed. Consequently, a thread's accesses to memory
-    locations different from that of the atomic operation can be reordered in
-    relation to the atomic operation.

-
However, the implementation on the
-     and
-    
-    architectures provide sequentially consistent semantics. In particular, the
-    reordering mentioned above cannot occur.

-
On the
-    
-    architecture, the operation may include either acquire semantics on the
-    constituent load or release semantics on the constituent store. This means
-    that accesses to other locations in program order before the atomic, might
-    be observed as executed after the load that is the part of the atomic
-    operation (but not after the store from the operation due to release).
-    Similarly, accesses after the atomic might be observed as executed before
-    the store.

-

-

-

-
Alternatively, a programmer can use atomic thread fence operations
-    to constrain the reordering of accesses. In contrast to other atomic
-    operations, fences do not, themselves, access memory.

-
When a fence has acquire semantics,
-    all prior loads (by program order) must have completed before any subsequent
-    load or store is performed. Thus, an acquire fence is a two-way barrier for
-    load operations. To denote acquire semantics, the suffix
-    “_acq” is appended to the function
-    name, for example,
-    ().

-
When a fence has release semantics,
-    all prior loads or stores (by program order) must have completed before any
-    subsequent store operation is performed. Thus, a release fence is a two-way
-    barrier for store operations. To denote release semantics, the suffix
-    “_rel” is appended to the function
-    name, for example,
-    ().

-
Although
-    ()
-    implements both acquire and release semantics, it is not a full barrier. For
-    example, a store prior to the fence (in program order) may be completed
-    after a load subsequent to the fence. In contrast,
-    ()
-    implements a full barrier. Neither loads nor stores may cross this barrier
-    in either direction.

-
In C11, a release fence by one thread synchronizes with an acquire
-    fence by another thread when an atomic load that is prior to the acquire
-    fence (by program order) reads the value written by an atomic store that is
-    subsequent to the release fence. In contrast, in
-    FreeBSD, because of the atomicity of ordinary,
-    naturally aligned loads and stores, fences can also be synchronized by
-    ordinary loads and stores. This simplifies the implementation and use of
-    some synchronization primitives in FreeBSD.

-
Since neither a compiler nor a processor can foresee which
-    (atomic) load will read the value written by an (atomic) store, the ordering
-    constraints imposed by fences must be more restrictive than acquire loads
-    and release stores. Essentially, this is why fences are two-way
-  barriers.

-
Although fences impose more restrictive ordering than acquire
-    loads and release stores, by separating access from ordering, they can
-    sometimes facilitate more efficient implementations of synchronization
-    primitives. For example, they can be used to avoid executing a memory
-    barrier until a memory access shows that some condition is satisfied.

-

-

-

-
The
-    ()
-    function establishes ordering between its call location and any interrupt
-    handler executing on the same CPU. It is modeled after the similar C11
-    function
-    (),
-    and adapted for the kernel environment.

-

-

-

-
In multiprocessor systems, the atomicity of the atomic operations
-    on memory depends on support for cache coherence in the underlying
-    architecture. In general, cache coherence on the default memory type,
-    VM_MEMATTR_DEFAULT, is guaranteed by all
-    architectures that are supported by FreeBSD. For
-    example, cache coherence is guaranteed on write-back memory by the amd64 and
-    i386 architectures. However, on some architectures, cache coherence might
-    not be enabled on all memory types. To determine if cache coherence is
-    enabled for a non-default memory type, consult the architecture's
-    documentation.

-

-

-

-
This section describes the semantics of each operation using a C
-    like notation.

-

-  
(p,
-    v)

-  

-    

-    
*p += v;

-    

-  

-  
(p,
-    v)

-  

-    

-    
*p &= ~v;

-    

-  

-  
atomic_cmpset(dst,
-    old, new)

-  

-    

-    
if (*dst == old) {
-	*dst = new;
-	return (1);
-} else
-	return (0);

-    

-  

-

-
Some architectures do not implement the
-    ()
-    functions for the types “char”,
-    “short”,
-    “8”, and
-    “16”.

-

-  
atomic_fcmpset(dst,
-    *old, new)

-  

-

-
On architectures implementing
-    
-    operation in hardware, the functionality can be described as

-

-
if (*dst == *old) {
-	*dst = new;
-	return (1);
-} else {
-	*old = *dst;
-	return (0);
-}

-

-On architectures which provide
-   primitive, the write to *dst might
-  also fail for several reasons, most important of which is a parallel write to
-  *dst cache line by other CPU. In this case
-  ()
-  function also returns false, despite
-
*old == *dst

-.
-
Some architectures do not implement the
-    ()
-    functions for the types “char”,
-    “short”,
-    “8”, and
-    “16”.

-

-  
atomic_fetchadd(p,
-    v)

-  

-    

-    
tmp = *p;
-*p += v;
-return (tmp);

-    

-  

-

-
The
-    ()
-    functions are only implemented for the types
-    “int”,
-    “long” and
-    “32” and do not have any variants with
-    memory barriers at this time.

-

-  
(p)

-  

-    

-    
return (*p);

-    

-  

-  
atomic_readandclear(p)

-  

-    

-    
tmp = *p;
-*p = 0;
-return (tmp);

-    

-  

-

-
The
-    ()
-    functions are not implemented for the types
-    “char”,
-    “short”,
-    “ptr”,
-    “8”, and
-    “16” and do not have any variants with
-    memory barriers at this time.

-

-  
(p,
-    v)

-  

-    

-    
*p |= v;

-    

-  

-  
(p,
-    v)

-  

-    

-    
*p -= v;

-    

-  

-  
(p,
-    v)

-  

-    

-    
*p = v;

-    

-  

-  
atomic_swap(p,
-    v)

-  

-    

-    
tmp = *p;
-*p = v;
-return (tmp);

-    

-  

-

-
The
-    ()
-    functions are not implemented for the types
-    “char”,
-    “short”,
-    “ptr”,
-    “8”, and
-    “16” and do not have any variants with
-    memory barriers at this time.

-

-  
(p,
-    v)

-  

-    

-    
bit = 1 << (v % (sizeof(*p) * NBBY));
-tmp = (*p & bit) != 0;
-*p &= ~bit;
-return (tmp);

-    

-  

-

-

-  
atomic_testandset(p,
-    v)

-  

-    

-    
bit = 1 << (v % (sizeof(*p) * NBBY));
-tmp = (*p & bit) != 0;
-*p |= bit;
-return (tmp);

-    

-  

-

-
The
-    ()
-    and
-    ()
-    functions are only implemented for the types
-    “int”,
-    “long”, “ptr”,
-    “32”, and
-    “64” and generally do not have any
-    variants with memory barriers at this time except for
-    ().

-
The type “64” is currently
-    not implemented for some of the atomic operations on the arm, i386, and
-    powerpc architectures.

-

-

-

-

-
The atomic_cmpset() function returns the
-    result of the compare operation. The
-    atomic_fcmpset() function returns
-    true if the operation succeeded. Otherwise it
-    returns false and sets *old to
-    the found value. The atomic_fetchadd(),
-    atomic_load(),
-    atomic_readandclear(), and
-    atomic_swap() functions return the value at the
-    specified address. The atomic_testandset() and
-    atomic_testandclear() function returns the result of
-    the test operation.

-

-

-

-
This example uses the
-    atomic_cmpset_acq_ptr() and
-    atomic_set_ptr() functions to obtain a sleep mutex
-    and handle recursion. Since the mtx_lock member of a
-    struct mtx is a pointer, the
-    “ptr” type is used.

-

-
/* Try to obtain mtx_lock once. */
-#define _obtain_lock(mp, tid)						\
-	atomic_cmpset_acq_ptr(&(mp)->mtx_lock, MTX_UNOWNED, (tid))
-
-/* Get a sleep lock, deal with recursion inline. */
-#define _get_sleep_lock(mp, tid, opts, file, line) do {			\
-	uintptr_t _tid = (uintptr_t)(tid);				\
-									\
-	if (!_obtain_lock(mp, tid)) {					\
-		if (((mp)->mtx_lock & MTX_FLAGMASK) != _tid)		\
-			_mtx_lock_sleep((mp), _tid, (opts), (file), (line));\
-		else {							\
-			atomic_set_ptr(&(mp)->mtx_lock, MTX_RECURSE);	\
-			(mp)->mtx_recurse++;				\
-		}							\
-	}								\
-} while (0)

-

-

-

-

-
The atomic_add(),
-    atomic_clear(),
-    atomic_set(), and
-    atomic_subtract() operations were introduced in
-    FreeBSD 3.0. Initially, these operations were
-    defined on the types “char”,
-    “short”,
-    “int”, and
-    “long”.

-
The atomic_cmpset(),
-    atomic_load_acq(),
-    atomic_readandclear(), and
-    atomic_store_rel() operations were added in
-    FreeBSD 5.0. Simultaneously, the acquire and release
-    variants were introduced, and support was added for operation on the types
-    “8”,
-    “16”,
-    “32”,
-    “64”, and
-    “ptr”.

-
The atomic_fetchadd() operation was added
-    in FreeBSD 6.0.

-
The atomic_swap() and
-    atomic_testandset() operations were added in
-    FreeBSD 10.0.

-
The atomic_testandclear() and
-    atomic_thread_fence() operations were added in
-    FreeBSD 11.0.

-
The relaxed variants of atomic_load() and
-    atomic_store() were added in
-    FreeBSD 12.0.

-
The atomic_interrupt_fence() operation was
-    added in FreeBSD 13.0.

-

-

-
-  
-    
-    
-  
-
December 16, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/backlight.9 3.html b/static/freebsd/man9/backlight.9 3.html
deleted file mode 100644
index 59865e09..00000000
--- a/static/freebsd/man9/backlight.9 3.html	
+++ /dev/null
@@ -1,97 +0,0 @@
-
-  
-    
-    
-    
-  
-
BACKLIGHT(9)Kernel Developer's ManualBACKLIGHT(9)

-

-

-

-
backlight,
-    backlight_register,
-    backlight_destroy,
-    BACKLIGHT_GET_STATUS,
-    BACKLIGHT_SET_STATUS —
-    BACKLIGHT methods

-

-

-

-
device backlight
-  

-  #include <backlight_if.h>
-  

-  #include
-  <sys/sys/backlight.h>

-
int
-  

-  BACKLIGHT_GET_STATUS(device_t
-    bus, struct
-    backlight_props *props);

-
int
-  

-  BACKLIGHT_SET_STATUS(device_t
-    bus, struct
-    backlight_props *props);

-
struct cdev *
-  

-  backlight_register(const
-    char *name, device_t
-    dev);

-
int
-  

-  backlight_destroy(struct
-    cdev *cdev);

-

-

-

-
The backlight driver provides a generic way for handling a panel
-    backlight.

-
Drivers for backlight system register
-    themselves globally using the
-    ()
-    function. They must define two methods,
-    ()
-    which is used to query the current brightness level and
-    ()
-    which is used to update it.

-

-

-

-

-  
BACKLIGHT_GET_STATUS(device_t
-    bus, struct backlight_props *props)

-  
Driver fills the current brightless level and the optional supported
-      levels.

-  
BACKLIGHT_SET_STATUS(device_t
-    bus, struct backlight_props *props)

-  
Driver update the backlight level based on the brightness member of the
-      props struct.

-

-

-

-

-

-  
/dev/backlight/*

-  
 

-

-

-

-

-
backlight(8)

-

-

-

-
The backlight interface first appear in
-    FreeBSD 13.0. The backlight
-    driver and manual page was written by Emmanuel Vadot
-    <manu@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 2, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/bhnd.9 3.html b/static/freebsd/man9/bhnd.9 3.html
deleted file mode 100644
index cb26480d..00000000
--- a/static/freebsd/man9/bhnd.9 3.html	
+++ /dev/null
@@ -1,2322 +0,0 @@
-
-  
-    
-    
-    
-  
-
BHND(9)Kernel Developer's ManualBHND(9)

-

-

-

-
bhnd — BHND driver
-    programming interface

-

-

-

-
#include
-    <dev/bhnd/bhnd.h>

-

-
Bus Resource Functions

-
int
-  

-  bhnd_activate_resource(device_t
-    dev, int type, int rid,
-    struct bhnd_resource *r);

-
struct bhnd_resource *
-  

-  bhnd_alloc_resource(device_t
-    dev, int type, int *rid,
-    rman_res_t start, rman_res_t
-    end, rman_res_t count, u_int
-    flags);

-
struct bhnd_resource *
-  

-  bhnd_alloc_resource_any(device_t
-    dev, int type, int *rid,
-    u_int flags);

-
int
-  

-  bhnd_alloc_resources(device_t
-    dev, struct resource_spec *rs,
-    struct bhnd_resource **res);

-
int
-  

-  bhnd_deactivate_resource(device_t
-    dev, int type, int rid,
-    struct bhnd_resource *r);

-
int
-  

-  bhnd_release_resource(device_t
-    dev, int type, int rid,
-    struct bhnd_resource *r);

-
void
-  

-  bhnd_release_resources(device_t
-    dev, const struct resource_spec *rs,
-    struct bhnd_resource **res);

-

-

-
Bus Space Functions

-
void
-  

-  bhnd_bus_barrier(struct bhnd_resource
-    *r, bus_size_t offset,
-    bus_size_t length, int
-  flags);

-
uint8_t
-  

-  bhnd_bus_read_1(struct
-    bhnd_resource *r,
-    bus_size_t offset);

-
uint16_t
-  

-  bhnd_bus_read_2(struct
-    bhnd_resource *r,
-    bus_size_t offset);

-
uint32_t
-  

-  bhnd_bus_read_4(struct
-    bhnd_resource *r,
-    bus_size_t offset);

-
void
-  

-  bhnd_bus_read_multi_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_multi_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_multi_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_multi_stream_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_multi_stream_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_multi_stream_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_region_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_region_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_region_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_region_stream_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_region_stream_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_region_stream_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_read_stream_1(struct
-    bhnd_resource *r,
-    bus_size_t offset);

-
void
-  

-  bhnd_bus_read_stream_2(struct
-    bhnd_resource *r,
-    bus_size_t offset);

-
uint32_t
-  

-  bhnd_bus_read_stream_4(struct
-    bhnd_resource *r,
-    bus_size_t offset);

-
void
-  

-  bhnd_bus_set_multi_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t value, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_set_multi_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t value, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_set_multi_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t value, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_set_region_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t value, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_set_region_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t value, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_set_region_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t value, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_1(struct
-    bhnd_resource *r, uint8_t
-    value);

-
void
-  

-  bhnd_bus_write_2(struct
-    bhnd_resource *r,
-    uint16_t value);

-
void
-  

-  bhnd_bus_write_4(struct
-    bhnd_resource *r,
-    uint32_t value);

-
void
-  

-  bhnd_bus_write_multi_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_multi_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_multi_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_multi_stream_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_multi_stream_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_multi_stream_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_region_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_region_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_region_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_region_stream_1(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint8_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_region_stream_2(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint16_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_region_stream_4(struct
-    bhnd_resource *r, bus_size_t offset,
-    uint32_t *datap, bus_size_t
-    count);

-
void
-  

-  bhnd_bus_write_stream_1(struct
-    bhnd_resource *r, uint8_t
-    value);

-
void
-  

-  bhnd_bus_write_stream_2(struct
-    bhnd_resource *r,
-    uint16_t value);

-
void
-  

-  bhnd_bus_write_stream_4(struct
-    bhnd_resource *r,
-    uint32_t value);

-

-

-
Device Configuration Functions

-
int
-  

-  bhnd_read_ioctl(device_t
-    dev, uint16_t
-    *ioctl);

-
int
-  

-  bhnd_write_ioctl(device_t
-    dev, uint16_t
-    value, uint16_t
-    mask);

-
int
-  

-  bhnd_read_iost(device_t
-    dev, uint16_t
-    *iost);

-
uint32_t
-  

-  bhnd_read_config(device_t dev,
-    bus_size_t offset, void *value,
-    u_int width);

-
int
-  

-  bhnd_write_config(device_t dev,
-    bus_size_t offset, const void
-    *value, u_int width);

-
int
-  

-  bhnd_reset_hw(device_t
-    dev, uint16_t
-    ioctl, uint16_t
-    reset_ioctl);

-
int
-  

-  bhnd_suspend_hw(device_t
-    dev, uint16_t
-    ioctl);

-
bool
-  

-  bhnd_is_hw_suspended(device_t
-    dev);

-

-

-
Device Information Functions

-
bhnd_attach_type
-  

-  bhnd_get_attach_type(device_t
-    dev);

-
const struct bhnd_chipid *
-  

-  bhnd_get_chipid(device_t
-  dev);

-
bhnd_devclass_t
-  

-  bhnd_get_class(device_t
-  dev);

-
u_int
-  

-  bhnd_get_core_index(device_t
-    dev);

-
struct bhnd_core_info
-  

-  bhnd_get_core_info(device_t
-    dev);

-
int
-  

-  bhnd_get_core_unit(device_t
-    dev);

-
uint16_t
-  

-  bhnd_get_device(device_t
-  dev);

-
const char *
-  

-  bhnd_get_device_name(device_t
-    dev);

-
uint8_t
-  

-  bhnd_get_hwrev(device_t
-  dev);

-
uint16_t
-  

-  bhnd_get_vendor(device_t
-  dev);

-
const char *
-  

-  bhnd_get_vendor_name(device_t
-    dev);

-
int
-  

-  bhnd_read_board_info(device_t
-    dev, struct bhnd_board_info *info);

-

-

-
Device Matching Functions

-
bool
-  

-  bhnd_board_matches(const struct
-    bhnd_board_info *board, const struct bhnd_board_match
-    *desc);

-
device_t
-  

-  bhnd_bus_match_child(device_t
-    bus, const struct bhnd_core_match *desc);

-
bool
-  

-  bhnd_chip_matches(const struct
-    bhnd_chipid *chip, const struct bhnd_chip_match
-    *desc);

-
struct bhnd_core_match
-  

-  bhnd_core_get_match_desc(const struct
-    bhnd_core_info *core);

-
bool
-  

-  bhnd_core_matches(const struct
-    bhnd_core_info *core, const struct bhnd_core_match
-    *desc);

-
bool
-  

-  bhnd_cores_equal(const struct
-    bhnd_core_info *lhs, const struct bhnd_core_info
-    *rhs);

-
bool
-  

-  bhnd_hwrev_matches(uint16_t
-    hwrev, const struct bhnd_hwrev_match *desc);

-
const struct bhnd_core_info *
-  

-  bhnd_match_core(const struct
-    bhnd_core_info *cores, u_int num_cores,
-    const struct bhnd_core_match *desc);

-

-

-
Device Table Functions

-
const struct bhnd_device *
-  

-  bhnd_device_lookup(device_t dev,
-    const struct bhnd_device *table,
-    size_t entry_size);

-
bool
-  

-  bhnd_device_matches(device_t
-    dev, const struct bhnd_device_match *desc);

-
uint32_t
-  

-  bhnd_device_quirks(device_t dev,
-    const struct bhnd_device *table,
-    size_t entry_size);

-
BHND_BOARD_QUIRK(board,
-    flags);

-
BHND_CHIP_QUIRK(chip,
-    hwrev, flags);

-
BHND_CORE_QUIRK(hwrev,
-    flags);

-
BHND_DEVICE(vendor,
-    device, desc,
-    quirks, ...);

-
BHND_DEVICE_IS_END(struct
-    bhnd_device *d);

-
BHND_DEVICE_QUIRK_IS_END(struct
-    bhnd_device_quirk *q);

-
BHND_PKG_QUIRK(chip,
-    pkg, flags);

-

-
struct bhnd_device_quirk {
-	struct bhnd_device_match	desc;
-	uint32_t			quirks;
-};

-

-

-
struct bhnd_device {
-    const struct bhnd_device_match	 core;
-    const char				*desc;
-    const struct bhnd_device_quirk	*quirks_table;
-    uint32_t				 device_flags;
-};

-

-

-
enum {
-	BHND_DF_ANY	= 0,
-	BHND_DF_HOSTB	= (1 << 0),
-	BHND_DF_SOC	= (1 << 1),
-	BHND_DF_ADAPTER	= (1 << 2)
-};

-

-

-
#define BHND_DEVICE_END { { BHND_MATCH_ANY }, NULL, NULL, 0 }

-

-

-
#define BHND_DEVICE_QUIRK_END { { BHND_MATCH_ANY }, 0 }

-

-

-

-
DMA Address Translation Functions

-
int
-  

-  bhnd_get_dma_translation(device_t
-    dev, u_int width, uint32_t
-    flags, bus_dma_tag_t *dmat,
-    struct bhnd_dma_translation *translation);

-

-
struct bhnd_dma_translation {
-	bhnd_addr_t	base_addr;
-	bhnd_addr_t	addr_mask;
-	bhnd_addr_t	addrext_mask;
-	uint32_t	flags;
-};

-

-

-
typedef enum {
-	BHND_DMA_ADDR_30BIT	= 30,
-	BHND_DMA_ADDR_32BIT	= 32,
-	BHND_DMA_ADDR_64BIT	= 64
-} bhnd_dma_addrwidth;

-

-

-
enum bhnd_dma_translation_flags {
-	BHND_DMA_TRANSLATION_PHYSMAP		= (1<<0),
-	BHND_DMA_TRANSLATION_BYTESWAPPED	= (1<<1)
-};

-

-

-

-
Interrupt Functions

-
u_int
-  

-  bhnd_get_intr_count(device_t
-    dev);

-
int
-  

-  bhnd_get_intr_ivec(device_t dev,
-    u_int intr, u_int *ivec);

-
int
-  

-  bhnd_map_intr(device_t dev,
-    u_int intr, rman_res_t
-  *irq);

-
void
-  

-  bhnd_unmap_intr(device_t dev,
-    rman_res_t irq);

-

-

-
NVRAM Functions

-
int
-  

-  bhnd_nvram_getvar(device_t dev,
-    const char *name, void *buf,
-    size_t *len, bhnd_nvram_type
-    type);

-
int
-  

-  bhnd_nvram_getvar_array(device_t
-    dev, const char *name, void
-    *buf, size_t size,
-    bhnd_nvram_type type);

-
int
-  

-  bhnd_nvram_getvar_int(device_t
-    dev, const char *name, void
-    *value, int width);

-
int
-  

-  bhnd_nvram_getvar_int8(device_t
-    dev, const char
-    *name, int8_t
-    *value);

-
int
-  

-  bhnd_nvram_getvar_int16(device_t
-    dev, const char
-    *name, int16_t
-    *value);

-
int
-  

-  bhnd_nvram_getvar_int32(device_t
-    dev, const char
-    *name, int32_t
-    *value);

-
int
-  

-  bhnd_nvram_getvar_uint(device_t
-    dev, const char *name, void
-    *value, int width);

-
int
-  

-  bhnd_nvram_getvar_uint8(device_t
-    dev, const char *name, uint8_t
-    *value);

-
int
-  

-  bhnd_nvram_getvar_uint16(device_t
-    dev, const char *name, uint16_t
-    *value);

-
int
-  

-  bhnd_nvram_getvar_uint32(device_t
-    dev, const char *name, uint32_t
-    *value);

-
int
-  

-  bhnd_nvram_getvar_str(device_t
-    dev, const char *name, char
-    *buf, size_t len, size_t
-    *rlen);

-
const char *
-  

-  bhnd_nvram_string_array_next(const
-    char *inp, size_t ilen, const
-    char *prev, size_t *olen);

-

-
typedef enum {
-	BHND_NVRAM_TYPE_UINT8		= 0,
-	BHND_NVRAM_TYPE_UINT16		= 1,
-	BHND_NVRAM_TYPE_UINT32		= 2,
-	BHND_NVRAM_TYPE_UINT64		= 3,
-	BHND_NVRAM_TYPE_INT8		= 4,
-	BHND_NVRAM_TYPE_INT16		= 5,
-	BHND_NVRAM_TYPE_INT32		= 6,
-	BHND_NVRAM_TYPE_INT64		= 7,
-	BHND_NVRAM_TYPE_CHAR		= 8,
-	BHND_NVRAM_TYPE_STRING		= 9,
-	BHND_NVRAM_TYPE_BOOL		= 10,
-	BHND_NVRAM_TYPE_NULL		= 11,
-	BHND_NVRAM_TYPE_DATA		= 12
-	BHND_NVRAM_TYPE_UINT8_ARRAY	= 16,
-	BHND_NVRAM_TYPE_UINT16_ARRAY	= 17,
-	BHND_NVRAM_TYPE_UINT32_ARRAY	= 18,
-	BHND_NVRAM_TYPE_UINT64_ARRAY	= 19,
-	BHND_NVRAM_TYPE_INT8_ARRAY	= 20,
-	BHND_NVRAM_TYPE_INT16_ARRAY	= 21,
-	BHND_NVRAM_TYPE_INT32_ARRAY	= 22,
-	BHND_NVRAM_TYPE_INT64_ARRAY	= 23,
-	BHND_NVRAM_TYPE_CHAR_ARRAY	= 24,
-	BHND_NVRAM_TYPE_STRING_ARRAY	= 25,
-	BHND_NVRAM_TYPE_BOOL_ARRAY	= 26
-} bhnd_nvram_type;

-

-

-

-
Port/Region Functions

-
int
-  

-  bhnd_decode_port_rid(device_t
-    dev, int type, int rid,
-    bhnd_port_type *port_type, u_int
-    *port, u_int *region);

-
u_int
-  

-  bhnd_get_port_count(device_t
-    dev, bhnd_port_type type);

-
int
-  

-  bhnd_get_port_rid(device_t dev,
-    bhnd_port_type type, u_int port,
-    u_int region);

-
int
-  

-  bhnd_get_region_addr(device_t
-    dev, bhnd_port_type port_type,
-    u_int port, u_int region,
-    bhnd_addr_t *region_addr, bhnd_size_t
-    *region_size);

-
u_int
-  

-  bhnd_get_region_count(device_t
-    dev, bhnd_port_type type, u_int
-    port);

-
bool
-  

-  bhnd_is_region_valid(device_t
-    dev, bhnd_port_type type, u_int
-    port, u_int region);

-

-
typedef enum {
-	BHND_PORT_DEVICE	= 0,
-	BHND_PORT_BRIDGE	= 1,
-	BHND_PORT_AGENT		= 2
-} bhnd_port_type;

-

-

-

-
Power Management Functions

-
int
-  

-  bhnd_alloc_pmu(device_t
-  dev);

-
int
-  

-  bhnd_release_pmu(device_t
-  dev);

-
int
-  

-  bhnd_enable_clocks(device_t dev,
-    uint32_t clocks);

-
int
-  

-  bhnd_request_clock(device_t dev,
-    bhnd_clock clock);

-
int
-  

-  bhnd_get_clock_freq(device_t
-    dev, bhnd_clock clock, u_int
-    *freq);

-
int
-  

-  bhnd_get_clock_latency(device_t
-    dev, bhnd_clock clock, u_int
-    *latency);

-
int
-  

-  bhnd_request_ext_rsrc(device_t
-    dev, u_int rsrc);

-
int
-  

-  bhnd_release_ext_rsrc(device_t
-    dev, u_int rsrc);

-

-
typedef enum {
-	BHND_CLOCK_DYN	= (1 << 0),
-	BHND_CLOCK_ILP	= (1 << 1),
-	BHND_CLOCK_ALP	= (1 << 2),
-	BHND_CLOCK_HT	= (1 << 3)
-} bhnd_clock;

-

-

-

-
Service Provider Functions

-
int
-  

-  bhnd_register_provider(device_t
-    dev, bhnd_service_t service);

-
int
-  

-  bhnd_deregister_provider(device_t
-    dev, bhnd_service_t service);

-
device_t
-  

-  bhnd_retain_provider(device_t
-    dev, bhnd_service_t service);

-
void
-  

-  bhnd_release_provider(device_t
-    dev, device_t provider,
-    bhnd_service_t service);

-

-
typedef enum {
-	BHND_SERVICE_CHIPC,
-	BHND_SERVICE_PWRCTL,
-	BHND_SERVICE_PMU,
-	BHND_SERVICE_NVRAM,
-	BHND_SERVICE_GPIO,
-	BHND_SERVICE_ANY	= 1000
-} bhnd_service_t;

-

-

-

-
Utility Functions

-
bhnd_erom_class_t *
-  

-  bhnd_driver_get_erom_class(driver_t
-    *driver);

-
bhnd_devclass_t
-  

-  bhnd_find_core_class(uint16_t
-    vendor, uint16_t device);

-
const char *
-  

-  bhnd_find_core_name(uint16_t
-    vendor, uint16_t device);

-
bhnd_devclass_t
-  

-  bhnd_core_class(const struct
-    bhnd_core_info *ci);

-
const char *
-  

-  bhnd_core_name(const struct
-    bhnd_core_info *ci);

-
int
-  

-  bhnd_format_chip_id(char
-    *buffer, size_t size, uint16_t
-    chip_id);

-
void
-  

-  bhnd_set_custom_core_desc(device_t
-    dev, const char *dev_name);

-
void
-  

-  bhnd_set_default_core_desc(device_t
-    dev);

-
const char *
-  

-  bhnd_vendor_name(uint16_t
-    vendor);

-

-
#define	BHND_CHIPID_MAX_NAMELEN	32

-

-

-

-

-

-
bhnd provides a unified bus and driver
-    programming interface for the on-chip interconnects and IP cores found in
-    Broadcom Home Networking Division (BHND) devices.

-
The BHND device family consists of MIPS/ARM SoCs (System On a
-    Chip) and host-connected chipsets based on a common library of Broadcom IP
-    cores, connected via one of two on-chip backplane (hardware bus)
-    architectures.

-
Hardware designed prior to 2009 used Broadcom's
-    “SSB” backplane architecture, based on Sonics Silicon's
-    interconnect IP. Each core on the Sonics backplane vends a 4 KiB register
-    block, containing both device-specific CSRs, and SSB-specific per-core
-    device management (enable/reset/etc) registers.

-
Subsequent hardware is based on Broadcom's “BCMA”
-    backplane, based on ARM's AMBA IP. The IP cores used in earlier SSB-based
-    devices were adapted for compatibility with the new backplane, with
-    additional “wrapper” cores providing per-core device
-    management functions in place of the SSB per-core management registers.

-
When BHND hardware is used as a host-connected peripheral (e.g.,
-    in a PCI Wi-Fi card), the on-chip peripheral controller core is configured
-    to operate as an endpoint device, bridging access to the SoC hardware:

-
    
-  
  • Host access to SoC address space is provided via a set of register windows
-      (e.g., a set of configurable windows into SoC address space mapped via PCI
-      BARs)
    • 
-  
  • DMA is supported by the bridge core's sparse mapping of host address space
-      into the backplane address space. These address regions may be used as a
-      target for the on-chip DMA engine.
    • 
-  
  • Any backplane interrupt vectors routed to the bridge core may be mapped by
-      the bridge to host interrupts (e.g., PCI INTx/MSI/MSI-X).
    • 
-

-
The bhnd driver programming interface
-    — and bhndb(4) host bridge drivers — support
-    the implementation of common drivers for Broadcom IP cores, whether attached
-    via a BHND host bridge, or via the native SoC backplane.

-

-
Bus Resource Functions

-
The bhnd_resource functions are wrappers for the standard
-    struct resource bus APIs, providing support for
-    SYS_RES_MEMORY resources that, on
-    bhndb(4) bridged chipsets, may require on-demand remapping
-    of address windows prior to accessing bus memory.

-
These functions are primarily used in the implementation of BHND
-    platform device drivers that, on host-connected peripherals, must share a
-    small set of register windows during initial setup and teardown.

-
BHND peripherals are designed to not require register window
-    remapping during normal operation, and most drivers may safely use the
-    standard struct resource APIs directly.

-
The
-    ()
-    function activates a previously allocated resource.

-
The arguments are as follows:

-

-  
dev

-  
The device holding ownership of the allocated resource.

-  
type

-  
The type of the resource.

-  
rid

-  
The bus-specific handle that identifies the resource being activated.

-  
r

-  
A pointer to the resource returned by
-      ().

-

-
The
-    ()
-    function allocates a resource from a device's parent
-    bhnd(4) bus.

-
The arguments are as follows:

-

-  
dev

-  
The device requesting resource ownership.

-  
type

-  
The type of resource to allocate. This may be any type supported by the
-      standard bus_alloc_resource(9) function.

-  
rid

-  
The bus-specific handle identifying the resource being allocated.

-  
start

-  
The start address of the resource.

-  
end

-  
The end address of the resource.

-  
count

-  
The size of the resource.

-  
flags

-  
The flags for the resource to be allocated. These may be any values
-      supported by the standard bus_alloc_resource(9)
-      function.

-

-
To request that the bus supply the resource's default
-    start, end, and
-    count values, pass start and
-    end values of 0ul and ~0ul respectively, and a
-    count of 1.

-
The
-    ()
-    function is a convenience wrapper for
-    bhnd_alloc_resource(), using the resource's default
-    start, end, and
-    count values.

-
The arguments are as follows:

-

-  
dev

-  
The device requesting resource ownership.

-  
type

-  
The type of resource to allocate. This may be any type supported by the
-      standard bus_alloc_resource(9) function.

-  
rid

-  
The bus-specific handle identifying the resource being allocated.

-  
flags

-  
The flags for the resource to be allocated. These may be any values
-      supported by the standard bus_alloc_resource(9)
-      function.

-

-
The
-    ()
-    function allocates resources defined in resource specification from a
-    device's parent bhnd(4) bus.

-
The arguments are as follows:

-

-  
dev

-  
The device requesting ownership of the resources.

-  
rs

-  
A standard bus resource specification. If all requested resources, are
-      successfully allocated, this will be updated with the allocated resource
-      identifiers.

-  
res

-  
If all requested resources are successfully allocated, this will be
-      populated with the allocated struct bhnd_resource
-      instances.

-

-
The
-    ()
-    function deactivates a resource previously activated by.
-    bhnd_activate_resource(). The arguments are as
-    follows:

-

-  
dev

-  
The device holding ownership of the activated resource.

-  
type

-  
The type of the resource.

-  
rid

-  
The bus-specific handle identifying the resource.

-  
r

-  
A pointer to the resource returned by bhnd_alloc_resource.

-

-
The
-    ()
-    function frees a resource previously returned by
-    bhnd_alloc_resource(). The arguments are as
-  follows:

-

-  
dev

-  
The device holding ownership of the resource.

-  
type

-  
The type of the resource.

-  
rid

-  
The bus-specific handle identifying the resource.

-  
r

-  
A pointer to the resource returned by bhnd_alloc_resource.

-

-
The
-    ()
-    function frees resources previously returned by
-    bhnd_alloc_resources(). The arguments are as
-    follows:

-

-  
dev

-  
The device that owns the resources.

-  
rs

-  
A standard bus resource specification previously initialized by
-      bhnd_alloc_resources().

-  
res

-  
The resources to be released.

-

-
The bhnd_resource structure contains the
-    following fields:

-

-  
res

-  
A pointer to the bus struct resource.

-  
direct

-  
If true, the resource requires bus window remapping before it is MMIO
-      accessible.

-

-

-

-
Bus Space Functions

-
The bhnd_bus_space functions wrap their equivalent
-    bus_space(9) counterparts, and provide support for
-    accessing bus memory via struct bhnd_resource.

-

-

-  
()

-  

-  
()

-  

-  
()

-  

-  
()

-  

-  
()

-  

-  
()

-  

-  
()

-  

-  
()

-  

-

-
Drivers that do not rely on struct
-    bhnd_resource should use the standard struct
-    resource and bus_space(9) APIs directly.

-

-

-
Device Configuration Functions

-
The
-    ()
-    function is used to read the I/O control register value of device
-    dev, returning the current value in
-    ioctl.

-
The
-    ()
-    function is used to modify the I/O control register of
-    dev. The new value of the register is computed by
-    updating any bits set in mask to
-    value. The following I/O control flags are
-  supported:

-

-

-  

-  
Initiate a built-in self-test (BIST). Must be cleared after BIST results
-      are read via the IOST (I/O Status) register.

-  

-  
Enable posting of power management events by the core.

-  

-  
Force disable of clock gating, resulting in all clocks being distributed
-      within the core. Should be set when asserting/deasserting reset to ensure
-      the reset signal fully propagates to the entire core.

-  

-  
If cleared, the core clock will be disabled. Should be set during normal
-      operation, and cleared when the core is held in reset.

-  

-  
The mask of IOCTL bits reserved for additional core-specific I/O control
-      flags.

-

-

-
The
-    ()
-    function is used to read the I/O status register of device
-    dev, returning the current value in
-    iost. The following I/O status flags are
-  supported:

-

-

-  

-  
Set upon BIST completion. Will be cleared when the
-      BHND_IOCTL_BIST flag of the I/O control register
-      is cleared using bhnd_write_ioctl().

-  

-  
Set upon detection of a BIST error; the value is unspecified if BIST has
-      not completed and BHND_IOST_BIST_DONE is not also
-      set.

-  

-  
Set if the core has required that clocked be ungated, or cleared
-      otherwise. The value is undefined if a core does not support clock
-    gating.

-  

-  
Set if this core supports 64-bit DMA.

-  

-  
The mask of IOST bits reserved for additional core-specific I/O status
-      flags.

-

-

-
The
-    ()
-    function is used to read a data item of width bytes at
-    offset from the backplane-specific agent/config space
-    of the device dev.

-
The
-    ()
-    function is used to write a data item of width bytes
-    with value at offset from the
-    backplane-specific agent/config space of the device
-    dev. The requested width must be
-    one of 1, 2, or 4 bytes.

-
The agent/config space accessible via
-    ()
-    and bhnd_write_config() is backplane-specific, and
-    these functions should only be used for functionality that is not available
-    via another bhnd function.

-
The
-    ()
-    function transitions the device dev to a low power
-    “RESET” state, writing ioctl to the I/O
-    control flags of dev. The hardware may be brought out
-    of this state using bhnd_reset_hw().

-
The
-    ()
-    function first transitions the device dev to a low
-    power RESET state, writing ioctl_reset to the I/O
-    control flags of dev, and then brings the device out
-    of RESET, writing ioctl to the device's I/O control
-    flags.

-
The
-    ()
-    function returns true if the device
-    dev is currently held in a RESET state, or is
-    otherwise not clocked. Otherwise, it returns
-  false.

-
Any outstanding per-device PMU requests
-    made using
-    (),
-    bhnd_request_clock(), or
-    bhnd_request_ext_rsrc() will be released
-    automatically upon placing a device into a RESET state.

-

-

-
Device Information Functions

-
The
-    ()
-    function returns the attachment type of the parent bhnd(4)
-    bus of device dev.

-
The following attachment types are supported:

-

-  

-  
The bus is resident on a bridged adapter, such as a PCI Wi-Fi device.

-  

-  
The bus is resident on the native host, such as the primary or secondary
-      bus of an embedded SoC.

-

-
The
-    ()
-    function returns chip information from the parent bhnd(4)
-    bus of device dev. The returned
-    bhnd_chipid struct contains the following fields:

-

-

-  
chip_id

-  
The chip identifier.

-  
chip_rev

-  
The chip's hardware revision.

-  
chip_pkg

-  
The chip's semiconductor package identifier.
-    
Several different physical semiconductor package variants may
-        exist for a given chip, each of which may require driver workarounds for
-        hardware errata, unpopulated components, etc.

-  

-  
chip_type

-  
The interconnect architecture used by this chip.

-  
chip_caps

-  
The bhnd capability flags supported by this
-    chip.

-  
enum_addr

-  
The backplane enumeration address. On SSB devices, this will be the base
-      address of the first SSB core. On BCMA devices, this will be the address
-      of the enumeration ROM (EROM) core.

-  
ncores

-  
The number of cores on the chip backplane, or 0 if unknown.

-

-

-
The following constants are defined for known
-    chip_type values:

-

-

-  

-  
SSB interconnect.

-  

-  
BCMA interconnect.

-  

-  
BCMA-compatible variant found in Broadcom Northstar ARM SoCs.

-  

-  
UBUS interconnect. This BCMA-derived interconnect is found in Broadcom
-      BCM33xx DOCSIS SoCs, and BCM63xx xDSL SoCs. UBUS is not currently
-      supported by bhnd(4).

-

-

-
The following chip_caps flags are
-  supported:

-

-

-  

-  
The backplane supports 64-bit addressing.

-  

-  
PMU is present.

-

-

-
Additional symbolic constants for known
-    chip_id, chip_pkg, and
-    chip_type values are defined in
-    <dev/bhnd/bhnd_ids.h>.

-
The
-    ()
-    function returns the BHND class of device dev, if the
-    device's
-    
-    and
-    
-    identifiers are recognized. Otherwise, returns
-    BHND_DEVCLASS_OTHER.

-
One of the following device classes will be returned:

-

-

-

-  

-  
ChipCommon I/O Controller

-  

-  
ChipCommon Auxiliary Controller

-  

-  
PMU Controller

-  

-  
PCI Host/Device Bridge

-  

-  
PCIe Host/Device Bridge

-  

-  
PCMCIA Host/Device Bridge

-  

-  
Internal RAM/SRAM

-  

-  
Memory Controller

-  

-  
IEEE 802.3 MAC/PHY

-  

-  
IEEE 802.3 MAC

-  

-  
IEEE 802.3 PHY

-  

-  
IEEE 802.11 MAC/PHY/Radio

-  

-  
IEEE 802.11 MAC

-  

-  
IEEE 802.11 PHY

-  

-  
CPU Core

-  

-  
Interconnect Router

-  

-  
Interconnect Host Bridge

-  

-  
Device Enumeration ROM

-  

-  
NVRAM/Flash Controller

-  

-  
Analog/PSTN SoftModem Codec

-  

-  
USB Host Controller

-  

-  
USB Device Controller

-  

-  
USB Host/Device Controller

-  

-  
Other / Unknown

-  

-  
Invalid Class

-

-

-
The
-    ()
-    function returns the core information for device dev.
-    The returned bhnd_core_info structure contains the
-    following fields:

-

-

-

-  
vendor

-  
Vendor identifier (JEP-106, ARM 4-bit continuation encoded)

-  
device

-  
Device identifier

-  
hwrev

-  
Hardware revision

-  
core_idx

-  
Core index

-  
unit

-  
Core unit

-

-

-
Symbolic constants for common vendor and device identifiers are
-    defined in
-    <dev/bhnd/bhnd_ids.h>.
-    Common vendor identifiers include:

-

-

-

-  

-  
ARM

-  

-  
Broadcom

-  

-  
MIPS

-

-

-
The
-    (),
-    (),
-    (),
-    (),
-    and
-    ()
-    functions are convenience wrappers for
-    bhnd_get_core_info(), returning, respect the
-    core_idx, core_unit,
-    device, hwrev, or
-    vendor field from the
-    bhnd_core_info structure.

-
The
-    ()
-    function returns a human readable name for device
-  dev.

-
The
-    ()
-    function returns a human readable name for the vendor of device
-    dev.

-
The
-    ()
-    function attempts to read the board information for device
-    dev. The board information will be returned in the
-    location pointed to by info on success.

-
The bhnd_board_info structure contains the
-    following fields:

-

-

-  
board_vendor

-  
Vendor ID of the board manufacturer (PCI-SIG assigned).

-  
board_type

-  
Board ID.

-  
board_devid

-  
Device ID.

-  
board_rev

-  
Board revision.

-  
board_srom_rev

-  
Board SROM format revision.

-  
board_flags

-  
Board flags (1)

-  
board_flags2

-  
Board flags (2)

-  
board_flags3

-  
Board flags (3)

-

-

-
The board_devid field is the Broadcom PCI
-    device ID that most closely matches the capabilities of the BHND device (if
-    any).

-
On PCI devices, the board_vendor,
-    board_type, and board_devid
-    fields default to the PCI Subsystem Vendor ID, PCI Subsystem ID, and PCI
-    device ID, unless overridden in device NVRAM.

-
On other devices, including SoCs, the
-    board_vendor, board_type, and
-    board_devid fields will be populated from device
-    NVRAM.

-
Symbolic constants for common board flags are defined in
-    <dev/bhnd/bhnd_ids.h>.

-

-

-
Device Matching Functions

-
The bhnd device matching functions are used to match against core,
-    chip, and board-level device attributes. Match requirements are specified
-    using the struct bhnd_board_match,
-    struct bhnd_chip_match, struct
-    bhnd_core_match, struct bhnd_device_match, and
-    struct bhnd_hwrev_match match descriptor
-  structures.

-
The
-    ()
-    function returns true if board
-    matches the board match descriptor desc. Otherwise, it
-    returns false.

-
The
-    ()
-    function returns true if chip
-    matches the chip match descriptor desc. Otherwise, it
-    returns false.

-
The
-    ()
-    function returns true if core
-    matches the core match descriptor desc. Otherwise, it
-    returns false.

-
The
-    ()
-    function returns true if the device
-    dev matches the device match descriptor
-    desc. Otherwise, it returns
-    false.

-
The
-    ()
-    function returns true if hwrev
-    matches the hwrev match descriptor desc. Otherwise, it
-    returns false.

-
The
-    ()
-    function returns the first child device of bus that
-    matches the device match descriptor desc. If no
-    matching child is found, NULL is returned.

-
The
-    ()
-    function returns an equality match descriptor for the core info in
-    core. The returned descriptor will match only on core
-    attributes identical to those defined by core.

-
The
-    ()
-    function is a convenience wrapper for
-    bhnd_core_matches() and
-    bhnd_core_get_match_desc(). This function returns
-    true if the bhnd_core_info
-    structures lhs and rhs are
-    equal. Otherwise, it returns false.

-
The
-    ()
-    function returns a pointer to the first entry in the array
-    cores of length num_cores that
-    matches desc. If no matching core is found,
-    NULL is returned.

-
A bhnd_board_match match descriptor may be
-    initialized using one or more of the following macros:

-

-

-  
(vendor)

-  
Match on boards with a vendor equal to vendor.

-  
(type)

-  
Match on boards with a type equal to BHND_BOARD_
-      ## type

-  
(sromrev)

-  
Match on boards with a sromrev that matches BHND_HWREV_
-      ## sromrev.

-  
(hwrev)

-  
Match on boards with hardware revisions that match BHND_
-      ## hwrev.

-  
(vendor,
-    type)

-  
A convenience wrapper for
-      BHND_MATCH_BOARD_VENDOR() and
-      BHND_MATCH_BOARD_TYPE().

-

-

-
For example:

-

-
struct bhnd_board_match board_desc = {
-	BHND_MATCH_BOARD_VENDOR(BHND_MFGID_BROADCOM),
-	BHND_MATCH_BOARD_TYPE(BCM94360X52C),
-	BHND_MATCH_BOARD_REV(HWREV_ANY),
-	BHND_MATCH_SROMREV(RANGE(0, 10))
-};

-

-
A bhnd_chip_match match descriptor may be
-    initialized using one or more of the following macros:

-

-

-  
(id)

-  
Match on chips with an ID equal to BHND_CHIPID_ ##
-      id

-  
(hwrev)

-  
Match on chips with hardware revisions that match BHND_
-      ## hwrev.

-  
(pkg)

-  
Match on chips with a package ID equal to BHND_PKGID_
-      ## pkg

-  
(type)

-  
Match on chips with a chip type equal to BHND_CHIPTYPE_
-      ## type

-  
(id,
-    pkg)

-  
A convenience wrapper for BHND_MATCH_CHIP_ID() and
-      BHND_MATCH_CHIP_PKG().

-  
(id,
-    pkg, hwrev)

-  
A convenience wrapper for BHND_MATCH_CHIP_ID(),
-      BHND_MATCH_CHIP_PKG(), and
-      BHND_MATCH_CHIP_REV().

-  
(id,
-    hwrev)

-  
A convenience wrapper for BHND_MATCH_CHIP_ID() and
-      BHND_MATCH_CHIP_REV().

-

-

-
For example:

-

-
struct bhnd_chip_match chip_desc = {
-	BHND_MATCH_CHIP_IP(BCM4329, BCM4329_289PIN),
-	BHND_MATCH_CHIP_TYPE(SIBA)
-};

-

-
A bhnd_core_match match descriptor may be
-    initialized using one or more of the following macros:

-

-

-  
(vendor)

-  
Match on cores with a vendor ID equal to vendor

-  
(id)

-  
Match on cores with a device ID equal to id

-  
(hwrev)

-  
Match on cores with hardware revisions that match BHND_
-      ## hwrev.

-  
(class)

-  
Match on cores with a core device class equal to
-      class

-  
(idx)

-  
Match on cores with a core index equal to idx

-  
(unit)

-  
Match on cores with a core unit equal to unit

-  
(vendor,
-    id)

-  
A convenience wrapper for BHND_MATCH_CORE_VENDOR()
-      and BHND_MATCH_CORE_ID().

-

-

-
For example:

-

-
struct bhnd_core_match core_desc = {
-	BHND_MATCH_CORE(BHND_MFGID_BROADCOM, BHND_COREID_CC),
-	BHND_MATCH_CORE_REV(HWREV_RANGE(0, 10))
-};

-

-
The bhnd_device_match match descriptor
-    supports matching on all board, chip, and core attributes, and may be
-    initialized using any of the bhnd_board_match,
-    bhnd_chip_match, or
-    bhnd_core_match macros.

-
For example:

-

-
struct bhnd_device_match device_desc = {
-	BHND_MATCH_CHIP_IP(BCM4329, BCM4329_289PIN),
-	BHND_MATCH_BOARD_VENDOR(BHND_MFGID_BROADCOM),
-	BHND_MATCH_BOARD_TYPE(BCM94329AGB),
-	BHND_MATCH_CORE(BHND_MFGID_BROADCOM, BHND_COREID_CC),
-};

-

-
A bhnd_hwrev_match match descriptor may be
-    initialized using one of the following macros:

-

-

-

-  

-  
Matches any hardware revision.

-  
(hwrev)

-  
Matches any hardware revision equal to hwrev

-  
(hwrev)

-  
Matches any hardware revision greater than or equal to
-      hwrev

-  
(hwrev)

-  
Matches any hardware revision less than or equal to
-      hwrev

-  
(start,
-    end)

-  
Matches any hardware revision within an inclusive range. If
-      BHND_HWREV_INVALID is specified as the
-      end value, will match on any revision equal to or
-      greater than start

-

-

-

-

-
Device Table Functions

-
The bhnd device table functions are used to query device and quirk
-    tables.

-
The
-    ()
-    function returns a pointer to the first entry in device table
-    table that matches the device
-    dev. The table entry size is specified by
-    entry_size.

-
The
-    ()
-    function scan the device table table for all quirk
-    entries that match the device dev, returning the
-    bitwise OR of all matching quirk flags. The table entry size is specified by
-    entry_size.

-
The bhnd_device structure contains the
-    following fields:

-

-

-  
core

-  
A bhnd_device_match descriptor.

-  
desc

-  
A verbose device description suitable for use with
-      device_set_desc(9), or
-    NULL.

-  
quirks_table

-  
The quirks table for this device, or NULL.

-  
device_flags

-  
The device flags required when matching this entry.

-

-

-
The following device flags are supported:

-

-

-  

-  
Match on any device.

-  

-  
Match only if the device is the bhndb(4) host bridge.
-      Implies BHND_DF_ADAPTER.

-  

-  
Match only if the device is attached to a native SoC backplane.

-  

-  
Match only if the device is attached to a bhndb(4)
-      bridged backplane.

-

-

-
A bhnd_device table entry may be initialized
-    using one of the following macros:

-

-  
(vendor,
-    device, desc,
-    quirks, flags)

-  
Match on devices with a vendor ID equal to BHND_MFGID_
-      ## vendor and a core device ID equal to
-      BHND_COREID_ ## device.
-    
The device's verbose description is specified by the
-        desc argument, a pointer to the device-specific
-        quirks table is specified by the quirks argument,
-        and any required device flags may be provided in
-        flags. The optional flags
-        argument defaults to BHND_DF_ANY if omitted.

-  

-  

-  
Terminate the bhnd_device table.

-

-
For example:

-

-
struct bhnd_device bhnd_usb11_devices[] = {
-	BHND_DEVICE(BCM, USB, "Broadcom USB1.1 Controller",
-	    bhnd_usb11_quirks),
-	BHND_DEVICE_END
-};

-

-
The bhnd_device_quirk structure contains the
-    following fields:

-

-

-  
desc

-  
A bhnd_device_match descriptor.

-  
quirks

-  
Applicable quirk flags.

-

-

-
A bhnd_device_quirk table entry may be initialized using one of
-    the following convenience macros:

-

-

-  
(board,
-    flags)

-  
Set quirk flags flags on devices with a board type
-      equal to BHND_BOARD_ ##
-      board.

-  
(chip,
-    hwrev, flags)

-  
Set quirk flags flags on devices with a chip ID
-      equal to BHND_CHIPID_BCM ##
-      chip and chip hardware revision that matches
-      BHND_ ## hwrev.

-  
(chip,
-    pkg, flags")

-  
Set quirk flags flags on devices with a chip ID
-      equal to BHND_CHIPID_BCM ##
-      chip and chip package equal to
-      BHND_ ## chip ## pkg.

-  
(hwrev,
-    flags")

-  
Set quirk flags flags on devices with a core
-      hardware revision that matches BHND_ ##
-      hwrev.

-

-

-For example:
-

-
struct bhnd_device_quirk bhnd_usb11_quirks[] = {
-	BHND_DEVICE(BCM, USB, "Broadcom USB1.1 Controller",
-	    bhnd_usb11_quirks),
-	BHND_DEVICE_END
-};

-

-

-

-
DMA Address Translation Functions

-
The
-    ()
-    function is used to request a DMA address translation descriptor suitable
-    for use with a maximum DMA address width of width,
-    with support for the requested translation flags.

-
If a suitable DMA address translation descriptor is found, it will
-    be stored in translation, and a bus DMA tag specifying
-    the DMA translation's address restrictions will be stored in
-    dmat. The translation and
-    dmat arguments may be NULL if
-    the translation descriptor or DMA tag are not desired.

-
The following DMA translation flags are supported:

-

-  

-  
The translation remaps the device's physical address space.
-    
This is used in conjunction with
-        BHND_DMA_TRANSLATION_BYTESWAPPED to define a DMA
-        translation that provides byteswapped access to physical memory on
-        big-endian MIPS SoCs.

-  

-  

-  
The translation provides a byte-swapped mapping; write requests will be
-      byte-swapped before being written to memory, and read requests will be
-      byte-swapped before being returned.
-    
This is primarily used to perform efficient byte swapping of
-        DMA data on embedded MIPS SoCs executing in big-endian mode.

-  

-

-
The following symbolic constants are defined for common DMA
-    address widths:

-

-

-

-  

-  
30-bit DMA

-  

-  
32-bit DMA

-  

-  
64-bit DMA

-

-

-
The bhnd_dma_translation structure contains
-    the following fields:

-

-  
base_addr

-  
Host-to-device physical address translation. This may be added to a host
-      physical address to produce a device DMA address.

-  
addr_mask

-  
Device-addressable address mask. This defines the device DMA address
-      range, and excludes any bits reserved for mapping the address within the
-      translation window at base_addr.

-  
addrext_mask

-  
Device-addressable extended address mask. If a the per-core BHND DMA
-      engine supports the 'addrext' control field, it can be used to provide
-      address bits excluded by addr_mask.
-    
Support for DMA extended address changes — including
-        coordination with the core providing device-to-host DMA address
-        translation — is handled transparently by the DMA engine.

-    
For example, on PCI Wi-Fi devices, the Wi-Fi core's DMA engine
-        will (in effect) update the PCI host bridge core's DMA
-        sbtopcitranslation base address to map the
-        target address prior to performing a DMA transaction.

-  

-  
flags

-  
Translation flags.

-

-

-

-
Interrupt Functions

-
The
-    ()
-    function is used to determine the number of backplane interrupt lines
-    assigned to the device dev. Interrupt line identifiers
-    are allocated in monotonically increasing order, starting with 0.

-
The
-    ()
-    function is used to determine the backplane interrupt vector assigned to
-    interrupt line intr on the device
-    dev, writing the result to ivec.
-    Interrupt vector assignments are backplane-specific: On BCMA devices, this
-    function returns the OOB bus line assigned to the interrupt. On SIBA
-    devices, it returns the target OCP slave flag number assigned to the
-    interrupt.

-
The
-    ()
-    function is used to map interrupt line intr assigned
-    to device dev to an IRQ number, writing the result to
-    irq. Until unmapped, this IRQ may be used when
-    allocating a resource of type SYS_RES_IRQ.

-
Ownership of the interrupt mapping is assumed by the caller, and
-    must be explicitly released using bhnd_unmap_intr.

-
The
-    ()
-    function is used to unmap bus IRQ irq previously
-    mapped using bhnd_map_intr() by the device
-    dev.

-

-

-
NVRAM Functions

-
The bhnd_nvram_getvar() function is used
-    to read the value of NVRAM variable name from the
-    NVRAM provider(s) registered with the parent bhnd(4) bus
-    of device dev, coerced to the desired data
-    representation type, written to the buffer specified
-    by buf.

-
Before the call, the maximum capacity of
-    buf is specified by len. After a
-    successful call — or if ENOMEM is returned
-    — the size of the available data will be written to
-    len. The size of the desired data representation can
-    be determined by calling
-    ()
-    with a NULL argument for
-  buf.

-
The following NVRAM data types are supported:

-

-

-

-  

-  
unsigned 8-bit integer

-  

-  
unsigned 16-bit integer

-  

-  
unsigned 32-bit integer

-  

-  
signed 64-bit integer

-  

-  
signed 8-bit integer

-  

-  
signed 16-bit integer

-  

-  
signed 32-bit integer

-  

-  
signed 64-bit integer

-  

-  
UTF-8 character

-  

-  
UTF-8 NUL-terminated string

-  

-  
uint8 boolean value

-  

-  
NULL (empty) value

-  

-  
opaque octet string

-  

-  
array of uint8 integers

-  

-  
array of uint16 integers

-  

-  
array of uint32 integers

-  

-  
array of uint64 integers

-  

-  
array of int8 integers

-  

-  
array of int16 integers

-  

-  
array of int32 integers

-  

-  
array of int64 integers

-  

-  
array of UTF-8 characters

-  

-  
array of UTF-8 NUL-terminated strings

-  

-  
array of uint8 boolean values

-

-

-
The
-    (),
-    bhnd_nvram_getvar_int(),
-    bhnd_nvram_getvar_int8(),
-    bhnd_nvram_getvar_int16(),
-    bhnd_nvram_getvar_int32(),
-    bhnd_nvram_getvar_uint(),
-    bhnd_nvram_getvar_uint8(),
-    bhnd_nvram_getvar_uint16(),
-    bhnd_nvram_getvar_uint32(), and
-    bhnd_nvram_getvar_str() functions are convenience
-    wrappers for bhnd_nvram_getvar().

-
The
-    ()
-    function returns either a value of exactly size in
-    buf, or returns an error code of
-    ENXIO if the data representation is not exactly
-    size in length.

-
The
-    ()
-    and
-    ()
-    functions return the value of NVRAM variable name,
-    coerced to a signed or unsigned integer type of width
-    (1, 2, or 4 bytes).

-
The
-    (),
-    (),
-    (),
-    bhnd_nvram_getvar_uint(),
-    (),
-    (),
-    and
-    ()
-    functions return the value of NVRAM variable name,
-    coerced to a signed or unsigned 8, 16, or 32-bit integer type.

-
The
-    ()
-    functions return the value of NVRAM variable name,
-    coerced to a NUL-terminated string.

-
The
-    ()
-    function iterates over all strings in the inp
-    BHND_NVRAM_TYPE_STRING_ARRAY value. The size of
-    inp, including any terminating NUL character(s), is
-    specified using the ilen argument. The
-    prev argument should be either a string pointer
-    previously returned by
-    bhnd_nvram_string_array_next(), or
-    NULL to begin iteration. If prev is
-    not NULL, the olen
-    argument must be a pointer to the length previously returned by
-    bhnd_nvram_string_array_next(). On success, the next
-    string element's length will be written to this pointer.

-

-

-
Port/Region Functions

-
Per-device interconnect memory mappings are identified by a
-    combination of port type, port number,
-    and . Port and memory region identifiers are allocated in
-    monotonically increasing order for each port type,
-    starting with 0.

-
The following port types are supported:

-

-

-  

-  
Device memory. The device's control/status registers are always mapped by
-      the first device port and region, and will be assigned a
-      SYS_RES_MEMORY resource ID of 0.

-  

-  
Bridge memory.

-  

-  
Interconnect agent/wrapper.

-

-

-
The
-    ()
-    function is used to decode the resource ID rid
-    assigned to device dev, of resource type
-    type, writing the port type to
-    port_type, port number to port,
-    and region number to region.

-
The
-    ()
-    function returns the number of ports of type type
-    assigned to device dev.

-
The
-    ()
-    function returns the resource ID for the
-    SYS_RES_MEMORY resource mapping the
-    port of type and
-    region on device dev, or -1 if
-    the port or region are invalid, or do not have an assigned resource ID.

-
The
-    ()
-    function is used to determine the base address and size of the memory
-    region on port of
-    type assigned to dev. The
-    region's base device address will be written to
-    region_addr, and the region size to
-    region_size.

-
The
-    ()
-    function returns the number of memory regions mapped to
-    port of type on device
-    dev.

-
The
-    ()
-    function returns true if
-    region is a valid region mapped by
-    port of type on device
-    dev.

-

-

-
Power Management Functions

-
Drivers must ask the parent bhnd(4) bus to
-    allocate device PMU state using bhnd_alloc_pmu()
-    before calling any another bhnd PMU functions.

-
The
-    ()
-    function is used to allocate per-device PMU state and enable PMU request
-    handling for device dev. The memory region containing
-    the device's PMU register block must be allocated using
-    bus_alloc_resource(9) or
-    bhnd_alloc_resource() before calling
-    bhnd_alloc_pmu(), and must not be released until
-    after calling bhnd_release_pmu().

-
On all supported BHND hardware, the PMU register block is mapped
-    by the device's control/status registers in the first device port and
-    region.

-
The
-    ()
-    function releases the per-device PMU state previously allocated for device
-    dev using bhnd_alloc_pmu().
-    Any outstanding clock and external resource requests will be discarded upon
-    release of the device PMU state.

-
The
-    ()
-    function is used to request that clocks be powered up
-    and routed to the backplane on behalf of device dev.
-    This will power any clock sources required (e.g., XTAL, PLL, etc) and wait
-    until the requested clocks are stable. If the request succeeds, any previous
-    clock requests issued by dev will be discarded.

-
The following clocks are supported, and may be combined using
-    bitwise OR to request multiple clocks:

-

-

-  
BHND_CLOCK_DYN

-  
Dynamically select an appropriate clock source based on all outstanding
-      clock requests by any device attached to the parent
-      bhnd(4) bus.

-  
BHND_CLOCK_ILP

-  
Idle Low-Power (ILP) Clock. May be used if no register access is required,
-      or long request latency is acceptable.

-  
BHND_CLOCK_ALP

-  
Active Low-Power (ALP) Clock. Supports low-latency register access and
-      low-rate DMA.

-  
BHND_CLOCK_HT

-  
High Throughput (HT) Clock. Supports high bus throughput and
-      lowest-latency register access.

-

-

-
The
-    ()
-    function is used to request that clock (or faster) be
-    powered up and routed to device dev.

-
The
-    ()
-    function is used to request the current clock frequency of
-    clock, writing the frequency in Hz to
-    freq.

-
The
-    ()
-    function is used to determine the transition latency required for
-    clock, writing the latency in microseconds to
-    latency. The BHND_CLOCK_HT
-    latency value is suitable for use as the D11 Wi-Fi core
-    
-    value.

-
The
-    ()
-    function is used to request that the external PMU-managed resource assigned
-    to device dev, identified by device-specific
-    identifier rsrc, be powered up.

-
The
-    ()
-    function releases any outstanding requests by device
-    dev for the PMU-managed resource identified by
-    device-specific identifier rsrc. If an external
-    resource is shared by multiple devices, it will not be powered down until
-    all device requests are released.

-

-

-
Service Provider Functions

-
The
-    ()
-    function is used to register device dev as a provider
-    for platform service with the parent
-    bhnd(4) bus.

-
The following service types are supported:

-

-

-  

-  
ChipCommon service. The providing device must implement the bhnd_chipc
-      interface.

-  

-  
Legacy PWRCTL service. The providing device must implement the bhnd_pwrctl
-      interface.

-  

-  
PMU service. The providing device must implement the bhnd_pmu
-    interface.

-  

-  
NVRAM service. The providing device must implement the bhnd_nvram
-      interface.

-  

-  
GPIO service. The providing device must implement the standard
-      gpio(4) interface.

-  

-  
Matches on any service type. May be used with
-      ()
-      to remove all service provider registrations for a device.

-

-

-
The
-    ()
-    function attempts to remove provider registration for the device
-    dev and service. If a
-    service argument of
-    BHND_SERVICE_ANY is specified, this function will
-    attempt to remove
-     dev.

-
The
-    ()
-    function retains and returns a reference to the provider registered for
-    service with the parent bhnd(4) bus
-    of device dev, if available. On success, the caller is
-    responsible for releasing this provider reference using
-    bhnd_release_provider(). The service provider is
-    guaranteed to remain available until the provider reference is released.

-
The
-    ()
-    function releases a reference to a provider for
-    service, previously retained by device
-    dev using
-    bhnd_retain_provider().

-

-

-
Utility Functions

-
The
-    ()
-    function returns the bhnd_erom(9) class for the device
-    enumeration table format used by bhnd(4) bus driver
-    instance driver. If the driver does not support
-    bhnd_erom(9) device enumeration,
-    NULL is returned.

-
The
-    ()
-    function looks up the BHND class, if known, for the BHND vendor ID
-    vendor and device ID device.

-
The
-    ()
-    function is used to fetch the human-readable name, if known, for the BHND
-    core with a vendor ID of vendor and device ID of
-    device.

-
The
-    ()
-    and
-    ()
-    functions are convenience wrappers for
-    bhnd_find_core_class() and
-    bhnd_find_core_name(), that use the
-    vendor and device fields of the
-    core info structure ci.

-
The
-    ()
-    function writes a NUL-terminated human-readable representation of the BHND
-    chip_id value to the specified
-    buffer with a capacity of size.
-    No more than size-1 characters will be written, with
-    the size'th character set to '\0'. A buffer size of
-    BHND_CHIPID_MAX_NAMELEN is sufficient for any string
-    representation produced using
-  bhnd_format_chip_id().

-
The
-    ()
-    function uses the bhnd(4) device identification of
-    dev, overriding the core name with the specified
-    dev_name, to populate the device's verbose description
-    using device_set_desc(9).

-
The
-    ()
-    function uses the bhnd(4) device identification of
-    dev to populate the device's verbose description using
-    device_set_desc(9).

-
The
-    ()
-    function returns the human-readable name for the JEP-106, ARM 4-bit
-    continuation encoded manufacturer ID vendor, if
-  known.

-

-

-

-

-

-
Bus Resource Functions

-
The bhnd_activate_resource(),
-    bhnd_alloc_resources(),
-    bhnd_deactivate_resource(), and
-    bhnd_release_resource() functions return 0 on
-    success, otherwise an appropriate error code is returned.

-
The bhnd_alloc_resource() and
-    bhnd_alloc_resource_any() functions return a pointer
-    to struct resource on success, a null pointer
-    otherwise.

-

-

-
Device Configuration Functions

-
The bhnd_read_config() and
-    bhnd_write_config() functions return 0 on success,
-    or one of the following values on error:

-

-  
[EINVAL]

-  
The device is not a direct child of the bhnd(4) bus

-  
[EINVAL]

-  
The requested width is not one of 1, 2, or 4 bytes.

-  
[ENODEV]

-  
Accessing agent/config space for the device is unsupported.

-  
[EFAULT]

-  
The requested offset or width exceeds the bounds of the mapped
-      agent/config space.

-

-
The bhnd_read_ioctl(),
-    bhnd_write_ioctl(),
-    bhnd_read_iost(),
-    bhnd_reset_hw(), and
-    bhnd_suspend_hw() functions return 0 on success,
-    otherwise an appropriate error code is returned.

-

-

-
Device Information Functions

-
The bhnd_read_board_info() function
-    returns 0 on success, otherwise an appropriate error code is returned.

-

-

-
DMA Address Translation Functions

-
The bhnd_get_dma_translation() function
-    returns 0 on success, or one of the following values on error:

-

-  
[ENODEV]

-  
DMA is not supported.

-  
[ENOENT]

-  
No DMA translation matching the requested address width and translation
-      flags is available.

-

-
If fetching the requested DMA address translation otherwise fails,
-    an appropriate error code will be returned.

-

-

-
Interrupt Functions

-
The bhnd_get_intr_ivec() function returns
-    0 on success, or ENXIO if the requested interrupt
-    line exceeds the number of interrupt lines assigned to the device.

-
The bhnd_map_intr() function returns 0 on
-    success, otherwise an appropriate error code is returned.

-

-

-
NVRAM Functions

-
The bhnd_nvram_getvar(),
-    bhnd_nvram_getvar_array(),
-    bhnd_nvram_getvar_int(),
-    bhnd_nvram_getvar_int8(),
-    bhnd_nvram_getvar_int16(),
-    bhnd_nvram_getvar_int32(),
-    bhnd_nvram_getvar_uint(),
-    bhnd_nvram_getvar_uint8(),
-    bhnd_nvram_getvar_uint16(), and
-    bhnd_nvram_getvar_uint32() functions return 0 on
-    success, or one of the following values on error:

-

-  
[ENODEV]

-  
If an NVRAM provider has not been registered with the bus.

-  
[ENOENT]

-  
The requested variable was not found.

-  
[ENOMEM]

-  
If the buffer of size is too small to hold the requested value.

-  
[EOPNOTSUPP]

-  
If the value's native type is incompatible with and cannot be coerced to
-      the requested type.

-  
[ERANGE]

-  
If value coercion would overflow (or underflow) the requested type

-

-
If reading the variable otherwise fails, an appropriate error code
-    will be returned.

-

-

-
Port/Region Functions

-
The bhnd_decode_port_rid() function
-    returns 0 on success, or an appropriate error code if no matching
-    port/region is found.

-
The bhnd_get_port_rid() function returns
-    the resource ID for the requested port and region, or -1 if the port or
-    region are invalid, or do not have an assigned resource ID.

-
The bhnd_get_region_addr() function
-    returns 0 on success, or an appropriate error code if no matching
-    port/region is found.

-

-

-

-
The bhnd_alloc_pmu() function returns 0 on
-    success, otherwise an appropriate error code is returned.

-
The bhnd_release_pmu() function returns 0
-    on success, otherwise an appropriate error code is returned, and the core
-    state will be left unmodified.

-
The bhnd_enable_clocks() and
-    bhnd_request_clock() functions return 0 on success,
-    or one of the following values on error:

-

-  
[ENODEV]

-  
An unsupported clock was requested.

-  
[ENXIO]

-  
No PMU or PWRCTL provider has been registered with the bus.

-

-
The bhnd_get_clock_freq() function returns
-    0 on success, or ENODEV if the frequency for the
-    specified clock is not available.

-
The bhnd_get_clock_latency() function
-    returns 0 on success, or ENODEV if the transition
-    latency for the specified clock is not available.

-
The bhnd_request_ext_rsrc() and
-    bhnd_release_ext_rsrc() functions return 0 on
-    success, otherwise an appropriate error code is returned.

-

-

-
Service Provider Functions

-
The bhnd_register_provider() function
-    returns 0 on success, EEXIST if an entry for service
-    already exists, or an appropriate error code if service registration
-    otherwise fails.

-
The bhnd_deregister_provider() function
-    returns 0 on success, or EBUSY if active references
-    to the service provider exist.

-
The bhnd_retain_provider() function
-    returns a pointer to device_t on success, a null
-    pointer if the requested provider is not registered.

-

-

-
Utility Functions

-
The bhnd_format_chip_id() function returns
-    the total number of bytes written on success, or a negative integer on
-    failure.

-

-

-

-

-
bhnd(4), bhnd_erom(9)

-

-

-

-
The bhnd driver programming interface and
-    this manual page were written by Landon Fuller
-    <landonf@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 26, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/bhnd_erom.9 3.html b/static/freebsd/man9/bhnd_erom.9 3.html
deleted file mode 100644
index cd4de85c..00000000
--- a/static/freebsd/man9/bhnd_erom.9 3.html	
+++ /dev/null
@@ -1,355 +0,0 @@
-
-  
-    
-    
-    
-  
-
BHND_EROM(9)Kernel Developer's ManualBHND_EROM(9)

-

-

-

-
bhnd_erom,
-    bhnd_erom_alloc,
-    bhnd_erom_dump,
-    bhnd_erom_fini_static,
-    bhnd_erom_free,
-    bhnd_erom_free_core_table,
-    bhnd_erom_get_core_table,
-    bhnd_erom_init_static,
-    bhnd_erom_io,
-    bhnd_erom_io_fini,
-    bhnd_erom_io_map,
-    bhnd_erom_io_read,
-    bhnd_erom_iobus_init,
-    bhnd_erom_iores_new,
-    bhnd_erom_lookup_core,
-    bhnd_erom_lookup_core_addr,
-    bhnd_erom_probe,
-    bhnd_erom_probe_driver_classes —
-    BHND device enumeration table parsing

-

-

-

-
#include
-    <dev/bhnd/bhnd.h>
-  

-  #include
-    <dev/bhnd/bhnd_erom.h>

-
typedef struct bhnd_erom bhnd_erom_t;
-  

-  typedef struct kobj_class bhnd_erom_class_t;
-  

-  typedef struct bhnd_erom_static bhnd_erom_static_t;

-
int
-  

-  bhnd_erom_probe(bhnd_erom_class_t
-    *cls, struct bhnd_erom_io *eio,
-    const struct bhnd_chipid *hint, struct
-    bhnd_chipid *cid);

-
bhnd_erom_class_t *
-  

-  bhnd_erom_probe_driver_classes(devclass_t
-    bus_devclass, struct bhnd_erom_io *eio,
-    const struct bhnd_chipid *hint, struct
-    bhnd_chipid *cid);

-
bhnd_erom_t *
-  

-  bhnd_erom_alloc(bhnd_erom_class_t
-    *cls, const struct bhnd_chipid *cid,
-    struct bhnd_erom_io *eio);

-
void
-  

-  bhnd_erom_free(bhnd_erom_t
-    *erom);

-
int
-  

-  bhnd_erom_init_static(bhnd_erom_class_t
-    *cls, bhnd_erom_t *erom, size_t
-    esize, const struct bhnd_chipid *cid,
-    struct bhnd_erom_io *eio);

-
void
-  

-  bhnd_erom_fini_static(bhnd_erom_t
-    *erom);

-
int
-  

-  bhnd_erom_dump(bhnd_erom_t
-    *erom);

-
int
-  

-  bhnd_erom_get_core_table(bhnd_erom_t
-    *erom, struct bhnd_core_info **cores,
-    u_int *num_cores);

-
void
-  

-  bhnd_erom_free_core_table(bhnd_erom_t
-    *erom, struct bhnd_core_info *cores);

-
int
-  

-  bhnd_erom_lookup_core(bhnd_erom_t
-    *erom, const struct bhnd_core_match *desc,
-    struct bhnd_core_info *core);

-
int
-  

-  bhnd_erom_lookup_core_addr(bhnd_erom_t
-    *erom, const struct bhnd_core_match *desc,
-    bhnd_port_type type, u_int port,
-    u_int region, struct bhnd_core_info
-    *core, bhnd_addr_t *addr,
-    bhnd_size_t *size);

-

-
Bus Space I/O

-
struct bhnd_erom_io *
-  

-  bhnd_erom_iores_new(device_t
-    dev, int rid);

-
int
-  

-  bhnd_erom_iobus_init(struct
-    bhnd_erom_iobus *iobus, bhnd_addr_t addr,
-    bhnd_size_t size, bus_space_tag_t
-    bst, bus_space_handle_t bsh);

-
void
-  

-  bhnd_erom_io_fini(struct bhnd_erom_io
-    *eio);

-
int
-  

-  bhnd_erom_io_map(struct bhnd_erom_io
-    *eio, bhnd_addr_t addr,
-    bhnd_size_t size);

-
uint32_t
-  

-  bhnd_erom_io_read(struct bhnd_erom_io
-    *eio, bhnd_size_t offset, u_int
-    width);

-
#include
-    <dev/bhnd/bhnd_eromvar.h>

-

-
struct bhnd_erom_io {
-	bhnd_erom_io_map_t	*map;
-	bhnd_erom_io_read_t	*read;
-	bhnd_erom_io_fini_t	*fini;
-};

-

-

-typedef int
-

-(bhnd_erom_io_map_t)(struct bhnd_erom_io
-  *eio, bhnd_addr_t addr,
-  bhnd_size_t size);
-
typedef uint32_t
-  

-  (bhnd_erom_io_read_t)(struct
-    bhnd_erom_io *eio, bhnd_size_t offset,
-    u_int width);

-
typedef void
-  

-  (bhnd_erom_io_fini_t)(struct
-    bhnd_erom_io *eio);

-

-

-

-

-
The bhnd_erom framework provides a common
-    parser interface to the BHND device enumeration table formats supported by
-    bhnd(4) bus drivers.

-
The
-    ()
-    function is used to identify a bhnd(4) bus device and
-    determine whether the erom class cls is capable of
-    parsing its device enumeration table. If successful, the probed chip
-    identification is written to the location pointed to by
-    cid.

-
A pointer to a bus I/O instance mapping the
-    device registers of the first hardware core must be provided using the
-    eio argument. The registers can be mapped using
-    ().

-
On devices that do not provide standard
-    bhnd_chipc(4) chip identification registers via the first
-    hardware core, a pointer to chip information for the device must be
-    specified using the hint argument. Otherwise, the
-    hint argument should be
-  NULL.

-
The
-    ()
-    function is a convenience wrapper for
-    bhnd_erom_probe(). This function will iterate over
-    all drivers instances in the device class
-    bus_devclass, using
-    bhnd_driver_get_erom_class(9) to fetch each driver's erom
-    class and probe the hardware core mapped by eio. A
-    pointer to the erom class with the highest probe priority is returned on
-    success. If there are no successful probe results from the erom classes,
-    NULL is returned.

-
The
-    ()
-    function allocates and returns a new parser instance of the device
-    enumeration class cls for the chip identified by
-    cid, using the bus I/O instance
-    eio to map and read the device table. On success, the
-    returned bhnd_erom_t assumes ownership of
-    eio.

-
The
-    ()
-    function releases all resources held by an erom parser successfully
-    allocated using bhnd_erom_alloc().

-
Clients can manage the allocation of
-    memory themselves with
-    ().
-    This is useful in cases like performing device enumeration before
-    malloc(9) initialization.
-    bhnd_erom_init_static() is called with
-    erom set to a pointer to the memory for the instance,
-    and the total available bytes in esize.

-
The bhnd_erom_static structure is large
-    enough to statically allocate any supported parser class instance state.
-    Pointers to a bhnd_erom_static structure can be cast
-    to bhnd_erom_t.

-
The
-    ()
-    function releases all resources held by an erom parser successfully
-    initialized using bhnd_erom_init_static().

-
The
-    ()
-    function enumerates and prints all device table entries in
-    erom.

-
The
-    ()
-    function enumerates all device table entries in erom,
-    returning a table of core information structures in
-    cores and the count in
-    num_cores. The memory allocated for the table must be
-    freed using bhnd_erom_free_core_table().

-
The
-    ()
-    function frees any memory allocated in a previous call to
-    bhnd_erom_get_core_table().

-
The
-    ()
-    function locates the first device table entry in erom
-    that matches core match descriptor desc, writing the
-    core information of the matching entry to core.

-
The
-    ()
-    function locates the first device table entry in erom
-    that matches core match descriptor desc, fetching the
-    base address and size of the memory region region
-    mapped to the port port of type
-    type. On success, the core information of the matching
-    entry is written to core, the base address of the port
-    region is written to addr, and the total size of the
-    port region is written to size. If the core
-    information is not desired, set core to
-    NULL.

-

-
Bus Space I/O

-
The bhnd_erom_io structure provides a set of
-    I/O callbacks used by bhnd_erom to map and read the
-    device enumeration table. Clients may either use the existing
-    bhnd_erom_iores_new() or
-    bhnd_erom_iobus_init() functions to allocate a bus
-    I/O instance, or implement the bhnd_erom_io callbacks
-    directly.

-
The bhnd_erom_io structure contains these
-    required fields:

-

-

-  
map

-  
A function implementing
-      ().

-  
read

-  
A function implementing bhnd_erom_io_read().

-  
fini

-  
A function implementing bhnd_erom_io_fini().

-

-

-
The
-    ()
-    function allocates and returns a new bus I/O instance that will perform
-    mapping by using bhnd_alloc_resource(9) to allocate
-    SYS_RES_MEMORY bus resources on demand from the
-    device dev using a resource ID of
-    rid.

-
The
-    ()
-    function initializes a caller-allocated bus I/O instance
-    iobus that will perform bus I/O using the bus space
-    tag bst and handle bsh. The base
-    address and total size mapped by bsh should be
-    specified using the addr and
-    size arguments.

-
The
-    ()
-    function frees all resources held by the bus I/O instance
-    eio.

-
The
-    ()
-    function is used to request that the bus I/O instance
-    eio map bhnd(4) bus space at bus
-    address addr with a mapping of size
-    size.

-
The
-    ()
-    function is used to read a data item of width bytes
-    from the bus I/O instance eio at
-    offset, relative to the bus address previously mapped
-    using bhnd_erom_io_map().

-
The width must be one of 1, 2, or 4
-  bytes.

-

-

-

-

-
The bhnd_erom_probe() function returns a
-    standard DEVICE_PROBE(9) result.

-
A return value equal to or less than zero indicates success.
-    Values greater than zero indicates an error, and will be an appropriate
-    error code. For values less than or equal to zero, the erom class returning
-    the highest value should be used to parse the erom table.
-    ENXIO is returned if the device is not supported by
-    the parser.

-
The bhnd_erom_probe_driver_classes()
-    function returns a pointer to the probed
-    bhnd_erom_class_t instance on success, a null pointer
-    otherwise.

-
The bhnd_erom_alloc() function returns a
-    pointer to bhnd_erom_t on success, or
-    NULL if an error occurred allocating or initializing
-    the EROM parser.

-
The bhnd_erom_init_static() function
-    returns 0 on success, ENOMEM if the allocation size
-    is smaller than required by the erom class, or an appropriate error code if
-    initialization otherwise fails.

-
The bhnd_erom_lookup_core() function
-    returns 0 on success, ENOENT if no matching core is
-    found, or an appropriate error code if parsing the device table otherwise
-    fails.

-
The bhnd_erom_dump(),
-    bhnd_erom_get_core_table(),
-    bhnd_erom_iobus_init(),
-    bhnd_erom_io_map(), functions return 0 on success,
-    otherwise an appropriate error code is returned.

-

-

-

-
bhnd(4), bhnd(9),
-    bhnd_alloc_resource(9),
-    bhnd_driver_get_erom_class(9),
-    bus_space(9)

-

-

-

-
The bhnd_erom framework and this manual
-    page were written by Landon Fuller
-    <landonf@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 9, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/bios.9 3.html b/static/freebsd/man9/bios.9 3.html
deleted file mode 100644
index 59c484bb..00000000
--- a/static/freebsd/man9/bios.9 3.html	
+++ /dev/null
@@ -1,158 +0,0 @@
-
-  
-    
-    
-    
-  
-
BIOS(9)Kernel Developer's ManualBIOS(9)

-

-

-

-
bios_sigsearch,
-    bios32_SDlookup, bios32,
-    bios_oem_strings — interact
-    with PC BIOS

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>
-  

-  #include
-  <machine/pc/bios.h>

-
uint32_t
-  

-  bios_sigsearch(uint32_t
-    start, u_char *sig,
-    int siglen,
-    int paralen,
-    int sigofs);

-
int
-  

-  bios32_SDlookup(struct
-    bios32_SDentry *ent);

-
int
-  

-  bios32(struct
-    bios_regs *br, u_int
-    offset, u_short
-    segment);

-
BIOS_PADDRTOVADDR(addr);

-
BIOS_VADDRTOPADDR(addr);

-
extern struct bios32_SDentry PCIbios;
-  

-  extern struct SMBIOS_table SMBIOStable;
-  

-  extern struct DMI_table DMItable;

-
int
-  

-  bios_oem_strings(struct
-    bios_oem *oem, u_char
-    *buffer, size_t
-    maxlen);

-

-
struct bios_oem_signature {
-        char * anchor;          /* search anchor string in BIOS memory */
-        size_t offset;          /* offset from anchor (may be negative) */
-        size_t totlen;          /* total length of BIOS string to copy */
-};
-struct bios_oem_range {
-        u_int from;             /* shouldn't be below 0xe0000 */
-        u_int to;               /* shouldn't be above 0xfffff */
-};
-struct bios_oem {
-        struct bios_oem_range range;
-        struct bios_oem_signature signature[];
-};

-

-

-

-

-
These functions provide a general-purpose interface for dealing
-    with the BIOS functions and data encountered on x86 PC-architecture
-  systems.

-

-  
()

-  
Searches the BIOS address space for a service signature, usually an
-      uppercase ASCII sequence surrounded by underscores. The search begins at
-      start, or at the beginning of the BIOS if
-      start is zero. siglen bytes of
-      the BIOS image and sig are compared at
-      sigofs bytes offset from the current location. If no
-      match is found, the current location is incremented by
-      paralen bytes and the search repeated. If the
-      signature is found, its effective physical address is returned. If no
-      signature is found, zero is returned.

-  
()

-  
Searches a given BIOS memory range for one or more strings, and composes a
-      printable concatenation of those found. The routine expects a structure
-      describing the BIOS address range (within
-      0xe0000 - 0xfffff), and a
-      { NULL, 0,
-      0 } -terminated array of
-      bios_oem_signature structures which define the
-      anchor string, an offset from
-      the beginning of the match (which may be negative), and
-      totlen number of bytes to be collected from BIOS
-      memory starting at that offset. Unmatched anchors are ignored, whereas
-      matches are copied from BIOS memory starting at their corresponding
-      offset with unprintable characters being replaced
-      with space, and consecutive spaces being suppressed. This composed string
-      is stored in buffer up to the given
-      maxlen bytes (including trailing
-      ‘\0’, and any trailing space
-      suppressed). If an error is encountered, i.e. trying to read out of said
-      BIOS range, other invalid input, or buffer overflow,
-      a negative integer is returned, otherwise the length of the composed
-      string is returned. In particular, a return value of 0 means that none of
-      the given anchor strings were found in the specified BIOS memory
-    range.

-  
()

-  
Returns the effective physical address which corresponds to the kernel
-      virtual address addr.

-  
()

-  
Returns the kernel virtual address which corresponds to the effective
-      physical address addr.

-  
SMBIOStable

-  
If not NULL, points to a struct SMBIOS_table
-      structure containing information read from the System Management BIOS
-      table during system startup.

-  
DMItable

-  
If not NULL, points to a struct DMI_table structure
-      containing information read from the Desktop Management Interface
-      parameter table during system startup.

-

-

-

-

-
At system startup, the BIOS is scanned for the BIOS32 Service
-    Directory (part of the PCI specification), and the existence of the
-    directory is recorded. This can then be used to locate other services.

-

-  
()

-  
Attempts to locate the BIOS32 service matching the 4-byte identifier
-      passed in the ident field of the
-      ent argument.

-  
()

-  
Calls a bios32 function. This presumes that the function is capable of
-      working within the kernel segment (normally the case). The virtual address
-      of the entrypoint is supplied in entry and the
-      register arguments to the function are supplied in
-      args.

-  
PCIbios

-  
If not NULL, points to a struct bios32_SDentry
-      structure describing the PCI BIOS entrypoint which was found during system
-      startup.

-

-

-

-
-  
-    
-    
-  
-
August 9, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/bitset.9 3.html b/static/freebsd/man9/bitset.9 3.html
deleted file mode 100644
index f0a617ef..00000000
--- a/static/freebsd/man9/bitset.9 3.html	
+++ /dev/null
@@ -1,487 +0,0 @@
-
-  
-    
-    
-    
-  
-
BITSET(9)Kernel Developer's ManualBITSET(9)

-

-

-

-
bitset(9) —
-    BITSET_DEFINE,
-    BITSET_T_INITIALIZER,
-    BITSET_FSET, BIT_CLR,
-    BIT_COPY, BIT_ISSET,
-    BIT_SET, BIT_ZERO,
-    BIT_FILL, BIT_SETOF,
-    BIT_EMPTY, BIT_ISFULLSET,
-    BIT_FFS, BIT_FFS_AT,
-    BIT_FLS, BIT_FOREACH_ISSET,
-    BIT_FOREACH_ISCLR,
-    BIT_COUNT, BIT_SUBSET,
-    BIT_OVERLAP, BIT_CMP,
-    BIT_OR, BIT_OR2,
-    BIT_ORNOT, BIT_ORNOT2,
-    BIT_AND, BIT_AND2,
-    BIT_ANDNOT, BIT_ANDNOT2,
-    BIT_XOR, BIT_XOR2,
-    BIT_CLR_ATOMIC,
-    BIT_SET_ATOMIC,
-    BIT_SET_ATOMIC_ACQ,
-    BIT_TEST_SET_ATOMIC,
-    BIT_TEST_CLR_ATOMIC,
-    BIT_AND_ATOMIC,
-    BIT_OR_ATOMIC,
-    BIT_COPY_STORE_REL — bitset
-    manipulation macros

-

-

-

-
#include
-    <sys/_bitset.h>
-  

-  #include <sys/bitset.h>

-
BITSET_DEFINE(STRUCTNAME,
-    const SETSIZE);

-
BITSET_T_INITIALIZER(ARRAY_CONTENTS);

-
BITSET_FSET(N_WORDS);

-
BIT_CLR(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
BIT_COPY(const
-    SETSIZE, struct
-    STRUCTNAME *from, struct
-    STRUCTNAME *to);

-
bool
-  

-  BIT_ISSET(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
BIT_SET(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
BIT_ZERO(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
BIT_FILL(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
BIT_SETOF(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
bool
-  

-  BIT_EMPTY(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
bool
-  

-  BIT_ISFULLSET(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
long
-  

-  BIT_FFS(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
long
-  

-  BIT_FFS_AT(const
-    SETSIZE, struct
-    STRUCTNAME *bitset, long
-    start);

-
long
-  

-  BIT_FLS(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
BIT_FOREACH_ISSET(const
-    SETSIZE, size_t bit, const
-    struct STRUCTNAME *bitset);

-
BIT_FOREACH_ISCLR(const
-    SETSIZE, size_t bit, const
-    struct STRUCTNAME *bitset);

-
long
-  

-  BIT_COUNT(const
-    SETSIZE, struct
-    STRUCTNAME *bitset);

-
bool
-  

-  BIT_SUBSET(const SETSIZE,
-    struct STRUCTNAME *haystack, struct
-    STRUCTNAME *needle);

-
bool
-  

-  BIT_OVERLAP(const SETSIZE,
-    struct STRUCTNAME *bitset1, struct
-    STRUCTNAME *bitset2);

-
bool
-  

-  BIT_CMP(const SETSIZE,
-    struct STRUCTNAME *bitset1, struct
-    STRUCTNAME *bitset2);

-
BIT_OR(const
-    SETSIZE, struct
-    STRUCTNAME *dst, struct
-    STRUCTNAME *src);

-
BIT_OR2(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src1, struct
-    STRUCTNAME *src2);

-
BIT_ORNOT(const
-    SETSIZE, struct
-    STRUCTNAME *dst, struct
-    STRUCTNAME *src);

-
BIT_ORNOT2(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src1, struct
-    STRUCTNAME *src2);

-
BIT_AND(const
-    SETSIZE, struct
-    STRUCTNAME *dst, struct
-    STRUCTNAME *src);

-
BIT_AND2(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src1, struct
-    STRUCTNAME *src2);

-
BIT_ANDNOT(const
-    SETSIZE, struct
-    STRUCTNAME *dst, struct
-    STRUCTNAME *src);

-
BIT_ANDNOT2(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src1, struct
-    STRUCTNAME *src2);

-
BIT_XOR(const
-    SETSIZE, struct
-    STRUCTNAME *dst, struct
-    STRUCTNAME *src);

-
BIT_XOR2(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src1, struct
-    STRUCTNAME *src2);

-
BIT_CLR_ATOMIC(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
BIT_SET_ATOMIC(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
BIT_SET_ATOMIC_ACQ(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
bool
-  

-  BIT_TEST_SET_ATOMIC(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
bool
-  

-  BIT_TEST_CLR_ATOMIC(const
-    SETSIZE, size_t
-    bit, struct STRUCTNAME
-    *bitset);

-
BIT_AND_ATOMIC(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src);

-
BIT_OR_ATOMIC(const
-    SETSIZE, struct STRUCTNAME *dst,
-    struct STRUCTNAME *src);

-
BIT_COPY_STORE_REL(const
-    SETSIZE, struct STRUCTNAME *from,
-    struct STRUCTNAME *to);

-
#define _WANT_FREEBSD_BITSET

-

-

-

-
The bitset(9) family of macros provide a
-    flexible and efficient bitset implementation if the maximum size of the set
-    is known at compilation. Throughout this manual page, the name
-    SETSIZE refers to the size of the bitset in bits.
-    Individual bits in bitsets are referenced with indices zero through
-    SETSIZE - 1. One example use of
-    <sys/bitset.h> is
-    <sys/cpuset.h>.

-
These macros are meant to be used in the kernel and are visible if
-    _KERNEL is defined when
-    <sys/_bitset.h> or
-    <sys/bitset.h> are included
-    in a program. Userland programs must define
-    _WANT_FREEBSD_BITSET before including these files to
-    make the macros visible.

-
The
-    ()
-    macro defines a bitset struct STRUCTNAME with room to
-    represent SETSIZE bits.

-
The
-    ()
-    macro allows one to initialize a bitset struct with a compile time literal
-    value.

-
The
-    ()
-    macro generates a compile time literal, usable by
-    BITSET_T_INITIALIZER(), representing a full bitset
-    (all bits set). For examples of
-    BITSET_T_INITIALIZER() and
-    BITSET_FSET() usage, see the
-    BITSET_T_INITIALIZER
-    EXAMPLE section. The N_WORDS parameter to
-    BITSET_FSET() should be:

-

-
__bitset_words(SETSIZE)

-

-
The
-    ()
-    macro clears bit bit in the bitset pointed to by
-    bitset. The
-    ()
-    macro is identical, but the bit is cleared atomically. The
-    ()
-    macro atomically clears the bit and returns whether it was set.

-
The
-    ()
-    macro copies the contents of the bitset from to the
-    bitset to.
-    ()
-    is similar, but copies component machine words from
-    from and writes them to to with
-    atomic store with release semantics. (That is, if to
-    is composed of multiple machine words,
-    BIT_COPY_STORE_REL() performs multiple individually
-    atomic operations.)

-
The
-    ()
-    macro returns true if the bit
-    bit in the bitset pointed to by
-    bitset is set.

-
The
-    ()
-    macro sets bit bit in the bitset pointed to by
-    bitset. The
-    ()
-    macro is identical, but the bit is set atomically. The
-    ()
-    macro sets the bit with acquire semantics. The
-    ()
-    macro atomically sets the bit and returns whether it was set.

-
The
-    ()
-    macro clears all bits in bitset.

-
The
-    ()
-    macro sets all bits in bitset.

-
The
-    ()
-    macro clears all bits in bitset before setting only
-    bit bit.

-
The
-    ()
-    macro returns true if bitset
-    is empty.

-
The
-    ()
-    macro returns true if bitset
-    is full (all bits set).

-
The
-    ()
-    macro returns the 1-index of the first (lowest) set bit in
-    bitset, or zero if bitset is
-    empty. Like with ffs(3), to use the non-zero result of
-    BIT_FFS() as a bit index
-    parameter to any other bitset(9) macro, you must
-    subtract one from the result.

-
The
-    ()
-    macro returns the 1-index of the first (lowest) set bit in
-    bitset, which is greater than the given 1-indexed
-    start, or zero if no bits in
-    bitset greater than start are
-    set.

-
The
-    ()
-    macro returns the 1-index of the last (highest) set bit in
-    bitset, or zero if bitset is
-    empty. Like with fls(3), to use the non-zero result of
-    BIT_FLS() as a bit index
-    parameter to any other bitset(9) macro, you must
-    subtract one from the result.

-
The
-    ()
-    macro can be used to iterate over all set bits in
-    bitset. The index variable bit
-    must have been declared with type int, and upon each
-    iteration bit is set to the index of successive set
-    bits. The value of bit after the loop terminates is
-    undefined. Similarly,
-    ()
-    iterates over all clear bits in bitset. In the loop
-    body, the currently indexed bit may be set or cleared. However, setting or
-    clearing bits other than the currently indexed bit does not guarantee that
-    they will or will not be returned in subsequent iterations of the same
-  loop.

-
The
-    ()
-    macro returns the total number of set bits in
-  bitset.

-
The
-    ()
-    macro returns true if needle
-    is a subset of haystack.

-
The
-    ()
-    macro returns true if bitset1
-    and bitset2 have any common bits. (That is, if
-    bitset1 AND bitset2 is not the
-    empty set.)

-
The
-    ()
-    macro returns true if bitset1
-    is NOT equal to bitset2.

-
The
-    ()
-    macro sets bits present in src in
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst |=
-    src.)
-    ()
-    is similar, but sets bits in the component machine words in
-    dst atomically. (That is, if dst
-    is composed of multiple machine words,
-    BIT_OR_ATOMIC() performs multiple individually
-    atomic operations.)

-
The
-    ()
-    macro computes src1 bitwise or
-    src2 and assigns the result to
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst =
-    src1 | src2.)

-
The
-    ()
-    macro sets bits not in src in
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst |= ~
-    src.)

-
The
-    ()
-    macro computes src1 bitwise or not
-    src2 and assigns the result to
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst =
-    src1 | ~ src2.)

-
The
-    ()
-    macro clears bits absent from src from
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst &=
-    src.)
-    ()
-    is similar, with the same atomic semantics as
-    BIT_OR_ATOMIC().

-
The
-    ()
-    macro computes src1 bitwise and
-    src2 and assigns the result to
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst =
-    src1 & src2.)

-
The
-    ()
-    macro clears bits set in src from
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst &= ~
-    src.)

-
The
-    ()
-    macro computes src1 bitwise and not
-    src2 and assigns the result to
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst =
-    src1 & ~ src2.)

-
The
-    ()
-    macro toggles bits set in src in
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst ^=
-    src.)

-
The
-    ()
-    macro computes src1 bitwise exclusive or
-    src2 and assigns the result to
-    dst. (It is the bitset(9)
-    equivalent of the scalar: dst =
-    src1 ^ src2.)

-

-

-

-

-
BITSET_DEFINE(_myset, MYSETSIZE);
-
-struct _myset myset;
-
-/* Initialize myset to filled (all bits set) */
-myset = BITSET_T_INITIALIZER(BITSET_FSET(__bitset_words(MYSETSIZE)));
-
-/* Initialize myset to only the lowest bit set */
-myset = BITSET_T_INITIALIZER(0x1);

-

-

-

-

-
bitstring(3), cpuset(9)

-

-

-

-
The bitset(9) macros first appeared in
-    FreeBSD 10.0 in January 2014. They were MFCed to
-    FreeBSD 9.3, released in July 2014.

-
This manual page first appeared in FreeBSD
-    11.0.

-

-

-

-
The bitset(9) macros were generalized and
-    pulled out of <sys/cpuset.h>
-    as <sys/_bitset.h> and
-    <sys/bitset.h> by
-    Attilio Rao
-    <attilio@FreeBSD.org>.
-    This manual page was written by Conrad Meyer
-    <cem@FreeBSD.org>.

-

-

-

-
The SETSIZE argument to all of these macros
-    must match the value given to BITSET_DEFINE().

-
Unlike every other reference to individual set members, which are
-    zero-indexed, BIT_FFS(),
-    BIT_FFS_AT() and BIT_FLS()
-    return a one-indexed result (or zero if the set is empty).

-
In order to use the macros defined in
-    <sys/bitset.h> and
-    <sys/_bitset.h> in userland
-    programs, _WANT_FREEBSD_BITSET has to be defined
-    before including the header files. This requirements exists to prevent a
-    name space pollution due to macros defined in
-    bitset(9) in programs that include
-    <sys/cpuset.h> or
-    <sched.h>.

-

-

-
-  
-    
-    
-  
-
September 20, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/bpf.9 3.html b/static/freebsd/man9/bpf.9 3.html
deleted file mode 100644
index 57031e64..00000000
--- a/static/freebsd/man9/bpf.9 3.html	
+++ /dev/null
@@ -1,196 +0,0 @@
-
-  
-    
-    
-    
-  
-
BPF(9)Kernel Developer's ManualBPF(9)

-

-

-

-
bpf — Berkeley
-    Packet Filter

-

-

-

-
#include
-    <net/bpf.h>

-
void
-  

-  bpfattach(struct
-    ifnet *ifp, u_int
-    dlt, u_int
-  hdrlen);

-
void
-  

-  bpfattach2(struct ifnet *ifp,
-    u_int dlt, u_int hdrlen,
-    struct bpf_if **driverp);

-
void
-  

-  bpfdetach(struct
-    ifnet *ifp);

-
void
-  

-  bpf_tap(struct
-    ifnet *ifp, u_char
-    *pkt, u_int
-    *pktlen);

-
void
-  

-  bpf_mtap(struct
-    ifnet *ifp, struct mbuf
-    *m);

-
void
-  

-  bpf_mtap2(struct
-    bpf_if *bp, void
-    *data, u_int dlen,
-    struct mbuf *m);

-
u_int
-  

-  bpf_filter(const struct bpf_insn *pc
-    , u_char *pkt, u_int
-    wirelen, u_int buflen);

-
int
-  

-  bpf_validate(const
-    struct bpf_insn *fcode,
-    int flen);

-

-

-

-
The Berkeley Packet Filter provides a raw interface, that is
-    protocol independent, to data link layers. It allows all packets on the
-    network, even those destined for other hosts, to be passed from a network
-    interface to user programs. Each program may specify a filter, in the form
-    of a bpf filter machine program. The
-    bpf(4) manual page describes the interface used by user
-    programs. This manual page describes the functions used by interfaces to
-    pass packets to bpf and the functions for testing
-    and running bpf filter machine programs.

-
The
-    ()
-    function attaches a network interface to bpf. The
-    ifp argument is a pointer to the structure that
-    defines the interface to be attached to an interface. The
-    dlt argument is the data link-layer type:
-    DLT_NULL (no link-layer encapsulation),
-    DLT_EN10MB (Ethernet),
-    DLT_IEEE802_11 (802.11 wireless networks), etc. The
-    rest of the link layer types can be found in
-    <net/bpf.h>. The
-    hdrlen argument is the fixed size of the link header;
-    variable length headers are not yet supported. The
-    bpf system will hold a pointer to
-    ifp->if_bpf. This variable will set to a
-    non-NULL value when bpf
-    requires packets from this interface to be tapped using the functions
-  below.

-
The
-    ()
-    function allows multiple bpf instances to be
-    attached to a single interface, by registering an explicit
-    if_bpf rather than using
-    ifp->if_bpf. It is then possible to run
-    tcpdump(1) on the interface for any data link-layer types
-    attached.

-
The
-    ()
-    function detaches a bpf instance from an interface,
-    specified by ifp. The
-    bpfdetach() function should be called once for each
-    bpf instance attached.

-
The
-    ()
-    function is used by an interface to pass the packet to
-    bpf. The packet data (including link-header),
-    pointed to by pkt, is of length
-    pktlen, which must be a contiguous buffer. The
-    ifp argument is a pointer to the structure that
-    defines the interface to be tapped. The packet is parsed by each processes
-    filter, and if accepted, it is buffered for the process to read.

-
The
-    ()
-    function is like bpf_tap() except that it is used to
-    tap packets that are in an mbuf chain,
-    m. The ifp argument is a pointer
-    to the structure that defines the interface to be tapped. Like
-    bpf_tap(), bpf_mtap()
-    requires a link-header for whatever data link layer type is specified. Note
-    that bpf only reads from the
-    mbuf chain, it does not free it or keep a pointer to
-    it. This means that an mbuf containing the link-header
-    can be prepended to the chain if necessary. A cleaner interface to achieve
-    this is provided by bpf_mtap2().

-
The
-    ()
-    function allows the user to pass a link-header data,
-    of length dlen, independent of the
-    mbuf m, containing the packet.
-    This simplifies the passing of some link-headers.

-
The
-    ()
-    function executes the filter program starting at pc on
-    the packet pkt. The wirelen
-    argument is the length of the original packet and
-    buflen is the amount of data present. The
-    buflen value of 0 is special; it indicates that the
-    pkt is actually a pointer to an mbuf chain
-    (struct mbuf *).

-
The
-    ()
-    function checks that the filter code fcode, of length
-    flen, is valid.

-

-

-

-
The bpf_filter() function returns -1 (cast
-    to an unsigned integer) if there is no filter. Otherwise, it returns the
-    result of the filter program.

-
The bpf_validate() function returns 0 when
-    the program is not a valid filter program.

-

-

-

-
bpf invokes
-    bpf_track EVENTHANDLER(9) event each
-    time listener attaches to or detaches from an interface. Pointer to
-    (struct ifnet *) is passed as the first argument,
-    interface dlt follows. Last argument indicates
-    listener is attached (1) or detached (0). Note that handler is invoked with
-    bpf global lock held, which implies restriction on
-    sleeping and calling bpf subsystem inside
-    EVENTHANDLER(9) dispatcher. Note that handler is not
-    called for write-only listeners.

-

-

-

-
tcpdump(1), bpf(4),
-    EVENTHANDLER(9)

-

-

-

-
The Enet packet filter was created in 1980 by Mike Accetta and
-    Rick Rashid at Carnegie-Mellon University. Jeffrey Mogul, at Stanford,
-    ported the code to BSD and continued its development
-    from 1983 on. Since then, it has evolved into the Ultrix Packet Filter at
-    DEC, a STREAMS NIT module under SunOS 4.1, and BPF.

-

-

-

-
Steven McCanne, of Lawrence Berkeley
-    Laboratory, implemented BPF in Summer 1990. Much of the design is due to
-    Van Jacobson. This manpage was written by
-    Orla McGann.

-

-

-
-  
-    
-    
-  
-
May 11, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/buf.9 3.html b/static/freebsd/man9/buf.9 3.html
deleted file mode 100644
index c441c3b4..00000000
--- a/static/freebsd/man9/buf.9 3.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUF(9)Kernel Developer's ManualBUF(9)

-

-

-

-
buf — kernel
-    buffer I/O scheme used in FreeBSD VM system

-

-

-

-
The kernel implements a KVM abstraction of the buffer cache which
-    allows it to map potentially disparate vm_page's into contiguous KVM for use
-    by (mainly file system) devices and device I/O. This abstraction supports
-    block sizes from DEV_BSIZE (usually 512) to upwards
-    of several pages or more. It also supports a relatively primitive
-    byte-granular valid range and dirty range currently hardcoded for use by
-    NFS. The code implementing the VM Buffer abstraction is mostly concentrated
-    in sys/kern/vfs_bio.c in the
-    FreeBSD source tree.

-
One of the most important things to remember when
-    dealing with buffer pointers (struct buf) is that the
-    underlying pages are mapped directly from the buffer cache. No data copying
-    occurs in the scheme proper, though some file systems such as UFS do have to
-    copy a little when dealing with file fragments. The second most important
-    thing to remember is that due to the underlying page mapping, the
-    b_data base pointer in a buf is always
-    -aligned, not
-    -aligned.
-    When you have a VM buffer representing some b_offset
-    and b_size, the actual start of the buffer is
-    ‘b_data + (b_offset & PAGE_MASK)’
-    and not just ‘b_data’. Finally, the VM
-    system's core buffer cache supports valid and dirty bits
-    (m->valid, m->dirty) for
-    pages in DEV_BSIZE chunks. Thus a platform with a
-    hardware page size of 4096 bytes has 8 valid and 8 dirty bits. These bits
-    are generally set and cleared in groups based on the device block size of
-    the device backing the page. Complete page's worth are often referred to
-    using the VM_PAGE_BITS_ALL bitmask (i.e., 0xFF if
-    the hardware page size is 4096).

-
VM buffers also keep track of a byte-granular dirty range and
-    valid range. This feature is normally only used by the NFS subsystem. I am
-    not sure why it is used at all, actually, since we have
-    DEV_BSIZE valid/dirty granularity within the VM
-    buffer. If a buffer dirty operation creates a “hole”, the
-    dirty range will extend to cover the hole. If a buffer validation operation
-    creates a “hole” the byte-granular valid range is left alone
-    and will not take into account the new extension. Thus the whole
-    byte-granular abstraction is considered a bad hack and it would be nice if
-    we could get rid of it completely.

-
A VM buffer is capable of mapping the underlying VM cache pages
-    into KVM in order to allow the kernel to directly manipulate the data
-    associated with the (vnode,
-    b_offset, b_size). The kernel
-    typically unmaps VM buffers the moment they are no longer needed but often
-    keeps the struct buf structure instantiated and even
-    bp->b_pages array instantiated despite having
-    unmapped them from KVM. If a page making up a VM buffer is about to undergo
-    I/O, the system typically unmaps it from KVM and replaces the page in the
-    b_pages[] array with a place-marker called bogus_page.
-    The place-marker forces any kernel subsystems referencing the associated
-    struct buf to re-lookup the associated page. I believe
-    the place-marker hack is used to allow sophisticated devices such as file
-    system devices to remap underlying pages in order to deal with, for example,
-    re-mapping a file fragment into a file block.

-
VM buffers are used to track I/O operations within the kernel.
-    Unfortunately, the I/O implementation is also somewhat of a hack because the
-    kernel wants to clear the dirty bit on the underlying pages the moment it
-    queues the I/O to the VFS device, not when the physical I/O is actually
-    initiated. This can create confusion within file system devices that use
-    delayed-writes because you wind up with pages marked clean that are actually
-    still dirty. If not treated carefully, these pages could be thrown away!
-    Indeed, a number of serious bugs related to this hack were not fixed until
-    the FreeBSD 2.2.8 / FreeBSD
-    3.0 release. The kernel uses an instantiated VM buffer (i.e.,
-    struct buf) to place-mark pages in this special state.
-    The buffer is typically flagged B_DELWRI. When a
-    device no longer needs a buffer it typically flags it as
-    B_RELBUF. Due to the underlying pages being marked
-    clean, the ‘B_DELWRI|B_RELBUF’
-    combination must be interpreted to mean that the buffer is still actually
-    dirty and must be written to its backing store before it can actually be
-    released. In the case where B_DELWRI is not set, the
-    underlying dirty pages are still properly marked as dirty and the buffer can
-    be completely freed without losing that clean/dirty state information. (XXX
-    do we have to check other flags in regards to this situation ???)

-
The kernel reserves a portion of its KVM space to hold VM Buffer's
-    data maps. Even though this is virtual space (since the buffers are mapped
-    from the buffer cache), we cannot make it arbitrarily large because
-    instantiated VM Buffers (struct buf's) prevent their
-    underlying pages in the buffer cache from being freed. This can complicate
-    the life of the paging system.

-

-

-

-
The buf manual page was originally written
-    by Matthew Dillon and first appeared in
-    FreeBSD 3.1, December 1998.

-

-

-
-  
-    
-    
-  
-
December 22, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/buf_ring.9 3.html b/static/freebsd/man9/buf_ring.9 3.html
deleted file mode 100644
index b7aed8b2..00000000
--- a/static/freebsd/man9/buf_ring.9 3.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUF_RING(9)Kernel Developer's ManualBUF_RING(9)

-

-

-

-
buf_ring,
-    buf_ring_alloc,
-    buf_ring_free,
-    buf_ring_enqueue,
-    buf_ring_dequeue_mc,
-    buf_ring_dequeue_sc,
-    buf_ring_count,
-    buf_ring_empty,
-    buf_ring_full, buf_ring_peek
-    — multi-producer, {single, multi}-consumer lock-less
-    ring buffer

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/buf_ring.h>

-
struct buf_ring *
-  

-  buf_ring_alloc(int
-    count, struct malloc_type
-    *type, int flags,
-    struct mtx *sc_lock);

-
void
-  

-  buf_ring_free(struct
-    buf_ring *br, struct
-    malloc_type *type);

-
int
-  

-  buf_ring_enqueue(struct
-    buf_ring *br, void
-    *buf);

-
void *
-  

-  buf_ring_dequeue_mc(struct
-    buf_ring *br);

-
void *
-  

-  buf_ring_dequeue_sc(struct
-    buf_ring *br);

-
int
-  

-  buf_ring_count(struct
-    buf_ring *br);

-
int
-  

-  buf_ring_empty(struct
-    buf_ring *br);

-
int
-  

-  buf_ring_full(struct
-    buf_ring *br);

-
void *
-  

-  buf_ring_peek(struct
-    buf_ring *br);

-

-

-

-
The buf_ring functions provide a lock-less
-    multi-producer and lock-less multi-consumer as well as single-consumer ring
-    buffer.

-
The
-    ()
-    function is used to allocate a buf_ring ring buffer with
-    count slots using malloc_type
-    type and memory flags flags. The
-    single consumer interface is protected by sc_lock.

-
The
-    ()
-    function is used to free a buf_ring. The user is responsible for freeing any
-    enqueued items.

-
The
-    ()
-    function is used to enqueue a buffer to a buf_ring.

-
The
-    ()
-    function is a multi-consumer safe way of dequeueing elements from a
-    buf_ring.

-
The
-    ()
-    function is a single-consumer interface to dequeue elements - requiring the
-    user to serialize accesses with a lock.

-
The
-    ()
-    function returns the number of elements in a buf_ring.

-
The
-    ()
-    function returns TRUE if the buf_ring is empty,
-    FALSE otherwise.

-
The
-    ()
-    function returns TRUE if no more items can be
-    enqueued, FALSE otherwise.

-
The
-    ()
-    function returns a pointer to the last element in the buf_ring if the
-    buf_ring is not empty, NULL otherwise.

-

-

-

-
The buf_ring_enqueue() function return
-    ENOBUFS if there are no available slots in the
-    buf_ring.

-

-

-

-
These functions were introduced in FreeBSD
-    8.0.

-

-

-
-  
-    
-    
-  
-
September 27, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_activate_resource.9 3.html b/static/freebsd/man9/bus_activate_resource.9 3.html
deleted file mode 100644
index e9e89e4c..00000000
--- a/static/freebsd/man9/bus_activate_resource.9 3.html	
+++ /dev/null
@@ -1,115 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_ACTIVATE_RESOURCE(9)Kernel Developer's ManualBUS_ACTIVATE_RESOURCE(9)

-

-

-

-
bus_activate_resource,
-    bus_deactivate_resource —
-    activate or deactivate a resource

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
int
-  

-  bus_activate_resource(device_t
-    dev, struct resource *r);

-
int
-  

-  bus_deactivate_resource(device_t
-    dev, struct resource *r);

-

-

-

-
These functions activate or deactivate a previously allocated
-    resource. In general, resources must be activated before they can be
-    accessed by the driver. Bus drivers may perform additional actions to ensure
-    that the resource is ready to be accessed. For example, the PCI bus driver
-    enables memory decoding in a PCI device's command register when activating a
-    memory resource.

-
The arguments are as follows:

-

-  
dev

-  
The device that requests ownership of the resource. Before allocation, the
-      resource is owned by the parent bus.

-  
r

-  
A pointer to the struct resource returned by
-      bus_alloc_resource(9).

-

-

-

-
Resources which can be mapped for CPU access by a
-    bus_space(9) tag and handle will create a mapping of the
-    entire resource when activated. The tag and handle for this mapping are
-    stored in r and can be retrieved via
-    rman_get_bustag(9) and
-    rman_get_bushandle(9). These can be used with the
-    bus_space(9) API to access device registers or memory
-    described by r. If the mapping is associated with a
-    virtual address, the virtual address can be retrieved via
-    rman_get_virtual(9).

-
This implicit mapping can be disabled by passing the
-    RF_UNMAPPED flag to
-    bus_alloc_resource(9). A driver may use this if it wishes
-    to allocate its own mappings of a resource using
-    bus_map_resource(9).

-
A wrapper API for bus_space(9)
-    is also provided that accepts the associated resource as the first argument
-    in place of the bus_space(9) tag and handle. The functions
-    in this wrapper API are named similarly to the
-    bus_space(9) API except that “_space” is
-    removed from their name. For example,
-    ()
-    can be used in place of
-    ().
-    The wrapper API is preferred in new drivers.

-
These two statements both read a 32-bit register at the start of a
-    resource:

-

-
	bus_space_read_4(rman_get_bustag(res), rman_get_bushandle(res), 0);
-	bus_read_4(res, 0);

-

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
bus_alloc_resource(9),
-    bus_map_resource(9), bus_space(9),
-    device(9), driver(9)

-

-

-

-
This manual page was written by Warner
-    Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 13, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_adjust_resource.9 4.html b/static/freebsd/man9/bus_adjust_resource.9 4.html
deleted file mode 100644
index b3ec2d7b..00000000
--- a/static/freebsd/man9/bus_adjust_resource.9 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_ADJUST_RESOURCE(9)Kernel Developer's ManualBUS_ADJUST_RESOURCE(9)

-

-

-

-
bus_adjust_resource —
-    adjust resource allocated from a parent bus

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
int
-  

-  bus_adjust_resource(device_t
-    dev, struct resource *r,
-    rman_res_t start, rman_res_t
-    end);

-

-

-

-
This function is used to ask the parent bus to adjust the resource
-    range assigned to an allocated resource. The resource
-    r should have been allocated by a previous call to
-    bus_alloc_resource(9). The new resource range must overlap
-    the existing range of r.

-
Note that none of the constraints of the
-    original allocation request such as alignment or boundary restrictions are
-    checked by
-    ().
-    It is the caller's responsibility to enforce any such requirements.

-

-

-

-
The bus_adjust_resource() method returns
-    zero on success or an error code on failure.

-

-

-

-
Grow an existing memory resource by 4096 bytes.

-

-
	struct resource *res;
-	int error;
-
-	error = bus_adjust_resource(dev, res, rman_get_start(res),
-	    rman_get_end(res) + 0x1000);

-

-

-

-

-
bus_adjust_resource() will fail if:

-

-  
[]

-  
The dev device does not have a parent device.

-  
[]

-  
The r resource is a shared resource.

-  
[]

-  
The new address range does not overlap with the existing address range of
-      r.

-  
[]

-  
The new address range conflicts with another allocated resource.

-

-

-

-

-
bus_alloc_resource(9),
-    bus_release_resource(9), device(9),
-    driver(9)

-

-

-
-  
-    
-    
-  
-
March 13, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_alloc_resource.9 3.html b/static/freebsd/man9/bus_alloc_resource.9 3.html
deleted file mode 100644
index 9f42e4da..00000000
--- a/static/freebsd/man9/bus_alloc_resource.9 3.html	
+++ /dev/null
@@ -1,168 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_ALLOC_RESOURCE(9)Kernel Developer's ManualBUS_ALLOC_RESOURCE(9)

-

-

-

-
bus_alloc_resource,
-    bus_alloc_resource_any,
-    bus_alloc_resource_anywhere —
-    allocate resources from a parent bus

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
struct resource *
-  

-  bus_alloc_resource(device_t dev,
-    int type, int rid,
-    rman_res_t start, rman_res_t
-    end, rman_res_t count, u_int
-    flags);

-
struct resource *
-  

-  bus_alloc_resource_any(device_t
-    dev, int type,
-    int rid,
-    u_int flags);

-
struct resource *
-  

-  bus_alloc_resource_anywhere(device_t
-    dev, int type, int rid,
-    rman_res_t count, u_int
-  flags);

-

-

-

-
This is an easy interface to the resource-management functions. It
-    hides the indirection through the parent's method table. This function
-    generally should be called in attach, but (except in some rare cases) never
-    earlier.

-
The
-    ()
-    and
-    ()
-    functions are convenience wrappers for
-    ().
-    bus_alloc_resource_any() sets
-    start, end, and
-    count to the default resource (see description of
-    start below).
-    bus_alloc_resource_anywhere() sets
-    start and end to the default
-    resource and uses the provided count argument.

-
The arguments are as follows:

-
    
-  
  • dev is the device that requests ownership of the
-      resource. Before allocation, the resource is owned by the parent bus.
    • 
-  
  • type is the type of resource you want to allocate.
-      It is one of:
-    
    
-      
    
-      
    for PCI bus numbers
    
-      
    
-      
    for IRQs
    
-      
    
-      
    for ISA DMA lines
    
-      
    
-      
    for I/O ports
    
-      
    
-      
    for I/O memory
    
-    
    
-  
    • 
-  
  • rid is a bus specific handle that identifies the
-      resource being allocated. For ISA this is an index into an array of
-      resources that have been setup for this device by either the PnP
-      mechanism, or via the hints mechanism. For PCCARD, this is an index into
-      the array of resources described by the PC Card's CIS entry. For PCI, the
-      offset into PCI config space which has the BAR to use to access the
-      resource.
    • 
-  
  • start and end are the
-      start/end addresses of the resource. If you specify values of 0ul for
-      start and ~0ul for end and 1
-      for count, the default values for the bus are
-      calculated.
    • 
-  
  • count is the size of the resource. For example, the
-      size of an I/O port is usually 1 byte (but some devices override this). If
-      you specified the default values for start and
-      end, then the default value of the bus is used if
-      count is smaller than the default value and
-      count is used, if it is bigger than the default
-      value.
    • 
-  
  • flags sets the flags for the resource. You can set
-      zero or more of these flags:
-    
    
-      
    
-      
    activate resource atomically.
    
-      
    
-      
    resource is prefetchable.
    
-      
    
-      
    resource permits contemporaneous sharing. It should always be set
-          unless you know that the resource cannot be shared. It is the bus
-          driver's task to filter out the flag if the bus does not support
-          sharing.
    
-      
    
-      
    do not establish implicit mapping when activated via
-          bus_activate_resource(9).
    
-    
    
-  
    • 
-

-

-

-

-
A pointer to struct resource is returned on
-    success, a null pointer otherwise.

-

-

-

-
This is some example code that allocates a 32 byte I/O port range
-    and an IRQ.

-

-
	struct resource *portres, *irqres;
-
-	portres = bus_alloc_resource(dev, SYS_RES_IOPORT, 0,
-			0ul, ~0ul, 32, RF_ACTIVE);
-	irqres = bus_alloc_resource_any(dev, SYS_RES_IRQ, 0,
-			RF_ACTIVE | RF_SHAREABLE);

-

-

-

-

-
bus_activate_resource(9),
-    bus_adjust_resource(9),
-    bus_map_resource(9),
-    bus_release_resource(9), device(9),
-    driver(9)

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@big.endian.de>
-    with parts by Warner Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 6, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_attach_children.9 3.html b/static/freebsd/man9/bus_attach_children.9 3.html
deleted file mode 100644
index 18344241..00000000
--- a/static/freebsd/man9/bus_attach_children.9 3.html	
+++ /dev/null
@@ -1,138 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_ATTACH_CHILDREN(9)Kernel Developer's ManualBUS_ATTACH_CHILDREN(9)

-

-

-

-
bus_attach_children,
-    bus_delayed_attach_children,
-    bus_detach_children,
-    bus_enumerate_hinted_children,
-    bus_identify_children —
-    manage child devices of a bus device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  bus_attach_children(device_t
-    dev);

-
void
-  

-  bus_delayed_attach_children(device_t
-    bus);

-
int
-  

-  bus_detach_children(device_t
-    dev);

-
void
-  

-  bus_enumerate_hinted_children(device_t
-    bus);

-
void
-  

-  bus_identify_children(device_t
-    dev);

-

-

-

-
These functions manage state transitions of child devices for
-    dev.

-
()
-    walks the kernel environment to identify any device hints that describe a
-    device attached to dev. For each set of matching
-    hints, the BUS_HINTED_CHILD(9) method is invoked. This
-    function is typically called from a bus driver's
-    DEVICE_ATTACH(9) method to add hinted devices. Note that
-    most bus drivers do not use hints to identify child devices. This is
-    typically used for legacy buses such as ISA that do not provide a mechanism
-    for enumerating devices.

-
()
-    iterates over all eligible device drivers for children of
-    dev invoking the DEVICE_IDENTIFY(9)
-    method. This allows device drivers to add child devices that are enumerated
-    via alternate mechanisms such as firmware tables. This function is typically
-    called from a bus driver's DEVICE_ATTACH(9) method.

-
()
-    attaches device drivers to all children of dev. This
-    function invokes device_probe_and_attach(9) on each child
-    device ignoring errors. It makes a best-effort pass to attach device drivers
-    to all children. Child devices are attached in increasing order. Child
-    devices with the same order are attached in FIFO order based on the time
-    when the device was created via device_add_child(9). This
-    function is typically called from a bus driver's
-    DEVICE_ATTACH(9) method after adding devices.

-
()
-    attaches device drivers to all children of dev after
-    interrupts are enabled. This function schedules a call to
-    bus_attach_children() after interrupts are enabled
-    via config_intrhook_establish(9). If interrupts are
-    already enabled (for example, when loading a device driver after booting),
-    bus_attach_children() is called immediately.

-
()
-    detaches device drivers from all children of dev by
-    calling device_detach(9) on each child device. Unlike
-    bus_attach_children(), this function does not make a
-    best-effort pass. If a child device fails to detach,
-    bus_detach_children() immediately fails returning
-    the error from the child's failed detach. Child devices are detached in
-    reverse order compared to bus_attach_children().
-    That is, child devices are detached in decreasing order, and child devices
-    with the same order are detached in LIFO order. Detached devices are not
-    deleted.

-
()
-    is typically called at the start of a bus driver's
-    DEVICE_DETACH(9) method to give child devices a chance to
-    veto the detach request. It is usually paired with a later call to
-    (9)
-    to delete child devices. If no additional logic is required between the two
-    function calls, a bus driver can use bus_generic_detach(9)
-    to detach and delete children.

-

-

-

-

-

-

-
config_intrhook_establish(9),
-    device_add_child(9), DEVICE_ATTACH(9),
-    device_delete_children(9),
-    DEVICE_DETACH(9), device_detach(9),
-    DEVICE_IDENTIFY(9),
-    device_probe_and_attach(9)

-

-

-

-
bus_enumerate_hinted_children() first
-    appeared in FreeBSD 6.2.

-
bus_delayed_attach_children() first
-    appeared in FreeBSD 12.2.

-
bus_identify_children() first appeared in
-    FreeBSD 15.0. Its functionality is available in
-    older releases via the deprecated
-    bus_generic_probe().

-
bus_attach_children() first appeared in
-    FreeBSD 15.0. Its functionality is available in
-    older releases via the deprecated
-    bus_generic_attach().

-
bus_detach_children() first appeared in
-    FreeBSD 15.0. Its functionality is available in
-    older releases via bus_generic_detach().

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_child_present.9 3.html b/static/freebsd/man9/bus_child_present.9 3.html
deleted file mode 100644
index ee1a643e..00000000
--- a/static/freebsd/man9/bus_child_present.9 3.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_CHILD_PRESENT(9)Kernel Developer's ManualBUS_CHILD_PRESENT(9)

-

-

-

-
bus_child_present —
-    ask the bus driver to see if this device is still really
-    present

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
int
-  

-  bus_child_present(device_t
-    dev);

-

-

-

-
The
-    ()
-    function requests that the parent device driver of dev
-    check to see if the hardware represented by dev is
-    still physically accessible at this time. While the notion of accessible
-    varies from bus to bus, generally hardware that is not accessible cannot be
-    accessed via the
-    ()
-    methods that would otherwise be used to access the device.

-
This does not ask the question “does this device have
-    children?” which can better be answered by
-    device_get_children(9).

-

-

-

-
A zero return value indicates that the device is not present in
-    the system. A non-zero return value indicates that the device is present in
-    the system, or that the state of the device cannot be determined.

-

-

-

-
This is some example code. It only calls stop when the
-    dc(4) device is actually present.

-

-
device_t dev;
-dc_softc *sc;
-
-sc = device_get_softc(dev);
-if (bus_child_present(dev))
-	dc_stop(sc);

-

-

-

-

-
device(9), driver(9)

-

-

-

-
This manual page was written by Warner
-    Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 27, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_dma.9 3.html b/static/freebsd/man9/bus_dma.9 3.html
deleted file mode 100644
index 06b5a960..00000000
--- a/static/freebsd/man9/bus_dma.9 3.html	
+++ /dev/null
@@ -1,1154 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_DMA(9)Kernel Developer's ManualBUS_DMA(9)

-

-

-

-
bus_dma,
-    bus_dma_tag_create,
-    bus_dma_tag_destroy,
-    bus_dma_template_init,
-    bus_dma_template_tag,
-    bus_dma_template_clone,
-    bus_dma_template_fill,
-    BUS_DMA_TEMPLATE_FILL,
-    bus_dmamap_create,
-    bus_dmamap_destroy,
-    bus_dmamap_load,
-    bus_dmamap_load_bio,
-    bus_dmamap_load_ccb,
-    bus_dmamap_load_crp,
-    bus_dmamap_load_crp_buffer,
-    bus_dmamap_load_mbuf,
-    bus_dmamap_load_mbuf_sg,
-    bus_dmamap_load_uio,
-    bus_dmamap_unload,
-    bus_dmamap_sync,
-    bus_dmamem_alloc,
-    bus_dmamem_free — Bus and
-    Machine Independent DMA Mapping Interface

-

-

-

-
#include
-    <machine/bus.h>

-
int
-  

-  bus_dma_tag_create(bus_dma_tag_t
-    parent, bus_size_t
-    alignment, bus_addr_t
-    boundary, bus_addr_t
-    lowaddr, bus_addr_t
-    highaddr,
-    bus_dma_filter_t
-    *filtfunc, void
-    *filtfuncarg, bus_size_t
-    maxsize, int
-    nsegments, bus_size_t
-    maxsegsz, int
-    flags, bus_dma_lock_t
-    *lockfunc, void
-    *lockfuncarg,
-    bus_dma_tag_t *dmat);

-
int
-  

-  bus_dma_tag_destroy(bus_dma_tag_t
-    dmat);

-
void
-  

-  bus_dma_template_init(bus_dma_template_t
-    *template, bus_dma_tag_t parent);

-
int
-  

-  bus_dma_template_tag(bus_dma_template_t
-    *template, bus_dma_tag_t *dmat);

-
void
-  

-  bus_dma_template_clone(bus_dma_template_t
-    *template, bus_dma_tag_t dmat);

-
void
-  

-  bus_dma_template_fill(bus_dma_template_t
-    *template, bus_dma_param_t params[],
-    u_int count);

-
BUS_DMA_TEMPLATE_FILL(bus_dma_template_t
-    *template, bus_dma_param_t param ...);

-
int
-  

-  bus_dmamap_create(bus_dma_tag_t
-    dmat, int flags,
-    bus_dmamap_t *mapp);

-
int
-  

-  bus_dmamap_destroy(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map);

-
int
-  

-  bus_dmamap_load(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, void *buf,
-    bus_size_t buflen,
-    bus_dmamap_callback_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
int
-  

-  bus_dmamap_load_bio(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, struct bio
-    *bio,
-    bus_dmamap_callback_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
int
-  

-  bus_dmamap_load_ccb(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, union ccb
-    *ccb,
-    bus_dmamap_callback_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
int
-  

-  bus_dmamap_load_crp(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, struct crypto
-    *crp,
-    bus_dmamap_callback_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
int
-  

-  bus_dmamap_load_crp_buffer(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, struct crypto_buffer
-    *cb,
-    bus_dmamap_callback_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
int
-  

-  bus_dmamap_load_mbuf(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, struct mbuf
-    *mbuf,
-    bus_dmamap_callback2_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
int
-  

-  bus_dmamap_load_mbuf_sg(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, struct mbuf
-    *mbuf, bus_dma_segment_t
-    *segs, int *nsegs,
-    int flags);

-
int
-  

-  bus_dmamap_load_uio(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, struct uio
-    *uio,
-    bus_dmamap_callback2_t
-    *callback, void
-    *callback_arg, int
-    flags);

-
void
-  

-  bus_dmamap_unload(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map);

-
void
-  

-  bus_dmamap_sync(bus_dma_tag_t
-    dmat, bus_dmamap_t
-    map, op);

-
int
-  

-  bus_dmamem_alloc(bus_dma_tag_t
-    dmat, void **vaddr,
-    int flags,
-    bus_dmamap_t *mapp);

-
void
-  

-  bus_dmamem_free(bus_dma_tag_t
-    dmat, void *vaddr,
-    bus_dmamap_t map);

-

-

-

-
Direct Memory Access (DMA) is a method of transferring data
-    without involving the CPU, thus providing higher performance. A DMA
-    transaction can be achieved between device to memory, device to device, or
-    memory to memory.

-
The bus_dma API is a bus, device, and
-    machine-independent (MI) interface to DMA mechanisms. It provides the client
-    with flexibility and simplicity by abstracting machine dependent issues like
-    setting up DMA mappings, handling cache issues, bus specific features and
-    limitations.

-

-

-

-
A tag structure (bus_dma_tag_t) is used to
-    describe the properties of a group of related DMA transactions. One way to
-    view this is that a tag describes the limitations of a DMA engine. For
-    example, if a DMA engine in a device is limited to 32-bit addresses, that
-    limitation is specified by a parameter when creating the tag for that
-    device. Similarly, a tag can be marked as requiring buffers whose addresses
-    are aligned to a specific boundary.

-
Some devices may require multiple tags to describe DMA
-    transactions with differing properties. For example, a device might require
-    16-byte alignment of its descriptor ring while permitting arbitrary
-    alignment of I/O buffers. In this case, the driver must create one tag for
-    the descriptor ring and a separate tag for I/O buffers. If a device has
-    restrictions that are common to all DMA transactions in addition to
-    restrictions that differ between unrelated groups of transactions, the
-    driver can first create a “parent” tag that describes the
-    common restrictions. The per-group tags can then inherit these restrictions
-    from this “parent” tag rather than having to list them
-    explicitly when creating the per-group tags.

-
A mapping structure (bus_dmamap_t)
-    represents a mapping of a memory region for DMA. On systems with I/O MMUs,
-    the mapping structure tracks any I/O MMU entries used by a request. For DMA
-    requests that require bounce pages, the mapping tracks the bounce pages
-    used.

-
To prepare for one or more DMA transactions,
-    a mapping must be bound to a memory region by calling one of the
-    ()
-    functions. These functions configure the mapping which can include
-    programming entries in an I/O MMU and/or allocating bounce pages. An output
-    of these functions (either directly or indirectly by invoking a callback
-    routine) is the list of scatter/gather address ranges a consumer can pass to
-    a DMA engine to access the memory region. When a mapping is no longer
-    needed, the mapping must be unloaded via
-    bus_dmamap_unload().

-
Before and after each DMA transaction,
-    ()
-    must be used to ensure that the correct data is used by the DMA engine and
-    the CPU. If a mapping uses bounce pages, the sync operations copy data
-    between the bounce pages and the memory region bound to the mapping. Sync
-    operations also handle architecture-specific details such as CPU cache
-    flushing and CPU memory operation ordering.

-

-

-

-
bus_dma handles two types of DMA
-    transactions: static and dynamic. Static transactions are used with a
-    long-lived memory region that is reused for many transactions such as a
-    descriptor ring. Dynamic transactions are used for transfers to or from
-    transient buffers such as I/O buffers holding a network packet or disk
-    block. Each transaction type uses a different subset of the
-    bus_dma API.

-

-

-
Static transactions use memory regions allocated by
-    bus_dma. Each static memory region is allocated by
-    calling bus_dmamem_alloc(). This function requires a
-    valid tag describing the properties of the DMA transactions to this region
-    such as alignment or address restrictions. Multiple regions can share a
-    single tag if they share the same restrictions.

-
()
-    allocates a memory region along with a mapping object. The associated tag,
-    memory region, and mapping object must then be passed to
-    bus_dmamap_load() to bind the mapping to the
-    allocated region and obtain the scatter/gather list.

-
It is expected that
-    ()
-    will attempt to allocate memory requiring less expensive sync operations
-    (for example, implementations should not allocate regions requiring bounce
-    pages), but sync operations should still be used. For example, a driver
-    should use bus_dmamap_sync() in an interrupt handler
-    before reading descriptor ring entries written by the device prior to the
-    interrupt.

-
When a consumer is finished with a memory
-    region, it should unload the mapping via
-    ()
-    and then release the memory region and mapping object via
-    bus_dmamem_free().

-

-

-

-
Dynamic transactions map memory regions provided by other parts of
-    the system. A tag must be created via
-    bus_dma_tag_create() to describe the DMA
-    transactions to and from these memory regions, and a pool of mapping objects
-    must be allocated via bus_dmamap_create() to track
-    the mappings of any in-flight transactions.

-
When a consumer wishes to schedule a
-    transaction for a memory region, the consumer must first obtain an unused
-    mapping object from its pool of mapping objects. The memory region must be
-    bound to the mapping object via one of the
-    ()
-    functions. Before scheduling the transaction, the consumer should sync the
-    memory region via bus_dmamap_sync() with one or more
-    of the “PRE” flags. After the transaction has completed, the
-    consumer should sync the memory region via
-    bus_dmamap_sync() with one or more of the
-    “POST” flags. The mapping can then be unloaded via
-    bus_dmamap_unload(), and the mapping object can be
-    returned to the pool of unused mapping objects.

-
When a consumer is no longer scheduling
-    DMA transactions, the mapping objects should be freed via
-    (),
-    and the tag should be freed via
-    bus_dma_tag_destroy().

-

-

-

-

-

-  
bus_dma_tag_t

-  
A machine-dependent (MD) opaque type that describes the characteristics of
-      a group of DMA transactions. DMA tags are organized into a hierarchy, with
-      each child tag inheriting the restrictions of its parent. This allows all
-      devices along the path of DMA transactions to contribute to the
-      constraints of those transactions.

-  
bus_dma_template_t

-  
A template is a structure for creating a
-      bus_dma_tag_t from a set of defaults. Once
-      initialized with bus_dma_template_init(), a driver
-      can over-ride individual fields to suit its needs. The following fields
-      start with the indicated default values:
-    

-    
	alignment	1
-	boundary	0
-	lowaddr		BUS_SPACE_MAXADDR
-	highaddr	BUS_SPACE_MAXADDR
-	maxsize		BUS_SPACE_MAXSIZE
-	nsegments	BUS_SPACE_UNRESTRICTED
-	maxsegsize	BUS_SPACE_MAXSIZE
-	flags		0
-	lockfunc	NULL
-	lockfuncarg	NULL

-    

-    
Descriptions of each field are
-        documented with
-        ().
-        Note that the filtfunc and
-        filtfuncarg attributes of the DMA tag are not
-        supported with templates.

-  

-  
bus_dma_filter_t

-  
Client specified address filter having the format:
-    

-      
int

-      
(void
-          *filtarg, bus_addr_t testaddr)

-    

-    
Address filters can be specified during tag creation to allow
-        for devices whose DMA address restrictions cannot be specified by a
-        single window. The filtarg argument is specified
-        by the client during tag creation to be passed to all invocations of the
-        callback. The testaddr argument contains a
-        potential starting address of a DMA mapping. The filter function
-        operates on the set of addresses from testaddr to
-        ‘trunc_page(testaddr) + PAGE_SIZE -
-        1’, inclusive. The filter function should return zero if
-        any mapping in this range can be accommodated by the device and non-zero
-        otherwise.

-    

-  

-  
bus_dma_segment_t

-  
A machine-dependent type that describes individual DMA segments. It
-      contains the following fields:
-    

-    
	bus_addr_t	ds_addr;
-	bus_size_t	ds_len;

-    

-    
The ds_addr field contains the device
-        visible address of the DMA segment, and ds_len
-        contains the length of the DMA segment. Although the DMA segments
-        returned by a mapping call will adhere to all restrictions necessary for
-        a successful DMA operation, some conversion (e.g. a conversion from host
-        byte order to the device's byte order) is almost always required when
-        presenting segment information to the device.

-  

-  
bus_dmamap_t

-  
A machine-dependent opaque type describing an individual mapping. One map
-      is used for each memory allocation that will be loaded. Maps can be reused
-      once they have been unloaded. Multiple maps can be associated with one DMA
-      tag. While the value of the map may evaluate to
-      NULL on some platforms under certain conditions,
-      it should never be assumed that it will be NULL in
-      all cases.

-  
bus_dmamap_callback_t

-  
Client specified callback for receiving mapping information resulting from
-      the load of a bus_dmamap_t via
-      (),
-      bus_dmamap_load_bio(),
-      bus_dmamap_load_ccb(),
-      bus_dmamap_load_crp(), or
-      bus_dmamap_load_crp_buffer(). Callbacks are of the
-      format:
-    

-      
void

-      
(void
-          *callback_arg, bus_dma_segment_t *segs,
-          int nseg, int error)

-    

-    
The callback_arg is the callback
-        argument passed to dmamap load functions. The segs
-        and nseg arguments describe an array of
-        bus_dma_segment_t structures that represent the
-        mapping. This array is only valid within the scope of the callback
-        function. The success or failure of the mapping is indicated by the
-        error argument. More information on the use of
-        callbacks can be found in the description of the individual dmamap load
-        functions.

-  

-  
bus_dmamap_callback2_t

-  
Client specified callback for receiving mapping information resulting from
-      the load of a bus_dmamap_t via
-      ()
-      or
-      ().
-    
Callback2s are of the format:

-    

-      
void

-      
(void
-          *callback_arg, bus_dma_segment_t *segs,
-          int nseg, bus_size_t
-          mapsize, int error)

-    

-    
Callback2's behavior is the same as
-        bus_dmamap_callback_t with the addition that the
-        length of the data mapped is provided via
-      mapsize.

-  

-  
bus_dmasync_op_t

-  
Memory synchronization operation specifier. Bus DMA requires explicit
-      synchronization of memory with its device visible mapping in order to
-      guarantee memory coherency. The bus_dmasync_op_t
-      allows the type of DMA operation that will be or has been performed to be
-      communicated to the system so that the correct coherency measures are
-      taken. The operations are represented as bitfield flags that can be
-      combined together, though it only makes sense to combine PRE flags or POST
-      flags, not both. See the
-      ()
-      description below for more details on how to use these operations.
-    
All operations specified below are performed from the host
-        memory point of view, where a read implies data coming from the device
-        to the host memory, and a write implies data going from the host memory
-        to the device. Alternatively, the operations can be thought of in terms
-        of driver operations, where reading a network packet or storage sector
-        corresponds to a read operation in bus_dma.

-    

-      

-      
Perform any synchronization required prior to an update of host memory
-          by the device.

-      

-      
Perform any synchronization required after an update of host memory by
-          the CPU and prior to device access to host memory.

-      

-      
Perform any synchronization required after an update of host memory by
-          the device and prior to CPU access to host memory.

-      

-      
Perform any synchronization required after device access to host
-          memory.

-    

-  

-  
bus_dma_lock_t

-  
Client specified lock/mutex manipulation method. This will be called from
-      within busdma whenever a client lock needs to be manipulated. In its
-      current form, the function will be called immediately before the callback
-      for a DMA load operation that has been deferred with
-      BUS_DMA_LOCK and immediately after with
-      BUS_DMA_UNLOCK. If the load operation does not
-      need to be deferred, then it will not be called since the function loading
-      the map should be holding the appropriate locks. This method is of the
-      format:
-    

-      
void

-      
(void
-          *lockfunc_arg, bus_dma_lock_op_t op)

-    

-    
The lockfuncarg argument is specified by
-        the client during tag creation to be passed to all invocations of the
-        callback. The op argument specifies the lock
-        operation to perform.

-    
Two lockfunc
-        implementations are provided for convenience.
-        ()
-        performs standard mutex operations on the sleep mutex provided via
-        lockfuncarg.
-        ()
-        will generate a system panic if it is called. It is substituted into the
-        tag when lockfunc is passed as
-        NULL to
-        bus_dma_tag_create() and is useful for tags that
-        should not be used with deferred load operations.

-  

-  
bus_dma_lock_op_t

-  
Operations to be performed by the client-specified
-      lockfunc().
-    

-      

-      
Acquires and/or locks the client locking primitive.

-      

-      
Releases and/or unlocks the client locking primitive.

-    

-  

-

-

-

-

-

-  
bus_dma_tag_create(parent,
-    alignment, boundary,
-    lowaddr, highaddr,
-    *filtfunc, *filtfuncarg,
-    maxsize, nsegments,
-    maxsegsz, flags,
-    lockfunc, lockfuncarg,
-    *dmat)

-  
Allocates a DMA tag, and initializes it according to the arguments
-      provided:
-    

-      
parent

-      
A parent tag from which to inherit restrictions. The restrictions
-          passed in other arguments can only further tighten the restrictions
-          inherited from the parent tag.
-        
All tags created by a device driver
-            must inherit from the tag returned by
-            ()
-            to honor restrictions between the parent bridge, CPU memory, and the
-            device.

-      

-      
alignment

-      
Alignment constraint, in bytes, of any mappings created using this
-          tag. The alignment must be a power of 2. Hardware that can DMA
-          starting at any address would specify
-           for byte
-          alignment. Hardware requiring DMA transfers to start on a multiple of
-          4K would specify
-          .

-      
boundary

-      
Boundary constraint, in bytes, of the target DMA memory region. The
-          boundary indicates the set of addresses, all multiples of the boundary
-          argument, that cannot be crossed by a single
-          bus_dma_segment_t. The boundary must be a power
-          of 2 and must be no smaller than the maximum segment size.
-          ‘0’ indicates that there are no
-          boundary restrictions.

-      
lowaddr,
-        highaddr

-      
Bounds of the window of bus address space that
-           be
-          directly accessed by the device. The window contains all addresses
-          greater than lowaddr and less than or equal to
-          highaddr. For example, a device incapable of DMA
-          above 4GB, would specify a highaddr of
-          BUS_SPACE_MAXADDR and a
-          lowaddr of
-          BUS_SPACE_MAXADDR_32BIT. Similarly a device
-          that can only perform DMA to addresses below 16MB would specify a
-          highaddr of
-          BUS_SPACE_MAXADDR and a
-          lowaddr of
-          BUS_SPACE_MAXADDR_24BIT. Some implementations
-          require that some region of device visible address space, overlapping
-          available host memory, be outside the window. This area of
-          ‘safe memory’ is used to bounce
-          requests that would otherwise conflict with the exclusion window.

-      
filtfunc

-      
Formerly the optional filter function; must be
-          NULL.

-      
filtfuncarg

-      
Must be NULL.

-      
maxsize

-      
Maximum size, in bytes, of the sum of all segment lengths in a given
-          DMA mapping associated with this tag.

-      
nsegments

-      
Number of discontinuities (scatter/gather segments) allowed in a DMA
-          mapped region.

-      
maxsegsz

-      
Maximum size, in bytes, of a segment in any DMA mapped region
-          associated with dmat.

-      
flags

-      
Are as follows:
-        

-          

-          
Pre-allocate enough resources to handle at least one map load
-              operation on this tag. If sufficient resources are not available,
-              ENOMEM is returned. This should not be
-              used for tags that only describe buffers that will be allocated
-              with bus_dmamem_alloc(). Also, due to
-              resource sharing with other tags, this flag does not guarantee
-              that resources will be allocated or reserved exclusively for this
-              tag. It should be treated only as a minor optimization.

-          

-          
Indicate that the DMA engine and CPU are cache-coherent. Cached
-              memory may be used to back allocations created by
-              bus_dmamem_alloc(). For
-              bus_dma_tag_create(), the
-              BUS_DMA_COHERENT flag is currently
-              implemented on arm64.

-        

-      

-      
lockfunc

-      
Optional lock manipulation function (may be
-          NULL) to be called when busdma needs to
-          manipulate a lock on behalf of the client. If
-          NULL is specified,
-          dflt_lock() is used.

-      
lockfuncarg

-      
Optional argument to be passed to the function specified by
-          lockfunc.

-      
dmat

-      
Pointer to a bus_dma_tag_t where the resulting DMA tag will be
-        stored.

-    

-    
Returns ENOMEM if sufficient memory is
-        not available for tag creation or allocating mapping resources. Returns
-        EINVAL if either filtfunc
-        or filtarg arguments are not
-        NULL.

-  

-  
(dmat)

-  
Deallocate the DMA tag dmat that was created by
-      bus_dma_tag_create().
-    
Returns EBUSY if any DMA maps remain
-        associated with dmat or
-        ‘0’ on success.

-  

-  
(*template,
-    parent)

-  
Initializes a bus_dma_template_t structure. If the
-      parent argument is non-NULL, this parent tag is
-      associated with the template and will be compiled into the dma tag that is
-      later created. The values of the parent are not copied into the template.
-      During tag creation in
-      (),
-      any parameters from the parent tag that are more restrictive than what is
-      in the provided template will overwrite what goes into the new tag.

-  
(*template,
-    *dmat)

-  
Unpacks a template into a tag, and returns the tag via the
-      dmat. All return values are identical to
-      bus_dma_tag_create(). The template is not modified
-      by this function, and can be reused and/or freed upon return.

-  
(*template,
-    dmat)

-  
Copies the fields from an existing tag to a template. The template does
-      not need to be initialized first. All of its fields will be overwritten by
-      the values contained in the tag. When paired with
-      bus_dma_template_tag(), this function is useful
-      for creating copies of tags.

-  
(*template,
-    params[], count)

-  
Fills in the selected fields of the template with the keyed values from
-      the params array. This is not meant to be called
-      directly, use
-      ()
-      instead.

-  
BUS_DMA_TEMPLATE_FILL(*template,
-    param ...)

-  
Fills in the selected fields of the template with a variable number of
-      key-value parameters. The macros listed below take an argument of the
-      specified type and encapsulate it into a key-value structure that is
-      directly usable as a parameter argument. Multiple parameters may be
-      provided at once.
-    

-    
	BD_PARENT()	void *
-	BD_ALIGNMENT()	uintmax_t
-	BD_BOUNDARY()	uintmax_t
-	BD_LOWADDR()	vm_paddr_t
-	BD_HIGHADDR()	vm_paddr_t
-	BD_MAXSIZE()	uintmax_t
-	BD_NSEGMENTS()	uintmax_t
-	BD_MAXSEGSIZE()	uintmax_t
-	BD_FLAGS()	uintmax_t
-	BD_LOCKFUNC()	void *
-	BD_LOCKFUNCARG() void *

-    

-  

-  
bus_dmamap_create(dmat,
-    flags, *mapp)

-  
Allocates and initializes a DMA map. Arguments are as follows:
-    

-      
dmat

-      
DMA tag.

-      
flags

-      
Are as follows:
-        

-          

-          
Attempt to map the memory loaded with this map such that cache
-              sync operations are as cheap as possible. This flag is typically
-              set on maps when the memory loaded with these will be accessed by
-              both a CPU and a DMA engine, frequently such as control data and
-              as opposed to streamable data such as receive and transmit
-              buffers. Use of this flag does not remove the requirement of using
-              bus_dmamap_sync(), but it may reduce the
-              cost of performing these operations.

-        

-      

-      
mapp

-      
Pointer to a bus_dmamap_t where the resulting
-          DMA map will be stored.

-    

-    
Returns ENOMEM if sufficient memory is
-        not available for creating the map or allocating mapping resources.

-  

-  
(dmat,
-    map)

-  
Frees all resources associated with a given DMA map. Arguments are as
-      follows:
-    

-      
dmat

-      
DMA tag used to allocate map.

-      
map

-      
The DMA map to destroy.

-    

-    
Returns EBUSY if a mapping is still
-        active for map.

-  

-  
(dmat,
-    map, buf,
-    buflen, *callback,
-    callback_arg, flags)

-  
Creates a mapping in device visible address space of
-      buflen bytes of buf,
-      associated with the DMA map map. This call will
-      always return immediately and will not block for any reason. Arguments are
-      as follows:
-    

-      
dmat

-      
DMA tag used to allocate map.

-      
map

-      
A DMA map without a currently active mapping.

-      
buf

-      
A kernel virtual address pointer to a contiguous (in KVA) buffer, to
-          be mapped into device visible address space.

-      
buflen

-      
The size of the buffer.

-      
callback callback_arg

-      
The callback function, and its argument. This function is called once
-          sufficient mapping resources are available for the DMA operation. If
-          resources are temporarily unavailable, this function will be deferred
-          until later, but the load operation will still return immediately to
-          the caller. Thus, callers should not assume that the callback will be
-          called before the load returns, and code should be structured
-          appropriately to handle this. See below for specific flags and error
-          codes that control this behavior.

-      
flags

-      
Are as follows:
-        

-          

-          
The load should not be deferred in case of insufficient mapping
-              resources, and instead should return immediately with an
-              appropriate error.

-          

-          
The generated transactions to and from the virtual page are
-              non-cacheable.

-        

-      

-    

-    
Return values to the caller are as follows:

-    

-      
0

-      
The callback has been called and completed. The status of the mapping
-          has been delivered to the callback.

-      
EINPROGRESS

-      
The mapping has been deferred for lack of resources. The callback will
-          be called as soon as resources are available. Callbacks are serviced
-          in FIFO order.
-        
Note that subsequent load operations for the same tag that
-            do not require extra resources will still succeed. This may result
-            in out-of-order processing of requests. If the caller requires the
-            order of requests to be preserved, then the caller is required to
-            stall subsequent requests until a pending request's callback is
-            invoked.

-      

-      
ENOMEM

-      
The load request has failed due to insufficient resources, and the
-          caller specifically used the BUS_DMA_NOWAIT
-          flag.

-      
EINVAL

-      
The load request was invalid. The callback has been called and has
-          been provided the same error. This error value may indicate that
-          dmat, map,
-          buf, or callback were
-          invalid, or buflen was larger than the
-          maxsize argument used to create the dma tag
-          dmat.

-    

-    
When the callback is called, it is presented with an error
-        value indicating the disposition of the mapping. Error may be one of the
-        following:

-    

-      
0

-      
The mapping was successful and the dm_segs
-          callback argument contains an array of
-          bus_dma_segment_t elements describing the
-          mapping. This array is only valid during the scope of the callback
-          function.

-      
EFBIG

-      
A mapping could not be achieved within the segment constraints
-          provided in the tag even though the requested allocation size was less
-          than maxsize.

-    

-  

-  
(dmat,
-    map, bio,
-    callback, callback_arg,
-    flags)

-  
This is a variation of bus_dmamap_load() which
-      maps buffers pointed to by bio for DMA transfers.
-      bio may point to either a mapped or unmapped
-    buffer.

-  
bus_dmamap_load_ccb(dmat,
-    map, ccb,
-    callback, callback_arg,
-    flags)

-  
This is a variation of bus_dmamap_load() which
-      maps data pointed to by ccb for DMA transfers. The
-      data for ccb may be any of the following types:
-    

-      
CAM_DATA_VADDR

-      
The data is a single KVA buffer.

-      
CAM_DATA_PADDR

-      
The data is a single bus address range.

-      
CAM_DATA_SG

-      
The data is a scatter/gather list of KVA buffers.

-      
CAM_DATA_SG_PADDR

-      
The data is a scatter/gather list of bus address ranges.

-      
CAM_DATA_BIO

-      
The data is contained in a struct bio attached
-          to the CCB.

-    

-    
()
-        supports the following CCB XPT function codes:

-    

-    
    
-      
  • XPT_ATA_IO
    • 
-      
  • XPT_CONT_TARGET_IO
    • 
-      
  • XPT_SCSI_IO
    • 
-    

-  

-  
(dmat,
-    map, crp,
-    callback, callback_arg,
-    flags)

-  
This is a variation of bus_dmamap_load() which
-      maps the input buffer pointed to by crp for DMA
-      transfers. The BUS_DMA_NOWAIT flag is implied,
-      thus no callback deferral will happen.

-  
(dmat,
-    map, cb,
-    callback, callback_arg,
-    flags)

-  
This is a variation of bus_dmamap_load() which
-      maps the crypto data buffer pointed to by cb for DMA
-      transfers. The BUS_DMA_NOWAIT flag is implied,
-      thus no callback deferral will happen.

-  
bus_dmamap_load_mbuf(dmat,
-    map, mbuf,
-    callback2, callback_arg,
-    flags)

-  
This is a variation of bus_dmamap_load() which
-      maps mbuf chains for DMA transfers. A bus_size_t
-      argument is also passed to the callback routine, which contains the mbuf
-      chain's packet header length. The BUS_DMA_NOWAIT
-      flag is implied, thus no callback deferral will happen.
-    
Mbuf chains are assumed to be in kernel virtual address
-      space.

-    
Beside the error values listed for
-        (),
-        EINVAL will be returned if the size of the mbuf
-        chain exceeds the maximum limit of the DMA tag.

-  

-  
(dmat,
-    map, mbuf,
-    segs, nsegs,
-    flags)

-  
This is just like bus_dmamap_load_mbuf() except
-      that it returns immediately without calling a callback function. It is
-      provided for efficiency. The scatter/gather segment array
-      segs is provided by the caller and filled in
-      directly by the function. The nsegs argument is
-      returned with the number of segments filled in. Returns the same errors as
-      bus_dmamap_load_mbuf().

-  
bus_dmamap_load_uio(dmat,
-    map, uio,
-    callback2, callback_arg,
-    flags)

-  
This is a variation of bus_dmamap_load() which
-      maps buffers pointed to by uio for DMA transfers. A
-      bus_size_t argument is also passed to the callback
-      routine, which contains the size of uio, i.e.
-      uio->uio_resid. The
-      BUS_DMA_NOWAIT flag is implied, thus no callback
-      deferral will happen. Returns the same errors as
-      bus_dmamap_load().
-    
If uio->uio_segflg is
-        UIO_USERSPACE, then it is assumed that the
-        buffer, uio is in
-        uio->uio_td->td_proc's address space. User
-        space memory must be in-core and wired prior to attempting a map load
-        operation. Pages may be locked using vslock(9).

-  

-  
(dmat,
-    map)

-  
Unloads a DMA map. Arguments are as follows:
-    

-      
dmat

-      
DMA tag used to allocate map.

-      
map

-      
The DMA map that is to be unloaded.

-    

-    
()
-        will not perform any implicit synchronization of DMA buffers. This must
-        be done explicitly by a call to
-        bus_dmamap_sync() prior to unloading the
-      map.

-  

-  
bus_dmamap_sync(dmat,
-    map, op)

-  
Performs synchronization of a device visible mapping with the CPU visible
-      memory referenced by that mapping. Arguments are as follows:
-    

-      
dmat

-      
DMA tag used to allocate map.

-      
map

-      
The DMA mapping to be synchronized.

-      
op

-      
Type of synchronization operation to perform. See the definition of
-          bus_dmasync_op_t for a description of the
-          acceptable values for op.

-    

-    
The
-        ()
-        function is the method used to ensure that CPU's and device's direct
-        memory access (DMA) to shared memory is coherent. For example, the CPU
-        might be used to set up the contents of a buffer that is to be made
-        available to a device. To ensure that the data are visible via the
-        device's mapping of that memory, the buffer must be loaded and a DMA
-        sync operation of BUS_DMASYNC_PREWRITE must be
-        performed after the CPU has updated the buffer and before the device
-        access is initiated. If the CPU modifies this buffer again later,
-        another BUS_DMASYNC_PREWRITE sync operation must
-        be performed before an additional device access. Conversely, suppose a
-        device updates memory that is to be read by a CPU. In this case, the
-        buffer must be loaded, and a DMA sync operation of
-        BUS_DMASYNC_PREREAD must be performed before the
-        device access is initiated. The CPU will only be able to see the results
-        of this memory update once the DMA operation has completed and a
-        BUS_DMASYNC_POSTREAD sync operation has been
-        performed.

-    
If read and write operations are not preceded and followed by
-        the appropriate synchronization operations, behavior is undefined.

-  

-  
(dmat,
-    **vaddr, flags,
-    *mapp)

-  
Allocates memory that is mapped into KVA at the address returned in
-      vaddr and that is permanently loaded into the newly
-      created bus_dmamap_t returned via
-      mapp. Arguments are as follows:
-    

-      
dmat

-      
DMA tag describing the constraints of the DMA mapping.

-      
vaddr

-      
Pointer to a pointer that will hold the returned KVA mapping of the
-          allocated region.

-      
flags

-      
Flags are defined as follows:
-        

-          

-          
The routine can safely wait (sleep) for resources.

-          

-          
The routine is not allowed to wait for resources. If resources are
-              not available, ENOMEM is returned.

-          

-          
Attempt to map this memory in a coherent fashion. See
-              ()
-              above for a description of this flag. For
-              bus_dmamem_alloc(), the
-              BUS_DMA_COHERENT flag is currently
-              implemented on arm and arm64.

-          

-          
Causes the allocated memory to be set to all zeros.

-          

-          
The allocated memory will not be cached in the processor caches.
-              All memory accesses appear on the bus and are executed without
-              reordering. For bus_dmamem_alloc(), the
-              BUS_DMA_NOCACHE flag is currently
-              implemented on amd64 and i386 where it results in the Strong
-              Uncacheable PAT to be set for the allocated virtual address
-            range.

-        

-      

-      
mapp

-      
Pointer to a bus_dmamap_t where the resulting
-          DMA map will be stored.

-    

-    
The size of memory to be allocated
-        is maxsize as specified in the call to
-        ()
-        for dmat.

-    
The current implementation of
-        ()
-        will allocate all requests as a single segment.

-    
An initial load operation is required to
-        obtain the bus address of the allocated memory, and an unload operation
-        is required before freeing the memory, as described below in
-        ().
-        Maps are automatically handled by this function and should not be
-        explicitly allocated or destroyed.

-    
Although an explicit load is not
-        required for each access to the memory referenced by the returned map,
-        the synchronization requirements as described in the
-        ()
-        section still apply and should be used to achieve portability on
-        architectures without coherent buses.

-    
Returns ENOMEM if sufficient memory is
-        not available for completing the operation.

-  

-  
(dmat,
-    *vaddr, map)

-  
Frees memory previously allocated by
-      bus_dmamem_alloc(). Any mappings will be
-      invalidated. Arguments are as follows:
-    

-      
dmat

-      
DMA tag.

-      
vaddr

-      
Kernel virtual address of the memory.

-      
map

-      
DMA map to be invalidated.

-    

-  

-

-

-

-

-
Behavior is undefined if invalid arguments are passed to any of
-    the above functions. If sufficient resources cannot be allocated for a given
-    transaction, ENOMEM is returned. All routines that
-    are not of type void will return 0 on success or an
-    error code on failure as discussed above.

-
All void routines will succeed if provided
-    with valid arguments.

-

-

-

-
Two locking protocols are used by bus_dma.
-    The first is a private global lock that is used to synchronize access to the
-    bounce buffer pool on the architectures that make use of them. This lock is
-    strictly a leaf lock that is only used internally to
-    bus_dma and is not exposed to clients of the
-  API.

-
The second protocol involves protecting
-    various resources stored in the tag. Since almost all
-    bus_dma operations are done through requests from
-    the driver that created the tag, the most efficient way to protect the tag
-    resources is through the lock that the driver uses. In cases where
-    bus_dma acts on its own without being called by the
-    driver, the lock primitive specified in the tag is acquired and released
-    automatically. An example of this is when the
-    ()
-    callback function is called from a deferred context instead of the driver
-    context. This means that certain bus_dma functions
-    must always be called with the same lock held that is specified in the tag.
-    These functions include:

-

-
    
-  
  • ()
    • 
-  
  • bus_dmamap_load_bio()
    • 
-  
  • bus_dmamap_load_ccb()
    • 
-  
  • bus_dmamap_load_mbuf()
    • 
-  
  • bus_dmamap_load_mbuf_sg()
    • 
-  
  • bus_dmamap_load_uio()
    • 
-  
  • bus_dmamap_unload()
    • 
-  
  • bus_dmamap_sync()
    • 
-

-
There is one exception to this rule. It is common practice to call
-    some of these functions during driver start-up without any locks held. So
-    long as there is a guarantee of no possible concurrent use of the tag by
-    different threads during this operation, it is safe to not hold a lock for
-    these functions.

-
Certain bus_dma operations should not be
-    called with the driver lock held, either because they are already protected
-    by an internal lock, or because they might sleep due to memory or resource
-    allocation. The following functions must not be called with any
-    non-sleepable locks held:

-

-
-
All other functions do not have a locking protocol and can thus be
-    called with or without any system or driver locks held.

-

-

-

-
devclass(9), device(9),
-    driver(9), rman(9),
-    vslock(9)

-

-
Jason R. Thorpe,
-    A Machine-Independent DMA Framework for NetBSD,
-    Proceedings of the Summer 1998 USENIX Technical
-    Conference, USENIX Association,
-    June 1998.

-

-

-

-
The bus_dma interface first appeared in
-    NetBSD 1.3.

-
The bus_dma API was adopted from
-    NetBSD for use in the CAM SCSI subsystem. The
-    alterations to the original API were aimed to remove the need for a
-    bus_dma_segment_t array stored in each
-    bus_dmamap_t while allowing callers to queue up on
-    scarce resources.

-

-

-

-
The bus_dma interface was designed and
-    implemented by Jason R. Thorpe of the Numerical
-    Aerospace Simulation Facility, NASA Ames Research Center. Additional input
-    on the bus_dma design was provided by
-    Chris Demetriou, Charles
-    Hannum, Ross Harvey, Matthew
-    Jacob, Jonathan Stone, and
-    Matt Thomas.

-
The bus_dma interface in
-    FreeBSD benefits from the contributions of
-    Justin T. Gibbs, Peter Wemm,
-    Doug Rabson, Matthew N.
-    Dodd, Sam Leffler, Maxime
-    Henrion, Jake Burkholder,
-    Takahashi Yoshihiro, Scott
-    Long and many others.

-
This manual page was written by Hiten M.
-    Pandya and Justin T. Gibbs.

-

-

-
-  
-    
-    
-  
-
May 25, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_generic_detach.9 4.html b/static/freebsd/man9/bus_generic_detach.9 4.html
deleted file mode 100644
index 1f468de0..00000000
--- a/static/freebsd/man9/bus_generic_detach.9 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_GENERIC_DETACH(9)Kernel Developer's ManualBUS_GENERIC_DETACH(9)

-

-

-

-
bus_generic_detach —
-    generic implementation of
-    DEVICE_DETACH for buses

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  bus_generic_detach(device_t
-    dev);

-

-

-

-
This function provides an implementation of the
-    DEVICE_DETACH(9) method which can be used by most bus
-    code. It uses bus_detach_children(9) to detach drivers
-    from all child devices giving them a chance to veto the detach request. If
-    ()
-    succeeds,
-    ()
-    calls device_delete_children(9) to delete all child
-    devices.

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned.

-

-

-

-
bus_detach_children(9),
-    device(9), device_delete_children(9),
-    driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_generic_new_pass.9 4.html b/static/freebsd/man9/bus_generic_new_pass.9 4.html
deleted file mode 100644
index c25b1be7..00000000
--- a/static/freebsd/man9/bus_generic_new_pass.9 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_GENERIC_NEW_PASS(9)Kernel Developer's ManualBUS_GENERIC_NEW_PASS(9)

-

-

-

-
bus_generic_new_pass —
-    generic implementation of BUS_NEW_PASS for bus
-    devices

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  bus_generic_new_pass(device_t
-    dev);

-

-

-

-
This function provides an implementation of the
-    BUS_NEW_PASS(9) method which can be used by bus drivers.
-    It first invokes the DEVICE_IDENTIFY(9) method for any
-    drivers whose pass level is equal to the new pass level. Then, for each
-    attached child device it calls BUS_NEW_PASS(9) to rescan
-    child buses, and for each unattached child device it calls
-    device_probe_and_attach(9).

-

-

-

-
BUS_NEW_PASS(9),
-    bus_set_pass(9), device(9),
-    DEVICE_IDENTIFY(9)

-

-

-
-  
-    
-    
-  
-
January 15, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_generic_print_child.9 3.html b/static/freebsd/man9/bus_generic_print_child.9 3.html
deleted file mode 100644
index d77797f1..00000000
--- a/static/freebsd/man9/bus_generic_print_child.9 3.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_GENERIC_PRINT_CHILD(9)Kernel Developer's ManualBUS_GENERIC_PRINT_CHILD(9)

-

-

-

-
bus_generic_print_child,
-    bus_print_child_domain,
-    bus_print_child_footer,
-    bus_print_child_header —
-    generic implementation of
-    BUS_PRINT_CHILD(9)

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  bus_generic_print_child(device_t
-    dev, device_t
-    child);

-
int
-  

-  bus_print_child_domain(device_t
-    dev, device_t
-    child);

-
int
-  

-  bus_print_child_footer(device_t
-    dev, device_t
-    child);

-
int
-  

-  bus_print_child_header(device_t
-    dev, device_t
-    child);

-

-

-

-
()
-    prints out the default device announcement message. Given device
-    ‘foo0’ on bus ‘bar0’ where foo0 has the
-    description “FooCard 1234” and is associated with the NUMA
-    domain 1, the following would be printed:

-

-
foo0: <FooCard 1234> numa-domain 1 on bar0

-

-
()
-    calls the three helper functions
-    bus_print_child_header(),
-    bus_print_child_domain(), and
-    bus_print_child_footer().

-
()
-    outputs the device name and unit followed by the device description in angle
-    brackets (“foo0: <FooCard 1234>”).

-
()
-    outputs “ numa-domain” followed by the domain number if
-    ()
-    returns a valid domain for the device (“numa-domain 1”). If
-    dev is not associated witha valid domain, nothing is
-    output.

-
-
These functions can be used to
-    implement BUS_PRINT_CHILD(9) in a bus driver if
-    ()
-    is not sufficient.

-

-

-

-
The number of characters output.

-

-

-

-
BUS_PRINT_CHILD(9),
-  device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_generic_read_ivar.9 4.html b/static/freebsd/man9/bus_generic_read_ivar.9 4.html
deleted file mode 100644
index 4eefb5f9..00000000
--- a/static/freebsd/man9/bus_generic_read_ivar.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_GENERIC_READ_IVAR(9)Kernel Developer's ManualBUS_GENERIC_READ_IVAR(9)

-

-

-

-
bus_generic_read_ivar,
-    bus_generic_write_ivar —
-    generic implementation of
-    BUS_READ_IVAR and
-    BUS_WRITE_IVAR for buses

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  bus_generic_read_ivar(device_t
-    dev, device_t
-    child, int index,
-    uintptr_t *result);

-
int
-  

-  bus_generic_write_ivar(device_t
-    dev, device_t
-    child, int index,
-    uintptr_t value);

-

-

-

-
These functions simply return ENOENT.

-

-

-

-
device(9), driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 15, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_generic_shutdown.9 4.html b/static/freebsd/man9/bus_generic_shutdown.9 4.html
deleted file mode 100644
index e09ca54f..00000000
--- a/static/freebsd/man9/bus_generic_shutdown.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_GENERIC_SHUTDOWN(9)Kernel Developer's ManualBUS_GENERIC_SHUTDOWN(9)

-

-

-

-
bus_generic_shutdown —
-    generic implementation of
-    DEVICE_SHUTDOWN for buses

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  bus_generic_shutdown(device_t
-    dev);

-

-

-

-
This function provides an implementation of the
-    DEVICE_SHUTDOWN(9) method which can be used by most bus
-    code. It simply calls the DEVICE_SHUTDOWN(9) method of
-    each child device attached to the bus.

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned.

-

-

-

-
device(9), driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 15, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_get_resource.9 4.html b/static/freebsd/man9/bus_get_resource.9 4.html
deleted file mode 100644
index 9e11492a..00000000
--- a/static/freebsd/man9/bus_get_resource.9 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_GET_RESOURCE(9)Kernel Developer's ManualBUS_GET_RESOURCE(9)

-

-

-

-
bus_get_resource —
-    read a resource range/value with a given resource
-  ID

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>
-  

-  #include <sys/rman.h>

-
int
-  

-  bus_get_resource(device_t dev,
-    int type, int rid,
-    rman_res_t *startp, rman_res_t
-    *countp);

-

-

-

-
The
-    ()
-    function reads the range or value of the resource
-    type, rid pair and stores it in
-    the startp and countp
-  arguments.

-
The arguments are as follows:

-

-  
dev

-  
The device to read the resource from.

-  
type

-  
The type of resource you want to read. It is one of:
-    

-    

-      

-      
for IRQs

-      

-      
for ISA DMA lines

-      

-      
for I/O memory

-      

-      
for I/O ports

-    

-  

-  
rid

-  
A bus-specific handle that identifies the resource being read.

-  
startp

-  
A pointer to the start address of this resource.

-  
countp

-  
A pointer to the length of the resource. For example, the size of the
-      memory in bytes.

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
bus_set_resource(9),
-    device(9), driver(9)

-

-

-

-
This manual page was written by Sascha
-    Wildner.

-

-

-
-  
-    
-    
-  
-
September 26, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_map_resource.9 3.html b/static/freebsd/man9/bus_map_resource.9 3.html
deleted file mode 100644
index 54ae36f4..00000000
--- a/static/freebsd/man9/bus_map_resource.9 3.html	
+++ /dev/null
@@ -1,150 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_MAP_RESOURCE(9)Kernel Developer's ManualBUS_MAP_RESOURCE(9)

-

-

-

-
bus_map_resource,
-    bus_unmap_resource,
-    resource_init_map_request —
-    map or unmap an active resource

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
int
-  

-  bus_map_resource(device_t dev,
-    struct resource *r, struct
-    resource_map_request *args, struct resource_map
-    *map);

-
int
-  

-  bus_unmap_resource(device_t dev,
-    struct resource *r, struct
-    resource_map *map);

-
void
-  

-  resource_init_map_request(struct
-    resource_map_request *args);

-

-

-

-
These functions create or destroy a mapping of a previously
-    activated resource. Mappings permit CPU access to the resource via the
-    bus_space(9) API.

-
The arguments are as follows:

-

-  
dev

-  
The device that owns the resource.

-  
r

-  
A pointer to the struct resource returned by
-      bus_alloc_resource(9).

-  
args

-  
A set of optional properties to apply when creating a mapping. This
-      argument can be set to NULL to request a mapping
-      of the entire resource with the default properties.

-  
map

-  
The resource mapping to create or destroy.

-

-

-

-
Resource mappings are described by a struct
-    resource_map object. This structure contains a
-    bus_space(9) tag and handle in the
-    r_bustag and r_bushandle members
-    that can be used for CPU access to the mapping. The structure also contains
-    a r_vaddr member which contains the virtual address of
-    the mapping if one exists.

-
The wrapper API for struct
-    resource objects described in
-    bus_activate_resource(9) can also be used with
-    struct resource_map. For example, a pointer to a
-    mapping object can be passed as the first argument to
-    ().
-    This wrapper API is preferred over using the r_bustag
-    and r_bushandle members directly.

-

-

-

-
The struct resource_map_request object
-    passed in args can be used to specify optional
-    properties of a mapping. The structure must be initialized by invoking
-    ().
-    Properties are then specified by setting one or more of these members:

-

-  
offset,
-    length

-  
These two members specify a region of the resource to map. By default a
-      mapping is created for the entire resource. The
-      offset is relative to the start of the
-    resource.

-  
memattr

-  
Specifies a memory attribute to use when mapping the resource. By default
-      memory mappings use the VM_MEMATTR_UNCACHEABLE
-      attribute.

-

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
This maps a PCI memory BAR with the write-combining memory
-    attribute and reads the first 32-bit word:

-

-
	struct resource *r;
-	struct resource_map map;
-	struct resource_map_request req;
-	uint32_t val;
-	int rid;
-
-	rid = PCIR_BAR(0);
-	r = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE |
-	    RF_UNMAPPED);
-	resource_init_map_request(&req);
-	req.memattr = VM_MEMATTR_WRITE_COMBINING;
-	bus_map_resource(dev, SYS_RES_MEMORY, r, &req, &map);
-	val = bus_read_4(&map, 0);

-

-

-

-

-
bus_activate_resource(9),
-    bus_alloc_resource(9), bus_space(9),
-    device(9), driver(9)

-

-

-

-
This manual page was written by John
-    Baldwin
-    <jhb@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 13, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_release_resource.9 4.html b/static/freebsd/man9/bus_release_resource.9 4.html
deleted file mode 100644
index fbaa4611..00000000
--- a/static/freebsd/man9/bus_release_resource.9 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_RELEASE_RESOURCE(9)Kernel Developer's ManualBUS_RELEASE_RESOURCE(9)

-

-

-

-
bus_release_resource —
-    release resources on a bus

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
int
-  

-  bus_release_resource(device_t
-    dev, struct resource
-    *r);

-

-

-

-
Free a resource allocated by
-    bus_alloc_resource(9). The resource must not be in use on
-    release, i.e., call an appropriate function before (e.g.
-    bus_teardown_intr(9) for IRQs).

-
    
-  
  • dev is the device that owns the resource.
    • 
-  
  • r is the pointer to struct
-      resource, i.e., the resource itself, returned by
-      bus_alloc_resource(9).
    • 
-

-

-

-

-
EINVAL is returned, if the device
-    dev has no parent, 0
-    otherwise. The kernel will panic, if it cannot release the resource.

-

-

-

-

-
	/* deactivate IRQ */
-	bus_teardown_intr(dev, foosoftc->irqres, foosoftc->irqid);
-
-	/* release IRQ resource */
-	bus_release_resource(dev, foosoftc->irqres);
-
-	/* release I/O port resource */
-	bus_release_resource(dev, foosoftc->portres);

-

-

-

-

-
bus_alloc_resource(9),
-    device(9), driver(9)

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@big.endian.de>.

-

-

-
-  
-    
-    
-  
-
March 13, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_set_pass.9 4.html b/static/freebsd/man9/bus_set_pass.9 4.html
deleted file mode 100644
index 4df5f01d..00000000
--- a/static/freebsd/man9/bus_set_pass.9 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_SET_PASS(9)Kernel Developer's ManualBUS_SET_PASS(9)

-

-

-

-
bus_set_pass —
-    raise the bus pass level

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  bus_set_pass(int
-    pass);

-

-

-

-
The bus_set_pass function is called during
-    boot to raise the bus pass level to pass. The function
-    will rescan the device tree for each pass level between the current pass
-    level and the new level that has at least one associated driver. The device
-    tree rescans are implemented by invoking the
-    BUS_NEW_PASS(9) method on the root bus device.

-

-

-

-
BUS_NEW_PASS(9), device(9)

-

-

-
-  
-    
-    
-  
-
June 8, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_set_resource.9 4.html b/static/freebsd/man9/bus_set_resource.9 4.html
deleted file mode 100644
index a24aad50..00000000
--- a/static/freebsd/man9/bus_set_resource.9 4.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_SET_RESOURCE(9)Kernel Developer's ManualBUS_SET_RESOURCE(9)

-

-

-

-
bus_set_resource —
-    associate a definite resource with a given resource
-    ID

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-

-  

-  #include <machine/bus.h>
-  

-  #include <sys/rman.h>
-  

-  #include
-  <machine/resource.h>

-
int
-  

-  bus_set_resource(device_t dev,
-    int type, int rid,
-    rman_res_t start, rman_res_t
-    count);

-

-

-

-
The
-    ()
-    function sets the start address of the resource type,
-    rid pair to be count long.
-    Typically, client drivers do not use this interface. Bus drivers, however,
-    often use it to set up the resources a client driver uses.

-
The arguments are as follows:

-

-  
dev

-  
The device to set the resource on.

-  
type

-  
The type of resource you want to allocate. It is one of:
-    

-    

-      

-      
for IRQs

-      

-      
for ISA DMA lines

-      

-      
for I/O ports

-      

-      
for I/O memory

-    

-  

-  
rid

-  
A bus-specific handle that identifies the resource being allocated.

-  
start

-  
The start address of this resource.

-  
count

-  
The length of the resource. For example, the size of the memory in
-    bytes.

-

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
bus_alloc_resource(9),
-    bus_get_resource(9), device(9),
-    driver(9)

-

-

-

-
This manual page was written by Warner
-    Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 29, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/bus_space.9 3.html b/static/freebsd/man9/bus_space.9 3.html
deleted file mode 100644
index e2f00da9..00000000
--- a/static/freebsd/man9/bus_space.9 3.html	
+++ /dev/null
@@ -1,1712 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_SPACE(9)Kernel Developer's ManualBUS_SPACE(9)

-

-

-

-
bus_space,
-    bus_space_barrier,
-    bus_space_copy_region_1,
-    bus_space_copy_region_2,
-    bus_space_copy_region_4,
-    bus_space_copy_region_8,
-    bus_space_copy_region_stream_1,
-    bus_space_copy_region_stream_2,
-    bus_space_copy_region_stream_4,
-    bus_space_copy_region_stream_8,
-    bus_space_free,
-    bus_space_map,
-    bus_space_peek_1,
-    bus_space_peek_2,
-    bus_space_peek_4,
-    bus_space_peek_8,
-    bus_space_poke_1,
-    bus_space_poke_2,
-    bus_space_poke_4,
-    bus_space_poke_8,
-    bus_space_read_1,
-    bus_space_read_2,
-    bus_space_read_4,
-    bus_space_read_8,
-    bus_space_read_multi_1,
-    bus_space_read_multi_2,
-    bus_space_read_multi_4,
-    bus_space_read_multi_8,
-    bus_space_read_multi_stream_1,
-    bus_space_read_multi_stream_2,
-    bus_space_read_multi_stream_4,
-    bus_space_read_multi_stream_8,
-    bus_space_read_region_1,
-    bus_space_read_region_2,
-    bus_space_read_region_4,
-    bus_space_read_region_8,
-    bus_space_read_region_stream_1,
-    bus_space_read_region_stream_2,
-    bus_space_read_region_stream_4,
-    bus_space_read_region_stream_8,
-    bus_space_read_stream_1,
-    bus_space_read_stream_2,
-    bus_space_read_stream_4,
-    bus_space_read_stream_8,
-    bus_space_set_multi_1,
-    bus_space_set_multi_2,
-    bus_space_set_multi_4,
-    bus_space_set_multi_8,
-    bus_space_set_multi_stream_1,
-    bus_space_set_multi_stream_2,
-    bus_space_set_multi_stream_4,
-    bus_space_set_multi_stream_8,
-    bus_space_set_region_1,
-    bus_space_set_region_2,
-    bus_space_set_region_4,
-    bus_space_set_region_8,
-    bus_space_set_region_stream_1,
-    bus_space_set_region_stream_2,
-    bus_space_set_region_stream_4,
-    bus_space_set_region_stream_8,
-    bus_space_subregion,
-    bus_space_unmap,
-    bus_space_write_1,
-    bus_space_write_2,
-    bus_space_write_4,
-    bus_space_write_8,
-    bus_space_write_multi_1,
-    bus_space_write_multi_2,
-    bus_space_write_multi_4,
-    bus_space_write_multi_8,
-    bus_space_write_multi_stream_1,
-    bus_space_write_multi_stream_2,
-    bus_space_write_multi_stream_4,
-    bus_space_write_multi_stream_8,
-    bus_space_write_region_1,
-    bus_space_write_region_2,
-    bus_space_write_region_4,
-    bus_space_write_region_8,
-    bus_space_write_region_stream_1,
-    bus_space_write_region_stream_2,
-    bus_space_write_region_stream_4,
-    bus_space_write_region_stream_8,
-    bus_space_write_stream_1,
-    bus_space_write_stream_2,
-    bus_space_write_stream_4,
-    bus_space_write_stream_8 —
-    bus space manipulation functions

-

-

-

-
#include
-    <machine/bus.h>

-
int
-  

-  bus_space_map(bus_space_tag_t
-    space, bus_addr_t address,
-    bus_size_t size, int flags,
-    bus_space_handle_t *handlep);

-
void
-  

-  bus_space_unmap(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t size);

-
int
-  

-  bus_space_subregion(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, bus_size_t
-    size, bus_space_handle_t *nhandlep);

-
int
-  

-  bus_space_alloc(bus_space_tag_t
-    space, bus_addr_t reg_start,
-    bus_addr_t reg_end, bus_size_t
-    size, bus_size_t alignment,
-    bus_size_t boundary, int flags,
-    bus_addr_t *addrp, bus_space_handle_t
-    *handlep);

-
void
-  

-  bus_space_free(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t size);

-
int
-  

-  bus_space_peek_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_peek_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_peek_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_peek_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_poke_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_poke_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_poke_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_poke_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap);

-
uint8_t
-  

-  bus_space_read_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint16_t
-  

-  bus_space_read_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint32_t
-  

-  bus_space_read_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint64_t
-  

-  bus_space_read_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint8_t
-  

-  bus_space_read_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint16_t
-  

-  bus_space_read_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint32_t
-  

-  bus_space_read_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
uint64_t
-  

-  bus_space_read_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset);

-
void
-  

-  bus_space_write_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    value);

-
void
-  

-  bus_space_write_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    value);

-
void
-  

-  bus_space_write_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    value);

-
void
-  

-  bus_space_write_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    value);

-
void
-  

-  bus_space_write_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    value);

-
void
-  

-  bus_space_write_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    value);

-
void
-  

-  bus_space_write_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    value);

-
void
-  

-  bus_space_write_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    value);

-
void
-  

-  bus_space_barrier(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, bus_size_t
-    length, int flags);

-
void
-  

-  bus_space_read_region_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_region_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_region_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_copy_region_1(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_2(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_4(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_8(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_stream_1(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_stream_2(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_stream_4(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_stream_8(bus_space_tag_t
-    space, bus_space_handle_t srchandle,
-    bus_size_t srcoffset,
-    bus_space_handle_t dsthandle,
-    bus_size_t dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_set_region_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_region_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_read_multi_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_read_multi_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_write_multi_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    *datap, bus_size_t count);

-
void
-  

-  bus_space_set_multi_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_stream_1(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint8_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_stream_2(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint16_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_stream_4(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint32_t
-    value, bus_size_t count);

-
void
-  

-  bus_space_set_multi_stream_8(bus_space_tag_t
-    space, bus_space_handle_t handle,
-    bus_size_t offset, uint64_t
-    value, bus_size_t count);

-

-

-

-
The bus_space functions exist to allow
-    device drivers machine-independent access to bus memory and register areas.
-    All of the functions and types described in this document can be used by
-    including the
-    <machine/bus.h> header
-  file.

-
Many common devices are used on multiple architectures, but are
-    accessed differently on each because of architectural constraints. For
-    instance, a device which is mapped in one system's I/O space may be mapped
-    in memory space on a second system. On a third system, architectural
-    limitations might change the way registers need to be accessed (e.g.
-    creating a non-linear register space). In some cases, a single driver may
-    need to access the same type of device in multiple ways in a single system
-    or architecture. The goal of the bus_space functions
-    is to allow a single driver source file to manipulate a set of devices on
-    different system architectures, and to allow a single driver object file to
-    manipulate a set of devices on multiple bus types on a single
-  architecture.

-
Not all buses have to implement all functions described in this
-    document, though that is encouraged if the operations are logically
-    supported by the bus. Unimplemented functions should cause compile-time
-    errors if possible.

-
All of the interface definitions described in this document are
-    shown as function prototypes and discussed as if they were required to be
-    functions. Implementations are encouraged to implement prototyped
-    (type-checked) versions of these interfaces, but may implement them as
-    macros if appropriate. Machine-dependent types, variables, and functions
-    should be marked clearly in
-    <machine/bus.h> to avoid
-    confusion with the machine-independent types and functions, and, if
-    possible, should be given names which make the machine-dependence clear.

-

-

-

-
Bus spaces are described by bus space tags, which can be created
-    only by machine-dependent code. A given machine may have several different
-    types of bus space (e.g. memory space and I/O space), and thus may provide
-    multiple different bus space tags. Individual buses or devices on a machine
-    may use more than one bus space tag. For instance, ISA devices are given an
-    ISA memory space tag and an ISA I/O space tag. Architectures may have
-    several different tags which represent the same type of space, for instance
-    because of multiple different host bus interface chipsets.

-
A range in bus space is described by a bus address and a bus size.
-    The bus address describes the start of the range in bus space. The bus size
-    describes the size of the range in bytes. Buses which are not byte
-    addressable may require use of bus space ranges with appropriately aligned
-    addresses and properly rounded sizes.

-
Access to regions of bus space is facilitated by use of bus space
-    handles, which are usually created by mapping a specific range of a bus
-    space. Handles may also be created by allocating and mapping a range of bus
-    space, the actual location of which is picked by the implementation within
-    bounds specified by the caller of the allocation function.

-
All of the bus space access functions require one bus space tag
-    argument, at least one handle argument, and at least one offset argument (a
-    bus size). The bus space tag specifies the space, each handle specifies a
-    region in the space, and each offset specifies the offset into the region of
-    the actual location(s) to be accessed. Offsets are given in bytes, though
-    buses may impose alignment constraints. The offset used to access data
-    relative to a given handle must be such that all of the data being accessed
-    is in the mapped region that the handle describes. Trying to access data
-    outside that region is an error.

-
Because some architectures' memory systems use buffering to
-    improve memory and device access performance, there is a mechanism which can
-    be used to create “barriers” in the bus space read and write
-    stream. There are three types of barriers: read, write, and read/write. All
-    reads started to the region before a read barrier must complete before any
-    reads after the read barrier are started. (The analogous requirement is true
-    for write barriers.) Read/write barriers force all reads and writes started
-    before the barrier to complete before any reads or writes after the barrier
-    are started. Correctly-written drivers will include all appropriate
-    barriers, and assume only the read/write ordering imposed by the barrier
-    operations.

-
People trying to write portable drivers with the
-    bus_space functions should try to make minimal
-    assumptions about what the system allows. In particular, they should expect
-    that the system requires bus space addresses being accessed to be naturally
-    aligned (i.e., base address of handle added to offset is a multiple of the
-    access size), and that the system does alignment checking on pointers (i.e.,
-    pointer to objects being read and written must point to properly-aligned
-    data).

-
The descriptions of the bus_space
-    functions given below all assume that they are called with proper arguments.
-    If called with invalid arguments or arguments that are out of range (e.g.
-    trying to access data outside of the region mapped when a given handle was
-    created), undefined behaviour results. In that case, they may cause the
-    system to halt, either intentionally (via panic) or unintentionally (by
-    causing a fatal trap of by some other means) or may cause improper operation
-    which is not immediately fatal. Functions which return
-    void or which return data read from bus space (i.e.,
-    functions which do not obviously return an error code) do not fail. They
-    could only fail if given invalid arguments, and in that case their behaviour
-    is undefined. Functions which take a count of bytes have undefined results
-    if the specified count is zero.

-

-

-

-
Several types are defined in
-    <machine/bus.h> to
-    facilitate use of the bus_space functions by
-    drivers.

-

-

-
The bus_addr_t type is used to describe bus
-    addresses. It must be an unsigned integral type capable of holding the
-    largest bus address usable by the architecture. This type is primarily used
-    when mapping and unmapping bus space.

-

-

-

-
The bus_size_t type is used to describe
-    sizes of ranges in bus space. It must be an unsigned integral type capable
-    of holding the size of the largest bus address range usable on the
-    architecture. This type is used by virtually all of the
-    bus_space functions, describing sizes when mapping
-    regions and offsets into regions when performing space access
-  operations.

-

-

-

-
The bus_space_tag_t type is used to describe
-    a particular bus space on a machine. Its contents are machine-dependent and
-    should be considered opaque by machine-independent code. This type is used
-    by all bus_space functions to name the space on
-    which they are operating.

-

-

-

-
The bus_space_handle_t type is used to
-    describe a mapping of a range of bus space. Its contents are
-    machine-dependent and should be considered opaque by machine-independent
-    code. This type is used when performing bus space access operations.

-

-

-

-

-
This section is specific to the NetBSD
-    version of these functions and may or may not apply to the
-    FreeBSD version.

-
Bus space must be mapped before it can be used,
-    and should be unmapped when it is no longer needed. The
-    ()
-    and bus_space_unmap() functions provide these
-    capabilities.

-
Some drivers need to be able to pass a
-    subregion of already-mapped bus space to another driver or module within a
-    driver. The
-    ()
-    function allows such subregions to be created.

-

-

-
The bus_space_map() function maps the
-    region of bus space named by the space,
-    address, and size arguments. If
-    successful, it returns zero and fills in the bus space handle pointed to by
-    handlep with the handle that can be used to access the
-    mapped region. If unsuccessful, it will return non-zero and leave the bus
-    space handle pointed to by handlep in an undefined
-    state.

-
The flags argument controls how the space is
-    to be mapped. Supported flags include:

-

-  

-  
Try to map the space so that accesses can be cached and/or prefetched by
-      the system. If this flag is not specified, the implementation should map
-      the space so that it will not be cached or prefetched.
-    
This flag must have a value of 1 on all implementations for
-        backward compatibility.

-  

-  

-  
Try to map the space so that its contents can be accessed linearly via
-      normal memory access methods (e.g. pointer dereferencing and structure
-      accesses). This is useful when software wants to do direct access to a
-      memory device, e.g. a frame buffer. If this flag is specified and linear
-      mapping is not possible, the
-      ()
-      call should fail. If this flag is not specified, the system may map the
-      space in whatever way is most convenient.

-  

-  
Try to map the space using non-posted device memory. This is to support
-      buses and devices where mapping with posted device memory is unsupported
-      or broken. This flag is currently only available on arm64.

-

-
Not all combinations of flags make sense or are supported with all
-    spaces. For instance, BUS_SPACE_MAP_CACHEABLE may be
-    meaningless when used on many systems' I/O port spaces, and on some systems
-    BUS_SPACE_MAP_LINEAR without
-    BUS_SPACE_MAP_CACHEABLE may never work. When the
-    system hardware or firmware provides hints as to how spaces should be mapped
-    (e.g. the PCI memory mapping registers' “prefetchable” bit),
-    those hints should be followed for maximum compatibility. On some systems,
-    requesting a mapping that cannot be satisfied (e.g. requesting a
-    non-cacheable mapping when the system can only provide a cacheable one) will
-    cause the request to fail.

-
Some implementations may keep track of use of bus space for some
-    or all bus spaces and refuse to allow duplicate allocations. This is
-    encouraged for bus spaces which have no notion of slot-specific space
-    addressing, such as ISA, and for spaces which coexist with those spaces
-    (e.g. PCI memory and I/O spaces co-existing with ISA memory and I/O
-  spaces).

-
Mapped regions may contain areas for which there is no device on
-    the bus. If space in those areas is accessed, the results are
-  bus-dependent.

-

-

-
(space,
-  handle, size)

-
The bus_space_unmap() function unmaps a
-    region of bus space mapped with bus_space_map().
-    When unmapping a region, the size specified should be
-    the same as the size given to bus_space_map() when
-    mapping that region.

-
After
-    ()
-    is called on a handle, that handle is no longer valid. (If copies were made
-    of the handle they are no longer valid, either.)

-
This function will never fail. If it would
-    fail (e.g. because of an argument error), that indicates a software bug
-    which should cause a panic. In that case,
-    ()
-    will never return.

-

-

-

-
The bus_space_subregion() function is a
-    convenience function which makes a new handle to some subregion of an
-    already-mapped region of bus space. The subregion described by the new
-    handle starts at byte offset offset into the region
-    described by handle, with the size give by
-    size, and must be wholly contained within the original
-    region.

-
If successful,
-    ()
-    returns zero and fills in the bus space handle pointed to by
-    nhandlep. If unsuccessful, it returns non-zero and
-    leaves the bus space handle pointed to by nhandlep in
-    an undefined state. In either case, the handle described by
-    handle remains valid and is unmodified.

-
When done with a handle created by
-    (),
-    the handle should be thrown away. Under no circumstances should
-    bus_space_unmap() be used on the handle. Doing so
-    may confuse any resource management being done on the space, and will result
-    in undefined behaviour. When bus_space_unmap() or
-    bus_space_free() is called on a handle, all
-    subregions of that handle become invalid.

-

-

-

-

-
This section is specific to the NetBSD
-    version of these functions and may or may not apply to the
-    FreeBSD version.

-
Some devices require or allow bus space to be
-    allocated by the operating system for device use. When the devices no longer
-    need the space, the operating system should free it for use by other
-    devices. The
-    ()
-    and bus_space_free() functions provide these
-    capabilities.

-

-

-
The bus_space_alloc() function allocates
-    and maps a region of bus space with the size given by
-    size, corresponding to the given constraints. If
-    successful, it returns zero, fills in the bus address pointed to by
-    addrp with the bus space address of the allocated
-    region, and fills in the bus space handle pointed to by
-    handlep with the handle that can be used to access
-    that region. If unsuccessful, it returns non-zero and leaves the bus address
-    pointed to by addrp and the bus space handle pointed
-    to by handlep in an undefined state.

-
Constraints on the allocation are given by
-    the reg_start, reg_end,
-    alignment, and boundary
-    parameters. The allocated region will start at or after
-    reg_start and end before or at
-    reg_end. The alignment
-    constraint must be a power of two, and the allocated region will start at an
-    address that is an even multiple of that power of two. The
-    boundary constraint, if non-zero, ensures that the
-    region is allocated so that first address in region /
-    boundary has the same value as last
-    address in region / boundary. If the constraints
-    cannot be met,
-    ()
-    will fail. It is an error to specify a set of constraints that can never be
-    met (for example, size greater than
-    boundary).

-
The flags parameter is
-    the same as the like-named parameter to
-    (),
-    the same flag values should be used, and they have the same meanings.

-
Handles created by
-    ()
-    should only be freed with bus_space_free(). Trying
-    to use bus_space_unmap() on them causes undefined
-    behaviour. The bus_space_subregion() function can be
-    used on handles created by bus_space_alloc().

-

-

-

-
The bus_space_free() function unmaps and
-    frees a region of bus space mapped and allocated with
-    bus_space_alloc(). When unmapping a region, the
-    size specified should be the same as the size given to
-    bus_space_alloc() when allocating the region.

-
After
-    ()
-    is called on a handle, that handle is no longer valid. (If copies were made
-    of the handle, they are no longer valid, either.)

-
This function will never fail. If it would
-    fail (e.g. because of an argument error), that indicates a software bug
-    which should cause a panic. In that case,
-    ()
-    will never return.

-

-

-

-

-
The simplest way to access bus space is to read or write a single
-    data item. The bus_space_read_N() and
-    bus_space_write_N() families of functions provide
-    the ability to read and write 1, 2, 4, and 8 byte data items on buses which
-    support those access sizes.

-

-
(space,
-  handle, offset)

-

-

-
(space,
-  handle, offset)

-

-

-
(space,
-  handle, offset)

-

-

-
(space,
-  handle, offset)

-
The bus_space_read_N() family of functions
-    reads a 1, 2, 4, or 8 byte data item from the offset specified by
-    offset into the region specified by
-    handle of the bus space specified by
-    space. The location being read must lie within the bus
-    space region specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data item being read. On some systems, not obeying this requirement
-    may cause incorrect data to be read, on others it may cause a system
-  crash.

-
Read operations done by the
-    ()
-    functions may be executed out of order with respect to other pending read
-    and write operations unless order is enforced by use of the
-    bus_space_barrier() function.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-
(space,
-  handle, offset,
-  value)

-

-

-
(space,
-  handle, offset,
-  value)

-

-

-
(space,
-  handle, offset,
-  value)

-

-

-
(space,
-  handle, offset,
-  value)

-
The bus_space_write_N() family of
-    functions writes a 1, 2, 4, or 8 byte data item to the offset specified by
-    offset into the region specified by
-    handle of the bus space specified by
-    space. The location being written must lie within the
-    bus space region specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data item being written. On some systems, not obeying this
-    requirement may cause incorrect data to be written, on others it may cause a
-    system crash.

-
Write operations done by the
-    ()
-    functions may be executed out of order with respect to other pending read
-    and write operations unless order is enforced by use of the
-    bus_space_barrier() function.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-

-

-
One problem with the
-    ()
-    and bus_space_write_N() family of functions is that
-    they provide no protection against exceptions which can occur when no
-    physical hardware or device responds to the read or write cycles. In such a
-    situation, the system typically would panic due to a kernel-mode bus error.
-    The bus_space_peek_N() and
-    bus_space_poke_N() family of functions provide a
-    mechanism to handle these exceptions gracefully without the risk of crashing
-    the system.

-
As with
-    ()
-    and bus_space_write_N(), the peek and poke functions
-    provide the ability to read and write 1, 2, 4, and 8 byte data items on
-    busses which support those access sizes. All of the constraints specified in
-    the descriptions of the bus_space_read_N() and
-    bus_space_write_N() functions also apply to
-    bus_space_peek_N() and
-    bus_space_poke_N().

-
In addition, explicit calls to the
-    ()
-    function are not required as the implementation will ensure all pending
-    operations complete before the peek or poke operation starts. The
-    implementation will also ensure that the peek or poke operations complete
-    before returning.

-
The return value indicates the outcome of
-    the peek or poke operation. A return value of zero implies that a hardware
-    device is responding to the operation at the specified offset in the bus
-    space. A non-zero return value indicates that the kernel intercepted a
-    hardware exception (e.g., bus error) when the peek or poke operation was
-    attempted. Note that some busses are incapable of generating exceptions when
-    non-existent hardware is accessed. In such cases, these functions will
-    always return zero and the value of the data read by
-    ()
-    will be unspecified.

-
Finally, it should be noted that at this
-    time the
-    ()
-    and bus_space_poke_N() functions are not re-entrant
-    and should not, therefore, be used from within an interrupt service routine.
-    This constraint may be removed at some point in the future.

-

-

-  
(space,
-    handle, offset,
-    datap)

-  

-  
(space,
-    handle, offset,
-    datap)

-  

-  
(space,
-    handle, offset,
-    datap)

-  

-  
(space,
-    handle, offset,
-    datap)

-  

-    
The
-        ()
-        family of functions cautiously read a 1, 2, 4, or 8 byte data item from
-        the offset specified by offset in the region
-        specified by handle of the bus space specified by
-        space. The data item read is stored in the
-        location pointed to by datap. It is permissible
-        for datap to be NULL, in which case the data item
-        will be discarded after being read.

-    

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-    
The
-        ()
-        family of functions cautiously write a 1, 2, 4, or 8 byte data item
-        specified by value to the offset specified by
-        offset in the region specified by
-        handle of the bus space specified by
-        space.

-  

-

-

-

-

-
In order to allow high-performance buffering implementations to
-    avoid bus activity on every operation, read and write ordering should be
-    specified explicitly by drivers when necessary. The
-    bus_space_barrier() function provides that
-  ability.

-

-

-
The bus_space_barrier() function enforces
-    ordering of bus space read and write operations for the specified subregion
-    (described by the offset and
-    length parameters) of the region named by
-    handle in the space named by
-    space.

-
The flags argument controls what types of
-    operations are to be ordered. Supported flags are:

-

-  

-  
Synchronize read operations.

-  

-  
Synchronize write operations.

-

-
Those flags can be combined (or-ed together) to enforce ordering
-    on both read and write operations.

-
All of the specified type(s) of operation which are done to the
-    region before the barrier operation are guaranteed to complete before any of
-    the specified type(s) of operation done after the barrier.

-
Example: Consider a hypothetical device with two single-byte
-    ports, one write-only input port (at offset 0) and a read-only output port
-    (at offset 1). Operation of the device is as follows: data bytes are written
-    to the input port, and are placed by the device on a stack, the top of which
-    is read by reading from the output port. The sequence to correctly write two
-    data bytes to the device then read those two data bytes back would be:

-

-
/*
- * t and h are the tag and handle for the mapped device's
- * space.
- */
-bus_space_write_1(t, h, 0, data0);
-bus_space_barrier(t, h, 0, 1, BUS_SPACE_BARRIER_WRITE);  /* 1 */
-bus_space_write_1(t, h, 0, data1);
-bus_space_barrier(t, h, 0, 2,
-    BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE);     /* 2 */
-ndata1 = bus_space_read_1(t, h, 1);
-bus_space_barrier(t, h, 1, 1, BUS_SPACE_BARRIER_READ);   /* 3 */
-ndata0 = bus_space_read_1(t, h, 1);
-/* data0 == ndata0, data1 == ndata1 */

-

-
The first barrier makes sure that the first write finishes before
-    the second write is issued, so that two writes to the input port are done in
-    order and are not collapsed into a single write. This ensures that the data
-    bytes are written to the device correctly and in order.

-
The second barrier makes sure that the writes to the output port
-    finish before any of the reads to the input port are issued, thereby making
-    sure that all of the writes are finished before data is read. This ensures
-    that the first byte read from the device really is the last one that was
-    written.

-
The third barrier makes sure that the first read finishes before
-    the second read is issued, ensuring that data is read correctly and in
-    order.

-
The barriers in the example above are specified to cover the
-    absolute minimum number of bus space locations. It is correct (and often
-    easier) to make barrier operations cover the device's whole range of bus
-    space, that is, to specify an offset of zero and the size of the whole
-    region.

-

-

-

-

-
Some devices use buffers which are mapped as regions in bus space.
-    Often, drivers want to copy the contents of those buffers to or from memory,
-    e.g. into mbufs which can be passed to higher levels of the system or from
-    mbufs to be output to a network. In order to allow drivers to do this as
-    efficiently as possible, the
-    ()
-    and bus_space_write_region_N() families of functions
-    are provided.

-
Drivers occasionally need to copy one
-    region of a bus space to another, or to set all locations in a region of bus
-    space to contain a single value. The
-    ()
-    family of functions and the bus_space_set_region_N()
-    family of functions allow drivers to perform these operations.

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-
The bus_space_read_region_N() family of
-    functions reads count 1, 2, 4, or 8 byte data items
-    from bus space starting at byte offset offset in the
-    region specified by handle of the bus space specified
-    by space and writes them into the array specified by
-    datap. Each successive data item is read from an
-    offset 1, 2, 4, or 8 bytes after the previous data item (depending on which
-    function is used). All locations being read must lie within the bus space
-    region specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data items being read and the data array pointer should be properly
-    aligned. On some systems, not obeying these requirements may cause incorrect
-    data to be read, on others it may cause a system crash.

-
Read operations done by the
-    ()
-    functions may be executed in any order. They may also be executed out of
-    order with respect to other pending read and write operations unless order
-    is enforced by use of the bus_space_barrier()
-    function. There is no way to insert barriers between reads of individual bus
-    space locations executed by the
-    bus_space_read_region_N() functions.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-
The bus_space_write_region_N() family of
-    functions reads count 1, 2, 4, or 8 byte data items
-    from the array specified by datap and writes them to
-    bus space starting at byte offset offset in the region
-    specified by handle of the bus space specified by
-    space. Each successive data item is written to an
-    offset 1, 2, 4, or 8 bytes after the previous data item (depending on which
-    function is used). All locations being written must lie within the bus space
-    region specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data items being written and the data array pointer should be
-    properly aligned. On some systems, not obeying these requirements may cause
-    incorrect data to be written, on others it may cause a system crash.

-
Write operations done by the
-    ()
-    functions may be executed in any order. They may also be executed out of
-    order with respect to other pending read and write operations unless order
-    is enforced by use of the bus_space_barrier()
-    function. There is no way to insert barriers between writes of individual
-    bus space locations executed by the
-    bus_space_write_region_N() functions.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-
(space,
-  srchandle, srcoffset,
-  dsthandle, dstoffset,
-  count)

-

-

-
(space,
-  srchandle, srcoffset,
-  dsthandle, dstoffset,
-  count)

-

-

-
(space,
-  srchandle, srcoffset,
-  dsthandle, dstoffset,
-  count)

-

-

-
(space,
-  srchandle, srcoffset,
-  dsthandle, dstoffset,
-  count)

-
The bus_space_copy_region_N() family of
-    functions copies count 1, 2, 4, or 8 byte data items
-    in bus space from the area starting at byte offset
-    srcoffset in the region specified by
-    srchandle of the bus space specified by
-    space to the area starting at byte offset
-    dstoffset in the region specified by
-    dsthandle in the same bus space. Each successive data
-    item read or written has an offset 1, 2, 4, or 8 bytes after the previous
-    data item (depending on which function is used). All locations being read
-    and written must lie within the bus space region specified by their
-    respective handles.

-
For portability, the starting addresses of the regions specified
-    by the each handle plus its respective offset should be a multiple of the
-    size of data items being copied. On some systems, not obeying this
-    requirement may cause incorrect data to be copied, on others it may cause a
-    system crash.

-
Read and write operations done by
-    the
-    ()
-    functions may be executed in any order. They may also be executed out of
-    order with respect to other pending read and write operations unless order
-    is enforced by use of the bus_space_barrier()
-    function. There is no way to insert barriers between reads or writes of
-    individual bus space locations executed by the
-    bus_space_copy_region_N() functions.

-
Overlapping copies between
-    different subregions of a single region of bus space are handled correctly
-    by the
-    ()
-    functions.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-
(space,
-  handle, offset,
-  value, count)

-

-

-
(space,
-  handle, offset,
-  value, count)

-

-

-
(space,
-  handle, offset,
-  value, count)

-

-

-
(space,
-  handle, offset,
-  value, count)

-
The bus_space_set_region_N() family of
-    functions writes the given value to
-    count 1, 2, 4, or 8 byte data items in bus space
-    starting at byte offset offset in the region specified
-    by handle of the bus space specified by
-    space. Each successive data item has an offset 1, 2,
-    4, or 8 bytes after the previous data item (depending on which function is
-    used). All locations being written must lie within the bus space region
-    specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data items being written. On some systems, not obeying this
-    requirement may cause incorrect data to be written, on others it may cause a
-    system crash.

-
Write operations done by the
-    ()
-    functions may be executed in any order. They may also be executed out of
-    order with respect to other pending read and write operations unless order
-    is enforced by use of the bus_space_barrier()
-    function. There is no way to insert barriers between writes of individual
-    bus space locations executed by the
-    bus_space_set_region_N() functions.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-

-

-
Some devices implement single locations in bus space which are to
-    be read or written multiple times to communicate data, e.g. some ethernet
-    devices' packet buffer FIFOs. In order to allow drivers to manipulate these
-    types of devices as efficiently as possible, the
-    (),
-    bus_space_set_multi_N(), and
-    bus_space_write_multi_N() families of functions are
-    provided.

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-
The bus_space_read_multi_N() family of
-    functions reads count 1, 2, 4, or 8 byte data items
-    from bus space at byte offset offset in the region
-    specified by handle of the bus space specified by
-    space and writes them into the array specified by
-    datap. Each successive data item is read from the same
-    location in bus space. The location being read must lie within the bus space
-    region specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data items being read and the data array pointer should be properly
-    aligned. On some systems, not obeying these requirements may cause incorrect
-    data to be read, on others it may cause a system crash.

-
Read operations done by the
-    ()
-    functions may be executed out of order with respect to other pending read
-    and write operations unless order is enforced by use of the
-    bus_space_barrier() function. Because the
-    bus_space_read_multi_N() functions read the same bus
-    space location multiple times, they place an implicit read barrier between
-    each successive read of that bus space location.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-

-

-
(space,
-  handle, offset,
-  datap, count)

-
The bus_space_write_multi_N() family of
-    functions reads count 1, 2, 4, or 8 byte data items
-    from the array specified by datap and writes them into
-    bus space at byte offset offset in the region
-    specified by handle of the bus space specified by
-    space. Each successive data item is written to the
-    same location in bus space. The location being written must lie within the
-    bus space region specified by handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data items being written and the data array pointer should be
-    properly aligned. On some systems, not obeying these requirements may cause
-    incorrect data to be written, on others it may cause a system crash.

-
Write operations done by the
-    ()
-    functions may be executed out of order with respect to other pending read
-    and write operations unless order is enforced by use of the
-    bus_space_barrier() function. Because the
-    bus_space_write_multi_N() functions write the same
-    bus space location multiple times, they place an implicit write barrier
-    between each successive write of that bus space location.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-
(space,
-  handle, offset,
-  value, count)

-

-

-
(space,
-  handle, offset,
-  value, count)

-

-

-
(space,
-  handle, offset,
-  value, count)

-

-

-
(space,
-  handle, offset,
-  value, count)

-
The bus_space_set_multi_N() writes
-    value into bus space at byte offset
-    offset in the region specified by
-    handle of the bus space specified by
-    space, count times. The location
-    being written must lie within the bus space region specified by
-    handle.

-
For portability, the starting address of the region specified by
-    handle plus the offset should be a multiple of the
-    size of data items being written and the data array pointer should be
-    properly aligned. On some systems, not obeying these requirements may cause
-    incorrect data to be written, on others it may cause a system crash.

-
Write operations done by the
-    ()
-    functions may be executed out of order with respect to other pending read
-    and write operations unless order is enforced by use of the
-    bus_space_barrier() function. Because the
-    bus_space_set_multi_N() functions write the same bus
-    space location multiple times, they place an implicit write barrier between
-    each successive write of that bus space location.

-
These functions will never fail. If they would fail (e.g. because
-    of an argument error), that indicates a software bug which should cause a
-    panic. In that case, they will never return.

-

-

-

-

-
Most of the bus_space functions imply a
-    host byte-order and a bus byte-order and take care of any translation for
-    the caller. In some cases, however, hardware may map a FIFO or some other
-    memory region for which the caller may want to use multi-word, yet
-    untranslated access. Access to these types of memory regions should be with
-    the
-    ()
-    functions.

-

-

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-

-
These functions are defined just as their non-stream counterparts,
-    except that they provide no byte-order translation.

-

-

-

-
The current NetBSD version of the
-    bus_space interface specification differs slightly
-    from the original specification that came into wide use and
-    FreeBSD adopted. A few of the function names and
-    arguments have changed for consistency and increased functionality.

-

-

-

-
bus_dma(9)

-

-

-

-
The bus_space functions were introduced in
-    a different form (memory and I/O spaces were accessed via different sets of
-    functions) in NetBSD 1.2. The functions were merged
-    to work on generic “spaces” early in the
-    NetBSD 1.3 development cycle, and many drivers were
-    converted to use them. This document was written later during the
-    NetBSD 1.3 development cycle, and the specification
-    was updated to fix some consistency problems and to add some missing
-    functionality.

-
The manual page was then adapted to the version of the interface
-    that FreeBSD imported for the CAM SCSI drivers, plus
-    subsequent evolution. The FreeBSD
-    bus_space version was imported in
-    FreeBSD 3.0.

-

-

-

-
The bus_space interfaces were designed and
-    implemented by the NetBSD developer community.
-    Primary contributors and implementors were Chris
-    Demetriou, Jason Thorpe, and
-    Charles Hannum, but the rest of the
-    NetBSD developers and the user community played a
-    significant role in development.

-
Justin Gibbs ported these interfaces to
-    FreeBSD.

-
Chris Demetriou wrote this manual
-  page.

-
Warner Losh modified it for the
-    FreeBSD implementation.

-

-

-

-
This manual may not completely and accurately document the
-    interface, and many parts of the interface are unspecified.

-

-

-
-  
-    
-    
-  
-
May 1, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/byteorder.9 4.html b/static/freebsd/man9/byteorder.9 4.html
deleted file mode 100644
index 84a05bb1..00000000
--- a/static/freebsd/man9/byteorder.9 4.html	
+++ /dev/null
@@ -1,219 +0,0 @@
-
-  
-    
-    
-    
-  
-
BYTEORDER(9)Kernel Developer's ManualBYTEORDER(9)

-

-

-

-
bswap16, bswap32,
-    bswap64, be16toh,
-    be32toh, be64toh,
-    htobe16, htobe32,
-    htobe64, htole16,
-    htole32, htole64,
-    le16toh, le32toh,
-    le64toh, be16enc,
-    be16dec, be32enc,
-    be32dec, be64enc,
-    be64dec, le16enc,
-    le16dec, le32enc,
-    le32dec, le64enc,
-    le64dec — byte order
-    operations

-

-

-

-
#include
-    <sys/endian.h>

-
uint16_t
-  

-  bswap16(uint16_t
-    int16);

-
uint32_t
-  

-  bswap32(uint32_t
-    int32);

-
uint64_t
-  

-  bswap64(uint64_t
-    int64);

-
uint16_t
-  

-  be16toh(uint16_t
-    big16);

-
uint32_t
-  

-  be32toh(uint32_t
-    big32);

-
uint64_t
-  

-  be64toh(uint64_t
-    big64);

-
uint16_t
-  

-  htobe16(uint16_t
-    host16);

-
uint32_t
-  

-  htobe32(uint32_t
-    host32);

-
uint64_t
-  

-  htobe64(uint64_t
-    host64);

-
uint16_t
-  

-  htole16(uint16_t
-    host16);

-
uint32_t
-  

-  htole32(uint32_t
-    host32);

-
uint64_t
-  

-  htole64(uint64_t
-    host64);

-
uint16_t
-  

-  le16toh(uint16_t
-    little16);

-
uint32_t
-  

-  le32toh(uint32_t
-    little32);

-
uint64_t
-  

-  le64toh(uint64_t
-    little64);

-
uint16_t
-  

-  be16dec(const
-    void *);

-
uint32_t
-  

-  be32dec(const
-    void *);

-
uint64_t
-  

-  be64dec(const
-    void *);

-
uint16_t
-  

-  le16dec(const
-    void *);

-
uint32_t
-  

-  le32dec(const
-    void *);

-
uint64_t
-  

-  le64dec(const
-    void *);

-
void
-  

-  be16enc(void
-    *, uint16_t);

-
void
-  

-  be32enc(void
-    *, uint32_t);

-
void
-  

-  be64enc(void
-    *, uint64_t);

-
void
-  

-  le16enc(void
-    *, uint16_t);

-
void
-  

-  le32enc(void
-    *, uint32_t);

-
void
-  

-  le64enc(void
-    *, uint64_t);

-

-

-

-
The
-    (),
-    (),
-    and
-    ()
-    functions return a byte order swapped integer. On big endian systems, the
-    number is converted to little endian byte order. On little endian systems,
-    the number is converted to big endian byte order.

-
The
-    (),
-    (),
-    and
-    ()
-    functions return a big endian byte ordered integer converted to the system's
-    native byte order. The return value will be the same as the argument on big
-    endian systems.

-
The
-    (),
-    (),
-    and
-    ()
-    functions return a little endian byte ordered integer converted to the
-    system's native byte order. The return value will be the same as the
-    argument on little endian systems.

-
The
-    (),
-    (),
-    and
-    ()
-    functions return an integer in the system's native byte order converted to
-    big endian byte order. The return value will be the same as the argument on
-    big endian systems.

-
The
-    (),
-    (),
-    and
-    ()
-    functions return a integer in the system's native byte order converted to
-    little endian byte order. The return value will be the same as the argument
-    on little endian systems.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    and
-    ()
-    functions encode and decode integers to/from byte strings on any alignment
-    in big/little endian format.

-

-

-

-
byteorder(3)

-

-

-

-
The hto*() and
-    *toh() functions first appeared in
-    FreeBSD 5.0, and were originally developed by the
-    NetBSD project.

-
The encode/decode functions first appeared in
-    FreeBSD 5.1.

-

-

-
-  
-    
-    
-  
-
April 29, 2002FreeBSD 15.0

diff --git a/static/freebsd/man9/callout.9 3.html b/static/freebsd/man9/callout.9 3.html
deleted file mode 100644
index e2951509..00000000
--- a/static/freebsd/man9/callout.9 3.html	
+++ /dev/null
@@ -1,614 +0,0 @@
-
-  
-    
-    
-    
-  
-
CALLOUT(9)Kernel Developer's ManualCALLOUT(9)

-

-

-

-
callout_active,
-    callout_deactivate,
-    callout_drain, callout_init,
-    callout_init_mtx,
-    callout_init_rm,
-    callout_init_rw,
-    callout_pending,
-    callout_reset,
-    callout_reset_curcpu,
-    callout_reset_on,
-    callout_reset_sbt,
-    callout_reset_sbt_curcpu,
-    callout_reset_sbt_on,
-    callout_schedule,
-    callout_schedule_curcpu,
-    callout_schedule_on,
-    callout_schedule_sbt,
-    callout_schedule_sbt_curcpu,
-    callout_schedule_sbt_on,
-    callout_stop, callout_when
-    — execute a function after a specified length of
-    time

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/callout.h>

-

-
typedef void callout_func_t (void *);

-

-

-int
-

-callout_active(struct
-  callout *c);
-
void
-  

-  callout_deactivate(struct
-    callout *c);

-
int
-  

-  callout_drain(struct
-    callout *c);

-
void
-  

-  callout_init(struct
-    callout *c, int
-    mpsafe);

-
void
-  

-  callout_init_mtx(struct
-    callout *c, struct mtx
-    *mtx, int
-  flags);

-
void
-  

-  callout_init_rm(struct
-    callout *c, struct rmlock
-    *rm, int
-  flags);

-
void
-  

-  callout_init_rw(struct
-    callout *c, struct rwlock
-    *rw, int
-  flags);

-
int
-  

-  callout_pending(struct
-    callout *c);

-
int
-  

-  callout_reset(struct callout *c,
-    int ticks, callout_func_t *func,
-    void *arg);

-
int
-  

-  callout_reset_curcpu(struct callout
-    *c, int ticks, callout_func_t
-    *func, void *arg);

-
int
-  

-  callout_reset_on(struct callout
-    *c, int ticks, callout_func_t
-    *func, void *arg, int
-    cpu);

-
int
-  

-  callout_reset_sbt(struct callout
-    *c, sbintime_t sbt, sbintime_t
-    pr, callout_func_t *func, void
-    *arg, int flags);

-
int
-  

-  callout_reset_sbt_curcpu(struct
-    callout *c, sbintime_t sbt,
-    sbintime_t pr, callout_func_t
-    *func, void *arg, int
-    flags);

-
int
-  

-  callout_reset_sbt_on(struct callout
-    *c, sbintime_t sbt, sbintime_t
-    pr, callout_func_t *func, void
-    *arg, int cpu, int
-  flags);

-
int
-  

-  callout_schedule(struct
-    callout *c, int
-    ticks);

-
int
-  

-  callout_schedule_curcpu(struct
-    callout *c, int
-    ticks);

-
int
-  

-  callout_schedule_on(struct
-    callout *c, int
-    ticks, int
-  cpu);

-
int
-  

-  callout_schedule_sbt(struct callout
-    *c, sbintime_t sbt, sbintime_t
-    pr, int flags);

-
int
-  

-  callout_schedule_sbt_curcpu(struct
-    callout *c, sbintime_t sbt,
-    sbintime_t pr, int flags);

-
int
-  

-  callout_schedule_sbt_on(struct callout
-    *c, sbintime_t sbt, sbintime_t
-    pr, int cpu, int
-  flags);

-
int
-  

-  callout_stop(struct
-    callout *c);

-
sbintime_t
-  

-  callout_when(sbintime_t sbt,
-    sbintime_t precision, int flags,
-    sbintime_t *sbt_res, sbintime_t
-    *precision_res);

-

-

-

-
The callout API is used to schedule a call
-    to an arbitrary function at a specific time in the future. Consumers of this
-    API are required to allocate a callout structure (struct callout) for each
-    pending function invocation. This structure stores state about the pending
-    function invocation including the function to be called and the time at
-    which the function should be invoked. Pending function calls can be
-    cancelled or rescheduled to a different time. In addition, a callout
-    structure may be reused to schedule a new function call after a scheduled
-    call is completed.

-
Callouts only provide a single-shot mode. If a consumer requires a
-    periodic timer, it must explicitly reschedule each function call. This is
-    normally done by rescheduling the subsequent call within the called
-    function.

-
Callout functions must not sleep. They may not acquire sleepable
-    locks, wait on condition variables, perform blocking allocation requests, or
-    invoke any other action that might sleep.

-
Each callout structure must be initialized by
-    (),
-    callout_init_mtx(),
-    callout_init_rm(), or
-    callout_init_rw() before it is passed to any of the
-    other callout functions. The callout_init() function
-    initializes a callout structure in c that is not
-    associated with a specific lock. If the mpsafe
-    argument is zero, the callout structure is not considered to be
-    “multi-processor safe”; and the Giant lock will be acquired
-    before calling the callout function and released when the callout function
-    returns.

-
The
-    (),
-    callout_init_rm(), and
-    ()
-    functions initialize a callout structure in c that is
-    associated with a specific lock. The lock is specified by the
-    mtx, rm, or
-    rw parameter. The associated lock must be held while
-    stopping or rescheduling the callout. The callout subsystem acquires the
-    associated lock before calling the callout function and releases it after
-    the function returns. If the callout was cancelled while the callout
-    subsystem waited for the associated lock, the callout function is not
-    called, and the associated lock is released. This ensures that stopping or
-    rescheduling the callout will abort any previously scheduled invocation.

-
A sleepable read-mostly lock (one initialized
-    with the RM_SLEEPABLE flag) may not be used with
-    ().
-    Similarly, other sleepable lock types such as sx(9) and
-    lockmgr(9) cannot be used with callouts because sleeping
-    is not permitted in the callout subsystem.

-
These flags may be
-    specified for
-    (),
-    callout_init_rm(), or
-    ():

-

-  

-  
The callout function will release the associated lock itself, so the
-      callout subsystem should not attempt to unlock it after the callout
-      function returns.

-  

-  
The lock is only acquired in read mode when running the callout handler.
-      This flag is ignored by callout_init_mtx().

-

-
The function
-    ()
-    cancels a callout c if it is currently pending. If the
-    callout is pending and successfully stopped, then
-    callout_stop() returns a value of one. If the
-    callout is not set, or has already been serviced, then negative one is
-    returned. If the callout is currently being serviced and cannot be stopped,
-    then zero will be returned. If the callout is currently being serviced and
-    cannot be stopped, and at the same time a next invocation of the same
-    callout is also scheduled, then callout_stop()
-    unschedules the next run and returns zero. If the callout has an associated
-    lock, then that lock must be held when this function is called.

-
The function
-    ()
-    is identical to callout_stop() except that it will
-    wait for the callout c to complete if it is already in
-    progress. This function MUST NOT be called while holding any locks on which
-    the callout might block, or deadlock will result. Note that if the callout
-    subsystem has already begun processing this callout, then the callout
-    function may be invoked before callout_drain()
-    returns. However, the callout subsystem does guarantee that the callout will
-    be fully stopped before callout_drain() returns.

-
The
-    ()
-    and
-    ()
-    function families schedule a future function invocation for callout
-    c. If c already has a pending
-    callout, it is cancelled before the new invocation is scheduled. These
-    functions return a value of one if a pending callout was cancelled and zero
-    if there was no pending callout. If the callout has an associated lock, then
-    that lock must be held when any of these functions are called.

-
The time at which the callout function will be invoked is
-    determined by either the ticks argument or the
-    sbt, pr, and
-    flags arguments. When ticks is
-    used, the callout is scheduled to execute after
-    ticks/hz seconds. Non-positive
-    values of ticks are silently converted to the value
-    ‘1’.

-
The sbt, pr, and
-    flags arguments provide more control over the
-    scheduled time including support for higher resolution times, specifying the
-    precision of the scheduled time, and setting an absolute deadline instead of
-    a relative timeout. The callout is scheduled to execute in a time window
-    which begins at the time specified in sbt and extends
-    for the amount of time specified in pr. If
-    sbt specifies a time in the past, the window is
-    adjusted to start at the current time. A non-zero value for
-    pr allows the callout subsystem to coalesce callouts
-    scheduled close to each other into fewer timer interrupts, reducing
-    processing overhead and power consumption. These flags
-    may be specified to adjust the interpretation of sbt
-    and pr:

-

-  

-  
Handle the sbt argument as an absolute time since
-      boot. By default, sbt is treated as a relative
-      amount of time, similar to ticks.

-  

-  
Run the handler directly from hardware interrupt context instead of from
-      the softclock thread. This reduces latency and overhead, but puts more
-      constraints on the callout function. Callout functions run in this context
-      may use only spin mutexes for locking and should be as small as possible
-      because they run with absolute priority.

-  
()

-  
Specifies relative event time precision as binary logarithm of time
-      interval divided by acceptable time deviation: 1 -- 1/2, 2 -- 1/4, etc.
-      Note that the larger of pr or this value is used as
-      the length of the time window. Smaller values (which result in larger time
-      intervals) allow the callout subsystem to aggregate more events in one
-      timer interrupt.

-  

-  
The sbt argument specifies the absolute time at
-      which the callout should be run, and the pr argument
-      specifies the requested precision, which will not be adjusted during the
-      scheduling process. The sbt and
-      pr values should be calculated by an earlier call to
-      callout_when() which uses the user-supplied
-      sbt, pr, and
-      flags values.

-  

-  
Align the timeouts to
-      ()
-      calls if possible.

-

-
The
-    ()
-    functions accept a func argument which identifies the
-    function to be called when the time expires. It must be a pointer to a
-    function that takes a single void * argument. Upon
-    invocation, func will receive
-    arg as its only argument. The
-    ()
-    functions reuse the func and arg
-    arguments from the previous callout. Note that one of the
-    callout_reset() functions must always be called to
-    initialize func and arg before
-    one of the callout_schedule() functions can be
-  used.

-
The callout subsystem provides a softclock
-    thread for each CPU in the system. Callouts are assigned to a single CPU and
-    are executed by the softclock thread for that CPU. Initially, callouts are
-    assigned to CPU 0. The
-    (),
-    (),
-    ()
-    and
-    ()
-    functions assign the callout to CPU cpu. The
-    (),
-    (),
-    ()
-    and
-    ()
-    functions assign the callout to the current CPU. The
-    callout_reset(),
-    (),
-    callout_schedule() and
-    ()
-    functions schedule the callout to execute in the softclock thread of the CPU
-    to which it is currently assigned.

-
Softclock threads are not pinned to their respective CPUs by
-    default. The softclock thread for CPU 0 can be pinned to CPU 0 by setting
-    the kern.pin_default_swi loader tunable to a non-zero
-    value. Softclock threads for CPUs other than zero can be pinned to their
-    respective CPUs by setting the kern.pin_pcpu_swi
-    loader tunable to a non-zero value.

-
The macros
-    (),
-    callout_active() and
-    callout_deactivate() provide access to the current
-    state of the callout. The callout_pending() macro
-    checks whether a callout is pending; a callout is
-    considered pending when a timeout has been set but the
-    time has not yet arrived. Note that once the timeout time arrives and the
-    callout subsystem starts to process this callout,
-    callout_pending() will return
-    FALSE even though the callout function may not have
-    finished (or even begun) executing. The
-    callout_active() macro checks whether a callout is
-    marked as active, and the
-    callout_deactivate() macro clears the callout's
-    active flag. The callout subsystem marks a callout as
-    active when a timeout is set and it clears the
-    active flag in callout_stop() and
-    callout_drain(), but it
-    
-    clear it when a callout expires normally via the execution of the callout
-    function.

-
The
-    ()
-    function may be used to pre-calculate the absolute time at which the timeout
-    should be run and the precision of the scheduled run time according to the
-    required time sbt, precision
-    precision, and additional adjustments requested by the
-    flags argument. Flags accepted by the
-    callout_when() function are the same as flags for
-    the callout_reset() function. The resulting time is
-    assigned to the variable pointed to by the sbt_res
-    argument, and the resulting precision is assigned to
-    *precision_res. When passing the results to
-    callout_reset, add the C_PRECALC
-    flag to flags, to avoid incorrect re-adjustment. The
-    function is intended for situations where precise time of the callout run
-    should be known in advance, since trying to read this time from the callout
-    structure itself after a callout_reset() call is
-    racy.

-

-

-
The callout subsystem invokes callout functions from its own
-    thread context. Without some kind of synchronization, it is possible that a
-    callout function will be invoked concurrently with an attempt to stop or
-    reset the callout by another thread. In particular, since callout functions
-    typically acquire a lock as their first action, the callout function may
-    have already been invoked, but is blocked waiting for that lock at the time
-    that another thread tries to reset or stop the callout.

-
There are three main techniques for addressing these
-    synchronization concerns. The first approach is preferred as it is the
-    simplest:

-
    
-  
  1. Callouts can be associated with a specific lock
-      when they are initialized by
-      (),
-      callout_init_rm(), or
-      ().
-      When a callout is associated with a lock, the callout subsystem acquires
-      the lock before the callout function is invoked. This allows the callout
-      subsystem to transparently handle races between callout cancellation,
-      scheduling, and execution. Note that the associated lock must be acquired
-      before calling callout_stop() or one of the
-      callout_reset() or
-      callout_schedule() functions to provide this
-      safety.
-    
    A callout initialized via
-        ()
-        with mpsafe set to zero is implicitly associated
-        with the Giant mutex. If
-        Giant is held when cancelling or rescheduling the
-        callout, then its use will prevent races with the callout function.
    
-  
    2. 
-  
  2. The return value from callout_stop() (or the
-      callout_reset() and
-      callout_schedule() function families) indicates
-      whether or not the callout was removed. If it is known that the callout
-      was set and the callout function has not yet executed, then a return value
-      of FALSE indicates that the callout function is
-      about to be called. For example:
-    
    
-    
    if (sc->sc_flags & SCFLG_CALLOUT_RUNNING) {
-	if (callout_stop(&sc->sc_callout)) {
-		sc->sc_flags &= ~SCFLG_CALLOUT_RUNNING;
-		/* successfully stopped */
-	} else {
-		/*
-		 * callout has expired and callout
-		 * function is about to be executed
-		 */
-	}
-}
    
-    
    
-  
    3. 
-  
  3. The callout_pending(),
-      callout_active() and
-      callout_deactivate() macros can be used together
-      to work around the race conditions. When a callout's timeout is set, the
-      callout subsystem marks the callout as both active and
-      pending. When the timeout time arrives, the callout
-      subsystem begins processing the callout by first clearing the
-      pending flag. It then invokes the callout function
-      without changing the active flag, and does not clear the
-      active flag even after the callout function returns. The
-      mechanism described here requires the callout function itself to clear the
-      active flag using the
-      callout_deactivate() macro. The
-      callout_stop() and
-      callout_drain() functions always clear both the
-      active and pending flags before
-      returning.
-    
    The callout function should first check
-        the pending flag and return without action if
-        ()
-        returns TRUE. This indicates that the callout
-        was rescheduled using callout_reset() just
-        before the callout function was invoked. If
-        callout_active() returns
-        FALSE then the callout function should also
-        return without action. This indicates that the callout has been stopped.
-        Finally, the callout function should call
-        callout_deactivate() to clear the
-        active flag. For example:
    
-    
    
-    
    mtx_lock(&sc->sc_mtx);
-if (callout_pending(&sc->sc_callout)) {
-	/* callout was reset */
-	mtx_unlock(&sc->sc_mtx);
-	return;
-}
-if (!callout_active(&sc->sc_callout)) {
-	/* callout was stopped */
-	mtx_unlock(&sc->sc_mtx);
-	return;
-}
-callout_deactivate(&sc->sc_callout);
-/* rest of callout function */
    
-    
    
-    
    Together with appropriate synchronization,
-        such as the mutex used above, this approach permits the
-        ()
-        and callout_reset() functions to be used at any
-        time without races. For example:
    
-    
    
-    
    mtx_lock(&sc->sc_mtx);
-callout_stop(&sc->sc_callout);
-/* The callout is effectively stopped now. */
    
-    
    
-    
    If the callout is still pending then
-        these functions operate normally, but if processing of the callout has
-        already begun then the tests in the callout function cause it to return
-        without further action. Synchronization between the callout function and
-        other code ensures that stopping or resetting the callout will never be
-        attempted while the callout function is past the
-        ()
-        call.
    
-    
    The above technique additionally ensures
-        that the active flag always reflects whether the
-        callout is effectively enabled or disabled. If
-        ()
-        returns false, then the callout is effectively disabled, since even if
-        the callout subsystem is actually just about to invoke the callout
-        function, the callout function will return without action.
    
-  
    4. 
-

-
There is one final race condition that must
-    be considered when a callout is being stopped for the last time. In this
-    case it may not be safe to let the callout function itself detect that the
-    callout was stopped, since it may need to access data objects that have
-    already been destroyed or recycled. To ensure that the callout is completely
-    finished, a call to
-    ()
-    should be used. In particular, a callout should always be drained prior to
-    destroying its associated lock or releasing the storage for the callout
-    structure.

-

-

-

-

-
The callout_active() macro returns the
-    state of a callout's active flag.

-
The callout_pending() macro returns the
-    state of a callout's pending flag.

-
The callout_reset() and
-    callout_schedule() function families return a value
-    of one if the callout was pending before the new function invocation was
-    scheduled.

-
The callout_stop() and
-    callout_drain() functions return a value of one if
-    the callout was still pending when it was called, a zero if the callout
-    could not be stopped and a negative one is it was either not running or has
-    already completed.

-

-

-

-
dtrace_callout_execute(4)

-

-

-

-
FreeBSD initially used the long standing
-    BSD linked list callout mechanism which offered O(n)
-    insertion and removal running time but did not generate or require handles
-    for untimeout operations.

-
FreeBSD 3.0 introduced a new set of
-    timeout and untimeout routines from NetBSD based on
-    the work of Adam M. Costello and
-    George Varghese, published in a technical report
-    entitled Redesigning the BSD Callout and Timer
-    Facilities and modified for inclusion in
-    FreeBSD by Justin T. Gibbs.
-    The original work on the data structures used in that implementation was
-    published by G. Varghese and A.
-    Lauck in the paper Hashed and Hierarchical Timing
-    Wheels: Data Structures for the Efficient Implementation of a Timer
-    Facility in the Proceedings of the 11th ACM Annual
-    Symposium on Operating Systems Principles.

-
FreeBSD 3.3 introduced the first
-    implementations of callout_init(),
-    callout_reset(), and
-    callout_stop() which permitted callers to allocate
-    dedicated storage for callouts. This ensured that a callout would always
-    fire unlike timeout() which would silently fail if
-    it was unable to allocate a callout.

-
FreeBSD 5.0 permitted callout handlers to
-    be tagged as MPSAFE via callout_init().

-
FreeBSD 5.3 introduced
-    callout_drain().

-
FreeBSD 6.0 introduced
-    callout_init_mtx().

-
FreeBSD 8.0 introduced per-CPU callout
-    wheels, callout_init_rw(), and
-    callout_schedule().

-
FreeBSD 9.0 changed the underlying timer
-    interrupts used to drive callouts to prefer one-shot event timers instead of
-    a periodic timer interrupt.

-
FreeBSD 10.0 switched the callout wheel to
-    support tickless operation. These changes introduced
-    sbintime_t and the
-    callout_reset_sbt*() family of functions.
-    FreeBSD 10.0 also added
-    C_DIRECT_EXEC and
-    callout_init_rm().

-
FreeBSD 10.2 introduced the
-    callout_schedule_sbt*() family of functions.

-
FreeBSD 11.0 introduced
-    callout_async_drain(). FreeBSD
-    11.1 introduced callout_when().
-    FreeBSD 13.0 removed
-    timeout_t, timeout(), and
-    untimeout().

-

-

-
-  
-    
-    
-  
-
November 4, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/casuword.9 3.html b/static/freebsd/man9/casuword.9 3.html
deleted file mode 100644
index eaa380ab..00000000
--- a/static/freebsd/man9/casuword.9 3.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
CASU(9)Kernel Developer's ManualCASU(9)

-

-

-

-
casueword,
-    casueword32, casuword,
-    casuword32 — fetch, compare
-    and store data from user-space

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
int
-  

-  casueword(volatile u_long *base,
-    u_long oldval, u_long *oldvalp,
-    u_long newval);

-
int
-  

-  casueword32(volatile uint32_t
-    *base, uint32_t oldval, uint32_t
-    *oldvalp, uint32_t newval);

-
u_long
-  

-  casuword(volatile u_long *base,
-    u_long oldval, u_long
-  newval);

-
uint32_t
-  

-  casuword32(volatile uint32_t
-    *base, uint32_t oldval, uint32_t
-    newval);

-

-

-

-
The casueword functions are designed to
-    perform atomic compare-and-swap operation on the value in the usermode
-    memory of the current process.

-
The casueword routines
-    reads the value from user memory with address base,
-    and compare the value read with oldval. If the
-    values are equal, newval is written to the
-    *base. In case of
-    ()
-    and
-    (),
-    old value is stored into the (kernel-mode) variable pointed by
-    *oldvalp. The userspace value must be naturally
-    aligned.

-
The callers of
-    ()
-    and
-    ()
-    functions cannot distinguish between -1 read from userspace and function
-    failure.

-

-

-

-
The casuword() and
-    casuword32() functions return the data fetched or -1
-    on failure. The casueword() and
-    casueword32() functions return 0 on success, -1 on
-    failure to access memory, and 1 when comparison or store failed. The store
-    can fail on load-linked/store-conditional architectures.

-

-

-

-
atomic(9), fetch(9),
-    store(9)

-

-

-
-  
-    
-    
-  
-
April 19, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/cd.9 3.html b/static/freebsd/man9/cd.9 3.html
deleted file mode 100644
index 344017b2..00000000
--- a/static/freebsd/man9/cd.9 3.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
CD(9)Kernel Developer's ManualCD(9)

-

-

-

-
cd — CDROM driver
-    for the CAM SCSI subsystem

-

-

-

-
The cd device driver provides a read-only
-    interface for CDROM drives (SCSI type 5) and WORM drives (SCSI type 4) that
-    support CDROM type commands. Some drives do not behave as the driver
-    expects. See the QUIRKS section for
-    information on possible flags.

-

-

-

-
Each CD-ROM device can have different interpretations of the SCSI
-    spec. This can lead to drives requiring special handling in the driver. The
-    following is a list of quirks that the driver recognizes.

-

-  

-  
This flag tells the driver not to probe the drive at attach time to see if
-      there is a disk in the drive and find out what size it is. This flag is
-      currently unimplemented in the CAM cd driver.

-  

-  
This flag is for broken drives that return the track numbers in packed BCD
-      instead of straight decimal. If the drive seems to skip tracks (tracks
-      10-15 are skipped) then you have a drive that is in need of this
-    flag.

-  

-  
This flag tells the driver that the device in question is not a changer.
-      This is only necessary for a CDROM device with multiple luns that are not
-      a part of a changer.

-  

-  
This flag tells the driver that the given device is a multi-lun changer.
-      In general, the driver will figure this out automatically when it sees a
-      LUN greater than 0. Setting this flag only has the effect of telling the
-      driver to run the initial read capacity command for LUN 0 of the changer
-      through the changer scheduling code.

-  

-  
This flag tells the driver that the given device only accepts 10 byte MODE
-      SENSE/MODE SELECT commands. In general these types of quirks should not be
-      added to the cd(4) driver. The reason is that the driver
-      does several things to attempt to determine whether the drive in question
-      needs 10 byte commands. First, it issues a CAM Path Inquiry command to
-      determine whether the protocol that the drive speaks typically only allows
-      10 byte commands. (ATAPI and USB are two prominent examples of protocols
-      where you generally only want to send 10 byte commands.) Then, if it gets
-      an ILLEGAL REQUEST error back from a 6 byte MODE SENSE or MODE SELECT
-      command, it attempts to send the 10 byte version of the command instead.
-      The only reason you would need a quirk is if your drive uses a protocol
-      (e.g., SCSI) that typically does not have a problem with 6 byte
-    commands.

-

-

-

-

-

-  
/sys/cam/scsi/scsi_cd.c

-  
is the driver source file.

-

-

-

-

-
cd(4), scsi(4)

-

-

-

-
The cd manual page first appeared in
-    FreeBSD 2.2.

-

-

-

-
This manual page was written by John-Mark
-    Gurney
-    <jmg@FreeBSD.org>. It
-    was updated for CAM and FreeBSD 3.0 by
-    Kenneth Merry
-    <ken@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 25, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/cdefs.9 3.html b/static/freebsd/man9/cdefs.9 3.html
deleted file mode 100644
index 7c6680b3..00000000
--- a/static/freebsd/man9/cdefs.9 3.html	
+++ /dev/null
@@ -1,937 +0,0 @@
-
-  
-    
-    
-    
-  
-
CDEFS(9)Kernel Developer's ManualCDEFS(9)

-

-

-

-
cdefs — compiler
-    portability macro definitions

-

-

-

-
<sys/cdefs.h>
-    defines macros for compiler, C language standard portability, POSIX
-    standards compliance and symbol visibility. It defines programming
-    interfaces for the system header files to adopt to the many environments
-    FreeBSD supports compilation for. It defines
-    convenience macros for the FreeBSD sources, tailored
-    to the base system's needs.

-
Most of these macros are for use inside the
-    FreeBSD sources only. They are not intended as a
-    general portability layer.

-

-

-

-

-

-  
Compilers supported for building programs on
-    FreeBSD:

-  

-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
gcc9, 10, 11, 12, 13, 14
clang10, 11, 12, 13, 14, 15, 16, 17, 18
TinyC (tcc)0.9
pcc1.1

-    
Due to testing constraints, tcc and pcc may not always
-      work.

-  

-  
Compilers supported for building FreeBSD
-    itself:

-  

-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
gcc12, 13, 14
clang16, 17, 18

-    
Please note: Not every single minor versions of these
-        compilers will work or are supported.

-  

-

-

-

-

-

-
cdefs defines (or refrains from defining)
-    a number of macros to increase portability of compiled programs. These are
-    to allow more advanced language features to appear in header files. The
-    header files assume a compiler that accepts C prototype function
-    declarations. They also assume that the compiler accepts ANSI C89 keywords
-    for all language dialects.

-

-

-
General macros that facilitate multiple language environments and
-    language dialects.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
expands to volatile in C++ and C89 and newer environments, __volatile in
-      pre-ANSI environments that support this extension or nothing
-      otherwise.
expands to inline in C++ and C89 and newer environments, __inline in
-      pre-ANSI environments that support this extension or nothing
-      otherwise.
expands to restrict in C99 and newer environments, or __restrict
-      otherwise.
used to paste two pre-processor tokens.
used to convert the argument to a string.
Start a group of functions.
End a group of functions. In a C environment, these are defined as
-      nothing. In a C++ environment, these declare the functions to have
-      “C” linkage.

-

-

-

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Declare the symbol to be a weak symbol
Function will not return
Function has no side effects
To Variable may be unused (usually arguments), so do not warn about
-      it
Function really is used, so emit it even if it appears unused.
Function interface has been deprecated, and clients should migrate to a
-      new interface. A warning will be issued for clients of this
-      interface.
Function interface has been deprecated, and clients should migrate to a
-      new interface. The string msg will be included in a
-      warning issued for clients of this interface.
Do not have space between structure elements for natural alignment. Used
-      when communicating with external protocols.
Specify in bytes the minimum alignment for the specified field,
-      structure or variable
Place function or variable in section x
Hint that the variable is only assigned to, but do not warn about it.
-      Useful for macros and other places the eventual use of the result is
-      unknown.
The function always returns at least the number of bytes determined by
-      argument number Fa x
The function always returns an array, whose size is at least the number
-      of bytes determined by argument number Fa x times the number of elements
-      specified by argument number Fa n
Function either returns a pointer aligned to x
-      bytes or Dv NULL.
Declare the array to have a certain, minimum size
Function behaves like the “malloc” family of
-      functions.
Function has no side effects
Always inline this function when called
Use the “fastcall” ABI to call and name mangle this
-      function.
Warn if function caller does not use its return value
Equivalent to the standard “[[nodiscard]]” attribute. If
-      applied to a function, warn if function caller does not use its return
-      value. The warning may be silenced using a cast to
-      void, or in C++, using an assignment to
-      std::ignore. If applied to a struct, C++ class or
-      enum, this applies to all functions returning values of that type. If
-      applied to a C++ constructor, this applies to creating instances of the
-      class using that constructor.
Returns multiple times, like fork(2)
This code is not reachable at runtime
Hint to the compiler that x is true most of the
-      time. Should only be used when performance is improved for a frequently
-      called bit of code.
Hint to the compiler that x is false most of the
-      time. Should only be used when performance is improved for a frequently
-      called bit of code.
The varadic function contains a parameter that is a NULL sentinel to
-      mark the end of its arguments.
Function is similar to
-      ()
-      which specifies the format argument with fmtarg and
-      where the arguments formatted by that format start with the
-      firstvararg, with 0 meaning that
-      va_arg is used and cannot be checked.
Function is similar to
-      ()
-      which specifies the format argument with fmtarg and
-      where the arguments formatted by that format start with the
-      firstvararg, with 0 meaning that
-      va_arg is used and cannot be checked.
Specifies that arg f contains a string that will
-      be passed to a function like printf() or
-      scanf after being translated in some way.
Function is similar to scanf() which specifies
-      the format argument with fmtarg and where the
-      arguments formatted by that format start with the
-      firstvararg, with 0 meaning that
-      va_arg is used and cannot be checked.
Function is similar to scanf() which specifies
-      the format argument with fmtarg and where the
-      arguments formatted by that format start with the
-      firstvararg, with 0 meaning that
-      va_arg is used and cannot be checked.
Exactly the same as
-      
-      except fmtarg may be
-      NULL.

-

-

-

-
Macros for lock annotation and debugging, as well as some general
-    debugging macros for address sanitizers.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-

-

-

-

-
As C evolves, many of the old macros we once used have been
-    incorporated into the standard language. As this happens, we add support for
-    these keywords as macros for older compilation environments. Sometimes this
-    results in a nop in the older environment.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Expands to “[[noreturn]]” in C++-11 and newer compilation
-      environments, otherwise “__dead2”
Compile time assertion that x is true, otherwise
-      emit y as the error message.
Designate variable as thread local storage
implement _Generic-like features which aren't entirely possible to
-      emulate the _Generic keyword
to emulate the C++11 argument-less noexcept form
to emulate the C++11 conditional noexcept form

-

-

-

-
The following macros are defined, or have specific values, to
-    denote certain things about the build environment.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Variables may be declared “long long”. This is defined for
-      C99 or newer and C++ environments.

-

-

-

-
These macros make it easier to do a number of things, even though
-    strictly speaking the standard places their normal form in another
-  header.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-

-

-

-

-
This section is deprecated, but is kept around because too much
-    contrib software still uses these.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-

-

-

-

-

-
FreeBSD supports a number C standard
-    environments. Selection of the language dialect is a compiler-dependent
-    command line option, though it is usually -std=XX
-    where XX is the standard to set for compiling, such as c89 or c23.
-    FreeBSD provides a number of selection macros to
-    control visibility of symbols. Please see the section on Selection Macros
-    for the specifics.

-

-  
K & R

-  
Pre-ANSI Kernighan and Ritchie C. Sometimes called “knr” or
-      “C78” to distinguish it from newer standards. Support for
-      this compilation environment is dependent on compilers supporting this
-      configuration. Most of the old forms of C have been deprecated or removed
-      in. Compilers make compiling in this mode increasingly difficult and
-      support for it may ultimately be removed from the tree.

-  
ANSI X3.159-1989
-    (“ANSI C89”)

-  

-      is defined, however __STDC_VERSION__ is not.
-    
Strict environment selected with
-        _ANSI_SOURCE.

-  

-  
ISO/IEC 9899:1999
-    (“ISO C99”)

-  

-    
Strict environment selected with
-        _C99_SOURCE.

-  

-  
ISO/IEC 9899:2011
-    (“ISO C11”)

-  

-    
Strict environment selected with
-        _C11_SOURCE.

-  

-  
ISO/IEC 9899:2018 (“ISO C17”)

-  

-    
Strict environment selected with
-        _C11_SOURCE since there are no new C17 only
-        symbols or macros.

-    
This version of the standard did not introduce any new
-        features, only made minor, technical corrections.

-  

-  

-  
 Strict environment selected with
-      _C23_SOURCE though ISO C23 support is only
-      partially implemented.

-

-
For more information on C standards, see
-  c(7).

-

-

-
Defining the macros outlined below requests that the system header
-    files provide only the functions, structures and macros (symbols) defined by
-    the appropriate standard, while suppressing all extensions. However, system
-    headers not defined by that standard may define extensions. You may only
-    define one of the following for any compilation unit.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
IEEE Std 1003.1-1988 (“POSIX.1”)
-      including ANSI X3.159-1989
-      (“ANSI C89”)
IEEE Std 1003.1-1988 (“POSIX.1”)
-      including ANSI X3.159-1989
-      (“ANSI C89”)
IEEE Std 1003.1-1990 (“POSIX.1”)
-      including ANSI X3.159-1989
-      (“ANSI C89”)
IEEE Std 1003.1b-1993 (“POSIX.1b”)
-      including ANSI X3.159-1989
-      (“ANSI C89”)
IEEE Std 1003.1c-1995 (“POSIX.1c”)
-      including ANSI X3.159-1989
-      (“ANSI C89”)
IEEE Std 1003.1-2001 (“POSIX.1”)
-      including ISO/IEC 9899:1999
-      (“ISO C99”)
IEEE Std 1003.1-2008 (“POSIX.1”)
-      including ISO/IEC 9899:1999
-      (“ISO C99”)
including ISO/IEC 9899:2018 ("ISO C17"),
IEEE Std 1003.1-1990 (“POSIX.1”)
-      with XPG Extensions to Version 1 of the Single
-      UNIX Specification (“SUSv1”) including
-      ANSI X3.159-1989
-      (“ANSI C89”). However,
-      FreeBSD implements this as a NOP because too much
-      software breaks with the correct strict environment.
IEEE Std 1003.1c-1995 (“POSIX.1c”)
-      and XPG extensions to Version 2 of the Single UNIX
-      Specification (“SUSv2”) including
-      ANSI X3.159-1989
-      (“ANSI C89”)
IEEE Std 1003.1-2001 (“POSIX.1”)
-      and XPG extensions to Version 3 of the Single UNIX
-      Specification (“SUSv3”) including
-      ISO/IEC 9899:1999
-      (“ISO C99”)
IEEE Std 1003.1-2008 (“POSIX.1”)
-      and XPG extensions to Version 4 of the Single UNIX
-      Specification (“SUSv4”) including
-      ISO/IEC 9899:1999
-      (“ISO C99”)
and XPG extensions to Version 5 of the Single UNIX Specification
-      (“SUSv5”) including ISO/IEC 9899:2018 (“ISO
-      C17”)
ANSI X3.159-1989
-      (“ANSI C89”)
ISO/IEC 9899:1999
-      (“ISO C99”)
ISO/IEC 9899:2011
-      (“ISO C11”)
Everything, including FreeBSD extensions

-
Note: and XPG extensions to Version 5 of the Single UNIX
-    Specification ("SUSv5") support is incomplete.

-
When both POSIX and C environments are selected, the POSIX
-    environment selects which C environment is used. However, when C11 dialect
-    is selected with IEEE Std 1003.1-2008
-    (“POSIX.1”), definitions for ISO/IEC
-    9899:2011 (“ISO C11”) are also included.
-    Likewise, when C23 dialog is selected with IEEE Std
-    1003.1-2008 (“POSIX.1”) or, definitions for are also
-    included.

-

-

-

-
These macros are set by cdefs to control
-    the visibility of different standards. Users must not define these, and
-    doing so will produced undefined results. They are documented here for
-    developers working on system's header files.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Restricts the visibility of XOPEN Single Unix Standard version. Possible
-      values are 500, 600, 700 or 800, corresponding to Issue 5, 6, 7, or 8 of
-      the Single Unix Standard. These are extra functions in addition to the
-      normal POSIX ones.
Make symbols associated with certain standards versions visible. Set to
-      the value assigned to _POSIX_C_SOURCE by
-      convention with 199009 for IEEE Std 1003.1-1988
-      (“POSIX.1”) and 199209 IEEE Std
-      1003.1-1990 (“POSIX.1”).
The C level that's visible. Possible values include 1990, 1999, 2011,
-      2017 and 2023 for ISO/IEC 9899:1990
-      (“ISO C90”), ISO/IEC
-      9899:1999 (“ISO C99”),
-      ISO/IEC 9899:2011
-      (“ISO C11”), ISO/IEC 9899:2018 ("ISO
-      C17"), and, respectively.
1 if the FreeBSD extensions are visible, 0
-      otherwise.
1 if the ISO/IEC 9899:2011
-      (“ISO C11”) Appendix K 3.7.4.1 extensions are
-      visible, 0 otherwise.

-

-

-

-

-
FreeBSD supports C++11 and newer standards
-    fully.

-

-  
ISO/IEC 14882:1998 ("C++98")

-  

-    
The first standardized version of C++. Unlike K & R
-        support in C, compilers dropped support for versions of the language
-        prior to C++98.

-  

-  
ISO/IEC 14882:2003 ("C++03")

-  

-    
Note, this is the same value as C++98. C++03 did not define a
-        new value for __cplusplus. There is no way, at
-        compile time, to detect the difference. The standard resolved a number
-        of defect reports and slightly expanded value initialization. Most
-        compilers support it the same as C++98.

-  

-  
ISO/IEC 14882:2011 ("C++11")

-  

-  
ISO/IEC 14882:2014 ("C++14")

-  

-  
ISO/IEC 14882:2017 ("C++17")

-  

-  
ISO/IEC 14882:2020 ("C++20")

-  

-  
ISO/IEC 14882:2023 ("C++23")

-  

-

-
FreeBSD uses llvm project's libc++.
-    However, they are removing support for C++ prior to C++11. While programs
-    can still build with earlier environments for now, these changes mean that
-    -pedantic-errors cannot be reliably enabled for
-    standards older than C++11.

-

-

-

-
<sys/cdefs.h>
-    first appeared in 4.3BSD-NET/2.

-

-

-
-  
-    
-    
-  
-
May 9, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/cnv.9 4.html b/static/freebsd/man9/cnv.9 4.html
deleted file mode 100644
index bca0c09f..00000000
--- a/static/freebsd/man9/cnv.9 4.html	
+++ /dev/null
@@ -1,278 +0,0 @@
-
-  
-    
-    
-    
-  
-
CNV(9)Kernel Developer's ManualCNV(9)

-

-

-

-
cnvlist_get,
-    cnvlist_take, cnvlist_free
-    — API for managing name/value pairs by
-  cookie

-

-

-

-
Name/value pairs library (libnv, -lnv)

-

-

-

-
#include
-    <sys/cnv.h>

-
const char *
-  

-  cnvlist_name(const
-    void *cookie);

-
int
-  

-  cnvlist_type(const
-    void *cookie);

-
bool
-  

-  cnvlist_get_bool(const
-    void *cookie);

-
uint64_t
-  

-  cnvlist_get_number(const
-    void *cookie);

-
const char *
-  

-  cnvlist_get_string(const
-    void *cookie);

-
const nvlist_t *
-  

-  cnvlist_get_nvlist(const
-    void *cookie);

-
const void *
-  

-  cnvlist_get_binary(const
-    void *cookie, size_t
-    *sizep);

-
const bool *
-  

-  cnvlist_get_bool_array(const
-    void *cookie, size_t
-    *nitemsp);

-
const uint64_t *
-  

-  cnvlist_get_number_array(const
-    void *cookie, size_t
-    *nitemsp);

-
const char * const *
-  

-  cnvlist_get_string_array(const
-    void *cookie, size_t
-    *nitemsp);

-
const nvlist_t * const *
-  

-  cnvlist_get_nvlist_array(const
-    void *cookie, size_t
-    *nitemsp);

-
int
-  

-  cnvlist_get_descriptor(const
-    void *cookie);

-
const int *
-  

-  cnvlist_get_descriptor_array(const
-    void *cookie, size_t
-    *nitemsp);

-
bool
-  

-  cnvlist_take_bool(void
-    *cookie);

-
uint64_t
-  

-  cnvlist_take_number(void
-    *cookie);

-
const char *
-  

-  cnvlist_take_string(void
-    *cookie);

-
const nvlist_t *
-  

-  cnvlist_take_nvlist(void
-    *cookie);

-
const void *
-  

-  cnvlist_take_binary(void
-    *cookie, size_t
-    *sizep);

-
const bool *
-  

-  cnvlist_take_bool_array(void
-    *cookie, size_t
-    *nitemsp);

-
const uint64_t *
-  

-  cnvlist_take_number_array(void
-    *cookie, size_t
-    *nitemsp);

-
const char * const *
-  

-  cnvlist_take_string_array(void
-    *cookie, size_t
-    *nitemsp);

-
const nvlist_t * const *
-  

-  cnvlist_take_nvlist_array(void
-    *cookie, size_t
-    *nitemsp);

-
int
-  

-  cnvlist_take_descriptor(void
-    *cookie);

-
const int *
-  

-  cnvlist_take_descriptor_array(void
-    *cookie, size_t
-    *nitemsp);

-
void
-  

-  cnvlist_free_null(void
-    *cookie);

-
void
-  

-  cnvlist_free_bool(void
-    *cookie);

-
void
-  

-  cnvlist_free_number(void
-    *cookie);

-
void
-  

-  cnvlist_free_string(void
-    *cookie);

-
void
-  

-  cnvlist_free_nvlist(void
-    *cookie);

-
void
-  

-  cnvlist_free_descriptor(void
-    *cookie);

-
void
-  

-  cnvlist_free_binary(void
-    *cookie);

-
void
-  

-  cnvlist_free_bool_array(void
-    *cookie);

-
void
-  

-  cnvlist_free_number_array(void
-    *cookie);

-
void
-  

-  cnvlist_free_string_array(void
-    *cookie);

-
void
-  

-  cnvlist_free_nvlist_array(void
-    *cookie);

-
void
-  

-  cnvlist_free_descriptor_array(void
-    *cookie);

-

-

-

-
The libnv library permits easy management
-    of name/value pairs and can send and receive them over sockets. For more
-    information, see nv(9).

-
The concept of cookies is explained in
-    (),
-    (),
-    and
-    ()
-    from nv(9).

-
The
-    ()
-    function returns the name of an element associated with
-    cookie.

-
The
-    ()
-    function returns the type of an element associated with
-    cookie. Types which can be returned are described in
-    nv(9).

-
The cnvlist_get functions return the value
-    associated with cookie. Returned strings, nvlists,
-    descriptors, binaries, or arrays must not be modified by the user since they
-    still belong to the nvlist. The nvlist must not be in an error state.

-
The cnvlist_take functions
-    return the value associated with the given cookie and remove the element
-    from the nvlist. When the value is a string, binary, or array value, the
-    caller is responsible for freeing the returned memory with
-    (3).
-    When the value is an nvlist, the caller is responsible for destroying the
-    returned nvlist with
-    ().
-    When the value is a descriptor, the caller is responsible for closing the
-    returned descriptor with
-    (2).

-
The cnvlist_free functions remove the
-    element identified by cookie and free any associated
-    resources. If the element identified by cookie has the
-    wrong type or does not exist, the program aborts.

-

-

-

-
The following example demonstrates how to deal with the cnvlist
-    API.

-

-
int type;
-void *cookie, *scookie, *bcookie;
-nvlist_t *nvl;
-char *name;
-
-nvl = nvlist_create(0);
-nvlist_add_bool(nvl, "test", 1 == 2);
-nvlist_add_string(nvl, "test2", "cnvlist");
-cookie = NULL;
-
-while (nvlist_next(nvl, &type, &cookie) != NULL) {
-        switch (type) {
-        case NV_TYPE_BOOL:
-                printf("test: %d\n", cnvlist_get_bool(cookie));
-                bcookie = cookie;
-                break;
-        case NV_TYPE_STRING:
-                printf("test2: %s\n", cnvlist_get_string(cookie));
-                scookie = cookie;
-                break;
-        }
-}
-
-name = cnvlist_take_string(scookie);
-cnvlist_free_bool(bcookie);
-
-printf("test2: %s\n", name);
-free(name);
-
-printf("nvlist_empty = %d\n", nvlist_empty(nvl));
-nvlist_destroy(nvl);
-
-return (0);

-

-

-

-

-
close(2), free(3),
-    nv(9)

-

-

-

-
The cnv API was created during the Google
-    Summer Of Code 2016 by Adam Starak.

-

-

-
-  
-    
-    
-  
-
January 3, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/condvar.9 4.html b/static/freebsd/man9/condvar.9 4.html
deleted file mode 100644
index 88cf8dc4..00000000
--- a/static/freebsd/man9/condvar.9 4.html	
+++ /dev/null
@@ -1,216 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONDVAR(9)Kernel Developer's ManualCONDVAR(9)

-

-

-

-
condvar, cv_init,
-    cv_destroy, cv_wait,
-    cv_wait_sig, cv_wait_unlock,
-    cv_timedwait,
-    cv_timedwait_sbt,
-    cv_timedwait_sig,
-    cv_timedwait_sig_sbt,
-    cv_signal, cv_broadcast,
-    cv_broadcastpri, cv_wmesg
-    — kernel condition variable

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>
-  

-  #include <sys/condvar.h>

-
void
-  

-  cv_init(struct
-    cv *cvp, const char
-    *desc);

-
void
-  

-  cv_destroy(struct
-    cv *cvp);

-
void
-  

-  cv_wait(struct
-    cv *cvp, lock);

-
int
-  

-  cv_wait_sig(struct
-    cv *cvp, lock);

-
void
-  

-  cv_wait_unlock(struct
-    cv *cvp, lock);

-
int
-  

-  cv_timedwait(struct
-    cv *cvp, lock,
-    int timo);

-
int
-  

-  cv_timedwait_sbt(struct
-    cv *cvp, lock,
-    sbintime_t sbt,
-    sbintime_t pr,
-    int flags);

-
int
-  

-  cv_timedwait_sig(struct
-    cv *cvp, lock,
-    int timo);

-
int
-  

-  cv_timedwait_sig_sbt(struct
-    cv *cvp, lock,
-    sbintime_t sbt,
-    sbintime_t pr,
-    int flags);

-
void
-  

-  cv_signal(struct
-    cv *cvp);

-
void
-  

-  cv_broadcast(struct
-    cv *cvp);

-
void
-  

-  cv_broadcastpri(struct
-    cv *cvp, int
-  pri);

-
const char *
-  

-  cv_wmesg(struct
-    cv *cvp);

-

-

-

-
Condition variables are used in conjunction with mutexes to wait
-    for conditions to occur. Condition variables are created with
-    (),
-    where cvp is a pointer to space for a
-    struct cv, and desc is a pointer
-    to a null-terminated character string that describes the condition variable.
-    Condition variables are destroyed with
-    ().
-    Threads wait on condition variables by calling
-    cv_wait(), cv_wait_sig(),
-    cv_wait_unlock(),
-    cv_timedwait(), or
-    cv_timedwait_sig(). Threads unblock waiters by
-    calling
-    ()
-    to unblock one waiter, or
-    ()
-    or
-    ()
-    to unblock all waiters. In addition to waking waiters,
-    cv_broadcastpri() ensures that all of the waiters
-    have a priority of at least pri by raising the
-    priority of any threads that do not.
-    ()
-    returns the description string of cvp, as set by the
-    initial call to cv_init().

-
The lock argument is a pointer
-    to either a mutex(9), rwlock(9), or
-    sx(9) lock. A mutex(9) argument must be
-    initialized with MTX_DEF and not
-    MTX_SPIN. A thread must hold
-    lock before calling
-    (),
-    (),
-    (),
-    (),
-    or
-    ().
-    When a thread waits on a condition, lock is atomically
-    released before the thread is blocked, then reacquired before the function
-    call returns. In addition, the thread will fully drop the
-    Giant mutex (even if recursed) while the it is
-    suspended and will reacquire the Giant mutex before
-    the function returns. The cv_wait_unlock() function
-    does not reacquire the lock before returning. Note that the
-    Giant mutex may be specified as
-    lock. However, Giant may not be
-    used as lock for the
-    cv_wait_unlock() function. All waiters must pass the
-    same lock in conjunction with
-    cvp.

-
When
-    (),
-    (),
-    (),
-    (),
-    and
-    ()
-    unblock, their calling threads are made runnable.
-    cv_timedwait() and
-    cv_timedwait_sig() wait for at most
-    timo / HZ seconds before being
-    unblocked and returning EWOULDBLOCK; otherwise, they
-    return 0. cv_wait_sig() and
-    cv_timedwait_sig() return prematurely with a value
-    of EINTR or ERESTART if a
-    signal is caught, or 0 if signaled via cv_signal()
-    or cv_broadcast().

-
()
-    and
-    ()
-    functions take sbt argument instead of
-    timo. It allows to specify relative or absolute
-    unblock time with higher resolution in form of
-    sbintime_t. The parameter pr
-    allows to specify wanted absolute event precision. The parameter
-    flags allows to pass additional
-    ()
-    flags.

-

-

-

-
If successful, cv_wait_sig(),
-    cv_timedwait(), and
-    cv_timedwait_sig() return 0. Otherwise, a non-zero
-    error code is returned.

-
cv_wmesg() returns the description string
-    that was passed to cv_init().

-

-

-

-
cv_wait_sig() and
-    cv_timedwait_sig() will fail if:

-

-  
[]

-  
A signal was caught and the system call should be interrupted.

-  
[]

-  
A signal was caught and the system call should be restarted.

-

-
cv_timedwait() and
-    cv_timedwait_sig() will fail if:

-

-  
[]

-  
Timeout expired.

-

-

-

-

-
callout(9), locking(9),
-    mtx_pool(9), mutex(9),
-    rwlock(9), sema(9),
-    sleep(9), sx(9)

-

-

-
-  
-    
-    
-  
-
February 19, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/config_intrhook.9 3.html b/static/freebsd/man9/config_intrhook.9 3.html
deleted file mode 100644
index a728940d..00000000
--- a/static/freebsd/man9/config_intrhook.9 3.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONFIG_INTRHOOK(9)Kernel Developer's ManualCONFIG_INTRHOOK(9)

-

-

-

-
config_intrhook —
-    schedule a function to be run after interrupts have been
-    enabled, but before root is mounted

-

-

-

-
#include
-    <sys/kernel.h>

-
typedef void (*ich_func_t)(void *arg);

-
int
-  

-  config_intrhook_establish(struct
-    intr_config_hook *hook);

-
void
-  

-  config_intrhook_disestablish(struct
-    intr_config_hook *hook);

-
int
-  

-  config_intrhook_drain(struct
-    intr_config_hook *hook);

-
void
-  

-  config_intrhook_oneshot(ich_func_t
-    func, void
-  *arg);

-

-

-

-
The
-    ()
-    function schedules a function to be run after interrupts have been enabled,
-    but before root is mounted. If the system has already passed this point in
-    its initialization, the function is called immediately.

-
The
-    ()
-    function removes the entry from the hook queue.

-
The
-    ()
-    function removes the entry from the hook queue in a safe way. If the hook is
-    not currently active it removes hook from the hook
-    queue and returns ICHS_QUEUED. If the hook is active,
-    it waits for the hook to complete before returning
-    ICHS_RUNNING. If the hook has previously completed, it
-    returns ICHS_DONE. Because a
-    config_intrhook is undefined prior to
-    config_intrhook_establish(), this function may only
-    be called after that function has returned.

-
The
-    ()
-    function schedules a function to be run as described for
-    config_intrhook_establish(); the entry is
-    automatically removed from the hook queue after that function runs. This is
-    appropriate when additional device configuration must be done after
-    interrupts are enabled, but there is no need to stall the boot process after
-    that. This function allocates memory using M_WAITOK; do not call this while
-    holding any non-sleepable locks.

-
Before root is mounted, all
-    the previously established hooks are run. The boot process is then stalled
-    until all handlers remove their hook from the hook queue with
-    ().
-    The boot process then proceeds to attempt to mount the root file system. Any
-    driver that can potentially provide devices they wish to be mounted as root
-    must use either this hook, or probe all these devices in the initial probe.
-    Since interrupts are disabled during the probe process, many drivers need a
-    method to probe for devices with interrupts enabled.

-
The requests are made with the
-    intr_config_hook structure. This structure is defined
-    as follows:

-

-
struct intr_config_hook {
-	TAILQ_ENTRY(intr_config_hook) ich_links;/* Private */
-	ich_func_t	ich_func;		/* function to call */
-	void		*ich_arg;		/* Argument to call */
-};

-

-
Storage for the intr_config_hook structure
-    must be provided by the driver. It must be stable from just before the hook
-    is established until after the hook is disestablished.

-
Specifically, hooks are run at
-    (),
-    which is immediately after the scheduler is started, and just before the
-    root file system device is discovered.

-

-

-

-
A zero return value means the hook was successfully added to the
-    queue (with either deferred or immediate execution). A non-zero return value
-    means the hook could not be added to the queue because it was already on the
-    queue.

-

-

-

-
DEVICE_ATTACH(9)

-

-

-

-
These functions were introduced in FreeBSD
-    3.0 with the CAM subsystem, but are available for any driver to
-  use.

-

-

-

-
The functions were written by Justin Gibbs
-    <gibbs@FreeBSD.org>.
-    This manual page was written by M. Warner Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 8, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/contigmalloc.9 3.html b/static/freebsd/man9/contigmalloc.9 3.html
deleted file mode 100644
index 8bfe5a5d..00000000
--- a/static/freebsd/man9/contigmalloc.9 3.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONTIGMALLOC(9)Kernel Developer's ManualCONTIGMALLOC(9)

-

-

-

-
contigmalloc —
-    manage contiguous kernel physical memory

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/malloc.h>

-
void *
-  

-  contigmalloc(unsigned long size,
-    struct malloc_type *type, int
-    flags, vm_paddr_t low,
-    vm_paddr_t high, unsigned long
-    alignment, vm_paddr_t boundary);

-
#include
-    <sys/param.h>
-  

-  #include <sys/domainset.h>

-
void *
-  

-  contigmalloc_domainset(unsigned long
-    size, struct malloc_type *type,
-    struct domainset *ds, int flags,
-    vm_paddr_t low, vm_paddr_t high,
-    unsigned long alignment, vm_paddr_t
-    boundary);

-

-

-

-
The
-    ()
-    function allocates size bytes of contiguous physical
-    memory that is aligned to alignment bytes, and which
-    does not cross a boundary of boundary bytes. If
-    successful, the allocation will reside between physical addresses
-    low and high. The returned
-    pointer points to a wired kernel virtual address range of
-    size bytes allocated from the kernel virtual address
-    (KVA) map.

-
The
-    ()
-    variant allows the caller to additionally specify a
-    numa(4) domain selection policy. See
-    domainset(9) for some example policies.

-
The flags parameter
-    modifies
-    ()'s
-    behaviour as follows:

-

-  

-  
Causes the allocated physical memory to be zero filled.

-  

-  
Causes contigmalloc() to return
-      NULL if the request cannot be immediately
-      fulfilled due to resource shortage.

-

-
Other flags (if present) are ignored.

-
The
-    ()
-    function is deprecated. Use free(9) instead.

-

-

-

-
The contigmalloc() function does not sleep
-    waiting for memory resources to be freed up, but instead actively reclaims
-    pages before giving up. However, unless M_NOWAIT is
-    specified, it may select a page for reclamation that must first be written
-    to backing storage, causing it to sleep.

-

-

-

-
The contigmalloc() function returns a
-    kernel virtual address if allocation succeeds, or
-    NULL otherwise.

-

-

-

-

-
void *p;
-p = contigmalloc(8192, M_DEVBUF, M_ZERO, 0, (1L << 22),
-    32 * 1024, 1024 * 1024);

-

-
Ask for 8192 bytes of zero-filled memory residing between physical
-    address 0 and 4194303 inclusive, aligned to a 32K boundary and not crossing
-    a 1M address boundary.

-

-

-

-
The contigmalloc() function will panic if
-    size is zero, or if alignment or
-    boundary is not a power of two.

-

-

-

-
malloc(9), memguard(9)

-

-

-
-  
-    
-    
-  
-
July 26, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/copy.9 3.html b/static/freebsd/man9/copy.9 3.html
deleted file mode 100644
index 9e2c2554..00000000
--- a/static/freebsd/man9/copy.9 3.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
COPY(9)Kernel Developer's ManualCOPY(9)

-

-

-

-
copy, copyin,
-    copyin_nofault, copyout,
-    copyout_nofault, copystr,
-    copyinstr — heterogeneous
-    address space copy functions

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
int
-  

-  copyin(const
-    void *uaddr, void
-    *kaddr, size_t
-    len);

-
int
-  

-  copyin_nofault(const
-    void *uaddr, void
-    *kaddr, size_t
-    len);

-
int
-  

-  copyout(const
-    void *kaddr, void
-    *uaddr, size_t
-    len);

-
int
-  

-  copyout_nofault(const
-    void *kaddr, void
-    *uaddr, size_t
-    len);

-
int __deprecated
-  

-  copystr(const
-    void *kfaddr, void
-    *kdaddr, size_t
-    len, size_t
-  *done);

-
int
-  

-  copyinstr(const
-    void *uaddr, void
-    *kaddr, size_t len,
-    size_t *done);

-

-

-

-
The copy functions are designed to copy
-    contiguous data from one address space to another.

-
()
-    is deprecated and should be replaced with strlcpy(9). It
-    will be removed from FreeBSD 13.

-
The
-    () and
-    copyin_nofault() functions copy
-    len bytes of data from the user-space address
-    uaddr to the kernel-space address
-    kaddr.

-
The
-    ()
-    and
-    ()
-    functions copy len bytes of data from the kernel-space
-    address kaddr to the user-space address
-    uaddr.

-
The
-    ()
-    and
-    ()
-    functions require that the kernel-space and user-space data be accessible
-    without incurring a page fault. The source and destination addresses must be
-    physically mapped for read and write access, respectively, and neither the
-    source nor destination addresses may be pageable.

-
The
-    ()
-    function copies a NUL-terminated string, at most len
-    bytes long, from kernel-space address kfaddr to
-    kernel-space address kdaddr. The number of bytes
-    actually copied, including the terminating NUL, is returned in
-    *done (if done is
-    non-NULL).

-
The
-    ()
-    function copies a NUL-terminated string, at most len
-    bytes long, from user-space address uaddr to
-    kernel-space address kaddr. The number of bytes
-    actually copied, including the terminating NUL, is returned in
-    *done (if done is
-    non-NULL).

-

-

-

-
The copy functions return 0 on success.
-    All but copystr() return
-    EFAULT if a bad address is encountered. The
-    copyin_nofault() and
-    copyout_nofault() functions return
-    EFAULT if a page fault occurs. The
-    copystr() and copyinstr()
-    functions return ENAMETOOLONG if the string is
-    longer than len bytes.

-

-

-

-
fetch(9), store(9)

-

-

-
-  
-    
-    
-  
-
May 11, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/coredumper_register.9 3.html b/static/freebsd/man9/coredumper_register.9 3.html
deleted file mode 100644
index c63860e1..00000000
--- a/static/freebsd/man9/coredumper_register.9 3.html	
+++ /dev/null
@@ -1,181 +0,0 @@
-
-  
-    
-    
-    
-  
-
COREDUMPER_REGISTER(9)Kernel Developer's ManualCOREDUMPER_REGISTER(9)

-

-

-

-
coredumper_register,
-    coredumper_unregister —
-    loadable user coredumper support

-

-

-

-
#include
-    <sys/ucoredump.h>

-
void
-  

-  coredumper_register(struct
-    coredumper *cd);

-
void
-  

-  coredumper_unregister(struct
-    coredumper *cd);

-

-  

-  int
-  

-  coredumper_probe_fn(struct
-    thread *td);

-
int
-  

-  coredumper_handle_fn(struct
-    thread *td, off_t
-    limit);

-

-
/* Incomplete, but the useful members are depicted here. */
-struct coredumper {
-	const char		*cd_name;
-	coredumper_probe_fn	*cd_probe;
-	coredumper_handle_fn	*cd_handle;
-};

-

-

-  

-  int
-  

-  coredump_init_fn(const
-    struct coredump_writer *,
-    const struct coredump_params
-    *);

-
int
-  

-  coredump_write_fn(const
-    struct coredump_writer *,
-    const void *,
-    size_t,
-    off_t,
-    enum uio_seg,
-    struct ucred *,
-    size_t *,
-    struct thread *);

-
int
-  

-  coredump_extend_fn(const
-    struct coredump_writer *,
-    off_t,
-    struct ucred *);

-

-
struct coredump_writer {
-	void			*ctx;
-	coredump_init_fn	*init_fn;
-	coredump_write_fn	*write_fn;
-	coredump_extend_fn	*extend_fn;
-};

-

-

-

-

-
The coredumper_register mechanism provides
-    a path for kernel modules to register a new user process core dumper. The
-    expected use of coredumper_register is for a module
-    to define the fields of the struct coredumper listed above, then call
-    ()
-    at MOD_LOAD time. A corresponding
-    ()
-    should be called at MOD_UNLOAD time. Note that
-    coredumper_unregister() will block until the
-    specified coredumper is no longer processing coredumps.

-
When a user process is preparing to start dumping
-    core, the kernel will execute the
-    ()
-    function for each coredumper currently registered. The
-    cd_probe() function is expected to return either -1
-    if it would decline to dump the process, or a priority level greater than 0.
-    The coredumper with the highest priority will handle the coredump. The
-    following default priorities are defined:

-

-  

-  
This dumper declines dumping the process.

-  

-  
This dumper will dump the process at the lowest priority. This priority is
-      not recommended, as the default vnode dumper will bid at
-      COREDUMPER_GENERIC as well.

-  

-  
This dumper provides special behavior, and will dump the process at a
-      higher priority.

-  

-  
This dumper would prefer to handle this coredump. This may be used by, for
-      instance, a custom or vendor-specific coredump mechanism that wishes to
-      preempt others.

-

-
Note that this system has been designed such that
-    the
-    ()
-    function can examine the process in question and make an informed decision.
-    Different processes being dumped could probe at different priorities in the
-    same coredumper.

-
Once the highest priority coredumper has been
-    selected, the
-    ()
-    function will be invoked. The cd_handle() will
-    receive both the thread and the RLIMIT_CORE
-    setrlimit(2) limit. The proc lock
-    will be held on entry, and should be unlocked before the handler returns.
-    The limit is typically passed to the
-    sv_coredump() that belongs to the process's
-    p_sysent.

-
The
-    ()
-    function should return either 0 if the dump was successful, or an
-    appropriate errno(2) otherwise.

-

-

-
Custom coredumpers can define their own
-    coredump_writer to pass to
-    sv_coredump().

-
The ctx member is opaque and only to be used
-    by the coredumper itself.

-
The init_fn function, if
-    it's provided, will be called by the
-    ()
-    implementation before any data is to be written. This allows the writer
-    implementation to record any coredump parameters that it might need to
-    capture, or setup the object to be written to.

-
The write_fn function
-    will be called by the
-    ()
-    implementation to write out data. The extend_fn
-    function will be called to enlarge the coredump, in the sense that a hole is
-    created in any difference between the current size and the new size. For
-    convenience, the
-    ()
-    and
-    ()
-    functions used by the vnode coredumper are exposed in
-    <sys/ucordumper.h>, and the
-    coredump_vnode_ctx defined there should be populated
-    with the vnode to write to.

-

-

-

-

-
setrlimit(2), core(5)

-

-

-

-
This manual page was written by Kyle Evans
-    <kevans@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 23, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/counter.9 4.html b/static/freebsd/man9/counter.9 4.html
deleted file mode 100644
index b9e32121..00000000
--- a/static/freebsd/man9/counter.9 4.html	
+++ /dev/null
@@ -1,282 +0,0 @@
-
-  
-    
-    
-    
-  
-
COUNTER(9)Kernel Developer's ManualCOUNTER(9)

-

-

-

-
counter —
-    SMP-friendly kernel counter implementation

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/counter.h>

-
counter_u64_t
-  

-  counter_u64_alloc(int
-    wait);

-
void
-  

-  counter_u64_free(counter_u64_t
-    c);

-
void
-  

-  counter_u64_add(counter_u64_t
-    c, int64_t v);

-
void
-  

-  counter_enter();

-
void
-  

-  counter_exit();

-
void
-  

-  counter_u64_add_protected(counter_u64_t
-    c, int64_t v);

-
uint64_t
-  

-  counter_u64_fetch(counter_u64_t
-    c);

-
void
-  

-  counter_u64_zero(counter_u64_t
-    c);

-
struct counter_rate *
-  

-  counter_rate_alloc(int
-    flags, int
-  period);

-
int64_t
-  

-  counter_ratecheck(struct
-    counter_rate *cr, int64_t
-    limit);

-
uint64_t
-  

-  counter_rate_get(struct
-    counter_rate *cr);

-
void
-  

-  counter_rate_free(struct
-    counter_rate *cr);

-
COUNTER_U64_SYSINIT(counter_u64_t
-    c);

-
COUNTER_U64_DEFINE_EARLY(counter_u64_t
-    c);

-
#include
-    <sys/sysctl.h>

-
SYSCTL_COUNTER_U64(parent,
-    nbr,
-    name,
-    access,
-    ptr,
-    descr);

-
SYSCTL_ADD_COUNTER_U64(ctx,
-    parent,
-    nbr,
-    name,
-    access,
-    ptr,
-    descr);

-
SYSCTL_COUNTER_U64_ARRAY(parent,
-    nbr,
-    name,
-    access,
-    ptr,
-    len,
-    descr);

-
SYSCTL_ADD_COUNTER_U64_ARRAY(ctx,
-    parent,
-    nbr,
-    name,
-    access,
-    ptr,
-    len,
-    descr);

-

-

-

-
counter is a generic facility to create
-    counters that can be utilized for any purpose (such as collecting
-    statistical data). A counter is guaranteed to be
-    lossless when several kernel threads do simultaneous updates. However,
-    counter does not block the calling thread, also no
-    atomic(9) operations are used for the update, therefore
-    the counters can be used in any non-interrupt context. Moreover,
-    counter has special optimisations for SMP
-    environments, making counter update faster than
-    simple arithmetic on the global variable. Thus
-    counter is considered suitable for accounting in the
-    performance-critical code paths.

-

-  
(wait)

-  
Allocate a new 64-bit unsigned counter. The wait
-      argument is the malloc(9) wait flag, should be either
-      M_NOWAIT or M_WAITOK. If
-      M_NOWAIT is specified the operation may fail and
-      return NULL.

-  
(c)

-  
Free the previously allocated counter c. It is safe
-      to pass NULL.

-  
(c,
-    v)

-  
Add v to c. The KPI does not
-      guarantee any protection from wraparound.

-  
()

-  
Enter mode that would allow the safe update of several counters via
-      ().
-      On some machines this expands to critical(9) section,
-      while on other is a nop. See
-      IMPLEMENTATION
-    DETAILS.

-  
()

-  
Exit mode for updating several counters.

-  
counter_u64_add_protected(c,
-    v)

-  
Same as counter_u64_add(), but should be preceded
-      by counter_enter().

-  
(c)

-  
Take a snapshot of counter c. The data obtained is
-      not guaranteed to reflect the real cumulative value for any moment.

-  
(c)

-  
Clear the counter c and set it to zero.

-  
(flags,
-    period)

-  
Allocate a new struct counter_rate. flags is passed
-      to malloc(9). period is the time
-      over which the rate is checked.

-  
(cr,
-    limit)

-  
The function is a multiprocessor-friendly version of
-      ()
-      which uses counter internally. Returns
-      non-negative value if the rate is not yet reached during the current
-      period, and a negative value otherwise. If the limit was reached during
-      the previous period, but was just reset back to zero, then
-      counter_ratecheck() returns number of events since
-      previous reset.

-  
(cr)

-  
The number of hits to this check within the current period.

-  
(cr)

-  
Free the cr counter.

-  
(c)

-  
Define a SYSINIT(9) initializer for the global counter
-      c.

-  
(c)

-  
Define and initialize a global counter c. It is
-      always safe to increment c, though updates prior to
-      the SI_SUB_COUNTER SYSINIT(9)
-      event are lost.

-  
(parent,
-    nbr, name,
-    access, ptr,
-    descr)

-  
Declare a static sysctl(9) oid that would represent a
-      counter. The ptr argument
-      should be a pointer to allocated counter_u64_t. A
-      read of the oid returns value obtained through
-      counter_u64_fetch(). Any write to the oid zeroes
-      it.

-  
(ctx,
-    parent, nbr,
-    name, access,
-    ptr, descr)

-  
Create a sysctl(9) oid that would represent a
-      counter. The ptr argument
-      should be a pointer to allocated counter_u64_t. A
-      read of the oid returns value obtained through
-      counter_u64_fetch(). Any write to the oid zeroes
-      it.

-  
(parent,
-    nbr, name,
-    access, ptr,
-    len, descr)

-  
Declare a static sysctl(9) oid that would represent an
-      array of counter. The ptr
-      argument should be a pointer to allocated array of
-      counter_u64_t's. The len
-      argument should specify number of elements in the array. A read of the oid
-      returns len-sized array of uint64_t values obtained
-      through counter_u64_fetch(). Any write to the oid
-      zeroes all array elements.

-  
(ctx,
-    parent, nbr,
-    name, access,
-    ptr, len,
-    descr)

-  
Create a sysctl(9) oid that would represent an array of
-      counter. The ptr argument
-      should be a pointer to allocated array of
-      counter_u64_t's. The len
-      argument should specify number of elements in the array. A read of the oid
-      returns len-sized array of uint64_t values obtained
-      through counter_u64_fetch(). Any write to the oid
-      zeroes all array elements.

-

-

-

-

-
On all architectures counter is
-    implemented using per-CPU data fields that are specially aligned in memory,
-    to avoid inter-CPU bus traffic due to shared use of the variables between
-    CPUs. These are allocated using UMA_ZONE_PCPU
-    uma(9) zone. The update operation only touches the field
-    that is private to current CPU. Fetch operation loops through all per-CPU
-    fields and obtains a snapshot sum of all fields.

-
On amd64 a counter update is implemented
-    as a single instruction without lock semantics, operating on the private
-    data for the current CPU, which is safe against preemption and
-  interrupts.

-
On i386 architecture, when machine supports the cmpxchg8
-    instruction, this instruction is used. The multi-instruction sequence
-    provides the same guarantees as the amd64 single-instruction
-  implementation.

-
On some architectures updating a counter require a
-    critical(9) section.

-

-

-

-
The following example creates a static counter array exported to
-    userspace through a sysctl:

-

-
#define MY_SIZE 8
-static counter_u64_t array[MY_SIZE];
-SYSCTL_COUNTER_U64_ARRAY(_debug, OID_AUTO, counter_array, CTLFLAG_RW,
-    &array[0], MY_SIZE, "Test counter array");

-

-

-

-

-
atomic(9), critical(9),
-    locking(9), malloc(9),
-    ratecheck(9), sysctl(9),
-    SYSINIT(9), uma(9)

-

-

-

-
The counter facility first appeared in
-    FreeBSD 10.0.

-

-

-

-
The counter facility was written by
-    Gleb Smirnoff and Konstantin
-    Belousov.

-

-

-
-  
-    
-    
-  
-
June 19, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/cpu_machdep.9 3.html b/static/freebsd/man9/cpu_machdep.9 3.html
deleted file mode 100644
index a3ce382f..00000000
--- a/static/freebsd/man9/cpu_machdep.9 3.html	
+++ /dev/null
@@ -1,334 +0,0 @@
-
-  
-    
-    
-    
-  
-
cpu_machdep(9)Kernel Developer's Manualcpu_machdep(9)

-

-

-

-
cpu_machdep,
-    cpu_copy_thread,
-    cpu_exec_vmspace_reuse,
-    cpu_exit,
-    cpu_fetch_syscall_args,
-    cpu_fork,
-    cpu_fork_kthread_handler,
-    cpu_idle, cpu_idle_wakeup,
-    cpu_procctl,
-    cpu_set_syscall_retval,
-    cpu_set_upcall,
-    cpu_set_user_tls,
-    cpu_switch, cpu_sync_core,
-    cpu_thread_alloc,
-    cpu_thread_clean,
-    cpu_thread_exit,
-    cpu_thread_free, cpu_throw,
-    cpu_update_pcb —
-    machine-dependent interfaces to handle CPU and thread
-    state

-

-

-

-
#include
-    <sys/proc.h>
-  

-  #include <sys/ptrace.h>

-
void
-  

-  cpu_copy_thread(struct
-    thread *td, struct thread
-    *td0);

-
bool
-  

-  cpu_exec_vmspace_reuse(struct
-    proc *p, struct vm_map
-    *map);

-
void
-  

-  cpu_exit(struct
-    thread *td);

-
int
-  

-  cpu_fetch_syscall_args(struct
-    thread *td);

-
void
-  

-  cpu_fork(struct thread *td1,
-    struct proc *p2, struct thread
-    *td2, int flags);

-
void
-  

-  cpu_fork_kthread_handler(struct thread
-    *td, void (*func)(void *), void
-    *arg);

-
void
-  

-  cpu_idle(int
-    busy);

-
int
-  

-  cpu_idle_wakeup(int
-    cpu);

-
int
-  

-  cpu_procctl(struct thread *td,
-    int idtype, id_t id,
-    int com, void *data);

-
int
-  

-  cpu_ptrace(struct
-    thread *_td, int
-    req, void *addr,
-    int data);

-
void
-  

-  cpu_set_syscall_retval(struct
-    thread *td, int
-    error);

-
int
-  

-  cpu_set_upcall(struct thread
-    *td, void (*entry)(void *), void
-    *arg, stack_t *stack);

-
int
-  

-  cpu_set_user_tls(struct
-    thread *td, void
-    *tls_base, int
-    thr_flags);

-
void
-  

-  cpu_switch(struct
-    thread *old, struct
-    thread *new, struct mtx
-    *mtx);

-
void
-  

-  cpu_sync_core(void);

-
void
-  

-  cpu_thread_alloc(struct
-    thread *td);

-
void
-  

-  cpu_thread_clean(struct
-    thread *td);

-
void
-  

-  cpu_thread_exit(struct
-    thread *td);

-
void
-  

-  cpu_thread_free(struct
-    thread *td);

-
void
-  

-  cpu_throw(struct
-    thread *old, struct
-    thread *new);

-
void
-  

-  cpu_update_pcb(struct
-    thread *td);

-

-

-

-
These functions provide architecture-specific implementations of
-    machine-independent abstractions.

-
()
-    returns true if
-    ()
-    can reuse an existing struct vmspace
-    (map) for the process p during
-    execve(2). This is only invoked if
-    map is not shared with any other consumers. If this
-    returns false, exec_new_vmspace() will create a new
-    struct vmspace.

-
()
-    releases machine-dependent resources other than the address space for the
-    process containing td during process exit.

-
()
-    copies and updates machine-dependent state (for example, the pcb and user
-    registers) from the forking thread td1 in an existing
-    process to the new thread td2 in the new process
-    p2. This function must set up the new thread's kernel
-    stack and pcb so that td2 calls
-    ()
-    when it begins execution passing a pointer to
-    ()
-    as the callout argument and td2
-    as the arg argument.

-
()
-    adjusts a new thread's initial pcb and/or kernel stack to pass
-    func and arg as the
-    callout and arg arguments to
-    ().
-    This must be called before a new thread is scheduled to run and is used to
-    set the “main” function for kernel threads.

-
()
-    copies machine-dependent state (for example, the pcb and user registers)
-    from td to td0 when creating a
-    new thread in the same process. This function must set up the new thread's
-    kernel stack and pcb so that td0 calls
-    ()
-    when it begins execution passing a pointer to
-    ()
-    as the callout argument and td0
-    as the arg argument.

-
()
-    updates a new thread's initial user register state to call
-    entry with arg as the sole
-    argument using the user stack described in stack.

-
()
-    sets a new thread's initial user thread pointer register to reference the
-    user TLS base pointer tls_base. The
-    thr_flags argument provides flags bits, from the same
-    namespace as flags member of the
-    struct thr_param argument to the
-    thr_new(2) syscall.

-
()
-    updates the pcb of the current thread with current user register values.
-    This is invoked before writing out register notes in a core dump. This
-    function typically only has to update user registers for the current thread
-    that are saved in the pcb during context switches rather than in the
-    trapframe on kernel entry.

-
Note that when
-    ()
-    is used, threads in a process other than the current thread are stopped,
-    typically by
-    ().
-    The pcbs of those stopped threads should already be updated by
-    cpu_switch().

-
()
-    fetches the current system call arguments for the native FreeBSD ABI from
-    the current thread's user register state and/or user stack. The arguments
-    are saved in the td_sa member of
-    td.

-
()
-    updates the user register state for td to store system
-    call error and return values. If error is 0, indicate
-    success and return the two values in td_retval. If
-    error is ERESTART, adjust the
-    user PC to re-invoke the current system call after returning to user mode.
-    If error is EJUSTRETURN, leave
-    the current user register state unchanged. For any other value of
-    error, indicate error and return
-    error as the error code.

-
()
-    waits for the next interrupt to occur on the current CPU. If an architecture
-    supports low power idling, this function should place the CPU into a low
-    power state while waiting. busy is a hint from the
-    scheduler. If busy is non-zero, the scheduler expects
-    a short sleep, so the CPU should prefer low-latency over maximum power
-    savings. If busy is zero, the CPU should maximumize
-    power savings including deferring unnecessary clock interrupts via
-    ().

-
()
-    awakens the idle CPU with the ID cpu from a low-power
-    state.

-
()
-    handles any machine-dependent procctl(2) requests.

-
()
-    handles any machine-dependent ptrace(2) requests.

-
()
-    switches the current CPU between threads by swapping register state. This
-    function saves the current CPU register state in the pcb of
-    old and loads register values from the pcb of
-    new before returning. While the pcb generally contains
-    caller-save kernel register state, it can also contain user registers that
-    are not saved in the trapframe.

-
After saving the current CPU register state of
-    old,
-    ()
-    stores mtx in the td_lock member
-    of old transferring ownership of the old thread. No
-    data belonging to old can be accessed after that
-    store. Specifically, the old thread's kernel stack must not be accessed
-    after this point.

-
When SCHED_ULE is being used, this
-    function must wait (via spinning) for the td_lock
-    member of new to change to a value not equal to
-    &blocked_lock before loading register values from
-    new or accessing its kernel stack.

-
From the caller's perspective,
-    ()
-    returns when old is rescheduled in the future,
-    possibly on a different CPU. However, the implementation of
-    cpu_switch() returns immediately on the same CPU
-    into the previously-saved context of new.

-
()
-    is similar to cpu_switch() but does not save any
-    state for old or write to the old thread's
-    td_lock member.

-
()
-    ensures that all possible speculation and out-of-order execution is
-    serialized on the current CPU. Note that this is called from an IPI handler
-    so only has to handle additional serialization beyond that provided by
-    handling an IPI.

-

-

-
These functions support the management of machine-dependent thread
-    state in conjunction with a thread object's lifecycle.

-
The general model is that a thread object is allocated each time a
-    new kernel thread is created either by system calls like
-    fork(2) or thr_new(2) or when
-    kernel-only threads are created via kproc_create(9),
-    kproc_kthread_add(9), or kthread_add(9).
-    When a kernel thread exits, the thread object is freed. However, there is
-    one special case to support an optimization where each free process object
-    caches a thread object. When a process exits, the last thread object is not
-    freed but remains attached to the process. When the process object is later
-    reused for a new process in fork(2), the kernel recycles
-    that last thread object and uses it as the initial thread in the new
-    process. When a thread is recycled, some of the steps in the thread
-    allocation and free cycle are skipped as an optimization.

-
()
-    initializes machine-dependent fields in td after
-    allocating a new kernel stack. This function typically sets the
-    td_pcb and initial td_frame
-    pointers. cpu_thread_alloc() is called both when
-    allocating a new thread object and when a recycled thread allocates a new
-    kernel stack. Note that this function is
-     called
-    if a recycled thread reuses its existing kernel stack.

-
()
-    releases any machine-dependent resources for the last thread in a process
-    during wait(2). The thread is a candidate for recycling so
-    should be reset to run as a new thread in case it is recycled by a future
-    fork(2).

-
()
-    cleans any machine-dependent state in td while it is
-    exiting. This is called by the exiting thread so cannot free state needed
-    during in-kernel execution.

-
()
-    releases any machine-dependent state in td when it is
-    being freed. This is called for any thread that was not the last thread in a
-    process once it has finished execution.

-

-

-

-

-
fork(2), procctl(2),
-    ptrace(2), thr_new(2),
-    wait(2), kproc_create(9),
-    kproc_kthread_add(9), kthread_add(9),
-    mi_switch(9)

-

-

-

-
This manual page was developed by SRI International, the
-    University of Cambridge Computer Laboratory (Department of Computer Science
-    and Technology), and Capabilities Limited under contract (FA8750-24-C-B047)
-    (“DEC”).

-

-

-
-  
-    
-    
-  
-
January 31, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/cpuset.9 4.html b/static/freebsd/man9/cpuset.9 4.html
deleted file mode 100644
index e1fcba59..00000000
--- a/static/freebsd/man9/cpuset.9 4.html	
+++ /dev/null
@@ -1,323 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPUSET(9)Kernel Developer's ManualCPUSET(9)

-

-

-

-
cpuset(9) —
-    CPUSET_T_INITIALIZER,
-    CPUSET_FSET, CPU_CLR,
-    CPU_COPY, CPU_ISSET,
-    CPU_SET, CPU_ZERO,
-    CPU_FILL, CPU_SETOF,
-    CPU_EMPTY, CPU_ISFULLSET,
-    CPU_FFS, CPU_COUNT,
-    CPU_SUBSET, CPU_OVERLAP,
-    CPU_CMP, CPU_OR,
-    CPU_ORNOT, CPU_AND,
-    CPU_ANDNOT, CPU_XOR,
-    CPU_CLR_ATOMIC,
-    CPU_TEST_CLR_ATOMIC,
-    CPU_SET_ATOMIC,
-    CPU_SET_ATOMIC_ACQ,
-    CPU_TEST_SET_ATOMIC,
-    CPU_AND_ATOMIC,
-    CPU_OR_ATOMIC,
-    CPU_COPY_STORE_REL — cpuset
-    manipulation macros

-

-

-

-
#include
-    <sys/_cpuset.h>
-  

-  #include <sys/cpuset.h>

-
CPUSET_T_INITIALIZER(ARRAY_CONTENTS);

-
CPUSET_FSET

-
CPU_CLR(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_COPY(cpuset_t
-    *from, cpuset_t
-    *to);

-
bool
-  

-  CPU_ISSET(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_SET(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_ZERO(cpuset_t
-    *cpuset);

-
CPU_FILL(cpuset_t
-    *cpuset);

-
CPU_SETOF(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
bool
-  

-  CPU_EMPTY(cpuset_t
-    *cpuset);

-
bool
-  

-  CPU_ISFULLSET(cpuset_t
-    *cpuset);

-
int
-  

-  CPU_FFS(cpuset_t
-    *cpuset);

-
int
-  

-  CPU_COUNT(cpuset_t
-    *cpuset);

-
bool
-  

-  CPU_SUBSET(cpuset_t
-    *haystack, cpuset_t
-    *needle);

-
bool
-  

-  CPU_OVERLAP(cpuset_t
-    *cpuset1, cpuset_t
-    *cpuset2);

-
bool
-  

-  CPU_CMP(cpuset_t
-    *cpuset1, cpuset_t
-    *cpuset2);

-
CPU_OR(cpuset_t
-    *dst, cpuset_t
-    *src1, cpuset_t
-    *src2);

-
CPU_ORNOT(cpuset_t
-    *dst, cpuset_t
-    *src1, cpuset_t
-    *src2);

-
CPU_AND(cpuset_t
-    *dst, cpuset_t
-    *src1, cpuset_t
-    *src2);

-
CPU_ANDNOT(cpuset_t
-    *dst, cpuset_t
-    *src1, cpuset_t
-    *src2);

-
CPU_XOR(cpuset_t
-    *dst, cpuset_t
-    *src1, cpuset_t
-    *src2);

-
CPU_CLR_ATOMIC(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_TEST_CLR_ATOMIC(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_SET_ATOMIC(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_SET_ATOMIC_ACQ(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_TEST_SET_ATOMIC(size_t
-    cpu_idx, cpuset_t
-    *cpuset);

-
CPU_AND_ATOMIC(cpuset_t
-    *dst, cpuset_t
-    *src);

-
CPU_OR_ATOMIC(cpuset_t
-    *dst, cpuset_t
-    *src);

-
CPU_COPY_STORE_REL(cpuset_t
-    *from, cpuset_t
-    *to);

-

-

-

-
The cpuset(9) family of macros provide a
-    flexible and efficient CPU set implementation, backed by the
-    bitset(9) macros. Each CPU is represented by a single bit.
-    The maximum number of CPUs representable by cpuset_t
-    is CPU_SETSIZE. Individual CPUs in cpusets are
-    referenced with indices zero through CPU_SETSIZE -
-  1.

-
The
-    ()
-    macro allows one to initialize a cpuset_t with a
-    compile time literal value.

-
The
-    ()
-    macro defines a compile time literal, usable by
-    CPUSET_T_INITIALIZER(), representing a full cpuset
-    (all CPUs present). For examples of
-    CPUSET_T_INITIALIZER() and
-    CPUSET_FSET() usage, see the
-    CPUSET_T_INITIALIZER
-    EXAMPLE section.

-
The
-    ()
-    macro removes CPU cpu_idx from the cpuset pointed to
-    by cpuset. The
-    ()
-    macro is identical, but the bit representing the CPU is cleared with atomic
-    machine instructions. The
-    ()
-    macro atomically clears the bit representing the CPU and returns whether it
-    was set.

-
The
-    ()
-    macro copies the contents of the cpuset from to the
-    cpuset to.
-    ()
-    is similar, but copies component machine words from
-    from and writes them to to with
-    atomic store with release semantics. (That is, if to
-    is composed of multiple machine words,
-    CPU_COPY_STORE_REL() performs multiple individually
-    atomic operations.)

-
The
-    ()
-    macro adds CPU cpu_idx to the cpuset pointed to by
-    cpuset, if it is not already present. The
-    ()
-    macro is identical, but the bit representing the CPU is set with atomic
-    machine instructions. The
-    ()
-    macro sets the bit representing the CPU with atomic acquire semantics. The
-    ()
-    macro atomically sets the bit representing the CPU and returns whether it
-    was set.

-
The
-    ()
-    macro returns true if CPU
-    cpu_idx is a member of the cpuset pointed to by
-    cpuset.

-
The
-    ()
-    macro removes all CPUs from cpuset.

-
The
-    ()
-    macro adds all CPUs to cpuset.

-
The
-    ()
-    macro removes all CPUs in cpuset before adding only
-    CPU cpu_idx.

-
The
-    ()
-    macro returns true if cpuset
-    is empty.

-
The
-    ()
-    macro returns true if cpuset
-    is full (the set of all CPUs).

-
The
-    ()
-    macro returns the 1-index of the first (lowest) CPU in
-    cpuset, or zero if cpuset is
-    empty. Like with ffs(3), to use the non-zero result of
-    CPU_FFS() as a cpu_idx index
-    parameter to any other cpuset(9) macro, you must
-    subtract one from the result.

-
The
-    ()
-    macro returns the total number of CPUs in cpuset.

-
The
-    ()
-    macro returns true if needle
-    is a subset of haystack.

-
The
-    ()
-    macro returns true if cpuset1
-    and cpuset2 have any common CPUs. (That is, if
-    cpuset1 AND cpuset2 is not the
-    empty set.)

-
The
-    ()
-    macro returns true if cpuset1
-    is NOT equal to cpuset2.

-
The
-    ()
-    macro adds CPUs present in src to
-    dst. (It is the cpuset(9)
-    equivalent of the scalar: dst |=
-    src.)
-    ()
-    is similar, but sets the bits representing CPUs in the component machine
-    words in dst with atomic machine instructions. (That
-    is, if dst is composed of multiple machine words,
-    CPU_OR_ATOMIC() performs multiple individually
-    atomic operations.)

-
The
-    ()
-    macro add CPUs not in src to
-    dst. (It is the cpuset(9)
-    equivalent of the scalar: dst |= ~
-    src.)

-
The
-    ()
-    macro removes CPUs absent from src from
-    dst. (It is the cpuset(9)
-    equivalent of the scalar: dst &=
-    src.)
-    ()
-    is similar, with the same atomic semantics as
-    CPU_OR_ATOMIC().

-
The
-    ()
-    macro removes CPUs in src from
-    dst. (It is the cpuset(9)
-    equivalent of the scalar: dst &= ~
-    src.)

-

-

-

-

-
cpuset_t myset;
-
-/* Initialize myset to filled (all CPUs) */
-myset = CPUSET_T_INITIALIZER(CPUSET_FSET);
-
-/* Initialize myset to only the lowest CPU */
-myset = CPUSET_T_INITIALIZER(0x1);

-

-

-

-

-
cpuset(1), cpuset(2),
-    bitset(9)

-

-

-

-
<sys/cpuset.h>
-    first appeared in FreeBSD 7.1, released in January
-    2009, and in FreeBSD 8.0, released in November
-  2009.

-
This manual page first appeared in FreeBSD
-    11.0.

-

-

-

-
The cpuset(9) macros were written by
-    Jeff Roberson
-    <jeff@FreeBSD.org>.
-    This manual page was written by Conrad Meyer
-    <cem@FreeBSD.org>.

-

-

-

-
Unlike every other reference to individual set members, which are
-    zero-indexed, CPU_FFS() returns a one-indexed result
-    (or zero if the cpuset is empty).

-

-

-
-  
-    
-    
-  
-
August 7, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/cr_bsd_visible.9 3.html b/static/freebsd/man9/cr_bsd_visible.9 3.html
deleted file mode 100644
index e9fda69c..00000000
--- a/static/freebsd/man9/cr_bsd_visible.9 3.html	
+++ /dev/null
@@ -1,97 +0,0 @@
-
-  
-    
-    
-    
-  
-
CR_BSD_VISIBLE(9)Kernel Developer's ManualCR_BSD_VISIBLE(9)

-

-

-

-
cr_bsd_visible —
-    determine if subjects may see entities according to BSD
-    security policies

-

-

-

-
#include
-    <sys/proc.h>

-
int
-  

-  cr_bsd_visible(struct
-    ucred *u1, struct ucred
-    *u2);

-

-

-

-
This function determines if a subject with credentials
-    u1 is denied seeing an object or subject associated to
-    credentials u2 by the following policies and
-    associated sysctl(8) knobs:

-

-  
security.bsd.seeotheruids

-  
If set to 0, subjects cannot see other subjects or objects if they are not
-      associated with the same real user ID. The corresponding internal function
-      is cr_canseeotheruids(9).

-  
security.bsd.seeothergids

-  
If set to 0, subjects cannot see other subjects or objects if they are not
-      both a member of at least one common group. The corresponding internal
-      function is cr_canseeothergids(9).

-  
security.bsd.see_jail_proc

-  
If set to 0, subjects cannot see other subjects or objects that are not
-      associated with the same jail as they are. The corresponding internal
-      function is cr_canseejailproc(9).

-

-
As usual, the superuser (effective user ID 0) is exempt from any
-    of these policies provided that the sysctl(8) variable
-    security.bsd.suser_enabled is non-zero and no active
-    MAC policy explicitly denies the exemption (see
-    priv_check_cred(9)).

-
This function is intended to be used as a helper to implement
-    cr_cansee(9) and similar functions.

-

-

-

-
This function returns zero if a subject with credentials
-    u1 may see a subject or object with credentials
-    u2 by the active above-mentioned policies, or
-    ESRCH otherwise.

-

-

-

-

-  
[]

-  
Credentials u1 and u2 do not
-      have the same real user ID.

-  
[]

-  
Credentials u1 and u2 are not
-      members of any common group (as determined by
-      realgroupmember(9)).

-  
[]

-  
Credentials u1 and u2 are not
-      in the same jail.

-

-

-

-

-
cr_cansee(9),
-    cr_canseejailproc(9),
-    cr_canseeothergids(9),
-    cr_canseeotheruids(9),
-    priv_check_cred(9)

-

-

-

-
This function and its manual page were written by
-    Olivier Certner
-    <olce.freebsd@certner.fr>.

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/cr_cansee.9 3.html b/static/freebsd/man9/cr_cansee.9 3.html
deleted file mode 100644
index c17f4ccc..00000000
--- a/static/freebsd/man9/cr_cansee.9 3.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
CR_CANSEE(9)Kernel Developer's ManualCR_CANSEE(9)

-

-

-

-
cr_cansee —
-    determine visibility of objects given their user
-    credentials

-

-

-

-
#include
-    <sys/proc.h>

-
int
-  

-  cr_cansee(struct
-    ucred *u1, struct ucred
-    *u2);

-

-

-

-
This function determines if a subject with credential
-    u1 can see a subject or object associated to
-    credential u2.

-
Specific types of subjects may need to submit to additional or
-    different restrictions. As an example, for processes, see
-    p_cansee(9), which calls this function.

-
The implementation relies on cr_bsd_visible(9)
-    and consequently the sysctl(8) variables referenced in its
-    manual page influence the result.

-

-

-

-
This function returns zero if the subject with credential
-    u1 can “see” the subject or object with
-    credential u2, or ESRCH
-    otherwise.

-

-

-

-

-  
[]

-  
The subject with credential u1 has been jailed and
-      the subject or object with credential u2 does not
-      belong to the same jail or one of its sub-jails, as determined by
-      prison_check(9).

-  
[]

-  
The MAC subsystem denied visibility.

-  
[]

-  
cr_bsd_visible(9) denied visibility according to the BSD
-      security policies in force.

-

-

-

-

-
cr_bsd_visible(9), mac(9),
-    p_cansee(9), prison_check(9)

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/cr_canseejailproc.9 4.html b/static/freebsd/man9/cr_canseejailproc.9 4.html
deleted file mode 100644
index e53cab66..00000000
--- a/static/freebsd/man9/cr_canseejailproc.9 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
CR_CANSEEJAILPROC(9)Kernel Developer's ManualCR_CANSEEJAILPROC(9)

-

-

-

-
cr_canseejailproc —
-    determine if subjects may see entities in
-  sub-jails

-

-

-

-
int
-  

-  cr_canseejailproc(struct
-    ucred *u1, struct ucred
-    *u2);

-

-

-

-
This function is internal. Its functionality is integrated
-  into the function cr_bsd_visible(9), which should be called
-  instead.

-
This function checks if a subject associated to credentials
-    u1 is denied seeing a subject or object associated to
-    credentials u2 by a policy that requires both
-    credentials to be associated to the same jail. This is a restriction to the
-    baseline jail policy that a subject can see subjects or objects in its own
-    jail or any sub-jail of it.

-
This policy is active if and only if the
-    sysctl(8) variable
-    security.bsd.see_jail_proc is set to zero.

-
As usual, the superuser (effective user ID 0) is exempt from this
-    policy provided that the sysctl(8) variable
-    security.bsd.suser_enabled is non-zero and no active
-    MAC policy explicitly denies the exemption (see
-    priv_check_cred(9)).

-

-

-

-
The cr_canseejailproc() function returns 0
-    if the policy is disabled, both credentials are associated to the same jail,
-    or if u1 has privilege exempting it from the policy.
-    Otherwise, it returns ESRCH.

-

-

-

-
cr_bsd_visible(9),
-    priv_check_cred(9)

-

-

-

-
This manual page was written by Olivier
-    Certner
-    <olce.freebsd@certner.fr>.

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/cr_canseeothergids.9 4.html b/static/freebsd/man9/cr_canseeothergids.9 4.html
deleted file mode 100644
index 60dd82af..00000000
--- a/static/freebsd/man9/cr_canseeothergids.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
CR_CANSEEOTHERGIDS(9)Kernel Developer's ManualCR_CANSEEOTHERGIDS(9)

-

-

-

-
cr_canseeothergids —
-    determine if subjects may see entities in a disjoint group
-    set

-

-

-

-
int
-  

-  cr_canseeothergids(struct
-    ucred *u1, struct ucred
-    *u2);

-

-

-

-
This function is internal. Its functionality is integrated
-  into the function cr_bsd_visible(9), which should be called
-  instead.

-
This function checks if a subject associated to credentials
-    u1 is denied seeing a subject or object associated to
-    credentials u2 by a policy that requires both
-    credentials to have at least one group in common. For this determination,
-    the real and supplementary group IDs are used, but not the effective group
-    IDs, as per realgroupmember(9).

-
This policy is active if and only if the
-    sysctl(8) variable
-    security.bsd.see_other_gids is set to zero.

-
As usual, the superuser (effective user ID 0) is exempt from this
-    policy provided that the sysctl(8) variable
-    security.bsd.suser_enabled is non-zero and no active
-    MAC policy explicitly denies the exemption (see
-    priv_check_cred(9)).

-

-

-

-
The cr_canseeothergids() function returns
-    0 if the policy is disabled, the credentials share at least one common
-    group, or if u1 has privilege exempting it from the
-    policy. Otherwise, it returns ESRCH.

-

-

-

-
cr_bsd_visible(9),
-    priv_check_cred(9),
-  realgroupmember(9)

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/cr_canseeotheruids.9 4.html b/static/freebsd/man9/cr_canseeotheruids.9 4.html
deleted file mode 100644
index fb57c009..00000000
--- a/static/freebsd/man9/cr_canseeotheruids.9 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
CR_CANSEEOTHERUIDS(9)Kernel Developer's ManualCR_CANSEEOTHERUIDS(9)

-

-

-

-
cr_canseeotheruids —
-    determine if subjects may see entities with differing user
-    ID

-

-

-

-
int
-  

-  cr_canseeotheruids(struct
-    ucred *u1, struct ucred
-    *u2);

-

-

-

-
This function is internal. Its functionality is integrated
-  into the function cr_bsd_visible(9), which should be called
-  instead.

-
This function checks if a subject associated to credentials
-    u1 is denied seeing a subject or object associated to
-    credentials u2 by a policy that requires both
-    credentials to have the same real user ID.

-
This policy is active if and only if the
-    sysctl(8) variable
-    security.bsd.see_other_uids is set to zero.

-
As usual, the superuser (effective user ID 0) is exempt from this
-    policy provided that the sysctl(8) variable
-    security.bsd.suser_enabled is non-zero and no active
-    MAC policy explicitly denies the exemption (see
-    priv_check_cred(9)).

-

-

-

-
The cr_canseeotheruids() function returns
-    0 if the policy is disabled, both credentials have the same real user ID, or
-    if u1 has privilege exempting it from the policy.
-    Otherwise, it returns ESRCH.

-

-

-

-
cr_bsd_visible(9),
-    priv_check_cred(9)

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/critical_enter.9 3.html b/static/freebsd/man9/critical_enter.9 3.html
deleted file mode 100644
index 8f5d8b6a..00000000
--- a/static/freebsd/man9/critical_enter.9 3.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRITICAL_ENTER(9)Kernel Developer's ManualCRITICAL_ENTER(9)

-

-

-

-
critical_enter,
-    critical_exit — enter and
-    exit a critical region

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  critical_enter(void);

-
void
-  

-  critical_exit(void);

-
CRITICAL_ASSERT(struct
-    thread *td);

-

-

-

-
These functions are used to prevent preemption in a critical
-    region of code. All that is guaranteed is that the thread currently
-    executing on a CPU will not be preempted. Specifically, a thread in a
-    critical region will not migrate to another CPU while it is in a critical
-    region, nor will the current CPU switch to a different thread. The current
-    CPU may still trigger faults and exceptions during a critical section;
-    however, these faults are usually fatal.

-
The CPU might also receive and handle interrupts within a critical
-    section. When this occurs the interrupt exit will not result in a context
-    switch, and execution will continue in the critical section. Thus, the net
-    effect of a critical section on the current thread's execution is similar to
-    running with interrupts disabled, except that timer interrupts and filtered
-    interrupt handlers do not incur a latency penalty.

-
The
-    ()
-    and
-    ()
-    functions manage a per-thread counter to handle nested critical sections. If
-    a thread is made runnable that would normally preempt the current thread
-    while the current thread is in a critical section, then the preemption will
-    be deferred until the current thread exits the outermost critical
-  section.

-
Note that these functions do not provide any inter-CPU
-    synchronization, data protection, or memory ordering guarantees, and thus
-    should  be used to
-    protect shared data structures.

-
These functions should be used with care as an unbound or infinite
-    loop within a critical region will deadlock the CPU. Also, they should not
-    be interlocked with operations on mutexes, sx locks, semaphores, or other
-    synchronization primitives, as these primitives may require a context switch
-    to operate. One exception to this is that spin mutexes include a critical
-    section, so in certain cases critical sections may be interlocked with spin
-    mutexes.

-
Critical regions should be only as wide as necessary. That is,
-    code which does not require the critical section to operate correctly should
-    be excluded from its bounds whenever possible. Abuse of critical sections
-    has an effect on overall system latency and timer precision, since disabling
-    preemption will delay the execution of threaded interrupt handlers and
-    callout(9) events on the current CPU.

-
The
-    ()
-    macro verifies that the provided thread td is
-    currently executing in a critical section. It is a wrapper around
-    KASSERT(9).

-

-

-

-
callout(9), KASSERT(9),
-    locking(9)

-

-

-

-
These functions were introduced in FreeBSD
-    5.0.

-

-

-
-  
-    
-    
-  
-
March 20, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/crypto.9 3.html b/static/freebsd/man9/crypto.9 3.html
deleted file mode 100644
index 5d0efed8..00000000
--- a/static/freebsd/man9/crypto.9 3.html	
+++ /dev/null
@@ -1,182 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRYPTO(9)Kernel Developer's ManualCRYPTO(9)

-

-

-

-
crypto — API for
-    cryptographic services in the kernel

-

-

-

-
#include
-    <opencrypto/cryptodev.h>

-

-

-

-
crypto is a framework for in-kernel
-    cryptography. It permits in-kernel consumers to encrypt and decrypt data and
-    also enables userland applications to use cryptographic hardware through the
-    /dev/crypto device.

-
crypto supports encryption and decryption
-    operations using block and stream ciphers as well as computation and
-    verification of message authentication codes (MACs). Consumers allocate
-    sessions to describe a transform as discussed in
-    crypto_session(9). Consumers then allocate request objects
-    to describe each transformation such as encrypting a network packet or
-    decrypting a disk sector. Requests are described in
-    crypto_request(9).

-
Device drivers are responsible for processing requests submitted
-    by consumers. crypto_driver(9) describes the interfaces
-    drivers use to register with the framework, helper routines the framework
-    provides to facilitate request processing, and the interfaces drivers are
-    required to provide.

-

-

-
Since the consumers may not be associated with a process, drivers
-    may not sleep(9). The same holds for the framework. Thus,
-    a callback mechanism is used to notify a consumer that a request has been
-    completed (the callback is specified by the consumer on a per-request
-    basis). The callback is invoked by the framework whether the request was
-    successfully completed or not. Errors are reported to the callback
-  function.

-
Session initialization does not use callbacks and returns errors
-    synchronously.

-

-

-

-
Operations may fail with a specific error code,
-    EAGAIN, to indicate that a session handle has
-    changed and that the request may be re-submitted immediately with the new
-    session. The consumer should update its saved copy of the session handle to
-    the value of crp_session so that future requests use
-    the new session.

-

-

-

-
More details on some algorithms may be found in
-    crypto(7).

-
The following authentication algorithms are supported:

-

-

-

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-

-

-
The following encryption algorithms are supported:

-

-

-

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-

-

-
The following authenticated encryption with additional data (AEAD)
-    algorithms are supported:

-

-

-

-  

-  
 

-  

-  
 

-  

-  
 

-

-

-
The following compression algorithms are supported:

-

-

-

-  

-  
 

-

-

-

-

-

-

-

-  
sys/opencrypto/crypto.c

-  
most of the framework code

-

-

-

-

-
crypto(4), ipsec(4),
-    crypto(7), crypto_driver(9),
-    crypto_request(9), crypto_session(9),
-    sleep(9)

-

-

-

-
The cryptographic framework first appeared in
-    OpenBSD 2.7 and was written by
-    Angelos D. Keromytis
-    <angelos@openbsd.org>.

-

-

-

-
The framework needs a mechanism for determining which driver is
-    best for a specific set of algorithms associated with a session. Some type
-    of benchmarking is in order here.

-

-

-
-  
-    
-    
-  
-
April 12, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/crypto_buffer.9 3.html b/static/freebsd/man9/crypto_buffer.9 3.html
deleted file mode 100644
index cb954fa0..00000000
--- a/static/freebsd/man9/crypto_buffer.9 3.html	
+++ /dev/null
@@ -1,256 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRYPTO_BUFFER(9)Kernel Developer's ManualCRYPTO_BUFFER(9)

-

-

-

-
crypto_buffer —
-    symmetric cryptographic request buffers

-

-

-

-
#include
-    <opencrypto/cryptodev.h>

-
int
-  

-  crypto_apply(struct cryptop
-    *crp, int off, int len,
-    int (*f)(void *, void *, u_int), void
-    *arg);

-
int
-  

-  crypto_apply_buf(struct crypto_buffer
-    *cb, int off, int len,
-    int (*f)(void *, void *, u_int), void
-    *arg);

-
void *
-  

-  crypto_buffer_contiguous_subsegment(struct
-    crypto_buffer *cb, size_t skip,
-    size_t len);

-
size_t
-  

-  crypto_buffer_len(struct
-    crypto_buffer *cb);

-
void *
-  

-  crypto_contiguous_subsegment(struct
-    cryptop *crp, size_t skip,
-    size_t len);

-
void
-  

-  crypto_cursor_init(struct
-    crypto_buffer_cursor *cc, const struct crypto_buffer
-    *cb);

-
void
-  

-  crypto_cursor_advance(struct
-    crypto_buffer_cursor *cc,
-    size_t amount);

-
void
-  

-  crypto_cursor_copyback(struct
-    crypto_buffer_cursor *cc, int size,
-    const void *src);

-
void
-  

-  crypto_cursor_copydata(struct
-    crypto_buffer_cursor *cc, int size,
-    void *dst);

-
void
-  

-  crypto_cursor_copydata_noadv(struct
-    crypto_buffer_cursor *cc, int size,
-    void *dst);

-
void *
-  

-  crypto_cursor_segment(struct
-    crypto_buffer_cursor *cc,
-    size_t *len);

-
void
-  

-  crypto_cursor_copy(const struct
-    crypto_buffer_cursor *fromc, struct
-    crypto_buffer_cursor *toc);

-
bool
-  

-  CRYPTO_HAS_OUTPUT_BUFFER(struct
-    cryptop *crp);

-

-

-

-
Symmetric cryptographic requests use data buffers to describe the
-    data to be modified. Requests can either specify a single data buffer whose
-    contents are modified in place, or requests may specify separate data
-    buffers for input and output. struct crypto_buffer
-    provides an abstraction that permits cryptographic requests to operate on
-    different types of buffers. struct crypto_cursor
-    allows cryptographic drivers to iterate over a data buffer.

-
()
-    returns true if crp uses separate buffers for input
-    and output and false if crp uses a single buffer.

-
()
-    returns the length of data buffer cb in bytes.

-
()
-    invokes a caller-supplied function to a region of the data buffer
-    cb. The function f is called one
-    or more times. For each invocation, the first argument to
-    f is the value of arg passed to
-    crypto_apply_buf(). The second and third arguments
-    to f are a pointer and length to a segment of the
-    buffer mapped into the kernel. The function is called enough times to cover
-    the len bytes of the data buffer which starts at an
-    offset off. If any invocation of
-    f returns a non-zero value,
-    crypto_apply_buf() immediately returns that value
-    without invoking f on any remaining segments of the
-    region, otherwise crypto_apply_buf() returns the
-    value from the final call to f.
-    ()
-    invokes the callback f on a region of the input data
-    buffer for crp.

-
()
-    attempts to locate a single, virtually-contiguous segment of the data buffer
-    cb. The segment must be len
-    bytes long and start at an offset of skip bytes. If a
-    segment is found, a pointer to the start of the segment is returned.
-    Otherwise, NULL is returned.
-    ()
-    attempts to locate a single, virtually-contiguous segment in the input data
-    buffer for crp.

-

-

-
Data buffers are described by an instance of
-    struct crypto buffer. The
-    cb_type member contains the type of the data buffer.
-    The following types are supported:

-

-  

-  
An invalid buffer. Used to mark the output buffer when a crypto request
-      uses a single data buffer.

-  

-  
An array of bytes mapped into the kernel's address space.

-  

-  
A scatter/gather list of kernel buffers as described in
-      uio(9).

-  

-  
A chain of network memory buffers as described in
-      mbuf(9).

-  

-  
A single network memory buffer as described in
-    mbuf(9).

-  

-  
A scatter/gather list of vm_page_t structures
-      describing pages in the kernel's address space. This buffer type is only
-      available if CRYPTO_HAS_VMPAGE is true.

-

-
The structure also contains the following type-specific
-  fields:

-

-  
cb_buf

-  
A pointer to the start of a CRYPTO_BUF_CONTIG data
-      buffer.

-  
cb_buf_len

-  
The length of a CRYPTO_BUF_CONTIG data buffer

-  
cb_mbuf

-  
A pointer to a struct mbuf for
-      CRYPTO_BUF_MBUF and
-      CRYPTO_BUF_SINGLE_MBUF.

-  
cb_uio

-  
A pointer to a struct uio for
-      CRYPTO_BUF_UIO.

-  
cb_vm_page

-  
A pointer to an array of struct vm_page for
-      CRYPTO_BUF_VMPAGE.

-  
cb_vm_page_len

-  
The total amount of data included in the cb_vm_page
-      array, in bytes.

-  
cb_vm_page_offset

-  
Offset in bytes in the first page of cb_vm_page
-      where valid data begins.

-

-

-

-

-
Cursors provide a mechanism for iterating over a data buffer. They
-    are primarily intended for use in software drivers which access data buffers
-    via virtual addresses.

-
()
-    initializes the cursor cc to reference the start of
-    the data buffer cb.

-
()
-    advances the cursor amount bytes forward in the data
-    buffer.

-
()
-    copies size bytes from the local buffer pointed to by
-    src into the data buffer associated with
-    cc. The bytes are written to the current position of
-    cc, and the cursor is then advanced by
-    size bytes.

-
()
-    copies size bytes out of the data buffer associated
-    with cc into a local buffer pointed to by
-    dst. The bytes are read from the current position of
-    cc, and the cursor is then advanced by
-    size bytes.

-
()
-    is similar to crypto_cursor_copydata() except that
-    it does not change the current position of cc.

-
()
-    returns the start of the virtually-contiguous segment at the current
-    position of cc. The length of the segment is stored in
-    len.

-

-

-

-

-
crypto_apply() and
-    crypto_apply_buf() return the return value from the
-    caller-supplied callback function.

-
crypto_buffer_contiguous_subsegment(),
-    crypto_contiguous_subsegment(), and
-    crypto_cursor_segment() return a pointer to a
-    contiguous segment or NULL.

-
crypto_buffer_len() returns the length of
-    a buffer in bytes.

-
crypto_cursor_seglen() returns the length
-    in bytes of a contiguous segment.

-
crypto_cursor_copy() makes a deep copy of
-    the cursor fromc. The two copies do not share any
-    state and can thus be used independently.

-
CRYPTO_HAS_OUTPUT_BUFFER() returns true if
-    the request uses a separate output buffer.

-

-

-

-
ipsec(4), crypto(7),
-    bus_dma(9), crypto(9),
-    crypto_driver(9), crypto_request(9),
-    crypto_session(9), mbuf(9),
-    uio(9)

-

-

-

-
The crypto_buffer functions first appeared
-    in FreeBSD 13.

-

-

-

-
The crypto_buffer functions and this
-    manual page were written by John Baldwin
-    <jhb@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 11, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/crypto_driver.9 4.html b/static/freebsd/man9/crypto_driver.9 4.html
deleted file mode 100644
index ca7af164..00000000
--- a/static/freebsd/man9/crypto_driver.9 4.html	
+++ /dev/null
@@ -1,269 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRYPTO_DRIVER(9)Kernel Developer's ManualCRYPTO_DRIVER(9)

-

-

-

-
crypto_driver —
-    interface for symmetric cryptographic drivers

-

-

-

-
#include
-    <opencrypto/cryptodev.h>

-
void
-  

-  crypto_copyback(struct
-    cryptop *crp, int
-    off, int size,
-    const void *src);

-
void
-  

-  crypto_copydata(struct
-    cryptop *crp, int
-    off, int size,
-    void *dst);

-
void
-  

-  crypto_done(struct
-    cryptop *crp);

-
int32_t
-  

-  crypto_get_driverid(device_t
-    dev, size_t
-    session_size, int
-    flags);

-
void *
-  

-  crypto_get_driver_session(crypto_session_t
-    crypto_session);

-
void
-  

-  crypto_read_iv(struct
-    cryptop *crp, void
-    *iv);

-
int
-  

-  crypto_unblock(uint32_t
-    driverid, int
-    what);

-
int
-  

-  crypto_unregister_all(uint32_t
-    driverid);

-
int
-  

-  CRYPTODEV_FREESESSION(device_t
-    dev, crypto_session_t
-    crypto_session);

-
int
-  

-  CRYPTODEV_NEWSESSION(device_t
-    dev, crypto_session_t crypto_session,
-    const struct crypto_session_params *csp);

-
int
-  

-  CRYPTODEV_PROBESESSION(device_t
-    dev, const struct crypto_session_params
-  *csp);

-
int
-  

-  CRYPTODEV_PROCESS(device_t
-    dev, struct cryptop
-    *crp, int
-  flags);

-
void
-  

-  hmac_init_ipad(struct auth_hash
-    *axf, const char *key, int
-    klen, void *auth_ctx);

-
void
-  

-  hmac_init_opad(struct auth_hash
-    *axf, const char *key, int
-    klen, void *auth_ctx);

-

-

-

-
Symmetric cryptographic drivers process cryptographic requests
-    submitted to sessions associated with the driver.

-
Cryptographic drivers call
-    ()
-    to register with the cryptographic framework. dev is
-    the device used to service requests. The
-    ()
-    methods are defined in the method table for the device driver attached to
-    dev. session_size specifies the
-    size of a driver-specific per-session structure allocated by the
-    cryptographic framework. flags is a bitmask of
-    properties about the driver. Exactly one of
-    CRYPTOCAP_F_SOFTWARE or
-    CRYPTOCAP_F_HARDWARE must be specified.
-    CRYPTOCAP_F_SOFTWARE should be used for drivers
-    which process requests using host CPUs.
-    CRYPTOCAP_F_HARDWARE should be used for drivers
-    which process requests on separate co-processors.
-    CRYPTOCAP_F_SYNC should be set for drivers which
-    process requests synchronously in
-    CRYPTODEV_PROCESS().
-    CRYPTOCAP_F_ACCEL_SOFTWARE should be set for
-    software drivers which use accelerated CPU instructions.
-    crypto_get_driverid() returns an opaque driver
-  id.

-
()
-    unregisters a driver from the cryptographic framework. If there are any
-    pending operations or open sessions, this function will sleep.
-    driverid is the value returned by an earlier call to
-    crypto_get_driverid().

-
When a new session is created by
-    (),
-    ()
-    is invoked by the cryptographic framework on each active driver to determine
-    the best driver to use for the session. This method should inspect the
-    session parameters in csp. If a driver does not
-    support requests described by csp, this method should
-    return an error value. If the driver does support requests described by
-    csp, it should return a negative value. The framework
-    prefers drivers with the largest negative value, similar to
-    DEVICE_PROBE(9). The following values are defined for
-    non-error return values from this method:

-

-  

-  
The driver processes requests via a co-processor.

-  

-  
The driver processes requests on the host CPU using optimized instructions
-      such as AES-NI.

-  

-  
The driver processes requests on the host CPU.

-

-
This method should not sleep.

-
Once the framework has chosen a driver
-    for a session, the framework invokes the
-    ()
-    method to initialize driver-specific session state. Prior to calling this
-    method, the framework allocates a per-session driver-specific data
-    structure. This structure is initialized with zeroes, and its size is set by
-    the session_size passed to
-    crypto_get_driverid(). This method can retrieve a
-    pointer to this data structure by passing
-    crypto_session to
-    crypto_get_driver_session(). Session parameters are
-    described in csp.

-
This method should not sleep.

-
()
-    is invoked to release any driver-specific state when a session is destroyed.
-    The per-session driver-specific data structure is explicitly zeroed and
-    freed by the framework after this method returns. If a driver requires no
-    additional tear-down steps, it can leave this method undefined.

-
This method should not sleep.

-
()
-    is invoked for each request submitted to an active session. This method can
-    either complete a request synchronously or schedule it to be completed
-    asynchronously, but it must not sleep.

-
If this method is not able to complete a
-    request due to insufficient resources such as a full command queue, it can
-    defer the request by returning ERESTART. The request
-    will be queued by the framework and retried once the driver releases pending
-    requests via
-    ().
-    Any requests submitted to sessions belonging to the driver will also be
-    queued until crypto_unblock() is called.

-
If a driver encounters errors while processing a request, it
-    should report them via the crp_etype field of
-    crp rather than returning an error directly.

-
flags may be set to
-    CRYPTO_HINT_MORE if there are additional requests
-    queued for this driver. The driver can use this as a hint to batch
-    completion interrupts. Note that these additional requests may be from
-    different sessions.

-
()
-    returns a pointer to the driver-specific per-session data structure for the
-    session crypto_session. This function can be used in
-    the CRYPTODEV_NEWSESSION(),
-    CRYPTODEV_PROCESS(), and
-    CRYPTODEV_FREESESSION() callbacks.

-
()
-    copies size bytes out of the input buffer for
-    crp into a local buffer pointed to by
-    dst. The bytes are read starting at an offset of
-    off bytes in the request's input buffer.

-
()
-    copies size bytes from the local buffer pointed to by
-    src into the output buffer for
-    crp. The bytes are written starting at an offset of
-    off bytes in the request's output buffer.

-
()
-    copies the IV or nonce for crp into the local buffer
-    pointed to by iv.

-
A driver calls
-    ()
-    to mark the request crp as completed. Any errors
-    should be set in crp_etype prior to calling this
-    function.

-
If a driver defers a request by returning
-    ERESTART from
-    CRYPTO_PROCESS, the framework will queue all
-    requests for the driver until the driver calls
-    ()
-    to indicate that the temporary resource shortage has been relieved. For
-    example, if a driver returns ERESTART due to a full
-    command ring, it would invoke crypto_unblock() from
-    a command completion interrupt that makes a command ring entry available.
-    driverid is the value returned by
-    crypto_get_driverid(). what
-    indicates which types of requests the driver is able to handle again:

-

-  

-  
indicates that the driver is able to handle symmetric requests passed to
-      CRYPTODEV_PROCESS().

-

-
()
-    prepares an authentication context to generate the inner hash of an HMAC.
-    axf is a software implementation of an authentication
-    algorithm such as the value returned by
-    ().
-    key is a pointer to a HMAC key of
-    klen bytes. auth_ctx points to a
-    valid authentication context for the desired algorithm. The function
-    initializes the context with the supplied key.

-
()
-    is similar to hmac_init_ipad() except that it
-    prepares an authentication context to generate the outer hash of an
-  HMAC.

-

-

-

-
crypto_apply() returns the return value
-    from the caller-supplied callback function.

-
crypto_contiguous_subsegment() returns a
-    pointer to a contiguous segment or NULL.

-
crypto_get_driverid() returns a driver
-    identifier on success or -1 on error.

-
crypto_unblock(),
-    crypto_unregister_all(),
-    CRYPTODEV_FREESESSION(),
-    CRYPTODEV_NEWSESSION(), and
-    CRYPTODEV_PROCESS() return zero on success or an
-    error on failure.

-
CRYPTODEV_PROBESESSION() returns a
-    negative value on success or an error on failure.

-

-

-

-
crypto(7), crypto(9),
-    crypto_buffer(9), crypto_request(9),
-    crypto_session(9)

-

-

-
-  
-    
-    
-  
-
April 12, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/crypto_request.9 4.html b/static/freebsd/man9/crypto_request.9 4.html
deleted file mode 100644
index f33fe032..00000000
--- a/static/freebsd/man9/crypto_request.9 4.html	
+++ /dev/null
@@ -1,505 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRYPTO_REQUEST(9)Kernel Developer's ManualCRYPTO_REQUEST(9)

-

-

-

-
crypto_request —
-    symmetric cryptographic operations

-

-

-

-
#include
-    <opencrypto/cryptodev.h>

-
struct cryptop *
-  

-  crypto_clonereq(crypto_session_t
-    cses, struct cryptop
-    *crp, int how);

-
int
-  

-  crypto_dispatch(struct
-    cryptop *crp);

-
int
-  

-  crypto_dispatch_async(struct
-    cryptop *crp, int
-    flags);

-
void
-  

-  crypto_dispatch_batch(struct
-    cryptopq *crpq, int
-    flags);

-
void
-  

-  crypto_destroyreq(struct
-    cryptop *crp);

-
void
-  

-  crypto_freereq(struct
-    cryptop *crp);

-
struct cryptop *
-  

-  crypto_getreq(crypto_session_t
-    cses, int how);

-
void
-  

-  crypto_initreq(struct
-    cryptop *crp,
-    crypto_session_t
-  cses);

-
void
-  

-  crypto_use_buf(struct
-    cryptop *crp, void
-    *buf, int len);

-
void
-  

-  crypto_use_mbuf(struct
-    cryptop *crp, struct mbuf
-    *m);

-
void
-  

-  crypto_use_uio(struct
-    cryptop *crp, struct uio
-    *uio);

-
void
-  

-  crypto_use_vmpage(struct
-    cryptop *crp, vm_page_t
-    *pages, int len,
-    int offset);

-
void
-  

-  crypto_use_output_buf(struct
-    cryptop *crp, void
-    *buf, int len);

-
void
-  

-  crypto_use_output_mbuf(struct
-    cryptop *crp, struct mbuf
-    *m);

-
void
-  

-  crypto_use_output_uio(struct
-    cryptop *crp, struct uio
-    *uio);

-
void
-  

-  crypto_use_output_vmpage(struct
-    cryptop *crp, vm_page_t
-    *pages, int len,
-    int offset);

-

-

-

-
Each symmetric cryptographic operation in the kernel is described
-    by an instance of struct cryptop and is associated
-    with an active session.

-
Requests can either be allocated dynamically or
-    use caller-supplied storage. Dynamically allocated requests should be
-    allocated by either
-    ()
-    or crypto_clonereq(), and freed by
-    crypto_freereq() once the request has completed.
-    Requests using caller-supplied storage should be initialized by
-    crypto_initreq() at the start of each operation and
-    destroyed by crypto_destroyreq() once the request
-    has completed.

-
For
-    (),
-    crypto_getreq(), and
-    (),
-    cses is a reference to an active session. For
-    crypto_clonereq() and
-    crypto_getreq(), how is passed
-    to malloc(9) and should be set to either
-    M_NOWAIT or M_WAITOK.

-
()
-    allocates a new request that inherits request inputs such as request buffers
-    from the original crp request. However, the new
-    request is associated with the cses session rather
-    than inheriting the session from crp.
-    crp must not be a completed request.

-
Once a request has been initialized, the caller should set fields
-    in the structure to describe request-specific parameters. Unused fields
-    should be left as-is.

-
The
-    (),
-    crypto_dispatch_async(), and
-    crypto_dispatch_batch() functions pass one or more
-    crypto requests to the driver attached to the request's session. If there
-    are errors in the request's fields, these functions may return an error to
-    the caller. If errors are encountered while servicing the request, they will
-    instead be reported to the request's callback function
-    (crp_callback) via
-  crp_etype.

-
Note that a request's callback function may
-    be invoked before
-    ()
-    returns.

-
Once a request has signaled completion by
-    invoking its callback function, it should be freed via
-    ()
-    or
-    ().

-
Cryptographic operations include several fields to describe the
-    request.

-

-

-
Requests can either specify a single data buffer that is modified
-    in place (crp_buf) or separate input
-    (crp_buf) and output (crp_obuf)
-    buffers. Note that separate input and output buffers are not supported for
-    compression mode requests.

-
All requests must have a valid crp_buf
-    initialized by one of the following functions:

-

-  
()

-  
Uses an array of len bytes pointed to by
-      buf as the data buffer.

-  
()

-  
Uses the network memory buffer m as the data
-    buffer.

-  
()

-  
Uses the scatter/gather list uio as the data
-    buffer.

-  
()

-  
Uses the array of vm_page_t structures as the data
-      buffer.

-

-
One of the following functions should be used to initialize
-    crp_obuf for requests that use separate input and
-    output buffers:

-

-  
()

-  
Uses an array of len bytes pointed to by
-      buf as the output buffer.

-  
()

-  
Uses the network memory buffer m as the output
-      buffer.

-  
()

-  
Uses the scatter/gather list uio as the output
-      buffer.

-  
()

-  
Uses the array of vm_page_t structures as the output
-      buffer.

-

-

-

-

-
Each request describes one or more regions in the data buffers.
-    Each region is described by an offset relative to the start of a data buffer
-    and a length. The length of some regions is the same for all requests
-    belonging to a session. Those lengths are set in the session parameters of
-    the associated session. All requests must define a payload region. Other
-    regions are only required for specific session modes.

-
For requests with separate input and output data buffers, the AAD,
-    IV, and payload regions are always defined as regions in the input buffer,
-    and a separate payload output region is defined to hold the output of
-    encryption or decryption in the output buffer. The digest region describes a
-    region in the input data buffer for requests that verify an existing digest.
-    For requests that compute a digest, the digest region describes a region in
-    the output data buffer. Note that the only data written to the output buffer
-    is the encryption or decryption result and any computed digest. AAD and IV
-    regions are not copied from the input buffer into the output buffer but are
-    only used as inputs.

-
The following regions are defined:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
AADInputEmbedded Additional Authenticated Data
IVInputEmbedded IV or nonce
PayloadInputData to encrypt, decrypt, compress, or decompress
Payload OutputOutputEncrypted or decrypted data
DigestInput/OutputAuthentication digest, hash, or tag

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
AADcrp_aad_startcrp_aad_length
IVcrp_iv_startcsp_ivlen
Payloadcrp_payload_startcrp_payload_length
Payload Outputcrp_payload_output_startcrp_payload_length
Digestcrp_digest_startcsp_auth_mlen

-
Requests are permitted to operate on only a subset of the data
-    buffer. For example, requests from IPsec operate on network packets that
-    include headers not used as either additional authentication data (AAD) or
-    payload data.

-

-

-

-
All requests must specify the type of operation to perform in
-    crp_op. Available operations depend on the session's
-    mode.

-
Compression requests support the following operations:

-

-  

-  
Compress the data in the payload region of the data buffer.

-  

-  
Decompress the data in the payload region of the data buffer.

-

-
Cipher requests support the following operations:

-

-  

-  
Encrypt the data in the payload region of the data buffer.

-  

-  
Decrypt the data in the payload region of the data buffer.

-

-
Digest requests support the following operations:

-

-  

-  
Calculate a digest over the payload region of the data buffer and store
-      the result in the digest region.

-  

-  
Calculate a digest over the payload region of the data buffer. Compare the
-      calculated digest to the existing digest from the digest region. If the
-      digests match, complete the request successfully. If the digests do not
-      match, fail the request with EBADMSG.

-

-
AEAD and Encrypt-then-Authenticate requests support the following
-    operations:

-

-  

-    |
-    

-  
Encrypt the data in the payload region of the data buffer. Calculate a
-      digest over the AAD and payload regions and store the result in the data
-      buffer.

-  

-    |
-    

-  
Calculate a digest over the AAD and payload regions of the data buffer.
-      Compare the calculated digest to the existing digest from the digest
-      region. If the digests match, decrypt the payload region. If the digests
-      do not match, fail the request with EBADMSG.

-

-

-

-

-
AEAD and Encrypt-then-Authenticate requests may optionally include
-    Additional Authenticated Data. AAD may either be supplied in the AAD region
-    of the input buffer or as a single buffer pointed to by
-    crp_aad. In either case,
-    crp_aad_length always indicates the amount of AAD in
-    bytes.

-

-

-

-
IPsec requests may optionally include Extended Sequence Numbers
-    (ESN). ESN may either be supplied in crp_esn or as
-    part of the AAD pointed to by crp_aad.

-
If the ESN is stored in crp_esn,
-    CSP_F_ESN should be set in
-    csp_flags. This use case is dedicated for encrypt and
-    authenticate mode, since the high-order 32 bits of the sequence number are
-    appended after the Next Header (RFC 4303).

-
AEAD modes supply the ESN in a separate AAD buffer (see e.g. RFC
-    4106, Chapter 5 AAD Construction).

-

-

-

-
Some cryptographic operations require an IV or nonce as an input.
-    An IV may be stored either in the IV region of the data buffer or in
-    crp_iv. By default, the IV is assumed to be stored in
-    the IV region. If the IV is stored in crp_iv,
-    CRYPTO_F_IV_SEPARATE should be set in
-    crp_flags and crp_iv_start
-    should be left as zero.

-
Requests that store part, but not all, of the IV in the data
-    buffer should store the partial IV in the data buffer and pass the full IV
-    separately in crp_iv.

-

-

-

-
The crypto framework provides multiple methods of scheduling the
-    dispatch of requests to drivers along with the processing of driver
-    callbacks. The
-    (),
-    crypto_dispatch_async(), and
-    crypto_dispatch_batch() functions can be used to
-    request different dispatch scheduling policies.

-
()
-    synchronously passes the request to the driver. The driver itself may
-    process the request synchronously or asynchronously depending on whether the
-    driver is implemented by software or hardware.

-
()
-    dispatches the request asynchronously. If the driver is inherently
-    synchronous, the request is queued to a taskqueue backed by a pool of worker
-    threads. This can increase throughput by allowing requests from a single
-    producer to be processed in parallel. By default the pool is sized to
-    provide one thread for each CPU. Worker threads dequeue requests and pass
-    them to the driver asynchronously.
-    crypto_dispatch_async() additionally takes a
-    flags parameter. The
-    CRYPTO_ASYNC_ORDERED flag indicates that completion
-    callbacks for requests must be called in the same order as requests were
-    dispatched. If the driver is asynchronous, the behavior of
-    crypto_dispatch_async() is identical to that of
-    crypto_dispatch().

-
()
-    allows the caller to collect a batch of requests and submit them to the
-    driver at the same time. This allows hardware drivers to optimize the
-    scheduling of request processing and batch completion interrupts. A batch is
-    submitted to the driver by invoking the driver's process method on each
-    request, specifying CRYPTO_HINT_MORE with each
-    request except for the last. The flags parameter to
-    crypto_dispatch_batch() is currently ignored.

-
Callback function scheduling is simpler than
-    request scheduling. Callbacks can either be invoked synchronously from
-    (),
-    or they can be queued to a pool of worker threads. This pool of worker
-    threads is also sized to provide one worker thread for each CPU by default.
-    Note that a callback function invoked synchronously from
-    crypto_done() must follow the same restrictions
-    placed on threaded interrupt handlers.

-
By default, callbacks are invoked
-    asynchronously by a worker thread. If CRYPTO_F_CBIMM
-    is set, the callback is always invoked synchronously from
-    ().
-    If CRYPTO_F_CBIFSYNC is set, the callback is invoked
-    synchronously if the request was processed by a software driver or
-    asynchronously if the request was processed by a hardware driver.

-
If a request was scheduled to the taskqueue with
-    CRYPTO_ASYNC_ORDERED, callbacks are always invoked
-    asynchronously ignoring CRYPTO_F_CBIMM and
-    CRYPTO_F_CBIFSYNC. This flag is used by IPsec to
-    ensure that decrypted network packets are passed up the network stack in
-    roughly the same order they were received.

-

-

-

-
In addition to the fields and flags enumerated above,
-    struct cryptop includes the following:

-

-  
crp_session

-  
A reference to the active session. This is set when the request is created
-      by
-      ()
-      and should not be modified. Drivers can use this to fetch driver-specific
-      session state or session parameters.

-  
crp_etype

-  
Error status. Either zero on success, or an error if a request fails. Set
-      by drivers prior to completing a request via
-      crypto_done().

-  
crp_flags

-  
A bitmask of flags.

-  
crp_cipher_key

-  
Pointer to a request-specific encryption key. If this value is not set,
-      the request uses the session encryption key.

-  
crp_auth_key

-  
Pointer to a request-specific authentication key. If this value is not
-      set, the request uses the session authentication key.

-  
crp_opaque

-  
An opaque pointer. This pointer permits users of the cryptographic
-      framework to store information about a request to be used in the
-    callback.

-  
crp_callback

-  
Callback function. This must point to a callback function of type
-      void (*)(struct cryptop *). The callback function
-      should inspect crp_etype to determine the status of
-      the completed operation. It should also arrange for the request to be
-      freed via crypto_freereq().

-  
crp_olen

-  
Used with compression and decompression requests to describe the updated
-      length of the payload region in the data buffer.
-    
If a compression request increases the size of the payload,
-        then the data buffer is unmodified, the request completes successfully,
-        and crp_olen is set to the size the compressed
-        data would have used. Callers can compare this to the payload region
-        length to determine if the compressed data was discarded.

-  

-

-

-

-

-

-
crypto_dispatch() returns an error if the
-    request contained invalid fields, or zero if the request was valid.
-    crypto_getreq() returns a pointer to a new request
-    structure on success, or NULL on failure.
-    NULL can only be returned if
-    M_NOWAIT was passed in
-  how.

-

-

-

-
ipsec(4), crypto(7),
-    crypto(9), crypto_session(9),
-    mbuf(9), uio(9)

-

-

-

-
Not all drivers properly handle mixing session and per-request
-    keys within a single session. Consumers should either use a single key for a
-    session specified in the session parameters or always use per-request
-  keys.

-

-

-
-  
-    
-    
-  
-
May 8, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/crypto_session.9 3.html b/static/freebsd/man9/crypto_session.9 3.html
deleted file mode 100644
index dab25818..00000000
--- a/static/freebsd/man9/crypto_session.9 3.html	
+++ /dev/null
@@ -1,230 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRYPTO_SESSION(9)Kernel Developer's ManualCRYPTO_SESSION(9)

-

-

-

-
crypto_session —
-    state used for symmetric cryptographic services

-

-

-

-
#include
-    <opencrypto/cryptodev.h>

-
struct auth_hash *
-  

-  crypto_auth_hash(const
-    struct crypto_session_params *csp);

-
struct enc_xform *
-  

-  crypto_cipher(const
-    struct crypto_session_params *csp);

-
const struct crypto_session_params *
-  

-  crypto_get_params(crypto_session_t
-    cses);

-
int
-  

-  crypto_newsession(crypto_session_t
-    *cses, const struct crypto_session_params *csp,
-    int crid);

-
int
-  

-  crypto_freesession(crypto_session_t
-    cses);

-

-

-

-
Symmetric cryptographic operations in the kernel are associated
-    with cryptographic sessions. Sessions hold state shared across multiple
-    requests. Active sessions are associated with a single cryptographic
-  driver.

-
The crypto_session_t type represents an
-    opaque reference to an active session. Session objects are allocated and
-    managed by the cryptographic framework.

-
New sessions are created by
-    ().
-    csp describes various parameters associated with the
-    new session such as the algorithms to use and any session-wide keys.
-    crid can be used to request either a specific
-    cryptographic driver or classes of drivers. For the latter case,
-    crid should be set to a mask of the following
-  values:

-

-  

-  
Request hardware drivers. Hardware drivers do not use the host CPU to
-      perform operations. Typically, a separate co-processor performs the
-      operations asynchronously.

-  

-  
Request software drivers. Software drivers use the host CPU to perform
-      operations. The kernel includes a simple, yet portable implementation of
-      each supported algorithm in the cryptosoft(4) driver.
-      Additional software drivers may also be available on architectures which
-      provide instructions designed to accelerate cryptographic operations.

-

-
If both hardware and software drivers are requested, hardware
-    drivers are preferred over software drivers. Accelerated software drivers
-    are preferred over the baseline software driver. If multiple hardware
-    drivers are available, the framework will distribute sessions across these
-    drivers in a round-robin fashion.

-
On success,
-    ()
-    saves a reference to the newly created session in
-    cses.

-
()
-    is used to free the resources associated with the session
-    cses.

-
()
-    returns a structure describing the baseline software implementation of an
-    authentication algorithm requested by csp. If
-    csp does not specify an authentication algorithm, or
-    requests an invalid algorithm, NULL is returned.

-
()
-    returns a structure describing the baseline software implementation of an
-    encryption algorithm requested by csp. If
-    csp does not specify an encryption algorithm, or
-    requests an invalid algorithm, NULL is returned.

-
()
-    returns a pointer to the session parameters used by
-    cses.

-

-

-
Session parameters are used to describe the cryptographic
-    operations performed by cryptographic requests. Parameters are stored in an
-    instance of struct crypto_session_params. When
-    initializing parameters to pass to
-    crypto_newsession(), the entire structure should
-    first be zeroed. Needed fields should then be set leaving unused fields as
-    zero. This structure contains the following fields:

-

-  
csp_mode

-  
Type of operation to perform. This field must be set to one of the
-      following:
-    

-      

-      
Compress or decompress request payload.
-        
The compression algorithm is specified in
-            csp_cipher_alg.

-      

-      

-      
Encrypt or decrypt request payload.
-        
The encryption algorithm is specified in
-            csp_cipher_alg.

-      

-      

-      
Compute or verify a digest, or hash, of request payload.
-        
The authentication algorithm is specified in
-            csp_auth_alg.

-      

-      

-      
Authenticated encryption with additional data. Decryption operations
-          require the digest, or tag, and fail if it does not match.
-        
The AEAD algorithm is specified in
-            csp_cipher_alg.

-      

-      

-      
Encrypt-then-Authenticate. In this mode, encryption operations encrypt
-          the payload and then compute an authentication digest over the request
-          additional authentication data followed by the encrypted payload.
-          Decryption operations fail without decrypting the data if the provided
-          digest does not match.
-        
The encryption algorithm is specified in
-            csp_cipher_alg and the authentication
-            algorithm is specified in csp_auth_alg.

-      

-    

-  

-  
csp_flags

-  
A mask of optional driver features. Drivers will only attach to a session
-      if they support all of the requested features.
-    

-      

-      
Support requests that use separate input and output buffers. Sessions
-          with this flag set permit requests with either a single buffer that is
-          modified in-place, or requests with separate input and output buffers.
-          Sessions without this flag only permit requests with a single buffer
-          that is modified in-place.

-      

-      
Support requests that use a separate buffer for AAD rather than
-          providing AAD as a region in the input buffer. Sessions with this flag
-          set permit requests with AAD passed in either in a region of the input
-          buffer or in a single, virtually-contiguous buffer. Sessions without
-          this flag only permit requests with AAD passed in as a region in the
-          input buffer.

-      

-      
Support requests that use a separate buffer for IPsec ESN (Extended
-          Sequence Numbers).
-        
Sessions with this flag set permit requests with IPsec ESN
-            passed in special buffer. It is required for IPsec ESN support of
-            encrypt and authenticate mode where the high-order 32 bits of the
-            sequence number are appended after the Next Header (RFC 4303).

-      

-    

-  

-  
csp_ivlen

-  
If either the cipher or authentication algorithms require an explicit
-      initialization vector (IV) or nonce, this specifies the length in bytes.
-      All requests for a session use the same IV length.

-  
csp_cipher_alg

-  
Encryption or compression algorithm.

-  
csp_cipher_klen

-  
Length of encryption or decryption key in bytes. All requests for a
-      session use the same key length.

-  
csp_cipher_key

-  
Pointer to encryption or decryption key. If all requests for a session use
-      request-specific keys, this field should be left as
-      NULL. This pointer and associated key must remain
-      valid for the duration of the crypto session.

-  
csp_auth_alg

-  
Authentication algorithm.

-  
csp_auth_klen

-  
Length of authentication key in bytes. If the authentication algorithm
-      does not use a key, this field should be left as zero.

-  
csp_auth_key

-  
Pointer to the authentication key. If all requests for a session use
-      request-specific keys, this field should be left as
-      NULL. This pointer and associated key must remain
-      valid for the duration of the crypto session.

-  
csp_auth_mlen

-  
The length in bytes of the digest. If zero, the full length of the digest
-      is used. If non-zero, the first csp_auth_mlen bytes
-      of the digest are used.

-

-

-

-

-

-
crypto_newsession() returns a non-zero
-    value if an error occurs or zero on success.

-
crypto_auth_hash() and
-    crypto_cipher() return NULL
-    if the request is valid or a pointer to a structure on success.

-

-

-

-
crypto(7), crypto(9),
-    crypto_request(9)

-

-

-

-
The current implementation of
-    crypto_freesession does not provide a way for the
-    caller to know that there are no other references to the keys stored in the
-    session's associated parameters. This function should probably sleep until
-    any in-flight cryptographic operations associated with the session are
-    completed.

-

-

-
-  
-    
-    
-  
-
June 22, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/deadfs.9 4.html b/static/freebsd/man9/deadfs.9 4.html
deleted file mode 100644
index c28a1858..00000000
--- a/static/freebsd/man9/deadfs.9 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEADFS(9)Kernel Developer's ManualDEADFS(9)

-

-

-

-
deadfs —
-    pseudo-filesystem to own reclaimed vnodes

-

-

-

-
The deadfs file system implements
-    operations that do not modify any data and instead return indications of
-    invalid IO. Its role is to provide a fallback vnode operations vector for
-    reclaimed vnode(9)'s.

-
It is a kernel-only pseudo-file system and so cannot be mounted
-    from userspace.

-

-

-

-
insmntque(9), vnode(9),
-    VOP_RECLAIM(9)

-

-

-

-
UNIX System Manager's Manual (SMM) for
-    4.4BSD described deadfs as a
-    file system “where rejected vnodes go to die”.

-

-

-

-
The deadfs manual page was written by
-    Mateusz Piotrowski
-    <0mp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 24, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/dev_clone.9 4.html b/static/freebsd/man9/dev_clone.9 4.html
deleted file mode 100644
index f978b0e0..00000000
--- a/static/freebsd/man9/dev_clone.9 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEV_CLONE(9)Kernel Developer's ManualDEV_CLONE(9)

-

-

-

-
dev_clone,
-    drain_dev_clone_events —
-    eventhandler for name-based device cloning in
-  devfs

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/conf.h>

-
void
-  

-  clone_handler(void
-    *arg, struct ucred
-    *cr, char *name,
-    int namelen,
-    struct cdev **dev);

-

-
EVENTHANDLER_REGISTER(dev_clone, clone_handler, arg, priority);

-

-

-void
-

-drain_dev_clone_events();
-

-

-

-
A device driver may register a listener that will be notified each
-    time a name lookup on the devfs(4) mount point fails to
-    find the vnode. A listener shall be registered for the
-    dev_clone event. When called, it is supplied with the
-    first argument arg that was specified at handler
-    registration time, appropriate credentials cr, and a
-    name name of length namelen that
-    we look for. If the handler decides that the name is appropriate and wants
-    to create the device that will be associated with the name, it should return
-    it to devfs in the dev argument.

-
The
-    ()
-    function is a barrier. It is guaranteed that all calls to eventhandlers for
-    dev_clone that were started before
-    drain_dev_clone_events() call, are finished before
-    it returns control.

-

-

-

-
devfs(4), namei(9)

-

-

-
-  
-    
-    
-  
-
January 3, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/dev_refthread.9 3.html b/static/freebsd/man9/dev_refthread.9 3.html
deleted file mode 100644
index 9ca70fac..00000000
--- a/static/freebsd/man9/dev_refthread.9 3.html	
+++ /dev/null
@@ -1,125 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEV_REFTHREAD(9)Kernel Developer's ManualDEV_REFTHREAD(9)

-

-

-

-
dev_refthread,
-    devvn_refthread,
-    dev_relthread — safely
-    access device methods

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/conf.h>

-
struct cdevsw *
-  

-  dev_refthread(struct
-    cdev *dev, int
-    *ref);

-
struct cdevsw *
-  

-  devvn_refthread(struct
-    vnode *vp, struct cdev
-    **devp, int
-  *ref);

-
void
-  

-  dev_relthread(struct
-    cdev *dev, int
-    ref);

-

-

-

-
The
-    ()
-    (or devvn_refthread()) and
-    dev_relthread() routines provide a safe way to
-    access devfs(4) devices that may be concurrently destroyed
-    by
-    ()
-    (e.g., removable media).

-
If successful,
-    ()
-    and devvn_refthread() acquire a "thread
-    reference" to the associated struct cdev and
-    return a non-NULL pointer to the cdev's struct cdevsw
-    method table. For the duration of that reference, the cdev's associated
-    private data and method table object are valid. Destruction of the cdev
-    sleeps until the thread reference is released.

-
A reference cannot prevent media removal. It
-    is an implementation detail of individual drivers how method calls from
-    callers with
-    ()
-    references are handled when the device is pending destruction. A common
-    behavior for disk devices is to return the ENXIO
-    status, but that is not required by this KPI.

-
The
-    ()
-    variant of dev_refthread() extracts the
-    struct cdev pointer out of the
-    VCHR vnode(9) automatically before
-    performing the same actions as dev_refthread().
-    Additionally, a pointer to the struct cdev is returned
-    to the caller via *devp.
-    devvn_refthread() correctly handles possible
-    parallel reclamation of the vnode.

-
()
-    is used to release a reference to a struct cdev.
-    dev_relthread()
-     only
-    be invoked when the associated invocation of
-    dev_refthread() or
-    devvn_refthread() returned a non-NULL
-    struct cdevsw *.

-

-

-

-
struct cdev objects have two reference
-    counts, si_refcount and
-    si_threadcount. The
-    dev_refthread(),
-    devvn_refthread(), and
-    dev_relthread() functions manipulate the
-    si_threadcount. The
-    si_threadcount reference guarantees the liveness of
-    the struct cdev object. The other
-    si_refcount reference provides only the weaker
-    guarantee that the memory backing the struct cdev has
-    not been freed.

-

-

-

-
If dev_refthread() or
-    devvn_refthread() are unsuccessful, they return
-    NULL.

-
If these routines are unsuccessful, they do not increment the
-  struct cdev si_threadcount and do
-  not initialize the value pointed to by the *ref
-  parameter in any way.

-

-

-

-
devfs(4), destroy_dev(9)

-

-

-

-
Do not invoke dev_relthread() unless the
-    matching refthread routine succeeded!

-

-

-
-  
-    
-    
-  
-
August 29, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass.9 4.html b/static/freebsd/man9/devclass.9 4.html
deleted file mode 100644
index 499a6ffc..00000000
--- a/static/freebsd/man9/devclass.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS(9)Kernel Developer's ManualDEVCLASS(9)

-

-

-

-
devclass — object
-    representing a class of devices

-

-

-

-
typedef struct devclass *devclass_t;

-

-

-

-
The devclass object has two main functions
-    in the system. The first is to manage the allocation of unit numbers for
-    device instances and the second is to hold the list of device drivers for a
-    particular bus type. Each devclass has a name and
-    there cannot be two devclasses with the same name. This ensures that unique
-    unit numbers are allocated to device instances. All instances with the same
-    name are treated as being the same.

-
When no specific unit number is needed,
-    DEVICE_UNIT_ANY is used.

-

-

-

-
devclass_add_driver(9),
-    devclass_delete_driver(9),
-    devclass_find(9),
-    devclass_find_driver(9),
-    devclass_get_device(9),
-    devclass_get_devices(9),
-    devclass_get_maxunit(9),
-    devclass_get_name(9),
-    devclass_get_softc(9), device(9),
-    driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_find.9 4.html b/static/freebsd/man9/devclass_find.9 4.html
deleted file mode 100644
index 79af0683..00000000
--- a/static/freebsd/man9/devclass_find.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_FIND(9)Kernel Developer's ManualDEVCLASS_FIND(9)

-

-

-

-
devclass_find —
-    search for a devclass

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
devclass_t
-  

-  devclass_find(const
-    char *classname);

-

-

-

-
Search for the devclass with the specified
-    name.

-

-

-

-
If the devclass exists, it is returned,
-    otherwise NULL is returned.

-

-

-

-
devclass(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_count.9 4.html b/static/freebsd/man9/devclass_get_count.9 4.html
deleted file mode 100644
index 44df7de9..00000000
--- a/static/freebsd/man9/devclass_get_count.9 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_COUNT(9)Kernel Developer's ManualDEVCLASS_GET_COUNT(9)

-

-

-

-
devclass_get_count —
-    get the number of devices in a devclass

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  devclass_get_count(devclass_t
-    dc);

-

-

-

-
Returns the number of device instances in the specified
-    devclass.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Nate
-    Lawson.

-

-

-
-  
-    
-    
-  
-
December 5, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_device.9 4.html b/static/freebsd/man9/devclass_get_device.9 4.html
deleted file mode 100644
index f788b688..00000000
--- a/static/freebsd/man9/devclass_get_device.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_DEVICE(9)Kernel Developer's ManualDEVCLASS_GET_DEVICE(9)

-

-

-

-
devclass_get_device —
-    translate unit number to device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
device_t
-  

-  devclass_get_device(devclass_t
-    dc, int unit);

-

-

-

-
This function retrieves the device instance with the given unit
-    number and returns it.

-

-

-

-
If the device exists, it is returned, otherwise NULL is
-  returned.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_devices.9 4.html b/static/freebsd/man9/devclass_get_devices.9 4.html
deleted file mode 100644
index 41814f66..00000000
--- a/static/freebsd/man9/devclass_get_devices.9 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_DEVICES(9)Kernel Developer's ManualDEVCLASS_GET_DEVICES(9)

-

-

-

-
devclass_get_devices —
-    get a list of devices in a devclass

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  devclass_get_devices(devclass_t
-    dc, device_t
-    **devlistp, int
-    *devcountp);

-

-

-

-
Retrieve a list of all device instances currently in the devclass
-    and return the list in *devlistp and the count in
-    *devcountp. The memory allocated for the list should
-    be freed using
-    (*devlistp,
-    M_TEMP), even if *devcountp is
-    0.

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
May 19, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_drivers.9 4.html b/static/freebsd/man9/devclass_get_drivers.9 4.html
deleted file mode 100644
index 9a741184..00000000
--- a/static/freebsd/man9/devclass_get_drivers.9 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_DRIVERS(9)Kernel Developer's ManualDEVCLASS_GET_DRIVERS(9)

-

-

-

-
devclass_get_drivers —
-    get a list of drivers in a devclass

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  devclass_get_drivers(devclass_t
-    dc, driver_t
-    ***listp, int
-    *countp);

-

-

-

-
Retrieve a list of pointers to all driver instances currently in
-    the devclass and return the list in *listp and the
-    number of drivers in the list in *countp. The memory
-    allocated for the list should be freed using
-    (*listp,
-    M_TEMP), even if *countp is
-  0.

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Nate
-    Lawson.

-

-

-
-  
-    
-    
-  
-
May 19, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_maxunit.9 4.html b/static/freebsd/man9/devclass_get_maxunit.9 4.html
deleted file mode 100644
index 7e43b64a..00000000
--- a/static/freebsd/man9/devclass_get_maxunit.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_MAXUNIT(9)Kernel Developer's ManualDEVCLASS_GET_MAXUNIT(9)

-

-

-

-
devclass_get_maxunit —
-    find the maximum unit number in the class

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  devclass_get_maxunit(devclass_t
-    dc);

-

-

-

-
Returns the next unit number to be allocated to device instances
-    in the devclass. This is one greater than the
-    highest currently allocated unit.

-

-

-

-
The devclass_get_maxunit() function
-    returns -1 if dc is NULL,
-    otherwise it returns the next unit number in dc's
-    devclass.

-

-

-

-
None.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-

-
The name is confusing since it is one greater than the maximum
-    unit.

-

-

-
-  
-    
-    
-  
-
September 10, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_name.9 4.html b/static/freebsd/man9/devclass_get_name.9 4.html
deleted file mode 100644
index 5b16d87f..00000000
--- a/static/freebsd/man9/devclass_get_name.9 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_NAME(9)Kernel Developer's ManualDEVCLASS_GET_NAME(9)

-

-

-

-
devclass_get_name —
-    access the name of a devclass

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
const char *
-  

-  devclass_get_name(devclass_t
-    dc);

-

-

-

-
Return the name of a devclass.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/devclass_get_softc.9 4.html b/static/freebsd/man9/devclass_get_softc.9 4.html
deleted file mode 100644
index 16f2e427..00000000
--- a/static/freebsd/man9/devclass_get_softc.9 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCLASS_GET_SOFTC(9)Kernel Developer's ManualDEVCLASS_GET_SOFTC(9)

-

-

-

-
devclass_get_softc —
-    translate unit number to driver private
-  structure

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void *
-  

-  devclass_get_softc(devclass_t
-    dc, int unit);

-

-

-

-
This function retrieves the driver private instance variables for
-    the device with the given unit number and returns it.

-

-

-

-
If the device exists, its driver-private variables are returned,
-    otherwise NULL is returned.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/devctl_notify.9 4.html b/static/freebsd/man9/devctl_notify.9 4.html
deleted file mode 100644
index 71ee56ba..00000000
--- a/static/freebsd/man9/devctl_notify.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCTL_NOTIFY(9)Kernel Developer's ManualDEVCTL_NOTIFY(9)

-

-

-

-
devctl_notify —
-    Send a message, via devctl, to userland

-

-

-

-
#include
-    <sys/devctl.h>

-
void
-  

-  devctl_notify(const
-    char *system, const char
-    *subsystem, const char
-    *type, const char
-    *data);

-

-

-

-
Send a notification to user land via devctl(4).
-    See devctl(4) for the format of these messages.

-
The devctl_notify function creates a
-    string using the following template:

-

-
snprintf(buffer, sizeof(buffer), "!system=%s subsystem=%s type=%s",
-   system, subsystem, type);

-

-
The system, subsystem,
-    and type pointers cannot be NULL.

-
The data argument may be NULL (for no
-    additions) or a message formatted properly for devctl(4).
-    A space will be added to the above template and this argument copied
-    verbatim to form the message passed to userland. Senders should balance
-    between only passing data that userland can not discover itself and sending
-    all the data userland will want to use to decide what to do with the
-    message.

-
The current total message length limit is just under 1kb. Senders
-    should try to remain well below this limit.

-

-

-

-
devctl(4), devd(8)

-

-

-

-
This manual page was written by M. Warner
-    Losh

-

-

-
-  
-    
-    
-  
-
September 22, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/devctl_process_running.9 4.html b/static/freebsd/man9/devctl_process_running.9 4.html
deleted file mode 100644
index 3c3afc28..00000000
--- a/static/freebsd/man9/devctl_process_running.9 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCTL_PROCESS_RUNNING(9)Kernel Developer's ManualDEVCTL_PROCESS_RUNNING(9)

-

-

-

-
devctl_process_running —
-    Returns true when devctl has a consumer process
-    running

-

-

-

-
#include
-    <sys/devctl.h>

-
bool
-  

-  devctl_process_running(void);

-

-

-

-
The devctl_process_running call returns
-    true when a process has the devctl device open for
-    reading, and false otherwise. One can assume from this
-    that the default devd(8) or similar is running when
-    true is returned. Some subsystems will send a message
-    and allow userland to do something before proceeding with a default action
-    if there's a timeout. This call allows those subsystems to do the default
-    action right away when no process is running.

-

-

-

-
devd(8)

-

-

-

-
This manual page was written by M. Warner
-    Losh

-

-

-
-  
-    
-    
-  
-
September 22, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/devctl_safe_quote_sb.9 4.html b/static/freebsd/man9/devctl_safe_quote_sb.9 4.html
deleted file mode 100644
index d83d4a27..00000000
--- a/static/freebsd/man9/devctl_safe_quote_sb.9 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVCTL_SAFE_QUOTE_SB(9)Kernel Developer's ManualDEVCTL_SAFE_QUOTE_SB(9)

-

-

-

-
devctl_safe_quote_sb —
-    Insert a string, properly quoted, into a sbuf

-

-

-

-
#include
-    <sys/devctl.h>
-  

-  #include <sys/sbuf.h>

-
void
-  

-  devctl_safe_quote_sb(struct
-    sbuf *sb, const char
-    *src);

-

-

-

-
Copy the string from src into
-    sb. All backslash characters are doubled. All double
-    quote characters ‘"’ are also preceded by a backslash.
-    All other characters are copied without modification. The
-    devctl(4) protocol requires quoted string to be quoted
-    thus. This routine centralizes this knowledge.

-

-

-

-
devd(8)

-

-

-

-
This manual page was written by M. Warner
-    Losh

-

-

-
-  
-    
-    
-  
-
September 22, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/devfs_set_cdevpriv.9 3.html b/static/freebsd/man9/devfs_set_cdevpriv.9 3.html
deleted file mode 100644
index 46f226bb..00000000
--- a/static/freebsd/man9/devfs_set_cdevpriv.9 3.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVFS_CDEVPRIV(9)Kernel Developer's ManualDEVFS_CDEVPRIV(9)

-

-

-

-
devfs_set_cdevpriv,
-    devfs_get_cdevpriv,
-    devfs_clear_cdevpriv,
-    devfs_foreach_cdevpriv —
-    manage per-open filedescriptor data for devices

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/conf.h>

-

-
typedef	void d_priv_dtor_t(void *data);

-

-

-int
-

-devfs_get_cdevpriv(void
-  **datap);
-
int
-  

-  devfs_set_cdevpriv(void
-    *priv, d_priv_dtor_t
-    *dtr);

-
void
-  

-  devfs_clear_cdevpriv(void);

-
int
-  

-  devfs_foreach_cdevpriv(struct cdev
-    *dev, int (*cb)(void *data, void *arg),
-    void *arg);

-

-

-

-
The
-    ()
-    family of functions allows the cdev driver methods to
-    associate some driver-specific data with each user process
-    open(2) of the device special file. Currently, functioning
-    of these functions is restricted to the context of the
-    cdevsw switch method calls performed as
-    devfs(4) operations in response to system calls that use
-    filedescriptors.

-
The
-    ()
-    function associates a data pointed by priv with
-    current calling context (filedescriptor). The data may be retrieved later,
-    possibly from another call performed on this filedescriptor, by the
-    devfs_get_cdevpriv() function. The
-    devfs_clear_cdevpriv() disassociates previously
-    attached data from context. Immediately after
-    devfs_clear_cdevpriv() finished operating, the
-    dtr callback is called, with private data supplied
-    data argument. The
-    devfs_clear_cdevpriv() function will be also be
-    called if the open callback function returns an error code.

-
On the last filedescriptor close, system
-    automatically arranges
-    ()
-    call.

-
If successful, the functions return 0.

-
The function
-    ()
-    returns the following values on error:

-

-  
[ENOENT]

-  
The current call is not associated with some filedescriptor.

-  
[EBUSY]

-  
The private driver data is already associated with current
-    filedescriptor.

-

-
The function
-    ()
-    returns the following values on error:

-

-  
[EBADF]

-  
The current call is not associated with some filedescriptor.

-  
[ENOENT]

-  
The private driver data was not associated with current filedescriptor, or
-      devfs_clear_cdevpriv() was called.

-

-
The function
-    ()
-    sequentially calls the function cb for each
-    cdevpriv structure, currently associated with the
-    cdev device. The iterated
-    cdevpriv data pointer and the user-supplied context
-    arg are passed to the function
-    cb. If cb returns non-zero
-    value, the iteration stops on that element. The
-    devfs_foreach_cdevpriv() returns the return value
-    from the last call to cb, or zero if no
-    cdevpriv data is currently associated with the
-    device.

-
Current implementation of the iterator makes it impossible to use
-    any blockable locking inside the callback cb.

-

-

-

-
close(2), open(2),
-    devfs(4)

-

-

-

-
The devfs_cdevpriv() family of functions
-    first appeared in FreeBSD 7.1.

-

-

-
-  
-    
-    
-  
-
March 23, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/device.9 3.html b/static/freebsd/man9/device.9 3.html
deleted file mode 100644
index 44abf9ea..00000000
--- a/static/freebsd/man9/device.9 3.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE(9)Kernel Developer's ManualDEVICE(9)

-

-

-

-
device — an
-    abstract representation of a device

-

-

-

-
typedef struct _device *device_t;

-

-

-

-
The device object represents a piece of hardware attached to the
-    system such as an expansion card, the bus which that card is plugged into,
-    disk drives attached to the expansion card etc. The system defines one
-    device, root_bus and all other devices are created
-    dynamically during autoconfiguration. Normally devices representing
-    top-level buses in the system (ISA, PCI etc.) will be attached directly to
-    root_bus and other devices will be added as children
-    of their relevant bus.

-
The devices in a system form a tree. All devices except
-    root_bus have a parent (see
-    device_get_parent(9)). In addition, any device can have
-    children attached to it (see device_add_child(9),
-    device_add_child_ordered(9),
-    device_find_child(9),
-    device_get_children(9), and
-    device_delete_child(9)).

-
A device which has been successfully probed and attached to the
-    system will also have a driver (see device_get_driver(9)
-    and driver(9)) and a devclass (see
-    device_get_devclass(9) and devclass(9)).
-    Various other attributes of the device include a unit number (see
-    device_get_unit(9)), verbose description (normally
-    supplied by the driver, see device_set_desc(9) and
-    device_get_desc(9)), a set of bus-specific variables (see
-    device_get_ivars(9)) and a set of driver-specific
-    variables (see device_get_softc(9)).

-
Devices can be in one of several states:

-

-  

-  
the device has not been probed for existence or the probe failed

-  

-  
the device probe succeeded but not yet attached

-  

-  
the device has been successfully attached

-  

-  
the device is currently open

-

-
The current state of the device can be determined by calling
-    device_get_state(9).

-

-

-

-
devclass(9), driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 15, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/device_add_child.9 3.html b/static/freebsd/man9/device_add_child.9 3.html
deleted file mode 100644
index c61595dd..00000000
--- a/static/freebsd/man9/device_add_child.9 3.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_ADD_CHILD(9)Kernel Developer's ManualDEVICE_ADD_CHILD(9)

-

-

-

-
device_add_child,
-    device_add_child_ordered —
-    add a new device as a child of an existing
-  device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
device_t
-  

-  device_add_child(device_t
-    dev, const char
-    *name, int
-  unit);

-
device_t
-  

-  device_add_child_ordered(device_t
-    dev, int order,
-    const char *name,
-    int unit);

-

-

-

-
Create a new child device of dev. The
-    name and unit arguments specify
-    the name and unit number of the device. If the name is unknown then the
-    caller should pass NULL. If the unit is unknown then
-    the caller should pass DEVICE_UNIT_ANY and the
-    system will choose the next available unit number.

-
The name of the device is used to determine which drivers might be
-    appropriate for the device. If a name is specified then only drivers of that
-    name are probed. If no name is given then all drivers for the owning bus are
-    probed. In any event, only the name of the device is stored so that one may
-    safely unload/load a driver bound to that name.

-
This allows buses which can uniquely identify device instances
-    (such as PCI) to allow each driver to check each device instance for a
-    match. For buses which rely on supplied probe hints where only one driver
-    can have a chance of probing the device, the driver name should be specified
-    as the device name.

-
Normally unit numbers will be chosen automatically by the system
-    and a unit number of DEVICE_UNIT_ANY should be
-    given. When a specific unit number is desired (e.g., for wiring a particular
-    piece of hardware to a pre-configured unit number), that unit should be
-    passed. If the specified unit number is already allocated, a new unit will
-    be allocated and a diagnostic message printed.

-
If the devices attached to a bus
-    must be probed in a specific order (e.g., for the ISA bus some devices are
-    sensitive to failed probe attempts of unrelated drivers and therefore must
-    be probed first), the order argument of
-    ()
-    should be used to specify a partial ordering. The new device will be added
-    before any existing device with a greater order. If
-    device_add_child() is used, then the new child will
-    be added as if its order was zero.

-
When adding a device in the context of
-    DEVICE_IDENTIFY(9) routine, the
-    device_find_child(9) routine should be used to ensure that
-    the device has not already been added to the tree. Because the device name
-    and devclass_t are associated at probe time (not child
-    addition time), previous instances of the driver (say in a module that was
-    later unloaded) may have already added the instance. Authors of bus drivers
-    must likewise be careful when adding children when they are loaded and
-    unloaded to avoid duplication of children devices.

-
When adding a child to another device node,
-    such as in an identify routine, use BUS_ADD_CHILD(9)
-    instead of
-    ().
-    BUS_ADD_CHILD(9) will call
-    device_add_child() and add the proper bus-specific
-    data to the new child. device_add_child() does not
-    call BUS_ADD_CHILD(9).

-

-

-

-
The new device if successful, NULL otherwise.

-

-

-

-
BUS_ADD_CHILD(9), device(9),
-    device_delete_child(9),
-    device_find_child(9),
-  DEVICE_IDENTIFY(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 11, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/device_delete_child.9 4.html b/static/freebsd/man9/device_delete_child.9 4.html
deleted file mode 100644
index f17d2680..00000000
--- a/static/freebsd/man9/device_delete_child.9 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_DELETE_CHILD(9)Kernel Developer's ManualDEVICE_DELETE_CHILD(9)

-

-

-

-
device_delete_child —
-    delete a child from a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  device_delete_child(device_t
-    dev, device_t
-    child);

-

-

-

-
The specified device is removed from dev and
-    deleted. If the device is currently attached, it is first detached via
-    device_detach(9). If
-    ()
-    fails, its error value is returned. Otherwise, all descendant devices of
-    child are deleted and zero is returned.

-
The BUS_CHILD_DELETED(9) method is invoked for
-    each device that is deleted. This permits the parent device's driver to tear
-    down any state associated with child devices such as ivars.

-

-

-

-
Zero is returned on success, otherwise an error is returned.

-

-

-

-
BUS_CHILD_DELETED(9),
-    device_add_child(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/device_delete_children.9 4.html b/static/freebsd/man9/device_delete_children.9 4.html
deleted file mode 100644
index b5589441..00000000
--- a/static/freebsd/man9/device_delete_children.9 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_DELETE_CHILDREN(9)Kernel Developer's ManualDEVICE_DELETE_CHILDREN(9)

-

-

-

-
device_delete_children —
-    delete all child devices of a given device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  device_delete_children(device_t
-    dev);

-

-

-

-
The
-    ()
-    function deletes all child devices of the given device
-    dev, if any, using the
-    ()
-    function for each device it finds. If a child device cannot be deleted, this
-    function will return an error code.

-

-

-

-
Zero is returned on success, a non-zero return value indicates
-    failure.

-

-

-

-
device_delete_child(9)

-

-

-

-
This manual page was written by Jeroen Ruigrok
-    van der Werven.

-

-

-
-  
-    
-    
-  
-
September 28, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/device_enable.9 4.html b/static/freebsd/man9/device_enable.9 4.html
deleted file mode 100644
index 9a6ed988..00000000
--- a/static/freebsd/man9/device_enable.9 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_ENABLE(9)Kernel Developer's ManualDEVICE_ENABLE(9)

-

-

-

-
device_enable,
-    device_disable,
-    device_is_enabled —
-    manipulate device enabled flag

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  device_enable(device_t
-    dev);

-
void
-  

-  device_disable(device_t
-    dev);

-
int
-  

-  device_is_enabled(device_t
-    dev);

-

-

-

-
Each device has an enabled flag associated with it. A device is
-    enabled by default when it is created but may be disabled (for instance to
-    prevent a destructive or time consuming probe attempt). To disable a device,
-    call
-    (),
-    to re-enable it, call
-    ()
-    and to test to see if a device is enabled, call
-    ().

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/device_find_child.9 4.html b/static/freebsd/man9/device_find_child.9 4.html
deleted file mode 100644
index 53f1c4c3..00000000
--- a/static/freebsd/man9/device_find_child.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_FIND_CHILD(9)Kernel Developer's ManualDEVICE_FIND_CHILD(9)

-

-

-

-
device_find_child —
-    search for a child of a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
device_t
-  

-  device_find_child(device_t
-    dev, const char
-    *classname, int
-    unit);

-

-

-

-
This function looks for a specific child of
-    dev with the given classname
-    and unit. If unit is -1, it
-    returns the first child of dev with a matching
-    classname (that is, the one with the lowest unit).

-

-

-

-
If it exists, the child device is returned, otherwise NULL.

-

-

-

-
device_add_child(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 8, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_children.9 3.html b/static/freebsd/man9/device_get_children.9 3.html
deleted file mode 100644
index 9857e468..00000000
--- a/static/freebsd/man9/device_get_children.9 3.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_CHILDREN(9)Kernel Developer's ManualDEVICE_GET_CHILDREN(9)

-

-

-

-
device_get_children,
-    device_has_children —
-    examine devices connected to a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  device_get_children(device_t
-    dev, device_t
-    **devlistp, int
-    *devcountp);

-
bool
-  

-  device_has_children(device_t
-    dev);

-

-

-

-
The device_get_children function retrieves
-    a list of all device instances currently connected to
-    dev. It returns the list in
-    *devlistp and the count in
-    *devcountp. The memory allocated for the list should
-    be freed using
-    (*devlistp,
-    M_TEMP). devlistp and
-    devcountp are not changed when an error is
-  returned.

-
As a special case, if devlistp is null, no
-    memory is allocated but the count is still returned in
-    *devcountp.

-
The device_has_children function returns
-    true if dev has at least one
-    child and false if it has none.

-

-

-

-
The device_get_children function returns
-    zero on success and an appropriate error otherwise. The
-    device_has_children function returns true if the
-    specified device has at least one child and false otherwise.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson
-    <dfr@FreeBSD.org> and
-    Dag-Erling Smørgrav
-    <des@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 28, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_devclass.9 4.html b/static/freebsd/man9/device_get_devclass.9 4.html
deleted file mode 100644
index 7a654926..00000000
--- a/static/freebsd/man9/device_get_devclass.9 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_DEVCLASS(9)Kernel Developer's ManualDEVICE_GET_DEVCLASS(9)

-

-

-

-
device_get_devclass —
-    access the devclass of a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
devclass_t
-  

-  device_get_devclass(device_t
-    dev);

-

-

-

-
The current devclass associated with the device is returned. If
-    the device has no devclass, NULL is returned.

-

-

-

-
devclass(9), device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_driver.9 4.html b/static/freebsd/man9/device_get_driver.9 4.html
deleted file mode 100644
index 9bcf091b..00000000
--- a/static/freebsd/man9/device_get_driver.9 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_DRIVER(9)Kernel Developer's ManualDEVICE_GET_DRIVER(9)

-

-

-

-
device_get_driver —
-    access the current driver of a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
driver_t *
-  

-  device_get_driver(device_t
-    dev);

-

-

-

-
The current driver associated with the device is returned. If the
-    device has no driver, NULL is returned.

-

-

-

-
device(9), driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_ivars.9 4.html b/static/freebsd/man9/device_get_ivars.9 4.html
deleted file mode 100644
index dc8500ab..00000000
--- a/static/freebsd/man9/device_get_ivars.9 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_IVARS(9)Kernel Developer's ManualDEVICE_GET_IVARS(9)

-

-

-

-
device_get_ivars,
-    device_set_ivars — access
-    bus private variables

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void *
-  

-  device_get_ivars(device_t
-    dev);

-
void
-  

-  device_set_ivars(device_t
-    dev, void
-  *ivar);

-

-

-

-
The
-    ()
-    function returns the bus-specific instance variables of a device.

-
The
-    ()
-    function sets the bus-specific instance variables of a device.

-
Typically, only bus drivers will use these functions. The kernel
-    assumes that the bus driver will manage this memory, and no automatic memory
-    allocation or deallocation happens. Client drivers should access ivars
-    through the BUS_READ_IVAR(9) interface instead.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_name.9 4.html b/static/freebsd/man9/device_get_name.9 4.html
deleted file mode 100644
index d0a137cd..00000000
--- a/static/freebsd/man9/device_get_name.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_NAME(9)Kernel Developer's ManualDEVICE_GET_NAME(9)

-

-

-

-
device_get_name,
-    device_get_nameunit — access
-    the name of a device's device class or instance

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
const char *
-  

-  device_get_name(device_t
-    dev);

-
const char *
-  

-  device_get_nameunit(device_t
-    dev);

-

-

-

-
The
-    ()
-    function returns the name of the device's device class.

-
The
-    ()
-    function returns the name of the device's instance.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Warner
-    Losh.

-

-

-
-  
-    
-    
-  
-
April 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_parent.9 4.html b/static/freebsd/man9/device_get_parent.9 4.html
deleted file mode 100644
index e2f9ca4d..00000000
--- a/static/freebsd/man9/device_get_parent.9 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_PARENT(9)Kernel Developer's ManualDEVICE_GET_PARENT(9)

-

-

-

-
device_get_parent —
-    return the device's parent

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
device_t
-  

-  device_get_parent(device_t
-    dev);

-

-

-

-
The
-    ()
-    function returns the name of the device's parent device.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Warner
-    Losh.

-

-

-
-  
-    
-    
-  
-
April 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_property.9 3.html b/static/freebsd/man9/device_get_property.9 3.html
deleted file mode 100644
index 33387eef..00000000
--- a/static/freebsd/man9/device_get_property.9 3.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_PROPERTY(9)Kernel Developer's ManualDEVICE_GET_PROPERTY(9)

-

-

-

-
device_get_property,
-    device_has_property — access
-    device specific data

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
ssize_t
-  

-  device_get_property(device_t
-    dev, const char
-    *prop, void *val,
-    size_t sz,
-    device_property_type_t
-    type);

-
bool
-  

-  device_has_property(device_t
-    dev, const char
-    *prop);

-

-

-

-
Access device specific data provided by the parent bus. Drivers
-    can use these properties to obtain device capabilities and set necessary
-    quirks.

-
The underlying property type is specified with the
-    type argument. Currently the following types are
-    supported:

-

-  

-  
The underlying property is a string of bytes.

-  

-  
Wildcard property type.

-  

-  
Following a reference the underlying property is a handle of the
-      respective bus.

-  

-  
The underlying property is an array of unsigned 32 bit integers. The
-      sz argument shall be a multiple of 4.

-  

-  
The underlying property is an array of unsigned 64 bit integers. The
-      sz argument shall be a multiple of 8.

-

-

-

-

-
You can pass NULL as pointer to property's value when calling
-    ()
-    to obtain its size.

-
Currently this interface is implemented by
-    simplebus(4) and acpi(4).

-

-

-

-
device_get_property() if successful
-    returns property's size, otherwise returns -1.

-
device_has_property() returns true if
-    given property was found.

-

-

-

-
acpi(4), simplebus(4),
-    device(9)

-

-

-

-
This manual page was written by Bartlomiej
-    Grzesik.

-

-

-
-  
-    
-    
-  
-
September 29, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_softc.9 4.html b/static/freebsd/man9/device_get_softc.9 4.html
deleted file mode 100644
index 6fb8a6d9..00000000
--- a/static/freebsd/man9/device_get_softc.9 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_SOFTC(9)Kernel Developer's ManualDEVICE_GET_SOFTC(9)

-

-

-

-
device_get_softc —
-    access driver private instance variables

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void *
-  

-  device_get_softc(device_t
-    dev);

-

-

-

-
Return the driver-specific software context of
-    dev. The softc is automatically allocated and zeroed
-    when the device is attached. The softc is also initialized and present when
-    a device is probed, but is subject to caveats as described in
-    DEVICE_PROBE(9). The size of the allocation is determined
-    by the device's driver_t information used to define
-    the driver. The softc typically encapsulates the state of this instance of
-    the device.

-
Driver writers are discouraged from using their own softc
-    management mechanisms. Driver writers should not copy such mechanisms found
-    in drivers in the tree that predate this function.

-

-

-

-
The pointer to the driver-specific instance variable is
-  returned.

-

-

-

-
device(9), DEVICE_PROBE(9),
-    device_set_softc(9), driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 21, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_state.9 3.html b/static/freebsd/man9/device_get_state.9 3.html
deleted file mode 100644
index f430ef69..00000000
--- a/static/freebsd/man9/device_get_state.9 3.html	
+++ /dev/null
@@ -1,90 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_STATE(9)Kernel Developer's ManualDEVICE_GET_STATE(9)

-

-

-

-
device_get_state,
-    device_busy, device_unbusy,
-    device_is_alive,
-    device_is_attached —
-    manipulate device state

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
device_state_t
-  

-  device_get_state(device_t
-    dev);

-
void
-  

-  device_busy(device_t
-    dev);

-
void
-  

-  device_unbusy(device_t
-    dev);

-
int
-  

-  device_is_alive(device_t
-    dev);

-
int
-  

-  device_is_attached(device_t
-    dev);

-

-

-

-
The current state of a device is accessed by calling
-    ()
-    which returns DS_NOTPRESENT,
-    DS_ALIVE, DS_ATTACHED or
-    DS_BUSY (described in device(9)).
-    To test see if a device was successfully probed, call
-    ()
-    which simply returns if the state is greater or equal to
-    DS_ALIVE. To test see if a device was successfully
-    attached, call
-    ()
-    which simply returns if the state is greater or equal to
-    DS_ATTACHED.

-
Each device has a busy count which is incremented
-    when
-    ()
-    is called and decremented when
-    ()
-    is called. Both routines return an error if the device state is less than
-    DS_ATTACHED.

-
When
-    ()
-    is called on a device in the DS_ATTACHED state, the
-    device changes to the DS_BUSY state. When
-    ()
-    is called and after decrementing, the busy count for the device is zero, the
-    device changes to the DS_ATTACHED state.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_sysctl.9 4.html b/static/freebsd/man9/device_get_sysctl.9 4.html
deleted file mode 100644
index 71297d92..00000000
--- a/static/freebsd/man9/device_get_sysctl.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_SYSCTL(9)Kernel Developer's ManualDEVICE_GET_SYSCTL(9)

-

-

-

-
device_get_sysctl_ctx,
-    device_get_sysctl_tree —
-    manipulate the sysctl oid tree for driver specific sysctl
-    nodes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
struct sysctl_ctx_list *
-  

-  device_get_sysctl_ctx(device_t
-    dev);

-
struct sysctl_oid *
-  

-  device_get_sysctl_tree(device_t
-    dev);

-

-

-

-
The newbus system automatically adds a sysctl node for each device
-    in the system. This node can be accessed with the
-    ()
-    function. The context for the node can be obtained with the
-    ()
-    function.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Warner
-    Losh.

-

-

-
-  
-    
-    
-  
-
June 18, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/device_get_unit.9 4.html b/static/freebsd/man9/device_get_unit.9 4.html
deleted file mode 100644
index 3d3584dc..00000000
--- a/static/freebsd/man9/device_get_unit.9 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_UNIT(9)Kernel Developer's ManualDEVICE_GET_UNIT(9)

-

-

-

-
device_get_unit —
-    access the unit number of a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  device_get_unit(device_t
-    dev);

-

-

-

-
Return the unit number of the device.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
June 16, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/device_printf.9 4.html b/static/freebsd/man9/device_printf.9 4.html
deleted file mode 100644
index 7e50e808..00000000
--- a/static/freebsd/man9/device_printf.9 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_PRINTF(9)Kernel Developer's ManualDEVICE_PRINTF(9)

-

-

-

-
device_printf —
-    formatted output conversion

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  device_printf(device_t
-    dev, const char
-    *fmt, ...);

-

-

-

-
The
-    ()
-    function is a convenience interface to the printf(9)
-    function. It outputs the name of the dev device,
-    followed by a colon and a space, and then what printf(9)
-    would print if you passed fmt and the remaining
-    arguments to it.

-

-

-

-
The device_printf() function returns the
-    number of characters displayed.

-

-

-

-
printf(3), printf(9)

-

-

-
-  
-    
-    
-  
-
April 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/device_probe_and_attach.9 3.html b/static/freebsd/man9/device_probe_and_attach.9 3.html
deleted file mode 100644
index 0e2c80a0..00000000
--- a/static/freebsd/man9/device_probe_and_attach.9 3.html	
+++ /dev/null
@@ -1,117 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_PROBE_AND_ATTACH(9)Kernel Developer's ManualDEVICE_PROBE_AND_ATTACH(9)

-

-

-

-
device_attach,
-    device_detach, device_probe,
-    device_probe_and_attach —
-    manage device's connection to a device driver

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  device_attach(device_t
-    dev);

-
int
-  

-  device_detach(device_t
-    dev);

-
int
-  

-  device_probe(device_t
-    dev);

-
int
-  

-  device_probe_and_attach(device_t
-    dev);

-

-

-

-
These functions manage the relationship between a device and
-    device drivers.

-
()
-    invokes the DEVICE_PROBE(9) method of each suitable driver
-    and to find the driver with the best match for dev. If
-    a matching driver is found, dev is set to the
-    DS_ALIVE state and zero is returned. If
-    dev is already attached to a device driver or has been
-    disabled via device_disable(9), then it will not be probed
-    and -1 is returned.

-
()
-    fully attaches a device driver to dev. This function
-    prints a description of the device and invokes the
-    DEVICE_ATTACH(9) method. If the
-    DEVICE_ATTACH(9) method succeeds,
-    dev is set to the DS_ATTACHED
-    state and zero is returned. If the DEVICE_ATTACH(9) method
-    fails, BUS_CHILD_DETACHED(9) is called and an error value
-    is returned.

-
If the device name and unit are disabled by a
-    hint,
-    ()
-    disables the device, demotes it to the DS_NOTPRESENT
-    state, and returns ENXIO. The device retains its
-    device name and unit and can be re-enabled via
-  devctl(8).

-
()
-    is a wrapper function around device_probe() and
-    device_attach() that fully initialises a device. If
-    dev is already attached or disabled,
-    device_probe_and_attach() leaves the device
-    unchanged and returns zero. Otherwise,
-    device_probe() is used to identify a device driver
-    for dev and device_attach()
-    finalizes attaching the driver to dev. Device drivers
-    should generally use this function to initialize a device rather than direct
-    calls to device_probe() and
-    device_attach().

-
()
-    detaches the device driver from dev. This function
-    invokes the DEVICE_DETACH(9) method to tear down device
-    driver state for dev. If the method fails, its error
-    value is returned and dev remains attached. If the
-    method succeeds, otherwise, BUS_CHILD_DETACHED(9) is
-    called, the device is set to the DS_NOTPRESENT
-    state, and zero is returned. If a device is busy,
-    device_detach() fails with
-    EBUSY and leaving dev
-    unchanged.

-

-

-

-
Zero is returned on success, otherwise an appropriate error is
-    returned. In addition, device_probe() returns -1 if
-    dev is disabled or already attached.

-

-

-

-
devctl(8),
-    BUS_CHILD_DETACHED(9), device(9),
-    DEVICE_ATTACH(9), DEVICE_DETACH(9),
-    DEVICE_PROBE(9), driver(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
February 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/device_quiet.9 4.html b/static/freebsd/man9/device_quiet.9 4.html
deleted file mode 100644
index fc00d092..00000000
--- a/static/freebsd/man9/device_quiet.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_QUIET(9)Kernel Developer's ManualDEVICE_QUIET(9)

-

-

-

-
device_quiet,
-    device_verbose,
-    device_is_quiet — manipulate
-    device quiet flag

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  device_quiet(device_t
-    dev);

-
void
-  

-  device_verbose(device_t
-    dev);

-
int
-  

-  device_is_quiet(device_t
-    dev);

-

-

-

-
Each device has a quiet flag associated with it. A device is
-    verbose by default when it is created but may be quieted to prevent printing
-    of the device identification string during attach and printing of a message
-    during detach. To quiet a device, call
-    ()
-    during a device driver probe routine. To re-enable probe messages, call
-    ().
-    To test to see if a device is quieted, call
-    ().

-
Devices are implicitly marked verbose after a driver detaches.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
September 12, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/device_set_desc.9 4.html b/static/freebsd/man9/device_set_desc.9 4.html
deleted file mode 100644
index 01aa7a3d..00000000
--- a/static/freebsd/man9/device_set_desc.9 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_SET_DESC(9)Kernel Developer's ManualDEVICE_SET_DESC(9)

-

-

-

-
device_set_desc,
-    device_set_descf,
-    device_set_desc_copy,
-    device_get_desc — access the
-    description of a device

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  device_set_desc(device_t
-    dev, const char
-    *desc);

-
void
-  

-  device_set_descf(device_t
-    dev, const char
-    *fmt, ...);

-
void
-  

-  device_set_desc_copy(device_t
-    dev, const char
-    *desc);

-
const char *
-  

-  device_get_desc(device_t
-    dev);

-

-

-

-
Manipulate the verbose description of a device. This description
-    (if present) is printed as part of the message when it is attached during
-    autoconfiguration. The variation
-    ()
-    is used to set the description if the string passed is a temporary buffer
-    which will be overwritten. In this case, the system will copy the string,
-    otherwise the pointer passed will be used directly.
-    ()
-    is a printf-like version of
-    ().

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 9, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/device_set_driver.9 4.html b/static/freebsd/man9/device_set_driver.9 4.html
deleted file mode 100644
index 5de2faec..00000000
--- a/static/freebsd/man9/device_set_driver.9 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_SET_DRIVER(9)Kernel Developer's ManualDEVICE_SET_DRIVER(9)

-

-

-

-
device_set_driver —
-    associate a specific driver with a device node in the
-    tree

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  device_set_driver(device_t
-    dev, driver_t
-    *driver);

-

-

-

-
This function associates a specific driver with a given device
-    node in the tree. It is typically used in
-    DEVICE_IDENTIFY(9) functions to add devices to a bus that
-    does not support doing so automatically, such as the ISA bus.

-

-

-

-
device(9)

-

-

-

-
This manual page was written by M. Warner
-    Losh.

-

-

-
-  
-    
-    
-  
-
April 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/device_set_flags.9 4.html b/static/freebsd/man9/device_set_flags.9 4.html
deleted file mode 100644
index deb0683c..00000000
--- a/static/freebsd/man9/device_set_flags.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVICE_GET_FLAGS(9)Kernel Developer's ManualDEVICE_GET_FLAGS(9)

-

-

-

-
device_set_flags,
-    device_get_flags —
-    manipulate driver flags

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
void
-  

-  device_set_flags(device_t
-    dev, uint32_t
-    flags);

-
uint32_t
-  

-  device_get_flags(device_t
-    dev);

-

-

-

-
Each device supports a set of driver-dependent flags which are
-    often used to control device behaviour. These flags are read by calling
-    ()
-    and written by calling
-    ().

-

-

-

-
device(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
September 6, 1999FreeBSD 15.0

diff --git a/static/freebsd/man9/devstat.9 3.html b/static/freebsd/man9/devstat.9 3.html
deleted file mode 100644
index 4c185552..00000000
--- a/static/freebsd/man9/devstat.9 3.html	
+++ /dev/null
@@ -1,401 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVSTAT(9)Kernel Developer's ManualDEVSTAT(9)

-

-

-

-
devstat,
-    devstat_end_transaction,
-    devstat_end_transaction_bio,
-    devstat_end_transaction_bio_bt,
-    devstat_new_entry,
-    devstat_remove_entry,
-    devstat_start_transaction,
-    devstat_start_transaction_bio —
-    kernel interface for keeping device statistics

-

-

-

-
#include
-    <sys/devicestat.h>

-
struct devstat *
-  

-  devstat_new_entry(const void
-    *dev_name, int unit_number,
-    uint32_t block_size,
-    devstat_support_flags flags,
-    devstat_type_flags device_type,
-    devstat_priority priority);

-
void
-  

-  devstat_remove_entry(struct
-    devstat *ds);

-
void
-  

-  devstat_start_transaction(struct
-    devstat *ds, const struct bintime *now);

-
void
-  

-  devstat_start_transaction_bio(struct
-    devstat *ds, struct bio *bp);

-
void
-  

-  devstat_end_transaction(struct devstat
-    *ds, uint32_t bytes,
-    devstat_tag_type tag_type,
-    devstat_trans_flags flags, const
-    struct bintime *now, const struct bintime
-    *then);

-
void
-  

-  devstat_end_transaction_bio(struct
-    devstat *ds, const struct bio *bp);

-
void
-  

-  devstat_end_transaction_bio_bt(struct
-    devstat *ds, const struct bio *bp,
-    const struct bintime *now);

-

-

-

-
The devstat subsystem is an interface for recording device
-    statistics, as its name implies. The idea is to keep reasonably detailed
-    statistics while utilizing a minimum amount of CPU time to record them.
-    Thus, no statistical calculations are actually performed in the kernel
-    portion of the devstat code. Instead, that is left
-    for user programs to handle.

-
The historical and antiquated devstat
-    model assumed a single active IO operation per device, which is not accurate
-    for most disk-like drivers in the 2000s and beyond. New consumers of the
-    interface should almost certainly use only the "bio" variants of
-    the start and end transacation routines.

-
()
-    allocates and initializes devstat structure and
-    returns a pointer to it. devstat_new_entry() takes
-    several arguments:

-

-  
dev_name

-  
The device name, e.g., da, cd, sa.

-  
unit_number

-  
Device unit number.

-  
block_size

-  
Block size of the device, if supported. If the device does not support a
-      block size, or if the blocksize is unknown at the time the device is added
-      to the devstat list, it should be set to 0.

-  
flags

-  
Flags indicating operations supported or not supported by the device. See
-      below for details.

-  
device_type

-  
The device type. This is broken into three sections: base device type
-      (e.g., direct access, CDROM, sequential access), interface type (IDE, SCSI
-      or other) and a pass-through flag to indicate pas-through devices. See
-      below for a complete list of types.

-  
priority

-  
The device priority. The priority is used to determine how devices are
-      sorted within devstat's list of devices. Devices
-      are sorted first by priority (highest to lowest), and then by attach
-      order. See below for a complete list of available priorities.

-

-
()
-    removes a device from the devstat subsystem. It
-    takes the devstat structure for the device in question as an argument. The
-    devstat generation number is incremented and the
-    number of devices is decremented.

-
()
-    registers the start of a transaction with the
-    devstat subsystem. Optionally, if the caller already
-    has a binuptime() value available, it may be passed
-    in *now. Usually the caller can just pass
-    NULL for now, and the routine
-    will gather the current binuptime() itself. The busy
-    count is incremented with each transaction start. When a device goes from
-    idle to busy, the system uptime is recorded in the
-    busy_from field of the devstat
-    structure.

-
()
-    records the binuptime() in the provided bio's
-    bio_t0 and then invokes
-    devstat_start_transaction().

-
()
-    registers the end of a transaction with the devstat
-    subsystem. It takes six arguments:

-

-  
ds

-  
The devstat structure for the device in
-    question.

-  
bytes

-  
The number of bytes transferred in this transaction.

-  
tag_type

-  
Transaction tag type. See below for tag types.

-  
flags

-  
Transaction flags indicating whether the transaction was a read, write, or
-      whether no data was transferred.

-  
now

-  
The binuptime() at the end of the transaction, or
-      NULL.

-  
then

-  
The binuptime() at the beginning of the
-      transaction, or NULL.

-

-
If now is
-    NULL, it collects the current time from
-    ().
-    If then is NULL, the operation
-    is not tracked in the devstat
-    duration table.

-
()
-    is a thin wrapper for
-    devstat_end_transaction_bio_bt() with a
-    NULL now parameter.

-
()
-    is a wrapper for devstat_end_transaction() which
-    pulls all needed information from a struct bio
-    prepared by devstat_start_transaction_bio(). The bio
-    must be ready for
-    ()
-    (i.e., bio_bcount and bio_resid
-    must be correctly initialized).

-
The devstat structure is composed of the
-    following fields:

-

-  
sequence0,

-  
 

-  
sequence1

-  
An implementation detail used to gather consistent snapshots of device
-      statistics.

-  
start_count

-  
Number of operations started.

-  
end_count

-  
Number of operations completed. The “busy_count” can be
-      calculated by subtracting end_count from
-      start_count. (sequence0 and
-      sequence1 are used to get a consistent snapshot.)
-      This is the current number of outstanding transactions for the device.
-      This should never go below zero, and on an idle device it should be zero.
-      If either one of these conditions is not true, it indicates a problem.
-    
There should be one and only one transaction start event and
-        one transaction end event for each transaction.

-  

-  
dev_links

-  
Each devstat structure is placed in a linked list
-      when it is registered. The dev_links field contains
-      a pointer to the next entry in the list of devstat
-      structures.

-  
device_number

-  
The device number is a unique identifier for each device. The device
-      number is incremented for each new device that is registered. The device
-      number is currently only a 32-bit integer, but it could be enlarged if
-      someone has a system with more than four billion device arrival
-    events.

-  
device_name

-  
The device name is a text string given by the registering driver to
-      identify itself. (e.g., “da”, “cd”,
-      “sa”, etc.)

-  
unit_number

-  
The unit number identifies the particular instance of the peripheral
-      driver in question.

-  
bytes[4]

-  
This array contains the number of bytes that have been read (index
-      DEVSTAT_READ), written (index
-      DEVSTAT_WRITE), freed or erased (index
-      DEVSTAT_FREE), or other (index
-      DEVSTAT_NO_DATA). All values are unsigned 64-bit
-      integers.

-  
operations[4]

-  
This array contains the number of operations of a given type that have
-      been performed. The indices are identical to those for
-      bytes above. DEVSTAT_NO_DATA
-      or "other" represents the number of transactions to the device
-      which are neither reads, writes, nor frees. For instance, SCSI drivers
-      often send a test unit ready command to SCSI devices. The test unit ready
-      command does not read or write any data. It merely causes the device to
-      return its status.

-  
duration[4]

-  
This array contains the total bintime corresponding to completed
-      operations of a given type. The indices are identical to those for
-      bytes above. (Operations that complete using the
-      historical
-      ()
-      API and do not provide a non-NULL then are not
-      accounted for.)

-  
busy_time

-  
This is the amount of time that the device busy count has been greater
-      than zero. This is only updated when the busy count returns to zero.

-  
creation_time

-  
This is the time, as reported by
-      ()
-      that the device was registered.

-  
block_size

-  
This is the block size of the device, if the device has a block size.

-  
tag_types

-  
This is an array of counters to record the number of various tag types
-      that are sent to a device. See below for a list of tag types.

-  
busy_from

-  
If the device is not busy, this was the time that a transaction last
-      completed. If the device is busy, this the most recent of either the time
-      that the device became busy, or the time that the last transaction
-      completed.

-  
flags

-  
These flags indicate which statistics measurements are supported by a
-      particular device. These flags are primarily intended to serve as an aid
-      to userland programs that decipher the statistics.

-  
device_type

-  
This is the device type. It consists of three parts: the device type
-      (e.g., direct access, CDROM, sequential access, etc.), the interface (IDE,
-      SCSI or other) and whether or not the device in question is a pass-through
-      driver. See below for a complete list of device types.

-  
priority

-  
This is the priority. This is the first parameter used to determine where
-      to insert a device in the devstat list. The second
-      parameter is attach order. See below for a list of available
-    priorities.

-  
id

-  
Identification for GEOM nodes.

-

-
Each device is given a device type. Pass-through devices have the
-    same underlying device type and interface as the device they provide an
-    interface for, but they also have the pass-through flag set. The base device
-    types are identical to the SCSI device type numbers, so with SCSI
-    peripherals, the device type returned from an inquiry is usually ORed with
-    the SCSI interface type and the pass-through flag if appropriate. The device
-    type flags are as follows:

-

-
typedef enum {
-	DEVSTAT_TYPE_DIRECT	= 0x000,
-	DEVSTAT_TYPE_SEQUENTIAL	= 0x001,
-	DEVSTAT_TYPE_PRINTER	= 0x002,
-	DEVSTAT_TYPE_PROCESSOR	= 0x003,
-	DEVSTAT_TYPE_WORM	= 0x004,
-	DEVSTAT_TYPE_CDROM	= 0x005,
-	DEVSTAT_TYPE_SCANNER	= 0x006,
-	DEVSTAT_TYPE_OPTICAL	= 0x007,
-	DEVSTAT_TYPE_CHANGER	= 0x008,
-	DEVSTAT_TYPE_COMM	= 0x009,
-	DEVSTAT_TYPE_ASC0	= 0x00a,
-	DEVSTAT_TYPE_ASC1	= 0x00b,
-	DEVSTAT_TYPE_STORARRAY	= 0x00c,
-	DEVSTAT_TYPE_ENCLOSURE	= 0x00d,
-	DEVSTAT_TYPE_FLOPPY	= 0x00e,
-	DEVSTAT_TYPE_MASK	= 0x00f,
-	DEVSTAT_TYPE_IF_SCSI	= 0x010,
-	DEVSTAT_TYPE_IF_IDE	= 0x020,
-	DEVSTAT_TYPE_IF_OTHER	= 0x030,
-	DEVSTAT_TYPE_IF_NVME	= 0x040,
-	DEVSTAT_TYPE_IF_MASK	= 0x0f0,
-	DEVSTAT_TYPE_PASS	= 0x100
-} devstat_type_flags;

-

-
Devices have a priority associated with them, which controls
-    roughly where they are placed in the devstat list.
-    The priorities are as follows:

-

-
typedef enum {
-	DEVSTAT_PRIORITY_MIN	= 0x000,
-	DEVSTAT_PRIORITY_OTHER	= 0x020,
-	DEVSTAT_PRIORITY_PASS	= 0x030,
-	DEVSTAT_PRIORITY_FD	= 0x040,
-	DEVSTAT_PRIORITY_WFD	= 0x050,
-	DEVSTAT_PRIORITY_TAPE	= 0x060,
-	DEVSTAT_PRIORITY_CD	= 0x090,
-	DEVSTAT_PRIORITY_DISK	= 0x110,
-	DEVSTAT_PRIORITY_ARRAY	= 0x120,
-	DEVSTAT_PRIORITY_MAX	= 0xfff
-} devstat_priority;

-

-
Each device has associated with it flags to indicate what
-    operations are supported or not supported. The
-    devstat_support_flags values are as follows:

-

-  
DEVSTAT_ALL_SUPPORTED

-  
Every statistic type is supported by the device.

-  
DEVSTAT_NO_BLOCKSIZE

-  
This device does not have a blocksize.

-  
DEVSTAT_NO_ORDERED_TAGS

-  
This device does not support ordered tags.

-  
DEVSTAT_BS_UNAVAILABLE

-  
This device supports a blocksize, but it is currently unavailable. This
-      flag is most often used with removable media drives.

-

-
Transactions to a device fall into
-    one of three categories, which are represented in the
-    flags passed into
-    ().
-    The transaction types are as follows:

-

-
typedef enum {
-	DEVSTAT_NO_DATA	= 0x00,
-	DEVSTAT_READ	= 0x01,
-	DEVSTAT_WRITE	= 0x02,
-	DEVSTAT_FREE	= 0x03
-} devstat_trans_flags;
-#define DEVSTAT_N_TRANS_FLAGS   4

-

-
DEVSTAT_NO_DATA is a type of transactions to the device which are
-    neither reads or writes. For instance, SCSI drivers often send a test unit
-    ready command to SCSI devices. The test unit ready command does not read or
-    write any data. It merely causes the device to return its status.

-
There are four possible values for
-    the tag_type argument to
-    ():

-

-  
DEVSTAT_TAG_SIMPLE

-  
The transaction had a simple tag.

-  
DEVSTAT_TAG_HEAD

-  
The transaction had a head of queue tag.

-  
DEVSTAT_TAG_ORDERED

-  
The transaction had an ordered tag.

-  
DEVSTAT_TAG_NONE

-  
The device does not support tags.

-

-
The tag type values correspond to
-    the lower four bits of the SCSI tag definitions. In CAM, for instance, the
-    tag_action from the CCB is ORed with 0xf to determine
-    the tag type to pass in to
-    ().

-
There is a macro, DEVSTAT_VERSION that is
-    defined in
-    <sys/devicestat.h>. This is
-    the current version of the devstat subsystem, and it
-    should be incremented each time a change is made that would require
-    recompilation of userland programs that access
-    devstat statistics. Userland programs use this
-    version, via the kern.devstat.version
-    sysctl variable to determine whether they are in
-    sync with the kernel devstat structures.

-

-

-

-
systat(1), devstat(3),
-    iostat(8), rpc.rstatd(8),
-    vmstat(8)

-

-

-

-
The devstat statistics system appeared in
-    FreeBSD 3.0.

-

-

-

-
Kenneth Merry
-    <ken@FreeBSD.org>

-

-

-

-
There may be a need for spl() protection
-    around some of the devstat list manipulation code to
-    ensure, for example, that the list of devices is not changed while someone
-    is fetching the kern.devstat.all
-    sysctl variable.

-

-

-
-  
-    
-    
-  
-
July 15, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/devtoname.9 4.html b/static/freebsd/man9/devtoname.9 4.html
deleted file mode 100644
index 53231f0a..00000000
--- a/static/freebsd/man9/devtoname.9 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
DEVTONAME(9)Kernel Developer's ManualDEVTONAME(9)

-

-

-

-
devtoname —
-    converts character device into a string indicating the
-    device name

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/conf.h>

-
const char *
-  

-  devtoname(struct
-    cdev *dev);

-

-

-

-
The
-    ()
-    function returns a pointer to the name of the device passed to it. The name
-    is whatever was set to it in
-    ().

-

-

-

-
The devtoname() interface first appeared
-    in FreeBSD 4.0

-

-

-
-  
-    
-    
-  
-
February 10, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/disk.9 3.html b/static/freebsd/man9/disk.9 3.html
deleted file mode 100644
index 6374b646..00000000
--- a/static/freebsd/man9/disk.9 3.html	
+++ /dev/null
@@ -1,258 +0,0 @@
-
-  
-    
-    
-    
-  
-
DISK(9)Kernel Developer's ManualDISK(9)

-

-

-

-
disk — kernel disk
-    storage API

-

-

-

-
#include
-    <geom/geom_disk.h>

-
struct disk *
-  

-  disk_alloc(void);

-
void
-  

-  disk_create(struct
-    disk *disk, int
-    version);

-
void
-  

-  disk_gone(struct
-    disk *disk);

-
void
-  

-  disk_destroy(struct
-    disk *disk);

-
int
-  

-  disk_resize(struct
-    disk *disk, int
-    flags);

-
void
-  

-  disk_add_alias(struct
-    disk *disk, const char
-    *alias);

-

-

-

-
The disk storage API permits kernel device drivers providing
-    access to disk-like storage devices to advertise the device to other kernel
-    components, including GEOM(4) and
-    devfs(4).

-
Each disk device is described by a struct
-    disk structure, which contains a variety of parameters for the disk
-    device, function pointers for various methods that may be performed on the
-    device, as well as private data storage for the device driver. In addition,
-    some fields are reserved for use by GEOM in managing access to the device
-    and its statistics.

-
GEOM has the ownership of struct
-    disk, and drivers must allocate storage for it with the
-    ()
-    function, fill in the fields and call disk_create()
-    when the device is ready to service requests.
-    ()
-    adds an alias for the disk and must be called before
-    disk_create(), but may be called multiple times. For
-    each alias added, a device node will be created with
-    make_dev_alias(9) in the same way primary device nodes are
-    created with make_dev(9) for d_name
-    and d_unit. Care should be taken to ensure that only
-    one driver creates aliases for any given name.
-    ()
-    can be called by the driver after modifying
-    d_mediasize to notify GEOM about the disk capacity
-    change. The flags field should be set to either
-    M_WAITOK, or M_NOWAIT. disk_gone() orphans all of
-    the providers associated with the drive, setting an error condition of ENXIO
-    in each one. In addition, it prevents a re-taste on last close for writing
-    if an error condition has been set in the provider. After calling
-    (),
-    the device driver is not allowed to access the contents of
-    struct disk anymore.

-
The
-    ()
-    function takes a second parameter, version, which must
-    always be passed DISK_VERSION. If GEOM detects that
-    the driver is compiled against an unsupported version, it will ignore the
-    device and print a warning on the console.

-

-

-
The following fields identify the disk device described by the
-    structure instance, and must be filled in prior to submitting the structure
-    to disk_create() and may not be subsequently
-    changed:

-

-  
u_int d_flags

-  
Optional flags indicating to the storage framework what optional features
-      or descriptions the storage device driver supports. Currently supported
-      flags are DISKFLAG_OPEN (maintained by storage
-      framework), DISKFLAG_CANDELETE (maintained by
-      device driver), and DISKFLAG_CANFLUSHCACHE
-      (maintained by device driver).

-  
const char * d_name

-  
Holds the name of the storage device class, e.g.,
-      “ahd”. This value typically uniquely
-      identifies a particular driver device, and must not conflict with devices
-      serviced by other device drivers.

-  
u_int d_unit

-  
Holds the instance of the storage device class, e.g.,
-      “4”. This namespace is managed by
-      the device driver, and assignment of unit numbers might be a property of
-      probe order, or in some cases topology. Together, the
-      d_name and d_unit values will
-      uniquely identify a disk storage device.

-

-

-

-

-
The following fields identify various disk device methods, if
-    implemented:

-

-  
disk_open_t * d_open

-  
Optional: invoked when the disk device is opened. If no method is
-      provided, open will always succeed.

-  
disk_close_t * d_close

-  
Optional: invoked when the disk device is closed. Although an error code
-      may be returned, the call should always terminate any state setup by the
-      corresponding open method call.

-  
disk_strategy_t *
-    d_strategy

-  
Mandatory: invoked when a new struct bio is to be
-      initiated on the disk device.

-  
disk_ioctl_t * d_ioctl

-  
Optional: invoked when an I/O control operation is initiated on the disk
-      device. Please note that for security reasons these operations should not
-      be able to affect other devices than the one on which they are
-    performed.

-  
dumper_t * d_dump

-  
Optional: if configured with dumpon(8), this function is
-      invoked from a very restricted system state after a kernel panic to record
-      a copy of the system RAM to the disk.

-  
disk_getattr_t *
-    d_getattr

-  
Optional: if this method is provided, it gives the disk driver the
-      opportunity to override the default GEOM response to BIO_GETATTR requests.
-      This function should return -1 if the attribute is not handled, 0 if the
-      attribute is handled, or an errno to be passed to
-      ().

-  
disk_gone_t *
-    d_gone

-  
Optional: if this method is provided, it will be called after
-      ()
-      is called, once GEOM has finished its cleanup process. Once this callback
-      is called, it is safe for the disk driver to free all of its resources, as
-      it will not be receiving further calls from GEOM.

-

-

-

-

-
The following fields identify the size and granularity of the disk
-    device. These fields must stay stable from return of the drivers open method
-    until the close method is called, but it is perfectly legal to modify them
-    in the open method before returning.

-

-  
u_int d_sectorsize

-  
The sector size of the disk device in bytes.

-  
off_t d_mediasize

-  
The size of the disk device in bytes.

-  
u_int d_maxsize

-  
The maximum supported size in bytes of an I/O request. Requests larger
-      than this size will be chopped up by GEOM.

-

-

-

-

-
These optional fields can provide extra information about the disk
-    device. Do not initialize these fields if the field/concept does not apply.
-    These fields must stay stable from return of the drivers open method until
-    the close method is called, but it is perfectly legal to modify them in the
-    open method before returning.

-

-  
u_int d_fwsectors,
-    u_int d_fwheads

-  
The number of sectors and heads advertised on the disk device by the
-      firmware or BIOS. These values are almost universally bogus, but on some
-      architectures necessary for the correct calculation of disk
-    partitioning.

-  
u_int d_stripeoffset,
-    u_int d_stripesize

-  
These two fields can be used to describe the width and location of natural
-      performance boundaries for most disk technologies. Please see
-      src/sys/geom/notes for details.

-  
char
-    d_ident[DISK_IDENT_SIZE]

-  
This field can and should be used to store disk's serial number if the
-      d_getattr method described above isn't implemented, or if it does not
-      support the GEOM::ident attribute.

-  
char
-    d_descr[DISK_IDENT_SIZE]

-  
This field can be used to store the disk vendor and product
-    description.

-  
uint16_t d_hba_vendor

-  
This field can be used to store the PCI vendor ID for the HBA connected to
-      the disk.

-  
uint16_t d_hba_device

-  
This field can be used to store the PCI device ID for the HBA connected to
-      the disk.

-  
uint16_t d_hba_subvendor

-  
This field can be used to store the PCI subvendor ID for the HBA connected
-      to the disk.

-  
uint16_t d_hba_subdevice

-  
This field can be used to store the PCI subdevice ID for the HBA connected
-      to the disk.

-

-

-

-

-
This field may be used by the device driver to store a pointer to
-    private data to implement the disk service.

-

-  
void * d_drv1

-  
Private data pointer. Typically used to store a pointer to the drivers
-      softc structure for this disk device.

-

-

-

-

-

-
devfs(4), GEOM(4)

-

-

-

-
The kernel disk storage API first appeared
-    in FreeBSD 4.9.

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-

-
Disk aliases are not a general purpose aliasing mechanism, but are
-    intended only to ease the transition from one name to another. They can be
-    used to ensure that nvd0 and nda0 are the same thing. They cannot be used to
-    implement the diskX concept from macOS.

-

-

-
-  
-    
-    
-  
-
April 30, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/dnv.9 3.html b/static/freebsd/man9/dnv.9 3.html
deleted file mode 100644
index 3e295eaf..00000000
--- a/static/freebsd/man9/dnv.9 3.html	
+++ /dev/null
@@ -1,153 +0,0 @@
-
-  
-    
-    
-    
-  
-
DNV(9)Kernel Developer's ManualDNV(9)

-

-

-

-
dnvlist_get,
-    dnvlist_take — API for
-    getting name/value pairs with a default value

-

-

-

-
Name/value pairs library (libnv, -lnv)

-

-

-

-
#include
-    <sys/dnv.h>

-
bool
-  

-  dnvlist_get_bool(const
-    nvlist_t *nvl, const char
-    *name, bool
-    defval);

-
uint64_t
-  

-  dnvlist_get_number(const
-    nvlist_t *nvl, const char
-    *name, uint64_t
-    defval);

-
char *
-  

-  dnvlist_get_string(const
-    nvlist_t *nvl, const char
-    *name, const char
-    *defval);

-
nvlist_t *
-  

-  dnvlist_get_nvlist(const
-    nvlist_t *nvl, const char
-    *name, nvlist_t
-    *defval);

-
int
-  

-  dnvlist_get_descriptor(const
-    nvlist_t *nvl, const char
-    *name, int
-  defval);

-
void *
-  

-  dnvlist_get_binary(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *sizep, void
-    *defval, size_t
-    defsize);

-
bool
-  

-  dnvlist_take_bool(const
-    nvlist_t *nvl, const char
-    *name, bool
-    defval);

-
uint64_t
-  

-  dnvlist_take_number(const
-    nvlist_t *nvl, const char
-    *name, uint64_t
-    defval);

-
char *
-  

-  dnvlist_take_string(const
-    nvlist_t *nvl, const char
-    *name, const char
-    *defval);

-
nvlist_t *
-  

-  dnvlist_take_nvlist(const
-    nvlist_t *nvl, const char
-    *name, nvlist_t
-    *defval);

-
int
-  

-  dnvlist_take_descriptor(const
-    nvlist_t *nvl, const char
-    *name, int
-  defval);

-
void *
-  

-  dnvlist_take_binary(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *sizep, void
-    *defval, size_t
-    defsize);

-

-

-

-
The libnv library permits easy management
-    of name/value pairs and can send and receive them over sockets. For more
-    information, see nv(9).

-
The dnvlist_get functions return the value
-    associated with name. If an element named
-    name does not exist, the function returns the value
-    provided in defval. Returned strings, nvlists,
-    descriptors, binaries, or arrays must not be modified by the user since they
-    still belong to the nvlist. If the nvlist is in an error state, attempts to
-    use any of these functions will cause the program to abort.

-
The dnvlist_take functions
-    return the value associated with name and removes the
-    associated element from nvl. If an element named
-    name does not exist, the value provided in
-    defval is returned. When the value is a string,
-    binary, or array value, the caller is responsible for freeing returned
-    memory with
-    (3).
-    When the value is an nvlist, the caller is responsible for destroying the
-    returned nvlist with
-    ().
-    When the value is a descriptor, the caller is responsible for closing the
-    returned descriptor with
-    (2).

-

-

-

-
close(2), free(3),
-    nv(9)

-

-

-

-
The dnv API appeared in
-    FreeBSD 11.0.

-

-

-

-
The dnv API was implemented by
-    Pawel Jakub Dawidek
-    <pawel@dawidek.net>
-    under sponsorship from the FreeBSD Foundation. This manual page was written
-    by Adam Starak
-    <starak.adam@gmail.com>

-

-

-
-  
-    
-    
-  
-
January 3, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/domain.9 3.html b/static/freebsd/man9/domain.9 3.html
deleted file mode 100644
index 70233fd5..00000000
--- a/static/freebsd/man9/domain.9 3.html	
+++ /dev/null
@@ -1,194 +0,0 @@
-
-  
-    
-    
-    
-  
-
DOMAIN(9)Kernel Developer's ManualDOMAIN(9)

-

-

-

-
domain, protosw
-    — programming interface for kernel socket
-    implementation

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/protosw.h>
-  

-  #include <sys/domain.h>

-
void
-  

-  domain_add(struct
-    domain *dom);

-
void
-  

-  domain_remove(struct
-    domain *dom);

-
void
-  

-  DOMAIN_SET(domain);

-
int
-  

-  protosw_register(struct
-    domain *dom, struct
-    protosw *pr);

-
int
-  

-  protosw_unregister(struct
-    protosw *pr);

-

-

-

-
The domain subsystem allows implementation
-    of communication protocols that are exposed to the userland via the
-    socket(2) API. When an application performs a
-    (domain,
-    type, protocol) syscall, the
-    kernel searches for a domain matching the
-    domain argument, then within this domain, searches for
-    a protocol matching type. If the third argument,
-    protocol, is not 0, that value
-    must also match. The structure found must implement certain methods, so that
-    socket(2) API works for this particular kind of a
-  socket.

-
A minimal domain structure implementing a
-    domain shall be initialized with sparse C99 initializer and has public
-    fields as follows:

-

-
struct domain {
-    /*
-     * Mandatory fields.
-     */
-    int	dom_family;	/* PF_xxx, first argument of socket(2) */
-    char	*dom_name;	/* text name of the domain */
-    u_int	dom_nprotosw;	/* length of dom_protosw[] */
-    /*
-     * Following methods are optional.
-     */
-    int	(*dom_probe)(void);			/* check for support */
-    struct rib_head *(*dom_rtattach)(uint32_t);	/* init route table */
-    void (*dom_rtdetach)(struct rib_head *);	/* clean up table */
-    void *(*dom_ifattach)(struct ifnet *);	/* interface attach */
-    void (*dom_ifdetach)(struct ifnet *, void *);/* & detach callbacks */
-    int	(*dom_ifmtu)(struct ifnet *);		/* mtu change */
-    /*
-     * Mandatory variable size array of pointers to protosw structs.
-     */
-    struct  protosw *dom_protosw[];
-};

-

-
Each domain contains the dom_protosw array
-    of protocol switch structures (struct protosw *), one
-    for each socket type supported. The array may have
-    NULL spacers for loadable protocols. Sparse C99
-    initializers shall be used to initialize protosw
-    structures. The structure has mandatory field pr_type
-    and mandatory pr_attach method. The rest of the
-    methods are optional, but a meaningful protocol should implement some.

-

-
struct protosw {
-    short	pr_type;	/* second argument of socket(2) */
-    short	pr_protocol;	/* third argument of socket(2) or 0 */
-    short	pr_flags;	/* see protosw.h */
-    pr_soreceive_t  *pr_soreceive;  /* recv(2) */
-    pr_rcvd_t       *pr_rcvd;       /* soreceive_generic() if PR_WANTRCV */
-    pr_sosend_t     *pr_sosend;     /* send(2) */
-    pr_send_t       *pr_send;       /* send(2) via sosend_generic() */
-    pr_ready_t      *pr_ready;      /* sendfile/ktls readyness */
-    pr_sopoll_t     *pr_sopoll;     /* poll(2) */
-    pr_attach_t     *pr_attach;     /* creation: socreate(), sonewconn() */
-    pr_detach_t     *pr_detach;     /* destruction: sofree() */
-    pr_connect_t    *pr_connect;    /* connect(2) */
-    pr_disconnect_t *pr_disconnect; /* sodisconnect() */
-    pr_close_t      *pr_close;      /* close(2) */
-    pr_shutdown_t   *pr_shutdown;   /* shutdown(2) */
-    pr_abort_t      *pr_abort;      /* abrupt tear down: soabort() */
-    pr_aio_queue_t  *pr_aio_queue;  /* aio(9) */
-    pr_bind_t       *pr_bind;       /* bind(2) */
-    pr_bindat_t     *pr_bindat;     /* bindat(2) */
-    pr_listen_t     *pr_listen;     /* listen(2) */
-    pr_accept_t     *pr_accept;     /* accept(2) */
-    pr_connectat_t  *pr_connectat;  /* connectat(2) */
-    pr_connect2_t   *pr_connect2;   /* socketpair(2) */
-    pr_control_t    *pr_control;    /* ioctl(2) */
-    pr_rcvoob_t     *pr_rcvoob;     /* soreceive_rcvoob() */
-    pr_ctloutput_t  *pr_ctloutput;  /* control output (from above) */
-    pr_peeraddr_t   *pr_peeraddr;   /* getpeername(2) */
-    pr_sockaddr_t   *pr_sockaddr;   /* getsockname(2) */
-    pr_sense_t      *pr_sense;      /* stat(2) */
-};

-

-
The following functions handle the registration of new domains and
-    protocols.

-
()
-    adds a new protocol domain to the system. In most cases
-    domain_add() is not called directly, instead
-    ()
-    is used, which is a wrapper around
-    ()
-    macro. If the new domain has defined a dom_probe
-    routine, it is called first in domain_add() to
-    determine if the domain should be supported on the current system. If the
-    probe routine returns a non-0 value, then the domain will not be added. Once
-    a domain is added it cannot be completely unloaded. This is because there is
-    no reference counting system in place to determine if there are any active
-    references from sockets within that domain. However, the experimental
-    ()
-    exists, and unloadable domains may be supported in the future.

-
()
-    dynamically adds a protocol to a domain, if the latter has an empty slot in
-    its dom_protosw. Dynamically added protocol can later
-    be unloaded with
-    ().

-

-

-

-
The domain_add() never fails, but it may
-    not add a domain if its dom_probe fails.

-
The protosw_register() function may fail
-    if:

-

-  
[EEXIST]

-  
A protocol with the same value of pr_type and
-      pr_protocol already exists in the domain.

-  
[ENOMEM]

-  
The domain doesn't have any NULL slots in its
-      dom_protosw.

-

-

-

-

-
socket(2), SYSINIT(9)

-

-

-

-
The domain subsystem first appeared in
-    4.3BSD as the part of the very first
-    socket(2) API implementation.

-
The domain subsystem and this manual page
-    were significantly rewritten in FreeBSD 14.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>
-    and
-  

-  Gleb Smirnoff
-    <glebius@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
September 14, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/domainset.9 3.html b/static/freebsd/man9/domainset.9 3.html
deleted file mode 100644
index cef5b340..00000000
--- a/static/freebsd/man9/domainset.9 3.html	
+++ /dev/null
@@ -1,160 +0,0 @@
-
-  
-    
-    
-    
-  
-
DOMAINSET(9)Kernel Developer's ManualDOMAINSET(9)

-

-

-

-
domainset(9) —
-    domainset functions and operation

-

-

-

-
#include
-    <sys/_domainset.h>
-  

-  #include <sys/domainset.h>

-

-
struct domainset {
-        domainset_t     ds_mask;
-        uint16_t        ds_policy;
-        domainid_t      ds_prefer;
-	...
-};

-

-

-  

-  struct domainset *
-  

-  DOMAINSET_FIXED(domain);

-
struct domainset *
-  

-  DOMAINSET_FT();

-
struct domainset *
-  

-  DOMAINSET_IL();

-
struct domainset *
-  

-  DOMAINSET_RR();

-
struct domainset *
-  

-  DOMAINSET_PREF(domain);

-
struct domainset *
-  

-  domainset_create(const
-    struct domainset *key);

-
int
-  

-  domainset_populate(struct
-    domainset *domain,
-    domainset_t *mask,
-    int policy,
-    size_t mask_size);

-
int
-  

-  sysctl_handle_domainset(SYSCTL_HANDLER_ARGS);

-

-

-

-
The domainset(9) API provides memory
-    domain allocation policy for NUMA machines. Each
-    domainset contains a bitmask of allowed domains, an
-    integer policy, and an optional preferred domain. Together, these specify a
-    search order for memory allocations as well as the ability to restrict
-    threads and objects to a subset of available memory domains for system
-    partitioning and resource management.

-
Every thread in the system and optionally every
-    vm_object_t, which is used to represent files and
-    other memory sources, has a reference to a struct
-    domainset. The domainset associated with the object is consulted first
-    and the system falls back to the thread policy if none exists.

-
The allocation policy has the following possible values:

-

-  

-  
Memory is allocated from each domain in the mask in a round-robin fashion.
-      This distributes bandwidth evenly among available domains. This policy can
-      specify a single domain for a fixed allocation.

-  

-  
Memory is allocated from the node that it is first accessed on. Allocation
-      falls back to round-robin if the current domain is not in the allowed set
-      or is out of memory. This policy optimizes for locality but may give
-      pessimal results if the memory is accessed from many CPUs that are not in
-      the local domain.

-  

-  
Memory is allocated from the node in the prefer
-      member. The preferred node must be set in the allowed mask. If the
-      preferred node is out of memory the allocation falls back to round-robin
-      among allowed sets.

-  

-  
Memory is allocated in a striped fashion with multiple pages allocated to
-      each domain in the set according to the offset within the object. The
-      strip width is object dependent and may be as large as a super-page (2MB
-      on amd64). This gives good distribution among memory domains while keeping
-      system efficiency higher and is preferential to round-robin for general
-      use.

-

-
The
-    (),
-    (),
-    (),
-    ()
-    and
-    ()
-    macros provide pointers to global pre-defined policies for use when the
-    desired policy is known at compile time.
-    DOMAINSET_FIXED() is a policy which only permits
-    allocations from the specified domain.
-    DOMAINSET_FT() is a policy which attempts to
-    allocate memory local to the current CPU, falling back to a round-robin
-    policy if the initial allocation fails.
-    DOMAINSET_IL() and
-    DOMAINSET_RR() provide round-robin selection among
-    all domains in the system, corresponding to the
-    DOMAINSET_POLICY_INTERLEAVE and
-    DOMAINSET_POLICY_ROUNDROBIN policies, respectively.
-    The DOMAINSET_PREF() policies attempt allocation
-    from the specified domain, but unlike
-    DOMAINSET_FIXED() will fall back to other domains to
-    satisfy the request. These policies should be used in preference to
-    DOMAINSET_FIXED() to avoid blocking indefinitely on
-    a M_WAITOK request.

-
The
-    ()
-    function takes a partially filled in domainset as a key and returns a valid
-    domainset or NULL. It is critical that consumers not use domainsets that
-    have not been returned by this function. domainset is
-    an immutable type that is shared among all matching keys and must not be
-    modified after return.

-
The
-    ()
-    function fills a domainset struct using a domain mask
-    and policy. It is used for validating and translating a domain mask and
-    policy into a domainset struct when creating a custom
-    domainset using domainset_create.

-
The
-    ()
-    function is provided as a convenience for modifying or viewing domainsets
-    that are not accessible via cpuset(2). It is intended for
-    use with sysctl(9).

-

-

-

-
cpuset(1), cpuset(2),
-    cpuset_setdomain(2), bitset(9)

-

-

-

-
<sys/domainset.h>
-    first appeared in FreeBSD 12.0.

-

-

-
-  
-    
-    
-  
-
June 24, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/dpcpu.9 4.html b/static/freebsd/man9/dpcpu.9 4.html
deleted file mode 100644
index bb0c8df8..00000000
--- a/static/freebsd/man9/dpcpu.9 4.html	
+++ /dev/null
@@ -1,160 +0,0 @@
-
-  
-    
-    
-    
-  
-
DPCPU(9)Kernel Developer's ManualDPCPU(9)

-

-

-

-
dpcpu — Kernel
-    Dynamic Per-CPU Memory Allocator

-

-

-

-
#include
-    <sys/pcpu.h>

-

-

-
DPCPU_DEFINE(type,
-    name);

-
DPCPU_DEFINE_STATIC(type,
-    name);

-
DPCPU_DECLARE(type,
-    name);

-

-

-

-
DPCPU_PTR(name);

-
DPCPU_GET(name);

-
DPCPU_SET(name,
-    value);

-

-

-

-
DPCPU_ID_PTR(cpu,
-    name);

-
DPCPU_ID_GET(cpu,
-    name);

-
DPCPU_ID_SET(cpu,
-    name,
-    value);

-

-

-

-

-
dpcpu instantiates one instance of a
-    global variable with each CPU in the system. Dynamically allocated per-CPU
-    variables are defined using
-    (),
-    which defines a variable of name name and type
-    type. Arbitrary C types may be used, including
-    structures and arrays. If no initialization is provided, then each per-CPU
-    instance of the variable will be zero-filled (i.e., as though allocated in
-    BSS):

-

-
DPCPU_DEFINE(int, foo_int);

-

-
Values may also be initialized statically with the definition,
-    causing each per-CPU instance to be initialized with the value:

-

-
DPCPU_DEFINE(int, foo_int) = 1;

-

-
Values that can be defined as
-    static must use
-    ():

-

-
DPCPU_DEFINE_STATIC(int, foo_int);

-

-
()
-    produces a declaration of the per-CPU variable suitable for use in header
-    files.

-
The current CPU's variable instance can be accessed via
-    DPCPU_PTR (which returns a pointer to the per-CPU
-    instance), DPCPU_GET (which retrieves the value of
-    the per-CPU instance), and DPCPU_SET (which sets the
-    value of the per-CPU instance).

-
Instances of variables associated with specific CPUs can be
-    accessed via the DPCPU_ID_PTR,
-    DPCPU_ID_GET, and
-    DPGPU_ID_SET accessor functions, which accept an
-    additional CPU ID argument, cpu.

-

-

-
In addition to the ordinary synchronization concerns associated
-    with global variables, which may imply the use of
-    atomic(9), mutex(9), or other kernel
-    synchronization primitives, it is further the case that thread migration
-    could dynamically change the instance of a variable being accessed by a
-    thread between operations. This requires additional care when reasoning
-    about and protecting per-CPU variables.

-
For example, it may be desirable to protect access using
-    critical_section(9) to prevent both preemption and
-    migration during use. Alternatively, it may be desirable to cache the CPU ID
-    at the start of a sequence of accesses, using suitable synchronization to
-    make non-atomic sequences safe in the presence of migration.

-

-
DPCPU_DEFINE_STATIC(int, foo_int);
-DPCPU_DEFINE_STATIC(struct mutex, foo_lock);
-
-void
-foo_int_increment(void)
-{
-    int cpu, value;
-
-    /* Safe as atomic access. */
-    atomic_add_int(DPCPU_PTR(foo_int), 1);
-
-    /*
-     * Protect with a critical section, which prevents preemption
-     * and migration.  However, access to instances from remote CPUs
-     * is not safe, as critical sections prevent concurrent access
-     * only from the current CPU.
-     */
-    critical_enter();
-    value = DPCPU_GET(foo_int);
-    value++;
-    DPCPU_SET(foo_int, value);
-    critical_exit();
-
-    /*
-     * Protect with a per-CPU mutex, tolerating migration, but
-     * potentially accessing the variable from multiple CPUs if
-     * migration occurs after reading curcpu.  Remote access to a
-     * per-CPU variable is safe as long as the correct mutex is
-     * acquired.
-     */
-    cpu = curcpu;
-    mtx_lock(DPCPU_ID_PTR(cpu, foo_lock));
-    value = DPCPU_ID_GET(cpu, foo_int);
-    value++;
-    DPCPU_ID_SET(cpu, foo_int);
-    mtx_unlock(DPCPU_ID_PTR(cpu, foo_lock));
-}

-

-

-

-

-

-
atomic(9), critical_enter(9),
-    mutex(9)

-

-

-

-
dpcpu was first introduced by
-    Jeff Roberson in FreeBSD
-    8.0. This manual page was written by Robert N. M.
-    Watson.

-

-

-
-  
-    
-    
-  
-
July 5, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/drbr.9 3.html b/static/freebsd/man9/drbr.9 3.html
deleted file mode 100644
index 7b88f6ba..00000000
--- a/static/freebsd/man9/drbr.9 3.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRBR(9)Kernel Developer's ManualDRBR(9)

-

-

-

-
drbr, drbr_free,
-    drbr_enqueue, drbr_dequeue,
-    drbr_dequeue_cond,
-    drbr_flush, drbr_empty,
-    drbr_inuse — network driver
-    interface to buf_ring

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <net/if.h>
-  

-  #include <net/if_var.h>

-
void
-  

-  drbr_free(struct
-    buf_ring *br, struct
-    malloc_type *type);

-
int
-  

-  drbr_enqueue(struct
-    ifnet *ifp, struct
-    buf_ring *br, struct mbuf
-    *m);

-
struct mbuf *
-  

-  drbr_dequeue(struct
-    ifnet *ifp, struct
-    buf_ring *br);

-
struct mbuf *
-  

-  drbr_dequeue_cond(struct
-    ifnet *ifp, struct
-    buf_ring *br, int (*func)
-    (struct mbuf *, void *),
-    void *arg);

-
void
-  

-  drbr_flush(struct
-    ifnet *ifp, struct
-    buf_ring *br);

-
int
-  

-  drbr_empty(struct
-    ifnet *ifp, struct
-    buf_ring *br);

-
int
-  

-  drbr_inuse(struct
-    ifnet *ifp, struct
-    buf_ring *br);

-

-

-

-
The drbr functions provide an API to
-    network drivers for using buf_ring(9) for enqueueing and
-    dequeueing packets. This is meant as a replacement for the IFQ interface for
-    packet queuing. It allows a packet to be enqueued with a single atomic and
-    packet dequeue to be done without any per-packet atomics as it is protected
-    by the driver's tx queue lock. If INVARIANTS is
-    enabled,
-    ()
-    will assert that the tx queue lock is held when it is called.

-
The
-    ()
-    function frees all the enqueued mbufs and then frees the buf_ring.

-
The
-    ()
-    function is used to enqueue an mbuf to a buf_ring, falling back to the
-    ifnet's IFQ if ALTQ(4) is enabled.

-
The
-    ()
-    function is used to dequeue an mbuf from a buf_ring or, if
-    ALTQ(4) is enabled, from the ifnet's IFQ.

-
The
-    ()
-    function is used to conditionally dequeue an mbuf from a buf_ring based on
-    whether func returns TRUE or
-    FALSE.

-
The
-    ()
-    function frees all mbufs enqueued in the buf_ring and the ifnet's IFQ.

-
The
-    ()
-    function returns TRUE if there are no mbufs
-    enqueued, FALSE otherwise.

-
The
-    ()
-    function returns the number of mbufs enqueued. Note to users that this is
-    intrinsically racy as there is no guarantee that there will not be more
-    mbufs when drbr_dequeue() is actually called.
-    Provided the tx queue lock is held there will not be less.

-

-

-

-
The drbr_enqueue() function returns
-    ENOBUFS if there are no slots available in the
-    buf_ring and 0 on success.

-
The drbr_dequeue() and
-    drbr_dequeue_cond() functions return an mbuf on
-    success and NULL if the buf_ring is empty.

-

-

-

-
These functions were introduced in FreeBSD
-    8.0.

-

-

-
-  
-    
-    
-  
-
September 27, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/driver.9 3.html b/static/freebsd/man9/driver.9 3.html
deleted file mode 100644
index 3b34b562..00000000
--- a/static/freebsd/man9/driver.9 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRIVER(9)Kernel Developer's ManualDRIVER(9)

-

-

-

-
driver — structure
-    describing a device driver

-

-

-

-

-
#include <sys/param.h>
-#include <sys/kernel.h>
-#include <sys/bus.h>
-#include <sys/module.h>
-
-static int foo_probe(device_t);
-static int foo_attach(device_t);
-static int foo_detach(device_t);
-static int foo_frob(device_t, int, int);
-static int foo_twiddle(device_t, char *);
-
-static device_method_t foo_methods[] = {
-	/* Methods from the device interface */
-	DEVMETHOD(device_probe,		foo_probe),
-	DEVMETHOD(device_attach,	foo_attach),
-	DEVMETHOD(device_detach,	foo_detach),
-
-	/* Methods from the bogo interface */
-	DEVMETHOD(bogo_frob,		foo_frob),
-	DEVMETHOD(bogo_twiddle,		foo_twiddle),
-
-	/* Terminate method list */
-	DEVMETHOD_END
-};
-
-static driver_t foo_driver = {
-	"foo",
-	foo_methods,
-	sizeof(struct foo_softc)
-};
-
-DRIVER_MODULE(foo, bogo, foo_driver, NULL, NULL);

-

-

-

-

-
Each driver in the kernel is described by a
-    driver_t structure. The structure contains the name
-    of the device, a pointer to a list of methods, an indication of the kind of
-    device which the driver implements and the size of the private data which
-    the driver needs to associate with a device instance. Each driver will
-    implement one or more sets of methods (called interfaces). The example
-    driver implements the standard "driver" interface and the
-    fictitious "bogo" interface.

-
When a driver is registered with the system (by the
-    DRIVER_MODULE macro, see
-    DRIVER_MODULE(9)), it is added to the list of drivers
-    contained in the devclass of its parent bus type. For instance all PCI
-    drivers would be contained in the devclass named "pci" and all ISA
-    drivers would be in the devclass named "isa". The reason the
-    drivers are not held in the device object of the parent bus is to handle
-    multiple instances of a given type of bus. The
-    DRIVER_MODULE macro will also create the devclass
-    with the name of the driver and can optionally call extra initialisation
-    code in the driver by specifying an extra module event handler and argument
-    as the last two arguments.

-

-

-

-
devclass(9), device(9),
-    DEVICE_ATTACH(9), DEVICE_DETACH(9),
-    DEVICE_IDENTIFY(9), DEVICE_PROBE(9),
-    DEVICE_SHUTDOWN(9), DRIVER_MODULE(9)

-

-

-

-
The driver framework first appeared in
-    FreeBSD 2.2.7.

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
April 19, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/ecn.9 3.html b/static/freebsd/man9/ecn.9 3.html
deleted file mode 100644
index aa2145aa..00000000
--- a/static/freebsd/man9/ecn.9 3.html	
+++ /dev/null
@@ -1,174 +0,0 @@
-
-  
-    
-    
-    
-  
-
ECN(9)Kernel Developer's ManualECN(9)

-

-

-

-
ecn,
-    ip_ecn_ingress,
-    ip_ecn_egress,
-    ip6_ecn_ingress,
-    ip6_ecn_egress — IP ECN
-    interfaces for tunnel encapsulation/decapsulation

-

-

-

-
#include
-    <sys/netinet/ip_ecn.h>
-  

-  #include
-    <sys/netinet6/ip6_ecn.h>

-

-

-
ECN_COMPLETE
-    ECN_ALLOWED ECN_FORBIDDEN
-    ECN_NOCARE

-

-

-

-
void
-  

-  ip_ecn_ingress(int
-    mode, uint8_t
-    *outer, const uint8_t
-    *inner);

-
void
-  

-  ip6_ecn_ingress(int
-    mode, uint32_t
-    *outer, const uint32_t
-    *inner);

-
int
-  

-  ip_ecn_egress(int
-    mode, uint8_t
-    *outer, const uint8_t
-    *inner);

-
int
-  

-  ip6_ecn_egress(int
-    mode, uint32_t
-    *outer, const uint32_t
-    *inner);

-

-

-

-

-
The
-    ()
-    and ip_ecn_egress() interfaces implement Explicit
-    Congestion Notification (ECN) processing for tunnel encapsulation (ingress)
-    and decapsulation (egress). They operate on the ECN bits in the IP Type of
-    Service (TOS) or IPv6 Traffic Class (TCLASS) header field. These functions
-    implements the standard specification of RFC6040 in
-    ECN_ALLOWED mode for
-    ip_ecn_egress() with addition of
-    ECN_FORBIDDEN mode as compatibility mode in
-    ip_ecn_ingress().

-

-

-
The functions for manipulating ip_tos and
-    ipv6_flow are as follows:

-

-

-  
ip_ecn_ingress()
-    ip6_ecn_ingress()

-  
Perform ECN processing at encapsulation time (ingress) based on the ECN
-      bits of the ip_tos field in struct
-      ip or the ip6_flow field in
-      struct ip6_hdr as inner to
-      outer. It also copies the DSCP value from
-      inner to outer.

-  
ip_ecn_egress()
-    ip6_ecn_egress()

-  
Perform ECN processing at decapsulation time (egress) based on the ECN
-      bits of outer to inner.
-      ECN_ALLOWED mode may modify the
-      inner ECN bits or instruct the caller to drop or log
-      by returning ECN_WARN or
-      ECN_ALARM values.

-

-

-
Return codes for
-    ()
-    are as follows:

-

-

-  

-  
(0) Caller MUST drop the packet.

-  

-  
(1) Processing succeeded; inner ECN bits may have been updated.

-  

-  
(2) Processing succeeded; caller MAY log a warning for an anomalous ECN
-      combination.

-  

-  
(3) Processing succeeded; caller SHOULD log and MAY raise an alarm for a
-      serious ECN anomaly.

-

-

-
The following modes are handled by functions:

-

-

-  

-  
Normal mode as defined in RFC6040. ECN bits are preserved through
-      encapsulation; decapsulation follows RFC6040 rules and it returns
-      ECN_WARN or ECN_ALARM values
-      when a potentially dangerous packet detected.

-  

-  
Normal mode as defined in RFC6040 without security checks. ECN bits are
-      preserved through encapsulation; decapsulation follows RFC6040 rules.

-  

-  
Compatibility mode. ECN is stripped on encapsulation and decapsulation
-      will drop packets that carry CE in the outer header. This mode should not
-      be used in
-      ()
-      or
-      ()
-      since the ECN_ALLOWED mode already covers all
-      possible scenarios as specified in RFC6040.

-  

-  
leave ECN bits unchanged and ignored.

-

-

-

-

-

-
IPv6 interfaces
-    ()
-    and ip6_ecn_egress() extract the 8-bit DSCP and ECN
-    values from the 32-bit ip6_flow and insert it to IPv4
-    equivalent interfaces.

-

-

-

-

-
ip(4), ip6(4),
-    ipsec(4)

-

-

-

-
Historically ip_ecn_egress() used a
-    boolean-style return. The current API preserves numeric mapping for drop
-    (ECN_DROP == 0) and success (ECN_SUCCESS == 1) but defines additional
-    non-zero status codes (ECN_WARN, ECN_ALARM). Callers that only test for
-    non-zero success will continue to treat WARN/ALARM as success.

-

-

-

-
Pouria Mousavizadeh Tehrani
-    <pouria@FreeBSD.org>

-

-

-
-  
-    
-    
-  
-
March 19, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/efirt.9 3.html b/static/freebsd/man9/efirt.9 3.html
deleted file mode 100644
index 6c662062..00000000
--- a/static/freebsd/man9/efirt.9 3.html	
+++ /dev/null
@@ -1,208 +0,0 @@
-
-  
-    
-    
-    
-  
-
EFIRT(9)Kernel Developer's ManualEFIRT(9)

-

-

-

-
efirt, efi_rt_ok,
-    efi_get_table, efi_get_time,
-    efi_get_time_capabilities,
-    efi_reset_system,
-    efi_set_time, efi_var_get,
-    efi_var_nextname,
-    efi_var_set — kernel access
-    to UEFI runtime services

-

-

-

-
options EFIRT

-

-  

-  #include <sys/efi.h>

-
int
-  

-  efi_rt_ok(void);

-
int
-  

-  efi_get_table(struct
-    uuid *uuid, void
-    **ptr);

-
int
-  

-  efi_get_time(struct
-    efi_tm *tm);

-
int
-  

-  efi_get_time_capabilities(struct
-    efi_tmcap *tmcap);

-
int
-  

-  efi_reset_system(enum
-    efi_reset type);

-
int
-  

-  efi_set_time(struct
-    efi_tm *tm);

-
int
-  

-  efi_var_get(uint16_t
-    *name, struct uuid
-    *vendor, uint32_t
-    *attrib, size_t
-    *datasize, void
-    *data);

-
int
-  

-  efi_var_nextname(size_t
-    *namesize, uint16_t
-    *name, struct uuid
-    *vendor);

-
int
-  

-  efi_var_set(uint16_t
-    *name, struct uuid
-    *vendor, uint32_t
-    attrib, size_t
-    datasize, void
-    *data);

-

-

-

-
All of the following calls will return
-    ENXIO if UEFI runtime services are not available.
-    efirt is currently only available on amd64 and
-    arm64.

-
The
-    ()
-    Returns 0 if UEFI runtime services are present and functional, or
-    ENXIO if not.

-
The
-    ()
-    function gets a table by uuid from the UEFI system table. Returns 0 if the
-    table was found and populates *ptr with the address. Returns
-    ENXIO if the configuration table or system table are
-    unset. Returns ENOENT if the requested table cannot
-    be found.

-
The
-    ()
-    function gets the current time from the RTC, if available. Returns 0 and
-    populates the struct efi_tm on success. Returns
-    EINVAL if the struct efi_tm is
-    NULL, or EIO if the time
-    could not be retrieved due to a hardware error.

-
The
-    ()
-    function gets the capabilities from the RTC. Returns 0 and populates the
-    struct efi_tmcap on success. Returns
-    EINVAL if the struct efi_tm is
-    NULL, or EIO if the time
-    could not be retrieved due to a hardware error.

-
The
-    ()
-    function requests a reset of the system. The type
-    argument may be one of the enum efi_reset values:

-

-  

-  
Perform a cold reset of the system, and reboot.

-  

-  
Perform a warm reset of the system, and reboot.

-  

-  
Power off the system.

-

-
The
-    ()
-    function sets the time on the RTC to the time described by the
-    struct efi_tm passed in. Returns 0 on success,
-    EINVAL if a time field is out of range, or
-    EIO if the time could not be set due to a hardware
-    error.

-
The
-    ()
-    function fetches the variable identified by vendor and
-    name. Returns 0 and populates
-    attrib, datasize, and
-    data on success. Otherwise, one of the following
-    errors are returned:

-

-  

-  
The variable was not found.

-  

-  
datasize is not sufficient to hold the variable
-      data. namesize is updated to reflect the size needed
-      to complete the request.

-  

-  
One of name, vendor, or
-      datasize are NULL. Alternatively,
-      datasize is large enough to hold the response but
-      data is NULL.

-  

-  
The variable could not be retrieved due to a hardware error.

-  

-  
The variable could not be retrieved due to an authentication failure.

-

-
The
-    ()
-    function is used for enumeration of variables. On the initial call to
-    efi_var_nextname(), name
-    should be an empty string. Subsequent calls should pass in the last
-    name and vendor returned until
-    ENOENT is returned. Returns 0 and populates
-    namesize, name, and
-    vendor with the next variable's data. Otherwise,
-    returns one of the following errors:

-

-  

-  
The next variable was not found.

-  

-  
datasize is not sufficient to hold the variable
-      data. namesize is updated to reflect the size needed
-      to complete the request.

-  

-  
One of name, vendor, or
-      datasize are NULL.

-  

-  
The variable could not be retrieved due to a hardware error.

-

-
The
-    ()
-    function sets the variable described by name and
-    vendor. Returns 0 if the variable has been
-    successfully. Otherwise, returns one of the following errors:

-

-  

-  
Either attrib was an invalid combination of
-      attributes, datasize exceeds the maximum allowed
-      size, or name is an empty Unicode stirng.

-  

-  
Not enough storage is available to hold the variable and its data.

-  

-  
The variable could not be saved due to a hardware error.

-  

-  
The variable in question is read-only or may not be deleted.

-  

-  
The variable could not be set due to an authentication failure.

-  

-  
The variable trying to be updated or deleted was not found.

-

-

-

-

-
efidev(4)

-

-

-

-
This manual page was written by Kyle Evans
-    <kevans@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 2, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/epoch.9 4.html b/static/freebsd/man9/epoch.9 4.html
deleted file mode 100644
index eb84213b..00000000
--- a/static/freebsd/man9/epoch.9 4.html	
+++ /dev/null
@@ -1,284 +0,0 @@
-
-  
-    
-    
-    
-  
-
EPOCH(9)Kernel Developer's ManualEPOCH(9)

-

-

-

-
epoch,
-    epoch_context, epoch_alloc,
-    epoch_free, epoch_enter,
-    epoch_exit, epoch_wait,
-    epoch_enter_preempt,
-    epoch_exit_preempt,
-    epoch_wait_preempt,
-    epoch_call,
-    epoch_drain_callbacks,
-    in_epoch, in_epoch_verbose
-    — kernel epoch based reclamation

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>
-  

-  #include <sys/epoch.h>

-

-
struct epoch;		/* Opaque */

-

-

-typedef struct epoch *epoch_t;
-

-
struct epoch_context {
-	void	*data[2];
-};

-

-

-typedef struct epoch_context *epoch_context_t;
-

-typedef void epoch_callback_t(epoch_context_t);
-

-
struct epoch_tracker;	/* Opaque */

-

-

-typedef struct epoch_tracker *epoch_tracker_t;
-
epoch_t
-  

-  epoch_alloc(const
-    char *name, int
-    flags);

-
void
-  

-  epoch_free(epoch_t
-    epoch);

-
void
-  

-  epoch_enter(epoch_t
-    epoch);

-
void
-  

-  epoch_exit(epoch_t
-    epoch);

-
void
-  

-  epoch_wait(epoch_t
-    epoch);

-
void
-  

-  epoch_enter_preempt(epoch_t
-    epoch, epoch_tracker_t
-    et);

-
void
-  

-  epoch_exit_preempt(epoch_t
-    epoch, epoch_tracker_t
-    et);

-
void
-  

-  epoch_wait_preempt(epoch_t
-    epoch);

-
void
-  

-  epoch_call(epoch_t
-    epoch, epoch_callback_t
-    callback, epoch_context_t
-    ctx);

-
void
-  

-  epoch_drain_callbacks(epoch_t
-    epoch);

-
int
-  

-  in_epoch(epoch_t
-    epoch);

-
int
-  

-  in_epoch_verbose(epoch_t
-    epoch, int
-    dump_onfail);

-

-

-

-
Epochs are used to guarantee liveness and immutability of data by
-    deferring reclamation and mutation until a grace period has elapsed. Epochs
-    do not have any lock ordering issues. Entering and leaving an epoch section
-    will never block.

-
Epochs are allocated with
-    ().
-    The name argument is used for debugging convenience
-    when the EPOCH_TRACE kernel option is configured. By
-    default, epochs do not allow preemption during sections. By default mutexes
-    cannot be held across
-    ().
-    The flags specified are formed by
-    'ing the
-    following values:

-

-

-  

-  
Permit holding mutexes across epoch_wait_preempt()
-      (requires EPOCH_PREEMPT). When doing this one must
-      be cautious of creating a situation where a deadlock is possible.

-  

-  
The epoch will allow preemption during sections.
-      Only non-sleepable locks may be acquired during a preemptible epoch. The
-      functions epoch_enter_preempt(),
-      epoch_exit_preempt(), and
-      epoch_wait_preempt() must be used in place of
-      epoch_enter(),
-      epoch_exit(), and
-      epoch_wait(), respectively.

-

-

-
epochs are freed with
-    ().

-
Threads indicate the start of an epoch critical
-    section by calling
-    ()
-    (or
-    ()
-    for preemptible epochs). Threads call
-    ()
-    (or
-    ()
-    for preemptible epochs) to indicate the end of a critical section.
-    struct epoch_trackers are stack objects whose pointers
-    are passed to epoch_enter_preempt() and
-    epoch_exit_preempt() (much like
-    struct rm_priotracker).

-
Threads can defer work until a grace period has
-    expired since any thread has entered the epoch either synchronously or
-    asynchronously.
-    ()
-    defers work asynchronously by invoking the provided
-    callback at a later time.
-    epoch_wait() (or
-    epoch_wait_preempt()) blocks the current thread
-    until the grace period has expired and the work can be done safely.

-
Default, non-preemptible epoch wait
-    (())
-    is guaranteed to have much shorter completion times relative to preemptible
-    epoch wait
-    (()).
-    (In the default type, none of the threads in an epoch section will be
-    preempted before completing its section.)

-
INVARIANTS can assert that a thread is in an epoch
-    by using
-    ().
-    in_epoch(epoch) is equivalent
-    to invoking
-    (epoch,
-    0). If EPOCH_TRACE is enabled,
-    in_epoch_verbose(epoch,
-    1) provides additional verbose debugging
-  information.

-
The epoch API currently does not support
-    sleeping in epoch_preempt sections. A caller should never call
-    ()
-    in the middle of an epoch section for the same epoch as this will lead to a
-    deadlock.

-
The
-    ()
-    function is used to drain all pending callbacks which have been invoked by
-    prior epoch_call() function calls on the same epoch.
-    This function is useful when there are shared memory structure(s) referred
-    to by the epoch callback(s) which are not refcounted and are rarely freed.
-    The typical place for calling this function is right before freeing or
-    invalidating the shared resource(s) used by the epoch callback(s). This
-    function can sleep and is not optimized for performance.

-

-

-

-
in_epoch(curepoch)
-    will return 1 if curthread is in curepoch, 0 otherwise.

-

-

-

-
Async free example: Thread 1:

-

-
int
-in_pcbladdr(struct inpcb *inp, struct in_addr *faddr, struct in_laddr *laddr,
-    struct ucred *cred)
-{
-    /* ... */
-    epoch_enter(net_epoch);
-    CK_STAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
-        sa = ifa->ifa_addr;
-	if (sa->sa_family != AF_INET)
-	    continue;
-	sin = (struct sockaddr_in *)sa;
-	if (prison_check_ip4(cred, &sin->sin_addr) == 0) {
-	     ia = (struct in_ifaddr *)ifa;
-	     break;
-	}
-    }
-    epoch_exit(net_epoch);
-    /* ... */
-}

-

-Thread 2:
-

-
void
-ifa_free(struct ifaddr *ifa)
-{
-
-    if (refcount_release(&ifa->ifa_refcnt))
-        epoch_call(net_epoch, ifa_destroy, &ifa->ifa_epoch_ctx);
-}
-
-void
-if_purgeaddrs(struct ifnet *ifp)
-{
-
-    /* .... *
-    IF_ADDR_WLOCK(ifp);
-    CK_STAILQ_REMOVE(&ifp->if_addrhead, ifa, ifaddr, ifa_link);
-    IF_ADDR_WUNLOCK(ifp);
-    ifa_free(ifa);
-}

-

-
Thread 1 traverses the ifaddr list in an epoch. Thread 2 unlinks
-    with the corresponding epoch safe macro, marks as logically free, and then
-    defers deletion. More general mutation or a synchronous free would have to
-    follow a call to epoch_wait().

-

-

-

-
callout(9), locking(9),
-    mtx_pool(9), mutex(9),
-    rwlock(9), sema(9),
-    sleep(9), sx(9)

-

-

-

-
The epoch framework first appeared in
-    FreeBSD 11.0.

-

-

-

-
One must be cautious when using
-    epoch_wait_preempt(). Threads are pinned during
-    epoch sections, so if a thread in a section is then preempted by a higher
-    priority compute bound thread on that CPU, it can be prevented from leaving
-    the section indefinitely.

-
Epochs are not a straight replacement for read locks. Callers must
-    use safe list and tailq traversal routines in an epoch (see ck_queue). When
-    modifying a list referenced from an epoch section safe removal routines must
-    be used and the caller can no longer modify a list entry in place. An item
-    to be modified must be handled with copy on write and frees must be deferred
-    until after a grace period has elapsed.

-

-

-
-  
-    
-    
-  
-
March 25, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/ether_gen_addr.9 4.html b/static/freebsd/man9/ether_gen_addr.9 4.html
deleted file mode 100644
index d8f4aea2..00000000
--- a/static/freebsd/man9/ether_gen_addr.9 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
ETHER_GEN_ADDR(9)Kernel Developer's ManualETHER_GEN_ADDR(9)

-

-

-

-
ether_gen_addr —
-    generate an arbitrary MAC address for use

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <net/if.h>
-  

-  #include <net/if_var.h>
-  

-  #include <net/ethernet.h>

-
void
-  

-  ether_gen_addr(struct
-    ifnet *ifp, struct
-    ether_addr *hwaddr);

-

-

-

-
The
-    ()
-    function generates an arbitrary MAC address for use by an ethernet interface
-    that does not have an assigned address.

-
By default, ether_gen_addr attempts to
-    generate a stable MAC address using the hostid of the jail that the
-    ifp is being added to. During early boot, the hostid
-    may not be set on machines that haven't yet populated
-    /etc/hostid, or on machines that do not use
-    loader(8).

-
ether_gen_addr can fail to derive a MAC
-    address due to memory allocation failure, or because the hostid has not been
-    populated. In these cases, a locally-administered unicast MAC address will
-    be randomly generated and returned via the hwaddr
-    parameter.

-
If ether_gen_addr succeeds, then it will
-    return a MAC address in the FreeBSD Foundation OUI,
-    “58:9c:fc”, via the hwaddr
-  parameter.

-

-

-

-
This manual page was written by Kyle Evans
-    <kevans@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 1, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/eventtimers.9 4.html b/static/freebsd/man9/eventtimers.9 4.html
deleted file mode 100644
index f08938bc..00000000
--- a/static/freebsd/man9/eventtimers.9 4.html	
+++ /dev/null
@@ -1,252 +0,0 @@
-
-  
-    
-    
-    
-  
-
EVENTTIMERS(9)Kernel Developer's ManualEVENTTIMERS(9)

-

-

-

-
eventtimers —
-    kernel event timers subsystem

-

-

-

-
#include
-    <sys/timeet.h>

-

-
struct eventtimer;
-
-typedef int et_start_t(struct eventtimer *et,
-    sbintime_t first, sbintime_t period);
-typedef int et_stop_t(struct eventtimer *et);
-typedef void et_event_cb_t(struct eventtimer *et, void *arg);
-typedef int et_deregister_cb_t(struct eventtimer *et, void *arg);
-
-struct eventtimer {
-	SLIST_ENTRY(eventtimer)	et_all;
-	char			*et_name;
-	int			et_flags;
-#define ET_FLAGS_PERIODIC	1
-#define ET_FLAGS_ONESHOT	2
-#define ET_FLAGS_PERCPU		4
-#define ET_FLAGS_C3STOP		8
-#define ET_FLAGS_POW2DIV	16
-	int			et_quality;
-	int			et_active;
-	uint64_t		et_frequency;
-	sbintime_t		et_min_period;
-	sbintime_t		et_max_period;
-	et_start_t		*et_start;
-	et_stop_t		*et_stop;
-	et_event_cb_t		*et_event_cb;
-	et_deregister_cb_t	*et_deregister_cb;
-	void 			*et_arg;
-	void			*et_priv;
-	struct sysctl_oid	*et_sysctl;
-};

-

-

-int
-

-et_register(struct
-  eventtimer *et);
-
int
-  

-  et_deregister(struct
-    eventtimer *et);

-
void
-  

-  et_change_frequency(struct
-    eventtimer *et, uint64_t
-    newfreq);

-
ET_LOCK();

-
ET_UNLOCK();

-
struct eventtimer *
-  

-  et_find(const
-    char *name, int
-    check, int
-  want);

-
int
-  

-  et_init(struct
-    eventtimer *et,
-    et_event_cb_t *event,
-    et_deregister_cb_t
-    *deregister, void
-    *arg);

-
int
-  

-  et_start(struct
-    eventtimer *et,
-    sbintime_t first,
-    sbintime_t period);

-
int
-  

-  et_stop(struct
-    eventtimer *et);

-
int
-  

-  et_ban(struct
-    eventtimer *et);

-
int
-  

-  et_free(struct
-    eventtimer *et);

-

-

-

-
Event timers are responsible for generating interrupts at
-    specified time or periodically, to run different time-based events.
-    Subsystem consists of three main parts:

-

-  
Drivers

-  
Manage hardware to generate requested time events.

-  
Consumers

-  
sys/kern/kern_clocksource.c uses event timers to
-      supply kernel with
-      (),
-      ()
-      and
-      ()
-      time events.

-  
Glue code

-  
sys/sys/timeet.h,
-      sys/kern/kern_et.c provide APIs for event timer
-      drivers and consumers.

-

-

-

-

-
Driver API is built around eventtimer structure. To register its
-    functionality driver allocates that structure and calls
-    ().
-    Driver should fill following fields there:

-

-  
et_name

-  
Unique name of the event timer for management purposes.

-  
et_flags

-  
Set of flags, describing timer capabilities:
-    

-      
ET_FLAGS_PERIODIC

-      
Periodic mode supported.

-      
ET_FLAGS_ONESHOT

-      
One-shot mode supported.

-      
ET_FLAGS_PERCPU

-      
Timer is per-CPU.

-      
ET_FLAGS_C3STOP

-      
Timer may stop in CPU sleep state.

-      
ET_FLAGS_POW2DIV

-      
Timer supports only 2^n divisors.

-    

-  

-  
et_quality

-  
Abstract value to certify whether this timecounter is better than the
-      others. Higher value means better.

-  
et_frequency

-  
Timer oscillator's base frequency, if applicable and known. Used by
-      consumers to predict set of possible frequencies that could be obtained by
-      dividing it. Should be zero if not applicable or unknown.

-  
et_min_period,
-    et_max_period

-  
Minimal and maximal reliably programmable time periods.

-  
et_start

-  
Driver's timer start function pointer.

-  
et_stop

-  
Driver's timer stop function pointer.

-  
et_priv

-  
Driver's private data storage.

-

-
After the event timer functionality is registered, it is
-    controlled via et_start and
-    et_stop methods. et_start method
-    is called to start the specified event timer. The last two arguments are
-    used to specify time when events should be generated.
-    first argument specifies time period before the first
-    event generated. In periodic mode NULL value specifies that first period is
-    equal to the period argument value.
-    period argument specifies the time period between
-    following events for the periodic mode. The NULL value there specifies the
-    one-shot mode. At least one of these two arguments should be not NULL. When
-    event time arrive, driver should call et_event_cb
-    callback function, passing et_arg as the second
-    argument. et_stop method is called to stop the
-    specified event timer. For the per-CPU event timers
-    et_start and et_stop methods
-    control timers associated with the current CPU.

-
Driver may deregister its functionality by
-    calling
-    ().

-
If the frequency of the clock hardware
-    can change while it is running (for example, during power-saving modes), the
-    driver must call
-    ()
-    on each change. If the given event timer is the active timer,
-    et_change_frequency() stops the timer on all CPUs,
-    updates et->frequency, then restarts the timer on
-    all CPUs so that all current events are rescheduled using the new frequency.
-    If the given timer is not currently active,
-    et_change_frequency() simply updates
-    et->frequency.

-

-

-

-
et_find() allows consumer to find
-    available event timer, optionally matching specific name and/or capability
-    flags. Consumer may read returned eventtimer structure, but should not
-    modify it. When wanted event timer is found,
-    et_init() should be called for it, submitting
-    event and optionally deregister
-    callbacks functions, and the opaque argument arg. That
-    argument will be passed as argument to the callbacks. Event callback
-    function will be called on scheduled time events. It is called from the
-    hardware interrupt context, so no sleep is permitted there. Deregister
-    callback function may be called to report consumer that the event timer
-    functionality is no longer available. On this call, consumer should stop
-    using event timer before the return.

-
After the timer is found and initialized, it can
-    be controlled via
-    ()
-    and et_stop(). The arguments are the same as
-    described in driver API. Per-CPU event timers can be controlled only from
-    specific CPUs.

-
()
-    allows consumer to mark event timer as broken via clearing both one-shot and
-    periodic capability flags, if it was somehow detected.
-    ()
-    is the opposite to
-    ().
-    It releases the event timer for other consumers use.

-
()
-    and
-    ()
-    macros should be used to manage mutex(9) lock around
-    (),
-    et_init() and et_free()
-    calls to serialize access to the list of the registered event timers and the
-    pointers returned by et_find().
-    et_start() and et_stop()
-    calls should be serialized in consumer's internal way to avoid concurrent
-    timer hardware access.

-

-

-

-
eventtimers(4)

-

-

-

-
Alexander Motin
-    <mav@FreeBSD.org>

-

-

-
-  
-    
-    
-  
-
April 2, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/extattr.9 3.html b/static/freebsd/man9/extattr.9 3.html
deleted file mode 100644
index 94bcd948..00000000
--- a/static/freebsd/man9/extattr.9 3.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
EXTATTR(9)Kernel Developer's ManualEXTATTR(9)

-

-

-

-
extattr — virtual
-    file system named extended attributes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/extattr.h>

-

-

-

-
Named extended attributes allow additional meta-data to be
-    associated with vnodes representing files and directories. The semantics of
-    this additional data is that of a "name=value" pair, where a name
-    may be defined or undefined, and if defined, associated with zero or more
-    bytes of arbitrary binary data. Extended attribute names exist within a set
-    of namespaces; each operation on an extended attribute is required to
-    provide the namespace to which to operation refers. If the same name is
-    present in multiple namespaces, the extended attributes associated with the
-    names are stored and manipulated independently. The following two namespaces
-    are defined universally, although individual file systems may implement
-    additional namespaces, or not implement these namespaces:
-    EXTATTR_NAMESPACE_USER,
-    EXTATTR_NAMESPACE_SYSTEM. The semantics of these
-    attributes are intended to be as follows: user attribute data is protected
-    according the normal discretionary and mandatory protections associated with
-    the data in the file or directory; system attribute data is protected such
-    that appropriate privilege is required to directly access or manipulate
-    these attributes. By default, processes in a jail(8)
-    cannot access the system attribute data unless the
-    allow.extattr configuration parameter is
-  specified.

-
Reads of extended attribute data may return specific contiguous
-    regions of the meta-data, in the style of VOP_READ(9), but
-    writes will replace the entire current "value" associated with a
-    given name. As there are a plethora of file systems with differing extended
-    attributes, availability and functionality of these functions may be
-    limited, and they should be used with awareness of the underlying semantics
-    of the supporting file system. Authorization schemes for extended attribute
-    data may also vary by file system, as well as maximum attribute size, and
-    whether or not any or specific new attributes may be defined.

-
Extended attributes are named using a null-terminated character
-    string. Depending on underlying file system semantics, this name may or may
-    not be case-sensitive. Appropriate vnode extended attribute calls are:
-    VOP_GETEXTATTR(9), VOP_LISTEXTATTR(9),
-    and VOP_SETEXTATTR(9).

-

-

-

-
jail(8), VFS(9),
-    VOP_GETEXTATTR(9), VOP_LISTEXTATTR(9),
-    VOP_SETEXTATTR(9)

-

-

-

-
This manual page was written by Robert
-    Watson.

-

-

-

-
In addition, the interface does not provide a mechanism to
-    retrieve the current set of available attributes; it has been suggested that
-    providing a NULL attribute name should cause a list
-    of defined attributes for the passed file or directory, but this is not
-    currently implemented.

-

-

-
-  
-    
-    
-  
-
September 5, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/exterror.9 3.html b/static/freebsd/man9/exterror.9 3.html
deleted file mode 100644
index c28538a1..00000000
--- a/static/freebsd/man9/exterror.9 3.html	
+++ /dev/null
@@ -1,185 +0,0 @@
-
-  
-    
-    
-    
-  
-
EXTERROR(9)Kernel Developer's ManualEXTERROR(9)

-

-

-

-
exterror — provide
-    extended error information to userspace

-

-

-

-

-
#define	EXTERR_CATEGORY EXTERR_CAT_MYCATEGORY

-

-

-
#include
-    <sys/exterrvar.h>

-
struct kexterr;

-
void
-  

-  exterr_clear(struct
-    kexterr *ke);

-
int
-  

-  exterr_set_from(const
-    struct kexterr *ke);

-
int
-  

-  EXTERROR(int
-    error, const char
-    *msg, ...);

-
void
-  

-  EXTERROR_KE(struct
-    kexterr *ke, int
-    error, const char
-    *msg, ...);

-

-

-

-
The exterror framework allows the kernel
-    to return additional information about an error along with the standard
-    errno(3) error code, which is terse and often lacking
-    context.

-
The terseness is especially visible with commonly overloaded error
-    codes like EINVAL or EIO,
-    which occur at many places for a given syscall, or even outside the context
-    of the current kernel call. Identifying the specific cause for the returned
-    error using only the errno value requires searching
-    for all instances that the error is returned in the kernel and trying to
-    guess which is the most likely code path to have returned the error.
-    exterror attaches additional data to the error
-    itself and records the error category and the kernel source code file line
-    number. The intent of exterror is to make it easier
-    for a user to identify the cause of the error.

-

-

-

-
Before exterror can be used in the given
-    source .c file, the category of extended errors should be allocated in the
-    <sys/exterr_cat.h> file. The
-    category is the unique integer, that, together with the source line number,
-    uniquely identifies the extended error occurrence. Then, the
-    EXTERR_CATEGORY symbol should be defined as an alias
-    for the allocated category, as shown in the summary.

-
A typical code fragment to report an error is just

-
return (EINVAL);

-An extended error can augment the error code with additional information:
-
return (EXTERROR(EINVAL, "Invalid
-  length"));

-The error data and metadata is saved in the current thread storage. The metadata
-  includes the category and the source file line number.
-
Arguments to the
-    ()
-    macro:

-
    
-  
  • The first argument to EXTERROR() is the errno
-      error code.
    • 
-  
  • The second argument is a constant string with the unbound lifetime, which
-      should tersely provide enough human-readable details about the error.
    • 
-  
  • The EXTERROR() macro can take two optional 64-bit
-      integer arguments, whose meaning is specific to the subsystem. The format
-      string may include up to two printf-like format specifiers to insert the
-      optional argument values in the user output, which is done in userspace.
-    
    The format specifier must be for an integer type, and include
-        the “j” format modifier to accept only the types
-        intmax_t or uintmax_t.
    
-  
    • 
-

-
The strings passed as the second argument are only retained in the
-    kernel text if the option EXTERR_STRINGS was enabled
-    in the kernel config. Otherwise they are stripped at compile time and are
-    not available to userspace at runtime.

-
The
-    ()
-    macro can be used in any context where the current thread is defined.
-    Specifically, EXTERROR() cannot be used in interrupt
-    contexts and context switch code. Additionally, use of
-    EXTERROR() in kernel threads is not sensible as
-    there is no userspace to retrieve the extended error data.

-
The
-    ()
-    macro is similar to EXTERROR(), but it takes an
-    explicit pointer kep to the struct
-    kexterr to fill with the extended error information. The macro
-    expression value is void. See below for description of
-    the asynchronous i/o error facilities.

-
The
-    ()
-    function clears the content of the struct kexterr
-    pointed to by the argument ke.

-
The
-    ()
-    function sets the current thread extended error data from the
-    struct kexterr pointed to by the argument
-    ke.

-

-

-

-
There is no syscall overhead for using
-    exterror in the non-error case. When an error occurs
-    that has supplied extended information, the kernel copies out that
-    information into the userspace per-thread area that was registered with the
-    kernel, typically on image activation, or later at thread startup. The area
-    is controlled by the exterrctl(2) internal syscall,
-    normally done by the userspace C runtime.

-
Userspace programs do not need to access the extended information
-    area directly. There is no field that is stable for the specific error
-    condition. Instead, the base library
-    “c” functions err(3) and
-    warn(3) were modified to print the extended information if
-    it is available in addition to the usual errno
-    decoding.

-

-

-

-
Due to the nature of the FreeBSD i/o
-    subsystem, most input/output requests, presented as buffers (as in
-    struct buf) and geom bio's ( struct
-    bio) are processed asynchronously in filesystem- and geom-private
-    threads. This makes it challenging to pass any extended error information
-    from the geom providers and drivers, where an error typically occurs, back
-    to the thread that initiated the request, and is the consumer of the
-  result.

-
To alleviate the mismatch, both
-    struct buf and struct bio have
-    member of the struct kexterr type. For buffers, the
-    b_exterr for struct buf, and
-    bio_exterr for struct bio.
-    Asynchronous i/o code can use the
-    ()
-    macro, passing the pointer to the current request's embedded
-    struct kexterr, to record the extended error. In both
-    cases, the BIO_EXTERR flag should be set to indicate
-    that whole extended error is valid, not only the
-    b_error or bio_error values.

-
Both VFS and geom generic layers, and several geom providers that
-    generate subordinate bio's from the original request, are aware of the
-    extended errors. They pass kexterr from the failed
-    request back to the thread that create the request.

-

-

-

-
errno(3), err(3),
-    uexterr_gettext(3)

-

-

-

-
The exterror facility was introduced in
-    FreeBSD 15.0.

-

-

-
-  
-    
-    
-  
-
November 5, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/fail.9 3.html b/static/freebsd/man9/fail.9 3.html
deleted file mode 100644
index 273245d4..00000000
--- a/static/freebsd/man9/fail.9 3.html	
+++ /dev/null
@@ -1,263 +0,0 @@
-
-  
-    
-    
-    
-  
-
FAIL(9)Kernel Developer's ManualFAIL(9)

-

-

-

-
DEBUG_FP,
-    KFAIL_POINT_CODE,
-    KFAIL_POINT_CODE_FLAGS,
-    KFAIL_POINT_CODE_COND,
-    KFAIL_POINT_ERROR,
-    KFAIL_POINT_EVAL,
-    KFAIL_POINT_DECLARE,
-    KFAIL_POINT_DEFINE,
-    KFAIL_POINT_GOTO,
-    KFAIL_POINT_RETURN,
-    KFAIL_POINT_RETURN_VOID,
-    KFAIL_POINT_SLEEP_CALLBACKS,
-    fail_point — fail
-    points

-

-

-

-
#include
-    <sys/fail.h>

-
KFAIL_POINT_CODE(parent,
-    name,
-    code);

-
KFAIL_POINT_CODE_FLAGS(parent,
-    name,
-    flags,
-    code);

-
KFAIL_POINT_CODE_COND(parent,
-    name,
-    cond,
-    flags,
-    code);

-
KFAIL_POINT_ERROR(parent,
-    name,
-    error_var);

-
KFAIL_POINT_EVAL(name,
-    code);

-
KFAIL_POINT_DECLARE(name);

-
KFAIL_POINT_DEFINE(parent,
-    name,
-    flags);

-
KFAIL_POINT_GOTO(parent,
-    name,
-    error_var,
-    label);

-
KFAIL_POINT_RETURN(parent,
-    name);

-
KFAIL_POINT_RETURN_VOID(parent,
-    name);

-
KFAIL_POINT_SLEEP_CALLBACKS(parent,
-    name,
-    pre_func,
-    pre_arg,
-    post_func,
-    post_arg,
-    code);

-

-

-

-
Fail points are used to add code points where errors may be
-    injected in a user controlled fashion. Fail points provide a convenient
-    wrapper around user-provided error injection code, providing a
-    sysctl(9) MIB, and a parser for that MIB that describes
-    how the error injection code should fire.

-
The base fail point macro is
-    ()
-    where parent is a sysctl tree (frequently
-    DEBUG_FP for kernel fail points, but various subsystems
-    may wish to provide their own fail point trees), and
-    name is the name of the MIB in that tree, and
-    code is the error injection code. The
-    code argument does not require braces, but it is
-    considered good style to use braces for any multi-line code arguments.
-    Inside the code argument, the evaluation of
-    
-    is derived from the return() value set in the sysctl
-    MIB.

-
Additionally,
-    ()
-    provides a flags argument which controls the fail
-    point's behaviour. This can be used to e.g., mark the fail point's context
-    as non-sleepable, which causes the sleep action to be
-    coerced to a busy wait. The supported flags are:

-

-  
FAIL_POINT_USE_TIMEOUT_PATH

-  
Rather than sleeping on a sleep() call, just fire
-      the post-sleep function after a timeout fires.

-  
FAIL_POINT_NONSLEEPABLE

-  
Mark the fail point as being in a non-sleepable context, which coerces
-      sleep() calls to delay()
-      calls.

-

-
Likewise,
-    ()
-    supplies a cond argument, which allows you to set the
-    condition under which the fail point's code may fire. This is equivalent
-  to:

-

-
	if (cond)
-		KFAIL_POINT_CODE_FLAGS(...);
-
-

-

-See SYSCTL VARIABLES below.
-
The remaining
-    ()
-    macros are wrappers around common error injection paths:

-

-  
(parent,
-    name)

-  
is the equivalent of KFAIL_POINT_CODE(..., return
-      RETURN_VALUE)

-  
(parent,
-    name)

-  
is the equivalent of KFAIL_POINT_CODE(..., return)

-  
(parent,
-    name, error_var)

-  
is the equivalent of KFAIL_POINT_CODE(..., error_var =
-      RETURN_VALUE)

-  
(parent,
-    name, error_var,
-    label)

-  
is the equivalent of KFAIL_POINT_CODE(..., { error_var =
-      RETURN_VALUE; goto label;})

-

-
You can also introduce fail points by separating the declaration,
-    definition, and evaluation portions.

-

-  
(name)

-  
is used to declare the fail_point struct.

-  
(parent,
-    name, flags)

-  
defines and initializes the fail_point and sets up its
-      sysctl(9).

-  
(name,
-    code)

-  
is used at the point that the fail point is executed.

-

-

-

-

-
The KFAIL_POINT_*() macros add sysctl MIBs
-    where specified. Many base kernel MIBs can be found in the
-    
-    tree (referenced in code by DEBUG_FP).

-
The sysctl variable may be set in a number of ways:

-

-
  [<pct>%][<cnt>*]<type>[(args...)][-><more terms>]

-

-
The <type> argument specifies which action to take; it can
-    be one of:

-

-  

-  
Take no action (does not trigger fail point code)

-  

-  
Trigger fail point code with specified argument

-  

-  
Sleep the specified number of milliseconds

-  

-  
Panic

-  

-  
Break into the debugger, or trap if there is no debugger support

-  

-  
Print that the fail point executed

-  

-  
Threads sleep at the fail point until the fail point is set to
-      off

-  

-  
Thread yields the cpu when the fail point is evaluated

-  

-  
Similar to sleep, but busy waits the cpu. (Useful in non-sleepable
-      contexts.)

-

-
The <pct>% and <cnt>* modifiers prior to <type>
-    control when <type> is executed. The <pct>% form (e.g.
-    "1.2%") can be used to specify a probability that <type>
-    will execute. This is a decimal in the range (0, 100] which can specify up
-    to 1/10,000% precision. The <cnt>* form (e.g. "5*") can be
-    used to specify the number of times <type> should be executed before
-    this <term> is disabled. Only the last probability and the last count
-    are used if multiple are specified, i.e. "1.2%2%" is the same as
-    "2%". When both a probability and a count are specified, the
-    probability is evaluated before the count, i.e. "2%5*" means
-    "2% of the time, but only 5 times total".

-
The operator -> can be used to express cascading
-    terms. If you specify <term1>-><term2>, it means that if
-    <term1> does not ‘execute’,
-    <term2> is evaluated. For the purpose of this operator, the
-    ()
-    and print() operators are the only types that
-    cascade. A return() term only cascades if the code
-    executes, and a print() term only cascades when
-    passed a non-zero argument. A pid can optionally be specified. The fail
-    point term is only executed when invoked by a process with a matching
-  p_pid.

-

-

-

-

-  

-  
21/1000ths of the time, execute code with
-      RETURN_VALUE set to 5.

-  

-  
2/100ths of the time, execute code with RETURN_VALUE
-      set to 5. If that does not happen, 5% of the time execute
-      code with RETURN_VALUE set to 22.

-  

-  
For 5 times, return 5. After that, 1/1000th of the time, return 22.

-  

-  
Return 5 for 1 in 1000 executions, but only 5 times total.

-  

-  
1/100th of the time, sleep 50ms.

-  

-  
Return 5 once, when pid 1234 executes the fail point.

-

-

-

-

-
This manual page was written by

-
Matthew Bryan
-    <matthew.bryan@isilon.com>
-    and

-
Zach Loafman
-    <zml@FreeBSD.org>.

-

-

-

-
It is easy to shoot yourself in the foot by setting fail points
-    too aggressively or setting too many in combination. For example, forcing
-    malloc() to fail consistently is potentially harmful
-    to uptime.

-
The sleep()
-    sysctl setting may not be appropriate in all situations. Currently,
-    fail_point_eval() does not verify whether the
-    context is appropriate for calling msleep(). You can
-    force it to evaluate a sleep action as a
-    delay action by specifying the
-    
-    flag at the point the fail point is declared.

-

-

-
-  
-    
-    
-  
-
June 6, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/fdt_pinctrl.9 3.html b/static/freebsd/man9/fdt_pinctrl.9 3.html
deleted file mode 100644
index 4e0102b7..00000000
--- a/static/freebsd/man9/fdt_pinctrl.9 3.html	
+++ /dev/null
@@ -1,174 +0,0 @@
-
-  
-    
-    
-    
-  
-
fdt_pinctrl(9)Kernel Developer's Manualfdt_pinctrl(9)

-

-

-

-
fdt_pinctrl —
-    helper functions for FDT pinmux controller
-  drivers

-

-

-

-
#include
-    <dev/fdt/fdt_pinctrl.h>

-
int
-  

-  fdt_pinctrl_configure(device_t
-    client, u_int
-    index);

-
int
-  

-  fdt_pinctrl_configure_by_name(device_t
-    client, const char *
-    name);

-
int
-  

-  fdt_pinctrl_register(device_t
-    pinctrl, const char
-    *pinprop);

-
int
-  

-  fdt_pinctrl_configure_tree(device_t
-    pinctrl);

-

-

-

-
fdt_pinctrl(4) provides an API for manipulating
-    I/O pin configurations on pinmux controllers and pinmux clients. On the
-    controller side, the standard newbus probe and attach methods are
-    implemented. As part of handling attach, it calls the
-    ()
-    function to register itself as a pinmux controller. Then
-    fdt_pinctrl_configure_tree() is used to walk the
-    device tree and configure pins specified by the pinctrl-0 property for all
-    active devices. The driver also implements the
-    fdt_pinctrl_configure() method, which allows client
-    devices to change their pin configurations after startup. If a client device
-    requires a pin configuration change at some point of its lifecycle, it uses
-    the fdt_pinctrl_configure() or
-    fdt_pinctrl_configure_by_name() functions.

-
()
-    is used by client device client to request a pin
-    configuration described by the pinctrl-N property with index
-    index.

-
()
-    is used by client device client to request the pin
-    configuration with name name.

-
()
-    registers a pinctrl driver so that it can be used by other devices which
-    call fdt_pinctrl_configure() or
-    fdt_pinctrl_configure_by_name(). It also registers
-    each child node of the pinctrl driver's node which contains a property with
-    the name given in pinprop. If
-    pinprop is NULL, every
-    descendant node is registered. It is possible for the driver to register
-    itself as a pinmux controller for more than one pin property type by calling
-    fdt_pinctrl_register() multiple types.

-
()
-    walks through enabled devices in the device tree. If the pinctrl-0 property
-    contains references to child nodes of the specified pinctrl device, their
-    pins are configured.

-

-

-

-

-
static int
-foo_configure_pins(device_t dev, phandle_t cfgxref)
-{
-	phandle_t cfgnode;
-	uint32_t *pins, *functions;
-	int npins, nfunctions;
-
-	cfgnode = OF_node_from_xref(cfgxref);
-	pins = NULL;
-	npins = OF_getencprop_alloc_multi(cfgnode, "foo,pins", sizeof(*pins),
-	    (void **)&pins);
-	functions = NULL;
-	nfunctions = OF_getencprop_alloc_multi(cfgnode, "foo,functions",
-	    sizeof(*functions), (void **)&functions);
-	...
-}
-
-static int
-foo_is_gpio(device_t dev, device_t gpiodev, bool *is_gpio)
-{
-	return (foo_is_pin_func_gpio(is_gpio));
-}
-
-static int
-foo_set_flags(device_t dev, device_t gpiodev, uint32_t pin, uint32_t flags)
-{
-	int rv;
-
-	rv = foo_is_pin_func_gpio(is_gpio);
-	if (rv != 0)
-		return (rv);
-	foo_set_flags(pin, flags);
-	return (0);
-}
-
-static int
-foo_get_flags(device_t dev, device_t gpiodev, uint32_t pin, uint32_t *flags)
-{
-	int rv;
-
-	rv = foo_is_pin_func_gpio(is_gpio);
-	if (rv != 0)
-		return (rv);
-	foo_get_flags(pin, flags);
-	return (0);
-}
-
-static int
-foo_attach(device_t dev)
-{
-	...
-
-	fdt_pinctrl_register(dev, "foo,pins");
-	/*
-	 * It is possible to register more than one pinprop handler
-	 */
-	fdt_pinctrl_register(dev, "bar,pins");
-	fdt_pinctrl_configure_tree(dev);
-
-	return (0);
-}
-
-static device_method_t foo_methods[] = {
-	...
-
-	/* fdt_pinctrl interface */
-	DEVMETHOD(fdt_pinctrl_configure, foo_configure_pins),
-	DEVMETHOD(fdt_pinctrl_is_gpio, foo_is_gpio),
-	DEVMETHOD(fdt_pinctrl_set_flags, foo_set_flags),
-	DEVMETHOD(fdt_pinctrl_get_flags, foo_get_flags),
-
-	/* Terminate method list */
-	DEVMETHOD_END
-};
-
-DRIVER_MODULE(foo, simplebus, foo_driver, foo_devclass, NULL, NULL);

-

-

-

-

-
fdt_pinctrl(4)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko.

-

-

-
-  
-    
-    
-  
-
June 23, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/fetch.9 3.html b/static/freebsd/man9/fetch.9 3.html
deleted file mode 100644
index 05657272..00000000
--- a/static/freebsd/man9/fetch.9 3.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
FETCH(9)Kernel Developer's ManualFETCH(9)

-

-

-

-
fetch, fubyte,
-    fuword, fuword16,
-    fuword32, fuword64,
-    fueword, fueword32,
-    fueword64 — fetch data from
-    user-space

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
int
-  

-  fubyte(volatile
-    const void *base);

-
long
-  

-  fuword(volatile
-    const void *base);

-
int
-  

-  fuword16(volatile
-    const void *base);

-
int32_t
-  

-  fuword32(volatile
-    const void *base);

-
int64_t
-  

-  fuword64(volatile
-    const void *base);

-
int
-  

-  fueword(volatile
-    const void *base, long
-    *val);

-
int
-  

-  fueword32(volatile
-    const void *base, int32_t
-    *val);

-
int
-  

-  fueword64(volatile
-    const void *base, int64_t
-    *val);

-

-

-

-
The fetch functions are designed to copy
-    small amounts of data from user-space of the current process. If the user
-    address is naturally aligned, then the operation will be performed
-    atomically. Otherwise it may fail or be performed non-atomically, depending
-    on the platform.

-
The fetch routines provide the following
-    functionality:

-

-  
()

-  
Fetches a byte of data from the user-space address
-      base. The byte read is zero-extended into the
-      results variable.

-  
fuword()

-  
Fetches a word of data (long) from the user-space address
-      base.

-  
()

-  
Fetches 16 bits of data from the user-space address
-      base. The half-word read is zero-extended into the
-      results variable.

-  
fuword32()

-  
Fetches 32 bits of data from the user-space address
-      base.

-  
fuword64()

-  
Fetches 64 bits of data from the user-space address
-      base.

-  
()

-  
Fetches a word of data (long) from the user-space address
-      base and stores the result in the variable pointed
-      by val.

-  
()

-  
Fetches 32 bits of data from the user-space address
-      base and stores the result in the variable pointed
-      by val.

-  
()

-  
Fetches 64 bits of data from the user-space address
-      base and stores the result in the variable pointed
-      by val.

-

-
The callers of
-    (),
-    ()
-    and
-    ()
-    functions cannot distinguish between -1 read from userspace and function
-    failure.

-

-

-

-
The fubyte(),
-    fuword(), fuword16(),
-    fuword32(), and fuword64()
-    functions return the data fetched or -1 on failure. The
-    fueword(), fueword32() and
-    fueword64() functions return 0 on success and -1 on
-    failure.

-

-

-

-
copy(9), store(9)

-

-

-
-  
-    
-    
-  
-
July 22, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/firmware.9 3.html b/static/freebsd/man9/firmware.9 3.html
deleted file mode 100644
index 06e4ca52..00000000
--- a/static/freebsd/man9/firmware.9 3.html	
+++ /dev/null
@@ -1,319 +0,0 @@
-
-  
-    
-    
-    
-  
-
FIRMWARE(9)Kernel Developer's ManualFIRMWARE(9)

-

-

-

-
firmware_register,
-    firmware_unregister,
-    firmware_get,
-    firmware_get_flags,
-    firmware_put — firmware
-    image loading and management

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/linker.h>
-  

-  #include <sys/firmware.h>

-

-
struct firmware {
-	const char	*name;		/* system-wide name */
-	const void	*data;		/* location of image */
-	size_t		datasize;	/* size of image in bytes */
-	unsigned int	version;	/* version of the image */
-};

-

-

-const struct firmware *
-

-firmware_register(const char
-  *imagename, const void *data,
-  size_t datasize, unsigned int
-  version, const struct firmware *parent);
-
int
-  

-  firmware_unregister(const
-    char *imagename);

-
const struct firmware *
-  

-  firmware_get(const
-    char *imagename);

-
const struct firmware *
-  

-  firmware_get_flags(const
-    char *imagename, uint32_t
-    flags);

-
void
-  

-  firmware_put(const
-    struct firmware *fp, int
-    flags);

-

-

-

-
The firmware abstraction provides a
-    convenient interface for loading firmware images
-    into the kernel, and for accessing such images from kernel components.

-
A firmware image (or
-    image for brevity) is an opaque block of data
-    residing in kernel memory. It is associated to a unique
-    imagename which constitutes a search key, and to an
-    integer version number, which is also an opaque
-    piece of information for the firmware subsystem.

-
An image is registered with the
-    firmware subsystem by calling the function
-    (),
-    and unregistered by calling firmware_unregister().
-    These functions are usually (but not exclusively) called by specially
-    crafted kernel modules that contain the firmware image. The modules can be
-    statically compiled in the kernel, or loaded by
-    /boot/loader, manually at runtime, or on demand by
-    the firmware subsystem.

-
Firmware binary files may also be loaded directly rather than
-    embedded into kernel modules.

-
Clients of the firmware
-    subsystem can request access to a given image by calling the function
-    ()
-    with the imagename they want as an argument, or by
-    calling
-    ()
-    with the imagename and flags
-    they want as an arguments. If a matching image is not already registered,
-    the firmware subsystem will try to load it using the mechanisms specified
-    below (typically, a kernel module with
-    firmware_register the same name as the image).

-

-

-

-
The kernel firmware_register firmware API
-    is made of the following functions:

-
()
-    registers with the kernel an image of size datasize
-    located at address data, under the name
-    imagename.

-
The function returns NULL on error (e.g. because an image with the
-    same name already exists, or the image table is full), or a
-    const struct firmware * pointer to the image
-    requested.

-
()
-    tries to unregister the firmware image imagename
-    from the system. The function is successful and returns 0 if there are no
-    pending references to the image, otherwise it does not unregister the image
-    and returns EBUSY.

-
()
-    and
-    ()
-    return the requested firmware image. The flags
-    argument may be set to FIRMWARE_GET_NOWARN to
-    indicate that errors on firmware load or registration should only be logged
-    in case of booverbose. If the image is not yet
-    registered with the system, the functions try to load it. This involves the
-    linker subsystem and disk access, so firmware_get()
-    or firmware_get_flags() must not be called with any
-    locks (except for Giant). Note also that if the
-    firmware image is loaded from a filesystem it must already be mounted. In
-    particular this means that it may be necessary to defer requests from a
-    driver attach method unless it is known the root filesystem is already
-    mounted.

-
On success,
-    ()
-    and
-    ()
-    return a pointer to the image description and increase the reference count
-    for this image. On failure, the functions return NULL.

-
()
-    drops a reference to a firmware image. The flags
-    argument may be set to FIRMWARE_UNLOAD to indicate
-    that firmware_put is free to reclaim resources associated with the firmware
-    image if this is the last reference. By default a firmware image will be
-    deferred to a taskqueue(9) thread so the call may be done
-    while holding a lock. In certain cases, such as on driver detach, this
-    cannot be allowed.

-

-

-

-
As mentioned before, any component of the system can register
-    firmware images at any time by simply calling
-    firmware_register().

-
This is typically done when a module
-    containing a firmware image is given control, whether compiled in, or
-    preloaded by /boot/loader, or manually loaded with
-    kldload(8). However, a system can implement additional
-    mechanisms to bring these images into memory before calling
-    ().

-
When
-    ()
-    or
-    ()
-    does not find the requested image, it tries to load it using one of the
-    available loading mechanisms. At the moment, there is only one, namely
-    Loadable kernel modules.

-
A firmware image named foo is looked up by
-    trying to load the module named foo.ko, using the
-    facilities described in kld(4). In particular, images are
-    looked up in the directories specified by the sysctl variable
-    kern.module_path which on most systems defaults to
-    /boot/kernel;/boot/modules.

-
Note that in case a module contains multiple
-    images, the caller should first request a
-    ()
-    or
-    ()
-    for the first image contained in the module, followed by requests for the
-    other images.

-

-

-

-
A firmware module is built by embedding the
-    firmware image into a suitable loadable kernel
-    module that calls firmware_register() on loading,
-    and firmware_unregister() on unloading.

-
Various system scripts and makefiles let you build a module by
-    simply writing a Makefile with the following entries:

-

-
-        KMOD=   imagename
-        FIRMWS= image_file:imagename[:version]
-        .include <bsd.kmod.mk>
-
-

-

-where KMOD is the basename of the module; FIRMWS is a list of colon-separated
-  tuples indicating the image_file's to be embedded in the module, the imagename
-  and version of each firmware image.
-
If you need to embed firmware images into a system, you should
-    write appropriate entries in the <files.arch> or <files> file,
-    e.g. this example is from sys/conf/files

-

-
iwn1000fw.c			optional iwn1000fw | iwnfw		\
-	compile-with	"${AWK} -f $S/tools/fw_stub.awk iwn1000.fw:iwn1000fw -miwn1000fw -c${.TARGET}" \
-	no-ctfconvert no-implicit-rule before-depend local		\
-	clean		"iwn1000fw.c"
-#
-# NB: ld encodes the path in the binary symbols generated for the
-#     firmware image so link the file to the object directory to
-#     get known values for reference in the _fw.c file.
-#
-iwn1000fw.fwo			optional iwn1000fw | iwnfw		\
-	dependency	"iwn1000.fw"					\
-	compile-with	"${NORMAL_FWO}"					\
-	no-implicit-rule						\
-	clean		"iwn1000fw.fwo"

-

-
Firmware was previously committed to the source tree as uuencoded
-    files, but this is no longer required; the binary firmware file should be
-    committed to the tree as provided by the vendor.

-
Note that generating the firmware modules in this way requires the
-    availability of the following tools: awk(1),
-    make(1), the compiler and the linker.

-

-

-

-

-

-
Binary firmware files can also be loaded, either from
-    /boot/loader, or when
-    firmware_get cannot find the registered firmware
-    from a kernel module. Binary firmware files are raw binary files that the
-    creator of the firmware made. They offer an easier way to load firmware, but
-    one that lacks the full flexibility and generality of kernel modules with
-    the following restrictions:

-
    
-  
  • Binary firmware files only hold one set of firmware.
    • 
-  
  • They do not offer kernel module dependencies to ensure they are loaded
-      automatically by the boot loader.
    • 
-  
  • They cannot be compiled into the kernel.
    • 
-  
  • The imagename is identical to the full path name
-      used to load the module.
    • 
-  
  • The version number is assumed to be zero.
    • 
-

-

-

-

-
Binary firmware files may be loaded either from the command line
-    with “load -t firmware /boot/firmware/filename” or using the
-    loader.conf(5) mechanism to load modules with a type of
-    “firmware” For example

-

-
wififw_load="YES"
-wififw_name="/boot/firmware/wifi2034_fw.bin"
-wififw_type="firmware"

-

-

-

-

-
If no kernel module with an embedded firmware image named
-    imagename is loaded, then
-    imagename will be appended to the module path (by
-    default /boot/firmware/) and if that file exists, it
-    will be loaded and registered using
-    firmware_register using the full path to the
-    filename as imagename.

-

-

-

-
firmware_get uses the following algorithm
-    to find firmware images:

-
    
-  
  • If an existing firmware image is registered for
-      imagename, that image is returned.
    • 
-  
  • If imagename matches the trailing subpath of a
-      registered image with a full path, that image is returned.
    • 
-  
  • The kernel linker searches for a kernel module named
-      imagename. If a kernel module is found, it is
-      loaded, and the list of registered firmware images is searched again. If a
-      match is found, the matching image is returned.
    • 
-  
  • The kernel searches for a file named imagename in
-      the firmware image path (by default
-      /boot/firmware/). If that file exists and can be
-      read, it contents are registered as a firmware image with the full path as
-      the imagename and that firmware is returned.
-      Currently, there is an 8MB limit on the size of the firmware image. This
-      can be changed by by the sysctl variable
-      debug.max_firmware_size.
    • 
-

-

-

-

-

-
kld(4), module(9)

-
/boot/firmware

-
/usr/share/examples/kld/firmware

-

-

-

-
The firmware system was introduced in
-    FreeBSD 6.1. Binary firmware loading was introduced
-    in FreeBSD 15.0.

-

-

-

-
This manual page was written by Max Laier
-    <mlaier@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 25, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/fpu_kern.9 3.html b/static/freebsd/man9/fpu_kern.9 3.html
deleted file mode 100644
index 9d23f79c..00000000
--- a/static/freebsd/man9/fpu_kern.9 3.html	
+++ /dev/null
@@ -1,192 +0,0 @@
-
-  
-    
-    
-    
-  
-
FPU_KERN(9)Kernel Developer's ManualFPU_KERN(9)

-

-

-

-
fpu_kern —
-    facility to use the FPU in the kernel

-

-

-

-
#include
-    <machine/fpu.h>

-
struct fpu_kern_ctx *
-  

-  fpu_kern_alloc_ctx(u_int
-    flags);

-
void
-  

-  fpu_kern_free_ctx(struct
-    fpu_kern_ctx *ctx);

-
void
-  

-  fpu_kern_enter(struct
-    thread *td, struct
-    fpu_kern_ctx *ctx, u_int
-    flags);

-
int
-  

-  fpu_kern_leave(struct
-    thread *td, struct
-    fpu_kern_ctx *ctx);

-
int
-  

-  fpu_kern_thread(u_int
-    flags);

-
int
-  

-  is_fpu_kern_thread(u_int
-    flags);

-

-

-

-
The fpu_kern family of functions allows
-    the use of FPU hardware in kernel code. Modern FPUs are not limited to
-    providing hardware implementation for floating point arithmetic; they offer
-    advanced accelerators for cryptography and other computational-intensive
-    algorithms. These facilities share registers with the FPU hardware.

-
Typical kernel code does not need access to the FPU. Saving a
-    large register file on each entry to the kernel would waste time. When
-    kernel code uses the FPU, the current FPU state must be saved to avoid
-    corrupting the user-mode state, and vice versa.

-
The management of the save and restore is automatic. The processor
-    catches accesses to the FPU registers when the non-current context tries to
-    access them. Explicit calls are required for the allocation of the save area
-    and the notification of the start and end of the code using the FPU.

-
The
-    ()
-    function allocates the memory used by fpu_kern to
-    track the use of the FPU hardware state and the related software state. The
-    fpu_kern_alloc_ctx() function requires the
-    flags argument, which currently accepts the following
-    flags:

-

-

-  

-  
Do not wait for the available memory if the request could not be satisfied
-      without sleep.

-  
0

-  
No special handling is required.

-

-

-
The function returns the allocated context area, or
-    NULL if the allocation failed.

-
The
-    ()
-    function frees the context previously allocated by
-    fpu_kern_alloc_ctx().

-
The
-    ()
-    function designates the start of the region of kernel code where the use of
-    the FPU is allowed. Its arguments are:

-

-

-  
td

-  
Currently must be curthread.

-  
ctx

-  
The context save area previously allocated by
-      fpu_kern_alloc_ctx() and not currently in use by
-      another call to fpu_kern_enter().

-  
flags

-  
This argument currently accepts the following flags:
-    

-    

-      

-      
Indicates that the caller intends to access the full FPU state. Must
-          be specified currently.

-      

-      
Indicates that no saving of the current FPU state should be performed,
-          if the thread called fpu_kern_thread(9) function.
-          This is intended to minimize code duplication in callers which could
-          be used from both kernel thread and syscall contexts. The
-          fpu_kern_leave() function correctly handles
-          such contexts.

-      

-      
Avoid nesting save area. If the flag is specified, the
-          ctx must be passed as
-          NULL. The flag should only be used for really
-          short code blocks which can be executed in a critical section. It
-          avoids the need to allocate the FPU context by the cost of increased
-          system latency.

-    

-    

-  

-

-

-
The function does not sleep or block. It could cause an FPU trap
-    during execution, and on the first FPU access after the function returns, as
-    well as after each context switch. On i386 and amd64 this will be the
-    Device Not Available exception (see Intel Software
-    Developer Manual for the reference).

-
The
-    ()
-    function ends the region started by
-    fpu_kern_enter(). It is erroneous to use the FPU in
-    the kernel before fpu_kern_enter() or after
-    fpu_kern_leave(). The function takes the
-    td thread argument, which currently must be
-    curthread, and the ctx context
-    pointer, previously passed to fpu_kern_enter().
-    After the function returns, the context may be freed or reused by another
-    invocation of fpu_kern_enter(). The function always
-    returns 0.

-
The
-    ()
-    function enables an optimization for threads which never leave to the
-    usermode. The current thread will reuse the usermode save area for the
-    kernel FPU state instead of requiring an explicitly allocated context. There
-    are no flags defined for the function, and no error states that the function
-    returns. Once this function has been called, neither
-    fpu_kern_enter() nor
-    fpu_kern_leave() is required to be called and the
-    fpu is available for use in the calling thread.

-
The
-    ()
-    function returns the boolean indicating whether the current thread entered
-    the mode enabled by fpu_kern_thread(). There is
-    currently no flags defined for the function, the return value is true if the
-    current thread have the permanent FPU save area, and false otherwise.

-

-

-

-
The fpu_kern is currently implemented only
-    for the i386, amd64, arm64, and powerpc architectures.

-
There is no way to handle floating point exceptions raised from
-    kernel mode.

-
The unused flags arguments to the
-    fpu_kern functions are to be extended to allow
-    specification of the set of the FPU hardware state used by the code region.
-    This would allow optimizations of saving and restoring the state.

-

-

-

-
The fpu_kern facitily and this manual page
-    were written by Konstantin Belousov
-    <kib@FreeBSD.org>. The
-    arm64 support was added by
-  

-  Andrew Turner
-    <andrew@FreeBSD.org>.
-    The powerpc support was added by
-  

-  Shawn Anastasio
-    <sanastasio@raptorengineering.com>.

-

-

-

-
fpu_kern_leave() should probably have type
-    void (like
-  fpu_kern_enter()).

-

-

-
-  
-    
-    
-  
-
October 13, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/g_access.9 3.html b/static/freebsd/man9/g_access.9 3.html
deleted file mode 100644
index 9c60e98a..00000000
--- a/static/freebsd/man9/g_access.9 3.html	
+++ /dev/null
@@ -1,151 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_ACCESS(9)Kernel Developer's ManualG_ACCESS(9)

-

-

-

-
g_access — control
-    access to GEOM consumers and their providers

-

-

-

-
#include
-    <geom/geom.h>

-
int
-  

-  g_access(struct
-    g_consumer *cp, int
-    dcr, int dcw,
-    int dce);

-

-

-

-
The
-    ()
-    function allows to open, close, and generally change access to the provider
-    which is attached to the given consumer cp. The
-    arguments dcr, dcw, and
-    dce represent relative read, write, and exclusive
-    access count changes. Read and write access counts are self explanatory, and
-    exclusive access counts deny write access to other interested parties. A
-    provider's access count is the sum of the access counts of all attached
-    consumers.

-
After attaching a consumer to a provider with
-    g_attach(9), the
-    ()
-    function has to be called on the consumer before starting I/O requests.

-

-

-

-
The consumer has to be attached to a provider.

-
The intended change must not result in a negative access
-  count.

-
No-operation is not permitted (dcr =
-    dcw = dce =
-    0).

-
The provider's geom must have an access method defined (e.g.,
-    gp->access).

-
The topology lock has to be held.

-

-

-

-
The g_access() function returns 0 if
-    successful; otherwise an error code is returned. Note that
-    g_access() cannot fail when the arguments
-    dcr, dcw, and
-    dce are less than or equal to 0.

-

-

-

-
Create a consumer, attach it to a given provider, gain read access
-    and read first sector.

-

-
void
-some_function(struct g_geom *mygeom, struct g_provider *pp)
-{
-	struct g_consumer *cp;
-	void *ptr;
-	int error;
-
-	g_topology_assert();
-
-	/* Create new consumer on 'mygeom' geom. */
-	cp = g_new_consumer(mygeom);
-	/* Attach newly created consumer to given provider. */
-	if (g_attach(cp, pp) != 0) {
-		g_destroy_consumer(cp);
-		return;
-	}
-	/* Open provider for reading through our consumer. */
-	error = g_access(cp, 1, 0, 0);
-	if (error != 0) {
-		printf("Cannot access provider: %s\n", error);
-		g_detach(cp);
-		g_destroy_consumer(cp);
-		return;
-	}
-
-	/*
-	 * Don't hold topology lock while reading.
-	 */
-	g_topology_unlock();
-	ptr = g_read_data(cp, 0, pp->sectorsize, &error);
-	if (ptr == NULL)
-		printf("Error while reading: %d\n", error);
-	/*
-	 * Do something useful with data.
-	 */
-	g_topology_lock();
-
-	/* Disconnect from provider (release access count). */
-	g_access(cp, -1, 0, 0);
-	/* Detach from provider. */
-	g_detach(cp);
-	/* Destroy consumer. */
-	g_destroy_consumer(cp);
-}

-

-

-

-

-
Possible errors:

-

-  
[]

-  
The function is trying to open a provider with an exclusive access count,
-      but it is already open for writing.

-  
[]

-  
The function is trying to open a provider for writing, but it is already
-      exclusively open.

-

-
Any other error that can be returned by the provider's access
-    method.

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_attach(9),
-    g_bio(9), g_consumer(9),
-    g_data(9), g_event(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 16, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/g_attach.9 3.html b/static/freebsd/man9/g_attach.9 3.html
deleted file mode 100644
index 21fb0f5f..00000000
--- a/static/freebsd/man9/g_attach.9 3.html	
+++ /dev/null
@@ -1,139 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_ATTACH(9)Kernel Developer's ManualG_ATTACH(9)

-

-

-

-
g_attach, g_detach
-    — attach/detach GEOM consumers to/from
-    providers

-

-

-

-
#include
-    <geom/geom.h>

-
int
-  

-  g_attach(struct
-    g_consumer *cp, struct
-    g_provider *pp);

-
void
-  

-  g_detach(struct
-    g_consumer *cp);

-

-

-

-
The
-    ()
-    function attaches given consumer cp to given provider
-    pp, thus establishing a communication channel between
-    the consumer and the provider that allows to change access counts and
-    perform I/O operations.

-
The
-    ()
-    function detaches given consumer cp from its
-    corresponding provider, tearing down the communication channel between
-  them.

-

-

-

-
g_attach():

-
    
-  
  • The consumer must not be attached to a provider.
    • 
-  
  • The operation must not create a topology loop.
    • 
-  
  • The topology lock has to be held.
    • 
-

-
():

-
    
-  
  • The consumer has to be attached.
    • 
-  
  • The access count has to be 0.
    • 
-  
  • There must be no active requests.
    • 
-  
  • The topology lock has to be held.
    • 
-

-

-

-

-
The g_attach() function returns 0 if
-    successful; otherwise an error code is returned.

-

-

-

-
Create a consumer, attach it to a given provider, gain read access
-    and clean up.

-

-
void
-some_function(struct g_geom *mygeom, struct g_provider *pp)
-{
-	struct g_consumer *cp;
-
-	g_topology_assert();
-
-	/* Create new consumer on 'mygeom' geom. */
-	cp = g_new_consumer(mygeom);
-	/* Attach newly created consumer to given provider. */
-	if (g_attach(cp, pp) != 0) {
-		g_destroy_consumer(cp);
-		return;
-	}
-	/* Open provider for reading through our consumer. */
-	if (g_access(cp, 1, 0, 0) != 0) {
-		g_detach(cp);
-		g_destroy_consumer(cp);
-		return;
-	}
-
-	g_topology_unlock();
-	/*
-	 * Read data from provider.
-	 */
-	g_topology_lock();
-
-	/* Disconnect from provider (release access count). */
-	g_access(cp, -1, 0, 0);
-	/* Detach from provider. */
-	g_detach(cp);
-	/* Destroy consumer. */
-	g_destroy_consumer(cp);
-}

-

-

-

-

-
Possible errors:

-

-  
[]

-  
The operation creates a topology loop.

-  
[]

-  
Provider got orphaned.

-

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_bio(9), g_consumer(9),
-    g_data(9), g_event(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 10, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/g_bio.9 3.html b/static/freebsd/man9/g_bio.9 3.html
deleted file mode 100644
index fcd3ab31..00000000
--- a/static/freebsd/man9/g_bio.9 3.html	
+++ /dev/null
@@ -1,270 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_BIO(9)Kernel Developer's ManualG_BIO(9)

-

-

-

-
g_new_bio,
-    g_clone_bio, g_destroy_bio,
-    g_format_bio, g_print_bio,
-    g_reset_bio — GEOM bio
-    controlling functions

-

-

-

-
#include
-    <sys/bio.h>
-  

-  #include <geom/geom.h>

-
struct bio *
-  

-  g_new_bio(void);

-
struct bio *
-  

-  g_alloc_bio(void);

-
struct bio *
-  

-  g_clone_bio(struct
-    bio *bp);

-
struct bio *
-  

-  g_duplicate_bio(struct
-    bio *bp);

-
void
-  

-  g_destroy_bio(struct
-    bio *bp);

-
void
-  

-  g_format_bio(struct
-    sbuf *sb, const struct
-    bio *bp);

-
void
-  

-  g_print_bio(struct sbuf *sb,
-    const char *prefix, const struct bio
-    *bp, const char *fmtsuffix,
-    ...);

-
void
-  

-  g_reset_bio(struct
-    bio *bp);

-

-

-

-
A struct bio is used by GEOM to describe I/O
-    requests, its most important fields are described below:

-

-  
bio_cmd

-  
I/O request command. There are five I/O requests available in GEOM:
-    

-      

-      
A read request.

-      

-      
A write request.

-      

-      
Indicates that a certain range of data is no longer used and that it
-          can be erased or freed as the underlying technology supports.
-          Technologies like flash adaptation layers can arrange to erase the
-          relevant blocks before they will become reassigned and cryptographic
-          devices may want to fill random bits into the range to reduce the
-          amount of data available for attack.

-      

-      
Inspect and manipulate out-of-band attributes on a particular provider
-          or path. Attributes are named by ascii strings and are stored in the
-          bio_attribute field.

-      

-      
Tells underlying providers to flush their write caches.

-    

-  

-  
bio_flags

-  
Available flags:
-    

-      

-      
Request failed (error value is stored in
-          bio_error field).

-      

-      
Request finished.

-    

-  

-  
bio_cflags

-  
Private use by the consumer.

-  
bio_pflags

-  
Private use by the provider.

-  
bio_offset

-  
Offset into provider.

-  
bio_data

-  
Pointer to data buffer.

-  
bio_error

-  
Error value when BIO_ERROR is set.

-  
bio_done

-  
Pointer to function which will be called when the request is
-    finished.

-  
bio_driver1

-  
Private use by the provider.

-  
bio_driver2

-  
Private use by the provider.

-  
bio_caller1

-  
Private use by the consumer.

-  
bio_caller2

-  
Private use by the consumer.

-  
bio_attribute

-  
Attribute string for BIO_GETATTR request.

-  
bio_from

-  
Consumer to use for request (attached to provider stored in
-      bio_to field) (typically read-only for a
-    class).

-  
bio_to

-  
Destination provider (typically read-only for a class).

-  
bio_length

-  
Request length in bytes.

-  
bio_completed

-  
Number of bytes completed, but they may not be completed from the front of
-      the request.

-  
bio_children

-  
Number of bio clones (typically read-only for a
-      class).

-  
bio_inbed

-  
Number of finished bio clones.

-  
bio_parent

-  
Pointer to parent bio.

-

-
The
-    ()
-    function allocates a new, empty bio structure.

-
()
-    - same as g_new_bio(), but always succeeds
-    (allocates bio with the M_WAITOK malloc flag).

-
The
-    ()
-    function allocates a new bio structure and copies the
-    following fields from the bio given as an argument to
-    clone: bio_cmd, bio_length,
-    bio_offset, bio_data,
-    bio_attribute. The field
-    bio_parent in the clone points to the passed
-    bio and the field bio_children
-    in the passed bio is incremented.

-
This function should be used for every request which enters
-    through the provider of a particular geom and needs to be scheduled down.
-    Proper order is:

-

-
    
-  
  1. Clone the received struct bio.
    2. 
-  
  2. Modify the clone.
    3. 
-  
  3. Schedule the clone on its own consumer.
    4. 
-

-
()
-    - same as g_clone_bio(), but always succeeds
-    (allocates bio with the M_WAITOK malloc flag).

-
The
-    ()
-    function deallocates and destroys the given bio
-    structure.

-
The
-    ()
-    function prints information about the given bio
-    structure into the provided sbuf.

-
The
-    ()
-    function is a convenience wrapper around
-    g_format_bio() that can be used for debugging
-    purposes. It prints a provided prefix string, followed
-    by the formatted bio, followed by a
-    fmtsuffix in the style of printf(9).
-    Any of the prefix or suffix strings may be the empty string.
-    g_print_bio() always prints a newline character at
-    the end of the line.

-
The
-    ()
-    function resets the given bio structure back to its
-    initial state. g_reset_bio() preserves internal data
-    structures, while setting all user visible fields to their initial values.
-    When reusing a bio obtained from
-    g_new_bio(), g_alloc_bio(),
-    g_clone_bio(), or
-    g_duplicate_bio() for multiple transactions,
-    g_reset_bio() must be called between the
-    transactions in lieu of
-    ().
-    While not strictly required for a bio structure
-    created by other means, g_reset_bio() should be used
-    to initialize it and between transactions.

-

-

-

-
The g_new_bio() and
-    g_clone_bio() functions return a pointer to the
-    allocated bio, or NULL if an
-    error occurred.

-

-

-

-
Implementation of
-    “NULL-transformation”, meaning that an
-    I/O request is cloned and scheduled down without any modifications. Let us
-    assume that field ex_consumer in structure
-    example_softc contains a consumer attached to the
-    provider we want to operate on.

-

-
void
-example_start(struct bio *bp)
-{
-	struct example_softc *sc;
-	struct bio *cbp;
-
-	g_print_bio("Request received: ", bp, "");
-
-	sc = bp->bio_to->geom->softc;
-	if (sc == NULL) {
-		g_io_deliver(bp, ENXIO);
-		return;
-	}
-
-	/* Let's clone our bio request. */
-	cbp = g_clone_bio(bp);
-	if (cbp == NULL) {
-		g_io_deliver(bp, ENOMEM);
-		return;
-	}
-	cbp->bio_done = g_std_done;	/* Standard 'done' function. */
-
-	/* Ok, schedule it down. */
-	/*
-	 * The consumer can be obtained from
-	 * LIST_FIRST(&bp->bio_to->geom->consumer) as well,
-	 * if there is only one in our geom.
-	 */
-	g_io_request(cbp, sc->ex_consumer);
-}

-

-

-

-

-
dtrace_io(4), geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_consumer(9),
-    g_data(9), g_event(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 26, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/g_consumer.9 3.html b/static/freebsd/man9/g_consumer.9 3.html
deleted file mode 100644
index dbd9d284..00000000
--- a/static/freebsd/man9/g_consumer.9 3.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_CONSUMER(9)Kernel Developer's ManualG_CONSUMER(9)

-

-

-

-
g_new_consumer,
-    g_destroy_consumer — GEOM
-    consumers management

-

-

-

-
#include
-    <geom/geom.h>

-
struct g_consumer *
-  

-  g_new_consumer(struct
-    g_geom *gp);

-
void
-  

-  g_destroy_consumer(struct
-    g_consumer *cp);

-

-

-

-
A GEOM consumer is the backdoor through which a geom connects to
-    another GEOM provider and through which I/O requests are sent.

-
The
-    ()
-    function creates a new consumer on geom gp. Before
-    using the new consumer, it has to be attached to a provider with
-    g_attach(9) and opened with
-  g_access(9).

-
The
-    ()
-    function destroys the given consumer and cancels all related pending events.
-    This function is the last stage of killing an unwanted consumer.

-

-

-

-
g_new_consumer():

-
    
-  
  • The geom gp has to have an
-      orphan method defined.
    • 
-  
  • The topology lock has to be held.
    • 
-

-
():

-
    
-  
  • The consumer must not be attached to a provider.
    • 
-  
  • The access count has to be 0.
    • 
-  
  • The topology lock has to be held.
    • 
-

-

-

-

-
The g_new_consumer() function returns a
-    pointer to the newly created consumer.

-

-

-

-
Create consumer, attach it to given provider, gain read access and
-    clean up.

-

-
void
-some_function(struct g_geom *mygeom, struct g_provider *pp)
-{
-	struct g_consumer *cp;
-
-	g_topology_assert();
-
-	/* Create new consumer on 'mygeom' geom. */
-	cp = g_new_consumer(mygeom);
-	/* Attach newly created consumer to given provider. */
-	if (g_attach(cp, pp) != 0) {
-		g_destroy_consumer(cp);
-		return;
-	}
-	/* Open provider for reading through our consumer. */
-	if (g_access(cp, 1, 0, 0) != 0) {
-		g_detach(cp);
-		g_destroy_consumer(cp);
-		return;
-	}
-
-	g_topology_unlock();
-	/*
-	 * Read data from provider.
-	 */
-	g_topology_lock();
-
-	/* Disconnect from provider (release access count). */
-	g_access(cp, -1, 0, 0);
-	/* Detach from provider. */
-	g_detach(cp);
-	/* Destroy consumer. */
-	g_destroy_consumer(cp);
-}

-

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_data(9), g_event(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 16, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/g_data.9 3.html b/static/freebsd/man9/g_data.9 3.html
deleted file mode 100644
index 07a20eca..00000000
--- a/static/freebsd/man9/g_data.9 3.html	
+++ /dev/null
@@ -1,104 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_DATA(9)Kernel Developer's ManualG_DATA(9)

-

-

-

-
g_read_data,
-    g_write_data — read/write
-    data from/to GEOM consumer

-

-

-

-
#include
-    <geom/geom.h>

-
void *
-  

-  g_read_data(struct g_consumer
-    *cp, off_t offset, off_t
-    length, int *error);

-
int
-  

-  g_write_data(struct g_consumer
-    *cp, off_t offset, void
-    *ptr, off_t length);

-

-

-

-
The
-    ()
-    function reads length bytes of data from the provider
-    attached to consumer cp, starting at offset
-    offset. The buffer returned from
-    g_read_data() is allocated with
-    (),
-    so it should be freed by the caller with
-    ()
-    after use. If the operation fails, an error value will be stored in the
-    error argument if it is not
-    NULL.

-
The
-    ()
-    function writes length bytes of data from the buffer
-    pointed to by ptr to the provider attached to consumer
-    cp, starting at offset
-  offset.

-

-

-

-
The length argument should be a multiple of
-    the provider's sectorsize and less than or equal to
-    DFLTPHYS (DFLTPHYS is
-    defined in
-  <sys/param.h>).

-
The topology lock must not be held.

-

-

-

-
The g_read_data() function returns a
-    pointer to a data buffer or NULL if an error
-    occurred. In that case an error value is stored in the
-    error argument unless it is
-    NULL.

-
The g_write_data() function returns 0 if
-    successful; otherwise an error code is returned.

-

-

-

-
Possible errors:

-

-  
[]

-  
An I/O error occurred while reading from or writing to the consumer.

-  
[]

-  
Corrupted data was detected while reading from the consumer.

-

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_consumer(9), g_event(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 30, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/g_event.9 3.html b/static/freebsd/man9/g_event.9 3.html
deleted file mode 100644
index 22b26793..00000000
--- a/static/freebsd/man9/g_event.9 3.html	
+++ /dev/null
@@ -1,176 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_EVENT(9)Kernel Developer's ManualG_EVENT(9)

-

-

-

-
g_post_event,
-    g_waitfor_event,
-    g_cancel_event — GEOM events
-    management

-

-

-

-
#include
-    <geom/geom.h>

-
int
-  

-  g_post_event(g_event_t
-    *func, void *arg,
-    int flag,
-    ...);

-
int
-  

-  g_waitfor_event(g_event_t
-    *func, void *arg,
-    int flag,
-    ...);

-
void
-  

-  g_cancel_event(void
-    *ref);

-
struct g_event *
-  

-  g_alloc_event(int
-    flag);

-
void
-  

-  g_post_event_ep(g_event_t
-    *func, void *arg,
-    struct g_event *ep,
-    ...);

-

-

-

-
The GEOM framework has its own event queue to inform classes about
-    important events. The event queue can be also used by GEOM classes
-    themselves, for example to work around some restrictions in the I/O path,
-    where sleeping, heavy weight tasks, etc. are not permitted.

-
The
-    ()
-    function tells the GEOM framework to call function
-    func with argument arg from the
-    event queue. The flag argument is passed to
-    malloc(9) for memory allocations inside of
-    g_post_event(). The only allowed flags are
-    M_WAITOK and M_NOWAIT. The
-    rest of the arguments are used as references to identify the event. An event
-    can be canceled by using any of the given references as an argument to
-    g_cancel_event(). The list of references has to end
-    with a NULL value.

-
The
-    ()
-    function is a blocking version of the g_post_event()
-    function. It waits until the event is finished or canceled and then
-  returns.

-
The
-    ()
-    function posts the event with a pre-allocated struct
-    g_event. An event may be pre-allocated with
-    g_alloc_event().

-
The
-    ()
-    function cancels all event(s) identified by ref.
-    Cancellation is equivalent to calling the requested function with requested
-    arguments and argument flag set to
-    EV_CANCEL.

-

-

-

-
g_post_event():

-
    
-  
  • The argument flag has to be
-      M_WAITOK or M_NOWAIT.
    • 
-  
  • The list of references has to end with a NULL
-      value.
    • 
-

-
():

-
    
-  
  • The argument flag has to be
-      M_WAITOK or M_NOWAIT.
    • 
-  
  • The list of references has to end with a NULL
-      value.
    • 
-  
  • The g_waitfor_event() function cannot be called
-      from an event, since doing so would result in a deadlock.
    • 
-

-
():

-
    
-  
  • The argument flag has to be
-      M_WAITOK or M_NOWAIT.
    • 
-  
  • The returned struct g_event * must be
-      freed with
-      ()
-      if g_post_event_ep() is not called.
    • 
-

-

-

-

-
The g_post_event() and
-    g_waitfor_event() functions return 0 if successful;
-    otherwise an error code is returned.

-

-

-

-
Example of a function called from the event queue.

-

-
void
-example_event(void *arg, int flag)
-{
-
-	if (flag == EV_CANCEL) {
-		printf("Event with argument %p canceled.\n", arg);
-		return;
-	}
-
-	printf("Event with argument %p called.\n", arg);
-}

-

-

-

-

-
Possible errors for the g_post_event()
-    function:

-

-  
[]

-  
The flag argument was set to
-      M_NOWAIT and there was insufficient memory.

-

-
Possible errors for the g_waitfor_event()
-    function:

-

-  
[]

-  
The event was canceled.

-  
[]

-  
The flag argument was set to
-      M_NOWAIT and there was insufficient memory.

-

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_consumer(9), g_data(9),
-    g_geom(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 23, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/g_geom.9 3.html b/static/freebsd/man9/g_geom.9 3.html
deleted file mode 100644
index df3c6f34..00000000
--- a/static/freebsd/man9/g_geom.9 3.html	
+++ /dev/null
@@ -1,197 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_GEOM(9)Kernel Developer's ManualG_GEOM(9)

-

-

-

-
g_new_geomf,
-    g_new_geom, g_destroy_geom
-    — geom management

-

-

-

-
#include
-    <geom/geom.h>

-
struct g_geom *
-  

-  g_new_geomf(struct
-    g_class *mp, const char
-    *fmt, ...);

-
struct g_geom *
-  

-  g_new_geom(struct
-    g_class *mp, const char
-    *name);

-
void
-  

-  g_destroy_geom(struct
-    g_geom *gp);

-

-

-

-
The geom (do not confuse “geom” with
-    “GEOM”) is an instance of a GEOM class. For example: in a
-    typical i386 FreeBSD system, there will be one geom
-    of class MBR for each disk. The geom's name is not really important, it is
-    only used in the XML dump and for debugging purposes. There can be many
-    geoms with the same name.

-
The
-    ()
-    function creates a new geom, which will be an instance of the class
-    mp. The geom's name is created in a
-    printf(3)-like way from the rest of the arguments.

-
The
-    ()
-    function is very similar to g_new_geomf() except
-    that it accepts a regular string instead of a
-    printf(3)-like format string as the geom's name.

-
The
-    ()
-    function destroys the given geom immediately and cancels all related pending
-    events.

-
The g_geom structure contains fields that
-    should be set by the caller after geom creation, but before creating any
-    providers or consumers related to this geom (not all are required):

-

-

-  
g_start_t * start

-  
Pointer to a function used for I/O processing.

-  
g_spoiled_t * spoiled

-  
Pointer to a function used for consumers spoiling.

-  
g_dumpconf_t * dumpconf

-  
Pointer to a function used for configuration in XML format dumping.

-  
g_access_t * access

-  
Pointer to a function used for access control.

-  
g_orphan_t * orphan

-  
Pointer to a function used to inform about orphaned consumer.

-  
g_ioctl_t * ioctl

-  
Pointer to a function used for handling ioctl requests.

-  
void * softc

-  
Field for private use.

-

-

-

-

-

-
If you intend to use providers in this geom you must set field
-    start of your geom.

-
If you are planning to use consumers in your geom you must set
-    fields orphan and access for
-  it.

-
()
-    and g_new_geom():

-
    
-  
  • Class mp must be valid (registered in GEOM).
    • 
-  
  • The topology lock has to be held.
    • 
-

-
():

-
    
-  
  • The geom cannot possess any providers.
    • 
-  
  • The geom cannot possess any consumers.
    • 
-  
  • The topology lock has to be held.
    • 
-

-

-

-

-
The g_new_geomf() function returns a
-    pointer to the newly created geom.

-

-

-

-
Create an example geom.

-

-
static void
-g_example_start(struct bio *bp)
-{
-
-	[...]
-}
-
-static void
-g_example_orphan(struct g_consumer *cp)
-{
-
-	g_topology_assert();
-
-	[...]
-}
-
-static void
-g_example_spoiled(struct g_consumer *cp)
-{
-
-	g_topology_assert();
-
-	[...]
-}
-
-static int
-g_example_access(struct g_provider *pp, int dr, int dw, int de)
-{
-
-	[...]
-}
-
-static struct g_geom *
-create_example_geom(struct g_class *myclass)
-{
-	struct g_geom *gp;
-
-	g_topology_lock();
-	gp = g_new_geomf(myclass, "example_geom");
-	g_topology_unlock();
-	gp->start = g_example_start;
-	gp->orphan = g_example_orphan;
-	gp->spoiled = g_example_spoiled;
-	gp->access = g_example_access;
-	gp->softc = NULL;
-
-	return (gp);
-}
-
-static int
-destroy_example_geom(struct g_geom *gp)
-{
-
-	g_topology_lock();
-	if (!LIST_EMPTY(&gp->provider) ||
-	    !LIST_EMPTY(&gp->consumer)) {
-		g_topology_unlock();
-		return (EBUSY);
-	}
-	g_destroy_geom(gp);
-	g_topology_unlock();
-
-	return (0);
-}

-

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_consumer(9), g_data(9),
-    g_event(9), g_provider(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 24, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/g_provider.9 3.html b/static/freebsd/man9/g_provider.9 3.html
deleted file mode 100644
index 96d01924..00000000
--- a/static/freebsd/man9/g_provider.9 3.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_PROVIDER(9)Kernel Developer's ManualG_PROVIDER(9)

-

-

-

-
g_new_providerf,
-    g_destroy_provider,
-    g_error_provider — GEOM
-    providers management

-

-

-

-
#include
-    <geom/geom.h>

-
struct g_provider *
-  

-  g_new_providerf(struct
-    g_geom *gp, const char
-    *fmt, ...);

-
void
-  

-  g_destroy_provider(struct
-    g_provider *pp);

-
void
-  

-  g_error_provider(struct
-    g_provider *pp, int
-    error);

-

-

-

-
A GEOM provider is the front gate at which a geom offers service.
-    A provider is “a disk-like thing which appears in
-    /dev” – a logical disk in other words.
-    All providers have three main properties: name, sectorsize and size.

-
The
-    ()
-    function creates a new provider on given geom gp. The
-    name of the provider, which will appear as device in
-    devfs(4), is created in a printf(3)-like
-    way from the rest of the arguments. After creation, the caller has to set
-    the provider's mediasize and
-    sectorsize, as well as other desired initializations,
-    and then call g_error_provider() to reset the
-    provider's error, which is initially set to
-  ENXIO.

-
The
-    ()
-    function destroys the given provider, cancels all related pending events and
-    removes the corresponding devfs entry.

-
The
-    ()
-    function is used to set the provider's error value. If set to a nonzero, all
-    I/O requests will be denied, as well as increasing its access count will not
-    be possible (error error will be returned).

-

-

-

-
():

-
    
-  
  • The provider name should be unique, but this is not enforced by GEOM. If
-      the name is not unique, one will end up with two (or more) files with the
-      same name, which is a programmer error.
    • 
-  
  • The geom gp has to have a
-      start method defined.
    • 
-  
  • The topology lock has to be held.
    • 
-

-
():

-
    
-  
  • The provider must not have consumers attached.
    • 
-  
  • The access count has to be 0.
    • 
-  
  • The topology lock has to be held.
    • 
-

-

-

-

-
The g_new_providerf() function returns a
-    pointer to the newly created provider.

-

-

-

-
Create an example provider, set its parameters and make it
-  usable.

-

-
struct g_provider *
-create_example_provider(struct g_geom *gp)
-{
-	struct g_provider *pp;
-
-	g_topology_lock();
-	pp = g_new_providerf(gp, "example_provider");
-	g_topology_unlock();
-	pp->mediasize = 65536;
-	pp->sectorsize = 512;
-	g_error_provider(pp, 0);
-
-	return (pp);
-}

-

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_consumer(9), g_data(9),
-    g_event(9), g_geom(9),
-    g_provider_by_name(9),
-  g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 16, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/g_provider_by_name.9 4.html b/static/freebsd/man9/g_provider_by_name.9 4.html
deleted file mode 100644
index 34be0003..00000000
--- a/static/freebsd/man9/g_provider_by_name.9 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_PROVIDER_BY_NAME(9)Kernel Developer's ManualG_PROVIDER_BY_NAME(9)

-

-

-

-
g_provider_by_name —
-    find GEOM provider with given name

-

-

-

-
#include
-    <geom/geom.h>

-
struct g_provider *
-  

-  g_provider_by_name(const
-    char *name);

-

-

-

-
The
-    ()
-    function searches for a provider called name and
-    returns the structure g_provider bound to it. Argument
-    name can be a name or full path (i.e.,
-    “da0”, or
-    “/dev/da0”).

-

-

-

-
The topology lock has to be held.

-

-

-

-
The g_provider_by_name() function returns
-    a pointer to the provider called name or
-    NULL if there is no such provider.

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_consumer(9), g_data(9),
-    g_event(9), g_geom(9),
-    g_provider(9), g_wither_geom(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 29, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/g_wither_geom.9 3.html b/static/freebsd/man9/g_wither_geom.9 3.html
deleted file mode 100644
index db3affc3..00000000
--- a/static/freebsd/man9/g_wither_geom.9 3.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
G_WITHER_GEOM(9)Kernel Developer's ManualG_WITHER_GEOM(9)

-

-

-

-
g_wither_geom —
-    destroy geom and related providers and consumers when you
-    get a chance

-

-

-

-
#include
-    <geom/geom.h>

-
void
-  

-  g_wither_geom(struct
-    g_geom *gp, int
-    error);

-

-

-

-
The
-    ()
-    function tells GEOM that geom gp is to be destroyed.
-    GEOM sets an error on each provider of the given geom (in the orphaning
-    process) and waits for a chance to destroy the geom. If the access count of
-    any possessed consumer goes to 0, the consumer will be detached and
-    destroyed automatically. If the last consumer attached to any possessed
-    provider will be detached, the provider will be destroyed. If there are no
-    more providers nor consumers, the geom will be destroyed.

-
This is an automatic “garbage
-    collect” to avoid duplicated code in all classes. Before it is
-    called, field softc should be disposed of and set to
-    NULL. Note that the
-    ()
-    function gives no guarantee that the geom will be immediately destroyed,
-    mostly because the access counts of the geom's consumers and providers may
-    not be 0. That is why calling this function for every geom from a given
-    class is not enough to be sure that the class can be unloaded.

-

-

-

-
The argument error must be nonzero.

-
The topology lock has to be held.

-

-

-

-
geom(4),
-    DECLARE_GEOM_CLASS(9), g_access(9),
-    g_attach(9), g_bio(9),
-    g_consumer(9), g_data(9),
-    g_event(9), g_geom(9),
-    g_provider(9), g_provider_by_name(9)

-

-

-

-
This manual page was written by Pawel Jakub
-    Dawidek
-    <pjd@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 16, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/get_cyclecount.9 4.html b/static/freebsd/man9/get_cyclecount.9 4.html
deleted file mode 100644
index f12a259b..00000000
--- a/static/freebsd/man9/get_cyclecount.9 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
GET_CYCLECOUNT(9)Kernel Developer's ManualGET_CYCLECOUNT(9)

-

-

-

-
get_cyclecount —
-    get the CPU's fast counter register contents

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <machine/cpu.h>

-
uint64_t
-  

-  get_cyclecount(void);

-

-

-

-
The
-    ()
-    function uses a register available in most modern CPUs to return a value
-    that is monotonically increasing inside each CPU.

-
On SMP systems, there will be a number of separate monotonic
-    sequences, one for each CPU running. The value in the SMP case is selected
-    from one of these sequences, dependent on which CPU was scheduled to service
-    the request.

-
The speed and the maximum value of each
-    counter is CPU-dependent. Some CPUs (such as the Intel 80486) do not have
-    such a register, so
-    ()
-    on these platforms returns a (monotonic) combination of numbers represented
-    by the structure returned by binuptime(9).

-
The AMD64 and Intel 64 processors use the
-    TSC register.

-

-

-

-
binuptime(9)

-

-

-

-
The get_cyclecount() function first
-    appeared in FreeBSD 5.0.

-

-

-

-
This manual page was written by Mark
-    Murray
-    <markm@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 15, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/getenv.9 4.html b/static/freebsd/man9/getenv.9 4.html
deleted file mode 100644
index 889c8db7..00000000
--- a/static/freebsd/man9/getenv.9 4.html	
+++ /dev/null
@@ -1,231 +0,0 @@
-
-  
-    
-    
-    
-  
-
GETENV(9)Kernel Developer's ManualGETENV(9)

-

-

-

-
freeenv,
-    kern_getenv, getenv_int,
-    getenv_long, getenv_string,
-    getenv_quad, getenv_uint,
-    getenv_ulong, getenv_bool,
-    getenv_is_true,
-    getenv_is_false,
-    kern_setenv, testenv,
-    kern_unsetenv — kernel
-    environment variable functions

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  freeenv(char
-    *env);

-
char *
-  

-  kern_getenv(const
-    char *name);

-
int
-  

-  getenv_int(const
-    char *name, int
-    *data);

-
int
-  

-  getenv_long(const
-    char *name, long
-    *data);

-
int
-  

-  getenv_string(const
-    char *name, char
-    *data, int
-  size);

-
int
-  

-  getenv_quad(const
-    char *name, quad_t
-    *data);

-
int
-  

-  getenv_uint(const
-    char *name, unsigned int
-    *data);

-
int
-  

-  getenv_ulong(const
-    char *name, unsigned long
-    *data);

-
int
-  

-  getenv_bool(const
-    char *name, bool
-    *data);

-
bool
-  

-  getenv_is_true(const
-    char *name);

-
bool
-  

-  getenv_is_false(const
-    char *name);

-
int
-  

-  kern_setenv(const
-    char *name, const char
-    *value);

-
int
-  

-  testenv(const
-    char *name);

-
int
-  

-  kern_unsetenv(const
-    char *name);

-

-

-

-
These functions set, unset, fetch, and parse variables from the
-    kernel's environment.

-
The
-    ()
-    function obtains the current value of the kernel environment variable
-    name and returns a pointer to the string value. The
-    caller should not modify the string pointed to by the return value. The
-    kern_getenv() function may allocate temporary
-    storage, so the freeenv() function must be called to
-    release any allocated resources when the value returned by
-    kern_getenv() is no longer needed.

-
The
-    ()
-    function is used to release the resources allocated by a previous call to
-    kern_getenv(). The env
-    argument passed to freeenv() is the pointer returned
-    by the earlier call to kern_getenv(). Like
-    free(3), the env argument can be
-    NULL, in which case no action occurs.

-
The
-    ()
-    function inserts or resets the kernel environment variable
-    name to value. If the variable
-    name already exists, its value is replaced. This
-    function can fail if an internal limit on the number of environment
-    variables is exceeded.

-
The
-    ()
-    function deletes the kernel environment variable
-  name.

-
The
-    ()
-    function is used to determine if a kernel environment variable exists. It
-    returns a non-zero value if the variable name exists
-    and zero if it does not.

-
The
-    (),
-    (),
-    (),
-    (),
-    and
-    ()
-    functions look for a kernel environment variable name
-    and parse it as a signed integer, long integer, signed 64-bit integer,
-    unsigned integer, or an unsigned long integer, respectively. These functions
-    fail and return zero if name does not exist or if any
-    invalid characters are present in its value. On success, these function
-    store the parsed value in the integer variable pointed to by
-    data. If the parsed value overflows the integer type,
-    a truncated value is stored in data and zero is
-    returned. If the value begins with a prefix of “0x” it is
-    interpreted as hexadecimal. If it begins with a prefix of “0”
-    it is interpreted as octal. Otherwise, the value is interpreted as decimal.
-    The value may contain a single character suffix specifying a unit for the
-    value. The interpreted value is multiplied by the unit's magnitude before
-    being returned. The following unit suffixes are supported:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
k2^10
m2^20
g2^30
t2^40

-
The
-    ()
-    function stores a copy of the kernel environment variable
-    name in the buffer described by
-    data and size. If the variable
-    does not exist, zero is returned. If the variable exists, up to
-    size - 1 characters of its value are copied to the
-    buffer pointed to by data followed by a null character
-    and a non-zero value is returned.

-
The
-    ()
-    function interprets the value of the kernel environment variable
-    name as a boolean value by performing a
-    case-insensitive comparison against the strings "1",
-    "0", "true", and "false". If the environment
-    variable exists and has a valid boolean value, then that value will be
-    copied to the variable pointed to by data. If the
-    environment variable exists but is not a boolean value, then a warning will
-    be printed to the kernel message buffer. The
-    ()
-    and
-    ()
-    functions are wrappers around getenv_bool() that
-    simplify testing for a desired boolean value.

-

-

-

-
The kern_getenv() function returns a
-    pointer to an environment variable's value on success or
-    NULL if the variable does not exist.

-
The kern_setenv() and
-    kern_unsetenv() functions return zero on success and
-    -1 on failure.

-
The testenv() function returns zero if the
-    specified environment variable does not exist and a non-zero value if it
-    does exist.

-
The getenv_int(),
-    getenv_long(),
-    getenv_string(),
-    getenv_quad(),
-    getenv_uint(),
-    getenv_ulong(), and
-    getenv_bool() functions return a non-zero value on
-    success and zero on failure.

-
The getenv_is_true() and
-    getenv_is_false() functions return
-    true if the specified environment variable exists
-    and its value matches the desired boolean condition, and
-    false otherwise.

-

-

-
-  
-    
-    
-  
-
September 21, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/getnewvnode.9 4.html b/static/freebsd/man9/getnewvnode.9 4.html
deleted file mode 100644
index 2d14c2c8..00000000
--- a/static/freebsd/man9/getnewvnode.9 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
GETNEWVNODE(9)Kernel Developer's ManualGETNEWVNODE(9)

-

-

-

-
getnewvnode — get
-    a new vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  getnewvnode(const
-    char *tag, struct mount
-    *mp, struct vop_vector
-    *vops, struct vnode
-    **vpp);

-

-

-

-
The
-    ()
-    function initializes a new vnode, assigning it the vnode operations passed
-    in vops.

-
The arguments to
-    ()
-    are:

-

-  
tag

-  
The file system type string. This field should only be referenced for
-      debugging or for userland utilities.

-  
mp

-  
The mount point to add the new vnode to.

-  
vops

-  
The vnode operations to assign to the new vnode.

-  
vpp

-  
Points to the new vnode upon successful completion.

-

-

-

-

-
getnewvnode() returns 0 on success.

-

-

-

-
It never returns an error, instead either succeeds or blocks
-    indefinitely.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
November 1, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/gone_in.9 4.html b/static/freebsd/man9/gone_in.9 4.html
deleted file mode 100644
index 6cf83b16..00000000
--- a/static/freebsd/man9/gone_in.9 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
GONE_IN(9)Kernel Developer's ManualGONE_IN(9)

-

-

-

-
gone_in,
-    gone_in_dev — deprecation
-    notice functions

-

-

-

-
#include
-    <sys/systm.h>

-
void
-  

-  gone_in(int
-    major, const char
-    *msg, ...);

-
void
-  

-  gone_in_dev(device_t
-    dev, int major,
-    const char *msg,
-    ...);

-

-

-

-
The gone_in functions are used to provide
-    a notice that the kernel is actively using a driver or some other
-    functionality that is deprecated, and is planned for removal in a future
-    FreeBSD release. The notice is sent to the kernel
-    dmesg(8) log and will appear on the console. The
-    major argument specifies the major version of the
-    FreeBSD release that will remove the deprecated
-    functionality. The notice shall be printed only once, thus
-    gone_in functions are safe to use in often executed
-    code paths.

-
gone_in_dev will prepend driver name
-    before the notice.

-
In releases before major the provided notice
-    will be appended with “To be removed in FreeBSD
-    major”.

-

-

-

-

-
void
-example_api(foo_t *args)
-{
-	gone_in(16, "Warning! %s[%u] uses obsolete API. ",
-	    curthread->td_proc->p_comm, curthread->td_proc->p_pid);
-
-	/* API implementation omitted. */
-}
-
-int
-example_driver_attach(struct example_driver_softc *sc)
-{
-	/* Attach code omitted. */
-
-        gone_in_dev(sc->dev, 16, "driver is deprecated");
-}

-

-

-

-

-
The gone_in functions first appeared in
-    FreeBSD 11.

-

-

-
-  
-    
-    
-  
-
June 24, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/groupmember.9 4.html b/static/freebsd/man9/groupmember.9 4.html
deleted file mode 100644
index a3b9f6a0..00000000
--- a/static/freebsd/man9/groupmember.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
GROUPMEMBER(9)Kernel Developer's ManualGROUPMEMBER(9)

-

-

-

-
groupmember —
-    checks if credentials mandate some group
-  membership

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/ucred.h>

-
bool
-  

-  groupmember(gid_t
-    gid, const struct ucred
-    *cred);

-
bool
-  

-  realgroupmember(gid_t
-    gid, const struct ucred
-    *cred);

-

-

-

-
The
-    ()
-    function checks if credentials cred indicate that the
-    associated subject or object is a member of the group designated by the
-    group ID gid.

-
Considered groups in cred are the effective
-    and supplementary groups. The real group is not taken into account.

-
Function
-    ()
-    works the same except that it considers instead the real and supplementary
-    groups, and not the effective one.

-

-

-

-
The groupmember() and
-    realgroupmember() functions return
-    true if the given credentials indicate membership of
-    the group gid, or false
-    otherwise.

-

-

-

-
getgroups(2), setgroups(2)

-

-

-

-
This manual page was initially written by Chad
-    David
-    <davidc@acns.ab.ca>
-    and was revised by Olivier Certner
-    <olce.freebsd@certner.fr>.

-

-

-
-  
-    
-    
-  
-
October 31, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/hardclock.9 3.html b/static/freebsd/man9/hardclock.9 3.html
deleted file mode 100644
index 446d83ea..00000000
--- a/static/freebsd/man9/hardclock.9 3.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
HARDCLOCK(9)Kernel Developer's ManualHARDCLOCK(9)

-

-

-

-
hardclock —
-    real-time timer

-

-

-

-
void
-  

-  hardclock(int
-    cnt, int
-  usermode);

-

-

-

-
The
-    ()
-    function is called periodically based on pending work. The rate ranges from
-    hz times per second on a very busy system, to twice a
-    second on an idle system. The cnt argument reports an
-    estimate of the number of ticks since the last call. Over long timescales,
-    the average sum of cnt over one second is
-    hz. See hz(9) for important details
-    over shorter time scales. The usermode argument is
-    non-zero when hardclock() is called from an context
-    that interrupted usermode execution.

-
()
-    may perform different tasks such as:

-
    
-  
  • Run the current process's virtual and profile time (decrease the
-      corresponding timers, if they are activated, and generate
-      SIGVTALRM or SIGPROF,
-      respectively).
    • 
-  
  • Increment the time-of-day, taking care of any ntpd(8) or
-      adjtime(2) induced changes and leap seconds, as well as
-      any necessary compensations to keep in sync with PPS signals or external
-      clocks, if supported by the kernel.
    • 
-  
  • Schedule softclock interrupts (swi(9)) processing.
    • 
-  
  • Collect hwpmc(4) statistics.
    • 
-  
  • Do device polling, when enabled (see polling(4)).
    • 
-  
  • Implement software watchdog(9) processing.
    • 
-  
  • Enqueue epoch(9) processing.
    • 
-

-

-

-

-
adjtime(2), ntp_adjtime(2),
-    signal(3), hwpmc(4),
-    polling(4), ntpd(8),
-    epoch(9), eventtimers(9),
-    hz(9), swi(9),
-    watchdog(9)

-

-

-
-  
-    
-    
-  
-
February 27, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/hash.9 3.html b/static/freebsd/man9/hash.9 3.html
deleted file mode 100644
index 7c754137..00000000
--- a/static/freebsd/man9/hash.9 3.html	
+++ /dev/null
@@ -1,211 +0,0 @@
-
-  
-    
-    
-    
-  
-
HASH(9)Kernel Developer's ManualHASH(9)

-

-

-

-
hash, hash32,
-    hash32_buf, hash32_str,
-    hash32_strn, hash32_stre,
-    hash32_strne, jenkins_hash,
-    jenkins_hash32,
-    murmur3_32_hash,
-    murmur3_32_hash32 — general
-    kernel hashing functions

-

-

-

-
#include
-    <sys/hash.h>

-
uint32_t
-  

-  hash32_buf(const
-    void *buf, size_t
-    len, uint32_t
-    hash);

-
uint32_t
-  

-  hash32_str(const
-    void *buf, uint32_t
-    hash);

-
uint32_t
-  

-  hash32_strn(const
-    void *buf, size_t
-    len, uint32_t
-    hash);

-
uint32_t
-  

-  hash32_stre(const
-    void *buf, int end,
-    const char **ep,
-    uint32_t hash);

-
uint32_t
-  

-  hash32_strne(const
-    void *buf, size_t
-    len, int end,
-    const char **ep,
-    uint32_t hash);

-
uint32_t
-  

-  jenkins_hash(const
-    void *buf, size_t
-    len, uint32_t
-    hash);

-
uint32_t
-  

-  jenkins_hash32(const
-    uint32_t *buf, size_t
-    count, uint32_t
-    hash);

-
uint32_t
-  

-  murmur3_32_hash(const
-    void *buf, size_t
-    len, uint32_t
-    hash);

-
uint32_t
-  

-  murmur3_32_hash32(const
-    uint32_t *buf, size_t
-    count, uint32_t
-    hash);

-

-

-

-
The
-    ()
-    functions are used to give a consistent and general interface to a decent
-    hashing algorithm within the kernel. These functions can be used to hash
-    ASCII NUL terminated strings, as well as blocks of
-    memory.

-
A len argument is the length of the buffer
-    in bytes. A count argument is the length of the buffer
-    in 32-bit words.

-
The
-    ()
-    function is used as a general buffer hashing function. The argument
-    buf is used to pass in the location, and
-    len is the length of the buffer in bytes. The argument
-    hash is used to extend an existing hash, or is passed
-    the initial value HASHINIT to start a new hash.

-
The
-    ()
-    function is used to hash a NUL terminated string
-    passed in buf with initial hash value given in
-    hash.

-
The
-    ()
-    function is like the hash32_str() function, except
-    it also takes a len argument, which is the maximal
-    length of the expected string.

-
The
-    ()
-    and
-    ()
-    functions are helper functions used by the kernel to hash pathname
-    components. These functions have the additional termination condition of
-    terminating when they find a character given by end in
-    the string to be hashed. If the argument ep is not
-    NULL, it is set to the point in the buffer at which
-    the hash function terminated hashing.

-
The
-    ()
-    function has same semantics as the hash32_buf(), but
-    provides more advanced hashing algorithm with better distribution.

-
The
-    ()
-    uses same hashing algorithm as the jenkins_hash()
-    function, but works only on uint32_t sized arrays,
-    thus is simpler and faster. It accepts an array of
-    uint32_t values in its first argument and size of this
-    array in the second argument.

-
The
-    ()
-    and
-    ()
-    functions are similar to jenkins_hash() and
-    jenkins_hash32(), but implement the 32-bit version
-    of MurmurHash3.

-

-

-

-
The hash32() functions return a 32 bit
-    hash value of the buffer or string.

-

-

-

-

-
LIST_HEAD(head, cache) *hashtbl = NULL;
-u_long mask = 0;
-
-void
-sample_init(void)
-{
-
-        hashtbl = hashinit(numwanted, type, flags, &mask);
-}
-
-void
-sample_use(char *str, int len)
-{
-        uint32_t hash;
-
-        hash = hash32_str(str, HASHINIT);
-        hash = hash32_buf(&len, sizeof(len), hash);
-        hashtbl[hash & mask] = len;
-}

-

-

-

-

-
free(9), hashinit(9),
-    malloc(9)

-

-

-

-
The hash32() functions are only 32 bit
-    functions. They will prove to give poor 64 bit performance, especially for
-    the top 32 bits. At the current time, this is not seen as a great
-    limitation, as these hash values are usually used to index into an array.
-    Should these hash values be used for other means, this limitation should be
-    revisited.

-

-

-

-
The hash functions first appeared in
-    NetBSD 1.6. The current implementation of
-    hash32 functions was first committed to
-    OpenBSD 3.2, and later imported to
-    FreeBSD 6.1. The
-    jenkins_hash functions were added in
-    FreeBSD 10.0. The
-    murmur3_32_hash functions were added in
-    FreeBSD 10.1.

-

-

-

-
The hash32 functions were written by
-    Tobias Weingartner. The
-    jenkins_hash functions were written by
-  

-  Bob Jenkins. The
-    murmur3_32_hash functions were written by
-  

-  Dag-Erling Smørgrav
-    <des@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 30, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/hashalloc.9 3.html b/static/freebsd/man9/hashalloc.9 3.html
deleted file mode 100644
index c53cd5aa..00000000
--- a/static/freebsd/man9/hashalloc.9 3.html	
+++ /dev/null
@@ -1,253 +0,0 @@
-
-  
-    
-    
-    
-  
-
HASHALLOC(9)Kernel Developer's ManualHASHALLOC(9)

-

-

-

-
hashalloc,
-    hashfree — allocate and free
-    kernel hash tables

-

-

-

-
#include
-    <sys/malloc.h>
-  

-  #include <sys/hash.h>

-
void *
-  

-  hashalloc(struct
-    hashalloc_args *args);

-
void
-  

-  hashfree(void
-    *table, struct
-    hashalloc_args *args);

-

-

-

-
The
-    ()
-    and hashfree() functions provide a flexible kernel
-    programming interface (KPI) for allocating and freeing hash tables with
-    configurable bucket headers.

-
()
-    allocates memory for a hash table according to the parameters specified in
-    the args structure. It computes an appropriate number
-    of buckets (adjusting args->size as needed based on
-    the requested type), allocates memory using
-    malloc(9), initializes each bucket's queue header (e.g.,
-    LIST_HEAD, TAILQ_HEAD, etc.),
-    and, if requested, initializes per-bucket locks. The returned memory
-    allocation can be used as an array of header structures that start with
-    initialized list header of the requested type followed by initialized lock
-    of requested type.

-
()
-    frees a hash table previously allocated by
-    hashalloc().

-
Both functions require the caller to pass the same (or equivalent)
-    struct hashalloc_args that specifies the desired
-    configuration of the hash table and has the following members:

-

-
struct hashalloc_args {
-    /* Required arguments */
-    size_t  size;          /* in: desired buckets, out: allocated */
-    int     mflags;            /* malloc(9) flags */
-    struct malloc_type *mtype; /* malloc(9) type */
-    /* Optional arguments */
-    size_t  hdrsize;            /* bucket header size; 0 = auto */
-    enum {
-        HASH_TYPE_POWER2,
-        HASH_TYPE_PRIME,
-    }       type;               /* default HASH_TYPE_POWER2 */
-    enum {
-        HASH_HEAD_LIST,
-        HASH_HEAD_CK_LIST,
-        HASH_HEAD_SLIST,
-        HASH_HEAD_CK_SLIST,
-        HASH_HEAD_STAILQ,
-        HASH_HEAD_CK_STAILQ,
-        HASH_HEAD_TAILQ,
-    }       head;               /* default HASH_HEAD_LIST */
-    enum {
-        HASH_LOCK_NONE,
-        HASH_LOCK_MTX,
-        HASH_LOCK_RWLOCK,
-        HASH_LOCK_SX,
-        HASH_LOCK_RMLOCK,
-        HASH_LOCK_RMSLOCK,
-    }       lock;               /* default HASH_LOCK_NONE */
-    int     lopts;              /* lock init options */
-    const char *lname;          /* lock name */
-    int  (*ctor)(void *);	/* bucket constructor */
-    void (*dtor)(void *);	/* bucket destructor */
-    /* Returned arguments */
-    int error;                  /* error code in case of failure */
-};

-

-
Argument members size,
-    mflags and mtype are required
-    for the
-    ().
-    The argument size, as filled by earlier call to
-    hashalloc(), and mtype are
-    required for the hashfree(). The rest of arguments
-    are optional and have reasonable defaults. A hash table that was allocated
-    with a non-default allocation arguments shall pass the same arguments to
-    hashfree(). The structure shall be initialized with
-    sparse C99 initializer as it may contain opaque extension members. The
-    structure may be allocated on the stack of a caller.

-

-  
size

-  
Desired number of buckets for hashalloc(). Upon a
-      successful return hashalloc() sets this member to
-      the actual number allocated (may be rounded up to power-of-2 or nearest
-      prime). The value returned by hashalloc() shall be
-      later supplied to the hashfree().

-  
mflags, mtype

-  
Passed directly to malloc(9).

-  
hdrsize

-  
Optional member that allows the caller to set a different (increased) size
-      of a bucket header.

-  
type

-  
Bucket count policy:
-    

-      

-      
Rounded up to largest power of two less than or equal to argument
-          size.

-      

-      
Sized to the largest prime number less than or equal to argument
-          size.

-    

-    
Default is HASH_TYPE_POWER2.

-  

-  
head

-  
Queue header type for each bucket, a queue(3) or
-      Concurrency-kit (CK) type.
-    

-      

-      
queue(3) LIST_HEAD

-      

-      
Concurrency-kit CK_LIST_HEAD

-      

-      
queue(3) SLIST_HEAD

-      

-      
Concurrency-kit CK_SLIST_HEAD

-      

-      
queue(3) STAILQ_HEAD

-      

-      
Concurrency-kit CK_STAILQ_HEAD

-      

-      
queue(3) TAILQ_HEAD

-    

-    
Default is HASH_HEAD_LIST.

-  

-  
lock

-  
Synchronization:
-    

-      

-      
No per-bucket lock.

-      

-      
Per-bucket mutex(9).

-      

-      
Per-bucket rwlock(9).

-      

-      
Per-bucket sx(9).

-      

-      
Per-bucket rmlock(9).

-      

-      
Per-bucket sleepable (rms) rmlock(9).

-    

-    
Default is HASH_LOCK_NONE.

-  

-  
lopts

-  
Options passed to mtx_init(9),
-      rw_init(9), sx_init(9),
-      rm_init(9) or rms_init(9) (if locking
-      is enabled).

-  
lname

-  
Lock name. This member is required unless lock is
-      HASH_LOCK_NONE.

-  
ctor

-  
Optional constructor to be called by
-      ()
-      for each bucket after list header and lock initialization. May fail with
-      error code, yielding in a failure of
-    hashalloc().

-  
dtor

-  
Optional destructor to be called by hashfree() for
-      each bucket before lock destructors and list emptyness checks.

-

-

-

-

-
hashalloc() returns a pointer to the
-    allocated and initialized hash table on success, or
-    NULL on memory allocation failure or constructor
-    failure. The error member of
-    args is set to appropriate error code. When
-    mflags in args contain the
-    M_WAITOK flag and the ctor is
-    either NULL or never fails, then hashalloc() never
-    fails.

-

-

-

-
A simple mutex-protected hash table using TAILQ buckets:

-

-
struct bucket {
-    TAILQ_HEAD(, foo)   head;
-    struct mtx          lock;
-} *table;
-
-struct hashalloc_args args = {
-    .size    = 9000,
-    .mflags  = M_WAITOK,
-    .mtype   = M_FOO,
-    .head    = HASH_HEAD_TAILQ,
-    .lock    = HASH_LOCK_MTX,
-    .lopts   = MTX_DEF,
-    .lname   = "bucket of foo",
-};
-
-table = hashalloc(&args);
-/* Use table as array of struct bucket ... */
-mtx_lock(&table[hash].lock);
-TAILQ_INSERT_HEAD(&table[hash].head, foo, next);
-
-/* Later */
-hashfree(table, &args);

-

-

-

-

-
malloc(9), mutex(9),
-    rmlock(9), rwlock(9),
-    sx(9), queue(3)

-

-

-

-
The hashalloc KPI first appeared in
-    FreeBSD 16.0. It supersedes older interface
-    hashinit(), that was available since
-    4.4BSD, by offering greater control over the hash
-    table structure and locking strategy.

-

-

-

-
Gleb Smirnoff
-    <glebius@FreeBSD.org>

-

-

-
-  
-    
-    
-  
-
April 12, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/hashinit.9 3.html b/static/freebsd/man9/hashinit.9 3.html
deleted file mode 100644
index 3b29700f..00000000
--- a/static/freebsd/man9/hashinit.9 3.html	
+++ /dev/null
@@ -1,174 +0,0 @@
-
-  
-    
-    
-    
-  
-
HASHINIT(9)Kernel Developer's ManualHASHINIT(9)

-

-

-

-
hashinit,
-    hashinit_flags, hashdestroy,
-    phashinit, phashinit_flags
-    — manage kernel hash tables

-

-

-

-
#include
-    <sys/malloc.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/queue.h>

-
void *
-  

-  hashinit(int
-    nelements, struct
-    malloc_type *type, u_long
-    *hashmask);

-
void
-  

-  hashinit_flags(int nelements,
-    struct malloc_type *type, u_long
-    *hashmask, int flags);

-
void
-  

-  hashdestroy(void
-    *hashtbl, struct
-    malloc_type *type, u_long
-    hashmask);

-
void *
-  

-  phashinit(int
-    nelements, struct
-    malloc_type *type, u_long
-    *nentries);

-
phashinit_flags(int
-    nelements, struct
-    malloc_type *type, u_long
-    *nentries, int
-    flags);

-

-

-

-
This KPI is obsolete and scheduled for removal in
-    FreeBSD 17. Use hashalloc(9)
-    instead.

-

-

-

-
The
-    (),
-    hashinit_flags(),
-    phashinit() and
-    phashinit_flags() functions allocate space for hash
-    tables of size given by the argument nelements.

-
The
-    ()
-    function allocates hash tables that are sized to largest power of two less
-    than or equal to argument nelements. The
-    ()
-    function allocates hash tables that are sized to the largest prime number
-    less than or equal to argument nelements. The
-    hashinit_flags() function operates like
-    hashinit() but also accepts an additional argument
-    flags which control various options during allocation.
-    phashinit_flags() function operates like
-    phashinit() but also accepts an additional argument
-    flags which control various options during allocation.
-    Allocated hash tables are contiguous arrays of
-    LIST_HEAD(3) entries, allocated using
-    malloc(9), and initialized using
-    LIST_INIT(3). The malloc arena to be used for allocation
-    is pointed to by argument type.

-
The
-    ()
-    function frees the space occupied by the hash table pointed to by argument
-    hashtbl. Argument type
-    determines the malloc arena to use when freeing space. The argument
-    hashmask should be the bit mask returned by the call
-    to hashinit() that allocated the hash table. The
-    argument flags must be used with one of the following
-    values.

-

-

-

-  

-  
Any malloc performed by the
-      ()
-      and
-      ()
-      function will not be allowed to wait, and therefore may fail.

-  

-  
Any malloc performed by hashinit_flags() and
-      phashinit_flags() function is allowed to wait for
-      memory. This is also the behavior of hashinit()
-      and phashinit().

-

-

-

-

-

-
The largest prime hash value chosen by
-    phashinit() is 32749.

-

-

-

-
The hashinit() function returns a pointer
-    to an allocated hash table and sets the location pointed to by
-    hashmask to the bit mask to be used for computing the
-    correct slot in the hash table.

-
The phashinit() function returns a pointer
-    to an allocated hash table and sets the location pointed to by
-    nentries to the number of rows in the hash table.

-

-

-

-
A typical example is shown below:

-

-
...
-static LIST_HEAD(foo, foo) *footable;
-static u_long foomask;
-...
-footable = hashinit(32, M_FOO, &foomask);

-

-
Here we allocate a hash table with 32 entries from the malloc
-    arena pointed to by M_FOO. The mask for the
-    allocated hash table is returned in foomask. A
-    subsequent call to hashdestroy() uses the value in
-    foomask:

-

-
...
-hashdestroy(footable, M_FOO, foomask);

-

-

-

-

-
The hashinit() and
-    phashinit() functions will panic if argument
-    nelements is less than or equal to zero.

-
The hashdestroy() function will panic if
-    the hash table pointed to by hashtbl is not empty.

-

-

-

-
hashalloc(9), LIST_HEAD(3),
-    malloc(9)

-

-

-

-
There is no phashdestroy() function, and
-    using hashdestroy() to free a hash table allocated
-    by phashinit() usually has grave consequences.

-

-

-
-  
-    
-    
-  
-
March 17, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/hexdump.9 4.html b/static/freebsd/man9/hexdump.9 4.html
deleted file mode 100644
index f2df6903..00000000
--- a/static/freebsd/man9/hexdump.9 4.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
HEXDUMP(9)Kernel Developer's ManualHEXDUMP(9)

-

-

-

-
hexdump — dump a
-    block of bytes to the console in hexadecimal form

-

-

-

-
#include
-    <sys/systm.h>

-
void
-  

-  hexdump(void
-    *ptr, int length,
-    const char *hdr,
-    int flags);

-

-

-

-
The
-    ()
-    function prints an array of bytes to the console in hexadecimal form, along
-    with the ASCII representation of the bytes, if possible. By default, each
-    line of output will start with an offset count, followed by 16 hexadecimal
-    values, followed by 16 ASCII characters.

-

-  
ptr

-  
Pointer to the array of bytes to print. It does not need to be
-      NUL-terminated.

-  
length

-  
Number of bytes to print.

-  
hdr

-  
Pointer to a NUL-terminated character string that
-      will be prepended to each line of output. A value of
-      NULL implies that no header will be printed.

-  
flags

-  
Flags for controlling the formatting of the output.
-    

-      
Bits 0-7

-      
Integer value of the number of bytes to display on each line. A value
-          of 0 implies that the default value of 16 will be used.

-      
Bits 8-15

-      
Character ASCII value to use as the separator for the hexadecimal
-          output. A value of 0 implies that the default value of 32 (ASCII
-          space) will be used.

-      

-      
Do not print the offset column at the beginning of each line.

-      

-      
Do not print the hexadecimal values on each line.

-      

-      
Do not print the character values on each line.

-    

-  

-

-

-

-

-
ascii(7)

-

-

-

-
This manual page was written by Scott
-    Long.

-

-

-
-  
-    
-    
-  
-
December 7, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/hhook.9 3.html b/static/freebsd/man9/hhook.9 3.html
deleted file mode 100644
index 3d7bf97d..00000000
--- a/static/freebsd/man9/hhook.9 3.html	
+++ /dev/null
@@ -1,292 +0,0 @@
-
-  
-    
-    
-    
-  
-
HHOOK(9)Kernel Developer's ManualHHOOK(9)

-

-

-

-
hhook,
-    hhook_head_register,
-    hhook_head_deregister,
-    hhook_head_deregister_lookup,
-    hhook_run_hooks,
-    HHOOKS_RUN_IF,
-    HHOOKS_RUN_LOOKUP_IF —
-    Helper Hook Framework

-

-

-

-
#include
-    <sys/hhook.h>

-
typedef int
-  

-  (*hhook_func_t)(int32_t
-    hhook_type, int32_t
-    hhook_id, void
-    *udata, void
-    *ctx_data, void
-    *hdata, struct osd
-    *hosd);

-
int
-    hhook_head_register(int32_t
-    hhook_type, int32_t
-    hhook_id, struct
-    hhook_head **hhh,
-    uint32_t flags);

-
int
-    hhook_head_deregister(struct
-    hhook_head *hhh);

-
int
-    hhook_head_deregister_lookup(int32_t
-    hhook_type, int32_t
-    hhook_id);

-
void
-    hhook_run_hooks(struct
-    hhook_head *hhh, void
-    *ctx_data, struct osd
-    *hosd);

-
HHOOKS_RUN_IF(hhh,
-    ctx_data,
-    hosd);

-
HHOOKS_RUN_LOOKUP_IF(hhook_type,
-    hhook_id,
-    ctx_data,
-    hosd);

-

-

-

-
hhook provides a framework for managing
-    and running arbitrary hook functions at defined hook points within the
-    kernel. The KPI was inspired by pfil(9), and in many
-    respects can be thought of as a more generic superset of pfil.

-
The khelp(9) and hhook
-    frameworks are tightly integrated. Khelp is responsible for registering and
-    deregistering Khelp module hook functions with hhook
-    points. The KPI functions used by khelp(9) to do this are
-    not documented here as they are not relevant to consumers wishing to
-    instantiate hook points.

-

-

-
Khelp modules indirectly interact with
-    hhook by defining appropriate hook functions for
-    insertion into hook points. Hook functions must conform to the
-    hhook_func_t function pointer declaration outlined in
-    the SYNOPSIS.

-
The hhook_type and
-    hhook_id arguments identify the hook point which has
-    called into the hook function. These are useful when a single hook function
-    is registered for multiple hook points and wants to know which hook point
-    has called into it.
-    <sys/hhook.h> lists
-    available hhook_type defines and subsystems which
-    export hook points are responsible for defining the
-    hhook_id value in appropriate header files.

-
The udata argument will be passed to the
-    hook function if it was specified in the struct
-    hookinfo at hook registration time.

-
The ctx_data argument contains context
-    specific data from the hook point call site. The data type passed is
-    subsystem dependent.

-
The hdata argument is a pointer to the
-    persistent per-object storage allocated for use by the module if required.
-    The pointer will only ever be NULL if the module did not request per-object
-    storage.

-
The hosd argument can be
-    used with the khelp(9) framework's
-    ()
-    function to access data belonging to a different Khelp module.

-
Khelp modules instruct the Khelp framework to register their hook
-    functions with hhook points by creating a
-    struct hookinfo per hook point, which contains the
-    following members:

-

-
struct hookinfo {
-	hhook_func_t	hook_func;
-	struct helper	*hook_helper;
-	void		*hook_udata;
-	int32_t		hook_id;
-	int32_t		hook_type;
-};

-

-
Khelp modules are responsible for setting all members of the
-    struct except hook_helper which is handled by the
-    Khelp framework.

-

-

-

-
Kernel subsystems that wish to provide
-    hhook points typically need to make four and
-    possibly five key changes to their implementation:

-
    
-  
  • Define a list of hhook_id mappings in an appropriate
-      subsystem header.
    • 
-  
  • Register each hook point with the
-      ()
-      function during initialisation of the subsystem.
    • 
-  
  • Select or create a standardised data type to pass to hook functions as
-      contextual data.
    • 
-  
  • Add a call to HHOOKS_RUN_IF() or
-      HHOOKS_RUN_IF_LOOKUP() at the point in the
-      subsystem's code where the hook point should be executed.
    • 
-  
  • If the subsystem can be dynamically added/removed at runtime, each hook
-      point registered with the hhook_head_register()
-      function when the subsystem was initialised needs to be deregistered with
-      the hhook_head_deregister() or
-      hhook_head_deregister_lookup() functions when the
-      subsystem is being deinitialised prior to removal.
    • 
-

-
The
-    ()
-    function registers a hook point with the hhook
-    framework. The hook_type argument defines the high
-    level type for the hook point. Valid types are defined in
-    <sys/hhook.h> and new types
-    should be added as required. The hook_id argument
-    specifies a unique, subsystem specific identifier for the hook point. The
-    hhh argument will, if not NULL, be used to store a
-    reference to the struct hhook_head created as part of
-    the registration process. Subsystems will generally want to store a local
-    copy of the struct hhook_head so that they can use the
-    HHOOKS_RUN_IF() macro to instantiate hook points.
-    The HHOOK_WAITOK flag may be passed in via the flags
-    argument if malloc(9) is allowed to sleep waiting for
-    memory to become available. If the hook point is within a virtualised
-    subsystem (e.g. the network stack), the HHOOK_HEADISINVNET flag should be
-    passed in via the flags argument so that the
-    struct hhook_head created during the registration
-    process will be added to a virtualised list.

-
The
-    ()
-    function deregisters a previously registered hook point from the
-    hhook framework. The hhh
-    argument is the pointer to the struct hhook_head
-    returned by
-    ()
-    when the hook point was registered.

-
The
-    ()
-    function can be used instead of
-    hhook_head_deregister() in situations where the
-    caller does not have a cached copy of the struct
-    hhook_head and wants to deregister a hook point using the appropriate
-    hook_type and hook_id
-    identifiers instead.

-
The
-    ()
-    function should normally not be called directly and should instead be called
-    indirectly via the HHOOKS_RUN_IF() macro. However,
-    there may be circumstances where it is preferable to call the function
-    directly, and so it is documented here for completeness. The
-    hhh argument references the
-    hhook point to call all registered hook functions
-    for. The ctx_data argument specifies a pointer to the
-    contextual hook point data to pass into the hook functions. The
-    hosd argument should be the pointer to the appropriate
-    object's struct osd if the subsystem provides the
-    ability for Khelp modules to associate per-object data. Subsystems which do
-    not should pass NULL.

-
The
-    ()
-    macro is the preferred way to implement hook points. It only calls the
-    hhook_run_hooks() function if at least one hook
-    function is registered for the hook point. By checking for registered hook
-    functions, the macro minimises the cost associated with adding hook points
-    to frequently used code paths by reducing to a simple if test in the common
-    case where no hook functions are registered. The arguments are as described
-    for the hhook_run_hooks() function.

-
The
-    ()
-    macro performs the same function as the
-    HHOOKS_RUN_IF() macro, but performs an additional
-    step to look up the struct hhook_head for the
-    specified hook_type and hook_id
-    identifiers. It should not be used except in code paths which are
-    infrequently executed because of the reference counting overhead associated
-    with the look up.

-

-

-

-

-
Each struct hhook_head protects its internal
-    list of hook functions with a rmlock(9). Therefore,
-    anytime hhook_run_hooks() is called directly or
-    indirectly via the HHOOKS_RUN_IF() or
-    HHOOKS_RUN_IF_LOOKUP() macros, a non-sleepable read
-    lock will be acquired and held across the calls to all registered hook
-    functions.

-

-

-

-
hhook_head_register() returns 0 if no
-    errors occurred. It returns EEXIST if a hook point with the same
-    hook_type and hook_id is already
-    registered. It returns EINVAL if the HHOOK_HEADISINVNET flag is not set in
-    flags because the implementation does not yet support
-    hook points in non-virtualised subsystems (see the
-    BUGS section for details). It returns ENOMEM
-    if malloc(9) failed to allocate memory for the new
-    struct hhook_head.

-
hhook_head_deregister() and
-    hhook_head_deregister_lookup() return 0 if no errors
-    occurred. They return ENOENT if hhh is NULL. They
-    return EBUSY if the reference count of hhh is greater
-    than one.

-

-

-

-
A well commented example Khelp module can be found at:
-    /usr/share/examples/kld/khelp/h_example.c

-
The tcp(4) implementation provides two
-    hhook points which are called for packets
-    sent/received when a connection is in the established phase. Search for
-    HHOOK in the following files: sys/netinet/tcp_var.h,
-    sys/netinet/tcp_input.c,
-    sys/netinet/tcp_output.c and
-    sys/netinet/tcp_subr.c.

-

-

-

-
khelp(9)

-

-

-

-
Development and testing of this software were made possible in
-    part by grants from the FreeBSD Foundation and Cisco University Research
-    Program Fund at Community Foundation Silicon Valley.

-

-

-

-
The hhook framework first appeared in
-    FreeBSD 9.0.

-
The hhook framework was first released in
-    2010 by Lawrence Stewart whilst studying at Swinburne University of
-    Technology's Centre for Advanced Internet Architectures, Melbourne,
-    Australia. More details are available at:

-
http://caia.swin.edu.au/urp/newtcp/

-

-

-

-
The hhook framework was written by
-    Lawrence Stewart
-    <lstewart@FreeBSD.org>.

-
This manual page was written by David
-    Hayes
-    <david.hayes@ieee.org>
-    and Lawrence Stewart
-    <lstewart@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 21, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/hz.9 3.html b/static/freebsd/man9/hz.9 3.html
deleted file mode 100644
index fdc35443..00000000
--- a/static/freebsd/man9/hz.9 3.html	
+++ /dev/null
@@ -1,115 +0,0 @@
-
-  
-    
-    
-    
-  
-
HZ(9)Kernel Developer's ManualHZ(9)

-

-

-

-
hz, tick,
-    stathz, profhz —
-    system time model

-

-

-

-
#include
-    <sys/kernel.h>

-

-  

-  extern int hz;
-  

-  extern int tick;
-  

-  extern int stathz;
-  

-  extern int profhz; /* deprecated */

-

-

-

-
FreeBSD utilizes periodic, one-shot,
-    global or per-CPU timing hardware using eventtimers(9) to
-    produce traditional clock behavior. These clocks regulate periodic events in
-    the system.

-
The main clock is used to update the system's notion of time via
-    timecounters(9) and to pace periodic system processing as
-    documented in hardclock(9). That routine may be called
-    once every 1 / hz seconds, though the call is omitted
-    if no work is needed in the next tick and it has not been 0.5 seconds since
-    the last call.

-
The stat clock running at stathz gathers
-    statistics on the system and its processes. It computes values for
-    getrusage(2) and statistics displayed by
-    ps(1) and top(1).

-
Finally, a profiling clock may run at profhz
-    to sample user program counter values for profiling purposes. This profiling
-    mechanism has been replaced by the more functional
-    hwpmc(4) and may be removed in a future version of
-    FreeBSD.

-
tick is the length of time in microseconds
-    of one system tick.

-
These system variables are also available as
-    
-    from sysctl(3) and
-    
-    from sysctl(8).

-
The current global and per-CPU CPU time usage is
-    returned to the user in units of 1 / stathz ticks in
-    the
-    
-    and
-    
-    sysctl MIBs.

-
The hz rate may be overridden
-    by defining HZ in the kernel configuration file or
-    setting 
-    system tuneable via loader.conf(5).

-
The current default is 1000 Hz for a tick of 1 ms for real
-    hardware. For virtual machine guests, the default is 100 Hz for a tick of 10
-    ms. Only override the default value if you really know what you are doing.
-    Due to the adaptive nature of timeouts, changing this value has less effect
-    than it had in the past.

-

-

-

-
ps(1), top(1),
-    setitimer(2), timer_settime(2),
-    loader.conf(5), eventtimers(9),
-    hardclock(9), microtime(9),
-    time_second(9), timecounters(9)

-

-

-

-
Historically, both the stathz and
-    profhz clocks have run off the same physical timer
-    running at the slower rate when no process is using the profile features, or
-    at the higher rate when at least one process is using it. Although the
-    interface is deprecated by IEEE Std 1003.1-2008
-    (“POSIX.1”) in favor of
-    timer_settime(2), several programs still use
-    setitimer(2) and ITIMER_PROF for a
-    higher-resolution periodic interrupt than has been traditionally
-  available.

-
Historically, hardclock(9) has also been run off
-    a separate interrupt, except on constrained platforms that lack enough
-    periodic interrupt sources. FreeBSD uses
-    eventtimers(9) to abstract these details away, though some
-    old code may still harbor assumptions that are an imperfect fit to this
-    abstraction.

-
timecounters(9) are limited to 32-bits and wrap
-    after about a second, so we must update the time hands they maintain at
-    least every half second to get the proper wrapping math. In addition,
-    kern.cp_times needs to updated at least once a second
-    so that the values displayed by top(1) update every
-    second.

-

-

-
-  
-    
-    
-  
-
July 1, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211.9 3.html b/static/freebsd/man9/ieee80211.9 3.html
deleted file mode 100644
index 7c8c3714..00000000
--- a/static/freebsd/man9/ieee80211.9 3.html	
+++ /dev/null
@@ -1,568 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211(9)Kernel Developer's ManualIEEE80211(9)

-

-

-

-
IEEE80211 — 802.11
-    network layer

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-
void
-  

-  ieee80211_ifattach(struct
-    ieee80211com *ic);

-
void
-  

-  ieee80211_ifdetach(struct
-    ieee80211com *ic);

-
int
-  

-  ieee80211_mhz2ieee(u_int
-    freq, u_int
-  flags);

-
int
-  

-  ieee80211_chan2ieee(struct
-    ieee80211com *ic, const
-    struct ieee80211_channel *c);

-
u_int
-  

-  ieee80211_ieee2mhz(u_int
-    chan, u_int
-  flags);

-
int
-  

-  ieee80211_media_change(struct
-    ifnet *ifp);

-
void
-  

-  ieee80211_media_status(struct
-    ifnet *ifp, struct
-    ifmediareq *imr);

-
int
-  

-  ieee80211_setmode(struct
-    ieee80211com *ic, enum
-    ieee80211_phymode mode);

-
enum ieee80211_phymode
-  

-  ieee80211_chan2mode(const struct
-    ieee80211_channel *chan);

-
int
-  

-  ieee80211_rate2media(struct
-    ieee80211com *ic, int rate, enum
-    ieee80211_phymode mode);

-
int
-  

-  ieee80211_media2rate(int
-    mword);

-

-

-

-
IEEE 802.11 device drivers are written to use the infrastructure
-    provided by the IEEE80211 software layer. This
-    software provides a support framework for drivers that includes ifnet
-    cloning, state management, and a user management API by which applications
-    interact with 802.11 devices. Most drivers depend on the
-    IEEE80211 layer for protocol services but devices
-    that off-load functionality may bypass the layer to connect directly to the
-    device.

-
A IEEE80211 device driver implements a
-    virtual radio API that is exported to users through network interfaces (aka
-    vaps) that are cloned from the underlying device. These interfaces have an
-    operating mode (station, adhoc, hostap, wds, monitor, etc.) that is fixed
-    for the lifetime of the interface. Devices that can support multiple
-    concurrent interfaces allow multiple vaps to be cloned. This enables
-    construction of interesting applications such as an AP vap and one or more
-    WDS vaps or multiple AP vaps, each with a different security model. The
-    IEEE80211 layer virtualizes most 802.11 state and
-    coordinates vap state changes including scheduling multiple vaps. State that
-    is not virtualized includes the current channel and WME/WMM parameters.
-    Protocol processing is typically handled entirely in the
-    IEEE80211 layer with drivers responsible purely for
-    moving data between the host and device. Similarly,
-    IEEE80211 handles most ioctl(2)
-    requests without entering the driver; instead drivers are notified of state
-    changes that require their involvement.

-
The virtual radio interface defined by the
-    IEEE80211 layer means that drivers must be
-    structured to follow specific rules. Drivers that support only a single
-    interface at any time must still follow these rules.

-
Most of these functions require that attachment to the stack is
-    performed before calling.

-
The
-    ()
-    function attaches the wireless network interface ic to
-    the 802.11 network stack layer. This function must be called before using
-    any of the IEEE80211 functions which need to store
-    driver state across invocations.

-
The
-    ()
-    function frees any IEEE80211 structures associated
-    with the driver, and performs Ethernet and BPF detachment on behalf of the
-    caller.

-
The
-    ()
-    utility function converts the frequency freq
-    (specified in MHz) to an IEEE 802.11 channel number. The
-    flags argument is a hint which specifies whether the
-    frequency is in the 2GHz ISM band
-    (IEEE80211_CHAN_2GHZ) or the 5GHz band
-    (IEEE80211_CHAN_5GHZ); appropriate clipping of the
-    result is then performed.

-
The
-    ()
-    function converts the channel specified in *c to an
-    IEEE channel number for the driver ic. If the
-    conversion would be invalid, an error message is printed to the system
-    console. This function REQUIRES that the driver is hooked up to the
-    IEEE80211 subsystem.

-
The
-    ()
-    utility function converts the IEEE channel number chan
-    to a frequency (in MHz). The flags argument is a hint
-    which specifies whether the frequency is in the 2GHz ISM band
-    (IEEE80211_CHAN_2GHZ) or the 5GHz band
-    (IEEE80211_CHAN_5GHZ); appropriate clipping of the
-    result is then performed.

-
The
-    ()
-    and
-    ()
-    functions are device-independent handlers for ifmedia
-    commands and are not intended to be called directly.

-
The
-    ()
-    function is called from within the 802.11 stack to change the mode of the
-    driver's PHY; it is not intended to be called directly.

-
The
-    ()
-    function returns the PHY mode required for use with the channel
-    chan. This is typically used when selecting a rate
-    set, to be advertised in beacons, for example.

-
The
-    ()
-    function converts the bit rate rate (measured in units
-    of 0.5Mbps) to an ifmedia sub-type, for the device
-    ic running in PHY mode mode. The
-    ()
-    performs the reverse of this conversion, returning the bit rate (in 0.5Mbps
-    units) corresponding to an ifmedia sub-type.

-

-

-

-
The virtual radio architecture splits state between a single
-    per-device ieee80211com structure and one or more
-    ieee80211vap structures. Drivers are expected to setup
-    various shared state in these structures at device attach and during vap
-    creation but otherwise should treat them as read-only. The
-    ieee80211com structure is allocated by the
-    IEEE80211 layer as adjunct data to a device's
-    ifnet; it is accessed through the
-    if_l2com structure member. The
-    ieee80211vap structure is allocated by the driver in
-    the “vap create” method and should be extended with any
-    driver-private state. This technique of giving the driver control to
-    allocate data structures is used for other IEEE80211
-    data structures and should be exploited to maintain driver-private state
-    together with public IEEE80211 state.

-
The other main data structures are the station, or node, table
-    that tracks peers in the local BSS, and the channel table that defines the
-    current set of available radio channels. Both tables are bound to the
-    ieee80211com structure and shared by all vaps.
-    Long-lasting references to a node are counted to guard against premature
-    reclamation. In particular every packet sent/received holds a node reference
-    (either explicitly for transmit or implicitly on receive).

-
The ieee80211com and
-    ieee80211vap structures also hold a collection of
-    method pointers that drivers fill-in and/or override to take control of
-    certain operations. These methods are the primary way drivers are bound to
-    the IEEE80211 layer and are described below.

-

-

-

-
Drivers attach to the IEEE80211 layer with
-    the
-    ()
-    function. The driver is expected to allocate and setup any device-private
-    data structures before passing control. The
-    ieee80211com structure must be pre-initialized with
-    state required to setup the IEEE80211 layer:

-

-  

-  
Backpointer to the physical device's ifnet.

-  

-  
Device/driver capabilities; see below for a complete description.

-  

-  
Table of channels the device is capable of operating on. This is initially
-      provided by the driver but may be changed through calls that change the
-      regulatory state.

-  

-  
Number of entries in ic_channels.

-

-
On return from
-    ()
-    the driver is expected to override default callback functions in the
-    ieee80211com structure to register it's private
-    routines. Methods marked with a “*” must be provided by the
-    driver.

-

-  

-  
Create a vap instance of the specified type (operating mode). Any fixed
-      BSSID and/or MAC address is provided. Drivers that support multi-bssid
-      operation may honor the requested BSSID or assign their own.

-  

-  
Destroy a vap instance created with
-    ic_vap_create.

-  

-  
Return the list of calibrated channels for the radio. The default method
-      returns the current list of channels (space permitting).

-  

-  
Process a request to change regulatory state. The routine may reject a
-      request or constrain changes (e.g. reduce transmit power caps). The
-      default method accepts all proposed changes.

-  

-  
Send an 802.11 management frame. The default method fabricates the frame
-      using IEEE80211 state and passes it to the driver
-      through the ic_raw_xmit method.

-  

-  
Transmit a raw 802.11 frame. The default method drops the frame and
-      generates a message on the console.

-  

-  
Update hardware state after an 802.11 IFS slot time change. There is no
-      default method; the pointer may be NULL in which case it will not be
-    used.

-  

-  
Update hardware for a change in the multicast packet filter. The default
-      method prints a console message.

-  

-  
Update hardware for a change in the promiscuous mode setting. The default
-      method prints a console message.

-  

-  
Update driver/device state for association to a new AP (in station mode)
-      or when a new station associates (e.g. in AP mode). There is no default
-      method; the pointer may be NULL in which case it will not be used.

-  

-  
Allocate and initialize a ieee80211_node structure.
-      This method cannot sleep. The default method allocates zero'd memory using
-      malloc(9). Drivers should override this method to
-      allocate extended storage for their own needs. Memory allocated by the
-      driver must be tagged with M_80211_NODE to balance
-      the memory allocation statistics.

-  

-  
Reclaim storage of a node allocated by
-      ic_node_alloc. Drivers are expected to
-      
-      their own method to cleanup private state but must call through this
-      method to allow IEEE80211 to reclaim it's private
-      state.

-  

-  
Cleanup state in a ieee80211_node created by
-      ic_node_alloc. This operation is distinguished
-      from ic_node_free in that it may be called long
-      before the node is actually reclaimed to cleanup adjunct state. This can
-      happen, for example, when a node must not be reclaimed due to references
-      held by packets in the transmit queue. Drivers typically interpose
-      ic_node_cleanup instead of
-      ic_node_free.

-  

-  
Age, and potentially reclaim, resources associated with a node. The
-      default method ages frames on the power-save queue (in AP mode) and
-      pending frames in the receive reorder queues (for stations using
-    A-MPDU).

-  

-  
Reclaim all optional resources associated with a node. This call is used
-      to free up resources when they are in short supply.

-  

-  
Return the Receive Signal Strength Indication (RSSI) in .5 dBm units for
-      the specified node. This interface returns a subset of the information
-      returned by ic_node_getsignal. The default method
-      calculates a filtered average over the last ten samples passed in to
-      ieee80211_input(9) or
-      ieee80211_input_all(9).

-  

-  
Return the RSSI and noise floor (in .5 dBm units) for a station. The
-      default method calculates RSSI as described above; the noise floor
-      returned is the last value supplied to
-      ieee80211_input(9) or
-      ieee80211_input_all(9).

-  

-  
Return MIMO radio state for a station in support of the
-      IEEE80211_IOC_STA_INFO ioctl request. The default
-      method returns nothing.

-  

-  
Prepare driver/hardware state for scanning. This callback is done in a
-      sleepable context.

-  

-  
Restore driver/hardware state after scanning completes. This callback is
-      done in a sleepable context.

-  

-  
Set the current radio channel using ic_curchan. This
-      callback is done in a sleepable context.

-  

-  
Start scanning on a channel. This method is called immediately after each
-      channel change and must initiate the work to scan a channel and schedule a
-      timer to advance to the next channel in the scan list. This callback is
-      done in a sleepable context. The default method handles active scan work
-      (e.g. sending ProbeRequest frames), and schedules a call to
-      ieee80211_scan_next(9) according to the maximum dwell
-      time for the channel. Drivers that off-load scan work to firmware
-      typically use this method to trigger per-channel scan activity.

-  

-  
Handle reaching the minimum dwell time on a channel when scanning. This
-      event is triggered when one or more stations have been found on a channel
-      and the minimum dwell time has been reached. This callback is done in a
-      sleepable context. The default method signals the scan machinery to
-      advance to the next channel as soon as possible. Drivers can use this
-      method to preempt further work (e.g. if scanning is handled by firmware)
-      or ignore the request to force maximum dwell time on a channel.

-  

-  
Process a received Action frame. The default method points to
-      ieee80211_recv_action(9) which provides a mechanism for
-      setting up handlers for each Action frame class.

-  

-  
Transmit an Action frame. The default method points to
-      ieee80211_send_action(9) which provides a mechanism for
-      setting up handlers for each Action frame class.

-  

-  
Check if transmit A-MPDU should be enabled for the specified station and
-      AC. The default method checks a per-AC traffic rate against a per-vap
-      threshold to decide if A-MPDU should be enabled. This method also
-      rate-limits ADDBA requests so that requests are not made too frequently
-      when a receiver has limited resources.

-  

-  
Request A-MPDU transmit aggregation. The default method sets up local
-      state and issues an ADDBA Request Action frame. Drivers may interpose this
-      method if they need to setup private state for handling transmit
-    A-MPDU.

-  

-  
Process a received ADDBA Response Action frame and setup resources as
-      needed for doing transmit A-MPDU.

-  

-  
Shutdown an A-MPDU transmit stream for the specified station and AC. The
-      default method reclaims local state after sending a DelBA Action
-    frame.

-  

-  
Process a response to a transmitted BAR control frame.

-  

-  
Prepare to receive A-MPDU data from the specified station for the
-    TID.

-  

-  
Terminate receipt of A-MPDU data from the specified station for the
-    TID.

-

-
Once the IEEE80211 layer is attached to a
-    driver there are two more steps typically done to complete the work:

-
    
-  
  1. Setup “radiotap support” for capturing raw 802.11 packets
-      that pass through the device. This is done with a call to
-      ieee80211_radiotap_attach(9).
    2. 
-  
  2. Do any final device setup like enabling interrupts.
    3. 
-

-
State is torn down and reclaimed with a
-    call to
-    ().
-    Note this call may result in multiple callbacks into the driver so it should
-    be done before any critical driver state is reclaimed. On return from
-    ieee80211_ifdetach() all associated vaps and ifnet
-    structures are reclaimed or inaccessible to user applications so it is safe
-    to teardown driver state without worry about being re-entered. The driver is
-    responsible for calling if_free(9) on the ifnet it
-    allocated for the physical device.

-

-

-

-
Driver/device capabilities are specified using several sets of
-    flags in the ieee80211com structure. General
-    capabilities are specified by ic_caps. Hardware
-    cryptographic capabilities are specified by
-    ic_cryptocaps. Software cryptographic capabilities are
-    specified by ic_sw_cryptocaps. 802.11n capabilities,
-    if any, are specified by ic_htcaps. The
-    IEEE80211 layer propagates a subset of these
-    capabilities to each vap through the equivalent fields:
-    iv_caps, iv_cryptocaps, and
-    iv_htcaps. The following general capabilities are
-    defined:

-

-  

-  
Device is capable of operating in station (aka Infrastructure) mode.

-  

-  
Device requires 802.3-encapsulated frames be passed for transmit. By
-      default IEEE80211 will encapsulate all outbound
-      frames as 802.11 frames (without a PLCP header).

-  

-  
Device supports Atheros Fast-Frames.

-  

-  
Device supports Atheros Dynamic Turbo mode.

-  

-  
Device is capable of operating in adhoc/IBSS mode.

-  

-  
Device supports dynamic power-management (aka power save) in station
-    mode.

-  

-  
Device is capable of operating as an Access Point in Infrastructure
-    mode.

-  

-  
Device is capable of operating in Adhoc Demo mode. In this mode the device
-      is used purely to send/receive raw 802.11 frames.

-  

-  
Device supports software retry of transmitted frames.

-  

-  
Device support dynamic transmit power changes on transmitted frames; also
-      known as Transmit Power Control (TPC).

-  

-  
Device supports short slot time operation (for 802.11g).

-  

-  
Device supports short preamble operation (for 802.11g).

-  

-  
Device is capable of operating in monitor mode.

-  

-  
Device supports radar detection and/or DFS. DFS protocol support can be
-      handled by IEEE80211 but the device must be
-      capable of detecting radar events.

-  

-  
Device is capable of operating in MeshBSS (MBSS) mode (as defined by
-      802.11s Draft 3.0).

-  

-  
Device supports WPA1 operation.

-  

-  
Device supports WPA2/802.11i operation.

-  

-  
Device supports frame bursting.

-  

-  
Device supports WME/WMM operation (at the moment this is mostly support
-      for sending and receiving QoS frames with EDCF).

-  

-  
Device supports transmit/receive of 4-address frames.

-  

-  
Device supports background scanning.

-  

-  
Device supports transmit of fragmented 802.11 frames.

-  

-  
Device is capable of operating in TDMA mode.

-

-
The follow general crypto capabilities are defined. In general
-    IEEE80211 will fall-back to software support when a
-    device is not capable of hardware acceleration of a cipher. This can be done
-    on a per-key basis. IEEE80211 can also handle
-    software Michael calculation combined with hardware
-    AES acceleration.

-

-  

-  
Device supports hardware WEP cipher.

-  

-  
Device supports hardware TKIP cipher.

-  

-  
Device supports hardware AES-OCB cipher.

-  

-  
Device supports hardware AES-CCM cipher.

-  

-  
Device supports hardware Michael for use with TKIP.

-  

-  
Devices supports hardware CKIP cipher.

-

-
The follow general 802.11n capabilities are defined. The first
-    capabilities are defined exactly as they appear in the 802.11n
-    specification. Capabilities beginning with IEEE80211_HTC_AMPDU are used
-    solely by the IEEE80211 layer.

-

-  

-  
Device supports 20/40 channel width operation.

-  

-  
Device supports dynamic SM power save operation.

-  

-  
Device supports static SM power save operation.

-  

-  
Device supports Greenfield preamble.

-  

-  
Device supports Short Guard Interval on 20MHz channels.

-  

-  
Device supports Short Guard Interval on 40MHz channels.

-  

-  
Device supports Space Time Block Convolution (STBC) for transmit.

-  

-  
Device supports 1 spatial stream for STBC receive.

-  

-  
Device supports 1-2 spatial streams for STBC receive.

-  

-  
Device supports 1-3 spatial streams for STBC receive.

-  

-  
Device supports A-MSDU frames up to 7935 octets.

-  

-  
Device supports A-MSDU frames up to 3839 octets.

-  

-  
Device supports use of DSSS/CCK on 40MHz channels.

-  

-  
Device supports PSMP.

-  

-  
Device is intolerant of 40MHz wide channel use.

-  

-  
Device supports L-SIG TXOP protection.

-  

-  
Device supports A-MPDU aggregation. Note that any 802.11n compliant device
-      must support A-MPDU receive so this implicitly means support for
-      transmit of A-MPDU frames.

-  

-  
Device supports A-MSDU aggregation. Note that any 802.11n compliant device
-      must support A-MSDU receive so this implicitly means support for
-      transmit of A-MSDU frames.

-  

-  
Device supports High Throughput (HT) operation. This capability must be
-      set to enable 802.11n functionality in
-    IEEE80211.

-  

-  
Device supports MIMO Power Save operation.

-  

-  
Device supports Reduced Inter Frame Spacing (RIFS).

-

-

-

-

-
ioctl(2), ieee80211_amrr(9),
-    ieee80211_beacon(9), ieee80211_bmiss(9),
-    ieee80211_crypto(9), ieee80211_ddb(9),
-    ieee80211_input(9), ieee80211_node(9),
-    ieee80211_output(9), ieee80211_proto(9),
-    ieee80211_radiotap(9),
-    ieee80211_regdomain(9),
-    ieee80211_scan(9), ieee80211_vap(9),
-    ifnet(9), malloc(9)

-

-

-

-
The IEEE80211 series of functions first
-    appeared in NetBSD 1.5, and were later ported to
-    FreeBSD 4.6. This man page was updated with the
-    information from NetBSD
-    IEEE80211 man page.

-

-

-

-
The original NetBSD
-    IEEE80211 man page was written by
-    Bruce M. Simpson
-    <bms@FreeBSD.org> and
-    Darron Broad
-    <darron@kewl.org>.

-

-

-
-  
-    
-    
-  
-
April 24, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_amrr.9 3.html b/static/freebsd/man9/ieee80211_amrr.9 3.html
deleted file mode 100644
index b1c80d53..00000000
--- a/static/freebsd/man9/ieee80211_amrr.9 3.html	
+++ /dev/null
@@ -1,159 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE8021_AMRR(9)Kernel Developer's ManualIEEE8021_AMRR(9)

-

-

-

-
ieee80211_amrr —
-    802.11 network driver transmit rate control
-  support

-

-

-

-
#include
-    <net80211/ieee80211_amrr.h>

-
void
-  

-  ieee80211_amrr_init(struct
-    ieee80211_amrr *, struct ieee80211vap *,
-    int amin, int amax,
-    int interval);

-
void
-  

-  ieee80211_amrr_cleanup(struct
-    ieee80211_amrr *);

-
void
-  

-  ieee80211_amrr_setinterval(struct
-    ieee80211_amrr *, int
-    interval);

-
void
-  

-  ieee80211_amrr_node_init(struct
-    ieee80211_amrr *, struct ieee80211_amrr_node *,
-    struct ieee80211_node *);

-
int
-  

-  ieee80211_amrr_choose(struct
-    ieee80211_node *, struct ieee80211_amrr_node
-  *);

-
void
-  

-  ieee80211_amrr_tx_complete(struct
-    ieee80211_amrr_node *, int ok,
-    int retries);

-
void
-  

-  ieee80211_amrr_tx_update(struct
-    ieee80211_amrr_node *, int txnct,
-    int success, int retrycnt);

-

-

-

-
ieee80211_amrr is an implementation of the
-    AMRR transmit rate control algorithm for drivers that use the
-    net80211 software layer. A rate control algorithm is
-    responsible for choosing the transmit rate for each frame. To maximize
-    throughput algorithms try to use the highest rate that is appropriate for
-    the operating conditions. The rate will vary as conditions change; the
-    distance between two stations may change, transient noise may be present
-    that affects signal quality, etc. ieee80211_amrr
-    uses very simple information from a driver to do it's job: whether a frame
-    was successfully delivered and how many transmit attempts were made. While
-    this enables its use with virtually any wireless device it limits it's
-    effectiveness--do not expect it to function well in difficult environments
-    and/or respond quickly to changing conditions.

-
ieee80211_amrr requires per-vap state and
-    per-node state for each station it is to select rates for. The API's are
-    designed for drivers to pre-allocate state in the driver-private extension
-    areas of each vap and node. For example the ral(4) driver
-    defines a vap as:

-

-
struct rt2560_vap {
-        struct ieee80211vap     ral_vap;
-        struct ieee80211_beacon_offsets ral_bo;
-        struct ieee80211_amrr   amrr;
-
-        int      (*ral_newstate)(struct ieee80211vap *,
-                      enum ieee80211_state, int);
-};

-

-
The amrr structure member holds the per-vap
-    state for ieee80211_amrr and
-    ral(4) initializes it in the vap create method with:

-

-
ieee80211_amrr_init(&rvp->amrr, vap,
-    IEEE80211_AMRR_MIN_SUCCESS_THRESHOLD,
-    IEEE80211_AMRR_MAX_SUCCESS_THRESHOLD,
-    500 /* ms */);

-

-
The node is defined as:

-

-
struct rt2560_node {
-        struct ieee80211_node   ni;
-        struct ieee80211_amrr_node amrr;
-};

-

-
with initialization done in the driver's
-    iv_newassoc method:

-

-
static void
-rt2560_newassoc(struct ieee80211_node *ni, int isnew)
-{
-        struct ieee80211vap *vap = ni->ni_vap;
-
-        ieee80211_amrr_node_init(&RT2560_VAP(vap)->amrr,
-            &RT2560_NODE(ni)->amrr, ni);
-}

-

-
Once
-    ieee80211_amrr state is setup, transmit rates are
-    requested by calling
-    ()
-    in the transmit path; e.g.:

-

-
tp = &vap->iv_txparms[ieee80211_chan2mode(ni->ni_chan)];
-if (IEEE80211_IS_MULTICAST(wh->i_addr1)) {
-	rate = tp->mcastrate;
-} else if (m0->m_flags & M_EAPOL) {
-	rate = tp->mgmtrate;
-} else if (tp->ucastrate != IEEE80211_FIXED_RATE_NONE) {
-	rate = tp->ucastrate;
-} else {
-	(void) ieee80211_amrr_choose(ni, &RT2560_NODE(ni)->amrr);
-	rate = ni->ni_txrate;
-}

-

-
Note a rate is chosen only for
-    unicast data frames when a fixed transmit rate is not configured; the other
-    cases are handled with the net80211 transmit
-    parameters. Note also that
-    ()
-    writes the chosen rate in ni_txrate; this eliminates
-    copying the value as it is exported to user applications so they can display
-    the current transmit rate in status.

-
The remaining work a driver must
-    do is feed status back to ieee80211_amrr when a
-    frame transmit completes using
-    ().
-    Drivers that poll a device to retrieve statistics can use
-    ()
-    (instead or in addition).

-

-

-

-
ieee80211(9),
-    ieee80211_output(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_beacon.9 3.html b/static/freebsd/man9/ieee80211_beacon.9 3.html
deleted file mode 100644
index eff2b10e..00000000
--- a/static/freebsd/man9/ieee80211_beacon.9 3.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_BEACON(9)Kernel Developer's ManualIEEE80211_BEACON(9)

-

-

-

-
ieee80211_beacon —
-    802.11 beacon support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-

-  

-  struct mbuf *
-  

-  ieee80211_beacon_alloc(struct
-    ieee80211_node *, struct ieee80211_beacon_offsets
-    *);

-
int
-  

-  ieee80211_beacon_update(struct
-    ieee80211_node *, struct ieee80211_beacon_offsets
-    *, struct mbuf *, int
-    mcast);

-
void
-  

-  ieee80211_beacon_notify(struct
-    ieee80211vap *, int
-    what);

-

-

-

-
The net80211 software layer provides a
-    support framework for drivers that includes a template-based mechanism for
-    dynamic update of beacon frames transmit in hostap, adhoc, and mesh
-    operating modes. Drivers should use
-    ()
-    to create an initial beacon frame. The
-    ieee80211_beacon_offsets structure holds information
-    about the beacon contents that is used to optimize updates done with
-    ieee80211_beacon_update().

-
Update calls should only be done when something changes that
-    affects the contents of the beacon frame. When this happens the
-    iv_update_beacon method is invoked and a
-    driver-supplied routine must do the right thing. For devices that involve
-    the host to transmit each beacon frame this work may be as simple as marking
-    a bit in the ieee80211_beacon_offsets structure:

-

-
static void
-ath_beacon_update(struct ieee80211vap *vap, int item)
-{
-        struct ieee80211_beacon_offsets *bo = &ATH_VAP(vap)->av_boff;
-	setbit(bo->bo_flags, item);
-}

-

-
with the
-    ()
-    call done before the next beacon is to be sent.

-
Devices that off-load beacon generation may instead choose to use
-    this callback to push updates immediately to the device. Exactly how that is
-    accomplished is unspecified. One possibility is to update the beacon frame
-    contents and extract the appropriate information element, but other
-    scenarios are possible.

-

-

-

-
Drivers that support multiple vaps that can each beacon need to
-    consider how to schedule beacon frames. There are two possibilities at the
-    moment:
-    
-    all beacons at TBTT or
-     over the beacon interval. Bursting beacon frames may result
-    in aperiodic delivery that can affect power save operation of associated
-    stations. Applying some jitter (e.g. by randomly ordering burst frames) may
-    be sufficient to combat this and typically this is not an issue unless
-    stations are using aggressive power save techniques such as U-APSD
-    (sometimes employed by VoIP phones). Staggering frames requires more
-    interrupts and device support that may not be available. Staggering beacon
-    frames is usually superior to bursting frames, up to about eight vaps, at
-    which point the overhead becomes significant and the channel becomes
-    noticeably busy anyway.

-

-

-

-
ieee80211(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_bmiss.9 3.html b/static/freebsd/man9/ieee80211_bmiss.9 3.html
deleted file mode 100644
index 55b693b8..00000000
--- a/static/freebsd/man9/ieee80211_bmiss.9 3.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_BMISS(9)Kernel Developer's ManualIEEE80211_BMISS(9)

-

-

-

-
ieee80211_bmiss —
-    802.11 beacon miss support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-

-  

-  void
-  

-  ieee80211_beacon_miss(struct
-    ieee80211com *);

-

-

-

-
The net80211 software layer provides a
-    support framework for drivers that includes handling beacon miss events in
-    station mode. Drivers can dispatch beacon miss events that are recognized in
-    hardware or net80211 can detect beacon miss if the
-    driver dispatches received beacon frames through the normal receive path.
-    Software beacon miss support is especially useful when multiple vaps are
-    operating and any hardware beacon miss support is not available (e.g.
-    operating as an access point together with one or more station mode
-  vaps).

-
Drivers should dispatch beacon miss
-    events recognized in the driver with
-    ().
-    This causes some number of ProbeRequest frames to be sent to the access
-    point to check if the association is still alive. If no response is received
-    and roaming mode is set to IEEE80211_ROAMING_AUTO
-    then net80211 will try to re-associate and if that
-    fails trigger a scan to look for the access point or another suitable AP.
-    When the net80211 state machine is being operated
-    manually, e.g. by wpa_supplicant(8), then applications are
-    notified of the state change and are responsible for handling the work of
-    scanning for a new access point. The number of beacon miss events (without a
-    ProbeResponse) is user settable with the
-    IEEE80211_IOC_BMISSTHRESHOLD request.

-
Software beacon miss detection is enabled per-vap by setting the
-    IEEE80211_FEXT_SWBMISS flag. Typically this is done
-    when a vap is setup when the
-    IEEE80211_CLONE_NOBEACONS option is supplied to the
-    clone operation. But drivers may also force this when they know they need
-    help detecting beacon miss. When beacon miss is detected in software the
-    event is dispatched without driver involvement. Note that software beacon
-    miss handling is not limited to station mode; it can be used in any
-    operating mode where beacons from a peer station are received.

-

-

-

-
wpa_supplicant(8),
-    ieee80211(9), ieee80211_vap(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_crypto.9 3.html b/static/freebsd/man9/ieee80211_crypto.9 3.html
deleted file mode 100644
index b518feda..00000000
--- a/static/freebsd/man9/ieee80211_crypto.9 3.html	
+++ /dev/null
@@ -1,221 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_CRYPTO(9)Kernel Developer's ManualIEEE80211_CRYPTO(9)

-

-

-

-
ieee80211_crypto —
-    802.11 cryptographic support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-

-  

-  void
-  

-  ieee80211_crypto_register(const
-    struct ieee80211_cipher *);

-
void
-  

-  ieee80211_crypto_unregister(const
-    struct ieee80211_cipher *);

-
int
-  

-  ieee80211_crypto_available(int
-    cipher);

-

-  

-  void
-  

-  ieee80211_notify_replay_failure(struct
-    ieee80211vap *, const struct ieee80211_frame *,
-    const struct ieee80211_key *, uint64_t
-    rsc, int tid);

-
void
-  

-  ieee80211_notify_michael_failure(struct
-    ieee80211vap *, const struct ieee80211_frame *,
-    u_int keyix);

-
int
-  

-  ieee80211_crypto_newkey(struct
-    ieee80211vap *, int cipher, int
-    flags, struct ieee80211_key *);

-
int
-  

-  ieee80211_crypto_setkey(struct
-    ieee80211vap *, struct
-    ieee80211_key *);

-
int
-  

-  ieee80211_crypto_delkey(struct
-    ieee80211vap *, struct
-    ieee80211_key *);

-
void
-  

-  ieee80211_key_update_begin(struct
-    ieee80211vap *);

-
void
-  

-  ieee80211_key_update_end(struct
-    ieee80211vap *);

-
void
-  

-  ieee80211_crypto_delglobalkeys(struct
-    ieee80211vap *);

-
void
-  

-  ieee80211_crypto_reload_keys(struct
-    ieee80211com *);

-

-  

-  struct ieee80211_key *
-  

-  ieee80211_crypto_encap(struct
-    ieee80211_node *, struct
-    mbuf *);

-
struct ieee80211_key *
-  

-  ieee80211_crypto_decap(struct
-    ieee80211_node *, struct
-    mbuf *, int
-  flags);

-
int
-  

-  ieee80211_crypto_demic(struct
-    ieee80211vap *, struct ieee80211_key *,
-    struct mbuf *, int force);

-
int
-  

-  ieee80211_crypto_enmic(struct
-    ieee80211vap *, struct ieee80211_key *,
-    struct mbuf *, int force);

-

-

-

-
The net80211 layer includes comprehensive
-    cryptographic support for 802.11 protocols. Software implementations of
-    ciphers required by WPA and 802.11i are provided as well as encap/decap
-    processing of 802.11 frames. Software ciphers are written as kernel modules
-    and register with the core crypto support. The cryptographic framework
-    supports hardware acceleration of ciphers by drivers with automatic
-    fall-back to software implementations when a driver is unable to provide
-    necessary hardware services.

-

-

-

-
net80211 cipher modules register their
-    services using
-    ()
-    and supply a template that describes their operation. This
-    ieee80211_cipher structure defines protocol-related
-    state such as the number of bytes of space in the 802.11 header to
-    reserve/remove during encap/decap and entry points for setting up keys and
-    doing cryptographic operations.

-
Cipher modules can associate private state to each key through the
-    wk_private structure member. If state is setup by the
-    module it will be called before a key is destroyed so it can reclaim
-    resources.

-
Crypto modules can notify the
-    system of two events. When a packet replay event is recognized
-    ()
-    can be used to signal the event. When a TKIP Michael
-    failure is detected
-    ()
-    can be invoked. Drivers may also use these routines to signal events
-    detected by the hardware.

-

-

-

-
The net80211 layer implements a per-vap
-    4-element “global key table” and a per-station “unicast
-    key” for protocols such as WPA, 802.1x, and 802.11i. The global key
-    table is designed to support legacy WEP operation and Multicast/Group keys,
-    though some applications also use it to implement WPA in station mode. Keys
-    in the global table are identified by a key index in the range 0-3.
-    Per-station keys are identified by the MAC address of the station and are
-    typically used for unicast PTK bindings.

-
net80211 provides
-    ioctl(2) operations for managing both global and
-    per-station keys. Drivers typically do not participate in software key
-    management; they are involved only when providing hardware acceleration of
-    cryptographic operations.

-
()
-    is used to allocate a new net80211 key or
-    reconfigure an existing key. The cipher must be specified along with any
-    fixed key index. The net80211 layer will handle
-    allocating cipher and driver resources to support the key.

-
Once a key is allocated it's contents
-    can be set using
-    ()
-    and deleted with
-    ()
-    (with any cipher and driver resources reclaimed).

-
()
-    is used to reclaim all keys in the global key table for a vap; it typically
-    is used only within the net80211 layer.

-
()
-    handles hardware key state reloading from software key state, such as
-    required after a suspend/resume cycle.

-

-

-

-
Drivers identify ciphers they have hardware support for through
-    the ic_cryptocaps field of the
-    ieee80211com structure. If hardware support is
-    available then a driver should also fill in the
-    iv_key_alloc, iv_key_set,
-    and iv_key_delete methods of each
-    ieee80211vap created for use with the device. In
-    addition the methods iv_key_update_begin and
-    iv_key_update_end can be setup to handle
-    synchronization requirements for updating hardware key state.

-
When net80211 allocates a software key and
-    the driver can accelerate the cipher operations the
-    iv_key_alloc method will be invoked. Drivers may
-    return a token that is associated with outbound traffic (for use in
-    encrypting frames). Otherwise, e.g. if hardware resources are not available,
-    the driver will not return a token and net80211 will
-    arrange to do the work in software and pass frames to the driver that are
-    already prepared for transmission.

-
For receive, drivers mark frames with the
-    M_WEP mbuf flag to indicate the hardware has
-    decrypted the payload. If frames have the
-    IEEE80211_FC1_PROTECTED bit marked in their 802.11
-    header and are not tagged with M_WEP then decryption
-    is done in software. For more complicated scenarios the software key state
-    is consulted; e.g. to decide if Michael verification needs to be done in
-    software after the hardware has handled TKIP decryption.

-
Drivers that manage complicated
-    key data structures, e.g. faulting software keys into a hardware key cache,
-    can safely manipulate software key state by bracketing their work with calls
-    to
-    ()
-    and
-    ().
-    These calls also synchronize hardware key state update when receive traffic
-    is active.

-

-

-

-
ioctl(2), wlan_ccmp(4),
-    wlan_tkip(4), wlan_wep(4),
-    ieee80211(9)

-

-

-
-  
-    
-    
-  
-
March 29, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_ddb.9 4.html b/static/freebsd/man9/ieee80211_ddb.9 4.html
deleted file mode 100644
index 7b99741f..00000000
--- a/static/freebsd/man9/ieee80211_ddb.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_DDB(9)Kernel Developer's ManualIEEE80211_DDB(9)

-

-

-

-
ieee80211_ddb —
-    802.11 ddb support

-

-

-

-
options DDB

-
show vap [addr]
-

-show all vaps
-

-show com [addr]
-

-show sta [addr]
-

-show statab [addr]
-

-show mesh [addr]

-

-

-

-
The net80211 layer includes
-    ddb(4) support for displaying important data structures.
-    This is especially important because wireless applications are often built
-    for embedded environments where cross-machine or post-mortem debugging
-    facilities like kgdb(1)
-    (ports/devel/gdb) are infeasible.

-
The most commonly used command is

-

-
show all vaps/a

-

-
which dumps the contents of all
-    ieee80211vap, ieee80211com, and
-    ieee80211_node data structures in the system.

-

-

-

-
ddb(4), ieee80211(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_input.9 3.html b/static/freebsd/man9/ieee80211_input.9 3.html
deleted file mode 100644
index e0ded463..00000000
--- a/static/freebsd/man9/ieee80211_input.9 3.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_INPUT(9)Kernel Developer's ManualIEEE80211_INPUT(9)

-

-

-

-
ieee80211_input —
-    software 802.11 stack input functions

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-
void
-  

-  ieee80211_input(struct ieee80211_node
-    *, struct mbuf *, int
-    rssi, int noise);

-
void
-  

-  ieee80211_input_all(struct
-    ieee80211com *, struct mbuf *,
-    int rssi, int noise);

-

-

-

-
The net80211 layer that supports 802.11
-    device drivers requires that receive processing be single-threaded.
-    Typically this is done using a dedicated driver
-    taskqueue(9) thread.
-    ()
-    and
-    ()
-    process received 802.11 frames and are designed for use in that context;
-    e.g. no driver locks may be held.

-
The frame passed up in the mbuf must have
-    the 802.11 protocol header at the front; all device-specific information
-    and/or PLCP must be removed. Any CRC must be stripped from the end of the
-    frame. The 802.11 protocol header should be 32-bit aligned for optimal
-    performance but receive processing does not require it. If the frame holds a
-    payload and that is not aligned to a 32-bit boundary then the payload will
-    be re-aligned so that it is suitable for processing by protocols such as
-    ip(4).

-
If a device (such as ath(4)) inserts padding
-    after the 802.11 header to align the payload to a 32-bit boundary the
-    IEEE80211_C_DATAPAD capability must be set.
-    Otherwise header and payload are assumed contiguous in the mbuf chain.

-
If a received frame must pass through the A-MPDU receive reorder
-    buffer then the mbuf must be marked with the M_AMPDU
-    flag. Note that for the moment this is required of all frames received from
-    a station and TID where a Block ACK stream is active, not just A-MPDU
-    aggregates. It is sufficient to check for
-    IEEE80211_NODE_HT in the
-    ni_flags of the station's node table entry, any frames
-    that do not require reorder processing will be dispatched with only minimal
-    overhead.

-
The rssi parameter is the Receive Signal
-    Strength Indication of the frame measured in 0.5dBm units relative to the
-    noise floor. The noise parameter is the best
-    approximation of the noise floor in dBm units at the time the frame was
-    received. RSSI and noise are used by the net80211
-    layer to make scanning and roaming decisions in station mode and to do auto
-    channel selection for hostap and similar modes. Otherwise the values are
-    made available to user applications (with the rssi presented as a filtered
-    average over the last ten values and the noise floor the last reported
-    value).

-

-

-

-
ieee80211(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_node.9 3.html b/static/freebsd/man9/ieee80211_node.9 3.html
deleted file mode 100644
index 5f8c677e..00000000
--- a/static/freebsd/man9/ieee80211_node.9 3.html	
+++ /dev/null
@@ -1,190 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_NODE(9)Kernel Developer's ManualIEEE80211_NODE(9)

-

-

-

-
ieee80211_node —
-    software 802.11 stack node management functions

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-
struct ieee80211_node *
-  

-  ieee80211_find_rxnode(struct
-    ieee80211com *, const struct ieee80211_frame_min
-    *);

-
struct ieee80211_node *
-  

-  ieee80211_find_rxnode_withkey(struct
-    ieee80211com *, const struct ieee80211_frame_min
-    *, ieee80211_keyix);

-
struct ieee80211_node *
-  

-  ieee80211_ref_node(struct
-    ieee80211_node *);

-
void
-  

-  ieee80211_free_node(struct
-    ieee80211_node *);

-
void
-  

-  ieee80211_iterate_nodes(struct
-    ieee80211_node_table *, ieee80211_iter_func *f,
-    void *arg);

-
void
-  

-  ieee80211_dump_nodes(struct
-    ieee80211_node_table *);

-
void
-  

-  ieee80211_dump_node(struct
-    ieee80211_node *);

-

-

-

-
The net80211 layer that supports 802.11
-    device drivers maintains a database of peer stations called the “node
-    table” in the ic_sta entry of the
-    ieee80211com structure. Station mode vaps create an
-    entry for the access point the station is associated to. AP mode vaps create
-    entries for associated stations. Adhoc and mesh mode vaps create entries for
-    neighbor stations. WDS mode vaps create an entry for the peer station.
-    Stations for all vaps reside in the same table; each node entry has a
-    ni_vap field that identifies the vap that created it.
-    In some instances an entry is used by multiple vaps (e.g. for dynamic WDS a
-    station associated to an ap vap may also be the peer of a WDS vap).

-
Node table entries are reference counted.
-    That is, there is a count of all long term references that determines when
-    an entry may be reclaimed. References are held by every in-flight frame sent
-    to a station to ensure the entry is not reclaimed while the frame is queued
-    or otherwise held by a driver. Routines that lookup a table entry return a
-    “held reference” (i.e. a pointer to a table entry with the
-    reference count incremented). The
-    ()
-    call explicitly increments the reference count of a node.
-    ()
-    decrements the reference count of a node and if the count goes to zero
-    reclaims the table entry.

-
The station table and its entries are exposed to drivers in
-    several ways. Each frame transmitted to a station includes a reference to
-    the associated node in the m_pkthdr.rcvif field. This
-    reference must be reclaimed by the driver when transmit processing is done.
-    For each frame received the driver must lookup the table entry to use in
-    dispatching the frame “up the stack”. This lookup implicitly
-    obtains a reference to the table entry and the driver must reclaim the
-    reference when frame processing is completed. Otherwise drivers frequently
-    inspect the contents of the iv_bss node when handling
-    state machine changes as important information is maintained in the data
-    structure.

-
The node table is opaque to drivers.
-    Entries may be looked up using one of the pre-defined API's or the
-    ()
-    call may be used to iterate through all entries to do per-node processing or
-    implement some non-standard search mechanism. Note that
-    ieee80211_iterate_nodes() is single-threaded
-    per-device and the effort processing involved is fairly substantial so it
-    should be used carefully.

-
Two routines are provided to print the
-    contents of nodes to the console for debugging:
-    ()
-    displays the contents of a single node while
-    ()
-    displays the contents of the specified node table. Nodes may also be
-    displayed using ddb(4) with the “show node”
-    directive and the station node table can be displayed with “show
-    statab”.

-

-

-

-
Node data structures may be extended by the driver to include
-    driver-private state. This is done by overriding the
-    ic_node_alloc method used to allocate a node table
-    entry. The driver method must allocate a structure that is an extension of
-    the ieee80211_node structure. For example the
-    iwi(4) driver defines a private node structure as:

-

-
struct iwi_node {
-        struct ieee80211_node   in_node;
-	int                     in_station;
-};

-

-
and then provides a private allocation routine that does this:

-

-
static struct ieee80211_node *
-iwi_node_alloc(struct ieee80211vap *vap,
-    const uint8_t mac[IEEE80211_ADDR_LEN])
-{
-        struct iwi_node *in;
-
-        in = malloc(sizeof(struct iwi_node), M_80211_NODE,
-		M_NOWAIT | M_ZERO);
-        if (in == NULL)
-                return NULL;
-        in->in_station = -1;
-        return &in->in_node;
-}

-

-
Note that when reclaiming a node allocated by the driver the
-    “parent method” must be called to ensure
-    net80211 state is reclaimed; for example:

-

-
static void
-iwi_node_free(struct ieee80211_node *ni)
-{
-        struct ieee80211com *ic = ni->ni_ic;
-        struct iwi_softc *sc = ic->ic_ifp->if_softc;
-        struct iwi_node *in = (struct iwi_node *)ni;
-
-        if (in->in_station != -1)
-                free_unr(sc->sc_unr, in->in_station);
-        sc->sc_node_free(ni);	/* invoke net80211 free handler */
-}

-

-
Beware that care must be taken to avoid holding references that
-    might cause nodes from being reclaimed. net80211
-    will reclaim a node when the last reference is reclaimed in its data
-    structures. However if a driver holds additional references then
-    net80211 will not recognize this and table entries
-    will not be reclaimed. Such references should not be needed if the driver
-    overrides the ic_node_cleanup and/or
-    ic_node_free methods.

-

-

-

-
Node table lookups are typically done using a hash of the
-    stations' mac address. When receiving frames this is sufficient to find the
-    node table entry for the transmitter. But some devices also identify the
-    sending station in the device state received with each frame and this data
-    can be used to optimize lookups on receive using a companion table called
-    the “keytab”. This table records a separate node table
-    reference that can be fetched without any locking using the table index.
-    This logic is handled with the
-    ()
-    call: if a keytab entry is found using the specified index then it is
-    returned directly; otherwise a normal lookup is done and the keytab entry is
-    written using the specified index. If the specified index is
-    IEEE80211_KEYIX_NONE then a normal lookup is done
-    without a table update.

-

-

-

-
ddb(4), ieee80211(9),
-    ieee80211_proto(9)

-

-

-
-  
-    
-    
-  
-
October 2, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_output.9 3.html b/static/freebsd/man9/ieee80211_output.9 3.html
deleted file mode 100644
index 62d80efc..00000000
--- a/static/freebsd/man9/ieee80211_output.9 3.html	
+++ /dev/null
@@ -1,141 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_OUTPUT(9)Kernel Developer's ManualIEEE80211_OUTPUT(9)

-

-

-

-
ieee80211_output —
-    software 802.11 stack output functions

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-
int
-  

-  M_WME_GETAC(struct
-    mbuf *);

-
int
-  

-  M_SEQNO_GET(struct
-    mbuf *);

-
struct ieee80211_key *
-  

-  ieee80211_crypto_encap(struct
-    ieee80211_node *, struct
-    mbuf *);

-
void
-  

-  ieee80211_process_callback(struct
-    ieee80211_node *, struct mbuf *,
-    int);

-

-

-

-
The net80211 layer that supports 802.11
-    device drivers handles most of the work required to transmit frames. Drivers
-    usually receive fully-encapsulated 802.11 frames that have been classified
-    and assigned a transmit priority; all that is left is to do crypto
-    encapsulation, prepare any hardware-specific state, and push the packet out
-    to the device. Outbound frames are either generated by the
-    net80211 layer (e.g. management frames) or are
-    passed down from upper layers through the ifnet(9)
-    transmit queue. Data frames passed down for transmit flow through
-    net80211 which handles aggregation, 802.11
-    encapsulation, and then dispatches the frames to the driver through it's
-    transmit queue.

-
There are two control paths by which frames reach a driver for
-    transmit. Data packets are queued to the device's
-    if_snd queue and the driver's
-    if_start method is called. Other frames are passed
-    down using the ic_raw_xmit method without queueing
-    (unless done by the driver). The raw transmit path may include data frames
-    from user applications that inject them through bpf(4) and
-    NullData frames generated by net80211 to probe for
-    idle stations (when operating as an access point).

-
net80211 handles all state-related
-    bookkeeping and management for the handling of data frames. Data frames are
-    only transmit for a vap in the IEEE80211_S_RUN
-    state; there is no need, for example, to check for frames sent down when CAC
-    or CSA is active. Similarly, net80211 handles
-    activities such as background scanning and power save mode, frames will not
-    be sent to a driver unless it is operating on the BSS channel with
-    “full power”.

-
All frames passed to a driver for
-    transmit hold a reference to a node table entry in the
-    m_pkthdr.rcvif field. The node is associated with the
-    frame destination. Typically it is the receiver's entry but in some
-    situations it may be a placeholder entry or the “next hop
-    station” (such as in a mesh network). In all cases the reference must
-    be reclaimed with
-    ()
-    when the transmit work is completed. The rule to remember is:
-    net80211 passes responsibility for the
-    mbuf and “node reference” to the driver
-    with each frame it hands off for transmit.

-

-

-

-
All frames passed by net80211 for transmit
-    are assigned a priority based on any vlan tag assigned to the receiving
-    station and/or any Diffserv setting in an IP or IPv6 header. If both vlan
-    and Diffserv priority are present the higher of the two is used. If WME/WMM
-    is being used then any ACM policy (in station mode) is also enforced. The
-    resulting AC is attached to the mbuf and may be read back using the
-    ()
-    macro.

-
PAE/EAPOL frames are tagged with an
-    M_EAPOL mbuf flag; drivers should transmit them with
-    care, usually by using the transmit rate for management frames.
-    Multicast/broadcast frames are marked with the
-    M_MCAST mbuf flag. Frames coming out of a station's
-    power save queue and that have more frames immediately following are marked
-    with the M_MORE_DATA mbuf flag. Such frames will be
-    queued consecutively in the driver's if_snd queue and
-    drivers should preserve the ordering when passing them to the device.

-

-

-

-
The net80211 layer will fragment data
-    frames according to the setting of iv_fragthreshold if
-    a driver marks the IEEE80211_C_TXFRAG capability.
-    Fragmented frames are placed in the devices transmit queue with the
-    fragments chained together with m_nextpkt. Each frame
-    is marked with the M_FRAG mbuf flag, and the first
-    and last are marked with M_FIRSTFRAG and
-    M_LASTFRAG, respectively. Drivers are expected to
-    process all fragments or none.

-

-

-

-
Frames sent by net80211 may be tagged with
-    the M_TXCB mbuf flag to indicate a callback should
-    be done when their transmission completes. The callback is done using
-    ()
-    with the last parameter set to a non-zero value if an error occurred and
-    zero otherwise. Note net80211 understands that
-    drivers may be incapable of determining status; a device may not report if
-    an ACK frame is received and/or a device may queue transmit requests in its
-    hardware and only report status on whether the frame was successfully
-    queued.

-

-

-

-
bpf(4), ieee80211(9),
-    ifnet(9)

-

-

-
-  
-    
-    
-  
-
March 29, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_proto.9 3.html b/static/freebsd/man9/ieee80211_proto.9 3.html
deleted file mode 100644
index 921b1d66..00000000
--- a/static/freebsd/man9/ieee80211_proto.9 3.html	
+++ /dev/null
@@ -1,198 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_PROTO(9)Kernel Developer's ManualIEEE80211_PROTO(9)

-

-

-

-
ieee80211_proto —
-    802.11 state machine support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-

-  

-  void
-  

-  ieee80211_start_all(struct
-    ieee80211com *);

-
void
-  

-  ieee80211_stop_all(struct
-    ieee80211com *);

-
void
-  

-  ieee80211_suspend_all(struct
-    ieee80211com *);

-
void
-  

-  ieee80211_resume_all(struct
-    ieee80211com *);

-
enum ieee80211_state;
-  

-  int
-  

-  ieee80211_new_state(struct
-    ieee80211vap *, enum
-    ieee80211_state,
-    int);

-

-  

-  void
-  

-  ieee80211_wait_for_parent(struct
-    ieee80211com *);

-

-

-

-
The net80211 layer that supports 802.11
-    device drivers uses a state machine to control operation of vaps. These
-    state machines vary according to the vap operating mode. Station mode state
-    machines follow the 802.11 MLME states in the protocol specification. Other
-    state machines are simpler and reflect operational work such as scanning for
-    a BSS or automatically selecting a channel to operate on. When multiple vaps
-    are operational the state machines are used to coordinate operation such as
-    choosing a channel. The state machine mechanism also serves to bind the
-    net80211 layer to a driver; this is described more
-    below.

-
The following states are defined for state machines:

-

-  

-  
Default/initial state. A vap in this state should not hold any dynamic
-      state (e.g. entries for associated stations in the node table). The driver
-      must quiesce the hardware; e.g. there should be no interrupts firing.

-  

-  
Scanning for a BSS or choosing a channel to operate on. Note that scanning
-      can also take place in other states (e.g. when background scanning is
-      active); this state is entered when initially bringing a vap to an
-      operational state or after an event such as a beacon miss (in station
-      mode).

-  

-  
Authenticating to an access point (in station mode). This state is
-      normally reached from IEEE80211_S_SCAN after
-      selecting a BSS, but may also be reached from
-      IEEE80211_S_ASSOC or
-      IEEE80211_S_RUN if the authentication handshake
-      fails.

-  

-  
Associating to an access point (in station mode). This state is reached
-      from IEEE80211_S_AUTH after successfully
-      authenticating or from IEEE80211_S_RUN if a
-      DisAssoc frame is received.

-  

-  
Doing Channel Availability Check (CAC). This state is entered only when
-      DFS is enabled and the channel selected for operation requires CAC.

-  

-  
Operational. In this state a vap can transmit data frames, accept requests
-      for stations associating, etc. Beware that data traffic is also gated by
-      whether the associated “port” is authorized. When
-      WPA/802.11i/802.1x is operational authorization may happen separately;
-      e.g. in station mode wpa_supplicant(8) must complete the
-      handshakes and plumb the necessary keys before a port is authorized. In
-      this state a BSS is operational and associated state is valid and may be
-      used; e.g. ic_bss and
-      ic_bsschan are guaranteed to be usable.

-  

-  
Channel Switch Announcement (CSA) is pending. This state is reached only
-      from IEEE80211_S_RUN when either a CSA is received
-      from an access point (in station mode) or the local station is preparing
-      to change channel. In this state traffic may be muted depending on the
-      Mute setting in the CSA.

-  

-  
Asleep to save power (in station mode). This state is reached only from
-      IEEE80211_S_RUN when power save operation is
-      enabled and the local station is deemed sufficiently idle to enter low
-      power mode.

-

-
Note that states are ordered (as shown above); e.g. a vap must be
-    in the IEEE80211_S_RUN or “greater”
-    before it can transmit frames. Certain net80211 data
-    are valid only in certain states; e.g. the iv_bsschan
-    that specifies the channel for the operating BSS should never be used except
-    in IEEE80211_S_RUN or greater.

-

-

-

-
State machine changes are typically handled internal to the
-    net80211 layer in response to
-    ioctl(2) requests, received frames, or external events
-    such as a beacon miss. The
-    ()
-    function is used to initiate a state machine change on a vap. The new state
-    and an optional argument are supplied. The request is initially processed to
-    handle coordination of multiple vaps. For example, only one vap at a time
-    can be scanning, if multiple vaps request a change to
-    IEEE80211_S_SCAN the first will be permitted to run
-    and the others will be
-    
-    until the scan operation completes at which time the selected channel will
-    be adopted. Similarly net80211 handles coordination
-    of combinations of vaps such as an AP and station vap where the station may
-    need to roam to follow the AP it is associated to (dragging along the AP vap
-    to the new channel). Another important coordination is the handling of
-    IEEE80211_S_CAC and
-    IEEE80211_S_CSA. No more than one vap can ever be
-    actively changing state at a time. In fact net80211
-    single-threads the state machine logic in a dedicated
-    taskqueue(9) thread that is also used to synchronize work
-    such as scanning and beacon miss handling.

-
After multi-vap scheduling/coordination is done the per-vap
-    iv_newstate method is called to carry out the state
-    change work. Drivers use this entry to setup private state and then dispatch
-    the call to the net80211 layer using the previously
-    defined method pointer (in OOP-parlance they call the “super
-    method” ).

-
net80211 handles two state changes
-    specially. On transition to IEEE80211_S_RUN the
-    IFF_DRV_OACTIVE bit on the vap's transmit queue is
-    cleared so traffic can flow. On transition to
-    IEEE80211_S_INIT any state in the scan cache
-    associated with the vap is flushed and any frames pending on the transmit
-    queue are flushed.

-

-

-

-
Drivers are expected to override the
-    iv_newstate method to interpose their own code and
-    handle setup work required by state changes. Otherwise drivers must call
-    ()
-    in response to being marked up through an
-    SIOCSIFFLAGS ioctl request and they should use
-    ()
-    and
-    ()
-    to implement suspend/resume support.

-
There is also an
-    ()
-    call to force all vaps to an IEEE80211_S_INIT state
-    but this should not be needed by a driver; control is usually handled by
-    net80211 or, in the case of card eject or vap
-    destroy, work will be initiated outside the driver.

-

-

-

-
ioctl(2), wpa_supplicant(8),
-    ieee80211(9), ifnet(9),
-    taskqueue(9)

-

-

-

-
The state machine concept was part of the original
-    ieee80211 code base that first appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_radiotap.9 3.html b/static/freebsd/man9/ieee80211_radiotap.9 3.html
deleted file mode 100644
index eb4f76f8..00000000
--- a/static/freebsd/man9/ieee80211_radiotap.9 3.html	
+++ /dev/null
@@ -1,248 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_RADIOTAP(9)Kernel Developer's ManualIEEE80211_RADIOTAP(9)

-

-

-

-
ieee80211_radiotap —
-    802.11 device packet capture support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-

-  

-  void
-  

-  ieee80211_radiotap_attach(struct
-    ieee80211com *, struct ieee80211_radiotap_header
-    *th, int tlen, uint32_t
-    tx_radiotap, struct ieee80211_radiotap_header
-    *rh, int rlen, uint32_t
-    rx_radiotap);

-
int
-  

-  ieee80211_radiotap_active_vap(struct
-    ieee80211vap *);

-
int
-  

-  ieee80211_radiotap_active(struct
-    ieee80211com *);

-
void
-  

-  ieee80211_radiotap_tx(struct
-    ieee80211vap *, struct
-    mbuf *);

-

-

-

-
The net80211 layer used by 802.11 drivers
-    includes support for a device-independent packet capture format called
-    radiotap that is understood by tools such as
-    tcpdump(1). This facility is designed for capturing 802.11
-    traffic, including information that is not part of the normal 802.11 frame
-    structure.

-
Radiotap was designed to balance
-    the desire for a hardware-independent, extensible capture format against the
-    need to conserve CPU and memory bandwidth on embedded systems. These
-    considerations led to a format consisting of a standard preamble followed by
-    an extensible bitmap indicating the presence of optional capture fields. A
-    net80211 device driver supporting
-    radiotap defines two packed structures that it shares
-    with net80211. These structures embed an instance of
-    a ieee80211_radiotap_header structure at the
-    beginning, with subsequent fields in the appropriate order, and macros to
-    set the bits of the it_present bitmap to indicate
-    which fields exist and are filled in by the driver. This information is then
-    supplied through the
-    ()
-    call after a successful
-    ()
-    request.

-
With radiotap setup, drivers
-    just need to fill in per-packet capture state for frames sent/received and
-    dispatch capture state in the transmit path (since control is not returned
-    to the net80211 layer before the packet is handed to
-    the device). To minimize overhead this work should be done only when one or
-    more processes are actively capturing data; this is checked with one of
-    ()
-    and
-    ().
-    In the transmit path capture work looks like this:

-

-
if (ieee80211_radiotap_active_vap(vap)) {
-	... /* record transmit state */
-	ieee80211_radiotap_tx(vap, m); /* capture transmit event */
-}

-

-
While in the receive path capture is handled in
-    net80211 but state must be captured before
-    dispatching a frame:

-

-
if (ieee80211_radiotap_active(ic)) {
-	... /* record receive state */
-}
-...
-ieee80211_input(...);	/* packet capture handled in net80211 */

-

-
The following fields are defined for
-    radiotap, in the order in which they should appear in
-    the buffer supplied to net80211.

-

-  

-  
This field contains the unsigned 64-bit value, in microseconds, of the
-      MAC's 802.11 Time Synchronization Function (TSF). In theory, for each
-      received frame, this value is recorded when the first bit of the MPDU
-      arrived at the MAC. In practice, hardware snapshots the TSF otherwise and
-      one cannot assume this data is accurate without driver adjustment.

-  

-  
This field contains a single unsigned 8-bit value, containing one or more
-      of these bit flags:
-    

-      

-      
Frame was sent/received during the Contention Free Period (CFP).

-      

-      
Frame was sent/received with short preamble.

-      

-      
Frame was encrypted.

-      

-      
Frame was an 802.11 fragment.

-      

-      
Frame contents includes the FCS.

-      

-      
Frame contents potentially has padding between the 802.11 header and
-          the data payload to align the payload to a 32-bit boundary.

-      

-      
Frame was received with an invalid FCS.

-      

-      
Frame was sent/received with Short Guard Interval.

-    

-  

-  

-  
This field contains a single unsigned 8-bit value that is the data rate.
-      Legacy rates are in units of 500Kbps. MCS rates (used on 802.11n/HT
-      channels) have the high bit set and the MCS in the low 7 bits.

-  

-  
This field contains two unsigned 16-bit values. The first value is the
-      center frequency for the channel the frame was sent/received on. The
-      second value is a bitmap containing flags that specify channel properties.
-    
This field is deprecated in favor of
-        IEEE80211_RADIOTAP_XCHANNEL but may be used to
-        save space in the capture file for legacy devices.

-  

-  

-  
This field contains a single signed 8-bit value that indicates the RF
-      signal power at the antenna, in decibels difference from 1mW.

-  

-  
This field contains a single signed 8-bit value that indicates the RF
-      noise power at the antenna, in decibels difference from 1mW.

-  

-  
Transmit power expressed as decibels from a 1mW reference. This field is a
-      single signed 8-bit value. This is the absolute power level measured at
-      the antenna port.

-  

-  
This field contains a single unsigned 8-bit value that specifies which
-      antenna was used to transmit or receive the frame. Antenna numbering is
-      device-specific but typically the primary antenna has the lowest number.
-      On transmit a value of zero may be seen which typically means antenna
-      selection is left to the device.

-  

-  
This field contains a single unsigned 8-bit value that indicates the RF
-      signal power at the antenna, in decibels difference from an arbitrary,
-      fixed reference.

-  

-  
This field contains a single unsigned 8-bit value that indicates the RF
-      noise power at the antenna, in decibels difference from an arbitrary,
-      fixed reference.

-  

-  
This field contains four values: a 32-bit unsigned bitmap of flags that
-      describe the channel attributes, a 16-bit unsigned frequency in MHz
-      (typically the channel center), an 8-bit unsigned IEEE channel number, and
-      a signed 8-bit value that holds the maximum regulatory transmit power cap
-      in .5 dBm (8 bytes total). Channel flags are defined in:
-      <net80211/_ieee80211.h>
-      (only a subset are found in
-      <net80211/ieee80211_radiotap.h>
-      ). This property supersedes
-      IEEE80211_RADIOTAP_CHANNEL and is the only way to
-      completely express all channel attributes and the mapping between channel
-      frequency and IEEE channel number.

-

-

-

-

-
Radiotap receive definitions for the Intersil Prism driver:

-

-
#define WI_RX_RADIOTAP_PRESENT \
-        ((1 << IEEE80211_RADIOTAP_TSFT) \
-         (1 << IEEE80211_RADIOTAP_FLAGS) | \
-         (1 << IEEE80211_RADIOTAP_RATE) | \
-         (1 << IEEE80211_RADIOTAP_CHANNEL) | \
-         (1 << IEEE80211_RADIOTAP_DB_ANTSIGNAL) | \
-         (1 << IEEE80211_RADIOTAP_DB_ANTNOISE))
-
-struct wi_rx_radiotap_header {
-        struct ieee80211_radiotap_header wr_ihdr;
-        uint64_t       wr_tsf;
-        uint8_t        wr_flags;
-        uint8_t        wr_rate;
-        uint16_t       wr_chan_freq;
-        uint16_t       wr_chan_flags;
-        uint8_t        wr_antsignal;
-        uint8_t        wr_antnoise;
-} __packed __aligned(8);

-

-
and transmit definitions for the Atheros driver:

-

-
#define ATH_TX_RADIOTAP_PRESENT (               \
-        (1 << IEEE80211_RADIOTAP_FLAGS)         | \
-        (1 << IEEE80211_RADIOTAP_RATE)          | \
-        (1 << IEEE80211_RADIOTAP_DBM_TX_POWER)  | \
-        (1 << IEEE80211_RADIOTAP_ANTENNA)       | \
-        (1 << IEEE80211_RADIOTAP_XCHANNEL)      | \
-        0)
-
-struct ath_tx_radiotap_header {
-        struct ieee80211_radiotap_header wt_ihdr;
-        uint8_t        wt_flags;
-        uint8_t        wt_rate;
-        uint8_t        wt_txpower;
-        uint8_t        wt_antenna;
-        uint32_t       wt_chan_flags;
-        uint16_t       wt_chan_freq;
-        uint8_t        wt_chan_ieee;
-        int8_t         wt_chan_maxpow;
-} __packed;

-

-

-

-

-
tcpdump(1), bpf(4),
-    ieee80211(9)

-

-

-

-
The ieee80211_radiotap definitions first
-    appeared in NetBSD 1.5.

-

-

-

-
The original version of this manual page was written by
-    Bruce M. Simpson
-    <bms@FreeBSD.org> and
-    Darron Broad
-    <darron@kewl.org>.

-

-

-
-  
-    
-    
-  
-
March 11, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_regdomain.9 3.html b/static/freebsd/man9/ieee80211_regdomain.9 3.html
deleted file mode 100644
index b0233133..00000000
--- a/static/freebsd/man9/ieee80211_regdomain.9 3.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_REGDOMAIN(9)Kernel Developer's ManualIEEE80211_REGDOMAIN(9)

-

-

-

-
ieee80211_regdomain —
-    802.11 regulatory support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>
-  

-  #include
-    <net80211/ieee80211_regdomain.h>

-

-  

-  int
-  

-  ieee80211_init_channels(struct
-    ieee80211com *, const struct ieee80211_regdomain
-    *, const uint8_t bands[]);

-
void
-  

-  ieee80211_sort_channels(struct
-    ieee80211_channel *, int nchans);

-
struct ieee80211_appie *
-  

-  ieee80211_alloc_countryie(struct
-    ieee80211com *);

-

-

-

-
The net80211 software layer provides a
-    support framework for drivers that includes comprehensive regulatory
-    support. net80211 provides mechanisms that enforce
-     by privileged user applications.

-
Drivers define a device's capabilities and
-    can intercept and control regulatory changes requested through
-    net80211. The initial regulatory state, including
-    the channel list, must be filled in by the driver before calling
-    ().
-    The channel list should reflect the set of channels the device is
-    
-    for use on. This list may also be requested later through the
-    ic_getradiocaps method in the
-    ieee80211com structure. The
-    ()
-    function is provided as a rudimentary fallback for drivers that do not (or
-    cannot) fill in a proper channel list. Default regulatory state is supplied
-    such as the regulatory SKU, ISO country code, location (e.g. indoor,
-    outdoor), and a set of frequency bands the device is capable of operating
-    on. net80211 populates the channel table in
-    ic_channels with a default set of channels and
-    capabilities. Note this mechanism should be used with care as any mismatch
-    between the channel list created and the device's capabilities can result in
-    runtime errors (e.g. a request to operate on a channel the device does not
-    support). The SKU and country information are used for generating 802.11h
-    protocol elements and related operation such as for 802.11d; mis-setup by a
-    driver is not fatal, only potentially confusing.

-
Devices that do not have a
-    fixed/default regulatory state can set the regulatory SKU to
-    SKU_DEBUG and country code to
-    CTRY_DEFAULT and leave proper setup to user
-    applications. If default settings are known they can be installed and/or an
-    event can be dispatched to user space using
-    ()
-    so that devd(8) will do the appropriate setup work at
-    system boot (or device insertion).

-
The channel table is sorted to
-    optimize lookups using the
-    ()
-    routine. This should be done whenever the channel table contents are
-    modified.

-
The
-    ()
-    function allocates an information element as specified by 802.11h. Because
-    this is expensive to generate it is cached in
-    ic_countryie and generated only when regulatory state
-    changes. Drivers that call
-    ieee80211_alloc_countryie() directly should not help
-    with this caching; doing so may confuse the net80211
-    layer.

-

-

-

-
Drivers can control regulatory change requests by overriding the
-    ic_setregdomain method that checks change requests.
-    While drivers can reject any request that does not meet its requirements it
-    is recommended that one be lenient in what is accepted and, whenever
-    possible, instead of rejecting a request, alter it to be correct. For
-    example, if the transmit power cap for a channel is too high the driver can
-    either reject the request or (better) reduce the cap to be compliant.
-    Requests that include unacceptable channels should cause the request to be
-    rejected as otherwise a mismatch may be created between application state
-    and the state managed by net80211. The exact rules
-    by which to operate are still being codified.

-

-

-

-
regdomain(5), ifconfig(8),
-    ieee80211(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_scan.9 3.html b/static/freebsd/man9/ieee80211_scan.9 3.html
deleted file mode 100644
index d331f5d8..00000000
--- a/static/freebsd/man9/ieee80211_scan.9 3.html	
+++ /dev/null
@@ -1,291 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_SCAN(9)Kernel Developer's ManualIEEE80211_SCAN(9)

-

-

-

-
ieee80211_scan —
-    802.11 scanning support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-

-  

-  int
-  

-  ieee80211_start_scan(struct
-    ieee80211vap *, int flags, u_int
-    duration, u_int mindwell, u_int
-    maxdwell, u_int nssid, const
-    struct ieee80211_scan_ssid ssids[]);

-
int
-  

-  ieee80211_check_scan(struct
-    ieee80211vap *, int flags, u_int
-    duration, u_int mindwell, u_int
-    maxdwell, u_int nssid, const
-    struct ieee80211_scan_ssid ssids[]);

-
int
-  

-  ieee80211_check_scan_current(struct
-    ieee80211vap *);

-
int
-  

-  ieee80211_bg_scan(struct
-    ieee80211vap *,
-    int);

-
int
-  

-  ieee80211_cancel_scan(struct
-    ieee80211vap *);

-
int
-  

-  ieee80211_cancel_scan_any(struct
-    ieee80211vap *);

-
int
-  

-  ieee80211_scan_next(struct
-    ieee80211vap *);

-
int
-  

-  ieee80211_scan_done(struct
-    ieee80211vap *);

-
int
-  

-  ieee80211_probe_curchan(struct
-    ieee80211vap *,
-    int);

-
void
-  

-  ieee80211_add_scan(struct ieee80211vap
-    *, const struct ieee80211_scanparams *,
-    const struct ieee80211_frame *, int
-    subtype, int rssi, int
-    noise);

-
void
-  

-  ieee80211_scan_timeout(struct
-    ieee80211com *);

-
void
-  

-  ieee80211_scan_assoc_fail(struct
-    ieee80211vap *, const uint8_t
-    mac[IEEE80211_ADDR_LEN], int reason);

-
void
-  

-  ieee80211_scan_flush(struct
-    ieee80211vap *);

-
void
-  

-  ieee80211_scan_iterate(struct
-    ieee80211vap *, ieee80211_scan_iter_func,
-    void *);

-
void
-  

-  ieee80211_scan_dump_channels(const
-    struct ieee80211_scan_state *);

-
void
-  

-  ieee80211_scanner_register(enum
-    ieee80211_opmode, const struct ieee80211_scanner
-    *);

-
void
-  

-  ieee80211_scanner_unregister(enum
-    ieee80211_opmode, const struct ieee80211_scanner
-    *);

-
void
-  

-  ieee80211_scanner_unregister_all(const
-    struct ieee80211_scanner *);

-
const struct ieee80211_scanner *
-  

-  ieee80211_scanner_get(enum
-    ieee80211_opmode);

-

-

-

-
The net80211 software layer provides an
-    extensible framework for scanning. Scanning is the procedure by which a
-    station locates a BSS to join (in infrastructure and IBSS mode), or a
-    channel to use (when operating as an AP or an IBSS master). Scans are either
-    “active” or “passive”. An active scan causes one
-    or more ProbeRequest frames to be sent on visiting each channel. A passive
-    request causes each channel in the scan set to be visited but no frames to
-    be transmitted; the station only listens for traffic. Note that active
-    scanning may still need to listen for traffic before sending ProbeRequest
-    frames depending on regulatory constraints.

-
A scan operation involves constructing a set of channels to
-    inspect (the scan set), visiting each channel and collecting information
-    (e.g. what BSS are present), and then analyzing the results to make
-    decisions such as which BSS to join. This process needs to be as fast as
-    possible so net80211 does things like intelligently
-    construct scan sets and dwell on a channel only as long as necessary. Scan
-    results are cached and the scan cache is used to avoid scanning when
-    possible and to enable roaming between access points when operating in
-    infrastructure mode.

-
Scanning is handled by pluggable modules that
-    implement 
-    per-operating mode. The core scanning support provides an infrastructure to
-    support these modules and exports a common API to the rest of the
-    net80211 layer. Policy modules decide what channels
-    to visit, what state to record to make decisions, and selects the final
-    station/channel to return as the result of a scan.

-
Scanning is done synchronously when
-    initially bringing a vap to an operational state and optionally in the
-    background to maintain the scan cache for doing roaming and rogue AP
-    monitoring. Scanning is not tied to the net80211
-    state machine that governs vaps except for linkage to the
-    IEEE80211_S_SCAN state. Only one vap at a time may
-    be scanning; this scheduling policy is handled in
-    ()
-    and is transparent to scanning code.

-
Scanning is controlled by a set of parameters that (potentially)
-    constrains the channel set and any desired SSID's and BSSID's.
-    net80211 comes with a standard scanner module that
-    works with all available operating modes and supports “background
-    scanning” and “roaming” operation.

-

-

-

-
Scanning modules use a registration mechanism to hook into the
-    net80211 layer. Use
-    ()
-    to register a scan module for a particular operating mode and
-    ()
-    or
-    ()
-    to clear entries (typically on module unload). Only one scanner module can
-    be registered at any time for an operating mode.

-

-

-

-
Scanning operations are usually managed by the
-    net80211 layer. Drivers must provide
-    ic_scan_start and ic_scan_stop
-    methods that are called at the start of a scan and when the work is done;
-    these should handle work such as enabling receive of Beacon and
-    ProbeResponse frames and disable any BSSID matching. The
-    ic_set_channel method is used to change channels while
-    scanning. net80211 will generate ProbeRequest frames
-    and transmit them using the ic_raw_xmit method.
-    Frames received while scanning are dispatched to
-    net80211 using the normal receive path. Devices that
-    off-load scan work to firmware most easily mesh with
-    net80211 by operating on a channel-at-a-time basis
-    as this defers control to net80211's scan machine
-    scheduler. But multi-channel scanning is supported if the driver manually
-    dispatches results using ieee80211_add_scan()
-    routine to enter results into the scan cache.

-

-

-

-
Scan requests occur by way of the
-    IEEE80211_SCAN_REQUEST ioctl or through a change in
-    a vap's state machine that requires scanning. In both cases the scan cache
-    can be checked first and, if it is deemed suitably “warm” then
-    it's contents are used without leaving the current channel. To start a scan
-    without checking the cache
-    ()
-    can be called; otherwise
-    ()
-    can be used to first check the scan cache, kicking off a scan if the cache
-    contents are out of date. There is also
-    ()
-    which is a shorthand for using previously set scan parameters for checking
-    the scan cache and then scanning.

-
Background scanning is done using
-    ()
-    in a co-routine fashion. The first call to this routine will start a
-    background scan that runs for a limited period of time before returning to
-    the BSS channel. Subsequent calls advance through the scan set until all
-    channels are visited. Typically these later calls are timed to allow receipt
-    of frames buffered by an access point for the station.

-
A scan operation can be canceled using
-    ()
-    if it was initiated by the specified vap, or
-    ()
-    to force termination regardless which vap started it. These requests are
-    mostly used by net80211 in the transmit path to
-    cancel background scans when frames are to be sent. Drivers should not need
-    to use these calls (or most of the calls described on this page).

-
The
-    ()
-    and
-    ()
-    routines do explicit iteration through the scan set and should not normally
-    be used by drivers.
-    ()
-    handles the work of transmitting ProbeRequest frames when visiting a channel
-    during an active scan. When the channel attributes are marked with
-    IEEE80211_CHAN_PASSIVE this function will arrange
-    that before any frame is transmitted 802.11 traffic is first received (in
-    order to comply with regulatory constraints).

-
Min/max dwell time parameters are used to constrain time spent
-    visiting a channel. The maximum dwell time constrains the time spent
-    listening for traffic. The minimum dwell time is used to reduce this
-    time--when it is reached and one or more frames have been received then an
-    immediate channel change will be done. Drivers can override this behaviour
-    through the iv_scan_mindwell method.

-

-

-

-
The scan cache contents are managed by the scan policy module and
-    are opaque outside this module. The net80211 scan
-    framework defines API's for interacting. The validity of the scan cache
-    contents are controlled by iv_scanvalid which is
-    exported to user space through the
-    IEEE80211_SCAN_VALID request.

-
The cache contents can be explicitly
-    flushed with
-    ()
-    or by setting the IEEE80211_SCAN_FLUSH flag when
-    starting a scan operation.

-
Scan cache entries are created with the
-    ()
-    routine; usually on receipt of Beacon or ProbeResponse frames. Existing
-    entries are typically updated based on the latest information though some
-    information such as RSSI and noise floor readings may be combined to present
-    an average.

-
The cache contents is aged through
-    ()
-    calls. Typically these happen together with other station table activity;
-    every IEEE80211_INACT_WAIT seconds (default 15).

-
Individual cache entries are
-    marked usable with
-    ()
-    and faulty with
-    ()
-    with the latter taking an argument to identify if there was no response to
-    Authentication/Association requests or if a negative response was received
-    (which might hasten cache eviction or blacklist the entry).

-
The cache contents can be viewed using
-    the
-    ()
-    call. Cache entries are exported in a public format that is exported to user
-    applications through the IEEE80211_SCAN_RESULTS
-    request.

-

-

-

-
ioctl(2), ieee80211(9),
-    ieee80211_proto(9)

-

-

-
-  
-    
-    
-  
-
March 29, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/ieee80211_vap.9 3.html b/static/freebsd/man9/ieee80211_vap.9 3.html
deleted file mode 100644
index 0ae1b2b1..00000000
--- a/static/freebsd/man9/ieee80211_vap.9 3.html	
+++ /dev/null
@@ -1,116 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_VAP(9)Kernel Developer's ManualIEEE80211_VAP(9)

-

-

-

-
net80211_vap —
-    802.11 network layer virtual radio support

-

-

-

-
#include
-    <net80211/ieee80211_var.h>

-
int
-  

-  ieee80211_vap_setup(struct
-    ieee80211com *, struct ieee80211vap *,
-    const char name[IFNAMSIZ], int
-    unit, int opmode, int
-    flags, const uint8_t bssid[IEEE80211_ADDR_LEN],
-    const uint8_t macaddr[IEEE80211_ADDR_LEN]);

-
int
-  

-  ieee80211_vap_attach(struct
-    ieee80211vap *, ifm_change_cb_t media_change,
-    ifm_stat_cb_t media_stat);

-
void
-  

-  ieee80211_vap_detach(struct
-    ieee80211vap *);

-

-

-

-
The net80211 software layer provides a
-    support framework for drivers that includes a virtual radio API that is
-    exported to users through network interfaces (aka vaps) that are cloned from
-    the underlying device. These interfaces have an operating mode (station,
-    adhoc, hostap, wds, monitor, etc.) that is fixed for the lifetime of the
-    interface. Devices that can support multiple concurrent interfaces allow
-    multiple vaps to be cloned.

-
The virtual radio interface defined by the
-    net80211 layer means that drivers must be structured
-    to follow specific rules. Drivers that support only a single interface at
-    any time must still follow these rules.

-
The virtual radio architecture splits state between a single
-    per-device ieee80211com structure and one or more
-    ieee80211vap structures. Vaps are created with the
-    SIOCIFCREATE2 request. This results in a call into
-    the driver's ic_vap_create method where the driver can
-    decide if the request should be accepted.

-
The vap creation process is done in three
-    steps. First the driver allocates the data structure with
-    malloc(9). This data structure must have an
-    ieee80211vap structure at the front but is usually
-    extended with driver-private state. Next the vap is setup with a call to
-    ().
-    This request initializes net80211 state but does not
-    activate the interface. The driver can then override methods setup by
-    net80211 and setup driver resources before finally
-    calling
-    ()
-    to complete the process. Both these calls must be done without holding any
-    driver locks as work may require the process block/sleep.

-
A vap is deleted when an
-    SIOCIFDESTROY ioctl request is made or when the
-    device detaches (causing all associated vaps to automatically be deleted).
-    Delete requests cause the ic_vap_delete method to be
-    called. Drivers must quiesce the device before calling
-    ()
-    to deactivate the vap and isolate it from activities such as requests from
-    user applications. The driver can then reclaim resources held by the vap and
-    re-enable device operation. The exact procedure for quiescing a device is
-    unspecified but typically it involves blocking interrupts and stopping
-    transmit and receive processing.

-

-

-

-
Drivers are responsible for deciding if multiple vaps can be
-    created and how to manage them. Whether or not multiple concurrent vaps can
-    be supported depends on a device's capabilities. For example, multiple
-    hostap vaps can usually be supported but many devices do not support
-    assigning each vap a unique BSSID. If a device supports hostap operation it
-    can usually support concurrent station mode vaps but possibly with
-    limitations such as losing support for hardware beacon miss support. Devices
-    that are capable of hostap operation and can send and receive 4-address
-    frames should be able to support WDS vaps together with an ap vap. But in
-    contrast some devices cannot support WDS vaps without at least one ap vap
-    (this however can be finessed by forcing the ap vap to not transmit beacon
-    frames). All devices should support the creation of any number of monitor
-    mode vaps concurrent with other vaps but it is the responsibility of the
-    driver to allow this.

-
An important consequence of supporting multiple concurrent vaps is
-    that a driver's iv_newstate method must be written to
-    handle being called for each vap. Where necessary, drivers must track
-    private state for all vaps and not just the one whose state is being changed
-    (e.g. for handling beacon timers the driver may need to know if all vaps
-    that beacon are stopped before stopping the hardware timers).

-

-

-

-
ieee80211(9), ifnet(9),
-    malloc(9)

-

-

-
-  
-    
-    
-  
-
August 4, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/iflib.9 4.html b/static/freebsd/man9/iflib.9 4.html
deleted file mode 100644
index 86e00305..00000000
--- a/static/freebsd/man9/iflib.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
IFLIB(9)Kernel Developer's ManualIFLIB(9)

-

-

-

-
iflib — Network
-    Interface Driver Framework

-

-

-

-
iflib is a framework for writing network
-    interface drivers for FreeBSD. It is designed to
-    remove a large amount of the boilerplate that is often needed for modern
-    network interface devices, allowing driver authors to focus on the specific
-    code needed for their hardware.

-
There are three logical components to
-    iflib each of which is described in its own manual
-    page. These are:

-

-  
iflibdi(9)

-  
Device-independent functions, used to integrate
-      iflib into the rest of the
-      FreeBSD networking stack.

-  
iflibdd(9)

-  
Device-dependent functions, used when writing new
-      iflib based drivers.

-  
iflibtxrx(9)

-  
Device-dependent transmit and receive functions, used when writing new
-      iflib based drivers.

-

-

-

-

-
iflib(4), iflibdd(9),
-    iflibdi(9), iflibtxrx(9),
-    ifnet(9)

-

-

-

-
Benno Rice
-    <benno@FreeBSD.org>

-

-

-
-  
-    
-    
-  
-
September 20, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/iflibdd.9 4.html b/static/freebsd/man9/iflibdd.9 4.html
deleted file mode 100644
index a3986f5d..00000000
--- a/static/freebsd/man9/iflibdd.9 4.html	
+++ /dev/null
@@ -1,367 +0,0 @@
-
-  
-    
-    
-    
-  
-
IFLIBDD(9)Kernel Developer's ManualIFLIBDD(9)

-

-

-

-
iflibdd — Device
-    Dependent Configuration Functions

-

-

-

-
#include
-    <ifdi_if.h>

-

-

-

-

-
Mandatory Functions

-
int
-  

-  ifdi_tx_queues_alloc(if_ctx_t
-    ctx, caddr_t *vaddrs, uint64_t
-    *paddrs, int ntxqs, int
-    ntxqsets);

-
int
-  

-  ifdi_rx_queues_alloc(if_ctx_t
-    ctx, caddr_t *vaddrs, uint64_t
-    *paddrs, int nrxqs, int
-    nrxqsets);

-
int
-  

-  ifdi_queues_free(if_ctx_t
-  ctx);

-

-

-
Optional Functions

-
int
-  

-  ifdi_txq_setup(if_ctx_t ctx,
-    uint16_t qid);

-
int
-  

-  ifdi_rxq_setup(if_ctx_t ctx,
-    uint16_t qid);

-

-

-

-

-

-
Mandatory Functions

-
int
-  

-  ifdi_attach_pre(if_ctx_t
-  ctx);

-
int
-  

-  ifdi_attach_post(if_ctx_t
-  ctx);

-
int
-  

-  ifdi_detach(if_ctx_t ctx);

-

-

-
Optional Functions

-
void
-  

-  ifdi_vlan_register(if_ctx_t ctx,
-    uint16_t vtag);

-
void
-  

-  ifdi_vlan_unregister(if_ctx_t
-    ctx, uint16_t vtag);

-
int
-  

-  ifdi_suspend(if_ctx_t ctx);

-
int
-  

-  ifdi_resume(if_ctx_t ctx);

-

-

-
Device Configuration Functions

-

-

-
Mandatory Functions

-
void
-  

-  ifdi_init(if_ctx_t ctx);

-
void
-  

-  ifdi_stop(if_ctx_t ctx);

-
void
-  

-  ifdi_multi_set(if_ctx_t
-  ctx);

-
int
-  

-  ifdi_mtu_set(if_ctx_t ctx,
-    uint32_t mtu);

-
void
-  

-  ifdi_media_status(if_ctx_t ctx,
-    struct ifmediareq *ifr);

-
int
-  

-  ifdi_media_change(if_ctx_t
-  ctx);

-
void
-  

-  ifdi_promisc_set(if_ctx_t ctx,
-    int flags);

-
uint64_t
-  

-  ifdi_get_counter(if_ctx_t ctx,
-    ift_counter cnt);

-
void
-  

-  ifdi_update_admin_status(if_ctx_t
-    ctx);

-

-

-
Optional Functions

-
void
-  

-  ifdi_media_set(if_ctx_t
-  ctx);

-

-

-

-

-

-
Mandatory Functions

-
void
-  

-  ifdi_intr_enable(if_ctx_t
-  ctx);

-
void
-  

-  ifdi_queue_intr_enable(if_ctx_t
-    ctx, uint16_t qid);

-
void
-  

-  ifdi_intr_disable(if_ctx_t
-  ctx);

-

-

-

-
init
-  

-  iov_init(if_ctx_t ctx,
-    uint16_t num_vfs, const nvlist_t
-    *params);

-
void
-  

-  iov_uinit(if_ctx_t ctx);

-
void
-  

-  ifdi_vflr_handle(if_ctx_t
-  ctx);

-
int
-  

-  ifdi_vf_add(if_ctx_t ctx,
-    uint16_t vfnum, const nvlist_t
-    *params);

-

-

-
Optional Functions

-
void
-  

-  ifdi_link_intr_enable(if_ctx_t
-    ctx);

-

-

-

-
void
-  

-  ifdi_timer(if_ctx_t ctx);

-
void
-  

-  ifdi_watchdog_reset(if_ctx_t
-    ctx);

-

-

-
Additional Functions

-
void
-  

-  ifdi_led_func(if_ctx_t ctx,
-    int onoff);

-
int
-  

-  ifdi_sysctl_int_delay(if_ctx_t
-    ctx, if_int_delay_info_t iidi);

-
int
-  

-  ifdi_i2c_req(if_ctx_t ctx,
-    struct ifi2creq *req);

-

-

-

-

-
The above named functions are device dependent configuration
-    functions. These routines are registered with iflib by the driver and are
-    called from the corresponding iflib function to configure device specific
-    functions and registers.

-

-

-

-

-

-

-  
()

-  
Mandatory function that is called during iflib_attach to allocate transmit
-      queues. vaddrs and paddrs are arrays of virtual and physical addresses
-      respectively of the hardware transmit queues. ntxqs is the number of
-      queues per qset. ntxqsets is the number of qsets.

-  
()

-  
Mandatory function that is called during iflib_attach to allocate receive
-      queues. vaddrs and paddrs are arrays of virtual and physical addresses
-      respectively of the hardware receive queues. nrxqs is the number of queues
-      per qset. nrxqsets is the number of qsets.

-  
()

-  
Mandatory function that frees the allocated queues and associated transmit
-      buffers.

-  
()

-  
Optional function for each transmit queue that handles device specific
-      initialization.

-  
()

-  
Optional function for each receive queue that handles device specific
-      initialization.

-

-

-

-

-

-  
()

-  
Mandatory function implemented by the driver to perform any attach logic
-      that procedes interrupt and queue allocation, queue setup, and interrupt
-      assignment.

-  
()

-  
Mandatory function implemented by the driver to perform any attach logic
-      that occurs after ifdi_attach_pre, and iflib's queue setup and MSI/MSIX(X)
-      or legacy interrupt assignment.

-  
()

-  
Mandatory function that frees any resources allocated by the driver in
-      ifdi_attach_pre and ifdi_attach_post.

-  
()

-  
Optional function called by the VLAN config eventhandler.
-      vtag is the new VLAN tag.

-  
()

-  
Optional function called by the VLAN unconfig eventhandler.

-  
()

-  
Optional function that suspends the driver.

-  
()

-  
Optional function that resumes a driver.

-

-

-

-
Device Configuration Functions

-

-  
()

-  
Mandatory function that will initialize and bring up the hardware. For
-      example, it will reset the chip and enable the receiver unit. It should
-      mark the interface running, but not active (
-      IFF_DRV_RUNNING, ~IIF_DRV_OACTIVE
-      ).

-  
()

-  
Mandatory function that should disable all traffic on the interface by
-      issuing a global reset on the MAC and deallocating the TX and RX
-    buffers.

-  
()

-  
Programs the interfaces multicast addresses

-  
()

-  
Media Ioctl Callback. Function is called whenever the user queries the
-      status of the interface using ifconfig(8). The driver
-      sets the appropriate link type and speed in ifmr->ifm_active.

-  
()

-  
Sets the mtu interface to the value of the second function parameter
-    mtu.

-  
()

-  
Function is called when the user changes speed/duplex using the
-      media/mediaopt option with ifconfig(8).

-  
()

-  
Enables or disables promisc settings depending upon the flags value.
-      flags contains the interface's
-      ifnet(9) flags.

-  
()

-  
Returns the value for counter cnt depending upon counter type.

-  
()

-  
Sets the link_up state to TRUE or FALSE depending upon the OS link state.
-      A real check of the hardware only happens with a link interrupt.

-  
()

-  
Need to define

-

-

-

-

-

-  
()

-  
Mandatory function that enables all interrupts.

-  
()

-  
Mandatory function that disables all interrupts.

-  
()

-  
Mandatory function that enables interrupts on queue qid.

-  
()

-  
Initialize num_vfs VFs.

-  
()

-  
Tear down the context for all VFs.

-  
()

-  
Handle any VFs that have reset themselves via a Function Level Reset
-      (FLR).

-  
()

-  
Set parameters in params in VF vfnum.

-

-

-

-

-

-  
()

-  
Optional timer routine that will be run every 500ms.

-  
()

-  
Optional function to run when a transmit queue is hung.

-

-

-

-
Additional Functions

-

-  
()

-  

-  
()

-  

-  
()

-  

-

-

-

-

-

-
ifconfig(8), iflibdi(9),
-    iflibtxrx(9), ifnet(9)

-

-

-

-
This manual page was written by Nicole
-    Graziano

-

-

-
-  
-    
-    
-  
-
May 3, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/iflibdi.9 4.html b/static/freebsd/man9/iflibdi.9 4.html
deleted file mode 100644
index 0c074e67..00000000
--- a/static/freebsd/man9/iflibdi.9 4.html	
+++ /dev/null
@@ -1,250 +0,0 @@
-
-  
-    
-    
-    
-  
-
IFLIBDI(9)Kernel Developer's ManualIFLIBDI(9)

-

-

-

-
iflibdi — Device
-    Independent Configuration Functions

-

-

-

-
#include
-    <ifdi_if.h>

-

-
Device Independent Functions

-
int
-  

-  iflib_device_attach(device_t
-    dev);

-
int
-  

-  iflib_device_detach(device_t
-    dev);

-
int
-  

-  iflib_device_suspend(device_t
-    dev);

-
int
-  

-  iflib_device_resume(device_t
-    dev);

-
int
-  

-  iflib_device_register(device_t
-    dev, void *softc,
-    if_shared_ctx_t sctx, if_ctx_t
-    *ctxp);

-
int
-  

-  iflib_device_deregister(if_ctx_t
-    ctx);

-
int
-  

-  iflib_irq_alloc(if_ctx_t ctx,
-    if_irq_t irq_info, int rid,
-    driver_filter_t filter, void
-    *filter_arg, driver_intr_t handler,
-    void *arg, char *name);

-
int
-  

-  iflib_irq_alloc_generic(if_ctx_t
-    ctx, if_irq_t irq, int
-    rid, intr_type_t type,
-    driver_filter_t *filter, void
-    *filter_arg, int qid, char
-    *name);

-
void
-  

-  iflib_led_create(if_ctx_t
-  ctx);

-
void
-  

-  iflib_tx_intr_deferred(if_ctx_t
-    ctx, int txqid);

-
void
-  

-  iflib_rx_intr_deferred(if_ctx_t
-    ctx, int rxqid);

-
void
-  

-  iflib_link_intr_deferred(if_ctx_t
-    ctx);

-
void
-  

-  iflib_link_state_change(if_ctx_t
-    ctx, int linkstate);

-
void
-  

-  iflib_add_int_delay_sysctl(if_ctx_t
-    ctx, const char *, const char
-    *, if_int_delay_info_t,
-    int, int);

-

-

-

-
extern struct if_txrx

-

-

-

-

-
The if_ctx_t Structure is the device independent data
-    structure that contains statistics and identifying information used to
-    transmit and receive data packets. The interface is associated with an array
-    of queues assigned sequentially. Each queue has its own transmit
-    (iflib_txq_t) and receive (iflib_rxq_t) queue. The transmit queue is used to
-    hold packets while the interface is in the process of sending another. The
-    receive queue is used to receive packets that are awaiting processing.

-

-

-
The fields of struct if_ctx_t are as
-    follows:

-

-

-  
if_softc

-  
(void) A pointer to the driver's private state
-      block.

-  
ifc_dev

-  
(device_t) The underlying device structure.

-  
ifc_ip

-  
(if_t) A link back to the interface structure

-  
ifc_cpus

-  
(cpuset_t)

-  
ifc_mutex

-  
(struct mtx) Mutex lock used to maintain data
-      integrity

-  
ifc_mtx_name

-  
(char *) The name of the mutex

-  
ifc_txqs

-  
(iflib_txq_t) Device independent transmit queue
-      maintained internally by iflib

-  
ifc_rxqs

-  
(iflib_rxq_t) Device independent receive queue
-      maintained internally by iflib

-  
ifc_qsets

-  
(iflib_qset_t) Output queue that contains a single
-      transmit (ifc_txq_t) and receive (ifc_rxq_t) queue

-  
ifc_if_flags

-  
(uint32_t) Flags describing the operational
-      parameter of the interface

-  
ifc_in_detach

-  
(int)

-  
-  
(int) Describes the current link state of the
-      Ethernet interface. Its possible values are either active or
-    inactive.

-  
-  
(int)

-  
ifc_vlan_attach_event

-  
(eventhandler_tag)

-  
ifc_vlan_detach_event

-  
(eventhandler_tag)

-  
ifc_pause_frames

-  
(int)

-  
ifc_watchdog_events

-  
(int)

-  
ifc_mac

-  
(uint8_t)

-  
ifc_msix_mem

-  
(struct resource *)

-  
ifc_legacy_irq

-  
(struct if_irq)

-  
ifc_admin_task

-  
(struct grouptask) Taskqueue task scheduled for link
-      state change events of the interface

-  
ifc_filter_info

-  
(struct iflib_filter_info) Statistics and
-      information relating to the interface device filter

-  
ifc_media

-  
(struct ifmedia)

-  
ifc_txrx

-  
(struct if_txrx)

-

-

-

-

-

-

-
The above named functions are found exclusively in iflib. They are
-    independent of the underlying hardware type or configuration.

-

-
Device Independent Functions

-

-  
()

-  
Function initiates a device registration with the iflib framework. It
-      calls the iflib_register function, which is responsible for allocating and
-      initializing the if_ctx_t structure.

-  
()

-  
Shutdown and detach the device. Unregister vlan events, drain any
-      dependent tasks, and release irq, pci, and msix memory.

-  
()

-  
Suspend a device by calling the device dependent suspend function and
-      bus_generic_suspend.

-  
()

-  
Resume a device by calling the device dependent resume function, the
-      iflib_init_locked function, and bus_generic_resume.

-  
()

-  
Register a device with the iflib framework. Allocate and initialize the
-      if_ctx_t structure. Setup and initialize the MSI or MSI/X interrupt
-      queues if necessary. Allocate memory for queues and qset structure
-    setup.

-  
()

-  
Allocate an interrupt resource for a given rid value with an associated
-      filter and handler function.

-  
()

-  
Performs the same function as iflib_device_irq_alloc along with the
-      additional functionality of adding a taskgroup. The data fields and
-      callback function are determined by the type of interrupt, such as
-      IFLIB_INTR_TX,
-      IFLIB_INTR_RX, and
-      IFLIB_INTR_ADMIN.

-  
()

-  
Calls led_create to initialize the ctx->ifc_led_dev field

-  
()

-  
Calls GROUPTASK_ENQUEUE to enqueue the transfer queues ift_task.

-  
()

-  
Calls GROUPTASK_ENQUEUE to enqueue the receive queues ifr_task.

-  
-  
Calls GROUPTASK_ENQUEUE to enqueue the link task

-  
-  
Change the interface link status to either
-      LINK_STATE_UP or
-      LINK_STATE_DOWN as specified by the second
-      argument to the function.
-    
 The following link states are currently defined:

-  

-  
-  
The link is up.

-  
-  
The link is down.

-  
()

-  
Modifies settings to user defined values for a given set of
-    variables.

-

-

-

-

-

-
iflibdd(9), iflibtxrx(9)

-

-

-

-
This manual page was written by Nicole
-    Graziano

-

-

-
-  
-    
-    
-  
-
May 21, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/iflibtxrx.9 3.html b/static/freebsd/man9/iflibtxrx.9 3.html
deleted file mode 100644
index f16a0d37..00000000
--- a/static/freebsd/man9/iflibtxrx.9 3.html	
+++ /dev/null
@@ -1,258 +0,0 @@
-
-  
-    
-    
-    
-  
-
IFLIBTXTX(9)Kernel Developer's ManualIFLIBTXTX(9)

-

-

-

-
iflibtxrx — Device
-    Dependent Transmit and Receive Functions

-

-

-

-
#include
-    <ifdi_if.h>

-

-

-
int
-  

-  isc_txd_encap(void *sc,
-    if_pkt_info_t pi);

-
void
-  

-  isc_txd_flush(void *sc,
-    uint16_t qid, uint32_t
-    _pidx_or_credits_);

-
int
-  

-  isc_txd_credits_update(void *sc,
-    uint16_t qid, bool clear);

-
int
-  

-  isc_rxd_available(void *sc,
-    uint16_t qsid, uint32_t
-  cidx);

-
void
-  

-  isc_rxd_refill(void *sc,
-    uint16_t qsid, uint8_t flid,
-    uint32_t pidx, uint64_t *paddrs,
-    caddr_t *vaddrs, uint16_t
-    count);

-
void
-  

-  isc_rxd_flush(void *sc,
-    uint16_t qsid, uint8_t flid,
-    uint32_t pidx);

-
int
-  

-  isc_rxd_pkt_get(void *sc,
-    if_rxd_info_t ri);

-

-

-

-
extern struct if_txrx

-

-

-

-

-
The device dependent mechanisms for handling packet transmit and
-    receive are primarily defined by the functions named above. The if_pkt_info
-    data structure contains statistics and identifying info necessary for packet
-    transmission. While the data structure for packet receipt is the if_rxd_info
-    structure.

-

-

-
The fields of struct if_pkt_info are as
-    follows:

-

-

-  
ipi_len

-  
(uint32_t) Denotes the size of packet to be sent on
-      the transmit queue.

-  
ipi_segs

-  
(bus_dma_segment_t *) A pointer to the
-      bus_dma_segment of the device independent transfer queue defined in
-    iflib.

-  
ipi_qsidx

-  
Unique index value assigned sequentially to each transmit queue. Used to
-      reference the currently transmitting queue.

-  
ipi_nsegs

-  
(uint16_t) Number of descriptors to be read into the
-      device dependent transfer descriptors.

-  
ipi_ndescs

-  
(uint16_t) Number of descriptors in use. Calculated
-      by subtracting the old pidx value from the new pidx value.

-  
ipi_flags

-  
(uint16_t) Flags defined on a per packet basis.

-  
ipi_pidx

-  
(uint32_t) Value of first pidx sent to the isc_encap
-      function for encapsulation and subsequent transmission.

-  
ipi_new_pidx

-  
(uint32_t) Value set after the termination of the
-      isc_encap function. This value will become the first pidx sent to the
-      isc-encap the next time that the function is called.

-  
The Following Fields Are
-    Used For Offload Handling

-  
 

-  
ipi_csum_flags

-  
(uint64_t) Flags describing the checksum values,
-      used on a per packet basis.

-  
ipi_tso_segsz

-  
(uint16_t) Size of the TSO Segment Size.

-  
ipi_mflags

-  
(uint16_t) Flags describing the operational
-      parameters of the mbuf.

-  
ipi_vtag

-  
(uint16_t) Contains the VLAN information in the
-      Ethernet Frame.

-  
ipi_etype

-  
(uint16_t) Type of ethernet header protocol as
-      contained by the struct ether_vlan_header.

-  
ipi_ehrdlen

-  
(uint8_t) Length of the Ethernet Header.

-  
ipi_ip_hlen

-  
(uint8_t) Length of the TCP Header

-  
ipi_tcp_hlen

-  
(uint8_t) Length of the TCP Header.

-  
ipi_tcp_hflags

-  
(uint8_t) Flags describing the operational
-      parameters of the TCP Header.

-  
ipi_ipproto

-  
(uint8_t) Specifies the type of IP Protocol in use.
-      Example TCP, UDP, or SCTP.

-

-

-

-

-

-
The fields of struct if_rxd_info are as
-    follows:

-

-

-  
iri_qsidx

-  
(uint16_t) Unique index value assigned sequentially
-      to each receive queue. Used to reference the currently receiving
-    queue.

-  
iri_vtag

-  
(uint16_t) Contains the VLAN information in the
-      Ethernet Frame.

-  
iri_len

-  
(uint16_t) Denotes the size of a received
-    packet.

-  
iri_next_offset

-  
(uint16_t) Denotes the offset value for the next
-      packet to be receive. A Null value signifies the end of packet.

-  
iri_cidx

-  
(uint32_t) Denotes the index value of the packet
-      currently being processed in the consumer queue.

-  
iri_flowid

-  
(uint32_t) Value of the RSS hash for the
-    packet.

-  
iri_flags

-  
(uint)
-    

-     Flags describing the operational parameters of the mbuf contained in the
-    

-     receive packet.

-  
iri_csum_flags

-  
(uint32_t) Flags describing the checksum value
-      contained in the receive packet.

-  
iri_csum_data

-  
(uint32_t) Checksum data contained in the
-      mbuf(9) packet header.

-  
iri_m

-  
(struct mbuf *) A mbuf for drivers that manage their
-      own receive queues.

-  
iri_ifp

-  
(struct ifnet *) A link back to the interface
-      structure. Utilized by drivers that have multiple interface per
-    softc.

-  
iri_rsstype

-  
(uint8_t) The value of the RSS hash type.

-  
iri_pad

-  
(uint8_t) The length of any padding contained by the
-      received data.

-  
iri_qidx

-  
(uint8_t) Represents the type of queue event. If
-      value >= 0 then it is the freelist id otherwise it is a completion
-      queue event.

-

-

-

-

-

-

-
All function calls are associated exclusively with either packet
-    transmission or receipt. The void *sc passed as the first argument to all of
-    the following functions represents the driver's softc.

-

-

-

-  
()

-  
Transmit function that sends a packet on an interface. The if_pkt_info
-      data structure contains data information fields describing the packet.
-      This function returns 0 if successful, otherwise an error value is
-      returned.

-  
()

-  
Flush function is called immediately after the isc_txd_encap function
-      transmits a packet. It updates the hardware producer index or increments
-      the descriptors used to pidx_or_credits in the queue designated by the qid
-      number. This is often referred to as poking the doorbell register.

-  
()

-  
Credit function advances the buffer ring and calculates the credits
-      (descriptors) processed. Until the I/O is complete it cleans the range in
-      case of multisegments and updates the count of processed packets. The
-      function returns the number of processed credits.

-

-

-

-

-

-  
()

-  
Function calculates the remaining number of descriptors from a position
-      given by idx. The function returns this value.

-  
()

-  
Starting with the physical address paddrs, the function reads a packet
-      into the rx_ring until a value designated by count is reached. vaddrs is
-      typically not needed and is provided for devices that place their own
-      metadata in the packet header.

-  
()

-  
Flush function updates the producer pointer on the free list flid in queue
-      set number qid to pidx to reflect the presence of new buffers.

-  
()

-  
Process a single software descriptor. rxr->rx_base[i] contains a
-      descriptor that describes a received packet. Hardware specific information
-      about the buffer referred to by ri is returned in the data structure
-      if_rxd_info

-

-

-

-

-

-
iflibdd(9), iflibdi(9),
-    mbuf(9)

-

-

-

-
This manual page was written by Nicole
-    Graziano

-

-

-
-  
-    
-    
-  
-
December 17, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/ifnet.9 3.html b/static/freebsd/man9/ifnet.9 3.html
deleted file mode 100644
index dbf27192..00000000
--- a/static/freebsd/man9/ifnet.9 3.html	
+++ /dev/null
@@ -1,1731 +0,0 @@
-
-  
-    
-    
-    
-  
-
IFNET(9)Kernel Developer's ManualIFNET(9)

-

-

-

-
if_t, ifnet,
-    ifaddr, ifqueue,
-    if_data — kernel interfaces
-    for manipulating network interfaces

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/time.h>
-  

-  #include <sys/socket.h>
-  

-  #include <net/if.h>
-  

-  #include <net/if_var.h>
-  

-  #include <net/if_types.h>

-

-
Interface Manipulation Functions

-
if_t
-  

-  if_alloc(u_char
-    type);

-
if_t
-  

-  if_alloc_dev(u_char
-    type, device_t
-    dev);

-
if_t
-  

-  if_alloc_domain(u_char
-    type, int
-    numa_domain);

-
void
-  

-  if_attach(if_t
-    ifp);

-
void
-  

-  if_detach(if_t
-    ifp);

-
void
-  

-  if_free(if_t
-    ifp);

-
void
-  

-  if_free_type(if_t
-    ifp, u_char
-  type);

-
void
-  

-  if_down(if_t
-    ifp);

-
int
-  

-  ifioctl(struct
-    socket *so, u_long
-    cmd, caddr_t data,
-    struct thread *td);

-
int
-  

-  ifpromisc(if_t
-    ifp, int
-  pswitch);

-
int
-  

-  if_allmulti(if_t
-    ifp, int
-  amswitch);

-
if_t
-  

-  ifunit(const
-    char *name);

-
if_t
-  

-  ifunit_ref(const
-    char *name);

-
void
-  

-  if_up(if_t
-    ifp);

-

-

-
Interface Address Functions

-
struct ifaddr *
-  

-  ifa_ifwithaddr(struct
-    sockaddr *addr);

-
struct ifaddr *
-  

-  ifa_ifwithdstaddr(struct
-    sockaddr *addr, int
-    fib);

-
struct ifaddr *
-  

-  ifa_ifwithnet(struct
-    sockaddr *addr, int
-    ignore_ptp, int
-    fib);

-
struct ifaddr *
-  

-  ifaof_ifpforaddr(struct
-    sockaddr *addr, if_t
-    ifp);

-
void
-  

-  ifa_ref(struct
-    ifaddr *ifa);

-
void
-  

-  ifa_free(struct
-    ifaddr *ifa);

-

-

-
Interface Multicast Address Functions

-
int
-  

-  if_addmulti(if_t
-    ifp, struct sockaddr
-    *sa, struct ifmultiaddr
-    **ifmap);

-
int
-  

-  if_delmulti(if_t
-    ifp, struct sockaddr
-    *sa);

-
struct ifmultiaddr *
-  

-  if_findmulti(if_t
-    ifp, struct sockaddr
-    *sa);

-

-

-

-
if_dequeue(if_t
-    ifp, struct mbuf
-    *m);

-

-

-

-
IF_DEQUEUE(struct
-    ifqueue *ifq, struct mbuf
-    *m);

-

-

-

-
uint64_t
-  

-  if_setbaudrate(if_t
-    ifp, uint64_t
-    baudrate);

-
uint64_t
-  

-  if_getbaudrate(const
-    if_t ifp);

-
int
-  

-  if_setcapabilities(if_t
-    ifp, int
-    capabilities);

-
int
-  

-  if_setcapabilitiesbit(if_t
-    ifp, int setbit,
-    int clearbit);

-
int
-  

-  if_getcapabilities(const
-    if_t ifp);

-
int
-  

-  if_togglecapenable(if_t
-    ifp, int
-    togglecap);

-
int
-  

-  if_setcapenable(if_t
-    ifp, int
-    capenable);

-
int
-  

-  if_setcapenablebit(if_t
-    ifp, int setcap,
-    int clearcap);

-
int
-  

-  if_getcapenable(const
-    if_t ifp);

-
int
-  

-  if_setcapabilities2(if_t
-    ifp, int
-    capabilities);

-
int
-  

-  if_setcapabilities2bit(if_t
-    ifp, int setbit,
-    int clearbit);

-
int
-  

-  if_getcapabilities2(const
-    if_t ifp);

-
int
-  

-  if_togglecapenable2(if_t
-    ifp, int
-    togglecap);

-
int
-  

-  if_setcapenable2(if_t
-    ifp, int
-    capenable);

-
int
-  

-  if_setcapenable2bit(if_t
-    ifp, int setcap,
-    int clearcap);

-
int
-  

-  if_getcapenable2(const
-    if_t ifp);

-
int
-  

-  if_getdunit(const
-    if_t ifp);

-
int
-  

-  if_getindex(const
-    if_t ifp);

-
int
-  

-  if_getidxgen(const
-    if_t ifp);

-
const char *
-  

-  if_getdname(const
-    if_t ifp);

-
void
-  

-  if_setdname(if_t
-    ifp, const char
-    *name);

-
const char *
-  

-  if_name(if_t
-    ifp);

-
int
-  

-  if_setname(if_t
-    ifp, const char
-    *name);

-
void
-  

-  if_setdescr(if_t
-    ifp, char
-    *descrbuf);

-
char *
-  

-  if_allocdescr(size_t
-    sz, int
-    malloc_flag);

-
void
-  

-  if_freedescr(char
-    *descrbuf);

-
int
-  

-  if_getalloctype(const
-    if_t ifp);

-
int
-  

-  if_gettype(const
-    if_t ifp);

-
int
-  

-  if_setdev(if_t
-    ifp, void
-  *dev);

-
int
-  

-  if_setdrvflagbits(if_t
-    ifp, int
-    if_setflags, int
-    clear_flags);

-
int
-  

-  if_getdrvflags(const
-    if_t ifp);

-
int
-  

-  if_setdrvflags(if_t
-    ifp, int
-  flags);

-
int
-  

-  if_getlinkstate(if_t
-    ifp);

-
int
-  

-  if_clearhwassist(if_t
-    ifp);

-
int
-  

-  if_sethwassistbits(if_t
-    ifp, int toset,
-    int toclear);

-
int
-  

-  if_sethwassist(if_t
-    ifp, int
-    hwassist_bit);

-
int
-  

-  if_gethwassist(const
-    if_t ifp);

-
int
-  

-  if_togglehwassist(if_t
-    ifp, int
-    toggle_bits);

-
int
-  

-  if_setsoftc(if_t
-    ifp, void
-  *softc);

-
void *
-  

-  if_getsoftc(if_t
-    ifp);

-
void
-  

-  if_setllsoftc(if_t
-    ifp, void
-  *softc);

-
void *
-  

-  if_getllsoftc(if_t
-    ifp);

-
u_int
-  

-  if_getfib(if_t
-    ifp);

-
uint8_t
-  

-  if_getaddrlen(if_t
-    ifp);

-
int
-  

-  if_gethwaddr(const
-    if_t ifp, struct ifreq
-    *);

-
const uint8_t *
-  

-  if_getbroadcastaddr(const
-    if_t ifp);

-
void
-  

-  if_setbroadcastaddr(if_t
-    ifp, const uint8_t
-    *);

-
int
-  

-  if_setmtu(if_t
-    ifp, int mtu);

-
int
-  

-  if_getmtu(const
-    if_t ifp);

-
int
-  

-  if_getmtu_family(const
-    if_t ifp, int
-    family);

-
void
-  

-  if_notifymtu(if_t
-    ifp);

-
int
-  

-  if_setflagbits(if_t
-    ifp, int set,
-    int clear);

-
int
-  

-  if_setflags(if_t
-    ifp, int
-  flags);

-
int
-  

-  if_getflags(const
-    if_t ifp);

-
int
-  

-  if_getnumadomain(if_t
-    ifp);

-
int
-  

-  if_sendq_empty(if_t
-    ifp);

-
int
-  

-  if_setsendqready(if_t
-    ifp);

-
int
-  

-  if_setsendqlen(if_t
-    ifp, int
-    tx_desc_count);

-
int
-  

-  if_sethwtsomax(if_t
-    ifp, u_int
-    if_hw_tsomax);

-
int
-  

-  if_sethwtsomaxsegcount(if_t
-    ifp, u_int
-    if_hw_tsomaxsegcount);

-
int
-  

-  if_sethwtsomaxsegsize(if_t
-    ifp, u_int
-    if_hw_tsomaxsegsize);

-
u_int
-  

-  if_gethwtsomax(const
-    if_t ifp);

-
u_int
-  

-  if_gethwtsomaxsegcount(const
-    if_t ifp);

-
u_int
-  

-  if_gethwtsomaxsegsize(const
-    if_t ifp);

-
void
-  

-  if_setnetmapadapter(if_t
-    ifp, struct
-    netmap_adapter *na);

-
struct netmap_adapter *
-  

-  if_getnetmapadapter(if_t
-    ifp);

-
void
-  

-  if_input(if_t
-    ifp, struct mbuf*
-    sendmp);

-
int
-  

-  if_sendq_prepend(if_t
-    ifp, struct mbuf
-    *m);

-
struct mbuf *
-  

-  if_dequeue(if_t
-    ifp);

-
int
-  

-  if_setifheaderlen(if_t
-    ifp, int len);

-
void
-  

-  if_setrcvif(struct
-    mbuf *m, if_t
-  ifp);

-
void
-  

-  if_setvtag(struct
-    mbuf *m, u_int16_t
-    tag);

-
u_int16_t
-  

-  if_getvtag(struct
-    mbuf *m);

-
int
-  

-  if_vlantrunkinuse(if_t
-    ifp);

-
caddr_t
-  

-  if_getlladdr(const
-    if_t ifp);

-
struct vnet *
-  

-  if_getvnet(const
-    if_t ifp);

-
void *
-  

-  if_gethandle(u_char);

-
void
-  

-  if_bpfmtap(if_t
-    ifp, struct mbuf
-    *m);

-
void
-  

-  if_etherbpfmtap(if_t
-    ifp, struct mbuf
-    *m);

-
void
-  

-  if_vlancap(if_t
-    ifp);

-
int
-  

-  if_transmit(if_t
-    ifp, struct mbuf
-    *m);

-
void
-  

-  if_init(if_t
-    ifp, void
-  *ctx);

-
int
-  

-  if_resolvemulti(if_t
-    ifp, struct sockaddr
-    **, struct sockaddr
-    *);

-
uint64_t
-  

-  if_getcounter(if_t
-    ifp, ift_counter
-    counter);

-
struct label *
-  

-  if_getmaclabel(if_t
-    ifp);

-
void
-  

-  if_setmaclabel(if_t
-    ifp, struct label
-    *label);

-
struct bpf_if *
-  

-  if_getbpf(if_t
-    ifp);

-
uint8_t
-  

-  if_getpcp(if_t
-    ifp);

-
void *
-  

-  if_getl2com(if_t
-    ifp);

-
struct ifvlantrunk *
-  

-  if_getvlantrunk(if_t
-    ifp);

-
bool
-  

-  if_altq_is_enabled(if_t
-    ifp);

-

-

-

-
void
-  

-  (*if_input)(if_t
-    ifp, struct mbuf
-    *m);

-
int
-  

-  (*if_output)(if_t ifp,
-    struct mbuf *m, const struct sockaddr
-    *dst, struct route *ro);

-
void
-  

-  (*if_start)(if_t
-    ifp);

-
int
-  

-  (*if_transmit)(if_t
-    ifp, struct mbuf
-    *m);

-
void
-  

-  (*if_qflush)(if_t
-    ifp);

-
int
-  

-  (*if_ioctl)(if_t
-    ifp, u_long cmd,
-    caddr_t data);

-
void
-  

-  (*if_init)(void
-    *if_softc);

-
int
-  

-  (*if_resolvemulti)(if_t ifp,
-    struct sockaddr **retsa, struct
-    sockaddr *addr);

-

-

-

-
void
-  

-  (*ifa_rtrequest)(int cmd,
-    struct rtentry *rt, struct rt_addrinfo
-    *info);

-

-

-

-
extern struct ifnethead ifnet;
-  

-  extern int if_index;
-  

-  extern int ifqmaxlen;

-

-

-

-

-
The kernel mechanisms for handling network interfaces reside
-    primarily in the ifnet, if_data,
-    ifaddr, and ifmultiaddr
-    structures in <net/if.h> and
-    <net/if_var.h> and the
-    functions named above and defined in /sys/net/if.c.
-    Those interfaces which are intended to be used by user programs are defined
-    in <net/if.h>; these include
-    the interface flags, the if_data structure, and the
-    structures defining the appearance of interface-related messages on the
-    route(4) routing socket and in
-    sysctl(3). The header file
-    <net/if_var.h> defines the
-    kernel-internal interfaces, including the ifnet,
-    ifaddr, and ifmultiaddr
-    structures and the functions which manipulate them. (A few user programs
-    will need <net/if_var.h>
-    because it is the prerequisite of some other header file like
-    <netinet/if_ether.h>. Most
-    references to those two files in particular can be replaced by
-    <net/ethernet.h>.)

-
The system keeps a linked list of interfaces using the
-    TAILQ macros defined in queue(3);
-    this list is headed by a struct ifnethead called
-    ifnet. The elements of this list are of type
-    struct ifnet, and most kernel routines which
-    manipulate interface as such accept or return pointers to these structures.
-    Each interface structure contains an if_data structure
-    used for statistics and information. Each interface also has a
-    TAILQ of interface addresses, described by
-    ifaddr structures. An AF_LINK
-    address (see link_addr(3)) describing the link layer
-    implemented by the interface (if any) is accessed by the
-    if_addr structure. (Some trivial interfaces do not
-    provide any link layer addresses; this structure, while still present,
-    serves only to identify the interface name and index.)

-
Finally, those interfaces supporting reception of multicast
-    datagrams have a TAILQ of multicast group
-    memberships, described by ifmultiaddr structures.
-    These memberships are reference-counted.

-
Interfaces are also associated with an output queue, defined as a
-    struct ifqueue; this structure is used to hold packets
-    while the interface is in the process of sending another.

-

-

-
The accessors for if_t are as follows:

-

-

-  
()
-    ()

-  
(u_long) The line rate of the interface, in bits per
-      second.

-  
()
-    ()
-    ()

-  
(int) Flags describing the capabilities the
-      interface supports (see below).

-  
()
-    ()
-    ()
-    ()

-  
(int) Flags describing the enabled capabilities of
-      the interface (see below).

-  
()
-    ()
-    ()

-  
 

-  
()
-    ()
-    ()
-    ()

-  
 

-  
()

-  
(int) A unique number assigned to each interface
-      managed by a particular driver. Drivers may choose to set this to
-      IF_DUNIT_NONE if a unit number is not associated
-      with the device. (Initialized by driver, usually via
-      ().)

-  
()

-  
(u_short) Return the unique number assigned to the
-      device when attached. This number can be used in a struct
-      sockaddr_dl to refer to a particular interface by index (see
-      link_addr(3)). This is initialized by
-      if_alloc().

-  
()

-  
 

-  
()
-    ()

-  
(const char *) The name of the driver. This is
-      initialized by driver (usually via
-    if_initname()).

-  
()
-    ()

-  
(char *) The name of the interface, (e.g.,
-      ‘fxp0’ or
-      “lo0”). This is initialized by
-      driver, usually via if_initname().

-  
()

-  
(u_char) The type of the interface as it was at the
-      time of its allocation. It is used to cache the type passed to
-      if_alloc(), but unlike
-      if_type, it would not be changed by drivers.

-  
()

-  
 

-  
()

-  
 

-  
()
-    ()
-    ()

-  
 

-  
()

-  
 

-  
()
-    ()

-  
()
-      ()
-      ()
-      (u_long) A detailed interpretation of the
-      capabilities to offload computational tasks for outgoing
-      packets. The interface driver must keep this field in accord with the
-      current value of if_capenable.

-  
()
-    ()

-  
(void *) A pointer to the driver's private state
-      block. This is initialized by driver at attach.

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()
-    ()

-  
Access the interface broadcast address.

-  
()

-  
 

-  
()

-  
Access the interface MTU.

-  
()
-    ()
-    ()

-  
(int) Flags describing operational parameters of
-      this interface (see below). These flags are manipulated by generic
-    code.

-  
()

-  
(uint8_t) The NUMA domain of the hardware device
-      associated with the interface. This is filled in with a wildcard value
-      unless the kernel is NUMA aware, the system is a NUMA system, and the
-      ifnet is allocated using if_alloc_dev() or
-      if_alloc_domain().

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()
-    ()

-  
 

-  
()
-    ()

-  
 

-  
()
-    ()

-  
 

-  
()
-    ()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()
-    ()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()

-  
(struct vnet *) A pointer to the virtual network
-      stack instance. This is initialized by
-      if_attach().

-  
()

-  
 

-  
()

-  
 

-  
()

-  
 

-  
()
-    ()

-  
 

-  
()

-  
(struct bpf_if *) Opaque per-interface data for the
-      packet filter, bpf(4). This is initialized by
-      ().

-  
()

-  
 

-  
()

-  
A pointer to the common data for the interface's layer 2 protocol. This is
-      initialized by if_alloc().
-      (if_t
-      ifp) (struct ifvlantrunk *) A pointer to
-      802.1Q trunk structure, vlan(4). This is initialized by
-      the driver-specific if_ioctl() routine.

-  
if_getdrvflags()
-    if_setdrvflags()
-    if_setdrvflagbits()

-  
(int) Flags describing operational status of this
-      interface (see below). These flags are manipulated by driver.

-  
if_addmulti()
-    if_delmulti()
-    if_findmulti()

-  
Add, remove, and find multicast addresses assigned to this interface.

-  
()

-  
(struct ifaddr *) Get a pointer to the interface's
-      link-level address.

-  
if_getbroadcastaddr()
-    if_setbroadcastaddr()

-  
(const u_int8_t *) A link-level broadcast bytestring
-      for protocols with variable address length.

-  
()

-  
(void *) An address family dependent data
-    region.

-  
()
-    ()

-  
Add and delete groups from the interface.

-

-

-
References to ifnet structures
-    are gained by calling the
-    ()
-    function and released by calling the
-    ()
-    function. They are used to allow kernel code walking global interface lists
-    to release the ifnet lock yet keep the
-    ifnet structure stable.

-
There are in addition a number of function pointers which the
-    driver must initialize to complete its interface with the generic interface
-    layer:

-

-  
()

-  
Pass a packet to an appropriate upper layer as determined from the
-      link-layer header of the packet. This routine is to be called from an
-      interrupt handler or used to emulate reception of a packet on this
-      interface. A single function implementing
-      if_input() can be shared among multiple drivers
-      utilizing the same link-layer framing, e.g., Ethernet.

-  
()

-  
Output a packet on interface ifp, or queue it on the
-      output queue if the interface is already active.

-  
()

-  
Transmit a packet on an interface or queue it if the interface is in use.
-      This function will return ENOBUFS if the devices
-      software and hardware queues are both full. This function must be
-      installed after if_attach() to override the
-      default implementation. This function is exposed in order to allow drivers
-      to manage their own queues and to reduce the latency caused by a
-      frequently gratuitous enqueue / dequeue pair to ifq. The suggested
-      internal software queuing mechanism is buf_ring.

-  
()

-  
Free mbufs in internally managed queues when the interface is marked down.
-      This function must be installed after if_attach()
-      to override the default implementation. This function is exposed in order
-      to allow drivers to manage their own queues and to reduce the latency
-      caused by a frequently gratuitous enqueue / dequeue pair to ifq. The
-      suggested internal software queuing mechanism is buf_ring.

-  
()

-  
Start queued output on an interface. This function is exposed in order to
-      provide for some interface classes to share a
-      if_output() among all drivers.
-      if_start() may only be called when the
-      IFF_DRV_OACTIVE flag is not set. (Thus,
-      IFF_DRV_OACTIVE does not literally mean that
-      output is active, but rather that the device's internal output queue is
-      full.) Please note that this function will soon be deprecated.

-  
if_ioctl()

-  
Process interface-related ioctl(2) requests (defined in
-      <sys/sockio.h>).
-      Preliminary processing is done by the generic routine
-      ifioctl() to check for appropriate privileges,
-      locate the interface being manipulated, and perform certain generic
-      operations like twiddling flags and flushing queues. See the description
-      of ifioctl() below for more information.

-  
()

-  
Initialize and bring up the hardware, e.g., reset the chip and enable the
-      receiver unit. Should mark the interface running, but not active
-      (IFF_DRV_RUNNING,
-      ~IIF_DRV_OACTIVE).

-  
if_resolvemulti()

-  
Check the requested multicast group membership,
-      addr, for validity, and if necessary compute a
-      link-layer group which corresponds to that address which is returned in
-      *retsa. Returns zero on success, or an error code on
-      failure.

-

-

-

-

-
Interface flags are used for a number of different purposes. Some
-    flags simply indicate information about the type of interface and its
-    capabilities; others are dynamically manipulated to reflect the current
-    state of the interface. Flags of the former kind are marked
-    ⟨S⟩ in this table; the latter are marked ⟨D⟩.
-    Flags which begin with “IFF_DRV_” are stored in
-    if_drv_flags; all other flags are stored in
-    if_flags.

-
The macro IFF_CANTCHANGE defines the bits
-    which cannot be set by a user program using the
-    SIOCSIFFLAGS command to ioctl(2);
-    these are indicated by an asterisk
-    (‘*’) in the following listing.

-

-

-

-  

-  
⟨D⟩ The interface has been configured up by the user-level
-      code.

-  

-  
⟨S*⟩ The interface supports broadcast.

-  

-  
⟨D⟩ Used to enable/disable driver debugging code.

-  

-  
⟨S⟩ The interface is a loopback device.

-  

-  
⟨S*⟩ The interface is point-to-point;
-      “broadcast” address is actually the address of the other
-      end.

-  

-  
⟨D*⟩ The interface has been configured and dynamic resources
-      were successfully allocated. Probably only useful internal to the
-      interface.

-  

-  
⟨D⟩ Disable network address resolution on this
-    interface.

-  

-  
⟨D*⟩ This interface is in promiscuous mode.

-  

-  
⟨D⟩ This interface is in the permanently promiscuous mode
-      (implies IFF_PROMISC).

-  

-  
⟨D*⟩ This interface is in all-multicasts mode (used by
-      multicast routers).

-  

-  
⟨D⟩ This interface is in the permanently all-multicasts mode
-      (implies IFF_ALLMULTI).

-  

-  
⟨D*⟩ The interface's hardware output queue (if any) is full;
-      output packets are to be queued.

-  

-  
⟨S*⟩ The interface cannot hear its own transmissions.

-  

-  
 

-  

-  
 

-  

-  
⟨D⟩ Control flags for the link layer. (Currently abused to
-      select among multiple physical layers on some devices.)

-  

-  
⟨S*⟩ This interface supports multicast.

-  

-  
⟨S*⟩ The interface is not configurable in a meaningful way.
-      Primarily useful for IFT_USB interfaces registered
-      at the interface list.

-  

-  
⟨D⟩ This interface blocks transmission of packets and
-      discards incoming packets after BPF processing. Used to monitor network
-      traffic but not interact with the network in question.

-  

-  
⟨D⟩ Used to enable/disable ARP requests on this
-    interface.

-  

-  
⟨D*⟩ Set when the ifnet structure of
-      this interface is being released and still has
-      if_refcount references.

-

-

-

-

-

-
Interface capabilities are specialized features an interface may
-    or may not support. These capabilities are very hardware-specific and allow,
-    when enabled, to offload specific network processing to the interface or to
-    offer a particular feature for use by other kernel parts.

-
It should be stressed that a capability can be
-    completely uncontrolled (i.e., stay always enabled with no way to disable
-    it) or allow limited control over itself (e.g., depend on another
-    capability's state.) Such peculiarities are determined solely by the
-    hardware and driver of a particular interface. Only the driver possesses the
-    knowledge on whether and how the interface capabilities can be controlled.
-    Consequently, capabilities flags in if_capenable
-    should never be modified directly by kernel code other than the interface
-    driver. The command SIOCSIFCAP to
-    ()
-    is the dedicated means to attempt altering
-    if_capenable on an interface. Userland code shall use
-    ioctl(2).

-
The following capabilities are currently supported by the
-  system:

-

-

-  

-  
This interface can do checksum validation on receiving data. Some
-      interfaces do not have sufficient buffer storage to store frames above a
-      certain MTU-size completely. The driver for the interface might disable
-      hardware checksum validation if the MTU is set above the hardcoded
-    limit.

-  

-  
This interface can do checksum calculation on transmitting data.

-  

-  
A shorthand for (IFCAP_RXCSUM |
-      IFCAP_TXCSUM).

-  

-  
This interface can be a network console.

-  

-  
The vlan(4) driver can operate over this interface in
-      software tagging mode without having to decrease MTU on
-      vlan(4) interfaces below 1500 bytes. This implies the
-      ability of this interface to cope with frames somewhat longer than
-      permitted by the Ethernet specification.

-  

-  
This interface can do VLAN tagging on output and demultiplex frames by
-      their VLAN tag on input.

-  

-  
This Ethernet interface can transmit and receive frames up to 9000 bytes
-      long.

-  

-  
This interface supports polling(4). See below for
-      details.

-  

-  
This interface can do checksum calculation on both transmitting and
-      receiving data on vlan(4) interfaces (implies
-      IFCAP_HWCSUM).

-  

-  
This Ethernet interface supports TCP4 Segmentation offloading.

-  

-  
This Ethernet interface supports TCP6 Segmentation offloading.

-  

-  
A shorthand for (IFCAP_TSO4 |
-      IFCAP_TSO6).

-  

-  
This Ethernet interface supports TCP4 Offload Engine.

-  

-  
This Ethernet interface supports TCP6 Offload Engine.

-  

-  
A shorthand for (IFCAP_TOE4 |
-      IFCAP_TOE6).

-  

-  
This Ethernet interface supports waking up on any Unicast packet.

-  

-  
This Ethernet interface supports waking up on any Multicast packet.

-  

-  
This Ethernet interface supports waking up on any Magic packet such as
-      those sent by wake(8).

-  

-  
A shorthand for (IFCAP_WOL_UCAST |
-      IFCAP_WOL_MCAST |
-      IFCAP_WOL_MAGIC).

-  

-  
This interface supports frame filtering in hardware on
-      vlan(4) interfaces.

-  

-  
This interface supports TCP Segmentation offloading on
-      vlan(4) interfaces (implies
-      IFCAP_TSO).

-  

-  
This Ethernet interface supports dynamic link state changes.

-  

-  
This Ethernet interface supports netmap(4).

-

-

-
The ability of advanced network interfaces to offload certain
-    computational tasks from the host CPU to the board is limited mostly to
-    TCP/IP. Therefore a separate field associated with an interface (see
-    ifnet.if_data.ifi_hwassist below) keeps a detailed
-    description of its enabled capabilities specific to TCP/IP processing. The
-    TCP/IP module consults the field to see which tasks can be done on an
-    outgoing packet by the interface. The flags defined for
-    that field are a superset of those for
-    mbuf.m_pkthdr.csum_flags, namely:

-

-

-  

-  
The interface will compute IP checksums.

-  

-  
The interface will compute TCP checksums.

-  

-  
The interface will compute UDP checksums.

-

-

-
An interface notifies the TCP/IP module about the
-    tasks the former has performed on an
-     packet
-    by setting the corresponding flags in the field
-    mbuf.m_pkthdr.csum_flags of the mbuf
-    chain containing the packet. See mbuf(9) for
-    details.

-
The capability of a network interface to operate in
-    polling(4) mode involves several flags in different global
-    variables and per-interface fields. The capability flag
-    IFCAP_POLLING set in interface's
-    if_capabilities indicates support for
-    polling(4) on the particular interface. If set in
-    if_capabilities, the same flag can be marked or
-    cleared in the interface's if_capenable within
-    (),
-    thus initiating switch of the interface to polling(4) mode
-    or interrupt mode, respectively. The actual mode change is managed by the
-    driver-specific if_ioctl() routine. The
-    polling(4) handler returns the number of packets
-    processed.

-

-

-

-
The if_data structure contains statistics
-    and identifying information used by management programs, and which is
-    exported to user programs by way of the ifmib(4) branch of
-    the sysctl(3) MIB. The following elements of the
-    if_data structure are initialized by the interface and
-    are not expected to change significantly over the course of normal
-    operation:

-

-

-  
ifi_type

-  
(u_char) The type of the interface, as defined in
-      <net/if_types.h> and
-      described below in the Interface
-      Types section.

-  
ifi_physical

-  
(u_char) Intended to represent a selection of
-      physical layers on devices which support more than one; never
-    implemented.

-  
ifi_addrlen

-  
(u_char) Length of a link-layer address on this
-      device, or zero if there are none. Used to initialized the address length
-      field in sockaddr_dl structures referring to this
-      interface.

-  
ifi_hdrlen

-  
(u_char) Maximum length of any link-layer header
-      which might be prepended by the driver to a packet before transmission.
-      The generic code computes the maximum over all interfaces and uses that
-      value to influence the placement of data in mbufs to
-      attempt to ensure that there is always sufficient space to prepend a
-      link-layer header without allocating an additional
-      mbuf.

-  
ifi_datalen

-  
(u_char) Length of the if_data
-      structure. Allows some stabilization of the routing socket ABI in the face
-      of increases in the length of struct ifdata.

-  
ifi_mtu

-  
(u_long) The maximum transmission unit of the
-      medium, exclusive of any link-layer overhead.

-  
ifi_metric

-  
(u_long) A dimensionless metric interpreted by a
-      user-mode routing process.

-  
ifi_epoch

-  
(time_t) The system uptime when interface was
-      attached or the statistics below were reset. This is intended to be used
-      to set the SNMP variable ifCounterDiscontinuityTime.
-      It may also be used to determine if two successive queries for an
-      interface of the same index have returned results for the same
-    interface.

-

-

-
The structure additionally contains generic statistics applicable
-    to a variety of different interface types (except as noted, all members are
-    of type u_long):

-

-

-  
-  
(u_char) The current link state of Ethernet
-      interfaces. See the Interface
-      Link States section for possible values.

-  
ifi_ipackets

-  
Number of packets received.

-  
ifi_ierrors

-  
Number of receive errors detected (e.g., FCS errors, DMA overruns, etc.).
-      More detailed breakdowns can often be had by way of a link-specific
-    MIB.

-  
ifi_opackets

-  
Number of packets transmitted.

-  
ifi_oerrors

-  
Number of output errors detected (e.g., late collisions, DMA overruns,
-      etc.). More detailed breakdowns can often be had by way of a link-specific
-      MIB.

-  
ifi_collisions

-  
Total number of collisions detected on output for CSMA interfaces. (This
-      member is sometimes [ab]used by other types of interfaces for other output
-      error counts.)

-  
ifi_ibytes

-  
Total traffic received, in bytes.

-  
ifi_obytes

-  
Total traffic transmitted, in bytes.

-  
ifi_imcasts

-  
Number of packets received which were sent by link-layer multicast.

-  
ifi_omcasts

-  
Number of packets sent by link-layer multicast.

-  
ifi_iqdrops

-  
Number of packets dropped on input. Rarely implemented.

-  
ifi_oqdrops

-  
Number of packets dropped on output.

-  
ifi_noproto

-  
Number of packets received for unknown network-layer protocol.

-  
ifi_lastchange

-  
(struct timeval) The time of the last administrative
-      change to the interface (as required for SNMP ) .

-

-

-

-

-

-
The header file
-    <net/if_types.h> defines
-    symbolic constants for a number of different types of interfaces. The most
-    common are:

-

-

-

-  

-  
none of the following

-  

-  
Ethernet

-  

-  
ISO 8802-3 CSMA/CD

-  

-  
ISO 8802-4 Token Bus

-  

-  
ISO 8802-5 Token Ring

-  

-  
ISO 8802-6 DQDB MAN

-  

-  
FDDI

-  

-  
Internet Point-to-Point Protocol (ppp(8))

-  

-  
The loopback (lo(4)) interface

-  

-  
Serial Line IP

-  

-  
Parallel-port IP (“PLIP”)

-  

-  
Asynchronous Transfer Mode

-  

-  
USB Interface

-

-

-

-

-
-
The following link states are currently defined:

-

-

-

-  
-  
The link is in an invalid or unknown state.

-  
-  
The link is down.

-  
-  
The link is up.

-

-

-

-

-

-
Every interface is associated with a list (or, rather, a
-    TAILQ) of addresses, rooted at the interface
-    structure's if_addrhead member. The first element in
-    this list is always an AF_LINK address representing
-    the interface itself; multi-access network drivers should complete this
-    structure by filling in their link-layer addresses after calling
-    ().
-    Other members of the structure represent network-layer addresses which have
-    been configured by means of the SIOCAIFADDR command
-    to ioctl(2), called on a socket of the appropriate
-    protocol family. The elements of this list consist of
-    ifaddr structures. Most protocols will declare their
-    own protocol-specific interface address structures, but all begin with a
-    struct ifaddr which provides the most-commonly-needed
-    functionality across all protocols. Interface addresses are
-    reference-counted.

-
The members of struct ifaddr are as
-  follows:

-

-

-  
ifa_addr

-  
(struct sockaddr *) The local address of the
-      interface.

-  
ifa_dstaddr

-  
(struct sockaddr *) The remote address of
-      point-to-point interfaces, and the broadcast address of broadcast
-      interfaces. (ifa_broadaddr is a macro for
-      ifa_dstaddr.)

-  
ifa_netmask

-  
(struct sockaddr *) The network mask for
-      multi-access interfaces, and the confusion generator for point-to-point
-      interfaces.

-  
ifa_ifp

-  
(if_t) A link back to the interface structure.

-  
-  
((ifaddr))
-      queue(3) glue for list of addresses on each
-    interface.

-  
ifa_rtrequest

-  
See below.

-  
ifa_flags

-  
(u_short) Some of the flags which would be used for
-      a route representing this address in the route table.

-  
ifa_refcnt

-  
(short) The reference count.

-

-

-
References to ifaddr structures
-    are gained by calling the
-    ()
-    function and released by calling the
-    ()
-    function.

-
()
-    is a pointer to a function which receives callouts from the routing code
-    (())
-    to perform link-layer-specific actions upon requests to add, or delete
-    routes. The cmd argument indicates the request in
-    question: RTM_ADD, or
-    RTM_DELETE. The rt argument is
-    the route in question; the info argument contains the
-    specific destination being manipulated.

-

-

-

-

-
The functions provided by the generic interface code can be
-    divided into two groups: those which manipulate interfaces, and those which
-    manipulate interface addresses. In addition to these functions, there may
-    also be link-layer support routines which are used by a number of drivers
-    implementing a specific link layer over different hardware; see the
-    documentation for that link layer for more details.

-

-

-
Every multicast-capable interface is associated with a list of
-    multicast group memberships, which indicate at a low level which link-layer
-    multicast addresses (if any) should be accepted, and at a high level, in
-    which network-layer multicast groups a user process has expressed
-  interest.

-
The elements of the structure are as follows:

-

-

-  
-  
((ifmultiaddr))
-      queue(3) macro glue.

-  
ifma_addr

-  
(struct sockaddr *) A pointer to the address which
-      this record represents. The memberships for various address families are
-      stored in arbitrary order.

-  
ifma_lladdr

-  
(struct sockaddr *) A pointer to the link-layer
-      multicast address, if any, to which the network-layer multicast address in
-      ifma_addr is mapped, else a null pointer. If this
-      element is non-nil, this membership also holds an invisible reference to
-      another membership for that link-layer address.

-  
ifma_refcount

-  
(u_int) A reference count of requests for this
-      particular membership.

-

-

-

-

-
Interface Manipulation Functions

-

-  
()

-  
Allocate and initialize struct ifnet. Initialization
-      includes the allocation of an interface index and may include the
-      allocation of a type specific structure in
-      if_l2com.

-  
()

-  
Allocate and initialize struct ifnet as
-      if_alloc() does, with the addition that the ifnet
-      can be tagged with the appropriate NUMA domain derived from the
-      dev argument passed by the caller.

-  
()

-  
Allocate and initialize struct ifnet as
-      if_alloc() does, with the addition that the ifnet
-      will be tagged with the NUMA domain via the
-      numa_domain argument passed by the caller.

-  
if_attach()

-  
Link the specified interface ifp into the list of
-      network interfaces. Also initialize the list of addresses on that
-      interface, and create a link-layer ifaddr structure
-      to be the first element in that list. (A pointer to this address structure
-      is saved in the ifnet structure.) The
-      ifp must have been allocated by
-      if_alloc(), if_alloc_dev()
-      or if_alloc_domain().

-  
()

-  
Shut down and unlink the specified ifp from the
-      interface list.

-  
()

-  
Free the given ifp back to the system. The interface
-      must have been previously detached if it was ever attached.

-  
()

-  
Identical to if_free() except that the given
-      type is used to free if_l2com
-      instead of the type in if_type. This is intended for
-      use with drivers that change their interface type.

-  
if_down()

-  
Mark the interface ifp as down (i.e.,
-      IFF_UP is not set), flush its output queue, notify
-      protocols of the transition, and generate a message from the
-      route(4) routing socket.

-  
if_up()

-  
Mark the interface ifp as up, notify protocols of
-      the transition, and generate a message from the route(4)
-      routing socket.

-  
()

-  
Add or remove a promiscuous reference to ifp. If
-      pswitch is true, add a reference; if it is false,
-      remove a reference. On reference count transitions from zero to one and
-      one to zero, set the IFF_PROMISC flag
-      appropriately and call if_ioctl() to set up the
-      interface in the desired mode.

-  
()

-  
As ifpromisc(), but for the all-multicasts
-      (IFF_ALLMULTI) flag instead of the promiscuous
-      flag.

-  
()

-  
Return an ifnet pointer for the interface named
-      name.

-  
()

-  
Return a reference-counted (via ifa_ref())
-      ifnet pointer for the interface named
-      name. This is the preferred function over
-      ifunit(). The caller is responsible for releasing
-      the reference with if_rele() when it is finished
-      with the ifnet.

-  
ifioctl()

-  
Process the ioctl request cmd, issued on socket
-      so by thread td, with data
-      parameter data. This is the main routine for
-      handling all interface configuration requests from user mode. It is
-      ordinarily only called from the socket-layer ioctl(2)
-      handler, and only for commands with class
-      ‘i’. Any unrecognized commands will
-      be passed down to socket so's protocol for further
-      interpretation. The following commands are handled by
-      ifioctl():
-    

-    

-    

-      

-      
Get interface configuration. (No call-down to driver.)
-        

-      

-      

-      
Set the interface name. RTM_IFANNOUNCE
-          departure and arrival messages are sent so that routing code that
-          relies on the interface name will update its interface list. Caller
-          must have appropriate privilege. (No call-down to driver.)

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
Get interface capabilities, data, FIB, flags, metric, MTU, medium
-          selection. (No call-down to driver.)
-        

-      

-      

-      
Enable or disable interface capabilities. Caller must have appropriate
-          privilege. Before a call to the driver-specific
-          ()
-          routine, the requested mask for enabled capabilities is checked
-          against the mask of capabilities supported by the interface,
-          if_capabilities. Requesting to enable an
-          unsupported capability is invalid. The rest is supposed to be done by
-          the driver, which includes updating if_capenable
-          and if_data.ifi_hwassist appropriately.
-        

-      

-      

-      
nv(9) version of the
-          SIOCGIFCAP ioctl. Caller must provide a
-          pointer to struct ifreq_cap_nv as
-          data, where the member
-          buffer points to some buffer containing
-          buf_length bytes. The serialized nvlist with
-          description of the device capabilities is written to the buffer. If
-          buffer is too short, the structure is updated with
-          buffer member set to
-          NULL, length set to
-          the minimal required length, and error EFBIG
-          is returned.
-        
Elements of the returned nvlist for simple capabilities
-            are boolean, identified by names. Presence of the boolean element
-            means that corresponding capability is supported by the interface.
-            Element's value describes the current configured state:
-            true means that the capability is enabled,
-            and false that it is disabled.

-        
Driver indicates support for both
-            SIOCGIFCAPNV and
-            SIOCSIFCAPNV requests by setting
-            IFCAP_NV non-modifiable capability bit in
-            if_capabilities.

-        

-      

-      

-      
nv(9) version of the
-          SIOCSIFCAP ioctl. Caller must provide the
-          pointer to struct ifreq_cap_nv as
-          data, where the member
-          buffer points to serialized nvlist of
-          length bytes. Each element of nvlist describes
-          a requested update of one capability, identified by the element name.
-          For simple capabilities, the element must be boolean. Its
-          true value means that the caller asks to
-          enable the capability, and false value to
-          disable. Only capabilities listed in the nvlist are affected by the
-          call.
-        

-      

-      

-      
Sets interface FIB. Caller must have appropriate privilege. FIB values
-          start at 0 and values greater or equals than
-          net.fibs are considered invalid.

-      

-      
Change interface flags. Caller must have appropriate privilege. If a
-          change to the IFF_UP flag is requested,
-          ()
-          or
-          ()
-          is called as appropriate. Flags listed in
-          IFF_CANTCHANGE are masked off, and the field
-          if_flags in the interface structure is updated.
-          Finally, the driver if_ioctl() routine is
-          called to perform any setup requested.
-        

-      

-      

-      
 

-      

-      
Change interface metric or medium. Caller must have appropriate
-          privilege.
-        

-      

-      

-      
Change interface MTU. Caller must have appropriate privilege. MTU
-          values less than 72 or greater than 65535 are considered invalid. The
-          driver
-          ()
-          routine is called to implement the change; it is responsible for any
-          additional sanity checking and for actually modifying the MTU in the
-          interface structure.
-        

-      

-      

-      
 

-      

-      
Add or delete permanent multicast group memberships on the interface.
-          Caller must have appropriate privilege. The
-          ()
-          or if_delmulti() function is called to perform
-          the operation; qq.v.
-        

-      

-      

-      
 

-      

-      
The socket's protocol control routine is called to implement the
-          requested action.

-    

-    

-  

-

-

-

-
Interface Address Functions

-
Several functions exist to look up an interface address structure
-    given an address.
-    ()
-    returns an interface address with either a local address or a broadcast
-    address precisely matching the parameter addr.
-    ()
-    returns an interface address for a point-to-point interface whose remote
-    (“destination”) address is addr and a
-    fib is fib. If fib is
-    RT_ALL_FIBS, then the first interface address
-    matching addr will be returned.

-
()
-    returns the most specific interface address which matches the specified
-    address, addr, subject to its configured netmask, or a
-    point-to-point interface address whose remote address is
-    addr if one is found. If
-    ignore_ptp is true, skip point-to-point interface
-    addresses. The fib parameter is handled the same way
-    as by
-    ().

-
()
-    returns the most specific address configured on interface
-    ifp which matches address addr,
-    subject to its configured netmask. If the interface is point-to-point, only
-    an interface address whose remote address is precisely
-    addr will be returned.

-
All of these functions return a null pointer if no such address
-    can be found.

-

-

-
Interface Multicast Address Functions

-
The
-    (),
-    if_delmulti(), and
-    if_findmulti() functions provide support for
-    requesting and relinquishing multicast group memberships, and for querying
-    an interface's membership list, respectively. The
-    if_addmulti() function takes a pointer to an
-    interface, ifp, and a generic address,
-    sa. It also takes a pointer to a
-    struct ifmultiaddr * which is filled in on successful
-    return with the address of the group membership control block. The
-    if_addmulti() function performs the following
-    four-step process:

-
    
-  
  1. Call the interface's
-      ()
-      entry point to determine the link-layer address, if any, corresponding to
-      this membership request, and also to give the link layer an opportunity to
-      veto this membership request should it so desire.
    2. 
-  
  2. Check the interface's group membership list for a pre-existing membership
-      for this group. If one is not found, allocate a new one; if one is,
-      increment its reference count.
    3. 
-  
  3. If the if_resolvemulti() routine returned a
-      link-layer address corresponding to the group, repeat the previous step
-      for that address as well.
    4. 
-  
  4. If the interface's multicast address filter needs to be changed because a
-      new membership was added, call the interface's
-      if_ioctl() routine (with a
-      cmd argument of
-      SIOCADDMULTI) to request that it do so.
    5. 
-

-
The
-    ()
-    function, given an interface ifp and an address,
-    sa, reverses this process. Both functions return zero
-    on success, or a standard error number on failure.

-
The
-    ()
-    function examines the membership list of interface ifp
-    for an address matching sa, and returns a pointer to
-    that struct ifmultiaddr if one is found, else it
-    returns a null pointer.

-

-

-

-

-
ioctl(2), link_addr(3),
-    queue(3), sysctl(3),
-    bpf(4), ifmib(4),
-    lo(4), netintro(4),
-    polling(4), config(8),
-    ppp(8), mbuf(9),
-    rtentry(9)

-
Gary R. Wright and
-    W. Richard Stevens, TCP/IP
-    Illustrated, Vol. 2,
-    Addison-Wesley, ISBN 0-201-63354-X.

-

-

-

-
This manual page was written by Garrett A.
-    Wollman.

-

-

-
-  
-    
-    
-  
-
December 10, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/inittodr.9 3.html b/static/freebsd/man9/inittodr.9 3.html
deleted file mode 100644
index 1b0460ad..00000000
--- a/static/freebsd/man9/inittodr.9 3.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
INITTODR(9)Kernel Developer's ManualINITTODR(9)

-

-

-

-
inittodr —
-    initialize system time

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  inittodr(time_t
-    base);

-

-

-

-
The
-    ()
-    function determines the time and sets the system clock. It tries to pick the
-    correct time using a set of heuristics that examine the system's battery
-    backed clock and the time obtained from the root file system, as given in
-    base. How the base value is
-    obtained will vary depending on the root file system type. The heuristics
-    used include:

-
    
-  
  • If the battery-backed clock has a valid time, it is used.
    • 
-  
  • If the battery-backed clock does not have a valid time, the time provided
-      in base will be used.
    • 
-

-
Once a system time has been determined, it is stored in the
-    time variable.

-

-

-

-
The inittodr() function prints diagnostic
-    messages if it has trouble figuring out the system time. Conditions that can
-    cause diagnostic messages to be printed include:

-
    
-  
  • The battery-backed clock's time appears nonsensical.
    • 
-

-

-

-

-
resettodr(9), time(9)

-

-

-

-
On many systems, inittodr() has to convert
-    from a time expressed in terms of year, month, day, hours, minutes, and
-    seconds to time, expressed in seconds. Many of the
-    implementations could share code, but do not.

-
Each system's heuristics for picking the correct time are slightly
-    different.

-
The FreeBSD implementation should do a
-    better job of validating the time provided in base
-    when the battery-backed clock is unusable. Currently it unconditionally sets
-    the system clock to this value.

-

-

-
-  
-    
-    
-  
-
March 22, 1997FreeBSD 15.0

diff --git a/static/freebsd/man9/insmntque.9 3.html b/static/freebsd/man9/insmntque.9 3.html
deleted file mode 100644
index 94bac6db..00000000
--- a/static/freebsd/man9/insmntque.9 3.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
INSMNTQUE(9)Kernel Developer's ManualINSMNTQUE(9)

-

-

-

-
insmntque,
-    insmntque1 — associate a
-    vnode with a mount

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  insmntque(struct
-    vnode *vp, struct mount
-    *mp);

-
int
-  

-  insmntque1(struct
-    vnode *vp, struct mount
-    *mp);

-

-

-

-
The
-    ()
-    function associates a vnode with a mount. This includes updating
-    v_mount for the vnode, and inserting the vnode into
-    the mount's vnode list.

-
The indirect mount reference count, maintained as the count of the
-    vnodes owned by it, is incremented for each vnode added to the mount, and
-    that reference is decremented by vgone(9).

-
The mount's interlock is held while the vnode is inserted. The
-    vnode must be exclusively locked.

-
On failure,
-    ()
-    resets vnode's operations vector to the vector of
-    deadfs(9), clears v_data, and then
-    calls vgone(9) and vput(9). If more
-    elaborated cleanup after insmntque() failure is
-    needed, the
-    ()
-    function may be used instead. It does not do any cleanup following a
-    failure, leaving all the work to the caller. In particular, the operations
-    vector v_op and v_data fields of
-    the vnode are kept intact.

-

-

-

-
The insmntque() function will always
-    return 0, unless the file system is currently being unmounted in which case
-    it may return EBUSY. Also,
-    insmntque() may be forced to insert the vnode into
-    the mount's vnode list by setting the VV_FORCEINSMQ
-    flag in the vnode v_flag, even if the file system is
-    being unmounted.

-

-

-

-
vgone(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
October 24, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/intr_event.9 3.html b/static/freebsd/man9/intr_event.9 3.html
deleted file mode 100644
index 07f157eb..00000000
--- a/static/freebsd/man9/intr_event.9 3.html	
+++ /dev/null
@@ -1,341 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTR_EVENT(9)Kernel Developer's ManualINTR_EVENT(9)

-

-

-

-
intr_event_add_handler,
-    intr_event_create,
-    intr_event_destroy,
-    intr_event_handle,
-    intr_event_remove_handler,
-    intr_priority — kernel
-    interrupt handler and thread API

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>
-  

-  #include <sys/interrupt.h>

-
int
-  

-  intr_event_add_handler(struct
-    intr_event *ie, const char *name,
-    driver_filter_t filter, driver_intr_t
-    handler, void *arg, u_char
-    pri, enum intr_type flags, void
-    **cookiep);

-
int
-  

-  intr_event_create(struct intr_event
-    **event, void *source, int
-    flags, int irq, void
-    (*pre_ithread)(void *), void (*post_ithread)(void
-    *), void (*post_filter)(void *),
-    int (*assign_cpu)(void *, int), const
-    char *fmt, ...);

-
int
-  

-  intr_event_destroy(struct
-    intr_event *ie);

-
int
-  

-  intr_event_handle(struct
-    intr_event *ie, struct
-    trapframe *frame);

-
int
-  

-  intr_event_remove_handler(void
-    *cookie);

-
u_char
-  

-  intr_priority(enum
-    intr_type flags);

-

-

-

-
The interrupt event API provides methods to manage the
-    registration and execution of interrupt handlers and their associated thread
-    contexts.

-
Each interrupt event in the system corresponds to a single
-    hardware or software interrupt source. Each interrupt event maintains a list
-    of interrupt handlers, sorted by priority, which will be invoked when
-    handling the event. An interrupt event will typically, but not always, have
-    an associated kthread(9), known as the interrupt thread.
-    Finally, each event contains optional callback functions which will be
-    invoked before and after the handler functions themselves.

-
An interrupt handler contains two distinct handler functions: the
-    filter and the thread handler. The
-    filter function is run from interrupt context and is
-    intended to perform quick handling such as acknowledging or masking a
-    hardware interrupt, and queueing work for the ensuing thread
-    handler. Both functions are optional; each interrupt
-    handler may choose to register a filter, a thread handler, or both. Each
-    interrupt handler also consists of a name, a set of flags, and an opaque
-    argument which will be passed to both the filter and
-    handler functions.

-

-

-
The filter function is executed inside a
-    critical(9) section. Therefore, filters may not yield the
-    CPU for any reason, and may only use spin locks to access shared data.
-    Allocating memory within a filter is not permitted.

-
The handler function executes from the context
-    of the associated interrupt kernel thread. Sleeping is not permitted, but
-    the interrupt thread may be preempted by higher priority threads. Thus,
-    threaded handler functions may obtain non-sleepable locks, as described in
-    locking(9). Any memory or zone allocations in an interrupt
-    thread must specify the M_NOWAIT flag, and any
-    allocation errors must be handled.

-
The exception to these constraints is software interrupt threads,
-    which are allowed to sleep but should be allocated and scheduled using the
-    swi(9) interface.

-

-

-

-
The
-    ()
-    function creates a new interrupt event. The event
-    argument points to a struct intr_event pointer that
-    will reference the newly created event upon success. The
-    source argument is an opaque pointer which will be
-    passed to the pre_ithread,
-    post_ithread, and post_filter
-    callbacks. The flags argument is a mask of properties
-    of this thread. The only valid flag currently for
-    intr_event_create() is
-    IE_SOFT to specify that this interrupt thread is a
-    software interrupt. The enable and
-    disable arguments specify optional functions used to
-    enable and disable this interrupt thread's interrupt source. The
-    irq argument is the unique interrupt vector number
-    corresponding to the event. The pre_ithread,
-    post_ithread, and post_filter
-    arguments are callback functions that are invoked at different points while
-    handling an interrupt. This is described in more detail in the
-    Handler Callbacks section,
-    below. They may be NULL to specify no callback. The
-    assign_cpu argument points to a callback function that
-    will be invoked when binding an interrupt to a particular CPU. It may be
-    NULL if binding is unsupported. The remaining
-    arguments form a printf(9) argument list that is used to
-    build the base name of the new interrupt thread. The full name of an
-    interrupt thread is formed by concatenating the base name of the interrupt
-    thread with the names of all of its interrupt handlers.

-
The
-    ()
-    function destroys a previously created interrupt event by releasing its
-    resources. An interrupt event can only be destroyed if it has no handlers
-    remaining.

-
The
-    ()
-    function adds a new handler to an existing interrupt event specified by
-    ie. The name argument specifies
-    a name for this handler. The filter argument provide
-    the filter function to execute. The handler argument
-    provides the handler function to be executed from the event's interrupt
-    thread. The arg argument will be passed to the
-    filter and handler functions
-    when they are invoked. The pri argument specifies the
-    priority of this handler, corresponding to the values defined in
-    <sys/priority.h>. It
-    determines the order this handler is called relative to the other handlers
-    for this event, as well as the scheduling priority of the backing kernel
-    thread. flags argument can be used to specify
-    properties of this handler as defined in
-    <sys/bus.h>. If
-    cookiep is not NULL, then it
-    will be assigned a cookie that can be used later to remove this handler.

-
The
-    ()
-    function is the main entry point into the interrupt handling code. It must
-    be called from an interrupt context. The function will execute all filter
-    handlers associated with the interrupt event ie, and
-    schedule the associated interrupt thread to run, if applicable. The
-    frame argument is used to pass a pointer to the
-    struct trapframe containing the machine state at the
-    time of the interrupt. The main body of this function runs within a
-    critical(9) section.

-
The
-    ()
-    function removes an interrupt handler from the interrupt event specified by
-    ie. The cookie argument,
-    obtained from intr_event_add_handler(), identifies
-    the handler to remove.

-
The
-    ()
-    function translates the INTR_TYPE_* interrupt flags
-    into interrupt thread scheduling priorities.

-
The interrupt flags not related to the type of a particular
-    interrupt (INTR_TYPE_*) can be used to specify
-    additional properties of both hardware and software interrupt handlers. The
-    INTR_EXCL flag specifies that this handler cannot
-    share an interrupt thread with another handler. The
-    INTR_MPSAFE flag specifies that this handler is MP
-    safe in that it does not need the Giant mutex to be held while it is
-    executed. The INTR_ENTROPY flag specifies that the
-    interrupt source this handler is tied to is a good source of entropy, and
-    thus that entropy should be gathered when an interrupt from the handler's
-    source triggers. Presently, the INTR_ENTROPY flag is
-    not valid for software interrupt handlers. The
-    INTR_SLEEPABLE flag specifies that the interrupt
-    ithread may sleep. Presently, the INTR_SLEEPABLE
-    flag requires the INTR_EXCL flag to be set.

-

-

-

-
Each struct intr_event is assigned three
-    optional callback functions when it is created:
-    pre_ithread, post_ithread, and
-    post_filter. These callbacks are intended to be
-    defined by the interrupt controller driver, to allow for actions such as
-    masking and unmasking hardware interrupt signals.

-
When an interrupt is triggered, all filters are run to determine
-    if any threaded interrupt handlers should be scheduled for execution by the
-    associated interrupt thread. If no threaded handlers are scheduled, the
-    post_filter callback is invoked which should
-    acknowledge the interrupt and permit it to trigger in the future. If any
-    threaded handlers are scheduled, the pre_ithread
-    callback is invoked instead. This handler should acknowledge the interrupt,
-    but it should also ensure that the interrupt will not fire continuously
-    until after the threaded handlers have executed. Typically this callback
-    masks level-triggered interrupts in an interrupt controller while leaving
-    edge-triggered interrupts alone. Once all threaded handlers have executed,
-    the post_ithread callback is invoked from the
-    interrupt thread to enable future interrupts. Typically this callback
-    unmasks level-triggered interrupts in an interrupt controller.

-

-

-

-

-
The intr_event_add_handler(),
-    intr_event_create(),
-    intr_event_destroy(),
-    intr_event_handle(), and
-    intr_event_remove_handler() functions return zero on
-    success and non-zero on failure. The intr_priority()
-    function returns a process priority corresponding to the passed in interrupt
-    flags.

-

-

-

-
The swi_add(9) function demonstrates the use of
-    intr_event_create() and
-    intr_event_add_handler().

-

-
int
-swi_add(struct intr_event **eventp, const char *name, driver_intr_t handler,
-    void *arg, int pri, enum intr_type flags, void **cookiep)
-{
-	struct intr_event *ie;
-	int error = 0;
-
-	if (flags & INTR_ENTROPY)
-		return (EINVAL);
-
-	ie = (eventp != NULL) ? *eventp : NULL;
-
-	if (ie != NULL) {
-		if (!(ie->ie_flags & IE_SOFT))
-			return (EINVAL);
-	} else {
-		error = intr_event_create(&ie, NULL, IE_SOFT, 0,
-		    NULL, NULL, NULL, swi_assign_cpu, "swi%d:", pri);
-		if (error)
-			return (error);
-		if (eventp != NULL)
-			*eventp = ie;
-	}
-	if (handler != NULL) {
-		error = intr_event_add_handler(ie, name, NULL, handler, arg,
-		    PI_SWI(pri), flags, cookiep);
-	}
-	return (error);
-}

-

-

-

-

-
The intr_event_add_handler() function will
-    fail if:

-

-  
[]

-  
The ie or name arguments are
-      NULL.

-  
[]

-  
The handler and filter
-      arguments are both NULL.

-  
[]

-  
The IH_EXCLUSIVE flag is specified and the
-      interrupt thread ie already has at least one
-      handler, or the interrupt thread ie already has an
-      exclusive handler.

-

-
The intr_event_create() function will fail
-    if:

-

-  
[]

-  
A flag other than IE_SOFT was specified in the
-      flags parameter.

-

-
The intr_event_destroy() function will
-    fail if:

-

-  
[]

-  
The ie argument is
-    NULL.

-  
[]

-  
The interrupt event pointed to by ie has at least
-      one handler which has not been removed with
-      intr_event_remove_handler().

-

-
The intr_event_handle() function will fail
-    if:

-

-  
[]

-  
The ie argument is
-    NULL.

-  
[]

-  
There are no interrupt handlers assigned to ie.

-  
[]

-  
The interrupt was not acknowledged by any filter and has no associated
-      thread handler.

-

-
The intr_event_remove_handler() function
-    will fail if:

-

-  
[]

-  
The cookie argument is
-    NULL.

-

-

-

-

-
critical(9), kthread(9),
-    locking(9), malloc(9),
-    swi(9), uma(9)

-

-

-

-
Interrupt threads and their corresponding API first appeared in
-    FreeBSD 5.0.

-

-

-
-  
-    
-    
-  
-
January 24, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/intro.9 3.html b/static/freebsd/man9/intro.9 3.html
deleted file mode 100644
index 9c218a7a..00000000
--- a/static/freebsd/man9/intro.9 3.html	
+++ /dev/null
@@ -1,387 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(9)Kernel Developer's ManualINTRO(9)

-

-

-

-
intro —
-    introduction to kernel programming interfaces

-

-

-

-
Welcome to the FreeBSD kernel
-    documentation. Outside the source code itself, this set of
-    man(1) pages is the primary resource for information on
-    usage of the numerous programming interfaces available within the kernel. In
-    some cases, it is also a source of truth for the implementation details
-    and/or design decisions behind a particular subsystem or piece of code.

-
The intended audience of this documentation is developers, and the
-    primary authors are also developers. It is written assuming a certain
-    familiarity with common programming or OS-level concepts and practices.
-    However, this documentation should also attempt to provide enough background
-    information that readers approaching a particular subsystem or interface for
-    the first time will be able to understand.

-
To further set expectations, we acknowledge that kernel
-    documentation, like the source code itself, is forever a work-in-progress.
-    There will be large sections of the codebase whose documentation is subtly
-    or severely outdated, or missing altogether. This documentation is a
-    supplement to the source code, and cannot always be taken at face value.

-
At its best, section 9 documentation will provide a description of
-    a particular piece of code that, paired with its implementation, fully
-    informs the reader of the intended and realized effects.

-
man(1) pages in this section most frequently
-    describe functions, but may also describe types, global variables, macros,
-    or high-level concepts.

-

-

-

-
Code written for the FreeBSD kernel is
-    expected to conform to the established style and coding conventions. Please
-    see style(9) for a detailed set of rules and
-  guidelines.

-

-

-

-
Below is presented various subsystems.

-

-

-
There are implementations for many well-known data structures
-    available in the kernel.

-

-  
bitstring(3)

-  
Simple bitmap implementation.

-  
counter(9)

-  
An SMP-safe general-purpose counter implementation.

-  
hash(9)

-  
Hash map implementation.

-  
nv(9)

-  
Name/value pairs.

-  
queue(3)

-  
Singly-linked and doubly-linked lists, and queues.

-  
refcount(9)

-  
An SMP-safe implementation of reference counts.

-  
sbuf(9)

-  
Dynamic string composition.

-  
sglist(9)

-  
A scatter/gather list implementation.

-

-

-

-

-
Functions or facilities of general usefulness or convenience. See
-    also the Testing and
-    Debugging Tools or Miscellaneous
-    sub-sections below.

-
Formatted output and logging functions are described by
-    printf(9).

-
Endian-swapping functions: byteorder(9).

-
Data output in hexadecimal format:
-  hexdump(9).

-
A rich set of macros for declaring sysctl(8)
-    variables and functions is described by sysctl(9).

-
Non-recoverable errors in the kernel should
-    trigger a panic(9). Run-time assertions can be verified
-    using the KASSERT(9) macros. Compile-time assertions
-    should use
-    ().

-
The SYSINIT framework provides macros for declaring functions that
-    will be executed during start-up and shutdown; see
-    SYSINIT(9).

-
Deprecation messages may be emitted with
-    gone_in(9).

-
A unit number facility is provided by
-  unr(9).

-

-

-

-
The locking(9) man page gives an overview of the
-    various types of locks available in the kernel and advice on their
-  usage.

-
Atomic primitives are described by
-  atomic(9).

-
The epoch(9) and smr(9)
-    facilities are used to create lock-free data structures. There is also
-    seqc(9).

-

-

-

-
Dynamic memory allocations inside the kernel are generally done
-    using malloc(9). Frequently allocated objects may prefer
-    to use uma(9).

-
Much of the virtual memory system operates on
-    vm_page_t structures. The following functions are
-    documented:

-
vm_page_advise(9),
-  vm_page_aflag(9), vm_page_alloc(9),
-  vm_page_bits(9), vm_page_busy(9),
-  vm_page_deactivate(9), vm_page_free(9),
-  vm_page_grab(9), vm_page_insert(9),
-  vm_page_lookup(9), vm_page_rename(9),
-  vm_page_sbusy(9), vm_page_wire(9)

-
Virtual address space maps are managed with the
-    vm_map(9) API.

-
The machine-dependent portion of the virtual memory stack is the
-    pmap(9) module.

-
Allocation policies for NUMA memory domains are managed with the
-    domainset(9) API.

-

-

-

-
The kernel interface for file systems is VFS(9).
-    File system implementations register themselves with
-    vfsconf(9).

-
The vnode(9) is the abstract and
-    filesystem-independent representation of a file, directory, or other
-    file-like entity within the kernel.

-
The implementation of access control lists for filesystems is
-    described by acl(9). Also
-  vaccess(9).

-

-

-

-
The GEOM framework represents I/O requests using the
-    bio(9) structure.

-
Disk drivers connect themselves to GEOM using the
-    disk(9) API.

-
The devstat(9) facility provides an interface
-    for recording device statistics in disk drivers.

-

-

-

-
Much of the networking stack uses the mbuf(9), a
-    flexible memory management unit commonly used to store network packets.

-
Network interfaces are implemented using the
-    ifnet(9) API, which has functions for drivers and
-    consumers.

-
A framework for managing packet output queues is described by
-    altq(9).

-
To receive incoming packets, network protocols register themselves
-    with netisr(9).

-
Virtualization of the network stack is provided by
-    VNET(9).

-
The front-end for interfacing with network sockets from within the
-    kernel is described by socket(9). The back-end interface
-    for socket implementations is domain(9).

-
The low-level packet filter interface is described by
-    pfil(9).

-
The bpf(9) interface provides a mechanism to
-    redirect packets to userspace.

-
The subsystem for IEEE 802.11 wireless networking is described by
-    ieee80211(9).

-
A framework for modular TCP implementations is described by
-    tcp_functions(9).

-
A framework for modular congestion control algorithms is described
-    by mod_cc(9).

-

-

-

-
Consult the device(9) and
-    driver(9) pages first.

-
Most drivers act as devices, and provide a set of methods
-    implementing the device interface. This includes methods such as
-    DEVICE_PROBE(9), DEVICE_ATTACH(9), and
-    DEVICE_DETACH(9).

-
In addition to devices, there are buses. Buses may have children,
-    in the form of devices or other buses. Bus drivers will implement additional
-    methods, such as BUS_ADD_CHILD(9),
-    BUS_READ_IVAR(9), or BUS_RESCAN(9).

-
Buses often perform resource accounting on behalf of their
-    children. For this there is the rman(9) API.

-
Drivers can request and manage their resources (e.g. memory-space
-    or IRQ number) from their parent using the following sets of functions:

-
bus_alloc_resource(9),
-  bus_adjust_resource(9),
-  bus_get_resource(9), bus_map_resource(9),
-  bus_release_resource(9),
-  bus_set_resource(9)

-
Direct Memory Access (DMA) is handled using the
-    busdma(9) framework.

-
Functions for accessing bus space (i.e. read/write) are provided
-    by bus_space(9).

-

-

-

-
The kernel clock frequency and overall system time model is
-    described by hz(9).

-
A few global time variables, such as system up-time, are described
-    by time(9).

-
Raw CPU cycles are provided by
-    get_cyclecount(9).

-

-

-

-
Direct read/write access of userspace memory from the kernel is
-    not permitted, and memory transactions that cross the kernel/user boundary
-    must go through one of several interfaces built for this task.

-
Most device drivers use the uiomove(9) set of
-    routines.

-
Simpler primitives for reading or writing smaller chunks of memory
-    are described by casuword(9), copy(9),
-    fetch(9), and store(9).

-

-

-

-
Kernel threads and processes are created using the
-    kthread(9) and kproc(9) interfaces,
-    respectively.

-
Where dedicated kernel threads are too heavyweight, there is also
-    the taskqueue(9) interface.

-
For low-latency callback handling, the
-    callout(9) framework should be used.

-
Dynamic handlers for pre-defined event hooks are registered and
-    invoked using the EVENTHANDLER(9) API.

-

-

-

-
The machine-independent interface to a context switch is
-    mi_switch(9).

-
To prevent preemption, use a critical(9)
-    section.

-
To voluntarily yield the processor, use
-    kern_yield(9).

-
The various functions which will deliberately put a thread to
-    sleep are described by sleep(9). Sleeping threads are
-    removed from the scheduler and placed on a
-  sleepqueue(9).

-

-

-

-
To locate a process or process group by its identifier, use
-    pfind(9) and pgfind(9). Alternatively,
-    the pget(9) function provides additional search
-    specificity.

-
The "hold count" of a process can be manipulated with
-    PHOLD(9).

-
The kernel interface for signals is described by
-    signal(9).

-
Signals can be sent to processes or process groups using the
-    functions described by psignal(9).

-

-

-

-
See the overview in security(7).

-
The basic structure for user credentials is struct
-    ucred, managed by the ucred(9) API. Thread
-    credentials are verified using priv(9) to allow or deny
-    certain privileged actions.

-
Policies influenced by kern.securelevel must
-    use the securelevel_gt(9) or
-    securelevel_ge(9) functions.

-
The Mandatory Access Control (MAC) framework provides a wide set
-    of hooks, supporting dynamically-registered security modules; see
-    mac(9).

-
Cryptographic services are provided by the OpenCrypto framework.
-    This API provides an interface for both consumers and crypto drivers; see
-    crypto(9).

-
For information on random number generation, see
-    random(9) and prng(9).

-

-

-

-
The interfaces for declaring loadable kernel modules are described
-    by module(9).

-

-

-

-
intr_event(9) describes the machine-independent
-    portion of the interrupt framework that supports registration and execution
-    of interrupt handlers.

-
Software interrupts are provided by swi(9).

-
Device drivers register their interrupt handlers using the
-    bus_setup_intr(9) function.

-

-

-

-
A kernel test framework: kern_testfrwk(9)

-
A facility for defining configurable fail points is described by
-    fail(9).

-
Commands for the ddb(4) kernel debugger are
-    defined with the DB_COMMAND(9) family of macros.

-
The ktr(4) tracing facility adds static
-    tracepoints to many areas of the kernel. These tracepoints are defined using
-    the macros described by ktr(9).

-
Static probes for DTrace are defined using the
-    SDT(9) macros.

-
Stack traces can be captured and printed with the
-    stack(9) API.

-
Kernel sanitizers can perform additional compiler-assisted checks
-    against memory use/access. These runtimes are capable of detecting
-    difficult-to-identify classes of bugs, at the cost of a large overhead. The
-    Kernel Address Sanitizer KASAN(9) and Kernel Memory
-    Sanitizer KMSAN(9) are supported.

-
The LOCK_PROFILING(9) kernel config option
-    enables extra code to assist with profiling and/or debugging lock
-    performance.

-

-

-

-
Defined functions/APIs for specific types of devices.

-

-  
iflib(9)

-  
Programming interface for iflib(4) based network
-      drivers.

-  
pci(9)

-  
Peripheral Component Interconnect (PCI) and PCI Express (PCIe) programming
-      API.

-  
pwmbus(9)

-  
Pulse-Width Modulation (PWM) bus interface methods.

-  
usbdi(9)

-  
Universal Serial Bus programming interface.

-  
superio(9)

-  
Functions for Super I/O controller devices.

-

-

-

-

-
Dynamic per-CPU variables: dpcpu(9).

-
CPU bitmap management: cpuset(9).

-
Kernel environment management: getenv(9).

-
Contexts for CPU floating-point registers are managed by the
-    fpu_kern(9) facility.

-
For details on the shutdown/reboot procedure and available
-    shutdown hooks, see reboot(9).

-
A facility for asynchronous logging to files from within the
-    kernel is provided by alq(9).

-
The osd(9) framework provides a mechanism to
-    dynamically extend core structures in a way that preserves KBI. See the
-    hhook(9) and khelp(9) APIs for
-    information on how this is used.

-
The kernel object implementation is described by
-    kobj(9).

-

-

-

-

-
man(1), style(9)

-
The FreeBSD Architecture
-    Handbook,
-    https://docs.freebsd.org/en/books/arch-handbook/.

-

-

-
-  
-    
-    
-  
-
January 30, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/kasan.9 3.html b/static/freebsd/man9/kasan.9 3.html
deleted file mode 100644
index c5bf9093..00000000
--- a/static/freebsd/man9/kasan.9 3.html	
+++ /dev/null
@@ -1,137 +0,0 @@
-
-  
-    
-    
-    
-  
-
KASAN(9)Kernel Developer's ManualKASAN(9)

-

-

-

-
KASAN — Kernel
-    Address SANitizer

-

-

-

-
The GENERIC-KASAN kernel configuration can
-    be used to compile a KASAN-enabled kernel using
-    GENERIC as a base configuration. Alternately, to
-    compile KASAN into the kernel, place the following line in your kernel
-    configuration file:

-
options KASAN

-

-  

-  #include <sys/asan.h>

-
void
-  

-  kasan_mark(const
-    void *addr, size_t
-    size, size_t
-    redzsize, uint8_t
-    code);

-

-

-

-
KASAN is a subsystem which leverages
-    compiler instrumentation to detect invalid memory accesses in the kernel.
-    Currently it is implemented on the amd64 and arm64 platforms.

-
When KASAN is compiled
-    into the kernel, the compiler is configured to emit function calls upon
-    every memory access. The functions are implemented by
-    KASAN and permit run-time detection of several types
-    of bugs including use-after-frees, double frees and frees of invalid
-    pointers, and out-of-bounds accesses. These protections apply to memory
-    allocated by uma(9), malloc(9) and
-    related functions, and
-    ()
-    and related functions, as well as global variables and kernel stacks.
-    KASAN is conservative and will not detect all
-    instances of these types of bugs. Memory accesses through the kernel map are
-    sanitized, but accesses via the direct map are not. When
-    KASAN is configured, the kernel aims to minimize its
-    use of the direct map.

-

-

-

-
KASAN is implemented using compiler
-    instrumentation and a kernel runtime. When a kernel is built with the KASAN
-    option enabled, the compiler inserts function calls before most memory
-    accesses in the generated code. The runtime implements the corresponding
-    functions, which decide whether a given access is valid. If not, the runtime
-    prints a warning or panics the kernel, depending on the value of the
-    
-    sysctl/tunable.

-
The KASAN
-    runtime in a KASAN-configured kernel can be disabled by setting the loader
-    tunable
-    .

-
The KASAN runtime works by maintaining a
-    shadow map for the kernel map. There exists a linear mapping between
-    addresses in the kernel map and addresses in the shadow map. The shadow map
-    is used to store information about the current state of allocations from the
-    kernel map. For example, when a buffer is returned by
-    malloc(9), the corresponding region of the shadow map is
-    marked to indicate that the buffer is valid. When it is freed, the shadow
-    map is updated to mark the buffer as invalid. Accesses to the buffer are
-    intercepted by the KASAN runtime and validated using
-    the contents of the shadow map.

-
Upon booting, all kernel memory is marked as valid. Kernel
-    allocators must mark cached but free buffers as invalid, and must mark them
-    valid before freeing the kernel virtual address range. This slightly reduces
-    the effectiveness of KASAN but simplifies its
-    maintenance and integration into the kernel.

-
Updates to the shadow map are performed by calling
-    kasan_mark(). Parameter addr
-    is the address of the buffer whose shadow is to be updated,
-    size is the usable size of the buffer, and
-    redzsize is the full size of the buffer allocated from
-    lower layers of the system. redzsize must be greater
-    than or equal to size. In some cases kernel allocators
-    will return a buffer larger than that requested by the consumer; the unused
-    space at the end is referred to as a red zone and is always marked as
-    invalid. code allows the caller to specify an
-    identifier used when marking a buffer as invalid. The identifier is included
-    in any reports generated by KASAN and helps identify
-    the source of the invalid access. For instance, when an item is freed to a
-    uma(9) zone, the item is marked with
-    KASAN_UMA_FREED. See
-    <sys/asan.h> for the
-    available identifiers. If the entire buffer is to be marked valid, i.e.,
-    size and redzsize are equal,
-    code should be 0.

-

-

-

-
build(7), KMSAN(9),
-    malloc(9), memguard(9),
-    redzone(9), uma(9)

-

-

-

-
KASAN was ported from
-    NetBSD and first appeared in
-    FreeBSD 13.1.

-

-

-

-
Accesses to kernel memory outside of the kernel map are ignored by
-    the KASAN runtime. When
-    KASAN is configured, the kernel memory allocators
-    are configured to use the kernel map, but some uses of the direct map
-    remain. For example, on amd64 and arm64, accesses to page table pages are
-    not tracked.

-
Some kernel memory allocators explicitly permit accesses after an
-    object has been freed. These cannot be sanitized by
-    KASAN. For example, memory from all
-    uma(9) zones initialized with the
-    UMA_ZONE_NOFREE flag are not sanitized.

-

-

-
-  
-    
-    
-  
-
October 13, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/kern_reboot.9 3.html b/static/freebsd/man9/kern_reboot.9 3.html
deleted file mode 100644
index 126aea0f..00000000
--- a/static/freebsd/man9/kern_reboot.9 3.html	
+++ /dev/null
@@ -1,228 +0,0 @@
-
-  
-    
-    
-    
-  
-
REBOOT(9)Kernel Developer's ManualREBOOT(9)

-

-

-

-
kern_reboot,
-    shutdown_nice — reboot,
-    halt, or power off the system

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/reboot.h>

-
extern int rebooting;

-
void
-  

-  kern_reboot(int
-    howto);

-
void
-  

-  shutdown_nice(int
-    howto);

-
#include
-    <sys/eventhandler.h>

-
EVENTHANDLER_REGISTER(shutdown_pre_sync,
-    shutdown_fn,
-    private,
-    priority);

-
EVENTHANDLER_REGISTER(shutdown_post_sync,
-    shutdown_fn,
-    private,
-    priority);

-
EVENTHANDLER_REGISTER(shutdown_final,
-    shutdown_fn,
-    private,
-    priority);

-

-

-

-
The
-    ()
-    function handles final system shutdown, and either halts, reboots, or powers
-    down the system. The exact action to be taken is determined by the flags
-    passed in howto.

-
The relevant flags are:

-

-

-  

-  
Halt the system in-place rather than restarting.

-  

-  
Power down the system rather than restarting.

-  

-  
Request a power-cycle in addition to restarting.

-  

-  
Do not sync filesystems during shutdown.

-  

-  
Dump kernel memory during shutdown.

-

-

-
The howto field, and its full list of flags
-    are described in additional detail by reboot(2).

-
()
-    performs the following actions:

-
    
-  
  1. Set the rebooting variable to
-      1, indicating that the reboot process has begun
-      and cannot be stopped.
    2. 
-  
  2. Unless the RB_NOSYNC flag is set in
-      howto, sync and unmount the system's disks by
-      calling vfs_unmountall(9).
    3. 
-  
  3. If rebooting after a panic (RB_DUMP
-      is set in howto, but RB_HALT
-      is not set), initiate a system crash dump via
-      ().
    4. 
-  
  4. Print a message indicating that the system is about to be halted or
-      rebooted, and a report of the total system uptime.
    5. 
-  
  5. Execute all registered shutdown hooks. See
-      SHUTDOWN HOOKS below.
    6. 
-  
  6. As a last resort, if none of the shutdown hooks handled the
-      reboot, call the machine-dependent
-      ()
-      function. In the unlikely case that this is not supported,
-      kern_reboot() will loop forever at the end of the
-      function. This requires a manual reset of the system.
    7. 
-

-
()
-    may be called from a typical kernel execution context, when the system is
-    running normally. It may also be called as the final step of a kernel panic,
-    or from the kernel debugger. Therefore, the code in this function is subject
-    to restrictions described by the
-    EXECUTION CONTEXT section of the
-    panic(9) man page.

-
The
-    ()
-    function is the intended path for performing a clean reboot or shutdown when
-    the system is operating under normal conditions. Calling this function will
-    send a signal to the init(8) process, instructing it to
-    perform a shutdown. When init(8) has cleanly terminated
-    its children, it will perform the reboot(2) system call,
-    which in turn calls kern_reboot().

-
If
-    ()
-    is called before the init(8) process has been spawned, or
-    if the system has panicked or otherwise halted,
-    kern_reboot() will be called directly.

-

-

-

-
The system defines three separate
-    EVENTHANDLER(9) events, which are invoked successively
-    during the shutdown procedure. These are
-    shutdown_pre_sync,
-    shutdown_post_sync, and
-    shutdown_final. They will be executed unconditionally
-    in the listed order. Handler functions registered to any of these events
-    will receive the value of howto as their second
-    argument, which may be used to decide what action to take.

-
The shutdown_pre_sync event is invoked
-    before syncing filesystems to disk. It enables any action or state
-    transition that must happen before this point to take place.

-
The shutdown_post_sync event is invoked at
-    the point immediately after the filesystem sync has finished. It enables,
-    for example, disk drivers to complete the sync by flushing their cache to
-    disk. Note that this event still takes place before the optional kernel core
-    dump.

-
The shutdown_final event
-    is invoked as the very last step of
-    ().
-    Drivers and subsystems such as acpi(4) can register
-    handlers to this event that will perform the actual reboot, power-off, or
-    halt.

-
Notably, the shutdown_final event is also
-    the point at which all kernel modules will have their shutdown
-    (MOD_SHUTDOWN) hooks executed, and when the
-    DEVICE_SHUTDOWN(9) method will be executed recursively on
-    all devices.

-
All event handlers, like
-    ()
-    itself, may be run in either normal shutdown context or a kernel panic or
-    debugger context. Handler functions are expected to take care not to trigger
-    recursive panics.

-

-

-

-
The kern_reboot() function does not
-    return.

-
The shutdown_nice() function will usually
-    return to its caller, having initiated the asynchronous system shutdown. It
-    will not return when called from a panic or debugger context, or during
-    early boot.

-

-

-

-
A hypothetical driver, foo(4), defines a
-    shutdown_final event handler that can handle system
-    power-off by writing to a device register, but it does not handle halt or
-    reset.

-

-
void
-foo_poweroff_handler(struct void *arg, int howto)
-{
-        struct foo_softc *sc = arg;
-        uint32_t reg;
-
-        if ((howto & RB_POWEROFF) != 0) {
-                reg = FOO_POWEROFF;
-                WRITE4(sc, FOO_POWEROFF_REG, reg);
-        }
-}

-

-
The handler is then registered in the device attach routine:

-

-
int
-foo_attach(device_t dev)
-{
-        struct foo_softc *sc;
-
-        ...
-
-        /* Pass the device's software context as the private arg. */
-        EVENTHANDLER_REGISTER(shutdown_final, foo_poweroff_handler, sc,
-            SHUTDOWN_PRI_DEFAULT);
-
-        ...
-}

-

-
This shutdown_final handler uses the
-    RB_NOSYNC flag to detect that a panic or other
-    unusual condition has occurred, and returns early:

-

-
void
-bar_shutdown_final(struct void *arg, int howto)
-{
-
-        if ((howto & RB_NOSYNC) != 0)
-                return;
-
-        /* Some code that is not panic-safe. */
-        ...
-}

-

-

-

-

-
reboot(2), init(8),
-    DEVICE_SHUTDOWN(9), EVENTHANDLER(9),
-    module(9), panic(9),
-    vfs_unmountall(9)

-

-

-
-  
-    
-    
-  
-
November 23, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/kern_testfrwk.9 3.html b/static/freebsd/man9/kern_testfrwk.9 3.html
deleted file mode 100644
index 71687c21..00000000
--- a/static/freebsd/man9/kern_testfrwk.9 3.html	
+++ /dev/null
@@ -1,150 +0,0 @@
-
-  
-    
-    
-    
-  
-
KERN_TESTFRWK(9)Kernel Developer's ManualKERN_TESTFRWK(9)

-

-

-

-
kern_testfrwk — A
-    kernel testing framework

-

-

-

-
kldload kern_testfrwk

-

-

-

-
So what is this sys/tests directory in the kernel all about?

-
Have you ever wanted to test a part of the
-    FreeBSD kernel in some way and you had no real way
-    from user-land to make what you want to occur happen? Say an error path or
-    situation where locking occurs in a particular manner that happens only once
-    in a blue moon?

-
If so, then the kernel test framework is just what you are looking
-    for. It is designed to help you create the situation you want.

-
There are two components to the system: the test framework and
-    your test. This document will describe both components and use the test
-    submitted with the initial commit of this code to discuss the test
-    (callout_test(4)). All of the tests become kernel loadable
-    modules. The test you write should have a dependency on the test framework.
-    That way it will be loaded automatically with your test. For example, you
-    can see how to do this in the bottom of callout_test.c in
-    sys/tests/callout_test/callout_test.c.

-
The framework itself is in
-    sys/tests/framework/kern_testfrwk.c. Its job is to
-    manage the tests that are loaded. (More than one can be loaded.) The idea is
-    pretty simple; you load the test framework and then load your test.

-
When your test loads, you
-    register your tests with the kernel test framework. You do that through a
-    call to
-    ().
-    Usually this is done at the module load event as shown below:

-

-
	switch (type) {
-	case MOD_LOAD:
-		err = kern_testframework_register("callout_test",
-		    run_callout_test);

-

-
Here the test is "callout_test"
-    and it is registered to run the function
-    ()
-    passing it a struct kern_test *ptr. The
-    kern_test structure is defined in
-    kern_testfrwk.h.

-

-
struct kern_test {
-	char name[TEST_NAME_LEN];
-	int num_threads;  /* Fill in how many threads you want */
-	int tot_threads_running;       /* Private to framework */
-	uint8_t test_options[TEST_OPTION_SPACE];
-};

-

-
The user sends this structure down via a sysctl to start your
-    test. He or she places the same name you registered
-    ("callout_test" in our example) in the name
-    field. The user can also set the number of threads to run with
-    num_threads.

-
The framework will start the requested
-    number of kernel threads, all running your test at the same time. The user
-    does not specify anything in tot_threads_running; it
-    is private to the framework. As the framework calls each of your tests, it
-    will set the tot_threads_running to the index of the
-    thread that your call is made from. For example, if the user sets
-    num_threads to 2, then the function
-    ()
-    will be called once with tot_threads_running to 0, and
-    a second time with tot_threads_running set to 1.

-
The test_options field is a test-specific
-    set of information that is an opaque blob. It is passed in from user space
-    and has a maximum size of 256 bytes. You can pass arbitrary test input in
-    the space. In the case of callout_test we reshape that to:

-

-
struct callout_test {
-	int number_of_callouts;
-	int test_number;
-};

-

-
So the first lines of
-    ()
-    does the following to get at the user specific data:

-

-
	struct callout_test *u;
-	size_t sz;
-	int i;
-	struct callout_run *rn;
-	int index = test->tot_threads_running;
-
-	u = (struct callout_test *)test->test_options;

-

-
That way it can access: u->test_number
-    (there are two types of tests provided with this test) and
-    u->number_of_callouts (how many simultaneous
-    callouts to run).

-
Your test can do anything with these
-    bytes. So the callout_test in question wants to create a situation where
-    multiple callouts are all run, that is the
-    number_of_callouts, and it tries to cancel the callout
-    with the new
-    ().
-    The threads do this by acquiring the lock in question, and then starting
-    each of the callouts. It waits for the callouts to all go off (the executor
-    spins waits). This forces the situation that the callouts have expired and
-    are all waiting on the lock that the executor holds. After the callouts are
-    all blocked, the executor calls
-    callout_async_drain() on each callout and releases
-    the lock.

-
After all the callouts are done, a total status is printed showing
-    the results via printf(9). The human tester can run
-    dmesg(8) to see the results. In this case it is expected
-    that if you are running test 0, all the callouts expire on the same CPU so
-    only one callout_drain function would have been called. the number of
-    zero_returns should match the number of callout_drains that were called,
-    i.e., 1. The one_returns should be the remainder of the callouts. If the
-    test number was 1, the callouts were spread across all CPUs. The number of
-    zero_returns will again match the number of drain calls made which matches
-    the number of CPUs that were put in use.

-
More than one thread can be used with this test, though in the
-    example case it is probably not necessary.

-
You should not need to change the framework. Just add tests and
-    register them after loading.

-

-

-

-
The kernel test framework was written by Randall
-    Stewart
-    <rrs@FreeBSD.org> with
-    help from
-  

-  John Mark Gurney
-    <jmg@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 12, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/kern_yield.9 3.html b/static/freebsd/man9/kern_yield.9 3.html
deleted file mode 100644
index 2be273f0..00000000
--- a/static/freebsd/man9/kern_yield.9 3.html	
+++ /dev/null
@@ -1,114 +0,0 @@
-
-  
-    
-    
-    
-  
-
KERN_YIELD(9)Kernel Developer's ManualKERN_YIELD(9)

-

-

-

-
kern_yield,
-    maybe_yield, should_yield
-    — functions for yielding execution of the current
-    thread

-

-

-

-
void
-  

-  kern_yield(int
-    prio);

-
void
-  

-  maybe_yield();

-
bool
-  

-  should_yield();

-

-

-

-
The
-    ()
-    function causes the currently running thread to voluntarily, but
-    unconditionally, surrender its execution to the scheduler. The
-    prio argument specifies the scheduling priority to be
-    assigned before the context switch, which has an influence on when execution
-    will resume. Note that the requested priority will take effect until the
-    thread returns to usermode, after which its base user priority will be
-    restored. Valid values for prio are any of the
-    PRI_* values defined in
-    <sys/priority.h>, as well as
-    the following special values:

-

-  

-  
Schedule the thread with its base user priority; the value corresponding
-      to setpriority(2) / nice(3).

-  

-  
Yield the thread without changing its priority.

-

-
The
-    ()
-    function checks if sufficient time has passed since the thread's last
-    voluntary context switch that yielding would be a useful service to other
-    threads. It returns true when this is the case. See
-    USAGE NOTES for an elaboration of what
-    this means.

-
The
-    ()
-    function is a helper function for the common task of optionally yielding the
-    processor. Internally,
-    kern_yield(PRI_USER) will be
-    called if should_yield() returns
-    true.

-

-

-

-
Although the kernel supports preemption, this is usually reserved
-    for high-priority realtime or interrupt threads. Kernel worker threads and
-    timesharing threads are not guaranteed to preempt each another. Thus,
-    threads executing in the kernel are expected to behave cooperatively with
-    respect to other threads in the system. The yield functions are mostly
-    intended to be used by threads which perform a lot of work inside the
-    kernel. For example: maybe_yield() is called by the
-    vlnru process each time it reclaims a vnode.

-
The scheduler aims to identify threads which
-    monopolize the CPU, and will schedule them with decreased priority. Threads
-    which regularly yield the processor will be given the chance to run more
-    often. The possibly surprising effect of this is that, depending on the
-    disposition of other threads on the CPU's runqueue, a call to
-    ()
-    does not guarantee that the yielding thread will be taken off the CPU.

-
With the above considerations in mind, it is
-    advised that code written using
-    ()
-    be measured to confirm that its use has a positive effect on relevant
-    performance or responsiveness metrics. Switching thread contexts has a
-    non-zero cost, and thus yielding the processor too eagerly could have a
-    negative impact on performance.

-
Additionally, since yielding is a cooperative action, it is
-    advised that the yielding thread release any locks that it may be holding,
-    when possible. Otherwise, threads which have been given the chance to run
-    could end up waiting on the yielding thread to release the lock, largely
-    defeating the purpose of the yield.

-

-

-

-
setpriority(2), nice(3),
-    mi_switch(9)

-

-

-

-
This manual page was written by Mitchell
-    Horne
-    <mhorne@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 30, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/kernacc.9 4.html b/static/freebsd/man9/kernacc.9 4.html
deleted file mode 100644
index eb0269e2..00000000
--- a/static/freebsd/man9/kernacc.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
KERNACC(9)Kernel Developer's ManualKERNACC(9)

-

-

-

-
kernacc, useracc
-    — check memory regions for accessibility

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_extern.h>

-
int
-  

-  kernacc(void
-    *addr, int len,
-    int rw);

-
int
-  

-  useracc(void
-    *addr, int len,
-    int rw);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions check whether operations of the type specified in
-    rw are permitted in the range of virtual addresses
-    given by addr and len. The
-    possible values of rw are any bitwise combination of
-    VM_PROT_READ, VM_PROT_WRITE
-    and VM_PROT_EXECUTE.
-    kernacc() checks addresses in the kernel address
-    space, while useracc() considers
-    addr to represent an user space address. The process
-    context to use for this operation is taken from the global variable
-    curproc.

-

-

-

-
Both functions return boolean true if the type of access specified
-    by rw is permitted. Otherwise boolean false is
-    returned.

-

-

-

-
The process pointer should be passed in as an argument to
-    useracc().

-

-

-
-  
-    
-    
-  
-
June 16, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/kernel_mount.9 3.html b/static/freebsd/man9/kernel_mount.9 3.html
deleted file mode 100644
index 9e4c49e7..00000000
--- a/static/freebsd/man9/kernel_mount.9 3.html	
+++ /dev/null
@@ -1,160 +0,0 @@
-
-  
-    
-    
-    
-  
-
KERNEL_MOUNT(9)Kernel Developer's ManualKERNEL_MOUNT(9)

-

-

-

-
free_mntarg,
-    kernel_mount, mount_arg,
-    mount_argb, mount_argf,
-    mount_argsu — functions
-    provided as part of the kernel mount interface

-

-

-

-
void
-  

-  free_mntarg(struct
-    mntarg *ma);

-
int
-  

-  kernel_mount(struct
-    mntarg *ma, int
-    flags);

-
struct mntarg *
-  

-  mount_arg(struct mntarg *ma,
-    const char *name, const void
-    *val, int len);

-
struct mntarg *
-  

-  mount_argb(struct
-    mntarg *ma, int
-    flag, const char
-    *name);

-
struct mntarg *
-  

-  mount_argf(struct
-    mntarg *ma, const char
-    *name, const char
-    *fmt, ...);

-
struct mntarg *
-  

-  mount_argsu(struct mntarg *ma,
-    const char *name, const void
-    *val, int len);

-

-

-

-
The
-    ()
-    family of functions are provided as an API for building a list of mount
-    arguments which will be used to mount file systems from inside the kernel.
-    By accumulating a list of arguments, the API takes shape and provides the
-    information necessary for the kernel to control the
-    mount(8) utility. When an error occurs, the process will
-    stop. This will not cause a panic(9).

-
The header of the structure is stored in
-    src/sys/kern/vfs_mount.c which permits automatic
-    structure creation to ease the mount process. Memory allocation must always
-    be freed when the entire process is complete, it is an error otherwise.

-
The
-    ()
-    function is used to free or clear the mntarg
-    structure.

-
The
-    ()
-    function pulls information from the structure to perform the mount request
-    on a given file system. Additionally, the
-    kernel_mount() function always calls the
-    free_mntarg() function. If ma
-    contains any error code generated during the construction, that code will be
-    called and the file system mount will not be attempted.

-
The
-    ()
-    function takes a plain argument and crafts parts of the structure with
-    regards to various mount options. If the length is a value less than 0,
-    strlen(3) is used. This argument will be referenced until
-    either free_mntarg() or
-    kernel_mount() is called.

-
The
-    ()
-    function is used to add boolean arguments to the structure. The
-    flag is the boolean value and
-    name must start with
-    "no", otherwise a panic will occur.

-
The
-    ()
-    function adds printf(9) style arguments to the current
-    structure.

-
The
-    ()
-    function will add arguments to the structure from a userland string.

-

-

-

-
An example of the *_cmount() function:

-

-
static int
-msdosfs_cmount(struct mntarg *ma, void *data, int flags, struct thread *td)
-{
-	struct msdosfs_args args;
-	int error;
-
-	if (data == NULL)
-		return (EINVAL);
-	error = copyin(data, &args, sizeof(args));
-	if (error)
-		return (error);
-
-	ma = mount_argsu(ma, "from", args.fspec, MAXPATHLEN);
-	ma = mount_arg(ma, "export", &args.export, sizeof(args.export));
-	ma = mount_argf(ma, "uid", "%d", args.uid);
-	ma = mount_argf(ma, "gid", "%d", args.gid);
-	ma = mount_argf(ma, "mask", "%d", args.mask);
-	ma = mount_argf(ma, "dirmask", "%d", args.dirmask);
-
-	ma = mount_argb(ma, args.flags & MSDOSFSMNT_SHORTNAME, "noshortname");
-	ma = mount_argb(ma, args.flags & MSDOSFSMNT_LONGNAME, "nolongname");
-	ma = mount_argb(ma, !(args.flags & MSDOSFSMNT_NOWIN95), "nowin95");
-	ma = mount_argb(ma, args.flags & MSDOSFSMNT_KICONV, "nokiconv");
-
-	ma = mount_argsu(ma, "cs_win", args.cs_win, MAXCSLEN);
-	ma = mount_argsu(ma, "cs_dos", args.cs_dos, MAXCSLEN);
-	ma = mount_argsu(ma, "cs_local", args.cs_local, MAXCSLEN);
-
-	error = kernel_mount(ma, flags);
-
-	return (error);
-}

-

-

-

-

-
VFS(9), VFS_MOUNT(9)

-

-

-

-
The kernel_mount() family of functions and
-    this manual page first appeared in FreeBSD 6.0.

-

-

-

-
The kernel_mount() family of functions and
-    API was developed by Poul-Henning Kamp
-    <phk@FreeBSD.org>.
-    This manual page was written by Tom Rhodes
-    <trhodes@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 20, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/khelp.9 3.html b/static/freebsd/man9/khelp.9 3.html
deleted file mode 100644
index 1dd082c7..00000000
--- a/static/freebsd/man9/khelp.9 3.html	
+++ /dev/null
@@ -1,309 +0,0 @@
-
-  
-    
-    
-    
-  
-
KHELP(9)Kernel Developer's ManualKHELP(9)

-

-

-

-
khelp,
-    khelp_init_osd,
-    khelp_destroy_osd,
-    khelp_get_id, khelp_get_osd,
-    khelp_add_hhook,
-    khelp_remove_hhook,
-    KHELP_DECLARE_MOD,
-    KHELP_DECLARE_MOD_UMA —
-    Kernel Helper Framework

-

-

-

-
#include
-    <sys/khelp.h>
-  

-  #include
-  <sys/module_khelp.h>

-
int
-    khelp_init_osd(uint32_t
-    classes, struct osd
-    *hosd);

-
int
-    khelp_destroy_osd(struct
-    osd *hosd);

-
int32_t
-    khelp_get_id(char
-    *hname);

-
void *
-    khelp_get_osd(struct
-    osd *hosd, int32_t
-    id);

-
int
-    khelp_add_hhook(const
-    struct hookinfo *hki,
-    uint32_t flags);

-
int
-    khelp_remove_hhook(const
-    struct hookinfo *hki);

-
KHELP_DECLARE_MOD(hname,
-    hdata,
-    hhooks,
-    version);

-
KHELP_DECLARE_MOD_UMA(hname,
-    hdata,
-    hhooks,
-    version,
-    ctor,
-    dtor);

-

-

-

-
khelp provides a framework for managing
-    khelp modules, which indirectly use the
-    hhook(9) KPI to register their hook functions with hook
-    points of interest within the kernel. Khelp modules aim to provide a
-    structured way to dynamically extend the kernel at runtime in an ABI
-    preserving manner. Depending on the subsystem providing hook points, a
-    khelp module may be able to associate per-object
-    data for maintaining relevant state between hook calls. The
-    hhook(9) and khelp frameworks are
-    tightly integrated and anyone interested in khelp
-    should also read the hhook(9) manual page thoroughly.

-

-

-
khelp modules are represented within the
-    khelp framework by a struct
-    helper which has the following members:

-

-
struct helper {
-	int (*mod_init) (void);
-	int (*mod_destroy) (void);
-#define	HELPER_NAME_MAXLEN 16
-	char			h_name[HELPER_NAME_MAXLEN];
-	uma_zone_t		h_zone;
-	struct hookinfo		*h_hooks;
-	uint32_t		h_nhooks;
-	uint32_t		h_classes;
-	int32_t			h_id;
-	volatile uint32_t	h_refcount;
-	uint16_t		h_flags;
-	TAILQ_ENTRY(helper)	h_next;
-};

-

-
Modules must instantiate a struct helper,
-    but are only required to set the h_classes field, and
-    may optionally set the h_flags,
-    mod_init and mod_destroy fields
-    where required. The framework takes care of all other fields and modules
-    should refrain from manipulating them. Using the C99 designated initialiser
-    feature to set fields is encouraged.

-
If specified, the mod_init function will be
-    run by the khelp framework prior to completing the
-    registration process. Returning a non-zero value from the
-    mod_init function will abort the registration process
-    and fail to load the module. If specified, the
-    mod_destroy function will be run by the
-    khelp framework during the deregistration process,
-    after the module has been deregistered by the khelp
-    framework. The return value is currently ignored. Valid
-    khelp classes are defined in
-    <sys/khelp.h>. Valid flags
-    are defined in
-    <sys/module_khelp.h>. The
-    HELPER_NEEDS_OSD flag should be set in the h_flags
-    field if the khelp module requires persistent
-    per-object data storage. There is no programmatic way (yet) to check if a
-    khelp class provides the ability for
-    khelp modules to associate persistent per-object
-    data, so a manual check is required.

-
The
-    ()
-    and KHELP_DECLARE_MOD_UMA() macros provide
-    convenient wrappers around the DECLARE_MODULE(9) macro,
-    and are used to register a khelp module with the
-    khelp framework.
-    KHELP_DECLARE_MOD_UMA() should only be used by
-    modules which require the use of persistent per-object storage i.e. modules
-    which set the HELPER_NEEDS_OSD flag in their struct
-    helper's h_flags field.

-
The first four arguments common to both
-    macros are as follows. The hname argument specifies
-    the unique ascii(7) name for the
-    khelp module. It should be no longer than
-    HELPER_NAME_MAXLEN-1 characters in length. The hdata
-    argument is a pointer to the module's struct helper.
-    The hhooks argument points to a static array of
-    struct hookinfo structures. The array should contain a
-    struct hookinfo for each hhook(9)
-    point the module wishes to hook, even when using the same hook function
-    multiple times for different hhook(9) points. The
-    version argument specifies a version number for the
-    module which will be passed to MODULE_VERSION(9). The
-    ()
-    macro takes the additional ctor and
-    dtor arguments, which specify optional
-    uma(9) constructor and destructor functions. NULL should
-    be passed where the functionality is not required.

-
The
-    ()
-    function returns the numeric identifier for the
-    khelp module with name
-  hname.

-
The
-    ()
-    function is used to obtain the per-object data pointer for a specified
-    khelp module. The hosd
-    argument is a pointer to the underlying subsystem object's
-    struct osd. This is provided by the
-    hhook(9) framework when calling into a
-    khelp module's hook function. The
-    id argument specifies the numeric identifier for the
-    khelp module to extract the data pointer from
-    hosd for. The id is obtained
-    using the khelp_get_id() function.

-
The
-    ()
-    and
-    ()
-    functions allow a khelp module to dynamically
-    hook/unhook hhook(9) points at run time. The
-    hki argument specifies a pointer to a
-    struct hookinfo which encapsulates the required
-    information about the hhook(9) point and hook function
-    being manipulated. The HHOOK_WAITOK flag may be passed in via the
-    flags argument of
-    khelp_add_hhook() if malloc(9) is
-    allowed to sleep waiting for memory to become available.

-

-

-

-
Most of the work required to allow khelp
-    modules to do useful things relates to defining and instantiating suitable
-    hhook(9) points for khelp modules
-    to hook into. The only additional decision a subsystem needs to make is
-    whether it wants to allow khelp modules to associate
-    persistent per-object data. Providing support for persistent data storage
-    can allow khelp modules to perform more complex
-    functionality which may be desirable. Subsystems which want to allow Khelp
-    modules to associate persistent per-object data with one of the subsystem's
-    data structures need to make the following two key changes:

-
    
-  
  • Embed a struct osd pointer in the structure
-      definition for the object.
    • 
-  
  • Add calls to khelp_init_osd() and
-      khelp_destroy_osd() to the subsystem code paths
-      which are responsible for respectively initialising and destroying the
-      object.
    • 
-

-
The
-    ()
-    function initialises the per-object data storage for all currently loaded
-    khelp modules of appropriate classes which have set
-    the HELPER_NEEDS_OSD flag in their h_flags field. The
-    classes argument specifies a bitmask of
-    khelp classes which this subsystem associates with.
-    If a khelp module matches any of the classes in the
-    bitmask, that module will be associated with the object. The
-    hosd argument specifies the pointer to the object's
-    struct osd which will be used to provide the
-    persistent storage for use by khelp modules.

-
The
-    ()
-    function frees all memory that was associated with an object's
-    struct osd by a previous call to
-    khelp_init_osd(). The hosd
-    argument specifies the pointer to the object's struct
-    osd which will be purged in preparation for destruction.

-

-

-

-

-
khelp modules are protected from being
-    prematurely unloaded by a reference count. The count is incremented each
-    time a subsystem calls khelp_init_osd() causing
-    persistent storage to be allocated for the module, and decremented for each
-    corresponding call to khelp_destroy_osd(). Only when
-    a module's reference count has dropped to zero can the module be
-  unloaded.

-

-

-

-
The khelp_init_osd() function returns zero
-    if no errors occurred. It returns ENOMEM if a khelp
-    module which requires per-object storage fails to allocate the necessary
-    memory.

-
The khelp_destroy_osd() function only
-    returns zero to indicate that no errors occurred.

-
The khelp_get_id() function returns the
-    unique numeric identifier for the registered khelp
-    module with name hname. It return -1 if no module with
-    the specified name is currently registered.

-
The khelp_get_osd() function returns the
-    pointer to the khelp module's persistent object
-    storage memory. If the module identified by id does
-    not have persistent object storage registered with the object's
-    hosd struct osd, NULL is
-    returned.

-
The khelp_add_hhook() function returns
-    zero if no errors occurred. It returns ENOENT if it could not find the
-    requested hhook(9) point. It returns ENOMEM if
-    malloc(9) failed to allocate memory. It returns EEXIST if
-    attempting to register the same hook function more than once for the same
-    hhook(9) point.

-
The khelp_remove_hhook() function returns
-    zero if no errors occurred. It returns ENOENT if it could not find the
-    requested hhook(9) point.

-

-

-

-
A well commented example Khelp module can be found at:
-    /usr/share/examples/kld/khelp/h_example.c

-
The Enhanced Round Trip Time (ERTT) h_ertt(4)
-    khelp module provides a more complex example of what
-    is possible.

-

-

-

-
h_ertt(4), hhook(9),
-    osd(9)

-

-

-

-
Development and testing of this software were made possible in
-    part by grants from the FreeBSD Foundation and Cisco University Research
-    Program Fund at Community Foundation Silicon Valley.

-

-

-

-
The khelp kernel helper framework first
-    appeared in FreeBSD 9.0.

-
The khelp framework was first released in
-    2010 by Lawrence Stewart whilst studying at Swinburne University of
-    Technology's Centre for Advanced Internet Architectures, Melbourne,
-    Australia. More details are available at:

-
http://caia.swin.edu.au/urp/newtcp/

-

-

-

-
The khelp framework was written by
-    Lawrence Stewart
-    <lstewart@FreeBSD.org>.

-
This manual page was written by David
-    Hayes
-    <david.hayes@ieee.org>
-    and Lawrence Stewart
-    <lstewart@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 1, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/kmsan.9 3.html b/static/freebsd/man9/kmsan.9 3.html
deleted file mode 100644
index f90b3f3c..00000000
--- a/static/freebsd/man9/kmsan.9 3.html	
+++ /dev/null
@@ -1,314 +0,0 @@
-
-  
-    
-    
-    
-  
-
KMSAN(9)Kernel Developer's ManualKMSAN(9)

-

-

-

-
KMSAN — Kernel
-    Memory SANitizer

-

-

-

-
The GENERIC-KMSAN kernel configuration can
-    be used to compile a KMSAN-enabled kernel using
-    GENERIC as a base configuration. Alternately, to
-    compile KMSAN into the kernel, place the following line in your kernel
-    configuration file:

-
options KMSAN

-

-  

-  #include <sys/msan.h>

-
void
-  

-  kmsan_mark(const
-    void *addr, size_t
-    size, uint8_t
-    code);

-
void
-  

-  kmsan_orig(const
-    void *addr, size_t
-    size, int type,
-    uintptr_t pc);

-
void
-  

-  kmsan_check(const
-    void *addr, size_t
-    size, const char
-    *descr);

-
void
-  

-  kmsan_check_bio(const
-    struct bio *, const char
-    *descr);

-
void
-  

-  kmsan_check_ccb(const
-    union ccb *, const char
-    *descr);

-
void
-  

-  kmsan_check_mbuf(const
-    struct mbuf *, const char
-    *descr);

-
void
-  

-  kmsan_check_uio(const
-    struct uio *, const char
-    *descr);

-

-

-

-
KMSAN is a subsystem which leverages
-    compiler instrumentation to detect uses of uninitialized memory in the
-    kernel. Currently it is implemented only on the amd64 and arm64
-  platforms.

-
When KMSAN is compiled into
-    the kernel, the compiler is configured to emit function calls preceding
-    memory accesses. The functions are implemented by the
-    KMSAN runtime component and use hidden,
-    byte-granular shadow state to determine whether the source operand has been
-    initialized. When uninitialized memory is used as a source operand in
-    certain operations, such as control flow expressions or memory accesses, the
-    runtime reports an error. Otherwise, the shadow state is propagated to
-    destination operand. For example, a variable assignment or a
-    ()
-    call which copies uninitialized memory will cause the destination buffer or
-    variable to be marked uninitialized.

-
To report an error, the
-    KMSAN runtime will either trigger a kernel panic or
-    print a message to the console, depending on the value of the
-    
-    sysctl. In both cases, a stack trace and information about the origin of the
-    uninitialized memory is included.

-
In addition to compiler-detected uses of uninitialized memory,
-    various kernel I/O “exit points”, such as
-    copyout(9), perform validation of the input's shadow state
-    and will raise an error if any uninitialized bytes are detected.

-
The KMSAN option imposes a significant
-    performance penalty. Kernel code typically runs two or three times slower,
-    and each byte mapped in the kernel map requires two bytes of shadow state.
-    As a result, KMSAN should be used only for kernel
-    testing and development. It is not recommended to enable
-    KMSAN in systems with less than 8GB of physical
-  RAM.

-
The sanitizer in a KMSAN-configured
-    kernel can be disabled by setting the loader tunable
-    .

-

-

-

-
The
-    ()
-    and kmsan_orig() functions update
-    KMSAN shadow state.
-    kmsan_mark() marks an address range as valid or
-    invalid according to the value of the code parameter.
-    The valid values for this parameter are
-    KMSAN_STATE_INITED and
-    KMSAN_STATE_UNINIT, which mark the range as
-    initialized and uninitialized, respectively. For example, when a piece of
-    memory is freed to a kernel allocator, it will typically have been marked
-    initialized; before the memory is reused for a new allocation, the allocator
-    should mark it as uninitialized. As another example, writes to host memory
-    performed by devices, e.g., via DMA, are not intercepted by the sanitizer;
-    to avoid false positives, drivers should mark device-written memory as
-    initialized. For many drivers this is handled internally by the
-    busdma(9) subsystem.

-
The
-    ()
-    function updates “origin” shadow state. In particular, it
-    associates a given uninitialized buffer with a memory type and code address.
-    This is used by the KMSAN runtime to track the
-    source of uninitialized memory and is only for debugging purposes. See
-    IMPLEMENTATION NOTES for more
-    details.

-
The
-    ()
-    function and its sub-typed siblings validate the shadow state of the
-    region(s) of kernel memory passed as input parameters. If any byte of the
-    input is marked as uninitialized, the runtime will generate a report. These
-    functions are useful during debugging, as they can be strategically inserted
-    into code paths to narrow down the source of uninitialized memory. They are
-    also used to perform validation in various kernel I/O paths, helping ensure
-    that, for example, packets transmitted over a network do not contain
-    uninitialized kernel memory. kmsan_check() and
-    related functions also take a descr parameter which is
-    inserted into any reports raised by the check.

-

-

-

-

-

-
The KMSAN runtime makes use of two shadows
-    of the kernel map. Each address in the kernel map has a linear mapping to
-    addresses in the two shadows. The first, simply called the shadow map,
-    tracks the state of the corresponding kernel memory. A non-zero byte in the
-    shadow map indicates that the corresponding byte of kernel memory is
-    uninitialized. The KMSAN instrumentation
-    automatically propagates shadow state as the contents of kernel memory are
-    transformed and copied.

-
The second shadow is called the origin map, and exists only to
-    help debug reports from the sanitizer. To avoid false positives,
-    KMSAN does not raise reports for certain operations
-    on uninitialized memory, such as copying or arithmetic. Thus, operations on
-    uninitialized state which raise a report may be far removed from the source
-    of the bug, complicating debugging. The origin map contains information
-    which can help pinpoint the root cause of a particular
-    KMSAN report; when generating a report, the runtime
-    uses state from the origin map to provide extra details.

-
Unlike the shadow map, the origin map is not byte-granular, but
-    consists of 4-byte “cells”. Each cell describes the
-    corresponding four bytes of mapped kernel memory and holds a type and
-    compressed code address. When kernel memory is allocated for some purpose,
-    its origin is initialized either by the compiler instrumentation or by
-    runtime hooks in the allocator. The type indicates the specific allocator,
-    e.g., uma(9), and the address provides the location in the
-    kernel code where the memory was allocated.

-

-

-

-
When KMSAN is configured, the compiler
-    will only emit instrumentation for C code. Files containing assembly code
-    are left un-instrumented. In some cases this is handled by the sanitizer
-    runtime, which defines wrappers for subroutines implemented in assembly.
-    These wrappers are referred to as interceptors and handle updating shadow
-    state to reflect the operations performed by the original subroutines. In
-    other cases, C code which calls assembly code or is called from assembly
-    code may need to use kmsan_mark() to manually update
-    shadow state. This is typically only necessary in machine-dependent
-  code.

-
Inline assembly is instrumented by the compiler to update shadow
-    state based on the output operands of the code, and thus does not usually
-    require any special handling to avoid false positives.

-

-

-

-
In addition to the shadow maps, the sanitizer requires some
-    thread-local storage (TLS) to track initialization and origin state for
-    function parameters and return values. The sanitizer instrumentation will
-    automatically fetch, update and verify this state. In particular, this
-    storage block has a layout defined by the sanitizer ABI.

-
Most kernel code runs in a context where interrupts or exceptions
-    may redirect the CPU to begin execution of unrelated code. To ensure that
-    thread-local sanitizer state remains consistent, the runtime maintains a
-    stack of TLS blocks for each thread. When machine-dependent interrupt and
-    exception handlers begin execution, they push a new entry onto the stack
-    before calling into any C code, and pop the stack before resuming execution
-    of the interrupted code. These operations are performed by the
-    kmsan_intr_enter() and
-    kmsan_intr_leave() functions in the sanitizer
-    runtime.

-

-

-

-

-
The following contrived example demonstrates some of the types of
-    bugs that are automatically detected by KMSAN:

-

-
int
-f(size_t osz)
-{
-	struct {
-		uint32_t bar;
-		uint16_t baz;
-		/* A 2-byte hole is here. */
-	} foo;
-	char *buf;
-	size_t sz;
-	int error;
-
-	/*
-	 * This will raise a report since "sz" is uninitialized
-	 * here.  If it is initialized, and "osz" was left uninitialized
-	 * by the caller, a report would also be raised.
-	 */
-	if (sz < osz)
-		return (1);
-
-	buf = malloc(32, M_TEMP, M_WAITOK);
-
-	/*
-	 * This will raise a report since "buf" has not been
-	 * initialized and contains whatever data is left over from the
-	 * previous use of that memory.
-	 */
-	for (i = 0; i < 32; i++)
-		if (buf[i] != ' ')
-			foo.bar++;
-	foo.baz = 0;
-
-	/*
-	 * This will raise a report since the pad bytes in "foo" have
-	 * not been initialized, e.g., by memset(), and this call will
-	 * thus copy uninitialized kernel stack memory into userspace.
-	 */
-	copyout(&foo, uaddr, sizeof(foo));
-
-	/*
-	 * This line itself will not raise a report, but may trigger
-	 * a report in the caller depending on how the return value is
-	 * used.
-	 */
-	return (error);
-}

-

-

-

-

-
build(7), busdma(9),
-    copyout(9), KASAN(9),
-    uio(9), uma(9)

-
Evgeniy Stepanov and
-    Konstantin Serebryany,
-    MemorySanitizer: fast detector of uninitialized memory use
-    in C++, 2015 IEEE/ACM International Symposium on Code
-    Generation and Optimization (CGO),
-  2015.

-

-

-

-
KMSAN was ported from
-    NetBSD and first appeared in
-    FreeBSD 14.0.

-

-

-

-
Accesses to kernel memory outside of the kernel map are ignored by
-    the KMSAN runtime. In particular, memory accesses
-    via the direct map are not validated. When memory is copied from outside the
-    kernel map into the kernel map, that region of the kernel map is marked as
-    initialized. When KMSAN is configured, kernel memory
-    allocators are configured to use the kernel map, and filesystems are
-    configured to always map data buffers into the kernel map, so usage of the
-    direct map is minimized. However, some uses of the direct map remain. This
-    is a conservative policy which aims to avoid false positives, but it will
-    mask bug in some kernel subsystems.

-
On amd64, global variables and the physical page array
-    vm_page_array are not sanitized. This is intentional,
-    as it reduces memory usage by avoiding creating shadows of large regions of
-    the kernel map. However, this can allow bugs to go undetected by
-    KMSAN.

-
Some kernel memory allocators provide type-stable objects, and
-    code which uses them frequently depends on object data being preserved
-    across allocations. Such allocations cannot be sanitized by
-    KMSAN. However, in some cases it may be possible to
-    use kmsan_mark() to manually annotate fields which
-    are known to contain invalid data upon allocation.

-

-

-
-  
-    
-    
-  
-
January 11, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/kobj.9 3.html b/static/freebsd/man9/kobj.9 3.html
deleted file mode 100644
index 42459e96..00000000
--- a/static/freebsd/man9/kobj.9 3.html	
+++ /dev/null
@@ -1,142 +0,0 @@
-
-  
-    
-    
-    
-  
-
KOBJ(9)Kernel Developer's ManualKOBJ(9)

-

-

-

-
kobj — a kernel
-    object system for FreeBSD

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kobj.h>

-
void
-  

-  kobj_class_compile(kobj_class_t
-    cls);

-
void
-  

-  kobj_class_compile_static(kobj_class_t
-    cls, kobj_ops_t
-    ops);

-
void
-  

-  kobj_class_free(kobj_class_t
-    cls);

-
kobj_t
-  

-  kobj_create(kobj_class_t
-    cls, struct malloc_type
-    *mtype, int
-    mflags);

-
void
-  

-  kobj_init(kobj_t
-    obj, kobj_class_t
-    cls);

-
void
-  

-  kobj_init_static(kobj_t
-    obj, kobj_class_t
-    cls);

-
void
-  

-  kobj_delete(kobj_t
-    obj, struct malloc_type
-    *mtype);

-
DEFINE_CLASS(name,
-    kobj_method_t *methods,
-    size_t size);

-

-

-

-
The kernel object system implements an object-oriented programming
-    system in the FreeBSD kernel. The system is based
-    around the concepts of interfaces, which are descriptions of sets of
-    methods; classes, which are lists of functions implementing certain methods
-    from those interfaces; and objects, which combine a class with a structure
-    in memory.

-
Methods are called using a dynamic method dispatching algorithm
-    which is designed to allow new interfaces and classes to be introduced into
-    the system at runtime. The method dispatch algorithm is designed to be both
-    fast and robust and is only slightly more expensive than a direct function
-    call, making kernel objects suitable for performance-critical
-  algorithms.

-
Suitable uses for kernel objects are any algorithms which need
-    some kind of polymorphism (i.e., many different objects which can be treated
-    in a uniform way). The common behaviour of the objects is described by a
-    suitable interface and each different type of object is implemented by a
-    suitable class.

-
The simplest way to create a kernel object is to
-    call
-    ()
-    with a suitable class, malloc type and flags (see
-    malloc(9) for a description of the malloc type and flags).
-    This will allocate memory for the object based on the object size specified
-    by the class and initialise it by zeroing the memory and installing a
-    pointer to the class' method dispatch table. Objects created in this way
-    should be freed by calling
-    ().

-
Clients which would like to manage the allocation
-    of memory themselves should call
-    ()
-    or
-    ()
-    with a pointer to the memory for the object and the class which implements
-    it. It is also possible to use kobj_init() and
-    kobj_init_static() to change the class for an
-    object. This should be done with care as the classes must agree on the
-    layout of the object. The device framework uses this feature to associate
-    drivers with devices.

-
The functions
-    (),
-    ()
-    and
-    ()
-    are used to process a class description to make method dispatching
-    efficient. A client should not normally need to call these since a class
-    will automatically be compiled the first time it is used. If a class is to
-    be used before malloc(9) and mutex(9)
-    are initialised, then kobj_class_compile_static()
-    should be called with the class and a pointer to a statically allocated
-    kobj_ops structure before the class is used to
-    initialise any objects. In that case, also
-    kobj_init_static() should be used instead of
-    kobj_init().

-
To define a class, first define a simple array of
-    kobj_method_t. Each method which the class implements
-    should be entered into the table using the macro
-    ()
-    which takes the name of the method (including its interface) and a pointer
-    to a function which implements it. The table should be terminated with two
-    zeros. The macro
-    ()
-    can then be used to initialise a kobj_class_t
-    structure. The size argument to DEFINE_CLASS()
-    specifies how much memory should be allocated for each object.

-

-

-

-
Some of the concepts for this interface appeared in the device
-    framework used for the alpha port of FreeBSD 3.0 and
-    more widely in FreeBSD 4.0.

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
November 14, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/kproc.9 3.html b/static/freebsd/man9/kproc.9 3.html
deleted file mode 100644
index 90e3b0c3..00000000
--- a/static/freebsd/man9/kproc.9 3.html	
+++ /dev/null
@@ -1,294 +0,0 @@
-
-  
-    
-    
-    
-  
-
KPROC(9)Kernel Developer's ManualKPROC(9)

-

-

-

-
kproc_start,
-    kproc_shutdown,
-    kproc_create, kproc_exit,
-    kproc_resume, kproc_suspend,
-    kproc_suspend_check — kernel
-    processes

-

-

-

-
#include
-    <sys/kthread.h>

-
void
-  

-  kproc_start(const
-    void *udata);

-
void
-  

-  kproc_shutdown(void
-    *arg, int
-  howto);

-
int
-  

-  kproc_create(void (*func)(void
-    *), void *arg, struct proc
-    **newpp, int flags, int
-    pages, const char *fmt,
-    ...);

-
void
-  

-  kproc_exit(int
-    ecode);

-
int
-  

-  kproc_resume(struct
-    proc *p);

-
int
-  

-  kproc_suspend(struct
-    proc *p, int
-  timo);

-
void
-  

-  kproc_suspend_check(struct
-    proc *p);

-
int
-  

-  kproc_kthread_add(void (*func)(void
-    *), void *arg, struct proc
-    **procptr, struct thread **tdptr,
-    int flags, int pages,
-    char * procname, const char
-    *fmt, ...);

-

-

-

-
In FreeBSD 8.0, the
-    (9)
-    family of functions was renamed to be the
-    (9)
-    family of functions, as they were misnamed and actually produced kernel
-    processes. A new family of
-    
-    (9)
-    functions was added to produce
-    
-    kernel
-    .
-    See the kthread(9) man page for more information on those
-    calls. Also note that the
-    kproc_kthread_add(9) function
-    appears in both pages as its functionality is split.

-
The function
-    ()
-    is used to start “internal” daemons such as
-    bufdaemon, pagedaemon,
-    vmdaemon, and the syncer and
-    is intended to be called from SYSINIT(9). The
-    udata argument is actually a pointer to a
-    struct kproc_desc which describes the kernel process
-    that should be created:

-

-
struct kproc_desc {
-	char		*arg0;
-	void		(*func)(void);
-	struct proc	**global_procpp;
-};

-

-
The structure members are used by
-    ()
-    as follows:

-

-

-  
arg0

-  
String to be used for the name of the process. This string will be copied
-      into the p_comm member of the new process'
-      struct proc.

-  
func

-  
The main function for this kernel process to run.

-  
global_procpp

-  
A pointer to a struct proc pointer that should be
-      updated to point to the newly created process' process structure. If this
-      variable is NULL, then it is ignored.

-

-

-
The
-    ()
-    function is used to create a kernel process. The new process shares its
-    address space with process 0, the swapper process,
-    and runs in kernel mode only. The func argument
-    specifies the function that the process should execute. The
-    arg argument is an arbitrary pointer that is passed in
-    as the only argument to func when it is called by the
-    new process. The newpp pointer points to a
-    struct proc pointer that is to be updated to point to
-    the newly created process. If this argument is NULL,
-    then it is ignored. The flags argument specifies a set
-    of flags as described in rfork(2). The
-    pages argument specifies the size of the new kernel
-    process's stack in pages. If 0 is used, the default kernel stack size is
-    allocated. The rest of the arguments form a printf(9)
-    argument list that is used to build the name of the new process and is
-    stored in the p_comm member of the new process's
-    struct proc.

-
The
-    ()
-    function is used to terminate kernel processes. It should be called by the
-    main function of the kernel process rather than letting the main function
-    return to its caller. The ecode argument specifies the
-    exit status of the process. While exiting, the function
-    exit1(9) will initiate a call to
-    wakeup(9) on the process handle.

-
The
-    (),
-    (),
-    and
-    ()
-    functions are used to suspend and resume a kernel process. During the main
-    loop of its execution, a kernel process that wishes to allow itself to be
-    suspended should call kproc_suspend_check() passing
-    in curproc as the only argument. This function checks
-    to see if the kernel process has been asked to suspend. If it has, it will
-    tsleep(9) until it is told to resume. Once it has been
-    told to resume it will return allowing execution of the kernel process to
-    continue. The other two functions are used to notify a kernel process of a
-    suspend or resume request. The p argument points to
-    the struct proc of the kernel process to suspend or
-    resume. For kproc_suspend(), the
-    timo argument specifies a timeout to wait for the
-    kernel process to acknowledge the suspend request and suspend itself.

-
The
-    ()
-    function is meant to be registered as a shutdown event for kernel processes
-    that need to be suspended voluntarily during system shutdown so as not to
-    interfere with system shutdown activities. The actual suspension of the
-    kernel process is done with
-    ().

-
The
-    ()
-    function is much like the kproc_create() function
-    above except that if the kproc already exists, then only a new thread (see
-    kthread(9)) is created on the existing process. The
-    func argument specifies the function that the process
-    should execute. The arg argument is an arbitrary
-    pointer that is passed in as the only argument to func
-    when it is called by the new process. The procptr
-    pointer points to a struct proc pointer that is the
-    location to be updated with the new proc pointer if a new process is
-    created, or if not NULL, must contain the process
-    pointer for the already existing process. If this argument points to
-    NULL, then a new process is created and the field
-    updated. If not NULL, the tdptr pointer points to a
-    struct thread pointer that is the location to be
-    updated with the new thread pointer. The flags
-    argument specifies a set of flags as described in
-    rfork(2). The pages argument
-    specifies the size of the new kernel thread's stack in pages. If 0 is used,
-    the default kernel stack size is allocated. The procname argument is the
-    name the new process should be given if it needs to be created. It is
-     a printf
-    style format specifier but a simple string. The rest of the arguments form a
-    printf(9) argument list that is used to build the name of
-    the new thread and is stored in the td_name member of
-    the new thread's struct thread.

-

-

-

-
The kproc_create(),
-    kproc_resume(), and
-    kproc_suspend() functions return zero on success and
-    non-zero on failure.

-

-

-

-
This example demonstrates the use of a struct
-    kproc_desc and the functions kproc_start(),
-    kproc_shutdown(), and
-    kproc_suspend_check() to run the
-    bufdaemon process.

-

-
static struct proc *bufdaemonproc;
-
-static struct kproc_desc buf_kp = {
-	"bufdaemon",
-	buf_daemon,
-	&bufdaemonproc
-};
-SYSINIT(bufdaemon, SI_SUB_KTHREAD_BUF, SI_ORDER_FIRST, kproc_start,
-    &buf_kp)
-
-static void
-buf_daemon()
-{
-	...
-	/*
-	 * This process needs to be suspended prior to shutdown sync.
-	 */
-	EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown,
-	    bufdaemonproc, SHUTDOWN_PRI_LAST);
-	...
-	for (;;) {
-		kproc_suspend_check(bufdaemonproc);
-		...
-	}
-}

-

-

-

-

-
The kproc_resume() and
-    kproc_suspend() functions will fail if:

-

-  
[]

-  
The p argument does not reference a kernel
-    process.

-

-
The kproc_create() function will fail
-  if:

-

-  
[]

-  
The system-imposed limit on the total number of processes under execution
-      would be exceeded. The limit is given by the sysctl(3)
-      MIB variable KERN_MAXPROC.

-  
[]

-  
The RFCFDG flag was specified in the
-      flags parameter.

-

-

-

-

-
rfork(2), exit1(9),
-    kthread(9), SYSINIT(9),
-    wakeup(9)

-

-

-

-
The kproc_start() function first appeared
-    in FreeBSD 2.2. The
-    kproc_shutdown(),
-    kproc_create(),
-    kproc_exit(),
-    kproc_resume(),
-    kproc_suspend(), and
-    kproc_suspend_check() functions were introduced in
-    FreeBSD 4.0. Prior to FreeBSD
-    5.0, the kproc_shutdown(),
-    kproc_resume(),
-    kproc_suspend(), and
-    kproc_suspend_check() functions were named
-    shutdown_kproc(),
-    resume_kproc(),
-    shutdown_kproc(), and
-    kproc_suspend_loop(), respectively. Originally they
-    had the names kthread_*() but were changed to
-    kproc_*() when real kthreads became available.

-

-

-
-  
-    
-    
-  
-
October 19, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/kqueue.9 4.html b/static/freebsd/man9/kqueue.9 4.html
deleted file mode 100644
index 827536ea..00000000
--- a/static/freebsd/man9/kqueue.9 4.html	
+++ /dev/null
@@ -1,299 +0,0 @@
-
-  
-    
-    
-    
-  
-
KQUEUE(9)Kernel Developer's ManualKQUEUE(9)

-

-

-

-
kqueue_add_filteropts,
-    kqueue_del_filteropts,
-    kqfd_register,
-    knote_fdclose, knlist_init,
-    knlist_init_mtx, knlist_add,
-    knlist_remove, knlist_empty,
-    knlist_clear, knlist_delete,
-    knlist_destroy,
-    KNOTE_LOCKED, KNOTE_UNLOCKED
-    — event delivery subsystem

-

-

-

-
#include
-    <sys/event.h>

-
int
-  

-  kqueue_add_filteropts(int
-    filt, struct filterops
-    *filtops);

-
int
-  

-  kqueue_del_filteropts(int
-    filt);

-
int
-  

-  kqfd_register(int
-    fd, struct kevent
-    *kev, struct thread
-    *td, int
-  waitok);

-
void
-  

-  knote_fdclose(struct
-    thread *td, int
-    fd);

-
void
-  

-  knlist_init(struct knlist *knl,
-    void *lock, void (*kl_lock)(void
-    *), void (*kl_unlock)(void *),
-    int (*kl_locked)(void *));

-
void
-  

-  knlist_init_mtx(struct
-    knlist *knl, struct mtx
-    *lock);

-
void
-  

-  knlist_add(struct
-    knlist *knl, struct knote
-    *kn, int
-  islocked);

-
void
-  

-  knlist_remove(struct
-    knlist *knl, struct knote
-    *kn, int
-  islocked);

-
int
-  

-  knlist_empty(struct
-    knlist *knl);

-
void
-  

-  knlist_clear(struct
-    knlist *knl, int
-    islocked);

-
void
-  

-  knlist_delete(struct
-    knlist *knl, struct
-    thread *td, int
-    islocked);

-
void
-  

-  knlist_destroy(struct
-    knlist *knl);

-
void
-  

-  KNOTE_LOCKED(struct
-    knlist *knl, long
-    hint);

-
void
-  

-  KNOTE_UNLOCKED(struct
-    knlist *knl, long
-    hint);

-

-

-

-
The functions
-    ()
-    and
-    ()
-    allow for the addition and removal of a filter type. The filter is
-    statically defined by the EVFILT_* macros. The
-    function kqueue_add_filteropts() will make
-    filt available. The struct
-    filterops has the following members:

-

-  
f_isfd

-  
If f_isfd is set, ident in
-      struct kevent is taken to be a file descriptor. In
-      this case, the knote passed into
-      f_attach will have the kn_fp
-      member initialized to the struct file * that
-      represents the file descriptor.

-  
f_attach

-  
The f_attach function will be called when attaching
-      a knote to the object. The method should call
-      ()
-      to add the knote to the list that was initialized
-      with knlist_init(). The call to
-      knlist_add() is only necessary if the object can
-      have multiple knotes associated with it. If there is
-      no knlist to call
-      knlist_add() with, the function
-      f_attach must clear the
-      KN_DETACHED bit of kn_status
-      in the knote. The function shall return 0 on
-      success, or appropriate error for the failure, such as when the object is
-      being destroyed, or does not exist. During f_attach,
-      it is valid to change the kn_fop pointer to a
-      different pointer. This will change the f_event and
-      f_detach functions called when processing the
-      knote.

-  
f_detach

-  
The f_detach function will be called to detach the
-      knote if the knote has not
-      already been detached by a call to
-      ()
-      or knlist_delete(). The list
-      lock will not be held when this function is
-    called.

-  
f_event

-  
The f_event function will be called to update the
-      status of the knote. If the function returns 0, it
-      will be assumed that the object is not ready (or no longer ready) to be
-      woken up. The hint argument will be 0 when scanning
-      knotes to see which are triggered. Otherwise, the
-      hint argument will be the value passed to either
-      KNOTE_LOCKED or
-      KNOTE_UNLOCKED. The kn_data
-      value should be updated as necessary to reflect the current value, such as
-      number of bytes available for reading, or buffer space available for
-      writing.
-    
Locks
-         be
-        acquired in f_event. If a lock is required in
-        f_event, it must be obtained in the
-        kl_lock function of the
-        knlist that the knote was
-        added to.

-  

-  
f_copy

-  
The f_copy function is called to copy notes when the
-      process forks. When NULL, the current node is not
-      duplicated to the child process. Filter might set
-      f_copy to
-      ()
-      if there is no additional handling required, besides shallow copying of
-      the knote itself.

-

-
The function
-    ()
-    will register the kevent on the kqueue file descriptor
-    fd. If it is safe to sleep,
-    waitok should be set.

-
The function
-    ()
-    is used to delete all knotes associated with
-    fd. Once returned, there will no longer be any
-    knotes associated with the fd.
-    The knotes removed will never be returned from a
-    kevent(2) call, so if userland uses the
-    knote to track resources, they will be leaked. The
-    ()
-    lock must be held over the call to knote_fdclose()
-    so that file descriptors cannot be added or removed.

-
The
-    ()
-    family of functions are for managing knotes associated
-    with an object. A knlist is not required, but is
-    commonly used. If used, the knlist must be initialized
-    with either knlist_init() or
-    knlist_init_mtx(). The knlist
-    structure may be embedded into the object structure. The
-    lock will be held over f_event
-    calls.

-
For the
-    ()
-    function, if lock is NULL, a
-    shared global lock will be used and the remaining arguments must be
-    NULL. The function pointers
-    kl_lock, kl_unlock and
-    kl_locked will be used to manipulate the argument
-    lock. If any of the function pointers are
-    NULL, a function operating on
-    MTX_DEF style mutex(9) locks will
-    be used instead.

-
The function
-    ()
-    may be used to initialize a knlist when
-    lock is a MTX_DEF style
-    mutex(9) lock.

-
The function
-    ()
-    returns true when there are no knotes on the list. The
-    function requires that the lock be held when
-  called.

-
The function
-    ()
-    removes all knotes from the list. The
-    islocked argument declares if the
-    lock has been acquired. All
-    knotes will have EV_ONESHOT
-    set so that the knote will be returned and removed
-    during the next scan. The f_detach function will be
-    called when the knote is deleted during the next
-  scan.

-
The function
-    ()
-    removes and deletes all knotes on the list. The
-    function f_detach will not be called, and the
-    knote will not be returned on the next scan. Using
-    this function could leak userland resources if a process uses the
-    knote to track resources.

-
Both the
-    ()
-    and knlist_delete() functions may sleep. They also
-    may release the lock to wait for other
-    knotes to drain.

-
The
-    ()
-    function is used to destroy a knlist. There must be no
-    knotes associated with the
-    knlist (knlist_empty() returns
-    true) and no more knotes may be attached to the
-    object. A knlist may be emptied by calling
-    knlist_clear() or
-    knlist_delete().

-
The macros
-    ()
-    and
-    ()
-    are used to notify knotes about events associated with
-    the object. It will iterate over all knotes on the
-    list calling the f_event function associated with the
-    knote. The macro
-    KNOTE_LOCKED() must be used if the lock associated
-    with the knl is held. The function
-    KNOTE_UNLOCKED() will acquire the lock before
-    iterating over the list of knotes.

-

-

-

-
The function kqueue_add_filteropts() will
-    return zero on success, EINVAL in the case of an
-    invalid filt, or EEXIST if the
-    filter has already been installed.

-
The function kqueue_del_filteropts() will
-    return zero on success, EINVAL in the case of an
-    invalid filt, or EBUSY if the
-    filter is still in use.

-
The function kqfd_register() will return
-    zero on success, EBADF if the file descriptor is not
-    a kqueue, or any of the possible values returned by
-    kevent(2).

-

-

-

-
kevent(2), kqueue(2)

-

-

-

-
This manual page was written by John-Mark
-    Gurney
-    <jmg@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 2, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/kstack_contains.9 4.html b/static/freebsd/man9/kstack_contains.9 4.html
deleted file mode 100644
index 4c5acd20..00000000
--- a/static/freebsd/man9/kstack_contains.9 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
KSTACK_CONTAINS(9)Kernel Developer's ManualKSTACK_CONTAINS(9)

-

-

-

-
kstack_contains —
-    determine if an address range lies within the kernel stack
-    for a thread

-

-

-

-
#include
-    <machine/stack.h>

-
bool
-  

-  kstack_contains(struct
-    thread *td, vm_offset_t
-    va, size_t
-  len);

-

-

-

-
This function can be used to determine whether a given address
-    range falls within the kernel stack for the thread pointed to by
-    td.

-

-

-

-
The function kstack_contains() returns
-    true if the range of addresses
-    [va..(va+len-1)]
-    (both addresses inclusive) lies within the kernel stack for the thread
-    pointed to by argument td, or returns
-    false otherwise.

-

-

-

-
This function does not return an error.

-

-

-

-
kproc(9), kthread(9)

-

-

-
-  
-    
-    
-  
-
May 2, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/kthread.9 3.html b/static/freebsd/man9/kthread.9 3.html
deleted file mode 100644
index 01aa3362..00000000
--- a/static/freebsd/man9/kthread.9 3.html	
+++ /dev/null
@@ -1,271 +0,0 @@
-
-  
-    
-    
-    
-  
-
KTHREAD(9)Kernel Developer's ManualKTHREAD(9)

-

-

-

-
kthread_start,
-    kthread_shutdown,
-    kthread_add, kthread_exit,
-    kthread_resume,
-    kthread_suspend,
-    kthread_suspend_check —
-    kernel threads

-

-

-

-
#include
-    <sys/kthread.h>

-
void
-  

-  kthread_start(const
-    void *udata);

-
void
-  

-  kthread_shutdown(void
-    *arg, int
-  howto);

-
void
-  

-  kthread_exit(void);

-
int
-  

-  kthread_resume(struct
-    thread *td);

-
int
-  

-  kthread_suspend(struct
-    thread *td, int
-    timo);

-
void
-  

-  kthread_suspend_check(void);

-
#include
-    <sys/unistd.h>

-
int
-  

-  kthread_add(void (*func)(void
-    *), void *arg, struct proc
-    *procp, struct thread **newtdpp,
-    int flags, int pages,
-    const char *fmt, ...);

-
int
-  

-  kproc_kthread_add(void (*func)(void
-    *), void *arg, struct proc
-    **procptr, struct thread **tdptr,
-    int flags, int pages,
-    char * procname, const char
-    *fmt, ...);

-

-

-

-
In FreeBSD 8.0, the older family of
-    (9)
-    functions was renamed to be the
-    (9)
-    family of functions, as they were previously misnamed and actually produced
-    kernel processes. This new family of
-    kthread_*(9) functions was
-    added to produce
-    
-    kernel threads. See the kproc(9) man page for more
-    information on the renamed calls. Also note that the
-    kproc_kthread_add(9) function
-    appears in both pages as its functionality is split.

-
The function
-    ()
-    is used to start “internal” daemons such as
-    bufdaemon, pagedaemon,
-    vmdaemon, and the syncer and
-    is intended to be called from SYSINIT(9). The
-    udata argument is actually a pointer to a
-    struct kthread_desc which describes the kernel thread
-    that should be created:

-

-
struct kthread_desc {
-	char		*arg0;
-	void		(*func)(void);
-	struct thread	**global_threadpp;
-};

-

-
The structure members are used by
-    ()
-    as follows:

-

-

-  
arg0

-  
String to be used for the name of the thread. This string will be copied
-      into the td_name member of the new threads'
-      struct thread.

-  
func

-  
The main function for this kernel thread to run.

-  
global_threadpp

-  
A pointer to a struct thread pointer that should be
-      updated to point to the newly created thread's
-      thread structure. If this variable is
-      NULL, then it is ignored. The thread will be a
-      subthread of proc0 (PID 0).

-

-

-
The
-    ()
-    function is used to create a kernel thread. The new thread runs in kernel
-    mode only. It is added to the process specified by the
-    procp argument, or if that is
-    NULL, to proc0. The
-    func argument specifies the function that the thread
-    should execute. The arg argument is an arbitrary
-    pointer that is passed in as the only argument to func
-    when it is called by the new thread. The newtdpp
-    pointer points to a struct thread pointer that is to
-    be updated to point to the newly created thread. If this argument is
-    NULL, then it is ignored. The
-    flags argument may be set to
-    RFSTOPPED to leave the thread in a stopped state.
-    The caller must call
-    ()
-    to start the thread. The pages argument specifies the
-    size of the new kernel thread's stack in pages. If 0 is used, the default
-    kernel stack size is allocated. The rest of the arguments form a
-    printf(9) argument list that is used to build the name of
-    the new thread and is stored in the td_name member of
-    the new thread's struct thread.

-
The
-    ()
-    function is much like the kthread_add() function
-    above except that if the kproc does not already exist, it is created. This
-    function is better documented in the kproc(9) manual
-  page.

-
The
-    ()
-    function is used to terminate kernel threads. It should be called by the
-    main function of the kernel thread rather than letting the main function
-    return to its caller.

-
The
-    (),
-    (),
-    and
-    ()
-    functions are used to suspend and resume a kernel thread. During the main
-    loop of its execution, a kernel thread that wishes to allow itself to be
-    suspended should call kthread_suspend_check() in
-    order to check if the it has been asked to suspend. If it has, it will
-    msleep(9) until it is told to resume. Once it has been
-    told to resume it will return allowing execution of the kernel thread to
-    continue. The other two functions are used to notify a kernel thread of a
-    suspend or resume request. The td argument points to
-    the struct thread of the kernel thread to suspend or
-    resume. For kthread_suspend(), the
-    timo argument specifies a timeout to wait for the
-    kernel thread to acknowledge the suspend request and suspend itself.

-
The
-    ()
-    function is meant to be registered as a shutdown event for kernel threads
-    that need to be suspended voluntarily during system shutdown so as not to
-    interfere with system shutdown activities. The actual suspension of the
-    kernel thread is done with
-    ().

-

-

-

-
The kthread_add(),
-    kthread_resume(), and
-    kthread_suspend() functions return zero on success
-    and non-zero on failure.

-

-

-

-
This example demonstrates the use of a struct
-    kthread_desc and the functions
-    kthread_start(),
-    kthread_shutdown(), and
-    kthread_suspend_check() to run the
-    bufdaemon process.

-

-
static struct thread *bufdaemonthread;
-
-static struct kthread_desc buf_kp = {
-	"bufdaemon",
-	buf_daemon,
-	&bufdaemonthread
-};
-SYSINIT(bufdaemon, SI_SUB_KTHREAD_BUF, SI_ORDER_FIRST, kthread_start,
-    &buf_kp)
-
-static void
-buf_daemon()
-{
-	...
-	/*
-	 * This process needs to be suspended prior to shutdown sync.
-	 */
-	EVENTHANDLER_REGISTER(shutdown_pre_sync, kthread_shutdown,
-	    bufdaemonthread, SHUTDOWN_PRI_LAST);
-	...
-	for (;;) {
-		kthread_suspend_check();
-		...
-	}
-}

-

-

-

-

-
The kthread_resume() and
-    kthread_suspend() functions will fail if:

-

-  
[]

-  
The td argument does not reference a kernel
-    thread.

-

-
The kthread_add() function will fail
-  if:

-

-  
[]

-  
Memory for a thread's stack could not be allocated.

-

-

-

-

-
kproc(9), SYSINIT(9),
-    wakeup(9)

-

-

-

-
The kthread_start() function first
-    appeared in FreeBSD 2.2 where it created a whole
-    process. It was converted to create threads in FreeBSD
-    8.0. The kthread_shutdown(),
-    kthread_exit(),
-    kthread_resume(),
-    kthread_suspend(), and
-    kthread_suspend_check() functions were introduced in
-    FreeBSD 4.0 and were converted to threads in
-    FreeBSD 8.0. The
-    kthread_create() call was renamed to
-    kthread_add() in FreeBSD
-    8.0. The old functionality of creating a kernel process was renamed
-    to kproc_create(9). Prior to FreeBSD
-    5.0, the kthread_shutdown(),
-    kthread_resume(),
-    kthread_suspend(), and
-    kthread_suspend_check() functions were named
-    shutdown_kproc(),
-    resume_kproc(),
-    shutdown_kproc(), and
-    kproc_suspend_loop(), respectively.

-

-

-
-  
-    
-    
-  
-
July 15, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/ktr.9 4.html b/static/freebsd/man9/ktr.9 4.html
deleted file mode 100644
index 1863f4fd..00000000
--- a/static/freebsd/man9/ktr.9 4.html	
+++ /dev/null
@@ -1,182 +0,0 @@
-
-  
-    
-    
-    
-  
-
KTR(9)Kernel Developer's ManualKTR(9)

-

-

-

-
CTR0, CTR1,
-    CTR2, CTR3,
-    CTR4, CTR5 —
-    kernel tracing facility

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/ktr.h>

-
extern int ktr_cpumask;
-  

-  extern int ktr_entries;
-  

-  extern int ktr_extend;
-  

-  extern int ktr_mask;
-  

-  extern int ktr_verbose;
-  

-  extern struct ktr_entry ktr_buf[];

-
void
-  

-  CTR(u_int
-    mask, char *format,
-    ...);

-
void
-  

-  CTR0(u_int
-    mask, char
-    *format);

-
void
-  

-  CTR1(u_int
-    mask, char *format,
-    arg1);

-
void
-  

-  CTR2(u_int
-    mask, char *format,
-    arg1,
-    arg2);

-
void
-  

-  CTR3(u_int
-    mask, char *format,
-    arg1,
-    arg2,
-    arg3);

-
void
-  

-  CTR4(u_int
-    mask, char *format,
-    arg1,
-    arg2,
-    arg3,
-    arg4);

-
void
-  

-  CTR5(u_int
-    mask, char *format,
-    arg1,
-    arg2,
-    arg3,
-    arg4,
-    arg5);

-
void
-  

-  CTR6(u_int
-    mask, char *format,
-    arg1,
-    arg2,
-    arg3,
-    arg4,
-    arg5,
-    arg6);

-

-

-

-
KTR provides a circular buffer of events that can be logged in a
-    printf(9) style fashion. These events can then be dumped
-    with ddb(4), gdb(1)
-    (ports/devel/gdb) or
-  ktrdump(8).

-
Events are created and logged in the kernel via the
-    CTR and
-    CTRx macros. The first
-    parameter is a mask of event types (KTR_*) defined
-    in <sys/ktr_class.h>. The
-    event will be logged only if any of the event types specified in
-    mask are enabled in the global event mask stored in
-    ktr_mask. The format argument is
-    a printf(9) style format string used to build the text of
-    the event log message. Following the format string are
-    zero to six arguments referenced by format. Each event
-    is logged with a file name and source line number of the originating CTR
-    call, and a timestamp in addition to the log message.

-
The event is stored in the circular buffer with supplied arguments
-    as is, and formatting is done at the dump time. Do not use pointers to the
-    objects with limited lifetime, for instance, strings, because the pointer
-    may become invalid when buffer is printed.

-
The CTRx macros
-    differ only in the number of arguments each one takes, as indicated by its
-    name.

-
The ktr_entries variable contains the number
-    of entries in the ktr_buf array. These variables are
-    mostly useful for post-mortem crash dump tools to locate the base of the
-    circular trace buffer and its length.

-
The ktr_mask variable contains the run time
-    mask of events to log.

-
The CPU event mask is stored in the
-    ktr_cpumask variable.

-
The ktr_verbose variable stores the verbose
-    flag that controls whether events are logged to the console in addition to
-    the event buffer.

-

-

-

-
This example demonstrates the use of tracepoints at the
-    KTR_PROC logging level.

-

-
void
-mi_switch()
-{
-	...
-	/*
-	 * Pick a new current process and record its start time.
-	 */
-	...
-	CTR3(KTR_PROC, "mi_switch: old proc %p (pid %d)", p, p->p_pid);
-	...
-	cpu_switch();
-	...
-	CTR3(KTR_PROC, "mi_switch: new proc %p (pid %d)", p, p->p_pid);
-	...
-}

-

-

-

-

-
ktr(4), ktrdump(8)

-

-

-

-
The KTR kernel tracing facility first appeared in
-    BSD/OS 3.0 and was imported into
-    FreeBSD 5.0.

-
The CTR() macro accepting a variable
-    number of arguments first appeared in FreeBSD
-  14.0.

-

-

-

-
Currently there is one global buffer shared among all CPUs. It
-    might be profitable at some point in time to use per-CPU buffers instead so
-    that if one CPU halts or starts spinning, then the log messages it emitted
-    just prior to halting or spinning will not be drowned out by events from the
-    other CPUs.

-
The arguments given in CTRx() macros are
-    stored as u_long, so do not pass arguments larger than
-    size of an u_long type. For example passing 64bit
-    arguments on 32bit architectures will give incorrect results.

-

-

-
-  
-    
-    
-  
-
April 12, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/lock.9 4.html b/static/freebsd/man9/lock.9 4.html
deleted file mode 100644
index 2e87a299..00000000
--- a/static/freebsd/man9/lock.9 4.html	
+++ /dev/null
@@ -1,431 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOCK(9)Kernel Developer's ManualLOCK(9)

-

-

-

-
lockinit,
-    lockdestroy, lockmgr,
-    lockmgr_args,
-    lockmgr_args_rw,
-    lockmgr_disown,
-    lockmgr_disowned,
-    lockmgr_lock_flags,
-    lockmgr_printinfo,
-    lockmgr_recursed,
-    lockmgr_rw, lockmgr_slock,
-    lockmgr_unlock,
-    lockmgr_xlock, lockstatus,
-    lockmgr_assert — lockmgr
-    family of functions

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/lockmgr.h>

-
void
-  

-  lockinit(struct
-    lock *lkp, int
-    prio, const char
-    *wmesg, int timo,
-    int flags);

-
void
-  

-  lockdestroy(struct
-    lock *lkp);

-
int
-  

-  lockmgr(struct
-    lock *lkp, u_int
-    flags, struct mtx
-    *ilk);

-
int
-  

-  lockmgr_args(struct
-    lock *lkp, u_int
-    flags, struct mtx
-    *ilk, const char
-    *wmesg, int prio,
-    int timo);

-
int
-  

-  lockmgr_args_rw(struct
-    lock *lkp, u_int
-    flags, struct rwlock
-    *ilk, const char
-    *wmesg, int prio,
-    int timo);

-
void
-  

-  lockmgr_disown(struct
-    lock *lkp);

-
int
-  

-  lockmgr_disowned(const
-    struct lock *lkp);

-
int
-  

-  lockmgr_lock_flags(struct
-    lock *lkp, u_int
-    flags, struct lock_object
-    *ilk, const char
-    *file, int
-  line);

-
void
-  

-  lockmgr_printinfo(const
-    struct lock *lkp);

-
int
-  

-  lockmgr_recursed(const
-    struct lock *lkp);

-
int
-  

-  lockmgr_rw(struct
-    lock *lkp, u_int
-    flags, struct rwlock
-    *ilk);

-
int
-  

-  lockmgr_slock(struct
-    lock *lkp, u_int
-    flags, const char
-    *file, int
-  line);

-
int
-  

-  lockmgr_unlock(struct
-    lock *lkp);

-
int
-  

-  lockmgr_xlock(struct
-    lock *lkp, u_int
-    flags, const char
-    *file, int
-  line);

-
int
-  

-  lockstatus(const
-    struct lock *lkp);

-

-  

-  options INVARIANTS
-  

-  options INVARIANT_SUPPORT
-  

-  void
-  

-  lockmgr_assert(const
-    struct lock *lkp, int
-    what);

-

-

-

-
The
-    ()
-    function is used to initialize a lock. It must be called before any
-    operation can be performed on a lock. Its arguments are:

-

-  
lkp

-  
A pointer to the lock to initialize.

-  
prio

-  
The priority passed to sleep(9).

-  
wmesg

-  
The lock message. This is used for both debugging output and
-      sleep(9).

-  
timo

-  
The timeout value passed to sleep(9).

-  
flags

-  
The flags the lock is to be initialized with:
-    

-      

-      
Allow recursive exclusive locks.

-      

-      
Disable lock profiling for this lock.

-      

-      
Allow exclusive locks only.

-      

-      
Instruct witness(4) to ignore this lock.

-      

-      
witness(4) should log messages about duplicate locks
-          being acquired.

-      

-      
Disable ktr(4) logging for this lock.

-    

-  

-

-
The
-    ()
-    function is used to destroy a lock, and while it is called in a number of
-    places in the kernel, it currently does nothing.

-
The
-    ()
-    and
-    ()
-    functions handle general locking functionality within the kernel, including
-    support for shared and exclusive locks, and recursion.
-    lockmgr() and lockmgr_rw()
-    are also able to upgrade and downgrade locks.

-
Their arguments are:

-

-  
lkp

-  
A pointer to the lock to manipulate.

-  
flags

-  
Flags indicating what action is to be taken.
-    

-      

-      
Acquire a shared lock. If an exclusive lock is currently held,
-          EDEADLK will be returned.

-      

-      
Acquire an exclusive lock. If an exclusive lock is already held, and
-          LK_CANRECURSE is not set, the system will
-          panic(9).

-      

-      
Downgrade exclusive lock to a shared lock. Downgrading a shared lock
-          is not permitted. If an exclusive lock has been recursed, the system
-          will panic(9).

-      

-      
Upgrade a shared lock to an exclusive lock. If this call fails, the
-          shared lock is lost, even if the LK_NOWAIT
-          flag is specified. During the upgrade, the shared lock could be
-          temporarily dropped. Attempts to upgrade an exclusive lock will cause
-          a panic(9).

-      

-      
Try to upgrade a shared lock to an exclusive lock. The failure to
-          upgrade does not result in the dropping of the shared lock
-        ownership.

-      

-      
Release the lock. Releasing a lock that is not held can cause a
-          panic(9).

-      

-      
Wait for all activity on the lock to end, then mark it decommissioned.
-          This is used before freeing a lock that is part of a piece of memory
-          that is about to be freed. (As documented in
-          <sys/lockmgr.h>.)

-      

-      
Fail if operation has slept.

-      

-      
Do not allow the call to sleep. This can be used to test the
-        lock.

-      

-      
Use timo during a sleep; otherwise, 0 is
-        used.

-      

-      
Skip the witness(4) checks for this instance.

-      

-      
Allow recursion on an exclusive lock. For every lock there must be a
-          release.

-      

-      
Unlock the interlock (which should be locked already).

-      

-      
Normally,
-          ()
-          postpones serving further shared requests for shared-locked lock if
-          there is exclusive waiter, to avoid exclusive lock starvation. But, if
-          the thread requesting the shared lock already owns a shared lockmgr
-          lock, the request is granted even in presence of the parallel
-          exclusive lock request, which is done to avoid deadlocks with
-          recursive shared acquisition.
-        
The LK_NODDLKTREAT flag can only
-            be used by code which requests shared non-recursive lock. The flag
-            allows exclusive requests to preempt the current shared request even
-            if the current thread owns shared locks. This is safe since shared
-            lock is guaranteed to not recurse, and is used when thread is known
-            to held unrelated shared locks, to not cause unnecessary starvation.
-            An example is vp locking in VFS
-            lookup(9), when dvp is
-            already locked.

-      

-    

-  

-  
ilk

-  
An interlock mutex for controlling group access to the lock. If
-      LK_INTERLOCK is specified,
-      ()
-      and
-      ()
-      assume ilk is currently owned and not recursed, and
-      will return it unlocked. See mtx_assert(9).

-

-
The
-    ()
-    and
-    ()
-    function work like lockmgr() and
-    lockmgr_rw() but accepting a
-    wmesg, timo and
-    prio on a per-instance basis. The specified values
-    will override the default ones, but this can still be used passing,
-    respectively, LK_WMESG_DEFAULT,
-    LK_PRIO_DEFAULT and
-    LK_TIMO_DEFAULT.

-
The
-    ()
-    function works like lockmgr() but accepts explicit
-    file and line arguments for lock
-    tracing.

-
The
-    (),
-    (),
-    and
-    ()
-    functions are lightweight entry points that function like
-    lockmgr() for the LK_SHARED,
-    LK_EXCLUSIVE, and LK_RELEASE
-    operations respectively. They provide functionality similar to
-    sx(9) locks in that none of the additional
-    lockmgr(9) features are supported. Specifically, these
-    functions do not support unlocking interlocks, the
-    LK_SLEEPFAIL flag, or locks with shared locking
-    disabled via LK_NOSHARE. They also accept explicit
-    file and line arguments for lock
-    tracing.

-
The
-    ()
-    function switches the owner from the current thread to be
-    LK_KERNPROC, if the lock is already held.

-
The
-    ()
-    function returns true or false according to whether the lock is held by
-    LK_KERNPROC.

-
The
-    ()
-    function prints debugging information about the lock. It is used primarily
-    by VOP_PRINT(9) functions.

-
The
-    ()
-    function returns true if the lock is recursed, 0 otherwise.

-
The
-    ()
-    function returns the status of the lock in relation to the current
-  thread.

-
When compiled with options
-    INVARIANTS and options INVARIANT_SUPPORT, the
-    ()
-    function tests lkp for the assertions specified in
-    what, and panics if they are not met. One of the
-    following assertions must be specified:

-

-  

-  
Assert that the current thread has either a shared or an exclusive lock on
-      the lkp lock pointed to by the first argument.

-  

-  
Assert that the current thread has a shared lock on the
-      lkp lock pointed to by the first argument.

-  

-  
Assert that the current thread has an exclusive lock on the
-      lkp lock pointed to by the first argument.

-  

-  
Assert that the current thread has no lock on the
-      lkp lock pointed to by the first argument.

-

-
In addition, one of the following optional assertions can be used
-    with either an KA_LOCKED,
-    KA_SLOCKED, or KA_XLOCKED
-    assertion:

-

-  

-  
Assert that the current thread has a recursed lock on
-      lkp.

-  

-  
Assert that the current thread does not have a recursed lock on
-      lkp.

-

-

-

-

-
The lockmgr() and
-    lockmgr_rw() functions return 0 on success and
-    non-zero on failure.

-
The lockstatus() function returns:

-

-  

-  
An exclusive lock is held by the current thread.

-  

-  
An exclusive lock is held by someone other than the current thread.

-  

-  
A shared lock is held.

-  

-  
The lock is not held by anyone.

-

-

-

-

-
lockmgr() and
-    lockmgr_rw() fail if:

-

-  
[]

-  

-      was requested and another thread had already requested a lock
-    upgrade.

-  
[]

-  

-      was set, and a sleep would have been required, or
-      LK_TRYUPGRADE operation was not able to upgrade
-      the lock.

-  
[]

-  
A shared lock was attempted while the thread already held the exclusive
-      lock.

-  
[]

-  

-      was set and lockmgr() or
-      lockmgr_rw() did sleep.

-  
[]

-  

-      was set in the lock priority, and a signal was delivered during a sleep.
-      Note the
-      
-      error below.

-  
[]

-  

-      was set in the lock priority, a signal was delivered during a sleep, and
-      the system call is to be restarted.

-  
[]

-  
a non-zero timeout was given, and the timeout expired.

-

-

-

-

-
If LK_INTERLOCK is passed in the
-    flags argument to
-    ()
-    or
-    (),
-    the ilk must be held prior to calling
-    lockmgr() or lockmgr_rw(),
-    and will be returned unlocked.

-
Upgrade attempts that fail result in the loss of the lock that is
-    currently held. Also, it is invalid to upgrade an exclusive lock, and a
-    panic(9) will be the result of trying.

-

-

-

-
witness(4), condvar(9),
-    locking(9), mtx_assert(9),
-    mutex(9), panic(9),
-    rwlock(9), sleep(9),
-    sx(9), VOP_PRINT(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
June 21, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/locking.9 3.html b/static/freebsd/man9/locking.9 3.html
deleted file mode 100644
index a983183f..00000000
--- a/static/freebsd/man9/locking.9 3.html	
+++ /dev/null
@@ -1,458 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOCKING(9)Kernel Developer's ManualLOCKING(9)

-

-

-

-
locking — kernel
-    synchronization primitives

-

-

-

-
The
-    
-    kernel is written to run across multiple CPUs and as such provides several
-    different synchronization primitives to allow developers to safely access
-    and manipulate many data types.

-

-

-
Mutexes (also called "blocking mutexes") are the most
-    commonly used synchronization primitive in the kernel. A thread acquires
-    (locks) a mutex before accessing data shared with other threads (including
-    interrupt threads), and releases (unlocks) it afterwards. If the mutex
-    cannot be acquired, the thread requesting it will wait. Mutexes are adaptive
-    by default, meaning that if the owner of a contended mutex is currently
-    running on another CPU, then a thread attempting to acquire the mutex will
-    spin rather than yielding the processor. Mutexes fully support priority
-    propagation.

-
See mutex(9) for details.

-

-

-

-
Spin mutexes are a variation of basic mutexes; the main difference
-    between the two is that spin mutexes never block. Instead, they spin while
-    waiting for the lock to be released. To avoid deadlock, a thread that holds
-    a spin mutex must never yield its CPU. Unlike ordinary mutexes, spin mutexes
-    disable interrupts when acquired. Since disabling interrupts can be
-    expensive, they are generally slower to acquire and release. Spin mutexes
-    should be used only when absolutely necessary, e.g. to protect data shared
-    with interrupt filter code (see bus_setup_intr(9) for
-    details), or for scheduler internals.

-

-

-

-
With most synchronization primitives, such as mutexes, the
-    programmer must provide memory to hold the primitive. For example, a mutex
-    may be embedded inside the structure it protects. Mutex pools provide a
-    preallocated set of mutexes to avoid this requirement. Note that mutexes
-    from a pool may only be used as leaf locks.

-
See mtx_pool(9) for details.

-

-

-

-
Reader/writer locks allow shared access to protected data by
-    multiple threads or exclusive access by a single thread. The threads with
-    shared access are known as
-    
-    since they should only read the protected data. A thread with exclusive
-    access is known as a
-    
-    since it may modify protected data.

-
Reader/writer locks can be treated as mutexes (see above and
-    mutex(9)) with shared/exclusive semantics. Reader/writer
-    locks support priority propagation like mutexes, but priority is propagated
-    only to an exclusive holder. This limitation comes from the fact that shared
-    owners are anonymous.

-
See rwlock(9) for details.

-

-

-

-
Read-mostly locks are similar to
-    
-    locks but optimized for very infrequent write locking.
-    
-    locks implement full priority propagation by tracking shared owners using a
-    caller-supplied
-    
-    data structure.

-
See rmlock(9) for details.

-

-

-

-
Sleepable read-mostly locks are a variation on read-mostly locks.
-    Threads holding an exclusive lock may sleep, but threads holding a shared
-    lock may not. Priority is propagated to shared owners but not to exclusive
-    owners.

-

-

-

-
Shared/exclusive locks are similar to reader/writer locks; the
-    main difference between them is that shared/exclusive locks may be held
-    during unbounded sleep. Acquiring a contested shared/exclusive lock can
-    perform an unbounded sleep. These locks do not support priority
-  propagation.

-
See sx(9) for details.

-

-

-

-
Lockmanager locks are sleepable shared/exclusive locks used mostly
-    in VFS(9) (as a vnode(9) lock) and in
-    the buffer cache (BUF_LOCK(9)). They have features other
-    lock types do not have such as sleep timeouts, blocking upgrades, writer
-    starvation avoidance, draining, and an interlock mutex, but this makes them
-    complicated both to use and to implement; for this reason, they should be
-    avoided.

-
See lock(9) for details.

-

-

-

-
The kernel has two facilities, epoch(9) and
-    smr(9), which can be used to provide read-only access to a
-    data structure while one or more writers are concurrently modifying the data
-    structure. Specifically, readers using epoch(9) and
-    smr(9) to synchronize accesses do not block writers, in
-    contrast with reader/writer locks, and they help ensure that memory freed by
-    writers is not reused until all readers which may be accessing it have
-    finished. Thus, they are a useful building block in the construction of
-    lock-free data structures.

-
These facilities are difficult to use correctly and should be
-    avoided in preference to traditional mutual exclusion-based synchronization,
-    except when performance or non-blocking guarantees are a major concern.

-
See epoch(9) and smr(9) for
-    details.

-

-

-

-
Counting semaphores provide a mechanism for synchronizing access
-    to a pool of resources. Unlike mutexes, semaphores do not have the concept
-    of an owner, so they can be useful in situations where one thread needs to
-    acquire a resource, and another thread needs to release it. They are largely
-    deprecated.

-
See sema(9) for details.

-

-

-

-
Condition variables are used in conjunction with locks to wait for
-    a condition to become true. A thread must hold the associated lock before
-    calling one of the
-    (),
-    functions. When a thread waits on a condition, the lock is atomically
-    released before the thread yields the processor and reacquired before the
-    function call returns. Condition variables may be used with blocking
-    mutexes, reader/writer locks, read-mostly locks, and shared/exclusive
-  locks.

-
See condvar(9) for details.

-

-

-

-
The functions
-    (),
-    msleep(), msleep_spin(),
-    pause(), wakeup(), and
-    ()
-    also handle event-based thread blocking. Unlike condition variables,
-    arbitrary addresses may be used as wait channels and a dedicated structure
-    does not need to be allocated. However, care must be taken to ensure that
-    wait channel addresses are unique to an event. If a thread must wait for an
-    external event, it is put to sleep by tsleep(),
-    msleep(), msleep_spin(), or
-    pause(). Threads may also wait using one of the
-    locking primitive sleep routines mtx_sleep(9),
-    rw_sleep(9), or sx_sleep(9).

-
The parameter chan is an
-    arbitrary address that uniquely identifies the event on which the thread is
-    being put to sleep. All threads sleeping on a single
-    chan are woken up later by
-    ()
-    (often called from inside an interrupt routine) to indicate that the event
-    the thread was blocking on has occurred.

-
Several of the sleep functions including
-    (),
-    (),
-    and the locking primitive sleep routines specify an additional lock
-    parameter. The lock will be released before sleeping and reacquired before
-    the sleep routine returns. If priority includes the
-    PDROP flag, then the lock will not be reacquired
-    before returning. The lock is used to ensure that a condition can be checked
-    atomically, and that the current thread can be suspended without missing a
-    change to the condition or an associated wakeup. In addition, all of the
-    sleep routines will fully drop the Giant mutex (even
-    if recursed) while the thread is suspended and will reacquire the
-    Giant mutex (restoring any recursion) before the
-    function returns.

-
The
-    ()
-    function is a special sleep function that waits for a specified amount of
-    time to pass before the thread resumes execution. This sleep cannot be
-    terminated early by either an explicit wakeup() or a
-    signal.

-
See sleep(9) for details.

-

-

-

-
Giant is a special mutex used to protect data structures that do
-    not yet have their own locks. Since it provides semantics akin to the old
-    spl(9) interface, Giant has special characteristics:

-
    
-  
  1. It is recursive.
    2. 
-  
  2. Drivers can request that Giant be locked around them by not marking
-      themselves MPSAFE. Note that infrastructure to do this is slowly going
-      away as non-MPSAFE drivers either became properly locked or
-    disappear.
    3. 
-  
  3. Giant must be locked before other non-sleepable locks.
    4. 
-  
  4. Giant is dropped during unbounded sleeps and reacquired after wakeup.
    5. 
-  
  5. There are places in the kernel that drop Giant and pick it back up again.
-      Sleep locks will do this before sleeping. Parts of the network or VM code
-      may do this as well. This means that you cannot count on Giant keeping
-      other code from running if your code sleeps, even if you want it to.
    6. 
-

-

-

-

-

-
The primitives can interact and have a number of rules regarding
-    how they can and can not be combined. Many of these rules are checked by
-    witness(4).

-

-

-
In a bounded sleep (also referred to as “blocking”)
-    the only resource needed to resume execution of a thread is CPU time for the
-    owner of a lock that the thread is waiting to acquire. In an unbounded sleep
-    (often referred to as simply “sleeping”) a thread waits for an
-    external event or for a condition to become true. In particular, a
-    dependency chain of threads in bounded sleeps should always make forward
-    progress, since there is always CPU time available. This requires that no
-    thread in a bounded sleep is waiting for a lock held by a thread in an
-    unbounded sleep. To avoid priority inversions, a thread in a bounded sleep
-    lends its priority to the owner of the lock that it is waiting for.

-
The following primitives perform bounded sleeps: mutexes,
-    reader/writer locks and read-mostly locks.

-
The following primitives perform unbounded sleeps: sleepable
-    read-mostly locks, shared/exclusive locks, lockmanager locks, counting
-    semaphores, condition variables, and sleep/wakeup.

-

-

-

-
    
-  
  • It is an error to do any operation that could result in yielding the
-      processor while holding a spin mutex.
    • 
-  
  • It is an error to do any operation that could result in unbounded sleep
-      while holding any primitive from the 'bounded sleep' group. For example,
-      it is an error to try to acquire a shared/exclusive lock while holding a
-      mutex, or to try to allocate memory with M_WAITOK while holding a
-      reader/writer lock.
-    
    Note that the lock passed to one of the
-        ()
-        or cv_wait() functions is dropped before the
-        thread enters the unbounded sleep and does not violate this rule.
    
-  
    • 
-  
  • It is an error to do any operation that could result in yielding of the
-      processor when running inside an interrupt filter.
    • 
-  
  • It is an error to do any operation that could result in unbounded sleep
-      when running inside an interrupt thread.
    • 
-

-

-

-

-
The following table shows what you can and can not do while
-    holding one of the locking primitives discussed. Note that
-    “sleep” includes
-    (),
-    (),
-    any of the cv_wait() functions, and any of the
-    sleep() functions.

-
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-
 You want:spin mtxmutex/rwrmlocksleep rmsx/lksleep
-----------------------------------------
spin mtxoknonononono-1
mutex/rwokokoknonono-1
rmlockokokoknonono-1
sleep rmokokokok-2ok-2ok-2/3
sxokokokokokok-3
lockmgrokokokokokok

-

-    There are calls that atomically release this primitive when going to sleep
-    and reacquire it on wakeup
-    ((),
-    (),
-    msleep_spin(), etc.).

-

-    These cases are only allowed while holding a write lock on a sleepable
-    read-mostly lock.

-

-    Though one can sleep while holding this lock, one can also use a
-    ()
-    function to atomically release this primitive when going to sleep and
-    reacquire it on wakeup.

-
Note that non-blocking try operations on locks are always
-    permitted.

-

-

-

-
The next table shows what can be used in different contexts. At
-    this time this is a rather easy to remember table.

-
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-
spin mtxmutex/rwrmlocksleep rmsx/lksleep
interrupt filter:oknonononono
interrupt thread:okokoknonono
callout:okokoknonono
direct callout:oknonononono
system call:okokokokokok

-

-

-

-

-
lockstat(1), witness(4),
-    atomic(9), BUS_SETUP_INTR(9),
-    callout(9), condvar(9),
-    epoch(9), lock(9),
-    LOCK_PROFILING(9), mtx_pool(9),
-    mutex(9), rmlock(9),
-    rwlock(9), sema(9),
-    sleep(9), smr(9),
-    sx(9)

-

-

-

-
There are too many locking primitives to choose from.

-

-

-
-  
-    
-    
-  
-
December 28, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/mac.9 3.html b/static/freebsd/man9/mac.9 3.html
deleted file mode 100644
index 87203490..00000000
--- a/static/freebsd/man9/mac.9 3.html	
+++ /dev/null
@@ -1,200 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAC(9)Kernel Developer's ManualMAC(9)

-

-

-

-
mac — TrustedBSD
-    Mandatory Access Control framework

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/mac.h>

-
In the kernel configuration file:
-  

-  options MAC
-  

-  options MAC_DEBUG

-

-

-

-

-

-
The TrustedBSD mandatory access control framework permits
-    dynamically introduced system security modules to modify system security
-    functionality. This can be used to support a variety of new security
-    services, including traditional labeled mandatory access control models. The
-    framework provides a series of entry points which must be called by code
-    supporting various kernel services, especially with respects to access
-    control points and object creation. The framework then calls out to security
-    modules to offer them the opportunity to modify security behavior at those
-    MAC API entry points. Both consumers of the API (normal kernel services) and
-    security modules must be aware of the semantics of the API calls,
-    particularly with respect to synchronization primitives (such as
-  locking).

-

-

-

-
The MAC framework manages labels on a variety of types of
-    in-kernel objects, including process credentials, vnodes, devfs_dirents,
-    mount points, sockets, mbufs, bpf descriptors, network interfaces, IP
-    fragment queues, and pipes. Label data on kernel objects, represented by
-    struct label, is policy-unaware, and may be used in
-    the manner seen fit by policy modules.

-

-

-

-
The MAC API provides a large set of entry points, too broad to
-    specifically document here. In general, these entry points represent an
-    access control check or other MAC-relevant operations, accept one or more
-    subjects (credentials) authorizing the activity, a set of objects on which
-    the operation is to be performed, and a set of operation arguments providing
-    information about the type of operation being requested.

-

-

-

-
Consumers of the MAC API must be aware of the locking requirements
-    for each API entry point: generally, appropriate locks must be held over
-    each subject or object being passed into the call, so that MAC modules may
-    make use of various aspects of the object for access control purposes. For
-    example, vnode locks are frequently required in order that the MAC framework
-    and modules may retrieve security labels and attributes from the vnodes for
-    the purposes of access control. Similarly, the caller must be aware of the
-    reference counting semantics of any subject or object passed into the MAC
-    API: all calls require that a valid reference to the object be held for the
-    duration of the (potentially lengthy) MAC API call. Under some
-    circumstances, objects must be held in either a shared or exclusive
-  manner.

-

-

-

-
Each module exports a structure describing the MAC API operations
-    that the module chooses to implement, including initialization and
-    destruction API entry points, a variety of object creation and destruction
-    calls, and a large set of access control check points. In the future,
-    additional audit entry points will also be present. Module authors may
-    choose to only implement a subset of the entry points, setting API function
-    pointers in the description structure to NULL,
-    permitting the framework to avoid calling into the module.

-

-

-

-
Module writers must be aware of the locking semantics of entry
-    points that they implement: MAC API entry points will have specific locking
-    or reference counting semantics for each argument, and modules must follow
-    the locking and reference counting protocol or risk a variety of failure
-    modes (including race conditions, inappropriate pointer dereferences,
-  etc).

-
MAC module writers must also be aware that MAC API entry points
-    will frequently be invoked from deep in a kernel stack, and as such must be
-    careful to avoid violating more global locking requirements, such as global
-    lock order requirements. For example, it may be inappropriate to lock
-    additional objects not specifically maintained and ordered by the policy
-    module, or the policy module might violate a global ordering requirement
-    relating to those additional objects.

-
Finally, MAC API module implementors must be careful to avoid
-    inappropriately calling back into the MAC framework: the framework makes use
-    of locking to prevent inconsistencies during policy module attachment and
-    detachment. MAC API modules should avoid producing scenarios in which
-    deadlocks or inconsistencies might occur.

-

-

-

-
The MAC API is intended to be easily expandable as new services
-    are added to the kernel. In order that policies may be guaranteed the
-    opportunity to ubiquitously protect system subjects and objects, it is
-    important that kernel developers maintain awareness of when security checks
-    or relevant subject or object operations occur in newly written or modified
-    kernel code. New entry points must be carefully documented so as to prevent
-    any confusion regarding lock orders and semantics. Introducing new entry
-    points requires four distinct pieces of work: introducing new MAC API
-    entries reflecting the operation arguments, scattering these MAC API entry
-    points throughout the new or modified kernel service, extending the
-    front-end implementation of the MAC API framework, and modifying appropriate
-    modules to take advantage of the new entry points so that they may
-    consistently enforce their policies.

-

-

-

-

-
System service and module authors should reference the
-    FreeBSD Architecture Handbook for information on
-    the MAC Framework APIs.

-

-

-

-
acl(3), mac(3),
-    posix1e(3), mac(4),
-    ucred(9), vaccess(9),
-    vaccess_acl_posix1e(9), VFS(9),
-    VOP_SETLABEL(9)

-
The FreeBSD Architecture
-    Handbook,
-    https://docs.freebsd.org/en/books/arch-handbook/.

-

-

-

-
The TrustedBSD MAC Framework first appeared in
-    FreeBSD 5.0.

-

-

-

-
This manual page was written by Robert
-    Watson. This software was contributed to the
-    FreeBSD Project by Network Associates Laboratories,
-    the Security Research Division of Network Associates Inc. under DARPA/SPAWAR
-    contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA
-    CHATS research program.

-
The TrustedBSD MAC Framework was designed by
-    Robert Watson, and implemented by the Network
-    Associates Laboratories Network Security (NETSEC), Secure Execution
-    Environment (SEE), and Adaptive Network Defense research groups. Network
-    Associates Laboratory staff contributing to the CBOSS Project include (in
-    alphabetical order): Lee Badger,
-    Brian Feldman, Hrishikesh
-    Dandekar, Tim Fraser, Doug
-    Kilpatrick, Suresh Krishnaswamy,
-    Adam Migus, Wayne Morrison,
-    Andrew Reisse, Chris Vance,
-    and Robert Watson.

-
Sub-contracted staff include: Chris
-    Costello, Poul-Henning Kamp,
-    Jonathan Lemon, Kirk
-    McKusick, Dag-Erling Smørgrav.

-
Additional contributors include: Pawel
-    Dawidek, Chris Faulhaber,
-    Ilmar Habibulin, Mike
-    Halderman, Bosko Milekic,
-    Thomas Moestl, Andrew
-    Reiter, and Tim Robbins.

-

-

-

-
While the MAC Framework design is intended to support the
-    containment of the root user, not all attack channels are currently
-    protected by entry point checks. As such, MAC Framework policies should not
-    be relied on, in isolation, to protect against a malicious privileged
-  user.

-

-

-
-  
-    
-    
-  
-
May 20, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/make_dev.9 4.html b/static/freebsd/man9/make_dev.9 4.html
deleted file mode 100644
index 75599e63..00000000
--- a/static/freebsd/man9/make_dev.9 4.html	
+++ /dev/null
@@ -1,415 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAKE_DEV(9)Kernel Developer's ManualMAKE_DEV(9)

-

-

-

-
make_dev,
-    make_dev_cred,
-    make_dev_credf, make_dev_p,
-    make_dev_s, make_dev_alias,
-    make_dev_alias_p,
-    destroy_dev,
-    destroy_dev_sched,
-    destroy_dev_sched_cb,
-    destroy_dev_drain,
-    dev_depends — create and
-    destroy character devices including devfs registration

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/conf.h>

-
void
-  

-  make_dev_args_init(struct
-    make_dev_args *args);

-
int
-  

-  make_dev_s(struct
-    make_dev_args *args,
-    struct cdev **cdev,
-    const char *fmt,
-    ...);

-
int
-  

-  make_dev_alias_p(int
-    flags, struct cdev
-    **cdev, struct cdev
-    *pdev, const char
-    *fmt, ...);

-
void
-  

-  destroy_dev(struct
-    cdev *dev);

-
void
-  

-  destroy_dev_sched(struct
-    cdev *dev);

-
void
-  

-  destroy_dev_sched_cb(struct
-    cdev *dev, void
-    (*cb)(void *), void
-    *arg);

-
void
-  

-  destroy_dev_drain(struct
-    cdevsw *csw);

-
void
-  

-  dev_depends(struct
-    cdev *pdev, struct cdev
-    *cdev);

-
LEGACY INTERFACES
-  

-  struct cdev *
-  

-  make_dev(struct
-    cdevsw *cdevsw, int
-    unit, uid_t uid,
-    gid_t gid,
-    int perms,
-    const char *fmt,
-    ...);

-
struct cdev *
-  

-  make_dev_cred(struct
-    cdevsw *cdevsw, int
-    unit, struct ucred
-    *cr, uid_t uid,
-    gid_t gid,
-    int perms,
-    const char *fmt,
-    ...);

-
struct cdev *
-  

-  make_dev_credf(int
-    flags, struct cdevsw
-    *cdevsw, int unit,
-    struct ucred *cr,
-    uid_t uid,
-    gid_t gid,
-    int perms,
-    const char *fmt,
-    ...);

-
int
-  

-  make_dev_p(int
-    flags, struct cdev
-    **cdev, struct cdevsw
-    *devsw, struct ucred
-    *cr, uid_t uid,
-    gid_t gid,
-    int mode,
-    const char *fmt,
-    ...);

-
struct cdev *
-  

-  make_dev_alias(struct
-    cdev *pdev, const char
-    *fmt, ...);

-

-

-

-
The
-    ()
-    function creates a cdev structure for a new device,
-    which is returned into the cdev argument. It also
-    notifies devfs(4) of the presence of the new device, that
-    causes corresponding nodes to be created. Besides this, a
-    devctl(4) notification is sent. The function takes the
-    structure struct make_dev_args args, which specifies
-    the parameters for the device creation:

-

-

-
struct make_dev_args {
-	size_t		 mda_size;
-	int		 mda_flags;
-	struct cdevsw	*mda_devsw;
-	struct ucred	*mda_cr;
-	uid_t		 mda_uid;
-	gid_t		 mda_gid;
-	int		 mda_mode;
-	int		 mda_unit;
-	void		*mda_si_drv1;
-	void		*mda_si_drv2;
-};

-

-
Before use and filling with the desired
-    values, the structure must be initialized by the
-    ()
-    function, which ensures that future kernel interface expansion does not
-    affect driver source code or binary interface.

-
The created device will be owned by
-    args.mda_uid, with the group ownership as
-    args.mda_gid. The name is the expansion of
-    fmt and following arguments as
-    printf(9) would print it. The name determines its path
-    under /dev or other devfs(4) mount
-    point and may contain slash ‘/’
-    characters to denote subdirectories. The permissions of the file specified
-    in args.mda_mode are defined in
-    <sys/stat.h>:

-

-

-
#define S_IRWXU 0000700    /* RWX mask for owner */
-#define S_IRUSR 0000400    /* R for owner */
-#define S_IWUSR 0000200    /* W for owner */
-#define S_IXUSR 0000100    /* X for owner */
-
-#define S_IRWXG 0000070    /* RWX mask for group */
-#define S_IRGRP 0000040    /* R for group */
-#define S_IWGRP 0000020    /* W for group */
-#define S_IXGRP 0000010    /* X for group */
-
-#define S_IRWXO 0000007    /* RWX mask for other */
-#define S_IROTH 0000004    /* R for other */
-#define S_IWOTH 0000002    /* W for other */
-#define S_IXOTH 0000001    /* X for other */
-
-#define S_ISUID 0004000    /* set user id on execution */
-#define S_ISGID 0002000    /* set group id on execution */
-#define S_ISVTX 0001000    /* sticky bit */
-#ifndef _POSIX_SOURCE
-#define S_ISTXT 0001000
-#endif

-

-
The args.mda_cr argument specifies
-    credentials that will be stored in the si_cred member
-    of the initialized struct cdev.

-
The args.mda_flags
-    argument alters the operation of
-    ().
-    The following values are currently accepted:

-

-

-

-  

-  
reference the created device

-  

-  
do not sleep, the call may fail

-  

-  
allow the function to sleep to satisfy malloc

-  

-  
created device will be never destroyed

-  

-  
return an error if the device name is invalid or already exists

-

-

-
Only MAKEDEV_NOWAIT,
-    MAKEDEV_WAITOK and
-    MAKEDEV_CHECKNAME values are accepted for the
-    ()
-    function.

-
The MAKEDEV_WAITOK flag is assumed if none
-    of MAKEDEV_WAITOK,
-    MAKEDEV_NOWAIT is specified.

-
The dev_clone(9) event handler
-    shall specify the MAKEDEV_REF flag when creating a
-    device in response to lookup, to avoid a race where the created device is
-    immediately destroyed after
-    ()
-    drops its reference to cdev.

-
The MAKEDEV_ETERNAL flag
-    allows the kernel to not acquire some locks when translating system calls
-    into the cdevsw methods calls. It is responsibility of the driver author to
-    make sure that
-    ()
-    is never called on the returned cdev. For the convenience, use the
-    MAKEDEV_ETERNAL_KLD flag for the code that can be
-    compiled into kernel or loaded (and unloaded) as loadable module.

-
A panic will occur if the
-    MAKEDEV_CHECKNAME flag is not specified and the
-    device name is invalid or already exists.

-
The
-    ()
-    use of the form:

-

-
struct cdev *dev;
-int res;
-res = make_dev_p(flags, &dev, cdevsw, cred, uid, gid, perms, name);

-

-
is equivalent to the code:

-

-
struct cdev *dev;
-struct make_dev_args args;
-int res;
-
-make_dev_args_init(&args);
-args.mda_flags = flags;
-args.mda_devsw = cdevsw;
-args.mda_cr = cred;
-args.mda_uid = uid;
-args.mda_gid = gid;
-args.mda_mode = perms;
-res = make_dev_s(&args, &dev, name);

-

-
Similarly, the
-    ()
-    function call is equivalent to:

-

-
(void) make_dev_s(&args, &dev, name);

-

-
In other words,
-    ()
-    does not allow the caller to obtain the return value, and in kernels
-    compiled with the INVARIANTS options, the function
-    asserts that the device creation succeeded.

-
The
-    ()
-    function is equivalent to the call:

-

-
make_dev_credf(0, cdevsw, unit, cr, uid, gid, perms, fmt, ...);

-

-
The
-    ()
-    function call is the same as:

-

-
make_dev_credf(0, cdevsw, unit, NULL, uid, gid, perms, fmt, ...);

-

-
The
-    ()
-    function takes the returned cdev from
-    make_dev() and makes another (aliased) name for this
-    device. It is an error to call make_dev_alias_p()
-    prior to calling make_dev().

-
The
-    ()
-    function is similar to make_dev_alias_p() but it
-    returns the resulting aliasing *cdev and may not
-    return an error.

-
The cdev returned by
-    ()
-    and make_dev_alias_p() has two fields,
-    si_drv1 and si_drv2, that are
-    available to store state. Both fields are of type void
-    *, and can be initialized simultaneously with the
-    cdev allocation by filling
-    args.mda_si_drv1 and
-    args.mda_si_drv2 members of the
-    make_dev_s() argument structure, or filled after the
-    cdev is allocated, if using legacy interfaces. In the
-    latter case, the driver should handle the race of accessing uninitialized
-    si_drv1 and si_drv2 itself.
-    These are designed to replace the unit argument to
-    make_dev(), which can be obtained with
-    ().

-
The
-    ()
-    function takes the returned cdev from
-    make_dev() and destroys the registration for that
-    device. The notification is sent to devctl(4) about the
-    destruction event. Do not call destroy_dev() on
-    devices that were created with make_dev_alias().

-
The
-    ()
-    function establishes a parent-child relationship between two devices. The
-    net effect is that a destroy_dev() of the parent
-    device will also result in the destruction of the child device(s), if any
-    exist. A device may simultaneously be a parent and a child, so it is
-    possible to build a complete hierarchy.

-
The
-    ()
-    function schedules execution of the destroy_dev()
-    for the specified cdev in the safe context. After
-    destroy_dev() is finished, and if the supplied
-    cb is not NULL, the callback
-    cb is called, with argument arg.
-    The destroy_dev_sched() function is the same as:

-

-
destroy_dev_sched_cb(cdev, NULL, NULL);

-

-
Neither the
-    ()
-    driver method, nor a devfs_cdevpriv(9)
-    dtr method can destroy_dev()
-    directly. Doing so causes deadlock when
-    destroy_dev() waits for all threads to leave the
-    driver methods and finish executing any per-open destructors. Also, because
-    destroy_dev() sleeps, no non-sleepable locks may be
-    held over the call. The destroy_dev_sched() family
-    of functions overcome these issues.

-
The device driver may call the
-    ()
-    function to wait until all devices that have supplied
-    csw as cdevsw, are destroyed. This is useful when
-    driver knows that
-    ()
-    is called for all instantiated devices, but need to postpone module unload
-    until destroy_dev() is actually finished for all of
-    them.

-

-

-

-
If successful, make_dev_s() and
-    make_dev_p() will return 0, otherwise they will
-    return an error. If successful, make_dev_credf()
-    will return a valid cdev pointer, otherwise it will
-    return NULL.

-

-

-

-
The make_dev_s(),
-    make_dev_p() and
-    make_dev_alias_p() calls will fail and the device
-    will be not registered if:

-

-  
[]

-  
The MAKEDEV_NOWAIT flag was specified and a memory
-      allocation request could not be satisfied.

-  
[]

-  
The MAKEDEV_CHECKNAME flag was specified and the
-      provided device name is longer than
-    SPECNAMELEN.

-  
[]

-  
The MAKEDEV_CHECKNAME flag was specified and the
-      provided device name is empty, contains a "." or ".."
-      path component or ends with
-    ‘/’.

-  
[]

-  
The MAKEDEV_CHECKNAME flag was specified and the
-      provided device name contains invalid characters.

-  
[]

-  
The MAKEDEV_CHECKNAME flag was specified and the
-      provided device name already exists.

-

-

-

-

-
devctl(4), devfs(4),
-    dev_clone(9)

-

-

-

-
The make_dev() and
-    destroy_dev() functions first appeared in
-    FreeBSD 4.0. The function
-    make_dev_alias() first appeared in
-    FreeBSD 4.1. The function
-    dev_depends() first appeared in
-    FreeBSD 5.0. The functions
-    make_dev_credf(),
-    destroy_dev_sched(),
-    destroy_dev_sched_cb() first appeared in
-    FreeBSD 7.0. The function
-    make_dev_p() first appeared in
-    FreeBSD 8.2. The function
-    make_dev_s() first appeared in
-    FreeBSD 11.0.

-

-

-
-  
-    
-    
-  
-
November 4, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/malloc.9 4.html b/static/freebsd/man9/malloc.9 4.html
deleted file mode 100644
index 2676cb88..00000000
--- a/static/freebsd/man9/malloc.9 4.html	
+++ /dev/null
@@ -1,332 +0,0 @@
-
-  
-    
-    
-    
-  
-
MALLOC(9)Kernel Developer's ManualMALLOC(9)

-

-

-

-
malloc,
-    mallocarray, free,
-    zfree, realloc,
-    reallocf,
-    malloc_usable_size,
-    malloc_aligned, malloc_exec,
-    MALLOC_DECLARE,
-    MALLOC_DEFINE,
-    malloc_domainset,
-    malloc_domainset_aligned,
-    malloc_domainset_exec,
-    mallocarray_domainset —
-    kernel memory management routines

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/malloc.h>

-
void *
-  

-  malloc(size_t
-    size, struct malloc_type
-    *type, int
-  flags);

-
void *
-  

-  mallocarray(size_t
-    nmemb, size_t size,
-    struct malloc_type *type,
-    int flags);

-
void
-  

-  free(void
-    *addr, struct malloc_type
-    *type);

-
void
-  

-  zfree(void
-    *addr, struct malloc_type
-    *type);

-
void *
-  

-  realloc(void
-    *addr, size_t size,
-    struct malloc_type *type,
-    int flags);

-
void *
-  

-  reallocf(void
-    *addr, size_t size,
-    struct malloc_type *type,
-    int flags);

-
size_t
-  

-  malloc_usable_size(const
-    void *addr);

-
void *
-  

-  malloc_aligned(size_t size,
-    size_t align, struct malloc_type
-    *type, int flags);

-
void *
-  

-  malloc_exec(size_t
-    size, struct malloc_type
-    *type, int
-  flags);

-
MALLOC_DECLARE(type);

-
#include
-    <sys/param.h>
-  

-  #include <sys/malloc.h>
-  

-  #include <sys/kernel.h>

-
MALLOC_DEFINE(type,
-    shortdesc,
-    longdesc);

-
#include
-    <sys/param.h>
-  

-  #include <sys/domainset.h>
-  

-  #include <sys/malloc.h>

-
void *
-  

-  malloc_domainset(size_t
-    size, struct malloc_type
-    *type, struct domainset
-    *ds, int
-  flags);

-
void *
-  

-  malloc_domainset_aligned(size_t
-    size, size_t align, struct
-    malloc_type *type, struct domainset *ds,
-    int flags);

-
void *
-  

-  malloc_domainset_exec(size_t
-    size, struct malloc_type
-    *type, struct domainset
-    *ds, int
-  flags);

-
void *
-  

-  mallocarray_domainset(size_t
-    nmemb, size_t size,
-    struct malloc_type *type,
-    struct domainset *ds,
-    int flags);

-

-

-

-
The
-    ()
-    function allocates uninitialized memory in kernel address space for an
-    object whose size is specified by size.

-
The
-    ()
-    variant allocates memory from a specific numa(4) domain
-    using the specified domain selection policy. See
-    domainset(9) for some example policies.

-
The
-    ()
-    and
-    ()
-    variants return allocations aligned as specified by
-    align, which must be non-zero, a power of two, and
-    less than or equal to the page size.

-
Both
-    ()
-    and
-    ()
-    can be used to return executable memory. Not all platforms enforce a
-    distinction between executable and non-executable memory.

-
The
-    ()
-    function allocates uninitialized memory in kernel address space for an array
-    of nmemb entries whose size is specified by
-    size.

-
The
-    ()
-    variant allocates memory from a specific numa(4) domain
-    using the specified domain selection policy. See
-    domainset(9) for some example policies.

-
The
-    ()
-    function releases memory at address addr that was
-    previously allocated by malloc() for re-use. The
-    memory is not zeroed. If addr is
-    NULL, then free() does
-    nothing.

-
Like
-    (), the
-    ()
-    function releases memory at address addr that was
-    previously allocated by malloc() for re-use.
-    However, zfree() will zero the memory before it is
-    released.

-
The
-    ()
-    function changes the size of the previously allocated memory referenced by
-    addr to size bytes. The contents
-    of the memory are unchanged up to the lesser of the new and old sizes. Note
-    that the returned value may differ from addr. If the
-    requested memory cannot be allocated, NULL is
-    returned and the memory referenced by addr is valid
-    and unchanged. If addr is
-    NULL, the realloc() function
-    behaves identically to malloc() for the specified
-    size.

-
The
-    ()
-    function is identical to realloc() except that it
-    will free the passed pointer when the requested memory cannot be
-  allocated.

-
The
-    ()
-    function returns the usable size of the allocation pointed to by
-    addr. The return value may be larger than the size
-    that was requested during allocation.

-
Unlike its standard C library counterpart
-    (malloc(3)), the kernel version takes two more arguments.
-    The flags argument further qualifies
-    ()'s
-    operational characteristics as follows:

-

-  

-  
Causes the allocated memory to be set to all zeros.

-  

-  
For allocations greater than page size, causes the allocated memory to be
-      excluded from kernel core dumps.

-  

-  
Causes malloc(),
-      realloc(), and reallocf()
-      to return NULL if the request cannot be
-      immediately fulfilled due to resource shortage. Note that
-      M_NOWAIT is required when running in an interrupt
-      context.

-  

-  
Indicates that it is OK to wait for resources. If the request cannot be
-      immediately fulfilled, the current process is put to sleep to wait for
-      resources to be released by other processes. The
-      malloc(), mallocarray(),
-      realloc(), and reallocf()
-      functions cannot return NULL if
-      M_WAITOK is specified. If the multiplication of
-      nmemb and size would cause an
-      integer overflow, the mallocarray() function
-      induces a panic.

-  

-  
Indicates that the system can use its reserve of memory to satisfy the
-      request. This option should only be used in combination with
-      M_NOWAIT when an allocation failure cannot be
-      tolerated by the caller without catastrophic effects on the system.

-  

-  
This is an internal flag used by the uma(9) allocator
-      and should not be used in regular malloc()
-      invocations. See the description of VM_ALLOC_NOFREE in
-      vm_page_alloc(9) for more details.

-

-
Exactly one of either M_WAITOK or
-    M_NOWAIT must be specified.

-
The type argument is used to perform
-    statistics on memory usage, and for basic sanity checks. It can be used to
-    identify multiple allocations. The statistics can be examined by
-    ‘vmstat -m’.

-
A type is defined using
-    struct malloc_type via the
-    ()
-    and MALLOC_DEFINE() macros.

-

-
/* sys/something/foo_extern.h */
-
-MALLOC_DECLARE(M_FOOBUF);
-
-/* sys/something/foo_main.c */
-
-MALLOC_DEFINE(M_FOOBUF, "foobuffers", "Buffers to foo data into the ether");
-
-/* sys/something/foo_subr.c */
-
-...
-buf = malloc(sizeof(*buf), M_FOOBUF, M_NOWAIT);
-
-

-

-
In order to use
-    (),
-    one must include
-    <sys/param.h> (instead of
-    <sys/types.h>) and
-    <sys/kernel.h>.

-

-

-

-
malloc(),
-    realloc() and reallocf() may
-    not be called from fast interrupts handlers. When called from threaded
-    interrupts, flags must contain
-    M_NOWAIT.

-
malloc(),
-    realloc() and reallocf() may
-    sleep when called with M_WAITOK.
-    free() never sleeps. However,
-    malloc(), realloc(),
-    reallocf() and free() may
-    not be called in a critical section or while holding a spin lock.

-
Any calls to malloc() (even with
-    M_NOWAIT) or free() when
-    holding a vnode(9) interlock, will cause a LOR (Lock Order
-    Reversal) due to the intertwining of VM Objects and Vnodes.

-

-

-

-
The memory allocator allocates memory in chunks that have size a
-    power of two for requests up to the size of a page of memory. For larger
-    requests, one or more pages is allocated. While it should not be relied
-    upon, this information may be useful for optimizing the efficiency of memory
-    use.

-

-

-

-
The malloc(),
-    realloc(), and reallocf()
-    functions return a kernel virtual address that is suitably aligned for
-    storage of any type of object, or NULL if the
-    request could not be satisfied (implying that
-    M_NOWAIT was set).

-

-

-

-
A kernel compiled with the INVARIANTS
-    configuration option attempts to detect memory corruption caused by such
-    things as writing outside the allocated area and imbalanced calls to the
-    malloc() and free()
-    functions. Failing consistency checks will cause a panic or a system console
-    message.

-

-

-

-
numa(4), vmstat(8),
-    contigmalloc(9), domainset(9),
-    memguard(9), vnode(9)

-

-

-

-
zfree() first appeared in
-    FreeBSD 13.0.

-

-

-
-  
-    
-    
-  
-
August 4, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/mbchain.9 4.html b/static/freebsd/man9/mbchain.9 4.html
deleted file mode 100644
index 8fec949c..00000000
--- a/static/freebsd/man9/mbchain.9 4.html	
+++ /dev/null
@@ -1,229 +0,0 @@
-
-  
-    
-    
-    
-  
-
MBCHAIN(9)Kernel Developer's ManualMBCHAIN(9)

-

-

-

-
mbchain, mb_init,
-    mb_initm, mb_done,
-    mb_detach, mb_fixhdr,
-    mb_reserve, mb_put_uint8,
-    mb_put_uint16be,
-    mb_put_uint16le,
-    mb_put_uint32be,
-    mb_put_uint32le,
-    mb_put_int64be,
-    mb_put_int64le, mb_put_mem,
-    mb_put_mbuf, mb_put_uio
-    — set of functions to build an mbuf chain from
-    various data types

-

-

-

-
options LIBMCHAIN kldload
-    libmchain

-

-  

-  #include <sys/param.h>
-  

-  #include <sys/uio.h>
-  

-  #include <sys/mchain.h>

-
int
-  

-  mb_init(struct
-    mbchain *mbp);

-
void
-  

-  mb_initm(struct
-    mbchain *mbp, struct mbuf
-    *m);

-
void
-  

-  mb_done(struct
-    mbchain *mbp);

-
struct mbuf *
-  

-  mb_detach(struct
-    mbchain *mbp);

-
int
-  

-  mb_fixhdr(struct
-    mbchain *mbp);

-
caddr_t
-  

-  mb_reserve(struct
-    mbchain *mbp, int
-    size);

-
int
-  

-  mb_put_uint8(struct
-    mbchain *mbp, uint8_t
-    x);

-
int
-  

-  mb_put_uint16be(struct
-    mbchain *mbp, uint16_t
-    x);

-
int
-  

-  mb_put_uint16le(struct
-    mbchain *mbp, uint16_t
-    x);

-
int
-  

-  mb_put_uint32be(struct
-    mbchain *mbp, uint32_t
-    x);

-
int
-  

-  mb_put_uint32le(struct
-    mbchain *mbp, uint32_t
-    x);

-
int
-  

-  mb_put_int64be(struct
-    mbchain *mbp, int64_t
-    x);

-
int
-  

-  mb_put_int64le(struct
-    mbchain *mbp, int64_t
-    x);

-
int
-  

-  mb_put_mem(struct
-    mbchain *mbp, c_caddr_t
-    source, int size,
-    int type);

-
int
-  

-  mb_put_mbuf(struct
-    mbchain *mbp, struct mbuf
-    *m);

-
int
-  

-  mb_put_uio(struct
-    mbchain *mbp, struct uio
-    *uiop, int
-  size);

-

-

-

-
These functions are used to compose mbuf chains from various data
-    types. The mbchain structure is used as a working
-    context and should be initialized with a call to either
-    ()
-    or
-    ().
-    It has the following fields:

-

-  
mb_top

-  
(struct mbuf *) A pointer to the top of constructed
-      mbuf chain.

-  
mb_cur

-  
(struct mbuf *) A pointer to the currently filled
-      mbuf.

-  
mb_mleft

-  
(int) Number of bytes left in the current mbuf.

-  
mb_count

-  
(int) Total number of bytes placed in the mbuf
-      chain.

-  
mb_copy

-  
(mb_copy_t *) User-defined function to perform a
-      copy into mbuf; useful if any unusual data conversion is necessary.

-  
mb_udata

-  
(void *) User-supplied data which can be used in the
-      mb_copy function.

-

-
()
-    function disposes an mbuf chain pointed to by
-    mbp->mb_top field and sets the field to
-    NULL.

-
()
-    function returns the value of mbp->mb_top field and
-    sets its value to NULL.

-
()
-    recalculates the length of an mbuf chain and updates the
-    m_pkthdr.len field of the first mbuf in the chain. It
-    returns the calculated length.

-
()
-    ensures that the object of the length specified by the
-    size argument will fit in the current mbuf (mbuf
-    allocation is performed if necessary), and advances all pointers as if the
-    real data was placed. Returned value will point to the beginning of the
-    reserved space. Note that the size of the object should not exceed
-    MLEN bytes.

-
All
-    ()
-    functions perform an actual copy of the data into mbuf chain. Functions
-    which have le or be suffixes
-    will perform conversion to the little- or big-endian data formats.

-
()
-    function copies size bytes of data specified by the
-    source argument to an mbuf chain. The
-    type argument specifies the method used to perform a
-    copy, and can be one of the following:

-

-  

-  
Use
-      ()
-      function.

-  

-  
Use copyin(9) function.

-  

-  
Use an “inline” loop which does not call any function.

-  

-  
Do not copy any data, but just fill the destination with zero bytes.

-  

-  
Call function specified by the mbp->mb_copy
-      field.

-

-

-

-

-
All int functions except
-    mb_fixhdr() return zero if successful and an error
-    code otherwise.

-
:
-    after failure of any function, an mbuf chain is left in the broken state,
-    and only mb_done() function can safely be called to
-    destroy it.

-

-

-

-

-
struct mbchain *mbp;
-struct mbuf *m;
-
-mb_init(mbp);
-mb_put_uint8(mbp, 33);
-mb_put_uint16le(mbp, length);
-m = m_copym(mbp->mb_top, 0, M_COPYALL, M_WAIT);
-send(m);
-mb_done(mbp);

-

-

-

-

-
mbuf(9), mdchain(9)

-

-

-

-
This manual page was written by Boris
-    Popov
-    <bp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 20, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/mbuf.9 4.html b/static/freebsd/man9/mbuf.9 4.html
deleted file mode 100644
index de9adb99..00000000
--- a/static/freebsd/man9/mbuf.9 4.html	
+++ /dev/null
@@ -1,1032 +0,0 @@
-
-  
-    
-    
-    
-  
-
MBUF(9)Kernel Developer's ManualMBUF(9)

-

-

-

-
mbuf — memory
-    management in the kernel IPC subsystem

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/mbuf.h>

-

-

-
MGET(struct
-    mbuf *mbuf, int
-    how, short
-  type);

-
MGETHDR(struct
-    mbuf *mbuf, int
-    how, short
-  type);

-
int
-  

-  MCLGET(struct
-    mbuf *mbuf, int
-    how);

-
MEXTADD(struct mbuf
-    *mbuf, char *buf, u_int
-    size, void (*free)(struct mbuf *),
-    void *opt_arg1, void *opt_arg2,
-    int flags, int type);

-

-

-

-
type
-  

-  mtod(struct
-    mbuf *mbuf,
-  type);

-
void *
-  

-  mtodo(struct
-    mbuf *mbuf,
-    offset);

-
M_ALIGN(struct
-    mbuf *mbuf, u_int
-    len);

-
MH_ALIGN(struct
-    mbuf *mbuf, u_int
-    len);

-
int
-  

-  M_LEADINGSPACE(struct
-    mbuf *mbuf);

-
int
-  

-  M_TRAILINGSPACE(struct
-    mbuf *mbuf);

-
M_MOVE_PKTHDR(struct
-    mbuf *to, struct mbuf
-    *from);

-
M_PREPEND(struct
-    mbuf *mbuf, int
-    len, int how);

-
MCHTYPE(struct
-    mbuf *mbuf, short
-    type);

-
int
-  

-  M_WRITABLE(struct
-    mbuf *mbuf);

-

-

-

-
struct mbuf *
-  

-  m_get(int
-    how, short
-  type);

-
struct mbuf *
-  

-  m_get2(int
-    size, int how,
-    short type,
-    int flags);

-
struct mbuf *
-  

-  m_get3(int
-    size, int how,
-    short type,
-    int flags);

-
struct mbuf *
-  

-  m_getm(struct
-    mbuf *orig, int
-    len, int how,
-    short type);

-
struct mbuf *
-  

-  m_getjcl(int
-    how, short type,
-    int flags,
-    int size);

-
struct mbuf *
-  

-  m_getcl(int
-    how, short type,
-    int flags);

-
struct mbuf *
-  

-  m_gethdr(int
-    how, short
-  type);

-
struct mbuf *
-  

-  m_free(struct
-    mbuf *mbuf);

-
void
-  

-  m_freem(struct
-    mbuf *mbuf);

-

-

-

-
void
-  

-  m_adj(struct
-    mbuf *mbuf, int
-    len);

-
void
-  

-  m_align(struct
-    mbuf *mbuf, int
-    len);

-
int
-  

-  m_append(struct
-    mbuf *mbuf, int
-    len, c_caddr_t
-  cp);

-
struct mbuf *
-  

-  m_prepend(struct
-    mbuf *mbuf, int
-    len, int how);

-
struct mbuf *
-  

-  m_copyup(struct
-    mbuf *mbuf, int
-    len, int
-  dstoff);

-
struct mbuf *
-  

-  m_pullup(struct
-    mbuf *mbuf, int
-    len);

-
struct mbuf *
-  

-  m_pulldown(struct
-    mbuf *mbuf, int
-    offset, int len,
-    int *offsetp);

-
struct mbuf *
-  

-  m_copym(struct
-    mbuf *mbuf, int
-    offset, int len,
-    int how);

-
struct mbuf *
-  

-  m_copypacket(struct
-    mbuf *mbuf, int
-    how);

-
struct mbuf *
-  

-  m_dup(const
-    struct mbuf *mbuf, int
-    how);

-
void
-  

-  m_copydata(const
-    struct mbuf *mbuf, int
-    offset, int len,
-    caddr_t buf);

-
void
-  

-  m_copyback(struct
-    mbuf *mbuf, int
-    offset, int len,
-    caddr_t buf);

-
struct mbuf *
-  

-  m_devget(char *buf,
-    int len, int offset,
-    struct ifnet *ifp, void (*copy)(char
-    *from, caddr_t to, u_int len));

-
void
-  

-  m_cat(struct
-    mbuf *m, struct mbuf
-    *n);

-
void
-  

-  m_catpkt(struct
-    mbuf *m, struct mbuf
-    *n);

-
u_int
-  

-  m_fixhdr(struct
-    mbuf *mbuf);

-
int
-  

-  m_dup_pkthdr(struct
-    mbuf *to, const struct
-    mbuf *from, int
-    how);

-
void
-  

-  m_move_pkthdr(struct
-    mbuf *to, struct mbuf
-    *from);

-
u_int
-  

-  m_length(struct
-    mbuf *mbuf, struct mbuf
-    **last);

-
struct mbuf *
-  

-  m_split(struct
-    mbuf *mbuf, int
-    len, int how);

-
int
-  

-  m_apply(struct
-    mbuf *mbuf, int
-    off, int len,
-    int (*f)(void *arg, void *data,
-    u_int len), void
-    *arg);

-
struct mbuf *
-  

-  m_getptr(struct
-    mbuf *mbuf, int
-    loc, int *off);

-
struct mbuf *
-  

-  m_defrag(struct
-    mbuf *m0, int
-  how);

-
struct mbuf *
-  

-  m_collapse(struct
-    mbuf *m0, int how,
-    int maxfrags);

-
struct mbuf *
-  

-  m_unshare(struct
-    mbuf *m0, int
-  how);

-

-

-

-

-
An mbuf is a basic unit of memory management
-    in the kernel IPC subsystem. Network packets and socket buffers are stored
-    in mbufs. A network packet may span multiple
-    mbufs arranged into a mbuf chain
-    (linked list), which allows adding or trimming network headers with little
-    overhead.

-
While a developer should not bother with
-    mbuf internals without serious reason in order to
-    avoid incompatibilities with future changes, it is useful to understand the
-    general structure of an mbuf.

-
An mbuf consists of a variable-sized header
-    and a small internal buffer for data. The total size of an
-    mbuf, MSIZE, is a constant
-    defined in <sys/param.h>.
-    The mbuf header includes:

-

-

-  
m_next

-  
(struct mbuf *) A pointer to the next
-      mbuf in the mbuf chain.

-  
m_nextpkt

-  
(struct mbuf *) A pointer to the next
-      mbuf chain in the queue.

-  
m_data

-  
(caddr_t) A pointer to data attached to this
-      mbuf.

-  
m_len

-  
(int) The length of the data.

-  
m_type

-  
(short) The type of the data.

-  
m_flags

-  
(int) The mbuf flags.

-

-

-
The mbuf flag bits are defined as
-  follows:

-

-
#define	M_EXT		0x00000001 /* has associated external storage */
-#define	M_PKTHDR	0x00000002 /* start of record */
-#define	M_EOR		0x00000004 /* end of record */
-#define	M_RDONLY	0x00000008 /* associated data marked read-only */
-#define	M_BCAST		0x00000010 /* send/received as link-level broadcast */
-#define	M_MCAST		0x00000020 /* send/received as link-level multicast */
-#define	M_PROMISC	0x00000040 /* packet was not for us */
-#define	M_VLANTAG	0x00000080 /* ether_vtag is valid */
-#define	M_EXTPG		0x00000100 /* has array of unmapped pages and TLS */
-#define	M_NOFREE	0x00000200 /* do not free mbuf, embedded in cluster */
-#define	M_TSTMP		0x00000400 /* rcv_tstmp field is valid */
-#define	M_TSTMP_HPREC	0x00000800 /* rcv_tstmp is high-prec, typically
-				      hw-stamped on port (useful for IEEE 1588
-				      and 802.1AS) */
-
-#define	M_PROTO1	0x00001000 /* protocol-specific */
-#define	M_PROTO2	0x00002000 /* protocol-specific */
-#define	M_PROTO3	0x00004000 /* protocol-specific */
-#define	M_PROTO4	0x00008000 /* protocol-specific */
-#define	M_PROTO5	0x00010000 /* protocol-specific */
-#define	M_PROTO6	0x00020000 /* protocol-specific */
-#define	M_PROTO7	0x00040000 /* protocol-specific */
-#define	M_PROTO8	0x00080000 /* protocol-specific */
-#define	M_PROTO9	0x00100000 /* protocol-specific */
-#define	M_PROTO10	0x00200000 /* protocol-specific */
-#define	M_PROTO11	0x00400000 /* protocol-specific */
-#define	M_PROTO12	0x00800000 /* protocol-specific */

-

-
The available mbuf types are defined as
-    follows:

-

-
#define	MT_DATA		1	/* dynamic (data) allocation */
-#define	MT_HEADER	MT_DATA	/* packet header */
-
-#define	MT_VENDOR1	4	/* for vendor-internal use */
-#define	MT_VENDOR2	5	/* for vendor-internal use */
-#define	MT_VENDOR3	6	/* for vendor-internal use */
-#define	MT_VENDOR4	7	/* for vendor-internal use */
-
-#define	MT_SONAME	8	/* socket name */
-
-#define	MT_EXP1		9	/* for experimental use */
-#define	MT_EXP2		10	/* for experimental use */
-#define	MT_EXP3		11	/* for experimental use */
-#define	MT_EXP4		12	/* for experimental use */
-
-#define	MT_CONTROL	14	/* extra-data protocol message */
-#define	MT_EXTCONTROL	15	/* control message with externalized contents */
-#define	MT_OOBDATA	16	/* expedited data  */

-

-
The available external buffer types are defined as follows:

-

-
#define	EXT_CLUSTER	1	/* mbuf cluster */
-#define	EXT_SFBUF	2	/* sendfile(2)'s sf_bufs */
-#define	EXT_JUMBOP	3	/* jumbo cluster 4096 bytes */
-#define	EXT_JUMBO9	4	/* jumbo cluster 9216 bytes */
-#define	EXT_JUMBO16	5	/* jumbo cluster 16184 bytes */
-#define	EXT_PACKET	6	/* mbuf+cluster from packet zone */
-#define	EXT_MBUF	7	/* external mbuf reference */
-#define	EXT_RXRING	8	/* data in NIC receive ring */
-#define	EXT_PGS		9	/* array of unmapped pages */
-
-#define	EXT_VENDOR1	224	/* for vendor-internal use */
-#define	EXT_VENDOR2	225	/* for vendor-internal use */
-#define	EXT_VENDOR3	226	/* for vendor-internal use */
-#define	EXT_VENDOR4	227	/* for vendor-internal use */
-
-#define	EXT_EXP1	244	/* for experimental use */
-#define	EXT_EXP2	245	/* for experimental use */
-#define	EXT_EXP3	246	/* for experimental use */
-#define	EXT_EXP4	247	/* for experimental use */
-
-#define	EXT_NET_DRV	252	/* custom ext_buf provided by net driver(s) */
-#define	EXT_MOD_TYPE	253	/* custom module's ext_buf type */
-#define	EXT_DISPOSABLE	254	/* can throw this buffer away w/page flipping */
-#define	EXT_EXTREF	255	/* has externally maintained ref_cnt ptr */

-

-
If the M_PKTHDR flag is set, a
-    struct pkthdr m_pkthdr is added
-    to the mbuf header. It contains a pointer to the
-    interface the packet has been received from (struct
-    ifnet *rcvif), and the total packet length
-    (int len). Optionally, it may
-    also contain an attached list of packet tags (struct
-    m_tag). See mbuf_tags(9) for details. Fields used in
-    offloading checksum calculation to the hardware are kept in
-    m_pkthdr as well. See
-    HARDWARE-ASSISTED
-    CHECKSUM CALCULATION for details.

-
If small enough, data is stored in the internal data buffer of an
-    mbuf. If the data is sufficiently large, another
-    mbuf may be added to the mbuf
-    chain, or external storage may be associated with the
-    mbuf. MHLEN bytes of data can
-    fit into an mbuf with the
-    M_PKTHDR flag set, MLEN
-    bytes can otherwise.

-
If external storage is being associated with an
-    mbuf, the m_ext header is added
-    at the cost of losing the internal data buffer. It includes a pointer to
-    external storage, the size of the storage, a pointer to a function used for
-    freeing the storage, a pointer to an optional argument that can be passed to
-    the function, and a pointer to a reference counter. An
-    mbuf using external storage has the
-    M_EXT flag set.

-
The system supplies a macro for allocating the desired external
-    storage buffer, MEXTADD.

-
The allocation and management of the reference counter is handled
-    by the subsystem.

-
The system also supplies a default type of external storage buffer
-    called an mbuf cluster. Mbuf
-    clusters can be allocated and configured with the use of the
-    MCLGET macro. Each mbuf
-    cluster is MCLBYTES in size, where MCLBYTES is
-    a machine-dependent constant. The system defines an advisory macro
-    MINCLSIZE, which is the smallest amount of data to
-    put into an mbuf cluster. It is equal to
-    MHLEN plus one. It is typically preferable to store
-    data into the data region of an mbuf, if size permits,
-    as opposed to allocating a separate mbuf cluster to
-    hold the same data.

-

-

-
There are numerous predefined macros and functions that provide
-    the developer with common utilities.

-

-  
(mbuf,
-    type)

-  
Convert an mbuf pointer to a data pointer. The macro
-      expands to the data pointer cast to the specified
-      type. Note: It is advisable to
-      ensure that there is enough contiguous data in mbuf.
-      See
-      ()
-      for details.

-  
(mbuf,
-    offset)

-  
Return a data pointer at an offset (in bytes) into the data attached to
-      mbuf. Returns a void * pointer
-      . Note: The caller must ensure that the offset is in
-      bounds of the attached data.

-  
MGET(mbuf,
-    how, type)

-  
Allocate an mbuf and initialize it to contain
-      internal data. mbuf will point to the allocated
-      mbuf on success, or be set to
-      NULL on failure. The how
-      argument is to be set to M_WAITOK or
-      M_NOWAIT. It specifies whether the caller is
-      willing to block if necessary. A number of other functions and macros
-      related to mbufs have the same argument because they
-      may at some point need to allocate new mbufs.

-  
(mbuf,
-    how, type)

-  
Allocate an mbuf and initialize it to contain a
-      packet header and internal data. See MGET() for
-      details.

-  
(mbuf,
-    buf, size,
-    free, opt_arg1,
-    opt_arg2, flags,
-    type)

-  
Associate externally managed data with mbuf. Any
-      internal data contained in the mbuf will be discarded, and the
-      M_EXT flag will be set. The
-      buf and size arguments are the
-      address and length, respectively, of the data. The
-      free argument points to a function which will be
-      called to free the data when the mbuf is freed; it is only used if
-      type is EXT_EXTREF. The
-      opt_arg1 and opt_arg2
-      arguments will be saved in ext_arg1 and
-      ext_arg2 fields of the struct
-      m_ext of the mbuf. The flags argument
-      specifies additional mbuf flags; it is not necessary
-      to specify M_EXT. Finally, the
-      type argument specifies the type of external data,
-      which controls how it will be disposed of when the
-      mbuf is freed. In most cases, the correct value is
-      EXT_EXTREF.

-  
(mbuf,
-    how)

-  
Allocate and attach an mbuf cluster to
-      mbuf. On success, a non-zero value returned;
-      otherwise, 0. Historically, consumers would check for success by testing
-      the M_EXT flag on the mbuf, but this is now
-      discouraged to avoid unnecessary awareness of the implementation of
-      external storage in protocol stacks and device drivers.

-  
(mbuf,
-    len)

-  
Set the pointer mbuf->m_data to place an object
-      of the size len at the end of the internal data area
-      of mbuf, long word aligned. Applicable only if
-      mbuf is newly allocated with
-      MGET() or m_get().

-  
(mbuf,
-    len)

-  
Serves the same purpose as M_ALIGN() does, but
-      only for mbuf newly allocated with
-      MGETHDR() or m_gethdr(),
-      or initialized by
-      ()
-      or
-      ().

-  
(mbuf,
-    len)

-  
Services the same purpose as M_ALIGN() but handles
-      any type of mbuf.

-  
(mbuf)

-  
Returns the number of bytes available before the beginning of data in
-      mbuf.

-  
(mbuf)

-  
Returns the number of bytes available after the end of data in
-      mbuf.

-  
(mbuf,
-    len, how)

-  
This macro operates on an mbuf chain. It is an
-      optimized wrapper for m_prepend() that can make
-      use of possible empty space before data (e.g. left after trimming of a
-      link-layer header). The new mbuf chain pointer or
-      NULL is in mbuf after the
-      call.

-  
(to,
-    from)

-  
Using this macro is equivalent to calling
-      m_move_pkthdr(to,
-      from).

-  
(mbuf)

-  
This macro will evaluate true if mbuf is not marked
-      M_RDONLY and if either mbuf
-      does not contain external storage or, if it does, then if the reference
-      count of the storage is not greater than 1. The
-      M_RDONLY flag can be set in
-      mbuf->m_flags. This can be achieved during setup
-      of the external storage, by passing the M_RDONLY
-      bit as a flags argument to the
-      MEXTADD() macro, or can be directly set in
-      individual mbufs.

-  
(mbuf,
-    type)

-  
Change the type of mbuf to
-      type. This is a relatively expensive operation and
-      should be avoided.

-

-
The functions are:

-

-  
(how,
-    type)

-  
A function version of
-      ()
-      for non-critical paths.

-  
(size,
-    how, type,
-    flags)

-  
Allocate an mbuf with enough space to hold specified
-      amount of data. If the size is larger than
-      MJUMPAGESIZE, NULL will be
-      returned.

-  
(size,
-    how, type,
-    flags)

-  
Allocate an mbuf with enough space to hold specified
-      amount of data. If the size is larger than MJUM16BYTES,
-      NULL will be returned.

-  
(orig,
-    len, how,
-    type)

-  
Allocate len bytes worth of
-      mbufs and mbuf clusters if
-      necessary and append the resulting allocated mbuf
-      chain to the mbuf chain
-      orig, if it is
-      non-NULL. If the
-      allocation fails at any point, free whatever was allocated and return
-      NULL. If orig is
-      non-NULL, it will not be
-      freed. It is possible to use m_getm() to either
-      append len bytes to an existing
-      mbuf or mbuf chain (for
-      example, one which may be sitting in a pre-allocated ring) or to simply
-      perform an all-or-nothing mbuf and
-      mbuf cluster allocation.

-  
(how,
-    type)

-  
A function version of MGETHDR() for non-critical
-      paths.

-  
(how,
-    type, flags)

-  
Fetch an mbuf with a mbuf
-      cluster attached to it. If one of the allocations fails, the entire
-      allocation fails. This routine is the preferred way of fetching both the
-      mbuf and mbuf cluster
-      together, as it avoids having to unlock/relock between allocations.
-      Returns NULL on failure.

-  
(how,
-    type, flags,
-    size)

-  
This is like m_getcl() but the specified
-      size of the cluster to be allocated must be one of
-      MCLBYTES, MJUMPAGESIZE,
-      MJUM9BYTES, or
-      MJUM16BYTES.

-  
(mbuf)

-  
Frees mbuf. Returns m_next of
-      the freed mbuf.

-

-
The functions below operate on mbuf
-  chains.

-

-  
(mbuf)

-  
Free an entire mbuf chain, including any external
-      storage.

-  
(mbuf,
-    len)

-  
Trim len bytes from the head of an
-      mbuf chain if len is positive,
-      from the tail otherwise.

-  
(mbuf,
-    len, cp)

-  
Append len bytes of data cp to
-      the mbuf chain. Extend the mbuf chain if the new
-      data does not fit in existing space.

-  
(mbuf,
-    len, how)

-  
Allocate a new mbuf and prepend it to the
-      mbuf chain, handle M_PKTHDR
-      properly. Note: It does not allocate any
-      mbuf clusters, so len must be
-      less than MLEN or MHLEN,
-      depending on the M_PKTHDR flag setting.

-  
(mbuf,
-    len, dstoff)

-  
Similar to m_pullup() but copies
-      len bytes of data into a new mbuf at
-      dstoff bytes into the mbuf. The
-      dstoff argument aligns the data and leaves room for
-      a link layer header. Returns the new mbuf chain on
-      success, and frees the mbuf chain and returns
-      NULL on failure. Note: The
-      function does not allocate mbuf clusters, so
-      len + dstoff must be less than
-      MHLEN.

-  
m_pullup(mbuf,
-    len)

-  
Arrange that the first len bytes of an
-      mbuf chain are contiguous and lay in the data area
-      of mbuf, so they are accessible with
-      mtod(mbuf,
-      type). It is important to remember that this may
-      involve reallocating some mbufs and moving data so all pointers
-      referencing data within the old mbuf chain must be recalculated or made
-      invalid. Return the new mbuf chain on success,
-      NULL on failure (the mbuf
-      chain is freed in this case). Note: It does not
-      allocate any mbuf clusters, so
-      len must be less than or equal to
-      MHLEN.

-  
(mbuf,
-    offset, len,
-    offsetp)

-  
Arrange that len bytes between
-      offset and offset + len in the
-      mbuf chain are contiguous and lay in the data area
-      of mbuf, so they are accessible with
-      mtod() or mtodo().
-      len must be smaller than, or equal to, the size of
-      an mbuf cluster. Return a pointer to an intermediate
-      mbuf in the chain containing the requested region;
-      the offset in the data region of the mbuf chain to
-      the data contained in the returned mbuf is stored in
-      *offsetp. If offsetp is NULL,
-      the region may be accessed using
-      mtod(mbuf,
-      type) or
-      mtodo(mbuf,
-      0). If offsetp is non-NULL,
-      the region may be accessed using
-      mtodo(mbuf,
-      *offsetp). The region of the mbuf chain between its
-      beginning and offset is not modified, therefore it
-      is safe to hold pointers to data within this region before calling
-      m_pulldown().

-  
(mbuf,
-    offset, len,
-    how)

-  
Make a copy of an mbuf chain starting
-      offset bytes from the beginning, continuing for
-      len bytes. If len is
-      M_COPYALL, copy to the end of the
-      mbuf chain. Note: The copy is
-      read-only, because the mbuf clusters are not copied,
-      only their reference counts are incremented.

-  
(mbuf,
-    how)

-  
Copy an entire packet including header, which must be present. This is an
-      optimized version of the common case
-      m_copym(mbuf,
-      0, M_COPYALL,
-      how). Note: the copy is read-only,
-      because the mbuf clusters are not copied, only their
-      reference counts are incremented.

-  
(mbuf,
-    how)

-  
Copy a packet header mbuf chain into a completely
-      new mbuf chain, including copying any
-      mbuf clusters. Use this instead of
-      m_copypacket() when you need a writable copy of an
-      mbuf chain.

-  
(mbuf,
-    offset, len,
-    buf)

-  
Copy data from an mbuf chain starting
-      off bytes from the beginning, continuing for
-      len bytes, into the indicated buffer
-      buf.

-  
(mbuf,
-    offset, len,
-    buf)

-  
Copy len bytes from the buffer
-      buf back into the indicated mbuf
-      chain, starting at offset bytes from the
-      beginning of the mbuf chain, extending the
-      mbuf chain if necessary. Note: It
-      does not allocate any mbuf clusters, just adds
-      mbufs to the mbuf chain. It is
-      safe to set offset beyond the current
-      mbuf chain end: zeroed mbufs
-      will be allocated to fill the space.

-  
(mbuf,
-    last)

-  
Return the length of the mbuf chain, and optionally
-      a pointer to the last mbuf.

-  
m_dup_pkthdr(to,
-    from, how)

-  
Upon the function's completion, the mbuf
-      to will contain an identical copy of
-      from->m_pkthdr and the per-packet attributes
-      found in the mbuf chain from.
-      The mbuf from must have the
-      flag M_PKTHDR initially set, and
-      to must be empty on entry.

-  
m_move_pkthdr(to,
-    from)

-  
Move m_pkthdr and the per-packet attributes from the
-      mbuf chain from to the
-      mbuf to. The
-      mbuf from must have the flag
-      M_PKTHDR initially set, and
-      to must be empty on entry. Upon the function's
-      completion, from will have the flag
-      M_PKTHDR and the per-packet attributes
-    cleared.

-  
(mbuf)

-  
Set the packet-header length to the length of the mbuf
-      chain.

-  
(buf,
-    len, offset,
-    ifp, copy)

-  
Copy data from a device local memory pointed to by
-      buf to an mbuf chain. The copy
-      is done using a specified copy routine copy, or
-      ()
-      if copy is NULL.

-  
(m,
-    n)

-  
Concatenate n to m. Both
-      mbuf chains must be of the same type.
-      n is not guaranteed to be valid after
-      m_cat() returns. m_cat()
-      does not update any packet header fields or free mbuf tags.

-  
(m,
-    n)

-  
A variant of m_cat() that operates on packets.
-      Both m and n must contain
-      packet headers. n is not guaranteed to be valid
-      after m_catpkt() returns.

-  
(mbuf,
-    len, how)

-  
Partition an mbuf chain in two pieces, returning the
-      tail: all but the first len bytes. In case of
-      failure, it returns NULL and attempts to restore
-      the mbuf chain to its original state.

-  
m_apply(mbuf,
-    off, len,
-    f, arg)

-  
Apply a function to an mbuf chain, at offset
-      off, for length len bytes.
-      Typically used to avoid calls to m_pullup() which
-      would otherwise be unnecessary or undesirable. arg
-      is a convenience argument which is passed to the callback function
-      f.
-    
Each time
-        () is
-        called, it will be passed arg, a pointer to the
-        data in the current mbuf, and the length
-        len of the data in this mbuf to which the function
-        should be applied.

-    
The function should return zero to indicate
-        success; otherwise, if an error is indicated, then
-        ()
-        will return the error and stop iterating through the
-        mbuf chain.

-  

-  
(mbuf,
-    loc, off)

-  
Return a pointer to the mbuf containing the data located at
-      loc bytes from the beginning of the
-      mbuf chain. The corresponding offset into the mbuf
-      will be stored in *off.

-  
m_defrag(m0,
-    how)

-  
Defragment an mbuf chain, returning the shortest possible chain of mbufs
-      and clusters. If allocation fails and this can not be completed,
-      NULL will be returned and the original chain will
-      be unchanged. Upon success, the original chain will be freed and the new
-      chain will be returned. how should be either
-      M_WAITOK or M_NOWAIT,
-      depending on the caller's preference.
-    
This function is especially useful in network drivers, where
-        certain long mbuf chains must be shortened before being added to TX
-        descriptor lists.

-  

-  
(m0,
-    how, maxfrags)

-  
Defragment an mbuf chain, returning a chain of at most
-      maxfrags mbufs and clusters. If allocation fails or
-      the chain cannot be collapsed as requested, NULL
-      will be returned, with the original chain possibly modified. As with
-      (),
-      how should be one of
-      M_WAITOK or M_NOWAIT.

-  
(m0,
-    how)

-  
Create a version of the specified mbuf chain whose contents can be safely
-      modified without affecting other users. If allocation fails and this
-      operation can not be completed, NULL will be
-      returned. The original mbuf chain is always reclaimed and the reference
-      count of any shared mbuf clusters is decremented.
-      how should be either
-      M_WAITOK or M_NOWAIT,
-      depending on the caller's preference. As a side-effect of this process the
-      returned mbuf chain may be compacted.
-    
This function is especially useful in the transmit path of
-        network code, when data must be encrypted or otherwise altered prior to
-        transmission.

-  

-

-

-

-

-

-
This section currently applies to SCTP, TCP, and UDP over IP only.
-    In order to save the host CPU resources, computing checksums is offloaded to
-    the network interface hardware if possible. The
-    m_pkthdr member of the leading
-    mbuf of a packet contains two fields used for that
-    purpose, int csum_flags and
-    int csum_data. The meaning of
-    those fields depends on whether the packet is fragmented. Henceforth,
-    csum_flags or csum_data of a
-    packet will denote the corresponding field of the
-    m_pkthdr member of the leading
-    mbuf in the mbuf chain
-    containing the packet.

-
When a packet is sent by SCTP, TCP, or UDP, the computation of the
-    checksum is delayed until the outgoing interface has been determined for a
-    packet. The interface-specific field
-    ifnet.if_data.ifi_hwassist (see
-    ifnet(9)) is consulted by IP for the capabilities of the
-    network interface selected for output to assist in computing checksums. The
-    csum_flags field of the packet header is set to
-    indicate which actions the interface is supposed to perform on it. The
-    actions unsupported by the network interface are done in the software prior
-    to passing the packet down to the interface driver; such actions will never
-    be requested through csum_flags.

-
The flags demanding a particular action from an interface are as
-    follows:

-

-

-  

-  
The IP header checksum is to be computed and stored in the corresponding
-      field of the packet. The hardware is expected to know the format of an IP
-      header to determine the offset of the IP checksum field.

-  

-  
The SCTP checksum is to be computed. (See below.)

-  

-  
The TCP checksum is to be computed. (See below.)

-  

-  
The UDP checksum is to be computed. (See below.)

-

-

-
Should a SCTP, TCP, or UDP checksum be offloaded to the hardware,
-    the field csum_data will contain the byte offset of
-    the checksum field relative to the end of the IP header. In the case of TCP
-    or UDP, the checksum field will be initially set by the TCP or UDP
-    implementation to the checksum of the pseudo header defined by the TCP and
-    UDP specifications. In the case of SCTP, the checksum field will be
-    initially set by the SCTP implementation to 0.

-
When a packet is received by an interface, it indicates the
-    actions it has performed on a packet by setting one or more of the following
-    flags in csum_flags associated with the packet:

-

-

-  

-  
The IP header checksum has been computed.

-  

-  
The IP header has a valid checksum. This flag can appear only in
-      combination with CSUM_IP_CHECKED.

-  

-  
The checksum of the data portion of the IP packet has been computed and
-      stored in the field csum_data in network byte
-    order.

-  

-  
Can be set only along with CSUM_DATA_VALID to
-      indicate that the IP data checksum found in
-      csum_data allows for the pseudo header defined by
-      the TCP and UDP specifications. Otherwise the checksum of the pseudo
-      header must be calculated by the host CPU and added to
-      csum_data to obtain the final checksum to be used
-      for TCP or UDP validation purposes.

-

-

-
If a particular network interface just indicates success or
-    failure of SCTP, TCP, or UDP checksum validation without returning the exact
-    value of the checksum to the host CPU, its driver can mark
-    CSUM_DATA_VALID in csum_flags
-    as well as, for TCP and UDP, CSUM_PSEUDO_HDR and set
-    csum_data to 0xFFFF
-    hexadecimal to indicate a valid checksum. It is a peculiarity of the
-    algorithm used that the Internet checksum calculated over any valid packet
-    will be 0xFFFF as long as the original checksum
-    field is included. Note that for SCTP the value of
-    csum_data is not relevant and
-    CSUM_PSEUDO_HDR in csum_flags
-    is not set, since SCTP does not use a pseudo header checksum.

-
If IP delivers a packet with the flags
-    CSUM_IP, CSUM_SCTP,
-    CSUM_TCP, or CSUM_UDP set in
-    csum_flags to a local IP, SCTP, TCP, or UDP stack, the
-    packet will be processed without computing or validating the checksum, since
-    the packet has not been on the wire. This can happen if the packet was
-    handled by a virtual interface such as tap(4) or
-    epair(4).

-

-

-

-
When running a kernel compiled with the option
-    MBUF_STRESS_TEST, the following
-    sysctl(8)-controlled options may be used to create various
-    failure/extreme cases for testing of network drivers and other parts of the
-    kernel that rely on mbufs.

-

-  
net.inet.ip.mbuf_frag_size

-  
Causes
-      ()
-      to fragment outgoing mbuf chains into fragments of
-      the specified size. Setting this variable to 1 is an excellent way to test
-      the long mbuf chain handling ability of network
-      drivers.

-  
kern.ipc.m_defragrandomfailures

-  
Causes the function
-      ()
-      to randomly fail, returning NULL. Any piece of
-      code which uses m_defrag() should be tested with
-      this feature.

-

-

-

-

-
See above.

-

-

-

-
ifnet(9), mbuf_tags(9)

-
S. J. Leffler,
-    W. N. Joy, R. S. Fabry,
-    and M. J. Karels, Networking
-    Implementation Notes, 4.4BSD System Manager's Manual
-    (SMM).

-

-

-

-
Mbufs appeared in an early version of
-    BSD. Besides being used for network packets, they
-    were used to store various dynamic structures, such as routing table
-    entries, interface addresses, protocol control blocks, etc. In more recent
-    FreeBSD use of mbufs is almost
-    entirely limited to packet storage, with uma(9) zones
-    being used directly to store other network-related memory.

-
Historically, the mbuf allocator has been a
-    special-purpose memory allocator able to run in interrupt contexts and
-    allocating from a special kernel address space map. As of
-    FreeBSD 5.3, the mbuf
-    allocator is a wrapper around uma(9), allowing caching of
-    mbufs, clusters, and mbuf +
-    cluster pairs in per-CPU caches, as well as bringing other benefits of slab
-    allocation.

-

-

-

-
The original mbuf manual page was written
-    by Yar Tikhiy. The uma(9)
-    mbuf allocator was written by
-  

-  Bosko Milekic.

-

-

-
-  
-    
-    
-  
-
January 20, 2026FreeBSD 15.0

diff --git a/static/freebsd/man9/mbuf_tags.9 4.html b/static/freebsd/man9/mbuf_tags.9 4.html
deleted file mode 100644
index aac5e5f6..00000000
--- a/static/freebsd/man9/mbuf_tags.9 4.html	
+++ /dev/null
@@ -1,262 +0,0 @@
-
-  
-    
-    
-    
-  
-
MBUF_TAGS(9)Kernel Developer's ManualMBUF_TAGS(9)

-

-

-

-
mbuf_tags — a
-    framework for generic packet attributes

-

-

-

-
#include
-    <sys/mbuf.h>

-
struct m_tag *
-  

-  m_tag_alloc(uint32_t
-    cookie, uint16_t
-    type, int len,
-    int wait);

-
struct m_tag *
-  

-  m_tag_copy(struct
-    m_tag *t, int
-  how);

-
int
-  

-  m_tag_copy_chain(struct
-    mbuf *to, const struct
-    mbuf *from, int
-    how);

-
void
-  

-  m_tag_delete(struct
-    mbuf *m, struct m_tag
-    *t);

-
void
-  

-  m_tag_delete_chain(struct
-    mbuf *m, struct m_tag
-    *t);

-
void
-  

-  m_tag_delete_nonpersistent(struct
-    mbuf *m);

-
struct m_tag *
-  

-  m_tag_find(struct
-    mbuf *m, uint16_t
-    type, struct m_tag
-    *start);

-
struct m_tag *
-  

-  m_tag_first(struct
-    mbuf *m);

-
void
-  

-  m_tag_free(struct
-    m_tag *t);

-
struct m_tag *
-  

-  m_tag_get(uint16_t
-    type, int len,
-    int wait);

-
void
-  

-  m_tag_init(struct
-    mbuf *m);

-
struct m_tag *
-  

-  m_tag_locate(struct
-    mbuf *m, uint32_t
-    cookie, uint16_t
-    type, struct m_tag
-    *t);

-
struct m_tag *
-  

-  m_tag_next(struct
-    mbuf *m, struct m_tag
-    *t);

-
void
-  

-  m_tag_prepend(struct
-    mbuf *m, struct m_tag
-    *t);

-
void
-  

-  m_tag_unlink(struct
-    mbuf *m, struct m_tag
-    *t);

-

-

-

-
Mbuf tags allow additional meta-data to be associated with
-    in-flight packets by providing a mechanism for the tagging of additional
-    kernel memory onto packet header mbufs. Tags are maintained in chains off of
-    the mbuf(9) header, and maintained using a series of API
-    calls to allocate, search, and delete tags. Tags are identified using an ID
-    and cookie that uniquely identify a class of data tagged onto the packet,
-    and may contain an arbitrary amount of additional storage. Typical uses of
-    mbuf tags include Mandatory Access Control (MAC) labels as described in
-    mac(9), IPsec policy information as described in
-    ipsec(4), and packet filter tags used by
-    pf(4).

-
Tags will be maintained across a variety of
-    operations, including the copying of packet headers using facilities such as
-    ()
-    and
-    ().
-    Any tags associated with an mbuf header will be automatically freed when the
-    mbuf is freed, although some subsystems will wish to delete the tags prior
-    to that time.

-
Packet tags are used by different kernel APIs to keep track of
-    operations done or scheduled to happen to packets. Each packet tag can be
-    distinguished by its type and cookie. The cookie is used to identify a
-    specific module or API. The packet tags are attached to mbuf packet
-  headers.

-
The first
-    (struct
-    m_tag) bytes of a tag contain a struct
-  m_tag:

-

-
struct m_tag {
-	SLIST_ENTRY(m_tag)	m_tag_link;	/* List of packet tags */
-	uint16_t		m_tag_id;	/* Tag ID */
-	uint16_t		m_tag_len;	/* Length of data */
-	uint32_t		m_tag_cookie;	/* ABI/Module ID */
-	void			(*m_tag_free)(struct m_tag *);
-};

-

-
The m_tag_link field
-    is used to link tags together (see queue(3) for more
-    details). The m_tag_id,
-    m_tag_len and m_tag_cookie
-    fields are set to type, length, and cookie, respectively.
-    m_tag_free points to
-    ().
-    Following this structure are m_tag_len bytes of space
-    that can be used to store tag-specific information. Addressing this data
-    region may be tricky. A safe way is embedding struct
-    m_tag into a private data structure, as follows:

-

-
struct foo {
-	struct m_tag	tag;
-	...
-};
-struct foo *p = (struct foo *)m_tag_alloc(...);
-struct m_tag *mtag = &p->tag;

-

-
Note that OpenBSD does not support
-    cookies, it needs m_tag_id to be globally unique. To
-    keep compatibility with OpenBSD, a cookie
-    MTAG_ABI_COMPAT is provided along with some
-    compatibility functions. When writing an OpenBSD
-    compatible code, one should be careful not to take already used tag type.
-    Tag types are defined in
-    <sys/mbuf.h>.

-

-

-

-  
(cookie,
-    type, len,
-    wait)

-  
Allocate a new tag of type type and cookie
-      cookie with len bytes of space
-      following the tag header itself. The wait argument
-      is passed directly to malloc(9). If successful,
-      m_tag_alloc() returns a memory buffer of
-      (len +
-      sizeof(struct m_tag)) bytes.
-      Otherwise, NULL is returned. A compatibility
-      function
-      ()
-      is also provided.

-  
(tag,
-    how)

-  
Allocate a copy of tag. The
-      how argument is passed directly to
-      m_tag_alloc(). The return values are the same as
-      in m_tag_alloc().

-  
(tombuf,
-    frommbuf, how)

-  
Allocate and copy all tags from mbuf frommbuf to
-      mbuf tombuf. Returns 1 on success, and 0 on failure.
-      In the latter case, mbuf tombuf loses all its tags,
-      even previously present.

-  
(mbuf,
-    tag)

-  
Remove tag from mbuf's list
-      and free it.

-  
(mbuf,
-    tag)

-  
Remove and free a packet tag chain, starting from
-      tag. If tag is
-      NULL, all tags are deleted.

-  
(mbuf)

-  
Traverse mbuf's tags and delete those which do not
-      have the MTAG_PERSISTENT flag set.

-  
(mbuf)

-  
Return the first tag associated with mbuf.

-  
(tag)

-  
Free tag using its m_tag_free
-      method. The m_tag_free_default() function is used
-      by default.

-  
(mbuf)

-  
Initialize the tag storage for packet mbuf.

-  
(mbuf,
-    cookie, type,
-    tag)

-  
Search for a tag defined by type and
-      cookie in mbuf, starting from
-      position specified by tag. If the latter is
-      NULL, then search through the whole list. Upon
-      success, a pointer to the first found tag is returned. In either case,
-      NULL is returned. A compatibility function
-      ()
-      is also provided.

-  
(mbuf,
-    tag)

-  
Return tag next to tag in
-      mbuf. If absent, NULL is
-      returned.

-  
(mbuf,
-    tag)

-  
Add the new tag tag at the head of the tag list for
-      packet mbuf.

-  
-  
Remove tag tag from the list of tags of packet
-      mbuf.

-

-

-

-

-

-
The tag-manipulating code is contained in the file
-    sys/kern/uipc_mbuf2.c. Inlined functions are defined
-    in <sys/mbuf.h>.

-

-

-

-
queue(3), mbuf(9)

-

-

-

-
The packet tags first appeared in OpenBSD
-    2.9 and were written by Angelos D. Keromytis
-    <angelos@openbsd.org>.

-

-

-
-  
-    
-    
-  
-
December 28, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/mdchain.9 4.html b/static/freebsd/man9/mdchain.9 4.html
deleted file mode 100644
index 4866652a..00000000
--- a/static/freebsd/man9/mdchain.9 4.html	
+++ /dev/null
@@ -1,229 +0,0 @@
-
-  
-    
-    
-    
-  
-
MDCHAIN(9)Kernel Developer's ManualMDCHAIN(9)

-

-

-

-
mdchain, md_initm,
-    md_done, md_append_record,
-    md_next_record,
-    md_get_uint8, md_get_uint16,
-    md_get_uint16be,
-    md_get_uint16le,
-    md_get_uint32,
-    md_get_uint32be,
-    md_get_uint32le,
-    md_get_int64,
-    md_get_int64be,
-    md_get_int64le, md_get_mem,
-    md_get_mbuf, md_get_uio
-    — set of functions to dissect an mbuf chain to
-    various data types

-

-

-

-
options LIBMCHAIN kldload
-    libmchain

-

-  

-  #include <sys/param.h>
-  

-  #include <sys/uio.h>
-  

-  #include <sys/mchain.h>

-
void
-  

-  md_initm(struct
-    mdchain *mdp, struct mbuf
-    *m);

-
void
-  

-  md_done(struct
-    mdchain *mdp);

-
void
-  

-  md_append_record(struct
-    mdchain *mdp, struct mbuf
-    *top);

-
int
-  

-  md_next_record(struct
-    mdchain *mdp);

-
int
-  

-  md_get_uint8(struct
-    mdchain *mdp, uint8_t
-    *x);

-
int
-  

-  md_get_uint16(struct
-    mdchain *mdp, uint16_t
-    *x);

-
int
-  

-  md_get_uint16be(struct
-    mdchain *mdp, uint16_t
-    *x);

-
int
-  

-  md_get_uint16le(struct
-    mdchain *mdp, uint16_t
-    *x);

-
int
-  

-  md_get_uint32(struct
-    mdchain *mdp, uint32_t
-    *x);

-
int
-  

-  md_get_uint32be(struct
-    mdchain *mdp, uint32_t
-    *x);

-
int
-  

-  md_get_uint32le(struct
-    mdchain *mdp, uint32_t
-    *x);

-
int
-  

-  md_get_int64(struct
-    mdchain *mdp, int64_t
-    *x);

-
int
-  

-  md_get_int64be(struct
-    mdchain *mdp, int64_t
-    *x);

-
int
-  

-  md_get_int64le(struct
-    mdchain *mdp, int64_t
-    *x);

-
int
-  

-  md_get_mem(struct
-    mdchain *mdp, caddr_t
-    target, int size,
-    int type);

-
int
-  

-  md_get_mbuf(struct
-    mdchain *mdp, int
-    size, struct mbuf
-    **m);

-
int
-  

-  md_get_uio(struct
-    mdchain *mdp, struct uio
-    *uiop, int
-  size);

-

-

-

-
These functions are used to decompose mbuf chains to various data
-    types. The mdchain structure is used as a working
-    context and should be initialized through a call of the
-    ()
-    function. It has the following fields:

-

-  
md_top

-  
(struct mbuf *) A pointer to the top of the parsed
-      mbuf chain.

-  
md_cur

-  
(struct mbuf *) A pointer to the currently parsed
-      mbuf.

-  
md_pas

-  
(int) Offset in the current mbuf.

-

-
The
-    ()
-    function disposes of an mbuf chain pointed to by the
-    mdp->md_top field and sets the field to
-    NULL.

-
The
-    ()
-    appends a new mbuf chain using m_nextpkt field to form
-    a single linked list of mbuf chains. If the
-    mdp->md_top field is NULL,
-    then this function behaves exactly as the
-    ()
-    function.

-
The
-    ()
-    function extracts the next mbuf chain and disposes the current one, if any.
-    For a new mbuf chain it calls the
-    ()
-    function. If there is no data left the function returns
-    ENOENT.

-
All
-    ()
-    functions perform an actual copy of the data from an mbuf chain. Functions
-    which have le or be suffixes
-    will perform conversion to the little- or big-endian data formats.

-
()
-    function copies size bytes of data specified by the
-    source argument from an mbuf chain. The
-    type argument specifies the method used to perform a
-    copy, and can be one of the following:

-

-  

-  
Use the
-      ()
-      function.

-  

-  
Use the copyin(9) function.

-  

-  
Use an “inline” loop which does not call any function.

-

-
If target is NULL,
-    an actual copy is not performed and the function just skips the given number
-    of bytes.

-

-

-

-
All int functions return zero if successful,
-    otherwise an error code is returned.

-
:
-    after failure of any function, an mbuf chain is left in the broken state and
-    only the md_done() function can safely be called to
-    destroy it.

-

-

-

-

-
struct mdchain *mdp;
-struct mbuf *m;
-uint16_t length;
-uint8_t byte;
-
-receive(so, &m);
-md_initm(mdp, m);
-if (md_get_uint8(mdp, &byte) != 0 ||
-    md_get_uint16le(mdp, &length) != 0)
-	error = EBADRPC;
-mb_done(mdp);

-

-

-

-

-
mbchain(9), mbuf(9)

-

-

-

-
This manual page was written by Boris
-    Popov
-    <bp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 28, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/memcchr.9 4.html b/static/freebsd/man9/memcchr.9 4.html
deleted file mode 100644
index 4dbb5109..00000000
--- a/static/freebsd/man9/memcchr.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEMCCHR(9)Kernel Developer's ManualMEMCCHR(9)

-

-

-

-
memcchr — locate
-    the complement of a byte in byte string

-

-

-

-
#include
-    <sys/libkern.h>

-
void *
-  

-  memcchr(const
-    void *b, int c,
-    size_t len);

-

-

-

-
The
-    ()
-    function locates the first occurrence of a byte unequal to
-    c (converted to an unsigned
-    char) in string b.

-

-

-

-
The memcchr() function returns a pointer
-    to the byte located, or NULL if no such byte exists within
-    len bytes.

-

-

-

-
memchr(3)

-

-

-

-
The memcchr() function first appeared in
-    FreeBSD 10.0.

-

-

-
-  
-    
-    
-  
-
January 1, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/memguard.9 3.html b/static/freebsd/man9/memguard.9 3.html
deleted file mode 100644
index 8ba31e90..00000000
--- a/static/freebsd/man9/memguard.9 3.html	
+++ /dev/null
@@ -1,135 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEMGUARD(9)Kernel Developer's ManualMEMGUARD(9)

-

-

-

-
MemGuard — memory
-    allocator for debugging purposes

-

-

-

-
options DEBUG_MEMGUARD

-

-

-

-
MemGuard is a simple and small replacement
-    memory allocator designed to help detect tamper-after-free scenarios. These
-    problems are more and more common and likely with multithreaded kernels
-    where race conditions are more prevalent.

-
MemGuard can take over
-    (),
-    ()
-    and
-    ()
-    for a single malloc type. Alternatively MemGuard can
-    take over
-    (),
-    ()
-    and
-    ()
-    for a single uma(9) zone. Also
-    MemGuard can guard all allocations larger than
-    PAGE_SIZE, and can guard a random fraction of all
-    allocations. There is also a knob to prevent allocations smaller than a
-    specified size from being guarded, to limit memory waste.

-

-

-

-
To use MemGuard for a memory type, either
-    add an entry to /boot/loader.conf:

-

-
vm.memguard.desc=<memory_type>

-

-
Or set the vm.memguard.desc
-    sysctl(8) variable at run-time:

-

-
sysctl vm.memguard.desc=<memory_type>

-

-
Where memory_type can be either a short
-    description of the memory type to monitor, either name of
-    uma(9) zone. Only allocations from that
-    memory_type made after
-    vm.memguard.desc is set will potentially be guarded.
-    If vm.memguard.desc is modified at run-time then only
-    allocations of the new memory_type will potentially be
-    guarded once the sysctl(8) is set. Existing guarded
-    allocations will still be properly released by either
-    free(9) or uma_zfree(9), depending on
-    what kind of allocation was taken over.

-
To determine short description of a malloc(9)
-    type one can either take it from the first column of
-    vmstat(8) -m output, or to find it
-    in the kernel source. It is the second argument to
-    MALLOC_DEFINE(9) macro. To determine name of
-    uma(9) zone one can either take it from the first column
-    of vmstat(8) -z output, or to find
-    it in the kernel source. It is the first argument to the
-    uma_zcreate(9) function.

-
The vm.memguard.divisor boot-time tunable is
-    used to scale how much of the system's physical memory
-    MemGuard is allowed to consume. The default is 10,
-    so up to vm_cnt.v_page_count/10 pages can be used.
-    MemGuard will reserve
-    vm_kmem_max /
-    vm.memguard.divisor bytes of virtual address space,
-    limited by twice the physical memory size. The physical limit is reported as
-    vm.memguard.phys_limit and the virtual space reserved
-    for MemGuard is reported as
-    vm.memguard.mapsize.

-
MemGuard will not do page promotions for
-    any allocation smaller than vm.memguard.minsize bytes.
-    The default is 0, meaning all allocations can potentially be guarded.
-    MemGuard can guard sufficiently large allocations
-    randomly, with average frequency of every one in 100000 /
-    vm.memguard.frequency allocations. The default is 0,
-    meaning no allocations are randomly guarded.

-
MemGuard can optionally add unmapped guard
-    pages around each allocation to detect overflow and underflow, if
-    vm.memguard.options has the 1 bit set. This option is
-    enabled by default. MemGuard will optionally guard
-    all allocations of PAGE_SIZE or larger if
-    vm.memguard.options has the 2 bit set. This option is
-    off by default. By default MemGuard does not guard
-    uma(9) zones that have been initialized with the
-    UMA_ZONE_NOFREE flag set, since it can produce false
-    positives on them. However, this safety measure can be turned off by setting
-    bit 3 of the vm.memguard.options tunable.

-

-

-

-
sysctl(8), vmstat(8),
-    contigmalloc(9), malloc(9),
-    redzone(9), uma(9)

-

-

-

-
MemGuard first appeared in
-    FreeBSD 6.0.

-

-

-

-
MemGuard was originally written by
-    Bosko Milekic
-    <bmilekic@FreeBSD.org>.
-    This manual page was originally written by Christian
-    Brueffer
-    <brueffer@FreeBSD.org>.
-    Additions have been made by Matthew Fleming
-    <mdf@FreeBSD.org> and
-    Gleb Smirnoff
-    <glebius@FreeBSD.org>
-    to both the implementation and the documentation.

-

-

-
-  
-    
-    
-  
-
March 22, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/mi_switch.9 3.html b/static/freebsd/man9/mi_switch.9 3.html
deleted file mode 100644
index bbd5d65c..00000000
--- a/static/freebsd/man9/mi_switch.9 3.html	
+++ /dev/null
@@ -1,134 +0,0 @@
-
-  
-    
-    
-    
-  
-
MI_SWITCH(9)Kernel Developer's ManualMI_SWITCH(9)

-

-

-

-
mi_switch — switch
-    to another thread context

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
void
-  

-  mi_switch(int
-    flags);

-

-

-

-
The
-    ()
-    function implements the machine-independent prelude to a thread context
-    switch. It is the single entry point for every context switch and is called
-    from only a few distinguished places in the kernel. The context switch is,
-    by necessity, always performed by the switched thread, even when the switch
-    is initiated from elsewhere; e.g. preemption requested via Inter-Processor
-    Interrupt (IPI).

-
The various major uses of
-    ()
-    can be enumerated as follows:

-
    
-  
  1. From within a function such as
-      sleepq_wait(9) or
-      ()
-      when the current thread voluntarily relinquishes the CPU to wait for some
-      resource or lock to become available.
    2. 
-  
  2. Involuntary preemption due to arrival of a higher-priority thread.
    3. 
-  
  3. At the tail end of critical_exit(9), if preemption was
-      deferred due to the critical section.
    4. 
-  
  4. Within the TDA_SCHED AST handler, when rescheduling
-      before the return to usermode was requested. There are several reasons for
-      this, a notable one coming from
-      ()
-      when the running thread has exceeded its time slice.
    5. 
-  
  5. In the signal handling code (see issignal(9)) if a
-      signal is delivered that causes a process to stop.
    6. 
-  
  6. In
-      ()
-      where a thread needs to stop execution due to the suspension state of the
-      process as a whole.
    7. 
-  
  7. In kern_yield(9) when a thread wants to voluntarily
-      relinquish the processor.
    8. 
-

-
The flags argument to
-    ()
-    indicates the context switch type. One of the following must be passed:

-

-

-  

-  
Switch due to delayed preemption after exiting a critical section.

-  

-  
Switch after propagating scheduling priority to the owner of a
-    resource.

-  

-  
Begin waiting on a sleepqueue(9).

-  

-  
Yield call.

-  

-  
Rescheduling was requested.

-  

-  
Switch from the idle thread.

-  

-  
A kernel thread which handles interrupts has finished work and must wait
-      for interrupts to schedule additional work.

-  

-  
Thread suspended.

-  

-  
Preemption by a higher-priority thread, initiated by a remote
-    processor.

-  

-  
Idle thread preempted, initiated by a remote processor.

-  

-  
The running thread has been bound to another processor and must be
-      switched out.

-

-

-
In addition to the switch type, callers must specify the nature of
-    the switch by performing a bitwise OR with one of the
-    SW_VOL or SW_INVOL flags,
-    but not both. Respectively, these flags denote whether the context switch is
-    voluntary or involuntary on the part of the current thread. For an
-    involuntary context switch in which the running thread is being preempted,
-    the caller should also pass the SW_PREEMPT flag.

-
Upon entry to
-    (),
-    the current thread must be holding its assigned thread lock. It may be
-    unlocked as part of the context switch. After they have been rescheduled and
-    execution resumes, threads will exit mi_switch()
-    with their thread lock unlocked.

-
()
-    records the amount of time the current thread has been running before
-    handing control over to the scheduler, via
-    ().
-    After selecting a new thread to run, the scheduler will call
-    cpu_switch() to perform the low-level context
-    switch.

-
()
-    is the machine-dependent function that performs the actual switch from the
-    running thread oldtd to the chosen thread
-    newtd.

-

-

-

-
cpu_switch(9), cpu_throw(9),
-    critical_exit(9), issignal(9),
-    kern_yield(9), mutex(9),
-    pmap(9), sleepqueue(9),
-    thread_exit(9)

-

-

-
-  
-    
-    
-  
-
January 7, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/microseq.9 4.html b/static/freebsd/man9/microseq.9 4.html
deleted file mode 100644
index 0977e1c5..00000000
--- a/static/freebsd/man9/microseq.9 4.html	
+++ /dev/null
@@ -1,524 +0,0 @@
-
-  
-    
-    
-    
-  
-
MICROSEQ(9)Kernel Developer's ManualMICROSEQ(9)

-

-

-

-
microseq — ppbus
-    microsequencer developer's guide

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <dev/ppbus/ppbconf.h>
-  

-  #include
-  <dev/ppbus/ppb_msq.h>

-

-

-

-
See ppbus(4) for ppbus description and general
-    info about the microsequencer.

-
The purpose of this document is to encourage developers to use the
-    microsequencer mechanism in order to have:

-
    
-  
  1. a uniform programming model
    2. 
-  
  2. efficient code
    3. 
-

-
Before using microsequences, you are encouraged to look at
-    ppc(4) microsequencer implementation and an example of how
-    using it in ppi(4).

-

-

-

-

-

-
The parallel port model chosen for ppbus is the PC parallel port
-    model. Thus, any register described later has the same semantic than its
-    counterpart in a PC parallel port. For more info about ISA/ECP programming,
-    get the Microsoft standard referenced as "Extended Capabilities Port
-    Protocol and ISA interface Standard". Registers described later are
-    standard parallel port registers.

-
Mask macros are defined in the standard ppbus include files for
-    each valid bit of parallel port registers.

-

-

-

-
In compatible or nibble mode, writing to this register will drive
-    data to the parallel port data lines. In any other mode, drivers may be
-    tri-stated by setting the direction bit (PCD) in the control register. Reads
-    to this register return the value on the data lines.

-

-

-

-
This read-only register reflects the inputs on the parallel port
-    interface.

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
7nBUSYinverted version of parallel port Busy signal
6nACKversion of parallel port nAck signal
5PERRORversion of parallel port PERROR signal
4SELECTversion of parallel port Select signal
3nFAULTversion of parallel port nFault signal

-
Others are reserved and return undefined result when read.

-

-

-

-
This register directly controls several output signals as well as
-    enabling some functions.

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
5PCDdirection bit in extended modes
4IRQENABLE1 enables an interrupt on the rising edge of nAck
3SELECTINinverted and driven as parallel port nSelectin signal
2nINITdriven as parallel port nInit signal
1AUTOFEEDinverted and driven as parallel port nAutoFd signal
0STROBEinverted and driven as parallel port nStrobe signal

-

-

-

-

-

-

-

-    are either parallel port accesses, program iterations, submicrosequence or C
-    calls. The parallel port must be considered as the logical model described
-    in ppbus(4).

-
Available microinstructions are:

-

-
#define MS_OP_GET       0	/* get <ptr>, <len>			*/
-#define MS_OP_PUT       1	/* put <ptr>, <len>			*/
-#define MS_OP_RFETCH	2	/* rfetch <reg>, <mask>, <ptr>		*/
-#define MS_OP_RSET	3	/* rset <reg>, <mask>, <mask>		*/
-#define MS_OP_RASSERT	4	/* rassert <reg>, <mask>		*/
-#define MS_OP_DELAY     5	/* delay <val>				*/
-#define MS_OP_SET       6	/* set <val>				*/
-#define MS_OP_DBRA      7	/* dbra <offset>			*/
-#define MS_OP_BRSET     8	/* brset <mask>, <offset>		*/
-#define MS_OP_BRCLEAR   9	/* brclear <mask>, <offset>		*/
-#define MS_OP_RET       10	/* ret <retcode>			*/
-#define MS_OP_C_CALL	11	/* c_call <function>, <parameter>	*/
-#define MS_OP_PTR	12	/* ptr <pointer>			*/
-#define MS_OP_ADELAY	13	/* adelay <val>				*/
-#define MS_OP_BRSTAT	14	/* brstat <mask>, <mask>, <offset>	*/
-#define MS_OP_SUBRET	15	/* subret <code>			*/
-#define MS_OP_CALL	16	/* call <microsequence>			*/
-#define MS_OP_RASSERT_P	17	/* rassert_p <iter>, <reg>		*/
-#define MS_OP_RFETCH_P	18	/* rfetch_p <iter>, <reg>, <mask>	*/
-#define MS_OP_TRIG	19	/* trigger <reg>, <len>, <array>	*/

-

-

-

-

-
The
-     of microinstructions is:

-
    
-  
  • the
-      
-      which points to the next microinstruction to execute either in the main
-      microsequence or in a subcall
    • 
-  
  • the current value of
-       which points to
-      the next char to send/receive
    • 
-  
  • the current value of the internal
-      
    • 
-

-
This data is modified by some of the microinstructions, not
-  all.

-

-

-

-
are microinstructions used to do either predefined standard
-    IEEE1284-1994 transfers or programmed non-standard io.

-

-

-

-
is used to retrieve the current value of a parallel port register,
-    apply a mask and save it in a buffer.

-
Parameters:

-
    
-  
  1. register
    2. 
-  
  2. character mask
    3. 
-  
  3. pointer to the buffer
    4. 
-

-
Predefined macro: MS_RFETCH(reg,mask,ptr)

-

-

-

-
is used to assert/clear some bits of a particular parallel port
-    register, two masks are applied.

-
Parameters:

-
    
-  
  1. register
    2. 
-  
  2. mask of bits to assert
    3. 
-  
  3. mask of bits to clear
    4. 
-

-
Predefined macro: MS_RSET(reg,assert,clear)

-

-

-

-
is used to assert all bits of a particular parallel port
-  register.

-
Parameters:

-
    
-  
  1. register
    2. 
-  
  2. byte to assert
    3. 
-

-
Predefined macro: MS_RASSERT(reg,byte)

-

-

-

-
is used to delay the execution of the microsequence.

-
Parameter:

-
    
-  
  1. delay in microseconds
    2. 
-

-
Predefined macro: MS_DELAY(delay)

-

-

-

-
is used to set the value of the internal branch register.

-
Parameter:

-
    
-  
  1. integer value
    2. 
-

-
Predefined macro: MS_SET(accum)

-

-

-

-
is used to branch if internal branch register decremented by one
-    result value is positive.

-
Parameter:

-
    
-  
  1. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    2. 
-

-
Predefined macro: MS_DBRA(offset)

-

-

-

-
is used to branch if some of the status register bits of the
-    parallel port are set.

-
Parameter:

-
    
-  
  1. bits of the status register
    2. 
-  
  2. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    3. 
-

-
Predefined macro: MS_BRSET(mask,offset)

-

-

-

-
is used to branch if some of the status register bits of the
-    parallel port are cleared.

-
Parameter:

-
    
-  
  1. bits of the status register
    2. 
-  
  2. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    3. 
-

-
Predefined macro: MS_BRCLEAR(mask,offset)

-

-

-

-
is used to return from a microsequence. This instruction is
-    mandatory. This is the only way for the microsequencer to detect the end of
-    the microsequence. The return code is returned in the integer pointed by the
-    (int *) parameter of the ppb_MS_microseq().

-
Parameter:

-
    
-  
  1. integer return code
    2. 
-

-
Predefined macro: MS_RET(code)

-

-

-

-
is used to call C functions from microsequence execution. This may
-    be useful when a non-standard i/o is performed to retrieve a data character
-    from the parallel port.

-
Parameter:

-
    
-  
  1. the C function to call
    2. 
-  
  2. the parameter to pass to the function call
    3. 
-

-
The C function shall be declared as a int(*)(void
-    *p, char *ptr). The ptr parameter is the current position in the
-    buffer currently scanned.

-
Predefined macro: MS_C_CALL(func,param)

-

-

-

-
is used to initialize the internal pointer to the currently
-    scanned buffer. This pointer is passed to any C call (see above).

-
Parameter:

-
    
-  
  1. pointer to the buffer that shall be accessed by xxx_P() microsequence
-      calls. Note that this pointer is automatically incremented during xxx_P()
-      calls
    2. 
-

-
Predefined macro: MS_PTR(ptr)

-

-

-

-
is used to make a tsleep() during microsequence execution. The
-    tsleep is executed at PPBPRI level.

-
Parameter:

-
    
-  
  1. delay in ms
    2. 
-

-
Predefined macro: MS_ADELAY(delay)

-

-

-

-
is used to branch on status register state condition.

-
Parameter:

-
    
-  
  1. mask of asserted bits. Bits that shall be asserted in the status register
-      are set in the mask
    2. 
-  
  2. mask of cleared bits. Bits that shall be cleared in the status register
-      are set in the mask
    3. 
-  
  3. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    4. 
-

-
Predefined macro: MS_BRSTAT(asserted_bits,clear_bits,offset)

-

-

-

-
is used to return from the submicrosequence call. This action is
-    mandatory before a RET call. Some microinstructions (PUT, GET) may not be
-    callable within a submicrosequence.

-
No parameter.

-
Predefined macro: MS_SUBRET()

-

-

-

-
is used to call a submicrosequence. A submicrosequence is a
-    microsequence with a SUBRET call. Parameter:

-
    
-  
  1. the submicrosequence to execute
    2. 
-

-
Predefined macro: MS_CALL(microseq)

-

-

-

-
is used to assert a register with data currently pointed by the
-    internal PTR pointer. Parameter:

-
    
-  
  1. amount of data to write to the register
    2. 
-  
  2. register
    3. 
-

-
Predefined macro: MS_RASSERT_P(iter,reg)

-

-

-

-
is used to fetch data from a register. Data is stored in the
-    buffer currently pointed by the internal PTR pointer. Parameter:

-
    
-  
  1. amount of data to read from the register
    2. 
-  
  2. register
    3. 
-  
  3. mask applied to fetched data
    4. 
-

-
Predefined macro: MS_RFETCH_P(iter,reg,mask)

-

-

-

-
is used to trigger the parallel port. This microinstruction is
-    intended to provide a very efficient control of the parallel port.
-    Triggering a register is writing data, wait a while, write data, wait a
-    while... This allows to write magic sequences to the port. Parameter:

-
    
-  
  1. amount of data to read from the register
    2. 
-  
  2. register
    3. 
-  
  3. size of the array
    4. 
-  
  4. array of unsigned chars. Each couple of u_chars define the data to write
-      to the register and the delay in us to wait. The delay is limited to 255
-      us to simplify and reduce the size of the array.
    5. 
-

-
Predefined macro: MS_TRIG(reg,len,array)

-

-

-

-

-

-

-

-
union ppb_insarg {
-     int     i;
-     char    c;
-     void    *p;
-     int     (* f)(void *, char *);
-};
-
-struct ppb_microseq {
-     int                     opcode;         /* microins. opcode */
-     union ppb_insarg        arg[PPB_MS_MAXARGS];    /* arguments */
-};

-

-

-

-

-
To instantiate a microsequence, just declare an array of
-    ppb_microseq structures and initialize it as needed. You may either use
-    predefined macros or code directly your microinstructions according to the
-    ppb_microseq definition. For example,

-

-
     struct ppb_microseq select_microseq[] = {
-
-	     /* parameter list
-	      */
-	     #define SELECT_TARGET    MS_PARAM(0, 1, MS_TYP_INT)
-	     #define SELECT_INITIATOR MS_PARAM(3, 1, MS_TYP_INT)
-
-	     /* send the select command to the drive */
-	     MS_DASS(MS_UNKNOWN),
-	     MS_CASS(H_nAUTO | H_nSELIN |  H_INIT | H_STROBE),
-	     MS_CASS( H_AUTO | H_nSELIN |  H_INIT | H_STROBE),
-	     MS_DASS(MS_UNKNOWN),
-	     MS_CASS( H_AUTO | H_nSELIN | H_nINIT | H_STROBE),
-
-	     /* now, wait until the drive is ready */
-	     MS_SET(VP0_SELTMO),
-/* loop: */     MS_BRSET(H_ACK, 2 /* ready */),
-	     MS_DBRA(-2 /* loop */),
-/* error: */    MS_RET(1),
-/* ready: */    MS_RET(0)
-     };

-

-
Here, some parameters are undefined and must be filled before
-    executing the microsequence. In order to initialize each microsequence, one
-    should use the ppb_MS_init_msq() function like this:

-

-
     ppb_MS_init_msq(select_microseq, 2,
-		     SELECT_TARGET, 1 << target,
-		     SELECT_INITIATOR, 1 << initiator);

-

-
and then execute the microsequence.

-

-

-

-
The microsequencer is executed either at ppbus or adapter level
-    (see ppbus(4) for info about ppbus system layers). Most of
-    the microsequencer is executed at ppc level to avoid ppbus to adapter
-    function call overhead. But some actions like deciding whereas the transfer
-    is IEEE1284-1994 compliant are executed at ppbus layer.

-

-

-

-

-
ppbus(4), ppc(4),
-    ppi(4)

-

-

-

-
The microseq manual page first appeared in
-    FreeBSD 3.0.

-

-

-

-
This manual page was written by Nicolas
-    Souchu.

-

-

-

-
Only one level of submicrosequences is allowed.

-
When triggering the port, maximum delay allowed is 255 us.

-

-

-
-  
-    
-    
-  
-
June 6, 1998FreeBSD 15.0

diff --git a/static/freebsd/man9/microtime.9 4.html b/static/freebsd/man9/microtime.9 4.html
deleted file mode 100644
index 10dd7210..00000000
--- a/static/freebsd/man9/microtime.9 4.html	
+++ /dev/null
@@ -1,104 +0,0 @@
-
-  
-    
-    
-    
-  
-
MICROTIME(9)Kernel Developer's ManualMICROTIME(9)

-

-

-

-
bintime,
-    getbintime, microtime,
-    getmicrotime, nanotime,
-    getnanotime — get the
-    current time

-

-

-

-
#include
-    <sys/time.h>

-
void
-  

-  bintime(struct
-    bintime *bt);

-
void
-  

-  getbintime(struct
-    bintime *bt);

-
void
-  

-  microtime(struct
-    timeval *tv);

-
void
-  

-  getmicrotime(struct
-    timeval *tv);

-
void
-  

-  nanotime(struct
-    timespec *ts);

-
void
-  

-  getnanotime(struct
-    timespec *tsp);

-

-

-

-
The
-    ()
-    and getbintime() functions store the system time as
-    a struct bintime at the addresses specified by
-    bt. The microtime() and
-    getmicrotime() functions perform the same utility,
-    but record the time as a struct timeval instead.
-    Similarly the nanotime() and
-    getnanotime() functions store the time as a
-    struct timespec.

-
The
-    (),
-    (),
-    and
-    ()
-    functions always query the timecounter to return the current time as
-    precisely as possible. Whereas getbintime(),
-    getmicrotime(), and
-    getnanotime() functions are abstractions which
-    return a less precise, but faster to obtain, time.

-
The intent of the
-    (),
-    (),
-    and
-    ()
-    functions is to enforce the user's preference for timer accuracy versus
-    execution time.

-

-

-

-
binuptime(9), getbinuptime(9),
-    getmicrouptime(9), getnanouptime(9),
-    microuptime(9), nanouptime(9),
-    tvtohz(9)

-

-

-

-
The bintime functions first appeared in
-    FreeBSD 5.0. The microtime
-    and nanotime functions first appeared in
-    FreeBSD 3.0 but have existed in other incarnations
-    since 4.4BSD.

-

-

-

-
This manual page was written by Kelly
-    Yancey
-    <kbyanc@posi.net>.

-

-

-
-  
-    
-    
-  
-
September 16, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/microuptime.9 4.html b/static/freebsd/man9/microuptime.9 4.html
deleted file mode 100644
index c3b21012..00000000
--- a/static/freebsd/man9/microuptime.9 4.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
MICROUPTIME(9)Kernel Developer's ManualMICROUPTIME(9)

-

-

-

-
binuptime,
-    getbinuptime, microuptime,
-    getmicrouptime, nanouptime,
-    getnanouptime, sbinuptime,
-    getsbinuptime — get the time
-    elapsed since boot

-

-

-

-
#include
-    <sys/time.h>

-
void
-  

-  binuptime(struct
-    bintime *bt);

-
void
-  

-  getbinuptime(struct
-    bintime *bt);

-
void
-  

-  microuptime(struct
-    timeval *tv);

-
void
-  

-  getmicrouptime(struct
-    timeval *tv);

-
void
-  

-  nanouptime(struct
-    timespec *ts);

-
void
-  

-  getnanouptime(struct
-    timespec *tsp);

-
sbintime_t
-  

-  sbinuptime(void);

-
sbintime_t
-  

-  getsbinuptime(void);

-

-

-

-
The
-    ()
-    and getbinuptime() functions store the time elapsed
-    since boot as a struct bintime at the address
-    specified by bt. The
-    microuptime() and
-    getmicrouptime() functions perform the same utility,
-    but record the elapsed time as a struct timeval
-    instead. Similarly the nanouptime() and
-    getnanouptime() functions store the elapsed time as
-    a struct timespec. The
-    sbinuptime() and
-    getsbinuptime() functions return the time elapsed
-    since boot as a sbintime_t.

-
The
-    (),
-    (),
-    (),
-    and
-    ()
-    functions always query the timecounter to return the current time as
-    precisely as possible. Whereas getbinuptime(),
-    getmicrouptime(),
-    getnanouptime(), and
-    getsbinuptime() functions are abstractions which
-    return a less precise, but faster to obtain, time.

-
The intent of the
-    (),
-    (),
-    (),
-    and
-    ()
-    functions is to enforce the user's preference for timer accuracy versus
-    execution time.

-

-

-

-
bintime(9), get_cyclecount(9),
-    getbintime(9), getmicrotime(9),
-    getnanotime(9), microtime(9),
-    nanotime(9), tvtohz(9)

-

-

-

-
This manual page was written by Kelly
-    Yancey
-    <kbyanc@posi.net>.

-

-

-
-  
-    
-    
-  
-
February 21, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/mod_cc.9 3.html b/static/freebsd/man9/mod_cc.9 3.html
deleted file mode 100644
index 6e448911..00000000
--- a/static/freebsd/man9/mod_cc.9 3.html	
+++ /dev/null
@@ -1,281 +0,0 @@
-
-  
-    
-    
-    
-  
-
MOD_CC(9)Kernel Developer's ManualMOD_CC(9)

-

-

-

-
mod_cc,
-    DECLARE_CC_MODULE, CCV
-    — Modular Congestion Control

-

-

-

-
#include
-    <netinet/tcp.h>
-  

-  #include <netinet/cc/cc.h>
-  

-  #include
-    <netinet/cc/cc_module.h>

-
DECLARE_CC_MODULE(ccname,
-    ccalgo);

-
CCV(ccv,
-    what);

-

-

-

-
The mod_cc framework allows congestion
-    control algorithms to be implemented as dynamically loadable kernel modules
-    via the kld(4) facility. Transport protocols can select
-    from the list of available algorithms on a connection-by-connection basis,
-    or use the system default (see mod_cc(4) for more
-    details).

-
mod_cc modules are identified by an
-    ascii(7) name and set of hook functions encapsulated in a
-    struct cc_algo, which has the following members:

-

-
struct cc_algo {
-	char	name[TCP_CA_NAME_MAX];
-	int	(*mod_init) (void);
-	int	(*mod_destroy) (void);
-	size_t  (*cc_data_sz)(void);
-	int	(*cb_init) (struct cc_var *ccv, void *ptr);
-	void	(*cb_destroy) (struct cc_var *ccv);
-	void	(*conn_init) (struct cc_var *ccv);
-	void	(*ack_received) (struct cc_var *ccv, uint16_t type);
-	void	(*cong_signal) (struct cc_var *ccv, uint32_t type);
-	void	(*post_recovery) (struct cc_var *ccv);
-	void	(*after_idle) (struct cc_var *ccv);
-	int	(*ctl_output)(struct cc_var *, struct sockopt *, void *);
-	void    (*rttsample)(struct cc_var *, uint32_t, uint32_t, uint32_t);
-	void    (*newround)(struct cc_var *, uint32_t);
-};

-

-
The name field identifies the unique name of
-    the algorithm, and should be no longer than TCP_CA_NAME_MAX-1 characters in
-    length (the TCP_CA_NAME_MAX define lives in
-    <netinet/tcp.h> for
-    compatibility reasons).

-
The mod_init function is called when a new
-    module is loaded into the system but before the registration process is
-    complete. It should be implemented if a module needs to set up some global
-    state prior to being available for use by new connections. Returning a
-    non-zero value from mod_init will cause the loading of
-    the module to fail.

-
The mod_destroy function is called prior to
-    unloading an existing module from the kernel. It should be implemented if a
-    module needs to clean up any global state before being removed from the
-    kernel. The return value is currently ignored.

-
The cc_data_sz function is called by the
-    socket option code to get the size of data that the
-    cb_init function needs. The socket option code then
-    preallocates the modules memory so that the cb_init
-    function will not fail (the socket option code uses M_WAITOK with no locks
-    held to do this).

-
The cb_init function is called when a TCP
-    control block struct tcpcb is created. It should be
-    implemented if a module needs to allocate memory for storing private
-    per-connection state. Returning a non-zero value from
-    cb_init will cause the connection set up to be
-    aborted, terminating the connection as a result. Note that the ptr argument
-    passed to the function should be checked to see if it is non-NULL, if so it
-    is preallocated memory that the cb_init function must use instead of calling
-    malloc itself.

-
The cb_destroy function is called when a TCP
-    control block struct tcpcb is destroyed. It should be
-    implemented if a module needs to free memory allocated in
-    cb_init.

-
The conn_init function is called when a new
-    connection has been established and variables are being initialised. It
-    should be implemented to initialise congestion control algorithm variables
-    for the newly established connection.

-
The ack_received function is called when a
-    TCP acknowledgement (ACK) packet is received. Modules use the
-    type argument as an input to their congestion
-    management algorithms. The ACK types currently reported by the stack are
-    CC_ACK and CC_DUPACK. CC_ACK indicates the received ACK acknowledges
-    previously unacknowledged data. CC_DUPACK indicates the received ACK
-    acknowledges data we have already received an ACK for.

-
The cong_signal function is called when a
-    congestion event is detected by the TCP stack. Modules use the
-    type argument as an input to their congestion
-    management algorithms. The congestion event types currently reported by the
-    stack are CC_ECN, CC_RTO, CC_RTO_ERR and CC_NDUPACK. CC_ECN is reported when
-    the TCP stack receives an explicit congestion notification (RFC3168). CC_RTO
-    is reported when the retransmission time out timer fires. CC_RTO_ERR is
-    reported if the retransmission time out timer fired in error. CC_NDUPACK is
-    reported if N duplicate ACKs have been received back-to-back, where N is the
-    fast retransmit duplicate ack threshold (N=3 currently as per RFC5681).

-
The post_recovery function is called after
-    the TCP connection has recovered from a congestion event. It should be
-    implemented to adjust state as required.

-
The after_idle function is called when data
-    transfer resumes after an idle period. It should be implemented to adjust
-    state as required.

-
The ctl_output function is called when
-    getsockopt(2) or setsockopt(2) is called
-    on a tcp(4) socket with the struct
-    sockopt pointer forwarded unmodified from the TCP control, and a
-    void * pointer to algorithm specific argument.

-
The rttsample function is called to pass
-    round trip time information to the congestion controller. The additional
-    arguments to the function include the microsecond RTT that is being noted,
-    the number of times that the data being acknowledged was retransmitted as
-    well as the flightsize at send. For transports that do not track flightsize
-    at send, this variable will be the current cwnd at the time of the call.

-
The newround function is called each time a
-    new round trip time begins. The montonically increasing round number is also
-    passed to the congestion controller as well. This can be used for various
-    purposes by the congestion controller (e.g Hystart++).

-
Note that currently not all TCP stacks call the
-    rttsample and newround function
-    so dependency on these functions is also dependent upon which TCP stack is
-    in use.

-
The
-    ()
-    macro provides a convenient wrapper around the
-    DECLARE_MODULE(9) macro, and is used to register a
-    mod_cc module with the
-    mod_cc framework. The ccname
-    argument specifies the module's name. The ccalgo
-    argument points to the module's struct cc_algo.

-
mod_cc modules must instantiate a
-    struct cc_algo, but are only required to set the name
-    field, and optionally any of the function pointers. Note that if a module
-    defines the cb_init function it also must define a
-    cc_data_sz function. This is because when switching
-    from one congestion control module to another the socket option code will
-    preallocate memory for the cb_init function. If no
-    memory is allocated by the modules cb_init then the
-    cc_data_sz function should return 0.

-
The stack will skip calling any function pointer which is NULL, so
-    there is no requirement to implement any of the function pointers (with the
-    exception of the cb_init <-> cc_data_sz dependency noted above). Using
-    the C99 designated initialiser feature to set fields is encouraged.

-
Each function pointer which deals with congestion control state is
-    passed a pointer to a struct cc_var, which has the
-    following members:

-

-
struct cc_var {
-	void		*cc_data;
-	int		bytes_this_ack;
-	tcp_seq		curack;
-	uint32_t	flags;
-	int		type;
-	union ccv_container {
-		struct tcpcb		*tcp;
-		struct sctp_nets	*sctp;
-	} ccvc;
-	uint16_t	nsegs;
-	uint8_t		labc;
-};

-

-
struct cc_var groups congestion control
-    related variables into a single, embeddable structure and adds a layer of
-    indirection to accessing transport protocol control blocks. The eventual
-    goal is to allow a single set of mod_cc modules to
-    be shared between all congestion aware transport protocols, though currently
-    only tcp(4) is supported.

-
To aid the eventual transition towards this goal, direct
-    use of variables from the transport protocol's data structures is strongly
-    discouraged. However, it is inevitable at the current time to require access
-    to some of these variables, and so the
-    () macro
-    exists as a convenience accessor. The ccv argument
-    points to the struct cc_var passed into the function
-    by the mod_cc framework. The
-    what argument specifies the name of the variable to
-    access.

-
Apart from the type and
-    ccv_container fields, the remaining fields in
-    struct cc_var are for use by
-    mod_cc modules.

-
The cc_data field is available for
-    algorithms requiring additional per-connection state to attach a dynamic
-    memory pointer to. The memory should be allocated and attached in the
-    module's cb_init hook function.

-
The bytes_this_ack field specifies the
-    number of new bytes acknowledged by the most recently received ACK packet.
-    It is only valid in the ack_received hook
-  function.

-
The curack field specifies the sequence
-    number of the most recently received ACK packet. It is only valid in the
-    ack_received, cong_signal and
-    post_recovery hook functions.

-
The flags field is used to pass useful
-    information from the stack to a mod_cc module. The
-    CCF_ABC_SENTAWND flag is relevant in ack_received and
-    is set when appropriate byte counting (RFC3465) has counted a window's worth
-    of bytes has been sent. It is the module's responsibility to clear the flag
-    after it has processed the signal. The CCF_CWND_LIMITED flag is relevant in
-    ack_received and is set when the connection's ability
-    to send data is currently constrained by the value of the congestion window.
-    Algorithms should use the absence of this flag being set to avoid
-    accumulating a large difference between the congestion window and send
-    window.

-
The nsegs variable is used to pass in how
-    much compression was done by the local LRO system. So for example if LRO
-    pushed three in-order acknowledgements into one acknowledgement the variable
-    would be set to three.

-
The labc variable is used in conjunction
-    with the CCF_USE_LOCAL_ABC flag to override what labc variable the
-    congestion controller will use for this particular acknowledgement.

-

-

-

-
cc_cdg(4), cc_chd(4),
-    cc_cubic(4), cc_dctcp(4),
-    cc_hd(4), cc_htcp(4),
-    cc_newreno(4), cc_vegas(4),
-    mod_cc(4), tcp(4)

-

-

-

-
Development and testing of this software were made possible in
-    part by grants from the FreeBSD Foundation and Cisco University Research
-    Program Fund at Community Foundation Silicon Valley.

-

-

-

-
Integrate with sctp(4).

-

-

-

-
The modular Congestion Control (CC) framework first appeared in
-    FreeBSD 9.0.

-
The framework was first released in 2007 by James Healy and
-    Lawrence Stewart whilst working on the NewTCP research project at Swinburne
-    University of Technology's Centre for Advanced Internet Architectures,
-    Melbourne, Australia, which was made possible in part by a grant from the
-    Cisco University Research Program Fund at Community Foundation Silicon
-    Valley. More details are available at:

-
http://caia.swin.edu.au/urp/newtcp/

-

-

-

-
The mod_cc framework was written by
-    Lawrence Stewart
-    <lstewart@FreeBSD.org>,
-    James Healy
-    <jimmy@deefa.com> and
-    David Hayes
-    <david.hayes@ieee.org>.

-
This manual page was written by David
-    Hayes
-    <david.hayes@ieee.org>
-    and Lawrence Stewart
-    <lstewart@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
May 13, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/module.9 3.html b/static/freebsd/man9/module.9 3.html
deleted file mode 100644
index ad8230b9..00000000
--- a/static/freebsd/man9/module.9 3.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
MODULE(9)Kernel Developer's ManualMODULE(9)

-

-

-

-
module — structure
-    describing a kernel module

-

-

-

-
Each module in the kernel is described by a
-    module_t structure. The structure contains the name of
-    the device, a unique ID number, a pointer to an event handler function and
-    to an argument, which is given to the event handler, as well as some kernel
-    internal data. If the event handler function is
-    NULL, the module will use a no-operation function
-    handler instead.

-
The DECLARE_MODULE(9) macro registers the module
-    with the system.

-
When the module is loaded, the event handler function is called
-    with the what argument set to
-    MOD_LOAD.

-
On unload it is first called with what set
-    to MOD_QUIESCE. If the unload was not forced, a
-    non-zero return will prevent the unload from happening.

-
If the unload continues what is set to
-    MOD_UNLOAD. If the module returns non-zero to this,
-    the unload will not happen.

-
The difference between MOD_QUIESCE and
-    MOD_UNLOAD is that the module should fail
-    MOD_QUIESCE if it is currently in use, whereas
-    MOD_UNLOAD should only fail if it is impossible to
-    unload the module, for instance because there are memory references to the
-    module which cannot be revoked.

-
When the system is shutting down, what
-    contains the value of MOD_SHUTDOWN.

-
The module should return EOPNOTSUPP for
-    unsupported and unrecognized values of what.

-

-

-

-

-
#include <sys/param.h>
-#include <sys/kernel.h>
-#include <sys/module.h>
-
-static int foo_handler(module_t mod, int /*modeventtype_t*/ what,
-                       void *arg);
-
-static moduledata_t mod_data= {
-        "foo",
-        foo_handler,
-	NULL
-};
-
-MODULE_VERSION(foo, 1);
-MODULE_DEPEND(foo, bar, 1, 3, 4);
-
-DECLARE_MODULE(foo, mod_data, SI_SUB_EXEC, SI_ORDER_ANY);

-

-

-

-

-
DECLARE_MODULE(9),
-    DEV_MODULE(9), DRIVER_MODULE(9),
-    MODULE_DEPEND(9), MODULE_PNP_INFO(9),
-    MODULE_VERSION(9), SYSCALL_MODULE(9)

-
/usr/share/examples/kld

-

-

-

-
This manual page was written by Alexander
-    Langer
-    <alex@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 11, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/mtx_pool.9 3.html b/static/freebsd/man9/mtx_pool.9 3.html
deleted file mode 100644
index 59b9f25f..00000000
--- a/static/freebsd/man9/mtx_pool.9 3.html	
+++ /dev/null
@@ -1,162 +0,0 @@
-
-  
-    
-    
-    
-  
-
MTX_POOL(9)Kernel Developer's ManualMTX_POOL(9)

-

-

-

-
mtx_pool,
-    mtx_pool_alloc,
-    mtx_pool_find,
-    mtx_pool_lock,
-    mtx_pool_lock_spin,
-    mtx_pool_unlock,
-    mtx_pool_unlock_spin,
-    mtx_pool_create,
-    mtx_pool_destroy — mutex
-    pool routines

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/mutex.h>

-
struct mtx *
-  

-  mtx_pool_alloc(struct
-    mtx_pool *pool);

-
struct mtx *
-  

-  mtx_pool_find(struct
-    mtx_pool *pool, void
-    *ptr);

-
void
-  

-  mtx_pool_lock(struct
-    mtx_pool *pool, void
-    *ptr);

-
void
-  

-  mtx_pool_lock_spin(struct
-    mtx_pool *pool, void
-    *ptr);

-
void
-  

-  mtx_pool_unlock(struct
-    mtx_pool *pool, void
-    *ptr);

-
void
-  

-  mtx_pool_unlock_spin(struct
-    mtx_pool *pool, void
-    *ptr);

-
struct mtx_pool *
-  

-  mtx_pool_create(const
-    char *mtx_name, int
-    pool_size, int
-    opts);

-
void
-  

-  mtx_pool_destroy(struct
-    mtx_pool **poolp);

-

-

-

-
Mutex pools are designed to be used as short term leaf mutexes;
-    i.e., the last mutex one might acquire before calling
-    mtx_sleep(9). They operate using a shared pool of mutexes.
-    A mutex may be chosen from the pool based on a supplied pointer, which may
-    or may not point to anything valid, or the caller may allocate an arbitrary
-    shared mutex from the pool and save the returned mutex pointer for later
-    use.

-
The shared mutexes in the mtxpool_sleep
-    mutex pool, which is created by default, are standard, non-recursive,
-    blockable mutexes, and should only be used in appropriate situations. The
-    mutexes in the mtxpool_lockbuilder mutex pool are
-    similar, except that they are initialized with the MTX_NOWITNESS flag so
-    that they may be used to build higher-level locks. Other mutex pools may be
-    created that contain mutexes with different properties, such as spin
-    mutexes.

-
The caller can lock and unlock mutexes returned by the pool
-    routines, but since the mutexes are shared, the caller should not attempt to
-    destroy them or modify their characteristics. While pool mutexes are
-    normally leaf mutexes (meaning that one cannot depend on any ordering
-    guarantees after obtaining one), one can still obtain other mutexes under
-    carefully controlled circumstances. Specifically, if one has a private mutex
-    (one that was allocated and initialized by the caller), one can obtain it
-    after obtaining a pool mutex if ordering issues are carefully accounted for.
-    In these cases the private mutex winds up being the true leaf mutex.

-
Pool mutexes have the following advantages:

-

-
    
-  
  1. No structural overhead; i.e., they can be associated with a structure
-      without adding bloat to it.
    2. 
-  
  2. Mutexes can be obtained for invalid pointers, which is useful when one
-      uses mutexes to interlock destructor operations.
    3. 
-  
  3. No initialization or destruction overhead.
    4. 
-  
  4. Can be used with mtx_sleep(9).
    5. 
-

-
And the following disadvantages:

-

-
    
-  
  1. Should generally only be used as leaf mutexes.
    2. 
-  
  2. Pool/pool dependency ordering cannot be guaranteed.
    3. 
-  
  3. Possible L1 cache mastership contention between CPUs.
    4. 
-

-
()
-    obtains a shared mutex from the specified pool. This routine uses a simple
-    rover to choose one of the shared mutexes managed by the
-    mtx_pool subsystem.

-
()
-    returns the shared mutex associated with the specified address. This routine
-    will create a hash out of the pointer passed into it and will choose a
-    shared mutex from the specified pool based on that hash. The pointer does
-    not need to point to anything real.

-
(),
-    (),
-    (),
-    and
-    ()
-    lock and unlock the shared mutex from the specified pool associated with the
-    specified address; they are a combination of
-    mtx_pool_find() and mtx_lock(9),
-    mtx_lock_spin(9), mtx_unlock(9), and
-    mtx_unlock_spin(9), respectively. Since these routines
-    must first find the mutex to operate on, they are not as fast as directly
-    using the mutex pointer returned by a previous invocation of
-    mtx_pool_find() or
-    mtx_pool_alloc().

-
()
-    allocates and initializes a new mutex pool of the specified size. The pool
-    size must be a power of two. The opts argument is
-    passed to mtx_init(9) to set the options for each mutex in
-    the pool.

-
()
-    calls mtx_destroy(9) on each mutex in the specified pool,
-    deallocates the memory associated with the pool, and assigns NULL to the
-    pool pointer.

-

-

-

-
locking(9), mutex(9)

-

-

-

-
These routines first appeared in FreeBSD
-    5.0.

-

-

-
-  
-    
-    
-  
-
February 6, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/mutex.9 4.html b/static/freebsd/man9/mutex.9 4.html
deleted file mode 100644
index f676d026..00000000
--- a/static/freebsd/man9/mutex.9 4.html	
+++ /dev/null
@@ -1,456 +0,0 @@
-
-  
-    
-    
-    
-  
-
MUTEX(9)Kernel Developer's ManualMUTEX(9)

-

-

-

-
mutex, mtx_init,
-    mtx_destroy, mtx_lock,
-    mtx_lock_spin,
-    mtx_lock_flags,
-    mtx_lock_spin_flags,
-    mtx_trylock,
-    mtx_trylock_flags,
-    mtx_trylock_spin,
-    mtx_trylock_spin_flags,
-    mtx_unlock, mtx_unlock_spin,
-    mtx_unlock_flags,
-    mtx_unlock_spin_flags,
-    mtx_sleep, mtx_initialized,
-    mtx_owned, mtx_recursed,
-    mtx_assert, MTX_SYSINIT
-    — kernel synchronization primitives

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/mutex.h>

-
void
-  

-  mtx_init(struct
-    mtx *mutex, const char
-    *name, const char
-    *type, int
-  opts);

-
void
-  

-  mtx_destroy(struct
-    mtx *mutex);

-
void
-  

-  mtx_lock(struct
-    mtx *mutex);

-
void
-  

-  mtx_lock_spin(struct
-    mtx *mutex);

-
void
-  

-  mtx_lock_flags(struct
-    mtx *mutex, int
-    flags);

-
void
-  

-  mtx_lock_spin_flags(struct
-    mtx *mutex, int
-    flags);

-
int
-  

-  mtx_trylock(struct
-    mtx *mutex);

-
int
-  

-  mtx_trylock_flags(struct
-    mtx *mutex, int
-    flags);

-
int
-  

-  mtx_trylock_spin(struct
-    mtx *mutex);

-
int
-  

-  mtx_trylock_spin_flags(struct
-    mtx *mutex, int
-    flags);

-
void
-  

-  mtx_unlock(struct
-    mtx *mutex);

-
void
-  

-  mtx_unlock_spin(struct
-    mtx *mutex);

-
void
-  

-  mtx_unlock_flags(struct
-    mtx *mutex, int
-    flags);

-
void
-  

-  mtx_unlock_spin_flags(struct
-    mtx *mutex, int
-    flags);

-
int
-  

-  mtx_sleep(void
-    *chan, struct mtx
-    *mtx, int priority,
-    const char *wmesg,
-    int timo);

-
int
-  

-  mtx_initialized(const
-    struct mtx *mutex);

-
int
-  

-  mtx_owned(const
-    struct mtx *mutex);

-
int
-  

-  mtx_recursed(const
-    struct mtx *mutex);

-

-  

-  options INVARIANTS
-  

-  options INVARIANT_SUPPORT
-  

-  void
-  

-  mtx_assert(const
-    struct mtx *mutex, int
-    what);

-
#include
-    <sys/kernel.h>

-
MTX_SYSINIT(name,
-    struct mtx *mtx,
-    const char *description,
-    int opts);

-

-

-

-
Mutexes are the most basic and primary method of thread
-    synchronization. The major design considerations for mutexes are:

-
    
-  
  1. Acquiring and releasing uncontested mutexes should be as cheap as
-      possible.
    2. 
-  
  2. They must have the information and storage space to support priority
-      propagation.
    3. 
-  
  3. A thread must be able to recursively acquire a mutex, provided that the
-      mutex is initialized to support recursion.
    4. 
-

-
There are currently two flavors of mutexes, those that context
-    switch when they block and those that do not.

-
By default, MTX_DEF mutexes will context
-    switch when they are already held. As an optimization, they may spin for
-    some amount of time before context switching. It is important to remember
-    that since a thread may be preempted at any time, the possible context
-    switch introduced by acquiring a mutex is guaranteed to not break anything
-    that is not already broken.

-
Mutexes which do not context switch are
-    MTX_SPIN mutexes. These should only be used to
-    protect data shared with primary interrupt code. This includes interrupt
-    filters and low level scheduling code. In all architectures both acquiring
-    and releasing of a uncontested spin mutex is more expensive than the same
-    operation on a non-spin mutex. In order to protect an interrupt service
-    routine from blocking against itself all interrupts are either blocked or
-    deferred on a processor while holding a spin lock. It is permissible to hold
-    multiple spin mutexes.

-
Once a spin mutex has been acquired it is not permissible to
-    acquire a blocking mutex.

-
The storage needed to implement a mutex is provided by a
-    struct mtx. In general this should be treated as an
-    opaque object and referenced only with the mutex primitives.

-
The
-    ()
-    function must be used to initialize a mutex before it can be passed to any
-    of the other mutex functions. The name option is used
-    to identify the lock in debugging output etc. The type
-    option is used by the witness code to classify a mutex when doing checks of
-    lock ordering. If type is
-    NULL, name is used in its
-    place. The pointer passed in as name and
-    type is saved rather than the data it points to. The
-    data pointed to must remain stable until the mutex is destroyed. The
-    opts argument is used to set the type of mutex. It may
-    contain either MTX_DEF or
-    MTX_SPIN but not both. If the kernel has been
-    compiled with option INVARIANTS,
-    mtx_init() will assert that the
-    mutex has not been initialized multiple times without
-    intervening calls to mtx_destroy() unless the
-    MTX_NEW option is specified. See below for
-    additional initialization options.

-
The
-    ()
-    function acquires a MTX_DEF mutual exclusion lock on
-    behalf of the currently running kernel thread. If another kernel thread is
-    holding the mutex, the caller will be disconnected from the CPU until the
-    mutex is available (i.e., it will block).

-
The
-    ()
-    function acquires a MTX_SPIN mutual exclusion lock
-    on behalf of the currently running kernel thread. If another kernel thread
-    is holding the mutex, the caller will spin until the mutex becomes
-    available. Interrupts are disabled during the spin and remain disabled
-    following the acquiring of the lock.

-
It is possible for the same thread to recursively
-    acquire a mutex with no ill effects, provided that the
-    MTX_RECURSE bit was passed to
-    ()
-    during the initialization of the mutex.

-
The
-    ()
-    and
-    ()
-    functions acquire a MTX_DEF or
-    MTX_SPIN lock, respectively, and also accept a
-    flags argument. In both cases, the only flags
-    presently available for lock acquires are MTX_QUIET
-    and MTX_RECURSE. If the
-    MTX_QUIET bit is turned on in the
-    flags argument, then if
-    KTR_LOCK tracing is being done, it will be silenced
-    during the lock acquire. If the MTX_RECURSE bit is
-    turned on in the flags argument, then the mutex can be
-    acquired recursively.

-
The
-    ()
-    and
-    ()
-    functions attempt to acquire a MTX_DEF or
-    MTX_SPIN mutex, respectively, pointed to by
-    mutex. If the mutex cannot be immediately acquired,
-    the functions will return 0, otherwise the mutex will be acquired and a
-    non-zero value will be returned.

-
The
-    ()
-    and
-    ()
-    functions have the same behavior as mtx_trylock()
-    and mtx_trylock_spin() respectively, but should be
-    used when the caller desires to pass in a flags value.
-    Presently, the only valid value in the mtx_trylock()
-    and mtx_trylock_spin() cases is
-    MTX_QUIET, and its effects are identical to those
-    described for mtx_lock() above.

-
The
-    ()
-    function releases a MTX_DEF mutual exclusion lock.
-    The current thread may be preempted if a higher priority thread is waiting
-    for the mutex.

-
The
-    ()
-    function releases a MTX_SPIN mutual exclusion
-  lock.

-
The
-    ()
-    and
-    ()
-    functions behave in exactly the same way as do the standard mutex unlock
-    routines above, while also allowing a flags argument
-    which may specify MTX_QUIET. The behavior of
-    MTX_QUIET is identical to its behavior in the mutex
-    lock routines.

-
The
-    ()
-    function is used to destroy mutex so the data
-    associated with it may be freed or otherwise overwritten. Any mutex which is
-    destroyed must previously have been initialized with
-    mtx_init(). It is permissible to have a single hold
-    count on a mutex when it is destroyed. It is not permissible to hold the
-    mutex recursively, or have another thread blocked on the mutex when it is
-    destroyed.

-
The
-    ()
-    function is used to atomically release mtx while
-    waiting for an event. For more details on the parameters to this function,
-    see sleep(9).

-
The
-    ()
-    function returns non-zero if mutex has been
-    initialized and zero otherwise.

-
The
-    ()
-    function returns non-zero if the current thread holds
-    mutex. If the current thread does not hold
-    mutex zero is returned.

-
The
-    ()
-    function returns non-zero if the mutex is recursed.
-    This check should only be made if the running thread already owns
-    mutex.

-
The
-    ()
-    function allows assertions specified in what to be
-    made about mutex. If the assertions are not true and
-    the kernel is compiled with options INVARIANTS and
-    options INVARIANT_SUPPORT, the kernel will panic.
-    Currently the following assertions are supported:

-

-  

-  
Assert that the current thread holds the mutex pointed to by the first
-      argument.

-  

-  
Assert that the current thread does not hold the mutex pointed to by the
-      first argument.

-  

-  
Assert that the current thread has recursed on the mutex pointed to by the
-      first argument. This assertion is only valid in conjunction with
-      MA_OWNED.

-  

-  
Assert that the current thread has not recursed on the mutex pointed to by
-      the first argument. This assertion is only valid in conjunction with
-      MA_OWNED.

-

-
The
-    ()
-    macro is used to generate a call to the
-    ()
-    routine at system startup in order to initialize a given mutex lock. The
-    parameters are the same as mtx_init() but with an
-    additional argument, name, that is used in generating
-    unique variable names for the related structures associated with the lock
-    and the sysinit routine.

-

-

-
Most kernel code should use the default lock type,
-    MTX_DEF. The default lock type will allow the thread
-    to be disconnected from the CPU if the lock is already held by another
-    thread. The implementation may treat the lock as a short term spin lock
-    under some circumstances. However, it is always safe to use these forms of
-    locks in an interrupt thread without fear of deadlock against an interrupted
-    thread on the same CPU.

-

-

-

-
A MTX_SPIN mutex will not relinquish the
-    CPU when it cannot immediately get the requested lock, but will loop,
-    waiting for the mutex to be released by another CPU. This could result in
-    deadlock if another thread interrupted the thread which held a mutex and
-    then tried to acquire the mutex. For this reason spin locks disable all
-    interrupts on the local CPU.

-
Spin locks are fairly specialized locks that are intended to be
-    held for very short periods of time. Their primary purpose is to protect
-    portions of the code that implement other synchronization primitives such as
-    default mutexes, thread scheduling, and interrupt threads.

-

-

-

-
The options passed in the opts argument of
-    ()
-    specify the mutex type. One of the MTX_DEF or
-    MTX_SPIN options is required and only one of those
-    two options may be specified. The possibilities are:

-

-  

-  
Default mutexes will always allow the current thread to be suspended to
-      avoid deadlock conditions against interrupt threads. The implementation of
-      this lock type may spin for a while before suspending the current
-    thread.

-  

-  
Spin mutexes will never relinquish the CPU. All interrupts are disabled on
-      the local CPU while any spin lock is held.

-  

-  
Specifies that the initialized mutex is allowed to recurse. This bit must
-      be present if the mutex is permitted to recurse.
-    
Note that neither
-        ()
-        nor
-        ()
-        support recursion; that is, attempting to acquire an already-owned mutex
-        fails.

-  

-  

-  
Do not log any mutex operations for this lock.

-  

-  
Instruct witness(4) to ignore this lock.

-  

-  
Witness should not log messages about duplicate locks being acquired.

-  

-  
Do not profile this lock.

-  

-  
Do not check for double-init.

-

-

-

-

-
The flags passed to the mtx_lock_flags(),
-    mtx_lock_spin_flags(),
-    mtx_unlock_flags(), and
-    mtx_unlock_spin_flags() functions provide some basic
-    options to the caller, and are often used only under special circumstances
-    to modify lock or unlock behavior. Standard locking and unlocking should be
-    performed with the mtx_lock(),
-    mtx_lock_spin(),
-    mtx_unlock(), and
-    mtx_unlock_spin() functions. Only if a flag is
-    required should the corresponding flags-accepting routines be used.

-
Options that modify mutex behavior:

-

-  

-  
This option is used to quiet logging messages during individual mutex
-      operations. This can be used to trim superfluous logging messages for
-      debugging purposes.

-

-

-

-

-
If Giant must be acquired, it must be
-    acquired prior to acquiring other mutexes. Put another way: it is impossible
-    to acquire Giant non-recursively while holding another
-    mutex. It is possible to acquire other mutexes while holding
-    Giant, and it is possible to acquire
-    Giant recursively while holding other mutexes.

-

-

-

-
Sleeping while holding a mutex (except for
-    Giant) is never safe and should be avoided. There are
-    numerous assertions which will fail if this is attempted.

-

-

-

-
No mutexes should be held (except for Giant)
-    across functions which access memory in userspace, such as
-    copyin(9), copyout(9),
-    uiomove(9), fuword(9), etc. No locks are
-    needed when calling these functions.

-

-

-

-

-
condvar(9), LOCK_PROFILING(9),
-    locking(9), mtx_pool(9),
-    panic(9), rwlock(9),
-    sema(9), sleep(9),
-    sx(9)

-

-

-

-
These functions appeared in BSD/OS 4.1 and
-    FreeBSD 5.0. The
-    mtx_trylock_spin() function was added in
-    FreeBSD 11.1.

-

-

-
-  
-    
-    
-  
-
February 17, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/namei.9 3.html b/static/freebsd/man9/namei.9 3.html
deleted file mode 100644
index 634973b7..00000000
--- a/static/freebsd/man9/namei.9 3.html	
+++ /dev/null
@@ -1,423 +0,0 @@
-
-  
-    
-    
-    
-  
-
NAMEI(9)Kernel Developer's ManualNAMEI(9)

-

-

-

-
namei, NDINIT,
-    NDINIT_AT, NDFREE_PNBUF
-    — pathname translation and lookup
-  operations

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/fcntl.h>
-  

-  #include <sys/namei.h>

-
int
-  

-  namei(struct
-    nameidata *ndp);

-
void
-  

-  NDINIT(struct nameidata *ndp,
-    enum nameiop op, u_int64_t
-    flags, enum uio_seg segflg,
-    const char *namep);

-
void
-  

-  NDINIT_AT(struct nameidata *ndp,
-    enum nameiop op, u_int64_t
-    flags, enum uio_seg segflg,
-    const char *namep, int
-  dirfd);

-
void
-  

-  NDFREE_PNBUF(struct
-    nameidata *ndp);

-

-

-

-
The namei facility allows the client to
-    perform pathname translation and lookup operations. The
-    namei functions will increment the reference count
-    for the vnode in question. The reference count has to be decremented after
-    use of the vnode, by using either vrele(9) or
-    vput(9), depending on whether the
-    LOCKLEAF flag was specified or not.

-
The
-    ()
-    macro is used to initialize namei components. It
-    takes the following arguments:

-

-  
ndp

-  
A pointer to the struct nameidata to
-    initialize.

-  
op

-  
The operation which
-      ()
-      will perform. The following operations are valid:
-      LOOKUP, CREATE,
-      DELETE, and RENAME. The
-      latter three are just setup for those effects; just calling
-      namei() will not result in
-      ()
-      being called.

-  
flags

-  
Operation flags, described in the next section. Several of these can be
-      effective at the same time.

-  
segflg

-  
UIO segment indicator. This indicates if the name of the object is in
-      userspace (UIO_USERSPACE) or in the kernel address
-      space (UIO_SYSSPACE).

-  
namep

-  
Pointer to the component's pathname buffer (the file or directory name
-      that will be looked up).

-

-
The
-    ()
-    macro is similar to NDINIT(), but takes one extra
-    argument:

-

-  
dirfd

-  
File descriptor referencing a directory, or the special value
-      AT_FDCWD meaning the calling thread's current
-      working directory. Lookups will be performed relative to this
-    directory.

-

-
The
-    ()
-    macro is used to free the pathname buffer. It must be called exactly once
-    for each successful
-    ()
-    call. It takes the following argument:

-

-  
ndp

-  
A pointer to a struct nameidata that was used in a
-      successful namei() call.

-

-

-

-

-
The namei() function takes the following
-    set of “operation flags” that influence its operation:

-

-  

-  
An alias for NOCACHE.

-  

-  
Keep the positive-caching entry in cache. This flag is typically combined
-      with NOCACHE to not cache a new entry, but keep
-      existing one, or with MAKEENTRY.

-  

-  
Avoid namei() creating this entry in the namecache
-      if it is not already present. Normally, namei()
-      will add entries to the name cache if they are not already there.

-  

-  
Lock vnode on return with LK_EXCLUSIVE unless
-      LOCKSHARED is also set.
-      VOP_UNLOCK(9) should be used to release the lock (or
-      vput(9) which is equivalent to calling
-      VOP_UNLOCK(9) followed by vrele(9),
-      all in one).

-  

-  
This flag lets the namei() function return the
-      parent (directory) vnode, ni_dvp in locked state,
-      unless it is identical to ni_vp, in which case
-      ni_dvp is not locked per se (but may be locked due
-      to LOCKLEAF). If a lock is enforced, it should be
-      released using vput(9) or
-      VOP_UNLOCK(9) and vrele(9).

-  

-  
This flag allows the namei() function to return
-      the parent (directory) vnode in an unlocked state. The parent vnode must
-      be released separately by using vrele(9).

-  

-  
Makes the namei operation fail if the target
-      exists. It requires that the LOCKPARENT flag is
-      set and LOCKLEAF is not.

-  

-  
With this flag, namei() will follow the symbolic
-      link if the last part of the path supplied is a symbolic link (i.e., it
-      will return a vnode for whatever the link points at, instead for the link
-      itself).

-  

-  
For namei call initialized with
-      NDINIT_AT(), allow the namep
-      path to be empty. In this case, the dirfd file
-      descriptor may reference a file of arbitrary type, not necessary a
-      directory, and lookup returns the vnode for this file.

-  

-  
Lock vnode on return with LK_SHARED, if permitted
-      by the file system that owns the vnode. The file system must explicitly
-      permit this by setting MNTK_LOOKUP_SHARED in
-      mp->mnt_kern_flag during mount and by calling
-      ()
-      when allocating the vnode. If LOCKLEAF is
-      specified but shared locking is not permitted, then the vnode will be
-      returned with LK_EXCLUSIVE.
-      VOP_UNLOCK(9) should be used to release the lock (or
-      vput(9) which is equivalent to calling
-      VOP_UNLOCK(9) followed by vrele(9),
-      all in one).

-  

-  
Do not follow symbolic links (pseudo). This flag is not looked for by the
-      actual code, which looks for FOLLOW.
-      NOFOLLOW is used to indicate to the source code
-      reader that symlinks are intentionally not followed.

-  

-  
Requires that namei did not cross the
-      dirfd directory. The flag is used to implement
-      O_RESOLVE_BENEATH flag for
-      openat(2).

-  

-  
The component is embedded in a namei lookup
-      structure, and the
-      ()
-      function can be used to obtain that structure. This can be useful in
-      VOP_LOOKUP(9) implementations which need to obtain extra
-      lookup metadata.

-

-

-

-

-
These flags are used for several purposes. Some of them affects
-    the global namei operation, some provide information
-    for processing of the specific path element, for instance, by the
-    VOP_LOOKUP implementation of the involved
-    filesystem.

-

-  

-  
Specifies that the lookup should act as if the final node is located on
-      read-only mount. The flag is typically used by file servers, e.g. NFS, to
-      handle read-only exports.

-  

-  
The namei was restarted with
-      ().
-      This is used internally for double-root lookups used by ABI subsystems,
-      after the lookup with native root failed. The components are reset to the
-      original values, and lookup is repeated with different root, once.

-  

-  
Ignore whiteouts, e.g. when checking if a directory is empty.

-  

-  
The result of lookup is whiteout.

-  

-  
Handle whiteouts, the instruction for the
-      ()
-      filesystem methods.

-  

-  
The lookup is done for creating a new entry that will be directory. It
-      allows the trailing slash in the path string.

-  

-  
The caller is the code that opens a file. This allows to weaken the lock
-      mode of the return vnode, if the mount point indicates extended shared
-      lock support.

-  

-  
Do not cross mount points during lookup.
-    
For “..” lookup leading to mount root, returns
-        the root vnode of the mount instead of the covered vnode of the
-        filesystem where the mount was placed.

-    
For other lookups passing over mount, do not jump into the
-        mounted filesystem. This allows to descend into the file hierarchy
-        otherwise shadowed by the mount point.

-  

-  

-  
Do not perform MAC checks during lookup.

-  

-  
Audit the looked up vnode information, use the first slot for audit
-      information.

-  

-  
Same as AUDITVNODE1 but use the second slot.

-  

-  
Do not perform capability checks. If the calling process is in capability
-      mode, lookup is denied outright.

-  

-  
The lookup was for open and file will be opened for read.

-  

-  
The lookup was for open and file will be opened for write.

-  

-  
Leave ioctl caps for the caller. See the description of
-      namei results.

-  

-  
Opening a named attribute (directory).

-  

-  
Do not perform check for allowed execution on the starting directory. It
-      is used to implement the POSIX-required semantic for
-      openat(2) lookups that must use the permissions from
-      time the directory was opened, and not when used for lookup.

-  

-  
Looked-up entry is to be added to name cache.

-  
-  
Current component is symlink, and it needs the interpretation according to
-      the FOLLOW or NOFOLLOW
-      flags.

-  

-  
This is last component of pathname. It is handled specially, many flags
-      augment its processing.

-  

-  
Current component name is “..”. Usually implies a need to
-      specially handle the vnode locking for instantiation of the target vnode.
-      The generic
-      ()
-      function and its more specialized variant
-      ()
-      might be useful.

-  

-  
Path ended in a slash.

-  

-  
Create a named attribute dir.

-

-

-

-

-
The nameidata structure is composed of the
-    following fields:

-

-  
ni_startdir

-  
In the normal case, this is either the current directory or the root. It
-      is the current directory if the name passed in does not start with
-      ‘/’ and we have not gone through any
-      symlinks with an absolute path, and the root otherwise.
-    
In this case, it is only used by
-        (),
-        and should not be considered valid after a call to
-        ().

-  

-  
ni_dvp

-  
Vnode pointer to directory of the object on which lookup is performed.
-      This is available on successful return if
-      LOCKPARENT or WANTPARENT
-      is set. It is locked if LOCKPARENT is set.

-  
ni_vp

-  
Vnode pointer to the resulting object, NULL
-      otherwise. The v_usecount field of this vnode is
-      incremented. If LOCKLEAF is set, it is also
-      locked.

-  
ni_cnd.cn_pnbuf

-  
The pathname buffer contains the location of the file or directory that
-      will be used by the namei operations. It is
-      managed by the uma(9) zone allocation interface.

-

-

-

-

-
The struct namei member
-    ni_resflags returns the following flags giving some
-    details of the successful operation:

-

-  

-  
The path passed was absolute.

-  

-  
Restricted lookup result. Only relative lookups were done to resolve the
-      path to vnode.

-  

-  
The EMPTYPATH flag was provided and used. In
-      particular, the passed path was empty.

-

-
If the WANTIOCTLCAPS flag was specified,
-    on return the ni_filecaps member of the
-    struct namei contains the capabilities of the file
-    descriptor used as the lookup starting point
-  (dirfd).

-

-

-

-
If successful, namei() will return 0,
-    otherwise it will return an error.

-

-

-

-

-  
src/sys/kern/vfs_lookup.c

-  
 

-

-

-

-

-
Assuming the path variable contains a
-    pointer to userspace path string, the following example looks up the file
-    named by it, and performs required error and resource handling:

-

-
	char *path;
-	struct nameidata nd;
-	int error;
-
-	NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | AUDITVNODE1, UIO_USERSPACE,
-	    path);
-	if ((error = namei(&nd)) != 0)
-		return (error);
-	NDFREE_PNBUF(&nd);
-	... use nd.ni_vp vnode

-

-

-

-

-
Errors which namei() may return:

-

-  
[]

-  
A component of the specified pathname is not a directory when a directory
-      is expected.

-  
[]

-  
A component of a pathname exceeded 255 characters, or an entire pathname
-      exceeded 1023 characters.

-  
[]

-  
A component of the specified pathname does not exist, or the pathname is
-      an empty string.

-  
[]

-  
An attempt is made to access a file in a way forbidden by its file access
-      permissions.

-  
[]

-  
Too many symbolic links were encountered in translating the pathname.

-  
[]

-  
An attempt is made to open a directory with write mode specified.

-  
[]

-  
The last component of the pathname specified for a
-      DELETE or RENAME operation
-      is ‘.’.

-  
[]

-  
An attempt is made to modify a file or directory on a read-only file
-      system.

-

-

-

-

-
uio(9), uma(9),
-    VFS(9), vnode(9),
-    vput(9), vref(9),
-    vrele(9)

-

-

-

-
This manual page was written by Eivind
-    Eklund
-    <eivind@FreeBSD.org>
-    and later significantly revised by Hiten M. Pandya
-    <hmp@FreeBSD.org>.

-

-

-

-
The LOCKPARENT flag does not always result
-    in the parent vnode being locked. This results in complications when the
-    LOCKPARENT is used. In order to solve this for the
-    cases where both LOCKPARENT and
-    LOCKLEAF are used, it is necessary to resort to
-    recursive locking.

-

-

-
-  
-    
-    
-  
-
September 30, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/netisr.9 4.html b/static/freebsd/man9/netisr.9 4.html
deleted file mode 100644
index 0c91038b..00000000
--- a/static/freebsd/man9/netisr.9 4.html	
+++ /dev/null
@@ -1,235 +0,0 @@
-
-  
-    
-    
-    
-  
-
NETISR(9)Kernel Developer's ManualNETISR(9)

-

-

-

-
netisr — Kernel
-    network dispatch service

-

-

-

-
#include
-    <net/netisr.h>

-
void
-  

-  netisr_register(const
-    struct netisr_handler *nhp);

-
void
-  

-  netisr_unregister(const
-    struct netisr_handler *nhp);

-
int
-  

-  netisr_dispatch(u_int
-    proto, struct mbuf
-    *m);

-
int
-  

-  netisr_dispatch_src(u_int
-    proto, uintptr_t
-    source, struct mbuf
-    *m);

-
int
-  

-  netisr_queue(u_int
-    proto, struct mbuf
-    *m);

-
int
-  

-  netisr_queue_src(u_int
-    proto, uintptr_t
-    source, struct mbuf
-    *m);

-
void
-  

-  netisr_clearqdrops(const
-    struct netisr_handler *nhp);

-
void
-  

-  netisr_getqdrops(const
-    struct netisr_handler *nhp,
-    uint64_t *qdropsp);

-
void
-  

-  netisr_getqlimit(const
-    struct netisr_handler *nhp,
-    u_int *qlimitp);

-
int
-  

-  netisr_setqlimit(const
-    struct netisr_handler *nhp,
-    u_int qlimit);

-
u_int
-  

-  netisr_default_flow2cpu(u_int
-    flowid);

-
u_int
-  

-  netisr_get_cpucount(void);

-
u_int
-  

-  netisr_get_cpuid(u_int
-    cpunumber);

-
With optional virtual network stack support enabled via the
-    following kernel compile option:

-
options VIMAGE

-

-void
-

-netisr_register_vnet(const
-  struct netisr_handler *nhp);
-
void
-  

-  netisr_unregister_vnet(const
-    struct netisr_handler *nhp);

-

-

-

-
The netisr kernel interface suite allows
-    device drivers (and other packet sources) to direct packets to protocols for
-    directly dispatched or deferred processing. Protocol registration and work
-    stream statistics may be monitored using netstat(1).

-

-

-
Protocols register and unregister handlers using
-    ()
-    and
-    (),
-    and may also manage queue limits and statistics using the
-    (),
-    (),
-    (),
-    and
-    ().

-
In case of VIMAGE kernels each virtual
-    network stack (vnet), that is not the default base system network stack,
-    calls
-    ()
-    and
-    ()
-    to enable or disable packet processing by the netisr
-    for each protocol. Disabling will also purge any outstanding packet from the
-    protocol queue.

-
netisr supports multi-processor execution
-    of handlers, and relies on a combination of source ordering and
-    protocol-specific ordering and work-placement policies to decide how to
-    distribute work across one or more worker threads. Registering protocols
-    will declare one of three policies:

-

-  

-  
netisr should maintain source ordering without
-      advice from the protocol. netisr will ignore any
-      flow IDs present on mbuf headers for the purposes of
-      work placement.

-  

-  
netisr should maintain flow ordering as defined by
-      the mbuf header flow ID field. If the protocol
-      implements nh_m2flow, then
-      netisr will query the protocol in the event that
-      the mbuf doesn't have a flow ID, falling back on
-      source ordering.

-  
NETISR_POLICY_CPU

-  
netisr will entirely delegate all work placement
-      decisions to the protocol, querying nh_m2cpuid for
-      each packet.

-

-
Registration is declared using struct
-    netisr_handler, whose fields are defined as follows:

-

-  
const char * nh_name

-  
Unique character string name of the protocol, which may be included in
-      sysctl(3) MIB names, so should not contain
-    whitespace.

-  
netisr_handler_t
-    nh_handler

-  
Protocol handler function that will be invoked on each packet received for
-      the protocol.

-  
netisr_m2flow_t nh_m2flow

-  
Optional protocol function to generate a flow ID and set a valid hashtype
-      for packets that enter the netisr with
-      M_HASHTYPE_GET(m) equal to
-      M_HASHTYPE_NONE. Will be used only with
-      NETISR_POLICY_FLOW.

-  
netisr_m2cpuid_t
-    nh_m2cpuid

-  
Protocol function to determine what CPU a packet should be processed on.
-      Will be used only with NETISR_POLICY_CPU.

-  
netisr_drainedcpu_t
-    nh_drainedcpu

-  
Optional callback function that will be invoked when a per-CPU queue was
-      drained. It will never fire for directly dispatched packets. Unless fully
-      understood, this special-purpose function should not be used.

-  
u_int nh_proto

-  
Protocol number used by both protocols to identify themselves to
-      netisr, and by packet sources to select what
-      handler will be used to process packets. A table of supported protocol
-      numbers appears below. For implementation reasons, protocol numbers great
-      than 15 are currently unsupported.

-  
u_int nh_qlimit

-  
The maximum per-CPU queue depth for the protocol; due to internal
-      implementation details, the effective queue depth may be as much as twice
-      this number.

-  
u_int nh_policy

-  
The ordering and work placement policy for the protocol, as described
-      earlier.

-

-

-

-

-
Packet sources, such as network interfaces, may request protocol
-    processing using the
-    ()
-    and
-    ()
-    interfaces. Both accept a protocol number and mbuf
-    argument, but while netisr_queue() will always
-    execute the protocol handler asynchronously in a deferred context,
-    netisr_dispatch() will optionally direct dispatch if
-    permitted by global and per-protocol policy.

-
In order to provide additional load
-    balancing and flow information, packet sources may also specify an opaque
-    source identifier, which in practice might be a network interface number or
-    socket pointer, using the
-    ()
-    and
-    ()
-    variants.

-

-

-

-
The follow protocol numbers are currently defined:

-

-  

-  
IPv4

-  

-  
IGMPv3 loopback

-  

-  
Routing socket loopback

-  

-  
ARP

-  

-  
IPv6

-

-

-

-

-

-
This manual page and the netisr
-    implementation were written by Robert N. M.
-  Watson.

-

-

-
-  
-    
-    
-  
-
April 12, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/nv.9 4.html b/static/freebsd/man9/nv.9 4.html
deleted file mode 100644
index 0dc22c75..00000000
--- a/static/freebsd/man9/nv.9 4.html	
+++ /dev/null
@@ -1,1177 +0,0 @@
-
-  
-    
-    
-    
-  
-
NV(9)Kernel Developer's ManualNV(9)

-

-

-

-
nvlist_create,
-    nvlist_destroy,
-    nvlist_error,
-    nvlist_set_error,
-    nvlist_empty, nvlist_flags,
-    nvlist_exists, nvlist_free,
-    nvlist_clone, nvlist_dump,
-    nvlist_fdump, nvlist_size,
-    nvlist_pack, nvlist_unpack,
-    nvlist_send, nvlist_recv,
-    nvlist_xfer,
-    nvlist_in_array,
-    nvlist_next, nvlist_add,
-    nvlist_move, nvlist_get,
-    nvlist_take, nvlist_append
-    — library for name/value pairs

-

-

-

-
Name/value pairs library (libnv, -lnv)

-

-

-

-
#include
-    <sys/nv.h>

-
nvlist_t *
-  

-  nvlist_create(int
-    flags);

-
void
-  

-  nvlist_destroy(nvlist_t
-    *nvl);

-
int
-  

-  nvlist_error(const
-    nvlist_t *nvl);

-
void
-  

-  nvlist_set_error(nvlist_t
-    *nvl, int
-  error);

-
bool
-  

-  nvlist_empty(const
-    nvlist_t *nvl);

-
int
-  

-  nvlist_flags(const
-    nvlist_t *nvl);

-
bool
-  

-  nvlist_in_array(const
-    nvlist_t *nvl);

-
nvlist_t *
-  

-  nvlist_clone(const
-    nvlist_t *nvl);

-
void
-  

-  nvlist_dump(const
-    nvlist_t *nvl, int
-    fd);

-
void
-  

-  nvlist_fdump(const
-    nvlist_t *nvl, FILE
-    *fp);

-
size_t
-  

-  nvlist_size(const
-    nvlist_t *nvl);

-
void *
-  

-  nvlist_pack(const
-    nvlist_t *nvl, size_t
-    *sizep);

-
nvlist_t *
-  

-  nvlist_unpack(const
-    void *buf, size_t
-    size, int
-  flags);

-
int
-  

-  nvlist_send(int
-    sock, const nvlist_t
-    *nvl);

-
nvlist_t *
-  

-  nvlist_recv(int
-    sock, int
-  flags);

-
nvlist_t *
-  

-  nvlist_xfer(int
-    sock, nvlist_t
-    *nvl, int
-  flags);

-
const char *
-  

-  nvlist_next(const
-    nvlist_t *nvl, int
-    *typep, void
-    **cookiep);

-
bool
-  

-  nvlist_exists(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_type(const
-    nvlist_t *nvl, const char
-    *name, int
-  type);

-
bool
-  

-  nvlist_exists_null(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_bool(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_number(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_string(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_nvlist(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_descriptor(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_binary(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_bool_array(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_number_array(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_string_array(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_nvlist_array(const
-    nvlist_t *nvl, const char
-    *name);

-
bool
-  

-  nvlist_exists_descriptor_array(const
-    nvlist_t *nvl, const char
-    *name);

-
void
-  

-  nvlist_add_null(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_add_bool(nvlist_t
-    *nvl, const char
-    *name, bool
-  value);

-
void
-  

-  nvlist_add_number(nvlist_t
-    *nvl, const char
-    *name, uint64_t
-    value);

-
void
-  

-  nvlist_add_string(nvlist_t
-    *nvl, const char
-    *name, const char
-    *value);

-
void
-  

-  nvlist_add_stringf(nvlist_t
-    *nvl, const char
-    *name, const char
-    *valuefmt,
-  ...);

-
void
-  

-  nvlist_add_stringv(nvlist_t
-    *nvl, const char
-    *name, const char
-    *valuefmt, va_list
-    valueap);

-
void
-  

-  nvlist_add_nvlist(nvlist_t
-    *nvl, const char
-    *name, const nvlist_t
-    *value);

-
void
-  

-  nvlist_add_descriptor(nvlist_t
-    *nvl, const char
-    *name, int
-  value);

-
void
-  

-  nvlist_add_binary(nvlist_t
-    *nvl, const char
-    *name, const void
-    *value, size_t
-    size);

-
void
-  

-  nvlist_add_bool_array(nvlist_t
-    *nvl, const char
-    *name, const bool
-    *value, size_t
-    nitems);

-
void
-  

-  nvlist_add_number_array(nvlist_t
-    *nvl, const char
-    *name, const uint64_t
-    *value, size_t
-    nitems);

-
void
-  

-  nvlist_add_string_array(nvlist_t
-    *nvl, const char
-    *name, const char * const
-    * value, size_t
-    nitems);

-
void
-  

-  nvlist_add_nvlist_array(nvlist_t
-    *nvl, const char
-    *name, const nvlist_t *
-    const * value, size_t
-    nitems);

-
void
-  

-  nvlist_add_descriptor_array(nvlist_t
-    *nvl, const char
-    *name, const int
-    *value, size_t
-    nitems);

-
void
-  

-  nvlist_move_string(nvlist_t
-    *nvl, const char
-    *name, char
-    *value);

-
void
-  

-  nvlist_move_nvlist(nvlist_t
-    *nvl, const char
-    *name, nvlist_t
-    *value);

-
void
-  

-  nvlist_move_descriptor(nvlist_t
-    *nvl, const char
-    *name, int
-  value);

-
void
-  

-  nvlist_move_binary(nvlist_t
-    *nvl, const char
-    *name, void *value,
-    size_t size);

-
void
-  

-  nvlist_move_bool_array(nvlist_t
-    *nvl, const char
-    *name, bool *value,
-    size_t nitems);

-
void
-  

-  nvlist_move_number_array(nvlist_t
-    *nvl, const char
-    *name, uint64_t
-    *value, size_t
-    nitems);

-
void
-  

-  nvlist_move_string_array(nvlist_t
-    *nvl, const char
-    *name, char
-    **value, size_t
-    nitems);

-
void
-  

-  nvlist_move_nvlist_array(nvlist_t
-    *nvl, const char
-    *name, nvlist_t
-    **value, size_t
-    nitems);

-
void
-  

-  nvlist_move_descriptor_array(nvlist_t
-    *nvl, const char
-    *name, int *value,
-    size_t nitems);

-
bool
-  

-  nvlist_get_bool(const
-    nvlist_t *nvl, const char
-    *name);

-
uint64_t
-  

-  nvlist_get_number(const
-    nvlist_t *nvl, const char
-    *name);

-
const char *
-  

-  nvlist_get_string(const
-    nvlist_t *nvl, const char
-    *name);

-
const nvlist_t *
-  

-  nvlist_get_nvlist(const
-    nvlist_t *nvl, const char
-    *name);

-
int
-  

-  nvlist_get_descriptor(const
-    nvlist_t *nvl, const char
-    *name);

-
const void *
-  

-  nvlist_get_binary(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *sizep);

-
const bool *
-  

-  nvlist_get_bool_array(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *nitems);

-
const uint64_t *
-  

-  nvlist_get_number_array(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *nitems);

-
const char * const *
-  

-  nvlist_get_string_array(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *nitems);

-
const nvlist_t * const *
-  

-  nvlist_get_nvlist_array(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *nitems);

-
const int *
-  

-  nvlist_get_descriptor_array(const
-    nvlist_t *nvl, const char
-    *name, size_t
-    *nitems);

-
const nvlist_t *
-  

-  nvlist_get_parent(const
-    nvlist_t *nvl, void
-    **cookiep);

-
const nvlist_t *
-  

-  nvlist_get_array_next(const
-    nvlist_t *nvl);

-
const nvlist_t *
-  

-  nvlist_get_pararr(const
-    nvlist_t *nvl, void
-    **cookiep);

-
bool
-  

-  nvlist_take_bool(nvlist_t
-    *nvl, const char
-    *name);

-
uint64_t
-  

-  nvlist_take_number(nvlist_t
-    *nvl, const char
-    *name);

-
char *
-  

-  nvlist_take_string(nvlist_t
-    *nvl, const char
-    *name);

-
nvlist_t *
-  

-  nvlist_take_nvlist(nvlist_t
-    *nvl, const char
-    *name);

-
int
-  

-  nvlist_take_descriptor(nvlist_t
-    *nvl, const char
-    *name);

-
void *
-  

-  nvlist_take_binary(nvlist_t
-    *nvl, const char
-    *name, size_t
-    *sizep);

-
bool *
-  

-  nvlist_take_bool_array(nvlist_t
-    *nvl, const char
-    *name, size_t
-    *nitems);

-
uint64_t **
-  

-  nvlist_take_number_array(nvlist_t
-    *nvl, const char
-    *name, size_t
-    *nitems);

-
char **
-  

-  nvlist_take_string_array(nvlist_t
-    *nvl, const char
-    *name, size_t
-    *nitems);

-
nvlist_t **
-  

-  nvlist_take_nvlist_array(nvlist_t
-    *nvl, const char
-    *name, size_t
-    *nitems);

-
int *
-  

-  nvlist_take_descriptor_array(nvlist_t
-    *nvl, const char
-    *name, size_t
-    *nitems);

-
void
-  

-  nvlist_append_bool_array(nvlist_t
-    *nvl, const char
-    *name, const bool
-    value);

-
void
-  

-  nvlist_append_number_array(nvlist_t
-    *nvl, const char
-    *name, const uint64_t
-    value);

-
void
-  

-  nvlist_append_string_array(nvlist_t
-    *nvl, const char
-    *name, const char * const
-    value);

-
void
-  

-  nvlist_append_nvlist_array(nvlist_t
-    *nvl, const char
-    *name, const nvlist_t *
-    const value);

-
void
-  

-  nvlist_append_descriptor_array(nvlist_t
-    *nvl, const char
-    *name, int
-  value);

-
void
-  

-  nvlist_free(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_type(nvlist_t
-    *nvl, const char
-    *name, int
-  type);

-
void
-  

-  nvlist_free_null(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_bool(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_number(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_string(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_nvlist(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_descriptor(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_binary(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_bool_array(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_number_array(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_string_array(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_nvlist_array(nvlist_t
-    *nvl, const char
-    *name);

-
void
-  

-  nvlist_free_descriptor_array(nvlist_t
-    *nvl, const char
-    *name);

-

-

-

-
The libnv library permits creating and
-    managing name value pairs as well as sending and receiving them over
-    sockets. A group (list) of name value pairs is called an
-    nvlist. The API supports the following data types
-    for values:

-

-  

-    ()

-  
There is no data associated with the name.

-  

-    ()

-  
The value can be either true or
-      false.

-  

-    ()

-  
The value is a number stored as uint64_t.

-  

-    ()

-  
The value is a C string.

-  

-    ()

-  
The value is a nested nvlist.

-  

-    ()

-  
The value is a file descriptor. Note that file descriptors can be sent
-      only over unix(4) domain sockets.

-  

-    ()

-  
The value is a binary buffer.

-  
bool array
-    ()

-  
The value is an array of boolean values.

-  
number array
-    ()

-  
The value is an array of numbers, each stored as
-      uint64_t.

-  
string array
-    ()

-  
The value is an array of C strings.

-  
nvlist array
-    ()

-  
The value is an array of nvlists. When an nvlist is added to an array, it
-      becomes part of the primary nvlist. Traversing these arrays can be done
-      using the
-      ()
-      and nvlist_get_pararr() functions.

-  
descriptor array
-    ()

-  
The value is an array of files descriptors.

-

-
The
-    ()
-    function allocates memory and initializes an nvlist.

-
The following flags can be provided:

-

-

-

-  

-  
Perform case-insensitive lookups of provided names.

-  

-  
Names in the nvlist do not have to be unique.

-

-

-
The
-    ()
-    function destroys the given nvlist. This function does nothing if
-    nvl is NULL. This function
-    never modifies errno.

-
The
-    ()
-    function returns the first error set on nvl. If
-    nvl is not in the error state, this function returns
-    zero. If nvl is NULL,
-    ENOMEM is returned.

-
The
-    ()
-    function sets an the error value for nvl. Subsequent
-    calls to nvlist_error() will return
-    error. This function cannot be used to clear the error
-    state from an nvlist. This function does nothing if the nvlist is already in
-    the error state.

-
The
-    ()
-    function returns true if nvl
-    is empty and false otherwise. The nvlist must not be
-    in the error state.

-
The
-    ()
-    function returns the flags used to create nvl with the
-    nvlist_create(),
-    nvlist_recv(),
-    nvlist_unpack(), or
-    nvlist_xfer() functions.

-
The
-    ()
-    function returns true if nvl
-    is part of an array that is a member of another nvlist.

-
The
-    ()
-    function clones nvl. The clone shares no resources
-    with its origin. This also means that all file descriptors that are part of
-    the nvlist will be duplicated with the dup(2) system call
-    before placing them in the clone.

-
The
-    ()
-    function dumps nvlist content for debugging purposes to the file descriptor
-    fd.

-
The
-    ()
-    dumps nvlist content for debugging purposes to the file stream
-    fp.

-
The
-    ()
-    function returns the size of the binary buffer that would be generated by
-    the nvlist_pack() function.

-
The
-    ()
-    function converts the given nvlist to a binary buffer. The function
-    allocates memory for the buffer which should be freed with the
-    free(3) function. If the sizep
-    argument is not NULL, the size of the buffer is
-    stored there. This function returns NULL in case of
-    an error (allocation failure). If the nvlist contains any file descriptors
-    NULL will be returned. The nvlist must not be in the
-    error state.

-
The
-    ()
-    function converts a binary buffer to a new nvlist. The
-    flags argument has the same meaning as the
-    flags argument passed to
-    nvlist_create(). If flags do
-    not match the flags used to create the initial nvlist before it was packed,
-    this function will fail. The flags of nested nvlists are not validated by
-    this function. The caller is responsible for validating the flags on any
-    nested nvlists using nvlist_flags(). This function
-    returns the new nvlist on success or NULL in case of
-    an error.

-
The
-    ()
-    function sends nvl over the socket
-    sock. Note that nvlists that contain file descriptors
-    can only be sent over unix(4) domain sockets.

-
The
-    ()
-    function receives an nvlist over the socket sock. As
-    with nvlist_unpack(), the
-    flags argument is used to construct the new nvlist and
-    must match the flags used to construct the original nvlist written to
-    sock by the peer. The flags of nested nvlists are not
-    validated by this function. The caller is responsible for validating the
-    flags on any nested nvlists using nvlist_flags().
-    This function returns the new nvlist on success or
-    NULL in case of an error.

-
The
-    ()
-    function sends nvl over the socket
-    sock argument and then receives a new nvlist over the
-    same socket. The flags argument applies to the new
-    nvlist similar to nvlist_recv(). The nvlist
-    nvl is always destroyed. This function returns the new
-    nvlist on success or NULL in case of an error.

-
The
-    ()
-    function iterates over nvl returning the names and
-    types of subsequent elements. The cookiep argument
-    determines which element is returned. If *cookiep is
-    NULL, the values for the first element in the list
-    are returned. Otherwise, *cookiep should contain the
-    result of a prior call to nvlist_next() in which
-    case values for the next element from nvl are
-    returned. This function returns NULL when there are
-    no more elements on nvl. The
-    typep argument can be NULL.
-    Elements may not be removed from nvl the nvlist while
-    traversing it. nvl must not be in the error state.
-    Additional actions can be performed on an element identified by a cookie via
-    the cnv(9) API .

-
The
-    ()
-    function returns true if an element named
-    name exists in nvl (regardless
-    of type) or false otherwise. The nvlist must not be
-    in the error state.

-
The
-    ()
-    function returns true if an element named
-    name of type type exists or
-    false otherwise. The nvlist must not be in the error
-    state.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    ()
-    functions return true if element named
-    name with the type determined by the function name
-    exists or false otherwise. The nvlist must not be in
-    the error state.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    nvlist_add_nvlist_array(),
-    ()
-    functions add an element to nvl. When adding a string
-    or binary buffer, these functions allocate memory and copy the data. When
-    adding an nvlist, the value nvlist is cloned and the
-    clone is added to nvl. When adding a file descriptor,
-    the descriptor is duplicated via the dup(2) system call
-    and the new file descriptor is added. The array functions fail if there are
-    any NULL elements in the array, or if the array
-    pointer is NULL. If an error occurs while adding a
-    new element, an internal error is set which can be examined using the
-    nvlist_error() function.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    nvlist_move_nvlist_array(),
-    ()
-    functions add an element to nvl, but unlike the
-    ()
-    functions they consume the given resource. For string, file descriptor,
-    binary buffer, or nvlist values, no value should be moved into an nvlist
-    multiple times; doing so will cause that value to be freed multiple times.
-    Note that strings or binary buffers must be allocated with
-    malloc(3), and the pointers will be released via
-    free(3) when nvl is destroyed. The
-    array functions fail if there are any NULL elements,
-    or if the array pointer is NULL. If an error occurs
-    while adding new element, the resource is destroyed and an internal error is
-    set which can be examined using the nvlist_error()
-    function.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    ()
-    functions return the value of the first element in nvl
-    named name. For string, nvlist, file descriptor,
-    binary buffer, or array values, the returned resource must not be modified -
-    it still belongs to nvl.

-
If an element named name does not exist, the
-    program aborts. To avoid this, the caller should check for the existence of
-    the element before trying to obtain the value or use the
-    dnv(9) extension which provides a default value in the
-    case of a missing element.

-
The nvlist must not be in the error state.

-
The
-    ()
-    function returns the parent nvlist of nvl.

-
The
-    ()
-    function returns the next element after nvl from an
-    array of nvlists. If nvl is not in an array of nvlists
-    or it is the last element, this function returns
-    NULL. An nvlist is only in an nvlist array if it was
-    added to an nvlist array using
-    (),
-    (),
-    or
-    ().

-
The
-    ()
-    function returns the next element after
-    ()
-    from an array of nvlists. If nvl() is the last
-    element in an array of nvlists, the parent nvlist of nvl
-    is returned. If nvl() is not in an array of
-    nvlists, NULL is returned.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    ()
-    functions return the value of the element named name
-    and remove the element from nvl. For string and binary
-    buffer values, the caller is responsible for freeing the returned value
-    using the free(3) function. For nvlist values, the caller
-    is responsible for destroying the returned nvlist using the
-    nvlist_destroy() function. For file descriptor
-    values, the caller is responsible for closing the returned descriptor using
-    the
-    (2)
-    system call. For array values, the caller is responsible for destroying
-    every element of the array based on the element type. In addition, the
-    caller must also free the pointer to the array using the
-    free(3) function.

-
If an element named name does not exist, the
-    program aborts. To avoid this, the caller should check for the existence of
-    the element before trying to obtain the value or use the
-    dnv(9) extension which provides a default value in the
-    case of a missing element.

-
The nvlist must not be in the error state.

-
The
-    (),
-    (),
-    (),
-    nvlist_append_nvlist_array(),
-    ()
-    functions append an element to an existing array using the same semantics as
-    the add functions (that is, the element will be copied when applicable). If
-    the array named name does not exist, then it will be
-    created as if using the
-    ()
-    function. If an error occurs while appending a new element, an internal
-    error is set on nvl.

-
The
-    ()
-    function removes the first element named name from
-    nvl (regardless of type) and frees all resources
-    associated with it. If no element named name exists,
-    the program aborts. The nvlist must not be in the error state.

-
The
-    ()
-    function removes the first element named name of type
-    type from nvl and frees all
-    resources associated with it. If no element named name
-    of type type exists, the program aborts. The nvlist
-    must not be in the error state.

-
The
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    ()
-    functions remove the first element named name with the
-    type determined by the function name from nvl free all
-    resources associated with it. If no element named name
-    with the appropriate type exists, the program aborts. The nvlist must not be
-    in the error state.

-

-

-
The nvlist_pack() and
-    nvlist_unpack() functions handle byte-order
-    conversions, so binary buffers can be packed and unpacked on hosts with
-    different endianness.

-
The
-    (),
-    nvlist_send(), and
-    nvlist_xfer() functions can transfer nvlists between
-    hosts with different endianness.

-

-

-

-
The nv, cnv, and
-    dnv APIs can be used in the kernel with the
-    following differences:

-
    
-  
  • File descriptor and file descriptor array value types are not
-    supported.
    • 
-  
  • nvlist_recv(),
-      nvlist_send(), and
-      nvlist_xfer() are not supported.
    • 
-  
  • All memory allocations use the M_NVLIST memory
-      type with malloc(9) and free(9). As a
-      result, any allocated buffers moved into an nvlist must be allocated with
-      M_NVLIST, and buffers returned by functions such
-      as nvlist_pack() must be freed with
-      M_NVLIST.
    • 
-

-

-

-

-

-
The following example demonstrates how to prepare an nvlist and
-    send it over a unix(4) domain socket.

-

-
nvlist_t *nvl;
-int fd;
-
-fd = open("/tmp/foo", O_RDONLY);
-if (fd < 0)
-        err(1, "open(\"/tmp/foo\") failed");
-
-nvl = nvlist_create(0);
-
-/*
- * There is no need to check if nvlist_create() succeeded
- * as the nvlist_add_<type>() functions can cope.
- * If it failed, nvlist_send() will fail.
- */
-nvlist_add_string(nvl, "filename", "/tmp/foo");
-nvlist_add_number(nvl, "flags", O_RDONLY);
-
-/*
- * We just want to send the descriptor, so we can give it
- * for the nvlist to consume (that is why we use nvlist_move
- * not nvlist_add).
- */
-nvlist_move_descriptor(nvl, "fd", fd);
-if (nvlist_send(sock, nvl) < 0) {
-	nvlist_destroy(nvl);
-	err(1, "nvlist_send() failed");
-}
-nvlist_destroy(nvl);

-

-
Receiving an nvlist and retrieving element values:

-

-
nvlist_t *nvl;
-const char *command;
-char *filename;
-int fd;
-
-nvl = nvlist_recv(sock, 0);
-if (nvl == NULL)
-	err(1, "nvlist_recv() failed");
-
-/* For command we accept a pointer to the nvlist's internal buffer. */
-command = nvlist_get_string(nvl, "command");
-
-/*
- * For filename we remove it from the nvlist and take
- * ownership of the buffer.
- */
-filename = nvlist_take_string(nvl, "filename");
-
-/* The same for the file descriptor. */
-fd = nvlist_take_descriptor(nvl, "fd");
-
-printf("command=%s filename=%s fd=%d0, command, filename, fd);
-
-/* command is freed by nvlist_destroy() */
-nvlist_destroy(nvl);
-free(filename);
-close(fd);

-

-
Iterating over an nvlist:

-

-
nvlist_t *nvl;
-const char *name;
-void *cookie;
-int type;
-
-nvl = nvlist_recv(sock, 0);
-if (nvl == NULL)
-	err(1, "nvlist_recv() failed");
-
-cookie = NULL;
-while ((name = nvlist_next(nvl, &type, &cookie)) != NULL) {
-	printf("%s=", name);
-	switch (type) {
-	case NV_TYPE_NUMBER:
-		printf("%ju", (uintmax_t)nvlist_get_number(nvl, name));
-		break;
-	case NV_TYPE_STRING:
-		printf("%s", nvlist_get_string(nvl, name));
-		break;
-	default:
-		printf("N/A");
-		break;
-	}
-	printf("\n");
-}

-

-
Iterating over every nested nvlist:

-

-
nvlist_t *nvl;
-const char *name;
-void *cookie;
-int type;
-
-nvl = nvlist_recv(sock, 0);
-if (nvl == NULL)
-	err(1, "nvlist_recv() failed");
-
-cookie = NULL;
-do {
-	while ((name = nvlist_next(nvl, &type, &cookie)) != NULL) {
-		if (type == NV_TYPE_NVLIST) {
-			nvl = nvlist_get_nvlist(nvl, name);
-			cookie = NULL;
-		}
-	}
-} while ((nvl = nvlist_get_parent(nvl, &cookie)) != NULL);

-

-
Iterating over every nested nvlist and every nvlist element:

-

-
nvlist_t *nvl;
-const nvlist_t * const *array;
-const char *name;
-void *cookie;
-int type;
-
-nvl = nvlist_recv(sock, 0);
-if (nvl == null)
-	err(1, "nvlist_recv() failed");
-
-cookie = NULL;
-do {
-	while ((name = nvlist_next(nvl, &type, &cookie)) != NULL) {
-		if (type == NV_TYPE_NVLIST) {
-			nvl = nvlist_get_nvlist(nvl, name);
-			cookie = NULL;
-		} else if (type == NV_TYPE_NVLIST_ARRAY) {
-			nvl = nvlist_get_nvlist_array(nvl, name, NULL)[0];
-			cookie = NULL;
-		}
-	}
-} while ((nvl = nvlist_get_pararr(nvl, &cookie)) != NULL);

-

-
Or alternatively:

-

-
nvlist_t *nvl, *tmp;
-const nvlist_t * const *array;
-const char *name;
-void *cookie;
-int type;
-
-nvl = nvlist_recv(sock, 0);
-if (nvl == null)
-	err(1, "nvlist_recv() failed");
-
-cooke = NULL;
-tmp = nvl;
-do {
-	do {
-		nvl = tmp;
-		while ((name = nvlist_next(nvl, &type, &cookie)) != NULL) {
-			if (type == NV_TYPE_NVLIST) {
-				nvl = nvlist_get_nvlist(nvl, name);
-				cookie = NULL;
-			} else if (type == NV_TYPE_NVLIST_ARRAY) {
-				nvl = nvlist_get_nvlist_array(nvl, name,
-				    NULL)[0];
-				cookie = NULL;
-			}
-		}
-		cookie = NULL;
-	} while ((tmp = nvlist_get_array_next(nvl)) != NULL);
-} while ((tmp = nvlist_get_parent(nvl, &cookie)) != NULL);

-

-

-

-

-
close(2), dup(2),
-    open(2), err(3),
-    free(3), printf(3),
-    unix(4)

-

-

-

-
The libnv library appeared in
-    FreeBSD 11.0.

-

-

-

-
The libnv library was implemented by
-    Pawel Jakub Dawidek
-    <pawel@dawidek.net>
-    under sponsorship from the FreeBSD Foundation.

-

-

-
-  
-    
-    
-  
-
January 3, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/nvmem.9 3.html b/static/freebsd/man9/nvmem.9 3.html
deleted file mode 100644
index 291f9867..00000000
--- a/static/freebsd/man9/nvmem.9 3.html	
+++ /dev/null
@@ -1,192 +0,0 @@
-
-  
-    
-    
-    
-  
-
nvmem(9)Kernel Developer's Manualnvmem(9)

-

-

-

-
nvmem,
-    nvmem_get_cell_len,
-    nvmem_read_cell_by_name,
-    nvmem_read_cell_by_idx,
-    nvmem_write_cell_by_name,
-    nvmem_write_cell_by_idx

-

-

-

-
options FDT
-  

-  device nvmem
-  

-  #include
-    <sys/extres/nvmem/nvmem.h>

-
int
-  

-  nvmem_get_cell_len(phandle_t
-    node, const char
-    *name);

-
int
-  

-  nvmem_read_cell_by_name(phandle_t
-    node, const char
-    *name, void *cell,
-    size_t buflen);

-
int
-  

-  nvmem_read_cell_by_idx(phandle_t
-    node, int idx,
-    void *cell,
-    size_t buflen);

-
int
-  

-  nvmem_write_cell_by_name(phandle_t
-    node, const char
-    *name, void *cell,
-    size_t buflen);

-
int
-  

-  nvmem_write_cell_by_idx(phandle_t
-    node, int idx,
-    void *cell,
-    size_t buflen);

-

-

-

-
On some embedded boards, the manufacturer stored some data on a
-    NVMEM (Non-Volatile Memory), this is generally stored in some eeprom or
-    fuses.

-
The nvmem API consist of helpers functions
-    for consumer and device methods for providers.

-

-

-

-

-  
(phandle_t
-    node, const char *name)

-  
Get the size of the cell base on the reg property on the node. Return the
-      size or ENOENT if the cell name wasn't found

-  
(phandle_t
-    node, const char *name, void
-    *cell, size_t buflen)

-  
Get the cell content based on the name. Return 0 on success or ENOENT if
-      the cell doesn't exists, ENXIO if no provider device was found, EINVAL if
-      the size isn't correct.

-  
(phandle_t
-    node, int idx, void *cell,
-    size_t buflen)

-  
Get the cell content based on the id. Return 0 on success or ENOENT if the
-      cell doesn't exists, ENXIO if no provider device was found, EINVAL if the
-      size isn't correct.

-  
(phandle_t
-    node, const char *name, void
-    *cell, size_t buflen)

-  
Write the cell content based on the name. Return 0 on success or ENOENT if
-      the cell doesn't exists, ENXIO if no provider device was found, EINVAL if
-      the size isn't correct.

-  
(phandle_t
-    node, int idx, void *cell,
-    size_t buflen)

-  
Write the cell content based on the id. Return 0 on success or ENOENT if
-      the cell doesn't exists, ENXIO if no provider device was found, EINVAL if
-      the size isn't correct.

-

-

-

-

-

-  
(device_t
-    dev, uint32_t offset, uint32_t
-    size, uint8_t *buffer)

-  
Provider device method to read a cell content.

-  
(device_t
-    dev, uint32_t offset, uint32_t
-    size, uint8_t *buffer)

-  
Provider device method to write a cell content.

-

-

-

-

-
Consider this DTS

-

-
/* Provider */
-eeprom: eeprom@20000 {
-	board_id: id@0 {
-		reg = <0x0 0x4>;
-	};
-};
-/* Consumer */
-device@30000 {
-	...
-
-	nvmem-cells = <&board_id>
-	nvmem-cell-names = "boardid";
-};

-

-
The device driver for eeprom@20000 needs to expose itself as a
-    provider

-

-
#include "nvmem_if.h"
-
-int
-foo_nvmem_read(device_t dev, uint32_t offset, uint32_t size, uint8_t *buffer)
-{
-	/* Read the data */
-}
-
-int
-foo_attach(device_t dev)
-{
-	phandle_t node;
-
-	node = ofw_bus_get_node(dev);
-	...
-	/* Registering the device so the consumers can find us */
-	OF_device_register_xref(OF_xref_from_node(node), dev);
-
-	...
-}
-
-static device_method_t foo_methods[] = {
-	...
-
-	/* nvmem interface */
-	DEVMETHOD(nvmem_read, foo_nvmem_read),
-
-	/* Terminate method list */
-	DEVMETHOD_END
-};

-

-
The consumer device driver for device@30000 can now read the nvmem
-    data

-

-
int
-bar_attach(device_t dev)
-{
-	phandle_t node;
-	uint32_t boardid;
-
-	...
-	node = ofw_bus_get_node(dev);
-	nvmem_read_cell_by_name(node, "boardid", (void *)&boardid, sizeof(boardid));
-	...
-}

-

-

-

-

-
The nvmem related function first appear in
-    FreeBSD 12.0. The nvmem interface and manual page
-    was written by Emmanuel Vadot
-    <manu@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 24, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/ofw_bus_is_compatible.9 3.html b/static/freebsd/man9/ofw_bus_is_compatible.9 3.html
deleted file mode 100644
index 55f3b28c..00000000
--- a/static/freebsd/man9/ofw_bus_is_compatible.9 3.html	
+++ /dev/null
@@ -1,138 +0,0 @@
-
-  
-    
-    
-    
-  
-
ofw_bus_is_compatible(9)Kernel Developer's Manualofw_bus_is_compatible(9)

-

-

-

-
ofw_bus_is_compatible,
-    ofw_bus_is_compatible_strict,
-    ofw_bus_node_is_compatible,
-    ofw_bus_search_compatible —
-    check device tree nodes for compatibility with
-    drivers

-

-

-

-
#include
-    <dev/ofw/openfirm.h>
-  

-  #include <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
int
-  

-  ofw_bus_is_compatible(device_t
-    dev, const char
-    *compatstr);

-
int
-  

-  ofw_bus_is_compatible_strict(device_t
-    dev, const char
-    *compatstr);

-
int
-  

-  ofw_bus_node_is_compatible(phandle_t
-    node, const char
-    *compatstr);

-
const struct ofw_compat_data *
-  

-  ofw_bus_search_compatible(device_t
-    dev, const struct
-    ofw_compat_data *compat);

-

-

-

-
The "compatible" property of the device tree node is
-    used to identify the type of the device the node represents. The property is
-    a list of one or more strings that represent hardware types the device is
-    compatible with. The common format for such strings is
-    "vendor,hardware" where "vendor" is an abbreviated name
-    of the manufacturer and "hardware" is a device identifier, for
-    instance, "fsl" for "Freescale" and
-    "imx6ul-i2c" for the I2C controller. More than one string is
-    required for compatibility with older revisions of the driver. If hardware
-    revision B is backward compatible with revision A device tree node can
-    signal this compatibility by providing both "vndr,hrdwrA" and
-    "vndr,hrdwrB" strings in the "compatible" property
-    value. This way older driver can use features available only in revision A,
-    and the new version of the driver can take advantage of revision B feature
-    set.

-
()
-    returns 1 if the compatstr value occurs in the
-    "compatible" property list of the device tree node associated with
-    the device dev, and 0 otherwise.

-
()
-    return 1 if the "compatible" property of the device tree node
-    associated with the device dev consists of only one
-    string and this string is equal to compatstr, and 0
-    otherwise.

-
()
-    returns 1 if the compatstr value occurs in the
-    "compatible" property list of the device tree node
-    node, and 0 otherwise.

-
()
-    returns pointer to the first entry of the compat table
-    whose ocd_str field occurs in "compatible" property of the device
-    tree node associated with the device dev. The
-    compat table is an array of struct ofw_compat_data
-    elements defined as follows:

-

-
struct ofw_compat_data {
-	const char *ocd_str;
-	uintptr_t  ocd_data;
-};

-

-The compat table must be terminated by the entry with
-  ocd_str set to NULL. If the device tree node is not compatible with any of the
-  entries, the function returns the pointer to the terminating entry.
-

-

-

-

-
static struct ofw_compat_data compat_data[] = {
-	{"arm,hrdwrA",		FEATURE_A},
-	{"arm,hrdwrB",		FEATURE_A | FEATURE_B},
-	{NULL,			0}
-};
-
-static int
-hrdwr_probe(device_t dev)
-{
-	...
-	if (!ofw_bus_search_compatible(dev, compat_data)->ocd_data)
-		return (ENXIO);
-	...
-}
-
-static int
-hrdwr_attach(device_t dev)
-{
-	...
-	sc = device_get_softc(dev);
-	sc->sc_features = ofw_bus_search_compatible(dev, compat_data)->ocd_data;
-	...
-}

-

-

-

-

-
ofw_bus_find_compatible(9)

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko.

-

-

-
-  
-    
-    
-  
-
April 8, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/ofw_bus_status_okay.9 4.html b/static/freebsd/man9/ofw_bus_status_okay.9 4.html
deleted file mode 100644
index 4134ab44..00000000
--- a/static/freebsd/man9/ofw_bus_status_okay.9 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
ofw_bus_status_okay(9)Kernel Developer's Manualofw_bus_status_okay(9)

-

-

-

-
ofw_bus_get_status,
-    ofw_bus_status_okay,
-    ofw_bus_node_status_okay —
-    check status of the device tree node

-

-

-

-
#include
-    <dev/ofw/openfirm.h>
-  

-  #include <dev/ofw/ofw_bus.h>
-  

-  #include
-    <dev/ofw/ofw_bus_subr.h>

-
const char *
-  

-  ofw_bus_get_status(device_t
-    dev);

-
int
-  

-  ofw_bus_status_okay(device_t
-    dev);

-
int
-  

-  ofw_bus_node_status_okay(phandle_t
-    node);

-

-

-

-
The "status" property of the device tree node indicates
-    whether the device is enabled or not. Multiple hardware versions might be
-    built using the same base System-on-Chip but with a different set of blocks
-    enabled. It is common to use SoC device tree and only enable/disable device
-    nodes for the derivative boards. The device tree node is considered enabled
-    only if it has "status" property with the value set to either
-    "ok" or "okay".

-
()
-    returns the value of the "status" property of the device tree node
-    associated with the device dev. If the node does not
-    have "status" property or there is no node associated with the
-    device the function returns NULL.

-
()
-    returns 1 if the device tree node associated with the device
-    dev has "status" property and its value is
-    either "ok" or "okay".

-
()
-    returns 1 if the device tree node node has
-    "status" property and its value is either "ok" or
-    "okay".

-

-

-

-
This manual page was written by Oleksandr
-    Tymoshenko.

-

-

-
-  
-    
-    
-  
-
April 8, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/ofw_graph.9 4.html b/static/freebsd/man9/ofw_graph.9 4.html
deleted file mode 100644
index 3f04803c..00000000
--- a/static/freebsd/man9/ofw_graph.9 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
ofw_graph(9)Kernel Developer's Manualofw_graph(9)

-

-

-

-
ofw_graph,
-    ofw_graph_get_port_by_idx,
-    ofw_graph_port_get_num_endpoints,
-    ofw_graph_get_endpoint_by_idx,
-    ofw_graph_get_remote_endpoint,
-    ofw_graph_get_remote_parent,
-    ofw_graph_get_device_by_port_ep —
-    Helpers for the graph bindings

-

-

-

-
#include
-    <dev/ofw/openfirm.h>
-  

-  #include
-  <dev/ofw/ofw_graph.h>

-
phandle_t
-  

-  ofw_graph_get_port_by_idx(phandle_t
-    node, uint32_t
-    idx);

-
size_t
-  

-  ofw_graph_port_get_num_endpoints(phandle_t
-    port);

-
phandle_t
-  

-  ofw_graph_get_endpoint_by_idx(phandle_t
-    port, uint32_t
-    idx);

-
phandle_t
-  

-  ofw_graph_get_remote_endpoint(phandle_t
-    endpoint);

-
phandle_t
-  

-  ofw_graph_get_remote_parent(phandle_t
-    remote);

-
device_t
-  

-  ofw_graph_get_device_by_port_ep(phandle_t
-    node, uint32_t
-    port_id, uin32_t
-    ep_id);

-

-

-

-
The ofw_graph functions are helpers to parse the DTS graph
-    bindings

-
()
-    return the port with id idx. It will first check node
-    named port@idx and then fallback on checking the
-    ports child for a child node matching the id. If no
-    ports matching idx is found the function return 0.

-
()
-    returns the number of endpoints a port node have.

-
()
-    return the endpoint with id idx. It will first check
-    if there is a single child named endpoint and returns
-    it if there is. If there is multiple endpoints it will check the
-    reg property and returns the correct
-    phandle_t or 0 if none match.

-
()
-    returns the remote-endpoint property if it exists or
-    0.

-
()
-    returns the device node corresponding to the
-    remote-endpoint phandle or 0 if none.
-    ()
-    returns the device associated with the port and endpoint or
-    NULL if none. The device driver should have called
-    ()
-    before.

-

-

-

-
The ofw_graph functions first appeared in
-    FreeBSD 13.0. The ofw_graph
-    functions and manual page were written by Emmanuel
-    Vadot
-    <manu@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 10, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/osd.9 4.html b/static/freebsd/man9/osd.9 4.html
deleted file mode 100644
index 622db548..00000000
--- a/static/freebsd/man9/osd.9 4.html	
+++ /dev/null
@@ -1,307 +0,0 @@
-
-  
-    
-    
-    
-  
-
OSD(9)Kernel Developer's ManualOSD(9)

-

-

-

-
osd, osd_register,
-    osd_deregister, osd_set,
-    osd_reserve,
-    osd_set_reserved,
-    osd_free_reserved, osd_get,
-    osd_del, osd_call,
-    osd_exit — Object Specific
-    Data

-

-

-

-
#include
-    <sys/osd.h>

-
typedef void
-  

-  (*osd_destructor_t)(void
-    *value);

-
typedef int
-  

-  (*osd_method_t)(void
-    *obj, void
-  *data);

-
int
-  

-  osd_register(u_int type,
-    osd_destructor_t destructor, const
-    osd_method_t *methods);

-
void
-  

-  osd_deregister(u_int type,
-    u_int slot);

-
int
-  

-  osd_set(u_int type,
-    struct osd *osd, u_int slot,
-    void *value);

-
void **
-  

-  osd_reserve(u_int slot);

-
int
-  

-  osd_set_reserved(u_int type,
-    struct osd *osd, u_int slot,
-    void **rsv, void *value);

-
void
-  

-  osd_free_reserved(void
-  **rsv);

-
void *
-  

-  osd_get(u_int type,
-    struct osd *osd, u_int
-  slot);

-
void
-  

-  osd_del(u_int type,
-    struct osd *osd, u_int
-  slot);

-
int
-  

-  osd_call(u_int type,
-    u_int method, void *obj,
-    void *data);

-
void
-  

-  osd_exit(u_int type,
-    struct osd *osd);

-

-

-

-
The osd framework provides a mechanism to
-    dynamically associate arbitrary data at run-time with any kernel data
-    structure which has been suitably modified for use with
-    osd. The one-off modification required involves
-    embedding a struct osd inside the kernel data
-    structure.

-
An additional benefit is that after the initial change to a
-    structure is made, all subsequent use of osd with
-    the structure involves no changes to the structure's layout. By extension,
-    if the data structure is part of the ABI, osd
-    provides a way of extending the structure in an ABI preserving manner.

-
The details of the embedded struct osd are
-    not relevant to consumers of the osd framework and
-    should not be manipulated directly.

-
Data associated with a structure is referenced
-    by the osd framework using a type/slot identifier
-    pair. Types are statically defined in
-    <sys/osd.h> and provide a
-    high-level grouping for slots to be registered under. Slot identifiers are
-    dynamically assigned by the framework when a data type is registered using
-    ()
-    and remains valid until a corresponding call to
-    osd_deregister().

-

-

-
The osd_register() function registers a
-    type/slot identifier pair with the osd framework for
-    use with a new data type. The function may sleep and therefore cannot be
-    called from a non-sleepable context. The type argument
-    specifies which high-level type grouping from
-    <sys/osd.h> the slot
-    identifier should be allocated under. The destructor
-    argument specifies an optional osd_destructor_t function pointer that will
-    be called for objects of the type being registered which are later destroyed
-    by the osd_del() function. NULL may be passed if no
-    destructor is required. The methods argument specifies
-    an optional array of osd_method_t function pointers which can be later
-    invoked by the osd_call() function. NULL may be
-    passed if no methods are required. The methods
-    argument is currently only useful with the OSD_JAIL type identifier.

-
The
-    ()
-    function deregisters a previously registered type/slot identifier pair. The
-    function may sleep and therefore cannot be called from a non-sleepable
-    context. The type argument specifies which high-level
-    type grouping from
-    <sys/osd.h> the slot
-    identifier is allocated under. The slot argument
-    specifies the slot identifier which is being deregistered and should be the
-    value that was returned by osd_register() when the
-    data type was registered.

-
The
-    ()
-    function associates a data object pointer with a kernel data structure's
-    struct osd member. The type
-    argument specifies which high-level type grouping from
-    <sys/osd.h> the slot
-    identifier is allocated under. The osd argument is a
-    pointer to the kernel data structure's struct osd
-    which will have the value pointer associated with it.
-    The slot argument specifies the slot identifier to
-    assign the value pointer to. The
-    value argument points to a data object to associate
-    with osd.

-
The
-    ()
-    function does the same as osd_set(), but with an
-    extra argument rsv that is internal-use memory
-    previously allocated via
-    ().

-
The
-    ()
-    function returns the data pointer associated with a kernel data structure's
-    struct osd member from the specified type/slot
-    identifier pair. The type argument specifies which
-    high-level type grouping from
-    <sys/osd.h> the slot
-    identifier is allocated under. The osd argument is a
-    pointer to the kernel data structure's struct osd to
-    retrieve the data pointer from. The slot argument
-    specifies the slot identifier to retrieve the data pointer from.

-
The
-    ()
-    function removes the data pointer associated with a kernel data structure's
-    struct osd member from the specified type/slot
-    identifier pair. The type argument specifies which
-    high-level type grouping from
-    <sys/osd.h> the slot
-    identifier is allocated under. The osd argument is a
-    pointer to the kernel data structure's struct osd to
-    remove the data pointer from. The slot argument
-    specifies the slot identifier to remove the data pointer from. If an
-    osd_destructor_t function pointer was specified at registration time, the
-    destructor function will be called and passed the data pointer for the
-    type/slot identifier pair which is being deleted.

-
The
-    ()
-    function calls the specified osd_method_t function pointer for all currently
-    registered slots of a given type on the specified obj
-    and data pointers. The function may sleep and
-    therefore cannot be called from a non-sleepable context. The
-    type argument specifies which high-level type grouping
-    from <sys/osd.h> to call the
-    method for. The method argument specifies the index
-    into the osd_method_t array that was passed to
-    osd_register(). The obj and
-    data arguments are passed to the method function
-    pointer of each slot.

-
The
-    ()
-    function removes all data object pointers from all currently registered
-    slots for a given type for the specified kernel data structure's
-    struct osd member. The type
-    argument specifies which high-level type grouping from
-    <sys/osd.h> to remove data
-    pointers from. The osd argument is a pointer to the
-    kernel data structure's struct osd to remove all data
-    object pointers for all currently registered slots from.

-

-

-

-

-
osd uses a two dimensional matrix (array
-    of arrays) as the data structure to manage the external data associated with
-    a kernel data structure's struct osd member. The type
-    identifier is used as the index into the outer array, and the slot
-    identifier is used as the index into the inner array. To set or retrieve a
-    data pointer for a given type/slot identifier pair,
-    osd_set() and osd_get()
-    perform the equivalent of array[type][slot], which is both constant time and
-    fast.

-
If osd_set() is called on a
-    struct osd for the first time, the array for storing
-    data pointers is dynamically allocated using malloc(9)
-    with M_NOWAIT to a size appropriate for the slot identifier being set. If a
-    subsequent call to osd_set() attempts to set a slot
-    identifier which is numerically larger than the slot used in the previous
-    osd_set() call, realloc(9) is used
-    to grow the array to the appropriate size such that the slot identifier can
-    be used. To maximise the efficiency of any code which calls
-    osd_set() sequentially on a number of different slot
-    identifiers (e.g., during an initialisation phase) one should loop through
-    the slot identifiers in descending order from highest to lowest. This will
-    result in only a single malloc(9) call to create an array
-    of the largest slot size and all subsequent calls to
-    osd_set() will proceed without any
-    realloc(9) calls.

-
It is possible for osd_set() to fail to
-    allocate this array. To ensure that such allocation succeeds,
-    osd_reserve() may be called (in a non-blocking
-    context), and it will pre-allocate the memory via
-    malloc(9) with M_WAITOK. Then this pre-allocated memory is
-    passed to osd_set_reserved(), which will use it if
-    necessary or otherwise discard it. The memory may also be explicitly
-    discarded by calling osd_free_reserved(). As this
-    method always allocates memory whether or not it is ultimately needed, it
-    should be used only rarely, such as in the unlikely event that
-    osd_set() fails.

-
The osd API is geared towards slot
-    identifiers storing pointers to the same underlying data structure type for
-    a given osd type identifier. This is not a
-    requirement, and khelp(9) for example stores completely
-    different data types in slots under the OSD_KHELP type identifier.

-

-

-
osd internally uses a mix of
-    mutex(9), rmlock(9) and
-    sx(9) locks to protect its internal data structures and
-    state.

-
Responsibility for synchronising access to a kernel data
-    structure's struct osd member is left to the subsystem
-    that uses the data structure and calls the osd
-  API.

-
osd_get() only acquires an
-    rmlock(9) in read mode, therefore making it safe to use in
-    the majority of contexts within the kernel including most fast paths.

-

-

-

-

-
osd_register() returns the slot identifier
-    for the newly registered data type.

-
osd_set() and
-    osd_set_reserved() return zero on success or ENOMEM
-    if the specified type/slot identifier pair triggered an internal
-    realloc(9) which failed
-    (osd_set_reserved() will always succeed when
-    rsv is non-NULL).

-
osd_get() returns the data pointer for the
-    specified type/slot identifier pair, or NULL if the slot has not been
-    initialised yet.

-
osd_reserve() returns a pointer suitable
-    for passing to osd_set_reserved() or
-    osd_free_reserved().

-
osd_call() returns zero if no method is
-    run or the method for each slot runs successfully. If a method for a slot
-    returns non-zero, osd_call() terminates prematurely
-    and returns the method's error to the caller.

-

-

-

-
khelp(9)

-

-

-

-
The Object Specific Data (OSD) facility first appeared in
-    FreeBSD 8.0.

-

-

-

-
The osd facility was written by
-    Pawel Jakub Dawidek
-    <pjd@FreeBSD.org>.

-
This manual page was written by Lawrence
-    Stewart
-    <lstewart@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 7, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/owll.9 4.html b/static/freebsd/man9/owll.9 4.html
deleted file mode 100644
index 4c2a7efb..00000000
--- a/static/freebsd/man9/owll.9 4.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
OWLL(9)Kernel Developer's ManualOWLL(9)

-

-

-

-
owll,
-    OWLL_WRITE_ONE,
-    OWLL_WRITE_ZERO,
-    OWLL_READ_DATA,
-    OWLL_REASET_AND_PRESENCE —
-    Dallas Semiconductor 1-Wire Link Layer Interface

-

-

-

-
int
-  

-  OWLL_WRITE_ONE(device_t
-    lldev, struct ow_timing
-    *timing);

-
int
-  

-  OWLL_WRITE_ZERO(device_t
-    lldev, struct ow_timing
-    *timing);

-
int
-  

-  OWLL_READ_DATA(device_t
-    lldev, struct ow_timing
-    *timing, int
-  *bit);

-
int
-  

-  OWLL_RESET_AND_PRESENCE(device_t
-    lldev, struct ow_timing
-    *timing, int
-  *bit);

-

-

-

-
The owll interface provides access to the
-    link layer of the Dallas Semiconductor 1-Wire from upper layers of the
-    protocol.

-
()
-    and
-    ()
-    writes a one bit or a zero bit respectively on the 1-Wire bus.

-
()
-    reads one bit from the 1-Wire bus. This is often referred to as a
-    “Read Time Slot” in the 1-Wire device data sheets.

-
The
-    ()
-    function starts a reset sequence and detects if any device(s) are present on
-    the bus. This is the beginning of all 1-Wire transactions.

-

-

-

-
This interface is intended to be used only by the
-    ow(4) device to talk to the low-level bus. By convention,
-    the device that implements this interface is called
-    owc(4). Only devices that implement
-    own(9) should call these interfaces.

-

-

-

-
ow(4), owc(4),
-    own(9)

-

-

-

-
1-Wire is a registered trademark of Maxim Integrated Products,
-    Inc.

-

-

-

-
The owll driver first appeared in
-    FreeBSD 11.0.

-

-

-

-
The owll device driver and this manual
-    page were written by Warner Losh.

-

-

-
-  
-    
-    
-  
-
September 22, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/own.9 4.html b/static/freebsd/man9/own.9 4.html
deleted file mode 100644
index 2d3f0288..00000000
--- a/static/freebsd/man9/own.9 4.html	
+++ /dev/null
@@ -1,216 +0,0 @@
-
-  
-    
-    
-    
-  
-
OWN(9)Kernel Developer's ManualOWN(9)

-

-

-

-
own,
-    own_send_command,
-    own_command_wait,
-    own_self_command,
-    own_acquire_bus, own crc,
-    own_release_bus,
-    OWN_ACQUIRE_BUS, OWN_CRC,
-    OWN_RELEASE_BUS,
-    OWN_SEND_COMMAND — Dallas
-    Semiconductor 1-Wire Network and Transport Interface

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include <dev/ow/own.h>

-
int
-  

-  own_send_command(device_t
-    pdev, struct ow_cmd
-    *cmd);

-
int
-  

-  own_command_wait(device_t
-    pdev, struct ow_cmd
-    *cmd);

-
int
-  

-  own_self_command(device_t
-    pdev, struct ow_cmd
-    *cmd, uint8_t
-    xpt_cmd);

-
int
-  

-  own_acquire_bus(device_t
-    pdev, int how);

-
int
-  

-  own_release_bus(device_t
-    pdev);

-
int
-  

-  own_crc(device_t
-    pdev, uint8_t
-    *buffer, size_t
-    len);

-
int
-  

-  OWN_SEND_COMMAND(device_t
-    ndev, device_t
-    pdev, struct ow_cmd
-    *cmd);

-
int
-  

-  OWN_ACQUIRE_BUS(device_t
-    ndev, device_t
-    pdev, int how);

-
void
-  

-  OWN_RELEASE_BUS(device_t
-    ndev, device_t
-    pdev);

-
uint8_t
-  

-  OWN_CRC(device_t
-    ndev, device_t
-    pdev, uint8_t
-    *buffer, size_t
-    len);

-

-

-

-
The own interface defines three sets of
-    functions for interacting with 1-Wire devices: sending commands, reserving
-    the bus, and ensuring data integrity. Wrappers are provided for the raw
-    OWN kobj(9) interfaces and should
-    be used for improved safety over the kobj(9) ones.

-

-

-
The 1-Wire bus defines different layers of access to the devices
-    on the bus. The own functions provide access to the
-    network and transport layers. The network layer designates the next command
-    as being either for all devices on the bus, or for a specific device. The
-    network layer also specifies the speed used by the link layer.

-
struct ow_cmd encapsulates network access,
-    speed, and timing information. It specifies the commands to send and whether
-    or not to read data. Its members are:

-

-  
flags

-  
Flags controlling the interpretation of the structure. These flags are
-      defined in <dev/ow/ow.h>:
-    

-      
OW_FLAG_OVERDRIVE

-      
Send xpt_cmd bytes and read
-          xpt_read bytes at overdrive speed.

-      
OW_FLAG_READ_BIT

-      
Interpret xpt_read_len to be in bits to be read
-          after xpt_cmd rather than bytes.

-    

-  

-  
rom_cmd

-  
ROM command bytes to send.

-  
rom_len

-  
Number of ROM command bytes to send.

-  
rom_read_len

-  
Number of bytes to read after sending the ROM command.

-  
rom_read

-  
Buffer for bytes read after the ROM command.

-  
xpt_cmd

-  
Transport command to send.

-  
xpt_len

-  
Length of the transport command bytes to send. Specify 0 for no transport
-      command.

-  
xpt_read_len

-  
Number of bytes to read after xpt_cmd bytes are
-      sent. If the OW_FLAG_READ_BIT bit is set in
-      flags, then it is the number of bits to read. Bits
-      read are packed into bytes.

-  
xpt_read

-  
Buffer for data read.

-

-
()
-    acquires the 1-Wire bus, waiting if necessary, sends the command, and then
-    releases the bus.
-    ()
-    sends the command without bus reservation. pdev is the
-    client device (the presentation layer device) sending the command. The
-    cmd argument describes the transaction to send to the
-    1-Wire bus.

-
()
-    fills in cmd with a MATCH_ROM ROM command, the ROM
-    address of pdev and the xpt_cmd
-    as a convenient way to create directed commands.

-

-

-

-
The 1-Wire system includes an advisory lock for the bus that
-    presentation layer devices can use to coordinate access. Locking is purely
-    advisory at this time.

-
()
-    reserves the bus. It waits indefinitely if the how
-    argument is OWN_WAIT and returns the error
-    EWOULDBLOCK if passed
-    OWN_DONTWAIT when the bus is owned by another
-    client.

-
()
-    releases the bus.

-

-

-

-
()
-    computes the 1-Wire standard CRC function over the data passed in
-    buffer and len and returns the
-    result.

-

-

-

-
The 1-Wire standard (Maxim AN937) defines layers that are akin to
-    ISO networking layers. The lowest relevant layer, the link layer, defines
-    the polling windows and the timing of the signaling of different modes. The
-    network layer is built on top of the link layer and is used to address
-    devices in a unicast or multicast manner. The transport layer defines
-    commands and responses from the devices. The presentation layer is composed
-    of the device specific commands and actions used to control the specific
-    1-Wire devices on bus.

-
These interfaces are implemented by the ow(4)
-    device. Presentation layer devices (children of the newbus
-    ow(4) device) should only call the functions described
-    here. The functionality provided by the owc(4) device
-    (specifically the owll(9) interface) should only be called
-    by the ow(4) driver.

-

-

-

-

-
ow(4), owc(4),
-    owll(9)
-    https://pdfserv.maximintegrated.com/en/an/AN937.pdf

-

-

-

-
1-Wire is a registered trademark of Maxim Integrated Products,
-    Inc.

-

-

-

-
The own driver first appeared in
-    FreeBSD 11.0.

-

-

-

-
The own device driver and this manual page
-    were written by Warner Losh.

-

-

-
-  
-    
-    
-  
-
July 20, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/p_candebug.9 4.html b/static/freebsd/man9/p_candebug.9 4.html
deleted file mode 100644
index bea842ab..00000000
--- a/static/freebsd/man9/p_candebug.9 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
P_CANDEBUG(9)Kernel Developer's ManualP_CANDEBUG(9)

-

-

-

-
p_candebug —
-    determine debuggability of a process

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
int
-  

-  p_candebug(struct
-    thread *td, struct proc
-    *p);

-

-

-

-
This function determines if a given process
-    p is debuggable by some thread
-    td.

-
The following sysctl(8)
-    variables directly influence the behaviour of
-    ():

-

-  
security.bsd.unprivileged_proc_debug

-  
Must be set to a non-zero value to allow unprivileged processes access to
-      the kernel's debug facilities.

-  
kern.securelevel

-  
Debugging of the init process is not allowed if this variable is
-      1 or greater.

-

-
Other such variables indirectly influence it; see
-    cr_bsd_visible(9).

-

-

-

-
The p_candebug() function returns
-    0 if the process denoted by p
-    is debuggable by thread td, or a non-zero error return
-    value otherwise.

-

-

-

-

-  
[]

-  
An unprivileged process attempted to debug another process but the system
-      is configured to deny it (see sysctl(8) variable
-      security.bsd.unprivileged_proc_debug above).

-  
[]

-  
Thread td has been jailed and the process to debug
-      does not belong to the same jail or one of its sub-jails, as determined by
-      prison_check(9).

-  
[]

-  
cr_bsd_visible(9) denied visibility according to the BSD
-      security policies in force.

-  
[]

-  
Thread td lacks superuser credentials and its
-      (effective) group set is not a superset of process
-      p's whole group set (including real, effective and
-      saved group IDs).

-  
[]

-  
Thread td lacks superuser credentials and its
-      (effective) user ID does not match all user IDs of process
-      p.

-  
[]

-  
Thread td lacks superuser credentials and process
-      p is executing a set-user-ID or set-group-ID
-      executable.

-  
[]

-  
Process p denotes the initial process
-      initproc() and the sysctl(8)
-      variable kern.securelevel is greater than zero.

-  
[]

-  
Process p is in the process of being
-      exec()'ed.

-  
[]

-  
Process p denied debuggability (see
-      procctl(2), command
-      PROC_TRACE_CTL).

-

-

-

-

-
procctl(2), cr_bsd_visible(9),
-    mac(9), p_cansee(9),
-    prison_check(9)

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/p_cansee.9 4.html b/static/freebsd/man9/p_cansee.9 4.html
deleted file mode 100644
index 42823bc6..00000000
--- a/static/freebsd/man9/p_cansee.9 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
P_CANSEE(9)Kernel Developer's ManualP_CANSEE(9)

-

-

-

-
p_cansee —
-    determine visibility of a process

-

-

-

-
#include
-    <sys/proc.h>

-
int
-  

-  p_cansee(struct
-    thread *td, struct proc
-    *p);

-

-

-

-
This function determines if a given process
-    p is visible to the thread td,
-    where the notion of “visibility” may be read as
-    “awareness of existence”.

-
This function explicitly allows a thread to always see its own
-    process, even with pending credentials changes (see
-    ucred(9)). Otherwise, it simply defers to
-    cr_cansee(9).

-

-

-

-
The p_cansee() function returns
-    0 if the process denoted by p
-    is visible by thread td, or ESRCH otherwise.

-

-

-

-

-  
[]

-  
Thread td is not part of process
-      p and cannot see it as determined by
-      cr_cansee(9).

-

-

-

-

-
cr_cansee(9), p_candebug(9),
-    ucred(9)

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/panic.9 3.html b/static/freebsd/man9/panic.9 3.html
deleted file mode 100644
index afde7a46..00000000
--- a/static/freebsd/man9/panic.9 3.html	
+++ /dev/null
@@ -1,114 +0,0 @@
-
-  
-    
-    
-    
-  
-
PANIC(9)Kernel Developer's ManualPANIC(9)

-

-

-

-
panic — bring down
-    system on fatal error

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
extern char *panicstr;

-
void
-  

-  panic(const
-    char *fmt,
-  ...);

-
void
-  

-  vpanic(const
-    char *fmt, va_list
-    ap);

-
KERNEL_PANICKED();

-

-

-

-
The
-    ()
-    and vpanic() functions terminate the running system.
-    The message fmt is a printf(3) style
-    format string. The message is printed to the console and
-    panicstr is set pointing to the address of the message
-    text. This can be retrieved from a core dump at a later time.

-
Upon entering the
-    ()
-    function the panicking thread disables interrupts and calls
-    critical_enter(9). This prevents the thread from being
-    preempted or interrupted while the system is still in a running state. Next,
-    it will instruct the other CPUs in the system to stop. This synchronizes
-    with other threads to prevent concurrent panic conditions from interfering
-    with one another. In the unlikely event of concurrent panics, only one
-    panicking thread will proceed.

-
Control will be passed to the kernel debugger via
-    ().
-    This is conditional on a debugger being installed and enabled by the
-    debugger_on_panic variable; see
-    ddb(4) and gdb(4). The debugger may
-    initiate a system reset, or it may eventually return.

-
Finally, kern_reboot(9) is called
-    to restart the system, and a kernel dump will be requested. If
-    () is
-    called recursively (from the disk sync routines, for example),
-    ()
-    will be instructed not to sync the disks.

-
The
-    ()
-    function implements the main body of panic(). It is
-    suitable to be called by functions which perform their own variable-length
-    argument processing. In all other cases, panic() is
-    preferred.

-
The
-    ()
-    macro is the preferred way to determine if the system has panicked. It
-    returns a boolean value. Most often this is used to avoid taking an action
-    that cannot possibly succeed in a panic context.

-

-

-

-
Once the panic has been initiated, code executing in a panic
-    context is subject to the following restrictions:

-
    
-  
  • Single-threaded execution. The scheduler is disabled, and other CPUs are
-      stopped/forced idle. Functions that manipulate the scheduler state must be
-      avoided. This includes, but is not limited to, wakeup(9)
-      and sleepqueue(9) functions.
    • 
-  
  • Interrupts are disabled. Device I/O (e.g. to the console) must be achieved
-      with polling.
    • 
-  
  • Dynamic memory allocation cannot be relied on, and must be avoided.
    • 
-  
  • Lock acquisition/release will be ignored, meaning these operations will
-      appear to succeed.
    • 
-  
  • Sleeping on a resource is not strictly prohibited, but will result in an
-      immediate return from the sleep function. Time-based sleeps such as
-      pause(9) may be performed as a busy-wait.
    • 
-

-

-

-

-
The panic() and
-    vpanic() functions do not return.

-

-

-

-
printf(3), ddb(4),
-    gdb(4), KASSERT(9),
-    kern_reboot(9)

-

-

-
-  
-    
-    
-  
-
March 17, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/pci.9 4.html b/static/freebsd/man9/pci.9 4.html
deleted file mode 100644
index 553c5a43..00000000
--- a/static/freebsd/man9/pci.9 4.html	
+++ /dev/null
@@ -1,897 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI(9)Kernel Developer's ManualPCI(9)

-

-

-

-
pci,
-    pci_alloc_msi,
-    pci_alloc_msix,
-    pci_clear_pme,
-    pci_disable_busmaster,
-    pci_disable_io,
-    pci_enable_busmaster,
-    pci_enable_io,
-    pci_enable_pme,
-    pci_find_bsf, pci_find_cap,
-    pci_find_dbsf,
-    pci_find_device,
-    pci_find_extcap,
-    pci_find_htcap,
-    pci_find_next_cap,
-    pci_find_next_extcap,
-    pci_find_next_htcap,
-    pci_find_pcie_root_port,
-    pci_get_id,
-    pci_get_max_payload,
-    pci_get_max_read_req,
-    pci_get_powerstate,
-    pci_get_vpd_ident,
-    pci_get_vpd_readonly,
-    pci_has_pm, pci_iov_attach,
-    pci_iov_attach_name,
-    pci_iov_detach,
-    pci_msi_count,
-    pci_msix_count,
-    pci_msix_pba_bar,
-    pci_msix_table_bar,
-    pci_pending_msix,
-    pci_read_config,
-    pci_release_msi,
-    pci_remap_msix,
-    pci_restore_state,
-    pci_save_state,
-    pci_set_max_read_req,
-    pci_set_powerstate,
-    pci_write_config,
-    pcie_adjust_config,
-    pcie_flr,
-    pcie_get_max_completion_timeout,
-    pcie_read_config,
-    pcie_wait_for_pending_transactions,
-    pcie_write_config — PCI bus
-    interface

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include <dev/pci/pcireg.h>
-  

-  #include
-  <dev/pci/pcivar.h>

-
int
-  

-  pci_alloc_msi(device_t
-    dev, int
-  *count);

-
int
-  

-  pci_alloc_msix(device_t
-    dev, int
-  *count);

-
void
-  

-  pci_clear_pme(device_t
-    dev);

-
int
-  

-  pci_disable_busmaster(device_t
-    dev);

-
int
-  

-  pci_disable_io(device_t
-    dev, int
-  space);

-
int
-  

-  pci_enable_busmaster(device_t
-    dev);

-
int
-  

-  pci_enable_io(device_t
-    dev, int
-  space);

-
void
-  

-  pci_enable_pme(device_t
-    dev);

-
device_t
-  

-  pci_find_bsf(uint8_t
-    bus, uint8_t slot,
-    uint8_t func);

-
int
-  

-  pci_find_cap(device_t
-    dev, int
-    capability, int
-    *capreg);

-
device_t
-  

-  pci_find_dbsf(uint32_t
-    domain, uint8_t
-    bus, uint8_t slot,
-    uint8_t func);

-
device_t
-  

-  pci_find_device(uint16_t
-    vendor, uint16_t
-    device);

-
int
-  

-  pci_find_extcap(device_t
-    dev, int
-    capability, int
-    *capreg);

-
int
-  

-  pci_find_htcap(device_t
-    dev, int
-    capability, int
-    *capreg);

-
int
-  

-  pci_find_next_cap(device_t
-    dev, int
-    capability, int
-    start, int
-    *capreg);

-
int
-  

-  pci_find_next_extcap(device_t
-    dev, int
-    capability, int
-    start, int
-    *capreg);

-
int
-  

-  pci_find_next_htcap(device_t
-    dev, int
-    capability, int
-    start, int
-    *capreg);

-
device_t
-  

-  pci_find_pcie_root_port(device_t
-    dev);

-
int
-  

-  pci_get_id(device_t
-    dev, enum pci_id_type
-    type, uintptr_t
-    *id);

-
int
-  

-  pci_get_max_payload(device_t
-    dev);

-
int
-  

-  pci_get_max_read_req(device_t
-    dev);

-
int
-  

-  pci_get_powerstate(device_t
-    dev);

-
int
-  

-  pci_get_vpd_ident(device_t
-    dev, const char
-    **identptr);

-
int
-  

-  pci_get_vpd_readonly(device_t
-    dev, const char
-    *kw, const char
-    **vptr);

-
bool
-  

-  pci_has_pm(device_t
-    dev);

-
int
-  

-  pci_msi_count(device_t
-    dev);

-
int
-  

-  pci_msix_count(device_t
-    dev);

-
int
-  

-  pci_msix_pba_bar(device_t
-    dev);

-
int
-  

-  pci_msix_table_bar(device_t
-    dev);

-
int
-  

-  pci_pending_msix(device_t
-    dev, u_int
-  index);

-
uint32_t
-  

-  pci_read_config(device_t
-    dev, int reg,
-    int width);

-
int
-  

-  pci_release_msi(device_t
-    dev);

-
int
-  

-  pci_remap_msix(device_t
-    dev, int count,
-    const u_int
-  *vectors);

-
void
-  

-  pci_restore_state(device_t
-    dev);

-
void
-  

-  pci_save_state(device_t
-    dev);

-
int
-  

-  pci_set_max_read_req(device_t
-    dev, int size);

-
int
-  

-  pci_set_powerstate(device_t
-    dev, int
-  state);

-
void
-  

-  pci_write_config(device_t
-    dev, int reg,
-    uint32_t val,
-    int width);

-
uint32_t
-  

-  pcie_adjust_config(device_t dev,
-    int reg, uint32_t mask,
-    uint32_t val, int width);

-
bool
-  

-  pcie_flr(device_t
-    dev, u_int
-    max_delay, bool
-    force);

-
int
-  

-  pcie_get_max_completion_timeout(device_t
-    dev);

-
uint32_t
-  

-  pcie_read_config(device_t
-    dev, int reg,
-    int width);

-
bool
-  

-  pcie_wait_for_pending_transactions(device_t
-    dev, u_int
-    max_delay);

-
void
-  

-  pcie_write_config(device_t
-    dev, int reg,
-    uint32_t val,
-    int width);

-
void
-  

-  pci_event_fn(void
-    *arg, device_t
-    dev);

-
EVENTHANDLER_REGISTER(pci_add_device,
-    pci_event_fn);

-
EVENTHANDLER_DEREGISTER(pci_delete_resource,
-    pci_event_fn);

-
#include
-    <dev/pci/pci_iov.h>

-
int
-  

-  pci_iov_attach(device_t
-    dev, nvlist_t
-    *pf_schema, nvlist_t
-    *vf_schema);

-
int
-  

-  pci_iov_attach_name(device_t
-    dev, nvlist_t *pf_schema,
-    nvlist_t *vf_schema, const char
-    *fmt, ...);

-
int
-  

-  pci_iov_detach(device_t
-    dev);

-

-

-

-
The pci set of functions are used for
-    managing PCI devices. The functions are split into several groups: raw
-    configuration access, locating devices, device information, device
-    configuration, and message signaled interrupts.

-

-

-
The
-    ()
-    function is used to read data from the PCI configuration space of the device
-    dev, at offset reg, with
-    width specifying the size of the access.

-
The
-    ()
-    function is used to write the value val to the PCI
-    configuration space of the device dev, at offset
-    reg, with width specifying the
-    size of the access.

-
The
-    ()
-    function is used to modify the value of a register in the PCI-express
-    capability register set of device dev. The offset
-    reg specifies a relative offset in the register set
-    with width specifying the size of the access. The new
-    value of the register is computed by modifying bits set in
-    mask to the value in val. Any
-    bits not specified in mask are preserved. The previous
-    value of the register is returned.

-
The
-    ()
-    function is used to read the value of a register in the PCI-express
-    capability register set of device dev. The offset
-    reg specifies a relative offset in the register set
-    with width specifying the size of the access.

-
The
-    ()
-    function is used to write the value val to a register
-    in the PCI-express capability register set of device
-    dev. The offset reg specifies a
-    relative offset in the register set with width
-    specifying the size of the access.

-
:
-    Device drivers should only use these functions for functionality that is not
-    available via another
-    ()
-    function.

-

-

-

-
The
-    ()
-    function looks up the device_t of a PCI device, given
-    its bus, slot, and
-    func. The slot number actually
-    refers to the number of the device on the bus, which does not necessarily
-    indicate its geographic location in terms of a physical slot. Note that in
-    case the system has multiple PCI domains, the
-    pci_find_bsf() function only searches the first one.
-    Actually, it is equivalent to:

-

-
pci_find_dbsf(0, bus, slot, func);

-

-
The
-    ()
-    function looks up the device_t of a PCI device, given
-    its domain, bus,
-    slot, and func. The
-    slot number actually refers to the number of the
-    device on the bus, which does not necessarily indicate its geographic
-    location in terms of a physical slot.

-
The
-    ()
-    function looks up the device_t of a PCI device, given
-    its vendor and device IDs. Note
-    that there can be multiple matches for this search; this function only
-    returns the first matching device.

-

-

-

-
The
-    ()
-    function is used to locate the first instance of a PCI capability register
-    set for the device dev. The capability to locate is
-    specified by ID via capability. Constant macros of the
-    form PCIY_xxx for standard capability IDs are
-    defined in
-    <dev/pci/pcireg.h>. If the
-    capability is found, then *capreg is set to the offset
-    in configuration space of the capability register set, and
-    pci_find_cap() returns zero. If the capability is
-    not found or the device does not support capabilities,
-    pci_find_cap() returns an error. The
-    ()
-    function is used to locate the next instance of a PCI capability register
-    set for the device dev. The
-    start should be the *capreg
-    returned by a prior pci_find_cap() or
-    pci_find_next_cap(). When no more instances are
-    located pci_find_next_cap() returns an error.

-
The
-    ()
-    function returns true if dev supports power
-    management.

-
The
-    ()
-    function is used to locate the first instance of a PCI-express extended
-    capability register set for the device dev. The
-    extended capability to locate is specified by ID via
-    capability. Constant macros of the form
-    PCIZ_xxx for standard extended capability IDs are
-    defined in
-    <dev/pci/pcireg.h>. If the
-    extended capability is found, then *capreg is set to
-    the offset in configuration space of the extended capability register set,
-    and pci_find_extcap() returns zero. If the extended
-    capability is not found or the device is not a PCI-express device,
-    pci_find_extcap() returns an error. The
-    ()
-    function is used to locate the next instance of a PCI-express extended
-    capability register set for the device dev. The
-    start should be the *capreg
-    returned by a prior pci_find_extcap() or
-    pci_find_next_extcap(). When no more instances are
-    located pci_find_next_extcap() returns an error.

-
The
-    ()
-    function is used to locate the first instance of a HyperTransport capability
-    register set for the device dev. The capability to
-    locate is specified by type via capability. Constant
-    macros of the form PCIM_HTCAP_xxx for standard
-    HyperTransport capability types are defined in
-    <dev/pci/pcireg.h>. If the
-    capability is found, then *capreg is set to the offset
-    in configuration space of the capability register set, and
-    pci_find_htcap() returns zero. If the capability is
-    not found or the device is not a HyperTransport device,
-    pci_find_htcap() returns an error. The
-    ()
-    function is used to locate the next instance of a HyperTransport capability
-    register set for the device dev. The
-    start should be the *capreg
-    returned by a prior pci_find_htcap() or
-    pci_find_next_htcap(). When no more instances are
-    located pci_find_next_htcap() returns an error.

-
The
-    ()
-    function walks up the PCI device hierarchy to locate the PCI-express root
-    port upstream of dev. If a root port is not found,
-    pci_find_pcie_root_port() returns
-    NULL.

-
The
-    ()
-    function is used to read an identifier from a device. The
-    type flag is used to specify which identifier to read.
-    The following flags are supported:

-

-  

-  
Read the routing identifier for the device.

-  

-  
Read the MSI routing ID. This is needed by some interrupt controllers to
-      route MSI and MSI-X interrupts.

-

-
The
-    ()
-    function is used to fetch a device's Vital Product Data (VPD) identifier
-    string. If the device dev supports VPD and provides an
-    identifier string, then *identptr is set to point at a
-    read-only, null-terminated copy of the identifier string, and
-    pci_get_vpd_ident() returns zero. If the device does
-    not support VPD or does not provide an identifier string, then
-    pci_get_vpd_ident() returns an error.

-
The
-    ()
-    function is used to fetch the value of a single VPD read-only keyword for
-    the device dev. The keyword to fetch is identified by
-    the two character string kw. If the device supports
-    VPD and provides a read-only value for the requested keyword, then
-    *vptr is set to point at a read-only, null-terminated
-    copy of the value, and pci_get_vpd_readonly()
-    returns zero. If the device does not support VPD or does not provide the
-    requested keyword, then pci_get_vpd_readonly()
-    returns an error.

-
The
-    ()
-    function returns the maximum completion timeout configured for the device
-    dev in microseconds. If the dev
-    device is not a PCI-express device,
-    pcie_get_max_completion_timeout() returns zero. When
-    completion timeouts are disabled for dev, this
-    function returns the maximum timeout that would be used if timeouts were
-    enabled.

-
The
-    ()
-    function waits for any pending transactions initiated by the
-    dev device to complete. The function checks for
-    pending transactions by polling the transactions pending flag in the
-    PCI-express device status register. It returns true
-    once the transaction pending flag is clear. If transactions are still
-    pending after max_delay milliseconds,
-    pcie_wait_for_pending_transactions() returns
-    false. If max_delay is set to
-    zero, pcie_wait_for_pending_transactions() performs
-    a single check; otherwise, this function may sleep while polling the
-    transactions pending flag.
-    pcie_wait_for_pending_transactions returns
-    true if dev is not a
-    PCI-express device.

-

-

-

-
The
-    ()
-    function enables PCI bus mastering for the device dev,
-    by setting the PCIM_CMD_BUSMASTEREN bit in the
-    PCIR_COMMAND register. The
-    ()
-    function clears this bit.

-
The
-    ()
-    function enables memory or I/O port address decoding for the device
-    dev, by setting the
-    PCIM_CMD_MEMEN or
-    PCIM_CMD_PORTEN bit in the
-    PCIR_COMMAND register appropriately. The
-    ()
-    function clears the appropriate bit. The space
-    argument specifies which resource is affected; this can be either
-    SYS_RES_MEMORY or
-    SYS_RES_IOPORT as appropriate. Device drivers should
-    generally not use these routines directly. The PCI bus will enable decoding
-    automatically when a SYS_RES_MEMORY or
-    SYS_RES_IOPORT resource is activated via
-    bus_alloc_resource(9) or
-    bus_activate_resource(9).

-
The
-    ()
-    function returns the current maximum TLP payload size in bytes for a
-    PCI-express device. If the dev device is not a
-    PCI-express device, pci_get_max_payload() returns
-    zero.

-
The
-    ()
-    function returns the current maximum read request size in bytes for a
-    PCI-express device. If the dev device is not a
-    PCI-express device, pci_get_max_read_req() returns
-    zero.

-
The
-    ()
-    sets the PCI-express maximum read request size for
-    dev. The requested size may be
-    adjusted, and pci_set_max_read_req() returns the
-    actual size set in bytes. If the dev device is not a
-    PCI-express device, pci_set_max_read_req() returns
-    zero.

-
The
-    ()
-    function returns the current power state of the device
-    dev. If the device does not support power management
-    capabilities, then the default state of
-    PCI_POWERSTATE_D0 is returned. The following power
-    states are defined by PCI:

-

-  

-  
State in which device is on and running. It is receiving full power from
-      the system and delivering full functionality to the user.

-  

-  
Class-specific low-power state in which device context may or may not be
-      lost. Buses in this state cannot do anything to the bus, to force devices
-      to lose context.

-  

-  
Class-specific low-power state in which device context may or may not be
-      lost. Attains greater power savings than
-      PCI_POWERSTATE_D1. Buses in this state can cause
-      devices to lose some context. Devices
-       be
-      prepared for the bus to be in this state or higher.

-  

-  
State in which the device is off and not running. Device context is lost,
-      and power from the device can be (but is not necessarily) removed.

-  

-  
Same as PCI_POWERSTATE_D3_HOT, except power has
-      been removed from the device.

-  

-  
State of the device is unknown.

-

-
The
-    ()
-    function is used to transition the device dev to the
-    PCI power state state. If the device does not support
-    power management capabilities or it does not support the specific power
-    state state, then the function will fail with
-    EOPNOTSUPP.

-
The
-    ()
-    function is used to clear any pending PME# signal and disable generation of
-    power management events.

-
The
-    ()
-    function is used to enable generation of power management events before
-    suspending a device.

-
The
-    ()
-    function is used to advertise that the given device (and associated device
-    driver) supports PCI Single-Root I/O Virtualization (SR-IOV). A driver that
-    supports SR-IOV must implement the PCI_IOV_INIT(9),
-    PCI_IOV_ADD_VF(9) and PCI_IOV_UNINIT(9)
-    methods. This function should be called during the
-    DEVICE_ATTACH(9) method. If this function returns an
-    error, it is recommended that the device driver still successfully attaches,
-    but runs with SR-IOV disabled. The pf_schema and
-    vf_schema parameters are used to define what
-    device-specific configuration parameters the device driver accepts when
-    SR-IOV is enabled for the Physical Function (PF) and for individual Virtual
-    Functions (VFs) respectively. See pci_iov_schema(9) for
-    details on how to construct the schema. If either the
-    pf_schema or vf_schema is
-    invalid or specifies parameter names that conflict with parameter names that
-    are already in use, pci_iov_attach() will return an
-    error and SR-IOV will not be available on the PF device. If a driver does
-    not accept configuration parameters for either the PF device or the VF
-    devices, the driver must pass an empty schema for that device. The SR-IOV
-    infrastructure takes ownership of the pf_schema and
-    vf_schema and is responsible for freeing them. The
-    driver must never free the schemas itself.

-
The
-    ()
-    function is a variant of pci_iov_attach() that
-    allows the name of the associated character device in
-    /dev/iov to be specified by
-    fmt. The pci_iov_attach()
-    function uses the name of dev as the device name.

-
The
-    ()
-    function is used to advise the SR-IOV infrastructure that the driver for the
-    given device is attempting to detach and that all SR-IOV resources for the
-    device must be released. This function must be called during the
-    DEVICE_DETACH(9) method if
-    pci_iov_attach() was successfully called on the
-    device and pci_iov_detach() has not subsequently
-    been called on the device and returned no error. If this function returns an
-    error, the DEVICE_DETACH(9) method must fail and return an
-    error, as detaching the PF driver while VF devices are active would cause
-    system instability. This function is safe to call and will always succeed if
-    pci_iov_attach() previously failed with an error on
-    the given device, or if pci_iov_attach() was never
-    called on the device.

-
The
-    ()
-    and
-    ()
-    functions can be used by a device driver to save and restore standard PCI
-    config registers. The pci_save_state() function must
-    be invoked while the device has valid state before
-    pci_restore_state() can be used. If the device is
-    not in the fully-powered state (PCI_POWERSTATE_D0)
-    when pci_restore_state() is invoked, then the device
-    will be transitioned to PCI_POWERSTATE_D0 before any
-    config registers are restored.

-
The
-    ()
-    function requests a Function Level Reset (FLR) of dev.
-    If dev is not a PCI-express device or does not support
-    Function Level Resets via the PCI-express device control register,
-    false is returned. Pending transactions are drained
-    by disabling busmastering and calling
-    pcie_wait_for_pending_transactions() before
-    resetting the device. The max_delay argument specifies
-    the maximum timeout to wait for pending transactions as described for
-    pcie_wait_for_pending_transactions(). If
-    pcie_wait_for_pending_transactions() fails with a
-    timeout and force is false,
-    busmastering is re-enabled and false is returned. If
-    pcie_wait_for_pending_transactions() fails with a
-    timeout and force is true, the
-    device is reset despite the timeout. After the reset has been requested,
-    pcie_flr sleeps for at least 100 milliseconds before
-    returning true. Note that
-    pcie_flr does not save and restore any state around
-    the reset. The caller should save and restore state as needed.

-

-

-

-
Message Signaled Interrupts (MSI) and Enhanced Message Signaled
-    Interrupts (MSI-X) are PCI capabilities that provide an alternate method for
-    PCI devices to signal interrupts. The legacy INTx interrupt is available to
-    PCI devices as a SYS_RES_IRQ resource with a
-    resource ID of zero. MSI and MSI-X interrupts are available to PCI devices
-    as one or more SYS_RES_IRQ resources with resource
-    IDs greater than zero. A driver must ask the PCI bus to allocate MSI or
-    MSI-X interrupts using pci_alloc_msi() or
-    pci_alloc_msix() before it can use MSI or MSI-X
-    SYS_RES_IRQ resources. A driver is not allowed to
-    use the legacy INTx SYS_RES_IRQ resource if MSI or
-    MSI-X interrupts have been allocated, and attempts to allocate MSI or MSI-X
-    interrupts will fail if the driver is currently using the legacy INTx
-    SYS_RES_IRQ resource. A driver is only allowed to
-    use either MSI or MSI-X, but not both.

-
The
-    ()
-    function returns the maximum number of MSI messages supported by the device
-    dev. If the device does not support MSI, then
-    pci_msi_count() returns zero.

-
The
-    ()
-    function attempts to allocate *count MSI messages for
-    the device dev. The
-    pci_alloc_msi() function may allocate fewer messages
-    than requested for various reasons including requests for more messages than
-    the device dev supports, or if the system has a
-    shortage of available MSI messages. On success, *count
-    is set to the number of messages allocated and
-    pci_alloc_msi() returns zero. The
-    SYS_RES_IRQ resources for the allocated messages
-    will be available at consecutive resource IDs beginning with one. If
-    pci_alloc_msi() is not able to allocate any
-    messages, it returns an error. Note that MSI only supports message counts
-    that are powers of two; requests to allocate a non-power of two count of
-    messages will fail.

-
The
-    ()
-    function is used to release any allocated MSI or MSI-X messages back to the
-    system. If any MSI or MSI-X SYS_RES_IRQ resources
-    are allocated by the driver or have a configured interrupt handler, this
-    function will fail with EBUSY. The
-    pci_release_msi() function returns zero on success
-    and an error on failure.

-
The
-    ()
-    function returns the maximum number of MSI-X messages supported by the
-    device dev. If the device does not support MSI-X, then
-    pci_msix_count() returns zero.

-
The
-    ()
-    function returns the offset in configuration space of the Base Address
-    Register (BAR) containing the MSI-X Pending Bit Array (PBA) for device
-    dev. The returned value can be used as the resource ID
-    with bus_alloc_resource(9) and
-    bus_release_resource(9) to allocate the BAR. If the device
-    does not support MSI-X, then pci_msix_pba_bar()
-    returns -1.

-
The
-    ()
-    function returns the offset in configuration space of the BAR containing the
-    MSI-X vector table for device dev. The returned value
-    can be used as the resource ID with bus_alloc_resource(9)
-    and bus_release_resource(9) to allocate the BAR. If the
-    device does not support MSI-X, then
-    pci_msix_table_bar() returns -1.

-
The
-    ()
-    function attempts to allocate *count MSI-X messages
-    for the device dev. The
-    pci_alloc_msix() function may allocate fewer
-    messages than requested for various reasons including requests for more
-    messages than the device dev supports, or if the
-    system has a shortage of available MSI-X messages. On success,
-    *count is set to the number of messages allocated and
-    pci_alloc_msix() returns zero. For MSI-X messages,
-    the resource ID for each SYS_RES_IRQ resource
-    identifies the index in the MSI-X table of the corresponding message. A
-    resource ID of one maps to the first index of the MSI-X table; a resource ID
-    two identifies the second index in the table, etc. The
-    pci_alloc_msix() function assigns the
-    *count messages allocated to the first
-    *count table indices. If
-    pci_alloc_msix() is not able to allocate any
-    messages, it returns an error. Unlike MSI, MSI-X does not require message
-    counts that are powers of two.

-
The BARs containing the MSI-X vector table
-    and PBA must be allocated via bus_alloc_resource(9) before
-    calling
-    ()
-    and must not be released until after calling
-    pci_release_msi(). Note that the vector table and
-    PBA may be stored in the same BAR or in different BARs.

-
The
-    ()
-    function examines the dev device's PBA to determine
-    the pending status of the MSI-X message at table index
-    index. If the indicated message is pending, this
-    function returns a non-zero value; otherwise, it returns zero. Passing an
-    invalid index to this function will result in
-    undefined behavior.

-
As mentioned in the description of
-    (),
-    MSI-X messages are initially assigned to the first N table entries. A driver
-    may use a different distribution of available messages to table entries via
-    the pci_remap_msix() function. Note that this
-    function must be called after a successful call to
-    pci_alloc_msix() but before any of the
-    SYS_RES_IRQ resources are allocated. The
-    pci_remap_msix() function returns zero on success,
-    or an error on failure.

-
The vectors array
-    should contain count message vectors. The array maps
-    directly to the MSI-X table in that the first entry in the array specifies
-    the message used for the first entry in the MSI-X table, the second entry in
-    the array corresponds to the second entry in the MSI-X table, etc. The
-    vector value in each array index can either be zero to indicate that no
-    message should be assigned to the corresponding MSI-X table entry, or it can
-    be a number from one to N (where N is the count returned from the previous
-    call to
-    ())
-    to indicate which of the allocated messages should be assigned to the
-    corresponding MSI-X table entry.

-
If
-    ()
-    succeeds, each MSI-X table entry with a non-zero vector will have an
-    associated SYS_RES_IRQ resource whose resource ID
-    corresponds to the table index as described above for
-    pci_alloc_msix(). MSI-X table entries that with a
-    vector of zero will not have an associated
-    SYS_RES_IRQ resource. Additionally, if any of the
-    original messages allocated by pci_alloc_msix() are
-    not used in the new distribution of messages in the MSI-X table, they will
-    be released automatically. Note that if a driver wishes to use fewer
-    messages than were allocated by pci_alloc_msix(),
-    the driver must use a single, contiguous range of messages beginning with
-    one in the new distribution. The pci_remap_msix()
-    function will fail if this condition is not met.

-

-

-

-
The pci_add_device event handler is invoked
-    every time a new PCI device is added to the system. This includes the
-    creation of Virtual Functions via SR-IOV.

-
The pci_delete_device event handler is
-    invoked every time a PCI device is removed from the system.

-
Both event handlers pass the device_t object
-    of the relevant PCI device as dev to each callback
-    function. Both event handlers are invoked while dev is
-    unattached but with valid instance variables.

-

-

-

-

-
pci(4), pciconf(8),
-    bus_alloc_resource(9), bus_dma(9),
-    bus_release_resource(9),
-    bus_setup_intr(9), bus_teardown_intr(9),
-    devclass(9), device(9),
-    driver(9), eventhandler(9),
-    rman(9)

-
NewBus,
-    FreeBSD Developers' Handbook,
-    https://docs.freebsd.org/en/books/developers-handbook/.

-
Shanley and
-    Anderson, PCI System
-    Architecture, Addison-Wesley, 2nd
-    Edition, ISBN 0-201-30974-2.

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@FreeBSD.org> and
-    John Baldwin
-    <jhb@FreeBSD.org>.

-

-

-

-
The kernel PCI code has a number of references to “slot
-    numbers”. These do not refer to the geographic location of PCI
-    devices, but to the device number assigned by the combination of the PCI
-    IDSEL mechanism and the platform firmware. This should be taken note of when
-    working with the kernel PCI code.

-
The PCI bus driver should allocate the MSI-X vector table and PBA
-    internally as necessary rather than requiring the caller to do so.

-

-

-
-  
-    
-    
-  
-
March 27, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/pci_iov_schema.9 3.html b/static/freebsd/man9/pci_iov_schema.9 3.html
deleted file mode 100644
index ae4d9e47..00000000
--- a/static/freebsd/man9/pci_iov_schema.9 3.html	
+++ /dev/null
@@ -1,233 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_IOV_SCHEMA(9)Kernel Developer's ManualPCI_IOV_SCHEMA(9)

-

-

-

-
pci_iov_schema,
-    pci_iov_schema_alloc_node,
-    pci_iov_schema_add_bool,
-    pci_iov_schema_add_string,
-    pci_iov_schema_add_uint8,
-    pci_iov_schema_add_uint16,
-    pci_iov_schema_add_uint32,
-    pci_iov_schema_add_uint64,
-    pci_iov_schema_add_unicast_mac —
-    PCI SR-IOV config schema interface

-

-

-

-
#include
-    <sys/stdarg.h>
-  

-  #include <sys/nv.h>
-  

-  #include
-  <sys/iov_schema.h>

-
nvlist_t *
-  

-  pci_iov_schema_alloc_node(void);

-
void
-  

-  pci_iov_schema_add_bool(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, int
-    defaultVal);

-
void
-  

-  pci_iov_schema_add_string(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, const char
-    *defaultVal);

-
void
-  

-  pci_iov_schema_add_uint8(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, uint8_t
-    defaultVal);

-
void
-  

-  pci_iov_schema_add_uint16(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, uint16_t
-    defaultVal);

-
void
-  

-  pci_iov_schema_add_uint32(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, uint32_t
-    defaultVal);

-
void
-  

-  pci_iov_schema_add_uint64(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, uint64_t
-    defaultVal);

-
void
-  

-  pci_iov_schema_add_unicast_mac(nvlist_t
-    *schema, const char
-    *name, uint32_t
-    flags, const uint8_t
-    *defaultVal);

-

-

-

-
The PCI Single-Root I/O Virtualization (SR-IOV) configuration
-    schema is a data structure that describes the device-specific configuration
-    parameters that a PF driver will accept when SR-IOV is enabled on the PF
-    device. Each PF driver defines two schema instances: the PF schema and the
-    VF schema. The PF schema describes configuration that applies to the PF
-    device as a whole. The VF schema describes configuration that applies to an
-    individual VF device. Different VF devices may have different configuration
-    applied to them, as long as the configuration for each VF conforms to the VF
-    schema.

-
A PF driver builds a configuration schema by first allocating a
-    schema node and then adding configuration parameter specifications to the
-    schema. The configuration parameter specification consists of a name and a
-    value type.

-
Configuration parameter names are case-insensitive. It is an error
-    to specify two or more configuration parameters with the same name. It is
-    also an error to specific a configuration parameter that uses the same name
-    as a configuration parameter used by the SR-IOV infrastructure. See
-    iovctl.conf(5) for documentation of all configuration
-    parameters used by the SR-IOV infrastructure.

-
The parameter type constrains the possible values that the
-    configuration parameter may take.

-
A configuration parameter may be specified as a required parameter
-    by setting the IOV_SCHEMA_REQUIRED flag in the
-    flags argument. Required parameters must be
-    specified by the user when SR-IOV is enabled. If the user does not specify a
-    required parameter, the SR-IOV infrastructure will abort the request to
-    enable SR-IOV and return an error to the user.

-
Alternatively, a configuration parameter may be given a default
-    value by setting the IOV_SCHEMA_HASDEFAULT flag in
-    the flags argument. If a configuration parameter has
-    a default value but the user has not specified a value for that parameter,
-    then the SR-IOV infrastructure will apply defaultVal
-    for that parameter in the configuration before passing it to the PF driver.
-    It is an error for the value of the defaultVal
-    parameter to not conform to the restrictions of the specified type. If this
-    flag is not specified then the defaultVal argument
-    is ignored. This flag is not compatible with the
-    IOV_SCHEMA_REQUIRED flag; it is an error to specify
-    both on the same parameter.

-
The SR-IOV infrastructure guarantees that all configuration
-    parameters that are either specified as required or given a default value
-    will be present in the configuration passed to the PF driver. Configuration
-    parameters that are neither specified as required nor given a default value
-    are optional and may or may not be present in the configuration passed to
-    the PF driver.

-
It is highly recommended that a PF driver reserve the use of
-    optional parameters for configuration that is truly optional. For example, a
-    Network Interface PF device might have the option to encapsulate all traffic
-    to and from a VF device in a vlan tag. The PF driver could expose that
-    option as a "vlan" parameter accepting an integer argument
-    specifying the vlan tag. In this case, it would be appropriate to set the
-    "vlan" parameter as an optional parameter as it would be
-    legitimate for a VF to be configured to have no vlan tagging enabled at
-  all.

-
Alternatively, if the PF device had an boolean option that
-    controlled whether the VF was allowed to change its MAC address, it would
-    not be appropriate to set this parameter as optional. The PF driver must
-    either allow the MAC to change or not, so it would be more appropriate for
-    the PF driver to document the default behaviour by specifying a default
-    value in the schema (or potentially force the user to make the choice by
-    setting the parameter to be required).

-
Configuration parameters that have security implications must
-    default to the most secure configuration possible.

-
All device-specific configuration parameters must be documented in
-    the manual page for the PF driver, or in a separate manual page that is
-    cross-referenced from the main driver manual page.

-
It is not necessary for a PF driver to check for failure from any
-    of these functions. If an error occurs, it is flagged in the schema. The
-    pci_iov_attach(9) function checks for this error and will
-    fail to initialize SR-IOV on the PF device if an error is set in the schema.
-    If this occurs, it is recommended that the PF driver still succeed in
-    attaching and run with SR-IOV disabled on the device.

-
The
-    ()
-    function is used to allocate an empty configuration schema. It is not
-    necessary to check for failure from this function. The SR-IOV infrastructure
-    will gracefully handle failure to allocate a schema and will simply not
-    enable SR-IOV on the PF device.

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a boolean type.
-    Boolean values can only take the value true or false (1 or 0,
-  respectively).

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a string type. String
-    values are standard C strings.

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a
-    uint8_t type. Values of type
-    uint8_t are unsigned integers in the range 0 to 255,
-    inclusive.

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a
-    uint16_t type. Values of type
-    uint16_t are unsigned integers in the range 0 to
-    65535, inclusive.

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a
-    uint32_t type. Values of type
-    uint32_t are unsigned integers in the range 0 to
-    (2**32 - 1), inclusive.

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a
-    uint64_t type. Values of type
-    uint64_t are unsigned integers in the range 0 to
-    (2**64 - 1), inclusive.

-
The
-    ()
-    function is used to specify a configuration parameter in the given schema
-    with the name name and having a unicast-mac type.
-    Values of type unicast-mac are binary values exactly 6 bytes long. The MAC
-    address is guaranteed to not be a multicast or broadcast address.

-

-

-

-
The pci_iov_schema_alloc_node() function
-    returns a pointer to the allocated schema, or NULL if a failure occurs.

-

-

-

-
pci(9), PCI_IOV_ADD_VF(9),
-    PCI_IOV_INIT(9)

-

-

-

-
This manual page was written by Ryan Stone
-    ⟨rstone@FreeBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
July 8, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/pfil.9 3.html b/static/freebsd/man9/pfil.9 3.html
deleted file mode 100644
index 1a7b42e2..00000000
--- a/static/freebsd/man9/pfil.9 3.html	
+++ /dev/null
@@ -1,135 +0,0 @@
-
-  
-    
-    
-    
-  
-
PFIL(9)Kernel Developer's ManualPFIL(9)

-

-

-

-
pfil,
-    pfil_head_register,
-    pfil_head_unregister,
-    pfil_link, pfil_run_hooks
-    — packet filter interface

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mbuf.h>
-  

-  #include <net/pfil.h>

-
pfil_head_t
-  

-  pfil_head_register(struct
-    pfil_head_args *args);

-
void
-  

-  pfil_head_unregister(struct
-    pfil_head_t *head);

-
pfil_hook_t
-  

-  pfil_add_hook(struct
-    pfil_hook_args *);

-
void
-  

-  pfil_remove_hook(pfil_hook_t);

-
int
-  

-  pfil_link(struct
-    pfil_link_args *args);

-
int
-  

-  pfil_run_hooks(phil_head_t
-    *, pfil_packet_t,
-    struct ifnet *,
-    int,
-    struct inpcb *);

-

-

-

-
The pfil framework allows for a specified
-    function or a list of functions to be invoked for every incoming or outgoing
-    packet for a particular network I/O stream. These hooks may be used to
-    implement a firewall or perform packet transformations.

-
Packet filtering points, for historical reasons named
-    , are
-    registered with
-    ().
-    The function is supplied with special versioned struct
-    pfil_head_args structure that specifies type and features of the head
-    as well as human readable name. If the filtering point to be ever destroyed,
-    the subsystem that created it must unregister it with call to
-    ().

-
Packet filtering systems may register arbitrary number
-    of filters, for historical reasons named
-    . To register
-    a new hook
-    ()
-    with special versioned struct pfil_hook_args structure
-    is called. The structure specifies type and features of the hook, pointer to
-    the actual filtering function and user readable name of the filtering module
-    and ruleset name. Later hooks can be removed with
-    ()
-    functions.

-
To connect existing
-     to an existing
-    head function
-    ()
-    shall be used. The function is supplied with versioned
-    struct pfil_link_args structure that specifies either
-    literal names of hook and head or pointers to them. Typically
-    pfil_link() is called by filtering modules to
-    autoregister their default ruleset and default filtering points. It also
-    serves on the kernel side of ioctl(2) when user changes
-    pfil configuration with help of
-    pfilctl(8) utility.

-
For every packet traveling through a
-    head the latter shall invoke
-    ().
-    The function can accept either struct mbuf * pointer
-    or a void * pointer and length. In case if a hooked
-    filtering module cannot understand void * pointer
-    pfil will provide it with a fake one. All calls to
-    pfil_run_hooks() are performed in network
-    epoch(9).

-

-

-

-
By default kernel creates the following heads:

-

-  
inet

-  
IPv4 packets.

-  
inet6

-  
IPv6 packets.

-  
ethernet

-  
Link-layer packets.

-

-
Default rulesets are automatically linked to these heads to
-    preserve historical behaviour.

-

-

-

-
ipfilter(4), ipfw(4),
-    pf(4), pfilctl(8)

-

-

-

-
The pfil interface first appeared in
-    NetBSD 1.3. The pfil
-    interface was imported into FreeBSD 5.2. In
-    FreeBSD 13.0 the interface was significantly
-    rewritten.

-

-

-
-  
-    
-    
-  
-
January 28, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/pfind.9 4.html b/static/freebsd/man9/pfind.9 4.html
deleted file mode 100644
index 9ec43a3f..00000000
--- a/static/freebsd/man9/pfind.9 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
PFIND(9)Kernel Developer's ManualPFIND(9)

-

-

-

-
pfind, pfind_any,
-    pfind_any_locked — locate a
-    process by number

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
struct proc *
-  

-  pfind(pid_t
-    pid);

-
struct proc *
-  

-  pfind_any(pid_t
-    pid);

-
struct proc *
-  

-  pfind_any_locked(pid_t
-    pid);

-

-

-

-
The
-    ()
-    function walks the list of processes in the system, looking for the one with
-    a process ID of pid. If the process exists, and is not
-    in the zombie state, a pointer to the process structure will be
-  returned.

-
()
-    takes a pid as its argument.
-    pfind_any() searches the
-    allproc list and returns the first process with a
-    matching PID, whose state may be PRS_ZOMBIE.

-
()
-    is similar to pfind_any(), but it does not lock the
-    process hash bucket for the given pid. Instead, it
-    asserts the corresponding process hash bucket is already locked.

-
All three functions
-    (),
-    pfind_any(), and
-    pfind_any_locked() lock the
-    proc structure before returning.

-

-

-

-
pfind(),
-    pfind_any(), and
-    pfind_any_locked() return pointer to a
-    proc structure on success or
-    NULL on failure.

-

-

-

-
pget(9), pgfind(9)

-

-

-

-
This manual page was written by Evan
-    Sarmiento
-    <kaworu@sektor7.ath.cx>.

-

-

-
-  
-    
-    
-  
-
November 3, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/pget.9 4.html b/static/freebsd/man9/pget.9 4.html
deleted file mode 100644
index 5f143c73..00000000
--- a/static/freebsd/man9/pget.9 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
PGET(9)Kernel Developer's ManualPGET(9)

-

-

-

-
pget — locate a
-    process by number

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
int
-  

-  pget(pid_t
-    pid, int flags,
-    struct proc **pp);

-

-

-

-
This function takes a pid as its argument,
-    which can be either a process or thread id, and fills a pointer to the
-    proc structure in *pp. In the
-    latter case, a process owning the specified thread is looked for. The
-    operation is performed by invoking the pfind(9) function.
-    The found process is returned locked. For the
-    PGET_HOLD case, it is returned unlocked (but held).
-    The
-    ()
-    function can perform additional manipulations, depending on a
-    flags argument.

-
The flags argument is the logical OR of some
-    subset of:

-

-  

-  
If set, the found process will be held and unlocked.

-  

-  
If set, the found process will be checked for its visibility. See
-      p_cansee(9).

-  

-  
If set, the found process will be checked for its debuggability. See
-      p_candebug(9).

-  

-  
If set, the found process will be checked that it matches the current
-      process context.

-  

-  
If set, the found process will be checked that it does not have the
-      process flag P_WEXIT set.

-  

-  
If set, the found process will be checked that it does not have the
-      process flag P_INEXEC set.

-  

-  
If set, pid is not assumed as a thread id for values
-      larger than PID_MAX.

-  

-  
If set, the found process will be checked that the caller may get a read
-      access to its structure. A shorthand for
-      (PGET_HOLD | PGET_CANDEBUG
-      | PGET_NOTWEXIT).

-

-

-

-

-
If the process is found in the specified way, then zero is
-    returned, otherwise an appropriate error code is returned.

-

-

-

-
p_candebug(9), p_cansee(9),
-    pfind(9)

-

-

-
-  
-    
-    
-  
-
May 3, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/pgfind.9 4.html b/static/freebsd/man9/pgfind.9 4.html
deleted file mode 100644
index e9830402..00000000
--- a/static/freebsd/man9/pgfind.9 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
PGFIND(9)Kernel Developer's ManualPGFIND(9)

-

-

-

-
pgfind — locate a
-    process group by number

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
struct pgrp *
-  

-  pgfind(pid_t
-    pgid);

-

-

-

-
The
-    ()
-    function takes a pgid as its argument and returns a
-    pointer to the pgrp structure whose
-    pg_id is specified in the argument.

-
()
-    locks the pgrp structure that is returned.

-

-

-

-
The pgfind() function returns
-    NULL on failure or a pointer to a
-    pgrp structure on successful completion.

-

-

-

-
pfind(9)

-

-

-

-
This manual page was written by Evan
-    Sarmiento
-    <kaworu@sektor7.ath.cx>.

-

-

-
-  
-    
-    
-  
-
August 8, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/physio.9 4.html b/static/freebsd/man9/physio.9 4.html
deleted file mode 100644
index 2992988d..00000000
--- a/static/freebsd/man9/physio.9 4.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
PHYSIO(9)Kernel Developer's ManualPHYSIO(9)

-

-

-

-
physio — initiate
-    I/O on raw devices

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/bio.h>
-  

-  #include <sys/buf.h>

-
int
-  

-  physio(struct
-    cdev *dev, struct uio
-    *uio, int
-  ioflag);

-

-

-

-
The
-    ()
-    is a helper function typically called from character device
-    read() and write() routines
-    to start I/O on a user process buffer. The maximum amount of data to
-    transfer with each call is determined by
-    dev->si_iosize_max. The
-    physio() call converts the I/O request into a
-    ()
-    request and passes the new request to the driver's
-    strategy() routine for processing.

-
Since uio normally describes
-    user space addresses,
-    ()
-    needs to lock those pages into memory. This is done by calling
-    ()
-    for the appropriate pages. physio() always awaits
-    the completion of the entire requested transfer before returning, unless an
-    error condition is detected earlier.

-
A break-down of the arguments follows:

-

-  
dev

-  
The device number identifying the device to interact with.

-  
uio

-  
The description of the entire transfer as requested by the user process.
-      Currently, the results of passing a uio structure
-      with the uio_segflg set to anything other than
-      UIO_USERSPACE are undefined.

-  
ioflag

-  
The ioflag argument from the
-      () or
-      ()
-      function calling physio().

-

-

-

-

-
If successful physio() returns 0.
-    EFAULT is returned if the address range described by
-    uio is not accessible by the requesting process.
-    physio() will return any error resulting from calls
-    to the device strategy routine, by examining the
-    B_ERROR buffer flag and the
-    b_error field. Note that the actual transfer size may
-    be less than requested by uio if the device signals an
-    “end of file” condition.

-

-

-

-
read(2), write(2)

-

-

-

-
The physio manual page is originally from
-    NetBSD with minor changes for applicability with
-    FreeBSD.

-
The physio call has been completely
-    re-written for providing higher I/O and paging performance.

-

-

-
-  
-    
-    
-  
-
January 19, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap.9 4.html b/static/freebsd/man9/pmap.9 4.html
deleted file mode 100644
index 7f71ac8d..00000000
--- a/static/freebsd/man9/pmap.9 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP(9)Kernel Developer's ManualPMAP(9)

-

-

-

-
pmap —
-    machine-dependent portion of virtual memory
-    subsystem

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-

-

-

-
The pmap module is the machine-dependent
-    portion of the FreeBSD VM (Virtual Memory)
-    sub-system. Each function documented herein must have its own
-    architecture-dependent implementation.

-
The pmap module is responsible for
-    managing hardware-dependent objects such as page tables, address maps, TLBs,
-    etc.

-
Machine-dependent code must provide the header file
-    <machine/pmap.h>. This file
-    contains the definition of the pmap structure:

-

-
struct pmap {
-        /* Contents defined by pmap implementation. */
-};
-typedef struct pmap *pmap_t;

-

-
This header file may also define other data structures used by the
-    pmap implementation.

-
The header file
-    <vm/pmap.h> defines a
-    structure for tracking pmap statistics (see below).
-    This structure is defined as:

-

-
struct pmap_statistics {
-        long        resident_count; /* number of mapped pages */
-        long        wired_count;    /* number of wired pages */
-};

-

-
The implementation's struct pmap must
-    contain an instance of this structure having the name
-    pm_stats, and it must be updated by the implementation
-    after each relevant pmap operation.

-

-

-

-
pmap_activate(9),
-    pmap_clear_modify(9), pmap_copy(9),
-    pmap_copy_page(9), pmap_enter(9),
-    pmap_extract(9),
-    pmap_extract_and_hold(9),
-    pmap_growkernel(9), pmap_init(9),
-    pmap_is_modified(9),
-    pmap_is_prefaultable(9),
-    pmap_kextract(9), pmap_map(9),
-    pmap_mincore(9), pmap_object_init_pt(9),
-    pmap_page_exists_quick(9),
-    pmap_page_init(9), pmap_pinit(9),
-    pmap_pinit0(9), pmap_protect(9),
-    pmap_qenter(9), pmap_qremove(9),
-    pmap_quick_enter_page(9),
-    pmap_quick_remove_page(9),
-    pmap_release(9), pmap_remove(9),
-    pmap_remove_all(9),
-    pmap_remove_pages(9),
-    pmap_resident_count(9),
-    pmap_ts_referenced(9), pmap_unwire(9),
-    pmap_wired_count(9), pmap_zero_area(9),
-    pmap_zero_page(9), vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
January 12, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_activate.9 4.html b/static/freebsd/man9/pmap_activate.9 4.html
deleted file mode 100644
index de2fd7da..00000000
--- a/static/freebsd/man9/pmap_activate.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_ACTIVATE(9)Kernel Developer's ManualPMAP_ACTIVATE(9)

-

-

-

-
pmap_activate —
-    activate a physical map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_activate(struct
-    thread *td);

-

-

-

-
The
-    ()
-    function activates the physical map for a user thread
-    td. This function must be called before the thread's
-    address space may be accessed.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_clear_modify.9 4.html b/static/freebsd/man9/pmap_clear_modify.9 4.html
deleted file mode 100644
index 1debe353..00000000
--- a/static/freebsd/man9/pmap_clear_modify.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_CLEAR_MODIFY(9)Kernel Developer's ManualPMAP_CLEAR_MODIFY(9)

-

-

-

-
pmap_clear_modify —
-    set information about physical pages

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_clear_modify(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    function clears the “modified” bit on the physical page
-    m.

-

-

-

-
pmap(9),
-  pmap_is_modified(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 17, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_copy.9 4.html b/static/freebsd/man9/pmap_copy.9 4.html
deleted file mode 100644
index 0126b737..00000000
--- a/static/freebsd/man9/pmap_copy.9 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_COPY(9)Kernel Developer's ManualPMAP_COPY(9)

-

-

-

-
pmap_copy,
-    pmap_copy_page — copy
-    physical memory pages

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_copy(pmap_t dst_pmap,
-    pmap_t src_pmap, vm_offset_t
-    dst_addr, vm_size_t len,
-    vm_offset_t src_addr);

-
void
-  

-  pmap_copy_page(vm_page_t
-    src, vm_page_t
-    dst);

-

-

-

-
The
-    ()
-    function copies the range specified by src_addr and
-    len from the source physical map
-    src_pmap to the destination physical map
-    dst_pmap at the address
-    dst_addr.

-
The
-    ()
-    function copies the physical page src to the physical
-    page dst, by mapping the page into kernel virtual
-    address space (KVA), and using
-    ()
-    to copy the page.

-

-

-

-
The pmap_copy() routine is only advisory
-    and need not do anything. Actually implementing it may seriously reduce
-    system performance.

-
The pmap_copy_page() routine only operates
-    upon a single page.

-

-

-

-
bcopy(3), pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_enter.9 3.html b/static/freebsd/man9/pmap_enter.9 3.html
deleted file mode 100644
index 2070b99f..00000000
--- a/static/freebsd/man9/pmap_enter.9 3.html	
+++ /dev/null
@@ -1,134 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_ENTER(9)Kernel Developer's ManualPMAP_ENTER(9)

-

-

-

-
pmap_enter —
-    insert a virtual page into a physical map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
int
-  

-  pmap_enter(pmap_t pmap,
-    vm_offset_t va, vm_page_t m,
-    vm_prot_t prot, u_int flags,
-    int8_t psind);

-

-

-

-
The
-    ()
-    function creates a mapping in the physical map pmap
-    from the virtual address va to the physical page
-    m with the protection prot. Any
-    previous mapping at the virtual address va is
-    destroyed.

-
The flags argument may have the following
-    values:

-

-  

-  
A read access to the given virtual address triggered the call.

-  

-  
A write access to the given virtual address triggered the call.

-  

-  
An execute access to the given virtual address triggered the call.

-  

-  
The mapping should be marked as wired.

-  

-  
This function may not sleep during creation of the mapping. If the mapping
-      cannot be created without sleeping, an appropriate Mach VM error is
-      returned.

-

-If the PMAP_ENTER_NOSLEEP flag is not specified, this
-  function must create the requested mapping before returning. It may not fail.
-  In order to create the requested mapping, this function may destroy any
-  non-wired mapping in any pmap.
-
The psind parameter specifies the page size
-    that should be used by the mapping. The supported page sizes are described
-    by the global array pagesizes[]. The desired page
-    size is specified by passing the index of the array element that equals the
-    desired page size.

-
When the
-    ()
-    function destroys or updates a managed mapping, including an existing
-    mapping at virtual address va, it updates the
-    vm_page structure corresponding to the previously
-    mapped physical page. If the physical page was accessed through the managed
-    mapping, then the vm_page structure's
-    PGA_REFERENCED aflag is set. If the physical page
-    was modified through the managed mapping, then the
-    ()
-    function is called on the vm_page structure.

-
The PGA_WRITEABLE aflag must be set for
-    the page m if the new mapping is managed and
-    writeable. It is advised to clear PGA_WRITEABLE for
-    destroyed mappings if the implementation can ensure that no other writeable
-    managed mappings for the previously mapped pages exist.

-
If the request modifies an existing mapping to use a different
-    physical page, an implementation of pmap_enter must
-    invalidate the previous mapping before installing the new one. This ensures
-    that all threads sharing the pmap keep a consistent view of the mapping,
-    which is necessary for the correct handling of CoW (copy on write)
-  faults.

-
If the page m is managed, the page must be
-    busied by the caller or the owning object must be locked. In the later case,
-    the PMAP_ENTER_NOSLEEP must be specified by the
-    caller.

-
The
-    ()
-    function must handle the multiprocessor TLB consistency for the given
-    address.

-

-

-

-
On arm and i386 architectures the existing implementation of the
-    pmap_enter function is incomplete, only value 0 for
-    psind is supported. Other supported architectures,
-    except amd64, have pagesizes[] array of size 1.

-

-

-

-
If successful, the pmap_enter() function
-    returns KERN_SUCCESS. If the
-    PMAP_ENTER_NOSLEEP flag was specified and the
-    resources required for the mapping cannot be acquired without sleeping,
-    KERN_RESOURCE_SHORTAGE is returned.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was first written by Bruce M
-    Simpson
-    <bms@spc.org> and then
-    rewritten by
-  

-  Alan Cox
-    <alc@FreeBSD.org> and
-  

-  Konstantin Belousov
-    <kib@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 16, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_extract.9 4.html b/static/freebsd/man9/pmap_extract.9 4.html
deleted file mode 100644
index b78eb29a..00000000
--- a/static/freebsd/man9/pmap_extract.9 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_EXTRACT(9)Kernel Developer's ManualPMAP_EXTRACT(9)

-

-

-

-
pmap_extract,
-    pmap_extract_and_hold — map
-    a virtual address to a physical page

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
vm_paddr_t
-  

-  pmap_extract(pmap_t
-    pmap, vm_offset_t
-    va);

-
vm_page_t
-  

-  pmap_extract_and_hold(pmap_t
-    pmap, vm_offset_t
-    va, vm_prot_t
-    prot);

-

-

-

-
The
-    ()
-    function maps a virtual address to a physical page. In certain situations,
-    callers may use pmap_extract_and_hold() instead, to
-    ensure that the returned page is held.

-
The
-    ()
-    function maps a virtual address to a physical page, and atomically holds the
-    returned page for use by the caller, only if the mapping permits the given
-    page protection.

-

-

-

-
Currently, the page protection requested by the caller is not
-    verified.

-

-

-

-
The pmap_extract() function will return
-    the physical page address associated with the virtual address
-    va inside the physical map pmap.
-    If the mapping does not exist, or if the pmap
-    parameter is NULL, then NULL
-    will be returned.

-
The pmap_extract_and_hold() function will
-    return the vm_page_t associated with the virtual
-    address va inside the physical map
-    pmap. If the mapping does not exist, the result is a
-    no-op, and NULL will be returned.

-

-

-

-
mutex(9), pmap(9)

-

-

-

-
The pmap_extract_and_hold() function was
-    implemented by Alan L. Cox
-    <alc@imimic.com>. This
-    manual page was written by Bruce M Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_growkernel.9 4.html b/static/freebsd/man9/pmap_growkernel.9 4.html
deleted file mode 100644
index 54b08971..00000000
--- a/static/freebsd/man9/pmap_growkernel.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_GROWKERNEL(9)Kernel Developer's ManualPMAP_GROWKERNEL(9)

-

-

-

-
pmap_growkernel —
-    grow the kernel virtual address (KVA) space

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_growkernel(vm_offset_t
-    addr);

-

-

-

-
The
-    ()
-    function grows the kernel virtual address space to the virtual address
-    addr.

-
It will allocate more page entries if required.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_init.9 4.html b/static/freebsd/man9/pmap_init.9 4.html
deleted file mode 100644
index 6c49b889..00000000
--- a/static/freebsd/man9/pmap_init.9 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_INIT(9)Kernel Developer's ManualPMAP_INIT(9)

-

-

-

-
pmap_init —
-    initialize the pmap subsystem

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_init(void);

-

-

-

-
The
-    ()
-    function initializes the pmap(9) sub-system. It is called
-    during system initialization by
-    (),
-    to initialize any structures that the pmap_init
-    system needs in order to map between physical and virtual memory.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
January 12, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_is_modified.9 4.html b/static/freebsd/man9/pmap_is_modified.9 4.html
deleted file mode 100644
index 66598ad0..00000000
--- a/static/freebsd/man9/pmap_is_modified.9 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_IS_MODIFIED(9)Kernel Developer's ManualPMAP_IS_MODIFIED(9)

-

-

-

-
pmap_is_modified,
-    pmap_ts_modified — return
-    information about physical pages

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
bool
-  

-  pmap_is_modified(vm_page_t
-    m);

-
int
-  

-  pmap_ts_referenced(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions return information about physical pages.

-

-

-

-
The pmap_is_modified() function returns
-    the status of the “page modified” bit for the physical page
-    m.

-
The pmap_ts_referenced() function returns
-    a count of reference bits for a page m, clearing those
-    bits. It is not necessary for every reference bit to be cleared, but it is
-    necessary that 0 only be returned when there are no remaining reference bits
-    set on the page.

-

-

-

-
pmap(9),
-  pmap_clear_modify(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 17, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_is_prefaultable.9 4.html b/static/freebsd/man9/pmap_is_prefaultable.9 4.html
deleted file mode 100644
index 5ff4daae..00000000
--- a/static/freebsd/man9/pmap_is_prefaultable.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_IS_PREFAULTABLE(9)Kernel Developer's ManualPMAP_IS_PREFAULTABLE(9)

-

-

-

-
pmap_is_prefaultable —
-    determine if a page may be prefaulted

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
bool
-  

-  pmap_is_prefaultable(pmap_t
-    pmap, vm_offset_t
-    va);

-

-

-

-
The
-    ()
-    function provides a means of determining if the page residing at virtual
-    address va in the physical map
-    pmap may be pre-faulted into main memory.

-
This is a helper function which is called by
-    vm_fault_prefault(9).

-

-

-

-
pmap(9),
-  vm_fault_prefault(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_kextract.9 4.html b/static/freebsd/man9/pmap_kextract.9 4.html
deleted file mode 100644
index 7a829224..00000000
--- a/static/freebsd/man9/pmap_kextract.9 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_KEXTRACT(9)Kernel Developer's ManualPMAP_KEXTRACT(9)

-

-

-

-
pmap_kextract,
-    vtophys — extract a physical
-    address from the kernel page table

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
vm_paddr_t
-  

-  pmap_kextract(vm_offset_t
-  va);

-
vm_paddr_t
-  

-  vtophys(vm_offset_t va);

-

-

-

-
The
-    ()
-    function retrieves the underlying physical memory address corresponding to
-    the given kernel virtual address va. The caller is
-    responsible for ensuring that va belongs to a valid
-    mapping in the kernel address space. The returned physical address is only
-    meaningful as long as the mapping remains stable, so the caller must also
-    have some knowledge or guarantee of the mapping's lifetime. For example, it
-    is invalid to call pmap_kextract() with the address
-    of a malloc'd object while there is a possibility for that object to be
-    freed concurrently.

-
Unlike pmap_extract(9),
-    ()
-    is safe to be called from any context; it has no internal locking or
-  sleep.

-
()
-    is an alias for pmap_kextract() and behaves
-    identically.

-

-

-

-
The pmap_kextract() function returns the
-    physical address of memory mapped at the kernel virtual address
-    va.

-
pmap_kextract() generally does not fail.
-    However, if supplied with an illegitimate value for
-    va, the function may return zero, an invalid non-zero
-    value, or call panic(9).

-

-

-

-
pmap(9), pmap_extract(9)

-

-

-

-
This manual page was written by Mina
-    Galić
-    <FreeBSD@igalic.co>,
-    based on the pmap_extract(9) page written by
-    Bruce M Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
October 16, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_map.9 4.html b/static/freebsd/man9/pmap_map.9 4.html
deleted file mode 100644
index ea955ec5..00000000
--- a/static/freebsd/man9/pmap_map.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_MAP(9)Kernel Developer's ManualPMAP_MAP(9)

-

-

-

-
pmap_map — map a
-    physical memory range into kernel virtual address (KVA) space

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
vm_offset_t
-  

-  pmap_map(vm_offset_t *virt,
-    vm_paddr_t start, vm_paddr_t
-    end, int prot);

-

-

-

-
The
-    ()
-    function maps a range of physical addresses into kernel virtual address
-    (KVA) space, from start to end,
-    with protection bits prot.

-
The value passed in *virt is treated as a
-    hint for the virtual address of the beginning of the mapping.

-

-

-

-
The prot argument is currently ignored by
-    machine-dependent implementations.

-
Architectures which can support a direct mapped physical to
-    virtual region can return the appropriate address within that region,
-    leaving *virt unchanged.

-

-

-

-
The pmap_map() function returns the
-    virtual address of the beginning of the mapping, if the mapping was
-    successfully made; *virt will also be updated with the
-    first usable address after the mapped region.

-
If the function is unsuccessful, NULL is
-    returned.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_mincore.9 4.html b/static/freebsd/man9/pmap_mincore.9 4.html
deleted file mode 100644
index 837ec067..00000000
--- a/static/freebsd/man9/pmap_mincore.9 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_MINCORE(9)Kernel Developer's ManualPMAP_MINCORE(9)

-

-

-

-
pmap_mincore —
-    determine if a virtual address is resident in physical
-    memory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
int
-  

-  pmap_mincore(pmap_t
-    pmap, vm_offset_t
-    addr);

-

-

-

-
The
-    ()
-    function determines if the page at the virtual address
-    addr in the physical map pmap is
-    resident in physical memory. It is the machine-dependent interface used by
-    the mincore(2) system call.

-

-

-

-
If the page is resident in physical memory, a mask of flags is
-    returned, whose meaning is documented in mincore(2);
-    otherwise, 0 is returned.

-
The pmap must exist and
-    addr must be mapped into the
-    pmap. If any error occurs, the machine-dependent
-    implementation should return 0.

-

-

-

-
mincore(2), pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_object_init_pt.9 4.html b/static/freebsd/man9/pmap_object_init_pt.9 4.html
deleted file mode 100644
index 012081b1..00000000
--- a/static/freebsd/man9/pmap_object_init_pt.9 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_OBJECT_INIT_PT(9)Kernel Developer's ManualPMAP_OBJECT_INIT_PT(9)

-

-

-

-
pmap_object_init_pt —
-    initialize page tables for a VM object

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_object_init_pt(pmap_t pmap,
-    vm_offset_t addr, vm_object_t
-    object, vm_pindex_t pindex,
-    vm_size_t size, int limit);

-

-

-

-
The
-    ()
-    function preloads the page table entries into the specified physical map
-    pmap, for the given object at
-    the virtual address addr, for
-    size bytes, beginning at the page index
-    pindex within the object. The map bits
-    limit are heeded when creating the mapping.

-

-

-

-
This function is not strictly required by an architecture's
-    pmap(9) implementation, but it does provide performance
-    benefits if implemented.

-
It is intended to eliminate the blast of soft faults on process
-    startup, and immediately following a call to mmap(2).

-

-

-

-
pmap(9), vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_page_exists_quick.9 4.html b/static/freebsd/man9/pmap_page_exists_quick.9 4.html
deleted file mode 100644
index 310bc4b8..00000000
--- a/static/freebsd/man9/pmap_page_exists_quick.9 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_PAGE_EXISTS_QUICK(9)Kernel Developer's ManualPMAP_PAGE_EXISTS_QUICK(9)

-

-

-

-
pmap_page_exists_quick —
-    determine if a page exists in a physical map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
bool
-  

-  pmap_page_exists_quick(pmap_t
-    pmap, vm_page_t
-  m);

-

-

-

-
The
-    ()
-    function is used to quickly determine if the page m
-    exists in the physical map pmap. It is typically
-    called from the VM paging code.

-

-

-

-
The PV count used above may be changed upwards or downwards in
-    future; it is only necessary that true be returned
-    for a small subset of pmaps for proper page aging.

-

-

-

-
The pmap_page_exists_quick() returns
-    true only if the PV entry for the physical map
-    pmap is one of the first 16 PVs linked from the page
-    m.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_page_init.9 4.html b/static/freebsd/man9/pmap_page_init.9 4.html
deleted file mode 100644
index 8a3c7789..00000000
--- a/static/freebsd/man9/pmap_page_init.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_PAGE_INIT(9)Kernel Developer's ManualPMAP_PAGE_INIT(9)

-

-

-

-
pmap_page_init —
-    initialize machine-dependent fields of a VM page

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_page_init(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    function initializes the machine-dependent fields of a VM page structure.
-    This procedure is normally used when adding new pages to the VM page queue
-    management lists.

-

-

-

-
pmap(9), pmap_pinit(9)

-

-

-

-
This manual page was written by Hiten
-    Pandya
-    <hmp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 10, 2005FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_pinit.9 4.html b/static/freebsd/man9/pmap_pinit.9 4.html
deleted file mode 100644
index 174f0b8f..00000000
--- a/static/freebsd/man9/pmap_pinit.9 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_PINIT(9)Kernel Developer's ManualPMAP_PINIT(9)

-

-

-

-
pmap_pinit,
-    pmap_pinit0 — initialize
-    pmap structures

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_pinit(pmap_t
-    pmap);

-
void
-  

-  pmap_pinit0(pmap_t
-    pm);

-

-

-

-
The
-    ()
-    function initializes the preallocated and zeroed structure
-    pmap, such as one in a vmspace
-    structure.

-
The
-    ()
-    function initializes the physical map pm, associated
-    with process 0, the first process created in the system.

-

-

-

-
pmap(9),
-  pmap_growkernel(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
January 12, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_protect.9 4.html b/static/freebsd/man9/pmap_protect.9 4.html
deleted file mode 100644
index 7aeee7d9..00000000
--- a/static/freebsd/man9/pmap_protect.9 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_PROTECT(9)Kernel Developer's ManualPMAP_PROTECT(9)

-

-

-

-
pmap_protect — set
-    physical page protection

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_protect(pmap_t pmap,
-    vm_offset_t sva, vm_offset_t
-    eva, vm_prot_t prot);

-

-

-

-
The
-    ()
-    function sets the physical page permissions to prot
-    for all physical pages in the physical map pmap in the
-    virtual address range between sva and
-    eva.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 18, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_qenter.9 4.html b/static/freebsd/man9/pmap_qenter.9 4.html
deleted file mode 100644
index d104731a..00000000
--- a/static/freebsd/man9/pmap_qenter.9 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_QENTER(9)Kernel Developer's ManualPMAP_QENTER(9)

-

-

-

-
pmap_qenter,
-    pmap_qremove — manage
-    temporary kernel space mappings

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_qenter(vm_offset_t
-    sva, vm_page_t *m,
-    int count);

-
void
-  

-  pmap_qremove(vm_offset_t
-    sva, int
-  count);

-

-

-

-
The
-    ()
-    function accepts a linear array of count pointers to
-    wired pages *m, and enters each of these pages into
-    the kernel virtual address (KVA) space, beginning at the address
-    sva. The pages are mapped non-executable, if possible.
-    (For example, non-PAE i386 has no capability to map pages
-  non-executable.)

-
The
-    ()
-    function tears out a mapping from the kernel virtual address space,
-    beginning at sva and for count
-    pages.

-

-

-

-
The pmap_qenter() function is intended for
-    temporary mappings that do not require page modification or reference
-    counting. Old mappings are simply overwritten. The pages
-     be
-    wired into physical memory.

-
The corresponding pmap_qremove() function
-    is intended to remove such temporary mappings.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
February 15, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_quick_enter_page.9 4.html b/static/freebsd/man9/pmap_quick_enter_page.9 4.html
deleted file mode 100644
index 0f1b7876..00000000
--- a/static/freebsd/man9/pmap_quick_enter_page.9 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_QUICK_ENTER_PAGE(9)Kernel Developer's ManualPMAP_QUICK_ENTER_PAGE(9)

-

-

-

-
pmap_quick_enter_page,
-    pmap_quick_remove_page —
-    manage fast, single-page kernel address space
-    mappings

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
vm_offset_t
-  

-  pmap_quick_enter_page(vm_page_t
-    m);

-
void
-  

-  pmap_quick_remove_page(vm_offset_t
-    kva);

-

-

-

-
The
-    ()
-    function accepts a single page m, and enters this page
-    into a preallocated address in kernel virtual address (KVA) space. This
-    function is intended for temporary mappings that will only be used for a
-    very short period, for example a copy operation on the page contents.

-
The
-    ()
-    function removes a mapping previously created by
-    pmap_quick_enter_page() at
-    kva, making the KVA frame used by
-    pmap_quick_enter_page() available for reuse.

-
On many architectures,
-    ()
-    uses a per-CPU pageframe. In those cases, it must disable preemption on the
-    local CPU. The corresponding call to
-    pmap_quick_remove_page() then re-enables preemption.
-    It is therefore not safe for machine-independent code to sleep or perform
-    locking operations while holding these mappings. Current implementations
-    only guarantee the availability of a single page for the calling thread, so
-    calls to pmap_quick_enter_page() must not be
-  nested.

-
()
-    and pmap_quick_remove_page() do not sleep, and
-    pmap_quick_enter_page() always returns a valid
-    address. It is safe to use these functions under all types of locks except
-    spin mutexes. It is also safe to use them in all thread contexts except
-    primary interrupt context.

-
The page
-     not be swapped
-    or otherwise reused while the mapping is active. It must be either wired or
-    held, or it must belong to an unmanaged region such as I/O device
-  memory.

-

-

-

-
The pmap_quick_enter_page() function
-    returns the kernel virtual address that is mapped to the page
-    m.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Jason A
-    Harmening
-    <jah@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 6, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_release.9 4.html b/static/freebsd/man9/pmap_release.9 4.html
deleted file mode 100644
index 7f4d72b3..00000000
--- a/static/freebsd/man9/pmap_release.9 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_RELEASE(9)Kernel Developer's ManualPMAP_RELEASE(9)

-

-

-

-
pmap_release —
-    release resources held by a physical map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_release(pmap_t
-    pmap);

-

-

-

-
The
-    ()
-    function releases any resources held by the physical map
-    pmap. This function is called when a pmap initialized
-    by the corresponding function,
-    ()
-    is being released.

-

-

-

-
This function should only be called if pmap
-    no longer contains any valid mappings.

-

-

-

-
pmap(9), pmap_pinit(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_remove.9 4.html b/static/freebsd/man9/pmap_remove.9 4.html
deleted file mode 100644
index be66a28e..00000000
--- a/static/freebsd/man9/pmap_remove.9 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_REMOVE(9)Kernel Developer's ManualPMAP_REMOVE(9)

-

-

-

-
pmap_remove,
-    pmap_remove_all,
-    pmap_remove_pages — remove
-    pages from a physical map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_remove(pmap_t
-    pmap, vm_offset_t
-    sva, vm_offset_t
-    eva);

-
void
-  

-  pmap_remove_all(vm_page_t
-    m);

-
void
-  

-  pmap_remove_pages(pmap_t
-    pmap);

-

-

-

-
The
-    ()
-    function removes the range of addresses between sva
-    and eva from the physical map
-    pmap. If eva is less than
-    sva, then the result is undefined. It is assumed that
-    both sva and eva are
-    page-aligned addresses.

-
The
-    ()
-    removes the physical page m from all physical maps in
-    which it resides, and reflects back the modify bits to the appropriate
-    pager.

-
The
-    ()
-    function removes all user pages from the physical map
-    pmap. This function is called when a process exits to
-    run down its address space more quickly than would be the case for calling
-    pmap_remove().

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_resident_count.9 4.html b/static/freebsd/man9/pmap_resident_count.9 4.html
deleted file mode 100644
index bab357ac..00000000
--- a/static/freebsd/man9/pmap_resident_count.9 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_RESIDENT_COUNT(9)Kernel Developer's ManualPMAP_RESIDENT_COUNT(9)

-

-

-

-
pmap_resident_count,
-    pmap_wired_count — return
-    page resident and wiring statistics

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
long
-  

-  pmap_resident_count(pmap_t
-    pmap);

-
long
-  

-  pmap_wired_count(pmap_t
-    pmap);

-

-

-

-
The
-    ()
-    and
-    ()
-    macros allow pmap consumers to retrieve statistics
-    from the pm_stats member of the machine-dependent
-    structure struct pmap.

-

-

-

-
Both functions are defined as in-line macros. The members which
-    they access have type long.

-

-

-

-
The pmap_resident_count() returns the
-    number of pages in the physical map pmap which are
-    currently resident in main memory.

-
The pmap_wired_count() returns the number
-    of pages in the physical map pmap which are currently
-    wired into in main memory.

-

-

-

-
pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_unwire.9 4.html b/static/freebsd/man9/pmap_unwire.9 4.html
deleted file mode 100644
index 30b1fa11..00000000
--- a/static/freebsd/man9/pmap_unwire.9 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_UNWIRE(9)Kernel Developer's ManualPMAP_UNWIRE(9)

-

-

-

-
pmap_unwire —
-    unwire a range of virtual pages

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_unwire(pmap_t pmap,
-    vm_offset_t start, vm_offset_t
-    end);

-

-

-

-
The function
-    ()
-    removes the wired attribute from each of the virtual-to-physical page
-    mappings within the virtual address range from start
-    to end of the physical map pmap.
-    Every valid mapping within that range is required to have the wired
-    attribute set. Invalid mappings are ignored, since they cannot have the
-    wired attribute set.

-

-

-

-
Only the function pmap_enter(9) can be used to
-    set the wired attribute of a virtual-to-physical page mapping.

-

-

-

-
pmap(9), pmap_enter(9),
-    pmap_wired_count(9)

-

-

-

-
This manual page was written by Alan L.
-    Cox ⟨alc@rice.edu⟩.

-

-

-
-  
-    
-    
-  
-
July 17, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/pmap_zero_page.9 4.html b/static/freebsd/man9/pmap_zero_page.9 4.html
deleted file mode 100644
index 139cc54e..00000000
--- a/static/freebsd/man9/pmap_zero_page.9 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMAP_ZERO(9)Kernel Developer's ManualPMAP_ZERO(9)

-

-

-

-
pmap_zero_page,
-    pmap_zero_area — zero-fill a
-    page using machine-dependent optimizations

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  pmap_zero_page(vm_page_t
-    m);

-
void
-  

-  pmap_zero_page_area(vm_page_t
-    m, int off,
-    int size);

-

-

-

-
The
-    ()
-    function zero-fills an entire page using machine-dependent optimizations.
-    The
-    ()
-    function is used to zero-fill an area of a page. The range specified must
-    not cross a page boundary; it must be contained entirely within a single
-    page.

-

-

-

-
This function is required to be implemented for each architecture
-    supported by FreeBSD.

-

-

-

-
bzero(3), pmap(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
August 30, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/printf.9 3.html b/static/freebsd/man9/printf.9 3.html
deleted file mode 100644
index 174c8ca8..00000000
--- a/static/freebsd/man9/printf.9 3.html	
+++ /dev/null
@@ -1,162 +0,0 @@
-
-  
-    
-    
-    
-  
-
PRINTF(9)Kernel Developer's ManualPRINTF(9)

-

-

-

-
printf, uprintf,
-    tprintf, log —
-    formatted output conversion

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
int
-  

-  printf(const
-    char *fmt,
-  ...);

-
void
-  

-  tprintf(struct
-    proc *p, int pri,
-    const char *fmt,
-    ...);

-
int
-  

-  uprintf(const
-    char *fmt,
-  ...);

-
int
-  

-  vprintf(const
-    char *fmt, va_list
-    ap);

-
#include
-    <sys/syslog.h>

-
void
-  

-  log(int
-    pri, const char
-    *fmt, ...);

-
void
-  

-  vlog(int
-    pri, const char
-    *fmt, va_list
-  ap);

-

-

-

-
The printf family of functions are similar
-    to the printf(3) family of functions. The different
-    functions each use a different output stream. The
-    ()
-    function outputs to the current process' controlling tty, while
-    ()
-    writes to the console as well as to the logging facility. The
-    ()
-    function outputs to the tty associated with the process
-    p and the logging facility if
-    pri is not -1. The log()
-    function sends the message to the kernel logging facility, using the log
-    level as indicated by pri, and to the console if no
-    process is yet reading the log.

-
Each of these related functions use the fmt
-    parameter in the same manner as printf(3). However,
-    printf adds two other conversion specifiers and
-    omits one.

-
The %b identifier expects two arguments:
-    an int and a char *. These are
-    used as a register value and a print mask for decoding bitmasks. The print
-    mask is made up of two parts: the base and the arguments. The base value is
-    the output base (radix) expressed as an octal value; for example, \10 gives
-    octal and \20 gives hexadecimal. The arguments are made up of a sequence of
-    bit identifiers. Each bit identifier begins with a character specifying the
-    number of the bit (starting from 1) this identifier describes. The
-    characters from \01 to \40 can be used to specify bit numbers in the range
-    from 1 to 32 and characters from \200 to \377 to specify bit numbers in the
-    range from 1 to 128. The rest of the identifier is a string of characters
-    containing the name of the bit. The identifier is terminated by either the
-    bit number at the start of the next bit identifier or by
-    NUL for the last bit identifier.

-
The %D identifier is meant to assist in
-    hexdumps. It requires two arguments: a u_char *
-    pointer and a char * string. The memory pointed to by
-    the pointer is output in hexadecimal one byte at a time. The string is used
-    as a delimiter between individual bytes. If present, a width directive will
-    specify the number of bytes to display. By default, 16 bytes of data are
-    output.

-
The %n conversion specifier is not
-    supported.

-
The
-    () function
-    uses syslog(3) level values
-    LOG_DEBUG through LOG_EMERG
-    for its pri parameter (mistakenly called
-    ‘priority’ here). Alternatively, if a
-    pri of -1 is given, the message will be appended to
-    the last log message started by a previous call to
-    log(). As these messages are generated by the kernel
-    itself, the facility will always be LOG_KERN.

-

-

-

-
The printf() and the
-    uprintf() functions return the number of characters
-    displayed.

-

-

-

-
This example demonstrates the use of the
-    %b and %D conversion
-    specifiers. The function

-

-
void
-printf_test(void)
-{
-	printf("reg=%b\n", 3, "\10\2BITTWO\1BITONE");
-	printf("out: %4D\n", "AAZZ", ":");
-}

-

-
will produce the following output:

-

-
reg=3<BITTWO,BITONE>
-out: 41:41:5a:5a

-

-
The same output will be generated by the following function:

-

-
void
-printf_test(void)
-{
-	printf("reg=%b\n", 3, "\10\201BITTWO\200BITONE");
-	printf("out: %4D\n", "AAZZ", ":");
-}

-

-
The call

-

-
log(LOG_DEBUG, "%s%d: been there.\n", sc->sc_name, sc->sc_unit);

-

-
will add the appropriate debug message at priority
-    “kern.debug” to the system log.

-

-

-

-
printf(3), syslog(3)

-

-

-
-  
-    
-    
-  
-
December 19, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/prison_check.9 4.html b/static/freebsd/man9/prison_check.9 4.html
deleted file mode 100644
index cefd7eac..00000000
--- a/static/freebsd/man9/prison_check.9 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PRISON_CHECK(9)Kernel Developer's ManualPRISON_CHECK(9)

-

-

-

-
prison_check —
-    determine if subjects may see entities according to jail
-    restrictions

-

-

-

-
#include
-    <sys/jail.h>

-
int
-  

-  prison_check(struct
-    ucred *cred1, struct
-    ucred *cred2);

-

-

-

-
This function determines if a subject with credentials
-    cred1 is denied access to subjects or objects with
-    credentials cred2 according to the policy that a
-    subject can see subjects or objects in its own jail or any sub-jail of
-  it.

-

-

-

-
The prison_check() function returns
-    ESRCH if cred2 is not in the
-    same jail or a sub-jail of that of cred1. In all other
-    cases, prison_check() returns zero.

-

-

-

-
jail(2)

-

-

-
-  
-    
-    
-  
-
August 18, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/priv.9 3.html b/static/freebsd/man9/priv.9 3.html
deleted file mode 100644
index 175e0eb9..00000000
--- a/static/freebsd/man9/priv.9 3.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
PRIV(9)Kernel Developer's ManualPRIV(9)

-

-

-

-
priv — kernel
-    privilege checking API

-

-

-

-
#include
-    <sys/priv.h>

-
int
-  

-  priv_check(struct
-    thread *td, int
-    priv);

-
int
-  

-  priv_check_cred(struct
-    ucred *cred, int
-    priv);

-

-

-

-
The priv interfaces check to see if
-    specific system privileges are granted to the passed thread,
-    td, or credential, cred. This
-    interface replaces the now removed suser(9) privilege
-    checking interface. Privileges typically represent rights in one of two
-    categories: the right to manage a particular component of the system, or an
-    exemption to a specific policy or access control list. The caller identifies
-    the desired privilege via the priv argument.

-

-

-
Privileges are typically granted based on one of two base system
-    policies: the superuser policy, which grants privilege based on the
-    effective (or sometimes real) UID having a value of 0, and the
-    jail(2) policy, which permits only certain privileges to
-    be granted to processes in a jail. The set of available privileges may also
-    be influenced by the TrustedBSD MAC Framework, described in
-    mac(9).

-

-

-

-

-
When adding a new privilege check to a code path, first check the
-    complete list of current privileges in sys/priv.h to
-    see if one already exists for the class of privilege required. Only if there
-    is not an exact match should a new privilege be added to the privilege list.
-    As privilege numbers becomes encoded in the kernel module ABI, privilege
-    constants must not be changed as any kernel modules depending on privileges
-    will then need to be recompiled. When adding a new privilege, be certain to
-    also determine whether it should be listed in
-    prison_priv_check(), which includes a complete list
-    of privileges granted to the root user in jail(2).

-
Certain catch-all privileges exist, such as
-    PRIV_DRIVER, intended to be used by device drivers,
-    rather than adding a new driver-specific privilege.

-

-

-

-
Typically, 0 will be returned for success, and
-    EPERM will be returned on failure. Most consumers of
-    priv will wish to directly return the error code
-    from a failed privilege check to user space; a small number will wish to
-    translate it to another error code appropriate to a specific context.

-
When designing new APIs, it is preferable to return explicit
-    errors from a call if privilege is not granted rather than changing the
-    semantics of the call but returning success. For example, the behavior
-    exhibited by stat(2), in which the generation field is
-    optionally zero'd out when there is insufficient privilege is highly
-    undesirable, as it results in frequent privilege checks, and the caller is
-    unable to tell if an access control failure occurred.

-

-

-

-
jail(2), dtrace_priv(4),
-    mac(9), ucred(9)

-

-

-

-
The priv API and implementation were
-    created by Robert Watson under contract to nCircle
-    Network Security, Inc.

-

-

-
-  
-    
-    
-  
-
November 12, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/prng.9 4.html b/static/freebsd/man9/prng.9 4.html
deleted file mode 100644
index 5665dccc..00000000
--- a/static/freebsd/man9/prng.9 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
PRNG(9)Kernel Developer's ManualPRNG(9)

-

-

-

-
prng — Kernel
-    pseudo-random number generators

-

-

-

-
#include
-    <sys/prng.h>

-
uint32_t
-  

-  prng32(void);

-
uint32_t
-  

-  prng32_bounded(uint32_t
-    bound);

-
uint64_t
-  

-  prng64(void);

-
uint64_t
-  

-  prng64_bounded(uint64_t
-    bound);

-

-

-

-

-

-
prng is a family of fast,
-    
-    pseudo-random number generators. Unlike random(9),
-    (),
-    (),
-    (),
-    and
-    ()
-    avoid shared global state, removing unnecessary contention on SMP systems.
-    The routines are not explicitly tied to any specific implementation, and may
-    produce different specific sequences on different hosts, reboots, or
-    versions of FreeBSD. Different CPUs in SMP systems
-    are guaranteed to produce different sequences of integers.

-
For
-     random numbers generated by the random(4)
-    kernel cryptographically secure random number generator subsystem, see
-    arc4random(9).

-

-  
()

-  
Generate a 32-bit integer uniformly distributed in [0, 2^32-1].

-  
(bound)

-  
Generate an integer uniformly in the range [0, bound-1].

-  
()

-  
Generate a 64-bit integer uniformly distributed in [0, 2^64-1].

-  
(bound)

-  
Generate an integer uniformly in the range [0, bound-1].

-

-
These routines are not reentrant; they are not safe to use in
-    interrupt handlers ("interrupt filters" in
-    bus_setup_intr(9) terminology). They are safe to use in
-    all other kernel contexts, including interrupt threads
-    ("ithreads").

-

-

-

-
In addition to these per-CPU helpers, the
-    <sys/prng.h> header also
-    exposes the entire API of the PCG family of PRNGs as inline functions. The
-    PCG-C API is described in full at
-    https://www.pcg-random.org/using-pcg-c.html.

-

-

-

-

-
prng was introduced in
-    FreeBSD 13.

-

-

-
-  
-    
-    
-  
-
August 5, 2020FreeBSD 15.0

diff --git a/static/freebsd/man9/proc_rwmem.9 4.html b/static/freebsd/man9/proc_rwmem.9 4.html
deleted file mode 100644
index 0d391845..00000000
--- a/static/freebsd/man9/proc_rwmem.9 4.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
PROC_RWMEM(9)Kernel Developer's ManualPROC_RWMEM(9)

-

-

-

-
proc_rwmem,
-    proc_readmem, proc_writemem
-    — read from or write to a process address
-    space

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/ptrace.h>

-
int
-  

-  proc_rwmem(struct
-    proc *p, struct uio
-    *uio);

-
ssize_t
-  

-  proc_readmem(struct
-    thread *td, struct proc
-    *p, vm_offset_t va,
-    void *buf,
-    size_t len);

-
ssize_t
-  

-  proc_writemem(struct
-    thread *td, struct proc
-    *p, vm_offset_t va,
-    void *buf,
-    size_t len);

-

-

-

-
These functions are used to read to or write from the address
-    space of the process p. The
-    ()
-    function requires the caller to specify the I/O parameters using a
-    struct uio, described in uio(9). The
-    ()
-    and
-    ()
-    functions provide a simpler, less general interface which allows the caller
-    to read into or write the kernel buffer buf of size
-    len from or to the memory at offset
-    va in the address space of p.
-    The operation is performed on behalf of thread td,
-    which will most often be the current thread.

-
These functions may sleep and thus may not be called with any
-    non-sleepable locks held. The process p must be held
-    by the caller using PHOLD(9).

-

-

-

-
The proc_rwmem() function returns
-    0 on success. EFAULT is
-    returned if the specified user address is invalid, and
-    ENOMEM is returned if the target pages could not be
-    faulted in due to a resource shortage.

-
The proc_readmem() and
-    proc_writemem() functions return the number of bytes
-    read or written, respectively. This may be smaller than the number of bytes
-    requested, for example if the request spans multiple pages in the process
-    address space and one of them after the first is not mapped. Otherwise, -1
-    is returned.

-

-

-

-
copyin(9), locking(9),
-    PHOLD(9), uio(9)

-

-

-

-
This manual page was written by Mark
-    Johnston
-    <markj@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 7, 2015FreeBSD 15.0

diff --git a/static/freebsd/man9/pseudofs.9 4.html b/static/freebsd/man9/pseudofs.9 4.html
deleted file mode 100644
index 23c58be2..00000000
--- a/static/freebsd/man9/pseudofs.9 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSEUDOFS(9)Kernel Developer's ManualPSEUDOFS(9)

-

-

-

-
pseudofs — pseudo
-    file system construction kit

-

-

-

-
#include
-    <fs/pseudofs/pseudofs.h>

-

-

-

-
The pseudofs module offers an abstract API
-    for pseudo-file systems such as procfs(4) and
-    linprocfs(4). It takes care of all the hairy bits like
-    interfacing with the VFS system, enforcing access control, keeping track of
-    file numbers, and cloning files and directories that are process-specific.
-    The consumer module, i.e., the module that implements the actual guts of the
-    file system, needs only provide the directory structure (represented by a
-    collection of structures declared and initialized by macros provided by
-    pseudofs) and callbacks that report file attributes
-    or write the actual file contents into sbufs.

-

-

-

-
linprocfs(4), linsysfs(4),
-    procfs(4), sbuf(9),
-    vnode(9)

-

-

-

-
The pseudofs module appeared in
-    FreeBSD 5.0.

-

-

-

-
The pseudofs module and this manual page
-    were written by Dag-Erling Smørgrav
-    <des@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 20, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/psignal.9 3.html b/static/freebsd/man9/psignal.9 3.html
deleted file mode 100644
index 7f9f81ab..00000000
--- a/static/freebsd/man9/psignal.9 3.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSIGNAL(9)Kernel Developer's ManualPSIGNAL(9)

-

-

-

-
psignal,
-    kern_psignal, pgsignal,
-    tdsignal — post signal to a
-    thread, process, or process group

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/signalvar.h>

-
void
-  

-  kern_psignal(struct
-    proc *p, int
-    signum);

-
void
-  

-  pgsignal(struct
-    pgrp *pgrp, int
-    signum, int
-    checkctty);

-
void
-  

-  tdsignal(struct
-    thread *td, int
-    signum);

-

-

-

-
These functions post a signal to a thread or one or more
-    processes. The argument signum common to all three
-    functions should be in the range [1-NSIG].

-
The
-    ()
-    function posts signal number signum to the process
-    represented by the process structure p. The
-    kern_psignal() function used to be called
-    ()
-    but was renamed in order to eliminate a name collision with the libc
-    function of that name and facilitate code reuse. With a few exceptions noted
-    below, the target process signal disposition is updated and is marked as
-    runnable, so further handling of the signal is done in the context of the
-    target process after a context switch. Note that
-    kern_psignal() does not by itself cause a context
-    switch to happen.

-
The target process is not marked as runnable in the following
-    cases:

-
    
-  
  • The target process is sleeping uninterruptibly. The signal will be noticed
-      when the process returns from the system call or trap.
    • 
-  
  • The target process is currently ignoring the signal.
    • 
-  
  • If a stop signal is sent to a sleeping process that takes the default
-      action (see sigaction(2)), the process is stopped
-      without awakening it.
    • 
-  
  • 
-      restarts a stopped process (or puts them back to sleep) regardless of the
-      signal action (e.g., blocked or ignored).
    • 
-

-
If the target process is being traced
-    ()
-    behaves as if the target process were taking the default action for
-    signum. This allows the tracing process to be notified
-    of the signal.

-
The
-    ()
-    function posts signal number signum to each member of
-    the process group described by pgrp. If
-    checkctty is non-zero, the signal will be posted only
-    to processes that have a controlling terminal.
-    pgsignal() is implemented by walking along the
-    process list headed by the field pg_members of the
-    process group structure pointed at by pgrp and calling
-    kern_psignal() as appropriate. If
-    pgrp is NULL no action is
-    taken.

-
The
-    ()
-    function posts signal number signum to the thread
-    represented by the thread structure td.

-

-

-

-
sigaction(2), signal(9),
-    tsleep(9)

-

-

-

-
The psignal() function was renamed to
-    kern_psignal() in FreeBSD
-    9.0.

-

-

-
-  
-    
-    
-  
-
July 14, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/pwmbus.9 3.html b/static/freebsd/man9/pwmbus.9 3.html
deleted file mode 100644
index d9fcebd1..00000000
--- a/static/freebsd/man9/pwmbus.9 3.html	
+++ /dev/null
@@ -1,135 +0,0 @@
-
-  
-    
-    
-    
-  
-
PWMBUS(9)Kernel Developer's ManualPWMBUS(9)

-

-

-

-
pwmbus,
-    PWMBUS_CHANNEL_CONFIG,
-    PWMBUS_CHANNEL_COUNT,
-    PWMBUS_CHANNEL_ENABLE,
-    PWMBUS_CHANNEL_GET_CONFIG,
-    PWMBUS_CHANNEL_GET_FLAGS,
-    PWMBUS_CHANNEL_IS_ENABLED,
-    PWMBUS_CHANNEL_SET_FLAGS,
-    PWMBUS_GET_BUS — PWMBUS
-    methods

-

-

-

-
device pwm
-  

-  #include <pwmbus_if.h>

-
int
-  

-  PWMBUS_CHANNEL_CONFIG(device_t
-    bus, u_int channel,
-    u_int period,
-    u_int duty);

-
int
-  

-  PWMBUS_CHANNEL_COUNT(device_t
-    bus, u_int
-    *nchannel);

-
int
-  

-  PWMBUS_CHANNEL_ENABLE(device_t
-    bus, u_int channel,
-    bool enable);

-
int
-  

-  PWMBUS_CHANNEL_GET_CONFIG(device_t
-    bus, u_int channel,
-    u_int *period,
-    u_int *duty);

-
int
-  

-  PWMBUS_CHANNEL_GET_FLAGS(device_t
-    bus, u_int channel,
-    uint32_t *flags);

-
int
-  

-  PWMBUS_CHANNEL_IS_ENABLED(device_t
-    bus, u_int channel,
-    bool *enabled);

-
int
-  

-  PWMBUS_CHANNEL_SET_FLAGS(device_t
-    bus, u_int channel,
-    uint32_t flags);

-

-

-

-
The PWMBUS (Pulse-Width Modulation) interface allows a device
-    driver to register to a global bus so other devices in the kernel can use
-    them in a generic way.

-
For all pwmbus methods, the
-    period argument is the duration in nanoseconds of one
-    complete on-off cycle, and the duty argument is the
-    duration in nanoseconds of the on portion of that cycle.

-
Some PWM hardware is organized as a single controller with
-    multiple channels. Channel numbers count up from zero. When multiple
-    channels are present, they sometimes share a common clock or other
-    resources. In such cases, changing the period or duty cycle of any one
-    channel may affect other channels within the hardware which share the same
-    resources. Consult the documentation for the underlying PWM hardware device
-    driver for details on channels that share resources.

-

-

-

-

-  
(device_t
-    bus, u_int channel, u_int
-    period, u_int duty)

-  
Configure the period and duty (in nanoseconds) in the PWM controller on
-      the bus for the specified channel. Returns 0 on success or
-      EINVAL if the values are not supported by the
-      controller or EBUSY if the PWMBUS controller is in
-      use and does not support changing the value on the fly.

-  
(device_t
-    bus, u_int *nchannel)

-  
Get the number of channels supported by the controller.

-  
(device_t
-    bus, u_int channel, bool
-    enable)

-  
Enable the PWM channel.

-  
(device_t
-    bus, u_int channel, u_int
-    *period, u_int *duty)

-  
Get the current configuration of the period and duty for the specified
-      channel.

-  
(device_t
-    bus, u_int channel, uint32_t
-    *flags)

-  
Get the current flags for the channel. If the driver or controller does
-      not support this, a default method returns a flags value of zero.

-  
(device_t
-    bus, u_int channel, bool
-    *enable)

-  
Test whether the PWM channel is enabled.

-  
(device_t
-    bus, u_int channel, uint32_t
-    flags)

-  
Set the flags of the channel (such as inverted polarity). If the driver or
-      controller does not support this a do-nothing default method is used.

-

-

-

-

-
The pwmbus interface first appear in
-    FreeBSD 13.0. The pwmbus
-    interface and manual page was written by Emmanuel
-    Vadot
-    <manu@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 9, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/random.9 4.html b/static/freebsd/man9/random.9 4.html
deleted file mode 100644
index dea2d113..00000000
--- a/static/freebsd/man9/random.9 4.html	
+++ /dev/null
@@ -1,160 +0,0 @@
-
-  
-    
-    
-    
-  
-
RANDOM(9)Kernel Developer's ManualRANDOM(9)

-

-

-

-
arc4rand,
-    arc4random, arc4random_buf,
-    is_random_seeded, random,
-    read_random, read_random_uio
-    — supply pseudo-random numbers

-

-

-

-
#include
-    <sys/libkern.h>

-
uint32_t
-  

-  arc4random(void);

-
void
-  

-  arc4random_buf(void
-    *ptr, size_t
-  len);

-
void
-  

-  arc4rand(void
-    *ptr, u_int length,
-    int reseed);

-

-  

-  #include <sys/random.h>

-
bool
-  

-  is_random_seeded(void);

-
void
-  

-  read_random(void
-    *buffer, int
-    count);

-
int
-  

-  read_random_uio(struct
-    uio *uio, bool
-    nonblock);

-

-

-
#include
-    <sys/libkern.h>

-
u_long
-  

-  random(void);

-

-

-

-

-
The
-    ()
-    and
-    ()
-    functions will return very good quality random numbers, suited for
-    security-related purposes. Both are wrappers around the underlying
-    arc4rand() interface.
-    arc4random() returns a 32-bit random value, while
-    arc4random_buf() fills ptr
-    with len bytes of random data.

-
The
-    ()
-    CSPRNG is seeded from the random(4) kernel abstract
-    entropy device. Automatic reseeding happens at unspecified time and bytes
-    (of output) intervals. A reseed can be forced by passing a non-zero
-    reseed value.

-
The
-    ()
-    function is used to read entropy directly from the kernel abstract entropy
-    device. read_random() blocks if and until the
-    entropy device is seeded. The provided buffer is
-    filled with no more than count bytes. It is strongly
-    advised that read_random() is not used directly;
-    instead, use the arc4rand() family of functions.

-
The
-    ()
-    function can be used to check in advance if
-    read_random() will block. (If random is seeded, it
-    will not block.)

-
The
-    ()
-    function behaves identically to read(2) on
-    /dev/random. The uio argument
-    points to a buffer where random data should be stored. If
-    nonblock is true and the random device is not seeded,
-    this function does not return any data. Otherwise, this function may block
-    interruptibly until the random device is seeded. If the function is
-    interrupted before the random device is seeded, no data is returned.

-
The deprecated
-    ()
-    function will return a 31-bit value. It is obsolete and scheduled to be
-    removed in FreeBSD 16.0. Consider
-    prng(9) instead and see
-    SECURITY
-  CONSIDERATIONS.

-

-

-

-
The arc4rand() function uses the Chacha20
-    algorithm to generate a pseudo-random sequence of bytes. The
-    arc4random() function uses
-    arc4rand() to generate pseudo-random numbers in the
-    range from 0 to (2**32)−1.

-
The read_random() function returns the
-    number of bytes placed in buffer.

-
read_random_uio() returns zero when
-    successful, otherwise an error code is returned.

-
random() returns numbers in the range from
-    0 to (2**31)−1.

-

-

-

-

-
read_random_uio() may fail if:

-

-  
[]

-  
uio points to an invalid memory region.

-  
[]

-  
The random device is unseeded and nonblock is
-    true.

-

-

-

-

-
Dan Moschuk wrote
-    arc4random().
-  

-  Mark R V Murray wrote
-    read_random().

-

-

-

-
Do not use random() in new code.

-
It is important to remember that the
-    random() function is entirely predictable. It is
-    easy for attackers to predict future output of
-    random() by recording some generated values. We
-    cannot emphasize strongly enough that random() must
-    not be used to generate values that are intended to be unpredictable.

-

-

-
-  
-    
-    
-  
-
May 11, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/random_harvest.9 4.html b/static/freebsd/man9/random_harvest.9 4.html
deleted file mode 100644
index 973e5ff1..00000000
--- a/static/freebsd/man9/random_harvest.9 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
RANDOM_HARVEST(9)Kernel Developer's ManualRANDOM_HARVEST(9)

-

-

-

-
random_harvest —
-    gather entropy from the kernel for the entropy
-    device

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/random.h>

-
void
-  

-  random_harvest_direct(void
-    *entropy, u_int size, enum
-    esource source);

-
void
-  

-  random_harvest_fast(void
-    *entropy, u_int size, enum
-    esource source);

-
void
-  

-  random_harvest_queue(void
-    *entropy, u_int size, enum
-    esource source);

-

-

-

-
The
-    ()
-    functions are used by device drivers and other kernel processes to pass data
-    that is considered (at least partially) stochastic to the entropy
-  device.

-
The caller should pass a pointer pointing to the
-    “random” data in entropy. The argument
-    size contains the number of bytes pointed to. The
-    source is chosen from one of the values enumerated in
-    sys/dev/random.h. and is used to indicate the source
-    of the entropy.

-
The
-    ();
-    variant is used for early harvesting before any multitasking is enabled.

-
The
-    ()
-    variant is used by sources that should not take a performance hit from
-    harvesting, as they are high-rate sources. Some entropy is sacrificed, but
-    the high rate of supply will compensate for this.

-
The
-    ()
-    variant is used for general harvesting and is the default choice for most
-    entropy sources such as interrupts or console events.

-
Interrupt harvesting has been in part simplified for the kernel
-    programmer. If a device driver registers an interrupt handler with
-    BUS_SETUP_INTR(9) or bus_setup_intr(9),
-    then it is only necessary to include the
-    INTR_ENTROPY bit in the flags
-    argument to have that interrupt source be used for entropy harvesting. This
-    should be done wherever practicable.

-

-

-

-
random(4),
-  BUS_SETUP_INTR(9)

-

-

-

-
The FreeBSD random(4)
-    entropy device and supporting documentation was written by
-    Mark R V Murray.

-

-

-
-  
-    
-    
-  
-
August 26, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/ratecheck.9 4.html b/static/freebsd/man9/ratecheck.9 4.html
deleted file mode 100644
index 49d3b4e9..00000000
--- a/static/freebsd/man9/ratecheck.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
RATECHECK(9)Kernel Developer's ManualRATECHECK(9)

-

-

-

-
ratecheck,
-    ppsratecheck — event rate
-    limiting

-

-

-

-
#include
-    <sys/time.h>

-
int
-  

-  ratecheck(struct
-    timeval *lasttime, const
-    struct timeval *mininterval);

-
int
-  

-  ppsratecheck(struct
-    timeval *lasttime, int
-    *curpps, int
-    maxpps);

-

-

-

-
The ratecheck and
-    ppsratecheck functions facilitate rate-limiting of
-    arbitrary events. The former enforces a minimum interval between events
-    while the latter enforces a maximum number of events per second.

-
The ratecheck function compares the
-    current time to the value pointed to by lasttime. If
-    the difference is equal to or greater than
-    mininterval, it returns a non-zero value and updates
-    lasttime to the current time. Otherwise, it returns
-    zero.

-
The ppsratecheck function first compares
-    the current time to lasttime. If at least a full
-    second has passed, the value pointed to by the curpps
-    argument is reset to 1 and lasttime is updated to the
-    current time. Otherwise, curpps is incremented and
-    lasttime is left untouched. In either case,
-    ppsratecheck returns a non-zero value if and only if
-    the updated curpps is less than or equal to
-    maxpps or maxpps is
-  negative.

-

-

-

-
counter(9)

-

-

-

-
The ratecheck and
-    ppsratecheck functions first appeared in
-    FreeBSD 5.1.

-

-

-
-  
-    
-    
-  
-
March 11, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/redzone.9 4.html b/static/freebsd/man9/redzone.9 4.html
deleted file mode 100644
index d44b494c..00000000
--- a/static/freebsd/man9/redzone.9 4.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
REDZONE(9)Kernel Developer's ManualREDZONE(9)

-

-

-

-
RedZone — buffer
-    corruptions detector

-

-

-

-
options KDB
-  

-  options DDB
-  

-  options DEBUG_REDZONE

-

-

-

-
RedZone detects buffer underflow and
-    buffer overflow bugs at runtime. Currently RedZone
-    only detects buffer corruptions for memory allocated with
-    malloc(9). When such corruption is detected two backtraces
-    are printed on the console. The first one shows from where memory was
-    allocated, the second one shows from where memory was freed. By default the
-    system will not panic when buffer corruption is detected. This can be
-    changed by setting the vm.redzone.panic
-    sysctl(8) variable to 1. The amount of extra memory
-    allocated for RedZone's needs is stored in the
-    vm.redzone.extra_mem sysctl(8)
-    variable.

-

-

-

-
The example below shows the logs from the detection of a buffer
-    underflow and a buffer overflow.

-

-
REDZONE: Buffer underflow detected. 2 bytes corrupted before 0xc8688580 (16 bytes allocated).
-Allocation backtrace:
-#0 0xc0583e4e at redzone_setup+0x3c
-#1 0xc04a23fa at malloc+0x19e
-#2 0xcdeb69ca at redzone_modevent+0x60
-#3 0xc04a3f3c at module_register_init+0x82
-#4 0xc049d96a at linker_file_sysinit+0x8e
-#5 0xc049dc7c at linker_load_file+0xed
-#6 0xc04a041f at linker_load_module+0xc4
-#7 0xc049e883 at kldload+0x116
-#8 0xc05d9b3d at syscall+0x325
-#9 0xc05c944f at Xint0x80_syscall+0x1f
-Free backtrace:
-#0 0xc0583f92 at redzone_check+0xd4
-#1 0xc04a2422 at free+0x1c
-#2 0xcdeb69a6 at redzone_modevent+0x3c
-#3 0xc04a438d at module_unload+0x61
-#4 0xc049e0b3 at linker_file_unload+0x89
-#5 0xc049e979 at kern_kldunload+0x96
-#6 0xc049ea00 at kldunloadf+0x2c
-#7 0xc05d9b3d at syscall+0x325
-#8 0xc05c944f at Xint0x80_syscall+0x1f
-
-REDZONE: Buffer overflow detected. 4 bytes corrupted after 0xc8688590 (16 bytes allocated).
-Allocation backtrace:
-#0 0xc0583e4e at redzone_setup+0x3c
-#1 0xc04a23fa at malloc+0x19e
-#2 0xcdeb69ca at redzone_modevent+0x60
-#3 0xc04a3f3c at module_register_init+0x82
-#4 0xc049d96a at linker_file_sysinit+0x8e
-#5 0xc049dc7c at linker_load_file+0xed
-#6 0xc04a041f at linker_load_module+0xc4
-#7 0xc049e883 at kldload+0x116
-#8 0xc05d9b3d at syscall+0x325
-#9 0xc05c944f at Xint0x80_syscall+0x1f
-Free backtrace:
-#0 0xc0584020 at redzone_check+0x162
-#1 0xc04a2422 at free+0x1c
-#2 0xcdeb69a6 at redzone_modevent+0x3c
-#3 0xc04a438d at module_unload+0x61
-#4 0xc049e0b3 at linker_file_unload+0x89
-#5 0xc049e979 at kern_kldunload+0x96
-#6 0xc049ea00 at kldunloadf+0x2c
-#7 0xc05d9b3d at syscall+0x325
-#8 0xc05c944f at Xint0x80_syscall+0x1f

-

-

-

-

-
sysctl(8), malloc(9),
-    memguard(9)

-

-

-

-
RedZone first appeared in
-    FreeBSD 7.0.

-

-

-

-
Pawel Jakub Dawidek
-    <pjd@FreeBSD.org>

-

-

-

-
Currently, RedZone does not cooperate with
-    memguard(9). Allocations from a memory type controlled by
-    memguard(9) are simply skipped, so buffer corruptions will
-    not be detected there.

-

-

-
-  
-    
-    
-  
-
January 9, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/refcount.9 3.html b/static/freebsd/man9/refcount.9 3.html
deleted file mode 100644
index b0622f5f..00000000
--- a/static/freebsd/man9/refcount.9 3.html	
+++ /dev/null
@@ -1,156 +0,0 @@
-
-  
-    
-    
-    
-  
-
REFCOUNT(9)Kernel Developer's ManualREFCOUNT(9)

-

-

-

-
refcount,
-    refcount_init,
-    refcount_acquire,
-    refcount_release — manage a
-    simple reference counter

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/refcount.h>

-
void
-  

-  refcount_init(volatile
-    u_int *count, u_int
-    value);

-
u_int
-  

-  refcount_load(volatile
-    u_int *count);

-
u_int
-  

-  refcount_acquire(volatile
-    u_int *count);

-
bool
-  

-  refcount_acquire_checked(volatile
-    u_int *count);

-
bool
-  

-  refcount_acquire_if_not_zero(volatile
-    u_int *count);

-
bool
-  

-  refcount_release(volatile
-    u_int *count);

-
bool
-  

-  refcount_release_if_last(volatile
-    u_int *count);

-
bool
-  

-  refcount_release_if_not_last(volatile
-    u_int *count);

-

-

-

-
The refcount functions provide an API to
-    manage a simple reference counter. The caller provides the storage for the
-    counter in an unsigned integer. A pointer to this integer is passed via
-    count. Usually the counter is used to manage the
-    lifetime of an object and is stored as a member of the object.

-
Currently all functions are implemented as static inline.

-
The
-    ()
-    function is used to set the initial value of the counter to
-    value. It is normally used when creating a
-    reference-counted object.

-
The
-    ()
-    function returns a snapshot of the counter value. This value may immediately
-    become out-of-date in the absence of external synchronization.
-    refcount_load() should be used instead of relying on
-    the properties of the volatile qualifier.

-
The
-    ()
-    function is used to acquire a new reference. It returns the counter value
-    before the new reference was acquired. The caller is responsible for
-    ensuring that it holds a valid reference while obtaining a new reference.
-    For example, if an object is stored on a list and the list holds a reference
-    on the object, then holding a lock that protects the list provides
-    sufficient protection for acquiring a new reference.

-
The
-    ()
-    variant performs the same operation as
-    refcount_acquire(), but additionally checks that the
-    count value does not overflow as result of the
-    operation. It returns true if the reference was
-    successfully obtained, and false if it was not, due
-    to the overflow.

-
The
-    ()
-    function is yet another variant of
-    refcount_acquire(), which only obtains the reference
-    when some reference already exists. In other words,
-    *count must be already greater than zero for the
-    function to succeed, in which case the return value is
-    true, otherwise false is
-    returned.

-
The
-    ()
-    function is used to release an existing reference. The function returns true
-    if the reference being released was the last reference; otherwise, it
-    returns false.

-
The
-    ()
-    and
-    ()
-    functions are variants of refcount_release() which
-    only drop the reference when it is or is not the last reference,
-    respectively. In other words,
-    refcount_release_if_last() returns
-    true when *count is equal to
-    one, in which case it is decremented to zero. Otherwise,
-    *count is not modified and the function returns
-    false. Similarly,
-    refcount_release_if_not_last() returns
-    true when *count is greater
-    than one, in which case *count is decremented.
-    Otherwise, if *count is equal to one, the reference is
-    not released and the function returns false.

-
Note that these routines do not provide any inter-CPU
-    synchronization or data protection for managing the counter. The caller is
-    responsible for any additional synchronization needed by consumers of any
-    containing objects. In addition, the caller is also responsible for managing
-    the life cycle of any containing objects including explicitly releasing any
-    resources when the last reference is released.

-
The
-    ()
-    unconditionally executes a release fence (see atomic(9))
-    before releasing the reference, which synchronizes with an acquire fence
-    executed right before returning the true value. This
-    ensures that the destructor, supposedly executed by the caller after the
-    last reference was dropped, sees all updates done during the lifetime of the
-    object.

-

-

-

-
The refcount_release function returns true
-    when releasing the last reference and false when releasing any other
-    reference.

-

-

-

-
These functions were introduced in FreeBSD
-    6.0.

-

-

-
-  
-    
-    
-  
-
October 12, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/regulator.9 4.html b/static/freebsd/man9/regulator.9 4.html
deleted file mode 100644
index 7c9a410b..00000000
--- a/static/freebsd/man9/regulator.9 4.html	
+++ /dev/null
@@ -1,193 +0,0 @@
-
-  
-    
-    
-    
-  
-
REGULATOR(9)Kernel Developer's ManualREGULATOR(9)

-

-

-

-
regulator,
-    regulator_get_by_name,
-    regulator_get_by_id,
-    regulator_release,
-    regulator_get_name,
-    regulator_enable,
-    regulator_disable,
-    regulator_stop,
-    regulator_status,
-    regulator_get_voltage,
-    regulator_set_voltage,
-    regulator_check_voltage,
-    regulator_get_by_ofw_property —
-    regulator methods

-

-

-

-
device regulator
-  

-  #include
-    <dev/extres/regulator/regulator.h>

-
int
-  

-  regulator_get_by_name(device_t
-    cdev, const char
-    *name, regulator_t
-    *regulator);

-
int
-  

-  regulator_get_by_id(device_t
-    cdev, device_t
-    pdev, intptr_t id,
-    regulator_t
-  *regulator);

-
int
-  

-  regulator_release(regulator_t
-    regulator);

-
int
-  

-  regulator_get_name(regulator_t
-    regulator);

-
int
-  

-  regulator_enable(regulator_t
-    reg);

-
int
-  

-  regulator_disable(regulator_t
-    reg);

-
int
-  

-  regulator_stop(regulator_t
-    reg);

-
int
-  

-  regulator_status(regulator_t
-    reg, int
-  *status);

-
int
-  

-  regulator_get_voltage(regulator_t
-    reg, int
-  *uvolt);

-
int
-  

-  regulator_set_voltage(regulator_t
-    reg, int min_uvolt,
-    int max_uvolt);

-
int
-  

-  regulator_check_voltage(regulator_t
-    reg, int
-  uvolt);

-
int
-  

-  regulator_get_by_ofw_property(device_t
-    dev, phandle_t
-    node, char *name,
-    regulator_t *reg);

-

-

-

-
The regulator framework allow drivers to enable, disable and
-    change regulator voltage.

-

-

-

-
All functions returns 0 on success or
-    ENODEV if the regulator or one of its parent was not
-    found.

-

-

-

-

-  
(device_t
-    cdev, const char *name,
-    regulator_t *regulator)

-  
Resolve a regulator based on its name. All regulators names are unique.
-      This will also increment the refcount on the regulator.

-  
(device_t
-    cdev, device_t pdev, intptr_t
-    id, regulator_t *regulator)

-  
Resolve a regulator based on its id. All regulators ids are unique. This
-      will also increment the refcount on the regulator.

-  
(device_t
-    dev, phandle_t node, char
-    *name, regulator_t *reg)

-  
Resolve a regulator based on the fdt property named name. If node is 0
-      then the function will get the ofw node itself. This will also increment
-      the refcount on the regulator. Returns 0 on success or
-      ENOENT if the ofw property does not exists.

-  
(regulator_t
-    regulator)

-  
This disables the regulator, decrements the refcount on it and frees the
-      regulator variable passed.

-  
(regulator_t
-    regulator)

-  
Returns the name of the regulator. All regulator names are unique.

-  
(regulator_t
-    reg)

-  
Enable the regulator. If the regulator supports a voltage range, the one
-      configured in the hardware will be the output voltage. If the regulator
-      was already enabled by another driver this simply increments the enable
-      counter.

-  
(regulator_t
-    reg)

-  
Disable the regulator. If the regulator was also enabled by another driver
-      this simply decrements the enable counter. If the regulator was not
-      previously enabled we will kassert.

-  
(regulator_t
-    reg)

-  
Disable the regulator in hardware. This ensures the regulator is disabled
-      even if it was enabled by bootloader. This should not be called on
-      regulator that has previously been enabled by a driver. Returns 0 on
-      success or EBUSY if another consumer enabled
-    it.

-  
(regulator_t
-    reg, int *status)

-  
Get the hardware status of the regulator. status will contain a bit mask
-      with thoses possible value :
-    

-      
REGULATOR_STATUS_ENABLED

-      
The regulator is enabled.

-      
REGULATOR_STATUS_OVERCURRENT

-      
The hardware reports that too much current is being drawn.

-    

-  

-  
(regulator_t
-    reg, int *uvolt)

-  
Get the current voltage set for the regulator in microvolts.

-  
(regulator_t
-    reg, int min_uvolt, int
-    max_uvolt)

-  
Change the voltage for the regulator. If a range is acceptable by the
-      hardware or driver different values can be provided as min and max.
-      Returns 0 on success or ERANGE if the regulator
-      doesn't support this voltage range.

-  
(regulator_t
-    reg, int uvolt)

-  
Checks if the regulator support the given voltage. Returns 0 on success or
-      ERANGE if the regulator doesn't support this
-      voltage range.

-

-

-

-

-
The regulator framework first appear in
-    FreeBSD 12.0. The regulator
-    framework was written by Michal Meloun
-    <mmel@FreeBSD.org>.
-    The regulator manual page was written by
-    Emmanuel Vadot
-    <manu@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 14, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/resettodr.9 4.html b/static/freebsd/man9/resettodr.9 4.html
deleted file mode 100644
index 9b499684..00000000
--- a/static/freebsd/man9/resettodr.9 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
RESETTODR(9)Kernel Developer's ManualRESETTODR(9)

-

-

-

-
resettodr — set
-    battery-backed clock from system time

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  resettodr(void);

-

-

-

-
The
-    ()
-    function sets the system's battery-backed clock based on the contents of the
-    system time variable.

-

-

-

-
inittodr(9), time(9)

-

-

-

-
On many systems, resettodr() has to
-    convert from time to a time expressed in terms of
-    year, month, day, hours, minutes, and seconds. Many of the implementations
-    could share code, but do not.

-

-

-
-  
-    
-    
-  
-
November 13, 1995FreeBSD 15.0

diff --git a/static/freebsd/man9/resource_int_value.9 4.html b/static/freebsd/man9/resource_int_value.9 4.html
deleted file mode 100644
index ec56381f..00000000
--- a/static/freebsd/man9/resource_int_value.9 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
RESOURCE_INT_VALUE(9)Kernel Developer's ManualRESOURCE_INT_VALUE(9)

-

-

-

-
resource_int_value,
-    resource_long_value,
-    resource_string_value — get
-    a value from the hints mechanism

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>

-
int
-  

-  resource_int_value(const
-    char *name, int
-    unit, const char
-    *resname, int
-    *result);

-
int
-  

-  resource_long_value(const
-    char *name, int
-    unit, const char
-    *resname, long
-    *result);

-
int
-  

-  resource_string_value(const
-    char *name, int
-    unit, const char
-    *resname, const char
-    **result);

-

-

-

-
These functions fetch a value from the “hints”
-    mechanism.

-
The functions take the following arguments:

-

-  
name

-  
The name of the device to get the resource value from.

-  
unit

-  
The unit number of the device. -1 is special and is used for wildcard
-      entries.

-  
resname

-  
The resource name.

-  
result

-  
A pointer to memory in which to store the resource value.

-

-

-

-

-
If successful, the functions return 0. Otherwise, a non-zero error
-    code is returned.

-

-

-

-
The functions will fail if:

-

-  
[]

-  
The resource could not be found.

-  
[]

-  
Inappropriate resource type.

-

-

-

-

-
device(9), driver(9)

-

-

-

-
This manual page was written by Warner
-    Losh
-    <imp@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 1, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/rijndael.9 3.html b/static/freebsd/man9/rijndael.9 3.html
deleted file mode 100644
index bb3a114a..00000000
--- a/static/freebsd/man9/rijndael.9 3.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
RIJNDAEL(9)Kernel Developer's ManualRIJNDAEL(9)

-

-

-

-
rijndael_makeKey,
-    rijndael_cipherInit,
-    rijndael_blockEncrypt,
-    rijndael_padEncrypt,
-    rijndael_blockDecrypt,
-    rijndael_padDecrypt — AES
-    encryption

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include
-  <crypto/rijndael.h>

-
int
-  

-  rijndael_makeKey(keyInstance
-    *key, uint8_t direction, int
-    keyLen, char *keyMaterial);

-
int
-  

-  rijndael_cipherInit(cipherInstance
-    *cipher, uint8_t mode, char
-    *IV);

-
int
-  

-  rijndael_blockEncrypt(cipherInstance
-    *cipher, keyInstance *key,
-    uint8_t *input, int inputLen,
-    uint8_t *outBuffer);

-
int
-  

-  rijndael_padEncrypt(cipherInstance
-    *cipher, keyInstance *key,
-    uint8_t *input, int inputOctets,
-    uint8_t *outBuffer);

-
int
-  

-  rijndael_blockDecrypt(cipherInstance
-    *cipher, keyInstance *key,
-    uint8_t *input, int inputLen,
-    uint8_t *outBuffer);

-
int
-  

-  rijndael_padDecrypt(cipherInstance
-    *cipher, keyInstance *key,
-    uint8_t *input, int inputOctets,
-    uint8_t *outBuffer);

-

-

-

-
The
-    ()
-    function is used to set up the key schedule in key.
-    The direction (which may be
-    DIR_ENCRYPT or DIR_DECRYPT)
-    specifies the intended use of the key. The length of the key (in bits) is
-    given in keyLen, and must be 128, 192 or 256. The
-    actual key is supplied in the buffer pointed to by
-    keyMaterial. This material may be raw binary data, or
-    an ASCII string containing a hexadecimal rendition of the raw binary data,
-    dependent on a compile-time option in the
-    rijndael_makeKey sources,
-    BINARY_KEY_MATERIAL.

-

-

-

-
The rijndael_makeKey() function will
-    return BAD_KEY_INSTANCE if a
-    NULL key is passed,
-    BAD_KEY_DIR if direction is
-    not DIR_ENCRYPT or
-    DIR_DECRYPT, BAD_KEY_MAT if
-    the key materials are not a hexadecimal string (and binary keys are not
-    set), and TRUE otherwise.

-

-

-

-
Mark R V Murray

-

-

-
-  
-    
-    
-  
-
February 6, 2002FreeBSD 15.0

diff --git a/static/freebsd/man9/rman.9 4.html b/static/freebsd/man9/rman.9 4.html
deleted file mode 100644
index 12719e79..00000000
--- a/static/freebsd/man9/rman.9 4.html	
+++ /dev/null
@@ -1,411 +0,0 @@
-
-  
-    
-    
-    
-  
-
RMAN(9)Kernel Developer's ManualRMAN(9)

-

-

-

-
rman,
-    rman_activate_resource,
-    rman_adjust_resource,
-    rman_deactivate_resource,
-    rman_fini, rman_init,
-    rman_init_from_resource,
-    rman_is_region_manager,
-    rman_manage_region,
-    rman_first_free_region,
-    rman_last_free_region,
-    rman_release_resource,
-    rman_reserve_resource,
-    rman_make_alignment_flags,
-    rman_get_start,
-    rman_get_end,
-    rman_get_device,
-    rman_get_size,
-    rman_get_flags,
-    rman_set_mapping,
-    rman_get_mapping,
-    rman_set_virtual,
-    rman_get_virtual,
-    rman_set_bustag,
-    rman_get_bustag,
-    rman_set_bushandle,
-    rman_get_bushandle,
-    rman_set_rid, rman_get_rid,
-    rman_set_type, rman_get_type
-    — resource management functions

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/rman.h>

-
int
-  

-  rman_activate_resource(struct
-    resource *r);

-
int
-  

-  rman_adjust_resource(struct
-    resource *r, rman_res_t
-    start, rman_res_t
-    end);

-
int
-  

-  rman_deactivate_resource(struct
-    resource *r);

-
int
-  

-  rman_fini(struct
-    rman *rm);

-
int
-  

-  rman_init(struct
-    rman *rm);

-
int
-  

-  rman_init_from_resource(struct
-    rman *rm, struct resource
-    *r);

-
int
-  

-  rman_is_region_manager(struct
-    resource *r, struct rman
-    *rm);

-
int
-  

-  rman_manage_region(struct
-    rman *rm, rman_res_t
-    start, rman_res_t
-    end);

-
int
-  

-  rman_first_free_region(struct
-    rman *rm, rman_res_t
-    *start, rman_res_t
-    *end);

-
int
-  

-  rman_last_free_region(struct
-    rman *rm, rman_res_t
-    *start, rman_res_t
-    *end);

-
int
-  

-  rman_release_resource(struct
-    resource *r);

-
struct resource *
-  

-  rman_reserve_resource(struct rman
-    *rm, rman_res_t start,
-    rman_res_t end, rman_res_t
-    count, u_int flags, device_t
-    dev);

-
uint32_t
-  

-  rman_make_alignment_flags(uint32_t
-    size);

-
rman_res_t
-  

-  rman_get_start(struct
-    resource *r);

-
rman_res_t
-  

-  rman_get_end(struct
-    resource *r);

-
device_t
-  

-  rman_get_device(struct
-    resource *r);

-
rman_res_t
-  

-  rman_get_size(struct
-    resource *r);

-
u_int
-  

-  rman_get_flags(struct
-    resource *r);

-
void
-  

-  rman_set_mapping(struct
-    resource *r, struct
-    resource_map *map);

-
void
-  

-  rman_get_mapping(struct
-    resource *r, struct
-    resource_map *map);

-
void
-  

-  rman_set_virtual(struct
-    resource *r, void
-    *v);

-
void *
-  

-  rman_get_virtual(struct
-    resource *r);

-
void
-  

-  rman_set_bustag(struct
-    resource *r,
-    bus_space_tag_t t);

-
bus_space_tag_t
-  

-  rman_get_bustag(struct
-    resource *r);

-
void
-  

-  rman_set_bushandle(struct
-    resource *r,
-    bus_space_handle_t
-  h);

-
bus_space_handle_t
-  

-  rman_get_bushandle(struct
-    resource *r);

-
void
-  

-  rman_set_rid(struct
-    resource *r, int
-    rid);

-
int
-  

-  rman_get_rid(struct
-    resource *r);

-
void
-  

-  rman_set_type(struct
-    resource *r, int
-    type);

-
int
-  

-  rman_get_type(struct
-    resource *r);

-

-

-

-
The rman set of functions provides a
-    flexible resource management abstraction. It is used extensively by the bus
-    management code. It implements the abstractions of region and resource. A
-    region descriptor is used to manage a region; this could be memory or some
-    other form of bus space.

-
Each region has a set of bounds. Within these bounds, allocated
-    segments may reside. Each segment, termed a resource, has several properties
-    which are represented by a 16-bit flag register, as follows.

-

-
#define RF_ALLOCATED    0x0001 /* resource has been reserved */
-#define RF_ACTIVE       0x0002 /* resource allocation has been activated */
-#define RF_SHAREABLE    0x0004 /* resource permits contemporaneous sharing */
-#define RF_FIRSTSHARE   0x0020 /* first in sharing list */
-#define RF_PREFETCHABLE 0x0040 /* resource is prefetchable */
-#define RF_UNMAPPED     0x0100 /* don't map resource when activating */

-

-
Bits 15:10 of the flag register are used to represent the desired
-    alignment of the resource within the region.

-
The
-    ()
-    function initializes the region descriptor, pointed to by the
-    rm argument, for use with the resource management
-    functions. It is required that the fields rm_type and
-    rm_descr of struct rman be set
-    before calling rman_init(). The field
-    rm_type shall be set to
-    RMAN_ARRAY. The field rm_descr
-    shall be set to a string that describes the resource to be managed. The
-    rm_start and rm_end fields may
-    be set to limit the range of acceptable resource addresses. If these fields
-    are not set, rman_init() will initialize them to
-    allow the entire range of resource addresses. It also initializes any
-    mutexes associated with the structure. If
-    rman_init() fails to initialize the mutex, it will
-    return ENOMEM; otherwise it will
-    return 0 and rm will be initialized.

-
The
-    ()
-    function frees any structures associated with the structure pointed to by
-    the rm argument. If any of the resources within the
-    managed region have the RF_ALLOCATED flag set, it
-    will return EBUSY; otherwise, any mutexes associated
-    with the structure will be released and destroyed, and the function will
-    return 0.

-
The
-    ()
-    function establishes the concept of a region which is under
-    rman control. The rman
-    argument points to the region descriptor. The start
-    and end arguments specify the bounds of the region. If
-    successful, rman_manage_region() will return 0. If
-    the region overlaps with an existing region, it will return
-    EBUSY. If any part of the region falls outside of
-    the valid address range for rm, it will return
-    EINVAL. ENOMEM will be
-    returned when rman_manage_region() failed to
-    allocate memory for the region.

-
The
-    ()
-    function is a wrapper routine to create a resource manager backed by an
-    existing resource. It initializes rm using
-    rman_init() and then adds a region to
-    rm corresponding to the address range allocated to
-    r via
-  rman_manage_region().

-
The
-    ()
-    and
-    ()
-    functions can be used to query a resource manager for its first (or last)
-    unallocated region. If rm contains no free region,
-    these functions will return ENOENT. Otherwise,
-    *start and *end are set to the
-    bounds of the free region and zero is returned.

-
The
-    ()
-    function is where the bulk of the rman logic is
-    located. It attempts to reserve a contiguous range in the specified region
-    rm for the use of the device
-    dev. The caller can specify the
-    start and end of an acceptable
-    range, required alignment, and the code will attempt to find a free segment
-    which fits. The start argument is the lowest
-    acceptable starting value of the resource. The end
-    argument is the highest acceptable ending value of the resource. Therefore,
-    start +
-    count - 1 must be ≤
-    end for any allocation to happen. The alignment
-    requirement (if any) is specified in flags. Often the
-    RF_ALIGNMENT_LOG2 macro is used to specify alignment
-    to a power-of-2 size, or rman_make_alignment_flags()
-    can be used to compute the flags value at runtime. A
-    shared segment will be allocated if the RF_SHAREABLE
-    flag is set, otherwise an exclusive segment will be allocated. If this
-    shared segment already exists, the caller has its device added to the list
-    of consumers.

-
The
-    ()
-    function returns the flag mask corresponding to the desired alignment
-    size. This should be used when calling
-    ().

-
The
-    ()
-    function returns true if the allocated resource r was
-    allocated from rm. Otherwise, it returns false.

-
The
-    ()
-    function is used to adjust the reserved address range of an allocated
-    resource to reserve start through
-    end. It can be used to grow or shrink one or both ends
-    of the resource range. The current implementation does not support entirely
-    relocating the resource and will fail with EINVAL if
-    the new resource range does not overlap the old resource range. If either
-    end of the resource range grows and the new resource range would conflict
-    with another allocated resource, the function will fail with
-    EBUSY. The
-    rman_adjust_resource() function does not support
-    adjusting the resource range for shared resources and will fail such
-    attempts with EINVAL. Upon success, the resource
-    r will have a start address of
-    start and an end address of end
-    and the function will return zero. Note that none of the constraints of the
-    original allocation request such as alignment or boundary restrictions are
-    checked by rman_adjust_resource(). It is the
-    caller's responsibility to enforce any such requirements.

-
The
-    ()
-    function releases the reserved resource r. It may
-    attempt to merge adjacent free resources.

-
The
-    ()
-    function marks a resource as active, by setting the
-    RF_ACTIVE flag. If this is a time shared resource,
-    and the caller has not yet acquired the resource, the function returns
-    EBUSY.

-
The
-    ()
-    function marks a resource r as inactive, by clearing
-    the RF_ACTIVE flag. If other consumers are waiting
-    for this range, it will wakeup their threads.

-
The
-    (),
-    (),
-    (),
-    and
-    ()
-    functions return the bounds, size and flags of the previously reserved
-    resource r.

-
The
-    ()
-    function associates a bus_space_tag_t
-    t with the resource r. The
-    ()
-    function is used to retrieve this tag once set.

-
The
-    ()
-    function associates a bus_space_handle_t
-    h with the resource r. The
-    ()
-    function is used to retrieve this handle once set.

-
The
-    ()
-    function is used to associate a kernel virtual address with a resource
-    r. The
-    ()
-    function can be used to retrieve the KVA once set.

-
The
-    ()
-    function is used to associate a resource mapping with a resource
-    r. The mapping must cover the entire resource. Setting
-    a mapping sets the associated bus_space(9) handle and tag
-    for r as well as the kernel virtual address if the
-    mapping contains one. These individual values can be retrieved via
-    (),
-    rman_get_bustag(), and
-    rman_get_virtual().

-
The
-    ()
-    function can be used to retrieve the associated resource mapping once
-  set.

-
The
-    ()
-    function associates a resource identifier with a resource
-    r. The
-    ()
-    function retrieves this RID.

-
The
-    ()
-    function associates a resource type with a resource r.
-    The
-    ()
-    function retrieves this type.

-
The
-    ()
-    function returns a pointer to the device which reserved the resource
-    r.

-

-

-

-
bus_activate_resource(9),
-    bus_adjust_resource(9),
-    bus_alloc_resource(9),
-    bus_map_resource(9),
-    bus_release_resource(9),
-    bus_set_resource(9), bus_space(9),
-    mutex(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
March 13, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/rmlock.9 4.html b/static/freebsd/man9/rmlock.9 4.html
deleted file mode 100644
index 7120bb56..00000000
--- a/static/freebsd/man9/rmlock.9 4.html	
+++ /dev/null
@@ -1,366 +0,0 @@
-
-  
-    
-    
-    
-  
-
RMLOCK(9)Kernel Developer's ManualRMLOCK(9)

-

-

-

-
rmlock, rm_init,
-    rm_init_flags, rm_destroy,
-    rm_rlock, rm_try_rlock,
-    rm_wlock, rm_runlock,
-    rm_wunlock, rm_wowned,
-    rm_sleep, rm_assert,
-    RM_SYSINIT,
-    RM_SYSINIT_FLAGS, rms_init,
-    rms_destroy, rms_rlock,
-    rms_wlock, rms_runlock,
-    rms_wunlock — kernel
-    reader/writer lock optimized for read-mostly access patterns

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/rmlock.h>

-
void
-  

-  rm_init(struct
-    rmlock *rm, const char
-    *name);

-
void
-  

-  rm_init_flags(struct
-    rmlock *rm, const char
-    *name, int
-  opts);

-
void
-  

-  rm_destroy(struct
-    rmlock *rm);

-
void
-  

-  rm_rlock(struct
-    rmlock *rm, struct
-    rm_priotracker* tracker);

-
int
-  

-  rm_try_rlock(struct
-    rmlock *rm, struct
-    rm_priotracker* tracker);

-
void
-  

-  rm_wlock(struct
-    rmlock *rm);

-
void
-  

-  rm_runlock(struct
-    rmlock *rm, struct
-    rm_priotracker* tracker);

-
void
-  

-  rm_wunlock(struct
-    rmlock *rm);

-
int
-  

-  rm_wowned(const
-    struct rmlock *rm);

-
int
-  

-  rm_sleep(void
-    *wchan, struct rmlock
-    *rm, int priority,
-    const char *wmesg,
-    int timo);

-

-  

-  options INVARIANTS
-  

-  options INVARIANT_SUPPORT
-  

-  void
-  

-  rm_assert(struct
-    rmlock *rm, int
-    what);

-
#include
-    <sys/kernel.h>

-
RM_SYSINIT(name,
-    struct rmlock *rm,
-    const char *desc);

-
RM_SYSINIT_FLAGS(name,
-    struct rmlock *rm,
-    const char *desc,
-    int flags);

-
void
-  

-  rms_init(struct
-    rmslock *rms, const char
-    *name);

-
void
-  

-  rms_destroy(struct
-    rmslock *rms);

-
void
-  

-  rms_rlock(struct
-    rmslock *rms);

-
void
-  

-  rms_wlock(struct
-    rmslock *rms);

-
void
-  

-  rms_runlock(struct
-    rmslock *rms);

-
void
-  

-  rms_wunlock(struct
-    rmslock *rms);

-

-

-

-
Read-mostly locks allow shared access to protected data by
-    multiple threads, or exclusive access by a single thread. The threads with
-    shared access are known as
-    
-    since they only read the protected data. A thread with exclusive access is
-    known as a
-    
-    since it can modify protected data.

-
Read-mostly locks are designed to be efficient for locks almost
-    exclusively used as reader locks and as such should be used for protecting
-    data that rarely changes. Acquiring an exclusive lock after the lock has
-    been locked for shared access is an expensive operation.

-
Normal read-mostly locks are similar to
-    rwlock(9) locks and follow the same lock ordering rules as
-    rwlock(9) locks. Read-mostly locks have full priority
-    propagation like mutexes. Unlike rwlock(9), read-mostly
-    locks propagate priority to both readers and writers. This is implemented
-    via the rm_priotracker structure argument supplied to
-    ()
-    and
-    ().
-    Readers can recurse if the lock is initialized with the
-    RM_RECURSE option; however, writers are never
-    allowed to recurse.

-
Sleeping for writers can be allowed by passing
-    RM_SLEEPABLE to
-    ().
-    It changes lock ordering rules to the same as for sx(9)
-    locks. They do not propagate priority to writers, but they do propagate
-    priority to readers. Note that readers are not permitted to sleep regardless
-    of the flag.

-
Sleepable read-mostly locks (created with
-    ())
-    allow sleeping for both readers and writers, but don't do priority
-    propagation for either. They follow sx(9) lock
-  ordering.

-

-

-

-  
(struct
-    rmlock *rm, const char *name)

-  
Initialize the read-mostly lock rm. The
-      name description is used solely for debugging
-      purposes. This function must be called before any other operations on the
-      lock.

-  
rm_init_flags(struct rmlock
-    *rm, const char *name, int
-    opts)

-  
Similar to rm_init(), initialize the read-mostly
-      lock rm with a set of optional flags. The
-      opts arguments contains one or more of the following
-      flags:
-    

-      

-      
Instruct witness(4) to ignore this lock.

-      

-      
Allow threads to recursively acquire shared locks for
-          rm.

-      

-      
Create a sleepable read-mostly lock.

-      

-      
If the kernel has been compiled with option
-          INVARIANTS, rm_init_flags() will assert
-          that the rm has not been initialized multiple
-          times without intervening calls to
-          ()
-          unless this option is specified.

-      

-      
witness(4) should not log messages about duplicate
-          locks being acquired.

-    

-  

-  
rm_rlock(struct rmlock *rm,
-    struct rm_priotracker* tracker)

-  
Lock rm as a reader using
-      tracker to track read owners of a lock for priority
-      propagation. This data structure is only used internally by
-      rmlock and must persist until
-      rm_runlock() has been called. This data structure
-      can be allocated on the stack since readers cannot sleep. If any thread
-      holds this lock exclusively, the current thread blocks, and its priority
-      is propagated to the exclusive holder. If the lock was initialized with
-      the RM_RECURSE option the
-      rm_rlock() function can be called when the current
-      thread has already acquired reader access on
-    rm.

-  
(struct
-    rmlock *rm, struct rm_priotracker* tracker)

-  
Try to lock rm as a reader.
-      rm_try_rlock() will return 0 if the lock cannot be
-      acquired immediately; otherwise, the lock will be acquired and a non-zero
-      value will be returned. Note that rm_try_rlock()
-      may fail even while the lock is not currently held by a writer. If the
-      lock was initialized with the RM_RECURSE option,
-      rm_try_rlock() will succeed if the current thread
-      has already acquired reader access.

-  
(struct
-    rmlock *rm)

-  
Lock rm as a writer. If there are any shared owners
-      of the lock, the current thread blocks. The
-      rm_wlock() function cannot be called
-    recursively.

-  
rm_runlock(struct rmlock
-    *rm, struct rm_priotracker* tracker)

-  
This function releases a shared lock previously acquired by
-      rm_rlock(). The tracker
-      argument must match the tracker argument used for
-      acquiring the shared lock

-  
(struct
-    rmlock *rm)

-  
This function releases an exclusive lock previously acquired by
-      rm_wlock().

-  
rm_destroy(struct rmlock
-    *rm)

-  
This functions destroys a lock previously initialized with
-      rm_init(). The rm lock must
-      be unlocked.

-  
(const
-    struct rmlock *rm)

-  
This function returns a non-zero value if the current thread owns an
-      exclusive lock on rm.

-  
(void
-    *wchan, struct rmlock *rm, int
-    priority, const char *wmesg, int
-    timo)

-  
This function atomically releases rm while waiting
-      for an event. The rm lock must be exclusively
-      locked. For more details on the parameters to this function, see
-      sleep(9).

-  
(struct
-    rmlock *rm, int what)

-  
This function asserts that the rm lock is in the
-      state specified by what. If the assertions are not
-      true and the kernel is compiled with options
-      INVARIANTS and options INVARIANT_SUPPORT,
-      the kernel will panic. Currently the following base assertions are
-      supported:
-    

-      

-      
Assert that current thread holds either a shared or exclusive lock of
-          rm.

-      

-      
Assert that current thread holds a shared lock of
-          rm.

-      

-      
Assert that current thread holds an exclusive lock of
-          rm.

-      

-      
Assert that current thread holds neither a shared nor exclusive lock
-          of rm.

-    

-    
In addition, one of the following optional flags may be
-        specified with RA_LOCKED,
-        RA_RLOCKED, or
-        RA_WLOCKED:

-    

-      

-      
Assert that the current thread holds a recursive lock of
-          rm.

-      

-      
Assert that the current thread does not hold a recursive lock of
-          rm.

-    

-  

-

-

-  
(struct
-    rmslock *rms, const char *name)

-  
Initialize the sleepable read-mostly lock rms. The
-      name description is used as
-      wmesg parameter to the msleep(9)
-      routine. This function must be called before any other operations on the
-      lock.

-  
(struct
-    rmlock *rm)

-  
Lock rms as a reader. If any thread holds this lock
-      exclusively, the current thread blocks.

-  
(struct
-    rmslock *rms)

-  
Lock rms as a writer. If the lock is already taken,
-      the current thread blocks. The rms_wlock()
-      function cannot be called recursively.

-  
(struct
-    rmslock *rms)

-  
This function releases a shared lock previously acquired by
-      rms_rlock().

-  
(struct
-    rmslock *rms)

-  
This function releases an exclusive lock previously acquired by
-      rms_wlock().

-  
(struct
-    rmslock *rms)

-  
This functions destroys a lock previously initialized with
-      rms_init(). The rms lock
-      must be unlocked.

-

-

-

-

-

-
locking(9), mutex(9),
-    panic(9), rwlock(9),
-    sema(9), sleep(9),
-    sx(9)

-

-

-

-
These functions appeared in FreeBSD
-  7.0.

-

-

-

-
The rmlock facility was written by
-    Stephan Uphoff. This manual page was written by
-    Gleb Smirnoff for rwlock and modified to reflect
-    rmlock by Stephan Uphoff.

-

-

-

-
The rmlock implementation is currently not
-    optimized for single processor systems.

-
rm_try_rlock() can fail transiently even
-    when there is no writer, while another reader updates the state on the local
-    CPU.

-
The rmlock implementation uses a single
-    per CPU list shared by all rmlocks in the system. If rmlocks become popular,
-    hashing to multiple per CPU queues may be needed to speed up the writer lock
-    process.

-

-

-
-  
-    
-    
-  
-
April 12, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/rtentry.9 3.html b/static/freebsd/man9/rtentry.9 3.html
deleted file mode 100644
index 587f2f69..00000000
--- a/static/freebsd/man9/rtentry.9 3.html	
+++ /dev/null
@@ -1,206 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTENTRY(9)Kernel Developer's ManualRTENTRY(9)

-

-

-

-
rtentry —
-    structure of an entry in the kernel routing
-  table

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <net/route.h>

-

-

-

-
The kernel provides a common mechanism by which all protocols can
-    store and retrieve entries from a central table of routes. Parts of this
-    mechanism are also used to interact with user-level processes by means of a
-    socket in the route(4) pseudo-protocol family. The
-    <net/route.h> header file
-    defines the structures and manifest constants used in this facility.

-
The basic structure of a route is defined by
-    struct rtentry, which includes the following
-  fields:

-

-

-  
struct radix_node rt_nodes[2];

-  
Glue used by the radix-tree routines. These members also include in their
-      substructure the key (i.e., destination address) and mask used when the
-      route was created. The
-      (rt)
-      and
-      (rt)
-      macros can be used to extract this information (in the form of a
-      struct sockaddr *) given a struct
-      rtentry *.

-  
struct sockaddr *rt_gateway;

-  
The “target” of the route, which can either represent a
-      destination in its own right (some protocols will put a link-layer address
-      here), or some intermediate stop on the way to that destination (if the
-      RTF_GATEWAY flag is set).

-  
int rt_flags;

-  
See below. If the RTF_UP flag is not present, the
-      ()
-      function will delete the route from the radix tree when the last reference
-      drops.

-  
int rt_refcnt;

-  
Route entries are reference-counted; this field indicates the number of
-      external (to the radix tree) references.

-  
struct ifnet *rt_ifp;

-  
 

-  
struct ifaddr *rt_ifa;

-  
These two fields represent the “answer”, as it were, to the
-      question posed by a route lookup; that is, they name the interface and
-      interface address to be used in sending a packet to the destination or set
-      of destinations which this route represents.

-  
u_long rt_mtu;

-  
See description of rmx_mtu below.

-  
u_long rt_weight;

-  
See description of rmx_weight below.

-  
u_long rt_expire;

-  
See description of rmx_expire below.

-  
counter64_t rt_pksent;

-  
See description of rmx_pksent below.

-  
struct rtentry *rt_gwroute;

-  
This member is a reference to a route whose destination is
-      rt_gateway. It is only used for
-      RTF_GATEWAY routes.

-  
struct mtx rt_mtx;

-  
Mutex to lock this routing entry.

-

-

-
The following flag bits are defined:

-

-

-  

-  
The route is not deleted.

-  

-  
The route points to an intermediate destination and not the ultimate
-      recipient; the rt_gateway and
-      rt_gwroute fields name that destination.

-  

-  
This is a host route.

-  

-  
The destination is presently unreachable. This should result in an
-      EHOSTUNREACH error from output routines.

-  

-  
This route was created dynamically by
-      ().

-  

-  
This route was modified by rtredirect().

-  

-  
Used only in the route(4) protocol, indicating that the
-      request was executed.

-  

-  
When this route is returned as a result of a lookup, send a report on the
-      route(4) interface requesting that an external process
-      perform resolution for this route.

-  

-  
Indicates that this route was manually added by means of the
-      route(8) command.

-  

-  
Requests that output sent via this route be discarded.

-  

-  
 

-  

-  
 

-  

-  
Protocol-specific.

-  

-  
Indicates that this route is immutable to a routing protocol.

-  

-  
Indicates that the destination of this route is an address configured as
-      belonging to this system.

-  

-  
Indicates that the destination is a broadcast address.

-  

-  
Indicates that the destination is a multicast address.

-

-

-
Several metrics are supplied in struct
-    rt_metrics passed with routing control messages via
-    route(4) API. Currently only
-    rmx_mtu, rmx_expire, and
-    rmx_pksent metrics are supplied. All others are
-    ignored.

-
The following metrics are defined by struct
-    rt_metrics:

-

-

-  
u_long rmx_locks;

-  
Flag bits indicating which metrics the kernel is not permitted to
-      dynamically modify.

-  
u_long rmx_mtu;

-  
MTU for this path.

-  
u_long rmx_hopcount;

-  
Number of intermediate systems on the path to this destination.

-  
u_long rmx_expire;

-  
The time (a la time(3)) at which this route should
-      expire, or zero if it should never expire. It is the responsibility of
-      individual protocol suites to ensure that routes are actually deleted once
-      they expire.

-  
u_long rmx_recvpipe;

-  
Nominally, the bandwidth-delay product for the path
-       the
-      destination
-       this
-      system. In practice, this value is used to set the size of the receive
-      buffer (and thus the window in sliding-window protocols like TCP).

-  
u_long rmx_sendpipe;

-  
As before, but in the opposite direction.

-  
u_long rmx_ssthresh;

-  
The slow-start threshold used in TCP congestion-avoidance.

-  
u_long rmx_rtt;

-  
The round-trip time to this destination, in units of
-      RMX_RTTUNIT per second.

-  
u_long rmx_rttvar;

-  
The average deviation of the round-trip time to this destination, in units
-      of RMX_RTTUNIT per second.

-  
u_long rmx_pksent;

-  
A count of packets successfully sent via this route.

-  
u_long rmx_filler[4];

-  
Empty space available for protocol-specific information.

-

-

-

-

-

-
route(4), route(8)

-

-

-

-
The rtentry structure first appeared in
-    4.2BSD. The radix-tree representation of the routing
-    table and the rt_metrics structure first appeared in
-    4.3BSD-Reno.

-

-

-

-
This manual page was written by Garrett
-    Wollman.

-

-

-

-
There are a number of historical relics remaining in this
-    interface. The rt_gateway and
-    rmx_filler fields could be named better.

-

-

-
-  
-    
-    
-  
-
March 5, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/runqueue.9 3.html b/static/freebsd/man9/runqueue.9 3.html
deleted file mode 100644
index 0807f214..00000000
--- a/static/freebsd/man9/runqueue.9 3.html	
+++ /dev/null
@@ -1,107 +0,0 @@
-
-  
-    
-    
-    
-  
-
RUNQUEUE(9)Kernel Developer's ManualRUNQUEUE(9)

-

-

-

-
choosethread,
-    procrunnable, remrunqueue,
-    setrunqueue — manage the
-    queue of runnable processes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
extern struct rq itqueues[];
-  

-  extern struct rq rtqueues[];
-  

-  extern struct rq queues[];
-  

-  extern struct rq idqueues[];

-
struct thread *
-  

-  choosethread(void);

-
int
-  

-  procrunnable(void);

-
void
-  

-  remrunqueue(struct
-    thread *td);

-
void
-  

-  setrunqueue(struct
-    thread *td);

-

-

-

-
The run queue consists of four priority queues:
-    itqueues for interrupt threads,
-    rtqueues for realtime priority processes,
-    queues for time sharing processes, and
-    idqueues for idle priority processes. Each priority
-    queue consists of an array of NQS queue header
-    structures. Each queue header identifies a list of runnable processes of
-    equal priority. Each queue also has a single word that contains a bit mask
-    identifying non-empty queues to assist in selecting a process quickly. These
-    are named itqueuebits,
-    rtqueuebits, queuebits, and
-    idqueuebits. The run queues are protected by the
-    sched_lock mutex.

-
()
-    returns zero if there are no runnable processes other than the idle process.
-    If there is at least one runnable process other than the idle process, it
-    will return a non-zero value. Note that the sched_lock
-    mutex does
-     need to
-    be held when this function is called. There is a small race window where one
-    CPU may place a process on the run queue when there are currently no other
-    runnable processes while another CPU is calling this function. In that case
-    the second CPU will simply travel through the idle loop one additional time
-    before noticing that there is a runnable process. This works because idle
-    CPUs are not halted in SMP systems. If idle CPUs are halted in SMP systems,
-    then this race condition might have more serious repercussions in the losing
-    case, and procrunnable() may have to require that
-    the sched_lock mutex be acquired.

-
()
-    returns the highest priority runnable thread. If there are no runnable
-    threads, then the idle thread is returned. This function is called by
-    ()
-    and
-    ()
-    to determine which thread to switch to.
-    choosethread() must be called with the
-    sched_lock mutex held.

-
()
-    adds the thread td to the tail of the appropriate
-    queue in the proper priority queue. The thread must be runnable, i.e.
-    p_stat must be set to SRUN.
-    This function must be called with the sched_lock mutex
-    held.

-
()
-    removes thread td from its run queue. If
-    td is not on a run queue, then the kernel will
-    panic(9). This function must be called with the
-    sched_lock mutex held.

-

-

-

-
cpu_switch(9), scheduler(9),
-    sleepqueue(9)

-

-

-
-  
-    
-    
-  
-
August 15, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/rwlock.9 4.html b/static/freebsd/man9/rwlock.9 4.html
deleted file mode 100644
index 15ec3908..00000000
--- a/static/freebsd/man9/rwlock.9 4.html	
+++ /dev/null
@@ -1,324 +0,0 @@
-
-  
-    
-    
-    
-  
-
RWLOCK(9)Kernel Developer's ManualRWLOCK(9)

-

-

-

-
rwlock, rw_init,
-    rw_init_flags, rw_destroy,
-    rw_rlock, rw_wlock,
-    rw_runlock, rw_wunlock,
-    rw_unlock, rw_try_rlock,
-    rw_try_upgrade,
-    rw_try_wlock, rw_downgrade,
-    rw_sleep, rw_initialized,
-    rw_wowned, rw_assert,
-    RW_SYSINIT, RW_SYSINIT_FLAGS
-    — kernel reader/writer lock

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/rwlock.h>

-
void
-  

-  rw_init(struct
-    rwlock *rw, const char
-    *name);

-
void
-  

-  rw_init_flags(struct
-    rwlock *rw, const char
-    *name, int
-  opts);

-
void
-  

-  rw_destroy(struct
-    rwlock *rw);

-
void
-  

-  rw_rlock(struct
-    rwlock *rw);

-
void
-  

-  rw_wlock(struct
-    rwlock *rw);

-
int
-  

-  rw_try_rlock(struct
-    rwlock *rw);

-
int
-  

-  rw_try_wlock(struct
-    rwlock *rw);

-
void
-  

-  rw_runlock(struct
-    rwlock *rw);

-
void
-  

-  rw_wunlock(struct
-    rwlock *rw);

-
void
-  

-  rw_unlock(struct
-    rwlock *rw);

-
int
-  

-  rw_try_upgrade(struct
-    rwlock *rw);

-
void
-  

-  rw_downgrade(struct
-    rwlock *rw);

-
int
-  

-  rw_sleep(void
-    *chan, struct rwlock
-    *rw, int priority,
-    const char *wmesg,
-    int timo);

-
int
-  

-  rw_initialized(const
-    struct rwlock *rw);

-
int
-  

-  rw_wowned(const
-    struct rwlock *rw);

-

-  

-  options INVARIANTS
-  

-  options INVARIANT_SUPPORT
-  

-  void
-  

-  rw_assert(const
-    struct rwlock *rw, int
-    what);

-
#include
-    <sys/kernel.h>

-
RW_SYSINIT(name,
-    struct rwlock *rw,
-    const char *desc);

-
RW_SYSINIT_FLAGS(name,
-    struct rwlock *rw,
-    const char *desc,
-    int flags);

-

-

-

-
Reader/writer locks allow shared access to protected data by
-    multiple threads, or exclusive access by a single thread. The threads with
-    shared access are known as
-    
-    since they only read the protected data. A thread with exclusive access is
-    known as a
-    
-    since it can modify protected data.

-
Although reader/writer locks look very similar to
-    sx(9) locks, their usage pattern is different.
-    Reader/writer locks can be treated as mutexes (see
-    mutex(9)) with shared/exclusive semantics. Unlike
-    sx(9), an rwlock can be locked
-    while holding a non-spin mutex, and an rwlock cannot
-    be held while sleeping. The rwlock locks have
-    priority propagation like mutexes, but priority can be propagated only to
-    writers. This limitation comes from the fact that readers are anonymous.
-    Another important property is that readers can always recurse, and exclusive
-    locks can be made recursive selectively.

-

-

-

-  
(struct
-    rwlock *rw, const char *name)

-  
Initialize structure located at rw as reader/writer
-      lock, described by name name. The description is
-      used solely for debugging purposes. This function must be called before
-      any other operations on the lock.

-  
(struct
-    rwlock *rw, const char *name,
-    int opts)

-  
Initialize the rw lock just like the rw_init()
-      function, but specifying a set of optional flags to alter the behaviour of
-      rw, through the opts argument.
-      It contains one or more of the following flags:
-    

-      

-      
Witness should not log messages about duplicate locks being
-        acquired.

-      

-      
Do not profile this lock.

-      

-      
Instruct witness(4) to ignore this lock.

-      

-      
Do not log any operations for this lock via
-        ktr(4).

-      

-      
Allow threads to recursively acquire exclusive locks for
-          rw.

-      

-      
If the kernel has been compiled with option
-          INVARIANTS, rw_init_flags() will assert
-          that the rw has not been initialized multiple
-          times without intervening calls to
-          ()
-          unless this option is specified.

-    

-  

-  
(struct
-    rwlock *rw)

-  
Lock rw as a reader. If any thread holds this lock
-      exclusively, the current thread blocks, and its priority is propagated to
-      the exclusive holder. The rw_rlock() function can
-      be called when the thread has already acquired reader access on
-      rw. This is called “recursing on a
-      lock”.

-  
(struct
-    rwlock *rw)

-  
Lock rw as a writer. If there are any shared owners
-      of the lock, the current thread blocks. The
-      rw_wlock() function can be called recursively only
-      if rw has been initialized with the
-      RW_RECURSE option enabled.

-  
(struct
-    rwlock *rw)

-  
Try to lock rw as a reader. This function will
-      return true if the operation succeeds, otherwise 0 will be returned.

-  
(struct
-    rwlock *rw)

-  
Try to lock rw as a writer. This function will
-      return true if the operation succeeds, otherwise 0 will be returned.

-  
(struct
-    rwlock *rw)

-  
This function releases a shared lock previously acquired by
-      rw_rlock().

-  
(struct
-    rwlock *rw)

-  
This function releases an exclusive lock previously acquired by
-      rw_wlock().

-  
(struct
-    rwlock *rw)

-  
This function releases a shared lock previously acquired by
-      rw_rlock() or an exclusive lock previously
-      acquired by rw_wlock().

-  
(struct
-    rwlock *rw)

-  
Attempt to upgrade a single shared lock to an exclusive lock. The current
-      thread must hold a shared lock of rw. This will only
-      succeed if the current thread holds the only shared lock on
-      rw, and it only holds a single shared lock. If the
-      attempt succeeds rw_try_upgrade() will return a
-      non-zero value, and the current thread will hold an exclusive lock. If the
-      attempt fails rw_try_upgrade() will return zero,
-      and the current thread will still hold a shared lock.

-  
(struct
-    rwlock *rw)

-  
Convert an exclusive lock into a single shared lock. The current thread
-      must hold an exclusive lock of rw.

-  
(void
-    *chan, struct rwlock *rw, int
-    priority, const char *wmesg, int
-    timo)

-  
Atomically release rw while waiting for an event.
-      For more details on the parameters to this function, see
-      sleep(9).

-  
(const
-    struct rwlock *rw)

-  
This function returns non-zero if rw has been
-      initialized, and zero otherwise.

-  
rw_destroy(struct rwlock
-    *rw)

-  
This functions destroys a lock previously initialized with
-      rw_init(). The rw lock must
-      be unlocked.

-  
(const
-    struct rwlock *rw)

-  
This function returns a non-zero value if the current thread owns an
-      exclusive lock on rw.

-  
(const
-    struct rwlock *rw, int what)

-  
This function allows assertions specified in what to
-      be made about rw. If the assertions are not true and
-      the kernel is compiled with options INVARIANTS and
-      options INVARIANT_SUPPORT, the kernel will panic.
-      Currently the following base assertions are supported:
-    

-      

-      
Assert that current thread holds either a shared or exclusive lock of
-          rw.

-      

-      
Assert that current thread holds a shared lock of
-          rw.

-      

-      
Assert that current thread holds an exclusive lock of
-          rw.

-      

-      
Assert that current thread holds neither a shared nor exclusive lock
-          of rw.

-    

-    
In addition, one of the following optional flags may be
-        specified with RA_LOCKED,
-        RA_RLOCKED, or
-        RA_WLOCKED:

-    

-      

-      
Assert that the current thread holds a recursive lock of
-          rw.

-      

-      
Assert that the current thread does not hold a recursive lock of
-          rw.

-    

-  

-

-

-

-

-

-
locking(9), mutex(9),
-    panic(9), sema(9),
-    sx(9)

-

-

-

-
These functions appeared in FreeBSD
-  7.0.

-

-

-

-
The rwlock facility was written by
-    John Baldwin. This manual page was written by
-    Gleb Smirnoff.

-

-

-

-
A kernel without WITNESS cannot assert
-    whether the current thread does or does not hold a read lock.
-    RA_LOCKED and RA_RLOCKED can
-    only assert that
-     thread
-    holds a read lock. They cannot ensure that the current thread holds a read
-    lock. Further, RA_UNLOCKED can only assert that the
-    current thread does not hold a write lock.

-
Reader/writer is a bit of an awkward name. An
-    rwlock can also be called a “Robert
-    Watson” lock if desired.

-

-

-
-  
-    
-    
-  
-
November 11, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/sbuf.9 4.html b/static/freebsd/man9/sbuf.9 4.html
deleted file mode 100644
index 320c464f..00000000
--- a/static/freebsd/man9/sbuf.9 4.html	
+++ /dev/null
@@ -1,525 +0,0 @@
-
-  
-    
-    
-    
-  
-
SBUF(9)Kernel Developer's ManualSBUF(9)

-

-

-

-
sbuf, sbuf_new,
-    sbuf_new_auto,
-    sbuf_new_for_sysctl,
-    sbuf_clear, sbuf_get_flags,
-    sbuf_set_flags,
-    sbuf_clear_flags,
-    sbuf_setpos, sbuf_bcat,
-    sbuf_bcopyin, sbuf_bcpy,
-    sbuf_cat, sbuf_copyin,
-    sbuf_cpy, sbuf_nl_terminate,
-    sbuf_printf, sbuf_vprintf,
-    sbuf_putc, sbuf_set_drain,
-    sbuf_trim, sbuf_error,
-    sbuf_finish, sbuf_data,
-    sbuf_len, sbuf_done,
-    sbuf_delete,
-    sbuf_start_section,
-    sbuf_end_section,
-    sbuf_hexdump,
-    sbuf_printf_drain,
-    sbuf_putbuf — safe string
-    composition

-

-

-

-
Safe String Composition Library (libsbuf,
-    -lsbuf)

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/sbuf.h>

-
typedef int
-  

-  (sbuf_drain_func)(void *arg,
-    const char *data, int len);

-

-  

-  struct sbuf *
-  

-  sbuf_new(struct sbuf *s,
-    char *buf, int length,
-    int flags);

-
struct sbuf *
-  

-  sbuf_new_auto(void);

-
void
-  

-  sbuf_clear(struct sbuf *s);

-
int
-  

-  sbuf_get_flags(struct sbuf
-  *s);

-
void
-  

-  sbuf_set_flags(struct sbuf *s,
-    int flags);

-
void
-  

-  sbuf_clear_flags(struct sbuf *s,
-    int flags);

-
int
-  

-  sbuf_setpos(struct sbuf *s,
-    int pos);

-
int
-  

-  sbuf_bcat(struct sbuf *s,
-    const void *buf, size_t
-  len);

-
int
-  

-  sbuf_bcpy(struct sbuf *s,
-    const void *buf, size_t
-  len);

-
int
-  

-  sbuf_cat(struct sbuf *s,
-    const char *str);

-
int
-  

-  sbuf_cpy(struct sbuf *s,
-    const char *str);

-
int
-  

-  sbuf_nl_terminate(struct
-    sbuf *);

-
int
-  

-  sbuf_printf(struct sbuf *s,
-    const char *fmt, ...);

-
int
-  

-  sbuf_vprintf(struct sbuf *s,
-    const char *fmt, va_list
-  ap);

-
int
-  

-  sbuf_putc(struct sbuf *s,
-    int c);

-
void
-  

-  sbuf_set_drain(struct sbuf *s,
-    sbuf_drain_func *func, void
-    *arg);

-
int
-  

-  sbuf_trim(struct sbuf *s);

-
int
-  

-  sbuf_error(struct sbuf *s);

-
int
-  

-  sbuf_finish(struct sbuf *s);

-
char *
-  

-  sbuf_data(struct sbuf *s);

-
ssize_t
-  

-  sbuf_len(struct sbuf *s);

-
int
-  

-  sbuf_done(struct sbuf *s);

-
void
-  

-  sbuf_delete(struct sbuf *s);

-
void
-  

-  sbuf_start_section(struct sbuf
-    *s, ssize_t *old_lenp);

-
ssize_t
-  

-  sbuf_end_section(struct sbuf *s,
-    ssize_t old_len, size_t pad,
-    int c);

-
void
-  

-  sbuf_hexdump(struct sbuf *sb,
-    void *ptr, int length,
-    const char *hdr, int flags);

-
int
-  

-  sbuf_printf_drain(void *arg,
-    const char *data, int len);

-
void
-  

-  sbuf_putbuf(struct sbuf *s);

-
#ifdef _KERNEL

-
#include
-    <sys/types.h>
-  

-  #include <sys/sbuf.h>

-
int
-  

-  sbuf_bcopyin(struct sbuf *s,
-    const void *uaddr, size_t
-  len);

-
int
-  

-  sbuf_copyin(struct sbuf *s,
-    const void *uaddr, size_t
-  len);

-
#include
-    <sys/sysctl.h>

-
struct sbuf *
-  

-  sbuf_new_for_sysctl(struct sbuf
-    *s, char *buf, int length,
-    struct sysctl_req *req);

-
#endif	/* _KERNEL */

-

-

-

-
The sbuf family of functions allows one to
-    safely allocate, compose and release strings in kernel or user space.

-
Instead of arrays of characters, these functions operate on
-    structures called sbufs, defined in
-    <sys/sbuf.h>.

-
Any errors encountered during the allocation or composition of the
-    string will be latched in the data structure, making a single error test at
-    the end of the composition sufficient to determine success or failure of the
-    entire process.

-
The
-    ()
-    function initializes the sbuf pointed to by its first
-    argument. If that pointer is NULL,
-    sbuf_new() allocates a struct
-    sbuf using malloc(9). The buf
-    argument is a pointer to a buffer in which to store the actual string; if it
-    is NULL, sbuf_new() will
-    allocate one using malloc(9). The
-    length is the initial size of the storage buffer. The
-    fourth argument, flags, may be comprised of the
-    following flags:

-

-  

-  
The storage buffer is fixed at its initial size. Attempting to extend the
-      sbuf beyond this size results in an overflow condition.

-  

-  
This indicates that the storage buffer may be extended as necessary, so
-      long as resources allow, to hold additional data.

-  

-  
This causes the final nulterm byte to be counted in the length of the
-      data.

-  

-  
Treat top-level sections started with
-      sbuf_start_section() as a record boundary marker
-      that will be used during drain operations to avoid records being split. If
-      a record grows sufficiently large such that it fills the
-      sbuf and therefore cannot be drained without being
-      split, an error of EDEADLK is set.

-  

-  
Indicates that attempts to extend the storage buffer should fail in low
-      memory conditions, like malloc(9)
-      M_NOWAIT.

-

-
Note that if buf is not
-    NULL, it must point to an array of at least
-    length characters. The result of accessing that array
-    directly while it is in use by the sbuf is undefined.

-
The
-    ()
-    function is a shortcut for creating a completely dynamic
-    sbuf. It is the equivalent of calling
-    sbuf_new() with values NULL,
-    NULL, 0, and
-    SBUF_AUTOEXTEND.

-
The
-    ()
-    function will set up an sbuf with a drain function to use
-    ()
-    when the internal buffer fills. Note that if the various functions which
-    append to an sbuf are used while a non-sleepable lock is held, the user
-    buffer should be wired using
-    ().

-
The
-    ()
-    function clears the sbuf and frees any memory
-    allocated for it. There must be a call to
-    sbuf_delete() for every call to
-    sbuf_new(). Any attempt to access the sbuf after it
-    has been deleted will fail.

-
The
-    ()
-    function invalidates the contents of the sbuf and
-    resets its position to zero.

-
The
-    ()
-    function returns the current user flags. The
-    ()
-    and
-    ()
-    functions set or clear one or more user flags, respectively. The user flags
-    are described under the sbuf_new() function.

-
The
-    ()
-    function sets the sbuf's end position to
-    pos, which is a value between zero and the current
-    position in the buffer. It can only truncate the sbuf to the new
-  position.

-
The
-    ()
-    function appends the first len bytes from the buffer
-    buf to the sbuf.

-
The
-    ()
-    function copies len bytes from the specified userland
-    address into the sbuf.

-
The
-    ()
-    function replaces the contents of the sbuf with the
-    first len bytes from the buffer
-    buf.

-
The
-    ()
-    function appends the NUL-terminated string str to the
-    sbuf at the current position.

-
The
-    ()
-    function sets a drain function func for the
-    sbuf, and records a pointer arg
-    to be passed to the drain on callback. The drain function cannot be changed
-    while sbuf_len is non-zero.

-
The registered drain function
-    sbuf_drain_func will be called with the argument
-    arg provided to
-    (),
-    a pointer data to a byte string that is the contents
-    of the sbuf, and the length len of the data. If the
-    drain function exists, it will be called when the sbuf internal buffer is
-    full, or on behalf of sbuf_finish(). The drain
-    function may drain some or all of the data, but must drain at least 1 byte.
-    The return value from the drain function, if positive, indicates how many
-    bytes were drained. If negative, the return value indicates the negative
-    error code which will be returned from this or a later call to
-    sbuf_finish(). If the returned drained length is 0,
-    an error of EDEADLK is set. To do unbuffered
-    draining, initialize the sbuf with a two-byte buffer. The drain will be
-    called for every byte added to the sbuf. The
-    sbuf_bcopyin(), sbuf_bcpy(),
-    sbuf_clear(), sbuf_copyin(),
-    sbuf_cpy(), sbuf_trim(),
-    sbuf_data(), and sbuf_len()
-    functions cannot be used on an sbuf with a drain.

-
The
-    ()
-    function copies a NUL-terminated string from the specified userland address
-    into the sbuf. If the len
-    argument is non-zero, no more than len characters (not
-    counting the terminating NUL) are copied; otherwise the entire string, or as
-    much of it as can fit in the sbuf, is copied.

-
The
-    ()
-    function replaces the contents of the sbuf with those
-    of the NUL-terminated string str. This is equivalent
-    to calling sbuf_cat() with a fresh
-    sbuf or one which position has been reset to zero with
-    sbuf_clear() or
-    sbuf_setpos().

-
The
-    ()
-    function appends a trailing newline character, if the current line is
-    non-empty and not already terminated by a newline character.

-
The
-    ()
-    function formats its arguments according to the format string pointed to by
-    fmt and appends the resulting string to the
-    sbuf at the current position.

-
The
-    ()
-    function behaves the same as sbuf_printf() except
-    that the arguments are obtained from the variable-length argument list
-    ap.

-
The
-    ()
-    function appends the character c to the
-    sbuf at the current position.

-
The
-    ()
-    function removes trailing whitespace from the
-  sbuf.

-
The
-    ()
-    function returns any error value that the sbuf may
-    have accumulated, either from the drain function, or
-    ENOMEM if the sbuf overflowed.
-    This function is generally not needed and instead the error code from
-    sbuf_finish() is the preferred way to discover
-    whether an sbuf had an error.

-
The
-    ()
-    function will call the attached drain function if one exists until all the
-    data in the sbuf is flushed. If there is no attached
-    drain, sbuf_finish() NUL-terminates the
-    sbuf. In either case it marks the
-    sbuf as finished, which means that it may no longer be
-    modified using sbuf_setpos(),
-    sbuf_cat(), sbuf_cpy(),
-    sbuf_printf() or
-    sbuf_putc(), until
-    sbuf_clear() is used to reset the sbuf.

-
The
-    ()
-    function returns the actual string; sbuf_data() only
-    works on a finished sbuf. The
-    ()
-    function returns the length of the string. For an sbuf
-    with an attached drain, sbuf_len() returns the
-    length of the un-drained data.
-    ()
-    returns non-zero if the sbuf is finished.

-
The
-    ()
-    and
-    ()
-    functions may be used for automatic section alignment. The arguments
-    pad and c specify the padding
-    size and a character used for padding. The arguments
-    old_lenp and old_len are to save
-    and restore the current section length when nested sections are used. For
-    the top level section NULL and -1 can be specified
-    for old_lenp and old_len
-    respectively.

-
The
-    ()
-    function prints an array of bytes to the supplied sbuf, along with an ASCII
-    representation of the bytes if possible. See the
-    hexdump(3) man page for more details on the interface.

-
The
-    ()
-    function is a drain function that will call printf, or log to the console.
-    The argument arg must be either
-    NULL, or a valid pointer to a
-    size_t. If arg is not
-    NULL, the total bytes drained will be added to the
-    value pointed to by arg.

-
The
-    ()
-    function printfs the sbuf to stdout if in userland, and to the console and
-    log if in the kernel. The sbuf must be finished before
-    calling sbuf_putbuf(). It does not drain the buffer
-    or update any pointers.

-

-

-

-
If an operation caused an sbuf to overflow,
-    most subsequent operations on it will fail until the
-    sbuf is finished using
-    sbuf_finish() or reset using
-    sbuf_clear(), or its position is reset to a value
-    between 0 and one less than the size of its storage buffer using
-    sbuf_setpos(), or it is reinitialized to a
-    sufficiently short string using sbuf_cpy().

-
Drains in user-space will not always function as indicated. While
-    the drain function will be called immediately on overflow from the
-    sbuf_putc, sbuf_bcat,
-    sbuf_cat functions, sbuf_printf
-    and sbuf_vprintf currently have no way to determine
-    whether there will be an overflow until after it occurs, and cannot do a
-    partial expansion of the format string. Thus when using libsbuf the buffer
-    may be extended to allow completion of a single printf call, even though a
-    drain is attached.

-

-

-

-
The sbuf_new() function returns
-    NULL if it failed to allocate a storage buffer, and
-    a pointer to the new sbuf otherwise.

-
The sbuf_setpos() function returns -1 if
-    pos was invalid, and zero otherwise.

-
The sbuf_bcat(),
-    sbuf_cat(), sbuf_cpy(),
-    sbuf_printf(), sbuf_putc(),
-    and sbuf_trim() functions all return -1 if the
-    buffer overflowed, and zero otherwise.

-
The sbuf_error() function returns a
-    non-zero value if the buffer has an overflow or drain error, and zero
-    otherwise.

-
The sbuf_len() function returns -1 if the
-    buffer overflowed.

-
The sbuf_copyin() function returns -1 if
-    copying string from userland failed, and number of bytes copied
-  otherwise.

-
The sbuf_end_section() function returns
-    the section length or -1 if the buffer has an error.

-
The sbuf_finish(9)
-    function (the kernel version) returns ENOMEM if the
-    sbuf overflowed before being finished, or returns the error code from the
-    drain if one is attached.

-
The sbuf_finish(3)
-    function (the userland version) will return zero for success and -1 and set
-    errno on error.

-

-

-

-

-
#include <sys/types.h>
-#include <sys/sbuf.h>
-
-struct sbuf *sb;
-
-sb = sbuf_new_auto();
-sbuf_cat(sb, "Customers found:\n");
-TAILQ_FOREACH(foo, &foolist, list) {
-	sbuf_printf(sb, "   %4d %s\n", foo->index, foo->name);
-	sbuf_printf(sb, "      Address: %s\n", foo->address);
-	sbuf_printf(sb, "      Zip: %s\n", foo->zipcode);
-}
-if (sbuf_finish(sb) != 0) /* Check for any and all errors */
-	err(1, "Could not generate message");
-transmit_msg(sbuf_data(sb), sbuf_len(sb));
-sbuf_delete(sb);

-

-

-

-

-
hexdump(3), printf(3),
-    strcat(3), strcpy(3),
-    copyin(9), copyinstr(9),
-    printf(9)

-

-

-

-
The sbuf family of functions first
-    appeared in FreeBSD 4.4.

-

-

-

-
The sbuf family of functions was designed
-    by Poul-Henning Kamp
-    <phk@FreeBSD.org> and
-    implemented by Dag-Erling Smørgrav
-    <des@FreeBSD.org>.
-    Additional improvements were suggested by Justin T.
-    Gibbs
-    <gibbs@FreeBSD.org>.
-    Auto-extend support added by Kelly Yancey
-    <kbyanc@FreeBSD.org>.
-    Drain functionality added by Matthew Fleming
-    <mdf@FreeBSD.org>.

-
This manual page was written by Dag-Erling
-    Smørgrav
-    <des@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 3, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/scheduler.9 4.html b/static/freebsd/man9/scheduler.9 4.html
deleted file mode 100644
index 0e31a487..00000000
--- a/static/freebsd/man9/scheduler.9 4.html	
+++ /dev/null
@@ -1,208 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCHEDULER(9)Kernel Developer's ManualSCHEDULER(9)

-

-

-

-
curpriority_cmp,
-    maybe_resched,
-    resetpriority, roundrobin,
-    roundrobin_interval,
-    sched_setup, schedclock,
-    schedcpu, setrunnable,
-    updatepri — perform
-    round-robin scheduling of runnable processes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
int
-  

-  curpriority_cmp(struct
-    proc *p);

-
void
-  

-  maybe_resched(struct
-    thread *td);

-
void
-  

-  propagate_priority(struct
-    proc *p);

-
void
-  

-  resetpriority(struct
-    ksegrp *kg);

-
void
-  

-  roundrobin(void
-    *arg);

-
int
-  

-  roundrobin_interval(void);

-
void
-  

-  sched_setup(void
-    *dummy);

-
void
-  

-  schedclock(struct
-    thread *td);

-
void
-  

-  schedcpu(void
-    *arg);

-
void
-  

-  setrunnable(struct
-    thread *td);

-
void
-  

-  updatepri(struct
-    thread *td);

-

-

-

-
Each process has three different priorities stored in
-    struct proc: p_usrpri,
-    p_nativepri, and p_priority.

-
The p_usrpri member is the user priority of
-    the process calculated from a process' estimated CPU time and nice
-  level.

-
The p_nativepri
-    member is the saved priority used by
-    ().
-    When a process obtains a mutex, its priority is saved in
-    p_nativepri. While it holds the mutex, the process's
-    priority may be bumped by another process that blocks on the mutex. When the
-    process releases the mutex, then its priority is restored to the priority
-    saved in p_nativepri.

-
The p_priority member is the actual priority
-    of the process and is used to determine what runqueue(9)
-    it runs on, for example.

-
The
-    ()
-    function compares the cached priority of the currently running process with
-    process p. If the currently running process has a
-    higher priority, then it will return a value less than zero. If the current
-    process has a lower priority, then it will return a value greater than zero.
-    If the current process has the same priority as p,
-    then curpriority_cmp() will return zero. The cached
-    priority of the currently running process is updated when a process resumes
-    from tsleep(9) or returns to userland in
-    ()
-    and is stored in the private variable curpriority.

-
The
-    ()
-    function compares the priorities of the current thread and
-    td. If td has a higher priority
-    than the current thread, then a context switch is needed, and
-    KEF_NEEDRESCHED is set.

-
The
-    ()
-    looks at the process that owns the mutex p is blocked
-    on. That process's priority is bumped to the priority of
-    p if needed. If the process is currently running, then
-    the function returns. If the process is on a runqueue(9),
-    then the process is moved to the appropriate runqueue(9)
-    for its new priority. If the process is blocked on a mutex, its position in
-    the list of processes blocked on the mutex in question is updated to reflect
-    its new priority. Then, the function repeats the procedure using the process
-    that owns the mutex just encountered. Note that a process's priorities are
-    only bumped to the priority of the original process p,
-    not to the priority of the previously encountered process.

-
The
-    ()
-    function recomputes the user priority of the ksegrp kg
-    (stored in kg_user_pri) and calls
-    maybe_resched() to force a reschedule of each thread
-    in the group if needed.

-
The
-    ()
-    function is used as a timeout(9) function to force a
-    reschedule every sched_quantum ticks.

-
The
-    ()
-    function simply returns the number of clock ticks in between reschedules
-    triggered by roundrobin(). Thus, all it does is
-    return the current value of sched_quantum.

-
The
-    ()
-    function is a SYSINIT(9) that is called to start the
-    callout driven scheduler functions. It just calls the
-    roundrobin() and schedcpu()
-    functions for the first time. After the initial call, the two functions will
-    propagate themselves by registering their callout event again at the
-    completion of the respective function.

-
The
-    ()
-    function is called by
-    ()
-    to adjust the priority of the currently running thread's ksegrp. It updates
-    the group's estimated CPU time and then adjusts the priority via
-    resetpriority().

-
The
-    ()
-    function updates all process priorities. First, it updates statistics that
-    track how long processes have been in various process states. Secondly, it
-    updates the estimated CPU time for the current process such that about 90%
-    of the CPU usage is forgotten in 5 * load average seconds. For example, if
-    the load average is 2.00, then at least 90% of the estimated CPU time for
-    the process should be based on the amount of CPU time the process has had in
-    the last 10 seconds. It then recomputes the priority of the process and
-    moves it to the appropriate runqueue(9) if necessary.
-    Thirdly, it updates the %CPU estimate used by utilities such as
-    ps(1) and top(1) so that 95% of the CPU
-    usage is forgotten in 60 seconds. Once all process priorities have been
-    updated, schedcpu() calls
-    ()
-    to update various other statistics including the load average. Finally, it
-    schedules itself to run again in hz clock ticks.

-
The
-    ()
-    function is used to change a process's state to be runnable. The process is
-    placed on a runqueue(9) if needed, and the swapper process
-    is woken up and told to swap the process in if the process is swapped out.
-    If the process has been asleep for at least one run of
-    schedcpu(), then updatepri()
-    is used to adjust the priority of the process.

-
The
-    ()
-    function is used to adjust the priority of a process that has been asleep.
-    It retroactively decays the estimated CPU time of the process for each
-    schedcpu() event that the process was asleep.
-    Finally, it calls resetpriority() to adjust the
-    priority of the process.

-

-

-

-
mi_switch(9), runqueue(9),
-    sleepqueue(9), tsleep(9)

-

-

-

-
The curpriority variable really should be
-    per-CPU. In addition, maybe_resched() should compare
-    the priority of chk with that of each CPU, and then
-    send an IPI to the processor with the lowest priority to trigger a
-    reschedule if needed.

-
Priority propagation is broken and is thus disabled by default.
-    The p_nativepri variable is only updated if a process
-    does not obtain a sleep mutex on the first try. Also, if a process obtains
-    more than one sleep mutex in this manner, and had its priority bumped in
-    between, then p_nativepri will be clobbered.

-

-

-
-  
-    
-    
-  
-
November 3, 2000FreeBSD 15.0

diff --git a/static/freebsd/man9/securelevel_gt.9 4.html b/static/freebsd/man9/securelevel_gt.9 4.html
deleted file mode 100644
index f71286f0..00000000
--- a/static/freebsd/man9/securelevel_gt.9 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
SECURELEVEL_GT(9)Kernel Developer's ManualSECURELEVEL_GT(9)

-

-

-

-
securelevel_gt,
-    securelevel_ge — test active
-    securelevel

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/proc.h>

-
int
-  

-  securelevel_gt(struct
-    ucred *cr, int
-    level);

-
int
-  

-  securelevel_ge(struct
-    ucred *cr, int
-    level);

-

-

-

-
These functions test the active security level against the given
-    level. If the calling credential
-    cr was imprisoned by the jail(2)
-    system call, and has a different security level set than the host
-    environment, the security level with the highest value is used.

-
The
-    ()
-    function will evaluate whether or not the active security level is greater
-    than the supplied level.

-
The
-    ()
-    function will evaluate whether or not the active security level is greater
-    than or equal to the supplied level.

-

-

-

-
These functions return EPERM if condition
-    evaluated to true, and 0 otherwise.

-

-

-

-
securelevel(7)

-

-

-
-  
-    
-    
-  
-
June 2, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/selrecord.9 4.html b/static/freebsd/man9/selrecord.9 4.html
deleted file mode 100644
index 9a70d9b4..00000000
--- a/static/freebsd/man9/selrecord.9 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
SELRECORD(9)Kernel Developer's ManualSELRECORD(9)

-

-

-

-
seldrain,
-    selrecord, selwakeup
-    — record and wakeup select requests

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/selinfo.h>

-
void
-  

-  seldrain(struct
-    selinfo *sip);

-
void
-  

-  selrecord(struct
-    thread *td, struct
-    selinfo *sip);

-
void
-  

-  selwakeup(struct
-    selinfo *sip);

-

-

-

-
(),
-    selrecord() and selwakeup()
-    are the three central functions used by select(2),
-    poll(2) and the objects that are being selected on. They
-    handle the task of recording which threads are waiting on which objects and
-    the waking of the proper threads when an event of interest occurs on an
-    object.

-
()
-    records that the calling thread is interested in events related to a given
-    object. If another thread is already waiting on the object a collision will
-    be flagged in sip which will be later dealt with by
-    selwakeup().

-
()
-    acquires and releases sellock.

-
()
-    is called by the underlying object handling code in order to notify any
-    waiting threads that an event of interest has occurred. If a collision has
-    occurred, selwakeup() will increment
-    nselcoll, and broadcast on the global cv in order to
-    wake all waiting threads so that they can handle it. If the thread waiting
-    on the object is not currently sleeping or the wait channel is not
-    selwait, selwakeup() will
-    clear the TDF_SELECT flag which should be noted by
-    select(2) and poll(2) when they wake
-  up.

-
()
-    will flush the waiters queue on a specified object before its destruction.
-    The object handling code must ensure that *sip cannot
-    be used once seldrain() has been called.

-
The contents of *sip must
-    be zeroed, such as by softc initialization, before any call to
-    ()
-    or selwakeup(), otherwise a panic may occur.
-    selwakeup() acquires and releases
-    sellock and may acquire and release
-    sched_lock. seldrain() could
-    usually be just a wrapper for selwakeup(), but
-    consumers should not generally rely on this feature.

-

-

-

-
poll(2), select(2)

-

-

-

-
This manual page was written by Chad David
-    <davidc@FreeBSD.org>
-    and Alfred Perlstein
-    <alfred@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 25, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/sema.9 4.html b/static/freebsd/man9/sema.9 4.html
deleted file mode 100644
index ca4f197b..00000000
--- a/static/freebsd/man9/sema.9 4.html	
+++ /dev/null
@@ -1,126 +0,0 @@
-
-  
-    
-    
-    
-  
-
SEMA(9)Kernel Developer's ManualSEMA(9)

-

-

-

-
sema, sema_init,
-    sema_destroy, sema_post,
-    sema_wait, sema_timedwait,
-    sema_trywait, sema_value
-    — kernel counting semaphore

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/sema.h>

-
void
-  

-  sema_init(struct
-    sema *sema, int
-    value, const char
-    *description);

-
void
-  

-  sema_destroy(struct
-    sema *sema);

-
void
-  

-  sema_post(struct
-    sema *sema);

-
void
-  

-  sema_wait(struct
-    sema *sema);

-
int
-  

-  sema_timedwait(struct
-    sema *sema, int
-    timo);

-
int
-  

-  sema_trywait(struct
-    sema *sema);

-
int
-  

-  sema_value(struct
-    sema *sema);

-

-

-

-
Counting semaphores provide a mechanism for synchronizing access
-    to a pool of resources. Unlike mutexes, semaphores do not have the concept
-    of an owner, so they can also be useful in situations where one thread needs
-    to acquire a resource, and another thread needs to release it. Each
-    semaphore has an integer value associated with it. Posting (incrementing)
-    always succeeds, but waiting (decrementing) can only successfully complete
-    if the resulting value of the semaphore is greater than or equal to
-  zero.

-
Semaphores should not be used where mutexes and condition
-    variables will suffice. Semaphores are a more complex synchronization
-    mechanism than mutexes and condition variables, and are not as
-  efficient.

-
Semaphores are created with
-    (),
-    where sema is a pointer to space for a
-    struct sema, value is the
-    initial value of the semaphore, and description is a
-    pointer to a null-terminated character string that describes the semaphore.
-    Semaphores are destroyed with
-    ().
-    A semaphore is posted (incremented) with
-    ().
-    A semaphore is waited on (decremented) with
-    (),
-    (),
-    or
-    ().
-    The timo argument to
-    sema_timedwait() specifies the minimum time in ticks
-    to wait before returning with failure.
-    ()
-    is used to read the current value of the semaphore.

-

-

-

-
The sema_value() function returns the
-    current value of the semaphore.

-
If decrementing the semaphore would result in its value being
-    negative, sema_trywait() returns 0 to indicate
-    failure. Otherwise, a non-zero value is returned to indicate success.

-
The sema_timedwait() function returns 0 if
-    waiting on the semaphore succeeded; otherwise a non-zero error code is
-    returned.

-

-

-

-
The sema_timedwait() function will fail
-    if:

-

-  
[]

-  
Timeout expired.

-

-

-

-

-
condvar(9), locking(9),
-    mtx_pool(9), mutex(9),
-    rwlock(9), sx(9)

-

-

-
-  
-    
-    
-  
-
February 1, 2006FreeBSD 15.0

diff --git a/static/freebsd/man9/seqc.9 4.html b/static/freebsd/man9/seqc.9 4.html
deleted file mode 100644
index 29e244d3..00000000
--- a/static/freebsd/man9/seqc.9 4.html	
+++ /dev/null
@@ -1,124 +0,0 @@
-
-  
-    
-    
-    
-  
-
SEQC(9)Kernel Developer's ManualSEQC(9)

-

-

-

-
seqc_consistent,
-    seqc_read, seqc_write_begin,
-    seqc_write_end — lockless
-    read algorithm

-

-

-

-
#include
-    <sys/seqc.h>

-
void
-  

-  seqc_write_begin(seqc_t
-    *seqcp);

-
void
-  

-  seqc_write_end(seqc_t
-    *seqcp);

-
seqc_t
-  

-  seqc_read(seqc_t
-    *seqcp);

-
seqc_t
-  

-  seqc_consistent(const
-    seqc_t *seqcp, seqc_t
-    oldseqc);

-

-

-

-
The seqc allows zero or more readers and
-    zero or one writer to concurrently access an object, providing a consistent
-    snapshot of the object for readers. No mutual exclusion between readers and
-    writers is required, but readers may be starved indefinitely by writers.

-
The functions
-    ()
-    and
-    ()
-    are used to create a transaction for writer, and notify the readers that the
-    object will be modified.

-
The
-    ()
-    function returns the current sequence number. If a writer has started a
-    transaction, this function will spin until the transaction has ended.

-
The
-    ()
-    function compares the sequence number with a previously fetched value. The
-    oldseqc variable should contain a sequence number from
-    the beginning of read transaction.

-
The reader at the end of a transaction checks if the sequence
-    number has changed. If the sequence number didn't change the object wasn't
-    modified, and fetched variables are valid. If the sequence number changed
-    the object was modified and the fetch should be repeated. In case when
-    sequence number is odd the object change is in progress and the reader will
-    wait until the write will the sequence number will become even.

-

-

-

-
The following example for a writer changes the
-    var1 and var2 variables in the
-    obj structure:

-

-
lock_exclusive(&obj->lock);
-seqc_write_begin(&obj->seqc);
-obj->var1 = 1;
-obj->var2 = 2;
-seqc_write_end(&obj->seqc);
-unlock_exclusive(&obj->lock);

-

-
The following example for a reader reads the
-    var1 and var2 variables from the
-    obj structure. In the case where the sequence number
-    was changed it restarts the whole process.

-

-
int var1, var2;
-seqc_t seqc;
-
-for (;;) {
-	seqc = seqc_read(&obj->seqc);
-	var1 = obj->var1;
-	var2 = obj->var2;
-	if (seqc_consistent(&obj->seqc, seqc))
-		break;
-}

-

-

-

-

-
The seqc functions was implemented by
-    Mateusz Guzik
-    <mjg@FreeBSD.org>.
-    This manual page was written by
-  

-  Mariusz Zaborski
-    <oshogbo@FreeBSD.org>.

-

-

-

-
There is no guarantee of progress for readers. In case when there
-    are a lot of writers the reader can be starved. This concern may be solved
-    by returning error after a few attempts.

-
Theoretically if reading takes a very long time, and when there
-    are many writers the counter may overflow and wrap around to the same value.
-    In that case the reader will not notice that the object was changed. Given
-    that this needs 4 billion transactional writes across a single contended
-    reader, it is unlikely to ever happen. This could be avoided by extending
-    the interface to allow 64-bit counters.

-

-

-
-  
-    
-    
-  
-
July 29, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/sf_buf.9 3.html b/static/freebsd/man9/sf_buf.9 3.html
deleted file mode 100644
index c151edb6..00000000
--- a/static/freebsd/man9/sf_buf.9 3.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
SF_BUF(9)Kernel Developer's ManualSF_BUF(9)

-

-

-

-
sf_buf — manage
-    temporary kernel address space mapping for memory pages

-

-

-

-
#include
-    <sys/sf_buf.h>

-
struct sf_buf *
-  

-  sf_buf_alloc(struct
-    vm_page *m, int
-    flags);

-
void
-  

-  sf_buf_free(struct
-    sf_buf *sf);

-
vm_offset_t
-  

-  sf_buf_kva(struct
-    sf_buf *sf);

-
struct vm_page *
-  

-  sf_buf_page(struct
-    sf_buf *sf);

-

-

-

-
The sf_buf interface, historically the
-    sendfile(2) buffer interface, allows kernel subsystems to
-    manage temporary kernel address space mappings for physical memory pages. On
-    systems with a direct memory map region (allowing all physical pages to be
-    visible in the kernel address space at all times), the
-    struct sf_buf will point to an address in the direct
-    map region; on systems without a direct memory map region, the
-    struct sf_buf will manage a temporary kernel address
-    space mapping valid for the lifetime of the struct
-    sf_buf.

-
Call
-    ()
-    to allocate a struct sf_buf for a physical memory
-    page. sf_buf_alloc() is not responsible for
-    arranging for the page to be present in physical memory; the caller should
-    already have arranged for the page to be wired, i.e., by calling
-    vm_page_wire(9). Several flags may be passed to
-    sf_buf_alloc():

-

-  

-  
Cause sf_buf_alloc() to abort and return
-      NULL if a signal is received waiting for a
-      struct sf_buf to become available.

-  

-  
Cause sf_buf_alloc() to return
-      NULL rather than sleeping if a
-      struct sf_buf is not immediately available.

-  

-  
Cause sf_buf_alloc() to only arrange that the
-      temporary mapping be valid on the current CPU, avoiding unnecessary TLB
-      shootdowns for mappings that will only be accessed on a single CPU at a
-      time. The caller must ensure that accesses to the virtual address occur
-      only on the CPU from which sf_buf_alloc() was
-      invoked, perhaps by using
-      ().

-

-
Call
-    ()
-    to return a kernel mapped address for the page.

-
Call
-    ()
-    to return a pointer to the page originally passed into
-    sf_buf_alloc().

-
Call
-    ()
-    to release the struct sf_buf reference. The caller is
-    responsible for releasing any wiring they have previously acquired on the
-    physical page; sf_buf_free() releases only the
-    temporary kernel address space mapping, not the page itself.

-
Uses of this interface include managing mappings of borrowed pages
-    from user memory, such as in zero-copy socket I/O, or pages of memory from
-    the buffer cache referenced by mbuf external storage for
-    sendfile(2).

-

-

-

-
sendfile(2),
-  vm_page_wire(9)

-

-

-

-
The struct sf_buf API was designed and
-    implemented by Alan L. Cox. This manual page was
-    written by Robert N. M. Watson.

-

-

-
-  
-    
-    
-  
-
January 28, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/sglist.9 4.html b/static/freebsd/man9/sglist.9 4.html
deleted file mode 100644
index 237d7500..00000000
--- a/static/freebsd/man9/sglist.9 4.html	
+++ /dev/null
@@ -1,471 +0,0 @@
-
-  
-    
-    
-    
-  
-
SGLIST(9)Kernel Developer's ManualSGLIST(9)

-

-

-

-
sglist,
-    sglist_alloc, sglist_append,
-    sglist_append_bio,
-    sglist_append_mbuf,
-    sglist_append_mbuf_epg,
-    sglist_append_phys,
-    sglist_append_sglist,
-    sglist_append_single_mbuf,
-    sglist_append_uio,
-    sglist_append_user,
-    sglist_append_vmpages,
-    sglist_build, sglist_clone,
-    sglist_consume_uio,
-    sglist_count,
-    sglist_count_mbuf_epg,
-    sglist_count_vmpages,
-    sglist_free, sglist_hold,
-    sglist_init, sglist_join,
-    sglist_length, sglist_reset,
-    sglist_slice, sglist_split
-    — manage a scatter/gather list of physical memory
-    addresses

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/sglist.h>

-
struct sglist *
-  

-  sglist_alloc(int
-    nsegs, int
-  mflags);

-
int
-  

-  sglist_append(struct
-    sglist *sg, void
-    *buf, size_t
-  len);

-
int
-  

-  sglist_append_bio(struct
-    sglist *sg, struct bio
-    *bp);

-
int
-  

-  sglist_append_mbuf_epg(struct
-    sglist *sg, struct mbuf
-    *m, size_t offset,
-    size_t len);

-
int
-  

-  sglist_append_mbuf(struct
-    sglist *sg, struct mbuf
-    *m);

-
int
-  

-  sglist_append_phys(struct
-    sglist *sg, vm_paddr_t
-    paddr, size_t
-  len);

-
int
-  

-  sglist_append_sglist(struct
-    sglist *sg, struct sglist
-    *source, size_t
-    offset, size_t
-    len);

-
int
-  

-  sglist_append_single_mbuf(struct
-    sglist *sg, struct mbuf
-    *m);

-
int
-  

-  sglist_append_uio(struct
-    sglist *sg, struct uio
-    *uio);

-
int
-  

-  sglist_append_user(struct
-    sglist *sg, void
-    *buf, size_t len,
-    struct thread *td);

-
int
-  

-  sglist_append_vmpages(struct
-    sglist *sg, vm_page_t
-    *m, size_t pgoff,
-    size_t len);

-
struct sglist *
-  

-  sglist_build(void
-    *buf, size_t len,
-    int mflags);

-
struct sglist *
-  

-  sglist_clone(struct
-    sglist *sg, int
-    mflags);

-
int
-  

-  sglist_consume_uio(struct
-    sglist *sg, struct uio
-    *uio, size_t
-    resid);

-
int
-  

-  sglist_count(void
-    *buf, size_t
-  len);

-
int
-  

-  sglist_count_mbuf_epg(struct
-    mbuf *m, size_t
-    offset, size_t
-    len);

-
int
-  

-  sglist_count_vmpages(vm_page_t
-    *m, size_t pgoff,
-    size_t len);

-
void
-  

-  sglist_free(struct
-    sglist *sg);

-
struct sglist *
-  

-  sglist_hold(struct
-    sglist *sg);

-
void
-  

-  sglist_init(struct
-    sglist *sg, int
-    maxsegs, struct
-    sglist_seg *segs);

-
int
-  

-  sglist_join(struct
-    sglist *first, struct
-    sglist *second);

-
size_t
-  

-  sglist_length(struct
-    sglist *sg);

-
void
-  

-  sglist_reset(struct
-    sglist *sg);

-
int
-  

-  sglist_slice(struct
-    sglist *original, struct
-    sglist **slice, size_t
-    offset, size_t
-    length, int
-    mflags);

-
int
-  

-  sglist_split(struct
-    sglist *original, struct
-    sglist **head, size_t
-    length, int
-    mflags);

-

-

-

-
The sglist API manages physical address
-    ranges. Each list contains one or more elements. Each element contains a
-    starting physical address and a length. Scatter/gather lists are read-only
-    while they are shared. If one wishes to alter an existing scatter/gather
-    list and does not hold the sole reference to the list, then one should
-    create a new list instead of modifying the existing list.

-
Each scatter/gather list object contains a reference count. New
-    lists are created with a single reference. New references are obtained by
-    calling sglist_hold and are released by calling
-    sglist_free.

-

-

-
Each sglist object consists of a header
-    structure and a variable-length array of scatter/gather list elements. The
-    sglist_alloc function allocates a new list that
-    contains a header and nsegs scatter/gather list
-    elements. The mflags argument can be set to either
-    M_NOWAIT or M_WAITOK.

-
The sglist_count function returns the
-    number of scatter/gather list elements needed to describe the physical
-    address ranges mapped by a single kernel virtual address range. The kernel
-    virtual address range starts at buf and is
-    len bytes long.

-
The sglist_count_mbuf_epg function returns
-    the number of scatter/gather list elements needed to describe the external
-    multipage mbuf buffer m. The ranges start at an offset
-    of offset relative to the start of the buffer and is
-    len bytes long.

-
The sglist_count_vmpages function returns
-    the number of scatter/gather list elements needed to describe the physical
-    address ranges of a buffer backed by an array of virtual memory pages
-    m. The buffer starts at an offset of
-    pgoff bytes relative to the first page and is
-    len bytes long.

-
The sglist_build function allocates a new
-    scatter/gather list object that describes the physical address ranges mapped
-    by a single kernel virtual address range. The kernel virtual address range
-    starts at buf and is len bytes
-    long. The mflags argument can be set to either
-    M_NOWAIT or M_WAITOK.

-
The sglist_clone function returns a copy
-    of an existing scatter/gather list object sg. The
-    mflags argument can be set to either
-    M_NOWAIT or M_WAITOK. This
-    can be used to obtain a private copy of a scatter/gather list before
-    modifying it.

-
The sglist_init function initializes a
-    scatter/gather list header. The header is pointed to by
-    sg and is initialized to manage an array of
-    maxsegs scatter/gather list elements pointed to by
-    segs. This can be used to initialize a scatter/gather
-    list header whose storage is not provided by
-    sglist_alloc. In that case, the caller should not
-    call sglist_free to release its own reference and is
-    responsible for ensuring all other references to the list are dropped before
-    it releases the storage for sg and
-    segs.

-

-

-

-
The sglist API provides several routines
-    for building a scatter/gather list to describe one or more objects.
-    Specifically, the sglist_append family of routines
-    can be used to append the physical address ranges described by an object to
-    the end of a scatter/gather list. All of these routines return 0 on success
-    or an error on failure. If a request to append an address range to a
-    scatter/gather list fails, the scatter/gather list will remain
-  unchanged.

-
The sglist_append function appends the
-    physical address ranges described by a single kernel virtual address range
-    to the scatter/gather list sg. The kernel virtual
-    address range starts at buf and is
-    len bytes long.

-
The sglist_append_bio function appends the
-    physical address ranges described by a single bio bp
-    to the scatter/gather list sg.

-
The sglist_append_mbuf_epg function
-    appends the physical address ranges described by the external multipage
-    mbuf(9) buffer ext_pgs to the
-    scatter/gather list sg. The physical address ranges
-    start at offset offset within
-    ext_pgs and continue for len
-    bytes. Note that unlike sglist_append_mbuf,
-    sglist_append_mbuf_epg only adds ranges for a single
-    mbuf, not an entire mbuf chain.

-
The sglist_append_mbuf function appends
-    the physical address ranges described by an entire mbuf chain
-    m to the scatter/gather list
-  sg.

-
The sglist_append_single_mbuf function
-    appends the physical address ranges described by a single mbuf
-    m to the scatter/gather list
-  sg.

-
The sglist_append_phys function appends a
-    single physical address range to the scatter/gather list
-    sg. The physical address range starts at
-    paddr and is len bytes long.

-
The sglist_append_sglist function appends
-    physical address ranges described by the scatter/gather list
-    source to the scatter/gather list
-    sg. The physical address ranges start at offset
-    offset within source and
-    continue for len bytes.

-
The sglist_append_uio function appends the
-    physical address ranges described by a uio(9) object to
-    the scatter/gather list sg. Note that it is the
-    caller's responsibility to ensure that the pages backing the I/O request are
-    wired for the lifetime of sg. Note also that this
-    routine does not modify uio.

-
The sglist_append_user function appends
-    the physical address ranges described by a single user virtual address range
-    to the scatter/gather list sg. The user virtual
-    address range is relative to the address space of the thread
-    td. It starts at buf and is
-    len bytes long. Note that it is the caller's
-    responsibility to ensure that the pages backing the user buffer are wired
-    for the lifetime of sg.

-
The sglist_append_vmpages function appends
-    the physical address ranges of a buffer backed by an array of virtual memory
-    pages m. The buffer starts at an offset of
-    pgoff bytes relative to the first page and is
-    len bytes long.

-
The sglist_consume_uio function is a
-    variation of sglist_append_uio. As with
-    sglist_append_uio, it appends the physical address
-    ranges described by uio to the scatter/gather list
-    sg. Unlike sglist_append_uio,
-    however, sglist_consume_uio modifies the I/O request
-    to indicate that the appended address ranges have been processed similar to
-    calling uiomove(9). This routine will only append ranges
-    that describe up to resid total bytes in length. If
-    the available segments in the scatter/gather list are exhausted before
-    resid bytes are processed, then the
-    uio structure will be updated to reflect the actual
-    number of bytes processed, and sglist_consume_io
-    will return zero to indicate success. In effect, this function will perform
-    partial reads or writes. The caller can compare the
-    uio_resid member of uio before
-    and after calling sglist_consume_uio to determine
-    the actual number of bytes processed.

-

-

-

-
The sglist_join function appends physical
-    address ranges from the scatter/gather list second
-    onto first and then resets
-    second to an empty list. It returns zero on success or
-    an error on failure.

-
The sglist_split function splits an
-    existing scatter/gather list into two lists. The first
-    length bytes described by the list
-    original are moved to a new list
-    *head. If original describes a
-    total address range that is smaller than length bytes,
-    then all of the address ranges will be moved to the new list at
-    *head and original will be an
-    empty list. The caller may supply an existing scatter/gather list in
-    *head. If so, the list must be empty. Otherwise, the
-    caller may set *head to NULL
-    in which case a new scatter/gather list will be allocated. In that case,
-    mflags may be set to either
-    M_NOWAIT or M_WAITOK. Note
-    that since the original list is modified by this call,
-    it must be a private list with no other references. The
-    sglist_split function returns zero on success or an
-    error on failure.

-
The sglist_slice function generates a new
-    scatter/gather list from a sub-range of an existing scatter/gather list
-    original. The sub-range to extract is specified by the
-    offset and length parameters.
-    The new scatter/gather list is stored in *slice. As
-    with head for sglist_join, the
-    caller may either provide an empty scatter/gather list, or it may set
-    *slice to NULL in which case
-    sglist_slice will allocate a new list subject to
-    mflags. Unlike sglist_split,
-    sglist_slice does not modify
-    original and does not require it to be a private list.
-    The sglist_split function returns zero on success or
-    an error on failure.

-

-

-

-
The sglist_reset function clears the
-    scatter/gather list sg so that it no longer maps any
-    address ranges. This can allow reuse of a single scatter/gather list object
-    for multiple requests.

-
The sglist_length function returns the
-    total length of the physical address ranges described by the scatter/gather
-    list sg.

-

-

-

-

-
The sglist_alloc,
-    sglist_build, and
-    sglist_clone functions return a new scatter/gather
-    list on success or NULL on failure.

-
The sglist_append family of functions and
-    the sglist_consume_uio,
-    sglist_join, sglist_slice,
-    and sglist_split functions return zero on success or
-    an error on failure.

-
The sglist_count family of functions
-    return a count of scatter/gather list elements.

-
The sglist_length function returns a count
-    of address space described by a scatter/gather list in bytes.

-

-

-

-
The sglist_append functions return the
-    following errors on failure:

-

-  
[]

-  
The scatter/gather list has zero segments.

-  
[]

-  
There are not enough available segments in the scatter/gather list to
-      append the specified physical address ranges.

-

-
The sglist_consume_uio function returns
-    the following error on failure:

-

-  
[]

-  
The scatter/gather list has zero segments.

-

-
The sglist_join function returns the
-    following error on failure:

-

-  
[]

-  
There are not enough available segments in the scatter/gather list
-      first to append the physical address ranges from
-      second.

-

-
The sglist_slice function returns the
-    following errors on failure:

-

-  
[]

-  
The original scatter/gather list does not describe
-      enough address space to cover the requested sub-range.

-  
[]

-  
The caller-supplied scatter/gather list in *slice is
-      not empty.

-  
[]

-  
An attempt to allocate a new scatter/gather list with
-      M_NOWAIT set in mflags
-      failed.

-  
[]

-  
There are not enough available segments in the caller-supplied
-      scatter/gather list in *slice to describe the
-      requested physical address ranges.

-

-
The sglist_split function returns the
-    following errors on failure:

-

-  
[]

-  
The original scatter/gather list has more than one
-      reference.

-  
[]

-  
The caller-supplied scatter/gather list in *head is
-      not empty.

-  
[]

-  
An attempt to allocate a new scatter/gather list with
-      M_NOWAIT set in mflags
-      failed.

-  
[]

-  
There are not enough available segments in the caller-supplied
-      scatter/gather list in *head to describe the
-      requested physical address ranges.

-

-

-

-

-
g_bio(9), malloc(9),
-    mbuf(9), uio(9)

-

-

-

-
This API was first introduced in FreeBSD
-    8.0.

-

-

-
-  
-    
-    
-  
-
May 25, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/shm_map.9 4.html b/static/freebsd/man9/shm_map.9 4.html
deleted file mode 100644
index 0fd117c8..00000000
--- a/static/freebsd/man9/shm_map.9 4.html	
+++ /dev/null
@@ -1,163 +0,0 @@
-
-  
-    
-    
-    
-  
-
SHM_MAP(9)Kernel Developer's ManualSHM_MAP(9)

-

-

-

-
shm_map, shm_unmap
-    — map shared memory objects into the kernel's
-    address space

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/mman.h>

-
int
-  

-  shm_map(struct
-    file *fp, size_t
-    size, off_t offset,
-    void **memp);

-
int
-  

-  shm_unmap(struct
-    file *fp, void
-    *mem, size_t
-  size);

-

-

-

-
The
-    ()
-    and shm_unmap() functions provide an API for mapping
-    shared memory objects into the kernel. Shared memory objects are created by
-    shm_open(2). These objects can then be passed into the
-    kernel via file descriptors.

-
A shared memory object cannot be shrunk while it is mapped into
-    the kernel. This is to avoid invalidating any pages that may be wired into
-    the kernel's address space. Shared memory objects can still be grown while
-    mapped into the kernel.

-
To simplify the accounting needed to enforce the
-    above requirement, callers of this API are required to unmap the entire
-    region mapped by
-    ()
-    when calling shm_unmap(). Unmapping only a portion
-    of the region is not permitted.

-
The
-    ()
-    function locates the shared memory object associated with the open file
-    fp. It maps the region of that object described by
-    offset and size into the
-    kernel's address space. If it succeeds, *memp will be
-    set to the start of the mapping. All pages for the range will be wired into
-    memory upon successful return.

-
The
-    ()
-    function unmaps a region previously mapped by
-    shm_map(). The mem argument
-    should match the value previously returned in *memp,
-    and the size argument should match the value passed to
-    shm_map().

-
Note that
-    ()
-    will not hold an extra reference on the open file fp
-    for the lifetime of the mapping. Instead, the calling code is required to do
-    this if it wishes to use shm_unmap() on the region
-    in the future.

-

-

-

-
The shm_map() and
-    shm_unmap() functions return zero on success or an
-    error on failure.

-

-

-

-
The following function accepts a file descriptor for a shared
-    memory object. It maps the first sixteen kilobytes of the object into the
-    kernel, performs some work on that address, and then unmaps the address
-    before returning.

-

-
int
-shm_example(int fd)
-{
-	struct file *fp;
-	void *mem;
-	int error;
-
-	error = fget(curthread, fd, CAP_MMAP, &fp);
-	if (error)
-		return (error);
-	error = shm_map(fp, 16384, 0, &mem);
-	if (error) {
-		fdrop(fp, curthread);
-		return (error);
-	}
-
-	/* Do something with 'mem'. */
-
-	error = shm_unmap(fp, mem, 16384);
-	fdrop(fp, curthread);
-	return (error);
-}

-

-

-

-

-
The shm_map() function returns the
-    following errors on failure:

-

-  
[]

-  
The open file fp is not a shared memory object.

-  
[]

-  
The requested region described by offset and
-      size extends beyond the end of the shared memory
-      object.

-  
[]

-  
Insufficient address space was available.

-  
[]

-  
The shared memory object could not be mapped due to a protection
-    error.

-  
[]

-  
The shared memory object could not be mapped due to some other VM
-    error.

-

-
The shm_unmap() function returns the
-    following errors on failure:

-

-  
[]

-  
The open file fp is not a shared memory object.

-  
[]

-  
The address range described by mem and
-      size is not a valid address range.

-  
[]

-  
The address range described by mem and
-      size is not backed by the shared memory object
-      associated with the open file fp, or the address
-      range does not cover the entire mapping of the object.

-

-

-

-

-
shm_open(2)

-

-

-

-
This API was first introduced in FreeBSD
-    10.0.

-

-

-
-  
-    
-    
-  
-
December 14, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/signal.9 4.html b/static/freebsd/man9/signal.9 4.html
deleted file mode 100644
index 5e0e079d..00000000
--- a/static/freebsd/man9/signal.9 4.html	
+++ /dev/null
@@ -1,356 +0,0 @@
-
-  
-    
-    
-    
-  
-
SIGNAL(9)Kernel Developer's ManualSIGNAL(9)

-

-

-

-
signal, SIGADDSET,
-    SIGDELSET, SETEMPTYSET,
-    SIGFILLSET, SIGISMEMBER,
-    SIGISEMPTY, SIGNOTEMPTY,
-    SIGSETEQ, SIGSETNEQ,
-    SIGSETOR, SIGSETAND,
-    SIGSETNAND, SIGSETCANTMASK,
-    SIG_STOPSIGMASK,
-    SIG_CONTSIGMASK, SIGPENDING,
-    cursig, execsigs,
-    issignal, killproc,
-    pgsigio, postsig,
-    sigexit, siginit,
-    signotify, trapsignal
-    — kernel signal functions

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>
-  

-  #include <sys/signalvar.h>

-
void
-  

-  SIGADDSET(sigset_t
-    set, int
-  signo);

-
void
-  

-  SIGDELSET(sigset_t
-    set, int
-  signo);

-
void
-  

-  SIGEMPTYSET(sigset_t
-    set);

-
void
-  

-  SIGFILLSET(sigset_t
-    set);

-
int
-  

-  SIGISMEMBER(sigset_t
-    set, int
-  signo);

-
int
-  

-  SIGISEMPTY(sigset_t
-    set);

-
int
-  

-  SIGNOTEMPTY(sigset_t
-    set);

-
int
-  

-  SIGSETEQ(sigset_t
-    set1, sigset_t
-    set2);

-
int
-  

-  SIGSETNEQ(sigset_t
-    set1, sigset_t
-    set2);

-
void
-  

-  SIGSETOR(sigset_t
-    set1, sigset_t
-    set2);

-
void
-  

-  SIGSETAND(sigset_t
-    set1, sigset_t
-    set2);

-
void
-  

-  SIGSETNAND(sigset_t
-    set1, sigset_t
-    set2);

-
void
-  

-  SIG_CANTMASK(sigset_t
-    set);

-
void
-  

-  SIG_STOPSIGMASK(sigset_t
-    set);

-
void
-  

-  SIG_CONTSIGMASK(sigset_t
-    set);

-
int
-  

-  SIGPENDING(struct
-    proc *p);

-
int
-  

-  cursig(struct
-    thread *td);

-
void
-  

-  execsigs(struct
-    proc *p);

-
int
-  

-  issignal(struct
-    thread *td);

-
void
-  

-  killproc(struct
-    proc *p, char
-    *why);

-
void
-  

-  pgsigio(struct
-    sigio **sigiop, int
-    sig, int
-    checkctty);

-
void
-  

-  postsig(int
-    sig);

-
void
-  

-  sigexit(struct
-    thread *td, int
-    signum);

-
void
-  

-  siginit(struct
-    proc *p);

-
void
-  

-  signotify(struct
-    thread *td);

-
void
-  

-  trapsignal(struct
-    thread *td, int
-    sig, u_long
-  code);

-

-

-

-
The
-    ()
-    macro adds signo to set. No
-    effort is made to ensure that signo is a valid signal
-    number.

-
The
-    ()
-    macro removes signo from set. No
-    effort is made to ensure that signo is a valid signal
-    number.

-
The
-    ()
-    macro clears all signals in set.

-
The
-    ()
-    macro sets all signals in set.

-
The
-    ()
-    macro determines if signo is set in
-    set.

-
The
-    ()
-    macro determines if set does not have any signals
-  set.

-
The
-    ()
-    macro determines if set has any signals set.

-
The
-    ()
-    macro determines if two signal sets are equal; that is, the same signals are
-    set in both.

-
The
-    ()
-    macro determines if two signal sets differ; that is, if any signal set in
-    one is not set in the other.

-
The
-    ()
-    macro ORs the signals set in set2 into
-    set1.

-
The
-    ()
-    macro ANDs the signals set in set2 into
-    set1.

-
The
-    ()
-    macro NANDs the signals set in set2 into
-    set1.

-
The
-    ()
-    macro clears the SIGKILL and
-    SIGSTOP signals from set.
-    These two signals cannot be blocked or caught and
-    SIG_CANTMASK() is used in code where signals are
-    manipulated to ensure this policy is enforced.

-
The
-    ()
-    macro clears the SIGSTOP,
-    SIGTSTP, SIGTTIN, and
-    SIGTTOU signals from set.
-    SIG_STOPSIGMASK() is used to clear stop signals when
-    a process is waiting for a child to exit or exec, and when a process is
-    continuing after having been suspended.

-
The
-    ()
-    macro clears the SIGCONT signal from
-    set. SIG_CONTSIGMASK() is
-    called when a process is stopped.

-
The
-    ()
-    macro determines if the given process has any pending signals that are not
-    masked. If the process has a pending signal and the process is currently
-    being traced, SIGPENDING() will return true even if
-    the signal is masked.

-
The
-    ()
-    function returns the signal number that should be delivered to process
-    td->td_proc. If there are no signals pending, zero
-    is returned.

-
The
-    ()
-    function resets the signal set and signal stack of a process in preparation
-    for an execve(2). The process lock for
-    p must be held before
-    execsigs() is called.

-
The
-    ()
-    function determines if there are any pending signals for process
-    td->td_proc that should be caught, or cause this
-    process to terminate or interrupt its current system call. If process
-    td->td_proc is currently being traced, ignored
-    signals will be handled and the process is always stopped. Stop signals are
-    handled and cleared right away by issignal() unless
-    the process is a member of an orphaned process group and the stop signal
-    originated from a TTY. The process spin lock for
-    td->td_proc may be acquired and released. The
-    sigacts structure
-    td->td_proc->p_sigacts must be locked before
-    calling issignal() and may be released and
-    reacquired during the call. The process lock for
-    td->td_proc must be acquired before calling
-    issignal() and may be released and reacquired during
-    the call. Default signal actions are not taken for system processes and
-    init.

-
The
-    ()
-    function delivers SIGKILL to
-    p. why is logged as the reason
-     the
-    process was killed.

-
The
-    ()
-    function sends the signal sig to the process or
-    process group sigiop->sio_pgid. If
-    checkctty is non-zero, the signal is only delivered to
-    processes in the process group that have a controlling terminal. If
-    sigiop->sio_pgid is for a process (> 0), the
-    lock for sigiop->sio_proc is acquired and released.
-    If sigiop->sio_pgid is for a process group (<
-    0), the process group lock for sigiop->sio_pgrp is
-    acquired and released. The lock sigio_lock is acquired
-    and released.

-
The
-    ()
-    function handles the actual delivery of the signal
-    sig. postsig() is called from
-    ast() after the kernel has been notified that a
-    signal should be delivered (via a call to
-    signotify(), which causes the flag
-    PS_NEEDSIGCHK to be set). The process lock for
-    process that owns curthread must be held before
-    postsig() is called, and the current process cannot
-    be 0. The lock for the p_sigacts field of the current
-    process must be held before postsig() is called, and
-    may be released and reacquired.

-
The
-    ()
-    function causes the process that owns td to exit with
-    a return value of signal number sig. If required, the
-    process will dump core. The process lock for the process that owns
-    td must be held before
-    sigexit() is called.

-
The
-    ()
-    function is called during system initialization to cause every signal with a
-    default property of SA_IGNORE (except
-    SIGCONT) to be ignored by p.
-    The process lock for p is acquired and released, as is
-    the lock for sigacts structure p->p_sigacts. The
-    only process that siginit() is ever called for is
-    proc0.

-
The
-    ()
-    function flags that there are unmasked signals pending that
-    ()
-    should handle. The process lock for process
-    td->td_proc must be held before
-    signotify() is called, and the thread lock is
-    acquired and released.

-
The
-    ()
-    function sends a signal that is the result of a trap to process
-    td->td_proc. If the process is not being traced and
-    the signal can be delivered immediately,
-    trapsignal() will deliver it directly; otherwise,
-    trapsignal() will call psignal(9)
-    to cause the signal to be delivered. The process lock for
-    td->td_proc is acquired and released. The lock for
-    the p_sigacts field of
-    td->td_proc is acquired and released.

-

-

-

-
The SIGISMEMBER(),
-    SIGISEMPTY(), SIGNOTEMPTY(),
-    SIGSETEQ(), SIGSETNEQ(), and
-    SIGPENDING() macros all return non-zero (true) if
-    the condition they are checking is found to be true; otherwise, zero (false)
-    is returned.

-
The cursig() function returns either a
-    valid signal number or zero.

-
issignal() returns either a valid signal
-    number or zero.

-

-

-

-
pgsignal(9), psignal(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 14, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/sleep.9 4.html b/static/freebsd/man9/sleep.9 4.html
deleted file mode 100644
index e56521f9..00000000
--- a/static/freebsd/man9/sleep.9 4.html	
+++ /dev/null
@@ -1,307 +0,0 @@
-
-  
-    
-    
-    
-  
-
SLEEP(9)Kernel Developer's ManualSLEEP(9)

-

-

-

-
msleep,
-    msleep_sbt, msleep_spin,
-    msleep_spin_sbt, pause,
-    pause_sig, pause_sbt,
-    tsleep, tsleep_sbt,
-    wakeup, wakeup_one,
-    wakeup_any — wait for
-    events

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/proc.h>

-
int
-  

-  msleep(const
-    void *chan, struct mtx
-    *mtx, int priority,
-    const char *wmesg,
-    int timo);

-
int
-  

-  msleep_sbt(const
-    void *chan, struct mtx
-    *mtx, int priority,
-    const char *wmesg,
-    sbintime_t sbt,
-    sbintime_t pr,
-    int flags);

-
int
-  

-  msleep_spin(const
-    void *chan, struct mtx
-    *mtx, const char
-    *wmesg, int
-  timo);

-
int
-  

-  msleep_spin_sbt(const
-    void *chan, struct mtx
-    *mtx, const char
-    *wmesg, sbintime_t
-    sbt, sbintime_t pr,
-    int flags);

-
int
-  

-  pause(const
-    char *wmesg, int
-    timo);

-
int
-  

-  pause_sig(const
-    char *wmesg, int
-    timo);

-
int
-  

-  pause_sbt(const
-    char *wmesg, sbintime_t
-    sbt, sbintime_t pr,
-    int flags);

-
int
-  

-  tsleep(const
-    void *chan, int
-    priority, const char
-    *wmesg, int
-  timo);

-
int
-  

-  tsleep_sbt(const
-    void *chan, int
-    priority, const char
-    *wmesg, sbintime_t
-    sbt, sbintime_t pr,
-    int flags);

-
void
-  

-  wakeup(const
-    void *chan);

-
void
-  

-  wakeup_one(const
-    void *chan);

-
void
-  

-  wakeup_any(const
-    void *chan);

-

-

-

-
The functions
-    (),
-    msleep(), msleep_spin(),
-    pause(),
-    (),
-    pause_sbt(), wakeup(),
-    wakeup_one(), and
-    wakeup_any() handle event-based thread blocking. If
-    a thread must wait for an external event, it is put to sleep by
-    tsleep(), msleep(),
-    msleep_spin(), pause(),
-    pause_sig(), or pause_sbt().
-    Threads may also wait using one of the locking primitive sleep routines
-    mtx_sleep(9), rw_sleep(9), or
-    sx_sleep(9).

-
The parameter chan is an
-    arbitrary address that uniquely identifies the event on which the thread is
-    being put to sleep. All threads sleeping on a single
-    chan are woken up later by
-    (),
-    often called from inside an interrupt routine, to indicate that the resource
-    the thread was blocking on is available now.

-
The parameter priority specifies a new
-    priority for the thread as well as some optional flags. If the new priority
-    is not 0, then the thread will be made runnable with the specified
-    priority when it resumes.
-    PZERO should never be used, as it is for
-    compatibility only. A new priority of 0 means to use the thread's current
-    priority when it is made runnable again.

-
If priority includes the
-    PCATCH flag, pending signals are allowed to
-    interrupt the sleep, otherwise pending signals are ignored during the sleep.
-    If PCATCH is set and a signal becomes pending,
-    ERESTART is returned if the current system call
-    should be restarted if possible, and EINTR is
-    returned if the system call should be interrupted by the signal (return
-    EINTR).

-
The parameter wmesg is a string describing
-    the sleep condition for tools like ps(1). Due to the
-    limited space of those programs to display arbitrary strings, this message
-    should not be longer than 6 characters.

-
The parameter timo specifies a timeout for
-    the sleep. If timo is not 0, then the thread will
-    sleep for at most timo /
-    hz seconds. If the timeout expires, then the sleep
-    function will return EWOULDBLOCK.

-
(),
-    (),
-    ()
-    and
-    ()
-    functions take sbt parameter instead of
-    timo. It allows the caller to specify relative or
-    absolute wakeup time with higher resolution in form of
-    sbintime_t. The parameter pr
-    allows the caller to specify wanted absolute event precision. The parameter
-    flags allows the caller to pass additional
-    ()
-    flags.

-
Several of the sleep functions including
-    (),
-    msleep_spin(), and the locking primitive sleep
-    routines specify an additional lock parameter. The lock will be released
-    before sleeping and reacquired before the sleep routine returns. If
-    priority includes the PDROP
-    flag, then the lock will not be reacquired before returning. The lock is
-    used to ensure that a condition can be checked atomically, and that the
-    current thread can be suspended without missing a change to the condition,
-    or an associated wakeup. In addition, all of the sleep routines will fully
-    drop the Giant mutex (even if recursed) while the
-    thread is suspended and will reacquire the Giant mutex
-    before the function returns. Note that the Giant mutex
-    may be specified as the lock to drop. In that case, however, the
-    PDROP flag is not allowed.

-
To avoid lost wakeups, either a lock should be used
-    to protect against races, or a timeout should be specified to place an upper
-    bound on the delay due to a lost wakeup. As a result, the
-    ()
-    function should only be invoked with a timeout of 0 when the
-    Giant mutex is held.

-
The
-    ()
-    function requires that mtx reference a default, i.e.
-    non-spin, mutex. Its use is deprecated in favor of
-    mtx_sleep(9) which provides identical behavior.

-
The
-    ()
-    function requires that mtx reference a spin mutex. The
-    msleep_spin() function does not accept a
-    priority parameter and thus does not support changing
-    the current thread's priority, the PDROP flag, or
-    catching signals via the PCATCH flag.

-
The
-    ()
-    function is a wrapper around tsleep() that suspends
-    execution of the current thread for the indicated timeout. The thread can
-    not be awakened early by signals or calls to
-    wakeup(), wakeup_one() or
-    wakeup_any(). The
-    pause_sig() function is a variant of
-    pause() which can be awakened early by signals.

-
The
-    ()
-    function makes the first highest priority thread in the queue that is
-    sleeping on the parameter chan runnable. This reduces
-    the load when a large number of threads are sleeping on the same address,
-    but only one of them can actually do any useful work when made runnable.

-
Due to the way it works, the
-    ()
-    function requires that only related threads sleep on a specific
-    chan address. It is the programmer's responsibility to
-    choose a unique chan value. The older
-    wakeup() function did not require this, though it
-    was never good practice for threads to share a chan
-    value. When converting from wakeup() to
-    wakeup_one(), pay particular attention to ensure
-    that no other threads wait on the same chan.

-
The
-    ()
-    function is similar to wakeup_one(), except that it
-    makes runnable last thread on the queue (sleeping less), ignoring fairness.
-    It can be used when threads sleeping on the chan are
-    known to be identical and there is no reason to be fair.

-
If the timeout given by timo or
-    sbt is based on an absolute real-time clock value,
-    then the thread should copy the global rtc_generation
-    into its td_rtcgen member before reading the RTC. If
-    the real-time clock is adjusted, these functions will set
-    td_rtcgen to zero and return zero. The caller should
-    reconsider its orientation with the new RTC value.

-

-

-

-
When awakened by a call to wakeup() or
-    wakeup_one(), if a signal is pending and
-    PCATCH is specified, a non-zero error code is
-    returned. If the thread is awakened by a call to
-    wakeup() or wakeup_one(),
-    the msleep(), msleep_spin(),
-    tsleep(), and locking primitive sleep functions
-    return 0. Zero can also be returned when the real-time clock is adjusted;
-    see above regarding td_rtcgen. Otherwise, a non-zero
-    error code is returned.

-

-

-

-
msleep(),
-    msleep_spin(), tsleep(), and
-    the locking primitive sleep functions will fail if:

-

-  
[]

-  
The PCATCH flag was specified, a signal was
-      caught, and the system call should be interrupted.

-  
[]

-  
The PCATCH flag was specified, a signal was
-      caught, and the system call should be restarted.

-  
[]

-  
A non-zero timeout was specified and the timeout expired.

-

-

-

-

-
ps(1), callout(9),
-    locking(9), malloc(9),
-    mi_switch(9), mtx_sleep(9),
-    rw_sleep(9), sx_sleep(9)

-

-

-

-
The functions sleep() and
-    wakeup() were present in
-    Version 1 AT&T UNIX. They were probably
-    also present in the preceding PDP-7 version of UNIX.
-    They were the basic process synchronization model.

-
The tsleep() function appeared in
-    4.4BSD and added the parameters
-    wmesg and timo. The
-    sleep() function was removed in
-    FreeBSD 2.2. The
-    wakeup_one() function appeared in
-    FreeBSD 2.2. The msleep()
-    function appeared in FreeBSD 5.0, and the
-    msleep_spin() function appeared in
-    FreeBSD 6.2. The pause()
-    function appeared in FreeBSD 7.0. The
-    pause_sig() function appeared in
-    FreeBSD 12.0.

-

-

-

-
This manual page was written by Jörg
-    Wunsch
-    <joerg@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 19, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/sleepqueue.9 4.html b/static/freebsd/man9/sleepqueue.9 4.html
deleted file mode 100644
index bb93c74b..00000000
--- a/static/freebsd/man9/sleepqueue.9 4.html	
+++ /dev/null
@@ -1,326 +0,0 @@
-
-  
-    
-    
-    
-  
-
SLEEPQUEUE(9)Kernel Developer's ManualSLEEPQUEUE(9)

-

-

-

-
init_sleepqueues,
-    sleepq_abort, sleepq_add,
-    sleepq_alloc,
-    sleepq_broadcast,
-    sleepq_free, sleepq_lock,
-    sleepq_lookup,
-    sleepq_release,
-    sleepq_remove,
-    sleepq_signal,
-    sleepq_set_timeout,
-    sleepq_set_timeout_sbt,
-    sleepq_sleepcnt,
-    sleepq_timedwait,
-    sleepq_timedwait_sig,
-    sleepq_type, sleepq_wait,
-    sleepq_wait_sig — manage the
-    queues of sleeping threads

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include
-  <sys/sleepqueue.h>

-
void
-  

-  init_sleepqueues(void);

-
int
-  

-  sleepq_abort(struct
-    thread *td);

-
void
-  

-  sleepq_add(const
-    void *wchan, struct
-    lock_object *lock, const
-    char *wmesg, int
-    flags, int
-  queue);

-
struct sleepqueue *
-  

-  sleepq_alloc(void);

-
int
-  

-  sleepq_broadcast(const
-    void *wchan, int
-    flags, int pri,
-    int queue);

-
void
-  

-  sleepq_free(struct
-    sleepqueue *sq);

-
struct sleepqueue *
-  

-  sleepq_lookup(const
-    void *wchan);

-
void
-  

-  sleepq_lock(const
-    void *wchan);

-
void
-  

-  sleepq_release(const
-    void *wchan);

-
void
-  

-  sleepq_remove(struct
-    thread *td, const void
-    *wchan);

-
int
-  

-  sleepq_signal(const
-    void *wchan, int
-    flags, int pri,
-    int queue);

-
void
-  

-  sleepq_set_timeout(const
-    void *wchan, int
-    timo);

-
void
-  

-  sleepq_set_timeout_sbt(const
-    void *wchan, sbintime_t
-    sbt, sbintime_t pr,
-    int flags);

-
u_int
-  

-  sleepq_sleepcnt(const
-    void *wchan, int
-    queue);

-
int
-  

-  sleepq_timedwait(const
-    void *wchan, int
-    pri);

-
int
-  

-  sleepq_timedwait_sig(const
-    void *wchan, int
-    pri);

-
int
-  

-  sleepq_type(const
-    void *wchan);

-
void
-  

-  sleepq_wait(const
-    void *wchan, int
-    pri);

-
int
-  

-  sleepq_wait_sig(const
-    void *wchan, int
-    pri);

-

-

-

-
Sleep queues provide a mechanism for suspending execution of a
-    thread until some condition is met. Each queue is associated with a specific
-    wait channel when it is active, and only one queue may be associated with a
-    wait channel at any given point in time. The implementation of each wait
-    channel splits its sleepqueue into 2 sub-queues in order to enable some
-    optimizations on threads' wakeups. An active queue holds a list of threads
-    that are blocked on the associated wait channel. Threads that are not
-    blocked on a wait channel have an associated inactive sleep queue. When a
-    thread blocks on a wait channel it donates its inactive sleep queue to the
-    wait channel. When a thread is resumed, the wait channel that it was blocked
-    on gives it an inactive sleep queue for later use.

-
The
-    ()
-    function allocates an inactive sleep queue and is used to assign a sleep
-    queue to a thread during thread creation. The
-    ()
-    function frees the resources associated with an inactive sleep queue and is
-    used to free a queue during thread destruction.

-
Active sleep queues are stored in a hash
-    table hashed on the addresses pointed to by wait channels. Each bucket in
-    the hash table contains a sleep queue chain. A sleep queue chain contains a
-    spin mutex and a list of sleep queues that hash to that specific chain.
-    Active sleep queues are protected by their chain's spin mutex. The
-    ()
-    function initializes the hash table of sleep queue chains.

-
The
-    ()
-    function locks the sleep queue chain associated with wait channel
-    wchan.

-
The
-    ()
-    returns a pointer to the currently active sleep queue for that wait channel
-    associated with wchan or NULL
-    if there is no active sleep queue associated with argument
-    wchan. It requires the sleep queue chain associated
-    with wchan to have been locked by a prior call to
-    sleepq_lock().

-
The
-    ()
-    function unlocks the sleep queue chain associated with
-    ()
-    and is primarily useful when aborting a pending sleep request before one of
-    the wait functions is called.

-
The
-    ()
-    function places the current thread on the sleep queue associated with the
-    wait channel wchan. The sleep queue chain associated
-    with argument wchan must be locked by a prior call to
-    sleepq_lock() when this function is called. If a
-    lock is specified via the lock argument, and if the
-    kernel was compiled with options INVARIANTS, then
-    the sleep queue code will perform extra checks to ensure that the lock is
-    used by all threads sleeping on wchan. The
-    wmesg parameter should be a short description of
-    wchan. The flags parameter is a
-    bitmask consisting of the type of sleep queue being slept on and zero or
-    more optional flags. The queue parameter specifies the
-    sub-queue, in which the contending thread will be inserted.

-
There are currently three types of sleep queues:

-

-

-  

-  
A sleep queue used to implement condition variables.

-  

-  
A sleep queue used to implement sleep(9),
-      wakeup(9) and wakeup_one(9).

-  

-  
A sleep queue used to implement pause(9).

-

-
There are currently two optional flag:

-

-

-  

-  
The current thread is entering an interruptible sleep.

-

-

-  

-  
When thread is entering an interruptible sleep, do not stop it upon
-      arrival of stop action, like SIGSTOP. Wake it up
-      instead.

-

-
A timeout on the sleep may be specified by
-    calling
-    ()
-    after sleepq_add(). The wchan
-    parameter should be the same value from the preceding call to
-    sleepq_add(), and the sleep queue chain associated
-    with wchan must have been locked by a prior call to
-    sleepq_lock(). The timo
-    parameter should specify the timeout value in ticks.

-
()
-    function takes sbt argument instead of
-    timo. It allows to specify relative or absolute wakeup
-    time with higher resolution in form of sbintime_t. The
-    parameter pr allows to specify wanted absolute event
-    precision. The parameter flags allows to pass
-    additional
-    ()
-    flags.

-
Once the thread is ready to suspend, one of the
-    wait functions is called to put the current thread to sleep until it is
-    awakened and to context switch to another thread. The
-    ()
-    function is used for non-interruptible sleeps that do not have a timeout.
-    The
-    ()
-    function is used for non-interruptible sleeps that have had a timeout set
-    via sleepq_set_timeout(). The
-    ()
-    function is used for interruptible sleeps that do not have a timeout. The
-    ()
-    function is used for interruptible sleeps that do have a timeout set. The
-    wchan argument to all of the wait functions is the
-    wait channel being slept on. The sleep queue chain associated with argument
-    wchan needs to have been locked with a prior call to
-    sleepq_lock(). The pri
-    argument is used to set the priority of the thread when it is awakened. If
-    it is set to zero, the thread's priority is left alone.

-
When the thread is resumed, the wait functions return a non-zero
-    value if the thread was awakened due to an interrupt other than a signal or
-    a timeout. If the sleep timed out, then EWOULDBLOCK
-    is returned. If the sleep was interrupted by something other than a signal,
-    then some other return value will be returned.

-
A sleeping thread is normally resumed by the
-    ()
-    and
-    ()
-    functions. The sleepq_signal() function awakens the
-    highest priority thread sleeping on a wait channel (if SLEEPQ_UNFAIR flag is
-    set, thread that went to sleep recently) while
-    sleepq_broadcast() awakens all of the threads
-    sleeping on a wait channel. The wchan argument
-    specifics which wait channel to awaken. The flags
-    argument must match the sleep queue type contained in the
-    flags argument passed to
-    sleepq_add() by the threads sleeping on the wait
-    channel. If the pri argument does not equal -1, then
-    each thread that is awakened will have its priority raised to
-    pri if it has a lower priority. The sleep queue chain
-    associated with argument wchan must be locked by a
-    prior call to sleepq_lock() before calling any of
-    these functions. The queue argument specifies the
-    sub-queue, from which threads need to be woken up.

-
A thread in an interruptible sleep can be
-    interrupted by another thread via the
-    ()
-    function. The td argument specifies the thread to
-    interrupt. An individual thread can also be awakened from sleeping on a
-    specific wait channel via the
-    ()
-    function. The td argument specifies the thread to
-    awaken and the wchan argument specifies the wait
-    channel to awaken it from. If the thread td is not
-    blocked on the wait channel wchan then this function
-    will not do anything, even if the thread is asleep on a different wait
-    channel. This function should only be used if one of the other functions
-    above is not sufficient. One possible use is waking up a specific thread
-    from a widely shared sleep channel.

-
The
-    ()
-    function offer a simple way to retrieve the number of threads sleeping for
-    the specified queue, given a
-    wchan.

-
The
-    ()
-    function returns the type of wchan associated to a
-    sleepqueue.

-
The
-    (),
-    sleepq_broadcast(), and
-    sleepq_signal() functions all return a boolean
-    value. If the return value is true, then at least one thread was resumed
-    that is currently swapped out. The caller is responsible for awakening the
-    scheduler process so that the resumed thread will be swapped back in. This
-    is done by calling the
-    ()
-    function after releasing the sleep queue chain lock via a call to
-    sleepq_release().

-
The sleep queue interface is currently used to implement the
-    sleep(9) and condvar(9) interfaces.
-    Almost all other code in the kernel should use one of those interfaces
-    rather than manipulating sleep queues directly.

-

-

-

-
callout(9), condvar(9),
-    runqueue(9), scheduler(9),
-    sleep(9)

-

-

-
-  
-    
-    
-  
-
June 19, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/smr.9 3.html b/static/freebsd/man9/smr.9 3.html
deleted file mode 100644
index 662b447e..00000000
--- a/static/freebsd/man9/smr.9 3.html	
+++ /dev/null
@@ -1,234 +0,0 @@
-
-  
-    
-    
-    
-  
-
SMR(9)Kernel Developer's ManualSMR(9)

-

-

-

-
smr — safe memory
-    reclamation for lock-free data structures

-

-

-

-
#include
-    <sys/smr.h>

-
smr_seq_t
-  

-  smr_advance(smr_t smr);

-
smr_t
-  

-  smr_create(const char
-  *name);

-
void
-  

-  smr_destroy(smr_t smr);

-
void
-  

-  smr_enter(smr_t smr);

-
void
-  

-  smr_exit(smr_t smr);

-
bool
-  

-  smr_poll(smr_t smr,
-    smr_seq_t goal, bool wait);

-
void
-  

-  smr_synchronize(smr_t smr);

-
void
-  

-  smr_wait(smr_t smr,
-    smr_seq_t goal);

-

-

-

-
Safe Memory Reclamation (SMR) is a facility which enables the
-    implementation of memory-safe lock-free data structures. In typical usage,
-    read accesses to an SMR-protected data structure, such as a hash table or
-    tree, are performed in a “read section” consisting of code
-    bracketed by
-    ()
-    and
-    ()
-    calls, while mutations of the data structure are serialized by a traditional
-    mutex such as mutex(9). In contrast with reader-writer
-    locks such as rwlock(9), rmlock(9), and
-    sx(9), SMR allows readers and writers to access the data
-    structure concurrently. Readers can always enter a read section immediately
-    (smr_enter() never blocks), so mutations do not
-    introduce read latency. Furthermore, smr_enter() and
-    smr_exit() operate only on per-CPU data and thus
-    avoid some of the performance problems inherent in the implementation of
-    traditional reader-writer mutexes. SMR can therefore be a useful building
-    block for data structures which are accessed frequently but are only rarely
-    modified.

-
Note that any SMR-protected data structure must be implemented
-    carefully such that operations behave correctly in the absence of mutual
-    exclusion between readers and writers. The data structure must be designed
-    to be lock-free; SMR merely facilitates the implementation, for example by
-    making it safe to follow dangling pointers and by helping avoid the ABA
-    problem.

-
When shared accesses to and mutations of a data
-    structure can proceed concurrently, writers must take care to ensure that
-    any items removed from the structure are not freed and recycled while
-    readers are accessing them in parallel. This requirement results in a
-    two-phase approach to the removal of items: first, the item is unlinked such
-    that all pointers to the item are removed from the structure, preventing any
-    new readers from observing the item. Then, the writer waits until some
-    mechanism guarantees that no existing readers are still accessing the item.
-    At that point the memory for that item can be freed and reused safely. SMR
-    provides this mechanism: readers may access a lock-free data structure in
-    between calls to the
-    ()
-    and
-    ()
-    functions, which together create a read section, and the
-    smr_advance(), smr_poll(),
-    smr_wait(), and
-    smr_synchronize() functions can be used to wait for
-    threads in read sections to finish. All of these functions operate on a
-    smr_t state block which holds both per-CPU and global
-    state. Readers load global state and modify per-CPU state, while writers
-    must scan all per-CPU states to detect active readers. SMR is designed to
-    amortize this cost by batching to give acceptable performance in write-heavy
-    workloads.

-

-

-
Threads enter a read section by calling
-    smr_enter(). Read sections should be short, and many
-    operations are not permitted while in a read section. Specifically, context
-    switching is disabled, and thus readers may not acquire blocking mutexes
-    such as mutex(9). Another consequence of this is that the
-    thread is pinned to the current CPU for the duration of the read section.
-    Furthermore, read sections may not be nested: it is incorrect to call
-    smr_enter() with a given smr_t
-    state block when already in a read section for that state block.

-

-

-

-
To simplify the integration of SMR into consumers, the
-    uma(9) kernel memory allocator provides some SMR-specified
-    facilities. This eliminates a good deal of complexity from the
-    implementation of consumers and automatically batches write operations.

-
In typical usage, a UMA zone (created with
-    the UMA_ZONE_SMR flag or initialized with the
-    ()
-    function) is coupled with a smr_t state block. To
-    insert an item into an SMR-protected data structure, memory is allocated
-    from the zone using the
-    ()
-    function. Insertions and removals are serialized using traditional mutual
-    exclusion and items are freed using the
-    ()
-    function. Read-only lookup operations are performed in SMR read sections.
-    uma_zfree_smr() waits for all active readers which
-    may be accessing the freed item to finish their read sections before
-    recycling that item's memory.

-
If the zone has an associated per-item destructor, it will be
-    invoked at some point when no readers can be accessing a given item. The
-    destructor can be used to release additional resources associated with the
-    item. Note however that there is no guarantee that the destructor will be
-    invoked in a bounded time period.

-

-

-

-
Consumers are expected to use SMR in conjunction with UMA and thus
-    need only make use of the
-    ()
-    and
-    ()
-    functions, and the SMR helper macros defined in
-    sys/smr_types.h. However, an introduction to the
-    write-side interface of SMR can be useful.

-
Internally, SMR maintains a global
-    ‘write sequence’ number. When entering
-    a read section,
-    ()
-    loads a copy of the write sequence and stores it in per-CPU memory, hence
-    ‘observing’ that value. To exit a read
-    section, this per-CPU memory is overwritten with an invalid value, making
-    the CPU inactive. Writers perform two operations: advancing the write
-    sequence number, and polling all CPUs to see whether active readers have
-    observed a given sequence number. These operations are performed by
-    smr_advance() and
-    smr_poll(), respectively, which do not require
-    serialization between multiple writers.

-
After a writer unlinks an item from a data
-    structure, it increments the write sequence number and tags the item with
-    the new value returned by
-    ().
-    Once all CPUs have observed the new value, the writer can use
-    smr_poll() to deduce that no active readers have
-    access to the unlinked item, and thus the item is safe to recycle. Because
-    this pair of operations is relatively expensive, it is generally a good idea
-    to amortize this cost by accumulating a collection of multiple unlinked
-    items and tagging the entire batch with a target write sequence number.

-
()
-    is a non-blocking operation and returns true only if all active readers are
-    guaranteed to have observed the target sequence number value.
-    ()
-    is a variant of smr_poll() which waits until all
-    CPUs have observed the target sequence number value.
-    ()
-    combines smr_advance() with
-    smr_wait() to wait for all CPUs to observe a new
-    write sequence number. This is an expensive operation and should only be
-    used if polling cannot be deferred in some way.

-

-

-

-
The smr_enter() function has acquire
-    semantics, and the smr_exit() function has release
-    semantics. The smr_advance(),
-    smr_poll(), smr_wait(), and
-    smr_synchronize() functions should not be assumed to
-    have any guarantees with respect to memory ordering. In practice, some of
-    these functions have stronger ordering semantics than is stated here, but
-    this is specific to the implementation and should not be relied upon. See
-    atomic(9) for more details.

-

-

-

-

-
Outside of FreeBSD the acronym SMR
-    typically refers to a family of algorithms which enable memory-safe
-    read-only access to a data structure concurrent with modifications to that
-    data structure. Here, SMR refers to a particular algorithm belonging to this
-    family, as well as its implementation in FreeBSD.
-    See sys/sys/smr.h and
-    sys/kern/subr_smr.c in the
-    FreeBSD source tree for further details on the
-    algorithm and the context.

-
The acronym SMR is also used to mean "shingled magnetic
-    recording", a technology used to store data on hard disk drives which
-    requires operating system support. These two uses of the acronym are
-    unrelated.

-

-

-

-
atomic(9), locking(9),
-    uma(9)

-

-

-

-
The SMR algorithm and its implementation were provided by
-    Jeff Roberson
-    <jeff@FreeBSD.org>.
-    This manual page was written by
-  

-  Mark Johnston
-    <markj@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 17, 2023FreeBSD 15.0

diff --git a/static/freebsd/man9/socket.9 4.html b/static/freebsd/man9/socket.9 4.html
deleted file mode 100644
index 525c16d0..00000000
--- a/static/freebsd/man9/socket.9 4.html	
+++ /dev/null
@@ -1,563 +0,0 @@
-
-  
-    
-    
-    
-  
-
SOCKET(9)Kernel Developer's ManualSOCKET(9)

-

-

-

-
socket — kernel
-    socket interface

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <sys/socketvar.h>

-
void
-  

-  soabort(struct
-    socket *so);

-
int
-  

-  soaccept(struct
-    socket *so, struct
-    sockaddr *nam);

-
int
-  

-  socheckuid(struct
-    socket *so, uid_t
-    uid);

-
int
-  

-  sobind(struct
-    socket *so, struct
-    sockaddr *nam, struct
-    thread *td);

-
void
-  

-  soclose(struct
-    socket *so);

-
int
-  

-  soconnect(struct
-    socket *so, struct
-    sockaddr *nam, struct
-    thread *td);

-
int
-  

-  socreate(int dom,
-    struct socket **aso, int type,
-    int proto, struct ucred *cred,
-    struct thread *td);

-
int
-  

-  sodisconnect(struct
-    socket *so);

-
void
-  

-  sodtor_set(struct socket *so,
-    void (*func)(struct socket *));

-
struct sockaddr *
-  

-  sodupsockaddr(const
-    struct sockaddr *sa, int
-    mflags);

-
void
-  

-  sofree(struct
-    socket *so);

-
void
-  

-  sohasoutofband(struct
-    socket *so);

-
int
-  

-  solisten(struct
-    socket *so, int
-    backlog, struct thread
-    *td);

-
void
-  

-  solisten_proto(struct
-    socket *so, int
-    backlog);

-
int
-  

-  solisten_proto_check(struct
-    socket *so);

-
struct socket *
-  

-  sonewconn(struct
-    socket *head, int
-    connstatus);

-
int
-  

-  sopoll(struct socket *so,
-    int events, struct ucred
-    *active_cred, struct thread *td);

-
int
-  

-  sopoll_generic(struct socket
-    *so, int events, struct ucred
-    *active_cred, struct thread *td);

-
int
-  

-  soreceive(struct socket *so,
-    struct sockaddr **psa, struct uio
-    *uio, struct mbuf **mp0, struct
-    mbuf **controlp, int *flagsp);

-
int
-  

-  soreceive_stream(struct socket
-    *so, struct sockaddr **paddr,
-    struct uio *uio, struct mbuf
-    **mp0, struct mbuf **controlp,
-    int *flagsp);

-
int
-  

-  soreceive_dgram(struct socket
-    *so, struct sockaddr **paddr,
-    struct uio *uio, struct mbuf
-    **mp0, struct mbuf **controlp,
-    int *flagsp);

-
int
-  

-  soreceive_generic(struct socket
-    *so, struct sockaddr **paddr,
-    struct uio *uio, struct mbuf
-    **mp0, struct mbuf **controlp,
-    int *flagsp);

-
int
-  

-  soreserve(struct
-    socket *so, u_long
-    sndcc, u_long
-    rcvcc);

-
void
-  

-  sorflush(struct
-    socket *so);

-
int
-  

-  sosend(struct socket *so,
-    struct sockaddr *addr, struct uio
-    *uio, struct mbuf *top, struct
-    mbuf *control, int flags, struct
-    thread *td);

-
int
-  

-  sosend_dgram(struct socket *so,
-    struct sockaddr *addr, struct uio
-    *uio, struct mbuf *top, struct
-    mbuf *control, int flags, struct
-    thread *td);

-
int
-  

-  sosend_generic(struct socket
-    *so, struct sockaddr *addr,
-    struct uio *uio, struct mbuf
-    *top, struct mbuf *control, int
-    flags, struct thread *td);

-
int
-  

-  soshutdown(struct
-    socket *so, int
-    how);

-
void
-  

-  sotoxsocket(struct
-    socket *so, struct
-    xsocket *xso);

-
void
-  

-  soupcall_clear(struct
-    socket *so, int
-    which);

-
void
-  

-  soupcall_set(struct socket *so,
-    int which, int (*func)(struct socket
-    *, void *, int), void *arg);

-
void
-  

-  sowakeup(struct
-    socket *so, struct
-    sockbuf *sb);

-
#include
-    <sys/sockopt.h>

-
int
-  

-  sosetopt(struct
-    socket *so, struct
-    sockopt *sopt);

-
int
-  

-  sogetopt(struct
-    socket *so, struct
-    sockopt *sopt);

-
int
-  

-  sooptcopyin(struct
-    sockopt *sopt, void
-    *buf, size_t len,
-    size_t minlen);

-
int
-  

-  sooptcopyout(struct
-    sockopt *sopt, const void
-    *buf, size_t
-  len);

-

-

-

-
The kernel socket programming interface
-    permits in-kernel consumers to interact with local and network socket
-    objects in a manner similar to that permitted using the
-    socket(2) user API. These interfaces are appropriate for
-    use by distributed file systems and other network-aware kernel services.
-    While the user API operates on file descriptors, the kernel interfaces
-    operate directly on struct socket pointers. Some
-    portions of the kernel API exist only to implement the user API, and are not
-    expected to be used by kernel code. The portions of the socket API used by
-    socket consumers and implementations of network protocols will differ; some
-    routines are only useful for protocol implementors.

-
Except where otherwise indicated, socket
-    functions may sleep, and are not appropriate for use in an interrupt thread
-    context or while holding non-sleepable kernel locks.

-

-

-
A new socket may be created using
-    ().
-    As with socket(2), arguments specify the requested domain,
-    type, and protocol via dom,
-    type, and proto. The socket is
-    returned via aso on success. In addition, the
-    credential used to authorize operations associated with the socket will be
-    passed via cred (and will be cached for the lifetime
-    of the socket), and the thread performing the operation via
-    td.
-    :
-    authorization of the socket creation operation will be performed using the
-    thread credential for some protocols (such as raw sockets).

-
Sockets may be closed and freed using
-    (),
-    which has similar semantics to close(2).

-
In certain circumstances, it is appropriate to
-    destroy a socket without waiting for it to disconnect, for which
-    ()
-    is used. This is only appropriate for incoming connections which are in a
-    partially connected state. It must be called on an unreferenced socket, by
-    the thread which removed the socket from its listen queue, to prevent races.
-    It will call into protocol code, so no socket locks may be held over the
-    call. The caller of soabort() is responsible for
-    setting the VNET context. The normal path to freeing a socket is
-    (),
-    which handles reference counting on the socket. It should be called whenever
-    a reference is released, and also whenever reference flags are cleared in
-    socket or protocol code. Calls to sofree() should
-    not be made from outside the socket layer; outside callers should use
-    soclose() instead.

-

-

-

-
The
-    ()
-    function is equivalent to the bind(2) system call, and
-    binds the socket so to the address
-    nam. The operation would be authorized using the
-    credential on thread td.

-
The
-    ()
-    function is equivalent to the connect(2) system call, and
-    initiates a connection on the socket so to the address
-    nam. The operation will be authorized using the
-    credential on thread td. Unlike the user system call,
-    soconnect() returns immediately; the caller may
-    msleep(9) on so->so_timeo while
-    holding the socket mutex and waiting for the
-    SS_ISCONNECTING flag to clear or
-    so->so_error to become non-zero. If
-    soconnect() fails, the caller must manually clear
-    the SS_ISCONNECTING flag.

-
A call to
-    ()
-    disconnects the socket without closing it.

-
The
-    ()
-    function is equivalent to the shutdown(2) system call, and
-    causes part or all of a connection on a socket to be closed down.

-
Sockets are transitioned from non-listening status
-    to listening with
-    ().

-

-

-

-
The sogetopt() function is equivalent to
-    the getsockopt(2) system call, and retrieves a socket
-    option on socket so. The
-    sosetopt() function is equivalent to the
-    setsockopt(2) system call, and sets a socket option on
-    socket so.

-
The second argument in both
-    ()
-    and
-    ()
-    is the sopt pointer to a struct
-    sopt describing the socket option operation. The caller-allocated
-    structure must be zeroed, and then have its fields initialized to specify
-    socket option operation arguments:

-

-  
sopt_dir

-  
Set to SOPT_SET or
-      SOPT_GET depending on whether this is a get or set
-      operation.

-  
sopt_level

-  
Specify the level in the network stack the operation is targeted at; for
-      example, SOL_SOCKET.

-  
sopt_name

-  
Specify the name of the socket option to set.

-  
sopt_val

-  
Kernel space pointer to the argument value for the socket option.

-  
sopt_valsize

-  
Size of the argument value in bytes.

-

-

-

-

-
In order for the owner of a socket to be notified when the socket
-    is ready to send or receive data, an upcall may be registered on the socket.
-    The upcall is a function that will be called by the socket framework when a
-    socket buffer associated with the given socket is ready for reading or
-    writing.
-    ()
-    is used to register a socket upcall. The function func
-    is registered, and the pointer arg will be passed as
-    its second argument when it is called by the framework. The possible values
-    for which are SO_RCV and
-    SO_SND, which register upcalls for receive and send
-    events, respectively. The upcall function
-    ()
-    must return either SU_OK or
-    SU_ISCONNECTED, depending on whether or not a call
-    to soisconnected should be made by the socket framework
-    after the upcall returns. The upcall func cannot call
-    soisconnected itself due to lock ordering with the socket
-    buffer lock. Only SO_RCV upcalls should return
-    SU_ISCONNECTED. When a
-    SO_RCV upcall returns
-    SU_ISCONNECTED, the upcall will be removed from the
-    socket.

-
Upcalls are removed from their socket by
-    ().
-    The which argument again specifies whether the sending
-    or receiving upcall is to be cleared, with SO_RCV or
-    SO_SND.

-

-

-

-
A kernel system can use the
-    ()
-    function to set a destructor for a socket. The destructor is called when the
-    socket is about to be freed. The destructor is called before the protocol
-    detach routine. The destructor can serve as a callback to initiate
-    additional cleanup actions.

-

-

-

-
The
-    ()
-    function is equivalent to the recvmsg(2) system call, and
-    attempts to receive bytes of data from the socket so,
-    optionally blocking awaiting for data if none is ready to read. Data may be
-    retrieved directly to kernel or user memory via the
-    uio argument, or as an mbuf chain returned to the
-    caller via mp0, avoiding a data copy. The
-    uio must always be non-NULL.
-    If mp0 is non-NULL, only the
-    uio_resid of uio is used. The
-    caller may optionally retrieve a socket address on a protocol with the
-    PR_ADDR capability by providing storage via
-    non-NULL psa argument. The
-    caller may optionally retrieve control data mbufs via a
-    non-NULL controlp argument.
-    Optional flags may be passed to soreceive() via a
-    non-NULL flagsp argument, and
-    use the same flag name space as the recvmsg(2) system
-    call.

-
The
-    ()
-    function is equivalent to the sendmsg(2) system call, and
-    attempts to send bytes of data via the socket so,
-    optionally blocking if data cannot be immediately sent. Data may be sent
-    directly from kernel or user memory via the uio
-    argument, or as an mbuf chain via top, avoiding a data
-    copy. Only one of the uio or top
-    pointers may be non-NULL. An optional destination
-    address may be specified via a non-NULL
-    addr argument, which may result in an implicit connect
-    if supported by the protocol. The caller may optionally send control data
-    mbufs via a non-NULL control
-    argument. Flags may be passed to sosend() using the
-    flags argument, and use the same flag name space as
-    the sendmsg(2) system call.

-
Kernel callers running in an interrupt thread context, or with a
-    mutex held, will wish to use non-blocking sockets and pass the
-    MSG_DONTWAIT flag in order to prevent these
-    functions from sleeping.

-
A socket can be queried for readability, writability,
-    out-of-band data, or end-of-file using
-    ().
-    The possible values for events are as for
-    poll(2), with symbolic values
-    POLLIN, POLLPRI,
-    POLLOUT, POLLRDNORM,
-    POLLWRNORM, POLLRDBAND, and
-    POLLINGEOF taken from
-    <sys/poll.h>.

-
Calls to
-    ()
-    pass through to the protocol's accept routine to accept an incoming
-    connection.

-

-

-

-
The uid of a socket's credential may be compared against a
-    uid with
-    ().

-
A copy of an existing struct
-    sockaddr may be made using
-    ().

-
Protocol implementations notify the socket
-    layer of the arrival of out-of-band data using
-    (),
-    so that the socket layer can notify socket consumers of the available
-  data.

-
An “external-format” version of a
-    struct socket can be created using
-    (),
-    suitable for isolating user code from changes in the kernel structure.

-

-

-

-
Protocols must supply an implementation for
-    solisten(); such protocol implementations can call
-    back into the socket layer using
-    ()
-    and
-    ()
-    to check and set the socket-layer listen state. These callbacks are provided
-    so that the protocol implementation can order the socket layer and protocol
-    locks as necessary. Protocols must supply an implementation of
-    soreceive(); the functions
-    (),
-    (),
-    and
-    ()
-    are supplied for use by such implementations.

-
Protocol implementations can use
-    ()
-    to create a socket and attach protocol state to that socket. This can be
-    used to create new sockets available for soaccept()
-    on a listen socket. The returned socket has a reference count of zero.

-
Protocols must supply an implementation for
-    ();
-    ()
-    is provided for the use by protocol implementations.

-
The functions
-    ()
-    and
-    ()
-    are supplied to assist in protocol implementations of
-    sosend().

-
When a protocol creates a new socket structure, it
-    is necessary to reserve socket buffer space for that socket, by calling
-    ().
-    The rough inverse of this reservation is performed by
-    (),
-    which is called automatically by the socket framework.

-
When a protocol needs to wake up threads waiting for
-    the socket to become ready to read or write, variants of
-    ()
-    are used. The sowakeup() function should not be
-    called directly by protocol code, instead use the wrappers
-    (),
-    (),
-    (),
-    and
-    ()
-    for readers and writers, with the corresponding socket buffer lock not
-    already locked, or already held, respectively.

-
The functions
-    ()
-    and
-    ()
-    are useful for transferring struct sockopt data
-    between user and kernel code.

-

-

-

-

-
bind(2), close(2),
-    connect(2), getsockopt(2),
-    recv(2), send(2),
-    setsockopt(2), shutdown(2),
-    socket(2), ng_ksocket(4),
-    intr_event(9), msleep(9),
-    ucred(9)

-

-

-

-
The socket(2) system call appeared in
-    4.2BSD. This manual page was introduced in
-    FreeBSD 7.0.

-

-

-

-
This manual page was written by Robert
-    Watson and
-  

-  Benjamin Kaduk.

-

-

-

-
The use of explicitly passed credentials, credentials hung from
-    explicitly passed threads, the credential on
-    curthread, and the cached credential from socket
-    creation time is inconsistent, and may lead to unexpected behaviour. It is
-    possible that several of the td arguments should be
-    cred arguments, or simply not be present at all.

-
The caller may need to manually clear
-    SS_ISCONNECTING if
-    soconnect() returns an error.

-
The MSG_DONTWAIT flag is not implemented
-    for sosend(), and may not always work with
-    soreceive() when zero copy sockets are enabled.

-
This manual page does not describe how to register socket upcalls
-    or monitor a socket for readability/writability without using blocking
-  I/O.

-
The soref() and
-    sorele() functions are not described, and in most
-    cases should not be used, due to confusing and potentially incorrect
-    interactions when sorele() is last called after
-    soclose().

-

-

-
-  
-    
-    
-  
-
September 6, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/stack.9 4.html b/static/freebsd/man9/stack.9 4.html
deleted file mode 100644
index d54d5f4a..00000000
--- a/static/freebsd/man9/stack.9 4.html	
+++ /dev/null
@@ -1,174 +0,0 @@
-
-  
-    
-    
-    
-  
-
STACK(9)Kernel Developer's ManualSTACK(9)

-

-

-

-
stack — kernel
-    thread stack tracing routines

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/stack.h>

-
In the kernel configuration file:
-  

-  options DDB
-  

-  options STACK

-

-  

-  struct stack *
-  

-  stack_create(int
-    flags);

-
void
-  

-  stack_destroy(struct
-    stack *st);

-
int
-  

-  stack_put(struct
-    stack *st, vm_offset_t
-    pc);

-
void
-  

-  stack_copy(const
-    struct stack *src, struct
-    stack *dst);

-
void
-  

-  stack_zero(struct
-    stack *st);

-
void
-  

-  stack_print(const
-    struct stack *st);

-
void
-  

-  stack_print_ddb(const
-    struct stack *st);

-
void
-  

-  stack_print_short(const
-    struct stack *st);

-
void
-  

-  stack_print_short_ddb(const
-    struct stack *st);

-
void
-  

-  stack_sbuf_print(struct
-    sbuf *sb, const struct
-    stack *st);

-
void
-  

-  stack_sbuf_print_ddb(struct
-    sbuf *sb, const struct
-    stack *st);

-
void
-  

-  stack_save(struct
-    stack *st);

-
int
-  

-  stack_save_td(struct
-    stack *st, struct thread
-    *td);

-

-

-

-
The stack KPI allows querying of kernel
-    stack trace information and the automated generation of kernel stack trace
-    strings for the purposes of debugging and tracing. To use the KPI, at least
-    one of options DDB and options
-    STACK must be compiled into the kernel.

-
Each stack trace is described by a
-    struct stack. It can be declared in the usual ways,
-    including on the stack, and optionally initialized with
-    (),
-    though this is not necessary before saving a trace. It can also be
-    dynamically allocated with
-    ().
-    The flags argument is passed to
-    malloc(9). This dynamic allocation must be freed with
-    ().

-
A trace of the current thread's kernel call stack
-    may be captured using
-    ().
-    ()
-    can be used to capture the kernel stack of a caller-specified thread.
-    Callers of stack_save_td() must own the thread lock
-    of the specified thread, and the thread's stack must not be swapped out.
-    stack_save_td() can capture the kernel stack of a
-    running thread, though note that this is not implemented on all platforms.
-    If the thread is running, the caller must also hold the process lock for the
-    target thread.

-
()
-    and
-    ()
-    may be used to print a stack trace using the kernel
-    printf(9), and may sleep as a result of acquiring
-    sx(9) locks in the kernel linker while looking up symbol
-    names. In locking-sensitive environments, the unsynchronized
-    ()
-    and
-    ()
-    variants may be invoked. This function bypasses kernel linker locking,
-    making it usable in ddb(4), but not in a live system where
-    linker data structures may change.

-
()
-    may be used to construct a human-readable string, including conversion
-    (where possible) from a simple kernel instruction pointer to a named symbol
-    and offset. The argument sb must be an initialized
-    struct sbuf as described in
-    sbuf(9). This function may sleep if an auto-extending
-    struct sbuf is used, or due to kernel linker
-    locking. In locking-sensitive environments, such as
-    ddb(4), the unsynchronized
-    ()
-    variant may be invoked to avoid kernel linker locking; it should be used
-    with a fixed-length sbuf.

-
The utility functions stack_zero,
-    stack_copy, and stack_put
-    may be used to manipulate stack data structures directly.

-

-

-

-
stack_put() returns 0 on success.
-    Otherwise the struct stack does not contain space to
-    record additional frames, and a non-zero value is returned.

-
stack_save_td() returns 0 when the stack
-    capture was successful and a non-zero error number otherwise. In particular,
-    EBUSY is returned if the thread was running in user
-    mode at the time that the capture was attempted, and
-    EOPNOTSUPP is returned if the operation is not
-    implemented.

-

-

-

-
ddb(4), printf(9),
-    sbuf(9), sx(9)

-

-

-

-
The stack function suite was created by
-    Antoine Brodin. stack was
-    extended by Robert Watson for general-purpose use
-    outside of ddb(4).

-

-

-
-  
-    
-    
-  
-
March 6, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/store.9 4.html b/static/freebsd/man9/store.9 4.html
deleted file mode 100644
index aff016d8..00000000
--- a/static/freebsd/man9/store.9 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
STORE(9)Kernel Developer's ManualSTORE(9)

-

-

-

-
store, subyte,
-    suword — store data to
-    user-space

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/time.h>
-  

-  #include <sys/systm.h>

-
int
-  

-  subyte(volatile
-    void *base, int
-    byte);

-
int
-  

-  suword(volatile
-    void *base, long
-    word);

-
int
-  

-  suword16(volatile
-    void *base, int
-    word);

-
int
-  

-  suword32(volatile
-    void *base, int32_t
-    word);

-
int
-  

-  suword64(volatile
-    void *base, int64_t
-    word);

-

-

-

-
The store functions are designed to copy
-    small amounts of data to user-space. If the user address is naturally
-    aligned, then the operation will be performed atomically. Otherwise it may
-    fail or be performed non-atomically, depending on the platform.

-
The store routines provide the following
-    functionality:

-

-  
()

-  
Stores a byte of data to the user-space address
-      base.

-  
()

-  
Stores a word of data to the user-space address
-      base.

-  
()

-  
Stores 16 bits of data to the user-space address
-      base.

-  
()

-  
Stores 32 bits of data to the user-space address
-      base.

-  
()

-  
Stores 64 bits of data to the user-space address
-      base.

-

-

-

-

-
The store functions return 0 on success or
-    -1 on failure.

-

-

-

-
copy(9), fetch(9)

-

-

-
-  
-    
-    
-  
-
July 22, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/style.9 3.html b/static/freebsd/man9/style.9 3.html
deleted file mode 100644
index 4371bdc1..00000000
--- a/static/freebsd/man9/style.9 3.html	
+++ /dev/null
@@ -1,783 +0,0 @@
-
-  
-    
-    
-    
-  
-
STYLE(9)Kernel Developer's ManualSTYLE(9)

-

-

-

-
style — kernel
-    source file style guide

-

-

-

-
This file specifies the preferred style for kernel source files in
-    the FreeBSD source tree. It is also a guide for the
-    preferred userland code style. The preferred line width is 80 characters,
-    but some exceptions are made when a slightly longer line is clearer or
-    easier to read. Anything that is frequently grepped for, such as diagnostic,
-    error, or panic messages, should not be broken up over multiple lines
-    despite this rule. Many of the style rules are implicit in the examples. Be
-    careful to check the examples before assuming that
-    style is silent on an issue.

-

-
/*
- * Style guide for FreeBSD.  Based on the CSRG's KNF (Kernel Normal Form).
- */
-
-/*
- * VERY important single-line comments look like this.
- */
-
-/* Most single-line comments look like this. */
-
-// Although they may look like this.
-
-/*
- * Multi-line comments look like this.  Make them real sentences.  Fill
- * them so they look like real paragraphs.
- */

-

-
C++ comments may be used in C and C++ code. Single-line comments
-    should be consistently either C or C++ within a file. Multi-line comments
-    should also be consistently either C or C++, but may differ from single-line
-    comments.

-
The copyright header should be a multi-line comment like so:

-

-
/*
- * Copyright (c) 1984-2025 John Q. Public
- *
- * SPDX-License-Identifier: BSD-2-Clause
- */

-

-
Comments starting in columns other than the first are never
-    considered license statements. Write the copyright lines before the
-    appropriate SPDX-License-Identifier. If the copyright assertion contains the
-    phrase “All Rights Reserved” that
-    should be on the same line as the word
-    “Copyright”. You should not insert a
-    new copyright line between an old copyright line and this phrase. Instead,
-    you should insert a new copyright phrase after a pre-existing
-    “All Rights Reserved” line. When
-    making changes, it is acceptable to fold an “All
-    Rights Reserved” line with each of the
-    “Copyright” lines. For files that have
-    the “All Rights Reserved” line on the
-    same line(s) as the word “Copyright”,
-    new copyright assertions should be added last. New
-    “Copyright” lines should only be added
-    when making substantial changes to the file, not for trivial changes.

-
After any copyright and license comment, there is a blank line.
-    Non-C/C++ source files follow the example above, while C/C++ source files
-    follow the one below. Version control system ID tags should only exist once
-    in a file (unlike in this one). All VCS (version control system) revision
-    identification in files obtained from elsewhere should be maintained,
-    including, where applicable, multiple IDs showing a file's history. In
-    general, do not edit foreign IDs or their infrastructure. Unless otherwise
-    wrapped (such as “#if
-    defined(LIBC_SCCS)”), enclose both in
-    “#if 0 ... #endif” to hide any
-    uncompilable bits and to keep the IDs out of object files. Only add
-    “From: ” in front of foreign VCS IDs
-    if the file is renamed. Add “From: ”
-    and the FreeBSD git hash with full path name if the
-    file was derived from another FreeBSD file and
-    include relevant copyright info from the original file.

-
Leave one blank line before the header files.

-
Kernel include files (sys/*.h) come first.
-    If either <sys/types.h> or
-    <sys/param.h> is needed,
-    include it before other include files.
-    (<sys/param.h> includes
-    <sys/types.h>; do not
-    include both.) Next, include
-    <sys/systm.h>, if needed.
-    The remaining kernel headers should be sorted alphabetically.

-

-
#include <sys/types.h>	/* Non-local includes in angle brackets. */
-#include <sys/systm.h>
-#include <sys/endian.h>
-#include <sys/lock.h>
-#include <sys/queue.h>

-

-
For a network program, put the network include files next.

-

-
#include <net/if.h>
-#include <net/if_dl.h>
-#include <net/route.h>
-#include <netinet/in.h>
-#include <protocols/rwhod.h>

-

-
Do not include files from /usr/include in
-    the kernel.

-
Leave a blank line before the next group, the
-    /usr/include files, which should be sorted
-    alphabetically by name.

-

-
#include <stdio.h>

-

-
Global pathnames are defined in
-    <paths.h>. Pathnames local
-    to the program go in "pathnames.h" in the
-    local directory.

-

-
#include <paths.h>

-

-
Leave another blank line before the local include files.

-

-
#include "pathnames.h"		/* Local includes in double quotes. */

-

-
Do not #define or declare names in the
-    implementation namespace except for implementing application interfaces.

-
The names of “unsafe” macros (ones that have side
-    effects), and the names of macros for manifest constants, are all in
-    uppercase. The expansions of expression-like macros are either a single
-    token or have outer parentheses. Put a single space or tab character between
-    the #define and the macro name, but be consistent
-    within a file. If a macro is an inline expansion of a function, the function
-    name is all in lowercase and the macro has the same name all in uppercase.
-    Right-justify the backslashes; it makes it easier to read. If the macro
-    encapsulates a compound statement, enclose it in a
-    do loop, so that it can safely be used in
-    if statements. Any final statement-terminating
-    semicolon should be supplied by the macro invocation rather than the macro,
-    to make parsing easier for pretty-printers and editors.

-

-
#define	MACRO(x, y) do {						\
-	variable = (x) + (y);						\
-	(y) += 2;							\
-} while (0)

-

-
When code is conditionally compiled using
-    #ifdef or #if, a comment may
-    be added following the matching #endif or
-    #else to permit the reader to easily discern where
-    conditionally compiled code regions end. This comment should be used only
-    for (subjectively) long regions, regions greater than 20 lines, or where a
-    series of nested #ifdef 's may be confusing to the
-    reader. The comment should be separated from the
-    #endif or #else by a single
-    space. For short conditionally compiled regions, a closing comment should
-    not be used.

-
The comment for #endif should match the
-    expression used in the corresponding #if or
-    #ifdef. The comment for
-    #else and #elif should match
-    the inverse of the expression(s) used in the preceding
-    #if and/or #elif statements.
-    In the comments, the subexpression
-    “defined(FOO)” is abbreviated as
-    “FOO”. For the purposes of comments,
-    “#ifndef FOO”
-    is treated as “#if
-    !defined(FOO)”.

-

-
#ifdef KTRACE
-#include <sys/ktrace.h>
-#endif
-
-#ifdef COMPAT_43
-/* A large region here, or other conditional code. */
-#else /* !COMPAT_43 */
-/* Or here. */
-#endif /* COMPAT_43 */
-
-#ifndef COMPAT_43
-/* Yet another large region here, or other conditional code. */
-#else /* COMPAT_43 */
-/* Or here. */
-#endif /* !COMPAT_43 */

-

-
The project prefers the use of ISO/IEC 9899:1999
-    (“ISO C99”) unsigned integer identifiers of the
-    form uintXX_t rather than the older
-    BSD-style integer identifiers of the form
-    u_intXX_t. New code should use the former, and old
-    code should be converted to the new form if other major work is being done
-    in that area and there is no overriding reason to prefer the older
-    BSD-style. Like white-space commits, care should be
-    taken in making uintXX_t only commits.

-
Similarly, the project prefers the use of ISO C99
-    bool rather than the older int
-    or boolean_t. New code should use
-    bool, and old code may be converted if it is
-    reasonable to do so. Literal values are named true
-    and false. These are preferred to the old spellings
-    TRUE and FALSE. Userspace
-    code should include
-    <stdbool.h>, while kernel
-    code should include
-    <sys/types.h>.

-
Likewise, the project prefers ISO C99 designated initializers when
-    it makes sense to do so.

-
Enumeration values are all uppercase.

-

-
enum enumtype { ONE, TWO } et;

-

-
The use of internal_underscores in identifiers is preferred over
-    camelCase or TitleCase.

-
In declarations, do not put any whitespace between asterisks and
-    adjacent tokens, except for tokens that are identifiers related to types.
-    (These identifiers are the names of basic types, type qualifiers, and
-    typedef-names other than the one being declared.)
-    Separate these identifiers from asterisks using a single space.

-
When declaring variables in structures, declare them sorted by
-    use, then by size (largest to smallest), and then in alphabetical order. The
-    first category normally does not apply, but there are exceptions. Each one
-    gets its own line. Try to make the structure readable by aligning the member
-    names using either one or two tabs depending upon your judgment. You should
-    use one tab only if it suffices to align at least 90% of the member names.
-    Names following extremely long types should be separated by a single
-  space.

-
Major structures should be declared at the top of the file in
-    which they are used, or in separate header files if they are used in
-    multiple source files. Use of the structures should be by separate
-    declarations and should be extern if they are
-    declared in a header file.

-

-
struct foo {
-	struct foo	*next;		/* List of active foo. */
-	struct mumble	amumble;	/* Comment for mumble. */
-	int		bar;		/* Try to align the comments. */
-	struct verylongtypename *baz;	/* Does not fit in 2 tabs. */
-};
-struct foo *foohead;			/* Head of global foo list. */

-

-
Use queue(3) macros rather than rolling your own
-    lists, whenever possible. Thus, the previous example would be better
-    written:

-

-
#include <sys/queue.h>
-
-struct foo {
-	LIST_ENTRY(foo)	link;		/* Use queue macros for foo lists. */
-	struct mumble	amumble;	/* Comment for mumble. */
-	int		bar;		/* Try to align the comments. */
-	struct verylongtypename *baz;	/* Does not fit in 2 tabs. */
-};
-LIST_HEAD(, foo) foohead;		/* Head of global foo list. */

-

-
Avoid using typedefs for structure types. Typedefs are problematic
-    because they do not properly hide their underlying type; for example you
-    need to know if the typedef is the structure itself or a pointer to the
-    structure. In addition they must be declared exactly once, whereas an
-    incomplete structure type can be mentioned as many times as necessary.
-    Typedefs are difficult to use in stand-alone header files: the header that
-    defines the typedef must be included before the header that uses it, or by
-    the header that uses it (which causes namespace pollution), or there must be
-    a back-door mechanism for obtaining the typedef.

-
When convention requires a typedef, make
-    its name match the struct tag. Avoid typedefs ending in
-    “_t”, except as specified in Standard
-    C or by POSIX.

-

-
/* Make the structure name match the typedef. */
-typedef	struct bar {
-	int	level;
-} BAR;
-typedef	int		foo;		/* This is foo. */
-typedef	const long	baz;		/* This is baz. */

-

-
All functions are prototyped somewhere.

-
Function prototypes for private functions (i.e., functions not
-    used elsewhere) go at the top of the first source module. Functions local to
-    one source module should be declared static.

-
Functions used from other parts of the kernel are prototyped in
-    the relevant include file. Function prototypes should be listed in a logical
-    order, preferably alphabetical unless there is a compelling reason to use a
-    different ordering.

-
Functions that are used locally in more than one module go into a
-    separate header file, e.g.,
-  "extern.h".

-
The kernel has a name associated with parameter types, e.g., in
-    the kernel use:

-

-
void	function(int fd);

-

-
In header files visible to userland applications, prototypes that
-    are visible must use either “protected” names (ones beginning
-    with an underscore) or no names with the types. It is preferable to use
-    protected names. E.g., use:

-

-
void	function(int);

-

-
or:

-

-
void	function(int _fd);

-

-
Prototypes may have an extra space after a tab to enable function
-    names to line up:

-

-
static char	*function(int _arg, const char *_arg2, struct foo *_arg3,
-		    struct bar *_arg4);
-static void	 usage(void);
-
-/*
- * All major routines should have a comment briefly describing what
- * they do.  The comment before the "main" routine should describe
- * what the program does.
- */
-int
-main(int argc, char *argv[])
-{
-	char *ep;
-	long num;
-	int ch;

-

-
For consistency, getopt(3) should be used to
-    parse options. Options should be sorted in the getopt(3)
-    call and the switch statement, unless parts of the
-    switch cascade. Elements in a
-    switch statement that execute some code and then
-    cascade to the next case should have a FALLTHROUGH
-    comment. Numerical arguments should be checked for accuracy. Code which is
-    unreachable for non-obvious reasons may be marked /*
-    NOTREACHED */.

-

-
	while ((ch = getopt(argc, argv, "abNn:")) != -1)
-		switch (ch) {		/* Indent the switch. */
-		case 'a':		/* Do not indent the case. */
-			aflag = 1;	/* Indent case body one tab. */
-			/* FALLTHROUGH */
-		case 'b':
-			bflag = 1;
-			break;
-		case 'N':
-			Nflag = 1;
-			break;
-		case 'n':
-			num = strtol(optarg, &ep, 10);
-			if (num <= 0 || *ep != '\0') {
-				warnx("illegal number, -n argument -- %s",
-				    optarg);
-				usage();
-			}
-			break;
-		case '?':
-		default:
-			usage();
-		}
-	argc -= optind;
-	argv += optind;

-

-
Space after keywords (if,
-    while, for,
-    return, switch). Two styles
-    of braces (‘{’ and
-    ‘}’) are allowed for single line
-    statements. Either they are used for all single statements, or they are used
-    only where needed for clarity. Usage within a function should be consistent.
-    Forever loops are done with for's, not
-    while's.

-

-
	for (p = buf; *p != '\0'; ++p)
-		;	/* nothing */
-	for (;;)
-		stmt;
-	for (;;) {
-		z = a + really + long + statement + that + needs +
-		    two + lines + gets + indented + four + spaces +
-		    on + the + second + and + subsequent + lines;
-	}
-	for (;;) {
-		if (cond)
-			stmt;
-	}
-	if (val != NULL)
-		val = realloc(val, newsize);

-

-
Parts of a for loop may be left empty.

-

-
	for (; cnt < 15; cnt++) {
-		stmt1;
-		stmt2;
-	}

-

-
A for loop may declare and initialize its
-    counting variable.

-

-
	for (int i = 0; i < 15; i++) {
-		stmt1;
-	}

-

-
Indentation is an 8 character tab. Second level indents are four
-    spaces. If you have to wrap a long statement, put the operator at the end of
-    the line.

-

-
	while (cnt < 20 && this_variable_name_is_too_long &&
-	    ep != NULL)
-		z = a + really + long + statement + that + needs +
-		    two + lines + gets + indented + four + spaces +
-		    on + the + second + and + subsequent + lines;

-

-
Do not add whitespace at the end of a line, and only use tabs
-    followed by spaces to form the indentation. Do not use more spaces than a
-    tab will produce and do not use spaces in front of tabs.

-
Closing and opening braces go on the same line as the
-    else. Braces that are not necessary may be left
-  out.

-

-
	if (test)
-		stmt;
-	else if (bar) {
-		stmt;
-		stmt;
-	} else
-		stmt;

-

-
No spaces after function names. Commas have a space after them. No
-    spaces after ‘(’ or
-    ‘[’ or preceding
-    ‘]’ or
-    ‘)’ characters.

-

-
	error = function(a1, a2);
-	if (error != 0)
-		exit(error);

-

-
Unary operators do not require spaces, binary operators do. Do not
-    use parentheses unless they are required for precedence or unless the
-    statement is confusing without them. Remember that other people may confuse
-    easier than you. Do YOU understand the following?

-

-
	a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1;
-	k = !(l & FLAGS);

-

-
Exits should be 0 on success, or 1 on failure.

-

-
	exit(0);	/*
-			 * Avoid obvious comments such as
-			 * "Exit 0 on success."
-			 */
-}

-

-
The function type should be on a line by itself preceding the
-    function. The opening brace of the function body should be on a line by
-    itself.

-

-
static char *
-function(int a1, int a2, float fl, int a4, struct bar *bar)
-{

-

-
When declaring variables in functions declare them sorted by size,
-    then in alphabetical order; multiple ones per line are okay. If a line
-    overflows reuse the type keyword. Variables may be initialized where
-    declared especially when they are constant for the rest of the scope.
-    Declarations may be in any block, but must be placed before statements.
-    Calls to complicated functions should be avoided when initializing
-    variables.

-

-
	struct foo one, *two;
-	struct baz *three = bar_get_baz(bar);
-	double four;
-	int *five, six;
-	char *seven, eight, nine, ten, eleven, twelve;
-
-	four = my_complicated_function(a1, f1, a4);

-

-
Do not declare functions inside other functions; ANSI C says that
-    such declarations have file scope regardless of the nesting of the
-    declaration. Hiding file declarations in what appears to be a local scope is
-    undesirable and will elicit complaints from a good compiler.

-
Casts and sizeof's are not
-    followed by a space. sizeof's are written with
-    parenthesis always. The redundant parenthesis rules do not apply to
-    (var)
-    instances.

-
NULL is the preferred null pointer
-    constant. Use NULL instead of (type
-    *)0 or (type *)NULL in
-    contexts where the compiler knows the type, e.g., in assignments. Use
-    (type *)NULL in other
-    contexts, in particular for all function args. (Casting is essential for
-    variadic args and is necessary for other args if the function prototype
-    might not be in scope.) Test pointers against NULL,
-    e.g., use:

-

-
(p = f()) == NULL

-

-
not:

-

-
!(p = f())

-

-
Do not test without a comparison, or with unary
-    ! (except for booleans). For example, use:

-

-
if (*p == '\0')

-

-
not:

-

-
if (!*p)

-

-
Prefer:

-

-
if (count != 0)

-

-
over:

-

-
if (count)

-

-
Routines returning void * should not have
-    their return values cast to any pointer type.

-
Values in return statements should be
-    enclosed in parentheses.

-
Use err(3) or warn(3), do not
-    roll your own.

-

-
	if ((four = malloc(sizeof(struct foo))) == NULL)
-		err(1, (char *)NULL);
-	if ((six = (int *)overflow()) == NULL)
-		errx(1, "number overflowed");
-	return (eight);
-}

-

-
Do not use K&R style declarations or definitions, they are
-    obsolete and are forbidden in C23. Compilers warn of their use and some
-    treat them as an error by default. When converting K&R style definitions
-    to ANSI style, preserve any comments about parameters.

-
Long parameter lists are wrapped with a normal four space
-  indent.

-
Variable numbers of arguments should look like this:

-

-
#include <stdarg.h>
-
-void
-vaf(const char *fmt, ...)
-{
-	va_list ap;
-
-	va_start(ap, fmt);
-	STUFF;
-	va_end(ap);
-	/* No return needed for void functions. */
-}
-
-static void
-usage(void)
-{

-

-
Functions should have local variable declarations first, followed
-    by one blank line, followed by the first statement. If no local variables
-    are declared, the first line should be a statement. Older versions of this
-    style document required a blank line before code.
-    Such lines should be removed when significant changes are made to the
-  code.

-
Use printf(3), not fputs(3),
-    puts(3), putchar(3), whatever; it is
-    faster and usually cleaner, not to mention avoiding stupid bugs.

-
Usage statements should look like the manual pages
-    SYNOPSIS. The usage statement should be
-    structured in the following order:

-
    
-  
  1. Options without operands come first, in alphabetical order, inside a
-      single set of brackets (‘[’ and
-      ‘]’).
    2. 
-  
  2. Options with operands come next, also in alphabetical order, with each
-      option and its argument inside its own pair of brackets.
    3. 
-  
  3. Required arguments (if any) are next, listed in the order they should be
-      specified on the command line.
    4. 
-  
  4. Finally, any optional arguments should be listed, listed in the order they
-      should be specified, and all inside brackets.
    5. 
-

-
A bar (‘|’) separates
-    “either-or” options/arguments, and multiple options/arguments
-    which are specified together are placed in a single set of brackets.

-

-
"usage: f [-aDde] [-b b_arg] [-m m_arg] req1 req2 [opt1 [opt2]]\n"
-"usage: f [-a | -b] [-c [-dEe] [-n number]]\n"

-

-

-
	(void)fprintf(stderr, "usage: f [-ab]\n");
-	exit(1);
-}

-

-
Note that the manual page options description should list the
-    options in pure alphabetical order. That is, without regard to whether an
-    option takes arguments or not. The alphabetical ordering should take into
-    account the case ordering shown above.

-
Whenever possible, code should be run through a code checker
-    (e.g., various static analyzers or cc
-    -Wall) and produce minimal warnings.

-
New code should use
-    ()
-    instead of the older
-    ().

-
()
-    and
-    ()
-    should only be used in frequently executed code when it makes the code
-    measurably faster. It is wasteful to make predictions for infrequently run
-    code, like subsystem initialization. When using branch prediction hints,
-    atypical error conditions should use
-    __predict_false() (document the exceptions).
-    Operations that almost always succeed use
-    __predict_true(). Only use the annotation for the
-    entire if statement, rather than individual clauses. Do not add these
-    annotations without empirical evidence of the likelihood of the branch.

-
New core kernel code should be compliant with the
-    style guides. The guidelines for third-party
-    maintained modules and device drivers are more relaxed. Their code is
-    expected to at least be internally consistent with their style.

-
Stylistic changes, including whitespace ones, complicate the work
-    of downstream consumers and may impair developers' ability to trace the
-    history of some changes. Such standalone must be avoided, and should not
-    span unrelated directories as this increases the chances of conflicts when
-    merging to stable and release branches (MFCs). On the other hand, when a
-    significant portion, usually about a half, of some logical unit of code, be
-    it a function, group of functions, file or group of files, is going to be
-    modified, developers are encouraged to amend the style of the whole unit as
-    described in this document. In this case, style changes to otherwise
-    unmodified code should be committed separately. Style-only commits should be
-    added to the file .git-blame-ignore-revs at the top
-    of the source repository to hide them from ‘git
-    blame’. Comments in this file indicate how to use it. Code
-    that is approximately FreeBSD KNF
-    style compliant in the repository must not diverge
-    from compliance.

-

-

-
KNF style was originally defined as a style for C. C++ introduces
-    several new idioms which do not have an existing corollary in KNF C such as
-    inline function definitions in classes. C++ is also not always compatible
-    with some KNF guidelines such as enclosing return values in parentheses. For
-    C++ code, FreeBSD aims to follow broadly accepted C++ practices while also
-    following the general shape of KNF. This section enumerates C++ specific
-    guidelines that differ from KNF C.

-
The preferred suffixes for C++ source files are
-    “.cc” and “.hh”. Header files should always use
-    a suffix, unlike headers from the C++ standard library.

-
Return values should not be enclosed in parentheses. When
-    converting existing C code to C++, existing return values may remain in
-    parentheses.

-
The opening curly brace for namespace declarations should be on
-    the first line similar to structure and class definitions. Nested namespaces
-    should be declared using a single namespace declaration.

-

-
namespace foo::bar {
-}

-

-
Member function declarations should follow the same style used for
-    standalone function prototypes except that a space should be used between a
-    function's return type and name.

-
Function definitions at the top level should use a newline after
-    the function type similar to C function definitions.

-
Nested member function definitions inside of a class, structure,
-    or union should not use a newline after the function type. Instead, these
-    should follow the style of member function declarations. This is more common
-    C++ style and is more compact for small methods such as getters and
-  setters.

-
Inline functions whose body consists of a single statement may use
-    a single line for the function body. Inline functions with an empty body
-    should always use a single line.

-

-
struct widget {
-	int foo() { return 4; }
-	int bar();
-};
-
-int
-widget::bar()
-{
-	return 6;
-}

-

-
Default and deleted methods should be declared as a single
-  line.

-

-
class box {
-	~box() = default;
-};

-

-
In template declarations, the template
-    keyword and list of template parameters should be followed by a newline
-    before the templated declaration.

-

-
template <typename T>
-class box {
-	T data;
-};

-

-
The & for reference variables should
-    be placed on the variable name rather than the type similar to the style
-    used with * for pointers.

-

-
	int x;
-	int &xp = x;

-

-
Variables may be declared at any point within a function, not just
-    at the start of blocks.

-
Standard library containers should be used in preference to
-    queue(3) or tree(3) macros.

-
nullptr should be used instead of
-    NULL or 0.

-
Use standard library types for managing strings such as
-    std::string and std::string_view
-    rather than char * and const char
-    *. C types may be used when interfacing with C code.

-
The auto keyword can
-    be used in various contexts which improve readability. Examples include
-    iterators, non-trivial types of ranged-for values, and return values of
-    obvious types, such as static_cast or
-    ().
-    Place any qualifiers before auto, for example:
-    const auto.

-
Use the
-    std::unique_ptr and
-    std::shared_ptr smart pointers to manage the lifetime
-    of dynamically allocated objects instead of new and
-    delete. Construct smart pointers with
-    ()
-    or
-    ().
-    Do not use malloc(3) except when necessary to interface
-    with C code.

-
Do not import any namespaces with using at
-    global scope in header files. Namespaces other than the
-    std namespace (for example,
-    std::literals) may be imported in source files and
-    in function scope in header files.

-
Define type aliases using using instead of
-    typedef.

-

-

-

-

-

-  
/usr/src/tools/build/checkstyle9.pl

-  
A script to check for violations of style in a
-      source file.

-  
/usr/src/tools/tools/editing/freebsd.el

-  
An Emacs plugin to follow the FreeBSD
-      style indentation rules.

-  
/usr/src/tools/tools/editing/freebsd.vim

-  
A Vim plugin to follow the FreeBSD
-      style indentation rules.

-

-

-

-

-
indent(1), err(3),
-    warn(3), style.Makefile(5),
-    style.mdoc(5), style.lua(9)

-

-

-

-
This manual page was originally based on the
-    src/admin/style/style file from the
-    4.4BSD-Lite2 release, with frequent updates to
-    reflect the current practice and desire of the
-    FreeBSD project.
-    src/admin/style/style is a codification by the CSRG
-    of the programming style of Ken Thompson and Dennis Ritchie in
-    Version 6 AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
July 28, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/style.lua.9 3.html b/static/freebsd/man9/style.lua.9 3.html
deleted file mode 100644
index 94053bfd..00000000
--- a/static/freebsd/man9/style.lua.9 3.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
STYLE.LUA(9)Kernel Developer's ManualSTYLE.LUA(9)

-

-

-

-
style.lua —
-    FreeBSD lua file style
-  guide

-

-

-

-
This file specifies the preferred style for lua source files in
-    the FreeBSD source tree. Many of the style rules are
-    implicit in the examples. Be careful to check the examples before assuming
-    that style.lua is silent on an issue.

-
The copyright header should be a series of single-line comments.
-    Use the single-line comment style for every line in a multi-line
-  comment.

-
After any copyright header there is a blank line.

-
The preferred method of including other files and
-    modules is with
-    (name),
-    such as:

-

-
-- License block
-
-config = require("config");
-menu = require("menu");
-password = require("password");
--- One blank line following the module require block

-

-
()
-    is generally avoided.

-
Indentation and wrapping should match the guidelines provided by
-    style(9). Do note that it is ok to wrap much earlier than
-    80 columns if readability would otherwise suffer.

-
Where possible,
-    (...)
-    is preferred to
-    (s,
-    ...). This is applicable to objects with methods.
-    String are a commonly-used example of objects with methods.

-
Testing for nil should be done explicitly,
-    rather than as a boolean expression. Single-line conditional statements and
-    loops should be avoided.

-
local variables should be preferred to
-    global variables in module scope. internal_underscores tend to be preferred
-    for variable identifiers, while camelCase tends to be preferred for function
-    identifiers.

-
If a table definition spans multiple lines, then the final value
-    in the table should include the optional terminating comma. For example:

-

-
-- No terminating comma needed for trivial table definitions
-local trivial_table = {1, 2, 3, 4}
-
-local complex_table = {
-	{
-		id = "foo",
-		func = foo_function, -- Trailing comma preferred
-	},
-	{
-		id = "bar",
-		func = bar_function,
-	},	-- Trailing comma preferred
-}

-

-
This reduces the chance for errors to be introduced when modifying
-    more complex tables.

-
Multiple local variables should not be declared
-     initialized on a
-    single line. Lines containing multiple variable declarations without
-    initialization are ok. Lines containing multiple variable declarations
-    initialized to a single function call returning a tuple with the same number
-    of values is also ok.

-
Initialization
-     be done at
-    declaration time as appropriate.

-

-

-

-
style(9)

-

-

-

-
This manual page is inspired from the same source as
-    style(9) manual page in
-  FreeBSD.

-

-

-
-  
-    
-    
-  
-
February 25, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/superio.9 4.html b/static/freebsd/man9/superio.9 4.html
deleted file mode 100644
index c933e7e5..00000000
--- a/static/freebsd/man9/superio.9 4.html	
+++ /dev/null
@@ -1,195 +0,0 @@
-
-  
-    
-    
-    
-  
-
SUPERIO(9)Kernel Developer's ManualSUPERIO(9)

-

-

-

-
superio,
-    superio_devid,
-    superio_dev_disable,
-    superio_dev_enable,
-    superio_dev_enabled,
-    superio_find_dev,
-    superio_get_dma,
-    superio_get_iobase,
-    superio_get_irq,
-    superio_get_ldn,
-    superio_get_type,
-    superio_read, superio_revid,
-    superio_vendor,
-    superio_write — Super I/O
-    bus interface

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include
-    <dev/superio/superio.h>

-
uint16_t
-  

-  superio_devid(device_t
-    dev);

-
void
-  

-  superio_dev_disable(device_t
-    dev, uint8_t
-  mask);

-
void
-  

-  superio_dev_enable(device_t
-    dev, uint8_t
-  mask);

-
bool
-  

-  superio_dev_enabled(device_t
-    dev, uint8_t
-  mask);

-
device_t
-  

-  superio_find_dev(device_t
-    dev, superio_dev_type_t
-    type, int ldn);

-
uint8_t
-  

-  superio_get_dma(device_t
-    dev);

-
uint16_t
-  

-  superio_get_iobase(device_t
-    dev);

-
uint8_t
-  

-  superio_get_irq(device_t
-    dev);

-
uint8_t
-  

-  superio_get_ldn(device_t
-    dev);

-
superio_dev_type_t
-  

-  superio_get_type(device_t
-    dev);

-
uint8_t
-  

-  superio_read(device_t
-    dev, uint8_t
-  reg);

-
uint8_t
-  

-  superio_revid(device_t
-    dev);

-
superio_vendor_t
-  

-  superio_vendor(device_t
-    dev);

-
void
-  

-  superio_write(device_t
-    dev, uint8_t reg,
-    uint8_t val);

-

-

-

-
The superio set of functions are used for
-    managing Super I/O devices. The functions provide support for raw
-    configuration access, locating devices, device information, and device
-    configuration.

-

-

-
The
-    ()
-    function is used to get a vendor of the Super I/O controller
-    dev. Possible return values are
-    SUPERIO_VENDOR_ITE and
-    SUPERIO_VENDOR_NUVOTON.

-
The
-    ()
-    function is used to get a device ID of the Super I/O controller
-    dev.

-
The
-    ()
-    function is used to get a revision ID of the Super I/O controller
-    dev.

-
The
-    ()
-    function is used to find a device on the superio(4) bus,
-    specified by dev, that has the requested type and
-    logical device number. Either of those, but not both, can be a wildcard.
-    Supported types are SUPERIO_DEV_GPIO,
-    SUPERIO_DEV_HWM, and
-    SUPERIO_DEV_WDT. The wildcard value for
-    type is SUPERIO_DEV_NONE. The
-    wildcard value for ldn is -1.

-

-

-

-
The
-    ()
-    function is used to read data from the Super I/O configuration register of
-    the device dev.

-
The
-    ()
-    function is used to write data to the Super I/O configuration register of
-    the device dev.

-
The
-    (),
-    (),
-    and
-    ()
-    functions are used to enable, disable, or check status of the device
-    dev. The mask parameter selects
-    sub-functions of a device that supports them. For devices that do not have
-    sub-functions, mask should be set to 1.

-

-

-

-
The
-    ()
-    is used to get a DMA channel number configured for the device
-    dev.

-
The
-    ()
-    is used to get a base I/O port configured for the device
-    dev. The device may expose additional or alternative
-    configuration access via the I/O ports.

-
The
-    ()
-    is used to get an interrupt number configured for the device
-    dev.

-
The
-    ()
-    is used to get a Logical Device Number of the device
-    dev.

-
The
-    ()
-    is used to get a type of the device dev.

-

-

-

-

-
superio(4), device(9),
-    driver(9)

-

-

-

-
This manual page was written by Andriy
-    Gapon
-  avg@FreeBSD.org

-

-

-
-  
-    
-    
-  
-
October 11, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/swi.9 3.html b/static/freebsd/man9/swi.9 3.html
deleted file mode 100644
index e6f547e6..00000000
--- a/static/freebsd/man9/swi.9 3.html	
+++ /dev/null
@@ -1,172 +0,0 @@
-
-  
-    
-    
-    
-  
-
SWI(9)Kernel Developer's ManualSWI(9)

-

-

-

-
swi_add,
-    swi_remove, swi_sched
-    — register and schedule software interrupt
-    handlers

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/bus.h>
-  

-  #include <sys/interrupt.h>

-
extern struct intr_event
-  *clk_intr_event;

-
int
-  

-  swi_add(struct intr_event
-    **eventp, const char *name,
-    driver_intr_t handler, void
-    *arg, int pri, enum intr_type
-    flags, void **cookiep);

-
int
-  

-  swi_remove(void
-    *cookie);

-
void
-  

-  swi_sched(void
-    *cookie, int
-    flags);

-

-

-

-
These functions are used to register and schedule software
-    interrupt handlers. Software interrupt handlers are attached to a software
-    interrupt thread, just as hardware interrupt handlers are attached to a
-    hardware interrupt thread. Multiple handlers can be attached to the same
-    thread. Software interrupt handlers can be used to queue up less critical
-    processing inside of hardware interrupt handlers so that the work can be
-    done at a later time. Software interrupt threads are different from other
-    kernel threads in that they are treated as an interrupt thread. This means
-    that time spent executing these threads is counted as interrupt time, and
-    that they can be run via a lightweight context switch.

-
The
-    ()
-    function is used to add a new software interrupt handler to a specified
-    interrupt event. The eventp argument is an optional
-    pointer to a struct intr_event pointer. If this
-    argument points to an existing event that holds a list of interrupt
-    handlers, then this handler will be attached to that event. Otherwise a new
-    event will be created, and if eventp is not
-    NULL, then the pointer at that address to will be
-    modified to point to the newly created event. The name
-    argument is used to associate a name with a specific handler. This name is
-    appended to the name of the software interrupt thread that this handler is
-    attached to. The handler argument is the function that
-    will be executed when the handler is scheduled to run. The
-    arg parameter will be passed in as the only parameter
-    to handler when the function is executed. The
-    pri value specifies the priority of this interrupt
-    handler relative to other software interrupt handlers. If an interrupt event
-    is created, then this value is used as the vector, and the
-    flags argument is used to specify the attributes of a
-    handler such as INTR_MPSAFE. The
-    cookiep argument points to a void
-    * cookie. This cookie will be set to a value that uniquely identifies
-    this handler, and is used to schedule the handler for execution later
-  on.

-
The
-    ()
-    function is used to teardown an interrupt handler pointed to by the
-    cookie argument. It detaches the interrupt handler
-    from the associated interrupt event and frees its memory.

-
The
-    ()
-    function is used to schedule an interrupt handler and its associated thread
-    to run. The cookie argument specifies which software
-    interrupt handler should be scheduled to run. The
-    flags argument specifies how and when the handler
-    should be run and is a mask of one or more of the following flags:

-

-  

-  
Specifies that the kernel should mark the specified handler as needing to
-      run, but the kernel should not schedule the software interrupt thread to
-      run. Instead, handler will be executed the next time
-      that the software interrupt thread runs after being scheduled by another
-      event.

-  

-  
Specifies that swi_sched() is called from NMI
-      context and should be careful about used KPIs. On platforms allowing IPI
-      sending from NMI context it immediately wakes
-      clk_intr_event via the IPI, otherwise it works just
-      like SWI_DELAY.

-

-
clk_intr_event is a pointer to the
-    struct intr_event used to hang delayed handlers off of
-    the clock interrupt, and is invoked directly by
-    hardclock(9).

-

-

-

-
The swi_add() and
-    swi_remove() functions return zero on success and
-    non-zero on failure.

-

-

-

-
The swi_add() function will fail if:

-

-  
[]

-  
The system-imposed limit on the total number of processes under execution
-      would be exceeded. The limit is given by the sysctl(3)
-      MIB variable KERN_MAXPROC.

-  
[]

-  
The flags argument specifies
-      INTR_ENTROPY.

-  
[]

-  
The eventp argument points to a hardware interrupt
-      thread.

-  
[]

-  
Either of the name or handler
-      arguments are NULL.

-  
[]

-  
The INTR_EXCL flag is specified and the interrupt
-      event pointed to by eventp already has at least one
-      handler, or the interrupt event already has an exclusive handler.

-

-
The swi_remove() function will fail
-  if:

-

-  
[]

-  
A software interrupt handler pointed to by cookie is
-      NULL.

-

-

-

-

-
hardclock(9), intr_event(9),
-    taskqueue(9)

-

-

-

-
The swi_add() and
-    swi_sched() functions first appeared in
-    FreeBSD 5.0. They replaced the
-    register_swi() function which appeared in
-    FreeBSD 3.0 and the
-    setsoft*(), and schedsoft*()
-    functions which date back to at least 4.4BSD. The
-    swi_remove() function first appeared in
-    FreeBSD 6.1.

-

-

-
-  
-    
-    
-  
-
October 12, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/sx.9 4.html b/static/freebsd/man9/sx.9 4.html
deleted file mode 100644
index 3e4feed3..00000000
--- a/static/freebsd/man9/sx.9 4.html	
+++ /dev/null
@@ -1,301 +0,0 @@
-
-  
-    
-    
-    
-  
-
SX(9)Kernel Developer's ManualSX(9)

-

-

-

-
sx, sx_init,
-    sx_init_flags, sx_destroy,
-    sx_slock, sx_xlock,
-    sx_slock_sig, sx_xlock_sig,
-    sx_try_slock, sx_try_xlock,
-    sx_sunlock, sx_xunlock,
-    sx_unlock, sx_try_upgrade,
-    sx_downgrade, sx_sleep,
-    sx_xholder, sx_xlocked,
-    sx_assert, SX_SYSINIT,
-    SX_SYSINIT_FLAGS — kernel
-    shared/exclusive lock

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/lock.h>
-  

-  #include <sys/sx.h>

-
void
-  

-  sx_init(struct
-    sx *sx, const char
-    *description);

-
void
-  

-  sx_init_flags(struct
-    sx *sx, const char
-    *description, int
-    opts);

-
void
-  

-  sx_destroy(struct
-    sx *sx);

-
void
-  

-  sx_slock(struct
-    sx *sx);

-
void
-  

-  sx_xlock(struct
-    sx *sx);

-
int
-  

-  sx_slock_sig(struct
-    sx *sx);

-
int
-  

-  sx_xlock_sig(struct
-    sx *sx);

-
int
-  

-  sx_try_slock(struct
-    sx *sx);

-
int
-  

-  sx_try_xlock(struct
-    sx *sx);

-
void
-  

-  sx_sunlock(struct
-    sx *sx);

-
void
-  

-  sx_xunlock(struct
-    sx *sx);

-
void
-  

-  sx_unlock(struct
-    sx *sx);

-
int
-  

-  sx_try_upgrade(struct
-    sx *sx);

-
void
-  

-  sx_downgrade(struct
-    sx *sx);

-
int
-  

-  sx_sleep(void
-    *chan, struct sx
-    *sx, int priority,
-    const char *wmesg,
-    int timo);

-
struct thread *
-  

-  sx_xholder(struct
-    sx *sx);

-
int
-  

-  sx_xlocked(const
-    struct sx *sx);

-

-  

-  options INVARIANTS
-  

-  options INVARIANT_SUPPORT
-  

-  void
-  

-  sx_assert(const
-    struct sx *sx, int
-    what);

-
#include
-    <sys/kernel.h>

-
SX_SYSINIT(name,
-    struct sx *sx,
-    const char *desc);

-
SX_SYSINIT_FLAGS(name,
-    struct sx *sx,
-    const char *desc,
-    int flags);

-

-

-

-
Shared/exclusive locks are used to protect data that are read far
-    more often than they are written. Shared/exclusive locks do not implement
-    priority propagation like mutexes and reader/writer locks to prevent
-    priority inversions, so shared/exclusive locks should be used prudently.

-
Shared/exclusive locks are created with either
-    ()
-    or
-    ()
-    where sx is a pointer to space for a
-    struct sx, and description is a
-    pointer to a null-terminated character string that describes the
-    shared/exclusive lock. The opts argument to
-    sx_init_flags() specifies a set of optional flags to
-    alter the behavior of sx. It contains one or more of
-    the following flags:

-

-  

-  
Witness should not log messages about duplicate locks being acquired.

-  

-  
Instruct witness(4) to ignore this lock.

-  

-  
Do not profile this lock.

-  

-  
Allow threads to recursively acquire exclusive locks for
-      sx.

-  

-  
Do not log any operations for this lock via ktr(4).

-  

-  
If the kernel has been compiled with options
-      INVARIANTS, sx_init() will assert that the
-      sx has not been initialized multiple times without
-      intervening calls to sx_destroy() unless this
-      option is specified.

-

-
Shared/exclusive locks are destroyed with
-    ().
-    The lock sx must not be locked by any thread when it
-    is destroyed.

-
Threads acquire and release a shared lock by calling
-    (),
-    sx_slock_sig() or
-    sx_try_slock() and
-    sx_sunlock() or sx_unlock().
-    Threads acquire and release an exclusive lock by calling
-    (),
-    sx_xlock_sig() or
-    sx_try_xlock() and
-    sx_xunlock() or sx_unlock().
-    A thread can attempt to upgrade a currently held shared lock to an exclusive
-    lock by calling sx_try_upgrade(). A thread that has
-    an exclusive lock can downgrade it to a shared lock by calling
-    ().

-
()
-    and
-    ()
-    will return 0 if the shared/exclusive lock cannot be acquired immediately;
-    otherwise the shared/exclusive lock will be acquired and a non-zero value
-    will be returned.

-
()
-    will return 0 if the shared lock cannot be upgraded to an exclusive lock
-    immediately; otherwise the exclusive lock will be acquired and a non-zero
-    value will be returned.

-
()
-    and
-    ()
-    do the same as their normal versions but performing an interruptible sleep.
-    They return a non-zero value if the sleep has been interrupted by a signal
-    or an interrupt, otherwise 0.

-
A thread can atomically release a shared/exclusive
-    lock while waiting for an event by calling
-    ().
-    For more details on the parameters to this function, see
-    sleep(9).

-
When compiled with options
-    INVARIANTS and options INVARIANT_SUPPORT, the
-    ()
-    function tests sx for the assertions specified in
-    what, and panics if they are not met. One of the
-    following assertions must be specified:

-

-  

-  
Assert that the current thread has either a shared or an exclusive lock on
-      the sx lock pointed to by the first argument.

-  

-  
Assert that the current thread has a shared lock on the
-      sx lock pointed to by the first argument.

-  

-  
Assert that the current thread has an exclusive lock on the
-      sx lock pointed to by the first argument.

-  

-  
Assert that the current thread has no lock on the sx
-      lock pointed to by the first argument.

-

-
In addition, one of the following optional assertions may be
-    included with either an SA_LOCKED,
-    SA_SLOCKED, or SA_XLOCKED
-    assertion:

-

-  

-  
Assert that the current thread has a recursed lock on
-      sx.

-  

-  
Assert that the current thread does not have a recursed lock on
-      sx.

-

-
()
-    will return a pointer to the thread which currently holds an exclusive lock
-    on sx. If no thread holds an exclusive lock on
-    sx, then NULL is returned
-    instead.

-
()
-    will return non-zero if the current thread holds the exclusive lock;
-    otherwise, it will return zero.

-
For ease of programming,
-    ()
-    is provided as a macro frontend to the respective functions,
-    ()
-    and
-    ().
-    Algorithms that are aware of what state the lock is in should use either of
-    the two specific functions for a minor performance benefit.

-
The
-    ()
-    macro is used to generate a call to the
-    ()
-    routine at system startup in order to initialize a given
-    sx lock. The parameters are the same as
-    sx_init() but with an additional argument,
-    name, that is used in generating unique variable names
-    for the related structures associated with the lock and the sysinit routine.
-    The
-    ()
-    macro can similarly be used to initialize a given sx
-    lock using sx_init_flags().

-
A thread may not hold both a shared lock and an exclusive lock on
-    the same lock simultaneously; attempting to do so will result in
-  deadlock.

-

-

-

-
A thread may hold a shared or exclusive lock on an
-    sx lock while sleeping. As a result, an
-    sx lock may not be acquired while holding a mutex.
-    Otherwise, if one thread slept while holding an sx
-    lock while another thread blocked on the same sx
-    lock after acquiring a mutex, then the second thread would effectively end
-    up sleeping while holding a mutex, which is not allowed.

-

-

-

-
lock(9), locking(9),
-    mutex(9), panic(9),
-    rwlock(9), sema(9)

-

-

-

-
A kernel without WITNESS cannot assert
-    whether the current thread does or does not hold a shared lock.
-    SA_LOCKED and SA_SLOCKED can
-    only assert that
-     thread
-    holds a shared lock. They cannot ensure that the current thread holds a
-    shared lock. Further, SA_UNLOCKED can only assert
-    that the current thread does not hold an exclusive lock.

-

-

-
-  
-    
-    
-  
-
November 11, 2017FreeBSD 15.0

diff --git a/static/freebsd/man9/syscall_helper_register.9 4.html b/static/freebsd/man9/syscall_helper_register.9 4.html
deleted file mode 100644
index cd3e0983..00000000
--- a/static/freebsd/man9/syscall_helper_register.9 4.html	
+++ /dev/null
@@ -1,129 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSCALL_HELPER_REGISTER(9)Kernel Developer's ManualSYSCALL_HELPER_REGISTER(9)

-

-

-

-
syscall_helper_register,
-    syscall_helper_unregister —
-    kernel syscall registration routines

-

-

-

-
#include
-    <sys/sysent.h>

-
int
-  

-  syscall_helper_register(struct
-    syscall_helper_data *sd,
-    int flags);

-
int
-  

-  syscall_helper_unregister(struct
-    syscall_helper_data *sd);

-

-

-
struct syscall_helper_data
-  

-  SYSCALL_INIT_HELPER(syscallname);

-
struct syscall_helper_data
-  

-  SYSCALL_INIT_HELPER_F(syscallname,
-    int flags);

-

-

-

-
struct syscall_helper_data
-  

-  SYSCALL_INIT_HELPER_COMPAT(syscallname);

-
struct syscall_helper_data
-  

-  SYSCALL_INIT_HELPER_COMPAT_F(syscallname,
-    int flags);

-

-

-

-

-
The
-    ()
-    registers a system call. This function takes the structure
-    struct syscall_helper_data sd, which specifies the
-    parameters for syscall registration:

-

-

-
struct syscall_helper_data {
-	struct sysent	new_sysent;
-	struct sysent	old_sysent;
-	int		syscall_no;
-	int		registered;
-};

-

-
The only valid flag for the
-    flags argument to
-    ()
-    is SY_THR_STATIC. This flag prevents the syscall
-    from being unregistered.

-
Before use, the structure must be
-    initialized with one of the
-    ()
-    macros. In new code, syscall implementation functions shall be named
-    ()
-    and the regular macros shall be used.

-
For legacy syscall functions named without "sys_"
-    prefixes, the "COMPAT" versions of the macros may be used.

-
The only valid flag for the flags argument
-    to the "F" variants of the initializer macros is
-    SYF_CAPENABLED. This flag indicates that the syscall
-    is allowed in capability mode.

-
The
-    ()
-    unregisters a system call. This function takes the same structure
-    struct syscall_helper_data sd that was previously
-    initialized in the manner described above and used in a successful
-    invocation of syscall_helper_register().

-

-

-

-
If successful, syscall_helper_register()
-    and syscall_helper_unregister() will return 0.
-    Otherwise, they will return an error.

-

-

-

-
The syscall_helper_register() call will
-    fail and the syscall will not be registered if:

-

-  
[]

-  
The flags argument contained a value other than
-      SY_THR_STATIC.

-  
[]

-  
The specified syscall number, sd.syscall_no
-      (SYS_syscallname), was outside of the valid range
-      of system call numbers (zero through
-      SYS_MAXSYSCALL).

-  
[]

-  
The system call table does not have any available slots.

-  
[]

-  
The specified syscall number, sd.syscall_no
-      (SYS_syscallname), was already in use.

-

-

-

-

-
SYSCALL_MODULE(9)

-

-

-
-  
-    
-    
-  
-
February 10, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/sysctl.9 3.html b/static/freebsd/man9/sysctl.9 3.html
deleted file mode 100644
index 93380af8..00000000
--- a/static/freebsd/man9/sysctl.9 3.html	
+++ /dev/null
@@ -1,1148 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSCTL(9)Kernel Developer's ManualSYSCTL(9)

-

-

-

-
SYSCTL_DECL,
-    SYSCTL_ADD_BOOL,
-    SYSCTL_ADD_COUNTER_U64,
-    SYSCTL_ADD_COUNTER_U64_ARRAY,
-    SYSCTL_ADD_INT,
-    SYSCTL_ADD_LONG,
-    SYSCTL_ADD_NODE,
-    SYSCTL_ADD_NODE_WITH_LABEL,
-    SYSCTL_ADD_OPAQUE,
-    SYSCTL_ADD_PROC,
-    SYSCTL_ADD_QUAD,
-    SYSCTL_ADD_ROOT_NODE,
-    SYSCTL_ADD_S8,
-    SYSCTL_ADD_S16,
-    SYSCTL_ADD_S32,
-    SYSCTL_ADD_S64,
-    SYSCTL_ADD_SBINTIME_MSEC,
-    SYSCTL_ADD_SBINTIME_USEC,
-    SYSCTL_ADD_STRING,
-    SYSCTL_ADD_CONST_STRING,
-    SYSCTL_ADD_STRUCT,
-    SYSCTL_ADD_TIMEVAL_SEC,
-    SYSCTL_ADD_U8,
-    SYSCTL_ADD_U16,
-    SYSCTL_ADD_U32,
-    SYSCTL_ADD_U64,
-    SYSCTL_ADD_UAUTO,
-    SYSCTL_ADD_UINT,
-    SYSCTL_ADD_ULONG,
-    SYSCTL_ADD_UMA_CUR,
-    SYSCTL_ADD_UMA_MAX,
-    SYSCTL_ADD_UQUAD,
-    SYSCTL_CHILDREN,
-    SYSCTL_STATIC_CHILDREN,
-    SYSCTL_NODE_CHILDREN,
-    SYSCTL_PARENT, SYSCTL_BOOL,
-    SYSCTL_COUNTER_U64,
-    SYSCTL_COUNTER_U64_ARRAY,
-    SYSCTL_INT,
-    SYSCTL_INT_WITH_LABEL,
-    SYSCTL_LONG,
-    sysctl_msec_to_ticks,
-    SYSCTL_NODE,
-    SYSCTL_NODE_WITH_LABEL,
-    SYSCTL_OPAQUE, SYSCTL_PROC,
-    SYSCTL_QUAD,
-    SYSCTL_ROOT_NODE, SYSCTL_S8,
-    SYSCTL_S16, SYSCTL_S32,
-    SYSCTL_S64,
-    SYSCTL_SBINTIME_MSEC,
-    SYSCTL_SBINTIME_USEC,
-    SYSCTL_STRING,
-    SYSCTL_CONST_STRING,
-    SYSCTL_STRUCT,
-    SYSCTL_TIMEVAL_SEC,
-    SYSCTL_U8, SYSCTL_U16,
-    SYSCTL_U32, SYSCTL_U64,
-    SYSCTL_UINT, SYSCTL_ULONG,
-    SYSCTL_UMA_CUR,
-    SYSCTL_UMA_MAX, SYSCTL_UQUAD
-    — Dynamic and static sysctl MIB creation
-    functions

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/sysctl.h>

-
SYSCTL_DECL(name);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_BOOL(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, bool *ptr,
-    uint8_t val, const char
-  *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_COUNTER_U64(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags,
-    counter_u64_t *ptr, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_COUNTER_U64_ARRAY(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags,
-    counter_u64_t *ptr, intmax_t
-    len, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_INT(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int *ptr,
-    int val, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_LONG(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, long *ptr,
-    const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_NODE(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int
-    (*handler)(SYSCTL_HANDLER_ARGS), const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_NODE_WITH_LABEL(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, int
-    (*handler)(SYSCTL_HANDLER_ARGS), const char
-    *descr, const char *label);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_OPAQUE(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, void
-    *ptr, intptr_t len, const char
-    *format, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_PROC(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, void *arg1,
-    intptr_t arg2, int (*handler)
-    (SYSCTL_HANDLER_ARGS), const char *format,
-    const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_QUAD(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int64_t *ptr,
-    const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_ROOT_NODE(struct
-    sysctl_ctx_list *ctx, int number,
-    const char *name, int ctlflags,
-    int (*handler)(SYSCTL_HANDLER_ARGS),
-    const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_S8(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int8_t *ptr,
-    int8_t val, const char
-  *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_S16(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int16_t *ptr,
-    int16_t val, const char
-  *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_S32(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int32_t *ptr,
-    int32_t val, const char
-  *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_S64(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, int64_t *ptr,
-    int64_t val, const char
-  *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_SBINTIME_MSEC(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, sbintime_t
-    *ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_SBINTIME_USEC(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, sbintime_t
-    *ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_STRING(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, char
-    *ptr, intptr_t len, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_CONST_STRING(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, const char
-    *ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_STRUCT(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, void
-    *ptr, struct_type, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_TIMEVAL_SEC(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, struct
-    timeval *ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_U8(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, uint8_t *ptr,
-    uint8_t val, const char
-  *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_U16(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, uint16_t *ptr,
-    uint16_t val, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_U32(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, uint32_t *ptr,
-    uint32_t val, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_U64(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, uint64_t *ptr,
-    uint64_t val, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_UINT(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int ctlflags, unsigned int *ptr,
-    unsigned int val, const char
-    *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_ULONG(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, unsigned
-    long *ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_UQUAD(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, uint64_t
-    *ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_UMA_CUR(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, uma_zone_t
-    ptr, const char *descr);

-
struct sysctl_oid *
-  

-  SYSCTL_ADD_UMA_MAX(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, uma_zone_t
-    ptr, const char *descr); const
-    char *descr
-  

-  struct sysctl_oid *
-  

-  SYSCTL_ADD_UAUTO(struct
-    sysctl_ctx_list *ctx, struct sysctl_oid_list
-    *parent, int number, const char
-    *name, int ctlflags, void
-    *ptr, const char *descr);

-
struct sysctl_oid_list *
-  

-  SYSCTL_CHILDREN(struct sysctl_oid
-    *oidp);

-
struct sysctl_oid_list *
-  

-  SYSCTL_STATIC_CHILDREN(struct
-    sysctl_oid_list OID_NAME);

-
struct sysctl_oid_list *
-  

-  SYSCTL_NODE_CHILDREN(parent,
-    name);

-
struct sysctl_oid *
-  

-  SYSCTL_PARENT(struct sysctl_oid
-    *oid);

-
SYSCTL_BOOL(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_COUNTER_U64(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    descr);

-
SYSCTL_COUNTER_U64_ARRAY(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    len,
-    descr);

-
SYSCTL_INT(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_INT_WITH_LABEL(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr,
-    label);

-
SYSCTL_LONG(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
int
-  

-  sysctl_msec_to_ticks(SYSCTL_HANDLER_ARGS);

-
SYSCTL_NODE(parent,
-    number,
-    name,
-    ctlflags,
-    handler,
-    descr);

-
SYSCTL_NODE_WITH_LABEL(parent,
-    number,
-    name,
-    ctlflags,
-    handler,
-    descr,
-    label);

-
SYSCTL_OPAQUE(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    len,
-    format,
-    descr);

-
SYSCTL_PROC(parent,
-    number,
-    name,
-    ctlflags,
-    arg1,
-    arg2,
-    handler,
-    format,
-    descr);

-
SYSCTL_QUAD(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_ROOT_NODE(number,
-    name,
-    ctlflags,
-    handler,
-    descr);

-
SYSCTL_S8(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_S16(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_S32(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_S64(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_SBINTIME_MSEC(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    descr);

-
SYSCTL_SBINTIME_USEC(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    descr);

-
SYSCTL_STRING(parent,
-    number,
-    name,
-    ctlflags,
-    arg,
-    len,
-    descr);

-
SYSCTL_CONST_STRING(parent,
-    number,
-    name,
-    ctlflags,
-    arg,
-    descr);

-
SYSCTL_STRUCT(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    struct_type,
-    descr);

-
SYSCTL_TIMEVAL_SEC(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    descr);

-
SYSCTL_U8(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_U16(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_U32(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_U64(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_UINT(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_ULONG(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_UQUAD(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    val,
-    descr);

-
SYSCTL_UMA_MAX(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    descr);

-
SYSCTL_UMA_CUR(parent,
-    number,
-    name,
-    ctlflags,
-    ptr,
-    descr);

-

-

-

-
The SYSCTL kernel interface allows dynamic
-    or static creation of sysctl(8) MIB entries. All static
-    sysctls are automatically destroyed when the module which they are part of
-    is unloaded. Most top level categories are created statically and are
-    available to all kernel code and its modules.

-

-

-

-

-  
ctx

-  
Pointer to sysctl context or NULL, if no context. See
-      sysctl_ctx_init(9) for how to create a new sysctl
-      context. Programmers are strongly advised to use contexts to organize the
-      dynamic OIDs which they create because when a context is destroyed all
-      belonging sysctls are destroyed as well. This makes the sysctl cleanup
-      code much simpler. Else deletion of all created OIDs is required at module
-      unload.

-  
parent

-  
A pointer to a struct sysctl_oid_list, which is
-      the head of the parent's list of children. This pointer is retrieved using
-      the
-      ()
-      macro for static sysctls and the
-      ()
-      macro for dynamic sysctls. The
-      ()
-      macro can be used to get the parent of an OID. The macro returns NULL if
-      there is no parent.

-  
number

-  
The OID number that will be assigned to this OID. In almost all cases this
-      should be set to OID_AUTO, which will result in
-      the assignment of the next available OID number.

-  
name

-  
The name of the OID. The newly created OID will contain a copy of the
-      name.

-  
ctlflags

-  
A bit mask of sysctl control flags. See the section below describing all
-      the control flags.

-  
arg1

-  
First callback argument for procedure sysctls.

-  
arg2

-  
Second callback argument for procedure sysctls.

-  
len

-  
The length of the data pointed to by the ptr
-      argument. For string type OIDs a length of zero means that
-      strlen(3) will be used to get the length of the string
-      at each access to the OID. For array type OIDs the length must be greater
-      than zero.

-  
ptr

-  
Pointer to sysctl variable or string data. For sysctl values the pointer
-      can be SYSCTL_NULL_XXX_PTR which means the OID is read-only and the
-      returned value should be taken from the val
-      argument.

-  
val

-  
If the ptr argument is SYSCTL_NULL_XXX_PTR, gives
-      the constant value returned by this OID. Else this argument is not
-    used.

-  
struct_type

-  
Name of structure type.

-  
handler

-  
A pointer to the function that is responsible for handling read and write
-      requests to this OID. There are several standard handlers that support
-      operations on nodes, integers, strings and opaque objects. It is possible
-      to define custom handlers using the SYSCTL_PROC()
-      macro or the SYSCTL_ADD_PROC() function.

-  
format

-  
A pointer to a string which specifies the format of the OID in a symbolic
-      way. This format is used as a hint by sysctl(8) to apply
-      proper data formatting for display purposes.
-    
Current formats:

-    

-    

-      

-      
node

-      

-      

-      

-      

-      

-      

-      

-      

-      
[n]

-      
temperature in Kelvin, multiplied by an optional single digit power of
-          ten scaling factor: 1 (default) gives deciKelvin, 0 gives Kelvin, 3
-          gives milliKelvin

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      

-      
 structures

-    

-    

-  

-  
descr

-  
A pointer to a textual description of the OID.

-  
label

-  
A pointer to an aggregation label for this component of the OID. To make
-      it easier to export sysctl data to monitoring systems that support
-      aggregations through labels (e.g., Prometheus), this argument can be used
-      to attach a label name to an OID. The label acts as a hint that this
-      component's name should not be part of the metric's name, but attached to
-      the metric as a label instead.
-    
Labels should only be applied to siblings that are
-        structurally similar and encode the same type of value, as aggregation
-        is of no use otherwise.

-  

-

-

-

-

-
Most of the macros and functions used to create sysctl nodes
-    export a read-only constant or in-kernel variable whose type matches the
-    type of the node's value. For example,
-    ()
-    reports the raw value of an associated variable of type
-    int. However, nodes may also export a value that is a
-    translation of an internal representation.

-
The
-    ()
-    handler can be used with SYSCTL_PROC() or
-    ()
-    to export a millisecond time interval. When using this handler, the
-    arg2 parameter points to an in-kernel variable of type
-    int which stores a tick count suitable for use with
-    functions like tsleep(9). The
-    sysctl_msec_to_ticks() function converts this value
-    to milliseconds when reporting the node's value. Similarly,
-    sysctl_msec_to_ticks() accepts new values in
-    milliseconds and stores an equivalent value in ticks to
-    *arg2. Note that new code should use kernel variables
-    of type sbintime_t instead of tick counts.

-
The
-    ()
-    and
-    ()
-    functions and
-    ()
-    and
-    ()
-    macros all create nodes which export an in-kernel variable of type
-    sbintime_t. These nodes do not export the raw value of
-    the associated variable. Instead, they export a 64-bit integer containing a
-    count of either milliseconds (the MSEC variants) or microseconds (the USEC
-    variants).

-
The
-    ()
-    function and
-    ()
-    macro create nodes which export an in-kernel variable of type
-    struct timeval. These nodes do not export full value
-    of the associated structure. Instead, they export a count in seconds as a
-    simple integer which is stored in the tv_sec field of
-    the associated variable. This function and macro are intended to be used
-    with variables which store a non-negative interval rather than an absolute
-    time. As a result, they reject attempts to store negative values.

-

-

-

-
Sysctl MIBs or OIDs are created in a hierarchical tree. The nodes
-    at the bottom of the tree are called root nodes, and have no parent OID. To
-    create bottom tree nodes the
-    ()
-    macro or the
-    ()
-    function needs to be used. By default all static sysctl node OIDs are global
-    and need a
-    ()
-    statement prior to their
-    ()
-    definition statement, typically in a so-called header file.

-

-

-

-
Zero terminated character strings sysctls are created either using
-    the
-    ()
-    macro or the
-    ()
-    function. If the len argument is zero, the string
-    length is computed at every access to the OID using
-    strlen(3). Use the
-    ()
-    macro or the
-    ()
-    function to add a sysctl for a constant string.

-

-

-

-
The
-    ()
-    or
-    ()
-    macros or the
-    ()
-    or
-    ()
-    functions create an OID that handle any chunk of data of the size specified
-    by the len argument and data pointed to by the
-    ptr argument. When using the structure version the
-    type is encoded as part of the created sysctl.

-

-

-

-
The SYSCTL_PROC() macro and the
-    SYSCTL_ADD_PROC() function create OIDs with the
-    specified handler function. The handler is
-    responsible for handling all read and write requests to the OID. This OID
-    type is especially useful if the kernel data is not easily accessible, or
-    needs to be processed before exporting.

-

-

-

-
Static sysctls are declared using one of the
-    (),
-    (),
-    (),
-    SYSCTL_INT(),
-    (),
-    (),
-    SYSCTL_NODE(),
-    (),
-    SYSCTL_OPAQUE(),
-    SYSCTL_PROC(),
-    (),
-    SYSCTL_ROOT_NODE(),
-    (),
-    (),
-    (),
-    (),
-    SYSCTL_SBINTIME_MSEC(),
-    SYSCTL_SBINTIME_USEC(),
-    SYSCTL_STRING(),
-    SYSCTL_CONST_STRING(),
-    SYSCTL_STRUCT(),
-    SYSCTL_TIMEVAL_SEC(),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    ()
-    or
-    ()
-    macros.

-

-

-

-
Dynamic nodes are created using one of the
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    SYSCTL_ADD_OPAQUE(),
-    SYSCTL_ADD_PROC(),
-    (),
-    SYSCTL_ADD_ROOT_NODE(),
-    (),
-    (),
-    (),
-    (),
-    SYSCTL_ADD_SBINTIME_MSEC(),
-    SYSCTL_ADD_SBINTIME_USEC(),
-    SYSCTL_ADD_STRING(),
-    SYSCTL_ADD_CONST_STRING(),
-    SYSCTL_ADD_STRUCT(),
-    SYSCTL_ADD_TIMEVAL_SEC(),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    (),
-    ()
-    or
-    ()
-    functions. See sysctl_remove_oid(9) or
-    sysctl_ctx_free(9) for more information on how to destroy
-    a dynamically created OID.

-

-

-

-
For most of the above functions and macros, declaring a type as
-    part of the access flags is not necessary — however, when declaring a
-    sysctl implemented by a function, including a type in the access mask is
-    required:

-

-  

-  
This is a node intended to be a parent for other nodes.

-  

-  
This is a signed integer.

-  

-  
This is a nul-terminated string stored in a character array.

-  

-  
This is an 8-bit signed integer.

-  

-  
This is a 16-bit signed integer.

-  

-  
This is a 32-bit signed integer.

-  

-  
This is a 64-bit signed integer.

-  

-  
This is an opaque data structure.

-  

-  
Alias for CTLTYPE_OPAQUE.

-  

-  
This is an 8-bit unsigned integer.

-  

-  
This is a 16-bit unsigned integer.

-  

-  
This is a 32-bit unsigned integer.

-  

-  
This is a 64-bit unsigned integer.

-  

-  
This is an unsigned integer.

-  

-  
This is a signed long.

-  

-  
This is an unsigned long.

-

-
All sysctl types except for new node declarations require one of
-    the following flags to be set indicating the read and write disposition of
-    the sysctl:

-

-  

-  
This is a read-only sysctl.

-  

-  
This is a read-only sysctl and tunable which is fetched once from the
-      system environment early during module load or system boot.

-  

-  
This is a writable sysctl.

-  

-  
This sysctl is readable and writable.

-  

-  
This is a readable and writeable sysctl and tunable which is fetched once
-      from the system environment early during module load or system boot.

-  

-  
In case the node is marked as a tunable using the CTLFLAG_[XX]TUN, this
-      flag will prevent fetching the initial value from the system environment.
-      Typically this flag should only be used for very early low level system
-      setup code, and not by common drivers and modules.

-  

-  
This sysctl(9) handler is MP safe. Do not grab Giant
-      around calls to this handler. This should only be used for
-      ()
-      entries.

-

-
Additionally, any of the following optional flags may also be
-    specified:

-

-  

-  
Any user or process can write to this sysctl.

-  

-  
A process in capability mode can read from this sysctl.

-  

-  
A process in capability mode can write to this sysctl.

-  

-  
This sysctl can be written to only if the effective securelevel of the
-      process is ≤ 0.

-  

-  
This sysctl can be written to by processes in
-    jail(2).

-  

-  
When iterating the sysctl name space, do not list this sysctl.

-  

-  
Advisory flag that a system tunable also exists for this variable. The
-      initial sysctl value is fetched once from the system environment early
-      during module load or system boot.

-  

-  
Dynamically created OIDs automatically get this flag set.

-  

-  
OID references a VIMAGE-enabled variable.

-

-

-

-

-
Sample use of SYSCTL_DECL() to declare the
-    security sysctl tree for use by new nodes:

-

-
SYSCTL_DECL(_security);

-

-
Examples of integer, opaque, string, and procedure sysctls
-  follow:

-

-
/*
- * Example of a constant integer value.  Notice that the control
- * flags are CTLFLAG_RD, the variable pointer is SYSCTL_NULL_INT_PTR,
- * and the value is declared.
- */
-SYSCTL_INT(_kern, OID_AUTO, hz_max, CTLFLAG_RD, SYSCTL_NULL_INT_PTR, HZ_MAXIMUM,
-    "Maximum hz value supported");
-
-/*
- * Example of a variable integer value.  Notice that the control
- * flags are CTLFLAG_RW, the variable pointer is set, and the
- * value is 0.
- */
-static int	doingcache = 1;		/* 1 => enable the cache */
-SYSCTL_INT(_debug, OID_AUTO, vfscache, CTLFLAG_RW, &doingcache, 0,
-    "Enable name cache");
-
-/*
- * Example of a variable string value.  Notice that the control
- * flags are CTLFLAG_RW, that the variable pointer and string
- * size are set.  Unlike newer sysctls, this older sysctl uses a
- * static oid number.
- */
-char kernelname[MAXPATHLEN] = "/kernel";	/* XXX bloat */
-SYSCTL_STRING(_kern, KERN_BOOTFILE, bootfile, CTLFLAG_RW,
-    kernelname, sizeof(kernelname), "Name of kernel file booted");
-
-/*
- * Example of an opaque data type exported by sysctl.  Notice that
- * the variable pointer and size are provided, as well as a format
- * string for sysctl(8).
- */
-static l_fp pps_freq;	/* scaled frequency offset (ns/s) */
-SYSCTL_OPAQUE(_kern_ntp_pll, OID_AUTO, pps_freq, CTLFLAG_RD,
-    &pps_freq, sizeof(pps_freq), "I", "");
-
-/*
- * Example of a procedure based sysctl exporting string
- * information.  Notice that the data type is declared, the NULL
- * variable pointer and 0 size, the function pointer, and the
- * format string for sysctl(8).
- */
-SYSCTL_PROC(_kern_timecounter, OID_AUTO, hardware, CTLTYPE_STRING |
-    CTLFLAG_RW, NULL, 0, sysctl_kern_timecounter_hardware, "A",
-    "");

-

-
The following is an example of how to create a new top-level
-    category and how to hook up another subtree to an existing static node. This
-    example does not use contexts, which results in tedious management of all
-    intermediate oids, as they need to be freed later on:

-

-
#include <sys/sysctl.h>
- ...
-/*
- * Need to preserve pointers to newly created subtrees,
- * to be able to free them later:
- */
-static struct sysctl_oid *root1;
-static struct sysctl_oid *root2;
-static struct sysctl_oid *oidp;
-static int a_int;
-static char *string = "dynamic sysctl";
- ...
-
-root1 = SYSCTL_ADD_ROOT_NODE(NULL,
-	OID_AUTO, "newtree", CTLFLAG_RW, 0, "new top level tree");
-oidp = SYSCTL_ADD_INT(NULL, SYSCTL_CHILDREN(root1),
-	OID_AUTO, "newint", CTLFLAG_RW, &a_int, 0, "new int leaf");
- ...
-root2 = SYSCTL_ADD_NODE(NULL, SYSCTL_STATIC_CHILDREN(_debug),
-	OID_AUTO, "newtree", CTLFLAG_RW, 0, "new tree under debug");
-oidp = SYSCTL_ADD_STRING(NULL, SYSCTL_CHILDREN(root2),
-	OID_AUTO, "newstring", CTLFLAG_RD, string, 0, "new string leaf");

-

-
This example creates the following subtrees:

-

-
debug.newtree.newstring
-newtree.newint

-

-

-

-

-

-
When adding, modifying, or removing sysctl names, it is important
-    to be aware that these interfaces may be used by users, libraries,
-    applications, or documentation (such as published books), and are implicitly
-    published application interfaces. As with other application interfaces,
-    caution must be taken not to break existing applications, and to think about
-    future use of new name spaces so as to avoid the need to rename or remove
-    interfaces that might be depended on in the future.

-
The semantics chosen for a new sysctl should be as clear as
-    possible, and the name of the sysctl must closely reflect its semantics.
-    Therefore the sysctl name deserves a fair amount of consideration. It should
-    be short but yet representative of the sysctl meaning. If the name consists
-    of several words, they should be separated by underscore characters, as in
-    compute_summary_at_mount. Underscore characters may be
-    omitted only if the name consists of not more than two words, each being not
-    longer than four characters, as in bootfile.

-
For boolean sysctls, negative logic should be totally avoided.
-    That is, do not use names like no_foobar or
-    foobar_disable. They are confusing and lead to
-    configuration errors. Use positive logic instead:
-    foobar, foobar_enable.

-
A temporary sysctl node OID that should not be relied upon must be
-    designated as such by a leading underscore character in its name. For
-    example: _dirty_hack.

-

-

-

-
sysctl(3), sysctl(8),
-    device_get_sysctl(9), sysctl_add_oid(9),
-    sysctl_ctx_free(9), sysctl_ctx_init(9),
-    sysctl_remove_oid(9)

-

-

-

-
The sysctl(8) utility first appeared in
-    4.4BSD.
-    SYSCTL_ADD_CONST_STRING first appeared in
-    FreeBSD 12.1.

-

-

-

-
The sysctl implementation originally found
-    in BSD has been extensively rewritten by
-    Poul-Henning Kamp in order to add support for name
-    lookups, name space iteration, and dynamic addition of MIB nodes.

-
This man page was written by Robert N. M.
-    Watson.

-

-

-

-
When creating new sysctls, careful attention should be paid to the
-    security implications of the monitoring or management interface being
-    created. Most sysctls present in the kernel are read-only or writable only
-    by the superuser. Sysctls exporting extensive information on system data
-    structures and operation, especially those implemented using procedures,
-    will wish to implement access control to limit the undesired exposure of
-    information about other processes, network connections, etc.

-
The following top level sysctl name spaces are commonly used:

-

-  
compat

-  
Compatibility layer information.

-  
debug

-  
Debugging information. Various name spaces exist under
-      debug.

-  
hw

-  
Hardware and device driver information.

-  
kern

-  
Kernel behavior tuning; generally deprecated in favor of more specific
-      name spaces.

-  
machdep

-  
Machine-dependent configuration parameters.

-  
net

-  
Network subsystem. Various protocols have name spaces under
-      net.

-  
regression

-  
Regression test configuration and information.

-  
security

-  
Security and security-policy configuration and information.

-  
sysctl

-  
Reserved name space for the implementation of sysctl.

-  
user

-  
Configuration settings relating to user application behavior. Generally,
-      configuring applications using kernel sysctls is discouraged.

-  
vfs

-  
Virtual file system configuration and information.

-  
vm

-  
Virtual memory subsystem configuration and information.

-

-

-

-
-  
-    
-    
-  
-
September 28, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/sysctl_add_oid.9 3.html b/static/freebsd/man9/sysctl_add_oid.9 3.html
deleted file mode 100644
index a47cb3ce..00000000
--- a/static/freebsd/man9/sysctl_add_oid.9 3.html	
+++ /dev/null
@@ -1,151 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSCTL_ADD_OID(9)Kernel Developer's ManualSYSCTL_ADD_OID(9)

-

-

-

-
sysctl_add_oid,
-    sysctl_move_oid,
-    sysctl_remove_oid,
-    sysctl_remove_name — runtime
-    sysctl tree manipulation

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/sysctl.h>

-
struct sysctl_oid *
-  

-  sysctl_add_oid(struct sysctl_ctx_list
-    *ctx, struct sysctl_oid_list *parent,
-    int number, const char *name,
-    int kind, void *arg1,
-    intmax_t arg2, int (*handler)
-    (SYSCTL_HANDLER_ARGS), const char *format,
-    const char *descr, const char
-    *label);

-
int
-  

-  sysctl_move_oid(struct sysctl_oid
-    *oidp, struct sysctl_oid_list *parent);

-
int
-  

-  sysctl_remove_oid(struct sysctl_oid
-    *oidp, int del, int
-    recurse);

-
int
-  

-  sysctl_remove_name(struct sysctl_oid
-    *oidp, const char *name, int
-    del, int recurse);

-

-

-

-
These functions provide the interface for creating and deleting
-    sysctl OIDs at runtime for example during the lifetime of a module. The
-    wrapper macros defined by sysctl(9) are recommended when
-    creating new OIDs.
-    ()
-    should not be called directly from the code.

-
Dynamic OIDs of type CTLTYPE_NODE are
-    reusable so that several code sections can create and delete them, but in
-    reality they are allocated and freed based on their reference count. As a
-    consequence, it is possible for two or more code sections to create
-    partially overlapping trees that they both can use. It is not possible to
-    create overlapping leaves, nor to create different child types with the same
-    name and parent.

-
The
-    ()
-    function creates a raw OID of any type and connects it to its parent node,
-    if any. If the OID is successfully created, the function returns a pointer
-    to it else it returns NULL. Many of the arguments
-    for sysctl_add_oid() are common to the wrapper
-    macros defined by sysctl(9).

-
The
-    ()
-    function reparents an existing OID. The OID is assigned a new number as if
-    it had been created with number set to
-    OID_AUTO.

-
The
-    ()
-    function removes a dynamically created OID from the tree and optionally
-    freeing its resources. It takes the following arguments:

-

-  
oidp

-  
A pointer to the dynamic OID to be removed. If the OID is not dynamic, or
-      the pointer is NULL, the function returns
-      EINVAL.

-  
del

-  
If non-zero, sysctl_remove_oid() will try to free
-      the OID's resources when the reference count of the OID becomes zero.
-      However, if del is set to 0, the routine will only
-      deregister the OID from the tree, without freeing its resources. This
-      behaviour is useful when the caller expects to rollback (possibly
-      partially failed) deletion of many OIDs later.

-  
recurse

-  
If non-zero, attempt to remove the node and all its children. If
-      recurse is set to 0, any attempt to remove a node
-      that contains any children will result in a
-      ENOTEMPTY error.
-      :
-      ! Normally it should not be needed if
-      contexts are used. Contexts take care of tracking inter-dependencies
-      between users of the tree. However, in some extreme cases it might be
-      necessary to remove part of the subtree no matter how it was created, in
-      order to free some other resources. Be aware, though, that this may result
-      in a system panic(9) if other code sections continue to
-      use removed subtrees.

-

-
The
-    ()
-    function looks up the child node matching the name
-    argument and then invokes the sysctl_remove_oid()
-    function on that node, passing along the del and
-    recurse arguments. If a node having the specified name
-    does not exist an error code of ENOENT is returned.
-    Else the error code from sysctl_remove_oid() is
-    returned.

-
In most cases the programmer should use contexts, as described in
-    sysctl_ctx_init(9), to keep track of created OIDs, and to
-    delete them later in orderly fashion.

-

-

-

-
sysctl(8), sysctl(9),
-    sysctl_ctx_free(9),
-  sysctl_ctx_init(9)

-

-

-

-
These functions first appeared in FreeBSD
-    4.2.

-

-

-

-
Andrzej Bialecki
-    <abial@FreeBSD.org>

-

-

-

-
Sharing nodes between many code sections causes interdependencies
-    that sometimes may lock the resources. For example, if module A hooks up a
-    subtree to an OID created by module B, module B will be unable to delete
-    that OID. These issues are handled properly by sysctl contexts.

-
Many operations on the tree involve traversing linked lists. For
-    this reason, OID creation and removal is relatively costly.

-

-

-
-  
-    
-    
-  
-
December 13, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/sysctl_ctx_init.9 3.html b/static/freebsd/man9/sysctl_ctx_init.9 3.html
deleted file mode 100644
index 6d96ac48..00000000
--- a/static/freebsd/man9/sysctl_ctx_init.9 3.html	
+++ /dev/null
@@ -1,200 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSCTL_CTX_INIT(9)Kernel Developer's ManualSYSCTL_CTX_INIT(9)

-

-

-

-
sysctl_ctx_init,
-    sysctl_ctx_free,
-    sysctl_ctx_entry_add,
-    sysctl_ctx_entry_find,
-    sysctl_ctx_entry_del —
-    sysctl context for managing dynamically created sysctl
-    OIDs

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/sysctl.h>

-
int
-  

-  sysctl_ctx_init(struct sysctl_ctx_list
-    *clist);

-
int
-  

-  sysctl_ctx_free(struct sysctl_ctx_list
-    *clist);

-
struct sysctl_ctx_entry *
-  

-  sysctl_ctx_entry_add(struct
-    sysctl_ctx_list *clist, struct sysctl_oid
-    *oidp);

-
struct sysctl_ctx_entry *
-  

-  sysctl_ctx_entry_find(struct
-    sysctl_ctx_list *clist, struct sysctl_oid
-    *oidp);

-
int
-  

-  sysctl_ctx_entry_del(struct
-    sysctl_ctx_list *clist, struct sysctl_oid
-    *oidp);

-

-

-

-
These functions provide an interface for managing dynamically
-    created OIDs. The sysctl context is responsible for keeping track of created
-    OIDs, as well as their proper removal when needed. It adds a simple
-    transactional aspect to OID removal operations; i.e., if a removal operation
-    fails part way, it is possible to roll back the sysctl tree to its previous
-    state.

-
The
-    ()
-    function initializes a sysctl context. The clist
-    argument must point to an already allocated variable. A context
-     be
-    initialized before use. Once it is initialized, a pointer to the context can
-    be passed as an argument to all the SYSCTL_ADD_*
-    macros (see sysctl_add_oid(9)), and it will be updated
-    with entries pointing to newly created OIDS.

-
Internally, the context is represented as a
-    queue(3) TAILQ linked list. The list consists of
-    struct sysctl_ctx_entry entries:

-

-
struct sysctl_ctx_entry {
-	struct sysctl_oid *entry;
-	TAILQ_ENTRY(sysctl_ctx_entry) link;
-};
-
-TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry);

-

-
Each context entry points to one dynamic OID that it manages.
-    Newly created OIDs are always inserted in the front of the list.

-
The
-    ()
-    function removes the context and associated OIDs it manages. If the function
-    completes successfully, all managed OIDs have been unregistered (removed
-    from the tree) and freed, together with all their allocated memory, and the
-    entries of the context have been freed as well.

-
The removal operation is performed in two
-    steps. First, for each context entry, the function
-    sysctl_remove_oid(9) is executed, with parameter
-    del set to 0, which inhibits the freeing of resources.
-    If there are no errors during this step,
-    ()
-    proceeds to the next step. If the first step fails, all unregistered OIDs
-    associated with the context are registered again.

-
:
-    in most cases, the programmer specifies OID_AUTO as
-    the OID number when creating an OID. However, during registration of the OID
-    in the tree, this number is changed to the first available number greater
-    than or equal to CTL_AUTO_START. If the first step
-    of context deletion fails, re-registration of the OID does not change the
-    already assigned OID number (which is different from OID_AUTO). This ensures
-    that re-registered entries maintain their original positions in the
-  tree.

-
The second step actually performs the deletion of the dynamic
-    OIDs. sysctl_remove_oid(9) iterates through the context
-    list, starting from beginning (i.e., the newest entries).
-    Important: this time, the function not only deletes the
-    OIDs from the tree, but also frees their memory (provided that oid_refcnt ==
-    0), as well as the memory of all context entries.

-
The
-    ()
-    function allows the addition of an existing dynamic OID to a context.

-
The
-    ()
-    function removes an entry from the context. Important: in
-    this case, only the corresponding struct
-    sysctl_ctx_entry is freed, but the oidp pointer
-    remains intact. Thereafter, the programmer is responsible for managing the
-    resources allocated to this OID.

-
The
-    ()
-    function searches for a given oidp within a context
-    list, either returning a pointer to the struct
-    sysctl_ctx_entry found, or NULL.

-

-

-

-
The following is an example of how to create a new top-level
-    category and how to hook up another subtree to an existing static node. This
-    example uses contexts to keep track of the OIDs.

-

-
#include <sys/sysctl.h>
- ...
-static struct sysctl_ctx_list clist;
-static struct sysctl_oid *oidp;
-static int a_int;
-static const char *string = "dynamic sysctl";
- ...
-
-sysctl_ctx_init(&clist);
-oidp = SYSCTL_ADD_ROOT_NODE(&clist,
-	OID_AUTO, "newtree", CTLFLAG_RW, 0, "new top level tree");
-oidp = SYSCTL_ADD_INT(&clist, SYSCTL_CHILDREN(oidp),
-	OID_AUTO, "newint", CTLFLAG_RW, &a_int, 0, "new int leaf");
- ...
-oidp = SYSCTL_ADD_NODE(&clist, SYSCTL_STATIC_CHILDREN(_debug),
-	OID_AUTO, "newtree", CTLFLAG_RW, 0, "new tree under debug");
-oidp = SYSCTL_ADD_STRING(&clist, SYSCTL_CHILDREN(oidp),
-	OID_AUTO, "newstring", CTLFLAG_RD, string, 0, "new string leaf");
- ...
-/* Now we can free up the OIDs */
-if (sysctl_ctx_free(&clist)) {
-	printf("can't free this context - other OIDs depend on it");
-	return (ENOTEMPTY);
-} else {
-	printf("Success!\n");
-	return (0);
-}

-

-
This example creates the following subtrees:

-

-
debug.newtree.newstring
-newtree.newint

-

-
Note that both trees are removed, and their resources freed,
-    through one sysctl_ctx_free() call, which starts by
-    freeing the newest entries (leaves) and then proceeds to free the older
-    entries (in this case the nodes).

-

-

-

-
queue(3), sysctl(8),
-    sysctl(9), sysctl_add_oid(9),
-    sysctl_remove_oid(9)

-

-

-

-
These functions first appeared in FreeBSD
-    4.2.

-

-

-

-
Andrzej Bialecki
-    <abial@FreeBSD.org>

-

-

-

-
The current removal algorithm is somewhat heavy. In the worst
-    case, all OIDs need to be unregistered, registered again, and then
-    unregistered and deleted. However, the algorithm does guarantee
-    transactional properties for removal operations.

-
All operations on contexts involve linked list traversal. For this
-    reason, creation and removal of entries is relatively costly.

-

-

-
-  
-    
-    
-  
-
July 31, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/taskqueue.9 4.html b/static/freebsd/man9/taskqueue.9 4.html
deleted file mode 100644
index d9c314ee..00000000
--- a/static/freebsd/man9/taskqueue.9 4.html	
+++ /dev/null
@@ -1,494 +0,0 @@
-
-  
-    
-    
-    
-  
-
TASKQUEUE(9)Kernel Developer's ManualTASKQUEUE(9)

-

-

-

-
taskqueue —
-    asynchronous task execution

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/malloc.h>
-  

-  #include <sys/queue.h>
-  

-  #include <sys/taskqueue.h>

-

-
typedef void (*task_fn_t)(void *context, int pending);
-
-typedef void (*taskqueue_enqueue_fn)(void *context);
-
-struct task {
-	STAILQ_ENTRY(task)	ta_link;	/* link for queue */
-	u_short			ta_pending;	/* count times queued */
-	u_short			ta_priority;	/* priority of task in queue */
-	task_fn_t		ta_func;	/* task handler */
-	void			*ta_context;	/* argument for handler */
-};
-
-enum taskqueue_callback_type {
-	TASKQUEUE_CALLBACK_TYPE_INIT,
-	TASKQUEUE_CALLBACK_TYPE_SHUTDOWN,
-};
-
-typedef void (*taskqueue_callback_fn)(void *context);
-
-struct timeout_task;

-

-

-struct taskqueue *
-

-taskqueue_create(const
-  char *name, int
-  mflags,
-  taskqueue_enqueue_fn
-  enqueue, void
-  *context);
-
struct taskqueue *
-  

-  taskqueue_create_fast(const
-    char *name, int
-    mflags,
-    taskqueue_enqueue_fn
-    enqueue, void
-    *context);

-
int
-  

-  taskqueue_start_threads(struct
-    taskqueue **tqp, int
-    count, int pri,
-    const char *name,
-    ...);

-
int
-  

-  taskqueue_start_threads_cpuset(struct
-    taskqueue **tqp, int count, int
-    pri, cpuset_t *mask, const char
-    *name, ...);

-
int
-  

-  taskqueue_start_threads_in_proc(struct
-    taskqueue **tqp, int count, int
-    pri, struct proc *proc, const
-    char *name, ...);

-
void
-  

-  taskqueue_set_callback(struct
-    taskqueue *queue, enum
-    taskqueue_callback_type cb_type,
-    taskqueue_callback_fn
-    callback, void
-    *context);

-
void
-  

-  taskqueue_free(struct
-    taskqueue *queue);

-
int
-  

-  taskqueue_enqueue(struct
-    taskqueue *queue, struct
-    task *task);

-
int
-  

-  taskqueue_enqueue_flags(struct
-    taskqueue *queue, struct
-    task *task, int
-    flags);

-
int
-  

-  taskqueue_enqueue_timeout(struct
-    taskqueue *queue, struct
-    timeout_task *timeout_task,
-    int ticks);

-
int
-  

-  taskqueue_enqueue_timeout_sbt(struct
-    taskqueue *queue, struct
-    timeout_task *timeout_task,
-    sbintime_t sbt,
-    sbintime_t pr,
-    int flags);

-
int
-  

-  taskqueue_cancel(struct
-    taskqueue *queue, struct
-    task *task, u_int
-    *pendp);

-
int
-  

-  taskqueue_cancel_timeout(struct
-    taskqueue *queue, struct
-    timeout_task *timeout_task,
-    u_int *pendp);

-
void
-  

-  taskqueue_drain(struct
-    taskqueue *queue, struct
-    task *task);

-
void
-  

-  taskqueue_drain_timeout(struct
-    taskqueue *queue, struct
-    timeout_task *timeout_task);

-
void
-  

-  taskqueue_drain_all(struct
-    taskqueue *queue);

-
void
-  

-  taskqueue_quiesce(struct
-    taskqueue *queue);

-
void
-  

-  taskqueue_block(struct
-    taskqueue *queue);

-
void
-  

-  taskqueue_unblock(struct
-    taskqueue *queue);

-
int
-  

-  taskqueue_member(struct
-    taskqueue *queue, struct
-    thread *td);

-
void
-  

-  taskqueue_run(struct
-    taskqueue *queue);

-
TASK_INIT(struct
-    task *task, int
-    priority, task_fn_t
-    func, void
-    *context);

-
TASK_INITIALIZER(int
-    priority, task_fn_t
-    func, void
-    *context);

-
TASKQUEUE_DECLARE(name);

-
TASKQUEUE_DEFINE(name,
-    taskqueue_enqueue_fn
-    enqueue, void
-    *context,
-  init);

-
TASKQUEUE_FAST_DEFINE(name,
-    taskqueue_enqueue_fn
-    enqueue, void
-    *context,
-  init);

-
TASKQUEUE_DEFINE_THREAD(name);

-
TASKQUEUE_FAST_DEFINE_THREAD(name);

-
TIMEOUT_TASK_INIT(struct
-    taskqueue *queue, struct
-    timeout_task *timeout_task,
-    int priority,
-    task_fn_t func,
-    void *context);

-

-

-

-
These functions provide a simple interface for asynchronous
-    execution of code.

-
The function
-    ()
-    is used to create new queues. The arguments to
-    taskqueue_create() include a name that should be
-    unique, a set of malloc(9) flags that specify whether the
-    call to
-    ()
-    is allowed to sleep, a function that is called from
-    taskqueue_enqueue() when a task is added to the
-    queue, and a pointer to the memory location where the identity of the thread
-    that services the queue is recorded. The function called from
-    taskqueue_enqueue() must arrange for the queue to be
-    processed (for instance by scheduling a software interrupt or waking a
-    kernel thread). The memory location where the thread identity is recorded is
-    used to signal the service thread(s) to terminate--when this value is set to
-    zero and the thread is signaled it will terminate. If the queue is intended
-    for use in fast interrupt handlers
-    taskqueue_create_fast() should be used in place of
-    taskqueue_create().

-
The function
-    ()
-    should be used to free the memory used by the queue. Any tasks that are on
-    the queue will be executed at this time after which the thread servicing the
-    queue will be signaled that it should exit.

-
Once a taskqueue has been created,
-    its threads should be started using
-    (),
-    ()
-    or
-    ().
-    taskqueue_start_threads_cpuset() takes a
-    cpuset argument which will cause the threads which are
-    started for the taskqueue to be restricted to run on the given CPUs.
-    taskqueue_start_threads_in_proc() takes a
-    proc argument which will cause the threads which are
-    started for the taskqueue to be assigned to the given kernel process.
-    Callbacks may optionally be registered using
-    ().
-    Currently, callbacks may be registered for the following purposes:

-

-  

-  
This callback is called by every thread in the taskqueue, before it
-      executes any tasks. This callback must be set before the taskqueue's
-      threads are started.

-  

-  
This callback is called by every thread in the taskqueue, after it
-      executes its last task. This callback will always be called before the
-      taskqueue structure is reclaimed.

-

-
To add a task to the list of tasks queued
-    on a taskqueue, call
-    ()
-    with pointers to the queue and task. If the task's
-    ta_pending field is non-zero, then it is simply
-    incremented to reflect the number of times the task was enqueued, up to a
-    cap of USHRT_MAX. Otherwise, the task is added to the list before the first
-    task which has a lower ta_priority value or at the end
-    of the list if no tasks have a lower priority. Enqueueing a task does not
-    perform any memory allocation which makes it suitable for calling from an
-    interrupt handler. This function will return EPIPE
-    if the queue is being freed.

-
When a task is executed, first it is
-    removed from the queue, the value of ta_pending is
-    recorded and then the field is zeroed. The function
-    ta_func from the task structure is called with the
-    value of the field ta_context as its first argument
-    and the value of ta_pending as its second argument.
-    After the function ta_func returns,
-    wakeup(9) is called on the task pointer passed to
-    ().

-
The
-    ()
-    accepts an extra flags parameter which specifies a set
-    of optional flags to alter the behavior of
-    taskqueue_enqueue(). It contains one or more of the
-    following flags:

-

-  

-  
taskqueue_enqueue_flags() fails if the task is
-      already scheduled for execution. EEXIST is
-      returned and the ta_pending counter value remains
-      unchanged.

-  

-  
taskqueue_enqueue_flags() fails if the task is in
-      the canceling state and ECANCELED is
-    returned.

-

-
The
-    ()
-    function is used to schedule the enqueue after the specified number of
-    ticks. The
-    ()
-    function provides finer control over the scheduling based on
-    sbt, pr, and
-    flags, as detailed in callout(9). If
-    the ticks argument is negative, the already scheduled
-    enqueueing is not re-scheduled. Otherwise, the task is scheduled for
-    enqueueing in the future, after the absolute value of
-    ticks is passed. This function returns -1 if the task
-    is being drained. Otherwise, the number of pending calls is returned.

-
The
-    ()
-    function is used to cancel a task. The ta_pending
-    count is cleared, and the old value returned in the reference parameter
-    pendp, if it is non-NULL. If
-    the task is currently running, EBUSY is returned,
-    otherwise 0. To implement a blocking
-    taskqueue_cancel() that waits for a running task to
-    finish, it could look like:

-

-
while (taskqueue_cancel(tq, task, NULL) != 0)
-	taskqueue_drain(tq, task);

-

-
Note that, as with
-    (),
-    the caller is responsible for ensuring that the task is not re-enqueued
-    after being canceled.

-
Similarly, the
-    ()
-    function is used to cancel the scheduled task execution.

-
The
-    ()
-    function is used to wait for the task to finish, and the
-    ()
-    function is used to wait for the scheduled task to finish. There is no
-    guarantee that the task will not be enqueued after call to
-    taskqueue_drain(). If the caller wants to put the
-    task into a known state, then before calling
-    taskqueue_drain() the caller should use out-of-band
-    means to ensure that the task would not be enqueued. For example, if the
-    task is enqueued by an interrupt filter, then the interrupt could be
-    disabled.

-
The
-    ()
-    function is used to wait for all pending and running tasks that are enqueued
-    on the taskqueue to finish. Tasks posted to the taskqueue after
-    taskqueue_drain_all() begins processing, including
-    pending enqueues scheduled by a previous call to
-    taskqueue_enqueue_timeout(), do not extend the wait
-    time of taskqueue_drain_all() and may complete after
-    taskqueue_drain_all() returns. The
-    ()
-    function is used to wait for the queue to become empty and for all running
-    tasks to finish. To avoid blocking indefinitely, the caller must ensure by
-    some mechanism that tasks will eventually stop being posted to the
-  queue.

-
The
-    ()
-    function blocks the taskqueue. It prevents any enqueued but not running
-    tasks from being executed. Future calls to
-    taskqueue_enqueue() will enqueue tasks, but the
-    tasks will not be run until taskqueue_unblock() is
-    called. Please note that taskqueue_block() does not
-    wait for any currently running tasks to finish. Thus, the
-    taskqueue_block() does not provide a guarantee that
-    taskqueue_run() is not running after
-    taskqueue_block() returns, but it does provide a
-    guarantee that taskqueue_run() will not be called
-    again until taskqueue_unblock() is called. If the
-    caller requires a guarantee that taskqueue_run() is
-    not running, then this must be arranged by the caller. Note that if
-    taskqueue_drain() is called on a task that is
-    enqueued on a taskqueue that is blocked by
-    taskqueue_block(), then
-    taskqueue_drain() can not return until the taskqueue
-    is unblocked. This can result in a deadlock if the thread blocked in
-    taskqueue_drain() is the thread that is supposed to
-    call taskqueue_unblock(). Thus, use of
-    taskqueue_drain() after
-    taskqueue_block() is discouraged, because the state
-    of the task can not be known in advance. The same caveat applies to
-    taskqueue_drain_all().

-
The
-    ()
-    function unblocks the previously blocked taskqueue. All enqueued tasks can
-    be run after this call.

-
The
-    ()
-    function returns 1 if the given thread
-    td is part of the given taskqueue
-    queue and 0 otherwise.

-
The
-    ()
-    function will run all pending tasks in the specified
-    queue. Normally this function is only used
-  internally.

-
A convenience macro,
-    (task,
-    priority, func,
-    context) is provided to initialise a
-    task structure. The
-    ()
-    macro generates an initializer for a task structure. A macro
-    (queue,
-    timeout_task, priority,
-    func, context) initializes the
-    timeout_task structure. The values of
-    priority, func, and
-    context are simply copied into the task structure
-    fields and the ta_pending field is cleared.

-
Five macros
-    (name),
-    (name,
-    enqueue, context,
-    init),
-    TASKQUEUE_FAST_DEFINE(name,
-    enqueue, context,
-    init), and
-    TASKQUEUE_DEFINE_THREAD(name)
-    TASKQUEUE_FAST_DEFINE_THREAD(name)
-    are used to declare a reference to a global queue, to define the
-    implementation of the queue, and declare a queue that uses its own thread.
-    The TASKQUEUE_DEFINE() macro arranges to call
-    taskqueue_create() with the values of its
-    name, enqueue and
-    context arguments during system initialisation. After
-    calling taskqueue_create(), the
-    init argument to the macro is executed as a C
-    statement, allowing any further initialisation to be performed (such as
-    registering an interrupt handler, etc.).

-
The
-    ()
-    macro defines a new taskqueue with its own kernel thread to serve tasks. The
-    variable struct taskqueue *taskqueue_name is used to
-    enqueue tasks onto the queue.

-
()
-    and
-    ()
-    act just like TASKQUEUE_DEFINE() and
-    TASKQUEUE_DEFINE_THREAD() respectively but taskqueue
-    is created with
-    ().

-

-

-
The system provides four global taskqueues,
-    taskqueue_fast, taskqueue_swi,
-    taskqueue_swi_giant, and
-    taskqueue_thread. The
-    taskqueue_fast queue is for swi handlers dispatched
-    from fast interrupt handlers, where sleep mutexes cannot be used. The swi
-    taskqueues are run via a software interrupt mechanism. The
-    taskqueue_swi queue runs without the protection of the
-    Giant kernel lock, and the
-    taskqueue_swi_giant queue runs with the protection of
-    the Giant kernel lock. The thread taskqueue
-    taskqueue_thread runs in a kernel thread context, and
-    tasks run from this thread do not run under the Giant
-    kernel lock. If the caller wants to run under Giant,
-    he should explicitly acquire and release Giant in his
-    taskqueue handler routine.

-
To use these queues, call
-    ()
-    with the value of the global taskqueue variable for the queue you wish to
-    use.

-
The software interrupt queues can be used, for instance, for
-    implementing interrupt handlers which must perform a significant amount of
-    processing in the handler. The hardware interrupt handler would perform
-    minimal processing of the interrupt and then enqueue a task to finish the
-    work. This reduces to a minimum the amount of time spent with interrupts
-    disabled.

-
The thread queue can be used, for instance, by interrupt level
-    routines that need to call kernel functions that do things that can only be
-    done from a thread context. (e.g., call malloc with the M_WAITOK flag.)

-
Note that tasks queued on shared taskqueues such as
-    taskqueue_swi may be delayed an indeterminate amount
-    of time before execution. If queueing delays cannot be tolerated then a
-    private taskqueue should be created with a dedicated processing thread.

-

-

-

-

-
callout(9), intr_event(9),
-    kthread(9), swi(9)

-

-

-

-
This interface first appeared in FreeBSD
-    5.0. There is a similar facility called work_queue in the Linux
-    kernel.

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
April 25, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/tcp_functions.9 3.html b/static/freebsd/man9/tcp_functions.9 3.html
deleted file mode 100644
index a75f8a1f..00000000
--- a/static/freebsd/man9/tcp_functions.9 3.html	
+++ /dev/null
@@ -1,316 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCP_FUNCTIONS(9)Kernel Developer's ManualTCP_FUNCTIONS(9)

-

-

-

-
tcp_functions —
-    Alternate TCP Stack Framework

-

-

-

-
#include
-    <netinet/tcp.h>
-  

-  #include
-  <netinet/tcp_var.h>

-
int
-  

-  register_tcp_functions(struct
-    tcp_function_block *blk,
-    int wait);

-
int
-  

-  register_tcp_functions_as_name(struct
-    tcp_function_block *blk,
-    const char *name,
-    int wait);

-
int
-  

-  register_tcp_functions_as_names(struct
-    tcp_function_block *blk,
-    int wait,
-    const char *names[],
-    int *num_names);

-
int
-  

-  deregister_tcp_functions(struct
-    tcp_function_block *blk);

-

-

-

-
The tcp_functions framework allows a
-    kernel developer to implement alternate TCP stacks. The alternate stacks can
-    be compiled in the kernel or can be implemented in loadable kernel modules.
-    This functionality is intended to encourage experimentation with the TCP
-    stack and to allow alternate behaviors to be deployed for different TCP
-    connections on a single system.

-
A system administrator can set a system default stack. By default,
-    all TCP connections will use the system default stack. Additionally, users
-    can specify a particular stack to use on a per-connection basis. (See
-    tcp(4) for details on setting the system default stack, or
-    selecting a specific stack for a given connection.)

-
This man page treats "TCP stacks" as synonymous with
-    "function blocks". This is intentional. A "TCP stack" is
-    a collection of functions that implement a set of behavior. Therefore, an
-    alternate "function block" defines an alternate "TCP
-    stack".

-
The
-    (),
-    register_tcp_functions_as_name(), and
-    register_tcp_functions_as_names() functions request
-    that the system add a specified function block and register it for use with
-    a given name. Modules may register the same function block multiple times
-    with different names. However, names must be globally unique among all
-    registered function blocks. Also, modules may not ever modify the contents
-    of the function block (including the name) after it has been registered,
-    unless the module first successfully de-registers the function block.

-
The
-    ()
-    function requests that the system register the function block with the name
-    defined in the function block's tfb_tcp_block_name
-    field. Note that this is the only one of the three registration functions
-    that automatically registers the function block using the name defined in
-    the function block's tfb_tcp_block_name field. If a
-    module uses one of the other registration functions, it may request that the
-    system register the function block using the name defined in the function
-    block's tfb_tcp_block_name field by explicitly
-    providing that name.

-
The
-    ()
-    function requests that the system register the function block with the name
-    provided in the name argument.

-
The
-    ()
-    function requests that the system register the function block with all the
-    names provided in the names argument. The
-    num_names argument provides a pointer to the number of
-    names. This number must not exceed TCP_FUNCTION_NAME_NUM_MAX. This function
-    will either succeed in registering all of the names in the array, or none of
-    the names in the array. On failure, the num_names
-    argument is updated with the index number of the entry in the
-    names array which the system was processing when it
-    encountered the error.

-
The
-    ()
-    function requests that the system remove a specified function block from the
-    system. If this call succeeds, it will completely deregister the function
-    block, regardless of the number of names used to register the function
-    block. If the call fails because sockets are still using the specified
-    function block, the system will mark the function block as being in the
-    process of being removed. This will prevent additional sockets from using
-    the specified function block. However, it will not impact sockets that are
-    already using the function block.

-
tcp_functions
-    modules must call one or more of the registration functions during
-    initialization and successfully call the
-    ()
-    function prior to allowing the module to be unloaded.

-
The blk argument is a pointer to a
-    struct tcp_function_block, which is explained below
-    (see Function Block
-    Structure). The wait argument is used as the
-    flags argument to malloc(9), and
-    must be set to one of the valid values defined in that man page.

-

-

-
The blk argument is a pointer to a
-    struct tcp_function_block, which has the following
-    members:

-

-
struct tcp_function_block {
-	char	tfb_tcp_block_name[TCP_FUNCTION_NAME_LEN_MAX];
-	int	(*tfb_tcp_output)(struct tcpcb *);
-	void	(*tfb_tcp_do_segment)(struct mbuf *, struct tcphdr *,
-			    struct socket *, struct tcpcb *,
-			    int, int, uint8_t,
-			    int);
-	int     (*tfb_tcp_ctloutput)(struct socket *so,
-			    struct sockopt *sopt,
-			    struct inpcb *inp, struct tcpcb *tp);
-	/* Optional memory allocation/free routine */
-	void	(*tfb_tcp_fb_init)(struct tcpcb *);
-	void	(*tfb_tcp_fb_fini)(struct tcpcb *, int);
-	/* Optional timers, must define all if you define one */
-	int	(*tfb_tcp_timer_stop_all)(struct tcpcb *);
-	void	(*tfb_tcp_timer_activate)(struct tcpcb *,
-			    uint32_t, u_int);
-	int	(*tfb_tcp_timer_active)(struct tcpcb *, uint32_t);
-	void	(*tfb_tcp_timer_stop)(struct tcpcb *, uint32_t);
-	/* Optional function */
-	void	(*tfb_tcp_rexmit_tmr)(struct tcpcb *);
-	/* Mandatory function */
-	int	(*tfb_tcp_handoff_ok)(struct tcpcb *);
-	/* System use */
-	volatile uint32_t tfb_refcnt;
-	uint32_t  tfb_flags;
-};

-

-
The tfb_tcp_block_name field identifies the
-    unique name of the TCP stack, and should be no longer than
-    TCP_FUNCTION_NAME_LEN_MAX-1 characters in length.

-
The tfb_tcp_output,
-    tfb_tcp_do_segment, and
-    tfb_tcp_ctloutput fields are pointers to functions
-    that perform the equivalent actions as the default
-    (),
-    (),
-    and
-    ()
-    functions, respectively. Each of these function pointers must be
-  non-NULL.

-
If a TCP stack needs to initialize data when a socket first
-    selects the TCP stack (or, when the socket is first opened), it should set a
-    non-NULL pointer in the tfb_tcp_fb_init field.
-    Likewise, if a TCP stack needs to cleanup data when a socket stops using the
-    TCP stack (or, when the socket is closed), it should set a non-NULL pointer
-    in the tfb_tcp_fb_fini field.

-
If the tfb_tcp_fb_fini argument is non-NULL,
-    the function to which it points is called when the kernel is destroying the
-    TCP control block or when the socket is transitioning to use a different TCP
-    stack. The function is called with arguments of the TCP control block and an
-    integer flag. The flag will be zero if the socket is transitioning to use
-    another TCP stack or one if the TCP control block is being destroyed.

-
If the TCP stack implements additional
-    timers, the TCP stack should set a non-NULL pointer in the
-    tfb_tcp_timer_stop_all,
-    tfb_tcp_timer_activate,
-    tfb_tcp_timer_active, and
-    tfb_tcp_timer_stop fields. These fields should all be
-    NULL or should all contain pointers to functions.
-    The tfb_tcp_timer_activate,
-    tfb_tcp_timer_active, and
-    tfb_tcp_timer_stop functions will be called when the
-    (),
-    (),
-    and
-    ()
-    functions, respectively, are called with a timer type other than the
-    standard types. The functions defined by the TCP stack have the same
-    semantics (both for arguments and return values) as the normal timer
-    functions they supplement.

-
Additionally, a stack may define its own actions to take when the
-    retransmit timer fires by setting a non-NULL function pointer in the
-    tfb_tcp_rexmit_tmr field. This function is called very
-    early in the process of handling a retransmit timer. However, care must be
-    taken to ensure the retransmit timer leaves the TCP control block in a valid
-    state for the remainder of the retransmit timer logic.

-
A user may select a new TCP stack before calling at any time.
-    Therefore, the function pointer tfb_tcp_handoff_ok
-    field must be non-NULL. If a user attempts to select that TCP stack, the
-    kernel will call the function pointed to by the
-    tfb_tcp_handoff_ok field. The function should return 0
-    if the user is allowed to switch the socket to use the TCP stack. In this
-    case, the kernel will call the function pointed to by
-    tfb_tcp_fb_init if this function pointer is non-NULL
-    and finally perform the stack switch. If the user is not allowed to switch
-    the socket, the function should undo any changes it made to the connection
-    state configuration and return an error code, which will be returned to the
-    user.

-
The tfb_refcnt and
-    tfb_flags fields are used by the kernel's TCP code and
-    will be initialized when the TCP stack is registered.

-

-

-

-
If the TCP stack needs to store data beyond what is stored in the
-    default TCP control block, the TCP stack can initialize its own
-    per-connection storage. The t_fb_ptr field in the
-    struct tcpcb control block structure has been reserved
-    to hold a pointer to this per-connection storage. If the TCP stack uses this
-    alternate storage, it should understand that the value of the
-    t_fb_ptr pointer may not be initialized to
-    NULL. Therefore, it should use a
-    tfb_tcp_fb_init function to initialize this field.
-    Additionally, it should use a tfb_tcp_fb_fini function
-    to deallocate storage when the socket is closed.

-
It is understood that alternate TCP stacks may keep different sets
-    of data. However, in order to ensure that data is available to both the user
-    and the rest of the system in a standardized format, alternate TCP stacks
-    must update all fields in the TCP control block to the greatest extent
-    practical.

-

-

-

-

-
The register_tcp_functions(),
-    register_tcp_functions_as_name(),
-    register_tcp_functions_as_names(), and
-    deregister_tcp_functions() functions return zero on
-    success and non-zero on failure. In particular, the
-    deregister_tcp_functions() will return
-    EBUSY until no more connections are using the
-    specified TCP stack. A module calling
-    deregister_tcp_functions() must be prepared to wait
-    until all connections have stopped using the specified TCP stack.

-

-

-

-
The register_tcp_functions(),
-    register_tcp_functions_as_name(), and
-    register_tcp_functions_as_names() functions will
-    fail if:

-

-  
[]

-  
Any of the members of the blk argument are set
-      incorrectly.

-  
[]

-  
The function could not allocate memory for its internal data.

-  
[]

-  
The blk is already registered or a function block is
-      already registered with the same name.

-

-Additionally, register_tcp_functions_as_names() will
-  fail if:
-

-  
[]

-  
The number of names pointed to by the num_names
-      argument is larger than TCP_FUNCTION_NAME_NUM_MAX.

-

-The deregister_tcp_functions() function will fail if:
-

-  
[]

-  
The blk argument references the kernel's compiled-in
-      default function block.

-  
[]

-  
The function block is still in use by one or more sockets, or is defined
-      as the current default function block.

-  
[]

-  
The blk argument references a function block that is
-      not currently registered.

-

-

-

-

-
connect(2), listen(2),
-    tcp(4), malloc(9)

-

-

-

-
This framework first appeared in FreeBSD
-    11.0.

-

-

-

-
The tcp_functions framework was written by
-    Randall Stewart
-    <rrs@FreeBSD.org>.

-
This manual page was written by Jonathan
-    Looney
-    <jtl@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 13, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/thread_exit.9 4.html b/static/freebsd/man9/thread_exit.9 4.html
deleted file mode 100644
index 399dfae7..00000000
--- a/static/freebsd/man9/thread_exit.9 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
THREAD_EXIT(9)Kernel Developer's ManualTHREAD_EXIT(9)

-

-

-

-
thread_exit —
-    abandon current thread context

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>

-
void
-  

-  thread_exit(void);

-

-

-

-
The
-    ()
-    function implements the machine independent prelude to a thread shutdown. It
-    will not return, and will result in a call to mi_switch(9)
-    to schedule some other thread.

-
()
-    arranges to free all the resources of the thread, specifically the kernel
-    stack.

-
To protect the runqueue(9),
-    ()
-    must be called with the sched_lock mutex held.

-

-

-

-
mi_switch(9), mutex(9),
-    runqueue(9), sleep(9)

-

-

-
-  
-    
-    
-  
-
July 5, 2002FreeBSD 15.0

diff --git a/static/freebsd/man9/time.9 4.html b/static/freebsd/man9/time.9 4.html
deleted file mode 100644
index 6a526213..00000000
--- a/static/freebsd/man9/time.9 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
TIME(9)Kernel Developer's ManualTIME(9)

-

-

-

-
boottime,
-    time_second, time_uptime
-    — system time variables

-

-

-

-
#include
-    <sys/time.h>

-

-  

-  extern struct timeval boottime;
-  

-  extern time_t time_second;
-  

-  extern time_t time_uptime;

-

-

-

-
The boottime variable holds the estimated
-    system boot time. This time is initially set when the system boots, either
-    from the RTC, or from a time estimated from the system's root filesystem.
-    When the current system time is set, stepped by ntpd(8),
-    or a new time is read from the RTC as the system resumes,
-    boottime is recomputed as new_time - uptime. The
-    sysctl(8) kern.boottime returns this
-    value.

-
The time_second variable is the system's
-    “wall time” clock to the second.

-
The time_uptime variable is the number of
-    seconds since boot.

-
The bintime(9), getbintime(9),
-    microtime(9), getmicrotime(9),
-    nanotime(9), and getnanotime(9)
-    functions can be used to get the current time more accurately and in an
-    atomic manner. Similarly, the binuptime(9),
-    getbinuptime(9), microuptime(9),
-    getmicrouptime(9), nanouptime(9), and
-    getnanouptime(9) functions can be used to get the time
-    elapse since boot more accurately and in an atomic manner. The
-    boottime variable may be read and written without
-    special precautions. It is adjusted when the phase of the system time
-    changes.

-

-

-

-
clock_settime(2),
-    ntp_adjtime(2), settimeofday(2),
-    bintime(9), binuptime(9),
-    getbintime(9), getbinuptime(9),
-    getmicrotime(9), getmicrouptime(9),
-    getnanotime(9), getnanouptime(9),
-    microtime(9), microuptime(9),
-    nanotime(9), nanouptime(9)

-
Poul-Henning Kamp,
-    Timecounters: Efficient and precise timekeeping in SMP
-    kernels, Proceedings of EuroBSDCon 2002,
-    Amsterdam,
-    /usr/share/doc/papers/timecounter.ascii.gz.

-
Marshall Kirk McKusick
-    and George V. Neville-Neil, The
-    Design and Implementation of the FreeBSD Operating System,
-    Addison-Wesley, 57-61,65-66,
-    July 2004.

-

-

-
-  
-    
-    
-  
-
May 4, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/tvtohz.9 4.html b/static/freebsd/man9/tvtohz.9 4.html
deleted file mode 100644
index 170f67d9..00000000
--- a/static/freebsd/man9/tvtohz.9 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
TVTOHZ(9)Kernel Developer's ManualTVTOHZ(9)

-

-

-

-
tvtohz — convert
-    time interval to tick count

-

-

-

-
#include
-    <sys/time.h>

-
int
-  

-  tvtohz(struct
-    timeval *tv);

-

-

-

-
The
-    ()
-    function accepts a single argument tv which specifies
-    the time interval over which to calculate the number of system ticks that
-    would elapse.

-

-

-

-
Returns the integral number of system ticks expected to elapse in
-    the given interval, including the current tick.

-

-

-

-
callout(9), microtime(9),
-    microuptime(9)

-

-

-

-
The tvtohz function first appeared in
-    FreeBSD 3.0

-

-

-

-
This manual page was written by Kelly
-    Yancey
-    <kbyanc@posi.net>.

-

-

-
-  
-    
-    
-  
-
January 3, 2000FreeBSD 15.0

diff --git a/static/freebsd/man9/ucred.9 4.html b/static/freebsd/man9/ucred.9 4.html
deleted file mode 100644
index 81a93db8..00000000
--- a/static/freebsd/man9/ucred.9 4.html	
+++ /dev/null
@@ -1,188 +0,0 @@
-
-  
-    
-    
-    
-  
-
UCRED(9)Kernel Developer's ManualUCRED(9)

-

-

-

-
ucred, crget,
-    crhold, crfree,
-    crcopy, crdup,
-    cru2x — functions related to
-    user credentials

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/ucred.h>

-
struct ucred *
-  

-  crget(void);

-
struct ucred *
-  

-  crhold(struct
-    ucred *cr);

-
void
-  

-  crfree(struct
-    ucred *cr);

-
void
-  

-  crcopy(struct
-    ucred *dest, struct ucred
-    *src);

-
struct ucred *
-  

-  crcopysafe(struct
-    proc *p, struct ucred
-    *cr);

-
struct ucred *
-  

-  crdup(struct
-    ucred *cr);

-
void
-  

-  crsetgroups(struct
-    ucred *cr, int
-    ngrp, gid_t
-    *groups);

-
void
-  

-  crsetgroups_and_egid(struct
-    ucred *cr, int
-    ngrp, gid_t
-    *groups, gid_t
-    default_egid);

-
void
-  

-  cru2x(struct
-    ucred *cr, struct xucred
-    *xcr);

-

-

-

-
The ucred family of functions is used to
-    manage user credential structures (struct ucred)
-    within the kernel.

-
The
-    ()
-    function allocates memory for a new structure, sets its reference count to
-    1, and initializes its lock.

-
The
-    ()
-    function increases the reference count on the credential.

-
The
-    ()
-    function decreases the reference count on the credential. If the count drops
-    to 0, the storage for the structure is freed.

-
The
-    ()
-    function copies the contents of the source (template) credential into the
-    destination template. The uidinfo structure within the
-    destination is referenced by calling uihold(9).

-
The
-    ()
-    function copies the current credential associated with the process
-    p into the newly allocated credential
-    cr. The process lock on p must
-    be held and will be dropped and reacquired as needed to allocate group
-    storage space in cr.

-
The
-    ()
-    function allocates memory for a new structure and copies the contents of
-    cr into it. The actual copying is performed by
-    crcopy().

-
The
-    ()
-    function sets the cr_groups and
-    cr_ngroups variables representing the supplementary
-    groups, allocating space as needed. It also truncates the group list to the
-    current maximum number of groups. The
-    ()
-    function is similar, but interprets separately the first group of
-    groups as the effective GID to set, only setting the
-    subsequent groups as supplementary ones. It will use
-    default_egid as the new effective GID if
-    groups is empty. No other mechanism should be used to
-    modify the cr_groups array.

-
The
-    ()
-    function converts a ucred structure to an
-    xucred structure. That is, it copies data from
-    cr to xcr; it ignores fields in
-    the former that are not present in the latter (e.g.,
-    cr_uidinfo), and appropriately sets fields in the
-    latter that are not present in the former (e.g.,
-    cr_version).

-

-

-

-
crget(), crhold(),
-    crdup(), and crcopysafe()
-    all return a pointer to a ucred structure.

-

-

-

-
As of FreeBSD 5.0, the
-    ucred structure contains extensible fields. This means
-    that the correct protocol must always be followed to create a fresh and
-    writable credential structure: new credentials must always be derived from
-    existing credentials using crget(),
-    crcopy(), and
-  crcopysafe().

-
In the common case, credentials required for access control
-    decisions are used in a read-only manner. In these circumstances, the thread
-    credential td_ucred should be used, as it requires no
-    locking to access safely, and remains stable for the duration of the call
-    even in the face of a multi-threaded application changing the process
-    credentials from another thread.

-
During a process credential update, the process lock must be held
-    across check and update, to prevent race conditions. The process credential,
-    td->td_proc->p_ucred, must be used both for
-    check and update. If a process credential is updated during a system call
-    and checks against the thread credential are to be made later during the
-    same system call, the thread credential must also be refreshed from the
-    process credential so as to prevent use of a stale value. To avoid this
-    scenario, it is recommended that system calls updating the process
-    credential be designed to avoid other authorization functions.

-
If temporarily elevated privileges are required for a
-    thread, the thread credential can be replaced for the duration of an
-    activity, or for the remainder of the system call. However, as a thread
-    credential is often shared, appropriate care should be taken to make sure
-    modifications are made to a writable credential through the use of
-    () and
-    crcopy().

-
Caution should be exercised when checking authorization
-    for a thread or process perform an operation on another thread or process.
-    As a result of temporary elevation, the target thread credential should
-     be used as
-    the target credential in an access control decision: the process credential
-    associated with the thread,
-    td->td_proc->p_ucred, should be used instead.
-    For example, p_candebug(9) accepts a target process, not a
-    target thread, for access control purposes.

-

-

-

-
uihold(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
August 29, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/uidinfo.9 4.html b/static/freebsd/man9/uidinfo.9 4.html
deleted file mode 100644
index 42f090f9..00000000
--- a/static/freebsd/man9/uidinfo.9 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
UIDINFO(9)Kernel Developer's ManualUIDINFO(9)

-

-

-

-
uidinfo,
-    uihashinit, uifind,
-    uihold, uifree —
-    functions for managing UID information

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>
-  

-  #include
-  <sys/resourcevar.h>

-
void
-  

-  uihashinit(void);

-
struct uidinfo *
-  

-  uifind(uid_t
-    uid);

-
void
-  

-  uihold(struct
-    uidinfo *uip);

-
void
-  

-  uifree(struct
-    uidinfo *uip);

-

-

-

-
The uidinfo family of functions is used to
-    manage uidinfo structures. Each
-    uidinfo structure maintains per uid resource
-    consumption counts, including the process count and socket buffer space
-    usage.

-
The
-    ()
-    function initializes the uidinfo hash table and its
-    mutex. This function should only be called during system initialization.

-
The
-    ()
-    function looks up and returns the uidinfo structure
-    for uid. If no uidinfo structure
-    exists for uid, a new structure will be allocated and
-    initialized. The uidinfo hash mutex is acquired and
-    released.

-
The
-    ()
-    function increases the reference count on uip.
-    uip's lock is acquired and released.

-
The
-    ()
-    function decreases the reference count on uip, and if
-    the count reaches 0 uip is freed.
-    uip's lock is acquired and release and the uidinfo
-    hash mutex may be acquired and released.

-

-

-

-
uifind() returns a pointer to an
-    initialized uidinfo structure, and should not
-  fail.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 10, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/uio.9 3.html b/static/freebsd/man9/uio.9 3.html
deleted file mode 100644
index 8baecde9..00000000
--- a/static/freebsd/man9/uio.9 3.html	
+++ /dev/null
@@ -1,212 +0,0 @@
-
-  
-    
-    
-    
-  
-
UIO(9)Kernel Developer's ManualUIO(9)

-

-

-

-
uio, uiomove,
-    uiomove_frombuf,
-    uiomove_nofault — device
-    driver I/O routines

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/uio.h>

-

-
struct uio {
-	struct	iovec *uio_iov;		/* scatter/gather list */
-	int	uio_iovcnt;		/* length of scatter/gather list */
-	off_t	uio_offset;		/* offset in target object */
-	ssize_t	uio_resid;		/* remaining bytes to copy */
-	enum	uio_seg uio_segflg;	/* address space */
-	enum	uio_rw uio_rw;		/* operation */
-	struct	thread *uio_td;		/* owner */
-};

-

-

-int
-

-uiomove(void
-  *buf, int howmuch,
-  struct uio *uiop);
-
int
-  

-  uiomove_frombuf(void
-    *buf, int howmuch,
-    struct uio *uiop);

-
int
-  

-  uiomove_nofault(void
-    *buf, int howmuch,
-    struct uio *uiop);

-

-

-

-
The functions
-    (),
-    uiomove_frombuf(), and
-    uiomove_nofault() are used to transfer data between
-    buffers and I/O vectors that might possibly cross the user/kernel space
-    boundary.

-
As a result of any read(2),
-    write(2), readv(2), or
-    writev(2) system call that is being passed to a
-    character-device driver, the appropriate driver d_read
-    or d_write entry will be called with a pointer to a
-    struct uio being passed. The transfer request is
-    encoded in this structure. The driver itself should use
-    ()
-    or uiomove_nofault() to get at the data in this
-    structure.

-
The fields in the uio structure are:

-

-  
uio_iov

-  
The array of I/O vectors to be processed. In the case of scatter/gather
-      I/O, this will be more than one vector.

-  
uio_iovcnt

-  
The number of I/O vectors present.

-  
uio_offset

-  
The offset into the device.

-  
uio_resid

-  
The remaining number of bytes to process, updated after transfer.

-  
uio_segflg

-  
One of the following flags:
-    

-      

-      
The I/O vector points into a process's address space.

-      

-      
The I/O vector points into the kernel address space.

-      

-      
Do not copy, already in object.

-    

-  

-  
uio_rw

-  
The direction of the desired transfer. The supported flags are:
-    

-      

-      
Transfer data from the buffers into the I/O vectors.

-      

-      
Transfer data from the I/O vectors into the buffers.

-    

-  

-  
uio_td

-  
The pointer to a struct thread for the associated
-      thread; used if uio_segflg indicates that the
-      transfer is to be made from/to a process's address space.

-

-
The function
-    ()
-    requires that the buffer and I/O vectors be accessible without incurring a
-    page fault. The source and destination addresses must be physically mapped
-    for read and write access, respectively, and neither the source nor
-    destination addresses may be pageable. Thus, the function
-    uiomove_nofault() can be called from contexts where
-    acquiring virtual memory system locks or sleeping are prohibited.

-
The
-    ()
-    function is a convenience wrapper around uiomove()
-    for drivers that serve data which is wholly contained within an existing
-    buffer in memory. It validates the uio_offset and
-    uio_resid values against the size of the existing
-    buffer, handling short transfers when the request partially overlaps the
-    buffer. When uio_offset is greater than or equal to
-    the buffer size, the result is success with no bytes transferred,
-    effectively signaling EOF.

-

-

-

-
On success uiomove(),
-    uiomove_frombuf(), and
-    uiomove_nofault() will return 0; on error they will
-    return an appropriate error code.

-

-

-

-
The idea is that the driver maintains a private buffer for its
-    data, and processes the request in chunks of maximal the size of this
-    buffer. Note that the buffer handling below is very simplified and will not
-    work (the buffer pointer is not being advanced in case of a partial read),
-    it is just here to demonstrate the uio handling.

-

-
/* MIN() can be found there: */
-#include <sys/param.h>
-
-#define BUFSIZE 512
-static char buffer[BUFSIZE];
-
-static int data_available;	/* amount of data that can be read */
-
-static int
-fooread(struct cdev *dev, struct uio *uio, int flag)
-{
-	int rv, amnt;
-
-	rv = 0;
-	while (uio->uio_resid > 0) {
-		if (data_available > 0) {
-			amnt = MIN(uio->uio_resid, data_available);
-			rv = uiomove(buffer, amnt, uio);
-			if (rv != 0)
-				break;
-			data_available -= amnt;
-		} else
-			tsleep(...);	/* wait for a better time */
-	}
-	if (rv != 0) {
-		/* do error cleanup here */
-	}
-	return (rv);
-}

-

-

-

-

-
uiomove() and
-    uiomove_nofault() will fail and return the following
-    error code if:

-

-  
[]

-  
The invoked copyin(9) or copyout(9)
-      returned
-      

-

-
In addition, uiomove_nofault() will fail
-    and return the following error code if:

-

-  
[]

-  
A page fault occurs.

-

-

-

-

-
read(2), readv(2),
-    write(2), writev(2),
-    copyin(9), copyout(9),
-    sleep(9)

-

-

-

-
The uio mechanism appeared in some early
-    version of UNIX.

-

-

-

-
This manual page was written by Jörg
-    Wunsch.

-

-

-
-  
-    
-    
-  
-
October 22, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/unr.9 4.html b/static/freebsd/man9/unr.9 4.html
deleted file mode 100644
index 2bb3bf0c..00000000
--- a/static/freebsd/man9/unr.9 4.html	
+++ /dev/null
@@ -1,186 +0,0 @@
-
-  
-    
-    
-    
-  
-
UNR(9)Kernel Developer's ManualUNR(9)

-

-

-

-
new_unrhdr,
-    clean_unrhdr, clear_unrhdr,
-    delete_unrhdr, alloc_unr,
-    alloc_unr_specific,
-    free_unr, create_iter_unr,
-    next_iter_unr, free_iter_unr
-    — kernel unit number allocator

-

-

-

-
#include
-    <sys/systm.h>

-
struct unrhdr *
-  

-  new_unrhdr(int
-    low, int high,
-    struct mtx *mutex);

-
void
-  

-  clean_unrhdr(struct
-    unrhdr *uh);

-
void
-  

-  clean_unrhdrl(struct
-    unrhdr *uh);

-
void
-  

-  clear_unrhdr(struct
-    unrhdr *uh);

-
void
-  

-  delete_unrhdr(struct
-    unrhdr *uh);

-
int
-  

-  alloc_unr(struct
-    unrhdr *uh);

-
int
-  

-  alloc_unrl(struct
-    unrhdr *uh);

-
int
-  

-  alloc_unr_specific(struct
-    unrhdr *uh, u_int
-    item);

-
void
-  

-  free_unr(struct
-    unrhdr *uh, u_int
-    item);

-
void *
-  

-  create_iter_unr(struct
-    unrhdr *uh);

-
int
-  

-  next_iter_unr(void
-    *handle);

-
void
-  

-  free_iter_unr(void
-    *handle);

-

-

-

-
The kernel unit number allocator is a generic facility, which
-    allows to allocate unit numbers within a specified range.

-

-  
(low,
-    high, mutex)

-  
Initialize a new unit number allocator entity. The
-      low and high arguments specify
-      minimum and maximum number of unit numbers. There is no cost associated
-      with the range of unit numbers, so unless the resource really is finite,
-      INT_MAX can be used. If
-      mutex is not NULL, it is
-      used for locking when allocating and freeing units. If the passed value is
-      the token UNR_NO_MTX, then no locking is applied
-      internally. Otherwise, internal mutex is used.

-  
(uh)

-  
Clear all units from the specified unit number allocator entity. This
-      function resets the entity as if it were just initialized with
-      new_unrhdr().

-  
(uh)

-  
Delete specified unit number allocator entity. This function frees the
-      memory associated with the entity, it does not free any units. To free all
-      units use clear_unrhdr().

-  
(uh)

-  
Freeing unit numbers might result in some internal memory becoming unused.
-      There are unit allocator consumers that cannot
-      tolerate taking malloc(9) locks to free the memory,
-      while having their unit mutex locked. For this reason, free of the unused
-      memory after delete is postponed until the consumer can afford calling
-      into the malloc(9) subsystem. Call
-      clean_unrhdr(uh) to do the
-      cleanup. In particular, this needs to be done before freeing a unr, if a
-      deletion of units could have been performed.

-  
()

-  
Same as clean_unrhdr(), but assumes that the unr
-      mutex is already owned, if any.

-  
(uh)

-  
Return a new unit number. The lowest free number is always allocated. This
-      function does not allocate memory and never sleeps, however it may block
-      on a mutex. If no free unit numbers are left, -1
-      is returned.

-  
(uh)

-  
Same as alloc_unr() except that mutex is assumed
-      to be already locked and thus is not used.

-  
(uh,
-    item)

-  
Allocate a specific unit number. This function allocates memory and thus
-      may sleep. The allocated unit number is returned on success. If the
-      specified number is already allocated or out of the range,
-      -1 is returned.

-  
(uh,
-    item)

-  
Free a previously allocated unit number. This function may require
-      allocating memory, and thus it can sleep. There is no pre-locked
-    variant.

-

-

-

-

-
The unr facility provides an interface to
-    iterate over all allocated units for the given
-    unrhdr. Iterators are identified by an opaque
-    handle. More than one iterators can operate simultaneously; the iterator
-    position data is recorded only in the iterator handle.

-
Consumers must ensure that the unit allocator
-    is not modified between calls to the iterator functions. In particular, the
-    internal allocator mutex cannot provide consistency, because it is acquired
-    and dropped inside the
-    ()
-    function. If the allocator was modified, it is safe to free the iterator
-    with
-    ()
-    method nevertheless.

-

-  
(uh)

-  
Create an iterator. Return the handle that should be passed to other
-      iterator functions.

-  
next_iter_unr(handle)

-  
Return the value of the next unit. Units are returned in ascending order.
-      A return value of -1 indicates the end of
-      iteration, in which case -1 is returned for all
-      future calls.

-  
free_iter_unr(handle)

-  
Free the iterator, handle is no longer valid.

-

-

-

-

-
The above functions are implemented in
-    sys/kern/subr_unit.c.

-

-

-

-
Kernel unit number allocator first appeared in
-    FreeBSD 6.0.

-

-

-

-
Kernel unit number allocator was written by
-    Poul-Henning Kamp. This manpage was written by
-    Gleb Smirnoff.

-

-

-
-  
-    
-    
-  
-
April 21, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/usbdi.9 3.html b/static/freebsd/man9/usbdi.9 3.html
deleted file mode 100644
index c173ca47..00000000
--- a/static/freebsd/man9/usbdi.9 3.html	
+++ /dev/null
@@ -1,477 +0,0 @@
-
-  
-    
-    
-    
-  
-
USBDI(9)Kernel Developer's ManualUSBDI(9)

-

-

-

-
usb_fifo_alloc_buffer,
-    usb_fifo_attach,
-    usb_fifo_detach,
-    usb_fifo_free_buffer,
-    usb_fifo_get_data,
-    usb_fifo_get_data_buffer,
-    usb_fifo_get_data_error,
-    usb_fifo_get_data_linear,
-    usb_fifo_put_bytes_max,
-    usb_fifo_put_data,
-    usb_fifo_put_data_buffer,
-    usb_fifo_put_data_error,
-    usb_fifo_put_data_linear,
-    usb_fifo_reset,
-    usb_fifo_softc,
-    usb_fifo_wakeup,
-    usbd_do_request,
-    usbd_do_request_flags,
-    usbd_errstr,
-    usbd_lookup_id_by_info,
-    usbd_lookup_id_by_uaa,
-    usbd_transfer_clear_stall,
-    usbd_transfer_drain,
-    usbd_transfer_pending,
-    usbd_transfer_poll,
-    usbd_transfer_setup,
-    usbd_transfer_start,
-    usbd_transfer_stop,
-    usbd_transfer_submit,
-    usbd_transfer_unsetup,
-    usbd_xfer_clr_flag,
-    usbd_xfer_frame_data,
-    usbd_xfer_frame_len,
-    usbd_xfer_get_frame,
-    usbd_xfer_get_priv,
-    usbd_xfer_is_stalled,
-    usbd_xfer_max_framelen,
-    usbd_xfer_max_frames,
-    usbd_xfer_max_len,
-    usbd_xfer_set_flag,
-    usbd_xfer_set_frame_data,
-    usbd_xfer_set_frame_len,
-    usbd_xfer_set_frame_offset,
-    usbd_xfer_set_frames,
-    usbd_xfer_set_interval,
-    usbd_xfer_set_priv,
-    usbd_xfer_set_stall,
-    usbd_xfer_set_timeout,
-    usbd_xfer_softc,
-    usbd_xfer_state,
-    usbd_xfer_status — Universal
-    Serial Bus driver programming interface

-

-

-

-
#include
-    <dev/usb/usb.h>
-  

-  #include <dev/usb/usbdi.h>
-  

-  #include
-    <dev/usb/usbdi_util.h>

-
usb_error_t
-  

-  usbd_transfer_setup(struct usb_device
-    *udev, const uint8_t *ifaces,
-    struct usb_xfer **pxfer, const struct
-    usb_config *setup_start, uint16_t n_setup,
-    void *priv_sc, struct mtx
-    *priv_mtx);

-
void
-  

-  usbd_transfer_unsetup(struct usb_xfer
-    **pxfer, uint16_t n_setup);

-
void
-  

-  usbd_transfer_start(struct usb_xfer
-    *xfer);

-
void
-  

-  usbd_transfer_stop(struct usb_xfer
-    *xfer);

-
void
-  

-  usbd_transfer_drain(struct usb_xfer
-    *xfer);

-

-

-

-
The Universal Serial Bus (USB) driver programming interface
-    provides USB peripheral drivers with a host controller independent API for
-    controlling and communicating with USB peripherals. The
-    usb module supports both USB Host and USB Device
-    side mode.

-

-

-

-
The USB standard defines four types of USB transfers. Control
-    transfers, Bulk transfers, Interrupt transfers and Isochronous transfers.
-    All the transfer types are managed using the following five functions:

-
()
-    This function will allocate memory for and initialise an array of USB
-    transfers and all required DMA memory. This function can sleep or block
-    waiting for resources to become available. udev is a
-    pointer to "struct usb_device". ifaces is an
-    array of interface index numbers to use. See "if_index".
-    pxfer is a pointer to an array of USB transfer
-    pointers that are initialized to NULL, and then pointed to allocated USB
-    transfers. setup_start is a pointer to an array of USB
-    config structures. n_setup is a number telling the USB
-    system how many USB transfers should be setup. priv_sc
-    is the private softc pointer, which will be used to initialize
-    "xfer->priv_sc". priv_mtx is the private
-    mutex protecting the transfer structure and the softc. This pointer is used
-    to initialize "xfer->priv_mtx". This function returns zero upon
-    success. A non-zero return value indicates failure.

-
()
-    This function will release the given USB transfers and all allocated
-    resources associated with these USB transfers. pxfer
-    is a pointer to an array of USB transfer pointers, that may be NULL, that
-    should be freed by the USB system. n_setup is a number
-    telling the USB system how many USB transfers should be unsetup. This
-    function can sleep waiting for USB transfers to complete. This function is
-    NULL safe with regard to the USB transfer structure pointer. It is not
-    allowed to call this function from the USB transfer callback.

-
()
-    This function will start the USB transfer pointed to by
-    xfer, if not already started. This function is always
-    non-blocking and must be called with the so-called private USB mutex locked.
-    This function is NULL safe with regard to the USB transfer structure
-    pointer.

-
()
-    This function will stop the USB transfer pointed to by
-    xfer, if not already stopped. This function is always
-    non-blocking and must be called with the so-called private USB mutex locked.
-    This function can return before the USB callback has been called. This
-    function is NULL safe with regard to the USB transfer structure pointer. If
-    the transfer was in progress, the callback will called with
-    "USB_ST_ERROR" and "error = USB_ERR_CANCELLED".

-
()
-    This function will stop an USB transfer, if not already stopped and wait for
-    any additional USB hardware operations to complete. Buffers that are loaded
-    into DMA using "usbd_xfer_set_frame_data()" can safely be freed
-    after that this function has returned. This function can block the caller
-    and will not return before the USB callback has been called. This function
-    is NULL safe with regard to the USB transfer structure pointer.

-

-

-

-
The USB callback has three states. USB_ST_SETUP,
-    USB_ST_TRANSFERRED and USB_ST_ERROR. USB_ST_SETUP is the initial state.
-    After the callback has been called with this state it will always be called
-    back at a later stage in one of the other two states. The USB callback
-    should not restart the USB transfer in case the error cause is
-    USB_ERR_CANCELLED. The USB callback is protected from recursion. That means
-    one can start and stop whatever transfer from the callback of another
-    transfer one desires. Also the transfer that is currently called back.
-    Recursion is handled like this that when the callback that wants to recurse
-    returns it is called one more time.

-
()
-    This function should only be called from within the USB callback and is used
-    to start the USB hardware. An USB transfer can have multiple frames
-    consisting of one or more USB packets making up an I/O vector for all USB
-    transfer types.

-

-
void
-usb_default_callback(struct usb_xfer *xfer, usb_error_t error)
-{
-	int actlen;
-
-	usbd_xfer_status(xfer, &actlen, NULL, NULL, NULL);
-
-	switch (USB_GET_STATE(xfer)) {
-	case USB_ST_SETUP:
-		/*
-		 * Setup xfer frame lengths/count and data
-		 */
-		usbd_transfer_submit(xfer);
-		break;
-
-	case USB_ST_TRANSFERRED:
-		/*
-		 * Read	usb frame data, if any.
-		 * "actlen" has the total length for all frames
-		 * transferred.
-		 */
-		break;
-
-	default: /* Error */
-		/*
-		 * Print error message and clear stall
-		 * for example.
-		 */
-		break;
-	}
-	/*
-	 * Here it is safe to do something without the private
-	 * USB mutex locked.
-	 */
-	return;
-}

-

-

-

-

-
An USB control transfer has three parts. First the SETUP packet,
-    then DATA packet(s) and then a STATUS packet. The SETUP packet is always
-    pointed to by frame 0 and the length is set by
-    ()
-    also if there should not be sent any SETUP packet! If an USB control
-    transfer has no DATA stage, then the number of frames should be set to 1.
-    Else the default number of frames is 2.

-

-
-Example1: SETUP + STATUS
- usbd_xfer_set_frames(xfer, 1);
- usbd_xfer_set_frame_len(xfer, 0, 8);
- usbd_transfer_submit(xfer);
-
-Example2: SETUP + DATA + STATUS
- usbd_xfer_set_frames(xfer, 2);
- usbd_xfer_set_frame_len(xfer, 0, 8);
- usbd_xfer_set_frame_len(xfer, 1, 1);
- usbd_transfer_submit(xfer);
-
-Example3: SETUP + DATA + STATUS - split
-1st callback:
- usbd_xfer_set_frames(xfer, 1);
- usbd_xfer_set_frame_len(xfer, 0, 8);
- usbd_transfer_submit(xfer);
-
-2nd callback:
- /* IMPORTANT: frbuffers[0] must still point at the setup packet! */
- usbd_xfer_set_frames(xfer, 2);
- usbd_xfer_set_frame_len(xfer, 0, 0);
- usbd_xfer_set_frame_len(xfer, 1, 1);
- usbd_transfer_submit(xfer);
-
-Example4: SETUP + STATUS - split
-1st callback:
- usbd_xfer_set_frames(xfer, 1);
- usbd_xfer_set_frame_len(xfer, 0, 8);
- usbd_xfer_set_flag(xfer, USB_MANUAL_STATUS);
- usbd_transfer_submit(xfer);
-
-2nd callback:
- usbd_xfer_set_frames(xfer, 1);
- usbd_xfer_set_frame_len(xfer, 0, 0);
- usbd_xfer_clr_flag(xfer, USB_MANUAL_STATUS);
- usbd_transfer_submit(xfer);
-
-

-

-

-

-

-
To simplify the search for endpoints the
-    usb module defines a USB config structure where it
-    is possible to specify the characteristics of the wanted endpoint.

-

-
-struct usb_config {
-	bufsize,
-	callback
-	direction,
-	endpoint,
-	frames,
-	index flags,
-	interval,
-	timeout,
-	type,
-};
-
-

-

-
type field selects the USB pipe type. Valid
-    values are: UE_INTERRUPT, UE_CONTROL, UE_BULK, UE_ISOCHRONOUS. The special
-    value UE_BULK_INTR will select BULK and INTERRUPT pipes. This field is
-    mandatory.

-
endpoint field selects the USB endpoint
-    number. A value of 0xFF, "-1" or "UE_ADDR_ANY" will
-    select the first matching endpoint. This field is mandatory.

-
direction field selects the USB endpoint
-    direction. A value of "UE_DIR_ANY" will select the first matching
-    endpoint. Else valid values are: "UE_DIR_IN" and
-    "UE_DIR_OUT". "UE_DIR_IN" and "UE_DIR_OUT" can
-    be binary OR'ed by "UE_DIR_SID" which means that the direction
-    will be swapped in case of USB_MODE_DEVICE. Note that "UE_DIR_IN"
-    refers to the data transfer direction of the "IN" tokens and
-    "UE_DIR_OUT" refers to the data transfer direction of the
-    "OUT" tokens. This field is mandatory.

-
interval field selects the interrupt
-    interval. The value of this field is given in milliseconds and is
-    independent of device speed. Depending on the endpoint type, this field has
-    different meaning:

-

-  
UE_INTERRUPT

-  
"0" use the default interrupt interval based on endpoint
-      descriptor. "Else" use the given value for polling rate.

-  
UE_ISOCHRONOUS

-  
"0" use default. "Else" the value is ignored.

-  
UE_BULK

-  
 

-  
UE_CONTROL

-  
"0" no transfer pre-delay. "Else" a delay as given by
-      this field in milliseconds is inserted before the hardware is started when
-      "usbd_transfer_submit()" is called.
-    
NOTE: The transfer timeout, if any, is started after that the
-        pre-delay has elapsed!

-  

-

-
timeout field, if non-zero, will set the
-    transfer timeout in milliseconds. If the "timeout" field is zero
-    and the transfer type is ISOCHRONOUS a timeout of 250ms will be used.

-
frames field sets the maximum number of
-    frames. If zero is specified it will yield the following results:

-

-  
UE_BULK

-  
xfer->nframes = 1;

-  
UE_INTERRUPT

-  
xfer->nframes = 1;

-  
UE_CONTROL

-  
xfer->nframes = 2;

-  
UE_ISOCHRONOUS

-  
Not allowed. Will cause an error.

-

-
ep_index field allows you to give a number,
-    in case more endpoints match the description, that selects which matching
-    "ep_index" should be used.

-
if_index field allows you to select which of
-    the interface numbers in the "ifaces" array parameter passed to
-    "usbd_transfer_setup" that should be used when setting up the
-    given USB transfer.

-
flags field has type "struct
-    usb_xfer_flags" and allows one to set initial flags an USB transfer.
-    Valid flags are:

-

-  
force_short_xfer

-  
This flag forces the last transmitted USB packet to be short. A short
-      packet has a length of less than "xfer->max_packet_size",
-      which derives from "wMaxPacketSize". This flag can be changed
-      during operation.

-  
short_xfer_ok

-  
This flag allows the received transfer length, "xfer->actlen"
-      to be less than "xfer->sumlen" upon completion of a transfer.
-      This flag can be changed during operation.

-  
short_frames_ok

-  
This flag allows the reception of multiple short USB frames. This flag
-      only has effect for BULK and INTERRUPT endpoints and if the number of
-      frames received is greater than 1. This flag can be changed during
-      operation.

-  
pipe_bof

-  
This flag causes a failing USB transfer to remain first in the PIPE queue
-      except in the case of "xfer->error" equal to
-      "USB_ERR_CANCELLED". No other USB transfers in the affected PIPE
-      queue will be started until either:
-    

-      
1

-      
The failing USB transfer is stopped using
-          "usbd_transfer_stop()".

-      
2

-      
The failing USB transfer performs a successful transfer.

-    

-    The purpose of this flag is to avoid races when multiple transfers are
-      queued for execution on an USB endpoint, and the first executing transfer
-      fails leading to the need for clearing of stall for example. In this case
-      this flag is used to prevent the following USB transfers from being
-      executed at the same time the clear-stall command is executed on the USB
-      control endpoint. This flag can be changed during operation.
-    
"BOF" is short for "Block On Failure".

-    
NOTE: This flag should be set on all BULK and INTERRUPT USB
-        transfers which use an endpoint that can be shared between userland and
-        kernel.

-  

-  
proxy_buffer

-  
Setting this flag will cause that the total buffer size will be rounded up
-      to the nearest atomic hardware transfer size. The maximum data length of
-      any USB transfer is always stored in the
-      "xfer->max_data_length". For control transfers the USB kernel
-      will allocate additional space for the 8-bytes of SETUP header. These
-      8-bytes are not counted by the "xfer->max_data_length"
-      variable. This flag cannot be changed during operation.

-  
ext_buffer

-  
Setting this flag will cause that no data buffer will be allocated.
-      Instead the USB client must supply a data buffer. This flag cannot be
-      changed during operation.

-  
manual_status

-  
Setting this flag prevents an USB STATUS stage to be appended to the end
-      of the USB control transfer. If no control data is transferred this flag
-      must be cleared. Else an error will be returned to the USB callback. This
-      flag is mostly useful for the USB device side. This flag can be changed
-      during operation.

-  
no_pipe_ok

-  
Setting this flag causes the USB_ERR_NO_PIPE error to be ignored. This
-      flag cannot be changed during operation.

-  
stall_pipe

-  

-    

-      
Device Side Mode

-      
Setting this flag will cause STALL pids to be sent to the endpoint
-          belonging to this transfer before the transfer is started. The
-          transfer is started at the moment the host issues a clear-stall
-          command on the STALL'ed endpoint. This flag can be changed during
-          operation.

-      
Host Side Mode

-      
Setting this flag will cause a clear-stall control request to be
-          executed on the endpoint before the USB transfer is started.

-    

-    
If this flag is changed outside the USB callback function you
-        have to use the "usbd_xfer_set_stall()" and
-        "usbd_transfer_clear_stall()" functions! This flag is
-        automatically cleared after that the stall or clear stall has been
-        executed.

-  

-  
pre_scale_frames

-  
If this flag is set the number of frames specified is assumed to give the
-      buffering time in milliseconds instead of frames. During transfer setup
-      the frames field is pre scaled with the corresponding value for the
-      endpoint and rounded to the nearest number of frames greater than zero.
-      This option only has effect for ISOCHRONOUS transfers.

-

-
bufsize field sets the total buffer size in
-    bytes. If this field is zero, "wMaxPacketSize" will be used,
-    multiplied by the "frames" field if the transfer type is
-    ISOCHRONOUS. This is useful for setting up interrupt pipes. This field is
-    mandatory.

-
NOTE: For control transfers "bufsize" includes the
-    length of the request structure.

-
callback pointer sets the USB callback. This
-    field is mandatory.

-

-

-

-
The usb module supports the Linux USB
-  API.

-

-

-

-
libusb(3), usb(4),
-    usbconfig(8)

-

-

-

-
The usb module complies with the USB 2.0
-    standard.

-

-

-

-
The usb module has been inspired by the
-    NetBSD USB stack initially written by Lennart Augustsson. The
-    usb module was written by Hans
-    Petter Selasky
-    <hselasky@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
November 14, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/vaccess.9 3.html b/static/freebsd/man9/vaccess.9 3.html
deleted file mode 100644
index 80cc8b09..00000000
--- a/static/freebsd/man9/vaccess.9 3.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
VACCESS(9)Kernel Developer's ManualVACCESS(9)

-

-

-

-
vaccess — generate
-    an access control decision using vnode parameters

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vaccess(enum vtype type,
-    mode_t file_mode, uid_t
-    file_uid, gid_t file_gid,
-    accmode_t accmode, struct ucred
-    *cred);

-

-

-

-
This call implements the logic for the
-    UNIX discretionary file security model common to
-    many file systems in FreeBSD. It accepts the vnodes
-    type type, permissions via
-    file_mode, owning UID file_uid,
-    owning GID file_gid, desired access mode
-    accmode and requesting credential
-    cred.

-
This call is intended to support implementations of
-    VOP_ACCESS(9), which will use their own access methods to
-    retrieve the vnode properties, and then invoke
-    ()
-    in order to perform the actual check. Implementations of
-    VOP_ACCESS(9) may choose to implement additional security
-    mechanisms whose results will be composed with the return value.

-
The algorithm used by
-    ()
-    selects a component of the file permission bits based on comparing the
-    passed credential, file owner, and file group. If the credential's effective
-    UID matches the file owner, then the owner component of the permission bits
-    is selected. If the UID does not match, then the credential's effective GID,
-    followed by additional groups, are compared with the file group—if
-    there is a match, then the group component of the permission bits is
-    selected. If neither the credential UID or GIDs match the passed file owner
-    and group, then the other component of the permission bits is selected.

-
Once appropriate protections are selected for the current
-    credential, the requested access mode, in combination with the vnode type,
-    will be compared with the discretionary rights available for the credential.
-    If the rights granted by discretionary protections are insufficient, then
-    super-user privilege, if available for the credential, will also be
-    considered.

-

-

-

-
vaccess() will return 0 on success, or a
-    non-zero error value on failure.

-

-

-

-

-  
[]

-  
Permission denied. An attempt was made to access a file in a way forbidden
-      by its file access permissions.

-  
[]

-  
Operation not permitted. An attempt was made to perform an operation
-      limited to processes with appropriate privileges or to the owner of a file
-      or other resource.

-

-

-

-

-
vaccess_acl_nfs4(9),
-    vaccess_acl_posix1e(9), vnode(9),
-    VOP_ACCESS(9)

-

-

-

-
This manual page and the current implementation of
-    vaccess() were written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
August 23, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/vaccess_acl_nfs4.9 3.html b/static/freebsd/man9/vaccess_acl_nfs4.9 3.html
deleted file mode 100644
index 809b8c41..00000000
--- a/static/freebsd/man9/vaccess_acl_nfs4.9 3.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
VACCESS_ACL_NFS4(9)Kernel Developer's ManualVACCESS_ACL_NFS4(9)

-

-

-

-
vaccess_acl_nfs4 —
-    generate a NFSv4 ACL access control decision using vnode
-    parameters

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/acl.h>

-
int
-  

-  vaccess_acl_nfs4(enum vtype
-    type, uid_t file_uid, gid_t
-    file_gid, struct acl *acl,
-    accmode_t accmode, struct ucred
-    *cred, int *privused);

-

-

-

-
This call implements the logic for the
-    UNIX discretionary file security model with NFSv4
-    ACL extensions. It accepts the vnodes type type,
-    owning UID file_uid, owning GID
-    file_gid, access ACL for the file
-    acl, desired access mode
-    accmode, requesting credential
-    cred, and an optional call-by-reference
-    int pointer returning whether or not privilege was
-    required for successful evaluation of the call; the
-    privused pointer may be set to
-    NULL by the caller in order not to be informed of
-    privilege information, or it may point to an integer that will be set to 1
-    if privilege is used, and 0 otherwise.

-
This call is intended to support
-    implementations of VOP_ACCESS(9), which will use their own
-    access methods to retrieve the vnode properties, and then invoke
-    ()
-    in order to perform the actual check. Implementations of
-    VOP_ACCESS(9) may choose to implement additional security
-    mechanisms whose results will be composed with the return value.

-
The algorithm used by
-    ()
-    is based on the NFSv4 ACL evaluation algorithm, as described in NFSv4 Minor
-    Version 1, draft-ietf-nfsv4-minorversion1-21.txt. The algorithm selects a
-    
-    entry from the access ACL, which may then be composed with an available ACL
-    mask entry, providing UNIX security
-  compatibility.

-
Once appropriate protections are selected for the current
-    credential, the requested access mode, in combination with the vnode type,
-    will be compared with the discretionary rights available for the credential.
-    If the rights granted by discretionary protections are insufficient, then
-    super-user privilege, if available for the credential, will also be
-    considered.

-

-

-

-
vaccess_acl_nfs4() will return 0 on
-    success, or a non-zero error value on failure.

-

-

-

-

-  
[]

-  
Permission denied. An attempt was made to access a file in a way forbidden
-      by its file access permissions.

-  
[]

-  
Operation not permitted. An attempt was made to perform an operation
-      limited to processes with appropriate privileges or to the owner of a file
-      or other resource.

-

-

-

-

-
vaccess(9), vnode(9),
-    VOP_ACCESS(9)

-

-

-

-
Current implementation of
-    vaccess_acl_nfs4() was written by
-    Edward Tomasz Napierala
-    <trasz@FreeBSD.org>.

-

-

-

-
This manual page should include a full description of the NFSv4
-    ACL evaluation algorithm, or cross reference another page that does.

-

-

-
-  
-    
-    
-  
-
September 18, 2009FreeBSD 15.0

diff --git a/static/freebsd/man9/vaccess_acl_posix1e.9 3.html b/static/freebsd/man9/vaccess_acl_posix1e.9 3.html
deleted file mode 100644
index d989a75f..00000000
--- a/static/freebsd/man9/vaccess_acl_posix1e.9 3.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
VACCESS_ACL_POSIX1E(9)Kernel Developer's ManualVACCESS_ACL_POSIX1E(9)

-

-

-

-
vaccess_acl_posix1e —
-    generate a POSIX.1e ACL access control decision using vnode
-    parameters

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/acl.h>

-
int
-  

-  vaccess_acl_posix1e(enum vtype
-    type, uid_t file_uid, gid_t
-    file_gid, struct acl *acl,
-    accmode_t accmode, struct ucred
-    *cred, int *privused);

-

-

-

-
This call implements the logic for the
-    UNIX discretionary file security model with POSIX.1e
-    ACL extensions. It accepts the vnodes type type,
-    owning UID file_uid, owning GID
-    file_gid, access ACL for the file
-    acl, desired access mode
-    accmode, requesting credential
-    cred, and an optional call-by-reference
-    int pointer returning whether or not privilege was
-    required for successful evaluation of the call; the
-    privused pointer may be set to
-    NULL by the caller in order not to be informed of
-    privilege information, or it may point to an integer that will be set to 1
-    if privilege is used, and 0 otherwise.

-
This call is intended to support
-    implementations of VOP_ACCESS(9), which will use their own
-    access methods to retrieve the vnode properties, and then invoke
-    ()
-    in order to perform the actual check. Implementations of
-    VOP_ACCESS(9) may choose to implement additional security
-    mechanisms whose results will be composed with the return value.

-
The algorithm used by
-    ()
-    is based on the POSIX.1e ACL evaluation algorithm. The algorithm selects a
-    
-    entry from the access ACL, which may then be composed with an available ACL
-    mask entry, providing UNIX security
-  compatibility.

-
Once appropriate protections are selected for the current
-    credential, the requested access mode, in combination with the vnode type,
-    will be compared with the discretionary rights available for the credential.
-    If the rights granted by discretionary protections are insufficient, then
-    super-user privilege, if available for the credential, will also be
-    considered.

-

-

-

-
vaccess_acl_posix1e() will return 0 on
-    success, or a non-zero error value on failure.

-

-

-

-

-  
[]

-  
Permission denied. An attempt was made to access a file in a way forbidden
-      by its file access permissions.

-  
[]

-  
Operation not permitted. An attempt was made to perform an operation
-      limited to processes with appropriate privileges or to the owner of a file
-      or other resource.

-

-

-

-

-
vaccess(9), vnode(9),
-    VOP_ACCESS(9)

-

-

-

-
This manual page and the current implementation of
-    vaccess_acl_posix1e() were written by
-    Robert Watson.

-

-

-

-
This manual page should include a full description of the POSIX.1e
-    ACL evaluation algorithm, or cross reference another page that does.

-

-

-
-  
-    
-    
-  
-
August 22, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vflush.9 4.html b/static/freebsd/man9/vflush.9 4.html
deleted file mode 100644
index e8531cea..00000000
--- a/static/freebsd/man9/vflush.9 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFLUSH(9)Kernel Developer's ManualVFLUSH(9)

-

-

-

-
vflush — flush
-    vnodes for a mount point

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vflush(struct
-    mount *mp, int
-    rootrefs, int
-    flags, struct thread
-    *td);

-

-

-

-
The
-    ()
-    function removes any vnodes in the vnode table that belong to the given
-    mount structure.

-
Its arguments are:

-

-  
mp

-  
The mount point whose vnodes should be removed.

-  
rootrefs

-  
The number of references expected on the root vnode.
-      vrele(9) will be invoked on the root vnode
-      rootrefs times.

-  
flags

-  
The flags indicating how vnodes should be handled.
-    

-      

-      
If set, busy vnodes will be forcibly closed.

-      

-      
If set, vnodes with the VV_SYSTEM flag set
-          will be skipped.

-      

-      
If set, only regular files currently opened for writing will be
-          removed.

-    

-  

-  
td

-  
The calling thread.

-

-

-

-

-
A value of 0 is returned if the flush is successful; otherwise,
-    EBUSY will be returned.

-

-

-

-
vgone(9), vrele(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
November 21, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_busy.9 4.html b/static/freebsd/man9/vfs_busy.9 4.html
deleted file mode 100644
index 56c7fa2e..00000000
--- a/static/freebsd/man9/vfs_busy.9 4.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_BUSY(9)Kernel Developer's ManualVFS_BUSY(9)

-

-

-

-
vfs_busy — marks a
-    mount point as busy

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  vfs_busy(struct
-    mount *mp, int
-    flags);

-

-

-

-
The
-    ()
-    function marks a mount point as busy by incrementing the reference count of
-    a mount point. It also delays unmounting by sleeping on
-    mp if the MNTK_UNMOUNT flag is
-    set in mp->mnt_kern_flag and the
-    MBF_NOWAIT flag is
-     set.

-
Its arguments are:

-

-  
mp

-  
The mount point to busy.

-  
flags

-  
Flags controlling how
-      ()
-      should act.
-    

-      

-      
do not sleep if MNTK_UNMOUNT is set.

-      

-      
drop the mountlist_mtx in the critical path.

-    

-  

-

-

-

-

-
A 0 value is returned on success. If the mount point is being
-    unmounted and MBF_NOWAIT flag is specified ENOENT
-    will be returned.

-

-

-

-

-  
[]

-  
The mount point is being unmounted (MNTK_UNMOUNT
-      is set).

-

-

-

-

-
vfs_unbusy(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
February 11, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_getnewfsid.9 4.html b/static/freebsd/man9/vfs_getnewfsid.9 4.html
deleted file mode 100644
index 62b4b66b..00000000
--- a/static/freebsd/man9/vfs_getnewfsid.9 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_GETNEWFSID(9)Kernel Developer's ManualVFS_GETNEWFSID(9)

-

-

-

-
vfs_getnewfsid —
-    allocate a new file system identifier

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
void
-  

-  vfs_getnewfsid(struct
-    mount *mp);

-

-

-

-
The
-    ()
-    function allocates a new file system identifier for the mount point given.
-    File systems typically call vfs_getnewfsid() in
-    their mount routine in order to acquire a unique ID within the system which
-    can later be used to uniquely identify the file system via calls such as
-    vfs_getvfs(9).

-
The actual fsid is made up of two 32 bit
-    integers, that are stored in the statfs structure of
-    mp. The first integer is unique in the set of mounted
-    file systems, while the second holds the file system type.

-

-
typedef	struct fsid {
-	int32_t val[2];
-} fsid_t;

-

-

-

-

-

-
xxx_mount(struct mount *mp, char *path, caddr_t data,
-	struct nameidata *ndp, struct thread *td)
-{
-	...
-	vfs_getnewfsid(mp);
-	...
-}

-

-

-

-

-
vfs_getvfs(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
November 21, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_getopt.9 4.html b/static/freebsd/man9/vfs_getopt.9 4.html
deleted file mode 100644
index 442b6a2a..00000000
--- a/static/freebsd/man9/vfs_getopt.9 4.html	
+++ /dev/null
@@ -1,176 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_GETOPT(9)Kernel Developer's ManualVFS_GETOPT(9)

-

-

-

-
vfs_getopt,
-    vfs_getopts, vfs_flagopt,
-    vfs_scanopt, vfs_copyopt,
-    vfs_filteropt, vfs_setopt,
-    vfs_setopt_part, vfs_setopts
-    — manipulate mount options and their
-  values

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  vfs_getopt(struct vfsoptlist
-    *opts, const char *name, void
-    **buf, int *len);

-
char *
-  

-  vfs_getopts(struct
-    vfsoptlist *opts, const
-    char *name, int
-    *error);

-
int
-  

-  vfs_flagopt(struct vfsoptlist
-    *opts, const char *name,
-    uint64_t *flags, uint64_t
-  flag);

-
int
-  

-  vfs_scanopt(struct vfsoptlist
-    *opts, const char *name, const
-    char *fmt, ...);

-
int
-  

-  vfs_copyopt(struct vfsoptlist
-    *opts, const char *name, void
-    *dest, int len);

-
int
-  

-  vfs_filteropt(struct vfsoptlist
-    *opts, const char **legal);

-
int
-  

-  vfs_setopt(struct vfsoptlist
-    *opts, const char *name, void
-    *value, int len);

-
int
-  

-  vfs_setopt_part(struct vfsoptlist
-    *opts, const char *name, void
-    *value, int len);

-
int
-  

-  vfs_setopts(struct vfsoptlist
-    *opts, const char *name, const
-    char *value);

-

-

-

-
The
-    ()
-    function sets buf to point to the value of the named
-    mount option, and sets len to the length of the value
-    if it is not NULL. The buf
-    argument will point to the actual value, and does not need to be freed or
-    released (and probably should not be modified).

-
The
-    ()
-    function returns the value of the specified option if it is a string (i.e.,
-    NUL terminated).

-
The
-    ()
-    function determines if an option exists. If the option does exist, and
-    flags is not NULL,
-    flag is added to those already set in
-    flags. If the option does not exist, and
-    flags is not NULL,
-    flag is removed from those already set in
-    flags. An example of typical usage is:

-

-
if (vfs_flagopt(mp->mnt_optnew, "wormlike", NULL, 0))
-	vfs_flagopt(mp->mnt_optnew, "appendok", &(mp->flags), F_APPENDOK);

-

-
The
-    ()
-    function performs a vsscanf(3) with the option's value,
-    using the given format, into the specified variable arguments. The value
-    must be a string (i.e., NUL terminated).

-
The
-    ()
-    function creates a copy of the option's value. The len
-    argument must match the length of the option's value exactly (i.e., a larger
-    buffer will still cause
-    ()
-    to fail with EINVAL).

-
The
-    ()
-    function ensures that no unknown options were specified. A option is valid
-    if its name matches one of the names in the list of legal names. An option
-    may be prefixed with 'no', and still be considered valid.

-
The
-    ()
-    and
-    ()
-    functions copy new data into the option's value. In
-    vfs_setopt(), the len argument
-    must match the length of the option's value exactly (i.e., a larger buffer
-    will still cause vfs_copyout() to fail with
-    EINVAL).

-
The
-    ()
-    function copies a new string into the option's value. The string, including
-    NUL byte, must be no longer than the option's
-    length.

-

-

-

-
The vfs_getopt() function returns 0 if the
-    option was found; otherwise, ENOENT is returned.

-
The vfs_getopts() function returns the
-    specified option if it is found, and is NUL
-    terminated. If the option was found, but is not NUL
-    terminated, error is set to
-    EINVAL and NULL is returned.
-    If the option was not found, error is set to 0, and
-    NULL is returned.

-
The vfs_flagopt() function returns 1 if
-    the option was found, and 0 if it was not.

-
The vfs_scanopt() function returns 0 if
-    the option was not found, or was not NUL terminated;
-    otherwise, the return value of vsscanf(3) is returned. If
-    vsscanf(3) returns 0, it will be returned unchanged;
-    therefore, a return value of 0 does not always mean the option does not
-    exist, or is not a valid string.

-
The vfs_copyopt() and
-    vfs_setopt() functions return 0 if the copy was
-    successful, EINVAL if the option was found but the
-    lengths did not match, and ENOENT if the option was
-    not found.

-
The vfs_filteropt() function returns 0 if
-    all of the options are legal; otherwise, EINVAL is
-    returned.

-
The vfs_setopts() function returns 0 if
-    the copy was successful, EINVAL if the option was
-    found but the string was too long, and ENOENT if the
-    option was not found.

-

-

-

-
This manual page was written by Chad David
-    <davidc@FreeBSD.org>
-    and Ruslan Ermilov
-    <ru@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
May 19, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_getvfs.9 4.html b/static/freebsd/man9/vfs_getvfs.9 4.html
deleted file mode 100644
index 917d858c..00000000
--- a/static/freebsd/man9/vfs_getvfs.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_GETVFS(9)Kernel Developer's ManualVFS_GETVFS(9)

-

-

-

-
vfs_getvfs —
-    returns a mount point given its file system
-    identifier

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
struct mount *
-  

-  vfs_getvfs(fsid_t
-    *fsid);

-

-

-

-
The
-    ()
-    function returns the mount point structure for a file system given its file
-    system identifier. The file system ID should have been allocated by calling
-    vfs_getnewfsid(9); otherwise, it will not be found.

-
A major user of
-    ()
-    is NFS, which uses the fsid as part of file handles in
-    order to determine the file system a given RPC is for. If
-    vfs_getvfs() fails to find the mount point related
-    to fsid, the file system is considered stale.

-

-

-

-
If fsid is found, the mount point for the ID
-    is returned; otherwise, NULL is returned.

-

-

-

-

-
if ((mp = vfs_getvfs(&fhp->fh_fsid)) == NULL) {
-	error = ESTALE;
-	goto out;
-}

-

-

-

-

-
vfs_getnewfsid(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
November 21, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_mountedfrom.9 4.html b/static/freebsd/man9/vfs_mountedfrom.9 4.html
deleted file mode 100644
index a7fefa18..00000000
--- a/static/freebsd/man9/vfs_mountedfrom.9 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_MOUNTEDFROM(9)Kernel Developer's ManualVFS_MOUNTEDFROM(9)

-

-

-

-
vfs_mountedfrom —
-    sets the mounted from name for a mount

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
void
-  

-  vfs_mountedfrom(struct
-    mount *mp, const char
-    *from);

-

-

-

-
The
-    ()
-    function sets the mounted from name for a mount. This value is used by
-    (2)
-    to fill in f_mntfromname.

-
In most cases from is the device that
-    contains the file system, but in the case of a pseudo file system it could
-    be a descriptive name like "devfs" or "procfs".

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
February 25, 2008FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_rootmountalloc.9 4.html b/static/freebsd/man9/vfs_rootmountalloc.9 4.html
deleted file mode 100644
index d33a6f01..00000000
--- a/static/freebsd/man9/vfs_rootmountalloc.9 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_ROOTMOUNTALLOC(9)Kernel Developer's ManualVFS_ROOTMOUNTALLOC(9)

-

-

-

-
vfs_rootmountalloc —
-    allocate a root mount
-    structure

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  vfs_rootmountalloc(char
-    *fstypename, char
-    *devname, struct mount
-    **mpp);

-

-

-

-
()
-    allocates a mount structure initialized from the
-    vfsconf type that matches
-    fstypename.

-

-

-

-
If successful, 0 is returned and mpp points
-    to the newly allocated mount structure.
-    ENODEV is returned if
-    fstypename is NULL or
-  invalid.

-

-

-

-
vfsconf(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
November 21, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_suser.9 4.html b/static/freebsd/man9/vfs_suser.9 4.html
deleted file mode 100644
index ae8790a7..00000000
--- a/static/freebsd/man9/vfs_suser.9 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_SUSER(9)Kernel Developer's ManualVFS_SUSER(9)

-

-

-

-
vfs_suser — check
-    if credentials have superuser privileges for a mount point

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  vfs_suser(struct
-    mount *mp, struct thread
-    *td);

-

-

-

-
The
-    ()
-    function checks if the credentials given include superuser powers for the
-    given mount point. It will check to see if the thread passed in has the same
-    credentials as the user that mounted the file system. If so, it returns 0,
-    otherwise it returns what priv_check(9) would have
-    returned.

-

-

-

-
The vfs_suser() function returns 0 if the
-    user has superuser powers and EPERM otherwise. This
-    is the
-     of some other implementations of
-    suser() in which a TRUE response indicates superuser
-    powers.

-

-

-

-
chroot(2), jail(2)

-

-

-

-
The vfs_suser() function was introduced in
-    FreeBSD 5.2.

-

-

-

-
This manual page was written by Alfred
-    Perlstein.

-

-

-
-  
-    
-    
-  
-
April 2, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_timestamp.9 4.html b/static/freebsd/man9/vfs_timestamp.9 4.html
deleted file mode 100644
index a3073888..00000000
--- a/static/freebsd/man9/vfs_timestamp.9 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_TIMESTAMP(9)Kernel Developer's ManualVFS_TIMESTAMP(9)

-

-

-

-
vfs_timestamp —
-    generate current timestamp

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
void
-  

-  vfs_timestamp(struct
-    timespec *tsp);

-

-

-

-
The
-    ()
-    function fills in tsp with the current time.

-
The precision is based on the value of the
-    vfs.timestamp_precision sysctl variable:

-

-

-  
0

-  
seconds only; nanoseconds are zeroed.

-  
1

-  
seconds and nanoseconds, accurate within 1/HZ.

-  
2

-  
seconds and nanoseconds, truncated to microseconds.

-  
≥3

-  
seconds and nanoseconds, maximum precision.

-

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
November 21, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_unbusy.9 4.html b/static/freebsd/man9/vfs_unbusy.9 4.html
deleted file mode 100644
index c18fa727..00000000
--- a/static/freebsd/man9/vfs_unbusy.9 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_UNBUSY(9)Kernel Developer's ManualVFS_UNBUSY(9)

-

-

-

-
vfs_unbusy —
-    unbusy a mount point

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
void
-  

-  vfs_unbusy(struct
-    mount *mp);

-

-

-

-
The
-    ()
-    function un-busies a mount point by decrementing the reference count of a
-    mount point. The reference count is typically incremented by calling
-    vfs_busy(9) prior to this call.

-
Its arguments are:

-

-  
mp

-  
The mount point to unbusy.

-

-

-

-

-
vfs_busy(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
June 14, 2010FreeBSD 15.0

diff --git a/static/freebsd/man9/vfs_unmountall.9 4.html b/static/freebsd/man9/vfs_unmountall.9 4.html
deleted file mode 100644
index 910d0eb3..00000000
--- a/static/freebsd/man9/vfs_unmountall.9 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS_UNMOUNTALL(9)Kernel Developer's ManualVFS_UNMOUNTALL(9)

-

-

-

-
vfs_unmountall —
-    unmount all file systems

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
void
-  

-  vfs_unmountall(void);

-

-

-

-
The vfs_unmountall function, run only at
-    system shutdown, unmounts all mounted file systems from most recent to
-    oldest in order to avoid handling dependencies.

-

-

-

-
boot(9)

-

-

-
-  
-    
-    
-  
-
July 26, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vfsconf.9 3.html b/static/freebsd/man9/vfsconf.9 3.html
deleted file mode 100644
index bac8b42c..00000000
--- a/static/freebsd/man9/vfsconf.9 3.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFSCONF(9)Kernel Developer's ManualVFSCONF(9)

-

-

-

-
vfsconf — vfs
-    configuration information

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>

-
int
-  

-  vfs_register(struct
-    vfsconf *vfc);

-
int
-  

-  vfs_unregister(struct
-    vfsconf *vfc);

-
int
-  

-  vfs_modevent(module_t
-    mod, int type,
-    void *data);

-

-

-

-
Each file system type known to the kernel has a
-    vfsconf structure that contains the information
-    required to create a new mount of that file systems type.

-

-
struct vfsconf {
-	struct	vfsops *vfc_vfsops;	/* file system operations vector */
-	char	vfc_name[MFSNAMELEN];	/* file system type name */
-	int	vfc_typenum;		/* historic file system type number */
-	int	vfc_refcount;		/* number mounted of this type */
-	int	vfc_flags;		/* permanent flags */
-	struct	vfsconf *vfc_next;	/* next in list */
-};

-

-
When a new file system is mounted,
-    mount(2) does a lookup of the
-    vfsconf structure by its name, and if it is not
-    already registered, attempts to load a kernel module for it. The file system
-    operations for the new mount point are taken from
-    vfc_vfsops, and mnt_vfc in the
-    mount structure is made to point directly at the
-    vfsconf structure for the file system type. The file
-    system type number is taken from vfc_typenum which was
-    assigned in
-    (),
-    and the mount flags are taken from a mask of
-    vfc_flags. Each time a file system of a given type is
-    mounted, vfc_refcount is incremented.

-
()
-    takes a new vfsconf structure and adds it to the list
-    of existing file systems. If the type has not already been registered, it is
-    initialized by calling the
-    ()
-    function in the file system operations vector.
-    vfs_register() also updates the oid's of any sysctl
-    nodes for this file system type to be the same as the newly assigned type
-    number.

-
()
-    unlinks vfc from the list of registered file system
-    types if there are currently no mounted instances. If the
-    ()
-    function in the file systems initialization vector is defined, it is
-  called.

-
()
-    is registered by
-    ()
-    to handle the loading and unloading of file system kernel modules. In the
-    case of MOD_LOAD,
-    vfs_register() is called. In the case of
-    MOD_UNLOAD, vfs_unregister()
-    is called.

-

-

-

-
vfs_register() returns 0 if successful;
-    otherwise, EEXIST is returned indicating that the
-    file system type has already been registered.

-
vfs_unregister() returns 0 if successful.
-    If no vfsconf entry can be found matching the name in
-    vfc, EINVAL is returned. If
-    the reference count of mounted instances of the file system type is not
-    zero, EBUSY is returned. If
-    vfs_uninit() is called, any errors it returns will
-    be returned by vfs_unregister().

-
vfs_modevent() returns the result of the
-    call to vfs_register() or
-    vfs_unregister(), whatever the case.

-

-

-

-
mount(2),
-    vfs_rootmountalloc(9), VFS_SET(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
June 16, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/vget.9 4.html b/static/freebsd/man9/vget.9 4.html
deleted file mode 100644
index 5c45def3..00000000
--- a/static/freebsd/man9/vget.9 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
VGET(9)Kernel Developer's ManualVGET(9)

-

-

-

-
vget — get a vnode
-    from the free list

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vget(struct
-    vnode *vp, int
-    lockflag, struct thread
-    *td);

-

-

-

-
Get a vnode from the free list and increment its reference
-  count.

-

-  
vp

-  
The vnode to remove from the free list.

-  
lockflag

-  
If non-zero, the vnode will also be locked.

-

-
When not in use, vnodes are kept on a free list. The vnodes still
-    reference valid files but may be reused to refer to a new file at any time.
-    Often, these vnodes are also held in caches in the system, such as the name
-    cache.

-
When a vnode which is on the free list is used again,
-    for instance if the vnode was found in the name cache as a result of a call
-    to VOP_LOOKUP(9) then the new user must call
-    () to
-    increment the reference count and remove it from the free list.

-

-

-

-
vnode(9), vput(9),
-    vref(9), vrele(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 24, 1996FreeBSD 15.0

diff --git a/static/freebsd/man9/vgone.9 4.html b/static/freebsd/man9/vgone.9 4.html
deleted file mode 100644
index a79439d5..00000000
--- a/static/freebsd/man9/vgone.9 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
VGONE(9)Kernel Developer's ManualVGONE(9)

-

-

-

-
vgone — prepare a
-    vnode for reuse

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
void
-  

-  vgone(struct
-    vnode *vp);

-

-

-

-
The
-    ()
-    function prepares the vnode to be destroyed. The preparation includes the
-    cleaning of all file system specific data and the removal from its mount
-    point vnode list.

-
If the vnode has a v_usecount of zero, and
-    its VIRF_DOOMED flag is not set, it is moved to the
-    head of the free list as in most cases the vnode is about to be reused, or
-    its file system is being unmounted.

-
The
-    ()
-    function takes an exclusively locked vnode, and returns with the vnode
-    exclusively locked.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
December 8, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/vhold.9 4.html b/static/freebsd/man9/vhold.9 4.html
deleted file mode 100644
index 2cc31278..00000000
--- a/static/freebsd/man9/vhold.9 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
VHOLD(9)Kernel Developer's ManualVHOLD(9)

-

-

-

-
vhold, vdrop,
-    vdropl — acquire/release a
-    hold on a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
void
-  

-  vhold(struct
-    vnode *vp);

-
void
-  

-  vholdl(struct
-    vnode *vp);

-
void
-  

-  vdrop(struct
-    vnode *vp);

-
void
-  

-  vdropl(struct
-    vnode *vp);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions increment the v_holdcnt of the given vnode.
-    If the vnode has already been added to the free list and is still
-    referenced, it will be removed.

-
The
-    () and
-    ()
-    functions decrement the v_holdcnt of the vnode. If the
-    holdcount is less than or equal to zero prior to calling
-    vdrop() or vdropl(), the
-    system will panic. If the vnode is no longer referenced, it will be
-  freed.

-
()
-    and vdrop() lock the vnode interlock while
-    vholdl() and vdropl() expect
-    the interlock to already be held.

-

-

-

-
vnode(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
April 1, 2007FreeBSD 15.0

diff --git a/static/freebsd/man9/vinvalbuf.9 4.html b/static/freebsd/man9/vinvalbuf.9 4.html
deleted file mode 100644
index 8e16da5b..00000000
--- a/static/freebsd/man9/vinvalbuf.9 4.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
VINVALBUF(9)Kernel Developer's ManualVINVALBUF(9)

-

-

-

-
vinvalbuf —
-    flushes and invalidates all buffers associated with a
-    vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vinvalbuf(struct
-    vnode *vp, int
-    flags, struct ucred
-    *cred, int slpflag,
-    int slptimeo);

-

-

-

-
The
-    ()
-    function invalidates all of the buffers associated with the given vnode.
-    This includes buffers on the clean list and the dirty list. If the
-    V_SAVE flag is specified then the buffers on the
-    dirty list are synced prior to being released. If there is a VM Object
-    associated with the vnode, it is removed.

-
Its arguments are:

-

-  
vp

-  
A pointer to the vnode whose buffers will be invalidated.

-  
flags

-  
The only supported flag is V_SAVE and it indicates
-      that dirty buffers should be synced with the disk.

-  
cred

-  
The user credentials that are used to VOP_FSYNC(9)
-      buffers if V_SAVE is set.

-  
slpflag

-  
The slp flag that will be used in the priority of any sleeps in the
-      function.

-  
slptimeo

-  
The timeout for any sleeps in the function.

-

-

-

-

-
The vnode is assumed to be locked prior to the call and remains
-    locked upon return.

-
Giant must be held by prior to the call and
-    remains locked upon return.

-

-

-

-
A 0 value is returned on success.

-

-

-

-

-
vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY);
-error = vinvalbuf(devvp, V_SAVE, cred, 0, 0);
-VOP_UNLOCK(devvp, 0);
-if (error)
-	return (error);

-

-

-

-

-

-  
[]

-  
The file system is full. (With V_SAVE)

-  
[]

-  
Disc quota exceeded. (With V_SAVE)

-  
[]

-  
Sleep operation timed out. (See slptimeo)

-  
[]

-  
A signal needs to be delivered and the system call should be restarted.
-      (With PCATCH set in
-    slpflag)

-  
[]

-  
The system has been interrupted by a signal. (With
-      PCATCH set in slpflag)

-

-

-

-

-
tsleep(9), VOP_FSYNC(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
October 20, 2008FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_fault_prefault.9 4.html b/static/freebsd/man9/vm_fault_prefault.9 4.html
deleted file mode 100644
index 5f73900c..00000000
--- a/static/freebsd/man9/vm_fault_prefault.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_FAULT_PREFAULT(9)Kernel Developer's ManualVM_FAULT_PREFAULT(9)

-

-

-

-
vm_fault_prefault —
-    cluster page faults into a process's address
-  space

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/pmap.h>

-
void
-  

-  vm_fault_prefault(pmap_t
-    pmap, vm_offset_t
-    addra, vm_map_entry_t
-    entry);

-

-

-

-
The
-    ()
-    function provides a means of clustering pagefaults into a process's address
-    space. It operates upon the physical map pmap. The
-    entry argument specifies the entry to be prefaulted;
-    the addra argument specifies the beginning of the
-    mapping in the process's virtual address space.

-
It is typically called by
-    ()
-    after the first page fault. It benefits the execve(2)
-    system call by eliminating repetitive calls to
-    vm_fault(), which would otherwise be made to bring
-    the process's executable pages into physical memory.

-

-

-

-
This is a machine-independent function which calls the
-    machine-dependent pmap_is_prefaultable(9) helper function
-    to determine if a page may be prefaulted into physical memory.

-

-

-

-
execve(2),
-    pmap_is_prefaultable(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map.9 4.html b/static/freebsd/man9/vm_map.9 4.html
deleted file mode 100644
index c6cb9812..00000000
--- a/static/freebsd/man9/vm_map.9 4.html	
+++ /dev/null
@@ -1,290 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP(9)Kernel Developer's ManualVM_MAP(9)

-

-

-

-
vm_map — virtual
-    address space portion of virtual memory subsystem

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-

-

-

-
The vm_map subsystem is used to manage
-    virtual address spaces. This section describes the main data structures used
-    within the code.

-
The struct vm_map is a generic
-    representation of an address space. This address space may belong to a user
-    process or the kernel. The kernel actually uses several maps, which are
-    maintained as subordinate maps, created using the
-    vm_map_submap(9) function.

-

-
struct vm_map {
-	struct vm_map_entry header;
-	union {
-	        struct sx lock;
-		struct mtx system_mtx;
-	};
-        int nentries;
-        vm_size_t size;
-        u_int timestamp;
-        u_int flags;
-        vm_map_entry_t root;
-        pmap_t pmap;
-        int busy;
-};

-

-
The fields of struct vm_map are as
-  follows:

-

-  
-  
Head node of a circular, doubly linked list of struct
-      vm_map_entry objects. Each object defines a particular region within
-      this map's address space.

-  
lock

-  
Used to serialize access to the structure.

-  
system_mtx

-  
A mutex which is used if the map is a system map.

-  
nentries

-  
A count of the members in use within the circular map entry list.

-  
size

-  
Specifies the size of the virtual address space.

-  
timestamp

-  
Used to determine if the map has changed since its last access.

-  
flags

-  
Map flags, described below.

-  
root

-  
Root node of a binary search tree used for fast lookup of map
-    entries.

-  
pmap

-  
Pointer to the underlying physical map with which this virtual map is
-      associated.

-  
busy

-  
Map busy counter, prevents forks.

-

-
Possible map flags:

-

-  

-  
Wire all future pages in this map.

-  

-  
There are waiters for the map busy status.

-  
MAP_NEEDS_WAKEUP

-  
Indicates if a thread is waiting for an allocation within the map. Used
-      only by system maps.

-  
MAP_SYSTEM_MAP

-  
If set, indicates that the map is the system map; otherwise, it belongs to
-      a user process.

-

-
The following flags can be passed to
-    vm_map_find(9) and vm_map_insert(9) to
-    specify the copy-on-write properties of regions within the map:

-

-  

-  
The mapping is copy-on-write.

-  

-  
The mapping should not generate page faults.

-  

-  
The mapping should be prefaulted into physical memory.

-  

-  
The mapping should be partially prefaulted into physical memory.

-  

-  
Do not periodically flush dirty pages; only flush them when absolutely
-      necessary.

-  

-  
Do not include the mapping in a core dump.

-  

-  
Specify that the request is from a user process calling
-      madvise(2).

-  

-  
Region is already charged to the requestor by some means.

-  

-  
Do not charge for allocated region.

-

-
The struct vm_map_entry is a generic
-    representation of a region. The region managed by each entry is associated
-    with a union vm_map_object, described below.

-

-
struct vm_map_entry {
-        struct vm_map_entry *prev;
-        struct vm_map_entry *next;
-        struct vm_map_entry *left;
-        struct vm_map_entry *right;
-        vm_offset_t start;
-        vm_offset_t end;
-        vm_offset_t avail_ssize;
-        vm_size_t adj_free;
-        vm_size_t max_free;
-        union vm_map_object object;
-        vm_ooffset_t offset;
-        vm_eflags_t eflags;
-        /* Only in task maps: */
-        vm_prot_t protection;
-        vm_prot_t max_protection;
-        vm_inherit_t inheritance;
-        int wired_count;
-        vm_pindex_t lastr;
-};

-

-
The fields of struct vm_map_entry are as
-    follows:

-

-  
prev

-  
Pointer to the previous node in a doubly-linked, circular list.

-  
next

-  
Pointer to the next node in a doubly-linked, circular list.

-  
left

-  
Pointer to the left node in a binary search tree.

-  
-  
Pointer to the right node in a binary search tree.

-  
start

-  
Lower address bound of this entry's region.

-  
end

-  
Upper address bound of this entry's region.

-  
avail_ssize

-  
If the entry is for a process stack, specifies how much the entry can
-      grow.

-  
adj_free

-  
The amount of free, unmapped address space adjacent to and immediately
-      following this map entry.

-  
max_free

-  
The maximum amount of contiguous free space in this map entry's
-    subtree.

-  
object

-  
Pointer to the struct vm_map_object with which this
-      entry is associated.

-  
offset

-  
Offset within the object which is mapped from
-      start onwards.

-  
eflags

-  
Flags applied to this entry, described below.

-

-
The following five members are only valid for entries forming part
-    of a user process's address space:

-

-  
protection

-  
Memory protection bits applied to this region.

-  
max_protection

-  
Mask for the memory protection bits which may be actually be applied to
-      this region.

-  
inheritance

-  
Contains flags which specify how this entry should be treated during fork
-      processing.

-  
wired_count

-  
Count of how many times this entry has been wired into physical
-    memory.

-  
lastr

-  
Contains the address of the last read which caused a page fault.

-

-
The following flags may be applied to each entry, by specifying
-    them as a mask within the eflags member:

-

-  

-  
The system should not flush the data associated with this map
-      periodically, but only when it needs to.

-  

-  
If set, then the object member specifies a
-      subordinate map.

-  

-  
Indicate that this is a copy-on-write region.

-  

-  
Indicate that a copy-on-write region needs to be copied.

-  

-  
Specifies that accesses within this region should never cause a page
-      fault. If a page fault occurs within this region, the system will
-    panic.

-  

-  
Indicate that this region was wired on behalf of a user process.

-  

-  
The system should use the default paging behaviour for this region.

-  

-  
The system should depress the priority of pages immediately preceding each
-      page within this region when faulted in.

-  

-  
Is a hint that pages within this region will be accessed randomly, and
-      that prefetching is likely not advantageous.

-  

-  
Indicate that wiring or unwiring of an entry is in progress, and that
-      other kernel threads should not attempt to modify fields in the
-    structure.

-  

-  
Indicate that there are kernel threads waiting for this region to become
-      available.

-  

-  
The region should not be included in a core dump.

-

-
The inheritance member has type
-    vm_inherit_t. This governs the inheritance behaviour
-    for a map entry during fork processing. The following values are defined for
-    vm_inherit_t:

-

-  

-  
The object associated with the entry should be cloned and shared with the
-      new map. A new struct vm_object will be created if
-      necessary.

-  

-  
The object associated with the entry should be copied to the new map.

-  

-  
The entry should not be copied to the new map.

-  

-  
Specifies the default behaviour,
-    VM_INHERIT_COPY.

-

-
The union vm_map_object is used to specify
-    the structure which a struct vm_map_entry is
-    associated with.

-
The fields of union vm_map_object are as
-    follows:

-

-
union vm_map_object {
-        struct vm_object *vm_object;
-        struct vm_map *sub_map;
-};

-

-
Normally, the sub_map member is only used by
-    system maps to indicate that a memory range is managed by a subordinate
-    system map. Within a user process map, each struct
-    vm_map_entry is backed by a struct
-  vm_object.

-

-

-

-
pmap(9),
-    vm_map_check_protection(9),
-    vm_map_delete(9),
-    vm_map_entry_resize_free(9),
-    vm_map_find(9), vm_map_findspace(9),
-    vm_map_inherit(9), vm_map_init(9),
-    vm_map_insert(9), vm_map_lock(9),
-    vm_map_lookup(9), vm_map_madvise(9),
-    vm_map_max(9), vm_map_min(9),
-    vm_map_pmap(9), vm_map_protect(9),
-    vm_map_remove(9), vm_map_stack(9),
-    vm_map_submap(9), vm_map_sync(9),
-    vm_map_wire(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 3, 2018FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_check_protection.9 4.html b/static/freebsd/man9/vm_map_check_protection.9 4.html
deleted file mode 100644
index bce222b6..00000000
--- a/static/freebsd/man9/vm_map_check_protection.9 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_CHECK_PROTECTION(9)Kernel Developer's ManualVM_MAP_CHECK_PROTECTION(9)

-

-

-

-
vm_map_check_protection —
-    check memory protection for a vm_map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
boolean_t
-  

-  vm_map_check_protection(vm_map_t
-    map, vm_offset_t start,
-    vm_offset_t end, vm_prot_t
-    protection);

-

-

-

-
The
-    ()
-    function asserts that the target map allows the
-    specified privilege protection over the entire address
-    range from start to end. The
-    region MUST be contiguous; no holes are allowed.

-

-

-

-
This code does not and SHOULD not check whether the contents of
-    the region are accessible. For example, a small file may be mapped into an
-    address space which is significantly larger in size.

-

-

-

-
The vm_map_check_protection() function
-    returns TRUE if the privilege is allowed; if it is not allowed, or if any
-    other error occurred, the value FALSE is returned.

-

-

-

-
munmap(2), vm_map(9),
-    vm_map_protect(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_delete.9 4.html b/static/freebsd/man9/vm_map_delete.9 4.html
deleted file mode 100644
index c3cd8010..00000000
--- a/static/freebsd/man9/vm_map_delete.9 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_DELETE(9)Kernel Developer's ManualVM_MAP_DELETE(9)

-

-

-

-
vm_map_delete —
-    deallocate an address range from a map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_delete(vm_map_t
-    map, vm_offset_t
-    start, vm_offset_t
-    end);

-

-

-

-
The
-    ()
-    function deallocates the address range bounded by
-    start and end from the
-    map.

-

-

-

-
This function is for FreeBSD VM internal
-    use only. The vm_map_remove(9) function should be called
-    by FreeBSD VM consumers instead.

-

-

-

-
The vm_map_delete() function always
-    returns KERN_SUCCESS.

-

-

-

-
vm_map(9),
-  vm_map_remove(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_entry_resize_free.9 3.html b/static/freebsd/man9/vm_map_entry_resize_free.9 3.html
deleted file mode 100644
index 11a88d84..00000000
--- a/static/freebsd/man9/vm_map_entry_resize_free.9 3.html	
+++ /dev/null
@@ -1,176 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_ENTRY_RESIZE_FREE(9)Kernel Developer's ManualVM_MAP_ENTRY_RESIZE_FREE(9)

-

-

-

-
vm_map_entry_resize_free —
-    vm map free space algorithm

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
void
-  

-  vm_map_entry_resize_free(vm_map_t
-    map, vm_map_entry_t
-    entry);

-

-

-

-
This manual page describes the vm_map_entry
-    fields used in the VM map free space algorithm, how to maintain consistency
-    of these variables, and the
-    ()
-    function.

-
VM map entries are organized as both a doubly-linked list
-    (prev and next pointers) and as
-    a binary search tree (left and
-    right pointers). The search tree is organized as a
-    Sleator and Tarjan splay tree, also known as a “self-adjusting
-    tree”.

-

-
struct vm_map_entry {
-        struct vm_map_entry *prev;
-        struct vm_map_entry *next;
-        struct vm_map_entry *left;
-        struct vm_map_entry *right;
-        vm_offset_t start;
-        vm_offset_t end;
-        vm_offset_t avail_ssize;
-        vm_size_t adj_free;
-        vm_size_t max_free;
-        ...
-};

-

-
The free space algorithm adds two fields to struct
-    vm_map_entry: adj_free and
-    max_free. The adj_free field is
-    the amount of free address space adjacent to and immediately following
-    (higher address) the map entry. This field is unused in the map header. Note
-    that adj_free depends on the linked list, not the
-    splay tree and that adj_free can be computed as:

-

-
entry->adj_free = (entry->next == &map->header ?
-    map->max_offset : entry->next->start) - entry->end;

-

-
The max_free field is the maximum amount of
-    contiguous free space in the entry's subtree. Note that
-    max_free depends on the splay tree, not the linked
-    list and that max_free is computed by taking the
-    maximum of its own adj_free and the
-    max_free of its left and right subtrees. Again,
-    max_free is unused in the map header.

-
These fields allow for an
-    (log
-    n) implementation of
-    ().
-    Using max_free, we can immediately test for a
-    sufficiently large free region in an entire subtree. This makes it possible
-    to find a first-fit free region of a given size in one pass down the tree,
-    so O(log n) amortized using
-    splay trees.

-
When a free region changes size, we must
-    update adj_free and max_free in
-    the preceding map entry and propagate max_free up the
-    tree. This is handled in
-    ()
-    and
-    ()
-    for the cases of inserting and deleting an entry. Note that
-    vm_map_entry_link() updates both the new entry and
-    the previous entry, and that vm_map_entry_unlink()
-    updates the previous entry. Also note that max_free is
-    not actually propagated up the tree. Instead, that entry is first splayed to
-    the root and then the change is made there. This is a common technique in
-    splay trees and is also how map entries are linked and unlinked into the
-    tree.

-
The
-    ()
-    function updates the free space variables in the given
-    entry and propagates those values up the tree. This
-    function should be called whenever a map entry is resized in-place, that is,
-    by modifying its start or end
-    values. Note that if you change end, then you should
-    resize that entry, but if you change start, then you
-    should resize the previous entry. The map must be locked before calling this
-    function, and again, propagating max_free is performed
-    by splaying that entry to the root.

-

-

-

-
Consider adding a map entry with
-    vm_map_insert().

-

-
ret = vm_map_insert(map, object, offset, start, end, prot,
-    max_prot, cow);

-

-
In this case, no further action is required to maintain
-    consistency of the free space variables. The
-    vm_map_insert() function calls
-    vm_map_entry_link() which updates both the new entry
-    and the previous entry. The same would be true for
-    vm_map_delete() and for calling
-    vm_map_entry_link() or
-    vm_map_entry_unlink() directly.

-
Now consider resizing an entry in-place without a call to
-    vm_map_entry_link() or
-    vm_map_entry_unlink().

-

-
entry->start = new_start;
-if (entry->prev != &map->header)
-        vm_map_entry_resize_free(map, entry->prev);

-

-
In this case, resetting start changes the
-    amount of free space following the previous entry, so we use
-    vm_map_entry_resize_free() to update the previous
-    entry.

-
Finally, suppose we change an entry's end
-    address.

-

-
entry->end = new_end;
-vm_map_entry_resize_free(map, entry);

-

-
Here, we call vm_map_entry_resize_free()
-    on the entry itself.

-

-

-

-
vm_map(9),
-  vm_map_findspace(9)

-
Daniel D. Sleator and
-    Robert E. Tarjan, Self-Adjusting
-    Binary Search Trees, JACM, vol.
-    32(3), pp. 652-686, July
-    1985.

-

-

-

-
Splay trees were added to the VM map in FreeBSD
-    5.0, and the O(log n)
-    tree-based free space algorithm was added in FreeBSD
-    5.3.

-

-

-

-
The tree-based free space algorithm and this manual page were
-    written by Mark W. Krentel
-    <krentel@dreamscape.com>.

-

-

-
-  
-    
-    
-  
-
August 17, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_find.9 3.html b/static/freebsd/man9/vm_map_find.9 3.html
deleted file mode 100644
index 059a93bd..00000000
--- a/static/freebsd/man9/vm_map_find.9 3.html	
+++ /dev/null
@@ -1,122 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_FIND(9)Kernel Developer's ManualVM_MAP_FIND(9)

-

-

-

-
vm_map_find — find
-    a free region within a map, and optionally map a vm_object

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_find(vm_map_t map,
-    vm_object_t object, vm_ooffset_t
-    offset, vm_offset_t *addr,
-    vm_size_t length, vm_offset_t
-    max_addr, int find_space,
-    vm_prot_t prot, vm_prot_t max,
-    int cow);

-

-

-

-
The
-    ()
-    function attempts to find a free region in the target
-    map, with the given length. If a
-    free region is found, vm_map_find() creates a
-    mapping of object via a call to
-    vm_map_insert(9).

-
The arguments offset,
-    prot, max, and
-    cow are passed unchanged to
-    vm_map_insert(9) when creating the mapping, if and only if
-    a free region is found.

-
If object is
-    non-NULL, the reference count on the object must be
-    incremented by the caller before calling this function to account for the
-    new entry.

-
If max_addr is non-zero, it specifies an
-    upper bound on the mapping. The mapping will only succeed if a free region
-    can be found that resides entirely below max_addr.

-
The find_space argument specifies the
-    strategy to use when searching for a free region of the requested length.
-    For all values other than VMFS_NO_SPACE,
-    vm_map_findspace(9) is called to locate a free region of
-    the requested length with a starting address at or above
-    *addr. The following strategies are supported:

-

-  

-  
The mapping will only succeed if there is a free region of the requested
-      length at the given address *addr.

-  

-  
The mapping will succeed as long as there is a free region.

-  

-  
The mapping will succeed as long as there is a free region that begins on
-      a superpage boundary. If object is
-      non-NULL and is already backed by superpages, then
-      the mapping will require a free region that aligns relative to the
-      existing superpages rather than one beginning on a superpage
-    boundary.

-  

-  
The mapping will succeed as long as there is a free region. However, if
-      object is non-NULL and is
-      already backed by superpages, this strategy will attempt to find a free
-      region aligned relative to the existing superpages.

-  
(n)

-  
The mapping will succeed as long as there is a free region that aligns on
-      a 2^n boundary.

-

-

-

-

-
This function acquires a lock on map by
-    calling vm_map_lock(9), and holds it until the function
-    returns.

-
The search for a free region is defined to be first-fit, from the
-    address addr onwards.

-

-

-

-
The vm_map_find() function returns
-    KERN_SUCCESS if the mapping was successfully
-    created. If space could not be found or find_space was
-    VMFS_NO_SPACE and the given address,
-    addr, was already mapped,
-    KERN_NO_SPACE will be returned. If the discovered
-    range turned out to be bogus, KERN_INVALID_ADDRESS
-    will be returned.

-

-

-

-
vm_map(9),
-    vm_map_findspace(9), vm_map_insert(9),
-    vm_map_lock(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
September 12, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_findspace.9 4.html b/static/freebsd/man9/vm_map_findspace.9 4.html
deleted file mode 100644
index a9452ff0..00000000
--- a/static/freebsd/man9/vm_map_findspace.9 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_FINDSPACE(9)Kernel Developer's ManualVM_MAP_FINDSPACE(9)

-

-

-

-
vm_map_findspace —
-    find a free region within a map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_findspace(vm_map_t map,
-    vm_offset_t start, vm_size_t
-    length, vm_offset_t *addr);

-

-

-

-
The
-    ()
-    function attempts to find a region with sufficient space in the
-    map for an object of size length
-    at the address addr.

-

-

-

-
It is the caller's responsibility to obtain a lock on the
-    map using vm_map_lock(9) before
-    calling this function.

-
This routine may call pmap_growkernel(9) to grow
-    the kernel's address space, if and only if the mapping is being made within
-    the kernel address space, and if insufficient space remains in the
-    kernel_map.

-

-

-

-
The vm_map_findspace() function returns
-    the value 0 if successful, and *addr will contain the
-    first virtual address in the found region; otherwise, the value 1 is
-    returned.

-

-

-

-
pmap_growkernel(9), vm_map(9),
-    vm_map_entry_resize_free(9),
-    vm_map_lock(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_inherit.9 4.html b/static/freebsd/man9/vm_map_inherit.9 4.html
deleted file mode 100644
index c4c9b447..00000000
--- a/static/freebsd/man9/vm_map_inherit.9 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_INHERIT(9)Kernel Developer's ManualVM_MAP_INHERIT(9)

-

-

-

-
vm_map_inherit —
-    set fork inheritance flags for a range within a
-  map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_inherit(vm_map_t map,
-    vm_offset_t start, vm_offset_t
-    end, vm_inherit_t new_inheritance);

-

-

-

-
The
-    ()
-    function sets the inheritance flags for the range
-    start to end within the target
-    map to the value
-    new_inheritance.

-
The new_inheritance flag must have one of
-    the values VM_INHERIT_NONE,
-    VM_INHERIT_COPY, or
-    VM_INHERIT_SHARE. This affects how the map will be
-    shared with child maps when the associated process forks.

-

-

-

-
The vm_map_inherit() function obtains a
-    lock on the map using vm_map_lock(9)
-    for the duration of the function.

-

-

-

-
The vm_map_inherit() function returns
-    KERN_SUCCESS if the inheritance flags could be set.
-    Otherwise, if the provided flags were invalid,
-    KERN_INVALID_ARGUMENT will be returned.

-

-

-

-
fork(2)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_init.9 4.html b/static/freebsd/man9/vm_map_init.9 4.html
deleted file mode 100644
index 146ddb0d..00000000
--- a/static/freebsd/man9/vm_map_init.9 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_INIT(9)Kernel Developer's ManualVM_MAP_INIT(9)

-

-

-

-
vm_map_init —
-    initialize a vm_map structure for process zero

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
void
-  

-  vm_map_init(vm_map_t
-    map, vm_offset_t
-    min, vm_offset_t
-    max);

-

-

-

-
The
-    ()
-    function initializes the system map map by setting its
-    upper and lower address bounds to max and
-    min respectively.

-
It also initializes the system map mutex.

-

-

-

-
This routine is for internal use only. It is called during early
-    system initialization.

-

-

-

-
vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_insert.9 4.html b/static/freebsd/man9/vm_map_insert.9 4.html
deleted file mode 100644
index b4de9344..00000000
--- a/static/freebsd/man9/vm_map_insert.9 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_INSERT(9)Kernel Developer's ManualVM_MAP_INSERT(9)

-

-

-

-
vm_map_insert —
-    insert an object into a map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_insert(vm_map_t map,
-    vm_object_t object, vm_ooffset_t
-    offset, vm_offset_t start,
-    vm_offset_t end, vm_prot_t prot,
-    vm_prot_t max, int cow);

-

-

-

-
The
-    ()
-    function inserts a mapping for the entire vm_object
-    object into the target map
-  map.

-
The offset argument specifies the offset
-    into the object at which to begin mapping. The
-    object's size should match that of the specified address range.

-
The start and end
-    arguments specify the bounds of the mapped object's window in the address
-    space of map.

-
The cow argument specifies the flags which
-    should be propagated to the new entry, for example, to indicate that this is
-    a copy-on-write mapping.

-

-

-

-
This function implicitly creates a new
-    vm_map_entry by calling the internal function
-    vm_map_entry_create().

-

-

-

-
The vm_map_insert() function returns
-    KERN_SUCCESS if the mapping could be made
-    successfully.

-
Otherwise, KERN_INVALID_ADDRESS will be
-    returned if the start of the range could not be found, or
-    KERN_NO_SPACE if the range was found to be part of
-    an existing entry or if it overlaps the end of the map.

-

-

-

-
vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
January 11, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_lock.9 4.html b/static/freebsd/man9/vm_map_lock.9 4.html
deleted file mode 100644
index b6c4bd95..00000000
--- a/static/freebsd/man9/vm_map_lock.9 4.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_LOCK(9)Kernel Developer's ManualVM_MAP_LOCK(9)

-

-

-

-
vm_map_lock,
-    vm_map_unlock,
-    vm_map_lock_read,
-    vm_map_unlock_read,
-    vm_map_trylock,
-    vm_map_trylock_read,
-    vm_map_lock_upgrade,
-    vm_map_lock_downgrade —
-    vm_map locking macros

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
void
-  

-  vm_map_lock(vm_map_t
-    map);

-
void
-  

-  vm_map_unlock(vm_map_t
-    map);

-
void
-  

-  vm_map_lock_read(vm_map_t
-    map);

-
void
-  

-  vm_map_unlock_read(vm_map_t
-    map);

-
int
-  

-  vm_map_trylock(vm_map_t
-    map);

-
int
-  

-  vm_map_trylock_read(vm_map_t
-    map);

-
int
-  

-  vm_map_lock_upgrade(vm_map_t
-    map);

-
int
-  

-  vm_map_lock_downgrade(vm_map_t
-    map);

-

-

-

-
The
-    ()
-    macro obtains an exclusive lock on map.

-
The
-    ()
-    macro releases an exclusive lock on map.

-
The
-    ()
-    macro obtains a read-lock on map.

-
The
-    ()
-    macro releases a read-lock on map.

-
The
-    ()
-    macro attempts to obtain an exclusive lock on map. It
-    returns FALSE if the lock cannot be immediately acquired; otherwise return
-    TRUE with the lock acquired.

-
The
-    ()
-    macro attempts to obtain a read-lock on map. It
-    returns FALSE if the lock cannot be immediately acquired; otherwise return
-    TRUE with the lock acquired.

-
The
-    ()
-    macro attempts to atomically upgrade a read-lock on
-    map to an exclusive lock.

-
The
-    ()
-    macro attempts to downgrade an exclusive lock on map
-    to a read-lock.

-

-

-

-
Currently, all of the locking macros implement their locks as
-    sleep locks.

-

-

-

-
vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_lookup.9 3.html b/static/freebsd/man9/vm_map_lookup.9 3.html
deleted file mode 100644
index dcb4ee1e..00000000
--- a/static/freebsd/man9/vm_map_lookup.9 3.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_LOOKUP(9)Kernel Developer's ManualVM_MAP_LOOKUP(9)

-

-

-

-
vm_map_lookup,
-    vm_map_lookup_done — lookup
-    the vm_object backing a given virtual region

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_lookup(vm_map_t *var_map,
-    vm_offset_t vaddr, vm_prot_t
-    fault_type, vm_map_entry_t *out_entry,
-    vm_object_t *object, vm_pindex_t
-    *pindex, vm_prot_t *out_prot,
-    boolean_t *wired);

-
void
-  

-  vm_map_lookup_done(vm_map_t
-    map, vm_map_entry_t
-    entry);

-

-

-

-
The
-    ()
-    function attempts to find the vm_object, page index
-    and protection, for the given virtual address vaddr,
-    in the map var_map, assuming a page fault of the type
-    fault_type had occurred.

-
Return values are guaranteed until
-    ()
-    is called to release the lock.

-

-

-

-
The function vm_map_lookup() acquires a
-    read-lock on the map *var_map, but does not release
-    it. The caller should invoke vm_map_lookup_done() in
-    order to release this lock.

-

-

-

-
The vm_map_lookup() function returns
-    KERN_SUCCESS, and sets the
-    *object, *pindex,
-    *out_prot, and *out_entry
-    arguments appropriately for the hypothetical page fault.

-

-

-

-
vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_madvise.9 4.html b/static/freebsd/man9/vm_map_madvise.9 4.html
deleted file mode 100644
index 5484c761..00000000
--- a/static/freebsd/man9/vm_map_madvise.9 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_MADVISE(9)Kernel Developer's ManualVM_MAP_MADVISE(9)

-

-

-

-
vm_map_madvise —
-    apply advice about use of memory to map entries

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_madvise(vm_map_t map,
-    vm_offset_t start, vm_offset_t
-    end, int behav);

-

-

-

-
The
-    ()
-    function applies the flags behav to the entries within
-    map between start and
-    end.

-
Advisories are classified as either those affecting the
-    vm_map_entry structure, or those affecting the
-    underlying objects.

-
The
-    ()
-    function is used by the madvise(2) system call.

-

-

-

-
The vm_map_madvise() function returns 0 if
-    successful. If the behav argument was not recognised,
-    KERN_INVALID_ARGUMENT is returned.

-

-

-

-
madvise(2), vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_max.9 4.html b/static/freebsd/man9/vm_map_max.9 4.html
deleted file mode 100644
index 62f9bc47..00000000
--- a/static/freebsd/man9/vm_map_max.9 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_MAX(9)Kernel Developer's ManualVM_MAP_MAX(9)

-

-

-

-
vm_map_max,
-    vm_map_min, vm_map_pmap
-    — return map properties

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
vm_offset_t
-  

-  vm_map_max(vm_map_t
-    map);

-
vm_offset_t
-  

-  vm_map_min(vm_map_t
-    map);

-
pmap_t
-  

-  vm_map_pmap(vm_map_t
-    map);

-

-

-

-
The function
-    ()
-    returns the upper address bound of the map map.

-
The function
-    ()
-    returns the lower address bound of the map map.

-
The function
-    ()
-    returns a pointer to the physical map associated with the virtual map
-    map.

-

-

-

-
pmap(9), vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_protect.9 3.html b/static/freebsd/man9/vm_map_protect.9 3.html
deleted file mode 100644
index 843a69ed..00000000
--- a/static/freebsd/man9/vm_map_protect.9 3.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_PROTECT(9)Kernel Developer's ManualVM_MAP_PROTECT(9)

-

-

-

-
vm_map_protect —
-    apply protection bits to a virtual memory region

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_protect(vm_map_t map,
-    vm_offset_t start, vm_offset_t
-    end, vm_prot_t new_prot,
-    vm_prot_t new_maxprot, int
-    flags);

-

-

-

-
The
-    ()
-    function sets the protection bits and maximum protection bits of the address
-    region bounded by start and end
-    within the map map.

-
If the flags argument has the
-    VM_MAP_PROTECT_SET_PROT bit set, then the effective
-    protection is set to new_prot.

-
If the flags argument has the
-    VM_MAP_PROTECT_SET_MAXPROT bit set, then the maximum
-    protection is set to new_maxprot. Protection bits not
-    included into new_maxprot will be cleared from
-    existing entries.

-
The values specified by new_prot and
-    new_maxprot are not allowed to include any protection
-    bits that are not set in existing max_protection on
-    every entry within the range. The operation will fail if this condition is
-    violated. For instance, this prevents upgrading a shared mapping of a
-    read-only file from read-only to read-write.

-
The specified range must not contain sub-maps.

-

-

-

-
The function acquires a lock on the map for
-    the duration, by calling vm_map_lock(9). Also, any
-    in-progress wiring operation on the map affecting the specified range will
-    cause vm_map_protect to sleep, waiting for
-    completion.

-

-

-

-

-  

-  
The specified protection bits were set successfully.

-  

-  
A sub-map entry was encountered in the range,

-  

-  
The value of new_prot or
-      new_maxprot exceed
-      max_protection for an entry within the range.

-  

-  
The map does not allow simultaneous setting of write and execute
-      permissions, but new_prot has both
-      VM_PROT_WRITE and
-      VM_PROT_EXECUTE set.

-  

-  
A copy-on-write mapping is transitioned from read-only to read-write, and
-      not enough swap space is available to back the copied pages.

-  

-  
Both new protection and new maximum protection updates were requested, but
-      the specified new_prot is not a subset of
-      new_maxprot.

-

-

-

-

-
vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
January 23, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_remove.9 4.html b/static/freebsd/man9/vm_map_remove.9 4.html
deleted file mode 100644
index 16adbad1..00000000
--- a/static/freebsd/man9/vm_map_remove.9 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_REMOVE(9)Kernel Developer's ManualVM_MAP_REMOVE(9)

-

-

-

-
vm_map_remove —
-    remove a virtual address range from a map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_remove(vm_map_t
-    map, vm_offset_t
-    start, vm_offset_t
-    end);

-

-

-

-
The
-    ()
-    function removes the given address range bounded by
-    start and end from the target
-    map.

-

-

-

-
This is the exported form of vm_map_delete(9)
-    which may be called by consumers of the VM subsystem.

-
The function calls vm_map_lock(9) to hold a lock
-    on map for the duration of the function call.

-

-

-

-
The vm_map_remove() always returns
-    KERN_SUCCESS.

-

-

-

-
vm_map(9),
-  vm_map_delete(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_stack.9 3.html b/static/freebsd/man9/vm_map_stack.9 3.html
deleted file mode 100644
index d13eae52..00000000
--- a/static/freebsd/man9/vm_map_stack.9 3.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_STACK(9)Kernel Developer's ManualVM_MAP_STACK(9)

-

-

-

-
vm_map_stack,
-    vm_map_growstack — manage
-    process stacks

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_stack(vm_map_t map,
-    vm_offset_t addrbos, vm_size_t
-    max_ssize, vm_prot_t prot,
-    vm_prot_t max, int cow);

-
int
-  

-  vm_map_growstack(struct
-    proc *p, vm_offset_t
-    addr);

-

-

-

-
The
-    ()
-    function maps a process stack for a new process image. The stack is mapped
-    addrbos in map, with a maximum
-    size of max_ssize. Copy-on-write flags passed in
-    cow are also applied to the new mapping. Protection
-    bits are supplied by prot and
-    max.

-
It is typically called by execve(2).

-
The
-    ()
-    function is responsible for growing a stack for the process
-    p to the desired address addr,
-    similar to the legacy sbrk(2) call.

-

-

-

-
The vm_map_stack() function calls
-    vm_map_insert(9) to create its mappings.

-
The vm_map_stack() and
-    vm_map_growstack() functions acquire the process
-    lock on p for the duration of the call.

-

-

-

-
The vm_map_stack() function returns
-    KERN_SUCCESS if the mapping was allocated
-    successfully.

-
Otherwise, if mapping the stack would exceed the process's VMEM
-    resource limit, or if the specified bottom-of-stack address is out of range
-    for the map, or if there is already a mapping at the address which would
-    result, or if max_ssize could not be accommodated
-    within the current mapping, KERN_NO_SPACE is
-    returned.

-
Other possible return values for this function are documented in
-    vm_map_insert(9).

-
The vm_map_growstack() function returns
-    KERN_SUCCESS if addr is
-    already mapped, or if the stack was grown successfully.

-
It also returns KERN_SUCCESS if
-    addr is outside the stack range; this is done in order
-    to preserve compatibility with the deprecated grow()
-    function previously located in the file
-    vm_machdep.c.

-

-

-

-
vm_map(9),
-  vm_map_insert(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
January 11, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_submap.9 3.html b/static/freebsd/man9/vm_map_submap.9 3.html
deleted file mode 100644
index 96a0aa55..00000000
--- a/static/freebsd/man9/vm_map_submap.9 3.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_SUBMAP(9)Kernel Developer's ManualVM_MAP_SUBMAP(9)

-

-

-

-
vm_map_submap —
-    create a subordinate map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_submap(vm_map_t map,
-    vm_offset_t start, vm_offset_t
-    end, vm_map_t submap);

-

-

-

-
The
-    ()
-    function marks the range bounded by start and
-    end within the map map as being
-    handled by a subordinate map sub_map.

-
It is generally called by the kernel memory allocator.

-

-

-

-
This function is for internal use only.

-
Both maps must exist. The range must have been created with
-    vm_map_find(9) previously.

-
No other operations may have been performed on this range before
-    calling this function. Only the vm_fault() operation
-    may be performed within this range after calling this function.

-
To remove a submapping, one must first remove the range from the
-    parent map, and then destroy the
-    sub_map. This procedure is not recommended.

-

-

-

-
The vm_map_submap() function returns
-    KERN_SUCCESS if successful.

-
Otherwise, it returns
-    KERN_INVALID_ARGUMENT if the caller requested
-    copy-on-write flags, or if the range specified for the sub-map was out of
-    range for the parent map, or if a NULL backing
-    object was specified.

-

-

-

-
vm_map(9), vm_map_find(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_sync.9 4.html b/static/freebsd/man9/vm_map_sync.9 4.html
deleted file mode 100644
index 626ccf83..00000000
--- a/static/freebsd/man9/vm_map_sync.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_SYNC(9)Kernel Developer's ManualVM_MAP_SYNC(9)

-

-

-

-
vm_map_sync — push
-    dirty pages to their pager

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_sync(vm_map_t map,
-    vm_offset_t start, vm_offset_t
-    end, boolean_t syncio, boolean_t
-    invalidate);

-

-

-

-
The
-    ()
-    function forces any dirty cached pages in the range
-    start to end within the
-    map to be pushed to their underlying pager.

-
If syncio is TRUE, dirty pages are written
-    synchronously.

-
If invalidate is TRUE, any cached pages are
-    also freed.

-
The range provided must be contiguous, it MUST NOT contain holes.
-    The range provided MUST NOT contain any sub-map entries.

-

-

-

-
The vm_map_sync() function returns
-    KERN_SUCCESS if successful.

-
Otherwise, KERN_INVALID_ADDRESS will be
-    returned if the function encountered a sub-map entry;
-    KERN_INVALID_ARGUMENT will be returned if the
-    function encountered a hole in the region provided, or if an entry could not
-    be found for the given start address.

-

-

-

-
vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 9, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_map_wire.9 3.html b/static/freebsd/man9/vm_map_wire.9 3.html
deleted file mode 100644
index b98e282f..00000000
--- a/static/freebsd/man9/vm_map_wire.9 3.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_MAP_WIRE(9)Kernel Developer's ManualVM_MAP_WIRE(9)

-

-

-

-
vm_map_wire,
-    vm_map_unwire — manage page
-    wiring within a virtual memory map

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_map.h>

-
int
-  

-  vm_map_wire(vm_map_t
-    map, vm_offset_t
-    start, vm_offset_t
-    end, int
-  flags);

-
int
-  

-  vm_map_unwire(vm_map_t map,
-    vm_offset_t start, vm_offset_t
-    end, int flags);

-

-

-

-
The
-    ()
-    function is responsible for wiring pages in the range between
-    start and end within the map
-    map. Wired pages are locked into physical memory, and
-    may not be paged out as long as their wire count remains above zero.

-
The
-    ()
-    function performs the corresponding unwire operation.

-
The flags argument is a bit mask, consisting
-    of the following flags:

-
If the VM_MAP_WIRE_USER flag is set, the
-    function operates within user address space.

-
If the VM_MAP_WIRE_HOLESOK flag is set, it
-    may operate upon an arbitrary range within the address space of
-    map.

-
If a contiguous range is desired, callers should explicitly
-    express their intent by specifying the
-    VM_MAP_WIRE_NOHOLES flag.

-

-

-

-
Both functions will attempt to acquire a lock on the map using
-    vm_map_lock(9) and hold it for the duration of the call.
-    If they detect MAP_ENTRY_IN_TRANSITION, they will
-    call vm_map_unlock_and_wait(9) until the map becomes
-    available again.

-
The map could have changed during this window as it was held by
-    another consumer, therefore consumers of this interface should check for
-    this condition using the return values below.

-

-

-

-
The vm_map_wire() and
-    vm_map_unwire() functions have identical return
-    values. The functions return KERN_SUCCESS if all
-    pages within the range were [un]wired successfully.

-
Otherwise, if the specified range was not valid, or if the map
-    changed while the MAP_ENTRY_IN_TRANSITION flag was
-    set, KERN_INVALID_ADDRESS is returned.

-

-

-

-
mlockall(2), munlockall(2),
-    vm_map(9)

-

-

-

-
This manual page was written by Bruce M
-    Simpson
-    <bms@spc.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2003FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_aflag.9 4.html b/static/freebsd/man9/vm_page_aflag.9 4.html
deleted file mode 100644
index 5a1e29a4..00000000
--- a/static/freebsd/man9/vm_page_aflag.9 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_AFLAG(9)Kernel Developer's ManualVM_PAGE_AFLAG(9)

-

-

-

-
vm_page_aflag_clear,
-    vm_page_aflag_set,
-    vm_page_reference — change
-    page atomic flags

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_aflag_clear(vm_page_t
-    m, uint8_t
-  bits);

-
void
-  

-  vm_page_aflag_set(vm_page_t
-    m, uint8_t
-  bits);

-
void
-  

-  vm_page_reference(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    atomically clears the specified bits on the page's
-    aflags.

-
The
-    ()
-    atomically sets the specified bits on the page's
-    aflags.

-
The
-    (m)
-    call is the same as

-

-
vm_page_aflag_set(m, PGA_REFERENCED);

-

-
and is the recommended way to mark the page as referenced from
-    third-party kernel modules.

-
These functions neither block nor require any locks to be held
-    around the calls for correctness.

-
The functions arguments are:

-

-  
m

-  
The page whose aflags are updated.

-  
bits

-  
The bits that are set or cleared on the page's flags.

-

-
The following aflags can be set or
-  cleared:

-

-  
PGA_REFERENCED

-  
The bit may be set to indicate that the page has been recently accessed.
-      For instance, pmap(9) sets this bit to reflect the
-      accessed attribute of the page mapping typically updated by processor's
-      memory management unit on the page access.

-  
PGA_WRITEABLE

-  
A writeable mapping for the page may exist.

-

-
Both PGA_REFERENCED and
-    PGA_WRITEABLE bits are only valid for the managed
-    pages.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
August 31, 2011FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_alloc.9 4.html b/static/freebsd/man9/vm_page_alloc.9 4.html
deleted file mode 100644
index b9f43502..00000000
--- a/static/freebsd/man9/vm_page_alloc.9 4.html	
+++ /dev/null
@@ -1,248 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_ALLOC(9)Kernel Developer's ManualVM_PAGE_ALLOC(9)

-

-

-

-
vm_page_alloc —
-    allocate a page of memory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
vm_page_t
-  

-  vm_page_alloc(vm_object_t
-    object, vm_pindex_t
-    pindex, int
-  req);

-
vm_page_t
-  

-  vm_page_alloc_after(vm_object_t
-    object, vm_pindex_t pindex, int
-    req, vm_page_t mpred);

-
vm_page_t
-  

-  vm_page_alloc_contig(vm_object_t
-    object, vm_pindex_t pindex, int
-    req, u_long npages, vm_paddr_t
-    low, vm_paddr_t high, u_long
-    alignment, vm_paddr_t boundary,
-    vm_memattr_t memattr);

-
vm_page_t
-  

-  vm_page_alloc_contig_domain(vm_object_t
-    object, vm_pindex_t pindex, int
-    req, u_long npages, vm_paddr_t
-    low, vm_paddr_t high, u_long
-    alignment, vm_paddr_t boundary,
-    vm_memattr_t memattr);

-
vm_page_t
-  

-  vm_page_alloc_domain(vm_object_t
-    object, vm_pindex_t pindex, int
-    domain, int req);

-
vm_page_t
-  

-  vm_page_alloc_domain_after(vm_object_t
-    object, vm_pindex_t pindex, int
-    domain, int req, vm_page_t
-    mpred);

-
vm_page_t
-  

-  vm_page_alloc_noobj(int
-  req);

-
vm_page_t
-  

-  vm_page_alloc_noobj_contig(int
-    req, u_long npages, vm_paddr_t
-    low, vm_paddr_t high, u_long
-    alignment, vm_paddr_t boundary,
-    vm_memattr_t memattr);

-
vm_page_t
-  

-  vm_page_alloc_noobj_contig_domain(int
-    domain, int req, u_long
-    npages, vm_paddr_t low,
-    vm_paddr_t high, u_long
-    alignment, vm_paddr_t boundary,
-    vm_memattr_t memattr);

-
vm_page_t
-  

-  vm_page_alloc_noobj_domain(int
-    domain, int req);

-

-

-

-
The
-    ()
-    family of functions allocate one or more pages of physical memory. Most
-    kernel code should not call these functions directly but should instead use
-    a kernel memory allocator such as malloc(9) or
-    uma(9), or should use a higher-level interface to the page
-    cache, such as vm_page_grab(9).

-
All of the functions take a req parameter
-    which encodes the allocation priority and optional modifier flags, described
-    below. The functions whose names do not include “noobj”
-    additionally insert the pages starting at index pindex
-    in the VM object object. The object must be
-    write-locked and not have a page already resident at the specified index.
-    The functions whose names include “domain” support NUMA-aware
-    allocation by returning pages from the numa(4) domain
-    specified by domain.

-
The
-    ()
-    and
-    ()
-    functions behave identically to vm_page_alloc() and
-    (),
-    respectively, except that they take an additional parameter
-    mpred which must be the page resident in
-    object with largest index smaller than
-    pindex, or NULL if no such
-    page exists. These functions exist to optimize the common case of loops that
-    allocate multiple pages at successive indices within an object.

-
The
-    ()
-    and
-    ()
-    functions and their NUMA-aware variants allocate a physically contiguous run
-    of npages pages which satisfies the specified
-    constraints. The low and high
-    parameters specify a physical address range from which the run is to be
-    allocated. The alignment parameter specifies the
-    requested alignment of the first page in the run and must be a power of two.
-    If the boundary parameter is non-zero, the pages
-    constituting the run will not cross a physical address that is a multiple of
-    the parameter value, which must be a power of two. If
-    memattr is not equal to
-    VM_MEMATTR_DEFAULT, then mappings of the returned
-    pages created by, e.g., pmap_enter(9) or
-    pmap_qenter(9), will carry the machine-dependent encoding
-    of the memory attribute. Additionally, the direct mapping of the page, if
-    any, will be updated to reflect the requested memory attribute.

-

-

-

-
All page allocator functions accept a req
-    parameter that governs certain aspects of the function's behavior.

-
The VM_ALLOC_WAITOK,
-    VM_ALLOC_WAITFAIL, and
-    VM_ALLOC_NOWAIT flags specify the behavior of the
-    allocator if free pages could not be immediately allocated. The
-    VM_ALLOC_WAITOK flag can only be used with the
-    “noobj” variants. If VM_ALLOC_NOWAIT
-    is specified, then the allocator gives up and returns
-    NULL. VM_ALLOC_NOWAIT is
-    specified implicitly if none of the flags are present in the request. If
-    either VM_ALLOC_WAITOK or
-    VM_ALLOC_WAITFAIL is specified, the allocator will
-    put the calling thread to sleep until sufficient free pages become
-    available. At this point, if VM_ALLOC_WAITFAIL is
-    specified the allocator will return NULL, and if
-    VM_ALLOC_WAITOK is specified the allocator will
-    retry the allocation. After a failed
-    VM_ALLOC_WAITFAIL allocation returns, the VM object,
-    if any, will have been unlocked while the thread was sleeping. In this case
-    the VM object write lock will be re-acquired before the function call
-    returns.

-
req also encodes the allocation request
-    priority. By default the page(s) are allocated with no special treatment. If
-    the number of available free pages is below a certain watermark, the
-    allocation will fail or the allocating thread will sleep, depending on the
-    specified wait flag. The watermark is computed at boot time and corresponds
-    to a small (less than one percent) fraction of the system's total physical
-    memory. To allocate memory more aggressively, one of following flags may be
-    specified.

-

-  

-  
The page can be allocated if the free page count is above the interrupt
-      reserved water mark. This flag should be used only when the system really
-      needs the page.

-  

-  
The allocation will fail only if zero free pages are available. This flag
-      should be used only if the consequences of an allocation failure are worse
-      than leaving the system without free memory. For example, this flag is
-      used when allocating kernel page table pages, where allocation failures
-      trigger a kernel panic.

-

-
The following optional flags can further modify allocator
-    behavior:

-

-  

-  
The returned page will be shared-busy. This flag may only be specified
-      when allocating pages in a VM object.

-  

-  
The returned page will not be busy. This flag is implicit when allocating
-      pages without a VM object. When allocating pages in a VM object, and
-      neither VM_ALLOC_SBUSY nor
-      VM_ALLOC_NOBUSY are specified, the returned pages
-      will be exclusively busied.

-  

-  
The returned page will not be included in any kernel core dumps regardless
-      of whether or not it is mapped in to KVA.

-  

-  
The returned page will be wired.

-  

-  
If this flag is specified, the “noobj” variants will return
-      zeroed pages. The other allocator interfaces ignore this flag.

-  

-  
If this flag is specified and the request can not be immediately
-      satisfied, the allocator will not attempt to break superpage reservations
-      to satisfy the allocation. This may be useful when the overhead of
-      scanning the reservation queue outweighs the cost of a failed allocation.
-      This flag may be used only with the “contig” variants, and
-      must not be specified in combination with
-      VM_ALLOC_WAITOK.

-  

-  
Hint that at least n pages will be allocated by the
-      caller in the near future. n must be no larger than
-      65535. If the system is short of free pages, this hint may cause the
-      kernel to reclaim memory more aggressively than it would otherwise.

-  

-  
The caller asserts that the returned page will never be released. If this
-      flag is specified, the allocator will try to fetch a page from a special
-      per-domain arena in order to curb long-term physical memory
-    fragmentation.

-

-

-

-

-
If the allocation was successful, a pointer to the
-    struct vm_page corresponding to the allocated page is
-    returned. If the allocation request specified multiple pages, the returned
-    pointer points to an array of struct vm_page
-    constituting the run. Upon failure, NULL is
-    returned. Regardless of whether the allocation succeeds or fails, the VM
-    object object will be write-locked upon return.

-

-

-

-
numa(4), malloc(9),
-    uma(9), vm_page_grab(9),
-    vm_page_sbusy(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
August 4, 2024FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_bits.9 4.html b/static/freebsd/man9/vm_page_bits.9 4.html
deleted file mode 100644
index 9952bb8c..00000000
--- a/static/freebsd/man9/vm_page_bits.9 4.html	
+++ /dev/null
@@ -1,141 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_BITS(9)Kernel Developer's ManualVM_PAGE_BITS(9)

-

-

-

-
vm_page_bits,
-    vm_page_set_validclean,
-    vm_page_clear_dirty,
-    vm_page_set_invalid,
-    vm_page_zero_invalid,
-    vm_page_is_valid,
-    vm_page_test_dirty,
-    vm_page_dirty,
-    vm_page_undirty — manage
-    page clean and dirty bits

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
int
-  

-  vm_page_bits(int
-    base, int
-  size);

-
void
-  

-  vm_page_set_validclean(vm_page_t
-    m, int base,
-    int size);

-
void
-  

-  vm_page_clear_dirty(vm_page_t
-    m, int base,
-    int size);

-
void
-  

-  vm_page_set_invalid(vm_page_t
-    m, int base,
-    int size);

-
void
-  

-  vm_page_zero_invalid(vm_page_t
-    m, boolean_t
-    setvalid);

-
int
-  

-  vm_page_is_valid(vm_page_t
-    m, int base,
-    int size);

-
void
-  

-  vm_page_test_dirty(vm_page_t
-    m);

-
void
-  

-  vm_page_dirty(vm_page_t
-    m);

-
void
-  

-  vm_page_undirty(vm_page_t
-    m);

-

-

-

-
()
-    calculates the bits representing the DEV_BSIZE range
-    of bytes between base and size.
-    The byte range is expected to be within a single page, and if
-    size is zero, no bits will be set.

-
()
-    flags the byte range between base and
-    size as valid and clean. The range is expected to be
-    DEV_BSIZE aligned and no larger than
-    PAGE_SIZE. If it is not properly aligned, any
-    unaligned chunks of the DEV_BSIZE blocks at the
-    beginning and end of the range will be zeroed.

-
If base is zero and
-    size is one page, the modified bit in the page map is
-    cleared; as well, the VPO_NOSYNC flag is
-  cleared.

-
()
-    clears the dirty bits within a page in the range between
-    base and size. The bits
-    representing the range are calculated by calling
-    vm_page_bits().

-
()
-    clears the bits in both the valid and dirty flags representing the
-    DEV_BSIZE blocks between base
-    and size in the page. The bits are calculated by
-    calling vm_page_bits(). As well as clearing the bits
-    within the page, the generation number within the object holding the page is
-    incremented.

-
()
-    zeroes all of the blocks within the page that are currently flagged as
-    invalid. If setvalid is TRUE,
-    all of the valid bits within the page are set.

-
In some cases, such as NFS, the valid bits cannot be set in order
-    to maintain cache consistency.

-
()
-    checks to determine if the all of the DEV_BSIZE
-    blocks between base and size of
-    the page are valid. If size is zero and the page is
-    entirely invalid vm_page_is_valid() will return
-    TRUE, in all other cases a size of zero will return
-    FALSE.

-
()
-    checks if a page has been modified via any of its physical maps, and if so,
-    flags the entire page as dirty. vm_page_dirty() is
-    called to modify the dirty bits.

-
()
-    flags the entire page as dirty. It is expected that the page is not
-    currently on the cache queue.

-
()
-    clears all of the dirty bits in a page.

-

-

-

-
None of these functions are allowed to block.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
December 1, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_busy.9 4.html b/static/freebsd/man9/vm_page_busy.9 4.html
deleted file mode 100644
index cd48c618..00000000
--- a/static/freebsd/man9/vm_page_busy.9 4.html	
+++ /dev/null
@@ -1,178 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_BUSY(9)Kernel Developer's ManualVM_PAGE_BUSY(9)

-

-

-

-
vm_page_busied,
-    vm_page_busy_downgrade,
-    vm_page_busy_sleep,
-    vm_page_sbusied,
-    vm_page_sunbusy,
-    vm_page_trysbusy,
-    vm_page_tryxbusy,
-    vm_page_xbusied,
-    vm_page_xunbusy,
-    vm_page_assert_sbusied,
-    vm_page_assert_unbusied,
-    vm_page_assert_xbusied —
-    protect page identity changes and page content
-    references

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
int
-  

-  vm_page_busied(vm_page_t
-    m);

-
void
-  

-  vm_page_busy_downgrade(vm_page_t
-    m);

-
bool
-  

-  vm_page_busy_sleep(vm_page_t
-    m, const char *msg,
-    int allocflags);

-
int
-  

-  vm_page_sbusied(vm_page_t
-    m);

-
void
-  

-  vm_page_sunbusy(vm_page_t
-    m);

-
int
-  

-  vm_page_trysbusy(vm_page_t
-    m);

-
int
-  

-  vm_page_tryxbusy(vm_page_t
-    m);

-
int
-  

-  vm_page_xbusied(vm_page_t
-    m);

-
void
-  

-  vm_page_xunbusy(vm_page_t
-    m);

-

-  

-  options INVARIANTS
-  

-  options INVARIANT_SUPPORT
-  

-  void
-  

-  vm_page_assert_sbusied(vm_page_t
-    m);

-
void
-  

-  vm_page_assert_unbusied(vm_page_t
-    m);

-
void
-  

-  vm_page_assert_xbusied(vm_page_t
-    m);

-

-

-

-
Page identity is usually protected by higher level locks like
-    vm_object locks and vm page locks. However, sometimes it is not possible to
-    hold such locks for the time necessary to complete the identity change. In
-    such case the page can be exclusively busied by a thread which needs to own
-    the identity for a certain amount of time.

-
In other situations, threads do not need to change the identity of
-    the page but they want to prevent other threads from changing the identity
-    themselves. For example, when a thread wants to access or update page
-    contents without a lock held the page is shared busied.

-
Before busying a page the vm_object lock must be held. The same
-    rule applies when a page is unbusied. This makes the vm_object lock a real
-    busy interlock.

-
The
-    ()
-    function returns non-zero if the current thread busied
-    m in either exclusive or shared mode. Returns zero
-    otherwise.

-
The
-    ()
-    function must be used to downgrade m from an exclusive
-    busy state to a shared busy state.

-
The
-    ()
-    checks the busy state of the page m and puts the
-    invoking thread to sleep if the page is busy. The VM object for the page
-    must be locked. The allocflags parameter must be
-    either 0, in which case the function will sleep if
-    the page is busied, or VM_ALLOC_IGN_SBUSY, in which
-    case the function will sleep only if the page is exclusively busied. A
-    return value of true indicates that the invoking thread was put to sleep and
-    that the object was unlocked. A return value of false indicates that the
-    invoking thread did not sleep and the object remains locked. The parameter
-    msg is a string describing the sleep condition for
-    userland tools.

-
The
-    ()
-    function returns non-zero if the current thread busied
-    m in shared mode. Returns zero otherwise.

-
The
-    ()
-    function shared unbusies m.

-
The
-    ()
-    attempts to shared busy m. If the operation cannot
-    immediately succeed vm_page_trysbusy() returns 0,
-    otherwise a non-zero value is returned.

-
The
-    ()
-    attempts to exclusive busy m. If the operation cannot
-    immediately succeed vm_page_tryxbusy() returns 0,
-    otherwise a non-zero value is returned.

-
The
-    ()
-    function returns non-zero if the current thread busied
-    m in exclusive mode. Returns zero otherwise.

-
The
-    ()
-    function exclusive unbusies m. Assertions on the busy
-    state allow kernels compiled with options INVARIANTS
-    and options INVARIANT_SUPPORT to panic if they are
-    not respected.

-
The
-    ()
-    function panics if m is not shared busied.

-
The
-    ()
-    function panics if m is not unbusied.

-
The
-    ()
-    function panics if m is not exclusive busied.

-

-

-

-
vm_page_aflag(9),
-    vm_page_alloc(9), vm_page_deactivate(9),
-    vm_page_free(9), vm_page_grab(9),
-    vm_page_insert(9), vm_page_lookup(9),
-    vm_page_rename(9), VOP_GETPAGES(9)

-

-

-
-  
-    
-    
-  
-
November 11, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_deactivate.9 4.html b/static/freebsd/man9/vm_page_deactivate.9 4.html
deleted file mode 100644
index bc9777b4..00000000
--- a/static/freebsd/man9/vm_page_deactivate.9 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_DEACTIVATE(9)Kernel Developer's ManualVM_PAGE_DEACTIVATE(9)

-

-

-

-
vm_page_deactivate —
-    deactivate a page

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_deactivate(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    function moves the given page to the inactive queue as long as it is
-    unmanaged and is not wired.

-

-

-

-
vm_page_wire(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 24, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_dontneed.9 4.html b/static/freebsd/man9/vm_page_dontneed.9 4.html
deleted file mode 100644
index 8808a94b..00000000
--- a/static/freebsd/man9/vm_page_dontneed.9 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_DONTNEED(9)Kernel Developer's ManualVM_PAGE_DONTNEED(9)

-

-

-

-
vm_page_dontneed —
-    indicate that a page is not needed anymore

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_dontneed(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    function advises the VM system that the given page is no longer required. If
-    the page is already in the inactive queue or in the cache queue, this
-    function does nothing; otherwise the page is deactivated.

-
Note that
-    ()
-    does not necessarily deactivate a page, but instead implements an algorithm
-    that attempts to prevent small objects from having their pages reused too
-    quickly, and large objects from flushing smaller ones from the queues as
-    their pages are released.

-

-

-

-
vm_page_deactivate(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 30, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_free.9 3.html b/static/freebsd/man9/vm_page_free.9 3.html
deleted file mode 100644
index 08a8c68d..00000000
--- a/static/freebsd/man9/vm_page_free.9 3.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_FREE(9)Kernel Developer's ManualVM_PAGE_FREE(9)

-

-

-

-
vm_page_free,
-    vm_page_free_toq,
-    vm_page_free_zero,
-    vm_page_try_to_free — free a
-    page

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_free(vm_page_t
-    m);

-
void
-  

-  vm_page_free_toq(vm_page_t
-    m);

-
void
-  

-  vm_page_free_zero(vm_page_t
-    m);

-
int
-  

-  vm_page_try_to_free(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    function moves a page into the free queue, and disassociates it from its
-    object. If the page is held, wired, already free, or its busy count is not
-    zero, the system will panic. If the PG_ZERO flag is
-    set on the page, it is placed at the end of the free queue; otherwise, it is
-    placed at the front.

-
If the page's object is of type OBJT_VNODE
-    and it is the last page associated with the object, the underlying vnode may
-    be freed.

-
The
-    ()
-    and
-    ()
-    functions both call vm_page_free_toq() to actually
-    free the page, but vm_page_free_zero() sets the
-    PG_ZERO flag and
-    vm_page_free() clears the
-    PG_ZERO flag prior to the call to
-    vm_page_free_toq().

-
The
-    ()
-    function verifies that the page is not held, wired, busy or dirty, and if
-    so, marks the page as busy, drops any protection that may be set on the
-    page, and frees it.

-

-

-

-
vm_page_try_to_free() returns 1 if it is
-    able to free the page; otherwise, 0 is returned.

-

-

-

-
vm_page_busy(9),
-    vm_page_hold(9), vm_page_wire(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 24, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_grab.9 4.html b/static/freebsd/man9/vm_page_grab.9 4.html
deleted file mode 100644
index 7073418e..00000000
--- a/static/freebsd/man9/vm_page_grab.9 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_GRAB(9)Kernel Developer's ManualVM_PAGE_GRAB(9)

-

-

-

-
vm_page_grab —
-    returns a page from an object

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
vm_page_t
-  

-  vm_page_grab(vm_object_t
-    object, vm_pindex_t
-    pindex, int
-    allocflags);

-

-

-

-
The
-    ()
-    function returns the page at pindex from the given
-    object. If the page exists and is busy,
-    vm_page_grab() will sleep while waiting for it. If
-    the page does not exist, it is allocated. The function sleeps until the
-    allocation request can be satisfied.

-
The function requires the
-    object to be locked on entry, and returns with the
-    object locked. If the
-    ()
-    function sleeps for any reason, the object lock is temporary dropped.

-
The
-    ()
-    supports all of the flags supported by vm_page_alloc(9).
-    In addition, vm_page_grab() supports the following
-    flags:

-

-  

-  
When waiting for the busy state of the existing page to drain, only test
-      for exclusive busy; ignore the shared busy counter.

-

-

-

-

-
The vm_page_grab() always returns the
-    page.

-

-

-

-
vm_page_alloc(9)

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
August 23, 2013FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_insert.9 4.html b/static/freebsd/man9/vm_page_insert.9 4.html
deleted file mode 100644
index e81844d7..00000000
--- a/static/freebsd/man9/vm_page_insert.9 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_INSERT(9)Kernel Developer's ManualVM_PAGE_INSERT(9)

-

-

-

-
vm_page_insert,
-    vm_page_remove — add/remove
-    page from an object

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_insert(vm_page_t
-    m, vm_object_t
-    object, vm_pindex_t
-    pindex);

-
void
-  

-  vm_page_remove(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    function adds a page to the given object at the given index. The page is
-    added to both the VM page hash table and to the object's list of pages, but
-    the hardware page tables are not updated. In the case of a user page, it
-    will be faulted in when it is accessed. If the page is a kernel page, the
-    caller is expected to handle adding the page to the kernel's pmap.

-
If PG_WRITEABLE is set in the page's
-    flags, OBJ_WRITEABLE and
-    OBJ_MIGHTBEDIRTY are set in the object's flags.

-
The
-    ()
-    function removes the given page from its object, and from the VM page hash
-    table. The page must be busy prior to this call, or the system will panic.
-    The pmap entry for the page is not removed by this function.

-
The arguments to
-    ()
-    are:

-

-  
m

-  
The page to add to the object.

-  
object

-  
The object the page should be added to.

-  
pindex

-  
The index into the object the page should be at.

-

-
The arguments to
-    ()
-    are:

-

-  
m

-  
The page to remove.

-

-

-

-

-
The index of a page in a VM object is the byte index into the same
-    object truncated to a page boundary. For example, if the page size is 4096
-    bytes, and the address in the object is 81944, the page index is 20.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 17, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_lookup.9 4.html b/static/freebsd/man9/vm_page_lookup.9 4.html
deleted file mode 100644
index 2344940e..00000000
--- a/static/freebsd/man9/vm_page_lookup.9 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_LOOKUP(9)Kernel Developer's ManualVM_PAGE_LOOKUP(9)

-

-

-

-
vm_page_lookup —
-    lookup a vm page

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
vm_page_t
-  

-  vm_page_lookup(vm_object_t
-    object, vm_pindex_t
-    pindex);

-

-

-

-
The
-    ()
-    function searches for a VM page given its VM object and index. If the page
-    is not found, NULL is returned. Its arguments
-  are:

-

-  
object

-  
The VM object to search on.

-  
pindex

-  
The page index to search on.

-

-

-

-

-
A vm_page_t is returned if successful;
-    otherwise, NULL is returned.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 13, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_rename.9 4.html b/static/freebsd/man9/vm_page_rename.9 4.html
deleted file mode 100644
index 92f57ee4..00000000
--- a/static/freebsd/man9/vm_page_rename.9 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_RENAME(9)Kernel Developer's ManualVM_PAGE_RENAME(9)

-

-

-

-
vm_page_rename —
-    move a page

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_rename(vm_page_t m,
-    vm_object_t new_object, vm_pindex_t
-    new_pindex);

-

-

-

-
The
-    ()
-    function removes a page from one object, and adds it to another at the given
-    page index. The page is added to the given object, and is removed from the
-    object that is currently associated with. If the page is currently on the
-    cache queue it will be deactivated unless it is wired or unmanaged, in which
-    case the deactivation will fail. The entire page is marked as dirty after
-    the move.

-
The arguments to
-    ()
-    are:

-

-  
m

-  
The page to move.

-  
new_object

-  
The object the page should be inserted into.

-  
new_pindex

-  
The page index into new_object at which the new page
-      should be inserted.

-

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
July 17, 2001FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_page_wire.9 4.html b/static/freebsd/man9/vm_page_wire.9 4.html
deleted file mode 100644
index b3a3c5dc..00000000
--- a/static/freebsd/man9/vm_page_wire.9 4.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_PAGE_WIRE(9)Kernel Developer's ManualVM_PAGE_WIRE(9)

-

-

-

-
vm_page_wire,
-    vm_page_unwire,
-    vm_page_unwire_noq — wire
-    and unwire pages

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_page_wire(vm_page_t
-    m);

-
bool
-  

-  vm_page_wire_mapped(vm_page_t
-    m);

-
void
-  

-  vm_page_unwire(vm_page_t
-    m, int queue);

-
bool
-  

-  vm_page_unwire_noq(vm_page_t
-    m);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions wire the page, which prevents it from being reclaimed by the page
-    daemon or when its containing object is destroyed. Both functions require
-    that the page belong to an object. The
-    vm_page_wire_mapped() function is for use by the
-    pmap(9) layer following a lookup. This function may fail
-    if mappings of the page are concurrently being destroyed, in which case it
-    will return false.

-
The
-    ()
-    and
-    ()
-    functions release a wiring of a page. The
-    vm_page_unwire() function takes a queue index and
-    will insert the page into the corresponding page queue upon releasing its
-    last wiring. If the page does not belong to an object and no other
-    references to the page exist, vm_page_unwire() will
-    free the page. vm_page_unwire_noq() releases the
-    wiring and returns true if it was the last wiring of the page.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
September 9, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/vm_set_page_size.9 4.html b/static/freebsd/man9/vm_set_page_size.9 4.html
deleted file mode 100644
index 7e69f16b..00000000
--- a/static/freebsd/man9/vm_set_page_size.9 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
VM_SET_PAGE_SIZE(9)Kernel Developer's ManualVM_SET_PAGE_SIZE(9)

-

-

-

-
vm_set_page_size —
-    initialize the system page size

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_page.h>

-
void
-  

-  vm_set_page_size(void);

-

-

-

-
The
-    ()
-    function initializes the system page size. If
-    vm_cnt.v_page_size (see
-    <sys/vmmeter.h>) equals 0,
-    PAGE_SIZE is used; otherwise, the value stored in
-    vm_cnt.v_page_size is used. If
-    vm_cnt.v_page_size is not a power of two, the system
-    will panic.

-
()
-    must be called prior to any page size dependent functions.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
March 21, 2014FreeBSD 15.0

diff --git a/static/freebsd/man9/vmem.9 3.html b/static/freebsd/man9/vmem.9 3.html
deleted file mode 100644
index 9e7e6121..00000000
--- a/static/freebsd/man9/vmem.9 3.html	
+++ /dev/null
@@ -1,261 +0,0 @@
-
-  
-    
-    
-    
-  
-
VMEM(9)Kernel Developer's ManualVMEM(9)

-

-

-

-
vmem — general
-    purpose resource allocator

-

-

-

-
#include
-    <sys/vmem.h>

-
vmem_t *
-  

-  vmem_create(const
-    char *name, vmem_addr_t
-    base, vmem_size_t
-    size, vmem_size_t
-    quantum, vmem_size_t
-    qcache_max, int
-    flags);

-
int
-  

-  vmem_add(vmem_t
-    *vm, vmem_addr_t
-    addr, vmem_size_t
-    size, int
-  flags);

-
int
-  

-  vmem_xalloc(vmem_t
-    *vm, const vmem_size_t
-    size, vmem_size_t
-    align, const vmem_size_t
-    phase, const vmem_size_t
-    nocross, const
-    vmem_addr_t minaddr,
-    const vmem_addr_t
-    maxaddr, int flags,
-    vmem_addr_t *addrp);

-
void
-  

-  vmem_xfree(vmem_t
-    *vm, vmem_addr_t
-    addr, vmem_size_t
-    size);

-
int
-  

-  vmem_alloc(vmem_t
-    *vm, vmem_size_t
-    size, int flags,
-    vmem_addr_t *addrp);

-
void
-  

-  vmem_free(vmem_t
-    *vm, vmem_addr_t
-    addr, vmem_size_t
-    size);

-
void
-  

-  vmem_destroy(vmem_t
-    *vm);

-

-

-

-
The vmem is a general purpose resource
-    allocator. Despite its name, it can be used for arbitrary resources other
-    than virtual memory.

-
()
-    creates a new vmem arena.

-

-

-  
name

-  
The string to describe the vmem.

-  
base

-  
The start address of the initial span. Pass 0 if
-      no initial span is required.

-  
size

-  
The size of the initial span. Pass 0 if no initial
-      span is required.

-  
quantum

-  
The smallest unit of allocation.

-  
qcache_max

-  
The largest size of allocations which can be served by quantum cache. It
-      is merely a hint and can be ignored.

-  
flags

-  
malloc(9) wait flag.

-

-

-
()
-    adds a span of size size starting at
-    addr to the arena. Returns 0 on success,
-    ENOMEM on failure. flags is
-    malloc(9) wait flag.

-
()
-    allocates a resource from the arena.

-

-

-  
vm

-  
The arena which we allocate from.

-  
size

-  
Specify the size of the allocation.

-  
align

-  
If zero, don't care about the alignment of the allocation. Otherwise,
-      request a resource segment starting at offset phase
-      from an align aligned boundary.

-  
phase

-  
See the above description of align. If
-      align is zero, phase should be
-      zero. Otherwise, phase should be smaller than
-      align.

-  
nocross

-  
Request a resource which doesn't cross nocross
-      aligned boundary.

-  
minaddr

-  
Specify the minimum address which can be allocated, or
-      VMEM_ADDR_MIN if the caller does not care.

-  
maxaddr

-  
Specify the maximum address which can be allocated, or
-      VMEM_ADDR_MAX if the caller does not care.

-  
flags

-  
A bitwise OR of an allocation strategy and a malloc(9)
-      wait flag. The allocation strategy is one of:
-    

-      

-      
Prefer allocation performance.

-      

-      
Prefer space efficiency.

-      

-      
Perform an address-ordered search for free addresses, beginning where
-          the previous search ended.

-    

-  

-  
addrp

-  
On success, if addrp is not
-      NULL, vmem_xalloc()
-      overwrites it with the start address of the allocated span.

-

-

-
()
-    frees resource allocated by vmem_xalloc() to the
-    arena.

-

-

-  
vm

-  
The arena which we free to.

-  
addr

-  
The resource being freed. It must be the one returned by
-      vmem_xalloc(). Notably, it must not be the one
-      from vmem_alloc(). Otherwise, the behaviour is
-      undefined.

-  
size

-  
The size of the resource being freed. It must be the same as the
-      size argument used for
-      vmem_xalloc().

-

-

-
()
-    allocates a resource from the arena.

-

-

-  
vm

-  
The arena which we allocate from.

-  
size

-  
Specify the size of the allocation.

-  
flags

-  
A bitwise OR of an vmem allocation strategy flag
-      (see above) and a malloc(9) sleep flag.

-  
addrp

-  
On success, if addrp is not
-      NULL, vmem_alloc()
-      overwrites it with the start address of the allocated span.

-

-

-
()
-    frees resource allocated by vmem_alloc() to the
-    arena.

-

-

-  
vm

-  
The arena which we free to.

-  
addr

-  
The resource being freed. It must be the one returned by
-      vmem_alloc(). Notably, it must not be the one from
-      vmem_xalloc(). Otherwise, the behaviour is
-      undefined.

-  
size

-  
The size of the resource being freed. It must be the same as the
-      size argument used for
-      vmem_alloc().

-

-

-
()
-    destroys a vmem arena.

-

-

-  
vm

-  
The vmem arena being destroyed. The caller should ensure that no one will
-      use it anymore.

-

-

-

-

-

-
vmem_create() returns a pointer to the
-    newly allocated vmem_t. Otherwise, it returns
-  NULL.

-
On success, vmem_xalloc() and
-    vmem_alloc() return 0. Otherwise,
-    ENOMEM is returned.

-

-

-

-
The vmem subsystem is implemented within
-    the file sys/kern/subr_vmem.c.

-

-

-

-
malloc(9)

-
libuvmem(3) for the userspace port of the
-    allocator.

-
Jeff Bonwick and
-    Jonathan Adams, Magazines and
-    Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary
-    Resources, 2001 USENIX Annual Technical
-    Conference, 2001.

-

-

-

-
The vmem allocator was originally
-    implemented in NetBSD. It was introduced in
-    FreeBSD 10.0.

-

-

-

-
Original implementation of vmem was
-    written by YAMAMOTO Takashi. The
-    FreeBSD port was made by Jeff
-    Roberson.

-

-

-

-
vmem relies on
-    malloc(9), so it cannot be used as early during system
-    bootstrap.

-

-

-
-  
-    
-    
-  
-
May 17, 2019FreeBSD 15.0

diff --git a/static/freebsd/man9/vn_deallocate.9 4.html b/static/freebsd/man9/vn_deallocate.9 4.html
deleted file mode 100644
index b2da14ec..00000000
--- a/static/freebsd/man9/vn_deallocate.9 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
VN_DEALLOCATE(9)Kernel Developer's ManualVN_DEALLOCATE(9)

-

-

-

-
vn_deallocate —
-    zero and/or deallocate storage from a file

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vn_deallocate(struct vnode *vp,
-    off_t *offset, off_t *length,
-    int flags, int ioflag,
-    struct ucred *active_cred, struct
-    ucred *file_cred);

-

-

-

-
The
-    ()
-    function zeros and/or deallocates backing storage space from a file. This
-    function only works on vnodes with VREG type.

-
The arguments are:

-

-  
vp

-  
The vnode of the file.

-  
offset

-  
The starting offset of the operation range.

-  
length

-  
The length of the operation range. This must be greater than 0.

-  
flags

-  
The control flags of the operation. This should be set to 0 for now.

-  
ioflag

-  
Directives and hints to be given to the file system.

-  
active_cred

-  
The user credentials of the calling thread.

-  
file_cred

-  
The credentials installed on the file description pointing to the vnode or
-      NOCRED.

-

-
The
-    ()
-    argument gives directives and hints to the file system. It may include one
-    or more of the following flags:

-

-  

-  
The vnode was locked before the call.

-  

-  
Rangelock was owned around the call.

-  

-  
Skip MAC checking in the call.

-  

-  
Do I/O synchronously.

-  

-  
Attempt to bypass buffer cache.

-

-
*offset and *length
-    are updated to reflect the unprocessed operation range of the call. For a
-    successful completion, *length is updated to be the
-    value 0, and *offset is incremented by the number of
-    bytes zeroed before the end-of-file.

-

-

-

-
Upon successful completion, the value 0 is returned; otherwise the
-    appropriate error is returned.

-

-

-

-
vnode(9),
-  VOP_DEALLOCATE(9)

-

-

-

-
vn_deallocate and this manual page was
-    written by Ka Ho Ng
-    <khng@FreeBSD.org>
-    under sponsorship from the FreeBSD Foundation.

-

-

-
-  
-    
-    
-  
-
August 25, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/vn_fullpath.9 3.html b/static/freebsd/man9/vn_fullpath.9 3.html
deleted file mode 100644
index c97d9065..00000000
--- a/static/freebsd/man9/vn_fullpath.9 3.html	
+++ /dev/null
@@ -1,156 +0,0 @@
-
-  
-    
-    
-    
-  
-
VN_FULLPATH(9)Kernel Developer's ManualVN_FULLPATH(9)

-

-

-

-
vn_fullpath —
-    convert a vnode reference to a full pathname, given a
-    process context

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vn_fullpath(struct
-    vnode *vp, char
-    **retbuf, char
-    **freebuf);

-
int
-  

-  vn_fullpath_jail(struct
-    vnode *vp, char
-    **retbuf, char
-    **freebuf);

-
int
-  

-  vn_fullpath_global(struct
-    vnode *vp, char
-    **retbuf, char
-    **freebuf);

-
int
-  

-  vn_fullpath_hardlink(struct vnode
-    *vp, struct vnode *dvp, const
-    char *hrdl_name, size_t hrdl_name_length,
-    char **retbuf, char **freebuf,
-    size_t *buflen);

-

-

-

-
The
-    (),
-    (),
-    ()
-    and vn_fullpath_hardlink() functions make a
-    “best effort” attempt at generating a string pathname for the
-    passed vnode. They differ in which directory the returned path is relative
-    to, except for vn_fullpath_hardlink() which behaves
-    like vn_fullpath() in this respect and is described
-    at the end.

-
The
-    ()
-    function returns a path relative to the root directory of the process
-    associated with the passed thread pointer. That root directory is either the
-    system's or the thread's process' containing jail's root directory, or some
-    descendant directory of such established by some chroot(2)
-    call. The
-    ()
-    function returns a path relative to the passed thread's process' current
-    jail's root, ignoring intervening chroot(2) calls possibly
-    made inside that jail. The
-    ()
-    function returns the full path from the system root, ignoring all jail roots
-    and chroot(2) calls.

-
Paths that the kernel intends to communicate to
-    the passed user thread should exclusively be obtained via
-    ().
-    Paths obtained via
-    ()
-    or
-    ()
-    are only useful for specific kernel checks or auditing purposes.

-
All these functions are implemented by inspecting the VFS name
-    cache, and attempting to reconstruct a path from the process root to the
-    object. This process is necessarily unreliable for several reasons:
-    intermediate entries in the path may not be found in the cache; files may
-    have more than one name (hard links), not all file systems use the name
-    cache (specifically, most synthetic file systems do not); a single name may
-    be used for more than one file (in the context of file systems covering
-    other file systems); a file may have no name (if deleted but still open or
-    referenced). However, the resulting string may still be more usable to a
-    user than a vnode pointer value, or a device number and inode number. Code
-    consuming the results of this function should anticipate (and properly
-    handle) failure.

-
These functions take the following arguments:

-

-  
vp

-  
The vnode to search for. No need to be locked by the caller.

-  
retbuf

-  
Pointer to a char * that may be set (on success) to
-      point at a newly allocated buffer containing the resulting pathname.

-  
freebuf

-  
Pointer to a char * that may be set (on success) to
-      point at a buffer to be freed, when the caller is done with
-      retbuf.

-

-
Typical consumers will declare two character
-    pointers: fullpath and freepath;
-    they will set freepath to
-    NULL, and fullpath to a name
-    to use in the event that the call to
-    ()
-    fails. After done with the value of fullpath, the
-    caller will check if freepath is
-    non-NULL, and if so, invoke
-    free(9) with a pool type of
-    M_TEMP.

-
-

-

-

-
If the vnode is successfully converted to a pathname, 0 is
-    returned; otherwise, an error number is returned.

-

-

-

-
free(9)

-

-

-

-
This manual page was initially written by Robert
-    Watson
-    <rwatson@FreeBSD.org>
-    to describe the vn_fullpath() function. The
-    descriptions of the other related functions were added by
-    Olivier Certner
-    <olce@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
September 29, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/vn_isdisk.9 4.html b/static/freebsd/man9/vn_isdisk.9 4.html
deleted file mode 100644
index 03b82ee8..00000000
--- a/static/freebsd/man9/vn_isdisk.9 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
VN_ISDISK(9)Kernel Developer's ManualVN_ISDISK(9)

-

-

-

-
vn_isdisk — checks
-    if a vnode represents a disk

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
bool
-  

-  vn_isdisk(struct
-    vnode *vp);

-
bool
-  

-  vn_isdisk_error(struct
-    vnode *vp, int
-    *errp);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions check to see if vp represents a disk. In
-    order for vp to be a disk, it must be a character
-    device, v_rdev must be valid, and the
-    cdevsw entry's flags must have
-    D_DISK set.

-
The arguments are:

-

-  
vp

-  
The vnode to check.

-  
errp

-  
An integer pointer to store the error number in if the call fails.

-

-

-

-

-
If the vnode represents a disk, true is returned; otherwise, false
-    is returned and errp will contain the error
-  number.

-

-

-

-
This manual page was written by Chad David
-    <davidc@acns.ab.ca>.

-

-

-
-  
-    
-    
-  
-
June 28, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/vnode.9 3.html b/static/freebsd/man9/vnode.9 3.html
deleted file mode 100644
index 27868c6b..00000000
--- a/static/freebsd/man9/vnode.9 3.html	
+++ /dev/null
@@ -1,153 +0,0 @@
-
-  
-    
-    
-    
-  
-
VNODE(9)Kernel Developer's ManualVNODE(9)

-

-

-

-
vnode — internal
-    representation of a file or directory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-

-

-

-
The vnode is the focus of all file activity in
-    UNIX. A vnode is described by struct
-    vnode. There is a unique vnode allocated for each active file, each
-    current directory, each mounted-on file, text file, and the root.

-
Each vnode has three reference counts,
-    v_usecount, v_holdcnt and
-    v_writecount. The first is the number of clients
-    within the kernel which are using this vnode. This count is maintained by
-    vref(9), vrele(9) and
-    vput(9). The second is the number of clients within the
-    kernel who veto the recycling of this vnode. This count is maintained by
-    vhold(9) and vdrop(9). When both the
-    v_usecount and the v_holdcnt of
-    a vnode reaches zero then the vnode will be put on the freelist and may be
-    reused for another file, possibly in another file system. The transition
-    from the freelist is handled by getnewvnode(9). The third
-    is a count of the number of clients which are writing into the file. It is
-    maintained by the open(2) and close(2)
-    system calls.

-
Any call which returns a vnode (e.g., vget(9),
-    VOP_LOOKUP(9), etc.) will increase the
-    v_usecount of the vnode by one. When the caller is
-    finished with the vnode, it should release this reference by calling
-    vrele(9) (or vput(9) if the vnode is
-    locked).

-
Other commonly used members of the vnode structure are
-    v_id which is used to maintain consistency in the name
-    cache, v_mount which points at the file system which
-    owns the vnode, v_type which contains the type of
-    object the vnode represents and v_data which is used
-    by file systems to store file system specific data with the vnode. The
-    v_op field is used by the
-    ()
-    functions to call functions in the file system which implement the vnode's
-    functionality.

-
The
-    ()
-    function declarations and definitions are generated from
-    sys/kern/vnode_if.src by the
-    sys/tools/vnode_if.awk script. The interfaces are
-    documented in their respective manual pages like
-    VOP_READ(9) and VOP_WRITE(9).

-

-

-

-

-  

-  
No type.

-  

-  
A regular file; may be with or without VM object backing. If you want to
-      make sure this get a backing object, call
-      ().

-  

-  
A directory.

-  

-  
A block device; may be with or without VM object backing. If you want to
-      make sure this get a backing object, call
-      vnode_create_vobject().

-  

-  
A character device.

-  

-  
A symbolic link.

-  

-  
A socket. Advisory locking will not work on this.

-  

-  
A FIFO (named pipe). Advisory locking will not work on this.

-  

-  
Indicates that the vnode has been reclaimed.

-

-

-

-

-
VFIFO uses the "struct fileops" from
-    /sys/kern/sys_pipe.c. VSOCK uses the "struct
-    fileops" from /sys/kern/sys_socket.c.
-    Everything else uses the one from
-    /sys/kern/vfs_vnops.c.

-
The VFIFO/VSOCK code, which is why "struct fileops" is
-    used at all, is an artifact of an incomplete integration of the VFS code
-    into the kernel.

-
Calls to malloc(9) or free(9)
-    when holding a vnode interlock, will cause a LOR
-    (Lock Order Reversal) due to the intertwining of VM Objects and Vnodes.

-

-

-

-

-  
sys/kern/vnode_if.src

-  
The input file for sys/tools/vnode_if.awk.

-  
sys/tools/vnode_if.awk

-  
The script generating the source code of the
-      VOP_*() functions.

-

-

-

-

-
malloc(9), VFS(9),
-    VOP_ACCESS(9), VOP_ACLCHECK(9),
-    VOP_ADVISE(9), VOP_ADVLOCK(9),
-    VOP_ALLOCATE(9), VOP_ATTRIB(9),
-    VOP_BWRITE(9), VOP_CREATE(9),
-    VOP_FSYNC(9), VOP_GETACL(9),
-    VOP_GETEXTATTR(9), VOP_GETPAGES(9),
-    VOP_INACTIVE(9), VOP_IOCTL(9),
-    VOP_LINK(9), VOP_LISTEXTATTR(9),
-    VOP_LOCK(9), VOP_LOOKUP(9),
-    VOP_OPENCLOSE(9), VOP_PATHCONF(9),
-    VOP_PRINT(9), VOP_RDWR(9),
-    VOP_READ_PGCACHE(9), VOP_READDIR(9),
-    VOP_READLINK(9), VOP_REALLOCBLKS(9),
-    VOP_REMOVE(9), VOP_RENAME(9),
-    VOP_REVOKE(9), VOP_SETACL(9),
-    VOP_SETEXTATTR(9), VOP_SETLABEL(9),
-    VOP_STRATEGY(9), VOP_VPTOCNP(9),
-    VOP_VPTOFH(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
July 15, 2025FreeBSD 15.0

diff --git a/static/freebsd/man9/vnode_pager_purge_range.9 4.html b/static/freebsd/man9/vnode_pager_purge_range.9 4.html
deleted file mode 100644
index fe6a0229..00000000
--- a/static/freebsd/man9/vnode_pager_purge_range.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
VNODE_PAGER_PURGE_RANGE(9)Kernel Developer's ManualVNODE_PAGER_PURGE_RANGE(9)

-

-

-

-
vnode_pager_purge_range —
-    invalidate the cached content within the given byte
-    range

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_extern.h>

-
void
-  

-  vnode_pager_purge_range(struct vnode
-    *vp, vm_ooffset_t start,
-    vm_ooffset_t end);

-

-

-

-
vnode_pager_purge_range invalidates the
-    cached content within the given byte range from the specified vnode
-    vp. The range to be purged is
-    [start, end). If the
-    end parameter is the value zero, the affected range
-    starts from start continues to the end of the object.
-    Pages within the specified range will be removed from the object's queue. If
-    start or end is not aligned to a
-    page boundary, the invalidated part of the page is zeroed. This function
-    only cleans the resident pages in the affected region, it is up to the
-    callers to ensure reading the backing store gets back zeroes.

-
In case the vnode vp does not have a VM
-    object allocated, the effect of calling this function is a no-op.

-

-

-

-
The vnode must be locked on entry and will still be locked on
-    exit.

-

-

-

-
vnode(9)

-

-

-

-
The vnode_pager_purge_range manual page
-    first appeared in FreeBSD 14.

-

-

-

-
This manual page was written by Ka Ho Ng
-    <khng@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 24, 2022FreeBSD 15.0

diff --git a/static/freebsd/man9/vnode_pager_setsize.9 4.html b/static/freebsd/man9/vnode_pager_setsize.9 4.html
deleted file mode 100644
index 03626ef3..00000000
--- a/static/freebsd/man9/vnode_pager_setsize.9 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
VNODE_PAGER_SETSIZE(9)Kernel Developer's ManualVNODE_PAGER_SETSIZE(9)

-

-

-

-
vnode_pager_setsize —
-    notify the VM system about updates in the file
-  size

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_extern.h>

-
void
-  

-  vnode_pager_setsize(struct
-    vnode *vp, vm_ooffset_t
-    nsize);

-

-

-

-
vnode_pager_setsize lets the VM system
-    know about a change in size for a file, and updates the object size and
-    vnode pager size of the vm object in vp with
-    nsize. Page faults on the object mapping with offset
-    beyond the new object size results in SIGBUS.

-
Pages between the old EOF and the new EOF are removed from the
-    object queue if the file size shrinks. In case the new EOF specified by the
-    nsize argument is not aligned to page boundary,
-    partial-page area starting beyond the EOF is zeroed and marked invalid. if
-    the page exists resident.

-
In case the vnode vp does not have a VM
-    object allocated, the effect of calling this function is no-op.

-
This function must be used within file system code to implement
-    truncation if the file system allocates vm objects for vnodes.

-

-

-

-
The vnode should be exclusively locked on entry and will still be
-    locked on exit.

-

-

-

-
vnode(9)

-

-

-

-
The vnode_pager_setsize manual page first
-    appeared in FreeBSD 14.

-

-

-

-
This manual page was written by Ka Ho Ng
-    <khng@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 8, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/vref.9 4.html b/static/freebsd/man9/vref.9 4.html
deleted file mode 100644
index 56e1adf8..00000000
--- a/static/freebsd/man9/vref.9 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
VREF(9)Kernel Developer's ManualVREF(9)

-

-

-

-
vref, vrefl
-    — increment the use count for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
void
-  

-  vref(struct
-    vnode *vp);

-
void
-  

-  vrefl(struct
-    vnode *vp);

-

-

-

-
Increment the v_usecount field of a
-  vnode.

-

-  
vp

-  
the vnode to increment

-

-
Each vnode maintains a reference count of how many parts of the
-    system are using the vnode. This allows the system to detect when a vnode is
-    no longer being used and can be safely recycled for a different file.

-
Any code in the system which is using a vnode (e.g.
-    during the operation of some algorithm or to store in a data structure)
-    should call
-    () or
-    ().

-
()
-    locks the vnode interlock while
-    ()
-    expects the interlock to already be held.

-

-

-

-
vget(9), vnode(9),
-    vput(9), vrefcnt(9),
-    vrele(9)

-

-

-

-
This manual page was written by Doug
-    Rabson.

-

-

-
-  
-    
-    
-  
-
January 18, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/vrefcnt.9 4.html b/static/freebsd/man9/vrefcnt.9 4.html
deleted file mode 100644
index 855d026e..00000000
--- a/static/freebsd/man9/vrefcnt.9 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
VREFCNT(9)Kernel Developer's ManualVREFCNT(9)

-

-

-

-
vrefcnt — returns
-    the use count of a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  vrefcnt(struct
-    vnode *vp);

-

-

-

-
Returns the use count of a vnode.

-
See vnode(9) for a detailed description of the
-    vnode reference counts.

-

-

-

-
vget(9), vnode(9),
-    vput(9), vrele(9)

-

-

-

-
This manual page was written by Chad
-    David.

-

-

-
-  
-    
-    
-  
-
February 10, 2008FreeBSD 15.0

diff --git a/static/freebsd/man9/vrele.9 4.html b/static/freebsd/man9/vrele.9 4.html
deleted file mode 100644
index 09d1a7bd..00000000
--- a/static/freebsd/man9/vrele.9 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
VRELE(9)Kernel Developer's ManualVRELE(9)

-

-

-

-
vput, vrele,
-    vunref — decrement the use
-    count for a vnode

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
void
-  

-  vput(struct
-    vnode *vp);

-
void
-  

-  vrele(struct
-    vnode *vp);

-
void
-  

-  vunref(struct
-    vnode *vp);

-

-

-

-
Decrement the v_usecount field of a
-  vnode.

-

-  
vp

-  
the vnode to decrement

-

-
The
-    ()
-    function takes an unlocked vnode and returns with the vnode unlocked.

-
The
-    ()
-    function should be given a locked vnode as argument, the vnode is unlocked
-    after the function returned. The vput() is
-    operationally equivalent to calling VOP_UNLOCK(9) followed
-    by vrele(), with less overhead.

-
The
-    ()
-    function takes a locked vnode as argument, and returns with the vnode
-    locked.

-
Any code in the system which signified its use of a vnode by
-    usecount should call one of the listed function to decrement use counter. If
-    the v_usecount field of the non-doomed vnode reaches
-    zero, then it will be inactivated and placed on the free list.

-
The
-    ()
-    function may lock the vnode. All three functions may sleep.

-
The hold count for the vnode is always greater or equal to the
-    usecount. Non-forced unmount fails when mount point owns a vnode that has
-    non-zero usecount, see vflush(9).

-

-

-

-
vget(9), vnode(9),
-    vref(9), vrefcnt(9)

-

-

-

-
This manual page was written by Doug
-    Rabson and
-  

-  Konstantin Belousov.

-

-

-
-  
-    
-    
-  
-
February 24, 2016FreeBSD 15.0

diff --git a/static/freebsd/man9/vslock.9 4.html b/static/freebsd/man9/vslock.9 4.html
deleted file mode 100644
index 348a61d9..00000000
--- a/static/freebsd/man9/vslock.9 4.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
VSLOCK(9)Kernel Developer's ManualVSLOCK(9)

-

-

-

-
vslock, vsunlock
-    — lock/unlock user space addresses in
-  memory

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/proc.h>
-  

-  #include <vm/vm.h>
-  

-  #include <vm/vm_extern.h>

-
int
-  

-  vslock(void
-    *addr, size_t
-  len);

-
void
-  

-  vsunlock(void
-    *addr, size_t
-  len);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions respectively lock and unlock a range of addresses belonging to the
-    currently running process into memory. The actual amount of memory locked is
-    a multiple of the machine's page size. The starting page number is computed
-    by truncating addr to the nearest preceding page
-    boundary, and by rounding up addr +
-    len to the next page boundary. The process context to
-    use for this operation is taken from the global variable
-    curproc.

-

-

-

-
The vslock() function will return 0 on
-    success, otherwise it will return one of the errors listed below.

-

-

-

-
The vslock() function will fail if:

-

-  
[]

-  
The addr and len parameters
-      specify a memory range that wraps around the end of the machine address
-      space.

-  
[]

-  
The size of the specified address range exceeds the system limit on locked
-      memory.

-  
[]

-  
Some portion of the indicated address range is not allocated. There was an
-      error faulting/mapping a page.

-

-

-

-
-  
-    
-    
-  
-
August 29, 2012FreeBSD 15.0

diff --git a/static/freebsd/man9/watchdog.9 4.html b/static/freebsd/man9/watchdog.9 4.html
deleted file mode 100644
index 71192669..00000000
--- a/static/freebsd/man9/watchdog.9 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
WATCHDOG(9)Kernel Developer's ManualWATCHDOG(9)

-

-

-

-
watchdog —
-    software and hardware watchdog facility

-

-

-

-
#include
-    <sys/watchdog.h>

-
void
-  

-  watchdog_fn(void
-    *private, u_int
-    cmd, int
-  *error);

-
EVENTHANDLER_REGISTER(watchdog_list,
-    watchdog_fn,
-    private,
-    0);

-
EVENTHANDLER_DEREGISTER(watchdog_list,
-    eventhandler_tag);

-

-

-

-
To implement a watchdog in software or hardware, only a single
-    function needs to be written and registered on the global
-    watchdog_list.

-
The function must examine the cmd argument
-    and act on it as follows:

-
If cmd is zero, the watchdog must be
-    disabled and the error argument left untouched. If the
-    watchdog cannot be disabled, the error argument must
-    be set to EOPNOTSUPP.

-
Else the watchdog should be reset and configured to a timeout of
-    (1 << (cmd &
-    WD_INTERVAL)) nanoseconds or larger and the
-    error argument be set to zero to signal arming of a
-    watchdog.

-
If the watchdog cannot be configured to the proposed timeout, it
-    must be disabled and the error argument left as is (to
-    avoid hiding the arming of another watchdog).

-
There is no specification of what the watchdog should do when it
-    times out, but a hardware reset or similar “drastic but
-    certain” behaviour is recommended.

-

-

-

-
watchdog(4)

-

-

-

-
The watchdog facility and this manual page
-    was written Poul-Henning Kamp
-    <phk@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 28, 2004FreeBSD 15.0

diff --git a/static/freebsd/man9/zero_region.9 4.html b/static/freebsd/man9/zero_region.9 4.html
deleted file mode 100644
index cedfbea5..00000000
--- a/static/freebsd/man9/zero_region.9 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZERO_REGION(9)Kernel Developer's ManualZERO_REGION(9)

-

-

-

-
zero_region —
-    Read-only region prefilled with zeroes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/systm.h>
-  

-  #include <vm/vm_param.h>

-
extern const void *zero_region;

-

-

-

-
The global variable zero_region points to a
-    read-only region prefilled with zeroes. The size of the region is specified
-    by the ZERO_REGION_SIZE macro.

-

-

-

-
The region zero_region points to is mapped
-    to the same page multiple times.

-

-

-

-

-
/*
- * This function writes zeroes to the vnode at offset 0
- * with ZERO_REGION_SIZE length.
- */
-static int
-write_example(struct vnode *vp)
-{
-	struct thread *td;
-	struct iovec aiov;
-	struct uio auio;
-	int error;
-
-	td = curthread;
-
-	aiov.iov_base = __DECONST(void *, zero_region);
-	aiov.iov_len = ZERO_REGION_SIZE;
-	auio.uio_iov = &aiov;
-	auio.uio_iovcnt = 1;
-	auio.uio_offset = 0;
-	auio.uio_resid = ZERO_REGION_SIZE;
-	auio.uio_segflg = UIO_SYSSPACE;
-	auio.uio_rw = UIO_WRITE;
-	auio.uio_td = td;
-
-	error = VOP_WRITE(vp, &auio, 0, td->td_ucred);
-	return (error);
-}

-

-

-

-

-
pmap(9), vm_map(9)

-

-

-

-
This manual page was written by Ka Ho Ng
-    <khng@FreeBSDFoundation.org>
-    under sponsorship from the FreeBSD Foundation.

-

-

-
-  
-    
-    
-  
-
March 2, 2021FreeBSD 15.0

diff --git a/static/freebsd/man9/zone.9 3.html b/static/freebsd/man9/zone.9 3.html
deleted file mode 100644
index e45ef578..00000000
--- a/static/freebsd/man9/zone.9 3.html	
+++ /dev/null
@@ -1,596 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMA(9)Kernel Developer's ManualUMA(9)

-

-

-

-
UMA —
-    general-purpose kernel object allocator

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/queue.h>
-  

-  #include <vm/uma.h>

-

-
typedef int (*uma_ctor)(void *mem, int size, void *arg, int flags);
-typedef void (*uma_dtor)(void *mem, int size, void *arg);
-typedef int (*uma_init)(void *mem, int size, int flags);
-typedef void (*uma_fini)(void *mem, int size);
-typedef int (*uma_import)(void *arg, void **store, int count, int domain,
-    int flags);
-typedef void (*uma_release)(void *arg, void **store, int count);
-typedef void *(*uma_alloc)(uma_zone_t zone, vm_size_t size, int domain,
-    uint8_t *pflag, int wait);
-typedef void (*uma_free)(void *item, vm_size_t size, uint8_t pflag);
-
-

-

-

-uma_zone_t
-

-uma_zcreate(char *name,
-  size_t size, uma_ctor ctor,
-  uma_dtor dtor, uma_init zinit,
-  uma_fini zfini, int align,
-  uint16_t flags);
-
uma_zone_t
-  

-  uma_zcache_create(char *name,
-    int size, uma_ctor ctor,
-    uma_dtor dtor, uma_init zinit,
-    uma_fini zfini, uma_import
-    zimport, uma_release zrelease,
-    void *arg, int flags);

-
uma_zone_t
-  

-  uma_zsecond_create(char *name,
-    uma_ctor ctor, uma_dtor dtor,
-    uma_init zinit, uma_fini zfini,
-    uma_zone_t master);

-
void
-  

-  uma_zdestroy(uma_zone_t
-    zone);

-
void *
-  

-  uma_zalloc(uma_zone_t
-    zone, int
-  flags);

-
void *
-  

-  uma_zalloc_arg(uma_zone_t
-    zone, void *arg,
-    int flags);

-
void *
-  

-  uma_zalloc_domain(uma_zone_t
-    zone, void *arg,
-    int domain,
-    int flags);

-
void *
-  

-  uma_zalloc_pcpu(uma_zone_t
-    zone, int
-  flags);

-
void *
-  

-  uma_zalloc_pcpu_arg(uma_zone_t
-    zone, void *arg,
-    int flags);

-
void *
-  

-  uma_zalloc_smr(uma_zone_t
-    zone, int
-  flags);

-
void
-  

-  uma_zfree(uma_zone_t
-    zone, void
-  *item);

-
void
-  

-  uma_zfree_arg(uma_zone_t
-    zone, void *item,
-    void *arg);

-
void
-  

-  uma_zfree_pcpu(uma_zone_t
-    zone, void
-  *item);

-
void
-  

-  uma_zfree_pcpu_arg(uma_zone_t
-    zone, void *item,
-    void *arg);

-
void
-  

-  uma_zfree_smr(uma_zone_t
-    zone, void
-  *item);

-
void
-  

-  uma_prealloc(uma_zone_t
-    zone, int
-  nitems);

-
void
-  

-  uma_zone_reserve(uma_zone_t
-    zone, int
-  nitems);

-
void
-  

-  uma_zone_reserve_kva(uma_zone_t
-    zone, int
-  nitems);

-
void
-  

-  uma_reclaim(int
-    req);

-
void
-  

-  uma_reclaim_domain(int
-    req, int
-  domain);

-
void
-  

-  uma_zone_reclaim(uma_zone_t
-    zone, int req);

-
void
-  

-  uma_zone_reclaim_domain(uma_zone_t
-    zone, int req,
-    int domain);

-
void
-  

-  uma_zone_set_allocf(uma_zone_t
-    zone, uma_alloc
-    allocf);

-
void
-  

-  uma_zone_set_freef(uma_zone_t
-    zone, uma_free
-    freef);

-
int
-  

-  uma_zone_set_max(uma_zone_t
-    zone, int
-  nitems);

-
void
-  

-  uma_zone_set_maxcache(uma_zone_t
-    zone, int
-  nitems);

-
int
-  

-  uma_zone_get_max(uma_zone_t
-    zone);

-
int
-  

-  uma_zone_get_cur(uma_zone_t
-    zone);

-
void
-  

-  uma_zone_set_warning(uma_zone_t
-    zone, const char
-    *warning);

-
void
-  

-  uma_zone_set_maxaction(uma_zone_t
-    zone, void
-    (*maxaction)(uma_zone_t));

-
smr_t
-  

-  uma_zone_get_smr(uma_zone_t
-    zone);

-
void
-  

-  uma_zone_set_smr(uma_zone_t
-    zone, smr_t
-  smr);

-
#include
-    <sys/sysctl.h>

-
SYSCTL_UMA_MAX(parent,
-    nbr,
-    name,
-    access,
-    zone,
-    descr);

-
SYSCTL_ADD_UMA_MAX(ctx,
-    parent,
-    nbr,
-    name,
-    access,
-    zone,
-    descr);

-
SYSCTL_UMA_CUR(parent,
-    nbr,
-    name,
-    access,
-    zone,
-    descr);

-
SYSCTL_ADD_UMA_CUR(ctx,
-    parent,
-    nbr,
-    name,
-    access,
-    zone,
-    descr);

-

-

-

-
UMA (Universal Memory Allocator) provides an efficient interface
-    for managing dynamically-sized collections of items of identical size,
-    referred to as zones. Zones keep track of which items are in use and which
-    are not, and UMA provides functions for allocating items from a zone and for
-    releasing them back, making them available for subsequent allocation
-    requests. Zones maintain per-CPU caches with linear scalability on SMP
-    systems as well as round-robin and first-touch policies for NUMA systems.
-    The number of items cached per CPU is bounded, and each zone additionally
-    maintains an unbounded cache of items that is used to quickly satisfy
-    per-CPU cache allocation misses.

-
Two types of zones exist: regular zones and cache zones. In a
-    regular zone, items are allocated from a slab, which is one or more
-    virtually contiguous memory pages that have been allocated from the kernel's
-    page allocator. Internally, slabs are managed by a UMA keg, which is
-    responsible for allocating slabs and keeping track of their usage by one or
-    more zones. In typical usage, there is one keg per zone, so slabs are not
-    shared among multiple zones.

-
Normal zones import items from a keg, and release items back to
-    that keg if requested. Cache zones do not have a keg, and instead use custom
-    import and release methods. For example, some collections of kernel objects
-    are statically allocated at boot-time, and the size of the collection does
-    not change. A cache zone can be used to implement an efficient allocator for
-    the objects in such a collection.

-
The
-    ()
-    and uma_zcache_create() functions create a new
-    regular zone and cache zone, respectively. The
-    ()
-    function creates a regular zone which shares the keg of the zone specified
-    by the master argument. The name
-    argument is a text name of the zone for debugging and stats; this memory
-    should not be freed until the zone has been deallocated.

-
The ctor and
-    dtor arguments are callback functions that are called
-    by the UMA subsystem at the time of the call to
-    ()
-    and uma_zfree() respectively. Their purpose is to
-    provide hooks for initializing or destroying things that need to be done at
-    the time of the allocation or release of a resource. A good usage for the
-    ctor and dtor callbacks might be
-    to initialize a data structure embedded in the item, such as a
-    queue(3) head.

-
The zinit and
-    zfini arguments are used to optimize the allocation of
-    items from the zone. They are called by the UMA subsystem whenever it needs
-    to allocate or free items to satisfy requests or memory pressure. A good use
-    for the zinit and zfini
-    callbacks might be to initialize and destroy a mutex contained within an
-    item. This would allow one to avoid destroying and re-initializing the mutex
-    each time the item is freed and re-allocated. They are not called on each
-    call to
-    ()
-    and uma_zfree() but rather when an item is imported
-    into a zone's cache, and when a zone releases an item to the slab allocator,
-    typically as a response to memory pressure.

-
For
-    (),
-    the zimport and zrelease
-    functions are called to import items into the zone and to release items from
-    the zone, respectively. The zimport function should
-    store pointers to items in the store array, which
-    contains a maximum of count entries. The function must
-    return the number of imported items, which may be less than the maximum.
-    Similarly, the store parameter to the
-    zrelease function contains an array of
-    count pointers to items. The arg
-    parameter passed to uma_zcache_create() is provided
-    to the import and release functions. The domain
-    parameter to zimport specifies the requested
-    numa(4) domain for the allocation. It is either a NUMA
-    domain number or the special value
-  UMA_ANYDOMAIN.

-
The flags argument of
-    ()
-    and uma_zcache_create() is a subset of the following
-    flags:

-

-  

-  
Slabs allocated to the zone's keg are never freed.

-  

-  
Pages belonging to the zone will not be included in minidumps.

-  

-  
An allocation from zone would have mp_ncpu shadow
-      copies, that are privately assigned to CPUs. A CPU can address its private
-      copy using base the allocation address plus a multiple of the current CPU
-      ID and
-      (struct
-      pcpu):
-    

-    
foo_zone = uma_zcreate(..., UMA_ZONE_PCPU);
- ...
-foo_base = uma_zalloc(foo_zone, ...);
- ...
-critical_enter();
-foo_pcpu = (foo_t *)zpcpu_get(foo_base);
-/* do something with foo_pcpu */
-critical_exit();
-
-    

-    

-    Note that M_ZERO cannot be used when allocating
-      items from a PCPU zone. To obtain zeroed memory from a PCPU zone, use the
-      uma_zalloc_pcpu() function and its variants
-      instead, and pass M_ZERO.

-  

-  
The UMA subsystem may not directly touch (i.e. read or write) the slab
-      memory. Otherwise, by default, book-keeping of items within a slab may be
-      done in the slab page itself, and INVARIANTS
-      kernels may also do use-after-free checking by accessing the slab
-    memory.

-  

-  
The zone will have its uma_init method set to
-      internal method that initializes a new allocated slab to all zeros. Do not
-      mistake uma_init method with
-      uma_ctor. A zone with
-      UMA_ZONE_ZINIT flag would not return zeroed memory
-      on every uma_zalloc().

-  

-  
An allocator function will be supplied with
-      uma_zone_set_allocf() and the memory that it
-      returns may not be kernel virtual memory backed by VM pages in the page
-      array.

-  

-  
The zone is for the malloc(9) subsystem.

-  

-  
The zone is for the VM subsystem.

-  

-  
Items in this zone must be contiguous in physical address space. Items
-      will follow normal alignment constraints and may span page boundaries
-      between pages with contiguous physical addresses.

-  

-  
By default, UMA zone caches are shrunk to help resolve free page
-      shortages. Cached items that have not been used for a long period may also
-      be freed from zone. When this flag is set, the system will not reclaim
-      memory from the zone's caches.

-  

-  
Create a zone whose items will be synchronized using the
-      smr(9) mechanism. Upon creation the zone will have an
-      associated smr_t structure which can be fetched
-      using
-      ().

-

-
Zones can be destroyed using
-    (),
-    freeing all memory that is cached in the zone. All items allocated from the
-    zone must be freed to the zone before the zone may be safely destroyed.

-
To allocate an item from a zone, simply call
-    ()
-    with a pointer to that zone and set the flags argument
-    to selected flags as documented in malloc(9). It will
-    return a pointer to an item if successful, or NULL
-    in the rare case where all items in the zone are in use and the allocator is
-    unable to grow the zone and M_NOWAIT is
-  specified.

-
Items are released back to the zone from which they
-    were allocated by calling
-    ()
-    with a pointer to the zone and a pointer to the item. If
-    item is NULL, then
-    uma_zfree() does nothing.

-
The variants
-    ()
-    and
-    ()
-    allow callers to specify an argument for the ctor
-    and dtor functions of the zone, respectively. The
-    variants
-    ()
-    and
-    ()
-    allocate and free mp_ncpu shadow copies as described
-    for UMA_ZONE_PCPU. If item is
-    NULL, then uma_zfree_pcpu()
-    does nothing.

-
The
-    ()
-    and
-    ()
-    functions allocate and free items from an SMR-enabled zone, that is, a zone
-    created with UMA_ZONE_SMR or a zone that has had
-    uma_zone_set_smr() called.

-
The
-    ()
-    function allows callers to specify a fixed numa(4) domain
-    to allocate from. This uses a guaranteed but slow path in the allocator
-    which reduces concurrency.

-
The
-    ()
-    function allocates slabs for the requested number of items, typically
-    following the initial creation of a zone. Subsequent allocations from the
-    zone will be satisfied using the pre-allocated slabs. Note that slab
-    allocation is performed with the M_WAITOK flag, so
-    uma_prealloc() may sleep.

-
The
-    ()
-    function sets the number of reserved items for the zone.
-    uma_zalloc() and variants will ensure that the zone
-    contains at least the reserved number of free items. Reserved items may be
-    allocated by specifying M_USE_RESERVE in the
-    allocation request flags. uma_zone_reserve() does
-    not perform any pre-allocation by itself.

-
The
-    ()
-    function pre-allocates kernel virtual address space for the requested number
-    of items. Subsequent allocations from the zone will be satisfied using the
-    pre-allocated address space. Note that unlike
-    uma_zone_reserve(),
-    uma_zone_reserve_kva() does not restrict the use of
-    the pre-allocation to M_USE_RESERVE requests.

-
The
-    ()
-    and
-    ()
-    functions reclaim cached items from UMA zones, releasing unused memory. The
-    uma_reclaim() function reclaims items from all
-    regular zones, while uma_zone_reclaim() reclaims
-    items only from the specified zone. The req parameter
-    must be one of three values which specify how aggressively items are to be
-    reclaimed:

-

-  

-  
Reclaim items only in excess of the zone's estimated working set size. The
-      working set size is periodically updated and tracks the recent history of
-      the zone's usage.

-  

-  
Reclaim all items from the unbounded cache. Free items in the per-CPU
-      caches are left alone.

-  

-  
Reclaim all cached items.

-

-The
-  ()
-  and
-  ()
-  functions apply only to items allocated from the specified domain. In the case
-  of domains using a round-robin NUMA policy, cached items from all domains are
-  freed to the keg, but only slabs from the specific domain will be freed.
-
The
-    ()
-    and
-    ()
-    functions allow a zone's default slab allocation and free functions to be
-    overridden. This is useful if memory with special constraints such as
-    attributes, alignment, or address ranges must be used.

-
The
-    ()
-    function limits the number of items (and therefore memory) that can be
-    allocated to zone. The nitems
-    argument specifies the requested upper limit number of items. The effective
-    limit is returned to the caller, as it may end up being higher than
-    requested due to the implementation rounding up to ensure all memory pages
-    allocated to the zone are utilised to capacity. The limit applies to the
-    total number of items in the zone, which includes allocated items, free
-    items and free items in the per-cpu caches. On systems with more than one
-    CPU it may not be possible to allocate the specified number of items even
-    when there is no shortage of memory, because all of the remaining free items
-    may be in the caches of the other CPUs when the limit is hit.

-
The
-    ()
-    function limits the number of free items which may be cached in the zone.
-    This limit applies to both the per-CPU caches and the cache of free
-  buckets.

-
The
-    ()
-    function returns the effective upper limit number of items for a zone.

-
The
-    ()
-    function returns an approximation of the number of items currently allocated
-    from the zone. The returned value is approximate because appropriate
-    synchronisation to determine an exact value is not performed by the
-    implementation. This ensures low overhead at the expense of potentially
-    stale data being used in the calculation.

-
The
-    ()
-    function sets a warning that will be printed on the system console when the
-    given zone becomes full and fails to allocate an item. The warning will be
-    printed no more often than every five minutes. Warnings can be turned off
-    globally by setting the vm.zone_warnings sysctl
-    tunable to 0.

-
The
-    ()
-    function sets a function that will be called when the given zone becomes
-    full and fails to allocate an item. The function will be called with the
-    zone locked. Also, the function that called the allocation function may have
-    held additional locks. Therefore, this function should do very little work
-    (similar to a signal handler).

-
The
-    ()
-    function associates an existing smr(9) structure with a
-    UMA zone. The effect is similar to creating a zone with the
-    UMA_ZONE_SMR flag, except that a new SMR structure
-    is not created. This function must be called before any allocations from the
-    zone are performed.

-
The
-    (parent,
-    nbr, name,
-    access, zone,
-    descr) macro declares a static
-    sysctl(9) oid that exports the effective upper limit
-    number of items for a zone. The zone argument should
-    be a pointer to uma_zone_t. A read of the oid returns
-    value obtained through uma_zone_get_max(). A write
-    to the oid sets new value via uma_zone_set_max().
-    The
-    (ctx,
-    parent, nbr,
-    name, access,
-    zone, descr) macro is provided
-    to create this type of oid dynamically.

-
The
-    (parent,
-    nbr, name,
-    access, zone,
-    descr) macro declares a static read-only
-    sysctl(9) oid that exports the approximate current
-    occupancy of the zone. The zone argument should be a
-    pointer to uma_zone_t. A read of the oid returns value
-    obtained through uma_zone_get_cur(). The
-    (ctx,
-    parent, nbr,
-    name, zone,
-    descr) macro is provided to create this type of oid
-    dynamically.

-

-

-

-
The memory that these allocation calls return is not executable.
-    The uma_zalloc() function does not support the
-    M_EXEC flag to allocate executable memory. Not all
-    platforms enforce a distinction between executable and non-executable
-    memory.

-

-

-

-
numa(4), vmstat(8),
-    malloc(9), smr(9)

-
Jeff Bonwick,
-    The Slab Allocator: An Object-Caching Kernel Memory
-    Allocator, 1994.

-

-

-

-
The zone allocator first appeared in FreeBSD
-    3.0. It was radically changed in FreeBSD 5.0
-    to function as a slab allocator.

-

-

-

-
The zone allocator was written by John S.
-    Dyson. The zone allocator was rewritten in large parts by
-    Jeff Roberson
-    <jeff@FreeBSD.org> to
-    function as a slab allocator.

-
This manual page was written by Dag-Erling
-    Smørgrav
-    <des@FreeBSD.org>.
-    Changes for UMA by Jeroen Ruigrok van der Werven
-    <asmodai@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 16, 2023FreeBSD 15.0

diff --git a/static/netbsd/man4/aac.4 4.html b/static/netbsd/man4/aac.4 4.html
deleted file mode 100644
index 4f4b5f55..00000000
--- a/static/netbsd/man4/aac.4 4.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
AAC(4)Device Drivers ManualAAC(4)

-

-

-

-
aac — Adaptec
-    AdvancedRAID Controller driver

-

-

-

-
aac* at pci? dev ? function ?
-  

-  ld* at aac? unit ?

-

-

-

-
The aac driver provides support for the
-    Adaptec AAC family of SCSI and SATA RAID controllers. These controllers
-    support RAID 0, 1, 5, 10, and volume sets. They have four channels in the
-    add-in version or 1-2 channels in the motherboard integrated version, and
-    are most often found rebadged by Dell, Hewlett-Packard or IBM. Supported
-    controllers include:

-

-
    
-  
  • Adaptec AAC-364
    • 
-  
  • Adaptec SCSI RAID 2120S
    • 
-  
  • Adaptec SCSI RAID 2200S
    • 
-  
  • Adaptec SATA RAID 2410SA
    • 
-  
  • Adaptec SATA RAID 3405
    • 
-  
  • Adaptec SCSI RAID 5400S
    • 
-  
  • Dell PERC 2/Si
    • 
-  
  • Dell PERC 2/QC
    • 
-  
  • Dell PERC 3/Di
    • 
-  
  • Dell PERC 3/Si
    • 
-  
  • Dell PERC 320/DC
    • 
-  
  • Dell CERC SATA RAID 1.5/6ch
    • 
-  
  • HP NetRAID 4M
    • 
-  
  • HP ML110 G2 (Adaptec SATA RAID 2610SA)
    • 
-  
  • IBM ServeRAID 8k
    • 
-

-
Access to RAID containers is available via the
-    ld device driver. Individual drives cannot be
-    accessed unless they are part of a container or volume set, and non-fixed
-    disks cannot be accessed. Containers can be configured by using the on-board
-    BIOS utility of the card.

-

-

-

-
The adapter can send status and alert messages asynchronously to
-    the driver. These messages are printed on the system console.

-

-

-

-
intro(4), ld(4)

-

-

-

-
The aac driver first appeared in
-    NetBSD 1.6, and was based on the
-    FreeBSD driver of the same name.

-

-

-

-
This driver is not compatible with controllers that have version
-    1.x firmware. The firmware version is the same as the kernel version printed
-    in the BIOS POST and driver attach messages.

-

-

-
-  
-    
-    
-  
-
June 1, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/ac97.4 4.html b/static/netbsd/man4/ac97.4 4.html
deleted file mode 100644
index 0493a705..00000000
--- a/static/netbsd/man4/ac97.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
AC97(4)Device Drivers ManualAC97(4)

-

-

-

-
ac97 — generic
-    AC97 codec driver

-

-

-

-
AC97 codecs contain the analog-to-digital (A/D), digital-to-analog
-    (D/A), and mixing circuitry of many modern sound cards. AC97 codecs, for the
-    most part, do not talk to host busses like the PCI bus directly. Instead,
-    they communicate through an interface chip, called the host controller. The
-    Ensoniq AudioPCI 97 (see eap(4)) is an example of such a
-    host controller.

-
Unlike many drivers, the ac97 driver does
-    not appear in the configuration file. Instead, the driver is automatically
-    attached by the drivers that require it.

-

-

-

-
auacer(4), auich(4),
-    auixp(4), autri(4),
-    auvia(4), clcs(4),
-    clct(4), eap(4),
-    emuxki(4), esa(4),
-    esm(4), fms(4),
-    neo(4), yds(4)

-

-

-

-
The ac97 driver does not keep track of the
-    current user settings and instead relies on the hardware to do this.

-
The ac97 driver could do more to detect
-    mixer channels that don't work and cull them from the list.

-

-

-
-  
-    
-    
-  
-
October 7, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/acardide.4 4.html b/static/netbsd/man4/acardide.4 4.html
deleted file mode 100644
index 2c19c241..00000000
--- a/static/netbsd/man4/acardide.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACARDIDE(4)Device Drivers ManualACARDIDE(4)

-

-

-

-
acardide — acard
-    IDE disk controllers driver

-

-

-

-
acardide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The acardide driver supports the following
-    IDE controllers:

-
    
-  
  • Acard ATP850U Ultra33
    • 
-  
  • Acard ATP860 Ultra66
    • 
-  
  • Acard ATP860-A Ultra66
    • 
-  
  • Acard ATP865-A Ultra100
    • 
-

-
It provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the acardide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 24, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/aceride.4 4.html b/static/netbsd/man4/aceride.4 4.html
deleted file mode 100644
index 5688352e..00000000
--- a/static/netbsd/man4/aceride.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACERIDE(4)Device Drivers ManualACERIDE(4)

-

-

-

-
aceride — PCI IDE
-    disk controllers driver

-

-

-

-
aceride* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The aceride driver supports the Acer Labs
-    M5229 IDE controllers, and provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the aceride driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/acphy.4 4.html b/static/netbsd/man4/acphy.4 4.html
deleted file mode 100644
index dbf006a9..00000000
--- a/static/netbsd/man4/acphy.4 4.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPHY(4)Device Drivers ManualACPHY(4)

-

-

-

-
acphy — Driver for
-    Altima AC101, AC101L and AMD Am79c874 10/100 Ethernet PHYs

-

-

-

-
acphy* at mii? phy ?

-

-

-

-
The acphy driver supports the Altima
-    AC101, AC101L and AMD Am79c874 NetPHY-1LP 10/100 Ethernet PHYs. These PHYs
-    are often found on low-power Ethernet interfaces, such as MiniPCI interfaces
-    found in laptops and embedded systems.

-
The AMD 79c874 is a work-alike (most likely an OEM of the core) of
-    the Altima part.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
August 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/acpi.4 4.html b/static/netbsd/man4/acpi.4 4.html
deleted file mode 100644
index 9f116eac..00000000
--- a/static/netbsd/man4/acpi.4 4.html	
+++ /dev/null
@@ -1,626 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPI(4)Device Drivers ManualACPI(4)

-

-

-

-
acpi — Advanced
-    Configuration and Power Interface

-

-

-

-
acpi0	at mainbus0

-

-  

-  options	ACPI_DEBUG
-  

-  options	ACPIVERBOSE
-  

-  options	ACPI_ACTIVATE_DEV
-  

-  options	ACPI_DSDT_OVERRIDE
-  

-  options	ACPI_DSDT_FILE=""
-  

-  options	ACPI_BLACKLIST_YEAR=2000
-  

-  options	ACPI__DIS_IS_BROKEN

-

-

-

-
NetBSD provides machine-independent bus
-    support for Advanced Configuration and Power Interface (ACPI) devices and
-    includes several ACPI device drivers.

-
The NetBSD implementation of ACPI
-    integrates Intel's ACPI Component Architecture (ACPI-CA) for the
-    OS-independent part. The ACPI-CA provides OS-neutral ACPI functionalities
-    such as ACPI BIOS table support, an ACPI event framework and an ACPI Machine
-    Language (AML) interpreter.

-
Options:

-

-

-  

-  
Enable various debug facilities.

-  

-  
Enable verbose debug messages.

-  

-  
Determine if the ACPI driver should attempt to activate inactive devices.
-      The default is off.

-  

-  
Force a given Differentiated System Description Table (DSDT) instead of
-      the version supplied by the BIOS. Use
-      ACPI_DSDT_FILE to specify a DSDT.

-  

-  
If ACPI_DSDT_FILE is not specified, default to
-      “dsdt.hex” in the build directory.

-  

-  
Do not use ACPI with any BIOS made on or before the specified year.

-  

-  
Do not call the ACPI "_DIS" method to disable interrupt links.
-      This may be required on specific “nForce4” chipset systems,
-      which hard hang when this method is called instead of having it fail
-      gracefully.

-

-

-

-

-

-
The following sysctl(8) variables are provided
-    by the acpi driver:

-

-

-  

-  
The address of the ACPI root pointer in system memory.

-  

-  
The system sleep state.

-  

-  
A list of system sleep states that the machine supports. The possible
-      values are:
-    

-    

-    

-      
S0

-      
fully running

-      
S1

-      
power on suspend (CPU and hard disks are off)

-      
S2

-      
similar to S3, usually not implemented

-      
S3

-      
suspend-to-RAM

-      
S4

-      
suspend-to-disk (not supported on NetBSD)

-      
S5

-      
power off

-    

-    

-  

-  

-  
A boolean variable that controls whether the PC speaker beeps upon resume.
-      Only available on i386 and amd64 architectures.

-  

-  
Defines the handling of the graphics card on i386 and amd64 architectures.
-      The supported values are:
-    

-    

-      
0

-      
No attempt to reset the VGA controller will be made.

-      
1

-      
Call the VGA BIOS when still in real mode. This can result in direct
-          reboots. In that case, use ‘2’ or
-          vbetool post from the
-          pkgsrc/sysutils/vbetool package.

-      
2

-      
Call the VGA BIOS using the in-kernel x86 emulator.

-    

-    

-    
If the system has problems in resuming from the S3 state,
-        experimenting with different values may provide a solution.

-  

-  

-  
The number of dispatched General Purpose Events (GPEs).

-  

-  
The number of System Control Interrupts (SCIs). See
-      acpiec(4) for a brief description of both GPEs and
-    SCIs.

-  

-  
The number of “fixed events”.

-  

-  
The number of AML methods executed by the interpreter.

-  

-  
This read-only node describes the ACPI power state of devices. The values
-      range from D0 (“on”) to D3 (“off”).

-  

-  
This node represents devices that can wake the system from the S3 or S4
-      sleep state. By default, acpibut(4),
-      acpilid(4), and pckbd(4) are allowed
-      to wake the system, provided that the devices are present and the firmware
-      supports wake-up capabilities for the devices.

-

-

-

-

-

-
NetBSD ACPI supports several
-    machine-dependent and machine-independent devices, some specific to ACPI and
-    some configured via it.

-

-

-

-

-  
acpiacad(4)

-  
ACPI AC adapters.

-  
acpibat(4)

-  
ACPI batteries.

-  
acpibut(4)

-  
ACPI power and sleep buttons.

-  
acpicpu(4)

-  
ACPI processors.

-  
acpidalb(4)

-  
ACPI direction application launch buttons.

-  
acpiec(4)

-  
ACPI embedded controllers.

-  
acpiecdt(4)

-  
ACPI Embedded Controller Boot Resource Table (ECDT).

-  
acpifan(4)

-  
ACPI fans.

-  
acpilid(4)

-  
ACPI lid switches.

-  
acpipmtr(4)

-  
ACPI power meters.

-  
acpismbus(4)

-  
ACPI SMBus via control method interface (CMI).

-  
acpitz(4)

-  
ACPI thermal zones.

-  
acpivga(4)

-  
ACPI display adapter and output devices.

-  
acpiwmi(4)

-  
ACPI support for Windows Management Instrumentation.

-  
acpiwdrt(4)

-  
ACPI watchdogs.

-  
aibs(4)

-  
ASUSTeK voltage, temperature and fan sensors.

-  
asus(4)

-  
ASUS laptop hotkeys.

-  
attimer(4)

-  
AT Timer.

-  
com(4)

-  
NS8250-, NS16450-, and NS16550-based serial ports.

-  
fdc(4)

-  
Floppy disk controllers.

-  
fujbp(4)

-  
Fujitsu brightness and pointer.

-  
fujhk(4)

-  
Fujitsu hotkeys.

-  
hpacel(4)

-  
HP 3D DriveGuard accelerometer.

-  
hpet(4)

-  
High Precision Event Timer (HPET).

-  
hpqlb(4)

-  
HP Quick Launch Buttons.

-  
joy(4)

-  
Joystick/Game port interface.

-  
lpt(4)

-  
Standard ISA parallel port interface.

-  
mpu(4)

-  
Roland MPU-401 (compatible) MIDI UART.

-  
pcppi(4)

-  
AT-style speaker sound.

-  
sdhc(4)

-  
SD Host Controller.

-  
thinkpad(4)

-  
IBM/Lenovo ThinkPad laptop device driver.

-  
ug(4)

-  
Abit uGuru Hardware monitor.

-  
vald(4)

-  
Toshiba Libretto device.

-  
valz(4)

-  
Toshiba Dynabook device.

-  
wb(4)

-  
Winbond W83L518D Integrated Media Reader.

-  
wss(4)

-  
Windows Sound System-compatible sound cards

-  
ym(4)

-  
Yamaha OPL3-SA2 and OPL3-SA3 audio device driver.

-

-

-

-

-

-

-

-  
pckbc(4)

-  
PC keyboard controllers.

-  
sony(4)

-  
Sony Miscellaneous Controller

-  
spic(4)

-  
Sony programmable I/O controller.

-

-

-

-

-

-

-
Although the situation has become better over the years, ACPI is
-    typically prone to various errors, ranging from blatant flaws in the
-    firmware to bugs in the implementation. Before anything else, it is a good
-    practice to upgrade the BIOS to the latest version available from the
-    vendor.

-
To ease the task of diagnosing and fixing different problems, the
-    ACPICA reference implementation provides a rich facility of different
-    debugging methods. In NetBSD these are generally
-    only available if the kernel has been compiled with the
-    ACPI_DEBUG option.

-

-

-
The ACPIVERBOSE compile time option
-    enables some verbose debug messages printed during the system startup. In a
-    MODULAR (see options(4)) system,
-    the information can be printed also at runtime, regardless of the presence
-    of ACPIVERBOSE. To print the messages,
-    modload(8) the acpiverbose module
-    using the option -b
-    dump=true.

-

-

-

-
ACPI interprets bytecode known as ACPI Machine Language (AML),
-    provided by the BIOS as a memory image during the system bootstrap. Most of
-    the AML relevant to acpi is implemented in the
-    so-called Differentiated System Descriptor Table (DSDT).
-    NetBSD provides support for overriding the default
-    DSDT supplied by the BIOS.

-
The following steps can be used to override the DSDT:

-
    
-  
  1. Dump the raw DSDT with acpidump(8).
    2. 
-  
  2. Disassemble the table with iasl(8).
    3. 
-  
  3. Modify the disassembled table.
    4. 
-  
  4. Compile the table with iasl(8) using the option
-      -tc.
    5. 
-  
  5. Either copy the (*.hex) file to
-    
    
-    
    src/sys/dev/acpi/acpica/Osd/custom_dsdt.hex
    
-    
    
-    
    or use the option
    
-    
    
-    
    ACPI_DSDT_FILE="/some/directory/custom_dsdt.hex"
    
-    
    
-    
    in the kernel configuration file.
    
-  
    6. 
-  
  6. Define ACPI_DSDT_OVERRIDE in the kernel
-      configuration file and rebuild.
    7. 
-

-

-

-

-
The ACPICA interpreter provides its own debugger for low-level
-    debugging. It can be used to display internal data structures and namespace
-    objects, and to debug the execution of control methods. Single step and
-    breakpoint functionality are available. In NetBSD
-    this is integrated to the in-kernel ddb(4). In order to
-    enter the ACPICA debugger from ddb(4), use the command
-    call with the argument
-    acpi_osd_debugger.

-

-

-

-
NetBSD provides three
-    sysctl(8) variables that control the debug output at
-    runtime. The hw.acpi.debug.layer variable limits the
-    output to a specific ACPI layer and the
-    hw.acpi.debug.level variable controls the debug
-    level. Both sysctl(8) variables are string literals. The
-    third variable is hw.acpi.debug.object. This is a
-    boolean that controls whether debug messages internal to the AML are
-    enabled.

-
For the first two variables, the possible values are:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-

-      *

-      *

-      *

-      *

-      *
* This is a compound
-      *
 constant, including
 all previous elements.

-      *

-
In addition, there is ACPI_DEBUG_DEFAULT
-    that is used by ACPICA as the default debug level. It includes
-    ACPI_LV_INIT and
-    ACPI_LV_DEBUG_OBJECT.

-
The debug layer can be divided into two groups: the first one is
-    specific to the ACPICA interpreter and the second one contains the internal
-    ACPI components of NetBSD. The constant
-    ACPI_ALL_DRIVERS includes all
-    NetBSD specific parts.

-
The ACPICA interpreter uses several debug levels internally, but
-    the NetBSD specific parts are typically limited to
-    ACPI_LV_DEBUG_OBJECT and
-    ACPI_LV_INFO. The debug output can be stopped by
-    setting hw.acpi.debug.level to
-    ACPI_DEBUG_NONE.

-

-

-

-
As an example, a driver may have defined the component it belongs
-    to and the name of the module:

-

-
#define _COMPONENT	ACPI_BUS_COMPONENT
-ACPI_MODULE_NAME	("acpi_example")

-

-
The driver may also utilize the debug facility:

-

-
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Failed to evaluate _STA\n"));

-

-
With these options the debug message from the
-    ACPI_DEBUG_PRINT macro is only visible when
-    hw.acpi.debug.layer is either
-    ACPI_BUS_COMPONENT or a compound constant including
-    it, and hw.acpi.debug.level is
-    ACPI_LV_INFO or some constant that includes it.
-    Finally, it can be noted that the ACPI implementation uses the prefix
-    ACPI_DB, whereas the debug level
-    sysctl(8) variable is always specified with the prefix
-    ACPI_LV.

-
Another example can be mentioned for the use of
-    hw.acpi.debug.object. The following could appear in
-    an ASL code:

-

-
Method(_Q19, 0, NotSerialized)
-{
-	Store("_Q19 invoked", Debug)
-	Notify(ACAD, 0x80)
-}

-

-
When hw.acpi.debug.object is set to 1, the
-    message stored to the debug object is printed every time the method is
-    called by the interpreter.

-

-

-

-

-

-  
/dev/acpi

-  
 

-

-

-

-

-
ioapic(4), acpidump(8),
-    amldb(8), iasl(8)

-
Hewlett-Packard
-    Corporation, Intel Corporation,
-    Microsoft Corporation, Phoenix
-    Technologies Ltd., and Toshiba Corporation,
-    Advanced Configuration and Power Interface
-    Specification, Revision 4.0,
-    http://www.acpi.info/spec.htm,
-    June 16, 2009.

-
Intel Corporation,
-    ACPI Component Architecture,,
-    Programmer Reference,,
-    OS-Independent Subsystem, Debugger, and Utilities,
-    Revision 1.27,
-    http://www.acpica.org/download/acpica-reference.pdf,
-    January 20, 2010.

-
Len Brown,
-    ACPI in Linux - Myths vs. Reality,
-    http://www.linuxsymposium.org/archives/OLS/Reprints-2007/brown_1-Reprint.pdf,
-    65-74, June 27-30, 2007,
-    Proceedings of the Linux Symposium.

-
Joerg Sonnenberger and
-    Jared D. McNeill, Sleeping Beauty
-    - NetBSD on Modern Laptops,
-    https://2008.asiabsdcon.org/papers/P9A-paper.pdf,
-    127-134, February 3, 2008,
-    Proceedings of AsiaBSDCon 2008.

-
Takanori Watanabe,
-    ACPI Implementation on FreeBSD,
-    Proceedings of the FREENIX Track: 2002 USENIX Annual
-    Technical Conference, USENIX Association,
-    https://www.usenix.org/legacy/event/usenix02/tech/freenix/full_papers/watanabe/watanabe.pdf,
-    121-131, June 10-15,
-    2002.

-

-

-

-
The acpi driver appeared in
-    NetBSD 1.6.

-

-

-

-
Authors of the acpi subsystem include
-    Charles M. Hannum, Frank van der
-    Linden, Jared D. McNeill,
-    Jason R. Thorpe, Joerg
-    Sonnenberger, and Jukka Ruohonen, among
-    others.

-

-

-

-
Most of the ACPI power management functionalities are not
-    implemented.

-
The ACPI__DIS_IS_BROKEN option should not
-    be necessary.

-

-

-
-  
-    
-    
-  
-
December 5, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/acpiacad.4 4.html b/static/netbsd/man4/acpiacad.4 4.html
deleted file mode 100644
index 34276e60..00000000
--- a/static/netbsd/man4/acpiacad.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIACAD(4)Device Drivers ManualACPIACAD(4)

-

-

-

-
acpiacad — ACPI AC
-    Adapter

-

-

-

-
acpiacad* at acpi?

-

-

-

-
The acpiacad driver supports ACPI AC
-    Adapters.

-
The status (connected or disconnected) can be monitored by the
-    envsys(4) API or the envstat(8) command.
-    Actions against AC adapter online/offline events can be configured using the
-    powerd(8) daemon.

-

-

-

-
acpi(4), envsys(4),
-    envstat(8), powerd(8)

-

-

-

-
The acpiacad driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
October 11, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/acpibat.4 4.html b/static/netbsd/man4/acpibat.4 4.html
deleted file mode 100644
index 59f84959..00000000
--- a/static/netbsd/man4/acpibat.4 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIBAT(4)Device Drivers ManualACPIBAT(4)

-

-

-

-
acpibat — ACPI
-    Battery

-

-

-

-
acpibat* at acpi?

-

-

-

-
The acpibat driver supports ACPI
-    batteries.

-
The battery status is made available through the
-    envsys(4) API. The battery information can be displayed
-    also with the envstat(8) command:

-

-
$ envstat -d acpibat0
-                Current  CritMax  WarnMax  WarnMin  CritMin Unit
-       present:      ON
-design voltage:  14.400                                        V
-       voltage:  16.267                                        V
-    design cap:  74.880                                       Wh
- last full cap:  48.260                                       Wh
-        charge:  47.910                      5.000%   0.414%  Wh (99.27%)
-   charge rate:     N/A
-discharge rate:  16.641                                        W
-      charging:     OFF
-  charge state:  NORMAL

-

-
Depending on the battery, the unit of measurement is either
-    watt-hour (Wh) or ampere-hour (Ah) for the capacity related information.
-    From these the “charge” is usually the most interesting value,
-    but it is possible to derive useful information also from the other values.
-    For example, when acpiacad(4) is disconnected, the
-    “discharge rate” gives a coarse approximation of the current
-    power consumption. The ratio between the design capacity and the last full
-    capacity on the other hand reveals the overall “health” of
-    deteriorating lithium-ion batteries.

-

-

-

-
The acpibat driver is able to send events
-    to powerd(8) daemon when a capacity state has been
-    changed. The new state will be reported as the
-    
-    argument to the /etc/powerd/scripts/sensor_battery
-    script. If a custom capacity limit was set via envstat(8),
-    the acpibat driver will report a
-    
-    event to the same script when current capacity limit has been reached.

-

-

-

-
acpi(4), envsys(4),
-    envstat(8), powerd(8)

-

-

-

-
The acpibat driver appeared in
-    NetBSD 1.6.

-

-

-

-
The ACPI specifications make a distinction between “control
-    method batteries” and “smart batteries”. The
-    acpibat driver only supports control method
-    batteries. Furthermore, acpibat does not yet support
-    some additional battery information introduced in the ACPI 4.0 standard.

-

-

-
-  
-    
-    
-  
-
March 17, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/acpibut.4 4.html b/static/netbsd/man4/acpibut.4 4.html
deleted file mode 100644
index 2ac93b3d..00000000
--- a/static/netbsd/man4/acpibut.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIBUT(4)Device Drivers ManualACPIBUT(4)

-

-

-

-
acpibut — ACPI
-    Button

-

-

-

-
acpibut* at acpi?

-

-

-

-
The acpibut driver supports two kinds of
-    ACPI buttons:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
/etc/powerd/scripts/power_button
/etc/powerd/scripts/sleep_button

-
When a button is pressed, the powerd(8) daemon,
-    if running, will execute the corresponding script.

-

-

-

-
acpi(4), powerd(8)

-

-

-

-
The acpibut driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
April 25, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/acpicpu.4 3.html b/static/netbsd/man4/acpicpu.4 3.html
deleted file mode 100644
index 364669bc..00000000
--- a/static/netbsd/man4/acpicpu.4 3.html	
+++ /dev/null
@@ -1,236 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPICPU(4)Device Drivers ManualACPICPU(4)

-

-

-

-
acpicpu — ACPI
-    CPU

-

-

-

-
acpicpu* at cpu?

-

-

-

-
The acpicpu device driver supports certain
-    processor features that are either only available via ACPI or that require
-    ACPI to function properly. Typically the ACPI processor functionality is
-    grouped into so-called C-, P-, and T-states.

-

-

-
The processor power states, or C-states, are low-power modes that
-    can be used when the CPU is idle. The idea is not new: already in the 80486
-    processor a specific instruction (HLT) was used for this purpose. This was
-    later accompanied by a pair of other instructions (MONITOR, MWAIT). By
-    default, NetBSD may use either one; see the
-    machdep.idle-mechanism sysctl(8)
-    variable. ACPI provides the latest amendment.

-
The following C-states are typically available. Additional
-    processor or vendor specific states (C4, ..., Cn) are handled internally by
-    acpicpu.

-

-

-  

-  
This is the normal state of a processor; the CPU is busy executing
-      instructions.

-  

-  
This is the state that is typically reached via the mentioned x86
-      instructions. On a typical processor, C1 turns off
-      the main internal CPU clock, leaving APIC running at full speed. The CPU
-      is free to temporarily leave the state to deal with important
-    requests.

-  

-  
The main difference between C1 and
-      C2 lies in the internal hardware entry method of
-      the processor. While less power is expected to be consumed than in
-      C1, the bus interface unit is still running. But
-      depending on the processor, the local APIC timer may be stopped. Like with
-      C1, entering and exiting the state are expected to
-      be fast operations.

-  

-  
This is the deepest conventional state. Parts of the CPU are actively
-      powered down. The internal CPU clock is stopped. The local APIC timer is
-      stopped. Depending on the processor, additional timers such as
-      x86/tsc(9) may be stopped. Processor caches may be
-      flushed. Entry and exit latencies are expected to be high; the CPU can no
-      longer “quickly” respond to bus activity or other
-      interruptions.

-

-

-
Each state has a latency associated with entry and exit. The
-    higher the state, the lower the power consumption, and the higher the
-    potential performance costs.

-
The acpicpu driver tries to balance the
-    latency constraints when choosing the appropriate state. One of the checks
-    involves bus master activity; if such activity is detected, a lower state is
-    used. It is known that particularly usb(4) may cause high
-    activity even when not in use. If maximum power savings are desirable, it
-    may be necessary to use a custom kernel without USB support. And generally:
-    to save power with C-states, one should avoid polling, both in userland and
-    in the kernel.

-

-

-

-
The processor performance states, or P-states, are used to control
-    the clock frequencies and voltages of a CPU. Underneath the abstractions of
-    ACPI, P-states are associated with such technologies as
-    “SpeedStep” (Intel), “PowerNow!” (AMD), and
-    “PowerSaver” (VIA).

-
The P0-state is always the highest operating frequency supported
-    by the processor. The number of additional P-states may vary across
-    processors and vendors. Each higher numbered P-state represents lower clock
-    frequencies and hence lower power consumption. Note that while
-    acpicpu always uses the exact frequencies
-    internally, the user-visible values reported by ACPI may be rounded or
-    approximated by the vendor.

-
Unlike conventional CPU frequency management, ACPI provides
-    support for Dynamic Voltage and Frequency Scaling (DVFS). Among other
-    things, this means that the firmware may request the implementation to
-    dynamically scale the presently supported maximum or minimum clock
-    frequency. For example, if acpiacad(4) is disconnected,
-    the maximum available frequency may be lowered. By default, the
-    NetBSD implementation may manipulate the frequencies
-    according to the notifications from the firmware.

-

-

-

-
Processor T-states, or “throttling states”, can be
-    used to actively modulate the time a processor is allowed to execute.
-    Outside the ACPI nomenclature, throttling and T-states may be known as
-    “on-demand clock modulation” (ODCM).

-
The concept of “duty cycle” is relevant to T-states.
-    It is generally defined to be a fraction of time that a system is in an
-    “active” state. The T0-state has always a duty cycle of 100 %,
-    and thus, comparable to the C0-state, the processor is fully active. Each
-    additional higher-numbered T-state indicates lower duty cycles. At most
-    eight T-states may be available, although also T-states use DVFS.

-
The duty cycle does not refer to the actual clock signal, but to
-    the time period in which the clock signal is allowed to drive the processor
-    chip. For instance, if a T-state has a duty cycle of 75 %, the CPU runs at
-    the same clock frequency and uses the same voltage, but 25 % of the time the
-    CPU is forced to idle. Because of this, the use of T-states may severely
-    affect system performance.

-
There are two typical situations for throttling: power management
-    and thermal control. As a technique to save power, T-states are largely an
-    artifact from the past. There was a short period in the x86 lineage when
-    P-states were not yet available and throttling was considered as an option
-    to modulate the processor power consumption. The approach was however
-    quickly abandoned. In modern x86 systems P-states should be preferred in all
-    circumstances. It is also more beneficial to move from the C0-state to
-    deeper C-states than it is to actively force down the duty cycle of a
-    processor.

-
But T-states have retained their use as a last line of defense
-    against critical thermal conditions. Many x86 processors include a
-    catastrophic shutdown detector. When the processor core temperature reaches
-    this factory defined trip-point, the processor execution is halted without
-    any software control. Before this fatal condition, it is possible to use
-    throttling for a short period of time in order to force the temperatures to
-    lower levels. The thermal control modulation is typically started only when
-    the system is in the highest-power P-state and a high temperature situation
-    exists. After the temperatures have returned to non-critical levels, the
-    modulation ceases.

-

-

-

-
The acpicpu driver uses the same
-    sysctl(8) controls for P-states as the ones provided by
-    est(4) and powernow(4). Please note that
-    future versions of acpicpu may however remove these
-    system control variables without further notice.

-
In addition, the following two variables are available.

-

-

-  

-  
A boolean that controls whether the states are allowed to change
-      dynamically. When enabled, C-, P-, and T-states may all change at runtime,
-      and acpicpu may also take actions based on
-      requests from the firmware.

-  

-  
A boolean that enables or disables automatic processor thermal management
-      via acpitz(4).

-

-

-

-

-

-
The acpicpu driver uses event counters to
-    track the times a processor has entered a given state. It is possible to
-    view the statistics by using vmstat(1) (with the
-    -e flag).

-

-

-

-

-
acpi(4), acpitz(4),
-    est(4), odcm(4),
-    powernow(4), cpu_idle(9)

-
Etienne Le Sueur and
-    Gernot Heiser, Dynamic Voltage
-    and Frequency Scaling: The Laws of Diminishing Returns,
-    http://www.ertos.nicta.com.au/publications/papers/LeSueur_Heiser_10.pdf,
-    October, 2010, Proceedings of the
-    2010 Workshop on Power Aware Computing and Systems
-    (HotPower'10).

-
David C. Snowdon,
-    Operating System Directed Power Management,
-    School of Computer Science and Engineering, University of New
-    South Wales,
-    http://ertos.nicta.com.au/publications/papers/Snowdon:phd.pdf,
-    March, 2010, PhD
-    Thesis.

-
Microsoft Corporation,
-    Windows Native Processor Performance Control,
-    Version 1.1a,
-    http://msdn.microsoft.com/en-us/windows/hardware/gg463343,
-    November, 2002.

-
Venkatesh Pallipadi and
-    Alexey Starikovskiy, The Ondemand
-    Governor. Past, Present, and Future, Intel Open Source
-    Technology Center,
-    https://www.kernel.org/doc/ols/2006/ols2006v2-pages-223-238.pdf,
-    July, 2006, Proceedings of the
-    Linux Symposium.

-

-

-

-
The acpicpu device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jukka Ruohonen
-    ⟨jruohonen@iki.fi⟩

-

-

-

-
At least the following caveats can be mentioned.

-
    
-  
  • It is currently only safe to use C1 on
-      NetBSD. All other C-states are disabled by
-      default.
    • 
-  
  • Processor thermal control (see acpitz(4)) is not yet
-      supported.
    • 
-  
  • Depending on the processor, changes in C-, P-, and T-states may all skew
-      timers and counters such as x86/tsc(9). This is neither
-      handled by acpicpu nor by est(4)
-      or powernow(4).
    • 
-  
  • There is currently neither a well-defined, machine-independent API for
-      processor performance management nor a “governor” for
-      different policies. It is only possible to control the CPU frequencies
-      from userland.
    • 
-

-

-

-
-  
-    
-    
-  
-
August 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/acpidalb.4 4.html b/static/netbsd/man4/acpidalb.4 4.html
deleted file mode 100644
index c963a0ac..00000000
--- a/static/netbsd/man4/acpidalb.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIDALB(4)Device Drivers ManualACPIDALB(4)

-

-

-

-
acpidalb — Direct
-    Application Launch Buttons

-

-

-

-
acpidalb* at acpi?

-

-

-

-
This driver provides support for PNP0C32 ACPI hotkeys a.k.a.
-    “The Direct Application Launch Buttons”.

-
These are recognized on startup from system-wake or at runtime.
-    Behaviour may differ from the standard specification in relation to the ACPI
-    implementation.

-
The hotkeys are reported to the power
-    management daemon as
-    .

-

-

-

-
acpi(4), powerd(8)

-
The PNP0C32 specification is described in:

-
Microsoft Corporation,
-    Direct Application Launch from System Startup on Windows
-    Vista,
-    http://www.microsoft.com/whdc/system/vista/DirAppLaunch.mspx,
-    October 26, 2006.

-

-

-

-
The acpidalb driver appeared in
-    NetBSD 5.0.

-

-

-

-
This driver was written for NetBSD by
-    Christoph Egger.

-

-

-
-  
-    
-    
-  
-
May 18, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/acpiec.4 4.html b/static/netbsd/man4/acpiec.4 4.html
deleted file mode 100644
index d11c6732..00000000
--- a/static/netbsd/man4/acpiec.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIEC(4)Device Drivers ManualACPIEC(4)

-

-

-

-
acpiec — ACPI
-    Embedded Controller

-

-

-

-
acpiec* at acpi?
-  

-  acpiecdt* at acpi?

-

-

-

-
The acpiec driver supports ACPI Embedded
-    Controllers.

-
An ACPI Embedded Controller (EC) is typically a small
-    microprocessor that is responsible for various tasks related to ACPI. The
-    primary task is to handle ACPI specific interrupts, which are mapped to
-    so-called ACPI General Purpose Events (GPEs). Other possible functions
-    include embedded access to other buses such as the
-  iic(4).

-
The ACPI specific events range from user initiated events to
-    events triggered by the hardware. When such an event occurs, typically
-    either a System Management Interrupt (SMI) or a System Control Interrupt
-    (SCI) is raised. The latter is an active, visible, shareable, level
-    interrupt. On most Intel chipsets SCI is hardwired to the interrupt number
-    9. The main task of an EC is to raise a system control interrupt.

-
All GPEs generate SCIs. A typical example of the internal wiring
-    of GPEs could involve gpio(4): when, e.g., the AC adapter
-    is connected, a certain GPIO line becomes active, a given GPE is flagged,
-    and a SCI interrupt is raised by the EC, leading to execution of ACPI
-    machine code in order to locate the handler associated with the event. A
-    corresponding driver, acpiacad(4) in this case, will
-    finally finish the processing of the event.

-
Due to the reasons described above, majority of ACPI specific
-    drivers are dysfunctional without acpiec. It is
-    therefore recommended that acpiec is always enabled,
-    even though it may not be required on some older systems.

-

-

-

-
acpi(4)

-

-

-

-
The acpiec driver appeared in
-    NetBSD 1.6.

-

-

-

-
Many machines depend on early attachment of
-    acpiec. In such cases the information required by
-    acpiec should be available as a separate and
-    optional Embedded Controller Descriptor Table (ECDT). If an ECDT is not
-    available or early attachment can not be carried out due other reasons, the
-    initialization of the whole acpi(4) subsystem may be
-    problematic.

-

-

-
-  
-    
-    
-  
-
February 27, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/acpifan.4 3.html b/static/netbsd/man4/acpifan.4 3.html
deleted file mode 100644
index 99a3fcf9..00000000
--- a/static/netbsd/man4/acpifan.4 3.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIFAN(4)Device Drivers ManualACPIFAN(4)

-

-

-

-
acpifan — ACPI
-    Fan

-

-

-

-
acpifan* at acpi?

-

-

-

-
The acpifan device driver supports fans
-    possibly exposed by the BIOS. Even if a system contains only one physical
-    fan, multiple acpifan instances may be present. In
-    such cases each acpifan typically represents an
-    acpitz(4) thermal zone, and the combined state of all
-    instances reveals the speed of the fan.

-
The acpifan driver does not support
-    controlling the fan. The current state (on or off) is made available through
-    the envsys(4) API and the envstat(8)
-    command.

-

-

-

-
acpi(4), acpitz(4)

-

-

-

-
The acpifan device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jukka Ruohonen
-    ⟨jruohonen@iki.fi⟩

-

-

-

-
The acpifan driver does not yet support
-    additional functionality introduced in the ACPI 4.0 specification.

-

-

-
-  
-    
-    
-  
-
January 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/acpihed.4 4.html b/static/netbsd/man4/acpihed.4 4.html
deleted file mode 100644
index 278f7dba..00000000
--- a/static/netbsd/man4/acpihed.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIHED(4)Device Drivers ManualACPIHED(4)

-

-

-

-
acpihed — ACPI
-    Hardware Error Device

-

-

-

-
acpihed* at acpi?

-

-

-

-
Certain hardware error sources that can be queried by
-    apei(4) notify an ACPI node with PNP ID
-    ‘PNP0C33’ when an error occurs. The
-    acpihed driver listens for these notifications and
-    passes them on to apei(4) so it can report the error.

-

-

-

-
acpi(4), apei(4)

-
ACPI Specification 6.5,
-    https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html,
-    Chapter 18: ACPI Platform Error Interfaces
-    (APEI).

-

-

-

-
The acpihed driver first appeared in
-    NetBSD 10.1.

-

-

-

-
The acpihed driver was written by
-    Taylor R Campbell
-    <riastradh@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 18, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/acpilid.4 4.html b/static/netbsd/man4/acpilid.4 4.html
deleted file mode 100644
index 0d0ef981..00000000
--- a/static/netbsd/man4/acpilid.4 4.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPILID(4)Device Drivers ManualACPILID(4)

-

-

-

-
acpilid — ACPI Lid
-    Switch

-

-

-

-
acpilid* at acpi?

-

-

-

-
The acpilid driver supports ACPI
-    “lid switches”. The powerd(8) daemon can be
-    used to control actions against the events of opening or closing the lid.
-    The script used is /etc/powerd/scripts/lid_switch,
-    and the events are either
-    
-    (the lid was closed) or
-    
-    (the lid was opened).

-

-

-

-
The following example modifies the mentioned script in order to
-    put the system into (S3) sleep when the lid is closed:

-

-
...
-
-case "${2}" in
-pressed)
-        logger -p info "${0}: suspending..."
-
-        # As in sleep_button, kill some daemons.
-        #
-        /etc/rc.d/dhcpcd stop
-        /etc/rc.d/network stop
-        /etc/rc.d/wpa_supplicant stop
-
-        # Suspend.
-        #
-        if /sbin/sysctl hw.acpi.sleep.state >/dev/null 2>&1; then
-                /sbin/sysctl -w hw.acpi.sleep.state=3
-	fi
-
-        # Waking up.
-        #
-        /etc/rc.d/wpa_supplicant start
-        /etc/rc.d/network start
-        /etc/rc.d/dhcpcd start
-
-...

-

-

-

-

-
acpi(4), powerd(8),
-    sysmon_pswitch(9)

-

-

-

-
The acpilid driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
January 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/acpipmtr.4 4.html b/static/netbsd/man4/acpipmtr.4 4.html
deleted file mode 100644
index d4edfae0..00000000
--- a/static/netbsd/man4/acpipmtr.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIPMTR(4)Device Drivers ManualACPIPMTR(4)

-

-

-

-
acpipmtr — ACPI
-    Power Meter

-

-

-

-
acpipmtr* at acpi?

-

-

-

-
The acpipmtr device driver provides
-    support for “power meters”. These are sensors that approximate
-    the current power consumption of the system. Alternatively, a power meter
-    may measure also the power gain when the system is connected to an external
-    power supply.

-
The available information (namely, the power consumption) is made
-    available through the envsys(4) API and the
-    envstat(8) command.

-

-

-

-
acpi(4), acpibat(4)

-

-

-

-
The acpipmtr device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jukka Ruohonen
-    <jruohonen@iki.fi>

-

-

-

-
The acpipmtr driver is experimental.

-

-

-
-  
-    
-    
-  
-
May 25, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/acpismbus.4 4.html b/static/netbsd/man4/acpismbus.4 4.html
deleted file mode 100644
index c72f5620..00000000
--- a/static/netbsd/man4/acpismbus.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPISMBUS(4)Device Drivers ManualACPISMBUS(4)

-

-

-

-
acpismbus — ACPI
-    SMBus Control Method Interface

-

-

-

-
acpismbus* at acpi?
-  

-  iic* at acpismbus?

-

-

-

-
The acpismbus driver supports instances of
-    the ACPI SMBus Control Method Interface. This enables i2c access to bus
-    segments which might not otherwise be accessible due to missing
-    "native" driver support. The SMBus Process Call protocol is not
-    supported. All other SMBus protocols are supported to the extent that the
-    underlying controller supports them.

-

-

-

-
acpi(4), iic(4)

-

-

-

-
The acpismbus driver appeared in
-    NetBSD 6.0.

-

-

-

-
Although acpismbus SMBus Alerts can be
-    associated with individual devices, this capability is ignored. When an
-    acpismbus SMBus Alert is generated, all devices on
-    the i2c bus segment which have registered an interrupt routine are
-  notified.

-
The SMBus CMI protocol defines a method to provide a list of
-    devices on an i2c bus segment and their addresses. The
-    acpismbus driver makes no attempt to retrieve or
-    process this device list.

-
There is currently no way to determine if the i2c controller
-    managed by an instance of the ACPI SMBus CMI can also be accessed using a
-    native device driver. Therefore, the acpismbus
-    driver should not be enabled by default. If both a native driver and the
-    acpismbus driver attempt to access the same i2c bus
-    segment, the results are undefined.

-

-

-
-  
-    
-    
-  
-
February 6, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/acpitz.4 4.html b/static/netbsd/man4/acpitz.4 4.html
deleted file mode 100644
index 654274cb..00000000
--- a/static/netbsd/man4/acpitz.4 4.html	
+++ /dev/null
@@ -1,96 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPITZ(4)Device Drivers ManualACPITZ(4)

-

-

-

-
acpitz — ACPI
-    Thermal Zone

-

-

-

-
acpitz* at acpi?

-

-

-

-
The acpitz driver supports so-called ACPI
-    “Thermal Zones”. The temperature can be monitored by the
-    envsys(4) API or the envstat(8)
-  command.

-
The distinction between “active” and
-    “passive” cooling is central to the abstractions behind
-    acpitz. These are inversely related to each
-  other:

-
    
-  
  1. Active cooling means that the system increases the power consumption of
-      the machine by performing active thermal management (for example, by
-      turning on a fan) in order to reduce the temperatures.
    2. 
-  
  2. Passive cooling means that the system reduces the power consumption of
-      devices at the cost of system performance (for example, by lowering the
-      CPU frequencies) in order to reduce the temperatures.
    3. 
-

-
Only active cooling is currently supported on
-    NetBSD.

-
It should be also noted that the internal functioning of these
-    cooling policies vary across machines. On some machines the operating system
-    may have little control over the thermal zones as the firmware manages the
-    thermal control internally, whereas on other machines the policies may be
-    exposed to the implementation at their full extent.

-

-

-

-
The acpitz driver knows about the active
-    cooling levels, the current temperatures, and critical, hot, and passive
-    temperature thresholds (as supported by the hardware). The driver is able to
-    send events to powerd(8) when the sensor's state has
-    changed. When a Thermal Zone is either critical or “hot”, the
-    /etc/powerd/scripts/sensor_temperature script will
-    be invoked with a
-    
-    event.

-
The critical temperature is the threshold for system shutdown.
-    Depending on the hardware, the mainboard will take down the system instantly
-    and no event will have a chance to be sent.

-

-

-

-
acpi(4), acpifan(4),
-    envsys(4), envstat(8),
-    powerd(8)

-

-

-

-
The acpitz driver appeared in
-    NetBSD 2.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-

-
While no pronounced bugs are known to exist, several caveats can
-    be mentioned:

-
    
-  
  • Passive cooling is not implemented.
    • 
-  
  • There is no user-controllable way to switch between active and passive
-      cooling, although the specifications support such transforms on some
-      machines.
    • 
-  
  • The “hot” temperature is a threshold in which the system
-      ought to be put into S4 sleep. This sleep state (“suspend to
-      disk”) is not supported on NetBSD.
    • 
-

-

-

-
-  
-    
-    
-  
-
January 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/acpivga.4 4.html b/static/netbsd/man4/acpivga.4 4.html
deleted file mode 100644
index a257228e..00000000
--- a/static/netbsd/man4/acpivga.4 4.html	
+++ /dev/null
@@ -1,91 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIVGA(4)Device Drivers ManualACPIVGA(4)

-

-

-

-
acpivga — ACPI
-    Display Adapter and Output Devices

-

-

-

-
acpivga* at acpi?
-  

-  acpiout* at acpivga?

-

-

-

-
The acpivga driver provides generic
-    support for brightness control and output switching, through ACPI video
-    extensions. The ACPI specification requires that systems containing a
-    built-in display adapter implement these extensions in their ACPI BIOS.

-
The driver handles brightness hotkeys and display switch hotkeys.
-    In addition, the following sysctl(8) read/write variables
-    are provided (when hardware support is available):

-

-  
hw.acpi.acpivga0.bios_switch

-  
BIOS output switching policy. This boolean variable controls the behavior
-      of the BIOS when a display switch hotkey is pressed.
-    

-      

-      
the BIOS should automatically switch outputs, with no interaction from
-          acpivga.

-      

-      
the BIOS should only notify acpivga of the
-          desired output state changes.

-    

-  

-  
hw.acpi.acpiout0.brightness

-  
Brightness level. This integer variable typically ranges from 0 to 100,
-      but any integer value is accepted (the driver uses the closest brightness
-      level supported by the device).

-

-
Please note, however, that future versions of
-    acpivga may remove these sysctl(8)
-    variables without prior notice.

-

-

-

-
acpi(4), vga(4),
-    sysctl(8)

-
Microsoft Corporation,
-    Mobile System Displays and Windows,
-    Version 1.2c,
-    http://www.microsoft.com/whdc/archive/mobiledisplay.mspx,
-    December 4, 2001.

-

-

-

-
The acpivga driver appeared in
-    NetBSD 6.0.

-

-

-

-
Grégoire Sutre
-    ⟨gsutre@NetBSD.org⟩

-

-

-

-
The acpivga driver only supports
-    PCI/PCI-X/PCI-E display adapters.

-
Many ACPI BIOSes implement only part of the ACPI video extensions.
-    In particular, display output switching via these extensions often does not
-    work. For this reason, acpivga enables
-    hw.acpi.acpivga0.bios_switch by default. If the
-    display switch hotkey does not work with this default setting, try setting
-    hw.acpi.acpivga0.bios_switch to 0.

-
Brightness level should be controlled via
-    wsconsctl(8) instead of sysctl(8).

-

-

-
-  
-    
-    
-  
-
October 28, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/acpivmgenid.4 4.html b/static/netbsd/man4/acpivmgenid.4 4.html
deleted file mode 100644
index 60a86f1a..00000000
--- a/static/netbsd/man4/acpivmgenid.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIVMGENID(4)Device Drivers ManualACPIVMGENID(4)

-

-

-

-
acpivmgenid — ACPI
-    Virtual Machine Generation ID

-

-

-

-
acpivmgenid* at acpi?

-

-

-

-
acpivmgenid provides a generation ID for
-    virtual machines.

-
When starting two otherwise identical virtual machines, whether
-    from the same clean image or by cloning snapshots or any other mechanism,
-    the VM host may choose a different generation ID. Although this generation
-    ID is not secret, it is incorporated into the entropy(7)
-    pool (with a measure of zero entropy) so that the two virtual machines will
-    produce independent random output.

-
If a live VM is cloned, the VM host may change the generation ID
-    in one or both of the clones and notify them through the
-    acpivmgenid device. When this happens,
-    NetBSD will reseed system random number generators,
-    so that output of /dev/urandom and
-    getentropy(3) will be independent in the two clones, and
-    the sysctl(7) variable
-    kern.entropy.epoch will advance to notify
-    applications that they should reseed random number generators from the
-    system entropy pool.

-

-

-

-
The following sysctl(7) nodes are available:

-

-  
N.id

-  
The current 16-byte VM generation ID.

-  
N.paddr

-  
The physical address of the VM generation ID provided by the host.

-

-

-

-

-
arc4random(3), getentropy(3),
-    rnd(4), entropy(7)

-
Virtual Machine Generation
-    ID,
-    http://go.microsoft.com/fwlink/?LinkId=260709,
-    Microsoft,
-    2018-08-01.

-
Virtual Machine Generation ID
-    Device,
-    https://www.qemu.org/docs/master/specs/vmgenid.html,
-    The QEMU Project Developers.

-

-

-

-
The acpivmgenid driver first appeared in
-    NetBSD 10.1.

-

-

-

-
Currently there is no cheaper way to detect VM generation ID
-    changes than to query sysctl. (Applications deciding whether to reseed
-    random number generators should generally query
-    kern.entropy.epoch, not
-    hw.acpivmgenidN.id.)

-

-

-
-  
-    
-    
-  
-
August 26, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/acpiwdrt.4 4.html b/static/netbsd/man4/acpiwdrt.4 4.html
deleted file mode 100644
index ef9783dc..00000000
--- a/static/netbsd/man4/acpiwdrt.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIWDRT(4)Device Drivers ManualACPIWDRT(4)

-

-

-

-
acpiwdrt — ACPI
-    Watchdog Timer (WDRT)

-

-

-

-
acpiwdrt* at acpi?

-

-

-

-
The acpiwdrt driver provides support for
-    watchdog timers specified in a so-called ACPI watchdog resource table
-    (WDRT). The acpiwdrt watchdog timer is configurable
-    via the wdogctl(8) utility.

-

-

-

-
acpi(4), wdogctl(8)

-
Microsoft Corporation,
-    Watchdog Timer Hardware Requirements for Windows Server
-    2003, Version 1.01,
-    http://www.microsoft.com/whdc/system/sysinternals/watchdog.mspx,
-    August 28, 2006.

-

-

-

-
The acpiwdrt device driver appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
January 17, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/acpiwmi.4 4.html b/static/netbsd/man4/acpiwmi.4 4.html
deleted file mode 100644
index 5f44733a..00000000
--- a/static/netbsd/man4/acpiwmi.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACPIWMI(4)Device Drivers ManualACPIWMI(4)

-

-

-

-
acpiwmi — Windows
-    Management Instrumentation support for ACPI

-

-

-

-
acpiwmi* at acpi?
-  

-  wmidell* at acpiwmibus?
-  

-  wmieeepc* at acpiwmibus?
-  

-  wmihp* at acpiwmibus?
-  

-  wmimsi* at acpiwmibus?

-

-

-

-
The acpiwmi device driver provides an ACPI
-    interface for Windows Management Instrumentation (WMI). The ACPI WMI
-    interface is typically used to support vendor specific features found in
-    various laptops.

-
The following WMI mappings are supported:

-

-

-  

-  
Dell laptops

-  

-  
Some models of Asus Eee PC

-  

-  
Hewlett-Packard laptops

-  

-  
MSI laptops

-

-

-
The functionality varies from vendor to vendor. Typically the
-    interface is used for function and hotkey handling, but additional features
-    may be present.

-

-

-

-
acpi(4), acpidalb(4)

-
Microsoft Corporation,
-    Windows Instrumentation: WMI and ACPI,
-    http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx,
-    December 4, 2001.

-

-

-

-
The acpiwmi device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jukka Ruohonen
-    <jruohonen@iki.fi>
-    wrote acpiwmi and most of the mappings.

-

-

-

-
While WMI should provide a certain degree of portability across
-    laptop models from a particular vendor, there is no guarantee that the
-    mappings are functional in all models.

-
The wmihp driver may conflict with
-    hpqlb(4).

-

-

-
-  
-    
-    
-  
-
May 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/adb.4 4.html b/static/netbsd/man4/adb.4 4.html
deleted file mode 100644
index a9e072ae..00000000
--- a/static/netbsd/man4/adb.4 4.html	
+++ /dev/null
@@ -1,187 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADB(4)Device Drivers ManualADB(4)

-

-

-

-
adb — Apple
-    Desktop Bus driver

-

-

-

-
adb* at obio?

-

-  

-  options MRG_ADB

-

-  

-  #include
-  <machine/adbsys.h>

-

-

-

-
The Apple Desktop Bus (ADB) is the single-master, multiple-slave,
-    low-speed serial bus interface used by Macintosh computers to connect input
-    devices such as keyboards, mice, trackpads, trackballs, and graphics tablets
-    to the machine. NetBSD provides support for the
-    Apple Desktop Bus as found on all supported mac68k models, as well as macppc
-    models with on-board ADB (PowerBooks and “Old World”
-  models).

-
The adb driver accesses the ADB controller
-    using the so-called “HWDIRECT” method. This method of access
-    bypasses the Macintosh ROM and uses only NetBSD
-    routines for ADB access. This is the only method supported on macppc and is
-    the default for mac68k systems.

-
On mac68k systems there is an alternate method of accessing the
-    ADB controller. With the Macintosh ROM Glue (MRG) method, the routines
-    written for MacOS are used. To enable this method of ADB access, uncomment
-    the line:

-
options MRG_ADB

-
in your kernel configuration file.

-
The ioctl(2) call is used to control the ADB
-    event device. The following is a list of available
-    ioctl(2) commands:

-

-  

-  
Get ADB Device Info
-    
The adb event device will return an
-        array of information containing an entry for each device connected to
-        the bus. Each entry contains the current address, default address, and
-        handler ID for the corresponding ADB device.

-  

-  

-  
Get Keyboard Repeat Info
-    
Returns a structure containing the current keyboard repeat
-        delay and keyboard repeat interval.

-  

-  

-  
Set Keyboard Repeat Rate
-    
Sets the keyboard repeat delay and interval to the values
-        specified by argp.

-  

-  

-  
ADB Reset
-    
Perform a reset of the ADB which will reinitialize all of the
-        devices attached to the bus.

-  

-  

-  
ADB Listen Command
-    
Send data to the register of the ADB device specified by
-        argp. This command is not fully implemented at
-        this time.

-  

-

-

-

-

-
NetBSD includes support for the following
-    ADB devices, sorted by driver name:

-

-

-  
abtn

-  
ADB mouse button?

-  
aed

-  
ADB event device

-  
akbd

-  
ADB keyboard

-  
ams

-  
ADB mouse

-  
apm

-  
APM emulation

-

-

-

-

-

-

-  
/dev/adb

-  
The ADB event device.

-

-

-

-

-

-  
aed0 at adb0 addr 0: ADB Event device

-  
This is a normal autoconfiguration message noting the presence of the
-      adb event device.

-  
adb0 at obio0 offset 0x16000 irq 18: 2 targets

-  
A standard autoconfiguration message indicating the initialization of the
-      ADB subsystem.

-  
adb: no devices found.

-  
No ADB devices were found to be connected to the bus during
-      autoconfiguration.

-  
adb: using %s series hardware support.

-  
Indicates the class of ADB hardware support the machine uses.

-  
adb: hardware type unknown for this machine.

-  
The ADB hardware in this machine is currently unsupported.

-  
adb: no ROM ADB driver in this kernel for this machine.

-  
The kernel lacks the necessary Macintosh ROM Glue (MRG) support for
-      accessing the ADB hardware on this machine.

-  
adb: using serial console.

-  
A serial console will be used for user input rather than the ADB event
-      device.

-  
adb: %s at %d.

-  
An ADB device of the type specified by
-       has been found at
-      location
-    .

-

-

-

-

-
aed(4), akbd(4),
-    ams(4), apm(4)

-

-

-

-
The adb interface first appeared in
-    NetBSD 0.9. It has been under development ever
-    since.

-

-

-

-
Bradley A. Grantham wrote the original
-    adb driver, including the MRG support. The hardware
-    direct interface was written by John P. Wittkowski.
-    The PowerManager interface was written by Takashi
-    Hamada.

-

-

-

-
    
-  
  • Not every class of ADB hardware is supported yet.
    • 
-  
  • The talk command is currently unimplemented.
    • 
-  
  • The listen command is not implemented yet.
    • 
-  
  • Not all multi-button mice are currently supported.
    • 
-  
  • Only mapped and relative-position ADB devices (i.e. keyboards and mice)
-      are supported. Thus absolute-position and other exotic devices will not
-      work.
    • 
-  
  • Some of the diagnostic messages in this man page need to be updated.
    • 
-

-
Some mac68k machines contain so-called dirty ROM. These machines
-    are the: Mac SE/30, Mac II, Mac IIx, and Mac IIcx. Machines with dirty ROM
-    may experience trouble booting if the MRG code is used, especially under the
-    following conditions:

-
    
-  
  • Both a keyboard and a mouse are not attached to the computer.
    • 
-  
  • An extended keyboard is attached to the computer.
    • 
-

-
On (some) machines with dirty ROM, the ROM indicates the presence
-    of a “ghost” keyboard or mouse. When this nonexistent device
-    is probed for, the result is an infinite loop. This is believed to be
-    triggered by the adb driver probing for extended
-    mice, and non-EMP Logitech mice.

-

-

-
-  
-    
-    
-  
-
August 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/adbbt.4 4.html b/static/netbsd/man4/adbbt.4 4.html
deleted file mode 100644
index e4d8dfce..00000000
--- a/static/netbsd/man4/adbbt.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADBBT(4)Device Drivers ManualADBBT(4)

-

-

-

-
adbbt — support
-    for ADB hotkey devices found in some Apple laptops

-

-

-

-
adbbt* at nadb?
-  

-  wskbd* at adbbt?

-

-

-

-
The adbbt driver handles all ADB hotkey
-    devices within the wscons(4) framework. So far it only
-    translates button events back to their corresponding function key codes.

-

-

-

-
nadb(4), wskbd(4),
-    wsconsctl(8)

-

-

-

-
Actually send hotkey events at least for the classes we can handle
-    like display brightness.

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/adbkbd.4 4.html b/static/netbsd/man4/adbkbd.4 4.html
deleted file mode 100644
index 6c068cbd..00000000
--- a/static/netbsd/man4/adbkbd.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADBKBD(4)Device Drivers ManualADBKBD(4)

-

-

-

-
adbkbd — support
-    for ADB keyboards

-

-

-

-
adbkbd* at nadb?
-  

-  wskbd* at adbkbd? console ? mux 1
-  

-  wsmouse* at adbkbd?

-

-

-

-
The adbkbd driver handles most ADB
-    keyboards within the wscons(4) framework. It also provides
-    an interface to translate key strokes to mouse button events.

-
Which keys are translated to mouse button events can be configured
-    for each individual keyboard via sysctl(8):

-

-  

-  
Controls which scan code is used for middle mouse button events. Default
-      is 103, which corresponds to F11.

-  

-  
Controls which scan code is used for right mouse button events. Default is
-      111, which corresponds to F12.

-

-

-

-

-
nadb(4), wskbd(4),
-    wsmouse(4), wsconsctl(8),
-    wskbd(9)

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/adbms.4 4.html b/static/netbsd/man4/adbms.4 4.html
deleted file mode 100644
index d7422fea..00000000
--- a/static/netbsd/man4/adbms.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADBMS(4)Device Drivers ManualADBMS(4)

-

-

-

-
adbms — support
-    for ADB mice, trackballs, and touchpads

-

-

-

-
adbms* at nadb?
-  

-  wsmouse* at adbms?

-

-

-

-
The adbms driver handles most relative ADB
-    pointing devices within the wscons(4) framework. For
-    touchpads it also provides support for translating tapping the pad to mouse
-    button events.

-
Tapping support can be turned on or off on a per-device basis
-    using sysctl(8):

-

-  

-  
0 disables tapping, 1 enables it.

-

-

-

-

-
nadb(4), wsmouse(4),
-    wsconsctl(8)

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/adc.4 4.html b/static/netbsd/man4/adc.4 4.html
deleted file mode 100644
index 931269df..00000000
--- a/static/netbsd/man4/adc.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADC(4)Device Drivers ManualADC(4)

-

-

-

-
adc — SuperH
-    on-chip analog/digital converter

-

-

-

-
adc* at shb?

-

-

-

-
The adc driver provides support for a
-    10-bit successive-approximation A/D converter with a selection of up to
-    eight analog input channels. ADC is an on-chip module found in some SuperH
-    microprocessors (SH7709 and others).

-

-

-

-
shb(4)

-

-

-

-
The adc driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
October 21, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/adm1026hm.4 4.html b/static/netbsd/man4/adm1026hm.4 4.html
deleted file mode 100644
index 513e1531..00000000
--- a/static/netbsd/man4/adm1026hm.4 4.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADM1026HM(4)Device Drivers ManualADM1026HM(4)

-

-

-

-
adm1026hm — Analog
-    Devices ADM1026 complete thermal system management controller

-

-

-

-
adm1026hm* at iic? addr?

-

-

-

-
The adm1026hm driver provides support for
-    the Analog Devices ADM1026 hardware monitor. The chip possesses 8 fan speed
-    sensors, 3 temperature sensors, and 17 voltage sensors. The number of each
-    sensor type configured by the driver depends on the chip configuration.

-
The values of the sensors are made available through the
-    envstat(8) interface.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-

-      NRPMFan 0–7
CInternal temperature

-      NCExternal temperature 1–2
mV DCBattery voltage
V3.3 standbymV DC3.3V standby voltage
V3.3 mainmV DC3.3V main voltage
mV DC5.0V supply voltage
mV DC+12V supply voltage
mV DC-12V supply voltage

-      NmV DCAnalog in (3.3V reference) 0–5

-      NmV DCAnalog in (2.5V reference) 0–3

-
Configurable limits for the sensors are also available via
-    envstat(8). Initial limit values are read from the chip.
-    Each temperature sensor has a high, therm and low limit, which are mapped to
-    critmax, warnmax and
-    warnmin, respectively. Voltage sensors have high
-    (warnmax) and low (warnmin)
-    limits. Fan sensors have a high limit mapped to
-    warnmin, because the fan measurements are revolution
-    intervals, so higher numbers correlate to lower fan speeds.

-

-

-

-
iic(4), intro(4),
-    envstat(8)

-

-

-

-
The adm1026hm driver was written by
-    Julian Coleman
-    <jcoleman@NetBSD.org>.

-

-

-

-
It's not possible to determine if either a sensor is not
-    connected, or the monitored device is producing no output. Therefore,
-    unconnected sensors will show outputs of 0.

-
The adm1026hm driver does not support
-    interrupt output nor the built-in EEPROM.

-

-

-
-  
-    
-    
-  
-
February 16, 2026NetBSD 10.1

diff --git a/static/netbsd/man4/admtemp.4 3.html b/static/netbsd/man4/admtemp.4 3.html
deleted file mode 100644
index 0ee4652f..00000000
--- a/static/netbsd/man4/admtemp.4 3.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADMTEMP(4)Device Drivers ManualADMTEMP(4)

-

-

-

-
admtemp — Analog
-    Devices ADM1021 temperature sensor

-

-

-

-
admtemp* at iic? addr 0x18

-

-

-

-
The admtemp driver provides support for
-    the Analog Devices ADM1021, Analog Devices ADM1023, Analog Devices ADM1032,
-    Genesys Logic GL523SM, Global Mixed-mode Technology G781, Texas Instruments
-    LM84, Maxim 1617, Maxim 1617A, Philips Semiconductors NE1617A, and Xeon
-    embedded temperature sensors. The device possesses internal and external
-    temperature sensors, and programmable low and high temperature limits, with
-    a temperature range of -65 to +127 degC and a resolution of 1 degC.

-
On i386 machines, this driver also supports the Xeon embedded I2C
-    temperature probes. In this case, however, only one temperature value is
-    provided.

-
Exceeding the temperature limits causes the device to assert an
-    Alarm signal, which can be used by other hardware to detect critical
-    conditions.

-
Some sensors differ from the ADM1021, MAX1617 and NE1617A:

-
    
-  
  • The ADM1021A, ADM1023, ADM1032, and G781 have a temperature range of 0 to
-      +127 degC and a resolution of 1 degC.
    • 
-  
  • The LM84 has no low temperature limits.
    • 
-  
  • The ADM1023, ADM1032, and G781 have extended precision remote temperature
-      sensors, with a range of 0 to +127.875 degC and a resolution of 0.125
-      degC.
    • 
-  
  • The ADM1032 and G781 have additional high temperature limits with a range
-      of 0 to +127 degC and a resolution of 1 degC. If these are exceeded, a
-      separate Therm signal is asserted.
    • 
-

-
The sensor and limit values are made available through the
-    envstat(8) interface. For devices without additional high
-    temperature limits, the limits that are displayed and set are the critical
-    limits. For devices with additional high temperature limits, high and low
-    temperature warning limits and high temperature critical limits are
-    displayed and can be set.

-

-

-

-
iic(4), intro(4),
-    envstat(8)

-

-

-

-
The admtemp driver was written by
-    Theo de Raadt
-    <deraadt@openbsd.org>.
-    Extended precision temperatures, and limit display and setting were added by
-    Julian Coleman
-    <jdc@NetBSD.org>.

-

-

-

-
Limit sensors occasionally read as 0xff. If this occurs, the
-    admtemp driver will ignore that limit.

-

-

-
-  
-    
-    
-  
-
December 31, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/adv.4 4.html b/static/netbsd/man4/adv.4 4.html
deleted file mode 100644
index b6cd6217..00000000
--- a/static/netbsd/man4/adv.4 4.html	
+++ /dev/null
@@ -1,144 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADV(4)Device Drivers ManualADV(4)

-

-

-

-
adv — ConnectCom
-    Solutions AdvanSys SCSI adapter driver

-

-

-

-
adv* at pci? dev ? function ?
-  

-  adv0 at isa? port ? irq ? drq ?
-  

-  adv* at cardbus? function ?
-  

-  scsibus* at adv?

-

-

-

-
The adv driver supports the following
-    AdvanSys SCSI host adapters

-

-

-
Connectivity Products:

-

-

-  
ABP920

-  
Bus-Master PCI (16 CDB)

-  
ABP930

-  
Bus-Master PCI (16 CDB) (note 1)

-  
ABP930U

-  
Bus-Master PCI Ultra (16 CDB)

-  
ABP930UA

-  
Bus-Master PCI Ultra (16 CDB)

-  
ABP960

-  
Bus-Master PCI MAC/PC (16 CDB) (note 2)

-  
ABP960U

-  
Bus-Master PCI MAC/PC Ultra (16 CDB) (note 2)

-

-

-
Notes:

-
    
-  
  1. This board has been sold by SIIG as the Fast SCSI Pro PCI.
    2. 
-  
  2. This board has been sold by Iomega as a Jaz Jet PCI adapter.
    3. 
-

-
Single Channel Products:

-

-

-  
ABP940

-  
Bus-Master PCI (240 CDB)

-  
ABP940U

-  
Bus-Master PCI Ultra (240 CDB)

-  
ABP970

-  
Bus-Master PCI MAC/PC (240 CDB)

-  
ABP970U

-  
Bus-Master PCI MAC/PC Ultra (240 CDB)

-  
ABP940UW

-  
Bus-Master PCI Ultra-Wide (240 CDB)

-

-

-
Multi Channel Products:

-

-

-  
ABP950

-  
Dual Channel Bus-Master PCI (240 CDB Per Channel)

-  
ABP980

-  
Four Channel Bus-Master PCI (240 CDB Per Channel)

-  
ABP980U

-  
Four Channel Bus-Master PCI Ultra (240 CDB Per Channel)

-

-

-

-

-

-
Connectivity Products:

-

-

-  
ABP510/5150

-  
Bus-Master ISA (240 CDB) (note 1)

-  
ABP5140

-  
Bus-Master ISA (16 CDB) (note 1) (note 2)

-  
ABP5142

-  
Bus-Master ISA with floppy (16 CDB) (note 3)

-

-

-
Notes:

-
    
-  
  1. This board has been shipped by HP with the 4020i CD-R drive. The board has
-      no BIOS so it cannot control a boot device, but it can control any
-      secondary SCSI device.
    2. 
-  
  2. This board has been sold by SIIG as the i540 SpeedMaster.
    3. 
-  
  3. This board has been sold by SIIG as the i542 SpeedMaster.
    4. 
-

-
Single Channel Products:

-

-

-  
ABP542

-  
Bus-Master ISA with floppy (240 CDB)

-  
ABP842

-  
Bus-Master VL (240 CDB)

-

-

-
Dual Channel Products:

-

-

-  
ABP852

-  
Dual Channel Bus-Master VL (240 CDB Per Channel)

-

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), isa(4),
-    pci(4), scsi(4),
-    sd(4), st(4)

-

-

-

-
The adv device driver appeared in
-    NetBSD 1.4.

-

-

-

-
Baldassare Dante Profeta
-    ⟨dante@mclink.it⟩

-

-

-
-  
-    
-    
-  
-
June 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/adw.4 4.html b/static/netbsd/man4/adw.4 4.html
deleted file mode 100644
index dd435188..00000000
--- a/static/netbsd/man4/adw.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
ADW(4)Device Drivers ManualADW(4)

-

-

-

-
adw — ConnectCom
-    Solutions AdvanSys PCI Ultra Wide SCSI host adapter driver

-

-

-

-
adw* at pci? dev ? function ?
-  

-  scsibus* at adw?

-

-  

-  options FAILSAFE
-  

-  options SCSI_ADW_WDTR_DISABLE=mask
-  

-  options SCSI_ADW_SDTR_DISABLE=mask
-  

-  options SCSI_ADW_TAGQ_DISABLE=mask

-

-

-

-
The adw driver provides support for the
-    ADW (AdvanSys) ABP-940UW, ASB-3940UW, ASB-3940U2W SCSI host adapters.

-
The following kernel configuration options are available:

-

-  
options FAILSAFE

-  
Disables tagged command queuing, wide data transfers and synchronous data
-      transfers for all SCSI devices controlled by the
-      adw driver. By default, tagged command queuing,
-      wide data transfers and synchronous data transfers are used if the SCSI
-      devices support them.
-    
The following options use a mask to specify
-        which SCSI peripherals the option applies to. The mask
-        is a 16 bit bitfield value. Each bit corresponds to a peripheral ID. The
-        LSB (bit 0) corresponds to the peripheral with ID 0. The MSB (bit 15)
-        corresponds to the peripheral with ID 15. The following features cannot
-        be disabled for the host adapter, which by default has ID 7.

-  

-  
options SCSI_ADW_WDTR_DISABLE=mask

-  
Disable WIDE data transfer for the peripherals specified by the mask
-      value.

-  
options SCSI_ADW_SDTR_DISABLE=mask

-  
Disable SYNCHRONOUS data transfer for the peripherals specified by the
-      mask value.

-  
options SCSI_ADW_TAGQ_DISABLE=mask

-  
Disable TAGGED COMMAND QUEUING for the peripherals specified by the mask
-      value.

-

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4),
-  uk(4)

-

-

-

-
The adw device driver appeared in
-    NetBSD 1.4.

-

-

-

-
Baldassare Dante Profeta
-    ⟨dante@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
February 3, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/age.4 4.html b/static/netbsd/man4/age.4 4.html
deleted file mode 100644
index 9c123d45..00000000
--- a/static/netbsd/man4/age.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
AGE(4)Device Drivers ManualAGE(4)

-

-

-

-
age — Attansic L1
-    10/100/Gigabit Ethernet device

-

-

-

-
age* at pci?
-  

-  atphy* at mii?

-

-

-

-
The age driver provides support for
-    Ethernet interfaces based on the Attansic L1 Ethernet chipset.

-
The age driver supports IPv4 receive
-    IP/TCP/UDP checksum offload and VLAN tag insertion and stripping.

-
The following media types are supported:

-

-

-  

-  
Enable autoselection of the media type and options.

-  

-  
Set 10Mbps operation.

-  

-  
Set 100Mbps (Fast Ethernet) operation.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation.

-

-
For more information on configuring this device, see
-    ifconfig(8). To view a list of media types and options
-    supported by the card, try ifconfig
-    ⟨device⟩
-    media. For example, ifconfig age0
-    media.

-

-

-

-
arp(4), atphy(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The age device driver first appeared in
-    OpenBSD 4.5. It was then ported to
-    NetBSD 5.1.

-

-

-

-
The age driver was written by
-    Pyun YongHyeon for FreeBSD,
-    ported to OpenBSD by Kevin
-    Lo ⟨kevlo@OpenBSD.org⟩ then ported to
-    NetBSD by Christoph Egger
-    ⟨cegger@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
May 5, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/agp.4 4.html b/static/netbsd/man4/agp.4 4.html
deleted file mode 100644
index 6d8dbc52..00000000
--- a/static/netbsd/man4/agp.4 4.html	
+++ /dev/null
@@ -1,230 +0,0 @@
-
-  
-    
-    
-    
-  
-
AGP(4)Device Drivers ManualAGP(4)

-

-

-

-
agp — accelerated
-    graphics port driver

-

-

-

-
agp* at pchb?

-

-

-

-
The agp driver provides
-    machine-independent support for the accelerated graphics port (AGP) found on
-    many PC-based and PCI systems. The AGP specification was designed by
-  Intel.

-
The AGP chipset is positioned between the PCI-Host bridge and the
-    graphics accelerator to provide a high-performance dedicated graphics bus
-    for moving large amounts of data directly from host memory to the graphics
-    accelerator. The specification currently supports a peak bandwidth of 528
-    MB/s. AGP uses a Graphics Address Remapping Table (GART) to provide a
-    physically-contiguous view of scattered pages in host memory for DMA
-    transfers.

-
The agp driver supports the following
-    chipsets:

-

-
    
-  
  • ALI M1541 host-to-AGP bridge
    • 
-  
  • AMD 751 and 761 host-to-AGP bridges
    • 
-  
  • Intel 82810, 82810-DC100, 82810E, and 82815 SVGA controllers
    • 
-  
  • SiS 5591 host-to-AGP bridge
    • 
-  
  • VIA
    • 
-

-
The agp driver also provides an interface
-    to user processes for use by X servers. A user process communicates to the
-    device initially by means of ioctl(2) calls. The calls
-    supported are:

-

-  

-  
Get AGP information, setting the members in the
-      
-      structure as defined in <sys/agpio.h>:
-    

-    
typedef struct _agp_info {
-        agp_version version;    /* version of the driver        */
-        uint32_t bridge_id;     /* bridge vendor/device         */
-        uint32_t agp_mode;      /* mode info of bridge          */
-        off_t aper_base;        /* base of aperture             */
-        size_t aper_size;       /* size of aperture             */
-        size_t pg_total;        /* max pages (swap + system)    */
-        size_t pg_system;       /* max pages (system)           */
-        size_t pg_used;         /* current pages used           */
-} agp_info;

-    

-  

-  

-  
Acquire AGP.

-  

-  
Release AGP.

-  

-  
Set up AGP, using the members in the
-      
-      structure as defined in <sys/agpio.h>:
-    

-    
typedef struct _agp_setup {
-        uint32_t agp_mode;      /* mode info of bridge          */
-} agp_setup;

-    

-  

-  

-  
Allocate AGP space, using and setting the members in the
-      
-      structure as defined in <sys/agpio.h>:
-    

-    
typedef struct _agp_allocate {
-        int key;                /* tag of allocation            */
-        size_t pg_count;        /* number of pages              */
-        uint32_t type;          /* 0 == normal, other devspec   */
-        uint32_t physical;      /* device specific (some devices
-                                 * need a phys address of the
-                                 * actual page behind the gatt
-                                 * table)                       */
-} agp_allocate;

-    

-  

-  

-  
Deallocate AGP space.

-  

-  
Bind AGP space, using the members in the
-      
-      structure as defined in <sys/agpio.h>:
-    

-    
typedef struct _agp_bind {
-        int key;                /* tag of allocation            */
-        off_t pg_start;         /* starting page to populate    */
-} agp_bind;

-    

-  

-  

-  
Unbind AGP space, using the members in the
-      
-      structure as defined in <sys/agpio.h>:
-    

-    
typedef struct _agp_unbind {
-        int key;                /* tag of allocation            */
-        uint32_t priority;      /* priority for paging out      */
-} agp_unbind;

-    

-  

-

-

-

-

-

-  
/dev/agp?

-  
AGP GART device special files

-  
/dev/agpgart

-  
AGP GART device special file

-

-

-

-

-
This short code fragment is an example of opening the AGP device
-    and performing some basic operations:

-

-
#include <sys/types.h>
-#include <sys/ioctl.h>
-#include <sys/agpio.h>
-#include <fcntl.h>
-#include <err.h>
-
-int
-main(int argc, char **argv)
-{
-	int fd;
-	agp_info info;
-	agp_allocate alloc;
-	agp_setup setup;
-	agp_bind bind;
-	agp_unbind unbind;
-
-	fd = open("/dev/agp0", O_RDWR);
-	if (fd < 0)
-		err(1, "open");
-
-	if (ioctl(fd, AGPIOC_INFO, &info) < 0)
-		err(2, "ioctl AGPIOC_INFO");
-
-	printf("version:	%u.%u\n", info.version.major,
-	    info.version.minor);
-
-	printf("id:		%x\n", info.bridge_id);
-	printf("mode:		%x\n", info.agp_mode);
-	printf("base:		%x\n", info.aper_base);
-	printf("size:		%uM\n", info.aper_size);
-	printf("total mem:	%u\n", info.pg_total);
-	printf("system mem:	%u\n", info.pg_system);
-	printf("used mem:	%u\n\n", info.pg_used);
-
-	setup.agp_mode = info.agp_mode;
-
-	if (ioctl(fd, AGPIOC_SETUP, &setup) < 0)
-		err(3, "ioctl AGPIOC_SETUP");
-
-	if (ioctl(fd, AGPIOC_ACQUIRE, 0) < 0)
-		err(3, "ioctl AGPIOC_ACQUIRE");
-
-	alloc.type = 0;
-	alloc.pg_count = 64;
-
-	if (ioctl(fd, AGPIOC_ALLOCATE, &alloc) < 0)
-		err(4, "ioctl AGPIOC_ALLOCATE");
-
-	printf("alloc key %d, paddr %x\n", alloc.key, alloc.physical);
-	if (ioctl(fd, AGPIOC_INFO, &info) < 0)
-		err(5, "ioctl AGPIOC_INFO");
-
-	bind.key = alloc.key;
-	bind.pg_start = 0x1000;
-
-	if (ioctl(fd, AGPIOC_BIND, &bind) < 0)
-		err(6, "ioctl AGPIOC_BIND");
-
-	printf("used mem now:	%u\n\n", info.pg_used);
-
-	unbind.key = alloc.key;
-	unbind.priority = 0;
-
-	if (ioctl(fd, AGPIOC_UNBIND, &unbind) < 0)
-		err(6, "ioctl AGPIOC_BIND");
-
-	if (ioctl(fd, AGPIOC_DEALLOCATE, &alloc.key) < 0)
-		err(6, "ioctl AGPIOC_DEALLOCATE");
-
-	if (ioctl(fd, AGPIOC_RELEASE, 0) < 0)
-		err(7, "ioctl AGPIOC_RELEASE");
-
-	close(fd);
-
-	printf("agp test successful\n");
-
-	return 0;
-}

-

-

-

-

-
ioctl(2), pci(4)

-

-

-

-
The agp driver first appeared in
-    FreeBSD 4.1. It was adopted in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
October 3, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/agr.4 4.html b/static/netbsd/man4/agr.4 4.html
deleted file mode 100644
index 39156438..00000000
--- a/static/netbsd/man4/agr.4 4.html	
+++ /dev/null
@@ -1,122 +0,0 @@
-
-  
-    
-    
-    
-  
-
AGR(4)Device Drivers ManualAGR(4)

-

-

-

-
agr — link
-    aggregation pseudo network interface driver

-

-

-

-
pseudo-device agr

-

-

-

-

-    

-
lagg(4)
-    

-
The agr driver provides link aggregation
-    functionality (a.k.a. L2 trunking or bonding).

-
It supports the IEEE 802.3ad Link Aggregation Control Protocol
-    (LACP) and the Marker Protocol.

-
The agr driver supports the following link
-    specific flags for ifconfig(8):

-

-  

-  
Use the round-robin distribution algorithm. Don't use it unless you're
-      really sure, because it violates the frame ordering rule.

-  

-  
Use the default distribution algorithm, which is based on the hash of
-      DA/SA, TCI, and, if available, some upper layer protocol information like
-      ip(4) DA/SA.

-  

-  
Disable LACP. Prevents any LACP or Marker messaging which leaves the ports
-      in the default static configuration. Set this prior to adding ports.

-

-

-

-

-
Create an agr interface,
-    agr0, and attach re0 and
-    re1 to it. In other words, aggregate re0
-    and re1 so that they can be used as a single interface,
-    agr0. The physical interfaces which are attached to the
-    agr interface must not have any IP addresses,
-    neither IPv4 nor IPv6.

-

-
	ifconfig re0 inet xxx.xxx.xxx.xxx delete
-	ifconfig re0 inet6 fe80::xxxx:xxxx:xxxx:xxxx delete
-	ifconfig re1 inet xxx.xxx.xxx.xxx delete
-	ifconfig re1 inet6 fe80::xxxx:xxxx:xxxx:xxxx delete
-
-	ifconfig agr0 create
-	ifconfig agr0 agrport re0
-	ifconfig agr0 agrport re1

-

-
Destroy an interface created in the above example.

-

-
	ifconfig agr0 -agrport re0
-	ifconfig agr0 -agrport re1
-	ifconfig agr0 destroy

-

-

-

-

-
lagg(4), ifconfig(8)

-

-

-

-
IEEE 802.3ad Aggregation of Multiple Link Segments

-

-

-

-
The agr driver first appeared in
-    NetBSD 4.0 and was obsoleted in
-    NetBSD 10.0.

-
The agr driver will be removed from
-    NetBSD 11.0.

-

-

-

-
The agr driver was written by
-    YAMAMOTO Takashi.

-

-

-

-
There is no way to configure LACP administrative variables,
-    including system and port priorities. The current implementation of the
-    agr driver always performs active-mode LACP and uses
-    0x8000 as system and port priorities.

-
The agr driver uses the MAC address of the
-    first-added physical interface as the MAC address of the
-    agr interface itself. Thus, removing the physical
-    interface and using it for another purpose can result in non-unique MAC
-    addresses.

-
The current implementation of the agr
-    driver doesn't prevent unsafe operations like some ioctls against underlying
-    physical interfaces. Such operations can result in unexpected behaviors, and
-    are strongly discouraged.

-
There is no way to configure agr
-    interfaces without attaching physical interfaces.

-
Physical interfaces being added to the agr
-    interface shouldn't have any addresses except for link level address.
-    Otherwise, the attempt will fail with EBUSY. Note
-    that it includes an automatically assigned IPv6 link-local address.

-

-

-
-  
-    
-    
-  
-
February 23, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/aha.4 4.html b/static/netbsd/man4/aha.4 4.html
deleted file mode 100644
index 8b245655..00000000
--- a/static/netbsd/man4/aha.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHA(4)Device Drivers ManualAHA(4)

-

-

-

-
aha — Adaptec 154x
-    SCSI adapter driver

-

-

-

-
aha0 at isa? port 0x330 irq ? drq ?
-  

-  aha* at isapnp?
-  

-  aha* at mca? slot ?
-  

-  scsibus* at aha?

-

-

-

-
The aha driver provides support for the
-    following SCSI adapters:

-

-

-

-  
Adaptec AHA-154xA

-  
 

-  
Adaptec AHA-154xB

-  
 

-  
Adaptec AHA-154xC

-  
 

-  
Adaptec AHA-154xCF

-  
 

-  
Buslogic BT-54x

-  
 

-  
Adaptec AHA-1640 (MCA)

-  
 

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), mca(4),
-    scsi(4), sd(4),
-  st(4)

-

-

-
-  
-    
-    
-  
-
November 29, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/ahb.4 4.html b/static/netbsd/man4/ahb.4 4.html
deleted file mode 100644
index 36146056..00000000
--- a/static/netbsd/man4/ahb.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHB(4)Device Drivers ManualAHB(4)

-

-

-

-
ahb — Adaptec 1742
-    SCSI adapter driver

-

-

-

-
ahb0 at eisa? slot ? irq ?
-  

-  scsibus* at ahb?

-

-

-

-
The ahb driver implements support for the
-    following card:

-

-

-

-  
Adaptec

-  
AHA-1742 EISA SCSI adaptor

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-
-  
-    
-    
-  
-
November 29, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/ahc.4 3.html b/static/netbsd/man4/ahc.4 3.html
deleted file mode 100644
index cd7867ce..00000000
--- a/static/netbsd/man4/ahc.4 3.html	
+++ /dev/null
@@ -1,347 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHC(4)Device Drivers ManualAHC(4)

-

-

-

-
ahc — Adaptec
-    VL/EISA/PCI/CardBus SCSI host adapter driver

-

-

-

-
For VL cards:
-  

-  ahc0 at isa? port ? irq ?

-
For EISA cards:
-  

-  ahc* at eisa? slot ?

-
For PCI cards:
-  

-  ahc* at pci? dev ? function ?

-
For CardBus cards:
-  

-  ahc* at cardbus? function ?

-
To allow PCI adapters to use memory mapped I/O if enabled:
-  

-  options AHC_ALLOW_MEMIO

-
Disable tagged queuing (avoids hangs on some hardware under load)
-  

-  options AHC_NO_TAGS

-
Change the default SCSI id for cards without a SEEPROM (default
-    7):
-  

-  options AHC_CARDBUS_DEFAULT_SCSI_ID=integer

-
For SCSI buses:
-  

-  scsibus* at ahc?

-

-

-

-
The ahc device driver supports SCSI
-    controllers based on Adaptec AIC77xx and AIC78xx SCSI host adapter chips
-    found on many motherboards as well as Adaptec SCSI controller cards.

-
Driver features include support for twin and wide buses, fast,
-    ultra or ultra2 synchronous transfers depending on controller type, tagged
-    queuing and SCB paging.

-
Memory mapped I/O can be enabled for PCI devices with the
-    “AHC_ALLOW_MEMIO” configuration
-    option. Memory mapped I/O is more efficient than the alternative, programmed
-    I/O. Most PCI BIOSes will map devices so that either technique for
-    communicating with the card is available. In some cases, usually when the
-    PCI device is sitting behind a PCI->PCI bridge, the BIOS may fail to
-    properly initialize the chip for memory mapped I/O. The typical symptom of
-    this problem is a system hang if memory mapped I/O is attempted. Most modern
-    motherboards perform the initialization correctly and work fine with this
-    option enabled.

-
Per target configuration performed in the SCSI-Select menu,
-    accessible at boot in non-EISA models, or through an EISA configuration
-    utility for EISA models, is honored by this driver. This includes
-    synchronous/asynchronous transfers, maximum synchronous negotiation rate,
-    wide transfers, disconnection, the host adapter's SCSI ID, and, in the case
-    of EISA Twin Channel controllers, the primary channel selection. For systems
-    that store non-volatile settings in a system specific manner rather than a
-    serial EEPROM directly connected to the aic7xxx controller, the BIOS must be
-    enabled for the driver to access this information. This restriction applies
-    to all EISA and many motherboard configurations.

-
Note that I/O addresses are determined automatically by the probe
-    routines, but care should be taken when using a 284x (VESA
-    local bus controller) in an EISA system. The jumpers
-    setting the I/O area for the 284x should match the EISA slot into which the
-    card is inserted to prevent conflicts with other EISA cards.

-
Performance and feature sets vary throughout the aic7xxx product
-    line. The following table provides a comparison of the different chips
-    supported by the ahc driver. Note that wide and twin
-    channel features, although always supported by a particular chip, may be
-    disabled in a particular motherboard or card design.

-
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-
aic777010EISA/VL10MHz16Bit41
aic785010PCI/3210MHz8Bit3
aic786010PCI/3220MHz8Bit3
aic787010PCI/3210MHz16Bit16
aic788010PCI/3220MHz16Bit16
aic789020PCI/3240MHz16Bit163 4 5 6 7 8
aic789120PCI/6440MHz16Bit163 4 5 6 7 8
aic789220PCI/6480MHz16Bit163 4 5 6 7 8
aic789515PCI/3220MHz16Bit162 3 4 5
aic7895C15PCI/3220MHz16Bit162 3 4 5 8
aic789620PCI/3240MHz16Bit162 3 4 5 6 7 8
aic789720PCI/6440MHz16Bit162 3 4 5 6 7 8
aic789920PCI/6480MHz16Bit162 3 4 5 6 7 8

-
    
-  
  1. Multiplexed Twin Channel Device - One controller servicing two buses.
    2. 
-  
  2. Multi-function Twin Channel Device - Two controllers on one chip.
    3. 
-  
  3. Command Channel Secondary DMA Engine - Allows scatter gather list and SCB
-      prefetch.
    4. 
-  
  4. 64 Byte SCB Support - SCSI CDB is embedded in the SCB to eliminate an
-      extra DMA.
    5. 
-  
  5. Block Move Instruction Support - Doubles the speed of certain sequencer
-      operations.
    6. 
-  
  6. ‘Bayonet’ style Scatter Gather Engine - Improves S/G
-      prefetch performance.
    7. 
-  
  7. Queuing Registers - Allows queuing of new transactions without pausing the
-      sequencer.
    8. 
-  
  8. Multiple Target IDs - Allows the controller to respond to selection as a
-      target on multiple SCSI IDs.
    9. 
-

-

-

-

-
Supported SCSI controllers include:

-
    
-  
  • Adaptec AHA-2742W EISA Fast Wide SCSI adapter
    • 
-  
  • Adaptec AHA-274xAT EISA dual channel Fast SCSI adapter
    • 
-  
  • Adaptec AHA-284x VL Fast SCSI adapter
    • 
-  
  • Adaptec AHA-2910 PCI Fast SCSI adapter (no SCSI BIOS)
    • 
-  
  • Adaptec AHA-2915 PCI Fast SCSI adapter (no SCSI BIOS)
    • 
-  
  • Adaptec AHA-2920C PCI Fast SCSI adapter
-    
      
-      
    • Note: Adaptec AHA-2920/A which use the Future Domain's chips are not
-          supported by this driver.
      • 
-    
    
-  
    • 
-  
  • Adaptec AHA-2930C PCI Ultra SCSI adapter
    • 
-  
  • Adaptec AHA-2930U2 PCI Ultra2 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-2940 PCI Fast SCSI adapter
    • 
-  
  • Adaptec AHA-2940U PCI Ultra SCSI adapter
    • 
-  
  • Adaptec AHA-2940AU PCI Ultra SCSI adapter
    • 
-  
  • Adaptec AHA-2940UW PCI Ultra Wide SCSI adapter
    • 
-  
  • Adaptec AHA-2940UW Dual PCI dual channel Ultra Wide SCSI adapter
    • 
-  
  • Adaptec AHA-2940UW Pro PCI Ultra Wide SCSI adapter
    • 
-  
  • Adaptec AHA-2940U2W PCI Ultra2 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-2940U2B PCI Ultra2 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-2944W PCI Fast Wide Differential SCSI adapter
    • 
-  
  • Adaptec AHA-2944UW PCI Ultra Wide Differential SCSI adapter
    • 
-  
  • Adaptec AHA-2950U2W
    • 
-  
  • Adaptec AHA-2950U2B 64bit PCI Ultra2 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-19160B PCI Ultra160 Wide LVD SCSI adapter
    • 
-  
  • Adaptec ASC-29160 PCI Ultra160 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-29160N PCI Ultra160 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-29160B 64bit PCI Ultra160 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-3940 PCI dual channel Fast SCSI adapter
    • 
-  
  • Adaptec AHA-3940U PCI dual channel Ultra SCSI adapter
    • 
-  
  • Adaptec AHA-3940AU PCI dual channel Ultra SCSI adapter
    • 
-  
  • Adaptec AHA-3940UW PCI dual channel Ultra Wide SCSI adapter
    • 
-  
  • Adaptec AHA-3940AUW PCI dual channel Ultra Wide SCSI adapter
    • 
-  
  • Adaptec AHA-3940U2W PCI dual channel Ultra2 Wide LVD SCSI adapter
    • 
-  
  • Adaptec AHA-3950U2 64bit PCI dual channel Ultra2 Wide LVD SCSI
-    adapter
    • 
-  
  • Adaptec AHA-3960 64bit PCI dual channel Ultra160 Wide LVD SCSI
-    adapter
    • 
-  
  • Adaptec AHA-3985 PCI dual channel Fast SCSI RAID adapter
    • 
-  
  • Adaptec AHA-39160 64bit PCI dual channel Ultra160 Wide LVD SCSI
-    adapter
    • 
-  
  • Adaptec AHA-4944UW PCI quad channel PCI Ultra Wide Differential SCSI
-      adapter
    • 
-  
  • Other SCSI controllers based on the Adaptec AIC7770, AIC7850, AIC7860,
-      AIC7870, AIC7880, AIC7890, AIC7891, AIC7892, AIC7895, AIC7896, AIC7897 and
-      AIC7899 SCSI host adapter chips.
    • 
-

-

-

-

-
Every transaction sent to a device on the SCSI bus is assigned a
-    ‘SCSI Control Block’ (SCB). The SCB contains all of the
-    information required by the controller to process a transaction. The chip
-    feature table lists the number of SCBs that can be stored in on-chip memory.
-    All chips with model numbers greater than or equal to 7870 allow for the on
-    chip SCB space to be augmented with external SRAM up to a maximum of 255
-    SCBs. Very few Adaptec controller configurations have external SRAM.

-
If external SRAM is not available, SCBs are a limited
-    resource. Using the SCBs in a straight forward manner would only allow the
-    driver to handle as many concurrent transactions as there are physical SCBs.
-    To fully use the SCSI bus and the devices on it, requires much more
-    concurrency. The solution to this problem is
-    , a concept
-    similar to memory paging. SCB paging takes advantage of the fact that
-    devices usually disconnect from the SCSI bus for long periods of time
-    without talking to the controller. The SCBs for disconnected transactions
-    are only of use to the controller when the transfer is resumed. When the
-    host queues another transaction for the controller to execute, the
-    controller firmware will use a free SCB if one is available. Otherwise, the
-    state of the most recently disconnected (and therefore most likely to stay
-    disconnected) SCB is saved, via DMA, to host memory, and the local SCB
-    reused to start the new transaction. This allows the controller to queue up
-    to 255 transactions regardless of the amount of SCB space. Since the local
-    SCB space serves as a cache for disconnected transactions, the more SCB
-    space available, the less host bus traffic consumed saving and restoring SCB
-    data.

-

-

-

-
aha(4), ahb(4),
-    ahd(4), cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-

-
The ahc driver appeared in
-    FreeBSD 2.0 and NetBSD
-  1.1.

-

-

-

-
The ahc driver, the AIC7xxx sequencer-code
-    assembler, and the firmware running on the aic7xxx chips was written by
-    Justin T. Gibbs. NetBSD
-    porting is done by Stefan Grefen, Charles M. Hannum, Michael Graff, Jason R.
-    Thorpe, Pete Bentley, Frank van der Linden and Noriyuki Soda.

-

-

-

-
Some Quantum drives (at least the Empire 2100 and 1080s) will not
-    run on an AIC7870 Rev B in synchronous mode at 10MHz. Controllers with this
-    problem have a 42 MHz clock crystal on them and run slightly above 10MHz.
-    This confuses the drive and hangs the bus. Setting a maximum synchronous
-    negotiation rate of 8MHz in the SCSI-Select utility will allow normal
-    operation.

-
Target mode is not supported on NetBSD
-    version of this driver.

-

-

-
-  
-    
-    
-  
-
July 16, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/ahcisata.4 4.html b/static/netbsd/man4/ahcisata.4 4.html
deleted file mode 100644
index c94ed56c..00000000
--- a/static/netbsd/man4/ahcisata.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHCISATA(4)Device Drivers ManualAHCISATA(4)

-

-

-

-
ahcisata — AHCI
-    1.0 and 1.1 compliant SATA controllers driver

-

-

-

-
ahcisata* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The ahcisata driver supports SATA
-    controllers compliant with the Serial ATA Advanced Host Controller Interface
-    Revision 1.0 or 1.1 specification, and provides the interface to the
-    hardware for the ata(4) driver.

-
The ahcisata driver will only attach if
-    the controller has been put in AHCI mode by the BIOS; if the controller is
-    in pciide-compatible mode, it will be handled by the appropriate driver
-    (piixide(4) for Intel AHCI controllers).

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-
Intel Corporation,
-    Serial ATA Advanced Host Controller Interface
-    (AHCI), Revision 1.3,
-    http://download.intel.com/technology/serialata/pdf/rev1_3.pdf,
-    June 26, 2008.

-

-

-

-
NCQ support was added in NetBSD on October
-    7, 2017 by Jaromir Dolecek
-    <jdolecek@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 7, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/ahd.4 3.html b/static/netbsd/man4/ahd.4 3.html
deleted file mode 100644
index 30cd610b..00000000
--- a/static/netbsd/man4/ahd.4 3.html	
+++ /dev/null
@@ -1,149 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHD(4)Device Drivers ManualAHD(4)

-

-

-

-
ahd — Adaptec
-    PCI/PCI-X Ultra320 SCSI host adapter driver

-

-

-

-
For one or more PCI/PCI-X cards:
-  

-  ahd* at pci? dev ? function ?

-
To compile in debugging code:

-
options AHD_DEBUG
-

-options AHD_DEBUG_OPTS=<bitmask of options>
-

-options AHD_REG_PRETTY_PRINT

-
For SCSI busses:
-  

-  scsibus* at ahd?

-

-

-

-
This driver provides access to the SCSI bus(ses) connected to
-    Adaptec AIC79xx host adapter chips.

-
Driver features include support for narrow and wide busses, fast,
-    ultra, ultra2, ultra160, and ultra320 synchronous transfers, packetized
-    transfers, tagged queueing, and 512 SCBs.

-
The AHD_DEBUG_OPTS option is used to
-    control which diagnostic messages are printed to the console when
-    AHD_DEBUG is enabled. Logically OR the following
-    bits together:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
0x0001Show miscellaneous information
0x0002Show sense data
0x0004Show Serial EEPROM contents
0x0008Show bus termination settings
0x0010Show host memory usage
0x0020Show SCSI protocol messages
0x0040Show mode pointer of the chip register window
0x0080Show selection timeouts
0x0100Show FIFO usage messages
0x0200Show Queue Full status
0x0400Show SCB queue status
0x0800Show inbound packet information
0x1000Show S/G list information
0x2000Enable extra diagnostic code in the firmware

-
The AHD_REG_PRETTY_PRINT option compiles
-    in support for human-readable bit definitions for each register that is
-    printed by the debugging code. However, it also bloats the compiled size of
-    the driver by approximately 215KB.

-

-

-

-
The ahd driver supports the following:

-

-
    
-  
  • Adaptec AIC7901 host adapter chip
    • 
-  
  • Adaptec AIC7901A host adapter chip
    • 
-  
  • Adaptec AIC7902 host adapter chip
    • 
-  
  • Adaptec 29320 host adapter
    • 
-  
  • Adaptec 39320 host adapter
    • 
-  
  • Many motherboards with on-board SCSI support
    • 
-

-

-

-

-
ahc(4), cd(4),
-    ch(4), intro(4),
-    scsi(4), sd(4),
-    ses(4), st(4)

-

-

-

-
The ahd driver first appeared in
-    FreeBSD 4.7 and NetBSD
-  2.0.

-

-

-

-
The ahd driver, the AIC7xxx sequencer-code
-    assembler, and the firmware running on the aic79xx chips was written by
-    Justin T. Gibbs. NetBSD
-    porting is done by Pascal Renauld, Frank van der Linden, Jason Thorpe, and
-    Allen Briggs. This manual page is based on the ahc(4)
-    manual page.

-

-

-
-  
-    
-    
-  
-
May 16, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/aht20temp.4 4.html b/static/netbsd/man4/aht20temp.4 4.html
deleted file mode 100644
index 309c1092..00000000
--- a/static/netbsd/man4/aht20temp.4 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHT20TEMP(4)Device Drivers ManualAHT20TEMP(4)

-

-

-

-
aht20temp — Driver
-    for Guangzhou Aosong AHT20 sensor chip via I2C bus

-

-

-

-
aht20temp* at iic? addr 0x38

-

-

-

-
The aht20temp driver provides measurements
-    from the AHT20 humidity/temperature sensors via the
-    envsys(4) framework. The aht20temp
-    addr argument selects the address at the
-    iic(4) bus. The crc validity can be changed through
-    sysctl(8) nodes.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
If set, the crc calculation for %RH and temperature will be ignored.

-  

-  
If the driver is compiled with AHT20_DEBUG, this
-      node will appear and can be used to set the debugging level.

-  

-  
To read %RH or temperature the chip requires that the command be sent,
-      then a delay must be observed before a read can be done to get the values
-      back. The delays are documented in the datasheet for the chip. The driver
-      will attempt to read back the values readattempts number of times. The
-      default is 10 which should be more than enough for most purposes.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The aht20temp driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The aht20temp driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
November 15, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/ai.4 4.html b/static/netbsd/man4/ai.4 4.html
deleted file mode 100644
index db36d815..00000000
--- a/static/netbsd/man4/ai.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
AI(4)Device Drivers ManualAI(4)

-

-

-

-
ai — AT&T
-    StarLAN Ethernet interface driver

-

-

-

-
ai0 at isa? port 0x360 iomem 0xd0000 irq
-  7

-

-

-

-
The ai driver supports the following ISA
-    bus NICs:

-

-

-

-  
AT&T StarLAN 10

-  
 

-  
AT&T StarLAN Fiber

-  
 

-

-

-
These cards are based on the Intel 82586 Ethernet controller
-  chip.

-

-

-

-
ef(4), elmc(4),
-    ifmedia(4), intro(4),
-    isa(4), ix(4),
-    ifconfig(8)

-

-

-

-
Rafal K. Boni

-

-

-
-  
-    
-    
-  
-
June 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/aibs.4 3.html b/static/netbsd/man4/aibs.4 3.html
deleted file mode 100644
index be7783b4..00000000
--- a/static/netbsd/man4/aibs.4 3.html	
+++ /dev/null
@@ -1,143 +0,0 @@
-
-  
-    
-    
-    
-  
-
AIBS(4)Device Drivers ManualAIBS(4)

-

-

-

-
aibs — ASUSTeK AI
-    Booster voltage, temperature, and fan sensor

-

-

-

-
aibs* at acpi?

-

-

-

-
The aibs driver provides support for
-    voltage, temperature, and fan sensors available as an ACPI device on ASUSTeK
-    motherboards. The number of sensors of each type, as well as the description
-    of each sensor, varies according to the motherboard.

-
The driver supports an arbitrary set of sensors, provides
-    descriptions regarding what each sensor is used for, and reports whether
-    each sensor is within the specifications as defined by the motherboard
-    manufacturer through ACPI.

-
The aibs driver supports
-    envsys(4) sensor states as follows:

-
    
-  
  • Voltage sensors can have a state of ‘valid’,
-      ‘critunder’, or ‘critover’; temperature
-      sensors can have a state of ‘valid’,
-      ‘warnover’, ‘critover’, or
-      ‘invalid’; and fan sensors can have a state of
-      ‘valid’, ‘warnunder’, or
-      ‘warnover’.
    • 
-  
  • Temperature sensors that have a reading of 0 are marked
-      ‘invalid’, whereas all other sensors are always assumed
-      valid.
    • 
-  
  • Voltage sensors have a lower and an upper limit, ‘critunder’
-      and ‘critover’, temperature sensors have two upper limits,
-      ‘warnover’ and ‘critover’, whereas fan sensors
-      may either have only the lower limit ‘warnunder’, or,
-      depending on the vendor's ACPI implementation, one lower and one upper
-      limit, ‘warnunder’ and ‘warnover’.
    • 
-

-
Sensor values and limits are made available through the
-    envsys(4) interface, and can be monitored with
-    envstat(8). For example, on an ASUS V3-P5G965
-  barebone:

-

-
$ envstat -d aibs0
-                     Current  CritMax  WarnMax  WarnMin  CritMin Unit
-    Vcore Voltage:     1.152    1.600                      0.850    V
-     +3.3 Voltage:     3.312    3.630                      2.970    V
-       +5 Voltage:     5.017    5.500                      4.500    V
-      +12 Voltage:    12.302   13.800                     10.200    V
-  CPU Temperature:    27.000   95.000   80.000                   degC
-   MB Temperature:    58.000   95.000   60.000                   degC
-    CPU FAN Speed:       878              7200      600           RPM
-CHASSIS FAN Speed:         0              7200      700           RPM

-

-
Generally, sensors provided by the aibs
-    driver may also be supported by a variety of other drivers, such as
-    lm(4) or itesio(4). The precise
-    collection of aibs sensors is comprised of the
-    sensors specifically utilised in the motherboard design, which may be
-    supported through a combination of one or more physical hardware monitoring
-    chips.

-
The aibs driver, however, provides the
-    following advantages when compared to the native hardware monitoring
-    drivers:

-
    
-  
  • Sensor values from aibs are expected to be more
-      reliable. For example, voltage sensors in many hardware monitoring chips
-      can only sense voltage from 0 to 2 or 4 volts, and the excessive voltage
-      is removed by the resistors, which may vary with the motherboard and with
-      the voltage that is being sensed. In aibs, the
-      required resistor factors are provided by the motherboard manufacturer
-      through ACPI; in the native drivers, the resistor factors are encoded into
-      the driver based on the chip manufacturer's recommendations. In essence,
-      sensor values from aibs are very likely to be
-      identical to the readings from the Hardware Monitor screen in the
-    BIOS.
    • 
-  
  • Sensor descriptions from aibs are more likely to
-      match the markings on the motherboard.
    • 
-  
  • Sensor states are supported by aibs. The state is
-      reported based on the acceptable range of values for each individual
-      sensor as suggested by the motherboard manufacturer. For example, the
-      threshold for the CPU temperature sensor is likely to be significantly
-      higher than that for the chassis temperature sensor.
    • 
-  
  • Support for newer chips in aibs. Newer chips may
-      miss a native driver, but should be supported through
-      aibs regardless.
    • 
-

-
As a result, sensor readings from the actual native hardware
-    monitoring drivers are redundant when aibs is
-    present, and may be ignored as appropriate. Whereas on some supported
-    operating systems the native drivers may have to be specifically disabled
-    should their presence be judged unnecessary, on others the drivers like
-    lm(4) are not probed provided that
-    acpi(4) is configured and the system potentially supports
-    the hardware monitoring chip through ACPI.

-

-

-

-
acpi(4), envsys(4),
-    envstat(8)

-

-

-

-
The aibs driver first appeared in
-    OpenBSD 4.7, DragonFly 2.4.1
-    and NetBSD 6.0. An earlier version of the driver,
-    named aiboost, first appeared in
-    FreeBSD 7.0 and NetBSD
-  5.0.

-

-

-

-
The aibs driver was written for
-    OpenBSD, DragonFly BSD, and
-    NetBSD by Constantine A.
-    Murenin
-    ⟨http://cnst.su/⟩,
-    Raouf Boutaba Research Group, David R. Cheriton School of Computer Science,
-    University of Waterloo. Jukka Ruohonen
-    ⟨jruohonen@iki.fi⟩ later reworked and adjusted the driver to
-    support new ASUSTeK motherboards. The earlier version of the driver,
-    aiboost, was written for
-    FreeBSD by Takanori Watanabe
-    and adapted to NetBSD by Juan
-    Romero Pardines.

-

-

-
-  
-    
-    
-  
-
June 8, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/aic.4 4.html b/static/netbsd/man4/aic.4 4.html
deleted file mode 100644
index e73fe41e..00000000
--- a/static/netbsd/man4/aic.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
AIC(4)Device Drivers ManualAIC(4)

-

-

-

-
aic — Adaptec
-    AIC-6260 and AIC-6360 SCSI driver

-

-

-

-
aic0 at isa? port 0x340 irq 12
-  

-  aic* at isapnp?
-  

-  aic* at pcmcia? function ?
-  

-  scsibus* at aic?

-

-

-

-
The aic driver provides support for the
-    Adaptec AIC-6260 and AIC-6360 SCSI controller chips.

-
The PCMCIA SCSI host adapters and many ISA cards do not include
-    boot ROMs and therefore cannot be used to connect the boot device.

-

-

-

-
Cards supported by the aic driver
-  include:

-
    
-  
  • Adaptec 1502 ISA SCSI host adaptor
    • 
-  
  • Adaptec 152x ISA SCSI host adaptor
    • 
-  
  • Adaptec AHA-1520B ISAPNP SCSI host adaptor
    • 
-  
  • Adaptec APA-1460 PCMCIA SCSI host adaptor
    • 
-  
  • Creative Labs SoundBlaster ISA SCSI host adaptor, and compatibles
    • 
-

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-
-  
-    
-    
-  
-
November 10, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/akbd.4 4.html b/static/netbsd/man4/akbd.4 4.html
deleted file mode 100644
index 7934bb7a..00000000
--- a/static/netbsd/man4/akbd.4 4.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
AKBD(4)Device Drivers ManualAKBD(4)

-

-

-

-
akbd — Apple
-    Desktop Bus keyboard driver for wscons

-

-

-

-
akbd* at obio?
-  

-  wskbd* at akbd? console ?

-

-  

-  options ALTXBUTTONS
-  

-  options CAPS_IS_CONTROL
-  

-  options FORCE_FUNCTION_KEYS

-

-

-

-
This driver provides the wscons(4) driver with
-    support for Apple Desktop Bus keyboards.

-

-  
options ALTXBUTTONS

-  
To map ⟨Option⟩+⟨1⟩,
-      ⟨Option⟩+⟨2⟩,
-      ⟨Option⟩+⟨3⟩, to mouse buttons 1, 2, and 3
-      respectively.

-  
options CAPS_IS_CONTROL

-  
On macppc systems it is possible to tweak the keyboard driver to treat the
-      caps lock key on an ADB keyboard as a control key. This requires special
-      remapping because of ADB's strange emulation of a mechanically-locked
-    key.

-  
options FORCE_FUNCTION_KEYS

-  
On macppc PowerBooks, several function keys double as “hot
-      keys” (brightness, volume, eject) when the ⟨Fn⟩
-      modifier is held down. Mac OS X likes to reprogram the keyboard
-      controller to send hot key events when ⟨Fn⟩ is
-       held down and
-      send function key events when it is. With this option you can transform
-      the non-keyboard “button” events back into function key
-      events.

-

-

-

-
To work around the limited number of buttons found on most ADB
-    mice, the following key sequences trigger mouse button events:

-

-
    
-  
  • ⟨Option⟩+⟨LeftArrow⟩ will work as the middle
-      mouse button.
    • 
-  
  • ⟨Option⟩+⟨RightArrow⟩ will work as the right
-      mouse button.
    • 
-

-
On PowerBook (mac68k) models the following key sequences are also
-    significant:

-

-
    
-  
  • ⟨Option⟩+⟨UpArrow⟩ increase screen
-    brightness.
    • 
-  
  • ⟨Option⟩+⟨DownArrow⟩ decrease screen
-      brightness.
    • 
-

-

-

-

-
NetBSD is known to support the following
-    ADB keyboards:

-

-
    
-  
  • On-board keyboards on PowerBook models
    • 
-  
  • Apple Standard Keyboard
    • 
-  
  • Apple Keyboard II
    • 
-  
  • Apple Extended Keyboard
    • 
-  
  • Apple Extended Keyboard II
    • 
-  
  • Apple Adjustable Keyboard
    • 
-  
  • Most third-party ADB keyboards are supported
    • 
-

-

-

-

-

-
xmodmap(1), adb(4),
-    wscons(4), wskbd(4),
-    wsconsctl(8)

-

-

-

-
The number pad on extended keyboards does not send out the proper
-    key codes for many applications.

-
The LEDs on extended keyboards are not functional under
-    NetBSD.

-
In X11 with the default key mapping, middle and right mouse button
-    events will hold ‘Meta_L’ and this
-    will clobber the intended mouse button. ⟨Option⟩ should be
-    remapped with xmodmap(1) to the ⟨Command⟩
-    key:

-

-
remove Mod4 = Super_L
-remove Mod1 = Alt_L
-add Mod1 = Super_L

-

-

-

-
-  
-    
-    
-  
-
January 20, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/alc.4 3.html b/static/netbsd/man4/alc.4 3.html
deleted file mode 100644
index 89d6e2ac..00000000
--- a/static/netbsd/man4/alc.4 3.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALC(4)Device Drivers ManualALC(4)

-

-

-

-
alc — Atheros
-    AR813x/AR815x/AR816x/AR817x Killer E2200/2400/2500 Ethernet
-  device

-

-

-

-
alc* at pci?
-  

-  atphy* at mii?

-

-

-

-
The alc driver provides support for
-    Ethernet interfaces based on the Atheros AR813x/AR815x/AR816x/AR817x
-    Gigabit/Fast Ethernet chipsets and Killer E2200/2400/2500 Ethernet
-  chipsets.

-
The following media types are supported:

-

-

-  

-  
Enable autoselection of the media type and options.

-  

-  
Set 10Mbps operation.

-  

-  
Set 100Mbps (Fast Ethernet) operation.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
arp(4), atphy(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The alc device driver was written by
-    Pyun YongHyeon and first appeared in
-    FreeBSD 8.0. It was ported to
-    OpenBSD 4.7 by Kevin Lo and
-    then ported to NetBSD 6.0 by Fire
-    Crow. Leonardo Taccari ported the
-    AR816x/AR817x support for alc from
-    FreeBSD 11.0.

-

-

-
-  
-    
-    
-  
-
October 16, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/ale.4 4.html b/static/netbsd/man4/ale.4 4.html
deleted file mode 100644
index c41f108e..00000000
--- a/static/netbsd/man4/ale.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALE(4)Device Drivers ManualALE(4)

-

-

-

-
ale — Atheros
-    AR8121/AR8113/AR8114 10/100/Gigabit Ethernet device

-

-

-

-
ale* at pci?
-  

-  atphy* at mii?

-

-

-

-
The ale driver provides support for
-    Ethernet interfaces based on the Atheros AR8121/AR8113/AR8114 Ethernet
-    chipset, also known as the Attansic L1E.

-
The ale driver supports IPv4 receive
-    IP/TCP/UDP checksum offload and VLAN tag insertion and stripping.

-
The following media types are supported:

-

-

-  

-  
Enable autoselection of the media type and options.

-  

-  
Set 10Mbps operation.

-  

-  
Set 100Mbps (Fast Ethernet) operation.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation.

-

-
For more information on configuring this device, see
-    ifconfig(8). To view a list of media types and options
-    supported by the card, try ifconfig
-    -m ⟨device⟩.
-    For example, ifconfig -m
-    ale0.

-

-

-

-
arp(4), atphy(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The ale device driver first appeared in
-    OpenBSD 4.5. It was then ported to
-    NetBSD 5.1.

-

-

-

-
The ale driver was written by
-    Pyun YongHyeon for FreeBSD
-    and ported to OpenBSD by Kevin
-    Lo ⟨kevlo@OpenBSD.org⟩ then ported to
-    NetBSD by Christoph Egger
-    ⟨cegger@NetBSD.org⟩ and Kevin Lahey.

-

-

-
-  
-    
-    
-  
-
May 5, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/alipm.4 4.html b/static/netbsd/man4/alipm.4 4.html
deleted file mode 100644
index 3d409adc..00000000
--- a/static/netbsd/man4/alipm.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALIPM(4)Device Drivers ManualALIPM(4)

-

-

-

-
alipm — Acer Labs
-    M7101 SMBus controller

-

-

-

-
alipm* at pci?
-  

-  iic* at alipm?

-

-

-

-
The alipm driver provides support for the
-    Acer Labs M7101 Power Management controller. Only the SMBus host interface
-    is supported and can be used with the iic(4)
-  framework.

-

-

-

-
iic(4), intro(4),
-    pci(4)

-

-

-

-
The alipm driver first appeared in
-    OpenBSD 3.9.

-

-

-

-
The alipm driver was written by
-    Mark Kettenis
-    <kettenis@openbsd.org>.

-

-

-

-
The driver doesn't support commands with a data buffer size of
-    more than 2 bytes.

-

-

-
-  
-    
-    
-  
-
October 29, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/altmem.4 4.html b/static/netbsd/man4/altmem.4 4.html
deleted file mode 100644
index 9f884399..00000000
--- a/static/netbsd/man4/altmem.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALTMEM(4)Device Drivers ManualALTMEM(4)

-

-

-

-
altmem —
-    Alternative memory disk driver

-

-

-

-
altmem* at altmemdev?

-

-

-

-
The altmem driver enables use of physical
-    memory that is normally inaccessible by the machine-dependent
-    pmap(9) as a swap device.

-
When an alternative memory disk device is present, this device is
-    generally preferred to hard disk-based swap space. See the
-    swapctl(8) and fstab(5) man pages for
-    instructions on how to assign priorities to swap devices.

-

-

-

-

-  
/dev/altmem??

-  
block mode alternative memory disk devices.

-  
/dev/raltmem??

-  
raw mode alternative memory disk devices.

-

-

-

-

-
md(4), fstab(5),
-    swapctl(8)

-

-

-

-
The altmem device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
March 11, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/altq.4 4.html b/static/netbsd/man4/altq.4 4.html
deleted file mode 100644
index 3b6cf37c..00000000
--- a/static/netbsd/man4/altq.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALTQ(4)Device Drivers ManualALTQ(4)

-

-

-

-
altq — alternate
-    queuing framework

-

-

-

-
options ALTQ
-  

-  options ALTQ_BLUE
-  

-  options ALTQ_CBQ
-  

-  options ALTQ_CDNR
-  

-  options ALTQ_FIFOQ
-  

-  options ALTQ_FLOWVALVE
-  

-  options ALTQ_HFSC
-  

-  options ALTQ_LOCALQ
-  

-  options ALTQ_PRIQ
-  

-  options ALTQ_RED
-  

-  options ALTQ_RIO
-  

-  options ALTQ_WFQ

-

-

-

-
The altq system is a framework which
-    provides several disciplines for queuing outgoing network packets. While
-    traffic shaping is perhaps the most prominent example,
-    altq provides also other measures related to QoS.
-    The framework has been integrated to the pf(4) packet
-    filter since NetBSD 4.0.

-
At the implementation level altq modifies
-    the interface packet queues. Therefore the driver modifications described in
-    altq(9) are required in order to use a certain network
-    card with altq.

-

-

-

-

-
/dev/altq

-

-

-

-

-
pf(4), altq.conf(5),
-    altqd(8), altq(9)

-
Kenjiro Cho,
-    Fitting theory into reality in the ALTQ case,
-    https://www.iijlab.net/~kjc/papers/fittingtheory.pdf,
-    Taipei, Taiwan, March,
-    2004, Asia BSD conference.

-

-

-

-
The altq system first appeared in March
-    1997 and found its home in the KAME project
-    (https://www.kame.net). It was
-    imported into NetBSD 1.6.

-

-

-

-
Please note that you must compile pf(4) in the
-    kernel, using the PF module(7) alongside
-    altq built in the kernel will not work.

-

-

-
-  
-    
-    
-  
-
March 7, 2026NetBSD 10.1

diff --git a/static/netbsd/man4/am2315temp.4 4.html b/static/netbsd/man4/am2315temp.4 4.html
deleted file mode 100644
index 21e2e0d6..00000000
--- a/static/netbsd/man4/am2315temp.4 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
AM2315TEMP(4)Device Drivers ManualAM2315TEMP(4)

-

-

-

-
am2315temp —
-    Driver for Aosong AM2315 sensor chip via I2C bus

-

-

-

-
am2315temp* at iic? addr 0x5c

-

-

-

-
The am2315temp driver provides
-    measurements from the AM2315 humidity/temperature sensors via the
-    envsys(4) framework. The
-    am2315temp addr argument
-    selects the address at the iic(4) bus. The AM2315 has
-    limits on how often the measurements can be read. Adjustments to the number
-    of times to take reading before considering it valid, and the number of
-    ticks to wait between readings can be changed through
-    sysctl(8) nodes.

-
There are other oddities about the AM2315 that should be
-    mentioned. The datasheet says that the device should read no more often then
-    every 2 seconds, further, it also implies that a measurement is not
-    performed until the device is 1) awake 2) has been asked for a measurement.
-    From observation, it has been noted that it is possible to ask for
-    measurements more often than every 2 seconds, and actually get something
-    that looks to be valid. It may, in fact, be valid, but it has also been
-    noted that the measurements do not appear to change. This implies that a
-    measurement was done, and then returned time and time again. It has also
-    been noticed that if measurements are taken very close to every 2 seconds,
-    that sometimes the device will return a I2C error on a read. If this happens
-    a lot, increase hw.am2315temp0.readticks a bit.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  
hw.am2315temp0.readcount

-  
The number of times to take a reading before considering it valid. This
-      defaults to 2.

-  
hw.am2315temp0.readticks

-  
The number of ticks to wait in between readings. The default is 100.

-  
hw.am2315temp0.debug

-  
If the driver is compiled with AM2315_DEBUG, this
-      node will appear and can be used to set the debugging level.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The am2315temp driver first appeared in
-    NetBSD 8.0.

-

-

-

-
The am2315temp driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The device does not appear to work with the
-    gpioiic(4) bitbang controller. When tried, reads would not
-    error, but no data was returned.

-

-

-
-  
-    
-    
-  
-
December 28, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/amdgpio.4 4.html b/static/netbsd/man4/amdgpio.4 4.html
deleted file mode 100644
index 53d33ae6..00000000
--- a/static/netbsd/man4/amdgpio.4 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDGPIO(4)Device Drivers ManualAMDGPIO(4)

-

-

-

-
amdgpio — AMD GPIO
-    Controller

-

-

-

-
amdgpio* at acpi?
-  

-  gpio* at gpiobus?

-

-

-

-
amdgpio provides a
-    gpio(4) interface for the following AMD chipsets:

-

-
    
-  
  • AMD Ryzen 7 5800U with Radeon Graphics
    • 
-  
  • AMD Ryzen 7 8840HS with Radeon 780M Graphics
    • 
-

-
The driver supports pin configuration flags

-

-
-
and interrupt capabilies

-

-
-

-

-

-
gpio(4)

-

-

-

-
The amdgpio driver first appeared in
-    NetBSD 11.0.

-

-

-

-
The amdgpio driver is derived from
-    qcomgpio(4) and OpenBSD's
-    amdgpio(4). Man page was written by Ryo
-    ONODERA
-    <ryoon@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 3, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/amdpm.4 4.html b/static/netbsd/man4/amdpm.4 4.html
deleted file mode 100644
index 8f69f440..00000000
--- a/static/netbsd/man4/amdpm.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDPM(4)Device Drivers ManualAMDPM(4)

-

-

-

-
amdpm — AMD768
-    Power Management Controller and AMD8111 System Management
-  Controller

-

-

-

-
amdpm* at pci? dev ? function ?

-

-

-

-
The amdpm provides support for the AMD768
-    Power Management Controller and for the AMD8111 System Management
-    Controller.

-

-

-

-
iic(4), pci(4),
-    rnd(4)

-

-

-

-
The amdpm driver appeared in
-    NetBSD 2.0.

-

-

-

-
Currently, this driver does not provide any power management
-    capabilities. It does, however, provide access to the SMBus via the System
-    Management Controller.

-

-

-
-  
-    
-    
-  
-
July 7, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/amdtemp.4 4.html b/static/netbsd/man4/amdtemp.4 4.html
deleted file mode 100644
index 672dfc67..00000000
--- a/static/netbsd/man4/amdtemp.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDTEMP(4)Device Drivers ManualAMDTEMP(4)

-

-

-

-
amdtemp — AMD CPU
-    on-die digital thermal sensor

-

-

-

-
amdtemp* at amdnb_miscbus?

-

-

-

-
The amdtemp driver provides support for
-    the on-die digital thermal sensor present on AMD K8, AMD Barcelona, AMD
-    Phenom, AMD Griffin, AMD Fusion, AMD Bobcat, and AMD Puma CPUs.

-
These sensors were officially introduced in AMD K8 Revision F
-    processors, and provide 0.5°C accuracy. Precision was improved in
-    Revision G chips, which provide two more bits for 0.25°C steppings.
-    Each core has two temperature sensors, and there are up to two cores per CPU
-    socket.

-
AMD Barcelona, AMD Phenom, AMD Griffin, AMD Fusion, AMD Bobcat,
-    and AMD Puma provide 0.125°gC accuracy and provide one temperature
-    sensor for each CPU socket.

-
The amdtemp driver reports temperatures
-    through the envsys(4) API.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
CPUN sensor0μKcpuN temperature

-

-

-

-
envsys(4), envstat(8),
-    powerd(8)

-

-

-

-
The amdtemp driver first appeared in
-    OpenBSD 4.4 named “kate”. It was then
-    ported to NetBSD 5.0. The driver has been renamed
-    with support for newer AMD CPUs.

-

-

-

-
The amdtemp driver was written by
-    Constantine A. Murenin
-    <cnst@openbsd.org>
-    whilst at the University of Waterloo. It was adapted to
-    NetBSD by Christoph
-  Egger.

-

-

-
-  
-    
-    
-  
-
January 28, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/amhphy.4 4.html b/static/netbsd/man4/amhphy.4 4.html
deleted file mode 100644
index 0b33da2f..00000000
--- a/static/netbsd/man4/amhphy.4 4.html	
+++ /dev/null
@@ -1,35 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMHPHY(4)Device Drivers ManualAMHPHY(4)

-

-

-

-
amhphy — Driver
-    for the AMD 79c901 10BASE-T PHY

-

-

-

-
amhphy* at mii? phy ?

-

-

-

-
The amhphy driver supports the 10BASE-T
-    portion of the AMD 79c901 HomePNA/10BASE-T PHY.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
August 24, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/amr.4 4.html b/static/netbsd/man4/amr.4 4.html
deleted file mode 100644
index 473a5f6a..00000000
--- a/static/netbsd/man4/amr.4 4.html	
+++ /dev/null
@@ -1,173 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMR(4)Device Drivers ManualAMR(4)

-

-

-

-
amr — AMI MegaRAID
-    PCI-SCSI RAID driver

-

-

-

-
amr* at pci? dev ? function ?
-  

-  scsibus* at amr?

-

-

-

-
The amr driver provides support for LSI
-    (formerly American Megatrends) MegaRAID Express, Elite and Enterprise family
-    RAID controllers for SCSI and SATA, including models relabeled and sold by
-    Dell, Hewlett-Packard, and Intel. Supported controllers include:

-

-
    
-  
  • MegaRAID 320-1
    • 
-  
  • MegaRAID 320-2
    • 
-  
  • MegaRAID Series 418
    • 
-  
  • MegaRAID Enterprise 1200 (Series 428)
    • 
-  
  • MegaRAID Enterprise 1300 (Series 434)
    • 
-  
  • MegaRAID Enterprise 1400 (Series 438)
    • 
-  
  • MegaRAID Enterprise 1500 (Series 467)
    • 
-  
  • MegaRAID Enterprise 1600 (Series 471)
    • 
-  
  • MegaRAID Elite 1500 (Series 467)
    • 
-  
  • MegaRAID Elite 1600 (Series 493)
    • 
-  
  • MegaRAID Express 100 (Series 466WS)
    • 
-  
  • MegaRAID Express 200 (Series 466)
    • 
-  
  • MegaRAID Express 300 (Series 490)
    • 
-  
  • LSI MegaRAID SCSI 320-0X, 320-2X, 320-4X
    • 
-  
  • LSI MegaRAID SCSI 320-1E, 320-2E
    • 
-  
  • LSI MegaRAID SATA 300-6x, 300-8x
    • 
-  
  • Dell PERC
    • 
-  
  • Dell PERC 2/SC
    • 
-  
  • Dell PERC 2/DC
    • 
-  
  • Dell PERC 4/Di
    • 
-  
  • Dell PERC 4/SC
    • 
-  
  • Dell PERC 4e/Si
    • 
-  
  • HP NetRAID-1/Si
    • 
-  
  • HP NetRAID-3/Si
    • 
-  
  • HP Embedded NetRAID
    • 
-  
  • Intel SRCU42X
    • 
-  
  • Intel SRCU42E
    • 
-  
  • Intel SRMOBU42E
    • 
-  
  • Intel SRCS28X
    • 
-

-

-

-

-

-

-

-  
amr%d: memory window not available

-  

-  
amr%d: I/O window not available

-  

-    
The PCI BIOS did not allocate resources necessary for the
-        correct operation of the controller. The driver cannot attach to this
-        controller.

-  

-  
amr%d: busmaster bit not set, enabling

-  

-    
The PCI BIOS did not enable busmaster DMA, which is required
-        for the correct operation of the controller. The driver has enabled this
-        bit and initialisation will proceed.

-  

-  
amr%d: can't allocate register window

-  

-  
amr%d: can't allocate interrupt

-  

-  
amr%d: can't set up interrupt

-  

-  
amr%d: can't allocate parent DMA tag

-  

-  
amr%d: can't allocate buffer DMA tag

-  

-  
amr%d: can't allocate scatter/gather DMA tag

-  

-  
amr%d: can't allocate s/g table

-  

-  
amr%d: can't allocate mailbox tag

-  

-  
amr%d: can't allocate mailbox memory

-  

-    
A resource allocation error occurred while initialising the
-        driver; initialisation has failed and the driver will not attach to this
-        controller.

-  

-  
amr%d: can't obtain configuration data from controller

-  

-  
amr%d: can't obtain product data from controller

-  

-    
The driver was unable to obtain vital configuration data from
-        the controller. Initialisation has failed and the driver will not attach
-        to this controller.

-  

-  
amr%d: can't establish configuration hook

-  

-  
amr%d: can't scan controller for drives

-  

-    
The scan for logical drives managed by the controller failed.
-        No drives will be attached.

-  

-  
amr%d: device_add_child failed

-  

-  
amr%d: bus_generic_attach returned %d

-  

-    
Creation of the logical drive instances failed; attachment of
-        one or more logical drives may have been aborted.

-  

-  
amr%d: flushing cache...

-  

-    
The controller cache is being flushed prior to shutdown or
-        detach.

-  

-

-

-

-

-

-  
amr%d: I/O beyond end of unit (%u,%d > %u)

-  

-    
A partitioning error or disk corruption has caused an I/O
-        request beyond the end of the logical drive. This may also occur if
-        FlexRAID Virtual Sizing is enabled and an I/O operation is attempted on
-        a portion of the virtual drive beyond the actual capacity available.

-  

-  
amr%d: polled command timeout

-  

-    
An initialisation command timed out. The initialisation
-        process may fail as a result.

-  

-  
amr%d: bad slot %d completed

-  

-    
The controller reported completion of a command that the
-        driver did not issue. This may result in data corruption, and suggests a
-        hardware or firmware problem with the system or controller.

-  

-  
amr%d: I/O error - %x

-  

-    
An I/O error has occurred.

-  

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), pci(4),
-    scsi(4), sd(4), st(4),
-    amrctl(8)

-

-

-
-  
-    
-    
-  
-
July 23, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/ams.4 3.html b/static/netbsd/man4/ams.4 3.html
deleted file mode 100644
index cb9292af..00000000
--- a/static/netbsd/man4/ams.4 3.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMS(4)Device Drivers ManualAMS(4)

-

-

-

-
ams — Apple
-    Desktop Bus mouse driver for wscons

-

-

-

-
ams* at obio?
-  

-  wsmouse* at ams?

-

-

-

-
This driver provides the wscons(4) driver with
-    support for Apple Desktop Bus mice.

-

-

-

-
NetBSD is known to support the following
-    ADB mice:

-
    
-  
  • On-board trackpads and trackballs in PowerBook models
    • 
-  
  • Apple Desktop Bus Mouse
    • 
-  
  • Apple Desktop Bus Mouse II
    • 
-  
  • Interex ADB Mouse
    • 
-  
  • Logitech TrackMan
    • 
-  
  • Logitech MouseMan
    • 
-  
  • Microspeed Mouse Deluxe
    • 
-  
  • Mouse Systems A3 Mouse
    • 
-  
  • Most third-party ADB mice, trackballs, and trackpads are supported
    • 
-

-

-

-

-

-  
ams0 at adb0 addr 3: 1-button, 100 dpi mouse

-  
This is a typical autoconfiguration message noting the presence of the
-      ams mouse.

-

-

-

-

-
adb(4), wscons(4),
-    wsmouse(4), wsconsctl(8)

-

-

-
-  
-    
-    
-  
-
September 21, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/an.4 3.html b/static/netbsd/man4/an.4 3.html
deleted file mode 100644
index 361c037f..00000000
--- a/static/netbsd/man4/an.4 3.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
AN(4)Device Drivers ManualAN(4)

-

-

-

-
an — Aironet
-    4500/4800 and Cisco 340/350 series wireless network driver

-

-

-

-
an* at pcmcia? function ?
-  

-  an* at pci? dev ? function ?
-  

-  an* at isapnp?

-

-

-

-
The an driver provides support for Aironet
-    Communications 4500/4800 and Cisco Aironet 340/350 series wireless network
-    adapters. This includes the ISA, PCI and PCMCIA varieties. The 4500 series
-    adapters operate at 1 and 2Mbps while the 4800 series and 340/350 series can
-    operate at 1, 2, 5.5 and 11Mbps. The ISA, PCI and PCMCIA devices are all
-    based on the same core PCMCIA modules and all have the same programming
-    interface, however unlike the Lucent WaveLAN/IEEE cards, the ISA and PCI
-    cards appear to the host as normal ISA and PCI devices and do not require
-    any PCMCIA support.

-
The PCMCIA Aironet cards require PCMCIA support. ISA cards can
-    either be configured to use ISA Plug and Play or to use a particular I/O
-    address and IRQ by properly setting the DIP switches on the board. (The
-    default switch setting is for plug and play.) The an
-    driver has Plug and Play support and will work in either configuration,
-    however when using a hard-wired I/O address and IRQ, the driver
-    configuration and the NIC's switch settings must agree. PCI cards require no
-    switch settings of any kind and will be automatically probed and
-  attached.

-
All host/device interaction with the Aironet cards is via
-    programmed I/O. The Aironet devices support 802.11 and 802.3 frames, power
-    management, BSS (infrastructure) and IBSS (ad-hoc) operation modes. The
-    an driver encapsulates all IP and ARP traffic as
-    802.11 frames, however it can receive either 802.11 or 802.3 frames.
-    Transmit speed is selectable between 1Mbps, 2Mbps, 5.5Mbps, 11Mbps, or
-    “auto” (the NIC automatically chooses the best speed).

-
By default, the an driver configures the
-    Aironet card to join an access point with an SSID of null string. For ad-hoc
-    mode, in which stations can communicate among each other without the aid of
-    an access point, the driver must be set using
-  ifconfig(8).

-
For more information on configuring this device, see
-    ifconfig(8) and ifmedia(4).

-

-

-

-
Cards supported by the an driver
-  include:

-
    
-  
  • Aironet 4500 Series
    • 
-  
  • Aironet 4800 Series
    • 
-  
  • Cisco Aironet 340 Series
    • 
-  
  • Cisco Aironet 350 Series
    • 
-

-

-

-

-

-  
an%d: init failed

-  
The Aironet card failed to come ready after an initialization command was
-      issued.

-  
an%d: failed to allocate %d bytes on NIC

-  
The driver was unable to allocate memory for transmit frames in the NIC's
-      on-board RAM.

-  
an%d: device timeout

-  
The Aironet card failed to generate an interrupt to acknowledge a transmit
-      command.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), ifconfig(8)

-

-

-

-
The an device driver first appeared in
-    FreeBSD 4.0, and then in NetBSD
-    1.6.

-

-

-

-
The an driver was written by
-    Bill Paul
-    <wpaul@ee.columbia.edu>.

-

-

-
-  
-    
-    
-  
-
December 13, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/apei.4 4.html b/static/netbsd/man4/apei.4 4.html
deleted file mode 100644
index 039308a8..00000000
--- a/static/netbsd/man4/apei.4 4.html	
+++ /dev/null
@@ -1,107 +0,0 @@
-
-  
-    
-    
-    
-  
-
APEI(4)Device Drivers ManualAPEI(4)

-

-

-

-
apei — ACPI
-    Platform Error Interfaces

-

-

-

-
apei* at apeibus?

-

-

-

-
apei reports hardware errors discovered
-    through APEI, the ACPI Platform Error Interfaces.

-
apei also supports injecting errors.

-

-

-

-
When the hardware detects an error and reports it to
-    apei, it will print information about the error to
-    the console.

-
Example of a correctable memory error, automatically corrected by
-    the system, with no further intervention needed:

-

-
apei0: error source 1 reported hardware error: severity=corrected nentries=1 status=0x12<CE,GEDE_COUNT=0x1>
-apei0: error source 1 entry 0: SectionType={0xa5bc1114,0x6f64,0x4ede,0xb8b8,{0x3e,0x83,0xed,0x7c,0x83,0xb1}} (memory error)
-apei0: error source 1 entry 0: ErrorSeverity=2 (corrected)
-apei0: error source 1 entry 0: Revision=0x201
-apei0: error source 1 entry 0: Flags=0x1<PRIMARY>
-apei0: error source 1 entry 0: FruText=CorrectedErr
-apei0: error source 1 entry 0: MemoryErrorType=8 (PARITY_ERROR)
-
-Example of a fatal uncorrectable memory error:
-

-

-apei0: error source 0 reported hardware error: severity=fatal nentries=1
-  status=0x11<UE,GEDE_COUNT=0x1>
-apei0: error source 0 entry 0:
-  SectionType={0xa5bc1114,0x6f64,0x4ede,0xb8b8,{0x3e,0x83,0xed,0x7c,0x83,0xb1}}
-  (memory error)
-apei0: error source 0 entry 0: ErrorSeverity=1 (fatal)
-apei0: error source 0 entry 0: Revision=0x201
-apei0: error source 0 entry 0: Flags=0x1<PRIMARY>
-apei0: error source 0 entry 0: FruText=UncorrectedErr
-apei0: error source 0 entry 0: ErrorStatus=0x400<ErrorType=0x4=ERR_MEM>
-apei0: error source 0 entry 0: Node=0x0
-apei0: error source 0 entry 0: Module=0x0
-apei0: error source 0 entry 0: Device=0x0
-panic: fatal hardware error

-
-Details of the hardware error sources can be dumped with
-acpidump(8).

-

-

-

-
acpi(4), acpihed(4),
-    acpidump(8)

-
ACPI Specification 6.5,
-    https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html,
-    Chapter 18: ACPI Platform Error Interfaces
-    (APEI).

-

-

-

-
The apei driver first appeared in
-    NetBSD 10.1.

-

-

-

-
The apei driver was written by
-    Taylor R Campbell
-    <riastradh@NetBSD.org>.

-

-

-

-
No sysctl interface to read BERT after boot.

-
No simple sysctl interface to inject errors with EINJ, or any way
-    to inject errors at physical addresses in pages allocated for testing.
-    Perhaps there should be a separate kernel module for that.

-
Nothing reads, writes, or clears ERST.
-    NetBSD could use it to store dmesg or other
-    diagnostic information on panic.

-
Many hardware error source types in the HEST are missing, such as
-    PCIe errors.

-
apei is not wired to any machine-dependent
-    machine check exception notifications.

-
No formal log format or sysctl/device interface that programs can
-    reliably act on.

-
NetBSD makes no attempt to recover from
-    uncorrectable but recoverable errors, such as discarding a clean cached page
-    where an uncorrectable memory error has occurred.

-

-

-
-  
-    
-    
-  
-
March 18, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/aps.4 4.html b/static/netbsd/man4/aps.4 4.html
deleted file mode 100644
index 543fd878..00000000
--- a/static/netbsd/man4/aps.4 4.html	
+++ /dev/null
@@ -1,126 +0,0 @@
-
-  
-    
-    
-    
-  
-
APS(4)Device Drivers ManualAPS(4)

-

-

-

-
aps — ThinkPad
-    Active Protection System accelerometer

-

-

-

-
aps0 at isa? port 0x1600

-

-

-

-
The aps driver provides support for
-    several sensors found in some ThinkPad laptops.

-
The sensors currently exposed via the envsys(4)
-    interface are:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
integerX-axis acceleration
integerY-axis acceleration
integerWeighted X acceleration?
integerWeighted Y acceleration?
degCUnknown temperature
degCUnknown temperature
booleanKeyboard activity
booleanMouse activity
booleanLid state

-

-

-

-
envsys(4), hpacel(4),
-    thinkpad(4), envstat(8)

-

-

-

-
The aps driver first appeared in
-    OpenBSD 3.8 and was then ported to
-    NetBSD 5.0.

-

-

-

-
The aps driver was written by
-    Jonathan Gray
-    <jsg@openbsd.org>.

-

-

-

-
Few issues can be mentioned.

-
    
-  
  • The aps driver does not maintain state and
-      subsequently does not take evasive action when it thinks the hard drive is
-      in danger. Possible actions would include spinning down the hard drive in
-      case excessive tremor is detected by the sensors.
    • 
-  
  • The Y axis on X40 and possibly other models seems to be inverted. It is
-      unknown how to distinguish between different versions of the accelerometer
-      to compensate for this in the driver at this time.
    • 
-  
  • The sensor values are refreshed every 0.5 seconds. Because no protection
-      measures are taken, this is unnecessary and may have a negative effect on
-      battery life.
    • 
-  
  • As IBM provides no documentation, it is not known what all the available
-      sensors are used for.
    • 
-

-

-

-
-  
-    
-    
-  
-
July 13, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/aq.4 4.html b/static/netbsd/man4/aq.4 4.html
deleted file mode 100644
index 1c0ae86f..00000000
--- a/static/netbsd/man4/aq.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
AQ(4)Device Drivers ManualAQ(4)

-

-

-

-
aq — Aquantia AQC
-    multigigabit Network driver

-

-

-

-
aq* at pci? dev ? function ?

-

-

-

-
The aq driver supports Aquantia AQC series
-    controllers. Supported controllers include:

-

-
    
-  
  • AQC100 10 Gigabit Network Adapter
    • 
-  
  • AQC107 10 Gigabit Network Adapter
    • 
-  
  • AQC108 5 Gigabit Network Adapter
    • 
-  
  • AQC109 2.5 Gigabit Network Adapter
    • 
-  
  • AQC111 5 Gigabit Network Adapter
    • 
-  
  • AQC112 2.5 Gigabit Network Adapter
    • 
-  
  • AQC100S 10 Gigabit Network Adapter
    • 
-  
  • AQC107S 10 Gigabit Network Adapter
    • 
-  
  • AQC108S 5 Gigabit Network Adapter
    • 
-  
  • AQC109S 2.5 Gigabit Network Adapter
    • 
-  
  • AQC111S 5 Gigabit Network Adapter
    • 
-  
  • AQC112S 2.5 Gigabit Network Adapter
    • 
-  
  • AQC113DEV 10 Gigabit Network Adapter
    • 
-  
  • AQC113 10 Gigabit Network Adapter
    • 
-  
  • AQC113C 10 Gigabit Network Adapter
    • 
-  
  • AQC113CA 10 Gigabit Network Adapter
    • 
-  
  • AQC113CS 10 Gigabit Network Adapter
    • 
-  
  • AQC114CS 5 Gigabit Network Adapter
    • 
-  
  • AQC115C 2.5 Gigabit Network Adapter
    • 
-  
  • AQC116C Gigabit Network Adapter
    • 
-  
  • D100 10 Gigabit Network Adapter
    • 
-  
  • D107 10 Gigabit Network Adapter
    • 
-  
  • D108 5 Gigabit Network Adapter
    • 
-  
  • D109 2.5 Gigabit Network Adapter
    • 
-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    vlan(4), ifconfig(8)

-

-

-

-
The aq driver first appeared in
-    NetBSD 9.1, and is based on the
-    FreeBSD driver of the same name, but has been
-    drastically rewritten by Ryo Shimizu.

-

-

-
-  
-    
-    
-  
-
January 14, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/arcmsr.4 3.html b/static/netbsd/man4/arcmsr.4 3.html
deleted file mode 100644
index d546d209..00000000
--- a/static/netbsd/man4/arcmsr.4 3.html	
+++ /dev/null
@@ -1,113 +0,0 @@
-
-  
-    
-    
-    
-  
-
ARCMSR(4)Device Drivers ManualARCMSR(4)

-

-

-

-
arcmsr — Areca
-    Technology Corporation SATA/SAS RAID controller

-

-

-

-
arcmsr* at pci? dev ? function ?

-

-

-

-
The arcmsr driver provides support for the
-    PCI-X and PCI Express RAID controllers from Areca Technology
-  Corporation:

-

-
    
-  
  • ARC-1110 PCI-X 4 Port SATA RAID Controller
    • 
-  
  • ARC-1110ML PCI-X 4 Port SATA RAID Controller
    • 
-  
  • ARC-1120 PCI-X 8 Port SATA RAID Controller
    • 
-  
  • ARC-1120ML PCI-X 8 Port SATA RAID Controller
    • 
-  
  • ARC-1130 PCI-X 12 Port SATA RAID Controller
    • 
-  
  • ARC-1130ML PCI-X 12 Port SATA RAID Controller
    • 
-  
  • ARC-1160 PCI-X 16 Port SATA RAID Controller
    • 
-  
  • ARC-1160ML PCI-X 16 Port SATA RAID Controller
    • 
-  
  • ARC-1170 PCI-X 24 Port SATA RAID Controller
    • 
-  
  • ARC-1200 Rev A PCI Express 2 Port SATA RAID Controller
    • 
-  
  • ARC-1202 PCI Express 2 Port SATA RAID Controller
    • 
-  
  • ARC-1210 PCI Express 4 Port SATA RAID Controller
    • 
-  
  • ARC-1220 PCI Express 8 Port SATA RAID Controller
    • 
-  
  • ARC-1230 PCI Express 12 Port SATA RAID Controller
    • 
-  
  • ARC-1230ML PCI Express 12 Port SATA RAID Controller
    • 
-  
  • ARC-1231ML PCI Express 12 Port SATA RAID Controller
    • 
-  
  • ARC-1260 PCI Express 16 Port SATA RAID Controller
    • 
-  
  • ARC-1260ML PCI Express 16 Port SATA RAID Controller
    • 
-  
  • ARC-1261ML PCI Express 16 Port SATA RAID Controller
    • 
-  
  • ARC-1280 PCI Express 24 Port SATA RAID Controller
    • 
-  
  • ARC-1280ML PCI Express 24 Port SATA RAID Controller
    • 
-  
  • ARC-1680 PCI Express 8 Port SAS RAID Controller
    • 
-  
  • ARC-1680LP PCI Express 8 Port SAS RAID Controller
    • 
-  
  • ARC-1680i PCI Express 8 Port SAS RAID Controller
    • 
-  
  • ARC-1680x PCI Express 8 Port SAS RAID Controller
    • 
-  
  • ARC-1681 PCI-X 8 Port SAS RAID Controller
    • 
-

-
These controllers support RAID levels 0, 1, 1E, 3, 5, 6, and JBOD
-    using either SAS or SATA II drives.

-
arcmsr supports management and monitoring
-    of the controller through the bioctl(8) and
-    envstat(8) commands.

-
Please note, however, that to use some features that
-    require special privileges, such as creating/removing hot-spares,
-    pass-through disks or RAID volumes will require to have the
-    
-    disabled in the firmware; otherwise a
-     error will be reported by bioctl(8).

-
When a RAID 1 or 1+0 volume is created, either through the
-    bioctl(8) command or controller's firmware, the volume
-    won't be accessible until the initialization is done. A way to get access to
-    the sd(4) device that corresponds to that volume without
-    rebooting, is to issue the following command (once the initialization is
-    finished):

-

-
$ scsictl scsibus0 scan any any

-

-
The arcmsr driver will also report to the
-    kernel log buffer any error that might appear when handling firmware
-    commands, such as used by the bioctl(8) command.

-

-

-

-
The arcmsr driver is able to send events
-    to powerd(8) if a volume or any drive connected to the
-    volume is not online. The
-    
-    event will be sent to the
-    /etc/powerd/scripts/sensor_drive script when such
-    condition happens.

-

-

-

-
intro(4), pci(4),
-    scsi(4), sd(4),
-    bioctl(8), envstat(8),
-    powerd(8), scsictl(8)

-

-

-

-
The arcmsr driver first appeared in
-    NetBSD 5.0.

-

-

-

-
The arcmsr driver was originally written
-    for OpenBSD by David Gwynne.
-    It was ported to NetBSD and extended by
-    Juan Romero Pardines.

-

-

-
-  
-    
-    
-  
-
March 3, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/arcofi.4 4.html b/static/netbsd/man4/arcofi.4 4.html
deleted file mode 100644
index 523be021..00000000
--- a/static/netbsd/man4/arcofi.4 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
ARCOFI(4)Device Drivers ManualARCOFI(4)

-

-

-

-
arcofi — Siemens
-    PSB2160 audio codec

-

-

-

-
arcofi* at dio?
-  

-  audio* at audiobus?

-

-

-

-
The arcofi driver supports the HP
-    “Audio1” audio devices, based upon the Siemens PSB2160
-    “ARCOFI” codec, to implement the audio device interface
-    described in audio(4).

-
This device is found onboard HP 9000 workstations models 425e, 705
-    and 710.

-
The arcofi is limited to a phone-quality
-    mono, 8000 Hz sound.

-

-

-
The following encodings are supported:

-

-

-

-  

-  
 

-  

-  
 

-  

-  
Natively supported.
-    

-  

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
Software converted to AUDIO_ENCODING_SLINEAR_BE
-      encoding.

-

-

-

-

-

-
The arcofi has three audio ports:

-

-

-

-  

-  
The ‘line in’ jack connector.

-  

-  
The ‘line out’ jack connector.

-  

-  
The built-in speaker.

-

-

-
Each port has a volume control, and can be muted.

-
The outputs.line and
-    outputs.speaker volume settings are tied to the same
-    hardware setting.

-

-

-

-

-
audioctl(1), mixerctl(1),
-    ioctl(2), audio(4),
-    dio(4), intro(4)

-

-

-

-
The arcofi driver was written for
-    OpenBSD and first appeared in
-    OpenBSD 5.1, and was ported to
-    NetBSD.

-

-

-
-  
-    
-    
-  
-
August 25, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/aria.4 4.html b/static/netbsd/man4/aria.4 4.html
deleted file mode 100644
index a29b574a..00000000
--- a/static/netbsd/man4/aria.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
ARIA(4)Device Drivers ManualARIA(4)

-

-

-

-
aria — Sierra's
-    Aria chipset audio device driver

-

-

-

-
aria0 at isa? port 0xPPP irq I
-  

-  aria0 at isa? port 0xPPP irq I flags 1
-  

-  audio* at audiobus?

-

-

-

-
The aria driver provides support for
-    Sierra's Aria chipset, which is the basis of such cards as the Prometheus
-    Aria 16, the Genoa AudioBahn 16 Pro, and some Diamond Sonic Sounds (Rev A5
-    and Rev B2).

-
The Sierra Aria chipset is full-duplex and is capable of 8- and
-    16- bit audio sample recording and playback at 7875 Hz, 11025 Hz, 15750 Hz,
-    22050 Hz, 31500 Hz, and 44100 Hz.

-
Valid I/O addresses are 0x280, 0x290, 0x2A0, and 0x2B0. The IRQ
-    may be set to 10, 11, or 12.

-
The flags setting is necessary for the Prometheus Aria 16, as it
-    needs to be specially configured at each cold boot by twiddling with the
-    joystick port.

-

-

-

-
audio(4), isa(4)

-

-

-

-
The aria device driver appeared in
-    NetBSD 1.4.

-

-

-

-
DMA is not yet supported.

-
The flags option should not be necessary.

-
It is necessary to configure the port and irq.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/artsata.4 4.html b/static/netbsd/man4/artsata.4 4.html
deleted file mode 100644
index 1f0aae98..00000000
--- a/static/netbsd/man4/artsata.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
ARTSATA(4)Device Drivers ManualARTSATA(4)

-

-

-

-
artsata — Intel
-    i31244 Serial ATA disk controller driver

-

-

-

-
artsata* at pci? dev ? function ? flags
-    0x0000
-  

-  options PCIIDE_I31244_DISABLEDMA

-

-

-

-
The artsata driver supports the Intel
-    i31244 Serial ATA and controllers, and provides the interface with the
-    hardware for the ata(4) driver.

-
The 0x0002 flag forces the artsata driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the SATA
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
Early samples of the Intel i31244 Serial ATA controller revision 0
-    had a bug affecting DMA data transfers. Full production samples have been
-    fixed, but have the same revision number. The
-    PCIIDE_I31244_DISABLEDMA option can be used to
-    disable DMA on the buggy revisions.

-

-

-
-  
-    
-    
-  
-
February 12, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/ast.4 4.html b/static/netbsd/man4/ast.4 4.html
deleted file mode 100644
index 05a70a9a..00000000
--- a/static/netbsd/man4/ast.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
AST(4)Device Drivers ManualAST(4)

-

-

-

-
ast — multiplexing
-    serial communications interface

-

-

-

-
ast0 at isa? port 0x1a0 irq 5
-  

-  com2 at ast? slave ?
-  

-  com3 at ast? slave ?
-  

-  com4 at ast? slave ?
-  

-  com5 at ast? slave ?

-

-

-

-
The ast driver provides support for boards
-    that multiplex together up to four EIA RS-232C (CCITT V.28) communications
-    interfaces. Apparently the original maker of hardware using this
-    multiplexing protocol was AST.

-
Each ast device is the master device for
-    up to four com devices. The kernel configuration
-    specifies these com devices as slave devices of the
-    ast device, as shown in the synopsis. The slave ID
-    given for each com device determines which bit in
-    the interrupt multiplexing register is tested to find interrupts for that
-    device. The port specification for the ast device is
-    used to compute the base addresses for the com
-    subdevices and the port for the interrupt multiplexing register.

-

-

-

-

-  
/dev/tty0?

-  
 

-

-

-

-

-
com(4)

-

-

-

-
The ast driver was written by Roland
-    McGrath and placed into the public domain.

-

-

-
-  
-    
-    
-  
-
March 30, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/asus.4 4.html b/static/netbsd/man4/asus.4 4.html
deleted file mode 100644
index a8088d7d..00000000
--- a/static/netbsd/man4/asus.4 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
ASUS(4)Device Drivers ManualASUS(4)

-

-

-

-
asus — ASUS
-    hotkeys

-

-

-

-
asus* at acpi?

-

-

-

-
The asus driver provides support for
-    hotkeys available in various ASUS laptops and netbooks (Eee PC series
-    included).

-
The following hotkeys are directly handled by
-    asus:

-

-

-  
Fn + F3

-  
Decrease LCD brightness

-  
Fn + F4

-  
Increase LCD brightness

-  
Fn + F5

-  
Switch between LCD and external video output

-  
Fn + F7

-  
Toggle audio

-  
Fn + F8

-  
Volume down

-  
Fn + F9

-  
Volume up

-

-

-

-

-

-
acpi(4), powerd(8)

-

-

-

-
The asus driver appeared in
-    NetBSD 5.0.

-

-

-

-
The asus device driver was written by
-    Jared D. McNeill. This man page was written by
-    Leonardo Taccari.

-

-

-

-
At the moment asus does not handle Fn + F6
-    (Task manager).

-

-

-
-  
-    
-    
-  
-
July 13, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/ata.4 4.html b/static/netbsd/man4/ata.4 4.html
deleted file mode 100644
index 6e66fabe..00000000
--- a/static/netbsd/man4/ata.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATA(4)Device Drivers ManualATA(4)

-

-

-

-
ata, atabus
-    — AT attachment (ATA) bus driver

-

-

-

-
atabus* at wdc? channel ?
-  

-  atabus* at pciide? channel ?
-  

-  atabus* at ahcisata? channel ?
-  

-  atabus* at mvsata? channel ?
-  

-  atabus* at siisata? channel ?

-

-

-

-
The ata driver provides basic low-level
-    functions for the wd(4) and atapi(4)
-    drivers, for hardware which provides direct access to the ATA registers.

-

-

-

-
ahcisata(4), atapi(4),
-    intro(4), mvsata(4),
-    pciide(4), siisata(4),
-    wd(4), wdc(4)

-

-

-
-  
-    
-    
-  
-
April 23, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/atalk.4 4.html b/static/netbsd/man4/atalk.4 4.html
deleted file mode 100644
index 4c2bb44e..00000000
--- a/static/netbsd/man4/atalk.4 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATALK(4)Device Drivers ManualATALK(4)

-

-

-

-
atalk — AppleTalk
-    Protocol Family

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <netatalk/at.h>

-

-

-

-
The AppleTalk Protocol Family provides presentation layer support
-    for the AppleTalk Datagram Delivery Protocol (DDP), using the SOCK_DGRAM
-    socket type. In addition, access to in-kernel AppleTalk routing tables and
-    network interface configurations is provided.

-
The AppleTalk Protocol Suite provides support for five kinds of
-    physical media: LocalTalk (230kbps wire-or'd serial), Ethernet, FDDI, Token
-    Ring, and asynchronous serial connections (using either AppleTalk Remote
-    Access (ARA) or PPP ). Currently, NetBSD's AppleTalk
-    implementation supports Ethernet.

-
AppleTalk packets are encapsulated on the Ethernet using the
-    EtherTalk Link Access Protocol (ELAP). Local network address resolution is
-    handled using the AppleTalk Address Resolution Protocol (AARP). Neither of
-    these protocols is exposed to user-mode applications.

-

-

-

-
AppleTalk addresses are three byte quantities, stored in network
-    byte order. The include file
-    <netatalk/at.h> defines the
-    AppleTalk address format.

-
Sockets in the AppleTalk protocol family use the following address
-    structure:

-

-
struct sockaddr_at {
-	uint8_t	sat_len;
-	sa_family_t	sat_family;
-	uint8_t	sat_port;
-	struct at_addr	sat_addr;
-	union {
-		struct netrange r_netrange;
-		char		r_zero[8];
-	} sat_range;
-};

-

-
The port of a socket may be set with bind(2).
-    The node for bind(2) must always be
-    ATADDR_ANYNODE: “this node”. The net
-    must be ATADDR_ANYNET.
-    ATADDR_ANYNET corresponds to the machine's
-    “primary” address (the first configured). The port of a socket
-    and the primary address are returned with
-  getsockname(2).

-

-

-

-
The AppleTalk protocol family comprises the DDP datagram delivery
-    protocol, AppleTalk Data Stream Protocol (ADSP), AppleTalk Echo Protocol
-    (AEP), AppleTalk Filing Protocol (AFP), AppleTalk Session Protocol (ASP),
-    AppleTalk Transaction Protocol (ATP), Name Binding Protocol (NBP), Printer
-    Access Protocol (PAP), and Zone Information Protocol (ZIP).

-
DDP is implemented in the kernel as
-    SOCK_DGRAM sockets in the
-    AF_APPLETALK address family.
-    NetBSD implements all other AppleTalk protocols
-    using the Netatalk package. Netatalk implements all functions except for
-    ADSP and an AFP client. AEP, NBP, and ZIP services are provided by the
-    atalkd daemon. ASP and ATP services are provided by a user library. PAP and
-    AFP services are provided by user programs and daemons.

-

-

-

-
bind(2), getsockname(2),
-    options(4)

-
Gursharan S. Sidhu,
-    Richard F. Andrews, and Alan B.
-    Oppenheimer, Inside AppleTalk, second
-    edition.

-

-

-
-  
-    
-    
-  
-
February 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/ataraid.4 4.html b/static/netbsd/man4/ataraid.4 4.html
deleted file mode 100644
index 22113b21..00000000
--- a/static/netbsd/man4/ataraid.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATARAID(4)Device Drivers ManualATARAID(4)

-

-

-

-
ataraid — software
-    BIOS RAID

-

-

-

-
pseudo-device ataraid
-  

-  ld* at ataraid? vendtype ? unit ?

-

-

-

-
The ataraid driver provides support for
-    BIOS-based software RAID controllers. These are devices which have some
-    simple support for several basic RAID levels (often RAID 0 and RAID 1), but
-    which require software support to actually perform the RAID function. The
-    BIOS support is largely just to create and recognize the array so that it
-    may be a boot device.

-
The driver currently supports RAID formats from:

-
    
-  
  • Adaptec HostRAID (found in Intel 6300ESB)
    • 
-  
  • Intel MatrixRAID
    • 
-  
  • JMicron RAID
    • 
-  
  • nVidia MediaShield
    • 
-  
  • Promise FastTrak
    • 
-  
  • Via V-RAID (found in many VIA-based motherboards)
    • 
-

-
Status of the logical disk, as well as the disks associated with
-    it, can be viewed through the bioctl(8) utility.

-

-

-

-
ld(4), bioctl(8)

-

-

-

-
The ataraid driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The ataraid driver was originally adapted
-    from FreeBSD by Jason Thorpe
-    ⟨thorpej@NetBSD.org⟩.

-

-

-

-
Not all features of the software RAID are currently recognized or
-    supported. For example, the Adaptec support doesn't recognize when a RAID 1
-    should be in a “building” state, and it does not do the right
-    thing.

-
At least part of the reason for this is that the
-    publicly-available information on these formats is quite limited.

-

-

-
-  
-    
-    
-  
-
September 16, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/ate.4 4.html b/static/netbsd/man4/ate.4 4.html
deleted file mode 100644
index 17a7428e..00000000
--- a/static/netbsd/man4/ate.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATE(4)Device Drivers ManualATE(4)

-

-

-

-
ate — Fujitsu
-    MB86965A based Allied-Telesis Ethernet cards driver

-

-

-

-
ate0 at isa? port 0x2a0 irq ?
-  

-  ate* at mca? slot ?

-

-

-

-
The ate driver supports Allied-Telesis ISA
-    and MCA bus Ethernet adapters based on the Fujitsu MB86965A Ethernet
-    controller. Supported boards include:

-

-

-  
Allied-Telesis AT1700T/AT1700BT/AT1700FT/AT1700AT

-  
 

-  
Allied-Telesis AT1720T/AT1720BT/AT1720FT/AT1720AT

-  
 

-  
Allied-Telesis RE2001/RE2003/RE2005/RE2009

-  
 

-

-

-

-

-

-
fmv(4), ifmedia(4),
-    intro(4), isa(4),
-    mbe(4), mca(4),
-    ifconfig(8)

-

-

-

-
The ate driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
October 5, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/ath.4 3.html b/static/netbsd/man4/ath.4 3.html
deleted file mode 100644
index 8f6ebddd..00000000
--- a/static/netbsd/man4/ath.4 3.html	
+++ /dev/null
@@ -1,450 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATH(4)Device Drivers ManualATH(4)

-

-

-

-
ath — Atheros IEEE
-    802.11 driver

-

-

-

-
ath* at pci? dev ? function ?
-  

-  ath* at cardbus? function ?

-

-

-

-
The ath driver provides support for
-    wireless network adapters based on the Atheros AR2413, AR2417, AR5210,
-    AR5211, AR5212, AR5213, AR5413, AR5416, AR5424, AR9160, AR9280, and AR9285
-    chips. Chip-specific support is provided by the Atheros Hardware Access
-    Layer (HAL).

-
Supported features include 802.11 and 802.3 frames, power
-    management, BSS, IBSS, and host-based access point operation modes. All
-    host/device interaction is via DMA.

-
The ath driver encapsulates all IP and ARP
-    traffic as 802.11 frames, however it can receive either 802.11 or 802.3
-    frames. Transmit speed and operating mode is selectable depending on your
-    hardware.

-
AR5210-based devices support 802.11a operation with transmit
-    speeds of 6 Mbps, 9 Mbps, 12 Mbps, 18 Mbps, 24 Mbps, 36 Mbps, 48 Mbps, and
-    54 Mbps.

-
AR5211-based devices support 802.11a and 802.11b operation with
-    transmit speeds as above for 802.11a operation and 1Mbps, 2Mbps, 5.5 Mbps
-    and 11Mbps for 802.11b operation.

-
AR5212-based and AR5213-based devices support 802.11a, 802.11b,
-    and 802.11g operation with transmit speeds appropriate to each.

-
All chips also support an Atheros Turbo Mode (TM) that operates in
-    the 802.11a frequency range with 2x the transmit speeds. (This mode is,
-    however, only interoperable with other Atheros-based devices.)

-
The actual transmit speed used is dependent on signal quality and
-    the “rate control” algorithm employed by the driver. All chips
-    support WEP encryption.

-
By default, the ath driver configures the
-    card for BSS operation (aka infrastructure mode). This mode requires the use
-    of an access point (base station).

-
The ath driver also supports the standard
-    IBSS point-to-point mode where stations can communicate amongst themselves
-    without the aid of an access point.

-
The driver may also be configured to operate in hostap mode. In
-    this mode a host may function as an access point (base station). Access
-    points are different than operating in IBSS mode. They operate in BSS mode.
-    They allow for easier roaming and bridge all Ethernet traffic such that
-    machines connected via an access point appear to be on the local Ethernet
-    segment.

-
The mode of operation is chosen by specifying the appropriate
-    mediaopt value to ifconfig. The -m flag to ifconfig
-    will list the available options.

-
For more information on configuring this device, see
-    ifconfig(8).

-
Devices supported by the ath driver come
-    in either CardBus or mini-PCI packages. Wireless cards in CardBus slots may
-    be inserted and ejected on the fly.

-
The following cards are among those supported by the
-    ath driver:

-

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
ChipBusStandard
3Com 3CRPAG175AR5212CardBusa/b/g
Airlink AWLH4030AR5212PCIb/g
Aztech WL830PCAR5212CardBusb/g
Belkin F6D3000AR5212PCIa/b/g
D-Link DWL-A520AR5210PCIa
D-Link DWL-A650AR5210CardBusa
D-Link DWL-AB650AR5211CardBusa/b
D-Link DWL-AG520AR5212PCIa/b/g
D-Link DWL-AG650AR5212CardBusa/b/g
D-Link DWL-AG660AR521?CardBusa/b/g
D-Link DWL-G520AR5212PCIb/g
D-Link DWL-G650BAR5212CardBusb/g
Elecom LD-WL54AR5211CardBusa
Elecom LD-WL54AGAR5212CardBusa/b/g
Fujitsu E5454AR5212CardBusa/b/g
Fujitsu E5454AR5212CardBusa/b/g
Fujitsu FMV-JW481AR5212CardBusa/b/g
HP NC4000AR5212PCIa/b/g
I/O Data WN-A54AR5212CardBusa
I/O Data WN-ABAR5212CardBusa/b
I/O Data WN-AGAR5212CardBusa/b/g
Linksys WMP55AGAR5212PCIa/b/g
Linksys WPC51ABAR5211CardBusa/b
Linksys WPC55AGAR5212CardBusa/b/g
NEC PA-WL/54AGAR5212CardBusa/b/g
Netgear WAB501AR5211CardBusa/b
Netgear WAG311AR5212PCIa/b/g
Netgear WAG511AR5212CardBusa/b/g
Netgear WG311AR5212PCIb/g
Netgear WG511TAR5212CardBusb/g
Orinoco 8470WDAR5212CardBusa/b/g
Orinoco 8480AR5212CardBusa/b/g
Planex GW-NS54AGAR5212CardBusa/b/g
Proxim Skyline 4030AR5210CardBusa
Proxim Skyline 4032AR5210PCIa
Samsung SWL-5200NAR5212CardBusa/b/g
SMC SMC2735WAR5210CardBusa
Sony PCWA-C300SAR5212CardBusb/g
Sony PCWA-C500AR5210CardBusa
Sony PCWA-C700AR5212CardBusa/b
Ubiquiti SRCAR5213CardBusa/b/g

-

-

-

-

-  
ath%d: unable to attach hardware; HAL status %u

-  
The Atheros Hardware Access Layer was unable to configure the hardware as
-      requested. The status code is explained in the HAL include file
-      contrib/sys/dev/ic/athhal.h.

-  
ath%d: failed to allocate descriptors: %d

-  
The driver was unable to allocate contiguous memory for the transmit and
-      receive descriptors. This usually indicates system memory is scarce and/or
-      fragmented.

-  
ath%d: unable to setup a data xmit queue!

-  
The request to the HAL to setup the transmit queue for normal data frames
-      failed. This should not happen.

-  
ath%d: unable to setup a beacon xmit queue!

-  
The request to the HAL to setup the transmit queue for 802.11 beacon
-      frames failed. This should not happen.

-  
ath%d: 802.11 address: %s

-  
The MAC address programmed in the EEPROM is displayed.

-  
ath%d: hardware error; resetting

-  
An unrecoverable error in the hardware occurred. Errors of this sort
-      include unrecoverable DMA errors. The driver will reset the hardware and
-      continue.

-  
ath%d: rx FIFO overrun; resetting

-  
The receive FIFO in the hardware overflowed before the data could be
-      transferred to the host. This typically occurs because the hardware ran
-      short of receive descriptors and had no place to transfer received data.
-      The driver will reset the hardware and continue.

-  
ath%d: unable to reset hardware; hal status %u

-  
The Atheros Hardware Access Layer was unable to reset the hardware as
-      requested. The status code is explained in the HAL include file
-      sys/external/isc/atheros_hal/dist/ah.h. This
-      should not happen.

-  
ath%d: unable to start recv logic

-  
The driver was unable to restart frame reception. This should not
-    happen.

-  
ath%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware and continue. This should not
-      happen.

-  
ath%d: bogus xmit rate 0x%x

-  
An invalid transmit rate was specified for an outgoing frame. The frame is
-      discarded. This should not happen.

-  
ath%d: ath_chan_set: unable to reset channel %u (%u MHz)

-  
The Atheros Hardware Access Layer was unable to reset the hardware when
-      switching channels during scanning. This should not happen.

-  
ath%d: unable to allocate channel table

-  
The driver was unable to allocate memory for the table used to hold the
-      set of available channels.

-  
ath%d: unable to collect channel list from hal

-  
A problem occurred while querying the HAL to find the set of available
-      channels for the device. This should not happen.

-  
ath%d: %s: %dM -> %dM (%d ok, %d err, %d retr)

-  
The driver's rate control algorithm changed the current rate for
-      transmitting frames. This message is temporarily enabled for normal use to
-      help in diagnosing and improving the rate control algorithm. The message
-      indicates the new and old transmit rates and the statistics it used to
-      decide on this change.

-  
ath%d: failed to enable memory mapping

-  
The driver was unable to enable memory-mapped I/O to the PCI device
-      registers. This should not happen.

-  
ath%d: failed to enable bus mastering

-  
The driver was unable to enable the device as a PCI bus master for doing
-      DMA. This should not happen.

-  
ath%d: cannot map register space

-  
The driver was unable to map the device registers into the host address
-      space. This should not happen.

-  
ath%d: could not map interrupt

-  
The driver was unable to allocate an IRQ for the device interrupt. This
-      should not happen.

-  
ath%d: could not establish interrupt

-  
The driver was unable to install the device interrupt handler. This should
-      not happen.

-

-

-

-

-
arp(4), cardbus(4),
-    ifmedia(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The ath device driver first appeared in
-    FreeBSD 5.2. It was ported to
-    NetBSD 2.0.

-

-

-

-
The ath driver was originally written by
-    Sam Leffler, and was ported to
-    NetBSD by David Young.

-

-

-

-
Different regulatory domains have different default channels for
-    adhoc mode. See ifconfig(8) for information on how to
-    change the channel. Different regulatory domains may not be able to
-    communicate with each other with 802.11a as different regulatory domains do
-    not necessarily have overlapping channels.

-
Revision A1 of the D-LINK DWL-G520 and DWL-G650 are based on an
-    Intersil PrismGT chip and are not supported by this driver.

-
Revision v2 of the Netgear WG311 is based on a Texas Instruments
-    ACX111 and is not supported by this driver.

-
Revision v3 of the Netgear WG311 is based on a Marvell Libertas
-    88W8335 and is not supported by this driver.

-

-

-

-
Performance in lossy environments is suboptimal. The algorithm
-    used to select the rate for transmitted packets is very simplistic. There is
-    no software retransmit; only hardware retransmit is used. Contributors are
-    encouraged to replace the existing rate control algorithm with a better one
-    (hint: all the information needed is available to the driver).

-
The driver does not fully enable power-save operation of the chip;
-    consequently power use is suboptimal.

-

-

-
-  
-    
-    
-  
-
May 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/athn.4 3.html b/static/netbsd/man4/athn.4 3.html
deleted file mode 100644
index 7fcf2c15..00000000
--- a/static/netbsd/man4/athn.4 3.html	
+++ /dev/null
@@ -1,331 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATHN(4)Device Drivers ManualATHN(4)

-

-

-

-
athn — Atheros
-    IEEE 802.11a/g/n wireless network device

-

-

-

-
athn* at cardbus?
-  

-  athn* at pci?
-  

-  athn* at uhub? port ?

-

-

-

-
The athn driver provides support for a
-    wide variety of Atheros 802.11n devices, ranging from the AR5008 up to the
-    AR9287.

-
The AR5008 (codenamed Owl) is the first generation of Atheros
-    802.11n solutions. It consists of two chips, a MAC/Baseband Processor and a
-    Radio-on-a-Chip. The MAC/Baseband Processor can be an AR5416 (PCI and
-    CardBus form factors) or an AR5418 (PCIe Mini Card form factor). The radio
-    can be an AR2122, AR2133, AR5122 or an AR5133 chip. The AR2122 chip operates
-    in the 2GHz spectrum and supports up to 2 transmit paths and 2 receiver
-    paths (2T2R). The AR2133 chip operates in the 2GHz spectrum and supports up
-    to 3 transmit paths and 3 receiver paths (3T3R). The AR5122 chip operates in
-    the 2GHz and 5GHz spectra and supports up to 2 transmit paths and 2 receiver
-    paths (2T2R). The AR5133 chip operates in the 2GHz and 5GHz spectra and
-    supports up to 3 transmit paths and 3 receiver paths (3T3R).

-
The AR9001 (codenamed Sowl) is a Mini-PCI 802.11n solution. It
-    consists of two chips, an AR9160 MAC/Baseband Processor and an AR9103 or
-    AR9106 Radio-on-a-Chip. The AR9103 chip operates in the 2GHz spectrum and
-    supports up to 3 transmit paths and 3 receiver paths (3T3R). The AR9106 chip
-    operates in the 2GHz and 5GHz spectra and supports up to 3 transmit paths
-    and 3 receiver paths (3T3R).

-
The AR9220, AR9223 and AR9280 (codenamed Merlin) are the first
-    generation of Atheros single-chip 802.11n solutions. The AR9220 and AR9223
-    exist in PCI and Mini-PCI form factors. The AR9280 exists in PCIe Mini Card
-    (XB92), half Mini Card (HB92) and USB 2.0 (AR9280+AR7010) form factors. The
-    AR9220 and AR9280 operate in the 2GHz and 5GHz spectra and support 2
-    transmit paths and 2 receiver paths (2T2R). The AR9223 operates in the 2GHz
-    spectrum and supports 2 transmit paths and 2 receiver paths (2T2R).

-
The AR9281 is a single-chip PCIe 802.11n solution. It exists in
-    PCIe Mini Card (XB91) and half Mini Card (HB91) form factors. It operates in
-    the 2GHz spectrum and supports 1 transmit path and 2 receiver paths
-  (1T2R).

-
The AR9285 (codenamed Kite) is a single-chip PCIe 802.11n solution
-    that targets the value PC market. It exists in PCIe half Mini Card (HB95)
-    form factor only. It operates in the 2GHz spectrum and supports a single
-    stream (1T1R). It can be combined with the AR3011 chip to form a combo
-    WiFi/Bluetooth device (WB195).

-
The AR9271 is a single-chip USB 2.0 802.11n solution. It operates
-    in the 2GHz spectrum and supports a single stream (1T1R).

-
The AR2427 is a single-chip PCIe 802.11b/g solution similar to the
-    other AR9280 solutions but with 802.11n capabilities removed. It exists in
-    PCIe Mini Card form factor only. It operates in the 2GHz spectrum.

-
The AR9227 and AR9287 are single-chip 802.11n solutions that
-    target mid-tier PCs. The AR9227 exists in PCI and Mini-PCI form factors. The
-    AR9287 exists in PCIe half Mini Card (HB97) and USB 2.0 (AR9287+AR7010) form
-    factors. They operate in the 2GHz spectrum and support 2 transmit paths and
-    2 receiver paths (2T2R).

-
The following table summarizes the supported chips and their
-    capabilities.

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
AR5008-2NG (AR5416+AR2122)2GHz2x2:2PCI/CardBus
AR5008-3NG (AR5416+AR2133)2GHz3x3:2PCI/CardBus
AR5008-2NX (AR5416+AR5122)2GHz/5GHz2x2:2PCI/CardBus
AR5008-3NX (AR5416+AR5133)2GHz/5GHz3x3:2PCI/CardBus
AR5008E-2NG (AR5418+AR2122)2GHz2x2:2PCIe
AR5008E-3NG (AR5418+AR2133)2GHz3x3:2PCIe
AR5008E-2NX (AR5418+AR5122)2GHz/5GHz2x2:2PCIe
AR5008E-3NX (AR5418+AR5133)2GHz/5GHz3x3:2PCIe
AR9001-2NG (AR9160+AR9103)2GHz2x2:2PCI
AR9001-3NG (AR9160+AR9103)2GHz3x3:2PCI
AR9001-3NX2 (AR9160+AR9106)2GHz/5GHz3x3:2PCI
AR92202GHz/5GHz2x2:2PCI
AR92232GHz2x2:2PCI
AR92802GHz/5GHz2x2:2PCIe
AR9280+AR70102GHz/5GHz2x2:2USB 2.0
AR92812GHz1x2:2PCIe
AR92852GHz1x1:1PCIe
AR92712GHz1x1:1USB 2.0
AR24272GHz1x1:1PCIe
AR92272GHz2x2:2PCI
AR92872GHz2x2:2PCIe
AR9287+AR70102GHz2x2:2USB 2.0

-
These are the modes the athn driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
Host AP

-  
In this mode the driver acts as an access point (base station) for other
-      cards.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The athn driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it. The
-    athn driver relies on the software 802.11 stack for
-    both encryption and decryption of data frames.

-
The transmit speed is user-selectable or can be adapted
-    automatically by the driver depending on the number of hardware transmission
-    retries.

-

-

-

-
For USB devices, the driver needs at least version 1.1 of the
-    following firmware files, which are loaded when an interface is
-  attached:

-

-

-

-  
/libdata/firmware/athn-ar7010

-  
 

-  
/libdata/firmware/athn-ar7010-11

-  
 

-  
/libdata/firmware/athn-ar9271

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    athn0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
dhcp NONE NONE NONE nwkey 0x1deadbeef1 chan 11

-

-
The following ifconfig.if(5) example creates a
-    host-based access point on boot:

-

-
inet 192.168.1.1 255.255.255.0 NONE media autoselect \
-	mediaopt hostap nwid my_net chan 11

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig athn0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
athn%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-  
athn%d: radio is disabled by hardware switch

-  
The radio transmitter is off and thus no packet can go out. The driver
-      will reset the hardware. Make sure the laptop radio switch is on.

-  
athn%d: radio switch turned off

-  
The radio switch has been turned off while the interface was up and
-      running. The driver will turn the interface down.

-  
athn%d: error %d, could not read firmware %s

-  
For some reason, the driver was unable to read the firmware file from the
-      filesystem. The file might be missing or corrupted.

-

-

-

-

-
arp(4), cardbus(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    usb(4), ifconfig.if(5),
-    ifconfig(8)

-

-

-

-
The athn driver first appeared in
-    OpenBSD 4.7. Support for USB 2.0 devices first
-    appeared in OpenBSD 4.9. It was later ported to
-    NetBSD 7.0.

-

-

-

-
The athn driver was written by
-    Damien Bergamini
-    <damien@openbsd.org>
-    based on source code licensed under the ISC released in 2008 by Atheros
-    Communications for Linux.

-

-

-

-
The athn driver does not support any of
-    the 802.11n capabilities offered by the adapters. Additional work is
-    required in ieee80211(9) before those features can be
-    supported.

-

-

-
-  
-    
-    
-  
-
July 31, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/atphy.4 4.html b/static/netbsd/man4/atphy.4 4.html
deleted file mode 100644
index 10b6011d..00000000
--- a/static/netbsd/man4/atphy.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATPHY(4)Device Drivers ManualATPHY(4)

-

-

-

-
atphy — Attansic
-    Technology F1 10/100/1000 Ethernet PHY

-

-

-

-
atphy* at mii?

-

-

-

-
The atphy driver supports the Attansic
-    Technology F1 10/100/1000 Ethernet PHY.

-

-

-

-
age(4), alc(4),
-    ifmedia(4), intro(4),
-    lii(4), mii(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
January 18, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/atppc.4 4.html b/static/netbsd/man4/atppc.4 4.html
deleted file mode 100644
index a9577af4..00000000
--- a/static/netbsd/man4/atppc.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATPPC(4)Device Drivers ManualATPPC(4)

-

-

-

-
atppc — driver for
-    AT-style parallel port chip sets

-

-

-

-
atppc* at acpi?
-  

-  atppc* at isa? port 0x378 irq 7 drq 3 flags 0x00
-  

-  atppc* at isapnp?
-  

-  atppc* at ofisa?
-  

-  atppc* at pnpbios? index ?
-  

-  atppc* at puc? port ?
-  

-  options ATPPC_VERBOSE
-  

-  options ATPPC_DEBUG

-

-

-

-
atppc supports parallel ports and provides
-    the low level support needed by higher level drivers such as
-    ppbus(4). This driver attaches where the traditional
-    NetBSD lpt(4) driver would
-    ordinarily. It provides the data transport and chip set manipulation needed
-    by higher driver layers, such as ppbus(4) and
-    lpt(4). This driver is designed to be one of many possible
-    implementations supporting machine independent parallel device support via
-    ppbus(4).

-

-

-
atppc is intended to provide to data-link
-    like services to higher level IEEE 1284 device drivers (such as
-    ppbus(4)). atppc does not directly
-    support IEEE 1284 features such as mode negotiation but rather provides the
-    necessary infrastructure to allow a higher level driver to provide these
-    services.

-
atppc does provide chip set manipulation,
-    device handshakes (where appropriate), low-level error detection, and data
-    transfer.

-

-

-

-
atppc supports the following data transfer
-    modes: Centronics Compatible (Standard), Nibble, Byte (PS2), Fast
-    Centronics, ECP, and EPP. Standard and Fast Centronics modes are write only,
-    Nibble and Byte modes are read only, and ECP and EPP modes are
-    bidirectional.

-

-

-

-

-
acpi(4), i386/pnpbios(4),
-    isa(4), isapnp(4),
-    lpt(4), ofisa(4),
-    ppbus(4), puc(4)

-

-

-

-
The atppc driver is based on the
-    ppc driver, which originally appeared in
-    FreeBSD. The driver was ported over in
-    NetBSD 2.0.

-

-

-

-
This manual page is based on the FreeBSD
-    ppc manual page. The information has been updated
-    for the NetBSD port by Gary
-    Thorpe.

-

-

-

-
The FreeBSD driver includes support for
-    some specific chip sets, specifically detection of some non-standard device
-    I/O locations on the ISA bus. This support was not ported over to the
-    NetBSD version of the driver yet.

-

-

-
-  
-    
-    
-  
-
August 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/attimer.4 4.html b/static/netbsd/man4/attimer.4 4.html
deleted file mode 100644
index 801c41e7..00000000
--- a/static/netbsd/man4/attimer.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATTIMER(4)Device Drivers ManualATTIMER(4)

-

-

-

-
attimer — AT Timer
-    (8253) driver

-

-

-

-
attimer*	at acpi?
-  

-  attimer0	at isa?

-

-

-

-
The attimer driver handles the so-called
-    AT Timer device, initially found as chip model 8253. It is used as the main
-    counter for the clock on the i386 port, but also offers control over the
-    pitch of the PC speaker.

-
The attimer driver currently only
-    implements the access to the ISA register “TIMER1” which
-    controls the pitch of the PC speaker, and should be configured along with
-    pcppi(4) to be of any actual use.

-

-

-

-
acpi(4), isa(4),
-    pcppi(4)

-

-

-
-  
-    
-    
-  
-
March 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/atu.4 4.html b/static/netbsd/man4/atu.4 4.html
deleted file mode 100644
index a4d96122..00000000
--- a/static/netbsd/man4/atu.4 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATU(4)Device Drivers ManualATU(4)

-

-

-

-
atu — Atmel
-    at76c50x 802.11B wireless network interfaces

-

-

-

-
atu* at uhub? port ?

-

-

-

-
The atu driver provides support for
-    wireless network adapters based around the Atmel at76c503, at76c503a,
-    at76c505, and at76c505a USB chipsets.

-
Supported features include 802.11 and 802.3 frames, power
-    management, BSS, IBSS, ad-hoc, and host-based access point mode.

-
The atu driver encapsulates all IP and ARP
-    traffic as 802.11 frames, however it can receive either 802.11 or 802.3
-    frames. Transmit speed is selectable between 1Mbps fixed, 2Mbps fixed, 2Mbps
-    with auto fallback, 5.5Mbps, 8Mbps, or 11Mbps depending on your
-  hardware.

-
Four different radio chipsets are used along with the device, each
-    requiring a different firmware.

-
By default, the atu driver configures the
-    card for BSS operation (aka infrastructure mode). This mode requires the use
-    of an access point (base station).

-
For more information on configuring this device, see
-    ifconfig(8).

-
The following devices are among those supported by the
-    atu driver:

-

-

-

-  
Acer Peripherals AWL400

-  
 

-  
AcerP AWL-300

-  
 

-  
Aincomm AWU2000B

-  
 

-  
Atmel 2662W-V4

-  
 

-  
Atmel BW002

-  
 

-  
Atmel DWL-120

-  
 

-  
Atmel WL-1330

-  
 

-  
Belkin F5D6050

-  
 

-  
Geowave GW-US11S

-  
 

-  
Linksys WUSB11

-  
 

-  
Linksys WUSB11-V28

-  
 

-  
Ovislink AirLive

-  
 

-  
SMC 2662W-AR

-  
 

-

-

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    usb(4), ifconfig(8),
-    wiconfig(8)

-

-

-

-
The atu driver was written by
-    Daan Vreeken and ported to
-    OpenBSD by Theo de Raadt and
-    David Gwynne. The OpenBSD
-    driver was then ported to NetBSD by
-    Jesse Off ⟨joff@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
January 23, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/atw.4 3.html b/static/netbsd/man4/atw.4 3.html
deleted file mode 100644
index aa4737a8..00000000
--- a/static/netbsd/man4/atw.4 3.html	
+++ /dev/null
@@ -1,144 +0,0 @@
-
-  
-    
-    
-    
-  
-
ATW(4)Device Drivers ManualATW(4)

-

-

-

-
atw — ADMtek
-    ADM8211 802.11 wireless network driver

-

-

-

-
atw* at cardbus? function ?
-  

-  atw* at pci? dev ? function ?

-

-

-

-
The atw driver supports PCI/CardBus
-    802.11b wireless adapters based on the ADMtek ADM8211.

-
The ADM8211 is a bus-mastering 802.11 Media Access Controller
-    (MAC) which is derived from ADMtek's Tulip clones (see
-    tlp(4)). It supports contention-free traffic (with an
-    802.11 Point Coordinator), 64/128-bit WEP encryption, and 802.11
-    power-saving. The ADM8211 integrates an RF3000 baseband processor (BBP) by
-    RF Microdevices.

-
In a typical application, the ADM8211 is coupled with an RF
-    front-end by RFMD and a Silicon Laboratories Si4126 RF/IF synthesizer.

-
With the ADM8211, the division of labor between the host and NIC
-    is different than with firmware-based NICs such as an(4),
-    awi(4), and wi(4). The ADM8211 is still
-    responsible for real-time 802.11 functions such as sending ACK/RTS/CTS/ATIM
-    frames, sending beacons, and answering CF polls from the access point, but
-    the host takes responsibility for providing 802.11 functions such as
-    scanning, association, and authentication. The host is also responsible for
-    programming both the BBP and the RF/IF synthesizer.

-
atw contains incomplete support for the
-    ADM8211's WEP encryption/decryption engine. atw does
-    not yet support hardware WEP decryption, however, it will use the ADM8211's
-    crypto engine to encrypt transmitted frames. Documentation from ADMtek
-    claims that, in addition to the 4 128-bit shared WEP keys, the ADM8211 will
-    store WEP key pairs for up to 20 peers. The documentation provides no
-    details, hence atw does not support the 20
-    key-pairs.

-
The ADM8211 operates in 802.11 infrastructure mode (with an access
-    point) and in 802.11 ad hoc mode (without an access point) at 1, 2, 5.5, and
-    11Mbps. ADMtek says that the ADM8211 cannot operate as an access point.

-
The operating mode is selected using the
-    ifconfig(8) utility. For more information on configuring
-    this device, see ifconfig(8) and
-    ifmedia(4).

-

-

-

-
Cards supported by the atw driver
-  include:

-

-
    
-  
  • D-Link DWL-650 Rev. ?? CardBus card
    • 
-  
  • D-Link DWL-520 Rev. C1 PCI card
    • 
-  
  • LanReady WP2000 PCI card
    • 
-  
  • TrendNet TEW-221PC CardBus card
    • 
-  
  • Xterasys XN2511B PCI card
    • 
-  
  • 
-

-

-

-

-

-  
atw0: failed to tune channel %d

-  
The driver failed to tune the radio to a new channel. The radio remains
-      tuned to the old channel.

-  
atw0: atw_si4136_write wrote %08x, SYNCTL still busy

-  
The driver waited 100ms without seeing an indication that the ADM8211 had
-      finished writing a register on the Si4126 RF/IF synthesizer.

-  
atw0: device timeout

-  
The ADM8211 failed to generate an interrupt to acknowledge a transmit
-      command.

-

-

-

-

-
arp(4), cardbus(4),
-    ifmedia(4), netintro(4),
-    pci(4), ifconfig(8)

-
ADMtek,
-    http://www.admtek.com.tw.

-
Silicon Laboratories,
-    https://www.silabs.com.

-
RF Microdevices,
-    http://www.rfmd.com.

-

-

-

-
The atw device driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The atw driver was written by
-    David Young ⟨dyoung@NetBSD.org⟩. For
-    features which the ADM8211 has in common with the DECchip 21x4x, code was
-    liberally borrowed from tlp(4) by Jason
-    Thorpe ⟨thorpej@NetBSD.org⟩.

-

-

-

-
The author does not fully understand what processing the duration
-    fields for the PLCP header and the 802.11 header undergo before they are
-    applied to a transmitted frame. If the duration fields in transmitted frames
-    are incorrect, the performance of your network may suffer.

-
The driver does not provide rate control when the media type is
-    set to autoselect.

-
The driver lets you change to hostap mode, but it does not work
-    and it probably never will.

-
The driver will sometimes complain that it cannot re-tune the
-    radio because the transmit process has not gone idle. The author is
-    investigating.

-
Many features are still missing, especially WEP decryption and
-    802.11 power-saving.

-
The ad hoc mode has not been rigorously tested. IBSSs with the
-    same SSID may not coalesce, but this should not matter for most
-    applications.

-
The driver is untested in the ad-hoc demo mode of Lucent WaveLAN
-    cards.

-
The ADM8211 supports 802.11 power-saving, however,
-    atw does not support it yet. For time-bounded
-    service, the ADM8211 will interoperate with an access point which implements
-    the 802.11 Point Coordination Function, however, this is also not
-  supported.

-
Combinations of an ADM8211 with either an Intersil or a Marvell RF
-    front-end are not supported.

-

-

-
-  
-    
-    
-  
-
June 5, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/auacer.4 4.html b/static/netbsd/man4/auacer.4 4.html
deleted file mode 100644
index cd3fb457..00000000
--- a/static/netbsd/man4/auacer.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUACER(4)Device Drivers ManualAUACER(4)

-

-

-

-
auacer — Acer Labs
-    I/O Controller Hub integrated AC'97 audio device driver

-

-

-

-
auacer* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The auacer device driver supports the
-    M5455 integrated AC'97 audio controller of some Acer Labs I/O Controller
-    Hub.

-

-

-

-
ac97(4), audio(4),
-    pci(4)

-

-

-

-
The auacer device driver first appeared in
-    NetBSD 3.0.

-

-

-

-
No input supported (yet).

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/aubtfwl.4 3.html b/static/netbsd/man4/aubtfwl.4 3.html
deleted file mode 100644
index 8a3ce1ae..00000000
--- a/static/netbsd/man4/aubtfwl.4 3.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUBTFWL(4)Device Drivers ManualAUBTFWL(4)

-

-

-

-
aubtfwl — Atheros
-    AR3011/AR3012 Firmware Loader

-

-

-

-
aubtfwl* at uhub?

-

-

-

-
The aubtfwl driver manages automatic
-    loading of firmware on the Atheros AR3011 and AR3012 Bluetooth chipsets. The
-    firmware files should be obtained and placed in a
-    ubt/ directory in the search path of the
-    firmload(9) kernel subsystem. Upon attachment, the
-    aubtfwl driver will load the necessary firmware
-    files and the device will detach and reattach as a generic Bluetooth device
-    using the ubt(4) driver.

-
For AR3011 chipsets, you will need the
-    ath3k-1.fw firmware file in
-    ubt/, and for AR3012 chipsets, the files
-    ar3k/AthrBT_*.dfu and
-    ar3k/ramps_*.dfu in
-    ubt/ar3k/.

-
The firmware files can be obtained from the Linux firmware git
-    repository at
-    https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git.

-

-

-

-
    
-  
  • ath3k-1.fw
    • 
-  
  • ar3k/AthrBT_*.dfu
    • 
-  
  • ar3k/ramps_*.dfu
    • 
-

-

-

-

-
bluetooth(4), ubt(4),
-    uhub(4), firmload(9)

-

-

-
-  
-    
-    
-  
-
May 9, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/audio.4 3.html b/static/netbsd/man4/audio.4 3.html
deleted file mode 100644
index 154e3177..00000000
--- a/static/netbsd/man4/audio.4 3.html	
+++ /dev/null
@@ -1,635 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUDIO(4)Device Drivers ManualAUDIO(4)

-

-

-

-
audio —
-    device-independent audio driver layer

-

-

-

-
#include
-    <sys/audioio.h>

-

-

-

-
The audio driver provides support for
-    various audio peripherals. It provides a uniform programming interface layer
-    above different underlying audio hardware drivers. The audio layer provides
-    full-duplex operation if the underlying hardware configuration supports
-  it.

-
There are four device files available for audio operation:
-    /dev/audio, /dev/sound,
-    /dev/audioctl, and
-    /dev/mixer.

-
/dev/audio and
-    /dev/sound are used for recording or playback of
-    digital samples.

-
/dev/mixer is used to manipulate volume,
-    recording source, or other audio mixer functions.

-
/dev/audioctl accepts the same
-    ioctl(2) operations as /dev/sound,
-    but no other operations. It can be opened at any time and can be used to
-    manipulate the audio device while it is in use.

-

-

-

-
When /dev/audio is opened, it
-    automatically sets the track to manipulate monaural 8-bit mu-law 8000Hz.
-    When /dev/sound is opened, it maintains the audio
-    format and pause/unpause state of the most recently opened track. In all
-    other respects /dev/audio and
-    /dev/sound are identical.

-
On a full-duplex device, reads and writes may operate concurrently
-    without interference.

-
On a half-duplex device, if there are any recording descriptors
-    already, opening with write mode will fail. Similarly, if there are any
-    playback descriptors already, opening with read mode will fail. If both
-    playback and recording are requested on a half-duplex device, it will be
-    treated as playback mode.

-
On either type of device, opening with write mode will start in
-    playback mode, opening with read mode will start in recording mode.

-
If the playback mode is paused then silence is played instead of
-    the provided samples, and if recording is paused then the process blocks in
-    read(2) until recording is unpaused.

-
If a writing process does not call write(2)
-    frequently enough to provide samples at the pace the hardware consumes them
-    silence is inserted. If a reading process does not call
-    read(2) frequently enough, it will simply miss
-  samples.

-
The audio driver supports track multiplexing. All sampling devices
-    can be opened at any time without interference. For playback, all tracks
-    opened simultaneously are mixed, even if their specified format is
-    different. For recording, recorded data is distributed to all opened tracks,
-    even if their specified format is different. To achieve this, the audio
-    driver has a small efficient encoding converter, a channel mixer, and a
-    frequency converter. The frequency conversion adapts the simplest way
-    (interpolation method for upward, and simple thinning method for downward)
-    due to restrictions in kernel resources and processing time. It will work
-    well in most cases but don't expect excessive quality.

-
The audio device is normally accessed with
-    read(2) or write(2) calls, but it can
-    also be mapped into user memory with mmap(2). Once the
-    device has been mapped it can no longer be accessed by read or write; all
-    access is by reading and writing to the mapped memory. The mmap'ped buffer
-    appears as a block of memory of size buffersize (as
-    available via AUDIO_GETINFO or
-    AUDIO_GETBUFINFO). The audio driver will
-    continuously move data from this buffer from/to the mixing buffer, wrapping
-    around at the end of the buffer. To find out where the hardware is currently
-    accessing data in the buffer the AUDIO_GETIOFFS and
-    AUDIO_GETOOFFS calls can be used. Note that
-    mmap(2) no longer maps hardware buffers directly. Now it
-    is achieved by emulation, so don't expect significant improvements over
-    normal write(2). For historical reasons, only encodings
-    that are not set AUDIO_ENCODINGFLAG_EMULATED are
-    able to mmap(2).

-
The audio device, like most devices, can be used in
-    select(2), can be set in non-blocking mode and can be set
-    (with a FIOASYNC ioctl) to send a
-    SIGIO when I/O is possible. The mixer device can be
-    set to generate a SIGIO whenever a mixer value is
-    changed.

-
The following ioctl(2) commands are supported on
-    the sample devices:

-

-  

-  
This command stops all playback and recording, clears all queued buffers,
-      resets error counters on this track, and restarts recording and playback
-      as appropriate for the current sampling mode.

-  

-  
 

-  

-  
This command fetches the count of dropped output (input) bytes into its
-      integer argument. There is no information regarding when in the sample
-      stream they were dropped.

-  

-  
This command fetches the count of bytes that are queued ahead of the first
-      sample in the most recent sample block written into its integer
-    argument.

-  

-  
This command suspends the calling process until all queued playback
-      samples have been played.

-  

-  
This command fetches the current hardware device information into the
-      audio_device_t argument.
-    

-    
typedef struct audio_device {
-        char name[MAX_AUDIO_DEV_LEN];
-        char version[MAX_AUDIO_DEV_LEN];
-        char config[MAX_AUDIO_DEV_LEN];
-} audio_device_t;

-    

-  

-  

-  
This command is used iteratively to fetch sample encoding names and format
-      IDs into the input/output audio_encoding_t argument. The encoding returned
-      by the command is the user-accessible encoding, not the hardware-supported
-      encoding.
-    

-    
typedef struct audio_encoding {
-	int index;      /* input: nth encoding */
-	char name[MAX_AUDIO_DEV_LEN]; /* name of encoding */
-	int encoding;   /* value for encoding parameter */
-	int precision;  /* value for precision parameter */
-	int flags;
-#define AUDIO_ENCODINGFLAG_EMULATED 1 /* software emulation mode */
-} audio_encoding_t;

-    

-    
To query all the supported encodings, start with an index
-        field of 0 and continue with successive encodings (1, 2, ...) until the
-        command returns an error.

-  

-  

-  
This command is obsolete.

-  

-  
This command is obsolete.

-  

-  
This command gets a bit set of hardware properties. If the hardware has a
-      certain property the corresponding bit is set, otherwise it is not. The
-      properties can have the following values:
-    

-    

-      

-      
the device admits full duplex operation.

-      

-      
the device can be used with mmap(2).

-      

-      
the device can set the playing and recording encoding parameters
-          independently.

-      

-      
the device is capable of audio playback.

-      

-      
the device is capable of audio capture.

-    

-  

-  

-  
 

-  

-  
This command fetches the current offset in the input(output) buffer where
-      the track mixer will be putting(getting) data. It mostly useful when the
-      device buffer is available in user space via the mmap(2)
-      call. The information is returned in the
-      audio_offset_t structure.
-    

-    
typedef struct audio_offset {
-	u_int	samples;   /* Total number of bytes transferred */
-	u_int	deltablks; /* Blocks transferred since last checked */
-	u_int	offset;    /* Physical transfer offset in buffer */
-} audio_offset_t;

-    

-  

-  

-  
 

-  

-  
 

-  

-  
Get or set audio information as encoded in the audio_info structure. For
-      historical reasons, the audio_info structure has three different layer's
-      parameters: track, track mixer, and hardware rich mixer.
-    

-    
typedef struct audio_info {
-	struct	audio_prinfo play;   /* info for play (output) side */
-	struct	audio_prinfo record; /* info for record (input) side */
-        u_int	monitor_gain;			/* input to output mix [HWmixer] */
-	/* BSD extensions */
-	u_int	blocksize;	/* read/write block size [track] */
-	u_int	hiwat;		/* output high water mark [track] */
-	u_int	lowat;		/* output low water mark [track] */
-	u_int	_ispare1;
-	u_int	mode;		/* current operation mode [track] */
-#define AUMODE_PLAY	0x01
-#define AUMODE_RECORD	0x02
-#define AUMODE_PLAY_ALL 0x04	/* Not used anymore */
-} audio_info_t;

-    

-    
When setting the current state with
-        AUDIO_SETINFO, the audio_info structure should
-        first be initialized with
-        AUDIO_INITINFO(&info) and then the
-        particular values to be changed should be set. This allows the audio
-        driver to only set those things that you wish to change and eliminates
-        the need to query the device with AUDIO_GETINFO
-        or AUDIO_GETBUFINFO first.

-    
The mode field indicates current
-        operation mode, either one of AUMODE_PLAY or
-        AUMODE_RECORD. These two flags can not be
-        changed once this descriptor is opened. For playback mode, the obsolete
-        AUMODE_PLAY_ALL flag can be set but has no
-        effect.

-    
hiwat and lowat
-        are used to control write behavior. Writes to the audio devices will
-        queue up blocks until the high-water mark is reached, at which point any
-        more write calls will block until the queue is drained to the low-water
-        mark. hiwat and lowat set
-        those high- and low-water marks (in audio blocks). The default for
-        hiwat is the maximum value and for
-        lowat 75% of hiwat.

-    
blocksize sets the
-        current audio blocksize. The generic audio driver layer and the hardware
-        driver have the opportunity to adjust this block size to get it within
-        implementation-required limits. Normally the
-        blocksize is calculated to correspond to the value
-        of the
-        
-        sysctl and is recalculated when the encoding parameters change. If the
-        descriptor is opened for read only, blocksize
-        indicates the blocksize for the recording track. Otherwise,
-        blocksize indicates the blocksize for the playback
-        track.

-    

-    
struct audio_prinfo {
-	u_int	sample_rate;	/* sample rate in samples/s [track] */
-	u_int	channels;	/* number of channels, usually 1 or 2 [track] */
-	u_int	precision;	/* number of bits/sample [track] */
-	u_int	encoding;	/* data encoding (AUDIO_ENCODING_* below) [track] */
-	u_int	gain;		/* volume level [HWmixer] */
-	u_int	port;		/* selected I/O port [HWmixer] */
-	u_long	seek;		/* BSD extension [track] */
-	u_int	avail_ports;	/* available I/O ports [HWmixer] */
-	u_int	buffer_size;	/* total size audio buffer [track] */
-	u_int	_ispare[1];
-	u_int	samples;	/* number of samples [track] */
-	u_int	eof;		/* End Of File (zero-size writes) counter [track] */
-	u_char	pause;		/* non-zero if paused, zero to resume [track] */
-	u_char	error;		/* non-zero if underflow/overflow occurred [track] */
-	u_char	waiting;	/* non-zero if another process hangs in open [track] */
-	u_char	balance;	/* stereo channel balance [HWmixer] */
-	u_char	cspare[2];
-	u_char	open;		/* non-zero if currently open [trackmixer] */
-	u_char	active;		/* non-zero if I/O is currently active [trackmixer] */
-};

-    

-    
Note: many hardware audio drivers require identical playback
-        and recording sample rates, sample encodings, and channel counts. The
-        playing information is always set last and will prevail on such
-        hardware. If the hardware can handle different settings the
-        AUDIO_PROP_INDEPENDENT property is set.

-    
The encoding parameter can have the following values:

-    

-    

-      

-      
mu-law encoding, 8 bits/sample

-      

-      
A-law encoding, 8 bits/sample

-      

-      
two's complement signed linear encoding with the platform byte
-        order

-      

-      
unsigned linear encoding with the platform byte order

-      

-      
ADPCM encoding, 8 bits/sample

-      

-      
two's complement signed linear encoding with little endian byte
-        order

-      

-      
two's complement signed linear encoding with big endian byte
-        order

-      

-      
unsigned linear encoding with little endian byte order

-      

-      
unsigned linear encoding with big endian byte order

-      

-      
Dolby Digital AC3

-    

-    
The audio driver accepts the following
-        formats. encoding and
-        precision are one of the values obtained by
-        AUDIO_GETENC, regardless of formats supported by
-        underlying driver. frequency ranges from 1000Hz to
-        192000Hz, regardless of frequency (ranges) supported by underlying
-        driver. channels depends your underlying driver.
-        If the underlying driver only supports monaural (1 channel) or stereo (2
-        channels), you can specify 1 or 2 regardless of number of channels
-        supported by underlying driver. If the underlying driver supports three
-        or more channels, you can specify the number of channels supported by
-        the underlying driver or fewer.

-    
The gain, port and
-        balance settings provide simple shortcuts to the
-        richer mixer interface described below and are not obtained by
-        AUDIO_GETBUFINFO. The gain should be in the
-        range [AUDIO_MIN_GAIN,
-        AUDIO_MAX_GAIN] and the balance in the range
-        [AUDIO_LEFT_BALANCE,
-        AUDIO_RIGHT_BALANCE] with the normal setting at
-        AUDIO_MID_BALANCE.

-    
The input port should be a combination of:

-    

-    

-      

-      
to select microphone input.

-      

-      
to select line input.

-      

-      
to select CD input.

-    

-    
The output port should be a combination of:

-    

-    

-      

-      
to select speaker output.

-      

-      
to select headphone output.

-      

-      
to select line output.

-    

-    
The available ports can be found in
-        avail_ports
-        (AUDIO_GETBUFINFO only).

-    
buffer_size is the total size of the
-        audio buffer. The buffer size divided by the
-        blocksize gives the maximum value for
-        hiwat. Currently the
-        buffer_size can only be read and not set.

-    
The seek and
-        samples fields are only used by
-        AUDIO_GETINFO and
-        AUDIO_GETBUFINFO. seek
-        represents the count of bytes pending; samples
-        represents the total number of bytes recorded or played, less those that
-        were dropped due to inadequate consumption/production rates.

-    
pause returns the current pause/unpause
-        state for recording or playback. For
-        AUDIO_SETINFO, if the pause value is specified
-        it will either pause or unpause the particular direction.

-  

-  

-  
This command enumerates formats supported by the hardware. Similarly to
-      AUDIO_GETENC, to query all the supported formats,
-      start with an index field of 0 and continue with successive formats (1, 2,
-      ...) until the command returns an error.
-    

-    
typedef struct audio_format_query {
-	u_int	index;
-	struct audio_format fmt;
-} audio_format_query_t;

-    

-  

-  

-  
This command fetches the current hardware format. Only the following
-      members in audio_info_t are used. Members which are not listed here or
-      belong in invalid direction are filled by -1.
-    
    
-      
  • mode
    • 
-      
  • play.encoding
    • 
-      
  • play.precision
    • 
-      
  • play.channels
    • 
-      
  • play.sample_rate
    • 
-      
  • record.encoding
    • 
-      
  • record.precision
    • 
-      
  • record.channels
    • 
-      
  • record.sample_rate
    • 
-    

-    
mode indicates which direction is
-      valid.

-  

-  

-  
This command sets the hardware format. It will fail if there are any
-      opened descriptors. So obviously, it must be issued on
-      /dev/audioctl. Similarly to
-      AUDIO_GETFORMAT, only above members in
-      audio_info_t are used. Members which is not listed or belong in invalid
-      direction are ignored. The parameters can be chosen from the choices
-      obtained by AUDIO_QUERYFORMAT.

-  

-  
This command is obsolete.

-  

-  
This command is obsolete.

-

-

-

-

-
The mixer device, /dev/mixer, may be
-    manipulated with ioctl(2) but does not support
-    read(2) or write(2). It supports the
-    following ioctl(2) commands:

-

-  

-  
This command is the same as described above for the sampling devices.

-  

-  
 

-  

-  
These commands read the current mixer state or set new mixer state for the
-      specified device dev. type
-      identifies which type of value is supplied in the
-      mixer_ctrl_t argument.
-    

-    
#define AUDIO_MIXER_CLASS  0
-#define AUDIO_MIXER_ENUM   1
-#define AUDIO_MIXER_SET    2
-#define AUDIO_MIXER_VALUE  3
-typedef struct mixer_ctrl {
-	int dev;			/* input: nth device */
-	int type;
-	union {
-		int ord;		/* enum */
-		int mask;		/* set */
-		mixer_level_t value;	/* value */
-	} un;
-} mixer_ctrl_t;
-
-#define AUDIO_MIN_GAIN  0
-#define AUDIO_MAX_GAIN  255
-typedef struct mixer_level {
-        int num_channels;
-        u_char level[8];               /* [num_channels] */
-} mixer_level_t;
-#define AUDIO_MIXER_LEVEL_MONO  0
-#define AUDIO_MIXER_LEVEL_LEFT  0
-#define AUDIO_MIXER_LEVEL_RIGHT 1

-    

-    
For a mixer value, the value field
-        specifies both the number of channels and the values for each channel.
-        If the channel count does not match the current channel count, the
-        attempt to change the setting may fail (depending on the hardware device
-        driver implementation). Audio levels may be adjusted in increments of
-        the delta value returned by
-        AUDIO_MIXER_DEVINFO. This field is optional for
-        hardware drivers to specify - devices with a delta of 0 may allow
-        arbitrary adjustment of levels.

-    
For an enumeration value, the ord field
-        should be set to one of the possible values as returned by a prior
-        AUDIO_MIXER_DEVINFO command.

-    
The type AUDIO_MIXER_CLASS is only
-        used for classifying particular mixer device types and is not used for
-        AUDIO_MIXER_READ or
-        AUDIO_MIXER_WRITE.

-  

-  

-  
This command is used iteratively to fetch audio mixer device information
-      into the input/output mixer_devinfo_t argument. To
-      query all the supported devices, start with an index field of 0 and
-      continue with successive devices (1, 2, ...) until the command returns an
-      error.
-    

-    
typedef struct mixer_devinfo {
-	int index;		/* input: nth mixer device */
-	audio_mixer_name_t label;
-	int type;
-	int mixer_class;
-	int next, prev;
-#define AUDIO_MIXER_LAST	-1
-	union {
-		struct audio_mixer_enum {
-			int num_mem;
-			struct {
-				audio_mixer_name_t label;
-				int ord;
-			} member[32];
-		} e;
-		struct audio_mixer_set {
-			int num_mem;
-			struct {
-				audio_mixer_name_t label;
-				int mask;
-			} member[32];
-		} s;
-		struct audio_mixer_value {
-			audio_mixer_name_t units;
-			int num_channels;
-			int delta;
-		} v;
-	} un;
-} mixer_devinfo_t;

-    

-    
The label field identifies the name of
-        this particular mixer control. The index field may
-        be used as the dev field in
-        AUDIO_MIXER_READ and
-        AUDIO_MIXER_WRITE commands. The
-        type field identifies the type of this mixer
-        control. Enumeration types are typically used for on/off style controls
-        (e.g., a mute control) or for input/output device selection (e.g.,
-        select recording input source from CD, line in, or microphone). Set
-        types are similar to enumeration types but any combination of the mask
-        bits can be used.

-    
The mixer_class field identifies what
-        class of control this is. The (arbitrary) value set by the hardware
-        driver may be determined by examining the
-        mixer_class field of the class itself, a mixer of
-        type AUDIO_MIXER_CLASS. For example, a mixer
-        controlling the input gain on the line in circuit would have a
-        mixer_class that matches an input class device
-        with the name “inputs”
-        (AudioCinputs), and would have a
-        label of “line”
-        (AudioNline). Mixer controls which control audio
-        circuitry for a particular audio source (e.g., line-in, CD in, DAC
-        output) are collected under the input class, while those which control
-        all audio sources (e.g., master volume, equalization controls) are under
-        the output class. Hardware devices capable of recording typically also
-        have a record class, for controls that only affect recording, and also a
-        monitor class.

-    
The next and prev
-        may be used by the hardware device driver to provide hints for the next
-        and previous devices in a related set (for example, the line in level
-        control would have the line in mute as its “next” value).
-        If there is no relevant next or previous value,
-        AUDIO_MIXER_LAST is specified.

-    
For AUDIO_MIXER_ENUM mixer control
-        types, the enumeration values and their corresponding names are filled
-        in. For example, a mute control would return appropriate values paired
-        with AudioNon and
-        AudioNoff. For
-        AUDIO_MIXER_VALUE and
-        AUDIO_MIXER_SET mixer control types, the channel
-        count is returned; the units name specifies what the level controls
-        (typical values are AudioNvolume,
-        AudioNtreble,
-        AudioNbass).

-  

-

-
By convention, all the mixer devices can be distinguished from
-    other mixer controls because they use a name from one of the
-    AudioC* string values.

-

-

-

-

-  
/dev/audio

-  
 

-  
/dev/audioctl

-  
 

-  
/dev/sound

-  
 

-  
/dev/mixer

-  
 

-

-

-

-

-
audiocfg(1), audioctl(1),
-    audioplay(1), audiorecord(1),
-    mixerctl(1), ioctl(2),
-    ossaudio(3), acorn32/vidcaudio(4),
-    arcofi(4), aria(4),
-    auacer(4), audiocs(4),
-    auich(4), auixp(4),
-    autri(4), auvia(4),
-    bba(4), btsco(4),
-    clcs(4), clct(4),
-    cmpci(4), dreamcast/aica(4),
-    eap(4), emuxki(4),
-    esa(4), esm(4),
-    eso(4), ess(4),
-    fms(4), gcscaudio(4),
-    gus(4), guspnp(4),
-    hdafg(4), hdaudio(4),
-    hppa/harmony(4), macppc/awacs(4),
-    macppc/snapper(4), midi(4),
-    neo(4), pad(4),
-    pas(4), radio(4),
-    sb(4), sgimips/haltwo(4),
-    sgimips/mavb(4), sparc/audioamd(4),
-    sparc/dbri(4), sv(4),
-    uaudio(4), wss(4),
-    x68k/vs(4), yds(4),
-    ym(4)

-

-

-

-
Support for virtual channels and mixing first appeared in
-    NetBSD 8.0.

-

-

-

-
If the device is used in mmap(2) it is currently
-    always mapped for writing (playing) due to VM system weirdness.

-

-

-
-  
-    
-    
-  
-
May 27, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/audiocs.4 4.html b/static/netbsd/man4/audiocs.4 4.html
deleted file mode 100644
index 85244691..00000000
--- a/static/netbsd/man4/audiocs.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUDIOCS(4)Device Drivers ManualAUDIOCS(4)

-

-

-

-
audiocs — Crystal
-    Semiconductor CS4231 audio device driver

-

-

-

-
audiocs0 at sbus0 slot ? offset ?
-  

-  audiocs0 at ebus?
-  

-  audio* at audiobus?

-

-

-

-
The audiocs driver provides support for
-    the CS4231 audio devices on the EBus and SBus buses in sparc and sparc64
-    machines.

-

-

-

-
audio(4), ebus(4),
-    sbus(4)

-

-

-

-
Mixer “outputs” class
-    (AudioCoutputs) is not yet supported.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/aue.4 4.html b/static/netbsd/man4/aue.4 4.html
deleted file mode 100644
index a50d04e1..00000000
--- a/static/netbsd/man4/aue.4 4.html	
+++ /dev/null
@@ -1,145 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUE(4)Device Drivers ManualAUE(4)

-

-

-

-
aue — ADMtek AN986
-    and AN8511 Pegasus USB Ethernet driver

-

-

-

-
aue* at uhub?
-  

-  ukphy* at mii?

-

-

-

-
The aue driver supports the following
-    adapters:

-

-

-

-  
@Home USB 10/100

-  
 

-  
Abocom DSB650TX

-  
 

-  
Billionton Systems USB100

-  
 

-  
Compaq HNE-200

-  
 

-  
Corega FEther USB-TX

-  
 

-  
Corega FEther USB-TXS

-  
 

-  
D-Link DSB-650

-  
 

-  
D-Link DSB-650TX

-  
 

-  
D-Link DSB-650TX-PNA

-  
 

-  
I/O DATA USB ET/TX

-  
 

-  
I/O DATA USB ET/TXS

-  
 

-  
I/O DATA ETX-US2

-  
 

-  
Hawking UF100

-  
 

-  
Kingston KNU101TX

-  
 

-  
LinkSys USB100TX

-  
 

-  
LinkSys USB100H1

-  
 

-  
LinkSys USB10TA

-  
 

-  
Melco Inc. LU-ATX

-  
 

-  
Microsoft MN110

-  
 

-  
SOHOware NUB100

-  
 

-  
SMC 2202USB

-  
 

-  
SMC 2206USB/ETH

-  
 

-

-

-

-

-

-
The aue driver provides support for USB
-    Ethernet adapters based on the ADMtek AN986 Pegasus and AN8511 Pegasus II
-    chipsets.

-
The Pegasus contains a 10/100 Ethernet MAC with MII interface and
-    is designed to work with both Ethernet and HomePNA transceivers. Although
-    designed to interface with 100Mbps peripherals, the existing USB standard
-    specifies a maximum transfer speed of 12Mbps. Users should therefore not
-    expect to actually achieve 100Mbps speeds with these devices.

-
The Pegasus supports a 64-bit multicast hash table, single perfect
-    filter entry for the station address and promiscuous mode. Packets are
-    received and transmitted over separate USB bulk transfer endpoints.

-
The aue driver supports the following
-    media types:

-

-  
autoselect

-  
Enable automatic selection of the media type and options. The user can
-      manually override the automatically selected mode by adding media options
-      to the /etc/rc.conf file.

-  
10baseT/UTP

-  
Set 10Mbps operation. The mediaopt option can also
-      be used to enable full-duplex operation. Not
-      specifying full duplex implies
-      half-duplex mode.

-  
100baseTX

-  
Set 100Mbps (fast Ethernet) operation. The mediaopt
-      option can also be used to enable full-duplex
-      operation. Not specifying full duplex implies
-      half-duplex mode.

-

-
The aue driver supports the following
-    media options:

-

-  
full-duplex

-  
Force full duplex operation. The interface will operate in half duplex
-      mode if this media option is not specified.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), netintro(4),
-    usb(4), usbnet(4),
-    ifconfig(8)

-
ADMtek AN986 data sheet,
-    http://www.admtek.com.tw.

-

-

-

-
The aue device driver first appeared in
-    FreeBSD 4.0, and in NetBSD
-    1.5.

-

-

-

-
The aue driver was written by
-    Bill Paul ⟨wpaul@ee.columbia.edu⟩.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/auich.4 4.html b/static/netbsd/man4/auich.4 4.html
deleted file mode 100644
index 1ee5ec74..00000000
--- a/static/netbsd/man4/auich.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUICH(4)Device Drivers ManualAUICH(4)

-

-

-

-
auich — Intel I/O
-    Controller Hub integrated AC'97 audio device driver

-

-

-

-
auich* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The auich device driver supports the
-    integrated AC'97 audio controller of the Intel I/O Controller Hub. Supported
-    chipsets include the i82801AA (ICH), i82801AB (ICH0), i82801BA (ICH2),
-    i82440MX, i82801CA (ICH3), i82801DB (ICH4), i82801EB (ICH5), i82801FB
-    (ICH6), i82801GB/GR (ICH7), and Intel 6300ESB. The driver also supports SiS
-    7012, nForce MCP, nForce2 MCP-T, nForce3 MCP-T, nForce3 250 MCP-T, nForce4,
-    and AMD 8111.

-
The driver provides the following sysctl(8)
-    read/write variable (when hardware support is available):

-

-  
hw.auich0.ac97rate

-  
Link rate of the device in Hz. The driver automatically measures and
-      calculates the correct rate so you usually don't need to change this.
-      There is, however, a chance that the driver miscalculates the rate
-      especially on an emulated hardware, resulting in an incorrect playback
-      pitch. When this happens you need to manually set this variable to the
-      correct value. Try 48000 if you don't know the
-      correct value as it is the default link rate.

-

-

-

-

-
ac97(4), audio(4),
-    pci(4), sysctl(8)

-

-

-

-
The auich device driver appeared in
-    NetBSD 1.6.

-

-

-

-
The ‘microphone’ input DMA channel is not currently
-    supported.

-

-

-
-  
-    
-    
-  
-
October 13, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/auixp.4 4.html b/static/netbsd/man4/auixp.4 4.html
deleted file mode 100644
index 1e00a106..00000000
--- a/static/netbsd/man4/auixp.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUIXP(4)Device Drivers ManualAUIXP(4)

-

-

-

-
auixp — ATI IXP
-    series integrated AC'97 audio device driver

-

-

-

-
auixp* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The auixp device driver supports the
-    integrated AC'97 audio controller of the ATP IXP series I/O controller hub.
-    Supported models include all the chips that have IXP-200 base functionality
-    for codec communication and DAC/ADC DMA support.

-

-

-

-
ac97(4), audio(4),
-    pci(4)

-

-

-

-
The auixp device driver appeared in
-    NetBSD 2.1.

-

-

-

-
The ‘SPDIF’ support is still rudimentary and not
-    supported other than through the codec. ‘Quadrophonic’ and
-    ‘Dolby 5.1’ audio are supported but untested.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/autri.4 4.html b/static/netbsd/man4/autri.4 4.html
deleted file mode 100644
index 5675b40e..00000000
--- a/static/netbsd/man4/autri.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTRI(4)Device Drivers ManualAUTRI(4)

-

-

-

-
autri — Trident
-    4DWAVE-DX/NX, SiS 7018, ALi M5451 audio device driver

-

-

-

-
autri* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  midi* at autri?

-

-

-

-
The autri device driver supports the AC'97
-    audio controller found in Trident 4DWAVE-DX/NX, SiS 7018 and ALi M5451.

-

-

-

-
ac97(4), audio(4),
-    midi(4), pci(4)

-

-

-

-
The autri device driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/auvia.4 4.html b/static/netbsd/man4/auvia.4 4.html
deleted file mode 100644
index f598e9b0..00000000
--- a/static/netbsd/man4/auvia.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUVIA(4)Device Drivers ManualAUVIA(4)

-

-

-

-
auvia — VIA
-    VT82C686A/VT8233/VT8235/VT8237 integrated AC'97 audio device
-  driver

-

-

-

-
auvia* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The auvia device driver supports the
-    integrated AC'97 audio controller of the VIA Technologies
-    VT82C686A/VT8233/VT8235/VT8237 Southbridge chip found on some
-  motherboards.

-

-

-

-
ac97(4), audio(4),
-    pci(4)

-

-

-

-
The auvia driver was originally written by
-    Tyler C. Sarna for NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/auvitek.4 4.html b/static/netbsd/man4/auvitek.4 4.html
deleted file mode 100644
index dc8e0a5f..00000000
--- a/static/netbsd/man4/auvitek.4 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUVITEK(4)Device Drivers ManualAUVITEK(4)

-

-

-

-
auvitek — Auvitek
-    AU0828 video capture device driver

-

-

-

-
auvitek* at uhub?
-  

-  dtv* at dtvbus?
-  

-  video* at videobus?
-  

-  uaudio* at auvitek?
-  

-  audio* at uaudio?

-

-

-

-
The auvitek driver provides support for
-    USB video capture devices based on the Auvitek AU0828 bridge. This hybrid
-    analog/digital device requires a hi-speed USB host controller (such as
-    ehci(4)) to function properly.

-
For auvitek devices with analog audio
-    capture interfaces, the uaudio(4) device driver provides
-    access to the audio stream. Application software can find a
-    video(4) device's audio(4) device by
-    comparing the VIDIOC_QUERYCAP
-    bus_info field with the audio device's
-    AUDIO_GETDEV config field.

-
The following cards are supported by the
-    auvitek driver:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
Hauppauge WinTV-HVR-850au8522(4)xc5k(4)
Hauppauge WinTV-HVR-950Qau8522(4)xc5k(4)

-
Cards with an XC5000 tuner require the firmware provided by the
-    pkgsrc/sysutils/xc5k-firmware package to function
-    properly.

-

-

-

-
audio(4), dtv(4),
-    dtviic(4), ehci(4),
-    uaudio(4), video(4)

-
pkgsrc/sysutils/xc5k-firmware

-

-

-

-
The auvitek device driver appeared in
-    NetBSD 6.0.

-

-

-

-
The auvitek driver was written by
-    Jared D. McNeill
-    ⟨jmcneill@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
August 30, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/awi.4 3.html b/static/netbsd/man4/awi.4 3.html
deleted file mode 100644
index 60928eb1..00000000
--- a/static/netbsd/man4/awi.4 3.html	
+++ /dev/null
@@ -1,154 +0,0 @@
-
-  
-    
-    
-    
-  
-
AWI(4)Device Drivers ManualAWI(4)

-

-

-

-
awi — AMD
-    PCnetMobile IEEE 802.11 PCMCIA wireless network driver

-

-

-

-
awi* at pcmcia? function ?

-

-

-

-
The awi driver supports various IEEE
-    802.11 wireless cards that run AMD PCnetMobile firmware based on the AMD
-    79c930 controller with the Intersil (formerly Harris) PRISM radio chipset.
-    It provides access to 32kb of memory shared between the controller and the
-    host. All host/device interaction is accomplished via this shared memory,
-    which can be accessed either via PCMCIA or I/O memory spaces. The
-    awi driver encapsulates all IP and ARP traffic in
-    802.11 frames.

-
The driver works both in infrastructure mode and in ad-hoc
-    (independent BSS) mode.

-
In infrastructure mode, it communicates with an Access Point,
-    which serves as a link-layer bridge between an Ethernet segment and the
-    wireless network. An access point also provides roaming capability, which
-    allows a wireless node to move between access points.

-
In ad-hoc mode, the device communicates peer to peer. Although it
-    is more efficient to communicate between wireless nodes, the coverage is
-    limited spatially due to the lack of roaming capability.

-
In addition to these two modes in the IEEE 802.11 specification,
-    the awi driver also supports a variant of ad-hoc
-    mode outside of the spec for DS radio cards. This makes it possible to
-    communicate with the WaveLAN ad-hoc mode of wi(4) driver.
-    The NWID has no effect in this mode.

-
Another mode added to the awi driver can
-    be used with old Melco access points with 2Mbps cards. This mode actually
-    uses the IEEE 802.11 ad-hoc mode with encapsulation of raw Ethernet packets
-    (including headers) in 802.11 frames.

-
For more information on configuring this device, see
-    ifconfig(8) and ifmedia(4).

-

-

-

-
Cards supported by the awi driver
-  include:

-

-

-

-  
BayStack 650

-  
1Mbps Frequency Hopping PCCARD adapter

-  
BayStack 660

-  
2Mbps Direct Sequence PCCARD adapter

-  
Icom SL-200

-  
2Mbps Direct Sequence PCCARD adapter

-  
Melco WLI-PCM

-  
2Mbps Direct Sequence PCCARD adapter

-  
NEL SSMagic

-  
2Mbps Direct Sequence PCCARD adapter

-  
Netwave AirSurfer Plus

-  
1Mbps Frequency Hopping PCCARD adapter

-  
Netwave AirSurfer Pro

-  
2Mbps Direct Sequence PCCARD adapter

-  
Nokia C020 WLAN

-  
2Mbps Direct Sequence PCCARD adapter

-  
Farallon SkyLINE

-  
2Mbps Direct Sequence PCCARD adapter

-  
Zoom Air Model 4000

-  
 

-

-

-
The original Xircom Netwave AirSurfer is supported by the
-    cnw(4) driver, and the PRISM-II cards are supported by the
-    wi(4) driver.

-

-

-

-
In addition to default
-     media
-    type, the DS cards support
-     and
-     media
-    types, while the FH cards support the
-     media
-    type. For each media type, the
-    
-    mediaopt can be used to indicate to the driver to operate in ad-hoc mode.
-    The
-    
-    mediaopt should be used only with old access points, which operate in IBSS
-    mode. For DS radio cards, the
-    
-    mediaopt can be used for wi(4) compatible WaveLAN ad-hoc
-    mode.

-

-

-

-

-  
awi0: no suitable CIS info found

-  
The device cannot be mapped due to a resource conflict. Or, the device
-      failed to initialize its firmware.

-  
awi0: failed to complete selftest (%s)

-  
The device failed to complete its self test. In some circumstances,
-      resetting device after power on fails. Re-inserting the card or setting
-      the interface up and then down again (using ifconfig(8))
-      may also be helpful.

-  
awi0: transmit timeout

-  
The device failed to generate an interrupt to acknowledge a transmitted
-      packet.

-  
awi0: failed to lock interrupt

-  
The system was unable to obtain the lock to access shared memory.

-  
awi0: command %d failed %x

-  
The device failed to complete the request from the system.

-

-

-

-

-
arp(4), cnw(4),
-    ifmedia(4), netintro(4),
-    pcmcia(4), wi(4),
-    ifconfig(8), wiconfig(8)

-
Am79C930 PCnet Mobile
-    Single-Chip Wireless LAN Media Access Controller,
-    http://www.amd.com.

-

-

-

-
The awi device driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The initial version of the awi driver was
-    written by Bill Sommerfeld
-    ⟨sommerfeld@NetBSD.org⟩. It was then completely rewritten to
-    support cards with the DS phy and ad-hoc mode by
-  

-  Atsushi Onoe ⟨onoe@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
January 2, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/axe.4 4.html b/static/netbsd/man4/axe.4 4.html
deleted file mode 100644
index 7f48fc08..00000000
--- a/static/netbsd/man4/axe.4 4.html	
+++ /dev/null
@@ -1,160 +0,0 @@
-
-  
-    
-    
-    
-  
-
AXE(4)Device Drivers ManualAXE(4)

-

-

-

-
axe — ASIX
-    Electronics AX88172/AX88178/AX88772 10/100/Gigabit USB Ethernet
-    device

-

-

-

-
axe* at uhub?
-  

-  ukphy* at mii?

-

-

-

-
The axe driver supports the following
-    adapters:

-

-

-

-  
Apple USB Ethernet Adapter A1277

-  
 

-  
ATEN UC-210T

-  
 

-  
BAFO BF-320

-  
 

-  
Billionton Systems USB2AR

-  
 

-  
Buffalo(MELCO) LUA-U2-GT

-  
 

-  
Buffalo(MELCO) LUA-U2-KTX

-  
 

-  
Buffalo(MELCO) LUA3-U2-ATX

-  
 

-  
Corega FEther USB2-TX

-  
 

-  
D-Link DUB-E100

-  
 

-  
Good Way GWUSB2E

-  
 

-  
Hawking UF200

-  
 

-  
Intellinet USB 2.0 to Ethernet (rev A)

-  
 

-  
IO-Data ETG-US2

-  
 

-  
JVC MP-PRX1

-  
 

-  
Konig CMP-NWUSB20

-  
 

-  
Level One USB-0200

-  
 

-  
Linksys USB200M

-  
 

-  
Linksys USB1000

-  
 

-  
Logitec LAN-GTJ/U2

-  
 

-  
Logitec LAN-TXU2C

-  
 

-  
Logitec LAN-TXU2H3A

-  
 

-  
Netgear FA120

-  
 

-  
Nintendo Wii USB Lan Ethernet Adapter RVL-015

-  
 

-  
OQO model 01+ Ethernet

-  
 

-  
Planex UE-200TX-G

-  
 

-  
Sitecom LN-029

-  
 

-  
SMC 2209USB/ETH

-  
 

-  
SnapPort USB 2.0 LAN Adapter

-  
 

-  
ST Lab USB 2.0 Fast Ethernet

-  
 

-  
Surecom EP-1427X-2

-  
 

-  
System TALKS SGC-X2UL

-  
 

-  
TRENDnet TU2-ET100

-  
 

-  
Z-TEK ZK-R01-2

-  
 

-

-

-

-

-

-
The axe driver provides support for USB
-    Ethernet adapters based on the ASIX Electronics AX88172, AX88178, AX88772,
-    AX88772A, AX88772B USB 2.0 chipsets.

-
The chip contains a 10/100 Ethernet MAC with MII interface and is
-    designed to work with both Ethernet and HomePNA transceivers. The AX88172
-    and AX88772 contain 10/100 Ethernet MACs with MII interfaces. The AX88178
-    contains a 10/100/1000 Gigabit Ethernet MAC with a GMII/MII interface. The
-    chip also supports USB 2.0, thereby accommodating 100 Mb/s data rates.

-
The axe driver supports the following
-    media types:

-

-  
autoselect

-  
Enable automatic selection of the media type and options.

-  
10baseT/UTP

-  
Set 10Mbps operation. The mediaopt option can also
-      be used to enable full-duplex operation. Not
-      specifying full duplex implies
-      half-duplex mode.

-  
100baseTX

-  
Set 100Mbps (fast Ethernet) operation. The mediaopt
-      option can also be used to enable full-duplex
-      operation. Not specifying full duplex implies
-      half-duplex mode.

-  
1000baseT

-  
Set 1000Mbps (Gigabit Ethernet) operation (AX88178 only).

-

-
The axe driver supports the following
-    media options:

-

-  
full-duplex

-  
Force full duplex operation. The interface will operate in half duplex
-      mode if this media option is not specified.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), usb(4),
-    usbnet(4), ifconfig(8)

-
ASIX AX88172 data sheet,
-    http://www.asix.com.tw.

-

-

-

-
The axe device driver first appeared in
-    FreeBSD and was ported to NetBSD
-    3.0. It replaces the NetBSD uax driver.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/axen.4 4.html b/static/netbsd/man4/axen.4 4.html
deleted file mode 100644
index bd16fa34..00000000
--- a/static/netbsd/man4/axen.4 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
AXEN(4)Device Drivers ManualAXEN(4)

-

-

-

-
axen — ASIX
-    Electronics AX88178a/AX88179 10/100/Gigabit USB Ethernet device

-

-

-

-
axen* at uhub? port ?
-  

-  rgephy* at mii?

-

-

-

-
The axen driver provides support for USB
-    Ethernet adapters based on the ASIX Electronics AX88178a USB 2.0 and AX88179
-    USB 3.0 chipsets including the following:

-

-

-

-  
Buffalo LUA4-U3-AGT

-  
 

-  
D-Link DUB-1312

-  
 

-  
Kurotoshiko GbE-USB3.0

-  
 

-  
Kurotoshiko GbE-USB3.0S2

-  
 

-  
Logitec LAN-GTJU3

-  
 

-  
Logitec LAN-GTJU3H3

-  
 

-  
Shanghai Donya DN-84327

-  
 

-

-

-
The axen driver supports the following
-    media types:

-

-  
autoselect

-  
Enable autoselection of the media type and options (this is the default).
-      The user can manually override the autoselected mode by adding media
-      options to the appropriate ifconfig.if(5) file.

-  
10baseT

-  
Set 10Mbps operation.

-  
100baseTX

-  
Set 100Mbps (Fast Ethernet) operation.

-  
1000baseT

-  
Set 1000Mbps (Gigabit Ethernet) operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), mii(4),
-    netintro(4), rgephy(4),
-    usb(4), usbnet(4),
-    ifconfig.if(5), ifconfig(8)

-

-

-

-
The axen device driver first appeared in
-    OpenBSD 5.4 and in NetBSD
-    7.0.

-

-

-

-
The axen driver was written by
-    Yojiro UO
-    <yuo@nui.org> for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro
-    <nonaka@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/az.4 4.html b/static/netbsd/man4/az.4 4.html
deleted file mode 100644
index e6eac59d..00000000
--- a/static/netbsd/man4/az.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
AZ(4)Device Drivers ManualAZ(4)

-

-

-

-
az —
-    Aztech/PackardBell radio card device driver

-

-

-

-
az0 at isa? port 0x350
-  

-  az1 at isa? port 0x358
-  

-  radio* at az?

-

-

-

-
The az driver provides support for the
-    Aztech/PackardBell radio cards.

-
The Aztech/PackardBell cards are stereo FM tuners that allow
-    tuning in the 87.5-108.0 MHz range. They are capable of reporting signal
-    status (tuned/not tuned, stereo/mono signal) and forcing audio output to
-    mono.

-
The Aztech cards use only one I/O port. The I/O port is set by the
-    driver to the value specified in the configuration file. The I/O port must
-    be one of 0x350 and 0x358.

-

-

-

-
isa(4), radio(4)

-

-

-

-
The az device driver appeared in
-    OpenBSD 3.0 and NetBSD
-  1.6.

-

-

-

-
The az driver was written by
-    Vladimir Popov and Maxim
-    Tsyplakov. The man page was written by Vladimir
-    Popov.

-

-

-

-
It is impossible to determine to which frequency the card is
-    tuned. Thus, the driver will report an internally stored value even if it is
-    not correct (changed by some program that uses direct port access).

-

-

-
-  
-    
-    
-  
-
August 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/battery_pmu.4 4.html b/static/netbsd/man4/battery_pmu.4 4.html
deleted file mode 100644
index 8a5a3c77..00000000
--- a/static/netbsd/man4/battery_pmu.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
BATTERY_PMU(4)Device Drivers ManualBATTERY_PMU(4)

-

-

-

-
battery_pmu —
-    support for batteries and sensors in PCI-based Apple
-    Powerbooks

-

-

-

-
battery* at pmu?

-

-

-

-
The battery_pmu driver provides support
-    for batteries and hardware sensors found in first generation PCI-based
-    PowerBooks (i.e. Apple Powerbook 2400, 3400 and 3500 (also known as Original
-    PowerBook G3). Currently it only exports a few sensors via the
-    envsys(4) interface, including battery charge, voltage,
-    CPU and battery temperature and AC power availability.

-

-

-

-
envsys(4), pmu(4),
-    envstat(8)

-

-

-

-
There is no APM emulation right now and the battery current sensor
-    may return misleading or wrong data. This driver is considered preliminary
-    and may be replaced at some point.

-

-

-
-  
-    
-    
-  
-
May 18, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/bba.4 4.html b/static/netbsd/man4/bba.4 4.html
deleted file mode 100644
index 406b8c54..00000000
--- a/static/netbsd/man4/bba.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
BBA(4)Device Drivers ManualBBA(4)

-

-

-

-
bba — IOASIC
-    Baseboard Audio device driver

-

-

-

-
bba0 at ioasic? offset ?
-  

-  audio* at audiobus?

-

-

-

-
The bba driver provides support for the
-    IOASIC baseboard audio found on DEC 3000/300, 3000/500
-    (NetBSD/alpha) and DEC Personal DECstation
-    (NetBSD/pmax) systems. The baseboard audio driver is
-    based on the AMD 79c30 ISDN and audio interface. The interface is only
-    capable of playing and recording 8kHz mu-law audio.

-

-

-

-
audio(4), ioasic(4)

-

-

-

-
The bba device driver appeared in
-    NetBSD 1.5. The name for the driver was adopted from
-    the same driver in ULTRIX.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/bce.4 4.html b/static/netbsd/man4/bce.4 4.html
deleted file mode 100644
index 2f2efc0d..00000000
--- a/static/netbsd/man4/bce.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
BCE(4)Device Drivers ManualBCE(4)

-

-

-

-
bce — Broadcom
-    BCM4401 Ethernet device driver

-

-

-

-
bce* at pci? dev ? function ?

-

-

-

-
The bce provides support for the Broadcom
-    BCM4401 10/100 Ethernet card. Other cards from the 440x series may also be
-    supported.

-

-

-

-
bge(4), mii(4),
-    ukphy(4)

-

-

-

-
The bce driver appeared in
-    NetBSD 1.6.2.

-

-

-

-
Cliff Wright
-    ⟨cliff@snipe444.org⟩

-

-

-

-
There is no VLAN support.

-
There is no flow control support.

-
Multicast is not using the packet filter and is in the accept all
-    multicast mode.

-

-

-
-  
-    
-    
-  
-
June 29, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/bcsp.4 4.html b/static/netbsd/man4/bcsp.4 4.html
deleted file mode 100644
index 1d72ab5c..00000000
--- a/static/netbsd/man4/bcsp.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
BCSP(4)Device Drivers ManualBCSP(4)

-

-

-

-
bcsp — BlueCore
-    Serial Protocol driver

-

-

-

-
pseudo-device bcsp

-

-

-

-
The bcsp driver provides a
-    tty(4) line discipline to send and receive BlueCore Serial
-    Protocol packets over a serial line, as described in the "BlueCore
-    Serial Protocol (BCSP)" specification.

-
Moreover, the bcsp supports BCSP Link
-    Establishment Protocol, as described in the "BCSP Link Establishment
-    Protocol" specification.

-
The btattach(8) program is used to configure the
-    tty line and create the bcsp driver instance.

-

-

-

-
bluetooth(4), btuart(4),
-    btattach(8)

-

-

-

-
The bcsp device appeared in
-    NetBSD 5.0.

-

-

-

-
KIYOHARA Takashi
-    <kiyohara@kk.iij4u.or.jp>

-

-

-

-
bcsp does not support configuration for
-    baud rate yet.

-

-

-
-  
-    
-    
-  
-
August 23, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/be.4 4.html b/static/netbsd/man4/be.4 4.html
deleted file mode 100644
index c16250ee..00000000
--- a/static/netbsd/man4/be.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
BE(4)Device Drivers ManualBE(4)

-

-

-

-
be — SPARC Fast
-    Ethernet interface

-

-

-

-
qec* at sbus? slot ? offset ?
-  

-  be* at qec?

-

-

-

-
The be interface provides access to the
-    10Mb/s and 100Mb/s (half duplex only) Ethernet networks. The
-    be is found on the Sun 10/100 Mbit Ethernet boards
-    (Sun part number SUNW,501-2450).

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    be interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-
The be is not capable of link
-    autonegotiation, so a media type must be specified with
-    ifconfig(8). The supported media types are:

-

-

-  
media 100baseTX

-  
Use 100Mbps, half duplex

-  
media 10baseT

-  
Use 10Mbps, half duplex

-

-

-

-

-

-
arp(4), ifmedia(4),
-    inet(4), intro(4),
-    netintro(4), sbus(4),
-    ifconfig(8)

-

-

-

-
Support for the be first appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 31, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/bge.4 3.html b/static/netbsd/man4/bge.4 3.html
deleted file mode 100644
index 0dbbfee0..00000000
--- a/static/netbsd/man4/bge.4 3.html	
+++ /dev/null
@@ -1,163 +0,0 @@
-
-  
-    
-    
-    
-  
-
BGE(4)Device Drivers ManualBGE(4)

-

-

-

-
bge — Broadcom
-    BCM57xx/BCM590x 10/100/Gigabit Ethernet driver

-

-

-

-
bge* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The bge driver provides support for
-    various NICs based on the Broadcom BCM570x, 571x, 572x, 575x, 576x, 578x,
-    5776x and 5778x Gigabit Ethernet controller chips and the 590x and 5779x
-    Fast Ethernet controller chips, including the following:

-

-
    
-  
  • 3Com 3c996-T (10/100/1000baseT)
    • 
-  
  • 3Com 3c996-SX (1000baseSX)
    • 
-  
  • 3Com 3c996B-T (10/100/1000baseT)
    • 
-  
  • Allied-Telesis AT-2972LX10/LC
    • 
-  
  • Apple Thunderbolt to Gigabit Ethernet adapter A1433
-    (10/100/1000baseT)
    • 
-  
  • Dell PowerEdge 1750 integrated BCM5704C NIC (10/100/1000baseT)
    • 
-  
  • Dell PowerEdge 2550 integrated BCM5700 NIC (10/100/1000baseT)
    • 
-  
  • Dell PowerEdge 2650 integrated BCM5703 NIC (10/100/1000baseT)
    • 
-  
  • Fujitsu PRIMEPOWER 250/450 LAN (10/100/1000baseT)
    • 
-  
  • Fujitsu PW0G8GE1U (1000baseSX)
    • 
-  
  • Fujitsu PW0G8GE2U (10/100/1000baseT)
    • 
-  
  • Fujitsu PW008GE4 (1000baseSX)
    • 
-  
  • Fujitsu PW008GE5 (10/100/1000baseT)
    • 
-  
  • Fujitsu PW008QG1U (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC320T PCI-E Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC320m PCI-E Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC331T PCI-E Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC332T PCI-E Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC370F PCI-X Gigabit NIC (1000baseSX)
    • 
-  
  • HP ProLiant NC370T PCI-X Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC1020 PCI Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC6770 PCI-X Gigabit NIC (1000baseSX)
    • 
-  
  • HP ProLiant NC7760 embedded PCI Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC7770 PCI-X Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC7771 PCI-X Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC7780 embedded PCI-X Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC7781 embedded PCI-X Gigabit NIC (10/100/1000baseT)
    • 
-  
  • HP ProLiant NC7782 embedded PCI-X Gigabit NIC (10/100/1000baseT)
    • 
-  
  • IBM ThinkPad T43/T43p integrated BCM5751M NIC (10/100/1000baseT)
    • 
-  
  • IBM xSeries 235 integrated BCM5703X NIC (10/100/1000baseT)
    • 
-  
  • IBM xSeries 305 integrated BCM5703X NIC (10/100/1000baseT)
    • 
-  
  • Netgear GA302T (10/100/1000baseT)
    • 
-  
  • SysKonnect SK-9D21 (10/100/1000baseT)
    • 
-  
  • SysKonnect SK-9D41 (1000baseSX)
    • 
-

-
The bge driver supports IPv4 IP, TCP, and
-    UDP checksum offload for receive, IP checksum offload for transmit, VLAN tag
-    insertion and stripping, as well as a 256-bit multicast hash filter. The
-    BCM5717, BCM5718, BCM5723, BCM5754, BCM5755, BCM5761, BCM5762, BCM5764,
-    BCM5784, BCM5785, BCM5787 and BCM577xx chips also support IPv6 receive
-    TCP/UDP checksum offload. The bge driver supports
-    this feature of the chip. See ifconfig(8) for information
-    on how to enable this feature.

-
The BCM5700, BCM5701, BCM5702, BCM5703, BCM5704, BCM5714, BCM5717,
-    BCM5719, BCM5720, BCM5762, BCM5780, BCM57765 and BCM57766 also support jumbo
-    frames, which can be configured via the interface MTU setting. Selecting an
-    MTU larger than 1500 bytes with the ifconfig(8) utility
-    configures the adapter to receive and transmit Jumbo frames.

-
The level of interrupt mitigation for received packets can be
-    adjusted with the hw.bge.rx_lvl
-    sysctl(8) control. A value of 1 yields a
-    bge interrupt for every two full-sized Ethernet
-    frames. Each increment of the value will, roughly, halve receive interrupt
-    rate, up to a maximum of 5, which interrupts about every 30 to 40 full-sized
-    TCP segments.

-
The bge driver supports the following
-    media types:

-

-  

-  
Enable autoselection of the media type and options. The user can manually
-      override the autoselected mode by adding media options to the appropriate
-      ifconfig.if(5) file.

-  

-  
Set 10Mbps operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 1000baseT operation over twisted pair. Both
-      full-duplex and
-      half-duplex modes are supported.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation. Both
-      full-duplex and
-      half-duplex modes are supported.

-

-
The bge driver supports the following
-    media options:

-

-  

-  
Force full duplex operation.

-  

-  
Force half duplex operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-

-  
bge%d: can't find mem space

-  
A fatal initialization error has occurred.

-  
bge%d: couldn't map interrupt

-  
A fatal initialization error has occurred.

-  
bge%d: watchdog timeout -- resetting

-  
The device has stopped responding to the network, or there is a problem
-      with the network connection (cable).

-

-

-

-

-
arp(4), brgphy(4),
-    ifmedia(4), mii(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The bge driver first appeared in
-    NetBSD 1.6.1.

-

-

-

-
The bge driver was written by
-    Bill Paul ⟨wpaul@windriver.com⟩ for
-    FreeBSD and ported to NetBSD
-    by Frank van der Linden
-    ⟨fvdl@wasabisystems.com⟩, Jason R.
-    Thorpe ⟨thorpej@wasabisystems.com⟩ and
-    Jonathan Stone
-    ⟨jonathan@dsg.stanford.edu⟩.

-

-

-
-  
-    
-    
-  
-
October 15, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/bha.4 4.html b/static/netbsd/man4/bha.4 4.html
deleted file mode 100644
index 3bec126a..00000000
--- a/static/netbsd/man4/bha.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
BHA(4)Device Drivers ManualBHA(4)

-

-

-

-
bha, bt —
-    Buslogic SCSI adapter driver

-

-

-

-
bha0 at isa? port 0x330 irq ? drq ?
-  

-  bha* at eisa? slot ?
-  

-  bha* at pci? dev ? function ?
-  

-  scsibus* at bha?

-

-

-

-
The bha driver supports the following
-    Buslogic SCSI adapters:

-

-

-

-  
Buslogic ISA BT-445

-  
 

-  
Buslogic EISA BT-74x

-  
 

-  
Buslogic PCI BT-9[45][68]

-  
 

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-

-
In NetBSD 1.2 and earlier, this driver was
-    named bt but was renamed to
-    bha in later releases.

-

-

-

-
The Buslogic BT-930 is not supported in this driver.

-
The Buslogic BT-445S has a problem in early hardware and firmware
-    revisions which prevents proper operation on a system with more than 16MB of
-    RAM. Hardware revision D and firmware revision 3.37 should be considered
-    minimum requirements for using this board on systems configured in this
-    manner.

-

-

-
-  
-    
-    
-  
-
November 29, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/bio.4 4.html b/static/netbsd/man4/bio.4 4.html
deleted file mode 100644
index 54ab564f..00000000
--- a/static/netbsd/man4/bio.4 4.html	
+++ /dev/null
@@ -1,171 +0,0 @@
-
-  
-    
-    
-    
-  
-
BIO(4)Device Drivers ManualBIO(4)

-

-

-

-
bio — Block IO
-    ioctl tunnel pseudo-device

-

-

-

-
pseudo-device bio

-

-  

-  #include <dev/biovar.h>

-

-

-

-
The bio driver provides userland
-    applications ioctl(2) access to devices otherwise not
-    found as /dev nodes. The
-    /dev/bio device node operates by delegating ioctl
-    calls to a requested device driver. Only drivers which have registered with
-    the bio device can be accessed via this
-  interface.

-
The following device drivers register with
-    bio for volume management:

-

-

-

-  
arcmsr(4)

-  
Areca Technology Corporation SATA RAID controller

-  
ataraid(4)

-  
Software BIOS RAID

-  
cac(4)

-  
Compaq RAID array controller

-  
ciss(4)

-  
Compaq Smart ARRAY 5/6 SAS/SATA/SCSI RAID controller

-  
mfi(4)

-  
LSI Logic & Dell MegaRAID SAS RAID controller

-  
mfii(4)

-  
LSI Logic MegaRAID SAS Fusion RAID controller

-  
mpii(4)

-  
LSI Logic Fusion-MPT Message Passing Interface II

-  
mpt(4)

-  
LSI Fusion-MPT RAID controller

-

-

-
The following ioctl calls apply to the bio
-    device:

-

-  

-  
Locate a named device and give back a cookie to the application for
-      subsequent ioctl calls. The cookie is used to tunnel further ioctls to the
-      right device.

-  

-  
Retrieve number of volumes and physical disks for a specific device.

-  

-  
Retrieve detailed information for the specified physical disk. Information
-      returned can include status, size, channel, target, lun, vendor name,
-      serial number, and processor device (ses).

-  

-  
Is just the same as BIOCDISK but doesn't require
-      the disks to be in volume sets, so this applies to any physical disk
-      connected to the controller.
-    
Note: this ioctl might not be supported on all hardware. It is
-        a NetBSD extension of
-        bio. It is supported by
-        arcmsr(4), ciss(4), and
-        mpt(4). It is also supported by
-        cac(4), but handled exactly the same as
-        BIOCDISK.

-  

-  

-  
Retrieve detailed information for the specified volume. Information
-      returned can include status, size, RAID level, number of disks, device
-      name association (sd?) and vendor name.

-  

-  
Control the alarm beeper on the device. Supported states are: disable
-      alarm, enable alarm, silence alarm, status and test alarm.
-    
Note: These options might not be supported on all hardware. It
-        is supported by arcmsr(4), mfi(4),
-        and mfii(4).

-  

-  
-  
Blink an LED of the specified physical disk. Supported blink states are:
-      blink LED, unblink LED and blink alarm LED.
-    
Note: This option is only supported if the disk is governed by
-        ses(4) and the hardware supports hardware blinking. It
-        is supported by ciss(4), mfi(4), and
-        mfii(4).

-  

-  

-  
Alter the state of specified physical disk. Supported states are:
-      create/remove hot-spare, create/remove pass through disk, start/stop
-      consistency check in a volume, online disk and offline disk, and a manual
-      rebuild kick-off designation.
-    
Note: These options might not be supported on all hardware.
-        Some of these options are supported by arcmsr(4),
-        mfi(4), and mfii(4).

-    
Online, offline and hotspare designations are supported by
-        mfi(4) and mfii(4), plus a rebuild
-        designation is supported by mfii(4); all four of these
-        state options are the original states from
-        OpenBSD, the other options, including hotspare
-        unmarking, being NetBSD extensions of
-        bio.

-    
Hotspare, pass through and consistency check options are
-        supported by arcmsr(4).

-  

-  

-  
For operations in volume sets. It's able to create and remove a volume set
-      in a supported RAID controller.
-    
Note: this ioctl might not be supported on all hardware. It is
-        a NetBSD extension of
-        bio, and is supported by
-        arcmsr(4).

-  

-

-
The bioctl(8) utility can be used to perform the
-    above controls from the userland. Additionally, since
-    BIOCVOL volume status is normally duplicated into
-    sysmon_envsys(9) sensors of
-    ENVSYS_DRIVE type, it is also available through
-    envsys(4), and can be monitored with
-    envstat(8) and powerd(8).

-

-

-

-

-  
/dev/bio

-  
ioctl tunnel device

-  
/etc/powerd/scripts/sensor_drive

-  
powerd script for drive sensors

-

-

-

-

-
ioctl(2), envsys(4),
-    bioctl(8), envstat(8),
-    powerd(8), sysmon_envsys(9)

-

-

-

-
The bio driver first appeared in
-    OpenBSD 3.2 and NetBSD
-  4.0.

-

-

-

-
The bio driver was written by
-    Niklas Hallqvist
-    <niklas@openbsd.org>.
-    The API was written by Marco Peereboom
-    <marco@openbsd.org>
-    and was extended even more for NetBSD by
-    Juan Romero Pardines
-    <xtraeme@netbsd.org>.

-

-

-
-  
-    
-    
-  
-
May 9, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/bktr.4 4.html b/static/netbsd/man4/bktr.4 4.html
deleted file mode 100644
index 8c7ded41..00000000
--- a/static/netbsd/man4/bktr.4 4.html	
+++ /dev/null
@@ -1,450 +0,0 @@
-
-  
-    
-    
-    
-  
-
BKTR(4)Device Drivers ManualBKTR(4)

-

-

-

-
bktr — Brooktree
-    848 compatible TV card driver

-

-

-

-
bktr* at pci? dev ? function ?
-  

-  radio* at bktr?

-

-  

-  #include <dev/ic/bt8xx.h>

-

-  

-  options BKTR_OVERRIDE_CARD=n
-  

-  options BKTR_OVERRIDE_TUNER=n
-  

-  options BKTR_OVERRIDE_DBX=n
-  

-  options BKTR_OVERRIDE_MSP=n
-  

-  options BKTR_SYSTEM_DEFAULT=n
-  

-  options BKTR_USE_PLL
-  

-  options BKTR_GPIO_ACCESS
-  

-  options BKTR_NO_MSP_RESET

-

-

-

-
This driver supports video capture (frame grabber) and TV tuner
-    cards based on the Brooktree Bt848, Bt848A, Bt849A, Bt878, and Bt879
-  chips.

-
Note that bktr is not part of the
-    dtv(4) framework.

-
Supported cards include most cards by AVerMedia, Hauppauge,
-    Leadtek, Miro, Pinnacle, Pixelview, Terratec, and some other companies,
-    especially all cards based on the Brooktree Bt848, Bt848A, Bt849A, Bt878, or
-    Bt879 chips. A notable exception are the ATI All-in-Wonder cards.

-
The following kernel configuration options are available:

-

-  
options BKTR_OVERRIDE_CARD=n

-  
If the card is not recognized correctly by the auto-detection routine, it
-      can be overridden by setting this option to the appropriate value. The
-      following values are allowed:
-    

-      
1

-      
Pinnacle Systems (Miro) TV,

-      
2

-      
Hauppauge WinCast/TV,

-      
3

-      
STB TV/PCI,

-      
4

-      
Intel Smart Video III and Videologic Captivator PCI,

-      
5

-      
IMS TV Turbo,

-      
6

-      
AVerMedia TV/FM,

-      
7

-      
MMAC Osprey,

-      
8

-      
NEC PK-UG-X017,

-      
9

-      
I/O DATA GV-BCTV2/PCI,

-      
10

-      
Animation Technologies FlyVideo,

-      
11

-      
Zoltrix TV,

-      
12

-      
KISS TV/FM PCI,

-      
13

-      
Video Highway Xtreme,

-      
14

-      
Askey/Dynalink Magic TView,

-      
15

-      
Leadtek WinFast TV 2000/VC100,

-      
16

-      
TerraTec TerraTV+, and

-      
17

-      
TerraTec TValue.

-    

-  

-  
options BKTR_OVERRIDE_TUNER=n

-  
If the TV tuner is not recognized correctly by the auto-detection routine,
-      it can be overridden by setting this option to the appropriate value.
-      Known values are:
-    

-      
1

-      
Temic NTSC,

-      
2

-      
Temic PAL,

-      
3

-      
Temic SECAM,

-      
4

-      
Philips NTSC,

-      
5

-      
Philips PAL,

-      
6

-      
Philips SECAM,

-      
7

-      
Temic PAL I,

-      
8

-      
Philips PAL I,

-      
9

-      
Philips FR1236 NTSC FM,

-      
10

-      
Philips FR1216 PAL FM,

-      
11

-      
Philips FR1236 SECAM FM,

-      
12

-      
ALPS TSCH5 NTSC FM, and

-      
13

-      
ALPS TSBH1 NTSC.

-    

-  

-  
options BKTR_OVERRIDE_DBX=n

-  
To override detection of the BTSC (dbx) chip, set this to
-      1 if you have one, or 0 if not.

-  
options BKTR_OVERRIDE_MSP=n

-  
To override detection of the MSP 34xx chip, set this to
-      1 if you have one, or 0 if not.

-  
options
-    BKTR_SYSTEM_DEFAULT=n

-  
If this option is set to
-      
-      default to PAL, else to NTSC.

-  
options BKTR_USE_PLL

-  
Default to PLL instead of XTAL.

-  
options BKTR_GPIO_ACCESS

-  
Use
-      ()s
-      for direct GPIO access.

-  
options BKTR_NO_MSP_RESET

-  
Skip the MSP reset. This option is handy if you initialize the MSP audio
-      in another operating system first and then do a soft reboot.

-

-

-

-

-
The video capture interface to bktr is
-    accessed through the /dev/bktrN devices. The
-    following ioctl(2) commands are supported on the
-    Brooktree848 video capture interface:

-

-  

-    unsigned long *

-  
This command sets the video format, also sometimes referred to as the
-      video norm. The supported formats are:
-    

-    

-      

-      
NTSC

-      

-      
PAL

-      

-      
SECAM

-      

-      
hardware default

-    

-  

-  

-    unsigned long *

-  
This command retrieves the current video format to the
-      unsigned long * argument.

-  

-    struct meteor_geomet *

-  
This command sets the video properties that affect the bit size of a frame
-      through the meteor_geomet * argument.
-    

-    
struct meteor_geomet {
-	u_short		rows;	 /* height in pixels*/
-	u_short		columns; /* width in pixels */
-	u_short		frames;
-	u_long		oformat;
-}

-    

-    
The frames field is the number of frames
-        to buffer. Currently only 1 frame is supported for most operations.

-    
The oformat field is a bit-field
-        describing the output pixel format type and which video fields to
-        capture. The following are supported pixel format types:
-      

-       .Pp

-    

-      

-      
16-bit RGB

-      

-      
24-bit RGB in 32 bits

-      

-      
16-bit 4:2:2 YUV

-      

-      
16-bit 4:2:2 YUV

-      

-      
unsigned UV

-      

-      
 

-      

-      
 

-      

-      
 

-    

-    
The following are supported field capture modes:

-    

-    

-      

-      
only odd fields

-      

-      
only even fields

-    

-    
By default, frames will consist of both the odd and even
-        fields.

-  

-  

-    struct meteor_pixfmt *

-  
This command is used interactively to fetch descriptions of supported
-      output pixel formats into the meteor_pixfmt *
-      argument.
-    

-    
struct meteor_pixfmt {
-	u_int          index;
-	METEOR_PIXTYPE type;
-	u_int          Bpp;		/* bytes per pixel */
-	u_long         masks[3];	/* YUV bit masks */
-	unsigned       swap_bytes :1;
-	unsigned       swap_shorts:1;
-};

-    

-    
To query all the supported formats, start with an index field
-        of 0 and continue with successive encodings (1, 2, ...) until the
-        command returns an error.

-  

-  

-    int *

-  
This command sets the active pixel format. The int *
-      argument is the index of the pixel format as returned by
-      METEORGSUPPIXFMT.

-  

-    int *

-  
This command fetches the active pixel format index into the
-      int * argument.

-  

-    unsigned long *

-  
This command sets the input port of the Brooktree848 device. The following
-      are supported input ports:
-    

-    

-      

-      
composite (RCA)

-      

-      
tuner

-      

-      
composite S-video

-      

-      
mystery device

-      

-      
rgb meteor

-      

-      
S-Video

-    

-    
Not all devices built with Brooktree848 chips support the full
-        list of input ports.

-  

-  

-    unsigned long *

-  
This command retrieves the current input port to the
-      unsigned long * argument.

-  

-    unsigned short *

-  
This command sets the number of frames to grab each second. Valid frame
-      rates are integers from 0 to 30.

-  

-    unsigned short *

-  
This command fetches the number of frames to grab each second into the
-      unsigned short * argument.

-  

-    int *

-  
This command controls capturing of video data. The following are valid
-      arguments:
-    

-    

-      

-      
capture one frame

-      

-      
continuously capture

-      

-      
stop continuous capture

-    

-  

-  

-    unsigned int *

-  
This command controls the signal emission properties of
-      bktr. If the unsigned int *
-      argument is a valid signal, then that signal will be emitted when either a
-      frame or field capture has completed. To select between frame or field
-      signalling, the following arguments are used:
-    

-    

-      

-      
signal every frame

-      

-      
signal every field

-    

-    
By default, signals will be generated for every frame.
-        Generation of signals is terminated with the
-        METEOR_SIG_MODE_MASK argument.

-  

-

-

-

-

-
Most cards supported by this driver feature a hardware television
-    tuner on the I2C bus. The tuner interface to bktr is
-    accessed through the /dev/tunerN devices. The
-    following ioctl(2) commands are supported on the tuner
-    interface:

-

-  

-    unsigned int *

-  
This command sets the tuner's TV channel set, also sometimes called the TV
-      channel band. This setting is used to calculate the proper tuning
-      frequencies. The desired channel set must be selected before attempting to
-      set the tuner channel or frequency. The following is a list of valid
-      channel sets:
-    

-    

-      

-      
North America broadcast

-      

-      
North America IRC cable

-      

-      
North America HRC cable

-      

-      
Western Europe

-      

-      
Japan broadcast

-      

-      
Japan cable

-      

-      
Russia

-      

-      
Australia

-      

-      
France

-    

-  

-  

-    unsigned int *

-  
This command fetches the tuner's current channel set to the
-      unsigned int * argument.

-  

-    unsigned int *

-  
This command sets the tuner's frequency to a specified channel in the
-      current channel set.

-  

-    unsigned int *

-  
This command fetches the last selected channel. Note that it is not
-      necessarily the current channel. In particular, changing the tuner's
-      frequency by a command other than TVTUNER_SETCHNL
-      will not update this setting, and it defaults to 0 on driver
-      initialization.

-  

-    unsigned int *

-  
This command sets the tuner's frequency to 1/16th the value of the
-      unsigned int * argument, in MHz. Note that the
-      current channelset is used to determine frequency offsets when this
-      command is executed.

-  

-    unsigned int *

-  
This command fetches the tuner's current frequency to the
-      unsigned int * argument. Note that this value is 16
-      times the actual tuner frequency, in MHz.

-  

-    int *

-  
This command controls the audio input port and mute state. The following
-      is a list of valid arguments:
-    

-    

-      

-      
tuner audio port

-      

-      
external audio port

-      

-      
internal audio port

-      

-      
mute audio

-      

-      
unmute audio

-    

-  

-  

-    int *

-  
This command fetches the audio input and mute state bits to the
-      int * argument.

-

-

-

-

-

-  
/dev/bktr*

-  
bktr driver interface device

-  
/dev/tuner*

-  
bktr tuner interface device

-  
/dev/vbi*

-  
teletext interface device

-

-

-

-

-
options(4), pci(4),
-    radio(4), pkgsrc/audio/xmradio,
-    pkgsrc/multimedia/ffmpeg,
-    pkgsrc/multimedia/fxtv

-

-

-

-
The bktr driver appeared in
-    FreeBSD 2.2 and NetBSD
-  1.5.

-

-

-

-
The bktr driver was originally written by
-    Amancio Hasty for FreeBSD
-    and is now maintained by Roger Hardiman.
-    NetBSD porting was done by Bernd
-    Ernesti, Berndt Josef Wulf,
-    Matthias Scheler, and Thomas
-    Klausner.

-

-

-
-  
-    
-    
-  
-
August 30, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/bluetooth.4 4.html b/static/netbsd/man4/bluetooth.4 4.html
deleted file mode 100644
index 959d6c8d..00000000
--- a/static/netbsd/man4/bluetooth.4 4.html	
+++ /dev/null
@@ -1,363 +0,0 @@
-
-  
-    
-    
-    
-  
-
BLUETOOTH(4)Device Drivers ManualBLUETOOTH(4)

-

-

-

-
bluetooth —
-    Bluetooth Protocol Family

-

-

-

-
#include
-    <netbt/bluetooth.h>
-  

-  #include <netbt/hci.h>
-  

-  #include <netbt/l2cap.h>
-  

-  #include <netbt/rfcomm.h>

-

-

-

-
The Bluetooth Protocol Family

-

-

-

-
Bluetooth Protocol Family sockets all use a
-    sockaddr_bt structure which contains a Bluetooth
-    Device Address (BDADDR). This consists of a six byte string in least
-    significant byte first order.

-

-
struct sockaddr_bt {
-	uint8_t		bt_len;
-	sa_family_t	bt_family;
-	bdaddr_t	bt_bdaddr;
-	uint16_t	bt_psm;
-	uint8_t		bt_channel;
-};

-

-
The local address used by the socket can be set with
-    bind(2).

-

-

-

-
Protocols included are:

-

-  

-  
This gives raw access to the Host Controller Interface of local devices
-      using the HCI protocol as described in the Bluetooth Core Specification.
-      Any user may open an HCI socket but there are limitations on what
-      unprivileged users can send and receive. The local address specified by
-      bind(2) may be used to select the device that the socket
-      will receive packets from. If BDADDR_ANY is
-      specified then the socket will receive packets from all devices on the
-      system. connect(2) may be used to create connections
-      such that packets sent with send(2) will be delivered to
-      the specified device, otherwise sendto(2) should be
-      used.
-    
The bt_psm and
-        bt_channel fields in the sockaddr_bt structure are
-        ignored by HCI protocol code and should be set to zero.

-    
HCI socket options:

-    

-      

-        [struct hci_filter]

-      
This filter controls which events will be received at the socket. See
-          <netbt/hci.h> for
-          available events. By default, Command_Complete and Command_Status
-          events only are enabled.

-      

-        [struct hci_filter]

-      
This filter controls the type of packets that will be received at the
-          socket. By default, Event packets only are enabled.

-      

-        [int]

-      
When set, this enables control messages on packets received at the
-          socket indicating the direction of travel of the packet.

-    

-    
HCI sysctl(8) controls:

-    

-      

-      
Default send buffer size for HCI sockets.

-      

-      
Default receive buffer size for HCI sockets

-      

-      
If set, this is the time in seconds after which unused ACL data
-          connections will be expired. If zero, connections will not be
-        closed.

-      

-      
Time, in seconds, that the system will keep records of Bluetooth
-          devices in the vicinity after an Inquiry Response packet has been
-          received. This information is used for routing purposes.

-      

-      
The maximum number of packets on the low level Event queue.

-      

-      
The maximum number of packets on the low level ACL queue.

-      

-      
The maximum number of packets on the low level SCO queue.

-    

-  

-  

-  
L2CAP sockets give sequential packet access over channels to other
-      Bluetooth devices and make use of the bt_psm field
-      in the sockaddr_bt structure to select the
-      Protocol/Service Multiplexer to specify when making connections. If the
-      special value of L2CAP_PSM_ANY is bound when the
-      listen(2) call is made, the next available PSM from the
-      dynamic range above 0x1001 will be selected and may be discovered using
-      the getsockname(2) call.
-    
L2CAP socket options:

-    

-      

-        [uint16_t]

-      
Incoming MTU

-      

-        [uint16_t]

-      
Outgoing MTU (read-only)

-      

-        [int]

-      
Link Mode. The following bits may be set:
-        

-        

-          

-          
Request authentication (pairing).

-          

-          
Request encryption (includes auth).

-          

-          
Request secured link (encryption, plus change link key).

-        

-        
Link mode settings will be applied to the baseband link
-            during L2CAP connection establishment. If the L2CAP connection is
-            already established, EINPROGRESS may be
-            returned, and it is not possible to guarantee that data already
-            queued (from either end) will not be delivered. If the mode change
-            fails, the L2CAP connection will be aborted.

-      

-    

-    
L2CAP sysctl(8) controls:

-    

-      

-      
Default send buffer size for L2CAP sockets.

-      

-      
Default receive buffer size for L2CAP sockets.

-      

-      
Response Timeout eXpiry for L2CAP signals.

-      

-      
Extended Response Timeout eXpiry for L2CAP signals.

-    

-  

-  

-  
RFCOMM sockets provide streamed data over Bluetooth connection and make
-      use of the bt_psm, and
-      bt_channel fields in the
-      sockaddr_bt structure. The channel number must be
-      between 1 and 30 inclusive except that if the special value
-      RFCOMM_CHANNEL_ANY is bound, when the
-      listen(2) call is made, the first unused channel for the
-      relevant bdaddr will be allocated and may be discovered using the
-      getsockname(2) call. If no PSM is specified, a default
-      value of L2CAP_PSM_RFCOMM (0x0003) will be used.
-    
RFCOMM socket options:

-    

-      

-        [uint16_t]

-      
Maximum Frame Size to use for this link.

-      

-        [int]

-      
Link Mode. The following bits may be set at any time:
-        

-        

-          

-          
Request authentication (pairing).

-          

-          
Request encryption (includes auth).

-          

-          
Request secured link (encryption, plus change link key).

-        

-        
Link mode settings will be applied to the baseband link
-            during RFCOMM connection establishment. If the RFCOMM connection is
-            already established, EINPROGRESS may be
-            returned, and it is not possible to guarantee that data already
-            queued (from either end) will not be delivered. If the mode change
-            fails, the RFCOMM connection will be aborted.

-      

-    

-    
RFCOMM sysctl(8) controls:

-    

-      

-      
Default send buffer size for RFCOMM sockets.

-      

-      
Default receive buffer size for RFCOMM sockets.

-      

-      
Maximum Frame Size (N1)

-      

-      
Acknowledgement Timer (T1)

-      

-      
Response Timer for Multiplexer Control Channel (T2)

-    

-  

-  

-  
SCO sockets provide sequential packet access to time sensitive data
-      channels over Bluetooth connections, typically used for audio data.
-    
SCO socket options:

-    

-      

-        [uint16_t]

-      
Maximum packet size for use on this link. This is read-only and will
-          be set by the protocol code when a connection is made. Currently, due
-          to limitations in the ubt(4) driver, the SCO
-          protocol code will only accept packets with exactly this size.

-      

-        [uint16_t]

-      
Connection handle for this link. This is read-only and provided for
-          informational purposes only.

-    

-    
SCO sysctl(8) controls:

-    

-      

-      
Default send buffer size for SCO sockets.

-      

-      
Default receive buffer size for SCO sockets.

-    

-  

-

-

-

-

-
The following ioctl(2) calls may be used to
-    manipulate Bluetooth devices. The ioctl(2) must be made on
-    BTPROTO_HCI sockets. All of the requests take a
-    btreq structure defined as follows as their parameter
-    and unless otherwise specified, use the btr_name field
-    to identify the device.

-

-
struct btreq {
-    char btr_name[HCI_DEVNAME_SIZE];	/* device name */
-
-    union {
-	struct {
-	    bdaddr_t btri_bdaddr;	/* device bdaddr */
-	    uint16_t btri_flags;	/* flags */
-	    uint16_t btri_num_cmd;	/* # of free cmd buffers */
-	    uint16_t btri_num_acl;	/* # of free ACL buffers */
-	    uint16_t btri_num_sco;	/* # of free SCO buffers */
-	    uint16_t btri_acl_mtu;	/* ACL mtu */
-	    uint16_t btri_sco_mtu;	/* SCO mtu */
-	    uint16_t btri_link_policy;	/* Link Policy */
-	    uint16_t btri_packet_type;	/* Packet Type */
-	    uint16_t btri_max_acl;	/* max ACL buffers */
-	    uint16_t btri_max_sco;	/* max SCO buffers */
-	} btri;
-	struct {
-	    uint8_t btrf_page0[HCI_FEATURES_SIZE]; /* basic */
-	    uint8_t btrf_page1[HCI_FEATURES_SIZE]; /* extended page 1 */
-	    uint8_t btrf_page2[HCI_FEATURES_SIZE]; /* extended page 2 */
-	} btrf;
-	struct bt_stats btrs;   /* unit stats */
-    } btru;
-};
-
-#define btr_flags	btru.btri.btri_flags
-#define btr_bdaddr	btru.btri.btri_bdaddr
-#define btr_num_cmd	btru.btri.btri_num_cmd
-#define btr_num_acl	btru.btri.btri_num_acl
-#define btr_num_sco	btru.btri.btri_num_sco
-#define btr_acl_mtu	btru.btri.btri_acl_mtu
-#define btr_sco_mtu	btru.btri.btri_sco_mtu
-#define btr_link_policy btru.btri.btri_link_policy
-#define btr_packet_type btru.btri.btri_packet_type
-#define btr_max_acl	btru.btri.btri_max_acl
-#define btr_max_sco	btru.btri.btri_max_sco
-#define btr_features0	btru.btrf.btrf_page0
-#define btr_features1	btru.btrf.btrf_page1
-#define btr_features2	btru.btrf.btrf_page2
-#define btr_stats	btru.btrs
-
-/* btr_flags */
-#define BTF_UP			(1<<0)	/* unit is up */
-#define BTF_RUNNING		(1<<1)	/* unit is running */
-#define BTF_XMIT_CMD		(1<<2)	/* transmitting CMD packets */
-#define BTF_XMIT_ACL		(1<<3)	/* transmitting ACL packets */
-#define BTF_XMIT_SCO		(1<<4)	/* transmitting SCO packets */
-#define BTF_INIT_BDADDR		(1<<5)	/* waiting for bdaddr */
-#define BTF_INIT_BUFFER_SIZE	(1<<6)	/* waiting for buffer size */
-#define BTF_INIT_FEATURES	(1<<7)	/* waiting for features */
-#define BTF_NOOP_ON_RESET	(1<<8)	/* wait for No-op on reset */
-#define BTF_INIT_COMMANDS	(1<<9)	/* waiting for supported commands */
-#define BTF_MASTER		(1<<10)	/* request Master role */
-
-struct bt_stats {
-	uint32_t	err_tx;
-	uint32_t	err_rx;
-	uint32_t	cmd_tx;
-	uint32_t	evt_rx;
-	uint32_t	acl_tx;
-	uint32_t	acl_rx;
-	uint32_t	sco_tx;
-	uint32_t	sco_rx;
-	uint32_t	byte_tx;
-	uint32_t	byte_rx;
-};
-
-

-

-

-  

-  
Get Bluetooth device Info. Given the device name, fill in the btreq
-      structure including the address field for use with socket addressing as
-      above.

-  

-  
Get Bluetooth device Info from Address. Given the device address, fill in
-      the btreq structure including the name field.

-  

-  
Next Bluetooth device Info. If name field is empty, the first device will
-      be returned. Otherwise, the next device will be returned until no more
-      devices are found when the call will fail, with error
-      ENXIO. Thus, you can cycle through all devices in
-      the system.

-  

-  
Set Bluetooth device Flags. Not all flags are settable.

-  

-  
Get Bluetooth device Features. This returns the cached basic (page 0) and
-      extended (page 1 & 2) features.

-  

-  
Set Bluetooth device Link Policy. Link Policy bits are defined in
-      <netbt/hci.h>, though you
-      can only set bits that the device supports.

-  

-  
Set Bluetooth device Packet Types. You can only set packet types that the
-      device supports.

-  

-  
Read device statistics.

-  

-  
Read device statistics, and zero them.

-

-
Only the super-user may change device configurations.

-

-

-

-
bind(2), getsockname(2),
-    bluetooth(3), bcsp(4),
-    bt3c(4), btbc(4),
-    btuart(4), options(4),
-    ubt(4)

-

-

-

-
The Bluetooth Protocol Stack was written for
-    NetBSD 4.0 by Iain Hibbert
-    under the sponsorship of Itronix, Inc.

-

-

-
-  
-    
-    
-  
-
November 20, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/bmtphy.4 4.html b/static/netbsd/man4/bmtphy.4 4.html
deleted file mode 100644
index afa6a3c2..00000000
--- a/static/netbsd/man4/bmtphy.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
BMTPHY(4)Device Drivers ManualBMTPHY(4)

-

-

-

-
bmtphy — Driver
-    for Broadcom BCM5201 and BCM5202 “Mini-Theta” Ethernet PHYs
-    and their derivatives

-

-

-

-
bmtphy* at mii? phy ?

-

-

-

-
The bmtphy driver supports the Broadcom
-    BCM5201 and BCM5202 10/100 Ethernet PHYs and their derivatives such as
-    BCM5214, BCM5221, BCM5222, and BCM4401. It also supports the internal PHY on
-    the 3Com 3c905C 10/100 Ethernet interface, and the internal PHY on some 3Com
-    3c905B 10/100 Ethernet interfaces.

-

-

-

-
ex(4), ifmedia(4),
-    intro(4), mii(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
January 17, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/bmx280thp.4 4.html b/static/netbsd/man4/bmx280thp.4 4.html
deleted file mode 100644
index 5bdcdc85..00000000
--- a/static/netbsd/man4/bmx280thp.4 4.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
BMX280THP(4)Device Drivers ManualBMX280THP(4)

-

-

-

-
bmx280thp — Driver
-    for Bosch BMP280/BME280 sensor chip via I2C bus

-

-

-

-
bmx280thp* at iic? addr 0x76
-  

-  bmx280thp* at iic? addr 0x77

-

-  

-  bmx280thp* at spi? slave 0
-  

-  bmx280thp* at spi? slave 1

-

-

-

-
The bmx280thp driver provides measurements
-    from the BMP280 and BME280 temperature, humidity and barometric pressure
-    sensors via the envsys(4) framework. The
-    bmx280thp addr argument
-    selects the address at the iic(4) bus and the
-    bmx280thp slave argument
-    selects which chip select will be used on the spi(4) bus.
-    The precision of the measurement which is related to the over sampling
-    performed on the measurement can be changed through
-    sysctl(8) nodes.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
 

-  

-  
 

-  

-  
These control oversampling of temperature, pressure and humidity. The
-      valid values are 1, 2, 4, 8, and 16 times oversample. Humidity is only
-      available if the chip is a BME280.

-  

-  
IRR is a filter that can be used to reduce the noise in the measurement.
-      The value values are 1 (or off), 2, 5, 11 and 22 samples to reach >=
-      75% of the step response.

-  

-  
 

-  

-  
 

-  

-  
These control the wait multiplication factor for a measurement cycle. This
-      factor is different for temperature, pressure and humidity and is based
-      upon the values of osrs_t, osrs_p and osrs_h. If the chip does not return
-      the correct measurements for a given over sampling then the wait factors
-      can be adjusted to allow more time for the measurement to complete
-      successfully.

-  

-  
 

-  

-  
If the driver is compiled with BMX280_DEBUG, these
-      nodes will appear and can be used to set the debugging level and provide
-      the calibration constants, upon refresh, that are stored in the chip.
-      Since the constants are fixed, this is a boolean node and will reset back
-      to false once one dump has been performed.

-  

-  
A status register tells the driver if the chip is busy with a measurement.
-      This status register must be polled and readattempts is the number of
-      times that this poll will be performed. The default is 25 which should be
-      more than enough for most purposes.

-

-

-

-

-
envsys(4), iic(4),
-    spi(4), envstat(8),
-    sysctl(8)

-

-

-

-
The bmx280thp driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The bmx280thp driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The driver does not support the continuous read mode that the
-    BMP280 and BME280 has.

-

-

-
-  
-    
-    
-  
-
November 19, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/bnx.4 4.html b/static/netbsd/man4/bnx.4 4.html
deleted file mode 100644
index 3c1a9df8..00000000
--- a/static/netbsd/man4/bnx.4 4.html	
+++ /dev/null
@@ -1,132 +0,0 @@
-
-  
-    
-    
-    
-  
-
BNX(4)Device Drivers ManualBNX(4)

-

-

-

-
bnx — Broadcom
-    NetXtreme II 10/100/1000 Ethernet device

-

-

-

-
bnx* at pci?
-  

-  brgphy* at mii?

-

-

-

-
The bnx driver supports Broadcom's
-    NetXtreme II product family, such as the BCM5706 PCI-X and
-    BCM5708-BCM5709-BCM5716 PCIe Ethernet controllers, which includes the
-    following:

-

-
    
-  
  • Dell PowerEdge 1950 integrated BCM5708 NIC (10/100/1000baseT)
    • 
-  
  • Dell PowerEdge 2950 integrated BCM5708 NIC (10/100/1000baseT)
    • 
-  
  • Dell PowerEdge M710 integrated BCM5709S NIC (1000baseSX)
    • 
-  
  • Dell PowerEdge R710 integrated BCM5709 NIC
    • 
-  
  • HP NC370F PCI-X Multifunction Gigabit server adapter (1000baseSX)
    • 
-  
  • HP NC370T PCI-X Multifunction Gigabit server adapter
-    (10/100/1000baseT)
    • 
-  
  • HP NC370i Multifunction Gigabit Server Adapter
    • 
-  
  • HP NC371i Multifunction Gigabit Server Adapter
    • 
-  
  • HP NC373F PCIe Multifunction Gigabit server adapter (1000baseSX)
    • 
-  
  • HP NC373T PCIe Multifunction Gigabit server adapter
-    (10/100/1000baseT)
    • 
-  
  • HP NC373i PCIe Multifunction Gigabit embedded server adapter
-      (10/100/1000baseT)
    • 
-  
  • HP NC373m Multifunction Gigabit Server Adapter
    • 
-  
  • HP NC374m PCIe Multifunction Gigabit embedded server adapter
-      (10/100/1000baseT)
    • 
-  
  • HP NC380T PCIe Dual Port Multifunction Gigabit server adapter
-      (10/100/1000baseT)
    • 
-  
  • HP NC382T PCIe Dual Port server adapter (10/100/1000baseT)
    • 
-  
  • HP NC382i DP Multifunction Gigabit Server Adapter
    • 
-  
  • HP NC382m DP 1GbE Multifunction BL-c Adapter
    • 
-  
  • IBM xSeries 3550 integrated BCM5708 NIC (10/100/1000baseT)
    • 
-  
  • IBM xSeries 3650 integrated BCM5708 NIC (10/100/1000baseT)
    • 
-

-
The NetXtreme II product family is composed of various Converged
-    NIC (or CNIC) Ethernet controllers which support a TCP Offload Engine (TOE),
-    Remote DMA (RDMA), and iSCSI acceleration, in addition to standard L2
-    Ethernet traffic, all on the same controller. The following features are
-    supported in the bnx driver under
-    NetBSD:

-

-
IPv4 receive IP/TCP/UDP checksum offload
-Jumbo frames (up to 9022 bytes)
-VLAN tag insertion
-Interrupt coalescing
-10/100/1000Mbps operation in full-duplex mode
-10/100Mbps operation in half-duplex mode

-

-
The bnx driver supports the following
-    media types:

-

-  

-  
Enable autoselection of the media type and options. The user can manually
-      override the autoselected mode via ifconfig(8).

-  

-  
Set 10Mbps operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 1000baseTX operation over twisted pair. Only
-      full-duplex mode is supported.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation. Both
-      full-duplex and
-      half-duplex modes are supported.

-  

-  
Set 2500Mbps operation. Only full-duplex mode is
-      supported.

-

-
The bnx driver supports the following
-    media options:

-

-  

-  
Force full duplex operation.

-  

-  
Force half duplex operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
arp(4), brgphy(4),
-    ifmedia(4), intro(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The bnx driver was written by
-    David Christensen
-    <davidch@broadcom.com>
-    in FreeBSD, where it is called
-    bce. And it's ported to
-    OpenBSD by Brad Smith
-    <brad@openbsd.org>.
-    It's ported to NetBSD by Quentin Garnier. The
-    bnx device driver first appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
March 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/boca.4 4.html b/static/netbsd/man4/boca.4 4.html
deleted file mode 100644
index e819a44a..00000000
--- a/static/netbsd/man4/boca.4 4.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOCA(4)Device Drivers ManualBOCA(4)

-

-

-

-
boca —
-    multiplexing serial communications interface

-

-

-

-
For 4-port BB1004 boards:

-

-  

-  boca0 at isa? port 0x100 irq 5
-  

-  com2 at boca? slave ?
-  

-  com3 at boca? slave ?
-  

-  com4 at boca? slave ?
-  

-  com5 at boca? slave ?

-
For 8-port BB1008 boards:

-

-  

-  boca0 at isa? port 0x100 irq 5
-  

-  com2 at boca? slave ?
-  

-  com3 at boca? slave ?
-  

-  com4 at boca? slave ?
-  

-  com5 at boca? slave ?
-  

-  com6 at boca? slave ?
-  

-  com7 at boca? slave ?
-  

-  com8 at boca? slave ?
-  

-  com9 at boca? slave ?

-
For 16-port BB2016 boards:

-

-  

-  boca0 at isa? port 0x100 irq 5
-  

-  com2 at boca? slave ?
-  

-  com3 at boca? slave ?
-  

-  com4 at boca? slave ?
-  

-  com5 at boca? slave ?
-  

-  com6 at boca? slave ?
-  

-  com7 at boca? slave ?
-  

-  com8 at boca? slave ?
-  

-  com9 at boca? slave ?
-  

-  boca1 at isa? port 0x140 irq 5
-  

-  com10 at boca? slave ?
-  

-  com11 at boca? slave ?
-  

-  com12 at boca? slave ?
-  

-  com13 at boca? slave ?
-  

-  com14 at boca? slave ?
-  

-  com15 at boca? slave ?
-  

-  com16 at boca? slave ?
-  

-  com17 at boca? slave ?

-
(The BB2016 is functionally equivalent to two BB1008 boards, and
-    is configured as such.)

-

-

-

-
The boca driver provides support for BOCA
-    Research BB1004, BB1008 and BB2016 boards that multiplex together up to
-    four, eight or sixteen EIA RS-232C (CCITT V.28) communications
-  interfaces.

-
Each boca device is the master device for
-    up to eight com devices. The kernel configuration
-    specifies these com devices as slave devices of the
-    boca device, as shown in the synopsis. The slave ID
-    given for each com device determines which bit in
-    the interrupt multiplexing register is tested to find interrupts for that
-    device. The port specification for the boca device
-    is used to compute the base addresses for the com
-    subdevices and the port for the interrupt multiplexing register.

-

-

-

-

-  
/dev/tty??

-  
 

-

-

-

-

-
com(4)

-

-

-

-
The boca driver was written by Charles
-    Hannum, based on the ast driver and source code from
-    David Muir Sharnoff. David wishes to acknowledge the assistance of Jason
-    Venner in determining how to use the BOCA boards.

-

-

-
-  
-    
-    
-  
-
January 3, 1995NetBSD 10.1

diff --git a/static/netbsd/man4/bochsfb.4 4.html b/static/netbsd/man4/bochsfb.4 4.html
deleted file mode 100644
index f0d2c1fd..00000000
--- a/static/netbsd/man4/bochsfb.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOCHSFB(4)Device Drivers ManualBOCHSFB(4)

-

-

-

-
bochsfb — Bochs
-    Display Interface framebuffer

-

-

-

-
bochsfb* at pci?
-  

-  wsdisplay* at bochsfb?

-

-

-
options
-    BOCHSFB_DEFAULT_WIDTH=integer
-  

-  options
-    BOCHSFB_DEFAULT_HEIGHT=integer

-

-

-

-

-
The bochsfb driver provides support for
-    graphics devices implementing the Bochs VBE DISPI interface, including the
-    Bochs reference VGA implementation, and the QEMU StdVGA device. It programs
-    the linear framebuffer through the DISPI registers and makes it available
-    through wsdisplay(4) as a console or
-    wsfb(4) compatible framebuffer.

-
When a memory-mapped DISPI bar with an EDID block is present,
-    bochsfb uses the preferred mode reported by the
-    display. Devices without EDID support (such as virtio-vga) fall back to a
-    1024x768 32-bit mode. If no MMIO bar is available, the driver accesses the
-    DISPI registers via the legacy VGA I/O ports.

-

-

-

-
intro(4), pci(4),
-    vga(4), wscons(4),
-    wsdisplay(4)

-

-

-

-
The bochsfb driver first appeared in
-    NetBSD 12.0.

-

-

-

-
The bochsfb driver was written by
-    Jiaxun Yang
-    <jiaxun.yang@flygoat.com>.

-

-

-
-  
-    
-    
-  
-
March 2, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/bpf.4 3.html b/static/netbsd/man4/bpf.4 3.html
deleted file mode 100644
index c1a782d1..00000000
--- a/static/netbsd/man4/bpf.4 3.html	
+++ /dev/null
@@ -1,838 +0,0 @@
-
-  
-    
-    
-    
-  
-
BPF(4)Device Drivers ManualBPF(4)

-

-

-

-
bpf — Berkeley
-    Packet Filter raw network interface

-

-

-

-
pseudo-device bpfilter

-

-

-

-
The Berkeley Packet Filter provides a raw interface to data link
-    layers in a protocol independent fashion. All packets on the network, even
-    those destined for other hosts, are accessible through this mechanism.

-
The packet filter appears as a character special device,
-    /dev/bpf. After opening the device, the file
-    descriptor must be bound to a specific network interface with the
-    BIOCSETIF ioctl. A given interface can be shared by
-    multiple listeners, and the filter underlying each descriptor will see an
-    identical packet stream.

-
Associated with each open instance of a
-    bpf file is a user-settable packet filter. Whenever
-    a packet is received by an interface, all file descriptors listening on that
-    interface apply their filter. Each descriptor that accepts the packet
-    receives its own copy.

-
Reads from these files return the next group of packets that have
-    matched the filter. To improve performance, the buffer passed to read must
-    be the same size as the buffers used internally by
-    bpf. This size is returned by the
-    BIOCGBLEN ioctl (see below), and can be set with
-    BIOCSBLEN. Note that an individual packet larger
-    than this size is necessarily truncated.

-
Since packet data is in network byte order, applications should
-    use the byteorder(3) macros to extract multi-byte
-  values.

-
A packet can be sent out on the network by writing to a
-    bpf file descriptor. The writes are unbuffered,
-    meaning only one packet can be processed per write. Currently, only writes
-    to Ethernet-based (including Wi-Fi), SLIP and loopback links are
-  supported.

-

-

-

-
The ioctl(2) command codes below are defined in
-    <net/bpf.h>. All commands
-    require these includes:

-

-
#include <sys/types.h>
-#include <sys/time.h>
-#include <sys/ioctl.h>
-#include <net/bpf.h>

-

-
Additionally, BIOCGETIF and
-    BIOCSETIF require
-    <net/if.h>.

-
The (third) argument to the ioctl(2) should be a
-    pointer to the type indicated.

-

-  

-    (u_int)

-  
Returns the required buffer length for reads on
-      bpf files.

-  

-    (u_int)

-  
Sets the buffer length for reads on bpf files. The
-      buffer must be set before the file is attached to an interface with
-      BIOCSETIF. If the requested buffer size cannot be
-      accommodated, the closest allowable size will be set and returned in the
-      argument. A read call will result in EINVAL if it
-      is passed a buffer that is not this size.

-  

-    (u_int)

-  
Returns the type of the data link layer underlying the attached interface.
-      EINVAL is returned if no interface has been
-      specified. The device types, prefixed with
-      ‘DLT_’, are defined in
-      <net/bpf.h>.

-  

-    (struct bpf_dltlist)

-  
Returns an array of the available types of the data link layer underlying
-      the attached interface:
-    

-    
struct bpf_dltlist {
-	u_int bfl_len;
-	u_int *bfl_list;
-};

-    

-    
The available types are returned in the array pointed to by
-        the bfl_list field while their length in
-        u_int is supplied to the
-        bfl_len field. ENOMEM is
-        returned if there is not enough buffer space and
-        EFAULT is returned if a bad address is
-        encountered. The bfl_len field is modified on
-        return to indicate the actual length in u_int of the array returned. If
-        bfl_list is NULL, the
-        bfl_len field is set to indicate the required
-        length of an array in u_int.

-  

-  

-    (u_int)

-  
Changes the type of the data link layer underlying the attached interface.
-      EINVAL is returned if no interface has been
-      specified or the specified type is not available for the interface.

-  

-  
Forces the interface into promiscuous mode. All packets, not just those
-      destined for the local host, are processed. Since more than one file can
-      be listening on a given interface, a listener that opened its interface
-      non-promiscuously may receive packets promiscuously. This problem can be
-      remedied with an appropriate filter.
-    
The interface remains in promiscuous mode until all files
-        listening promiscuously are closed.

-  

-  

-  
Flushes the buffer of incoming packets, and resets the statistics that are
-      returned by BIOCGSTATS.

-  

-    (struct ifreq)

-  
Returns the name of the hardware interface that the file is listening on.
-      The name is returned in the ifr_name field of
-      ifreq. All other fields are undefined.

-  

-    (struct ifreq)

-  
Sets the hardware interface associated with the file. This command must be
-      performed before any packets can be read. The device is indicated by name
-      using the ifr_name field of the
-      ifreq. Additionally, performs the actions of
-      BIOCFLUSH.

-  
,
-    BIOCGRTIMEOUT (struct
-    timeval)

-  
Sets or gets the “read timeout” parameter.
-      The timeval specifies the length of time to wait
-      before timing out on a read request. This parameter is initialized to zero
-      by open(2), indicating no timeout.

-  

-    (struct bpf_stat)

-  
Returns the following structure of packet statistics:
-    

-    
struct bpf_stat {
-	uint64_t bs_recv;
-	uint64_t bs_drop;
-	uint64_t bs_capt;
-	uint64_t bs_padding[13];
-};

-    

-    
The fields are:

-    

-    

-      
bs_recv

-      
the number of packets received by the descriptor since opened or reset
-          (including any buffered since the last read call);

-      
bs_drop

-      
the number of packets which were accepted by the filter but dropped by
-          the kernel because of buffer overflows (i.e., the application's reads
-          aren't keeping up with the packet traffic); and

-      
bs_capt

-      
the number of packets accepted by the filter.

-    

-    

-  

-  

-    (u_int)

-  
Enables or disables
-      “”, based on the truth value of the argument. When
-      immediate mode is enabled, reads return immediately upon packet reception.
-      Otherwise, a read will block until either the kernel buffer becomes full
-      or a timeout occurs. This is useful for programs like
-      rarpd(8), which must respond to messages in real time.
-      The default for a new file is off.

-  

-    (NULL)

-  
Set the locked flag on the bpf descriptor. This prevents the execution of
-      ioctl commands which could change the underlying operating parameters of
-      the device.

-  

-    (struct bpf_program)

-  
Sets the filter program used by the kernel to discard uninteresting
-      packets. An array of instructions and its length are passed in using the
-      following structure:
-    

-    
struct bpf_program {
-	u_int bf_len;
-	struct bpf_insn *bf_insns;
-};

-    

-    
The filter program is pointed to by the
-        bf_insns field while its length in units of
-        struct bpf_insn is given by the
-        bf_len field. Also, the actions of
-        BIOCFLUSH are performed.

-    
See section FILTER
-        MACHINE for an explanation of the filter language.

-  

-  

-    (struct bpf_program)

-  
Sets the write filter program used by the kernel to control what type of
-      packets can be written to the interface. See the
-      BIOCSETF command for more information on the bpf
-      filter program.

-  

-    (struct bpf_version)

-  
Returns the major and minor version numbers of the filter language
-      currently recognized by the kernel. Before installing a filter,
-      applications must check that the current version is compatible with the
-      running kernel. Version numbers are compatible if the major numbers match
-      and the application minor is less than or equal to the kernel minor. The
-      kernel version number is returned in the following structure:
-    

-    
struct bpf_version {
-	u_short bv_major;
-	u_short bv_minor;
-};

-    

-    
The current version numbers are given by
-        BPF_MAJOR_VERSION and
-        BPF_MINOR_VERSION from
-        <net/bpf.h>. An
-        incompatible filter may result in undefined behavior (most likely, an
-        error returned by ioctl(2) or haphazard packet
-        matching).

-  

-  
,
-    BIOCGRSIG (u_int)

-  
Sets or gets the receive signal. This signal will be sent to the process
-      or process group specified by FIOSETOWN. It
-      defaults to SIGIO.

-  
,
-    BIOCSHDRCMPLT (u_int)

-  
Sets or gets the status of the “header complete” flag. Set
-      to zero if the link level source address should be filled in automatically
-      by the interface output routine. Set to one if the link level source
-      address will be written, as provided, to the wire. This flag is
-      initialized to zero by default.

-  
,
-    BIOCSSEESENT (u_int)

-  
These commands are obsolete but left for compatibility. Use
-      BIOCSDIRECTION and
-      BIOCGDIRECTION instead. Set or get the flag
-      determining whether locally generated packets on the interface should be
-      returned by BPF. Set to zero to see only incoming packets on the
-      interface. Set to one to see packets originating locally and remotely on
-      the interface. This flag is initialized to one by default.

-  
,
-    BIOCGDIRECTION (u_int)

-  
Set or get the setting determining whether incoming, outgoing, or all
-      packets on the interface should be returned by BPF. Set to
-      BPF_D_IN to see only incoming packets on the
-      interface. Set to BPF_D_INOUT to see packets
-      originating locally and remotely on the interface. Set to
-      BPF_D_OUT to see only outgoing packets on the
-      interface. This setting is initialized to
-      BPF_D_INOUT by default.

-  
,
-    BIOCSFEEDBACK, BIOCGFEEDBACK
-    (u_int)

-  
Set (or get) “packet feedback mode”. This allows injected
-      packets to be fed back as input to the interface when output via the
-      interface is successful. The first name is meant for
-      FreeBSD compatibility, the two others follow the
-      Get/Set convention. Injected outgoing packets are not returned by BPF to
-      avoid duplication. This flag is initialized to zero by default.

-

-

-

-

-
bpf supports several standard
-    ioctl(2)'s which allow the user to do async and/or
-    non-blocking I/O to an open bpf file descriptor.

-

-  

-    (int)

-  
Returns the number of bytes that are immediately available for
-    reading.

-  

-    (int)

-  
Set or clear non-blocking I/O. If arg is non-zero, then doing a
-      read(2) when no data is available will return -1 and
-      errno will be set to EAGAIN.
-      If arg is zero, non-blocking I/O is disabled. Note: setting this overrides
-      the timeout set by BIOCSRTIMEOUT.

-  

-    (int)

-  
Enable or disable async I/O. When enabled (arg is non-zero), the process
-      or process group specified by FIOSETOWN will start
-      receiving SIGIO's when packets arrive. Note that
-      you must do an FIOSETOWN in order for this to take
-      effect, as the system will not default this for you. The signal may be
-      changed via BIOCSRSIG.

-  
,
-    FIOGETOWN (int)

-  
Set or get the process or process group (if negative) that should receive
-      SIGIO when packets are available. The signal may
-      be changed using BIOCSRSIG (see above).

-

-

-

-

-
The following structure is prepended to each packet returned by
-    read(2):

-

-
struct bpf_hdr {
-	struct bpf_timeval bh_tstamp;
-	uint32_t bh_caplen;
-	uint32_t bh_datalen;
-	uint16_t bh_hdrlen;
-};

-

-
The fields, whose values are stored in host order, are:

-

-

-  
bh_tstamp

-  
The time at which the packet was processed by the packet filter. This
-      structure differs from the standard struct timeval
-      in that both members are of type long.

-  
bh_caplen

-  
The length of the captured portion of the packet. This is the minimum of
-      the truncation amount specified by the filter and the length of the
-      packet.

-  
bh_datalen

-  
The length of the packet off the wire. This value is independent of the
-      truncation amount specified by the filter.

-  
bh_hdrlen

-  
The length of the BPF header, which may not be equal to
-      sizeof(struct bpf_hdr).

-

-

-
The bh_hdrlen field exists to
-    account for padding between the header and the link level protocol. The
-    purpose here is to guarantee proper alignment of the packet data structures,
-    which is required on alignment sensitive architectures and improves
-    performance on many other architectures. The packet filter ensures that the
-    bpf_hdr and the
-    
-    header will be word aligned. Suitable precautions must be taken when
-    accessing the link layer protocol fields on alignment restricted machines.
-    (This isn't a problem on an Ethernet, since the type field is a short
-    falling on an even offset, and the addresses are probably accessed in a
-    bytewise fashion).

-
Additionally, individual packets are padded so that each starts on
-    a word boundary. This requires that an application has some knowledge of how
-    to get from packet to packet. The macro
-    BPF_WORDALIGN is defined in
-    <net/bpf.h> to facilitate
-    this process. It rounds up its argument to the nearest word aligned value
-    (where a word is BPF_ALIGNMENT bytes wide).

-
For example, if p points to the start of a
-    packet, this expression will advance it to the next packet:

-

-
p = (char *)p +
-  BPF_WORDALIGN(p->bh_hdrlen + p->bh_caplen)

-
For the alignment mechanisms to work properly, the buffer passed
-    to read(2) must itself be word aligned.
-    malloc(3) will always return an aligned buffer.

-

-

-

-
A filter program is an array of instructions, with all branches
-    , terminated by a
-    
-    instruction. Each instruction performs some action on the pseudo-machine
-    state, which consists of an accumulator, index register, scratch memory
-    store, and implicit program counter.

-
The following structure defines the instruction format:

-

-
struct bpf_insn {
-	uint16_t code;
-	u_char 	jt;
-	u_char 	jf;
-	uint32_t k;
-};

-

-
The k field is used in different
-    ways by different instructions, and the jt and
-    jf fields are used as offsets by the branch
-    instructions. The opcodes are encoded in a semi-hierarchical fashion. There
-    are eight classes of instructions: BPF_LD,
-    BPF_LDX, BPF_ST,
-    BPF_STX, BPF_ALU,
-    BPF_JMP, BPF_RET, and
-    BPF_MISC. Various other mode and operator bits are
-    'd into the class to
-    give the actual instructions. The classes and modes are defined in
-    <net/bpf.h>.

-
Below are the semantics for each defined BPF instruction. We use
-    the convention that A is the accumulator,
-    X is the index register, P
-    packet data, and M scratch memory store.
-    P[i:n]
-    gives the data at byte offset i in the packet,
-    interpreted as a word (n = 4),
-    unsigned halfword (n = 2), or
-    unsigned byte (n = 1).
-    M[i]
-    gives the i'th word in the scratch memory store, which
-    is only addressed in word units. The memory store is indexed from 0 to
-    BPF_MEMWORDS-1.
-    k, jt, and
-    jf are the corresponding fields in the instruction
-    definition. len refers to the length of the
-  packet.

-

-  

-  
These instructions copy a value into the accumulator. The type of the
-      source operand is specified by an “addressing mode” and can
-      be a constant
-      (),
-      packet data at a fixed offset (BPF_ABS), packet data at
-      a variable offset (BPF_IND), the packet length
-      (),
-      or a word in the scratch memory store
-      ().
-      For BPF_IND and BPF_ABS, the data size
-      must be specified as a word
-      (),
-      halfword
-      (),
-      or byte
-      ().
-      Arithmetic overflow when calculating a variable offset terminates the
-      filter program and the packet is ignored. The semantics of all the
-      recognized BPF_LD instructions follow.
-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_LD + BPF_W + BPF_ABSA ← P[k:4]
BPF_LD + BPF_H + BPF_ABSA ← P[k:2]
BPF_LD + BPF_B + BPF_ABSA ← P[k:1]
BPF_LD + BPF_W + BPF_INDA ← P[X+k:4]
BPF_LD + BPF_H + BPF_INDA ← P[X+k:2]
BPF_LD + BPF_B + BPF_INDA ← P[X+k:1]
BPF_LD + BPF_W + BPF_LENA ← len
BPF_LD + BPF_IMMA ← k
BPF_LD + BPF_MEMA ← M[k]

-  

-  

-  
These instructions load a value into the index register. Note that the
-      addressing modes are more restricted than those of the accumulator loads,
-      but they include
-      ,
-      a hack for efficiently loading the IP header length.
-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_LDX + BPF_W + BPF_IMMX ← k
BPF_LDX + BPF_W + BPF_MEMX ← M[k]
BPF_LDX + BPF_W + BPF_LENX ← len
BPF_LDX + BPF_B + BPF_MSHX ← 4*(P[k:1]&0xf)

-  

-  

-  
This instruction stores the accumulator into the scratch memory. We do not
-      need an addressing mode since there is only one possibility for the
-      destination.
-    
-      
-        
-        
-      
-    
M[k] ← A

-  

-  

-  
This instruction stores the index register in the scratch memory store.
-    
-      
-        
-        
-      
-    
M[k] ← X

-  

-  

-  
The alu instructions perform operations between the accumulator and index
-      register or constant, and store the result back in the accumulator. For
-      binary operations, a source mode is required (BPF_K or
-      BPF_X).
-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_ALU + BPF_ADD + BPF_KA ← A + k
BPF_ALU + BPF_SUB + BPF_KA ← A - k
BPF_ALU + BPF_MUL + BPF_KA ← A * k
BPF_ALU + BPF_DIV + BPF_KA ← A / k
BPF_ALU + BPF_AND + BPF_KA ← A & k
BPF_ALU + BPF_OR + BPF_KA ← A | k
BPF_ALU + BPF_LSH + BPF_KA ← A ≪ k
BPF_ALU + BPF_RSH + BPF_KA ← A ≫ k
BPF_ALU + BPF_ADD + BPF_XA ← A + X
BPF_ALU + BPF_SUB + BPF_XA ← A - X
BPF_ALU + BPF_MUL + BPF_XA ← A * X
BPF_ALU + BPF_DIV + BPF_XA ← A / X
BPF_ALU + BPF_AND + BPF_XA ← A & X
BPF_ALU + BPF_OR + BPF_XA ← A | X
BPF_ALU + BPF_LSH + BPF_XA ← A ≪ X
BPF_ALU + BPF_RSH + BPF_XA ← A ≫ X
BPF_ALU + BPF_NEGA ← -A

-  

-  

-  
The jump instructions alter flow of control. Conditional jumps compare the
-      accumulator against a constant (BPF_K) or the index
-      register (BPF_X). If the result is true (or non-zero),
-      the true branch is taken, otherwise the false branch is taken. Jump
-      offsets are encoded in 8 bits so the longest jump is 256 instructions.
-      However, the jump always
-      ()
-      opcode uses the 32 bit k field as the offset,
-      allowing arbitrarily distant destinations. All conditionals use unsigned
-      comparison conventions.
-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_JMP + BPF_JApc += k
BPF_JMP + BPF_JGT + BPF_Kpc += (A > k) ? jt : jf
BPF_JMP + BPF_JGE + BPF_Kpc += (A ≥ k) ? jt : jf
BPF_JMP + BPF_JEQ + BPF_Kpc += (A == k) ? jt : jf
BPF_JMP + BPF_JSET + BPF_Kpc += (A & k) ? jt : jf
BPF_JMP + BPF_JGT + BPF_Xpc += (A > X) ? jt : jf
BPF_JMP + BPF_JGE + BPF_Xpc += (A ≥ X) ? jt : jf
BPF_JMP + BPF_JEQ + BPF_Xpc += (A == X) ? jt : jf
BPF_JMP + BPF_JSET + BPF_Xpc += (A & X) ? jt : jf

-  

-  

-  
The return instructions terminate the filter program and specify the
-      amount of packet to accept (i.e., they return the truncation amount). A
-      return value of zero indicates that the packet should be ignored. The
-      return value is either a constant (BPF_K) or the
-      accumulator
-      ().
-    
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_RET + BPF_Aaccept A bytes
BPF_RET + BPF_Kaccept k bytes

-  

-  

-  
The miscellaneous category was created for anything that doesn't fit into
-      the above classes, and for any new instructions that might need to be
-      added. Currently, these are the register transfer instructions that copy
-      the index register to the accumulator or vice versa.
-    
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_MISC + BPF_TAXX ← A
BPF_MISC + BPF_TXAA ← X

-    
Also, two instructions to call a
-        “”
-        if initialized by the kernel component. There is no coprocessor by
-        default.

-    
-      
-        
-        
-      
-      
-        
-        
-      
-    
BPF_MISC + BPF_COPA ← funcs[k](...)
BPF_MISC + BPF_COPXA ← funcs[X](...)

-    
If the coprocessor is not set or the function index is out of
-        range, these instructions will abort the program and return zero.

-  

-

-
The BPF interface provides the following macros to facilitate
-    array initializers:

-

-
(opcode, operand)
-(opcode, operand, true_offset, false_offset)

-

-

-

-

-
The following sysctls are available when
-    bpf is enabled:

-

-  

-  
Sets the maximum buffer size available for bpf
-      peers.

-  

-  
Shows bpf statistics. They can be retrieved with
-      the netstat(1) utility.

-  

-  
Shows the current bpf peers. This is only
-      available to the super user and can also be retrieved with the
-      netstat(1) utility.

-

-
On architectures with bpfjit(4) support, the
-    additional sysctl is available:

-

-  

-  
Toggle
-      
-      compilation of new filter programs. In order to enable just-in-time
-      compilation, the bpfjit kernel module must be loaded. Changing a value of
-      this sysctl doesn't affect existing filter programs.

-

-

-

-

-
/dev/bpf

-

-

-

-
The following filter is taken from the Reverse ARP Daemon. It
-    accepts only Reverse ARP requests.

-

-
struct bpf_insn insns[] = {
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_REVARP, 0, 3),
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, REVARP_REQUEST, 0, 1),
-	BPF_STMT(BPF_RET+BPF_K, sizeof(struct ether_arp) +
-	    sizeof(struct ether_header)),
-	BPF_STMT(BPF_RET+BPF_K, 0),
-};

-

-
This filter accepts only IP packets between host 128.3.112.15 and
-    128.3.112.35.

-

-
struct bpf_insn insns[] = {
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 8),
-	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 26),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x8003700f, 0, 2),
-	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 30),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x80037023, 3, 4),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x80037023, 0, 3),
-	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 30),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x8003700f, 0, 1),
-	BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
-	BPF_STMT(BPF_RET+BPF_K, 0),
-};

-

-
Finally, this filter returns only TCP finger
-    packets. We must parse the IP header to reach the TCP header. The
-    
-    instruction checks that the IP fragment offset is 0 so we are sure that we
-    have a TCP header.

-

-
struct bpf_insn insns[] = {
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 10),
-	BPF_STMT(BPF_LD+BPF_B+BPF_ABS, 23),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, IPPROTO_TCP, 0, 8),
-	BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 20),
-	BPF_JUMP(BPF_JMP+BPF_JSET+BPF_K, 0x1fff, 6, 0),
-	BPF_STMT(BPF_LDX+BPF_B+BPF_MSH, 14),
-	BPF_STMT(BPF_LD+BPF_H+BPF_IND, 14),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 79, 2, 0),
-	BPF_STMT(BPF_LD+BPF_H+BPF_IND, 16),
-	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 79, 0, 1),
-	BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
-	BPF_STMT(BPF_RET+BPF_K, 0),
-};

-

-

-

-

-
ioctl(2), read(2),
-    select(2), signal(3),
-    bpfjit(4), tcpdump(8)

-
S. McCanne and
-    V. Jacobson, The BSD Packet
-    Filter: A New Architecture for User-level Packet Capture,
-    Proceedings of the 1993 Winter USENIX,
-    Technical Conference, San Diego, CA.

-

-

-

-
The Enet packet filter was created in 1980 by Mike Accetta and
-    Rick Rashid at Carnegie-Mellon University. Jeffrey Mogul, at Stanford,
-    ported the code to BSD and continued its development from 1983 on. Since
-    then, it has evolved into the ULTRIX Packet Filter at DEC, a STREAMS NIT
-    module under SunOS 4.1, and BPF.

-

-

-

-
Steven McCanne, of Lawrence Berkeley
-    Laboratory, implemented BPF in Summer 1990. The design was in collaboration
-    with Van Jacobson, also of Lawrence Berkeley
-    Laboratory.

-

-

-

-
The read buffer must be of a fixed size (returned by the
-    BIOCGBLEN ioctl).

-
A file that does not request promiscuous mode may receive
-    promiscuously received packets as a side effect of another file requesting
-    this mode on the same hardware interface. This could be fixed in the kernel
-    with additional processing overhead. However, we favor the model where all
-    files must assume that the interface is promiscuous, and if so desired, must
-    use a filter to reject foreign packets.

-
“” and the “read timeout”
-    are misguided features. This functionality can be emulated with non-blocking
-    mode and select(2).

-

-

-
-  
-    
-    
-  
-
November 30, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/bpfjit.4 4.html b/static/netbsd/man4/bpfjit.4 4.html
deleted file mode 100644
index 36ff1112..00000000
--- a/static/netbsd/man4/bpfjit.4 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
BPFJIT(4)Device Drivers ManualBPFJIT(4)

-

-

-

-
bpfjit —
-    Just-In-Time compiler for Berkeley Packet Filter

-

-

-

-
options BPFJIT
-  

-  options SLJIT

-

-

-

-
The bpfjit kernel interface adds
-    Just-In-Time compilation of filter programs sent to a
-    bpf(4) device. Instead of being interpreted for every
-    packet, these filter programs are compiled into native code and the code is
-    being executed for every packet.

-
The implementation of
-    bpfjit is based on the
-     library, or sljit for short.
-    The library supports multiple platforms including

-
    
-  
  • AMD-x86 64
    • 
-  
  • ARM 32 (ARM-v5, ARM-v7 and Thumb2 instruction sets)
    • 
-  
  • Intel-x86 32
    • 
-  
  • MIPS 32 (III, R1)
    • 
-  
  • MIPS 64 (III, R1)
    • 
-  
  • PowerPC 32
    • 
-  
  • PowerPC 64
    • 
-  
  • SPARC 32
    • 
-

-
bpfjit supports all architectures listed
-    above.

-
bpfjit is also available as a module in
-    modular kernels.

-

-

-

-
The following sysctl is available when
-    bpfjit is enabled:

-

-  

-  
Toggle Just-In-Time compilation of new filter programs.
-      Changing a value of this sysctl doesn't affect existing filter
-    programs.

-

-

-

-

-
bpf(4), modload(8)

-
sljit
-    library

-

-

-

-
The bpfjit interface first appeared in
-    NetBSD 7.0.

-

-

-

-
The bpfjit code was written by
-    Alexander Nasonov
-    <alnsn@NetBSD.org>.

-
The sljit library was written by
-  

-  Zoltan Herczeg
-    <hzmester@freemail.hu>.

-

-

-
-  
-    
-    
-  
-
July 24, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/brgphy.4 4.html b/static/netbsd/man4/brgphy.4 4.html
deleted file mode 100644
index 32882fbd..00000000
--- a/static/netbsd/man4/brgphy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
BRGPHY(4)Device Drivers ManualBRGPHY(4)

-

-

-

-
brgphy — Driver
-    for Broadcom BCM5400 and BCM5700 series Gigabit Ethernet PHYs

-

-

-

-
brgphy* at mii? phy ?

-

-

-

-
The brgphy driver supports the Broadcom
-    BCM5400-family and BCM5700-family Gigabit Ethernet PHYs. These PHYs are
-    found on a variety of Gigabit Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
December 10, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/bridge.4 3.html b/static/netbsd/man4/bridge.4 3.html
deleted file mode 100644
index f102e54d..00000000
--- a/static/netbsd/man4/bridge.4 3.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
BRIDGE(4)Device Drivers ManualBRIDGE(4)

-

-

-

-
bridge — network
-    bridge device

-

-

-

-
pseudo-device bridge

-

-

-

-
The bridge driver creates a logical link
-    between two or more IEEE 802 networks that use the same (or “similar
-    enough”) framing format. For example, it is possible to bridge
-    Ethernet and 802.11 networks together, but it is not possible to bridge
-    Ethernet and Token Ring together.

-
To use bridge, the administrator must
-    first create the interface and configure the bridge parameters. The bridge
-    is created using the ifconfig(8)
-    create subcommand. The learning and forwarding
-    behavior and other parameters of a bridge are configured by the
-    brconfig(8) utility.

-
A bridge can be used to provide several services, such as a simple
-    802.11-to-Ethernet bridge for wireless hosts, and traffic isolation.

-
A bridge works like a switch, forwarding traffic from one
-    interface to another. Multicast and broadcast packets are always forwarded
-    to all interfaces that are part of the bridge. For unicast traffic, the
-    bridge learns which MAC addresses are associated with which interfaces and
-    will forward the traffic selectively.

-
The bridge driver implements the IEEE
-    802.1D Spanning Tree protocol (STP). Spanning Tree is used to detect and
-    remove loops in a network topology.

-
When filtering is enabled, bridged packets will pass through the
-    filter inbound on the originating interface and outbound on the appropriate
-    interfaces. ARP and REVARP packets are forwarded without being filtered and
-    others that are not IP nor IPv6 packets are not forwarded when filtering is
-    enabled.

-
Note that packets to and from the bridging host will be seen by
-    the filter on the interface with the appropriate address configured as well
-    as on the interface on which the packet arrives or departs.

-
The bridge driver will enable passing of
-    VLAN tagged packets automatically if the underlying interfaces support it.
-    This is to facilitate XEN network configurations with
-    xennet(4).

-
It is not possible to assign an IP address directly to the
-    bridge interface. Instead, assign an IP address to a
-    vether(4) interface which can be added to the bridge.

-

-

-

-
l2tp(4), options(4),
-    xennet(4), vether(4),
-    brconfig(8), ipf(8)

-

-

-

-
The bridge driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The bridge driver was originally written
-    by Jason L. Wright ⟨jason@thought.net⟩
-    as part of an undergraduate independent study at the University of North
-    Carolina at Greensboro.

-
This version of the bridge driver has been
-    heavily modified from the original version by Jason R.
-    Thorpe ⟨thorpej@wasabisystems.com⟩.

-

-

-

-
The bridge driver currently supports only
-    Ethernet and Ethernet-like (e.g. 802.11) network devices, with exactly the
-    same interface MTU size as the bridge device.

-
The bridge driver currently does not
-    support snooping via bpf(4).

-

-

-
-  
-    
-    
-  
-
September 27, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/bt3c.4 4.html b/static/netbsd/man4/bt3c.4 4.html
deleted file mode 100644
index 0947344e..00000000
--- a/static/netbsd/man4/bt3c.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
BT3C(4)Device Drivers ManualBT3C(4)

-

-

-

-
bt3c — 3Com
-    Bluetooth PC Card driver

-

-

-

-
bt3c* at pcmcia? function ?

-

-

-

-
The bt3c driver provides support for the
-    3Com Bluetooth PC Card, model 3CRWB6096, to the Bluetooth protocol
-  stack.

-

-

-

-
This card needs firmware loaded before it will work. Due to
-    copyright restrictions we cannot distribute the firmware with NetBSD, but if
-    you have the card then you should have received a CD with the drivers on, or
-    you may download the latest version from the 3Com website. Create a
-    directory named bt3c in the search path of the
-    firmload(9) kernel subsystem. Now, extract the driver
-    archive and find the firmware file called
-    BT3CPCC.bin, and place this file in the newly
-    created directory. The firmware will be loaded automatically as needed.

-

-

-

-

-  
bt3c%d: Cannot open firmware

-  
This will be printed to the console if the device cannot open the firmware
-      file as described above.
-    

-  

-  
bt3c%d: Antenna In

-  
 

-  
bt3c%d: Antenna Out

-  
If the kernel is compiled with the DIAGNOSTIC
-      option, these messages will be produced on the console when the card
-      antenna position is changed.
-    

-  

-  
bt3c%d: sleeping

-  
 

-  
bt3c%d: waking up

-  
These messages will be produced when the card is enabled or disabled due
-      to power change events.

-

-

-

-

-
bluetooth(4), pcmcia(4),
-    firmload(9)

-

-

-

-
This bt3c device driver was written by
-    Iain Hibbert using FreeBSD
-    and BlueZ drivers as a reference. It first appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
January 14, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/btbc.4 4.html b/static/netbsd/man4/btbc.4 4.html
deleted file mode 100644
index d2580b7b..00000000
--- a/static/netbsd/man4/btbc.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTBC(4)Device Drivers ManualBTBC(4)

-

-

-

-
btbc — AnyCom
-    BlueCard driver

-

-

-

-
btbc* at pcmcia? function ?

-

-

-

-
The btbc driver provides support for the
-    AnyCom BlueCard (LSE041, LSE039, LSE139) to the Bluetooth protocol
-  stack.

-

-

-

-
bluetooth(4), pcmcia(4)

-

-

-

-
This btbc device driver was written by
-    KIYOHARA Takashi using Linux bluecard_cs driver as a
-    reference. It first appeared in NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
August 19, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/bthidev.4 4.html b/static/netbsd/man4/bthidev.4 4.html
deleted file mode 100644
index 8d2379e4..00000000
--- a/static/netbsd/man4/bthidev.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTHIDEV(4)Device Drivers ManualBTHIDEV(4)

-

-

-

-
bthidev —
-    Bluetooth Human Interface Device support

-

-

-

-
bthidev* at bthub?

-

-  

-  btkbd* at bthidev? reportid ?
-  

-  btms* at bthidev? reportid ?

-

-

-

-
The bthidev driver handles all Bluetooth
-    Human Interface Devices. Each HID device can have several components, e.g.,
-    a keyboard and a mouse. These components use different report identifiers to
-    distinguish which component data is coming from. The
-    bthidev driver may have several children attached
-    that handle particular components and dispatches data to them based on the
-    report id.

-
Normally, Bluetooth HIDs will be attached using the
-    btdevctl(8) program. The following properties are used by
-    the bthidev driver during autoconfiguration:

-

-  
local-bdaddr

-  
Local device address.

-  
remote-bdaddr

-  
Remote device address.

-  
service-name

-  
The bthidev driver matches the ‘HID’
-      service.

-  
control-psm

-  
This, if set, will indicate the PSM to use for the Control channel. If not
-      set, L2CAP_PSM_HID_CNTL will be used.

-  
interrupt-psm

-  
This, if set, will indicate the PSM to use for the Interrupt channel. If
-      not set, L2CAP_PSM_HID_INTR will be used.

-  
descriptor

-  
This required binary blob is the HID descriptor containing information
-      about reports the device will produce, and obtained via SDP.

-  
reconnect

-  
If this boolean value is set, and is true, then the
-      bthidev driver will initiate reconnections to the
-      remote device when no connection is present.

-  
link-mode

-  
This optional string represents the link mode of the baseband link, and
-      may be one of ‘auth’, ‘encrypt’, or
-      ‘secure’.

-

-
When the bthidev driver has configured its
-    children, it will initiate a connection to the remote device. If this fails
-    and the reconnect flag is not set, it will then wait for the device to
-    initiate the connection.

-

-

-

-
bluetooth(4), bthub(4),
-    btkbd(4), btms(4),
-    btdevctl(8)

-

-

-

-
The bthidev driver was written by
-    Iain Hibbert under the sponsorship of Itronix, Inc.
-    and first appeared in NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
April 10, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/bthub.4 4.html b/static/netbsd/man4/bthub.4 4.html
deleted file mode 100644
index 2fa9eca9..00000000
--- a/static/netbsd/man4/bthub.4 4.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTHUB(4)Device Drivers ManualBTHUB(4)

-

-

-

-
bthub — Bluetooth
-    Remote Device Hub

-

-

-

-
bthub* at bcsp?
-  

-  bthub* at bt3c?
-  

-  bthub* at btbc?
-  

-  bthub* at btuart?
-  

-  bthub* at sbt?
-  

-  bthub* at ubt?

-

-  

-  bthidev* at bthub?
-  

-  btmagic* at bthub?
-  

-  btsco* at bthub?

-

-

-

-
The bthub device is used to attach remote
-    Bluetooth devices to the system, and will attach to Bluetooth controllers as
-    they are enabled.

-

-

-

-
Normally, Bluetooth Remote Devices will be configured on the
-    bthub using the btdevctl(8)
-    program, which passes a proplib(3) dictionary to the
-    control file /dev/bthub with the
-    BTDEV_ATTACH and
-    BTDEV_DETACH ioctl(2)
-  commands.

-
The following properties are used by
-    bthub:

-

-  
local-bdaddr

-  
Local BD_ADDR. This required property should be a
-      six byte data blob.

-  
remote-bdaddr

-  
Remote BD_ADDR. This required property should be a
-      six byte data blob.

-  
service-name

-  
Service name. This required property should be a string indicating the
-      service to configure, and may be one of the following:
-    

-    

-      
HF

-      
Handsfree, see btsco(4).

-      
HID

-      
Human Interface Device, see bthidev(4).

-      
HSET

-      
Headset, see btsco(4).

-    

-  

-

-
Properties used by the configured device are listed in the
-    appropriate device manual page.

-

-

-

-

-  
/dev/bthub

-  
 

-

-

-

-

-
bluetooth(4), bthidev(4),
-    btmagic(4), btsco(4),
-    btdevctl(8)

-

-

-

-
The bthub driver was written by
-    Iain Hibbert under the sponsorship of Itronix, Inc.
-    and first appeared in NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
October 17, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/btkbd.4 4.html b/static/netbsd/man4/btkbd.4 4.html
deleted file mode 100644
index 345cf1d5..00000000
--- a/static/netbsd/man4/btkbd.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTKBD(4)Device Drivers ManualBTKBD(4)

-

-

-

-
btkbd — Bluetooth
-    keyboard support

-

-

-

-
btkbd* at bthidev? reportid ?
-  

-  wskbd* at btkbd? console ?

-

-  

-  options BTKBD_REPEAT
-  

-  options BTKBD_LAYOUT=XXX

-

-

-

-
The btkbd driver provides support for
-    Bluetooth wireless keyboards.

-
Bluetooth keyboards are configured using the
-    btdevctl(8) program, and provide system access through the
-    wscons(4) driver.

-

-

-

-
bluetooth(4), bthidev(4),
-    wskbd(4), btdevctl(8)

-

-

-

-
The btkbd driver appeared in
-    NetBSD 4.0 and was written by Iain
-    Hibbert under the sponsorship of Itronix, Inc.

-

-

-

-
Due to the configuration and connection requirements, Bluetooth
-    keyboards cannot be used until NetBSD is fully
-    booted.

-
Bluetooth keyboards cannot be the NetBSD
-    system console.

-

-

-
-  
-    
-    
-  
-
May 16, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/btmagic.4 3.html b/static/netbsd/man4/btmagic.4 3.html
deleted file mode 100644
index 89f0e7dc..00000000
--- a/static/netbsd/man4/btmagic.4 3.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTMAGIC(4)Device Drivers ManualBTMAGIC(4)

-

-

-

-
btmagic — Apple
-    Magic Mouse and Apple Magic Trackpad

-

-

-

-
btmagic*	at bthub?
-  

-  wsmouse*	at btmagic?

-

-

-

-
The btmagic driver provides support for
-    the Bluetooth “Magic Mouse” and “Magic Trackpad”
-    from Apple, Inc. As remote devices cannot be discovered by autoconfig,
-    configuring a mouse is normally carried out with the
-    btdevctl(8) program.

-
The Magic Mouse and Magic Trackpad use the standard USB Human
-    Interface Device protocol to communicate, but do not provide a proper HID
-    Descriptor, and require specific initializations to enable the proprietary
-    touch reports.

-
The Magic Mouse provides basic mouse functionality with two
-    buttons, and the btmagic driver additionally
-    interprets the touch reports to emulate a middle mouse button when more than
-    one firm touch is detected during a click event, plus horizontal and
-    vertical scrolling for touch movements greater than a certain distance. The
-    mouse has a base resolution of 1300dpi, which the driver scales by default
-    to a less sensitive 650dpi, but this is adjustable with
-    sysctl(8) along with the pressure needed to discern a firm
-    touch, the minimum distance necessary to trigger scrolling and the
-    additional downscale factor applied to scroll movements.

-
The Magic Trackpad provides multi touch functionality and one
-    button. The btmagic driver emulates 3 buttons by
-    splitting the area at the bottom of the device in 3 equal zones and detects
-    finger presence in one of these zones when the button is pressed. In
-    addition, a tap in any area of the trackpad is interpreted as a left click.
-    The timeout for tap detection defaults to 100ms and is adjustable with
-    sysctl(8).

-
Pointer movement is reported for single-touch movements over the
-    device, and scroll is reported for multi-touch movements.

-
The trackpad has a base resolution of 1300dpi, which the driver
-    scales by default to a less sensitive 650dpi, but this is adjustable with
-    sysctl(8) along with the additional downscale factor
-    applied to scroll movements.

-
btmagic interfaces to the system as usual
-    through the wsmouse(4) driver, and the following
-    properties are used during autoconfiguration:

-

-  
vendor-id

-  
Must be 0x05ac.

-  
product-id

-  
Must be 0x030d or 0x030e.

-  
local-bdaddr

-  
Local device address.

-  
remote-bdaddr

-  
Remote device address.

-  
link-mode

-  
This optional string represents the link mode of the baseband link, and
-      may be one of ‘auth’, ‘encrypt’, or
-      ‘secure’.

-

-
When the btmagic driver has configured, it
-    will attempt to open a connection to the mouse and, if this fails or the
-    connection is lost, will wait for the mouse to initiate connections. The
-    Magic Mouse requires connections to be authenticated, and should accept a
-    PIN of ‘0000’ during the pairing process.

-

-

-

-
bluetooth(4), bthub(4),
-    wsmouse(4), btdevctl(8),
-    sysctl(8)

-

-

-

-
The btmagic driver was written by
-    Iain Hibbert with reference to the Linux driver
-    written by Michael Poole. Manuel
-    Bouyer added Magic Trackpad support, with reference to the Linux
-    driver written by Michael Poole and
-    Chase Douglas.

-

-

-
-  
-    
-    
-  
-
July 4, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/btms.4 4.html b/static/netbsd/man4/btms.4 4.html
deleted file mode 100644
index e9e69de5..00000000
--- a/static/netbsd/man4/btms.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTMS(4)Device Drivers ManualBTMS(4)

-

-

-

-
btms — Bluetooth
-    mouse support

-

-

-

-
btms*	at bthidev? reportid ?
-  

-  wsmouse*	at btms?

-

-

-

-
The btms driver provides support for
-    Bluetooth wireless mice.

-
Bluetooth mice must be configured with the
-    btdevctl(8) program and provide system access through the
-    wscons(4) driver.

-

-

-

-
bluetooth(4), bthidev(4),
-    wsmouse(4), btdevctl(8)

-

-

-

-
The btms driver appeared in
-    NetBSD 4.0 and was written by Iain
-    Hibbert under the sponsorship of Itronix, Inc.

-

-

-
-  
-    
-    
-  
-
August 12, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/btsco.4 4.html b/static/netbsd/man4/btsco.4 4.html
deleted file mode 100644
index 9a3070bf..00000000
--- a/static/netbsd/man4/btsco.4 4.html	
+++ /dev/null
@@ -1,97 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTSCO(4)Device Drivers ManualBTSCO(4)

-

-

-

-
btsco — Bluetooth
-    SCO Audio

-

-

-

-
btsco*	at bthub?
-  

-  audio*	at audiobus?

-

-

-

-
The btsco driver provides support for
-    Bluetooth SCO (Synchronous connection-oriented) Audio devices through the
-    audio(4) driver.

-
The btsco driver must be configured at run
-    time with the btdevctl(8) program. The following
-    properties are used by the btsco driver during
-    autoconfiguration:

-

-  
local-bdaddr

-  
Local device address.

-  
remote-bdaddr

-  
Remote device address.

-  
service-name

-  
The btsco driver matches the ‘HF’
-      and ‘HSET’ services. For the ‘HF’ service, the
-      btsco device will, on open(2),
-      listen for incoming connections from the remote device. Otherwise,
-      btsco will attempt to initiate a connection to the
-      remote device.

-  
rfcomm-channel

-  
This integer value is not used directly, but will be stored and passed via
-      the BTSCO_INFO ioctl as below:

-

-
SCO connections require a baseband connection between the two
-    devices before they can be created. The btsco driver
-    does not create this, but can provide information to facilitate an
-    application setting up a control channel prior to use, via the
-    BTSCO_INFO ioctl(2) call on the
-    mixer device, which returns a btsco_info structure as
-    follows:

-

-
#include <dev/bluetooth/btsco.h>
-
-struct btsco_info {
-	bdaddr_t	laddr;		/* controller bdaddr */
-	bdaddr_t	raddr;		/* headset bdaddr */
-	uint8_t		channel;	/* RFCOMM channel */
-	int		vgs;		/* mixer index speaker */
-	int		vgm;		/* mixer index mic */
-};
-
-#define BTSCO_INFO	_IOR('b', 16, struct btsco_info)

-

-
The btsco driver can be configured to act
-    in Connect or Listen mode. In Connect mode, the
-    btsco driver will initiate a connection to the
-    remote device on an open(2) call, whereas in Listen mode,
-    open(2) will block until the remote device initiates the
-    connection.

-

-

-

-
bthset(1), ioctl(2),
-    audio(4), bluetooth(4),
-    bthub(4), btdevctl(8)

-

-

-

-
The btsco driver was written for
-    NetBSD 4.0 by Iain Hibbert
-    under the sponsorship of Itronix, Inc.

-

-

-

-
btsco takes no notice of the HCI Voice
-    Setting in the Bluetooth controller, and this must be 0x0060 (the default)
-    as alternate values are currently unsupported.

-

-

-
-  
-    
-    
-  
-
November 29, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/btuart.4 4.html b/static/netbsd/man4/btuart.4 4.html
deleted file mode 100644
index cae48058..00000000
--- a/static/netbsd/man4/btuart.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
BTUART(4)Device Drivers ManualBTUART(4)

-

-

-

-
btuart — Bluetooth
-    HCI UART driver

-

-

-

-
pseudo-device btuart

-

-

-

-
The btuart driver provides a
-    tty(4) line discipline to send and receive Bluetooth
-    packets over a serial line, as described in the "Bluetooth Host
-    Controller Interface [Transport Layer] specification, Vol 4 part
-  A."

-
The btattach(8) program is used to configure the
-    tty line and create the btuart driver instance.

-

-

-

-
bcsp(4), bluetooth(4),
-    btattach(8)

-

-

-

-
The btuart driver was written with
-    reference to the BlueZ drivers for Linux, and first appeared in
-    NetBSD 5.0.

-

-

-

-
KIYOHARA Takashi
-    <kiyohara@kk.iij4u.or.jp>

-

-

-
-  
-    
-    
-  
-
August 23, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/bwfm.4 4.html b/static/netbsd/man4/bwfm.4 4.html
deleted file mode 100644
index ef219b04..00000000
--- a/static/netbsd/man4/bwfm.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
BWFM(4)Device Drivers ManualBWFM(4)

-

-

-

-
bwfm — Broadcom
-    and Cypress wireless network driver

-

-

-

-
bwfm* at uhub? port ?
-  

-  bwfm* at pci? dev ? function ?
-  

-  bwfm* at sdmmc?

-

-

-

-
The bwfm driver provides support for
-    Broadcom and Cypress FullMAC network adapters.

-

-

-

-
bwi(4), ifmedia(4),
-    usb(4), ifconfig.if(5),
-    wpa_supplicant(8)

-

-

-

-
The bwfm driver was written by
-    Patrick Wildt
-    <patrick@blueri.se>
-    and ported to NetBSD by Jared D.
-    McNeill
-    <jmcneill@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
September 1, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/bwi.4 4.html b/static/netbsd/man4/bwi.4 4.html
deleted file mode 100644
index c473b6ec..00000000
--- a/static/netbsd/man4/bwi.4 4.html	
+++ /dev/null
@@ -1,167 +0,0 @@
-
-  
-    
-    
-    
-  
-
BWI(4)Device Drivers ManualBWI(4)

-

-

-

-
bwi — Broadcom
-    BCM430x/4318 IEEE 802.11b/g wireless network driver

-

-

-

-
bwi* at pci? dev ? function ?
-  

-  bwi* at cardbus? function ?
-  

-  bwi* at sdmmc?

-

-

-

-
The bwi driver provides support for
-    Broadcom BCM430x/4318 wireless network adapters. For more information on
-    configuring this device, see ifconfig(8).

-

-

-
The following per-interface variables are implemented in the
-    hw.bwi
-    branch of the sysctl(3) MIB.

-

-  
debug

-  
Debug flags.

-  
dwell_time

-  
Channel dwell time during scan (msec).

-  
fw_version

-  
Firmware version.

-  
led_idle

-  
Number of ticks before LED enters idle state.

-  
-  
Allow LED to blink.

-  
txpwr_calib

-  
Enable software TX power calibration.

-

-

-

-

-

-
The following cards are among those supported by the
-    bwi driver:

-

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
ChipBusStandard
Apple AirPort Extremeb/g
Buffalo WLI-CB-G54BCM4306CardBusb/g
Buffalo WLI3-CB-G54LBCM4318CardBusb/g
Buffalo WLI-PCI-G54SBCM4306PCIb/g
Dell Wireless 1370BCM4318Mini PCIb/g
Dell Wireless 1470BCM4318Mini PCIb/g
Dell Truemobile 1400BCM4309Mini PCIb/g
Dell Latitude D505BCM4306PCIb/g
Nintendo Wii WLANBCM4318SDIOb/g

-

-

-

-
The firmware for the adapter is not shipped with
-    NetBSD and must be obtained separately. An archive
-    with firmware files that are known to work can be found at:

-

-
https://leaf.dragonflybsd.org/~sephe/bwi/v3.tbz

-

-
The firmware files conventionally reside in
-    /libdata/firmware/bwi and will be loaded when the
-    interface is brought up.
-    : the v3
-    subdirectory in the above firmware archive should exist in the firmware
-    folder. The full list of paths checked for firmware can be found in the
-    hw.firmware.path sysctl(3) node.

-

-

-

-
arp(4), cardbus(4),
-    ifmedia(4), pci(4),
-    ifconfig(8), sysctl(8),
-    wiconfig(8), wpa_supplicant(8)

-

-

-

-
The bwi driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The bwi driver was written by
-    Sepherosa Ziehau for Dragonfly BSD. It was ported to
-    NetBSD by Taylor R. Campbell
-    <riastradh@NetBSD.org>.

-
The hardware specification was reverse engineered by the people at
-    https://bcm-specs.sipsolutions.net/.
-    Thanks go also to johill and mb on the #bcm-specs channel.

-

-

-

-
BCM4306 and BCM4309 chips do not work properly on channel 1, 2,
-    and 3.

-

-

-
-  
-    
-    
-  
-
January 18, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/cac.4 4.html b/static/netbsd/man4/cac.4 4.html
deleted file mode 100644
index ad9a143a..00000000
--- a/static/netbsd/man4/cac.4 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
CAC(4)Device Drivers ManualCAC(4)

-

-

-

-
cac — Compaq array
-    controller driver

-

-

-

-
cac* at eisa? slot ?
-  

-  cac* at pci? dev ? function ?

-

-

-

-
The cac driver provides basic message
-    passing and DMA support for Compaq array controllers. Disk arrays are
-    supported by the ld driver. Monitoring of volume
-    status is supported through the bioctl(8) and
-    envstat(8) utilities, as well as the
-    powerd(8) monitoring daemon.

-

-

-

-
The cac driver provides support for the
-    following controllers:

-

-

-

-  
Compaq Integrated Array

-  
 

-  
Compaq IAES

-  
 

-  
Compaq IDA

-  
 

-  
Compaq IDA-2

-  
 

-  
Compaq RAID LC2

-  
 

-  
Compaq Smart Array 221

-  
 

-  
Compaq Smart Array 3100ES

-  
 

-  
Compaq Smart Array 3200

-  
 

-  
Compaq Smart Array 4200

-  
 

-  
Compaq Smart Array 4250ES

-  
 

-  
Compaq Smart Array 431

-  
 

-  
Compaq SMART

-  
 

-  
Compaq SMART-2/E

-  
 

-  
Compaq SMART-2/P

-  
 

-  
Compaq SMART-2DH

-  
 

-  
Compaq SMART-2SL

-  
 

-

-

-

-

-

-
bio(4), envsys(4),
-    intro(4), ld(4),
-    bioctl(8), envstat(8),
-    powerd(8)

-

-

-

-
The cac driver first appeared in
-    NetBSD 1.5. Support for volume monitoring through
-    bio(4) and envsys(4) was added in
-    NetBSD 5.0.

-

-

-
-  
-    
-    
-  
-
May 8, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/can.4 4.html b/static/netbsd/man4/can.4 4.html
deleted file mode 100644
index 29b0047b..00000000
--- a/static/netbsd/man4/can.4 4.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
CAN(4)Device Drivers ManualCAN(4)

-

-

-

-
CAN — CAN
-    Protocol

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netcan/can.h>

-
int
-  

-  socket(AF_CAN,
-    SOCK_RAW,
-    CAN_RAW);

-

-

-

-
CAN is the network layer protocol used on
-    top of CAN bus networks. At this time only the
-    SOCK_RAW socket type is supported. This protocol
-    layer is intended to be compatible with the Linux SocketCAN
-  implementation.

-

-

-
A CAN frame consists of a 11 bits (standard frame format) or 29
-    bits (extended frame format) identifier, followed by up to 8 data bytes. The
-    interpretation of the identifier is application-dependent, the CAN standard
-    itself doesn't define an addressing.

-
The CAN layer uses a 32bits identifier.
-    The 3 upper bits are used as control flags. The extended frame format is
-    selected by setting the CAN_EFF_FLAG control
-  bit.

-
The socket address is defined as

-

-
struct sockaddr_can {
-        u_int8_t        can_len;
-        sa_family_t     can_family;
-        int             can_ifindex;
-        union {
-                /* transport protocol class address information */
-                struct { canid_t rx_id, tx_id; } tp;
-                /* reserved for future CAN protocols address information */
-        } can_addr;
-};

-

-For CAN raw sockets, the 32bits identifier is part of the message data. The
-  can_addr field of the sockaddr structure is not used.
-

-

-

-
Raw CAN sockets use fixed-length messages defined as follow:

-

-
struct can_frame {
-        canid_t can_id; /* ID + EFF/RTR/ERR flags */
-        uint8_t can_dlc; /* frame payload length in byte (0 .. CAN_MAX_DLEN) */
-        uint8_t __pad;
-        uint8_t __res0;
-        uint8_t __res1;
-        uint8_t data[CAN_MAX_DLEN] __aligned(8);
-};

-

-The lower 11 bits (for standard frames) or 29 bits (for extended frames) are
-  used as the on-wire identifier. The CAN_EFF_FLAG bit
-  is set in can_id for extended frames. The CAN_RTR_FLAG
-  bit is set in can_id for remote transmission request frames.
-

-

-

-

-
socket(2), canloop(4),
-    netintro(4), canconfig(8),
-    /usr/include/netcan/can.h

-
SocketCAN
-    - Wikipedia
-    Readme
-    file for the Controller Area Network Protocol Family

-

-

-

-
The CAN protocol appeared in
-    NetBSD 8.0.

-

-

-

-
CANFD and error frames are not
-    implemented.

-

-

-
-  
-    
-    
-  
-
May 18, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/canloop.4 4.html b/static/netbsd/man4/canloop.4 4.html
deleted file mode 100644
index c804c877..00000000
--- a/static/netbsd/man4/canloop.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
CANLOOP(4)Device Drivers ManualCANLOOP(4)

-

-

-

-
canloop — software
-    loopback CAN network interface

-

-

-

-
pseudo-device canloop

-

-

-

-
The canloop pseudo interface is a loopback
-    interface for the CAN layer. It can be used as destination by a CAN
-    application, when no CAN hardware is available. Other sockets bound to the
-    same canloop interface (or not bound to any
-    interface) will receive the frames.

-
canloop interfaces can be created by using
-    the ifconfig(8) create
-  command.

-

-

-

-
can(4), intro(4),
-    ifconfig(8)

-

-

-

-
The canloop device appeared in
-    NetBSD 8.0.

-

-

-
-  
-    
-    
-  
-
May 18, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/cardbus.4 4.html b/static/netbsd/man4/cardbus.4 4.html
deleted file mode 100644
index a54e29d7..00000000
--- a/static/netbsd/man4/cardbus.4 4.html	
+++ /dev/null
@@ -1,214 +0,0 @@
-
-  
-    
-    
-    
-  
-
CARDBUS(4)Device Drivers ManualCARDBUS(4)

-

-

-

-
cardbus, cardslot,
-    cbb — CardBus
-  driver

-

-

-

-
cbb* at pci? dev? function ?
-  

-  cardslot* at cbb?
-  

-  cardbus* at cardslot?
-  

-  pcmcia* at cardslot?
-  

-  XX* at cardbus? function ?

-

-

-

-
NetBSD provides machine-independent bus
-    support and drivers for CardBus devices.

-
The cbb device represents the CardBus
-    controller. Each controller has a number of slots, represented by the
-    cardslot devices. A slot can have either a CardBus
-    card or a PCMCIA card, which are attached with the
-    cardbus or pcmcia devices,
-    respectively.

-

-

-

-
NetBSD includes the following
-    machine-independent CardBus drivers, sorted by function and driver name:

-

-

-

-

-  
ath(4)

-  
Atheros 5210/5211/5212 802.11

-  
atw(4)

-  
ADMtek ADM8211 (802.11)

-  
bwi(4)

-  
Broadcom BCM430x/4318 (802.11)

-  
ex(4)

-  
3Com 3c575TX and 3c575BTX

-  
fxp(4)

-  
Intel i8255x

-  
ral(4)

-  
Ralink Technology RT25x0 (802.11)

-  
re(4)

-  
RealTek 8139C+/8169/8169S/8110S

-  
rtk(4)

-  
Realtek 8129/8139

-  
rtw(4)

-  
Realtek 8180L (802.11)

-  
tlp(4)

-  
DECchip 21143

-

-

-

-

-

-

-

-  
com(4)

-  
Modems and serial cards

-

-

-

-

-

-

-

-  
adv(4)

-  
AdvanSys 1200[A,B], 9xx[U,UA]

-  
ahc(4)

-  
Adaptec ADP-1480

-  
njs(4)

-  
Workbit NinjaSCSI-32

-

-

-

-

-

-

-

-  
ehci(4)

-  
Enhanced Host Controller (2.0)

-  
ohci(4)

-  
Open Host Controller

-  
uhci(4)

-  
Universal Host Controller

-

-

-

-

-

-

-

-  
fwohci(4)

-  
OHCI controller

-

-

-

-

-

-

-

-  
sdhc(4)

-  
SD Host Controller

-

-

-

-

-

-

-

-  
njata(4)

-  
Workbit NinjaATA-32

-  
siisata(4)

-  
Silicon Image SATA-II controllers

-

-

-

-

-

-

-
cbb devices may not be properly handled by
-    the system BIOS on i386-family systems. If, on an i386-family system, the
-    cbb driver reports

-
cbb0: NOT USED because of
-  unconfigured interrupt

-then enabling
-
    
-  
  • options PCI_ADDR_FIXUP
    • 
-  
  • options PCI_BUS_FIXUP
    • 
-  
  • options PCI_INTR_FIXUP
    • 
-

-or (if ACPI is in use)
-
    
-  
  • options PCI_INTR_FIXUP_DISABLED
    • 
-

-in the kernel configuration might be of use.
-

-

-

-
options(4), pci(4),
-    pcmcia(4), cardbus(9)

-

-

-

-
The cardbus driver appeared in
-    NetBSD 1.5.

-

-

-

-

-

-
NetBSD maps memory on Cardbus (and
-    therefore PCMCIA cards behind Cardbus) in order to access the cards
-    (including reading CIS tuples on PCMCIA cards) and access the devices using
-    the RBUS abstraction. When the mapping does not work, PCMCIA cards are
-    typically ignored on insert, and Cardbus cards are recognized but
-    nonfunctional. On i386, the kernel has a heuristic to choose a memory
-    address for mapping, defaulting to 1 GB, but choosing 0.5 GB on machines
-    with less than 192 MB RAM and 2 GB on machines with more than 1 GB of RAM.
-    The intent is to use an address that is larger than available RAM, but low
-    enough to work; some systems seem to have trouble with addresses requiring
-    more than 20 address lines. On i386, the following kernel configuration line
-    disables the heuristics and forces Cardbus memory space to be mapped at
-    512M; this value makes Cardbus support (including PCMCIA attachment under a
-    cbb) work on some notebook models, including the IBM Thinkpad 600E
-    (2645-4AU) and the Compaq ARMADA M700:

-
options
-    RBUS_MIN_START="0x20000000"

-

-

-

-
By default, on i386 and amd64, the kernel uses
-    RBUS_IO_BASE as 0x4000 and
-    RBUS_IO_SIZE as 0x2000. On some machines, this
-    fails, due to a requirement that these addresses fit within 12 bits. The
-    following kernel options have been reported as helpful:

-
options RBUS_IO_BASE="0xa00"

-
options
-  RBUS_IO_SIZE="0x00ff"

-

-

-

-
-  
-    
-    
-  
-
December 31, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/carp.4 3.html b/static/netbsd/man4/carp.4 3.html
deleted file mode 100644
index 882a7400..00000000
--- a/static/netbsd/man4/carp.4 3.html	
+++ /dev/null
@@ -1,159 +0,0 @@
-
-  
-    
-    
-    
-  
-
CARP(4)Device Drivers ManualCARP(4)

-

-

-

-
carp — Common
-    Address Redundancy Protocol

-

-

-

-
pseudo-device carp

-

-

-

-
The carp interface is a pseudo-device
-    which implements and controls the CARP protocol.
-    carp allows multiple hosts on the same local network
-    to share a set of IP addresses. Its primary purpose is to ensure that these
-    addresses are always available, but in some configurations
-    carp can also provide load balancing
-  functionality.

-
A carp interface can be created at runtime
-    using the ifconfig carpN
-    create command.

-
To use carp, the administrator needs to
-    configure at minimum a common virtual host ID and virtual host IP address on
-    each machine which is to take part in the virtual group. Additional
-    parameters can also be set on a per-interface basis:
-    advbase and advskew, which
-    are used to control how frequently the host sends advertisements when it is
-    the master for a virtual host, and pass which is
-    used to authenticate carp advertisements. Finally
-    carpdev is used to specify which interface the
-    carp device attaches to. If unspecified, the kernel
-    attempts to set carpdev by looking for another interface with the same
-    subnet. These configurations can be done using
-    ifconfig(8), or through the
-    SIOCSVH ioctl.

-
Additionally, there are a number of global parameters which can be
-    set using sysctl(8):

-

-  
net.inet.carp.allow

-  
Accept incoming carp packets. Enabled by
-    default.

-  
net.inet.carp.preempt

-  
Allow virtual hosts to preempt each other. It is also used to failover
-      carp interfaces as a group. When the option is
-      enabled and one of the carp enabled physical
-      interfaces goes down, advskew is changed to 240 on all
-      carp interfaces. See also the first example.
-      Disabled by default.

-  
net.inet.carp.log

-  
Log bad carp packets. Disabled by default.

-  
net.inet.carp.arpbalance

-  
Balance local traffic using ARP. Disabled by default.

-

-

-

-

-
For firewalls and routers with multiple interfaces, it is
-    desirable to failover all of the carp interfaces
-    together, when one of the physical interfaces goes down. This is achieved by
-    the preempt option. Enable it on both host A and B:

-

-
# sysctl -w
-  net.inet.carp.preempt=1

-
Assume that host A is the preferred master and 192.168.1.x/24 is
-    configured on one physical interface and 192.168.2.y/24 on another. This is
-    the setup for host A:

-

-
# ifconfig carp0 create
-# ifconfig carp0 vhid 1 pass mekmitasdigoat 192.168.1.1 \
-	netmask 255.255.255.0
-# ifconfig carp1 create
-# ifconfig carp1 vhid 2 pass mekmitasdigoat 192.168.2.1 \
-	netmask 255.255.255.0

-

-
The setup for host B is identical, but it has a higher
-  advskew:

-

-
# ifconfig carp0 create
-# ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat \
-	192.168.1.1 netmask 255.255.255.0
-# ifconfig carp1 create
-# ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat \
-	192.168.2.1 netmask 255.255.255.0

-

-
Because of the preempt option, when one of the physical interfaces
-    of host A fails, advskew is adjusted to 240 on all its
-    carp interfaces. This will cause host B to preempt
-    on both interfaces instead of just the failed one.

-
In order to set up an ARP balanced virtual host, it is necessary
-    to configure one virtual host for each physical host which would respond to
-    ARP requests and thus handle the traffic. In the following example, two
-    virtual hosts are configured on two hosts to provide balancing and failover
-    for the IP address 192.168.1.10.

-
First the carp interfaces on Host A are
-    configured. The advskew of 100 on the second virtual
-    host means that its advertisements will be sent out slightly less
-    frequently.

-

-
# ifconfig carp0 create
-# ifconfig carp0 vhid 1 pass mekmitasdigoat 192.168.1.10 \
-	netmask 255.255.255.0
-# ifconfig carp1 create
-# ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat \
-	192.168.1.10 netmask 255.255.255.0

-

-
The configuration for host B is identical, except the skew is on
-    virtual host 1 rather than virtual host 2.

-

-
# ifconfig carp0 create
-# ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat \
-	192.168.1.10 netmask 255.255.255.0
-# ifconfig carp1 create
-# ifconfig carp1 vhid 2 pass mekmitasdigoat 192.168.1.10 \
-	netmask 255.255.255.0

-

-
Finally, the ARP balancing feature must be enabled on both
-  hosts:

-

-
# sysctl -w
-  net.inet.carp.arpbalance=1

-
When the hosts receive an ARP request for 192.168.1.10, the source
-    IP address of the request is used to compute which virtual host should
-    answer the request. The host which is master of the selected virtual host
-    will reply to the request, the other(s) will ignore it.

-
This way, locally connected systems will receive different ARP
-    replies and subsequent IP traffic will be balanced among the hosts. If one
-    of the hosts fails, the other will take over the virtual MAC address, and
-    begin answering ARP requests on its behalf.

-
Note: ARP balancing only works on the local network segment. It
-    cannot balance traffic that crosses a router, because the router itself will
-    always be balanced to the same virtual host.

-

-

-

-
netstat(1), sysctl(3),
-    arp(4), arp(8),
-    ifconfig(8), sysctl(8)

-

-

-

-
The carp device first appeared in
-    OpenBSD 3.5.

-

-

-
-  
-    
-    
-  
-
October 12, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/cas.4 4.html b/static/netbsd/man4/cas.4 4.html
deleted file mode 100644
index 1cba1a69..00000000
--- a/static/netbsd/man4/cas.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
CAS(4)Device Drivers ManualCAS(4)

-

-

-

-
cas —
-    Cassini/Cassini+ (GigaSwift) Ethernet device
-  driver

-

-

-

-
cas* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The cas driver provides support for the
-    Sun Cassini and Cassini+ (GigaSwift) and the National Semiconductor Saturn
-    Ethernet hardware found in Sun UltraSPARC machines and Sun GigaSwift PCI
-    cards.

-
Cards supported by this driver include:

-
    
-  
  • Sun GigaSwift Ethernet 1.0 MMF (Cassini Kuheen) (part no. 501-5524)
    • 
-  
  • Sun GigaSwift Ethernet 1.0 UTP (Cassini) (part no. 501-5902)
    • 
-  
  • Sun GigaSwift Ethernet UTP (GCS) (part no. 501-6719)
    • 
-  
  • Sun Quad GigaSwift Ethernet UTP (QGE) (part no. 501-6522)
    • 
-  
  • Sun Quad GigaSwift Ethernet PCI-X (QGE-X) (part no. 501-6738)
    • 
-

-

-

-

-
brgphy(4), gentbi(4),
-    gphyter(4), ifmedia(4),
-    intro(4), mii(4),
-    ifconfig(8)

-
Sun Microsystems,
-    Cassini+ ASIC Specification,
-    https://web.archive.org/web/20090701014334/http://www.sun.com/processors/manuals/cs_plus.pdf.

-

-

-

-
The cas driver first appeared in
-    OpenBSD 4.1. NetBSD support
-    was added in NetBSD 6.0.

-

-

-

-
The cas driver was written for
-    OpenBSD by Mark Kettenis
-    ⟨kettenis@openbsd.org⟩, based on the gem(4)
-    driver, and ported to NetBSD by
-    Julian Coleman ⟨jdc@NetBSD.org⟩.

-

-

-

-
The cas driver does not support any of the
-    advanced features of the Cassini chip.

-
On the SX fibre variants of the hardware, the link may stay down
-    if media options apart from autoselect are
-  chosen.

-

-

-
-  
-    
-    
-  
-
December 25, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/ccd.4 3.html b/static/netbsd/man4/ccd.4 3.html
deleted file mode 100644
index 193f668a..00000000
--- a/static/netbsd/man4/ccd.4 3.html	
+++ /dev/null
@@ -1,96 +0,0 @@
-
-  
-    
-    
-    
-  
-
CCD(4)Device Drivers ManualCCD(4)

-

-

-

-
ccd — Concatenated
-    disk driver

-

-

-

-
pseudo-device ccd

-

-

-

-
The ccd driver provides the capability of
-    combining one or more disks/partitions into one virtual disk.

-
This document assumes that you're familiar with how to generate
-    kernels, how to properly configure disks and pseudo-devices in a kernel
-    configuration file, and how to partition disks.

-
Note that the ‘raw’ partitions of the disks
-    must not be combined. Each component partition
-    should be offset at least one cylinder from the beginning of the component
-    disk. This avoids potential conflicts between the component disk's disklabel
-    and the ccd's disklabel. The kernel will only allow
-    component partitions of type FS_CCD. But for now, it
-    allows partition of all types since some port lacks support of an on-disk
-    BSD disklabel. The partition of FS_UNUSED may be
-    rejected because device driver of component disk will refuse it.

-
In order to compile in support for the
-    ccd, you must add a line similar to the following to
-    your kernel configuration file:

-

-
pseudo-device	ccd	# concatenated disk devices

-

-
The ccds are allocated dynamically as
-    needed.

-
A ccd may be either serially concatenated
-    or interleaved. To serially concatenate the partitions, specify the
-    interleave factor of 0.

-
If a ccd is interleaved correctly, a
-    “striping” effect is achieved, which can increase performance.
-    Since the interleave factor is expressed in units of
-    DEV_BSIZE, one must account for sector sizes other
-    than DEV_BSIZE in order to calculate the correct
-    interleave. The kernel will not allow an interleave factor less than the
-    size of the largest component sector divided by
-    DEV_BSIZE.

-
Note that best performance is achieved if all component disks have
-    the same geometry and size. Optimum striping cannot occur with different
-    disk types.

-
Also note that the total size of concatenated disk may vary
-    depending on the interleave factor even if the exact same components are
-    concatenated. And an old on-disk disklabel may be read after interleave
-    factor change. As a result, the disklabel may contain wrong partition
-    geometry and will cause an error when doing I/O near the end of concatenated
-    disk.

-
There is a run-time utility that is used for configuring
-    ccds. See ccdconfig(8) for more
-    information.

-

-

-

-
If just one (or more) of the disks in a non-mirrored
-    ccd fails, the entire file system will be lost.

-

-

-

-

-  
/dev/{,r}ccd*

-  
ccd device special files.

-

-

-

-

-
config(1), ccdconfig(8),
-    fsck(8), MAKEDEV(8),
-    mount(8), newfs(8)

-

-

-

-
The concatenated disk driver was originally written at the
-    University of Utah.

-

-

-
-  
-    
-    
-  
-
November 30, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/cd.4 4.html b/static/netbsd/man4/cd.4 4.html
deleted file mode 100644
index 3e30bd21..00000000
--- a/static/netbsd/man4/cd.4 4.html	
+++ /dev/null
@@ -1,274 +0,0 @@
-
-  
-    
-    
-    
-  
-
CD(4)Device Drivers ManualCD(4)

-

-

-

-
cd — SCSI and
-    ATAPI CD-ROM driver

-

-

-

-
cd* at scsibus? target ? lun ?
-  

-  cd1 at scsibus0 target 4 lun 0
-  

-  cd* at atapibus? drive ? flags 0x0000

-

-

-

-
The cd driver provides support for a Small
-    Computer Systems Interface (SCSI) bus and Advanced Technology Attachment
-    Packet Interface (ATAPI) Compact Disc-Read Only Memory (CD-ROM) drive. In an
-    attempt to look like a regular disk, the cd driver
-    synthesizes a partition table, with one partition covering the entire
-    CD-ROM. It is possible to modify this partition table using
-    disklabel(8), but it will only last until the CD-ROM is
-    unmounted. In general the interfaces are similar to those described by
-    wd(4) and sd(4).

-
As the SCSI adapter is probed during boot, the SCSI bus is scanned
-    for devices. Any devices found which answer as `Read-only' type devices will
-    be `attached' to the cd driver.

-
For the use of flags with ATAPI devices, see
-    wd(4).

-
The system utility disklabel(8) may be used to
-    read the synthesized disk label structure, which will contain correct
-    figures for the size of the CD-ROM should that information be required.

-

-

-

-
Any number of CD-ROM devices may be attached to the system
-    regardless of system configuration as all resources are dynamically
-    allocated.

-

-

-

-
The following ioctl(2) calls which apply to SCSI
-    CD-ROM drives are defined in the header files
-    <sys/cdio.h> and
-    <sys/disklabel.h>.

-

-  

-  
 

-  

-  
(struct disklabel) Read or write the in-core copy
-      of the disklabel for the drive. The disklabel is initialized with
-      information read from the SCSI inquiry commands, and should be the same as
-      the information printed at boot. This structure is defined in
-      disklabel(5).

-  

-  
(struct ioc_play_track) Start audio playback given
-      a track address and length. The structure is defined as follows:
-    

-    
struct ioc_play_track
-{
-	u_char	start_track;
-	u_char	start_index;
-	u_char	end_track;
-	u_char	end_index;
-};

-    

-  

-  

-  
(struct ioc_play_blocks) Start audio playback
-      given a block address and length. The structure is defined as follows:
-    

-    
struct ioc_play_blocks
-{
-	int	blk;
-	int	len;
-};

-    

-  

-  

-  
(struct ioc_play_msf) Start audio playback given a
-      `minutes-seconds-frames' address and length. The structure is defined as
-      follows:
-    

-    
struct ioc_play_msf
-{
-	u_char	start_m;
-	u_char	start_s;
-	u_char	start_f;
-	u_char	end_m;
-	u_char	end_s;
-	u_char	end_f;
-};

-    

-  

-  

-  
(struct ioc_read_subchannel) Read information from
-      the subchannel at the location specified by this structure:
-    

-    
struct ioc_read_subchannel {
-	u_char address_format;
-#define CD_LBA_FORMAT	1
-#define CD_MSF_FORMAT	2
-	u_char data_format;
-#define CD_SUBQ_DATA		0
-#define CD_CURRENT_POSITION	1
-#define CD_MEDIA_CATALOG	2
-#define CD_TRACK_INFO		3
-	u_char track;
-	int	data_len;
-	struct  cd_sub_channel_info *data;
-};

-    

-  

-  

-  
(struct ioc_toc_header) Return summary information
-      about the table of contents for the mounted CD-ROM. The information is
-      returned into the following structure:
-    

-    
struct ioc_toc_header {
-	u_short len;
-	u_char  starting_track;
-	u_char  ending_track;
-};

-    

-  

-  

-  
(struct ioc_read_toc_entry) Return information
-      from the table of contents entries mentioned. (Yes, this command name is
-      misspelled). The argument structure is defined as follows:
-    

-    
struct ioc_read_toc_entry {
-	u_char	address_format;
-	u_char	starting_track;
-	u_short	data_len;
-	struct  cd_toc_entry *data;
-};

-    

-    The requested data is written into an area of size
-      data_len and pointed to by
-      data.

-  

-  
(struct ioc_patch) Attach various audio channels
-      to various output channels. The argument structure is defined thusly:
-    

-    
struct ioc_patch {
-	u_char	patch[4];
-	/* one for each channel */
-};

-    

-  

-  

-  
 

-  

-  
(struct ioc_vol) Get (set) information about the
-      volume settings of the output channels. The argument structure is as
-      follows:
-    

-    
struct	ioc_vol
-{
-	u_char	vol[4];
-	/* one for each channel */
-};

-    

-  

-  

-  
Patch all output channels to all source channels.

-  

-  
Patch left source channel to the left output channel and the right source
-      channel to the right output channel.

-  

-  
Mute output without changing the volume settings.

-  

-  
 

-  

-  
Attach both output channels to the left (right) source channel.

-  

-  
 

-  

-  
Turn on (off) debugging for the appropriate device.

-  

-  
 

-  

-  
Pause (resume) audio play, without resetting the location of the
-      read-head.

-  

-  
Reset the drive.

-  

-  
 

-  

-  
Tell the drive to spin-up (-down) the CD-ROM.

-  

-  
 

-  

-  
Tell the drive to allow (prevent) manual ejection of the CD-ROM disc. Not
-      all drives support this feature.

-  

-  
Eject the CD-ROM.

-  

-  
Cause the ATAPI changer to load or unload discs.

-  

-  
Tell the drive to close its door and load the media. Not all drives
-      support this feature.

-  

-  
Test unit ready - to allow userland to silently check for presence of
-      media.

-

-
In addition the general scsi(4) ioctls may be
-    used with the cd driver, if used against the `whole
-    disk' partition (i.e. /dev/rcd0d for the bebox and
-    i386 port, /dev/rcd0c for all other ports).

-

-

-

-
When a CD-ROM is changed in a drive controlled by the
-    cd driver, then the act of changing the media will
-    invalidate the disklabel and information held within the kernel. To stop
-    corruption, all accesses to the device will be discarded until there are no
-    more open file descriptors referencing the device. During this period, all
-    new open attempts will be rejected. When no more open file descriptors
-    reference the device, the first next open will load a new set of parameters
-    (including disklabel) for the drive.

-
The audio code in the cd driver only
-    support SCSI-2 standard audio commands. Because many CD-ROM manufacturers
-    have not followed the standard, there are many CD-ROM drives for which audio
-    will not work. Some work is planned to support some of the more common
-    `broken' CD-ROM drives; however, this is not yet under way.

-

-

-

-

-  
/dev/cd[0-9][a-h]

-  
block mode CD-ROM devices

-  
/dev/rcd[0-9][a-h]

-  
raw mode CD-ROM devices

-

-

-

-

-
None.

-

-

-

-
intro(4), scsi(4),
-    sd(4), wd(4),
-    disklabel(5), disklabel(8)

-

-

-

-
The cd driver appeared in 386BSD 0.1.

-

-

-

-
The names of the structures used for the third argument to
-    ioctl() were poorly chosen, and a number of spelling
-    errors have survived in the names of the ioctl()
-    commands.

-

-

-
-  
-    
-    
-  
-
June 23, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/cdce.4 4.html b/static/netbsd/man4/cdce.4 4.html
deleted file mode 100644
index 89748f1a..00000000
--- a/static/netbsd/man4/cdce.4 4.html	
+++ /dev/null
@@ -1,112 +0,0 @@
-
-  
-    
-    
-    
-  
-
CDCE(4)Device Drivers ManualCDCE(4)

-

-

-

-
cdce — USB
-    Communication Device Class Ethernet driver

-

-

-

-
cdce* at uhub? port ?

-

-

-

-
The cdce driver provides support for USB
-    Host-to-Host (aka USB-to-USB) bridges and USB-to-Ethernet adapters based on
-    the USB Communication Device Class (CDC) and Ethernet subclass, including
-    the following:

-

-
    
-  
  • Acer Labs USB 2.0 Data Link
    • 
-  
  • Anker A7611
    • 
-  
  • Club 3D Adapter LAN-Adapter (CAC-1420)
    • 
-  
  • DIEWU USB-DW8152
    • 
-  
  • G.Mate YP3X00
    • 
-  
  • Huawei E5573s-320s
    • 
-  
  • Motorola USBNET
    • 
-  
  • NetChip EthernetGadget
    • 
-  
  • Prolific PL-2501
    • 
-  
  • Realtek RTL8152B, RTL8156, and RTL8156B Ethernet controllers
    • 
-  
  • Sharp Zaurus
    • 
-

-
The USB bridge appears as a regular network interface on both
-    sides, transporting Ethernet frames.

-
For more information on configuring this device, see
-    ifconfig(8).

-
USB 1.x bridges support speeds of up to 12Mbps, USB 2.0 speeds of
-    up to 480Mbps, and USB 3.0 speeds of up to 5Gbps.

-
Packets are received and transmitted over separate USB bulk
-    transfer endpoints.

-
The cdce driver does not support different
-    media types or options.

-

-

-

-

-  
cdce%d: no union descriptor

-  
The driver couldn't fetch an interface descriptor from the USB device. For
-      a manually added USB vendor/product, the CDCE_NO_UNION flag can be tried
-      to work around the missing descriptor.

-  
cdce%d: no data interface

-  

-  
cdce%d: could not read endpoint descriptor

-  

-  
cdce%d: unexpected endpoint

-  

-  
cdce%d: could not find data bulk in/out

-  
For a manually added USB vendor/product, these errors indicate that the
-      bridge is not compatible with the driver.

-

-
Also see usbnet(4) for diagnostics.

-

-

-

-
arp(4), intro(4),
-    netintro(4), usb(4),
-    usbnet(4), ifconfig.if(5),
-    ifconfig(8)

-
Universal Serial Bus Class
-    Definitions for Communication Devices,
-    http://www.usb.org/developers/devclass_docs/usbcdc11.pdf.

-
Data sheet Prolific PL-2501
-    Host-to-Host Bridge/Network Controller,
-    http://tech.prolific.com.tw/visitor/fcabdl.asp?fid=20679530.

-

-

-

-
The cdce device driver first appeared in
-    OpenBSD 3.6 and NetBSD
-  3.0.

-

-

-

-
The cdce driver was written by
-    Craig Boston
-    <craig@tobuj.gank.org>
-    based on the aue(4) driver written by
-    Bill Paul
-    <wpaul@windriver.com>
-    and ported to OpenBSD by Daniel
-    Hartmeier
-    <dhartmei@openbsd.org>.

-

-

-

-
Many USB devices notoriously fail to report their class and
-    interfaces correctly. Undetected products might work flawlessly when their
-    vendor and product IDs are added to the driver manually.

-

-

-
-  
-    
-    
-  
-
November 5, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/cec.4 4.html b/static/netbsd/man4/cec.4 4.html
deleted file mode 100644
index 6c61ced0..00000000
--- a/static/netbsd/man4/cec.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
CEC(4)Device Drivers ManualCEC(4)

-

-

-

-
cec — IEEE488 GPIB
-    controller boards

-

-

-

-
cec* at isa? port 0x2b8 irq 5 drq 1
-  

-  gpib* at cec?

-

-

-

-
The cec driver supports GPIB (IEEE488)
-    controller boards based on the NEC uPD7210 GPIB controller chip. The
-    following boards are supported:

-

-
    
-  
  • Capital Equipment Corp. IEEE488 board
    • 
-  
  • Keithley GPIB boards
    • 
-

-
The following GPIB boards are similar and support should be
-    available reasonably easily:

-

-
    
-  
  • HAMEG HO-80 IEEE488 board
    • 
-  
  • National Instruments PCII board
    • 
-  
  • Measurement Computing (Computer Boards) ISA GPIB boards
    • 
-

-

-

-

-
gpib(4), isa(4)

-

-

-

-
The cec driver appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
May 24, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/cfb.4 4.html b/static/netbsd/man4/cfb.4 4.html
deleted file mode 100644
index 8e23be86..00000000
--- a/static/netbsd/man4/cfb.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
CFB(4)Device Drivers ManualCFB(4)

-

-

-

-
cfb — PMAG-B CX
-    colour unaccelerated 2-D framebuffer

-

-

-

-
cfb* at tc? slot ? offset ?
-  

-  wsdisplay* at cfb?

-

-

-

-
The cfb driver provides support for the
-    PMAG-B CX colour framebuffer for the TURBOchannel bus. The PMAG-B is an 8
-    bpp colour framebuffer capable of running at a resolution of 1024-by-864 at
-    60 Hz.

-

-

-

-
mfb(4), px(4),
-    pxg(4), sfb(4), tc(4),
-    tfb(4), wscons(4)

-

-

-
-  
-    
-    
-  
-
August 22, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/cgd.4 3.html b/static/netbsd/man4/cgd.4 3.html
deleted file mode 100644
index 1b1ed0c0..00000000
--- a/static/netbsd/man4/cgd.4 3.html	
+++ /dev/null
@@ -1,231 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGD(4)Device Drivers ManualCGD(4)

-

-

-

-
cgd —
-    cryptographic disk driver

-

-

-

-
pseudo-device cgd

-

-

-

-
The cgd driver, configured with the
-    cgdconfig(8) tool, implements a logical disk device by
-    encrypting or decrypting disk sectors on their way to and from a physical
-    backing disk or partition.

-

-

-
As long as you keep the key secret, cgd
-    keeps the content of the disk secret from a
-    
-    adversary, such as a thief who steals your disk or a border patrol agent who
-    detains you and takes a snapshot of your laptop's disk while you are
-    crossing a border.

-
cgd
-     detect
-    tampering by an
-    
-    adversary who can modify the content of the backing store, such as a
-    man-in-the-middle between you and an iSCSI target, or after the border
-    patrol returns your laptop to you.

-

-

-

-
The following ciphers are supported:

-

-  

-  
The Adiantum tweakable wide-block cipher. The Adiantum tweak for each disk
-      sector is taken to be the little-endian encoding of the disk sector
-      number.
-    
Adiantum provides the best security by encrypting entire disk
-        sectors at a time (512 bytes), and generally provides the best
-        performance on machines without CPU support for accelerating AES.

-  

-  

-  
AES in CBC mode. The CBC initialization vector for each disk sector is
-      chosen to be the encryption under AES of the little-endian encoding of the
-      disk sector number. The default key length is 128 bits. CBC mode is
-      expected to provide marginally better theoretical security than XTS
-    mode.

-  

-  
AES in XTS mode. The XTS tweak for each disk sector is chosen to be the
-      little-endian encoding of the disk sector number. AES-XTS uses a 256-bit
-      or 512-bit key, composed of a pair of AES-128 or AES-256 keys. The default
-      key length is 256, meaning AES-128. XTS mode is expected to provide
-      marginally better theoretical performance than CBC mode.

-

-

-

-

-
The following obsolete ciphers are supported for compatibility
-    with old disks.

-

-    These obsolete ciphers are implemented without timing side channel
-    protection, so, for example, JavaScript code in a web browser that can
-    measure the timing of disk activity may be able to recover the secret key.
-    These are also based on 64-bit block ciphers and are therefore unsafe for
-    disks much larger than a gigabyte. You should not use these except where
-    compatibility with old disks is necessary.

-

-  

-  
3DES (Triple DES with EDE3) in CBC mode. The CBC initialization vector for
-      each disk sector is chosen to be the encryption under 3DES of the
-      little-endian encoding of the disk sector number.
-    
Note: Internally, the ‘parity bits’ of the
-        192-bit key are ignored, so there are only 168 bits of key material, and
-        owing to generic attacks on 64-bit block ciphers and to
-        meet-in-the-middle attacks on compositions of ciphers as in EDE3 the
-        security is much lower than one might expect even for a 168-bit key.

-  

-  

-  
Blowfish in CBC mode. The CBC initialization vector for each disk sector
-      is chosen to be the encryption under Blowfish of the little-endian
-      encoding of the disk sector number. It is strongly encouraged that keys be
-      at least 128 bits long. There are no performance advantages of using
-      shorter keys. The default key length is 128 bits.

-

-

-

-

-
A very early version of cgd had a bug in
-    the CBC-based ciphers aes-cbc,
-    3des-cbc, and blowfish-cbc:
-    the CBC initialization vector was chosen to be the
-    
-    encryption under the block cipher of the little-endian encoding of the disk
-    sector number, which has no impact on security but reduces performance. For
-    compatibility with such disks, the ‘IV method’ must be set to
-    encblkno8. Otherwise the ‘IV method’
-    should always be encblkno1. The parameter is
-    meaningless for adiantum and
-    aes-xts.

-

-

-

-

-
A cgd responds to all of the standard disk
-    ioctl(2) calls defined in sd(4), and
-    also defines the following:

-

-  

-  
Configure the cgd. This ioctl(2)
-      sets up the encryption parameters and points the
-      cgd at the underlying disk.

-  

-  
Unconfigure the cgd.

-  

-  
Get info about the cgd.

-

-
These ioctl(2)'s and their associated data
-    structures are defined in
-    <dev/cgdvar.h> header.

-

-

-

-
It goes without saying that if you forget the passphrase that you
-    used to configure a cgd, then you have irrevocably
-    lost all of the data on the disk. Please ensure that you are using an
-    appropriate backup strategy.

-

-

-

-

-  
/dev/{,r}cgd*

-  
cgd device special files.

-

-

-

-

-
config(1), ioctl(2),
-    sd(4), cgdconfig(8),
-    MAKEDEV(8)

-
Roland C. Dowdeswell and
-    John Ioannidis, The CryptoGraphic
-    Disk Driver, Proceedings of the FREENIX Track: 2003
-    USENIX Annual Technical Conference, USENIX
-    Association,
-    https://www.usenix.org/event/usenix03/tech/freenix03/full_papers/dowdeswell/dowdeswell.pdf,
-    179-186, June 9-14,
-    2003.

-
Paul Crowley and
-    Eric Biggers, Adiantum:
-    length-preserving encryption for entry-level processors,
-    International Association of Cryptologic Research,
-    Transactions on Symmetric Cryptology,
-    4, 2018,
-    https://doi.org/10.13154/tosc.v2018.i4.39-61,
-    39-61.

-
FIPS PUB 46-3: Data Encryption
-    Standard (DES), National Institute of Standards and
-    Technology,
-    https://csrc.nist.gov/publications/detail/fips/46/3/archive/1999-10-25,
-    United States Department of Commerce,
-    October 25, 1999, withdrawn May
-    19, 2005.

-
FIPS PUB 197: Advanced
-    Encryption Standard (AES), National Institute of
-    Standards and Technology,
-    https://csrc.nist.gov/publications/detail/fips/197/final,
-    United States Department of Commerce,
-    November 2001.

-
Morris Dworkin,
-    Recommendation for Block Cipher Modes of Operation:
-    Methods and Techniques, National Institute of
-    Standards and Technology,
-    https://csrc.nist.gov/publications/detail/sp/800-38a/final,
-    United States Department of Commerce,
-    December 2001, NIST Special
-    Publication 800-38A.

-
Morris Dworkin,
-    Recommendation for Block Cipher Modes of Operation: the
-    XTS-AES Mode for Confidentiality on Storage Devices,
-    National Institute of Standards and Technology,
-    https://csrc.nist.gov/publications/detail/sp/800-38e/final,
-    United States Department of Commerce,
-    January 2010, NIST Special
-    Publication 800-38E.

-
Bruce Schneier,
-    The Blowfish Encryption Algorithm,
-    https://www.schneier.com/academic/blowfish,
-    superseded by Twofish, superseded by
-    Threefish.

-
Karthikeyan Bhargavan
-    and Gaëtan Leurent,
-    Sweet32: Birthday attacks on 64-bit block ciphers in TLS
-    and OpenVPN,
-    https://sweet32.info.

-

-

-

-
The cgd driver was written by Roland C.
-    Dowdeswell for NetBSD. The
-    cgd driver originally appeared in
-    NetBSD 2.0. The aes-xts
-    cipher was added in NetBSD 8.0. The
-    adiantum cipher was added in NetBSD
-    10.0.

-

-

-
-  
-    
-    
-  
-
September 27, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/ch.4 4.html b/static/netbsd/man4/ch.4 4.html
deleted file mode 100644
index a9d313c1..00000000
--- a/static/netbsd/man4/ch.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
CH(4)Device Drivers ManualCH(4)

-

-

-

-
ch — SCSI media
-    changer driver

-

-

-

-
ch* at scsibus? target ? lun ?

-

-

-

-
The ch driver is essentially an
-    ioctl(2) interface to a robot on a SCSI bus - a device
-    that will change media (e.g. tapes, CD-ROMs, etc) in and out of drives for
-    that media. The chio(1) utility program uses this
-    interface to manipulate such robots.

-

-

-

-

-  
/dev/chu

-  
SCSI bus media changer unit u

-

-
/usr/include/sys/chio.h

-

-

-

-

-  
ch%d: waiting %d seconds for changer to settle...

-  
Some changers require a long time to settle out, to do tape inventory, for
-      instance.

-  
ch%d: offline

-  
The changer is not responding.

-  
ch%d: warning, READ ELEMENT STATUS avail != count

-  

-  
ch%d: could not sense element address page

-  

-  
ch%d: could not sense capabilities page

-  

-

-

-

-

-
chio(1), ioctl(2),
-    cd(4), intro(4),
-    scsi(4), st(4)

-

-

-

-
Jason R. Thorpe

-

-

-
-  
-    
-    
-  
-
June 10, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/chipsfb.4 4.html b/static/netbsd/man4/chipsfb.4 4.html
deleted file mode 100644
index c0d5579b..00000000
--- a/static/netbsd/man4/chipsfb.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
CHIPSFB(4)Device Drivers ManualCHIPSFB(4)

-

-

-

-
chipsfb — Chips
-    & Technologies 6555x based graphics chips

-

-

-

-
chipsfb* at pci?
-  

-  chipsfb* at ofbus?
-  

-  wsdisplay* at chipsfb?

-

-

-

-
The chipsfb driver provides support for
-    the C&T 65550 and 65554 graphics controllers. Currently it depends on
-    the firmware (usually Open Firmware) to set up the framebuffer, but all
-    graphics operations used by wsdisplay use the blitter.

-

-

-

-
wscons(4), wsdisplay(4)

-

-

-

-
The driver has been tested on macppc and shark only.

-

-

-
-  
-    
-    
-  
-
January 24, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/ciphy.4 4.html b/static/netbsd/man4/ciphy.4 4.html
deleted file mode 100644
index cec2593c..00000000
--- a/static/netbsd/man4/ciphy.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
CIPHY(4)Device Drivers ManualCIPHY(4)

-

-

-

-
ciphy — Driver for
-    Cicada 10/100/1000 copper Ethernet PHYs

-

-

-

-
ciphy* at mii? phy ?

-

-

-

-
The ciphy driver supports PHYs commonly
-    integrated on VIA Networking Technologies VT6122 Gigabit Ethernet
-  adapters.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-

-
Driver is ported from FreeBSD and first
-    appeared in NetBSD 3.0.

-

-

-

-
The driver was originally written by Bill
-    Paul ⟨wpaul@windriver.com⟩.

-

-

-
-  
-    
-    
-  
-
February 20, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/cir.4 4.html b/static/netbsd/man4/cir.4 4.html
deleted file mode 100644
index 27068c31..00000000
--- a/static/netbsd/man4/cir.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
CIR(4)Device Drivers ManualCIR(4)

-

-

-

-
cir — Consumer IR
-    (remote control) driver

-

-

-

-
cir* at irbus?

-

-

-

-
The cir provides access to consumer
-    infrared devices such as remote control receivers and transmitters.

-

-

-

-
irframe(4)

-

-

-

-
The cir driver appeared in
-    NetBSD 1.6.

-

-

-

-
This device is not yet functional.

-

-

-
-  
-    
-    
-  
-
December 29, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/ciss.4 4.html b/static/netbsd/man4/ciss.4 4.html
deleted file mode 100644
index 4695a19f..00000000
--- a/static/netbsd/man4/ciss.4 4.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
CISS(4)Device Drivers ManualCISS(4)

-

-

-

-
ciss — HP/Compaq
-    Smart ARRAY 5/6 RAID controllers

-

-

-

-
ciss* at pci? function ?

-

-

-

-
The ciss driver provides support for the
-    CISS interface implemented by fifth and later generations of the HP/Compaq
-    Smart ARRAY family of controllers.

-
The CISS interface is defined in the document entitled
-    CISS Command Interface for SCSI-3 Support
-    Open Specification, Version 1.04, Valence Number 1,
-    Compaq Computer Corporation,
-    2000/11/27.

-
This driver supports several Compaq and HP controllers
-    implementing the CISS interface, including:

-

-
    
-  
  • Compaq Smart Array 5300 version 1
    • 
-  
  • Compaq Smart Array 5300 version 2
    • 
-  
  • Compaq Smart Array 5i version 1
    • 
-  
  • Compaq Smart Array 5i version 2
    • 
-  
  • HP Smart Array 5312
    • 
-  
  • HP Smart Array 6i
    • 
-  
  • HP Smart Array 641
    • 
-  
  • HP Smart Array 642
    • 
-  
  • HP Smart Array 6400
    • 
-  
  • HP Smart Array 6400 EM
    • 
-  
  • HP Smart Array E200
    • 
-  
  • HP Smart Array E200i
    • 
-  
  • HP Smart Array P400
    • 
-  
  • HP Smart Array P400i
    • 
-  
  • HP Smart Array P410i
    • 
-  
  • HP Smart Array P600
    • 
-  
  • HP Smart Array P800
    • 
-  
  • HP Smart Array V100
    • 
-  
  • HP Smart Array 1 through 14
    • 
-  
  • HP Smart Array P700m
    • 
-  
  • HP Smart Array P212
    • 
-  
  • HP Smart Array P410
    • 
-  
  • HP Smart Array P410i
    • 
-  
  • HP Smart Array P411
    • 
-  
  • HP Smart Array P822
    • 
-  
  • HP Smart Array P712m
    • 
-  
  • HP Smart Array P222
    • 
-  
  • HP Smart Array P420
    • 
-  
  • HP Smart Array P421
    • 
-  
  • HP Smart Array P822
    • 
-  
  • HP Smart Array P420i
    • 
-  
  • HP Smart Array P220i
    • 
-  
  • HP Smart Array P721i
    • 
-  
  • HP Smart Array P430i
    • 
-  
  • HP Smart Array P830i
    • 
-  
  • HP Smart Array P430
    • 
-  
  • HP Smart Array P431
    • 
-  
  • HP Smart Array P830
    • 
-  
  • HP Smart Array P731m
    • 
-  
  • HP Smart Array P230i
    • 
-  
  • HP Smart Array P530
    • 
-  
  • HP Smart Array P531
    • 
-  
  • HP Smart Array P244br
    • 
-  
  • HP Smart Array P741m
    • 
-  
  • HP Smart Array H240ar
    • 
-  
  • HP Smart Array H440ar
    • 
-  
  • HP Smart Array P840ar
    • 
-  
  • HP Smart Array P440
    • 
-  
  • HP Smart Array P441
    • 
-  
  • HP Smart Array P841
    • 
-  
  • HP Smart Array H244br
    • 
-  
  • HP Smart Array H240
    • 
-  
  • HP Smart Array H241
    • 
-  
  • HP Smart Array P246br
    • 
-  
  • HP Smart Array P840
    • 
-  
  • HP Smart Array P542d
    • 
-  
  • HP Smart Array P240nr
    • 
-  
  • HP Smart Array H240nr
    • 
-

-
These controllers support RAID 0, RAID 1, RAID 5, JBOD, and
-    superpositions of those configurations.

-
Although the controllers are actual RAID controllers, the
-    ciss driver makes them look just like SCSI
-    controllers. All RAID configuration must be done through the controllers'
-    BIOSes.

-
Hardware from previous generations of this product family may be
-    supported by the cac(4) driver.

-

-

-

-
bio(4), cac(4),
-    intro(4), pci(4),
-    scsi(4), sd(4)

-

-

-

-
The ciss driver first appeared in
-    NetBSD 3.1.

-

-

-

-
The ciss driver was written by
-    Michael Shalayeff
-    <mickey@openbsd.org>,
-    and ported to NetBSD by Tonnerre
-    Lombard
-    <tonnerre@netbsd.org>.

-

-

-
-  
-    
-    
-  
-
July 14, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/clcs.4 4.html b/static/netbsd/man4/clcs.4 4.html
deleted file mode 100644
index cf85542a..00000000
--- a/static/netbsd/man4/clcs.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
CLCS(4)Device Drivers ManualCLCS(4)

-

-

-

-
clcs — Cirrus
-    Logic CS4280 audio device driver

-

-

-

-
clcs* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  midi* at clcs?

-

-

-

-
The clcs driver provides support for the
-    Cirrus Logic CS4280 chip. Partial support exists for the CS461x chips, but
-    is disabled. Instead, the wss(4) or
-    sb(4) drivers should be used.

-

-

-

-
audio(4), midi(4),
-    pci(4), sb(4),
-  wss(4)

-

-

-

-
The clcs device driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
January 2, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/clct.4 4.html b/static/netbsd/man4/clct.4 4.html
deleted file mode 100644
index d393bf15..00000000
--- a/static/netbsd/man4/clct.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
CLCT(4)Device Drivers ManualCLCT(4)

-

-

-

-
clct — Cirrus
-    Logic CS4281 audio device driver

-

-

-

-
clct* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The clct driver provides support for the
-    Cirrus Logic CS4281 chip.

-

-

-

-
ac97(4), audio(4),
-    pci(4)

-

-

-

-
The clct device driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/clockctl.4 4.html b/static/netbsd/man4/clockctl.4 4.html
deleted file mode 100644
index f38e5984..00000000
--- a/static/netbsd/man4/clockctl.4 4.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
CLOCKCTL(4)Device Drivers ManualCLOCKCTL(4)

-

-

-

-
clockctl — Clock
-    subsystem user control

-

-

-

-
pseudo-device clockctl

-

-

-

-
The clockctl interface brings clock
-    control to non-root users. Any user with write access to
-    /dev/clockctl will be able to perform operations
-    such as settimeofday(2),
-    clock_settime(2), adjtime(2), or
-    ntp_adjtime(2), which are normally restricted to the
-    super-user. Using the clockctl pseudo-device, it is
-    possible to run daemons such as ntpd(8) as non-privileged
-    users, thus reducing the security exposure if a compromise is found in such
-    a daemon.

-
The clockctl pseudo-device driver provides
-    an ioctl(2) call for each privileged clock-related system
-    call. The system call stubs in C library will use the
-    ioctl(2) on /dev/clockctl if the
-    special file is present and accessible, or will revert to the plain
-    super-user-restricted system call if the special file is not accessible.

-
The following ioctl(2) calls are defined in
-    <sys/clockctl.h>:

-

-  

-  
This will run the settimeofday(2) system call. Argument
-      should be a pointer to a struct
-      clockctl_settimeofday:
-    

-    
struct clockctl_settimeofday {
-	const struct timeval *tv;
-	const void *tzp;
-};

-    

-  

-  

-  
This will run the clock_settime(2) system call. Argument
-      should be a pointer to a struct
-      clockctl_clock_settime:
-    

-    
struct clockctl_clock_settime {
-	clockid_t clock_id;
-	struct timespec *tp;
-};

-    

-  

-  

-  
This will run the adjtime(2) system call. Argument
-      should be a pointer to a struct clockctl_adjtime:
-    

-    
struct clockctl_adjtime {
-	const struct timeval *delta;
-	struct timeval *olddelta;
-};

-    

-  

-  

-  
This will run the ntp_adjtime(2) system call. Argument
-      should be a pointer to a struct
-      clockctl_ntp_adjtime:
-    

-    
struct clockctl_ntp_adjtime {
-	struct timex *tp;
-};

-    

-  

-

-

-

-

-
adjtime(2), clock_settime(2),
-    ioctl(2), settimeofday(2)

-

-

-

-
clockctl appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
February 19, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/cmdide.4 4.html b/static/netbsd/man4/cmdide.4 4.html
deleted file mode 100644
index 03a101b8..00000000
--- a/static/netbsd/man4/cmdide.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
CMDIDE(4)Device Drivers ManualCMDIDE(4)

-

-

-

-
cmdide — CMD
-    Technology and Silicon Image IDE disk controllers driver

-

-

-

-
cmdide* at pci? dev ? function ? flags
-    0x0000
-  

-  options PCIIDE_CMD064x_DISABLE
-  

-  options PCIIDE_CMD0646U_ENABLEUDMA

-

-

-

-
The cmdide driver supports the CMD
-    Technology PCI0640, PCI0643, PCI0646, PCI0648, PCI0649, and Silicon Image
-    0680 IDE controllers, and provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the cmdide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
There's no way to reliably know if a PCI064x controller is enabled
-    or not. If the driver finds a PCI064x, it will assume it is enabled unless
-    the PCIIDE_CMD064x_DISABLE option is specified in the kernel config file.
-    This will be a problem only if the controller has been disabled in the BIOS
-    and another controller has been installed and uses the ISA legacy I/O ports
-    and interrupts.

-
The PCI0646U controller is known to be buggy with Ultra-DMA
-    transfers, so Ultra-DMA is disabled by default for this controller. To
-    enable Ultra-DMA, use the PCIIDE_CMD0646U_ENABLEUDMA option. Ultra-DMA can
-    eventually be disabled on a per-drive basis with config flags, see
-    wd(4).

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
December 13, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/cmpci.4 4.html b/static/netbsd/man4/cmpci.4 4.html
deleted file mode 100644
index 43b31d2c..00000000
--- a/static/netbsd/man4/cmpci.4 4.html	
+++ /dev/null
@@ -1,136 +0,0 @@
-
-  
-    
-    
-    
-  
-
CMPCI(4)Device Drivers ManualCMPCI(4)

-

-

-

-
cmpci — C-Media
-    CMI8x38 audio device driver

-

-

-

-
cmpci* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  mpu* at cmpci?
-  

-  opl* at cmpci? flags 1

-

-

-

-
The cmpci device driver supports C-Media
-    CMI8x38 based sound cards.

-
The device has SPDIF input/output interfaces, 16bit CODEC with
-    analog mixer, OPL3 FM Synthesizer, and MPU401 compatible MIDI I/O port
-    interface.

-

-

-

-
The mixer device of cmpci driver can be
-    accessed via mixerctl(1) command. The complex structure is
-    analyzed as follows.

-

-
SPDIF in  ----------------------
-#1(coax)->|spdin1              |  R    -----------------------
-#2(opt)-->|spdin2  spdif.input |--*->--|spdin   spdif.output |--> SPDIF
-       -->|spdout              |  | -->|playback             |    output
-       |  ----------------------  | |  -----------------------
-       --------------------<------+-*
-     ---------<-------------------+-+----------------------------------
-     |  ------------------------  | |   -----------------------       |
-     -->|legacy  spdif.output. |--+-*-->|spdout               |       |
-     -->|wave    playback      |  ----->|spdin  spdif.monitor |----   |
-     |  ------------------------     NC-|off                  |   |   |
-     ---------<-- spdif                 -----------------------   |   |
-         -------+------- dac ------------    -----------------    v   |
-wave  -->|playback.mode|---->|inputs.dac|-*->|inputs.dac.mute|->----- |
-playback ---------------     ------------ R  -----------------  | + | |
-                  -----------------     ---------------------   |mix| |
-FM synthesizer -->|inputs.fmsynth |--*->|inputs.fmsynth.mute|-->----- |
-                  -----------------  R  ---------------------     *->--
-CD        ----------------------   ---------------------------    v
-LINE-IN ->|inputs.{cd,line,aux}|-*>|inputs.{cd,line,aux}.mute|->-----
-AUX       ---------------------- R ---------------------------  |   |
-          ------------------                                    |   |
-PC-SPK -->| inputs.speaker |----------------------------------->| + |
-          ------------------                                    |   |
-          -------------------  ------------  -----------------  |mix|
-MIC --*-->|inputs.mic.preamp|->|inputs.mic|->|inputs.mic.mute|->|   |
-      |   -------------------  ------------  -----------------  -----
-      |   ------------   -----------------                       |
-      --->|record.mic|-->|               |                       v
-          ------------   | record.source |-->to         -----------
-                    *R-->| (select, mix) |   recording  |outputs.*|-->
-                         -----------------              ----------- SPK
-                                                                 (front)

-

-
Note the 2nd SPDIF input exists only on CMI8738/PCI-6ch
-  versions.

-

-

-

-
Here are examples about wave playback and SPDIF input/output
-    ports.

-

-  
Playback to speaker, SPDIF input to SPDIF output

-  

-    
mixerctl -w playback.mode=dac
-      spdif.output=spdin spdif.monitor=off

-  

-  
Playback to SPDIF output, SPDIF input to speaker

-  

-    
mixerctl -w playback.mode=spdif
-      spdif.output=playback spdif.output.playback=wave
-      spdif.monitor=spdin

-  

-  
SPDIF input to both SPDIF output and speaker

-  

-    
mixerctl -w spdif.output=spdin
-      spdif.monitor=spdin

-  

-  
Playback to both SPDIF output and speaker

-  

-    
mixerctl -w playback.mode=spdif
-      spdif.output=playback spdif.output.playback=wave
-      spdif.monitor=spdout

-  

-  
Mix playback and SPDIF input to speaker

-  

-    
mixerctl -w playback.mode=dac
-      spdif.monitor=spdin

-  

-

-

-

-

-
mixerctl(1), audio(4),
-    midi(4), mpu(4),
-    opl(4), pci(4)

-

-

-

-
The cmpci device driver appeared in
-    NetBSD 1.5.

-

-

-

-
4ch/6ch playback is not yet available. Joystick port is not
-    supported.

-
spdif.output.playback=legacy does not seem
-    to work properly.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/cms.4 4.html b/static/netbsd/man4/cms.4 4.html
deleted file mode 100644
index 59e5958f..00000000
--- a/static/netbsd/man4/cms.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
CMS(4)Device Drivers ManualCMS(4)

-

-

-

-
cms — Creative
-    Music System device driver

-

-

-

-
cms0 at isa? port 0x220
-  

-  midi* at cms?

-

-

-

-
The cms driver provides support for the
-    Creative Music System (C/MS). These cards were developed by Creative Labs,
-    the same people who designed the SoundBlaster cards. Chips were available
-    for the SoundBlaster to make them compatible with CMS.

-
The CMS cards are only capable of playing basic notes and noises,
-    making them suitable for playing midi, but not much else. The output is
-    stereo, but the cms driver doesn't support stereo
-    control. The cards have external volume control, line-output and
-  speaker.

-
The base I/O port address is usually jumper-selected to 0x220.
-    Valid jumper settings are for 0x210, 0x220, 0x230, 0x240, 0x250 and 0x260.
-    There are no interrupt settings.

-

-

-

-
isa(4), midi(4)

-

-

-

-
The cms device driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
April 28, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/cnw.4 4.html b/static/netbsd/man4/cnw.4 4.html
deleted file mode 100644
index be6ab412..00000000
--- a/static/netbsd/man4/cnw.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
CNW(4)Device Drivers ManualCNW(4)

-

-

-

-
cnw — Netwave
-    AirSurfer wireless network driver

-

-

-

-
cnw* at pcmcia? function ?

-

-

-

-
The cnw interface provides access to a
-    theoretical 1 Mb/s wireless Ethernet network based on the Netwave AirSurfer
-    Wireless LAN (formerly known as the Xircom Netwave Wireless LAN).

-
Note that the driver does not support newer devices such as the
-    Netwave AirSurfer “Plus”, or the BayStack 650/660. These
-    devices are supported by the awi(4) driver.

-
Netwave devices are not compatible with IEEE 802.11 wireless
-    networks. Also note that there are Netwave devices with different wireless
-    frequency, depending on the radio band plan in each country.

-
The card uses 36K of I/O memory mapped to the card. You may need
-    to increase memory space available to the PCMCIA controller. See
-    pcmcia(4) for details.

-
In use, the cards appear to achieve up to a 420Kb/s transfer rate,
-    though a transfer rate between 250Kb/s and 350Kb/s is typical.

-
The card operates in the 2.4GHz frequency range and is subject to
-    interference from microwaves, IEEE 802.11 wireless network devices, as well
-    as earth. For example, it seems that IEEE 802.11 channel 14 conflicts with
-    Netwave (US frequency). They interfere with each other if they are both
-    operated in the same geographic region, causing weird packet loss. You may
-    be able to avoid the interference with IEEE 802.11 devices, by changing the
-    IEEE 802.11 channel.

-

-

-

-
Cards supported by the cnw driver
-  include:

-
    
-  
  • Xircom CreditCard Netwave
    • 
-  
  • NetWave AirSurfer
    • 
-

-

-

-

-

-  
cnw0: can't map memory

-  
Indicates that the driver was not able to allocate enough PCMCIA bus
-      address space into which to map the device. See
-      pcmcia(4) and increase memory available to the PCMCIA
-      controller.

-

-

-

-

-
arp(4), awi(4),
-    inet(4), intro(4),
-    pcmcia(4), cnwctl(8)

-

-

-
-  
-    
-    
-  
-
January 5, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/com.4 4.html b/static/netbsd/man4/com.4 4.html
deleted file mode 100644
index ecbade2c..00000000
--- a/static/netbsd/man4/com.4 4.html	
+++ /dev/null
@@ -1,189 +0,0 @@
-
-  
-    
-    
-    
-  
-
COM(4)Device Drivers ManualCOM(4)

-

-

-

-
com — serial
-    communications interface for RS-232C

-

-

-

-
com0 at isa? port "IO_COM1" irq
-    4
-  

-  com1 at isa? port "IO_COM2" irq 3
-  

-  com* at acpi?
-  

-  com* at cardbus?
-  

-  com* at isapnp?
-  

-  com* at mca? slot ?
-  

-  com* at mhzc?
-  

-  com* at ofisa?
-  

-  com* at pcmcia?
-  

-  com* at pcmcom?
-  

-  com* at pnpbios? index ?
-  

-  com* at puc? port ?
-  

-  com* at xirc?
-  

-  options COM_HAYESP
-  

-  options PPS_SYNC
-  

-  options PPS_TRAILING_EDGE
-  

-  options RND_COM

-

-

-
com* at clockport?

-

-

-

-
com0 at mainbus? base 0x00210fe0
-  

-  com1 at mainbus? base 0x00210be0
-  

-  com0 at pxaip?

-

-

-

-
com* at dio? scode ?
-  

-  com* at frodo? offset ?

-

-

-

-
com* at dino?
-  

-  com* at gsc?
-  

-  com* at ssio?

-

-

-

-
com* at opb?

-

-

-

-
com* at ebus?
-  

-  com* at obio0

-

-

-

-
com0 at intio0 addr 0xefff00 intr 240
-  

-  com1 at intio0 addr 0xefff10 intr 241

-

-

-

-

-
The com driver provides support for
-    NS8250-, NS16450-, and NS16550-based EIA RS-232C (CCITT V.28) communications
-    interfaces. The NS8250 and NS16450 have single character buffers, and the
-    NS16550 has a 16 character buffer.

-
Input and output for each line may set to one of following baud
-    rates; 50, 75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 9600,
-    19200, 38400, 57600, or 115200, or any other baud rate which is a factor of
-    115200.

-
The ttyXX devices are traditional dial-in devices; the dtyXX
-    devices are used for dial-out. (See tty(4).)

-
options COM_HAYESP adds support for the
-    Hayes ESP serial board.

-
options PPS_SYNC enables code to use the
-    Data Carrier Detect (DCD) signal line for attachment to an external
-    precision clock source (e.g., GPS, CDMA) which generates a Pulse Per Second
-    (PPS) signal. This is used by ntpd(8) to discipline the
-    system clock, and more accurately count/measure time. See
-    options(4) for more discussion.

-
With options RND_COM enabled, the
-    com driver can be used to collect entropy for the
-    rnd(4) entropy pool. The entropy is generated from
-    interrupt randomness.

-

-

-
If “flags 1” is specified, the
-    com driver will not set the
-    MCR_IENABLE bit on the UART. This is mainly for use
-    on AST multiport boards, where the MCR_IENABLE bit
-    is used to control whether or not the devices use a shared interrupt.

-

-

-

-

-

-  
/dev/dty00

-  
 

-  
/dev/dty01

-  
 

-  
/dev/dty02

-  
 

-  
/dev/tty00

-  
 

-  
/dev/tty01

-  
 

-  
/dev/tty02

-  
 

-

-

-

-

-

-  
com%d: %d silo overflows

-  
The input “silo” has overflowed and incoming data has been
-      lost.

-  
com%d: weird interrupt: iir=%x

-  
The device has generated an unexpected interrupt with the code
-    listed.

-

-

-

-

-
acpi(4), ast(4),
-    cardbus(4), i386/pnpbios(4),
-    isa(4), isapnp(4),
-    mca(4), mhzc(4),
-    ofisa(4), options(4),
-    pcmcia(4), pcmcom(4),
-    puc(4), pxaip(4),
-    rtfps(4), tty(4),
-    xirc(4), ntpd(8)

-

-

-

-
The com driver was originally derived from
-    the HP9000/300 dca driver.

-

-

-

-
Data loss is possible on busy systems with unbuffered UARTs at
-    high speed.

-
The name of this driver and the constants which define the
-    locations of the various serial ports are holdovers from DOS.

-

-

-
-  
-    
-    
-  
-
March 4, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/coram.4 4.html b/static/netbsd/man4/coram.4 4.html
deleted file mode 100644
index 02f8cb9e..00000000
--- a/static/netbsd/man4/coram.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
CORAM(4)Device Drivers ManualCORAM(4)

-

-

-

-
coram — digital
-    video driver for Conexant CX23885 based cards

-

-

-

-
coram* at pci? dev ? function ?
-  

-  iic* at coram?

-

-

-

-
The coram driver provides support for
-    digital video cards based on the Conexant CX23885 DTV interface chips.

-
Supported cards include:

-
    
-  
  • Hauppauge WinTV HVR-1250
    • 
-

-

-

-

-
dtv(4), iic(4)

-

-

-

-
The coram device driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The coram driver was written by
-    Jonathan A. Kollasch
-    ⟨jakllsch@NetBSD.org⟩ and Jared D.
-    McNeill ⟨jmcneill@NetBSD.org⟩.

-

-

-

-
No support for analog capture and for IR receivers.

-

-

-
-  
-    
-    
-  
-
August 13, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/crypto.4 3.html b/static/netbsd/man4/crypto.4 3.html
deleted file mode 100644
index 8dc2c029..00000000
--- a/static/netbsd/man4/crypto.4 3.html	
+++ /dev/null
@@ -1,616 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRYPTO(4)Device Drivers ManualCRYPTO(4)

-

-

-

-
crypto, swcrypto
-    — user-mode access to hardware-accelerated
-    cryptography

-

-

-

-
hifn* at pci? dev ? function ?
-  

-  ubsec* at pci? dev ? function ?

-

-  

-  pseudo-device crypto
-  

-  pseudo-device swcrypto

-

-  

-  #include <sys/ioctl.h>
-  

-  #include <sys/time.h>
-  

-  #include
-  <crypto/cryptodev.h>

-

-

-

-
The crypto driver gives user-mode
-    applications access to hardware-accelerated cryptographic transforms, as
-    implemented by the opencrypto(9) in-kernel interface.

-
The swcrypto driver is a software-only
-    implementation of the opencrypto(9) interface, and must be
-    included to use the interface without hardware acceleration.

-
The /dev/crypto special device provides an
-    ioctl(2) based interface. User-mode applications should
-    open the special device, then issue ioctl(2) calls on the
-    descriptor. User-mode access to /dev/crypto is
-    generally controlled by three sysctl(8) variables,
-    kern.usercrypto,
-    kern.userasymcrypto, and
-    kern.cryptodevallowsoft. See
-    sysctl(7) for additional details.

-
The crypto device provides two distinct
-    modes of operation: one mode for symmetric-keyed cryptographic requests, and
-    a second mode for both asymmetric-key (public-key/private-key) requests, and
-    for modular arithmetic (for Diffie-Hellman key exchange and other
-    cryptographic protocols). The two modes are described separately below.

-

-

-

-
Regardless of whether symmetric-key or asymmetric-key operations
-    are to be performed, use of the device requires a basic series of steps:

-
    
-  
  1. Open a file descriptor for the device. See open(2).
    2. 
-  
  2. If any symmetric operation will be performed, create one session, with
-      CIOCGSESSION, or multiple sessions, with
-      CIOCNGSESSION. Most applications will require at
-      least one symmetric session. Since cipher and MAC keys are tied to
-      sessions, many applications will require more. Asymmetric operations do
-      not use sessions.
    3. 
-  
  3. Submit requests, synchronously with CIOCCRYPT
-      (symmetric) or CIOCKEY (asymmetric) or
-      asynchronously with CIOCNCRYPTM (symmetric) or
-      CIOCNFKEYM (asymmetric). The asynchronous
-      interface allows multiple requests to be submitted in one call if the user
-      so desires.
    4. 
-  
  4. If the asynchronous interface is used, wait for results with
-      select(2) or poll(2), then collect
-      them with CIOCNCRYPTRET (a particular request) or
-      CIOCNCRYPTRETM (multiple requests).
    5. 
-  
  5. Destroy one session with CIOCFSESSION or many at
-      once with CIOCNFSESSION.
    6. 
-  
  6. Close the device with close(2).
    7. 
-

-

-

-

-
The symmetric-key operation mode provides a context-based API to
-    traditional symmetric-key encryption (or privacy) algorithms, or to keyed
-    and unkeyed one-way hash (HMAC and MAC) algorithms. The symmetric-key mode
-    also permits fused operation, where the hardware performs both a privacy
-    algorithm and an integrity-check algorithm in a single pass over the data:
-    either a fused encrypt/HMAC-generate operation, or a fused
-    HMAC-verify/decrypt operation.

-
To use symmetric mode, you must first create a session specifying
-    the algorithm(s) and key(s) to use; then issue encrypt or decrypt requests
-    against the session.

-

-

-
Contingent upon device drivers for installed cryptographic
-    hardware registering with opencrypto(9), as providers of a
-    given algorithm, some or all of the following symmetric-key privacy
-    algorithms may be available:

-

-

-

-  
CRYPTO_DES_CBC

-  
 

-  
CRYPTO_3DES_CBC

-  
 

-  
CRYPTO_BLF_CBC

-  
 

-  
CRYPTO_CAST_CBC

-  
 

-  
CRYPTO_SKIPJACK_CBC

-  
 

-  
CRYPTO_AES_CBC

-  
 

-  
CRYPTO_ARC4

-  
 

-

-

-

-

-

-
Contingent upon hardware support, some or all of the following
-    keyed one-way hash algorithms may be available:

-

-

-

-  
CRYPTO_RIPEMD160_HMAC

-  
 

-  
CRYPTO_MD5_KPDK

-  
 

-  
CRYPTO_SHA1_KPDK

-  
 

-  
CRYPTO_MD5_HMAC

-  
 

-  
CRYPTO_SHA1_HMAC

-  
 

-  
CRYPTO_SHA2_256_HMAC

-  
 

-  
CRYPTO_SHA2_384_HMAC

-  
 

-  
CRYPTO_SHA2_512_HMAC

-  
 

-  
CRYPTO_MD5

-  
 

-  
CRYPTO_SHA1

-  
 

-

-

-
The
-     and
-    
-    algorithms are actually unkeyed, but should be requested as symmetric-key
-    hash algorithms with a zero-length key.

-

-

-

-

-  

-    int *fd

-  
This operation is deprecated and will be removed after
-      NetBSD 5.0. It clones the fd argument to
-      ioctl(2), yielding a new file descriptor for the
-      creation of sessions. Because the device now clones on open, this
-      operation is unnecessary.

-  

-    struct session_op *sessp

-  

-    

-    
struct session_op {
-    u_int32_t cipher;	/* e.g. CRYPTO_DES_CBC */
-    u_int32_t mac;	/* e.g. CRYPTO_MD5_HMAC */
-
-    u_int32_t keylen;	/* cipher key */
-    void * key;
-    int mackeylen;	/* mac key */
-    void * mackey;
-
-    u_int32_t ses;	/* returns: ses # */
-};
-
-    

-    

-    Create a new cryptographic session on a file descriptor for the device; that
-      is, a persistent object specific to the chosen privacy algorithm,
-      integrity algorithm, and keys specified in sessp.
-      The special value 0 for either privacy or integrity is reserved to
-      indicate that the indicated operation (privacy or integrity) is not
-      desired for this session.
-    
Multiple sessions may be bound to a single file descriptor.
-        The session ID returned in sessp->ses is
-        supplied as a required field in the symmetric-operation structure
-        crypt_op for future encryption or hashing
-        requests.

-    
This implementation will never return a session ID of 0 for a
-        successful creation of a session, which is a
-        NetBSD extension.

-    
For non-zero symmetric-key privacy algorithms, the privacy
-        algorithm must be specified in sessp->cipher,
-        the key length in sessp->keylen, and the key
-        value in the octets addressed by
-      sessp->key.

-    
For keyed one-way hash algorithms, the one-way hash must be
-        specified in sessp->mac, the key length in
-        sessp->mackey, and the key value in the octets
-        addressed by sessp->mackeylen.

-    
Support for a specific combination of fused privacy and
-        integrity-check algorithms depends on whether the underlying hardware
-        supports that combination. Not all combinations are supported by all
-        hardware, even if the hardware supports each operation as a stand-alone
-        non-fused operation.

-  

-  

-    struct crypt_sgop *sgop

-  

-    

-    
struct crypt_sgop {
-    size_t	count;			/* how many */
-    struct session_n_op * sessions; /* where to get them */
-};
-
-struct session_n_op {
-    u_int32_t cipher;		/* e.g. CRYPTO_DES_CBC */
-    u_int32_t mac;		/* e.g. CRYPTO_MD5_HMAC */
-
-    u_int32_t keylen;		/* cipher key */
-    void * key;
-    u_int32_t mackeylen;	/* mac key */
-    void * mackey;
-
-    u_int32_t ses;		/* returns: session # */
-    int status;
-};
-
-    

-    

-    Create one or more sessions. Takes a counted array of
-      session_n_op structures in
-      sgop. For each requested session (array element n),
-      the session number is returned in
-      sgop->sessions[n].ses and the status for that
-      session creation in
-    sgop->sessions[n].status.

-  

-    struct crypt_op *cr_op

-  

-    

-    
struct crypt_op {
-    u_int32_t ses;
-    u_int16_t op;	/* e.g. COP_ENCRYPT */
-    u_int16_t flags;
-    u_int len;
-    void * src, *dst;
-    void * mac;		/* must be large enough for result */
-    void * iv;
-};
-
-    

-    

-    Request a symmetric-key (or hash) operation. The file descriptor argument to
-      ioctl(2) must have been bound to a valid session. To
-      encrypt, set cr_op->op to
-      COP_ENCRYPT. To decrypt, set
-      cr_op->op to COP_DECRYPT.
-      The field cr_op->len supplies the length of the
-      input buffer; the fields cr_op->src,
-      cr_op->dst, cr_op->mac,
-      cr_op->iv supply the addresses of the input
-      buffer, output buffer, one-way hash, and initialization vector,
-      respectively.

-  

-    struct crypt_mop *cr_mop

-  

-    

-    
struct crypt_mop {
-    size_t count;		/* how many */
-    struct crypt_n_op * reqs;	/* where to get them */
-};
-
-struct crypt_n_op {
-    u_int32_t ses;
-    u_int16_t op;		/* e.g. COP_ENCRYPT */
-    u_int16_t flags;
-    u_int len;
-
-    u_int32_t reqid;		/* request id */
-    int status;			/* accepted or not */
-
-    void *opaque;		/* opaque pointer ret to user */
-    u_int32_t keylen;		/* cipher key - optional */
-    void * key;
-    u_int32_t mackeylen;	/* mac key - optional */
-    void * mackey;
-
-    void * src, * dst;
-    void * mac;
-    void * iv;
-};
-
-    

-    

-    This is the asynchronous version of CIOCCRYPT, which allows multiple
-      symmetric-key (or hash) operations to be started (see CIOCRYPT above for
-      the details for each operation).
-    
The cr_mop->count field specifies the
-        number of operations provided in the cr_mop->reqs array.

-    
Each operation is assigned a unique request id returned in the
-        cr_mop->reqs[n].reqid field.

-    
Each operation can accept an opaque value from the user to be
-        passed back to the user when the operation completes (e.g., to track
-        context for the request). The opaque field is
-        cr_mop->reqs[n].opaque.

-    
If a problem occurs with starting any of the operations then
-        that operation's cr_mop->reqs[n].status field
-        is filled with the error code. The failure of an operation does not
-        prevent the other operations from being started.

-    
The select(2) or poll(2)
-        functions must be used on the device file descriptor to detect that some
-        operation has completed; results are then retrieved with
-        CIOCNCRYPTRETM.

-    
The key and mackey
-        fields of the operation structure are currently unused. They are
-        intended for use to immediately rekey an existing session before
-        processing a new request.

-  

-  

-    u_int32_t *ses_id

-  
Destroys the /dev/crypto session associated with the file-descriptor
-      argument.

-  

-    struct crypt_sfop *sfop

-  

-    

-    
struct crypt_sfop {
-    size_t count;
-    u_int32_t *sesid;
-};
-
-    

-    

-    Destroys the sfop->count sessions specified by the
-      sfop array of session identifiers.

-

-

-

-

-

-

-

-
Contingent upon hardware support, the following asymmetric
-    (public-key/private-key; or key-exchange subroutine) operations may also be
-    available:

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
Input parameterOutput parameter
 CountCount
31
61
31
21
31
31
21
21
52
70
31

-
See below for discussion of the input and output parameter
-  counts.

-

-

-

-

-  

-    int *feature_mask

-  
Returns a bitmask of supported asymmetric-key operations. Each of the
-      above-listed asymmetric operations is present if and only if the bit
-      position numbered by the code for that operation is set. For example,
-      CRK_MOD_EXP is available if and only if the bit (1
-      << CRK_MOD_EXP) is set.

-  

-    struct crypt_kop *kop

-  

-    

-    
struct crypt_kop {
-    u_int crk_op;		/* e.g. CRK_MOD_EXP */
-    u_int crk_status;		/* return status */
-    u_short crk_iparams;	/* # of input params */
-    u_short crk_oparams;	/* # of output params */
-    u_int crk_pad1;
-    struct crparam crk_param[CRK_MAXPARAM];
-};
-
-/* Bignum parameter, in packed bytes. */
-struct crparam {
-    void * crp_p;
-    u_int crp_nbits;
-};
-
-    

-    

-    Performs an asymmetric-key operation from the list above. The specific
-      operation is supplied in kop->crk_op; final
-      status for the operation is returned in
-      kop->crk_status. The number of input arguments
-      and the number of output arguments is specified in
-      kop->crk_iparams and
-      kop->crk_iparams, respectively. The field
-      crk_param[] must be filled in with exactly
-      kop->crk_iparams + kop->crk_oparams arguments,
-      each encoded as a struct crparam (address,
-      bitlength) pair.
-    
The semantics of these arguments are currently
-      undocumented.

-  

-  

-    struct crypt_mkop *mkop

-  

-    

-    
struct crypt_mkop {
-    size_t count;		/* how many */
-    struct crypt_n_op * reqs;	/* where to get them */
-};
-
-struct crypt_n_kop {
-    u_int crk_op;		/* e.g. CRK_MOD_EXP */
-    u_int crk_status;		/* accepted or not */
-    u_short crk_iparams;	/* # of input params */
-    u_short crk_oparams;	/* # of output params */
-    u_int32_t crk_reqid;	/* request id */
-    struct crparam crk_param[CRK_MAXPARAM];
-    void *crk_opaque;		/* opaque pointer ret to user */
-};
-
-    

-    

-    This is the asynchronous version of CIOCKEY, which
-      starts one or more key operations. See CIOCNCRYPTM
-      above and CIOCNCRYPTRETM below for descriptions of
-      the mkop>count,
-      mkop>reqs,
-      mkop>reqs[n].crk_reqid,
-      mkop>reqs[n].crk_status, and
-      mkop>reqs[n].crk_opaque fields of the argument
-      structure, and result retrieval.

-

-

-

-

-
When requests are submitted with the
-    CIOCNCRYPTM or CIOCNFKEYM
-    commands, result retrieval is asynchronous (the submit ioctls return
-    immediately). Use the select(2) or
-    poll(2) functions to determine when the file descriptor
-    has completed operations ready to be retrieved.

-

-  

-    struct crypt_result *cres

-  

-    

-    
struct crypt_result {
-    u_int32_t reqid;	/* request ID */
-    u_int32_t status;	/* 0 if successful */
-    void * opaque;	/* pointer from user */
-};
-
-    

-    

-    Check for the status of the request specified by
-      cres->reqid. This requires a linear search
-      through all completed requests and should be used with extreme care if the
-      number of requests pending on this file descriptor may be large.
-    
The cres->status field is set as
-        follows:

-    

-      
0

-      
The request has completed, and its results have been copied out to the
-          original crypt_n_op or
-          crypt_n_kop structure used to start the request.
-          The copyout occurs during this ioctl, so the calling process must be
-          the process that started the request.

-      
EINPROGRESS

-      
The request has not yet completed.

-      
EINVAL

-      
The request was not found.

-    

-    
Other values indicate a problem during the processing of the
-        request.

-  

-  

-    struct cryptret_t *cret

-  

-    

-    
struct cryptret {
-    size_t count;			/* space for how many */
-    struct crypt_result * results;	/* where to put them */
-};
-
-    

-    

-    Retrieve a number of completed requests. This ioctl accepts a count and an
-      array (each array element is a crypt_result_t
-      structure as used by CIOCNCRYPTRET above) and
-      fills the array with up to cret->count results of
-      completed requests.
-    
This ioctl fills in the
-        cret->results[n].reqid field, so that the
-        request which has completed may be identified by the application. Note
-        that the results may include requests submitted both as symmetric and
-        asymmetric operations.

-  

-

-

-

-

-

-
hifn(4), ubsec(4),
-    opencrypto(9)

-

-

-

-
The crypto driver is derived from a
-    version which appeared in FreeBSD 4.8, which in turn
-    is based on code which appeared in OpenBSD 3.2.

-
The "new API" for asynchronous operation with multiple
-    basic operations per system call (the "N" ioctl variants) was
-    contributed by Coyote Point Systems, Inc. and first appeared in
-    NetBSD 5.0.

-

-

-

-
Error checking and reporting is weak.

-
The values specified for symmetric-key key sizes to
-    CIOCGSESSION must exactly match the values expected
-    by opencrypto(9). The output buffer and MAC buffers
-    supplied to CIOCCRYPT must follow whether privacy or
-    integrity algorithms were specified for session: if you request a
-    non-NULL algorithm, you must
-    supply a suitably-sized buffer.

-
The scheme for passing arguments for asymmetric requests is
-    baroque.

-
The naming inconsistency between CRIOGET
-    and the various CIOC* names is an unfortunate
-    historical artifact.

-

-

-
-  
-    
-    
-  
-
January 27, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/cs.4 4.html b/static/netbsd/man4/cs.4 4.html
deleted file mode 100644
index f89792f8..00000000
--- a/static/netbsd/man4/cs.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
CS(4)Device Drivers ManualCS(4)

-

-

-

-
cs — Cirrus Logic
-    Crystal CS89x0 Ethernet driver

-

-

-

-
cs0 at isa? port 0x300 iomem ? irq ? drq ?
-  

-  cs* at ofisa?
-  

-  cs* at isapnp?
-  

-  cs* at pcmcia? function ?
-  

-  cs0 at mainbus0 (PM/PPC port)

-

-

-

-
The cs driver supports Ethernet interfaces
-    based on the Cirrus Logic Crystal CS8900, 8920 and 8920M ISA bus Ethernet
-    controllers.

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), ofisa(4),
-    ifconfig(8)

-
Cirrus Logic

-

-

-

-
The cs driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
June 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/cs80bus.4 4.html b/static/netbsd/man4/cs80bus.4 4.html
deleted file mode 100644
index b5dd8fb4..00000000
--- a/static/netbsd/man4/cs80bus.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
CS80BUS(4)Device Drivers ManualCS80BUS(4)

-

-

-

-
cs80bus — support
-    for CS80/SS80 on the IEEE488 GPIB

-

-

-

-
cs80bus* at gpib?

-

-

-

-
The cs80bus driver supports devices on the
-    IEEE488 GPIB which communicate using the CS80/SS80 protocol. These device
-    are primarily block devices such as tapes and disks drives commonly found on
-    HP/Agilent equipment.

-

-

-

-
ct(4), gpib(4),
-    mt(4), rd(4)

-

-

-

-
The cs80bus driver appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
May 24, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/cuda.4 4.html b/static/netbsd/man4/cuda.4 4.html
deleted file mode 100644
index 8fd1cee4..00000000
--- a/static/netbsd/man4/cuda.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
CUDA(4)Device Drivers ManualCUDA(4)

-

-

-

-
cuda — support for
-    CUDA microcontrollers found in many Power Macintosh and compatible
-    computers

-

-

-

-
cuda* at obio?
-  

-  nadb* at cuda?
-  

-  iic* at cuda?

-

-

-

-
The cuda driver provides support for the
-    CUDA microcontroller found in many Power Macintosh and compatible computers,
-    mostly Old World desktop machines. CUDA controls the real time clock, ADB,
-    power and on some machines an iic(9) bus.

-

-

-

-
iic(4), nadb(4),
-    obio(4), pmu(4),
-    sgsmix(4)

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/cue.4 4.html b/static/netbsd/man4/cue.4 4.html
deleted file mode 100644
index 07cb4c26..00000000
--- a/static/netbsd/man4/cue.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
CUE(4)Device Drivers ManualCUE(4)

-

-

-

-
cue — CATC
-    USB-EL1201A USB Ethernet driver

-

-

-

-
cue* at uhub?

-

-

-

-
The cue driver supports the following
-    adapters:

-

-

-

-  
Belkin F5U111

-  
 

-  
CATC Netmate

-  
 

-  
CATC Netmate II

-  
 

-

-

-

-

-

-
The cue driver provides support for USB
-    Ethernet adapters based on the Computer Access Technology Corporation's
-    USB-EL1202A chipset.

-
The USB-EL1202A supports a 512-bit multicast hash filter, single
-    perfect filter entry for the station address and promiscuous mode. Packets
-    are received and transmitted over separate USB bulk transfer endpoints.

-
The CATC adapter supports only 10Mbps half-duplex mode, hence
-    there are no ifmedia(4) modes to select.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), netintro(4),
-    usb(4), usbnet(4),
-    ifconfig(8)

-

-

-

-
The cue device driver first appeared in
-    FreeBSD 4.0, and in NetBSD
-    1.5.

-

-

-

-
The cue driver was written by
-    Bill Paul
-    <wpaul@ee.columbia.edu>.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/cxdtv.4 4.html b/static/netbsd/man4/cxdtv.4 4.html
deleted file mode 100644
index d27745a2..00000000
--- a/static/netbsd/man4/cxdtv.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
CXDTV(4)Device Drivers ManualCXDTV(4)

-

-

-

-
cxdtv — digital
-    video driver for Conexant CX2388x based cards

-

-

-

-
cxdtv* at pci? dev ? function ?

-

-

-

-
The cxdtv driver provides support for
-    digital video cards based on the Conexant CX23881, CX23882, CX23883, and
-    CX23884 multimedia bridges.

-
Supported cards include:

-
    
-  
  • ATI HDTV Wonder (digital-only)
    • 
-  
  • pcHDTV HD5500
    • 
-

-

-

-

-
dtv(4)

-

-

-

-
The cxdtv device driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The cxdtv driver was written by
-    Jonathan A. Kollasch
-    ⟨jakllsch@NetBSD.org⟩ and Jared D.
-    McNeill ⟨jmcneill@NetBSD.org⟩.

-

-

-

-
The cxdtv driver lacks support for analog
-    video capture, analog audio capture, FM tuning, and the IR receiver.

-

-

-
-  
-    
-    
-  
-
August 13, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/cy.4 4.html b/static/netbsd/man4/cy.4 4.html
deleted file mode 100644
index f0017b75..00000000
--- a/static/netbsd/man4/cy.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
CY(4)Device Drivers ManualCY(4)

-

-

-

-
cy — Cyclades
-    Cyclom-{4, 8, 16, 32}Y asynchronous comms board serial device
-  driver

-

-

-

-
cy0 at isa? iomem 0xd4000 irq 12
-  

-  cy* at pci? dev ? function ?

-

-

-

-
This driver provides an interface to Cyclades Cyclom-4Y,
-    Cyclom-8Y, Cyclom-16Y, and Cyclom-32Y asynchronous multiport serial boards.
-    These boards are based around Cirrus Logic CD1400 communication
-  controllers.

-
The device minor numbers for this driver are encoded as
-  follows:

-

-
    d c c p p p p p	- bits in the minor device number
-
-    bits    meaning
-    ----    -------
-    ppppp   physical serial line (i.e. port) to use:
-		0-3 on Cyclom-4Y
-		0-7 on Cyclom-8Y
-		0-15 on Cyclom-16Y
-		0-31 on Cyclom-32Y
-
-    cc      card unit number; note this limits the driver to
-	    four cards per system
-
-    d       set to use as a dial-out line

-

-

-

-

-
The cy driver makes use of the CD1400's
-    automatic CTS flow control. In addition, the CD1400's automatic input flow
-    control can be used. This requires the kernel configuration option
-    
-    and a special cable that exchanges the RTS and DTR lines.

-

-

-

-

-  
cy%d: port %d: can't allocate tty

-  
There is not enough memory to allocate tty data structures.

-  
cy%d: can't allocate input buffer

-  
There is not enough memory to allocate the data input buffer.

-

-
Additional debugging output can be enable with the
-    kernel configuration option
-    .
-    Diagnostic counters may be enabled with the kernel configuration option
-    .

-

-

-

-
termios(4), tty(4)

-

-

-

-
The cy driver was written by Timmo
-  Rossi.

-

-

-

-
Support for the Cyclom-32Y has not been tested.

-

-

-
-  
-    
-    
-  
-
November 10, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/cypide.4 4.html b/static/netbsd/man4/cypide.4 4.html
deleted file mode 100644
index 048f0036..00000000
--- a/static/netbsd/man4/cypide.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
CYPIDE(4)Device Drivers ManualCYPIDE(4)

-

-

-

-
cypide — Cypress
-    IDE disk controllers driver

-

-

-

-
cypide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The cypide driver supports the Cypress
-    82C693 IDE controllers, and provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the cypide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/cz.4 3.html b/static/netbsd/man4/cz.4 3.html
deleted file mode 100644
index b635a68d..00000000
--- a/static/netbsd/man4/cz.4 3.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
CZ(4)Device Drivers ManualCZ(4)

-

-

-

-
cz — Cyclades-Z
-    series multi-port serial adapter device driver

-

-

-

-
cz* at pci? dev ? function ?

-

-

-

-
The cz device driver supports the
-    Cyclades-Z series of multi-port serial adapters. The Cyclades-Z is an
-    intelligent serial controller comprising:

-
    
-  
  • PLX9060ES PCI bus interface
    • 
-  
  • Xilinx XC5204 FPGA
    • 
-  
  • IDT R3052 MIPS CPU
    • 
-

-
The MIPS CPU runs firmware provided by the device driver.
-    Communication with the MIPS is performed by modifying data structures
-    located in board local RAM or host RAM.

-
The Cyclades-Z comes in three basic flavors:

-
    
-  
  • Cyclades-8Zo rev. 1 -- This is an older 8-port board with no FPGA. The
-      serial ports are provided by an octopus cable.
    • 
-  
  • Cyclades-8Zo rev. 2 -- This is the newer 8-port board. The serial ports
-      are provided by an octopus cable.
    • 
-  
  • Cyclades-Ze -- This is the expandable version of the Cyclades-Z. It uses
-      an HD-50 SCSI cable to connect the board to a 1U rack mountable serial
-      expansion box. Each box has 16 RJ45 serial ports, and up to 4 boxes may be
-      chained together, for a total of 64 ports. Boxes 3 and 4 require their own
-      external power supply, otherwise the firmware will refuse to start (as it
-      cannot communicate with the UARTs in those boxes).
    • 
-

-
The Cyclades-Z has several features to improve performance under
-    high serial I/O load:

-
    
-  
  • The board may operate in interrupt-driven mode or polled mode to reduce
-      interrupt load.
    • 
-  
  • Each channel has a large input and output buffer.
    • 
-  
  • Each channel may be programmed to generate an interrupt based on reception
-      of a specific character, e.g. a PPP End-Of-Frame character.
    • 
-  
  • The MIPS CPU on the board performs all flow-control handling.
    • 
-

-

-

-

-

-  
/dev/ttyCZnnnn -- dial-in (normal) TTY device

-  
 

-  
/dev/dtyCZnnnn -- dial-out TTY device

-  
 

-

-

-

-

-
pci(4), termios(4),
-    tty(4)

-

-

-

-
The cz driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The cz driver was written by
-    Jason R. Thorpe
-    <thorpej@zembu.com>
-    and
-  

-  Bill Studenmund
-    <wrstuden@zembu.com>
-    of Zembu Labs, Inc.

-

-

-

-
The cz driver does not currently implement
-    communication via host RAM. While this may improve performance by reducing
-    the number of PCI memory space read/write cycles, it is not straightforward
-    to implement with the current bus_dma(9) API.

-
Interrupt mode has not been tested.

-
There is no support for reading or writing the EEPROM connected to
-    the PLX PCI bus controller.

-

-

-
-  
-    
-    
-  
-
May 17, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/dbcool.4 3.html b/static/netbsd/man4/dbcool.4 3.html
deleted file mode 100644
index 10ccbb27..00000000
--- a/static/netbsd/man4/dbcool.4 3.html	
+++ /dev/null
@@ -1,265 +0,0 @@
-
-  
-    
-    
-    
-  
-
DBCOOL(4)Device Drivers ManualDBCOOL(4)

-

-

-

-
dbcool, adm1027,
-    adm1030, adm1031,
-    adt7463, adt7466,
-    adt7467, adt7468,
-    adt7473, adt7475,
-    adt7476, adt7490,
-    emc6d103s — dbCool(tm)
-    family of environmental monitors and fan controllers

-

-

-

-
dbcool* at ki2c?
-  

-  dbcool* at iic? addr 0x2e

-

-

-

-
The dbcool driver provides support for the
-    Analog Devices dbCool and the SMSC EMC6D103S environmental monitor chips to
-    be used with the envsys(4) API.

-
These chips support up to fifteen sensors. Not all of the
-    following sensors are supported on all chips.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uKlocal chip temperature
uKCPU temperature
uKGPU temperature
uV DCCPU Vcore
uV DCChip's supply voltage
uV DC2.5V supply
uV DC5V supply
uV DC12V supply
uV DCPECI ref. voltage (2.25V ref, ADT7490 only)
uV DCCurrent monitor (2.25V ref, ADT7490 only)
uV DCAnalog In (2.25V ref, ADT7466 only)
uV DCAnalog In (2.25V ref, ADT7466 only)
RPMChassis Fan
RPMChassis Fan
RPMChassis Fan
RPMChassis Fan
(none)CPU VID code (selected chips only)

-
Each temperature and voltage sensor has programmable hardware
-    high- and low-limits; fan sensors have only a low-limit. These limits can be
-    set using the envstat(8) utility. Due to hardware
-    limitations, the minimum permissible value for the fan speed low-limits is
-    83 RPM.

-
Temperature sensors also have Tmin,
-    ,
-    Thyst, and Ttherm
-    sysctl(8) variables; these values are used by the fan
-    speed controllers. Their values are in units of degC, since this is the unit
-    which is programmed into the device registers.

-
All members of the dbCool family support Pulse-Width Modulated
-    (PWM) fan speed control based on temperature thresholds - the fan will spin
-    up when its associated thermal sensor(s) exceeds its configured
-    Tmin value. The fan will go faster as the temperature
-    rises, and will slow down as the temperature falls. If the temperature
-    exceeds the sensor's Ttherm value, the THERM signal will
-    be asserted, and if enabled the fan will run at full speed. The fan will be
-    turned off when the sensor(s) that triggered it reports a temperature which
-    is at least Thyst degrees below its Tmin
-    threshold.

-
Each fan controller is programmable using the following
-    sysctl(8) variables.

-

-
hw.dbcool0.fan_ctl_0.behavior
-hw.dbcool0.fan_ctl_0.min_duty
-hw.dbcool0.fan_ctl_0.max_duty
-hw.dbcool0.fan_ctl_0.cur_duty

-

-
The behavior variable controls the
-    selection of temperature sensors associated with the fan controller. When
-    the associated temperature sensor reaches its Tmin value,
-    the fan controller starts the fan at its minimum duty cycle; when the
-    associated temperature sensor reaches its Ttherm value and
-    asserts the THERM signal (or if an external THERM signal is asserted), the
-    fan controller sets the fan speed to a 100% duty cycle. Between these two
-    settings, each temperature sensor is used to calculate a duty cycle linearly
-    based on the slope defined by the temperature sensor's
-     variable.
-    When the associated temperature falls at least Thyst
-    degrees below its Tmin value, the fan controller will turn
-    off the fan. (On the ADM1030, the value for Thyst is fixed
-    at 5 degC.)

-
Valid values for the behavior variable are:

-

-
local           (not available on ADM1030)
-remote1
-remote2         (not available on ADM1030)
-local+remote2   (not available on ADM1030)
-all-temps
-full-speed      (not available on ADM1030)
-manual
-disabled

-

-
When the behavior variable is set to
-    “manual”, the cur-duty variable becomes
-    user-writable and can be set to any value between 0 and 100 inclusive to
-    control the fan's duty cycle manually. In all other
-    behavior modes, the cur-duty variable is
-    read-only and updates are ignored.

-
The
-     and
-    max-duty variables define the range over which the fan
-    controller will manage the fan's duty cycle. On the ADM1030, these values
-    are not separately controllable. The max-duty is fixed at
-    100%, and the cur-duty variable is used to specify the
-    minimum duty cycle when the fan controller is running in automatic mode.

-
Note that the duty-cycle value does not directly correspond to the
-    fan's speed. That is, a 33% duty cycle does not mean that the fan runs at
-    33% of its maximum speed; in actuality, a 33% duty cycle drives the fan at a
-    speed close to 50% of its maximum. Fan speed correlates approximately to the
-    square root of the duty cycle.

-

-

-

-
The envstat(8) utility can be used to determine
-    the sensors supported:

-

-
            Current  CritMax  WarnMax  WarnMin  CritMin Unit
- l_temp:     44.250                                     degC
-r1_temp:     41.250                                     degC
-r2_temp:        N/A
-   Vccp:      0.002                                     V
-    Vcc:      3.351                                     V
-   fan1:        N/A
-   fan2:        N/A
-   fan3:        N/A
-   fan4:        N/A

-

-
Using this information, the following commands in
-    /etc/envsys.conf will set appropriate limits for CPU
-    temperature and chip supply voltage, and powerd will be notified if the
-    limits are exceeded:

-

-
dbcool0 {
-        sensor1 {
-                warning-max  = 60C;
-                critical-max = 65C;
-        }
-        sensor4 {
-                critical-min = 3.1;
-                warning-min =  3.2;
-                critical-max = 3.5;
-        }
-}

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), powerd(8),
-    sysctl(8)

-

-

-

-
The dbcool device appeared in
-    NetBSD 5.0.

-

-

-

-
Although the sensor limit registers can be programmed, there is
-    currently no use of the dbCool chips' ability to generate an SMBus interrupt
-    when the limits are exceeded. Limit checking and event generation are done
-    in software, and are performed only when the sensor values are polled and
-    refreshed.

-
The ADT7466 chip, although officially a member of the dbCool
-    family, is programmed quite differently. The fan controllers on this chip
-    are not currently implemented.

-
The PECI (Processor Environment Control Interface) temperature
-    sensors and the associated PWM behavior modes on the ADT7490 are not
-    currently supported.

-

-

-
-  
-    
-    
-  
-
June 10, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/ddb.4 4.html b/static/netbsd/man4/ddb.4 4.html
deleted file mode 100644
index d5f3760b..00000000
--- a/static/netbsd/man4/ddb.4 4.html	
+++ /dev/null
@@ -1,1210 +0,0 @@
-
-  
-    
-    
-    
-  
-
DDB(4)Device Drivers ManualDDB(4)

-

-

-

-
ddb — in-kernel
-    debugger

-

-

-

-
options DDB

-
To enable history editing:
-  

-  options DDB_HISTORY_SIZE=integer

-
To disable entering ddb upon kernel panic:
-  

-  options DDB_ONPANIC=0

-
To enable teeing all ddb output to the
-    kernel msgbuf:
-  

-  options DDB_TEE_MSGBUF=1

-
To specify commands which will be executed on each entry to
-    ddb:
-  

-  options DDB_COMMANDONENTER="trace;show
-    registers" In this case, "trace" and then "show
-    registers" will be executed automatically.

-
To enable extended online help:
-  

-  options DDB_VERBOSE_HELP.

-

-

-

-
ddb is the in-kernel debugger. It may be
-    entered at any time via a special key sequence, and optionally may be
-    invoked when the kernel panics.

-

-

-

-
Unless DDB_ONPANIC is set to 0,
-    ddb will be activated whenever the kernel would
-    otherwise panic.

-
ddb may also be activated from the
-    console. In general, sending a break on a serial console will activate
-    ddb. There are also key sequences for each port that
-    will activate ddb from the keyboard:

-

-

-  
alpha

-  
<Ctrl>-<Alt>-<Esc> on PC style keyboards.

-  
amd64

-  
<Ctrl>-<Alt>-<Esc>

-  

-  
<Break> on serial console.

-  
amiga

-  
<LAlt>-<LAmiga>-<F10>

-  
atari

-  
<Alt>-<LeftShift>-<F9>

-  
evbarm

-  
<Ctrl>-<Alt>-<Esc> on PC style keyboards.

-  

-  
<Break> on serial console.

-  

-  
Some models: +++++ (five plus signs) on serial console.

-  
hp300

-  
<Shift>-<Reset>

-  
hpcarm

-  
<Ctrl>-<Alt>-<Esc>

-  
hpcmips

-  
<Ctrl>-<Alt>-<Esc>

-  
hpcsh

-  
<Ctrl>-<Alt>-<Esc>

-  
hppa

-  
<Ctrl>-<Alt>-<Esc> on PC style keyboards.

-  

-  
+++++ (five plus signs) on PDC console

-  

-  
<Break> on serial console.

-  
i386

-  
<Ctrl>-<Alt>-<Esc>

-  

-  
<Break> on serial console.

-  
mac68k

-  
<Command>-<Power>, or the Interrupt switch.

-  
macppc

-  
Some models: <Command>-<Option>-<Power>

-  
mvme68k

-  
Abort switch on CPU card.

-  
pmax

-  
<Do> on LK-201 rcons console.

-  

-  
<Break> on serial console.

-  
sandpoint

-  
<Break> on serial console.

-  
sparc

-  
<L1>-A, or <Stop>-A on a Sun keyboard.

-  

-  
<Break> on serial console.

-  
sparc64

-  
<L1>-A, or <Stop>-A on a Sun keyboard.

-  

-  
<Break> on serial console.

-  
sun3

-  
<L1>-A, or <Stop>-A on a Sun keyboard.

-  

-  
<Break> on serial console.

-  
vax

-  
<Esc> followed by <Shift>-D on serial console.

-  
x68k

-  
Interrupt switch on the body.

-  
xen dom0

-  
<Ctrl>-<Alt>-<Esc> on PC style keyboards.

-  

-  
+++++ (five plus signs) on serial console.

-  
xen domU

-  
+++++ (five plus signs) on serial console.

-  
zaurus

-  
<Ctrl>-<Alt>-<Esc>

-

-

-
The key sequence to activate ddb can be
-    changed by modifying “hw.cnmagic” with
-    sysctl(8). If the console is not dedicated to
-    ddb the sequence should not be easily typed by
-    accident. In addition, ddb may be explicitly
-    activated by the debugging code in the kernel if DDB
-    is configured.

-
Commands can be automatically run when ddb
-    is entered by using options DDB_COMMANDONENTER or by
-    setting ddb.commandonenter with
-    sysctl(8). Multiple commands can be separated by a
-    semi-colon.

-

-

-

-
The general command syntax is:

-
command[/modifiers]
-  address[,count]

-
The current memory location being edited is referred to as
-    dot, and the next location is
-    next. They are displayed as hexadecimal numbers.

-
Commands that examine and/or modify memory update
-    dot to the address of the last line examined or the
-    last location modified, and set next to the next
-    location to be examined or modified. Other commands don't change
-    dot, and set next to be the same
-    as dot.

-
A blank line repeats the previous command from the address
-    next with the previous count
-    and no modifiers. Specifying address sets
-    dot to the address. If address is
-    omitted, dot is used. A missing
-    count is taken to be 1 for printing commands, and
-    infinity for stack traces.

-
The syntax:

-
,count

-
repeats the previous command, just as a blank line does, but with
-    the specified count.

-
ddb has a more(1)-like
-    functionality; if a number of lines in a command's output exceeds the number
-    defined in the lines variable, then
-    ddb displays “--db more--” and waits
-    for a response, which may be one of:

-

-

-  
⟨return⟩

-  
one more line.

-  
⟨space⟩

-  
one more page.

-  

-  
abort the current command, and return to the command input mode.

-

-

-
You can set lines variable to zero to
-    disable this feature.

-
If ddb history editing is enabled (by
-    defining the

-
options
-  DDB_HISTORY_SIZE=num

-kernel option), then a history of the last num commands
-  is kept. The history can be manipulated with the following key sequences:
-

-

-  
<Ctrl>-P

-  
retrieve previous command in history (if any).

-  
<Ctrl>-N

-  
retrieve next command in history (if any).

-

-

-

-

-

-
ddb supports the following commands:

-

-  
address[(expression[,...])]

-  
A synonym for call.

-  
[/u]
-    address[,count]

-  
Set a breakpoint at address. If
-      count is supplied, continues
-      (count-1) times before stopping at the breakpoint.
-      If the breakpoint is set, a breakpoint number is printed with
-      ‘#’. This number can be used to
-      delete the breakpoint, or to add conditions to it.
-    
If /u is specified, set a breakpoint
-        at a user-space address. Without /u,
-        address is considered to be in the kernel-space,
-        and an address in the wrong space will be rejected, and an error message
-        will be emitted. This modifier may only be used if it is supported by
-        machine dependent routines.

-    
Warning: if a user text is shadowed by a normal user-space
-        debugger, user-space breakpoints may not work correctly. Setting a
-        breakpoint at the low-level code paths may also cause strange
-      behavior.

-  

-  
[/ul]
-    [frame-address][,count]

-  
A synonym for trace.

-  
[/ul]
-    [pid][,count]

-  
A synonym for trace/t.

-  
[/ul]
-    [lwpaddr][,count]

-  
A synonym for trace/a.

-  

-    address[(expression[,...])]

-  
Call the function specified by address with the
-      argument(s) listed in parentheses. Parentheses may be omitted if the
-      function takes no arguments. The number of arguments is currently limited
-      to 10.

-  
[/c]

-  
Continue execution until a breakpoint or watchpoint. If
-      /c is specified, count instructions while
-      executing. Some machines (e.g., pmax) also count loads and stores.
-    
Warning: when counting, the debugger is really silently
-        single-stepping. This means that single-stepping on low-level may cause
-        strange behavior.

-  

-  

-    address |
-    number

-  
Delete a breakpoint. The target breakpoint may be specified by
-      address, as per break, or by
-      the breakpoint number returned by break if it's
-      prefixed with ‘#’.

-  

-    [count]

-  
Prints the contents of the kernel message buffer. The optional
-      count argument will limit printing to at most the
-      last count bytes of the message buffer.

-  

-    address

-  
Delete the watchpoint at address that was previously
-      set with watch command.

-  
[/modifier]
-    address[,count]

-  
Display the address locations according to the format in
-      modifier. Multiple modifier formats display multiple
-      locations. If modifier isn't specified, the modifier
-      from the last use of examine is used.
-    
The valid format characters for modifier
-        are:

-    

-    

-      

-      
examine bytes (8 bits).

-      

-      
examine half-words (16 bits).

-      

-      
examine words (legacy “long”, 32 bits).

-      

-      
examine quad-words (64 bits).

-      

-      
examine long words (implementation dependent)

-      

-      
print the location being examined.

-      

-      
print the location with a line number if possible.

-      

-      
display in unsigned hex.

-      

-      
display in signed hex.

-      

-      
display in unsigned octal.

-      

-      
display in signed decimal.

-      

-      
display in unsigned decimal.

-      

-      
display in current radix, signed.

-      

-      
display low 8 bits as a character. Non-printing characters as
-          displayed as an octal escape code (e.g., ‘\000’).

-      

-      
display the NUL terminated string at the location. Non-printing
-          characters are displayed as octal escapes.

-      

-      
display in unsigned hex with a character dump at the end of each line.
-          The location is displayed as hex at the beginning of each line.

-      

-      
display as a pointer and it's symbol if possible.

-      

-      
display as a machine instruction.

-      

-      
display as a machine instruction, with possible alternative formats
-          depending upon the machine:
-        

-        

-          
m68k

-          
use Motorola syntax

-          
vax

-          
don't assume that each external label is a procedure entry
-            mask

-        

-        

-      

-    

-    

-  

-  

-    pid[,signal_number]

-  
Send a signal to the process specified by the pid.
-      Note that pid is interpreted using the current radix
-      (see trace/t command for details). If
-      signal_number isn't specified, the SIGTERM signal is
-      sent.

-  
[/p]

-  
A synonym for next.

-  
[/p]

-  
Stop at the matching return instruction. If /p is
-      specified, print the call nesting depth and the cumulative instruction
-      count at each call or return. Otherwise, only print when the matching
-      return is hit.

-  
[/axzodurc]
-    address [address ...]

-  
Print addresses address according to the modifier
-      character, as per examine. Valid modifiers are:
-      /a, /x,
-      /z, /o,
-      /d, /u,
-      /r, and /c (as per
-      examine). If no modifier is specified, the most
-      recent one specified is used. address may be a
-      string, and is printed “as-is”. For example:
-    

-    
print/x "eax = " $eax "\necx = " $ecx "\n"

-    

-    
will produce:

-    

-    
eax = xxxxxx
-ecx = yyyyyy

-    

-  

-  
[/a][/n][/w][/l][/L]

-  
A synonym for show all procs.

-  

-    [flags]

-  
Reboot, using the optionally supplied boot flags,
-      which is a bitmask supporting the same values as for
-      reboot(2). Some of the more useful flags:
-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
0x1RB_ASKNAMEAsk for file name to reboot from
0x2RB_SINGLEReboot to single user mode
0x4RB_NOSYNCDon't sync before reboot
0x8RB_HALTHalt instead of reboot
0x40RB_KDBBoot into kernel debugger
0x100RB_DUMPDump unconditionally before reboot
0x808RB_POWERDOWNPower off (or at least halt)

-    
Note: Limitations of the command line interface preclude
-        specification of a boot string.

-  

-  
-  
Search memory from address for
-      value. The unit size is specified with a modifier
-      character, as per examine. Valid modifiers are:
-      /b, /h, and
-      /l. If no modifier is specified,
-      /l is used.
-    
This command might fail in interesting ways if it doesn't find
-        value. This is because ddb
-        doesn't always recover from touching bad memory. The optional
-        count limits the search.

-  

-  

-    $variable
-    [=] expression

-  
Set the named variable or register to the value of
-      expression. Valid variable names are described in
-      VARIABLES.

-  

-  
Display information about callouts in the system. See
-      callout(9) for more information on callouts.

-  
[/t]

-  
Display details information about all active locks. If
-      /t is specified, stack traces of LWPs holding
-      locks are also printed. This command is only useful if a kernel is
-      compiled with options LOCKDEBUG.

-  
[/f]

-  
Display all mount points. If /f is specified, the
-      complete vnode list is printed.

-  

-  
Display basic information about all physical pages managed by the VM
-      system. For more detailed information about a single page, use
-      show page.

-  
[/clpsS]

-  
Display all pool information. Modifiers are the same as
-      show pool.

-  
[/a][/n][/w][/l][/L]

-  
Display all process information. Valid modifiers:
-    

-      

-      
show process information in a ps(1) style format.
-          Information printed includes: process ID, parent process ID, process
-          group, UID, process status, process flags, number of LWPs, command
-          name, and process wait channel message.

-      

-      
show each process ID, command name, kernel virtual addresses of each
-          process' proc structure, u-area, and vmspace structure. The vmspace
-          address is also the address of the process' vm_map structure, and can
-          be used in the show map command.

-      

-      
show each LWP ID, process ID, command name, system call emulation,
-          priority, wait channel message and wait channel address. LWPs
-          currently running on a CPU are marked with the '>' sign.

-      

-      
show each LWP ID, process ID, process status, CPU ID the LWP runs on,
-          process flags, kernel virtual address of LWP structure, LWP name and
-          wait channel message. LWPs currently running on a CPU are marked with
-          the '>' sign. This is the default.

-      

-      
In addition to what /l shows, print the stack
-          trace of each LWPs.

-    

-  

-  
[/t]

-  
Display all lwps that are currently waiting in turnstiles to acquire
-      locks, which locks they are waiting for, and who currently holds them.
-      Valid modifiers:
-    

-      

-      
show a stack trace of the lwp that currently holds each lock

-    

-  

-  

-  
Dump the entire AF_INET routing table. This
-      command is available only on systems which support inet.

-  

-  
Display all breakpoints.

-  
[/f]
-    address

-  
Print the struct buf at address. The
-      /f does nothing at this time.

-  
[/f][/i][/m][/t]

-  
Print all the non-zero evcnt(9) event counters. Valid
-      modifiers:
-    

-      

-      
event counters with a count of zero are printed as well.

-      

-      
interrupted counters will be displayed.

-      

-      
misc counters will be displayed.

-      

-      
trap counters will be displayed.

-    

-    
If none of /i,
-        /m, or /t are specified,
-        all are shown. You can combine any of these. For example, the modifier
-        /itf will select both interrupt and trap events,
-        including those that are non-zero.

-  

-  
 address

-  
Display information about the vnodes of the files that are currently open
-      by the process associated with the proc structure at
-      address. This address can be found using the
-      show all procs /a command. If the kernel is
-      compiled with options LOCKDEBUG then details about
-      the locking of the underlying uvm object will also be displayed.

-  
 address

-  
Display information about a lock at address. This
-      command is only useful if a kernel is compiled with
-      options LOCKDEBUG.

-  

-  
Display information about lock statistics. This command is only useful if
-      a kernel is compiled with options LOCKDEBUG.

-  
[/f]
-    address

-  
Print the vm_map at address. If
-      /f is specified, the complete map is printed.

-  
[/f]
-    address

-  
Print the mount structure at address. If
-      /f is specified, the complete vnode list is
-      printed.

-  
[/cdv]
-    address

-  
Print the mbuf structure at address. Valid
-      modifiers:
-    

-      

-      
The mbufs in the chain are NOT followed.

-      

-      
The data is dumped.

-      

-      
Decode the mbuf chain as a packet. It currently supports Ethernet,
-          PPP, PPPoE, ARP, IPv4, ICMP, IPv6, ICMP6, TCP and UDP.

-    

-  

-  
 address

-  
Dump the namecache list associated with vnode at
-      address.

-  
[/f]
-    address

-  
Print the vm_object at address. If
-      /f is specified, the complete object is
-    printed.

-  
[/f]
-    address

-  
Print the vm_page at address. If
-      /f is specified, the complete page is
-    printed.

-  

-  
Print the current "panic" string.

-  
[/clpsS]
-    address

-  
Print the pool at address. Valid modifiers:
-    

-      

-      
Print the cachelist and its statistics for this pool.

-      

-      
Print the log entries for this pool.

-      

-      
Print the pagelist for this pool.

-      

-      
Print a short (one line) list per pool, showing the wait channel, pool
-          address, allocation size, alignment, allocated pages, allocated items,
-          consumed items, allocation requests, allocation frees, pages
-          allocated, pages freed, and currently idle pages, respectively.

-      

-      
Skip pools with zero allocations.

-    

-  

-  
[/ap] address |
-    pid

-  
Show information about a process and its LWPs. LWPs currently running on a
-      CPU are marked with the '>' sign.
-    

-      

-      
The argument passed is the kernel virtual address of LWP
-        structure.

-      

-      
The argument passed is a PID. Note that pid is
-          interpreted using the current radix (see
-          trace/t command for details). This is the
-          default.

-    

-  

-  
[/u]

-  
Display the register set. If /u is specified,
-      display user registers instead of kernel registers or the currently save
-      one.
-    
Warning: support for /u is machine
-        dependent. If not supported, incorrect information will be
-      displayed.

-  

-  

-  
Print the state of the scheduler's run queues. For each run queue that has
-      an LWP, the run queue index and the list of LWPs will be shown. If the run
-      queue has LWPs, but the sched_whichqs bit is not set for that queue, the
-      queue index will be prefixed with a ‘!’.

-  
[/ampv]

-  
Print usage of system's socket buffers. By default, empty sockets aren't
-      printed.
-    

-      

-      
Print all processes which use the socket.

-      

-      
Print mbuf chain in the socket buffer.

-      

-      
By default, a process which uses the socket is printed (only one
-          socket). If /p is specified, the process isn't
-          printed.

-      

-      
Verbose mode. If /v is specified, all sockets
-          are printed.

-    

-  

-  

-  
Print a selection of UVM counters and statistics.

-  
[/i]
-    [address[,count]]

-  
Dumps all the kernel histories if no address is specified, or the history
-      at the address. If /i is specified, display
-      information about the named history or all histories, instead of history
-      entries. If count is specified, only the last
-      count entries will be displayed. Currently the
-      count handling is only performed if a single history
-      is requested. This command is available only if a kernel is compiled with
-      one or more of the kernel history options
-      KERNHIST, SYSCALL_DEBUG,
-      USB_DEBUG, BIOHIST, or
-      UVMHIST.

-  
 address

-  
Print the vmem at address.

-  

-  
Display all vmems.

-  
[/f]
-    address

-  
Print the vnode at address. If
-      /f is specified, the complete vnode is
-    printed.

-  
[/f]
-    address

-  
Print the vnode which has its lock at address. If
-      /f is specified, the complete vnode is
-    printed.

-  

-  
Display all watchpoints.

-  
[/F]
-    string

-  
Search the symbol tables for all symbols of which
-      string is a substring, and display them. If
-      /F is specified, a character is displayed
-      immediately after each symbol name indicating the type of symbol.
-    
Object symbols display +,
-        function symbols display *, section symbols display
-        , and file
-        symbols display
-        .

-    
To sift for a string beginning with a number, escape the first
-        character with a backslash as:

-    

-    
sifting \386

-    

-  

-  
[/p]
-    [,count]

-  
Single-step count times. If
-      /p is specified, print each instruction at each
-      step. Otherwise, only print the last instruction.
-    
Warning: depending on the machine type, it may not be possible
-        to single-step through some low-level code paths or user-space code. On
-        machines with software-emulated single-stepping (e.g., pmax), stepping
-        through code executed by interrupt handlers will probably do the wrong
-        thing.

-  

-  

-  
Sync the disks, force a crash dump, and then reboot.

-  
[/u[l]]
-    [frame-address][,count]

-  
Stack trace from frame-address. If
-      /u is specified, trace user-space, otherwise trace
-      kernel-space. count is the number of frames to be
-      traced. If count is omitted, all frames are printed.
-      If /l is specified, the trace is printed and also
-      stored in the kernel message buffer.
-    
Warning: user-space stack trace is valid only if the machine
-        dependent code supports it.

-  

-  
[l]
-    [pid][,count]

-  
Stack trace by “thread” (process, on
-      NetBSD) rather than by stack frame address. Note
-      that pid is interpreted using the current radix,
-      whilst ps displays pids in decimal; prefix
-      pid with ‘0t’ to force it to be
-      interpreted as decimal (see VARIABLES
-      section for radix). If /l is specified, the trace
-      is printed and also stored in the kernel message buffer.
-    
Warning: trace by pid is valid only if the machine dependent
-        code supports it.

-  

-  
[l]
-    [lwpaddr][,count]

-  
Stack trace by light weight process (LWP) address rather than by stack
-      frame address. If /l is specified, the trace is
-      printed and also stored in the kernel message buffer.
-    
Warning: trace by LWP address is valid only if the machine
-        dependent code supports it.

-  

-  
[/p]

-  
Stop at the next call or return instruction. If /p
-      is specified, print the call nesting depth and the cumulative instruction
-      count at each call or return. Otherwise, only print when the matching
-      return is hit.

-  

-    address[,size]

-  
Set a watchpoint for a region. Execution stops when an attempt to modify
-      the region occurs. size defaults to 4.
-    
If you specify a wrong space address, the request is rejected
-        with an error message.

-    
Warning: attempts to watch wired kernel memory may cause an
-        unrecoverable error in some systems such as i386. Watchpoints on user
-        addresses work the best.

-  

-  

-    address

-  
Describe what an address is.

-  
[/bhlqBHLQ]
-    address expression
-    [expression ...]

-  
Write the expressions at succeeding locations. The
-      unit size is specified with a modifier character, as per
-      examine. Valid modifiers are:
-      /b, /h,
-      /l, and /q. If no modifier
-      is specified, /l is used.
-    
Specifying the modifiers in upper case,
-        /B, /H,
-        /L, /Q, will prevent
-        ddb from reading the memory location first,
-        which is useful for avoiding side effects when writing to I/O memory
-        regions.

-    
Warning: since there is no delimiter between
-        expressions, strange things may occur. It's best
-        to enclose each expression in parentheses.

-  

-  
[/modifier]
-    address[,count]

-  
A synonym for examine.

-

-

-

-

-
The "glue" code that hooks ddb
-    into the NetBSD kernel for any given port can also
-    add machine specific commands to the ddb command
-    parser. All of these commands are preceded by the command word
-    
-    to indicate that they are part of the machine-specific command set (e.g.
-    machine reboot). Some of these commands are:

-

-

-

-  

-  
Set or clear a hardware breakpoint.

-  

-  
Switch to another CPU.

-  

-  
Print CPU information about the ``struct cpuinfo''.

-  

-  
Given a trap frame address, print out the trap frame.

-  

-  
Print lwp information about the ``struct lwp''.

-  

-  
Print PTE information.

-  

-  
Reset the system.

-  

-  
Print system registers.

-  

-  
Set or clear a hardware watchpoint. Pass the address to be watched, or
-      watchpoint number to clear the watchpoint. Optional modifiers are
-      “r” for read access, “w” for write access
-      (default: trap on read or write access), “b” for 8 bit
-      width, “h” for 16 bit, “l” for 32 bit or,
-      “q” for 64 bit (default: 32 bit).

-

-

-

-

-

-  

-  
Switch to another CPU.

-

-

-

-

-

-  

-  
Switch to another CPU.

-

-

-

-

-

-  

-  
Given a trap frame address, print out the trap frame.

-  

-  
Reset the system.

-

-

-

-

-

-  

-  
Without an address the default trap frame is printed. Otherwise, the trap
-      frame address can be given, or, when the “l” modifier is
-      used, an LWP address.

-

-

-

-

-

-  

-  
Switch to another CPU.

-

-

-

-

-

-  

-  
Without a vector, information about all 256 vectors is shown. Otherwise,
-      the given vector is shown.

-

-

-

-

-

-  

-  
Dump CP0 (coprocessor 0) register values.

-  

-  
Switch to another CPU.

-  

-  
Print the physical address for a given kernel virtual address.

-  

-  
Send an NMI to a different CPU. This DDB command is currently only
-      implemented for Cavium Octeon CPUs.

-  

-  
Reset the system. Not implemented for many CPUs and/or systems.

-  

-  
Print out the Translation Lookaside Buffer (TLB). Use the
-      /v modifier to show only valid TLB entries.

-  

-  
Set a hardware watchpoint on an address or a TLB ASID. Pass the address to
-      be watched. If no address is specified, show a list of active watchpoints.
-      The modifiers are /m i for trap on an instruction
-      fetch, /r for trap on a read,
-      /w for trap on a write, /m
-      for a mask on the address to match, /a for trap on
-      a TLB ASID match. The /m and
-      /a modifiers require an extra argument for the
-      mask and ASID respectively.

-  

-  
Clear a hardware watchpoint. If an address is specified, clear watchpoints
-      that match that address. If no address is specified, clear all
-      watchpoints.

-

-

-

-

-

-  

-  
Print process MMU context information.

-  

-  
Print PA->VA mapping information.

-  

-  
Reset the system.

-  

-  
Display the contents of the trapframe.

-  

-  
Display instruction translation storage buffer information.

-  

-  
Set the DCR register. Must be between 0x00 and 0x3ff.

-  

-  
Display user memory. Use the “i” modifier to get instruction
-      decoding.

-

-

-

-

-

-  

-  
Print BAT registers and translations.

-  

-  
Print MMU registers.

-

-

-

-

-

-  

-  
Print TLB entries.

-  

-  
Print cache entries.

-  

-  
Print switch frame and trap frames.

-  

-  
Print kernel stack usage. Only works in NetBSD
-      kernels compiled with the KSTACK_DEBUG
-    option.

-

-

-

-

-

-  

-  
Switch to another CPU.

-  

-  
Enter the Sun PROM monitor.

-  

-  
Display some information about the LWP pointed to, or curlwp.

-  

-  
Display information about the “struct pcb” listed.

-  

-  
Display the pointer to the “struct vm_page” for this
-      physical address.

-

-

-

-

-

-  

-  
Print process context information.

-  

-  
Switch to another CPU.

-  

-  
Print data translation look-aside buffer context information.

-  

-  
Display data translation storage buffer information.

-  

-  
Display information about the listed mapping in the kernel pmap. Use the
-      “f” modifier to get a full listing.

-  

-  
Extract the physical address for a given virtual address from the kernel
-      pmap.

-  

-  
Dump the FPU state.

-  

-  
Print instruction translation look-aside buffer context information.

-  

-  
Display instruction translation storage buffer information.

-  

-  
Display a struct lwp

-  

-  
Display information about the “struct pcb” listed.

-  

-  
Attempt to change process context.

-  

-  
Display the pointer to the “struct vm_page” for this
-      physical address.

-  

-  
Display physical memory.

-  

-  
Display the pmap. Use the “f” modifier to get a fuller
-      listing.

-  

-  
Display some information about the process pointed to, or curproc.

-  

-  
Enter the OFW PROM.

-  

-  
Display the “struct pv_entry” pointed to.

-  

-  
Reset the machine and enter prom (do a Software Initiated Reset).

-  

-  
Dump the window stack. Use the “u” modifier to get userland
-      information.

-  

-  
Display full trap frame state. This is most useful for inclusion with bug
-      reports.

-  

-  
Display trap state.

-  

-  
Display or set trap trace information. Use the “r” and
-      “f” modifiers to get reversed and full information,
-      respectively.

-  

-  
Set or clear a physical or virtual hardware watchpoint. Pass the address
-      to be watched, or “0” (or omit the address) to clear the
-      watchpoint. Optional modifiers are “p” for physical address,
-      “r” for trap on read access (default: trap on write access
-      only), “b” for 8 bit width, “h” for 16 bit,
-      “l” for 32 bit or “L” for 64 bit.

-  

-  
Print register window information. Argument is a stack frame number (0 is
-      top of stack, which is used when no index is given).

-

-

-

-

-

-  

-  
Drop into monitor via abort (allows continue).

-  

-  
Exit to Sun PROM monitor as in halt(8).

-  

-  
Reboot the machine as in reboot(8).

-  

-  
Given an address, print the address, segment map, page map, and Page Table
-      Entry (PTE).

-

-

-

-

-

-  

-  
Switch to another CPU.

-

-

-

-

-

-
ddb accesses registers and variables as
-    $name. Register names are as
-    per the show registers command. Some variables are
-    suffixed with numbers, and may have a modifier following a colon immediately
-    after the variable name. For example, register variables may have a
-    ‘u’ modifier to indicate user register (e.g.,
-    $eax:u).

-
Built-in variables currently supported are:

-

-

-  
dumpstack

-  
If non-zero (the default), causes a stack trace to be printed when
-      ddb is entered on panic.

-  
fromconsole

-  
If non-zero (the default), the kernel allows to enter
-      ddb from the console (by break signal or special
-      key sequence). If the kernel configuration option
-    
options
-      DDB_FROMCONSOLE=0

-    is used, fromconsole will be initialized to off.

-  
lines

-  
The number of lines. This is used by the more
-      feature. When this variable is set to zero the
-      more feature is disabled.

-  
maxoff

-  
Addresses are printed as 'symbol'+offset unless
-      offset is greater than
-      maxoff.

-  
maxwidth

-  
The width of the displayed line. ddb wraps the
-      current line by printing new line when maxwidth
-      column is reached. When this variable is set to zero
-      ddb doesn't perform any wrapping.

-  
onpanic

-  
If greater than zero (the default is 1), ddb will
-      be invoked when the kernel panics. If the kernel configuration option
-    
options
-      DDB_ONPANIC=0

-    is used, onpanic will be initialized to off, causing a
-      stack trace to be printed and the system to be rebooted instead of
-      ddb being entered. Setting
-      onpanic to -1 suppresses the stack trace before
-      reboot.

-  
radix

-  
Input and output radix.

-  
tabstops

-  
Tab stop width.

-  
tee_msgbuf

-  
If explicitly set to non zero (zero is the default) all
-      ddb output will not only be displayed on screen
-      but also be fed to the msgbuf. The default of the variable can be set
-      using the kernel configuration option
-    
options
-      DDB_TEE_MSGBUF=1

-    which will initialize tee_msgbuf to be 1. This option
-      is especially handy for poor souls who don't have a serial console but
-      want to recall ddb output from a crash
-      investigation. This option is more generic than the /l command modifier
-      possible for selected commands as discussed above to log the output.
-      Mixing both /l and this setting can give double loggings.

-  
panicstackframes

-  
Number of stack frames to display on panic. Useful to avoid scrolling away
-      the interesting frames on a glass tty. Default value is
-      65535 (all frames), useful value around
-      10.

-

-

-
All built-in variables are accessible via
-    sysctl(3).

-

-

-

-
Almost all expression operators in C are supported, except
-    ‘~’, ‘^’, and unary ‘&’.
-    Special rules in ddb are:

-

-

-  
identifier

-  
name of a symbol. It is translated to the address (or value) of it.
-      ‘.’ and ‘:’ can be used in the identifier. If
-      supported by an object format dependent routine,
-      [filename:]function[:line number],
-      [filename:]variable, and
-      filename[:line number], can be
-      accepted as a symbol. The symbol may be prefixed with
-      symbol_table_name:: (e.g.,
-      emulator::mach_msg_trap) to specify other than
-      kernel symbols.

-  
number

-  
number. Radix is determined by the first two characters:
-      ‘0x’ - hex, ‘0o’ - octal, ‘0t’ -
-      decimal, otherwise follow current radix.

-  

-  
dot

-  

-  
next

-  

-  
address of the start of the last line examined. Unlike
-      dot or next, this is only
-      changed by the examine or
-      write commands.

-  

-  
last address explicitly specified.

-  
name

-  
register name or variable. It is translated to the value of it. It may be
-      followed by a ‘:’ and modifiers as described above.

-  

-  
a binary operator which rounds up the left hand side to the next multiple
-      of right hand side.

-  
expr

-  
expression indirection. It may be followed by a ‘:’ and
-      modifiers as described above.

-

-

-

-

-

-
reboot(2), options(4),
-    crash(8), reboot(8),
-    sysctl(8), cnmagic(9),
-    ddb(9)

-

-

-

-
The ddb kernel debugger was written as
-    part of the MACH project at Carnegie-Mellon University.

-

-

-
-  
-    
-    
-  
-
March 15, 2026NetBSD 10.1

diff --git a/static/netbsd/man4/ddc.4 4.html b/static/netbsd/man4/ddc.4 4.html
deleted file mode 100644
index 5f6f8771..00000000
--- a/static/netbsd/man4/ddc.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
DDC(4)Device Drivers ManualDDC(4)

-

-

-

-
ddc — VESA Display
-    Data Channel V2 devices

-

-

-

-
ddc at iic? addr 0x50

-

-

-

-
The ddc driver provides support for
-    accessing the VESA Display Data Channel Version 2 supported by many video
-    displays.

-

-

-

-
iic(4), ddc(9),
-    edid(9)

-

-

-

-
The ddc device appeared in
-    NetBSD 4.0.

-

-

-

-
Garrett D'Amore
-    <gdamore@NetBSD.org>

-

-

-

-
This driver does not provide any mechanism for access from user
-    applications. Its only use at this point is to provide a means for
-    framebuffer device drivers to query monitor description data (EDID) using a
-    specialized in-kernel API. No support for sending control commands to
-    display devices is provided.

-

-

-
-  
-    
-    
-  
-
May 11, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/dge.4 3.html b/static/netbsd/man4/dge.4 3.html
deleted file mode 100644
index 5ba6f342..00000000
--- a/static/netbsd/man4/dge.4 3.html	
+++ /dev/null
@@ -1,126 +0,0 @@
-
-  
-    
-    
-    
-  
-
DGE(4)Device Drivers ManualDGE(4)

-

-

-

-
dge — Intel
-    i82597EX Ten Gigabit Ethernet driver

-

-

-

-
dge* at pci? dev ? function ?

-

-

-

-
The dge device driver supports the Intel
-    i82597EX PRO/10GbE LR Ethernet adapter, which uses a single mode fiber
-    (1310nm) interface.

-
The i82597EX supports IPv4/TCP/UDP checksumming in hardware, as
-    well as TCP Segmentation Offloading (TSO). The driver does currently only
-    support the hardware checksumming features. See
-    ifconfig(8) for information on how to enable the hardware
-    checksum calculations.

-
The driver also makes use of the ifconfig(8)
-    link flags link0 and link1 to
-    set the PCIX burst size. The burst size is set according to this table:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
link1burst size
off512
off1024
on2048
on4096

-
A larger burst size will increase the transmit capacity of the
-    card dramatically but may have negative effect on other devices in the
-    system.

-

-

-

-

-  
dge%d: Tx packet consumes too many DMA segments, dropping...

-  
The packet consisted of too many small mbufs and could therefore not be
-      loaded into a DMA map. This is most unlikely, the driver can currently
-      handle up to 100 segments, but over 80 segments has been seen using large
-      (16k) jumbo frames.

-  
dge%s: device timeout (txfree %d txsfree %d txnext %d)

-  
The i82597EX had been given packets to send, but didn't interrupt within 5
-      seconds. This diagnostic is most likely the result of a hardware failure,
-      and the chip will be reset to resume normal operation.

-  
dge%d: Receive overrun

-  
If the computer is under heavy load, the software may not be able to keep
-      up removing received datagrams from the receive queue, and will therefore
-      lose datagrams. To avoid this, check that the other end is using the
-      XON/XOFF protocol, if possible, or increase the receive descriptor ring
-      size in the driver.

-  
dge%d: symbol error

-  

-  
dge%d: parity error

-  
An error in the XGMII communication was detected. This is a hardware error
-      in the MAC<->PHY communication bus.

-  
dge%d: CRC error

-  
A CRC error in the received datagram was detected. The error is probably
-      caused in the fiber communication.

-  
dge%d: WARNING: reset failed to complete

-  
This is a fatal error and means that the hardware is broken and will most
-      likely not function correctly.

-  
dge%d: unable to allocate or map rx buffer %d error = %d

-  
The driver was not able to map a mbuf cluster page to a receive descriptor
-      entry in the receive ring. Most likely the system has run out of mbuf
-      clusters or have a too small cluster map. See the errno for more
-      information.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The dge driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The dge driver was written by
-    Anders Magnusson
-    <ragge@ludd.luth.se>.

-

-

-

-
There should be an XGMII framework for the driver to use.

-

-

-
-  
-    
-    
-  
-
March 18, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/dk.4 3.html b/static/netbsd/man4/dk.4 3.html
deleted file mode 100644
index 06b93fec..00000000
--- a/static/netbsd/man4/dk.4 3.html	
+++ /dev/null
@@ -1,135 +0,0 @@
-
-  
-    
-    
-    
-  
-
DK(4)Device Drivers ManualDK(4)

-

-

-

-
dk — disk
-    partition (wedge) driver

-

-

-

-
options DKWEDGE_AUTODISCOVER
-  

-  options DKWEDGE_METHOD_APPLE
-  

-  options DKWEDGE_METHOD_BSDLABEL
-  

-  options DKWEDGE_METHOD_GPT
-  

-  options DKWEDGE_METHOD_MBR
-  

-  options DKWEDGE_METHOD_RDB
-  

-  options DKWEDGE_METHOD_TOS

-

-

-

-
The dk driver provides a disk-like
-    interface, or
-    ,
-    to an area of a physical disk. Wedges may be configured manually with
-    dkctl(8) or automatically by the kernel upon the
-    attachment of the physical disk.

-
Wedges need to have unique names. If a duplicate name is detected
-    during auto-discovery, that partition is ignored.

-

-

-

-

-  

-  
Automatically detect and configure wedges using any available methods. For
-      each partition found, a wedge with a corresponding name is created.
-    
Currently only DKWEDGE_METHOD_GPT and
-        DKWEDGE_METHOD_APPLE are enabled by default.

-  

-  

-  
Apple partition map detection method.

-  

-  
BSD disklabel detection method. For each configured partition in the
-      disklabel(5) that is not of type
-      FS_UNUSED, a wedge is created and named after the
-      d_packname field followed by
-      ‘/’ and the partition letter
-      ‘a’..‘p’.
-    
When the d_packname is empty or has the
-        value ‘fictitious’, the regular
-        partition names are used as wedge names, i.e. the device name, unit
-        number and partition letter, for example
-        ‘wd0a’.

-  

-  

-  
Extensible Firmware Interface Globally Unique Identifier Partition Table
-      (GPT) detection method.
-    
For every GPT partition a wedge is created and named after the
-        partition label. GPT partitions are UTF-16–encoded, this is
-        converted into UTF-8. If a partition has no label, its UUID is used
-        instead.

-  

-  

-  
IBM PC-compatible Master Boot Record (MBR) partitioning detection method,
-      with support for Extended MBRs.
-    
For every partition in the MBR a wedge is created and named
-        like a regular partition name, i.e. the device name, unit number and a
-        partition letter, for example
-        ‘wd0e’. Primary partitions start
-        with ‘e’, extended partitions
-        start with ‘i’.

-  

-  

-  
Amiga Rigid Disk Block (RDB) partitioning detection method.

-  

-  
Atari's TOS partition map detection method, for disks that conform to
-      Atari's AHDI specification.
-    
For each partition, a wedge is created with a name of the
-        format
-        ATARI_{type}_{number}
-        where type may either be
-        ‘GEM’ or
-        ‘BGM’. The number 0 partition
-        typically corresponds to the ‘C:’
-        drive when read on an actual Atari, the next to
-        ‘D:’ and so on. Extended
-        partitions (those of type ‘XGM’)
-        are not currently supported.

-  

-

-

-

-

-

-  
/dev/dk*

-  
Block mode dk device special files.

-  
/dev/rdk*

-  
Raw mode dk device special files.

-

-

-

-

-
config(1), disklabel(8),
-    dkctl(8), fdisk(8),
-    gpt(8), MAKEDEV(8)

-

-

-

-
The dk driver first appeared in
-    NetBSD 3.0.

-

-

-

-
The dk driver was written by
-    Jason R. Thorpe.

-

-

-
-  
-    
-    
-  
-
April 2, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/dm.4 3.html b/static/netbsd/man4/dm.4 3.html
deleted file mode 100644
index e727a19c..00000000
--- a/static/netbsd/man4/dm.4 3.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
DM(4)Device Drivers ManualDM(4)

-

-

-

-
dm — Device-mapper
-    disk driver

-

-

-

-
pseudo-device dm

-

-

-

-
The dm driver provides the capability of
-    creating one or more virtual disks based on the target mapping.

-
This document assumes that you're familiar with how to generate
-    kernels, how to properly configure disks and pseudo-devices in a kernel
-    configuration file, and how to partition disks. This driver is used by the
-    Linux lvm2tools to create and manage lvm in
-  NetBSD.

-
Currently, the linear,
-    zero, and error targets are
-    implemented. Each component partition should be offset at least 2 sectors
-    from the beginning of the component disk. This avoids potential conflicts
-    between the component disk's disklabel and dm's
-    disklabel. In i386 it is offset by 65 sectors, where 63 sectors are the
-    initial boot sectors and 2 sectors are used for the disklabel which is set
-    to be read-only.

-
In order to compile in support for dm, you
-    must add a line similar to the following to your kernel configuration
-  file:

-

-
pseudo-device	dm	 #device-mapper disk device

-

-
dm may create linear mapped devices, zero,
-    and error block devices. Zero and error block devices are used mostly for
-    testing. Linear devices are used to create virtual
-    disks with linearly mapped virtual blocks to blocks on real disk.
-    dm Device-mapper devices are controlled through the
-    /dev/mapper/control device. For controlling this
-    device ioctl(2) calls are used. For the implementation of
-    the communication channel, the proplib(3) library is used.
-    The protocol channel is defined as a proplib dictionary with needed values.
-    For more details, look at sys/dev/dm/netbsd-dm.h.
-    Before any device can be used, every device-mapper disk device must be
-    initialized. For initialization one line must be passed to the kernel driver
-    in the form of a proplib dictionary. Every device can have more than one
-    table active. An example for such a line is:

-

-
0 10240 linear /dev/wd1a 384

-

-
The first parameter is the start sector for the table defined with
-    this line, the second is the length in sectors which is described with this
-    table. The third parameter is the target name. All other parts of this line
-    depend on the chosen target.

-
For the linear target, there are two additional parameters: The
-    fourth parameter describes the disk device to which the device-mapper disk
-    is mapped. The fifth parameter is the offset on this disk from the start of
-    the disk/partition.

-

-

-

-
config(1), proplib(3),
-    dmsetup(8), fsck(8),
-    lvm(8), MAKEDEV(8),
-    mount(8), newfs(8)

-

-

-

-
The device-mapper disk driver first appeared in
-    NetBSD 6.0.

-

-

-

-
Adam Hamsik
-    <haad@NetBSD.org>
-    implemented the device-mapper driver for NetBSD.

-

-  

-  Brett Lymn
-    <blymn@NetBSD.org>,
-  

-  Reinoud Zandijk
-    <reinoud@NetBSD.org>,
-    and
-  

-  Bill Stouder-Studenmund
-    <wrstuden@NetBSD.org>
-    provided guidance and answered questions about the
-    NetBSD implementation.

-

-

-

-
This driver is still a work-in-progress — there can be
-    bugs.

-

-

-
-  
-    
-    
-  
-
April 4, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/dmoverio.4 4.html b/static/netbsd/man4/dmoverio.4 4.html
deleted file mode 100644
index aeacc40a..00000000
--- a/static/netbsd/man4/dmoverio.4 4.html	
+++ /dev/null
@@ -1,204 +0,0 @@
-
-  
-    
-    
-    
-  
-
DMOVERIO(4)Device Drivers ManualDMOVERIO(4)

-

-

-

-
dmoverio —
-    hardware-assisted data mover interface

-

-

-

-
pseudo-device dmoverio

-

-  

-  #include
-    <dev/dmover/dmover_io.h>

-

-

-

-
The dmoverio pseudo-device driver provides
-    an interface to hardware-assisted data movers, which the kernel supports
-    using the dmover(9) facility. This can be used to copy
-    data from one location in memory to another, clear a region of memory, fill
-    a region of memory with a pattern, and perform simple operations on multiple
-    regions of memory, such as an XOR, without intervention by the CPU.

-
A dmoverio function always has one output
-    region. A function may have zero or more input regions, or may use an
-    immediate value as an input. For functions which use input regions, the
-    lengths of each input region and the output region must be the same. All
-    dmoverio functions with the same name will have the
-    same number of and type inputs.

-
To use dmoverio, the client must first
-    create a session. This is achieved by performing the following steps:

-
    
-  
  • Create a session handle by opening the
-      /dev/dmoverio device.
    • 
-  
  • Select the dmoverio function using the
-      DMIO_SETFUNC ioctl, which takes the following argument:
-    
    
-    
    #define DMIO_MAX_FUNCNAME     64
-struct dmio_setfunc {
-        char dsf_name[DMIO_MAX_FUNCNAME];
-};
    
-    
    
-    
    If the specified function is not available, the DMIO_SETFUNC
-        ioctl will fail with an error code of ESRCH.
    
-  
    • 
-

-
To submit a request for processing the following steps must be
-    performed:

-
    
-  
  • Fill in a request structure:
-    
    
-    
    typedef struct {
-        struct iovec *dmbuf_iov;
-        u_int dmbuf_iovcnt;
-} dmio_buffer;
-
-struct dmio_usrreq {
-        /* Output buffer. */
-        dmio_buffer req_outbuf;
-
-        /* Input buffer. */
-        union {
-                uint8_t _immediate[8];
-                dmio_buffer *_inbuf;
-        } _req_inbuf_un;
-
-#define req_immediate           _req_inbuf_un._immediate
-#define req_inbuf               _req_inbuf_un._inbuf
-
-        uint32_t req_id;        /* request ID; passed in response */
-};
    
-    
    
-    
    For functions which use an immediate value
-        as an input, the
-        
-        member is used to specify the value. Values smaller than 8 bytes should
-        use the least-significant bytes first. For example, a 32-bit integer
-        would occupy bytes 0, 1, 2, and 3.
    
-    
    For functions which use input regions,
-        
-        should point to an array of dmio_buffer's.
    
-    
    The req_id should be a unique value for each
-        request submitted by the client. It will be passed back unchanged in the
-        response when processing of the request has completed.
    
-  
    • 
-  
  • Write the request structure to the session handle using the
-      write(2) system call. Multiple requests may be written
-      to the session in a single call.
    • 
-  
  • Read the response structure back from the session handle using the
-      read(2) system call. The response structure is defined
-      as follows:
-    
    
-    
    struct dmio_usrresp {
-        uint32_t resp_id;
-        int resp_error;
-};
    
-    
    
-    
    The
-        
-        corresponds to the req_id in the request.
-        
-        contains 0 if the request succeeded or an errno(2)
-        value indicating why the request failed. Multiple responses may be read
-        back in a single call. Note that responses may not be received in the
-        same order as requests were written.
    
-  
    • 
-

-
When a client is finished using a dmoverio
-    session, the session is destroyed by closing the session handle using
-    close(2).

-

-

-

-
The following is an example of a client using
-    dmoverio to zero-fill a region of memory. In this
-    example, the application would be able to perform other work while the
-    hardware-assisted data mover clears the specified block of memory.

-

-
int
-hw_bzero(void *buf, size_t len)
-{
-	static uint32_t reqid;
-
-	struct dmio_setfunc dsf;
-	struct iovec iov;
-	struct dmio_usrreq req;
-	struct dmio_usrresp resp;
-	int fd;
-
-	fd = open("/dev/dmoverio", O_RDWR, 0666);
-	if (fd == -1)
-		return (-1);
-
-	strcpy(dsf.dsf_name, "zero");
-
-	if (ioctl(fd, DMIO_SETFUNC, &dsf) == -1) {
-		close(fd);
-		return (-1);
-	}
-
-	iov.iov_base = buf;
-	iov.iov_len = len;
-
-	req.req_outbuf.dmbuf_iov = &iov;
-	req.req_outbuf.dmbuf_iovcnt = 1;
-	req.req_id = reqid++;
-
-	if (write(fd, &req, sizeof(req)) != sizeof(req)) {
-		close(fd);
-		return (-1);
-	}
-
-	/* Application can do other work here. */
-
-	if (read(fd, &resp, sizeof(resp)) != sizeof(resp)) {
-		close(fd);
-		return (-1);
-	}
-
-	if (resp.resp_id != req.req_id) {
-		close(fd);
-		return (-1);
-	}
-
-	if (resp.resp_error != 0) {
-		close(fd);
-		return (-1);
-	}
-
-	close(fd);
-	return (0);
-}

-

-

-

-

-
dmover(9)

-

-

-

-
The dmoverio device first appeared in
-    NetBSD 2.0.

-

-

-

-
The dmoverio device was designed and
-    implemented by Jason R. Thorpe
-    ⟨thorpej@wasabisystems.com⟩ and contributed by Wasabi Systems,
-    Inc.

-

-

-
-  
-    
-    
-  
-
August 1, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/dmphy.4 3.html b/static/netbsd/man4/dmphy.4 3.html
deleted file mode 100644
index d09368ca..00000000
--- a/static/netbsd/man4/dmphy.4 3.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
DMPHY(4)Device Drivers ManualDMPHY(4)

-

-

-

-
dmphy — Driver for
-    Davicom DM9101 and AMD 79c873 10/100 Ethernet PHYs

-

-

-

-
dmphy* at mii? phy ?

-

-

-

-
The dmphy driver supports the Davicom
-    DM9101 and AMD 79c873 10/100 Ethernet PHYs.

-
The AMD 79c873 is a work-alike (most likely an OEM of the core) of
-    the Davicom part.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
July 25, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/dpt.4 4.html b/static/netbsd/man4/dpt.4 4.html
deleted file mode 100644
index a2f1ab53..00000000
--- a/static/netbsd/man4/dpt.4 4.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
DPT(4)Device Drivers ManualDPT(4)

-

-

-

-
dpt — DPT EATA
-    SCSI adapter driver

-

-

-

-
dpt* at isa? port ? irq ? dma ?
-  

-  dpt* at eisa? slot ?
-  

-  dpt* at pci? dev ? function ?
-  

-  scsibus* at dpt?

-

-

-

-
The dpt driver provides support for third
-    and fourth generation DPT SCSI controllers. All communication with the
-    controllers is conducted via the EATA (Enhanced AT Bus Attachment)
-  protocol.

-
DPT adapters examine and interpret all SCSI commands received
-    before passing them to any underlying physical device(s). In this way,
-    caching, RAID and other transformations are achieved while remaining
-    transparent to the host operating system.

-

-

-

-
The dpt driver provides support for the
-    adapters listed below. Later models are supported by the
-    iop driver.

-

-

-

-  
DPT SmartCache III

-  
 

-  
DPT SmartCache IV

-  
 

-  
DPT SmartRAID III

-  
 

-  
DPT SmartRAID IV

-  
 

-

-

-

-

-

-

-  
/dev/dptu

-  
control device for unit u

-

-

-

-

-
None of these messages should be encountered under normal
-    circumstances. It should be noted that the list below is not complete.

-

-  
dpt%d: readcfg failed - see dpt(4)

-  
The EATA configuration data did not appear upon request. This may be
-      caused by older firmware. Generally the solution is to power-cycle the
-      affected machine.

-  
dpt%d: spurious intr

-  
A spurious interrupt was received from the HBA.

-  
dpt%d: bogus status (returned CCB id NNNN)

-  
A corrupt or incomplete status packet was received from the HBA.

-

-

-

-

-
cd(4), ch(4),
-    dpti(4), intro(4),
-    iop(4), scsi(4),
-    sd(4), st(4)

-
The sysutils/dptutil package.

-
CAM committee standard CAM/89-004 - the EATA (Enhanced AT Bus
-    Attachment) protocol.

-

-

-

-
The dpt driver first appeared in
-    NetBSD 1.4.2.

-

-

-

-
EATA adapters other than listed may function correctly with the
-    dpt driver, however a definitive list is not
-    available.

-
Older boards that do not support scatter-gather I/O or DMA are not
-    supported.

-
ECC formatted disk and arrays (i.e. with a sector size of 528
-    bytes) do not work correctly with the PM2041 and certain firmware revisions
-    of the PM3334.

-

-

-
-  
-    
-    
-  
-
December 7, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/dpti.4 4.html b/static/netbsd/man4/dpti.4 4.html
deleted file mode 100644
index 3861fe4f..00000000
--- a/static/netbsd/man4/dpti.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
DPTI(4)Device Drivers ManualDPTI(4)

-

-

-

-
dpti — DPT/Adaptec
-    I2O RAID management interface

-

-

-

-
dpti* at iop? tid 0

-

-

-

-
The dpti driver attaches to DPT and
-    Adaptec IOPs, and provides the pass-through command interface used by the
-    management tools for these devices. dptelog,
-    dptmgr, and raidutil version
-    3.12 as provided by Adaptec have been tested with this driver.

-

-

-

-

-  
/dev/dptiu

-  
control device for unit u

-

-

-

-

-
dpt(4), intro(4),
-    iop(4), iopsp(4),
-    ld(4), iopctl(8)

-
The sysutils/dptutil and
-    sysutils/storage-manager packages.

-

-

-

-
The dpti driver first appeared in
-    NetBSD 1.5.3.

-

-

-
-  
-    
-    
-  
-
December 7, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/drm.4 4.html b/static/netbsd/man4/drm.4 4.html
deleted file mode 100644
index b40c78f2..00000000
--- a/static/netbsd/man4/drm.4 4.html	
+++ /dev/null
@@ -1,205 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRM(4)Device Drivers ManualDRM(4)

-

-

-

-
drm — Direct
-    Rendering Manager — display configuration and graphics rendering
-    acceleration

-

-

-

-

-

-
amdgpu* at pci? dev ? function ?
-  

-  i915drmkms* at pci? dev ? function ?
-  

-  nouveau* at pci? dev ? function ?
-  

-  radeon* at pci? dev ? function ?
-  

-  rkdrm* at fdt? pass 5
-  

-  sunxidrm* at fdt? pass 5
-  

-  tegradrm* at fdt? pass 5

-

-

-

-
options DRM_LEGACY
-  

-  viadrmums* at drm?

-

-

-

-
options
-    DRM_MAX_RESOLUTION_HORIZONTAL=integer
-  

-  options DRM_MAX_RESOLUTION_VERTICAL=integer

-

-

-

-

-
The Direct Rendering Manager is part of the Direct Rendering
-    Infrastructure for supporting display configuration and hardware
-    acceleration for graphics rendering and other computation on a graphics
-    processing unit (GPU).

-
drm drivers come in two generations:

-

-  
Kernel mode-setting (KMS)

-  
Modern drivers that query and control display configuration in the kernel
-      via ioctl(2) commands exposed to userland.
-    
The /dev/dri/render* device nodes
-        provide access to graphics buffers and command stream submission for
-        rendering. The /dev/dri/card* device nodes
-        additionally provide access to the display configuration.

-    
KMS drivers provided as modules must generally be loaded by
-        the bootloader, configured in boot.cfg(8), and cannot
-        be loaded dynamically.

-  

-  
User mode-setting (UMS)

-  
Legacy drivers that rely on userland support code that accesses device
-      registers in the X(7) server to query and control
-      display configuration. The kernel may be unable to recover if the display
-      server crashes, or the device is suspended or resumed.
-    
The kernel driver and /dev/dri/card*
-        interfaces only manage buffers mapped in the GPU address space. Display
-        configuration from userland requires the
-        INSECURE option (see
-        options(4)) to allow userland access to device
-        registers.

-    
The DRM_LEGACY option allows legacy
-        UMS drivers to be loaded as modules (see
-      module(7)).

-  

-

-
The drm drivers provide support for the
-    following graphics devices:

-

-

-  
amdgpu

-  
Newer AMD graphics devices.

-  
i915drmkms

-  
Intel integrated graphics devices from the i915 series onward. (Some i8xx
-      support is included but not well-maintained. i7xx is not supported.)

-  
nouveau

-  
NVIDIA graphics devices.

-  
radeon

-  
Older AMD (including formerly ATI) Radeon graphics devices.

-  
viadrmums (legacy UMS)

-  
VIA graphics devices.

-

-

-
With some drivers (at least radeon(4)), in some
-    cases the driver does not choose the resolution correctly. The options
-    DRM_MAX_RESOLUTION_HORIZONTAL and
-    DRM_MAX_RESOLUTION_VERTICAL allow limiting the
-    maximum resolution in X and Y direction.

-
X(7) will attempt to create the device nodes
-    automatically and use drm automatically. To create a
-    device node manually:

-

-
mkdir -p /dev/dri
-mknod /dev/dri/card0 c 180 0
-chgrp wheel /dev/dri/card0
-chmod 0660 /dev/dri/card0

-

-
Debugging output can be enabled and disabled by setting flag bits
-    in the sysctl(8) node
-    hw.drm2.__drm_debug. Various other knobs may be
-    available under hw.drm2.

-

-

-

-

-  
/dev/dri/render*

-  
Provides access to graphics buffers and command stream submission for
-      rendering. Generally unprivileged.

-  
/dev/dri/card*

-  
In addition to everything provided by
-      /dev/dri/render*, provides access to change the
-      display configuration. Usually privileged.

-

-

-

-

-
The drm subsystem and drivers mostly live
-    under sys/external/bsd/drm2, with various Linux API
-    shims in sys/external/bsd/common and some individual
-    drm drivers scattered elsewhere in the tree.

-

-

-

-
Xorg(1), agp(4),
-    xorg.conf(5), X(7)

-
Direct Rendering
-    Infrastructure

-

-

-

-
drm was first available for Linux and
-    later ported to FreeBSD and
-    NetBSD. The port to NetBSD
-    was redone after the introduction of KMS.

-
The first generation of drm drivers
-    appeared in NetBSD 5.0. The second generation of
-    drm with KMS appeared in NetBSD
-    7.0.

-

-

-

-
Too many to list.

-
Work on the NetBSD port was contributed
-    by: Anonymous, Nia Alarie,
-    Eric Anholt, Rafal Boni,
-    Taylor R Campbell, Mihai
-    Chelaru, David Brownlee,
-    Jaromír Doleek, Matthias
-    Drochner, Christoph Egger,
-    FUKAUMI Naoki, Paul Goyette,
-    matthew green, Yorick Hardy,
-    Nick Hudson, Martin
-    Husemann, Arto Huusko,
-    Thomas Klausner, Jonathan
-    Kollasch, Tonnerre Lombard,
-    Jared McNeill, Jeremy Morse,
-    Kimihiro Nonaka, Tobias
-    Nygren, Rin Okuyama, Maya
-    Rashish, Erik Reid, Masanobu
-    SAITOH, Blair Sadewitz,
-    Chuck Silvers, Nathanial
-    Sloss, Jörg Sonnenberger,
-    Grégoire Sutre, Matt
-    Thomas, Izumi Tsutsui,
-    Patrick Welche, and Christos
-    Zoulas.

-

-

-

-
drm is large and complicated and has no
-    shortage of bugs. On systems where graphics is not important, you may wish
-    to use userconf(4) to disable the special-purpose
-    drm drivers for your graphics device and fall back
-    to vga(4) or genfb(4) with the default
-    display configuration provided by firmware.

-
drm is not ‘Digital Rights
-    Management’ and does not deprive you of agency over your own
-    computer, except insofar as the code base is difficult to maintain.

-

-

-
-  
-    
-    
-  
-
October 21, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/drum.4 4.html b/static/netbsd/man4/drum.4 4.html
deleted file mode 100644
index eea9487a..00000000
--- a/static/netbsd/man4/drum.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRUM(4)Device Drivers ManualDRUM(4)

-

-

-

-
drum — paging
-    device

-

-

-

-
This file refers to the paging device in use by the system. This
-    may actually be a subdevice of one of the disk drivers, but in a system with
-    paging interleaved across multiple disk drives it provides an indirect
-    driver for the multiple drives.

-

-

-

-

-  
/dev/drum

-  
 

-

-

-

-

-
The drum special file appeared in
-    3.0BSD.

-

-

-

-
Reads from the drum are not allowed across the interleaving
-    boundaries. Since these only occur every .5Mbytes or so, and since the
-    system never allocates blocks across the boundary, this is usually not a
-    problem.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/drvctl.4 4.html b/static/netbsd/man4/drvctl.4 4.html
deleted file mode 100644
index 3f8deb04..00000000
--- a/static/netbsd/man4/drvctl.4 4.html	
+++ /dev/null
@@ -1,172 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRVCTL(4)Device Drivers ManualDRVCTL(4)

-

-

-

-
drvctl — driver
-    control device

-

-

-

-
pseudo-device drvctl

-

-

-

-
The drvctl driver allows to control some
-    autoconf(9) operations from userland through the
-    /dev/drvctl device and the
-    drvctl(8) command.

-
The driver supports the following ioctl(2)
-    operations.

-

-

-

-  
DRVSUSPENDDEV

-  
 

-  
DRVRESUMEDEV

-  
Invoke power management functions for a named driver that has registered
-      itself with the pmf(9) framework. The ioctl argument
-      specifies the driver name as:
-    

-    
struct devpmargs {
-        char devname[16];
-        uint32_t flags;
-};

-    

-    
The flag DEVPM_F_SUBTREE lets the
-        function recurse over all children of that driver.

-    

-  

-  
DRVLISTDEV

-  
Return a list of child devices attached to the named driver. The ioctl
-      argument specifies the driver name as:
-    

-    
struct devlistargs {
-        char l_devname[16];
-        char (*l_childname)[16];
-        size_t l_children;
-};

-    

-    The names for up to l_children child devices are
-      copied to the l_childname array. If there is no
-      error, the ioctl returns the total number of children. Normally you would
-      call DRVLISTDEV once with
-      l_children set to zero, allocate a buffer for
-      enough 16-character strings and call DRVLISTDEV
-      again to fill the buffer.
-    

-  

-  
DRVDETACHDEV

-  
Detach the named driver and all its autoconfigured children. The ioctl
-      argument specifies the driver name as:
-    

-    
struct devdetachargs {
-        char devname[16];
-};

-    

-    

-  

-  
DRVSCANBUS

-  
Invoke the rescan method of the named driver to locate child devices. The
-      ioctl argument specifies the driver name as:
-    

-    
struct devrescanargs {
-        char busname[16];
-        char ifattr[16];
-        unsigned int numlocators;
-        int *locators;
-};

-    

-    
Some device drivers attach children to specific interface
-        attributes, a zero length ifattr represents that
-        no interface attribute should be used. The rescan can also be limited to
-        driver-specific locators.

-    

-  

-  
DRVCTLCOMMAND

-  
Send a command formatted as a property list. The property list includes
-      all arguments like the driver name, the result is again a property list.
-      Currently the only supported command is "get-properties", the
-      property list is constructed like:
-    

-    
const char *device = "sd0";
-const char *command = "get-properties";
-
-prop_string_t s;
-prop_dictionary_t c, a;
-
-c = prop_dictionary_create();
-a = prop_dictionary_create();
-
-s = prop_string_create_cstring_nocopy(command);
-prop_dictionary_set(c, "drvctl-command", s);
-prop_object_release(s);
-
-s = prop_string_create_cstring(device);
-prop_dictionary_set(a, "device-name", s);
-prop_object_release(s);
-
-prop_dictionary_set(c, "drvctl-arguments", a);
-prop_object_release(a);

-    

-    
The command must be sent with
-        prop_dictionary_sendrecv_ioctl(3). The resulting
-        property list contains the numeric attribute
-        drvctl-error, which corresponds to an
-        errno value, and the dictionary
-        drvctl-result-data. The contents of the
-        dictionary depends on the queried driver.

-    

-  

-  
DRVGETEVENT

-  
Return the next queued autoconfig event formatted as a property list. The
-      request needs to be sent with
-      prop_dictionary_recv_ioctl(3). The resulting property
-      list contains the string attributes event, device
-      and parent. Currently the events
-      "device-attach" and "device-detach" are generated by
-      the autoconf(9) framework.
-    
If /dev/drvctl was opened with
-        O_NONBLOCK and there is no event queued, the
-        call returns immediately with EWOULDBLOCK,
-        otherwise it waits for the next event.

-  

-

-

-
All names used in the ioctl arguments are zero-terminated strings.
-    A driver name is the name of a driver instance with the appended unit number
-    like sd0, atabus3,
-    ...

-

-

-

-

-  
/dev/drvctl

-  
drvctl access device

-

-

-

-

-
ioctl(2), prop_send_ioctl(3),
-    proplib(3), devpubd(8),
-    drvctl(8), autoconf(9)

-

-

-

-
The /dev/drvctl device appeared in
-    NetBSD 3.0 but was only added to the GENERIC
-    configuration in NetBSD 5.0.

-

-

-
-  
-    
-    
-  
-
May 13, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/ds2482ow.4 4.html b/static/netbsd/man4/ds2482ow.4 4.html
deleted file mode 100644
index 91fafc64..00000000
--- a/static/netbsd/man4/ds2482ow.4 4.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
DS2482OW(4)Device Drivers ManualDS2482OW(4)

-

-

-

-
ds2482ow — Driver
-    for Maxim DS2482-100 and DS2482-800 IC2 to 1-Wire bridge

-

-

-

-
ds2482ow* at iic? addr 0x18
-  

-  ds2482ow* at iic? addr 0x19
-  

-  ds2482ow* at iic? addr 0x1a
-  

-  ds2482ow* at iic? addr 0x1b
-  

-  ds2482ow* at iic? addr 0x1c DS2482-800 only
-  

-  ds2482ow* at iic? addr 0x1d DS2482-800 only
-  

-  ds2482ow* at iic? addr 0x1e DS2482-800 only
-  

-  ds2482ow* at iic? addr 0x1f DS2482-800 only
-  

-  onewire* at ds2482ow?

-

-

-

-
The ds2482ow driver provides 1 or 8
-    onewire(4) busses via an I2C interface. The
-    ds2482ow addr argument selects
-    the address at the iic(4) bus. The chip generates all of
-    the needed 1-Wire pulses on its own and provides for the pullup needed on
-    the 1-Wire data line. The method that the chip uses for pullup can be
-    changed through sysctl(8) nodes.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
If true, turn on active pullup on all channels supported by the chip.

-  

-  
If true, turn on strong pullup on all channels that the chip supports and
-      on the DS2482-100 chip, allow the PCTLZ pin to provide addition current to
-      the 1-Wire bus. This mode conflicts with a 1-Wire reset and will be
-      disabled if that command is sent to the 1-Wire bus.
-    

-  

-  

-  
use an internal passive resister.

-  

-  
If the driver is compiled with DS2482_DEBUG, this
-      node will appear and can be used to set the debugging level.

-

-

-

-

-
onewire(4), iic(4),
-    sysctl(8)

-

-

-

-
The ds2482ow driver first appeared in
-    NetBSD 11.0.

-

-

-

-
The ds2482ow driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The DS2482 chip supports overdrive speed on a 1-Wire bus. This
-    driver does not support overdrive speed mode.

-

-

-
-  
-    
-    
-  
-
October 31, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/ds28e17iic.4 3.html b/static/netbsd/man4/ds28e17iic.4 3.html
deleted file mode 100644
index 07aca3af..00000000
--- a/static/netbsd/man4/ds28e17iic.4 3.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
DS28E17IIC(4)Device Drivers ManualDS28E17IIC(4)

-

-

-

-
ds28e17iic —
-    Driver for Maxim DS28E17 1-Wire to I2C bridge

-

-

-

-
ds28e17iic* at onewire?

-

-

-

-
The ds28e17iic driver provides a 1-Wire to
-    I2C bridge with a iic(4) bus at the far end using the
-    DS28E17 bridge chip.

-
The DS28E17 will automatically detect and deal with a device at
-    the other end of the bus that uses I2C clock stretching.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
 

-  

-  
When the driver sends a transaction down the 1-Wire bus, these variables
-      are how long to delay before reading the status on whether or not the
-      conversion is done and the number of times to perform this read back. In
-      general, these values should be as short as possible, but if there are too
-      short, a EAGAIN timeout will occur when the end device is just taking a
-      longer than expect amount of time to respond. This may be particularly
-      noticed if end device is doing clock stretching.

-  

-  
If set to 1, report that an attempt to do a Read without a Stop occurred.
-      The chip does not support that operation. Read without Stop will be
-      treated as a Read with a Stop with the hope that the end device will be
-      able to deal with that.

-  

-  
If set to 1, report that an attempt to perform a zero length read or zero
-      length write occurred. The chip does not support zero length reads or
-      writes.

-  

-  
If the driver is compiled with DS28E17IIC_DEBUG,
-      this node will appear and can be used to set the debugging level.

-

-

-

-

-
onewire(4), iic(4),
-    sysctl(8)

-

-

-

-
The ds28e17iic driver first appeared in
-    NetBSD 11.0.

-

-

-

-
The ds28e17iic driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
While this may not be considered a bug, the DS28E17 chip will
-    detach itself from the onewire(4) bus if there is not a
-    device connected to its SDA and SCL pins.

-
The i2cscan(8) command will not function
-    entirely correctly when run against a DS28E17 chip. The default mode of
-    doing a I2C Write with Stop that is zero length is not supported by the
-    DS28E17 chip. When the i2cscan(8) command is used with its
-    one byte read mode it will find devices as long as the device does not NACK
-    on a I2C read.

-

-

-

-
-  
-    
-    
-  
-
January 12, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/dse.4 4.html b/static/netbsd/man4/dse.4 4.html
deleted file mode 100644
index 71388683..00000000
--- a/static/netbsd/man4/dse.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
DSE(4)Device Drivers ManualDSE(4)

-

-

-

-
dse — DaynaPORT
-    SCSI/Link SCSI bus Ethernet interface driver

-

-

-

-
dse* at scsibus? target ? lun ?

-

-

-

-
The dse driver supports the DaynaPORT
-    SCSI/Link SCSI bus Ethernet interface. These devices can also be currently
-    emulated on a Raspberry Pi with an RaSCSI board running PiSCSI software.

-
There are additionally
-    (),
-    (),
-    and
-    ()
-    entry points so that the device also appears as a SCSI device. Currently
-    these functions are place holders.

-

-

-

-
scsi(4), ifconfig(8)

-

-

-

-
Hiroshi Noguchi
-    <ngc@ff.iij4u.or.jp>

-
Matt Sandstrom
-    <mattias@beauty.se>
-    who modified this driver for NetBSD 1.5.3

-

-

-

-
This device doesn't conform to the SCSI specification. Also that
-    this manual page was written by Nathanial Sloss
-    <nathanialsloss@yahoo.com.au>

-

-

-

-
RaSCSI http://retropc.net/gimons/rascsi/

-
PiSCSI (formally RaSCSI Reloaded) https://github.com/PiSCSI

-
Raspberry Pi https://www.raspberrypi.org/

-

-

-
-  
-    
-    
-  
-
December 16, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/dtide.4 4.html b/static/netbsd/man4/dtide.4 4.html
deleted file mode 100644
index a26aee2b..00000000
--- a/static/netbsd/man4/dtide.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
DTIDE(4)Device Drivers ManualDTIDE(4)

-

-

-

-
dtide — D.T.
-    Software IDE interface driver

-

-

-

-
dtide* at podulebus0 slot ?
-  

-  atabus* at dtide? channel ?

-

-

-

-
The dtide driver handles a D.T. Software
-    IDE interface plugged into an Acorn expansion slot. It uses the standard
-    NetBSD IDE controller driver, and hence can use the
-    standard atabus driver.

-
The card provides two IDE channels. The external IDE connector is
-    channel 0, while the internal connector is channel 1.

-

-

-

-
atabus(4), atapibus(4),
-    podulebus(4), wd(4)

-

-

-

-
The driver was derived by reverse-engineering the card and its
-    RISC OS driver, so it may not handle the card entirely optimally.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/dtv.4 4.html b/static/netbsd/man4/dtv.4 4.html
deleted file mode 100644
index 8dad6555..00000000
--- a/static/netbsd/man4/dtv.4 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
DTV(4)Device Drivers ManualDTV(4)

-

-

-

-
dtv — interface
-    for digital television

-

-

-

-
dtv* at dtvbus?

-

-  

-  #include <dev/dtv/dtvio.h>
-  

-  #include
-    <dev/dtv/dtvio_demux.h>
-  

-  #include
-    <dev/dtv/dtvio_frontend.h>

-

-

-

-
The machine-independent dtv interface
-    provides support for digital television (DTV). A
-    subset of the Linux Digital Video Broadcasting (DVB)
-    APIs is supported. In particular,
-    dtv provides the DVB frontend and demodulator
-    APIs.

-

-

-

-
The following machine-independent devices are supported:

-

-

-  
auvitek(4)

-  
Auvitek AU0828-based video capture cards

-  
emdtv(4)

-  
EM28XX-based DTV cards

-

-

-
Note that the dtv device drivers are
-    generally only available as kernel modules; see module(7)
-    and modload(8) for additional details. Refer to
-    dtviic(4) for details about the supported demodulators and
-    tuners.

-

-

-

-

-  
/dev/dvb/adapterN/frontend0

-  
The frontend device, for controlling the tuner and demodulator
-    hardware.

-  
/dev/dvb/adapterN/demux0

-  
The demux device, for controlling the hardware filters.

-  
/dev/dvb/adapterN/dvr0

-  
Digital video recording device.

-

-

-

-

-
auvitek(4), dtviic(4),
-    emdtv(4), video(9)

-
pkgsrc/multimedia/dvb-apps,
-    pkgsrc/multimedia/mplayer

-
Linux Media Infrastructure
-    API., Part II. Linux DVB API,
-    https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/dvb/dvbapi.html,
-    2011.

-

-

-

-
The dtv interface first appeared in
-    NetBSD 6.0.

-

-

-

-
Jared D. McNeill
-    ⟨jmcneill@invisible.ca⟩

-

-

-
-  
-    
-    
-  
-
August 30, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/dtviic.4 4.html b/static/netbsd/man4/dtviic.4 4.html
deleted file mode 100644
index af52bca4..00000000
--- a/static/netbsd/man4/dtviic.4 4.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
DTVIIC(4)Device Drivers ManualDTVIIC(4)

-

-

-

-
dtviic, au8522,
-    cx24227, lg3303,
-    mt2131, nxt2k,
-    zl10353, tvpll,
-    xc3028, xc5k —
-    Inter IC (I2C) modules for DTV

-

-

-

-
The dtviic modules provide support for
-    dtv(4) devices. The dtviic module
-    group includes tuners, demodulators, and analog video decoders.

-
The usual hardware structure consists of a host controller
-    (connected for instance via usb(4) or
-    pci(4)) that provides the data moving facilities (for the
-    analog or digital video streams) and an iic(4) bus over
-    which the other chips can be configured.

-
For example, a typical dtv(4) setup would look
-    like this:

-
    
-  
  1. Initialize transport stream (TS) port on the host
-      controller.
    2. 
-  
  2. Configure the demodulator that “demodulates” the information
-      from an intermediate frequency (IF) that is
-      provided to it by the associated tuner. This step typically includes
-      setting the desired quadrature amplitude modulation
-      (QAM) and bandwidth, among other things.
    3. 
-  
  3. Configure the tuner. Typically this step includes at least setting the
-      frequency.
    4. 
-  
  4. Start TS transfer (using DMA transfers or
-      USB high speed transfers).
    5. 
-

-
The supported demodulators include:

-

-

-  
au8522

-  
Auvitek AU8522 ATSC/QAM64/QAM256 demodulator

-  
cx24227

-  
Conexant CX24227 ATSC/QAM64/QAM256 demodulator

-  
lg3303

-  
LG LGDT3303 ATSC/QAM64/QAM256 demodulator

-  
mt2131

-  
MicroTune MT2131 ATSC demodulator

-  
nxt2k

-  
NxtWave Communications NXT2004 ATSC demodulator

-  
zl10353

-  
Zarlink ZL10353 (Intel CE623x) COFDM/DVB-T demodulator

-

-

-
The supported tuners are:

-

-

-  

-  
Generic PLL-based tuners

-  
xc3028

-  
XCeive XC3028 analog and digital tuner

-  
xc5k

-  
Xceive XC5000 analog and digital tuner

-

-

-

-

-

-
    
-  
  • dvb-fe-nxt2004.fw needed by
-      nxt2k
    • 
-  
  • xc3028-v27.fw or
-      xc3028L-v36.fw (provided by
-      pkgsrc/sysutils/xc3028l-firmware) needed by
-      xc3028
    • 
-  
  • dvb-fe-xc5000-1.6.114.fw needed by
-      xc5k, provided by the
-      pkgsrc/sysutils/xc5k-firmware
    • 
-

-

-

-

-
dtv(4), iic(4),
-    module(7)

-

-

-

-
The dtviic modules first appeared in
-    NetBSD 6.0.

-

-

-

-
Authors include Jared D. McNeill
-    ⟨jmcneill@NetBSD.org⟩, Jonathan A.
-    Kollasch ⟨jakllsch@NetBSD.org⟩, and
-    Jukka Ruohonen ⟨jruohonen@iki.fi⟩.

-

-

-
-  
-    
-    
-  
-
August 30, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/dwctwo.4 4.html b/static/netbsd/man4/dwctwo.4 4.html
deleted file mode 100644
index bb79505c..00000000
--- a/static/netbsd/man4/dwctwo.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
DWCTWO(4)Device Drivers ManualDWCTWO(4)

-

-

-

-
dwctwo — USB
-    DesignWare HS Controller driver

-

-

-

-
dwctwo* at obio?
-  

-  usb* at dwctwo?

-

-

-

-
The dwctwo driver provides support for
-    DesignWare High Speed Controller as found in the Raspberry Pi.

-

-

-

-
usb(4)

-

-

-

-
The dwctwo driver appeared in
-    NetBSD 7.0.

-

-

-
-  
-    
-    
-  
-
July 15, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/ea.4 4.html b/static/netbsd/man4/ea.4 4.html
deleted file mode 100644
index cb0f66fe..00000000
--- a/static/netbsd/man4/ea.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
EA(4)Device Drivers ManualEA(4)

-

-

-

-
ea — Atomwide
-    “Ether3” Ethernet driver

-

-

-

-
ea* at podulebus0 slot ?

-

-

-

-
The ea driver provides access to a 10 Mb/s
-    Ethernet network through a card based on the SEEQ 8005 Advanced Ethernet
-    Data Link Controller.

-
The cards supported by this driver are generally those supported
-    by the “Ether3” driver under RISC OS. These include:

-

-
    
-  
  • Atomwide A-1005
    • 
-  
  • Atomwide A-1006
    • 
-  
  • Atomwide A-1007
    • 
-  
  • Acorn AEH54
    • 
-

-
Media selection on these cards is through links on the board, so
-    there are no media options available through the driver.

-

-

-

-
eb(4), netintro(4),
-    podulebus(4), ifconfig(8)

-

-

-

-
The driver doesn't support 8-bit cards like the A-1009, A-1010,
-    A-1011 and A-1012.

-

-

-
-  
-    
-    
-  
-
April 6, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/eap.4 4.html b/static/netbsd/man4/eap.4 4.html
deleted file mode 100644
index 3cdc2f83..00000000
--- a/static/netbsd/man4/eap.4 4.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
EAP(4)Device Drivers ManualEAP(4)

-

-

-

-
eap — AudioPCI
-    audio device driver

-

-

-

-
eap* at pci? dev ? function ?
-  

-  options EAP_USE_BOTH_DACS

-

-  

-  audio* at audiobus?
-  

-  joy* at eap?
-  

-  midi* at eap?

-

-

-

-
The eap driver provides support for the
-    Ensoniq AudioPCI and Creative Labs SoundBlaster PCI series of audio cards.
-    All models based on the ES1370, ES1371, and ES1373 chips are supported.

-
By specifying:

-

-
options
-  EAP_USE_BOTH_DACS

-
a second audio device is attached. This can be used for audio
-    output simultaneously with the primary DAC. You can use it simply by
-    directing audio output to the additional /dev/audioX
-    device associated with it.

-

-

-

-
ac97(4), audio(4),
-    joy(4), midi(4),
-    pci(4)

-

-

-

-
The eap device driver appeared in
-    NetBSD 1.4.

-

-

-

-
The joystick port hardware works by emulating a legacy
-    isa(4) joystick port, bypassing the
-    pci(4) bus method for address allocation. This is unlikely
-    to work on PCI busses other than the primary one. There is also a
-    possibility for conflicts with real ISA devices because the PCI bus is
-    probed before ISA. Use with caution.

-
The EAP_USE_BOTH_DACS option is rather
-    redundant after the introduction of the in-kernel audio mixer, and may be
-    removed in a future release. It is possible that it could be used to
-    accelerate mixing streams by taking advantage of the hardware's features,
-    but currently the additional (small) overhead of the kernel mixer is
-    impossible to bypass, since NetBSD no longer allows
-    userspace software to write directly to audio hardware. The
-    eap hardware only features one clock, so generally
-    the second audio device must be configured in the same way as the first.

-

-

-
-  
-    
-    
-  
-
May 16, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/eb.4 4.html b/static/netbsd/man4/eb.4 4.html
deleted file mode 100644
index 9496acbc..00000000
--- a/static/netbsd/man4/eb.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
EB(4)Device Drivers ManualEB(4)

-

-

-

-
eb — ANT
-    “EtherB” Ethernet driver

-

-

-

-
eb* at podulebus0 slot ?

-

-

-

-
The eb driver provides access to a 10 Mb/s
-    Ethernet network through a card based on the SEEQ 80C04 Ethernet Data Link
-    Controller.

-
The cards supported by this driver are generally those supported
-    by the “EtherB” driver under RISC OS. These include:

-

-
    
-  
  • ANT EtherB network slot card
    • 
-  
  • Acorn AEH61
    • 
-

-

-

-

-
ea(4), netintro(4),
-    podulebus(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
April 6, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ebus.4 4.html b/static/netbsd/man4/ebus.4 4.html
deleted file mode 100644
index 3f5e7e3d..00000000
--- a/static/netbsd/man4/ebus.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
EBUS(4)Device Drivers ManualEBUS(4)

-

-

-

-
EBus —
-    introduction to SPARC EBus bus support and
-  drivers

-

-

-

-
ebus* at pci?

-

-

-

-
The EBus bus is designed to provide the
-    ability to put ISA and traditional Intel-style peripherals in a SPARC based
-    system with a minimal amount of glue logic. Typically, it is implemented in
-    the PCIO IC from SME, which also implements a hme(4)
-    compatible PCI network device
-    (‘network’). The
-    EBus has four DMA channels, similar to the DMA seen
-    in the esp(4) SCSI DMA.

-

-

-

-
Sun Microelectronics,
-    Peripheral Component Interconnect Input Output
-    Controller,
-    Part No.: 802-7837-01,
-    http://www.sun.com/oem/products/manuals/802-7837.pdf,
-    March 1997.

-

-

-
-  
-    
-    
-  
-
March 13, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/ec.4 3.html b/static/netbsd/man4/ec.4 3.html
deleted file mode 100644
index b8526efe..00000000
--- a/static/netbsd/man4/ec.4 3.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
EC(4)Device Drivers ManualEC(4)

-

-

-

-
ec — driver for
-    3Com EtherLink II (3c503) ISA bus Ethernet cards

-

-

-

-
ec0 at isa? port 0x250 iomem 0xd8000 irq
-  9

-

-

-

-
The ec device driver supports 3Com
-    EtherLink II (3c503) Ethernet cards for ISA bus which are based on the
-    National Semiconductor DP8390/WD83C690 Ethernet interface chips.

-

-

-

-
The EtherLink II supports two media types on a single card. All
-    support the AUI media type. The other media is either BNC or UTP behind a
-    transceiver. Software cannot differentiate between BNC and UTP cards.

-
To enable the AUI media, select the
-     or
-     media
-    type with ifconfig(8)'s media
-    directive. To select the other media (BNC or UTP), select the
-    
-    or  media
-    type.

-

-

-

-

-  
ec0: wildcarded IRQ is not allowed

-  

-    
The IRQ was wildcarded in the kernel configuration file. This
-        is not supported.

-  

-  
ec0: invalid IRQ <n>, must be 3, 4, 5, or 9

-  

-    
An IRQ other than the above IRQ values was specified in the
-        kernel configuration file. The EtherLink II hardware only supports the
-        above listed IRQ values.

-  

-  
ec0: failed to clear shared memory at offset <off>

-  

-    
The memory test was unable to clear shared the
-        interface's shared memory region. This often indicates that the card is
-        configured at a conflicting
-        
-      address.

-  

-  
ec0: warning - receiver ring buffer overrun

-  

-    
The DP8390 Ethernet chip used by this board implements a
-        shared-memory ring-buffer to store incoming packets. The 3c503 usually
-        has only 8K bytes of shared memory. This is only enough room for about 4
-        full-size (1500 byte) packets. This can sometimes be a problem,
-        especially on the original 3c503, because these boards' shared-memory
-        access speed is quite slow; typically only about 1MB/second. The
-        overhead of this slow memory access, and the fact that there is only
-        room for 4 full-sized packets means that the ring-buffer will
-        occasionally overrun.

-    
When an overrun occurs, the board must be reset to avoid a
-        lockup problem in early revision DP8390 Ethernet chips. Resetting the
-        board causes all of the data in the ring-buffer to be lost, requiring
-        the data to be retransmitted/received, congesting the board further.
-        Because of this, maximum throughput on these boards is only about
-        400-600K bytes per second.

-    
This problem is exacerbated by NFS because the 8-bit boards
-        lack sufficient packet buffer memory to support the default 8K byte
-        packets that NFS and other protocols use as their default. If these
-        cards must be used with NFS, use the mount_nfs(8)
-        -r and -w options in
-        /etc/fstab to limit NFS's packet size. 4K (4096)
-        byte packets generally work.

-  

-

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), ifconfig(8),
-    mount_nfs(8)

-

-

-
-  
-    
-    
-  
-
October 20, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/edc.4 4.html b/static/netbsd/man4/edc.4 4.html
deleted file mode 100644
index 634024e8..00000000
--- a/static/netbsd/man4/edc.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
EDC(4)Device Drivers ManualEDC(4)

-

-

-

-
edc — IBM DASD
-    Storage Interface ESDI disk driver

-

-

-

-
edc* at mca? slot ?
-  

-  ed* at edc? drive ?

-

-

-

-
The edc driver supports IBM MCA ESDI disk
-    controllers and disks, most commonly found in IBM PS/2 machines. Supported
-    boards include:

-

-

-  
IBM ESDI Fixed Disk Controller

-  
 

-  
IBM Integrated ESDI Fixed Disk & Controller

-  
 

-

-

-

-

-

-
intro(4), mca(4)

-

-

-

-
This driver appeared in NetBSD 1.6.

-

-

-

-
The driver was written by Jaromir Dolecek
-    ⟨jdolecek@NetBSD.org⟩.

-

-

-

-
The driver should also work properly on machines with more than
-    16MB of memory, using buffer bouncing to overcome 24bit MCA DMA
-  limitation.

-

-

-
-  
-    
-    
-  
-
April 19, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ef.4 4.html b/static/netbsd/man4/ef.4 4.html
deleted file mode 100644
index 4858b30c..00000000
--- a/static/netbsd/man4/ef.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
EF(4)Device Drivers ManualEF(4)

-

-

-

-
ef — 3Com
-    EtherLink 16 (3c507) ISA Ethernet driver

-

-

-

-
ef0 at isa? port 0x360 iomem 0xd0000 irq
-  7

-

-

-

-
The ef driver supports 3Com EtherLink II
-    (3c507) 10Mb/s Ethernet NIC based on the Intel 82586 Ethernet chip.

-

-

-

-
ai(4), elmc(4),
-    ifmedia(4), intro(4),
-    isa(4), ix(4),
-    ifconfig(8)

-

-

-

-
Rafal K. Boni

-

-

-
-  
-    
-    
-  
-
June 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/eg.4 4.html b/static/netbsd/man4/eg.4 4.html
deleted file mode 100644
index 74581799..00000000
--- a/static/netbsd/man4/eg.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
EG(4)Device Drivers ManualEG(4)

-

-

-

-
eg — 3Com
-    EtherLink Plus (3c505) Ethernet interface device driver

-

-

-

-
eg0 at isa? port 0x280 irq 9

-

-

-

-
The eg interface provides access to a 10
-    Mb/s Ethernet network via the 3Com EtherLink Plus (3c505) Ethernet
-  board.

-

-

-

-
intro(4), isa(4),
-    ifconfig(8)

-

-

-

-
The eg driver was written by Dean
-  Huxley.

-

-

-
-  
-    
-    
-  
-
November 10, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/ehci.4 4.html b/static/netbsd/man4/ehci.4 4.html
deleted file mode 100644
index 32284df6..00000000
--- a/static/netbsd/man4/ehci.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
EHCI(4)Device Drivers ManualEHCI(4)

-

-

-

-
ehci — USB
-    Enhanced Host Controller driver

-

-

-

-
ehci* at cardbus? function ?
-  

-  ehci* at pci? dev ? function ?
-  

-  usb* at ehci?

-

-

-

-
The ehci driver provides support for the
-    USB Enhanced Host Controller Interface, which is used by USB 2.0
-    controllers.

-
EHCI controllers are peculiar in that they can only handle the USB
-    2.0 protocol. This means that they normally have one or more companion
-    controllers (i.e., ohci(4) or uhci(4))
-    handling USB 1.x devices. Consequently each USB connector is electrically
-    connected to two USB controllers. The handling of this is totally automatic,
-    but can be noticed since USB 1.x and USB 2.0 devices plugged in to the same
-    connector appear to connect to different USB busses.

-

-

-

-
cardbus(4), ohci(4),
-    pci(4), uhci(4),
-    usb(4)

-

-

-

-
The ehci driver appeared in
-    NetBSD 1.6.

-

-

-

-
The support for hubs that are connected with high speed upstream
-    and low or full speed downstream (i.e., for transaction translators) is
-    limited.

-

-

-
-  
-    
-    
-  
-
August 10, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/ei.4 4.html b/static/netbsd/man4/ei.4 4.html
deleted file mode 100644
index 129f800d..00000000
--- a/static/netbsd/man4/ei.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
EI(4)Device Drivers ManualEI(4)

-

-

-

-
ei — Acorn AKA25
-    (Ether1) Ethernet driver

-

-

-

-
ei* at podulebus0 slot ?

-

-

-

-
The ei driver provides access to a 10 Mb/s
-    Ethernet network through an Acorn AKA25 Ethernet card (also known as
-    “Ether1” after its RISC OS driver). The card is based on the
-    Intel 82586.

-
Media selection on the AKA25 is through links on the board
-    (LK3–LK8 and LK10), so there are no media options available through
-    the driver.

-

-

-

-
netintro(4), podulebus(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
October 22, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/eisa.4 4.html b/static/netbsd/man4/eisa.4 4.html
deleted file mode 100644
index 5f6c454b..00000000
--- a/static/netbsd/man4/eisa.4 4.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
EISA(4)Device Drivers ManualEISA(4)

-

-

-

-
eisa —
-    Introduction to EISA bus machine-independent drivers and
-    support

-

-

-

-
options EISAVERBOSE

-
Machine-dependent; depends on the bus topology and EISA bus
-    interface of your system. Typical EISA buses are either connected directly
-    to the main system bus, or via an PCI to EISA bridge. See the
-    intro(4) documentation for your system for details.

-

-

-

-
NetBSD includes a machine-independent EISA
-    bus subsystem and several machine-independent EISA device drivers.

-
Your system may support additional EISA devices. Drivers for EISA
-    devices not listed here are machine-dependent. Consult your system's
-    intro(4) for additional information.

-

-

-

-
NetBSD includes machine-independent EISA
-    drivers, sorted by device type and driver name:

-

-

-

-

-  
cac(4)

-  
Compaq array controllers.

-  
mlx(4)

-  
Mylex DAC960 and DEC SWXCR RAID controllers.

-

-

-

-

-

-

-

-  
ahb(4)

-  
Adaptec 174x SCSI interfaces.

-  
ahc(4)

-  
Adaptec AIC 7770, 274x, and 284x SCSI interfaces.

-  
bha(4)

-  
BusLogic BT-74x SCSI interfaces.

-  
dpt(4)

-  
DPT SmartCache/SmartRAID III and IV SCSI interfaces.

-  
uha(4)

-  
Ultrastor 24f SCSI interfaces.

-

-

-

-

-

-

-

-  
ep(4)

-  
3Com 3c579 and 3c592 10Mbit Ethernet, and 3c597 10/100Mbit Ethernet
-      interfaces.

-  
le(4)

-  
Digital DE422 Ethernet interfaces.

-  
tlp(4)

-  
Digital DE425 Ethernet interfaces.

-

-

-
Note that most or all EISA devices also have PCI or ISA
-    equivalents. These are listed in pci(4),
-    isa(4), or isapnp(4), respectively. The
-    manual pages for each individual driver also lists the supported bus
-    variants.

-

-

-

-

-
intro(4)

-

-

-

-
The machine-independent EISA subsystem appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
September 27, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/el.4 4.html b/static/netbsd/man4/el.4 4.html
deleted file mode 100644
index 2d9b4a48..00000000
--- a/static/netbsd/man4/el.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
EL(4)Device Drivers ManualEL(4)

-

-

-

-
el — 3Com
-    EtherLink (3c501) Ethernet interface device driver

-

-

-

-
el0 at isa? port 0x300 irq 9

-

-

-

-
The el interface provides access to a 10
-    Mb/s Ethernet network via the 3Com EtherLink (3c501) Ethernet cards.

-

-

-

-
intro(4), isa(4),
-    ifconfig(8)

-

-

-

-
The el driver was written my Matthew
-    Kimmel.

-

-

-

-
The el driver does not currently support
-    multicast or DMA.

-

-

-
-  
-    
-    
-  
-
November 10, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/elmc.4 4.html b/static/netbsd/man4/elmc.4 4.html
deleted file mode 100644
index e86e1bf6..00000000
--- a/static/netbsd/man4/elmc.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
ELMC(4)Device Drivers ManualELMC(4)

-

-

-

-
elmc — 3Com
-    EtherLink/MC (3c523) MCA Ethernet driver

-

-

-

-
elmc* at mca? slot ?

-

-

-

-
The elmc driver supports 3Com EtherLink/MC
-    (3c523) 10Mb/s Ethernet NIC based on the Intel 82586 Ethernet chip.

-

-

-

-
ai(4), ef(4),
-    ifmedia(4), intro(4),
-    ix(4), mca(4),
-    ifconfig(8)

-

-

-

-
The driver was written by Jaromir Dolecek
-    ⟨jdolecek@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
March 2, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/emcfan.4 3.html b/static/netbsd/man4/emcfan.4 3.html
deleted file mode 100644
index 31f90e71..00000000
--- a/static/netbsd/man4/emcfan.4 3.html	
+++ /dev/null
@@ -1,180 +0,0 @@
-
-  
-    
-    
-    
-  
-
EMCFAN(4)Device Drivers ManualEMCFAN(4)

-

-

-

-
emcfan — Driver
-    for the Microchip Technology EMC210x and EMC230x fan controllers via I2C
-    bus

-

-

-

-
emcfan* at iic? addr 0x2c
-  

-  emcfan* at iic? addr 0x2d
-  

-  emcfan* at iic? addr 0x2e
-  

-  emcfan* at iic? addr 0x2f
-  

-  emcfan* at iic? addr 0x4c
-  

-  emcfan* at iic? addr 0x4d

-

-

-

-
The emcfan driver supports the EMC210x
-    family with the following models: EMC2101, EMC2101-R, EMC2103-1, EMC2103-2,
-    EMC2103-4, EMC2104, and EMC2106 and for the EMC230x family with the
-    following models: EMC2301, EMC2302, EMC2303, and EMC2305. All chips have one
-    or more tachometers, and some of the chips have a number of temperature
-    sensors and GPIO. The emcfan driver provides
-    envsys(4) framework measurements for the RPM as determined
-    by the tachometers. If the chip has temperature sensors, the
-    envsys(4) framework will provide an entry for every
-    possible temperature sensor that a particular chip can support. GPIO support
-    is provided by gpio(4) framework and the pins can be
-    accessed with the gpioctl(8) command.

-
The EMC fan controllers are arranged as a set of registers. These
-    registers are accessed by a /dev device per attached chip. The program
-    emcfanctl(8) makes use of this device and allows all valid
-    registers for particular chip to be read or written and provides some higher
-    level commands that allow the drive level and frequency divider for a
-    particular fan to be adjusted.

-

-

-

-
The EMC2103-2, EMC2103-4, EMC2104 and EMC2106 chips have gpio
-    pins. For the EMC2103-2 and EMC2103-4, these pins are only gpio and are not
-    shared with any other function. For the EMC2104 and EMC2106, the following
-    is how the pins maps to the
-    altN flags in the
-    gpio(4) framework.

-

-
-  
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-  
-
PinALT0ALT1
GPIO1CLK_IN-
GPIO2TACH2-
GPIO3PWM2-
GPIO4OVERT2#PWM3
GPIO5OVERT3#PWM4
GPIO6--

-

-

-

-

-
The following sysctl(8) variables are
-  provided:

-

-  

-  
If the driver is compiled with EMCFAN_DEBUG, this
-      node will appear and can be used to set the debugging level.

-  

-  
For a number of the chips in the two chip families, the tachometer
-      calcuation algorithm needs to know the number of poles that the tachometer
-      has in order to calculate the RPM correctly. Usually this will be 2, but
-      if the situation is otherwise, set this node to the number of poles that
-      the particular fan has. The calculation is also effected by the number of
-      edges present in the tachometer signal. The number of edges is set with
-      the emcfanctl(8) command.

-  

-  
Many of the chips in the two famlies have a pin that can be used to drive
-      an alternative 32.767 kHz clock for the tachometers. The EMC2103-1,
-      EMC2103-2 and EMC2103-4 does not have this alternative clock pin, and
-      while it is likely that the chip is running at the default
-      32.000 kHz, it might not be. This variable lets one set an
-      alternative clock. The units for this node are in Hz.

-  

-  
The EMC2104 and EMC2106 have a special temperature sensor pin called VIN4,
-      if this sensor is wired up, then this variable can be set to 1 and
-      meaningful values will appear in the envsys(4)
-      framework.

-

-

-

-

-

-  
/dev/emcfanu

-  
The device unit u file.

-

-

-

-

-
emcfanctl(8), envsys(4),
-    iic(4), envstat(8),
-    sysctl(8)

-

-

-

-
The emcfan driver first appeared in
-    NetBSD 11.0.

-

-

-

-
The emcfan driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The driver does not support the EMC2105 chip.

-
While not exactly a bug, the driver does nothing with the alert
-    interrupts that can be generated from many of the chips. It would be more
-    typical for this to be tied to a GPIO pin which can interrupt using CPU
-    interrupts.

-

-

-
-  
-    
-    
-  
-
Feburary 19, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/emdtv.4 4.html b/static/netbsd/man4/emdtv.4 4.html
deleted file mode 100644
index 2788ace0..00000000
--- a/static/netbsd/man4/emdtv.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
EMDTV(4)Device Drivers ManualEMDTV(4)

-

-

-

-
emdtv — digital
-    video driver for Empia Technology EM28xx based cards

-

-

-

-
emdtv* at uhub?
-  

-  dtv* at dtvbus?

-

-

-

-
The emdtv driver provides support for
-    digital video cards based on the Empia Technology EM28xx series of DTV
-    interface chips (in particular, the EM2883). This chip is used in USB
-    products.

-
Supported cards include:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
ATI TV Wonder 600 USBlg3303(4)xc3028(4) (XC3028L)

-
The XC3028L digital tuner requires
-    firmware. This is provided by the
-    pkgsrc/sysutils/xc3028l-firmware package.

-

-

-

-
dtv(4), dtviic(4),
-    usb(4)

-

-

-

-
The emdtv device driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The emdtv driver was written by
-    Jared D. McNeill
-    ⟨jmcneill@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
August 30, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/emuxki.4 4.html b/static/netbsd/man4/emuxki.4 4.html
deleted file mode 100644
index f0cc02f7..00000000
--- a/static/netbsd/man4/emuxki.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
EMUXKI(4)Device Drivers ManualEMUXKI(4)

-

-

-

-
emuxki — Creative
-    Labs SBLive! and PCI 512 audio device driver

-

-

-

-
emuxki* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The emuxki device driver supports Creative
-    Sound Blaster Live! cards as well as the Sound Blaster PCI 512.

-
These Environmental Audio cards are based upon the programmable
-    EMU10K1 digital-processing chip.

-
Hardware features:

-
    
-  
  • E-mu Systems, Inc. EMU10K1 music synthesis engine
    • 
-  
  • 64-voice hardware polyphony with E-mu's patented 8-point interpolation
-      technology
    • 
-  
  • Up to 1024-voice polyphony with multi-timbre capability
    • 
-  
  • Support for real-time digital effects like reverb, chorus, flanger, pitch
-      shifter, or distortion across any audio source
    • 
-  
  • User-selectable settings are optimized for headphones, two or four
-      speakers
    • 
-  
  • Creative Multi Speaker Surround (CMSS) technology places any mono or
-      stereo source in a 360 degree audio space
    • 
-  
  • Processes sample rates from 5kHz to 48kHz
    • 
-  
  • Hardware full duplex support enables simultaneous record and playback at 8
-      standard sample rates
    • 
-  
  • Allows multiple audio sources playback on the same speaker system
    • 
-

-

-

-

-
ac97(4), audio(4),
-    joy(4), pci(4)

-

-

-

-
The emuxki device driver appeared in
-    NetBSD 1.5.3.

-

-

-

-
The emuxki driver was written by
-    Yannick Montulet
-    <yannick.montulet@epitech.net>.

-

-

-

-
Currently, this driver does not support multiple source recording,
-    MIDI nor the multi-voice capability.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/ena.4 4.html b/static/netbsd/man4/ena.4 4.html
deleted file mode 100644
index 32086269..00000000
--- a/static/netbsd/man4/ena.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
ENA(4)Device Drivers ManualENA(4)

-

-

-

-
ena — NetBSD
-    kernel driver for Elastic Network Adapter (ENA) family

-

-

-

-
ena* at pci? dev ? function ?

-

-

-

-
The ENA is a networking interface designed to make good use of
-    modern CPU features and system architectures.

-
The ENA device exposes a lightweight management interface with a
-    minimal set of memory mapped registers and extendable command set through an
-    Admin Queue.

-
The driver supports a range of ENA devices, is link-speed
-    independent (i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.),
-    and has a negotiated and extendable feature set.

-
Some ENA devices support SR-IOV. This driver is used for both the
-    SR-IOV Physical Function (PF) and Virtual Function (VF) devices.

-
The ENA devices enable high speed and low overhead network traffic
-    processing by providing multiple Tx/Rx queue pairs (the maximum number is
-    advertised by the device via the Admin Queue), a dedicated MSI-X interrupt
-    vector per Tx/Rx queue pair, and CPU cacheline optimized data placement.

-
The ena driver supports industry standard
-    TCP/IP offload features such as checksum offload and TCP transmit
-    segmentation offload (TSO). Receive-side scaling (RSS) is supported for
-    multi-core scaling.

-
The ena driver and its corresponding
-    devices implement health monitoring mechanisms such as watchdog, enabling
-    the device and driver to recover in a manner transparent to the application,
-    as well as debug logs.

-
Some of the ENA devices support a working mode called Low-latency
-    Queue (LLQ), which saves several more microseconds. This feature might be
-    implemented for the driver in future releases.

-

-

-

-
Supported PCI vendor ID/device IDs:

-

-
    
-  
  • 1d0f:0ec2 - ENA PF
    • 
-  
  • 1d0f:1ec2 - ENA PF with LLQ support
    • 
-  
  • 1d0f:ec20 - ENA VF
    • 
-  
  • 1d0f:ec21 - ENA VF with LLQ support
    • 
-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The ena driver was originally written by
-    Semihalf for FreeBSD. The
-    driver was ported to NetBSD by
-    Jared D. McNeill
-    <jmcneill@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 1, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/envsys.4 3.html b/static/netbsd/man4/envsys.4 3.html
deleted file mode 100644
index d0b213c1..00000000
--- a/static/netbsd/man4/envsys.4 3.html	
+++ /dev/null
@@ -1,403 +0,0 @@
-
-  
-    
-    
-    
-  
-
ENVSYS(4)Device Drivers ManualENVSYS(4)

-

-

-

-
envsys —
-    Environmental Systems framework (version 2)

-

-

-

-
#include
-    <sys/envsys.h>

-

-

-

-
The envsys framework provides support to
-    handle hardware monitor devices. Hardware monitoring chips are able to
-    report values from different types of sensors.

-
The envsys framework consists of two
-    parts:

-

-
    
-  
  1. the userland part, to receive the current sensor data and to set some
-      properties on sensors: envstat(8).
    2. 
-  
  2. The kernel part that is able to talk to the devices providing sensor data:
-      sysmon_envsys(9).
    3. 
-

-
The envsys framework uses
-    proplib(3) for communication between kernel and user
-    space. The following ioctl(2) types are available:

-

-  

-    (prop_dictionary_t)

-  

-    
This ioctl(2) is used to receive the global
-        dictionary that is being used in the kernel by the
-        sysmon_envsys(9) framework. It will contain an array
-        of dictionaries per device and one dictionary per sensor plus another
-        special dictionary that contains the properties for a device. Each
-        sensor dictionary will have its own characteristics and values.

-    
The following XML property list represents a virtual device
-        “device0” with one entry for sensor
-        “sensor0” and all available properties set on it, plus
-        another entry for the “device-properties” dictionary
-        (which contains specific properties for a device):

-    

-    
<key>device0</key>
-<array>
-	<dict>
-		<key>allow-rfact</key>
-		<true/>
-		<key>avg-value</key>
-		<integer>36400</integer>
-		<key>battery-capacity</key>
-		<string>NORMAL</string>
-		<key>critical-capacity</key>
-		<integer>21417</integer>
-		<key>critical-max</key>
-		<integer>343150000</integer>
-		<key>critical-min</key>
-		<integer>288150000</integer>
-		<key>cur-value</key>
-		<integer>406000</integer>
-		<key>description</key>
-		<string>CPU Temp</string>
-		<key>high-capacity</key>
-		<integer>21417</integer>
-		<key>index</key>
-		<string>sensor0</string>
-		<key>max-value</key>
-		<integer>3894000</integer>
-		<key>maximum-capacity</key>
-		<integer>21417</integer>
-		<key>min-value</key>
-		<integer>2894000</integer>
-		<key>monitoring-state-critical</key>
-		<true/>
-		<key>monitoring-state-critover</key>
-		<true/>
-		<key>monitoring-state-critunder</key>
-		<true/>
-		<key>monitoring-state-state-changed</key>
-		<true/>
-		<key>monitoring-state-warnover</key>
-		<true/>
-		<key>monitoring-state-warnunder</key>
-		<true/>
-		<key>monitoring-supported</key>
-		<true/>
-		<key>state</key>
-		<string>valid</string>
-		<key>type</key>
-		<string>Ampere hour</string>
-		<key>want-percentage</key>
-		<true/>
-		<key>warning-capacity</key>
-		<integer>19234</integer>
-		<key>warning-max</key>
-		<integer>323150000</integer>
-		<key>warning-min</key>
-		<integer>298150000</integer>
-	</dict>
-	<dict>
-		<key>device-properties</key>
-		<dict>
-			<key>refresh-timeout</key>
-			<integer>0xa</integer>
-		</dict>
-	</dict>
-</array>

-    

-    
Let's explain some more about those objects:

-    

-      
allow-rfact

-      
Set to true means that the sensor is able to change
-          the resistor factor, only used in Voltage sensors.

-      
avg-value

-      
Current average value in the sensor.

-      
battery-capacity

-      
Current capacity state for a battery capacity sensor.

-      
critical-capacity

-      
Critical capacity set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2). Only available on sensors with the
-          want-percentage object enabled.

-      
critical-max

-      
Critical max limit set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2).

-      
critical-min

-      
Critical min limit set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2).

-      
cur-value

-      
Current value in the sensor.

-      
description

-      
Description of the sensor.

-      
high-capacity

-      
High capacity set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2). Only available on sensors with the
-          want-percentage object enabled. Used to monitor
-          possible over-charging of batteries.

-      
index

-      
Index position of the sensor.

-      
max-value

-      
Current max value in the sensor.

-      
maximum-capacity

-      
Maximum capacity set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2). Only available on sensors with the
-          want-percentage object enabled. Used to monitor
-          possible over-charging of batteries.

-      
min-value

-      
Current min value in the sensor.

-      
monitoring-state-critical

-      
If true, the device has enabled the flag to monitor a critical
-        state.

-      
monitoring-state-hw-range-limits

-      
If true, the device has enabled the flag to monitor warning or
-          critical limits.

-      
monitoring-state-state-changed

-      
If true, the device has enabled the flag to monitor for state changes
-          in a drive or Battery state sensor.

-      
monitoring-supported

-      
If true, critical/warning capacity/max/min limits may be set by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2).

-      
state

-      
Current state in the sensor.

-      
type

-      
Type of unit in the sensor.

-      
want-percentage

-      
If true,
-          
-          and
-          
-          are valid and a percentage may be computed from them.

-      
warning-capacity

-      
Warning capacity set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2). Only available on sensors with the
-          want-percentage object enabled.

-      
warning-max

-      
Warning max limit set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2).

-      
warning-min

-      
Warning min limit set previously by the
-          ENVSYS_SETDICTIONARY
-          ioctl(2).

-    

-  

-  

-    (prop_dictionary_t)

-  

-    
This ioctl(2) is used to remove all
-        properties that are currently set via the
-        ENVSYS_SETDICTIONARY ioctl. The values will be
-        set to defaults, the ones that the device uses.

-    
Only one object is allowed on this dictionary:

-    

-    
<key>envsys-remove-props</key>
-<true/>

-    

-    
It is a boolean object and must be set to
-        true to be effective.

-  

-  

-    (prop_dictionary_t)

-  
This ioctl(2) is used to send a dictionary with new
-      properties that should be processed by the envsys
-      framework. Only a set of predefined keywords are recognized by the kernel
-      part. The following is the property list representation of a dictionary
-      with all recognized and required keywords that a sensor understands:
-    

-    
<dict>
-	<key>description</key>
-	<string>cpu temp</string>
-	<key>rfact</key>
-	<integer>56000</integer>
-	<key>critical-capacity</key>
-	<integer>10</integer>
-	<key>critical-max</key>
-	<integer>3400</integer>
-	<key>critical-min</key>
-	<integer>2800</integer>
-	<key>high-capacity</key>
-	<integer>95</integer>
-	<key>maximum-capacity</key>
-	<integer>100</integer>
-	<key>warning-capacity</key>
-	<integer>15</integer>
-	<key>warning-max</key>
-	<integer>3200</integer>
-	<key>warning-min</key>
-	<integer>2900</integer>
-</dict>

-    

-    
Also if some properties in a device need to be changed, the
-        “device-properties” dictionary must be used. At this
-        moment only the “refresh-timeout” property is understood.
-        This has the following structure:

-    

-    
<dict>
-	<key>device-properties</key>
-	<dict>
-		<key>refresh-timeout</key>
-		<integer>0xa</integer>
-	</dict>
-</dict>

-    

-    
A dictionary sent to the kernel with this
-        ioctl(2) should have the following structure:

-    

-    
<dict>
-	<key>device_name</key>
-	<array>
-		<dict>
-			<key>index</key>
-			<string>sensor0</string>
-			<key>description</key>
-			<string>cpu temp</string>
-			...
-			Another property for this sensor
-			...
-		</dict>
-		...
-		Another dictionary for device-properties or sensor
-		...
-	</array>
-	...
-	Another device as above
-	...
-</dict>

-    

-    
The named device will be an array and will contain
-        dictionaries, any dictionary needs to have the
-         object
-        specifying the sensor that is required for the new properties.

-    
If an unknown object was sent with the dictionary,
-        EINVAL will be returned, or if the sensor does
-        not support changing rfact (voltage sensors) or
-        critical/warning/capacity limits, ENOTSUP will
-        be returned.

-  

-

-
Additionally, the following ioctl(2) commands
-    are provided for compatibility purposes for applications written against the
-    original experimental envsys API available between
-    NetBSD 1.5 and NetBSD 4.0;
-    they have been deprecated since NetBSD 5.0, and may
-    be removed at any time:

-

-  

-    (envsys_tre_data_t)

-  
 

-  

-    (envsys_basic_info_t)

-  
 

-

-

-

-

-
When setting a critical/warning max or min limit with the
-    ENVSYS_SETDICTIONARY ioctl(2), the
-    user must be aware that sysmon_envsys(9) expects to have a
-    proper unit, so the value must be converted. Please see
-    sysmon_envsys(9) for more information.

-
Also when setting a critical or warning capacity limit,
-    the formula to send a proper value to sysmon_envsys(9) is
-    the following: . The max value is available in the
-    sensor's dictionary.

-

-

-

-
The following example shows how to change the description of
-    ‘sensor0’ in the
-    ‘aibs0’ device with the
-    ENVSYS_SETDICTIONARY ioctl(2):

-

-
int
-main(void)
-{
-	prop_dictionary_t global_dict, sensor_dict;
-	prop_array_t array;
-	prop_object_t obj;
-	int fd, error;
-
-	global_dict = prop_dictionary_create();
-	sensor_dict = prop_dictionary_create();
-	array = prop_array_create();
-
-	if (!prop_dictionary_set(global_dict, "aibs0", array))
-		err(EINVAL, "prop_dictionary_set global");
-
-	obj = prop_string_create_nocopy("sensor0");
-	if (obj == NULL ||
-	    !prop_dictionary_set(sensor_dict, "index", obj))
-		err(EINVAL, "sensor index");
-
-	prop_object_release(obj);
-
-	/* new description */
-	obj = prop_string_create_cstring_nocopy("CPU core voltage");
-	if (obj == NULL ||
-	    !prop_dictionary_set(sensor_dict, "description", obj))
-		err(EINVAL, "new description");
-
-	prop_object_release(obj);
-
-	if (!prop_array_add(array, sensor_dict))
-		err(EINVAL, "prop_array_add");
-
-	if ((fd = open(_PATH_SYSMON, O_RDWR)) == -1)
-		err(EXIT_FAILURE, "open");
-
-	/* we are done, send the dictionary */
-	error = prop_dictionary_send_ioctl(global_dict,
-					   fd,
-					   ENVSYS_SETDICTIONARY);
-	prop_object_release(array);
-	prop_object_release(sensor_dict);
-	prop_object_release(global_dict);
-	(void)close(fd);
-	return error;
-}

-

-

-

-

-
envsys.conf(5), envstat(8),
-    powerd(8), sysmon_envsys(9)

-

-

-

-
The first envsys framework first appeared in
-    NetBSD 1.5. The envsys 2 framework
-    first appeared in NetBSD 5.0.

-

-

-

-
The (current) envsys 2 framework was implemented
-    by Juan Romero Pardines. Additional input on the
-    design was provided by many NetBSD developers around
-    the world.

-
The first envsys framework was implemented by
-    Jason R. Thorpe, Tim Rightnour, and Bill Squier.

-

-

-
-  
-    
-    
-  
-
May 4, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/ep.4 3.html b/static/netbsd/man4/ep.4 3.html
deleted file mode 100644
index 42c8f129..00000000
--- a/static/netbsd/man4/ep.4 3.html	
+++ /dev/null
@@ -1,164 +0,0 @@
-
-  
-    
-    
-    
-  
-
EP(4)Device Drivers ManualEP(4)

-

-

-

-
ep — driver for
-    3Com EtherLink III Ethernet interfaces

-

-

-

-
ep0 at isa? port ? irq ?
-  

-  ep* at isapnp?
-  

-  ep* at eisa? slot ?
-  

-  ep* at mca? slot ?
-  

-  ep* at pci? dev ? function ?
-  

-  ep* at pcmcia? function ?

-

-

-

-
The ep device driver supports the 3Com
-    EtherLink III family of Ethernet cards.

-
The 3c515 is an ISA 10/100 card with DMA capability. The chipset
-    is similar to that of the 3c905, with some changes to make it work with the
-    more limited ISA bus address space. This card is supported, although DMA is
-    not used.

-
The EISA and PCI 3c59x devices use an older DMA engine which is
-    not capable of multi-segment DMA. DMA on these devices is not used.

-
The 3c529 is a MCA device, and doesn't support DMA.

-
The PCI 3c90x devices have multi-segment DMA capability, which is
-    not supported by the ep driver. To use the DMA
-    capabilities of these cards, the ex(4) driver must be
-    used.

-
The PCI 3c90xB devices are not supported by the
-    ep driver, as they do not include support for
-    programmed I/O. These devices are supported by the ex(4)
-    driver.

-
The 3c575 is a CardBus device, and is supported by
-    ex(4) driver.

-

-

-

-
There are 3 main chipset classes supported by the
-    ep driver. Each has their own media selection
-    capabilities.

-
The first class is the “3c509” class. This includes
-    the 3c509, 3c509B, 3c529, 3c579, 3c562, and 3c589. These devices can support
-    10BASE-T, 10BASE2, and 10BASE5. Available media will be displayed when the
-    device is found by the kernel.

-
The second class is the “Vortex” class. This
-    includes the 3c592, 3c579, 3c590, and 3c595. This class also includes the
-    3c900-TPO and 3c900-COMBO; they use the “Boomerang” chipset,
-    but use Vortex-style media selection. These devices have many different
-    media types varying by model. Some models have an external MII connector for
-    connecting an external PHY. This is supported by means of the
-    “manual” media type. Available media will be displayed when
-    the device is found by the kernel.

-
The third class is the “Boomerang” class. This
-    includes the 3c515, 3c905, and 3c574. These devices support media selection
-    via MII. The 3c515 and 3c905 have an nsphy(4), and the
-    3c574 has a tqphy(4), for this purpose. See
-    ifmedia(4) and mii(4) for more
-    information.

-

-

-

-
Supported cards include:

-

-

-  
3c509

-  
ISA 10Mbps card, in BNC and multiport variants

-  
3c509B

-  
ISA Plug-and-Play 10Mbps card, in BNC and multiport variants

-  
3c515

-  
ISA Plug-and-Play 10/100 card with UTP

-  
3c529

-  
MCA 10Mbps card, in UTP+AUI and BNC+AUI variants

-  
3c556B

-  
PCMCIA 56K modem-10/100Mbps Ethernet combo card with dongle

-  
3c562

-  
PCMCIA modem-10Mbps Ethernet combo card with dongle

-  
3c572B

-  
OfficeConnect. Same as 3c574, but with newer revision of
-      tqphy(4)

-  
3c574

-  
PCMCIA 10/100Mbps card with dongle

-  
3c579

-  
EISA 10Mbps card, in UTP, BNC, and multiport variants

-  
3c589

-  
PCMCIA 10Mbps card with dongle

-  
3c590

-  
PCI 10Mbps multiport card with DMA capability

-  
3c592

-  
EISA 10Mbps card with DMA capability

-  
3c595

-  
PCI 10/100Mbps with different media options and DMA capability

-  
3c597

-  
EISA 10/100Mbps card with DMA capability

-  
3c900

-  
PCI 10Mbps card in 10BASE-T and multiport variants with DMA
-    capability

-  
3c905

-  
PCI 10/100Mbps card in 10BASE-T, multiport, and fast variants with DMA
-      capability

-

-

-

-

-

-
EtherLink III cards have no jumpers to set the address. 3Com
-    supplies software to set the address of the card in software. To find the
-    card on the ISA bus, the kernel performs a complex scan operation at IO
-    address 0x100.
-    !
-    Avoid placing other cards at that address!

-
The 3Com configuration utilities can `autosense' the active media
-    and save it as default. The saved default medium is the medium that was
-    active at the time the configuration utility was run. The
-    ep driver does not yet re-autosense the active media
-    at boot time. If the EEPROM autosense bit is set, the driver simply uses the
-    media type sensed and saved when the configuration utility was run.

-

-

-

-

-  
ep0: reset (status: %x)

-  
The driver has encountered a FIFO underrun or overrun. The driver will
-      reset the card and the packet will be lost. This is not fatal.

-  
ep0: eeprom failed to come ready

-  
The EEPROM failed to come ready. This probably means the card is
-    wedged.

-  
ep0: 3c509 in test mode. Erase pencil mark!

-  
This means that someone has scribbled with pencil in the test area on the
-      card. Erase the pencil mark and reboot. (This is not a joke.)

-

-

-

-

-
eisa(4), ex(4),
-    ifmedia(4), intro(4),
-    isa(4), isapnp(4),
-    mca(4), mii(4),
-    nsphy(4), pci(4),
-    pcmcia(4), tqphy(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
October 11, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/epic.4 4.html b/static/netbsd/man4/epic.4 4.html
deleted file mode 100644
index dd9d0d84..00000000
--- a/static/netbsd/man4/epic.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
EPIC(4)Device Drivers ManualEPIC(4)

-

-

-

-
epic — SMC83C170
-    (EPIC/100) Ethernet driver

-

-

-

-
epic* at pci? dev ? function ?

-

-

-

-
The epic driver supports network adapters
-    based on the Standard Microsystems Corp. 83C170 Ethernet PCI Integrated
-    Controller (EPIC/100).

-

-

-

-
ifmedia(4), intro(4),
-    pci(4), ifconfig(8)

-
SMC Networks

-

-

-

-
The epic driver appeared in
-    NetBSD 1.4.

-

-

-

-
Jason R. Thorpe

-

-

-
-  
-    
-    
-  
-
June 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/eqos.4 4.html b/static/netbsd/man4/eqos.4 4.html
deleted file mode 100644
index 2e950c83..00000000
--- a/static/netbsd/man4/eqos.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
EQOS(4)Device Drivers ManualEQOS(4)

-

-

-

-
eqos — DesignWare
-    Ethernet Quality-of-Service controller

-

-

-

-
eqos* at acpi?
-  

-  eqos* at pci?

-

-

-

-
The eqos driver provides support for the
-    DesignWare Ethernet Quality-of-Service controller, which supports 10baseT,
-    100baseT, 1000baseT, and 2500baseT modes of operation.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    ifconfig(8)

-

-

-

-
The eqos device driver was written by
-    Jared D. McNeill. It first appeared in
-    NetBSD 10.0.

-

-

-
-  
-    
-    
-  
-
October 20, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/esa.4 4.html b/static/netbsd/man4/esa.4 4.html
deleted file mode 100644
index 8a19a7e8..00000000
--- a/static/netbsd/man4/esa.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
ESA(4)Device Drivers ManualESA(4)

-

-

-

-
esa — ESS
-    Technology Allegro-1 / Maestro-3 family audio device driver

-

-

-

-
esa* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  options ESA_NUM_VOICES=4

-

-

-

-
The esa driver provides support for the
-    ESS Allegro-1 and Maestro-3 audio devices on the PCI bus. These devices are
-    popular in laptop systems.

-
The Allegro-1 and the Maestro-3 are full-duplex devices that allow
-    independent playback and recording at sample rates between 8000Hz and
-    48000Hz and are capable of playback at 8 and 16 bit in mono and stereo.

-
Setting options ESA_NUM_VOICES=4 allows for hardware mixing in the
-    device driver. Note that due to microcode constraints, the
-    esa driver is currently limited to 4 simultaneous
-    voices.

-

-

-

-
ac97(4), audio(4),
-    pci(4)

-

-

-

-
The esa device driver appeared in
-    NetBSD 1.5.3.

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-
-  
-    
-    
-  
-
May 13, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/esiop.4 4.html b/static/netbsd/man4/esiop.4 4.html
deleted file mode 100644
index dd7b3629..00000000
--- a/static/netbsd/man4/esiop.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
ESIOP(4)Device Drivers ManualESIOP(4)

-

-

-

-
esiop — Enhanced
-    Symbios Logic/NCR 53c8xx SCSI driver

-

-

-

-
esiop* at pci? dev ? function ?
-  

-  options SIOP_SYMLED
-  

-  scsibus* at esiop?

-

-

-

-
The esiop driver provides improved support
-    over siop(4) for the Symbios Logic/NCR 53x8xx series of
-    SCSI controller chips:

-

-
    
-  
  • 53c825 and 53c825a (Fast-Wide SCSI)
    • 
-  
  • 53c875 and 53c875j (Ultra-Wide SCSI)
    • 
-  
  • 53c876 (Dual Ultra-Wide SCSI)
    • 
-  
  • 53c885 (Ultra-Wide SCSI and Ethernet)
    • 
-  
  • 53c895 (Ultra2-Wide SCSI)
    • 
-  
  • 53c896 (PCI 64bit, dual Ultra2-Wide SCSI)
    • 
-  
  • 53c1010-33 (PCI 64bit, dual Ultra160 SCSI)
    • 
-  
  • 53c1510d (PCI 64bit, dual Ultra2-wide SCSI)
    • 
-

-Older adapters are supported by the siop(4) driver.
-
The SIOP_SYMLED option causes the driver to report SCSI activity
-    on the GPIO pin 1, which is connected to the activity LED on some adapters.
-    At this time only the 53c895 based Symbios and Tekram adapters are known to
-    require this.

-

-

-

-
cd(4), ch(4),
-    intro(4), pci(4),
-    scsi(4), sd(4),
-    siop(4), st(4),
-  uk(4)

-

-

-

-
The esiop driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The esiop driver was written by Manuel
-    Bouyer ⟨Manuel.Bouyer@lip6.fr⟩ for
-    NetBSD.

-

-

-
-  
-    
-    
-  
-
April 23, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/esm.4 4.html b/static/netbsd/man4/esm.4 4.html
deleted file mode 100644
index 55ded369..00000000
--- a/static/netbsd/man4/esm.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
ESM(4)Device Drivers ManualESM(4)

-

-

-

-
esm — ESS
-    Technology Maestro 2/2E PCI Audio Accelerator audio device driver

-

-

-

-
esm* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The esm device driver supports sound cards
-    based on ESS Technology Maestro, Maestro-2, and Maestro-2E PCI AC97 Audio
-    Accelerator chips (ES1968 and ES1978). Due to their power management
-    capabilities, the Maestro chips are often used in laptop and notebook
-    systems.

-
The Maestro is a full-duplex device that allows independent
-    playback and recording at sample rates between 4000 Hz and 48 kHz. The sound
-    processor is capable of handling and converting 8 and 16 bit mono and stereo
-    data.

-

-

-

-
ac97(4), audio(4),
-    joy(4), mpu(4),
-  pci(4)

-

-

-

-
The esm device driver appeared in
-    NetBSD 1.6.

-

-

-

-
Currently, this driver only supports 16-bit mono recording; an
-    unknown bug causes stereo recording to miss a channel. Also not supported
-    yet are hardware volume settings, MIDI, and joystick input.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/eso.4 4.html b/static/netbsd/man4/eso.4 4.html
deleted file mode 100644
index 91d74b8f..00000000
--- a/static/netbsd/man4/eso.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
ESO(4)Device Drivers ManualESO(4)

-

-

-

-
eso — ESS
-    Technology Solo-1 PCI AudioDrive audio device driver

-

-

-

-
eso* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  joy* at eso?
-  

-  mpu* at eso?
-  

-  opl* at eso?

-

-

-

-
The eso device driver supports sound cards
-    based on ESS Technology Solo-1 PCI AudioDrive chips (ES1938 and ES1946),
-    e.g. the TerraTec 128i PCI card.

-

-

-

-

-  
eso0: can't map Audio 1 DMA into I/O space

-  
PCI autoconfiguration did not map the first audio channel DMA controller
-      into I/O space at a suitable address, and the driver was not able map it
-      by itself. In that case only playback functionality will be
-    available.

-  
eso0: reset timeout

-  
The device failed to acknowledge being reset.

-  
eso0: RDR timeout

-  
The driver timed out reading data from a controller register.

-  
eso0: WDR timeout

-  
The driver timed out waiting to send a command or writing to a controller
-      register.

-

-

-

-

-
audio(4), joy(4),
-    mpu(4), opl(4),
-  pci(4)

-

-

-

-
The eso device driver appeared in
-    NetBSD 1.5. The on-board gameport was first
-    supported in NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/esp.4 4.html b/static/netbsd/man4/esp.4 4.html
deleted file mode 100644
index 7871651b..00000000
--- a/static/netbsd/man4/esp.4 4.html	
+++ /dev/null
@@ -1,113 +0,0 @@
-
-  
-    
-    
-    
-  
-
ESP(4)Device Drivers ManualESP(4)

-

-

-

-
esp — NCR 53C9x,
-    Emulex ESP406, and Qlogic FAS408 SCSI driver

-

-

-

-

-

-
esp0 at isa? port 0x230 irq ?

-

-

-

-
esp* at pcmcia? function ?

-

-

-

-
esp* at mca? slot ?

-

-

-

-
esp0 at obio?
-  

-  esp1 at obio?

-

-

-

-
esp0 at obio0 flags 0x00ff

-

-

-

-
esp0 at obio0 addr 0x66000000 ipl 2 flags
-    0xff0f

-

-

-

-
dma0 at obio0 addr 0xfa001000 level 4 (Sun
-    4/300)
-  

-  esp0 at obio0 addr 0xfa000000 level 4 (Sun 4/300)

-

-  

-  dma0 at sbus0 slot ? offset ? (sun4c and sun4m)
-  

-  esp0 at sbus0 slot ? offset ? (sun4c)
-  

-  esp0 at dma0 (sun4m)

-

-  

-  dma* at sbus? slot ? offset ? (Sbus)
-  

-  esp* at sbus? slot ? offset ? (SBus, older PROMs)
-  

-  esp* at dma? (SBus)

-

-  

-  scsibus* at esp?

-

-

-

-

-
The esp driver provides support for the
-    NCR 53C90, 53C94 and 53C96; Emulex ESP100, ESP100A, ESP200 and ESP406; and
-    Qlogic FAS216 and FAS408 SCSI controller chips found in a wide variety of
-    systems and peripheral boards. This includes the Qlogic ISA and VLB SCSI
-    host adapters, and the Sun Fast SCSI buffered Ethernet for Sbus (FSBE/S,
-    X1053A, Sun part # 501-2015).

-
For Qlogic PCI SCSI host adapters, use the
-    isp(4) device.

-

-

-

-
The esp driver supports the following
-    
-    for use in config(1) files:

-

-

-  
bits 0-7:

-  
disable disconnect/reselect for the corresponding SCSI target

-  
bits 8-15:

-  
disable synchronous negotiation for the corresponding SCSI target

-  
bits 16-23:

-  
disable tagged queuing for the corresponding SCSI target

-

-
"Target" is synonymous with SCSI ID number.

-
Note that SCSI tape drives should be allowed to perform
-    disconnect/reselect or performance will suffer.

-

-

-

-
cd(4), ch(4),
-    intro(4), le(4),
-    mca(4), pcmcia(4),
-    scsi(4), sd(4), ss(4),
-    st(4), uk(4)

-

-

-
-  
-    
-    
-  
-
December 3, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ess.4 4.html b/static/netbsd/man4/ess.4 4.html
deleted file mode 100644
index b4821e4a..00000000
--- a/static/netbsd/man4/ess.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
ESS(4)Device Drivers ManualESS(4)

-

-

-

-
ess — ESS
-    Technology AudioDrive family audio device driver

-

-

-

-
ess* at isapnp?
-  

-  ess* at pnpbios? index ?
-  

-  ess* at ofisa?
-  

-  audio* at audiobus?
-  

-  opl* at ess?

-

-

-

-
The ess driver provides support for the
-    ESS 1788, 1888, 1887, and 888 AudioDrive audio devices.

-
The AudioDrive 1788 is a half-duplex device, while the 1888, 1887,
-    and 888 are full-duplex. All are capable of 8- and 16-bit audio sample
-    recording and playback at rates up to 44.1kHz.

-
The AudioDrive takes 16 I/O ports. The I/O port range, IRQ, and
-    DRQ channels are set by the driver to the values specified in the
-    configuration file (or for isapnp, pnpbios, or ofisa, the values assigned
-    from the firmware). The I/O port base must be one of 0x220, 0x230, 0x240,
-    0x250. The IRQ must be one of 5, 7, 9, 10 (or 15 on the 1887 only). The
-    first DRQ channel must be selected from 0, 1, 3. The second DRQ channel
-    (used for playback by the full-duplex 1888/1887, ignored by the 1788) can
-    additionally be set to 5. If both DRQ channels are used they must be
-    different.

-
The joystick interface (if enabled) is handled by the
-    joy(4) driver.

-

-

-

-
audio(4), isapnp(4),
-    joy(4), ofisa(4),
-    opl(4), i386/pnpbios(4)

-

-

-

-
The ess device driver appeared in
-    NetBSD 1.4.

-

-

-

-
The AudioDrive devices have a SoundBlaster compatibility mode, and
-    may be detected by the SoundBlaster driver (see sb(4))
-    rather than the AudioDrive driver. The workaround is to remove the
-    SoundBlaster driver from the kernel configuration.

-

-

-
-  
-    
-    
-  
-
August 25, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/et.4 4.html b/static/netbsd/man4/et.4 4.html
deleted file mode 100644
index 919c0469..00000000
--- a/static/netbsd/man4/et.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
ET(4)Device Drivers ManualET(4)

-

-

-

-
et — Agere/LSI
-    ET1310/ET1301 10/100/Gigabit Ethernet device

-

-

-

-
et* at pci? dev ? function ?
-  

-  etphy* at mii? phy ?

-

-

-

-
The et driver supports PCI Express
-    Ethernet adapters based on the Agere/LSI ET1310/ET1301 integrated
-  MAC/PHY.

-
The following media types are supported:

-

-

-  

-  
Enable autoselection of the media type and options.

-  

-  
Set 10Mbps operation.

-  

-  
Set 100Mbps (Fast Ethernet) operation.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation (ET1310 only).

-

-

-

-

-
arp(4), etphy(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    ifconfig.if(5), ifconfig(8)

-

-

-

-
The et device driver first appeared in
-    OpenBSD 4.3. It was added to NetBSD
-    6.0.

-

-

-

-
The et driver was written by
-    Sepherosa Ziehau for DragonFlyBSD, ported to
-    OpenBSD by Jonathan Gray
-    ⟨jsg@openbsd.org⟩, and subsequently ported to
-    NetBSD by Kaspar Brand.

-

-

-
-  
-    
-    
-  
-
October 13, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/etphy.4 4.html b/static/netbsd/man4/etphy.4 4.html
deleted file mode 100644
index b1de2462..00000000
--- a/static/netbsd/man4/etphy.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
ETPHY(4)Device Drivers ManualETPHY(4)

-

-

-

-
etphy — Agere/LSI
-    ET1011 TruePHY Gigabit Ethernet PHY

-

-

-

-
etphy* at mii? phy ?

-

-

-

-
The etphy driver supports the Agere/LSI
-    ET1011 TruePHY 10/100/1000 Ethernet PHYs including the integrated TruePHY in
-    ET1310/ET1301 based adapters.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-

-
The etphy device driver first appeared in
-    OpenBSD 4.3. It was added to NetBSD
-    6.0.

-

-

-

-
The etphy driver was written by
-    Sepherosa Ziehau for DragonFlyBSD, ported to
-    OpenBSD by Jonathan Gray
-    ⟨jsg@openbsd.org⟩, and subsequently ported to
-    NetBSD by Kaspar Brand.

-

-

-
-  
-    
-    
-  
-
October 13, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/ex.4 4.html b/static/netbsd/man4/ex.4 4.html
deleted file mode 100644
index 20ae6817..00000000
--- a/static/netbsd/man4/ex.4 4.html	
+++ /dev/null
@@ -1,153 +0,0 @@
-
-  
-    
-    
-    
-  
-
EX(4)Device Drivers ManualEX(4)

-

-

-

-
ex — driver for
-    3Com Fast EtherLink XL (3c900, 3c905, 3c980) and similar PCI bus and cardbus
-    Ethernet interfaces

-

-

-

-
ex* at cardbus? function ?
-  

-  ex* at pci? dev ? function ?

-

-

-

-
3Com Ethernet and Fast Ethernet cards supported by the
-    ex driver include:

-

-

-  
3c450-TX

-  
10/100 Ethernet

-  
3c555

-  
MiniPCI 10/100 Ethernet

-  
3c575-TX

-  
Ethernet

-  
3c575B-TX

-  
Ethernet

-  
3c575CT

-  
Ethernet

-  
3c656

-  
MiniPCI 10/100 Ethernet

-  
3c656B

-  
MiniPCI 10/100 Ethernet

-  
3c656C

-  
MiniPCI 10/100 Ethernet

-  
3c900-TPO

-  
Ethernet

-  
3c900-COMBO

-  
Ethernet

-  
3c900B-TPC

-  
Ethernet

-  
3c900B-TPO

-  
Ethernet

-  
3c900B-COMBO

-  
Ethernet

-  
3c905-T4

-  
10/100 Ethernet

-  
3c905-TX

-  
10/100 Ethernet

-  
3c905B-COMBO

-  
10/100 Ethernet

-  
3c905B-FX

-  
10/100 Ethernet

-  
3c905B-T4

-  
10/100 Ethernet

-  
3c905B-TX

-  
10/100 Ethernet

-  
3c905CX-TX

-  
10/100 Ethernet

-  
3c980

-  
Server Adapter 10/100 Ethernet

-  
3c980C-TXM

-  
10/100 Ethernet

-  
3cSOHO100-TX

-  
10/100 Ethernet

-

-
All versions of the EtherLink XL (except the older 3c900 and
-    3c905) support IPv4/TCP/UDP checksumming in hardware. The
-    ex driver supports this feature of the chip. See
-    ifconfig(8) for information on how to enable this
-  feature.

-

-

-

-
Some of these network interfaces support the Media Independent
-    Interface (MII), a bus which can have at least one arbitrary Physical
-    interface (PHY) chip on it. NetBSD supports MII and
-    has separate drivers for many different PHY chips, including
-    ukphy(4), a generic PHY driver that can support many PHY
-    chips that NetBSD does not yet have a specific
-    driver for.

-
Support for the PHY found on a given NIC must be configured into a
-    NetBSD kernel config(1) for this
-    driver to work properly in those cases.

-
See ifmedia(4), and
-  mii(4).

-

-

-

-

-  
%s: adapter failure (%x)

-  

-  
%s: can't allocate download descriptors, error = %d

-  

-  
%s: can't allocate or map rx buffers

-  

-  
%s: can't allocate upload descriptors, error = %d

-  

-  
%s: can't create download desc. DMA map, error = %d

-  

-  
%s: can't create rx DMA map %d, error = %d

-  

-  
%s: can't create tx DMA map %d, error = %d

-  

-  
%s: can't create upload desc. DMA map, error = %d

-  

-  
%s: can't load download desc. DMA map, error = %d

-  

-  
%s: can't load mbuf chain, error = %d

-  

-  
%s: can't load rx buffer, error = %d

-  

-  
%s: can't load upload desc. DMA map, error = %d

-  

-  
%s: can't map download descriptors, error = %d

-  

-  
%s: can't map upload descriptors, error = %d

-  

-  
%s: fifo underrun (%x) @%d

-  

-  
%s: jabber (%x)

-  

-  
%s: receive stalled

-  

-  
%s: too many segments, 

-  

-  
%s: uplistptr was 0

-  
host too slow to serve incoming packets

-

-

-

-

-
cardbus(4), exphy(4),
-    ifmedia(4), intro(4),
-    mii(4), pci(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
October 30, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/exphy.4 4.html b/static/netbsd/man4/exphy.4 4.html
deleted file mode 100644
index e243b2cc..00000000
--- a/static/netbsd/man4/exphy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
EXPHY(4)Device Drivers ManualEXPHY(4)

-

-

-

-
exphy — Driver for
-    3Com 3c905B-TX internal Ethernet PHY

-

-

-

-
exphy* at mii? phy ?

-

-

-

-
The exphy driver supports the internal PHY
-    on 3Com 3c905B-TX 10/100 Ethernet interfaces.

-

-

-

-
ex(4), ifmedia(4),
-    intro(4), mii(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 3, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/faith.4 3.html b/static/netbsd/man4/faith.4 3.html
deleted file mode 100644
index b95eb50c..00000000
--- a/static/netbsd/man4/faith.4 3.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
FAITH(4)Device Drivers ManualFAITH(4)

-

-

-

-
faith —
-    IPv6-to-IPv4 TCP relay capturing interface

-

-

-

-
pseudo-device faith

-

-

-

-
The faith interface captures IPv6 TCP
-    traffic, for implementing userland IPv6-to-IPv4 TCP relay like
-    faithd(8).

-
faith interfaces are dynamically created
-    and destroyed with the ifconfig(8)
-    create and destroy
-    subcommands.

-
Special action will be taken when IPv6 TCP traffic is seen on a
-    router, and the routing table suggests to route it to the
-    faith interface. In this case, the packet will be
-    accepted by the router, regardless of the list of IPv6 interface addresses
-    assigned to the router. The packet will be captured by an IPv6 TCP socket,
-    if it has the IN6P_FAITH flag turned on and matching
-    address/port pairs. As a result, faith will let you
-    capture IPv6 TCP traffic to some specific destination addresses. Userland
-    programs, such as faithd(8) can use this behavior to relay
-    IPv6 TCP traffic to IPv4 TCP traffic. The program can accept some specific
-    IPv6 TCP traffic, perform getsockname(2) to get the IPv6
-    destination address specified by the client, and perform
-    application-specific address mapping to relay IPv6 TCP to IPv4 TCP.

-
IN6P_FAITH flag on an IPv6 TCP socket can
-    be set by using setsockopt(2), with level
-    IPPROTO_IPV6 and optname
-    IPv6_FAITH.

-
To handle error reports by ICMPv6, some ICMPv6 packets routed to
-    an faith interface will be delivered to IPv6 TCP, as
-    well.

-
To understand how faith can be used, take
-    a look at the source code of faithd(8).

-
As the faith interface implements
-    potentially dangerous operations, great care must be taken when configuring
-    it. To avoid possible misuse, the sysctl(8) variable
-    net.inet6.ip6.keepfaith must be set to
-    1 prior to using the interface. When
-    net.inet6.ip6.keepfaith is
-    0, no packets will be captured by the
-    faith interface.

-
The faith interface is intended to be used
-    on routers, not on hosts.

-

-

-

-
inet(4), inet6(4),
-    faithd(8)

-
Jun-ichiro itojun Hagino
-    and Kazu Yamamoto, An
-    IPv6-to-IPv4 transport relay translator, RFC 3142,
-    ftp://ftp.isi.edu/in-notes/rfc3142.txt,
-    June 2001.

-

-

-

-
The FAITH IPv6-to-IPv4 TCP relay translator first appeared in the
-    WIDE hydrangea IPv6 stack.

-

-

-
-  
-    
-    
-  
-
January 9, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/fd.4 4.html b/static/netbsd/man4/fd.4 4.html
deleted file mode 100644
index e5b94b7f..00000000
--- a/static/netbsd/man4/fd.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
FD(4)Device Drivers ManualFD(4)

-

-

-

-
fd, stdin,
-    stdout, stderr —
-    file descriptor files

-

-

-

-
The files /dev/fd/0 through
-    /dev/fd/# refer to file descriptors which can be
-    accessed through the file system. If the file descriptor is open and the
-    mode the file is being opened with is a subset of the mode of the existing
-    descriptor, the call:

-

-
fd = open("/dev/fd/0", mode);

-

-
and the call:

-

-
fd = fcntl(0, F_DUPFD, 0);

-

-
are equivalent.

-
Opening the files /dev/stdin,
-    /dev/stdout and /dev/stderr
-    is equivalent to the following calls:

-

-
fd = fcntl(STDIN_FILENO,  F_DUPFD, 0);
-fd = fcntl(STDOUT_FILENO, F_DUPFD, 0);
-fd = fcntl(STDERR_FILENO, F_DUPFD, 0);

-

-
Flags to the open(2) call other than
-    O_RDONLY, O_WRONLY and
-    O_RDWR are ignored.

-

-

-

-

-  
/dev/fd/#

-  
 

-  
/dev/stdin

-  
 

-  
/dev/stdout

-  
 

-  
/dev/stderr

-  
 

-

-

-

-

-
tty(4), mount_fdesc(8)

-

-

-
The floppy disk driver on some ports is also called
-    fd; see fdc(4) for its
-    documentation.

-

-

-

-
-  
-    
-    
-  
-
December 29, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/finsio.4 4.html b/static/netbsd/man4/finsio.4 4.html
deleted file mode 100644
index 470220ec..00000000
--- a/static/netbsd/man4/finsio.4 4.html	
+++ /dev/null
@@ -1,138 +0,0 @@
-
-  
-    
-    
-    
-  
-
FINSIO(4)Device Drivers ManualFINSIO(4)

-

-

-

-
finsio — Fintek
-    LPC Super I/O driver

-

-

-

-
finsio0 at isa? port 0x4e

-

-

-

-
The finsio driver provides support for the
-    Fintek F71805F, F71806F, F71862FG, F71872, F71882 and F71883 LPC Super I/O
-    chips.

-
Only the Hardware Monitor device is supported and it provides you
-    to monitor the sensors through the envsys(4) API.

-
The finsio Super I/O Hardware Monitor
-    supports 15 sensors (this depends on the chip ID):

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uV DCInternal 3.3Vcc
uV DCMemory Vtt
uV DCRAM Vcc
uV DCChipset V
uV DC+5V
uV DC+12V
uV DCVcc 1.5V
uV DCVcore
uV DCVsb
uV DCVbat (optional)
uKCPU Temperature
uKMotherboard Temperature
uK(undefined)
RPMCPU Fan
RPMUser Fan1
RPMUser Fan2

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The finsio driver first appeared in
-    NetBSD 5.0.

-

-

-

-
The finsio driver was written by
-    Geoff Steckel and Juan Romero
-    Pardines.

-

-

-
-  
-    
-    
-  
-
April 3, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/flash.4 4.html b/static/netbsd/man4/flash.4 4.html
deleted file mode 100644
index 2290e16a..00000000
--- a/static/netbsd/man4/flash.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
FLASH(4)Device Drivers ManualFLASH(4)

-

-

-

-
flash —
-    device-independent flash layer

-

-

-

-
#include
-    <sys/flash.h>

-

-

-

-
The flash driver provides a
-    device-independent interface for using flash memory.

-
The following ioctl(2) operations are supported
-    on /dev/flash:

-

-  

-  
This command checks if a block is marked as bad.

-  

-  
This command marks a block as bad.

-  

-  
This command dumps a block.

-  

-  
This command erases one or more blocks.

-  

-  
This command acquires information about the flash device.

-

-

-

-

-

-  
/dev/flash

-  
 

-

-

-

-

-
flash(9), nand(9)

-

-

-

-
Adam Hoka
-    <ahoka@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
January 21, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/fms.4 4.html b/static/netbsd/man4/fms.4 4.html
deleted file mode 100644
index 4f795c0f..00000000
--- a/static/netbsd/man4/fms.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
FMS(4)Device Drivers ManualFMS(4)

-

-

-

-
fms — Forte Media
-    FM801 audio device driver

-

-

-

-
fms* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  mpu* at fms?
-  

-  opl* at fms?

-

-

-

-
The fms device driver supports the Forte
-    Media FM801 sound card.

-

-

-

-
ac97(4), audio(4),
-    mpu(4), opl(4),
-  pci(4)

-

-

-

-
The fms device driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/fmv.4 4.html b/static/netbsd/man4/fmv.4 4.html
deleted file mode 100644
index 89a8d81b..00000000
--- a/static/netbsd/man4/fmv.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
FMV(4)Device Drivers ManualFMV(4)

-

-

-

-
fmv — Fujitsu
-    FMV-18x Ethernet cards device driver

-

-

-

-
fmv0 at isa? port 0x2a0 irq ?
-  

-  fmv* at isapnp?

-

-

-

-
The fmv driver supports the Fujitsu
-    FMV-18x ISA network adapters based on the Fujitsu MB86964/MB86965A Ethernet
-    controllers. Supported boards include:

-

-

-  
Fujitsu FMV-181 ISA Ethernet

-  
 

-  
Fujitsu FMV-181A ISA Ethernet

-  
 

-  
Fujitsu FMV-182 ISA Ethernet

-  
 

-  
Fujitsu FMV-182A ISA Ethernet

-  
 

-  
Fujitsu FMV-183 ISA-PnP Ethernet

-  
 

-

-

-
For Fujitsu FMV-186/186A/188 PCI Ethernet adapters, use
-    fxp(4) driver.

-

-

-

-
ate(4), ifmedia(4),
-    intro(4), isa(4),
-    isapnp(4), mbe(4),
-    ifconfig(8)

-
Fujitsu
-    Semiconductor America

-

-

-

-
The fmv driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
October 5, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/fss.4 4.html b/static/netbsd/man4/fss.4 4.html
deleted file mode 100644
index 18959c8e..00000000
--- a/static/netbsd/man4/fss.4 4.html	
+++ /dev/null
@@ -1,123 +0,0 @@
-
-  
-    
-    
-    
-  
-
FSS(4)Device Drivers ManualFSS(4)

-

-

-

-
fss — file system
-    snapshot device

-

-

-

-
pseudo-device fss 4

-

-

-

-
The fss driver provides a read-only
-    interface to the snapshot of a currently mounted file system. Reading from a
-    fss device gives the view of the file system when
-    the snapshot was taken. It can be configured via
-  ioctl(2).

-

-

-

-
The ioctl(2) command codes below are defined in
-    <sys/dev/fssvar.h>.

-
The (third) argument to ioctl(2) should be a
-    pointer to the type indicated.

-

-  

-  
Configures a fss device.
-    

-    
struct fss_set {
-	char *fss_mount;
-	char *fss_bstore;
-	blksize_t fss_csize;
-	int fss_flags;
-};

-    

-    
The struct element fss_mount is the
-        mount point of the file system. The struct element
-        fss_bstore is either a regular file or a raw disk
-        device where data overwritten on the file system will be saved. The
-        struct element fss_csize is the preferred size of
-        this data. The struct element fss_flags is the
-        initial set of flags.

-  

-  

-  
Gets the status of a fss device.
-    

-    
struct fss_get {
-	char fsg_mount[MNAMELEN];
-	struct timeval fsg_time;
-	blksize_t fsg_csize;
-	blkcnt_t fsg_mount_size;
-	blkcnt_t fsg_bs_size;
-};

-    

-    The struct element fsg_mount is the mount point of the
-      file system. The struct element fsg_time is the time
-      this snapshot was taken. The struct element
-      fsg_csize is the current size of data clusters. The
-      struct element fsg_mount_size is the number of
-      clusters of the file system. The struct element
-      fsg_bs_size is the number of clusters written to the
-      backing store.

-  

-  
Unconfigures a fss device.

-  

-  
Sets the flags of a fss device. Possible flags
-      are:
-    

-      

-      
Unconfigure the fss device on the last
-        close.

-      
-      
Unlink the backing file before the fss device
-          is created.

-    

-  

-  

-  
Gets the flags of a fss device.

-

-

-

-

-
For each active snapshot device there is a kernel thread that
-    handles the backing store. This thread is named fssN
-    where N is the device minor number.

-

-

-

-

-  
/dev/rfss?

-  
 

-  
/dev/fss?

-  
 

-

-

-

-

-
fssconfig(8), mount(8),
-    umount(8)

-

-

-

-
The fss device appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 24, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/fujbp.4 4.html b/static/netbsd/man4/fujbp.4 4.html
deleted file mode 100644
index 85a01fd6..00000000
--- a/static/netbsd/man4/fujbp.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
FUJBP(4)Device Drivers ManualFUJBP(4)

-

-

-

-
fujbp, fujhk
-    — Fujitsu Brightness, Pointer, and
-  Hotkeys

-

-

-

-
fujbp* at acpi?
-  

-  fujhk* at acpi?

-

-

-

-
Some Fujitsu laptops come with vendor-specific ACPI devices to
-    manage the laptop hotkeys (such as the ‘Eco’ button), and to
-    control various built-in components (such as the display, the touchpad, and
-    the speakers). The fujbp and
-    fujhk drivers provide support, through these ACPI
-    devices, for hotkeys, backlight on/off switch, brightness level control, and
-    pointer on/off switch.

-
The following sysctl(8) read/write variables are
-    provided (when hardware support is available):

-

-

-  
hw.acpi.fujbp0.brightness

-  
Brightness level (integer).

-  
hw.acpi.fujbp0.pointer

-  
Pointer switch state (boolean).

-  
hw.acpi.fujhk0.backlight

-  
Backlight switch state (boolean).

-

-

-
Please note, however, that future versions of the drivers may
-    remove these sysctl(8) variables without prior notice.

-

-

-

-
acpi(4), acpivga(4),
-    sysctl(8), pmf(9),
-    sysmon_pswitch(9)

-

-

-

-
The fujbp and
-    fujhk drivers appeared in NetBSD
-    6.0.

-

-

-

-
Grégoire Sutre
-    ⟨gsutre@NetBSD.org⟩

-

-

-

-
Brightness level and backlight switch state should be controlled
-    via wsconsctl(8) instead of
-  sysctl(8).

-
The sysctl(8) variable
-    hw.acpi.fujbp0.pointer should be replaced by a
-    platform-independent userland control.

-

-

-
-  
-    
-    
-  
-
February 20, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/full.4 4.html b/static/netbsd/man4/full.4 4.html
deleted file mode 100644
index c73a0c13..00000000
--- a/static/netbsd/man4/full.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
FULL(4)Device Drivers ManualFULL(4)

-

-

-

-
full — the full
-    device

-

-

-

-
The full device always returns
-    [ENOSPC] on writing.

-
In all other cases it behaves like the zero(4)
-    device and provides an infinite stream of zeros.

-

-

-

-

-  
/dev/full

-  
 

-

-

-

-

-
The full device appeared in
-    NetBSD 8.

-

-

-

-
Christos Zoulas

-

-

-
-  
-    
-    
-  
-
January 17, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/fwip.4 4.html b/static/netbsd/man4/fwip.4 4.html
deleted file mode 100644
index bb3c09e5..00000000
--- a/static/netbsd/man4/fwip.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
FWIP(4)Device Drivers ManualFWIP(4)

-

-

-

-
fwip — IP over
-    IEEE1394 driver

-

-

-

-
fwip* at ieee1394if?

-

-

-

-
The fwip driver provides standard IP over
-    IEEE1394 based on the protocols described in RFC 2734 and RFC 3146.

-
The ieee1394if(4) and
-    fwohci(4) drivers must be configured in the kernel as
-    well.

-

-

-

-
arp(4), fwohci(4),
-    ieee1394if(4), netintro(4),
-    ifconfig(8), sysctl(8)

-

-

-

-
The fwip device driver first appeared in
-    FreeBSD 5.3. It was added to NetBSD
-    4.0.

-

-

-

-
The fwip driver and this manual page were
-    written by Doug Rabson, based on earlier work by
-    Hidetoshi Shimokawa. It was added to
-    NetBSD 4.0 by KIYOHARA
-    Takashi.

-

-

-

-
This driver currently does not support the MCAP protocol for
-    multicast IP over IEEE1394. Multicast packets are treated as broadcast
-    packets which is sufficient for most trivial uses of multicast.

-

-

-
-  
-    
-    
-  
-
June 18, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/fwohci.4 4.html b/static/netbsd/man4/fwohci.4 4.html
deleted file mode 100644
index 68023d68..00000000
--- a/static/netbsd/man4/fwohci.4 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
FWOHCI(4)Device Drivers ManualFWOHCI(4)

-

-

-

-
fwohci — OHCI
-    IEEE1394 chipset device driver

-

-

-

-
fwohci* at cardbus? function ?
-  

-  fwohci* at pci? dev ? function ?

-

-

-

-
The fwohci driver provides support for
-    PCI/CardBus IEEE1394 interface cards. The driver supports the following IEEE
-    1394 OHCI chipsets:

-

-
    
-  
  • Adaptec AHA-894x/AIC-5800
    • 
-  
  • Apple Pangea
    • 
-  
  • Apple UniNorth
    • 
-  
  • Intel 82372FB
    • 
-  
  • IOGEAR GUF320
    • 
-  
  • Lucent / Agere FW322/323
    • 
-  
  • NEC uPD72861
    • 
-  
  • NEC uPD72870
    • 
-  
  • NEC uPD72871/2
    • 
-  
  • NEC uPD72873
    • 
-  
  • NEC uPD72874
    • 
-  
  • National Semiconductor CS4210
    • 
-  
  • Ricoh R5C551
    • 
-  
  • Ricoh R5C552
    • 
-  
  • Sony CX3022
    • 
-  
  • Sony i.LINK (CXD1947)
    • 
-  
  • Sony i.LINK (CXD3222)
    • 
-  
  • Texas Instruments PCI4410A
    • 
-  
  • Texas Instruments PCI4450
    • 
-  
  • Texas Instruments PCI4451
    • 
-  
  • Texas Instruments TSB12LV22
    • 
-  
  • Texas Instruments TSB12LV23
    • 
-  
  • Texas Instruments TSB12LV26
    • 
-  
  • Texas Instruments TSB43AA22
    • 
-  
  • Texas Instruments TSB43AB21/A/AI/A-EP
    • 
-  
  • Texas Instruments TSB43AB22/A
    • 
-  
  • Texas Instruments TSB43AB23
    • 
-  
  • Texas Instruments TSB82AA2
    • 
-  
  • VIA Fire II (VT6306)
    • 
-

-

-

-

-
fwip(4), ieee1394if(4),
-    sbp(4), fwctl(8)

-

-

-

-
The fwohci device driver first appeared in
-    FreeBSD 5.0. It was added to NetBSD
-    4.0.

-

-

-

-
The fwohci device driver was written by
-    Katsushi Kobayashi and Hidetoshi
-    Shimokawa. It was added to NetBSD 4.0 by
-    KIYOHARA Takashi.

-

-

-

-
The driver allows physical access from any node on the bus by
-    default. This means that any devices on the bus can read and modify any
-    memory space which can be accessed by an IEEE 1394 OHCI chip. It is allowed
-    mostly for sbp(4) devices. This should be changed to allow
-    it only for specific devices. Anyway, IEEE1394 is a bus and not expected to
-    be connected with un-trustable devices because a node can monitor all the
-    traffic.

-

-

-
-  
-    
-    
-  
-
June 18, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/fxp.4 4.html b/static/netbsd/man4/fxp.4 4.html
deleted file mode 100644
index e9d25a87..00000000
--- a/static/netbsd/man4/fxp.4 4.html	
+++ /dev/null
@@ -1,120 +0,0 @@
-
-  
-    
-    
-    
-  
-
FXP(4)Device Drivers ManualFXP(4)

-

-

-

-
fxp — Intel i8255x
-    10/100 Ethernet device driver

-

-

-

-
fxp* at cardbus? function ?
-  

-  fxp* at pci? dev ? function ?

-

-

-

-
The fxp device driver supports Ethernet
-    interfaces based on the Intel i82557, i82558, i82559, and i82550 10/100 PCI
-    Ethernet chips.

-
Certain versions of the i8255x support loading microcode which
-    implements a receive interrupt mitigation function, known as
-    “CPUSaver”. Use of this option can improve performance in some
-    situations by reducing interrupt load on the host. This option is available
-    on the following chip versions:

-

-
    
-  
  • i82558 step A4 (rev 4)
    • 
-  
  • i82558 step B0 (rev 5)
    • 
-  
  • i82559 step A0 (rev 8)
    • 
-  
  • i82559S step A (rev 9)
    • 
-  
  • i82550 (rev 12)
    • 
-  
  • i82550 step C (rev 13)
    • 
-

-
This option is enabled by setting the “link0” option
-    with ifconfig(8).

-
Some chipset revisions can suffer from a receiver-side lockup bug
-    which can be mitigated by resetting the chip every sixteen seconds without
-    traffic. Since the probe for affected chipsets generates false positives and
-    the workaround can cause momentary loss of responsiveness, particularly
-    noticeable when playing audio, the workaround is not enabled by default. The
-    boot messages will indicate if any interface may have this issue. The
-    workaround is enabled by setting the “link1” option with
-    ifconfig(8).

-

-

-

-
Cards supported by the fxp driver
-  include:

-

-
    
-  
  • Intel EtherExpress Pro 10+
    • 
-  
  • Intel EtherExpress Pro 100B
    • 
-  
  • Intel EtherExpress Pro 100+
    • 
-  
  • Intel InBusiness 10/100
    • 
-  
  • Intel PRO/100 S
    • 
-

-

-

-

-
Media selection is supported via MII. See
-    ifmedia(4) and mii(4) for more
-    information.

-
EtherExpress Pro 10+ boards may use a Seeq 80c24 AutoDUPLEX(tm)
-    media interface. Boards with these chips do not support media selection, as
-    the 80c24 has no programming interface, and no way to read link status.
-    These boards claim a media of "manual" since they self-configure
-    based on the configuration of the link partner (hub or switch).

-

-

-

-

-  
fxp0: WARNING: SCB timed out!

-  
The driver timed out waiting for the chip's command interface to become
-      ready.

-  
fxp0: too many segments, aborting

-  
The driver encountered a packet that included too many DMA segments, and
-      was not able to allocate a new buffer to transmit the packet from. The
-      packet has been dropped.

-  
fxp0: too many segments, retrying

-  
The driver encountered a packet that included too many DMA segments, and
-      allocated a new buffer to transmit the packet from.

-  
fxp0: can't load mbuf chain, error = %d

-  
The driver was unable to load a transmit DMA map, and has reported the
-      errno value.

-  
fxp0: device timeout

-  
The device failed to generate a transmit complete interrupt for the last
-      packet transmitted. The device has been reset.

-  
fxp0: can't load rx buffer, error = %d

-  
The driver was unable to load the DMA map for a receive buffer, and has
-      reported the errno value. This error is currently fatal, and will panic
-      the system.

-  
fxp0: fxp_mdi_read: timed out

-  
The MDIO failed to become ready during an MII read operation.

-  
fxp0: fxp_mdi_write: timed out

-  
The MDIO failed to become ready during an MII write operation.

-  
fxp0: May need receiver lock-up workaround

-  
The interface may need to be periodically reset to workaround a receiver
-      lock-up bug.

-

-

-

-

-
cardbus(4), ifmedia(4),
-    intro(4), mii(4),
-    pci(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
October 15, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/g760a.4 4.html b/static/netbsd/man4/g760a.4 4.html
deleted file mode 100644
index 5124730b..00000000
--- a/static/netbsd/man4/g760a.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
G760A(4)Device Drivers ManualG760A(4)

-

-

-

-
g760a — Global
-    Mixed-mode Technology Inc. G760a fan speed controller driver

-

-

-

-
g760a0 at iic? addr 0x3e

-

-

-

-
The g760a driver provides support for the
-    Global Mixed-mode Technology Inc. G760a on iicbus fan speed controller to be
-    used with the envsys(4) API. This chip could be found in
-    D-Link's DNS-323 NAS box.

-
The following sysctl(8) variable controls the
-    fan's speed:

-

-  

-  
This value specifies the desired speed for the fan. Valid range is
-      2000..20000 or 0 (the fan is turned off). The default value is 0.
-    
When setting the desired speed the RPM number will be
-        converted to the internal representation and truncated. For example when
-        you are setting 2000 it will be truncated to 2006, and 8000 will be
-        changed to 8057.

-  

-

-

-

-

-
envsys(4), lm(4),
-    envstat(8)

-

-

-

-
The g760a driver was written by
-    A. Leo.

-

-

-
-  
-    
-    
-  
-
April 11, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/gcscaudio.4 4.html b/static/netbsd/man4/gcscaudio.4 4.html
deleted file mode 100644
index e477c687..00000000
--- a/static/netbsd/man4/gcscaudio.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
GCSCAUDIO(4)Device Drivers ManualGCSCAUDIO(4)

-

-

-

-
gcscaudio — AMD
-    Geode CS5536 audio device driver

-

-

-

-
gcscaudio* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The gcscaudio device driver supports the
-    audio controller of the AMD Geode CS5536 Companion Device chip found on some
-    motherboards. The CS5536 and this driver support 1, 2, 4, and 6 (5.1)
-    channels output, 1 and 2 channels input, and full-duplex.

-

-

-

-
audio(4), pci(4)

-

-

-

-
The gcscaudio device driver appeared in
-    NetBSD 6.0.

-

-

-

-
SHIMIZU Ryo

-

-

-

-
This driver was only tested on the KOHJINSHA SA5SX04, and 5.1
-    channel output is not tested.

-

-

-
-  
-    
-    
-  
-
February 7, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/gem.4 4.html b/static/netbsd/man4/gem.4 4.html
deleted file mode 100644
index e10c7680..00000000
--- a/static/netbsd/man4/gem.4 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
GEM(4)Device Drivers ManualGEM(4)

-

-

-

-
gem — ERI/GEM/GMAC
-    Ethernet device driver

-

-

-

-
gem* at pci? dev ? function ?
-  

-  gem* at sbus? slot ? offset ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The gem driver provides support for the
-    GMac Ethernet hardware found mostly in the last Apple PowerBooks G3s and
-    most G4-based Apple hardware, as well as many Sun UltraSPARCs.

-
Cards supported by this driver include:

-
    
-  
  • Sun GEM Gigabit Ethernet (SX fibre variants)
    • 
-  
  • Sun ERI 10/100
    • 
-  
  • Apple GMAC
    • 
-

-
The GEM family supports hardware checksumming to assist in
-    computing IPv4 TCP checksums. The gem driver
-    supports this feature of the chip. See ifconfig(8) for
-    information on how to enable this feature.

-

-

-

-
bmtphy(4), ifmedia(4),
-    intro(4), makphy(4),
-    mii(4), ifconfig(8)

-
Sun Microsystems,
-    GEM Gigabit Ethernet ASIC Specification,
-    http://www.sun.com/processors/manuals/ge.pdf.

-
Sun Microsystems,
-    Sbus GEM Specification,
-    http://mediacast.sun.com/users/Barton808/media/gem_sbus-1.pdf.

-

-

-

-
The gem device driver appeared in
-    NetBSD 1.6. Support for PCI SX fibre cards was added
-    in NetBSD 5.0. Support for SBus SX fibre cards was
-    added in NetBSD 5.0.

-

-

-

-
The gem driver was written by
-    Eduardo Horvath ⟨eeh@NetBSD.org⟩. SX
-    fibre support was added by Julian Coleman
-    ⟨jdc@NetBSD.org⟩. The man page was written by
-    Thomas Klausner ⟨wiz@NetBSD.org⟩.

-

-

-

-
The hardware checksumming support does not support IPv4 UDP,
-    although this was allowed prior to NetBSD 5.0. Also,
-    the hardware IPv4 TCP receive checksumming support has bugs, so this is
-    disabled.

-
On the SX fibre variants of the hardware, the link will stay down
-    if there is a duplex mismatch. Also, packet transmission may fail when in
-    half-duplex mode.

-

-

-
-  
-    
-    
-  
-
June 2, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/genet.4 4.html b/static/netbsd/man4/genet.4 4.html
deleted file mode 100644
index 2fe5a0f6..00000000
--- a/static/netbsd/man4/genet.4 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
GENET(4)Device Drivers ManualGENET(4)

-

-

-

-
genet — Broadcom
-    GENET 10/100/1Gb Ethernet device

-

-

-

-
genet* at acpi?
-  

-  genet* at fdt?
-  

-  brgphy* at mii?

-

-

-

-
The genet driver provides support for the
-    Broadcom GENET v5 controller found on the Raspberry Pi 4.

-
The genet driver supports several media
-    types, which are selected via the ifconfig(8) command. The
-    supported media types are:

-

-

-  

-    autoselect

-  
Attempt to autoselect the media type (default)

-  

-    1000baseT mediaopt
-    full-duplex

-  
Use 1000baseT on copper, full duplex

-  

-    1000baseT mediaopt
-    half-duplex

-  
Use 1000baseT on copper, half duplex

-  

-    100baseTX mediaopt
-    full-duplex

-  
Use 100baseTX, full duplex

-  

-    100baseTX mediaopt
-    half-duplex

-  
Use 100baseTX, half duplex

-  

-    10baseT mediaopt
-    full-duplex

-  
Use 10baseT, full duplex

-  

-    10baseT mediaopt
-    half-duplex

-  
Use 10baseT, half duplex

-

-

-

-

-

-
arp(4), brgphy(4),
-    ifmedia(4), inet(4),
-    intro(4), netintro(4),
-    ifconfig(8), rnd(9)

-

-

-

-
The genet driver first appeared in
-    NetBSD 10.

-

-

-

-
The genet driver was written by
-    Jared D. McNeill
-    <jmcneill@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 28, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/genfb.4 4.html b/static/netbsd/man4/genfb.4 4.html
deleted file mode 100644
index 15fe7726..00000000
--- a/static/netbsd/man4/genfb.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
GENFB(4)Device Drivers ManualGENFB(4)

-

-

-

-
genfb — generic
-    framebuffer console driver

-

-

-

-
genfb* at pci?
-  

-  genfb* at sbus?
-  

-  genfb* at intvid? (mac68k)
-  

-  genfb* at macvid? (mac68k)
-  

-  wsdisplay* at genfb?

-

-

-

-
The genfb driver provides support for
-    generic framebuffers that have no native driver. All it needs are some
-    parameters to describe the framebuffer and an address.

-

-

-
When attaching to a pci(4) bus the driver is
-    configured via device properties:

-

-  

-    (uint32)

-  
Width in pixels.

-  

-    (uint32)

-  
Height in pixels.

-  

-    (uint32)

-  
Line size in bytes.

-  

-    (uint32)

-  
Bits per pixel.

-  

-    (bool)

-  
If true, genfb will try to become the system
-      console.

-  

-    (uint32)

-  
Bus address of the framebuffer.

-

-

-

-

-
When attaching to sbus(4) all those parameters
-    are retrieved from the firmware.

-

-

-

-
All those parameters are configured with Mac OS, and retrieved
-    from the boot loader.

-

-

-

-

-
mac68k/intro(4), pci(4),
-    sbus(4), wscons(4),
-    wsdisplay(4)

-

-

-

-
There is no way to change the color map even when the firmware
-    supports it. The pci(4) bus frontend has only been tested
-    on macppc, i386, and amd64 and requires machine dependent code to pass the
-    properties mentioned above. So far only macppc, i386, and amd64 provides
-    them.

-

-

-
-  
-    
-    
-  
-
July 26, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/gentbi.4 4.html b/static/netbsd/man4/gentbi.4 4.html
deleted file mode 100644
index 9a45c0df..00000000
--- a/static/netbsd/man4/gentbi.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
GENTBI(4)Device Drivers ManualGENTBI(4)

-

-

-

-
gentbi — Driver
-    for generic 1000BASE-X ten-bit interfaces

-

-

-

-
gentbi* at mii? phy ?

-

-

-

-
The gentbi driver supports generic ten-bit
-    interfaces that implement the 1000BASE-X protocol, including 1000BASE-SX,
-    1000BASE-LX, and 1000BASE-CX.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
July 25, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/geodeide.4 4.html b/static/netbsd/man4/geodeide.4 4.html
deleted file mode 100644
index 66fb5f61..00000000
--- a/static/netbsd/man4/geodeide.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
GEODEIDE(4)Device Drivers ManualGEODEIDE(4)

-

-

-

-
geodeide — AMD
-    Geode IDE disk controllers driver

-

-

-

-
geodeide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The geodeide driver supports the AMD Geode
-    CS5530A and SC1100 IDE controllers, and provides the interface with the
-    hardware for the ata(4) driver.

-
The 0x0002 flag forces the geodeide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The SC1100 controller requires 4-byte aligned data transfers and
-    cannot handle transfers of exactly 64 kilobytes.

-
The CS5530 multifunction chip/core's IDE section claims to be
-    capable of UDMA mode 2 (33.3MB/s) but in practice using that mode swamps the
-    controller so badly that geodeide limits the UDMA
-    negotiation to mode 1 (25MB/s) so that the other functions of this chip
-    continue to work.

-
The IDE DMA engine in the CS5530 can only do transfers on
-    cache-line (16-byte) boundaries. Attempts to perform DMA on any other
-    alignment will crash the system. This problem may also exist in the SC1100
-    since the CS5530 was its direct predecessor, and it is not clear that
-    National Semiconductor fixed any bugs in it.

-
The geodeide driver will reject attempts
-    to DMA to buffers not aligned to the required boundary. The
-    wd(4) disk driver will back off to PIO mode to accomplish
-    these transfer requests, at reduced system performance.

-

-

-
-  
-    
-    
-  
-
July 5, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/gif.4 3.html b/static/netbsd/man4/gif.4 3.html
deleted file mode 100644
index ce3c79a4..00000000
--- a/static/netbsd/man4/gif.4 3.html	
+++ /dev/null
@@ -1,201 +0,0 @@
-
-  
-    
-    
-    
-  
-
GIF(4)Device Drivers ManualGIF(4)

-

-

-

-
gif — generic
-    tunnel interface

-

-

-

-
pseudo-device gif

-

-

-

-
The gif interface is a generic tunneling
-    pseudo device for IPv4 and IPv6. It can tunnel IPv[46] traffic over IPv[46].
-    Therefore, there can be four possible configurations. The behavior of
-    gif is mainly based on RFC 2893 IPv6-over-IPv4
-    configured tunnel.

-
To use gif, the administrator must first
-    create the interface and then configure protocol and addresses used for the
-    outer header. This can be done by using ifconfig(8)
-    create and tunnel
-    subcommands, or SIOCIFCREATE and
-    SIOCSIFPHYADDR ioctls. Also, administrator needs to
-    configure protocol and addresses used for the inner header, by using
-    ifconfig(8). Note that IPv6 link-local address (those
-    start with fe80::) will be automatically configured
-    whenever possible. You may need to remove IPv6 link-local address manually
-    using ifconfig(8), when you would like to disable the use
-    of IPv6 as inner header (like when you need pure IPv4-over-IPv6 tunnel).
-    Finally, use routing table to route the packets toward
-    gif interface.

-
gif can be configured to be ECN friendly.
-    This can be configured by IFF_LINK1.

-

-

-
gif can be configured to be ECN friendly,
-    as described in draft-ietf-ipsec-ecn-02.txt. This is
-    turned off by default, and can be turned on by
-    IFF_LINK1 interface flag.

-
Without IFF_LINK1,
-    gif will show a normal behavior, like described in
-    RFC 2893. This can be summarized as follows:

-

-

-  
Ingress

-  
Set outer TOS bit to 0.

-  
Egress

-  
Drop outer TOS bit.

-

-

-
With IFF_LINK1,
-    gif will copy ECN bits (0x02
-    and 0x01 on IPv4 TOS byte or IPv6 traffic class
-    byte) on egress and ingress, as follows:

-

-

-  
Ingress

-  
Copy TOS bits except for ECN CE (masked with 0xfe)
-      from inner to outer. set ECN CE bit to 0.

-  
Egress

-  
Use inner TOS bits with some change. If outer ECN CE bit is
-      1, enable ECN CE bit on the inner.

-

-

-
Note that the ECN friendly behavior violates RFC 2893. This should
-    be used in mutual agreement with the peer.

-

-

-

-
Every inner packet is encapsulated in an outer packet. The inner
-    packet may be IPv4 or IPv6. The outer packet may be IPv4 or IPv6, and has
-    all the usual IP headers, including a protocol field that identifies the
-    type of inner packet.

-
When the inner packet is IPv4, the protocol field of the outer
-    packet is 4 (IPPROTO_IPV4). When the inner packet is
-    IPv6, the protocol field of the outer packet is 41
-    (IPPROTO_IPV6).

-

-

-

-
Malicious party may try to circumvent security filters by using
-    tunneled packets. For better protection, gif
-    performs martian filter and ingress filter against outer source address, on
-    egress. Note that martian/ingress filters are no way complete. You may want
-    to secure your node by using packet filters. Ingress filter can be turned
-    off by IFF_LINK2 bit.

-

-

-

-

-
Configuration example:

-

-
Host X--NetBSD A  ----------------tunnel---------- cisco D------Host E
-           \                                          |
-            \                                        /
-             +-----Router B--------Router C---------+
-
-

-

-On NetBSD system A (NetBSD):
-

-
   # route add default B
-   # ifconfig gifN create
-   # ifconfig gifN A netmask 0xffffffff tunnel A D up
-   # route add E 0
-   # route change E -ifp gif0

-

-
On Host D (Cisco):

-

-
   Interface TunnelX
-    ip unnumbered D   ! e.g. address from Ethernet interface
-    tunnel source D   ! e.g. address from Ethernet interface
-    tunnel destination A
-    tunnel mode ipip
-   ip route C <some interface and mask>
-   ip route A mask C
-   ip route X mask tunnelX

-

-
or on Host D (NetBSD):

-

-
   # route add default C
-   # ifconfig gifN D A

-

-
If all goes well, you should see packets flowing.

-
If you want to reach Host A over the tunnel (from the Cisco D),
-    then you have to have an alias on Host A for e.g. the Ethernet interface
-    like: ifconfig <etherif> alias
-    Y and on the cisco ip route Y
-    mask tunnelX.

-

-

-

-
inet(4), inet6(4),
-    l2tp(4), ifconfig(8)

-
C. Perkins,
-    IP Encapsulation within IP, RFC
-    2003,
-    ftp://ftp.isi.edu/in-notes/rfc2003.txt,
-    October 1996.

-
R. Gilligan and
-    E. Nordmark, Transition
-    Mechanisms for IPv6 Hosts and Routers, RFC 2893,
-    ftp://ftp.isi.edu/in-notes/rfc2893.txt,
-    August 2000.

-
Sally Floyd,
-    David L. Black, and K. K.
-    Ramakrishnan, IPsec Interactions with ECN,
-    http://datatracker.ietf.org/internet-drafts/draft-ietf-ipsec-ecn/,
-    December 1999.

-
F. Baker and
-    P. Savola, Ingress Filtering for
-    Multihomed Networks, RFC 3704,
-    ftp://ftp.isi.edu/in-notes/rfc3704.txt,
-    March 2004.

-

-

-

-
IPv4 over IPv4 encapsulation is compatible with RFC 2003. IPv6
-    over IPv4 encapsulation is compatible with RFC 2893.

-

-

-

-
The gif device first appeared in WIDE
-    hydrangea IPv6 kit.

-

-

-

-
There are many tunneling protocol specifications, defined
-    differently from each other. gif may not
-    interoperate with peers which are based on different specifications, and are
-    picky about outer header fields. For example, you cannot usually use
-    gif to talk with IPsec devices that use IPsec tunnel
-    mode.

-
The current code does not check if the ingress address (outer
-    source address) configured to gif makes sense. Make
-    sure to configure an address which belongs to your node. Otherwise, your
-    node will not be able to receive packets from the peer, and your node will
-    generate packets with a spoofed source address.

-
If the outer protocol is IPv6, path MTU discovery for encapsulated
-    packet may affect communication over the interface.

-
In the past, gif had a multi-destination
-    behavior, configurable via IFF_LINK0 flag. The
-    behavior was obsoleted and is no longer supported.

-

-

-
-  
-    
-    
-  
-
August 14, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/glxtphy.4 3.html b/static/netbsd/man4/glxtphy.4 3.html
deleted file mode 100644
index b90e0912..00000000
--- a/static/netbsd/man4/glxtphy.4 3.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
GLXTPHY(4)Device Drivers ManualGLXTPHY(4)

-

-

-

-
glxtphy — Driver
-    for Level One LXT-1000 10/100/1000 Ethernet PHY

-

-

-

-
glxtphy* at mii? phy ?

-

-

-

-
The glxtphy driver supports the Level One
-    LXT-1000 10/100/1000 Ethernet PHY. This PHY is found on a variety of CAT5
-    Gigabit Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
July 24, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/gphyter.4 4.html b/static/netbsd/man4/gphyter.4 4.html
deleted file mode 100644
index 81e3620f..00000000
--- a/static/netbsd/man4/gphyter.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPHYTER(4)Device Drivers ManualGPHYTER(4)

-

-

-

-
gphyter — Driver
-    for National Semiconductor DP83861, DP83865 and DP83891 10/100/1000 Ethernet
-    PHYs

-

-

-

-
gphyter* at mii? phy ?

-

-

-

-
The gphyter driver supports the National
-    Semiconductor DP83861, DP83865 and DP83891 (Gig PHYTER) 10/100/1000 Ethernet
-    PHYs. These PHYs are found on a variety of CAT5 Gigabit Ethernet
-  interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
January 7, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/gpib.4 4.html b/static/netbsd/man4/gpib.4 4.html
deleted file mode 100644
index 29a521c9..00000000
--- a/static/netbsd/man4/gpib.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIB(4)Device Drivers ManualGPIB(4)

-

-

-

-
cec — support for
-    the IEEE488 GPIB

-

-

-

-
gpib* at cec?

-

-

-

-
The cec driver supports the IEEE488
-    general-purpose interface bus (GPIB).

-

-

-

-

-  
/dev/gpib?

-  
GPIB device special file

-

-

-

-

-
cs80bus(4), ct(4),
-    mt(4), rd(4)

-

-

-

-
The cec driver appeared in
-    NetBSD 2.0.

-

-

-

-
The user-level interface to the gpib driver current doesn't do
-    anything useful. The GPIB subsystem places the unfortunate constraint that
-    the local GPIB controller is always the controller in charge (CIC).

-

-

-
-  
-    
-    
-  
-
May 24, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/gpio.4 4.html b/static/netbsd/man4/gpio.4 4.html
deleted file mode 100644
index 5a628215..00000000
--- a/static/netbsd/man4/gpio.4 4.html	
+++ /dev/null
@@ -1,244 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIO(4)Device Drivers ManualGPIO(4)

-

-

-

-
gpio — General
-    Purpose Input/Output

-

-

-

-
gpio* at elansc?
-  

-  gpio* at emcfan?
-  

-  gpio* at epgpio?
-  

-  gpio* at gcscpcib?
-  

-  gpio* at gpiosim?
-  

-  gpio* at gscpcib?
-  

-  gpio* at ichlpcib?
-  

-  gpio* at nsclpcsio?
-  

-  gpio* at sc16is7xx?
-  

-  gpio* at soekrisgpio?
-  

-  gpio* at ppbus?
-  

-  gpio* at ptcd?
-  

-  gpio* at umcpmio?
-  

-  gpio* at wbsio?

-

-  

-  #include <sys/types.h>
-  

-  #include <sys/gpio.h>
-  

-  #include <sys/ioctl.h>

-

-

-

-
The gpio device attaches to the GPIO
-    controller and provides a uniform programming interface to its pins.

-
Each GPIO controller with an attached gpio
-    device has an associated device file under the /dev
-    directory, e.g. /dev/gpio0. Access from userland is
-    performed through ioctl(2) calls on these devices.

-
Whether the layout of the GPIO device can be configured is subject
-    to authorization by the kauth(9) framework.

-
If for example secmodel_securelevel(9) is
-    active, the layout of the GPIO device is defined at a securelevel less than
-    1, i.e. typically during system boot, and cannot be changed later. GPIO pins
-    can be configured and given a symbolic name and device drivers that use GPIO
-    pins can be attached to the gpio device at a
-    securelevel less than 1. All other pins will not be accessible once the
-    runlevel has been raised.

-

-

-

-
The following structures and constants are defined in the
-    <sys/gpio.h> header
-  file:

-

-

-  

-    (struct gpio_info)

-  
Returns information about the GPIO controller in the
-      gpio_info structure:
-    

-    
struct gpio_info {
-	int gpio_npins;		/* total number of pins available */
-};

-    

-    

-  

-  

-    (struct gpio_req)

-  
Returns the input pin value in the gpio_req
-      structure:
-    

-    
#define GPIOMAXNAME		64
-
-struct gpio_req {
-	char gp_name[GPIOMAXNAME];	/* pin name */
-	int gp_pin;			/* pin number */
-	int gp_value;			/* value */
-};

-    

-    
The gp_name or
-        gp_pin field must be set before calling. If both
-        are set, gp_name takes precedence. On return, the
-        gp_name field contains the current name of the
-        pin, if set by the controller driver or an earlier call to
-        GPIOSET.

-    

-  

-  

-    (struct gpio_req)

-  
Writes the output value to the pin. The value set in the
-      gp_value field must be either
-      GPIO_PIN_LOW (logical 0) or
-      GPIO_PIN_HIGH (logical 1). On return, the
-      gp_value field contains the old pin state.
-    

-  

-  

-    (struct gpio_req)

-  
Toggles the pin output value, i.e. changes it to the opposite.
-      gp_value field is ignored and on return contains the
-      old pin state.
-    

-  

-  

-    (struct gpio_set)

-  
Changes pin configuration flags with the new ones provided in the
-      gpio_set structure:
-    

-    
#define GPIOMAXNAME          64
-
-struct gpio_set {
-        char gp_name[GPIOMAXNAME];   /* pin name */
-        int gp_pin;                     /* pin number */
-        int gp_caps;                    /* pin capabilities (ro) */
-        int gp_flags;                   /* pin configuration flags */
-        char gp_name2[GPIOMAXNAME];  /* new name */
-};

-    

-    
The gp_flags field is a combination of
-        the following flags:

-    

-    

-      

-      
input direction

-      

-      
output direction

-      

-      
bi-directional

-      

-      
open-drain output

-      

-      
push-pull output

-      

-      
output disabled

-      

-      
internal pull-up enabled

-      

-      
internal pull-down enabled

-      

-      
invert input

-      

-      
invert output

-      

-      
pulsate output

-      

-      
 

-      

-      
select alternate pin function 0 to 7

-    

-    
Note that the GPIO controller may not support all of these
-        flags. On return the gp_caps field contains flags
-        that are supported. If no flags are specified, the pin configuration
-        stays unchanged.

-    
Only GPIO pins that have been set using
-        GPIOSET will be accessible at securelevels greater
-        than 0.

-    

-  

-  

-    (struct gpio_set)

-  
Unset the specified pin, i.e. clear its name and make it inaccessible at
-      securelevels greater than 0.
-    

-  

-  

-    (struct gpio_attach)

-  
Attach the device described in the gpio_attach
-      structure on this gpio device.
-    

-    
struct gpio_attach {
-        char ga_dvname[16];     /* device name */
-        int ga_offset;          /* pin number */
-        uint32_t ga_mask;       /* binary mask */
-        uint32_t ga_flags;      /* driver dependent */
-};

-    

-    
The drvctl(8) command can be used to detach
-        a device from a gpio pin.

-  

-

-

-

-

-

-  
/dev/gpiou

-  
GPIO device unit u file.

-

-

-

-

-
ioctl(2), drvctl(8),
-    gpioctl(8)

-

-

-

-
The gpio device first appeared in
-    OpenBSD 3.6 and NetBSD
-  4.0.

-

-

-

-
The gpio driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>.
-    gpio was ported to NetBSD by
-    Jared D. McNeill
-    <jmcneill@NetBSD.org>.
-    Runtime device attachment was added by Marc Balmer
-    <marc@msys.ch>.

-

-

-

-
Event capabilities are not supported.

-

-

-
-  
-    
-    
-  
-
May 4, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/gpioiic.4 4.html b/static/netbsd/man4/gpioiic.4 4.html
deleted file mode 100644
index 427f8678..00000000
--- a/static/netbsd/man4/gpioiic.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOIIC(4)Device Drivers ManualGPIOIIC(4)

-

-

-

-
gpioiic — GPIO I2C
-    controller

-

-

-

-
gpioiic* at gpio? offset 0 mask 0x3 flag
-    0x0
-  

-  gpioiic* at gpio?
-  

-  iic* at gpioiic?

-

-

-

-
The gpioiic driver allows bit-banging an
-    I2C bus as a master using two GPIO pins. By default the first pin is used as
-    a serial data (SDA) signal and the second as a serial clock (SCL). If the
-    flag locator is set to 0x01, the order of the SDA and SCL signals is
-    reversed. Both GPIO pins must be able to drive an output and the SDA pin
-    must be also able to read an input.

-
The pins can be specified in the kernel configuration with the
-    offset and the mask locators.
-    The offset and mask can also be
-    specified when gpioiic is attached at runtime using
-    the GPIOATTACH ioctl(2) on the
-    gpio(4) device. Each bit in the mask
-    locator defines one pin; the pin number is calculated as an addition of the
-    bit position and the offset locator. For example,
-    offset 17 and mask 0x5 defines
-    pin numbers 17 and 19.

-

-

-

-
gpio(4), iic(4),
-    intro(4)

-

-

-

-
The gpioiic driver first appeared in
-    OpenBSD 3.9 and NetBSD
-  5.0.

-

-

-

-
The gpioiic driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>
-    and was ported to NetBSD by Marc
-    Balmer
-    <marc@msys.ch>.

-

-

-

-
A gpioiic device can not be detached from
-    the gpio(4) bus at runtime due to the fact that
-    iic(4) busses can not detach once attached.

-

-

-
-  
-    
-    
-  
-
October 2, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/gpioirq.4 4.html b/static/netbsd/man4/gpioirq.4 4.html
deleted file mode 100644
index 0989156c..00000000
--- a/static/netbsd/man4/gpioirq.4 4.html	
+++ /dev/null
@@ -1,132 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOIRQ(4)Device Drivers ManualGPIOIRQ(4)

-

-

-

-
gpioirq — Install
-    an interrupt handler on GPIO pins

-

-

-

-
gpioirq* at gpio? offset 0 mask 0x1 flag
-    0x00

-

-

-

-
The gpioirq driver attaches an interrupt
-    handler to a one or more GPIO pins.

-
The base pin number is specified in the kernel configuration file
-    with the offset locator. The
-    mask locator can be 0x01 or greater to indicate that
-    more pins should have an interrupt handler attached to them.

-
The flag locator specifies the interrupt
-    mode to use:

-

-  

-  
Interrupt on the positive (rising) edge of the pin.

-  

-  
Interrupt on the negative (falling) edge of the pin.

-  

-  
Interrupt on both edges of the pin.

-  

-  
Assert the interrupt as long as the pin is high.

-  

-  
Assert the interrupt as long as the pin is low.

-

-
Note that the interrupts modes are mutually-exclusive, and exactly
-    one interrupt mode must be specified. These flags correspond to the
-    GPIO_INTR mode bits defined in
-    sys/gpio.h. In addition to the interrupt mode,
-    setting 0x1000 in flags will
-    enable the printing of a message to the console whenever the interrupt
-    handler is called.

-
The offset, mask, and
-    flag locators can also be specified when
-    gpioirq is attached at runtime using the
-    GPIOATTACH ioctl(2) on the
-    gpio(4) device.

-

-

-

-

-  
/dev/gpioirqu

-  
GPIOIRQ device unit u file. The output from this
-      device are three uint8_t bytes every time an interrupt fires. The bytes
-      contain the device unit, pin number and the current state of the pin.

-

-

-

-

-
The following example will output the device unit, pin and the
-    pins current state for pins 4, 5, 6, 7, 8, 9, 10, 11, 12 on gpio0:

-

-
/etc/gpio.conf contains:
-gpio0 attach gpioirq 4 0x1ff 0x04
-
-or a kernel was compiled to have the same parameters.
-
-#!/usr/pkg/bin/perl
-
-$dev = "/dev/gpioirq0";
-
-sysopen(DEV,$dev,O_RDONLY) || die "sysopen: $!";
-
-while (sysread(DEV,$b,3)) {
-    @v = unpack("CCC",$b);
-
-    print join(',',@v);
-    print "\n";
-}
-
-

-

-

-

-

-
gpio(4), drvctl(8),
-    gpioctl(8)

-

-

-

-
The gpioirq driver first appeared in
-    NetBSD 9.0.

-

-

-

-
The gpioirq driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
When an interrupt fires in most devices there is not any
-    information carried along in the interrupt as to whether or not the pin is
-    high or low. Hence the driver reads the current state of the pin after the
-    interrupt has fired and it is possible that the state of the pin could have
-    changed between the time the interrupt fired and the reading of the state.
-    As a practical matter the only time the pin state will be reported wrong is
-    if there is a very large number of interrupts happening. The driver could
-    have made some assumptions if the interrupt was only for a rising edge or
-    falling edge as in those cases it would be possible to know what the pin
-    state would have been, but in the case of the double edge, there really will
-    not be any way to be sure with most hardware and, in any case, the
-    gpio(4) infrastructure does not support getting at that
-    information even if it did exist.

-
It is important that if the gpioirq(4) device is
-    opened that it be read, as it may be possible to run the kernel out of
-    memory if the device is opened but not read and interrupts occur on a pin
-    tied to the driver.

-

-

-
-  
-    
-    
-  
-
November 5, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/gpiolock.4 4.html b/static/netbsd/man4/gpiolock.4 4.html
deleted file mode 100644
index 83541404..00000000
--- a/static/netbsd/man4/gpiolock.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOLOCK(4)Device Drivers ManualGPIOLOCK(4)

-

-

-

-
gpiolock — support
-    for multi-position keylocks attached to GPIO pins

-

-

-

-
gpiolock* at gpio? offset ? mask ?
-  

-  gpiolock* at gpio?

-

-

-

-
The gpiolock driver allows connecting of
-    multi-position keylocks over GPIO pins. The keylock driver registers with an
-    in-kernel keylock supporting system and provides kauth(9)
-    support through an experimental security model. The keylock state can be
-    queried using the hw.keylock sysctl variables. Only locks with 2-4 positions
-    are currently supported. The pin number is specified in the kernel
-    configuration with the offset locator. The
-    mask locator denotes the pins used for the lock
-    (minimum 2, maximum 4 pins are used). The offset and
-    mask can also be specified when
-    gpiolock is attached at runtime using the
-    GPIOATTACH ioctl(2) on the
-    gpio(4) device.

-

-

-

-
gpio(4), intro(4)

-

-

-

-
The gpiolock driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The gpiolock driver was written by
-    Marc Balmer
-    <marc@msys.ch>.

-

-

-
-  
-    
-    
-  
-
August 21, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/gpioow.4 4.html b/static/netbsd/man4/gpioow.4 4.html
deleted file mode 100644
index 01d72ee1..00000000
--- a/static/netbsd/man4/gpioow.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOOW(4)Device Drivers ManualGPIOOW(4)

-

-

-

-
gpioow — 1-Wire
-    bus bit-banging through GPIO pin

-

-

-

-
gpioow* at gpio? offset 0 mask 0x1
-  

-  gpioow* at gpio?
-  

-  onewire* at gpioow?

-

-

-

-
The gpioow driver allows bit-banging a
-    1-Wire bus as a master using one GPIO pin. The pin is used as a data signal.
-    The GPIO pin must be able to drive an output and read an input.

-
The pin number is specified in the kernel configuration with the
-    offset locator. The mask locator
-    should always be 0x1. The offset and
-    mask can also be specified when
-    gpioow is attached at runtime using the
-    GPIOATTACH ioctl(2) on the
-    gpio(4) device.

-

-

-

-
gpio(4), intro(4),
-    onewire(4)

-

-

-

-
The gpioow driver first appeared in
-    OpenBSD 4.0 and NetBSD
-  4.0.

-

-

-

-
The gpioow driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>
-    and was ported to NetBSD by Jeff
-    Rizzo
-    <riz@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 19, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/gpiopps.4 3.html b/static/netbsd/man4/gpiopps.4 3.html
deleted file mode 100644
index e75e6e9a..00000000
--- a/static/netbsd/man4/gpiopps.4 3.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOPPS(4)Device Drivers ManualGPIOPPS(4)

-

-

-

-
gpiopps — install
-    a PPS handler on GPIO pins

-

-

-

-
gpiopps* at gpio? offset 0 mask 0x1 flag
-    0x0

-

-

-

-
The gpiopps driver provides a 1PPS handler
-    using the PPSAPI on one or two GPIO pins.

-
The base pin number is specified in the kernel configuration file
-    with the offset locator. The
-    mask should have 1 or 2 bits set, indicating which
-    pins offset from the base pin should be used (0 .. 31). Pin configurations
-    are discussed below.

-
The flag locator modifies the pin
-    configuration:

-

-  

-  
The PPS ASSERT signal should be triggered on the negative (falling) edge
-      of the assert pin. The default is to trigger on the positive (rising) edge
-      of the pin.

-  

-  
By default, gpiopps will use double-edge
-      triggering when only a single pin is specified and the underlying GPIO
-      hardware supports it. This flag disables the use of double-edge
-      triggering.

-

-
If a single pin is specified, gpiopps uses
-    double-edge triggering to support ASSERT and CLEAR PPS signals. If the
-    underlying GPIO hardware does not support double-edge triggering, or if this
-    feature is disabled in the flag locator, then only
-    ASSERT will be signaled on the specified edge.

-
If two pins are specified, the first pin is used to trigger the
-    ASSERT signal and the second pin is used to trigger the CLEAR signal. The
-    ASSERT pin's trigger edge is specified by by the flag
-    locator, and the CLEAR pin triggers on the opposite edge. This allows ASSERT
-    and CLEAR signals to be triggered even if the underlying GPIO hardware does
-    not support double-edge triggering. In this scenario, both GPIO pins would
-    be connected in parallel to the device sending the 1PPS signals.

-
The offset, mask, and
-    flag locators can also be specified when
-    gpiopps is attached at runtime using the
-    GPIOATTACH ioctl(2) on the
-    gpio(4) device.

-

-

-

-
gpio(4), drvctl(8),
-    gpioctl(8)

-

-

-

-
The gpiopps driver first appeared in
-    NetBSD 9.0.

-

-

-

-
The gpiopps driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
May 11, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/gpiopwm.4 4.html b/static/netbsd/man4/gpiopwm.4 4.html
deleted file mode 100644
index a12e53d0..00000000
--- a/static/netbsd/man4/gpiopwm.4 4.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOPWM(4)Device Drivers ManualGPIOPWM(4)

-

-

-

-
gpiopwm — support
-    for pulsing GPIO pins in software

-

-

-

-
gpiopwm* at gpio? offset ? mask 1
-  

-  gpiopwm* at gpio?

-

-

-

-
The gpiopwm driver allows for pulsing GPIO
-    pins in software using the callout(9) facility. The pulse
-    frequency and duty cycle are specified indirectly by setting an
-    “on” and “off” period, in ticks. Both values are
-    accessible as sysctl(3) variables.

-

-

-

-
The following sysctl(3) variables are used to
-    define the pulsing:

-

-  
hw.gpiopwmN.off

-  
Define the “off” period in ticks.

-  
hw.gpiopwmN.on

-  
Define the “on” period in ticks.

-

-
Only when both the “on” and the “off”
-    period are set to values higher than zero pulsing will start. To stop the
-    pulsing, set either value to zero.

-

-

-

-
To pulse a pin on a machine with 100 ticks/second with a frequency
-    of 1Hz and a duty cycle of 20%, the “on” period must be set to
-    20 and the “off” period must be set to 80. The following
-    example will pulse the error LED of a Soekris net4801 with a frequency of 1
-    Hz and a duty cycle of 20%:

-

-
# gpioctl gpio0 20 set pp
-# gpioctl gpio0 attach gpiopwm 20 1
-# sysctl -w hw.gpiopwm0.off=80
-# sysctl -w hw.gpiopwm0.on=20

-

-

-

-

-
gpio(4), intro(4),
-    gpioctl(8), sysctl(8)

-

-

-

-
The gpiopwm driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The gpiopwm driver was written by
-    Marc Balmer
-    <marc@msys.ch>.

-

-

-
-  
-    
-    
-  
-
November 13, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/gpiosim.4 4.html b/static/netbsd/man4/gpiosim.4 4.html
deleted file mode 100644
index d3a0b614..00000000
--- a/static/netbsd/man4/gpiosim.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
GPIOSIM(4)Device Drivers ManualGPIOSIM(4)

-

-

-

-
gpiosim — General
-    Purpose Input/Output Simulator

-

-

-

-
pseudo-device gpiosim

-

-

-

-
The gpiosim pseudo-device simulates a
-    64-bit wide gpio(4) device. The state of the simulated
-    device can be manipulated through the sysctl(8) interface.
-    For this purpose, access the "hw.gpiosim<N>.value"
-    sysctl(8) variable, where "<N>" denotes
-    the number of the gpiosim instance.

-
Both edge and level interrupts are simulated. The
-    "hw.gpiosim<N>.ms" sysctl(8) variable will
-    change the amount of time between callout(9) ticks for
-    simulated level interrupts.

-

-

-

-
gpio(4), gpioirq(4),
-    sysctl(8)

-

-

-

-
The gpiosim driver was written by
-    Marc Balmer
-    <marc@msys.ch> Simulated
-    interrupts added by Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
November 8, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/gre.4 3.html b/static/netbsd/man4/gre.4 3.html
deleted file mode 100644
index a48863b5..00000000
--- a/static/netbsd/man4/gre.4 3.html	
+++ /dev/null
@@ -1,305 +0,0 @@
-
-  
-    
-    
-    
-  
-
GRE(4)Device Drivers ManualGRE(4)

-

-

-

-
gre —
-    encapsulating network device

-

-

-

-
pseudo-device gre

-

-

-

-
The gre network interface pseudo device
-    encapsulates datagrams into IP. These encapsulated datagrams are routed to a
-    destination host, where they are decapsulated and further routed to their
-    final destination. The “tunnel” appears to the inner datagrams
-    as one hop.

-
gre interfaces are dynamically created and
-    destroyed with the ifconfig(8)
-    create and destroy
-    subcommands.

-
This driver currently supports the following modes of
-  operation:

-

-  
GRE encapsulation (IP protocol number 47)

-  
Encapsulated datagrams are prepended an outer datagram and a GRE header.
-      The GRE header specifies the type of the encapsulated datagram and thus
-      allows for tunneling other protocols than IP like e.g. AppleTalk. GRE mode
-      is also the default tunnel mode on Cisco routers. This is also the default
-      mode of operation of the greX
-      interfaces.

-  
GRE in UDP encapsulation

-  
Encapsulated datagrams are prepended a GRE header, and then they are sent
-      over a UDP socket. Userland may create the socket and
-      “delegate” it to the kernel using the
-      GRESSOCK ioctl(2). If userland
-      does not supply a socket, then the kernel will create one using the
-      addresses and ports supplied by ioctl(2)s
-      SIOCSLIFPHYADDR,
-      GRESADDRD, and/or
-      GRESADDRS.

-  
MOBILE encapsulation (IP protocol number 55)

-  
Datagrams are encapsulated into IP, but with a shorter encapsulation. The
-      original IP header is modified and the modifications are inserted between
-      the so modified header and the original payload. Like
-      gif(4), only for IP in IP encapsulation.

-

-
The greX interfaces
-    support a number of ioctl(2)s, such as:

-

-  
GRESADDRS:

-  
Set the IP address of the local tunnel end. This is the source address set
-      by or displayed by ifconfig for the
-      greX interface.

-  
GRESADDRD:

-  
Set the IP address of the remote tunnel end. This is the destination
-      address set by or displayed by ifconfig for the
-      greX interface.

-  
GREGADDRS:

-  
Query the IP address that is set for the local tunnel end. This is the
-      address the encapsulation header carries as local address (i.e. the real
-      address of the tunnel start point.)

-  
GREGADDRD:

-  
Query the IP address that is set for the remote tunnel end. This is the
-      address the encapsulated packets are sent to (i.e. the real address of the
-      remote tunnel endpoint.)

-  
GRESPROTO:

-  
Set the operation mode to the specified IP protocol value. The protocol is
-      passed to the interface in (struct ifreq)->ifr_flags. The operation
-      mode can also be given as
-    

-      
link0 link2

-      
IPPROTO_UDP

-      
link0 -link2

-      
IPPROTO_GRE

-      
-link0 -link2

-      
IPPROTO_MOBILE

-    

-    
to ifconfig(8).

-  

-  
GREGPROTO:

-  
Query operation mode.

-  
GRESSOCK:

-  
Delegate a socket from userland to a tunnel interface in UDP encapsulation
-      mode. The file descriptor for the socket is passed in (struct
-      ifreq)->ifr_value.

-

-
Note that the IP addresses of the tunnel endpoints may be the same
-    as the ones defined with ifconfig(8) for the interface (as
-    if IP is encapsulated), but need not be, as e.g. when encapsulating
-    AppleTalk.

-

-

-

-

-

-
Configuration example:

-

-
Host X-- Router A  --------------tunnel---------- Router D ----Host E
-          |                                          |
-           \                                        /
-            +----- Router B ----- Router C --------+

-

-
On Router A (NetBSD):

-

-
   # route add default B
-   # ifconfig greN create
-   # ifconfig greN A D netmask 0xffffffff linkX up
-   # ifconfig greN tunnel A D
-   # route add E D

-

-
On Router D (Cisco):

-

-
   Interface TunnelX
-    ip unnumbered D   ! e.g. address from Ethernet interface
-    tunnel source D   ! e.g. address from Ethernet interface
-    tunnel destination A
-   ip route C <some interface and mask>
-   ip route A mask C
-   ip route X mask tunnelX

-

-
or on Router D (NetBSD):

-

-
   # route add default C
-   # ifconfig greN create
-   # ifconfig greN D A
-   # ifconfig tunnel greN D A

-

-
If all goes well, you should see packets flowing ;-)

-
If you want to reach Router A over the tunnel (from Router D
-    (Cisco)), then you have to have an alias on Router A for e.g. the Ethernet
-    interface like:

-

-
     ifconfig <etherif> alias Y

-

-
and on the Cisco

-

-
     ip route Y mask tunnelX

-

-

-

-

-
A similar setup can be used to create a link between two private
-    networks (for example in the 192.168 subnet) over the Internet:

-

-
192.168.1.* --- Router A  -------tunnel-------- Router B --- 192.168.2.*
-                   \                              /
-                    \                            /
-                      +----- the Internet ------+

-

-
Assuming Router A has the (external) IP address A and the internal
-    address 192.168.1.1, while Router B has external address B and internal
-    address 192.168.2.1, the following commands will configure the tunnel:

-
On Router A:

-

-
   # ifconfig greN create
-   # ifconfig greN 192.168.1.1 192.168.2.1
-   # ifconfig greN tunnel A B
-   # route add -net 192.168.2 -netmask 255.255.255.0 192.168.2.1

-

-
On Router B:

-

-
   # ifconfig greN create
-   # ifconfig greN 192.168.2.1 192.168.1.1
-   # ifconfig greN tunnel B A
-   # route add -net 192.168.1 -netmask 255.255.255.0 192.168.1.1

-

-

-

-

-
To setup the same tunnel as above, but using GRE in UDP
-    encapsulation instead of GRE encapsulation, set flags
-    link0 and link2, and specify
-    source and destination UDP ports.

-
On Router A:

-

-
   # ifconfig greN create
-   # ifconfig greN link0 link2
-   # ifconfig greN 192.168.1.1 192.168.2.1
-   # ifconfig greN tunnel A,port-A B,port-B
-   # route add -net 192.168.2 -netmask 255.255.255.0 192.168.2.1

-

-
On Router B:

-

-
   # ifconfig greN create
-   # ifconfig greN link0 link2
-   # ifconfig greN 192.168.2.1 192.168.1.1
-   # ifconfig greN tunnel B,port-B A,port-A
-   # route add -net 192.168.1 -netmask 255.255.255.0 192.168.1.1

-

-

-

-

-
Along these lines, you can use GRE tunnels to interconnect two
-    IPv6 networks over an IPv4 infrastructure, or to hook up to the IPv6
-    internet via an IPv4 tunnel to a Cisco router.

-

-
2001:db8:1::/64 -- NetBSD A  ---- Tunnel ---- Cisco B --- IPv6 Internet
-                   \                              /
-                    \                            /
-                     +------ the Internet ------+

-

-
The example will use the following addressing:

-

-  
NetBSD

-  
A has the IPv4 address A and the IPv6 address 2001:db8:1::1 (connects to
-      internal network 2001:db8:1::/64).

-  
Cisco B

-  
has external IPv4 address B.

-  
All the IPv6 internet world

-  
is behind B, so A wants to route 0::0/0 (the IPv6 default route) into the
-      tunnel.

-  
The GRE tunnel

-  
will use a transit network: 2001:db8:ffff::1/64 on the
-      NetBSD side, and ::2/64 on the Cisco side.

-

-
Then the following commands will configure the tunnel:

-
On Router A (NetBSD):

-

-
   # ifconfig greN create
-   # ifconfig greN inet6 2001:db8:ffff::1/64
-   # ifconfig greN tunnel A B
-   # route add -inet6 2001:db8:ffff::/64 2001:db8:ffff::2 -ifp greN
-   # route add -inet6 0::0/0 2001:db8:ffff::2 -ifp greN

-

-
On Router B (Cisco):

-

-
   Interface TunnelX
-     tunnel mode gre ip
-     ipv6 address 2001:db8:ffff::2/64   ! transfer network
-     tunnel source B                    ! e.g. address from LAN interface
-     tunnel destination A               ! where the tunnel is connected to
-   ipv6 route 2001:db8::/64 TunnelX     ! route this network through tunnel

-

-

-

-

-

-
The MTU of greX interfaces
-    is set to 1476 by default to match the value used by Cisco routers. This may
-    not be an optimal value, depending on the link between the two tunnel
-    endpoints. It can be adjusted via ifconfig(8).

-
There needs to be a route to the decapsulating host that does not
-    run over the tunnel, as this would be a loop. (This is not relevant for
-    IPv6-over-IPv4 tunnels, of course.)

-
In order to tell ifconfig(8) to actually mark
-    the interface as up, the keyword “up” must be given last on
-    its command line.

-
The kernel must be set to forward datagrams by either
-    option  in
-    the kernel config file or by issuing the appropriate option to
-    sysctl(8).

-

-

-

-
atalk(4), gif(4),
-    inet(4), ip(4),
-    netintro(4), options(4),
-    protocols(5), ifconfig(8),
-    sysctl(8)

-
A description of GRE encapsulation can be found in RFC 1701 and
-    RFC 1702.

-
A description of MOBILE encapsulation can be found in RFC
-  2004.

-

-

-

-
Heiko W.Rupp
-    <hwr@pilhuhn.de>
-  

-  David Young
-    <dyoung@NetBSD.org>
-    (GRE in UDP encapsulation, bug fixes)

-

-

-

-
The GRE RFCs are not yet fully implemented (no GRE options).

-
The MOBILE encapsulation appears to have been broken since it was
-    first added to NetBSD, until August 2006. It is
-    known to interoperate with another gre in MOBILE
-    mode, however, it has not been tested for interoperability with any other
-    implementation of RFC 2004.

-
The NetBSD base system does not (yet)
-    contain a daemon for automatically establishing a UDP tunnel between a host
-    behind a NAT router and a host on the Internet.

-

-

-
-  
-    
-    
-  
-
January 4, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/gscan.4 4.html b/static/netbsd/man4/gscan.4 4.html
deleted file mode 100644
index 327aac2f..00000000
--- a/static/netbsd/man4/gscan.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
GSCAN(4)Device Drivers ManualGSCAN(4)

-

-

-

-
gscan —
-    Geschwister Schneider (and clones) USB to CAN interface
-    driver

-

-

-

-
gscan* at uhub?

-

-

-

-
The gscan driver supports the Geschwister
-    Schneider USB to CAN device, and devices based on the candleLight
-  firmware.

-

-

-

-
usb(4), can(4),
-    ifconfig(8), canconfig(8)

-

-

-

-
The gscan driver first appeared in
-    NetBSD 10.2.

-

-

-

-
The gscan driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
April 3, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/gsip.4 4.html b/static/netbsd/man4/gsip.4 4.html
deleted file mode 100644
index fccd6d11..00000000
--- a/static/netbsd/man4/gsip.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
GSIP(4)Device Drivers ManualGSIP(4)

-

-

-

-
gsip — National
-    Semiconductor DP83820 Gigabit Ethernet driver

-

-

-

-
gsip* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The gsip device driver supports Gigabit
-    Ethernet interfaces based on the National Semiconductor DP83820 Gigabit
-    Ethernet chips.

-
The National Semiconductor DP83820 is found on NetGear GA-622,
-    Asante FriendlyNet GigaNIX, D-Link DGE-500T, SMC 9452TX and 9462TX, Accton
-    EN1407-T, Planex GN-1000TE, ARK SOHO GA2000T and GA2500T, and other low-cost
-    Gigabit Ethernet cards. It uses an external PHY or an external 10-bit
-    interface.

-
The DP83820 supports VLAN tag insertion/removal in hardware. The
-    gsip driver supports this feature of the chip.

-
The DP83820 supports IPv4/TCP/UDP checksumming in hardware. The
-    gsip driver supports this feature of the chip. See
-    ifconfig(8) for information on how to enable this
-  feature.

-
The DP83820 chip is a close relative of the DP83815 10/100
-    Ethernet chip, which is supported by the sip(4) driver,
-    hence the gsip name.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), vlan(4),
-    ifconfig(8)

-

-

-

-
The gsip driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The gsip driver was written by
-    Jason R. Thorpe
-  ⟨thorpej@NetBSD.org⟩.

-

-

-

-
The gsip driver does not support the
-    10-bit interface, which is required in order to support fiber-optic
-  media.

-

-

-
-  
-    
-    
-  
-
June 2, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/gtp.4 4.html b/static/netbsd/man4/gtp.4 4.html
deleted file mode 100644
index 109870e9..00000000
--- a/static/netbsd/man4/gtp.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
GTP(4)Device Drivers ManualGTP(4)

-

-

-

-
gtp — Gemtek PCI
-    FM radio device

-

-

-

-
gtp* at pci? flags 0x00
-  

-  radio* at gtp?

-

-

-

-
The gtp driver provides support for the
-    Gemtek PCI and Guillemot MaxiRadio FM2000 FM radio tuners.

-
The Gemtek PCI cards are stereo FM tuners that can tune in the
-    range 87.5 - 108.0 MHz, report signal status and stereo/mono on the current
-    frequency, force audio output to mono, perform hardware signal search, and
-    have an internal AFC.

-
The card is based on the TEA5757 chip; see
-    radio(4) for details.

-
The flags control the driver behavior. For example, with flags
-    0x01 the driver will assume that a TEA5759 chip is used.

-

-

-

-
intro(4), pci(4),
-    radio(4), radio(9)

-

-

-

-
The gtp device driver appeared in
-    OpenBSD 3.2 and subsequently in
-    NetBSD 1.6 wherein it replaced the
-    mr(4) driver.

-

-

-

-
The gtp driver and the man page was
-    written by Vladimir Popov
-    <jumbo@narod.ru>.

-

-

-

-
It is impossible to determine which frequency the card is tuned
-    to. Thus, the driver will report an internally stored value even if it is
-    not correct (changed by some program that uses direct port access).

-

-

-
-  
-    
-    
-  
-
March 26, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/gus.4 3.html b/static/netbsd/man4/gus.4 3.html
deleted file mode 100644
index bda17a46..00000000
--- a/static/netbsd/man4/gus.4 3.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
GUS(4)Device Drivers ManualGUS(4)

-

-

-

-
gus — Gravis
-    UltraSound/UltraSound MAX audio device driver

-

-

-

-
gus0 at isa? port 0xPPP irq X drq Y drq2 Z
-  

-  audio* at audiobus?

-

-

-

-
The gus driver provides support for the
-    Gravis UltraSound (GUS) and GUS MAX audio cards. Both cards have on-board
-    memory which is used for seamless playback of samples. They can play back 8-
-    or 16-bit samples at up to 44.1kHz. They can record 8-bit samples at up to
-    44.1kHz. The UltraSound MAX is a full-duplex sound device, and if configured
-    with two DRQ channels can be used for simultaneous playback and recording.
-    The I/O port base is jumper-selected, and may be chosen from 0x210-0x260 in
-    steps of 0x10. (The normal setting is 0x220.) The GUS takes 16 ports at its
-    base address and 8 ports at its base address + 0x100.

-
The IRQ is software programmed, so you may select any IRQ from the
-    set {3,5,7,9,11,12,15}. The DRQ lines are software programmed, and may be
-    chosen from {1,3,5,6,7}. The drq2 field in the configuration file line
-    specifies a second DRQ line for recording. If there is no drq2 field in the
-    config file, the playback channel will be used for recording DMA and only
-    half-duplex mode will be available.

-
The Gravis UltraSound MAX has an additional CODEC onboard which is
-    addressed with four ports at an offset of 0x10C from the base ports
-    (0x31C-0x36C).

-

-

-

-
audio(4)

-

-

-

-
Gravis UltraSound Low-Level Toolkit, Revision 2.01, 20 May 1993,
-    published by Advanced Gravis and Forte Technologies.

-

-

-

-
The gus device driver appeared in
-    NetBSD 1.1.

-

-

-

-
The full-duplex features of the GUS MAX have not been fully
-    tested, and full-duplex on the original GUS may not be possible at all.

-
Only two voices on the GF1 synthesizer chip are used by this
-    driver (for left and right channels).

-
Manipulating the mixer while audio samples are playing can lead to
-    device driver confusion (and maybe even a system panic).

-
Manipulating the mixer device seems to create pregnant system
-    pauses, probably due to excessive interrupt masking.

-
The joystick and MIDI port interfaces are not supported.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/guspnp.4 4.html b/static/netbsd/man4/guspnp.4 4.html
deleted file mode 100644
index aeada556..00000000
--- a/static/netbsd/man4/guspnp.4 4.html	
+++ /dev/null
@@ -1,97 +0,0 @@
-
-  
-    
-    
-    
-  
-
GUSPNP(4)Device Drivers ManualGUSPNP(4)

-

-

-

-
guspnp — Am78C201
-    audio device driver

-

-

-

-
guspnp* at isapnp?
-  

-  audio* at audiobus?

-
There should be no limit caused by the driver on the number of
-    drivers or cards active in the system.

-

-

-

-
The guspnp driver provides support for
-    audio subsystems using the Interwave (Am78C20x) family of ICs, usually the
-    Gravis Ultrasound Plug and Play. Unlike the gus
-    driver guspnp driver does not require any local memory for the IC, but uses
-    the codec for both playback and recording. The
-    guspnp driver can simultaneously playback and record
-    8- and 16-bit samples at frequencies from 5.51kHz to 48kHz.

-
The guspnp driver relies on
-    isapnp to allocate suitable resources for it. This
-    version of the driver only uses the first logical device of the five the
-    Interwave IC has. The four unused logical devices are the ATAPI CD-ROM
-    device, PnP Joystick device, legacy soundcard emulation device
-    (SoundBlaster) and MIDI serial device. Support for at least ATAPI CD-ROM and
-    Joystick is being worked on. This version of the driver will use 1 IRQ and 2
-    DRQs.

-

-

-

-
Cards supported by the guspnp driver
-    include:

-
    
-  
  • Gravis Ultrasound PNP, and compatibles
    • 
-

-

-

-

-
audio(4), gus(4),
-    isapnp(4)

-

-

-

-
Interwave(tm) IC Am78C201/202 Programmer's Guide Rev. 2. 1996.
-    Advanced Micro Devices.

-

-

-

-
The guspnp driver appeared in
-    NetBSD 1.3.

-

-

-

-
Kari Mettinen
-    <Kari.Mettinen@helsinki.fi>,
-    University of Helsinki.

-

-

-

-
Sometimes you can cause a hiss on either left or right channel, or
-    both. You can usually make it disappear by playing random data, however this
-    might not be a very nice thing to your audio equipment, but it is the only
-    way I have found out to be effective.

-
Only the Codec is used in this version of the driver, therefore
-    only 2 channels are supported (left and right). Also sound quality is
-    probably worse at lower kHz compared to playing through the synthesizer
-    which does interpolation.

-
If the implementation has a 'bad' oscillator, using frequencies
-    44.8kHz and 38.4kHz will result in incorrect playback frequency. The author
-    has a GUS PnP Pro which displays this behavior.

-
Other members of the Interwave family have not been tested and
-    don't have the glue needed to make them work. Should someone need to
-    implement it, not many changes in the existing code are needed. Output
-    voltage control in register CFIG2 [7] should be set differently for some
-    other members of the family.

-
Other architectures than i386 haven't been tested. The bus_space
-    abstraction has been used from the beginning, so it should work.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/hcide.4 4.html b/static/netbsd/man4/hcide.4 4.html
deleted file mode 100644
index bffb716e..00000000
--- a/static/netbsd/man4/hcide.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
HCIDE(4)Device Drivers ManualHCIDE(4)

-

-

-

-
dtide — HCCS IDE
-    interface driver

-

-

-

-
hcide* at podulebus0 slot ?
-  

-  ata* at hcide? channel ?

-

-

-

-
The dtide driver handles an HCCS IDE
-    interface plugged into an Acorn expansion slot. It uses the standard
-    NetBSD IDE controller driver, and hence can use the
-    standard atabus driver.

-
The card provides three IDE channels. The internal 44-way IDE
-    connector is channel 0, the internal 40-way connector is channel 1 and the
-    external connector is channel 2.

-

-

-

-
atabus(4), atapibus(4),
-    podulebus(4), wd(4)

-

-

-

-
The driver was derived by reverse-engineering the card, so it may
-    not handle the card entirely optimally.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/hdaudio.4 4.html b/static/netbsd/man4/hdaudio.4 4.html
deleted file mode 100644
index 74d2af84..00000000
--- a/static/netbsd/man4/hdaudio.4 4.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
HDAUDIO(4)Device Drivers ManualHDAUDIO(4)

-

-

-

-
hdaudio — High
-    Definition Audio device driver

-

-

-

-
hdaudio* at pci? dev ? function ?
-  

-  hdafg* at hdaudiobus?
-  

-  audio* at audiobus?

-

-  

-  options HDAUDIOVERBOSE
-  

-  options HDAUDIO_DEBUG
-  

-  options HDAFG_DEBUG

-

-

-

-
The hdaudio device driver is expected to
-    support any PCI device which is compliant to the High Definition Audio
-    Specification 1.0. It was written from scratch following the Intel HD Audio
-    and Microsoft Universal Audio Architecture specifications.

-
The driver consists of two interlinked components, which reflects
-    the hardware design. The hdaudio component
-    interfaces with a PCI/PCIe bus and provides an
-    hdaudiobus(4) onto which different function groups attach.
-    Each function group (e.g. audio, vendor-specific modem) is exported as a
-    separate child device of the hdaudio controller.
-    Audio function groups (a.k.a. audio codec) are exported as
-    hdafg(4) devices.

-
Audio codecs are available from a number of manufacturers and are
-    made up of a number of widgets (e.g. audio mixer, output pin,
-    analog-to-digital converter). The way the widgets are interlinked varies
-    significantly between implementations. The tree of widgets must be parsed
-    and mapped to mixer(4) controls. As part of this process,
-    loops in the inter-codec links must be detected and muted, bi-directional
-    pins must be set up appropriately and the locations of pins determined.
-    hdaudio works backwards by starting with a list of
-    desired, consistent and compatible mixer(4) controls and
-    configuring/discovering appropriate widget link routes to fit.

-
By following the published mechanisms for common implementations
-    of widget parsing, it is expected that nearly all High Definition Audio
-    devices will be supported without requiring per-device quirks.

-

-

-

-
In addition to many on-board sound cards included in mainboards,
-    the following add-on card is supported:

-

-  
TerraTec Aureon 7.1 PCIe

-  
 

-

-

-

-

-
audio(4), mixer(4),
-    pci(4), hdaudioctl(8),

-
Intel
-    High Definition Audio

-
Audio
-    Device Technologies for Windows

-

-

-

-
The hdaudio device driver appeared in
-    NetBSD 5.1.

-

-

-

-
The hdaudio driver was written by
-    Jared McNeill
-    <jmcneill@NetBSD.org>
-    under contract by
-    Precedence Technologies
-    Ltd. The UAA-compliant widget parser is derived from the
-    FreeBSD snd_hda(4) driver.

-

-

-

-
The following items are not yet implemented:

-
    
-  
  • Improve power management support when driver is idle
    • 
-  
  • Add support for non-PCM output formats
    • 
-  
  • Handle unsolicited RIRB messages
    • 
-  
  • Modem function groups
    • 
-  
  • 24-bit and 20-bit hardware formats cannot yet be used. Since the
-      machine-independent audio layer converts all input from userland and the
-      hardware layer to 16-bit precision for processing, there would currently
-      be no advantage in using them.
    • 
-

-

-

-
-  
-    
-    
-  
-
March 21, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/hifn.4 4.html b/static/netbsd/man4/hifn.4 4.html
deleted file mode 100644
index d3efc1ed..00000000
--- a/static/netbsd/man4/hifn.4 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
HIFN(4)Device Drivers ManualHIFN(4)

-

-

-

-
hifn — Hifn
-    7751/7951/7811/7955/7956 crypto accelerator

-

-

-

-
hifn* at pci? dev ? function ?

-

-

-

-
The hifn driver supports various cards
-    containing the Hifn 7751, 7951, 7811, 7955, and 7956 chipsets, such as

-

-

-  
Invertex AEON

-  
No longer being made. Came as 128KB SRAM model, or 2MB DRAM model.

-  
Hifn 7751

-  
Reference board with 512KB SRAM.

-  
PowerCrypt

-  
Comes with 512KB SRAM.

-  
XL-Crypt

-  
Only board based on 7811 (which is faster than 7751 and has a random
-      number generator).

-  
NetSec 7751

-  
Supports the most IPsec sessions, with 1MB SRAM.

-  
Soekris Engineering vpn1201 and vpn1211

-  
Contains a 7951 and supports symmetric and random number operations.

-  
Soekris Engineering vpn1401 and vpn1411

-  
Contains a 7955 and supports symmetric and random number operations.

-

-

-
The hifn driver registers itself to
-    accelerate DES, Triple-DES, AES (7955 and 7956 only), ARC4, MD5, MD5-HMAC,
-    SHA1, and SHA1-HMAC operations for opencrypto(9), and thus
-    for ipsec(4) and crypto(4).

-
The Hifn 7951, 7811, 7955, and 7956 may also supply data to the
-    kernel rnd(4) subsystem.

-

-

-

-
crypto(4), intro(4),
-    ipsec(4), rnd(4),
-    opencrypto(9)

-

-

-

-
The hifn device driver appeared in
-    OpenBSD 2.7. The hifn device
-    driver was imported to FreeBSD 5.0, back-ported to
-    FreeBSD 4.8, and subsequently imported into
-    NetBSD 2.0.

-

-

-

-
The Hifn 9751 shares the same PCI ID. This chip is basically a
-    7751, but with the cryptographic functions missing. Instead, the 9751 is
-    only capable of doing compression. Since we do not currently attempt to use
-    any of these chips to do compression, the 9751-based cards are not
-  useful.

-
Support for the 7955 and 7956 is incomplete; the asymmetric crypto
-    facilities are to be added and the performance is suboptimal.

-

-

-

-
The 7751 chip starts out at initialization by only supporting
-    compression. A proprietary algorithm, which has been reverse engineered, is
-    required to unlock the cryptographic functionality of the chip. It is
-    possible for vendors to make boards which have a lock ID not known to the
-    driver, but all vendors currently just use the obvious ID which is 13 bytes
-    of 0.

-

-

-
-  
-    
-    
-  
-
June 13, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/hil.4 4.html b/static/netbsd/man4/hil.4 4.html
deleted file mode 100644
index f185a211..00000000
--- a/static/netbsd/man4/hil.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
HIL(4)Device Drivers ManualHIL(4)

-

-

-

-
hil — introduction
-    to HP-HIL support

-

-

-

-

-

-
hil* at intio?

-

-  

-  hilkbd* at hil?
-  

-  hilms* at hil?
-  

-  hilid* at hil?

-

-

-

-

-
The hil interface provides access to the
-    “Human Interface Loop” controller found on many HP
-    workstations.

-
It provides generic HIL management and interfaces for child
-    devices, such as keyboards, button boxes, mice, graphics tablet, and ID
-    modules.

-
NetBSD provides support for the following
-    devices:

-

-

-

-  
hilid(4)

-  
HIL ID module device

-  
hilkbd(4)

-  
HIL keyboard device

-  
hilms(4)

-  
HIL mouse and graphics tablet device

-

-

-

-

-

-
intro(4)

-

-

-
-  
-    
-    
-  
-
February 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/hilid.4 4.html b/static/netbsd/man4/hilid.4 4.html
deleted file mode 100644
index 4041628a..00000000
--- a/static/netbsd/man4/hilid.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
HILID(4)Device Drivers ManualHILID(4)

-

-

-

-
hilid — HIL ID
-    module device

-

-

-

-
hilid* at hil?

-

-

-

-
This driver recognizes the HIL “ID module” device.
-    The only purpose of this device is to provide a small, unique,
-  bitstring.

-

-

-

-
hil(4), intro(4)

-

-

-

-
There is currently no way to communicate the ID module bitstring
-    to userland applications.

-

-

-
-  
-    
-    
-  
-
February 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/hilkbd.4 4.html b/static/netbsd/man4/hilkbd.4 4.html
deleted file mode 100644
index 46003e4f..00000000
--- a/static/netbsd/man4/hilkbd.4 4.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
HILKBD(4)Device Drivers ManualHILKBD(4)

-

-

-

-
hilkbd — HIL
-    keyboard device

-

-

-

-
hilkbd* at hil?
-  

-  wskbd* at hilkbd?

-

-  

-  option HILKBD_LAYOUT=XXX

-

-

-

-
This driver supports HIL keyboards within the
-    wscons(4) framework. It doesn't provide direct device
-    driver entry points, but makes its functions available through the internal
-    wskbd(4) interface.

-
The hilkbd driver supports a number of
-    different key mappings. By default, the layout corresponding to the keyboard
-    model as probed by the hilkbd driver will be used. A
-    different layout can be chosen either with the kernel option
-    “HILKBD_LAYOUT” at compile time, or with the
-    wsconsctl(8) utility (variable:
-    “keyboard.encoding”) at runtime.

-
The supported key mappings are at this time:

-

-

-

-  
KB_DE

-  
(de) German with “dead accents”.

-  
KB_FR

-  
(fr) French with “dead accents”.

-  
KB_SV

-  
(sv) Swedish.

-  
KB_UK

-  
(uk) British.

-  
KB_US

-  
(us) English/US keyboard mapping.

-

-

-
The KB_DE mapping can be used in the KB_NODEAD (.nodead) variant.
-    This switches off the “dead accents”.

-

-

-

-
To set a Swedish keyboard mapping, use wsconsctl
-    keyboard.encoding=sv. To set it at kernel build time, regardless of
-    what keyboard is plugged, add the following to the kernel configuration
-    file:

-

-
option HILKBD_LAYOUT="KB_SV"

-

-

-

-

-
hil(4), intro(4),
-    wskbd(4), wsconsctl(8)

-

-

-

-
The list of built-in mappings is incomplete and has grown as
-    people submitted information about their particular layout.

-
The Swedish and British layout have been reconstructed from tables
-    in the old HIL code present in the hp300 port, and have not been tested.

-

-

-
-  
-    
-    
-  
-
February 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/hilms.4 4.html b/static/netbsd/man4/hilms.4 4.html
deleted file mode 100644
index a0d3ba1a..00000000
--- a/static/netbsd/man4/hilms.4 4.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
HILMS(4)Device Drivers ManualHILMS(4)

-

-

-

-
hilms — HIL mouse
-    and graphics tablet device

-

-

-

-
hilms* at hil?
-  

-  wsmouse* at hilms? mux 0

-

-

-

-
This driver supports HIL mice and graphics tablet within the
-    wscons(4) framework. It doesn't provide direct device
-    driver entry points, but makes its functions available through the internal
-    wsmouse(4) interface.

-

-

-

-
hil(4), intro(4),
-    wsmouse(4)

-

-

-
-  
-    
-    
-  
-
February 9, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/hme.4 4.html b/static/netbsd/man4/hme.4 4.html
deleted file mode 100644
index fa3a6a20..00000000
--- a/static/netbsd/man4/hme.4 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
HME(4)Device Drivers ManualHME(4)

-

-

-

-
hme — Sun
-    Microelectronics STP2002-STQ Ethernet interfaces device driver

-

-

-

-
hme* at pci? dev ? function ?
-  

-  hme* at sbus? slot ? offset ?

-

-

-

-
The hme driver supports Sun
-    Microelectronics STP2002-STQ Fast Ethernet interfaces.

-

-

-

-
The hme driver supports the on-board
-    Ethernet interfaces of many Sun UltraSPARC workstation and server
-  models.

-
Cards supported by the hme driver
-  include:

-

-
    
-  
  • Sun PCI SunSwift Adapter (“SUNW,hme”)
    • 
-  
  • Sun SBus SunSwift Adapter (“hme” and
-      “SUNW,hme”)
    • 
-  
  • Sun PCI Sun100BaseT Adapter 2.0 (“SUNW,hme”)
    • 
-  
  • Sun SBus Sun100BaseT 2.0 (“SUNW,hme”)
    • 
-  
  • Sun PCI Quad FastEthernet Controller (“SUNW,qfe”)
    • 
-  
  • Sun SBus Quad FastEthernet Controller (“SUNW,qfe”)
    • 
-

-
The STP2002 family supports hardware checksumming to assist in
-    computing IPv4 TCP/UDP checksums. The hme driver
-    supports this feature of the chip. See ifconfig(8) for
-    information on how to enable this feature.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ukphy(4),
-    ifconfig(8)

-
Sun Microelectronics,
-    STP2002QFP Fast Ethernet, Parallel Port, SCSI (FEPS)
-    User's Guide,
-    http://mediacast.sun.com/users/Barton808/media/STP2002QFP-FEPs_UG.pdf,
-    April 1996.

-

-

-

-
The hme driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The hme driver was written by
-    Paul Kranenburg ⟨pk@NetBSD.org⟩.

-

-

-

-
Connecting a MII transceiver on those cards that support it will
-    cause the RJ45 connector to be detected as PHY instance 1, instead of the
-    default instance 0.

-

-

-
-  
-    
-    
-  
-
June 23, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/hpacel.4 4.html b/static/netbsd/man4/hpacel.4 4.html
deleted file mode 100644
index 0617d50c..00000000
--- a/static/netbsd/man4/hpacel.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
HPACEL(4)Device Drivers ManualHPACEL(4)

-

-

-

-
hpacel — HP 3D
-    DriveGuard accelerometer

-

-

-

-
hpacel* at acpi?

-

-

-

-
The hpacel device driver supports
-    accelerometers that are commonly available in Hewlett-Packard laptops. The
-    supported chip is LIS3LV02DL from
-    STMicroelectronics, although other chips from the same family, such as
-    LIS3LV02DQ, may also work, provided that the vendor
-    has implemented suitable ACPI access methods.

-
The hpacel driver reports the acceleration
-    readings of the X-, Y-, and Z-axis via the envsys(4) API
-    and the envstat(8) command.

-

-

-

-
acpi(4), aps(4),
-    hpqlb(4), wmihp(4)

-
STMicroelectronics,
-    LIS3LV02DL: 3-Axis - ±2g/±6g digital output
-    low voltage linear accelerometer. AN2381 Application Note,
-    Revision 1,
-    http://www.st.com/stonline/products/literature/anp/12441.pdf,
-    June, 2006.

-

-

-

-
The hpacel device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jukka Ruohonen
-    ⟨jruohonen@iki.fi⟩

-

-

-

-
The used accelerometer chip is capable of generating wake-up,
-    direction detection, and free-fall interrupts. In the ideal situation these
-    could be used to evoke possible emergency action. However, the
-    hpacel driver only reports the readings from the
-    accelerometer via sysmon_envsys(9).

-

-

-
-  
-    
-    
-  
-
September 7, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/hpqlb.4 4.html b/static/netbsd/man4/hpqlb.4 4.html
deleted file mode 100644
index 6e855b1b..00000000
--- a/static/netbsd/man4/hpqlb.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
HPQLB(4)Device Drivers ManualHPQLB(4)

-

-

-

-
hpqlb — HP Quick
-    Launch Buttons

-

-

-

-
hpqlb* at acpi?

-

-

-

-
Many HP notebook computers come with hotkeys. The
-    hpqlb driver provides support for all hotkeys
-    generating keycodes.

-
The following hotkeys which do not generate keycodes are:

-

-
    
-  
  • Display Switch
    • 
-  
  • Brightness Up
    • 
-  
  • Brightness Down
    • 
-

-

-

-

-
acpi(4)

-

-

-

-
The hpqlb driver appeared in
-    NetBSD 5.0.

-

-

-

-
This driver was written for NetBSD by
-    Christoph Egger.

-

-

-

-
The hpqlb driver conflicts with
-    wmihp(4).

-

-

-
-  
-    
-    
-  
-
April 8, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/hptide.4 4.html b/static/netbsd/man4/hptide.4 4.html
deleted file mode 100644
index 3414d780..00000000
--- a/static/netbsd/man4/hptide.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
HPTIDE(4)Device Drivers ManualHPTIDE(4)

-

-

-

-
hptide —
-    Triones/Highpoint IDE disk controllers driver

-

-

-

-
hptide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The hptide driver supports the
-    Triones/Highpoint HPT366, HPT370, HPT370A, HPT372 and HPT374 IDE
-    controllers, and provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the hptide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/hvn.4 4.html b/static/netbsd/man4/hvn.4 4.html
deleted file mode 100644
index 6c688359..00000000
--- a/static/netbsd/man4/hvn.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
HVN(4)Device Drivers ManualHVN(4)

-

-

-

-
hvn — Hyper-V
-    networking interface

-

-

-

-
hvn* at vmbus?

-

-

-

-
The hvn driver provides support for a
-    Network Virtual Service Client (NetVSC), a virtual networking interface that
-    relays device requests to the Virtual Service Provider (VSP) in the
-    management operating system via the VMBus.

-
NetVSC emulates an RNDIS 1.0 compliant device on top of a custom
-    NVS protocol operating over the VMBus channel ring.

-
Individual networking interfaces can be renamed by
-    issuing a Rename-VMNetworkAdapter PowerShell command
-    in the management domain. In order to enable sending and receiving of IEEE
-    802.1q (VLAN) frames, the virtual port needs to be put into
-     mode with the
-    Set-VMNetworkAdapterVlan command.

-

-

-

-
arp(4), netintro(4),
-    vlan(4), ifconfig(8)

-

-

-

-
The hvn driver first appeared in
-    OpenBSD 6.1 and appeared in NetBSD
-    8.0.

-

-

-

-
The hvn driver was written by
-    Mike Belopuhov
-    <mikeb@openbsd.org>
-    based on the FreeBSD driver by the Microsoft BSD
-    Integration Services Team
-    <bsdic@microsoft.com>
-    and ported to NetBSD by
-  

-  NONAKA Kimihiro.

-

-

-
-  
-    
-    
-  
-
October 12, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/hythygtemp.4 4.html b/static/netbsd/man4/hythygtemp.4 4.html
deleted file mode 100644
index b3b3dc0d..00000000
--- a/static/netbsd/man4/hythygtemp.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
HYTHYGTEMP(4)Device Drivers ManualHYTHYGTEMP(4)

-

-

-

-
hythygtemp —
-    Driver for IST-AG HYT-221/271/939 sensor chip via I2C
-    bus

-

-

-

-
hythygtemp* at iic? addr 0x28

-

-

-

-
The hythygtemp driver provides
-    measurements from the HYT-221/271/939 humidity/temperature sensors via the
-    envsys(4) framework. The
-    hythygtemp addr argument
-    selects the address at the iic(4) bus. The sampling
-    interval can be changed through the sysctl(8) node
-    hw.hythygtemp0.interval.

-
The sensor chips can be reconfigured to respond to other addresses
-    than the default value of 0x28 by external utilities, like for example the
-    pkgsrc/sysutils/hytctl package.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  
hw.hythygtemp0.interval

-  
Defines the sensor's sampling interval in seconds. It defaults to 50
-      seconds.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The hythygtemp driver first appeared in
-    NetBSD 7.0.

-

-

-

-
The hythygtemp driver was written by
-    Frank Kardel
-    <kardel@NetBSD.org>
-    and Frank Wille ⟨phx@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
September 9, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/iavf.4 4.html b/static/netbsd/man4/iavf.4 4.html
deleted file mode 100644
index 6990ce61..00000000
--- a/static/netbsd/man4/iavf.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
IAVF(4)Device Drivers ManualIAVF(4)

-

-

-

-
iavf — Intel
-    Ethernet Adaptive Virtual Function driver

-

-

-

-
iavf* at pci? dev ? function ?

-

-

-

-
The iavf driver supports the SR-IOV
-    Virtual Functions of Intel 700 series Ethernet controller devices.

-

-

-

-
arp(4), ifmedia(4),
-    pci(4), ifconfig(8)

-

-

-

-
The iavf driver comes from
-    OpenBSD. It first appeared in
-    NetBSD 10.0.

-

-

-

-
The iavf driver was written by
-    David Gwynne
-    <dlg@openbsd.org> and
-    Jonathan Matthew
-    <jmatthew@openbsd.org>.
-    It was imported from OpenBSD into
-    NetBSD.

-

-

-
-  
-    
-    
-  
-
September 7, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/ibmcd.4 4.html b/static/netbsd/man4/ibmcd.4 4.html
deleted file mode 100644
index 2d0b3441..00000000
--- a/static/netbsd/man4/ibmcd.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
IBMCD(4)Device Drivers ManualIBMCD(4)

-

-

-

-
ibmcd — support
-    for the IBM 4810 BSP cash drawer port

-

-

-

-
ibmcd* at at pci ? dev ? function ?
-  

-  gpio* at ibmcd?

-

-

-

-
The ibmcd driver controls the cash drawer
-    port of the IBM 4810 BSP PCI device found in IBM point of sale terminals
-    (e.g. in the SurePOS 300 series) using the GPIO subsystem.

-
ibmcd provides a GPIO device with three
-    pins: pin 0 is used to control the cash drawer while pin 1 can be used to
-    read the current state of the sense input pin. A logical 0 means the cash
-    drawer is closed, a logical 1 means the cash drawer is open.

-
Pin 2 reports if a cash drawer is connected. A logical 0 means
-    there is no cash drawer connected, a logical 1 means the cash drawer is
-    connected.

-
To open the cash drawer, set pin 0 to logical 1. There is no need
-    to reset pin 0 to logical 0 afterwards as the device generates a oneshot
-    impulse.

-

-

-

-
gpio(4), ptcd(4),
-    gpioctl(8)

-

-

-

-
The ibmcd driver first appeared in
-    NetBSD 6.1.

-

-

-

-
The ibmcd driver was written by
-    Marc Balmer
-    <marc@msys.ch>.

-

-

-
-  
-    
-    
-  
-
December 17, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/ibmhawk.4 4.html b/static/netbsd/man4/ibmhawk.4 4.html
deleted file mode 100644
index 7b3528d4..00000000
--- a/static/netbsd/man4/ibmhawk.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
IBMHAWK(4)Device Drivers ManualIBMHAWK(4)

-

-

-

-
ibmhawk — IBM Hawk
-    Integrated Systems Management Processor

-

-

-

-
ibmhawk0 at iic?

-

-

-

-
The ibmhawk driver provides support for
-    the temperature, voltage, and fan sensors present on IBM eServers equipped
-    with an on-board Hawk Integrated Systems Management Processor.

-
The ibmhawk driver reports these sensors
-    through the envsys(4) API.

-

-

-

-
envsys(4), envstat(8),
-    powerd(8)

-

-

-

-
The ibmhawk driver first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
February 14, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/ichsmb.4 4.html b/static/netbsd/man4/ichsmb.4 4.html
deleted file mode 100644
index 0ef90754..00000000
--- a/static/netbsd/man4/ichsmb.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
ICHSMB(4)Device Drivers ManualICHSMB(4)

-

-

-

-
ichsmb — Intel
-    Chipset internal SMBus controller

-

-

-

-
ichsmb* at pci?
-  

-  iic* at ichsmb?

-

-

-

-
The ichsmb driver provides support for the
-    Intel chipset internal SMBus host interface to be used with the
-    iic(4) framework.

-
Supported chipsets:

-

-
    
-  
  • ICH series.
    • 
-  
  • PCH series.
    • 
-  
  • 63xxESB series.
    • 
-  
  • C6xx series.
    • 
-

-

-

-

-
iic(4), intro(4),
-    pci(4)

-

-

-

-
The ichsmb driver first appeared in
-    NetBSD 5.0. It is based off of the
-    OpenBSD 3.9 “ichiic” driver.

-

-

-

-
The ichsmb driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>.

-

-

-

-
The driver doesn't support I2C commands with a data buffer size of
-    more than 2 bytes.

-

-

-
-  
-    
-    
-  
-
March 16, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/icmp.4 3.html b/static/netbsd/man4/icmp.4 3.html
deleted file mode 100644
index 7eaf62de..00000000
--- a/static/netbsd/man4/icmp.4 3.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
ICMP(4)Device Drivers ManualICMP(4)

-

-

-

-
icmp — Internet
-    Control Message Protocol

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netinet/in.h>

-
int
-  

-  socket(AF_INET,
-    SOCK_RAW,
-    proto);

-

-

-

-
ICMP is the error and control message protocol used by IP and the
-    Internet protocol family. It may be accessed through a “raw
-    socket” for network monitoring and diagnostic functions. The
-    proto parameter to the socket call to create an ICMP
-    socket is obtained from getprotobyname(3). ICMP sockets
-    are connectionless, and are normally used with the
-    sendto(2) and recvfrom(2) calls, though
-    the connect(2) call may also be used to fix the
-    destination for future packets (in which case the read(2)
-    or recv(2) and write(2) or
-    send(2) system calls may be used).

-
Outgoing packets automatically have an IP header prepended to them
-    (based on the destination address). Incoming packets are received with the
-    IP header and options intact.

-

-

-

-
A socket operation may fail with one of the following errors
-    returned:

-

-  
[EISCONN]

-  
when trying to establish a connection on a socket which already has one,
-      or when trying to send a datagram with the destination address specified
-      and the socket is already connected;

-  
[ENOTCONN]

-  
when trying to send a datagram, but no destination address is specified,
-      and the socket hasn't been connected;

-  
[ENOBUFS]

-  
when the system runs out of memory for an internal data structure;

-  
[EADDRNOTAVAIL]

-  
when an attempt is made to create a socket with a network address for
-      which no network interface exists.

-

-

-

-

-
recv(2), send(2),
-    inet(4), intro(4),
-    ip(4)

-
Internet Control Message
-    Protocol, RFC, 792,
-    September 1981.

-
Requirements for Internet Hosts
-    -- Communication Layers, RFC,
-    1122, October
-  1989.

-

-

-

-
The icmp protocol appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/icmp6.4 4.html b/static/netbsd/man4/icmp6.4 4.html
deleted file mode 100644
index 451ebb87..00000000
--- a/static/netbsd/man4/icmp6.4 4.html	
+++ /dev/null
@@ -1,387 +0,0 @@
-
-  
-    
-    
-    
-  
-
ICMP6(4)Device Drivers ManualICMP6(4)

-

-

-

-
icmp6 — Internet
-    Control Message Protocol for IPv6

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netinet/in.h>
-  

-  #include <netinet/icmp6.h>

-
int
-  

-  socket(AF_INET6,
-    SOCK_RAW,
-    IPPROTO_ICMPV6);

-

-

-

-
ICMPv6 is the error and control message protocol used by IPv6 and
-    the IPv6 protocol family (see ip6(4) and
-    inet6(4)). It may be accessed through a “raw
-    socket” for network monitoring and diagnostic functions.

-
The proto parameter to the
-    socket(2) call to create an ICMPv6 socket may be obtained
-    from getprotobyname(3). ICMPv6 sockets are connectionless,
-    and are normally used with the sendto(2) and
-    recvfrom(2) calls, though the connect(2)
-    call may also be used to fix the destination for future packets (in which
-    case read(2) or recv(2) and
-    write(2) or send(2) system calls may be
-    used).

-
Outgoing packets automatically have an IPv6 header prepended to
-    them (based on the destination address). Incoming packets on the socket are
-    received with the IPv6 header and any extension headers removed.

-

-

-
ICMPv6 messages are classified according to the type and code
-    fields present in the ICMPv6 header. The abbreviations for the types and
-    codes may be used in rules in pf.conf(5). The following
-    types are defined:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
1unreachDestination unreachable
2toobigPacket too big
3timexTime exceeded
4paramprobInvalid IPv6 header
128echoreqEcho service request
129echorepEcho service reply
130groupqryGroup membership query
130listqryMulticast listener query
131grouprepGroup membership report
131listenrepMulticast listener report
132grouptermGroup membership termination
132listendoneMulticast listener done
133routersolRouter solicitation
134routeradvRouter advertisement
135neighbrsolNeighbor solicitation
136neighbradvNeighbor advertisement
137redirShorter route exists
138routrrenumRoute renumbering
139fqdnreqFQDN query
139niqryNode information query
139wrureqWho-are-you request
140fqdnrepFQDN reply
140nirepNode information reply
140wrurepWho-are-you reply
200mtracerespmtrace response
201mtracemtrace messages

-
The following codes are defined:

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
0noroute-unrunreachNo route to destination
1admin-unrunreachAdministratively prohibited
2beyond-unrunreachBeyond scope of source address
2notnbr-unrunreachNot a neighbor (obsolete)
3addr-unrunreachAddress unreachable
4port-unrunreachPort unreachable
0transittimexTime exceeded in transit
1reassembtimexTime exceeded in reassembly
0badheadparamprobErroneous header field
1nxthdrparamprobUnrecognized next header
2redirUnrecognized option
0redironlinkredirRedirection to on-link node
1redirrouterredirRedirection to better router

-

-

-

-
All ICMPv6 messages are prefixed with an ICMPv6 header. This
-    header corresponds to the icmp6_hdr structure and has
-    the following definition:

-

-
struct icmp6_hdr {
-	uint8_t	icmp6_type;	/* type field */
-	uint8_t	icmp6_code;	/* code field */
-	uint16_t	icmp6_cksum;	/* checksum field */
-	union {
-		uint32_t icmp6_un_data32[1]; /* type-specific */
-		uint16_t icmp6_un_data16[2]; /* type-specific */
-		uint8_t  icmp6_un_data8[4];  /* type-specific */
-	} icmp6_dataun;
-} __packed;
-
-#define icmp6_data32	icmp6_dataun.icmp6_un_data32
-#define icmp6_data16	icmp6_dataun.icmp6_un_data16
-#define icmp6_data8	icmp6_dataun.icmp6_un_data8
-#define icmp6_pptr	icmp6_data32[0]	/* parameter prob */
-#define icmp6_mtu	icmp6_data32[0]	/* packet too big */
-#define icmp6_id	icmp6_data16[0]	/* echo request/reply */
-#define icmp6_seq	icmp6_data16[1]	/* echo request/reply */
-#define icmp6_maxdelay	icmp6_data16[0]	/* mcast group membership*/

-

-
icmp6_type describes the type of the
-    message. Suitable values are defined in
-    <netinet/icmp6.h>.
-    icmp6_code describes the sub-type of the message and
-    depends on icmp6_type.
-    icmp6_cksum contains the checksum for the message and
-    is filled in by the kernel on outgoing messages. The other fields are used
-    for type-specific purposes.

-

-

-

-
Because of the extra functionality of ICMPv6 in comparison to
-    ICMPv4, a larger number of messages may be potentially received on an ICMPv6
-    socket. Input filters may therefore be used to restrict input to a subset of
-    the incoming ICMPv6 messages so only interesting messages are returned by
-    the recv(2) family of calls to an application.

-
The icmp6_filter structure may be used to
-    refine the input message set according to the ICMPv6 type. By default, all
-    messages types are allowed on newly created raw ICMPv6 sockets. The
-    following macros may be used to refine the input set:

-

-  
void
-    (struct
-    icmp6_filter *filterp)

-  
Allow all incoming messages. filterp is modified to
-      allow all message types.

-  
void
-    (struct
-    icmp6_filter *filterp)

-  
Ignore all incoming messages. filterp is modified to
-      ignore all message types.

-  
void
-    (int
-    type, struct icmp6_filter *filterp)

-  
Allow ICMPv6 messages with the given type.
-      filterp is modified to allow such messages.

-  
void
-    (int
-    type, struct icmp6_filter *filterp)

-  
Ignore ICMPv6 messages with the given type.
-      filterp is modified to ignore such messages.

-  
int
-    (int
-    type, const struct icmp6_filter *filterp)

-  
Determine if the given filter will allow an ICMPv6 message of the given
-      type.

-  
int
-    (int
-    type, const struct icmp6_filter *filterp)

-  
Determine if the given filter will ignore an ICMPv6 message of the given
-      type.

-

-
The getsockopt(2) and
-    setsockopt(2) calls may be used to obtain and install the
-    filter on ICMPv6 sockets at option level
-    IPPROTO_ICMPV6 and name
-    ICMPV6_FILTER with a pointer to the
-    icmp6_filter structure as the option value.

-

-

-

-

-
getsockopt(2), recv(2),
-    send(2), setsockopt(2),
-    socket(2), getprotobyname(3),
-    inet6(4), ip6(4),
-    netintro(4)

-
W. Stevens and
-    M. Thomas, Advanced Sockets API
-    for IPv6, RFC 2292,
-    February 1998.

-
A. Conta and
-    S. Deering, Internet Control
-    Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
-    Specification, RFC 2463,
-    December 1998.

-

-

-
-  
-    
-    
-  
-
December 20, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/icp.4 4.html b/static/netbsd/man4/icp.4 4.html
deleted file mode 100644
index 431a0fda..00000000
--- a/static/netbsd/man4/icp.4 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
ICP(4)Device Drivers ManualICP(4)

-

-

-

-
icp — ICP-Vortex
-    and Intel Storage RAID driver

-

-

-

-
icp* at pci? dev ? function ?
-  

-  ld* at icp? unit ?
-  

-  icpsp* at icp? unit ?
-  

-  scsibus* at icpsp?

-

-

-

-
The icp driver provides support for the
-    newer (post 1997) ICP-Vortex GDT and Intel Storage RAID controllers.

-
The ld driver provides access to logical
-    devices (disk arrays) presented by the controller. The
-    icpsp driver provides direct access to other SCSI
-    devices attached to the controller, such as tape or CD-ROM drives.

-

-

-

-

-  
pci_mem_find: expected mem type 00000000, found 00000002

-  
This message may be displayed during autoconfiguration if the controller's
-      memory is mapped below 1MB in physical address space. This can be disabled
-      either through changing a setting in the controller's BIOS utility, or
-      changing the position of a jumper on the board. See your controller's
-      documentation for more information.

-

-

-

-

-
intro(4), ld(4),
-    scsi(4)

-

-

-

-
The icp driver first appeared in
-    NetBSD 1.6, and was based on the
-    FreeBSD and OpenBSD drivers
-    of the same name.

-

-

-

-
ISA & EISA front-ends and a management interface are
-  needed.

-
Older PCI boards are not yet supported.

-

-

-
-  
-    
-    
-  
-
April 20, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/icsphy.4 4.html b/static/netbsd/man4/icsphy.4 4.html
deleted file mode 100644
index 3c867ffa..00000000
--- a/static/netbsd/man4/icsphy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
ICSPHY(4)Device Drivers ManualICSPHY(4)

-

-

-

-
icsphy — Driver
-    for Integrated Circuit Systems ICS1890/1893 10/100 Ethernet PHYs

-

-

-

-
icsphy* at mii? phy ?

-

-

-

-
The icsphy driver supports the Integrated
-    Circuit Systems ICS1890 and ICS1893 10/100 Ethernet PHYs. These PHYs are
-    found on a variety of high-performance Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
March 14, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/iee.4 4.html b/static/netbsd/man4/iee.4 4.html
deleted file mode 100644
index 984760c6..00000000
--- a/static/netbsd/man4/iee.4 4.html	
+++ /dev/null
@@ -1,152 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEE(4)Device Drivers ManualIEE(4)

-

-

-

-
iee — Intel i82596
-    10MBit/s Ethernet interface

-

-

-

-

-

-
iee* at sbdio?

-

-

-

-
iee* at gsc?

-

-

-

-

-
The iee device provides access to the
-    Intel i82596 10MBit/s Ethernet interface. iee
-    supports IEEE 802.1Q Virtual LANs. iee operates the
-    i82596 in 32-Bit Linear Mode, opposed to ie(4) that drives
-    the i82596 only in i82586 compatibility mode.

-

-

-

-

-

-
The iee interface supports Intel i82596CA
-    based on-board Ethernet on EWS4800/350.

-

-

-

-
The iee interface supports Intel i82596DX
-    on ASP/ASP2 based machines and the i82596CA macrocell in LASI based
-    machines. GSC expansion cards may work, but are not tested. Media selection
-    on hppa is done either manually via hardware jumper or automatically
-    depending on machine model.

-

-

-

-

-

-  
iee%d: iee_intr: receive error %d, rfd_status=0x%.4x,
-    rfd_count=0x%.4x.

-  
An error during frame reception occurred. The frame was dropped.

-  
iee%d: iee_intr: can't allocate mbuf.

-  

-  
iee%d: iee_intr: can't alloc mbuf cluster.

-  
A frame was received, but dropped due to lack of memory.

-  
iee%d: iee_intr: receive ring buffer overrun

-  
Many frames where received under high load and the receive ring buffer was
-      to small to store them all. Frame reception was restarted from scratch.
-      Most likely there where frames lost.

-  
iee%d: iee_intr: scb_status=0x%x scb_cmd=0x%x failed command %d:
-    cb_status[%d]=0x%.4x cb_cmd[%d]=0x%.4x

-  
A transmit or setup command was not executed successfully.

-  
iee%d: iee_intr: crc_err=%d

-  
Number of frames with a CRC error received.

-  
iee%d: iee_intr: align_err=%d

-  
Number of unaligned frames received.

-  
iee%d: iee_intr: resource_err=%d

-  
Number of good frames dropped because the receive ring buffer was
-    full.

-  
iee%d: iee_intr: overrun_err=%d

-  
Number of frames lost because the system bus was not available for
-    DMA.

-  
iee%d: iee_intr: rcvcdt_err=%d

-  
Number of collisions detected during frame reception.

-  
iee%d: iee_intr: short_fr_err=%d

-  
Number of frames received that where shorter than the minimum frame
-      length.

-  
iee%d: iee_start: failed to load DMA map

-  
A mbuf(9) chain with too many elements could not be
-      setup for transmission. The mbuf(9) chain will be merged
-      into a single mbuf(9) cluster and retransmitted.

-  
iee%d: iee_start: can't allocate mbuf.

-  

-  
iee%d: iee_start: can't load TX DMA map.

-  
Said error occurred during merging the mbuf(9) chain
-      into a mbuf(9) cluster. The frame was dropped.

-  
iee%d: iee_init: can't create TX DMA map

-  

-  
iee%d: iee_init: can't allocate mbuf

-  

-  
iee%d: iee_init: can't allocate mbuf cluster

-  

-  
iee%d: iee_init: can't create RX DMA map

-  

-  
iee%d: iee_init: can't load RX DMA map

-  
There was no memory free to allocate resources when the operator tried to
-      bring the interface up. The interface will not come up. Try again
-    later.

-  
iee%d: iee_watchdog: transmit timeout %d

-  

-  
iee%d: iee_watchdog: setup timeout %d

-  
The hardware didn't respond to a transmit or setup command within five
-      seconds. The interface will be reset and restarted.

-  
iee%d: iee_gsc_cmd: timeout n=%d

-  
Timeout at sending a channel attention command to the chip.

-  
iee%d: iee_gsc_reset timeout busy=0x%x

-  
Timeout at resetting the chip. Possible errors during
-      autoconf(4).

-  
iee%d: iee_gsc_attach: can't map I/O space

-  
The driver failed to map the I/O ports of the chip. The device will not be
-      attached.

-  
iee%d: iee_gsc_attach: can't allocate %d bytes of DMA memory

-  

-  
iee%d: iee_gsc_attach: can't map DMA memory

-  

-  
iee%d: iee_gsc_attach: can't create DMA map

-  

-  
iee%d: iee_gsc_attach: can't load DMA map

-  
The driver failed to get the shared DMA memory for the chip. The device
-      will not be attached.

-

-

-

-

-
arp(4), ifmedia(4),
-    inet(4), intro(4),
-    vlan(4), ifconfig(8)

-

-

-

-
The iee driver appeared in
-    NetBSD 2.0.

-

-

-

-
Jochen Kunz

-

-

-

-
None. ;-)

-

-

-
-  
-    
-    
-  
-
May 5, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/ieee1394if.4 4.html b/static/netbsd/man4/ieee1394if.4 4.html
deleted file mode 100644
index 41df1b13..00000000
--- a/static/netbsd/man4/ieee1394if.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE1394IF(4)Device Drivers ManualIEEE1394IF(4)

-

-

-

-
ieee1394if —
-    IEEE1394 High-performance Serial Bus

-

-

-

-
ieee1394if* at fwohci?

-

-

-

-
NetBSD provides machine-independent bus
-    support and raw drivers for IEEE1394 interfaces.

-
The ieee1394if driver consists of two
-    layers: the controller and the bus layer. The controller attaches to a
-    physical bus (like pci(4)). The
-    ieee1394if bus attaches to the controller.
-    Additional drivers can be attached to the bus.

-
Up to 63 devices, including the host itself, can be attached to a
-    IEEE1394 bus. The root node is dynamically assigned with a PHY device
-    function. Also, the other IEEE1394 bus specific parameters, e.g., node ID,
-    cycle master, isochronous resource manager and bus manager, are dynamically
-    assigned, after bus reset is initiated. On the
-    ieee1394if bus, every device is identified by an EUI
-    64 address.

-

-

-

-

-  
/dev/fw0.0

-  
 

-  
/dev/fwmem0.0

-  
 

-

-

-

-

-
fwip(4), fwohci(4),
-    pci(4), sbp(4),
-    fwctl(8), sysctl(8)

-

-

-

-
The ieee1394if driver first appeared in
-    FreeBSD 5.0, as firewire. It
-    was added to NetBSD 4.0 under its present name.

-

-

-

-
The ieee1394if driver was written by
-    Katsushi Kobayashi and Hidetoshi
-    Shimokawa for the FreeBSD project. It was
-    added to NetBSD 4.0 by KIYOHARA
-    Takashi.

-

-

-

-
See fwohci(4) for security notes.

-

-

-
-  
-    
-    
-  
-
June 18, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/ieee80211.4 3.html b/static/netbsd/man4/ieee80211.4 3.html
deleted file mode 100644
index dbd540cb..00000000
--- a/static/netbsd/man4/ieee80211.4 3.html	
+++ /dev/null
@@ -1,186 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211(4)Device Drivers ManualIEEE80211(4)

-

-

-

-
ieee80211 —
-    standard interface to IEEE 802.11 devices

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <net/if.h>
-  

-  #include <net/ethernet.h>
-  

-  #include
-  <net/if_ieee80211.h>

-

-

-

-
This section describes the standard interface to configuration and
-    status information on IEEE 802.11 devices. Most devices support options not
-    configurable by this interface. They must be set by their respective,
-    specific control program. The interface is via one of the following
-    ioctl(2) calls on a socket:

-

-  

-  
Get configuration or status information.

-  

-  
Set configuration information.

-

-
These requests are made via a modified ifreq
-    structure. This structure is defined as follows:

-

-
struct ieee80211req {
-	char		i_name[IFNAMSIZ];	/* if_name, e.g. "wi0" */
-	uint16_t	i_type;			/* req type */
-	int16_t		i_val;			/* Index or simple value */
-	int16_t		i_len;			/* Index or simple value */
-	void		*i_data;		/* Extra data */
-};

-

-
For SIOCG80211 the following values of
-    i_type are valid:

-

-  

-  
Returns the requested SSID by copying it into the buffer pointed to by
-      i_data and setting i_len to
-      the length. If i_val is >= 0 then the request
-      refers to the configured value for that slot. Generally, 0 is the only
-      valid value, but some interfaces support more SSIDs. If
-      i_val is -1 then the request refers to the currently
-      active value.

-  

-  
Returns the number of SSIDs this card supports. In most cases, this is 1,
-      but some devices such as an(4) support more.

-  

-  
Returns the current WEP status in i_val. Valid
-      values are IEEE80211_WEP_NOSUP,
-      IEEE80211_WEP_ON,
-      IEEE80211_WEP_OFF, and
-      IEEE80211_WEP_MIXED. Respectively, these values
-      mean unsupported, mandatory for all devices, off, and on, but not required
-      for all devices.

-  

-  
Returns the requested WEP key via i_data and its
-      length via i_len. If the device does not support
-      returning the WEP key or the user is not root then the key may be returned
-      as all zeros. Technically this is a valid key, but it is the kind of key
-      an idiot would put on his luggage so we use it as a special value.
-      Generally, only four WEP keys are allowed, but some devices support more.
-      If so, the first four (0-3) are the standard keys stored in volatile
-      storage and the others are device specific.

-  

-  
Returns the number of WEP keys supported by this device, generally 4. A
-      device that does not support WEP may either report 0 or simply return
-      EINVAL.

-  

-  
Returns the WEP key used for transmission.

-  

-  
Returns the current authentication mode in i_val.
-      Valid values are IEEE80211_AUTH_NONE,
-      IEEE80211_AUTH_OPEN, and
-      IEEE80211_AUTH_SHARED.

-  

-  
Returns the station name via i_data and its length
-      via i_len. While all known devices seem to support
-      this in some way or another, they all do it differently and it appears to
-      not have anything to do with the actual IEEE 802.11 standard so making up
-      an answer may be necessary for future devices.

-  

-  
Returns the current direct sequence spread spectrum channel in use.

-  

-  
Returns the current powersaving mode. Valid values are
-      IEEE80211_POWERSAVE_NOSUP,
-      IEEE80211_POWERSAVE_OFF,
-      IEEE80211_POWERSAVE_ON,
-      IEEE80211_POWERSAVE_CAM,
-      IEEE80211_POWERSAVE_PSP, and
-      IEEE80211_POWERSAVE_PSP_CAM. Currently,
-      IEEE80211_POWERSAVE_ON is defined to be equal to
-      IEEE80211_POWERSAVE_CAM, but this may be
-      incorrect.

-  

-  
Returns the powersave sleep time in msec in
-    i_val.

-

-
For SIOCS80211 the following values of
-    i_type are valid:

-

-  

-  
Set the desired SSID for infrastructure and ad-hoc modes to value given by
-      i_data and i_len. The length
-      should be no longer than 32 characters.

-  

-  
Set the current WEP mode to the value given in
-      i_val. Valid values are the same as those for this
-      value above. Devices which do not support all modes may choose to either
-      return EINVAL or choose a reasonable alternate
-      (supported) setting.

-  

-  
Set the WEP key indicated by i_val to the value
-      given by i_data and i_len.
-      Generally, valid values of i_len are 0, 5, and 13
-      though not all devices with WEP support have support for 13-byte
-    keys.

-  

-  
Set the WEP key used for transmission to the value in
-      i_val. Not all values which are valid for setting
-      keys may be valid for setting transmit keys due to strange device
-      interfaces.

-  

-  
Set the current authorization mode to the value given in
-      i_val. Valid values are given above. Not all devices
-      support this.

-  

-  
Set the station name to the value given by i_data
-      and i_len. The standard does not appear to deal with
-      this feature so the range of valid values may vary from device to
-    device.

-  

-  
Set the desired ad-hoc channel to the value given by
-      i_val. On some devices this has an impact on
-      infrastructure mode as well. Valid values are 1-14, but 0 should be
-      allowed and should return the device to the default value. Many devices
-      support this directly by converting any invalid value to the default
-      value.

-  

-  
Set the current powersaving mode to the value given in
-      i_val. Valid values are the same as those for this
-      value above. Devices which do not support all modes may choose to either
-      return EINVAL or choose a reasonable alternate
-      (supported) setting. Most devices only support CAM mode.

-  

-  
Set the powersave sleep time in msec to the value in
-      i_val.

-

-

-

-

-
ioctl(2), an(4),
-    ray(4), wi(4),
-    ifconfig(8)

-

-

-

-
The ieee80211 manual appeared in
-    FreeBSD 4.3.

-

-

-
-  
-    
-    
-  
-
November 29, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/ietp.4 4.html b/static/netbsd/man4/ietp.4 4.html
deleted file mode 100644
index 8da0764d..00000000
--- a/static/netbsd/man4/ietp.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
IETP(4)Device Drivers ManualIETP(4)

-

-

-

-
ietp — Elantech
-    touchpad

-

-

-

-
ietp* at iic?
-  

-  wsmouse* at ietp? mux 0

-

-

-

-
The ietp driver provides support for
-    Elantech touchpad devices connected over Inter-Integrated Circuit (I2C)
-    buses. Access to these devices is through the wscons(4)
-    driver.

-

-

-

-
iic(4), wsmouse(4)

-

-

-

-
The ietp device driver first appeared in
-    OpenBSD 7.4.

-

-

-

-
The ietp driver was written by
-    Vladimir Serbinenko
-    <phcoder@gmail.com.>

-

-

-
-  
-    
-    
-  
-
July 9, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/ifmedia.4 4.html b/static/netbsd/man4/ifmedia.4 4.html
deleted file mode 100644
index 6486ae65..00000000
--- a/static/netbsd/man4/ifmedia.4 4.html	
+++ /dev/null
@@ -1,380 +0,0 @@
-
-  
-    
-    
-    
-  
-
IFMEDIA(4)Device Drivers ManualIFMEDIA(4)

-

-

-

-
ifmedia — network
-    interface media settings

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <net/if.h>
-  

-  #include <net/if_media.h>

-

-

-

-
The ifmedia interface provides a
-    consistent method for querying and setting network interface media and media
-    options. The media is typically set using the ifconfig(8)
-    command.

-
The lists below provide the possible names of each link type,
-    media type, or option. The first name in the list is the canonical name.
-    Additional names are accepted aliases.

-
There are currently four link types supported by
-    ifmedia:

-

-

-

-  

-  
Ethernet. [Ethernet,
-      ether]

-  

-  
Token Ring. [TokenRing,
-      token]

-  

-  
FDDI. [FDDI]

-  

-  
IEEE802.11 Wireless LAN. [IEEE802.11]

-

-

-
The following sections describe the possible media settings for
-    each link type. Not all of these are supported by every device; refer to
-    your device's manual page for more information.

-

-

-
The following media types
-    (media) are shared by all link types:

-

-

-

-  

-  
Autoselect the best media. [autoselect,
-      auto]

-  

-  
Jumper or switch on device selects media.
-    [manual]

-  

-  
Deselect all media. [none]

-

-

-
The following media options
-    (mediaopt) are shared by all link types:

-

-

-  

-  
Place the device into full-duplex mode. This option only has meaning if
-      the device is normally not full-duplex.
-      [full-duplex, fdx]

-  

-  
Place the device into half-duplex mode. This option only has meaning if
-      the device is normally not half-duplex.
-      [half-duplex, hdx]

-  

-  
Hardware flow control support. [flowcontrol,
-      flow]

-  

-  
Driver-defined flag. [flag0]

-  

-  
Driver-defined flag. [flag1]

-  

-  
Driver-defined flag. [flag2]

-  

-  
Place the device into hardware loopback mode.
-      [loopback, hw-loopback,
-      loop]

-

-

-

-

-

-
The following media types are defined for
-    Ethernet:

-

-

-  

-  
HomePNA 1.0, 1 Mb/s. [HomePNA1,
-      HPNA1]

-  

-  
10BASE-T, 10 Mb/s over unshielded twisted pair, RJ45 connector.
-      [10baseT, UTP,
-      10UTP]

-  

-  
10BASE2, 10 Mb/s over coaxial cable, BNC connector, also called
-      Thinnet. [10base2, BNC,
-      10BNC]

-  

-  
10BASE5, 10 Mb/s over 15-wire cables, DB15 connector, also called
-      AUI. [10base5, AUI,
-      10AUI]

-  

-  
10BASE-STP, 10 Mb/s over shielded twisted pair, DB9 connector.
-      [10baseSTP, STP,
-      10STP]

-  

-  
10BASE-FL, 10 Mb/s over fiber optic cables.
-      [10baseFL, FL,
-      10FL]

-  

-  
100BASE-TX, 100 Mb/s over unshielded twisted pair, RJ45 connector.
-      [100baseTX, 100TX]

-  

-  
100BASE-FX, 100 Mb/s over fiber optic cables.
-      [100baseFX, 100FX]

-  

-  
100BASE-T4, 100 Mb/s over 4-wire (category 3) unshielded twisted
-      pair, RJ45 connector. [100baseT4,
-      100T4]

-  

-  
100BASE-T2. [100baseT2,
-      100T2]

-  

-  
100VG-AnyLAN. [100baseVG,
-      100VG]

-  

-  
1000BASE-SX, 1 Gb/s over multi-mode fiber optic cables. (short
-      waves) [1000baseSX,
-      1000SX]

-  

-  
1000BASE-LX, 1 Gb/s over single-mode fiber or multi-mode fiber
-      optic cables. (long waves) [1000baseLX,
-      1000LX]

-  

-  
1000BASE-BX10, 1 Gb/s over bidirectional fiber optic cables. (long
-      waves) [1000BASE-BX10]

-  

-  
1000BASE-CX, 1 Gb/s over shielded twisted pair. (twinax)
-      [1000baseCX, 1000CX]

-  

-  
1000BASE-T, 1 Gb/s over category 5 unshielded twisted pair,
-      802.3ab, RJ45 connector. [1000baseT,
-      1000T]

-  

-  
1000BASE-KX, 1 Gb/s backplane.
-      [1000BASE-KX,
-    1000baseKX]

-  

-  
2500BASE-SX, 2.5 Gb/s over multi-mode fiber optic cables.
-      [2500baseSX, 2500SX]

-  

-  
2.5GBASE-T, 2.5 Gb/s over category 5e.
-      [2.5GBASE-T,
-    2500baseT]

-  

-  
2500BASE-KX, 2.5 Gb/s backplane.
-      [2500BASE-KX,
-    2500baseKX]

-  

-  
5GBASE-T, 5 Gb/s over category 6.
-      [5GBASE-T, 5GbaseT]

-  

-  
10GBASE-CX4, 10 Gb/s over XAUI 4-lane PCS and copper cables.
-      [10GbaseCX4, 10GCX4,
-      10GBASE-CX4]

-  

-  
10GBASE-LR, 10 Gb/s over single-mode fiber optic cables.
-      [10GbaseLR, 10GLR]

-  

-  
10GBASE-LR, 10 Gb/s over single-mode fiber optic cables.
-      [10GbaseLRM]

-  

-  
10GBASE-SR, 10 Gb/s over multi-mode fiber optic cables.
-      [10GbaseSR, 10GSR,
-      10GBASE-SR]

-  

-  
10GBASE-T, 10 Gb/s over unshielded twisted pair, RJ45 connector.
-      [10Gbase-T]

-  

-  
SFP+ direct attach, 10 Gb/s over twinaxial cable.
-      [10Gbase-Twinax]

-

-

-
The following media options are defined for
-    Ethernet:

-

-

-  

-  
Configure a 1000BASE-T PHY as the clock master for a 1000BASE-T link. This
-      option has no effect (shows current status only) if the media is
-      IFM_AUTO. [master]

-  

-  
Configure the device to send PAUSE (flow control) frames. This option has
-      no effect (shows current status only) if the media is
-      IFM_AUTO. [txpause]

-  

-  
Configure the device to receive PAUSE (flow control) frames. This option
-      has no effect (shows current status only) if the media is
-      IFM_AUTO. [rxpause]

-

-

-

-

-

-
The following media types are defined for Token
-    Ring:

-

-

-  

-  
4 Mb/s, shielded twisted pair, DB9 connector.
-      [DB9/4Mbit, 4STP]

-  

-  
16 Mb/s, shielded twisted pair, DB9 connector.
-      [DB9/16Mbit, 16STP]

-  

-  
4 Mb/s, unshielded twisted pair, RJ45 connector.
-      [UTP/4Mbit, 4UTP]

-  

-  
16 Mb/s, unshielded twisted pair, RJ45 connector.
-      [UTP/16Mbit, 16UTP]

-

-

-
The following media options are defined for
-    Token Ring:

-

-

-  

-  
Early token release. [EarlyTokenRelease,
-      ETR]

-  

-  
Enable source routing features. [SourceRouting,
-      SRCRT]

-  

-  
All routes vs. single route broadcast. [AllRoutes,
-      ALLR]

-

-

-

-

-

-
The following media types are defined for
-  FDDI:

-

-

-  

-  
Single-mode fiber. [Single-mode,
-      SMF]

-  

-  
Multi-mode fiber. [Multi-mode,
-      MMF]

-  

-  
Unshielded twisted pair, RJ45 connector. [UTP,
-      CDDI]

-

-

-
The following media options are defined for
-    FDDI:

-

-

-  

-  
Dual-attached station vs. Single-attached station.
-      [dual-attach, das]

-

-

-

-

-

-
The following media types are defined for
-    IEEE802.11 Wireless LAN:

-

-

-  

-  
Frequency Hopping 1 Mbps. [FH1]

-  

-  
Frequency Hopping 2 Mbps. [FH2]

-  

-  
Direct Sequence 1 Mbps. [DS1]

-  

-  
Direct Sequence 2 Mbps. [DS2]

-  

-  
Direct Sequence 5 Mbps. [DS5]

-  

-  
Direct Sequence 11 Mbps. [DS11]

-  

-  
Direct Sequence 22 Mbps. [DS22]

-  

-  
Orthogonal Frequency Division Multiplexing 6 Mbps.
-      [OFDM6]

-  

-  
Orthogonal Frequency Division Multiplexing 9 Mbps.
-      [OFDM9]

-  

-  
Orthogonal Frequency Division Multiplexing 12 Mbps.
-      [OFDM12]

-  

-  
Orthogonal Frequency Division Multiplexing 18 Mbps.
-      [OFDM18]

-  

-  
Orthogonal Frequency Division Multiplexing 24 Mbps.
-      [OFDM24]

-  

-  
Orthogonal Frequency Division Multiplexing 36 Mbps.
-      [OFDM36]

-  

-  
Orthogonal Frequency Division Multiplexing 48 Mbps.
-      [OFDM48]

-  

-  
Orthogonal Frequency Division Multiplexing 54 Mbps.
-      [OFDM54]

-  

-  
Orthogonal Frequency Division Multiplexing 72 Mbps.
-      [OFDM72]

-

-

-
The following media options are defined for
-    IEEE802.11 Wireless LAN:

-

-

-  

-  
Ad-hoc (IBSS) mode. [adhoc,
-      ibss]
-    
In some drivers, it may be used with the
-        IFM_FLAG0 [flag0] media
-        option to specify non-standard ad-hoc demo mode.

-  

-  

-  
Access Point mode. [hostap]

-  

-  
Monitor mode. [monitor]

-  

-  
Turbo mode. [turbo]

-

-

-

-

-

-

-
netintro(4), ifconfig(8)

-

-

-

-
The ifmedia interface first appeared in
-    BSD/OS 3.0. The implementation that appeared in
-    NetBSD 1.3 was written by Jonathan Stone and Jason
-    R. Thorpe to be compatible with the BSDI API. It has since gone through
-    several revisions which have extended the API while maintaining backwards
-    compatibility with the original API.

-
Support for the
-     link type was added in NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
August 3, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/igc.4 4.html b/static/netbsd/man4/igc.4 4.html
deleted file mode 100644
index 26c06044..00000000
--- a/static/netbsd/man4/igc.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
IGC(4)Device Drivers ManualIGC(4)

-

-

-

-
igc — Intel
-    I225/I226 1Gb/2.5Gb Ethernet device

-

-

-

-
igc* at pci?

-

-

-

-
The igc driver supports Intel I225/I226
-    series Ethernet devices.

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The igc driver first appeared in
-    OpenBSD 7.1, and in NetBSD
-    10.0.

-

-

-

-
The igc driver was written by
-    Intel Corporation and ported to
-    OpenBSD by
-  

-  Kevin Lo
-    <kevlo@openbsd.org>.
-    It was ported to NetBSD by
-  

-  Kengo Nakahara
-    <knakahara@NetBSD.org>,
-  

-  Rin Okuyama
-    <rin@NetBSD.org>, and
-  

-  Masanobu SAITOH
-    <msaitoh@NetBSD.org>.

-

-

-

-
The igc driver in NetBSD
-    10.0 is considered experimental. Some error handling paths are not
-    fully implemented. It does not support hardware VLAN tagging at the
-  moment.

-

-

-
-  
-    
-    
-  
-
June 1, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/igmafb.4 4.html b/static/netbsd/man4/igmafb.4 4.html
deleted file mode 100644
index 4cdf8355..00000000
--- a/static/netbsd/man4/igmafb.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
IGMAFB(4)Device Drivers ManualIGMAFB(4)

-

-

-

-
igmafb — Intel
-    Graphics Media Accelerator framebuffer driver

-

-

-

-
options VGA_RASTERCONSOLE
-  

-  no options VGA_POST
-  

-  no agp
-  

-  no device at drm
-  

-  no genfb
-  

-  igma0 at pci0 dev ? function ?
-  

-  igmafb* at igma0
-  

-  iic* at igma0

-

-

-

-
The igmafb driver provides support for
-    integrated graphics functions in Intel chipsets and provides an interface
-    for the machine independent wscons(4) driver.

-
Currently igmafb configures the display
-    for the integrated panel in notebooks and can control the backlight.
-    Automatic detection of the main display on desktop machines may or may not
-    work.

-
Supported hardware includes:

-
    
-  
  • GMA 900 (915G)
    • 
-  
  • GMA 950 (945G)
    • 
-  
  • GMA 3000 (Q965)
    • 
-  
  • GMA X3000 (G965)
    • 
-  
  • GMA X3500 (G35)
    • 
-  
  • GMA X4500 (G45)
    • 
-  
  • HD (Westmere)
    • 
-  
  • HD2000/3000 (Sandy Bridge)
    • 
-  
  • HD2500/4000 (Ivy Bridge)
    • 
-

-

-

-

-
genfb(4), wsdisplay(4)

-

-

-

-
The igmafb driver was written by
-    Michael van Elst.

-

-

-

-
The driver conflicts with genfb(4),
-    agp(4), and thus with drm(4). Support
-    for a hardware cursor is missing.

-

-

-
-  
-    
-    
-  
-
January 21, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/igphy.4 4.html b/static/netbsd/man4/igphy.4 4.html
deleted file mode 100644
index 181981c9..00000000
--- a/static/netbsd/man4/igphy.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
IGPHY(4)Device Drivers ManualIGPHY(4)

-

-

-

-
igphy — Driver for
-    Intel IGP01E1000, i82566 10/100/1000 Ethernet PHYs

-

-

-

-
igphy* at mii? phy ?

-

-

-

-
The igphy driver supports the Intel
-    IGP01E1000 and i82566 10/100/1000 Ethernet PHYs. These PHYs are found on the
-    Intel PRO 1000 GT Gigabit Ethernet Card, some Intel system boards, and some
-    models of ThinkPad.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), wm(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
June 7, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/igpio.4 4.html b/static/netbsd/man4/igpio.4 4.html
deleted file mode 100644
index a2e87e02..00000000
--- a/static/netbsd/man4/igpio.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
IGPIO(4)Device Drivers ManualIGPIO(4)

-

-

-

-
igpio — Intel GPIO
-    Controller

-

-

-

-
igpio* at acpi?
-  

-  gpio* at gpiobus?

-

-

-

-
igpio provides a gpio(4)
-    interface for the following Intel chipsets:

-

-  
Alder Lake-N

-  
 

-  
Alder Lake-P

-  
 

-  
Alder Lake-S

-  
 

-  
Cannon Lake-H

-  
 

-  
Cannon Lake-LP

-  
 

-  
Cedarfork

-  
 

-  
Coffee Lake-S

-  
 

-  
Denverton

-  
 

-  
Emmitsburg

-  
 

-  
Gemini Lake

-  
 

-  
Ice Lake-LP

-  
 

-  
Ice Lake-N

-  
 

-  
Jasper Lake

-  
 

-  
Lakefield

-  
 

-  
Lewisburg

-  
 

-  
Raptor Lake-S

-  
 

-  
Sunrisepoint-H

-  
 

-  
Sunrisepoint-LP

-  
 

-  
Tiger Lake-H

-  
 

-  
Tiger Lake-LP

-  
 

-

-Support for Baytrail, Broxton, Cherryview and Lynxpoint are not enabled yet.
-
The driver supports GPIO_PIN_INPUT,
-    GPIO_PIN_OUTPUT,
-    GPIO_PIN_INOUT,
-    GPIO_PIN_ININ,
-    GPIO_PIN_PULLUP,
-    GPIO_PIN_PULLDOWN, and interrupt capabilies
-    GPIO_INTR_POS_EDGE,
-    GPIO_INTR_NEG_EDGE,
-    GPIO_INTR_DOUBLE_EDGE,
-    GPIO_INTR_HIGH_LEVEL,
-    GPIO_INTR_LOW_LEVEL.

-

-

-

-
gpio(4)

-

-

-

-
The igpio driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The igpio driver and man page was written
-    by Emmanuel Dreyfus
-    <manu@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 27, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/igsfb.4 4.html b/static/netbsd/man4/igsfb.4 4.html
deleted file mode 100644
index 7779f206..00000000
--- a/static/netbsd/man4/igsfb.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
IGSFB(4)Device Drivers ManualIGSFB(4)

-

-

-

-
igsfb — IGA 1682
-    and CyberPro series graphics cards

-

-

-

-
igsfb* at pci?
-  

-  wsdisplay* at igsfb?

-

-

-

-
The igsfb driver provides support for IGA
-    1682 and CyberPro series of graphics cards by InteGraphics Systems, now
-    Tvia. The igsfb driver operates these cards in
-    linear framebuffer mode, not in VGA mode.

-

-

-

-
wscons(4)

-

-

-

-
The igsfb driver first appeared in
-    NetBSD 1.6.

-

-

-

-
There's currently no way to change resolution, frequency, etc. The
-    driver is hardcoded to init the card to 1024×768, 8bpp at 60Hz.

-

-

-
-  
-    
-    
-  
-
June 1, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/iha.4 4.html b/static/netbsd/man4/iha.4 4.html
deleted file mode 100644
index db150464..00000000
--- a/static/netbsd/man4/iha.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
IHA(4)Device Drivers ManualIHA(4)

-

-

-

-
iha — Initio
-    INIC-940/950 based PCI SCSI host adapter driver

-

-

-

-
iha* at pci? dev ? function ?
-  

-  scsibus* at iha?

-

-

-

-
The iha driver supports PCI SCSI host
-    adapters based on the Initio INIC-940 and INIC-950 chips.

-
The INI-9090U, INI-9100U/UW, the Iwill 2935UW and the IOI
-    Technology IOI-4203U have been tested.

-

-

-

-
cd(4), ch(4),
-    intro(4), pci(4),
-    scsi(4), sd(4), ss(4),
-    st(4), uk(4),
-    scsipi(9)

-
Initio
-  Corporation

-

-

-

-
The iha driver was originally written for
-    OpenBSD by Kenneth R. Westerback, based on a
-    FreeBSD driver by Winston Hung. Izumi Tsutsui ported
-    the driver to NetBSD.

-

-

-

-
iha driver does not currently use tagged
-    command queuing.

-

-

-
-  
-    
-    
-  
-
June 4, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ihidev.4 4.html b/static/netbsd/man4/ihidev.4 4.html
deleted file mode 100644
index 8c5e0e45..00000000
--- a/static/netbsd/man4/ihidev.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
IHIDEV(4)Device Drivers ManualIHIDEV(4)

-

-

-

-
ihidev — I2C Human
-    Interface Device support

-

-

-

-
ihidev* at iic?
-  

-  ims* at ihidev? reportid ?

-

-

-

-
The ihidev driver handles all Human
-    Interface Devices attached via I2C bus. Each HID device can have several
-    components, e.g., a keyboard and a mouse. These components use different
-    report identifiers (a byte) to distinguish which one data is coming from.
-    The ihidev driver has other drivers attached that
-    handle particular kinds of devices and ihidev only
-    dispatches data to them based on the report id.

-

-

-

-
ims(4)

-

-

-

-
The ihidev driver appeared in
-    NetBSD 8.0.

-

-

-
-  
-    
-    
-  
-
October 5, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/ihphy.4 4.html b/static/netbsd/man4/ihphy.4 4.html
deleted file mode 100644
index 5b4d03d7..00000000
--- a/static/netbsd/man4/ihphy.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
IHPHY(4)Device Drivers ManualIHPHY(4)

-

-

-

-
ihphy — Driver for
-    Intel “Hanksville” i82577 10/100/1000 Ethernet PHYs

-

-

-

-
ihphy* at mii? phy ?

-

-

-

-
The ihphy driver supports the Intel i82577
-    10/100/1000 Ethernet PHYs. These PHYs are found on the Lenovo T510 and
-    Thinkpad X201i.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), wm(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 27, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/iic.4 4.html b/static/netbsd/man4/iic.4 4.html
deleted file mode 100644
index f34a2513..00000000
--- a/static/netbsd/man4/iic.4 4.html	
+++ /dev/null
@@ -1,311 +0,0 @@
-
-  
-    
-    
-    
-  
-
IIC(4)Device Drivers ManualIIC(4)

-

-

-

-
iic — Inter IC
-    (I2C) bus

-

-

-

-
iic* at alipm? # alpha amd64 i386 sparc64 
-  

-  iic* at amdpm? # amd64 i386 
-  

-  iic* at armadillo9iic? # evbarm 
-  

-  iic0 at at91twi? # evbarm 
-  

-  iic0 at ausmbus0 # evbmips 
-  

-  iic* at awiniic? # evbarm 
-  

-  iic* at bcmi2c? # evbarm 
-  

-  iic* at coram? # amd64 i386 
-  

-  iic* at cuda? # macppc 
-  

-  iic* at cxdtv? # amd64 i386 
-  

-  iic* at diic? # acorn32 evbppc 
-  

-  iic* at ds28e17iic? # 1-Wire 
-  

-  iic* at dwiic? # amd64 i386 
-  

-  iic* at exyoi2c? # evbarm 
-  

-  iic* at g2i2c? # evbarm 
-  

-  iic0 at gpiic? # evbppc 
-  

-  iic* at gpioiic? # amd64 i386 
-  

-  iic* at gttwsi? # evbarm evbppc 
-  

-  iic* at gxiic? # evbarm 
-  

-  iic* at i2cbus? # evbarm 
-  

-  iic* at ichsmb? # amd64 i386 
-  

-  iic* at imcsmb? # amd64 i386 
-  

-  iic* at imxi2c? # evbarm 
-  

-  iic0 at iomdiic? # acorn32 
-  

-  iic0 at iopiic? # evbarm iyonix 
-  

-  iic* at ismt? # amd64 i386 
-  

-  iic* at jziic? # evbmips 
-  

-  iic* at ki2c? # macppc 
-  

-  iic* at nbpiic? # hpcarm 
-  

-  iic* at nfsmb? # amd64 i386 
-  

-  iic* at ociic? # sandpoint 
-  

-  iic* at omapiic? # evbarm 
-  

-  iic* at pcfiic? # sparc64 
-  

-  iic* at piixpm? # amd64 i386 
-  

-  iic* at pmu? # macppc 
-  

-  iic* at ri2c? # evbmips 
-  

-  iic* at rtciic? # mmeye 
-  

-  iic0 at slugiic0 # evbarm 
-  

-  iic* at tegrai2c? # evbarm 
-  

-  iic* at tiiic? # evbarm 
-  

-  iic* at tsciic? # alpha 
-  

-  iic* at umcpmio? # USB 
-  

-  iic* at viapcib? # i386 
-  

-  iic* at voyager0 # evbmips 
-  

-  iic0 at ziic? # evbmips zaurus 

-

-

-

-
I2C is a two-wire bus developed by Philips used for connecting
-    integrated circuits. It is commonly used for connecting devices such as
-    EEPROMs, temperature sensors, fan controllers, real-time clocks, tuners, and
-    other types of integrated circuits.

-
The iic driver provides a uniform
-    programming interface layer between I2C master controllers and various I2C
-    slave devices. Each I2C master controller attaches an
-    iic framework; several slave devices can then be
-    attached to the iic bus.

-
All I2C slave devices are uniquely identified by the address on
-    the bus. The master accesses a particular slave device using its
-  address.

-
System Management Bus (SMBus) protocol is also supported by
-    emulating it with the I2C commands.

-

-

-

-
The following ioctl(2) calls apply to
-     devices.
-    They are defined in the header file
-    <dev/i2c/i2c_io.h>:

-

-  

-  
User ioctl to execute an i2c operation.
-    

-    
typedef enum {
-        I2C_OP_READ,
-        I2C_OP_READ_WITH_STOP,
-        I2C_OP_WRITE,
-        I2C_OP_WRITE_WITH_STOP,
-        I2C_OP_READ_BLOCK,
-        I2C_OP_WRITE_BLOCK
-} i2c_op_t;
-
-typedef struct i2c_ioctl_exec {
-	i2c_op_t iie_op;	/* operation to perform */
-	i2c_addr_t iie_addr;	/* address of device */
-	const void *iie_cmd;	/* pointer to command */
-	size_t iie_cmdlen;	/* length of command */
-	void *iie_buf;		/* pointer to data buffer */
-	size_t iie_buflen;	/* length of data buffer */
-} i2c_ioctl_exec_t;

-    

-  

-

-

-

-

-
A wide list of I2C masters are supported, among them are:

-

-

-

-  
acpismbus(4)

-  
ACPI SMBus Control Method Interface

-  
alipm(4)

-  
Acer Labs M7101 SMBus controller

-  
amdpm(4)

-  
AMD768 Power Management Controller and AMD8111 System Management
-      Controller

-  
coram(4)

-  
Digital video driver for Conexant CX23885 based cards

-  
cuda(4)

-  
Support for CUDA microcontrollers found in many Power Macintosh and
-      compatible computers

-  
cxdtv(4)

-  
Digital video driver for Conexant CX2388x based cards

-  
ds28e17iic(4)

-  
1-Wire to I2C bridge

-  
gpioiic(4)

-  
GPIO I2C controller

-  
ichsmb(4)

-  
Intel Chipset internal SMBus controller

-  
ismt(4)

-  
Intel Chipset internal SMBus 2.0 controller with DMA

-  
nfsmb(4)

-  
NVIDIA nForce 2/3/4 SMBus controller and SMBus driver

-  
piixpm(4)

-  
Intel PIIX and compatible Power Management controller

-  
umcpmio(4)

-  
MCP-2221 / 2221A USB multi-io chip

-

-

-

-

-

-
A wide list of slaves are supported, among them:

-

-

-

-  
adm1026hm(4)

-  
Analog Devices ADM1026 complete thermal system management controller

-  
admtemp(4)

-  
Analog Devices ADM1021 temperature sensor

-  
aht20temp(4)

-  
Aosong AHT20 humidity/temperature sensors

-  
am2315temp(4)

-  
Aosong AM2315 humidity/temperature sensors

-  
bmx280thp(4)

-  
Bosch BMP280/BME280 humidity/temperature/pressure sensors

-  
ddc(4)

-  
VESA Display Data Channel V2 devices

-  
dbcool(4)

-  
dbCool(tm) family of environmental monitors and fan controllers

-  
ds2482ow(4)

-  
Maxim DS2482-100 and DS2482-800 I2C to 1-Wire bridge

-  
emcfan(4)

-  
Microchip Technology EMC210X and EMC230X fan controllers

-  
g760a(4)

-  
Global Mixed-mode Technology Inc. G760a fan speed controller

-  
hythygtemp(4)

-  
IST-AG HYT-221/271/939 humidity/temperature sensors

-  
ibmhawk(4)

-  
Temperature, voltage, and fan sensors present on IBM eServers

-  
ims(4)

-  
I2C mice and touch panels

-  
lm(4)

-  
National Semiconductor LM78, LM79, and compatible hardware monitors

-  
lmenv(4)

-  
National Semiconductor LM81, LM87, and compatible hardware monitors

-  
lmtemp(4)

-  
National Semiconductor LM75, LM77, and compatible hardware monitors

-  
mcp980x(4)

-  
Microchip 9800/1/2/3 I2C temperature sensor

-  
mpl115a(4)

-  
Freescale MPL115A2 absolute pressure sensor

-  
pcf8563rtc(4)

-  
NXP PCF8563 real-time clock

-  
rs5c372rtc(4)

-  
RICOH RS5C372A and RS5C372B real-time clock

-  
s390rtc(4)

-  
Seiko Instruments S-35390 real-time clock

-  
sc16is7xx(4)

-  
NXP 16C450 like UART bridge

-  
scmdi2c(4)

-  
I2C frontend for the Sparkfun Serial Controlled Motor Driver.

-  
sdtemp(4)

-  
JEDEC JC-42.4 compatible memory module temperature sensors

-  
seeprom(4)

-  
24-series I2C EEPROM driver

-  
sgp40mox(4)

-  
Sensirion SGP40 MOx gas sensors

-  
sgsmix(4)

-  
SGS 7433 Basic Audio Processor found in some Apple machines

-  
sht3xtemp(4)

-  
Sensirion SHT30/SHT31/SHT35 temperature/humidity sensors

-  
sht4xtemp(4)

-  
Sensirion SHT40/SHT41/SHT45 temperature/humidity sensors

-  
si70xxtemp(4)

-  
Silicon Labs SI7013/SI7020/SI7021 humidity/temperature sensors

-  
smscmon(4)

-  
Standard Microsystems Corporation LPC47M192 and LPC47M997 sensors

-  
spdmem(4)

-  
Generic Memory Module Serial Presence Detect

-  
ssdfb(4)

-  
OLED/PLED framebuffer modules

-  
tea5767radio(4)

-  
Philips/NXP TEA5767 FM stereo radio

-  
tps65217pmic(4)

-  
Texas Instruments TPS65217 Power Management IC

-  
tsllux(4)

-  
Taos TSL256x Light-to-Digital Converter

-

-

-

-

-

-

-  
/dev/iicu

-  
I2C device unit u file.

-

-

-

-

-
dtviic(4), intro(4),
-    i2cscan(8), iic(9)

-

-

-

-
The I2C framework first appeared in NetBSD
-    2.0. OpenBSD support was added in
-    OpenBSD 3.6. This manpage first appeared in
-    NetBSD 6.0, it was ported from
-    OpenBSD.

-

-

-

-
The I2C framework was written by Steve C.
-    Woodford and Jason R. Thorpe for
-    NetBSD and then ported to
-    OpenBSD by Alexander
-    Yurchenko
-    <grange@openbsd.org>.

-

-

-
-  
-    
-    
-  
-
November 6, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/ikphy.4 4.html b/static/netbsd/man4/ikphy.4 4.html
deleted file mode 100644
index 497b9ce2..00000000
--- a/static/netbsd/man4/ikphy.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
IKPHY(4)Device Drivers ManualIKPHY(4)

-

-

-

-
ikphy — driver for
-    Intel i82563 Kumeran 10/100/1000 Ethernet PHYs

-

-

-

-
ikphy* at mii? phy ?

-

-

-

-
The ikphy driver supports the Intel i82563
-    Kumeran 10/100/1000 Ethernet PHYs. These PHYs are found on a variety of
-    high-performance Ethernet interfaces.

-

-

-

-
While not required for basic card operation, the lack of this
-    device will mean that the wm(4) device cannot detect link
-    and link-speed.

-

-

-

-
ifmedia(4), mii(4),
-    wm(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
October 13, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/ims.4 4.html b/static/netbsd/man4/ims.4 4.html
deleted file mode 100644
index 14494801..00000000
--- a/static/netbsd/man4/ims.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
IMS(4)Device Drivers ManualIMS(4)

-

-

-

-
ims — I2C mouse
-    and touchpanel support

-

-

-

-
ims* at ihidev? reportid ?
-  

-  wsmouse* at ims?

-

-

-

-
The ims driver provides support for I2C
-    mice and touchpanels. Access to the movement data is through the
-    wsmouse(4) driver.

-

-

-

-
ihidev(4), wsmouse(4)

-

-

-

-
The ims driver appeared in
-    NetBSD 8.0.

-

-

-
-  
-    
-    
-  
-
December 10, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/inet.4 4.html b/static/netbsd/man4/inet.4 4.html
deleted file mode 100644
index a8a64588..00000000
--- a/static/netbsd/man4/inet.4 4.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
INET(4)Device Drivers ManualINET(4)

-

-

-

-
inet — Internet
-    protocol family

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <netinet/in.h>

-

-

-

-
The Internet protocol family is a collection of protocols layered
-    atop the
-     (IP) transport layer, and using the Internet address
-    format. The Internet family provides protocol support for the
-    SOCK_STREAM, SOCK_DGRAM, and
-    SOCK_RAW socket types; the
-    SOCK_RAW interface provides access to the IP
-    protocol.

-

-

-

-
Internet addresses are four byte quantities, stored in network
-    standard format (on the VAX these are word and byte reversed). The include
-    file <netinet/in.h> defines
-    this address as a discriminated union.

-
Sockets bound to the Internet protocol family use the following
-    addressing structure,

-

-
struct sockaddr_in {
-	uint8_t		sin_len;
-	sa_family_t	sin_family;
-	in_port_t	sin_port;
-	struct in_addr	sin_addr;
-	int8_t		sin_zero[8];
-};

-

-
Sockets may be created with the local address
-    INADDR_ANY to effect “wildcard”
-    matching on incoming messages. The address in a connect(2)
-    or sendto(2) call may be given as
-    INADDR_ANY to mean “this host”. The
-    distinguished address INADDR_BROADCAST is allowed as
-    a shorthand for the broadcast address on the primary network if the first
-    network configured supports broadcast.

-

-

-

-
The Internet protocol family comprises the IP transport protocol,
-    Internet Control Message Protocol (ICMP), Transmission Control Protocol
-    (TCP), and User Datagram Protocol (UDP). TCP is used to support the
-    SOCK_STREAM abstraction while UDP is used to support
-    the SOCK_DGRAM abstraction. A raw interface to IP is
-    available by creating an Internet socket of type
-    SOCK_RAW. The ICMP message protocol is accessible
-    from a raw socket.

-
The 32-bit Internet address contains both network and host parts.
-    It is frequency-encoded; the most-significant bit is clear in Class A
-    addresses, in which the high-order 8 bits are the network number. Class B
-    addresses use the high-order 16 bits as the network field, and Class C
-    addresses have a 24-bit network part. Sites with a cluster of local networks
-    and a connection to the Internet may chose to use a single network number
-    for the cluster; this is done by using subnet addressing. The local (host)
-    portion of the address is further subdivided into subnet and host parts.
-    Within a subnet, each subnet appears to be an individual network;
-    externally, the entire cluster appears to be a single, uniform network
-    requiring only a single routing entry. Subnet addressing is enabled and
-    examined by the following ioctl(2) commands on a datagram
-    socket in the Internet domain; they have the same form as the
-    SIOCIFADDR command (see
-    netintro(4)).

-

-  

-  
Set interface network mask. The network mask defines the network part of
-      the address; if it contains more of the address than the address type
-      would indicate, then subnets are in use.

-  

-  
Get interface network mask.

-

-

-

-

-
ioctl(2), socket(2),
-    icmp(4), intro(4),
-    ip(4), netintro(4),
-    tcp(4), udp(4)

-
Stuart Sechrest,
-    An Introductory 4.4BSD Interprocess Communication
-    Tutorial. (see
-    /usr/share/doc/reference/ref3/sockets)

-
Samuel J. Leffler,
-    Robert S. Fabry, William N.
-    Joy, Phil Lapsley, Steve
-    Miller, and Chris Torek,
-    Advanced 4.4BSD IPC Tutorial. (see
-    /usr/share/doc/reference/ref3/sockets-advanced)

-

-

-

-
The inet protocol interface appeared in
-    4.2BSD.

-

-

-

-
The Internet protocol support is subject to change as the Internet
-    protocols develop. Users should not depend on details of the current
-    implementation, but rather the services exported.

-

-

-
-  
-    
-    
-  
-
June 28, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/inet6.4 3.html b/static/netbsd/man4/inet6.4 3.html
deleted file mode 100644
index 722c4155..00000000
--- a/static/netbsd/man4/inet6.4 3.html	
+++ /dev/null
@@ -1,196 +0,0 @@
-
-  
-    
-    
-    
-  
-
INET6(4)Device Drivers ManualINET6(4)

-

-

-

-
inet6 — Internet
-    protocol version 6 family

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <netinet/in.h>

-

-

-

-
The inet6 family is an updated version of
-    inet(4) family. While inet(4) implements
-    Internet Protocol version 4, inet6 implements
-    Internet Protocol version 6.

-
inet6 is a collection of
-    protocols layered atop the
-     (IPv6) transport layer, and using the IPv6 address format.
-    The inet6 family provides protocol support for the
-    SOCK_STREAM, SOCK_DGRAM, and
-    SOCK_RAW socket types; the
-    SOCK_RAW interface provides access to the IPv6
-    protocol.

-

-

-

-
IPv6 addresses are 16 byte quantities, stored in network standard
-    byteorder. The include file
-    <netinet/in.h> defines this
-    address as a discriminated union.

-
Sockets bound to the inet6 family use the
-    following addressing structure:

-

-
struct sockaddr_in6 {
-	uint8_t		sin6_len;
-	sa_family_t	sin6_family;
-	in_port_t	sin6_port;
-	uint32_t	sin6_flowinfo;
-	struct in6_addr	sin6_addr;
-	uint32_t	sin6_scope_id;
-};

-

-
Sockets may be created with the local address
-    “::” (which is equal to IPv6 address
-    0:0:0:0:0:0:0:0) to effect “wildcard”
-    matching on incoming messages.

-
The IPv6 specification defines scoped addresses, like link-local
-    or site-local addresses. A scoped address is ambiguous to the kernel, if it
-    is specified without a scope identifier. To manipulate scoped addresses
-    properly from the userland, programs must use the advanced API defined in
-    RFC 2292. A compact description of the advanced API is available in
-    ip6(4). If a scoped address is specified without an
-    explicit scope, the kernel may raise an error. Note that scoped addresses
-    are not for daily use at this moment, both from a specification and an
-    implementation point of view.

-
The KAME implementation supports an extended numeric IPv6 address
-    notation for link-local addresses, like
-    “fe80::1%de0” to specify
-    “fe80::1 on de0
-    interface”. This notation is supported by
-    getaddrinfo(3) and getnameinfo(3). Some
-    of normal userland programs, such as telnet(1) or
-    ftp(1), are able to use this notation. With special
-    programs like ping6(8), you can specify the outgoing
-    interface by an extra command line option to disambiguate scoped
-  addresses.

-
Scoped addresses are handled specially in the kernel. In kernel
-    structures like routing tables or interface structures, a scoped address
-    will have its interface index embedded into the address. Therefore, the
-    address in some kernel structures is not the same as that on the wire. The
-    embedded index will become visible through a
-    PF_ROUTE socket, kernel memory accesses via
-    kvm(3) and on some other occasions. HOWEVER, users should
-    never use the embedded form. For details please consult
-    http://www.kame.net/dev/cvsweb2.cgi/kame/IMPLEMENTATION.
-    Note that the above URL describes the situation with the latest KAME tree,
-    not the NetBSD tree.

-

-

-

-
The inet6 family comprises the IPv6
-    network protocol, Internet Control Message Protocol version 6 (ICMPv6),
-    Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). TCP
-    is used to support the SOCK_STREAM abstraction while
-    UDP is used to support the SOCK_DGRAM abstraction.
-    Note that TCP and UDP are common to inet(4) and
-    inet6. A raw interface to IPv6 is available by
-    creating an Internet socket of type SOCK_RAW. The
-    ICMPv6 message protocol is accessible from a raw socket.

-

-

-
By default, NetBSD does not route IPv4
-    traffic to AF_INET6 sockets. The default behavior
-    intentionally violates RFC 2553 for security reasons. Listen to two sockets
-    if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed
-    with certain per-socket/per-node configuration, however, it is not
-    recommended to do so. Consult ip6(4) for details.

-
The behavior of AF_INET6 TCP/UDP socket is
-    documented in RFC 2553. Basically, it says this:

-
    
-  
  • A specific bind on an AF_INET6 socket
-      (bind(2) with an address specified) should accept IPv6
-      traffic to that address only.
    • 
-  
  • If you perform a wildcard bind on an AF_INET6
-      socket (bind(2) to IPv6 address
-      ::), and there is no wildcard bind
-      AF_INET socket on that TCP/UDP port, IPv6 traffic
-      as well as IPv4 traffic should be routed to that
-      AF_INET6 socket. IPv4 traffic should be seen as if
-      it came from an IPv6 address like ::ffff:10.1.1.1.
-      This is called an IPv4 mapped address.
    • 
-  
  • If there are both a wildcard bind AF_INET socket
-      and a wildcard bind AF_INET6 socket on one TCP/UDP
-      port, they should behave separately. IPv4 traffic should be routed to the
-      AF_INET socket and IPv6 should be routed to the
-      AF_INET6 socket.
    • 
-

-
However, RFC 2553 does not define the ordering constraint between
-    calls to bind(2), nor how IPv4 TCP/UDP port numbers and
-    IPv6 TCP/UDP port numbers relate to each other (should they be integrated or
-    separated). Implemented behavior is very different from kernel to kernel.
-    Therefore, it is unwise to rely too much upon the behavior of
-    AF_INET6 wildcard bind sockets. It is recommended to
-    listen to two sockets, one for AF_INET and another
-    for AF_INET6, when you would like to accept both
-    IPv4 and IPv6 traffic.

-
It should also be noted that malicious parties can take advantage
-    of the complexity presented above, and are able to bypass access control, if
-    the target node routes IPv4 traffic to AF_INET6
-    socket. Users are advised to take care handling connections from IPv4 mapped
-    address to AF_INET6 sockets.

-

-

-

-

-
ioctl(2), socket(2),
-    sysctl(3), icmp6(4),
-    intro(4), ip6(4),
-    tcp(4), udp(4)

-
Qing Li,
-    Tatuya Jinmei, and Keiichi
-    Shima, IPv6 Core Protocols Implementation,
-    Morgan Kaufmann,
-  2006.

-
Qing Li,
-    Tatuya Jinmei, and Keiichi
-    Shima, IPv6 Advanced Protocols Implementation,
-    Morgan Kaufmann,
-  2007.

-

-

-

-
Tatuya Jinmei and
-    Atsushi Onoe, An Extension of
-    Format for IPv6 Scoped Addresses, internet
-    draft,
-    draft-ietf-ipngwg-scopedaddr-format-02.txt,
-    June 2000, work in progress
-    material.

-

-

-

-
The inet6 protocol interfaces are defined
-    in RFC 2553 and RFC 2292. The implementation described herein appeared in
-    the WIDE/KAME project.

-

-

-

-
The IPv6 support is subject to change as the Internet protocols
-    develop. Users should not depend on details of the current implementation,
-    but rather the services exported.

-
Users are suggested to implement “version
-    independent” code as much as possible, as you will need to support
-    both inet(4) and inet6.

-

-

-
-  
-    
-    
-  
-
March 10, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/inphy.4 4.html b/static/netbsd/man4/inphy.4 4.html
deleted file mode 100644
index cc39ef64..00000000
--- a/static/netbsd/man4/inphy.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
INPHY(4)Device Drivers ManualINPHY(4)

-

-

-

-
inphy — Driver for
-    Intel i82555 and i82562 10/100 Ethernet PHYs

-

-

-

-
inphy* at mii? phy ?

-

-

-

-
The inphy driver supports the Intel i82555
-    and i82562 10/100 Ethernet PHYs. These PHYs are found on a variety of
-    high-performance Ethernet interfaces.

-

-

-

-
While not required for basic card operation, the lack of this
-    device will mean that the fxp(4) device cannot detect link
-    and link-speed.

-

-

-

-
fxp(4), ifmedia(4),
-    intro(4), mii(4),
-    wm(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 6, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/intersil7170.4 4.html b/static/netbsd/man4/intersil7170.4 4.html
deleted file mode 100644
index a1c51516..00000000
--- a/static/netbsd/man4/intersil7170.4 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTERSIL7170(4)Device Drivers ManualINTERSIL7170(4)

-

-

-

-
intersil7170 —
-    Intersil ICM7170 time-of-day clock driver

-

-

-

-
#include
-    <dev/ic/intersil7170reg.h>
-  

-  #include
-    <dev/ic/intersil7170var.h>

-
define intersil7170
-  

-  file dev/ic/intersil7170.c intersil7170

-

-

-

-
The intersil7170 driver provides access to
-    the Intersil ICM7170 time-of-day clock chip. Access methods to retrieve and
-    set date and time are provided through the
-    
-    interface defined in todr(9).

-
To tie an instance of this device to the
-    system, use the
-    ()
-    function and the intersil7170_softc structure defined
-    as follows:

-
void
-    (struct
-    intersil7170_softc *)

-

-
struct intersil7170_softc {
-	struct device	sc_dev;
-	bus_space_tag_t	sc_bst;
-	bus_space_handle_t sc_bsh;
-	struct todr_chip_handle sc_handle;
-	u_int		sc_year0;
-	u_int		sc_flag;
-};

-

-

-

-  
bus_tag

-  
 

-  
bus_handle

-  
Specify bus space access to the chip's non-volatile memory (including the
-      clock registers).

-  
sc_handle

-  
TODR handle passed to the
-      ()
-      function to register todr(9) interface.

-  
sc_year0

-  
The actual year represented by the clock's ‘year’ counter.
-      This is generally dependent on the system configuration in which the clock
-      device is mounted. For instance, on Sun Microsystems machines the
-      convention is to have clock's two-digit year represent the year 1968.

-  
sc_flag

-  
This flag is used to specify machine-dependent features.

-

-

-
Note that if the resulting date retrieved with the todr_gettime()
-    method is earlier that January 1, 1970, the driver will assume that the
-    chip's year counter actually represents a year in the 21st century. This
-    behaviour can be overridden by setting the
-    INTERSIL7170_NO_CENT_ADJUST flag in
-    sc_flag.

-

-

-

-
intro(4), todr(9)

-

-

-

-
The intersil7170 driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The intersil7170 driver was written by
-    Paul Kranenburg ⟨pk@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
October 1, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/intro.4 3.html b/static/netbsd/man4/intro.4 3.html
deleted file mode 100644
index 6a655eba..00000000
--- a/static/netbsd/man4/intro.4 3.html	
+++ /dev/null
@@ -1,136 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers ManualINTRO(4)

-

-

-

-
intro —
-    introduction to devices and device drivers

-

-

-

-
This section contains information related to devices, device
-    drivers and miscellaneous hardware.

-

-

-
Device is a term used mostly for hardware-related stuff that
-    belongs to the system, like disks, printers, or a graphics display with its
-    keyboard. There are also so-called
-    
-    where a device driver emulates the behaviour of a device in software without
-    any particular underlying hardware. A typical example for the latter class
-    is /dev/mem, a loophole where the physical memory
-    can be accessed using the regular file access semantics.

-
The device abstraction generally provides a common set of system
-    calls layered on top of them, which are dispatched to the corresponding
-    device driver by the upper layers of the kernel. The set of system calls
-    available for devices is chosen from open(2),
-    close(2), read(2),
-    write(2), ioctl(2),
-    select(2), and mmap(2). Not all drivers
-    implement all system calls, for example, calling mmap(2)
-    on terminal devices is likely to be not useful at all.

-

-

-

-
Most of the devices in a UNIX-like
-    operating system are accessed through so-called
-    , sometimes also called
-    . They are usually located under the directory
-    /dev in the file system hierarchy (see also
-    hier(7)).

-
Note that this could lead to an inconsistent state, where either
-    there are device nodes that do not have a configured driver associated with
-    them, or there may be drivers that have successfully probed for their
-    devices, but cannot be accessed since the corresponding device node is still
-    missing. In the first case, any attempt to reference the device through the
-    device node will result in an error, returned by the upper layers of the
-    kernel, usually ENXIO. In the second case, the
-    device node needs to be created before the driver and its device will be
-    usable.

-
Some devices come in two flavors:
-     and
-    
-    devices, or to use better terms, buffered and unbuffered (raw) devices. The
-    traditional names are reflected by the letters
-    ‘b’ and
-    ‘c’ as the file type identification in
-    the output of ‘ls -l’. Buffered
-    devices are being accessed through the buffer cache of the operating system,
-    and they are solely intended to layer a file system on top of them. They are
-    normally implemented for disks and disk-like devices only and, for
-    historical reasons, for tape devices.

-
Raw devices are available for all drivers, including those that
-    also implement a buffered device. For the latter group of devices, the
-    differentiation is conventionally done by prepending the letter
-    ‘r’ to the path name of the device
-    node, for example /dev/rsd0[cd] denotes the raw
-    device for the first SCSI disk, while /dev/sd0[cd]
-    is the corresponding device node for the buffered device.

-
Unbuffered devices should be used for all actions that
-    are not related to file system operations, even if the device in question is
-    a disk device. This includes making backups of entire disk partitions, or to
-     floppy disks
-    (i.e., those used like tapes).

-
Access restrictions to device nodes are usually subject to the
-    regular file permissions of the device node entry, instead of being enforced
-    directly by the drivers in the kernel.

-

-

-

-
Drivers for network devices do not use device nodes in order to be
-    accessed. Their selection is based on other decisions inside the kernel, and
-    instead of calling open(2), use of a network device is
-    generally introduced by using the system call
-  socket(2).

-

-

-

-
For each kernel, there is a configuration file that is used as a
-    base to select the facilities and drivers for that kernel, and to tune
-    several options. See config(1) for a detailed description
-    of the files involved. The individual manual pages in this section provide a
-    sample line for the configuration file in their synopsis portion. See also
-    the sample config file
-    /usr/src/sys/arch/i386/conf/GENERIC (for the
-    
-    architecture).

-

-

-

-

-
config(1), close(2),
-    ioctl(2), mmap(2),
-    open(2), read(2),
-    select(2), socket(2),
-    write(2), hier(7)

-

-

-

-
This manual page first appeared in FreeBSD
-    2.1 and NetBSD 9.

-

-

-

-
This man page has been written by Jörg
-    Wunsch with initial input by David E.
-    O'Brien.

-

-

-
-  
-    
-    
-  
-
December 18, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/ioasic.4 4.html b/static/netbsd/man4/ioasic.4 4.html
deleted file mode 100644
index 627d5e08..00000000
--- a/static/netbsd/man4/ioasic.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOASIC(4)Device Drivers ManualIOASIC(4)

-

-

-

-
ioasic — baseboard
-    IO control ASIC for DEC TURBOchannel systems

-

-

-

-
ioasic0 at tc? slot ? offset ?

-

-

-

-
The ioasic driver provides support for the
-    DEC proprietary IOCTL ASIC found on all DEC TURBOchannel machines with MIPS
-    (DECstation 5000 series, excluding the 5000/200) and Alpha (3000-series)
-    processors. On these machines (including the 5000/200), all baseboard
-    devices should be configured as children of the
-    ioasic device.

-
The ioasic provides hardware DMA channels
-    and interrupt support for several baseboard devices, including one
-    asc SCSI device with a scatter/gather DMA channel,
-    an mc146818-compatible mcclock, an Am7930 audio
-    device bba, one or two zs
-    two-port serial devices, and a AMD 7990 LANCE le
-    Ethernet interface.

-
The ioasic is also used for the
-    floppy-disc drive and audio/ISDN hardware on the Personal DECstation and
-    audio-equipped TURBOchannel Alphas, where the ioasic
-    hardware provides a scatter-gather DMA channel between the 16-bit device and
-    the 32-bit tc DMA address space.

-
Support for scatter-gather DMA eliminates the need for additional
-    copying. A baseboard asc SCSI adaptor attached to an
-    ioasic will give slightly better performance than
-    its tc counterpart.

-

-

-

-
asc(4), bba(4),
-    intro(4), le(4),
-    mcclock(4), tc(4),
-    zs(4)

-

-

-

-
The ioasic driver first appeared in
-    NetBSD 1.1, derived from DECstation boot-time
-    configuration code in 4.4BSD.

-

-

-

-
The DECstation 5000/200 does not actually have an IOASIC chip, but
-    for consistency it must be configured as if it did.

-

-

-
-  
-    
-    
-  
-
September 12, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/ioat.4 4.html b/static/netbsd/man4/ioat.4 4.html
deleted file mode 100644
index 7e0182bc..00000000
--- a/static/netbsd/man4/ioat.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOAT(4)Device Drivers ManualIOAT(4)

-

-

-

-
ioat —
-    multiplexing serial communications interface

-

-

-

-
For 6-port BOCA IOAT66 board:

-

-  

-  ioat0 at isa? port 0x220 irq 5
-  

-  com2 at ioat? slave ?
-  

-  com3 at ioat? slave ?
-  

-  com4 at ioat? slave ?
-  

-  com5 at ioat? slave ?
-  

-  com6 at ioat? slave ?
-  

-  com7 at ioat? slave ?

-

-

-

-
The ioat driver provides support for BOCA
-    Research IOAT66 boards that multiplex together up to six EIA RS-232C (CCITT
-    V.28) communications interfaces.

-
Each ioat device is the master device for
-    up to six com devices. The kernel configuration
-    specifies these com devices as slave devices of the
-    ioat device, as shown in the synopsis. The slave ID
-    given for each com device determines which bit in
-    the interrupt multiplexing register is tested to find interrupts for that
-    device. The port specification for the ioat device
-    is used to compute the base addresses for the com
-    subdevices. The port for the interrupt multiplexing register is not
-    programmable.

-

-

-

-

-  
/dev/tty??

-  
 

-

-

-

-

-
com(4)

-

-

-

-
The ioat driver was adapted from the boca
-    driver by Michael Richardson.

-

-

-
-  
-    
-    
-  
-
January 24, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/iop.4 2.html b/static/netbsd/man4/iop.4 2.html
deleted file mode 100644
index 702b81d9..00000000
--- a/static/netbsd/man4/iop.4 2.html	
+++ /dev/null
@@ -1,164 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOP(4)Device Drivers ManualIOP(4)

-

-

-

-
iop — I2O adapter
-    driver

-

-

-

-
iop* at pci? dev ? function ?
-  

-  iopsp* at iop? tid ?
-  

-  ld* at iop? tid ?
-  

-  dpti* at iop? tid 0

-

-

-

-
The iop driver provides support for PCI
-    I/O processors conforming to the I2O specification, revision 1.5 and
-  above.

-
I2O is a specification that defines a software interface for
-    communicating with a number of device types. In its basic form, I2O provides
-    the following:

-
    
-  
  • A vendor-neutral interface for communicating with an I/O processor (IOP)
-      and a number of types of peripherals. In order to achieve this,
-      hardware-specific device drivers run on the IOP, and hardware-neutral
-      device drivers run on the host.
    • 
-  
  • Reduced I/O overhead for the host. All communication between the host and
-      the IOP is performed using a high level protocol. The specification also
-      provides for batching of requests and replies between the host and
-    IOP.
    • 
-  
  • An optional vendor-neutral configuration interface. Data from HTTP GET and
-      POST operations can be channeled to individual devices, and HTML pages
-      returned.
    • 
-

-
Five types of devices are well defined by the specification. These
-    are:

-

-
    
-  
  • Random block storage devices (disks).
    • 
-  
  • Sequential storage devices (tapes).
    • 
-  
  • LAN interfaces, including Ethernet, FDDI, and Token Ring.
    • 
-  
  • Bus ports (SCSI).
    • 
-  
  • SCSI peripherals.
    • 
-

-
The iop driver's role is to initialize and
-    monitor the IOP, provide a conduit for messages and replies to and from
-    devices, and provide other common services for peripheral drivers, such as
-    DMA mapping.

-

-

-

-
The following structures and constants are defined in
-    dev/i2o/iopio.h. Note that the headers
-    sys/types.h, sys/device.h
-    and dev/i2o/i2o.h are prerequisites and must
-    therefore be included beforehand.

-

-  

-  
Submit a message to the IOP and return the reply. Note that the return
-      value of this ioctl is not affected by completion status as indicated by
-      the reply.
-    

-    
struct ioppt {
-	void	*pt_msg;	/* pointer to message buffer */
-	size_t	pt_msglen;	/* message buffer size in bytes */
-	void	*pt_reply;	/* pointer to reply buffer */
-	size_t	pt_replylen;	/* reply buffer size in bytes */
-	int	pt_timo;	/* completion timeout in ms */
-	int	pt_nbufs;	/* number of transfers */
-	struct	ioppt_buf pt_bufs[IOP_MAX_MSG_XFERS]; /* transfers */
-};
-
-struct ioppt_buf {
-	void	*ptb_data;	/* pointer to buffer */
-	size_t	ptb_datalen;	/* buffer size in bytes */
-	int	ptb_out;	/* non-zero if transfer is to IOP */
-};

-    

-    
The minimum timeout value that may be specified is 1000ms. All
-        other values must not exceed the iop driver's
-        operational limits.

-    
The initiator context and transaction context fields in the
-        message frame will be filled by the iop driver.
-        As such, this ioctl may not be used to send messages without a
-        transaction context payload.

-  

-  

-  
Request the latest available status record from the IOP. This special-case
-      ioctl is provided as the I2O_EXEC_STATUS_GET message does not post
-      replies, and can therefore not be safely issued using the IOPIOCPT
-    ioctl.

-

-
The following ioctls may block while attempting to acquire the
-    iop driver's configuration lock, and may fail if the
-    acquisition times out.

-

-  

-  
Retrieve the iop driver's copy of the logical
-      configuration table. This copy of the LCT matches the current device
-      configuration, but is not necessarily the latest available version of the
-      LCT.

-  

-  
Request that the iop driver scan all bus ports,
-      retrieve the latest version of the LCT, and attach or detach devices as
-      necessary. Note that higher-level reconfiguration tasks (such as logically
-      re-scanning SCSI busses) will not be performed by this ioctl.

-  

-  
Retrieve the TID to device map. This map indicates which targets are
-      configured, and what the corresponding device name for each is. Although
-      at any given point it contains the same number of entries as the LCT, the
-      number of entries should be determined using the iov_len field from the
-      returned iovec.
-    

-    
struct iop_tidmap {
-	u_short	it_tid;
-	u_short	it_flags;
-	char	it_dvname[16];	/* DEVICE_XNAME_SIZE */
-};
-#define	IT_CONFIGURED	0x02	/* target configured */

-    

-  

-

-

-

-

-

-  
/dev/iopu

-  
control device for IOP unit u

-

-

-

-

-
dpti(4), intro(4),
-    iopsp(4), ld(4),
-    iopctl(8)

-

-

-

-
The iop driver first appeared in
-    NetBSD 1.5.3.

-

-

-
-  
-    
-    
-  
-
December 2, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/iophy.4 4.html b/static/netbsd/man4/iophy.4 4.html
deleted file mode 100644
index e872b862..00000000
--- a/static/netbsd/man4/iophy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOPHY(4)Device Drivers ManualIOPHY(4)

-

-

-

-
iophy — Driver for
-    Intel i82553 10/100 Ethernet PHYs

-

-

-

-
iophy* at mii? phy ?

-

-

-

-
The iophy driver supports the Intel i82553
-    10/100 Ethernet PHYs found on some Intel i82557-based Ethernet cards.

-

-

-

-
fxp(4), ifmedia(4),
-    intro(4), mii(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 3, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/iopsp.4 4.html b/static/netbsd/man4/iopsp.4 4.html
deleted file mode 100644
index a568afc7..00000000
--- a/static/netbsd/man4/iopsp.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOPSP(4)Device Drivers ManualIOPSP(4)

-

-

-

-
iopsp — I2O SCSI
-    port driver

-

-

-

-
iopsp* at iop? tid ?
-  

-  scsibus* at iopsp?

-

-

-

-
The iopsp driver provides support for I2O
-    SCSI bus adapter ports and child peripherals.

-
IOPs present each child peripheral attached to a bus adapter port
-    as an individual device. In order to present the appearance of a bus, the
-    iopsp driver groups child peripherals by controlling
-    port.

-
On IOPs containing a SCSI port and block or tape driver modules,
-    some SCSI devices may not be directly accessible. For each inaccessible
-    device, a message will be displayed during configuration. For example:

-

-
	iopsp0: target 0,0 (tid 70): in use by tid 47

-

-
Such devices will usually be indirectly accessible as block
-    devices, either individually or as part of an array.

-

-

-

-
intro(4), iop(4),
-    ld(4), scsi(4)

-

-

-

-
The iopsp driver first appeared in
-    NetBSD 1.5.3.

-

-

-
-  
-    
-    
-  
-
November 8, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/ip.4 3.html b/static/netbsd/man4/ip.4 3.html
deleted file mode 100644
index bf3581ba..00000000
--- a/static/netbsd/man4/ip.4 3.html	
+++ /dev/null
@@ -1,379 +0,0 @@
-
-  
-    
-    
-    
-  
-
IP(4)Device Drivers ManualIP(4)

-

-

-

-
ip — Internet
-    Protocol

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netinet/in.h>

-
int
-  

-  socket(AF_INET,
-    SOCK_RAW,
-    proto);

-

-

-

-
IP is the network layer protocol used by the Internet protocol
-    family. Options may be set at the IP level when using higher-level protocols
-    that are based on IP (such as TCP and UDP). It may also be accessed through
-    a “raw socket” when developing new protocols, or
-    special-purpose applications.

-
There are several IP-level
-    setsockopt(2)/getsockopt(2) options.
-    IP_OPTIONS may be used to provide IP options to be
-    transmitted in the IP header of each outgoing packet or to examine the
-    header options on incoming packets. IP options may be used with any socket
-    type in the Internet family. The format of IP options to be sent is that
-    specified by the IP protocol specification (RFC 791), with one exception:
-    the list of addresses for Source Route options must include the first-hop
-    gateway at the beginning of the list of gateways. The first-hop gateway
-    address will be extracted from the option list and the size adjusted
-    accordingly before use. To disable previously specified options, use a
-    zero-length buffer:

-

-
setsockopt(s, IPPROTO_IP, IP_OPTIONS, NULL, 0);

-

-
IP_TOS and IP_TTL
-    may be used to set the type-of-service and time-to-live fields in the IP
-    header for SOCK_STREAM and
-    SOCK_DGRAM sockets. For example,

-

-
int tos = IPTOS_LOWDELAY;       /* see <netinet/ip.h> */
-setsockopt(s, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
-
-int ttl = 60;                   /* max = 255 */
-setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));

-

-
IP_IPSEC_POLICY controls IPSec policy for
-    sockets. For example,

-

-
const char *policy = "in ipsec ah/transport//require";
-char *buf = ipsec_set_policy(policy, strlen(policy));
-setsockopt(s, IPPROTO_IP, IP_IPSEC_POLICY, buf, ipsec_get_policylen(buf));

-

-
The IP_RECVPKTINFO option can be used to
-    turn on receiving of information about the destination address of the
-    packet, and the interface index. The information is passed in a
-    struct in_pktinfo structure, which contains

-

-
	struct in_addr ipi_addr;	/* the source or destination address */
-	unsigned int ipi_ifindex;	/* the interface index */

-

-
and added to the control portion of the message: The cmsghdr
-    fields have the following values:

-

-
cmsg_len = CMSG_LEN(sizeof(struct in_pktinfo))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_PKTINFO

-

-
For sendmsg(2), the source address or output
-    interface can be specified by adding an IP_PKTINFO
-    message to the control part of the message on a
-    SOCK_DGRAM or SOCK_RAW
-    socket. Setting ipi_ifindex will cause the primary address of that interface
-    to be used; setting ipi_addr will directly choose that address. The
-    IP_PKTINFO cmsghdr structure from a received message
-    may be used unchanged, in which case the outgoing message will be sent from
-    the address the incoming message was received on.

-
Setting the IP_PKTINFO option on a socket,
-    with the same struct in_pktinfo structure, will set
-    the default source address to be used until set again, unless explicitly
-    overridden on a per-packet basis, as above.

-
The IP_PORTALGO can be used to randomize
-    the port selection. Valid algorithms are described in
-    rfc6056(7) and their respective constants are in
-    <netinet/portalgo.h>. For
-    example,

-

-
int algo = PORTALGO_ALGO_RANDOM_PICK;       /* see <netinet/portalgo.h> */
-setsockopt(s, IPPROTO_IP, IP_PORTALGO, &algo, sizeof(algo));

-

-
The port selection can be also viewed and controlled at a global
-    level for all IP sockets using the following sysctl(7)
-    variables: net.inet.ip.anonportalgo.available and
-    net.inet.ip.anonportalgo.selected.

-
IP_PORTRANGE controls how ephemeral ports
-    are allocated for SOCK_STREAM and
-    SOCK_DGRAM sockets. For example,

-

-
int range = IP_PORTRANGE_LOW;       /* see <netinet/in.h> */
-setsockopt(s, IPPROTO_IP, IP_PORTRANGE, &range, sizeof(range));

-

-
If the IP_RECVDSTADDR option is enabled on
-    a SOCK_DGRAM or SOCK_RAW
-    socket, the recvmsg(2) call will return the destination IP
-    address for a UDP datagram. The msg_control field in the msghdr structure
-    points to a buffer that contains a cmsghdr structure followed by the IP
-    address. The cmsghdr fields have the following values:

-

-
cmsg_len = CMSG_LEN(sizeof(struct in_addr))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVDSTADDR

-

-
For sendmsg(2), the source address can be
-    specified by adding IP_SENDSRCADDR to the control
-    part of the message on a SOCK_DGRAM or
-    SOCK_RAW socket. The
-    IP_RECVDSTADDR cmsghdr structure from a received
-    message may be used unchanged, in which case the outgoing message will be
-    sent from the address the incoming message was received on.

-
If the IP_RECVIF option is enabled on a
-    SOCK_DGRAM or SOCK_RAW
-    socket, the recvmsg(2) call will return a struct
-    sockaddr_dl corresponding to the interface on which the packet was received.
-    the msg_control field in the msghdr structure points to a buffer that
-    contains a cmsghdr structure followed by the struct sockaddr_dl. The cmsghdr
-    fields have the following values:

-

-
cmsg_len = CMSG_LEN(sizeof(struct sockaddr_dl))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVIF

-

-
If the IP_BINDANY option is enabled on a
-    SOCK_STREAM, SOCK_DGRAM, or
-    a SOCK_RAW socket, one can bind(2)
-    to any address, even one not bound to any available network interface in the
-    system. This functionality (in conjunction with special firewall rules) can
-    be used for implementing a transparent proxy. The
-    KAUTH_REQ_NETWORK_BIND_ANYADDR privilege is needed
-    to set this option.

-
If the IP_RECVTTL option is enabled on a
-    SOCK_DGRAM socket, the recvmsg(2)
-    call will return the TTL of the received datagram. The msg_control field in
-    the msghdr structure points to a buffer that contains a cmsghdr structure
-    followed by the TTL value. The cmsghdr fields have the following values:

-

-
cmsg_len = CMSG_LEN(sizeof(uint8_t))
-cmsg_level = IPPROTO_IP
-cmsg_type = IP_RECVTTL

-

-
The IP_MINTTL option may
-    be used on SOCK_DGRAM or
-    SOCK_STREAM sockets to discard packets with a TTL
-    lower than the option value. This can be used to implement the
-     according to RFC 3682. To discard all
-    packets with a TTL lower than 255:

-

-
int minttl = 255;
-setsockopt(s, IPPROTO_IP, IP_MINTTL, &minttl, sizeof(minttl));

-

-

-

-
IP multicasting is supported only on
-    AF_INET sockets of type
-    SOCK_DGRAM and SOCK_RAW, and
-    only on networks where the interface driver supports multicasting.

-
The IP_MULTICAST_TTL option changes the
-    time-to-live (TTL) for outgoing multicast datagrams in order to control the
-    scope of the multicasts:

-

-
u_char ttl;	/* range: 0 to 255, default = 1 */
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

-

-
Datagrams with a TTL of 1 are not forwarded beyond the local
-    network. Multicast datagrams with a TTL of 0 will not be transmitted on any
-    network, but may be delivered locally if the sending host belongs to the
-    destination group and if multicast loopback has not been disabled on the
-    sending socket (see below). Multicast datagrams with TTL greater than 1 may
-    be forwarded to other networks if a multicast router is attached to the
-    local network.

-
For hosts with multiple interfaces, each multicast transmission is
-    sent from the primary network interface. The
-    IP_MULTICAST_IF option overrides the default for
-    subsequent transmissions from a given socket:

-

-
struct in_addr addr;
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));

-

-
where "addr" is the local IP address of the desired
-    interface or INADDR_ANY to specify the default
-    interface. An interface's local IP address and multicast capability can be
-    obtained via the SIOCGIFCONF and
-    SIOCGIFFLAGS ioctls. An application may also specify
-    an alternative to the default network interface by index:

-

-
struct uint32_t idx = htonl(ifindex);
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &idx, sizeof(idx));

-

-
where "ifindex" is an interface index as returned by
-    if_nametoindex(3).

-
Normal applications should not need to use
-    IP_MULTICAST_IF.

-
If a multicast datagram is sent to a group to which the sending
-    host itself belongs (on the outgoing interface), a copy of the datagram is,
-    by default, looped back by the IP layer for local delivery. The
-    IP_MULTICAST_LOOP option gives the sender explicit
-    control over whether or not subsequent datagrams are looped back:

-

-
u_char loop;	/* 0 = disable, 1 = enable (default) */
-setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));

-

-
This option improves performance for applications that may have no
-    more than one instance on a single host (such as a router demon), by
-    eliminating the overhead of receiving their own transmissions. It should
-    generally not be used by applications for which there may be more than one
-    instance on a single host (such as a conferencing program) or for which the
-    sender does not belong to the destination group (such as a time querying
-    program).

-
A multicast datagram sent with an initial TTL greater than 1 may
-    be delivered to the sending host on a different interface from that on which
-    it was sent, if the host belongs to the destination group on that other
-    interface. The loopback control option has no effect on such delivery.

-
A host must become a member of a multicast group before it can
-    receive datagrams sent to the group. To join a multicast group, use the
-    IP_ADD_MEMBERSHIP option:

-

-
struct ip_mreq mreq;
-setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

-

-
where mreq is the following structure:

-

-
struct ip_mreq {
-    struct in_addr imr_multiaddr; /* multicast group to join */
-    struct in_addr imr_interface; /* interface to join on */
-}

-

-
imr_interface should be
-    INADDR_ANY to choose the default multicast
-    interface, or the IP address of a particular multicast-capable interface if
-    the host is multihomed. Membership is associated with a single interface;
-    programs running on multihomed hosts may need to join the same group on more
-    than one interface. Up to IP_MAX_MEMBERSHIPS
-    (currently 20) memberships may be added on a single socket.

-
To drop a membership, use:

-

-
struct ip_mreq mreq;
-setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

-

-
where mreq contains the same values as used
-    to add the membership. Memberships are dropped when the socket is closed or
-    the process exits.

-

-

-

-
Raw IP sockets are connectionless, and are normally used with the
-    sendto(2) and recvfrom(2) calls, though
-    the connect(2) call may also be used to fix the
-    destination for future packets (in which case the read(2)
-    or recv(2) and write(2) or
-    send(2) system calls may be used).

-
If proto is 0, the default protocol
-    IPPROTO_RAW is used for outgoing packets, and only
-    incoming packets destined for that protocol are received. If
-    proto is non-zero, that protocol number will be used
-    on outgoing packets and to filter incoming packets.

-
Outgoing packets automatically have an IP header prepended to them
-    (based on the destination address and the protocol number the socket is
-    created with), unless the IP_HDRINCL option has been
-    set. Incoming packets are received with IP header and options intact.

-
IP_HDRINCL indicates the complete IP
-    header is included with the data and may be used only with the
-    SOCK_RAW type.

-

-
#include <netinet/ip.h>
-
-int hincl = 1;                  /* 1 = on, 0 = off */
-setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));

-

-
Unlike previous BSD releases, the program
-    must set all the fields of the IP header, including the following:

-

-
ip->ip_v = IPVERSION;
-ip->ip_hl = hlen >> 2;
-ip->ip_id = 0;  /* 0 means kernel set appropriate value */
-ip->ip_off = offset;

-

-
If the header source address is set to
-    INADDR_ANY, the kernel will choose an appropriate
-    address.

-

-

-

-

-
A socket operation may fail with one of the following errors
-    returned:

-

-  
[EACCES]

-  
when an attempt is made to create a raw IP socket by a non-privileged
-      process.

-  
[EADDRNOTAVAIL]

-  
when an attempt is made to create a socket with a network address for
-      which no network interface exists.

-  
[EISCONN]

-  
when trying to establish a connection on a socket which already has one,
-      or when trying to send a datagram with the destination address specified
-      and the socket is already connected;

-  
[ENOBUFS]

-  
when the system runs out of memory for an internal data structure;

-  
[ENOTCONN]

-  
when trying to send a datagram, but no destination address is specified,
-      and the socket hasn't been connected;

-

-
The following errors specific to IP may occur when setting or
-    getting IP options:

-

-  
[EINVAL]

-  
An unknown socket option name was given; or the IP option field was
-      improperly formed; an option field was shorter than the minimum value or
-      longer than the option buffer provided.

-

-

-

-

-
The IP_RECVPKTINFO option is used because
-    it is directly compatible with Solaris, AIX, etc., and the
-    IP_PKTINFO option is intended to be used in their
-    manner, to set the default source address for outgoing packets on a
-    SOCK_DGRAM or SOCK_RAW
-    socket. For compatibility with Linux, however, if you attempt to set the
-    IP_PKTINFO option, using an integer parameter as a
-    boolean value, this will transparently manipulate the
-    IP_RECVPKTINFO option instead. Source code
-    compatibility with both environments is thus maintained.

-

-

-

-
getsockopt(2), recv(2),
-    send(2), CMSG_DATA(3),
-    ipsec_set_policy(3), icmp(4),
-    inet(4), intro(4)

-
Internet Protocol,
-    RFC, 791,
-    September 1981.

-
Host Extensions for IP
-    Multicasting, RFC,
-    1112, August
-  1989.

-
Requirements for Internet Hosts
-    — Communication Layers, RFC,
-    1122, October
-  1989.

-

-

-

-
The ip protocol appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
September 8, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/ip6.4 3.html b/static/netbsd/man4/ip6.4 3.html
deleted file mode 100644
index b869b739..00000000
--- a/static/netbsd/man4/ip6.4 3.html	
+++ /dev/null
@@ -1,561 +0,0 @@
-
-  
-    
-    
-    
-  
-
IP6(4)Device Drivers ManualIP6(4)

-

-

-

-
ip6 — Internet
-    Protocol version 6 (IPv6) network layer

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netinet/in.h>

-
int
-  

-  socket(AF_INET6,
-    SOCK_RAW,
-    proto);

-

-

-

-
The IPv6 network layer is used by the IPv6 protocol family for
-    transporting data. IPv6 packets contain an IPv6 header that is not provided
-    as part of the payload contents when passed to an application. IPv6 header
-    options affect the behavior of this protocol and may be used by high-level
-    protocols (such as the tcp(4) and udp(4)
-    protocols) as well as directly by “raw sockets”, which process
-    IPv6 messages at a lower-level and may be useful for developing new
-    protocols and special-purpose applications.

-

-
-
All IPv6 packets begin with an IPv6 header. When data received by
-    the kernel are passed to the application, this header is not included in
-    buffer, even when raw sockets are being used. Likewise, when data are sent
-    to the kernel for transmit from the application, the buffer is not examined
-    for an IPv6 header: the kernel always constructs the header. To directly
-    access IPv6 headers from received packets and specify them as part of the
-    buffer passed to the kernel, link-level access (bpf(4),
-    for example) must be used instead.

-
The header has the following definition:

-

-
struct ip6_hdr {
-     union {
-          struct ip6_hdrctl {
-               uint32_t ip6_un1_flow;	/* 20 bits of flow ID */
-               uint16_t ip6_un1_plen;	/* payload length */
-               uint8_t	 ip6_un1_nxt;	/* next header */
-               uint8_t	 ip6_un1_hlim;	/* hop limit */
-          } ip6_un1;
-          uint8_t ip6_un2_vfc;   /* version and class */
-     } ip6_ctlun;
-     struct in6_addr ip6_src;	/* source address */
-     struct in6_addr ip6_dst;	/* destination address */
-} __packed;
-
-#define ip6_vfc		ip6_ctlun.ip6_un2_vfc
-#define ip6_flow	ip6_ctlun.ip6_un1.ip6_un1_flow
-#define ip6_plen	ip6_ctlun.ip6_un1.ip6_un1_plen
-#define ip6_nxt		ip6_ctlun.ip6_un1.ip6_un1_nxt
-#define ip6_hlim	ip6_ctlun.ip6_un1.ip6_un1_hlim
-#define ip6_hops	ip6_ctlun.ip6_un1.ip6_un1_hlim

-

-
All fields are in network-byte order. Any options specified (see
-    Options below) must also be specified in
-    network-byte order.

-
ip6_flow specifies the flow ID.
-    ip6_plen specifies the payload length.
-    ip6_nxt specifies the type of the next header.
-    ip6_hlim specifies the hop limit.

-
The top 4 bits of ip6_vfc specify the class
-    and the bottom 4 bits specify the version.

-
ip6_src and ip6_dst
-    specify the source and destination addresses.

-
The IPv6 header may be followed by any number of extension headers
-    that start with the following generic definition:

-

-
struct ip6_ext {
-     uint8_t ip6e_nxt;
-     uint8_t ip6e_len;
-} __packed;

-

-

-

-

-
IPv6 allows header options on packets to manipulate the behavior
-    of the protocol. These options and other control requests are accessed with
-    the getsockopt(2) and setsockopt(2)
-    system calls at level IPPROTO_IPV6 and by using
-    ancillary data in recvmsg(2) and
-    sendmsg(2). They can be used to access most of the fields
-    in the IPv6 header and extension headers.

-
The following socket options are supported:

-

-  

-    int *

-  
Get or set the default hop limit header field for outgoing unicast
-      datagrams sent on this socket. A value of -1 resets to the default
-    value.

-  

-    u_int *

-  
Get or set the interface from which multicast packets will be sent. For
-      hosts with multiple interfaces, each multicast transmission is sent from
-      the primary network interface. The interface is specified as its index as
-      provided by if_nametoindex(3). A value of zero specifies
-      the default interface.

-  

-    int *

-  
Get or set the default hop limit header field for outgoing multicast
-      datagrams sent on this socket. This option controls the scope of multicast
-      datagram transmissions.
-    
Datagrams with a hop limit of 1 are not forwarded beyond the
-        local network. Multicast datagrams with a hop limit of zero will not be
-        transmitted on any network but may be delivered locally if the sending
-        host belongs to the destination group and if multicast loopback (see
-        below) has not been disabled on the sending socket. Multicast datagrams
-        with a hop limit greater than 1 may be forwarded to the other networks
-        if a multicast router (such as mrouted(8)) is attached
-        to the local network.

-  

-  

-    u_int *

-  
Get or set the status of whether multicast datagrams will be looped back
-      for local delivery when a multicast datagram is sent to a group to which
-      the sending host belongs.
-    
This option improves performance for applications that may
-        have no more than one instance on a single host (such as a router
-        daemon) by eliminating the overhead of receiving their own
-        transmissions. It should generally not be used by applications for which
-        there may be more than one instance on a single host (such as a
-        conferencing program) or for which the sender does not belong to the
-        destination group (such as a time-querying program).

-    
A multicast datagram sent with an initial hop limit greater
-        than 1 may be delivered to the sending host on a different interface
-        from that on which it was sent if the host belongs to the destination
-        group on that other interface. The multicast loopback control option has
-        no effect on such delivery.

-  

-  

-    struct ipv6_mreq *

-  
Join a multicast group. A host must become a member of a multicast group
-      before it can receive datagrams sent to the group.
-    

-    
struct ipv6_mreq {
-	struct in6_addr	ipv6mr_multiaddr;
-	unsigned int	ipv6mr_interface;
-};

-    

-    
ipv6mr_interface may be set to zeroes to
-        choose the default multicast interface or to the index of a particular
-        multicast-capable interface if the host is multihomed. Membership is
-        associated with a single interface; programs running on multihomed hosts
-        may need to join the same group on more than one interface.

-    
If the multicast address is unspecified (i.e., all zeroes),
-        messages from all multicast addresses will be accepted by this group.
-        Note that setting to this value requires superuser privileges.

-  

-  

-    struct ipv6_mreq *

-  
Drop membership from the associated multicast group. Memberships are
-      automatically dropped when the socket is closed or when the process
-    exits.

-  

-    struct sadb_x_policy *

-  
Get or set IPSec policy for sockets. For example,
-    

-    
const char *policy = "in ipsec ah/transport//require";
-char *buf = ipsec_set_policy(policy, strlen(policy));
-setsockopt(s, IPPROTO_IPV6, IPV6_IPSEC_POLICY, buf, ipsec_get_policylen(buf));

-    

-  

-  

-    int *

-  
The IP_PORTALGO can be used to randomize the port
-      selection. Valid algorithms are described in rfc6056(7)
-      and their respective constants are in
-      <netinet/portalgo.h>. For
-      example,
-    

-    
int algo = PORTALGO_ALGO_RANDOM_PICK;       /* see <netinet/portalgo.h> */
-setsockopt(s, IPPROTO_IPV6, IPV6_PORTALGO, &algo, sizeof(algo));

-    

-    
The port selection can be also viewed and controlled at a
-        global level for all IPV6 sockets using the following
-        sysctl(7) variables:
-        net.inet6.ip6.anonportalgo.available and
-        net.inet6.ip6.anonportalgo.selected.

-  

-  

-    int *

-  
Get or set the allocation policy of ephemeral ports for when the kernel
-      automatically binds a local address to this socket. The following values
-      are available:
-    

-    

-      

-      
Use the regular range of non-reserved ports (varies, see
-          sysctl(8)).

-      

-      
Use a high range (varies, see sysctl(8)).

-      

-      
Use a low, reserved range (600-1023).

-    

-  

-  

-    int *

-  
Get or set whether additional information about subsequent packets will be
-      provided as ancillary data along with the payload in subsequent
-      recvmsg(2) calls. The information is stored in the
-      following structure in the ancillary data returned:
-    

-    
struct in6_pktinfo {
-	struct in6_addr ipi6_addr;    /* src/dst IPv6 address */
-	unsigned int    ipi6_ifindex; /* send/recv if index */
-};

-    

-  

-  

-    int *

-  
Get or set whether the hop limit header field from subsequent packets will
-      be provided as ancillary data along with the payload in subsequent
-      recvmsg(2) calls. The value is stored as an
-      int in the ancillary data returned.

-  

-    int *

-  
Get or set whether the hop-by-hop options from subsequent packets will be
-      provided as ancillary data along with the payload in subsequent
-      recvmsg(2) calls. The option is stored in the following
-      structure in the ancillary data returned:
-    

-    
struct ip6_hbh {
-	uint8_t ip6h_nxt;	/* next header */
-	uint8_t ip6h_len;	/* length in units of 8 octets */
-/* followed by options */
-} __packed;

-    

-    
The
-        ()
-        routine and family of routines may be used to manipulate this data.

-    
This option requires superuser privileges.

-  

-  

-    int *

-  
Get or set whether the destination options from subsequent packets will be
-      provided as ancillary data along with the payload in subsequent
-      recvmsg(2) calls. The option is stored in the following
-      structure in the ancillary data returned:
-    

-    
struct ip6_dest {
-	uint8_t ip6d_nxt;	/* next header */
-	uint8_t ip6d_len;	/* length in units of 8 octets */
-/* followed by options */
-} __packed;

-    

-    
The
-        ()
-        routine and family of routines may be used to manipulate this data.

-    
This option requires superuser privileges.

-  

-  

-    int *

-  
Get or set whether the routing header from subsequent packets will be
-      provided as ancillary data along with the payload in subsequent
-      recvmsg(2) calls. The header is stored in the following
-      structure in the ancillary data returned:
-    

-    
struct ip6_rthdr {
-	uint8_t ip6r_nxt;	/* next header */
-	uint8_t ip6r_len;	/* length in units of 8 octets */
-	uint8_t ip6r_type;	/* routing type */
-	uint8_t ip6r_segleft;	/* segments left */
-/* followed by routing-type-specific data */
-} __packed;

-    

-    
The
-        ()
-        routine and family of routines may be used to manipulate this data.

-    
This option requires superuser privileges.

-  

-  

-    struct cmsghdr *

-  
Get or set all header options and extension headers at one time on the
-      last packet sent or received on the socket. All options must fit within
-      the size of an mbuf (see mbuf(9)). Options are specified
-      as a series of cmsghdr structures followed by
-      corresponding values. cmsg_level is set to
-      IPPROTO_IPV6, cmsg_type to
-      one of the other values in this list, and trailing data to the option
-      value. When setting options, if the length optlen to
-      setsockopt(2) is zero, all header options will be reset
-      to their default values. Otherwise, the length should specify the size the
-      series of control messages consumes.
-    
Instead of using sendmsg(2) to specify
-        option values, the ancillary data used in these calls that correspond to
-        the desired header options may be directly specified as the control
-        message in the series of control messages provided as the argument to
-        setsockopt(2).

-  

-  

-    int *

-  
Get or set the byte offset into a packet where the 16-bit checksum is
-      located. When set, this byte offset is where incoming packets will be
-      expected to have checksums of their data stored and where outgoing packets
-      will have checksums of their data computed and stored by the kernel. A
-      value of -1 specifies that no checksums will be checked on incoming
-      packets and that no checksums will be computed or stored on outgoing
-      packets. The offset of the checksum for ICMPv6 sockets cannot be relocated
-      or turned off.

-  

-    int *

-  
Get or set whether only IPv6 connections can be made to this socket. For
-      wildcard sockets, this can restrict connections to IPv6 only.

-  

-    int *

-  
Get or set the status of whether faith(4) connections
-      can be made to this socket.

-  

-    int *

-  
Get or set whether the minimal IPv6 maximum transmission unit (MTU) size
-      will be used to avoid fragmentation from occurring for subsequent outgoing
-      datagrams.

-  

-    int *

-  
Get or set the ipsec(4) authentication level.

-  

-    int *

-  
Get or set the ESP transport level.

-  

-    int *

-  
Get or set the ESP encapsulation level.

-  

-    int *

-  
Get or set the ipcomp(4) level.

-  

-  
If this option is enabled on a SOCK_STREAM,
-      SOCK_DGRAM, or a SOCK_RAW
-      socket, one can bind(2) to any address, even one not
-      bound to any available network interface in the system. This functionality
-      (in conjunction with special firewall rules) can be used for implementing
-      a transparent proxy. The
-      KAUTH_REQ_NETWORK_BIND_ANYADDR privilege is needed
-      to set this option.

-

-
The IPV6_PKTINFO,
-    IPV6_HOPLIMIT, IPV6_HOPOPTS,
-    IPV6_DSTOPTS, and IPV6_RTHDR
-    options will return ancillary data along with payload contents in subsequent
-    recvmsg(2) calls with cmsg_level set
-    to IPPROTO_IPV6 and cmsg_type
-    set to respective option name value (e.g.,
-    IPV6_HOPTLIMIT). These options may also be used
-    directly as ancillary cmsg_type values in
-    sendmsg(2) to set options on the packet being transmitted
-    by the call. The cmsg_level value must be
-    IPPROTO_IPV6. For these options, the ancillary data
-    object value format is the same as the value returned as explained for each
-    when received with recvmsg(2).

-
Note that using sendmsg(2) to specify options on
-    particular packets works only on UDP and raw sockets. To manipulate header
-    options for packets on TCP sockets, only the socket options may be used.

-
In some cases, there are multiple APIs defined for manipulating an
-    IPv6 header field. A good example is the outgoing interface for multicast
-    datagrams, which can be set by the IPV6_MULTICAST_IF
-    socket option, through the IPV6_PKTINFO option, and
-    through the sin6_scope_id field of the socket address
-    passed to the sendto(2) system call.

-
Resolving these conflicts is implementation dependent. This
-    implementation determines the value in the following way: options specified
-    by using ancillary data (i.e., sendmsg(2)) are considered
-    first, options specified by using IPV6_PKTOPTIONS to
-    set “sticky” options are considered second, options specified
-    by using the individual, basic, and direct socket options (e.g.,
-    IPV6_UNICAST_HOPS) are considered third, and options
-    specified in the socket address supplied to sendto(2) are
-    the last choice.

-

-

-

-
IPv6 multicasting is supported only on
-    AF_INET6 sockets of type
-    SOCK_DGRAM and SOCK_RAW, and
-    only on networks where the interface driver supports multicasting. Socket
-    options (see above) that manipulate membership of multicast groups and other
-    multicast options include IPV6_MULTICAST_IF,
-    IPV6_MULTICAST_HOPS,
-    IPV6_MULTICAST_LOOP,
-    IPV6_LEAVE_GROUP, and
-    IPV6_JOIN_GROUP.

-

-

-

-
Raw IPv6 sockets are connectionless and are normally used with the
-    sendto(2) and recvfrom(2) calls,
-    although the connect(2) call may be used to fix the
-    destination address for future outgoing packets so that
-    send(2) may instead be used and the
-    bind(2) call may be used to fix the source address for
-    future outgoing packets instead of having the kernel choose a source
-    address.

-
By using connect(2) or
-    bind(2), raw socket input is constrained to only packets
-    with their source address matching the socket destination address if
-    connect(2) was used and to packets with their destination
-    address matching the socket source address if bind(2) was
-    used.

-
If the proto argument to
-    socket(2) is zero, the default protocol
-    (IPPROTO_RAW) is used for outgoing packets. For
-    incoming packets, protocols recognized by kernel are
-     passed to the
-    application socket (e.g., tcp(4) and
-    udp(4)) except for some ICMPv6 messages. The ICMPv6
-    messages not passed to raw sockets include echo, timestamp, and address mask
-    requests. If proto is non-zero, only packets with this
-    protocol will be passed to the socket.

-
IPv6 fragments are also not passed to application sockets until
-    they have been reassembled. If reception of all packets is desired,
-    link-level access (such as bpf(4)) must be used
-  instead.

-
Outgoing packets automatically have an IPv6 header prepended to
-    them (based on the destination address and the protocol number the socket
-    was created with). Incoming packets are received by an application without
-    the IPv6 header or any extension headers.

-
Outgoing packets will be fragmented automatically by the kernel if
-    they are too large. Incoming packets will be reassembled before being sent
-    to the raw socket, so packet fragments or fragment headers will never be
-    seen on a raw socket.

-

-

-

-

-
The following determines the hop limit on the next packet
-    received:

-

-
struct iovec iov[2];
-u_char buf[BUFSIZ];
-struct cmsghdr *cm;
-struct msghdr m;
-int found, optval;
-u_char data[2048];
-
-/* Create socket. */
-
-(void)memset(&m, 0, sizeof(m));
-(void)memset(&iov, 0, sizeof(iov));
-
-iov[0].iov_base = data;		/* buffer for packet payload */
-iov[0].iov_len = sizeof(data);	/* expected packet length */
-
-m.msg_name = &from;		/* sockaddr_in6 of peer */
-m.msg_namelen = sizeof(from);
-m.msg_iov = iov;
-m.msg_iovlen = 1;
-m.msg_control = buf;	/* buffer for control messages */
-m.msg_controllen = sizeof(buf);
-
-/*
- * Enable the hop limit value from received packets to be
- * returned along with the payload.
- */
-optval = 1;
-if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &optval,
-    sizeof(optval)) == -1)
-	err(1, "setsockopt");
-
-found = 0;
-while (!found) {
-	if (recvmsg(s, &m, 0) == -1)
-		err(1, "recvmsg");
-	for (cm = CMSG_FIRSTHDR(&m); cm != NULL;
-	     cm = CMSG_NXTHDR(&m, cm)) {
-		if (cm->cmsg_level == IPPROTO_IPV6 &&
-		    cm->cmsg_type == IPV6_HOPLIMIT &&
-		    cm->cmsg_len == CMSG_LEN(sizeof(int))) {
-			found = 1;
-			(void)printf("hop limit: %d\n",
-			    *(int *)CMSG_DATA(cm));
-			break;
-		}
-	}
-}

-

-

-

-

-
A socket operation may fail with one of the following errors
-    returned:

-

-  
[EISCONN]

-  
when trying to establish a connection on a socket which already has one or
-      when trying to send a datagram with the destination address specified and
-      the socket is already connected.

-  
[ENOTCONN]

-  
when trying to send a datagram, but no destination address is specified,
-      and the socket hasn't been connected.

-  
[ENOBUFS]

-  
when the system runs out of memory for an internal data structure.

-  
[EADDRNOTAVAIL]

-  
when an attempt is made to create a socket with a network address for
-      which no network interface exists.

-  
[EACCES]

-  
when an attempt is made to create a raw IPv6 socket by a non-privileged
-      process.

-

-
The following errors specific to IPv6 may occur when setting or
-    getting header options:

-

-  
[EINVAL]

-  
An unknown socket option name was given.

-  
[EINVAL]

-  
An ancillary data object was improperly formed.

-

-

-

-

-
getsockopt(2), recv(2),
-    send(2), setsockopt(2),
-    socket(2), CMSG_DATA(3),
-    if_nametoindex(3), bpf(4),
-    icmp6(4), inet6(4),
-    netintro(4), tcp(4),
-    udp(4)

-
W. Stevens and
-    M. Thomas, Advanced Sockets API
-    for IPv6, RFC 2292,
-    February 1998.

-
S. Deering and
-    R. Hinden, Internet Protocol,
-    Version 6 (IPv6) Specification, RFC 2460,
-    December 1998.

-
R. Gilligan,
-    S. Thomson, J. Bound, and
-    W. Stevens, Basic Socket
-    Interface Extensions for IPv6, RFC 2553,
-    March 1999.

-
W. Stevens,
-    B. Fenner, and A. Rudoff,
-    UNIX Network Programming, third edition.

-

-

-

-
Most of the socket options are defined in RFC 2292 or RFC 2553.
-    The IPV6_V6ONLY socket option is defined in RFC
-    3542. The IPV6_PORTRANGE socket option and the
-    conflict resolution rule are not defined in the RFCs and should be
-    considered implementation dependent.

-

-

-
-  
-    
-    
-  
-
September 4, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/ipgphy.4 4.html b/static/netbsd/man4/ipgphy.4 4.html
deleted file mode 100644
index 31ea759c..00000000
--- a/static/netbsd/man4/ipgphy.4 4.html	
+++ /dev/null
@@ -1,35 +0,0 @@
-
-  
-    
-    
-    
-  
-
IPGPHY(4)Device Drivers ManualIPGPHY(4)

-

-

-

-
ipgphy — IC Plus
-    IP1000A/IP1001 10/100/Gigabit Ethernet PHY

-

-

-

-
ipgphy* at mii?

-

-

-

-
The ipgphy driver supports the IC Plus
-    IP1000A/IP1001 10/100/Gigabit Ethernet PHY interface.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
October 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/ipmi.4 4.html b/static/netbsd/man4/ipmi.4 4.html
deleted file mode 100644
index bce6bc50..00000000
--- a/static/netbsd/man4/ipmi.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
IPMI(4)Device Drivers ManualIPMI(4)

-

-

-

-
ipmi — Intelligent
-    Platform Management Interface driver

-

-

-

-
ipmi0 at mainbus?

-

-

-

-
The ipmi device driver supports
-    motherboards implementing the Intelligent Platform Management Interface
-    version 1.5 or 2.0, and exports sensors and the watchdog through the
-    envsys(4) interface.

-

-

-

-
The ipmi driver is able to send events to
-    powerd(8) when a sensor's state has changed. Intrusion
-    sensors will send a critical event when state is not ok.
-    Power Supply sensors will send a critical event when the
-    Power Supply unit is not installed and warning-over when
-    the Power Supply unit is installed but not powered on. Fan, temperature and
-    voltage sensors will send
-    
-    or
-    
-    when the value is very critical, or warning-over or
-    
-    if it's in a warning alert.

-

-

-

-
envsys(4), envstat(8),
-    powerd(8), wdogctl(8)

-

-

-

-
The ipmi driver first appeared in
-    OpenBSD 3.9 and was then ported to
-    NetBSD 4.0.

-

-

-

-
The ipmi driver was originally written by
-    Jordan Hargrave and was ported to
-    NetBSD by Manuel Bouyer
-    ⟨bouyer@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
September 8, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/ipsec.4 3.html b/static/netbsd/man4/ipsec.4 3.html
deleted file mode 100644
index 87059d19..00000000
--- a/static/netbsd/man4/ipsec.4 3.html	
+++ /dev/null
@@ -1,350 +0,0 @@
-
-  
-    
-    
-    
-  
-
IPSEC(4)Device Drivers ManualIPSEC(4)

-

-

-

-
ipsec — IP
-    security protocol

-

-

-

-
options IPSEC
-  

-  options IPSEC_DEBUG

-

-

-

-
This manual page describes the IPsec protocol. For the network
-    device driver please see ipsecif(4).

-
ipsec is a security protocol in the
-    Internet Protocol (IP) layer. ipsec is defined for
-    both IPv4 and IPv6 (inet(4) and
-    inet6(4)). ipsec consists of three
-    sub-protocols:

-

-  
 (ESP)

-  
protects IP payloads from wire-tapping (interception) by encrypting them
-      with secret key cryptography algorithms.

-  
 (AH)

-  
guarantees the integrity of IP packets and protects them from intermediate
-      alteration or impersonation, by attaching cryptographic checksums computed
-      by one-way hash functions.

-  
 (IPComp)

-  
increases the communication performance by compressing the datagrams.

-

-
ipsec has two operation modes:

-

-  

-  
is for protecting peer-to-peer communication between end nodes.

-  

-  
includes IP-in-IP encapsulation operation and is designed for security
-      gateways, as in Virtual Private Network (VPN) configurations.

-

-

-

-
ipsec is controlled by two engines in the
-    kernel: one for key management and one for policy.

-
The key management engine can be accessed from userland by using
-    PF_KEY sockets. The PF_KEY
-    socket API is defined in RFC2367.

-
The policy engine can be controlled through the
-    PF_KEY API, setsockopt(2)
-    operations, and the sysctl(3) interface. The kernel
-    implements an extended version of the PF_KEY
-    interface and allows you to define IPsec policy like per-packet filters.
-    setsockopt(2) is used to define per-socket behavior, and
-    sysctl(3) is used to define host-wide default
-  behavior.

-
The kernel does not implement dynamic encryption key exchange
-    protocols like IKE (Internet Key Exchange). That should be done in userland
-    (usually as a daemon), using the APIs described above.

-

-

-

-
The kernel implements experimental policy management code. You can
-    manage the IPsec policy in two ways. One is to configure per-socket policy
-    using setsockopt(2). The other is to configure kernel
-    packet filter-based policy using the PF_KEY
-    interface, via setkey(8). In both cases, IPsec policy must
-    be specified with syntax described in
-  ipsec_set_policy(3).

-
With setsockopt(2), you can define IPsec policy
-    on a per-socket basis. You can enforce particular IPsec policy on packets
-    that go through a particular socket.

-
With setkey(8) you can define IPsec policy for
-    packets using a form of packet filtering rules. See
-    setkey(8) for details.

-
In the latter case,
-    “default” policy is allowed for use
-    with setkey(8). By configuring policy to
-    default, you can refer to system-wide
-    sysctl(8) variables for default settings. The following
-    variables are available. 1 means
-    “use”, and 2
-    means “require” in the syntax.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
net.inet.ipsec.esp_trans_deflevintegeryes
net.inet.ipsec.esp_net_deflevintegeryes
net.inet.ipsec.ah_trans_deflevintegeryes
net.inet.ipsec.ah_net_deflevintegeryes
net.inet6.ipsec6.esp_trans_deflevintegeryes
net.inet6.ipsec6.esp_net_deflevintegeryes
net.inet6.ipsec6.ah_trans_deflevintegeryes
net.inet6.ipsec6.ah_net_deflevintegeryes

-
If the kernel finds no matching policy, the system-wide default
-    value is applied. System-wide defaults are specified by the following
-    sysctl(8) variables. 0 means
-    “discard” which asks the kernel to
-    drop the packet. 1 means
-    “none”.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
net.inet.ipsec.def_policyintegeryes
net.inet6.ipsec6.def_policyintegeryes

-

-

-

-
The following variables are accessible via
-    sysctl(8), for tweaking kernel IPsec behavior:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
net.inet.ipsec.ah_cleartosintegeryes
net.inet.ipsec.ah_offsetmaskintegeryes
net.inet.ipsec.crypto_supportintegeryes
net.inet.ipsec.dfbitintegeryes
net.inet.ipsec.ecnintegeryes
net.inet.ipsec.debugintegeryes
net.inet6.ipsec6.ecnintegeryes
net.inet6.ipsec6.debugintegeryes

-
The variables are interpreted as follows:

-

-  

-  
If set to non-zero, the kernel clears the type-of-service field in the
-      IPv4 header during AH authentication data computation. The variable is for
-      tweaking AH behavior to interoperate with devices that implement RFC1826
-      AH. It should be set to non-zero (clear the type-of-service field) for
-      RFC2402 conformance.

-  

-  
During AH authentication data computation, the kernel will include a 16
-      bit fragment offset field (including flag bits) in the IPv4 header, after
-      computing logical AND with the variable. The variable is for tweaking AH
-      behavior to interoperate with devices that implement RFC1826 AH. It should
-      be set to zero (clear the fragment offset field during computation) for
-      RFC2402 conformance.

-  

-  
This variable configures the kernel behavior for selecting encryption
-      drivers. If set to > 0, the kernel will select a hardware encryption
-      driver first. If set to < 0, the kernel will select a software
-      encryption driver first. If set to 0, the kernel will select either a
-      hardware or software driver.

-  

-  
This variable configures the kernel behavior on IPv4 IPsec tunnel
-      encapsulation. If set to 0, the DF bit on the outer IPv4 header will be
-      cleared. 1 means that the outer DF bit is set from the inner DF bit. 2
-      means that the DF bit is copied from the inner header to the outer. The
-      variable is supplied to conform to RFC2401 chapter 6.1.

-  

-  
If set to non-zero, IPv4 IPsec tunnel encapsulation/decapsulation behavior
-      will be friendly to ECN (explicit congestion notification), as documented
-      in draft-ietf-ipsec-ecn-02.txt.
-      gif(4) talks more about the behavior.

-  

-  
If set to non-zero, debug messages will be generated via
-      syslog(3).

-

-
Variables under the net.inet6.ipsec6 tree
-    have similar meanings to their net.inet.ipsec
-    counterparts.

-

-

-

-
The current IPsec implementation, formerly called Fast IPsec, uses
-    the opencrypto(9) subsystem to carry out cryptographic
-    operations. This means, in particular, that cryptographic hardware devices
-    are employed whenever possible to optimize the performance of
-  sub-protocols.

-
System configuration requires the opencrypto(9)
-    subsystem. When the Fast IPsec protocols are configured for use, all
-    protocols are included in the system. To selectively enable/disable
-    protocols, use sysctl(8).

-

-

-

-

-
The ipsec protocol works like a plug-in to
-    inet(4) and inet6(4) protocols.
-    Therefore, ipsec supports most of the protocols
-    defined upon those IP-layer protocols. Some of the protocols, like
-    icmp(4) or icmp6(4), may behave
-    differently with ipsec. This is because
-    ipsec can prevent icmp(4) or
-    icmp6(4) routines from looking into IP payload.

-

-

-

-
ioctl(2), socket(2),
-    ipsec_set_policy(3), icmp6(4),
-    intro(4), ip6(4),
-    ipsecif(4), racoon(8),
-    setkey(8), sysctl(8)

-

-

-

-
Daniel L. McDonald,
-    Craig Metz, and Bao G.
-    Phan, PF_KEY Key Management API, Version 2,
-    RFC, 2367.

-

-

-

-
The protocols draw heavily on the OpenBSD
-    implementation of the IPsec protocols. The policy management code is derived
-    from the KAME implementation found in their IPsec protocols. The Fast IPsec
-    protocols are based on code which appeared in FreeBSD
-    4.7. The NetBSD version is a close copy of
-    the FreeBSD original, and first appeared in
-    NetBSD 2.0.

-
Support for IPv6 and IPcomp protocols has been added in
-    NetBSD 4.0.

-
Support for Network Address Translator Traversal as described in
-    RFCs 3947 and 3948 has been added in NetBSD 5.0.

-
Since NetBSD 6.0, the IPsec implementation
-    formerly known as Fast IPsec is used.

-

-

-

-
IPsec support is subject to change as the IPsec protocols
-  develop.

-
There is no single standard for policy engine API, so the policy
-    engine API described herein is just for the version introduced by KAME.

-
AH and tunnel mode encapsulation may not work as you might expect.
-    If you configure inbound “require” policy against AH tunnel or
-    any IPsec encapsulating policy with AH (like
-    “esp/tunnel/A-B/use
-    ah/transport/A-B/require”), tunneled packets will be rejected.
-    This is because we enforce policy check on inner packet on reception, and AH
-    authenticates encapsulating (outer) packet, not the encapsulated (inner)
-    packet (so for the receiving kernel there's no sign of authenticity). The
-    issue will be solved when we revamp our policy engine to keep all the packet
-    decapsulation history.

-
Under certain conditions, truncated results may be raised from the
-    kernel against SADB_DUMP and
-    SADB_SPDDUMP operations on
-    PF_KEY sockets. This occurs if there are too many
-    database entries in the kernel and socket buffer for the
-    PF_KEY socket is insufficient. If you manipulate
-    many IPsec key/policy database entries, increase the size of socket buffer
-    or use sysctl(8) interface.

-
Certain legacy authentication algorithms are not supported because
-    of issues with the opencrypto(9) subsystem.

-

-

-
-  
-    
-    
-  
-
June 13, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/ipsecif.4 3.html b/static/netbsd/man4/ipsecif.4 3.html
deleted file mode 100644
index 1282ca44..00000000
--- a/static/netbsd/man4/ipsecif.4 3.html	
+++ /dev/null
@@ -1,142 +0,0 @@
-
-  
-    
-    
-    
-  
-
IPSECIF(4)Device Drivers ManualIPSECIF(4)

-

-

-

-
ipsecif — IPsec
-    interface

-

-

-

-
pseudo-device ipsecif

-

-

-

-
The ipsecif interface is targeted for
-    route-based VPNs. It can tunnel IPv4 and IPv6 traffic over either IPv4 or
-    IPv6 and secure it with ESP.

-
ipsecif interfaces are dynamically created
-    and destroyed with the ifconfig(8)
-    create and destroy
-    subcommands. The administrator must configure
-    ipsecif tunnel endpoint addresses. These addresses
-    will be used for the outer IP header of ESP packets. The administrator also
-    configures the protocol and addresses for the inner IP header with the
-    ifconfig(8) inet or
-    inet6 subcommands, and modify the routing table to
-    route the packets through the ipsecif interface.

-
The packet processing is similar to gif(4) over
-    ipsec(4) transport mode, however the security policy
-    management is different. gif(4) over
-    ipsec(4) transport mode expects userland programs to
-    manage their security policies. In contrast, ipsecif
-    manages its security policies by itself: when the administrator sets up an
-    ipsecif tunnel source and destination address pair,
-    the related security policies are created automatically in the kernel. They
-    are automatically deleted when the tunnel is destroyed.

-
It also means that ipsecif ensures that
-    both the in and out security policy pairs exist, that is,
-    ipsecif avoids the trouble caused when only one of
-    the in and out security policy pair exists.

-
There are four security policies generated by
-    ipsecif: one in and out pair for IPv4 and IPv6 each.
-    These security policies are equivalent to the following
-    ipsec.conf(5) configuration where src and dst are IP
-    addresses specified to the tunnel:

-

-
spdadd "src" "dst" ipv4 -P out ipsec esp/transport//unique;
-spdadd "dst" "src" ipv4 -P in ipsec esp/transport//unique;
-spdadd "src" "dst" ipv6 -P out ipsec esp/transport//unique;
-spdadd "dst" "src" ipv6 -P in ipsec esp/transport//unique;

-

-
The ipsecif configuration will fail if
-    such security policies already exist, and vice versa.

-
The related security associations can be established by an IKE
-    daemon such as racoon(8). They can also be manipulated
-    manually by setkey(8) with the -u
-    option which sets a security policy's unique id.

-
Some ifconfig(8) parameters change the behaviour
-    of ipsecif. link0 can enable NAT-Traversal, link1
-    can enable ECN friendly mode like gif(4), and link2 can
-    enable forwarding inner IPv6 packets. Only link2 is set by default. If you
-    use only IPv4 packets as inner packets, you would want to do

-

-
ifconfig ipsec0 -link2

-

-
to reduce security associations for IPv6 packets.

-

-

-

-
Configuration example:

-

-
Out IP addr = 172.16.100.1            Out IP addr = 172.16.200.1
-wm0 = 192.168.0.1/24                        wm0 = 192.168.0.2/24
-wm1 = 10.100.0.1/24                          wm1 = 10.200.0.1/24
-
-+------------+                                    +------------+
-|  NetBSD_A  |                                    |  NetBSD_B  |
-|------------|                                    |------------|
-|  [ipsec0] - - - - - - - - (tunnel) - - - - - - - - [ipsec0]  |
-|          [wm0]------------- ... --------------[wm0]          |
-|            |                                    |            |
-+---[wm1]----+                                    +----[wm1]---+
-      |                                                  |
-      |                                                  |
-+------------+                                    +------------+
-|   Host_X   |                                    |   Host_Y   |
-+------------+                                    +------------+

-

-
Host_X and Host_Y will be able to communicate via an IPv4 IPsec
-    tunnel.

-
On NetBSD_A:

-

-
# ifconfig wm0 inet 192.168.0.1/24
-# ifconfig ipsec0 create
-# ifconfig ipsec0 tunnel 192.168.0.1 192.168.0.2
-# ifconfig ipsec0 inet 172.16.100.1/32 172.16.200.1
-start IKE daemon or set security associations manually.
-# ifconfig wm1 inet 10.100.0.1/24
-# route add 10.200.0.1 172.16.100.1

-

-
On NetBSD_B:

-

-
# ifconfig wm0 inet 192.168.0.2/24
-# ifconfig ipsec0 create
-# ifconfig ipsec0 tunnel 192.168.0.2 192.168.0.1
-# ifconfig ipsec0 inet 172.16.200.1/32 172.16.100.1
-start IKE daemon or set security associations manually.
-# ifconfig wm1 inet 10.200.0.1/24
-# route add 10.100.0.1 172.16.200.1

-

-

-

-

-
gif(4), inet(4),
-    inet6(4), ipsec(4),
-    ifconfig(8), racoon(8),
-    setkey(8)

-

-

-

-
The ipsecif device first appeared in
-    NetBSD 8.0.

-

-

-

-
Currently, the ipsecif interface supports
-    the ESP protocol only. ipsecif supports default port
-    number (4500) only for NAT-Traversal.

-

-

-
-  
-    
-    
-  
-
January 25, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/ipw.4 4.html b/static/netbsd/man4/ipw.4 4.html
deleted file mode 100644
index f13792fa..00000000
--- a/static/netbsd/man4/ipw.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
IPW(4)Device Drivers ManualIPW(4)

-

-

-

-
ipw — Intel
-    PRO/Wireless 2100 IEEE 802.11 driver

-

-

-

-
ipw* at pci? dev ? function ?

-

-

-

-
The ipw driver provides support for the
-    Intel PRO/Wireless 2100 MiniPCI network adapter.

-
The Intel firmware requires acceptance of the End User License
-    Agreement. The full license text can be found in
-    /libdata/firmware/if_ipw/LICENSE. The license is agreed to by setting the
-    sysctl variable hw.ipw.accept_eula to 1.

-
By default, the ipw driver configures the
-    adapter for BSS operation (aka infrastructure mode). This mode requires the
-    use of an access point.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
Join an existing BSS network (i.e.: connect to an access
-  point):

-

-
ifconfig ipw0 inet 192.168.0.20
-  netmask 0xffffff00

-
Join a specific BSS network with network name
-    “my_net”:

-

-
ifconfig ipw0 inet 192.168.0.20
-  netmask 0xffffff00 nwid my_net

-
Join a specific BSS network with 64 bits WEP encryption:

-

-
ifconfig ipw0 inet 192.168.0.20 netmask 0xffffff00 nwid my_net \
-        nwkey 0x1234567890

-

-
Join a specific BSS network with 128bits WEP encryption:

-

-
ifconfig ipw0 inet 192.168.0.20 netmask 0xffffff00 nwid my_net \
-        nwkey 0x01020304050607080910111213

-

-

-

-

-

-  
ipw%d: device timeout

-  
The driver will reset the hardware. This should not happen.

-

-

-

-

-
an(4), awi(4),
-    pci(4), wi(4),
-    ifconfig(8), ipwctl(8)

-
The IPW Web Page,
-    http://damien.bergamini.free.fr/ipw/.

-

-

-

-
The ipw driver and this man page were
-    written by Damien Bergamini
-    <damien.bergamini@free.fr>.

-

-

-
-  
-    
-    
-  
-
November 7, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/irframe.4 4.html b/static/netbsd/man4/irframe.4 4.html
deleted file mode 100644
index d75bae59..00000000
--- a/static/netbsd/man4/irframe.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
IRFRAME(4)Device Drivers ManualIRFRAME(4)

-

-

-

-
irframe — IrDA
-    frame level driver

-

-

-

-
irframe* at oboe?
-  

-  irframe* at udsir?
-  

-  irframe* at uirda?
-  

-  irframe* at ustir?
-  

-  pseudo-device irframetty

-

-  

-  #include <dev/irdaio.h>

-

-

-

-
The irframe driver provides support for
-    IrDA frame level transmission. It does not contain the IrDA protocol stack
-    per se, but the stack can be built on top of the
-    irframe driver.

-
Access to frames is via the read(2) and
-    write(2) system calls. Each write constitutes one frame,
-    and each read yields one frame. The poll(2) system call
-    can be used to check for availability of frames. There are also a number of
-    ioctl(2) calls to manipulate the device:

-

-  

-  
Reset the parameters set by IRDA_SET_PARAMS.

-  

-    (struct irda_params)

-  
Set the speed, extra beginning of frame bytes, and maximum frame
-    size.

-  

-    (int)

-  
Get the set of allowable speeds.

-  

-    (int)

-  
Get the set of allowable turn around times.

-

-

-

-

-
cir(4), irframetty(4),
-    oboe(4), uirda(4),
-    ustir(4)

-
comms/birda package

-

-

-

-
The irframe driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
December 2, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/irframetty.4 4.html b/static/netbsd/man4/irframetty.4 4.html
deleted file mode 100644
index 608be92a..00000000
--- a/static/netbsd/man4/irframetty.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
IRFRAMETTY(4)Device Drivers ManualIRFRAMETTY(4)

-

-

-

-
irframetty — IrDA
-    frame over serial line driver

-

-

-

-
pseudo-device irframetty

-

-  

-  #include <dev/irdaio.h>

-

-

-

-
The irframetty driver provides a
-    tty(4) line discipline to send and receive IrDA frames
-    over a serial line via an IrDA dongle.

-
Access to the frames is via the irframe(4)
-    driver.

-
Different dongles require different handling. The connected dongle
-    type can be set with ioctl(2) calls:

-

-  

-    (int)

-  
Set the dongle type. See the include file for possible dongles.

-  

-    (int)

-  
Get the dongle type.

-  

-    (int)

-  
Get the number of the irframe(4) device that must be
-      used to access the frames.

-

-

-

-

-
irframe(4), irdaattach(8)

-

-

-

-
The irframetty driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
December 3, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/irmce.4 4.html b/static/netbsd/man4/irmce.4 4.html
deleted file mode 100644
index 1880d1cb..00000000
--- a/static/netbsd/man4/irmce.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
IRMCE(4)Device Drivers ManualIRMCE(4)

-

-

-

-
irmce — driver for
-    Windows Media Center IR receivers/transceivers

-

-

-

-
irmce* at uhub ? port ?
-  

-  cir* at irmce?

-

-

-

-
The irmce driver provides support for
-    Windows Media Center Infrared (IR) transceivers/receivers.

-
Supported cards include:

-
    
-  
  • SMK eHome Infrared Transceiver
    • 
-

-

-

-

-
usb(4)

-

-

-

-
The irmce device driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The irmce driver was written by
-    Jared D. McNeill
-    ⟨jmcneill@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
August 13, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/isa.4 4.html b/static/netbsd/man4/isa.4 4.html
deleted file mode 100644
index 175a571d..00000000
--- a/static/netbsd/man4/isa.4 4.html	
+++ /dev/null
@@ -1,255 +0,0 @@
-
-  
-    
-    
-    
-  
-
ISA(4)Device Drivers ManualISA(4)

-

-

-

-
isa — introduction
-    to machine-independent ISA bus support and drivers

-

-

-

-
Attachments are machine-dependent and depend on the bus topology
-    and ISA bus interface of your system. See intro(4) for
-    your system for details.

-

-

-

-
NetBSD includes a machine-independent ISA
-    bus subsystem and several machine-independent ISA device drivers.

-
Your system may support additional ISA devices. Drivers for ISA
-    devices not listed here are machine-dependent. Consult your system's
-    intro(4) for additional information.

-

-

-

-
NetBSD includes machine-independent ISA
-    drivers, sorted by device type and driver name:

-

-

-

-

-  
adv(4)

-  
Advansys SCSI interfaces.

-  
aha(4)

-  
Adaptec AHA-154x family (154xA, 154xB, 154xC, and 154xCF) and the BusLogic
-      BT54x SCSI interfaces.

-  
ahc(4)

-  
Adaptec 29xx, 39xx, and other AIC-7xxx-based SCSI interfaces.

-  
aic(4)

-  
Adaptec AIC-6260 and Adaptec AIC-6360 based SCSI interfaces, including the
-      Adaptec 152x, SoundBlaster SCSI interfaces, and a variety of
-    compatibles.

-  
bha(4)

-  
BusLogic BT-445 SCSI interfaces.

-  
dpt(4)

-  
DPT SmartCache/SmartRAID III and IV SCSI interfaces.

-  
esp(4)

-  
NCR 53C9x, Emulex ESP406, and Qlogic FAS408 SCSI interfaces.

-  
nca(4)

-  
NCR-5380/NCR-53C400

-  
sea(4)

-  
Seagate/Future Domain SCSI cards. ST01/02, Future Domain TMC-885, and
-      Future Domain TMC-950.

-  
uha(4)

-  
Ultrastor 14f SCSI interfaces.

-  
wds(4)

-  
WD-7000 family of bus-mastering SCSI interfaces.

-

-

-

-

-

-

-

-  
mcd(4)

-  
Mitsumi CD-ROM drives.

-  
wdc(4)

-  
Standard Western Digital type hard drive controllers: MFM, RLL, ESDI, and
-      IDE/ATAPI.

-  
wt(4)

-  
Wangtek and compatible QIC-02 and QIC-36 tape drives.

-

-

-

-

-

-

-

-  
ast(4)

-  
Multi-port serial communications card first made by AST.

-  
boca(4)

-  
Boca BB100[48] and BB2016 multiplexing serial communications cards.

-  
com(4)

-  
NS8250-, NS16450-, and NS16550-based serial ports.

-  
cy(4)

-  
Cyclades Cyclom-4Y, -8Y, and -16Y asynchronous serial communications
-      cards.

-  
ioat(4)

-  
BOCA Research IOAT66 serial interfaces.

-  
lpt(4)

-  
Standard ISA parallel port interface.

-  
rtfps(4)

-  
IBM RT four-port serial interfaces.

-  
tcom(4)

-  
Byte Runner Technologies TC-400 and TC-800 series serial interfaces.

-

-

-

-

-

-

-

-  
ai(4)

-  
AT&T StarLan Ethernet interfaces.

-  
ate(4)

-  
Allied Telesis AT1700 series and RE2000 series Ethernet interfaces.

-  
cs(4)

-  
Cirrus Logic Crystal CS8900 Ethernet interfaces.

-  
ec(4)

-  
3Com EtherLink II (3c503) Ethernet interfaces.

-  
ef(4)

-  
3Com EtherLink II (3c507) Ethernet interfaces.

-  
eg(4)

-  
3Com EtherLink Plus (3c505) Ethernet interfaces.

-  
el(4)

-  
3Com EtherLink (3c501) Ethernet interfaces.

-  
ep(4)

-  
3Com EtherLink III (3c509) Ethernet interfaces.

-  
fmv(4)

-  
Fujitsu FMV-181 and FMV-182 interfaces.

-  
ix(4)

-  
Intel EtherExpress/16 Ethernet interfaces.

-  
iy(4)

-  
Intel i82595-based Ethernet interfaces, including the EtherExpress
-    Pro/10.

-  
lc(4)

-  
DEC EtherWORKS III Ethernet interfaces (DE203, DE204, and DE205).

-  
le(4)

-  
Ethernet interfaces based on the AMD LANCE chip, including BICC Isolan,
-      Novell NE2100, Digital DEPCA, and PCnet-ISA.

-  
ne(4)

-  
Novel NE2000 and compatible Ethernet interfaces.

-  
ntwoc(4)

-  
SDL Communications Riscom/N2 synchronous serial interfaces.

-  
sm(4)

-  
SMC91C9x-based Ethernet interfaces.

-  
we(4)

-  
Western Digital/SMC 80x3, SMC Elite Ultra, and SMC EtherEZ Ethernet
-      interfaces.

-

-

-

-

-

-

-

-  
aria(4)

-  
Sierra's Aria based sound cards.

-  
cms(4)

-  
Creative Music System.

-  
ess(4)

-  
ESS Technology AudioDrive 1788-, 1888-, 1887-, and 888-based sound
-    cards.

-  
gus(4)

-  
Gravis Ultrasound sound cards.

-  
mpu(4)

-  
Roland MPU401 (and compatible) MIDI UARTs.

-  
opl(4)

-  
Yamaha OPL2 and OPL3 FM MIDI synthesizers.

-  
pas(4)

-  
ProAudio Spectrum sound cards.

-  
sb(4)

-  
SoundBlaster, SoundBlaster 16, and SoundBlaster Pro sound cards.

-  
wss(4)

-  
Windows Sound System-compatible sound cards based on the AD1848 and
-      compatible chips.

-

-

-

-

-

-

-

-  
az(4)

-  
Aztech/PackardBell radio card.

-  
lm(4)

-  
National Semiconductor LM78, LM79 and compatible hardware monitors.

-  
nct(4)

-  
Nuvoton NCT5104D SuperIO.

-  
pcdisplay(4)

-  
PC display adapters.

-  
pcic(4)

-  
PCI PCMCIA controllers, including the Cirrus Logic GD6729.

-  
pckbc(4)

-  
PC keyboard controllers.

-  
pcppi(4)

-  
PC control and timer ports.

-  
pms(4)

-  
PS/2 auxiliary port mice (including wheel mice).

-  
rt(4)

-  
AIMS Lab Radiotrack FM radio.

-  
rtii(4)

-  
AIMS Lab Radiotrack II FM radio.

-  
sf2r(4)

-  
SoundForte RadioLink SF16-FMR2 FM radio.

-  
tcic(4)

-  
Databook DB86082, DB86084, DB86184, and DB86072 PCMCIA controllers.

-  
vga(4)

-  
VGA graphics boards.

-  
wbsio(4)

-  
Winbond LPC Super I/O.

-

-

-
Note that some ISA devices also have newer ISA Plug-and-Play
-    variants. These are listed in isapnp(4).

-

-

-

-

-

-  
Stray interrupt on IRQ 7

-  
It means the interrupt controller reported an unmasked interrupt on IRQ 7,
-      but no driver attached to that IRQ `claimed' it.
-    
There are two reasons this can happen:

-    
    
-      
  • In anything other than i386, it would almost always mean that there is
-          a driver attached to the IRQ, but it is the wrong driver.
    • 
-      
  • On i386, there is the more obscure issue of `default IRQ7's. That is,
-          when a device asserts an IRQ, but the IRQ is deasserted after the PIC
-          latches the interrupt and before the CPU acknowledges it, the PIC just
-          flat out lies about which IRQ it was. It is usually due to a
-          suboptimally coded driver.
    • 
-    

-  

-

-

-

-

-
intro(4), isapnp(4),
-    isa(9)

-

-

-

-
The machine-independent ISA subsystem appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
October 25, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/isapnp.4 4.html b/static/netbsd/man4/isapnp.4 4.html
deleted file mode 100644
index a3cc6645..00000000
--- a/static/netbsd/man4/isapnp.4 4.html	
+++ /dev/null
@@ -1,142 +0,0 @@
-
-  
-    
-    
-    
-  
-
ISAPNP(4)Device Drivers ManualISAPNP(4)

-

-

-

-
isapnp —
-    introduction to ISA Plug-and-Play support

-

-

-

-
isapnp0 at isa?

-
An

-

-
-  
-    
-    
-  
-
isapnpbus can be configured for each supported ISA bus.

-

-

-

-
NetBSD provides machine-independent bus
-    support and drivers for ISA Plug-and-Play (isapnp) autoconfiguration of
-    PnP-compatible devices on an ISA bus.

-

-

-

-
NetBSD includes machine-independent ISAPNP
-    drivers, sorted by function and driver name:

-

-

-

-

-  
aha(4)

-  
Adaptec AHA-154[02] SCSI interfaces.

-  
aic(4)

-  
Adaptec AHA-1520B SCSI interfaces.

-

-

-

-

-

-

-

-  
wdc(4)

-  
Standard IDE and ATAPI drive controller.

-

-

-

-

-

-

-

-  
com(4)

-  
8250/16450/16550-compatible ISA PnP serial cards and internal modems.

-

-

-

-

-

-

-

-  
an(4)

-  
Aironet 4500/4800 and Cisco 340 series 802.11 interfaces.

-  
ep(4)

-  
3Com 3c509B EtherLink III Ethernet interface.

-  
le(4)

-  
PCnet-PnP Ethernet interfaces based on the successor to the AMD LANCE
-      chip.

-  
ne(4)

-  
NE2000-compatible Ethernet interfaces.

-

-

-

-

-

-

-

-  
ess(4)

-  
ESS Technology derived PnP sound cards and devices.

-  
guspnp(4)

-  
Gravis Ultrasound PnP sound cards.

-  
sb(4)

-  
SoundBlaster, SoundBlaster 16, and SoundBlaster Pro sound cards.

-  
wss(4)

-  
Windows Sound System compatible cards, e.g., most of the cards with
-      Crystal Semiconductor chips.

-  
ym(4)

-  
Yamaha OPL3-SAx sound cards.

-

-

-

-

-

-

-

-  
pcic(4)

-  
PCI PCMCIA controllers, including the Cirrus Logic GD6729.

-

-

-
ISA Plug-and-Play devices also have alternate ISA drivers with
-    static ISA IO address configuration. These are listed in
-    isa(4). The isapnp bus ignores
-    devices that have already been found and configured as
-    isa(4) devices. The isapnp bus is
-    only effective on machines which lack a PnP BIOS, or on which the PnP BIOS
-    has been disabled. The manual pages for each individual
-    isapnp driver also list the supported front-ends for
-    other buses.

-

-

-

-

-
intro(4), isa(4),
-    isapnp(9)

-

-

-

-
The isapnp driver appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
February 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/ismt.4 4.html b/static/netbsd/man4/ismt.4 4.html
deleted file mode 100644
index 00120ca1..00000000
--- a/static/netbsd/man4/ismt.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
ISMT(4)Device Drivers ManualISMT(4)

-

-

-

-
ismt — Intel
-    Chipset internal SMBus 2.0 controller with DMA

-

-

-

-
ismt* at pci? dev ? function ?
-  

-  iic* at ismt?

-

-

-

-
The ismt driver provides support for the
-    Intel chipset internal SMBus 2.0 host interface with DMA to be used with the
-    iic(4) framework.

-
Supported chipsets:

-

-
    
-  
  • S1200 series.
    • 
-  
  • C2000 series.
    • 
-

-

-

-

-
iic(4), intro(4),
-    pci(4)

-

-

-

-
The ismt driver first appeared in
-    FreeBSD 11.0 and in NetBSD
-    8.0.

-

-

-

-
The ismt driver was written by
-    Jim Harris
-    <jimharris@freebsd.org>
-    for FreeBSD and ported to
-    NetBSD by Masanobu SAITOH
-    <msaitoh@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 5, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/isp.4 4.html b/static/netbsd/man4/isp.4 4.html
deleted file mode 100644
index 90d94951..00000000
--- a/static/netbsd/man4/isp.4 4.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
ISP(4)Device Drivers ManualISP(4)

-

-

-

-
isp — Qlogic based
-    SCSI and FibreChannel SCSI Host Adapters

-

-

-

-
isp* at pci? dev? function? (PCI)
-  

-  isp* at sbus? slot ? offset ? (SBus)
-  

-  scsibus* at isp?

-

-

-

-
This driver provides access to SCSI or FibreChannel devices.

-
SCSI features include support for Ultra SCSI and wide mode
-    transactions for SCSI, and LVD (for the ISP1080 and ISP1280),

-
Fibre Channel support uses FCP SCSI profile for FibreChannel and
-    uses Class 3 connections only. Support is available for Public and Private
-    loops. Command tagging is supported for all (in fact, FibreChannel requires
-    tagging).

-

-

-

-
An optional flags 0x80 appended to the
-    above isp declarations will disable the download of
-    driver firmware, which means you use whatever firmware is running on the
-    card. If no firmware is running on the card, the driver cannot operate the
-    card.

-
An optional flags 0x40 appended to the
-    above isp declarations (can be OR'd in with the
-    other config flags option) will keep the driver from looking at device or
-    bus NVRAM settings (this is in case NVRAM is just wrong and you have the
-    card in a platform where it is inconvenient to change NVRAM settings on the
-    card).

-

-

-

-
Supported cards include:

-

-

-  
ISP1000

-  
SBus Fast Wide, Ultra Fast Wide cards, Single Ended or Differential
-    cards.

-  
PTI SBS440

-  
Performance Technology ISP1000 variants.

-  
ISP1020

-  
Qlogic 1020 Fast Wide and Differential Fast Wide PCI cards.

-  
ISP1040

-  
Qlogic 1040 Ultra Wide and Differential Ultra Wide PCI cards.

-  
PTI SBS450

-  
Performance Technology ISP1040 variants.

-  
Qlogic 1240

-  
Qlogic 1240 Dual Bus Ultra Wide and Differential Ultra Wide PCI
-    cards.

-  
Qlogic 1080

-  
Qlogic 1280 LVD Ultra2 Wide PCI cards.

-  
Qlogic 1280

-  
Qlogic 1280 Dual Bus LVD Ultra2 Wide PCI cards.

-  
Qlogic 2100

-  
Qlogic 2100 and 2100A Copper and Optical Fibre Channel Arbitrated
-    Loop

-  
Qlogic 2102

-  
Qlogic Dual Loop 2100A Optical Fibre Channel Arbitrated Loop PCI
-    cards.

-  
Qlogic 2200

-  
Qlogic 2200 Copper and Optical Fibre Channel Arbitrated Loop PCI
-    cards.

-  
Qlogic 2202

-  
Qlogic 2200 Dual Bus Optical Fibre Channel Arbitrated Loop PCI cards.

-  
Qlogic 2204

-  
Qlogic 2200 Quad Bus Optical Fibre Channel Arbitrated Loop PCI cards.

-  
Qlogic 2300

-  
Qlogic 2300 2-Gigabit Optical Fibre Channel PCI cards.

-  
Qlogic 2312

-  
Qlogic 2300 2-Gigabit Dual Channel Optical Fibre Channel PCI cards.

-  
PTI SBS470

-  
Performance Technology ISP2100 variants.

-  
Antares P-0033

-  
Antares Microsystems ISP2100 variants.

-  
Qlogic 2400

-  
Qlogic 2400 4-Gigabit Optical Fibre Channel PCI cards.

-  
Qlogic 2500

-  
Qlogic 2500 8-Gigabit Optical Fibre Channel PCI cards.

-

-

-

-

-

-
cd(4), intro(4),
-    scsi(4), sd(4),
-  st(4)

-

-

-

-
The isp driver was written by
-    Matthew Jacob for NASA/Ames Research Center.

-

-

-

-
The driver currently ignores some NVRAM settings.

-
The driver currently doesn't do error recovery for timed out
-    commands very gracefully.

-
Sometimes, when booting, the driver gets stuck waiting for the
-    Fibre Channel firmware to tell it that the loop port database is ready. In
-    this case you'll see an announcement that the loop state has a value of 0x1.
-    To unwedge the system, unplug and replug the fibre channel connection, or
-    otherwise cause a LIP (Loop Initialization Primitive sequence) - this will
-    kick the firmware into getting unstuck.

-

-

-
-  
-    
-    
-  
-
June 24, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/isv.4 3.html b/static/netbsd/man4/isv.4 3.html
deleted file mode 100644
index a252aa01..00000000
--- a/static/netbsd/man4/isv.4 3.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
ISV(4)Device Drivers ManualISV(4)

-

-

-

-
isv — IDEC
-    Supervision/16 image capture board

-

-

-

-
isv0 at isa? port 0x2f0
-  

-  isv0 at isa? port 0x2e0
-  

-  isv0 at isa? port 0x3f0
-  

-  isv0 at isa? port 0x3e0

-

-

-

-
isv is a driver for the IDEC
-    Supervision/16, an image capture board that plugs into a 16-bit ISA bus. The
-    IDEC Supervision/16 digitizes an NTSC television signal, storing a 512 x
-    480-pixel, 8-bit grayscale image in its 256kB dynamic RAM array every 1/30th
-    of a second. The host reads frames from the DRAM using 122881 16-bit I/O
-    reads. Reading frames from the Supervision/16 is quite slow: after the host
-    reads a 16-bit word from the DRAM, the Supervision/16 state machine takes
-    approximately 0.5 microseconds to get ready for the next read.
-    Theoretically, a frame rate of approximately 10 frames per second is
-    possible. isv achieves a frame rate of approximately
-    6 frames per second.

-

-

-

-
Programming the Supervision/16
-    Image Capture Board, IDEC,
-    circa 1991.

-

-

-

-
The isv device first appeared in
-    NetBSD 5.0.

-

-

-

-
The isv driver was written by
-    David Young
-    <dyoung@NetBSD.org>.

-

-

-

-
Synchronizing with the hardware and reading frames from it is very
-    CPU-intensive.

-
isv will not detect the capture board if
-    it is not attached to an active video source. To force
-    NetBSD to detect the capture board at any time,
-    re-scan the ISA bus using, e.g., drvctl
-    -r isa0.

-

-

-
-  
-    
-    
-  
-
April 1, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/iteide.4 4.html b/static/netbsd/man4/iteide.4 4.html
deleted file mode 100644
index 160463ab..00000000
--- a/static/netbsd/man4/iteide.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
ITEIDE(4)Device Drivers ManualITEIDE(4)

-

-

-

-
iteide —
-    Integrated Technology Express IDE disk controllers
-    driver

-

-

-

-
iteide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The iteide driver supports the IT8211 and
-    IT8212 IDE controllers which are found on some Gigabyte motherboards (as
-    “GigaRAID”) and some PCI cards. This driver provides the
-    interface with the hardware for the ata(4) driver.

-
The optional RAID functionality of the IT8211 and IT8212 is not
-    supported and is explicitly disabled by the iteide
-    driver. The controller will act like a regular IDE controller with no RAID
-    functionality.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The iteide driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>
-    and ported to NetBSD by Grant
-    Beattie
-    <grant@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 30, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/itesio.4 4.html b/static/netbsd/man4/itesio.4 4.html
deleted file mode 100644
index 52079a2d..00000000
--- a/static/netbsd/man4/itesio.4 4.html	
+++ /dev/null
@@ -1,145 +0,0 @@
-
-  
-    
-    
-    
-  
-
ITESIO(4)Device Drivers ManualITESIO(4)

-

-

-

-
itesio — ITE
-    IT87xxF Super I/O driver

-

-

-

-
itesio0 at isa? port 0x2e
-  

-  itesio1 at isa? port 0x4e

-

-

-

-
The itesio driver provides support for the
-    Environment Controller and the Watchdog Timer on the IT87xxF Super I/Os, and
-    may be used to monitor hardware sensors or setting up a watchdog timeout
-    value for the system.

-
The itesio driver has 15 sensors:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uKCPU Temp
uKSystem Temp
uKAux Temp
uV DCVcore A
uV DCVcore B
uV DC+3.3V
uV DC+5V
uV DC+12V
uV DC-12V
uV DC-5V
uV DCSTANDBY
uV DCVBAT
RPMCPU Fan
RPMSystem Fan
RPMAux Fan

-
The itesio Watchdog Timer is configurable
-    via the wdogctl(8) utility and has a resolution between 1
-    and 65535 seconds. The Watchdog Timer is not supported on the IT8705 Super
-    I/O.

-

-

-

-
envsys(4), envstat(8),
-    wdogctl(8)

-

-

-

-
The itesio driver first appeared in
-    OpenBSD 3.4 and was then ported to
-    NetBSD 4.0.

-

-

-

-
The itesio driver was written by
-    Julien Bordet
-    <zejames@greyhats.org>
-    and Juan Romero Pardines
-    <xtraeme@netbsd.org>.

-

-

-

-
Interrupt support is unimplemented.

-

-

-
-  
-    
-    
-  
-
April 2, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/iwi.4 4.html b/static/netbsd/man4/iwi.4 4.html
deleted file mode 100644
index c884a3f3..00000000
--- a/static/netbsd/man4/iwi.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
IWI(4)Device Drivers ManualIWI(4)

-

-

-

-
iwi — Intel
-    PRO/Wireless 2200BG/2915ABG IEEE 802.11 driver

-

-

-

-
iwi* at pci? dev ? function ?

-

-

-

-
The iwi driver provides support for
-    Intel(R) PRO/Wireless 2200BG and 2915ABG MiniPCI network adapters.

-
By default, the iwi driver configures the
-    adapter for BSS operation (aka infrastructure mode). This mode requires the
-    use of an access point.

-
For more information on configuring this device, see
-    ifconfig(8).

-
The Intel firmware requires acceptance of the End User License
-    Agreement. The full license text can be found in
-    /libdata/firmware/if_iwi/LICENSE.ipw2200-fw. The
-    license is agreed to by setting the sysctl variable
-    hw.iwi.accept_eula to 1.

-

-

-

-
Join an existing BSS network (i.e.: connect to an access
-  point):

-

-
ifconfig iwi0 inet 192.168.0.20
-  netmask 0xffffff00

-
Join a specific BSS network with network name
-    “my_net”:

-

-
ifconfig iwi0 inet 192.168.0.20
-  netmask 0xffffff00 nwid my_net

-
Join a specific BSS network with 64 bits WEP encryption:

-

-
ifconfig iwi0 inet 192.168.0.20 netmask 0xffffff00 nwid my_net \
-        nwkey 0x1234567890

-

-
Join a specific BSS network with 128bits WEP encryption:

-

-
ifconfig iwi0 inet 192.168.0.20 netmask 0xffffff00 nwid my_net \
-        nwkey 0x01020304050607080910111213

-

-

-

-

-

-  
iwi%d: device timeout

-  
The driver will reset the hardware. This should not happen.

-

-

-

-

-
an(4), awi(4),
-    ipw(4), pci(4), wi(4),
-    ifconfig(8), iwictl(8),
-    firmload(9)

-
The IWI Web Page,
-    http://damien.bergamini.free.fr/ipw/.

-

-

-

-
The iwi driver and this man page were
-    written by Damien Bergamini
-    <damien.bergamini@free.fr>.

-

-

-
-  
-    
-    
-  
-
February 5, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/iwm.4 4.html b/static/netbsd/man4/iwm.4 4.html
deleted file mode 100644
index 6a80c5dd..00000000
--- a/static/netbsd/man4/iwm.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
IWM(4)Device Drivers ManualIWM(4)

-

-

-

-
iwm — Intel
-    Wireless AC and Centrino Wireless IEEE 802.11 wireless network
-  driver

-

-

-

-
iwm* at pci? dev ? function ?

-

-

-

-
The iwm driver provides support for Intel
-    Wireless 3160, 3165, 3168, 4165, 7260, 7265, 8260, and 8265 PCIe Mini Card
-    Dual Band network adapters.

-
By default, the iwm driver configures the
-    adapter for BSS operation (aka infrastructure mode). This mode requires the
-    use of an access point.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
ifmedia(4), iwn(4),
-    ifconfig.if(5), ifconfig(8)

-

-

-

-
The iwm driver was written by
-    Antti Kantee
-    <pooka@NetBSD.org>.

-

-

-

-
The iwm driver only supports the
-    802.11a/b/g capabilities offered by the adapters. Additional work is
-    required in ieee80211(9) before 802.11n/802.11ac modes can
-    be supported.

-

-

-
-  
-    
-    
-  
-
November 10, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/iwn.4 3.html b/static/netbsd/man4/iwn.4 3.html
deleted file mode 100644
index 99f3dcf7..00000000
--- a/static/netbsd/man4/iwn.4 3.html	
+++ /dev/null
@@ -1,220 +0,0 @@
-
-  
-    
-    
-    
-  
-
IWN(4)Device Drivers ManualIWN(4)

-

-

-

-
iwn — Intel WiFi
-    Link and Centrino IEEE 802.11 wireless network driver

-

-

-

-
iwn* at pci? dev ? function ?

-

-

-

-
The iwn driver provides support for Intel
-    Wireless WiFi Link 4965/5000/1000 and Centrino Wireless-N 1000/2000/6000
-    Series PCIe Mini Card network adapters.

-
The Intel Wireless WiFi Link 4965AGN (codenamed Kedron) is a PCIe
-    Mini Card network adapter that operates in the 2GHz and 5GHz spectra. It has
-    2 transmit paths and 3 receiver paths (2T3R). It is part of the
-    fourth-generation Centrino platform (codenamed Santa Rosa).

-
The Intel WiFi Link 5000 series is a family of wireless network
-    adapters that operate in the 2GHz and 5GHz spectra. They are part of the
-    fifth-generation Centrino platform (codenamed Montevina). These adapters are
-    available in both PCIe Mini Card (model code ending by MMW) and PCIe Half
-    Mini Card (model code ending by HMW) form factor. The
-    iwn driver provides support for the 5100 (codenamed
-    Shirley Peak 1x2), 5150 (codenamed Echo Peak-V), 5300 (codenamed Shirley
-    Peak 3x3) and 5350 (codenamed Echo Peak-P) adapters. The 5100 and 5150
-    adapters have 1 transmit path and 2 receiver paths (1T2R). The 5300 and 5350
-    adapters have 3 transmit paths and 3 receiver paths (3T3R).

-
The Intel WiFi Link 1000 (codenamed Condor Peak) is a single-chip
-    wireless network adapter that operates in the 2GHz spectrum. It is part of
-    the sixth-generation Centrino platform (codenamed Calpella). It is available
-    in both PCIe Mini Card (model code ending by MMW) and PCIe Half Mini Card
-    (model code ending by HMW) form factor. It has 1 transmit path and 2
-    receiver paths (1T2R).

-
The Intel Centrino Ultimate-N 6300 (codenamed Puma Peak 3x3) is a
-    single-chip wireless network adapter that operates in the 2GHz and 5GHz
-    spectra. It has 3 transmit paths and 3 receiver paths (3T3R). The Intel
-    Centrino Advanced-N 6250 (codenamed Kilmer Peak) is a combo WiFi/WiMAX
-    network adapter that operates in the 2GHz and 5GHz spectra. It has 2
-    transmit paths and 2 receiver paths (2T2R). The Intel Centrino Advanced-N
-    6200 (codenamed Puma Peak 2x2) is a wireless network adapter that operates
-    in the 2GHz and 5GHz spectra. It has 2 transmit paths and 2 receiver paths
-    (2T2R). These adapters are part of the sixth-generation Centrino platform
-    (codenamed Calpella).

-
The Intel Centrino Wireless-N 2230 (codename Jackson Peak) and
-    Intel Centrino Wireless-N 2200 (codename Marble Peak) are wireless network
-    adapters that operate in the 2GHz spectrum. These adapters have 2 transmit
-    paths and 2 receiver paths (2T2R). The Intel Centrino Wireless-N 135 and
-    Intel Centrino Wireless-N 105 (codename Canyon Peak) also operate in the
-    2GHz spectrum. These adapters have 1 transmit path and 1 receiver path
-    (1T1R).

-
By default, the iwn driver configures the
-    adapter for BSS operation (aka infrastructure mode). This mode requires the
-    use of an access point.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
The iwn driver can be configured at
-    runtime with ifconfig(8) using the following
-  parameters:

-

-  

-    bssid

-  
Set the desired BSSID.

-  

-  
Unset the desired BSSID. The interface will automatically select a BSSID
-      in this mode, which is the default.

-  

-    n

-  
Set the channel (radio frequency) to be used by the driver based on the
-      given channel ID n.

-  

-  
Unset the desired channel to be used by the driver. The driver will
-      automatically select a channel in this mode, which is the default.

-  

-    media

-  
The iwn driver supports the following
-      media types:
-    

-    

-      

-      
Enable autoselection of the media type and options.

-    

-  

-  

-    opts

-  
The iwn driver supports the following media
-      options:
-    

-    

-      

-      
Select monitor mode.

-    

-  

-  

-    opts

-  
Disable the specified media options on the driver and return it to the
-      default mode of operation (BSS).

-  

-    mode

-  
The iwn driver supports the following modes:
-    

-    

-      

-      
Force 802.11a operation.

-      

-      
Force 802.11b operation.

-      

-      
Force 802.11g operation.

-    

-  

-  

-    id

-  
Set the network ID. The id can either be any text
-      string up to 32 characters in length, or a series of hexadecimal digits up
-      to 64 digits. An empty id string allows the
-      interface to connect to any available access points. By default the
-      iwn driver uses an empty string. Note that network
-      ID is synonymous with Extended Service Set ID (ESSID).

-  

-    key

-  
Enable WEP encryption using the specified key. The
-      key can either be a string, a series of hexadecimal
-      digits (preceded by ‘0x’), or a set of keys of the form
-      “n:k1,k2,k3,k4”, where ‘n’ specifies which of
-      the keys will be used for transmitted packets, and the four keys,
-      “k1” through “k4”, are configured as WEP keys.
-      If a set of keys is specified, a comma (‘,’) within the key
-      must be escaped with a backslash. Note that if multiple keys are used,
-      their order must be the same within the network.
-      iwn is capable of using both 40-bit (5 characters
-      or 10 hexadecimal digits) or 104-bit (13 characters or 26 hexadecimal
-      digits) keys.

-  

-  
Disable WEP encryption. This is the default mode of operation.

-

-

-

-

-
The following ifconfig.if(5), example configures
-    iwn0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
dhcp NONE NONE NONE nwkey 0x1deadbeef1 chan 11

-

-
Configure iwn0 for WEP, using hex key
-    “0x1deadbeef1”:

-

-
# ifconfig iwn0 nwkey 0x1deadbeef1

-

-
Return iwn0 to its default settings:

-

-
# ifconfig iwn0 -bssid -chan media autoselect \
-	nwid "" -nwkey

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig iwn0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
iwn%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-  
iwn%d: fatal firmware error

-  
For some reason, the firmware crashed. The driver will reset the hardware.
-      This should not happen.

-  
iwn%d: radio is disabled by hardware switch

-  
The radio transmitter is off and thus no packet can go out. The driver
-      will reset the hardware. Make sure the laptop radio switch is on.

-  
iwn%d: error %d, could not read firmware %s

-  
For some reason, the driver was unable to read the firmware image from the
-      filesystem. The file might be missing or corrupted.

-  
iwn%d: could not get firmware handle %s

-  

-  
iwn%d: could not read firmware

-  
The driver was unable to find the file with the proper firmware image. It
-      should be located in
-    /libdata/firmware/if_iwn.

-  
iwn%d: firmware file too short: %d bytes

-  
The firmware image is corrupted and can't be loaded into the adapter.

-  
iwn%d: could not load firmware

-  
An attempt to load the firmware into the adapter failed. The driver will
-      reset the hardware.

-

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), ifconfig.if(5),
-    ifconfig(8)

-

-

-

-
The iwn driver and this man page were
-    written by Damien Bergamini
-    <damien.bergamini@free.fr>.

-

-

-
-  
-    
-    
-  
-
October 30, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/ix.4 4.html b/static/netbsd/man4/ix.4 4.html
deleted file mode 100644
index 2cadd6f7..00000000
--- a/static/netbsd/man4/ix.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
IX(4)Device Drivers ManualIX(4)

-

-

-

-
ix — Intel
-    EtherExpress/16 Ethernet ISA bus NIC driver

-

-

-

-
ix0 at isa? port 0x300 irq 10

-

-

-

-
The ix device driver supports the
-    EtherExpress/16 card, and might support other ISA bus cards using the same
-    chip. The EtherExpress/16 Ethernet adapter is based on the Intel 82586
-    Ethernet chip.

-

-

-

-
ai(4), ef(4),
-    elmc(4), ifmedia(4),
-    intro(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
June 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/ixg.4 4.html b/static/netbsd/man4/ixg.4 4.html
deleted file mode 100644
index c3290d92..00000000
--- a/static/netbsd/man4/ixg.4 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
IXG(4)Device Drivers ManualIXG(4)

-

-

-

-
ixg — Intel(R)
-    10Gb Ethernet driver

-

-

-

-
ixg* at pci? dev ? function ?

-

-

-

-
The ixg driver provides support for PCI
-    10Gb Ethernet adapters based on the Intel(R) 82598EB, 82599, X540 and X550
-    Ethernet Controllers. The driver supports Jumbo Frames, TCP Segmentation
-    Offload (TSO).

-
For questions related to hardware requirements, refer to the
-    documentation supplied with your Intel 10GbE adapter. All hardware
-    requirements listed apply to use with NetBSD.

-
Support for Jumbo Frames is provided via the interface MTU
-    setting. Selecting an MTU larger than 1500 bytes with the
-    ifconfig(8) utility configures the adapter to receive and
-    transmit Jumbo Frames. On NetBSD, the maximum MTU
-    size for Jumbo Frames is 9000 bytes.

-
This driver version supports VLANs. For information on enabling
-    VLANs, see ifconfig(8).

-

-

-

-

-  
ixg%d: Unable to allocate bus resource: memory

-  
A fatal initialization error has occurred.

-  
ixg%d: Unable to allocate bus resource: interrupt

-  
A fatal initialization error has occurred.

-  
ixg%d: watchdog timeout -- resetting

-  
The device has stopped responding to the network, or there is a problem
-      with the network connection (cable).

-

-

-

-

-
For general information and support, go to the Intel support
-    website at:
-    http://www.intel.com/support/.

-

-

-

-
arp(4), ixv(4),
-    netintro(4), vlan(4),
-    ifconfig(8)

-

-

-

-
The ixg device driver comes from
-    FreeBSD, where it is called
-    ixgbe. It first appeared in NetBSD
-    6.0.

-

-

-

-
The ixg driver was written by
-    Intel Corporation
-    <freebsdnic@mailbox.intel.com>.
-    It was imported from FreeBSD into
-    NetBSD by David Young
-    <dyoung@NetBSD.org>.

-

-

-

-
The hardware supports a maximum MTU of 16114 bytes, but the
-    NetBSD port of the driver supports only 9000
-  bytes.

-

-

-
-  
-    
-    
-  
-
August 25, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/ixl.4 4.html b/static/netbsd/man4/ixl.4 4.html
deleted file mode 100644
index 804ca064..00000000
--- a/static/netbsd/man4/ixl.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
IXL(4)Device Drivers ManualIXL(4)

-

-

-

-
ixl — Intel
-    Ethernet 700 Series driver

-

-

-

-
ixl* at pci? dev ? function ?

-

-

-

-
The ixl driver supports Intel Ethernet 700
-    series controllers based on the Intel X710, XXV710, XL710, and X722 Ethernet
-    chipsets.

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The ixl driver comes from
-    OpenBSD. It first appeared in
-    NetBSD 10.0.

-

-

-

-
The ixl driver was written by
-    David Gwynne
-    <dlg@openbsd.org> and
-    Jonathan Matthew
-    <jmatthew@openbsd.org>.
-    It was imported from OpenBSD into
-    NetBSD by Shoichi Yamaguchi
-    <yamaguchi@NetBSD.org>.

-

-

-

-
The VLAN hardware filter doesn't work while the interface is in
-    promiscuous mode. If registering a VLAN tag fails due to lack of resources,
-    the interface doesn't send and receive packets containing the tag.

-

-

-
-  
-    
-    
-  
-
December 10, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/ixpide.4 4.html b/static/netbsd/man4/ixpide.4 4.html
deleted file mode 100644
index 939981e1..00000000
--- a/static/netbsd/man4/ixpide.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
IXPIDE(4)Device Drivers ManualIXPIDE(4)

-

-

-

-
ixpide — PCI IDE
-    disk controllers driver

-

-

-

-
ixpide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The ixpide driver supports the ATI
-    Technologies IXP IDE controller, and provides the interface with the
-    hardware for the ata(4) driver.

-
The 0x0002 flag forces the ixpide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
The supported IDE controllers are

-
    
-  
  • ATI SB200
    • 
-  
  • ATI SB300
    • 
-  
  • ATI SB400, Parallel ATA
    • 
-  
  • ATI SB400, Serial ATA
    • 
-  
  • ATI SB700, Serial and Parallel ATA
    • 
-

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
Some SB700 controllers can hang under load when Native IDE mode is
-    selected in the system BIOS, but work fine in AHCI mode.

-

-

-
-  
-    
-    
-  
-
October 16, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/ixv.4 4.html b/static/netbsd/man4/ixv.4 4.html
deleted file mode 100644
index 0c31c9a1..00000000
--- a/static/netbsd/man4/ixv.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
IXV(4)Device Drivers ManualIXV(4)

-

-

-

-
ixv — Intel 10
-    Gigabit Ethernet virtual function

-

-

-

-
ixv* at pci? dev ? function ?

-

-

-

-
The ixv driver supports Intel 10 Gigabit
-    Ethernet virtual function that 82599 and newer chips support. It can be used
-    on a NetBSD guest that the host supports SR-IOV.

-

-

-

-
arp(4), ixg(4),
-    netintro(4), vlan(4),
-    ifconfig(8)

-

-

-

-
The ixv device driver comes from
-    FreeBSD. It first appeared in
-    NetBSD 8.0.

-

-

-

-
The ixv driver was written by
-    Intel Corporation
-    <freebsdnic@mailbox.intel.com>.

-

-

-

-
The following event counters are not cleared by
-    SIOCZIFDATA because the corresponding registers are
-    read only and not cleared on read:

-

-
    
-  
  • Good Packets Received
    • 
-  
  • Good Octets Received
    • 
-  
  • Multicast Packets Received
    • 
-  
  • Good Packets Transmitted
    • 
-  
  • Good Octets Transmitted
    • 
-

-

-

-
-  
-    
-    
-  
-
August 25, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/iy.4 4.html b/static/netbsd/man4/iy.4 4.html
deleted file mode 100644
index f49b2b87..00000000
--- a/static/netbsd/man4/iy.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
IY(4)Device Drivers ManualIY(4)

-

-

-

-
iy — Intel
-    EtherExpress PRO/10 Ethernet driver (Intel i82595)

-

-

-

-
iy0 at isa? port {port} irq ?

-

-

-

-
The iy device driver supports the
-    EtherExpress PRO/10 card, and might support other ISA cards using the same
-    chip.

-

-

-

-
The different models of the supported boards come with some subset
-    of RJ-45, BNC and AUI connectors. Supported media include:

-

-

-  
AUI/DIX

-  
Standard 15 pin connector

-  
10Base2

-  
BNC, also known as thin-net

-  
10BaseT

-  
UTP, also known as twisted pair

-

-

-
The default port to use is the port the card autodetects at
-    ifconfig up time. To choose an alternative port, an
-    explicit medium can be specified to ifconfig(8) or in your
-    ifconfig.iy? file.

-

-

-

-
The EtherExpress PRO card has no jumpers to set the address. Intel
-    supplies software to set the address of the card in software. You have to
-    hardwire this address in your kernel configuration file.

-

-

-

-
ed(4), eg(4),
-    el(4), ep(4),
-    intro(4), ix(4),
-    le(4), ifconfig(8)

-

-

-

-
are great. There's so many to choose from.

-

-

-
-  
-    
-    
-  
-
May 22, 1996NetBSD 10.1

diff --git a/static/netbsd/man4/jme.4 3.html b/static/netbsd/man4/jme.4 3.html
deleted file mode 100644
index 0a1b34e7..00000000
--- a/static/netbsd/man4/jme.4 3.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
JME(4)Device Drivers ManualJME(4)

-

-

-

-
jme — JMicron
-    Technologies JMC250 Gigabit Ethernet and JMC260 Fast Ethernet controller
-    driver

-

-

-

-
jme* at pci? dev ? function ?

-
Configuration of PHYs is necessary. See
-  mii(4).

-

-

-

-
The jme device driver supports network
-    adapters based on the JMicron Technologies JMC250 Gigabit Ethernet and
-    JMC260 Fast Ethernet chips. The following features are supported:

-

-
IPv4 transmit/receive IP/TCP/UDP checksum offload
-IPv6 transmit TCP/UDP checksum offload
-IPv4 and IPv6 TCP segmentation offload
-VLAN tag insertion/removal
-Interrupt coalescing
-10/100/1000Mbps operation in full-duplex mode
-10/100Mbps operation in half-duplex mode
-Jumbo frames (up to 9022 bytes)

-

-
Due to hardware limitation checksums and TCP segmentation offload
-    can't be enabled if the configured MTU is larger than 4000 bytes.

-
Interrupt coalescing can be controlled on a per-adapter basis
-    through the following sysctls:

-

-  

-  
jme receive interrupt moderation timer, in microseconds (defaults to
-    100)

-  

-  
jme receive interrupt moderation packet counter (defaults to 128)

-  

-  
jme transmit interrupt moderation timer, in microseconds (defaults to
-    100)

-  

-  
jme transmit interrupt moderation packet counter (defaults to 128)

-

-

-

-

-
ifmedia(4), jmphy(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The jme device driver first appeared in
-    NetBSD 5.0.

-

-

-

-
Hardware bugs prevent support of IPv6 receive TCP/UDP checksum
-    offload in the JMC250 rev A2, and is disabled in the driver. This should be
-    revisited when a newer hardware revision is available.

-

-

-
-  
-    
-    
-  
-
October 30, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/jmide.4 4.html b/static/netbsd/man4/jmide.4 4.html
deleted file mode 100644
index d885c74e..00000000
--- a/static/netbsd/man4/jmide.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
JMIDE(4)Device Drivers ManualJMIDE(4)

-

-

-

-
jmide — JMicron
-    Technology JMB36x PCIe to SATA II/PATA controller driver

-

-

-

-
jmide* at pci? dev ? function ? flags
-    0x0000
-  

-  ahcisata* at jmide?

-

-

-

-
The jmide driver supports the JMicron
-    Technology JMB36x IDE controllers.

-
These PCI-e controllers exist in different flavors (1 or 2 PATA
-    Ultra/133 ports and/or 1 or 2 SATA-II ports), and are highly flexible. The
-    SATA ports can be attached to the integrated AHCI controller or attached to
-    the PCI IDE channels in PATA emulation, in either single-drive emulation on
-    each PCI IDE channels, or in master/slave emulation on one of the PCI IDE
-    channels.

-
When enabled, the AHCI controller can either be on the PCI
-    function 0 or function 2. The PCI IDE controller can also be on either PCI
-    function, and can share the PCI function with AHCI. The
-    jmide driver supports both the AHCI controller and
-    PCI IDE controller in various configurations.

-

-

-

-
ahcisata(4), ata(4),
-    atapi(4), intro(4),
-    pci(4), pciide(4),
-    wd(4), wdc(4)

-

-

-

-
The jmide driver was written by
-    Manuel Bouyer.

-

-

-
-  
-    
-    
-  
-
July 2, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/jmphy.4 4.html b/static/netbsd/man4/jmphy.4 4.html
deleted file mode 100644
index c8b29b79..00000000
--- a/static/netbsd/man4/jmphy.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
JMPHY(4)Device Drivers ManualJMPHY(4)

-

-

-

-
jmphy — JMicron
-    JMP202/JMP211 10/100/Gigabit Ethernet PHY

-

-

-

-
jmphy* at mii?

-

-

-

-
The jmphy driver supports the JMicron
-    JMP202 10/100 and JMP211 10/100/Gigabit Ethernet PHYs.

-

-

-

-
ifmedia(4), intro(4),
-    jme(4), mii(4),
-    ifconfig(8)

-

-

-

-
The jmphy device driver first appeared in
-    OpenBSD 4.5 and NetBSD
-  9.0.

-

-

-

-
The jmphy driver was written by
-    Pyun YongHyeon for FreeBSD
-    and ported to OpenBSD by Jonathan
-    Gray
-    <jsg@openbsd.org> and
-    then ported to NetBSD by Masanobu
-    SAITOH.

-

-

-

-
It the media is set to gigabit speed, it may not link up or take a
-    very long time to set the link up. It depends on the link partner.

-

-

-
-  
-    
-    
-  
-
October 30, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/joy.4 4.html b/static/netbsd/man4/joy.4 4.html
deleted file mode 100644
index 890d96a2..00000000
--- a/static/netbsd/man4/joy.4 4.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
JOY(4)Device Drivers ManualJOY(4)

-

-

-

-
joy — game adapter
-    driver

-

-

-

-
joy* at acpi?
-  

-  joy* at eap?
-  

-  joy* at eso?
-  

-  joy0 at isa? port 0x201
-  

-  joy* at isapnp?
-  

-  joy* at ofisa?
-  

-  joy* at pci?
-  

-  joy* at pnpbios? index ?

-

-

-

-
This driver provides access to the game adapter. The lower bit in
-    the minor device number selects the joystick: 0 is the first joystick and 1
-    is the second.

-
The game control adapter allows up to two joysticks to be attached
-    to the system. The adapter plus the driver convert the present resistive
-    value to a relative joystick position. On receipt of an output signal, four
-    timing circuits are started. By determining the time required for the
-    circuit to time-out (a function of the resistance), the paddle position can
-    be determined. The adapter could be used as a general purpose I/O card with
-    four analog (resistive) inputs plus four digital input points.

-
Applications may call ioctl(2) on a game adapter
-    driver file descriptor to set and get the offsets of the two potentiometers
-    and the maximum time-out value for the circuit. The
-    ioctl(2) commands are listed in
-    <machine/joystick.h> and
-    currently are:

-

-

-  

-  
Sets the maximum time-out for the adapter.

-  

-  
Returns the current maximum time-out.

-  

-  
Sets an offset on X value.

-  

-  
Returns the current X offset.

-  

-  
Sets an offset on Y value.

-  

-  
Returns the current Y offset.

-

-
All these commands take an integer parameter.

-
read(2) on the file descriptor returns a
-    joystick structure:

-

-
struct joystick {
-	int x;
-	int y;
-	int b1;
-	int b2;
-};

-

-
The fields have the following functions:

-

-  
x

-  
current X coordinate of the joystick (or position of paddle 1)

-  
y

-  
current Y coordinate of the joystick (or position of paddle 2)

-  
b1

-  
current state of button 1

-  
b2

-  
current state of button 2

-

-
The b1 and b2 fields in struct joystick are set to 1 if the
-    corresponding button is down, 0 otherwise.

-
The x and y coordinates are supposed to be between 0 and 255 for a
-    good joystick and a good adapter. Unfortunately, because of the hardware
-    hack that is used to measure the position (by measuring the time needed to
-    discharge an RC circuit made from the joystick's potentiometer and a
-    capacitor on the adapter), calibration is needed to determine exactly what
-    values are returned for a specific joystick/adapter combination. Incorrect
-    hardware can yield negative or values greater than 255.

-
A typical calibration procedure uses the values returned at lower
-    left, center and upper right positions of the joystick to compute the
-    relative position.

-
This calibration is not part of the driver.

-

-

-

-

-  
/dev/joy0

-  
first joystick

-  
/dev/joy1

-  
second joystick

-

-

-

-

-
acpi(4), eap(4),
-    eso(4), isa(4),
-    isapnp(4), ofisa(4),
-    pci(4), pnpbios(4)

-

-

-

-
Jean-Marc Zucconi wrote the FreeBSD
-    driver. Matthieu Herrb ported it to NetBSD and wrote
-    this manual page.

-

-

-
-  
-    
-    
-  
-
July 22, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/kcov.4 3.html b/static/netbsd/man4/kcov.4 3.html
deleted file mode 100644
index 5489cb6a..00000000
--- a/static/netbsd/man4/kcov.4 3.html	
+++ /dev/null
@@ -1,174 +0,0 @@
-
-  
-    
-    
-    
-  
-
KCOV(4)Device Drivers ManualKCOV(4)

-

-

-

-
kcov — kernel code
-    coverage tracing

-

-

-

-
options KCOV

-

-  

-  #include <sys/kcov.h>

-

-

-

-
The kcov driver implements collection of
-    code coverage inside the kernel. It can be enabled on a per thread basis
-    from userland, allowing the kernel program counter to be collected during
-    syscalls triggered by the same thread.

-
The kcov descriptors (KD) are allocated
-    during open(2), and are associated with a file descriptor.
-    A thread can enable the kcov device. When this
-    happens, this thread becomes the owner of the kcov
-    descriptors (KD), and no thread can disable this KD except the owner.

-
A kcov descriptor (KD) is freed when its
-    file descriptor is closed iff the KD is not active on a thread. If it is, we
-    ask the thread to free it when it exits.

-
The collected coverage can be accessed by mapping the device using
-    mmap(2). The buffers are mapped without risk that the
-    kernel frees a buffer still mapped in a process.

-
By default, kcov is not enabled but
-    requires the compile-time configuration makeoptions
-    KCOV options KCOV to be present, see
-    options(4).

-
The following ioctl(2) calls are provided:

-

-  

-    uint64_t *nentries

-  
Allocate a coverage buffer with a capacity of
-      nentries. The buffer can be accessed using
-      mmap(2) whereas the returned pointer must be interpreted
-      as an array of kcov_int_t entries. Note that
-      kcov_int_t is volatile. The first entry contains the number of entries in
-      the array, excluding the first entry.

-  

-    int *mode

-  
Enable code coverage tracing for the current thread. The
-      mode must be one of the following:
-    

-      

-      
No trace selected. This option is useful for testing the
-          kcov device.

-      

-      
Trace the kernel program counter.

-      

-      
Trace comparison instructions and switch statements. For switch
-          statements, the number of traced comparison instructions is equal to
-          the number of switch cases. Each traced comparison instruction is
-          represented by 4 entries in the coverage buffer:
-        
    
-          
  1. A mask where the least significant bit is set if one of the
-              comparison operands is a compile-time constant, which is always
-              true for switch statements. The remaining bits represents the log2
-              size of the operands, ranging from 0 to 3.
    2. 
-          
  2. First comparison operand. For switch statements, this operand
-              corresponds to the case value.
    3. 
-          
  3. Second comparison operand. For switch statements, this operand
-              corresponds to the value passed to switch.
    4. 
-          
  4. Kernel program counter where the comparison instruction took
-              place.
    5. 
-        

-        
In this mode, the first entry in the coverage buffer
-            reflects the number of traced comparison instructions. Thus, the
-            effective number of entries in the coverage buffer is given by
-            multiplying the first entry by 4.

-      

-    

-  

-  

-    void

-  
Disable code coverage tracing for the current thread.

-

-

-

-

-

-  
/dev/kcov

-  
Default device node.

-

-

-

-

-
In the following example, the read(2) syscall is
-    traced and the coverage displayed, which in turn can be passed to
-    addr2line(1) in order to translate the kernel program
-    counter into the file name and line number it corresponds to.

-

-
#include <err.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-
-#include <sys/ioccom.h>
-#include <sys/ioctl.h>
-#include <sys/mman.h>
-
-#include <sys/kcov.h>
-
-int
-main(void)
-{
-	kcov_int_t *cover, i, n;
-	uint64_t size = 1024 * 100;
-	int fd;
-	int mode;
-
-	fd = open("/dev/kcov", O_RDWR);
-	if (fd == -1)
-		err(1, "open");
-	if (ioctl(fd, KCOV_IOC_SETBUFSIZE, &size) == -1)
-		err(1, "ioctl: KCOV_IOC_SETBUFSIZE");
-	cover = mmap(NULL, size * KCOV_ENTRY_SIZE,
-	    PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
-	if (cover == MAP_FAILED)
-		err(1, "mmap");
-	mode = KCOV_MODE_TRACE_PC;
-	if (ioctl(fd, KCOV_IOC_ENABLE, &mode) == -1)
-		err(1, "ioctl: KCOV_IOC_ENABLE");
-	cover[0] = 0;
-	read(-1, NULL, 0); /* syscall paths to be traced */
-	n = cover[0];
-	if (ioctl(fd, KCOV_IOC_DISABLE) == -1)
-		err(1, "ioctl: KCOV_IOC_DISABLE");
-	for (i = 0; i < n; i++)
-		printf("%p\n", (void *)cover[i + 1]);
-	if (munmap(cover, size * KCOV_ENTRY_SIZE) == -1)
-		err(1, "munmap");
-	close(fd);
-
-	return 0;
-}

-

-

-

-

-
options(4)

-

-

-

-
The kcov driver was initially developed in
-    Linux. A driver based on the same concept was then implemented in
-    NetBSD 9.

-

-

-

-
Siddharth Muralee
-    <siddharth.muralee@gmail.com>

-

-

-
-  
-    
-    
-  
-
May 28, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/kloader.4 4.html b/static/netbsd/man4/kloader.4 4.html
deleted file mode 100644
index 7ae215df..00000000
--- a/static/netbsd/man4/kloader.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
KLOADER(4)Device Drivers ManualKLOADER(4)

-

-

-

-
kloader —
-    in-kernel bootloader

-

-

-

-
options KLOADER
-  

-  options
-    KLOADER_KERNEL_PATH="\"/netbsd\""

-

-

-

-
The kloader is the in-kernel bootloader
-    for platforms that do not have a proper firmware.

-
Some platforms supported by NetBSD do not
-    have a firmware that can boot the NetBSD kernel.
-    Examples are game consoles (dreamcast and playstation2 ports), and handhelds
-    (hpcarm, hpcmips, and hpcsh ports). On such platforms the bootloader is
-    usually a host program that runs under the native OS. This means that
-    rebooting NetBSD is a lengthy process of booting
-    into the native OS first, launching the bootloader program, and finally
-    booting NetBSD again. This problem is addressed by
-    kloader, which allows the currently running kernel
-    to serve as a bootloader for the kernel being booted, thus avoiding the
-    burden of booting into the native OS first.

-
When kloader is configured into the
-    kernel, a call to reboot(2) causes the
-    kloader to load the new kernel into memory, and
-    arrange for control to be passed to the new kernel — just like a
-    standalone bootloader does. The new kernel then boots in the ordinary
-    manner.

-

-

-

-
reboot(2), boot(8),
-    reboot(8)

-

-

-

-
kloader first appeared in
-    NetBSD 1.6.

-

-

-

-
kloader ignores
-    howto and bootstr arguments
-    passed to the reboot(2) system call, and reboots the
-    system with the previous boot settings.

-
kloader doesn't support booting compressed
-    kernels.

-
The hpcarm port doesn't support kloader
-    yet.

-

-

-
-  
-    
-    
-  
-
April 3, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/kse.4 4.html b/static/netbsd/man4/kse.4 4.html
deleted file mode 100644
index c165f2c9..00000000
--- a/static/netbsd/man4/kse.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
KSE(4)Device Drivers ManualKSE(4)

-

-

-

-
kse — Micrel
-    8842/8841 PCI Ethernet controller driver

-

-

-

-
kse* at pci? dev ? function ?

-

-

-

-
The kse driver supports Ethernet
-    interfaces based on the Micrel 8842/8841 PCI Ethernet chips. The 8842 has 2
-    Ethernet ports which behave as a managed switch to bridge each other. It
-    works like a T-shape connector of Ethernet data flow in which an Ethernet
-    controller sits at the leg of the T. Frames can flow between the two ports
-    while traffic destined for the 8842 reaches the EMAC. The 8841 is a plain
-    10/100 Ethernet. The kse driver distinguishes and
-    handles them according to the HW model.

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The kse driver was written by
-    Tohru Nishimura.

-

-

-

-
__STRICT_ALIGNMENT case is not written. 8842 media selection keeps
-    “auto” and indicates “up 100baseTX-FX flow” when
-    either of two ports is found link-up. There is no functional provision to
-    see and control the media selection of them this moment. Advanced features
-    like flow volume bound, VLAN tag insertion/removal, QoS DiffServ are not
-    implemented and remain uncontrollable by the kse
-    driver. UDP4CSUM is not very useful since the HW has an implementation error
-    for the case when a large UDP datagram is fragmented into MTU sized
-  frames.

-

-

-
-  
-    
-    
-  
-
July 6, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/ksyms.4 4.html b/static/netbsd/man4/ksyms.4 4.html
deleted file mode 100644
index 4b1b110f..00000000
--- a/static/netbsd/man4/ksyms.4 4.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
KSYMS(4)Device Drivers ManualKSYMS(4)

-

-

-

-
ksyms — kernel
-    symbol table interface

-

-

-

-
pseudo-device ksyms

-

-

-

-
The /dev/ksyms character device provides a
-    read-only interface to the current kernel symbol table. It can be accessed
-    either as a sequential file, where it looks like an executable file but with
-    zero-sized text and data segments, or via ioctl(2).

-
/dev/ksyms represents the symbol table at
-    the time when the device is opened, and may not change until it is
-  closed.

-
The in-kernel symbol manager is designed to be able to handle any
-    type of symbol table. However, only elf(5) symbol tables
-    are currently dealt with.

-

-

-

-
The ioctl(2) command codes below are defined in
-    <sys/ksyms.h>.

-
The (third) argument to the ioctl(2) should be a
-    pointer to the type indicated.

-

-

-  

-    (int)

-  
Returns the total size of the current symbol table. This should be used
-      when allocating a buffer to read in the whole symbol table to memory.

-  

-    (struct ksyms_gvalue)

-  
Returns the value for the given symbol name in a symtab-independent
-      fashion.
-    

-    
struct ksyms_gvalue {
-        const char *kv_name;
-        uint64_t kv_value;
-};

-    

-    
The struct member kv_name should be set
-        to the name of the requested value, and upon return
-        kv_value contains the symbol value.

-  

-  

-    (struct ksyms_gsymbol)

-  
Returns the complete symbol for the given symbol name.
-    

-    
struct ksyms_gsymbol {
-        const char *kg_name;
-        void *kg_sym;
-};

-    

-    
The struct member kg_name should be set
-        to the name of the requested symbol, and the found symbol will be
-        written to the kg_sym address. It is the callers
-        responsibility to ensure that enough space for the symbol is
-      allocated.

-  

-

-

-

-

-

-

-  
/dev/ksyms

-  
 

-

-

-

-

-
ioctl(2), nlist(3),
-    elf(5)

-

-

-

-
A ksyms device exists in many different
-    operating systems. This implementation is modelled in function after Solaris
-    ksyms. This ksyms driver was
-    written by Anders Magnusson for NetBSD.

-
The ksyms driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
July 27, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/kttcp.4 4.html b/static/netbsd/man4/kttcp.4 4.html
deleted file mode 100644
index 5a127a67..00000000
--- a/static/netbsd/man4/kttcp.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
KTTCP(4)Device Drivers ManualKTTCP(4)

-

-

-

-
kttcp — kernel
-    support for testing network throughput

-

-

-

-
pseudo-device kttcp

-

-

-

-
This driver provides kernel support for testing network throughput
-    from the perspective of the kernel. It is similar in spirit to the classic
-    ttcp network benchmark program, the main difference being that with kttcp,
-    the kernel is the source and sink of the data.

-
Testing like this is useful for a few reasons:

-
    
-  
  1. This allows us to know what kind of performance we can expect from network
-      applications that run in the kernel space, such as the NFS server or the
-      NFS client. These applications don't have to move the data to/from
-      userspace, and so benchmark programs which run in userspace don't give us
-      an accurate model.
    2. 
-  
  2. Since data received is just thrown away, the receiver is very fast. This
-      can provide better exercise for the sender at the other end.
    3. 
-  
  3. Since the NetBSD kernel currently uses a
-      run-to-completion scheduling model, kttcp provides a benchmark model where
-      preemption of the benchmark program is not an issue.
    4. 
-

-

-

-

-
pkgsrc/benchmarks/kttcp,
-    pkgsrc/benchmarks/ttcp

-

-

-
-  
-    
-    
-  
-
December 2, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/kue.4 4.html b/static/netbsd/man4/kue.4 4.html
deleted file mode 100644
index 5bdb45ea..00000000
--- a/static/netbsd/man4/kue.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
KUE(4)Device Drivers ManualKUE(4)

-

-

-

-
kue — Kawasaki LSI
-    KL5KUSB101B USB Ethernet driver

-

-

-

-
kue* at uhub?

-

-

-

-
The kue driver supports the following
-    adapters:

-

-

-

-  
3Com 3c19250

-  
 

-  
3Com 3c460 HomeConnect Ethernet USB Adapter

-  
 

-  
Abocom URE450

-  
 

-  
ADS Technologies USB-10BT

-  
 

-  
Aox USB101

-  
 

-  
ATen UC10T

-  
 

-  
Corega EtherUSB

-  
 

-  
D-Link DSB-650

-  
 

-  
Entrega NET-USB-E45

-  
 

-  
I/O Data USB-ET/T

-  
 

-  
Kawasaki USB101

-  
 

-  
LinkSys USB10T

-  
 

-  
Netgear EA101

-  
 

-  
Peracom USB Ethernet Adapter (3 models)

-  
 

-  
SMC 2102USB

-  
 

-  
SMC 2104USB

-  
 

-

-

-

-

-

-
The kue driver provides support for USB
-    Ethernet adapters based on the Kawasaki LSI KL5KLUSB101B chipset.

-
The KL5KLUSB101B supports a 128-entry multicast filter, single
-    perfect filter entry for the station address and promiscuous mode. Packets
-    are received and transmitted over separate USB bulk transfer endpoints.

-
The Kawasaki adapter supports only 10Mbps half-duplex mode, hence
-    there are no ifmedia(4) modes to select.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), netintro(4),
-    usb(4), usbnet(4),
-    ifconfig(8)

-

-

-

-
The kue device driver first appeared in
-    FreeBSD 4.0, and in NetBSD
-    1.5.

-

-

-

-
The kue driver was written by
-    Bill Paul ⟨wpaul@ee.columbia.edu⟩.

-

-

-

-
The kue driver does not accumulate
-    Ethernet collisions statistics because the Kawasaki firmware does not appear
-    to maintain any internal statistics.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/l2tp.4 3.html b/static/netbsd/man4/l2tp.4 3.html
deleted file mode 100644
index c8dd8309..00000000
--- a/static/netbsd/man4/l2tp.4 3.html	
+++ /dev/null
@@ -1,157 +0,0 @@
-
-  
-    
-    
-    
-  
-
L2TP(4)Device Drivers ManualL2TP(4)

-

-

-

-
l2tp — layer two
-    tunneling protocol version 3

-

-

-

-
pseudo-device l2tp

-

-

-

-
The l2tp interface implements version 3 of
-    the Layer Two Tunneling Protocol (L2TPv3). It can tunnel layer 2 protocol
-    traffic over IPv4 or IPv6, as specified in
-  RFC3931.

-
The L2TPv3 protocol is comprised of two types of messages: control
-    messages and data messages. Control messages are used in the establishment,
-    maintenace, and clearing of control connections and sessions. The
-    l2tp interface can send control messages and data
-    messages; furthermore the management of control messages is entrusted to
-    userland daemon. Without a management daemon, the
-    l2tp interface can send data messages using the
-    ifconfig(8) tunnel and
-    session subcommands, or the
-    SIOCSIFPHYADDR and
-    SIOCSL2TPSESSION ioctls. Additionally, it can use
-    cookies specified in RFC3931 by using the
-    ifconfig(8) cookie subcommand, or
-    the SIOCSL2TPCOOKIE ioctl.

-

-

-
Layer 2 frames are prepended with a L2TPv3 header as described by
-    RFC 3931. The resulting L2TPv3 packets will be encapsulated in an outer
-    packet, which may be either an IPv4 or IPv6 packet, with IP protocol number
-    115.

-

-

-

-

-
Configuration example:

-

-
wm0 = 192.168.0.1/24                        wm0 = 192.168.0.2/24
-
-+------------+                                    +------------+
-|  NetBSD_A  |                                    |  NetBSD_B  |
-|------------|                                    |------------|
-|   [l2tp0] - - - - - - - - (tunnel) - - - - - - - - [l2tp0]   |
-|          [wm0]------------- ... --------------[wm0]          |
-|            |                                    |            |
-+---[wm1]----+                                    +----[wm1]---+
-      |                                                  |
-      |                                                  |
-+------------+                                    +------------+
-|   Host_X   |                                    |   Host_Y   |
-+------------+                                    +------------+

-

-

-

-
On NetBSD_A:

-

-
# ifconfig wm0 inet 192.168.0.1/24
-# ifconfig l2tp0 create
-# ifconfig l2tp0 tunnel 192.168.0.1 192.168.0.2
-# ifconfig l2tp0 session 1234 4321
-# ifconfig bridge0 create
-# brconfig bridge0 add wm1
-# brconfig bridge0 add l2tp0
-# ifconfig l2tp0 up
-# ifconfig wm1 up
-# ifconfig bridge0 up

-

-
On NetBSD_B:

-

-
# ifconfig wm0 inet 192.168.0.2/24
-# ifconfig l2tp0 create
-# ifconfig l2tp0 tunnel 192.168.0.2 192.168.0.1
-# ifconfig l2tp0 session 4321 1234
-# ifconfig bridge0 create
-# brconfig bridge0 add wm1
-# brconfig bridge0 add l2tp0
-# ifconfig l2tp0 up
-# ifconfig wm1 up
-# ifconfig bridge0 up

-

-

-

-

-
On NetBSD_A:

-

-
# ifconfig wm0 inet 192.168.0.1/24
-# ifconfig l2tp0 create
-# ifconfig l2tp0 tunnel 192.168.0.1 192.168.0.2
-# ifconfig l2tp0 session 1234 4321
-# ifconfig l2tp0 cookie 4 12345 4 54321
-# ifconfig bridge0 create
-# brconfig bridge0 add wm1
-# brconfig bridge0 add l2tp0
-# ifconfig l2tp0 up
-# ifconfig wm1 up
-# ifconfig bridge0 up

-

-
On NetBSD_B:

-

-
# ifconfig wm0 inet 192.168.0.2/24
-# ifconfig l2tp0 create
-# ifconfig l2tp0 tunnel 192.168.0.2 192.168.0.1
-# ifconfig l2tp0 session 4321 1234
-# ifconfig l2tp0 cookie 4 54321 4 12345
-# ifconfig bridge0 create
-# brconfig bridge0 add wm1
-# brconfig bridge0 add l2tp0
-# ifconfig l2tp0 up
-# ifconfig wm1 up
-# ifconfig bridge0 up

-

-

-

-

-

-
inet(4), inet6(4),
-    ifconfig(8)

-
J. Lau, Ed.,
-    M. Townsley, Ed., and I. Goyret,
-    Ed., Layer Two Tunneling Protocol - Version 3
-    (L2TPv3), RFC 3931,
-    ftp://ftp.ietf.org/rfc/rfc3931.txt,
-    March 2005.

-

-

-

-
The l2tp device first appeared in
-    NetBSD 8.0.

-

-

-

-
Currently, the l2tp interface supports
-    Ethernet frames over IPv4 or IPv6 only.

-

-

-
-  
-    
-    
-  
-
August 14, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/lagg.4 3.html b/static/netbsd/man4/lagg.4 3.html
deleted file mode 100644
index 2c6d4e39..00000000
--- a/static/netbsd/man4/lagg.4 3.html	
+++ /dev/null
@@ -1,139 +0,0 @@
-
-  
-    
-    
-    
-  
-
LAGG(4)Device Drivers ManualLAGG(4)

-

-

-

-
lagg — link
-    aggregation and link failover interface

-

-

-

-
pseudo-device lagg

-

-

-

-
The lagg interface allows aggregation of
-    multiple network interfaces as one virtual lagg
-    interface for the purpose of providing fault-tolerance and high-speed
-  links.

-
A lagg interface can be created using the
-    ifconfig laggN
-    create command. It can use different link
-    aggregation protocols specified using the laggproto
-    proto option. Child interfaces can be added using the
-    laggport child-iface option
-    and removed using the -laggport
-    child-iface option. A priority of each child interface
-    can be configured using the laggport
-    child-iface pri N or
-    laggportpri child-iface
-    N option. The interface preferentially uses the child
-    interface that is the smallest numeric in the priority.

-
The driver currently supports the aggregation protocols
-    failover, loadbalance,
-    lacp, and none (the
-    default). The protocols determine which ports are used for outgoing traffic
-    and whether a specific port accepts incoming traffic. The interface link
-    state is used to validate if the port is active or not.

-

-  

-  
Sends traffic only through the active port that is the highest priority.
-      When the same priority is configured, The first interface added is used
-      for sending traffic. If the link-state of the sending port becomes down,
-      The next priority port is used.
-    
Received traffic is accepted through all active port if
-        laggfailover rx-all
-        option is enabled. The option is enabled by default, and it can be
-        disabled by laggfailover
-        -rx-all option. If the option is disabled,
-        received traffic is only accepted through the sending port.

-  

-  

-  
Balances outgoing traffic across the active ports based on hashed protocol
-      header information and accepts incoming traffic from any active port. This
-      is a static setup and does not negotiate aggregation with the peer or
-      exchange frames to monitor the link. The hash includes the Ethernet source
-      and destination address, and, if available, the VLAN tag, and the IP
-      source and destination address.

-  

-  
Supports the IEEE 802.1AX (formerly 802.3ad) Link Aggregation Control
-      Protocol (LACP) and the Marker Protocol. LACP will negotiate a set of
-      aggregable links with the peer into a Link Aggregated Group. The LAG is
-      composed of ports of the different speed, set to full-duplex operation, if
-      lagglacp multi-speed
-      option is configured. The function can be disabled by
-      lagglacp -multi-speed
-      option. Outgoing traffic across the distributing ports based on hashed
-      protocol header information and accepts incoming traffic from any
-      collecting port. The maximum number of active ports in a LAG can be
-      configured by lagglacp
-      maxports N option.

-  

-  
This protocol is intended to do nothing: it disables any traffic without
-      disabling the lagg interface itself.

-

-
Each lagg interface is created at runtime
-    using interface cloning. This is most easily done with the
-    ifconfig(8) create command.

-
The MTU of the lagg(4) is applied to each
-    physical interfaces. And the physical interfaces can not change its MTU
-    directly.

-

-

-

-
Create a link aggregation using LACP with two
-    wm(4) Gigabit Ethernet interfaces:

-

-
# ifconfig wm0 up
-# ifconfig wm1 up
-# ifconfig lagg0 create
-# ifconfig lagg0 laggproto lacp laggport wm0 laggport wm1 \
-	192.168.1.1 netmask 255.255.255.0

-

-
Create a link aggregation using FAILOVER with two
-    wm(4) Gigabit Ethernet interfaces and set each
-  priority:

-

-
# ifconfig wm0 up
-# ifconfig wm1 up
-# ifconfig lagg0 create
-# ifconfig lagg0 laggproto failover
-# ifconfig lagg0 laggport wm0 pri 1000
-# ifconfig lagg0 laggport wm1 pri 2000
-# ifconfig lagg0 inet 192.168.1.1 netmask 255.255.255.0

-

-

-

-

-
ifconfig(8)

-

-

-

-
The lagg device first appeared in
-    NetBSD 10.0.

-

-

-

-
The lagg driver was written under the name
-    trunk by Reyk Floeter
-    <reyk@openbsd.org>.

-

-

-

-
There is no way to configure LACP administrative variables,
-    including system priority. The current implementation always performs
-    active-mode LACP and uses 0x8000 as system priority.

-

-

-
-  
-    
-    
-  
-
April 2, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/lc.4 4.html b/static/netbsd/man4/lc.4 4.html
deleted file mode 100644
index 46540111..00000000
--- a/static/netbsd/man4/lc.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
LC(4)Device Drivers ManualLC(4)

-

-

-

-
lc — DEC
-    EtherWORKS III Ethernet interfaces device driver

-

-

-

-
lc0 at isa? port ? iomem ? irq ?

-

-

-

-
The lc device driver supports DEC
-    EtherWORKS III Ethernet interfaces, which are based on the LEMAC Ethernet
-    chip. This includes the DE203, DE204, and DE205.

-

-

-

-
The EtherWORKS III series supports various combinations of media,
-    depending on model. Some models also support media autoselect. Media is
-    selected with ifconfig(8)'s media
-    directive.

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), ifconfig(8)

-

-

-

-
The lc does not currently support EISA
-    LEMAC interfaces.

-

-

-
-  
-    
-    
-  
-
November 10, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/ld.4 4.html b/static/netbsd/man4/ld.4 4.html
deleted file mode 100644
index 39bb99ca..00000000
--- a/static/netbsd/man4/ld.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
LD(4)Device Drivers ManualLD(4)

-

-

-

-
ld — logical disk
-    driver

-

-

-

-
ld* at aac? unit ?
-  

-  ld* at amr? unit ?
-  

-  ld* at ataraid? vendtype ? unit ?
-  

-  ld* at cac? unit ?
-  

-  ld* at icp? unit ?
-  

-  ld* at iop? tid ?
-  

-  ld* at mlx? unit ?
-  

-  ld* at nvme? nsid ?
-  

-  ld* at sdmmc?
-  

-  ld* at twa? unit ?
-  

-  ld* at twe? unit ?
-  

-  ld* at virtio?

-

-

-

-
The ld driver provides support for simple
-    block devices, usually presented by a disk array controller.

-

-

-

-

-  
/dev/ldup

-  
block mode disk unit u, partition
-      p

-  
/dev/rldup

-  
raw mode disk unit u, partition
-      p

-

-

-

-

-
aac(4), amr(4),
-    cac(4), icp(4),
-    intro(4), iop(4),
-    mlx(4), nvme(4),
-    sdmmc(4), twa(4),
-    twe(4), virtio(4)

-

-

-

-
The ld driver first appeared in
-    NetBSD 1.5.3.

-

-

-

-
The capacity and geometry of units as accessed through the
-    ld driver may be different than when accessed
-    through some other medium (e.g. SCSI).

-

-

-
-  
-    
-    
-  
-
November 5, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/le.4 4.html b/static/netbsd/man4/le.4 4.html
deleted file mode 100644
index 852ccc7a..00000000
--- a/static/netbsd/man4/le.4 4.html	
+++ /dev/null
@@ -1,383 +0,0 @@
-
-  
-    
-    
-    
-  
-
LE(4)Device Drivers ManualLE(4)

-

-

-

-
le — AMD 7990,
-    79C90, 79C960 LANCE Ethernet interface driver

-

-

-

-

-

-
nele0 at isa? port 0x320 irq 9 drq 7 #
-    NE2100
-  

-  le* at nele?
-  

-  bicc0 at isa? port 0x320 irq 10 drq 7 # BICC Isolan
-  

-  le* at bicc?
-  

-  depca0 at isa? port 0x300 iomem 0xc8000 iosiz 0x8000 irq 5 #
-    DEC DEPCA
-  

-  le* at depca?
-  

-  le* at isapnp? # ISA Plug-and-Play adapters

-

-

-

-
depca* at eisa? slot ? # DEC DE422
-  

-  le* at depca?

-

-

-

-
le* at mca? slot ? # SKNET
-  Personal/MC2+

-

-

-

-
le* at tc? slot ? offset ?

-

-

-

-
le* at ioasic? offset ?

-

-

-

-
le* at zbus0

-

-

-

-
le0 at vme0 irq 4 # BVME410
-  

-  le0 at vme0 irq 5 # Riebl/PAM

-

-

-

-
le* at dio? scode ?

-

-

-

-
le0 at mainbus0

-

-

-

-
le0 at pcc? ipl 3 # MVME147

-

-

-

-
le0 at hb0 addr 0xe0f00000 ipl 4

-

-

-

-
le0 at hb0 addr 0xbff80000 level 1

-

-

-

-
le* at ioasic? offset ?
-  

-  le* at ibus0 addr ?

-

-

-

-
le* at sbus? slot ? offset ?
-  

-  le* at ledma0 slot ? offset ?
-  

-  le* at lebuffer? slot ? offset ?

-

-

-

-
le0 at obio0 addr 0x120000 ipl 3
-  

-  options LANCE_REVC_BUG

-

-

-

-
le0 at vsbus0 csr 0x200e0000

-

-

-

-

-
The le interface provides access to a
-    Ethernet network via the AMD Am7990 and Am79C90 (CMOS, pin-compatible) LANCE
-    (Local Area Network Controller - Ethernet) chip set.

-
In previous releases of NetBSD, the
-    le driver also supported PCnet-PCI cards based on
-    the AMD 79c970 chipset, which is a single-chip implementation of an Ethernet
-    interface that has a LANCE compatibility mode combined with a PCI bus
-    interface. PCnet-PCI interfaces have been supported by the
-    pcn(4) driver since NetBSD
-  1.6.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    le interface employs the Address Resolution Protocol
-    (ARP) described in arp(4) to dynamically map between
-    Internet and Ethernet addresses on the local network.

-
Selective reception of multicast Ethernet frames is provided by a
-    64-bit mask; multicast destination addresses are hashed to a bit entry using
-    the Ethernet CRC function.

-
The use of "trailer" encapsulation to minimize copying
-    data on input and output is supported by the interface but offers no
-    advantage on systems with large page sizes. The use of trailers is
-    automatically negotiated with ARP. This negotiation may be disabled, on a
-    per-interface basis, with ifconfig(8).

-

-

-

-

-

-
The le interface supports the following
-    Zorro II expansion cards:

-

-

-  

-  
Commodore's Ethernet card, manufacturer 514,
-    product 112

-  

-  
Ameristar's Ethernet card, manufacturer 1053, product 1

-  

-  
Village Tronic's Ethernet card, manufacturer 2167,
-      product 201

-

-

-
The A2065 and Ameristar Ethernet cards support only manual media
-    selection.

-
The Ariadne card supports a software media selection for its two
-    different connectors:

-

-  
10Base2/BNC

-  
also known as thinwire-Ethernet

-  
10BaseT/UTP

-  
also known as twisted pair

-

-
The Ariadne card uses an autoselect between UTP and BNC, so it
-    uses UTP when an active UTP line is connected or otherwise BNC. See
-    ifmedia(4) for media selection options for
-    ifconfig(8).

-

-

-

-
The ISA-bus Ethernet cards supported by the
-    le interface are:

-

-

-

-  
BICC Isolan

-  
 

-  
Novell NE2100

-  
 

-  
Digital DEPCA

-  
 

-

-

-

-

-

-
The EISA-bus Ethernet cards supported by the
-    le interface are:

-

-

-

-  
DEC DE422

-  
 

-

-

-

-

-

-
The MCA-bus Ethernet cards supported by the
-    le interface are:

-

-

-

-  
SKNET Personal MC2

-  
 

-  
SKNET MC2+

-  
 

-

-

-

-

-

-
All LANCE interfaces on DECstations are supported, as are
-    interfaces on Alpha AXP machines with a TURBOchannel bus.

-
No support is provided for switching between media ports. The
-    DECstation 3100 provides both AUI and BNC (thinwire or 10BASE2) connectors.
-    Port selection is via a manual switch and is not software configurable.

-
The DECstation model 5000/200 PMAD-AA baseboard device provides
-    only a BNC connector.

-
The ioasic baseboard devices and the
-    PMAD-AA TURBOchannel option card provide only an AUI port.

-

-

-

-
The Sbus Ethernet cards supported by the
-    le interface include:

-

-

-  
SBE/S

-  
SCSI and Buffered Ethernet (sun part 501-1860)

-  
FSBE/S

-  
Fast SCSI and Buffered Ethernet (sun part 501-2015)

-  
Antares SBus 10Base-T Ethernet

-  
Buffered Ethernet (antares part 20-050-1007)

-

-

-
Interfaces attached to an
-     on SPARC
-    systems typically have two types of connectors:

-

-

-  
AUI/DIX

-  
Standard 15 pin connector

-  
10BaseT

-  
UTP, also known as twisted pair

-

-

-
The appropriate connector can be selected by supplying a
-    media parameter to ifconfig(8).
-    The supported arguments for media are:

-

-

-  

-  
to select the AUI connector, or

-  

-  
to select the UTP connector.

-

-

-
If a media parameter is not specified, a
-    default connector is selected for use by examining all media types for
-    carrier. The first connector on which a carrier is detected will be
-    selected. Additionally, if carrier is dropped on a port, the driver will
-    switch between the possible ports until one with carrier is found.

-

-

-

-

-

-  
le%d: overflow

-  
More packets came in from the Ethernet than there was space in the receive
-      buffers. Packets were missed.

-  
le%d: receive buffer error

-  
Ran out of buffer space, packet dropped.

-  
le%d: lost carrier

-  
The Ethernet carrier disappeared during an attempt to transmit. It will
-      finish transmitting the current packet, but will not automatically retry
-      transmission if there is a collision.

-  
le%d: excessive collisions, tdr %d

-  
Ethernet extremely busy or jammed, outbound packets dropped after 16
-      attempts to retransmit.
-    

-        is "Time Domain Reflectometry". The LANCE TDR value is an
-        internal counter of the interval between the start of a transmission and
-        the occurrence of a collision. This value can be used to determine the
-        distance from the Ethernet tap to the point on the Ethernet cable that
-        is shorted or open (unterminated).

-  

-  
le%d: dropping chained buffer

-  
Packet didn't fit into a single receive buffer, packet dropped. Since the
-      le driver allocates buffers large enough to
-      receive the maximum size Ethernet packet, this means some other station on
-      the LAN transmitted a packet larger than allowed by the Ethernet
-    standard.

-  
le%d: transmit buffer error

-  
LANCE ran out of buffer before finishing the transmission of a packet. If
-      this error occurs, the driver software has a bug.

-  
le%d: underflow

-  
LANCE ran out of buffer before finishing the transmission of a packet. If
-      this error occurs, the driver software has a bug.

-  
le%d: controller failed to initialize

-  
Driver failed to start the AM7990 LANCE. This is potentially a hardware
-      failure.

-  
le%d: memory error

-  
RAM failed to respond within the timeout when the LANCE wanted to read or
-      write it. This is potentially a hardware failure.

-  
le%d: receiver disabled

-  
The LANCE receiver was turned off due to an error.

-  
le%d: transmitter disabled

-  
The LANCE transmitter was turned off due to an error.

-

-

-

-

-
arp(4), ifmedia(4),
-    inet(4), intro(4),
-    mca(4), pcn(4),
-    ifconfig(8)

-
Am79C90 - CMOS Local Area
-    Network Controller for Ethernet, 17881,
-    May 1994, Advanced Micro
-    Devices.

-

-

-

-
The pmax le driver is derived from a
-    le driver that first appeared in
-    4.4BSD. Support for multiple bus attachments first
-    appeared in NetBSD 1.2.

-
The Amiga le interface first appeared in
-    NetBSD 1.0

-
The Ariadne Ethernet card first appeared with the Amiga ae
-    interface in NetBSD 1.1 and was converted to the
-    Amiga le interface in NetBSD
-    1.3

-

-

-

-
The Am7990 Revision C chips have a bug which causes garbage to be
-    inserted in front of the received packet occasionally. The work-around is to
-    ignore packets with an invalid destination address (garbage will usually not
-    match), by double-checking the destination address of every packet in the
-    driver. This work-around is enabled with the
-    LANCE_REVC_BUG kernel option.

-
When LANCE_REVC_BUG is enabled, the
-    le driver executes one or two calls to an inline
-    Ethernet address comparison function for every received packet. On the
-    mc68000 it is exactly eight instructions of 16 bits each. There is one
-    comparison for each unicast packet, and two comparisons for each broadcast
-    packet.

-
In summary, the cost of the LANCE_REVC_BUG option is:

-
    
-  
  1. loss of multicast support, and
    2. 
-  
  2. eight extra CPU instructions per received packet, sometimes sixteen,
-      depending on both the processor, and the type of packet.
    3. 
-

-
All sun3 systems are presumed to have this bad revision of the
-    Am7990, until proven otherwise. Alas, the only way to prove what revision of
-    the chip is in a particular system is inspection of the date code on the
-    chip package, to compare against a list of what chip revisions were
-    fabricated between which dates.

-
Alas, the Am7990 chip is so old that AMD has
-    "de-archived" the production information about it; pending a
-    search elsewhere, we don't know how to identify the revision C chip from the
-    date codes.

-
On all pmax front-ends, performance is impaired by hardware which
-    forces a software copy of packets to and from DMA buffers. The
-    ioasic machines and the DECstation 3100 must copy
-    packets to and from non-contiguous DMA buffers. The DECstation 5000/200 and
-    the PMAD-AA must copy to and from an onboard SRAM DMA buffer. The CPU
-    overhead is noticeable, but all machines can sustain full 10 Mb/s media
-    speed.

-

-

-
-  
-    
-    
-  
-
June 11, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/lii.4 4.html b/static/netbsd/man4/lii.4 4.html
deleted file mode 100644
index bd3cfa85..00000000
--- a/static/netbsd/man4/lii.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
LII(4)Device Drivers ManualLII(4)

-

-

-

-
lii —
-    Attansic/Atheros L2 Fast-Ethernet device driver

-

-

-

-
lii* at pci? dev ? function ?

-

-

-

-
The lii provides support for the
-    Attansic/Atheros Fast-Ethernet card. This card is found in a variety of
-    low-end Asus hardware, notably the Asus EeePC.

-

-

-

-
atphy(4), mii(4)

-

-

-

-
The lii driver appeared in
-    NetBSD 5.0.

-

-

-

-
Quentin Garnier
-    ⟨cube@NetBSD.org⟩

-

-

-
-  
-    
-    
-  
-
January 18, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/lm.4 4.html b/static/netbsd/man4/lm.4 4.html
deleted file mode 100644
index 0f6b0a61..00000000
--- a/static/netbsd/man4/lm.4 4.html	
+++ /dev/null
@@ -1,194 +0,0 @@
-
-  
-    
-    
-    
-  
-
LM(4)Device Drivers ManualLM(4)

-

-

-

-
lm — National
-    Semiconductor LM78, LM79 and compatible hardware monitors

-

-

-

-
lm0 at isa? port 0x280 flags 0x00
-  

-  lm1 at isa? port 0x290 flags 0x00
-  

-  lm2 at isa? port 0x310 flags 0x00
-  

-  lm3 at isa? port 0xa00 flags 0x00
-  

-  lm0 at pnpbios0 index ? flags 0x00
-  

-  lm0 at iic? addr 0x2e flags 0x00
-  

-  lm* at wbsio?

-

-

-

-
The lm driver provides support for the
-    National Semiconductor LM series hardware monitors and register compatible
-    chips to be used with the envsys(4) API.

-
The original LM78 hardware monitor supports 11 sensors:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uV DCCore voltage
uV DCunknown
uV DC+3.3V
uV DC+5V
uV DC+12V
uV DC-12V
uV DC-5V
uKMotherboard Temperature
RPMFan
RPMChassis Fan
RPMFan

-For other devices, sensors' names and numbers will be different.
-
Due to hardware limitations, fresh sensor data is only available
-    every 2 seconds.

-

-

-

-
Chips supported by the lm driver
-  include:

-
-
For most of the Winbond chips (identified with a * above), the
-    flags configuration option can be specified to select the
-    type of temperature sensor:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Sensor Type
Thermistor diode (Power-On default)
Pentium-II diode
2N3904 Bipolar
Thermistor diode

-

-

-

-
envsys(4), wbsio(4),
-    envstat(8)

-

-

-

-
The lm device appeared in
-    NetBSD 1.5.

-

-

-

-
Some vendors connect these chips to non-standard thermal diodes
-    and resistors. This will result in bogus sensor values.

-

-

-

-
Interrupt support is unimplemented.

-
There are currently no known pnpbios IDs assigned to LM chips.

-

-

-
-  
-    
-    
-  
-
December 15, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/lmenv.4 4.html b/static/netbsd/man4/lmenv.4 4.html
deleted file mode 100644
index 2d04e7ee..00000000
--- a/static/netbsd/man4/lmenv.4 4.html	
+++ /dev/null
@@ -1,107 +0,0 @@
-
-  
-    
-    
-    
-  
-
LMENV(4)Device Drivers ManualLMENV(4)

-

-

-

-
lmenv — National
-    Semiconductor LM81, LM87, and compatible hardware monitors

-

-

-

-
lmenv0 at iic0 addr 0x2c: ADM9240 rev
-  2

-

-

-

-
The lmenv driver provides support for the
-    National Semiconductor LM87, National Semiconductor LM81, Analog Devices
-    ADM9240, and Dallas Semiconductor DS1780 iicbus hardware monitors. Sensor
-    values are reported through the envstat(8) interface.

-
The lmenv supports the following voltage,
-    temperature, and fan speed sensors:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Type
Volts DC
Volts DC
Volts DC
Volts DC
Volts DC
Volts DC
Temperature
Temperature
Speed
Speed

-On the LM87 monitor, AIN1 and AIN2 Volts DC sensors may replace either, or both
-  of the FAN1 and FAN2 speed sensors, respectively.
-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The lmenv driver first appeared in
-    OpenBSD 3.9. NetBSD support
-    was added in NetBSD 7.0.

-

-

-

-
The lmenv driver was written for
-    OpenBSD by Mark Kettenis
-    ⟨kettenis@openbsd.org⟩, and ported to
-    NetBSD by
-  

-  Julian Coleman ⟨jdc@NetBSD.org⟩.

-

-

-

-
High and low sensor limits are not supported.

-
Interrupt support is not implemented.

-

-

-
-  
-    
-    
-  
-
October 14, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/lmtemp.4 3.html b/static/netbsd/man4/lmtemp.4 3.html
deleted file mode 100644
index e13881d3..00000000
--- a/static/netbsd/man4/lmtemp.4 3.html	
+++ /dev/null
@@ -1,118 +0,0 @@
-
-  
-    
-    
-    
-  
-
LMTEMP(4)Device Drivers ManualLMTEMP(4)

-

-

-

-
lmtemp — National
-    Semiconductor LM75, LM77 and compatible hardware monitors

-

-

-

-
lmtemp0 at iic? addr 0x48 flags 0x0000

-

-

-

-
The lmtemp driver provides support for the
-    National Semiconductor LM on iicbus series temperature sensors and register
-    compatible chips.

-
Each device is specified by the value of the address and
-  flags.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
0x48 - 0x4f0x0000
0x48 - 0x4f0x0000
0x48 - 0x4f0x0001
0x48 - 0x4b0x0002

-

-

-

-
Chips supported by the lmtemp driver
-    include:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
-55 – +1250.5 degC
-55 – +1250.5 degC
-55 – +1250.0625 degC
-55 – +1300.5 degC

-
The LM75, LM75A, and DS75 have a programmable high temperature
-    limit. When this is exceeded, the device asserts an over-temperature
-  output.

-
The LM77 has programmable low and high temperature limits.
-    Exceeding either of these causes the device to assert an interrupt output.
-    It also has a programmable critical high temperature limit, and exceeding
-    this causes the device to assert a separate critical alarm output.

-
The sensor and limit values are made available through the
-    envstat(8) interface.

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The lmtemp device appeared in
-    NetBSD 4.0.

-

-

-

-
Interrupt support is unimplemented.

-

-

-
-  
-    
-    
-  
-
January 1, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/lo.4 4.html b/static/netbsd/man4/lo.4 4.html
deleted file mode 100644
index a7eb372a..00000000
--- a/static/netbsd/man4/lo.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
LO(4)Device Drivers ManualLO(4)

-

-

-

-
lo — software
-    loopback network interface

-

-

-

-
pseudo-device loop

-

-

-

-
The loop interface is a software loopback
-    mechanism which may be used for performance analysis, software testing,
-    and/or local communication. As with other network interfaces, the loopback
-    interface must have network addresses assigned for each address family with
-    which it is to be used. These addresses may be set or changed with the
-    SIOCSIFADDR ioctl(2). The loopback
-    interface should be the last interface configured, as protocols may use the
-    order of configuration as an indication of priority. The loopback should
-     be
-    configured first unless no hardware interfaces exist.

-
The loopback interface lo0 is created at
-    boottime, it always exists and cannot be destroyed with
-    ifconfig(8). Additional loopback interfaces can be created
-    by using the ifconfig(8) create
-    command.

-

-

-

-

-  
lo%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-

-

-

-

-
inet(4), intro(4),
-    ifconfig(8)

-

-

-

-
The lo device appeared in
-    4.2BSD.

-

-

-

-
Previous versions of the system enabled the loopback interface
-    automatically, using a nonstandard Internet address (127.1). Use of that
-    address is now discouraged; a reserved host address for the local network
-    should be used instead.

-

-

-
-  
-    
-    
-  
-
September 3, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/lpt.4 4.html b/static/netbsd/man4/lpt.4 4.html
deleted file mode 100644
index e6a05ccc..00000000
--- a/static/netbsd/man4/lpt.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
LPT(4)Device Drivers ManualLPT(4)

-

-

-

-
lpt — generic
-    printer device driver

-

-

-

-
lpt* at ppbus?
-  

-  options LPT_DEBUG
-  

-  options LPT_VERBOSE

-

-

-

-
The lpt driver is the port of the lpt
-    driver to the ppbus(4) system.

-
The purpose of this driver is to allow parallel port sharing with
-    other parallel devices. See ppbus(4) for more information
-    about the parallel port bus system.

-
The parallel port bus is reserved by lpt
-    when the printer device is opened and released when the device is
-  closed.

-
Ports can be configured to use interrupts, DMA, IEEE negotiations,
-    and IEEE compliant transfer modes by using the lptctl(8)
-    command, with modes depending on the hardware available.

-

-

-

-

-  
/dev/lpt?

-  
parallel port device

-  
/dev/lpt?ctl

-  
parallel port control device

-

-

-

-

-
atppc(4), ppbus(4),
-    lptctl(8), mknod(8)

-

-

-

-
This driver is derived from the FreeBSD
-    ppbus and also from the historic NetBSD drivers.

-
The lpt driver used to assign special
-    meaning for some bits of device minor. This was dropped in ppbus-based
-    lpt in favour of configuration via
-    lptctl(8).

-

-

-

-
This manual page was based on the FreeBSD
-    lpt manual page. The information has been updated
-    for the NetBSD port by Gary Thorpe.

-

-

-
-  
-    
-    
-  
-
February 3, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/lua.4 4.html b/static/netbsd/man4/lua.4 4.html
deleted file mode 100644
index 9f3161e7..00000000
--- a/static/netbsd/man4/lua.4 4.html	
+++ /dev/null
@@ -1,189 +0,0 @@
-
-  
-    
-    
-    
-  
-
LUA(4)Device Drivers ManualLUA(4)

-

-

-

-
lua — control
-    in-kernel Lua states

-

-

-

-
lua*

-

-  

-  #include <sys/types.h>
-  

-  #include <sys/lua.h>

-

-

-

-
The lua device allows to create, control,
-    and delete Lua states in the kernel through an ioctl(2)
-    interface. Moreover, lua can be used to load Lua
-    scripts into a Lua state and to assign modules to an existing state, i.e.
-    perform the equivalent of the Lua command require.
-    lua is also used to retrieve information about
-    currently active Lua states.

-

-

-

-
Lua modules are used to provide functionality to Lua scripts not
-    available in the language itself, e.g. to access core kernel functionality
-    like printing text on the console. Unlike in user space Lua, where Lua
-    modules are files in the filesystem, modules must be provided to
-    lua in the form of loadable kernel modules that
-    register their functionality with lua. Modules are
-    loaded using the require Lua command; whether this
-    command is available or not is controlled by a sysctl(8)
-    variable. lua by default tries to load a kernel
-    module named
-    
-    when it encounters the Lua command require 'foo'.

-

-

-

-
The operation of lua can be controlled by
-    means of the following sysctl(8) variables:

-

-  

-  
When set to 1, lua tries to autoload kernel
-      modules.
-    
The default value is 1.

-  

-  

-  
When set to 1, loading of Lua bytecode is allowed.
-    
The default value is 0.

-  

-  

-  
When set to a value > 0, lua limits the number
-      of instructions executed to this number.
-    
The default value is 0.

-  

-  

-  
When set to 1, enables the require command in Lua.
-    
The default value is 1.

-  

-  

-  
When set to a value > 0, verbosity is increased.
-    
The default value is 0.

-  

-

-

-

-

-
The following structures and constants are defined in the
-    <sys/lua.h> header file:

-

-

-  

-  
Returns information about the lua states in the
-      lua_info structure:
-    

-    
#define MAX_LUA_NAME		16
-#define MAX_LUA_DESC		64
-
-struct lua_state_info {
-	char	name[MAX_LUA_NAME];
-	char	desc[MAX_LUA_DESC];
-	bool	user;
-};
-
-struct lua_info {
-	int num_states;		/* total number of Lua states */
-	struct lua_state_info *states;
-};

-    

-    

-  

-  

-  
Create a new named Lua state with name and description in the
-      lua_create structure:
-    

-    
struct lua_create {
-	char	name[MAX_LUA_NAME];
-	char	desc[MAX_LUA_DESC];
-};

-    

-    

-  

-  

-  
Destroy a named Lua state.
-    

-  

-  

-  
Perform the equivalent of the Lua command require in a
-      named state. The name of the state and of the module name is passed in the
-      lua_require structure:
-    

-    
#define LUA_MAX_MODNAME		32
-
-struct lua_require {
-	char	state[MAX_LUA_NAME];
-	char	module[LUA_MAX_MODNAME];
-};

-    

-    

-  

-  

-  
Load Lua code from the filesystem into a named Lua state. The name of the
-      state and the path to the Lua code are passed in the
-      lua_load structure:
-    

-    
struct lua_load {
-	char	state[MAX_LUA_NAME];
-	char	path[MAXPATHLEN];
-};

-    

-    
The path element of the lua_load
-        structure must contain at least one ‘/’ character.

-  

-

-

-

-

-

-  
/dev/lua

-  
Lua device file.

-

-

-

-

-
ioctl(2), luactl(8)

-

-

-

-
The lua device first appeared in
-    NetBSD 7.0.

-

-

-

-
The lua driver was written by
-    Marc Balmer
-    <mbalmer@NetBSD.org>.

-

-

-

-
The lua device is experimental.
-    Incompatible changes might be made in the future.

-

-

-
-  
-    
-    
-  
-
July 25, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/lxtphy.4 4.html b/static/netbsd/man4/lxtphy.4 4.html
deleted file mode 100644
index bb1ef066..00000000
--- a/static/netbsd/man4/lxtphy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
LXTPHY(4)Device Drivers ManualLXTPHY(4)

-

-

-

-
lxtphy — Driver
-    for Level One LXT-970 10/100 Ethernet PHYs

-

-

-

-
lxtphy* at mii? phy ?

-

-

-

-
The lxtphy driver supports the Level One
-    LXT-970, LXT-970A and LXT-971 10/100 Ethernet PHYs. These PHYs are found on
-    a variety of high-performance Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 3, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/m25p.4 4.html b/static/netbsd/man4/m25p.4 4.html
deleted file mode 100644
index 5a1a8b57..00000000
--- a/static/netbsd/man4/m25p.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
M25P(4)Device Drivers ManualM25P(4)

-

-

-

-
m25p —
-    STMicroelectronics M25P family of SPI-connected flash
-    devices

-

-

-

-
m25p* at spi0 slave 0

-

-

-

-
The m25p driver provides support for
-    STMicrolelectronics' M25P family of SPI connected NOR flash devices.

-

-

-

-
spi(4)

-

-

-

-
The machine-independent m25p driver was
-    written by Garrett D'Amore for the Champaign-Urbana
-    Community Wireless Network Project (CUWiN), and appeared in
-    NetBSD 4.0.

-

-

-

-
Some important bits that are vital for use as a mass storage
-    device are still missing. Specifically, there is no API to erase the device,
-    and there is no support for device partitioning.

-

-

-
-  
-    
-    
-  
-
October 9, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/machfb.4 4.html b/static/netbsd/man4/machfb.4 4.html
deleted file mode 100644
index 210e33cf..00000000
--- a/static/netbsd/man4/machfb.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
MACHFB(4)Device Drivers ManualMACHFB(4)

-

-

-

-
machfb — ATI
-    Mach64/RAGE framebuffer driver

-

-

-

-
machfb* at pci?
-  

-  wsdisplay* at machfb?

-

-

-

-
The machfb driver provides support for ATI
-    RAGE and Mach64 graphics accelerators. 2D acceleration is supported via the
-    rasops(9) framework.

-
machfb is primarily used on PowerPC and
-    SPARC64, but works on other architectures. By default, on other
-    architectures, vga(4) or genfb(4) will
-    be used instead.

-

-

-

-
The following chipsets should work:

-

-

-

-  
ATI RAGE II

-  
 

-  
ATI RAGE IIc

-  
 

-  
ATI RAGE Pro

-  
 

-  
ATI RAGE LT

-  
 

-  
ATI RAGE LT Pro

-  
 

-  
ATI RAGE XL

-  
 

-  
ATI Mach64 GX

-  
 

-  
ATI Mach64 CX

-  
 

-  
ATI Mach64 CT

-  
 

-  
ATI Mach64 VT

-  
 

-

-

-

-

-

-
ati(4), mach64drm(4),
-    wscons(4), wsdisplay(4)

-

-

-

-
The machfb driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
April 14, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/mainbus.4 4.html b/static/netbsd/man4/mainbus.4 4.html
deleted file mode 100644
index 7479d1a5..00000000
--- a/static/netbsd/man4/mainbus.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAINBUS(4)Device Drivers ManualMAINBUS(4)

-

-

-

-
mainbus — top
-    level pseudo “bus”

-

-

-

-
mainbus0 at root
-    instance
-  

-  at mainbus0

-

-

-

-
The mainbus is not a real bus, but serves
-    as the top level device to which other busses and drivers attach.

-

-

-

-
intro(4), config(5),
-    autoconf(9).

-

-

-
-  
-    
-    
-  
-
May 2, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/makphy.4 4.html b/static/netbsd/man4/makphy.4 4.html
deleted file mode 100644
index f1b8ee3f..00000000
--- a/static/netbsd/man4/makphy.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAKPHY(4)Device Drivers ManualMAKPHY(4)

-

-

-

-
makphy — Driver
-    for Marvell Semiconductor 88E1000 “Alaska” 10/100/1000
-    Ethernet PHY

-

-

-

-
makphy* at mii? phy ?

-

-

-

-
The makphy driver supports the Marvell
-    Semiconductor 88E1000 10/100/1000 Ethernet PHY. These PHYs are found on a
-    variety of CAT5 Gigabit Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
July 25, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/malo.4 4.html b/static/netbsd/man4/malo.4 4.html
deleted file mode 100644
index d638d29c..00000000
--- a/static/netbsd/man4/malo.4 4.html	
+++ /dev/null
@@ -1,148 +0,0 @@
-
-  
-    
-    
-    
-  
-
MALO(4)Device Drivers ManualMALO(4)

-

-

-

-
malo — Marvell
-    Libertas IEEE 802.11b/g wireless network device

-

-

-

-
malo* at pci?

-

-

-

-
The malo driver provides support for
-    Marvell Libertas 88W8335/88W8310/88W8385 based PCI network adapters. The
-    second generation 88W8335/88W8310 chipsets support 802.11b/g.

-
These are the modes the malo driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The malo driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it. The
-    malo driver relies on the software 802.11 stack for
-    both encryption and decryption of data frames.

-
The malo driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5).

-

-

-

-
The driver needs a set of firmware files which are loaded when an
-    interface is brought up:

-

-

-

-  
/libdata/firmware/malo/malo8335-h

-  
 

-  
/libdata/firmware/malo/malo8335-m

-  
 

-  
/libdata/firmware/malo/malo8338

-  
 

-  
/libdata/firmware/malo/malo8385-h

-  
 

-  
/libdata/firmware/malo/malo8385-m

-  
 

-

-

-
These firmware files are not free because Marvell refuses to grant
-    distribution rights. As a result, even though
-    OpenBSD includes the driver, the firmware files
-    cannot be included and users have to download these files on their own.

-
A prepackaged version of the firmware, designed to be used with
-    pkg_add(1), can be found at:

-

-
http://www.nazgul.ch/malo/malo-firmware-1.4.tgz

-

-

-

-

-
The following cards are among those supported by the
-    malo driver:

-

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
Netgear WG311v388W8335PCIb/g
Tenda TWL542P88W8335PCIb/g

-

-

-

-
The following ifconfig.if(5) example configures
-    malo0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
dhcp NONE NONE NONE nwkey 0x1deadbeef1 chan 11

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig malo0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-
Contrary to the driver on OpenBSD, this
-    driver currently does not work on PCMCIA/CARDBUS.

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), ifconfig.if(5),
-    hostapd(8), ifconfig(8)

-

-

-

-
The malo driver was first written by
-    Claudio Jeker
-    <claudio@openbsd.org>
-    and Marcus Glocker
-    <mglocker@openbsd.org>
-    and appeared first in OpenBSD 4.1.
-    NetBSD porting was done by Arnaud
-    Degroote
-    <degroote@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 30, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/man4.alpha/intro.4 2.html b/static/netbsd/man4/man4.alpha/intro.4 2.html
deleted file mode 100644
index 3a8336ec..00000000
--- a/static/netbsd/man4/man4.alpha/intro.4 2.html	
+++ /dev/null
@@ -1,403 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (alpha)INTRO(4)

-

-

-

-
intro —
-    introduction to alpha special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported by
-    NetBSD/alpha. Software support for these devices
-    comes in two forms. A hardware device may be supported with a character or
-    block , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    alpha/autoconf(4). A list of the supported devices is
-    given below.

-

-

-

-
config(1),
-  alpha/autoconf(4)

-

-

-

-
DEC and Compaq have produced a series of the Alpha CPU, some of
-    which are listed below, along with some systems which contain them.

-
The NetBSD Project distributes binary
-    programs for its Alpha port compiled for the lowest common denominator CPU
-    instruction set, to guarantee binary compatibility across all supported
-    Alpha systems. However, it is possible to sacrifice binary compatibility for
-    additional performance on later model CPUs with performance enhancing
-    instructions (e.g. the 21164-A and later with the BWX extensions). This
-    requires recompiling from source code, with appropriate options given to
-    cc(1) to indicate the target CPU.

-
"EV" stands for "Extended VAX" (or
-    "Electro Vlassic") and the number following is a reference to the
-    CMOS process used to make the chips. "LCA" stands for Low Cost
-    Alpha, and "PCA" stands for PC-architecture Alpha.

-

-  
21064

-  
 (100-200 MHz,
-      0.75 micron)
-    
AlphaPC 64 (EB64)

-    

-      
Jensen family

-      

-        

-        DECpc AXP 150 (Jensen)
-        

-        DEC 2000/300 (Jensen)
-        

-        DEC 2000/500 (Culzen)

-      
Avanti family

-      

-        

-        Digital's lower-end PCI-based workstations.
-        
AlphaStation 200 4/100-166 (Mustang)
-          

-          AlphaStation 400 4/166 (Chinet)

-      

-      
Sable family

-      

-        

-        AlphaServer 2000 4/200 (Demi-Sable)
-        

-        AlphaServer 2100 4/200 (Sable)

-      
Pelican family

-      

-        

-        Low-end TURBOchannel based workstations.
-        
DEC 3000/300 (150 MHz) (Pelican)
-          

-          DEC 3000/300X (175 MHz) (Pelican+)
-          

-          DEC 3000/300L (100 MHz) (Pelica)
-          

-          DEC 3000/300LX (125 MHz) (Pelica+)

-      

-      
Sandpiper family

-      

-        

-        High-end TURBOchannel based workstations.
-        
DEC 3000/400 (133 MHz) (Sandpiper)
-          

-          DEC 3000/600 (175 MHz) (Sandpiper+)

-      

-      
Flamingo family

-      

-        

-        High-end TURBOchannel based workstations.
-        
DEC 3000/500 (150 MHz) (Flamingo)
-          

-          DEC 3000/500X (200 MHz) (Hot Pink)
-          

-          DEC 3000/800 (200 MHz) (Flamingo II)

-      

-    

-  

-  
21064-A

-  
 (225-333 MHz,
-      0.50 micron)
-    
DEC 3000/700 (225 MHz) (Sandpiper45)
-      

-      DEC 3000/900 (275 MHz) (Flamingo45)

-    
Alpha XL 233-266 (XL)
-      

-      AlphaPC 64 (EB64+)

-    

-      
Avanti family

-      

-        

-        Digital's lower-end PCI-based workstations.
-        
AlphaStation 200 4/233 (Mustang+)
-          

-          AlphaStation 205 4/133-333 (LX3)
-          

-          AlphaStation 250 4/300 (M3+)
-          

-          AlphaStation 255 4/133-333 (LX3+)
-          

-          AlphaStation 300 4/266 (Melmac)
-          

-          AlphaStation 400 4/233-300 (Avanti)

-      

-      
Sable family

-      

-        

-        AlphaServer 2000 4/233-275 (Demi-Sable)
-        

-        AlphaServer 2100 4/233-275 (Sable)

-    

-    
AlphaServer 2100A (Lynx)

-  

-  
21066

-  
 (166-233 MHz,
-      0.75 micron)
-    

-      
NoName family

-      

-        

-        Digital's lowest-end family of PCI-based systems.
-        
DEC AXPpci33 (NoName)
-          

-          Universal Desktop Box AXPpci166MT (UDB/Multia)

-      

-    

-    
21066 evaluation motherboard (EB66)

-  

-  
21066-A

-  
 (233 MHz,
-      0.50 micron)
-    
21066-A evaluation motherboard (EB66+)

-  

-  
21068

-  
 (66-233
-      MHz, 0.75 micron)
-    
Alpha Book (Burns)
-      

-      Universal Desktop Box AXPpci233MT (UDB/Multia)

-  

-  
21164

-  
 (250-366 MHz,
-      0.50 micron)
-    

-      
Alcor family

-      

-        

-        AlphaStation 500/266-333 (Maverick)
-        

-        AlphaStation 600/266-300 (Alcor)
-        

-        Alpha XL 300-433 (XLT)

-      
Sable family

-      

-        

-        AlphaServer 2000 5/250-300 (Demi-Gamma)
-        

-        AlphaServer 2100 5/250-300 (Gamma Sable)

-      
Mikasa family

-      

-        

-        AlphaServer 1000 5/300 (Pinnacle)

-      
Noritake family

-      

-        

-        AlphaServer 1000A 5/300 (Pinnacle)

-      
Rawhide family

-      
(KN300)
-        

-        AlphaServer 4000 5/266-300 (Wrangler)
-        

-        AlphaServer 4000 5/266-300 (Durango)
-        

-        AlphaServer 4100 5/266-300 (Dodge)

-    

-    
AlphaServer 8200 and 8400 (KN8AE)

-    
21164 evaluation motherboard (EB164)

-  

-  
21164-A

-  
 (400-766 MHz,
-      0.35 micron, BWX)
-    

-      
Alcor family

-      

-        

-        AlphaStation 500/333-500 (Bret)

-      
Personal Workstation (PWS)

-      

-        

-        PWS 433a/433au (Miata)
-        

-        PWS 500a/500au (Miata)
-        

-        PWS 600a/600au (Miata)

-      
Sable family

-      

-        

-        AlphaServer 2100 5/375-400 (Gamma Sable)
-        

-        AlphaServer 2000 5/375-400 (Demi-Gamma)

-      
Mikasa family

-      

-        

-        AlphaServer 1000 5/333-500 (Primo)

-      
Noritake family

-      

-        

-        AlphaServer 1000A 5/333-500 (Primo)
-        

-        AlphaServer 600A 5/500 (Alcor-Primo)
-        

-        AlphaServer 800 5/333-500 (Corelle)

-      
Rawhide family

-      
(KN300)
-        

-        AlphaServer 4000 5/400-666 (Wrangler)
-        

-        AlphaServer 4000 5/400-666 (Durango)
-        

-        AlphaServer 4100 5/400-666 (Dodge)
-        
AlphaServer 1200 5/400-666 (Tincup)
-          

-          AlphaServer 1200 5/400-666 (DaVinci)

-      

-      
EB164 family

-      

-        

-        AlphaPC 164 motherboard (EB164)
-        

-        AlphaPC 164LX motherboard (EB164)

-    

-    
DigitalServer 3300 (rebadged AlphaServer 800 for NT)
-      

-      DigitalServer 5300 (rebadged AlphaServer 1200 for NT)
-      

-      DigitalServer 7300 (rebadged AlphaServer 4100 for NT)

-    
AlphaServer 8200 and 8400 (KN8AE)

-    
APi AlphaPC 164UX motherboard (Ruffian)

-  

-  
21164-PC

-  
 (400-600
-      MHz, 0.35 micron, MVI, no L2 cache)
-    
AlphaPC 164SX motherboard (EB164)

-    
PWS 466au (Miata)
-      

-      PWS 550au (Miata)

-  

-  
21264

-  
 (450-600 MHz,
-      0.35 micron)
-    
AlphaServer 8400 (KN8AE)

-    
APi UP1000 and UP1100; AMD 751-based EV6 systems.

-    
264DP, XP1000, DS10, DS20, APi UP2000, UP2000+ Tsunami-based
-        systems.

-  

-  
21264-A

-  
 (600-833 MHz,
-      0.28 micron)
-    
AlphaServer GS60E
-      

-      AlphaServer GS140

-  

-  
21264-B

-  
 (833-1250
-      MHz, 0.18 micron)
-    
AlphaServer DS20L

-  

-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-

-  
apecs

-  
DECchip 21072/21071 Core Logic chipset

-  
asc

-  
TURBOchannel single-channel SCSI adapter

-  
cia

-  
DECchip 2117x Core Logic chipset

-  
dwlpx

-  
DEC DWLPA and DWLPB PCI adapter

-  
gbus

-  
internal bus on AlphaServer CPU modules

-  
irongate

-  
APi UP1000 AMD751 Core Logic + AGP chipset

-  
jensenio

-  
DEC 2000/300 (Jensen) I/O module

-  
kft

-  
KFTIA and KFTHA Bus Adapter Node for I/O hoses

-  
lca

-  
DECchip 21066 Core Logic chipset

-  
mcbus

-  
MCBUS system bus found on AlphaServer 4100 systems

-  
mcpcia

-  
MCPCIA MCBUS-to-PCI bus adapter

-  
sableio

-  
AlphaServer 2100 (Sable) STD I/O module

-  
tcasic

-  
TURBOchannel host bus support

-  
tlsb

-  
AlphaServer 8x00 TurboLaser System bus

-  
tsc

-  
DECchip 21272 Core Logic chipset

-  
tsciic

-  
DECchip 21272 Core Logic chipset I2C controller

-  
tsp

-  
DECchip 21272 Core Logic chipset PCI controller

-  
ttwoga

-  
DEC T2 Gate Array

-  
ttwopci

-  
DEC T2 Gate Array PCI controller

-

-

-
TURBOchannel devices are supported through the
-    tc(4) bus and associated device drivers.

-
PCI devices are supported through the pci(4) bus
-    and associated device drivers.

-
ISA devices are supported through the isa(4) bus
-    and associated device drivers.

-
EISA devices are supported through the eisa(4)
-    bus and associated device drivers.

-
PCMCIA devices are supported through the
-    pcmcia(4) bus and associated device drivers.

-
I2C devices are supported through the iic(4) bus
-    and associated device drivers.

-
Console devices using ISA, EISA, or PCI video adaptors and
-    standard AT or PS/2 keyboards are supported by the machine independent
-    wscons(4) console driver.

-

-

-

-
This alpha intro appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.alpha/jensenio.4 3.html b/static/netbsd/man4/man4.alpha/jensenio.4 3.html
deleted file mode 100644
index 33a28ea9..00000000
--- a/static/netbsd/man4/man4.alpha/jensenio.4 3.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
JENSENIO(4)Device Drivers Manual (alpha)JENSENIO(4)

-

-

-

-
jensenio — DEC
-    2000/300 (Jensen) I/O module

-

-

-

-
jensenio* at mainbus0

-

-

-

-
The jensenio driver provides support for
-    the I/O module found on the DEC 2000/300. The module is comprised of two
-    things:

-

-
    
-  
  • VLSI VL82C106 junk I/O chip; and
    • 
-  
  • Intel EISA bus interface.
    • 
-

-
The following devices are supported by the
-    jensenio driver:

-

-

-

-  
com

-  
serial communications interface

-  
eisa

-  
machine-independent EISA bus

-  
isa

-  
machine-independent ISA bus

-  
lpt

-  
Parallel port driver

-  
mcclock

-  
DS1287 real-time clock

-  
pckbc

-  
PC keyboard controller driver

-

-

-

-

-

-
alpha/intro(4), com(4),
-    eisa(4), isa(4),
-    lpt(4), mcclock(4),
-    pckbc(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.alpha/tlsb.4 3.html b/static/netbsd/man4/man4.alpha/tlsb.4 3.html
deleted file mode 100644
index 9eaf9148..00000000
--- a/static/netbsd/man4/man4.alpha/tlsb.4 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
TLSB(4)Device Drivers Manual (alpha)TLSB(4)

-

-

-

-
tlsb — AlphaServer
-    8x00 TurboLaser System bus

-

-

-

-
tlsb* at mainbus0
-  

-  tlsbmem* at tlsb? node ? offset ?

-

-

-

-
The tlsb driver provides support for the
-    TurboLaser System Bus found on AlphaServer 8200 and 8400 systems.

-
The following devices are supported by the
-    tlsb driver:

-

-

-

-  
gbus

-  
internal bus on AlphaServer CPU modules

-  
kft

-  
KFTIA and KFTHA Bus Adapter Node for I/O hoses

-  
tlsbmem

-  
TurboLaser system memory

-

-

-

-

-

-
alpha/gbus(4), alpha/intro(4),
-    alpha/kft(4), mainbus(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.alpha/tsciic.4 3.html b/static/netbsd/man4/man4.alpha/tsciic.4 3.html
deleted file mode 100644
index 5fc19900..00000000
--- a/static/netbsd/man4/man4.alpha/tsciic.4 3.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
TSCIIC(4)Device Drivers Manual (alpha)TSCIIC(4)

-

-

-

-
tsciic — DECchip
-    21272 Core Logic chipset I2C controller

-

-

-

-
tsciic* at tsc?
-  

-  iic* at tsciic?

-

-

-

-
The tsciic driver provides support for the
-    I2C controller on the DECchip 21272 Core Logic chipset.

-

-

-

-
alpha/intro(4), alpha/tsc(4),
-    iic(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/a34kbbc.4 3.html b/static/netbsd/man4/man4.amiga/a34kbbc.4 3.html
deleted file mode 100644
index a03c0356..00000000
--- a/static/netbsd/man4/man4.amiga/a34kbbc.4 3.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
A34KBBC(4)Device Drivers Manual (amiga)A34KBBC(4)

-

-

-

-
a34kbbc — Amiga
-    3000/4000 on-board real-time clock

-

-

-

-
a34kbbc at mainbus0

-

-

-

-
The a34kbbc real-time clock driver
-    provides support for the Ricoh RP5C01 chip found in A3000/A4000 class
-    machines.

-

-

-

-
todr(9)

-

-

-

-
The a34kbbc device first appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
April 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/afsc.4 3.html b/static/netbsd/man4/man4.amiga/afsc.4 3.html
deleted file mode 100644
index 9aec5dbb..00000000
--- a/static/netbsd/man4/man4.amiga/afsc.4 3.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
AFSC(4)Device Drivers Manual (amiga)AFSC(4)

-

-

-

-
afsc — A4091 low
-    level SCSI interface

-

-

-

-
afsc0 at zbus0

-

-

-

-
The Amiga architecture uses a common machine independent scsi
-    sub-system provided in the kernel source. The machine independent drivers
-    that use this code access the hardware through a common interface. (see
-    scsibus(4)) This common interface interacts with a machine
-    dependent interface, such as afsc, which then
-    handles the hardware specific issues.

-
The afsc interface handles things such as
-    DMA and interrupts as well as actually sending commands, negotiating
-    synchronous or asynchronous transfers and handling disconnect/reconnect of
-    SCSI targets. The hardware that afsc uses is based
-    on the NCR53c710 SCSI chip.

-

-

-

-
The afsc interface supports the following
-    Zorro III expansion cards:

-

-

-  

-  
Commodore SCSI adapter, manufacturer 514, product 84

-

-

-

-

-

-

-  
afsc%s: abort %s: dstat %02x, sstat0 %02x sbcl %02x

-  
The scsi operation %s was aborted due to error. Dstat, sstat and sbcl are
-      registers within the NCR53c710 SCSI chip.

-  
siop id %d reset

-  
The NCR53c710 SCSI chip has been reset and configure at id %d.

-  
SIOP interrupt: %x sts %x msg %x sbcl %x

-  
The NCR53c710 SCSI chip has interrupted unexpectedly.

-  
SIOP: SCSI Gross Error

-  
The NCR53c710 SCSI chip has indicated that it is confused.

-  
SIOP: Parity Error

-  
The NCR53c710 SCSI chip has indicated that it has detected a parity error
-      on the SCSI bus.

-

-

-

-

-
scsibus(4)

-

-

-

-
The afsc interface first appeared in
-    NetBSD 1.0

-

-

-
-  
-    
-    
-  
-
July 23, 1995NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/ahsc.4 3.html b/static/netbsd/man4/man4.amiga/ahsc.4 3.html
deleted file mode 100644
index 00386f7e..00000000
--- a/static/netbsd/man4/man4.amiga/ahsc.4 3.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
AHSC(4)Device Drivers Manual (amiga)AHSC(4)

-

-

-

-
ahsc — A3000 low
-    level SCSI interface

-

-

-

-
ahsc0 at mainbus0

-

-

-

-
The Amiga architecture uses a common machine independent scsi
-    sub-system provided in the kernel source. The machine independent drivers
-    that use this code access the hardware through a common interface. (see
-    scsibus(4)) This common interface interacts with a machine
-    dependent interface, such as ahsc, which then
-    handles the hardware specific issues.

-
The ahsc interface handles things such as
-    DMA and interrupts as well as actually sending commands, negotiating
-    synchronous or asynchronous transfers and handling disconnect/reconnect of
-    SCSI targets. The hardware that ahsc uses is based
-    on the WD33c93 SCSI chip.

-

-

-

-

-  
sbicwait TIMEO @%d with asr=x%x csr=x%x

-  
The 33c93 code (sbic) has been waiting too long for a SCSI chip operation
-      to complete. %d is the line in the source file
-      amiga/dev/sbic.c at which the SCSI chip timed-out.
-      Asr and csr are status registers within the SCSI chip.

-  
ahsc%d: abort %s: csr = 0x%02x, asr = 0x%02x

-  
A SCSI operation %s was aborted due to an error.

-  
ahsc%d: csr == 0x%02i

-  
A error has occurred within the SCSI chip code.

-  
ahsc%d: unexpected phase %d in icmd from %d

-  
The target described by ‘from %d’ has taken the SCSI bus
-      into a phase which is not expected during polled IO.

-  
ahsc%d: unexpected phase %d in icmd from %d

-  
The target described by ‘from %d’ has taken the SCSI bus
-      into a phase which is not expected during DMA IO setup.

-

-

-

-

-
scsibus(4)

-

-

-

-
The ahsc interface first appeared in
-    NetBSD 1.0

-

-

-
-  
-    
-    
-  
-
August 31, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/bppcsc.4 3.html b/static/netbsd/man4/man4.amiga/bppcsc.4 3.html
deleted file mode 100644
index 1fdab1dc..00000000
--- a/static/netbsd/man4/man4.amiga/bppcsc.4 3.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
BPPCSC(4)Device Drivers Manual (amiga)BPPCSC(4)

-

-

-

-
bppcsc —
-    BlizzardPPC 603e+ SCSI host adapter device
-  driver

-

-

-

-
bppcsc0 at p5bus0
-  

-  scsibus* at bppcsc?

-

-

-

-
The bppcsc driver provides support for the
-    SCSI controller present on Blizzard PPC 603e+ cards.

-

-

-

-
The bppcsc driver supports the following
-    hardware:

-

-

-  

-  
Phase5 BlizzardPPC 603e+ on-board SCSI, manufacturer 8512, product 110,
-      serial number starting with "I"

-

-

-

-

-

-
amiga/wesc(4), scsibus(4)

-

-

-

-
The bppcsc device first appeared in
-    NetBSD 6.0.

-

-

-

-
The bppcsc driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.
-    It was heavily based on the amiga/wesc(4) driver and uses
-    the siop machine-dependent backend, both written by Michael
-    L. Hitch.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/cv3dpb.4 3.html b/static/netbsd/man4/man4.amiga/cv3dpb.4 3.html
deleted file mode 100644
index 943ec868..00000000
--- a/static/netbsd/man4/man4.amiga/cv3dpb.4 3.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
CV3DPB(4)Device Drivers Manual (amiga)CV3DPB(4)

-

-

-

-
cv3dpb — Phase5
-    CyberVision 64/3D PCI bridge driver

-

-

-

-
cv3dpb* at zbus0
-  

-  pci* at cv3dpb?

-

-

-

-
The cv3dpb driver provides support for the
-    PCI bus present on CyberVision 64/3D graphics card. It allows using the S3
-    ViRGE present on this card as a usual PCI device.

-

-

-

-
The cv3dpb driver supports the following
-    hardware:

-

-

-  
Phase5 CyberVision 64/3D graphics card

-  
 

-  
DCE Computer CyberVision 64/3D Mk-II graphics card

-  
 

-

-

-

-

-

-
amiga/grfcv3d(4),
-    amiga/p5pb(4), pci(4)

-

-

-

-
The cv3dpb device first appeared in
-    NetBSD 6.0.

-

-

-

-
The cv3dpb driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.

-

-

-

-
Machine-independent driver for the S3 ViRGE does not exist
-  yet.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/drbbc.4 3.html b/static/netbsd/man4/man4.amiga/drbbc.4 3.html
deleted file mode 100644
index 302ebc7d..00000000
--- a/static/netbsd/man4/man4.amiga/drbbc.4 3.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRBBC(4)Device Drivers Manual (amiga)DRBBC(4)

-

-

-

-
drbbc — DraCo
-    on-board real-time clock

-

-

-

-
drbbc at mainbus0

-

-

-

-
The drbbc real-time clock driver provides
-    support for the Dallas DS2404 chip found in the DraCo from Macro System.

-

-

-

-
todr(9)

-

-

-

-
The drbbc device first appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
April 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/efa.4 3.html b/static/netbsd/man4/man4.amiga/efa.4 3.html
deleted file mode 100644
index 35787b17..00000000
--- a/static/netbsd/man4/man4.amiga/efa.4 3.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
EFA(4)Device Drivers Manual (amiga)EFA(4)

-

-

-

-
efa — ELBOX
-    FastATA 1200 IDE disk controller driver

-

-

-

-
efa0 at mainbus0

-

-

-

-
The efa driver provides support for the
-    FastATA 1200 family of IDE controllers and provides the interface with the
-    hardware for the ata(4) driver. PIO modes 0, 3, 4 and 5
-    are supported.

-

-

-

-
The efa driver supports the following
-    hardware:

-

-

-  

-  
 

-  

-  
 

-  

-  
 

-

-

-

-

-

-
ata(4), wdc(4)

-

-

-

-
The efa device first appeared in
-    NetBSD 6.0.

-

-

-

-
The efa driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.

-

-

-

-
Older versions of FastATA 1200 are NOT supported:

-

-

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
 

-

-

-
These devices do not generate hardware interrupts and need to be
-    driven in non-standard polling mode. Code needed to support it is present in
-    driver but does not work correctly.

-
Some of the above devices were also marketed under PowerFlyer and
-    Winner brands.

-
The onboard Gayle IDE controller can not be used when FastATA is
-    installed and therefore, the efa driver will not
-    coexist with wdc(4) driver attached to
-    mainbus(4). Both efa and
-    wdc(4) can be enabled in the same kernel, but only one
-    will attach (depending on the return value of probe function in the
-    efa driver).

-
DMA modes are not supported, this is a hardware limitation.

-

-

-

-
Performance is worse than with official AmigaOS driver from
-  ELBOX.

-
Disks partitioned in split mode, which is specific to official
-    AmigaOS FastATA driver, are not recognized in
-    NetBSD.

-

-

-
-  
-    
-    
-  
-
April 13, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/em4k.4 3.html b/static/netbsd/man4/man4.amiga/em4k.4 3.html
deleted file mode 100644
index f4ea9d20..00000000
--- a/static/netbsd/man4/man4.amiga/em4k.4 3.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
EM4K(4)Device Drivers Manual (amiga)EM4K(4)

-

-

-

-
em4k — ELBOX
-    Mediator 4000 PCI bridge driver

-

-

-

-
em4k0 at zbus0
-  

-  emmem0 at zbus0
-  

-  pci* at empb0
-  

-  options PCI_NETBSD_CONFIGURE

-

-

-

-
The em4k driver provides support for the
-    PCI bus present on Mediator 4000 bridge and associated PCI/Zorro
-    daughterboards.

-

-

-

-
The em4k driver supports the following
-    hardware:

-

-

-  
ELBOX Mediator PCI 4000D

-  
 

-  
ELBOX Mediator PCI 4000Di

-  
 

-  
ELBOX Mediator PCI 4000T

-  
 

-  
ELBOX Mediator PCI 3000D

-  
 

-  
ELBOX Mediator PCI 3000T

-  
 

-

-

-MK-II editions are also supported.
-

-

-

-
amiga/empb(4), amiga/mppb(4),
-    amiga/p5pb(4), pci(4)

-

-

-

-
The em4k device first appeared in
-    NetBSD 7.0.

-

-

-

-
The em4k driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.
-    It was developed using information obtained through reverse engineering by
-    Frank Wille and Radoslaw
-    Kujawa. The authors have no access to official documentation (which
-    is only available under NDA).

-

-

-

-
DMA to host memory is not supported. It is unclear if the hardware
-    supports DMA to host memory at all. It is possible to implement DMA through
-    bounce buffers in graphics card memory, but this needs further research.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/grfcv3d.4 3.html b/static/netbsd/man4/man4.amiga/grfcv3d.4 3.html
deleted file mode 100644
index 4855c2e2..00000000
--- a/static/netbsd/man4/man4.amiga/grfcv3d.4 3.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
GRFCV3D(4)Device Drivers Manual (amiga)GRFCV3D(4)

-

-

-

-
grfcv3d —
-    8/15/16/24/32-bit color graphics driver

-

-

-

-
grfcv3d0 at zbus0
-  

-  grf7 at grfcv3d0
-  

-  ite7 at grf7
-  

-  wsdisplay* at grf7

-

-

-

-
The grfcv3d device driver supports
-    graphics boards with the S3 Virge chipset. It supports the minimal ioctl's
-    needed to run X11.

-

-

-

-
The grfcv3d interface supports the
-    following ZorroII/III expansion card:

-

-

-  

-  
A Zorro II/III card. From phase5, manufacturer 8512, product 67.

-

-

-

-

-

-

-  
/dev/grf7

-  
graphics interface special file

-  
/dev/ttye7

-  
console interface special file for the internal terminal emulator

-

-

-

-

-
amiga/console(4),
-    amiga/grfcv(4), amiga/ite(4),
-    amiga/grfconfig(8)

-

-

-

-
The grfcv3d interface first appeared in
-    NetBSD 1.3. It was modified for
-    NetBSD 6.0 to support wsdisplay(4)
-    interface.

-

-

-

-
The grfcv3d driver was written by
-    Tobias Abt based on amiga/grfcv(4)
-    driver. Bernd Ernesti. fixed multiple bugs and later
-    maintained the driver. The wsdisplay(4) interface was
-    added by Frank Wille and Radoslaw
-    Kujawa.

-

-

-

-
grfcv3d does not support the sync-on-green
-    flag from amiga/grfconfig(8).

-
The wsdisplay(4) interface does not support all
-    functionality provided by the driver and it can not be used at the same time
-    as amiga/ite(4). X11 is not supported with
-    wsdisplay(4). It needs more testing.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/grfrh.4 3.html b/static/netbsd/man4/man4.amiga/grfrh.4 3.html
deleted file mode 100644
index b50fa5d2..00000000
--- a/static/netbsd/man4/man4.amiga/grfrh.4 3.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
GRFRH(4)Device Drivers Manual (amiga)GRFRH(4)

-

-

-

-
grfrh —
-    8/16/24-bit color graphics driver

-

-

-

-
grfrh0 at zbus0
-  

-  grf2 at grfrh0
-  

-  ite2 at grf2

-

-

-

-
The grfrh device driver supports graphics
-    boards with the NCR 77C32BLT chipset. It supports the minimal ioctl's needed
-    to run X11.

-

-

-

-
The grfrh interface supports the following
-    expansion cards:

-

-

-  

-  
A Zorro III only card. From Macro System, manufacturer 18260, product
-    16.

-  

-  
A DraCo local bus only card. From Macro System, manufacturer 18260,
-      product 19.

-

-

-

-

-

-

-  
/dev/grf2

-  
graphics interface special file

-  
/dev/ttye2

-  
console interface special file for the internal terminal emulator

-

-

-

-

-
amiga/console(4),
-    amiga/ite(4), amiga/grfconfig(8)

-

-

-

-
The grfrh interface first appeared in
-    NetBSD 1.0.

-

-

-

-
grfrh does not allow setting graphics
-    modes with amiga/grfconfig(8).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/grful.4 3.html b/static/netbsd/man4/man4.amiga/grful.4 3.html
deleted file mode 100644
index fb503bb6..00000000
--- a/static/netbsd/man4/man4.amiga/grful.4 3.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
GRFUL(4)Device Drivers Manual (amiga)GRFUL(4)

-

-

-

-
grful — 8-bit
-    color graphics driver

-

-

-

-
grful* at zbus0
-  

-  grf4 at grful?
-  

-  ite4 at grf4

-

-

-

-
The grful is a driver for the A2410, a
-    TMS34010 based color graphics board. It supports the minimal ioctl's needed
-    to run X11, but doesn't provide a mappable framebuffer, so special X servers
-    are needed.
-  

-  A standard ITE terminal emulator is supported on one of the overlay
-  planes.

-

-

-

-
The grful interface supports the following
-    ZorroII expansion card:

-

-

-  

-  
A Zorro II only card with the TMS34010 processor. From the University of
-      Lowell, manufacturer 1030, product 0.

-

-

-

-

-

-

-  
/dev/grf4

-  
graphics interface special file

-  
/dev/grfim4

-  
graphics interface special file for accessing images

-  
/dev/grfov4

-  
graphics interface special file for overlays

-  
/dev/ttye4

-  
console interface special file for the internal terminal emulator

-

-

-

-

-
amiga/console(4),
-    amiga/ite(4), amiga/grfconfig(8)

-

-

-

-
The grful interface first appeared in
-    NetBSD 1.1.

-

-

-

-
grful does not allow setting graphics
-    modes with amiga/grfconfig(8).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/intro.4 2.html b/static/netbsd/man4/man4.amiga/intro.4 2.html
deleted file mode 100644
index fe9afdb2..00000000
--- a/static/netbsd/man4/man4.amiga/intro.4 2.html	
+++ /dev/null
@@ -1,147 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (amiga)INTRO(4)

-

-

-

-
intro —
-    introduction to amiga special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Amiga.
-    Software support for these devices comes in two forms. A hardware device may
-    be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    amiga/autoconf(4). A list of the supported devices is
-    given below.

-

-

-

-
config(1),
-  amiga/autoconf(4)

-

-

-

-
The Amiga intro man page first appeared in
-    NetBSD 1.1

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-  

-  
A4091 low level SCSI adapter interface

-  

-  
A3000 low level SCSI adapter interface

-  

-  
A2091 low level SCSI adapter interface

-  

-  
DP8390-based Ethernet interface

-  

-  
SMC91C90-based Ethernet interface

-  

-  
Floppy disk controller device

-  

-  
Floppy disk device

-  

-  
frame buffer for Custom Chips and graphics cards

-  

-  
color graphics driver for GVP Spectrum/Picasso II, II+ and
-      IV/Piccolo/Piccolo SD64 cards

-  

-  
color graphics driver for the Cybervision 64

-  

-  
color graphics driver for the Cybervision 64/3D

-  

-  
color graphics driver for Domino/Domino16M proto/oMniBus/Merlin cards

-  

-  
color graphics driver for the A2410

-  

-  
color graphics driver for Retina BLT Z3 and Altais cards

-  

-  
color graphics driver for the Retina Z2

-  

-  
GVP low level SCSI adapter interface

-  

-  
GVP custom bus

-  

-  
Amiga Keyboard device

-  

-  
kernel virtual memory

-  

-  
Amiga Internal Terminal Emulator

-  

-  
IVS low level SCSI adapter interface

-  

-  
AMD 7990 and AMD 79C960 Lance-based Ethernet interface

-  

-  
physical memory

-  

-  
MultiFaceCard II/II serial interface

-  

-  
Magnum 40 low level SCSI adapter interface

-  

-  
12 Gauge low level SCSI adapter interface

-  

-  
8520 built-in parallel interface

-  

-  
8520 built-in serial interface

-  

-  
Warp Engine low level SCSI adapter interface

-  

-  
Wordsync II low level SCSI adapter interface

-  

-  
Zeus low level SCSI adapter interface

-  

-  
Amiga Zorro II/III bus

-

-

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/mfcs.4 3.html b/static/netbsd/man4/man4.amiga/mfcs.4 3.html
deleted file mode 100644
index e04dbf74..00000000
--- a/static/netbsd/man4/man4.amiga/mfcs.4 3.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
MFCS(4)Device Drivers Manual (amiga)MFCS(4)

-

-

-

-
mfcs —
-    BSC/AlfaData MultiFaceCard II/III serial communications
-    interface

-

-

-

-
mfc0 at mainbus0
-  

-  mfcs0 at mfc0 unit 0
-  

-  mfcs1 at mfc0 unit 1

-

-

-

-
The MultiFaceCard II/III controls, among other things, a dual port
-    EIA RS-232C (CCITT V.28) communications interface with a multiple character
-    buffer.

-
Input and output for each MultiFaceCard III line may set to a
-    maximum baud rates of 1152000. Formula for baud rate: Baud = 230400 / N with
-    1 < N < 65536.

-
Input and output for each MultiFaceCard II line may set to a
-    maximum baud rates of 57600. Formula for baud rate: Baud = 115200 / N with 1
-    < N < 65536.

-

-

-

-

-  
/dev/ttyA?

-  
 

-

-

-

-

-

-  
mfcs0: fifo overflow.

-  
The four-character input “fifo” has overflowed and incoming
-      data has been lost.

-  
mfcs0: %d buffer overflows.

-  
The software based input ring buffer has overflowed %d times and incoming
-      data has been lost.

-

-

-

-

-
tty(4)

-

-

-

-
The Amiga mfcs device first appeared in
-    NetBSD 1.1

-

-

-

-
The MultiFaceCard II/III serial ports use the level 6 interrupt
-    and may experience fifo overflows if the LEV6_DEFER option is used.

-

-

-
-  
-    
-    
-  
-
July 23, 1995NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/p5pb.4 3.html b/static/netbsd/man4/man4.amiga/p5pb.4 3.html
deleted file mode 100644
index 4a2e3e46..00000000
--- a/static/netbsd/man4/man4.amiga/p5pb.4 3.html	
+++ /dev/null
@@ -1,91 +0,0 @@
-
-  
-    
-    
-    
-  
-
P5PB(4)Device Drivers Manual (amiga)P5PB(4)

-

-

-

-
p5pb — Phase5 PCI
-    bridge driver

-

-

-

-
p5pb0 at p5bus0
-  

-  pci* at p5pb?
-  

-  genfb* at pci?
-  

-  voodoofb* at pci?
-  

-  options P5PB_DEBUG
-  

-  options P5PB_CONSOLE

-

-

-

-
The p5pb driver provides support for the
-    PCI bus present on various devices equipped with the Phase5 PCI bridge.

-
The P5PB_CONSOLE option activates the
-    necessary support for the console on CyberVisionPPC and BlizzardVisionPPC,
-    allowing the attachment of the genfb(4) driver. 3Dfx
-    Voodoo 3 boards installed in G-REX are also supported as console by this
-    option in conjunction with the voodoofb(4) driver.

-
Additional, excessive debugging output is enabled by the
-    P5PB_DEBUG option.

-

-

-

-
The p5pb driver supports the following
-    hardware:

-

-
    
-  
  • Phase5 BlizzardVisionPPC graphics card
    • 
-  
  • Phase5 CyberVisionPPC graphics card
    • 
-  
  • DCE Computer G-REX 1200
    • 
-  
  • DCE Computer G-REX 4000
    • 
-

-

-

-

-
amiga/cv3dpb(4),
-    amiga/p5membar(4), genfb(4),
-    pci(4)

-
Programming
-    the G-REX PCI bridge

-

-

-

-
The p5pb device first appeared in
-    NetBSD 6.0.

-

-

-

-
The p5pb driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.

-

-

-

-
The NetBSD developers don't have access to
-    G-REX hardware or documentation. Support for this device is based on best
-    wishes.

-
Support for genfb(4) framebuffer on CVPPC/BVPPC
-    needs more testing.

-

-

-

-
DMA to host memory is not supported. This is a driver
-  limitation.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/xsh.4 3.html b/static/netbsd/man4/man4.amiga/xsh.4 3.html
deleted file mode 100644
index 20b2a2c9..00000000
--- a/static/netbsd/man4/man4.amiga/xsh.4 3.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
XSH(4)Device Drivers Manual (amiga)XSH(4)

-

-

-

-
xsh — Individual
-    Computers X-Surf 100 driver

-

-

-

-
xsh* at zbus0
-  

-  ne* at xshbus?
-  

-  ukphy* at mii? phy ?

-

-

-

-
The xsh driver provides support for
-    ethernet interface present on the Individual Computers X-Surf 100 card. It
-    acts as a bus attachment layer for the machine independent
-    ne(4) driver, which supports the AX88796 chip.

-

-

-

-
The xsh driver supports the following
-    hardware:

-

-

-  
Individual Computers X-Surf 100

-  
 

-

-

-

-

-

-
amiga/xsurf(4), mii(4),
-    ne(4)

-
X-Surf
-    100 on Individual Computers wiki

-

-

-

-
The xsh device first appeared in
-    NetBSD 7.0.

-

-

-

-
The xsh driver was written by
-    Radoslaw Kujawa
-    ⟨radoslaw.kujawa@gmail.com⟩.

-

-

-

-
The RapidRoad USB module is not supported (yet).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.amiga/zssc.4 3.html b/static/netbsd/man4/man4.amiga/zssc.4 3.html
deleted file mode 100644
index d22c94a4..00000000
--- a/static/netbsd/man4/man4.amiga/zssc.4 3.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZSSC(4)Device Drivers Manual (amiga)ZSSC(4)

-

-

-

-
zssc — Zeus low
-    level SCSI interface

-

-

-

-
zssc0 at zbus0

-

-

-

-
The Amiga architecture uses a common machine independent scsi
-    sub-system provided in the kernel source. The machine independent drivers
-    that use this code access the hardware through a common interface. (see
-    scsibus(4)) This common interface interacts with a machine
-    dependent interface, such as zssc, which then
-    handles the hardware specific issues.

-
The zssc interface handles things such as
-    DMA and interrupts as well as actually sending commands, negotiating
-    synchronous or asynchronous transfers and handling disconnect/reconnect of
-    SCSI targets. The hardware that zssc uses is based
-    on the NCR53c710 SCSI chip.

-

-

-

-

-  
zssc%s: abort %s: dstat %02x, sstat0 %02x sbcl %02x

-  
The scsi operation %s was aborted due to error. Dstat, sstat and sbcl are
-      registers within the NCR53c710 SCSI chip.

-  
siop id %d reset

-  
The NCR53c710 SCSI chip has been reset and configure at id %d.

-  
SIOP interrupt: %x sts %x msg %x sbcl %x

-  
The NCR53c710 SCSI chip has interrupted unexpectedly.

-  
SIOP: SCSI Gross Error

-  
The NCR53c710 SCSI chip has indicated that it is confused.

-  
SIOP: Parity Error

-  
The NCR53c710 SCSI chip has indicated that it has detected a parity error
-      on the SCSI bus.

-

-

-

-

-
scsibus(4)

-

-

-

-
The zssc interface first appeared in
-    NetBSD 1.0

-

-

-
-  
-    
-    
-  
-
August 31, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/man4.arc/intro.4 3.html b/static/netbsd/man4/man4.arc/intro.4 3.html
deleted file mode 100644
index c80c8552..00000000
--- a/static/netbsd/man4/man4.arc/intro.4 3.html	
+++ /dev/null
@@ -1,183 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (arc)INTRO(4)

-

-

-

-
intro —
-    introduction to special files and hardware
-  support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported by
-    NetBSD/arc. Software support for these devices comes
-    in two forms. A hardware device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), autoconf(4)

-

-

-

-
NetBSD/arc supports a variety of systems
-    conforming to the ARC machine specification. The following systems are
-    supported:

-

-

-

-  
Acer PICA

-  
 

-  
DESKstation rPC44

-  
 

-  
DESKstation Tyne

-  
 

-  
MIPS Magnum 4000

-  
 

-  
NEC Express 5800/230 PCI R4K

-  
 

-  
NEC Express 5800/240 EISA R4K

-  
 

-  
NEC Express RISCserver

-  
 

-  
NEC ImageRISCstation

-  
 

-  
NEC RISCserver 2200

-  
 

-  
NEC RISCstation 2200 EISA

-  
 

-  
NEC RISCstation 2200 PCI

-  
 

-  
NEC RISCstation 2250

-  
 

-

-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-

-  
arcsisabr

-  
DESKstation rPC44 ISA host bridge

-  
jazzio

-  
Jazz internal bus host bridge

-  
jazzisabr

-  
Jazz ISA/EISA bus bridge

-  
necpb

-  
NEC RISCstation PCI host bridge

-  
tyneisabr

-  
DESKstation Tyne ISA host bridge

-

-

-
The following devices on the Jazz internal bus are supported.

-

-

-

-  
asc

-  
NCR 53c9x-based SCSI interface

-  
com

-  
NS16550-based serial communications interface

-  
fdc

-  
Floppy disk controller

-  
lpt

-  
Parallel port

-  
mcclock

-  
DS1287 real-time clock

-  
oosiop

-  
Symbios/NCR 53c700-based SCSI interface

-  
osiop

-  
Symbios/NCR 53c710-based SCSI interface

-  
pckbc

-  
PC keyboard controller

-  
sn

-  
SONIC Ethernet

-  
timer

-  
Interval timer

-  
vga

-  
VGA graphics

-

-

-
PCI devices are supported through the pci(4) bus
-    and associated device drivers.

-
ISA devices are supported through the isa(4) bus
-    and associated device drivers.

-
Console devices using ISA, Jazzio, or PCI video adaptors and
-    standard AT or PS/2 keyboards are supported by the machine independent
-    wscons(4) console driver.

-

-

-

-
The following devices are not supported, due to unavailability of
-    either documentation or sample hardware:

-

-

-

-  
AD1848 audio on Jazzio

-  
 

-  
EISA devices

-  
 

-  
VXL framebuffer on MIPS Magnum and RISCstation 2200 EISA

-  
 

-

-

-

-

-

-
This arc intro appeared in
-    NetBSD 2.0.

-

-

-

-
DESKstation rPC44 and Tyne support is currently broken.

-

-

-
-  
-    
-    
-  
-
April 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/man4.atari/floppy.4 3.html b/static/netbsd/man4/man4.atari/floppy.4 3.html
deleted file mode 100644
index 38ae8b71..00000000
--- a/static/netbsd/man4/man4.atari/floppy.4 3.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
FLOPPY(4)Device Drivers Manual (atari)FLOPPY(4)

-

-

-

-
floppy — Atari
-    floppy interface

-

-

-

-
fd0 at fdc0 unit 0
-  

-  fd1 at fdc0 unit 1

-

-

-

-
This is an interface to the builtin and external floppy drives on
-    the Atari. Currently, there is no disklabel support for the floppy drives.
-    Instead, the floppy interface uses the partition number embedded in the
-    minor device number to distinguish between various floppy formats.

-
Currently, the following formats are supported:

-
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-
a360Kb1809
b720Kb2809
c1.44Mb28018

-

-

-

-

-  
/dev/fd[01][abc]

-  
Block files

-  
/dev/rfd[01][abc]

-  
Raw files

-

-

-

-

-
None.

-

-

-
-  
-    
-    
-  
-
October 15, 1995NetBSD 10.1

diff --git a/static/netbsd/man4/man4.atari/intro.4 2.html b/static/netbsd/man4/man4.atari/intro.4 2.html
deleted file mode 100644
index cdc6bbb4..00000000
--- a/static/netbsd/man4/man4.atari/intro.4 2.html	
+++ /dev/null
@@ -1,133 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (atari)INTRO(4)

-

-

-

-
intro —
-    introduction to atari special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each
-    configurable device gives a sample specification for use in constructing a
-    system description for the config(1) program. The
-    DIAGNOSTICS section lists messages which may appear on the console and/or in
-    the system error log /var/log/messages due to errors
-    in device operation; see syslogd(8) for more
-  information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
Platforms supported by the atari port:

-

-

-  
TT030

-  
A standard TT030 model with at least 4Mb of RAM.

-  
Falcon

-  
A standard Falcon with at least 4Mb of RAM. An FPU is not required as the
-      default kernels include FP-emulation support.

-  
Hades

-  
A standard Hades with either an 040 or 060 processor and at least 8 Mb of
-      RAM.

-

-

-

-

-

-
This section describes the hardware supported on the atari
-    (atari-clone) platform. Software support for these devices comes in two
-    forms. A hardware device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed, not all devices exist on all models.

-
Standard builtin devices:

-

-

-  
clock

-  
System clock

-  
fd

-  
Floppy device as found on the Falcon/TT030

-  
grf

-  
The standard internal video as found on the Falcon and TT030.

-  
grfet

-  
The et4000-PCI video as found on the HADES

-  
hdfd

-  
Floppy device as found on the Hades (NEC 765 compatible)

-  
isa

-  
ISA I/O bus (Hades only)

-  
kbd

-  
Standard keyboard

-  
lpt

-  
Parallel port device interface

-  
mem

-  
Main memory interface

-  
ncrscsi

-  
Onboard 5380 SCSI-bus

-  
nvr

-  
Non-volatile RAM interface

-  
pci

-  
PCI I/O bus (Hades only).

-  
ser0

-  
Serial1 (when connector available).

-  
vme

-  
VME I/O bus

-  
wd

-  
IDE interface (not on TT030)

-  
zs0

-  
Serial2 and modem2 ports.

-

-

-

-

-

-
config(1), autoconf(4),
-    netintro(4)

-

-

-

-
The atari intro appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
June 6, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/man4.atari/rtc.4 3.html b/static/netbsd/man4/man4.atari/rtc.4 3.html
deleted file mode 100644
index 7eee236a..00000000
--- a/static/netbsd/man4/man4.atari/rtc.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTC(4)Device Drivers Manual (atari)RTC(4)

-

-

-

-
rtc — Atari Real
-    Time Clock

-

-

-

-
clock0 at mainbus0

-

-

-

-
The rtc driver supports reading from and
-    writing to the Atari real time clock (RTC). When reading from the RTC, the
-    format string of the output, as described in the
-    strftime(3) manual page, is:

-

-
``%Y%m%d%H%M.%S''

-

-
The same format is used to set the RTC to the current date. Note
-    that the kernel expects the RTC to run in UTC.

-

-

-

-

-  
/dev/rtc

-  
 

-

-

-

-

-
date -u +%Y%m%d%H%M.%S > /dev/rtc

-

-

-

-
date(1), strftime(3)

-

-

-
-  
-    
-    
-  
-
November 21, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/man4.dreamcast/intro.4 3.html b/static/netbsd/man4/man4.dreamcast/intro.4 3.html
deleted file mode 100644
index 9566e7ab..00000000
--- a/static/netbsd/man4/man4.dreamcast/intro.4 3.html	
+++ /dev/null
@@ -1,104 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (dreamcast)INTRO(4)

-

-

-

-
intro —
-    introduction to dreamcast special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Dreamcast
-    platform. Software support for these devices come in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time, it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-
Standard builtin devices:

-

-

-  
g2bus

-  
“G2” internal I/O bus

-  
gapspci

-  
PCI bridge used in expansion port peripherals

-  
gdrom

-  
Builtin GD-ROM optical disc drive

-  
pvr

-  
Framebuffer device using the builtin NEC PVR graphics subsystem

-  
aica

-  
Builtin AICA sound system

-

-

-
Controller port peripherals are supported though the
-    dreamcast/maple(4) bus and associated device drivers.

-
Network interfaces:

-

-

-  
rtk

-  
Ethernet driver for the HIT-0400 Broadband Adapter

-  
mbe

-  
Ethernet driver for the HIT-0300 LAN Adapter

-

-

-

-

-

-
config(1), autoconf(4),
-    netintro(4)

-

-

-

-
The intro man page appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.dreamcast/maple.4 3.html b/static/netbsd/man4/man4.dreamcast/maple.4 3.html
deleted file mode 100644
index fc664675..00000000
--- a/static/netbsd/man4/man4.dreamcast/maple.4 3.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAPLE(4)Device Drivers Manual (dreamcast)MAPLE(4)

-

-

-

-
maple — Maple bus
-    driver

-

-

-

-
maple0 at shb?

-

-

-

-
The maple driver provides support for
-    controlling the Maple bus (controller ports).

-

-

-

-
The following ioctl(2) calls apply to Maple bus
-    devices.

-

-  

-    struct maple_devinfo

-  
Read, from the kernel, the device information of the device.
-    

-    
struct maple_devinfo {
-	uint32_t di_func;
-	uint32_t di_function_data[3];
-	uint8_t di_area_code;
-	uint8_t di_connector_direction;
-	char di_product_name[30];
-	char di_product_license[60];
-	uint16_t di_standby_power;
-	uint16_t di_max_power;
-};

-    

-  

-

-

-

-

-

-  
/dev/maplePs

-  
Maple bus device at port P (A-D), subunit
-      s (null for base device, 1-5 for expansion
-    device)

-

-

-

-

-
dreamcast/mkbd(4),
-    dreamcast/mlcd(4), dreamcast/mmem(4),
-    dreamcast/mms(4)

-

-

-

-
The maple device driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.dreamcast/mlcd.4 3.html b/static/netbsd/man4/man4.dreamcast/mlcd.4 3.html
deleted file mode 100644
index 770e9a83..00000000
--- a/static/netbsd/man4/man4.dreamcast/mlcd.4 3.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
MLCD(4)Device Drivers Manual (dreamcast)MLCD(4)

-

-

-

-
mlcd — Maple bus
-    monochrome LCD driver

-

-

-

-
mlcd* at maple? port ? subunit ?

-

-

-

-
The mlcd driver provides support for Maple
-    bus monochrome LCDs (liquid crystal displays).

-

-

-

-
Maple bus LCDs accept all ioctl(2) calls
-    described in dreamcast/maple(4).

-

-

-

-

-  
/dev/mlcdu.t

-  
Maple bus LCD device unit u, PT number
-      t (usually 0 only)

-

-

-

-

-
ioctl(2),
-  dreamcast/maple(4)

-

-

-

-
The mlcd device driver appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.emips/autoconf.4 3.html b/static/netbsd/man4/man4.emips/autoconf.4 3.html
deleted file mode 100644
index cb218533..00000000
--- a/static/netbsd/man4/man4.emips/autoconf.4 3.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (emips)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel. Devices which
-    exist in the machine but are not configured into the kernel are not
-    detected.

-

-

-

-

-  
CPU type (0x%x) not supported.

-  
You tried to boot NetBSD on a type of CPU type
-      which it doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-

-

-

-

-
config(1), emips/intro(4),
-    boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.emips/ebus.4 3.html b/static/netbsd/man4/man4.emips/ebus.4 3.html
deleted file mode 100644
index 6a4fc7de..00000000
--- a/static/netbsd/man4/man4.emips/ebus.4 3.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
EBUS(4)Device Drivers Manual (emips)EBUS(4)

-

-

-

-
ebus — eMIPS
-    Extensible I/O BUS driver

-

-

-

-
ebus0 at mainbus0

-

-

-

-
ebus is a virtual device for the
-    Extensible I/O BUS realized with eMIPS on FPGA boards such as the BEE3,
-    Xilinx XUP, and Xilinx ML40x systems.

-
Devices on the BUS can generally be relocated and can be found by
-    scanning the Peripheral Mapping Table at the top of the BUS physical space.
-    The driver is responsible for identifying devices that are currently
-    available, and to map them into the kernel virtual space during the kernel
-    startup procedure.

-
The ebus driver manages the Extensible I/O
-    BUS on eMIPS and provides

-
    
-  
  • Address range management to avoid conflicts.
    • 
-  
  • Interrupt vector management.
    • 
-  
  • Other utility functions.
    • 
-

-
ebus is always required to run the
-    NetBSD kernel.

-

-

-

-
emips/ace(4), emips/dz(4),
-    emips/eclock(4), emips/enic(4),
-    emips/intro(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.emips/enic.4 3.html b/static/netbsd/man4/man4.emips/enic.4 3.html
deleted file mode 100644
index d0f33e9b..00000000
--- a/static/netbsd/man4/man4.emips/enic.4 3.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
ENIC(4)Device Drivers ManualENIC(4)

-

-

-

-
enic — eMIPS
-    ExtensibleNIC Ethernet interface driver

-

-

-

-
enic* at ebus0 addr ?

-

-

-

-
The enic interface provides access to an
-    Ethernet network via the eMIPS builtin eNIC (Extensible Network Interface
-    Controller - Ethernet) interface.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    enic interface employs the Address Resolution
-    Protocol (ARP) described in arp(4) to dynamically map
-    between Internet and Ethernet addresses on the local network.

-
Multicast Ethernet frames are unconditionally received and must be
-    filtered in software.

-

-

-

-

-

-
The ENIC interface is present on the BEE3 and Xilinx XUP boards.
-    The interface speed is wired at 1Gbps.

-

-

-

-

-

-  
enic%d: enic_put: no mem?

-  
The driver could not allocate a transmit buffer, packet was not sent.

-  
enic%d: internal error

-  
This and other messages are indicative of bad hardware or software driver
-      coding errors.

-

-

-

-

-
arp(4), emips/intro(4),
-    ifmedia(4), inet(4),
-    ifconfig(8)

-

-

-

-
enic driver first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbarm/awge.4 3.html b/static/netbsd/man4/man4.evbarm/awge.4 3.html
deleted file mode 100644
index 5563cc0f..00000000
--- a/static/netbsd/man4/man4.evbarm/awge.4 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
AWGE(4)Device Drivers ManualAWGE(4)

-

-

-

-
awge — DesignWare
-    Gigabit Ethernet

-

-

-

-
awge* at fdt?

-

-

-

-
The awge driver provides support for the
-    DesignWare GMAC Ethernet.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    ifconfig(8)

-
Synopsys,
-    DesignWare Ethernet GMAC IP,
-    https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_mac10_100_1000_unive,
-    April, 2019.

-

-

-

-
The name awge was chosen due to the
-    hardware appearing in Allwinner boards, but awge is
-    in use in boards by other manufacturers, e.g., Rockchip.

-
The awge device driver was written by
-    Matt Thomas and Martin
-    Husemann. It first appeared in NetBSD
-  7.0.

-

-

-
-  
-    
-    
-  
-
March 22, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbarm/cpsw.4 3.html b/static/netbsd/man4/man4.evbarm/cpsw.4 3.html
deleted file mode 100644
index e3b83f6b..00000000
--- a/static/netbsd/man4/man4.evbarm/cpsw.4 3.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPSW(4)Device Drivers ManualCPSW(4)

-

-

-

-
cpsw — Texas
-    Instruments CPSW 3-port Ethernet Switch

-

-

-

-
cpsw* at obio?

-

-

-

-
The cpsw driver supports the TI AM335x
-    3-port Ethernet Switch subsystem.

-

-

-

-
ifmedia(4), mii(4),
-    ifconfig(8)

-

-

-

-
The cpsw driver appeared in
-    NetBSD 7.0.

-

-

-

-
Jonathan A. Kollasch
-    ⟨jakllsch@NetBSD.org⟩

-

-

-
-  
-    
-    
-  
-
December 2, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbarm/gxio.4 3.html b/static/netbsd/man4/man4.evbarm/gxio.4 3.html
deleted file mode 100644
index 7767dcf2..00000000
--- a/static/netbsd/man4/man4.evbarm/gxio.4 3.html	
+++ /dev/null
@@ -1,136 +0,0 @@
-
-  
-    
-    
-    
-  
-
GXIO(4)Device Drivers ManualGXIO(4)

-

-

-

-
gxio — driver for
-    Gumstix onboard I/O interface

-

-

-

-
gxio* at pxaip?
-  

-  options GXIO_BLUETOOTH_ON_HWUART
-  

-  options GXIO_DEFAULT_EXPANSION

-

-

-

-
The gxio driver supports several different
-    expansion boards. Those boards have to be configured either by kernel option
-    or using boot time parameter. The supported extension boards is system
-    specific.

-
gxio is available for XScale based Gumstix
-    boards. To setup the expansion board on boot the parameter
-    “expansion” can be used. Additionally, some XScale systems can
-    connect two expansion boards. The second board can be configured by the
-    “busheader” boot parameter. The gxio
-    driver does not verify validity of both parameters.

-
For Xscale boards the following drivers are available for the
-    peripherals:

-

-

-  
sm

-  
SMC91Cxx ethernet interface.

-  
smsh

-  
SMSC LAN9118/LAN9218 ethernet interface.

-

-

-

-

-

-

-

-  

-  
Uses HWUART pins for Bluetooth module.
-    
The option only affects Xscale PXA250 based Gumstix boards. If
-        set, the serial port HWUART is used to control Bluetooth module.
-        Otherwise no Bluetooth module is configured for PXA250 boards.

-  

-  

-  
Static configuration of expansion board.
-    
If configured, the gxio of the
-        processor is setup for the board. If a boot parameter is used, the boot
-        value is used instead.

-    
For Xscale based boards the following values are
-      supported:

-    
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-    
basix
cfstix
etherstix
netcf
netcf-vx
netduo
netduo-mmc
netmicrosd
netmicrosd-vx
netwifimicrosd
netmmc
netpro-vx
wfistix
wfistix-cf

-  

-

-

-

-

-

-
pxaip(4), sm(4),
-    smsh(4)

-

-

-

-
The gxio driver first appeared in
-    NetBSD 4.0.

-

-

-

-
The gxio driver was written by
-    Takashi Kiyohara
-    <kiyohara@NetBSD.org>
-    and Susumu Miki for WIDE Project and SOUM
-    Corporation. This manual page was contributed by
-    Stephan Meisinger.

-

-

-
-  
-    
-    
-  
-
October 29, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbarm/iopaau.4 3.html b/static/netbsd/man4/man4.evbarm/iopaau.4 3.html
deleted file mode 100644
index eed54864..00000000
--- a/static/netbsd/man4/man4.evbarm/iopaau.4 3.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOPAAU(4)Device Drivers Manual (evbarm)IOPAAU(4)

-

-

-

-
iopaau — Intel I/O
-    Processor Application Accelerator Unit

-

-

-

-
iopxs* at mainbus?
-  

-  iopaau* at iopxs?

-

-

-

-
The Application Accelerator Unit, or AAU, provides
-    hardware-assisted support for performing block fills on a region of memory,
-    XOR of multiple regions of memory (parity computation), and parity
-    verification.

-
The iopaau driver supports the Application
-    Accelerator Units on the following Intel I/O Processors:

-
    
-  
  • Intel i80321 I/O Processor
    • 
-

-
The iopaau driver provides a back-end to
-    the dmover(9) interface, and supports the following
-    dmover(9) functions:

-

-  
zero

-  
Zero a region of memory

-  
fill8

-  
Fill a region of memory with an 8-bit value

-  
copy

-  
Copy a region of memory

-  
xor2

-  
Perform an XOR of 2 input streams

-  
xor3

-  
Perform an XOR of 3 input streams

-  
xor4

-  
Perform an XOR of 4 input streams

-  
xor5

-  
Perform an XOR of 5 input streams

-  
xor6

-  
Perform an XOR of 6 input streams

-  
xor7

-  
Perform an XOR of 7 input streams

-  
xor8

-  
Perform an XOR of 8 input streams

-

-

-

-

-
dmover(9)

-

-

-

-
The iopaau device first appeared in
-    NetBSD 2.0.

-

-

-

-
The iopaau driver was written by
-    Jason R. Thorpe
-    <thorpej@wasabisystems.com>
-    and contributed by Wasabi Systems, Inc.

-

-

-

-
Due to limitations in how scatter-gather is done by the AAU
-    hardware, a given DMA segment must be the same length for the output stream
-    and each input stream. The easiest way to achieve this is to ensure that all
-    streams used in an AAU operation begin at the same offset into a page.

-

-

-
-  
-    
-    
-  
-
August 2, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbarm/vcaudio.4 3.html b/static/netbsd/man4/man4.evbarm/vcaudio.4 3.html
deleted file mode 100644
index 1d1c24df..00000000
--- a/static/netbsd/man4/man4.evbarm/vcaudio.4 3.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
VCAUDIO(4)Device Drivers ManualVCAUDIO(4)

-

-

-

-
vcaudio — Broadcom
-    VideoCore integrated audio device driver

-

-

-

-
vcaudio* at vchiq?

-

-

-

-
The vcaudio driver provides support for
-    the VideoCore 4 audio interface found on Broadcom SoCs used in boards such
-    as the Raspberry Pi.

-
Three outputs are supported: auto,
-    headphones, and hdmi. The
-    selected output can be changed using the
-    outputs.select mixerctl(1)
-    variable. headphones corresponds to the analog 3.5mm
-    jack on the Raspberry Pi.

-
The hardware does not support recording.

-

-

-

-
mixerctl(1), audio(4),
-    mixer(4), vchiq(4)

-

-

-

-
The vcaudio device driver appeared in
-    NetBSD 7.0.

-

-

-

-
The playback block size is fixed at 40ms of audio. The hardware
-    output format is fixed at stereo 48kHz 16-bit LPCM so is not configurable
-    with audiocfg(1).

-

-

-
-  
-    
-    
-  
-
February 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbmips/cnmac.4 3.html b/static/netbsd/man4/man4.evbmips/cnmac.4 3.html
deleted file mode 100644
index e3a91c87..00000000
--- a/static/netbsd/man4/man4.evbmips/cnmac.4 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
CNMAC(4)Device Drivers Manual (evbmips)CNMAC(4)

-

-

-

-
cnmac — Cavium
-    OCTEON gigabit Ethernet driver

-

-

-

-
cnmac* at octgmx?

-

-

-

-
The cnmac driver supports gigabit Ethernet
-    interfaces on the Cavium OCTEON Plus CN50xx and Cavium OCTEON III CN71xx
-    systems.

-
It presently provides IPv4/TCP/UDP checksumming on reception only.
-    It also supports VLAN-sized frames.

-

-

-

-
arp(4), atphy(4),
-    ifmedia(4), netintro(4),
-    vlan(4), ifconfig(8)

-

-

-

-
The cnmac driver first appeared in
-    NetBSD 8.0.

-

-

-

-
The cnmac driver was written for
-    NetBSD by Internet Initiative Japan
-    Inc.

-

-

-
-  
-    
-    
-  
-
February 7 2026NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbppc/intro_pmppc.4 3.html b/static/netbsd/man4/man4.evbppc/intro_pmppc.4 3.html
deleted file mode 100644
index a7654cb7..00000000
--- a/static/netbsd/man4/man4.evbppc/intro_pmppc.4 3.html	
+++ /dev/null
@@ -1,96 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO_PMPPC(4)Device Drivers Manual (evbppc)INTRO_PMPPC(4)

-

-

-

-
intro_pmppc —
-    introduction to pmppc special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Artesyn
-    PM/PPC card. Software support for these devices comes in two forms. A
-    hardware device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), autoconf(4),
-    cs(4), evbppc/cpc(4),
-    evbppc/rtc(4)

-

-

-

-
The evbppc intro_pmppc man page first
-    appeared in NetBSD 5.0.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-
PCI devices are supported through the pci(4) bus
-    and associated devices.

-
USB devices are supported through the usb(4) bus
-    and associated devices.

-
Additionally, the following specific devices are supported:

-

-

-  

-  
serial ports in the CPC700

-  

-  
PCI host controller CPC700

-  

-  
Ethernet driver

-  

-  
Real Time Clock driver

-

-

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.evbppc/rtc.4 3.html b/static/netbsd/man4/man4.evbppc/rtc.4 3.html
deleted file mode 100644
index 86c51fd8..00000000
--- a/static/netbsd/man4/man4.evbppc/rtc.4 3.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTC(4)Device Drivers Manual (evbppc)RTC(4)

-

-

-

-
rtc — DS17485
-    support

-

-

-

-
rtc0 at mainbus0 addr 0x7ff00000

-

-

-

-
The rtc provides support for the real time
-    clock DS17485.

-

-

-

-
evbppc/mainbus(4)

-

-

-

-
The rtc driver appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/autoconf.4 3.html b/static/netbsd/man4/man4.hp300/autoconf.4 3.html
deleted file mode 100644
index 9507fdd2..00000000
--- a/static/netbsd/man4/man4.hp300/autoconf.4 3.html	
+++ /dev/null
@@ -1,112 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (hp300)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel.

-
Autoconfiguration on the HP300s is similar to that on the VAX, the
-    primary difference is in the naming conventions. On the HP300, if devices
-    exist which are not configured they will be ignored; if devices exist of
-    unsupported type they will be ignored.

-
Normally, the system uses the disk from which it was loaded as the
-    root filesystem. If that is not possible, a generic system will use
-    ‘rd0’ if it exists. If such a system
-    is booted with the RB_ASKNAME option (see
-    reboot(2)), then the name of the root device is read from
-    the console terminal at boot time, and any available device may be used.

-

-

-

-

-  
SPU type not configured

-  
You tried to boot NetBSD on an SPU type which it
-      doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-  
nhpib%d at intio0 addr 0x478000 ipl %d

-  

-  
nhpib%d at dio0 scode %d ipl %d

-  

-  
fhpib%d at dio0 scode %d ipl %d

-  

-  
hpibbus%d at nhpib%d

-  

-  
hpibbus%d at fhpib%d

-  
An HP-IB was found at the internal bus or scode %d (the select code) with
-      ipl %d (interrupt priority level). NetBSD will
-      call it hpibbus%d.

-  
%s%d at hpibbus%d slave %d punit %d

-  

-  
%s%d: %s

-  
An HP-IB disk or tape controller was found. For disks
-      ‘%s%d’ will look like
-      ‘rd0’, for tapes like
-      ‘ct0’. The
-      ‘%s’ in the first line will be a
-      product type like ``7945A'' or ``9144''. The slave number comes from the
-      address select switches on the drive.

-  
dvbox0 at intio0 addr 0x560000

-  

-  
dvbox%d at dio0 scode %d

-  

-  
gbox0 at intio0 addr 0x560000

-  

-  
gbox%d at dio0 scode %d

-  

-  
hyper%d at dio0 scode %d

-  

-  
rbox0 at intio0 addr 0x560000

-  

-  
rbox%d at dio0 scode %d

-  

-  
topcat0 at intio0 addr 0x560000

-  

-  
topcat%d at dio0 scode %d

-  

-  
tvrx%d at dio0 scode %d

-  

-  
gendiofb%d at dio0 scode %d

-  

-  
sti%d at sgc0 slot %d

-  
A bit mapped display was found either at the ``internal'' address, at some
-      ``external'' select code, or at some SGC bus slot. If it exists, the
-      internal display will always be unit 0.

-  
%s%d at dio0 scode %d ipl %d

-  
Another peripheral controller was found at the indicated select code and
-      with indicated interrupt priority level.
-      ‘%s’ will be one of
-      com(4) (single-port serial interfaces),
-      hp300/dcm(4) (four-port serial interfaces), or
-      le(4) (LAN cards). The slave number comes from the
-      address select switches on the interface card.

-

-

-

-

-
config(1), hp300/intro(4),
-    boot(8)

-
4.3BSD for the HP300,
-    in the distribution documentation
-  package.

-

-

-
-  
-    
-    
-  
-
June 17, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/ct.4 3.html b/static/netbsd/man4/man4.hp300/ct.4 3.html
deleted file mode 100644
index 4f3869a4..00000000
--- a/static/netbsd/man4/man4.hp300/ct.4 3.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
CT(4)Device Drivers Manual (hp300)CT(4)

-

-

-

-
ct — CS/80
-    cartridge tape interface

-

-

-

-
ct0 at hpibbus? slave ?

-

-

-

-
The cartridge tape interface as found in the 7946 and 9144
-    products provides a standard tape drive interface as described in
-    mtio(4) with the following exceptions:

-
    
-  
  1. There is only one density.
    2. 
-  
  2. Only the “raw” interface is supported.
    3. 
-  
  3. The MTIOCTOP ioctl(2) is
-      limited. In particular, the command, MTFSR is not
-      supported.
    4. 
-  
  4. The MTIOCGET ioctl(2) is not
-      supported.
    5. 
-  
  5. The record size for read and write operations must be between 1K and 64K
-      inclusive.
    6. 
-

-
Special files rct0 through
-    rct3 refer to rewind on close interfaces to drives 0
-    to 3. Files rct4 through
-    rct7 refer to no-rewind interfaces. Files
-    rct8 through rct11 refer to
-    streaming rewind on close interfaces. (Only 9144 type devices can stream.)
-    Lastly, rct12 through rct15
-    refer to streaming no-rewind interfaces.

-

-

-

-
mt(1), tar(1),
-    mtio(4)

-

-

-

-
Read and writes of less than 1024 bytes will not behave as
-    expected.

-

-

-
-  
-    
-    
-  
-
June 9, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/dcm.4 3.html b/static/netbsd/man4/man4.hp300/dcm.4 3.html
deleted file mode 100644
index e73e2545..00000000
--- a/static/netbsd/man4/man4.hp300/dcm.4 3.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
DCM(4)Device Drivers Manual (hp300)DCM(4)

-

-

-

-
dcm — HP98642A
-    serial communications multiplexer

-

-

-

-
dcm* at dio? scode ? flags 0xe

-

-

-

-
The 98642A is a four port EIA RS-232C (CCITT V.28) communications
-    multiplexer. The 98642A has three direct-connect ports and one port with
-    full modem control.

-
Input and output for each line may set to one of following baud
-    rates; 50, 75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 9600,
-    19200, 38400.

-
Flags is usually specified as 0xe since 3 of
-    the 4 ports (1-3) do not support modem control and should be treated as
-    hard-wired with carrier always present. If port 0 does not have the need for
-    modem control then flags can be specified as
-    ‘0xf’.

-
Each port on the 98642A has a 128 byte input silo and a 16 byte
-    output silo. Interrupts happen on a per character basis unless the interrupt
-    rate for the card reaches 70 interrupts per second at which time the driver
-    changes to a 16.7ms (60 interrupts per second) polling scheme until the
-    interrupt rate drops.

-

-

-

-

-  
/dev/tty0[0-9a-f]

-  
 

-

-

-

-

-

-  
dcm%d port%d: silo overflow

-  
Input Silo has overflowed and incoming data has been lost.

-  
dcm%d port%d: uart overflow

-  
The 3 character buffer in the UART has overflowed.

-

-

-

-

-
hp300/dio(4), tty(4)

-

-

-

-
Total throughput per card, all ports together, is limited to 76800
-    bits per second continuous input rate.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/dnkbd.4 3.html b/static/netbsd/man4/man4.hp300/dnkbd.4 3.html
deleted file mode 100644
index ef7d84d9..00000000
--- a/static/netbsd/man4/man4.hp300/dnkbd.4 3.html	
+++ /dev/null
@@ -1,34 +0,0 @@
-
-  
-    
-    
-    
-  
-
DNKBD(4)Device Drivers Manual (hp300)DNKBD(4)

-

-

-

-
dnkbd — Domain
-    keyboard

-

-

-

-
dnkbd at frodo? offset ?

-

-

-

-
The dnkbd driver provides support for the
-    Domain keyboard found on HP Apollo 9000/4xx series workstations.

-

-

-

-
com(4), hp300/frodo(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/gbox.4 3.html b/static/netbsd/man4/man4.hp300/gbox.4 3.html
deleted file mode 100644
index baafa2ec..00000000
--- a/static/netbsd/man4/man4.hp300/gbox.4 3.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
GB(4)Device Drivers Manual (hp300)GB(4)

-

-

-

-
gb — HP98700
-    “Gatorbox” graphics device interface

-

-

-

-
gbox* at intio?
-  

-  gbox* at dio? scode ?
-  

-  wsdisplay* at gbox?

-

-

-

-
This driver is for the HP98700 and 98710 graphics devices, also
-    known as the Gatorbox. The term “Gator” will often be used,
-    and it is not to be confused with “Gator” used in reference to
-    an HP 9837 or 200/237 machine. Also, the term Gatorbox is used for the 98700
-    alone, with the 98701 frame buffer memory or with the 98710 accelerator
-    installed. This driver merely checks for the existence of the device and
-    does minimal setup, as it is expected the applications will initialize the
-    device to their requirements.

-
The 98700 can be used as the only graphics device on a system, in
-    which case it will be used as the system console. It can also be installed
-    as a secondary display device. For the first case, the HP 98287A M.A.D.
-    interface card should be set to internal control space. This will put the
-    frame buffer at the DIO address 0x200000 and the control registers at
-    0x560000. At this address it will be the “preferred” console
-    device (see hp300/cons(4)). For use as a secondary device,
-    the 98287A should be set to frame buffer address 0x300000, and to an
-    external select code.

-
It should be noted that this configuration will conflict with the
-    98547 display card which has a 2 megabyte frame buffer starting at address
-    0x200000. The 98700 should only be installed as a secondary device in a
-    machine with a 1 bit 98544 display card or 4 bit 98545 card. The
-    98700H Installation Guide contains further
-    configuration information.

-

-

-

-
wscons(4), wsdisplay(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/intro.4 3.html b/static/netbsd/man4/man4.hp300/intro.4 3.html
deleted file mode 100644
index 43a6b488..00000000
--- a/static/netbsd/man4/man4.hp300/intro.4 3.html	
+++ /dev/null
@@ -1,171 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (hp300)INTRO(4)

-

-

-

-
intro —
-    introduction to hp300 special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the HP 9000/300
-    series. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    hp300/autoconf(4).

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Pseudo-devices are not listed. Devices are indicated by their
-    functional interface. Occasionally, new devices of a similar type may be
-    added simply by creating appropriate table entries in the driver; for
-    example, new CS/80 drives.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
comserial interfaces (98644, 98626, and built-in apci and dca)
ct7946/9144 CS/80 cartridge tape
dcmHP 98642A communications multiplexer
dioDIO/DIO-II bus
dnkbdDomain keyboard
dvboxHP98730 ``DaVinci'' device interface
fhpib``fast'' HP-IB interface
frodoFrodo ASIC (a.k.a. Apollo Utility Chip)
gboxHP98700 ``Gatorbox'' device interface
grf/iteTopcat/Gatorbox/Renaissance frame buffer
hilHIL interface
nhpibBuilt-in and 98625 HP-IB interface
hyperHyperion device interface
intioHP300 internal I/O space driver
iteHP Internal Terminal Emulator
le98643 Lance-based Ethernet interface
ppiHP-IB printer/plotter interface
rboxHP98720 ``Renaissance'' device interface
rdCS/80 disk interface
rmpHP Remote Maintenance Protocol family
spcHP98265A SCSI interface
topcatHP98544-98550 ``Topcat'' and ``Catseye'' device interface

-

-

-

-
config(1),
-  hp300/autoconf(4)

-
Building 4.3 BSD UNIX Systems
-    with Config (SMM:2).

-

-

-

-
The HP300 intro appeared in
-    4.3BSD-Reno.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/ppi.4 3.html b/static/netbsd/man4/man4.hp300/ppi.4 3.html
deleted file mode 100644
index 6e1e6d6b..00000000
--- a/static/netbsd/man4/man4.hp300/ppi.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PPI(4)Device Drivers Manual (hp300)PPI(4)

-

-

-

-
ppi — HP-IB
-    printer/plotter interface

-

-

-

-
ppi0 at hpibbus0 slave 5

-

-

-

-
The ppi interface provides a means of
-    communication with HP-IB printers and plotters.

-
Special files ppi0 through
-    ppi7 are used to access the devices, with the digit
-    at the end of the filename referring to the bus address of the device.
-    Current versions of the autoconf code can not probe for these devices, so
-    the device entry in the configuration file must be fully qualified.

-
The device files appear as follows:

-

-
"crw-rw-rw-  1 root      11,   0 Dec 21 11:22 /dev/ppi"

-

-

-

-

-
None.

-

-

-

-
hp300/hpib(4)

-

-

-

-
This driver is very primitive, it handshakes data out byte by
-    byte. It should use DMA if possible.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hp300/topcat.4 3.html b/static/netbsd/man4/man4.hp300/topcat.4 3.html
deleted file mode 100644
index df7e0af7..00000000
--- a/static/netbsd/man4/man4.hp300/topcat.4 3.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
TOPCAT(4)Device Drivers Manual (hp300)TOPCAT(4)

-

-

-

-
topcat — HP98544
-    98550 “Topcat” and “Catseye” device
-    interface

-

-

-

-
topcat* at intio?
-  

-  topcat* at dio? scode ?
-  

-  wsdisplay* at topcat?

-

-

-

-
This driver is for the HP98544, 98545, 98542, 98543, and 98547
-    “Topcat” and HP98548, 98549, and 98550 “Catseye”
-    display cards. This driver merely checks for the existence of the device and
-    does minimal setup, as it is expected the applications will initialize the
-    device to their requirements. The Topcat and Catseye are nearly identical in
-    common usage and only the Topcat will be referred to from now on.

-
The Topcat display cards are not user configurable. If one is
-    present on a system, it will always have a frame buffer address of 0x200000
-    and a control register address of 0x560000. These are the HP series 300 ITE
-    (Internal Terminal Emulator) defaults. The device can also be used as a
-    graphics output device.

-

-

-

-
wscons(4), wsdisplay(4)

-

-

-
-  
-    
-    
-  
-
May 1, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hpcarm/intro.4 2.html b/static/netbsd/man4/man4.hpcarm/intro.4 2.html
deleted file mode 100644
index a5f09cd0..00000000
--- a/static/netbsd/man4/man4.hpcarm/intro.4 2.html	
+++ /dev/null
@@ -1,125 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (hpcarm)INTRO(4)

-

-

-

-
intro —
-    introduction to hpcarm special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the hpcarm
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
The hpcarm port supports StrongARM based Windows CE PDA
-    machines. The current supports models are:

-
HP Jornada series

-
    
-  
  • HP Jornada 710, 720, 728, 820
    • 
-

-
Compaq iPAQ series

-
    
-  
  • iPAQ H3600
    • 
-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-
Standard SA-11x0 on-chip peripheral devices:

-

-

-  
sacom

-  
Serial communication interface

-  
sacpcic

-  
PCMCIA controller

-  
saip

-  
Bus for integrated peripheral devices

-  
saost

-  
Operating System timer

-

-

-
Network interfaces:

-

-

-  
an

-  
Aironet 4500/4800 and Cisco 340/350 wireless network devices

-  
ep

-  
3Com EtherLink III Ethernet devices

-  
ne

-  
NE2000 and compatible Ethernet devices

-  
wi

-  
WaveLAN/IEEE and PRISM-II 802.11 wireless network devices

-

-

-
Pointer devices:

-

-

-  
j720lcd

-  
LCD screen control of the HP Jornada 7xx series machines

-  
j720tp

-  
Touch screen of the HP Jornada 7xx series machines

-

-

-

-

-

-
config(1), autoconf(4)

-

-

-

-
This manual page is incomplete.

-

-

-
-  
-    
-    
-  
-
June 25, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hpcarm/j720lcd.4 3.html b/static/netbsd/man4/man4.hpcarm/j720lcd.4 3.html
deleted file mode 100644
index 2a9de275..00000000
--- a/static/netbsd/man4/man4.hpcarm/j720lcd.4 3.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
J720LCD(4)Device Drivers Manual (hpcarm)J720LCD(4)

-

-

-

-
j720lcd — driver
-    for Jornada 710/720/728 LCD screen

-

-

-

-
j720lcd* at j720ssp?

-

-

-

-
The j720lcd driver provides support for
-    controlling brightness, contrast, and power of the LCD screen in the Jornada
-    720 series machines.

-
The default keymap binds
-    ⟨Ctrl⟩ +
-    ⟨Alt⟩ +
-    ⟨arrowkey⟩ to control brightness with up
-    and down arrow keys, and to control contrast with left and right arrow
-  keys.

-

-

-

-
screenblank(1),
-  wsconsctl(8)

-

-

-
-  
-    
-    
-  
-
March 29, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hpcsh/intro.4 3.html b/static/netbsd/man4/man4.hpcsh/intro.4 3.html
deleted file mode 100644
index 18809a6b..00000000
--- a/static/netbsd/man4/man4.hpcsh/intro.4 3.html	
+++ /dev/null
@@ -1,139 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (hpcsh)INTRO(4)

-

-

-

-
intro —
-    introduction to hpcsh special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the hpcsh
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
The NetBSD/hpcsh port supports HITACHI
-    SuperH family based Windows CE PDA machines. Currently supported
-    models are

-
HP Jornada Series:

-
    
-  
  • HP 620LX
    • 
-  
  • HP Jornada 680, 680e, 690, 690e
    • 
-

-
Hitachi Persona Series:

-
    
-  
  • PERSONA HPW-50PAD
    • 
-  
  • PERSONA HPW-230JC
    • 
-  
  • PERSONA HPW-650PA
    • 
-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-
Standard SuperH on-chip peripheral devices:

-

-

-  
adc

-  
analog/digital converter

-  
sci

-  
serial communication interface

-  
scif

-  
serial communication interface with FIFO

-  
shb

-  
bus for SuperH on-chip peripheral devices

-

-

-
Companion chips:

-

-

-  
hd64461

-  
HD64461 Windows CE Intelligent Peripheral Controller

-  
hd64461pcmcia

-  
HD64461 integrated PCMCIA controller

-  
hd64461video

-  
HD64461 integrated LCD controller

-  
hd64465

-  
HD64465 Windows CE Intelligent Peripheral Controller

-  
hd64465pcmcia

-  
HD64465 integrated PCMCIA controller

-  
hd64465video

-  
HD64465 integrated LCD controller

-

-

-
Pointer devices:

-

-

-  
j6x0lcd

-  
LCD screen of HP Jornada 680 series machines

-  
j6x0tp

-  
touch screen of HP Jornada 680 series machines

-  
psh3lcd

-  
LCD screen of HITACHI PERSONA SH3 series machines

-  
psh3tp

-  
touch screen of HITACHI PERSONA SH3 series machines

-

-

-

-

-

-
adc(4), hpcsh/j6x0lcd(4),
-    hpcsh/j6x0tp(4), hpcsh/psh3lcd(4),
-    hpcsh/psh3tp(4), shb(4)

-

-

-

-
This manual page is incomplete.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hpcsh/psh3tp.4 3.html b/static/netbsd/man4/man4.hpcsh/psh3tp.4 3.html
deleted file mode 100644
index 26f4bea7..00000000
--- a/static/netbsd/man4/man4.hpcsh/psh3tp.4 3.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSH3TP(4)Device Drivers Manual (hpcsh)PSH3TP(4)

-

-

-

-
psh3tp — driver
-    for PERSONA SH3 touch-panel

-

-

-

-
psh3tp* at adc?
-  

-  wsmouse* at psh3tp? mux 0

-

-

-

-
The psh3tp driver provides support for the
-    PERSONA SH3 touch-panel.

-
Pen movements are passed to wsmouse(4) as mouse
-    clicks and drags.

-

-

-

-
adc(4), wsmouse(4),
-    tpctl(8)

-

-

-

-
The psh3tp driver first appeared in
-    NetBSD 3.0.

-

-

-
-  
-    
-    
-  
-
May 14, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/asp.4 3.html b/static/netbsd/man4/man4.hppa/asp.4 3.html
deleted file mode 100644
index 1842936f..00000000
--- a/static/netbsd/man4/man4.hppa/asp.4 3.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
ASP(4)Device Drivers Manual (hppa)ASP(4)

-

-

-

-
asp — first
-    generation I/O subsystem

-

-

-

-
asp* at mainbus0
-  

-  gsc* at asp?

-

-

-

-
Core bus controller and I/O subsystem as present on older HP
-    9000/700 workstations. The supported core bus controllers are those used in
-    conjunction with PA7000, PA7100, and PA7150 CPUs and include:

-

-
    
-  
  • Core bus controller
    • 
-  
  • System Clock
    • 
-  
  • Interrupt Controller
    • 
-  
  • DMA Controller
    • 
-  
  • Real Time Clock Interface
    • 
-  
  • RAM and EEPROM controllers
    • 
-

-

-

-

-
An incomplete list of machines that use the ASP bus
-  controller:

-

-
    
-  
  • 705, 710
    • 
-  
  • 715/{33,50,75}
    • 
-  
  • 725/{50,75}
    • 
-  
  • 720, 730, 750
    • 
-  
  • 735/*, 755 (ASP2)
    • 
-  
  • 742i
    • 
-  
  • 745i/{50,75}
    • 
-  
  • 747i/{50,75}
    • 
-  
  • 755/*
    • 
-

-

-

-

-
hppa/gsc(4), hppa/intro(4),
-    hppa/io(4)

-
Hardball I/O Subsystem
-    ERS, Revision 1.1,
-    Hewlett-Packard, 30 September
-    1991.

-

-

-

-
The asp driver appeared in
-    OpenBSD 2.4. It was ported to
-    NetBSD 1.6 by Matthew Fredette.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/astro.4 3.html b/static/netbsd/man4/man4.hppa/astro.4 3.html
deleted file mode 100644
index 1a4100ea..00000000
--- a/static/netbsd/man4/man4.hppa/astro.4 3.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
ASTRO(4)Device Drivers Manual (hppa)ASTRO(4)

-

-

-

-
astro — Astro
-    Memory and I/O controller

-

-

-

-
astro* at mainbus?
-  

-  elroy* at astro?

-

-

-

-
The astro driver provides support for the
-    Astro memory and I/O controller used on systems with PA-8500 and later
-    64-bit CPUs. It functions as a bridge from the Runway bus to up to 8 I/O
-    ropes that connect to Elroy chips. Astro contains an IOMMU and provides
-    support for cache coherent DMA.

-

-

-

-
hppa/cpu(4), hppa/elroy(4),
-    hppa/intro(4)

-

-

-

-
The astro driver first appeared in
-    OpenBSD 4.2. It was ported to
-    NetBSD 6.0 by Nick Hudson.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/dino.4 3.html b/static/netbsd/man4/man4.hppa/dino.4 3.html
deleted file mode 100644
index b87bfb71..00000000
--- a/static/netbsd/man4/man4.hppa/dino.4 3.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
DINO(4)Device Drivers Manual (hppa)DINO(4)

-

-

-

-
dino — Dino and
-    Cujo Host/PCI bridges

-

-

-

-
dino* at phantomas?
-  

-  com* at dino?
-  

-  pci* at dino?

-

-

-

-
This driver supports Dino and Cujo Host/PCI bridges found in
-    [ABC][0-9][0-9][0-9]-Class workstations and GSC / HSC cards. Cujo is a 64
-    bit datapath version of Dino.

-
On some machines it may also provide an additional serial port
-    through the com(4) driver, or PS/2 keyboard and mouse
-    ports, though the latter are not yet supported.

-

-

-

-
An incomplete list of machines that use the Dino / Cujo Host/PCI
-    bridges:

-

-
    
-  
  • 744
    • 
-  
  • 748[i]
    • 
-  
  • A180[C]
    • 
-  
  • B132L[+], B160L, B180L+
    • 
-  
  • C132L, C160[L], C180, C200, C240, C360
    • 
-  
  • J2240
    • 
-  
  • D390
    • 
-  
  • R380, R390
    • 
-

-

-

-

-
com(4), hppa/intro(4),
-    hppa/phantomas(4), pci(4)

-

-

-

-
The dino driver appeared in
-    OpenBSD 3.5. It was ported to
-    NetBSD 2.0 by Jochen Kunz.

-

-

-

-
dino bridges of revision earlier than
-    three may exhibit data corruption on DMA. This hardware bug does not affect
-    cujo or card mode dino
-    bridges. See HP Service Note Numbers A4190A-01 and A4191A-01 for more
-    details. Systems affected are those shipped before Aug 20, 1997 and of
-    models: B132L, B160L, C160, C180, C200, C240.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/elroy.4 3.html b/static/netbsd/man4/man4.hppa/elroy.4 3.html
deleted file mode 100644
index 91608c76..00000000
--- a/static/netbsd/man4/man4.hppa/elroy.4 3.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
ELROY(4)Device Drivers Manual (hppa)ELROY(4)

-

-

-

-
elroy — Elroy PCI
-    hostbridge

-

-

-

-
elroy* at astro?
-  

-  pci* at elroy?

-

-

-

-
The elroy driver provides support for the
-    Elroy PCI hostbridge and its embedded I/O SAPIC interrupt controller.

-

-

-

-
hppa/astro(4), hppa/intro(4),
-    pci(4)

-

-

-

-
The elroy driver first appeared in
-    OpenBSD 4.2. It was ported to
-    NetBSD 6.0 by Nick Hudson.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/harmony.4 3.html b/static/netbsd/man4/man4.hppa/harmony.4 3.html
deleted file mode 100644
index 6cfb2ca4..00000000
--- a/static/netbsd/man4/man4.hppa/harmony.4 3.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
HARMONY(4)Device Drivers Manual (hppa)HARMONY(4)

-

-

-

-
harmony —
-    CS4215/AD1849 audio interface

-

-

-

-
harmony* at gsc?
-  

-  audio* at harmony?

-

-

-

-
The harmony device uses the Crystal
-    Semiconductor CS4215 16-Bit Multimedia Audio Codec or Analog Devices AD1849
-    SoundPort(R) Stereo Codec chip to implement the audio device interface
-    described in audio(4). This device is found on most HP
-    PA-RISC workstations. The harmony has a maximum
-    precision of 16 bits with a maximum 48000 Hz sample rate, and has stereo
-    input and stereo output.

-
On HP 9000/712 models harmony also
-    provides two additional channels for an add-on card with two fax/voice
-    modems.

-
One of the hardware registers reflects the state of the CHI bus
-    that is used to communicate with the codec and thus being sampled at a low
-    accuracy secondary frequency (such as timeout(9)) produces
-    a poor quality random bit stream that is fed into the entropy pool of
-    rnd(4).

-

-

-

-
An incomplete list of machines that feature
-    harmony audio:

-

-
    
-  
  • 712/*
    • 
-  
  • 715/*
    • 
-  
  • 725/*
    • 
-  
  • 735/*
    • 
-  
  • 755/*
    • 
-  
  • B132L[+], B160L, B180L+
    • 
-  
  • C100, C110, C132L, C160[L], C180, C200, C240, C360
    • 
-  
  • J200, J210[XC], J280, J282, J2240
    • 
-

-

-

-

-
hppa/ioctl(2), audio(4),
-    hppa/gsc(4), hppa/intro(4),
-    rnd(4)

-

-

-

-
Support for harmony first appeared in
-    OpenBSD 3.3. It was ported to
-    NetBSD 1.6 by Chuck Silvers.

-

-

-

-
To trigger entropy collection, the CHI bus has to be programmed
-    into the data mode that happens once a single buffer of data has been played
-    or recorded.

-

-

-
-  
-    
-    
-  
-
May 15, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/mem.4 3.html b/static/netbsd/man4/man4.hppa/mem.4 3.html
deleted file mode 100644
index c9a6fa3b..00000000
--- a/static/netbsd/man4/man4.hppa/mem.4 3.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (hppa)MEM(4)

-

-

-

-
mem, kmem —
-    memory files and memory controller

-

-

-

-
mem* at mainbus0

-

-

-

-
The mem driver controls and restricts
-    access to the systems memory by the hardware buses and the processor.

-
It also provides an interface to userland through the special
-    files /dev/mem and
-    /dev/kmem. Physical memory is accessed through
-    /dev/mem, while kernel virtual memory is accessed
-    through /dev/kmem. Access to kernel virtual
-    addresses not currently mapped to memory will fail. On hppa, the physical
-    memory range is always contiguous and starts at address 0; kernel virtual
-    memory begins at address 0 as well.

-
The writeability of the /dev/mem and
-    /dev/kmem special files are controlled by the system
-    securelevel in addition to the filesystem permissions.

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-

-

-

-

-
The mem driver originates from
-    OpenBSD. It was ported to NetBSD
-    1.6 by Matthew Fredette.

-

-

-

-
On some systems featuring a “Viper” memory
-    controller, NetBSD may not configure bus arbitration
-    correctly, causing the boot process to freeze during either
-    mem or hppa/cpu(4) device
-  probe.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/ssio.4 3.html b/static/netbsd/man4/man4.hppa/ssio.4 3.html
deleted file mode 100644
index 32dc4ef8..00000000
--- a/static/netbsd/man4/man4.hppa/ssio.4 3.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
SSIO(4)Device Drivers Manual (hppa)SSIO(4)

-

-

-

-
ssio — National
-    Semiconductor PC87560 Legacy IO

-

-

-

-
ssio* at pci?

-

-

-

-
The ssio driver provides support for the
-    National Semiconductor PC87560 Legacy IO chip on systems with PA-8500 and
-    later 64-bit CPUs. It configures the Programmable Interrupt Controllers
-    integrated on the chip to route interrupts for the integrated
-    ohci(4) USB controller (which appears as a separate PCI
-    device).

-
NetBSD provides support for the following
-    devices:

-

-

-

-  
com(4)

-  
serial communications interface

-  
lpt(4)

-  
parallel port driver

-

-

-

-

-

-
hppa/intro(4), pci(4)

-

-

-

-
The ssio driver appeared in
-    OpenBSD 4.2. It was ported to
-    NetBSD 6.0 by Nick Hudson.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.hppa/uturn.4 3.html b/static/netbsd/man4/man4.hppa/uturn.4 3.html
deleted file mode 100644
index 5f8f7aa6..00000000
--- a/static/netbsd/man4/man4.hppa/uturn.4 3.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
UTURN(4)Device Drivers Manual (hppa)UTURN(4)

-

-

-

-
uturn — U2/Uturn,
-    Runway to GSC Bus I/O Adapter

-

-

-

-
uturn* at mainbus?
-  

-  astro* at uturn?
-  

-  dino* at uturn?
-  

-  lasi* at uturn?
-  

-  sti* at uturn?

-

-

-

-
uturn provides the functionality of an I/O
-    Adapter (IOA) from the Runway CPU and memory bus to two GSC busses. Modern
-    systems, based on the PA-8000 and later 64-bit CPUs, use the
-    U-Turn version, whilst earlier systems, based on the
-    PA-7200 CPU, used a different version of the chip called
-    U2.

-

-

-

-
hppa/astro(4), hppa/cpu(4),
-    hppa/dino(4), hppa/gsc(4),
-    hppa/intro(4), pci(4),
-    sti(4)

-

-

-

-
The uturn driver appeared in
-    OpenBSD 3.7. It was ported to
-    NetBSD 6.0 by Nick Hudson.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/cmos.4 3.html b/static/netbsd/man4/man4.i386/cmos.4 3.html
deleted file mode 100644
index cbbd2027..00000000
--- a/static/netbsd/man4/man4.i386/cmos.4 3.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
CMOS(4)Device Drivers Manual (i386)CMOS(4)

-

-

-

-
cmos — Read/write
-    access to IBM PC/AT CMOS RAM

-

-

-

-
pseudo-device cmos

-

-

-

-
The cmos pseudo-device can be used to read
-    the real-time clock and ISA configuration data from an ISA-compatible CMOS
-    RAM, and to write the ISA configuration data.

-
A program reads between 0 and 48 bytes from the CMOS RAM, starting
-    at byte 0 of the RAM, using a single call to read(2).
-    Likewise, a program writes between 0 and 48 bytes to the CMOS RAM, starting
-    at byte 0 of the RAM, using a single call to write(2).

-
cmos does not allow programs to overwrite
-    the real-time clock data (bytes 0 through 9), the status registers (10
-    through 13), the diagnostic status or CMOS shutdown status (bytes 14 and
-    15), or the CMOS checksum (bytes 46 and 47). Writes to those bytes are
-    ignored.

-
On writes, cmos recomputes the CMOS
-    checksum and writes it to the CMOS RAM.

-

-

-

-
Display entire contents of CMOS RAM:

-

-
# dd if=/dev/cmos bs=48 count=1 | od -t x1
-0000000   37  00  09  00  22  00  06  13  04  80  26  02  50  80  00  00
-0000020   00  51  f0  00  01  80  02  00  fc  0f  2f  00  00  00  00  00
-0000040   00  80  81  f0  ff  00  00  00  00  00  00  00  00  00  05  ee
-0000060

-

-
Change boot order on Soekris net4521 to PXE ROM, Primary HDD,
-    Secondary HDD:

-

-
# dd if=/dev/cmos of=/tmp/cmos0 bs=48 count=1
-1+0 records in
-1+0 records out
-48 bytes transferred in 0.001 secs (48000 bytes/sec)
-# cp /tmp/cmos0 /tmp/cmos
-# printf '\xf0\x80\x81\xff' | dd bs=1 seek=33 conv=notrunc of=/tmp/cmos
-4+0 records in
-4+0 records out
-4 bytes transferred in 0.001 secs (4000 bytes/sec)
-# dd if=/tmp/cmos of=/dev/cmos
-0+1 records in
-0+1 records out
-48 bytes transferred in 0.001 secs (48000 bytes/sec)

-

-

-

-

-
A program can read or write no more than 48 bytes to
-    cmos. Both read(2) and
-    write(2) will return EINVAL if
-    more than 48 bytes are read or written at once.

-

-

-

-
The original cmos driver was written by
-    Takahiro Kambe
-    <taca@back-street.net>.
-  

-  David Young
-    <dyoung@NetBSD.org>
-    modified the original and added it to NetBSD.

-

-

-
-  
-    
-    
-  
-
April 21, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/elanpar.4 3.html b/static/netbsd/man4/man4.i386/elanpar.4 3.html
deleted file mode 100644
index 4ee833ca..00000000
--- a/static/netbsd/man4/man4.i386/elanpar.4 3.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
ELANPAR(4)Device Drivers Manual (i386)ELANPAR(4)

-

-

-

-
elanpar — AMD Elan
-    SC520 Programmable Address Regions

-

-

-

-
elansc* at mainbus? bus ?
-  

-  elanpar* at elansc?

-

-

-

-
The elanpar driver supports the
-    write-protect feature of the AMD Elan SC520 microcontroller's integrated
-    Programmable Address Regions. Currently, elanpar
-    protects the kernel text from being overwritten by the CPU or errant
-  DMA.

-

-

-

-

-  
elanpar0: cpu violated write-protect window %u

-  

-  
elanpar0: gp violated write-protect window %u

-  

-  
elanpar0: pci violated write-protect window %u

-  

-

-
A Programmable Address Region stopped either the CPU, the
-    general-purpose bus (gp), or a PCI bus master from writing to the indicated
-    window of write-protected memory.

-

-  
elanpar0: %u bytes of kernel text are unprotected

-  

-

-
elanpar has not write-protected
-     bytes of the kernel
-    text.

-

-

-

-
i386/elanpex(4),
-    i386/elansc(4), dmesg(8),
-    syslogd(8)

-

-

-

-
The elanpar device first appeared in
-    NetBSD 5.0.

-

-

-

-
The elanpar driver was written by
-    David Young
-    <dyoung@NetBSD.org>.

-

-

-

-
elanpar leaves as many as 65535 bytes
-    unprotected at the beginning and end of kernel text. Also,
-    elanpar is not compatible with setting breakpoints
-    using ddb(4). Disable elanpar
-    using drvctl -d
-    elanpar0 before setting a breakpoint with
-    ddb(4).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/elanpex.4 3.html b/static/netbsd/man4/man4.i386/elanpex.4 3.html
deleted file mode 100644
index 7b9340e1..00000000
--- a/static/netbsd/man4/man4.i386/elanpex.4 3.html	
+++ /dev/null
@@ -1,107 +0,0 @@
-
-  
-    
-    
-    
-  
-
ELANPEX(4)Device Drivers Manual (i386)ELANPEX(4)

-

-

-

-
elanpex — AMD Elan
-    SC520 PCI Exception Instrumentation

-

-

-

-
elansc* at mainbus? bus ?
-  

-  elanpex* at elansc?

-

-

-

-
The elanpex driver supports the PCI
-    exception-reporting facilities of the AMD Elan SC520 microcontroller's
-    integrated PCI host controller.

-

-

-

-

-  

-  

-    
The host controller may originate a transaction of type
-        %s on bus address %x that fails for
-        the following reasons:

-    

-      
elanpex0: %s %x master retry timeout

-      

-      
elanpex0: %s %x master target abort

-      

-      
elanpex0: %s %x master abort

-      

-      
elanpex0: %s %x master system error

-      

-      
elanpex0: %s %x master received parity error

-      

-      
elanpex0: %s %x master detected parity error

-      

-    

-    
Transaction types include

-    

-      
i/o read

-      

-      
i/o write

-      

-      
memory rd

-      

-      
memory wr

-      

-      
cfg rd

-      

-      
cfg wr

-      

-    

-  

-  

-  

-    
The host controller may be the target of a failed transaction
-        of type %s at bus address %x.
-        Failures may occur for the following reasons:

-    

-      
elanpex0: %s %x target delayed txn timeout

-      

-      
elanpex0: %s %x target address parity

-      

-      
elanpex0: %s %x target data parity

-      

-    

-    
Transaction types are alike to failed master exceptions.

-  

-

-

-

-

-
i386/elanpar(4),
-    i386/elansc(4), dmesg(8),
-    syslogd(8)

-

-

-

-
The elanpex device first appeared in
-    NetBSD 5.0.

-

-

-

-
The elanpex driver was written by
-    David Young
-    <dyoung@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/elansc.4 3.html b/static/netbsd/man4/man4.i386/elansc.4 3.html
deleted file mode 100644
index 86aaaf0b..00000000
--- a/static/netbsd/man4/man4.i386/elansc.4 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
ELANSC(4)Device Drivers Manual (i386)ELANSC(4)

-

-

-

-
elansc — AMD Elan
-    SC520 System Controller driver

-

-

-

-
elansc* at mainbus? bus ?
-  

-  gpio* at elansc?
-  

-  pci* at elansc?
-  

-  elanpar* at elansc?
-  

-  elanpex* at elansc?

-

-

-

-
The elansc driver supports the system
-    controller of the AMD Elan SC520 microcontroller. The SC520 consists of an
-    AMD Am5x86 processor core, integrated PCI host controller, and several
-    standard on-chip devices, such as NS16550-compatible UARTs, real-time clock,
-    and timers.

-
The Elan SC520 also provides several special on-chip devices. The
-    following are supported by the elansc driver:

-
    
-  
  • Watchdog timer. The watchdog timer may be configured for a 1 second, 2
-      second, 4 second, 8 second, 16 second, or 32 second expiration
-    period.
    • 
-  
  • PCI exceptions reporting. The SC520 microcontroller can report exceptions
-      that occur as it acts as both a PCI bus master and a bus target. See
-      i386/elanpex(4).
    • 
-  
  • RAM write-protection. The SC520 microcontroller can designate
-      write-protected regions of RAM using the Programmable Address Regions
-      registers. See i386/elanpar(4).
    • 
-  
  • Programmable Input/Output. The SC520 microcontroller supports 32
-      programmable I/O signals (PIOs) that can be used on the system board to
-      monitor signals or control devices that are not handled by the other
-      functions in the SC520 microcontroller. These signals can be programmed to
-      be inputs or to be driven “high” or “low” as
-      outputs. Pins can be accessed through the gpio(4)
-      framework. The gpioctl(8) program allows easy
-      manipulation of pins from userland.
    • 
-  
  • PCI host-bridge optimization. elansc takes
-      advantage of a suspend/resume cycle to tune the PCI host-bridge for higher
-      performance.
    • 
-

-

-

-

-
gpio(4), i386/elanpar(4),
-    i386/elanpex(4), gpioctl(8),
-    wdogctl(8)

-

-

-

-
The elansc device first appeared in
-    NetBSD 2.0. PIO function support was added in
-    OpenBSD 3.6, and subsequently ported to
-    NetBSD 4.0. Support for PCI exceptions reporting and
-    for RAM write-protection first appeared in NetBSD
-    5.0.

-

-

-

-
The elansc driver was written by
-    Jason R. Thorpe
-    <thorpej@NetBSD.org>.
-    Jasper Wallace provided the work-around for a
-    hardware bug related to the watchdog timer in some steppings of the SC520
-    CPU. Support for the PIO function was added to OpenBSD
-    3.6 by Alexander Yurchenko
-    <grange@openbsd.org>
-    and was ported to NetBSD by Jeff
-    Rizzo
-    <riz@NetBSD.org>.
-    David Young
-    <dyoung@NetBSD.org>
-    added support for PCI exceptions reporting and for RAM write-protection
-    using the Programmable Address Regions.

-

-

-
-  
-    
-    
-  
-
August 25, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/mms.4 3.html b/static/netbsd/man4/man4.i386/mms.4 3.html
deleted file mode 100644
index 99feadfb..00000000
--- a/static/netbsd/man4/man4.i386/mms.4 3.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
MMS(4)Device Drivers Manual (i386)MMS(4)

-

-

-

-
mms —
-    Microsoft-style bus mouse driver

-

-

-

-
mms0 at isa? port 0x23c irq 5
-  

-  mms1 at isa? port 0x238 irq 5
-  

-  wsmouse* at mms?

-

-

-

-
This driver provides an interface to a Microsoft-style bus mouse.
-    Mouse related data are accessed by wsmouse(4) devices.

-

-

-

-
i386/lms(4), pms(4),
-    wsmouse(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/pcibios.4 3.html b/static/netbsd/man4/man4.i386/pcibios.4 3.html
deleted file mode 100644
index 794f7013..00000000
--- a/static/netbsd/man4/man4.i386/pcibios.4 3.html	
+++ /dev/null
@@ -1,173 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCIBIOS(4)Device Drivers Manual (i386)PCIBIOS(4)

-

-

-

-
pcibios —
-    introduction to PCI BIOS support

-

-

-

-
options PCIBIOS
-  

-  options PCIBIOSVERBOSE
-  

-  #options PCIBIOS_IRQS_HINT=0x0a00 #IRQ 9,11
-  

-  #options PCIBIOS_INTR_FIXUP_FORCE
-  

-  options PCIBIOS_INTR_GUESS
-  

-  #options PCIINTR_DEBUG

-

-

-

-
pcibios provides support for setting up
-    PCI controllers, bridges, and devices using information extracted from the
-    BIOS.

-
Ideally, the boot firmware of a machine (a.k.a. BIOS) should set
-    up all PCI devices; assigning them I/O and memory addresses and interrupts.
-    Alas, this does not always happen, so there is some PC specific code that
-    can do the initialization when NetBSD boots.

-
Options:

-

-

-  
PCIBIOS

-  
turn on the PCI BIOS support.

-  
PCIBIOSVERBOSE

-  
make the setup procedure verbose.

-  
PCIBIOS_IRQS_HINT

-  
hint for IRQ use. When PCI_INTR_FIXUP cannot guess an
-      adequate IRQ for a device, the hint is used.
-    
The value is a logical or of power-of-2s of allowable
-        interrupts:

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
 0 0x0001 4 0x0010 8 0x010012 0x1000
 1 0x0002 5 0x0020 9 0x020013 0x2000
 2 0x0004 6 0x004010 0x040014 0x4000
 3 0x0008 7 0x008011 0x080015 0x8000

-    For example, "options PCIBIOS_IRQS_HINT=0x0a00"
-      allows IRQ 9 and IRQ 11.
-    
The kernel global variable
-        pcibios_irqs_hint holds this value, so a user can
-        override this value without kernel recompilation. For example:

-    
    
-      
  • To specify this value on the fly, type the following command at the
-          boot prompt to drop into DDB (the in-kernel debugger; you have to
-          specify "options DDB" to make kernel with
-          DDB):
-        
    boot
-          -d
    
-        And type the following command on
-          ""
-          prompt:
-        
    write
-          pcibios_irqs_hint 0x0a00
    
-        Then type the following to continue to boot:
-        
    c
    
-      
    • 
-      
  • To modify kernel image without kernel recompilation, run the following
-          command on shell:
-        
    gdb --write
-          /netbsd
    
-        And type the following commands at the
-          ""
-          prompt:
-        
    set
-          pcibios_irqs_hint=0xa00
    
-        
    quit
    
-      
    • 
-    

-  

-  
PCIBIOS_INTR_FIXUP_FORCE

-  
Some buggy BIOS implementations provide inconsistent information between
-      the PCI Interrupt Configuration Register and the PCI Interrupt Routing
-      table. In such case, the PCI Interrupt Configuration Register takes
-      precedence by default. If this happens, a kernel with
-      PCIBIOSVERBOSE shows "WARNING:
-      preserving irq XX" in the PCI routing table.
-    
If
-        
-        is specified in addition to the PCI_INTR_FIXUP, the
-        PCI Interrupt Routing table takes precedence. In this case, a kernel
-        with PCIBIOSVERBOSE shows "WARNING:
-        overriding irq XX" in the PCI routing table.

-  

-  
PCIBIOS_INTR_GUESS

-  
make PCI_INTR_FIXUP work with unknown interrupt router.
-    
If a PCI interrupt router is not known, normally interrupt
-        configuration will not be touched.

-    
But if
-        
-        is specified in addition to the PCI_INTR_FIXUP, and if
-        a PCI interrupt routing table entry indicates that only one IRQ is
-        available for the entry, the IRQ is assumed to be already connected to
-        the device, and corresponding PCI Interrupt Configuration Register will
-        be configured accordingly.

-  

-  
PCIINTR_DEBUG

-  
make the PCI_INTR_FIXUP procedure verbose.

-

-

-

-

-

-
cardbus(4), pci(4)

-

-

-

-
The pcibios code appeared in
-    NetBSD 1.5.

-

-

-

-
The
-    
-    option may conflict with the PCI CardBus driver's own address fixup.

-

-

-
-  
-    
-    
-  
-
October 9, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/rdcide.4 3.html b/static/netbsd/man4/man4.i386/rdcide.4 3.html
deleted file mode 100644
index 9c3d1afe..00000000
--- a/static/netbsd/man4/man4.i386/rdcide.4 3.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
RDCIDE(4)Device Drivers ManualRDCIDE(4)

-

-

-

-
rdcide — RDC IDE
-    disk controllers driver

-

-

-

-
rdcide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The rdcide driver supports the RDC IDE
-    controller as found in the vortex86 and PMX-1000 system on chip, and
-    provides the interface with the hardware for the ata(4)
-    driver.

-
The 0x0002 flag forces the rdcide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    i386/intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.i386/rdcpcib.4 3.html b/static/netbsd/man4/man4.i386/rdcpcib.4 3.html
deleted file mode 100644
index c4cfea07..00000000
--- a/static/netbsd/man4/man4.i386/rdcpcib.4 3.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
RDCPCIB(4)Device Drivers ManualRDCPCIB(4)

-

-

-

-
rdcpcib — RDC
-    PCI/ISA bridge and watchdog timer driver

-

-

-

-
rdcpcib* at pci? dev ? function ?
-  

-  isa0 at rdcpcib?

-

-

-

-
The rdcpcib driver supports the PCI/ISA
-    bridge and watchdog timer as found in RDC's Vortex86 and PMX-1000 system on
-    chip. The watchdog timer may be configured for expiration periods between
-    one and 512 seconds.

-

-

-

-

-  
rdcpcib0: watchdog fired bit set, clearing

-  
A bit was set in the watchdog's timer registers indicating that it has
-      reached the configured timeout at last once. This probably means this boot
-      has been triggered by a watchdog timeout.

-

-

-

-

-
wdogctl(8)

-

-

-
-  
-    
-    
-  
-
March 27, 2026NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mac68k/cpi.4 3.html b/static/netbsd/man4/man4.mac68k/cpi.4 3.html
deleted file mode 100644
index 8508bed7..00000000
--- a/static/netbsd/man4/man4.mac68k/cpi.4 3.html	
+++ /dev/null
@@ -1,202 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPI(4)Device Drivers Manual (mac68k)CPI(4)

-

-

-

-
cpi — parallel
-    printer driver for Creative Systems Inc. Hurdler CPI Nubus card

-

-

-

-
cpi* at nubus? flags 0x1

-

-

-

-
The cpi interface provides access to
-    parallel printer ports.

-

-

-

-
The cpi driver supports the following
-    
-    for use in config(1) files:

-

-

-  
bit 0:

-  
use the CIO counters 1 and 2 as a 32 bit
-    timecounter(9).

-

-

-

-

-
The cpi interface supports the Creative
-    Systems Inc. Hurdler CPI Nubus card, which is based on a Zilog Z8536
-  CIO.

-
The parallel port on the Hurdler CPI card is wired as follows:

-
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-
SubD pinZ8536 pinZ8536 signal
/STROBEStrobe122PC3
D0233PA0
D1332PA1
D2431PA2
D3530PA3
D4629PA4
D5728PA5
D6827PA6
D7926PA7
/ACK1021 + 11PC2 + PB3
BUSY1119 + 14PC0 + PB6
PEPaper Error1220PC1
SELSelect1313PB5
/AUTOFDAuto Feed1412PB4
/FAULT159PB1
/RESET168PB0
/SELINSelect In1710PB2

-
The Z8536 INT line (pin 24) is wired to PB7 (pin 15).

-

-

-

-
lpt(4), mac68k/autoconf(4),
-    nubus(4), printcap(5),
-    timecounter(9)

-
IEEE Standard 1284-1994

-

-

-

-
cpi first appeared in
-    NetBSD 5.0.

-

-

-

-
The cpi driver was written by
-    Hauke Fath ⟨hauke@NetBSD.org⟩.

-

-

-

-
The Hurdler CPI Nubus card does not use a TTL buffer to drive the
-    parallel interface. Instead, the card's Z8536 CIO drives the printer port
-    directly. Printers terminating the parallel interface with less than 2 kOhms
-    may cause permanent damage to the Z8536 CIO.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mac68k/iwm.4 3.html b/static/netbsd/man4/man4.mac68k/iwm.4 3.html
deleted file mode 100644
index 9ea3ab5b..00000000
--- a/static/netbsd/man4/man4.mac68k/iwm.4 3.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
IWM(4)Device Drivers Manual (mac68k)IWM(4)

-

-

-

-
iwm, fd —
-    floppy disk driver for IWM and non-DMA SWIM
-    controllers

-

-

-

-
iwm0 at obio?
-  

-  fd* at iwm0 drive ?

-

-

-

-
The iwm driver interfaces to the built-in
-    and external floppy disk drives on the Macintosh. It supports double-density
-    media, written in Apple's proprietary GCR format. Currently, there is no
-    disklabel support for the floppy drives. Instead, the
-    iwm driver sets up a fake in-core disklabel, using
-    the minor device number to select from the supported disk formats.

-
The following formats are supported:

-
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-
a800Kb28010 (default)
b400Kb18010
c800Kb28010

-
(The above table describes the logical mapping as implemented by
-    the driver; the physical layout of GCR floppies has 8..12 sectors per
-    track.)

-

-

-

-
The iwm driver does currently not support
-    floppy disk formatting.

-

-

-

-
Apple Computer, Inc.: "Inside Macintosh", Vol III-33f.
-    (Addison-Wesley)

-
Apple Computer, Inc.: "New Technical Notes DV 17 - Sony
-    Driver"

-
Neil Parker: "iwmstuff"

-
eject(1)

-

-

-

-
The iwm interface first appeared in
-    NetBSD 1.4.

-

-

-

-
Hauke Fath put together the beginnings of the
-    iwm driver in 1996 from the sparse documentation in
-    "Inside Macintosh", Neil Parker's "iwmstuff"
-    documentation for the Apple IIgs and a long, hard look at the .Sony
-  driver.

-

-

-

-
The FFS code is incapable of dealing with a varying number of
-    sectors per track. We have to fake a mapping and so lose FFS support for
-    hardware parameters like transition times.

-
The driver only supports an obsolete format.

-

-

-
-  
-    
-    
-  
-
June 6, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mac68k/netdock.4 3.html b/static/netbsd/man4/man4.mac68k/netdock.4 3.html
deleted file mode 100644
index d9612f62..00000000
--- a/static/netbsd/man4/man4.mac68k/netdock.4 3.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
NETDOCK(4)Device Drivers Manual (mac68k)NETDOCK(4)

-

-

-

-
netdock — Ethernet
-    driver for Asante NetDock and Newer Ether MicroDock

-

-

-

-
netdock* at nubus?

-

-

-

-
The netdock interface provides access to a
-    10 Mb/s Ethernet network via the Asante NetDock and Newer Ether MicroDock,
-    for PowerBook Duo series.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    netdock interface employs the address resolution
-    protocol described in arp(4) to dynamically map between
-    Internet and Ethernet addresses on the local network.

-

-

-

-
The netdock interface is currently known
-    to support the following interfaces for PowerBook Duo series:

-

-
    
-  
  • Asante NetDock
    • 
-  
  • Newer Ether MicroDock
    • 
-

-

-

-

-

-

-  
netdock%d at nubus%d: address %s, type %s %dKB memory.

-  
This is a normal autoconfiguration message noting the 6 byte physical
-      Ethernet address of the adapter, its manufacturer, and how much buffer
-      memory it has.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4), ifconfig(8)

-

-

-

-
The netdock interface first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
June 19, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mac68k/obio.4 3.html b/static/netbsd/man4/man4.mac68k/obio.4 3.html
deleted file mode 100644
index c434d75a..00000000
--- a/static/netbsd/man4/man4.mac68k/obio.4 3.html	
+++ /dev/null
@@ -1,120 +0,0 @@
-
-  
-    
-    
-    
-  
-
OBIO(4)Device Drivers Manual (mac68k)OBIO(4)

-

-

-

-
obio —
-    introduction to Macintosh On-Board IO bus support and
-    drivers

-

-

-

-
obio0 at mainbus?

-

-

-

-
The obio interface serves as an
-    abstraction used by the autoconfiguration system to help find and attach
-    devices (e.g. the Ethernet or disk controllers) connected to the Macintosh
-    onboard I/O bus.

-

-

-

-
NetBSD includes machine-dependent On-Board
-    drivers, sorted by device type and driver name:

-

-

-

-

-  
esp

-  
NCR 53C9x SCSI interfaces.

-  
ncrscsi

-  
NCR 5380 SCSI interface.

-

-

-

-

-

-

-

-  
iwm

-  
Integrated Woz Machine - Sony based floppy drives.

-  
wdc

-  
Standard IDE/ATAPI type hard drive controllers.

-

-

-

-

-

-

-

-  
mc

-  
Apple MACE ethernet interface.

-  
sn

-  
Sonic (DP83932, DP83916) based ethernet interfaces.

-

-

-

-

-

-

-

-  
zsc

-  
Zilog 8530 serial communications interfaces.

-

-

-

-

-

-

-

-  
asc

-  
Apple Sound Chip as found on 68k based Macintosh computers.

-

-

-

-

-

-

-

-  
adb

-  
Apple Desktop Bus for keyboards, mice, and other input devices.

-  
intvid

-  
Internal video hardware.

-

-

-

-

-

-

-
adb(4), asc(4),
-    esp(4), intvid(4),
-    mac68k/autoconf(4), mac68k/intro(4),
-    mac68k/iwm(4), mac68k/zsc(4),
-    mc(4), ncrscsi(4),
-    sn(4), wdc(4)

-

-

-

-
obio first appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mac68k/pbbat.4 3.html b/static/netbsd/man4/man4.mac68k/pbbat.4 3.html
deleted file mode 100644
index 4f308474..00000000
--- a/static/netbsd/man4/man4.mac68k/pbbat.4 3.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
PBBAT(4)Device Drivers ManualPBBAT(4)

-

-

-

-
pbbat — PowerBook
-    1xx Battery and AC adaptor

-

-

-

-
pbbat* at aed?

-

-

-

-
The pbbat driver supports PowerBook 1xx
-    batteries and AC adaptors.

-
The battery and adaptor status are made available through the
-    envsys(4) API. The battery information can be displayed
-    also with the envstat(8) command:

-

-
$ envstat
-                Current  CritMax  WarnMax  WarnMin  CritMin Unit
-[AC Adaptor]
-     connected:    TRUE
-[pbbat0]
-       present:    TRUE
-design voltage:   6.000                                        V
-       voltage:   7.267                                        V
-    design cap:  60.000                                       Wh
- last full cap:     N/A
-        charge:  47.910                      3.674%   2.799%  Wh (47.91%)
-   charge rate:     N/A
-discharge rate:   5.641                                        W
-      charging:    TRUE
-  charge state:  NORMAL

-

-

-

-

-
The pbbat driver is able to send events to
-    powerd(8) daemon when a capacity state has been changed.
-    The new state will be reported as the
-    
-    argument to the /etc/powerd/scripts/sensor_battery
-    script. If a custom capacity limit was set via envstat(8),
-    the pbbat driver will report a
-    
-    event to the same script when current capacity limit has been reached. AC
-    Adaptor events are passed to the
-    /etc/powerd/scripts/acadaptor script as pressed and
-    released events when power is connected or disconnected respectively.

-

-

-

-
adb(4), envsys(4),
-    envstat(8), powerd(8)

-

-

-

-
Nathanial Sloss

-

-

-

-
The pbbat driver appeared in
-    NetBSD 11.

-

-

-

-
This driver currently only supports the PowerBook 100 series
-    batteries excluding the 150 and 190 computers.

-
The design capacity is an approximation of charge based on a new
-    battery.

-
The charge and discharge rates are approximations between
-    successive reads of the battery capacity and should not be relied upon for
-    accurate running time calculations.

-

-

-
-  
-    
-    
-  
-
March 28, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mac68k/zsc.4 3.html b/static/netbsd/man4/man4.mac68k/zsc.4 3.html
deleted file mode 100644
index 5527de7c..00000000
--- a/static/netbsd/man4/man4.mac68k/zsc.4 3.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZSC(4)Device Drivers Manual (mac68k)ZSC(4)

-

-

-

-
zsc — serial
-    communications interface

-

-

-

-
zsc0 at obio?

-

-

-

-
The zsc driver provides support for Z8530-
-    and Z85230-compatible EIA RS-232C (CCITT V.28) communications interfaces.
-    The Z8530 has a 3 character buffer, and the Z85230 has a 8 character buffer.
-    However, due to limitations in the design of the Z85230, the driver is
-    unable to distinguish it from the Z8530 and will not enable any enhanced
-    features of the controller.

-
Input and output for each line may set to one of following baud
-    rates; 50, 75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 9600,
-    19200, 38400, 57600, 115200, 230400, or any other baud rate which is a
-    factor of 115200.

-

-

-

-

-  
/dev/tty00

-  
 

-  
/dev/tty01

-  
 

-

-

-

-

-
tty(4), zstty(4)

-

-

-

-
The zsc driver was originally derived from
-    the sun3 zs driver and is currently under
-    development.

-

-

-

-
Data loss is possible when using high speeds, particularly on
-    older (68020 or 68030) Macintosh models and on busy systems.

-

-

-
-  
-    
-    
-  
-
August 6, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/awacs.4 3.html b/static/netbsd/man4/man4.macppc/awacs.4 3.html
deleted file mode 100644
index e1c8cde3..00000000
--- a/static/netbsd/man4/man4.macppc/awacs.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
AWACS(4)Device Drivers Manual (macppc)AWACS(4)

-

-

-

-
awacs — Apple
-    audio device driver

-

-

-

-
awacs* at obio?
-  

-  audio* at awacs?

-

-

-

-
The awacs (audio waveform amplifier and
-    converter for sound) driver provides support for the audio hardware found in
-    many Apple PowerMacs.

-

-

-

-
audio(4)

-

-

-

-
The awacs device driver appeared in
-    NetBSD 1.5.1.

-

-

-

-
The awacs driver was written by
-    Tsubai Masanari
-    <tsubai@NetBSD.org>.

-

-

-

-
This manual page needs more precision and detail.

-

-

-
-  
-    
-    
-  
-
March 30, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/bm.4 3.html b/static/netbsd/man4/man4.macppc/bm.4 3.html
deleted file mode 100644
index a228e2e8..00000000
--- a/static/netbsd/man4/man4.macppc/bm.4 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
BM(4)Device Drivers Manual (macppc)BM(4)

-

-

-

-
bm — Apple BMac
-    Ethernet device driver

-

-

-

-
bm* at obio?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The bm driver provides support for the
-    BMac Ethernet hardware found mostly in Apple PowerBooks G3s and Power
-    Macintosh G3s.

-

-

-

-
gem(4), mc(4),
-    mii(4), nsphyter(4),
-    tlp(4)

-

-

-

-
The bm device driver appeared in
-    NetBSD 1.4.

-

-

-

-
The bm driver was written by Tsubai
-    Masanari ⟨tsubai@NetBSD.org⟩. The man page was written by
-    Thomas Klausner ⟨wiz@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
May 21, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/gm.4 3.html b/static/netbsd/man4/man4.macppc/gm.4 3.html
deleted file mode 100644
index 6a86bf61..00000000
--- a/static/netbsd/man4/man4.macppc/gm.4 3.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
GM(4)Device Drivers Manual (macppc)GM(4)

-

-

-

-
gm — Apple GMac
-    Ethernet device driver

-

-

-

-
gm* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The gm driver provides support for the
-    GMac Ethernet hardware found mostly in the newest Apple PowerBooks G3s and
-    most G4-based Apple hardware.

-
This driver is now obsolete. You should be using the
-    gem(4) driver.

-
Wireless hardware is not supported by this driver, but by
-    wi(4).

-

-

-

-
brgphy(4), gem(4),
-    macppc/bm(4), macppc/bmtphy(4),
-    mc(4), mii(4), tlp(4),
-    wi(4)

-

-

-

-
The gm device driver appeared in
-    NetBSD 1.5 and is obsoleted by the
-    gem(4) driver.

-

-

-

-
The gm driver was written by Tsubai
-    Masanari ⟨tsubai@NetBSD.org⟩. The man page was written by
-    Thomas Klausner ⟨wiz@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/intro.4 2.html b/static/netbsd/man4/man4.macppc/intro.4 2.html
deleted file mode 100644
index f3a17d9d..00000000
--- a/static/netbsd/man4/man4.macppc/intro.4 2.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (macppc)INTRO(4)

-

-

-

-
intro —
-    introduction to macppc special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Power
-    Macintosh. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    macppc/autoconf(4). A list of the supported devices is
-    given below.

-

-

-

-
config(1), gem(4),
-    macppc/autoconf(4), macppc/awacs(4),
-    macppc/bm(4), mc(4),
-    tlp(4)

-

-

-

-
The macppc intro man page first appeared
-    in NetBSD 1.5.1, based on the
-    NetBSD/mac68k macppc/intro(4).

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-
PCMCIA devices are supported through the
-    pcmcia(4) bus and associated devices.

-
Cardbus devices are supported through the
-    cardbus(4) bus and associated devices.

-
USB devices are supported through the usb(4) bus
-    and associated devices.

-
Additionally, the following specific devices are supported:

-

-

-  

-  
Apple Desktop Bus event interface.

-  

-  
Audio Waveform Amplifier and Converter — Apple Sound Chip
-      (supported systems include 603 and 604 based machines, and Open Firmware 3
-      based machines).

-  

-  
BMac Ethernet.

-  

-  
DECchip 21x4x based Ethernet cards (see also
-    tlp(4)).

-  

-  
NCR 53C9x built-in SCSI interface.

-  

-  
GMac Ethernet.

-  

-  
kernel virtual memory.

-  

-  
MACE Ethernet.

-  

-  
physical memory.

-  

-  
MESH built-in SCSI interface (most Old World machines up to the 1999
-      series of G3 PowerBooks).

-  

-  
NVRAM access.

-  

-  
PCI based frame buffer with Open Firmware support.

-  

-  
Open Firmware access.

-  

-  
DECchip 21x4x based Ethernet cards.

-  

-  
Standard on-board IDE controller.

-  

-  
Zilog Z8530 built-in serial interface.

-

-

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/mesh.4 3.html b/static/netbsd/man4/man4.macppc/mesh.4 3.html
deleted file mode 100644
index eb6bf035..00000000
--- a/static/netbsd/man4/man4.macppc/mesh.4 3.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
MESH(4)Device Drivers Manual (macppc)MESH(4)

-

-

-

-
mesh — Apple
-    Macintosh Enhanced SCSI Hardware driver

-

-

-

-
mesh* at obio? flags 0xffff
-  

-  scsibus* at mesh?

-

-

-

-
The mesh driver provides support for the
-    SCSI host adapters found on most supported models with on-board SCSI. The
-    Apple Network Server models use the esp(4) and
-    esiop(4) devices for SCSI, not
-    mesh.

-
Models supported by mesh are:

-
    
-  
  • Apple PowerBook (2400, 3400, G3, and G3 Series)
    • 
-  
  • Apple PowerBook (G3 Series (bronze keyboard))
    • 
-  
  • Apple Power Macintosh/Performa (4400, 54xx, 5500, 6300/160, 6360, 6400,
-      and 6500)
    • 
-  
  • Apple Power Macintosh (7300, 7500, 7600, 8500, 8600, 9500, and 9600)
    • 
-  
  • Apple Workgroup Server 8550
    • 
-  
  • Apple Power Macintosh G3 (Beige G3)
    • 
-  
  • APS Tech (M*Power 604e/200)
    • 
-  
  • Motorola StarMax (3000, 4000, 5000, and 5500)
    • 
-  
  • Power Computing (PowerBase, PowerCenter, PowerCenter Pro, PowerCurve,
-      PowerTower, PowerTower Pro, and PowerWave)
    • 
-  
  • UMAX (Apus 2000, Apus 3000, C500, and C600)
    • 
-  
  • UMAX (J700, S900)
    • 
-

-
Some models have a separate SCSI bus dedicated to external devices
-    using the esp(4) device. On these systems, the
-    mesh SCSI bus is operated in SCSI
-    ‘Fast’ mode (10 MB/s) and the external
-    esp(4) bus is operated at 5 MB/s. This applies only to the
-    following models:

-
    
-  
  • Apple Power Macintosh (7300, 7500, 7600, 8500, 8600, 9500, and 9600)
    • 
-  
  • Power Computing (PowerCenter, PowerCenter Pro, PowerCurve, PowerTower,
-      PowerTower Pro, and PowerWave)
    • 
-

-

-

-

-
cd(4), ch(4),
-    esiop(4), esp(4),
-    macppc/intro(4), macppc/obio(4),
-    scsi(4), sd(4), ss(4),
-    st(4), uk(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/obio.4 3.html b/static/netbsd/man4/man4.macppc/obio.4 3.html
deleted file mode 100644
index 5beccf0f..00000000
--- a/static/netbsd/man4/man4.macppc/obio.4 3.html	
+++ /dev/null
@@ -1,125 +0,0 @@
-
-  
-    
-    
-    
-  
-
OBIO(4)Device Drivers Manual (macppc)OBIO(4)

-

-

-

-
obio —
-    introduction to Macintosh On-Board IO bus support and
-    drivers

-

-

-

-
obio0 at pci? dev ? function ?

-

-

-

-
The obio interface serves as an
-    abstraction used by the autoconfiguration system to help find and attach
-    devices (e.g. the Ethernet or disk controllers) connected to the Macintosh
-    onboard I/O bus.

-

-

-

-
NetBSD includes machine-dependent On-Board
-    drivers, sorted by device type and driver name:

-

-

-

-

-  
esp

-  
NCR 53C9x SCSI interfaces.

-  
mesh

-  
Apple Macintosh Enhanced SCSI Hardware SCSI interfaces.

-

-

-

-

-

-

-

-  
wdc

-  
Standard IDE/ATAPI type hard drive controllers.

-  
mediabay

-  
Standard IDE/ATAPI type CD-ROM drive controllers in PowerBooks.

-

-

-

-

-

-

-

-  
bm

-  
Apple BMac ethernet interface.

-  
mc

-  
Apple MACE ethernet interface.

-  
gem

-  
GMAC ethernet interface.

-  
wi

-  
WaveLAN/IEEE and PRISM-II 802.11 wireless interfaces.

-

-

-

-

-

-

-

-  
zsc

-  
Zilog 8530 serial communications interfaces.

-

-

-

-

-

-

-

-  
awacs

-  
Apple's ‘audio waveform amplifier and converter for sound’
-      audio device found on most macppc models.

-

-

-

-

-

-

-

-  
adb

-  
Apple Desktop Bus for keyboards, mice, and other input devices.

-  
nvram

-  
Placeholder device for the persistent system settings.

-

-

-

-

-

-

-
adb(4), esp(4),
-    gem(4), macppc/autoconf(4),
-    macppc/awacs(4), macppc/bm(4),
-    macppc/intro(4), macppc/mesh(4),
-    mc(4), wdc(4), wi(4),
-    zsc(4)

-

-

-

-
obio first appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
March 30, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/pbms.4 3.html b/static/netbsd/man4/man4.macppc/pbms.4 3.html
deleted file mode 100644
index 3b053584..00000000
--- a/static/netbsd/man4/man4.macppc/pbms.4 3.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
PBMS(4)Device Drivers Manual (macppc)PBMS(4)

-

-

-

-
pbms — PowerBook
-    (and iBook) trackpad mouse support

-

-

-

-
pbms? at uhidev? reportid ?
-  

-  wsmouse* at pbms?

-

-

-

-
The pbms driver provides support for the
-    trackpads on new (post February 2005) Apple PowerBooks and iBooks that are
-    not standard USB HID mice. Access to the trackpad is through the
-    wscons(4) framework.

-

-

-

-
uhidev(4), usb(4),
-    wsmouse(4)

-

-

-

-
The pbms device driver appeared in
-    NetBSD 4.0.

-

-

-

-
The pbms driver was written by
-    Johan Wallén.

-

-

-
-  
-    
-    
-  
-
February 5, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/platinumfb.4 3.html b/static/netbsd/man4/man4.macppc/platinumfb.4 3.html
deleted file mode 100644
index d01d19ee..00000000
--- a/static/netbsd/man4/man4.macppc/platinumfb.4 3.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
PLATINUMFB(4)Device Drivers Manual (macppc)PLATINUMFB(4)

-

-

-

-
platinumfb — Apple
-    Platinum framebuffer driver

-

-

-

-
platinumfb0 at mainbus?

-

-

-

-
The platinumfb driver provides support for
-    Apple Platinum graphics devices found in a couple early model PowerMacs such
-    as the 7200.

-
This driver should support console output (with raster ops) and X
-    (in unaccelerated modes).

-
It may be required to set the output-device to 'platinum' in Open
-    Firmware.

-

-

-

-
wsdisplay(4), rasops(9)

-

-

-

-
The platinumfb device driver appeared in
-    NetBSD 7.0.

-

-

-

-
The platinumfb driver was written by
-    Sean Cole.

-

-

-

-
Early PowerMacs with the platinumfb device
-    may not work through Open Firmware.

-
X(7) is pretty slow.

-

-

-
-  
-    
-    
-  
-
December 11, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.macppc/snapper.4 3.html b/static/netbsd/man4/man4.macppc/snapper.4 3.html
deleted file mode 100644
index 219aeb88..00000000
--- a/static/netbsd/man4/man4.macppc/snapper.4 3.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
SNAPPER(4)Device Drivers Manual (macppc)SNAPPER(4)

-

-

-

-
snapper — Apple
-    audio device driver

-

-

-

-
snapper* at obio?
-  

-  audio* at snapper?

-

-

-

-
The snapper driver provides support for
-    audio hardware using the TAS3004 chipset found in many Apple iBooks,
-    PowerBooks, and PowerMacs. Other i2s compatible controllers found in Mac
-    Minis, which lack a TAS3004, are also supported.

-
Hardware features:

-
    
-  
  • Supports data word lengths of 16 to 24 bits
    • 
-  
  • Processes sample rates from 32kHz to 48kHz
    • 
-  
  • Provides digital equalization and compression capabilities
    • 
-

-

-

-

-
audio(4), macppc/awacs(4)

-

-

-

-
The snapper device driver appeared in
-    NetBSD 2.0.

-

-

-

-
The snapper driver was written by
-    Tsubai Masanari
-    <tsubai@NetBSD.org>
-    with modifications by Jared D. McNeill
-    <jmcneill@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 30, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/clmpcc.4 3.html b/static/netbsd/man4/man4.mvme68k/clmpcc.4 3.html
deleted file mode 100644
index 70c60619..00000000
--- a/static/netbsd/man4/man4.mvme68k/clmpcc.4 3.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
CLMPCC(4)Device Drivers Manual (mvme68k)CLMPCC(4)

-

-

-

-
clmpcc — Cirrus
-    Logic CD2400/CD2401 serial communications controller

-

-

-

-
clmpcc0 at pcctwo? ipl 4

-

-

-

-
The clmpcc driver provides support for the
-    Cirrus Logic CD2401 Multi-protocol Communications Controller found on
-    Motorola MVME167 and MVME177 single-board computers.

-
The chip integrates four serial channels in one package, with each
-    channel being completely independent and capable of running in Async (with
-    optional DMA control), Bisync, HDLC/SDLC and X.21 modes. Each channel has 32
-    bytes of FIFO, split into 16 bytes for the Tx side and 16 bytes for the Rx
-    side.

-
At the present time, the clmpcc driver
-    supports the non-DMA Async mode of operation, using the channel FIFOs to
-    maximize throughput with minimal interrupt overhead.

-
The Motorola MVME1x7 boards provide a 20MHz master clock to the
-    device, which allows the Tx and Rx side to be independently set to any baud
-    rate in the range 50 to 57600. The device should be capable of running at a
-    baud rate of 115200, however it is not a rate documented in the device's
-    datasheet for Async. mode so is not recommended.

-

-

-

-

-  
/dev/console

-  
 

-  
/dev/ttyC1

-  
 

-  
/dev/ttyC2

-  
 

-  
/dev/ttyC3

-  
 

-

-

-

-

-

-  
clmpcc%d: channel %d command timeout (idle)

-  
The chip failed to acknowledge a command sent to the specified
-    channel.

-  
clmpcc%d: Failed to reset chip

-  
The clmpcc driver was unable to determine if the
-      chip completed its RESET processing.

-

-

-

-

-
mvme68k/pcctwo(4), tty(4)

-

-

-

-
The clmpcc driver first appeared in
-    NetBSD 1.4 and is currently under development.

-

-

-

-
The hardware flow control features of the chip are not yet fully
-    supported.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/intro.4 3.html b/static/netbsd/man4/man4.mvme68k/intro.4 3.html
deleted file mode 100644
index 337d5293..00000000
--- a/static/netbsd/man4/man4.mvme68k/intro.4 3.html	
+++ /dev/null
@@ -1,113 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (mvme68k)INTRO(4)

-

-

-

-
intro —
-    introduction to mvme68k special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Motorola
-    MVME68K series of single board computers . Software support for these
-    devices comes in two forms. A hardware device may be supported with a
-    character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    mvme68k/autoconf(4). A list of the supported devices is
-    given below.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-  

-  
Cirrus Logic CD2401 four channel Communications controller

-  

-  
Hardware counter/timer clock driver

-  

-  
Intel 82596-based Ethernet interface

-  

-  
kernel virtual memory

-  

-  
AMD Lance-based Ethernet interface

-  

-  
Onboard parallel printer interface

-  

-  
physical memory

-  

-  
MVME162 and MVME172 MCChip (similar to PCCchip2)

-  

-  
NCR 53c710 SCSI I/O Processor

-  

-  
MVME147 PCC Chip

-  

-  
MVME167 and MVME177 PCCchip2

-  

-  
MVME147 VMEbus interface chip

-  

-  
MVME1[67]x Enhanced VMEbus interface chip

-  

-  
WD33c93 SCSI Bus Interface Controller

-  

-  
Zilog Z8530 Dual-port Serial Interface on MVME147 and MVME162

-

-

-

-

-

-
config(1),
-  mvme68k/autoconf(4)

-

-

-

-
The mvme68k intro man page first appeared
-    in NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/mem.4 3.html b/static/netbsd/man4/man4.mvme68k/mem.4 3.html
deleted file mode 100644
index ec4efd6b..00000000
--- a/static/netbsd/man4/man4.mvme68k/mem.4 3.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (mvme68k)MEM(4)

-

-

-

-
mem, kmem —
-    main memory

-

-

-

-
The file /dev/mem is an interface to the
-    physical memory of the computer. Byte offsets in this file are interpreted
-    as physical memory addresses. Reading and writing this file is equivalent to
-    reading and writing memory itself. An error will be returned if an attempt
-    is made to reference an offset outside of
-  /dev/mem.

-
Kernel virtual memory is accessed via the file
-    /dev/kmem in the same manner as
-    /dev/mem. Only kernel virtual addresses that are
-    currently mapped to memory are allowed.

-
On the Motorola MVME series of single board computers, physical
-    memory may be discontiguous; kernel virtual memory begins at
-    0x00008000.

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-

-

-

-

-
The files mem and
-    kmem appeared in Version 6
-    AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
November 28, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/memc.4 3.html b/static/netbsd/man4/man4.mvme68k/memc.4 3.html
deleted file mode 100644
index 5cddc300..00000000
--- a/static/netbsd/man4/man4.mvme68k/memc.4 3.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEMC(4)Device Drivers Manual (mvme68k)MEMC(4)

-

-

-

-
memc —
-    MVME162-MVME177 Memory Controller Chip

-

-

-

-
memc* at mainbus0

-

-

-

-
The memc devices are used on MVME162,
-    MVME167, MVME172 and MVME177 boards to manage one or more DRAM modules.

-
Depending on the type of DRAM module fitted, the device will
-    either be a MEMC040 device or an MCECC device. The former manages a Parity
-    DRAM module while the latter manages an ECC DRAM module.

-

-

-

-

-  
memc0 at mainbus0.

-  
This is the normal autoconfiguration message indicating that the Memory
-      Controller Chip has been found and attached to the main processor
-    bus.

-  
memc0: Correctable error on CPU read access to 0x12345678.

-  
This indicates that an MCECC memory controller detected and corrected a
-      single bit error in one of the DRAM banks. There are a few variations on
-      the message where "CPU" can be replaced with "Peripheral
-      Device" or "Scrubber", and "read" can be
-      substituted for "write". This message is followed by some more
-      details which can help pin-point the error...

-  
memc0: ECC Syndrome 0x23 (DRAM Bank C, Bit#16).

-  
Pin-points exactly where the error occurred.

-  
memc0: Uncorrectable error on CPU read access to 0x12345678.

-  
Errors like this have the potential to corrupt data. As such, it is likely
-      the system will panic very soon afterwards.

-

-

-

-

-
mvme68k/mainbus(4)

-

-

-

-
The memc driver does not yet fully support
-    the MEMC040 (Parity) version of the device.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/ncrsc.4 3.html b/static/netbsd/man4/man4.mvme68k/ncrsc.4 3.html
deleted file mode 100644
index 0df6e8a8..00000000
--- a/static/netbsd/man4/man4.mvme68k/ncrsc.4 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
NCRSC(4)Device Drivers Manual (mvme68k)NCRSC(4)

-

-

-

-
ncrsc — NCR 53c710
-    SCSI I/O Processor

-

-

-

-
ncrsc0 at pcctwo? ipl 2

-

-

-

-
The ncrsc driver provides an abstraction
-    layer between the SCSI hardware fitted to Motorola MVME167 and MVME177
-    single board computers (NCR73C710), and the machine independent SCSI drivers
-    described in scsibus(4).

-
In addition to sending the required SCSI commands to target
-    devices on the SCSI bus, the ncrsc driver deals with
-    DMA, device interrupts, sync/async negotiation and target
-    disconnects/reconnects.

-

-

-

-
Too many to mention.

-

-

-

-
mvme68k/pcctwo(4),
-  scsibus(4)

-

-

-

-
The current ncrsc driver should be
-    obsoleted and replaced with a machine independent version.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/pcc.4 3.html b/static/netbsd/man4/man4.mvme68k/pcc.4 3.html
deleted file mode 100644
index 9b5efd86..00000000
--- a/static/netbsd/man4/man4.mvme68k/pcc.4 3.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCC(4)Device Drivers Manual (mvme68k)PCC(4)

-

-

-

-
pcc — MVME147
-    Peripheral Channel Controller device

-

-

-

-
pcc0 at mainbus0

-

-

-

-
The pcc interface serves as an abstraction
-    used by the mvme68k/autoconf(4) system to help find and
-    attach devices whose resources are accessed via the PCC chip. (e.g. the
-    Ethernet and SCSI controllers)

-

-

-

-

-  
pcc0 at mainbus0.

-  
This is the normal autoconfiguration message indicating that the PCC chip
-      has been found and attached to the main processor bus.

-

-

-

-

-
mvme68k/autoconf(4),
-    mvme68k/mainbus(4),
-  mvme68k/pcctwo(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/pcctwo.4 3.html b/static/netbsd/man4/man4.mvme68k/pcctwo.4 3.html
deleted file mode 100644
index 7532947e..00000000
--- a/static/netbsd/man4/man4.mvme68k/pcctwo.4 3.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCCTWO(4)Device Drivers Manual (mvme68k)PCCTWO(4)

-

-

-

-
pcctwo —
-    MVME167/MVME177 Peripheral Channel Controller 2
-    device

-

-

-

-
pcctwo0 at mainbus0

-

-

-

-
The pcctwo interface serves as an
-    abstraction used by the mvme68k/autoconf(4) system to help
-    find and attach devices whose resources are accessed via the PCCchip2 found
-    on Motorola MVME167 and MVME177 single board computers. (e.g. the Ethernet
-    and SCSI controllers)

-

-

-

-

-  
pcctwo0 at mainbus0.

-  
This is the normal autoconfiguration message indicating that the PCCchip2
-      has been found and attached to the main processor bus.

-

-

-

-

-
mvme68k/autoconf(4),
-    mvme68k/mainbus(4), mvme68k/pcc(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/wdsc.4 3.html b/static/netbsd/man4/man4.mvme68k/wdsc.4 3.html
deleted file mode 100644
index 9e92f5e3..00000000
--- a/static/netbsd/man4/man4.mvme68k/wdsc.4 3.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
WDSC(4)Device Drivers Manual (mvme68k)WDSC(4)

-

-

-

-
wdsc — Western
-    Digital WD33c93 SCSI Bus Interface Controller

-

-

-

-
wdsc0 at pcc? ipl 2

-

-

-

-
The wdsc driver provides an abstraction
-    layer between the SCSI hardware fitted to the Motorola MVME147 single board
-    computer (WD33C93), and the machine independent SCSI drivers described in
-    scsibus(4).

-
In addition to sending the required SCSI commands to target
-    devices on the SCSI bus, the wdsc driver deals with
-    DMA, device interrupts, sync/async negotiation and target
-    disconnects/reconnects.

-

-

-

-
Too many to mention.

-

-

-

-
mvme68k/pcc(4), scsibus(4)

-

-

-

-
Negotiation of Synchronous SCSI data transfers has been
-    deliberately disabled in the MVME147's wdsc driver
-    as it has proved extremely difficult to make it work reliably in this
-  mode.

-
The wdsc driver does not respond well to
-    exceptional conditions caused by poor SCSI cabling and/or termination. In
-    those instances the machine is likely to require a hard reset to
-  recover.

-
The current wdsc driver should be blown
-    away and replaced with a machine independent version.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.mvme68k/zsc.4 3.html b/static/netbsd/man4/man4.mvme68k/zsc.4 3.html
deleted file mode 100644
index cdd87cb0..00000000
--- a/static/netbsd/man4/man4.mvme68k/zsc.4 3.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZSC(4)Device Drivers Manual (mvme68k)ZSC(4)

-

-

-

-
zsc — serial
-    communications interface

-

-

-

-
zsc0 at pcc? ipl 4

-

-

-

-
The zsc driver provides support for the
-    two Z8530- EIA RS-232C (CCITT V.28) dual channel communications interfaces
-    present on Motorola MVME147 single board computers. The
-    zsc driver implements a convenient abstraction
-    layer, which provides two channels per chip for the
-    zstty(4) driver to attach to.

-

-

-

-

-  
/dev/console

-  
 

-  
/dev/ttyZ1

-  
 

-  
/dev/ttyZ2

-  
 

-  
/dev/ttyZ3

-  
 

-

-

-

-

-
mvme68k/pcc(4), zstty(4)

-

-

-

-
Data loss is possible when using the higher bitrates on busy
-    systems.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/asc.4 3.html b/static/netbsd/man4/man4.pmax/asc.4 3.html
deleted file mode 100644
index d123fc8a..00000000
--- a/static/netbsd/man4/man4.pmax/asc.4 3.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
ASC(4)Device Drivers Manual (pmax)ASC(4)

-

-

-

-
asc — TURBOchannel
-    single-channel SCSI adapter

-

-

-

-
asc* at ioasic? offset ?
-  

-  asc* at tc? slot ? offset ?
-  

-  asc* at tcds? chip?
-  

-  scsibus* at asc?

-

-

-

-
The asc driver provides support for the
-    NCR 53c94-based SCSI host adapter on the DECstation 5000 series, and for the
-    PMAZ-AA and related TURBOchannel SCSI-adapter option boards. The
-    asc is a medium-performance implementation of the
-    SCSI-I common command set supporting synchronous and asynchronous SCSI
-    devices. The driver provides no support for targets with multiple Logical
-    Unit Numbers (LUNs).

-

-

-

-
cd(4), ch(4),
-    ioasic(4), pmax/intro(4),
-    scsi(4), sd(4), st(4),
-    tc(4), tcds(4)

-

-

-

-
The asc driver first appeared in
-    4.4BSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/autoconf.4 3.html b/static/netbsd/man4/man4.pmax/autoconf.4 3.html
deleted file mode 100644
index 68a1138a..00000000
--- a/static/netbsd/man4/man4.pmax/autoconf.4 3.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (pmax)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel. Devices which
-    exist in the machine but are not configured into the kernel are not
-    detected.

-

-

-

-

-  
CPU type (0x%x) not supported.

-  
You tried to boot NetBSD on a type of CPU type
-      which it doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-

-

-

-

-
config(1), pmax/intro(4),
-    boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/ibus.4 3.html b/static/netbsd/man4/man4.pmax/ibus.4 3.html
deleted file mode 100644
index 3ef3b8d6..00000000
--- a/static/netbsd/man4/man4.pmax/ibus.4 3.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
IBUS(4)Device Drivers Manual (pmax)IBUS(4)

-

-

-

-
ibus — pmax
-    internal I/O space driver

-

-

-

-
ibus0 at mainbus0
-  

-  ibus0 at tc? slot ? offset ?

-

-

-

-
ibus is a virtual device corresponding to
-    the pmax internal I/O space found on DEC 2100, 3100, 5100 and 5000/200
-    systems.

-
Internal I/O space spans the pmax physical address space, and is
-    mapped permanently in the kernel virtual space at the very early time of the
-    kernel startup procedure.

-
ibus driver manages the internal I/O space
-    of pmax.

-
    
-  
  • Address range management to avoid confliction of address space of which
-      devices probe by touching hardware port is difficult.
    • 
-  
  • Interrupt vector management.
    • 
-  
  • bus_space(9) and bus_dma(9)
-      implementation.
    • 
-  
  • Other utility functions.
    • 
-

-
ibus is always required to run the
-    NetBSD kernel.

-

-

-

-
pmax/intro(4), bus_dma(9),
-    bus_space(9)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/intro.4 2.html b/static/netbsd/man4/man4.pmax/intro.4 2.html
deleted file mode 100644
index 6b307c90..00000000
--- a/static/netbsd/man4/man4.pmax/intro.4 2.html	
+++ /dev/null
@@ -1,175 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (pmax)INTRO(4)

-

-

-

-
intro —
-    introduction to pmax special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the pmax
-    (MIPS-based DECstation/DECsystem) platform. Software support for these
-    devices comes in two forms. A hardware device may be supported with a
-    character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    pmax/autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1),
-  pmax/autoconf(4)

-

-

-

-
The following systems are supported:

-

-

-

-  
DECstation 2100 and 3100

-  
also known as "PMIN" and "PMAX". The 2100 and 3100
-      differ only in CPU clock speed.

-  
DECsystem 5100

-  
also known as "MIPSMATE".

-  
DECstation 5000/200

-  
also known as "3MAX". The 5000/200 has a 25 MHz R3000 and is the
-      first-generation TURBOchannel platform.

-  
DECstation 5000/1xx

-  
also known as "3MIN" or "kmin". The 5000/1xx comes in
-      20 MHz, 25 MHz, and 33 MHz versions and is numbered appropriately. Two
-      12.5 MHz TURBOchannel slots are provided.

-  
DECstation 5000/xx

-  
also known as "Personal DECstation" or "MAXINE". The
-      5000/xx comes in 20 MHz, 25 MHz, and 33 MHz variants. A baseboard 1024x786
-      framebuffer, and two 12.5 MHz TURBOchannel slots are provided.

-  
DECstation 5000/240 and DECsystem 5900

-  
also known as "3MAXPLUS". These systems have a 40 MHz R3400 CPU
-      and three 25 MHz TURBOchannel slots. The 5900 is an expanded-cabinet
-      version of the 5000/240.

-

-

-
TURBOchannel systems (except the 5000/200) can be upgraded to an
-    R4000 or R4400 CPU by upgrading the CPU daughterboard.

-
The Qbus-based DECsystem 5400 and 5500 are not supported.

-
The multi-processor XMI-bus DECsystem 5800 is not supported.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-

-  
asc

-  
NCR 53c94-based SCSI interface, either on DECstation 5000-series baseboard
-      or PMAZ-AA SCSI option card.

-  
bba

-  
baseboard audio on 5000/xx systems.

-  
dz

-  
serial driver for DEC custom four-port serial device (dc7085 DZ-11 clone)
-      on the baseboard of DECstation 2100/3100, 5100, and 5000/200 systems.

-  
zsc

-  
serial driver for Zilog SCC asynchronous/synchronous devices on the
-      baseboard of DECstation 5000-series systems (excluding 5000/200).

-  
le

-  
Ethernet driver for baseboard or TURBOchannel option cards.

-  
ioasic

-  
Adaptor for the baseboard IO ASIC on second-generation TURBOchannel
-      machines. An ioasic must be configured on a 5000/1xx, 5000/xx, and
-      5000/240 if support for baseboard devices or the TURBOchannel bus is
-      desired.

-  
wsdisplay

-  
Pseudo-device driver supporting glass-tty console emulation on DEC
-      framebuffers, DEC mice, and LK-201 family keyboards.

-  
sii

-  
DEC custom SCSI adaptor on DECstation 2100, 3100, and 5100.

-  
pm

-  
DECstation 2100/3100 baseboard framebuffer

-  
tc

-  
Adaptor for the TURBOchannel I/O expansion bus. This must be included if
-      any TURBOchannel option cards are supported, or for the baseboard Ethernet
-      and SCSI devices on a 5000/200.

-  
cfb

-  
PMAG-B TURBOchannel 1024x876 unaccelerated 2-D framebuffer.

-  
sfb

-  
PMAGB-BA TURBOchannel 1280x1024 accelerated framebuffer.

-  
mfb

-  
PMAG-AA TURBOchannel 1280x1024 mono/greyscale unaccelerated
-    framebuffer.

-  
tfb

-  
PMAG-JA and PMAG-RO TURBOchannel 1280x1024 unaccelerated framebuffer.

-  
px

-  
PMAG-C TURBOchannel 2-D accelerated graphics board.

-  
pxg

-  
PMAG-D, E and F TURBOchannel 2-D/3-D accelerated graphics boards.

-

-

-

-

-

-
The following devices are not supported, due to unavailability of
-    either documentation or sample hardware:

-

-

-

-  
LoFi

-  
DEC Western Research Labs audio card

-

-

-
The floppy-disk drive on the MAXINE baseboard is currently not
-    supported.

-

-

-

-
This pmax intro appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
July 28, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/pm.4 3.html b/static/netbsd/man4/man4.pmax/pm.4 3.html
deleted file mode 100644
index ba944712..00000000
--- a/static/netbsd/man4/man4.pmax/pm.4 3.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
PM(4)Device Drivers Manual (pmax)PM(4)

-

-

-

-
pm — DECstation
-    2100/3100 baseboard framebuffer

-

-

-

-
pm* at ibus? addr ?
-  

-  wsdisplay* at pm?

-

-

-

-
The pm driver provides support for the
-    2100/3100 baseboard framebuffer. It can operate as either a monochrome
-    framebuffer (with memory part number VFB01) or an 8 bpp colour framebuffer
-    (with memory part number VFB02). Both provide 16x16 hardware sprite
-  cursor.

-

-

-

-
cfb(4), mfb(4),
-    pmax/xcfb(4), px(4),
-    pxg(4), sfb(4), tc(4),
-    tfb(4), wscons(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/sii.4 3.html b/static/netbsd/man4/man4.pmax/sii.4 3.html
deleted file mode 100644
index 7076f288..00000000
--- a/static/netbsd/man4/man4.pmax/sii.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
SII(4)Device Drivers Manual (pmax)SII(4)

-

-

-

-
sii — SII SCSI
-    adaptor

-

-

-

-
sii* at ibus0 addr ?
-  

-  scsibus* at sii?

-

-

-

-
The sii driver provides support for the
-    DEC SII SCSI adaptor ASIC used in the DECstation 2100, 3100, and 5100.

-
The sii is a medium-performance
-    implementation of the SCSI-I common command set supporting synchronous and
-    asynchronous SCSI devices.

-
The SII cabling is unusual: the bulkhead connector is very similar
-    to a standard submicro wide SCSI-II connector, but has the other gender.

-
The sii chip only supports DMA to or from
-    a fixed window in memory. The driver uses this "window" area as a
-    bounce buffer, copying data to and from the DMA region.

-

-

-

-
cd(4), ch(4),
-    pmax/ibus(4), pmax/intro(4),
-    scsi(4), sd(4),
-  st(4)

-

-

-

-
The sii driver first appeared in
-    4.4BSD.

-

-

-
-  
-    
-    
-  
-
July 28, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.pmax/xcfb.4 3.html b/static/netbsd/man4/man4.pmax/xcfb.4 3.html
deleted file mode 100644
index 4533b533..00000000
--- a/static/netbsd/man4/man4.pmax/xcfb.4 3.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
XCFB(4)Device Drivers Manual (pmax)XCFB(4)

-

-

-

-
xcfb — DECstation
-    5000/xx PMAG-DV colour framebuffer

-

-

-

-
xcfb* at tc? slot ? offset ?
-  

-  wsdisplay* at xcfb?

-

-

-

-
The xcfb driver provides support for the
-    PMAG-DV framebuffer found on the DECstation 5000/xx baseboard. It is an 8
-    bpp colour framebuffer capable of running at a resolution of 1024-by-768 at
-    66 Hz.

-

-

-

-
cfb(4), mfb(4),
-    pmax/pm(4), px(4),
-    pxg(4), sfb(4), tc(4),
-    tfb(4), wscons(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.prep/intro.4 3.html b/static/netbsd/man4/man4.prep/intro.4 3.html
deleted file mode 100644
index d17795f2..00000000
--- a/static/netbsd/man4/man4.prep/intro.4 3.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (prep)INTRO(4)

-

-

-

-
intro —
-    introduction to prep special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the PowerPC
-    Reference Platform machines. Software support for these devices comes in two
-    forms. A hardware device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), autoconf(4),
-    pnpbus(4), prep/nvram(4)

-

-

-

-
The prep intro man page first appeared in
-    NetBSD 4.0.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-
The pnpbus is a pseudo-bus which is a configuration interface for
-    certain devices on PReP machines. These devices are defined in the PReP
-    residual data with configuration information, similar to
-    isapnp(4). The underlying bus is generally ISA.

-
ISA devices are supported through the isa(4) bus
-    and associated devices.

-
PCI devices are supported through the pci(4) bus
-    and associated devices.

-
USB devices are supported through the usb(4) bus
-    and associated devices.

-
Additionally, the following specific devices are supported:

-

-

-  

-  
serial ports

-  

-  
NVRAM chip

-  

-  
ISA IDE controller

-  

-  
Western Digital/SMC WD80x3 ethernet driver

-  

-  
mc146818 compatible time-of-day clock

-  

-  
Mostek MK48T18 time-of-day chip

-

-

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.prep/nvram.4 3.html b/static/netbsd/man4/man4.prep/nvram.4 3.html
deleted file mode 100644
index b4823126..00000000
--- a/static/netbsd/man4/man4.prep/nvram.4 3.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
NVRAM(4)Device Drivers Manual (prep)NVRAM(4)

-

-

-

-
nvram — PReP nvram
-    interface

-

-

-

-
#include
-    <machine/nvram.h>

-

-

-

-
The file /dev/nvram is an interface to the
-    PReP NVRAM, including the Global Environment Area. This interface is highly
-    stylized; ioctls are used for all operations. These ioctls refer to
-    individual variables in the Global Environment Area and their values.

-
The calls that take and/or return a variable use a pointer to an
-    int variable for this purpose; others use a pointer
-    to an struct pnviocdesc descriptor, which contains a
-    variable and two counted strings. The first string comprises the fields
-    pnv_namelen (an int) and
-    pnv_name (a char *), giving
-    the name of a field. The second string comprises the fields
-    pnv_buflen and pnv_buf, used
-    analogously. These two counted strings work in a
-    “value-result” fashion. At entry to the ioctl, the counts are
-    expected to reflect the buffer size; on return, the counts are updated to
-    reflect the buffer contents.

-
The following ioctls are supported:

-

-  
PNVIOCGETNEXTNAME

-  
Takes a variable name and returns the name of the following variable. If a
-      NULL is passed as the variable name, the first
-      variable name will be returned. If the last variable is given as an
-      argument, the ioctl will return EINVAL.

-  

-  
Fills in the value of the named property for the given variable. If no
-      such property is associated with that variable, the value length is set to
-      -1. If the named property exists but has no value, the value length is set
-      to 0.

-  

-  
Writes the given value under the given name.

-  

-  
Returns the number of variables in the Global Environment Area.

-

-

-

-

-
/dev/nvram

-

-

-

-
The following may result in rejection of an operation:

-

-  
[]

-  
The given variable name does not exist; or the buffer set up to retrieve
-      values from the nvram was not large enough to hold the result.

-

-

-

-

-
ioctl(2)

-
PowerPC Reference Platform Specification Version
-    1.1, Section 5.5

-

-

-

-
Due to limitations within the nvram
-    itself, these functions run at elevated priority and may adversely affect
-    system performance.

-
PNVIOCSET is not currently supported,
-    making the nvram driver read-only at this time.

-

-

-
-  
-    
-    
-  
-
March 1, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sandpoint/nhpow.4 3.html b/static/netbsd/man4/man4.sandpoint/nhpow.4 3.html
deleted file mode 100644
index 8acdbf9f..00000000
--- a/static/netbsd/man4/man4.sandpoint/nhpow.4 3.html	
+++ /dev/null
@@ -1,173 +0,0 @@
-
-  
-    
-    
-    
-  
-
NHPOW(4)Device Drivers Manual (sandpoint)NHPOW(4)

-

-

-

-
nhpow — driver for
-    the NH-230/231 board control GPIO pins

-

-

-

-
nhpow0 at mainbus0
-  

-  gpio* at nhpow0

-

-

-

-
This driver initializes the LEDs and the fan speed during boot and
-    establishes a reboot and power-off hook in the kernel.

-
nhpow also detects a soft power-off
-    condition, which is triggered by holding the front panel power button
-    pressed for several seconds. This driver can optionally invoke
-    powerd(8) to get a finer control over the system shutdown
-    procedure. It is capable of reporting a power-button-pressed event. Refer to
-    the powerd(8) manual section for more details.

-
The nhpow driver provides access to its 8
-    bidirectional GPIO pins through the gpio(4) controller
-    interface. The pins have the following meaning when being written:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
highSystem power off
highAssert system reset to all devices
lowStatus LED
highHigh speed fan
lowDebug LED 1
lowDebug LED 2
lowUSB port 1 LED
lowUSB port 2 LED

-
When reading, the pins have the following meaning:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
lowPower button pressed
lowReset/install button pressed
highH/W version bit 0
highH/W version bit 1
highH/W version bit 2
highH/W version bit 3

-
nhpow attaches automatically for all
-    NH-230/231 compatible products:

-
    
-  
  • Allnet 6250
    • 
-  
  • Allnet 6260
    • 
-  
  • Encore ENNHD-1000
    • 
-  
  • Fujitsu-Siemens AMS150
    • 
-  
  • Fujitsu-Siemens SBLAN2
    • 
-  
  • Longshine LCS-8311
    • 
-  
  • Netronix NH-230
    • 
-  
  • Netronix NH-231
    • 
-  
  • Planex NAS-01G
    • 
-

-

-

-

-
The following sysctl(3) variables are
-  available:

-

-  
machdep.nhpow.fan

-  
Sets the fan speed to high (1) or low (0).

-

-

-

-

-

-  
/dev/power

-  
event notify channel to powerd(8).

-

-

-

-

-
gpio(4), gpioctl(8),
-    powerd(8), sysctl(8)

-

-

-

-
The nhpow driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The nhpow driver was written by
-    Frank Wille.

-

-

-
-  
-    
-    
-  
-
January 15, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sandpoint/satmgr.4 3.html b/static/netbsd/man4/man4.sandpoint/satmgr.4 3.html
deleted file mode 100644
index 59b44b9a..00000000
--- a/static/netbsd/man4/man4.sandpoint/satmgr.4 3.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
SATMGR(4)Device Drivers Manual (sandpoint)SATMGR(4)

-

-

-

-
satmgr — driver
-    for satellite processor, controlling power, front panel LEDs, and
-    buttons

-

-

-

-
satmgr0 at eumb? unit 0
-  

-  satmgr0 at eumb? unit 1

-

-

-

-
This driver provides an interface to the NAS builtin satellite
-    microprocessor which controls the power, front panel LEDs, and push buttons.
-    Communication is performed through character sequences, whose definition and
-    usage depend on the NAS product models.

-
The device file /dev/satmgr can be written
-    to control the satellite processor and the LEDs. Reading it will return
-    single characters for button press events. This facility was designed to
-    implement a NAS control CGI program.

-
satmgr detects a soft power-off condition,
-    which is triggered by holding the front panel power button pressed for
-    several seconds. This driver can optionally invoke
-    powerd(8) to get a finer control over the system shutdown
-    procedure. It is capable of reporting a power-button-pressed event. Refer to
-    the powerd(8) manual section for more details.

-
NAS products supported by satmgr:

-
    
-  
  • Buffalo LinkStation
    • 
-  
  • Conceptronic CH3WNAS
    • 
-  
  • D-Link DSM-G600 (Rev. B)
    • 
-  
  • Iomega StorCenter
    • 
-  
  • KuroBox
    • 
-  
  • LevelOne FNS-5000B
    • 
-  
  • QNAP TurboStation
    • 
-  
  • Synology DiskStation
    • 
-

-

-

-

-
The following sysctl(3) variables are available
-    for Kurobox/Linkstation NAS products:

-

-  
machdep.satmgr.hwwdog_enable

-  
Toggle the system watchdog on (1) or off (0).

-

-
For the Iomega StorCenter the following variables have been
-    defined:

-

-  
machdep.satmgr.fan_low_temp

-  
Set the temperature below which the fan is turned off.

-  
machdep.satmgr.fan_high_temp

-  
Set the temperature above which the fan is turned on.

-

-

-

-

-

-  
/dev/satmgr

-  
communication interface to satmgr.

-  
/dev/power

-  
event notify channel to powerd(8).

-

-

-

-

-
powerd(8), sysctl(8)

-

-

-

-
The satmgr driver first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
January 15, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/crime.4 3.html b/static/netbsd/man4/man4.sgimips/crime.4 3.html
deleted file mode 100644
index 5be5384a..00000000
--- a/static/netbsd/man4/man4.sgimips/crime.4 3.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRIME(4)Device Drivers Manual (sgimips)CRIME(4)

-

-

-

-
crime — CPU,
-    Rendering, Interconnect and Memory Engine

-

-

-

-
crime0 at mainbus0 addr 0x14000000

-

-

-

-
The crime ASIC acts as a controller
-    between the CPU and VICE, MACE, the graphics back-end, and main memory.
-    crime can be typically found in O2 machines.

-

-

-

-
sgimips/mace(4)

-

-

-

-
The crime driver first appeared in
-    NetBSD 1.5.

-

-

-

-
crime does not pay.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/dpclock.4 3.html b/static/netbsd/man4/man4.sgimips/dpclock.4 3.html
deleted file mode 100644
index 7529e76a..00000000
--- a/static/netbsd/man4/man4.sgimips/dpclock.4 3.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
DPCLOCK(4)Device Drivers Manual (sgimips)DPCLOCK(4)

-

-

-

-
dpclock — DP8573A
-    real-time clock

-

-

-

-
dpclock* at hpc0 offset ?

-

-

-

-
The dpclock driver provides support for
-    the DP8573A real-time clock (RTC). This device appears on SGI Personal Iris
-    4D/2x, 4D/3x and Indigo machines. Note that the kernel expects the RTC to
-    run in UTC.

-

-

-

-
sgimips/dsclock(4),
-    sgimips/intro(4)

-

-

-

-
The dpclock driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/dsclock.4 3.html b/static/netbsd/man4/man4.sgimips/dsclock.4 3.html
deleted file mode 100644
index 71d25045..00000000
--- a/static/netbsd/man4/man4.sgimips/dsclock.4 3.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
DSCLOCK(4)Device Drivers Manual (sgimips)DSCLOCK(4)

-

-

-

-
dsclock — DS1286
-    real-time clock

-

-

-

-
dsclock* at hpc0 offset ?

-

-

-

-
The dsclock driver provides support for
-    the DS1286 real-time clock (RTC). This device appears on SGI Indy and
-    Indigo2 machines. Note that the kernel expects the RTC to run in UTC.

-

-

-

-
sgimips/dpclock(4),
-    sgimips/intro(4)

-

-

-

-
The dsclock driver first appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/gio.4 3.html b/static/netbsd/man4/man4.sgimips/gio.4 3.html
deleted file mode 100644
index ff5b3d6e..00000000
--- a/static/netbsd/man4/man4.sgimips/gio.4 3.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
GIO(4)Device Drivers Manual (sgimips)GIO(4)

-

-

-

-
gio — SGI's
-    Graphics I/O (GIO) bus (an early PCI-like bus)

-

-

-

-
gio0 at imc0
-  

-  gio0 at pic0

-

-

-

-
The gio bus is a bus for connecting
-    high-speed peripherals to the main memory and CPU. The devices themselves
-    are typically (but not necessarily) connected to the
-    sgimips/hpc(4) peripheral controller, and memory and CPU
-    are accessed through the sgimips/imc(4) (Indy Memory
-    Controller) or sgimips/pic(4) (Processor Interface
-    Controller). The gio bus is found on the Personal
-    Iris 4D/3x, Indigo, Indy, Challenge S, Challenge M, and Indigo2 machines and
-    exists in three incarnations: GIO32, GIO32-bis, and GIO64.

-

-

-

-
sgimips/giopci(4),
-    sgimips/grtwo(4), sgimips/hpc(4),
-    sgimips/imc(4), sgimips/light(4),
-    sgimips/newport(4), sgimips/pic(4)

-

-

-

-
The gio driver first appeared in
-    NetBSD 1.5.

-

-

-

-
Challenge S systems may use only one gio
-    DMA-capable expansion card, despite having two slots. Cards based on the
-    sgimips/hpc(4) controller, such as the GIO32 scsi and E++
-    Ethernet adapters, must be placed in slot 1 (closest to the side of the
-    case). All other cards must be placed in slot 0 (adjacent to the memory
-    banks).

-
Indigo2 and Challenge M systems contain either three or four GIO64
-    connectors, depending on the model. However, in both cases only two
-    electrically distinct slots are present. Therefore, distinct expansion cards
-    may not share physical connectors associated with the same slot. Refer to
-    the PCB stencils to determine the association between physical connectors
-    and slots.

-

-

-

-
Systems employing the sgimips/imc(4) may
-    experience spurious SysAD bus parity errors when using expansion cards,
-    which do not drive all data lines during a CPU PIO read. The only workaround
-    is to disable SysAD parity checking when using such cards.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/giopci.4 3.html b/static/netbsd/man4/man4.sgimips/giopci.4 3.html
deleted file mode 100644
index 3f5f518d..00000000
--- a/static/netbsd/man4/man4.sgimips/giopci.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
GIOPCI(4)Device Drivers Manual (sgimips)GIOPCI(4)

-

-

-

-
giopci —
-    Attachment for PCI devices bridged to the GIO
-  bus

-

-

-

-
giopci* at gio? slot?

-

-

-

-
The giopci driver provides support for the
-    machine-independent PCI subsystem (described in pci(4))
-    such that it may attach various GIO expansion boards featuring PCI chipsets
-    sitting behind various special GIO<->PCI bridges.

-
The following boards are presently supported:

-

-

-  
Phobos G100/G130/G160 Fast Ethernet

-  
tlp(4)

-  
Set Engineering GIO Fast Ethernet

-  
tl(4)

-

-

-

-

-

-
pci(4), sgimips/gio(4),
-    tl(4), tlp(4)

-

-

-

-
The giopci driver first appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/grtwo.4 3.html b/static/netbsd/man4/man4.sgimips/grtwo.4 3.html
deleted file mode 100644
index 8888c0c1..00000000
--- a/static/netbsd/man4/man4.sgimips/grtwo.4 3.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
GRTWO(4)Device Drivers Manual (sgimips)GRTWO(4)

-

-

-

-
grtwo — SGI GR2
-    graphics controller

-

-

-

-
grtwo* at gio? slot ?
-  

-  wsdisplay* at grtwo? console ?

-

-

-

-
The grtwo driver supports the SGI GR2
-    series of graphics controllers, which are found on Indigo, Crimson, and some
-    Personal Iris series machines.

-

-

-

-
sgimips/gio(4),
-    sgimips/light(4), sgimips/newport(4),
-    wscons(4)

-

-

-

-
The grtwo driver first appeared in
-    NetBSD 2.0.

-

-

-

-
Christopher SEKIYA wrote this driver.

-

-

-

-
This driver has not been extensively tested on the many different
-    GR2 series offerings. It is unlikely to run without modification on Crimson
-    machines.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/haltwo.4 3.html b/static/netbsd/man4/man4.sgimips/haltwo.4 3.html
deleted file mode 100644
index 71708233..00000000
--- a/static/netbsd/man4/man4.sgimips/haltwo.4 3.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
HALTWO(4)Device Drivers Manual (sgimips)HALTWO(4)

-

-

-

-
haltwo — SGI HAL2
-    audio controller

-

-

-

-
haltwo0 at hpc0 offset ?

-

-

-

-
haltwo is the audio controller found on
-    the Indy and Indigo2 machines.

-

-

-

-
audio(4), sgimips/hpc(4)

-

-

-

-
The haltwo driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The driver lacks support for most mixer operations and
-  recording.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/hpc.4 3.html b/static/netbsd/man4/man4.sgimips/hpc.4 3.html
deleted file mode 100644
index 66746954..00000000
--- a/static/netbsd/man4/man4.sgimips/hpc.4 3.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
HPC(4)Device Drivers Manual (sgimips)HPC(4)

-

-

-

-
hpc — SGI High
-    performance Peripheral Controller

-

-

-

-
hpc0 at gio0 addr 0x1fb80000
-  

-  hpc1 at gio0 addr 0x1fb00000
-  

-  hpc2 at gio0 addr 0x1fb98000
-  

-  hpc3 at gio0 addr 0x1fb90000

-

-

-

-
hpc interfaces the peripherals connected
-    to it to the sgimips/gio(4) bus.
-    hpc is found on the Personal Iris 4D/3x, Indigo,
-    Indy, Challenge S, Challenge M, and Indigo2 machines.

-
There are three different numerical revisions of the
-    hpc controller. Revisions 1 and 1.5 exist on
-    Personal Iris 4D/3x and Indigo machines, as well as GIO32bis expansion cards
-    such as the E++ SEEQ-based Ethernet adapter. Revision 1.5 supports bi-endian
-    operation. Revision 3 exists on Indy, Challenge S, Indigo2, and Challenge M
-    systems. It is possible to have an on-board HPC3 as well as HPC1.5-based
-    GIO32bis adapters in the Indy and Challenge S systems. Additionally, the
-    Challenge S may have a secondary HPC3 if the IOPLUS (a.k.a. ''mezzanine'')
-    board is installed.

-

-

-

-

-

-  
dsclock

-  
DS1286-based RTC

-  
dpclock

-  
DP8573A-based RTC

-  
haltwo

-  
HAL2 audio controller

-  
sq

-  
Seeq 8003 and 80C03 Ethernet controllers

-  
wdsc

-  
WD33c93 SCSI controller

-  
zsc

-  
Zilog Z8530 UART

-

-

-

-

-

-
sgimips/gio(4),
-    sgimips/imc(4), sgimips/pic(4)

-

-

-

-
The hpc driver first appeared in
-    NetBSD 1.6 with support for Revision 3. Revision 1
-    and 1.5 support was added in NetBSD 2.0.

-

-

-

-
hpc Revisions 1 and 1.5 support DMA buffer
-    pointers of only 28 bits and may therefore only address 256 megabytes of
-    memory. The R4k Indigo and Indy are the only systems that support sufficient
-    memory to illustrate this drawback. A software workaround is not currently
-    implemented. Revision 3, with 32 bit pointers, does not have this
-    limitation.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/imc.4 3.html b/static/netbsd/man4/man4.sgimips/imc.4 3.html
deleted file mode 100644
index b794983c..00000000
--- a/static/netbsd/man4/man4.sgimips/imc.4 3.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
IMC(4)Device Drivers Manual (sgimips)IMC(4)

-

-

-

-
imc — Indy Memory
-    Controller and system controller

-

-

-

-
imc0 at mainbus0 addr 0x1fa00000

-

-

-

-
The Indy Memory Controller is responsible for acting as an
-    interface from the sgimips/gio(4) bus to the main memory
-    and CPU. The imc is found in the Indigo R4k, Indy,
-    Challenge S, Challenge M, and Indigo2 machines.

-

-

-

-
sgimips/gio(4)

-

-

-

-
The imc driver first appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/intro.4 3.html b/static/netbsd/man4/man4.sgimips/intro.4 3.html
deleted file mode 100644
index eb137960..00000000
--- a/static/netbsd/man4/man4.sgimips/intro.4 3.html	
+++ /dev/null
@@ -1,140 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (sgimips)INTRO(4)

-

-

-

-
intro —
-    introduction to sgimips special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported by
-    NetBSD/sgimips. Software support for these devices
-    comes in two forms. A hardware device may be supported with a character or
-    block , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
The following systems are supported:

-

-

-

-  
O2

-  
IP32 (“Moosehead”)

-  
Indy/Challenge S

-  
IP24 (“Guinness”)

-  
Indigo 2/Challenge M

-  
IP22 (“Fullhouse”)

-  
Indigo R4k

-  
IP20 (“Blackjack”)

-  
Indigo R3k

-  
IP12 (“Hollywood”)

-  
Personal Iris 4D/3x

-  
IP12 (“Magnum”)

-

-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-

-  
crime

-  
found on the O2

-  
dpclock

-  
real-time clock

-  
dsclock

-  
real-time clock

-  
gio

-  
PCI-like bus

-  
hpc

-  
High performance Peripheral Controller

-  
imc

-  
Indigo R4k/Indy/Challenge S/Indigo2 bus arbiter

-  
mace

-  
found on the O2

-  
mec

-  
O2 MAC110 ethernet

-  
newport

-  
entry framebuffer on Indy and Indigo2

-  
pic

-  
Personal Iris 4D/3x and Indigo R3k bus arbiter

-  
sq

-  
SEEQ 8003/80C03 ethernet

-  
tl

-  
Set Engineering GIO 100baseTX Fast Ethernet

-  
tlp

-  
Phobos G130/G160 10/100 GIO Fast Ethernet

-  
wdsc

-  
WD33C93 SCSI interface

-

-

-
PCI devices are supported through the pci(4) bus
-    and associated device drivers.

-

-

-

-
config(1), autoconf(4),
-    sgimips/crime(4), sgimips/dpclock(4),
-    sgimips/dsclock(4), sgimips/gio(4),
-    sgimips/hpc(4), sgimips/imc(4),
-    sgimips/mace(4), sgimips/mec(4),
-    sgimips/newport(4), sgimips/pic(4),
-    sgimips/sq(4), sgimips/wdsc(4),
-    tlp(4)

-

-

-

-
This sgimips intro appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/light.4 3.html b/static/netbsd/man4/man4.sgimips/light.4 3.html
deleted file mode 100644
index 7178e9f9..00000000
--- a/static/netbsd/man4/man4.sgimips/light.4 3.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
LIGHT(4)Device Drivers Manual (sgimips)LIGHT(4)

-

-

-

-
light — SGI
-    Light/Entry/Starter (LG1/LG2) graphics controller

-

-

-

-
light* at gio? slot ?
-  

-  wsdisplay* at light? console ?

-

-

-

-
The light driver supports the SGI Light
-    series of graphics controllers, also known as Entry or Starter graphics and
-    designated LG1 or LG2. These controllers have a fixed 1024x768 resolution
-    with 8-bit colour depth. Unlike most SGI offerings, both 13w3 and VGA video
-    cables are supported. light is found in Indigo and
-    Crimson machines.

-

-

-

-
sgimips/gio(4),
-    sgimips/grtwo(4), sgimips/newport(4),
-    wscons(4)

-

-

-

-
The light driver first appeared in
-    NetBSD 5.0.

-

-

-

-
Stephen M. Rumble wrote this driver.

-

-

-

-
Much is unknown about the REX chipset. Therefore, the driver
-    relies on the PROM to properly initialise the graphics.

-
This driver will not run without modification on Crimson
-  machines.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/mace.4 3.html b/static/netbsd/man4/man4.sgimips/mace.4 3.html
deleted file mode 100644
index 6a9861a9..00000000
--- a/static/netbsd/man4/man4.sgimips/mace.4 3.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
MACE(4)Device Drivers Manual (sgimips)MACE(4)

-

-

-

-
mace — Multimedia,
-    Audio and Communications Engine I/O ASIC

-

-

-

-
mace0 at mainbus0 addr 0x1f000000

-

-

-

-
The mace I/O ASIC takes care of all the
-    basic I/O functions. Examples of interfaces provided by it are the keyboard
-    and mouse, fast Ethernet, video, audio, the PCI bus, and parallel and serial
-    connectors. It is connected to the host bus through the
-    sgimips/crime(4) controller. mace
-    is typically found on O2 machines.

-

-

-

-
pci(4), sgimips/crime(4)

-

-

-

-
The mace driver first appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/mavb.4 3.html b/static/netbsd/man4/man4.sgimips/mavb.4 3.html
deleted file mode 100644
index 0430298e..00000000
--- a/static/netbsd/man4/man4.sgimips/mavb.4 3.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAVB(4)Device Drivers Manual (sgimips)MAVB(4)

-

-

-

-
mavb — Moosehead
-    A/V Board audio device

-

-

-

-
mavb0 at mace0 offset 0x300000 intr 6
-  

-  audio* at audiobus?

-

-

-

-
The mavb driver provides support for the
-    Moosehead A/V Board found on SGI O2 machines.

-
The Moosehead A/V Board uses an AD1843 codec that supports 8- and
-    16-bit audio sample recording and playback at rates from 5 to 54 kHz, with 1
-    Hz resolution. The mavb driver also makes it
-    possible to control the playback volume by using the buttons on the front of
-    the O2.

-

-

-

-
audio(4), sgimips/intro(4),
-    sgimips/mace(4)

-

-

-

-
The mavb driver first appeared in
-    OpenBSD 3.7. It was later ported to
-    NetBSD 5.0.

-

-

-

-
The mavb driver was written by Mark
-    Kettenis, and ported to NetBSD by Jared D.
-  McNeill.

-

-

-

-
The analog mixer in the AD1843 codec does not provide a master
-    volume control. Therefore, the O2 volume buttons only control the output
-    volume of the DAC.

-

-

-

-
Currently only sample rates up to 48 kHz are supported. Recording
-    is not implemented yet. The second DAC on the AD1843 codec sits idle.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/mec.4 3.html b/static/netbsd/man4/man4.sgimips/mec.4 3.html
deleted file mode 100644
index e1ba73b6..00000000
--- a/static/netbsd/man4/man4.sgimips/mec.4 3.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEC(4)Device Drivers Manual (sgimips)MEC(4)

-

-

-

-
mec — MACE MAC-110
-    Ethernet driver

-

-

-

-
mec0 at mace0 offset 0x280000 intr 3

-

-

-

-
The mec driver provides support for the
-    MACE MAC-110 Ethernet interface found on SGI O2 machines.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    sgimips/intro(4), sgimips/mace(4),
-    ifconfig(8)

-

-

-

-
The mec driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The mec driver was written by
-    Christopher SEKIYA and
-  

-  Izumi Tsutsui.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/newport.4 3.html b/static/netbsd/man4/man4.sgimips/newport.4 3.html
deleted file mode 100644
index 60b472c5..00000000
--- a/static/netbsd/man4/man4.sgimips/newport.4 3.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
NEWPORT(4)Device Drivers Manual (sgimips)NEWPORT(4)

-

-

-

-
newport — SGI NG1
-    graphics controller

-

-

-

-
newport* at gio? slot ?
-  

-  wsdisplay* at newport? console ?

-

-

-

-
The newport driver supports the SGI NG1
-    (a.k.a. Indy 8-bit, Indy 24-bit, and XL) graphics controllers, often found
-    on Indy and Indigo2 machines.

-

-

-

-
sgimips/gio(4),
-    sgimips/grtwo(4), sgimips/light(4),
-    wscons(4)

-

-

-

-
The newport driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/pic.4 3.html b/static/netbsd/man4/man4.sgimips/pic.4 3.html
deleted file mode 100644
index 61893369..00000000
--- a/static/netbsd/man4/man4.sgimips/pic.4 3.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
PIC(4)Device Drivers Manual (sgimips)PIC(4)

-

-

-

-
pic — Processor
-    Interface Controller

-

-

-

-
pic0 at mainbus0 addr 0x1fa00000

-

-

-

-
The Processor Interface Controller interfaces the
-    sgimips/gio(4) bus (VME bus optional) to main memory and
-    CPU. The pic is found in the Personal Iris 4D/3x and
-    Indigo R3k machines.

-

-

-

-
sgimips/gio(4)

-

-

-

-
The pic driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/sq.4 3.html b/static/netbsd/man4/man4.sgimips/sq.4 3.html
deleted file mode 100644
index 79305913..00000000
--- a/static/netbsd/man4/man4.sgimips/sq.4 3.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
SQ(4)Device Drivers Manual (sgimips)SQ(4)

-

-

-

-
sq — SEEQ
-    8003/80c03 Ethernet driver

-

-

-

-
sq* at hpc? offset ?

-

-

-

-
The sq interface provides access to a
-    Ethernet network via the SEEQ 8003 and 80c03 (aka SGI EDLC) chip sets. DMA
-    is provided by sgimips/hpc(4).

-
The sq is found in the Personal Iris
-    4D/3x, Indigo, Indy, Challenge S, Challenge M, and Indigo2 machines, as well
-    as the SGI E++ GIO32bis Ethernet adapter.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    sgimips/hpc(4), ifconfig(8)

-

-

-

-
The sq driver first appeared in
-    NetBSD 1.6 with support for
-    sgimips/hpc(4) revision 3. Revision 1 and 1.5 support was
-    added in NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sgimips/wdsc.4 3.html b/static/netbsd/man4/man4.sgimips/wdsc.4 3.html
deleted file mode 100644
index ea795e2e..00000000
--- a/static/netbsd/man4/man4.sgimips/wdsc.4 3.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
WDSC(4)Device Drivers Manual (sgimips)WDSC(4)

-

-

-

-
wdsc — Western
-    Digital WD33c93 SCSI Bus Interface Controller

-

-

-

-
wdsc* at hpc? offset ?

-

-

-

-
The wdsc driver provides an abstraction
-    layer between the SCSI hardware found in multitudinous SGI machines
-    (including Personal Iris series, Indigo, Indy, Challenge S, Indigo2, and
-    Challenge M) and the machine independent SCSI drivers described in
-    scsibus(4).

-
In addition to sending the required SCSI commands to target
-    devices on the SCSI bus, the wdsc driver deals with
-    DMA, device interrupts, sync/async negotiation, and target
-    disconnects/reconnects.

-

-

-

-
scsibus(4), sgimips/hpc(4)

-

-

-

-
Wayne Knowles ported the sgimips incarnation of the
-    wdsc driver from the amiga and atari ports. It first
-    appeared in NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/apc.4 4.html b/static/netbsd/man4/man4.sparc/apc.4 4.html
deleted file mode 100644
index 8981559e..00000000
--- a/static/netbsd/man4/man4.sparc/apc.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
APC(4)Device Drivers Manual (sparc)APC(4)

-

-

-

-
apc — Aurora
-    personality chip device driver

-

-

-

-
apc0 at sbus0 slot 15 offset 0xa000000

-

-

-

-
The apc driver provides support for the
-    power management functions of the Aurora Personality Chip found in
-    SPARCstation 4 and SPARCstation 5 systems, and also emulated by QEMU. The
-    driver will idle the emulator when the emulated CPUs are idle.

-

-

-

-
The driver does not support controlling the fan speed nor the
-    convenience power outlet.

-

-

-

-
sbus(4)

-

-

-
-  
-    
-    
-  
-
May 5, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/audioamd.4 4.html b/static/netbsd/man4/man4.sparc/audioamd.4 4.html
deleted file mode 100644
index 034c1afd..00000000
--- a/static/netbsd/man4/man4.sparc/audioamd.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUDIOAMD(4)Device Drivers Manual (sparc)AUDIOAMD(4)

-

-

-

-
audioamd —
-    baseboard audio device driver

-

-

-

-
audioamd0	at mainbus0
-  

-  audioamd0	at obio0
-  

-  audioamd0	at sbus0 slot ? offset ?
-  

-  audio*	at audioamd0

-

-

-

-
The audioamd driver provides support for
-    the baseboard audio found on sun4c and sun4m systems. The baseboard audio
-    driver is based on the AMD 79c30 ISDN and audio interface. The interface is
-    only capable of playing and recording 8kHz mu-law audio.

-

-

-

-
audio(4), sbus(4)

-

-

-
-  
-    
-    
-  
-
January 31, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/autoconf.4 4.html b/static/netbsd/man4/man4.sparc/autoconf.4 4.html
deleted file mode 100644
index fcf1ddd9..00000000
--- a/static/netbsd/man4/man4.sparc/autoconf.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (sparc)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel. Devices which
-    exist in the machine but are not configured into the kernel are not
-    detected.

-

-

-

-

-  
CPU class not configured.

-  
You tried to boot NetBSD on a class of CPU type
-      which it doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-

-

-

-

-
config(1), sparc/intro(4),
-    boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/auxreg.4 3.html b/static/netbsd/man4/man4.sparc/auxreg.4 3.html
deleted file mode 100644
index ae45bbea..00000000
--- a/static/netbsd/man4/man4.sparc/auxreg.4 3.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUXREG(4)Device Drivers Manual (sparc)AUXREG(4)

-

-

-

-
auxreg — Sun SPARC
-    auxiliary register

-

-

-

-
auxreg0 at mainbus0 # sun4c
-  

-  auxreg0 at obio0 # sun4m
-  

-  options BLINK

-

-

-

-
The auxreg device contains controls for
-    the front panel LED and various status bits for the SPARC
-    sparc/fdc(4) floppy controller.

-
options BLINK Force the front panel LED to
-    blink.

-

-

-

-
sparc/fdc(4)

-

-

-

-
The auxreg appeared in
-    NetBSD 1.0.

-

-

-
-  
-    
-    
-  
-
February 24, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/bpp.4 4.html b/static/netbsd/man4/man4.sparc/bpp.4 4.html
deleted file mode 100644
index 1ee22204..00000000
--- a/static/netbsd/man4/man4.sparc/bpp.4 4.html	
+++ /dev/null
@@ -1,35 +0,0 @@
-
-  
-    
-    
-    
-  
-
BPP(4)Device Drivers Manual (sparc)BPP(4)

-

-

-

-
bpp — parallel
-    port driver

-

-

-

-
bpp0 at sbus?

-

-

-

-
This driver provides access to parallel ports.

-

-

-

-

-  
/dev/bpp

-  
 

-

-

-

-
-  
-    
-    
-  
-
November 28, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/bwtwo.4 4.html b/static/netbsd/man4/man4.sparc/bwtwo.4 4.html
deleted file mode 100644
index 865e7acf..00000000
--- a/static/netbsd/man4/man4.sparc/bwtwo.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
BWTWO(4)Device Drivers Manual (sparc)BWTWO(4)

-

-

-

-
bwtwo — Sun
-    monochromatic frame buffer

-

-

-

-
bwtwo* at sbus? slot ? offset ?

-

-

-

-
The bwtwo is a memory based black and
-    white frame buffer. It supports the minimal ioctl's needed to run
-    Xorg(1).

-

-

-

-
sparc/cgsix(4),
-    sparc/cgthree(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/cgeight.4 4.html b/static/netbsd/man4/man4.sparc/cgeight.4 4.html
deleted file mode 100644
index 09fc21ee..00000000
--- a/static/netbsd/man4/man4.sparc/cgeight.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGEIGHT(4)Device Drivers Manual (sparc)CGEIGHT(4)

-

-

-

-
cgeight — Sun
-    24-bit color frame buffer

-

-

-

-
cgeight0 at obio0 addr 0xfb300000 level 4
-    (sun4/300)
-  

-  cgeight0 at obio0 addr 0x0b300000 level 4
-  (sun4/100)

-

-

-

-
The cgeight is a memory based color frame
-    buffer. Its pixel memory can be mapped into a user process address space by
-    using the mmap(2) system call. The
-    cgeight driver supports the minimal ioctl's needed
-    to run Xorg(1).

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgfour(4), sparc/cgsix(4),
-    sparc/cgthree(4), sparc/cgtwo(4),
-    sparc/tcx(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/cgfour.4 4.html b/static/netbsd/man4/man4.sparc/cgfour.4 4.html
deleted file mode 100644
index 027f52fc..00000000
--- a/static/netbsd/man4/man4.sparc/cgfour.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGFOUR(4)Device Drivers Manual (sparc)CGFOUR(4)

-

-

-

-
cgfour — Sun 8-bit
-    color frame buffer

-

-

-

-
cgfour0 at obio0 addr 0xfb300000 level 4
-    (sun4/300)
-  

-  cgfour0 at obio0 addr 0x0b300000 level 4
-  (sun4/100)

-

-

-

-
The cgfour is a memory based color frame
-    buffer with overlay plane. Its pixel memory and control planes can be mapped
-    into a user process address space by using the mmap(2)
-    system call. The cgfour driver supports the minimal
-    ioctl's needed to run Xorg(1).

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgsix(4),
-    sparc/cgthree(4), sparc/cgtwo(4),
-    sparc/tcx(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/cgfourteen.4 4.html b/static/netbsd/man4/man4.sparc/cgfourteen.4 4.html
deleted file mode 100644
index fcae0785..00000000
--- a/static/netbsd/man4/man4.sparc/cgfourteen.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGFOURTEEN(4)Device Drivers Manual (sparc)CGFOURTEEN(4)

-

-

-

-
cgfourteen — Sun
-    accelerated 8/24-bit color frame buffer

-

-

-

-
cgfourteen* at obio?

-

-

-

-
The cgfourteen is a memory based color
-    frame buffer, with graphics acceleration and overlay capabilities. Its pixel
-    memory can be mapped into a user process address space by using the
-    mmap(2) system call. The
-    cgfourteen driver supports the minimal ioctl's
-    needed to run Xorg(1).

-
The driver operates by default in
-    sparc/cgthree(4) emulation mode, i.e. in 8-bit
-    unaccelerated mode. This emulation does include support for the hardware
-    cursor present on the cgfourteen, however.

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgfour(4),
-    sparc/cgsix(4), sparc/cgthree(4),
-    sparc/cgtwo(4), sparc/tcx(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/cgsix.4 4.html b/static/netbsd/man4/man4.sparc/cgsix.4 4.html
deleted file mode 100644
index 2b6dca0b..00000000
--- a/static/netbsd/man4/man4.sparc/cgsix.4 4.html	
+++ /dev/null
@@ -1,142 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGSIX(4)Device Drivers Manual (sparc)CGSIX(4)

-

-

-

-
cgsix — Sun
-    accelerated 8-bit color frame buffer

-

-

-

-
cgsix* at sbus? slot ? offset ?
-    (sun4c/sun4m)
-  

-  cgsix0 at obio0 addr 0xfb000000 level 4 (sun4/300)
-  

-  cgsix0 at obio0 addr 0x0b000000 level 4 (sun4/100)

-

-

-

-
The cgsix is a memory based color frame
-    buffer. It supports the minimal ioctl's needed to run
-    X(7).

-
There are several versions of the cgsix
-    board. The Sun part numbers and board types are:

-

-

-  
501-1374, 501-1532

-  
P4 GX

-  
501-1505

-  
P4 GX with 3/80 backpanel

-  
501-1481, 501-1645

-  
Sbus double-width GX

-  
501-1672, 501-1996

-  
Sbus GX

-  
501-1717, 501-2018, 501-2039

-  
Sbus GX+

-  
501-2325, 501-2922

-  
Sbus TGX

-  
501-2253, 501-2955

-  
Sbus TGX+

-

-
There are also on-board ‘GX’ cards in the
-    ‘SPARCstation IPX’ and ‘SPARCstation LX’
-    machines.

-
The ‘GX’ and ‘TGX’ cards have 1Mb of
-    on-board memory and support a maximum graphics resolution of 1152x900. The
-    ‘GX+’ cards have 4Mb of on-board memory and support a maximum
-    resolution of 1280x1024. The ‘TGX+’ cards have 4Mb of on-board
-    memory and support a maximum resolution of 1600x1280. The
-    ‘TGX’ (Turbo GX) cards are faster than the ‘GX’
-    cards.

-
The number of supported resolutions varies by card type. All cards
-    support a resolution of 1152x900 at 66Hz. All but the P4 and double-width
-    cards support a resolution of 1152x900 at 76Hz. The cards default to a
-    resolution dependent on the attached monitor (usually 1152x900).

-
It is only possible to change the resolution of a
-    cgsix card from the PROM before the operating system
-    is loaded. For the primary card, this can be done using the
-    ‘output-device’ PROM field. For example, for a
-    ‘TGX+’ card, the following PROM command will set the
-    resolution to 1280x1024 at 76Hz:

-

-
setenv output-device screen:r1280x1024x76

-

-
For secondary cards, a different method must be used to set the
-    resolution. For a machine with OpenBoot 2.x or 3.x, and assuming a
-    ‘TGX’ card at Sbus slot 1, the following PROM commands will
-    set the resolution to 1024x768 at 60Hz:

-

-
nvedit
-probe-all
-" /iommu/sbus/cgsix@1" select-dev
-r1024x768x60
-" /iommu/sbus/cgsix@1" " set-resolution" execute-device-method
-device-end
-install-console
-banner
-^C
-nvstore
-setenv use-nvramrc? true
-reset

-

-
For Sun4c machines, the device-path above would be:

-

-
" /sbus/cgsix@1"

-

-
For Sun-4 and Sun-3 systems, it is only possible to change PROM
-    fields by altering byte values. For these systems, it is probably easier to
-    use the eeprom(8) command to set the
-    scrsize field to the desired resolution.

-

-

-

-
cgsix0 at obio0 addr 0xfb000000 level 4:
-    cgsix/p4, 1152 x 900, rev 1 cgsix0 at sbus0 slot 0
-    offset 0x0 level 9: SUNW,501-2325, 1152 x 900, rev 11
-    cgsix0 at sbus0 slot 0 offset 0x0 level 9: SUNW,501-2253,
-    1280 x 1024, rev 11

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgfour(4),
-    sparc/cgfourteen(4), sparc/cgthree(4),
-    sparc/cgtwo(4), sparc/tcx(4),
-    eeprom(8)

-

-

-

-
The double-width ‘GX’ and the ‘GX+’
-    cards are not compatible with UltraSPARC machines.

-
On Sun-4 systems using a P4 GX card as console, the
-    console field in the PROM must be set to
-    p4opt, otherwise the card will not be recognised as
-    the console output device.

-
Several firmware revisions on cgsix boards
-    have a terminal emulation bug that shows up when using the screen control
-    sequences for inserting blank lines near the bottom end of the screen (i.e.,
-    the control sequences produced by the termcap ‘al’ and
-    ‘AL’ capabilities found in the terminfo(5)
-    database). The most likely occasion for triggering this bug is to use a
-    full-screen editor such as vi(1) on the workstation's
-    console.

-
To work around this you can set your TERM
-    environment variable to the ‘sun-cgsix’ terminal definition
-    which is the same as the ‘sun’ entry, except that the
-    ‘al’ and ‘AL’ capabilities have been removed (at
-    the cost of making the scrolling of the screen slower).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/cgthree.4 4.html b/static/netbsd/man4/man4.sparc/cgthree.4 4.html
deleted file mode 100644
index 9bdbec5f..00000000
--- a/static/netbsd/man4/man4.sparc/cgthree.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGTHREE(4)Device Drivers Manual (sparc)CGTHREE(4)

-

-

-

-
cgthree — Sun
-    8-bit color frame buffer

-

-

-

-
cgthree* at sbus? slot ? offset ?
-  

-  cgthree* at obio0 slot ? offset ? (some sun4m
-  models)

-

-

-

-
The cgthree is a memory based color frame
-    buffer. It supports the minimal ioctl's needed to run
-    Xorg(1).

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgfour(4),
-    sparc/cgsix(4), sparc/cgtwo(4),
-    sparc/tcx(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/cgtwo.4 4.html b/static/netbsd/man4/man4.sparc/cgtwo.4 4.html
deleted file mode 100644
index b35d38ac..00000000
--- a/static/netbsd/man4/man4.sparc/cgtwo.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGTWO(4)Device Drivers Manual (sparc)CGTWO(4)

-

-

-

-
cgtwo — Sun 8-bit
-    color frame buffer

-

-

-

-
cgtwo* at vmes0 addr 0xff400000 level 4 vect
-    0xa8

-

-

-

-
The cgtwo is a memory based color frame
-    buffer. Its control pixel memory can be mapped into a user process address
-    space by using the mmap(2) system call. The
-    cgtwo driver supports the minimal ioctl's needed to
-    run Xorg(1).

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgfour(4),
-    sparc/cgsix(4), sparc/cgthree(4),
-    sparc/tcx(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/clock.4 4.html b/static/netbsd/man4/man4.sparc/clock.4 4.html
deleted file mode 100644
index 0530ad5d..00000000
--- a/static/netbsd/man4/man4.sparc/clock.4 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
CLOCK(4)Device Drivers Manual (sparc)CLOCK(4)

-

-

-

-
clock, oclock
-    — Clock driver for Sun SPARC computers

-

-

-

-
clock0 at mainbus0 # sun4c
-  

-  clock0 at obio0 # sun4m
-  

-  clock0 at obio0 addr 0xf2000000 # sun4/300

-

-  

-  ooclock0 at obio0 addr 0xf3000000 # sun4/200
-  

-  ooclock0 at obio0 addr 0x03000000 # sun4/100

-

-

-

-
The clock device contains common timer,
-    clock and eeprom routines for the NetBSD kernel.

-
All system use the timer interrupt to drive the hard clock. The
-    second interrupt is used to drive statistics clock, except sun4/100 and
-    sun4/200 machines, which don't have a spare timer device.

-

-

-

-
The clock driver provides support for the
-    following chips:

-

-

-

-  
Dallas DS1287A

-  
 

-  
Intersil 7170

-  
 

-  
Mostek Mk48T02

-  
 

-  
Mostek Mk48T08

-  
 

-

-

-

-

-

-
sparc/timer(4)

-

-

-

-
The clock appeared in
-    NetBSD 1.0.

-

-

-
-  
-    
-    
-  
-
February 24, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/dbri.4 4.html b/static/netbsd/man4/man4.sparc/dbri.4 4.html
deleted file mode 100644
index c0ee7a86..00000000
--- a/static/netbsd/man4/man4.sparc/dbri.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
DBRI(4)Device Drivers Manual (sparc)DBRI(4)

-

-

-

-
dbri — SUNW,DBRI
-    audio device driver

-

-

-

-
dbri*	at sbus? slot ? offset ?
-  

-  audio*	at audiobus?

-

-

-

-
The dbri driver provides support for the
-    audio part of DBRI ISDN controllers found in various sun4m class machines.
-    It works with both onboard codecs and external speakerboxes.

-

-

-

-
audio(4), sbus(4)

-

-

-
-  
-    
-    
-  
-
July 16, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/fd.4 4.html b/static/netbsd/man4/man4.sparc/fd.4 4.html
deleted file mode 100644
index ec56534c..00000000
--- a/static/netbsd/man4/man4.sparc/fd.4 4.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
FD(4)Device Drivers Manual (sparc)FD(4)

-

-

-

-
fd, fdc —
-    Sun SPARCstation i82072 or i82077 floppy disk controller
-    driver

-

-

-

-
fdc0 at mainbus0 (sun4c)
-  

-  fdc0 at obio0 (sun4m)
-  

-  fd* at fdc0

-

-

-

-
This is the driver for the built-in floppy disk drive run by the
-    Intel i82072 or i82077 controller chip found on the SPARCstation desktop
-    systems, and other SPARC systems.

-
Bits [0-3] of the minor device number of the special files
-    referring to this device encode the floppy density as follows:

-

-

-  
0

-  
3.5'' 1.44MB floppy diskettes.

-  
1

-  
3.5'' 720KB floppy diskettes.

-  
2

-  
3.5'' 360KB floppy diskettes.

-  
3

-  
3.5'' 1.2MB/NEC Japanese format floppy diskettes.

-

-

-

-

-

-
The driver supports floppy disk formatting using the interfaces in
-    <sys/fdio.h>:

-

-

-  

-    struct fdformat_parms

-  
Fetch current formatting parameters. This gets the default parameters for
-      the open device if no parameters have been set during the session.
-    

-  

-  

-    struct fdformat_parms

-  
Set formatting parameters. The driver saves this state and it persists
-      while the device is open.
-    

-  

-  

-    struct fdformat_cmd

-  
Format a track on the medium. If this call returns
-      EINVAL, the track formatting parameters were out
-      of range for the medium. If it returns EIO, there
-      was a medium error while formatting the track.
-    

-  

-  

-    int

-  
Set driver options which persist until the device is closed. The options
-      should be the logical OR of the desired values below:
-    

-    

-      

-      
Do not retry operations on failure

-      

-      
Do not print error messages to the console

-    

-    

-  

-  

-    int

-  
Fetch drive options.

-

-
A typical use of the formatting facilities would be to open the
-    device, call FDIOCGETFORMAT to fetch the current
-    format parameters, perhaps change a parameter or two, display the formatting
-    details to the user, and then call FDIOCSETFORMAT
-    followed by a series of calls to
-  FDIOCFORMAT_TRACK.

-

-

-

-
eject(1),
-  sparc/fdformat(1)

-

-

-

-
The fd formatting support appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/ie.4 4.html b/static/netbsd/man4/man4.sparc/ie.4 4.html
deleted file mode 100644
index b3987224..00000000
--- a/static/netbsd/man4/man4.sparc/ie.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
IE(4)Device Drivers Manual (sparc)IE(4)

-

-

-

-
ie — SPARC Intel
-    82586 ethernet interface

-

-

-

-
ie0 at obio0 addr 0xf6000000 level 6 
-    (sun4/200 on-board)
-  

-  ie0 at obio0 addr 0x06000000 level 6  (sun4/100
-    on-board)
-  

-  ie1 at vmes0 addr 0xffe88000 level 5 vect 0x75 (VME)
-  

-  ie2 at vmes0 addr 0xff31ff02 level 5 vect 0x76 (VME)
-  

-  ie3 at vmes0 addr 0xff35ff02 level 5 vect 0x77 (VME)
-  

-  ie4 at vmes0 addr 0xff2dff02 level 5 vect 0x7c
-  (VME)

-

-

-

-
The ie interface provides access to the 10
-    Mb/s Ethernet network via the Intel 82586 Ethernet chip set. The
-    ie is found as an on-board interface on Sun 4/100
-    and 4/200 workstations. The ie also exists as a VME
-    card.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ie interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-
arp(4), ifmedia(4),
-    inet(4), sparc/intro(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/intro.4 3.html b/static/netbsd/man4/man4.sparc/intro.4 3.html
deleted file mode 100644
index b4e15380..00000000
--- a/static/netbsd/man4/man4.sparc/intro.4 3.html	
+++ /dev/null
@@ -1,257 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (sparc)INTRO(4)

-

-

-

-
intro —
-    introduction to sparc special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the SPARC
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    sparc/autoconf(4). A list of the supported devices is
-    given below.

-

-

-

-
config(1), cd(4),
-    ch(4), le(4), scsi(4),
-    sd(4), sparc/autoconf(4),
-    sparc/bwtwo(4), sparc/cgeight(4),
-    sparc/cgfour(4), sparc/cgfourteen(4),
-    sparc/cgsix(4), sparc/cgthree(4),
-    sparc/cgtwo(4), sparc/fd(4),
-    sparc/kbd(4), sparc/magma(4),
-    sparc/mem(4), sparc/ms(4),
-    sparc/openprom(4), sparc/tcx(4),
-    ss(4), st(4),
-  uk(4)

-

-

-

-
The following Sun SPARC system architectures and models are
-    supported:

-

-  
sun4

-  
first generation SPARC systems on VMEbus:
-    

-    Sun 4/100 series (14.28 MHz)
-    

-    Sun 4/200 series (16.67 MHz)
-    

-    Sun 4/300 series (25 MHz)

-  
sun4c

-  
desktop SPARC systems with Sbus:
-    

-    SPARCstation 1 (20 MHz)
-    

-    SPARCstation 1+ (25 MHz)
-    

-    SPARCstation 2 (40 MHz)
-    

-    SPARCstation SLC (20 MHz)
-    

-    SPARCstation ELC (33 MHz)
-    

-    SPARCstation IPC (25 MHz)
-    

-    SPARCstation IPX (40 MHz).

-  
sun4m

-  
desktop SPARC systems with Mbus for CPUs, and Sbus:
-    

-    SPARCclassic (50 MHz microSPARC I)
-    

-    SPARCstation LX (50 MHz microSPARC I)
-    

-    SPARCstation 4 (70 MHz microSPARC II)
-    

-    SPARCstation 5 (70, 85, 110 MHz microSPARC II)
-    

-    SPARCstation 5 (170 MHz TurboSPARC)
-    

-    SPARCstation 10M (36 MHz SuperSPARC I)
-    

-    SPARCstation 20M (50 MHz SuperSPARC I)
-    

-    SPARCstation 10 (Mbus modules)
-    

-    SPARCstation 20 (Mbus modules)

-

-
The SPARCstation 2 and IPX can be upgraded with a Weitek PowerUP
-    CPU that is clock-doubled (i.e. internally it runs at 80 MHz).
-    NetBSD supports this configuration.

-
Hardware level clones of these systems from other manufacturers
-    will likely work (e.g. Xerox, Tatung, Axil, Cycle); other systems which have
-    a SPARC CPU but do not use Sun's hardware architecture (e.g. Solbourne) will
-    likely not work.

-
The sun4m architecture with Mbus modules for the CPUs is supported
-    with the following modules with only one CPU:

-

-  
SM41

-  
40 MHz SuperSPARC I with 1MB SuperCACHE

-  
SM51

-  
50 MHz SuperSPARC I with 1MB SuperCACHE

-  
SM61

-  
60 MHz SuperSPARC I with 1MB SuperCACHE

-  
SM71

-  
75 MHz SuperSPARC II with 1MB SuperCACHE

-  
SM81

-  
85 MHz SuperSPARC II with 1MB SuperCACHE

-  
HS11

-  
100 MHz Ross Technology hyperSPARC

-  
HS21

-  
125 MHz Ross Technology hyperSPARC

-  
M151

-  
150 MHz Ross Technology hyperSPARC

-

-
This list is not exhaustive; NetBSD is
-    continuously being improved, and may well run on Mbus CPU modules not listed
-    here.

-
There is also some support for Sun JavaStation computers based on
-    the microSPARC CPU.

-
NetBSD does not yet properly support
-    multiprocessor systems, but will run on one processor of a multiprocessor
-    system.

-
The Sun 4/400 series, and sun4d (SPARCcenter 1000, 1000E, and
-    2000) are not supported.

-
The sun4u (UltraSPARC 64-bit) architectures are supported by
-    NetBSD/sparc64.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-  
audio

-  
AMD 79C30 obio (sun4c) and dbri (sun4m) audio controller

-  
bpp

-  
Bi-directional Parallel port

-  
bwtwo

-  
black and white obio frame buffer

-  
cgeight

-  
24 bit VMEbus color frame buffer

-  
cgfour

-  
8 bit obio (sun4 P4 bus) color graphics frame buffer

-  
cgfourteen

-  
24 bit Sbus color frame buffer

-  
cgsix

-  
8 bit obio (sun4c & sun4m), Sbus color graphics frame buffer

-  
cgthree

-  
8 bit VMEbus, Sbus, and obio (sun4m) color graphics frame buffer

-  
cgtwo

-  
8 bit VMEbus color frame buffer

-  
dbri

-  
Dual Basic Rate Interface (BRI) ISDN (SPARC LX & SPARCstation 10)
-      (only the audio component is supported)

-  
eeprom

-  
Sun non-volatile configuration RAM driver

-  
esp

-  
NCR53C90 ESP100 (Sun 4/300), ESP100A (sun4c), ESP200 (sun4m) SCSI
-      controller
-    

-    FSBE/S (X1053A, part # 501-2015) Fast SCSI-2/Buffered Ethernet Sbus
-      controller

-  
fd

-  
Intel 82072 obio (sun4c) or Intel 82077 obio (sun4m) floppy disk drive
-      controller

-  
ie

-  
Intel 82586 Ethernet controller (Sun 4/100)

-  
isp

-  
Qlogic ISP Sbus SCSI controller

-  
kbd

-  
Sun type 2, type 3, type 4, and type 5 keyboards (on zs)

-  
le/lebuffer

-  
AMD 7990 LANCE Ethernet controller (Sun 4/200, 4/300, sun4c, sun4m,
-    Sbus)

-  
magma

-  
Magma Sp Serial/Parallel board device driver

-  
ms

-  
Sun mouse (on zs)

-  
openprom

-  
Sun Open boot PROM (what became IEEE 1275) configuration driver

-  
power

-  
sun4m power management; the halt(8) and
-      shutdown(8) commands can use it to power down the
-      system.

-  
si

-  
NCR5380 "SCSI-2" VMEbus (Sun 4/200, Sun 4/400) SCSI
-    controller

-  
sw

-  
NCR5380 obio (Sun 4/100) "SCSI Weird" SCSI controller

-  
tcx

-  
8 or 24 bit Sbus color graphics frame buffer

-  
xd

-  
Xylogics 753/7053 VMEbus SMD disk controller

-  
xy

-  
Xylogics 450/451 VMEbus SMD disk controller

-  
zs

-  
Zilog 8530 serial controller

-

-

-

-

-
The following devices are not supported, due to unavailability of
-    either documentation or sample hardware:

-

-  
dbri

-  
Dual Basic Rate Interface (BRI) ISDN (SPARC LX & SPARCstation 10)

-

-

-

-

-
This sparc intro appeared in
-    NetBSD 1.3. Large chunks of text carefully recycled
-    (shamelessly appropriated) from NetBSD/pmax
-    intro.

-

-

-
-  
-    
-    
-  
-
September 22, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/kbd.4 3.html b/static/netbsd/man4/man4.sparc/kbd.4 3.html
deleted file mode 100644
index 602de745..00000000
--- a/static/netbsd/man4/man4.sparc/kbd.4 3.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
KBD(4)Device Drivers Manual (sparc)KBD(4)

-

-

-

-
kbd — Sun
-    workstation keyboard

-

-

-

-
pseudo-device kbd

-

-

-

-
The kbd driver provides an interface to
-    the workstation console keyboard. The Sun "type 2", "type
-    3", "type 4", and "type 5" keyboards are supported.
-    The "type 5" keyboard is treated as if it were a "type
-    4". All types generate keycodes encoding the key identity and motion
-    (up or down) as the keys are pressed and released. The
-    kbd driver either passes the keycodes to an
-    application as they come in (e.g.) Xorg(1), or translates
-    them into ASCII characters first according to a set of built-in tables.

-
If the kbd is configured as the device to
-    be used for system console input (see sparc/openprom(4)),
-    it will be internally connected to the /dev/console
-    device special file, which can be used as a tty(4)
-  device.

-
The device special file /dev/kbd is used
-    to get direct access to the keyboard input stream.

-
The following ioctl's are supported (mostly just enough to keep
-    the Xorg(1) server going):

-

-  
KIOCTRANS

-  
Set translation mode. The argument is of type int *,
-      the only value supported is TR_UNTRANS_EVENT.

-  
KIOCGTRANS

-  
Get translation mode. The argument is of type int *.
-      TR_UNTRANS_EVENT is always returned.

-  
KIOCGETKEY

-  
Fill in old-style key station translation. The argument is of type
-      struct okiockey *.

-  
KIOCCMD

-  
Send a command to the keyboard. The argument is of type
-      int *, and can have one of the following values:
-    

-      
KBD_CMD_BELL

-      
Start the keyboard beeper.

-      
KBD_CMD_NOBELL

-      
Stop the keyboard beeper.

-      
KBD_CMD_CLICK

-      
Instruct the keyboard to make extra noise when touching keys.

-      
KBD_CMD_NOCLICK

-      
Instruct the keyboard to stop making extra noise when touching
-        keys.

-    

-  

-  
KIOCTYPE

-  
Get keyboard type. The argument is of type int *, in
-      which one of the values KB_SUN2,
-      KB_SUN3 or KB_SUN4 will be
-      returned.

-  
KIOCSDIRECT

-  
Route the keyboard input stream through the SunOS compatible event module.
-      The argument is of type int *, a non-zero value will
-      put the driver into "event" mode, while a value of zero will
-      make it return to "ASCII translation" mode.

-  
KIOCSKEY

-  
Set key station translation. The argument is of type
-      struct kiockey * (see
-      /usr/include/machine/kbio.h for
-      more details).

-  
KIOCGKEY

-  
Get key station translation. The argument is of type
-      struct kiockey *.

-  
KIOCLAYOUT

-  
Get keyboard layout (“type 4” only). The argument is of type
-      int *, in which the uninterpreted result of the
-      KBD_CMD_GLAYOUT keyboard command is returned (on
-      KB_SUN4 type keyboards this will be the setting of
-      a DIP switch bank).

-  
KIOCSLED

-  
Set LED state (“type 4” only). The argument is of type
-      char *, and is the inclusive OR of the following
-      flags:
-    

-    

-      
LED_NUM_LOCK

-      
 

-      
LED_COMPOSE

-      
 

-      
LED_SCROLL_LOCK

-      
 

-      
LED_CAPS_LOCK

-      
 

-    

-    
Each of these flags turn on the LED in the obvious key.

-  

-  
KIOCGLED

-  
Get LED state (“type 4” only). The argument is of type
-      char *, in which the current LED state is
-    returned.

-

-

-

-

-
sparc/ms(4)

-

-

-

-
kbd is hardwired to the built-in
-     serial
-    port at 1200 bps.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/magma.4 4.html b/static/netbsd/man4/man4.sparc/magma.4 4.html
deleted file mode 100644
index bef693c3..00000000
--- a/static/netbsd/man4/man4.sparc/magma.4 4.html	
+++ /dev/null
@@ -1,115 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAGMA(4)Device Drivers Manual (sparc)MAGMA(4)

-

-

-

-
magma — Magma Sp
-    Serial/Parallel board device driver

-

-

-

-
magma* at sbus? slot ? offset ?
-  

-  mtty* at magma?
-  

-  mbpp* at magma?

-

-

-

-
The magma driver provides an interface to
-    Magma LC2+1Sp, 2+1Sp, 4+1Sp, 8+2Sp, 4Sp, 8Sp, 12Sp, 16Sp, 1P and 2P boards.
-    These boards are based around the Cirrus Logic CD1400 serial/parallel
-    communications engine and the Cirrus Logic CD1190 parallel communications
-    engine.

-
The device minor numbers for this driver are encoded as
-  follows:

-

-
    +---+---+---+---+---+---+---+---+
-    | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-    +---+---+---+---+---+---+---+---+
-      |   |   |   |   |   |   |   |
-      |   |   |   |   +---+---+---+---> port number
-      |   |   |   |
-      |   |   |   +-------------------> dial-out (on tty ports)
-      |   |   |
-      |   |   +-----------------------> unused
-      |   |
-      +---+---------------------------> card number

-

-
Up to four cards are supported in the system.

-
All tty ports have full automatic hardware (RTS/CTS) flow control
-    available and a 12 byte FIFO on the chip in each direction so errors should
-    be minimal.

-

-

-

-

-  
/dev/tty[0-3][0-a]

-  
Serial ports

-  
/dev/bpp[0-3][0-1]

-  
Parallel ports

-

-

-

-

-

-  
mtty%d%x: ring buffer overflow

-  
Incoming characters have been discarded due to a buffer overflow. This is
-      caused by the process in control of the device not reading characters fast
-      enough.
-    
If need be you can make the ring buffer bigger by changing the
-        MAGMA_RBUF_SIZE #define to something bigger, but
-        it should be a multiple of two.

-  

-  
mtty%d%x: fifo overflow

-  
Incoming characters have been discarded due to a CD1400 channel overrun.
-      This is caused by interrupts not being serviced sufficiently quickly to
-      prevent the 12 byte receive FIFO on a serial channel from overflowing.
-    
Reducing the value of either the
-        MTTY_RX_FIFO_THRESHOLD or
-        MTTY_RX_DTR_THRESHOLD #define's to something
-        smaller may help slow machines avoid this problem.

-  

-

-

-

-

-
read(2), termios(4),
-    tty(4)

-

-

-

-
The driver was loosely based upon the cy(4)
-    Cyclades Cyclom device driver written by Andrew Herbert and Timo Rossi.

-

-

-

-
The driver was written by Iain
-  Hibbert.

-

-

-

-
CD1190 parallel support.

-
"bpp" input.

-
Dial-out (cua) devices are not yet supported.

-
"mdmbuf" is unsupported (see tty(4)
-    and termios(4)).

-
Automatic XON/XOFF handshaking could be implemented fairly
-  easily.

-
It would be good if the tty port waited for the FIFO to empty
-    before allowing a close, so that I could turn off the channel interrupts at
-    that time. It can be done.

-

-

-
-  
-    
-    
-  
-
April 21, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/mem.4 4.html b/static/netbsd/man4/man4.sparc/mem.4 4.html
deleted file mode 100644
index 31936847..00000000
--- a/static/netbsd/man4/man4.sparc/mem.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (sparc)MEM(4)

-

-

-

-
mem, kmem —
-    Sun main memory access driver

-

-

-

-
The file /dev/mem is an interface to the
-    physical memory of the computer. Byte offsets in this file are interpreted
-    as physical memory addresses. Reading and writing this file is equivalent to
-    reading and writing memory itself. An error will be returned if an attempt
-    is made to reference an offset outside of
-  /dev/mem.

-
Kernel virtual memory is accessed via the file
-    /dev/kmem in the same manner as
-    /dev/mem. Only kernel virtual addresses that are
-    currently mapped to memory are allowed.

-

-

-

-
On the SPARC, physical memory may be discontiguous; kernel virtual
-    memory begins at 0xf0000000.

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-

-

-

-

-
The files mem and
-    kmem appeared in Version 6
-    AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/ms.4 4.html b/static/netbsd/man4/man4.sparc/ms.4 4.html
deleted file mode 100644
index 53c5ff5f..00000000
--- a/static/netbsd/man4/man4.sparc/ms.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
MS(4)Device Drivers Manual (sparc)MS(4)

-

-

-

-
ms — Sun
-    workstation mouse driver

-

-

-

-
pseudo-device mouse

-

-

-

-
The ms driver provides an interface to the
-    workstation console mouse. This Mouse Systems three-button device produces
-    five-byte blobs of the form:

-

-
b dx dy dx dy

-

-
where “b” is the button state, encoded as
-    0x80|(~buttons) -- there are three buttons (4=left,
-    2=middle, 1=right) -- and “dx” and “dy” are X
-    and Y delta values, none of which are in the range
-    [0x80..0x87].

-
The device special file /dev/mouse is used
-    to get direct access to the mouse input stream. The following ioctl's are
-    supported (mostly just enough to keep the Xorg(1) server
-    going):

-

-  

-  
Set translation mode. The argument is of type int *,
-      the only value supported is VUID_FIRM_EVENT.

-  

-  
Get translation mode. The argument is of type int *.
-      VUID_FIRM_EVENT is always returned.

-

-

-

-
The mouse driver can be configured using the following kernel
-    configuration file options.

-

-  
options SUN_MS_BPS=integer

-  
This option causes the kernel to communicate with the mouse using the
-      serial baud rate integer. It is useful for mice
-      which do not communicate at 1200 baud.

-

-

-

-

-

-
sparc/kbd(4)

-

-

-

-
ms is hardwired to the built-in
-     serial
-    port.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/nell.4 4.html b/static/netbsd/man4/man4.sparc/nell.4 4.html
deleted file mode 100644
index b2246cf9..00000000
--- a/static/netbsd/man4/man4.sparc/nell.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
NELL(4)Device Drivers Manual (sparc)NELL(4)

-

-

-

-
nell — sbus pcmcia
-    bridge

-

-

-

-
nell* at sbus? slot ? offset ? flags 0
-  

-  pcmcia* at nell? controller ? socket ?

-

-

-

-
The nell is a pcmcia bridge for the sbus.
-    It is also known as STP4020, the name of the chipset used to implement it,
-    and has SUN part number 501-2367.

-
The firmware assigns two interrupt levels to the nell, but the
-    driver only needs a single interrupt. Depending on distribution of interrupt
-    levels on your machine you might prefer the driver to use either the first
-    (use flags value 0) or the second (use flags value 1).

-

-

-

-
Each nell instance creates a kernel
-    thread, named like the instance. This thread is used to watch for card
-    insertions and removals, and handling the attachment and initialization of
-    the card's driver.

-

-

-

-
pcmcia(4), sbus(4)

-

-

-
-  
-    
-    
-  
-
October 19, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/openprom.4 3.html b/static/netbsd/man4/man4.sparc/openprom.4 3.html
deleted file mode 100644
index 29e4bf9b..00000000
--- a/static/netbsd/man4/man4.sparc/openprom.4 3.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
OPENPROM(4)Device Drivers Manual (sparc)OPENPROM(4)

-

-

-

-
openprom — Sun
-    OPENPROM and EEPROM interface

-

-

-

-
#include
-    <machine/openpromio.h>

-

-

-

-
The file /dev/openprom is an interface to
-    the SPARC OPENPROM, including the EEPROM area. This interface is highly
-    stylized; ioctls are used for all operations. These ioctls refer to
-    “nodes”, which are simply “magic” integer values
-    describing data areas. Occasionally the number 0 may be used or returned
-    instead, as described below. A special distinguished “options”
-    node holds the EEPROM settings.

-
The calls that take and/or return a node use a pointer to an
-    int variable for this purpose; others use a pointer
-    to an struct opiocdesc descriptor, which contains a
-    node and two counted strings. The first string comprises the fields
-    op_namelen (an int) and
-    op_name (a char *), giving
-    the name of a field. The second string comprises the fields
-    op_buflen and op_buf, used
-    analogously. These two counted strings work in a
-    “value-result” fashion. At entry to the ioctl, the counts are
-    expected to reflect the buffer size; on return, the counts are updated to
-    reflect the buffer contents.

-
The following ioctls are supported:

-

-  

-  
Takes nothing, and fills in the options node number.

-  
OPIOCGETNEXT

-  
Takes a node number and returns the number of the following node. The node
-      following the last node is number 0; the node following number 0 is the
-      first node.

-  

-  
Takes a node number and returns the number of the first
-      “child” of that node. This child may have siblings; these
-      can be discovered by using OPIOCGETNEXT.

-  

-  
Fills in the value of the named property for the given node. If no such
-      property is associated with that node, the value length is set to -1. If
-      the named property exists but has no value, the value length is set to
-    0.

-  

-  
Writes the given value under the given name. The OPENPROM may refuse this
-      operation; in this case EINVAL is returned.

-  

-  
Finds the property whose name follows the given name in OPENPROM internal
-      order. The resulting name is returned in the value field. If the named
-      property is the last, the “next” name is the empty string.
-      As with OPIOCGETNEXT, the next name after the
-      empty string is the first name.

-

-

-

-

-
/dev/openprom

-

-

-

-
The following may result in rejection of an operation:

-

-  
[]

-  
The given node number is not zero and does not correspond to any valid
-      node, or is zero where zero is not allowed.

-  
[]

-  
The requested operation requires permissions not specified at the call to
-      open().

-  
[]

-  
The given name or value field exceeds the maximum allowed length (8191
-      bytes).

-

-

-

-

-
ioctl(2)

-
IEEE 1275
-    Open Firmware

-

-

-

-
Due to limitations within the openprom
-    itself, these functions run at elevated priority and may adversely affect
-    system performance.

-
The Sun openprom is what became the Open
-    Firmware (IEEE 1275) standard for processor and system independent boot
-    firmware.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/pnozz.4 4.html b/static/netbsd/man4/man4.sparc/pnozz.4 4.html
deleted file mode 100644
index 61ccde45..00000000
--- a/static/netbsd/man4/man4.sparc/pnozz.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
PNOZZ(4)Device Drivers Manual (sparc)PNOZZ(4)

-

-

-

-
pnozz — Weitek
-    Power9100 accelerated frame buffer

-

-

-

-
pnozz0 at sbus? slot ? offset ?

-

-

-

-
The pnozz is a color frame buffer with
-    graphics acceleration, embedded in the Tadpole SPARCbook 3GS, 3GX, 3TX, and
-    3XP laptops. It is based on the Weitek Power9100 video processor and an IBM
-    RGB525 RAMDAC.

-
If the sparc/tctrl(4) device is also configured,
-    the pnozz will be powered down when the lid of the
-    laptop is closed or the screen is blanked.

-

-

-

-
sbus(4), sparc/intro(4),
-    sparc/tctrl(4)

-

-

-

-
Support for the pnozz first appeared in
-    NetBSD 1.6.

-

-

-

-
There is currently no way to switch back and forth from the
-    onboard display to the external connector. It is not possible to change
-    resolutions or color depth.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/tctrl.4 3.html b/static/netbsd/man4/man4.sparc/tctrl.4 3.html
deleted file mode 100644
index dddb0103..00000000
--- a/static/netbsd/man4/man4.sparc/tctrl.4 3.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCTRL(4)Device Drivers Manual (sparc)TCTRL(4)

-

-

-

-
tctrl — Tadpole
-    Microcontroller Interface

-

-

-

-
tctrl0 at obio0

-

-

-

-
The tctrl driver provides control over
-    many functions on the Tadpole SPARCbook 3 series laptops, via their TS102
-    chip. The microcontroller is used to power the TFT display down when the
-    laptop lid is closed and when the screen is blanked by the
-    sparc/pnozz(4) driver. The tctrl
-    is also used to power the laptop off when the reboot(2)
-    system call is used with the RB_POWERDOWN flag is set.
-    Power button events are forwarded to powerd(8). The PCMCIA
-    part of the controller is supported by sparc/tslot(4).

-

-

-

-
reboot(2), sparc/intro(4),
-    sparc/pnozz(4), sparc/tslot(4),
-    powerd(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/tcx.4 4.html b/static/netbsd/man4/man4.sparc/tcx.4 4.html
deleted file mode 100644
index 8736b9de..00000000
--- a/static/netbsd/man4/man4.sparc/tcx.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCX(4)Device Drivers Manual (sparc)TCX(4)

-

-

-

-
tcx — Sun
-    accelerated 8/24-bit color frame buffer

-

-

-

-
tcx* at sbus? slot ? offset ?

-

-

-

-
The tcx is a memory based color frame
-    buffer, with graphics acceleration and overlay capabilities. Its control
-    registers, colour lookup table and pixel memory can be mapped into a user
-    process address space by using the mmap(2) system call.
-    The tcx driver supports the minimal ioctl's needed
-    to run Xorg(1), and can be operated in
-    sparc/cgthree(4) emulation mode.

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgfour(4),
-    sparc/cgsix(4), sparc/cgthree(4),
-    sparc/cgtwo(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/timer.4 4.html b/static/netbsd/man4/man4.sparc/timer.4 4.html
deleted file mode 100644
index bfe15cff..00000000
--- a/static/netbsd/man4/man4.sparc/timer.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
TIMER(4)Device Drivers Manual (sparc)TIMER(4)

-

-

-

-
timer — Timer
-    driver for Sun SPARC computers

-

-

-

-
timer0 at mainbus0 # sun4c
-  

-  timer0 at obio0 # sun4m
-  

-  timer0 at obio0 addr 0xef000000 # sun4/300

-

-

-

-
The timer device is used to generate
-    clocks for the NetBSD kernel.

-
The hardclock is provided by the timer register and the statistics
-    clock by CPU counter registers.

-

-

-

-
sparc/clock(4)

-

-

-

-
The timer appeared in
-    NetBSD 1.0.

-

-

-
-  
-    
-    
-  
-
February 24, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/tslot.4 4.html b/static/netbsd/man4/man4.sparc/tslot.4 4.html
deleted file mode 100644
index 726f5007..00000000
--- a/static/netbsd/man4/man4.sparc/tslot.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
TSLOT(4)Device Drivers Manual (sparc)TSLOT(4)

-

-

-

-
tslot — sbus
-    pcmcia bridge

-

-

-

-
tslot* at sbus? slot ? offset ?
-  

-  pcmcia* at tslot? controller ? socket ?

-

-

-

-
tslot is a driver for the PCMCIA part of
-    the TS102 chip found in Tadpole SPARCbooks. The microcontroller interface is
-    supported by sparc/tctrl(4).

-

-

-

-
Each tslot instance creates a kernel
-    thread, named like the instance. This thread is used to watch for card
-    insertions and removals, and handling the attachment and initialization of
-    the card's driver.

-

-

-

-
pcmcia(4), sbus(4),
-    sparc/tctrl(4)

-

-

-

-
Inserting two cards with different requirements, like voltage, may
-    cause one of them not to function correctly.

-

-

-
-  
-    
-    
-  
-
June 11, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/xd.4 4.html b/static/netbsd/man4/man4.sparc/xd.4 4.html
deleted file mode 100644
index 33bf921b..00000000
--- a/static/netbsd/man4/man4.sparc/xd.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
XD(4)Device Drivers Manual (sparc)XD(4)

-

-

-

-
xd — Xylogics 753
-    or 7053 VME SMD disk controller driver

-

-

-

-
xdc0 at vmel0 addr 0xffffee80 level 3 vect
-    0x44 (sun4)
-  

-  xdc1 at vmel0 addr 0xffffee90 level 3 vect 0x45 (sun4)
-  

-  xdc2 at vmel0 addr 0xffffeea0 level 3 vect 0x46 (sun4)
-  

-  xdc3 at vmel0 addr 0xffffeeb0 level 3 vect 0x47 (sun4)
-  

-  xd* at xdc? drive ?  (sun4)

-

-

-

-
The xd is a Xylogics 753 or 7053 SMD disk
-    controller found on sun4 systems with the VME bus. The Xylogics 753 and 7053
-    are programmed the same way, but are different sizes. The 753 is a 6U VME
-    card, while the 7053 is a 9U VME card.

-

-

-

-
sparc/intro(4),
-  sparc/xy(4)

-
Xylogics
-    manuals (scanned)

-

-

-

-
The xd driver first appeared in
-    NetBSD 1.1 and was written by
-    Charles D. Cranor.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/xy.4 4.html b/static/netbsd/man4/man4.sparc/xy.4 4.html
deleted file mode 100644
index 9905663b..00000000
--- a/static/netbsd/man4/man4.sparc/xy.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
XY(4)Device Drivers Manual (sparc)XY(4)

-

-

-

-
xy — Xylogics 450
-    or 451 VME SMD disk controller driver

-

-

-

-
xyc0 at vmes0 addr 0xffffee40 level 3 vect
-    0x48 (sun4)
-  

-  xyc1 at vmes0 addr 0xffffee48 level 3 vect 0x49 (sun4)
-  

-  xy* at xyc? drive ?  (sun4)

-

-

-

-
The xy is a Xylogics 450/451 SMD disk
-    controller found on sun4 systems with the VME bus.

-

-

-

-
sparc/intro(4),
-  sparc/xd(4)

-
Xylogics
-    manuals (scanned)

-

-

-

-
The xy driver first appeared in
-    NetBSD 1.1 and was written by
-    Charles D. Cranor.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc/zx.4 4.html b/static/netbsd/man4/man4.sparc/zx.4 4.html
deleted file mode 100644
index bb003b3c..00000000
--- a/static/netbsd/man4/man4.sparc/zx.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZX(4)Device Drivers Manual (sparc)ZX(4)

-

-

-

-
zx — Sun ZX / Leo
-    frame buffer driver

-

-

-

-
zx* at sbus? slot ? offset ?

-

-

-

-
The zx is a memory based color frame
-    buffer, with graphics acceleration and overlay capabilities. Its control
-    registers, colour lookup table and pixel memory can be mapped into a user
-    process address space by using the mmap(2) system call.
-    The zx driver supports the minimal ioctl's needed to
-    run X(7).

-

-

-

-
sparc/bwtwo(4),
-    sparc/cgeight(4), sparc/cgfour(4),
-    sparc/cgsix(4), sparc/cgthree(4),
-    sparc/cgtwo(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/envctrl.4 4.html b/static/netbsd/man4/man4.sparc64/envctrl.4 4.html
deleted file mode 100644
index 04b5713b..00000000
--- a/static/netbsd/man4/man4.sparc64/envctrl.4 4.html	
+++ /dev/null
@@ -1,125 +0,0 @@
-
-  
-    
-    
-    
-  
-
ENVCTRL(4)Device Drivers Manual (sparc64)ENVCTRL(4)

-

-

-

-
envctrl — Sun
-    Ultra Enterprise 450 environmental monitoring

-

-

-

-
envctrl*	at ebus?

-

-

-

-
The envctrl driver provides thermal
-    monitoring of processors and power supplies, as well as automatic fan
-    regulation. The driver attaches to the SUNW,envctrl subsystem found on Ultra
-    Enterprise 450 systems.

-
The following sensors can be queried with
-    envstat(8):

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
degCProcessor 0 temperature
degCProcessor 1 temperature
degCProcessor 2 temperature
degCProcessor 3 temperature
degCPower supply 0 temperature
degCPower supply 1 temperature
degCPower supply 2 temperature
degCAmbient temperature
VVoltage used to drive processor fans
VVoltage used to drive power supply fans
countnumber of failed power supplies
countnumber of failed fans

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The envctrl driver first appeared in
-    NetBSD 5.0.

-

-

-

-
Tobias Nygren
-    <tnn@NetBSD.org>

-

-

-

-
The driver doesn't support SUNW,envctrltwo found on the Ultra
-    Enterprise 250.

-
Environmental interrupts are not supported.

-

-

-
-  
-    
-    
-  
-
April 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/fdc.4 4.html b/static/netbsd/man4/man4.sparc64/fdc.4 4.html
deleted file mode 100644
index 15021467..00000000
--- a/static/netbsd/man4/man4.sparc64/fdc.4 4.html	
+++ /dev/null
@@ -1,112 +0,0 @@
-
-  
-    
-    
-    
-  
-
FD(4)Device Drivers Manual (sparc64)FD(4)

-

-

-

-
fdc — Sun
-    SPARCstation i82072 or i82077 floppy disk controller driver

-

-

-

-
fdc0 at sbus0 (SBus based machines)
-  

-  fdc0 at ebus0 (PCI based machines)
-  

-  fd* at fdc0

-

-

-

-
This is the driver for the built-in floppy disk drive run by the
-    Intel i82072 or i82077 controller chip found on the SPARCstation desktop
-    systems, and other SPARC systems.

-
Bits [0-3] of the minor device number of the special files
-    referring to this device encode the floppy density as follows:

-

-

-  
0

-  
3.5'' 1.44MB floppy diskettes.

-  
1

-  
3.5'' 720KB floppy diskettes.

-  
2

-  
3.5'' 360KB floppy diskettes.

-  
3

-  
3.5'' 1.2MB/NEC Japanese format floppy diskettes.

-

-

-

-

-

-
The driver supports floppy disk formatting using the interfaces in
-    <sys/fdio.h>:

-

-

-  

-    struct fdformat_parms

-  
Fetch current formatting parameters. This gets the default parameters for
-      the open device if no parameters have been set during the session.
-    

-  

-  

-    struct fdformat_parms

-  
Set formatting parameters. The driver saves this state and it persists
-      while the device is open.
-    

-  

-  

-    struct fdformat_cmd

-  
Format a track on the medium. If this call returns
-      EINVAL, the track formatting parameters were out
-      of range for the medium. If it returns EIO, there
-      was a medium error while formatting the track.
-    

-  

-  

-    int

-  
Set driver options which persist until the device is closed. The options
-      should be the logical OR of the desired values below:
-    

-    

-      

-      
Do not retry operations on failure

-      

-      
Do not print error messages to the console

-    

-    

-  

-  

-    int

-  
Fetch drive options.

-

-
A typical use of the formatting facilities would be to open the
-    device, call FDIOCGETFORMAT to fetch the current
-    format parameters, perhaps change a parameter or two, display the formatting
-    details to the user, and then call FDIOCSETFORMAT
-    followed by a series of calls to
-  FDIOCFORMAT_TRACK.

-

-

-

-
eject(1), fdformat(1)

-

-

-

-
The fdc driver first appeared in
-    NetBSD 4.0.

-

-

-

-
The ebus attachment does not yet work.

-

-

-
-  
-    
-    
-  
-
May 8, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/ffb.4 4.html b/static/netbsd/man4/man4.sparc64/ffb.4 4.html
deleted file mode 100644
index 28243382..00000000
--- a/static/netbsd/man4/man4.sparc64/ffb.4 4.html	
+++ /dev/null
@@ -1,179 +0,0 @@
-
-  
-    
-    
-    
-  
-
FFB(4)Device Drivers Manual (sparc64)FFB(4)

-

-

-

-
ffb — Sun
-    accelerated 24-bit color frame buffer

-

-

-

-
ffb* at mainbus0 addr 0xff8de000: Creator3D,
-    model SUNW,501-4790, dac 10 (UltraSPARC II horizontal)
-  

-  ffb* at mainbus0 addr 0xfeb80000: Creator3D, model
-    SUNW,501-4788, dac 10 (UltraSPARC II vertical)
-  

-  ffb* at mainbus0: Elite3D, model SUNW,540-3623, dac 10
-    (UltraSPARC II vertical)
-  

-  ffb* at upa0: Creator3D, model SUNW,501-4788, dac 10
-    (UltraSPARC III vertical)
-  

-  ffb* at upa0: Elite3D, model SUNW,540-3623, dac 10
-    (UltraSPARC III vertical)

-

-

-

-
The ffb is a UPA based color frame buffer,
-    found in some Sun SBus and PCI systems. The ffb
-    driver supports both the Creator/Creator3D, and the Elite3D frame
-  buffers.

-
There are several versions of the ffb
-    board. The Sun part numbers and board types are:

-

-

-

-  
501-2634

-  
Creator Series 1 (FFB)

-  
 

-  
Ultra1, Ultra2

-  
501-4127

-  
Creator Series 1 (FFB)

-  
 

-  
Ultra1, Ultra2, Enterprisexx00

-  
501-2633

-  
Creator 3D Series 1 (FFB)

-  
 

-  
Ultra1, Ultra2

-  
501-3129

-  
Creator 3D Series 1 (FFB)

-  
 

-  
Ultra1, Ultra2, Enterprisexx00

-  
501-4126

-  
Creator 3D Series 1 (FFB)

-  
 

-  
Ultra1, Ultra2

-  
501-4174

-  
Creator Series 2 (FFB2)

-  
 

-  
Ultra 30, Ultra 60

-  
501-4173

-  
Creator3D Series 2 (FFB2)

-  
 

-  
Ultra1, Ultra2, Enterprisexx00

-  
501-4172

-  
Creator3D Series 2 (FFB2)

-  
 

-  
Ultra30, Ultra60

-  
501-4789

-  
Creator Series 3 (FFB2+)

-  
 

-  
Ultra10, Ultra30, Ultra60

-  
501-4790

-  
Creator 3D Series 3 (FFB2+)

-  
 

-  
Ultra2, Enterprisexx00

-  
501-4788, 501-5690

-  
Creator 3D Series 3 (FFB2+)

-  
 

-  
Ultra10, Ultra30, Ultra60, Blade1000, Blade2000

-  
501-4860, 501-5268, 501-5201, 501-5484

-  
Elite3D-m3 Series 1 (AFB)

-  
 

-  
Ultra10, Ultra30, Ultra60, Ultra80

-  
540-3623, 540-3902

-  
Elite3D-m6 Series 1 (AFB)

-  
 

-  
Ultra10, Ultra30, Ultra60, Ultra80

-  
501-5574, 501-5575

-  
Elite3D-m3 Series 2 (AFB)

-  
 

-  
Ultra10, Ultra30, Ultra60, Ultra80, Blade1000, Blade2000

-  
540-4313

-  
Elite3D-m6 Series 2 (AFB)

-  
 

-  
Ultra10, Ultra30, Ultra60, Ultra80, Blade1000, Blade2000

-  
540-3058, 540-3979, 540-4335

-  
Elite3D-m6 (AFB)

-  
 

-  
Ultra2, Ultra450, Enterprisexx00

-

-

-
The ‘Creator’ cards have 5MB of on-board memory,
-    support a maximum graphics resolution of 1280x1024, and are
-  single-buffered.

-
The ‘Creator3D’ cards have 15MB of on-board memory
-    support a maximum resolution of 1280x1024 double-buffered, and 1920x1360
-    single-buffered.

-
The ‘Elite3D’ cards have 15MB of on-board memory,
-    support a maximum resolution of 1280x1024, and are always double-buffered.
-    The ‘Elite3D-m3’ cards have one hardware geometry engine,
-    whereas the ‘Elite3D-m6’ cards have two.

-
The ‘Series 3’ cards are considerably faster than
-    the ‘Series 1’ and ‘Series 2’ cards.

-
The ffb driver supports reading
-    EDID data from connected monitors on ‘Series
-    2’ and ‘Series 3’ cards, and will automatically set a
-    resolution that is supported by both the card and the monitor if the
-    EDID data can be read. This can be overridden for
-    the console frame buffer, by setting the
-    output-device openprom variable. For example, the
-    following openprom command will set the console resolution to 1280x1024 @
-    60Hz, which will not be altered by the ffb
-  driver.

-

-
setenv output-device screen:r1280x1024x60

-

-

-

-

-
eeprom(8)

-

-

-

-
It is necessary to blank the video output when reading
-    EDID data.

-
The ffb driver does not support 3D
-    acceleration.

-
Not all 13W3 to
-    VGA converters connect 13W3
-    pin 2 to VGA pin 9. This pin supplies +5V DC to
-    power the monitor EEPROM, even when the monitor is
-    powered off, and is necessary in order to obtain
-    EDID data on some monitors.

-
Adapters that are known to connect these pins are:

-

-

-

-  
530-2917

-  

-    cable

-  
130-3034

-  

-    cable

-

-

-
Adapters that are known not to connect these pins are:

-

-

-

-  
530-2357

-  

-    cable

-

-

-

-

-
-  
-    
-    
-  
-
April 1, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/intro.4 4.html b/static/netbsd/man4/man4.sparc64/intro.4 4.html
deleted file mode 100644
index a118ef9d..00000000
--- a/static/netbsd/man4/man4.sparc64/intro.4 4.html	
+++ /dev/null
@@ -1,153 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (sparc64)INTRO(4)

-

-

-

-
intro —
-    introduction to sparc64 special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the SPARC64
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), autoconf(4),
-    cd(4), cgsix(4),
-    ch(4), kbd(4), le(4),
-    magma(4), mem(4),
-    ms(4), openprom(4),
-    scsi(4), sd(4), ss(4),
-    st(4), tcx(4),
-  uk(4)

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-  
auxio

-  
Auxiliary I/O & LED

-  
bpp

-  
Bi-directional Parallel port

-  
cgsix

-  
8 bit obio (sun4c & sun4m), Sbus color graphics frame buffer

-  
com

-  
PC-style serial port

-  
eeprom

-  
Sun non-volatile configuration RAM driver

-  
esp

-  
ESP200 SCSI controller
-    

-    FSBE/S (X1053A, part # 501-2015) Fast SCSI-2/Buffered Ethernet Sbus
-      controller

-  
fdc

-  
Floppy Disk Controller

-  
ffb

-  
Creator & Creaor3D graphics frame buffer

-  
isp

-  
Qlogic ISP Sbus and PCI SCSI controller

-  
kbd

-  
Sun type 2, type 3, type 4, and type 5 keyboards (on zs or com)

-  
le/lebuffer

-  
AMD 7990 LANCE Ethernet controller

-  
lpt

-  
PC-style parallel port

-  
magma

-  
Magma Sp Serial/Parallel board device driver

-  
ms

-  
Sun mouse (on zs or com)

-  
openprom

-  
Sun Open boot PROM (what became IEEE 1275) configuration driver

-  
power

-  
power management halt(8) and
-      shutdown(8) commands can use it to power down the
-      system.

-  
sab

-  
Siemens 82532 & 83538 serial controller

-  
zs

-  
Zilog 8530 serial controller

-

-
PCI devices are supported through the pci(4) bus
-    and associated devices.

-
PCMCIA devices are supported through the
-    pcmcia(4) bus and associated devices.

-
Cardbus devices are supported through the
-    cardbus(4) bus and associated devices.

-
USB devices are supported through the usb(4) bus
-    and associated devices.

-

-

-

-
The following devices are not supported, due to unavailability of
-    either documentation, sample hardware, or willing volunteer:

-

-  
atifb

-  
ATI 3D Rage Pro VGA graphics adapter (Ultra5, Ultra10)

-  
fdc

-  
sun4u floppy drive controllers (EBus based machines only)

-  
cgfourteen

-  
24 bit Sbus color frame buffer

-  
cgthree

-  
8 bit Sbus color frame buffer

-

-

-

-

-
This sparc64 intro appeared in
-    NetBSD 1.6. Large chunks of text carefully recycled
-    (shamelessly appropriated) from NetBSD/sparc
-    intro.

-

-

-
-  
-    
-    
-  
-
May 10, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/lom.4 4.html b/static/netbsd/man4/man4.sparc64/lom.4 4.html
deleted file mode 100644
index 7605aa5b..00000000
--- a/static/netbsd/man4/man4.sparc64/lom.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOM(4)Device Drivers Manual (sparc64)LOM(4)

-

-

-

-
lom — lights out
-    management

-

-

-

-
lom* at ebus?

-

-

-

-
The lom driver provides support for the
-    LOMlite lights out management module found on Sun Netra t1 systems and the
-    LOMlite2 module found on Sun Fire V100/V120 and Sun Netra T1/X1 systems.
-    Fault LED and alarms status, temperature readings, PSU status and fan status
-    provided by the LOM are made available through the
-    envstat(8) interface. The integrated watchdog timer can be
-    configured through the wdogctl(8) interface. The watchdog
-    timer supports timeouts between 1 and 126 seconds.

-
Fault LED and alarms status can be changed through the
-    sysctl(8) interface. An entry for the
-    lom driver is created under the
-    hw.lom
-    MIB.

-
The lom driver will update the hostname
-    stored in the LOM whenever the system's hostname is changed.

-

-

-

-
hostname(1), envsys(4),
-    envstat(8), sysctl(8),
-    wdogctl(8)

-

-

-

-
The lom driver first appeared in
-    OpenBSD 4.7 and was then ported to
-    NetBSD 5.1.

-

-

-

-
The lom driver was written by
-    Mark Kettenis
-    <kettenis@openbsd.org>.

-

-

-
-  
-    
-    
-  
-
December 28, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/psycho.4 4.html b/static/netbsd/man4/man4.sparc64/psycho.4 4.html
deleted file mode 100644
index 375412b4..00000000
--- a/static/netbsd/man4/man4.sparc64/psycho.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSYCHO(4)Device Drivers Manual (sparc64)PSYCHO(4)

-

-

-

-
psycho —
-    UltraSPARC Host/PCI bridge

-

-

-

-
psycho* at mainbus0
-  

-  pci* at psycho?

-

-

-

-
The psycho device provides support for the
-    pci(4) bus on sparc64 systems, most often found on
-    UltraSPARC I and UltraSPARC II based systems.

-

-

-

-
intro(4), pci(4)

-

-

-

-
Support for the psycho first appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
November 3, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/pyro.4 4.html b/static/netbsd/man4/man4.sparc64/pyro.4 4.html
deleted file mode 100644
index 52ecc16d..00000000
--- a/static/netbsd/man4/man4.sparc64/pyro.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PYRO(4)Device Drivers Manual (sparc64)PYRO(4)

-

-

-

-
pyro — SPARC64
-    Host/PCIe bridge

-

-

-

-
pyro* at mainbus0
-  

-  pci* at pyro?

-

-

-

-
The pyro device provides support for the
-    Fire and Oberon pci(4) bus, as found on UltraSPARC III
-    based sparc64 systems.

-

-

-

-
intro(4), pci(4)

-

-

-

-
The pyro driver first appeared in
-    OpenBSD 4.2. It was first available in
-    NetBSD 6.0.

-

-

-

-
The pyro driver was written by
-    Mark Kettenis
-    <kettenis@openbsd.org>,
-    and ported to NetBSD by Matthew R.
-    Green
-    <mrg@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 15, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/sab.4 4.html b/static/netbsd/man4/man4.sparc64/sab.4 4.html
deleted file mode 100644
index 1f3b25bf..00000000
--- a/static/netbsd/man4/man4.sparc64/sab.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
SAB(4)Device Drivers Manual (sparc64)SAB(4)

-

-

-

-
sab, sabtty
-    — Infineon 82532 Enhanced Serial Communication
-    Controller (ESCC2)

-

-

-

-
sab* at ebus?
-  

-  sabtty* at sab? channel ?

-

-

-

-
The sab driver provides TTY support for
-    the Infineon (previously Siemens) 82532 serial communications interface
-    found in many Sun Ultra workstations and servers.

-
Input and output speeds for each line may be set to any baud rate
-    in the following list: 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800,
-    2400, 4800, 9600, 19200, 38400, 57600, 76800, 115200, 153600, 230400,
-    307200, 460800, 614400, 921600.

-

-

-

-
The speed cannot be changed on the ports connected the Remote
-    System Control (RSC) on a Sun Enterprise[tm] 250 Server (ttyh2 and ttyh3).
-    These ports are fixed at 115200 baud.

-

-

-

-

-  
/dev/ttyh[0123]

-  
serial ports

-

-

-

-

-

-  
sab*: ring overflow

-  
The software input "ring" has overflowed. This usually means
-      input flow-control is not configured correctly (i.e. incorrect cable
-      wiring).

-

-

-

-

-
tty(4), zstty(4)

-

-

-

-
The sabtty driver first appeared in
-    OpenBSD 3.1 and was then ported to
-    NetBSD 2.0.

-

-

-

-
Jason L. Wright

-

-

-
-  
-    
-    
-  
-
January 18, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/schizo.4 4.html b/static/netbsd/man4/man4.sparc64/schizo.4 4.html
deleted file mode 100644
index c87041ca..00000000
--- a/static/netbsd/man4/man4.sparc64/schizo.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCHIZO(4)Device Drivers Manual (sparc64)SCHIZO(4)

-

-

-

-
schizo —
-    UltraSPARC Host/PCI bridge

-

-

-

-
schizo* at mainbus0
-  

-  pci* at schizo?

-

-

-

-
The schizo device provides support for the
-    Schizo, Schizo+ and Tomatillo pci(4) bus, as found on
-    UltraSPARC III and UltraSPARC IV based sparc64 systems.

-

-

-

-
intro(4), pci(4)

-

-

-

-
The schizo driver first appeared in
-    OpenBSD 3.2. It was later ported to
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
November 3, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/tadpmu.4 4.html b/static/netbsd/man4/man4.sparc64/tadpmu.4 4.html
deleted file mode 100644
index 5a994ce2..00000000
--- a/static/netbsd/man4/man4.sparc64/tadpmu.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
TADPMU(4)Device Drivers Manual (sparc64)TADPMU(4)

-

-

-

-
tda — Tadpole
-    PMU

-

-

-

-
Tadpole PMU Version 1.33

-

-

-

-
The tda driver provides basic support for
-    the Tadpole PMU found in Tadpole SPARCle and Viper systems. The status of
-    the AC adapter, battery, and fan are reported via the
-    envstat(8) interface, and AC adapter and lid switch events
-    are reported via the sysmon_pswitch(9) interface.

-

-

-

-
envstat(8)

-

-

-

-
The battery status is reported by reading the battery voltage. Pp.
-    The points at which the battery level becomes warning and critical are
-    reported by the PMU, but are not directly correlated with battery voltage,
-    so might be misreported by the driver.

-

-

-
-  
-    
-    
-  
-
May 16, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sparc64/tda.4 3.html b/static/netbsd/man4/man4.sparc64/tda.4 3.html
deleted file mode 100644
index cbd77f6d..00000000
--- a/static/netbsd/man4/man4.sparc64/tda.4 3.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
TDA(4)Device Drivers Manual (sparc64)TDA(4)

-

-

-

-
tda — TDA8444 fan
-    speed controller

-

-

-

-
tda0 at iic1 addr 0x24: fan-control

-

-

-

-
The tda driver provides support for the
-    TDA8444 DAC used to control the fan speeds in Sun Blade 1000 and Blade 2000
-    systems. The speed of the CPU fan and of the system fan are automatically
-    adjusted every 60 seconds, based on the currently reported CPU and system
-    temperatures, respectively.

-
The speed-related values are made available through the
-    envstat(8) interface. The range of the values are:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
<=57>=67
<=20>=30
1263

-

-

-

-
admtemp(4), envstat(8)

-

-

-

-
The temperatures are reported as ‘internal’ and
-    ‘external’ instead of ‘system’ and
-    ‘CPU’, respectively.

-

-

-
-  
-    
-    
-  
-
February 2, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/autoconf.4 4.html b/static/netbsd/man4/man4.sun2/autoconf.4 4.html
deleted file mode 100644
index 680008bc..00000000
--- a/static/netbsd/man4/man4.sun2/autoconf.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (sun2)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel. Devices which
-    exist in the machine but are not configured into the kernel are not
-    detected.

-

-

-

-

-  
CPU class not configured.

-  
You tried to boot NetBSD on a class of CPU type
-      which it doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-

-

-

-

-
config(1), sun2/intro(4),
-    boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/bwtwo.4 4.html b/static/netbsd/man4/man4.sun2/bwtwo.4 4.html
deleted file mode 100644
index 03ca13a4..00000000
--- a/static/netbsd/man4/man4.sun2/bwtwo.4 4.html	
+++ /dev/null
@@ -1,32 +0,0 @@
-
-  
-    
-    
-    
-  
-
BWTWO(4)Device Drivers Manual (sun2)BWTWO(4)

-

-

-

-
bwtwo — Sun
-    monochromatic frame buffer

-

-

-

-
bwtwo0 at obmem0 addr 0x700000
-  

-  bwtwo0 at obio addr 0x0

-

-

-

-
The bwtwo is a memory based black and
-    white frame buffer. It supports the minimal ioctl's needed to run
-    X.

-

-

-
-  
-    
-    
-  
-
June 10, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/ec.4 4.html b/static/netbsd/man4/man4.sun2/ec.4 4.html
deleted file mode 100644
index 4d67f38b..00000000
--- a/static/netbsd/man4/man4.sun2/ec.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
EC(4)Device Drivers Manual (sun2)EC(4)

-

-

-

-
ec — 3Com 3c400
-    Multibus Ethernet interface driver

-

-

-

-
ec0 at mbmem0 addr 0xe0000 ipl 3
-  

-  ec1 at mbmem0 addr 0xe2000 ipl 3

-

-

-

-
The ec interface provides access to the 10
-    Mb/s Ethernet network via the 3Com 3c400 Ethernet chip set.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ec interface employs the Address Resolution Protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-
arp(4), inet(4),
-    sun2/ie(4), sun2/intro(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/ie.4 4.html b/static/netbsd/man4/man4.sun2/ie.4 4.html
deleted file mode 100644
index 9846123d..00000000
--- a/static/netbsd/man4/man4.sun2/ie.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
IE(4)Device Drivers Manual (sun2)IE(4)

-

-

-

-
ie — Intel 82586
-    Ethernet interface driver

-

-

-

-
ie0 at obio0 addr 0x7f0800 ipl 3
-  

-  ie0 at mbmem0 addr 0x88000 ipl 3
-  

-  ie1 at mbmem0 addr 0x8c000 ipl 3
-  

-  ie1 at vme0 addr 0xe88000,0xe00000 len -1,0x40000 irq 3 vect
-    0x75

-

-

-

-
The ie interface provides access to the 10
-    Mb/s Ethernet network via the Intel 82586 Ethernet chip set.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ie interface employs the Address Resolution Protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-
arp(4), inet(4),
-    sun2/ec(4), sun2/intro(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/intro.4 3.html b/static/netbsd/man4/man4.sun2/intro.4 3.html
deleted file mode 100644
index a8fe1e49..00000000
--- a/static/netbsd/man4/man4.sun2/intro.4 3.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (sun2)INTRO(4)

-

-

-

-
intro —
-    introduction to sun2 special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Sun2
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    sun2/autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), cd(4),
-    sd(4), ss(4), st(4),
-    sun2/autoconf(4)

-

-

-

-
The following Sun2 system architectures and models are
-  supported:

-

-  
sun2

-  
Sun2 systems: (MC68010)
-    

-    Sun 2/120, 2/170 (10 MHz)

-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-  
bwtwo

-  
black and white obio frame buffer

-  
ie

-  
Intel 82586 Ethernet controller (Sun 2/120, 2/170)

-  
ec

-  
3Com 3c400 Multibus Ethernet controller (Sun 2/120, 2/170)

-  
kbd

-  
Sun type 2, type 3, type 4, and type 5 keyboards (on zstty)

-  
ms

-  
Sun mouse (on zstty)

-  
sc

-  
Sun "SCSI-2" Multibus SCSI controller

-  
zs

-  
Zilog 8530 serial controller

-

-

-

-

-
This sun2 intro appeared in
-    NetBSD 1.6. Large chunks of text carefully recycled
-    (shamelessly appropriated) from NetBSD/sun3
-    sun2/intro(4).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/kbd.4 3.html b/static/netbsd/man4/man4.sun2/kbd.4 3.html
deleted file mode 100644
index 806a1af9..00000000
--- a/static/netbsd/man4/man4.sun2/kbd.4 3.html	
+++ /dev/null
@@ -1,126 +0,0 @@
-
-  
-    
-    
-    
-  
-
KBD(4)Device Drivers Manual (sun2)KBD(4)

-

-

-

-
kbd — Sun
-    workstation keyboard

-

-

-

-
kbd0 at zstty?

-

-

-

-
The kbd driver provides an interface to
-    the workstation console keyboard. "type 2", "type 3",
-    "type 4", and "type 5" keyboards are supported. The
-    "type 5" keyboard is treated as if it were a "type 4".
-    All types generate keycodes encoding the key identity and motion (up or
-    down) as the keys are pressed and released. The kbd
-    driver either passes the keycodes to an application as they come in, or
-    translates them into ASCII characters first according to a set of built-in
-    tables.

-
If the keyboard is configured as the device to be used for system
-    console input, it will be internally connected to the
-    /dev/console device special file, which can be used
-    as a tty(4) device.

-
The device special file /dev/kbd is used
-    to get direct access to the keyboard input stream. The following ioctl's are
-    supported (mostly just enough to keep the X server
-    going):

-

-  
KIOCTRANS

-  
Set translation mode. The argument is of type int *,
-      the only value supported is TR_UNTRANS_EVENT.

-  
KIOCGTRANS

-  
Get translation mode. The argument is of type int *.
-      TR_UNTRANS_EVENT is always returned.

-  
KIOCGETKEY

-  
Fill in old-style key station translation. The argument is of type
-      struct okiockey *.

-  
KIOCCMD

-  
Send a command to the keyboard. The argument is of type
-      int *, and can have one of the following values:
-    

-      
KBD_CMD_BELL

-      
Start the keyboard beeper.

-      
KBD_CMD_NOBELL

-      
Stop the keyboard beeper.

-      
KBD_CMD_CLICK

-      
Instruct the keyboard to make extra noise when touching keys.

-      
KBD_CMD_NOCLICK

-      
Instruct the keyboard to stop making extra noise when touching
-        keys.

-    

-  

-  
KIOCTYPE

-  
Get keyboard type. The argument is of type int *, in
-      which one of the values KB_SUN2,
-      KB_SUN3 or KB_SUN4 will be
-      returned.

-  
KIOCSDIRECT

-  
Route the keyboard input stream through the SunOS compatible event module.
-      The argument is of type int *, a non-zero value will
-      put the driver into “event” mode, while a value of zero will
-      make it return to “ASCII translation” mode.

-  
KIOCSKEY

-  
Set key station translation. The argument is of type
-      struct kiockey * (see
-      /usr/include/machine/kbio.h for
-      more details).

-  
KIOCGKEY

-  
Get key station translation. The argument is of type
-      struct kiockey *.

-  
KIOCLAYOUT

-  
Get keyboard layout (“type 4” only). The argument is of type
-      int *, in which the uninterpreted result of the
-      KBD_CMD_GLAYOUT keyboard command is returned (on
-      KBDUN4 type keyboards this will be the setting of
-      a DIP switch bank).

-  
KIOCSLED

-  
Set LED state (“type 4” only). The argument is of type
-      char *, and is the inclusive OR of the following
-      flags:
-    

-    

-      
LED_NUM_LOCK

-      
 

-      
LED_COMPOSE

-      
 

-      
LED_SCROLL_LOCK

-      
 

-      
LED_CAPS_LOCK

-      
 

-    

-    
Each of these flags turn on the LED in the obvious key.

-  

-  
KIOCGLED

-  
Get LED state (“type 4” only). The argument is of type
-      char *, in which the current LED state is
-    returned.

-

-

-

-

-
sun2/ms(4)

-

-

-

-
kbd is hardwired to the built-in
-     serial
-    port at 1200 bps.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/leds.4 3.html b/static/netbsd/man4/man4.sun2/leds.4 3.html
deleted file mode 100644
index 34c499d1..00000000
--- a/static/netbsd/man4/man4.sun2/leds.4 3.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
LEDS(4)Device Drivers Manual (sun2)LEDS(4)

-

-

-

-
leds — sun2
-    diagnostic Light Emitting Diodes driver

-

-

-

-
#include
-    <machine/leds.h>

-

-

-

-
All sun2 machines are equipped a diagnostic display of eight Light
-    Emitting Diodes (LEDs), located on either the front (deskside chassis) or
-    the back (desktop machine) of the system unit.

-
The kernel changes the display during periods of idle processor
-    activity according to a stored sequential pattern list. The
-    /dev/leds interface provides a way of manipulating
-    the pattern list via simple file I/O.

-
The structure of the file is as follows:

-

-
struct led_patterns {
-        u_char divisor;
-        u_char patlen;
-        u_char pat[256];
-};

-

-

-  

-  
The number of idle periods to wait before switching to the next pattern in
-      the array.

-  

-  
The number of patterns stored in the array.

-  

-  
The array of patterns to display.

-

-
When a clock interrupt occurs while the processor is idle, a
-    pattern countdown timer is decremented. When the countdown timer reaches
-    zero it is reset with the divisor value and the next
-    pattern in the array is selected and displayed.

-
Each 8-bit pattern describes the state of the diagnostic LEDs. A
-    set bit in a pattern indicates that its corresponding LED should be
-    extinguished, while a reset bit indicates an LED to be illuminated.

-

-

-

-

-  
/dev/leds

-  
 

-

-

-

-

-
The following example uses awk(1) to display the
-    repeating animation of a single lit LED scrolling from one end of the
-    display to the other, using six clock ticks between each update.

-
# echo 5 8 254 253 251 247 239 223 191 127 |
-

- awk '{ for (i=1;i<=NF;i++) printf("%c",$i+0); }' >
-  /dev/leds

-

-

-

-
An I/O transfer to /dev/leds will complete
-    successfully unless:

-

-  
[]

-  
A read or write starting beyond the end of the file was attempted.

-

-

-

-

-
ppt(6)

-

-

-

-
/dev/leds first appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
March 2, 1996NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/mem.4 4.html b/static/netbsd/man4/man4.sun2/mem.4 4.html
deleted file mode 100644
index f6ec5412..00000000
--- a/static/netbsd/man4/man4.sun2/mem.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (sun2)MEM(4)

-

-

-

-
mem, kmem —
-    main memory

-

-

-

-
The file /dev/mem is an interface to the
-    physical memory of the computer. Byte offsets in this file are interpreted
-    as physical memory addresses. Reading and writing this file is equivalent to
-    reading and writing memory itself. An error will be returned if an attempt
-    is made to reference an offset outside of
-  /dev/mem.

-
Kernel virtual memory is accessed via the file
-    /dev/kmem in the same manner as
-    /dev/mem. Only kernel virtual addresses that are
-    currently mapped to memory are allowed.

-
On the Sun2, kernel virtual memory begins at
-    0x000000.

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-

-

-

-

-
The files mem and
-    kmem appeared in Version 6
-    AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun2/ms.4 4.html b/static/netbsd/man4/man4.sun2/ms.4 4.html
deleted file mode 100644
index 94d5733e..00000000
--- a/static/netbsd/man4/man4.sun2/ms.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
MS(4)Device Drivers Manual (sun2)MS(4)

-

-

-

-
ms — Sun
-    workstation mouse driver

-

-

-

-
ms0 at zstty?

-

-

-

-
The ms driver provides an interface to the
-    workstation console mouse. This Mouse Systems three-button device produces
-    five-byte blobs of the form:

-

-
b dx dy dx dy

-

-
where “b” is the button state, encoded as
-    0x80|(~buttons) -- there are three buttons (4=left,
-    2=middle, 1=right) -- and “dx” and “dy” are X
-    and Y delta values, none of which are in the range
-    [0x80..0x87].

-
The device special file /dev/mouse is used
-    to get direct access to the mouse input stream. The following ioctl's are
-    supported (mostly just enough to keep the X server
-    going):

-

-  

-  
Set translation mode. The argument is of type int *,
-      the only value supported is VUID_FIRM_EVENT.

-  

-  
Get translation mode. The argument is of type int *.
-      VUID_FIRM_EVENT is always returned.

-

-

-

-
The mouse driver can be configured using the following kernel
-    configuration file options.

-

-  
options SUN_MS_BPS=integer

-  
This option causes the kernel to communicate with the mouse using the
-      serial baud rate integer. It is useful for mice
-      which do not communicate at 1200 baud.

-

-

-

-

-

-
sun2/kbd(4)

-

-

-

-
ms is hardwired to the built-in
-     serial
-    port.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/autoconf.4 4.html b/static/netbsd/man4/man4.sun3/autoconf.4 4.html
deleted file mode 100644
index 64f33f12..00000000
--- a/static/netbsd/man4/man4.sun3/autoconf.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (sun3)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel. Devices which
-    exist in the machine but are not configured into the kernel are not
-    detected.

-

-

-

-

-  
CPU class not configured.

-  
You tried to boot NetBSD on a class of CPU type
-      which it doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-

-

-

-

-
config(1), sun3/intro(4),
-    boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/bwtwo.4 4.html b/static/netbsd/man4/man4.sun3/bwtwo.4 4.html
deleted file mode 100644
index 6a8950d5..00000000
--- a/static/netbsd/man4/man4.sun3/bwtwo.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
BWTWO(4)Device Drivers Manual (sun3)BWTWO(4)

-

-

-

-
bwtwo — Sun
-    monochromatic frame buffer

-

-

-

-
bwtwo0 at obmem0 addr ?

-

-

-

-
The bwtwo is a memory based black and
-    white frame buffer. It supports the minimal ioctl's needed to run
-    X.

-

-

-

-
sun3/cgfour(4),
-  sun3/cgtwo(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/cgfour.4 4.html b/static/netbsd/man4/man4.sun3/cgfour.4 4.html
deleted file mode 100644
index 28bd69e4..00000000
--- a/static/netbsd/man4/man4.sun3/cgfour.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGFOUR(4)Device Drivers Manual (sun3)CGFOUR(4)

-

-

-

-
cgfour — Sun 8-bit
-    color frame buffer

-

-

-

-
cgfour0 at obmem0 addr ?

-

-

-

-
The cgfour is a memory based color frame
-    buffer. It supports the minimal ioctl's needed to run
-    X.

-

-

-

-
sun3/bwtwo(4),
-  sun3/cgtwo(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/cgtwo.4 4.html b/static/netbsd/man4/man4.sun3/cgtwo.4 4.html
deleted file mode 100644
index 0dcc8419..00000000
--- a/static/netbsd/man4/man4.sun3/cgtwo.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
CGTWO(4)Device Drivers Manual (sun3)CGTWO(4)

-

-

-

-
cgtwo — Sun 8-bit
-    VME bus color frame buffer

-

-

-

-
cgtwo0 at vme2 addr 0x400000 ipl 4 vect
-    0xA8

-

-

-

-
The cgtwo is a memory based, VME bus,
-    color frame buffer. It supports the minimal ioctl's needed to run
-    X.

-

-

-

-
sun3/bwtwo(4),
-  sun3/cgfour(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/fd.4 4.html b/static/netbsd/man4/man4.sun3/fd.4 4.html
deleted file mode 100644
index 7b2645a3..00000000
--- a/static/netbsd/man4/man4.sun3/fd.4 4.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
FD(4)Device Drivers Manual (sun3)FD(4)

-

-

-

-
fd — Sun 3/80
-    i82027 floppy disk drive controller driver

-

-

-

-
fdc0 at obio0 (sun3x)
-  

-  fd* at fdc0

-

-

-

-
The fd driver is for the built-in floppy
-    diskette drive run by the Intel i82027 controller found on the Sun 3/80.

-
Bits [0-3] of the minor device number of the special files
-    referring to this device encode the floppy density as follows:

-

-

-  
0

-  
3.5'' 1.44MB floppy diskettes.

-  
1

-  
3.5'' 720KB floppy diskettes.

-  
2

-  
3.5'' 360KB floppy diskettes.

-  
3

-  
3.5'' 1.2MB/NEC Japanese format floppy diskettes.

-

-

-

-

-

-
The driver supports floppy disk formatting using the interfaces in
-    <sys/fdio.h>:

-

-

-  

-    struct fdformat_parms

-  
Fetch current formatting parameters. This gets the default parameters for
-      the open device if no parameters have been set during the session.
-    

-  

-  

-    struct fdformat_parms

-  
Set formatting parameters. The driver saves this state and it persists
-      while the device is open.
-    

-  

-  

-    struct fdformat_cmd

-  
Format a track on the medium. If this call returns
-      EINVAL, the track formatting parameters were out
-      of range for the medium. If it returns EIO, there
-      was a medium error while formatting the track.
-    

-  

-  

-    int

-  
Set driver options which persist until the device is closed. The options
-      should be the logical OR of the desired values below:
-    

-    

-      

-      
Do not retry operations on failure

-      

-      
Do not print error messages to the console

-    

-    

-  

-  

-    int

-  
Fetch drive options.

-

-
A typical use of the formatting facilities would be to open the
-    device, call FDIOCGETFORMAT to fetch the current
-    format parameters, perhaps change a parameter or two, display the formatting
-    details to the user, and then call FDIOCSETFORMAT
-    followed by a series of calls to
-  FDIOCFORMAT_TRACK.

-

-

-

-
eject(1), fdformat(1)

-

-

-

-
The fd formatting support appeared in
-    NetBSD 1.3.

-

-

-

-
Formatting appears to not work reliably on all machines.

-

-

-
-  
-    
-    
-  
-
June 23, 1996NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/ie.4 4.html b/static/netbsd/man4/man4.sun3/ie.4 4.html
deleted file mode 100644
index 7364b1ea..00000000
--- a/static/netbsd/man4/man4.sun3/ie.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
IE(4)Device Drivers Manual (sun3)IE(4)

-

-

-

-
ie — Intel 82586
-    Ethernet interface driver

-

-

-

-
ie0 at obio0 addr 0x0C0000 ipl 3
-  

-  ie1 at vme2 addr 0xe88000 ipl 3 vect 0x75
-  

-  ie* at sebuf?

-

-

-

-
The ie interface provides access to the 10
-    Mb/s Ethernet network via the Intel 82586 Ethernet chip set.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ie interface employs the Address Resolution Protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-
arp(4), inet(4),
-    le(4), sun3/intro(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/intro.4 4.html b/static/netbsd/man4/man4.sun3/intro.4 4.html
deleted file mode 100644
index de9c298a..00000000
--- a/static/netbsd/man4/man4.sun3/intro.4 4.html	
+++ /dev/null
@@ -1,147 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (sun3)INTRO(4)

-

-

-

-
intro —
-    introduction to sun3 special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the Sun3
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system must be rebooted.

-
The autoconfiguration system is described in
-    sun3/autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), cd(4),
-    sd(4), ss(4), st(4),
-    sun3/autoconf(4)

-

-

-

-
The following Sun3 system architectures and models are
-  supported:

-

-  
sun3

-  
Sun3 systems: (MC68020)
-    

-    Sun 3/50 (16 MHz)
-    

-    Sun 3/60 (20 MHz)
-    

-    Sun 3/100 series (16.67 MHz)
-    

-    Sun 3/200 series (25 MHz)

-  
sun3x

-  
Sun3X systems: (MC68030)
-    

-    Sun 3/80 (20 MHz)
-    

-    Sun 3/470 (33 MHz)

-

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-  
bwtwo

-  
black and white obio frame buffer

-  
cgtwo

-  
8 bit VMEbus color frame buffer

-  
cgfour

-  
8 bit obio color graphics frame buffer

-  
eeprom

-  
Sun non-volatile configuration RAM driver

-  
esp

-  
NCR53C90 ESP100 (Sun 3/80) SCSI controller

-  
fd

-  
Intel 82072 obio (Sun 3/80) floppy disk drive controller

-  
ie

-  
Intel 82586 Ethernet controller (Sun 3/100, 3/200, 3/470)

-  
kbd

-  
Sun type 2, type 3, type 4, and type 5 keyboards (on zs)

-  
le/lebuffer

-  
AMD 7990 LANCE Ethernet controller (Sun 3/50, 3/60, 3/80)

-  
ms

-  
Sun mouse (on zs)

-  
si

-  
NCR5380 "SCSI-3" VMEbus SCSI controller

-  
vme

-  
VMEbus support (Sun 3/100, 3/200, 3/470)

-  
xd

-  
Xylogics 753/7053 VMEbus SMD disk controller

-  
xy

-  
Xylogics 450/451 VMEbus SMD disk controller

-  
zs

-  
Zilog 8530 serial controller

-

-

-

-

-
The following devices are not supported, due to unavailability of
-    either documentation or sample hardware:

-

-  
sc

-  
Sun "SCSI-2" VMEbus SCSI controller

-

-

-

-

-
This sun3 intro appeared in
-    NetBSD 1.3. Large chunks of text carefully recycled
-    (shamelessly appropriated) from NetBSD/pmax
-    sun3/intro(4).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/kbd.4 3.html b/static/netbsd/man4/man4.sun3/kbd.4 3.html
deleted file mode 100644
index 7ed91207..00000000
--- a/static/netbsd/man4/man4.sun3/kbd.4 3.html	
+++ /dev/null
@@ -1,127 +0,0 @@
-
-  
-    
-    
-    
-  
-
KBD(4)Device Drivers Manual (sun3)KBD(4)

-

-

-

-
kbd — Sun
-    workstation keyboard

-

-

-

-
pseudo-device kbd

-

-

-

-
The kbd driver provides an interface to
-    the workstation console keyboard. "type 2", "type 3",
-    "type 4", and "type 5" keyboards are supported. The
-    "type 5" keyboard is treated as if it were a "type 4".
-    All types generate keycodes encoding the key identity and motion (up or
-    down) as the keys are pressed and released. The kbd
-    driver either passes the keycodes to an application as they come in, or
-    translates them into ASCII characters first according to a set of built-in
-    tables.

-
If the keyboard is configured as the device to be used for system
-    console input (see eeprom(8)), it will be internally
-    connected to the /dev/console device special file,
-    which can be used as a tty(4) device.

-
The device special file /dev/kbd is used
-    to get direct access to the keyboard input stream. The following ioctl's are
-    supported (mostly just enough to keep the X server
-    going):

-

-  
KIOCTRANS

-  
Set translation mode. The argument is of type int *,
-      the only value supported is TR_UNTRANS_EVENT.

-  
KIOCGTRANS

-  
Get translation mode. The argument is of type int *.
-      TR_UNTRANS_EVENT is always returned.

-  
KIOCGETKEY

-  
Fill in old-style key station translation. The argument is of type
-      struct okiockey *.

-  
KIOCCMD

-  
Send a command to the keyboard. The argument is of type
-      int *, and can have one of the following values:
-    

-      
KBD_CMD_BELL

-      
Start the keyboard beeper.

-      
KBD_CMD_NOBELL

-      
Stop the keyboard beeper.

-      
KBD_CMD_CLICK

-      
Instruct the keyboard to make extra noise when touching keys.

-      
KBD_CMD_NOCLICK

-      
Instruct the keyboard to stop making extra noise when touching
-        keys.

-    

-  

-  
KIOCTYPE

-  
Get keyboard type. The argument is of type int *, in
-      which one of the values KB_SUN2,
-      KB_SUN3 or KB_SUN4 will be
-      returned.

-  
KIOCSDIRECT

-  
Route the keyboard input stream through the SunOS compatible event module.
-      The argument is of type int *, a non-zero value will
-      put the driver into “event” mode, while a value of zero will
-      make it return to “ASCII translation” mode.

-  
KIOCSKEY

-  
Set key station translation. The argument is of type
-      struct kiockey * (see
-      /usr/include/machine/kbio.h for
-      more details).

-  
KIOCGKEY

-  
Get key station translation. The argument is of type
-      struct kiockey *.

-  
KIOCLAYOUT

-  
Get keyboard layout (“type 4” only). The argument is of type
-      int *, in which the uninterpreted result of the
-      KBD_CMD_GLAYOUT keyboard command is returned (on
-      KBDUN4 type keyboards this will be the setting of
-      a DIP switch bank).

-  
KIOCSLED

-  
Set LED state (“type 4” only). The argument is of type
-      char *, and is the inclusive OR of the following
-      flags:
-    

-    

-      
LED_NUM_LOCK

-      
 

-      
LED_COMPOSE

-      
 

-      
LED_SCROLL_LOCK

-      
 

-      
LED_CAPS_LOCK

-      
 

-    

-    
Each of these flags turn on the LED in the obvious key.

-  

-  
KIOCGLED

-  
Get LED state (“type 4” only). The argument is of type
-      char *, in which the current LED state is
-    returned.

-

-

-

-

-
eeprom(4), sun3/ms(4),
-    eeprom(8)

-

-

-

-
kbd is hardwired to the built-in
-     serial
-    port at 1200 bps.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/leds.4 4.html b/static/netbsd/man4/man4.sun3/leds.4 4.html
deleted file mode 100644
index 73cf4850..00000000
--- a/static/netbsd/man4/man4.sun3/leds.4 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
LEDS(4)Device Drivers Manual (sun3)LEDS(4)

-

-

-

-
leds — sun3
-    diagnostic Light Emitting Diodes driver

-

-

-

-
#include
-    <machine/leds.h>

-

-

-

-
With the exception of the Sun 3/80, all sun3 machines are equipped
-    a diagnostic display of eight Light Emitting Diodes (LEDs), located on the
-    back of the system unit. The Sun 3/80 has a single LED, which is located on
-    the front panel.

-
The kernel changes the display during periods of idle processor
-    activity according to a stored sequential pattern list. The
-    /dev/leds interface provides a way of manipulating
-    the pattern list via simple file I/O.

-
The structure of the file is as follows:

-

-
struct led_patterns {
-        u_char divisor;
-        u_char patlen;
-        u_char pat[256];
-};

-

-

-  

-  
The number of idle periods to wait before switching to the next pattern in
-      the array.

-  

-  
The number of patterns stored in the array.

-  

-  
The array of patterns to display.

-

-
When a clock interrupt occurs while the processor is idle, a
-    pattern countdown timer is decremented. When the countdown timer reaches
-    zero it is reset with the divisor value and the next
-    pattern in the array is selected and displayed.

-
Each 8-bit pattern describes the state of the diagnostic LEDs.
-    With the exception of the 3/80, a set bit in a pattern indicates that its
-    corresponding LED should be extinguished, while a reset bit indicates an LED
-    to be illuminated. On the 3/80 the polarity of the bits is reversed and only
-    the lowest order bit is used.

-

-

-

-

-  
/dev/leds

-  
 

-

-

-

-

-
The following example uses awk(1) to display the
-    repeating animation of a single lit LED scrolling from one end of the
-    display to the other, using six clock ticks between each update.

-
# echo 5 8 254 253 251 247 239 223 191 127 |
-

- awk '{ for (i=1;i<=NF;i++) printf("%c",$i+0); }' >
-  /dev/leds

-

-

-

-
An I/O transfer to /dev/leds will complete
-    successfully unless:

-

-  
[]

-  
A read or write starting beyond the end of the file was attempted.

-

-

-

-

-
ppt(6)

-

-

-

-
/dev/leds first appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
March 2, 1996NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/mem.4 4.html b/static/netbsd/man4/man4.sun3/mem.4 4.html
deleted file mode 100644
index 96761878..00000000
--- a/static/netbsd/man4/man4.sun3/mem.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (sun3)MEM(4)

-

-

-

-
mem, kmem —
-    main memory

-

-

-

-
The file /dev/mem is an interface to the
-    physical memory of the computer. Byte offsets in this file are interpreted
-    as physical memory addresses. Reading and writing this file is equivalent to
-    reading and writing memory itself. An error will be returned if an attempt
-    is made to reference an offset outside of
-  /dev/mem.

-
Kernel virtual memory is accessed via the file
-    /dev/kmem in the same manner as
-    /dev/mem. Only kernel virtual addresses that are
-    currently mapped to memory are allowed.

-
On the Sun3, kernel virtual memory begins at
-    0x0E000000.

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-

-

-

-

-
The files mem and
-    kmem appeared in Version 6
-    AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.sun3/ms.4 4.html b/static/netbsd/man4/man4.sun3/ms.4 4.html
deleted file mode 100644
index 6d6be4d4..00000000
--- a/static/netbsd/man4/man4.sun3/ms.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
MS(4)Device Drivers Manual (sun3)MS(4)

-

-

-

-
ms — Sun
-    workstation mouse driver

-

-

-

-
pseudo-device mouse

-

-

-

-
The ms driver provides an interface to the
-    workstation console mouse. This Mouse Systems three-button device produces
-    five-byte blobs of the form:

-

-
b dx dy dx dy

-

-
where “b” is the button state, encoded as
-    0x80|(~buttons) -- there are three buttons (4=left,
-    2=middle, 1=right) -- and “dx” and “dy” are X
-    and Y delta values, none of which are in the range
-    [0x80..0x87].

-
The device special file /dev/mouse is used
-    to get direct access to the mouse input stream. The following ioctl's are
-    supported (mostly just enough to keep the X server
-    going):

-

-  

-  
Set translation mode. The argument is of type int *,
-      the only value supported is VUID_FIRM_EVENT.

-  

-  
Get translation mode. The argument is of type int *.
-      VUID_FIRM_EVENT is always returned.

-

-

-

-
The mouse driver can be configured using the following kernel
-    configuration file options.

-

-  
options SUN_MS_BPS=integer

-  
This option causes the kernel to communicate with the mouse using the
-      serial baud rate integer. It is useful for mice
-      which do not communicate at 1200 baud.

-

-

-

-

-

-
sun3/kbd(4)

-

-

-

-
ms is hardwired to the built-in
-     serial
-    port.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/acc.4 4.html b/static/netbsd/man4/man4.vax/acc.4 4.html
deleted file mode 100644
index 4f84beaa..00000000
--- a/static/netbsd/man4/man4.vax/acc.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACC(4)Device Drivers Manual (vax)ACC(4)

-

-

-

-
acc — ACC LH/DH
-    IMP network interface

-

-

-

-
pseudo-device imp acc0 at uba0 csr 167600 vector
-    accrint accxint

-

-

-

-
NOTE: At the moment NetBSD does not
-    support IMP, so this manual page is not relevant.

-
The acc device provides
-    a Local Host/Distant Host interface to an IMP. It is normally used when
-    participating in the DARPA Internet. The controller itself is not accessible
-    to users, but instead provides the hardware support to the IMP interface
-    described in imp(4). The configuration entry for the
-    imp(4) must also include the
-    
-    as shown above.

-

-

-

-

-  
acc%d: not alive.

-  
The initialization routine was entered even though the device did not
-      autoconfigure. This indicates a system problem.

-  
acc%d: can't initialize.

-  
Insufficient UNIBUS resources existed to initialize the device. This is
-      likely to occur when the device is run on a buffered data path on an
-      11/750 and other network interfaces are also configured to use buffered
-      data paths, or when it is configured to use buffered data paths on an
-      11/730 (which has none).

-  
acc%d: imp doesn't respond, icsr=%b.

-  
The driver attempted to initialize the device, but the IMP failed to
-      respond after 500 tries. Check the cabling.

-  
acc%d: stray xmit interrupt, csr=%b.

-  
An interrupt occurred when no output had previously been started.

-  
acc%d: output error, ocsr=%b, icsr=%b.

-  
The device indicated a problem sending data on output.

-  
acc%d: input error, csr=%b.

-  
The device indicated a problem receiving data on input.

-  
acc%d: bad length=%d.

-  
An input operation resulted in a data transfer of less than 0 or more than
-      1008 bytes of data into memory (according to the word count register).
-      This should never happen as the maximum size of a host-IMP message is 1008
-      bytes.

-

-

-

-

-
netintro(4)

-

-

-

-
The acc interface appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ad.4 4.html b/static/netbsd/man4/man4.vax/ad.4 4.html
deleted file mode 100644
index fd7a55e5..00000000
--- a/static/netbsd/man4/man4.vax/ad.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
AD(4)Device Drivers Manual (vax)AD(4)

-

-

-

-
ad — Data
-    Translation A/D converter

-

-

-

-
ad0 at uba0 csr 0170400 vector adintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ad driver provides an
-    interface to the Data Translation A/D converter. This is
-     a real-time
-    driver, but merely allows the user process to sample the board's channels
-    one at a time. Each minor device selects a different A/D board.

-
The driver communicates to a user process by means of
-    ioctl(2)s. The AD_CHAN
-    ioctl(2) selects which channel of the board to read. For
-    example,

-

-
chan = 5;
-ioctl(fd, AD_CHAN, &chan);

-

-
selects channel 5. The AD_READ
-    ioctl(2) actually reads the data and returns it to the
-    user process. An example is

-

-
ioctl(fd, AD_READ, &data);

-

-

-

-

-

-  
/dev/ad

-  
 

-

-

-

-

-
None.

-

-

-

-
The ad driver appeared in
-    4.1BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/asc.4 4.html b/static/netbsd/man4/man4.vax/asc.4 4.html
deleted file mode 100644
index 45a10e71..00000000
--- a/static/netbsd/man4/man4.vax/asc.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
ASC(4)Device Drivers Manual (vax)ASC(4)

-

-

-

-
asc — VAXstation
-    4000 SCSI controller

-

-

-

-
asc* at vsbus? csr 0x200c0080 (VS-4000/60
-    or VLC)
-  

-  asc* at vsbus? csr 0x25000080 (VS-4000/9x)
-  

-  asc* at tc? (Not yet supported)
-  

-  scsibus* at asc?

-

-

-

-
The asc driver provides support for the
-    NCR 53c94-based SCSI host adapter on the VAXstation 4000 series, and for the
-    PMAZ-AA and related TURBOchannel SCSI adapter option boards (also on the
-    VAXstation 4000 series models which include support for the TURBOchannel
-    adapter).

-

-

-

-
The asc driver supports the following
-    
-    for use in config(1) files:

-

-

-  
bits 0-7:

-  
disable disconnect/reselect for the corresponding SCSI target

-  
bits 8-15:

-  
disable synchronous negotiation for SCSI target

-

-
"Target" is synonymous with SCSI ID number.

-
Note that SCSI tape drives should be allowed to perform
-    disconnect/reselect or performance will suffer.

-

-

-

-
cd(4), ch(4),
-    esp(4), scsi(4),
-    sd(4), st(4),
-    vax/intro(4)

-

-

-

-
The asc driver first appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/autoconf.4 3.html b/static/netbsd/man4/man4.vax/autoconf.4 3.html
deleted file mode 100644
index ad3d0792..00000000
--- a/static/netbsd/man4/man4.vax/autoconf.4 3.html	
+++ /dev/null
@@ -1,136 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (vax)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices. Each item found is recorded on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel.

-
On the VAX, devices in NEXUS slots are normally noted, thus memory
-    controllers, UNIBUS and MASSBUS adaptors. Devices which are not supported
-    which are found in NEXUS slots are noted also. The Q-bus on the MICROVAX is
-    configured in the same way as the UNIBUS.

-
MASSBUS devices are located by a very deterministic procedure
-    since MASSBUS space is completely probe-able. If devices exist which are not
-    configured they will be silently ignored; if devices exist of unsupported
-    type they will be noted.

-
UNIBUS devices are located by probing to see if their
-    control-status registers respond. If not, they are silently ignored. If the
-    control status register responds but the device cannot be made to interrupt,
-    a diagnostic warning will be printed on the console and the device will not
-    be available to the system.

-
Normally, the system uses the disk from which it was loaded as the
-    root filesystem. If that is not possible, a generic system will pick its
-    root device as the “best” available device (MASSBUS disks are
-    better than SMD UNIBUS disks are better than RK07s; the device must be drive
-    0 to be considered). If such a system is booted with the
-    RB_ASKNAME option (see reboot(2)),
-    then the name of the root device is read from the console terminal at boot
-    time, and any available device may be used.

-

-

-

-

-  
cpu type %d not configured.

-  
You tried to boot NetBSD on a CPU type which it
-      doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-  
mba%d at tr%d.

-  
A MASSBUS adapter was found in
-      ‘tr%d’ (the NEXUS slot number).
-      NetBSD will call it
-      ‘mba%d’.

-  
%d mba's not configured.

-  
More MASSBUS adapters were found on the machine than were declared in the
-      machine configuration; the excess MASSBUS adapters will not be
-    accessible.

-  
uba%d at tr%d.

-  
A UNIBUS adapter was found in ‘tr%d’
-      (the NEXUS slot number). NetBSD will call it
-      ‘uba%d’.

-  
dr32 unsupported (at tr %d).

-  
A DR32 interface was found in a NEXUS, for which
-      NetBSD does not have a driver.

-  
ci unsupported (at tr %d).

-  
A CI interface was found in a NEXUS, for which
-      NetBSD does not have a driver.

-  
mcr%d at tr%d.

-  
A memory controller was found in
-      ‘tr%d’ (the NEXUS slot number).
-      NetBSD will call it
-      ‘mcr%d’.

-  
5 mcr's unsupported.

-  
NetBSD supports only 4 memory controllers per
-    CPU.

-  
mpm unsupported (at tr%d).

-  
Multi-port memory is unsupported in the sense that
-      NetBSD does not know how to poll it for ECC
-      errors.

-  
%s%d at mba%d drive %d.

-  
A tape formatter or a disk was found on the MASSBUS; for disks
-      ‘%s%d’ will look like
-      “hp0”, for tape formatters like
-      “ht1”. The drive number comes from
-      the unit plug on the drive or in the TM formatter
-      ( on the tape
-      drive; see below).

-  
%s%d at %s%d slave %d.

-  
(For MASSBUS devices). Which would look like “tu0
-      at ht0 slave 0”, where
-      “tu0” is the name for the tape
-      device and “ht0” is the name for the
-      formatter. A tape slave was found on the tape formatter at the indicated
-      drive number (on the front of the tape drive).
-      UNIX will call the device, e.g.,
-      “tu0”.

-  
%s%d at uba%d csr %o vec %o ipl %x.

-  
The device ‘%s%d’, e.g.
-      “dz0” was found on
-      ‘uba%d’ at control-status register
-      address ‘%o’ and with device vector
-      ‘%o’. The device interrupted at
-      priority level ‘%x’.

-  
%s%d at uba%d csr %o zero vector.

-  
The device did not present a valid interrupt vector, rather presented 0 (a
-      passive release condition) to the adapter.

-  
%s%d at uba%d csr %o didn't interrupt.

-  
The device did not interrupt, likely because it is broken, hung, or not
-      the kind of device it is advertised to be.

-  
%s%d at %s%d slave %d.

-  
(For UNIBUS devices). Which would look like “up0
-      at sc0 slave 0”, where
-      “up0” is the name of a disk drive
-      and “sc0” is the name of the
-      controller. Analogous to MASSBUS case.

-

-

-

-

-
config(1), vax/intro(4),
-    boot(8)

-

-

-

-
The autoconf feature appeared in
-    4.1BSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/cons.4 4.html b/static/netbsd/man4/man4.vax/cons.4 4.html
deleted file mode 100644
index 3a002e84..00000000
--- a/static/netbsd/man4/man4.vax/cons.4 4.html	
+++ /dev/null
@@ -1,134 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONS(4)Device Drivers Manual (vax)CONS(4)

-

-

-

-
cons — VAX-11
-    console interface

-

-

-

-
The console is available to the processor through the console
-    registers. It acts like a normal terminal, except that when the local
-    functions are not disabled, ^P (control-P) puts the
-    console in local console mode (where the prompt is
-    ‘>>>’). The operation of the
-    console in this mode varies slightly per-processor.

-

-

-
On either the VAX-11/780 or 785 the following commands may be used
-    after placing the console in local mode with ^P.

-

-

-

-  

-  
 

-  

-  
Re-enter conversational mode if the processor was halted.
-    

-  

-  

-  
 

-  

-  
Halt the CPU. On an 11/780 or 785 the processor is not stopped by entering
-      local console mode.
-    

-  

-  

-  
(set terminal program) Re-enter conversational mode if the processor is
-      still running.
-    

-  

-  

-  
(proceed) Get out of ODT mode.
-    

-  

-  

-  
If you hit the break key on the console, then the console LSI-11 will go
-      into ODT (console debugger mode).

-

-

-

-

-

-
On an 11/750 or an 11/730 the processor is halted whenever the
-    console is not in conversational mode.

-

-

-

-  

-  
Return to conversational mode.
-    

-  

-  

-  
Return from remote diagnosis mode to local console mode.
-    

-  

-  

-  
(11/750 only) When in console mode on an 11/750 which has a remote
-      diagnosis module, a ^D will put you in remote
-      diagnosis mode, where the prompt will be
-      ‘RDM>’.

-

-

-

-

-

-
The VAX-8600 (8650) console normally works in the same way as the
-    11/750, except that there are many additional modes and commands.

-

-

-

-  

-  
 

-  

-  
Return to conversational mode.
-    

-  

-  

-  
Halt the processor if HEX debug enabled.
-    

-  

-  

-  
Halt the processor if in normal mode.

-

-

-
With the above proviso's the console works like any other
-    UNIX terminal.

-

-

-

-

-

-  
/dev/console

-  
 

-

-

-

-

-
tty(4), reboot(8)

-
VAX Hardware
-    Handbook.

-

-

-

-
The cons interface appeared in
-    4.0BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/covid.4 3.html b/static/netbsd/man4/man4.vax/covid.4 3.html
deleted file mode 100644
index 01bd4869..00000000
--- a/static/netbsd/man4/man4.vax/covid.4 3.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
COVID(4)Device Drivers Manual (vax)COVID(4)

-

-

-

-
covid —
-    coronavirus disease caused by SARS-CoV-2

-

-

-

-
covid19 at sarscov2 b11 7
-  

-  covid19 at sarscov2 b11 207
-  

-  covid19 at sarscov2 b11 351
-  

-  covid19 at sarscov2 b11 427
-  

-  covid19 at sarscov2 b11 429
-  

-  covid19 at sarscov2 b11 525
-  

-  covid19 at sarscov2 p 1

-

-

-

-
The covid family of diseases, attached to
-    humanity via a spike protein bus in the year 2019 as
-    covid19, is a contagious respiratory and
-    neurological disease caused by the coronavirus SARS-CoV-2.

-
covid is spread human-to-human mainly
-    through small droplets and aerosols, especially in crowds, closed spaces,
-    and close contact. Some approaches to mitigate transmission:

-
    
-  
  • Good ventilation with fresh air, and high-efficiency particulate air
-      filtration (HEPA), can mitigate accumulation of aerosols in indoor
-      settings, for activities that can't be moved outdoors.
    • 
-  
  • Widespread use of paper or cloth facial masks covering mouth and nose is
-      an effective population-wide mitigation reducing dispersal of droplets and
-      aerosols from carriers, many of whom are asymptomatic or
-    presymptomatic.
    • 
-  
  • Wearing European FFP2 masks, American N95 masks, or Chinese KN95 masks, if
-      appropriately fitted to the face, reduces individual risk of contracting
-      covid. (However, a mask with an output vent to
-      facilitate exhaling should be worn only with another paper or cloth mask
-      over it, to avoid spreading exhaled virus particles if the wearer is a
-      carrier.)
    • 
-

-
Several vaccines have been developed, tested in large-scale
-    randomized clinical trials, and approved by regulatory bodies to immunize
-    populations against SARS-CoV-2:

-
    
-  
  • Moderna (United States)
    • 
-  
  • Pfizer-BioNTech (multinational)
    • 
-  
  • Sputnik V (Russia)
    • 
-  
  • Oxford-AstraZeneca (multinational)
    • 
-  
  • Novavax (United Kingdom and South Africa)
    • 
-  
  • BBIBP-CorV (multinational)
    • 
-  
  • CoronaVac (Brazil)
    • 
-  
  • Johnson & Johnson, a.k.a. Janssen (multinational)
    • 
-  
  • Covaxin (India)
    • 
-  
  • Convidecia (multinational)
    • 
-

-
The approved covid vaccines are some of
-    the safest and most efficacious vaccines in history, with almost all of them
-    preventing essentially 100% of severe cases of the disease and
-    hospitalization, and preventing the vast majority of mild cases, according
-    to randomized clinical trials.

-

-

-

-
Key Things to Know About
-    COVID-19 Vaccines,
-    https://www.cdc.gov/coronavirus/2019-ncov/vaccines/keythingstoknow.html,
-    United States CDC — Centers for Disease Control and
-    Prevention, March 13, 2021.

-
Safety of COVID-19
-    Vaccines,
-    https://www.cdc.gov/coronavirus/2019-ncov/vaccines/safety/safety-of-vaccines.html,
-    United States CDC — Centers for Disease Control and
-    Prevention, March 25, 2021.

-
Possible Side Effects After
-    Getting a COVID-19 Vaccine,
-    https://www.cdc.gov/coronavirus/2019-ncov/vaccines/expect/after.html,
-    United States CDC — Centers for Disease Control and
-    Prevention, March 16, 2021.

-
Zeynep Tufekci,
-    5 Pandemic Mistakes We Keep Repeating,
-    The Atlantic,
-    https://www.theatlantic.com/ideas/archive/2021/02/how-public-health-messaging-backfired/618147/,
-    February 26, 2021.

-

-

-

-
2020 was a sordid year.

-

-

-

-
The covid man page was written by
-    Taylor R Campbell
-    ⟨riastradh@NetBSD.org⟩, sourced from many thousands of hours
-    of furiously doomscrolling epidemiology Twitter to pass the time during the
-    pandemic.

-

-

-

-
The covid vaccines may cause muscle pain,
-    redness, swelling, tiredness, headache, chills, fever, and/or nausea. (Sure
-    beats catching the plague, though!)

-

-

-

-
covid is technically caused by a virus,
-    not a bug.

-

-

-
-  
-    
-    
-  
-
March 397th, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/crl.4 4.html b/static/netbsd/man4/man4.vax/crl.4 4.html
deleted file mode 100644
index 2d37588f..00000000
--- a/static/netbsd/man4/man4.vax/crl.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRL(4)Device Drivers Manual (vax)CRL(4)

-

-

-

-
crl — VAX-8600
-    console RL02 interface

-

-

-

-
This is a simple interface to the DEC RL02 disk unit which is part
-    of the console subsystem on the VAX-8600 and 8650. Access is given to the
-    entire RL02 disk; the pack format is the same as that of RL02 disks on other
-    controllers. As on other VAX console media, transfers are done a word at a
-    time using privileged registers (i.e., slowly).

-
All I/O is raw; the seek addresses in raw transfers should be a
-    multiple of 512 bytes and a multiple of 512 bytes should be transferred, as
-    in other “raw” disk interfaces. (Although the sector size is
-    actually 256 bytes, the driver allows operations only on 512-byte
-    boundaries.)

-

-

-

-

-  
/dev/crl

-  
 

-

-

-

-

-
arff(8)

-

-

-

-
The crl driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/css.4 3.html b/static/netbsd/man4/man4.vax/css.4 3.html
deleted file mode 100644
index 56abf5e7..00000000
--- a/static/netbsd/man4/man4.vax/css.4 3.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
CSS(4)Device Drivers Manual (vax)CSS(4)

-

-

-

-
css — DEC IMP-11A
-    LH/DH IMP network interface

-

-

-

-
pseudo-device imp device css0 at uba0 csr 167600
-    flags 10 vector cssrint cssxint

-

-

-

-
NOTE: At the moment, NetBSD does not
-    support IMP, so this manual page is not relevant.

-
The css device provides
-    a Local Host/Distant Host interface to an IMP. It is normally used when
-    participating in the DARPA Internet. The controller itself is not accessible
-    to users, but instead provides the hardware support to the IMP interface
-    described in imp(4). The configuration entry for the
-    imp(4) must also include the
-    
-    as shown above.

-

-

-

-

-  
css%d: not alive.

-  
The initialization routine was entered even though the device did not
-      autoconfigure. This is indicates a system problem.

-  
css%d: can't initialize.

-  
Insufficient UNIBUS resources existed to initialize the device. This is
-      likely to occur when the device is run on a buffered data path on an
-      11/750 and other network interfaces are also configured to use buffered
-      data paths, or when it is configured to use buffered data paths on an
-      11/730 (which has none).

-  
css%d: imp doesn't respond, icsr=%b.

-  
The driver attempted to initialize the device, but the IMP failed to
-      respond after 500 tries. Check the cabling.

-  
css%d: stray output interrupt csr=%b.

-  
An interrupt occurred when no output had previously been started.

-  
css%d: output error, ocsr=%b icsr=%b.

-  
The device indicated a problem sending data on output.

-  
css%d: recv error, csr=%b.

-  
The device indicated a problem receiving data on input.

-  
css%d: bad length=%d.

-  
An input operation resulted in a data transfer of less than 0 or more than
-      1008 bytes of data into memory (according to the word count register).
-      This should never happen as the maximum size of a host-IMP message is 1008
-      bytes.

-

-

-

-

-
The css interface appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ct.4 4.html b/static/netbsd/man4/man4.vax/ct.4 4.html
deleted file mode 100644
index bc0cd693..00000000
--- a/static/netbsd/man4/man4.vax/ct.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
CT(4)Device Drivers Manual (vax)CT(4)

-

-

-

-
ct — C/A/T
-    phototypesetter interface

-

-

-

-
ct0 at uba0 csr 0167760 vector ctintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
This is an interface to either a Graphic Systems C/A/T
-    phototypesetter or an Autologic APS-Micro5 using a DR-11 C interface.

-
The ct is a write only device.

-

-

-

-

-  
/dev/cat

-  
 

-

-

-

-

-
None.

-

-

-

-
troff(1)

-
Phototypesetter interface
-    specification.

-

-

-

-
The ct driver appeared in
-    4.1BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ddn.4 3.html b/static/netbsd/man4/man4.vax/ddn.4 3.html
deleted file mode 100644
index e51f6023..00000000
--- a/static/netbsd/man4/man4.vax/ddn.4 3.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
DDN(4)Device Drivers Manual (vax)DDN(4)

-

-

-

-
ddn — DDN Standard
-    Mode X.25 IMP network interface

-

-

-

-
ddn0 at uba0 csr 166740 vector ddnintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ddn device provides a DDN Standard
-    Mode X.25 interface to an IMP using the ACC ACP625 X.25 board. It is
-    normally used for connecting to the Defense Data Network (DDN). The
-    controller itself is not accessible to users, but instead provides a network
-    interface for the Internet Protocol described in
-  ip(4).

-

-

-

-

-  
ddn%d: not alive.

-  
The initialization routine was entered even though the device did not
-      autoconfigure. This indicates a system problem.

-  
ddn%d: failed getting UBA resources for lcn %d."

-  
Insufficient UNIBUS resources existed to initialize the device. This is
-      likely to be a shortage of UNIBUS mapping registers.

-  
ddn%d: couldn't get X25 init buffer.

-  
This indicates that an mbuf could not be allocated for
-      sending the initialization message to the ACP625.

-  
DDN: illegal X25 address length!

-  

-  
DDN: illegal X25 address format!

-  
These errors indicate a problem with the called X.25 address received from
-      the IMP on an incoming call.

-  
X25 RESET on lcn = %d.

-  
This indicates that an unexpected X.25 RESET was received on the indicated
-      LCN.

-  
X25 INTERRUPT on lcn = %d, code = %d.

-  
This indicates that an unexpected X.25 INTERRUPT Packet was received on
-      the indicated LCN.

-  
ddn%d: failed to get supr msg bfr!

-  
This indicates that an mbuf could not be allocated for
-      sending a supervisor message to the ACP625.

-

-
Any other error message from
-    ‘ddn%d:’ indicates a serious error
-    detected by either the driver or the ACP625 firmware.

-

-

-

-
ip(4), netintro(4)

-

-

-

-
The ddn interface appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/de.4 4.html b/static/netbsd/man4/man4.vax/de.4 4.html
deleted file mode 100644
index 4f5834b6..00000000
--- a/static/netbsd/man4/man4.vax/de.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
DE(4)Device Drivers Manual (vax)DE(4)

-

-

-

-
de — DEC
-    DEUNA/DELUA 10 Mb/s Ethernet interface

-

-

-

-
de0 at uba? csr 174510

-

-

-

-
The de interface provides access to a 10
-    Mb/s Ethernet network through a Digital Equipment UNIBUS Network Adapter
-    (DEUNA).

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    de interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-

-  
de%d: hardware address %s.

-  
This is a normal autoconfiguration message noting the 6 byte physical
-      Ethernet address of the adapter.

-  
de%d: oerror, flags=%b tdrerr=%b (len=%d).

-  
The hardware indicated an error in transmitting a packet to the cable. The
-      status and error flags are reported.

-  
de%d: ierror, flags=%b lenerr=%b (len=%d).

-  
The hardware indicated an error in reading a packet from the cable. The
-      status and error flags are reported.

-

-
The following messages indicate a probable hardware error
-    performing the indicated operation during autoconfiguration or
-    initialization. The two control and status registers should indicate the
-    nature of the failure. See the hardware manual for details.

-

-  
de%d: reset failed, csr0=%b csr1=%b.

-  

-  
de%d: ppcb failed, csr0=%b csr1=%b.

-  

-  
de%d: read addr failed, csr0=%b csr1=%b.

-  

-  
de%d: wtring failed, csr0=%b csr1=%b.

-  

-  
de%d: wtmode failed, csr0=%b csr1=%b.

-  

-

-

-

-

-
arp(4), inet(4),
-    netintro(4)

-

-

-

-
The de driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
August 31, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dh.4 4.html b/static/netbsd/man4/man4.vax/dh.4 4.html
deleted file mode 100644
index 1ce264b8..00000000
--- a/static/netbsd/man4/man4.vax/dh.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
DH(4)Device Drivers Manual (vax)DH(4)

-

-

-

-
dh — DH-11/DM-11
-    serial multiplexer device interface

-

-

-

-
dh0 at uba0 csr 0160020 vector dhrint
-    dhxint [flags]
-  

-  dm0 at uba0 csr 0170500 vector dmintr
-    [flags]

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
A DH-11 provides 16 serial communication lines; DM-11s may
-    optionally be paired with DH-11s to provide modem control for the lines.

-
An optional argument flags may be supplied
-    with the device specification in the config(1) file
-    indicating that the line corresponding to bit number i
-    is not properly connected, and should be treated as hard-wired with carrier
-    always present. Thus specifying ‘flags
-    0x0004’ for dh0 would cause line
-    ttyh2 to be treated in this way.

-
Normal I/O control parameters for individual lines are managed by
-    ioctl(2) calls. Line speeds may be initiated via
-    getty(8) and stty(1) or may be
-    communicated by other programs which use ioctl(2) such as
-    ifconfig(8), see tty(4).

-
The dh driver monitors the rate of input
-    on each board, and switches between the use of character-at-a-time
-    interrupts and input silos. While the silo is enabled during periods of
-    high-speed input, the driver polls for input 30 times per second.

-

-

-

-

-  
/dev/tty[h-o][0-9a-f]

-  
 

-  
/dev/ttyd[0-9a-f]

-  
 

-

-

-

-

-

-  
dh%d: NXM.

-  
No response from UNIBUS on a DMA transfer within a timeout period. This is
-      often followed by a UNIBUS adapter error. This occurs most frequently when
-      the UNIBUS is heavily loaded and when devices which hog the bus (such as
-      RK07s) are present. It is not serious.

-  
dh%d: silo overflow.

-  
The character input silo overflowed before it could be serviced. This can
-      happen if a hard error occurs when the CPU is running with elevated
-      priority, as the system will then print a message on the console with
-      interrupts disabled. It is not serious.

-

-

-

-

-
tty(4)

-

-

-

-
A dh driver appeared in
-    Version 6 AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dhu.4 4.html b/static/netbsd/man4/man4.vax/dhu.4 4.html
deleted file mode 100644
index b7d692b4..00000000
--- a/static/netbsd/man4/man4.vax/dhu.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
DHU(4)Device Drivers Manual (vax)DHU(4)

-

-

-

-
dhu —
-    DHU-11/DHV-11 serial communications multiplexer

-

-

-

-
dhu0 at uba0 csr 0160440

-

-

-

-
A DHU-11 provides 16 communication lines.

-
Normal I/O control parameters for individual lines are managed by
-    ioctl(2) calls. Individual DHU-11 lines may be configured
-    to run at any of 13 speeds (50, 200 and 38400 baud are not available); the
-    speed may be set via getty(8) or stty(1)
-    or may be communicated by other programs which use
-    ioctl(2) such as ifconfig(8), see
-    tty(4).

-
The DHU-11 driver normally uses input silos and delays receiver
-    interrupts by 20 milliseconds rather than taking an interrupt on each input
-    character.

-

-

-

-

-  
/dev/tty[S-Z][0-9a-f]

-  
 

-

-

-

-

-
The driver currently does not make full use of the hardware
-    capabilities of the DHU-11, for dealing with XON/XOFF flow-control or
-    hard-wired lines for example.

-
Although the devices are not the same, a DHU-11 can convince the
-    DH-11 autoconfiguration code that it is a DH-11.

-
The 4 40-way cables are a pain.

-

-

-

-
tty(4)

-

-

-

-
The dhu driver appeared in
-    4.3BSD.

-
A new dhu driver showed up in
-    NetBSD 1.2.

-

-

-

-
Even if the dhu hardware supports DMA, the
-    driver cannot make use of this capability.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dl.4 4.html b/static/netbsd/man4/man4.vax/dl.4 4.html
deleted file mode 100644
index 9fae2473..00000000
--- a/static/netbsd/man4/man4.vax/dl.4 4.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
DL(4)Device Drivers Manual (vax)DL(4)

-

-

-

-
dl — DL-11/DLV-11
-    serial device driver

-

-

-

-
dl0 at uba? csr 0176500
-  

-  dl1 at uba? csr 0176510
-  

-  dl2 at uba? csr 0176520
-  

-  dl3 at uba? csr 0176530

-

-

-

-
The dl driver controls a DL-11-compatible
-    asynchronous serial card, and probably things compatible with it. A
-    four-port DLV-11J will appear four times in the device list, as the ports
-    look like separate cards to the driver.

-
The dl driver provides the normal
-    interface described in tty(4), but many of the
-    configuration calls are unsupported, since their functions are handled by
-    jumpers or switches on the serial card itself. Calls related to
-    modem-control lines are also ignored, since these cards lack them.

-
There's a chance this driver might also work with an LP11, an
-    LPV11 or even a PC11, but it hasn't been tested.

-

-

-

-

-  
/dev/ttyJ?

-  
Special files for communicating with dl devices.

-

-

-

-

-

-  
dl%d: rx overrun.

-  
The character in the receive buffer wasn't read before the next character
-      arrived, and has been lost.

-  
dl%d: stray rx interrupt.

-  
The driver was called to service a receive interrupt, but there was
-      nothing for it to read.

-

-

-

-

-
tty(4)

-

-

-

-
The dl driver was written for
-    NetBSD 1.3.

-

-

-

-
Ben Harris
-    <bjh21@NetBSD.org>

-

-

-

-
The DL-11 and friends only have single-character receive and
-    transmit buffers, so an interrupt is generated for every character received
-    or transmitted. Attempting to receive data at even moderately high rates
-    will cause rx overruns. Fast transmission seems to be fine though.

-
There is no support in the driver for the paper-tape reader on an
-    LT33 attached via a DLV-11KA or similar.

-
The overrun message is logged in the interrupt routine itself,
-    which will probably just make the problem worse.

-
The CSR printed on startup is that of the receiver, while the
-    interrupt vector is that of the transmitter.

-
In order to determine the card's interrupt vector, the driver
-    sends a NUL to each port. This may confuse things
-    attached to them.

-
The driver has so far only been tested on a DLV-11J. It may or may
-    not work on the other cards it claims to support.

-

-

-
-  
-    
-    
-  
-
January 28, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dmc.4 4.html b/static/netbsd/man4/man4.vax/dmc.4 4.html
deleted file mode 100644
index 4af84275..00000000
--- a/static/netbsd/man4/man4.vax/dmc.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
DMC(4)Device Drivers Manual (vax)DMC(4)

-

-

-

-
dmc — DEC
-    DMC-11/DMR-11 point-to-point serial communications device

-

-

-

-
dmc0 at uba0 csr 167600

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The dmc interface provides access to a
-    point-to-point communications device which runs at either 1 Mb/s or 56 Kb/s.
-    DMC-11s communicate using the DEC DDCMP link layer protocol.

-
The dmc interface driver also supports a
-    DEC DMR-11 providing point-to-point communication running at data rates from
-    2.4 Kb/s to 1 Mb/s. DMR-11s are a more recent design and thus are preferred
-    over DMC-11s. The NXMT and
-    NRCV constants in the driver may be increased in
-    this case, as the DMR can accept up to 64 transmit and receive buffers, as
-    opposed to 7 for the DMC.

-
The configuration flags specify how to set up the device,

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
0full duplex DDCMP (normal mode)
1DDCMP Maintenance mode (generally useless)
2DDCMP Half Duplex, primary station
3DDCMP Half Duplex, secondary station

-The host's address must be specified with an SIOCSIFADDR
-  ioctl(2), and the destination address specified with a
-  SIOCSIFDSTADDR ioctl(2), before the
-  interface will transmit or receive any packets.
-

-

-

-
The driver places a HOST entry in the kernel routing tables for
-    the address given in the SIOCSIFDSTADDR
-    ioctl(2). To use the DMC as a link between local nets, the
-    route to the remote net must be added manually with the
-    route(8) command, or by the use of the routing process
-    routed(8) on each end of the link.

-

-

-

-

-  
dmc%d: bad control %o.

-  
A bad parameter was passed to the
-      
-      routine.

-  
dmc%d: unknown address type %d.

-  
An input packet was received which contained a type of address unknown to
-      the driver.

-  
DMC fatal error 0%o.

-  
A fatal error in DDMCP occurred, causing the device to be restarted.

-  
DMC soft error 0%o.

-  
A non-fatal error in DDMCP has occurred.

-  
dmc%d: af%d not supported.

-  
The interface was handed a message which has addresses formatted in an
-      unsuitable address family.

-

-

-

-

-
inet(4), vax/intro(4)

-

-

-

-
The dmc driver appeared in
-    4.2BSD.

-

-

-

-
The current version of the driver uses a link-level encapsulation
-    so that multiple protocol types may be used. It is thus incompatible with
-    earlier drivers, including the 4.2BSD version.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dmf.4 4.html b/static/netbsd/man4/man4.vax/dmf.4 4.html
deleted file mode 100644
index 73b80b60..00000000
--- a/static/netbsd/man4/man4.vax/dmf.4 4.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
DMF(4)Device Drivers Manual (vax)DMF(4)

-

-

-

-
dmf — DMF-32
-    serial terminal multiplexor

-

-

-

-
dmf0 at uba? csr 0160340 vector dmfsrint dmfsxint
-    dmfdaint dmfdbint dmfrint dmfxint dmflint

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The dmf device provides 8 lines of
-    asynchronous serial line support. The first two of these have full modem
-    control. The device also provides a line printer port similar to the LP-11.
-    Other features of the DMF-32 are not supported. During autoconfiguration,
-    the driver examines the configuration of each DMF-32 and adjusts the
-    interrupt vectors so that fewer vector locations are used if possible.

-
An optional argument flags may be supplied
-    with the device specification in the config file indicating that the line
-    corresponding to bit number i is not properly
-    connected, and should be treated as hard-wired with carrier always present.
-    Thus specifying ‘flags 0x04’ for
-    dmf0 would cause line ttyA2
-    to be treated in this way. Flags should be set for all lines without
-    hardware support for modem control.

-
Normal I/O control parameters for individual lines are managed by
-    ioctl(2) calls. Line speeds may be initiated via
-    getty(8) and stty(1) or may be
-    communicated by other programs which use ioctl(2) such as
-    ifconfig(8), see tty(4).

-
The serial line part of the dmf driver
-    normally enables the input silos with a short timeout (30 milliseconds);
-    this allows multiple characters to be received per interrupt during periods
-    of high-speed input.

-
A line printer port on a dmf is designated
-    by a minor device number of the form 128+n. See
-    MAKEDEV(8). Column and lines per page may be changed from
-    the default 132 columns and 66 lines by encoding the number of columns in
-    bits 8-15 of flags and the number of lines in bits 16-23. This device does
-    not provide the fancy output canonicalization features of the
-    vax/lp(4) driver.

-

-

-

-

-  
/dev/tty[A-CE-I][0-7]

-  
 

-  
/dev/ttyd[0-7]

-  
 

-  
/dev/lp

-  
 

-

-

-

-

-

-  
dmf%d: NXM line %d.

-  
No response from UNIBUS on a DMA transfer within a timeout period. This is
-      often followed by a UNIBUS adapter error. This occurs most frequently when
-      the UNIBUS is heavily loaded and when devices which hog the bus (such as
-      RK07s) are present. It is not serious.

-  
dmf%d: silo overflow.

-  
The character input silo overflowed before it could be serviced. This can
-      happen if a hard error occurs when the CPU is running with elevated
-      priority, as the system will then print a message on the console with
-      interrupts disabled. It is not serious.

-  
dmfsrint, dmfsxint, dmfdaint, dmfdbint.

-  
One of the unsupported parts of the dmf interrupted; something is amiss,
-      check your interrupt vectors for a conflict with another device.

-

-

-

-

-
tty(4)

-

-

-

-
The dmf driver appeared in
-    4.2BSD.

-

-

-

-
It should be possible to set the silo timeout with a configuration
-    file option, as the value is a trade-off between efficiency and response
-    time for flow control and character echo.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dmv.4 4.html b/static/netbsd/man4/man4.vax/dmv.4 4.html
deleted file mode 100644
index d36d3592..00000000
--- a/static/netbsd/man4/man4.vax/dmv.4 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
DMV(4)Device Drivers Manual (vax)DMV(4)

-

-

-

-
dmv — DEC DMV-11
-    point-to-point serial communications device

-

-

-

-
dmv0 at uba0 csr 167000 vector dmvrint
-    dmvxint

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The dmv interface provides access to a
-    point-to-point communications device which runs at up to 56 Kb/s. DMV-11s
-    communicate using the DEC DDCMP link layer protocol.

-
The host's address must be specified with an
-    SIOCSIFADDR ioctl(2), and the
-    destination address specified with a SIOCSIFDSTADDR
-    ioctl(2), before the interface will transmit or receive
-    any packets.

-

-

-

-
The driver places a HOST entry in the kernel routing tables for
-    the address given in the SIOCSIFDSTADDR
-    ioctl(2). To use the DMV as a link between local nets, the
-    route to the remote net must be added manually with the
-    route(8) command, or by the use of the routing process
-    routed(8) on each end of the link.

-

-

-

-

-  
dmvprobe: can't start device.

-  

-  
dmvprobe: device init failed, bsel4=%o, bsel6=%o.

-  
The probe routine was unable to start the device.

-  
dmvinit: dmv%d not running.

-  

-  
dmvrestart: can't start device.

-  

-  
dmv%d: device init failed, bsel4=%o, bsel6=%o.

-  
The initialization/restart routine was unable to start the device.

-  
dmv%d: far end on-line.

-  
The other end of the connection has come online.

-  
dmv%d: far end restart.

-  
The other end of the line has restarted.

-  
dmv%d: bad control %o.

-  
A bad parameter was passed to the
-      
-      routine.

-  
dmvxint: dmv%d bad rcv pkt addr 0x%x len 0x%x.

-  
A bad packet was received.

-  
dmv%d: bad packet address 0x%x.

-  
An input packet was received which contained a type of address unknown to
-      the driver.

-  
dmvxint: dmv%d unallocated packet 0x%x.

-  
A protocol error has occurred with the board.

-  
dmvoutput, dmv%d can't handle af%d.

-  
A packet for an unsupported address family has been sent.

-  
dmv%d: output timeout, bsel0=%b bsel2=%b.

-  
A device timeout occurred.

-

-
Numerous other device errors may be displayed.

-

-

-

-
inet(4), vax/dmc(4),
-    vax/intro(4)

-

-

-

-
The dmv driver appeared in
-    4.3BSD-Tahoe.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dmz.4 4.html b/static/netbsd/man4/man4.vax/dmz.4 4.html
deleted file mode 100644
index 81b9f756..00000000
--- a/static/netbsd/man4/man4.vax/dmz.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
DMZ(4)Device Drivers Manual (vax)DMZ(4)

-

-

-

-
dmz — DMZ-32
-    serial terminal multiplexor

-

-

-

-
dmz0 at uba? csr 0160540 vector dmzrinta dmzxinta
-    dmzrintb dmzxintb dmzrintc dmzxintc

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The dmz device provides 24 lines of
-    asynchronous serial line support. Modem control on all ports is available as
-    an option for the H3014 distribution panel.

-
An optional argument flags may be supplied
-    with the device specification for dmz in the config
-    file indicating that the line corresponding to bit number
-    i is not properly connected, and should be treated as
-    hard-wired with carrier always present. Thus specifying
-    ‘flags 0x000004’ for
-    dmz0 would cause line ttya2
-    to be treated in this way.

-
Normal I/O control parameters for individual lines are managed by
-    ioctl(2) calls. Line speeds (there are 16 choices for the
-    DMZ) may be initiated via getty(8) and
-    stty(1) or may be communicated by other programs which use
-    ioctl(2) such as ifconfig(8), see
-    tty(4).

-
The dmz driver normally enables the input
-    silos with a short timeout (30 milliseconds); this allows multiple
-    characters to be received per interrupt during periods of high-speed
-  input.

-

-

-

-

-  
/dev/tty[abcefg][0-9a-n]

-  
 

-

-

-

-

-

-  
dmz%d: NXM line %d.

-  
No response from the UNIBUS on a DMA transfer within a timeout period.
-      This is often followed by a UNIBUS adapter error. This occurs most
-      frequently when the UNIBUS is heavily loaded and when devices which hog
-      the bus (such as RK07s) are present. It is not serious.

-  
dmz%d: silo overflow.

-  
The character input silo overflowed before it could be serviced. This can
-      happen if a hard error occurs when the CPU is running with elevated
-      priority, as the system will then print a message on the console with
-      interrupts disabled. It is not serious.

-

-

-

-

-
tty(4)

-

-

-

-
The dmz driver appeared in
-    4.3BSD.

-

-

-

-
It should be possible to set the silo timeout with a configuration
-    file option, as the value is a trade-off between efficiency and response
-    time for flow control and character echo.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dn.4 4.html b/static/netbsd/man4/man4.vax/dn.4 4.html
deleted file mode 100644
index e479ac3b..00000000
--- a/static/netbsd/man4/man4.vax/dn.4 4.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
DN(4)Device Drivers Manual (vax)DN(4)

-

-

-

-
dn — DN-11 serial
-    autocall unit interface

-

-

-

-
dn0 at uba? csr 0160020 vector dnintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The dn device provides an interface
-    through a DEC DN-11 (or equivalent such as the Able Quadracall) to an
-    auto-call unit (ACU). To place an outgoing call one forks a sub-process
-    which opens the appropriate call unit file,
-    /dev/cua? and writes the phone number on it. The
-    parent process then opens the corresponding modem line
-    /dev/cul?. When the connection has been established,
-    the open on the modem line /dev/cul? will return and
-    the process will be connected. A timer is normally used to timeout the
-    opening of the modem line.

-
The codes for the phone numbers are:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
0-9number to be dialed
*dial * (`:' is a synonym)
#dial # (`;' is a synonym)
-delay 20 milliseconds
<end of phone number (`e' is a synonym)
=delay for a second dial tone (`w' is a synonym)
fforce a hangup of any existing connection

-
The phone number to be dialed must be presented as one contiguous
-    string.

-
By convention, even numbered call units are for 300 baud modem
-    lines, while odd numbered units are for 1200 baud lines. For example,
-    /dev/cua0 is associated with a 300 baud modem line,
-    /dev/cul0, while /dev/cua1
-    is associated with a 1200 baud modem line,
-    /dev/cul1. For devices such as the Quadracall which
-    simulate multiple DN-11 units, the minor device indicates which outgoing
-    modem to use.

-

-

-

-

-  
/dev/cua?

-  
call units

-  
/dev/cul?

-  
associated modem lines

-

-

-

-

-
Two error numbers are of interest at open time.

-

-  
[EBUSY]

-  
The dialer is in use.

-  
[ENXIO]

-  
The device doesn't exist, or there's no power to it.

-

-

-

-

-
tip(1)

-

-

-

-
A dn driver appeared in
-    Version 6 AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/dz.4 4.html b/static/netbsd/man4/man4.vax/dz.4 4.html
deleted file mode 100644
index 6f150d75..00000000
--- a/static/netbsd/man4/man4.vax/dz.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
DZ(4)Device Drivers Manual (vax)DZ(4)

-

-

-

-
dz — DZ-11 serial
-    multiplexer device interface

-

-

-

-
dz0 at uba0 csr 0160100 vector dzrint
-    dzxint

-

-

-

-
A DZ-11 provides 8 communication lines with partial modem control,
-    adequate for UNIX dialup use.

-
An optional argument flags may be supplied
-    with the device specification in the config file indicating that the line
-    corresponding to bit number i is not properly
-    connected, and should be treated as hard-wired with carrier always present.
-    Thus specifying ‘flags 0x04’ for
-    dz0 would cause line tty02
-    to be treated in this way.

-
Normal I/O control parameters for individual lines are managed by
-    ioctl(2) calls. Line speeds may be initiated via the
-    ttys(5) file, stty(1) or
-    ifconfig(8) to name a few, see
-  tty(4).

-
The dz driver monitors the rate of input
-    on each board, and switches between the use of character-at-a-time
-    interrupts and input silos. While the silo is enabled during periods of
-    high-speed input, the driver polls for input 30 times per second.

-

-

-

-

-  
/dev/tty[0-9][0-9]

-  
 

-  
/dev/ttyd[0-9a-f]

-  
dialups

-

-

-

-

-

-  
dz%d: silo overflow.

-  
The 64 character input silo overflowed before it could be serviced. This
-      can happen if a hard error occurs when the CPU is running with elevated
-      priority, as the system will then print a message on the console with
-      interrupts disabled. It is not serious.

-

-

-

-

-
stty(1), tty(4),
-    ttys(5), getty(8)

-

-

-

-
A dz driver appeared in
-    Version 7 AT&T UNIX/32V.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ec.4 4.html b/static/netbsd/man4/man4.vax/ec.4 4.html
deleted file mode 100644
index b004089a..00000000
--- a/static/netbsd/man4/man4.vax/ec.4 4.html	
+++ /dev/null
@@ -1,91 +0,0 @@
-
-  
-    
-    
-    
-  
-
EC(4)Device Drivers Manual (vax)EC(4)

-

-

-

-
ec — 3Com 10 Mb/s
-    Ethernet interface

-

-

-

-
ec0 at uba0 csr 161000 vector ecrint eccollide
-    ecxint flags 0

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ec interface provides access to a 10
-    Mb/s Ethernet network through a 3Com controller.

-
The hardware has 32 kilobytes of dual-ported memory on the UNIBUS.
-    This memory is used for internal buffering by the board, and the interface
-    code reads the buffer contents directly through the UNIBUS. The address of
-    this memory is given in the flags field in the
-    configuration file. The first interface normally has its memory at UNIBUS
-    address 0.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ec interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-
The interface software implements an exponential backoff algorithm
-    when notified of a collision on the cable. This algorithm uses a 16-bit mask
-    and the VAX-11's interval timer in calculating a series of random backoff
-    values. The algorithm is as follows:

-
    
-  
  1. Initialize the mask to be all 1's.
    2. 
-  
  2. If the mask is zero, 16 retries have been made and we give up.
    3. 
-  
  3. Shift the mask left one bit and formulate a backoff by masking the
-      interval timer with the smaller of the complement of this mask and a 5-bit
-      mask, resulting in a pseudo-random number between 0 and 31. This produces
-      the number of slot times to delay, where a slot is 51 microseconds.
    4. 
-  
  4. Use the value calculated in step 3 to delay before retransmitting the
-      packet. The delay is done in a software busy loop.
    5. 
-

-

-

-

-

-  
ec%d: send error.

-  
After 16 retransmissions using the exponential backoff algorithm described
-      above, the packet was dropped.

-  
ec%d: input error (offset=%d).

-  
The hardware indicated an error in reading a packet off the cable or an
-      illegally sized packet. The buffer offset value is printed for debugging
-      purposes.

-  
ec%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4)

-

-

-

-
The ec driver appeared in
-    4.2BSD.

-

-

-

-
The hardware is not capable of talking to itself. The software
-    implements local sending and broadcast by sending such packets to the loop
-    interface. This is a kludge.

-
Backoff delays are done in a software busy loop. This can degrade
-    the system if the network experiences frequent collisions.

-

-

-
-  
-    
-    
-  
-
February 5, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/en.4 4.html b/static/netbsd/man4/man4.vax/en.4 4.html
deleted file mode 100644
index 914441ce..00000000
--- a/static/netbsd/man4/man4.vax/en.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
EN(4)Device Drivers Manual (vax)EN(4)

-

-

-

-
en — Xerox 3 Mb/s
-    Ethernet interface

-

-

-

-
en0 at uba0 csr 161000 vector enrint enxint
-    encollide

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The en interface provides access to a 3
-    Mb/s Ethernet network. Due to limitations in the hardware, DMA transfers to
-    and from the network must take place in the lower 64K bytes of the UNIBUS
-    address space, and thus this must be among the first UNIBUS devices enabled
-    after boot.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    station address is discovered by probing the on-board Ethernet address
-    register, and is used to verify the protocol addresses. No packets will be
-    sent or accepted until a network address is supplied.

-
The interface software implements an exponential backoff algorithm
-    when notified of a collision on the cable. This algorithm uses a 16-bit mask
-    and the VAX-11's interval timer in calculating a series of random backoff
-    values. The algorithm is as follows:

-
    
-  
  1. Initialize the mask to be all 1's.
    2. 
-  
  2. If the mask is zero, 16 retries have been made and we give up.
    3. 
-  
  3. Shift the mask left one bit and formulate a backoff by masking the
-      interval timer with the mask (this is actually the two's complement of the
-      value).
    4. 
-  
  4. Use the value calculated in step 3 to delay before retransmitting the
-      packet.
    5. 
-

-

-

-

-

-  
en%d: output error.

-  
The hardware indicated an error on the previous transmission.

-  
en%d: send error.

-  
After 16 retransmissions using the exponential backoff algorithm described
-      above, the packet was dropped.

-  
en%d: input error.

-  
The hardware indicated an error in reading a packet off the cable.

-  
en%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-

-

-

-

-
inet(4), netintro(4)

-

-

-

-
The en driver appeared in
-    4.2BSD.

-

-

-

-
The device has insufficient buffering to handle back to back
-    packets. This makes use in a production environment painful.

-
The hardware does word at a time DMA without byte swapping. To
-    compensate, byte swapping of user data must either be done by the user or by
-    the system. A kludge to byte swap only IP packets is provided if the
-    ENF_SWABIPS flag is defined in the driver and set at
-    boot time with an SIOCSIFFLAGS
-    ioctl(2).

-

-

-
-  
-    
-    
-  
-
February 5, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ex.4 4.html b/static/netbsd/man4/man4.vax/ex.4 4.html
deleted file mode 100644
index 71179675..00000000
--- a/static/netbsd/man4/man4.vax/ex.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
EX(4)Device Drivers Manual (vax)EX(4)

-

-

-

-
ex — Excelan 10
-    Mb/s Ethernet interface

-

-

-

-
ex0 at uba0 csr 164000 vector excdint

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ex interface provides access to a 10
-    Mb/s Ethernet network through an Excelan controller used as a link-layer
-    interface.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ex interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-

-  
ex%d: HW %c.%c, NX %c.%c, hardware address %s.

-  
This provides firmware revisions levels, and is expected during
-      autoconfiguration.

-  
ex%d: can't initialize.

-  
There was a failure in allocating UNIBUS resources for the device.

-  
ex%d: configuration failed; cc = %x.

-  
The hardware indicated an error when trying to initialize itself. The
-      error code returned is described at length in the device Reference
-    Manual.

-  
ex%d: receive error %b.

-  
The hardware indicated an error in reading a packet from the cable.
-      Specific Error bits are provided

-  
ex%d: transmit error %b.

-  
The hardware indicated an error in transmitting a packet to the cable or
-      an illegally sized packet. Specific Error bits are provided

-  
ex%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4)

-

-

-

-
The ex driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
February 5, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/fl.4 4.html b/static/netbsd/man4/man4.vax/fl.4 4.html
deleted file mode 100644
index 108591b0..00000000
--- a/static/netbsd/man4/man4.vax/fl.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
FL(4)Device Drivers Manual (vax)FL(4)

-

-

-

-
fl — console
-    floppy interface

-

-

-

-
This is a simple interface to the DEC RX01 floppy disk unit, which
-    is part of the console LSI-11 subsystem for VAX-11/780s. Access is given to
-    the entire floppy consisting of 77 tracks of 26 sectors of 128 bytes.

-
All I/O is raw; the seek addresses in raw transfers should be a
-    multiple of 128 bytes and a multiple of 128 bytes should be transferred, as
-    in other “raw” disk interfaces.

-

-

-

-

-  
/dev/floppy

-  
 

-

-

-

-

-
None.

-

-

-

-
arff(8)

-

-

-

-
The fl driver appeared in
-    4.0BSD.

-

-

-

-
Multiple console floppies are not supported.

-
If a write is given with a count not a multiple of 128 bytes then
-    the trailing portion of the last sector will be zeroed.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/hdh.4 4.html b/static/netbsd/man4/man4.vax/hdh.4 4.html
deleted file mode 100644
index c4cfb1cc..00000000
--- a/static/netbsd/man4/man4.vax/hdh.4 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
HDH(4)Device Drivers Manual (vax)HDH(4)

-

-

-

-
hdh — ACC
-    IF-11/HDH IMP network interface

-

-

-

-
pseudo-device imp
-  

-  hdh0 at uba0 csr 166740 vector hdhintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
NOTE: At the moment, NetBSD does not
-    support IMP, so this manual page is not relevant.

-
The hdh device provides
-    an HDLC Host (HDH) interface to an IMP. It is normally used when
-    participating in the DARPA Internet. The controller itself is not accessible
-    to users, but instead provides the hardware support to the IMP interface
-    described in imp(4). The configuration entry for the IMP
-    must also include the
-    
-    as shown above in the SYNOPSIS.

-

-

-

-

-  
hdh%d: not alive.

-  
The initialization routine was entered even though the device did not
-      autoconfigure. This indicates a system problem.

-  
hdh%d: cannot get chan %d uba resources.

-  
Insufficient UNIBUS resources existed to initialize the device. This is
-      likely to be a shortage of UNIBUS mapping registers.

-  
hdh%d: LINE UP.

-  
This indicates that both the HDLC and HDH protocols have declared the link
-      to the IMP alive.

-  
hdh%d: LINE DOWN.

-  
This indicates that the link to the IMP has died.

-  
hdh%d: TIMEOUT.

-  

-  
hdh%d: HOST DATA ERROR.

-  

-  
hdh%d: IMP SEQUENCE ERROR.

-  

-  
hdh%d: HOST SEQUENCE ERROR.

-  
These errors indicate that an HDH protocol error has been detected.

-  
hdh%d: cannot get supervisor cmnd buffer.

-  
This error indicates that an
-       could not be
-      allocated to send a command to the IF-11/HDH.

-

-
Any other error message from hdh%d: indicates a serious error
-    detected by either the driver or the IF-11/HDH firmware.

-

-

-

-
netintro(4)

-

-

-

-
The hdh driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/hk.4 4.html b/static/netbsd/man4/man4.vax/hk.4 4.html
deleted file mode 100644
index 12d19fd1..00000000
--- a/static/netbsd/man4/man4.vax/hk.4 4.html	
+++ /dev/null
@@ -1,205 +0,0 @@
-
-  
-    
-    
-    
-  
-
HK(4)Device Drivers Manual (vax)HK(4)

-

-

-

-
hk — RK6-11/ RK06
-    and RK07 disk interface

-

-

-

-
hk0 at uba? csr 0177440 vector rkintr
-  

-  rk0 at hk0 drive 0

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The hk driver is a typical block-device
-    disk driver; block device I/O is described in
-  physio(4).

-
The script MAKEDEV(8) should be used to create
-    the special files; if a special file needs to be created by hand consult
-    mknod(8).

-

-

-

-
Special file names begin with
-    ‘hk’ and
-    ‘rhk’ for the block and character
-    files respectively. The second component of the name, a drive unit number in
-    the range of zero to seven, is represented by a
-    ‘?’ in the disk layouts below. The
-    last component is the file system partition which is designated by a letter
-    from ‘a’ to
-    ‘h’. and corresponds to a minor device
-    number set: zero to seven, eight to 15, 16 to 23 and so forth for drive
-    zero, drive two and drive three respectively. The location and size (in
-    sectors) of the partitions for the RK06 and RK07 drives are as follows:

-

-  
RK07 partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyl
hk?a0158840-240
hk?b1590610032241-392
hk?c0537900-814
hk?d2593815884393-633
hk?f4184411792634-814
hk?g2593827786393-813

-  

-  
RK06 partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyl
hk?a0158840-240
hk?b1590611154241-409
hk?c0271260-410

-  

-

-
On a dual RK-07 system partition hk?a is used for the root for one
-    drive and partition hk?g for the /usr file system. If large jobs are to be
-    run using hk?b on both drives as swap area provides a 10Mbyte paging area.
-    Otherwise partition hk?c on the other drive is used as a single large file
-    system.

-

-

-

-

-  
/dev/hk[0-7][a-h]

-  
block files

-  
/dev/rhk[0-7][a-h]

-  
raw files

-

-

-

-

-

-  
hk%d%c: hard error %sing fsbn %d[-%d] cs2=%b ds=%b er=%b.

-  
An unrecoverable error occurred during transfer of the specified
-      filesystem block number(s), which are logical block numbers on the
-      indicated partition. The contents of the cs2, ds and er registers are
-      printed in octal and symbolically with bits decoded. The error was either
-      unrecoverable, or a large number of retry attempts (including offset
-      positioning and drive recalibration) could not recover the error.

-  
rk%d: write locked.

-  
The write protect switch was set on the drive when a write was attempted.
-      The write operation is not recoverable.

-  
rk%d: not ready.

-  
The drive was spun down or off line when it was accessed. The I/O
-      operation is not recoverable.

-  
rk%d: not ready (came back!).

-  
The drive was not ready, but after printing the message about being not
-      ready (which takes a fraction of a second) was ready. The operation is
-      recovered if no further errors occur.

-  
rk%d%c: soft ecc reading fsbn %d[-%d].

-  
A recoverable ECC error occurred on the specified sector(s) in the
-      specified disk partition. This happens normally a few times a week. If it
-      happens more frequently than this the sectors where the errors are
-      occurring should be checked to see if certain cylinders on the pack, spots
-      on the carriage of the drive or heads are indicated.

-  
hk%d: lost interrupt.

-  
A timer watching the controller detected no interrupt for an extended
-      period while an operation was outstanding. This indicates a hardware or
-      software failure. There is currently a hardware/software problem with
-      spinning down drives while they are being accessed which causes this error
-      to occur. The error causes a UNIBUS reset, and retry of the pending
-      operations. If the controller continues to lose interrupts, this error
-      will recur a few seconds later.

-

-

-

-

-
vax/hp(4), vax/uda(4),
-    vax/up(4), syslogd(8)

-

-

-

-
The hk driver appeared in
-    4.1BSD.

-

-

-

-
The write(2) function scribbles on the tail of
-    incomplete blocks.

-
DEC-standard error logging should be supported.

-
A program to analyze the logged error information (even in its
-    present reduced form) is needed.

-
The partition tables for the file systems should be read off of
-    each pack, as they are never quite what any single installation would
-    prefer, and this would make packs more portable.

-
The RK07 g partition size in rk.c disagrees with that in
-    /etc/disktab.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/hp.4 4.html b/static/netbsd/man4/man4.vax/hp.4 4.html
deleted file mode 100644
index 1f37dd67..00000000
--- a/static/netbsd/man4/man4.vax/hp.4 4.html	
+++ /dev/null
@@ -1,120 +0,0 @@
-
-  
-    
-    
-    
-  
-
HP(4)Device Drivers Manual (vax)HP(4)

-

-

-

-
hp — MASSBUS disk
-    interface

-

-

-

-
hp0 at mba0 drive 0
-  

-  hp* at mba? drive ?

-

-

-

-
The hp driver is a generic MASSBUS disk
-    driver which handles the standard DEC controllers. It is typical of a
-    block-device disk driver; block I/O is described in
-    physio(4).

-
The script MAKEDEV(8) should be used to create
-    the special files; if a special file needs to be created by hand consult
-    mknod(8). It is recommended as a security precaution to
-    not create special files for devices which may never be installed.

-
The first sector of each disk contains both a first-stage
-    bootstrap program and a disk label containing geometry information and
-    partition layouts (see disklabel(5). This sector is
-    normally write-protected, and disk-to-disk copies should avoid copying this
-    sector. The label may be updated with disklabel(8), which
-    can also be used to write-enable and write-disable the sector. The next 15
-    sectors contain a second-stage bootstrap program.

-

-

-

-
During autoconfiguration or whenever a drive comes on line for the
-    first time, or when a drive is opened after all partitions are closed, the
-    first sector of the drive is examined for a disk label. If a label is found,
-    the geometry of the drive and the partition tables are taken from it. If no
-    label is found, a fake label is created by the driver, enough so that a real
-    label can be written.

-
The hp?a partition is normally used for the root file system, the
-    hp?b partition as a paging area, and the hp?c partition for pack-pack
-    copying (it maps the entire disk). On disks larger than about 205 Megabytes,
-    the hp?h partition is inserted prior to the hp?d or hp?g partition; the hp?g
-    partition then maps the remainder of the pack.

-

-

-

-

-  
/dev/hp[0-7][a-h]

-  
block files

-  
/dev/rhp[0-7][a-h]

-  
raw files

-

-

-

-

-

-  
hp%d%c: hard error %sing fsbn %d [of %d-%d] (hp%d bn %d cn %d tn %d sn %d)
-    mbsr=%b er1=%b er2=%b.

-  
An unrecoverable error occurred during transfer of the specified
-      filesystem block number, which is a logical block number on the indicated
-      partition. If the transfer involved multiple blocks, the block range is
-      printed as well. The parenthesized fields list the actual disk sector
-      number relative to the beginning of the drive, as well as the cylinder,
-      track and sector number of the block. The MASSBUS status register is
-      printed in hexadecimal and with the error bits decoded if any error bits
-      other than MBEXC and DTABT are set. In any case the contents of the two
-      error registers are also printed in octal and symbolically with bits
-      decoded. (Note that er2 is what old RP06 manuals would call RPER3; the
-      terminology is that of the RM disks). The error was either unrecoverable,
-      or a large number of retry attempts (including offset positioning and
-      drive recalibration) could not recover the error.

-  
hp%d%c: soft ecc reading fsbn %d [of %d-%d] (hp%d bn %d cn %d tn %d sn
-    %d).

-  
A recoverable ECC error occurred on the specified sector of the specified
-      disk partition. If the transfer involved multiple blocks, the block range
-      is printed as well. The parenthesized fields list the actual disk sector
-      number relative to the beginning of the drive, as well as the cylinder,
-      track and sector number of the block. This happens normally a few times a
-      week. If it happens more frequently than this the sectors where the errors
-      are occurring should be checked to see if certain cylinders on the pack,
-      spots on the carriage of the drive or heads are indicated.

-

-

-

-

-
physio(4), vax/up(4),
-    disklabel(5), disklabel(8),
-    MAKEDEV(8), mknod(8)

-

-

-

-
The hp driver appeared in
-    4.0BSD.

-
A new hp driver showed up in
-    NetBSD 1.2.

-

-

-

-
DEC-standard bad144(8) bad-block handling should
-    be used.

-
DEC-standard error logging should be supported.

-
A program to analyze the logged error information (even in its
-    present reduced form) is needed.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ht.4 4.html b/static/netbsd/man4/man4.vax/ht.4 4.html
deleted file mode 100644
index 9253bd0a..00000000
--- a/static/netbsd/man4/man4.vax/ht.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
HT(4)Device Drivers Manual (vax)HT(4)

-

-

-

-
ht — TM-03/ TE-16,
-    TU-45, TU-77 MASSBUS mag tape device interface:

-

-

-

-
ht0 at mba? drive ?
-  

-  tu0 at ht0 slave 0

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The TM-03 transport combination provides a standard tape drive
-    interface as described in vax/mtio(4). All drives provide
-    both 800 and 1600 BPI; the TE-16 runs at 45 IPS, the TU-45 at 75 IPS, while
-    the TU-77 runs at 125 IPS and autoloads tapes.

-

-

-

-

-  
tu%d: no write ring.

-  
An attempt was made to write on the tape drive when no write ring was
-      present; this message is written on the terminal of the user who tried to
-      access the tape.

-  
tu%d: not online.

-  
An attempt was made to access the tape while it was offline; this message
-      is written on the terminal of the user who tried to access the tape.

-  
tu%d: can't change density in mid-tape.

-  
An attempt was made to write on a tape at a different density than is
-      already recorded on the tape. This message is written on the terminal of
-      the user who tried to switch the density.

-  
tu%d: hard error bn%d mbsr=%b er=%b ds=%b.

-  
A tape error occurred at block
-      ; the ht error
-      register and drive status register are printed in octal with the bits
-      symbolically decoded. Any error is fatal on non-raw tape; when possible
-      the driver will have retried the operation which failed several times
-      before reporting the error.

-

-

-

-

-
tar(1), vax/mt(1),
-    physio(4), vax/mt(4),
-    vax/mtio(4), vax/tm(4),
-    vax/ts(4), vax/ut(4)

-

-

-

-
An ht driver appeared in
-    Version 6 AT&T UNIX.

-

-

-

-
May hang if physical (non-data) errors occur.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/hy.4 4.html b/static/netbsd/man4/man4.vax/hy.4 4.html
deleted file mode 100644
index b3268739..00000000
--- a/static/netbsd/man4/man4.vax/hy.4 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
HY(4)Device Drivers Manual (vax)HY(4)

-

-

-

-
hy — Network
-    Systems Hyperchannel interface

-

-

-

-
hy0 at uba0 csr 0172410 vector hyint

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The hy interface provides access to a
-    Network Systems Corporation Hyperchannel Adapter.

-
The network to which the interface is attached is specified at
-    boot time with an SIOCSIFADDR
-    ioctl(2). The host's address is discovered by reading the
-    adapter status register. The interface will not transmit or receive packets
-    until the network number is known.

-

-

-

-

-  
hy%d: unit number 0x%x port %d type %x microcode level 0x%x.

-  
Identifies the device during autoconfiguration.

-  
hy%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-  
hy%d: can't initialize.

-  
The interface was unable to allocate UNIBUS resources. This is usually due
-      to having too many network devices on an 11/750 where there are only 3
-      buffered data paths.

-  
hy%d: NEX - Non Existent Memory.

-  
Non existent memory error returned from hardware.

-  
hy%d: BAR overflow.

-  
Bus address register overflow error returned from hardware.

-  
hy%d: Power Off bit set, trying to reset.

-  
Adapter has lost power, driver will reset the bit and see if power is
-      still out in the adapter.

-  
hy%d: Power Off Error, network shutdown.

-  
Power was really off in the adapter, network connections are dropped.
-      Software does not shut down the network unless power has been off for a
-      while.

-  
hy%d: RECVD MP > MPSIZE (%d).

-  
A message proper was received that is too big. Probable a driver bug.
-      Shouldn't happen.

-  
hy%d: xmit error - len > hy_olen [%d > %d].

-  
Probable driver error. Shouldn't happen.

-  
hy%d: DRIVER BUG - INVALID STATE %d.

-  
The driver state machine reached a non-existent state. Definite driver
-      bug.

-  
hy%d: watchdog timer expired.

-  
A command in the adapter has taken too long to complete. Driver will abort
-      and retry the command.

-  
hy%d: adapter power restored.

-  
Software was able to reset the power off bit, indicating that the power
-      has been restored.

-

-

-

-

-
inet(4), netintro(4)

-

-

-

-
The hy interface appeared in
-    4.2BSD.

-

-

-

-
If the adapter does not respond to the status command issued
-    during autoconfigure, the adapter is assumed down. A reboot is required to
-    recognize it.

-
The adapter power fail interrupt seems to occur sporadically when
-    power has, in fact, not failed. The driver will believe that power has
-    failed only if it can not reset the power fail latch after a
-    “reasonable” time interval. These seem to appear about 2-4
-    times a day on some machines. There seems to be no correlation with adapter
-    rev level, number of ports used etc. and whether a machine will get these
-    “bogus powerfails”. They don't seem to cause any real problems
-    so they have been ignored.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ik.4 4.html b/static/netbsd/man4/man4.vax/ik.4 4.html
deleted file mode 100644
index 2bb05a6a..00000000
--- a/static/netbsd/man4/man4.vax/ik.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
IK(4)Device Drivers Manual (vax)IK(4)

-

-

-

-
ik — Ikonas frame
-    buffer, graphics device interface

-

-

-

-
ik0 at uba? csr 0172460 vector ikintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ik driver provides an interface to an
-    Ikonas frame buffer graphics device. Each minor device is a different frame
-    buffer interface board. When the device is opened, its interface registers
-    are mapped, via virtual memory, into the user processes address space. This
-    allows the user process very high bandwidth to the frame buffer with no
-    system call overhead.

-
Bytes written or read from the device are DMA'ed from or to the
-    interface. The frame buffer XY address, its addressing mode, etc. must be
-    set up by the user process before calling write or read.

-
Other communication with the driver is via ioctls. The
-    IK_GETADDR ioctl(2) returns the
-    virtual address where the user process can find the interface registers. The
-    IK_WAITINT ioctl(2) suspends the
-    user process until the ikonas device has interrupted (for whatever reason
-    — the user process has to set the interrupt enables).

-

-

-

-

-  
/dev/ik

-  
 

-

-

-

-

-
None.

-

-

-

-
The ik driver appeared in
-    4.2BSD.

-

-

-

-
An invalid access (e.g., longword) to a mapped interface register
-    can cause the system to crash with a machine check. A user process could
-    possibly cause infinite interrupts hence bringing things to a crawl.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/il.4 4.html b/static/netbsd/man4/man4.vax/il.4 4.html
deleted file mode 100644
index 0f32cc57..00000000
--- a/static/netbsd/man4/man4.vax/il.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
IL(4)Device Drivers Manual (vax)IL(4)

-

-

-

-
il — Interlan
-    NI1010 10 Mb/s Ethernet interface

-

-

-

-
il0 at uba0 csr 164000

-

-

-

-
The il interface provides access to a 10
-    Mb/s Ethernet network through an Interlan 1010 or 1010A controller.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    il interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-

-  
il%d: input error.

-  
The hardware indicated an error in reading a packet off the cable or an
-      illegally sized packet.

-  
il%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-  
il%d: setaddr didn't work.

-  
The interface was unable to reprogram its physical Ethernet address. This
-      may happen with very early models of the interface. This facility is used
-      only when the controller is not the first network interface configured for
-      XNS. The oldest interface tested (2.7.1.0.1.45) has never failed in this
-      way.

-  
il%d: reset failed, csr=%b.

-  

-  
il%d: status failed, csr=%b.

-  

-  
il%d: hardware diag failed, csr=%b.

-  

-  
il%d: verifying setaddr, csr=%b.

-  

-  
il%d: stray xmit interrupt, csr=%b.

-  

-  
il%d: can't initialize.

-  
The above messages indicate a probable hardware error performing the
-      indicated operation during autoconfiguration or initialization. The status
-      field in the control and status register (the low-order four bits) should
-      indicate the nature of the failure. See the hardware manual for
-    details.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4)

-

-

-

-
The il interface appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/intro.4 3.html b/static/netbsd/man4/man4.vax/intro.4 3.html
deleted file mode 100644
index 74e49986..00000000
--- a/static/netbsd/man4/man4.vax/intro.4 3.html	
+++ /dev/null
@@ -1,272 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (vax)INTRO(4)

-

-

-

-
intro —
-    introduction to vax special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-

-

-

-
This section describes the hardware supported on the DEC VAX-11.
-    Software support for these devices comes in two forms. A hardware device may
-    be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see physio(4)
-    and mknod(8). Network interfaces are indirectly accessed
-    through the interprocess communication facilities provided by the system;
-    see socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device on either the UNIBUS (or
-    Q-bus) or MASSBUS and, if found, enable the software support for it. If a
-    UNIBUS device does not respond at autoconfiguration time it is not
-    accessible at any time afterwards. To enable a UNIBUS device which did not
-    autoconfigure, the system will have to be rebooted. If a MASSBUS device
-    comes “on-line” after the autoconfiguration sequence it will
-    be dynamically autoconfigured into the running system.

-
The autoconfiguration system is described in
-    vax/autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), netintro(4),
-    vax/autoconf(4)

-
Building 4.3 BSD UNIX Systems
-    with Config, SMM,
-    2.

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Pseudo-devices are not listed. Devices are indicated by their
-    functional interface. If second vendor products provide functionally
-    identical interfaces they should be usable with the supplied software.

-
Beware, however, that we promise the software works ONLY with
-  the hardware indicated on the appropriate manual page.

-Occasionally, new devices of a similar type may be added simply by creating
-  appropriate table entries in the driver.
-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
accACC LH/DH IMP communications interface
adData translation A/D interface
cssDEC IMP-11A communications interface
crlVAX-8600, 8650 console RL02 disk
ctC/A/T or APS phototypesetter
ddnACC ACP625 DDN Standard Mode X.25 IMP interface
deDEC DEUNA 10Mb/s Ethernet controller
dhDH-11 emulators, terminal multiplexor
dhuDHU-11 terminal multiplexor
dmcDEC DMC-11/DMR-11 point-to-point communications device
dmfDEC DMF-32 terminal multiplexor and parallel printer interface
dmzDEC DMZ-32 terminal multiplexor
dnDEC DN-11 autodialer interface
dzDZ-11 terminal multiplexor
ec3Com 10Mb/s Ethernet controller
enXerox 3Mb/s Ethernet controller (obsolete)
exExcelan 10Mb/s Ethernet controller
flVAX-11/780 console floppy interface
hdhACC IF-11/HDH IMP interface
hkRK6-11/RK06 and RK07 moving head disk
hpMASSBUS disk interface (with RP06, RM03, RM05, etc.)
htTM03 MASSBUS tape drive interface (with TE-16, TU-45, TU-77)
hyDR-11B or GI-13 interface to an NSC Hyperchannel
ikIkonas frame buffer graphics device interface
ilInterlan 1010, 1010A 10Mb/s Ethernet controller
ixInterlan NP-100 10Mb/s Ethernet controller
kgKL-11/DL-11W line clock
lpLP-11 parallel line printer interface
mtTM78 MASSBUS tape drive interface
npInterlan NP-100 10Mb/s Ethernet controller (intelligent mode)
pclDEC PCL-11 communications interface
psEvans and Sutherland Picture System 2 graphics interface
qeDEC DEQNA Q-bus 10 Mb/s Ethernet interface
rxDEC RX02 floppy interface
tmTM-11/TE-10 tape drive interface
tmscpTMSCP-compatible tape controllers (e.g., TU81, TK50)
tsTS-11 tape drive interface
tuVAX-11/730 TU-58 console cassette interface
udaDEC UDA-50 disk controller
unDR-11W interface to Ungermann-Bass
upEmulex SC-21V, SC-31 UNIBUS disk controller
utUNIBUS TU-45 tape drive interface
uuTU-58 dual cassette drive interface (DL-11)
vaBenson-Varian printer/plotter interface
vpVersatec printer/plotter interface
vvProteon proNET 10Mb/s and 80Mb/s ring network interface

-

-

-

-
The section 4 intro appeared in
-    4.1BSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ix.4 3.html b/static/netbsd/man4/man4.vax/ix.4 3.html
deleted file mode 100644
index ab251e82..00000000
--- a/static/netbsd/man4/man4.vax/ix.4 3.html	
+++ /dev/null
@@ -1,91 +0,0 @@
-
-  
-    
-    
-    
-  
-
IX(4)Device Drivers Manual (vax)IX(4)

-

-

-

-
ix — Interlan
-    Np100 10 Mb/s Ethernet interface

-

-

-

-
np0 at uba0 csr 166000 vector npintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ix interface provides access to a 10
-    Mb/s Ethernet network through an Interlan Np100 controller used as a
-    link-layer interface.

-
This interface is unusual in that it requires loading firmware
-    into the controller before it may be used as a network interface. This is
-    accomplished by opening a character special device, and writing data to it.
-    A program to load the image is provided in
-    /usr/src/new/np100. The sequence of commands would
-    be:

-

-
# ./npload np.image [/dev/np<board #> if other than np00]
-# sleep 10
-# ifconfig ix0 ...

-

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    ix interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-

-  
ix%d: Req failed, cmd %x, stat %x, ust error %x,%x.

-  
The firmware in the controller refused to honor a request from
-      UNIX in initializing packet level communications.
-      The board may need to be reset and reloaded. Or, you may not have allowed
-      enough time between loading the board and issuing the request to begin
-      UNIX network operation.

-  
ix%d: can't initialize.

-  
The interface was unable to obtain UNIBUS resources required for
-      operation.

-  
ix%d: failed to reinitialize DLA module.

-  
The interface got sick after attempting to reprogram its physical Ethernet
-      address. Try reloading the firmware. The attempt is made only when this
-      interfaces is not the first one configured for XNS.

-  
ix%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-  
ix%d: stray xmit interrupt, npreq=%x.

-  
This may happen if the board is reloaded while network processes are still
-      running.

-  
ixrint: cqe error %x, %x, %x.

-  
This will result if an ifconfig(8) request is made at an
-      inopportune time, such as not allowing enough time after loading the
-      firmware. After 100 such errors are logged, the
-      UNIX network driver will shut itself down,
-    saying:

-  
ixrint: shutting down unix dla.

-  
The recourse is to reload the firmware and allow more time.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4), vax/np(4)

-

-

-

-
The ix driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
February 5, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/kg.4 4.html b/static/netbsd/man4/man4.vax/kg.4 4.html
deleted file mode 100644
index 486f5111..00000000
--- a/static/netbsd/man4/man4.vax/kg.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
KG(4)Device Drivers Manual (vax)KG(4)

-

-

-

-
kg — KL-11/DL-11W
-    line clock

-

-

-

-
kg0 at uba0 csr 0176500 vector kglock

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
A KL-11 or DL-11W can be used as an alternative real time clock
-    source. When configured, certain system statistics and, optionally, system
-    profiling work will be collected each time the clock interrupts. For optimum
-    accuracy in profiling, the DL-11W should be configured to interrupt at the
-    highest possible priority level. The kg device
-    driver automatically calibrates itself to the line clock frequency.

-

-

-

-
config(1), kgmon(8)

-

-

-

-
The kg driver appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/lp.4 4.html b/static/netbsd/man4/man4.vax/lp.4 4.html
deleted file mode 100644
index 21d70842..00000000
--- a/static/netbsd/man4/man4.vax/lp.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
LP(4)Device Drivers Manual (vax)LP(4)

-

-

-

-
lp — parallel line
-    printer

-

-

-

-
lp0 at uba0 csr 0177514 vector lpintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The lp device supports DEC and DEC
-    compatible printers on the LP-11 parallel interface.

-
The unit number of the printer is specified by the minor device
-    after removing the low 3 bits, which act as per-device parameters. Currently
-    only the lowest of the low three bits is interpreted: if it is set, the
-    device is assumed to have a 64-character set or half-ASCII mode, rather than
-    a full 96-character set.

-
If the 64-character set is assumed, any lower case characters are
-    mapped to upper case; left curly and right curly braces are mapped to left
-    and right parentheses over laid with a hyphen; grave accents are mapped to
-    acute accents with overlaid with a hyphen; the pipe bar character is mapped
-    to an exclamation sign overlaid with a hyphen; and the tilde character is
-    mapped to a carat overlaid with a hyphen.

-
The default page width is 132 columns; longer lines are truncated.
-    This may be overridden by specifying, for example,
-    ‘flags 256’.

-

-

-

-

-  
/dev/lp

-  
 

-

-

-

-

-
vax/lpr(1)

-

-

-

-
A lp driver appeared in
-    Version 6 AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/mem.4 4.html b/static/netbsd/man4/man4.vax/mem.4 4.html
deleted file mode 100644
index eb1e1f86..00000000
--- a/static/netbsd/man4/man4.vax/mem.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (vax)MEM(4)

-

-

-

-
mem, kmem,
-    kUmem — memory
-  files

-

-

-

-
The special file /dev/mem is an interface
-    to the physical memory of the computer. Byte offsets in this file are
-    interpreted as physical memory addresses. Reading and writing this file is
-    equivalent to reading and writing memory itself. Only offsets within the
-    bounds of /dev/mem are allowed.

-
Kernel virtual memory is accessed through the interface
-    /dev/kmem in the same manner as
-    /dev/mem. Only kernel virtual addresses that are
-    currently mapped to memory are allowed.

-
The file /dev/kUmem also refers to kernel
-    virtual memory, but may be used to access areas mapped to UNIBUS address
-    space and other I/O areas. It forces all accesses to use word (short
-    integer) accesses.

-
On the VAX-11/780, the I/O space base address is 20000000(16); on
-    an 11/750 the I/O space addresses are of the form fxxxxx(16). On all VAX'en
-    the per-process data size for the current process is
-    UPAGES long and ends at the virtual address
-    80000000(16).

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-  
/dev/kUmem

-  
 

-

-

-

-

-
The mem, kmem
-    files appeared in Version 6 AT&T UNIX.
-    The file kUmem appeared in
-    3.0BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/mt.4 4.html b/static/netbsd/man4/man4.vax/mt.4 4.html
deleted file mode 100644
index c64c21ba..00000000
--- a/static/netbsd/man4/man4.vax/mt.4 4.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
MT(4)Device Drivers Manual (vax)MT(4)

-

-

-

-
mt — TM-78/TU-78
-    MASSBUS mag tape interface

-

-

-

-
mt0 at mba? drive ? tape mu0 at mt0 slave
-    0

-

-

-

-
The TM-78/TU-78 combination provides a standard tape drive
-    interface as described in mtio(4). Only 1600 and 6250 BPI
-    are supported; the TU-78 runs at 125 IPS and autoloads tapes.

-

-

-

-

-  
mu%d: no write ring.

-  
An attempt was made to write on the tape drive when no write ring was
-      present; this message is written on the terminal of the user who tried to
-      access the tape.

-  
mu%d: not online.

-  
An attempt was made to access the tape while it was offline; this message
-      is written on the terminal of the user who tried to access the tape.

-  
mu%d: can't change density in mid-tape.

-  
An attempt was made to write on a tape at a different density than is
-      already recorded on the tape. This message is written on the terminal of
-      the user who tried to switch the density.

-  
mu%d: hard error bn%d mbsr=%b er=%x ds=%b.

-  
A tape error occurred at block
-      ; the mt error
-      register and drive status register are printed in octal with the bits
-      symbolically decoded. Any error is fatal on non-raw tape; when possible
-      the driver will have retried the operation which failed several times
-      before reporting the error.

-  
mu%d: blank tape.

-  
An attempt was made to read a blank tape (a tape without even end-of-file
-      marks).

-  
mu%d: offline.

-  
During an i/o operation the device was set offline. If a non-raw tape was
-      used in the access it is closed.

-

-

-

-

-
mt(1), tar(1),
-    mtio(4), vax/tm(4),
-    vax/ts(4), vax/ut(4)

-

-

-

-
The mt driver appeared in
-    4.1BSD.

-

-

-

-
If a physical error (non-data) occurs, mt
-    may hang ungracefully.

-
Because 800 BPI tapes are not supported, the numbering of minor
-    devices is inconsistent with triple-density tape units. Unit 0 is drive 0,
-    1600 BPI.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/mtc.4 4.html b/static/netbsd/man4/man4.vax/mtc.4 4.html
deleted file mode 100644
index 27d62009..00000000
--- a/static/netbsd/man4/man4.vax/mtc.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
MTC(4)Device Drivers Manual (vax)MTC(4)

-

-

-

-
mtc — UNIBUS MSCP
-    tape controller driver

-

-

-

-
mtc0 at uba? csr 0174500
-  

-  mscpbus* at mtc?

-

-

-

-
The mtc driver is for UNIBUS tape
-    controllers that use MSCP. Among these controllers are:

-
    
-  
  • DEC KLESI-U UNIBUS ctlr
    • 
-  
  • DEC TK50 Q22 bus ctlr
    • 
-

-The mtc communicates with the host through a packet
-  protocol known as the Mass Storage Control Protocol (MSCP). Consult the file
-  <mscp/mscp.h> for a detailed
-  description of this protocol.
-

-

-

-
vax/intro(4)

-

-

-

-
The mtc driver appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/np.4 3.html b/static/netbsd/man4/man4.vax/np.4 3.html
deleted file mode 100644
index 41c67c91..00000000
--- a/static/netbsd/man4/man4.vax/np.4 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
NP(4)Device Drivers Manual (vax)NP(4)

-

-

-

-
np — Interlan
-    Np100 10 Mb/s Ethernet interface

-

-

-

-
np0 at uba0 csr 166000 vector npintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The np device provides access to an
-    Interlan Np100 Ethernet interface for control functions.

-
This interface is unusual in that it requires loading firmware
-    into the controller before it may be used as a network link-level interface.
-    This is accomplished by opening a character special device, and writing data
-    to it. It is also possible to do post-mortem debugging of firmware failures
-    by reading the local memory of the device.

-
Multiple control processes are allowed by opening separate minor
-    devices; secondary interfaces are specified by shifting the interface number
-    by 4 bits.

-
The device also responds to commands passed through the driver by
-    the following ioctl(2)s:

-

-  

-  
kills off all active network processes.

-  

-  
begins execution of the board at the specified address (usually
-      0x400).

-  

-  
downloads the image from a server on the network. [Contact MICOM-INTERLAN
-      for details.]

-

-

-

-

-

-  
np%d: Bad Maintenance command: %x!

-  
An invalid ioctl(2) was passed to the np driver.

-  
np%d: Panic NP100 bad buffer chain.

-  
An error occurred in an read or write operation causing it to run out of
-      buffers before it finished the operation. This indicates a kernel failure
-      rather than a device failure.

-  
NP100 unit %d not found!

-  
A failure occurred during initialization, such that the UNIBUS address
-      expected for the board was found to be bad. Probably indicates hardware
-      problems with the board, as do the following:
-    

-    
NP100 Unit %d timed out!
-NP100 Unit %d Failed diagnostics!
-Status from CSR0: %x.

-    

-  

-  
Panic from NP100 unit %d!

-  

-  
Panic Message: %s.

-  
An occurrence on the board was deemed serious enough to have the VAX print
-      it out.

-  
NP100 unit #%d available!

-  
The board was successfully loaded and started.

-  
np%d: Bad Req: %x.

-  
The board made a maintenance request to the VAX that it did not
-      understand.

-  
np%d: No more room on Command Queue!

-  
The np driver allowed an internal resource to be exhausted. This should
-      never happen.

-

-
There are 110 other diagnostic messages that can be enabled by
-    setting bits in a debugging mask. Consult the driver for details.

-

-

-

-
arp(4), inet(4),
-    netintro(4), vax/ix(4)

-

-

-

-
The np driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/pcl.4 2.html b/static/netbsd/man4/man4.vax/pcl.4 2.html
deleted file mode 100644
index bef541cb..00000000
--- a/static/netbsd/man4/man4.vax/pcl.4 2.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCL(4)Device Drivers Manual (vax)PCL(4)

-

-

-

-
pcl — DEC CSS
-    PCL-11 B Network Interface

-

-

-

-
pcl0 at uba? csr 164200 vector pclxint
-    pclrint

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The pcl device provides an IP-only
-    interface to the DEC CSS PCL-11 time division multiplexed network bus. The
-    controller itself is not accessible to users.

-
The host's address is specified with the
-    SIOCSIFADDR ioctl(2). The
-    interface will not transmit or receive any data before its address is
-    defined.

-
As the PCL-11 hardware is only capable of having 15 interfaces per
-    network, a single-byte host-on-network number is used, with range [1..15] to
-    match the TDM bus addresses of the interfaces.

-
The interface currently only supports the Internet protocol family
-    and only provides “natural” (header) encapsulation.

-

-

-

-

-  
pcl%d: can't init.

-  
Insufficient UNIBUS resources existed to initialize the device. This is
-      likely to occur when the device is run on a buffered data path on an
-      11/750 and other network interfaces are also configured to use buffered
-      data paths, or when it is configured to use buffered data paths on an
-      11/730 (which has none).

-  
pcl%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-  
pcl%d: stray xmit interrupt.

-  
An interrupt occurred when no output had previously been started.

-  
pcl%d: master.

-  
The TDM bus had no station providing ``bus master'' timing signals, so
-      this interface has assumed the ``master'' role. This message should only
-      appear at most once per UNIBUS INIT on a single system. Unless there is a
-      hardware failure, only one station may be master at a time.

-  
pcl%d: send error, tcr=%b, tsr=%b.

-  
The device indicated a problem sending data on output. If a ``receiver
-      offline'' error is detected, it is not normally logged unless the option
-      PCL_TESTING has been selected, as this causes a
-      lot of console chatter when sending to a down machine. However, this
-      option is quite useful when debugging problems with the PCL
-    interfaces.

-  
pcl%d: rcv error, rcr=%b rsr=%b.

-  
The device indicated a problem receiving data on input.

-  
pcl%d: bad len=%d.

-  
An input operation resulted in a data transfer of less than 0 or more than
-      1008 bytes of data into memory (according to the word count register).
-      This should never happen as the maximum size of a PCL message has been
-      agreed upon to be 1008 bytes (same as ARPANET message).

-

-

-

-

-
inet(4), vax/intro(4)

-

-

-

-
The pcl interface appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ps.4 3.html b/static/netbsd/man4/man4.vax/ps.4 3.html
deleted file mode 100644
index 44def9bc..00000000
--- a/static/netbsd/man4/man4.vax/ps.4 3.html	
+++ /dev/null
@@ -1,120 +0,0 @@
-
-  
-    
-    
-    
-  
-
PS(4)Device Drivers Manual (vax)PS(4)

-

-

-

-
ps — Evans and
-    Sutherland Picture System 2 graphics device interface

-

-

-

-
ps0 at uba? csr 0172460 vector psclockintr
-    pssystemintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ps driver provides access to an Evans
-    and Sutherland Picture System 2 graphics device. Each minor device is a new
-    PS2. When the device is opened, its interface registers are mapped, via
-    virtual memory, into a user process's address space. This allows the user
-    process very high bandwidth to the device with no system call overhead.

-
DMA to and from the PS2 is not supported. All read and write
-    system calls will fail. All data is moved to and from the PS2 via programmed
-    I/O using the device's interface registers.

-
Commands are fed to and from the driver using the following
-    ioctl(2)s:

-

-  

-  
Returns the virtual address through which the user process can access the
-      device's interface registers.

-  

-  
Start auto refreshing the screen. The argument is an address in user space
-      where the following data resides. The first longword is a
-      count of the number of static refresh buffers. The next
-      count longwords are the addresses in refresh memory
-      where the refresh buffers lie. The driver will cycle through these refresh
-      buffers displaying them one by one on the screen.

-  

-  
Start automatically passing the display file through the matrix processor
-      and into the refresh buffer. The argument is an address in user memory
-      where the following data resides. The first longword is a
-      count of the number of display files to operate on. The
-      next count longwords are the address of these display
-      files. The final longword is the address in refresh buffer memory where
-      transformed coordinates are to be placed if the driver is not in double
-      buffer mode (see below).

-  

-  
Cause the driver to double buffer the output from the map that is going to
-      the refresh buffer. The argument is again a user space address where the
-      real arguments are stored. The first argument is the starting address of
-      refresh memory where the two double buffers are located. The second
-      argument is the length of each double buffer. The refresh mechanism
-      displays the current double buffer, in addition to its static refresh
-      lists, when in double buffer mode.

-  

-  
Single step the refresh process. That is, the driver does not continually
-      refresh the screen.

-  

-  
Single step the matrix process. The driver does not automatically feed
-      display files through the matrix unit.

-  

-  
Turn off double buffering.

-  

-  
The argument is a count of the number of refresh interrupts to take before
-      turning off the screen. This is used to do time exposures.

-  

-  
Suspend the user process until a refresh interrupt has occurred. If in
-      TIMEREFRESH mode, suspend until count refreshes
-      have occurred.

-  

-  
Wait for the next refresh, stop all refreshes, and then return to user
-      process.

-  

-  
Wait until a map done interrupt has occurred.

-  

-  
Wait for a map done interrupt, do not restart the map, and then return to
-      the user.

-

-

-

-

-

-  
/dev/ps

-  
 

-

-

-

-

-

-  
ps device intr.

-  

-  
ps DMA intr.

-  
An interrupt was received from the device. This shouldn't happen, check
-      your device configuration for overlapping interrupt vectors.

-

-

-

-

-
The ps driver appeared in
-    4.2BSD.

-

-

-

-
An invalid access (e.g., longword) to a mapped interface register
-    can cause the system to crash with a machine check. A user process could
-    possibly cause infinite interrupts hence bringing things to a crawl.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/qe.4 4.html b/static/netbsd/man4/man4.vax/qe.4 4.html
deleted file mode 100644
index 70fba448..00000000
--- a/static/netbsd/man4/man4.vax/qe.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
QE(4)Device Drivers Manual (vax)QE(4)

-

-

-

-
qe — DEC
-    DEQNA/DELQA Q-bus 10 Mb/s Ethernet interface

-

-

-

-
qe0 at uba? csr 174440
-  

-  qe1 at uba? csr 174460

-

-

-

-
The qe interface provides access to a 10
-    Mb/s Ethernet network through the DEC DEQNA or DELQA Q-bus controller.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    qe interface employs the address resolution protocol
-    described in arp(4) to map dynamically between Internet
-    and Ethernet addresses on the local network.

-

-

-

-
arp(4), inet(4),
-    netintro(4)

-

-

-

-
The qe driver appeared in
-    4.3BSD.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/qt.4 4.html b/static/netbsd/man4/man4.vax/qt.4 4.html
deleted file mode 100644
index d97ee516..00000000
--- a/static/netbsd/man4/man4.vax/qt.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
QT(4)Device Drivers Manual (vax)QT(4)

-

-

-

-
qt — DEC
-    DELQA-PLUS (DELQA-YM) Q-bus 10 Mb/s Ethernet interface

-

-

-

-
qt0 at uba? csr 174440
-  

-  qt1 at uba? csr 174460

-

-

-

-
The qt interface provides access to a 10
-    Mb/s Ethernet network through a DEC DELQA-YM Q-bus controller.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    qt interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-

-  
qt%d: chained packet.

-  
A packet received from the network was longer than the allowed max length
-      and is therefore discarded. This is usually because a host on the local
-      network is behaving badly.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4)

-

-

-

-
The qt driver first appeared in
-    2.11BSD. It was later ported to
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
August 30, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/rf.4 4.html b/static/netbsd/man4/man4.vax/rf.4 4.html
deleted file mode 100644
index 4bc37afd..00000000
--- a/static/netbsd/man4/man4.vax/rf.4 4.html	
+++ /dev/null
@@ -1,146 +0,0 @@
-
-  
-    
-    
-    
-  
-
RF(4)Device Drivers Manual (vax)RF(4)

-

-

-

-
rf — DEC RX01 /
-    RX02 floppy disk interface

-

-

-

-
rfc0 at uba? csr 0177170 # RX01/RX02
-    controller
-  

-  rf* at rfc? drive? # RX01/RX02 floppy disk drive

-

-

-

-
The rf device provides access to DEC RX01
-    and RX02 floppy disk drives and clones thereof. These drives use
-    preformatted 8" single sided, soft sectored media. The RX01 and RX02
-    drives use a geometry of 77 cylinders, one head and 26 sectors. Each sector
-    contains 128 bytes in case of single density ( RX01 and RX02 in RX01 mode)
-    or 256 bytes in double density mode. As NetBSD is
-    not able to handle non-512 byte media the driver translates this to a
-    geometry of 50 cylinders, one head and 10 sectors in single density and 77
-    cylinders, one head and 13 sectors in double density mode. While the later
-    matches the total number of sectors, the fake geometry in single density
-    does not cover the last two physical sectors exact, but it is possible to
-    access this sectors at 512 byte LBN 501. When a 512 byte block is written to
-    LBN 501 the last 256 bytes are ignored. When this 512 byte block is read the
-    last 256 bytes contain undefined data.

-
This driver supports three minor devices corresponding to the
-    slices:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Description
aSingle density only mode.
bDouble density only mode.
cDensity autodetect.

-As the RX01 and RX02 hardware is not able to support formatting a blank disk,
-  this driver has no support for according IOCTLs. But there are clones from
-  third party vendors that support formatting. Formatting a blank disk may be
-  initiated by the following commands on the VAX chevron prompt:
-
-  
-    
-  
-  
-    
-  
-  
-    
-  
-
Single density
d/p/w 20001E78 9
d/p/w 20001E7A 92

-
-  
-    
-  
-  
-    
-  
-  
-    
-  
-
Double density
d/p/w 20001E78 109
d/p/w 20001E7A 92

-

-

-

-

-  
/dev/rf?[abc]

-  
 

-  
/dev/rrf?[abc]

-  
 

-

-

-

-

-

-  
rfc_attach: Error creating bus_dma map: %d

-  

-  
did not respond to INIT CMD

-  
Possible errors during vax/autoconf(4). %d is the return
-      code of bus_dmamap_create(9).

-  
%s: did not respond to CMD %x

-  
An error occurred while the driver tried to send command %x to drive
-    %s.

-  
rfc_intr: Error while reading sector: %x

-  

-  
rfc_intr: Error while writing sector: %x

-  

-  
rfc_intr: Error while DMA: %x

-  
%x is status code from the controller error and status register.

-  
rfc_intr: Error while loading bus_dma map: %d

-  
%d is return code of bus_dmamap_load(9).

-  
%s: density error.

-  
A single density disk was opened in double density only mode or vice versa
-      or the medium in the drive attached as %s was not readable at all.

-

-

-

-

-
dd(1), tar(1),
-    vax/intro(4), disklabel(5),
-    disklabel(8), mknod(8),
-    mount(8), newfs(8)

-

-

-

-
The rf driver appeared in NetBSD 2.0. It
-    is a complete rewrite, not related to the old 4.2BSD
-    rx driver.

-

-

-

-
Jochen Kunz

-

-

-

-
Writing of a disklabel(5) is not supported. The
-    driver return always the internally fake disklabel.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/rl.4 4.html b/static/netbsd/man4/man4.vax/rl.4 4.html
deleted file mode 100644
index a665013b..00000000
--- a/static/netbsd/man4/man4.vax/rl.4 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
RL(4)Device Drivers Manual (vax)RL(4)

-

-

-

-
rl — RL11/ RL01
-    and RL02 disk interface

-

-

-

-
rlc0 at uba? csr 0177440
-  

-  rl0 at rlc0 drive 0
-  

-  rl* at rlc? drive ?

-

-

-

-
The rl driver is a typical block-device
-    disk driver; block device I/O is described in
-  physio(4).

-
The script MAKEDEV(8) should be used to create
-    the special files; if a special file needs to be created by hand consult
-    mknod(8).

-

-

-

-

-  
/dev/rl[0-7][a-h]

-  
block files

-  
/dev/rrl[0-7][a-h]

-  
raw files

-

-

-

-

-

-  
rl%d: operation incomplete

-  
The current command to the disk did not complete within the timeout
-      period. This may be due to hardware failure or a heavily loaded
-    UNIBUS.

-  
rl%d: read data CRC

-  
The controller detected a CRC error on data read from the disk. Probably a
-      bad disk pack.

-  
rl%d: header CRC

-  
The controller detected a CRC error on header data read from the disk.
-      Probably a bad disk pack.

-  
rl%d: data late

-  
The controller was not able to transfer data over the bus fast enough to
-      not overflow/underflow the internal FIFO, probably because a heavily
-      loaded UNIBUS or mis-ordered UNIBUS devices.

-  
rl%d: header not found

-  
The requested sector was not found before the timer expired. If this error
-      is the only error then it may indicate a software bug.

-  
rl%d: non-existent memory

-  
The controller tried to do DMA to/from a non-mapped address. This is a
-      software bug.

-  
rl%d: memory parity error

-  
The host memory data sent had a parity error. This is a hardware
-    failure.

-

-

-

-

-
vax/hp(4), vax/uda(4),
-    vax/up(4), syslogd(8)

-

-

-

-
The rl driver has been around nearly
-    forever.

-
A complete new rl driver showed up in
-    NetBSD 1.5.

-

-

-

-
Error handling is less than optimal.

-
Seeks should be interleaved between multiple disks.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/tm.4 4.html b/static/netbsd/man4/man4.vax/tm.4 4.html
deleted file mode 100644
index f0264583..00000000
--- a/static/netbsd/man4/man4.vax/tm.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
TM(4)Device Drivers Manual (vax)TM(4)

-

-

-

-
tm — TM-11/TE-10
-    mag tape device interface

-

-

-

-

-    

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The TM-11/TE-10 combination provides a standard tape drive
-    interface as described in vax/mtio(4). Hardware
-    implementing this on the VAX is typified by the Emulex TC-11 controller
-    operating with a Kennedy model 9300 tape transport, providing 800 and 1600
-    BPI operation at 125 IPS.

-

-

-

-

-  
te%d: no write ring.

-  
An attempt was made to write on the tape drive when no write ring was
-      present; this message is written on the terminal of the user who tried to
-      access the tape.

-  
te%d: not online.

-  
An attempt was made to access the tape while it was offline; this message
-      is written on the terminal of the user who tried to access the tape.

-  
te%d: can't change density in mid-tape.

-  
An attempt was made to write on a tape at a different density than is
-      already recorded on the tape. This message is written on the terminal of
-      the user who tried to switch the density.

-  
te%d: hard error bn%d er=%b.

-  
A tape error occurred at block
-      ; the tm error
-      register is printed in octal with the bits symbolically decoded. Any error
-      is fatal on non-raw tape; when possible the driver will have retried the
-      operation which failed several times before reporting the error.

-  
te%d: lost interrupt.

-  
A tape operation did not complete within a reasonable time, most likely
-      because the tape was taken off-line during rewind or lost vacuum. The
-      controller should, but does not, give an interrupt in these cases. The
-      device will be made available again after this message, but any current
-      open reference to the device will return an error as the operation in
-      progress aborts.

-

-

-

-

-
tar(1), vax/mt(1),
-    vax/ht(4), vax/mt(4),
-    vax/mtio(4), vax/ts(4),
-    vax/ut(4)

-

-

-

-
A tm driver appeared in
-    Version 6 AT&T UNIX.

-

-

-

-
May hang if a physical (non-data) error occurs.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ts.4 4.html b/static/netbsd/man4/man4.vax/ts.4 4.html
deleted file mode 100644
index 3741eec5..00000000
--- a/static/netbsd/man4/man4.vax/ts.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
TS(4)Device Drivers Manual (vax)TS(4)

-

-

-

-
ts — TS-11/TSV-05
-    mag tape interface

-

-

-

-
ts0 at uba? csr 0172520

-

-

-

-
The TS-11/TSV-05 combination provides a standard tape drive
-    interface as described in vax/mtio(4). The TS-11 operates
-    only at 1600 BPI, and only one transport is possible per controller.

-
The TS-11 is attached to an UNIBUS, and the TSV-05 is attached to
-    a Q22 bus.

-

-

-

-

-  
ts%d: no write ring.

-  
An attempt was made to write on the tape drive when no write ring was
-      present; this message is written on the terminal of the user who tried to
-      access the tape.

-  
ts%d: not online.

-  
An attempt was made to access the tape while it was offline; this message
-      is written on the terminal of the user who tried to access the tape.

-  
ts%d: error at bn%d.

-  
An error occurred on the tape at block
-      ; status register
-      and controller state is printed in hex and decimal.

-

-

-

-

-
tar(1), vax/mt(1),
-    vax/ht(4), vax/mt(4),
-    vax/mtio(4), vax/tm(4),
-    vax/ut(4)

-

-

-

-
The ts driver appeared in
-    4.1BSD.

-
A new ts driver showed up in
-    NetBSD 1.2.

-

-

-

-
Lots of them.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/tu.4 3.html b/static/netbsd/man4/man4.vax/tu.4 3.html
deleted file mode 100644
index c6313b14..00000000
--- a/static/netbsd/man4/man4.vax/tu.4 3.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
TU(4)Device Drivers Manual (vax)TU(4)

-

-

-

-
tu — VAX-11/750
-    TU-58 console cassette interface

-

-

-

-
The tu interface provides access to the
-    VAX-11/750 TU-58 console cassette drive.

-
The interface supports only block I/O to the TU-58 cassettes. The
-    devices are normally manipulated with the dd(1)
-  program.

-
The device driver is automatically included when a system is
-    configured to run on an 11/750.

-
The TU-58 on an 11/750 uses the Radial Serial Protocol (RSP) to
-    communicate with the cpu over a serial line. This protocol is inherently
-    unreliable as it has no flow control measures built in.

-

-

-

-

-  
/dev/tu0

-  
 

-

-

-

-

-

-  
tu%d: lost recv interrupt.

-  
A timer watching the controller detected no interrupt for an extended
-      period while an operation was outstanding. This usually indicates that one
-      or more receiver interrupts were lost and the transfer is restarted.

-

-

-

-

-
The tu driver appeared in
-    4.1BSD.
-  

-  A new driver showed up in NetBSD 1.2.

-

-

-

-
The VAX-11/750 console interface is unusable while the system is
-    multi-user, because interrupts occur at a very high priority level (spl7)
-    and cannot be blocked with splbio. Use this driver only when the system is
-    running single-user and, even then, with caution.

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/uda.4 4.html b/static/netbsd/man4/man4.vax/uda.4 4.html
deleted file mode 100644
index 795bd42c..00000000
--- a/static/netbsd/man4/man4.vax/uda.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
UDA(4)Device Drivers Manual (vax)UDA(4)

-

-

-

-
uda — UNIBUS MSCP
-    disk controller driver

-

-

-

-
uda0 at uba? csr 0172150
-  

-  uda1 at uba? csr 0160334
-  

-  mscpbus* at uda?

-

-

-

-
The uda driver is for UNIBUS disk
-    controllers that use MSCP. Among these controllers are:

-

-

-

-  
DEC UDA50 UNIBUS ctlr

-  
 

-  
DEC KDA50 Q22 bus ctlr

-  
 

-  
DEC RQDX3 Q22 bus ctlr

-  
 

-

-

-
The uda communicates with the host through
-    a packet protocol known as the Mass Storage Control Protocol (MSCP). Consult
-    the file <mscp/mscp.h> for a
-    detailed description of this protocol.

-

-

-

-
vax/intro(4)

-

-

-

-
The uda driver appeared in
-    4.2BSD.

-
A new uda driver approach showed up in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/up.4 4.html b/static/netbsd/man4/man4.vax/up.4 4.html
deleted file mode 100644
index 0fb05554..00000000
--- a/static/netbsd/man4/man4.vax/up.4 4.html	
+++ /dev/null
@@ -1,528 +0,0 @@
-
-  
-    
-    
-    
-  
-
UP(4)Device Drivers Manual (vax)UP(4)

-

-

-

-
up — UNIBUS
-    storage module controller/disk drives

-

-

-

-
sc0 at uba? csr 0176700 vector upintr
-  

-  up0 at sc0 drive 0

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
This is a generic UNIBUS storage module disk driver. It is
-    specifically designed to work with the Emulex SC-21 and SC-31 controllers.
-    It can be easily adapted to other controllers (although bootstrapping will
-    not necessarily be directly possible.)

-
The script MAKEDEV(8) should be used to create
-    the up special files; consult
-    mknod(8) if a special file needs to be made manually. It
-    is recommended as a security precaution to not create special files for
-    devices which may never be installed.

-

-

-

-
The driver interrogates the controller's holding register to
-    determine the type of drive attached. The driver recognizes seven different
-    drives: CDC 9762, CDC 9766, AMPEX DM980, AMPEX 9300, AMPEX Capricorn,
-    FUJITSU 160, and FUJITSU Eagle (the Eagle is not supported by the
-  SC-21).

-
Special file names begin with
-    ‘up’ and
-    ‘rup’ for the block and character
-    files respectively. The second component of the name, a drive unit number in
-    the range of zero to seven, is represented by a
-    ‘?’ in the disk layouts below. The
-    last component of the name, the file system partition, is designated by a
-    letter from ‘a’ to
-    ‘h’ which also corresponds to a minor
-    device number set: zero to seven, eight to 15, 16 to 23 and so forth for
-    drive zero, drive two and drive three respectively (see
-    physio(4)). The location and size (in 512 byte sectors) of
-    the partitions for the above drives:

-

-  
CDC 9762 partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyls
hp?a0158840-99
hp?b1600033440100-309
hp?c01316800-822
hp?d4960015884309-408
hp?e6544055936409-758
hp?f12144010080759-822
hp?g4960082080309-822

-  

-  
CDC 9766 300M drive partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyl
up?a0158840-26
up?b164163344027-81
up?c05003840-822
up?d34169615884562-588
up?e35811255936589-680
up?f414048861760681-822
up?g341696158528562-822
up?h4985629134682-561

-  

-  
AMPEX DM980 partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyls
hp?a0158840-99
hp?b1600033440100-309
hp?c01316800-822
hp?d4960015884309-408
hp?e6544055936409-758
hp?f12144010080759-822
hp?g4960082080309-822

-  

-  
AMPEX 9300 300M drive partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyl
up?a0158840-26
up?b164163344027-81
up?c04955200-814
up?d34169615884562-588
up?e35811255936589-680
up?f41404881312681-814
up?g341696153664562-814
up?h4985629134682-561

-  

-  
AMPEX Capricorn 330M drive partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyl
hp?a0158840-31
hp?b163843344032-97
hp?c05242880-1023
hp?d34201615884668-699
hp?e35840055936700-809
hp?f414720109408810-1023
hp?g342016182112668-1023
hp?h5017629134698-667

-  

-  
FUJITSU 160M drive partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyl
up?a0158840-49
up?b160003344050-154
up?c02633600-822
up?d4960015884155-204
up?e6560055936205-379
up?f121600141600380-822
up?g49600213600155-822

-  

-  
FUJITSU Eagle partitions

-  

-    
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-      
-        
-        
-        
-        
-      
-    
startlengthcyls
hp?a0158840-16
hp?b163206688017-86
hp?c08083200-841
hp?d37536015884391-407
hp?e39168055936408-727
hp?f698880109248728-841
hp?g375360432768391-841
hp?h8352029134687-390

-  

-

-
The up?a partition is normally used for the root file system, the
-    up?b partition as a paging area, and the up?c partition for pack-pack
-    copying (it maps the entire disk). On 160M drives the up?g partition maps
-    the rest of the pack. On other drives both up?g and up?h are used to map the
-    remaining cylinders.

-

-

-

-

-  
/dev/up[0-7][a-h]

-  
block files

-  
/dev/rup[0-7][a-h]

-  
raw files

-

-

-

-

-

-  
up%d%c: hard error %sing fsbn %d[-%d] cs2=%b er1=%b er2=%b.

-  
An unrecoverable error occurred during transfer of the specified
-      filesystem block number(s), which are logical block numbers on the
-      indicated partition. The contents of the cs2, er1 and er2 registers are
-      printed in octal and symbolically with bits decoded. The error was either
-      unrecoverable, or a large number of retry attempts (including offset
-      positioning and drive recalibration) could not recover the error.

-  
up%d: write locked.

-  
The write protect switch was set on the drive when a write was attempted.
-      The write operation is not recoverable.

-  
up%d: not ready.

-  
The drive was spun down or off line when it was accessed. The I/O
-      operation is not recoverable.

-  
up%d: not ready (flakey).

-  
The drive was not ready, but after printing the message about being not
-      ready (which takes a fraction of a second) was ready. The operation is
-      recovered if no further errors occur.

-  
up%d%c: soft ecc reading fsbn %d[-%d].

-  
A recoverable ECC error occurred on the specified sector of the specified
-      disk partition. This happens normally a few times a week. If it happens
-      more frequently than this the sectors where the errors are occurring
-      should be checked to see if certain cylinders on the pack, spots on the
-      carriage of the drive or heads are indicated.

-  
sc%d: lost interrupt.

-  
A timer watching the controller detecting no interrupt for an extended
-      period while an operation was outstanding. This indicates a hardware or
-      software failure. There is currently a hardware/software problem with
-      spinning down drives while they are being accessed which causes this error
-      to occur. The error causes a UNIBUS reset, and retry of the pending
-      operations. If the controller continues to lose interrupts, this error
-      will recur a few seconds later.

-

-

-

-

-
vax/hk(4), vax/hp(4),
-    vax/uda(4)

-

-

-

-
The up driver appeared in
-    4.0BSD.

-

-

-

-
A program to analyze the logged error information (even in its
-    present reduced form) is needed.

-
The partition tables for the file systems should be read off of
-    each pack, as they are never quite what any single installation would
-    prefer, and this would make packs more portable.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/ut.4 4.html b/static/netbsd/man4/man4.vax/ut.4 4.html
deleted file mode 100644
index 6ffc602b..00000000
--- a/static/netbsd/man4/man4.vax/ut.4 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
UT(4)Device Drivers Manual (vax)UT(4)

-

-

-

-
ut — UNIBUS TU45
-    tri-density tape drive interface

-

-

-

-
ut0 at uba0 csr 0172440 vector utintr
-  

-  tj0 at ut0 drive 0

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The ut interface provides access to a
-    standard tape drive interface as describe in vax/mtio(4).
-    Hardware implementing this on the VAX is typified by the System Industries
-    SI 9700 tape subsystem. Tapes may be read or written at 800, 1600, and 6250
-    BPI.

-

-

-

-

-  
tj%d: no write ring.

-  
An attempt was made to write on the tape drive when no write ring was
-      present; this message is written on the terminal of the user who tried to
-      access the tape.

-  
tj%d: not online.

-  
An attempt was made to access the tape while it was offline; this message
-      is written on the terminal of the user who tried to access the tape.

-  
tj%d: can't change density in mid-tape.

-  
An attempt was made to write on a tape at a different density than is
-      already recorded on the tape. This message is written on the terminal of
-      the user who tried to switch the density.

-  
ut%d: soft error bn%d cs1=%b er=%b cs2=%b ds=%b.

-  
The formatter indicated a corrected error at a density other than 800bpi.
-      The data transferred is assumed to be correct.

-  
ut%d: hard error bn%d cs1=%b er=%b cs2=%b ds=%b.

-  
A tape error occurred at block

-  
bn.

-  
Any error is fatal on non-raw tape; when possible the driver will have
-      retried the operation which failed several times before reporting the
-      error.

-  
tj%d: lost interrupt.

-  
A tape operation did not complete within a reasonable time, most likely
-      because the tape was taken off-line during rewind or lost vacuum. The
-      controller should, but does not, give an interrupt in these cases. The
-      device will be made available again after this message, but any current
-      open reference to the device will return an error as the operation in
-      progress aborts.

-

-

-

-

-
vax/mt(1), vax/mtio(4)

-

-

-

-
The ut driver appeared in
-    4.2BSD.

-

-

-

-
May hang if a physical error (non-data) occurs.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/uu.4 4.html b/static/netbsd/man4/man4.vax/uu.4 4.html
deleted file mode 100644
index 7c6712f9..00000000
--- a/static/netbsd/man4/man4.vax/uu.4 4.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
UU(4)Device Drivers Manual (vax)UU(4)

-

-

-

-
uu — TU-58/DECtape
-    II UNIBUS cassette interface

-

-

-

-
options UUDMA
-  

-  uu0 at uba0 csr 0176500 vector uurintr uuxintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The uu device provides access to dual DEC
-    TU-58 tape cartridge drives connected to the UNIBUS via a DL-11W interface
-    module.

-
The interface supports only block I/O to the TU-58 cassettes (see
-    physio(4)). The drives are normally manipulated with the
-    arff(8) program using the ``m'' and ``f'' options.

-
The driver provides for an optional write and verify (read after
-    write) mode that is activated by specifying the ``a'' device.

-
The TU-58 is treated as a single device by the system even though
-    it has two separate drives, ‘uu0’ and
-    ‘uu1’. If there is more than one TU-58
-    unit on a system, the extra drives are named
-    ‘uu2’,
-    ‘uu3’ etc.

-

-

-

-
Assembly language code to assist the driver in handling the
-    receipt of data (using a pseudo-DMA approach) should be included when using
-    this driver; specify ‘options UUDMA’
-    in the configuration file.

-

-

-

-

-  
/dev/uu?

-  
 

-  
/dev/uu?a

-  
 

-

-

-

-

-

-  
uu%d: no bp, active %d.

-  
A transmission complete interrupt was received with no outstanding I/O
-      request. This indicates a hardware problem.

-  
uu%d protocol error, state=%s, op=%x, cnt=%d, block=%d.

-  
The driver entered an illegal state. The information printed indicates the
-      illegal state, the operation currently being executed, the I/O count, and
-      the block number on the cassette.

-  
uu%d: break received, transfer restarted.

-  
The TU-58 was sending a continuous break signal and had to be reset. This
-      may indicate a hardware problem, but the driver will attempt to recover
-      from the error.

-  
uu%d receive state error, state=%s, byte=%x.

-  
The driver entered an illegal state in the receiver finite state machine.
-      The state is shown along with the control byte of the received
-    packet.

-  
uu%d: read stalled.

-  
A timer watching the controller detected no interrupt for an extended
-      period while an operation was outstanding. This usually indicates that one
-      or more receiver interrupts were lost and the transfer is restarted.

-  
uu%d: hard error bn%d, pk_mod %o.

-  
The device returned a status code indicating a hard error. The actual
-      error code is shown in octal. No retries are attempted by the driver.

-

-

-

-

-
The following errors may be returned:

-

-  
[]

-  
Nonexistent drive (on open); offset is too large or bad (undefined)
-      ioctl(2) code.

-  
[]

-  
Open failed, the device could not be reset.

-  
[]

-  
Drive in use.

-

-

-

-

-
vax/tu(4), arff(8)

-

-

-

-
The uu driver appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/va.4 4.html b/static/netbsd/man4/man4.vax/va.4 4.html
deleted file mode 100644
index e329b417..00000000
--- a/static/netbsd/man4/man4.vax/va.4 4.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
VA(4)Device Drivers Manual (vax)VA(4)

-

-

-

-
va — Benson-Varian
-    printer/plotter interface

-

-

-

-
va0 at uba0 csr 0164000 vector vaintr
-  

-  vz0 at va0 drive 0

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-

-
(NOTE: the configuration description, while
-  counter-intuitive, is actually as shown above.)

-
The Benson-Varian printer/plotter in normally used with the line
-    printer system. This description is designed for those who wish to drive the
-    Benson-Varian directly.

-
In print mode, the Benson-Varian uses a modified ASCII character
-    set. Most control characters print various non-ASCII
-    graphics such as daggers, sigmas, copyright symbols, etc. Only LF and FF are
-    used as format effectors. LF acts as a newline, advancing to the beginning
-    of the next line, and FF advances to the top of the next page.

-
In plot mode, the Benson-Varian prints one raster line at a time.
-    An entire raster line of bits (2112 bits = 264 bytes) is sent, and then the
-    Benson-Varian advances to the next raster line.

-
:
-    The Benson-Varian must be sent an even number of bytes. If an odd number is
-    sent, the last byte will be lost. Nulls can be used in print mode to pad to
-    an even number of bytes.

-
To use the Benson-Varian yourself, you must realize that you
-    cannot open the device, /dev/va0 if there is a
-    daemon active. You can see if there is an active daemon by doing a
-    vax/lpq(1) and seeing if there are any files being
-    printed. Printing should be turned off using
-  vax/lpc(8).

-
To set the Benson-Varian into plot mode include the file
-    <sys/vcmd.h> and use the
-    following ioctl(2) call

-

-
ioctl(fileno(va), VSETSTATE, plotmd);

-

-where plotmd is defined to be
-

-
int plotmd[] = { VPLOT, 0, 0 };

-

-and va is the result of a call to
-  fopen(3) on stdio. When you finish using the Benson-Varian
-  in plot mode you should advance to a new page by sending it a FF after putting
-  it back into print mode, i.e. by
-

-
int prtmd[] = { VPRINT, 0, 0 };
-...
-fflush(va);
-ioctl(fileno(va), VSETSTATE, prtmd);
-write(fileno(va), "\f\0", 2);

-

-

-

-

-

-  
/dev/va0

-  
 

-

-

-

-

-
The following error numbers are significant at the time the device
-    is opened.

-

-  
[ENXIO]

-  
The device is already in use.

-  
[EIO]

-  
The device is offline.

-

-The following message may be printed on the console.
-

-  
va%d: npr timeout.

-  
The device was not able to get data from the UNIBUS within the timeout
-      period, most likely because some other device was hogging the bus. (But
-      see BUGS below).

-

-

-

-

-
vax/lpr(1), vax/vp(4),
-    vax/lpd(8)

-

-

-

-
The va driver appeared in
-    4.0BSD.

-

-

-

-
The 1's (one's) and l's (lower-case el's) in the Benson-Varian's
-    standard character set look very similar; caution is advised.

-
The interface hardware is rumored to have problems which can play
-    havoc with the UNIBUS. We have intermittent minor problems on the UNIBUS
-    where our vax/va(4) lives, but haven't ever been able to
-    pin them down completely.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/vp.4 4.html b/static/netbsd/man4/man4.vax/vp.4 4.html
deleted file mode 100644
index 3b063a75..00000000
--- a/static/netbsd/man4/man4.vax/vp.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
VP(4)Device Drivers Manual (vax)VP(4)

-

-

-

-
vp — Versatec
-    printer/plotter interface

-

-

-

-
vp0 at uba0 csr 0177510 vector vpintr
-    vpintr

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The Versatec printer/plotter is normally used with the line
-    printer system. This description is designed for those who wish to drive the
-    Versatec directly.

-
To use the Versatec yourself, you must realize that you cannot
-    open the device, /dev/vp0 if there is a daemon
-    active. You can see if there is a daemon active by doing a
-    vax/lpq(1), and seeing if there are any files being sent.
-    Printing should be turned off using vax/lpc(8).

-
To set the Versatec into plot mode you should include
-    <sys/vcmd.h> and use the
-    ioctl(2) call

-

-
ioctl(fileno(vp), VSETSTATE, plotmd);

-

-
where
-     is defined
-    to be

-

-
int plotmd[] = { VPLOT, 0, 0 };

-

-
and
-     is the result of a
-    call to fopen(3) on stdio. When you finish using the
-    Versatec in plot mode you should eject paper by sending it a EOT after
-    putting it back into print mode, i.e. by

-

-
int prtmd[] = { VPRINT, 0, 0 };
-...
-fflush(vp);
-ioctl(fileno(vp), VSETSTATE, prtmd);
-write(fileno(vp), "\04", 1);

-

-

-

-

-

-  
/dev/vp0

-  
 

-

-

-

-

-
The following error numbers are significant at the time the device
-    is opened.

-

-  
[ENXIO]

-  
The device is already in use.

-  
[EIO]

-  
The device is offline.

-

-

-

-

-
vax/lpr(1), vax/va(4),
-    vax/lpd(8)

-

-

-

-
A vp driver appeared in
-    Version 7 AT&T UNIX.

-

-

-

-
The configuration part of the driver assumes that the device is
-    set up to vector print mode through 0174 and plot mode through 0200. As the
-    configuration program can't be sure which vector interrupted at boot time,
-    we specify that it has two interrupt vectors, and if an interrupt comes
-    through 0200 it is reset to 0174. This is safe for devices with one or two
-    vectors at these two addresses. Other configurations with 2 vectors may
-    require changes in the driver.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.vax/vv.4 4.html b/static/netbsd/man4/man4.vax/vv.4 4.html
deleted file mode 100644
index e4068952..00000000
--- a/static/netbsd/man4/man4.vax/vv.4 4.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
VV(4)Device Drivers Manual (vax)VV(4)

-

-

-

-
vv — Proteon
-    proNET 10 Megabit ring network

-

-

-

-
vv0 at uba0 csr 0161000 vector vvrint
-    vvxint

-

-

-

-
NOTE: This driver has not been ported from
-    4.4BSD yet.

-
The vv interface provides access to a 10
-    Mb/s Proteon proNET ring network.

-
The network address of the interface must be specified with an
-    SIOCSIFADDR ioctl(2) before data
-    can be transmitted or received. It is only permissible to change the network
-    address while the interface is marked “down”.

-
The host's hardware address is discovered by putting the interface
-    in digital loopback mode (not joining the ring) and sending a broadcast
-    packet from which the hardware address is extracted.

-
Transmit timeouts are detected through use of a watchdog routine.
-    Lost input interrupts are checked for when packets are sent out.

-
If the installation is running CTL boards which use the old
-    broadcast address of ‘0’ instead of
-    the new address of ‘0xff’, the define
-    OLD_BROADCAST should be specified in the driver.

-

-

-

-

-  
vv%d: host %d.

-  
The software announces the host address discovered during
-      autoconfiguration.

-  
vv%d: can't initialize.

-  
The software was unable to discover the address of this interface, so it
-      deemed "dead" will not be enabled.

-  
vv%d: error vvocsr=%b.

-  
The hardware indicated an error on the previous transmission.

-  
vv%d: output timeout.

-  
The token timer has fired and the token will be recreated.

-  
vv%d: error vvicsr=%b.

-  
The hardware indicated an error in reading a packet off the ring.

-  
vv%d: can't handle af%d.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-  
vv%d: vs_olen=%d.

-  
The ring output routine has been handed a message with a preposterous
-      length. This results in an immediate
-      .

-

-

-

-

-
inet(4), netintro(4)

-

-

-

-
The vv driver appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
February 5, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/bmd.4 4.html b/static/netbsd/man4/man4.x68k/bmd.4 4.html
deleted file mode 100644
index 29321f96..00000000
--- a/static/netbsd/man4/man4.x68k/bmd.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
BMD(4)Device Drivers Manual (x68k)BMD(4)

-

-

-

-
bmd — Nereid bank
-    memory disk driver

-

-

-

-
bmd* at intio0 addr 0xece3f0
-  

-  bmd* at intio0 addr 0xecebf0

-

-

-

-
The bmd driver provides a memory disk for
-    the Nereid bank memory space. There is no special command to configure it,
-    because bmd is not a logical disk as
-    md(4).

-

-

-

-

-  
/dev/bmd??

-  
block mode bank memory disk

-  
/dev/rbmd??

-  
raw mode bank memory disk

-

-

-

-

-
In order to use it, do as follows:

-
newfs /dev/bmd0c

-
mount /dev/bmd0c /mnt

-

-

-

-
x68k/intio(4)

-

-

-

-
bmd appeared in NetBSD
-    2.0.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/intio.4 4.html b/static/netbsd/man4/man4.x68k/intio.4 4.html
deleted file mode 100644
index a55ecfc5..00000000
--- a/static/netbsd/man4/man4.x68k/intio.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTIO(4)Device Drivers Manual (x68k)INTIO(4)

-

-

-

-
intio — X68K
-    internal I/O space driver

-

-

-

-
intio0 at mainbus0

-

-

-

-
intio is a virtual device corresponding to
-    the x68k internal I/O space.

-
Internal I/O space spans from 0xc00000 to 0xffffff of the x68k
-    physical address space, and is mapped permanently in the kernel virtual
-    space at the very early time of the kernel startup procedure.

-
intio driver manages the internal I/O
-    space of x68k.

-
    
-  
  • Address range management to avoid confliction of address space of which
-      devices probe by touching hardware port is difficult.
    • 
-  
  • Interrupt vector management.
    • 
-  
  • bus_space(9) and bus_dma(9)
-      implementation.
    • 
-  
  • Other utility functions.
    • 
-

-
intio is always required to run the
-    NetBSD kernel.

-

-

-

-
x68k/intro(4), bus_dma(9),
-    bus_space(9)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/intro.4 3.html b/static/netbsd/man4/man4.x68k/intro.4 3.html
deleted file mode 100644
index 8c9a9561..00000000
--- a/static/netbsd/man4/man4.x68k/intro.4 3.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(4)Device Drivers Manual (x68k)INTRO(4)

-

-

-

-
intro —
-    introduction to x68k special files and hardware
-    support

-

-

-

-
This section describes the special files, related driver
-    functions, and networking support available in the system. In this part of
-    the manual, the SYNOPSIS section of each configurable device gives a sample
-    specification for use in constructing a system description for the
-    config(1) program. The DIAGNOSTICS section lists messages
-    which may appear on the console and/or in the system error log
-    /var/log/messages due to errors in device operation;
-    see syslogd(8) for more information.

-
This section contains both devices which may be configured into
-    the system and network related information. The networking support is
-    introduced in netintro(4).

-

-

-

-
This section describes the hardware supported on the x68k
-    platform. Software support for these devices comes in two forms. A hardware
-    device may be supported with a character or block
-    , or it may be used within the networking subsystem and have a
-    . Block and character devices are accessed through
-    files in the file system of a special type; see mknod(8).
-    Network interfaces are indirectly accessed through the interprocess
-    communication facilities provided by the system; see
-    socket(2).

-
A hardware device is identified to the system at configuration
-    time and the appropriate device or network interface driver is then compiled
-    into the system. When the resultant system is booted, the autoconfiguration
-    facilities in the system probe for the device and, if found, enable the
-    software support for it. If a device does not respond at autoconfiguration
-    time it is not accessible at any time afterwards. To enable a device which
-    did not autoconfigure, the system will have to be rebooted.

-
The autoconfiguration system is described in
-    autoconf(4). A list of the supported devices is given
-    below.

-

-

-

-
config(1), autoconf(4),
-    x68k/intio(4), x68k/mfp(4),
-    x68k/neptune(4), x68k/vs(4)

-

-

-

-
The devices listed below are supported in this incarnation of the
-    system. Devices are indicated by their functional interface. Not all
-    supported devices are listed.

-

-

-  

-  
Internal I/O virtual device

-  

-  
MC68901 MFP (Multi-Function Peripheral)

-  

-  
Sharp genuine MB89352 SCSI host adaptor

-  

-  
MK-HA1 Mankai-Seisakusho Mach-2 SCSI host adaptor

-  

-  
Neptune-X Ethernet interface

-  

-  
Built-in floppy disk controller device

-  

-  
Floppy disk device

-  

-  
Built-in frame buffer

-  

-  
kernel virtual memory

-  

-  
x68k Internal Terminal Emulator

-  

-  
physical memory

-  

-  
Centronics printer interface

-  

-  
NS16450 serial interface

-  

-  
Z8530 built-in serial interface

-  

-  
x68k Keyboard device

-  

-  
x68k mouse / trackball

-  

-  
The keyboard bell emulator

-  

-  
The power switch

-  

-  
MSM6258V built-in voice synthesizer

-

-

-

-

-

-
The x68k intro man page first appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/mfp.4 4.html b/static/netbsd/man4/man4.x68k/mfp.4 4.html
deleted file mode 100644
index b161289d..00000000
--- a/static/netbsd/man4/man4.x68k/mfp.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
MFP(4)Device Drivers Manual (x68k)MFP(4)

-

-

-

-
mfp — X68K
-    Multi-function Peripherals

-

-

-

-
mfp0 at intio0 addr 0xe88000 size 0x2000 intr
-    64

-

-

-

-
mfp drives Motorola MC68901 MFP
-    (Multi-function Peripheral). mfp driver is always
-    required to run the NetBSD/x68k kernel, because it
-    is connected to important devices such as the display controller, and
-    provides fundamental functions like the system clock tick and interrupt
-    controller. Since mfp provides many functions, most
-    of the jobs as a device driver is done by its child drivers such as
-    kbd(4) and clock(4).
-    mfp driver itself only provides the common way to
-    access its registers and a few utility functions for other non-child
-    drivers.

-

-

-

-
clock(4), kbd(4),
-    x68k/intro(4)

-

-

-

-
Machine-dependent part and machine-independent part should be
-    split.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/neptune.4 4.html b/static/netbsd/man4/man4.x68k/neptune.4 4.html
deleted file mode 100644
index 00052d3b..00000000
--- a/static/netbsd/man4/man4.x68k/neptune.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
NEPTUNE(4)Device Drivers Manual (x68k)NEPTUNE(4)

-

-

-

-
neptune —
-    Neptune-X ISA bridge driver

-

-

-

-
neptune0 at intio0 addr 0xece000 irq 239
-  

-  ne0 at neptune? addr 0x300

-

-

-

-
The Neptune-X is a Ethernet interface card initially designed by
-    Hirofumi Shimada, which uses popular NE2000 or its clone with its own
-    x68k-proprietary bus to ISA bus bridge.

-
The NetBSD neptune
-    driver takes charge of the ISA bridge part of the Neptune-X. It is
-    implemented as a more generic `bus' with its own
-    bus_space(9) interface, and is intended to be used with
-    ne(4) driver.

-

-

-

-
isa(4), ne(4),
-    x68k/intro(4), bus_space(9)

-

-

-

-
The neptune device appeared in
-    NetBSD 1.4.

-

-

-

-
neptune itself is always detected when it
-    is specified in the kernel config file. This is because the Neptune-X ISA
-    bridge is transparent to software. The attached device is detected
-    appropriately.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/powsw.4 4.html b/static/netbsd/man4/man4.x68k/powsw.4 4.html
deleted file mode 100644
index b5082530..00000000
--- a/static/netbsd/man4/man4.x68k/powsw.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
POWSW(4)Device Drivers Manual (x68k)POWSW(4)

-

-

-

-
powsw — x68k power
-    switch handler

-

-

-

-
powsw0 at mfp0
-  

-  powsw1 at mfp0

-

-

-

-
The powsw driver monitors x68k's power
-    switch, and is made as interface to sysmon_pswitch(9).

-
powsw0 monitors a front switch.
-    powsw1 monitors an external power switch (EXPWON
-    signal in I/O slot).

-

-

-

-
powerd(8)

-

-

-

-
powsw appeared in NetBSD
-    6.0.

-

-

-

-
I have no idea for powsw2 (rtc alarm).

-

-

-
-  
-    
-    
-  
-
November 27, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x68k/vs.4 4.html b/static/netbsd/man4/man4.x68k/vs.4 4.html
deleted file mode 100644
index 66f47e8d..00000000
--- a/static/netbsd/man4/man4.x68k/vs.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
VS(4)Device Drivers Manual (x68k)VS(4)

-

-

-

-
vs — X68K built-in
-    voice synthesizer driver

-

-

-

-
vs0 at intio0 addr 0xe92000 dma 3 dmaintr
-    106
-  

-  audio*	at vs?

-

-

-

-
vs drives x68k's built-in voice
-    synthesizer. It is implemented as an audio(4) device.

-

-

-

-
audio(4), x68k/intio(4)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/amdccp.4 4.html b/static/netbsd/man4/man4.x86/amdccp.4 4.html
deleted file mode 100644
index f23eac6b..00000000
--- a/static/netbsd/man4/man4.x86/amdccp.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDCCP(4)Device Drivers ManualAMDCCP(4)

-

-

-

-
amdccp — AMD
-    Cryptographic Coprocessor device driver

-

-

-

-
amdccp* at pci?

-

-

-

-
The amdccp driver provides support for
-    cryptographic coprocessors found on certain AMD CPUs. The coprocessor
-    supports hardware offloading for common cryptographic algorithms and a True
-    Random Number Generator (TRNG).

-
Currently, this driver only supports providing additional entropy
-    to the kernel's random number generator.

-

-

-

-
pci(4), rnd(4),
-    entropy(7), rnd(9)

-

-

-

-
The amdccp device driver appeared in
-    NetBSD 9.0.

-

-

-
-  
-    
-    
-  
-
July 25, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/amdpcib.4 4.html b/static/netbsd/man4/man4.x86/amdpcib.4 4.html
deleted file mode 100644
index 19656ccd..00000000
--- a/static/netbsd/man4/man4.x86/amdpcib.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDPCIB(4)Device Drivers Manual (x86)AMDPCIB(4)

-

-

-

-
amdpcib — AMD-8111
-    series LPC bridge and timecounter

-

-

-

-
amdpcib* at pci?
-  

-  hpet* at amdpcib?
-  

-  isa* at amdpcib?

-

-

-

-
The amdpcib driver provides support for
-    the AMD-8111 LPC bridge and implements a 32/64-bit 14.3 MHz (or variable)
-    timecounter using the HPET timer.

-

-

-

-
isa(4), pci(4),
-    x86/hpet(4)

-
Advanced Micro Devices,
-    AMD-8111 HyperTransport I/O Hub,
-    Revision 3.03,
-    http://support.amd.com/us/ChipsetMotherboard_TechDocs/24674.pdf,
-    July, 2004.

-

-

-

-
The amdpcib driver first appeared in
-    NetBSD 5.0.

-

-

-

-
Nicolas Joly
-    ⟨njoly@NetBSD.org⟩

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/amdsmn.4 4.html b/static/netbsd/man4/man4.x86/amdsmn.4 4.html
deleted file mode 100644
index 640e5f38..00000000
--- a/static/netbsd/man4/man4.x86/amdsmn.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDSMN(4)Device Drivers Manual (x86)AMDSMN(4)

-

-

-

-
amdsmn — device
-    driver for AMD processor System Management Network

-

-

-

-
amdsmn* at pci?

-

-

-

-
The amdsmn driver provides support for
-    resources on the System Management Network bus in AMD Family 19h processors,
-    17h processors and some later AMD Family 15h processors.

-

-

-

-
amdzentemp(4)

-

-

-

-
The amdsmn driver first appeared in
-    FreeBSD and NetBSD 9.0.

-

-

-

-
Based on the FreeBSD driver by
-    Conrad Meyer. It was adapted to
-    NetBSD by Ian Clark.

-

-

-
-  
-    
-    
-  
-
October 2, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/amdzentemp.4 4.html b/static/netbsd/man4/man4.x86/amdzentemp.4 4.html
deleted file mode 100644
index 0d564ab2..00000000
--- a/static/netbsd/man4/man4.x86/amdzentemp.4 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
AMDZENTEMP(4)Device Drivers Manual (x86)AMDZENTEMP(4)

-

-

-

-
amdzentemp — AMD
-    Zen CPU family on-die digital thermal sensor

-

-

-

-
amdzentemp* at amdsmnbus?

-

-

-

-
The amdzentemp driver provides support for
-    the on-die digital thermal sensor present on AMD Ryzen CPUs and some later
-    AMD Opteron CPUs.

-
These sensors provide 0.125°C accuracy. There is one sensor
-    for each CPU socket.

-
The amdzentemp driver reports temperatures
-    through the envsys(4) API.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
CPUN sensor0μKcpuN temperature

-

-

-

-
amdtemp(4), envsys(4),
-    envstat(8), powerd(8)

-

-

-

-
The amdzentemp driver first appeared in
-    OpenBSD 4.4 named “kate”. It was then
-    ported to NetBSD 5.0 under the name
-    amdtemp(4). The FreeBSD version of
-    the driver was updated with support for newer AMD CPUs. For
-    NetBSD, the support for the newer CPUs was separated
-    into its own amdzentemp driver.

-

-

-

-
The amdzentemp driver was written by
-    Constantine A. Murenin
-    <cnst@openbsd.org>
-    whilst at the University of Waterloo. Porting of support for the newer AMD
-    CPUs from FreeBSD was provided by
-    Ian Clark.

-

-

-

-
The temperature reading provided to envsys(4)
-    needs to have a CPU-dependent offset applied. For Ryzen X processors, the
-    offset is 20°C, while for Threadripper processors an offset of
-    27°C is needed.

-
The sensor has a thermal-trip value which should be retrieved and
-    provided to envsys(4) as the sensors critical-maximum
-    value.

-

-

-
-  
-    
-    
-  
-
April 20, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/apic.4 4.html b/static/netbsd/man4/man4.x86/apic.4 4.html
deleted file mode 100644
index 39537493..00000000
--- a/static/netbsd/man4/man4.x86/apic.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
APIC(4)Device Drivers Manual (x86)APIC(4)

-

-

-

-
apic, ioapic,
-    lapic — Intel APIC
-    Architecture

-

-

-

-
ioapic* at mainbus*

-

-

-

-
The apic subsystem provides basis for a
-    system of advanced programmable interrupt controllers (APICs) originally
-    designed by Intel but now widely used on all x86 systems.

-
There are two elements in the architecture, the local APIC (LAPIC)
-    and the I/O APIC. Historically these were connected by a dedicated 3-wire
-    “APIC bus”, but the system bus is used for communication
-    today. The configuration is increasingly dependent on ACPI.

-
Typically each CPU in the system contains one LAPIC that performs
-    two primary functions:

-
    
-  
  1. It receives interrupts both from internal sources and from the external
-      I/O APIC. The interrupt sources include I/O devices, the programmable APIC
-      timer, performance monitoring counters, thermal sensor interrupts, and
-      others.
    2. 
-  
  2. In multiprocessor (MP) systems a LAPIC receives and sends interprocessor
-      interrupts (IPIs) from and to other processors in the system. IPIs are
-      used to provide software interrupts, interrupt forwarding, or preemptive
-      scheduling. Against this, the architecture can be generally seen as an
-      attempt to solve the interrupt routing efficiency issues in MP
-    systems.
    3. 
-

-
There is typically one I/O APIC for each peripheral bus in the
-    system. Each I/O APIC has a series of interrupt inputs to external interrupt
-    sources. The architecture usually contains a redirection table which can be
-    used to route the interrupts that an I/O APIC receives to one or more local
-    APICs. When a LAPIC is able to accept an interrupt, it will signal the CPU.
-    Without an I/O APIC, the local APICs are therefore mostly useless; one of
-    the primary functions of the architecture is no longer achievable,
-    interrupts can not be distributed to different CPUs.

-
The 8259 PIC has coexisted with the architecture since its
-    introduction. It is still possible to disable the APIC system and revert
-    back to a 8259-compatible PIC. But the widespread use of MP systems has made
-    this mainly a fallback option.

-

-

-

-
acpi(4), mainbus(4),
-    x86/ichlpcib(4)

-
Intel Corporation,
-    Intel 64 and IA-32 Architectures Software Developer's
-    Manual, Volume 3A: System Programming Guide, Part
-    1,
-    http://www.intel.com/Assets/PDF/manual/253668.pdf,
-    Chapter 10, January,
-    2011.

-
Intel Corporation,
-    Intel 82093AA I/O Advanced Programmable,
-    Interrupt Controller (I/O APIC) Datasheet,
-    http://www.intel.com/design/chipsets/datashts/29056601.pdf,
-    May, 1996.

-
Intel Corporation,
-    8259A, Programmable Interrupt Controller,
-    http://pdos.csail.mit.edu/6.828/2005/readings/hardware/8259A.pdf,
-    December, 1988.

-
John Baldwin,
-    PCI Interrupts for x86 Machines under FreeBSD,
-    http://people.freebsd.org/~jhb/papers/bsdcan/2007/article.pdf,
-    May 18-19, 2007, Proceedings of
-    BSDCan 2007.

-
Microsoft Corporation,
-    PCI IRQ Routing on a Multiprocessor ACPI System,
-    http://www.microsoft.com/whdc/archive/acpi-mp.mspx,
-    December 4, 2001.

-

-

-

-
Authors of the NetBSD implementation of
-    the Intel APIC Architecture include Andrew Doran,
-    Bill Sommerfeld, Frank van der
-    Linden, and Stefan Grefen, among others. The
-    older 8259 PIC implementation is based on the work of
-    William Jolitz.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/autoconf.4 4.html b/static/netbsd/man4/man4.x86/autoconf.4 4.html
deleted file mode 100644
index c2ab14db..00000000
--- a/static/netbsd/man4/man4.x86/autoconf.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(4)Device Drivers Manual (x86)AUTOCONF(4)

-

-

-

-
autoconf —
-    diagnostics from the autoconfiguration code

-

-

-

-
When NetBSD bootstraps it probes the
-    innards of the machine on which it is running and locates controllers,
-    drives, and other devices, printing out what it finds on the console. This
-    procedure is driven by a system configuration table which is processed by
-    config(1) and compiled into each kernel. Devices which
-    exist in the machine but are not configured into the kernel are not
-    detected.

-

-

-

-

-  
CPU class not configured.

-  
You tried to boot NetBSD on a class of CPU type
-      which it doesn't (or at least this compiled version of
-      NetBSD doesn't) understand.

-

-

-

-

-
config(1), intro(4),
-    boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/balloon.4 4.html b/static/netbsd/man4/man4.x86/balloon.4 4.html
deleted file mode 100644
index 068c9029..00000000
--- a/static/netbsd/man4/man4.x86/balloon.4 4.html	
+++ /dev/null
@@ -1,159 +0,0 @@
-
-  
-    
-    
-    
-  
-
BALLOON(4)Device Drivers Manual (xen)BALLOON(4)

-

-

-

-
balloon — Xen
-    memory balloon driver

-

-

-

-
balloon* at xenbus?

-

-

-

-
The balloon driver supports the memory
-    ballooning operations offered in Xen environments. It allows shrinking or
-    extending a domain's available memory by passing pages between different
-    domains. At any time, the total memory available to a domain is called the
-    ``reservation''.

-
Pages are moved via the use of the balloon, a reserved quantity of
-    memory available to all domains that can be freely deflated (or inflated) at
-    a domain's will. Deflating balloon means that pages are moved out from it,
-    and bound to domain's virtual memory. Respectively, inflating balloon
-    indicates that pages are moved out of domain's memory and pushed inside
-    balloon. This is similar to a dynamic allocation of wired physical memory,
-    except that the pages are not available to domain anymore.

-
Any domain is free to request memory from
-    balloon up to the maximum value set by the host's
-    administrator through the mem-max command of
-    xm(1). Alternatively, the host's administrator is free to
-    request to a particular domain to give some memory back. This command
-    requires the targeted domain's cooperation and requires
-    balloon support within it. This can be done through
-    the mem-set command of xm(1).
-    Alternatively, one can control the ballooning directly by writing under the
-    “memory/target” node inside Xenstore. This entry controls the
-    target memory reservation of a given domain, indicated in kilobytes
-  (KiB).

-
An interface to control balloon is also
-    available through sysctl(8) under
-    “machdep.xen.balloon” (all values being in kilobytes):

-

-  
current

-  
(read-only) The current memory reservation of the domain.

-  
min

-  
(read-write) The minimum reservation value acceptable by the domain's
-      balloon driver. Any request that would require
-      domain to reduce its reservation below this threshold will be refused by
-      the driver. This can be used by a domain's administrator to control the
-      number of memory pages that will be kept available to domain.

-  
max

-  
(read-only) The maximum reservation accessible to a domain. Its value can
-      only be changed by the dom0's administrator, through the
-      mem-max command of xm(1).

-  
target

-  
(read-write) The target reservation of the domain. This entry serves the
-      same purpose as the “memory/target” entry in Xenstore. This
-      controls the targeted number of pages that the domain should have. Note
-      that this is only a target, and may not be achieved for a variety of
-      reasons.

-

-

-

-

-

-  
WARNING: balloon could not reach target %zu (current %zu)

-  
balloon failed to reach the target reservation.
-      This is typically due to a target set too low; the kernel prevented memory
-      exhaustion by refusing further allocation.

-  
increase reservation incomplete: was %zu, returned %d

-  
The hypervisor only gave a partial set of memory pages to domain. This
-      happens when host's memory consumption is high, and hypervisor is unable
-      to give enough free pages back to domain.

-  
memory 'hot-plug' unsupported - clipping reservation %zu => %zu
-    pages.

-  
An attempt was made by domain to get more memory than initially obtained
-      during boot. As physical memory pages cannot be added to memory management
-      sub-system dynamically, balloon will limit
-      reservation up to the maximum value it can handle.

-

-

-

-

-
When setting the minimum threshold or target reservation entries
-    through “machdep.xen.balloon”, the following errors can be
-    returned:

-

-  
[]

-  
The value passed is beyond limits. The new value is either too low
-      (“min” is below driver's safeguard value, or
-      “target” is below minimum value), or too high
-      (“target” is above maximum value).

-

-

-

-

-
xm(1), xenbus(4),
-    uvm(9)

-
Carl A. Waldspurger,
-    Memory Resource Management in VMware ESX Server,
-    Proceedings of the 5th Symposium on Operating Systems Design
-    and Implementation, USENIX Association,
-    http://www.usenix.org/events/osdi02/tech/full_papers/waldspurger/waldspurger.pdf,
-    December 9-11, 2002.

-

-

-

-
The balloon driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The balloon driver was written by
-    Cherry G. Mathew
-    <cherry@NetBSD.org>
-    and Jean-Yves Migeon
-    <jym@NetBSD.org>.

-

-

-

-
There are a number of reasons why a domain may not attain the
-    targeted memory reservation: balloon can be empty
-    and cannot be collapsed further, domain may not have enough free memory
-    pages (due to memory fragmentation, memory exhaustion, ...) so it cannot
-    give enough back to balloon.

-
Currently, the virtual memory sub-system of
-    NetBSD is not capable of ``hot-plugging'' new memory
-    pages into place. This means that increasing a domain's memory reservation
-    above its initial maximum value is pointless, as new memory pages cannot be
-    consumed by the memory management sub-system.

-
Over expanding balloon generates high
-    kernel memory pressure. While the driver tries to stay as conservative as
-    possible to avoid crashes, a very low memory reservation will lead to
-    unwanted swap or even panic().

-

-

-

-
Ballooning involves moving pages between different domains. This
-    includes their content, which can lead to information leak. If you are
-    running domains of different sensitivities on the same host, consider
-    disabling the use of ballooning altogether. The
-    NetBSD kernel zeroes all pages before relinquishing
-    them to balloon but this may not be the case for
-    other operating systems.

-

-

-
-  
-    
-    
-  
-
July 30, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/console.4 3.html b/static/netbsd/man4/man4.x86/console.4 3.html
deleted file mode 100644
index d5718dfc..00000000
--- a/static/netbsd/man4/man4.x86/console.4 3.html	
+++ /dev/null
@@ -1,114 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONS(4)Device Drivers Manual (x86)CONS(4)

-

-

-

-
console — x86
-    console interface

-

-

-

-
options CONSDEVNAME=string
-  

-  options CONADDR=integer
-  

-  options CONSPEED=integer
-  

-  options CONS_OVERRIDE
-  

-  options CONMODE=integer

-

-

-

-
The “console” device is used for
-    kernel printf messages and accesses to the
-    /dev/console character special device in user mode.
-    It is attached to a hardware interface at boot time controlled by options in
-    the kernel configuration file, or information passed by the boot loader.

-
Bootblocks from NetBSD 1.4 or newer select
-    their console device from a compiled-in list, and then pass their choice of
-    console device and console parameters to the kernel.

-
As of NetBSD 1.5, the
-    consdev bootblock command allows changing the
-    console device on-the-fly.

-
The kernel will use the same console device as the bootblock; no
-    special kernel configuration is required.

-
To override the bootblock's choice of console, or to use a serial
-    kernel console with older bootblocks, you must specify kernel config-file
-    options to override the information passed by the bootblock. The current
-    option choices are:

-

-  
- the standard PC keyboard and display

-  
(with either the “pc” or the wscons(4)
-      driver)

-  
- standard PC serial ports

-  
(with com(4) driver)

-

-
The available kernel configuration options
-  are:

-

-  
options CONSDEVNAME=string

-  
specifies the name of the console device. Valid values are
-      “pc” for the pc keyboard / display (default) and
-      “com” for a serial port.

-  
options CONADDR=integer

-  
sets the base address for the serial console port (default: 0x3f8).

-  
options CONSPEED=integer

-  
sets the baudrate for the serial console (default: 9600).

-  
options CONS_OVERRIDE

-  
causes console information passed by the bootloader to be ignored and the
-      settings specified by the three options above (or the defaults) to be
-      used. Default behaviour is to use the settings from the bootloader if
-      present, and to use option / default values only if no information was
-      passed.

-  
options CONMODE=integer

-  
allows to specify terminal control flags. The argument is a
-      “cflag” value, see termios(4) for details.
-      Default is (CREAD |
-       |
-      )
-      (8N1). This option takes always effect, because mode settings are not
-      passed by the bootloader.

-

-

-

-

-

-  
/dev/console

-  
 

-

-

-

-

-
options
-    CONSDEVNAME="\"com\"",CONADDR=0x2f8,CONSPEED=57600

-

-

-

-
config(1), tty(4),
-    boot(8)

-

-

-

-
The console device is chosen early in system startup regardless if
-    the specified driver / device is present in the system configuration file.
-    If the driver asked for by the bootloader or
-    “options CONSDEVNAME” is not
-    configured into the system, a panic is caused. Because there is no console
-    device, no explaining message will be printed. If the driver is present, but
-    the specific device instance not, kernel printf will work, but
-    /dev/console becomes a dummy.

-

-

-
-  
-    
-    
-  
-
September 6, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/coretemp.4 4.html b/static/netbsd/man4/man4.x86/coretemp.4 4.html
deleted file mode 100644
index bbbd0f3c..00000000
--- a/static/netbsd/man4/man4.x86/coretemp.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
CORETEMP(4)Device Drivers Manual (x86)CORETEMP(4)

-

-

-

-
coretemp — Intel
-    Core on-die digital thermal sensor

-

-

-

-
coretemp* at cpu?

-

-

-

-
The coretemp driver provides support for
-    the on-die digital thermal sensor present on Intel Core and newer CPUs.

-
The temperatures can be observed by using the
-    envsys(4) API or the envstat(8) command.
-    Temperatures are reported for each core separately.

-

-

-

-
The coretemp driver is able to send a
-    
-    event to the powerd(8) daemon. The script
-    /etc/powerd/scripts/sensor_temperature will be
-    executed by the daemon (if running) when the limit has been reached.

-

-

-

-
envsys(4), envstat(8),
-    powerd(8)

-
Michael Berktold and
-    Tian Tian (Intel Corporation),
-    CPU Monitoring With DTS/PECI, White Paper,
-    http://edc.intel.com/Download.aspx?id=2612,
-    September 2010.

-

-

-

-
The coretemp driver first appeared in
-    FreeBSD 7.0. It was later ported to
-    NetBSD 5.0.

-

-

-

-
The coretemp driver was written by
-    Rui Paulo
-    <rpaulo@FreeBSD.org>
-    as part of a Google Summer of Code project. It was adapted to
-    NetBSD by Juan Romero
-    Pardines.

-

-

-
-  
-    
-    
-  
-
February 23, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/est.4 4.html b/static/netbsd/man4/man4.x86/est.4 4.html
deleted file mode 100644
index 5b78affd..00000000
--- a/static/netbsd/man4/man4.x86/est.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
EST(4)Device Drivers Manual (x86)EST(4)

-

-

-

-
est — Enhanced
-    SpeedStep

-

-

-

-
est0 at cpu0

-

-

-

-
The est driver provides support for
-    Enhanced SpeedStep introduced in Intel's first and second generation of
-    Pentium M processors. The following sysctl(8) variables
-    are available with est:

-

-

-  

-  
The target frequency of the CPUs.

-  

-  
The current frequency.

-  

-  
The frequencies recognized by est.

-

-

-
Note, however, that these variables are not guaranteed to exist in
-    the future versions of NetBSD.

-

-

-

-
acpicpu(4), x86/odcm(4),
-    x86/powernow(4)

-
Intel Corporation,
-    Intel Pentium M Processor.,
-    Datasheet,
-    http://download.intel.com/support/processors/mobile/pm/sb/25261203.pdf,
-    March, 2004.

-
Intel Corporation,
-    Enhanced Intel SpeedStep Technology for the Intel Pentium
-    M Processor., White Paper,
-    http://download.intel.com/design/network/papers/30117401.pdf,
-    March, 2004.

-

-

-

-
The est driver is considered a legacy
-    interface to be used only with old systems. It is known to be problematic
-    with new CPUs. Furthermore, in the unlikely case where both
-    est and x86/ichlpcib(4) or
-    piixpcib(4) provide support for SpeedStep, the PCI-based
-    interfaces should not be accessed due possible race conditions.

-

-

-
-  
-    
-    
-  
-
September 7, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/fdc.4 4.html b/static/netbsd/man4/man4.x86/fdc.4 4.html
deleted file mode 100644
index 73fd66fb..00000000
--- a/static/netbsd/man4/man4.x86/fdc.4 4.html	
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    
-    
-    
-  
-
FDC(4)Device Drivers Manual (x86)FDC(4)

-

-

-

-
fdc — NEC 765
-    floppy disk controller driver

-

-

-

-
fdc0 at isa? port 0x3f0 irq 6 drq 2
-  

-  fdc* at acpi?
-  

-  fdc* at pnpbios? index ?
-  

-  fd* at fdc? drive ?

-

-

-

-
The fdc driver provides support for the
-    NEC 765 floppy disk controller and floppy disk drives, commonly found on
-    IBM-PC compatible systems.

-
The driver supports the following floppy diskette formats by using
-    particular partitions:

-

-

-  
1.44MB 3.5-inch (b)

-  
 

-  
1.2MB 5.25-inch (c)

-  
 

-  
360KB 5.25-inch (1.2MB drive) (d)

-  
 

-  
360KB 5.25-inch (IBM-PC drive) (e)

-  
 

-  
720KB 3.5-inch (f)

-  
 

-  
720KB 5.25-inch (g)

-  
 

-  
360KB 3.5-inch (h)

-  
 

-

-

-Partition a selects the default format for the attached
-  floppy drive, as determined by the BIOS configuration for the diskette drive.
-

-

-

-
The driver supports floppy disk formatting using the interfaces in
-    <sys/fdio.h>:

-

-  

-    struct fdformat_parms

-  
Fetch current formatting parameters. This gets the default parameters for
-      the open device if no parameters have been set during the session.

-  

-    struct fdformat_parms

-  
Set formatting parameters. The driver saves this state and it persists
-      while the device is open.

-  

-    struct fdformat_cmd

-  
Format a track on the medium. If this call returns
-      EINVAL, the track formatting parameters were out
-      of range for the medium. If it returns EIO, there
-      was a medium error while formatting the track.

-  

-    int

-  
Set driver options which persist until the device is closed. The options
-      should be the logical OR of the desired values below:
-    

-      

-      
Do not retry operations on failure

-      

-      
Do not print error messages to the console

-    

-  

-  

-    int

-  
Fetch drive options.

-

-
A typical use of the formatting facilities would be to open the
-    device, call FDIOCGETFORMAT to fetch the current
-    format parameters, perhaps change a parameter or two, display the formatting
-    details to the user, and then call FDIOCSETFORMAT
-    followed by a series of calls to
-  FDIOCFORMAT_TRACK.

-

-

-

-
fdformat(1), acpi(4),
-    isa(4), pnpbios(4)

-

-

-

-
The fdc formatting support appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
September 23, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/fwhrng.4 4.html b/static/netbsd/man4/man4.x86/fwhrng.4 4.html
deleted file mode 100644
index 4bd09938..00000000
--- a/static/netbsd/man4/man4.x86/fwhrng.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
FWHRNG(4)Device Drivers Manual (x86)FWHRNG(4)

-

-

-

-
fwhrng — Intel
-    Firmware Hub Random Number Generator

-

-

-

-
fwhrng* at ichlpcib?

-

-

-

-
The fwhrng driver provides support for
-    hardware Random Number Generator (RNG) available on some Intel Firmware Hubs
-    (FWHs). The fwhrng driver accesses the RNG through
-    an I/O controller hub (ICH).

-

-

-

-
rnd(4), x86/ichlpcib(4)

-
Intel Corporation,
-    Intel 82802AB/82802AC Firmware Hub (FWH),
-    http://download.intel.com/design/chipsets/datashts/29065804.pdf,
-    November, 2000.

-

-

-

-
The entropy source is not tested for randomness.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/hpet.4 4.html b/static/netbsd/man4/man4.x86/hpet.4 4.html
deleted file mode 100644
index 4dc1454d..00000000
--- a/static/netbsd/man4/man4.x86/hpet.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
HPET(4)Device Drivers Manual (x86)HPET(4)

-

-

-

-
hpet — High
-    Precision Event Timer

-

-

-

-
hpet* at acpihpetbus?
-  

-  hpet* at acpinodebus?
-  

-  hpet* at amdpcib?
-  

-  hpet* at ichlpcib?

-

-

-

-
The hpet driver supports High Precision
-    Event Timers (HPETs). The HPET architecture defines one main 64-bit counter
-    and several additional timers with variable width. The minimum clock
-    frequency of the main timecounter is 10 MHz, but much higher rates are
-    common. The additional 32 or 64 -bit parts are typically accessible via MMIO
-    that is set by the system BIOS through ACPI.

-
As a HPET can provide higher interrupt rates than a RTC or
-    attimer(4), multimedia is one typical application context.
-    The interrupt logic is configurable through I/O APIC, but a legacy mode is
-    provided for older systems.

-

-

-

-
acpi(4), attimer(4),
-    timecounter(9), tsc(9)

-
Intel Corporation,
-    IA-PC HPET (High Precision Event Timers)
-    Specification, Revision 1.0a,
-    http://www.intel.com/hardwaredesign/hpetspec_1.pdf,
-    October, 2004.

-

-

-
-  
-    
-    
-  
-
June 14, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/ichlpcib.4 3.html b/static/netbsd/man4/man4.x86/ichlpcib.4 3.html
deleted file mode 100644
index 985e08bf..00000000
--- a/static/netbsd/man4/man4.x86/ichlpcib.4 3.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
ICHLPCIB(4)Device Drivers Manual (x86)ICHLPCIB(4)

-

-

-

-
ichlpcib — Intel
-    ICH LPC Interface Bridge

-

-

-

-
ichlpcib* at pci? dev ? function ?
-  

-  fwhrng* at ichlpcib?
-  

-  hpet0 at ichlpcib?
-  

-  isa0 at ichlpcib?
-  

-  gpio* at ichlpcib?
-  

-  tco* at ichlpcib?

-

-

-

-
The ichlpcib driver supports the Intel ICH
-    LPC Interface Bridges on compatible chipsets. Supported functions
-  include:

-
    
-  
  • Watchdog timer. The watchdog timer may be configured for a 1 seconds (on
-      ICH6 or newer) and 2 seconds (on ICH5 or older) min period and for a 23
-      seconds (on ICH5 or older) or 367 seconds max period (on ICH6 or newer).
-    
    Prior to NetBSD 8.0, the
-        x86/tco(4) watchdog timer was included as part of the
-        ichlpcib driver, and did not require explicit
-        configuration.
    
-  
    • 
-  
  • Power Management timer. A 24-bit timer available to be used by the
-      timecounters framework.
    • 
-  
  • SpeedStep. In some older systems the SpeedStep function is also available,
-      and can be used to switch between high and low frequency (to reduce power
-      consumption) via the machdep.speedstep_state
-      sysctl(8) node. A value of 0 will use the low frequency
-      (low power) and a 1 will enable the high frequency (full power).
    • 
-  
  • General Purpose Input/Output. The ICH provides up to 64 I/O pins which can
-      be accessed through the gpio(4) framework.
    • 
-

-

-

-

-
gpio(4), x86/est(4),
-    x86/fwhrng(4), x86/hpet(4),
-    x86/ioapic(4), x86/tco(4),
-    sysctl(8), wdogctl(8)

-
Intel Corporation,
-    Intel I/O Controller Hub 6 (ICH6) Family,
-    http://www.intel.com/assets/pdf/datasheet/301473.pdf,
-    January, 2005.

-
Intel Corporation,
-    Intel I/O Controller Hub 7 (ICH7) Family,
-    http://www.intel.com/Assets/PDF/datasheet/307013.pdf,
-    April, 2007.

-
Intel Corporation,
-    Intel I/O Controller Hub 8 (ICH8) Family,
-    http://www.intel.com/assets/pdf/datasheet/313056.pdf,
-    May, 2007.

-
Intel Corporation,
-    Using the Intel ICH Family Watchdog Timer (WDT),
-    ftp://download.intel.com/design/chipsets/applnots/29227301.pdf,
-    September, 2002.

-

-

-

-
The ichlpcib driver first appeared in
-    NetBSD 3.0.

-

-

-

-
The ichlpcib driver was written by
-    Minoura Makoto and
-  

-  Matthew R. Green.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/imcsmb.4 3.html b/static/netbsd/man4/man4.x86/imcsmb.4 3.html
deleted file mode 100644
index 7b5477b3..00000000
--- a/static/netbsd/man4/man4.x86/imcsmb.4 3.html	
+++ /dev/null
@@ -1,113 +0,0 @@
-
-  
-    
-    
-    
-  
-
IMCSMB(4)Device Drivers Manual (x86)IMCSMB(4)

-

-

-

-
imcsmb — Intel
-    integrated Memory Controller (iMC) SMBus controller driver

-

-

-

-
imc* at pci? dev ? func ?
-  

-  imcsmb* at imc?
-  

-  iic* at i2cbus?

-
Alternatively, to load the driver as a module at boot time, place
-    the following line in boot.cfg(5):

-

-
load=imcsmb

-
or add the following line to your /etc/modules file:

-

-
imcsmb

-

-

-

-
The imcsmb driver provides
-    iic(4) support for the SMBus controller functionality in
-    the integrated Memory Controllers (iMCs) embedded in Intel Sandybridge-Xeon,
-    Ivybridge-Xeon, Haswell-Xeon, and Broadwell-Xeon CPUs. Each CPU implements
-    one or more iMCs, depending on the number of cores; each iMC implements two
-    SMBus controllers (iMC-SMBs). The iMC-SMBs are used by the iMCs to read
-    configuration information from the DIMMs during POST. They may also be used,
-    by motherboard firmware or a BMC, to monitor the temperature of the
-  DIMMs.

-
The iMC-SMBs are
-     general-purpose
-    SMBus controllers. By their nature, they are only ever attached to DIMMs, so
-    they implement only the SMBus operations needed for communicating with
-    DIMMs. Specifically:

-

-
    
-  
  • READB
    • 
-  
  • READW
    • 
-  
  • WRITEB
    • 
-  
  • WRITEW
    • 
-

-
A more detailed discussion of the hardware and driver architecture
-    can be found at the top of sys/dev/imcsmb/imc.c.

-

-

-

-
As mentioned above, firmware might use the iMC-SMBs to read DIMM
-    temperatures. The public iMC documentation does not describe any sort of
-    coordination mechanism to prevent requests from different sources —
-    such as the motherboard firmware, a BMC, or the operating system —
-    from interfering with each other.

-

-
Therefore, it is highly recommended that developers contact
-  the motherboard vendor for any board-specific instructions on how to disable
-  and re-enable DIMM temperature monitoring.

-
DIMM temperature monitoring should be
-    disabled before returning from
-    (),
-    and re-enabled before returning from
-    ().
-    The driver includes comments to that effect at the appropriate locations.
-    The driver has been tested and shown to work, with only that type of
-    modification, on certain motherboards from Intel. (Unfortunately, those
-    modifications were based on material covered under a non-disclosure
-    agreement, and therefore are not included in this driver.) The driver has
-    also been tested and shown to work as-is on various motherboards from
-    SuperMicro and ASUS.

-
Because of the above, the imcsmb driver is
-    not included in the default GENERIC kernel. In order
-    to use the imcsmb driver, you must compile a custom
-    kernel, or load the driver using modload(8).

-
The iic(4) driver will connect to the i2cbus
-    instances created by imcsmb.

-

-

-

-
iic(4)

-

-

-

-
The imcsmb driver first appeared in
-    FreeBSD 12.0. It was later ported to
-    NetBSD 9.0.

-

-

-

-
The imcsmb driver was originally written
-    for Panasas by Joe Kloss. It was substantially
-    refactored, and this manual page was written, by Ravi
-    Pokala
-    <rpokala@freebsd.org>.
-    It was adapted to NetBSD by Paul
-    Goyette
-    <pgoyette@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 16, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/lpt.4 4.html b/static/netbsd/man4/man4.x86/lpt.4 4.html
deleted file mode 100644
index 20149a8f..00000000
--- a/static/netbsd/man4/man4.x86/lpt.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
LPT(4)Device Drivers Manual (x86)LPT(4)

-

-

-

-
lpt — Parallel
-    port driver

-

-

-

-
lpt0 at isa? port "IO_LPT1" irq
-    7
-  

-  lpt1 at isa? port "IO_LPT2"
-  

-  lpt* at acpi?
-  

-  lpt* at ofisa?
-  

-  lpt* at pnpbios? index ?
-  

-  lpt* at puc? port ?

-

-

-

-
This driver provides access to parallel ports. The bits in the
-    minor number select various features of the driver. If no IRQ is specified
-    in the kernel configuration, only the polling device may be used.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Function
128Use the interruptless driver. (polling)
64Do not initialize the device on the port.
32Automatic LF on CR.

-

-

-

-

-  
/dev/lpt0

-  
first interrupt-driven parallel port device

-  
/dev/lpa0

-  
first polled parallel port device

-

-

-

-

-
acpi(4), isa(4),
-    ofisa(4), pnpbios(4),
-    puc(4)

-

-

-
-  
-    
-    
-  
-
September 23, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/mem.4 4.html b/static/netbsd/man4/man4.x86/mem.4 4.html
deleted file mode 100644
index d712ca60..00000000
--- a/static/netbsd/man4/man4.x86/mem.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEM(4)Device Drivers Manual (x86)MEM(4)

-

-

-

-
mem, kmem —
-    memory files

-

-

-

-
The special file /dev/mem is an interface
-    to the physical memory of the computer. Byte offsets in this file are
-    interpreted as physical memory addresses. Reading and writing this file is
-    equivalent to reading and writing memory itself. Only offsets within the
-    bounds of /dev/mem are allowed.

-
Kernel virtual memory is accessed through the interface
-    /dev/kmem in the same manner as
-    /dev/mem. Only kernel virtual addresses that are
-    currently mapped to memory are allowed.

-
On ISA the I/O memory space begins at physical address 0x000a0000
-    and runs to 0x00100000.

-

-

-

-

-  
/dev/mem

-  
 

-  
/dev/kmem

-  
 

-

-

-

-

-
The mem, kmem
-    files appeared in Version 6 AT&T
-  UNIX.

-

-

-
-  
-    
-    
-  
-
March 27, 2026NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/odcm.4 4.html b/static/netbsd/man4/man4.x86/odcm.4 4.html
deleted file mode 100644
index 9a5745fa..00000000
--- a/static/netbsd/man4/man4.x86/odcm.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
ODCM(4)Device Drivers Manual (x86)ODCM(4)

-

-

-

-
odcm — On-demand
-    Clock Modulation

-

-

-

-
odcm0 at cpu0

-

-

-

-
The odcm driver provides support for
-    changing the duty cycle of a CPU. This is sometimes known as
-    “on-demand clock modulation” (ODCM). Refer to
-    acpicpu(4) for additional details about ODCM.

-
The following sysctl(8) variables are available
-    with odcm:

-

-

-  

-  
The target duty cycle of all CPUs. The values range from 7 (100 %) to 0
-      (approximately 13 %).

-  

-  
The current duty cycle of CPUs.

-  

-  
A list of available duty cycles.

-

-

-
Note that some errata may limit the availability of some duty
-    cycles.

-

-

-

-
acpicpu(4), x86/est(4),
-    x86/powernow(4)

-

-

-

-
ODCM is meant for short-term thermal management, not power
-    management. There is usually no reason for a system administrator to change
-    the values manually. Lowering the duty cycle may dramatically decrease
-    performance and responsiveness of the system.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/powernow.4 4.html b/static/netbsd/man4/man4.x86/powernow.4 4.html
deleted file mode 100644
index 8e2ea4c8..00000000
--- a/static/netbsd/man4/man4.x86/powernow.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
POWERNOW(4)Device Drivers Manual (x86)POWERNOW(4)

-

-

-

-
powernow — AMD
-    PowerNow! and Cool'n'Quiet

-

-

-

-
powernow0 at cpu0

-

-

-

-
The powernow driver supports AMD
-    “PowerNow!” and “Cool'n'Quiet” CPU frequency
-    scaling technologies. The following sysctl(8) variables
-    are available with powernow:

-

-

-  

-  
The target frequency of the CPUs.

-  

-  
The current frequency.

-  

-  
The available frequencies.

-

-

-
Note, however, that these variables are not guaranteed to exist in
-    the future versions of NetBSD.

-

-

-

-
acpicpu(4), x86/est(4),
-    x86/odcm(4)

-

-

-

-
The powernow driver is considered a legacy
-    interface to be used only with relatively old systems. The driver supports
-    only AMD processor families K7 (for instance, Duron, Athlon, and some
-    Semprons) and K8 (namely, the early 64-bit family, including Athlon 64,
-    Opteron, and Turion).

-

-

-
-  
-    
-    
-  
-
September 7, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/soekrisgpio.4 4.html b/static/netbsd/man4/man4.x86/soekrisgpio.4 4.html
deleted file mode 100644
index 78bec8ac..00000000
--- a/static/netbsd/man4/man4.x86/soekrisgpio.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
SOEKRIS(4)Device Drivers Manual (x86)SOEKRIS(4)

-

-

-

-
soekrisgpio —
-    Soekris net6501 GPIO and LEDs

-

-

-

-
soekrisgpio0 at isa? port 0x680
-  

-  gpio* at soekrisgpio?

-

-

-

-
The soekrisgpio driver provides support
-    for the GPIO and LEDs as implemented by the Xilinx Spartan FGPA integrated
-    into the Soekris net6501 programmed with the default bitstream found in the
-    BIOS.

-
Two standard gpio(4) interfaces are provided,
-    one for the 16 real pins which can be configured as either inputs or outputs
-    and another with 2 output-only pins that map to the error and ready LEDs
-    respectively. Both may be used with gpioctl(8).

-

-

-

-
gpio(4), intro(4),
-    isa(4), gpioctl(8)

-

-

-

-
The soekrisgpio driver first appeared in
-    NetBSD 7.0.

-

-

-

-
The soekrisgpio driver was written by
-    Matt Dainty
-    <matt@...> and imported from
-    a patch for OpenBSD to
-    NetBSD by
-  

-  Frank Kardel
-    <kardel@NetBSD.org>.

-

-

-

-
If the Xilinx FPGA is programmed with a different bitstream, the
-    driver will likely not function.

-

-

-
-  
-    
-    
-  
-
June 10, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/tco.4 4.html b/static/netbsd/man4/man4.x86/tco.4 4.html
deleted file mode 100644
index d5fa68f4..00000000
--- a/static/netbsd/man4/man4.x86/tco.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCO(4)Device Drivers Manual (x86)TCO(4)

-

-

-

-
tco — Intel
-    Controller Hub TCO watchdog timer device

-

-

-

-
tco* at ichlpcib?

-

-

-

-
The tco driver provides support for the
-    watchdog timer included in the Intel Controller Hub (ICH).

-
Setting the timer interval and arming the watchdog is performed
-    using the wdogctl(8) utility. For ICH5 and earlier
-    controllers, the interval is in the range of 2 to 23 seconds; for ICH6 and
-    newer controllers, the interval is in the range of 1 to 367 seconds.

-

-

-

-
wdogctl(8)

-

-

-

-
The tco driver first appeared in
-    NetBSD 8.0. In earlier releases of
-    NetBSD the driver was included as part of the
-    x86/ichlpcib(4) driver.

-

-

-

-
The tco driver was written by
-    Minoura Makoto
-    <minoura@NetBSD.org>
-    and Matthew R. Green
-    <mrg@NetBSD.org>. The
-    tco driver was separated from the
-    x86/ichlpcib(4) driver by Paul
-    Goyette
-    <pgoyette@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 4, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/man4.x86/viac7temp.4 4.html b/static/netbsd/man4/man4.x86/viac7temp.4 4.html
deleted file mode 100644
index c94245a3..00000000
--- a/static/netbsd/man4/man4.x86/viac7temp.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIAC7TEMP(4)Device Drivers ManualVIAC7TEMP(4)

-

-

-

-
viac7temp — VIA
-    C7, VIA Nano and Zhaoxin CPU temperature sensor

-

-

-

-
viac7temp* at cpu?

-

-

-

-
The viac7temp driver supports temperature
-    sensors found in VIA C7, VIA Nano and Zhaoxin processors. The available
-    information is available through the envsys(4) API and the
-    envstat(8) command.

-

-

-

-
coretemp(4)

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-
-  
-    
-    
-  
-
April 30, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/mbe.4 4.html b/static/netbsd/man4/mbe.4 4.html
deleted file mode 100644
index cc181bd4..00000000
--- a/static/netbsd/man4/mbe.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
MBE(4)Device Drivers ManualMBE(4)

-

-

-

-
mbe — Fujitsu
-    MB8696x-based PCMCIA and SEGA LAN (HIT-0300) Ethernet driver

-

-

-

-

-

-
mbe* at pcmcia? function ?

-

-

-

-
mbe* at g2bus? function ?

-

-

-

-

-
The mbe driver supports PCMCIA Ethernet
-    adapters based on the Fujitsu MB86960A/MB86965A Ethernet controller.
-    Supported PCMCIA cards include:

-

-
    
-  
  • Fujitsu MBH10302
    • 
-  
  • Fujitsu MBH10304
    • 
-  
  • TDK Corp. LAK-CD021BX
    • 
-  
  • TDK Corp. DFL9610
    • 
-  
  • Fujitsu Towa LA501
    • 
-

-
It also supports the SEGA LAN (HIT-0300) Ethernet adapter
-    available on the dreamcast.

-

-

-

-
ifmedia(4), intro(4),
-    pcmcia(4), ifconfig(8)

-

-

-

-
The mbe driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 12, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/mc.4 4.html b/static/netbsd/man4/mc.4 4.html
deleted file mode 100644
index ff902d4c..00000000
--- a/static/netbsd/man4/mc.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
MC(4)Device Drivers ManualMC(4)

-

-

-

-
mc — Ethernet
-    driver for Am79C940 (MACE) onboard Ethernet

-

-

-

-
mc* at obio?

-

-

-

-
The mc interface provides access to a 10
-    Mb/s Ethernet network via the AMD Am79C940 (MACE) Ethernet chip set.

-

-

-

-
The mc interface supports the on-board
-    Ethernet of the following mac68k machines:

-
    
-  
  • Centris 660AV
    • 
-  
  • Quadra 660AV
    • 
-  
  • Quadra 840AV
    • 
-

-
The mc interface supports the on-board
-    Ethernet of the following macppc machines:

-
    
-  
  • Apple Network Server (500 and 700)
    • 
-  
  • Apple Power Macintosh (7200, 7300, 7500, 7600, 8500, 8600, 9500, and
-    9600)
    • 
-  
  • Power Computing (PowerCenter, PowerCenter Pro, PowerCurve, PowerTower,
-      PowerTower Pro, and PowerWave)
    • 
-

-

-

-

-

-  
mc0 at obio0: address %s.

-  
This is a normal autoconfiguration message noting the 6 byte physical
-      Ethernet address of the adapter.

-

-

-

-

-
gem(4), mac68k/ae(4),
-    sn(4), tlp(4),
-    ifconfig(8)

-

-

-

-
The mc interface first appeared in
-    NetBSD 1.3.

-

-

-

-
The mc Ethernet driver was written by
-    Dave Huang
-    <khym@bga.com>. The man
-    page was written by Thomas Klausner
-    <wiz@NetBSD.org> and
-    Michael Wolfson
-    <mbw@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
September 2, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/mca.4 4.html b/static/netbsd/man4/mca.4 4.html
deleted file mode 100644
index e33faf88..00000000
--- a/static/netbsd/man4/mca.4 4.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCA(4)Device Drivers ManualMCA(4)

-

-

-

-
mca — introduction
-    to machine-independent MCA bus support and drivers

-

-

-

-
mca0 at mainbus?

-

-  

-  options MCAVERBOSE

-
Machine-dependent; depends on the bus topology and MCA bus
-    interface of your system. Typical MCA buses are connected directly to the
-    main system bus.

-

-

-

-
NetBSD includes a machine-independent MCA
-    bus subsystem and several machine-independent MCA device drivers.

-

-

-

-
NetBSD includes machine-independent MCA
-    drivers, sorted by device type and driver name:

-

-

-

-

-  
aha(4)

-  
Adaptec AHA-1640 SCSI interface

-  
esp(4)

-  
NCR 53C90 SCSI Adapter

-

-

-

-

-

-

-

-  
edc(4)

-  
IBM ESDI Fixed Disk Controller

-

-

-

-

-

-

-

-  
com(4)

-  
NS8250-, NS16450-, and NS16550-based serial cards.

-

-

-

-

-

-

-

-  
ate(4)

-  
Allied-Telesis 1720 Ethernet interface cards

-  
we(4)

-  
WD/SMC WD80x3x Ethernet interface cards and clones

-  
le(4)

-  
SKNET Personal and MC+ Ethernet interface cards

-  
elmc(4)

-  
3Com EtherLink/MC (3c523) Ethernet interface

-  
ep(4)

-  
3Com EtherLink III 3c529 Ethernet interface

-  
tra(4)

-  
Tiara LANCard/E and Standard MicroSystems 3016/MC Ethernet interface

-

-

-

-

-

-

-
intro(4), mca(9)

-

-

-

-
The machine-independent MCA subsystem appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
February 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/mcclock.4 4.html b/static/netbsd/man4/mcclock.4 4.html
deleted file mode 100644
index a869186a..00000000
--- a/static/netbsd/man4/mcclock.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCCLOCK(4)Device Drivers ManualMCCLOCK(4)

-

-

-

-
mcclock — DS1287
-    real-time clock

-

-

-

-

-

-
mcclock* at isa? port 0x70

-

-

-

-
mcclock* at gbus? offset ?
-  

-  mcclock* at ioasic? offset ?
-  

-  mcclock* at isa? port 0x70
-  

-  mcclock* at jensenio? port ?

-

-

-

-
mcclock* at jazzio?

-

-

-

-
mcclock* at isa? port 0x70

-

-

-

-
mcclock* at ibus0 addr ?
-  

-  mcclock* at ioasic? offset ?

-

-

-

-
mcclock* at mace0 offset 0x3a0000

-

-

-

-

-
The mcclock driver provides support for
-    the DS1287 real-time clock (RTC). Note that the kernel expects the RTC to
-    run in UTC.

-

-

-

-
intro(4), ioasic(4),
-    isa(4)

-

-

-
-  
-    
-    
-  
-
September 18, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/mcd.4 4.html b/static/netbsd/man4/mcd.4 4.html
deleted file mode 100644
index 5325b279..00000000
--- a/static/netbsd/man4/mcd.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCD(4)Device Drivers ManualMCD(4)

-

-

-

-
mcd — Mitsumi
-    CD-ROM driver

-

-

-

-
mcd0 at isa? port 0x300 irq 10
-  

-  options MCD_PROMISC

-

-

-

-
The mcd driver provides support for
-    Mitsumi CD-ROM controller and drive on the isa(4) bus.

-

-

-

-

-  
/dev/cd[0-9][a-h]

-  
block mode Mitsumi CD-ROM devices

-  
/dev/rmcd[0-9][a-h]

-  
raw mode Mitsumi CD-ROM devices

-

-

-

-

-
intro(4), isa(4),
-    ne(4), we(4)

-

-

-

-
The mcd hardware is difficult to probe
-    accurately. Historically, the mcd probe would accept
-    any return values as indicating that an mcd drive
-    was present. Other devices, particularly ne(4) or
-    we(4), would then be incorrectly claimed by the
-    mcd driver. The driver now only accepts result codes
-    known to indicate Mitsumi-compatible CD controllers, but may reject some
-    mcd hardware which returns other result codes.

-
options MCD_PROMISC enables the original
-    promiscuous probe behaviour. Use with extreme caution.

-

-

-
-  
-    
-    
-  
-
November 29, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/mcommphy.4 4.html b/static/netbsd/man4/mcommphy.4 4.html
deleted file mode 100644
index f4934e79..00000000
--- a/static/netbsd/man4/mcommphy.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCOMMPHY(4)Device Drivers ManualMCOMMPHY(4)

-

-

-

-
mcommphy —
-    Motorcomm YT8511 / YT8531 family Gigabit Ethernet
-    PHYs

-

-

-

-
mcommphy* at mii?

-

-

-

-
The mcommphy driver provides support for
-    the Motorcomm YT8511C / YT8511H Integrated 10/100/1000 Gigabit Ethernet
-    Transceiver, and the Motorcomm YT8531(D)H / YT8531(D)C / YT8531P 10/100/1000
-    Gigabit Ethernet Transceiver.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    ifconfig(8)

-

-

-

-
The mcommphy device driver was written by
-    Jared D. McNeill, and updated by
-    Nick Hudson with YT8531 support. It first appeared
-    in NetBSD 10.0.

-

-

-
-  
-    
-    
-  
-
October 24, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/mcp3kadc.4 4.html b/static/netbsd/man4/mcp3kadc.4 4.html
deleted file mode 100644
index 5c0ee74f..00000000
--- a/static/netbsd/man4/mcp3kadc.4 4.html	
+++ /dev/null
@@ -1,139 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCP3KADC(4)Device Drivers ManualMCP3KADC(4)

-

-

-

-
mcp3kadc —
-    Microchip 3x0x SAR analog to digital converter

-

-

-

-
mcp3kadc* at spi? slave ? flags N

-

-

-

-
The mcp3kadc driver reports the current
-    voltage on the chip's ADC channels through the envsys(4)
-    API. The driver calculates these values according to the currently selected
-    reference voltage (Vref). It can be changed through
-    the sysctl(8) node
-    hw.mcp3kadc0.vref.

-
The following table shows the supported chips. The type of the
-    chip can be selected with the flags argument in the
-    config file.

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
10 bits10
10 bits21
10 bits42
10 bits83
12 bits14
12 bits25
12 bits46
12 bits87
13 bits18
13 bits49
13 bits810

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  
hw.mcp3kadc0.vref

-  
Defines the reference voltage on the chip's Vref
-      pin in millivolts (mV). It defaults to the ADC's maximum output value + 1
-      in millivolts (e.g., 4096 for a 12-bit ADC).

-

-

-

-

-
envsys(4), spi(4),
-    sysctl(8)

-

-

-

-
The mcp3kadc driver first appeared in
-    NetBSD 8.0.

-

-

-

-
The mcp3kadc driver was written by
-    Frank Wille.

-

-

-
-  
-    
-    
-  
-
August 18, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/mcp48x1dac.4 4.html b/static/netbsd/man4/mcp48x1dac.4 4.html
deleted file mode 100644
index e2a22a14..00000000
--- a/static/netbsd/man4/mcp48x1dac.4 4.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCP48X1DAC(4)Device Drivers ManualMCP48X1DAC(4)

-

-

-

-
mcp48x1dac —
-    Microchip 48x1 digital to analog converter

-

-

-

-
mcp48x1dac* at spi? slave ? flags N

-

-

-

-
The mcp48x1dac driver supports the MCP48x1
-    family of digital to analog converters. The digital values to be converted
-    to analog signal are passed through the sysctl(8)
-  node.

-
The driver reports the current voltage output on the chip's DAC
-    channel through the envsys(4) API. It calculates these
-    values assuming that internal 2.048V reference voltage
-    (Vref) is used.

-
The following table shows the supported chips. The type of the
-    chip can be selected with the flags argument in the
-    config file.

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
8 bits0
10 bits1
12 bits2

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  
machdep.mcp48x1dac0.data

-  
Defines digital data to be converted into analog signal. This value is
-      interpreted literally and sent to the DAC without any conversion. Refer to
-      the chip datasheet for more information.

-  
machdep.mcp48x1dac0.gain

-  
When set to 1 it enables 2x output gain on the DAC channel. The default
-      value is 0.

-

-

-

-

-
envsys(4), spi(4),
-    sysctl(8)

-
MCP4801/4811/4821 8/10/12-Bit
-    Voltage Output Digital-to-Analog Converter with Internal VREF and SPI
-    Interface Data Sheet.

-

-

-

-
The mcp48x1dac driver first appeared in
-    NetBSD 7.0.

-

-

-

-
The mcp48x1dac driver was written by
-    Radoslaw Kujawa.

-
This man page is based on mcp3kadc(4) page by
-    Frank Wille.

-

-

-

-
There are bugs.

-

-

-
-  
-    
-    
-  
-
August 23, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/mcp980x.4 4.html b/static/netbsd/man4/mcp980x.4 4.html
deleted file mode 100644
index a824a1d2..00000000
--- a/static/netbsd/man4/mcp980x.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCP980X(4)Device Drivers ManualMCP980X(4)

-

-

-

-
mcp980x —
-    Microchip 9800/1/2/3 I2C temperature sensor
-  driver

-

-

-

-
mcp980x* at iic? addr 0x48

-

-

-

-
The mcp980x driver provides support for
-    the MCP980x series of temperature sensors. It allows reporting ambient
-    temperature through the envsys(4) API.

-

-

-

-
The following sysctl(3) variable are
-  provided:

-

-  
machdep.mcp980x0.res

-  
ADC resolution (integer). Valid values are 0-3, where 0 is 9-bit (0.5
-      Celsius degree) and 3 is 12-bit (0.0625 Celsius degree) resolution.

-  
machdep.mcp980x0.templimit

-  
If the ambient temperature exceeds this limit, the chip asserts an alert
-      line (integer).

-  
machdep.mcp980x0.hysteresis

-  
Hysteresis for temperature limit (integer).

-

-

-

-

-
envsys(4)

-

-

-

-
The mcp980x device first appeared in
-    NetBSD 7.0.

-

-

-

-
The mcp980x driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.

-

-

-

-
MCP9804 and MCP9805 chip are different and are supported by the
-    sdtemp(4) driver.

-
The MCP980x chip supports hysteresis and temperature limit values
-    with a resolution of 0.5 Celsius degree, however the
-    mcp980x driver supports setting only integer
-  values.

-

-

-
-  
-    
-    
-  
-
July 26, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/mcpgpio.4 4.html b/static/netbsd/man4/mcpgpio.4 4.html
deleted file mode 100644
index 32b10b05..00000000
--- a/static/netbsd/man4/mcpgpio.4 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCPGPIO(4)Device Drivers ManualMCPGPIO(4)

-

-

-

-
mcpgpio — Driver
-    for Microchip I/O Expanders on I2C and SPI bus

-

-

-

-

-

-
mcpgpio* at iic? addr ?
-  

-  gpio* at gpiobus?

-

-

-

-
mcpgpio0 at spi? slave 0 flags 0
-  

-  mcpgpio1 at spi? slave 0 flags 1
-  

-  mcpgpio2 at spi? slave 0 flags 2
-  

-  mcpgpio3 at spi? slave 0 flags 3
-  

-  gpio* at gpiobus?

-

-

-

-

-
The mcpgpio driver supports the following
-    Microchip I/O Expanders:

-

-  
MCP23008

-  
8-bit I/O expander, I2C interface

-  
MCP23S08

-  
8-bit I/O expander, SPI interface

-  
MCP23017

-  
16-bit I/O expander, I2C interface

-  
MCP23S17

-  
16-bit I/O expander, SPI interface

-  
MCP23018

-  
16-bit I/O expander, open-drain outputs, I2C interface

-  
MCP23S18

-  
16-bit I/O expander, open-drain outputs, SPI interface

-

-
Access to the pins is provided by the gpio(4)
-    interface.

-
The SPI version of these devices support multiple chips per chip
-    select signal. On the MCP23S08 and MCP23S17, this is achieved by tying the
-    address select pins to VDD or GND to select an address (0-3 on MCP23S08 or
-    0-7 on MCP23S17). The MCP23S18 has a similar capability, but uses an analog
-    voltage input on a single address select pin, along with an internal voltage
-    divider ladder and a series of comparators to generate the 3 address bits;
-    see the data sheet for details. The flags argument in
-    the configuration directive for SPI attachments selects the hardware address
-    of the chip instance for that driver instance.

-

-

-

-
gpio(4), iic(4),
-    intro(4), spi(4)

-

-

-

-
The mcpgpio driver first appeared in
-    NetBSD 7.0. It was overhauled in
-    NetBSD 10.0 to support additional chip types and to
-    add the I2C attachment.

-

-

-

-
The mcpgpio driver was written by
-    Frank Kardel
-    <kardel@NetBSD.org>
-    and Jason R. Thorpe
-    <thorpej@NetBSD.org>.

-

-

-

-
SPI instances of the mcpgpio driver do not
-    utilize the Device Tree bindings for this device.

-
The mcpgpio driver does not currently act
-    as a GPIO provider for the platform device tree.

-

-

-
-  
-    
-    
-  
-
January 10, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/mcx.4 3.html b/static/netbsd/man4/mcx.4 3.html
deleted file mode 100644
index 6541969d..00000000
--- a/static/netbsd/man4/mcx.4 3.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
MCX(4)Device Drivers ManualMCX(4)

-

-

-

-
mcx — Mellanox 5th
-    generation Ethernet device

-

-

-

-
mcx* at pci? dev ? function ?

-

-

-

-
The mcx driver supports Mellanox 5th
-    generation Ethernet devices. Chipsets and cards in this group include:

-

-
    
-  
  • ConnectX-4 Lx EN
    • 
-  
  • ConnectX-4 EN
    • 
-  
  • ConnectX-5 EN
    • 
-  
  • ConnectX-6 EN
    • 
-  
  • ConnectX-6 Dx EN
    • 
-  
  • ConnectX-6 Lx EN
    • 
-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The mcx driver first appeared in
-    OpenBSD 6.6 and in NetBSD
-    9.0.

-

-

-

-
The mcx driver was written by
-    Jonathan Matthew
-    <jmatthew@openbsd.org>
-    and
-  

-  David Gwynne
-    <dlg@openbsd.org> for
-    OpenBSD and ported to NetBSD
-    by
-  

-  Jared McNeill
-    <jmcneill@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 26, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/md.4 4.html b/static/netbsd/man4/md.4 4.html
deleted file mode 100644
index e98c640f..00000000
--- a/static/netbsd/man4/md.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
MD(4)Device Drivers ManualMD(4)

-

-

-

-
md — memory disk
-    driver

-

-

-

-
pseudo-device md

-

-

-

-
The md driver enables use of system or
-    user memory as a disk. Memory for the disk must be allocated within the
-    kernel or with mdconfig(8) before the
-    md device may be used as a disk. Its behaviour is
-    configured by the kernel options
-    ,
-    ,
-    ,
-    ,
-    and
-    .

-

-

-

-

-  
/dev/md??

-  
block mode memory disk devices.

-  
/dev/rmd??

-  
raw mode memory disk devices.

-

-

-

-

-
options(4), mdconfig(8),
-    mdsetimage(8)

-

-

-
-  
-    
-    
-  
-
November 30, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/mfb.4 4.html b/static/netbsd/man4/mfb.4 4.html
deleted file mode 100644
index 940c5f65..00000000
--- a/static/netbsd/man4/mfb.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
MFB(4)Device Drivers ManualMFB(4)

-

-

-

-
mfb — PMAG-A MX
-    monochrome unaccelerated 2-D framebuffer

-

-

-

-
mfb* at tc? slot ? offset ?
-  

-  wsdisplay* at mfb?

-

-

-

-
The mfb driver provides support for the
-    PMAG-A MX monochrome framebuffer for the TURBOchannel bus. The PMAG-A is a
-    monochrome framebuffer capable of running at a resolution of 1280-by-1024 at
-    72 Hz.

-

-

-

-
cfb(4), px(4),
-    pxg(4), sfb(4), tc(4),
-    tfb(4), wscons(4)

-

-

-
-  
-    
-    
-  
-
August 22, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/mfi.4 4.html b/static/netbsd/man4/mfi.4 4.html
deleted file mode 100644
index 4d3aca84..00000000
--- a/static/netbsd/man4/mfi.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
MFI(4)Device Drivers ManualMFI(4)

-

-

-

-
mfi — LSI Logic
-    & Dell MegaRAID SAS RAID controller

-

-

-

-
mfi* at pci? dev ? function ?

-

-

-

-
The mfi driver provides support for the
-    MegaRAID SAS family of RAID controllers, including:

-

-
    
-  
  • Dell PERC 5/e, PERC 5/i, PERC 6/e, PERC 6/i, PERC H310, PERC H700, PERC
-      H800
    • 
-  
  • Intel RAID Controller SRCSAS18E, SRCSAS144E
    • 
-  
  • LSI Logic MegaRAID SAS 8208ELP, MegaRAID SAS 8208XLP, MegaRAID SAS
-      8300XLP, MegaRAID SAS 8308ELP, MegaRAID SAS 8344ELP, MegaRAID SAS 8408E,
-      MegaRAID SAS 8480E, MegaRAID SAS 8708ELP, MegaRAID SAS 8880EM2, MegaRAID
-      SAS 8888ELP, MegaRAID SAS 9260-8i, MegaRAID SAS 9261-8i, MegaRAID SAS
-      9265-8i
    • 
-  
  • IBM ServeRAID M1015, ServeRAID M5014
    • 
-

-
These controllers support RAID 0, RAID 1, RAID 5, RAID 6, RAID 10,
-    RAID 50 and RAID 60 using either SAS or SATA II drives.

-
Although the controllers are actual RAID controllers, the driver
-    makes them look just like SCSI controllers. All RAID configuration is done
-    through the controllers' BIOSes.

-
mfi supports monitoring of the logical
-    disks in the controller through the bioctl(8) and
-    envstat(8) commands.

-

-

-

-
The mfi driver is able to send events to
-    powerd(8) if a logical drive in the controller is not
-    online. The
-    
-    event will be sent to the
-    /etc/powerd/scripts/sensor_drive script when such
-    condition happens.

-

-

-

-
intro(4), pci(4),
-    scsi(4), sd(4),
-    bioctl(8), envstat(8),
-    powerd(8)

-

-

-

-
The mfi driver first appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
May 5, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/mfii.4 4.html b/static/netbsd/man4/mfii.4 4.html
deleted file mode 100644
index 13945136..00000000
--- a/static/netbsd/man4/mfii.4 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
MFII(4)Device Drivers ManualMFII(4)

-

-

-

-
mfii — LSI Logic
-    MegaRAID SAS Fusion RAID controller

-

-

-

-
mfii* at pci?

-

-

-

-
The mfii driver provides support for the
-    MegaRAID SAS Fusion family of RAID controllers using the following
-  chipsets:

-

-
    
-  
  • SAS2208
    • 
-  
  • SAS3008
    • 
-  
  • SAS3108
    • 
-  
  • SAS3216
    • 
-  
  • SAS3224
    • 
-  
  • SAS3316
    • 
-  
  • SAS3324
    • 
-  
  • SAS3404
    • 
-  
  • SAS3408
    • 
-  
  • SAS3416
    • 
-  
  • SAS3504
    • 
-  
  • SAS3508
    • 
-  
  • SAS3516
    • 
-  
  • SAS3908
    • 
-  
  • SAS3916
    • 
-

-
These controllers support RAID 0, RAID 1, RAID 5, RAID 6, RAID 10,
-    RAID 50 and RAID 60 using either SAS or SATA II drives.

-
Although the controllers are actual RAID controllers, they appear
-    as SCSI controllers. All RAID configuration is done through the controllers'
-    BIOSes.

-
mfii supports monitoring of the logical
-    disks in the controller through the bioctl(8) and
-    envstat(8) commands.

-

-

-

-
The mfii driver is able to send events to
-    powerd(8) if a logical drive in the controller is not
-    online. The
-    
-    event will be sent to the
-    /etc/powerd/scripts/sensor_drive script when such
-    condition happens.

-

-

-

-
bio(4), intro(4),
-    pci(4), scsi(4),
-    sd(4), bioctl(8),
-    envstat(8), powerd(8)

-

-

-

-
The mfii driver first appeared in
-    OpenBSD 5.3 and NetBSD
-  8.0.

-

-

-

-
The mfii driver was written by
-    David Gwynne
-    <dlg@openbsd.org>.

-

-

-
-  
-    
-    
-  
-
July 16, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/mhzc.4 4.html b/static/netbsd/man4/mhzc.4 4.html
deleted file mode 100644
index f0f9ceb8..00000000
--- a/static/netbsd/man4/mhzc.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
MHZC(4)Device Drivers ManualMHZC(4)

-

-

-

-
mhzc — Megahertz
-    Ethernet/modem card driver

-

-

-

-
mhzc* at pcmcia? function ?
-  

-  com* at mhzc?
-  

-  sm* at mhzc?

-

-

-

-
The mhzc device driver provides support
-    for the Megahertz combined Ethernet and modem cards.

-

-

-

-
com(4), pcmcia(4),
-    sm(4)

-

-

-

-
The mhzc driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
February 18, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/micphy.4 4.html b/static/netbsd/man4/micphy.4 4.html
deleted file mode 100644
index 51af5898..00000000
--- a/static/netbsd/man4/micphy.4 4.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
MICPHY(4)Device Drivers ManualMICPHY(4)

-

-

-

-
micphy — Micrel
-    KSZ8xxx 10/100 and KSZ9xxx 10/100/1000 PHY driver

-

-

-

-
micphy* at mii? phy ?

-

-

-

-
The micphy driver currently supports
-    KSZ80[2345689]1, KSZ87[23]x, KSZ90[23]1, KSZ9131 and KSZ9477. It also
-    supports LAN7430's internal PHY. The driver has a fixup for
-    evbarm/cpsw(4) which requires Gig-E PHYs to adjust RGMII
-    signal timing.

-

-

-

-
evbarm/cpsw(4), ifmedia(4),
-    intro(4), mii(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 6, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/midi.4 3.html b/static/netbsd/man4/midi.4 3.html
deleted file mode 100644
index 95f05fd4..00000000
--- a/static/netbsd/man4/midi.4 3.html	
+++ /dev/null
@@ -1,454 +0,0 @@
-
-  
-    
-    
-    
-  
-
MIDI(4)Device Drivers ManualMIDI(4)

-

-

-

-
midi —
-    device-independent MIDI driver layer

-

-

-

-
midi* at midibus?
-  

-  midi* at pcppi?
-  

-  pseudo-device sequencer

-

-  

-  #include <sys/types.h>
-  

-  #include <sys/midiio.h>

-

-

-

-
The midi driver is the machine independent
-    layer over anything that can source or sink a MIDI data stream, whether a
-    physical MIDI IN or MIDI OUT jack on a soundcard, cabled to some external
-    synthesizer or input controller, an on-board programmable tone generator, or
-    a single jack, synthesizer, or controller component within a complex USB or
-    IEEE1394 MIDI device that has several such components and appears as several
-    MIDI streams.

-

-

-
One MIDI data stream is a unidirectional stream of MIDI messages,
-    as could be carried over one MIDI cable in the MIDI 1.0 specification. Many
-    MIDI messages carry a four-bit channel number, creating up to 16 MIDI
-    channels within a single MIDI stream. There may be multiple consumers of a
-    MIDI stream, each configured to react only to messages on specific channels;
-    the sets of channels different consumers react to need not be disjoint. Many
-    modern devices such as multitimbral keyboards and tone generators listen on
-    all 16 channels, or may be viewed as collections of 16 independent consumers
-    each listening on one channel. MIDI defines some messages that take no
-    channel number, and apply to all consumers of the stream on which they are
-    sent. For an inbound stream, midi is a promiscuous
-    receiver, capturing all messages regardless of channel number. For an
-    outbound stream, the writer can specify a channel number per message; there
-    is no notion of binding the stream to one destination channel in
-  advance.

-
A single midi device instance is the
-    endpoint of one outbound stream, one inbound stream, or one of each. In the
-    third case, the write and read sides are independent MIDI streams. For
-    example, a soundcard driver may map its MIDI OUT and MIDI IN jacks to the
-    write and read sides of a single device instance, but those jacks can be
-    cabled to completely different pieces of gear. Information from
-    dmesg(8), and a diagram of any external MIDI cabling, will
-    help clarify the mapping.

-

-

-

-
Drivers midi can attach include soundcard
-    drivers, many of which support a UART resembling Roland's MPU401 and handled
-    by mpu(4), USB MIDI devices via
-    umidi(4), and on-board devices that can make sounds,
-    whether a lowly PC speaker or a Yamaha OPL. Serial port and IEEE1394
-    connections are currently science fiction.

-
The MIDI protocol permits some forms of message compression such
-    as running status and hidden note-off. Received messages on inbound streams
-    are always canonicalized by midi before presentation
-    to higher layers. Messages for transmission are accepted by
-    midi in any valid form.

-

-

-

-
Access to midi device instances can be
-    through the raw device nodes, /dev/rmidiN, or
-    through the sequencer, /dev/music.

-

-

-

-
A /dev/rmidiN device supports
-    read(2), write(2),
-    ioctl(2),
-    select(2)/poll(2) and the corresponding
-    kevent(2) filters, and may be opened only when it is not
-    already open. It may be opened in O_RDONLY,
-    O_WRONLY, or O_RDWR mode,
-    but a later read(2) or write(2) will
-    return -1 if the device has no associated input or output stream,
-    respectively.

-
Bytes written are passed as quickly as possible to the underlying
-    driver as complete MIDI messages; a maximum of two bytes at the end of a
-    write(2) may remain buffered if they do not complete a
-    message, until completed by a following write(2).

-
A read(2) will not block or return
-    EWOULDBLOCK when it could immediately return any
-    nonzero count, and MIDI messages received are available to
-    read(2) as soon as they are complete, with a maximum of
-    two received bytes remaining buffered if they do not complete a message.

-
As all MIDI messages are three bytes or fewer except for System
-    Exclusive, which can have arbitrary length, these rules imply that System
-    Exclusive messages are the only ones of which some bytes can be delivered
-    before all are available.

-
System Realtime messages are passed with minimum delay in either
-    direction, ahead of any possible buffered incomplete message. As a result,
-    they will never interrupt any MIDI message except possibly System
-  Exclusive.

-
A read(2) with a buffer large enough to
-    accommodate the first complete message available will be satisfied with as
-    many complete messages as will fit. A buffer too small for the first
-    complete message will be filled to capacity. Therefore, an application that
-    reads from an rmidi device with buffers of three
-    bytes or larger need never parse across read boundaries to assemble a
-    received message, except possibly in the case of a System Exclusive message.
-    However, if the application reads through a buffering layer such as
-    fread(3), this property will not be preserved.

-
The midi driver itself supports the
-    ioctl(2) operations FIOASYNC,
-    FIONBIO, and FIONREAD.
-    Underlying devices may support others. The value returned for
-    FIONREAD reflects the size in bytes of complete
-    messages (or System Exclusive chunks) ready to read. If the
-    ioctl(2) returns n and a
-    read(2) of size n is issued,
-    n bytes will be read, but if a
-    read(2) of size m <
-    n is issued, fewer than m bytes
-    may be read if m does not fall on a message/chunk
-    boundary.

-
Raw MIDI access can be used to receive bulk dumps from
-    synthesizers, download bulk data to them, and so on. Simple patching of one
-    device to another can be done at the command line, as with

-
$ cat -u 0<>/dev/rmidi0
-  1>&0

-which will loop all messages received on the input stream of
-  rmidi0 input stream back to its output stream in real
-  time. However, an attempt to record and play back music with
-
$ cat /dev/rmidiN >foo; cat foo
-  >/dev/rmidiN

-will be disappointing. The file foo will contain all of
-  the notes that were played, but because MIDI messages carry no explicit
-  timing, the ‘playback’ will reproduce them all at once, as fast
-  as they can be transmitted. To preserve timing information, the sequencer
-  device can be used.
-

-

-

-
The MIDI protocol includes a keepalive function called Active
-    Sensing. In any receiver that has
-     received
-    at least one Active Sense MIDI message, the feature is suppressed and no
-    timeout applies. If at least one such message has been received, the lapse
-    of any subsequent 300 ms interval without receipt of any message reflects
-    loss of communication, and the receiver should silence any currently
-    sounding notes and return to non-Active-Sensing behavior. A sender using
-    Active Sensing generally avoids 300 ms gaps in transmission by sending
-    Active Sense messages (which have no other effect) as needed when there is
-    no other traffic to send in the interval. This feature can be important for
-    MIDI, which relies on separate Note On and Note Off messages, to avoid notes
-    stuck on indefinitely if communication is interrupted before a Note Off
-    message arrives.

-
This protocol is supported in midi. An
-    outbound stream will be kept alive by sending Active Sense messages as
-    needed, beginning after any real traffic is sent on the stream, and
-    continuing until the stream is closed. On an inbound stream, if any Active
-    Sense has been received, then a process reading an
-    rmidi device will see an end-of-file indication if
-    the input timeout elapses. The stream remains open, the driver reverts to
-    enforcing no timeout, and the process may continue to read for more input.
-    Subsequent receipt of an Active Sense message will re-arm the timeout. As
-    received Active Sense messages are handled by midi,
-    they are not included among messages read from the
-    /dev/rmidiN device.

-
These rules support end-to-end Active Sensing behavior in simple
-    cases without special action in an application. For example, in

-
$ cat -u /dev/rmidi0
-  >/dev/rmidi1

-if the input stream to rmidi0 is lost, the
-  cat(1) command exits; on the close(2) of
-  rmidi1, midi ceases to send
-  Active Sense messages, and the receiving device will detect the loss and
-  silence any outstanding notes.
-

-

-

-
To play music using the raw MIDI API would require an application
-    to issue many small writes with very precise timing. The sequencer device,
-    /dev/music, can manage the timing of MIDI data in
-    the kernel, to avoid such demanding real-time constraints on a user
-  process.

-
The /dev/music device can be opened only
-    when it is not already open. When opened, the sequencer internally opens all
-    MIDI instances existing in the system that are not already open at their raw
-    nodes; any attempts to open them at their raw nodes while the sequencer is
-    open will fail. All access to the corresponding MIDI streams will then be
-    through the sequencer.

-
Reads and writes of /dev/music pass
-    eight-byte event structures defined in
-    <sys/midiio.h> (which see
-    for their documentation and examples of use). Some events correspond to MIDI
-    messages, and carry an integer device field to
-    identify one of the MIDI devices opened by the sequencer. Other events carry
-    timing information interpreted or generated by the sequencer itself.

-
A message received on an input stream is wrapped in a sequencer
-    event along with the device index of the stream it arrived on, and queued
-    for the reader of /dev/music. If a measurable time
-    interval passed since the last preceding message, a timing event that
-    represents a delay for that interval is queued ahead of the received event.
-    The sequencer handles output events by interpreting any timing event, and
-    routing any MIDI message event at the proper time to an underlying output
-    stream according to its device index. Therefore

-
$ cat /dev/music >foo; cat foo
-  >/dev/music

-can be expected to capture and reproduce an input performance including timing.
-
The process of playing back a complex MIDI file is illustrated
-    below. The file may contain several tracks—four, in this
-    example—of MIDI events, each marked with a device index and a time
-    stamp, that may overlap in time. In the example, a,
-    b, and c are device indices of
-    the three output MIDI streams; the left-hand digit in each input event
-    represents a MIDI channel on the selected stream, and the right-hand digit
-    represents a time for the event's occurrence. As illustrated, the input
-    tracks are not firmly associated with output streams; any track may contain
-    events for any stream.

-

-
     |      |     a2|4     |
-   a0|3     |     c1|3   c0|3
-     |    b0|2    b1|2     |
-     |    b1|1      |    c0|1
-   a0|0     |     b0|0     |
-     v      v       v      v
-  +---------------------------+
-  | merge to 1 ordered stream |
-  | user code, eg midiplay(1) |
-  +---------------------------+
-              b1|2
-              b0|2
-              c0|1
-              b1|1
-              b0|0
-              a0|0
-                v
-  _______+-------------+_______user
-         | /dev/music  |     kernel
-         | (sequencer) |
-         +-------------+
-           |    1    0
-     +-----'    |    '-----.
-     0          0          |
-     v          v          v
-  +-------+ +--------+ +---------+
-  |midi(4)| |midi(4) | |midi(4)  |
-  |rmidia | |rmidib  | |rmidic   |
-  +-------+ +--------+ +---------+
-  | mpu(4)| |umidi(4)| |midisyn  |
-  +-------+ +--------+ +---------+
-  |  HW   |     |      | opl(4)  |
-  | MIDI  |     U      +---------+
-  | UART  |      S     | internal|
-  +-------+       B    |   tone  |
-      |           |    |generator|
-      v           |    +---------+
-   external       v
-  MIDI device  external
-              MIDI device

-

-
A user process must merge the tracks into a single stream of
-    sequencer MIDI and timing events in order by desired timing. The sequencer
-    obeys the timing events and distributes the MIDI events to the three
-    destinations, in this case two external devices connected to a sound card
-    UART and a USB interface, and an OPL tone generator on a sound card.

-

-

-

-

-
Use of select(2)/poll(2) with
-    the sequencer is supported, however, there is no guarantee that a
-    write(2) will not block or return
-    EWOULDBLOCK if it begins with a timer-wait event,
-    even if select(2)/poll(2) reported the
-    sequencer writable.

-
The delivery of a realtime message ahead of buffered bytes of an
-    incomplete message may cause the realtime message to seem, in a saved byte
-    stream, to have arrived up to 640 us earlier than it really did, at MIDI 1.0
-    data rates. Higher data rates make the effect less significant.

-
Another sequencer device, /dev/sequencer,
-    is provided only for backward compatibility with an obsolete OSS interface
-    in which some sequencer events were four-byte records. It is not further
-    documented here, and the /dev/music API should be
-    used in new code. The /dev/sequencer emulation is
-    implemented only for writing, and that might not be complete.

-

-

-

-
Some hardware devices supporting midi lack
-    transmit-ready interrupts, and some have the capability in hardware but
-    currently lack driver support. They can be recognized by the annotation
-    (CPU-intensive output) in
-    dmesg(8). While suitable for music playback, they may have
-    an objectionable impact on system responsiveness during bulk transmission
-    such as patch downloads, and are best avoided for that purpose if other
-    suitable devices are present.

-
Buffer space in midi itself is adequate
-    for about 200 ms of traffic at MIDI 1.0 data rates, per stream.

-
Event counters record bytes and messages discarded because of
-    protocol errors or buffer overruns, and can be viewed with
-    vmstat -e. They can be useful in diagnosing flaky
-    cables and other communication problems.

-
A raw sound generator uses the midisyn layer to
-    present a MIDI message-driven interface attachable by
-    midi.

-
While midi accepts messages for
-    transmission in any valid mixture of compressed or canonical form, they are
-    always presented to an underlying driver in the form it prefers. Drivers for
-    simple UART-like devices register their preference for a compressed byte
-    stream, while those like umidi(4), which uses a packet
-    protocol, or midisyn, which interprets complete messages,
-    register for intact canonical messages. This design eliminates the need for
-    compression and canonicalization logic from all layers above and below
-    midi itself.

-

-

-

-

-  
/dev/rmidiN

-  
 

-  
/dev/music

-  
 

-  
/dev/sequencer

-  
 

-

-

-

-

-
In addition to other errors documented for the
-    write(2) family of system calls,
-    EPROTO can be returned if the bytes to be written on
-    a raw midi device would violate MIDI protocol.

-

-

-

-
midiplay(1), midirecord(1),
-    ioctl(2), ossaudio(3),
-    audio(4), mpu(4),
-    opl(4), umidi(4)

-
For ports using the ISA bus: cms(4),
-    pcppi(4), sb(4)

-
For ports using the PCI bus: autri(4),
-    clcs(4), eap(4)

-

-

-

-
The midi driver first appeared in
-    NetBSD 1.4. It was overhauled and this manual page
-    rewritten for NetBSD 4.0.

-

-

-

-
Some OSS sequencer events and ioctl(2)
-    operations are unimplemented, as
-    <sys/midiio.h> notes.

-
OSS source-compatible sequencer macros should be added to
-    <sys/soundcard.h>,
-    implemented with the NetBSD ones in
-    <sys/midiio.h>, so sources
-    written for OSS can be easily compiled.

-
The sequencer blocks (or returns
-    EWOULDBLOCK) only when its buffer physically fills,
-    which can represent an arbitrary latency because of buffered timing events.
-    As a result, interrupting a process writing the sequencer may not interrupt
-    music playback for a considerable time. The sequencer could enforce a
-    reasonable latency bound by examining timing events as they are enqueued and
-    blocking appropriately.

-
FIOASYNC enables signal delivery to the
-    calling process only; FIOSETOWN is not
-  supported.

-
The sequencer can only be a timing master, but does not send
-    timing messages to synchronize any slave device; it cannot be slaved to
-    timing messages received on any interface (which would presumably require a
-    PLL algorithm similar to NTP's, and expertise in that area to implement it).
-    The sequencer ignores timing messages received on any interface and does not
-    pass them along to the reading process, and the OSS operations to change
-    that behavior are unimplemented.

-
The SEQUENCER_TMR_TIMEBASE
-    ioctl(2) will report successfully setting any timebase up
-    to ridiculously high resolutions, though the actual resolution, and
-    therefore jitter, is constrained by hz(9). Comparable
-    sequencer implementations typically allow a selection from available sources
-    of time interrupts that may be programmable.

-
The device number in a sequencer event is treated on
-    write(2) as index into the array of MIDI devices the
-    sequencer has opened, but on read(2) as the unit number of
-    the source MIDI device; these are usually the same if the sequencer has
-    opened all the MIDI devices (that is, none was already open at its raw node
-    when the sequencer was opened), but might not be the same otherwise.

-
There is at present no way to make reception nonpromiscuous,
-    should anyone have a reason to want to.

-
There should be ways to override default Active Sense behavior. As
-    one obvious case, if an application is seen to send Active Sense explicitly,
-    midi should refrain from adding its own. On receive,
-    there should be an option to pass Active Sense through rather than
-    interpreting it, for apps that wish to handle or ignore it themselves and
-    never see EOF.

-
When a midi stream is open by the
-    sequencer, Active Sense messages received on the stream are passed to the
-    sequencer and not interpreted by midi. The sequencer
-    at present neither does anything itself with Active Sense messages received,
-    nor supports the OSS API for making them available to the user process.

-
System Exclusive messages can be received by reading a raw device,
-    but not by reading the sequencer; they are discarded on receipt when the
-    stream is open by the sequencer, rather than being presented as the
-    OSS-defined sequencer events.

-
midisyn is too rudimentary at present to get
-    satisfactory results from any onboard synth. It lacks the required special
-    interpretation of the General MIDI percussion channel in GM mode. More
-    devices should be supported; some sound cards with synthesis capability have
-    NetBSD drivers that implement the
-    audio(4) but not the midisyn interface.
-    Voice stealing algorithm does not follow the General MIDI Developer
-    Guidelines.

-
ALSA sequencer compatibility is lacking, but becoming important to
-    applications. It would require the function of merging multiple tracks into
-    a single ordered stream to be moved from user space into the sequencer.
-    Assuming the sequencer driven by periodic interrupts, timing wheels could be
-    used as in hardclock(9) itself. Similar functionality will
-    be in OSS4; with the right infrastructure it should be possible to support
-    both. When merging MIDI streams, a notion of transaction is needed to group
-    critical message sequences. If ALSA or OSS4 have no such notion, it should
-    be provided as an upward-compatible extension.

-
I would rather have open(2) itself return an
-    error (by the POSIX description ENODEV looks most
-    appropriate) if a read or write mode is requested that is not supported by
-    the instance, rather than letting open(2) succeed and
-    read(2) or write(2) return -1, but so
-    help me, the latter seems the more common UNIX
-    practice.

-

-

-
-  
-    
-    
-  
-
April 28, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/mii.4 3.html b/static/netbsd/man4/mii.4 3.html
deleted file mode 100644
index e78b437b..00000000
--- a/static/netbsd/man4/mii.4 3.html	
+++ /dev/null
@@ -1,144 +0,0 @@
-
-  
-    
-    
-    
-  
-
MII(4)Device Drivers ManualMII(4)

-

-

-

-
mii — IEEE 802.3
-    Media Independent Interface network bus

-

-

-

-
acphy* at mii? phy ?		# Altima AC101 10/100
-    PHY
-  

-  amhphy* at mii? phy ?		# AMD 79c901 PHY (10BASE-T
-    part)
-  

-  bmtphy* at mii? phy ?		# Broadcom BCM5201/5202 PHYs
-  

-  brgphy* at mii? phy ?		# Broadcom BCM5400/5401 Gig-E
-    PHYs
-  

-  ciphy* at mii? phy ?		# Cicada CS8201 Gig-E PHYs
-  

-  dmphy* at mii? phy ?		# Davicom DM9101 PHYs
-  

-  exphy* at mii? phy ?		# 3Com internal PHYs
-  

-  gentbi* at mii? phy ?		# Generic ten-bit 1000BASE-X
-    PHYs
-  

-  glxtphy* at mii? phy ?		# Level One LXT-1000 Gig-E
-    PHYs
-  

-  gphyter* at mii? phy ?		# NatSemi DP83861 Gig-E PHYs
-  

-  icsphy* at mii? phy ?		# Integrated Circuit Systems ICS1890
-    PHYs
-  

-  ikphy* at mii? phy ?		# Intel 82563 PHYs
-  

-  inphy* at mii? phy ?		# Intel 82555 PHYs
-  

-  iophy* at mii? phy ?		# Intel 82553 PHYs
-  

-  ipgphy* at mii? phy ?		# IC PLUS IP1000A/IP1001 PHYs
-  

-  jmphy* at mii? phy ?		# JMicron
-  

-  lxtphy* at mii? phy ?		# Level One LXT-970 PHYs
-  

-  makphy* at mii? phy ?		# Marvel 88E1000 Gig-E PHYs
-  

-  micphy* at mii? phy ?		# Micrel KSZ9021 Gig-E PHYs
-  

-  nsphy* at mii? phy ?		# NatSemi DP83840 PHYs
-  

-  nsphyter* at mii? phy ?		# NatSemi DP83843/DP83815
-    PHYs
-  

-  pnaphy* at mii? phy ?		# Generic HomePNA PHYs
-  

-  qsphy* at mii? phy ?		# Quality Semiconductor QS6612
-    PHYs
-  

-  rgephy* at mii? phy ?		# Realtek 8169S/8110S internal
-    PHYs
-  

-  rlphy* at mii? phy ?		# Realtek 8139/8201L PHYs
-  

-  smscphy* at mii? phy ?		# SMSC LAN87xx PHYs
-  

-  sqphy* at mii? phy ?		# Seeq 80220/80221/80223/80225
-    PHYs
-  

-  tlphy* at mii? phy ?		# ThunderLAN internal PHYs
-  

-  tqphy* at mii? phy ?		# TSC Semiconductor 78Q2120 PHYs
-  

-  ukphy* at mii? phy ?		# Generic/unknown PHYs
-  

-  urlphy* at mii? phy ?		# Realtek RTL8150L internal
-    PHYs

-

-  

-  options MIIVERBOSE

-

-

-

-
Media Independent Interface is an IEEE standard serial bus for
-    connecting MACs (network controllers) to PHYs (physical media interfaces).
-    The mii layer allows network device drivers to share
-    support code for various PHY models, and allows unused support for PHYs
-    which are not present in a system to be removed from the kernel.

-
Network device drivers which use the mii
-    layer carry the “mii” autoconfiguration attribute. This allows
-    kernel configuration files to simply specify PHYs as described above in the
-    synopsis.

-
The following is an example of the messages displayed when a
-    network interface with an attached PHY is detected by the kernel:

-

-
epic0 at pci0 dev 12 function 0: SMC EPIC/100 Fast Ethernet
-epic0: interrupting at kn20aa irq 4
-epic0: SMC9432TX, Ethernet address 00:e0:29:07:17:c4
-qsphy0 at epic0 phy 3: QS6612 10/100 media interface, rev. 1
-qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

-

-
All PHY drivers display the media types supported by the PHY when
-    it is detected by the kernel. These media types are valid media keywords for
-    use with the ifconfig(8) program.

-

-

-

-
acphy(4), amhphy(4),
-    bmtphy(4), brgphy(4),
-    ciphy(4), dmphy(4),
-    exphy(4), gentbi(4),
-    glxtphy(4), gphyter(4),
-    icsphy(4), ifmedia(4),
-    ikphy(4), inphy(4),
-    iophy(4), jmphy(4),
-    lxtphy(4), makphy(4),
-    micphy(4), nsphy(4),
-    nsphyter(4), pnaphy(4),
-    qsphy(4), rgephy(4),
-    rlphy(4), smscphy(4),
-    sqphy(4), tlphy(4),
-    tqphy(4), ukphy(4),
-    urlphy(4), ifconfig(8)

-
The OUI assignments list can be found at:
-    http://standards.ieee.org/regauth/oui/index.shtml

-

-

-
-  
-    
-    
-  
-
November 2, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/mk48txx.4 4.html b/static/netbsd/man4/mk48txx.4 4.html
deleted file mode 100644
index df0ea143..00000000
--- a/static/netbsd/man4/mk48txx.4 4.html	
+++ /dev/null
@@ -1,146 +0,0 @@
-
-  
-    
-    
-    
-  
-
MK48TXX(4)Device Drivers ManualMK48TXX(4)

-

-

-

-
mk48txx — Mostek
-    time-of-day clock driver

-

-

-

-
#include
-    <dev/ic/mk48txxreg.h>
-  

-  #include
-  <dev/ic/mk48txxvar.h>

-
define mk48txx
-  

-  file dev/ic/mk48txx.c mk48txx

-

-

-

-
The mk48txx driver provides access to
-    several models of Mostek time-of-day clock chips. Access methods to retrieve
-    and set date and time are provided through the
-    
-    interface defined in todr(9).

-
To tie an instance of this device to the
-    system, use the
-    ()
-    function and the mk48txx_softc structure defined as follows:

-
void
-    (struct
-    mk48txx_softc *)

-

-
typedef uint8_t (*mk48txx_nvrd_t)(struct mk48txx_softc *, int off);
-typedef void (*mk48txx_nvwr_t)(struct mk48txx_softc *, int off,
-    uint8_t datum);

-

-

-
struct mk48txx_softc {
-	struct device   sc_dev;
-	bus_space_tag_t sc_bst;
-	bus_space_handle_t sc_bsh;
-	struct todr_chip_handle sc_handle;
-	const char	*sc_model;
-	bus_size_t	sc_nvramsz;
-	bus_size_t	sc_clkoffset;
-	u_int		sc_year0;
-	u_int		sc_flag;
-	mk48txx_nvrd_t	sc_nvrd;
-	mk48txx_nvwr_t	sc_nvwr;
-};

-

-

-

-  
sc_bst

-  
 

-  
sc_bsh

-  
Specify bus space access to the chip's non-volatile memory (including the
-      clock registers).

-  
sc_handle

-  
TODR handle passed to the
-      ()
-      function to register todr(9) interface.

-  
sc_model

-  
The chip model which this instance should serve. Must be one of
-      “mk48t02”, “mk48t08”, “mk48t18”,
-      or “mk48t59”.

-  
sc_nvramsz

-  
Size of non-volatile RAM in the Mostek chip. This value is set by
-      mk48txx_attach().

-  
sc_clkoffset

-  
Offset into the control registers of the Mostek chip. This value is set by
-      mk48txx_attach().

-  
sc_year0

-  
The actual year represented by the clock's ‘year’ counter.
-      This is generally dependent on the system configuration in which the clock
-      device is mounted. For instance, on Sun Microsystems machines the
-      convention is to have clock's two-digit year represent the year 1968.

-  
sc_flag

-  
This flag is used to specify machine-dependent features.

-  
sc_nvread

-  
 

-  
sc_nvwrite

-  
Specify alternate access methods for reading resp. writing clock device
-      registers. The default, when NULL is passed as an
-      access method, is to access the chip memory (and clock registers) as if
-      they were direct-mapped with using the specified bus space.
-    
Otherwise, the driver will call the respective function to
-        perform the access, passing it the specified bus space and the offset
-        off of the chip memory (or clock register)
-        location to be read from or written to, respectively.

-  

-

-

-
Note that if the resulting date retrieved with the todr_gettime()
-    method is earlier that January 1, 1970, the driver will assume that the
-    chip's year counter actually represents a year in the 21st century. This
-    behaviour can be overridden by setting the
-    MK48TXX_NO_CENT_ADJUST flag in
-    sc_flag.

-

-

-

-
The following models are supported:

-

-

-

-  
Mostek MK48T02

-  
 

-  
Mostek MK48T08

-  
 

-  
Mostek MK48T18

-  
 

-  
Mostek MK48T59

-  
 

-

-

-

-

-

-
intro(4), todr(9)

-

-

-

-
The mk48txx driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The mk48txx driver was written by
-    Paul Kranenburg ⟨pk@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
October 1, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/mlx.4 4.html b/static/netbsd/man4/mlx.4 4.html
deleted file mode 100644
index 79150bec..00000000
--- a/static/netbsd/man4/mlx.4 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
MLX(4)Device Drivers ManualMLX(4)

-

-

-

-
mlx — Mylex DAC960
-    RAID controller driver

-

-

-

-
mlx* at eisa? slot ?
-  

-  mlx* at pci? dev ? function ?

-

-

-

-
The mlx driver provides support for the
-    Mylex DAC960 family of RAID controllers, including OEM versions from Compaq
-    and DEC. Attached disk arrays are supported by the
-    ld driver.

-
The mlx driver will warn if a controller
-    firmware upgrade may be necessary, although as a matter of course, the
-    latest available firmware should always be used.

-

-

-

-
Supported controllers include:

-

-

-

-  
DEC/Compaq SWXCR

-  
 

-  
Mylex AcceleRAID 150

-  
 

-  
Mylex AcceleRAID 200

-  
 

-  
Mylex AcceleRAID 250

-  
 

-  
Mylex DAC1164P (eXtremeRAID 1100)

-  
 

-  
Mylex DAC960P

-  
 

-  
Mylex DAC960PD

-  
 

-  
Mylex DAC960PG

-  
 

-  
Mylex DAC960PJ

-  
 

-  
Mylex DAC960PL

-  
 

-  
Mylex DAC960PR

-  
 

-  
Mylex DAC960PRL

-  
 

-  
Mylex DAC960PT

-  
 

-  
Mylex DAC960PTL0

-  
 

-  
Mylex DAC960PTL1

-  
 

-

-

-

-

-

-
intro(4), ld(4),
-    mly(4), mlxctl(8)

-

-

-

-
The mlx driver first appeared in
-    NetBSD 1.5.3, and was derived from the
-    FreeBSD driver of the same name.

-

-

-
-  
-    
-    
-  
-
January 10, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/mly.4 4.html b/static/netbsd/man4/mly.4 4.html
deleted file mode 100644
index 6991e19c..00000000
--- a/static/netbsd/man4/mly.4 4.html	
+++ /dev/null
@@ -1,365 +0,0 @@
-
-  
-    
-    
-    
-  
-
MLY(4)Device Drivers ManualMLY(4)

-

-

-

-
mly — Mylex
-    AcceleRAID/eXtremeRAID family driver

-

-

-

-
mly* at pci? dev ? function ?
-  

-  scsibus* at mly?

-

-

-

-
The mly driver provides support for Mylex
-    AcceleRAID and eXtremeRAID family of PCI to SCSI RAID controllers with
-    version 6.00 and later firmware. Supported controllers include:

-

-
    
-  
  • AcceleRAID 160
    • 
-  
  • AcceleRAID 170
    • 
-  
  • AcceleRAID 352
    • 
-  
  • eXtremeRAID 2000
    • 
-  
  • eXtremeRAID 3000
    • 
-

-
Compatible Mylex controllers not listed should work, but have not
-    been tested.

-
Logical devices (disk arrays) attached to the controller are
-    presented to the SCSI subsystem as though they were direct-access devices on
-    a virtual SCSI bus. Physical devices which are not claimed by a logical
-    device are presented on SCSI channels which match the physical channels on
-    the controller.

-
The results of the SCSI ``INQUIRY'' command from logical devices
-    are overwritten with status information by the mly
-    driver. The vendor field is the string ``MYLEX'', the product field
-    indicates the type of logical device, and the revision field contains a four
-    letter status code. The possible status codes and their meanings are as
-    follows:

-

-

-  
OFLN

-  
offline

-  
UNCF

-  
unconfigured

-  
ONLN

-  
online - optimal

-  
CRIT

-  
critical - one or more disks in the array has failed

-  
NORD

-  
write only

-  
STBY

-  
standby

-  
MISS

-  
missing

-

-

-

-

-

-

-

-  
mly%d: controller initialization started

-  

-  
mly%d: initialization complete

-  

-    
The controller firmware has started initialization. Normally
-        this process is performed by the controller BIOS, but the driver may
-        need to do this in cases where the BIOS has failed, or is not compatible
-        (e.g. on non-x86 systems).

-  

-  
mly%d: drive spinup in progress

-  

-    
Drive startup is in progress; this may take several
-      minutes.

-  

-  
mly%d: mirror race recovery failed, one or more drives offline

-  

-  
mly%d: mirror race recovery in progress

-  

-  
mly%d: mirror race recovery on a critical drive

-  

-    
These error codes are undocumented.

-  

-  
mly%d: FATAL MEMORY PARITY ERROR

-  

-    
Firmware detected a fatal memory error; the driver will not
-        attempt to attach to this controller.

-  

-  
mly%d: unknown initialization code %x

-  

-    
An unknown error occurred during initialization; it will be
-        ignored.

-  

-

-

-

-

-

-  
mly%d: physical device %d:%d online

-  

-  
mly%d: physical device %d:%d standby

-  

-  
mly%d: physical device %d:%d automatic rebuild started

-  

-  
mly%d: physical device %d:%d manual rebuild started

-  

-  
mly%d: physical device %d:%d rebuild completed

-  

-  
mly%d: physical device %d:%d rebuild cancelled

-  

-  
mly%d: physical device %d:%d rebuild failed for unknown reasons

-  

-  
mly%d: physical device %d:%d rebuild failed due to new physical
-    device

-  

-  
mly%d: physical device %d:%d rebuild failed due to logical drive
-    failure

-  

-  
mly%d: physical device %d:%d found

-  

-  
mly%d: physical device %d:%d gone

-  

-  
mly%d: physical device %d:%d unconfigured

-  

-  
mly%d: physical device %d:%d expand capacity started

-  

-  
mly%d: physical device %d:%d expand capacity completed

-  

-  
mly%d: physical device %d:%d expand capacity failed

-  

-  
mly%d: physical device %d:%d parity error

-  

-  
mly%d: physical device %d:%d soft error

-  

-  
mly%d: physical device %d:%d miscellaneous error

-  

-  
mly%d: physical device %d:%d reset

-  

-  
mly%d: physical device %d:%d active spare found

-  

-  
mly%d: physical device %d:%d warm spare found

-  

-  
mly%d: physical device %d:%d initialization started

-  

-  
mly%d: physical device %d:%d initialization completed

-  

-  
mly%d: physical device %d:%d initialization failed

-  

-  
mly%d: physical device %d:%d initialization cancelled

-  

-  
mly%d: physical device %d:%d write recovery failed

-  

-  
mly%d: physical device %d:%d scsi bus reset failed

-  

-  
mly%d: physical device %d:%d double check condition

-  

-  
mly%d: physical device %d:%d device cannot be accessed

-  

-  
mly%d: physical device %d:%d gross error on scsi processor

-  

-  
mly%d: physical device %d:%d bad tag from device

-  

-  
mly%d: physical device %d:%d command timeout

-  

-  
mly%d: physical device %d:%d system reset

-  

-  
mly%d: physical device %d:%d busy status or parity error

-  

-  
mly%d: physical device %d:%d host set device to failed state

-  

-  
mly%d: physical device %d:%d selection timeout

-  

-  
mly%d: physical device %d:%d scsi bus phase error

-  

-  
mly%d: physical device %d:%d device returned unknown status

-  

-  
mly%d: physical device %d:%d device not ready

-  

-  
mly%d: physical device %d:%d device not found at startup

-  

-  
mly%d: physical device %d:%d COD write operation failed

-  

-  
mly%d: physical device %d:%d BDT write operation failed

-  

-  
mly%d: physical device %d:%d missing at startup

-  

-  
mly%d: physical device %d:%d start rebuild failed due to physical drive
-    too small

-  

-  
mly%d: physical device %d:%d sense data received

-  

-  
mly%d: sense key %d asc %02x ascq %02x

-  

-  
mly%d: info %4D csi %4D

-  

-  
mly%d: physical device %d:%d offline

-  

-  
mly%d: sense key %d asc %02x ascq %02x

-  

-  
mly%d: info %4D csi %4D

-  

-    
The reported event refers to the physical device at the given
-        channel:target address.

-  

-  
mly%d: logical device %d:%d consistency check started

-  

-  
mly%d: logical device %d:%d consistency check completed

-  

-  
mly%d: logical device %d:%d consistency check cancelled

-  

-  
mly%d: logical device %d:%d consistency check completed with errors

-  

-  
mly%d: logical device %d:%d consistency check failed due to logical drive
-    failure

-  

-  
mly%d: logical device %d:%d consistency check failed due to physical
-    device failure

-  

-  
mly%d: logical device %d:%d automatic rebuild started

-  

-  
mly%d: logical device %d:%d manual rebuild started

-  

-  
mly%d: logical device %d:%d rebuild completed

-  

-  
mly%d: logical device %d:%d rebuild cancelled

-  

-  
mly%d: logical device %d:%d rebuild failed for unknown reasons

-  

-  
mly%d: logical device %d:%d rebuild failed due to new physical device

-  

-  
mly%d: logical device %d:%d rebuild failed due to logical drive
-    failure

-  

-  
mly%d: logical device %d:%d offline

-  

-  
mly%d: logical device %d:%d critical

-  

-  
mly%d: logical device %d:%d online

-  

-  
mly%d: logical device %d:%d initialization started

-  

-  
mly%d: logical device %d:%d initialization completed

-  

-  
mly%d: logical device %d:%d initialization cancelled

-  

-  
mly%d: logical device %d:%d initialization failed

-  

-  
mly%d: logical device %d:%d found

-  

-  
mly%d: logical device %d:%d gone

-  

-  
mly%d: logical device %d:%d expand capacity started

-  

-  
mly%d: logical device %d:%d expand capacity completed

-  

-  
mly%d: logical device %d:%d expand capacity failed

-  

-  
mly%d: logical device %d:%d bad block found

-  

-  
mly%d: logical device %d:%d size changed

-  

-  
mly%d: logical device %d:%d type changed

-  

-  
mly%d: logical device %d:%d bad data block found

-  

-  
mly%d: logical device %d:%d read of data block in bdt

-  

-  
mly%d: logical device %d:%d write back data for disk block lost

-  

-    
The reported event refers to the logical device at the given
-        channel:target address.

-  

-  
mly%d: enclosure %d fan %d failed

-  

-  
mly%d: enclosure %d fan %d ok

-  

-  
mly%d: enclosure %d fan %d not present

-  

-  
mly%d: enclosure %d power supply %d failed

-  

-  
mly%d: enclosure %d power supply %d ok

-  

-  
mly%d: enclosure %d power supply %d not present

-  

-  
mly%d: enclosure %d temperature sensor %d failed

-  

-  
mly%d: enclosure %d temperature sensor %d critical

-  

-  
mly%d: enclosure %d temperature sensor %d ok

-  

-  
mly%d: enclosure %d temperature sensor %d not present

-  

-  
mly%d: enclosure %d unit %d access critical

-  

-  
mly%d: enclosure %d unit %d access ok

-  

-  
mly%d: enclosure %d unit %d access offline

-  

-    
These events refer to external enclosures by number. The
-        driver does not attempt to name the enclosures.

-  

-  
mly%d: controller cache write back error

-  

-  
mly%d: controller battery backup unit found

-  

-  
mly%d: controller battery backup unit charge level low

-  

-  
mly%d: controller battery backup unit charge level ok

-  

-  
mly%d: controller installation aborted

-  

-  
mly%d: controller mirror race recovery in progress

-  

-  
mly%d: controller mirror race on critical drive

-  

-  
mly%d: controller memory soft ecc error

-  

-  
mly%d: controller memory hard ecc error

-  

-  
mly%d: controller battery backup unit failed

-  

-    
These events report controller status changes.

-  

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), mlx(4),
-    scsi(4), sd(4), st(4),
-    scsictl(8)

-

-

-

-
The mly driver first appeared in
-    NetBSD 1.6, and was based on the
-    FreeBSD driver of the same name.

-

-

-

-
The mly driver currently assumes that all
-    busses support at most 16 targets and 1 logical unit per target.

-
Enclosures are not named or otherwise identified in event
-    messages.

-
The transfer speed for devices is always reported to the kernel as
-    20MHz.

-

-

-
-  
-    
-    
-  
-
July 29, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/mos.4 4.html b/static/netbsd/man4/mos.4 4.html
deleted file mode 100644
index 8775dd49..00000000
--- a/static/netbsd/man4/mos.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
MOS(4)Device Drivers ManualMOS(4)

-

-

-

-
mos — MosChip
-    MCS7730/7830/7832 10/100 USB Ethernet device

-

-

-

-
mos* at uhub?

-

-

-

-
The mos driver provides support for USB
-    Ethernet adapters based on the MosChip MCS7730, MCS7830, and MCS7832 USB 2.0
-    chipsets, including the following:

-

-

-

-  
Delock 61147

-  
 

-  
Sitecom LN-030

-  
 

-  
Syba SY-U2LAN

-  
 

-

-

-
All adapters operate with either USB 1.x, 2.0, or 3.x controllers,
-    though performance with 1.x controllers is limited since the USB 1.x
-    standard specifies a maximum transfer speed of 12Mbps. Users with USB 1.x
-    controllers should therefore not expect to actually achieve 100Mbps speeds
-    with these devices.

-
A 64-bit multicast hash table is supported, single perfect filter
-    entry for the station address, all-multicast mode, and promiscuous mode.
-    Packets are received and transmitted over separate USB bulk transfer
-    endpoints.

-
The mos driver supports the following
-    media types:

-

-  
autoselect

-  
Enable autoselection of the media type and options (this is the default).
-      The user can manually override the autoselected mode by adding media
-      options to the appropriate ifconfig.if(5) file.

-  
10baseT

-  
Set 10Mbps operation.

-  
100baseTX

-  
Set 100Mbps (Fast Ethernet) operation.

-

-
The mos driver supports the following
-    media options:

-

-  
full-duplex

-  
Force full-duplex operation.

-  
half-duplex

-  
Force half-duplex operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    usb(4), usbnet(4),
-    ifconfig.if(5), ifconfig(8),
-    usbnet(9)

-
MosChip India,
-    http://www.moschip.com.

-

-

-

-
The mos driver first appeared in
-    OpenBSD 4.5. It was ported to
-    NetBSD by Matthew R. Green
-    <mrg@eterna23.net>
-    and first appeared in NetBSD 10.0.

-

-

-

-
The mos driver was written by
-    Johann Christian Rode
-    <jcrode@gmx.net>.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/mpii.4 4.html b/static/netbsd/man4/mpii.4 4.html
deleted file mode 100644
index c2dcb843..00000000
--- a/static/netbsd/man4/mpii.4 4.html	
+++ /dev/null
@@ -1,90 +0,0 @@
-
-  
-    
-    
-    
-  
-
MPII(4)Device Drivers ManualMPII(4)

-

-

-

-
mpii — LSI Logic
-    Fusion-MPT Message Passing Interface II

-

-

-

-
mpii* at pci? dev ? function ?

-

-

-

-
The mpii driver provides support for
-    storage controllers using the LSI Logic Fusion-MPT Message Passing Interface
-    II family of chipsets:

-

-
    
-  
  • LSISAS2004, LSISAS2008, LSISAS2108, LSISAS2208, LSISAS2216, LSISAS2308,
-      LSISAS3004, LSISAS3008, LSISAS3108, LSISAS3408, LSISAS3416, LSISAS3508,
-      LSISAS3516
    • 
-

-
These chipsets can be found on the following controllers:

-

-
    
-  
  • Dell PERC H200, HBA330, 12Gbps SAS HBA
    • 
-  
  • IBM ServeRAID H1110
    • 
-  
  • Lenovo N2215, ThinkSystem 430
    • 
-  
  • LSI SAS 9200-8e, SAS 9207-8i, SAS 9211-4i, SAS 9211-8i
    • 
-  
  • Broadcom SAS 9300, HBA 9400
    • 
-

-
Some models of these controllers carry an Integrated RAID (IR)
-    firmware providing support for RAID 0, RAID 1, RAID10 or RAID5 using SAS or
-    SATA drives. All RAID configuration is done through the controllers'
-  BIOSes.

-
mpii supports monitoring of the logical
-    disks in the controller through the bioctl(8) and
-    envstat(8) commands.

-

-

-

-
The mpii driver is able to send events to
-    powerd(8) if a logical drive in the controller is not
-    online. The
-    
-    event will be sent to the
-    /etc/powerd/scripts/sensor_drive script when such
-    condition happens.

-

-

-

-
bio(4), intro(4),
-    pci(4), scsi(4),
-    sd(4), bioctl(8),
-    envstat(8), powerd(8)

-

-

-

-
The mpii driver first appeared in
-    OpenBSD 4.7. NetBSD support
-    was added in NetBSD 6.0.

-

-

-

-
The mpii driver was written by
-    James Giannoules and Mike
-    Belopuhov.

-

-

-

-
The chips supported by mpii do not use a
-    SCSI-like identifier. Instead they use an opaque ID and leave discovery
-    order up to the operating system. The code to handle this is currently not
-    implemented and therefore it is not a good idea to run this driver on a
-    multi-boot machine.

-

-

-
-  
-    
-    
-  
-
May 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/mpl115a.4 4.html b/static/netbsd/man4/mpl115a.4 4.html
deleted file mode 100644
index 1d831c22..00000000
--- a/static/netbsd/man4/mpl115a.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
MPL115A(4)Device Drivers ManualMPL115A(4)

-

-

-

-
mpl115a —
-    Freescale MPL115A2 absolute pressure sensor
-  driver

-

-

-

-
mpl115a* at iic? addr 0x60

-

-

-

-
The mpl115a driver provides support for
-    the MPL115A2 pressure sensor. It allows reporting absolute pressure through
-    the envsys(4) API.

-

-

-

-
envsys(4)

-

-

-

-
The mpl115a device first appeared in
-    NetBSD 7.0.

-

-

-

-
The mpl115a driver was written by
-    Radoslaw Kujawa
-    ⟨radoslaw.kujawa@gmail.com⟩. The fixed-point pressure
-    calculation algorithm was suggested by Matt
-  Thomas.

-

-

-

-
The MPL115A2 chip has an accuracy of +/- 1 kPa, which makes it not
-    very useful for weather-related applications.

-
The envsys(4) API does not support pressure
-    reporting yet, so the result is reported just as integer number.

-

-

-
-  
-    
-    
-  
-
September 8, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/mpls.4 3.html b/static/netbsd/man4/mpls.4 3.html
deleted file mode 100644
index 1a36be39..00000000
--- a/static/netbsd/man4/mpls.4 3.html	
+++ /dev/null
@@ -1,261 +0,0 @@
-
-  
-    
-    
-    
-  
-
MPLS(4)Device Drivers ManualMPLS(4)

-

-

-

-
mpls —
-    Multiprotocol Label Switching

-

-

-

-
options MPLS
-  

-  pseudo-device mpls
-  

-  #include <sys/types.h>
-  

-  #include <netmpls/mpls.h>

-

-

-

-
MultiProtocol Label Switching represents a mechanism which directs
-    and carries data in high-performance networks, its techniques being
-    applicable to any network layer protocol.

-
In an MPLS domain the assignment of a particular packet a
-    particular Forward Equivalence Class is done just once, as the packet enters
-    the network. The FEC to which the packet is assigned is encoded as a short
-    fixed length value known as a “label”. When a packet is
-    forwarded to the next hop, the label is sent along with it; that is, the
-    packets are “labeled” before they are forwarded.

-
A router capable of receiving and forwarding MPLS frames is called
-    “Label Switch Router” or LSR. Label scope is generally
-    router-wide meaning that a certain label has a specific meaning only for a
-    certain LSR.

-
Currently, NetBSD supports MPLS over
-    Ethernet interfaces and GRE tunnels. For these kind of interfaces, a label
-    is contained by a fixed sized “shim” that precedes any network
-    layer headers, just after data link layer headers.

-

-

-
In network bit order:

-

-
-------------------------------------------
-|               |        |       |        |
-| Label         | TC     | BoS   | TTL    |
-| 20 bits       | 3 bits | 1 bit | 8 bits |
-|               |        |       |        |
--------------------------------------------

-

-

-  
Label

-  
20 bits representing FEC, consequently the only information used to
-      forward the frame to next-hop

-  
Traffic Class Field

-  
3 bits that are used for specifying a traffic class, usually used for
-      defining a type of service. This field was named the "Experimental
-      Field" in most early (pre-RFC 5462)
-      documents.

-  
Bottom of Stack

-  
One bit that is set for the last entry in the shim stack and 0 for all
-      others. An MPLS frame may contain more than one shim, the last one before
-      the network headers being marked by setting the BoS bit.

-  
TTL

-  
8 bits, representing Time to Live, decremented at every LSR.

-

-

-

-

-

-
The MPLS behavior is controlled by the
-    net.mpls sysctl(8) tree:

-

-  

-  
If zero, MPLS frames are dropped on sight on ingress interfaces.

-  

-  
If zero, MPLS frames are not forwarded to next-hop.

-  

-  
The default ttl for self generated MPLS frames.

-  

-  
If set, TTL field from IP header will be mapped into the MPLS shim on
-      encapsulation, and the TTL field from MPLS shim will be copied into IP
-      header on decapsulation.

-  

-  
The IPv6 version of the above.

-  

-  
If set, precedence field from IP header will be mapped into MPLS shim in
-      TC field on encapsulation, and the MPLS TC field will be copied into IP
-      Precedence field on decapsulation.

-  

-  
The IPv6 version of the above.

-  

-  
Returns ICMP TTL exceeded in transit when an MPLS frame is dropped because
-      of TTL = 0 on egress interface.

-  

-  
Pop the Explicit Null labels as specified by RFC
-      4182

-

-In order to encapsulate and decapsulate to and from MPLS, an mpls
-  pseudo-interface must be created and packets that should be encapsulated must
-  be routed to that interface.
-
MPLS routes may be created using AF_MPLS
-    sa_family sockaddrs for destination and tag fields.
-    Other protocols can be encapsulated using routes pointing to mpls
-    pseudo-interfaces, and AF_MPLS sockaddrs for tags.
-    Decapsulation can be made using values of reserved labels set in the tag
-    field (see below). For more information about doing this using userland
-    utilities see the EXAMPLES section of
-    this manual page.

-
The netstat(1) and route(8)
-    utilities should be used to manage routes from userland.

-
The NetBSD implementation stores route
-    tagging information into a sockaddr_mpls structure that is referenced by the
-    rt_tag field of rtentry struct. For storing multiple labels associated with
-    the next-hop, the current implementation abuses the sockaddr_mpls structure,
-    extending it in order to fit a stack of labels.

-
ldpd(8) should be used in order to automatically
-    import, manage and distribute labels among LSRs in the same MPLS domain.

-

-

-
MPLS labels 0 through 15 are reserved. Out of those, only four are
-    currently defined:

-

-  
0

-  
IPv4 Explicit NULL label. This label value is only legal at the bottom of
-      the label stack. It indicates that the label stack must be popped, and the
-      forwarding of the packet must then be based on the IPv4 header.

-  
1

-  
Router Alert Label. Currently not implemented in
-      NetBSD.

-  
2

-  
IPv6 Explicit NULL label. It indicates that the label stack must be
-      popped, and the forwarding of the packet must then be based on the IPv6
-      header.

-  
3

-  
Implicit NULL label. This is a label that an LSR may assign and
-      distribute, but which never actually appears in the encapsulation. When an
-      LSR would otherwise replace the label at the top of the stack with a new
-      label, but the new label is “Implicit NULL”, the LSR will
-      pop the stack instead of doing the replacement. In this case, the LSR will
-      have to deduce by itself what is the original address family of the
-      encapsulated network packet. Currently, NetBSD
-      implementation is assuming that the latter address family is equal to the
-      next-hop address family specified in the Implicit Null Label MPLS
-    route.

-

-

-

-

-

-
    
-  
  1. Create an MPLS interface and set an IP address:
-    
    
-    
    # ifconfig mpls0 create up
-# ifconfig mpls0 inet 192.168.0.1/32
    
-    
    
-  
    2. 
-  
  2. Route IP packets into MPLS domain with a specific tag
-    
    
-    
    # route add 10.0.0.0/8 -ifp mpls0 -tag 25 -inet 192.168.1.100
    
-    
    
-  
    3. 
-  
  3. Create a static MPLS forwarding rule - swap the incoming label 50 to 33
-      and forward the frame to 192.168.1.101 and verify the route
-    
    
-    
    # route add -mpls 50 -tag 33 -inet 192.168.1.101
-add host 50: gateway 192.168.1.101
-# route -n get -mpls 50
-   route to: 50
-destination: 50
-    gateway: 192.168.1.101
-        Tag: 33
- local addr: 192.168.1.180
-  interface: sk0
-      flags: <UP,GATEWAY,HOST,DONE,STATIC>
-recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
-      0         0         0         0         0         0         0         0
-sockaddrs: <DST,GATEWAY,IFP,IFA,TAG>
    
-    
    
-  
    4. 
-  
  4. Route IP packets into MPLS domain but use a different source address for
-      local generated packets.
-    
    
-    
    # route add 10.0.0.0/8 -ifa 192.168.1.180 -ifp mpls0 -tag 25 -inet 192.168.1.100
    
-    
    
-    For the latter example, setting an IP address for the mpls0 interface is not
-      necessary.
    5. 
-  
  5. Route MPLS packets encapsulated with label 60 to 192.168.1.100 and POP
-      label
-    
    
-    
    # route add -mpls 60 -tag 3 -inet 192.168.1.100
    
-    
    
-  
    6. 
-  
  6. Route IP packets into MPLS domain and prepend more tags
-    
    
-    
    # route add 10/8 -ifa 192.168.1.200 -ifp mpls0 -tag 20,30,40 -inet 192.168.1.100
    
-    
    
-    For the above example, tag 20 will be inserted at Bottom of Stack, while tag
-      40 will be set into the outermost shim.
    7. 
-  
  7. Replace label 60 with label 30, prepend two more labels: 40 and 41 (in
-      this order) and forward the result to 192.168.1.100
-    
    
-    
    # route add -mpls 60 -tag 30,40,41 -inet 192.168.1.100
    
-    
    
-  
    8. 
-

-

-

-

-
netstat(1), route(4),
-    ldpd(8), route(8),
-    sysctl(8)

-
Multiprotocol Label Switching
-    Architecture, RFC 3031.

-
MPLS Label Stack
-    Encoding, RFC 3032.

-
Removing a Restriction on the
-    use of MPLS Explicit NULL, RFC
-  4182.

-
MPLS Label Stack Entry: EXP
-    Field Renamed to Traffic Class Field, RFC
-    5462.

-

-

-

-
The mpls support appeared in
-    NetBSD 6.0.

-

-

-

-
User must be aware that encapsulating IP packets in MPLS implies a
-    major security effect when using firewalls. Currently neither
-    ipf(4) nor pf(4) implement the
-    heuristics in order to look inside an MPLS frame. Moreover, it's technically
-    impossible in most cases for an LSR to know information related to
-    encapsulated packet. Therefore, MPLS Domains should be strictly controlled
-    and, in most cases, limited to trusted connections inside the same
-    Autonomous System.

-
Users must be aware that the MPLS forwarding domain is entirely
-    separated from the inner (IP, IPv6 etc.) forwarding domain and once a packet
-    is encapsulated in MPLS, the former forwarding is used. This could result in
-    a different path for MPLS encapsulated packets than the original non-MPLS
-    one.

-
IP or IPv6 forwarding is not necessary for MPLS forwarding. Your
-    system may still forward IP or IPv6 packets encapsulated into MPLS if
-    net.mpls.forwarding is set.

-

-

-
-  
-    
-    
-  
-
September 14, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/mpt.4 4.html b/static/netbsd/man4/mpt.4 4.html
deleted file mode 100644
index da3940b3..00000000
--- a/static/netbsd/man4/mpt.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
MPT(4)Device Drivers ManualMPT(4)

-

-

-

-
mpt — LSI
-    Fusion-MPT SCSI/Fibre Channel driver

-

-

-

-
mpt* at pci? dev ? function ?
-  

-  scsibus* at mpt?

-

-

-

-
The mpt driver provides support for the
-    LSI Logic Fusion-MPT family of SCSI and Fibre Channel and SAS
-  controllers:

-

-
    
-  
  • 53c1020 (Ultra320 SCSI)
    • 
-  
  • 53c1030 (Dual Ultra320 SCSI)
    • 
-  
  • AS1068 (SAS/SATA)
    • 
-  
  • FC909 (1Gb/s Fibre Channel)
    • 
-  
  • FC909A (Dual 1Gb/s Fibre Channel)
    • 
-  
  • FC919 (2Gb/s Fibre Channel)
    • 
-  
  • FC919X (2Gb/s Fibre Channel, PCI-X)
    • 
-  
  • FC929 (Dual 2Gb/s Fibre Channel)
    • 
-  
  • FC929X (Dual 2Gb/s Fibre Channel, PCI-X)
    • 
-

-

-

-

-
bio(4), cd(4),
-    ch(4), intro(4),
-    pci(4), scsi(4),
-    sd(4), siop(4), st(4),
-    uk(4)

-

-

-

-
The mpt driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The mpt driver was originally written for
-    FreeBSD by Greg Ansley . It was ported to
-    NetBSD by Jason R. Thorpe and contributed by Wasabi
-    Systems, Inc.

-

-

-
-  
-    
-    
-  
-
September 27, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/mpu.4 4.html b/static/netbsd/man4/mpu.4 4.html
deleted file mode 100644
index 8d1ff966..00000000
--- a/static/netbsd/man4/mpu.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
MPU(4)Device Drivers ManualMPU(4)

-

-

-

-
mpu — Roland
-    MPU401 (and compatible) MIDI UART driver

-

-

-

-
mpu* at acpi?
-  

-  mpu* at eso?
-  

-  mpu* at fms?
-  

-  mpu* at isa? port 0x330 irq 9
-  

-  mpu* at sb?
-  

-  mpu* at ym?
-  

-  mpu* at yds?
-  

-  midi* at mpu?

-

-

-

-
The mpu driver provides support for the
-    Roland MPU401 (and compatible) MIDI UART cards.

-
Access to the device is through the MIDI driver.

-

-

-

-
eso(4), fms(4),
-    isa(4), midi(4),
-    sb(4), yds(4),
-  ym(4)

-

-

-

-
The mpu device driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
December 2, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/msm6242b.4 4.html b/static/netbsd/man4/msm6242b.4 4.html
deleted file mode 100644
index f2dd5d84..00000000
--- a/static/netbsd/man4/msm6242b.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
MSM6242B(4)Device Drivers ManualMSM6242B(4)

-

-

-

-
msm6242b — OKI
-    MSM6242B time-of-day clock driver

-

-

-

-
#include
-    <dev/ic/msm6242breg.h>
-  

-  #include
-    <dev/ic/msm6242bvar.h>

-
define msm6242b
-  

-  file dev/ic/msm6242b.c msm6242b

-

-

-

-
The msm6242b driver provides access to the
-    OKI MSM6242B time-of-day clock chip. Access methods to retrieve and set date
-    and time are provided through the
-    
-    interface defined in todr(9).

-

-

-

-
todr(9)

-

-

-

-
The msm6242b driver first appeared in
-    NetBSD 7.0.

-

-

-

-
The msm6242b driver was written by
-    Radoslaw Kujawa
-    ⟨radoslaw.kujawa@gmail.com⟩. It was inspired by an earlier
-    amiga-specific driver by Christian E. Hopps.

-

-

-
-  
-    
-    
-  
-
November 14, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/mtd.4 4.html b/static/netbsd/man4/mtd.4 4.html
deleted file mode 100644
index 5ff505b0..00000000
--- a/static/netbsd/man4/mtd.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
MTD(4)Device Drivers ManualMTD(4)

-

-

-

-
mtd — Driver for
-    Myson Technologies MTD803 3-in-1 Fast Ethernet board

-

-

-

-
mtd* at pci?

-

-

-

-
The mtd device driver supports the MTD803
-    PCI Ethernet chip.

-
Supported models include:

-
    
-  
  • Safeway Lancard SW-10/100 PCI (model 117204). Please note that some cards
-      sold under this name are supported by rtk(4)
-    instead.
    • 
-

-

-

-

-
intro(4), mii(4),
-    pci(4), rtk(4),
-    ifconfig(8)

-

-

-

-
The mtd driver appeared in
-    NetBSD 2.0.

-

-

-

-
Peter Bex
-    <Peter.Bex@student.kun.nl>

-

-

-

-
This driver has not been tested on any architecture besides i386.
-    It does not handle DMA cache flushes at all, so it will very likely not work
-    on other architectures that require this.

-
Power management is missing.

-
A CardBus variant is rumored to exist, but support for it has not
-    been added to the driver yet.

-

-

-
-  
-    
-    
-  
-
November 8, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/mtio.4 3.html b/static/netbsd/man4/mtio.4 3.html
deleted file mode 100644
index c8e97305..00000000
--- a/static/netbsd/man4/mtio.4 3.html	
+++ /dev/null
@@ -1,120 +0,0 @@
-
-  
-    
-    
-    
-  
-
MTIO(4)Device Drivers ManualMTIO(4)

-

-

-

-
mtio — generic
-    magnetic tape I/O interface

-

-

-

-
#include
-    <sys/ioctl.h>
-  

-  #include <sys/types.h>
-  

-  #include <sys/mtio.h>

-

-

-

-
Magnetic tape has been the computer system backup and data
-    transfer medium of choice for decades, because it has historically been
-    cheaper in cost per bit stored, and the formats have been designed for
-    portability and storage. However, tape drives have generally been the
-    slowest mass storage devices attached to any computer system.

-
Magnetic tape comes in a wide variety of formats, from classic
-    9-track, through various Quarter Inch Cartridge (QIC) variants, to more
-    modern systems using 8mm video tape, and Digital Audio Tape (DAT). There
-    have also been a variety of proprietary tape systems, including DECtape, and
-    IBM 3480.

-

-

-
Regardless of the specific characteristics of the particular tape
-    transport mechanism (tape drive), UNIX tape I/O has
-    two interfaces: "block" and "raw". I/O through the block
-    interface of a tape device is similar to I/O through the block special
-    device for a disk driver: the individual read(2) and
-    write(2) calls can be done in any amount of bytes, but all
-    data is buffered through the system buffer cache, and I/O to the device is
-    done in 1024 byte sized blocks. This limitation is sufficiently restrictive
-    that the block interface to tape devices is rarely used.

-
The "raw" interface differs in that all I/O can be done
-    in arbitrary sized blocks, within the limitations for the specific device
-    and device driver, and all I/O is synchronous. This is the most flexible
-    interface, but since there is very little that is handled automatically by
-    the kernel, user programs must implement specific magnetic tape handling
-    routines, which puts the onus of correctness on the application
-  programmer.

-

-

-

-
Each magnetic tape subsystem has a couple of special devices
-    associated with it.

-
The block device is usually named for the driver, e.g.
-    /dev/st0 for unit zero of a st(4)
-    SCSI tape drive.

-
The raw device name is the block device name with an "r"
-    prepended, e.g. /dev/rst0.

-
By default, the tape driver will rewind the tape drive when the
-    device is closed. To make it possible for multiple program invocations to
-    sequentially write multiple files on the same tape, a "no rewind on
-    close" device is provided, denoted by the letter "n"
-    prepended to the name of the device, e.g. /dev/nst0,
-    /dev/nrst0.

-
The mt(1) command can be used to explicitly
-    rewind, or otherwise position a tape at a particular point with the
-    no-rewind device.

-

-

-

-
Two end-of-file (EOF) markers mark the end of a tape (EOT), and
-    one end-of-file marker marks the end of a tape file.

-
By default, the tape driver will write two End Of File (EOF) marks
-    and rewind the tape when the device is closed after the last write.

-
If the tape is not to be rewound it is positioned with the head in
-    between the two tape marks, where the next write will over write the second
-    end-of-file marker.

-
All of the magnetic tape devices may be manipulated with the
-    mt(1) command.

-
A number of ioctl(2) operations are available on
-    raw magnetic tape. Please see
-    <sys/mtio.h> for their
-    definitions.

-
The manual pages for specific tape device drivers should list
-    their particular capabilities and limitations.

-

-

-

-

-
dd(1), mt(1),
-    pax(1), tar(1), st(4),
-    wt(4)

-

-

-

-
The mtio manual appeared in
-    4.2BSD.

-

-

-

-
The status should be returned in a device independent format.

-
If and when NetBSD is updated to deal with
-    non-512 byte per sector disk media through the system buffer cache, perhaps
-    a more sane tape interface can be implemented.

-

-

-
-  
-    
-    
-  
-
January 14, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/mue.4 4.html b/static/netbsd/man4/mue.4 4.html
deleted file mode 100644
index 3792f2c4..00000000
--- a/static/netbsd/man4/mue.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
MUE(4)Device Drivers ManualMUE(4)

-

-

-

-
mue — Microchip
-    LAN75xx/LAN78xx 10/100/Gigabit USB Ethernet device

-

-

-

-
mue* at uhub?
-  

-  ukphy* at mii?

-

-

-

-
The mue driver supports Microchip
-    LAN7500/LAN7505/LAN7515/LAN7850 USB 2.0 Gigabit Ethernet devices
-  including:

-

-

-

-  
StarTech USB21000S2

-  
 

-  
Z-TEK ZE582

-  
 

-

-

-
and LAN7800/LAN7801 USB 3.0 Gigabit Ethernet devices
-  including:

-

-

-

-  
Microchip EVB-LAN7800LC

-  
 

-  
Raspberry Pi 3 Model B+ (USB 2.0)

-  
 

-

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    ukphy(4), usb(4),
-    usbnet(4), ifconfig.if(5),
-    ifconfig(8)

-

-

-

-
The mue device driver first appeared in
-    OpenBSD 6.3 and NetBSD
-  9.0.

-

-

-

-
The mue driver was written by
-    Kevin Lo
-    <kevlo@openbsd.org>
-    for OpenBSD and ported to NetBSD
-    by Rin Okuyama
-    <rin@netbsd.org>.

-

-

-

-
If the media type is set to other than 1000BASE-T full-duplex,
-    data transmission becomes quite unstable. Also, ukphy mistakenly recognizes
-    1000BASE-T half-duplex as a supported media type, although the adapters do
-    not support it.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/multicast.4 3.html b/static/netbsd/man4/multicast.4 3.html
deleted file mode 100644
index f4cbdddc..00000000
--- a/static/netbsd/man4/multicast.4 3.html	
+++ /dev/null
@@ -1,717 +0,0 @@
-
-  
-    
-    
-    
-  
-
MULTICAST(4)Device Drivers ManualMULTICAST(4)

-

-

-

-
multicast —
-    Multicast Routing

-

-

-

-
options MROUTING

-

-  

-  #include <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <netinet/in.h>
-  

-  #include <netinet/ip_mroute.h>
-  

-  #include
-    <netinet6/ip6_mroute.h>

-
int
-  

-  getsockopt(int
-    s, IPPROTO_IP,
-    MRT_INIT,
-    void *optval,
-    socklen_t *optlen);

-
int
-  

-  setsockopt(int
-    s, IPPROTO_IP,
-    MRT_INIT,
-    const void *optval,
-    socklen_t optlen);

-
int
-  

-  getsockopt(int
-    s, IPPROTO_IPV6,
-    MRT6_INIT,
-    void *optval,
-    socklen_t *optlen);

-
int
-  

-  setsockopt(int
-    s, IPPROTO_IPV6,
-    MRT6_INIT,
-    const void *optval,
-    socklen_t optlen);

-

-

-

-
Multicast routing is used to efficiently propagate data packets to
-    a set of multicast listeners in multipoint networks. If unicast is used to
-    replicate the data to all listeners, then some of the network links may
-    carry multiple copies of the same data packets. With multicast routing, the
-    overhead is reduced to one copy (at most) per network link.

-
All multicast-capable routers must run a common multicast routing
-    protocol. The Distance Vector Multicast Routing Protocol (DVMRP) was the
-    first developed multicast routing protocol. Later, other protocols such as
-    Multicast Extensions to OSPF (MOSPF), Core Based Trees (CBT), Protocol
-    Independent Multicast - Sparse Mode (PIM-SM), and Protocol Independent
-    Multicast - Dense Mode (PIM-DM) were developed as well.

-
To start multicast routing, the user must enable multicast
-    forwarding in the kernel (see SYNOPSIS
-    about the kernel configuration options), and must run a multicast routing
-    capable user-level process. From developer's point of view, the programming
-    guide described in the Programming
-    Guide section should be used to control the multicast forwarding in the
-    kernel.

-

-

-
This section provides information about the basic multicast
-    routing API. The so-called “advanced multicast API” is
-    described in the
-    Advanced
-    Multicast API Programming Guide section.

-
First, a multicast routing socket must be open. That socket would
-    be used to control the multicast forwarding in the kernel. Note that most
-    operations below require certain privilege (i.e., root privilege):

-

-
/* IPv4 */
-int mrouter_s4;
-mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);

-

-

-
int mrouter_s6;
-mrouter_s6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);

-

-
Note that if the router needs to open an IGMP or ICMPv6 socket (in
-    case of IPv4 and IPv6 respectively) for sending or receiving of IGMP or MLD
-    multicast group membership messages, then the same
-    mrouter_s4 or mrouter_s6 sockets
-    should be used for sending and receiving respectively IGMP or MLD messages.
-    In case of BSD-derived kernel, it may be possible to
-    open separate sockets for IGMP or MLD messages only. However, some other
-    kernels (e.g., Linux) require that the multicast routing socket must be used
-    for sending and receiving of IGMP or MLD messages. Therefore, for
-    portability reason the multicast routing socket should be reused for IGMP
-    and MLD messages as well.

-
After the multicast routing socket is open, it can be used to
-    enable or disable multicast forwarding in the kernel:

-

-
/* IPv4 */
-int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, (void *)&v, sizeof(v));

-

-

-
/* IPv6 */
-int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_INIT, (void *)&v, sizeof(v));
-...
-/* If necessary, filter all ICMPv6 messages */
-struct icmp6_filter filter;
-ICMP6_FILTER_SETBLOCKALL(&filter);
-setsockopt(mrouter_s6, IPPROTO_ICMPV6, ICMP6_FILTER, (void *)&filter,
-           sizeof(filter));

-

-
After multicast forwarding is enabled, the multicast routing
-    socket can be used to enable PIM processing in the kernel if we are running
-    PIM-SM or PIM-DM (see pim(4)).

-
For each network interface (e.g., physical or a virtual tunnel)
-    that would be used for multicast forwarding, a corresponding multicast
-    interface must be added to the kernel:

-

-
/* IPv4 */
-struct vifctl vc;
-memset(&vc, 0, sizeof(vc));
-/* Assign all vifctl fields as appropriate */
-vc.vifc_vifi = vif_index;
-vc.vifc_flags = vif_flags;
-vc.vifc_threshold = min_ttl_threshold;
-vc.vifc_rate_limit = max_rate_limit;
-memcpy(&vc.vifc_lcl_addr, &vif_local_address, sizeof(vc.vifc_lcl_addr));
-if (vc.vifc_flags & VIFF_TUNNEL)
-    memcpy(&vc.vifc_rmt_addr, &vif_remote_address,
-           sizeof(vc.vifc_rmt_addr));
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc,
-           sizeof(vc));

-

-
The vif_index must be unique per vif. The
-    vif_flags contains the VIFF_*
-    flags as defined in
-    <netinet/ip_mroute.h>. The
-    min_ttl_threshold contains the minimum TTL a multicast
-    data packet must have to be forwarded on that vif. Typically, it would have
-    value of 1. The max_rate_limit contains the maximum
-    rate (in bits/s) of the multicast data packets forwarded on that vif. Value
-    of 0 means no limit. The vif_local_address contains
-    the local IP address of the corresponding local interface. The
-    vif_remote_address contains the remote IP address in
-    case of DVMRP multicast tunnels.

-

-
/* IPv6 */
-struct mif6ctl mc;
-memset(&mc, 0, sizeof(mc));
-/* Assign all mif6ctl fields as appropriate */
-mc.mif6c_mifi = mif_index;
-mc.mif6c_flags = mif_flags;
-mc.mif6c_pifi = pif_index;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MIF, (void *)&mc,
-           sizeof(mc));

-

-
The mif_index must be unique per vif. The
-    mif_flags contains the MIFF_*
-    flags as defined in
-    <netinet6/ip6_mroute.h>. The
-    pif_index is the physical interface index of the
-    corresponding local interface.

-
A multicast interface is deleted by:

-

-
/* IPv4 */
-vifi_t vifi = vif_index;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_VIF, (void *)&vifi,
-           sizeof(vifi));

-

-

-
/* IPv6 */
-mifi_t mifi = mif_index;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DEL_MIF, (void *)&mifi,
-           sizeof(mifi));

-

-
After the multicast forwarding is enabled, and the multicast
-    virtual interfaces are added, the kernel may deliver upcall messages (also
-    called signals later in this text) on the multicast routing socket that was
-    open earlier with MRT_INIT or
-    MRT6_INIT. The IPv4 upcalls have
-    struct igmpmsg header (see
-    <netinet/ip_mroute.h>) with
-    field im_mbz set to zero. Note that this header
-    follows the structure of struct ip with the protocol
-    field ip_p set to zero. The IPv6 upcalls have
-    struct mrt6msg header (see
-    <netinet6/ip6_mroute.h>)
-    with field im6_mbz set to zero. Note that this header
-    follows the structure of struct ip6_hdr with the next
-    header field ip6_nxt set to zero.

-
The upcall header contains field im_msgtype
-    and im6_msgtype with the type of the upcall
-    IGMPMSG_* and MRT6MSG_* for
-    IPv4 and IPv6 respectively. The values of the rest of the upcall header
-    fields and the body of the upcall message depend on the particular upcall
-    type.

-
If the upcall message type is
-    IGMPMSG_NOCACHE or
-    MRT6MSG_NOCACHE, this is an indication that a
-    multicast packet has reached the multicast router, but the router has no
-    forwarding state for that packet. Typically, the upcall would be a signal
-    for the multicast routing user-level process to install the appropriate
-    Multicast Forwarding Cache (MFC) entry in the kernel.

-
An MFC entry is added by:

-

-
/* IPv4 */
-struct mfcctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mfcc_origin, &source_addr, sizeof(mc.mfcc_origin));
-memcpy(&mc.mfcc_mcastgrp, &group_addr, sizeof(mc.mfcc_mcastgrp));
-mc.mfcc_parent = iif_index;
-for (i = 0; i < maxvifs; i++)
-    mc.mfcc_ttls[i] = oifs_ttl[i];
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_MFC,
-           (void *)&mc, sizeof(mc));

-

-

-
/* IPv6 */
-struct mf6cctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mf6cc_origin, &source_addr, sizeof(mc.mf6cc_origin));
-memcpy(&mc.mf6cc_mcastgrp, &group_addr, sizeof(mf6cc_mcastgrp));
-mc.mf6cc_parent = iif_index;
-for (i = 0; i < maxvifs; i++)
-    if (oifs_ttl[i] > 0)
-        IF_SET(i, &mc.mf6cc_ifset);
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MFC,
-           (void *)&mc, sizeof(mc));

-

-
The source_addr and
-    group_addr are the source and group address of the
-    multicast packet (as set in the upcall message). The
-    iif_index is the virtual interface index of the
-    multicast interface the multicast packets for this specific source and group
-    address should be received on. The oifs_ttl[] array
-    contains the minimum TTL (per interface) a multicast packet should have to
-    be forwarded on an outgoing interface. If the TTL value is zero, the
-    corresponding interface is not included in the set of outgoing interfaces.
-    Note that in case of IPv6 only the set of outgoing interfaces can be
-    specified.

-
An MFC entry is deleted by:

-

-
/* IPv4 */
-struct mfcctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mfcc_origin, &source_addr, sizeof(mc.mfcc_origin));
-memcpy(&mc.mfcc_mcastgrp, &group_addr, sizeof(mc.mfcc_mcastgrp));
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_MFC,
-           (void *)&mc, sizeof(mc));

-

-

-
/* IPv6 */
-struct mf6cctl mc;
-memset(&mc, 0, sizeof(mc));
-memcpy(&mc.mf6cc_origin, &source_addr, sizeof(mc.mf6cc_origin));
-memcpy(&mc.mf6cc_mcastgrp, &group_addr, sizeof(mf6cc_mcastgrp));
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DEL_MFC,
-           (void *)&mc, sizeof(mc));

-

-
The following method can be used to get various statistics per
-    installed MFC entry in the kernel (e.g., the number of forwarded packets per
-    source and group address):

-

-
/* IPv4 */
-struct sioc_sg_req sgreq;
-memset(&sgreq, 0, sizeof(sgreq));
-memcpy(&sgreq.src, &source_addr, sizeof(sgreq.src));
-memcpy(&sgreq.grp, &group_addr, sizeof(sgreq.grp));
-ioctl(mrouter_s4, SIOCGETSGCNT, &sgreq);

-

-

-
/* IPv6 */
-struct sioc_sg_req6 sgreq;
-memset(&sgreq, 0, sizeof(sgreq));
-memcpy(&sgreq.src, &source_addr, sizeof(sgreq.src));
-memcpy(&sgreq.grp, &group_addr, sizeof(sgreq.grp));
-ioctl(mrouter_s6, SIOCGETSGCNT_IN6, &sgreq);

-

-
The following method can be used to get various statistics per
-    multicast virtual interface in the kernel (e.g., the number of forwarded
-    packets per interface):

-

-
/* IPv4 */
-struct sioc_vif_req vreq;
-memset(&vreq, 0, sizeof(vreq));
-vreq.vifi = vif_index;
-ioctl(mrouter_s4, SIOCGETVIFCNT, &vreq);

-

-

-
/* IPv6 */
-struct sioc_mif_req6 mreq;
-memset(&mreq, 0, sizeof(mreq));
-mreq.mifi = vif_index;
-ioctl(mrouter_s6, SIOCGETMIFCNT_IN6, &mreq);

-

-

-

-

-
If we want to add new features in the kernel, it becomes difficult
-    to preserve backward compatibility (binary and API), and at the same time to
-    allow user-level processes to take advantage of the new features (if the
-    kernel supports them).

-
One of the mechanisms that allows us to preserve the backward
-    compatibility is a sort of negotiation between the user-level process and
-    the kernel:

-
    
-  
  1. The user-level process tries to enable in the kernel the set of new
-      features (and the corresponding API) it would like to use.
    2. 
-  
  2. The kernel returns the (sub)set of features it knows about and is willing
-      to be enabled.
    3. 
-  
  3. The user-level process uses only that set of features the kernel has
-      agreed on.
    4. 
-

-
To support backward compatibility, if the user-level process does
-    not ask for any new features, the kernel defaults to the basic multicast API
-    (see the Programming Guide
-    section). Currently, the advanced multicast API exists only for IPv4; in the
-    future there will be IPv6 support as well.

-
Below is a summary of the expandable API solution. Note that all
-    new options and structures are defined in
-    <netinet/ip_mroute.h> and
-    <netinet6/ip6_mroute.h>,
-    unless stated otherwise.

-
The user-level process uses new
-    ()/setsockopt()
-    options to perform the API features negotiation with the kernel. This
-    negotiation must be performed right after the multicast routing socket is
-    open. The set of desired/allowed features is stored in a bitset (currently,
-    in uint32_t; i.e., maximum of 32 new features). The
-    new
-    getsockopt()/setsockopt()
-    options are MRT_API_SUPPORT and
-    MRT_API_CONFIG. Example:

-

-
uint32_t v;
-getsockopt(sock, IPPROTO_IP, MRT_API_SUPPORT, (void *)&v, sizeof(v));

-

-
would set in v the
-    pre-defined bits that the kernel API supports. The eight least significant
-    bits in uint32_t are same as the eight possible flags
-    MRT_MFC_FLAGS_* that can be used in
-    mfcc_flags as part of the new definition of
-    struct mfcctl (see below about those flags), which
-    leaves 24 flags for other new features. The value returned by
-    (MRT_API_SUPPORT)
-    is read-only; in other words,
-    setsockopt(MRT_API_SUPPORT)
-    would fail.

-
To modify the API, and to set some specific feature in the kernel,
-    then:

-

-
uint32_t v = MRT_MFC_FLAGS_DISABLE_WRONGVIF;
-if (setsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)&v, sizeof(v))
-    != 0) {
-    return (ERROR);
-}
-if (v & MRT_MFC_FLAGS_DISABLE_WRONGVIF)
-    return (OK);	/* Success */
-else
-    return (ERROR);

-

-
In other words, when
-    (MRT_API_CONFIG)
-    is called, the argument to it specifies the desired set of features to be
-    enabled in the API and the kernel. The return value in
-    v is the actual (sub)set of features that were enabled
-    in the kernel. To obtain later the same set of features that were enabled,
-    then:

-

-
getsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)&v, sizeof(v));

-

-
The set of enabled features is global. In other
-    words,
-    (MRT_API_CONFIG)
-    should be called right after
-    setsockopt(MRT_INIT).

-
Currently, the following set of new features is defined:

-

-
#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 << 0) /* disable WRONGVIF signals */
-#define	MRT_MFC_FLAGS_BORDER_VIF   (1 << 1)  /* border vif              */
-#define MRT_MFC_RP                 (1 << 8)  /* enable RP address	*/
-#define MRT_MFC_BW_UPCALL          (1 << 9)  /* enable bw upcalls	*/

-

-
The advanced multicast API uses a newly defined
-    struct mfcctl2 instead of the traditional
-    struct mfcctl. The original struct
-    mfcctl is kept as is. The new struct mfcctl2
-  is:

-

-
/*
- * The new argument structure for MRT_ADD_MFC and MRT_DEL_MFC overlays
- * and extends the old struct mfcctl.
- */
-struct mfcctl2 {
-        /* the mfcctl fields */
-        struct in_addr  mfcc_origin;       /* ip origin of mcasts       */
-        struct in_addr  mfcc_mcastgrp;     /* multicast group associated*/
-        vifi_t          mfcc_parent;       /* incoming vif              */
-        u_char          mfcc_ttls[MAXVIFS];/* forwarding ttls on vifs   */
-
-        /* extension fields */
-        uint8_t         mfcc_flags[MAXVIFS];/* the MRT_MFC_FLAGS_* flags*/
-        struct in_addr  mfcc_rp;            /* the RP address           */
-};

-

-
The new fields are mfcc_flags[MAXVIFS] and
-    mfcc_rp. Note that for compatibility reasons they are
-    added at the end.

-
The mfcc_flags[MAXVIFS] field is used to set
-    various flags per interface per (S,G) entry. Currently, the defined flags
-    are:

-

-
#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 << 0) /* disable WRONGVIF signals */
-#define	MRT_MFC_FLAGS_BORDER_VIF       (1 << 1) /* border vif          */

-

-
The MRT_MFC_FLAGS_DISABLE_WRONGVIF flag is
-    used to explicitly disable the IGMPMSG_WRONGVIF
-    kernel signal at the (S,G) granularity if a multicast data packet arrives on
-    the wrong interface. Usually, this signal is used to complete the
-    shortest-path switch in case of PIM-SM multicast routing, or to trigger a
-    PIM assert message. However, it should not be delivered for interfaces that
-    are not in the outgoing interface set, and that are not expecting to become
-    an incoming interface. Hence, if the
-    MRT_MFC_FLAGS_DISABLE_WRONGVIF flag is set for some
-    of the interfaces, then a data packet that arrives on that interface for
-    that MFC entry will NOT trigger a WRONGVIF signal. If that flag is not set,
-    then a signal is triggered (the default action).

-
The MRT_MFC_FLAGS_BORDER_VIF flag is used
-    to specify whether the Border-bit in PIM Register messages should be set (in
-    case when the Register encapsulation is performed inside the kernel). If it
-    is set for the special PIM Register kernel virtual interface (see
-    pim(4)), the Border-bit in the Register messages sent to
-    the RP will be set.

-
The remaining six bits are reserved for future usage.

-
The mfcc_rp field is used
-    to specify the RP address (in case of PIM-SM multicast routing) for a
-    multicast group G if we want to perform kernel-level PIM Register
-    encapsulation. The mfcc_rp field is used only if the
-    MRT_MFC_RP advanced API flag/capability has been
-    successfully set by
-    (MRT_API_CONFIG).

-
If the MRT_MFC_RP flag
-    was successfully set by
-    (MRT_API_CONFIG),
-    then the kernel will attempt to perform the PIM Register encapsulation
-    itself instead of sending the multicast data packets to user level (inside
-    IGMPMSG_WHOLEPKT upcalls) for user-level
-    encapsulation. The RP address would be taken from the
-    mfcc_rp field inside the new struct
-    mfcctl2. However, even if the MRT_MFC_RP flag
-    was successfully set, if the mfcc_rp field was set to
-    INADDR_ANY, then the kernel will still deliver an
-    IGMPMSG_WHOLEPKT upcall with the multicast data
-    packet to the user-level process.

-
In addition, if the multicast data packet is too large to fit
-    within a single IP packet after the PIM Register encapsulation (e.g., if its
-    size was on the order of 65500 bytes), the data packet will be fragmented,
-    and then each of the fragments will be encapsulated separately. Note that
-    typically a multicast data packet can be that large only if it was
-    originated locally from the same hosts that performs the encapsulation;
-    otherwise the transmission of the multicast data packet over Ethernet for
-    example would have fragmented it into much smaller pieces.

-
Typically, a multicast routing user-level process would need to
-    know the forwarding bandwidth for some data flow. For example, the multicast
-    routing process may want to timeout idle MFC entries, or in case of PIM-SM
-    it can initiate (S,G) shortest-path switch if the bandwidth rate is above a
-    threshold for example.

-
The original solution for measuring the bandwidth of a dataflow
-    was that a user-level process would periodically query the kernel about the
-    number of forwarded packets/bytes per (S,G), and then based on those numbers
-    it would estimate whether a source has been idle, or whether the source's
-    transmission bandwidth is above a threshold. That solution is far from being
-    scalable, hence the need for a new mechanism for bandwidth monitoring.

-
Below is a description of the bandwidth monitoring mechanism.

-
    
-  
  • If the bandwidth of a data flow satisfies some pre-defined filter, the
-      kernel delivers an upcall on the multicast routing socket to the multicast
-      routing process that has installed that filter.
    • 
-  
  • The bandwidth-upcall filters are installed per (S,G). There can be more
-      than one filter per (S,G).
    • 
-  
  • Instead of supporting all possible comparison operations (i.e., < <=
-      == != > >= ), there is support only for the <= and >=
-      operations, because this makes the kernel-level implementation simpler,
-      and because practically we need only those two. Further, the missing
-      operations can be simulated by secondary user-level filtering of those
-      <= and >= filters. For example, to simulate !=, then we need to
-      install filter “bw <= 0xffffffff”, and after an upcall is
-      received, we need to check whether “measured_bw !=
-      expected_bw”.
    • 
-  
  • The bandwidth-upcall mechanism is enabled by
-      (MRT_API_CONFIG)
-      for the MRT_MFC_BW_UPCALL flag.
    • 
-  
  • The bandwidth-upcall filters are added/deleted by the new
-      setsockopt(MRT_ADD_BW_UPCALL)
-      and
-      setsockopt(MRT_DEL_BW_UPCALL)
-      respectively (with the appropriate struct bw_upcall
-      argument of course).
    • 
-

-
From application point of view, a developer needs to know about
-    the following:

-

-
/*
- * Structure for installing or delivering an upcall if the
- * measured bandwidth is above or below a threshold.
- *
- * User programs (e.g. daemons) may have a need to know when the
- * bandwidth used by some data flow is above or below some threshold.
- * This interface allows the userland to specify the threshold (in
- * bytes and/or packets) and the measurement interval. Flows are
- * all packet with the same source and destination IP address.
- * At the moment the code is only used for multicast destinations
- * but there is nothing that prevents its use for unicast.
- *
- * The measurement interval cannot be shorter than some Tmin (currently, 3s).
- * The threshold is set in packets and/or bytes per_interval.
- *
- * Measurement works as follows:
- *
- * For >= measurements:
- * The first packet marks the start of a measurement interval.
- * During an interval we count packets and bytes, and when we
- * pass the threshold we deliver an upcall and we are done.
- * The first packet after the end of the interval resets the
- * count and restarts the measurement.
- *
- * For <= measurement:
- * We start a timer to fire at the end of the interval, and
- * then for each incoming packet we count packets and bytes.
- * When the timer fires, we compare the value with the threshold,
- * schedule an upcall if we are below, and restart the measurement
- * (reschedule timer and zero counters).
- */
-
-struct bw_data {
-        struct timeval  b_time;
-        uint64_t        b_packets;
-        uint64_t        b_bytes;
-};
-
-struct bw_upcall {
-        struct in_addr  bu_src;         /* source address            */
-        struct in_addr  bu_dst;         /* destination address       */
-        uint32_t        bu_flags;       /* misc flags (see below)    */
-#define BW_UPCALL_UNIT_PACKETS (1 << 0) /* threshold (in packets)    */
-#define BW_UPCALL_UNIT_BYTES   (1 << 1) /* threshold (in bytes)      */
-#define BW_UPCALL_GEQ          (1 << 2) /* upcall if bw >= threshold */
-#define BW_UPCALL_LEQ          (1 << 3) /* upcall if bw <= threshold */
-#define BW_UPCALL_DELETE_ALL   (1 << 4) /* delete all upcalls for s,d*/
-        struct bw_data  bu_threshold;   /* the bw threshold          */
-        struct bw_data  bu_measured;    /* the measured bw           */
-};
-
-/* max. number of upcalls to deliver together */
-#define BW_UPCALLS_MAX				128
-/* min. threshold time interval for bandwidth measurement */
-#define BW_UPCALL_THRESHOLD_INTERVAL_MIN_SEC	3
-#define BW_UPCALL_THRESHOLD_INTERVAL_MIN_USEC	0

-

-
The bw_upcall structure is
-    used as an argument to
-    (MRT_ADD_BW_UPCALL)
-    and
-    setsockopt(MRT_DEL_BW_UPCALL).
-    Each
-    setsockopt(MRT_ADD_BW_UPCALL)
-    installs a filter in the kernel for the source and destination address in
-    the bw_upcall argument, and that filter will trigger
-    an upcall according to the following pseudo-algorithm:

-

-
 if (bw_upcall_oper IS ">=") {
-    if (((bw_upcall_unit & PACKETS == PACKETS) &&
-         (measured_packets >= threshold_packets)) ||
-        ((bw_upcall_unit & BYTES == BYTES) &&
-         (measured_bytes >= threshold_bytes)))
-       SEND_UPCALL("measured bandwidth is >= threshold");
-  }
-  if (bw_upcall_oper IS "<=" && measured_interval >= threshold_interval) {
-    if (((bw_upcall_unit & PACKETS == PACKETS) &&
-         (measured_packets <= threshold_packets)) ||
-        ((bw_upcall_unit & BYTES == BYTES) &&
-         (measured_bytes <= threshold_bytes)))
-       SEND_UPCALL("measured bandwidth is <= threshold");
-  }

-

-
In the same bw_upcall the unit can be
-    specified in both BYTES and PACKETS. However, the GEQ and LEQ flags are
-    mutually exclusive.

-
Basically, an upcall is delivered if the measured bandwidth is
-    >= or <= the threshold bandwidth (within the specified measurement
-    interval). For practical reasons, the smallest value for the measurement
-    interval is 3 seconds. If smaller values are allowed, then the bandwidth
-    estimation may be less accurate, or the potentially very high frequency of
-    the generated upcalls may introduce too much overhead. For the >=
-    operation, the answer may be known before the end of
-    threshold_interval, therefore the upcall may be
-    delivered earlier. For the <= operation however, we must wait until the
-    threshold interval has expired to know the answer.

-
Example of usage:

-

-
struct bw_upcall bw_upcall;
-/* Assign all bw_upcall fields as appropriate */
-memset(&bw_upcall, 0, sizeof(bw_upcall));
-memcpy(&bw_upcall.bu_src, &source, sizeof(bw_upcall.bu_src));
-memcpy(&bw_upcall.bu_dst, &group, sizeof(bw_upcall.bu_dst));
-bw_upcall.bu_threshold.b_data = threshold_interval;
-bw_upcall.bu_threshold.b_packets = threshold_packets;
-bw_upcall.bu_threshold.b_bytes = threshold_bytes;
-if (is_threshold_in_packets)
-    bw_upcall.bu_flags |= BW_UPCALL_UNIT_PACKETS;
-if (is_threshold_in_bytes)
-    bw_upcall.bu_flags |= BW_UPCALL_UNIT_BYTES;
-do {
-    if (is_geq_upcall) {
-        bw_upcall.bu_flags |= BW_UPCALL_GEQ;
-        break;
-    }
-    if (is_leq_upcall) {
-        bw_upcall.bu_flags |= BW_UPCALL_LEQ;
-        break;
-    }
-    return (ERROR);
-} while (0);
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_BW_UPCALL,
-          (void *)&bw_upcall, sizeof(bw_upcall));

-

-
To delete a single filter, then use
-    MRT_DEL_BW_UPCALL, and the fields of bw_upcall must
-    be set exactly same as when MRT_ADD_BW_UPCALL was
-    called.

-
To delete all bandwidth filters for a given (S,G), then only the
-    bu_src and bu_dst fields in
-    struct bw_upcall need to be set, and then just set
-    only the BW_UPCALL_DELETE_ALL flag inside field
-    bw_upcall.bu_flags.

-
The bandwidth upcalls are received by aggregating them in the new
-    upcall message:

-

-
#define IGMPMSG_BW_UPCALL  4  /* BW monitoring upcall */

-

-
This message is an array of struct
-    bw_upcall elements (up to BW_UPCALLS_MAX =
-    128). The upcalls are delivered when there are 128 pending upcalls, or when
-    1 second has expired since the previous upcall (whichever comes first). In
-    an struct upcall element, the
-    bu_measured field is filled-in to indicate the
-    particular measured values. However, because of the way the particular
-    intervals are measured, the user should be careful how
-    bu_measured.b_time is used. For example, if the filter
-    is installed to trigger an upcall if the number of packets is >= 1, then
-    bu_measured may have a value of zero in the upcalls
-    after the first one, because the measured interval for >= filters is
-    “clocked” by the forwarded packets. Hence, this upcall
-    mechanism should not be used for measuring the exact value of the bandwidth
-    of the forwarded data. To measure the exact bandwidth, the user would need
-    to get the forwarded packets statistics with the
-    (SIOCGETSGCNT)
-    mechanism (see the Programming
-    Guide section) .

-
Note that the upcalls for a filter are delivered until the
-    specific filter is deleted, but no more frequently than once per
-    bu_threshold.b_time. For example, if the filter is
-    specified to deliver a signal if bw >= 1 packet, the first packet will
-    trigger a signal, but the next upcall will be triggered no earlier than
-    bu_threshold.b_time after the previous upcall.

-

-

-

-

-
getsockopt(2), recvfrom(2),
-    recvmsg(2), setsockopt(2),
-    socket(2), icmp6(4),
-    inet(4), inet6(4),
-    intro(4), ip(4),
-    ip6(4), pim(4)

-

-

-

-
The original multicast code was written by David
-    Waitzman (BBN Labs), and later modified by the following individuals:
-    Steve Deering (Stanford), Mark J.
-    Steiglitz (Stanford), Van Jacobson (LBL),
-    Ajit Thyagarajan (PARC), Bill
-    Fenner (PARC). The IPv6 multicast support was implemented by the KAME
-    project
-    (https://www.kame.net), and
-    was based on the IPv4 multicast code. The advanced multicast API and the
-    multicast bandwidth monitoring were implemented by Pavlin
-    Radoslavov (ICSI) in collaboration with Chris
-    Brown (NextHop).

-
This manual page was written by Pavlin
-    Radoslavov (ICSI).

-

-

-
-  
-    
-    
-  
-
September 4, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/mvsata.4 4.html b/static/netbsd/man4/mvsata.4 4.html
deleted file mode 100644
index 5b4b6045..00000000
--- a/static/netbsd/man4/mvsata.4 4.html	
+++ /dev/null
@@ -1,113 +0,0 @@
-
-  
-    
-    
-    
-  
-
MVSATA(4)Device Drivers ManualMVSATA(4)

-

-

-

-
mvsata — Marvell
-    Hercules-I and Hercules-II SATA controllers driver

-

-

-

-
mvsata* at pci? dev ? function ?

-

-

-

-
The mvsata driver supports the Marvell
-    Hercules-I and Hercules-II family of SATA controllers, interfacing the
-    hardware with the ata(4) and atapi(4)
-    subsystems.

-
The following controllers are supported by the
-    mvsata driver:

-

-

-

-  
Gen I

-  

-    
    
-      
  • SATA 1.5Gbps; no support for NCQ, PMP, ATAPI
    • 
-      
  • Supported controllers:
-        
      
-          
    • Marvell 88SX50xx Hercules-I
      • 
-        
    
-      
    • 
-    

-  

-  
Gen II

-  

-    
    
-      
  • SATA 3Gbps, NCQ, and PMP support; no ATAPI support
    • 
-      
  • Supported controllers:
-        
      
-          
    • Adaptec RAID 1420SA
      • 
-          
    • Marvell 88SX60xx Hercules-II
      • 
-        
    
-      
    • 
-    

-  

-  
Gen IIe

-  

-    
    
-      
  • SATA 3Gbps, NCQ, PMP, ATAPI support
    • 
-      
  • Supported controllers:
-        
      
-          
    • Adaptec RAID 1430SA
      • 
-          
    • Marvell 88SX70xx Hercules-II
      • 
-          
    • Triones Technologies RocketRAID 2310 RAID card
      • 
-        
    
-      
    • 
-    

-  

-

-

-

-

-

-
ahcisata(4), ata(4),
-    atapi(4), pci(4),
-    wd(4)

-

-

-

-
The mvsata driver first appeared in
-    NetBSD 6.0. NCQ support was added, and ATAPI support
-    enabled, in NetBSD on October 7, 2017 .

-

-

-

-
The mvsata driver was written by
-    KIYOHARA Takashi
-    <kiyohara@kk.iij4u.or.jp>.
-    NCQ support was added by
-  

-  Jaromir Dolecek
-    <jdolecek@NetBSD.org>.

-

-

-

-

-  
NCQ is only enabled on Gen IIe controllers.

-  
 

-  
Device hot swapping is not yet supported.

-  
 

-  
Marvell's Software RAID is not supported by the

-  
ataraid(4) driver. raid(4) can be used
-      instead.

-

-
This controller hardware is very old and pretty peculiar, with
-    poor ATAPI support. It's very unlikely that the driver will receive any
-    further changes, particularly not for the Gen I and Gen II controllers. Use
-    an ahcisata(4) compatible controller instead.

-

-

-
-  
-    
-    
-  
-
October 24, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/nadb.4 4.html b/static/netbsd/man4/nadb.4 4.html
deleted file mode 100644
index 6c832e39..00000000
--- a/static/netbsd/man4/nadb.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
NADB(4)Device Drivers ManualNADB(4)

-

-

-

-
nadb — protocol
-    abstraction and device discovery for the Apple Desktop Bus

-

-

-

-
nadb* at cuda?
-  

-  nadb* at pmu?
-  

-  adbkbd* at nadb? console ? mux 1
-  

-  adbms* at nadb?
-  

-  adbbt* at nadb?

-

-

-

-
The nadb driver provides an abstract
-    interface for talking to ADB devices. It also scans the bus during startup,
-    resolves address conflicts and attaches drivers for known ADB hardware.

-

-

-

-
adbbt(4), adbkbd(4),
-    adbms(4), cuda(4),
-    pmu(4)

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/nca.4 4.html b/static/netbsd/man4/nca.4 4.html
deleted file mode 100644
index 4ea0e667..00000000
--- a/static/netbsd/man4/nca.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
NCA(4)Device Drivers ManualNCA(4)

-

-

-

-
nca —
-    NCR-5380/NCR-53C400 SCSI driver

-

-

-

-
nca0 at isa? port 0x360 irq 15 # Port-mapped NCR
-    53C80 controller
-  

-  nca1 at isa? iomem 0xd8000 irq 5 # Memory-mapped controller
-    (T128...)
-  

-  nca* at pci? dev ? function ? # Domex 536 (DMX-3191D)
-  

-  scsibus* at nca?

-

-

-

-
The nca driver provides support for the
-    NCR-5380/NCR-53C400 SCSI controllers.

-

-

-

-
isa(4), pci(4),
-    scsi(4)

-

-

-

-
The nca driver appeared in
-    NetBSD 1.4. Domex 536 support appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
April 1, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/ncm.4 4.html b/static/netbsd/man4/ncm.4 4.html
deleted file mode 100644
index bf4aa509..00000000
--- a/static/netbsd/man4/ncm.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
NCM(4)Device Drivers ManualNCM(4)

-

-

-

-
ncm — USB Network
-    Control Model driver

-

-

-

-
ncm* at uhub? port ?

-

-

-

-
The ncm driver provides support for USB
-    Network Control Model devices, often appearing as hotspot USB tethering in
-    Android devices on devices such as the following:

-

-
    
-  
  • Google Pixel 8
    • 
-

-

-

-

-
arp(4), intro(4),
-    netintro(4), usb(4),
-    usbnet(4), ifconfig.if(5),
-    ifconfig(8)

-
Universal Serial Bus Class
-    Communications Class Subclass Specification for Network Control Model
-    Devices,
-    https://www.usb.org/sites/default/files/NCM10_012011.zip.

-

-

-

-
The ncm device driver first appeared in
-    NetBSD 11.0.

-

-

-

-
The ncm driver was written by
-    Maya Rashish
-    <maya@netbsd.org>
-    based on the cdce(4) driver written by
-    Craig Boston
-    <craig@tobuj.gank.org>.

-

-

-
-  
-    
-    
-  
-
January 20, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/nct.4 4.html b/static/netbsd/man4/nct.4 4.html
deleted file mode 100644
index 398a1078..00000000
--- a/static/netbsd/man4/nct.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
NCT(4)Device Drivers ManualNCT(4)

-

-

-

-
nct — Nuvoton
-    NCT5104D SuperIO driver

-

-

-

-
nct0 at isa? port ?
-  

-  nct0 at isa? port 0x2e
-  

-  nct0 at isa? port 0x4e
-  

-  gpio* at nct?

-

-

-

-
The nct driver supports the GPIO functions
-    of the NCT5104D. The driver does not support the watchdog function of the
-    chip. The chip's UARTs are driven by the com(4)
-  driver.

-
The probe routine for this device is invasive. The chip will be
-    probed for only if the device is configured into the kernel with a fixed
-    port number (0x2e or 0x4e), or if running on a system that is known to have
-    a NCT5104D, such as the PC Engines APU line of systems.

-
GPIO pins on this chip are shared with the 3rd UART, 4th UART, a
-    clock input line, and the watchdog timer. If any these functions have been
-    enabled by the BIOS, the nct driver will not take
-    control of the corresponding GPIO lines. At attach time, the driver logs
-    which of the 17 GPIO lines are enabled.

-

-

-

-
gpio(4), isa(4),
-    gpioctl(8)

-

-

-

-
The nct driver first appeared in
-    NetBSD 10.

-

-

-

-
If the chip has not been configured in a complete and accurate
-    manner by the BIOS, GPIO lines may be needlessly disabled.

-

-

-
-  
-    
-    
-  
-
December 21, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/ne.4 4.html b/static/netbsd/man4/ne.4 4.html
deleted file mode 100644
index e29f8502..00000000
--- a/static/netbsd/man4/ne.4 4.html	
+++ /dev/null
@@ -1,133 +0,0 @@
-
-  
-    
-    
-    
-  
-
NE(4)Device Drivers ManualNE(4)

-

-

-

-
ne — NE2000 and
-    compatible Ethernet cards device driver

-

-

-

-

-

-
ne0 at isa? port 0x280 irq 9
-  

-  ne1 at isa? port 0x300 irq 10
-  

-  ne* at isapnp?

-

-

-

-
ne* at mca? slot ?

-

-

-

-
ne* at pci? dev ? function ?

-

-

-

-
ne* at pcmcia? function ?

-

-

-

-
ne* at podulebus?

-

-

-

-
ne* at zbus0 # AriadneII
-  

-  ne* at xsurfbus? # X-Surf
-  

-  ne* at xshbus? # X-Surf 100

-

-

-

-
ne* at zbus0 # AriadneII
-  

-  ne* at xsurfbus? # X-Surf
-  

-  ne* at xshbus? # X-Surf 100

-

-

-

-
ne0 at mainbus0 # EtherNEC on Atari ROM cartridge
-    slot

-

-

-

-
ne0 at obio? addr 0x0e000200 intr 5 # on-board
-    Asix AX88796

-

-

-

-
ne0 at mainbus? # Realtek RTL8019AS

-

-

-

-
ne* at intio0 addr 0xece300 intr 249 # Nereid
-    Ethernet
-  

-  ne* at intio0 addr 0xeceb00 intr 248 # Nereid Ethernet
-  

-  neptune0 at intio0 addr 0xece000 intr 249 # Neptune-X
-  

-  neptune1 at intio0 addr 0xece400 intr 249 # Neptune-X at alt.
-    addr.
-  

-  ne* at neptune? addr 0x300

-

-

-

-

-
The ne device driver supports NE2000 and
-    compatible (including NE1000) Ethernet cards. While the original NE2000 is
-    designed for ISA bus, the compatible Realtek 8019 chip is widely used on
-    various local busses and ne driver also supports
-    such devices on various machines.

-

-

-

-
The Realtek 8019 (ISA, ISAPnP, some PCMCIA) and Realtek 8029 (PCI)
-    NE2000-compatible Ethernet chips include support for software media
-    selection.

-
Some cards based on AX88x9x chips (like X-Surf 100) also support
-    media selection and link auto negotiation through the
-    mii(4) interface.

-
If one of the above chips is detected by the driver, the list of
-    supported media will be displayed.

-
For all other chips supported by the ne
-    driver, media selection must be performed either via card jumper settings or
-    by vendor-supplied configuration programs.

-

-

-

-

-  
ne0: where did the card go?

-  
The driver found the card, but was unable to make the card respond to
-      complete the configuration sequence.

-

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), isapnp(4),
-    mca(4), pci(4),
-    pcmcia(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
August 14, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/neo.4 4.html b/static/netbsd/man4/neo.4 4.html
deleted file mode 100644
index 85e1f2e2..00000000
--- a/static/netbsd/man4/neo.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
NEO(4)Device Drivers ManualNEO(4)

-

-

-

-
neo — NeoMagic
-    MagicMedia 256 audio device driver

-

-

-

-
neo* at pci? dev ? function ?
-  

-  audio* at audiobus?

-

-

-

-
The neo driver provides support for the
-    NeoMagic MagicMedia 256AV and 256ZX AC'97 audio devices, found on many
-    laptops.

-
The MagicMedia 256AV also comes in a variant (usually found on
-    Dell and HP laptops) that works in Windows Sound System emulation mode, not
-    in AC'97 mode. That variant of the chip must be used with the
-    wss(4) driver. The neo driver will
-    not attach to such chips.

-

-

-

-
ac97(4), audio(4),
-    intro(4), midi(4),
-    pci(4), wss(4)

-

-

-

-
The neo device driver appeared in
-    NetBSD 1.5.1.

-

-

-

-
The MagicMedia 256 series is not well-documented.

-
No MIDI or FM synthesizer capability is provided with the
-    MagicMedia 256 in AC'97 mode. While those capabilities are provided by the
-    Windows driver for the chip, they are emulated by the Windows driver, and
-    not directly supported by the hardware.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/netintro.4 3.html b/static/netbsd/man4/netintro.4 3.html
deleted file mode 100644
index 29a96470..00000000
--- a/static/netbsd/man4/netintro.4 3.html	
+++ /dev/null
@@ -1,279 +0,0 @@
-
-  
-    
-    
-    
-  
-
NETINTRO(4)Device Drivers ManualNETINTRO(4)

-

-

-

-
netintro —
-    introduction to networking facilities

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <net/route.h>
-  

-  #include <net/if.h>

-

-

-

-
This section is a general introduction to the networking
-    facilities available in the system. Documentation in this part of section 4
-    is broken up into three areas: protocol families
-    (domains),
-    ,
-    and .

-
All network protocols are associated with a specific
-    protocol family. A protocol family provides basic services
-    to the protocol implementation to allow it to function within a specific
-    network environment. These services may include packet fragmentation and
-    reassembly, routing, addressing, and basic transport. A protocol family may
-    support multiple methods of addressing, though the current protocol
-    implementations do not. A protocol family normally comprises a number of
-    protocols, one per socket(2) type. It is not required that
-    a protocol family support all socket types. A protocol family may contain
-    multiple protocols supporting the same socket abstraction.

-
A protocol supports one of the socket abstractions detailed in
-    socket(2). A specific protocol may be accessed either by
-    creating a socket of the appropriate type and protocol family, or by
-    requesting the protocol explicitly when creating a socket. Protocols
-    normally accept only one type of address format, usually determined by the
-    addressing structure inherent in the design of the protocol family/network
-    architecture. Certain semantics of the basic socket abstractions are
-    protocol specific. All protocols are expected to support the basic model for
-    their particular socket type, but may, in addition, provide non-standard
-    facilities or extensions to a mechanism. For example, a protocol supporting
-    the SOCK_STREAM abstraction may allow more than one
-    byte of out-of-band data to be transmitted per out-of-band message.

-
A network interface is similar to a device interface. Network
-    interfaces comprise the lowest layer of the networking subsystem,
-    interacting with the actual transport hardware. An interface may support one
-    or more protocol families and/or address formats. The
-    SYNOPSIS section of each network interface entry gives a
-    sample specification of the related drivers for use in providing a system
-    description to the config(1) program.

-
The
-    
-    section lists messages which may appear on the console and/or in the system
-    error log, /var/log/messages (see
-    syslogd(8)), due to errors in device operation.

-

-

-

-
The system currently supports the Internet protocols. Raw socket
-    interfaces are provided to the IP protocol layer of the Internet. Consult
-    the appropriate manual pages in this section for more information regarding
-    the support for a protocol.

-

-

-

-
Associated with each protocol family is an address format. All
-    network address adhere to a general structure, called a sockaddr, described
-    below. However, each protocol imposes finer and more specific structure,
-    generally renaming the variant, which is discussed in the protocol family
-    manual page alluded to above.

-

-
struct sockaddr {
-	u_char	sa_len;
-    	u_char	sa_family;
-    	char	sa_data[14];
-};

-

-
The field sa_len contains the total length
-    of the of the structure, which may exceed 16 bytes. The following address
-    values for sa_family are known to the system (and
-    additional formats are defined for possible future implementation):

-

-
#define    AF_LOCAL     1    /* local to host */
-#define    AF_INET      2    /* internetwork: UDP, TCP, etc. */
-#define    AF_NS        6    /* Xerox NS protocols */
-#define    AF_CCITT     10   /* CCITT protocols, X.25 etc */
-#define    AF_HYLINK    15   /* NSC Hyperchannel */
-#define    AF_INET6     24   /* internetwork, v6: UDP, TCP, etc. */

-

-

-

-

-
UNIX provides some packet routing
-    facilities. The kernel maintains a routing information database, which is
-    used in selecting the appropriate network interface when transmitting
-    packets.

-
A user process (or possibly multiple co-operating processes)
-    maintains this database by sending messages over a special kind of socket.
-    This supplants fixed size ioctl(2) used in earlier
-    releases.

-
This facility is described in route(4).

-

-

-

-
Each network interface in a system corresponds to a path through
-    which messages may be sent and received. A network interface usually has a
-    hardware device associated with it, though certain interfaces such as the
-    loopback interface, lo(4), do not.

-
The following ioctl(2) calls may be used to
-    manipulate network interfaces. The ioctl(2) is made on a
-    socket (typically of type SOCK_DGRAM) in the desired
-    domain. Most of the requests supported in earlier releases take an
-    ifreq structure as its parameter. This structure has
-    the form

-

-
struct	ifreq {
-#define    IFNAMSIZ    16
-    char    ifr_name[IFNAMSIZ];         /* if name, e.g. "en0" */
-    union {
-        struct    sockaddr ifru_addr;
-        struct    sockaddr ifru_dstaddr;
-        struct    sockaddr ifru_broadaddr;
-        short     ifru_flags;
-        int       ifru_metric;
-        void   *ifru_data;
-    } ifr_ifru;
-#define ifr_addr      ifr_ifru.ifru_addr    /* address */
-#define ifr_dstaddr   ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
-#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
-#define ifr_space     ifr_ifru.ifru_space     /* sockaddr_storage */
-#define ifr_flags     ifr_ifru.ifru_flags   /* flags */
-#define ifr_metric    ifr_ifru.ifru_metric  /* metric */
-#define ifr_mtu       ifr_ifru.ifru_mtu       /* mtu */
-#define ifr_dlt       ifr_ifru.ifru_dlt       /* data link type (DLT_*) */
-#define ifr_value     ifr_ifru.ifru_value     /* generic value */
-#define ifr_media     ifr_ifru.ifru_metric    /* media options (overload) */
-#define ifr_data      ifr_ifru.ifru_data    /* for use by interface */
-#define ifr_buf       ifr_ifru.ifru_b.b_buf   /* new interface ioctls */
-#define ifr_buflen    ifr_ifru.ifru_b.b_buflen
-#define ifr_index     ifr_ifru.ifru_value     /* interface index */
-};

-

-
Calls which are now deprecated are:

-

-  

-  
Set interface address for protocol family. Following the address
-      assignment, the ``initialization'' routine for the interface is
-    called.

-  

-  
Set point to point address for protocol family and interface.

-  

-  
Set broadcast address for protocol family and interface.

-

-
ioctl(2) requests to obtain addresses and
-    requests both to set and retrieve other data are still fully supported and
-    use the ifreq structure:

-

-  

-  
Get interface address for protocol family.

-  

-  
Get point to point address for protocol family and interface.

-  

-  
Get broadcast address for protocol family and interface.

-  

-  
Set interface flags field. If the interface is marked down, any processes
-      currently routing packets through the interface are notified; some
-      interfaces may be reset so that incoming packets are no longer received.
-      When marked up again, the interface is reinitialized.

-  

-  
Get interface flags.

-  

-  
Set interface routing metric. The metric is used only by user-level
-      routers.

-  

-  
Get interface metric.

-  

-  
Get the interface index and populate ifr_index.

-

-
There are two requests that make use of a new structure:

-

-  

-  
An interface may have more than one address associated with it in some
-      protocols. This request provides a means to add additional addresses (or
-      modify characteristics of the primary address if the default address for
-      the address family is specified). Rather than making separate calls to set
-      destination or broadcast addresses, or network masks (now an integral
-      feature of multiple protocols) a separate structure,
-      ifaliasreq, is used to specify all three facets
-      simultaneously (see below). One would use a slightly tailored version of
-      this struct specific to each family (replacing each sockaddr by one of the
-      family-specific type). Where the sockaddr itself is larger than the
-      default size, one needs to modify the ioctl(2)
-      identifier itself to include the total size, as described in
-      ioctl(2).

-  

-  
This requests deletes the specified address from the list associated with
-      an interface. It also uses the ifaliasreq structure
-      to allow for the possibility of protocols allowing multiple masks or
-      destination addresses, and also adopts the convention that specification
-      of the default address means to delete the first address for the interface
-      belonging to the address family in which the original socket was
-    opened.

-  

-  
This request provides means to get additional addresses together with
-      netmask and broadcast/destination from an interface. It also uses the
-      ifaliasreq structure.

-

-
Request making use of the ifconf
-  structure:

-

-  

-  
Get interface configuration list. This request takes an
-      ifconf structure (see below) as a value-result
-      parameter. The ifc_len field should be initially set
-      to the size of the buffer pointed to by ifc_buf. On
-      return it will contain the length, in bytes, of the configuration
-    list.

-

-

-
/*
-* Structure used in SIOC[AD]IFADDR request.
-*/
-struct ifaliasreq {
-        char    ifra_name[IFNAMSIZ];   /* if name, e.g. "en0" */
-        struct  sockaddr        ifra_addr;
-        struct  sockaddr        ifra_dstaddr;
-#define	ifra_broadaddr  ifra_dstaddr
-        struct  sockaddr        ifra_mask;
-};

-

-

-
/*
-* Structure used in SIOCGIFCONF request.
-* Used to retrieve interface configuration
-* for machine (useful for programs which
-* must know all networks accessible).
-*/
-struct ifconf {
-    int   ifc_len;		/* size of associated buffer */
-    union {
-        void    *ifcu_buf;
-        struct     ifreq *ifcu_req;
-    } ifc_ifcu;
-#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
-#define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
-};

-

-

-

-

-
config(1), ioctl(2),
-    socket(2), intro(4),
-    routed(8)

-

-

-

-
The netintro manual appeared in
-    4.3BSD-Tahoe.

-

-

-
-  
-    
-    
-  
-
August 2, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/nfe.4 4.html b/static/netbsd/man4/nfe.4 4.html
deleted file mode 100644
index be5a5b37..00000000
--- a/static/netbsd/man4/nfe.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
NFE(4)Device Drivers ManualNFE(4)

-

-

-

-
nfe — NVIDIA
-    nForce MCP Ethernet driver

-

-

-

-
nfe* at pci?
-  

-  ciphy* at mii?
-  

-  icsphy* at mii?
-  

-  makphy* at mii?
-  

-  rlphy* at mii?

-

-

-

-
The nfe driver supports PCI Ethernet
-    adapters based on the NVIDIA nForce Media and Communications Processors
-    (MCP), such as the nForce, nForce 2, nForce 3, CK804, MCP04, MCP51, MCP55,
-    MCP61, MCP65, MCP67 and MCP73 Ethernet controller chips.

-
The nfe driver supports the following
-    media types:

-

-

-  

-  
Enable autoselection of the media type and options.

-  

-  
Set 10Mbps operation.

-  

-  
Set 100Mbps (Fast Ethernet) operation.

-  

-  
Set 1000Mbps (Gigabit Ethernet) operation (recent models only).

-

-

-

-

-
arp(4), ciphy(4),
-    icsphy(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), rlphy(4),
-    ifconfig.if(5), ifconfig(8)

-

-

-

-
The nfe device driver first appeared in
-    OpenBSD 3.9. It was added to NetBSD
-    3.1.

-

-

-

-
The nfe driver was written by
-    Jonathan Gray ⟨jsg@openbsd.org⟩ and
-    Damien Bergamini
-  ⟨damien@openbsd.org⟩.

-

-

-

-
NVIDIA refuse to release any documentation on their products.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/nfsmb.4 4.html b/static/netbsd/man4/nfsmb.4 4.html
deleted file mode 100644
index ef8b37eb..00000000
--- a/static/netbsd/man4/nfsmb.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
NFSMB(4)Device Drivers ManualNFSMB(4)

-

-

-

-
nfsmb, nfsmbc
-    — NVIDIA nForce 2/3/4 SMBus controller and SMBus
-    driver

-

-

-

-
nfsmbc* at pci? dev ? function ?
-  

-  nfsmb* at nfsmbc?
-  

-  iic* at nfsmb?

-

-

-

-
The nfsmbc provides support for the NVIDIA
-    nForce 2/3/4 SMBus controller. The nfsmbc has two
-    SMBus (nfsmb).

-

-

-

-
iic(4), pci(4)

-

-

-

-
The nfsmb driver appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
January 8, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/njata.4 4.html b/static/netbsd/man4/njata.4 4.html
deleted file mode 100644
index d4267566..00000000
--- a/static/netbsd/man4/njata.4 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
NJATA(4)Device Drivers ManualNJATA(4)

-

-

-

-
njata — Workbit
-    NinjaATA-32 CardBus IDE controller driver

-

-

-

-
njata* at cardbus? function ?
-  

-  njata* at cardbus? function ? flags 0x01	# with wait
-    0x01

-

-

-

-
The njata driver provides support for the
-    following Workbit Bus-Master CardBus IDE controller chips:

-

-

-  
NinjaATA-32Bi

-  
CardBus / PCMCIA dual mode IDE controller (“DuoATA”). This
-      controller is mainly used for portable drives. This driver supports the
-      CardBus mode.

-  
NPATA-32

-  
CardBus IDE controller. This controller is widely used for CardBus
-      CompactFlash adapters.

-

-

-
These controllers are capable of bus-mastering for ATA PIO
-    transfer. The njata driver uses the bus-mastering
-    PIO transfer unless transfer buffer is unaligned, and significantly reduces
-    CPU usage for PIO-only ATA devices compared with usual PIO transfer.

-

-

-

-
The optional flags parameter is the “wait” value for
-    ATA transfers. Some combinations of host and device may fail without flags
-    parameter or flags 0x00. In this case try adding
-    wait values like flags 0x01 or
-    flags 0x11 (the wait parameter is composed of two
-    4-bit values). Smaller wait values should be faster. Too long waits may
-    cause transfer errors.

-

-

-

-
ata(4), atapi(4),
-    cardbus(4), intro(4),
-    wd(4), wdc(4)

-

-

-

-
The njata device driver first appeared in
-    NetBSD 4.0.

-

-

-

-
ITOH Yasufumi

-

-

-
-  
-    
-    
-  
-
September 7, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/njs.4 4.html b/static/netbsd/man4/njs.4 4.html
deleted file mode 100644
index 530ec93d..00000000
--- a/static/netbsd/man4/njs.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
NJS(4)Device Drivers ManualNJS(4)

-

-

-

-
njs — Workbit
-    NinjaSCSI-32 PCI/CardBus SCSI driver

-

-

-

-
njs* at pci? dev ? function ?
-  

-  njs* at cardbus? function ?

-

-

-

-
The njs driver provides support for the
-    following Workbit Bus-Master PCI/CardBus Ultra Narrow SCSI controller
-  chips:

-

-

-  
NinjaSCSI-32Bi

-  
CardBus / PCMCIA dual mode device (“DuoSCSI”). This driver
-      supports the CardBus mode.

-  
NinjaSCSI-32UDE

-  
PCI / CardBus device with DualEdge transfer (40MB/s max.) capability.

-

-

-

-

-

-
cardbus(4), cd(4),
-    ch(4), pci(4),
-    scsi(4), sd(4), st(4),
-    uk(4)

-

-

-

-
The njs device driver first appeared in
-    NetBSD 1.6.3.

-

-

-

-
ITOH Yasufumi

-

-

-

-
DualEdge transfer is not currently supported.

-

-

-
-  
-    
-    
-  
-
August 26, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/npflog.4 4.html b/static/netbsd/man4/npflog.4 4.html
deleted file mode 100644
index 5b161751..00000000
--- a/static/netbsd/man4/npflog.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
NPFLOG(4)Device Drivers ManualNPFLOG(4)

-

-

-

-
npflog — packet
-    filter logging interface

-

-

-

-
pseudo-device npflog

-

-

-

-
The npflog interface is a pseudo-device
-    which makes visible all packets logged by the npf(7)
-    packet filter. Logged packets can be monitored in real time by invoking
-    tcpdump(8) on the npflog
-    interface, or stored to disk using npfd(8).

-
The npflog0 interface is created automatically at boot if
-    npf(7) is enabled; further instances can be created using
-    ifconfig(8).

-
Each packet retrieved on this interface has a header associated
-    that presently matches the format used by pf(4). This
-    header documents the address family, interface name, rule number, reason,
-    action, and direction of the packet that was logged. This structure looks
-    like:

-

-
struct npfloghdr {
-	uint8_t		length;
-	sa_family_t	af;
-	uint8_t		action;
-	uint8_t		reason;
-	char		ifname[IFNAMSIZ];
-	char		ruleset[NPFLOG_RULESET_NAME_SIZE];
-	uint32_t	rulenr;
-	uint32_t	subrulenr;
-	uint32_t	uid;
-	uint32_t	pid;
-	uint32_t	rule_uid;
-	uint32_t	rule_pid;
-	uint8_t		dir;
-	uint8_t		pad[3];
-};

-

-

-

-

-
Monitor all packets logged on the default interface:

-

-
# tcpdump -n -e -tttt -i npflog0

-

-

-

-

-
inet(4), inet6(4),
-    netintro(4), npf(7),
-    ifconfig(8), npfd(8),
-    tcpdump(8)

-

-

-

-
The npflog device first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
June 29, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/nsclpcsio.4 4.html b/static/netbsd/man4/nsclpcsio.4 4.html
deleted file mode 100644
index ae4786e0..00000000
--- a/static/netbsd/man4/nsclpcsio.4 4.html	
+++ /dev/null
@@ -1,149 +0,0 @@
-
-  
-    
-    
-    
-  
-
NSCLPCSIO(4)Device Drivers ManualNSCLPCSIO(4)

-

-

-

-
nsclpcsio —
-    National Semiconductor PC87366 LPC Super I/O

-

-

-

-
nsclpcsio* at isa?
-  

-  gpio* at nsclpcsio?

-

-

-

-
The nsclpcsio driver provides support for
-    the National Semiconductor PC87366 LPC Super I/O. The Super I/O incorporates
-    several logical devices, the following ones are supported: GPIO, VLM and
-    TMS.

-
The GPIO logical device provides 29 I/O pins which can be accessed
-    through the gpio(4) framework. The
-    gpioctl(8) program allows easy manipulation of the pins
-    from userland.

-
VLM and TMS logical devices provides hardware monitoring
-    capabilities to be used with the envsys(4) API. The
-    following 17 monitoring sensors are available:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uKRemote diode
uKRemote diode
uKLocal diode
uV DCExternal source
uV DCExternal source
uV DCExternal source
uV DCExternal source
uV DCExternal source
uV DCExternal source
uV DCExternal source
uV DCVSB
uV DCVDD
uV DCVBAT
uV DCAVDD
uV DCThermistor
uV DCThermistor
uV DCThermistor

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The nsclpcsio device appeared in
-    NetBSD 2.0.

-

-

-

-
The chip decodes address ranges which are not obvious and cannot
-    be controlled by the kernel configuration file (must be set up by the
-  BIOS).

-

-

-
-  
-    
-    
-  
-
November 9, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/nside.4 4.html b/static/netbsd/man4/nside.4 4.html
deleted file mode 100644
index 400c0ed1..00000000
--- a/static/netbsd/man4/nside.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
NSIDE(4)Device Drivers ManualNSIDE(4)

-

-

-

-
nside — PCI IDE
-    disk controllers driver

-

-

-

-
nside* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The nside driver supports the National
-    Semiconductor PC87415 PCI-IDE DMA master mode interface controller, and
-    provides the interface with the hardware for the ata(4)
-    driver.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-
-  
-    
-    
-  
-
November 15, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/nsphy.4 4.html b/static/netbsd/man4/nsphy.4 4.html
deleted file mode 100644
index 1efad288..00000000
--- a/static/netbsd/man4/nsphy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
NSPHY(4)Device Drivers ManualNSPHY(4)

-

-

-

-
nsphy — Driver for
-    National Semiconductor DP83840 10/100 Ethernet PHYs

-

-

-

-
nsphy* at mii? phy ?

-

-

-

-
The nsphy driver supports the National
-    Semiconductor DP83840 and DP83840A 10/100 Ethernet PHYs. These PHYs are
-    found on a variety of high-performance Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 3, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/nsphyter.4 4.html b/static/netbsd/man4/nsphyter.4 4.html
deleted file mode 100644
index 7e97acb7..00000000
--- a/static/netbsd/man4/nsphyter.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
NSPHYTER(4)Device Drivers ManualNSPHYTER(4)

-

-

-

-
nsphyter — Driver
-    for National Semiconductor DP83843 10/100 Ethernet PHYs

-

-

-

-
nsphyter* at mii? phy ?

-

-

-

-
The nsphyter driver supports the National
-    Semiconductor DP83843 (PHYTER) 10/100 Ethernet PHY, which is found in a
-    variety of high-performance Ethernet interfaces, and DP83815 (MacPHYTER)
-    internal PHY. The DP83815 is a 10/100 Ethernet chip supported by the
-    sip(4) driver.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
May 31, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ntwoc.4 3.html b/static/netbsd/man4/ntwoc.4 3.html
deleted file mode 100644
index 5a8956a4..00000000
--- a/static/netbsd/man4/ntwoc.4 3.html	
+++ /dev/null
@@ -1,148 +0,0 @@
-
-  
-    
-    
-    
-  
-
NTWOC(4)Device Drivers ManualNTWOC(4)

-

-

-

-
ntwoc — Riscom/N2,
-    N2pci, WANic 400 synchronous serial interfaces

-

-

-

-
ntwoc* at pci? dev ? function ? flags 0
-  

-  ntwoc0 at isa? port 0x300 irq 5 iomem 0xc8000 flags
-  1

-

-

-

-
The ntwoc device driver supports
-    bit-synchronous serial communication using Cisco HDLC framing. The cards are
-    capable of being driven by the line clock or from an internal baud rate
-    generator. The devices all use the Hitachi hd64570 serial chip. The hd64570
-    supports 2 asynchronous/byte-synchronous/bit-synchronous serial ports, and
-    has a 4-channel DMA controller for loading the serial port FIFOs.

-
The ISA Riscom/N2 card has a jumper block to set the IRQ and a DIP
-    switch to set the port address the card will use. The values programmed into
-    the card must be specified with the port and
-    irq locators in the kernel configuration line. The
-    iomem locator must be specified and must occur on a
-    16k boundary. The driver uses a 16k region of io memory. Bit 0 of the
-    flags locator indicates if there is a second serial
-    port available on the card.

-
Currently clock source and speed information is specified with the
-    flags locator in the kernel configuration file. The
-    flags field has the following format.

-

-
  3                   2                   1
-1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
-+-------------+ +-----+ +-----+ + +---+ +-+     + +---+ +-+   +
-      tmc         tdiv    rdiv  e1 rxs1 ts1    e0 rxs0  txs0  np(*)

-

-

-  
tmc

-  
Defines the timer constant. The base clock frequency is divided by
-      tmc to generate the main clock for receiving and
-      sending. Further division is possible with the tdiv
-      and rdiv divisor options. A value of 0 is treated as
-      256.

-  
tdiv

-  
Defines the transmit divisor as 2^(tdiv). The
-      internal transmit clock frequency is determined by dividing the base clock
-      frequency by tmc and then dividing by
-      2^(tdiv).

-  
rdiv

-  
Defines the receive divisor as 2^(rdiv). The
-      internal receive clock frequency is determined by dividing the base clock
-      frequency by tmc and then dividing by
-      2^(rdiv).

-  
e0 e1

-  
If true the internal clock source is used to drive the line clock for port
-      0 or port 1 respectively.

-  
rxs0 rxs1

-  
Specifies which clock source to use for receiving data on port 0 and port
-      1 respectively. The following values are accepted:
-    

-    

-      
0

-      
Line clock.

-      
1

-      
Line clock with noise suppression.

-      
2

-      
Internal clock.

-    

-  

-  
txs0 txs1

-  
Specifies which clock source to use for transmitting data on port 0 and
-      port 1 respectively. The following values are accepted:
-    

-    

-      
0

-      
Line clock.

-      
1

-      
Internal clock.

-      
2

-      
Receive clock.

-    

-  

-  
np

-  
(For the ISA card only) A value of 1 indicates there is a second serial
-      port present on the card. This is auto-detected on the PCI card and need
-      not be specified.

-

-

-

-

-
Cards supported by the ntwoc driver
-    include:

-

-
    
-  
  • SDL Communications Riscom/N2
    • 
-  
  • SDL Communications N2pci
    • 
-  
  • SDL Communications WANic 400 (untested)
    • 
-

-

-

-

-

-  
ntwoc0: TXDMA underrun - fifo depth maxed

-  
Indicates that the serial port's FIFO is being drained faster than DMA can
-      fill it. The driver automatically increases the low-water mark at which to
-      begin DMA transfers when underruns occur. This diagnostic is issued when
-      the low-water mark is maximized (i.e., 1 less than the depth of the
-    FIFO).

-  
ntwoc0: RXDMA buffer overflow

-  
Indicates that a frame is being received by the card, but there are no
-      free receive buffers.

-

-

-

-

-
intro(4), isa(4),
-    pci(4), ifconfig(8)

-

-

-

-
The PCI driver first appeared in NetBSD
-    1.4. Much of the ISA driver was adapted from the
-    FreeBSD sr driver and first
-    appeared in NetBSD 1.5.

-

-

-

-
Use of the flags locator for setting the
-    clock sources and speeds should be replaced with ioctl's and a control
-    program.

-

-

-
-  
-    
-    
-  
-
October 2, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/null.4 4.html b/static/netbsd/man4/null.4 4.html
deleted file mode 100644
index 622d60b3..00000000
--- a/static/netbsd/man4/null.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
NULL(4)Device Drivers ManualNULL(4)

-

-

-

-
null — the null
-    device

-

-

-

-
The null device accepts and reads data as
-    any ordinary (and willing) file — but throws it away. The length of
-    the null device is always zero.

-

-

-

-

-  
/dev/null

-  
 

-

-

-

-

-
A null device appeared in
-    Version 4 AT&T UNIX.

-

-

-
-  
-    
-    
-  
-
August 29, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/nvme.4 3.html b/static/netbsd/man4/nvme.4 3.html
deleted file mode 100644
index 879c70a2..00000000
--- a/static/netbsd/man4/nvme.4 3.html	
+++ /dev/null
@@ -1,117 +0,0 @@
-
-  
-    
-    
-    
-  
-
NVME(4)Device Drivers ManualNVME(4)

-

-

-

-
nvme —
-    Non-Volatile Memory Host Controller Interface

-

-

-

-
nvme* at pci? dev ? function ?

-

-

-

-
The nvme driver provides support for NVMe,
-    or NVM Express, storage controllers conforming to the Non-Volatile Memory
-    Host Controller Interface specification. Controllers complying to
-    specification version 1.1 and 1.2 are known to work. Other versions should
-    work too for normal operation with the exception of some pass-through
-    commands.

-
The driver supports the following features:

-
    
-  
  • controller and namespace configuration and management using
-      nvmectl(8)
    • 
-  
  • highly parallel I/O using per-CPU I/O queues
    • 
-  
  • PCI MSI/MSI-X attachment, and INTx for legacy systems
    • 
-

-
On systems supporting MSI/MSI-X, the nvme
-    driver uses per-CPU IO queue pairs for lockless and highly parallelized I/O.
-    Interrupt handlers are scheduled on distinct CPUs. The driver allocates as
-    many interrupt vectors as available, up to number of CPUs + 1. MSI supports
-    up to 32 interrupt vectors within the system, MSI-X can have up to 2k. Each
-    I/O queue pair has a separate command circular buffer. The
-    nvme specification allows up to 64k commands per
-    queue, the driver currently allocates 1024 entries per queue, or controller
-    maximum, whatever is smaller. Command submissions are done always on the
-    current CPU, the command completion interrupt is handled on the CPU
-    corresponding to the I/O queue ID - first I/O queue on CPU0, second I/O
-    queue on CPU1, etc. Admin queue command completion is handled by CPU0 by
-    default. To keep lock contention to minimum, it is recommended to keep this
-    assignment, even though it is possible to reassign the interrupt handlers
-    differently using intrctl(8).

-
On systems without MSI, the driver uses a single HW interrupt
-    handler for both admin and standard I/O commands. Command submissions are
-    done on the current CPU, the command completion interrupt is handled on CPU0
-    by default. This leads to some lock contention, especially on command
-  ccbs.

-
The driver offloads command completion processing to soft
-    interrupt, in order to increase the total system I/O capacity and
-    throughput.

-

-

-

-

-  
/dev/nvme*

-  
nvme device special files used by nvmectl(8).

-

-

-

-

-
intro(4), ld(4),
-    pci(4), intrctl(8),
-    MAKEDEV(8), nvmectl(8)

-
NVM Express, Inc.,
-    NVM Express - scalable, efficient, and industry
-    standard,
-    https://nvmexpress.org/,
-    2016-06-12.

-
NVM Express, Inc.,
-    NVM Express Revision 1.2.1,
-    http://www.nvmexpress.org/wp-content/uploads/NVM_Express_1_2_1_Gold_20160603.pdf,
-    2016-06-05.

-

-

-

-
The nvme driver first appeared in
-    OpenBSD 6.0 and in NetBSD
-    8.0.

-

-

-

-
The nvme driver was written by
-    David Gwynne
-    <dlg@openbsd.org> for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro
-    <nonaka@NetBSD.org>.
-    Jaromir Dolecek
-    <jdolecek@NetBSD.org>
-    contributed to making this driver MPSAFE.

-

-

-

-
At least some Intel nvme adapter cards are
-    known to require PCIe Generation 3 slot. Such cards do not even probe when
-    plugged into older generation slot.

-
The driver was also tested and confirmed working fine for emulated
-    nvme devices under QEMU 2.8.0, Oracle VirtualBox
-    5.1.20, and Parallels Desktop 16.

-
For Parallels Desktop, it's important the virtual machine has the
-    NVMe disks configured starting from 'NVMe 1', in order for the NVMe
-    namespaces to be correctly initialized and ld(4) devices
-    to be attached.

-

-

-
-  
-    
-    
-  
-
October 5, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/nvmm.4 4.html b/static/netbsd/man4/nvmm.4 4.html
deleted file mode 100644
index da5583e5..00000000
--- a/static/netbsd/man4/nvmm.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
NVMM(4)Device Drivers ManualNVMM(4)

-

-

-

-
nvmm — NetBSD
-    Virtual Machine Monitor

-

-

-

-
The nvmm driver provides kernel support
-    for hardware-accelerated virtualization. It is made of a generic MI
-    frontend, to which MD backends can be plugged to implement the core
-    virtualization.

-
In practice, nvmm is used by the
-    libnvmm(3) API to implement hypervisors.

-

-

-

-
The following backends are supported:

-
    
-  
  • x86-SVM, for x86 AMD CPUs
    • 
-  
  • x86-VMX, for x86 Intel CPUs
    • 
-

-Note that for VMX support, the CPU must also support "VMX Unrestricted
-  Guest", which is only present if Extended Page Tables (EPT) is supported.
-  The earliest CPU family with this feature is Westmere, and not all later CPUs
-  have it.
-

-

-

-
libnvmm(3), nvmmctl(8)

-

-

-

-
The nvmm driver was written by
-    Maxime Villard.

-

-

-
-  
-    
-    
-  
-
July 30, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/oak.4 4.html b/static/netbsd/man4/oak.4 4.html
deleted file mode 100644
index 712d6129..00000000
--- a/static/netbsd/man4/oak.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
OAK(4)Device Drivers ManualOAK(4)

-

-

-

-
oak — Oak SCSI I
-    Card device interface

-

-

-

-
oak0 at podulebus?

-

-

-

-
The oak interface provides access to Oak
-    SCSI I interfaces.

-

-

-

-
asc(4), cosc(4),
-    csc(4), podulebus(4),
-    ptsc(4)

-

-

-
-  
-    
-    
-  
-
April 6, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/oboe.4 4.html b/static/netbsd/man4/oboe.4 4.html
deleted file mode 100644
index cb60efd7..00000000
--- a/static/netbsd/man4/oboe.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
OBOE(4)Device Drivers ManualOBOE(4)

-

-

-

-
oboe — Toshiba
-    OBOE IrDA SIR/FIR driver

-

-

-

-
oboe* at pci? dev ? function ?
-  

-  irframe* at oboe?

-

-

-

-
The oboe driver provides support for the
-    Toshiba Oboe IrDA chip.

-
Access to the device is through the irframe(4)
-    driver.

-

-

-

-
irframe(4), pci(4)

-

-

-

-
The oboe driver appeared in
-    NetBSD 1.6.

-

-

-

-
Jan Sparud
-    <jan@sparud.net>

-

-

-
-  
-    
-    
-  
-
December 2, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ofisa.4 4.html b/static/netbsd/man4/ofisa.4 4.html
deleted file mode 100644
index 754463b3..00000000
--- a/static/netbsd/man4/ofisa.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
OFISA(4)Device Drivers ManualOFISA(4)

-

-

-

-
ofisa —
-    introduction to machine-independent Open Firmware ISA bus
-    support and drivers

-

-

-

-
ofisa* at mainbus0
-  

-  XX* at ofisa?

-

-

-

-
NetBSD includes a machine-independent ISA
-    bus subsystem and several machine-independent ISA device drivers. The
-    ofisa bus uses Open Firmware to determine how to
-    attach devices.

-

-

-

-
NetBSD includes machine-independent Open
-    Firmware ISA drivers, sorted by device type and driver name:

-

-

-

-

-  
wdc

-  
Standard Western Digital type hard drive controllers: MFM, RLL, ESDI, and
-      IDE/ATAPI.

-

-

-

-

-

-

-

-  
com

-  
NS8250-, NS16450-, and NS16550-based serial ports.

-  
lpt

-  
Standard ISA parallel port interface.

-

-

-

-

-

-

-

-  
cs

-  
Cirrus Logic Crystal CS8900 Ethernet interfaces.

-

-

-

-

-

-

-

-  
ess

-  
ESS Technology AudioDrive 1788-, 1888-, 1887-, and 888-based sound
-    cards.

-

-

-

-

-

-

-

-  
joy

-  
Game (joystick) adapters.

-

-

-

-

-

-

-
com(4), cs(4),
-    ess(4), intro(4),
-    isa(4), joy(4),
-    lpt(4), wdc(4)

-

-

-

-
The Open Firmware ISA subsystem appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
July 25, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/ohci.4 4.html b/static/netbsd/man4/ohci.4 4.html
deleted file mode 100644
index 1b29c122..00000000
--- a/static/netbsd/man4/ohci.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
OHCI(4)Device Drivers ManualOHCI(4)

-

-

-

-
ohci — USB Open
-    Host Controller driver

-

-

-

-
ohci* at cardbus? function ?
-  

-  ohci* at pci? dev ? function ?
-  

-  usb* at ohci?

-

-

-
ohci0 at pxaip?

-

-

-

-

-
The ohci driver provides support for USB
-    Open Host Controller Interface.

-

-

-

-
cardbus(4), pci(4),
-    usb(4)

-

-

-

-
The ohci driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 4, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/onewire.4 4.html b/static/netbsd/man4/onewire.4 4.html
deleted file mode 100644
index 949f83d9..00000000
--- a/static/netbsd/man4/onewire.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
ONEWIRE(4)Device Drivers ManualONEWIRE(4)

-

-

-

-
onewire — 1-Wire
-    bus

-

-

-

-
onewire* at gpioow?

-

-  

-  option ONEWIREVERBOSE

-

-

-

-
1-Wire bus was originally developed by Dallas Semiconductor for
-    connecting integrated circuits. It is commonly used for connecting devices
-    such as electronic keys, EEPROMs, temperature sensors, real-time clocks,
-    security chips, etc.

-
The onewire driver provides a uniform
-    programming interface layer between 1-Wire master controllers and various
-    1-Wire slave devices. Each 1-Wire master controller attaches a
-    onewire framework; several slave devices can then be
-    attached to the onewire bus.

-
The driver supports plugging and unplugging slave devices on the
-    fly.

-

-

-

-

-

-  
ds2482ow(4)

-  
I2C to 1-Wire bridge

-  
gpioow(4)

-  
1-Wire bus bit-banging through GPIO pin

-

-

-

-

-

-

-

-  
ds28e17iic(4)

-  
1-Wire to IIC bridge

-  
owtemp(4)

-  
temperature family type device

-

-

-

-

-

-
intro(4)

-

-

-

-
The onewire driver first appeared in
-    OpenBSD 4.0 and NetBSD
-  4.0.

-

-

-

-
The onewire driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>
-    and ported to NetBSD by Jeff
-    Rizzo
-    <riz@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 4, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/oosiop.4 3.html b/static/netbsd/man4/oosiop.4 3.html
deleted file mode 100644
index 9fda7da4..00000000
--- a/static/netbsd/man4/oosiop.4 3.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
OOSIOP(4)Device Drivers ManualOOSIOP(4)

-

-

-

-
oosiop —
-    Symbios/NCR 53C700 SCSI driver

-

-

-

-

-

-
oosiop* at jazzio?

-

-

-

-
oosiop0 at gsc?

-

-  

-  scsibus* at oosiop?

-

-

-

-

-
The oosiop driver provides support for the
-    Symbios/NCR 53C700 SCSI controller chip.

-
For the Symbios/NCR 53C710 SCSI host adapters, use the
-    osiop(4) driver.

-
For the Symbios/NCR 53C8xx PCI SCSI host adapters, use the
-    siop(4) or esiop(4) driver.

-

-

-

-
cd(4), ch(4),
-    esiop(4), intro(4),
-    osiop(4), scsi(4),
-    sd(4), siop(4), ss(4),
-    st(4), uk(4),
-    scsipi(9)

-

-

-

-
oosiop driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The oosiop driver was originally written
-    by Shuichiro URATA for the arc port. Izumi Tsutsui modified the driver to
-    make it really machine independent for hppa.

-

-

-
-  
-    
-    
-  
-
April 6, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/opl.4 4.html b/static/netbsd/man4/opl.4 4.html
deleted file mode 100644
index f61ef022..00000000
--- a/static/netbsd/man4/opl.4 4.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
OPL(4)Device Drivers ManualOPL(4)

-

-

-

-
opl — Yamaha OPL2
-    and OPL3 FM MIDI synthesizer driver

-

-

-

-
opl* at cmpci? flags 1
-  

-  opl* at eso?
-  

-  opl* at ess?
-  

-  opl* at fms?
-  

-  opl0 at isa? port 0x388
-  

-  opl* at sb?
-  

-  opl* at sv?
-  

-  opl* at wss?
-  

-  opl* at yds?
-  

-  opl* at ym?
-  

-  midi* at opl?

-

-

-

-
The opl driver provides support for the
-    Yamaha OPL2 (YM3812) and OPL3 (YMF262) chips. The chips are FM synthesizers
-    and are capable of producing a wide range of sounds.

-
Access to the device is through the MIDI driver.

-
The opl driver usually attaches to a sound
-    card, but it can also sit directly on the ISA bus.

-
If “flags 1” is specified, the
-    opl driver handles left and right channels of OPL3
-    swapped. Use this flag if your device has such problem.

-

-

-

-
cmpci(4), eso(4),
-    ess(4), fms(4),
-    isa(4), midi(4),
-    sb(4), sv(4), wss(4),
-    yds(4), ym(4)

-

-

-

-
The opl device driver appeared in
-    NetBSD 1.4.

-

-

-

-
The OPL3 chip is operated in OPL2 mode despite being more
-  capable.

-

-

-
-  
-    
-    
-  
-
January 3, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/optiide.4 4.html b/static/netbsd/man4/optiide.4 4.html
deleted file mode 100644
index 924e6774..00000000
--- a/static/netbsd/man4/optiide.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
OPTIIDE(4)Device Drivers ManualOPTIIDE(4)

-

-

-

-
optiide — OPTi IDE
-    disk controllers driver

-

-

-

-
optiide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The optiide driver supports the OPTi
-    82c621, 82c568 and 82d568 IDE controllers, and provides the interface with
-    the hardware for the ata(4) driver.

-
The 0x0002 flag forces the optiide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 25 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/options.4 3.html b/static/netbsd/man4/options.4 3.html
deleted file mode 100644
index 6871c04a..00000000
--- a/static/netbsd/man4/options.4 3.html	
+++ /dev/null
@@ -1,2009 +0,0 @@
-
-  
-    
-    
-    
-  
-
OPTIONS(4)Device Drivers ManualOPTIONS(4)

-

-

-

-
options —
-    Miscellaneous kernel configuration options

-

-

-

-
cinclude ...
-  

-  config ...
-  

-  [no] file-system ...
-  

-  ident ...
-  

-  include ...
-  

-  [no] makeoptions ...
-  

-  maxusers ...
-  

-  [no] options ...
-  

-  [no] pseudo-device ...

-

-

-

-
This manual page describes a number of miscellaneous kernel
-    configuration options that may be specified in a kernel config file. See
-    config(1) and config(5) for information
-    on how to configure and build kernels.

-
The no form removes a previously specified
-    option.

-

-

-
The following keywords are recognized in a kernel configuration
-    file:

-

-  

-    "filename"

-  
Conditionally includes another kernel configuration file whose name is
-      filename, which may be double-quoted and may be an
-      explicit path or relative to the kernel source directory. Failure to open
-      the named file is ignored.

-  

-    exec_name root on
-    rootdev [type fstype] [dumps on
-    dumpdev]

-  
Defines a configuration whose kernel executable is named
-      exec_name, normally “netbsd”, with its
-      root file system of type fstype on the device
-      rootdev, and optionally specifying the location of
-      kernel core dumps on the device dumpdev.
-      dev or dumpdev and
-      fstype may be specified as “?”, which
-      is a wild card. The root fstype and
-      dumpdev are optional and assumed to be wild carded
-      if they are not specified.

-  
device_instance at
-    attachment [locators value
-    [...]] [flags value]

-  
Define an instance of the device driver
-      device_instance that attaches to the bus or device
-      named attachment. An
-      attachment may require additional information on
-      where the device can be found, such as an address, channel, function,
-      offset, and/or slot, referred to as locators, whose
-      value often may be a wild card, “?”.
-      Some device drivers have one or more flags that can
-      be adjusted to affect the way they operate.

-  

-    fs_name [, fs_name [...]]

-  
Include support for the file-system fs_name.

-  

-    "string"

-  
Sets the kernel identification string to
-    string.

-  

-    "filename"

-  
Functions the same as cinclude, except failure to
-      open filename produces a fatal error.

-  

-    name=value

-  
Defines a make(1) macro name with
-      the value value in the kernel Makefile.

-  

-    integer

-  
Set the maxusers variable in the kernel.

-  

-    keyword name
-    [arguments [...]]

-  
For the config(1) keywords
-      file-system, makeoptions, options, and pseudo-device,
-      no removes the file-system, makeoption, options, or
-      pseudo-device, name. This is useful when a kernel
-      configuration file includes another which has undesired options.
-    
For example, a local configuration file that wanted the
-        kitchen sink, but not COMPAT_09 or bridging, might be:

-    

-    
include "arch/i386/conf/GENERIC"
-no options COMPAT_09
-no pseudo-device bridge

-    

-  

-  

-    option_name [, option_name=value
-    [...]]

-  
Specifies (or sets) the option, or comma-separated list of options,
-      option_name. Some options expect to be assigned a
-      value, which may be an integer, a double-quoted word, a bare word, or an
-      empty string (""). Note that those are eventually handled by the
-      C compiler, so the rules of that language apply.
-    
:
-        Options that are not defined by device definition files are passed to
-        the compile process as -D flags to the C
-        compiler.

-  

-  

-    name [N]

-  
Includes support for the pseudo-device name. Some
-      pseudo-devices can have multiple or N
-    instances.

-

-

-

-

-
Note that compatibility options for older
-    NetBSD releases includes support for newer releases
-    as well. This means that typically only one of these is necessary, with the
-    COMPAT_09 option enabling all
-    NetBSD compatibility. This does not include the
-    COMPAT_43 or COMPAT_44
-    options.

-

-  
options COMPAT_09

-  
Enable binary compatibility with NetBSD 0.9. This
-      enables support for 16-bit user, group, and process IDs (following
-      revisions support 32-bit identifiers). It also allows the use of the
-      deprecated getdomainname(3),
-      setdomainname(3), and uname(3)
-      syscalls. This option also allows using numeric file system identifiers
-      rather than strings. Post NetBSD 0.9 versions use
-      string identifiers.

-  
options COMPAT_10

-  
Enable binary compatibility with NetBSD 1.0. This
-      option allows the use of the file system name of “ufs” as an
-      alias for “ffs”. The name “ffs” should be used
-      post 1.0 in /etc/fstab and other files. It also
-      adds old syscalls for the AT&T System V
-      UNIX shared memory interface. This was changed post 1.0 to work on
-      64-bit architectures. This option also enables “sgtty”
-      compatibility, without which programs using the old interface produce an
-      “inappropriate ioctl” error, and
-      /dev/io only works when this option is set in the
-      kernel, see io(4) on ports that support it.

-  
options COMPAT_11

-  
Enable binary compatibility with NetBSD 1.1. This
-      allows binaries running on the i386 port to gain direct access to the io
-      ports by opening /dev/io read/write. This
-      functionality was replaced by i386_iopl(2) post 1.1. On
-      the Atari port, the location of the disk label was moved after 1.1. When
-      the 
-      option is set, the kernel will read (pre) 1.1 style disk labels as a last
-      resort. When a disk label is re-written, the old style label will be
-      replaced with a post 1.1 style label. This also enables the
-      EXEC_ELF_NOTELESS option.

-  
options COMPAT_12

-  
Enable binary compatibility with NetBSD 1.2. This
-      allows the use of old syscalls for
-      ()
-      and
-      ().
-      The syscall numbers were changed post 1.2 to add functionality to the
-      reboot(2) syscall, and the new
-      swapctl(2) interface was introduced. This also enables
-      the EXEC_ELF_NOTELESS option.

-  
options COMPAT_13

-  
Enable binary compatibility with NetBSD 1.3. This
-      allows the use of old syscalls for
-      (),
-      and also enables the old swapctl(2) command
-      SWAP_STATS (now called
-      SWAP_OSTATS), which does not include the
-      se_path member of struct
-      swapent.

-  
options COMPAT_14

-  
Enable binary compatibility with NetBSD 1.4. This
-      allows some old ioctl(2) on wscons(4)
-      to be performed, and allows the NFSSVC_BIOD mode
-      of the nfssvc(2) system call to be used for
-      compatibility with the deprecated nfsiod program.

-  
options COMPAT_15

-  
Enable binary compatibility with NetBSD 1.5. Since
-      there were no API changes from NetBSD 1.5 and
-      NetBSD 1.6, this option does nothing.

-  
options COMPAT_16

-  
Enable binary compatibility with NetBSD 1.6. This
-      allows the use of old signal trampoline code which has been deprecated
-      with the addition of siginfo(2).

-  
options COMPAT_20

-  
Enable binary compatibility with NetBSD 2.0. This
-      allows the use of old syscalls for
-      (),
-      (),
-      ()
-      and
-      (),
-      which have been deprecated with the addition of the
-      statvfs(2), fstatvfs(2),
-      getvfsstat(2) and fhstatvfs(2) system
-      calls.

-  
options COMPAT_30

-  
Enable binary compatibility with NetBSD 3.0. See
-      compat_30(8) for details about the changes made after
-      the NetBSD 3.0 release.

-  
options COMPAT_40

-  
Enable binary compatibility with NetBSD 4.0. This
-      allows the use of old ptrace(2) calls for the SH3
-      platform. It also enables the old mount(2) system call
-      that did not include the data length parameter. The power_event_t
-      structure's pev_switch is filled in.

-  
options COMPAT_43

-  
Enables compatibility with 4.3BSD. This adds an
-      old syscall for lseek(2). It also adds the ioctls for
-      TIOCGETP and TIOCSETP. The
-      return values for getpid(2),
-      getgid(2), and getuid(2) syscalls are
-      modified as well, to return the parent's PID and UID as well as the
-      current process's. It also enables the deprecated
-      NTTYDISC terminal line discipline. It also
-      provides backwards compatibility with “old”
-      SIOC[GS]IF{ADDR,DSTADDR,BRDADDR,NETMASK} interface ioctls, including
-      binary compatibility with code written before the introduction of the
-      sa_len field in sockaddrs. It also enables support for some older pre
-      4.4BSD socket calls.

-  
options COMPAT_50

-  
Enable binary compatibility with NetBSD 5.0. This
-      enables support for the old time_t and
-      dev_t types as 32 bit, and all the associated kernel
-      interface changes. It also enables old gpio(4) and
-      rnd(4) interfaces.

-  
options COMPAT_60

-  
Enable binary compatibility with NetBSD 6.0. This
-      provides old ccd(4) interfaces, enables support for old
-      cpuctl(8) microcode interfaces, and support for the old
-      ptmget structure.

-  
options COMPAT_70

-  
Enable binary compatibility with NetBSD 7.0. This
-      provides support for old route(4) interfaces.

-  
options COMPAT_80

-  
Enable binary compatibility with NetBSD 8.0.

-  
options COMPAT_90

-  
Enable binary compatibility with NetBSD 9.0.

-  
options COMPAT_BSDPTY

-  
This option is currently on by default and enables the pty multiplexer
-      ptm(4) and ptmx(4) to find and use
-      ptys named /dev/ptyXX (master) and
-      /dev/ttyXX (slave). Eventually this option will
-      become optional as ptyfs based pseudo-ttys become the default, see
-      mount_ptyfs(8).

-  
options COMPAT_LINUX

-  
On those architectures that support it, this enables binary compatibility
-      with Linux ELF and a.out(5) applications built for the
-      same architecture. This currently includes the alpha, arm, i386, m68k,
-      mips, powerpc and x86_64 ports.

-  
options COMPAT_LINUX32

-  
On those 64 bit architectures that support it, this enables binary
-      compatibility with 32 bit Linux binaries. For now this is limited to
-      running i386 ELF Linux binaries on amd64.

-  
options COMPAT_SUNOS

-  
On those architectures that support it, this enables binary compatibility
-      with SunOS 4.1 applications built for the same architecture. This
-      currently includes the sparc, sparc64 and most or all m68k ports. Note
-      that the sparc64 requires the
-      
-      option for 64-bit kernels, in addition to this option.

-  
options COMPAT_ULTRIX

-  
On those architectures that support it, this enables binary compatibility
-      with ULTRIX applications built for the same architecture. This currently
-      is limited to the pmax. The functionality of this option is unknown.

-  
options COMPAT_FREEBSD

-  
On those architectures that support it, this enables binary compatibility
-      with FreeBSD applications built for the same
-      architecture. At the moment this is limited to the i386 port.

-  
options COMPAT_NOMID

-  
Enable compatibility with a.out(5) executables that lack
-      a machine ID. This includes NetBSD 0.8's ZMAGIC
-      format, and 386BSD and BSDI's QMAGIC, NMAGIC, and OMAGIC
-      a.out(5) formats.

-  
options COMPAT_NETBSD32

-  
On those architectures that support it, this enables binary compatibility
-      with 32-bit applications built for the same architecture. This is
-      currently limited to the amd64 and sparc64 ports, and only applicable for
-      64-bit kernels.

-  
options COMPAT_AOUT_M68K

-  
On m68k architectures which have switched to ELF, this enables binary
-      compatibility with NetBSD/m68k
-      a.out(5) executables on
-      NetBSD/m68k ELF kernels. This handles alignment
-      incompatibility of m68k ABI between a.out and ELF which causes the
-      structure padding differences. Currently only some system calls which use
-      struct stat are adjusted and some binaries which use
-      sysctl(3) to retrieve network details would not work
-      properly.

-  
options EMUL_NATIVEROOT=string

-  
Just like emulated binaries first try looking up files in an emulation
-      root (e.g. /emul/linux) before looking them up in
-      real root, this option causes native binaries to first look up files in an
-      "emulation" directory too. This can be useful to test an amd64
-      kernel on top of an i386 system before full migration: by unpacking the
-      amd64 distribution in e.g. /emul/netbsd64 and
-      specifying that location as EMUL_NATIVEROOT,
-      native amd64 binaries can be run while the root file system remains
-      populated with i386 binaries. Beware of /dev
-      incompatibilities between i386 and amd64 if you do this.

-  
options EXEC_ELF_NOTELESS

-  
Run unidentified ELF binaries as NetBSD binaries.
-      This might be needed for very old NetBSD ELF
-      binaries on some archs. These old binaries didn't contain an appropriate
-      .note.netbsd.ident section, and thus can't be
-      identified by the kernel as NetBSD binaries
-      otherwise. Beware - if this option is on, the kernel would run
-       unknown ELF
-      binaries as if they were NetBSD binaries.

-

-

-

-

-

-  
options DDB

-  
Compiles in a kernel debugger for diagnosing kernel problems. See
-      ddb(4) for details. NOTE: not
-      available on all architectures.

-  
options
-    DDB_FROMCONSOLE=integer

-  
If set to non-zero, DDB may be entered by sending a break on a serial
-      console or by a special key sequence on a graphics console. A value of
-      "0" ignores console breaks or key sequences. If not explicitly
-      specified, the default value is "1". Note that this sets the
-      value of the
-      
-      sysctl(3) variable which may be changed at run time
-      — see sysctl(8) for details.

-  
options DDB_HISTORY_SIZE=integer

-  
If this is non-zero, enable history editing in the kernel debugger and set
-      the size of the history to this value.

-  
options DDB_ONPANIC

-  
The default if not specified is “1” - just enter into DDB.
-      If set to “0” the kernel will attempt to print out a stack
-      trace and reboot the system. If set to “-1” then neither a
-      stack trace is printed or DDB entered - it is as if DDB were not compiled
-      into the kernel. Note that this sets the value of the
-      
-      sysctl(3) variable which may be changed at run time
-      — see sysctl(8) for details.

-  
options
-    DDB_COMMANDONENTER=string

-  
This option specify commands which will be executed on each entry to DDB.
-      This sets the default value of the
-      
-      sysctl(3) variable which may be changed at run
-    time.

-  
options DDB_BREAK_CHAR=integer

-  
This option overrides using break to enter the kernel debugger on the
-      serial console. The value given is the ASCII value to be used instead.
-      This is currently only supported by the com driver.

-  
options CNMAGIC=string

-  
This option overrides the cnmagic(9) string used to
-      enter the kernel debugger.

-  
options DDB_VERBOSE_HELP

-  
This option adds more verbose descriptions to the
-       command.

-  
options DDB_PANICSTACKFRAMES=integer

-  
Number of stack frames to display on panic. Useful to avoid scrolling away
-      the interesting frames on a glass tty. Default value is
-      65535 (all frames), useful value around
-      10.

-  
options KGDB

-  
Compiles in a remote kernel debugger stub for diagnosing kernel problems
-      using the “remote target” feature of gdb. See
-      gdb(1) for details. NOTE: not
-      available on all architectures.

-  
options KGDB_DEV

-  
Device number (as a dev_t) of kgdb device.

-  
options KGDB_DEVADDR

-  
Memory address of kgdb device.

-  
options KGDB_DEVMODE

-  
Permissions of kgdb device.

-  
options KGDB_DEVNAME

-  
Device name of kgdb device.

-  
options KGDB_DEVRATE

-  
Baud rate of kgdb device.

-  
makeoptions DEBUG="-g"

-  
The -g flag causes
-      netbsd.gdb to be built in addition to
-      netbsd. netbsd.gdb is
-      useful for debugging kernel crash dumps with gdb. See
-      gdb(1) for details.

-  
options DEBUG

-  
Turns on miscellaneous kernel debugging. Since options are turned into
-      preprocessor defines (see above), options DEBUG is
-      equivalent to doing a
-      
-      throughout the kernel. Much of the kernel has #ifdef
-      DEBUG conditionalized debugging code. Note that many parts of the
-      kernel (typically device drivers) include their own #ifdef
-      XXX_DEBUG conditionals instead. This option also turns on certain
-      other options, which may decrease system performance. Systems with this
-      option are not suitable for regular use, and are intended only for
-      debugging or looking for bugs.

-  
options DIAGNOSTIC

-  
Adds code to the kernel that does internal consistency checks. This code
-      will cause the kernel to panic if corruption of internal data structures
-      is detected. Historically, the performance degradation is sufficiently
-      small that it is reasonable for systems with options
-      DIAGNOSTIC to be in production use, with the real consideration not
-      being performance but instead a preference for more panics versus
-      continued operation with undetected problems.

-  
options LOCKDEBUG

-  
Adds code to the kernel to detect incorrect use of locking primitives
-      (mutex, rwlock). This code will cause the kernel to check for dead lock
-      conditions. It will also check for memory being freed to not contain
-      initialised lock primitives. Functions for use in ddb(4)
-      to check lock chains etc. are also enabled. These checks are very
-      expensive and can decrease performance on multi-processor machines by a
-      factor of three.

-  
options KDTRACE_HOOKS

-  
Adds hooks for the DTrace tracing facility, which allows users to analyze
-      many aspects of system and application behavior. See
-      dtrace(1) for details.

-  
options KSTACK_CHECK_MAGIC

-  
Check kernel stack usage and panic if stack overflow is detected. This
-      check is performance sensitive because it scans stack on each context
-      switch.

-  
options KTRACE

-  
Add hooks for the system call tracing facility, which allows users to
-      watch the system call invocation behavior of processes. See
-      ktrace(1) for details.

-  
options MSGBUFSIZE=integer

-  
This option sets the size of the kernel message buffer in bytes. This
-      buffer holds the kernel output of
-      ()
-      when not (yet) read by syslogd(8). This is particularly
-      useful when the system has crashed and you wish to lookup the kernel
-      output from just before the crash. Also, since the autoconfig output
-      becomes more and more verbose, it sometimes happens that the message
-      buffer overflows before syslogd(8) was able to read it.
-      Note that not all systems are capable of obtaining a variable sized
-      message buffer. There are also some systems on which memory contents are
-      not preserved across reboots.

-  
options KERNHIST

-  
Enables the kernel history logs, which create in-memory traces of various
-      kernel activities. These logs can be displayed by using
-      show kernhist from DDB. See the kernel source file
-      sys/kern/kern_history.c and the
-      kernhist(9) manual for details.

-  
options KERNHIST_PRINT

-  
Prints the kernel history logs on the system console as entries are added.
-      Note that the output is extremely voluminous, so this
-      option is really only useful for debugging the very earliest parts of
-      kernel initialization.

-  
options UVMHIST

-  
Like KERNHIST, it enables the UVM history logs. These
-      logs can be displayed by using show kernhist from
-      DDB. See the kernel source file sys/uvm/uvm_stat.c
-      for details.

-  
options UVMHIST_PRINT

-  
Like UVMHIST, it prints the UVM history logs on the
-      system console as entries are added. Note that the output is
-      extremely voluminous, so this option is really only
-      useful for debugging the very earliest parts of kernel
-    initialization.

-  
options UVMHIST_MAPHIST_SIZE

-  
Set the size of the “maphist” kernel history. The default is
-      100. This option depends upon the UVMHIST option.

-  
options UVMHIST_PDHIST_SIZE

-  
Set the size of the “pdhist” kernel history. The default is
-      100. This option depends upon the UVMHIST option.

-  
options BIOHIST

-  
Like KERNHIST, it enables the BIO history logs. These
-      logs can be displayed by using show kernhist from
-      DDB, and can help in debugging problems with Buffered I/O operations. See
-      the kernel source file sys/kern/vfs_vio.c for
-      details.

-  
options BIOHIST_PRINT

-  
Like BIOHIST, it prints the BIO history logs on the
-      system console as entries are added. Note that the output is
-      extremely voluminous, so this option is really only
-      useful for debugging the very earliest parts of kernel
-    initialization.

-  
options BIOHIST_SIZE

-  
Set the size of the “biohist” kernel history. The default is
-      500. This option depends upon the BIOHIST option.

-

-

-

-

-

-  
file-system FFS

-  
Includes code implementing the Berkeley Fast File System
-      (). Most
-      machines need this if they are not running diskless.

-  
file-system EXT2FS

-  
Includes code implementing the Second Extended File System
-      (ext2), revision 0 and revision 1 with the
-      ,
-      
-      and
-      
-      options. This is the most commonly used file system on the Linux operating
-      system, and is provided here for compatibility. Some of the specific
-      features of ext2 like the "behavior on errors"
-      are not implemented. See mount_ext2fs(8) for
-    details.

-  
file-system LFS

-  
[EXPERIMENTAL] Include the Log-structured File System
-      (). See
-      mount_lfs(8) and newfs_lfs(8) for
-      details.

-  
file-system MFS

-  
Include the Memory File System
-      (). This file
-      system stores files in swappable memory, and produces notable performance
-      improvements when it is used as the file store for
-      /tmp and similar file systems. See
-      mount_mfs(8) for details.

-  
file-system NFS

-  
Include the client side of the Network File System (NFS) remote file
-      sharing protocol. Although the bulk of the code implementing NFS is kernel
-      based, several user level daemons are needed for it to work. See
-      mount_nfs(8) for details.

-  
file-system CD9660

-  
Includes code for the ISO 9660 + Rock Ridge file system, which is the
-      standard file system on many CD-ROM discs. Useful primarily if you have a
-      CD-ROM drive. See mount_cd9660(8) for details.

-  
file-system MSDOSFS

-  
Includes the MS-DOS FAT file system, which is reportedly still used by
-      unfortunate people who have not heard about
-      NetBSD. Also implements the Windows 95 extensions
-      to the same, which permit the use of longer, mixed case file names. See
-      mount_msdos(8) and fsck_msdos(8) for
-      details.

-  
file-system NTFS

-  
[EXPERIMENTAL] Includes code for the Microsoft Windows
-      NT file system. See mount_ntfs(8) for details.

-  
file-system FDESC

-  
Includes code for a file system, conventionally mounted on
-      /dev/fd, which permits access to the per-process
-      file descriptor space via special files in the file system. See
-      mount_fdesc(8) for details. Note that this facility is
-      redundant, and thus unneeded on most NetBSD
-      systems, since the fd(4) pseudo-device driver already
-      provides identical functionality. On most NetBSD
-      systems, instances of fd(4) are mknoded under
-      /dev/fd/ and on
-      /dev/stdin, /dev/stdout,
-      and /dev/stderr.

-  
file-system KERNFS

-  
Includes code which permits the mounting of a special file system
-      (normally mounted on /kern) in which files
-      representing various kernel variables and parameters may be found. See
-      mount_kernfs(8) for details.

-  
file-system NULLFS

-  
Includes code for a loopback file system. This permits portions of the
-      file hierarchy to be re-mounted in other places. The code really exists to
-      provide an example of a stackable file system layer. See
-      mount_null(8) for details.

-  
file-system OVERLAY

-  
Includes code for a file system filter. This permits the overlay file
-      system to intercept all access to an underlying file system. This file
-      system is intended to serve as an example of a stacking file system which
-      has a need to interpose itself between an underlying file system and all
-      other access. See mount_overlay(8) for details.

-  
file-system PROCFS

-  
Includes code for a special file system (conventionally mounted on
-      /proc) in which the process space becomes visible
-      in the file system. Among other things, the memory spaces of processes
-      running on the system are visible as files, and signals may be sent to
-      processes by writing to ctl files in the procfs
-      namespace. See mount_procfs(8) for details.

-  
file-system UDF

-  
Includes code for the UDF file system commonly found on CD and DVD media
-      but also on USB sticks and harddiscs for interchange and backup. Supports
-      read and write access for all formats on discs and on rewritable and
-      recordable CD/DVD/BD media. It has a somewhat limited write support for
-      UDF 2.50 as it can't expand the metadata partion. See
-      mount_udf(8) and fsck_udf(8) for
-      details.

-  
file-system UMAPFS

-  
Includes a loopback file system in which user and group IDs may be
-      remapped — this can be useful when mounting alien file systems with
-      different UIDs and GIDs than the local system. See
-      mount_umap(8) for details.

-  
file-system UNION

-  
[EXPERIMENTAL] Includes code for the union file system,
-      which permits directories to be mounted on top of each other in such a way
-      that both file systems remain visible — this permits tricks like
-      allowing writing (and the deleting of files) on a read-only file system
-      like a CD-ROM by mounting a local writable file system on top of the
-      read-only file system. See mount_union(8) for
-    details.

-  
file-system CODA

-  
[EXPERIMENTAL] Includes code for the Coda file system.
-      Coda is a distributed file system like NFS and AFS. It is freely
-      available, like NFS, but it functions much like AFS in being a
-      “stateful” file system. Both Coda and AFS cache files on
-      your local machine to improve performance. Then Coda goes a step further
-      than AFS by letting you access the cached files when there is no available
-      network, viz. disconnected laptops and network outages. In Coda, both the
-      client and server are outside the kernel which makes them easier to
-      experiment with. Coda is available for several UNIX and non-UNIX
-      platforms. See
-      http://www.coda.cs.cmu.edu
-      for more details. NOTE: You also need to enable the
-      pseudo-device, vcoda, for the Coda file system to work.

-  
file-system PTYFS

-  
Includes code for a special file system (normally mounted on
-      /dev/pts) in which pseudo-terminal slave devices
-      become visible in the file system. See mount_ptyfs(8)
-      for details.

-  
file-system TMPFS

-  
Includes code for the efficient memory file system, normally used over
-      /tmp. See mount_tmpfs(8) for
-      details.

-  
file-system PUFFS

-  
Includes kernel support for the pass-to-userspace framework file system.
-      It can be used to implement file system functionality in userspace. See
-      puffs(3) for more details. This enables for example
-      sshfs: mount_psshfs(8).

-

-

-

-

-

-  
options DISKLABEL_EI

-  
Enable “Endian-Independent” disklabel(5)
-      support. This allows a system to recognize a disklabel written in the
-      other byte order. For writing, when a label already exists, its byte order
-      is preserved. Otherwise, a new label is written in the native byte order.
-      To specify the byte order explicitly, the -F
-      option of disklabel(8) should be used with the
-      -B option in order to avoid using
-      ioctl(2), which results in the default behavior
-      explained above. At the moment this option is restricted to the following
-      ports: amd64, bebox, emips, epoc32, evbarm, i386, ibmnws, landisk,
-      mvmeppc, prep, rs6000, sandpoint, xen, and zaurus; also to machines of the
-      evbmips and evbppc ports that support Master Boot Record (MBR).

-  
options MAGICLINKS

-  
Enables the expansion of special strings (beginning with
-      “@”) when traversing symbolic links. See
-      symlink(7) for a list of supported strings. Note that
-      this option only controls the enabling of this feature by the kernel at
-      boot-up. This feature can still be manipulated with the
-      sysctl(8) command regardless of the setting of this
-      option.

-  
options NFSSERVER

-  
Include the server side of the NFS (Network File System)
-      remote file sharing protocol. Although the bulk of the code implementing
-      NFS is kernel based, several user level daemons are
-      needed for it to work. See mountd(8) and
-      nfsd(8) for details.

-  
options NVNODE=integer

-  
This option sets the size of the cache used by the name-to-inode
-      translation routines, (a.k.a. the
-      ()
-      cache, though called by many other names in the kernel source). By
-      default, this cache has (NPROC + NTEXT + 100)
-      entries (NPROC set as 20 + 16 * MAXUSERS and NTEXT as 80 + NPROC / 8). A
-      reasonable way to derive a value of NVNODE, should
-      you notice a large number of namei cache misses with a tool such as
-      systat(1), is to examine your system's current computed
-      value with sysctl(8), (which calls this parameter
-      "kern.maxvnodes") and to increase this value until either the
-      namei cache hit rate improves or it is determined that your system does
-      not benefit substantially from an increase in the size of the namei
-    cache.

-  
options NAMECACHE_ENTER_REVERSE

-  
Causes the namei cache to always enter a reverse mapping (vnode ->
-      name) as well as a normal one. Normally, this is already done for
-      directory vnodes, to speed up the getcwd operation. This option will cause
-      longer hash chains in the reverse cache, and thus slow down getcwd
-      somewhat. However, it does make vnode -> path translations possible in
-      some cases. For now, only useful if strict
-      /proc/#/maps emulation for Linux binaries is
-      required.

-

-

-

-

-

-  
options APPLE_UFS

-  
Enable support for UFS file systems created on Mac OS X.

-  
options FFS_EI

-  
Enable “Endian-Independent” FFS support. This allows a
-      system to mount an FFS file system created for another architecture, at a
-      small performance cost for all FFS file systems. See also
-      newfs(8), fsck_ffs(8),
-      dumpfs(8) for file system byte order status and
-      manipulation.

-  
options FFS_NO_SNAPSHOT

-  
Disable support for the creation of file system internal snapshot of FFS
-      file systems. Maybe useful for install media kernels, small memory systems
-      and embedded systems which don't require the snapshot support.

-  
options QUOTA

-  
Enables kernel support for traditional quotas in FFS. Traditional quotas
-      store the quota information in external files and require
-      quotacheck(8) and quotaon(8) at boot
-      time. Traditional quotas are limited to 32-bit sizes and are at this point
-      considered a legacy feature.

-  
options QUOTA2

-  
Enables kernel support for in-volume quotas in FFS. The quota information
-      is file system metadata maintained by fsck(8) and/or
-      WAPBL journaling. MFS volumes can also use QUOTA2
-      quotas; see mount_mfs(8) for more information.

-  
options UFS_DIRHASH

-  
Increase lookup performance by maintaining in-core hash tables for large
-      directories.

-  
options UFS_EXTATTR

-  
Enable extended attribute support for UFS1 file systems.

-  
options WAPBL

-  
Enable “Write Ahead Physical Block Logging file system
-      journaling”. This provides rapid file system consistency checking
-      after a system outage. It also provides better general use performance
-      over regular FFS. See also wapbl(4).

-

-

-

-

-

-  
options LFS_EI

-  
Enable “Endian-Independent” LFS support. This allows (at a
-      small performance cost) mounting an LFS file system created for another
-      architecture.

-  
options LFS_DIRHASH

-  
Increase lookup performance by maintaining in-core hash tables for large
-      directories.

-

-

-

-

-

-  
options NFS_BOOT_BOOTP

-  
Enable use of the BOOTP protocol (RFCs 951 and 1048) to get configuration
-      information if NFS is used to mount the root file system. See
-      diskless(8) for details.

-  
options NFS_BOOT_BOOTSTATIC

-  
Enable use of static values defined as
-      “NFS_BOOTSTATIC_MYIP”, “NFS_BOOTSTATIC_GWIP”,
-      “NFS_BOOTSTATIC_SERVADDR”, and
-      “NFS_BOOTSTATIC_SERVER” in kernel options to get
-      configuration information if NFS is used to mount the root file
-    system.

-  
options NFS_BOOT_DHCP

-  
Same as “NFS_BOOT_BOOTP”, but use the DHCP extensions to the
-      BOOTP protocol (RFC 1541).

-  
options NFS_BOOT_BOOTP_REQFILE

-  
Specifies the string sent in the bp_file field of the BOOTP/DHCP request
-      packet.

-  
options NFS_BOOT_BOOTPARAM

-  
Enable use of the BOOTPARAM protocol, consisting of RARP and BOOTPARAM
-      RPC, to get configuration information if NFS is used to mount the root
-      file system. See diskless(8) for details.

-  
options NFS_BOOT_RWSIZE=value

-  
Set the initial NFS read and write sizes for diskless-boot requests. The
-      normal default is 8Kbytes. This option provides a way to lower the value
-      (e.g., to 1024 bytes) as a workaround for buggy network interface cards or
-      boot PROMs. Once booted, the read and write request sizes can be increased
-      by remounting the file system. See mount_nfs(8) for
-      details.

-  
options NFS_V2_ONLY

-  
Reduce the size of the NFS client code by omitting code that's only
-      required for NFSv3 and NQNFS support, leaving only that code required to
-      use NFSv2 servers.

-  
options NFS_BOOT_UDP

-  
Use NFS over UDP instead of the default TCP, for mounting root.

-

-

-

-

-
The following options enable alternative buffer queue
-  strategies.

-

-  
options BUFQ_READPRIO

-  
Enable alternate buffer queue strategy for disk I/O. In the default
-      strategy, outstanding disk requests are ordered by sector number and sent
-      to the disk, regardless of whether the operation is a read or write; this
-      option gives priority to issuing read requests over write requests.
-      Although requests may therefore be issued out of sector-order, causing
-      more seeks and thus lower overall throughput, interactive system
-      responsiveness under heavy disk I/O load may be improved, as processes
-      blocking on disk reads are serviced sooner (file writes typically don't
-      cause applications to block). The performance effect varies greatly
-      depending on the hardware, drive firmware, file system configuration,
-      workload, and desired performance trade-off. Systems using drive
-      write-cache (most modern IDE disks, by default) are unlikely to benefit
-      and may well suffer; such disks acknowledge writes very quickly, and
-      optimize them internally according to physical layout. Giving these disks
-      as many requests to work with as possible (the standard strategy) will
-      typically produce the best results, especially if the drive has a large
-      cache; the drive will silently complete writes from cache as it seeks for
-      reads. Disks that support a large number of concurrent tagged requests
-      (SCSI disks and many hardware RAID controllers) expose this internal
-      scheduling with tagged responses, and don't block for reads; such disks
-      may not see a noticeable difference with either strategy. However, if IDE
-      disks are run with write-cache disabled for safety, writes are not
-      acknowledged until actually completed, and only one request can be
-      outstanding; a large number of small writes in one locality can keep the
-      disk busy, starving reads elsewhere on the disk. Such systems are likely
-      to see the most benefit from this option. Finally, the performance
-      interaction of this option with ffs soft dependencies can be subtle, as
-      that mechanism can drastically alter the workload for file system metadata
-      writes.

-  
options BUFQ_PRIOCSCAN

-  
Enable another buffer queue strategy for disk I/O, per-priority cyclical
-      scan.

-  
options NEW_BUFQ_STRATEGY

-  
Synonym of
-      .

-

-

-

-

-

-  
options CPU_UCODE

-  
Support cpu microcode loading via cpuctl(8).

-  
options MEMORY_DISK_DYNAMIC

-  
This option makes the md(4) RAM disk size dynamically
-      sized. It is incompatible with mdsetimage(8).

-  
options MEMORY_DISK_HOOKS

-  
This option allows for some machine dependent functions to be called when
-      the md(4) RAM disk driver is configured. This can result
-      in automatically loading a RAM disk from floppy on open (among other
-      things).

-  
options MEMORY_DISK_IS_ROOT

-  
Forces the md(4) RAM disk to be the root device. This
-      can only be overridden when the kernel is booted in the 'ask-for-root'
-      mode.

-  
options MEMORY_DISK_ROOT_SIZE=integer

-  
Allocates the given number of 512 byte blocks as memory for the
-      md(4) RAM disk, to be populated with
-      mdsetimage(8).

-  
options MEMORY_DISK_SERVER=0

-  
Do not include the interface to a userland memory disk server process. Per
-      default, this option is set to 1, including the support code. Useful for
-      install media kernels.

-  
options MEMORY_DISK_RBFLAGS=value

-  
This option sets the reboot(2) flags used when booting
-      with a memory disk as root file system. Possible values include
-      RB_AUTOBOOT (boot in the usual fashion - default
-      value), and RB_SINGLE (boot in single-user
-    mode).

-  
options MODULAR

-  
Enables the framework for kernel modules (see
-      module(7)).

-  
options
-    MODULAR_DEFAULT_AUTOLOAD

-  
Enables the autoloading of kernel modules by default. This sets the
-      default value of the
-      
-      sysctl(3) variable which may be changed at run
-    time.

-  
options
-    MODULAR_DEFAULT_VERBOSE

-  
Enables verbose debug messages of kernel modules by default. This sets the
-      default value of the
-      
-      sysctl(3) variable which may be changed at run
-    time.

-  
options VND_COMPRESSION

-  
Enables the vnd(4) driver to also handle compressed
-      images. See vndcompress(1), vnd(4) and
-      vnconfig(8) for more information.

-  
options SELFRELOC

-  
Make the kernel able to self relocate at bootstrap, so that it can run
-      whatever its load address is. This is intented to be used with the
-      reloc bootstrap command documented in
-      x86/boot(8), to workaround UEFI bugs, and is only
-      available on amd64.

-  
options SPLDEBUG

-  
Help the kernel programmer find bugs related to the interrupt priority
-      level. When
-      ()
-      or
-      ()
-      changes the current CPU's interrupt priority level to or from
-      IPL_HIGH, record a backtrace. Read
-      i386/return_address(9) for caveats about collecting
-      backtraces. This feature is experimental, and it is only available on
-      i386. See sys/kern/subr_spldebug.c.

-  
options TFTPROOT

-  
Download the root memory disk through TFTP at root mount time. This
-      enables the use of a root RAM disk without requiring it to be embedded in
-      the kernel using mdsetimage(8). The RAM disk name is
-      obtained using DHCP's filename parameter. This option requires
-      
-      and
-      .
-      It is incompatible with
-      .

-  
options HEARTBEAT

-  
Turns on heartbeat checks to panic if any CPU in the system or the
-      timecounter appears stuck.
-    
Each CPU will periodically check in hard interrupt context
-        that the timecounter has advanced and soft interrupts have run on the
-        current CPU, and each CPU will also be periodically checked for progress
-        by another CPU.

-    
If a CPU detects no progress has been made after
-        HEARTBEAT_MAX_PERIOD seconds,
-        NetBSD will panic, giving the opportunity to
-        enter ddb or get a crash dump even if the system has become totally
-        unresponsive to keyboard input.

-    
This is different from a hardware watchdog timer
-        (wdogctl(8)):

-    
    
-      
  • options HEARTBEAT is purely a software
-          mechanism, so if hard interrupts are stuck on all CPUs, then
-          options HEARTBEAT cannot trigger, but a
-          hardware watchdog timer can.
    • 
-      
  • A hardware watchdog timer won't notice if a single CPU is stuck, or if
-          the system timecounter is stuck, as long as at least one CPU is not
-          stuck and able to run wdogctl(8) or the kernel
-          watchdog tickle thread. In contrast, options
-          HEARTBEAT uses hard interrupts on each CPU to cross-check soft
-          interrupt progress on another CPU as well as the timecounter, so it
-          can detect when a single CPU is unable to make progress when others
-          are able.
    • 
-    

-  

-  
options HEARTBEAT_MAX_PERIOD_DEFAULT=integer

-  
Time in seconds since the last options HEARTBEAT
-      progress check has passed before it will trigger a panic. Default: 15.
-    
Can be changed at runtime via the
-        kern.heartbeat.max_period
-        sysctl(7) knob.

-  

-  
options HZ=integer

-  
On ports that support it, set the system clock frequency (see
-      hz(9)) to the supplied value. Handle with care.

-  
options NTP

-  
Turns on in-kernel precision timekeeping support used by software
-      implementing NTP (Network Time Protocol, RFC 1305). The
-      NTP option adds an in-kernel Phase-Locked Loop (PLL) for
-      normal NTP operation, and a Frequency-Locked Loop (FLL)
-      for intermittently-connected operation. ntpd(8) will
-      employ a user-level PLL when kernel support is unavailable, but the
-      in-kernel version has lower latency and more precision, and so typically
-      keeps much better time.
-    
The interface to the kernel NTP support is
-        provided by the ntp_adjtime(2) and
-        ntp_gettime(2) system calls, which are intended for
-        use by ntpd(8) and are enabled by the option. On
-        systems with sub-microsecond resolution timers, or where (HZ/100000) is
-        not an integer, the NTP option also enables
-        extended-precision arithmetic to keep track of fractional clock ticks at
-        NTP time-format precision.

-  

-  
options PPS_SYNC

-  
This option enables a kernel serial line discipline for receiving time
-      phase signals from an external reference clock such as a radio clock. Some
-      reference clocks generate a Pulse Per Second (PPS) signal in phase with
-      their time source. The PPS line discipline receives this
-      signal on either the data leads or the DCD control lead of a serial port.
-    
NTP uses the PPS signal to discipline the
-        local clock oscillator to a high degree of precision (typically less
-        than 50 microseconds in time and 0.1 ppm in accuracy).
-        PPS can also generate a serial output pulse when the
-        system receives a PPS interrupt. This can be used to measure the system
-        interrupt latency and thus calibrate NTP to account
-        for it. Using PPS usually requires a gadget box to
-        convert from TTL to RS-232 signal levels. The gadget box and PPS are
-        described in more detail in the HTML documentation for
-        ntpd(8) in
-        /usr/share/doc/reference/ref8/ntp.

-    
NetBSD currently supports this option
-        in com(4) and zsc(4).

-    
NOTE: Using this option will also enable
-        options NTP.

-  

-  
options SETUIDSCRIPTS

-  
Allows scripts with the setuid bit set to execute as the effective user
-      rather than the real user, just like binary executables.
-    
NOTE: Using this option will also enable
-        options FDSCRIPTS

-  

-  
options FDSCRIPTS

-  
Allows execution of scripts with the execute bit set, but not the read
-      bit, by opening the file and passing the file descriptor to the shell,
-      rather than the filename.
-    
NOTE: Execute only (non-readable) scripts
-        will have argv[0] set to
-        /dev/fd/*. What this option allows as far as
-        security is concerned, is the ability to safely ensure that the correct
-        script is run by the interpreter, as it is passed as an already open
-        file.

-  

-  
options RTC_OFFSET=integer

-  
The kernel (and typically the hardware battery backed-up clock on those
-      machines that have one) keeps time in UTC (Universal
-      Coordinated Time, once known as
-      , or Greenwich
-      Mean Time) and not in the time of the local time zone. The
-      RTC_OFFSET option is used on some ports (such as the
-      i386) to tell the kernel that the hardware clock is offset from
-      UTC by the specified number of minutes. This is
-      typically used when a machine boots several operating systems and one of
-      them wants the hardware clock to run in the local time zone and not in
-      UTC, e.g.
-      
-      means the hardware clock is set to US Eastern Time (300 minutes behind
-      UTC), and not UTC. (Note:
-      RTC_OFFSET is used to initialize a kernel variable named
-      rtc_offset which is the source actually used to
-      determine the clock offset, and which may be accessed via the
-      kern.rtc_offset sysctl variable. See sysctl(8) and
-      sysctl(3) for details. Since the kernel clock is
-      initialized from the hardware clock very early in the boot process, it is
-      not possible to meaningfully change rtc_offset in
-      system initialization scripts. Changing this value currently may only be
-      done at kernel compile time or by patching the kernel and rebooting).
-    
NOTE: Unfortunately, in many cases where the
-        hardware clock is kept in local time, it is adjusted for Daylight
-        Savings Time; this means that attempting to use
-        RTC_OFFSET to let NetBSD
-        coexist with such an operating system, like Windows, would necessitate
-        changing RTC_OFFSET twice a year. As such, this
-        solution is imperfect.

-  

-  
options MAXUPRC=integer

-  
Sets the soft RLIMIT_NPROC resource limit, which
-      specifies the maximum number of simultaneous processes a user is permitted
-      to run, for process 0; this value is inherited by its child processes. It
-      defaults to CHILD_MAX, which is currently defined to be
-      160. Setting
-       to a
-      value less than CHILD_MAX is not permitted, as this
-      would result in a violation of the semantics of IEEE Std
-      1003.1-1990 (“POSIX.1”).

-  
options NOFILE=integer

-  
Sets the soft RLIMIT_NOFILE resource limit, which
-      specifies the maximum number of open file descriptors for each process;
-      this value is inherited by its child processes. It defaults to
-      ,
-      which is currently defined to be 128.

-  
options MAXFILES=integer

-  
Sets the default value of the
-      
-      sysctl variable, which indicates the maximum number of files that may be
-      open in the system.

-  
options
-    DEFCORENAME=string

-  
Sets the default value of the
-      
-      sysctl variable, otherwise it is set to %n.core.
-      See sysctl(8) and sysctl(3) for
-      details.

-  
options RASOPS_CLIPPING

-  
Enables clipping within the rasops raster-console
-      output system. NOTE: only available on architectures
-      that use rasops for console output.

-  
options RASOPS_SMALL

-  
Removes optimized character writing code from the
-      rasops raster-console output system.
-      NOTE: only available on architectures that use
-      rasops for console output.

-  
options INCLUDE_CONFIG_FILE

-  
Embeds the kernel config file used to define the kernel in the kernel
-      binary itself. The embedded data also includes any files directly included
-      by the config file itself, e.g. GENERIC.local or
-      std.$MACHINE. The embedded config file can be
-      extracted from the resulting kernel with config(1)
-      -x, or by the following command:
-    

-    
strings netbsd | sed -n 's/^_CFG_//p' | unvis

-    

-  

-  
options INCLUDE_JUST_CONFIG

-  
Similar to the above option, but includes just the actual config file, not
-      any included files.

-  
options PIPE_SOCKETPAIR

-  
Use slower, but smaller socketpair(2)-based pipe implementation instead of
-      default faster, but bigger one. Primarily useful for installation
-    kernels.

-  
options USERCONF

-  
Compiles in the in-kernel device configuration manager. See
-      userconf(4) for details.

-  
options SCDEBUG_DEFAULT

-  
Used with the options SYSCALL_DEBUG described
-      below to choose which types of events are displayed.
-    

-    

-    

-      

-      
Show system call entry points.

-      

-      
Show system call exit points.

-      

-      
Show all system call requests, including unimplemented calls.

-      

-      
Show the arguments provided.

-      

-      
Store a restricted form of the system call debug in a kernel history
-          instead of printing it to the console. This option relies upon
-          options KERNHIST.

-    

-    

-    
The default value is
-        (SCDEBUG_CALLS|SCDEBUG_RETURNS|SCDEBUG_SHOWARGS).

-  

-  
options SYSCALL_DEBUG

-  
Useful for debugging system call issues, usually in early single user
-      bringup. By default, writes entries to the system console for most system
-      call events. Can be configured with the options
-      SCDEBUG_DEFAULT option to to use the options
-      KERNHIST facility instead.

-  
options SYSCALL_STATS

-  
Count the number of times each system call number is called. The values
-      can be read through the sysctl interface and displayed using
-      systat(1). NOTE: not yet available on
-      all architectures.

-  
options SYSCALL_TIMES

-  
Count the time spent (using
-      ())
-      in each system call. NOTE: Using this option will also
-      enable options SYSCALL_STATS.

-  
options
-    SYSCALL_TIMES_HASCOUNTER

-  
Force use of cpu_counter32() even if
-      ()
-      reports false. Useful for systems where the cycle counter doesn't run at a
-      constant rate (e.g. Soekris boxes).

-  
options XSERVER_DDB

-  
A supplement to XSERVER that adds support for entering
-      ddb(4) while in X11.

-  
options FILEASSOC

-  
Support for fileassoc(9). Required for
-      options PAX_SEGVGUARD and
-      pseudo-device veriexec.

-  
options FILEASSOC_NHOOKS=integer

-  
Number of storage slots per file for fileassoc(9).
-      Default is 4.

-

-

-

-

-

-  
options GATEWAY

-  
Enables IPFORWARDING and (on most ports) increases the
-      size of
-      .
-      In general, GATEWAY is used to indicate that a system
-      should act as a router, and IPFORWARDING is not invoked
-      directly. (Note that GATEWAY has no impact on protocols
-      other than IP). GATEWAY option also compiles IPv4 and
-      IPv6 fast forwarding code into the kernel.

-  
options IPFORWARDING=value

-  
If value is 1 this enables IP routing behavior. If
-      value is 0 (the default), it disables it. The
-      GATEWAY option sets this to 1 automatically. With this
-      option enabled, the machine will forward IP datagrams destined for other
-      machines between its interfaces. Note that even without this option, the
-      kernel will still forward some packets (such as source routed packets)
-      — removing GATEWAY and
-      IPFORWARDING is insufficient to stop all routing through
-      a bastion host on a firewall — source routing is controlled
-      independently. Note that IP forwarding may be turned on and off
-      independently of the setting of the IPFORWARDING option
-      through the use of the net.inet.ip.forwarding sysctl
-      variable. If net.inet.ip.forwarding is 1, IP forwarding
-      is on. See sysctl(8) and sysctl(3) for
-      details.

-  
options IFA_STATS

-  
Tells the kernel to maintain per-address statistics on bytes sent and
-      received over (currently) Internet and AppleTalk addresses. The option is
-      not recommended as it degrades system stability.

-  
options IFQ_MAXLEN=value

-  
Increases the allowed size of the network interface packet queues. The
-      default queue size is 50 packets, and you do not normally need to increase
-      it.

-  
options IPSELSRC

-  
Includes support for source-address selection policies. See
-      in_getifa(9).

-  
options MROUTING

-  
Includes support for IP multicast routers. You certainly want
-      INET with this. Multicast routing is controlled by the
-      mrouted(8) daemon. See also option
-      PIM.

-  
options PIM

-  
Includes support for Protocol Independent Multicast (PIM) routing. You
-      need 
-      and INET with this. Software using this can be found
-      e.g. in pkgsrc/net/xorp.

-  
options INET

-  
Includes support for the TCP/IP protocol stack. You almost certainly want
-      this. See inet(4) for details.

-  
options INET6

-  
Includes support for the IPv6 protocol stack. See
-      inet6(4) for details. Unlike INET,
-       enables
-      multicast routing code as well. This option requires
-      INET at this moment, but it should not.

-  
options ND6_DEBUG

-  
The option sets the default value of net.inet6.icmp6.nd6_debug to 1, for
-      debugging IPv6 neighbor discovery protocol handling. See
-      sysctl(3) for details.

-  
options IPSEC

-  
Includes support for the IPsec protocol, using the implementation derived
-      from OpenBSD, relying on
-      opencrypto(9) to carry out cryptographic operations. See
-      ipsec(4) for details.

-  
options IPSEC_DEBUG

-  
Enables debugging code in IPsec stack. See ipsec(4) for
-      details. The IPSEC option includes support for
-      IPsec Network Address Translator traversal (NAT-T), as described in RFCs
-      3947 and 3948. This feature might be patent-encumbered in some
-    countries.

-  
options ALTQ

-  
Enabled ALTQ (Alternate Queueing). For simple rate-limiting, use
-      tbrconfig(8) to set up the interface transmission rate.
-      To use queueing disciplines, their appropriate kernel options should also
-      be defined (documented below). Queueing disciplines are managed by
-      altqd(8). See altq(9) for
-    details.

-  
options ALTQ_HFSC

-  
Include support for ALTQ-implemented HFSC (Hierarchical Fair Service
-      Curve) module. HFSC supports both link-sharing and guaranteed real-time
-      services. HFSC employs a service curve based QoS model, and its unique
-      feature is an ability to decouple delay and bandwidth allocation. Requires
-      ALTQ_RED to use the RED queueing discipline on HFSC
-      classes, or ALTQ_RIO to use the RIO queueing discipline
-      on HFSC classes. This option assumes ALTQ.

-  
options ALTQ_PRIQ

-  
Include support for ALTQ-implemented PRIQ (Priority Queueing). PRIQ
-      implements a simple priority-based queueing discipline. A higher priority
-      class is always served first. Requires ALTQ_RED to use
-      the RED queueing discipline on HFSC classes, or ALTQ_RIO
-      to use the RIO queueing discipline on HFSC classes. This option assumes
-      ALTQ.

-  
options ALTQ_WFQ

-  
Include support for ALTQ-implemented WFQ (Weighted Fair Queueing). WFQ
-      implements a weighted-round robin scheduler for a set of queues. A weight
-      can be assigned to each queue to give a different proportion of the link
-      capacity. A hash function is used to map a flow to one of a set of queues.
-      This option assumes ALTQ.

-  
options ALTQ_FIFOQ

-  
Include support for ALTQ-implemented FIFO queueing. FIFOQ is a simple
-      drop-tail FIFO (First In, First Out) queueing discipline. This option
-      assumes ALTQ.

-  
options ALTQ_RIO

-  
Include support for ALTQ-implemented RIO (RED with In/Out). The original
-      RIO has 2 sets of RED parameters; one for in-profile packets and the other
-      for out-of-profile packets. At the ingress of the network, profile meters
-      tag packets as IN or OUT based on contracted profiles for customers.
-      Inside the network, IN packets receive preferential treatment by the RIO
-      dropper. ALTQ/RIO has 3 drop precedence levels defined for the Assured
-      Forwarding PHB of DiffServ (RFC 2597). This option assumes
-      ALTQ.

-  
options ALTQ_BLUE

-  
Include support for ALTQ-implemented Blue buffer management. Blue is
-      another active buffer management mechanism. This option assumes
-      ALTQ.

-  
options ALTQ_FLOWVALVE

-  
Include support for ALTQ-implemented Flowvalve. Flowvalve is a simple
-      implementation of a RED penalty box that identifies and punishes
-      misbehaving flows. This option requires ALTQ_RED and
-      assumes ALTQ.

-  
options ALTQ_CDNR

-  
Include support for ALTQ-implemented CDNR (diffserv traffic conditioner)
-      packet marking/manipulation. Traffic conditioners are components to meter,
-      mark, or drop incoming packets according to some rules. As opposed to
-      queueing disciplines, traffic conditioners handle incoming packets at an
-      input interface. This option assumes ALTQ.

-  
options ALTQ_NOPCC

-  
Disables use of processor cycle counter to measure time in ALTQ. This
-      option should be defined for a non-Pentium i386 CPU which does not have
-      TSC, SMP (per-CPU counters are not in sync), or power management which
-      affects processor cycle counter. This option assumes
-      ALTQ.

-  
options ALTQ_IPSEC

-  
Include support for IPsec in IPv4 ALTQ. This option assumes
-      ALTQ.

-  
options ALTQ_JOBS

-  
Include support for ALTQ-implemented JoBS (Joint Buffer Management and
-      Scheduling). This option assumes ALTQ.

-  
options ALTQ_AFMAP

-  
Include support for an undocumented ALTQ feature that is used to map an IP
-      flow to an ATM VC (Virtual Circuit). This option assumes
-      ALTQ.

-  
options ALTQ_LOCALQ

-  
Include support for ALTQ-implemented local queues. Its practical use is
-      undefined. Assumes ALTQ.

-  
options SUBNETSARELOCAL

-  
Sets default value for net.inet.ip.subnetsarelocal variable, which
-      controls whether non-directly-connected subnets of connected networks are
-      considered "local" for purposes of choosing the MSS for a TCP
-      connection. This is mostly present for historic reasons and completely
-      irrelevant if you enable Path MTU discovery.

-  
options HOSTZEROBROADCAST

-  
Sets default value for net.inet.ip.hostzerobroadcast variable, which
-      controls whether the zeroth host address of each connected subnet is also
-      considered a broadcast address. Default value is "1", for
-      compatibility with old systems; if this is set to zero on all hosts on a
-      subnet, you should be able to fit an extra host per subnet on the
-      ".0" address.

-  
options MCLSHIFT=value

-  
This option is the base-2 logarithm of the size of mbuf clusters. The
-      BSD networking stack keeps network packets in a
-      linked list, or chain, of kernel buffer objects called mbufs. The system
-      provides larger mbuf clusters as an optimization for large packets,
-      instead of using long chains for large packets. The mbuf cluster size, or
-      , must
-      be a power of two, and is computed as two raised to the power
-      MCLSHIFT. On systems with Ethernet network adapters,
-      MCLSHIFT is often set to 11, giving 2048-byte mbuf
-      clusters, large enough to hold a 1500-byte Ethernet frame in a single
-      cluster. Systems with network interfaces supporting larger frame sizes
-      like ATM, FDDI, or HIPPI may perform better with
-      MCLSHIFT set to 12 or 13, giving mbuf cluster sizes of
-      4096 and 8192 bytes, respectively.

-  
options NETATALK

-  
Include support for the AppleTalk protocol stack. The kernel provides
-      provision for the
-       (DDP), providing SOCK_DGRAM support and AppleTalk
-      routing. This stack is used by the
-      
-      package, which adds support for AppleTalk server services via user
-      libraries and applications.

-  
options BLUETOOTH

-  
Include support for the Bluetooth protocol stack. See
-      bluetooth(4) for details.

-  
options IPNOPRIVPORTS

-  
Normally, only root can bind a socket descriptor to a so-called
-      “privileged” TCP port, that is, a port number in the range
-      0-1023. This option eliminates those checks from the kernel. This can be
-      useful if there is a desire to allow daemons without privileges to bind
-      those ports, e.g., on firewalls. The security tradeoffs in doing this are
-      subtle. This option should only be used by experts.

-  
options TCP_DEBUG

-  
Record the last
-      
-      TCP packets with SO_DEBUG set, and decode to the console if
-      
-      is set.

-  
options TCP_NDEBUG

-  
Number of packets to record for
-      .
-      Defaults to 100.

-  
options TCP_SENDSPACE=value

-  

-  
options TCP_RECVSPACE=value

-  
These options set the max TCP window size to other sizes than the default.
-      The TCP window sizes can be altered via sysctl(8) as
-      well.

-  
options TCP_INIT_WIN=value

-  
This option sets the initial TCP window size for non-local connections,
-      which is used when the transmission starts. The default size is 1, but if
-      the machine should act more aggressively, the initial size can be set to
-      some other value. The initial TCP window size can be set via
-      sysctl(8) as well.

-  
options TCP_SIGNATURE

-  
Enable MD5 TCP signatures (RFC 2385) to protect BGP sessions.

-  
options IPFILTER_LOG

-  
This option, in conjunction with pseudo-device ipfilter,
-      enables logging of IP packets using IP-Filter.

-  
options IPFILTER_LOOKUP

-  
This option enables the IP-Filter ippool(8)
-      functionality to be enabled.

-  
options IPFILTER_COMPAT

-  
This option enables older IP-Filter binaries to work.

-  
options IPFILTER_DEFAULT_BLOCK

-  
This option sets the default policy of IP-Filter. If it is set, IP-Filter
-      will block packets by default.

-  
options MBUFTRACE

-  
This option can help track down mbuf leaks. When enabled, mbufs are tagged
-      with the devices and protocols using them. This can significantly decrease
-      network performance, particularly on MP systems. This additional
-      information can be viewed with netstat(1):
-    
netstat
-      -mssv

-    Not all devices or protocols support this option.

-

-

-

-
-

-  
options SYSCTL_DISALLOW_CREATE

-  
Disallows the creation or deletion of nodes from the sysctl tree, as well
-      as the assigning of descriptions to nodes that lack them, by any process.
-      These operations are still available to kernel sub-systems, including
-      loadable kernel modules.

-  
options SYSCTL_DISALLOW_KWRITE

-  
Prevents processes from adding nodes to the sysctl tree that make existing
-      kernel memory areas writable. Sections of kernel memory can still be read
-      and new nodes that own their own data may still be writable.

-  
options SYSCTL_DEBUG_SETUP

-  
Causes the SYSCTL_SETUP routines to print a brief message when they are
-      invoked. This is merely meant as an aid in determining the order in which
-      sections of the tree are created.

-  
options
-    SYSCTL_DEBUG_CREATE

-  
Prints a message each time
-      (),
-      the function that adds nodes to the tree, is called.

-  
options SYSCTL_INCLUDE_DESCR

-  
Causes the kernel to include short, human readable descriptions for nodes
-      in the sysctl tree. The descriptions can be retrieved programmatically
-      (see sysctl(3)), or by the sysctl binary itself (see
-      sysctl(8)). The descriptions are meant to give an
-      indication of the purpose and/or effects of a given node's value, not
-      replace the documentation for the given subsystem as a whole.

-

-

-

-

-

-  
options SYSVMSG

-  
Includes support for AT&T System V UNIX
-      style message queues. See msgctl(2),
-      msgget(2), msgrcv(2),
-      msgsnd(2).

-  
options SYSVSEM

-  
Includes support for AT&T System V UNIX
-      style semaphores. See semctl(2),
-      semget(2), semop(2).

-  
options SEMMNI=value

-  
Sets the number of AT&T System V UNIX
-      style semaphore identifiers. The GENERIC config file for your port will
-      have the default.

-  
options SEMMNS=value

-  
Sets the number of AT&T System V UNIX
-      style semaphores in the system. The GENERIC config file for your port will
-      have the default.

-  
options SEMUME=value

-  
Sets the maximum number of undo entries per process for
-      AT&T System V UNIX style semaphores.
-      The GENERIC config file for your port will have the default.

-  
options SEMMNU=value

-  
Sets the number of undo structures in the system for
-      AT&T System V UNIX style semaphores.
-      The GENERIC config file for your port will have the default.

-  
options SYSVSHM

-  
Includes support for AT&T System V UNIX
-      style shared memory. See shmat(2),
-      shmctl(2), shmdt(2),
-      shmget(2).

-  
options SHMMAXPGS=value

-  
Sets the maximum number of AT&T System V
-      UNIX style shared memory pages that are available through the
-      shmget(2) system call. Default value is 1024 on most
-      ports. See /usr/include/machine/vmparam.h for the
-      default.

-

-

-

-
-

-  
options NMBCLUSTERS=value

-  
The number of mbuf clusters the kernel supports. Mbuf clusters are
-      MCLBYTES in size (usually 2k). The default value is calculated from the
-      amount of physical memory. Architectures without direct mapping also limit
-      it based on the kmem_map size, which is used as backing store. Some archs
-      limit the value with ‘NMBCLUSTERS_MAX’. See
-      /usr/include/machine/param.h for those archs. This
-      value can be accessed via the kern.mbuf.nmbclusters sysctl variable.
-      Increase this value if you get “mclpool limit reached”
-      messages.

-  
options NMBCLUSTERS_MAX=value

-  
The upper limit of NMBCLUSTERS.

-  
options NKMEMPAGES=value

-  

-  
options NKMEMPAGES_MIN=value

-  

-  
options NKMEMPAGES_MAX=value

-  
Size of kernel VM map
-      , in
-      PAGE_SIZE-sized chunks (the VM page size; this value may be read from the
-      sysctl(8) variable
-      
-      ). This VM map is used to map the kernel malloc arena. The kernel attempts
-      to auto-size this map based on the amount of physical memory in the
-      system. Platform-specific code may place bounds on this computed size,
-      which may be viewed with the sysctl(8) variable
-      .
-      See /usr/include/machine/param.h for the default
-      upper and lower bounds. The related options ‘NKMEMPAGES_MIN’
-      and ‘NKMEMPAGES_MAX’ allow the bounds to be overridden in
-      the kernel configuration file. These options are provided in the event the
-      computed value is insufficient resulting in an “out of space in
-      kmem_map” panic.

-  
options SB_MAX=value

-  
Sets the max size in bytes that a socket buffer is allowed to occupy. The
-      default is 256k, but sometimes it needs to be increased, for example when
-      using large TCP windows. This option can be changed via
-      sysctl(8) as well.

-  
options SOMAXKVA=value

-  
Sets the maximum size of kernel virtual memory that the socket buffers are
-      allowed to use. The default is 16MB, but in situations where for example
-      large TCP windows are used this value must also be increased. This option
-      can be changed via sysctl(8) as well.

-  
options BUFCACHE=value

-  
Size of the buffer cache as a percentage of total available RAM. Ignored
-      if BUFPAGES is also specified.

-  
options NBUF=value

-  
Sets the number of buffer headers available, i.e., the number of open
-      files that may have a buffer cache entry. Each buffer header requires
-      MAXBSIZE (machine dependent, but usually 65536) bytes. The default value
-      is machine dependent, but is usually equal to the value of BUFPAGES.

-  
options BUFPAGES=value

-  
These options set the number of pages available for the buffer cache.
-      Their default value is a machine dependent value, often calculated as
-      between 5% and 10% of total available RAM.

-  
options MAXTSIZ=bytes

-  
Sets the maximum size limit of a process' text segment. See
-      /usr/include/machine/vmparam.h for the
-      port-specific default.

-  
options DFLDSIZ=bytes

-  
Sets the default size limit of a process' data segment, the value that
-      will be returned as the soft limit for RLIMIT_DATA
-      (as returned by getrlimit(2)). See
-      /usr/include/machine/vmparam.h for the
-      port-specific default.

-  
options MAXDSIZ=bytes

-  
Sets the maximum size limit of a process' data segment, the value that
-      will be returned as the hard limit for RLIMIT_DATA
-      (as returned by getrlimit(2)). See
-      /usr/include/machine/vmparam.h for the
-      port-specific default.

-  
options DFLSSIZ=bytes

-  
Sets the default size limit of a process' stack segment, the value that
-      will be returned as the soft limit for
-      RLIMIT_STACK (as returned by
-      getrlimit(2)). See
-      /usr/include/machine/vmparam.h for the
-      port-specific default.

-  
options MAXSSIZ=bytes

-  
Sets the maximum size limit of a process' stack segment, the value that
-      will be returned as the hard limit for
-      RLIMIT_STACK (as returned by
-      getrlimit(2)). See
-      /usr/include/machine/vmparam.h for the
-      port-specific default.

-  
options
-    DUMP_ON_PANIC=integer

-  
Defaults to one. If set to zero, the kernel will not dump to the dump
-      device when it panics, though dumps can still be forced via
-      ddb(4) with the “sync” command. Note that
-      this sets the value of the
-      
-      sysctl(3) variable which may be changed at run time
-      — see sysctl(8) for details.

-  
options VMSWAP

-  
Enable paging device/file support. This option is on by default.

-  
options
-    VMSWAP_DEFAULT_PLAINTEXT

-  
Store swap in plaintext, not encrypted, which may expose secrets if the
-      underlying nonvolatile medium is disclosed. This option is off by default;
-      it is available only for extremely slow machines where the performance
-      impact of swapping early at boot outweighs the security risks. Swap
-      encryption can still be turned on dynamically with the
-      
-      sysctl(7) knob.

-  
options PDPOLICY_CLOCKPRO

-  
Use CLOCK-Pro, an alternative page replace policy.

-

-

-

-

-

-  
options INSECURE

-  
Initializes the kernel security level with -1 instead of 0. This means
-      that the system always starts in secure level -1 mode, even when running
-      multiuser, unless the securelevel variable is set to value > -1 in
-      /etc/rc.conf. In this case the kernel security
-      level will be raised to that value when the
-      /etc/rc.d/securelevel script is run during system
-      startup. See the manual page for init(8) for details on
-      the implications of this. The kernel secure level may manipulated by the
-      superuser by altering the
-      
-      sysctl(3) variable (the secure level may only be lowered
-      by a call from process ID 1, i.e., init(8)). See also
-      secmodel_securelevel(9), sysctl(8) and
-      sysctl(3).

-  
options VERIFIED_EXEC_FP_SHA256

-  
Enables support for SHA256 hashes in Veriexec.

-  
options VERIFIED_EXEC_FP_SHA384

-  
Enables support for SHA384 hashes in Veriexec.

-  
options VERIFIED_EXEC_FP_SHA512

-  
Enables support for SHA512 hashes in Veriexec.

-  
options PAX_MPROTECT=value

-  
Enables PaX MPROTECT, mprotect(2) restrictions from the
-      PaX project.
-    
The value is the default value for the
-        global knob, see sysctl(3). If 0,
-        PaX MPROTECT will be enabled only if explicitly set on programs using
-        paxctl(8). If 1, PaX MPROTECT will be enabled for all
-        programs. Programs can be exempted using
-      paxctl(8).

-    
See security(7) for more details.

-  

-  
options PAX_SEGVGUARD=value

-  
Enables PaX Segvguard. Requires options FILEASSOC.
-    
The value is the default value for the
-        global knob, see sysctl(3). If 0,
-        PaX Segvguard will be enabled only if explicitly set on programs using
-        paxctl(8). If 1, PaX Segvguard will be enabled to all
-        programs, and exemption can be done using
-      paxctl(8).

-    
See security(7) for more details.

-  

-  
options PAX_ASLR=value

-  
Enables PaX ASLR.
-    
The value is the default value for the
-        global knob, see sysctl(3). If 0,
-        PaX ASLR will be enabled only if explicitly set on programs using
-        paxctl(8). If 1, PaX ASLR will be enabled to all
-        programs, and exemption can be done using
-      paxctl(8).

-    
See security(7) for more details.

-  

-  
options USER_VA0_DISABLE_DEFAULT=value

-  
Sets the initial value of the flag which controls whether user programs
-      can map virtual address 0. The flag can be changed at runtime by
-      sysctl(3).

-  
options KASAN

-  
Enables Kernel Address Sanitizer. NOTE: not available on
-      all architectures.

-  
options KASLR

-  
Enables Kernel ASLR. This randomizes the location of the kernel image in
-      memory. NOTE: not available on all architectures.

-  
options SVS

-  
Enables Separate Virtual Space. On architectures that are designed to
-      function with a shared address space, this option explicitly isolates the
-      kernel and user spaces. NOTE: not available on all
-      architectures.

-

-

-

-

-

-  
options BB060STUPIDROM

-  
When the bootloader (which passes AmigaOS ROM information) claims we have
-      a 68060 CPU without FPU, go look into the Processor Configuration Register
-      (PCR) to find out. You need this with Amiga ROMs up to (at least) V40.xxx
-      (OS3.1), when you boot via the bootblocks and don't have a DraCo.

-  
options IOBZCLOCK=frequency

-  
The IOBlix boards come with two different serial master clocks: older ones
-      use 24 MHz, newer ones use 22.1184 MHz. The driver normally assumes the
-      latter. If your board uses 24 MHz, you can recompile your kernel with
-      options IOBZCLOCK=24000000 or patch the kernel variable iobzclock to the
-      same value.

-  
options LIMITMEM=value

-  
If there, limit the part of the first memory bank used by
-      NetBSD to value megabytes. Default is
-    unlimited.

-  
options P5PPC68KBOARD

-  
Add special support for Phase5 mixed 68k+PPC boards. Currently, this only
-      affects rebooting from NetBSD and is only needed
-      on 68040+PPC, not on 68060+PPC; without this, affected machines will hang
-      after NetBSD has shut down and will only restart
-      after a keyboard reset or a power cycle.

-

-

-

-

-

-  
options DISKLABEL_AHDI

-  
Include support for AHDI (native Atari) disklabels.

-  
options DISKLABEL_NBDA

-  
Include support for NetBSD/atari labels. If you
-      don't set this option, it will be set automatically.
-      NetBSD/atari will not work without it.

-  
options FALCON_SCSI

-  
Include support for the 5380-SCSI configuration as found on the
-    Falcon.

-  
options RELOC_KERNEL

-  
If set, the kernel will relocate itself to TT-RAM, if possible. This will
-      give you a slightly faster system.
-       that on
-      some TT030 systems, the system will frequently dump with MMU-faults with
-      this option enabled.

-  
options SERCONSOLE

-  
Allow the modem1-port to act as the system-console. A carrier should be
-      active on modem1 during system boot to active the console
-    functionality.

-  
options TT_SCSI

-  
Include support for the 5380-SCSI configuration as found on the TT030 and
-      Hades.

-

-

-

-

-

-  
options CPURESET_DELAY=value

-  
Specifies the time (in millisecond) to wait before doing a hardware reset
-      in the last phase of a reboot. This gives the user a chance to see error
-      messages from the shutdown operations (like NFS unmounts, buffer cache
-      flush, etc ...). Setting this to 0 will disable the delay. Default is 2
-      seconds.

-  
options USER_LDT

-  
Include i386-specific system calls for modifying the local descriptor
-      table, used by Windows emulators.

-  
options PAE

-  
Enable PAE (Physical Address Extension) mode. PAE permits up to 36 bits
-      physical addressing (64GB of physical memory), and turns physical
-      addresses to 64 bits entities in the memory management subsystem. Userland
-      virtual address space remains at 32 bits (4GB). PAE mode is required to
-      enable the NX/XD (No-eXecute/eXecute Disable) bit for pages, which allows
-      marking certain ones as not being executable. Any attempt to execute code
-      from such a page will raise an exception.

-  
options REALBASEMEM=integer

-  
Overrides the base memory size passed in from the boot block. (Value given
-      in kilobytes.) Use this option only if the boot block reports the size
-      incorrectly. (Note that some BIOSes put the extended BIOS data area at the
-      top of base memory, and therefore report a smaller base memory size to
-      prevent programs overwriting it. This is correct behavior, and you should
-      not use the
-      
-      option to access this memory).

-  
options SPECTRE_V2_GCC_MITIGATION=1

-  
Enable GCC-specific Spectre variant 2 mitigations. For 32-bit kernels this
-      means these options:
-    

-    
-mindirect-branch=thunk -mindirect-branch-register

-    

-    
For 64-bit kernels this means these options:

-    

-    
-mindirect-branch=thunk-inline -mindirect-branch-register

-    

-  

-  
options REALEXTMEM=integer

-  
Overrides the extended memory size passed in from the boot block. (Value
-      given in kilobytes. Extended memory does not include the first megabyte.)
-      Use this option only if the boot block reports the size incorrectly.

-  
options CYRIX_CACHE_WORKS

-  
Relevant only to the Cyrix 486DLC CPU. This option is used to turn on the
-      cache in hold-flush mode. It is not turned on by default because it is
-      known to have problems in certain motherboard implementations.

-  
options
-    CYRIX_CACHE_REALLY_WORKS

-  
Relevant only to the Cyrix 486DLC CPU. This option is used to turn on the
-      cache in write-back mode. It is not turned on by default because it is
-      known to have problems in certain motherboard implementations. In order
-      for this option to take effect, option
-      
-      must also be specified.

-  
options PCIBIOS

-  
Enable support for initializing the PCI bus using information from the
-      BIOS. See pcibios(4) for details.

-  
options MTRR

-  
Include support for accessing MTRR registers from user-space. See
-      i386_get_mtrr(2).

-  
options BEEP_ONHALT

-  
Make the system speaker emit several beeps when it is completely safe to
-      power down the computer after a halt(8) command.
-      Requires sysbeep(4) support.

-  
options BEEP_ONHALT_COUNT=times

-  
Number of times to beep the speaker when options
-      BEEP_ONHALT is enabled. Defaults to 3.

-  
options BEEP_ONHALT_PITCH=hz

-  
The tone frequency used when options BEEP_ONHALT
-      option, in hertz. Defaults to 1500.

-  
options BEEP_ONHALT_PERIOD=msecs

-  
The duration of each beep when options BEEP_ONHALT
-      is enabled, in milliseconds. Defaults to 250.

-  
options MULTIBOOT

-  
Makes the kernel Multiboot-compliant, allowing it to be booted through a
-      Multiboot-compliant boot manager such as GRUB. See
-      multiboot(8) for more information.

-  
options SPLASHSCREEN

-  
Display a splash screen during boot.

-

-

-

-

-
Options specific to isa(4) busses.

-

-  
options PCIC_ISA_ALLOC_IOBASE=address,
-    PCIC_ISA_ALLOC_IOSIZE=size

-  
Control the section of IO bus space used for PCMCIA bus space mapping.
-      Ideally the probed defaults are satisfactory, however in practice that is
-      not always the case. See pcmcia(4) for details.

-  
options PCIC_ISA_INTR_ALLOC_MASK=mask

-  
Controls the allowable interrupts that may be used for PCMCIA devices.
-      This mask is a logical-or of power-of-2s of allowable interrupts:
-    

-    

- 0  0x0001    4  0x0010    8  0x0100    12  0x1000
- 1  0x0002    5  0x0020    9  0x0200    13  0x2000
- 2  0x0004    6  0x0040   10  0x0400    14  0x4000
- 3  0x0008    7  0x0080   11  0x0800    15  0x8000

-    

-  

-  
options PCKBC_CNATTACH_SELFTEST

-  
Perform a self test of the keyboard controller before attaching it as a
-      console. This might be necessary on machines where we boot on cold iron,
-      and pckbc refuses to talk until we request a self test. Currently only the
-      netwinder port uses it.

-  
options PCKBD_CNATTACH_MAY_FAIL

-  
If this option is set the PS/2 keyboard will not be used as the console if
-      it cannot be found during boot. This allows other keyboards, like USB, to
-      be the console keyboard.

-  
options PCKBD_LAYOUT=layout

-  
Sets the default keyboard layout, see pckbd(4).

-

-

-

-

-

-  
options FPU_EMULATE

-  
Include support for MC68881/MC68882 emulator.

-  
options FPSP

-  
Include support for 68040 floating point.

-  
options M68020,M68030,M68040,M68060

-  
Include support for a specific CPU, at least one (the one you are using)
-      should be specified.

-  
options M060SP

-  
Include software support for 68060. This provides emulation of
-      unimplemented integer instructions as well as emulation of unimplemented
-      floating point instructions and data types and software support for
-      floating point traps.

-

-

-

-

-

-  
options PMAP_MEMLIMIT=value

-  
Limit the amount of memory seen by the kernel to
-      value bytes.

-  
options PTEGCOUNT=value

-  
Specify the size of the page table as value PTE
-      groups. Normally, one PTEG is allocated per physical page frame.

-

-

-

-

-

-  
options AUDIO_DEBUG

-  
Enable simple event debugging of the logging of the
-      audio(4) device.

-  
options BLINK

-  
Enable blinking of LED. Blink rate is full cycle every N seconds for N
-      < then current load average. See getloadavg(3).

-  
options COUNT_SW_LEFTOVERS

-  
Count how many times the sw SCSI device has left 3, 2, 1 and 0 in the
-      sw_3_leftover, sw_2_leftover, sw_1_leftover, and sw_0_leftover variables
-      accessible from ddb(4). See
-    sw(4).

-  
options DEBUG_ALIGN

-  
Adds debugging messages calls when user-requested alignment fault handling
-      happens.

-  
options DEBUG_EMUL

-  
Adds debugging messages calls for emulated floating point and alignment
-      fixing operations.

-  
options EXTREME_DEBUG

-  
Adds debugging functions callable from ddb(4). The
-      debug_pagetables, test_region and print_fe_map functions print information
-      about page tables for the SUN4M platforms only.

-  
options EXTREME_EXTREME_DEBUG

-  
Adds extra info to options EXTREME_DEBUG.

-  
options FPU_CONTEXT

-  
Make options COMPAT_SVR4 getcontext and setcontext
-      include floating point registers.

-  
options MAGMA_DEBUG

-  
Adds debugging messages to the magma(4) device.

-  
options RASTERCONS_FULLSCREEN

-  
Use the entire screen for the console.

-  
options RASTERCONS_SMALLFONT

-  
Use the Fixed font on the console, instead of the normal font.

-  
options SUN4

-  
Support sun4 class machines.

-  
options SUN4C

-  
Support sun4c class machines.

-  
options SUN4M

-  
Support sun4m class machines.

-  
options SUN4_MMU3L

-  
Enable support for sun4 3-level MMU machines.

-  
options V9

-  
Enable SPARC V9 assembler in ddb(4).

-

-

-

-

-

-  
options AUDIO_DEBUG

-  
Enable simple event debugging of the logging of the
-      audio(4) device.

-  
options BLINK

-  
Enable blinking of LED. Blink rate is full cycle every N seconds for N
-      < then current load average. See getloadavg(3).

-

-

-

-

-

-  
options EXTENDED_MEMORY

-  
Include support for extended memory, e.g., TS-6BE16 and 060turbo
-    on-board.

-  
options JUPITER

-  
Include support for Jupiter-X MPU accelerator

-  
options ZSCONSOLE,ZSCN_SPEED=value

-  
Use the built-in serial port as the system-console. Speed is specified in
-      bps, defaults to 9600.

-  
options ITE_KERNEL_ATTR=value

-  
Set the kernel message attribute for ITE. Value, an integer, is a logical
-      or of the following values:
-    

-    

-      
1

-      
color inversed

-      
2

-      
underlined

-      
4

-      
bolded

-    

-    

-  

-

-

-

-

-

-  
options NO_PCI_MSI_MSIX

-  
Disable support for MSI/MSIX in the kernel. See
-      pci_msi(9) for details of MSI/MSIX support

-  
options NO_PREEMPTION

-  
Disables kpreempt(9) support in the kernel.

-

-

-

-

-

-
config(1), gcc(1),
-    gdb(1), ktrace(1),
-    quota(1), vndcompress(1),
-    gettimeofday(2), i386_get_mtrr(2),
-    i386_iopl(2), msgctl(2),
-    msgget(2), msgrcv(2),
-    msgsnd(2), ntp_adjtime(2),
-    ntp_gettime(2), reboot(2),
-    semctl(2), semget(2),
-    semop(2), shmat(2),
-    shmctl(2), shmdt(2),
-    shmget(2), sysctl(3),
-    apm(4), ddb(4),
-    inet(4), md(4),
-    pcibios(4), pcmcia(4),
-    ppp(4), userconf(4),
-    vnd(4), wscons(4),
-    config(5), edquota(8),
-    init(8), mdsetimage(8),
-    mount_cd9660(8), mount_fdesc(8),
-    mount_kernfs(8), mount_lfs(8),
-    mount_mfs(8), mount_msdos(8),
-    mount_nfs(8), mount_ntfs(8),
-    mount_null(8), mount_portal(8),
-    mount_procfs(8), mount_udf(8),
-    mount_umap(8), mount_union(8),
-    mrouted(8), newfs_lfs(8),
-    ntpd(8), quotaon(8),
-    rpc.rquotad(8), sysctl(8),
-    cnmagic(9), in_getifa(9),
-    kernhist(9)

-

-

-

-
The options man page first appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
December 12, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/osiop.4 4.html b/static/netbsd/man4/osiop.4 4.html
deleted file mode 100644
index 1651db50..00000000
--- a/static/netbsd/man4/osiop.4 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
OSIOP(4)Device Drivers ManualOSIOP(4)

-

-

-

-
osiop —
-    Symbios/NCR 53C710 SCSI driver

-

-

-

-

-

-
osiop* at jazzio? flags 0x00000

-

-

-

-
osiop* at sbdio? flags 0x00000

-

-

-

-
osiop0 at gsc? flags 0x00000

-

-

-

-
osiop0 at pcctwo? ipl 2

-

-  

-  scsibus* at osiop?

-

-

-

-

-
The osiop driver provides support for the
-    Symbios/NCR 53C710 SCSI controller chip.

-
For the Symbios/NCR 53C700 SCSI host adapters, use the
-    oosiop(4) driver.

-
For the Symbios/NCR 53C8xx PCI SCSI host adapters, use the
-    siop(4) or esiop(4) driver.

-

-

-

-
The osiop driver supports the following
-    
-    for use in config(1) files:

-

-

-  
bits 0-7:

-  
disable disconnect/reselect for the corresponding SCSI target

-  
bits 8-15:

-  
disable synchronous negotiation for SCSI target

-  
bits 16:

-  
disable DMA interrupts

-

-
"Target" is synonymous with SCSI ID number.

-
Note that SCSI tape drives should be allowed to perform
-    disconnect/reselect or performance will suffer.

-

-

-

-
cd(4), ch(4),
-    esiop(4), intro(4),
-    oosiop(4), scsi(4),
-    sd(4), siop(4), ss(4),
-    st(4), uk(4),
-    scsipi(9)

-

-

-

-
osiop driver first appeared in
-    NetBSD 1.6.

-
The original NCR 53C710 driver appeared in
-    NetBSD 1.0 amiga port, and Izumi Tsutsui
-    ⟨tsutsui@NetBSD.org⟩ modified the driver and made it
-    machine-independent.

-

-

-
-  
-    
-    
-  
-
May 12, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/otus.4 3.html b/static/netbsd/man4/otus.4 3.html
deleted file mode 100644
index ca566b81..00000000
--- a/static/netbsd/man4/otus.4 3.html	
+++ /dev/null
@@ -1,175 +0,0 @@
-
-  
-    
-    
-    
-  
-
OTUS(4)Device Drivers ManualOTUS(4)

-

-

-

-
otus — Atheros USB
-    IEEE 802.11a/g/n wireless network device

-

-

-

-
otus* at uhub? port ?

-

-

-

-
The otus driver supports USB 2.0 wireless
-    network devices based on Atheros Communications AR9001U chipset.

-
The AR9001U chipset is made of an AR9170 MAC/Baseband and an
-    AR9101 (1T2R), AR9102 (2T2R) or AR9104 (dual-band 2T2R) Radio.

-
These are the modes the otus driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The otus driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it.

-
The otus driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5).

-

-

-

-
The driver needs at least version 1.0 of the following firmware
-    files, which are loaded when an interface is attached:

-

-

-

-  
/libdata/firmware/if_otus/otus-init

-  
 

-  
/libdata/firmware/if_otus/otus-main

-  
 

-

-

-
Although these firmware files are freely redistributable, their
-    usage is restricted.

-

-

-

-
The following adapters should work:

-

-

-

-  
Arcadyan WN7512

-  
 

-  
CACE AirPcap Nx

-  
 

-  
D-Link DWA-130 rev D1

-  
 

-  
D-Link DWA-160 rev A1

-  
 

-  
D-Link DWA-160 rev A2

-  
 

-  
IO-Data WN-GDN/US2

-  
 

-  
NEC Aterm WL300NU-G

-  
 

-  
Netgear WNDA3100

-  
 

-  
Netgear WN111 v2

-  
 

-  
Planex GW-US300

-  
 

-  
SMC SMCWUSB-N2

-  
 

-  
TP-Link TL-WN821N

-  
 

-  
Ubiquiti SR71 USB

-  
 

-  
Unex DNUA-81

-  
 

-  
Z-Com UB81

-  
 

-  
Z-Com UB82

-  
 

-  
ZyXEL NWD-271N

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    otus0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
nwkey 0x1deadbeef1 chan 11
-dhcp

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig otus0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-
To use WPA, see wpa_supplicant(8) and
-    wpa_supplicant.conf(5).

-

-

-

-

-  
otus%d: error %d, could not read firmware %s

-  
For some reason, the driver was unable to read the microcode file from the
-      filesystem. The file might be missing or corrupted.

-  
otus%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), usb(4),
-    wpa_supplicant.conf(5), ifconfig(8),
-    wpa_supplicant(8)

-

-

-

-
The otus driver first appeared in
-    OpenBSD 4.6. It was ported to
-    NetBSD by Anon Ymous and first appeared in
-    NetBSD 6.0.

-

-

-

-
The otus driver was written by
-    Damien Bergamini
-    <damien@openbsd.org>
-    based on source code licensed under the ISC released in 2008 by Atheros
-    Communications for Linux.

-

-

-

-
The AVM FRITZ!WLAN USB Stick N adapter is currently not
-  supported.

-
The otus driver does not support any of
-    the 802.11n capabilities offered by the AR9001U chipset. Additional work is
-    required in ieee80211(9) before those features can be
-    supported.

-
The otus driver also does not currently
-    support EDCA as this is missing in the NetBSD
-    network stack. The hooks for it are in the driver code.

-

-

-
-  
-    
-    
-  
-
November 4, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/owtemp.4 4.html b/static/netbsd/man4/owtemp.4 4.html
deleted file mode 100644
index d134b644..00000000
--- a/static/netbsd/man4/owtemp.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
OWTEMP(4)Device Drivers ManualOWTEMP(4)

-

-

-

-
owtemp — 1-Wire
-    temperature family type device

-

-

-

-
owtemp* at onewire?

-

-

-

-
The owtemp driver provides support for the
-    1-Wire temperature sensor. The sensor possesses a single temperature value
-    that can be accessed through the envsys(4) interface.

-
The following chips are supported by the driver:

-

-
    
-  
  • Maxim/Dallas DS18B20, DS1822, DS1920
    • 
-

-

-

-

-
envsys(4), intro(4),
-    onewire(4), envstat(8)

-

-

-

-
The owtemp driver first appeared in
-    OpenBSD 4.0 and NetBSD
-  4.0.

-

-

-

-
The owtemp driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>
-    and was ported to NetBSD by Jeff
-    Rizzo
-    <riz@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 4, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/pad.4 4.html b/static/netbsd/man4/pad.4 4.html
deleted file mode 100644
index 173c29e0..00000000
--- a/static/netbsd/man4/pad.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
PAD(4)Device Drivers ManualPAD(4)

-

-

-

-
pad — Pseudo audio
-    device driver

-

-

-

-
pseudo-device pad
-  

-  audio* at audiobus?

-

-

-

-
pad is a pseudo-device driver which
-    provides support for feeding back PCM data from consumers of an
-    audio(4) device to userland.

-
The raw PCM data readable from /dev/padN
-    is encoded in stereo little-endian 16-bit linear PCM at 44100 Hz.

-

-

-

-
The pad pseudo-device driver receives data
-    from /dev/audioN and feeds the raw PCM output to
-    /dev/padN. /dev/audioN is
-    created once /dev/padN is opened.

-
    
-  
  • /dev/audioN
    • 
-  
  • /dev/padN
    • 
-

-

-

-

-
The following example streams an MP3 to an Apple AirTunes
-    compatible device:

-

-
$ rtunes - < /dev/pad0 &
-$ mpg123 -a /dev/audio1 mozart.mp3

-

-
Record the output of an application (in this case, audioplay):

-

-
$ ffmpeg -f s16le -ar 44100 -ac 2 -i /dev/pad0 output.wav
-$ audioplay -d /dev/audio1 input.wav

-

-

-

-

-
audio(4)

-

-

-

-
The pad driver appeared in
-    NetBSD 5.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-
-  
-    
-    
-  
-
February 6, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/pas.4 4.html b/static/netbsd/man4/pas.4 4.html
deleted file mode 100644
index d6d5dcc7..00000000
--- a/static/netbsd/man4/pas.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
PAS(4)Device Drivers ManualPAS(4)

-

-

-

-
pas — ProAudio
-    Spectrum audio device driver

-

-

-

-
pas0 at isa? port 0x220 irq 7 drq 1
-  

-  audio* at audiobus?

-

-

-

-
The pas driver provides support for
-    ProAudio Spectrum sound cards.

-

-

-

-
audio(4), isa(4)

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/pcdisplay.4 4.html b/static/netbsd/man4/pcdisplay.4 4.html
deleted file mode 100644
index 67e733ab..00000000
--- a/static/netbsd/man4/pcdisplay.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCDISPLAY(4)Device Drivers ManualPCDISPLAY(4)

-

-

-

-
pcdisplay — PC
-    display adapter driver for wscons

-

-

-

-
options PCDISPLAY_SOFTCURSOR

-

-  

-  pcdisplay0 at isa?
-  

-  wsdisplay* at pcdisplay? console ?

-

-

-

-
This driver supports PC display adapter hardware within the
-    wscons(4) console framework. It doesn't provide direct
-    device driver entry points but makes its functions available via the
-    internal wsdisplay(4) interface.

-
The pcdisplay driver is intended as a
-    minimal “catch-all” driver for the different kinds of MDA or
-    CGA compatible adapters. It doesn't support multiple screens, nor colors or
-    font loading.

-
Supported kernel option(s):

-

-  
options PCDISPLAY_SOFTCURSOR

-  
Use a large, non-blinking cursor generated by software. The default is to
-      use the cursor provided by the underlying display hardware.

-

-

-

-

-
isa(4), vga(4),
-    wscons(4)

-

-

-
-  
-    
-    
-  
-
March 20, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/pcf8563rtc.4 4.html b/static/netbsd/man4/pcf8563rtc.4 4.html
deleted file mode 100644
index f3725108..00000000
--- a/static/netbsd/man4/pcf8563rtc.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCF8563RTC(4)Device Drivers ManualPCF8563RTC(4)

-

-

-

-
pcf8563rtc — NXP
-    PCF8563 real-time clock

-

-

-

-
pcf8563rtc* at iic? addr 0x51

-

-

-

-
The pcf8563rtc driver provides support for
-    the NXP PCF8563 real-time clock chip.

-
Access methods to retrieve and set date and time are
-    provided through the
-     interface
-    defined in todr(9).

-

-

-

-
iic(4), todr(9)

-

-

-

-
The pcf8563rtc device appeared in
-    NetBSD 6.0.

-

-

-

-
The driver does not support the chip's alarm and timer
-  features.

-

-

-
-  
-    
-    
-  
-
January 24, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/pchtemp.4 4.html b/static/netbsd/man4/pchtemp.4 4.html
deleted file mode 100644
index e686f613..00000000
--- a/static/netbsd/man4/pchtemp.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCHTEMP(4)Device Drivers ManualPCHTEMP(4)

-

-

-

-
pchtemp — Intel
-    PCH Temperature Sensor

-

-

-

-
pchtemp* at pci?

-

-

-

-
The pchtemp driver provides support for
-    Intel PCH Temperature Sensor.

-
The pchtemp driver reports temperatures
-    through the envsys(4) API.

-

-

-

-
envsys(4), envstat(8),
-    powerd(8)

-

-

-

-
The pchtemp driver first appeared in
-    NetBSD 12.0.

-

-

-

-
The pchtemp driver was written by
-    YAMAMOTO Takashi
-    <yamt@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 15, 2026NetBSD 10.1

diff --git a/static/netbsd/man4/pci.4 3.html b/static/netbsd/man4/pci.4 3.html
deleted file mode 100644
index 5bbd7dd8..00000000
--- a/static/netbsd/man4/pci.4 3.html	
+++ /dev/null
@@ -1,567 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI(4)Device Drivers ManualPCI(4)

-

-

-

-
pci — introduction
-    to machine-independent PCI bus support and drivers

-

-

-

-
pci* at mainbus? bus ?
-  

-  pci* at pchb? bus ?
-  

-  pci* at ppb? bus ?

-

-  

-  options PCIVERBOSE
-  

-  options PCI_CONFIG_DUMP
-  

-  options PCI_ADDR_FIXUP
-  

-  options PCI_BUS_FIXUP
-  

-  options PCI_INTR_FIXUP

-

-

-

-
NetBSD includes a machine-independent PCI
-    bus subsystem and several machine-independent PCI device drivers.

-
Your system may support additional PCI devices and attachments.
-    Drivers for PCI devices not listed here are machine-dependent. Consult your
-    system's intro(4) for additional information.

-

-

-

-

-

-  

-  
Fixup PCI I/O and memory addresses.
-    
Some i386 and amd64 BIOS implementations don't allocate I/O
-        space and memory space for some PCI devices — primarily BIOS in
-        PnP mode, or laptops that expect devices to be configured via ACPI.
-        Since necessary space isn't allocated, those devices will not work
-        without special handling.

-    
This option allocates I/O space and memory space instead of
-        relying upon the BIOS to do so.

-    
If necessary space is already correctly assigned to the
-        devices, this option leaves the space as is.

-  

-  

-  
Fixup PCI bus numbering; needed for many cardbus(4)
-      bridges.
-    
Each PCI bus and CardBus should have a unique bus number. But
-        some BIOS implementations don't assign a bus number for subordinate PCI
-        buses. And many BIOS implementations don't assign a bus number for
-        CardBuses.

-    
A typical symptom of this is the following boot message:

-    

-    Please note that this cardbus0 has a bus number ‘0’, but
-      normally the bus number 0 is used by the machine's primary PCI bus. Thus,
-      this bus number for cardbus is incorrect (not assigned). In this
-      situation, a device located in cardbus0 doesn't show correct device ID,
-      because its bus number 0 incorrectly refers to the primary PCI bus, and a
-      device ID in the primary PCI bus is shown in the boot message instead of
-      the device's ID in the cardbus0.
-    
This option assigns bus numbers for all subordinate PCI buses
-        and CardBuses.

-    
Since this option renumbers all PCI buses and CardBuses, all
-        bus numbers of subordinate buses become different when this option is
-        enabled.

-  

-  

-  
Fixup PCI interrupt routing via PCIBIOS or ACPI.
-    
Some i386 and amd64 BIOS implementations don't assign an
-        interrupt for some devices.

-    
This option assigns an interrupt for such devices instead of
-        relying upon the BIOS to do so.

-    
If a valid interrupt has already been assigned to a device,
-        this option leaves the interrupt as is.

-  

-

-

-

-

-

-
NetBSD includes machine-independent PCI
-    drivers, sorted by device type and driver name:

-

-

-

-

-  
ahc(4)

-  
Adaptec 29xx, 39xx, and other AIC-7xxx-based SCSI interfaces.

-  
adv(4)

-  
Advansys SCSI interfaces.

-  
adw(4)

-  
Advansys Ultra Wide SCSI interfaces.

-  
bha(4)

-  
Buslogic BT-9xx SCSI interfaces.

-  
dpt(4)

-  
DPT SmartCache/SmartRAID III and IV SCSI interfaces.

-  
esiop(4)

-  
Enhanced Symbios Logic/NCR 53c8xx SCSI controllers.

-  
iha(4)

-  
Initio INIC-940/950 SCSI interfaces.

-  
isp(4)

-  
QLogic ISP-1020, ISP-1040, and ISP-2100 SCSI and FibreChannel
-    interfaces.

-  
mfi(4)

-  
LSI Logic & Dell MegaRAID SAS RAID controllers.

-  
mly(4)

-  
Mylex AcceleRAID and eXtremeRAID controllers with v6 firmware.

-  
mpii(4)

-  
LSI Logic Fusion-MPT Message Passing Interface II SAS controllers.

-  
mpt(4)

-  
LSI Logic Fusion-MPT SCSI/Fibre Channel/SAS controllers.

-  
nca(4)

-  
Domex 536 SCSI interfaces.

-  
njs(4)

-  
Workbit NinjaSCSI-32 PCI/CardBus SCSI controllers.

-  
pcscp(4)

-  
Advanced Micro Devices Am53c974 PCscsi-PCI SCSI interfaces.

-  
siop(4)

-  
Symbios Logic/NCR 53c8xx-family SCSI interfaces.

-  
trm(4)

-  
Tekram TRM-S1040 ASIC based SCSI interfaces.

-

-

-

-

-

-

-

-  
aac(4)

-  
The Adaptec AAC family of RAID controllers.

-  
acardide(4)

-  
Acard IDE disk controllers.

-  
aceride(4)

-  
Acer Labs M5229 IDE controllers.

-  
ahcisata(4)

-  
AHCI 1.0 and 1.1 compliant SATA controllers.

-  
amr(4)

-  
The AMI and LSI Logic MegaRAID family of RAID controllers.

-  
arcmsr(4)

-  
Areca Technology Corporation SATA/SAS RAID controllers.

-  
artsata(4)

-  
Intel i31244 Serial ATA disk controllers.

-  
cac(4)

-  
Compaq array controllers.

-  
ciss(4)

-  
HP/Compaq Smart ARRAY 5/6 RAID controllers.

-  
cmdide(4)

-  
CMD Technology and Silicon Image IDE disk controllers.

-  
cypide(4)

-  
Cypress 82C693 IDE controllers.

-  
hptide(4)

-  
Triones/Highpoint IDE disk controllers.

-  
icp(4)

-  
ICP Vortex GDT and Intel Storage RAID controllers.

-  
iteide(4)

-  
Integrated Technology Express IDE disk controllers.

-  
ixpide(4)

-  
ATI Technologies IXP IDE controllers.

-  
jmide(4)

-  
JMicron Technology JMB36x PCIe to SATA II/PATA controllers.

-  
mlx(4)

-  
Mylex DAC960 and DEC SWXCR RAID controllers.

-  
mvsata(4)

-  
Marvell Hercules-I and Hercules-II SATA controllers.

-  
nside(4)

-  
National Semiconductor PC87415 PCI-IDE controllers.

-  
nvme(4)

-  
Non-Volatile Memory (NVM Express) host controllers.

-  
optiide(4)

-  
OPTi IDE disk controllers.

-  
pdcide(4)

-  
Promise IDE disk controllers.

-  
pdcsata(4)

-  
Promise Serial-ATA disk controllers.

-  
pciide(4)

-  
IDE disk controllers.

-  
rtsx(4)

-  
Realtek SD card readers.

-  
satalink(4)

-  
Silicon Image SATALink disk controllers.

-  
schide(4)

-  
Intel SCH IDE disk controllers.

-  
siisata(4)

-  
Silicon Image SATA-II controllers.

-  
siside(4)

-  
Silicon Integrated System IDE disk controllers.

-  
slide(4)

-  
Symphony Labs and Winbond IDE disk controllers.

-  
stpcide(4)

-  
STMicroelectronics STPC IDE disk controllers

-  
svwsata(4)

-  
Serverworks Serial ATA disk controllers.

-  
twa(4)

-  
3ware Apache RAID controllers.

-  
twe(4)

-  
3Ware Escalade RAID controllers.

-  
viaide(4)

-  
AMD, NVIDIA and VIA IDE disk controllers.

-

-

-

-

-

-

-

-  
age(4)

-  
Attansic L1 10/100/Gigabit Ethernet interfaces.

-  
alc(4)

-  
Atheros AR813x/AR815x/AR816x/AR817x and Killer E2200/2400/2500 10/100/1000
-      Ethernet interfaces.

-  
ale(4)

-  
Atheros AR8121/AR8113/AR8114 (Attansic L1E) 10/100/1000 Ethernet
-      interfaces.

-  
aq(4)

-  
Aquantia AQC multigigabit Ethernet interfaces.

-  
bce(4)

-  
Broadcom BCM4401 10/100 Ethernet interfaces.

-  
bge(4)

-  
Broadcom BCM57xx/BCM590x 10/100/1000 Ethernet interfaces.

-  
bnx(4)

-  
Broadcom NetXtreme II 10/100/1000 Ethernet interfaces.

-  
cas(4)

-  
Sun Cassini/Cassini+ (GigaSwift) Ethernet devices.

-  
dge(4)

-  
Intel i82597EX PRO/10GbE LR Ethernet interfaces.

-  
ena(4)

-  
Elastic Network Adapter interfaces.

-  
ep(4)

-  
3Com 3c590, 3c595, 3c900, and 3c905 Ethernet interfaces.

-  
epic(4)

-  
SMC83C170 (EPIC/100) Ethernet interfaces.

-  
eqos(4)

-  
DesignWare Ethernet Quality-of-Service controllers.

-  
et(4)

-  
Agere/LSI ET1310/ET1301 10/100/1000 Ethernet interfaces.

-  
ex(4)

-  
3Com 3c900, 3c905, and 3c980 Ethernet interfaces.

-  
fxp(4)

-  
Intel EtherExpress PRO 10+/100B Ethernet interfaces.

-  
gsip(4)

-  
National Semiconductor DP83820 based Gigabit Ethernet interfaces.

-  
hme(4)

-  
Sun Microelectronics STP2002-STQ Ethernet interfaces.

-  
igc(4)

-  
Intel I225/I226 1Gb/2.5Gb Ethernet devices.

-  
ixg(4)

-  
Intel 82598EB, 82599, X540 and X550 10 Gigabit Ethernet interfaces.

-  
ixl(4)

-  
Intel 700 series Ethernet interfaces.

-  
jme(4)

-  
JMicron Technologies JMC250/JMC260 Ethernet interfaces.

-  
kse(4)

-  
Micrel 8842/8841 PCI Ethernet controllers.

-  
le(4)

-  
PCNet-PCI Ethernet interfaces. Note, the pcn(4) driver
-      supersedes this driver.

-  
lii(4)

-  
Attansic/Atheros L2 Fast-Ethernet interfaces.

-  
mcx(4)

-  
Mellanox 5th generation Ethernet devices.

-  
msk(4)

-  
Marvell Yukon 2 based Gigabit Ethernet interfaces.

-  
ne(4)

-  
NE2000-compatible Ethernet interfaces.

-  
nfe(4)

-  
NVIDIA nForce Ethernet interfaces.

-  
ntwoc(4)

-  
SDL Communications N2pci and WAN/ic 400 synchronous serial
-    interfaces.

-  
pcn(4)

-  
AMD PCnet-PCI family of Ethernet interfaces.

-  
re(4)

-  
Realtek 10/100/1000 Ethernet adapters.

-  
rge(4)

-  
Realtek RTL8125-based Ethernet interfaces.

-  
rtk(4)

-  
Realtek 8129/8139 based Ethernet interfaces.

-  
sf(4)

-  
Adaptec AIC-6915 10/100 Ethernet interfaces.

-  
sip(4)

-  
Silicon Integrated Systems SiS 900, SiS 7016, and National Semiconductor
-      DP83815 based Ethernet interfaces.

-  
sk(4)

-  
SysKonnect SK-98xx based Gigabit Ethernet interfaces.

-  
ste(4)

-  
Sundance ST-201 10/100 based Ethernet interfaces.

-  
stge(4)

-  
Sundance/Tamarack TC9021 based Gigabit Ethernet interfaces.

-  
ti(4)

-  
Alteon Networks Tigon I and Tigon II Gigabit Ethernet driver.

-  
tl(4)

-  
Texas Instruments ThunderLAN-based Ethernet interfaces.

-  
tlp(4)

-  
DECchip 21x4x and clone Ethernet interfaces.

-  
txp(4)

-  
3Com 3XP Typhoon/Sidewinder (3CR990) Ethernet interfaces.

-  
vge(4)

-  
VIA Networking Technologies VT6122 PCI Gigabit Ethernet adapter
-    driver.

-  
vmx(4)

-  
VMware VMXNET3 virtual Ethernet interfaces.

-  
vr(4)

-  
VIA VT3043 (Rhine) and VT86C100A (Rhine-II) Ethernet interfaces.

-  
vte(4)

-  
Vortex86 RDC R6040 Fast Ethernet driver.

-  
wm(4)

-  
Intel i8254x Gigabit Ethernet driver.

-  
xge(4)

-  
Neterion Xframe-I LR Ethernet adapters.

-

-

-

-

-

-

-

-  
an(4)

-  
Aironet 4500/4800 and Cisco 340 series 802.11 interfaces.

-  
atw(4)

-  
ADMtek ADM8211 IEEE 802.11b PCI/CardBus wireless network interfaces.

-  
ath(4)

-  
Atheros IEEE 802.11a/b/g wireless network interfaces.

-  
athn(4)

-  
Atheros IEEE 802.11a/b/g/n wireless network interfaces.

-  
bwi(4)

-  
Broadcom BCM430x/4318 IEEE 802.11b/g wireless network interfaces.

-  
bwfm(4)

-  
Broadcom and Cypress FullMAC wireless network interfaces.

-  
ipw(4)

-  
Intel PRO/Wireless 2100 MiniPCI network interfaces.

-  
iwi(4)

-  
Intel PRO/Wireless 2200BG and 2915ABG MiniPCI network interfaces.

-  
iwm(4)

-  
Intel Dual Band Wireless AC PCIe Mini Card network interfaces.

-  
iwn(4)

-  
Intel Wireless WiFi Link 4965/5000/1000 and Centrino Wireless-N
-      1000/2000/6000 PCIe Mini network interfaces.

-  
malo(4)

-  
Marvell Libertas 88W8335/88W8310/88W8385 802.11b/g wireless network
-      interfaces.

-  
ral(4)

-  
Ralink Technology RT2500/RT2600-based 802.11a/b/g wireless network
-      interfaces.

-  
rtw(4)

-  
Realtek RTL8180L 802.11b wireless network interfaces.

-  
rtwn(4)

-  
Realtek RTL8188CE/RTL8192CE 802.11b/g/n wireless network interfaces.

-  
wi(4)

-  
WaveLAN/IEEE and PRISM-II 802.11 wireless interfaces.

-  
wpi(4)

-  
Intel PRO/Wireless 3945ABG Mini PCI Express network adapters.

-

-

-

-

-

-

-

-  
wwanc(4)

-  
Intel XMM 7360 LTE modem.

-

-

-

-

-

-

-

-  
cy(4)

-  
Cyclades Cyclom-4Y, -8Y, and -16Y multi-port serial interfaces.

-  
cz(4)

-  
Cyclades-Z series multi-port serial interfaces.

-  
pcweasel(4)

-  
PC-Weasel serial console board.

-

-

-

-

-

-

-

-  
auacer(4)

-  
Acer Labs M5455 I/O Controller Hub integrated AC'97 audio device.

-  
auich(4)

-  
Intel I/O Controller Hub integrated AC'97 audio device.

-  
auixp(4)

-  
ATI IXP series integrated AC'97 audio device.

-  
autri(4)

-  
Trident 4DWAVE-DX/NX, SiS 7018, ALi M5451 AC'97 audio device.

-  
auvia(4)

-  
VIA VT82C686A integrated AC'97 audio device.

-  
clcs(4)

-  
Cirrus Logic CS4280 audio device.

-  
clct(4)

-  
Cirrus Logic CS4281 audio device.

-  
cmpci(4)

-  
C-Media CMI8x38 audio device.

-  
eap(4)

-  
Ensoniq AudioPCI audio device.

-  
emuxki(4)

-  
Creative Labs SBLive! and PCI 512 audio device.

-  
esa(4)

-  
ESS Technology Allegro-1 / Maestro-3 audio device.

-  
esm(4)

-  
ESS Maestro-1/2/2e PCI AC'97 Audio Accelerator audio device.

-  
eso(4)

-  
ESS Solo-1 PCI AudioDrive audio device.

-  
fms(4)

-  
Forte Media FM801 audio device.

-  
gcscaudio(4)

-  
AMD Geode CS5536 audio device.

-  
hdaudio(4)

-  
High Definition Audio Specification 1.0 device.

-  
neo(4)

-  
NeoMagic MagicMedia 256 audio device.

-  
sv(4)

-  
S3 SonicVibes audio device.

-  
yds(4)

-  
Yamaha YMF724/740/744/754-based audio device.

-

-

-

-

-

-

-

-  
chipsfb(4)

-  
Chips & Technologies 6555x based framebuffers

-  
genfb(4)

-  
generic framebuffer console driver

-  
igmafb(4)

-  
Intel Graphics Media Accelerator framebuffers

-  
igsfb(4)

-  
IGA 1682 and CyberPro series graphics cards

-  
machfb(4)

-  
ATI Mach64/RAGE framebuffer driver

-  
pm3fb(4)

-  
3Dlabs Permedia 3 / Oxygen VX1 / Proformance 3 framebuffers

-  
r128fb(4)

-  
ATI RAGE 128 framebuffer driver

-  
radeonfb(4)

-  
ATI Radeon framebuffer driver

-  
tdvfb(4)

-  
3Dfx Voodoo Graphics / Voodoo 2 framebuffers

-  
voodoofb(4)

-  
3Dfx Voodoo 3 / Voodoo Banshee framebuffers

-  
vga(4)

-  
VGA graphics boards.

-

-

-

-

-

-

-

-  
hifn(4)

-  
Hifn 7751/7951/7811/7955/7956 crypto accelerators.

-  
qat(4)

-  
Intel QuickAssist crypto accelerator.

-  
ubsec(4)

-  
Broadcom and BlueSteel uBsec 5x0x crypto accelerator.

-

-

-

-

-

-

-

-  
ehci(4)

-  
USB EHCI host controllers.

-  
ohci(4)

-  
USB OHCI host controllers.

-  
uhci(4)

-  
USB UHCI host controllers.

-  
xhci(4)

-  
USB XHCI host controllers.

-

-

-

-

-

-

-

-  
cbb(4)

-  
PCI Yenta compatible CardBus bridges.

-  
pceb(4)

-  
Generic PCI-EISA bridges; see eisa(4).

-  
pcib(4)

-  
Generic PCI-ISA bridges; see isa(4).

-  
ppb(4)

-  
Generic PCI bridges, including expansion backplanes.

-

-

-

-

-

-

-

-  
coram(4)

-  
Conexant CX23885 based digital video cards.

-  
cxdtv(4)

-  
Conexant CX2388x based digital video cards.

-  
bktr(4)

-  
Brooktree 848 compatible TV cards.

-  
gtp(4)

-  
Gemtek PCI FM radio devices.

-  
ibmcd(4)

-  
IBM 4810 BSP cash drawer ports.

-  
iop(4)

-  
I2O I/O processors.

-  
oboe(4)

-  
Toshiba OBOE IrDA SIR/FIR controller.

-  
pcic(4)

-  
PCMCIA controllers, including the Cirrus Logic GD6729.

-  
puc(4)

-  
PCI “universal” communications cards, containing
-      com(4) and lpt(4) communications
-      ports.

-  
virtio(4)

-  
Para-virtualized I/O in a virtual machine.

-

-

-

-

-

-

-
pci(3), agp(4),
-    intro(4), pcictl(8),
-    pci(9)

-

-

-

-
The machine-independent PCI subsystem appeared in
-    NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
April 15, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/pciback.4 3.html b/static/netbsd/man4/pciback.4 3.html
deleted file mode 100644
index 0b713667..00000000
--- a/static/netbsd/man4/pciback.4 3.html	
+++ /dev/null
@@ -1,90 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCIBACK(4)Device Drivers Manual (xen)PCIBACK(4)

-

-

-

-
pciback — Xen
-    backend paravirtualized PCI pass-through driver

-

-

-

-
pciback* at pci?

-

-

-

-
The pciback driver is the backend part of
-    the PCI pass-through functionality that can be used by the Xen dom0 to
-    export pci(4) devices to a guest domain. To export a PCI
-    device to a guest domain, the device has to be attached to
-    pciback in the dom0.

-
When the guest domain is NetBSD, the
-    device attached to the pciback driver will attach to
-    a xpci(4) bus inside the guest domain.

-

-

-

-
To attach a device to the pciback driver,
-    follow these steps:

-
    
-  
  1. look for the device PCI ID, via pcictl(8).
    2. 
-  
  2. edit boot.cfg(5) and add the PCI ID to the list of PCI
-      IDs that you want to attach to pciback, in
-      bus:device.function notation. The list is passed to dom0 module via the
-      pciback.hide parameter:
-    
    pciback.hide=(bus:dev.fun)(bus:dev.func)(...)
    
-    See also boot(8).
    3. 
-  
  3. reboot dom0.
    4. 
-  
  4. add the PCI ID to the list of PCI devices in the domain configuration
-      file:
-    
    pci = ['bus:dev.fun',
-      '...']
    
-  
    5. 
-  
  5. start the guest domain.
    6. 
-

-

-

-

-
pci(4), xpci(4),
-    boot(8), pcictl(8)

-

-

-

-
The pciback driver first appeared in
-    NetBSD 5.1.

-

-

-

-
The pciback driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>.

-

-

-

-
Currently, to attach a device to the
-    pciback backend, this procedure has to be performed
-    at boot(8) time. In the future, it will be possible to do
-    it without requiring a dom0 reboot.

-

-

-

-
As PCI passthrough offers the possibility for guest domains to
-    send arbitrary PCI commands to a physical device, this has direct impact on
-    the overall stability and security of the system. For example, in case of
-    erroneous or malicious commands, the device could overwrite physical memory
-    portions, via DMA.

-

-

-
-  
-    
-    
-  
-
January 8, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/pcic.4 4.html b/static/netbsd/man4/pcic.4 4.html
deleted file mode 100644
index 755cfa8d..00000000
--- a/static/netbsd/man4/pcic.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCIC(4)Device Drivers ManualPCIC(4)

-

-

-

-
pcic — Intel and
-    Cirrus Logic PCMCIA controller driver

-

-

-

-
pcic0 at isa? port 0x3e0 iomem 0xd0000 iosiz
-    0x4000 flags N
-  

-  pcic1 at isa? port 0x3e2 iomem 0xd4000 iosiz 0x4000 flags
-    N
-  

-  pcic* at isapnp?
-  

-  pcic* at pci? dev? function ?
-  

-  pcmcia* at pcic? controller ? socket ?

-

-

-

-
NetBSD provides support for the Intel
-    82365SL, Cirrus Logic PD6710 and PD672x PCMCIA controllers.

-
For the isa(4) attachment a
-    flags value of 1 can be used to force the use of
-    polling instead of interrupts for card events.

-
The default configuration of the pcic gives each controller 16
-    kilobytes of memory, to be shared between slots. Some PC Card devices
-    require somewhat more memory than this; it may therefore be necessary to
-    adjust the iomem and iosiz
-    parameters of the pcic devices in the kernel config
-    file to accommodate these cards.

-

-

-

-
isa(4), isapnp(4),
-    pci(4), pcmcia(4),
-    tcic(4)

-

-
-

-

-

-
The pcic driver appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
May 21, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/pciide.4 3.html b/static/netbsd/man4/pciide.4 3.html
deleted file mode 100644
index 27c60839..00000000
--- a/static/netbsd/man4/pciide.4 3.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCIIDE(4)Device Drivers ManualPCIIDE(4)

-

-

-

-
pciide — PCI IDE
-    disk controllers driver

-

-

-

-
pciide* at pci? dev ? function ? flags
-    0x0000
-  

-  pciide* at pnpbios? index ?

-

-

-

-
The pciide driver supports the PCI IDE
-    controllers as specified in the "PCI IDE controller specification,
-    revision 1.0" draft, and provides the interface with the hardware for
-    the ata driver. Please use the chip-specific drivers
-    for the following controllers for enhanced and DMA support:

-
    
-  
  • Acard ATP850 (Ultra/33) and ATP860 (Ultra/66) IDE Controllers:
-      acardide(4)
    • 
-  
  • Acer labs M5229 IDE Controller: aceride(4)
    • 
-  
  • Advanced Micro Devices AMD-756, 766, and 768 IDE Controllers:
-      viaide(4)
    • 
-  
  • Advanced Micro Devices Geode IDE Controllers:
-      geodeide(4)
    • 
-  
  • CMD Tech PCI0643, PCI0646, PCI0648, and PCI0649 IDE Controllers:
-      cmdide(4)
    • 
-  
  • Contaq Microsystems/Cypress CY82C693 IDE Controller:
-      cypide(4)
    • 
-  
  • HighPoint HPT366 Ultra/66, HPT370 Ultra/100, HPT372, and HPT374 Ultra/133
-      IDE controller: hptide(4)
    • 
-  
  • Intel PIIX, PIIX3, and PIIX4 IDE Controllers:
-    piixide(4)
    • 
-  
  • Intel i31244 Serial ATA controller: artsata(4)
    • 
-  
  • Intel 82801 (ICH/ICH0/ICH2/ICH3/ICH4/ICH5/ICH6) IDE Controllers:
-      piixide(4)
    • 
-  
  • Intel SCH IDE Controllers: schide(4)
    • 
-  
  • NVIDIA nForce/nForce2 IDE Controllers: viaide(4)
    • 
-  
  • OPTi 82c621 (plus a few of its derivatives) IDE Controllers:
-      optiide(4)
    • 
-  
  • Promise PDC20246 (Ultra/33), PDC20262 (Ultra/66), PDC20265/PDC20267
-      (Ultra100), PDC20268 (Ultra/100TX2 and Ultra/100TX2v2), Ultra/133,
-      Ultra/133TX2 and Ultra/133TX2v2 PCI IDE controllers:
-      pdcide(4)
    • 
-  
  • Serverworks K2 SATA controllers: svwsata(4)
    • 
-  
  • Silicon Image 0680 IDE controller: cmdide(4)
    • 
-  
  • Silicon Image SATALink 3112 Serial ATA controller:
-      satalink(4)
    • 
-  
  • Silicon Image SteelVine 3124/3132/3531 Serial ATA II controller:
-      siisata(4)
    • 
-  
  • Silicon Integrated System 5597/5598 IDE controller:
-      siside(4)
    • 
-  
  • Symphony Labs 82C105 and Winbond W83C553F IDE controller:
-      slide(4)
    • 
-  
  • VIA Technologies VT82C586, VT82C586A, VT82C596A, VT82C686A, VT8233A, and
-      VT8235 IDE Controllers: viaide(4)
    • 
-

-
The 0x0001 flag forces the pciide driver
-    to use DMA when there is no explicit DMA mode setting support for the
-    controller but DMA is present. If the BIOS didn't set up the controller
-    properly, this can cause a machine hang.

-
The 0x0002 flag forces the pciide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
acardide(4), aceride(4),
-    artsata(4), ata(4),
-    atapi(4), cmdide(4),
-    cypide(4), geodeide(4),
-    hptide(4), intro(4),
-    optiide(4), pci(4),
-    pdcide(4), piixide(4),
-    pnpbios(4), satalink(4),
-    schide(4), siisata(4),
-    siside(4), slide(4),
-    viaide(4), wd(4),
-    wdc(4)

-

-

-
-  
-    
-    
-  
-
November 7, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/pckbc.4 4.html b/static/netbsd/man4/pckbc.4 4.html
deleted file mode 100644
index 3493c655..00000000
--- a/static/netbsd/man4/pckbc.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCKBC(4)Device Drivers ManualPCKBC(4)

-

-

-

-
pckbc — PC (ISA)
-    keyboard controller driver

-

-

-

-
pckbc* at acpi?
-  

-  pckbc* at isa?
-  

-  pckbc* at pnpbios? index ?
-  

-  pckbd* at pckbc? slot ?
-  

-  pms* at pckbc? slot ?

-

-

-

-
The pckbc driver handles resource
-    allocation and device attachment for the traditional PC/AT keyboard
-    controller. It provides two logical connections for child devices, the
-    “keyboard” slot for a keyboard and the
-    “auxiliary” slot for mice (the latter might be missing in
-    older keyboard controllers).

-
The optional “slot” locator argument can be used to
-    force unusual connections of devices to logical slots. This feature is for
-    experimentation only, it will not be useful in normal operation.

-

-

-

-
acpi(4), isa(4),
-    pckbd(4), pms(4),
-    pnpbios(4)

-

-

-
-  
-    
-    
-  
-
April 16, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/pckbd.4 4.html b/static/netbsd/man4/pckbd.4 4.html
deleted file mode 100644
index 5964b96f..00000000
--- a/static/netbsd/man4/pckbd.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCKBD(4)Device Drivers ManualPCKBD(4)

-

-

-

-
pckbd — PC
-    keyboard driver for wscons

-

-

-

-
pckbc* at isa?
-  

-  pckbd* at pckbc?
-  

-  wskbd* at pckbd? console ?
-  

-  options PCKBD_LAYOUT=XXX

-

-

-

-
This driver supports PC/AT keyboards within the
-    wscons(4) console framework. It doesn't provide direct
-    device driver entry points but makes its functions available via the
-    internal wskbd(4) interface.

-
The pckbd driver supports a number of
-    different key mappings which can be chosen from with the kernel option
-    PCKBD_LAYOUT at compile time or with the utility
-    wsconsctl(8) (variable: “encoding”) at
-    runtime. Other mappings can be used if the whole keymap is replaced by means
-    of wsconsctl(8).

-
Because PC keyboard hardware doesn't contain a beeper, requests
-    for “keyboard beeps” cannot be handled directly. On alpha and
-    i386 a helper device attached to the pcppi(4) driver
-    allows the use of the standard ISA speaker for this purpose. On acorn32,
-    acorn32/vidcaudio(4) performs this function.

-

-

-

-
To set a German keyboard layout without “dead
-    accents” and sending an ESC character before the key symbol if the
-    ALT key is pressed simultaneously, use wsconsctl
-    -w encoding=de.nodead.metaesc.
-    To set it at kernel build time, add

-
options
-  PCKBD_LAYOUT="(KB_DE | KB_NODEAD |
-  KB_METAESC)"

-to the kernel configuration file.
-

-

-

-
isa(4), pcppi(4),
-    wskbd(4), wsconsctl(8)

-

-

-
-  
-    
-    
-  
-
July 13, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/pcmcia.4 4.html b/static/netbsd/man4/pcmcia.4 4.html
deleted file mode 100644
index 47dcbbf0..00000000
--- a/static/netbsd/man4/pcmcia.4 4.html	
+++ /dev/null
@@ -1,216 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCMCIA(4)Device Drivers ManualPCMCIA(4)

-

-

-

-
pcmcia —
-    introduction to PCMCIA (PC Card) support

-

-

-

-
pcmcia* at pcic? controller ? socket ?
-  

-  pcmcia* at tcic? controller ? socket ?
-  

-  pcmcia* at cardslot?

-

-  

-  options PCMCIAVERBOSE

-

-

-
pcmcia* at pccard0

-

-

-

-
pcmcia* at it8368e? controller ? socket ?
-  

-  pcmcia* at plumpcmcia? controller ? socket ?

-

-

-

-
pcmcia* at hd64461pcmcia? controller ? socket
-    ?

-

-

-

-
pcmcia* at shpcic? controller ? socket
-  ?

-

-

-

-
pcmcia* at nell?

-

-

-

-

-
NetBSD provides machine-independent bus
-    support and drivers for PCMCIA (Personal Computer Memory Card International
-    Association) a.k.a. PC Card, CardBus devices.

-

-

-

-
NetBSD includes the following
-    machine-independent PCMCIA drivers, sorted by function and driver name:

-

-

-

-

-  
com(4)

-  
8250/16450/16550-compatible PCMCIA serial cards and modems.

-

-

-

-

-

-

-

-  
an(4)

-  
Aironet 4500/4800 and Cisco 340 series 802.11 controller.

-  
awi(4)

-  
802.11 controller based on the AMD PCnetMobile chipset.

-  
cnw(4)

-  
Netwave AirSurfer Wireless LAN interface.

-  
ep(4)

-  
3Com 3c589 EtherLink III Ethernet card.

-  
mbe(4)

-  
Ethernet card based on the Fujitsu MB86960A/MB86965A chipset.

-  
mhzc(4)

-  
Megahertz Ethernet/Modem combo cards

-  
ne(4)

-  
NE2000 compatible cards.

-  
ray(4)

-  
Raytheon Raylink and WebGear Aviator2.4 802.11 controller.

-  
sm(4)

-  
Megahertz Ethernet card.

-  
wi(4)

-  
Lucent WaveLAN/IEEE and PRISM-II based 802.11 controller.

-  
xi(4)

-  
Xircom CreditCard Ethernet

-

-

-

-

-

-

-

-  
aic(4)

-  
Adaptec APA-1460 SCSI controller card.

-  
esp(4)

-  
NCR 53C9x, Emulex ESP406, and Qlogic FAS408 SCSI controllers.

-  
spc(4)

-  
Fujitsu MB87030/MB89352 SCSI controllers.

-

-

-

-

-

-

-

-  
wdc(4)

-  
Digital Hinote Ultra Mobile Media Adapter

-

-

-

-

-

-

-

-  
bt3c(4)

-  
3Com 3CRWB6096 Bluetooth PC Card driver.

-  
btbc(4)

-  
AnyCom Bluetooth BlueCard driver.

-

-

-

-

-

-

-

-  
slhci(4)

-  
Cypress/ScanLogic SL811HS USB Host Controller driver.

-

-

-

-

-

-

-
cardbus(4), intro(4),
-    isa(4), options(4),
-    pcic(4), tcic(4),
-    pcmcia(9)

-

-

-

-
The pcmcia driver appeared in
-    NetBSD 1.3.

-

-

-

-

-

-
NetBSD probes the PCMCIA IO bus width and
-    uses that information to decide where to map PCMCIA IO space. For 10-bit
-    wide cards, 0x300-0x3ff is used. For 12-bit wide cards, 0x400-0x4ff is
-  used.

-
Neither choice is perfect. In the 12-bit case, 0x400 appears to
-    work in substantially more devices than 0x300. In the event that PCMCIA
-    devices are mapped in 0x400-0x4ff and appear to be nonfunctional, remapping
-    to 0x300-0x3ff may be appropriate; consult options
-    PCIC_ISA_ALLOC_IOBASE and options
-    PCIC_ISA_ALLOC_IOSIZE in options(4). Example:

-

-
# Avoid PCMCIA bus space conflicts with the default IO space
-# allocation on 12-bit wide busses (base 0x300 size 0xff).
-options PCIC_ISA_ALLOC_IOBASE=0x300
-options PCIC_ISA_ALLOC_IOSIZE=0x0ff

-

-

-

-

-
NetBSD attempts to probe for available
-    interrupts to assign to PCMCIA devices. In some cases, it is not possible to
-    detect all interrupts in use; in such cases, use of options
-    PCIC_ISA_INTR_ALLOC_MASK may be necessary. See
-    options(4).

-

-

-

-
During autoconfiguration, if a message is displayed saying that
-    your card is "not configured" it indicates that there isn't
-    support for your card compiled into the kernel. To fix this problem, it may
-    simply be a matter of adding the manufacturer and product IDs to the PCMCIA
-    database or adding a front-end attachment to an existing driver. In the
-    latter case, it is normally always necessary to get a dump of the CIS table
-    from the card. You can do this by adding options
-    PCMCIACISDEBUG and options PCMCIADEBUG into
-    your kernel config file. Additionally, you will have to patch the kernel to
-    enable run-time debugging. This can be done in the source by changing the
-    variables pcmcia_debug and
-    pcmciacis_debug to 0xff. Alternatively, you can patch
-    the same variables at run-time using ddb(4). For most
-    drivers you should also consider enabling any driver-specific debugging
-    options.

-

-

-

-
-  
-    
-    
-  
-
January 3, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/pcmcom.4 4.html b/static/netbsd/man4/pcmcom.4 4.html
deleted file mode 100644
index 761b65a9..00000000
--- a/static/netbsd/man4/pcmcom.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCMCOM(4)Device Drivers ManualPCMCOM(4)

-

-

-

-
pcmcom — PCMCIA
-    multi-port serial card driver

-

-

-

-
pcmcom* at pcmcia? function ?
-  

-  com* at pcmcom? slave ?

-

-

-

-
The pcmcom driver provides support for
-    Megahertz XJ2288 modem.

-

-

-

-
com(4), pcmcia(4)

-

-

-

-
The pcmcom driver appeared in
-    NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
May 21, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/pcn.4 4.html b/static/netbsd/man4/pcn.4 4.html
deleted file mode 100644
index a4cccdc0..00000000
--- a/static/netbsd/man4/pcn.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCN(4)Device Drivers ManualPCN(4)

-

-

-

-
pcn — AMD
-    PCnet-PCI Ethernet family driver

-

-

-

-
pcn* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The pcn device driver supports Ethernet
-    interfaces based on the AMD PCnet-PCI family of Ethernet chips. The chips
-    supported by the pcn driver include:

-
    
-  
  • Am79c970 PCnet-PCI Single-Chip Ethernet Controller for PCI Local Bus
    • 
-  
  • Am79c970A PCnet-PCI II Single-Chip Full-Duplex Ethernet Controller for PCI
-      Local Bus
    • 
-  
  • Am79c971 PCnet-FAST Single-Chip Full-Duplex 10/100Mbps Ethernet Controller
-      for PCI Local Bus
    • 
-  
  • Am79c972 PCnet-FAST+ Enhanced 10/100Mbps PCI Ethernet Controller with
-      OnNow Support
    • 
-  
  • Am79c973/Am79c975 PCnet-FAST III Single-Chip 10/100Mbps PCI Ethernet
-      Controller with Integrated PHY
    • 
-

-
PCnet-PCI chips are found on some Hewlett-Packard PCI Ethernet
-    boards, and on the Allied Telesyn AT-2700TX PCI Ethernet board. They are
-    also found on some processor evaluation boards as an example peripheral.

-
The pcn driver also supports the emulated
-    PCnet-PCI interface provided by VMware.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The pcn driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The pcn driver was written by
-    Jason R. Thorpe
-    ⟨thorpej@wasabisystems.com⟩.

-

-

-
-  
-    
-    
-  
-
August 27, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/pcppi.4 4.html b/static/netbsd/man4/pcppi.4 4.html
deleted file mode 100644
index 7a739519..00000000
--- a/static/netbsd/man4/pcppi.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCPPI(4)Device Drivers ManualPCPPI(4)

-

-

-

-
pcppi — PC (ISA)
-    control port driver

-

-

-

-
pcppi* at acpi?
-  

-  pcppi* at isa?
-  

-  isabeep* at pcppi? (alpha only)
-  

-  sysbeep* at pcppi? (i386 only)
-  

-  spkr0 at pcppi?
-  

-  midi* at pcppi?

-

-

-

-
The pcppi driver handles resource
-    allocation and device attachment for the ports related to the ISA speaker in
-    the traditional PC/AT “design”. These are the “system
-    control port” (which was implemented by the 8255 “PPI”
-    in the XT, hence the name of this driver) at IO address 0x61.

-
When associated with an attimer(4) device, it is
-    possible to change the pitch of the sounds emitted through
-    pcppi.

-
The pcppi driver provides its child
-    devices with the ability to output simple tones through the PC speaker. The
-    speaker(4) and midi(4) devices use this
-    to synthesize sounds. The isabeep(4) and
-    sysbeep(4) devices are helpers which the
-    pckbd(4) driver uses as a substitute for a
-    “keyboard beep”, because the PC keyboard hardware doesn't
-    provide this.

-

-

-

-
acpi(4), attimer(4),
-    isa(4), midi(4),
-    pckbd(4), speaker(4)

-

-

-
-  
-    
-    
-  
-
March 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/pcscp.4 3.html b/static/netbsd/man4/pcscp.4 3.html
deleted file mode 100644
index 1d7d4395..00000000
--- a/static/netbsd/man4/pcscp.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCSCP(4)Device Drivers ManualPCSCP(4)

-

-

-

-
pcscp — Advanced
-    Micro Devices Am53c974 PCscsi-PCI SCSI driver

-

-

-

-
pcscp* at pci? dev ? function ?
-  

-  scsibus* at pcscp?

-

-

-

-
The pcscp driver provides support for the
-    Advanced Micro Devices Am53c974 PCscsi-PCI SCSI controller and boards using
-    this chip, including the Tekram DC-390 PCI SCSI host adapter.

-
For Tekram DC-390U/UW/F PCI SCSI host adapters, use the
-    siop(4) driver.

-
For Tekram DC-395U/UW/F PCI SCSI host adapters, use the
-    trm(4) driver.

-

-

-

-
cd(4), ch(4),
-    esp(4), intro(4),
-    pci(4), scsi(4),
-    sd(4), ss(4), st(4),
-    uk(4), scsipi(9)

-
Advanced Micro
-    Devices

-

-

-

-
The driver currently ignores EEPROM settings, which establish
-    per-target parameters etc.

-

-

-
-  
-    
-    
-  
-
February 21, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/pcweasel.4 3.html b/static/netbsd/man4/pcweasel.4 3.html
deleted file mode 100644
index 1171b252..00000000
--- a/static/netbsd/man4/pcweasel.4 3.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCWEASEL(4)Device Drivers ManualPCWEASEL(4)

-

-

-

-
pcweasel — Support
-    for the PC-Weasel serial console board

-

-

-

-
pseudo-device pcweasel
-  

-  weasel* at pci? dev ? function ?

-
Note that the appropriate display device must also be enabled. See
-    pcdisplay(4) for more information.

-

-

-

-
The PC-Weasel is a serial console board for use primarily on
-    Intel-based PC-class systems. It addresses a problem that nearly everyone
-    who has deployed a PC-class server has experienced: the total lack of remote
-    management capability on PC-class hardware.

-
In addition to serial console support, the PC-Weasel provides the
-    ability to remotely reset the system (by means of a hardware reset signal),
-    and provides a watchdog timer function.

-
The PC-Weasel works by emulating the original IBM Monochrome
-    Display Adapter (MDA). Writes to the display's character cells are
-    translated into ANSI terminal sequences which are then sent out the
-    PC-Weasel's serial port. Incoming characters are translated into PC keyboard
-    scan codes and then fed (by means of a cable) into the system's keyboard
-    controller. The system believes it is using a display console. This is
-    particularly important in the event that one needs access to BIOS
-    configuration menus.

-
The PC-Weasel also includes a ST16550 serial port, which
-    may be configured as any one of the system's serial ports. Typical usage is
-    to configure the port as
-     at ISA I/O
-    address 0x3f8. When the PC-Weasel detects activity on the ST16550, the
-    serial port is automatically connected to the ST16550 so that the serial
-    port may be used as normal. When the PC-Weasel detects activity on the
-    internal UART used for MDA emulation, the serial port is automatically
-    reconnected to the emulation UART. This allows the boot program and kernel
-    to be configured to use the serial port directly (which is more efficient
-    than using the MDA emulation mode), yet allows the MDA emulation to be
-    reestablished as soon as the kernel loses control of the system.

-
The pcweasel driver provides support for
-    the additional features present on the PC-Weasel. At the moment, this
-    includes support for the watchdog timer function. Use of the
-    pcweasel driver is not required in order for the
-    system to function with a PC-Weasel installed so long as only the MDA
-    emulation and ST16550 serial port functionality is required.

-

-

-

-
pcdisplay(4), wdogctl(8)

-

-

-

-
The pcweasel driver first appeared in
-    NetBSD 1.5.1.

-

-

-

-
The PC-Weasel was invented by Herb Peyerl and Jonathan Levine at
-    Canada Connect Corporation.

-
The pcweasel driver was written by
-    Jason R. Thorpe ⟨thorpej@zembu.com⟩,
-    and contributed by Zembu Labs, Inc. Herb Peyerl of Middle Digital, Inc.
-    provided several firmware updates during the development of the driver.

-

-

-
-  
-    
-    
-  
-
November 23, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/pdcide.4 3.html b/static/netbsd/man4/pdcide.4 3.html
deleted file mode 100644
index 71b760a0..00000000
--- a/static/netbsd/man4/pdcide.4 3.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
PDCIDE(4)Device Drivers ManualPDCIDE(4)

-

-

-

-
pdcide — Promise
-    IDE disk controllers driver

-

-

-

-
pdcide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The pdcide driver supports the Promise
-    Ultra33, Ultra66, Ultra100, Ultra100TX2, Ultra100TX2v2, Ultra133,
-    Ultra133TX2, Ultra133TX2v2, Fasttrak133 and Serial ATA/150 IDE controllers,
-    and provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the pdcide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-
The pdcide driver does NOT function
-    correctly on NetBSD/sparc64.

-

-

-
-  
-    
-    
-  
-
December 23, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/pdcsata.4 4.html b/static/netbsd/man4/pdcsata.4 4.html
deleted file mode 100644
index 0a79ad3a..00000000
--- a/static/netbsd/man4/pdcsata.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
PDCSATA(4)Device Drivers ManualPDCSATA(4)

-

-

-

-
pdcsata — Promise
-    Serial-ATA disk controllers driver

-

-

-

-
pdcsata* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The pdcsata driver supports the Promise
-    SATA150 (PDC20571, PDC20575, PDC20579, PDC20318, PDC20319, PDC20371,
-    PDC20375, PDC20376, PDC20377, PDC20378, and PDC20379) and SATA300 (PDC20775,
-    PDC40518, PDC40519, PDC40718, PDC40719 and PDC40779) families of serial-ATA
-    controllers, and provides the interface with the hardware for the
-    ata(4) driver.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The pdcsata device driver first appeared
-    in NetBSD 2.1.

-

-

-
-  
-    
-    
-  
-
September 3, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/piixide.4 4.html b/static/netbsd/man4/piixide.4 4.html
deleted file mode 100644
index 85411139..00000000
--- a/static/netbsd/man4/piixide.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
PIIXIDE(4)Device Drivers ManualPIIXIDE(4)

-

-

-

-
piixide — Intel
-    IDE/SATA disk controllers driver

-

-

-

-
piixide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The piixide driver supports the Intel
-    PIIX, PIIX3, PIIX4, and 82801
-    (ICH/ICH0/ICH2/ICH3/ICH4/ICH5/ICH6/ICH7/ICH8/ICH9/ICH10) IDE/SATA
-    controllers and provides the interface with the hardware for the
-    ata(4) driver.

-
The 0x0002 flag forces the piixide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
July 30, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/piixpcib.4 4.html b/static/netbsd/man4/piixpcib.4 4.html
deleted file mode 100644
index 670ef784..00000000
--- a/static/netbsd/man4/piixpcib.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
PIIXPCIB(4)Device Drivers ManualPIIXPCIB(4)

-

-

-

-
piixpcib — Intel
-    PIIX4 PCI-ISA bridge with SpeedStep

-

-

-

-
piixpcib* at pci? dev ? function ?
-  

-  isa* at piixpcib?

-

-

-

-
The piixpcib driver provides support for
-    the Intel PIIX and compatible PCI-ISA Bridges with Intel's first generation
-    SpeedStep.

-
Frequency scaling is supported on Pentium III with two voltage
-    modes, used by SpeedStep as power states low and high. The driver will
-    switch into low power state by reducing voltage and frequency of the CPU.
-    The factor depends on the processor itself, but will always reduce power
-    consumption about 1/2.

-
The user can manually control the CPU frequency with the
-    sysctl(8) program using the following node:

-

-

-  
machdep.speedstep_state = [0/1]

-  
 

-

-

-

-

-

-
est(4), isa(4),
-    pci(4), apmd(8),
-    sysctl(8)

-

-

-

-
The piixpcib driver first appeared in
-    FreeBSD 5.5 and then in NetBSD
-    4.0.

-

-

-

-
The current piixpcib driver was written by
-    Bruno Ducrot. It was ported to
-    NetBSD by Jared D. McNeill
-    <jmcneill@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 1, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/piixpm.4 4.html b/static/netbsd/man4/piixpm.4 4.html
deleted file mode 100644
index 4de09d58..00000000
--- a/static/netbsd/man4/piixpm.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
PIIXPM(4)Device Drivers ManualPIIXPM(4)

-

-

-

-
piixpm — Intel
-    PIIX and compatible Power Management controller

-

-

-

-
piixpm* at pci? dev ? function ?
-  

-  iic* at piixpm?

-

-

-

-
The piixpm driver provides support for the
-    Intel PIIX and compatible Power Management controller. Only the SMBus host
-    interface is supported and can be used with the iic(4)
-    framework.

-
Supported chipsets:

-

-
    
-  
  • ATI SB200, SB300, SB400, SB600, SB700, SB800
    • 
-  
  • Intel 82371AB (PIIX4), 82440MX
    • 
-  
  • Serverworks OSB4, OSB5, OSB6, HT1000SB
    • 
-  
  • AMD FCHs (HUDSON, BOLTON and KERNCZ)
    • 
-

-

-

-

-
iic(4), intro(4),
-    pci(4)

-

-

-

-
The piixpm driver first appeared in
-    OpenBSD 3.9 and then in NetBSD
-    4.0.

-

-

-

-
The current piixpm driver was written by
-    Alexander Yurchenko
-    <grange@openbsd.org>.
-    It was ported to NetBSD by Jared D.
-    McNeill
-    <jmcneill@netbsd.org>.

-

-

-

-
The driver doesn't support I2C commands with a data buffer size of
-    more than 2 bytes.

-

-

-
-  
-    
-    
-  
-
January 14, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/pim.4 3.html b/static/netbsd/man4/pim.4 3.html
deleted file mode 100644
index 9e217320..00000000
--- a/static/netbsd/man4/pim.4 3.html	
+++ /dev/null
@@ -1,179 +0,0 @@
-
-  
-    
-    
-    
-  
-
PIM(4)Device Drivers ManualPIM(4)

-

-

-

-
pim — Protocol
-    Independent Multicast

-

-

-

-
options MROUTING
-  

-  options PIM

-

-  

-  #include <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <netinet/in.h>
-  

-  #include <netinet/ip_mroute.h>
-  

-  #include <netinet/pim.h>

-
int
-  

-  getsockopt(int
-    s, IPPROTO_IP,
-    MRT_PIM,
-    void *optval,
-    socklen_t *optlen);

-
int
-  

-  setsockopt(int
-    s, IPPROTO_IP,
-    MRT_PIM,
-    const void *optval,
-    socklen_t optlen);

-
int
-  

-  getsockopt(int
-    s, IPPROTO_IPV6,
-    MRT6_PIM,
-    void *optval,
-    socklen_t *optlen);

-
int
-  

-  setsockopt(int
-    s, IPPROTO_IPV6,
-    MRT6_PIM,
-    const void *optval,
-    socklen_t optlen);

-

-

-

-
PIM is the common name for two multicast routing protocols:
-    Protocol Independent Multicast - Sparse Mode (PIM-SM) and Protocol
-    Independent Multicast - Dense Mode (PIM-DM).

-
PIM-SM is a multicast routing protocol that can use the underlying
-    unicast routing information base or a separate multicast-capable routing
-    information base. It builds unidirectional shared trees rooted at a
-    Rendezvous Point (RP) per group, and optionally creates shortest-path trees
-    per source.

-
PIM-DM is a multicast routing protocol that uses the underlying
-    unicast routing information base to flood multicast datagrams to all
-    multicast routers. Prune messages are used to prevent future datagrams from
-    propagating to routers with no group membership information.

-
Both PIM-SM and PIM-DM are fairly complex protocols, though PIM-SM
-    is much more complex. To enable PIM-SM or PIM-DM multicast routing in a
-    router, the user must enable multicast routing and PIM processing in the
-    kernel (see SYNOPSIS about the kernel
-    configuration options), and must run a PIM-SM or PIM-DM capable user-level
-    process. From developer's point of view, the programming guide described in
-    the Programming Guide section
-    should be used to control the PIM processing in the kernel.

-

-

-
After a multicast routing socket is open and multicast forwarding
-    is enabled in the kernel (see multicast(4)), one of the
-    following socket options should be used to enable or disable PIM processing
-    in the kernel. Note that those options require certain privilege (i.e., root
-    privilege):

-

-
/* IPv4 */
-int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_PIM, (void *)&v, sizeof(v));

-

-

-
/* IPv6 */
-int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_PIM, (void *)&v, sizeof(v));

-

-
After PIM processing is enabled, the multicast-capable interfaces
-    should be added (see multicast(4)). In case of PIM-SM, the
-    PIM-Register virtual interface must be added as well. This can be
-    accomplished by using the following options:

-

-
/* IPv4 */
-struct vifctl vc;
-memset(&vc, 0, sizeof(vc));
-/* Assign all vifctl fields as appropriate */
-...
-if (is_pim_register_vif)
-    vc.vifc_flags |= VIFF_REGISTER;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc,
-           sizeof(vc));

-

-

-
/* IPv6 */
-struct mif6ctl mc;
-memset(&mc, 0, sizeof(mc));
-/* Assign all mif6ctl fields as appropriate */
-...
-if (is_pim_register_vif)
-    mc.mif6c_flags |= MIFF_REGISTER;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MIF, (void *)&mc,
-           sizeof(mc));

-

-
Sending or receiving of PIM packets can be accomplished by opening
-    first a “raw socket” (see socket(2)), with
-    protocol value of IPPROTO_PIM:

-

-
/* IPv4 */
-int pim_s4;
-pim_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_PIM);

-

-

-
/* IPv6 */
-int pim_s6;
-pim_s6 = socket(AF_INET6, SOCK_RAW, IPPROTO_PIM);

-

-
Then, the following system calls can be used to send or receive
-    PIM packets: sendto(2), sendmsg(2),
-    recvfrom(2), recvmsg(2).

-

-

-

-

-
getsockopt(2), recvfrom(2),
-    recvmsg(2), sendmsg(2),
-    sendto(2), setsockopt(2),
-    socket(2), inet(4),
-    intro(4), ip(4),
-    multicast(4)

-

-

-

-
The PIM-SM protocol is specified in RFC 2362 (to be replaced by
-    draft-ietf-pim-sm-v2-new-*). The PIM-DM protocol is
-    specified in draft-ietf-pim-dm-new-v2-*).

-

-

-

-
The original IPv4 PIM kernel support for IRIX and SunOS-4.x was
-    implemented by Ahmed Helmy (USC and SGI). Later the
-    code was ported to various BSD flavors and modified
-    by George Edmond Eddy (Rusty) (ISI),
-    Hitoshi Asaeda (WIDE Project), and
-    Pavlin Radoslavov (USC/ISI and ICSI). The IPv6 PIM
-    kernel support was implemented by the KAME project
-    (http://www.kame.net), and was
-    based on the IPv4 PIM kernel support.

-
This manual page was written by Pavlin
-    Radoslavov (ICSI).

-

-

-
-  
-    
-    
-  
-
September 4, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/plip.4 4.html b/static/netbsd/man4/plip.4 4.html
deleted file mode 100644
index a2929a59..00000000
--- a/static/netbsd/man4/plip.4 4.html	
+++ /dev/null
@@ -1,261 +0,0 @@
-
-  
-    
-    
-    
-  
-
PLIP(4)Device Drivers ManualPLIP(4)

-

-

-

-
plip — printer
-    port Internet Protocol driver

-

-

-

-
plip* at ppbus?
-  

-  options PLIP_DEBUG

-

-

-

-
The plip driver allows a PC parallel
-    printer port to be used as a point-to-point network interface between two
-    similarly configured systems. Data is transferred 4 bits at a time, using
-    the printer status lines for input: hence there is no requirement for
-    special bidirectional hardware and any standard AT-compatible printer port
-    with working interrupts may be used.

-
During the boot process, for each ppbus(4)
-    device which is attached and has an interrupt capability, a corresponding
-    plip device is attached. The
-    plip device is configured using
-    ifconfig(8) using the options for a point-to-point network
-    interface:

-
ifconfig plip0
-    hostaddress destaddress
-    [-link0|link0] [up|down] [...]

-
Configuring a plip device
-    “up” with ifconfig(8) causes the
-    corresponding ppbus(4) to be reserved for PLIP until the
-    network interface is configured “down”.

-
The communication protocol is selected by the
-    link0 flag:

-

-  

-  
(default) Use FreeBSD mode (LPIP). This is the
-      simpler of the two modes and therefore slightly more efficient.

-  

-  
Use Crynwr/Linux compatible mode (CLPIP). This mode has a simulated
-      Ethernet packet header, and is easier to interface to other types of
-      equipment.

-

-
The interface MTU defaults to 1500, but may be set to any value.
-    Both ends of the link must be configured with the same MTU. See
-    ifconfig(8) for details on configuring network
-  interfaces.

-

-

-
The cable connecting the two parallel ports should be wired as
-    follows:

-

-
	Pin	Pin	Description
-	2	15	Data0 -> ERROR*
-	3	13	Data1 -> SLCT
-	4	12	Data2 -> PE
-	5	10	Data3 -> ACK*
-	6	11	Data4 -> BUSY
-	15	2	ERROR* -> Data0
-	13	3	SLCT   -> Data1
-	12	4	PE     -> Data2
-	10	5	ACK*   -> Data3
-	11	6	BUSY   -> Data4
-	18-25	18-25	Ground

-

-
Cables with this wiring are widely available as
-    “Laplink” cables, and are often colored yellow.

-
The connections are symmetric, and provide 5 lines in each
-    direction (four data plus one handshake). The two modes use the same wiring,
-    but make a different choice of which line to use as handshake.

-

-

-

-
The signal lines are used as follows:

-

-  

-  
Data out, bit 0.

-  

-  
Data out, bit 1.

-  

-  
Data out, bit 2.

-  

-  
Handshake out.

-  

-  
Data out, bit 3.

-  

-  
Data in, bit 0.

-  

-  
Data in, bit 1.

-  

-  
Data in, bit 2.

-  

-  
Data in, bit 3.

-  

-  
Handshake in.

-

-
When idle, all data lines are at zero. Each byte is signaled in
-    four steps: sender writes the 4 most significant bits and raises the
-    handshake line; receiver reads the 4 bits and raises its handshake to
-    acknowledge; sender places the 4 least significant bits on the data lines
-    and lowers the handshake; receiver reads the data and lowers its
-  handshake.

-
The packet format has a two-byte header, comprising the fixed
-    values 0x08, 0x00, immediately followed by the IP header and data.

-
The start of a packet is indicated by simply signaling the first
-    byte of the header. The end of the packet is indicated by inverting the data
-    lines (i.e. writing the ones-complement of the previous nibble to be
-    transmitted) without changing the state of the handshake.

-
Note that the end-of-packet marker assumes that the handshake
-    signal and the data-out bits can be written in a single instruction -
-    otherwise certain byte values in the packet data would falsely be
-    interpreted as end-of-packet. This is not a problem for the PC printer port,
-    but requires care when implementing this protocol on other equipment.

-

-

-

-
The signal lines are used as follows:

-

-  

-  
Data out, bit 0.

-  

-  
Data out, bit 1.

-  

-  
Data out, bit 2.

-  

-  
Data out, bit 3.

-  

-  
Handshake out.

-  

-  
Data in, bit 0.

-  

-  
Data in, bit 1.

-  

-  
Data in, bit 2.

-  

-  
Data in, bit 3.

-  

-  
Handshake in.

-

-
When idle, all data lines are at zero. Each byte is signaled in
-    four steps: sender writes the 4 least significant bits and raises the
-    handshake line; receiver reads the 4 bits and raises its handshake to
-    acknowledge; sender places the 4 most significant bits on the data lines and
-    lowers the handshake; receiver reads the data and lowers its handshake.
-    [Note that this is the opposite nibble order to LPIP mode].

-
Packet format is:

-

-
Length (least significant byte)
-Length (most significant byte)
-12 bytes of supposed MAC addresses (ignored by FreeBSD).
-Fixed byte 0x08
-Fixed byte 0x00
-<IP datagram>
-Checksum byte.

-

-
The length includes the 14 header bytes, but not the length bytes
-    themselves nor the checksum byte.

-
The checksum is a simple arithmetic sum of all the bytes (again,
-    including the header but not checksum or length bytes).
-    FreeBSD calculates outgoing checksums, but does not
-    validate incoming ones.

-
The start of packet has to be signaled specially, since the line
-    chosen for handshake-in cannot be used to generate an interrupt. The sender
-    writes the value 0x08 to the data lines, and waits for the receiver to
-    respond by writing 0x01 to its data lines. The sender then starts signaling
-    the first byte of the packet (the length byte).

-
End of packet is deduced from the packet length and is not
-    signaled specially (although the data lines are restored to the zero, idle
-    state to avoid spuriously indicating the start of the next packet).

-

-

-

-

-
atppc(4), ppbus(4),
-    ifconfig(8)

-

-

-

-
The plip driver was implemented for
-    ppbus(4) in FreeBSD and imported
-    into NetBSD. Crynwr packet drivers implemented PLIP
-    for MS-DOS. Linux also has a PLIP driver. The protocols are know as LPIP
-    (FreeBSD) and CLPIP (Crynwr/Linux) in the
-    documentation and code of this port. LPIP originally appeared in
-    FreeBSD.

-

-

-

-
This manual page is based on the FreeBSD
-    lp manual page. The information has been updated for
-    the NetBSD port by Gary Thorpe.

-

-

-

-
Busy-waiting loops are used while handshaking bytes (and worse
-    still when waiting for the receiving system to respond to an interrupt for
-    the start of a packet). Hence a fast system talking to a slow one will
-    consume excessive amounts of CPU. This is unavoidable in the case of CLPIP
-    mode due to the choice of handshake lines; it could theoretically be
-    improved in the case of LPIP mode.

-
Regardless of the speed difference between hosts, PLIP is
-    CPU-intensive and its made worse by having to send nibbles (4 bits) at a
-    time.

-
Polling timeouts are controlled by counting loop iterations rather
-    than timers, and so are dependent on CPU speed. This is somewhat stabilized
-    by the need to perform (slow) ISA bus cycles to actually read the port.

-
In the FreeBSD implementation, the idle
-    state was not properly being restored on errors or when finishing
-    transmitting/receiving. This implementation attempts to fix this problem
-    which would result in an unresponsive interface that could no longer be used
-    (the port bits get stuck in a state and nothing can progress) by zeroing the
-    data register when necessary.

-
For unknown reasons, the more complex protocol (CLPIP) yields
-    higher data transfer rates during testing so far. This could possibly be
-    because the other side can reliably detect when the host is transmitting in
-    this implementation of CLPIP (this may not necessarily be true in Linux or
-    MS-DOS packet drivers). CLPIP gets about 70 KB/sec (the best expected is
-    about 75 KB/sec) and LPIP get about 55 KB/sec. This is despite LPIP being
-    able to send more packets over the interface (tested with
-    “ping -f”)
-    compared to CLPIP.

-

-

-
-  
-    
-    
-  
-
January 28, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/pm3fb.4 4.html b/static/netbsd/man4/pm3fb.4 4.html
deleted file mode 100644
index 10d09bd8..00000000
--- a/static/netbsd/man4/pm3fb.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
PM3FB(4)Device Drivers ManualPM3FB(4)

-

-

-

-
pm3fb — 3Dlabs
-    Permedia 3 / Oxygen VX1 / Proformance 3 framebuffer driver

-

-

-

-
pm3fb* at pci?
-  

-  wsdisplay* at pm3fb?

-

-

-

-
The pm3fb driver provides support for the
-    3Dlabs Permedia 3 / Oxygen VX1 / Proformance 3 series of graphics cards and
-    provides an interface for machine independent wscons(4)
-    driver.

-
Currently pm3fb does not support
-    anti-alias font rendering and OpenLDI video interface. However, it is
-    capable of changing the resolution and uses DDC2 to pick an appropriate
-    video mode.

-
A 2D graphics engine is used to accelerate scrolling, rectangle
-    fills and bitmap font rendering.

-

-

-

-
pci(4), wscons(4),
-    wsdisplay(4)

-

-

-

-
The pm3fb driver was written by
-    Naruaki Etomi.

-

-

-
-  
-    
-    
-  
-
November 20, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/pms.4 3.html b/static/netbsd/man4/pms.4 3.html
deleted file mode 100644
index ab4ccd0a..00000000
--- a/static/netbsd/man4/pms.4 3.html	
+++ /dev/null
@@ -1,246 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMS(4)Device Drivers ManualPMS(4)

-

-

-

-
pms — PS/2
-    auxiliary port mouse driver

-

-

-

-
pckbc* at isa?
-  

-  pms* at pckbc?
-  

-  wsmouse* at pms?

-

-  

-  options PMS_DISABLE_POWERHOOK
-  

-  options PMS_SYNAPTICS_TOUCHPAD
-  

-  options PMS_ELANTECH_TOUCHPAD
-  

-  options PMS_ALPS_TOUCHPAD

-

-

-

-
The pms driver provides an interface to
-    PS/2 auxiliary port mice within the wscons(4) framework.
-    Parent device in terms of the autoconfiguration framework is
-    pckbc(4), the PC keyboard controller. “pms”
-    is a generic driver which supports mice using common variants of the PS/2
-    protocol, including wheel mice of the “IntelliMouse” breed.
-    Wheel movements are mapped to a third (z-) axis. The driver is believed to
-    work with both 3-button and 5-button mice with scroll wheels. Mice which use
-    other protocol extensions are not currently supported, but might be if
-    protocol documentation could be found. Mouse related data are accessed by
-    wsmouse(4) devices.

-
The pms driver has been updated to attempt
-    to renegotiate mouse protocol after seeing suspicious or defective mouse
-    protocol packets, or unusual delays in the middle of a packet; this should
-    improve the chances that a mouse will recover after being switched away or
-    reset (for instance, by a console switch).

-
The PMS_DISABLE_POWERHOOK kernel option
-    disables PS/2 reset on resume.

-
In addition, the pms driver supports the
-    “Synaptics”, “Elantech” and “ALPS”
-    touchpads in native mode, enabled with the
-    PMS_SYNAPTICS_TOUCHPAD,
-    PMS_ELANTECH_TOUCHPAD and
-    PMS_ALPS_TOUCHPAD kernel options. This allows the
-    driver to take advantage of extra features available on Synaptics, Elantech
-    and ALPS Touchpads.

-
The following sysctl(8) variables control
-    behavior of Synaptics touchpads:

-

-  

-  
If the touchpad reports the existence of extra ("Up/Down")
-      buttons, this value determines what kind of mouse events they should
-      generate. On certain clickpads, the Up/Down buttons may be physical
-      buttons that can be used instead of pressing the pad down, or used as
-      additional buttons.
-    
    
-      
  • If set to 0, Up/Down events generate button 4 and 5 clicks.
    • 
-      
  • If set to 1, Up/Down events generate middle button clicks.
    • 
-      
  • If set to 2, the Up and Down buttons are used for Z-axis emulation,
-          which more closely resembles how mouse wheels operate.
    • 
-      
  • If set to 3 (default), Up/Down events generate left/right clicks.
    • 
-    

-  

-  

-  
When the Up/Down buttons are used for Z-axis emulation, this value
-      specifies the emulated delta-Z value per click.

-  

-  
Gestures will not be recognised if the finger moves by more than this
-      amount between taps.

-  

-  
Gestures will not be recognised if the number of packets (at 80 packets
-      per second) between taps exceeds this value.

-  

-  
 

-  

-  
 

-  

-  
 

-  

-  
These values define a border around the touchpad which will be used for
-      edge motion emulation during a drag gesture. If a drag gesture is in
-      progress and the finger moves into this border, the driver will behave as
-      if the finger continues to move in the same direction beyond the edge of
-      the touchpad.

-  

-  
This specifies the pointer speed when edge motion is in effect.

-  

-  
The driver will ignore new finger events until the reported pressure
-      exceeds this value.

-  

-  
The driver will assume a finger remains on the touchpad until the reported
-      pressure drops below this value.

-  

-  
More recent touchpads can report the presence of more than one finger on
-      the pad. This value determines how such events are used.
-    
    
-      
  • If set to 0 (default), two-finger events are ignored.
    • 
-      
  • If set to 1, two-finger events generate a right button click.
    • 
-      
  • If set to 2, two-finger events generate a middle button click.
    • 
-    

-  

-  

-  
 

-  

-  
 

-  

-  
Scale factor used to divide movement deltas derived from Synaptics
-      coordinates (0-6143) to yield more reasonable values (default 16 for x and
-      y, 1 for z).

-  

-  
 

-  

-  
 

-  

-  
Limits pointer rate of change (after scaling) per reported movement event
-      (default 32 for x and y, 2 for z).

-  

-  
Movements of less than this value (in Synaptics coordinates) are ignored
-      (default 4).

-  

-  
This value determines whether or not the touchpad will respond to touch.
-      If set to 1 then the touchpad will respond to touch, if set to 0 will not
-      respond effectively disabling the touchpad.

-  

-  
This value determines if finger movement events will be reported for
-      fingers that are located in the button emulation region defined by
-      hw.synaptics.button_boundary If set to 0 (the
-      default) finger movements will not be reported. If set to 1 finger
-      movements will be reported.

-  

-  
 

-  

-  
These two items are interrelated in that setting one will affect the value
-      of the other. Since a clickpad only reports left clicks this region is
-      used to emulate two or three buttons by detecting the finger location and
-      reporting either a button 2 or button 3 click if the click occurs within
-      the region bounded by button_boundary and the bottom of the clickpad.
-      hw.synaptics.button_boundary sets the top edge of
-      the button emulation region on a clickpad and the percentage that
-      represents this value is calculated and stored in
-      hw.synaptics.button_region_percent Conversely, if
-      hw.synaptics.button_region_percent is set then the
-      equivalent value for hw.synaptics.button_boundary is
-      calculated and stored. Using a percentage allows the button region for
-      trackpads that are able to report their maximum and minimum values to be
-      reliably set to occupy a defined portion of the trackpad area instead of
-      the user having to tweak an arbitrary number.

-  

-  
This defines the left hand edge of the button 3 region. If a click occurs
-      in the region bounded by button_boundary, button3_edge and the right hand
-      edge of the click pad then the click will be reported as a button3 event.
-      Button 3 emulation can be disabled by setting button3_edge to the right
-      hand edge of the clickpad.

-  

-  
This defines the left hand edge of the button 2 region. The button 2
-      region is bounded by button2_edge, button3_edge and button_boundary. If a
-      click occurs in this region then it will be reported as a button2 event.
-      For completeness, the region between the left hand side of the clickpad,
-      button2_edge and button_boundary will be reported as a button1 event as
-      will any clicks that occur outside the button emulation region.

-  

-  
This causes Y-axis movement on the "passthrough device" (e.g.
-      the TrackPoint on ThinkPads) to result in scrolling events instead of
-      Y-axis movement when the middle button is held.

-  

-  
Reserve this percentage of the trackpad for a vertical scroll region. This
-      will reduce hw.synaptics.edge_right by this
-      percentage.

-  

-  
Reserve this percentage of the trackpad for a horizontal scroll region.
-      This will reduce hw.synaptics.edge_bottom by this
-      percentage. The hw.synaptics.button_boundary will be
-      recalculated as a result of the change.

-

-
The following sysctl(8) variables control
-    behavior of Elantech touchpads:

-

-  

-  
 

-  

-  
Increased values improve the accuracy of X, Y, and Z-axis reporting at the
-      expense of slower mouse movement (default 2 for xy, and 3 for z).

-

-
For Elantech touchpads, the Z-axis is emulated using two-finger
-    Y-axis reporting.

-
The following sysctl(8) variables control
-    behavior of ALPS touchpads:

-

-  

-  
 

-  

-  
Decreased values improve the accuracy of X and Y-axis reporting at the
-      expense of slower mouse movement (default 2 for touchpad and 1 for
-      TrackStick).

-  

-  
Movements of less than this value (in ALPS coordinates) are ignored
-      (default 4).

-

-

-

-

-
pckbc(4), ums(4),
-    wsmouse(4)

-

-

-

-
The pms driver was originally written by
-    Christopher G. Demetriou. The changes to merge the
-    “IntelliMouse” protocol in, and reset the mouse in the event
-    of protocol problems, were contributed by Peter
-    Seebach. Special thanks to Ray Trent, at Synaptics, who contributed
-    valuable insight into how to identify bogus mouse data. The changes to add
-    “Synaptics” pad support were by Ales
-    Krenek, Kentaro A. Kurahone, and
-    Steve C. Woodford. The changes to add
-    “Elantech” pad support were by Jared D.
-    McNeill.

-

-

-

-
It is possible for the driver to mistakenly negotiate the
-    non-scroll-wheel protocol, after which it is unlikely to recover until the
-    device is closed and reopened.

-
The “Elantech” pad code only supports trackpads with
-    firmware version 2.48 or above.

-

-

-
-  
-    
-    
-  
-
October 21, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/pmu.4 4.html b/static/netbsd/man4/pmu.4 4.html
deleted file mode 100644
index 79372607..00000000
--- a/static/netbsd/man4/pmu.4 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMU(4)Device Drivers ManualPMU(4)

-

-

-

-
pmu — support for
-    Power Management Units found in all Apple laptops and some desktop Power
-    Macintosh computers

-

-

-

-
pmu* at obio?
-  

-  nadb* at pmu?
-  

-  battery* at pmu?
-  

-  smartbat* at pmu?

-

-

-

-
The pmu driver provides support for the
-    Power Management Unit found in Apple laptops and some desktop Power
-    Macintosh computers. Functions controlled by the PMU include the real time
-    clock, ADB, power, batteries, on some laptops like the PowerBook 3400c and
-    similar machines it also controls hotkeys and display brightness, on others
-    it provides an iic(9) bus and on some it controls CPU
-    speed. On many older machines it also provides access to some non-volatile
-    memory and thermal sensors. Not all those features are present on all
-    machines, for instance Power Macintosh G4 and later machines don't have ADB,
-    many more recent laptops have display brightness and backlight control built
-    into the graphics controller instead of the PMU, only a few older PowerBooks
-    use the PMU for CPU speed control and newer machines use a different way to
-    access non-volatile memory. However, all known PMUs so far provide a real
-    time clock and power control.

-

-

-
Real time clock and power control are present and supported on all
-    machines that can run NetBSD/macppc, ADB is
-    supported when present.

-

-  

-  
Battery status and thermal sensors found on the mainboard and in the
-      battery pack are supported by the battery(4) driver,
-      values can be read via envsys(4). Hotkeys for brightness
-      control are supported, CPU speed control and parameter RAM are present but
-      unsupported.

-  

-  
ADB is not present, iic(9) is present but
-    unsupported.

-

-

-

-

-

-
battery(4), cuda(4),
-    nadb(4), nvram(4),
-    obio(4), iic(9)

-

-

-

-
Some features are currently unsupported, like the
-    iic(9) bus, access to parameter RAM and CPU speed
-  control.

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/pnaphy.4 4.html b/static/netbsd/man4/pnaphy.4 4.html
deleted file mode 100644
index 5cf8abed..00000000
--- a/static/netbsd/man4/pnaphy.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
PNAPHY(4)Device Drivers ManualPNAPHY(4)

-

-

-

-
pnaphy — Driver
-    for generic HomePNA PHYs

-

-

-

-
pnaphy* at mii? phy ?

-

-

-

-
The pnaphy is a generic driver for HomePNA
-    “home networking” PHYs which provide Ethernet-like
-    connectivity over standard home telephone lines without interrupting POTS
-    service.

-
HomePNA 1.0 runs at a speed of 1Mb/s.

-
The pnaphy driver currently supports the
-    following devices:

-
    
-  
  • AMD Am79c901 HomePNA 1.0 PHY
    • 
-

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
August 24, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/podulebus.4 4.html b/static/netbsd/man4/podulebus.4 4.html
deleted file mode 100644
index 23470825..00000000
--- a/static/netbsd/man4/podulebus.4 4.html	
+++ /dev/null
@@ -1,126 +0,0 @@
-
-  
-    
-    
-    
-  
-
PODULEBUS(4)Device Drivers ManualPODULEBUS(4)

-

-

-

-
podulebus — Acorn
-    Expansion Card bus driver

-

-

-

-
podulebus0 at root
-    (NetBSD/acorn32)

-

-

-

-
The podulebus driver handles the
-    expansion-card interface in Archimedes machines and their successors. This
-    includes conventional expansion cards, mini expansion cards (as introduced
-    in the A3000), network expansion cards (as introduced in the A3020), DEBI
-    expansion cards (as introduced in the Risc PC), and Mk II network cards
-    (also introduced in the Risc PC). Drivers for individual cards attach as
-    children of the podulebus device.

-
NetBSD includes several
-    machine-independent expansion card device drivers. There are also some
-    device drivers which are specific to
-  NetBSD/acorn32.

-

-

-

-
The following devices are supported by
-    NetBSD.

-

-

-

-  
asc

-  
Acorn AKA30, AKA31, and AKA32 SCSI expansion cards
-      (NetBSD/acorn32).

-  
cosc

-  
MCS Connect32 SCSI interface
-    (NetBSD/acorn32).

-  
csa

-  
Cumana 8-bit SCSI interface (NetBSD/acorn32).

-  
csc

-  
Cumana 16-bit SCSI interface
-    (NetBSD/acorn32).

-  
hcsc

-  
HCCS 8-bit SCSI interface.

-  
oak

-  
Oak SCSI interface.

-  
ptsc

-  
Powertec SCSI interface (NetBSD/acorn32).

-  
sec

-  
Acorn AKA30, AKA31, and AKA32 SCSI expansion cards.

-

-

-

-

-

-  
dtide

-  
D.T. Software IDE controller.

-  
hcide

-  
HCCS IDE controller.

-  
icside

-  
ICS IDE controller (NetBSD/acorn32).

-  
rapide

-  
Yellowstone Educational Solutions RapIDE IDE controller
-      (NetBSD/acorn32).

-  
simide

-  
Simtec IDE controller (NetBSD/acorn32).

-

-

-

-

-

-  
ea

-  
Atomwide A-10xx and Acorn
-      AEH54 Ethernet cards (Ether3).

-  
eb

-  
Atomwide and ANT network-slot and Acorn AEH61 Ethernet cards
-    (EtherB).

-  
ei

-  
Acorn AKA25 Ethernet card (Ether1).

-  
ie

-  
Acorn AKA25 Ethernet card (Ether1)
-      (NetBSD/acorn32).

-  
ne

-  
Various vaguely NE2000-compatible Ethernet cards
-      (NetBSD/acorn32).

-

-

-

-

-

-  
amps

-  
Atomwide multi-port serial interface
-      (NetBSD/acorn32).

-

-

-

-

-

-
acorn32/asc(4),
-    acorn32/cosc(4), acorn32/csc(4),
-    acorn32/ie(4), acorn32/ptsc(4),
-    dtide(4), ea(4),
-    eb(4), ei(4),
-    hcide(4), ne(4),
-    oak(4), sec(4)

-

-

-
-  
-    
-    
-  
-
January 24, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/ppbus.4 4.html b/static/netbsd/man4/ppbus.4 4.html
deleted file mode 100644
index 310b7517..00000000
--- a/static/netbsd/man4/ppbus.4 4.html	
+++ /dev/null
@@ -1,384 +0,0 @@
-
-  
-    
-    
-    
-  
-
PPBUS(4)Device Drivers ManualPPBUS(4)

-

-

-

-
ppbus — Parallel
-    Port Bus system with GPIO

-

-

-

-
ppbus* at atppc?
-  

-  options PPBUS_VERBOSE
-  

-  options PPBUS_DEBUG
-  

-  options DEBUG_1284

-

-  

-  gpio* at ppbus?
-  

-  lpt* at ppbus?
-  

-  plip* at ppbus?
-  

-  pps* at ppbus?

-

-

-

-
The ppbus system provides a uniform,
-    modular, and architecture-independent system for the implementation of
-    drivers to control various parallel devices, and to use different parallel
-    port chip sets.

-

-

-

-
In order to write new drivers or port existing drivers, the
-    ppbus system provides the following facilities:

-
    
-  
  • architecture-independent macros or functions to access parallel ports
    • 
-  
  • mechanism to allow various devices to share the same parallel port
    • 
-  
  • a gpio(4) interface to access the individual pins
    • 
-  
  • a user interface named ppi(4) that allows parallel port
-      access from outside the kernel without conflicting with kernel-in
-    drivers.
    • 
-

-

-

-
The ppbus system has been designed to
-    support the development of standard and non-standard software:

-

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-

-      It uses standard and non-standard parallel port accesses.
Parallel port interface for general I/O
Pulse per second Timing Interface

-

-

-

-
Another approach to the ppbus system is to
-    port existing drivers. Various drivers have already been ported:

-

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
lpt printer driver
plip network interface driver

-
ppbus should let you port any other
-    software even from other operating systems that provide similar
-  services.

-

-

-

-

-
Parallel port chip set support is provided by
-    atppc(4).

-
The ppbus system provides functions and
-    macros to request service from the ppbus including
-    reads, writes, setting of parameters, and bus requests/releases.

-
atppc(4) detects chip set and capabilities and
-    sets up interrupt handling. It makes methods available for use to the
-    ppbus system.

-

-

-

-
The logical parallel port model chosen for the
-    ppbus system is the AT parallel port model.
-    Consequently, for the
-    
-    implementation of ppbus, most of the services
-    provided by ppbus will translate into I/O
-    instructions on actual registers. However, other parallel port
-    implementations may require more than one I/O instruction to do a single
-    logical register operation on data, status and control virtual
-  registers.

-

-

-
The parallel port may operate in the following modes:

-
    
-  
  • Compatible (Centronics -- the standard parallel port mode) mode, output
-      byte
    • 
-  
  • Nibble mode, input 4-bits
    • 
-  
  • Byte (PS/2) mode, input byte
    • 
-  
  • Extended Capability Port (ECP) mode, bidirectional byte
    • 
-  
  • Enhanced Parallel Port (EPP) mode, bidirectional byte
    • 
-

-

-

-

-
This mode defines the protocol used by most PCs to transfer data
-    to a printer. In this mode, data is placed on the port's data lines, the
-    printer status is checked for no errors and that it is not busy, and then a
-    data Strobe is generated by the software to clock the data to the
-  printer.

-
Many I/O controllers have implemented a mode that uses a FIFO
-    buffer to transfer data with the Compatibility mode protocol. This mode is
-    referred to as “Fast Centronics” or “Parallel Port FIFO
-    mode”.

-

-

-

-
The Nibble mode is the most common way to get reverse channel data
-    from a printer or peripheral. When combined with the standard host to
-    printer mode, a bidirectional data channel is created. Inputs are
-    accomplished by reading 4 of the 8 bits of the status register.

-

-

-

-
In this mode, the data register is used either for outputs and
-    inputs. All transfers are 8-bits long. Channel direction must be negotiated
-    when doing IEEE 1248 compliant operations.

-

-

-

-
The ECP protocol was proposed as an advanced mode for
-    communication with printer and scanner type peripherals. Like the EPP
-    protocol, ECP mode provides for a high performance bidirectional
-    communication path between the host adapter and the peripheral.

-
ECP protocol features include:

-
    
-  
  • Run_Length_Encoding (RLE) data compression for host adapters (not
-      supported in these drivers)
    • 
-  
  • FIFO's for both the forward and reverse channels
    • 
-  
  • DMA or programmed I/O for the host register interface.
    • 
-

-

-

-

-
The EPP protocol was originally developed as a means to provide a
-    high performance parallel port link that would still be compatible with the
-    standard parallel port.

-
The EPP mode has two types of cycle: address and data. What makes
-    the difference at hardware level is the strobe of the byte placed on the
-    data lines. Data are strobed with nAutofeed, addresses are strobed with
-    nSelectin signals.

-
A particularity of the ISA implementation of the EPP protocol is
-    that an EPP cycle fits in an ISA cycle. In this fashion, parallel port
-    peripherals can operate at close to the same performance levels as an
-    equivalent ISA plug-in card.

-
At software level, you may implement the protocol you wish, using
-    data and address cycles as you want. This is for the IEEE 1284 compatible
-    part. Peripheral vendors may implement protocol handshake with the following
-    status lines: PError, nFault and Select. Try to know how these lines toggle
-    with your peripheral, allowing the peripheral to request more data, stop the
-    transfer and so on.

-
At any time, the peripheral may interrupt the host with the nAck
-    signal without disturbing the current transfer.

-

-

-

-
Some manufacturers, like SMC, have implemented chip sets that
-    support mixed modes. With such chip sets, mode switching is available at any
-    time by accessing the extended control register. All ECP-capable chip sets
-    can switch between standard, byte, fast centronics, and ECP modes. Some ECP
-    chip sets also support switching to EPP mode.

-

-

-

-

-

-

-
This standard is also named “IEEE Standard Signaling Method
-    for a Bidirectional Parallel Peripheral Interface for Personal
-    Computers”. It defines a signaling method for asynchronous, fully
-    interlocked, bidirectional parallel communications between hosts and
-    printers or other peripherals. It also specifies a format for a peripheral
-    identification string and a method of returning this string to the host.

-
This standard is architecture independent and only specifies
-    dialog handshake at signal level. One should refer to architecture specific
-    documentation in order to manipulate machine dependent registers, mapped
-    memory or other methods to control these signals.

-
The IEEE 1284 protocol is fully oriented with all supported
-    parallel port modes. The computer acts as master and the peripheral as
-    slave.

-
Any transfer is defined as a finite state automate. It allows
-    software to properly manage the fully interlocked scheme of the signaling
-    method. The compatible mode is supported “as is” without any
-    negotiation because it is the default, backward-compatible transfer mode.
-    Any other mode must be firstly negotiated by the host to check it is
-    supported by the peripheral, then to enter one of the forward idle
-  states.

-
At any time, the slave may want to send data to the host. The host
-    must negotiate to permit the peripheral to complete the transfer. Interrupt
-    lines may be dedicated to the requesting signals to prevent time consuming
-    polling methods.

-
If the host accepts the transfer, it must firstly negotiate the
-    reverse mode and then start the transfer. At any time during reverse
-    transfer, the host may terminate the transfer or the slave may drive wires
-    to signal that no more data is available.

-

-

-

-
IEEE 1284 Standard support has been implemented at the top of the
-    ppbus system as a set of procedures that perform
-    high level functions like negotiation, termination, transfer in any mode
-    without bothering you with low level characteristics of the standard.

-
IEEE 1284 interacts with the ppbus system
-    as little as possible. That means you still have to request the
-    ppbus when you want to access it, and of course,
-    release it when finished.

-

-

-

-

-

-

-
First, there is the
-    
-    layer, the lowest of the ppbus system. It provides
-    chip set abstraction through a set of low level functions that maps the
-    logical model to the underlying hardware.

-
Secondly, there is the
-     layer that
-    provides functions to:

-
    
-  
  1. share the parallel port bus among the daisy-chain like connected
-    devices
    2. 
-  
  2. manage devices linked to ppbus
    3. 
-  
  3. propose an arch-independent interface to access the hardware layer.
    4. 
-

-
Finally, the
-     layer
-    represents the traditional device drivers such as lpt(4)
-    which now use an abstraction instead of real hardware.

-

-

-

-
Operating modes are differentiated at various
-    ppbus system layers. There is a difference between a
-    
-    and a
-    . A
-    chip set may have a combination of capabilities, but at any one time the
-    ppbus system operates in a single mode.

-
Nibble mode is a
-     mode: the
-    actual chip set would be in standard mode and the driver would change its
-    behavior to drive the right lines on the parallel port.

-
Each child device of ppbus must set its
-    operating mode and other parameters whenever it requests and gets access to
-    its parent ppbus.

-

-

-

-

-

-

-
ppbus attachment tries to detect any PnP
-    parallel peripheral (according to Plug and Play Parallel
-    Port Devices draft from (c)1993-4 Microsoft Corporation) then probes
-    and attaches known device drivers.

-
During probe, device drivers should request the
-    ppbus and try to determine if the right capabilities
-    are present in the system.

-

-

-

-
ppbus reservation via a bus request is
-    mandatory not to corrupt I/O of other devices. For example, when the
-    lpt(4) device is opened, the bus will be
-    “allocated” to the device driver and attempts to reserve the
-    bus for another device will fail until the lpt(4) driver
-    releases the bus.

-
Child devices can also register interrupt handlers to be called
-    when a hardware interrupt occurs. In order to attach a handler, drivers must
-    own the bus. Drivers should have interrupt handlers that check to see if the
-    device still owns the bus when they are called and/or ensure that these
-    handlers are removed whenever the device does not own the bus.

-

-

-

-
Micro-sequences are a general purpose mechanism
-    to allow fast low-level manipulation of the parallel port. Micro-sequences
-    may be used to do either standard (in IEEE 1284 modes) or non-standard
-    transfers. The philosophy of micro-sequences is to avoid the overhead of the
-    ppbus layer for a sequence of operations and do most
-    of the job at the chip set level.

-
A micro-sequence is an array of opcodes and parameters. Each
-    opcode codes an operation (opcodes are described in
-    microseq(9)). Standard I/O operations are implemented at
-    ppbus level whereas basic I/O operations and microseq language are coded at
-    adapter level for efficiency.

-

-

-

-
Pins 1 through 17 of the parallel port can be controlled through
-    the gpio(4) interface, pins 18 through 25 are hardwired to
-    ground. Pins 10 through 13 and pin 15 are input pins, the others are output
-    pins. Some of the pins are inverted by the hardware, the values read or
-    written are adjusted accordingly. Note that the gpio(4)
-    interface starts at 0 when numbering pins.

-

-

-

-

-
atppc(4), gpio(4),
-    lpt(4), plip(4),
-    ppi(4), microseq(9)

-

-

-

-
The ppbus system first appeared in
-    FreeBSD 3.0.

-

-

-

-
This manual page is based on the FreeBSD
-    ppbus manual page. The information has been updated
-    for the NetBSD port by Gary Thorpe.

-

-

-

-
The ppbus framework is still experimental
-    and not enabled by default yet.

-

-

-
-  
-    
-    
-  
-
August 19, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/ppi.4 4.html b/static/netbsd/man4/ppi.4 4.html
deleted file mode 100644
index e7f0dcd2..00000000
--- a/static/netbsd/man4/ppi.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
PPI(4)Device Drivers ManualPPI(4)

-

-

-

-
ppi — user-space
-    interface to ppbus parallel port

-

-

-

-
ppi* at ppbus?

-
Minor numbering: Unit numbers correspond directly to
-    ppbus(4) numbers.

-

-

-

-
The ppi driver provides a convenient means
-    for user applications to manipulate the state of the parallel port, enabling
-    easy low-speed I/O operations without the security problems inherent with
-    the use of the /dev/io interface.

-
The programming interface is described in
-    ppi(9).

-

-

-

-
atppc(4), io(4),
-    ppbus(4), ppi(9)

-

-

-

-
ppi originally appeared in
-    FreeBSD.

-

-

-

-
This manual page is based on the FreeBSD
-    ppi manual page and was updated for the
-    NetBSD port by Gary
-  Thorpe.

-

-

-

-
The inverse sense of signals is confusing.

-
The ioctl() interface is slow, and there
-    is no way (yet) to chain multiple operations together.

-
The headers required for user applications are not installed as
-    part of the standard system.

-

-

-
-  
-    
-    
-  
-
December 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/ppp.4 4.html b/static/netbsd/man4/ppp.4 4.html
deleted file mode 100644
index 292d2c3f..00000000
--- a/static/netbsd/man4/ppp.4 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
PPP(4)Device Drivers ManualPPP(4)

-

-

-

-
ppp — point to
-    point protocol network interface

-

-

-

-
options PPP_BSDCOMP
-  

-  options PPP_DEFLATE
-  

-  options PPP_FILTER

-

-  

-  pseudo-device ppp

-

-

-

-
The ppp interface allows serial lines to
-    be used as network interfaces using the
-     (PPP). The ppp interface can use
-    various types of compression and has many features over the SLIP protocol
-    used by the sl(4) interface.

-
Supported options are:

-

-  
options PPP_BSDCOMP

-  
Enable support for BSD-compress (`bsdcomp') compression in ppp.

-  
options PPP_DEFLATE

-  
Enable support for deflate compression in ppp.

-  
options PPP_FILTER

-  
This option turns on pcap(3) based filtering for ppp
-      connections. This option is used by pppd(8) which needs
-      to be compiled with
-      
-      defined (the current default).

-

-

-

-

-

-  
ppp%d: af%d not supported.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-

-

-

-

-
inet(4), intro(4),
-    sl(4), pppd(8),
-    pppstats(8)

-
The Point-to-Point Protocol
-    (PPP), RFC 1661, July
-    1994.

-

-

-

-
The ppp device appeared in
-    NetBSD 1.0.

-

-

-

-
Currently, only the ip(4) and
-    ip6(4) protocols are supported.

-

-

-
-  
-    
-    
-  
-
January 10, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/pppoe.4 3.html b/static/netbsd/man4/pppoe.4 3.html
deleted file mode 100644
index 9601ddc3..00000000
--- a/static/netbsd/man4/pppoe.4 3.html	
+++ /dev/null
@@ -1,249 +0,0 @@
-
-  
-    
-    
-    
-  
-
PPPOE(4)Device Drivers ManualPPPOE(4)

-

-

-

-
pppoe — PPP over
-    Ethernet protocol network interface

-

-

-

-
pseudo-device pppoe

-

-

-

-
The pppoe interface encapsulates
-     packets inside Ethernet frames as defined by
-    RFC2516.

-
This is often used to connect a router via a DSL modem to an
-    access concentrator. The pppoe interface does not by
-    itself transmit or receive frames, but needs an Ethernet interface to do so.
-    This Ethernet interface is connected to the pppoe
-    interface via pppoectl(8). The Ethernet interface needs to
-    be marked UP, but does not need to have an IP address.

-
There are two basic modes of operation, controlled via the
-    link1 switch. The default mode, link1
-    not being set, tries to keep the configured session open all the time. If
-    the session is disconnected, a new connection attempt is started
-    immediately. The “dial on demand” mode, selected by setting
-    link1, only establishes a connection when data is being
-    sent to the interface.

-
If the kernel is compiled with options
-    PPPOE_SERVER, there are two modes of connection,
-    controlled via the link0 switch. The default mode,
-    link0 not being set, is client mode. The “PPPoE
-    server” mode, selected by setting link0, is to wait
-    for incoming PPPoE session.

-
Before a pppoe interface is usable, it
-    needs to be configured. The following steps are necessary:

-
    
-  
  • Create the interface.
    • 
-  
  • Connect an Ethernet interface. This interface is used for the physical
-      communication. As noted above it must be marked UP, but need not have an
-      IP address.
    • 
-  
  • Configure authentication. The PPP session needs to identify the client to
-      the peer. For more details on the available options see
-      pppoectl(8).
    • 
-

-
This all is typically accomplished using an
-    /etc/ifconfig.pppoe0 file.

-

-

-
If you are using a pppoe interface, you
-    will have an unusually low MTU for today's Internet. Combined with a lot of
-    misconfigured sites (host using path MTU discovery behind a router blocking
-    all ICMP traffic) this will often cause problems. Connections to these
-    servers will only work if your system advertises the right MSS in the TCP
-    three way handshake. To get the right MSS, you need to set

-

-
# Obey interface MTUs when calculating MSS
-net.inet.tcp.mss_ifmtu=1

-

-
in your /etc/sysctl.conf file. This causes
-    the calculated MSS to be based on the MTU of the interface via which the
-    packet is sent. This is always the right value if you are sure the answer to
-    this packet will be received on the same interface (i.e., you only have one
-    interface connected to the Internet.)

-
Unfortunately this sysctl does not fix the MSS
-    advertised by hosts in the network behind a pppoe
-    connected router. To fix this you need
-    ,
-    explained below.

-

-

-

-
Some systems behind misconfigured firewalls try to use
-    Path-MTU-Discovery, while their firewall blocks all ICMP messages. This is
-    an illegal, but not uncommon, setup. Typically you will have no chance to
-    fix this (remote, outside of your control) setup. And sometimes you will
-    have to use such remote systems (to download data from them, or to do your
-    online banking).

-
Without special care systems as described above will not be able
-    to send larger chunks of data to a system connected via
-    pppoe. But there is a workaround (some may call it
-    cheating): pretend to not be able to handle large packets, by sending a
-    small MSS (maximum segment size) option during initial TCP handshake.

-
For connections originating from your
-    pppoe connected machines, this is accomplished by
-    setting the sysctl variable net.inet.tcp.mss_ifmtu
-    to 1 (see above). For connections originating from systems behind your
-    pppoe router, you need to set the
-    mssclamp options in your NAT rules, like in this
-    example of /etc/ipnat.conf:

-

-
map pppoe0 192.168.1.0/24 -> 0/32 portmap tcp/udp 44000:49999 mssclamp 1440
-map pppoe0 192.168.1.0/24 -> 0/32 mssclamp 1440

-

-
If you do not use NAT, you need to set up a 1:1 NAT rule, just to
-    get the clamping:

-

-
map pppoe0 x.x.x.x/24 -> 0/0 mssclamp 1440

-

-
The above examples assume a MTU of 1492 bytes. If the
-    MTU on your PPPoE connection is smaller use the MTU - 52 bytes for clamping
-    e.g. 1408 bytes for a MTU of 1460 bytes.
-    : The
-    theoretically correct value for the above example would be 1452 bytes (it
-    accounts for the smaller PPPoE MTU, the TCP header and the maximum of 0x40
-    bytes of TCP options) but it seems to not be sufficient in some cases.
-    Experiments conducted by various people have shown that clamping to the MSS
-    values suggested above works best.

-

-

-

-

-
A typical /etc/ifconfig.pppoe0 file looks
-    like this:

-

-
create
-! /sbin/ifconfig ne0 up
-! /sbin/pppoectl -e ne0 $int
-! /sbin/pppoectl $int myauthproto=pap myauthname=testcaller myauthsecret=donttell
-inet 0.0.0.0 0.0.0.1 netmask 0xffffffff
-#! /sbin/route add default -iface 0.0.0.1
-up

-

-The commented out call to route(8) may be omitted and the
-  route added in the ip-up script called by ifwatchd(8) when
-  the real IP address is known. This is easy in the “connect
-  always” mode (link1 not set), but hard to accomplish in the
-  “dial on demand” mode (link1 set). In the latter case adding an
-  iface route is an easy workaround.
-
The pppoe interfaces operate completely
-    inside the kernel, without any userland support. Because of this, a special
-    daemon is used to fire ip-up or down scripts to execute arbitrary code when
-    the PPP session is established and addresses of the interface become
-    available. To enable the usage of /etc/ppp/ip-up and
-    /etc/ppp/ip-down for this purpose, simply add

-

-
ifwatchd=YES

-

-
to /etc/rc.conf. See
-    ifwatchd(8) for details and parameters passed to these
-    scripts.

-
Since this is a PPP interface, the addresses assigned to the
-    interface may change during PPP negotiation. There is no fine grained
-    control available for deciding which addresses are acceptable and which are
-    not. For the local side and the remote address there is exactly one choice:
-    hard coded address or wildcard. If a real address is assigned to one side of
-    the connection, PPP negotiation will only agree to exactly this address. If
-    one side is wildcarded, every address suggested by the peer will be
-    accepted.

-
To wildcard the local address set it to 0.0.0.0, to wildcard the
-    remote address set it to 0.0.0.1. Wildcarding is not available (nor
-    necessary) for IPv6 operation.

-

-

-

-
A pppoe enabled kernel will not interfere
-    with other PPPoE implementations running on the same
-    machine. Under special circumstances (details below) this is not desirable,
-    so the pppoe driver can be told to kill all unknown
-    PPPoE sessions received by the Ethernet interface
-    used for a configured pppoe interface. To do this,
-    add the following to your kernel config file:

-

-
options
-  PPPOE_TERM_UNKNOWN_SESSIONS

-
and set the value of sysctl(7) variable
-    net.pppoe.term_unknown to true.

-
Note that this will break all userland
-    PPPoE implementations using the same Ethernet
-    interface!

-
This option is only useful if you have a static IP address
-    assigned and your ISP does not use LCP echo requests to monitor the link
-    status. After a crash or power failure the peer device still tries to send
-    data to the no longer active session on your computer, and might refuse to
-    reestablish a new connection, because there already is an open session. On
-    receipt of such packets, the pppoe driver with this
-    option set will send a PADT packet (request to terminate the session). The
-    peer will immediately disconnect the orphaned session and allow a new one to
-    be established.

-
To enable pppoe server support in the
-    kernel, use

-

-
options PPPOE_SERVER

-
As described above, this allows pppoe
-    interfaces to be created and configured for incoming connections by setting
-    the “link0” flag with
-    ifconfig(8).

-

-

-

-
ifwatchd(8), pppoectl(8)

-
A Method for Transmitting PPP
-    Over Ethernet (PPPoE), RFC,
-    2516, February
-    1999.

-
Accommodating a Maximum Transit
-    Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point
-    Protocol over Ethernet (PPPoE), RFC,
-    4638, September
-    2006.

-

-

-

-
The pppoe device appeared in
-    NetBSD 1.6.

-

-

-

-
The original PPPoE standard, RFC2516,
-    requires a maximal MTU of 1492 octets. This value is the maximum
-    conservative value possible, based on the PPPoE header size and the minimum
-    frame size Ethernet interfaces are required to support.

-
In practice most modern Ethernet interfaces support bigger frames,
-    and many PPPoE services allow the use of (slightly) larger MTUs, to avoid
-    the problems described above.

-
This implementation allows MTU values as large as possible with
-    the actual MTU of the used Ethernet interface and conforms to the
-    enhancement to the PPPoE standard, RFC4638, to
-    request the use of this larger MTU value with the PPPoE server.

-

-

-

-
When using the wildcard address 0.0.0.0 (as described above) it is
-    important to specify the proper
-    “netmask” to
-    ifconfig(8), in most setups
-    “0xffffffff”. If the netmask is
-    unspecified, it will be set to 8 when 0.0.0.0 is configured to the
-    interface, and it will persist after negotiation.

-

-

-
-  
-    
-    
-  
-
August 7, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/pseye.4 4.html b/static/netbsd/man4/pseye.4 4.html
deleted file mode 100644
index 6ceba14d..00000000
--- a/static/netbsd/man4/pseye.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSEYE(4)Device Drivers ManualPSEYE(4)

-

-

-

-
pseye — Sony
-    PlayStation Eye webcam device driver

-

-

-

-
pseye* at uhub?
-  

-  video* at videobus?

-

-

-

-
The pseye driver provides support for the
-    Sony PlayStation Eye USB webcam (model SLEH-00201).

-
This webcam supports 640x480 YUYV capture at 30 frames per second,
-    which requires a hi-speed USB host controller (such as
-    ehci(4)) to function properly.

-
The Sony PlayStation Eye device also has a separate audio
-    interface, which is supported by the uaudio(4) device
-    driver.

-

-

-

-
ehci(4), uaudio(4),
-    video(4)

-

-

-

-
The pseye device driver appeared in
-    NetBSD 5.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-

-
The only mode supported by the pseye
-    driver is 640x480 YUYV at 30fps.

-

-

-
-  
-    
-    
-  
-
September 6, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/ptcd.4 4.html b/static/netbsd/man4/ptcd.4 4.html
deleted file mode 100644
index cc7c4df9..00000000
--- a/static/netbsd/man4/ptcd.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
PTCD(4)Device Drivers ManualPTCD(4)

-

-

-

-
ptcd — support for
-    the Protech PS3100 cash drawer port

-

-

-

-
ptcd* at isa? port 0x48d
-  

-  gpio* at ptcd?

-

-

-

-
The ptcd driver controls the cash drawer
-    port of the Protech PS3100 point of sale terminal using the GPIO
-  subsystem.

-
ptcd provides a GPIO device with two pins:
-    pin 0 is used to control the cash drawer while pin 1 can be used to read the
-    current state of the sense input pin. A logical 0 means the cash drawer is
-    closed, a logical 1 means the cash drawer is open.

-
To open the cash drawer, set pin 0 to logical 1 for a short period
-    of time (e.g. < 1 sec) and then reset the pin to logical 0.

-

-

-

-
gpio(4), ibmcd(4),
-    gpioctl(8)

-

-

-

-
The ptcd driver first appeared in
-    NetBSD 6.1.

-

-

-

-
The ptcd driver was written by
-    Marc Balmer
-    <marc@msys.ch>.

-

-

-

-
As it is not possible to detect the hardware at runtime, this
-    driver, when enabled, will always attach. Only enable it in your kernel
-    configuration if you have the proper hardware.

-

-

-
-  
-    
-    
-  
-
December 17, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/ptm.4 4.html b/static/netbsd/man4/ptm.4 4.html
deleted file mode 100644
index 10fe5b3b..00000000
--- a/static/netbsd/man4/ptm.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
PTM(4)Device Drivers ManualPTM(4)

-

-

-

-
ptm —
-    pseudo-terminal multiplexor device

-

-

-

-
pseudo-device pty

-

-

-

-
The ptm driver is the backend for the
-    /dev/ptm device. It supports three
-    ioctl(2)s. The first is
-    TIOCPTMGET, which allocates a free pseudo-terminal
-    device, sets its user ID to the calling user, revoke(2)s
-    it, and returns the opened file descriptors for both the master and the
-    slave pseudo-terminal device to the caller in a struct
-    ptmget. This struct has the following content:

-

-
struct ptmget {
-        int     cfd;
-        int     sfd;
-        char    cn[PATH_MAX];
-        char    sn[PATH_MAX];
-};

-

-
where cfd and sfd
-    contain the master resp. slave device's file descriptor and
-    cn and sn the corresponding
-    paths in the file system.

-
The /dev/ptmx device supports two more
-    ioctl(2)s, TIOCGRANTPT, which is
-    used by grantpt(3), TIOCPTSNAME,
-    which is used by ptsname(3).

-
The ptm device is included with the
-    pseudo-device pty(4). It can be disabled by adding
-    “options NO_DEV_PTM” to the kernel
-    configuration.

-

-

-

-

-  
/dev/ptm

-  
ptm access device

-  
/dev/ptmx

-  
ptm cloning device, used to implement Unix98
-    ptys

-

-

-

-

-
grantpt(3), openpty(3),
-    posix_openpt(3), ptsname(3),
-    unlockpt(3), pty(4)

-

-

-

-
The /dev/ptm device appeared in
-    OpenBSD 3.5 and was ported to
-    NetBSD 3.0.

-

-

-
-  
-    
-    
-  
-
November 30, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/pty.4 3.html b/static/netbsd/man4/pty.4 3.html
deleted file mode 100644
index ff6ee275..00000000
--- a/static/netbsd/man4/pty.4 3.html	
+++ /dev/null
@@ -1,183 +0,0 @@
-
-  
-    
-    
-    
-  
-
PTY(4)Device Drivers ManualPTY(4)

-

-

-

-
pty — pseudo
-    terminal driver

-

-

-

-
pseudo-device pty

-

-

-

-
The pty driver provides support for a
-    device-pair termed a
-    . A pseudo terminal is a pair of character devices, a
-    
-    device and a
-    
-    device. The slave device provides to a process an interface identical to
-    that described in tty(4). However, whereas all other
-    devices which provide the interface described in tty(4)
-    have a hardware device of some sort behind them, the slave device has,
-    instead, another process manipulating it through the master half of the
-    pseudo terminal. That is, anything written on the master device is given to
-    the slave device as input and anything written on the slave device is
-    presented as input on the master device.

-
Pseudo terminal pairs are allocated on as-needed
-    basis, maximum number of them is controlled via
-    
-    sysctl (defaults to 992).

-
The following ioctl(2) calls apply only to
-    pseudo terminals:

-

-  

-  
Enable/disable “external processing”. This affects delivery
-      of TIOCPKT_IOCTL packets. External processing is
-      enabled by specifying (by reference) a nonzero int
-      parameter and disabled by specifying (by reference) a zero
-      int parameter.
-    
TIOCEXT is reset to its default
-        (disabled) when the slave closes the pty.

-  

-  

-  
Stops output to a terminal (e.g. like typing
-      ‘^S’). Takes no parameter.

-  

-  
Restarts output (stopped by TIOCSTOP or by typing
-      ‘^S’). Takes no parameter.

-  

-  
Enable/disable
-      
-      mode. Packet mode is enabled by specifying (by reference) a nonzero
-      int parameter and disabled by specifying (by
-      reference) a zero int parameter. When applied to the
-      master side of a pseudo terminal, each subsequent
-      read(2) from the terminal will return data written on
-      the slave part of the pseudo terminal preceded by a zero byte
-      (symbolically defined as TIOCPKT_DATA), or a
-      single byte reflecting control status information. In the latter case, the
-      byte is an inclusive-or of zero or more of the bits:
-    

-      

-      
whenever the read queue for the terminal is flushed.

-      

-      
whenever the write queue for the terminal is flushed.

-      

-      
whenever output to the terminal is stopped a la
-          ‘^S’.

-      

-      
whenever output to the terminal is restarted.

-      

-      
whenever
-          
-          is ‘^S’ and
-          
-          is ‘^Q’.

-      

-      
whenever the start and stop characters are not
-          ‘^S/^Q’.
-        
While this mode is in use, the presence of control status
-            information to be read from the master side may be detected by a
-            select(2) for exceptional conditions.

-        
This mode is used by rlogin(1) and
-            rlogind(8) to implement a remote-echoed, locally
-            ‘^S/^Q’ flow-controlled remote
-            login with proper back-flushing of output; it can be used by other
-            similar programs.

-      

-      

-      
When this bit is set, the slave has changed the
-          termios(4) structure (TTY state), and the remainder
-          of the data read from the master side of the
-          pty is the new termios(4)
-          structure. The master side of the pty can also
-          use tcgetattr(3) to read the new
-          termios(4) structure.
-        
The master will not read packets with the bit
-            TIOCPKT_IOCTL set until it has activated
-            “external processing” using
-            TIOCEXT.

-        
This is used by telnetd(8) to implement
-            TELNET "line mode" - it allows the
-            telnetd(8) to detect tty(4)
-            state changes by the slave, and negotiate the appropriate TELNET
-            protocol equivalents with the remote peer.

-      

-    

-  

-  

-  
Enable/disable a mode that allows a small number of simple user
-      ioctl(2) commands to be passed through the
-      pseudo-terminal, using a protocol similar to that of
-      TIOCPKT. The TIOCUCNTL and
-      TIOCPKT modes are mutually exclusive. This mode is
-      enabled from the master side of a pseudo terminal by specifying (by
-      reference) a nonzero int parameter and disabled by
-      specifying (by reference) a zero int parameter. Each
-      subsequent read(2) from the master side will return data
-      written on the slave part of the pseudo terminal preceded by a zero byte,
-      or a single byte reflecting a user control operation on the slave side. A
-      user control command consists of a special ioctl(2)
-      operation with no data; the command is given as
-      UIOCCMD(n), where n is a
-      number in the range 1-255. The operation value n
-      will be received as a single byte on the next read(2)
-      from the master side. The ioctl(2)
-      UIOCCMD(0) is a no-op that may be used to probe
-      for the existence of this facility. As with
-      TIOCPKT mode, command operations may be detected
-      with a select(2) for exceptional conditions.

-  

-  
A mode for the master half of a pseudo terminal, independent of
-      TIOCPKT. This mode causes input to the pseudo
-      terminal to be flow controlled and not input edited (regardless of the
-      terminal mode). Each write to the control terminal produces a record
-      boundary for the process reading the terminal. In normal usage, a write of
-      data is like the data typed as a line on the terminal; a write of 0 bytes
-      is like typing an end-of-file character.
-      TIOCREMOTE can be used when doing remote line
-      editing in a window manager, or whenever flow controlled input is
-      required.

-

-

-

-

-

-  
/dev/pty[p-zP-T][0-9a-zA-Z]

-  
master pseudo terminals

-  
/dev/tty[p-zP-T][0-9a-zA-Z]

-  
slave pseudo terminals

-

-

-

-

-
None.

-

-

-

-
ioctl(2), read(2),
-    select(2), write(2),
-    openpty(3), tty(4)

-

-

-

-
The pty driver appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
November 30, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/puc.4 4.html b/static/netbsd/man4/puc.4 4.html
deleted file mode 100644
index 89cc3abb..00000000
--- a/static/netbsd/man4/puc.4 4.html	
+++ /dev/null
@@ -1,388 +0,0 @@
-
-  
-    
-    
-    
-  
-
PUC(4)Device Drivers ManualPUC(4)

-

-

-

-
puc — PCI
-    “universal” communications card driver

-

-

-

-
puc* at pci? dev ? function ?
-  

-  com* at puc? port ?
-  

-  lpt* at puc? port ?

-

-

-

-
The puc driver provides support for PCI
-    communications cards containing simple communications ports, such as
-    NS16550-family (com) serial ports and standard
-    PC-like (lpt) parallel ports. The driver is called
-    “universal” because the interfaces to these devices aren't
-    nearly as well defined and standard as they should be.

-
The driver currently supports the following cards:

-

-

-

-  
ADDI-DATA APCI-7800 (8 port serial)

-  
 

-  
Actiontec 56K PCI Master

-  
 

-  
Advantech PCI-1604UP (2 port serial)

-  
 

-  
Advantech PCI-1610 (4 port serial)

-  
 

-  
Advantech PCI-1612 (4 port serial)

-  
 

-  
Advantech PCI-1620 (8 port serial)

-  
 

-  
ASIX AX9910 (4 port serial)

-  
 

-  
Avlab Low Profile PCI 4S Quartet (4 port serial)

-  
 

-  
Avlab Low Profile PCI 4 Serial (4 port serial)

-  
 

-  
Avlab PCI 2S (2 port serial)

-  
 

-  
Boca Research Turbo Serial 654 (4 port serial)

-  
 

-  
Boca Research Turbo Serial 658 (8 port serial)

-  
 

-  
Brainboxes UC card range

-  
 

-  
Brainboxes UP card range

-  
 

-  
Brainboxes PX card range

-  
 

-  
Chase Research / Perle PCI-FAST4 (4 port serial)

-  
 

-  
Chase Research / Perle PCI-FAST8 (8 port serial)

-  
 

-  
Comtrol RocketPort 550/4 series (4 port serial)

-  
 

-  
Comtrol RocketPort 550/8 series (8 port serial)

-  
 

-  
Comtrol RocketPort 550/16 series (16 port serial)

-  
 

-  
Decision Computer Inc PCCOM PCI 2 Port (2 port serial)

-  
 

-  
Decision Computer Inc PCCOM PCI 4 Port (4 port serial)

-  
 

-  
Decision Computer Inc PCCOM PCI 8 Port (8 port serial)

-  
 

-  
Digi International Digi Neo 4 (4 port serial)

-  
 

-  
Digi International Digi Neo 8 (8 port serial)

-  
 

-  
Dolphin Peripherals 4014 (dual parallel)

-  
 

-  
Dolphin Peripherals 4035 (dual serial)

-  
 

-  
Dolphin Peripherals 4036 (dual serial)

-  
 

-  
EXAR XR17D152 (2 port serial)

-  
 

-  
EXAR XR17D154 (4 port serial)

-  
 

-  
EXAR XR17D158 (8 port serial)

-  
 

-  
EXAR XR17V354 (4 port serial)

-  
 

-  
EXAR XR17V358 (8 port serial)

-  
 

-  
Exsys EX-41098 (4 port serial)

-  
 

-  
IBM 4810 SurePOS 300 Series SCC (4 port serial)

-  
 

-  
InnoSys Keyspan SX Pro (4 port serial)

-  
 

-  
IntaShield IS-100 (single serial)

-  
 

-  
IntaShield IS-200 (dual serial)

-  
 

-  
IntaShield IS-300 (single serial only)

-  
 

-  
IntaShield IS-400 (4 port serial)

-  
 

-  
IntaShield IX-100 (single serial)

-  
 

-  
IntaShield IX-200 (dual serial)

-  
 

-  
IntaShield IX-400 (4 port serial)

-  
 

-  
Intel chipset internal Serial over LAN

-  
 

-  
I-O DATA RSA-PCI (2 port serial)

-  
 

-  
I-O DATA RSA-PCI2 (2 port serial)

-  
 

-  
I-O DATA RSA-PCI2/P4 (4 port serial)

-  
 

-  
I-O DATA RSA-PCI2/P8 (8 port serial)

-  
 

-  
Lava Computers 2SP-PCI (single parallel)

-  
 

-  
Lava Computers Octopus (8 port serial)

-  
 

-  
Lava Computers Quatro-PCI (4 port serial)

-  
 

-  
Lava Computers dual serial

-  
 

-  
Lava Computers SSERIAL-PCI (single serial)

-  
 

-  
Middle Digital, Inc. Weasel serial port

-  
 

-  
Moxa Technologies SmartIO C104H/PCI (4 port serial)

-  
 

-  
Moxa Technologies SmartIO C168EL-A/PCIe (8 port serial)

-  
 

-  
Moxa Technologies SmartIO C168EL/PCIe (8 port serial)

-  
 

-  
Moxa Technologies SmartIO C168H/PCI (8 port serial)

-  
 

-  
Moxa Technologies SmartIO C168U/PCI (8 port serial)

-  
 

-  
Moxa Technologies SmartIO CP-114/PCI (4 port serial)

-  
 

-  
Moxa Technologies SmartIO CP-102/PCI (2 port serial)

-  
 

-  
Moxa Technologies SmartIO CP-104-EL/PCIe (4 port serial)

-  
 

-  
Moxa Technologies SmartIO CP-104-V2/PCI (4 port serial)

-  
 

-  
Moxa Technologies SmartIO CP-104/PCI (4 port serial)

-  
 

-  
Multi-Tech ISI5634PCI/4 (4 port serial)

-  
 

-  
NEC PK-UG-X001 K56flex PCI Modem

-  
 

-  
NEC PK-UG-X008

-  
 

-  
NetMos 1P PCI (single parallel)

-  
 

-  
NetMos 2S1P PCI 16C650 (dual serial and single parallel)

-  
 

-  
NetMos 4S1P PCI NM9845 (4 port serial and single parallel)

-  
 

-  
NetMos NM9805 1284 (single parallel)

-  
 

-  
NetMos NM9815 Dual 1284 (dual parallel)

-  
 

-  
NetMos NM9835 series (up to dual serial and single parallel)

-  
 

-  
NetMos NM9845 series (up to 6 serial and 1 parallel)

-  
 

-  
NetMos NM9855 series (up to 4 serial and 1 parallel)

-  
 

-  
NetMos NM9865 series (up to 4 serial and 2 parallel)

-  
 

-  
NetMos NM9900 PCIe (4 port or 8 port serial)

-  
 

-  
NetMos NM9901 PCIe (1 serial or 1 parallel)

-  
 

-  
NetMos NM9904 PCIe (4 port serial)

-  
 

-  
NetMos NM9912 PCIe (2 serial or 1 parallel)

-  
 

-  
NetMos NM9922 PCIe (2 port serial)

-  
 

-  
Oxford Semiconductor OX16PCI952 (dual serial and single parallel)

-  
 

-  
Oxford Semiconductor OX16PCI954 (4 port serial)

-  
 

-  
Oxford Semiconductor OX16PCI958 (8 port serial)

-  
 

-  
Oxford Semiconductor OXPCIe952 (2 port serial, legacy mode)

-  
 

-  
Oxford Semiconductor OXPCIe954 (4 port serial)

-  
 

-  
Oxford Semiconductor OXPCIe958 (8 port serial)

-  
 

-  
Oxford Semiconductor OXmPCI952 (2 port serial)

-  
 

-  
Oxford Semiconductor Exsys EX-41098 (4 port serial)

-  
 

-  
Perle Systems PCI-RAS 4 modem ports

-  
 

-  
Perle Systems PCI-RAS 8 modem ports

-  
 

-  
Perle Systems PCI-RASV92 4 modem ports

-  
 

-  
Perle Systems PCI-RASV92 8 modem ports

-  
 

-  
SIIG Cyber 2P1S PCI series (dual parallel and single serial)

-  
 

-  
SIIG Cyber 2S1P PCI series (dual serial and single parallel)

-  
 

-  
SIIG Cyber 4 PCI 16550 (4 port serial)

-  
 

-  
SIIG Cyber 4S PCI series (quad serial)

-  
 

-  
SIIG Cyber I/O PCI series (single serial and single parallel)

-  
 

-  
SIIG Cyber Parallel Dual PCI series (dual parallel)

-  
 

-  
SIIG Cyber Parallel PCI series (single parallel)

-  
 

-  
SIIG Cyber Serial Dual PCI series (dual serial)

-  
 

-  
SIIG Cyber Serial PCI series (single serial)

-  
 

-  
SIIG PS8000 PCI 8S series (8 port serial)

-  
 

-  
SUNIX 400x (1 port parallel)

-  
 

-  
SUNIX 401x (2 port parallel)

-  
 

-  
SUNIX 402x (1 port serial)

-  
 

-  
SUNIX 403x (2 port serial)

-  
 

-  
SUNIX 405x (4 port serial)

-  
 

-  
SUNIX 406x (8 port serial)

-  
 

-  
SUNIX 407x (2 port serial and 1 port parallel)

-  
 

-  
SUNIX 408x (2 port serial and 2 port parallel)

-  
 

-  
SUNIX 409x (4 port serial and 2 port parallel)

-  
 

-  
SUNIX 5008 (1 port parallel)

-  
 

-  
SUNIX 5016 (8 port serial)

-  
 

-  
SUNIX 5027 (1 port serial)

-  
 

-  
SUNIX 5037 (2 port serial)

-  
 

-  
SUNIX 5056 (4 port serial)

-  
 

-  
SUNIX 5066 (8 port serial)

-  
 

-  
SUNIX 5069 (1 port serial and 1 port parallel)

-  
 

-  
SUNIX 5079 (2 port serial and 1 port parallel)

-  
 

-  
SUNIX 5099 (4 port serial and 1 port parallel)

-  
 

-  
Syba Tech Ltd. PCI-4S

-  
 

-  
Syba Tech Ltd. PCI-4S2P-550-ECP

-  
 

-  
SystemBase SB16C1050PCI (2 port serial)

-  
 

-  
SystemBase SB16C1054PCI (4 port serial)

-  
 

-  
SystemBase SB16C1058PCI (8 port serial)

-  
 

-  
US Robotics (3Com) 3CP5609 PCI 16550 Modem

-  
 

-  
VScom PCI-010HV2 (1 port parallel)

-  
 

-  
VScom PCI-010L (1 port parallel)

-  
 

-  
VScom PCI-011H (1 port parallel)

-  
 

-  
VScom PCI-100H (1 port serial)

-  
 

-  
VScom PCI-100L (1 port serial)

-  
 

-  
VScom PCI-110L (1 port serial and 1 port parallel)

-  
 

-  
VScom PCI-200 (dual serial)

-  
 

-  
VScom PCI-200H (dual serial)

-  
 

-  
VScom PCI-200HV2 (dual serial)

-  
 

-  
VScom PCI-200L (dual serial)

-  
 

-  
VScom PCI-200Li (dual serial)

-  
 

-  
VScom PCI-210L (2 port serial and 1 port parallel)

-  
 

-  
VScom PCI-400 (4 port serial)

-  
 

-  
VScom PCI-400L (4 port serial)

-  
 

-  
VScom PCI-800 (8 port serial)

-  
 

-  
VScom PCI-800H (8 port serial)

-  
 

-  
VScom PCI-800L (8 port serial)

-  
 

-

-

-
The driver does not support the cards:

-

-

-

-  
Dolphin Peripherals 4006 (single parallel)

-  
 

-  
Dolphin Peripherals 4025 (single serial)

-  
 

-  
Dolphin Peripherals 4078 (dual serial and single parallel)

-  
 

-

-

-
but support for them (and for similar cards) should be trivial to
-    add.

-
The port locator is used to identify the
-    port (starting from 0) on the communications card that a subdevice is
-    supposed to attach to. Typically, the numbering of ports is explained in a
-    card's hardware documentation, and the port numbers used by the driver are
-    the same as (or one off from, e.g. the manual uses ports numbered starting
-    from 1) those described in the documentation.

-

-

-

-
com(4), lpt(4),
-    pci(4)

-

-

-

-
The puc driver appeared in
-    NetBSD 1.4.

-

-

-

-
The puc driver was written by
-    Chris Demetriou.

-

-

-

-
The current design of this driver keeps any
-    com ports on these cards from easily being used as
-    console. Of course, because boards with those are PCI boards, they also
-    suffer from dynamic address assignment, which also means that they can't
-    easily be used as console.

-
Some of the cards supported by this driver have jumper-selectable
-    com port clock multipliers, which are unsupported by
-    this driver. Those can be easily accommodated with driver flags, or by using
-    a properly scaled baud rate when talking to the card.

-
Some of the cards supported by this driver, e.g. the VScom
-    PCI-800, have software-selectable com port clock
-    multipliers, which are unsupported by this driver. Those can be accommodated
-    using internal driver flags, or by using a properly scaled baud rate when
-    talking to the card.

-
Some ports use an lpt driver other than
-    the machine-independent driver. Those ports will not be able to use
-    lpt ports attached to puc
-    devices.

-

-

-
-  
-    
-    
-  
-
May 3, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/pud.4 4.html b/static/netbsd/man4/pud.4 4.html
deleted file mode 100644
index 4ab2ec62..00000000
--- a/static/netbsd/man4/pud.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
PUD(4)Device Drivers ManualPUD(4)

-

-

-

-
pud —
-    Pass-to-Userspace Device

-

-

-

-
pseudo-device pud
-  

-  pseudo-device putter

-

-

-

-
The pud driver enables the implementation
-    of block and character device drivers as userspace daemons. The daemons
-    register the device major number they wish to handle. Registering a
-    character device is mandatory, supporting the block device interface for
-    same major device is optional. The major number must be available, i.e.
-    another driver must not be registered to handle the operation. After
-    successful registration the userspace daemon is supposed to handle the
-    driver methods the kernel passes down to it.

-

-

-

-
puffs(4), putter(9)

-

-

-

-
This document is in a hit-in-the-head style obviously not even
-    near complete.

-
The subsystem lacks a puffs-style library that servers can be
-    written against.

-

-

-
-  
-    
-    
-  
-
November 21, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/puffs.4 4.html b/static/netbsd/man4/puffs.4 4.html
deleted file mode 100644
index 6f3d4852..00000000
--- a/static/netbsd/man4/puffs.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
PUFFS(4)Device Drivers ManualPUFFS(4)

-

-

-

-
puffs —
-    Pass-to-Userspace Framework File System

-

-

-

-
file-system PUFFS
-  

-  pseudo-device putter

-

-

-

-
puffs provides a framework for creating
-    file systems as userspace servers. The in-kernel VFS attachment is
-    controlled through a special device node,
-    /dev/puffs. People looking to implement file systems
-    should use the system through the convenience library described in
-    puffs(3).

-

-

-
A puffs file system can be unmounted
-    regularly using umount(8). The file system will
-    automatically be unmounted in case the userspace server is killed or the
-    control file descriptor closed.

-

-

-

-

-
puffs(3)

-

-

-

-
An unsupported experimental version of
-    puffs first appeared in NetBSD
-    4.0. A stable version appeared in NetBSD
-  5.0.

-

-

-

-
Antti Kantee
-    <pooka@iki.fi>

-

-

-
-  
-    
-    
-  
-
November 22, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/pv.4 3.html b/static/netbsd/man4/pv.4 3.html
deleted file mode 100644
index a5afe23e..00000000
--- a/static/netbsd/man4/pv.4 3.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
PV(4)Device Drivers ManualPV(4)

-

-

-

-
pv — paravirtual
-    device tree root

-

-

-

-
pv* at pv?

-

-

-

-
The pv driver is used on virtual machines
-    that are running on hypervisors. It provides a pseudo-bus for all
-    paravirtual devices that do not attach to a well-known bus like
-    pci(4).

-

-

-

-
virtio(4)

-

-

-
-  
-    
-    
-  
-
January 2, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/pwdog.4 4.html b/static/netbsd/man4/pwdog.4 4.html
deleted file mode 100644
index 049ed929..00000000
--- a/static/netbsd/man4/pwdog.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
PWDOG(4)Device Drivers ManualPWDOG(4)

-

-

-

-
pwdog — Quancom
-    PWDOG1 watchdog timer device

-

-

-

-
pwdog0 at pci?

-

-

-

-
The pwdog driver provides support for
-    Quancom PWDOG1 boards.

-
If the kernel crashes, the watchdog timer is not reset and the
-    system will reboot (assuming a proper connection is made between the PWDOG1
-    and the motherboard). Alternatively, the watchdog can be reinitialized via a
-    userland process which ensures that process scheduling, not just kernel
-    timeout processing, is still taking place.

-
The timeout period of the PWDOG1 card is set using DIP switches
-    and cannot be changed by software.

-

-

-

-
intro(4), pci(4)

-

-

-

-
The pwdog driver first appeared in
-    OpenBSD 4.1 and NetBSD
-  6.0.

-

-

-

-
The pwdog driver was written by
-    Marc Balmer
-    <mbalmer@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 11, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/px.4 4.html b/static/netbsd/man4/px.4 4.html
deleted file mode 100644
index 936c9723..00000000
--- a/static/netbsd/man4/px.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
PX(4)Device Drivers ManualPX(4)

-

-

-

-
px — driver for
-    TURBOchannel PX accelerated graphics boards

-

-

-

-
px* at tc? slot ? offset ?
-  

-  wsdisplay* at px?

-

-

-

-
The px driver provides support for the 2D
-    DEC PixelStamp video display option card (PMAG-C).

-

-

-

-
pxg(4), tc(4),
-    wscons(4)

-

-

-

-
The px driver first appeared in
-    NetBSD 1.3. It became usable as a console device in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
August 22, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/pxagpio.4 4.html b/static/netbsd/man4/pxagpio.4 4.html
deleted file mode 100644
index d203c6de..00000000
--- a/static/netbsd/man4/pxagpio.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
PXAGPIO(4)Device Drivers ManualPXAGPIO(4)

-

-

-

-
pxaip — Intel
-    Xscale PXA250/PXA270 GPIO Controller

-

-

-

-
pxagpio* at pxaip?
-  

-  gpio* at gpiobus?

-

-

-

-
pxaip is an on-board GPIO controller found
-    in XScale PXA250, PXA255, PXA270, PXA271, PXA272, and PXA273 processors
-    manufactured by Intel and Marvell Technology. The driver supports 86 pins
-    for PXA250 or 121 pins for PXA270 processor families. Access to the pins is
-    provided by the gpio(4) interface. The driver supports
-    GPIO_PIN_INPUT and
-    GPIO_PIN_OUTPUT. GPIO pins being used in alternate
-    configurations are not available for GPIO operations.

-

-

-

-
gpio(4)

-

-

-

-
The pxaip driver first appeared in
-    NetBSD 2.0. GPIO attachment appeared in
-    NetBSD 8.0.

-

-

-

-
The pxaip driver was written by
-    Steve Woodford
-    <scw@NetBSD.org>. This
-    manual page was contributed by Stephan
-  Meisinger.

-

-

-
-  
-    
-    
-  
-
April 15, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/pxaip.4 4.html b/static/netbsd/man4/pxaip.4 4.html
deleted file mode 100644
index 49c691c0..00000000
--- a/static/netbsd/man4/pxaip.4 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
PXAIP(4)Device Drivers ManualPXAIP(4)

-

-

-

-
pxaip — Intel
-    Xscale PXA250/PXA270 Onboard Peripheral Controller

-

-

-

-
pxaip0 at mainbus?

-

-

-

-
pxaip is an on-board peripheral controller
-    found in XScale PXA250, PXA255, PXA270, PXA271, and PXA272 processors
-    manufactured by Intel and Marvell Technology. Drivers are available for the
-    following peripherals:

-

-

-  
com

-  
NS16650-compatible serial ports.

-  
gxiic

-  
Gumstix Inter IC controller.

-  
gxio

-  
Gumstix I/O interface.

-  
lcd

-  
LCD controller.

-  
obio

-  
Onboard I/O interface.

-  
ohci

-  
USB OHCI host controller.

-  
pxaacu

-  
Intel Xscale PXA250/270 AC'97 audio device.

-  
pxadmac

-  
Intel XScale PXA250/270 DMA controller.

-  
pxagpio0

-  
Intel XScale PXA250/270 GPIO controller.

-  
pxaintc

-  
Intel XScale PXA250/270 interrupt controller.

-  
pxamci

-  
Intel XScale PXA250/270 SD/MMC card controller.

-  
pxapcic

-  
Intel XScale PXA250/270 PCMCIA controller.

-  
pxartc

-  
Intel XScale PXA250/270 real time clock.

-  
saost

-  
StrongARM SA-110 compatible OS timer.

-  
sm

-  
SMC91Cxx Ethernet interface.

-  
zapm

-  
Sharp Zaurus power management controller.

-  
ziic

-  
Sharp Zaurus Inter IC controller

-  
zkbd

-  
Sharp Zaurus keyboard.

-  
zrc

-  
Sharp Zaurus remote controller.

-

-

-

-

-

-
com(4), evbarm/gxio(4),
-    ohci(4), sm(4)

-

-

-

-
The pxaip driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The pxaip driver was written by
-    Steve Woodford
-    <scw@NetBSD.org>. This
-    manual page was contributed by Stephan
-  Meisinger.

-

-

-
-  
-    
-    
-  
-
March 5, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/pxg.4 4.html b/static/netbsd/man4/pxg.4 4.html
deleted file mode 100644
index c132b68e..00000000
--- a/static/netbsd/man4/pxg.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
PXG(4)Device Drivers ManualPXG(4)

-

-

-

-
pxg — driver for
-    TURBOchannel PXG accelerated graphics boards

-

-

-

-
pxg* at tc? slot ? offset ?
-  

-  wsdisplay* at pxg?

-

-

-

-
The pxg driver provides support for the 3D
-    DEC PixelStamp video display option cards (PMAG-D, PMAG-E, and PMAG-F).

-

-

-

-
px(4), tc(4),
-    wscons(4)

-

-

-

-
The pxg driver first appeared in
-    NetBSD 1.6. Previously, the
-    px driver supported these devices in
-    NetBSD/pmax.

-

-

-
-  
-    
-    
-  
-
August 22, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/qat.4 4.html b/static/netbsd/man4/qat.4 4.html
deleted file mode 100644
index 4d058445..00000000
--- a/static/netbsd/man4/qat.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
QAT(4)Device Drivers ManualQAT(4)

-

-

-

-
qat — Intel
-    QuickAssist crypto accelerator

-

-

-

-
qat* at pci? dev ? function ?

-

-

-

-
The qat driver supports the following
-    system-on-chips, chipsets, and PCIe adapters, which are integrated with
-    QuickAssist:

-

-
    
-  
  • Intel Atom C2000 processor
    • 
-  
  • Intel Atom C3000 processor
    • 
-  
  • Intel Xeon D-1500 processor
    • 
-  
  • Intel Xeon D-2100 processor
    • 
-  
  • Intel C620 chipset
    • 
-  
  • Intel QuickAssist Adapter 8960/8970
    • 
-

-
When the qat driver is attached, it
-    automatically registers itself to accelerate DES-CBC, 3DES-CBC, AES-CBC,
-    HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 operations for
-    opencrypto(9), and thus for ipsec(4) and
-    crypto(4).

-

-

-

-
The qat driver loads the firmware which is
-    located in /libdata/firmware/qat/, by
-    firmload(9).

-

-

-

-
crypto(4), intro(4),
-    ipsec(4), firmload(9),
-    opencrypto(9)

-

-

-

-
The qat driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The qat driver was written by
-    Hikaru Abe
-    <hikaru@iij.ad.jp>.

-

-

-
-  
-    
-    
-  
-
November 20, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/qe.4 4.html b/static/netbsd/man4/qe.4 4.html
deleted file mode 100644
index 05ddc87b..00000000
--- a/static/netbsd/man4/qe.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
QE(4)Device Drivers ManualQE(4)

-

-

-

-
qe — SPARC Fast
-    Ethernet interface

-

-

-

-
qec* at sbus? slot ? offset ?
-  

-  qe* at qec?

-

-

-

-
The qe interface provides access to 10Mb/s
-    Ethernet networks via the AMD Am79C940 (MACE) Ethernet controller. The
-    qe is found on the Sun QuadEthernet boards (Sun part
-    number SUNW,501-2062).

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    qe interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-
arp(4), be(4),
-    hme(4), ie(4),
-    ifmedia(4), inet(4),
-    intro(4), le(4),
-    netintro(4), qec(4),
-    sbus(4), ifconfig(8)

-

-

-

-
Support for the qe first appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 31, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/qec.4 4.html b/static/netbsd/man4/qec.4 4.html
deleted file mode 100644
index dd3d7519..00000000
--- a/static/netbsd/man4/qec.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
QEC(4)Device Drivers ManualQEC(4)

-

-

-

-
qec — SPARC Quad
-    Ethernet Controller

-

-

-

-
qec* at sbus? slot ? offset ?
-  

-  qe* at qec?
-  

-  be* at qec?

-

-

-

-
The qec driver is an Sbus controller that
-    can contain either one be(4) Ethernet controller (Sun part
-    number SUNW,501-2655) or four qe(4) Ethernet controllers
-    (Sun part number SUNW,501-2062). This driver, like other busses, is not
-    directly available to users. In essence it is a buffering DMA
-  controller.

-

-

-

-
be(4), intro(4),
-    qe(4), sbus(4)

-

-

-

-
Support for the qec first appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 31, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/qemufwcfg.4 4.html b/static/netbsd/man4/qemufwcfg.4 4.html
deleted file mode 100644
index 2f24cc94..00000000
--- a/static/netbsd/man4/qemufwcfg.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
QEMUFWCFG(4)Device Drivers ManualQEMUFWCFG(4)

-

-

-

-
qemufwcfg — QEMU
-    Firmware Configuration device driver

-

-

-

-
qemufwcfg* at acpi?
-  

-  qemufwcfg* at fdt?

-

-

-

-
The qemufwcfg interface allows QEMU to
-    provide data items and files to guest operating systems.

-
See the -fw_cfg option in the
-    qemu man page.

-

-

-

-

-  
/dev/qemufwcfg<n>

-  
device path

-

-

-

-

-
mount_qemufwcfg(8)

-
QEMU Firmware Configuration
-    (fw_cfg) Device,
-    https://raw.githubusercontent.com/qemu/qemu/master/docs/specs/fw_cfg.txt.

-

-

-

-
The qemufwcfg driver first appeared in
-    NetBSD 9.0.

-

-

-
-  
-    
-    
-  
-
April 1, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/qsphy.4 4.html b/static/netbsd/man4/qsphy.4 4.html
deleted file mode 100644
index b8a46230..00000000
--- a/static/netbsd/man4/qsphy.4 4.html	
+++ /dev/null
@@ -1,36 +0,0 @@
-
-  
-    
-    
-    
-  
-
QSPHY(4)Device Drivers ManualQSPHY(4)

-

-

-

-
qsphy — Driver for
-    Quality Semiconductor QS6612 10/100 Ethernet PHYs

-

-

-

-
qsphy* at mii? phy ?

-

-

-

-
The qsphy driver supports the Quality
-    Semiconductor QS6612 10/100 Ethernet PHYs. These PHYs are found on a variety
-    of high-performance Ethernet interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 3, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/r128fb.4 4.html b/static/netbsd/man4/r128fb.4 4.html
deleted file mode 100644
index 3c78c821..00000000
--- a/static/netbsd/man4/r128fb.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
R128FB(4)Device Drivers ManualR128FB(4)

-

-

-

-
r128fb — ATI RAGE
-    128 framebuffer driver

-

-

-

-
r128fb* at pci?
-  

-  wsdisplay* at r128fb?

-

-

-

-
The r128fb driver provides support for the
-    ATI RAGE 128 graphics controller. This driver provides backlight control via
-    wsconsctl(8), as well as 2D acceleration for
-    rasops(9) operations.

-

-

-

-
machfb(4), r128(4),
-    r128drm(4), wscons(4),
-    wsdisplay(4)

-

-

-

-
The r128fb driver was written by
-    Michael Lorenz.

-

-

-

-
The driver has been tested on macppc only.

-

-

-
-  
-    
-    
-  
-
April 15, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/radeonfb.4 4.html b/static/netbsd/man4/radeonfb.4 4.html
deleted file mode 100644
index d06aa28b..00000000
--- a/static/netbsd/man4/radeonfb.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
RADEONFB(4)Device Drivers ManualRADEONFB(4)

-

-

-

-
radeonfb — ATI
-    Radeon framebuffer driver

-

-

-

-
radeonfb* at pci?
-  

-  wsdisplay* at radeonfb?

-

-

-

-
The radeonfb driver provides support for
-    ATI Radeon GPUs. The driver provides backlight control on laptops via
-    wsconsctl(8), as well as 2D acceleration for
-    rasops(9) operations.

-
This driver is primarily used on architectures without support for
-    drm(4). On newer systems, radeondrm(4)
-    can be used to take advantage of full hardware acceleration.

-

-

-

-
The following chipsets should work:

-

-

-

-  
Radeon VE / Radeon 7000 (RV100)

-  
 

-  
Radeon 7500, 7500 LE (RV200)

-  
 

-  
Radeon 8500, 8500 LE (R200)

-  
 

-  
Radeon 9000, 9000 Pro (RV250)

-  
 

-  
Radeon 9100 (RS350)

-  
 

-  
Radeon 9200 / 9200 SE (RV280)

-  
 

-  
Radeon 9250 (RV280)

-  
 

-  
Radeon 9500 / 9500 Pro (R300)

-  
 

-  
Radeon 9600 / 9600 Pro (RV350)

-  
 

-  
Radeon 9700 / 9700 Pro (R300)

-  
 

-  
Radeon 9800 / 9800 XL (R350)

-  
 

-  
Radeon X600 Pro (RV380)

-  
 

-  
Radeon X300 / Radeon X550 (RV370)

-  
 

-  
Mobility Radeon 9000 (RV250)

-  
 

-  
Mobility Radeon 9200 (RV280)

-  
 

-  
Mobility Radeon 9500 (RV360)

-  
 

-  
Mobility Radeon 9550 (RV360)

-  
 

-  
Mobility Radeon 9600 (RV350)

-  
 

-  
Mobility Radeon X600 (RV380)

-  
 

-  
Mobility Radeon X300 (RV370)

-  
 

-  
FireMV 2400 (RV380)

-  
 

-

-

-
Note that this list is likely incomplete.

-

-

-

-
radeon(4), wscons(4),
-    wsdisplay(4)

-

-

-

-
The radeonfb driver first appeared in
-    NetBSD 4.0.

-

-

-

-
ATI Technologies Inc. ("ATI") has not assisted in the
-    creation of, and does not endorse, this software. ATI will not be
-    responsible or liable for any actual or alleged damage or loss caused by or
-    in connection with the use of or reliance on this software.

-

-

-
-  
-    
-    
-  
-
April 14, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/radio.4 4.html b/static/netbsd/man4/radio.4 4.html
deleted file mode 100644
index fc81b9b3..00000000
--- a/static/netbsd/man4/radio.4 4.html	
+++ /dev/null
@@ -1,167 +0,0 @@
-
-  
-    
-    
-    
-  
-
RADIO(4)Device Drivers ManualRADIO(4)

-

-

-

-
radio —
-    device-independent radio driver layer

-

-

-

-
radio* at az?
-  

-  radio* at bktr?
-  

-  radio* at gtp?
-  

-  radio* at rt?
-  

-  radio* at rtii?
-  

-  radio* at sf2r?
-  

-  radio* at slurm?
-  

-  radio* at udsbr?

-

-  

-  #include <sys/types.h>
-  

-  #include <sys/ioctl.h>
-  

-  #include <sys/radioio.h>

-

-

-

-
The radio driver provides support for
-    various FM radio cards. It provides an uniform programming interface layer
-    above different underlying radio hardware drivers.

-
For radio tuner controlling there is a single device file
-    available: /dev/radio.

-
The following ioctl(2) commands are
-  supported:

-

-

-  

-  
This command assumes that a signal search is required and gives direction
-      of search to the driver - 0 to search down and any non-zero value to
-      search up.

-  

-  
 

-  

-  
Get or set the current hardware device information into the struct
-      radio_info structure.
-    

-    
struct radio_info {
-	int	mute;
-	int	volume;
-	int	stereo;
-	int	rfreq;	/* reference frequency */
-	int	lock;	/* locking field strength */
-	uint32_t	freq;	/* in kHz */
-	uint32_t	caps;	/* card capabilities */
-#define RADIO_CAPS_DETECT_STEREO	(1<<0)
-#define RADIO_CAPS_DETECT_SIGNAL	(1<<1)
-#define RADIO_CAPS_SET_MONO		(1<<2)
-#define RADIO_CAPS_HW_SEARCH		(1<<3)
-#define RADIO_CAPS_HW_AFC		(1<<4)
-#define RADIO_CAPS_REFERENCE_FREQ	(1<<5)
-#define RADIO_CAPS_LOCK_SENSITIVITY	(1<<6)
-#define RADIO_CARD_TYPE			(0xFF<<16)
-	uint32_t	info;
-#define RADIO_INFO_STEREO		(1<<0)
-#define RADIO_INFO_SIGNAL		(1<<1)
-};

-    

-    
The mute field is a boolean.

-    
The volume field holds the card volume
-        information and can be at most 255.

-    
The stereo field is a boolean.

-    
The rfreq holds information about the
-        card reference frequency (not all cards support this feature).

-    
The lock field holds information about
-        the card locking field strength during an automatic search for cards
-        that support this feature.

-    
The freq field is the frequency in kHz
-        the card is tuned to.

-    
The caps field is read-only and
-        describes the card capabilities. The capabilities can have following
-        values:

-    

-      

-      
The device can determine is it tuned to a stereo signal.

-      

-      
The device can determine is it tuned or not.

-      

-      
The device capable to forcible set its output to mono.

-      
-      
The device can do hardware search.

-      

-      
The device has an internal hardware automatic frequency control.

-      

-      
The device allow to change the reference frequency of a received
-          signal.

-      

-      
The device allow to change the station lock sensitivity used during
-          search operation.

-      

-      
Some cards have several different incarnations. This allow to
-          determine the variant of the card. Currently not used.

-    

-    
The info field is read-only and
-        describes the current state of the card - tuned/not tuned, stereo
-        signal/mono signal.

-    

-      

-      
Informs whether the device receives a stereo or mono signal.

-      

-      
Informs whether the device receives a valid signal or noise.

-    

-  

-

-

-

-

-

-  
/dev/radio

-  
 

-

-

-

-

-
radioctl(1), ioctl(2),
-    az(4), bktr(4),
-    gtp(4), rt(4),
-    rtii(4), sf2r(4),
-    slurm(4), udsbr(4)

-

-

-

-
The radio device driver appeared in
-    OpenBSD 3.0 and NetBSD
-  1.6.

-

-

-

-
The radio driver was written by
-    Vladimir Popov and Maxim
-    Tsyplakov for OpenBSD and ported to
-    NetBSD by Lennart
-    Augustsson. The man page was written by Vladimir Popov.

-

-

-
-  
-    
-    
-  
-
October 20, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/raid.4 3.html b/static/netbsd/man4/raid.4 3.html
deleted file mode 100644
index e8a74045..00000000
--- a/static/netbsd/man4/raid.4 3.html	
+++ /dev/null
@@ -1,374 +0,0 @@
-
-  
-    
-    
-    
-  
-
RAID(4)Device Drivers ManualRAID(4)

-

-

-

-
raid — RAIDframe
-    disk driver

-

-

-

-
options RAID_AUTOCONFIG
-  

-  options RAID_DIAGNOSTIC
-  

-  options RF_ACC_TRACE=n
-  

-  options RF_DEBUG_MAP=n
-  

-  options RF_DEBUG_PSS=n
-  

-  options RF_DEBUG_QUEUE=n
-  

-  options RF_DEBUG_QUIESCE=n
-  

-  options RF_DEBUG_RECON=n
-  

-  options RF_DEBUG_STRIPELOCK=n
-  

-  options RF_DEBUG_VALIDATE_DAG=n
-  

-  options RF_DEBUG_VERIFYPARITY=n
-  

-  options RF_INCLUDE_CHAINDECLUSTER=n
-  

-  options RF_INCLUDE_EVENODD=n
-  

-  options RF_INCLUDE_INTERDECLUSTER=n
-  

-  options RF_INCLUDE_PARITY_DECLUSTERING=n
-  

-  options RF_INCLUDE_PARITY_DECLUSTERING_DS=n
-  

-  options RF_INCLUDE_PARITYLOGGING=n
-  

-  options RF_INCLUDE_RAID5_RS=n

-

-  

-  pseudo-device raid

-

-

-

-
The raid driver provides RAID 0, 1, 4, and
-    5 (and more!) capabilities to NetBSD. This document
-    assumes that the reader has at least some familiarity with RAID and RAID
-    concepts. The reader is also assumed to know how to configure disks and
-    pseudo-devices into kernels, how to generate kernels, and how to partition
-    disks.

-
RAIDframe provides a number of different RAID levels
-  including:

-

-  
RAID 0

-  
provides simple data striping across the components.

-  
RAID 1

-  
provides mirroring.

-  
RAID 4

-  
provides data striping across the components, with parity stored on a
-      dedicated drive (in this case, the last component).

-  
RAID 5

-  
provides data striping across the components, with parity distributed
-      across all the components.

-

-
There are a wide variety of other RAID levels supported by
-    RAIDframe. The configuration file options to enable them are briefly
-    outlined at the end of this section.

-
Depending on the parity level configured, the device driver can
-    support the failure of component drives. The number of failures allowed
-    depends on the parity level selected. If the driver is able to handle drive
-    failures, and a drive does fail, then the system is operating in
-    "degraded mode". In this mode, all missing data must be
-    reconstructed from the data and parity present on the other components. This
-    results in much slower data accesses, but does mean that a failure need not
-    bring the system to a complete halt.

-
The RAID driver supports and enforces the use of ‘component
-    labels’. A ‘component label’ contains important
-    information about the component, including a user-specified serial number,
-    the row and column of that component in the RAID set, and whether the data
-    (and parity) on the component is ‘clean’. The component label
-    currently lives at the half-way point of the ‘reserved
-    section’ located at the beginning of each component. This
-    ‘reserved section’ is RF_PROTECTED_SECTORS in length (64
-    blocks or 32Kbytes) and the component label is currently 1Kbyte in size.

-
If the driver determines that the component labels are very
-    inconsistent with respect to each other (e.g. two or more serial numbers do
-    not match) or that the component label is not consistent with its assigned
-    place in the set (e.g. the component label claims the component should be
-    the 3rd one in a 6-disk set, but the RAID set has it as the 3rd component in
-    a 5-disk set) then the device will fail to configure. If the driver
-    determines that exactly one component label seems to be incorrect, and the
-    RAID set is being configured as a set that supports a single failure, then
-    the RAID set will be allowed to configure, but the incorrectly labeled
-    component will be marked as ‘failed’, and the RAID set will
-    begin operation in degraded mode. If all of the components are consistent
-    among themselves, the RAID set will configure normally.

-
Component labels are also used to support the auto-detection and
-    autoconfiguration of RAID sets. A RAID set can be flagged as
-    autoconfigurable, in which case it will be configured automatically during
-    the kernel boot process. RAID file systems which are automatically
-    configured are also eligible to be the root file system. There is currently
-    only limited support (alpha, amd64, i386, pmax, sparc, sparc64, and vax
-    architectures) for booting a kernel directly from a RAID 1 set, and no
-    support for booting from any other RAID sets. To use a RAID set as the root
-    file system, a kernel is usually obtained from a small non-RAID partition,
-    after which any autoconfiguring RAID set can be used for the root file
-    system. See raidctl(8) for more information on
-    autoconfiguration of RAID sets. Note that with autoconfiguration of RAID
-    sets, it is no longer necessary to hard-code SCSI IDs of drives. The
-    autoconfiguration code will correctly configure a device even after any
-    number of the components have had their device IDs changed or device names
-    changed.

-
The driver supports ‘hot spares’, disks which are
-    on-line, but are not actively used in an existing file system. Should a disk
-    fail, the driver is capable of reconstructing the failed disk onto a hot
-    spare or back onto a replacement drive. If the components are hot swappable,
-    the failed disk can then be removed, a new disk put in its place, and a
-    copyback operation performed. The copyback operation, as its name indicates,
-    will copy the reconstructed data from the hot spare to the previously failed
-    (and now replaced) disk. Hot spares can also be hot-added using
-    raidctl(8).

-
If a component cannot be detected when the RAID device is
-    configured, that component will be simply marked as 'failed'.

-
The user-land utility for doing all raid
-    configuration and other operations is raidctl(8). Most
-    importantly, raidctl(8) must be used with the
-    -i option to initialize all RAID sets. In
-    particular, this initialization includes re-building the parity data. This
-    rebuilding of parity data is also required when either a) a new RAID device
-    is brought up for the first time or b) after an un-clean shutdown of a RAID
-    device. By using the -P option to
-    raidctl(8), and performing this on-demand recomputation of
-    all parity before doing a fsck(8) or a
-    newfs(8), file system integrity and parity integrity can
-    be ensured. It bears repeating again that parity recomputation is
-    required before any file systems are created or used
-    on the RAID device. If the parity is not correct, then missing data cannot
-    be correctly recovered.

-
RAID levels may be combined in a hierarchical fashion. For
-    example, a RAID 0 device can be constructed out of a number of RAID 5
-    devices (which, in turn, may be constructed out of the physical disks, or of
-    other RAID devices).

-
The first step to using the raid driver is
-    to ensure that it is suitably configured in the kernel. This is done by
-    adding a line similar to:

-

-
pseudo-device   raid         # RAIDframe disk device

-

-
to the kernel configuration file. The RAIDframe drivers are
-    configured dynamically as needed. To turn on component auto-detection and
-    autoconfiguration of RAID sets, simply add:

-

-
options RAID_AUTOCONFIG

-

-
to the kernel configuration file.

-
All component partitions must be of the type
-    FS_BSDFFS (e.g. 4.2BSD) or
-    FS_RAID. The use of the latter is strongly
-    encouraged, and is required if autoconfiguration of the RAID set is desired.
-    Since RAIDframe leaves room for disklabels, RAID components can be simply
-    raw disks, or partitions which use an entire disk.

-
A more detailed treatment of actually using a
-    raid device is found in
-    raidctl(8). It is highly recommended that the steps to
-    reconstruct, copyback, and re-compute parity are well understood by the
-    system administrator(s) before a component failure.
-    Doing the wrong thing when a component fails may result in data loss.

-
Additional internal consistency checking can be enabled by
-    specifying:

-

-
options RAID_DIAGNOSTIC

-

-
These assertions are disabled by default in order to improve
-    performance.

-
RAIDframe supports an access tracing facility for tracking both
-    requests made and performance of various parts of the RAID systems as the
-    request is processed. To enable this tracing the following option may be
-    specified:

-

-
options RF_ACC_TRACE=1

-

-
For extensive debugging there are a number of kernel options which
-    will aid in performing extra diagnosis of various parts of the RAIDframe
-    sub-systems. Note that in order to make full use of these options it is
-    often necessary to enable one or more debugging options as listed in
-    src/sys/dev/raidframe/rf_options.h. As well, these
-    options are also only typically useful for people who wish to debug various
-    parts of RAIDframe. The options include:

-
For debugging the code which maps RAID addresses to physical
-    addresses:

-

-
options RF_DEBUG_MAP=1

-

-
Parity stripe status debugging is enabled with:

-

-
options RF_DEBUG_PSS=1

-

-
Additional debugging for queuing is enabled with:

-

-
options RF_DEBUG_QUEUE=1

-

-
Problems with non-quiescent file systems should be easier to debug
-    if the following is enabled:

-

-
options RF_DEBUG_QUIESCE=1

-

-
Stripelock debugging is enabled with:

-

-
options RF_DEBUG_STRIPELOCK=1

-

-
Additional diagnostic checks during reconstruction are enabled
-    with:

-

-
options RF_DEBUG_RECON=1

-

-
Validation of the DAGs (Directed Acyclic Graphs) used to describe
-    an I/O access can be performed when the following is enabled:

-

-
options RF_DEBUG_VALIDATE_DAG=1

-

-
Additional diagnostics during parity verification are enabled
-    with:

-

-
options RF_DEBUG_VERIFYPARITY=1

-

-
There are a number of less commonly used RAID levels supported by
-    RAIDframe. These additional RAID types should be considered experimental,
-    and may not be ready for production use. The various types and the options
-    to enable them are shown here:

-
For Even-Odd parity:

-

-
options RF_INCLUDE_EVENODD=1

-

-
For RAID level 5 with rotated sparing:

-

-
options RF_INCLUDE_RAID5_RS=1

-

-
For Parity Logging (highly experimental):

-

-
options RF_INCLUDE_PARITYLOGGING=1

-

-
For Chain Declustering:

-

-
options RF_INCLUDE_CHAINDECLUSTER=1

-

-
For Interleaved Declustering:

-

-
options RF_INCLUDE_INTERDECLUSTER=1

-

-
For Parity Declustering:

-

-
options RF_INCLUDE_PARITY_DECLUSTERING=1

-

-
For Parity Declustering with Distributed Spares:

-

-
options RF_INCLUDE_PARITY_DECLUSTERING_DS=1

-

-
The reader is referred to the RAIDframe documentation mentioned in
-    the HISTORY section for more detail on
-    these various RAID configurations.

-

-

-

-
Certain RAID levels (1, 4, 5, 6, and others) can protect against
-    some data loss due to component failure. However the loss of two components
-    of a RAID 4 or 5 system, or the loss of a single component of a RAID 0
-    system, will result in the entire file systems on that RAID device being
-    lost. RAID is NOT a substitute for good backup
-    practices.

-
Recomputation of parity MUST be performed
-    whenever there is a chance that it may have been compromised. This includes
-    after system crashes, or before a RAID device has been used for the first
-    time. Failure to keep parity correct will be catastrophic should a component
-    ever fail — it is better to use RAID 0 and get the additional space
-    and speed, than it is to use parity, but not keep the parity correct. At
-    least with RAID 0 there is no perception of increased data security.

-

-

-

-

-  
/dev/{,r}raid*

-  
raid device special files.

-

-

-

-

-
config(1), sd(4),
-    fsck(8), MAKEDEV(8),
-    mount(8), newfs(8),
-    raidctl(8)

-

-

-

-
The raid driver in
-    NetBSD is a port of RAIDframe, a framework for rapid
-    prototyping of RAID structures developed by the folks at the Parallel Data
-    Laboratory at Carnegie Mellon University (CMU). RAIDframe, as originally
-    distributed by CMU, provides a RAID simulator for a number of different
-    architectures, and a user-level device driver and a kernel device driver for
-    Digital Unix. The raid driver is a kernelized
-    version of RAIDframe v1.1.

-
A more complete description of the internals and functionality of
-    RAIDframe is found in the paper "RAIDframe: A Rapid Prototyping Tool
-    for RAID Systems", by William V. Courtright II, Garth Gibson, Mark
-    Holland, LeAnn Neal Reilly, and Jim Zelenka, and published by the Parallel
-    Data Laboratory of Carnegie Mellon University. The
-    raid driver first appeared in
-    NetBSD 1.4.

-
RAIDframe was ported to NetBSD by Greg
-    Oster in 1998, who has maintained it since. In 1999, component labels,
-    spares, automatic rebuilding of parity, and autoconfiguration of volumes
-    were added. In 2000, root on RAID support was added (initially, with no
-    support for loading kernels from RAID volumes, which has been added to many
-    ports since.) In 2009, support for parity bimap was added, reducing parity
-    resync time after a crash. In 2010, support for larger than 2TiB and non-512
-    sector devices was added. In 2018, support for 32-bit userland compatibility
-    was added. In 2021, support for autoconfiguration from other-endian raid
-    sets was added.

-
Support for loading kernels from RAID 1 partitions was added for
-    the pmax, alpha, i386, and vax ports in 2000, the sgimips port in 2001, the
-    sparc64 and amd64 ports in 2002, the arc port in 2005, the sparc, and
-    landisk ports in 2006, the cobalt port in 2007, the ofppc port in 2008, the
-    bebox port in 2010, the emips port in 2011, and the sandpoint port in
-  2012.

-

-

-

-

-
The RAIDframe Copyright is as follows:
-
-Copyright (c) 1994-1996 Carnegie-Mellon University.
-All rights reserved.
-
-Permission to use, copy, modify and distribute this software and
-its documentation is hereby granted, provided that both the copyright
-notice and this permission notice appear in all copies of the
-software, derivative works or modified versions, and any portions
-thereof, and that both notices appear in supporting documentation.
-
-CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
-CONDITION.  CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND
-FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
-
-Carnegie Mellon requests users of this software to return to
-
- Software Distribution Coordinator  or  Software.Distribution@CS.CMU.EDU
- School of Computer Science
- Carnegie Mellon University
- Pittsburgh PA 15213-3890
-
-any improvements or extensions that they make and grant Carnegie the
-rights to redistribute these changes.

-

-

-

-
-  
-    
-    
-  
-
May 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/ral.4 3.html b/static/netbsd/man4/ral.4 3.html
deleted file mode 100644
index 126128b5..00000000
--- a/static/netbsd/man4/ral.4 3.html	
+++ /dev/null
@@ -1,325 +0,0 @@
-
-  
-    
-    
-    
-  
-
RAL(4)Device Drivers ManualRAL(4)

-

-

-

-
ral — Ralink
-    Technology IEEE 802.11a/b/g wireless network driver

-

-

-

-
ral* at cardbus?
-  

-  ral* at pci?
-  

-  ral* at uhub? port ?

-

-

-

-
The ral driver supports PCI/CardBus
-    wireless adapters based on the Ralink RT2500, RT2501, and RT2600 chipsets.
-    The ral driver supports USB 2.0 wireless adapters
-    based on the Ralink RT2500USB chipset.

-
The RT2500 chipset is the first generation of 802.11b/g adapters
-    from Ralink. It consists of two integrated chips, an RT2560 or RT2570(USB)
-    MAC/BBP and an RT2525 or RT2526(USB) radio transceiver.

-
The RT2501 chipset is the second generation of 802.11b/g adapters
-    from Ralink. It consists of two integrated chips, an RT2561 MAC/BBP and an
-    RT2527 radio transceiver. This chipset provides support for the IEEE 802.11e
-    standard with multiple hardware transmission queues and allows
-    scatter/gather for efficient DMA operations.

-
The RT2600 chipset consists of two integrated chips, an RT2661
-    MAC/BBP and an RT2529 radio transceiver. This chipset uses the MIMO
-    (multiple-input multiple-output) technology with multiple antennas to extend
-    the operating range of the adapter and to achieve higher throughput. MIMO
-    will be the basis of the future IEEE 802.11n standard.

-
These are the modes the ral driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
IBSS mode

-  
Also known as  mode or
-      
-      mode. This is the standardized method of operating without an access
-      point. Stations associate with a service set. However, actual connections
-      between stations are peer-to-peer.

-  
Host AP

-  
In this mode the driver acts as an access point (base station) for other
-      cards.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
ral supports software WEP. Wired
-    Equivalent Privacy (WEP) is the de facto encryption standard for wireless
-    networks. It can be typically configured in one of three modes: no
-    encryption; 40-bit encryption; or 104-bit encryption. Unfortunately, due to
-    serious weaknesses in WEP protocol it is strongly recommended that it not be
-    used as the sole mechanism to secure wireless communication. WEP is not
-    enabled by default.

-
The transmit speed is user-selectable or can be adapted
-    automatically by the driver depending on the received signal strength and on
-    the number of hardware transmission retries. See
-    rssadapt(9) for more information.

-

-

-

-
The ral driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5) using the following parameters:

-

-  

-    bssid

-  
Set the desired BSSID.

-  

-  
Unset the desired BSSID. The interface will automatically select a BSSID
-      in this mode, which is the default.

-  

-    n

-  
Set the channel (radio frequency) to be used by the driver based on the
-      given channel ID n.

-  

-  
Unset the desired channel to be used by the driver. The driver will
-      automatically select a channel in this mode, which is the default.

-  

-    media

-  
The ral driver supports the following
-      media types:
-    

-    

-      

-      
Enable autoselection of the media type and options.

-      

-      
Set 802.11b DS 1Mbps operation.

-      

-      
Set 802.11b DS 2Mbps operation.

-      

-      
Set 802.11b DS 5.5Mbps operation.

-      

-      
Set 802.11b DS 11Mbps operation.

-      

-      
Set 802.11a/g OFDM 6Mbps operation.

-      

-      
Set 802.11a/g OFDM 9Mbps operation.

-      

-      
Set 802.11a/g OFDM 12Mbps operation.

-      

-      
Set 802.11a/g OFDM 18Mbps operation.

-      

-      
Set 802.11a/g OFDM 24Mbps operation.

-      

-      
Set 802.11a/g OFDM 36Mbps operation.

-      

-      
Set 802.11a/g OFDM 48Mbps operation.

-      

-      
Set 802.11a/g OFDM 54Mbps operation.

-    

-  

-  

-    opts

-  
The ral driver supports the following media
-      options:
-    

-    

-      

-      
Select Host AP operation.

-      

-      
Select IBSS operation.

-      

-      
Select monitor mode.

-    

-  

-  

-    opts

-  
Disable the specified media options on the driver and return it to the
-      default mode of operation (BSS).

-  

-    mode

-  
The ral driver supports the following modes:
-    

-    

-      

-      
Force 802.11a operation.

-      

-      
Force 802.11b operation.

-      

-      
Force 802.11g operation.

-    

-  

-  

-    id

-  
Set the network ID. The id can either be any text
-      string up to 32 characters in length, or a series of hexadecimal digits up
-      to 64 digits. An empty id string allows the
-      interface to connect to any available access points. By default the
-      ral driver uses an empty string. Note that network
-      ID is synonymous with Extended Service Set ID (ESSID).

-  

-    key

-  
Enable WEP encryption using the specified key. The
-      key can either be a string, a series of hexadecimal
-      digits (preceded by ‘0x’), or a set of keys of the form
-      “n:k1,k2,k3,k4”, where ‘n’ specifies which of
-      the keys will be used for transmitted packets, and the four keys,
-      “k1” through “k4”, are configured as WEP keys.
-      If a set of keys is specified, a comma (‘,’) within the key
-      must be escaped with a backslash. Note that if multiple keys are used,
-      their order must be the same within the network.
-      ral is capable of using both 40-bit (5 characters
-      or 10 hexadecimal digits) or 104-bit (13 characters or 26 hexadecimal
-      digits) keys.

-  

-  
Disable WEP encryption. This is the default mode of operation.

-

-

-

-

-
The following firmware files are potentially loaded when an
-    interface is brought up:

-

-

-

-  
/libdata/firmware/ral/ral-rt2561

-  
 

-  
/libdata/firmware/ral/ral-rt2561s

-  
 

-  
/libdata/firmware/ral/ral-rt2661

-  
 

-

-

-
RT2500 adapters do not require a firmware to operate.

-

-

-

-
The following PCI adapters should work:

-
A-Link WL54H. Amigo AWI-926W. AMIT WL531P. AOpen AOI-831.
-  ASUS WL-130g. ASUS WIFI-G-AAY. Atlantis Land A02-PCI-W54. Belkin F5D7000 v3.
-  Canyon CN-WF511. CNet CWP-854. Compex WLP54G. Conceptronic C54Ri. Corega
-  CG-WLPCI54GL. Digitus DN-7006G-RA. Dynalink WLG25PCI. E-Tech WGPI02. Edimax
-  EW-7128g. Eminent EM3037. Encore ENLWI-G-RLAM. Eusso UGL2454-VPR. Fiberline
-  WL-400P. Foxconn WLL-3350. Gigabyte GN-WPKG. Hama WLAN PCI Card 54 Mbps.
-  Hawking HWP54GR. Hercules HWGPCI-54. iNexQ CR054g-009 (R03). JAHT WN-4054PCI.
-  KCORP LifeStyle KLS-660. LevelOne WNC-0301 v2. Linksys WMP54G v4. Micronet
-  SP906GK. Minitar MN54GPC-R. MSI MS-6834. MSI PC54G2. OvisLink EVO-W54PCI.
-  PheeNet HWL-PCIG/RA. Pro-Nets PC80211G. Repotec RP-WP0854. SATech SN-54P.
-  Signamax 065-1798. Sitecom WL-115. SparkLAN WL-660R. Surecom EP-9321-g. Sweex
-  LC700030. TekComm NE-9321-g. Tonze PC-6200C. Unex CR054g-R02. Zinwell
-  ZWX-G361. Zonet ZEW1600.

-
The following CardBus adapters should work:

-
A-Link WL54PC. Alfa AWPC036. Amigo AWI-914W. AMIT WL531C.
-  ASUS WL-107G. Atlantis Land A02-PCM-W54. Belkin F5D7010 v2. Canyon CN-WF513.
-  CC&C WL-2102. CNet CWC-854. Conceptronic C54RC. Corega CG-WLCB54GL.
-  Digitus DN-7001G-RA. Dynalink WLG25CARDBUS. E-Tech WGPC02. E-Tech WGPC03.
-  Edimax EW-7108PCg. Eminent EM3036. Encore ENPWI-G-RLAM. Eusso UGL2454-01R.
-  Fiberline WL-400X. Gigabyte GN-WMKG. Hawking HWC54GR. Hercules HWGPCMCIA-54.
-  JAHT WN-4054P(E). KCORP LifeStyle KLS-611. LevelOne WPC-0301 v2. Micronet
-  SP908GK V3. Minitar MN54GCB-R. MSI CB54G2. MSI MS-6835. Pro-Nets CB80211G.
-  Repotec RP-WB7108. SATech SN-54C. Sitecom WL-112. SparkLAN WL-611R. Surecom
-  EP-9428-g. Sweex LC500050. TekComm NE-9428-g. Tonze PW-6200C. Unex MR054g-R02.
-  Zinwell ZWX-G160. Zonet ZEW1500.

-
The following Mini PCI adapters should work:

-
Amigo AWI-922W. Billionton MIWLGRL. Gigabyte GN-WIKG. MSI
-  MP54G2. MSI MS-6833. Tonze PC-620C. Zinwell ZWX-G360.

-
The following USB 2.0 adapters should work:

-
AMIT WL532U. ASUS WL-167g. Belkin F5D7050 v2000. Buffalo
-  WLI-U2-KG54. Buffalo WLI-U2-KG54-AI. Buffalo WLI-U2-KG54-YB. CNet CWD-854.
-  Compex WLU54G 2A1100. Conceptronic C54RU. D-Link DWL-G122 (b1). Dynalink
-  WLG25USB. E-Tech WGUS02. Gigabyte GN-WBKG. Hercules HWGUSB2-54. KCORP
-  LifeStyle KLS-685. Linksys HU200-TS. Linksys WUSB54G v4. Linksys WUSB54GP v4.
-  MSI MS-6861. MSI MS-6865. MSI MS-6869. Nintendo Wi-Fi USB Connector. OvisLink
-  Evo-W54USB. SerComm UB801R. SparkLAN WL-685R. Surecom EP-9001-g. Sweex
-  LC100060. Tonze UW-6200C. Zinwell ZWX-G261. Zonet ZEW2500P.

-

-

-

-
The following ifconfig.if(5) example creates a
-    host-based access point on boot:

-

-
inet 192.168.1.1 netmask 255.255.255.0 media autoselect \
-	mediaopt hostap nwid my_net chan 11

-

-
Configure ral0 for WEP, using hex key
-    “0x1deadbeef1”:

-

-
# ifconfig ral0 nwkey 0x1deadbeef1

-

-
Return ral0 to its default settings:

-

-
# ifconfig ral0 -bssid -chan media autoselect \
-	nwid "" -nwkey

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig ral0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
ral%d: could not read microcode %s

-  
For some reason, the driver was unable to read the microcode file from the
-      filesystem. The file might be missing or corrupted.

-  
ral%d: could not load 8051 microcode

-  
An error occurred while attempting to upload the microcode to the onboard
-      8051 microcontroller unit.

-  
ral%d: timeout waiting for MCU to initialize

-  
The onboard 8051 microcontroller unit failed to initialize in time.

-  
ral%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), cardbus(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    usb(4), ifconfig.if(5),
-    hostapd(8), ifconfig(8)

-
Ralink
-    Technology

-

-

-

-
The ral driver first appeared in
-    OpenBSD 3.7 and in NetBSD
-    3.0. Support for the RT2501 and RT2600 chipsets was added in
-    OpenBSD 3.9 and in NetBSD
-    4.0.

-

-

-

-
The ral driver was written by
-    Damien Bergamini
-    <damien@openbsd.org>.

-

-

-

-
Some PCI ral adapters seem to strictly
-    require a system supporting PCI 2.2 or greater and will likely not work in
-    systems based on older revisions of the PCI specification. Check the board's
-    PCI version before purchasing the card.

-
The USB ral driver supports automatic
-    control of the transmit speed in BSS mode only. Therefore the use of a USB
-    ral adapter in Host AP mode is discouraged.

-

-

-
-  
-    
-    
-  
-
December 13, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/ray.4 4.html b/static/netbsd/man4/ray.4 4.html
deleted file mode 100644
index 380a950f..00000000
--- a/static/netbsd/man4/ray.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
RAY(4)Device Drivers ManualRAY(4)

-

-

-

-
ray — Raytheon
-    Raylink / WebGear Aviator IEEE 802.11 2Mbps Wireless

-

-

-

-
ray* at pcmcia? function ?
-  

-  options
-    RAY_PID_COUNTRY_CODE_DEFAULT=RAY_PID_COUNTRY_CODE_USA

-

-

-

-
The ray device driver supports the
-    Raytheon Raylink and Aviator 2.4/PRO 802.11 FH 2Mbps wireless PCMCIA cards.
-    The cards can be operated in either ad-hoc or infrastructure modes. The
-    operating mode is selectable with ifconfig(8) through a
-    media option.

-
To communicate with other 802.11 cards a common network id or NWID
-    must be specified on each station that wishes to participate in the shared
-    wireless network. The NWID can be set with
-  ifconfig(8).

-
The device uses IEEE 802.11 standard Frequency Hopping Spread
-    Spectrum signaling and operates in the ranges of 2.400 to 2.4835 Gigahertz.
-    This frequency range is further restricted by country according to that
-    country's regulations. Currently the ray driver
-    defaults to using the ranges appropriate for the USA. To change this setting
-    you must define the kernel option RAY_PID_COUNTRY_CODE_DEFAULT to one of the
-    following values:

-

-
    
-  
  • RAY_PID_COUNTRY_CODE_USA
    • 
-  
  • RAY_PID_COUNTRY_CODE_EUROPE
    • 
-  
  • RAY_PID_COUNTRY_CODE_JAPAN
    • 
-  
  • RAY_PID_COUNTRY_CODE_KOREA
    • 
-  
  • RAY_PID_COUNTRY_CODE_SPAIN
    • 
-  
  • RAY_PID_COUNTRY_CODE_FRANCE
    • 
-  
  • RAY_PID_COUNTRY_CODE_ISRAEL
    • 
-  
  • RAY_PID_COUNTRY_CODE_AUSTRALIA
    • 
-

-
The output power of the transceiver is 100mW and the card's power
-    consumption is 365 mA @ 5 volts. The transmission range in open air (line of
-    sight) is a maximum of 1000 feet (or ~304 meters), and indoors (i.e., with
-    obstructions) it is a maximum of 500 feet (152 meters).

-

-

-

-
Cards supported by the ray driver
-  include:

-

-
    
-  
  • WebGear Aviator 2.4
    • 
-  
  • WebGear Aviator PRO
    • 
-  
  • Raytheon Raylink WLAN
    • 
-

-

-

-

-

-  
ray0: card failed self test: status x

-  
Indicates the card has failed its initial startup tests.

-

-

-

-

-
ifmedia(4), intro(4),
-    pcmcia(4), ifconfig(8)

-

-

-

-
The ray driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The ray driver was written by
-    Christian E. Hopps
-    ⟨chopps@NetBSD.org⟩.

-

-

-

-
Currently the infrastructure mode is untested, and authentication
-    using WEP is unimplemented.

-

-

-
-  
-    
-    
-  
-
January 24, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/rcons.4 4.html b/static/netbsd/man4/rcons.4 4.html
deleted file mode 100644
index f1b46950..00000000
--- a/static/netbsd/man4/rcons.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
RCONS(4)Device Drivers ManualRCONS(4)

-

-

-

-
rcons — raster
-    console access

-

-

-

-
options RASTERCONSOLE_FGCOL=n
-  

-  options RASTERCONSOLE_BGCOL=n
-  

-  options RCONS_2BPP
-  

-  options RCONS_4BPP
-  

-  options RCONS_16BPP

-

-

-
pseudo-device rasterconsole N

-

-

-

-

-
The rcons driver provides support for
-    machine-independent access to the raster console. Use of the
-    rcons driver is deprecated in favour of the
-    wscons(4) machine-independent console driver.

-
The rcons driver provides simple raster
-    and frame buffer routines. It's enough to implement a console terminal
-    emulator on monochrome and pseudo-colour screens.

-

-

-

-
wscons(4)

-

-

-
-  
-    
-    
-  
-
September 21, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/rdcphy.4 4.html b/static/netbsd/man4/rdcphy.4 4.html
deleted file mode 100644
index 51a89f09..00000000
--- a/static/netbsd/man4/rdcphy.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
RDCPHY(4)Device Drivers ManualRDCPHY(4)

-

-

-

-
rdcphy — Driver
-    for RDC R6040 Fast Ethernet controller internal PHY

-

-

-

-
rdcphy* at mii? phy ?

-

-

-

-
The rdcphy driver supports the internal
-    PHY on RDC R6040 Ethernet interfaces, commonly found on Vortex86 System On a
-    Chip (SoC).

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), vte(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
January 23, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/re.4 3.html b/static/netbsd/man4/re.4 3.html
deleted file mode 100644
index 631c66f3..00000000
--- a/static/netbsd/man4/re.4 3.html	
+++ /dev/null
@@ -1,156 +0,0 @@
-
-  
-    
-    
-    
-  
-
RE(4)Device Drivers ManualRE(4)

-

-

-

-
re — RealTek
-    8139C+/8169/8169S/8168/8110S/8111 PCI Ethernet adapter driver

-

-

-

-
re* at pci? dev ? function ?
-  

-  re* at cardbus? function ?

-

-

-

-
The re driver provides support for various
-    NICs based on the RealTek RTL8139C+, RTL8169, RTL8169S, RTL8168, and
-    RTL8110S PCI/Cardbus Ethernet controllers, including the following:

-

-
    
-  
  • Alloy Computer Products EtherGOLD 1439E 10/100 (8139C+)
    • 
-  
  • Compaq Evo N1015v Integrated Ethernet (8139C+)
    • 
-  
  • Gigabyte 7N400 Pro2 Integrated Gigabit Ethernet (8110S)
    • 
-  
  • NETGEAR GA311 (8169S)
    • 
-  
  • PLANEX COMMUNICATIONS Inc. GN-1200TC (8169S)
    • 
-  
  • Xterasys XN-152 10/100/1000 NIC (8169)
    • 
-  
  • Corega CG-LAPCIGT Gigabit Ethernet (8169S)
    • 
-  
  • D-Link DGE-528T Gigabit Ethernet (8169S)
    • 
-  
  • D-Link DGE-530T rev. C & D Gigabit Ethernet (8169)
    • 
-  
  • US Robotics (3Com) USR997902 Gigabit Ethernet (8169S)
    • 
-  
  • Linksys EG1032 rev. 3 Gigabit Ethernet (8169S)
    • 
-  
  • TP-Link TG-3468 v2 & v3 Gigabit Ethernet (8168)
    • 
-

-
NICs based on the 8139C+ are capable of 10 and 100Mbps speeds over
-    CAT5 cable. NICs based on the 8169, 8169S, 8168, and 8110S are capable of
-    10, 100, and 1000Mbps operation.

-
All NICs supported by the re driver have
-    IP/TCP/UDP checksum offload and hardware VLAN tagging/insertion features,
-    and use a descriptor-based DMA mechanism. They are also capable of TCP large
-    send (TCP segmentation offload).

-
The 8139C+ is a single-chip solution combining both a 10/100 MAC
-    and PHY, and its PHY is supported by rlphy(4). The 8169 is
-    a 10/100/1000 MAC only, requiring a GMII or TBI external PHY and some 8169
-    based boards have Marvell 88E1000 PHY supported by
-    makphy(4). The 8169S and 8110S are single-chip devices
-    containing both a 10/100/1000 MAC and 10/100/1000 copper PHY, which is
-    supported by rgephy(4). Standalone 10/100/1000 cards are
-    available in both 32-bit PCI and 64-bit PCI models. The 8110S is designed
-    for embedded LAN-on-motherboard applications.

-
The 8169, 8169S, and 8110S also support jumbo frames, which can be
-    configured via the interface MTU setting. Selecting an MTU larger than 1500
-    bytes with the ifconfig(8) utility configures the adapter
-    to receive and transmit jumbo frames.

-
The re driver supports the following media
-    types:

-

-  

-  
Enable autoselection of the media type and options. The user can manually
-      override the autoselected mode by adding media options to
-      rc.conf(5).

-  

-  
Set 10Mbps operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 1000baseTX operation over twisted pair. The RealTek GigE chips support
-      1000Mbps in full-duplex mode only.

-

-
The re driver supports the following media
-    options:

-

-  

-  
Force full duplex operation.

-  

-  
Force half duplex operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-

-  
re%d: can't map i/o space

-  
A fatal initialization error has occurred.

-  
re%d: can't map mem space

-  
A fatal initialization error has occurred.

-  
re%d: couldn't map interrupt

-  
A fatal initialization error has occurred.

-  
re%d: watchdog timeout

-  
The device has stopped responding to the network, or there is a problem
-      with the network connection (cable).

-

-

-

-

-
arp(4), cardbus(4),
-    mii(4), netintro(4),
-    pci(4), rgephy(4),
-    rlphy(4), ifconfig(8)

-
RealTek Semiconductor
-    RTL8139C+, RTL8169, RTL8169S, and RTL8110S datasheets,
-    http://www.realtek.com.tw.

-

-

-

-
The re device driver first appeared in
-    FreeBSD 5.2 and was ported to
-    NetBSD 2.0.

-

-

-

-
The re driver was written by
-    Bill Paul
-    <wpaul@windriver.com>.

-

-

-

-
The Xterasys XN-152 32-bit PCI NIC, which uses the RTL8169 MAC and
-    Marvell 88E1000 PHY, has a defect that causes DMA corruption if the board is
-    plugged into a 64-bit PCI slot. The defect lies in the board design, not the
-    chip itself: the PCI REQ64# and ACK64# lines should be pulled high, but they
-    are not. The result is that the 8169 chip is tricked into performing 64-bit
-    DMA transfers even though a 64-bit data path between the NIC and the bus
-    does not actually exist.

-
Unfortunately, it is not possible to correct this problem in
-    software, however it is possible to detect it. When the
-    re driver is loaded, it will run a diagnostic
-    routine designed to validate DMA operation by placing the chip in digital
-    loopback mode and initiating a packet transmission. If the card functions
-    properly, the transmitted data will be echoed back unmodified. If the echoed
-    data is corrupt, the driver will print an error message on the console and
-    abort the device attach. The user should ensure the NIC is installed in a
-    32-bit PCI slot to avoid this problem.

-
The RealTek 8169, 8169S, and 8110S chips appear to only be capable
-    of transmitting jumbo frames up to 7.5K in size.

-

-

-
-  
-    
-    
-  
-
November 18, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/rge.4 4.html b/static/netbsd/man4/rge.4 4.html
deleted file mode 100644
index 762a6e22..00000000
--- a/static/netbsd/man4/rge.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
RGE(4)Device Drivers ManualRGE(4)

-

-

-

-
rge — Realtek
-    8125/8125B/8126/8127 PCI Express 10/100/1Gb/2.5Gb/5Gb/10Gb Ethernet
-    device

-

-

-

-
rge* at pci?

-

-

-

-
The rge driver provides support for NICs
-    based on the Realtek RTL8125, RTL8126, and RTL8127 PCI Express Ethernet
-    controllers, including the following:

-

-
    
-  
  • IOCrest IO-PCE8126-GLAN Adapter (5000baseT)
    • 
-  
  • WisdPi WP-NA5000 Adapter (5000baseT)
    • 
-  
  • Realtek 8125/8125B 2.5GbE Adapter (2500baseT)
    • 
-  
  • Realtek 8126 5GbE Controller (5000baseT)
    • 
-  
  • Rivet Networks Killer E3000 Adapter (2500baseT)
    • 
-  
  • TP-LINK TL-NG421 Adapter (2500baseT)
    • 
-

-
NICs based on the 8125 and 8125B are capable of 10, 100, 1000 and
-    2500Mbps operation. NICs based on the 8126 are also capable of 5000Mbps
-    operation, while NICs based on the 8127 are additionally capable of
-    10000Mbps operation. All NICs support off-loading of checksum calculations
-    for IPv4, TCPv4, and UDPv4, but not for xxxv6.

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The rge driver support for the RTL8127
-    chip should be considered experimental.

-

-

-

-
The rge driver first appeared in
-    OpenBSD 6.6 and in NetBSD
-    10.0.

-

-

-

-
The rge driver was written by
-    Kevin Lo
-    <kevlo@openbsd.org>,
-    and was initially ported to NetBSD by
-    Sevan Janiyan. The current version was updated by
-    Paul Goyette
-    <pgoyette@netbsd.org>
-    to synch with changes from OpenBSD.

-

-

-
-  
-    
-    
-  
-
November 20, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/rgephy.4 4.html b/static/netbsd/man4/rgephy.4 4.html
deleted file mode 100644
index b3dd19ad..00000000
--- a/static/netbsd/man4/rgephy.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
RGEPHY(4)Device Drivers ManualRGEPHY(4)

-

-

-

-
rgephy — Realtek
-    8110S/8153/8169S/8211 internal 10/100/1000 PHY driver

-

-

-

-
rgephy* at mii? phy ?

-

-

-

-
The rgephy driver supports the internal
-    PHY found on Realtek 8110S/8153/8169S/8211 Ethernet adapters.

-

-

-

-
axen(4), ifmedia(4),
-    intro(4), mii(4),
-    re(4), ure(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
May 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/rlphy.4 4.html b/static/netbsd/man4/rlphy.4 4.html
deleted file mode 100644
index e4e2ab69..00000000
--- a/static/netbsd/man4/rlphy.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
RLPHY(4)Device Drivers ManualRLPHY(4)

-

-

-

-
rlphy — Realtek
-    8139/8201 and IC Plus IP101 Ethernet PHY driver

-

-

-

-
rlphy* at mii? phy ?

-

-

-

-
The rlphy driver supports the internal
-    physical layer interface (PHY) found on Realtek Semiconductor RTL8139 based
-    Ethernet adapters, RTL8201E, RTL8201L, and IC Plus Corp IP101 Ethernet PHY
-    chips.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), rtk(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
February 9, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/rnd.4 3.html b/static/netbsd/man4/rnd.4 3.html
deleted file mode 100644
index b34b74c6..00000000
--- a/static/netbsd/man4/rnd.4 3.html	
+++ /dev/null
@@ -1,547 +0,0 @@
-
-  
-    
-    
-    
-  
-
RND(4)Device Drivers ManualRND(4)

-

-

-

-
rnd — random
-    number generator

-

-

-

-
The /dev/random and
-    /dev/urandom devices generate bytes randomly with
-    uniform distribution. Every read from them is independent.

-
/dev/urandom never blocks.

-
/dev/random sometimes blocks. It will
-    block early at boot if the system's state is known to be predictable.

-
Applications should read from
-    /dev/urandom, or the sysctl(7)
-    variable kern.arandom, when they need randomly
-    generated data, e.g. key material for cryptography or seeds for simulations.
-    The kern.arandom variable is limited to 256 bytes
-    per read, but is otherwise equivalent to reading from
-    /dev/urandom and always works even in a
-    chroot(8) environment without requiring a populated
-    /dev tree and without opening a file descriptor, so
-    kern.arandom may be preferable to use in
-  libraries.

-
Systems should be engineered to judiciously read at least once
-    from /dev/random at boot before running any services
-    that talk to the internet or otherwise require cryptography, in order to
-    avoid generating keys predictably. /dev/random may
-    block at any time, so programs that read from it must be prepared to handle
-    blocking. Interactive programs that block due to reads from
-    /dev/random can be especially frustrating.

-
If interrupted by a signal, reads from either
-    /dev/random or /dev/urandom
-    may return short, so programs that handle signals must be prepared to retry
-    reads.

-
Writing to either /dev/random or
-    /dev/urandom influences subsequent output of both
-    devices, guaranteed to take effect at next open. If you have a coin in your
-    pocket, you can flip it 256 times and feed the outputs to
-    /dev/random to guarantee your system is in a state
-    that nobody but you and the bored security guard watching the surveillance
-    camera in your office can guess:

-

-
% echo
-  tthhhhhthhhththtthhhhthtththttth... > /dev/random

-
(Sequence generated from a genuine US quarter dollar, guaranteed
-    random.)

-

-

-

-
The rnd subsystem provides the following
-    security properties against two different classes of attackers, provided
-    that there is enough entropy from entropy sources not seen by attackers:

-
    
-  
  • An attacker who has seen some outputs and can supply some entropy sources'
-      inputs to the operating system cannot predict past or future unseen
-      outputs.
    • 
-  
  • An attacker who has seen the entire state of the machine cannot predict
-      past outputs.
    • 
-

-
One ‘output’ means a single read, no matter how
-    short it is.

-
‘Cannot predict’ means it is conjectured of the
-    cryptography in /dev/random that any computationally
-    bounded attacker who tries to distinguish outputs from uniform random cannot
-    do more than negligibly better than uniform random guessing.

-

-

-

-
The operating system continuously makes observations of hardware
-    devices, such as network packet timings, disk seek delays, and keystrokes.
-    The observations are combined into a seed for a cryptographic pseudorandom
-    number generator (PRNG) which is used to generate the outputs of both
-    /dev/random and
-    /dev/urandom.

-
An attacker may be able to guess with
-    nonnegligible chance of success what your last keystroke was, but guessing
-    every observation the operating system may have made is more difficult. The
-    difficulty of the best strategy at guessing a random variable is analyzed as
-    the -log_2 of the highest probability of any outcome, measured in bits, and
-    called its
-    ,
-    or entropy for short in cryptography. For example:

-

-
    
-  
  • A fair coin toss has one bit of entropy.
    • 
-  
  • A fair (six-sided) die roll has a little over 2.5 bits of entropy.
    • 
-  
  • A string of two independent fair coin tosses has two bits of entropy.
    • 
-  
  • The toss of a pair of fair coins that are glued together has one bit of
-      entropy.
    • 
-  
  • A uniform random distribution with n possibilities
-      has log_2 n bits of entropy.
    • 
-  
  • An utterance from an accounting troll who always says ‘nine’
-      has zero bits of entropy.
    • 
-

-
Note that entropy is a property of an observable physical process,
-    like a coin toss, or of a state of knowledge about that physical process; it
-    is not a property of a specific sample obtained by observing it, like the
-    string ‘tthhhhht’. There are also kinds of entropy in
-    information theory other than min-entropy, including the more well-known
-    Shannon entropy, but they are not relevant here.

-
Hardware devices that the operating system monitors for
-    observations are called entropy sources, and the
-    observations are combined into an entropy pool. The
-    rndctl(8) command queries information about entropy
-    sources and the entropy pool, and can control which entropy sources the
-    operating system uses or ignores.

-
256 bits of entropy is typically considered intractable to guess
-    with classical computers and with current models of the capabilities of
-    quantum computers.

-
Systems with nonvolatile storage should store a secret from
-    /dev/urandom on disk during installation or
-    shutdown, and feed it back during boot, so that the work the operating
-    system has done to gather entropy — including the work its operator
-    may have done to flip a coin! — can be saved from one boot to the
-    next, and so that newly installed systems are not vulnerable to generating
-    cryptographic keys predictably.

-
The boot loaders in some NetBSD ports
-    support a command to load a seed from disk before the kernel has started.
-    For those that don't, the rndctl(8) command can do it once
-    userland has started, for example by setting
-    ‘random_seed=YES’ in
-    /etc/rc.conf, which is enabled by default; see
-    rc.conf(5).

-

-

-

-
Some people worry about recovery from state compromise —
-    that is, ensuring that even if an attacker sees the entire state of the
-    operating system, then the attacker will be unable to predict any new future
-    outputs as long as the operating system gathers fresh entropy quickly
-    enough.

-
But if an attacker has seen the entire state of your machine,
-    refreshing entropy is probably the least of your worries, so we do not
-    address that threat model here.

-
The rnd subsystem does
-     automatically
-    defend against hardware colluding with an attacker to influence entropy
-    sources based on the state of the operating system.

-
For example, a PCI device or CPU instruction for random number
-    generation which has no side channel to an attacker other than the
-    /dev/urandom device could be bugged to observe all
-    other entropy sources, and to carefully craft ‘observations’
-    that cause a certain number of bits of /dev/urandom
-    output to be ciphertext that either is predictable to an attacker or conveys
-    a message to an attacker.

-
No amount of scrutiny by the system's operator could detect this.
-    The only way to prevent this attack would be for the operator to disable all
-    entropy sources that may be colluding with an attacker. If you're not sure
-    which ones are not, you can always disable all of them and fall back to the
-    coin in your pocket.

-

-

-

-
The /dev/random and
-    /dev/urandom devices support a number of ioctls,
-    defined in the <sys/rndio.h>
-    header file, for querying and controlling the entropy pool.

-
Since timing between hardware events contributes to the entropy
-    pool, statistics about the entropy pool over time may serve as a side
-    channel for the state of the pool, so access to such statistics is
-    restricted to the super-user and should be used with caution.

-
Several ioctls are concerned with particular entropy sources,
-    described by the following structure:

-

-
typedef struct {
-	char		name[16];	/* symbolic name */
-	uint32_t	total;		/* estimate of entropy provided */
-	uint32_t	type;		/* RND_TYPE_* value */
-	uint32_t	flags;		/* RND_FLAG_* mask */
-} rndsource_t;
-
-#define	RND_TYPE_UNKNOWN
-#define	RND_TYPE_DISK		/* disk device */
-#define	RND_TYPE_ENV		/* environment sensor (temp, fan, &c.) */
-#define	RND_TYPE_NET		/* network device */
-#define	RND_TYPE_POWER		/* power events */
-#define	RND_TYPE_RNG		/* hardware RNG */
-#define	RND_TYPE_SKEW		/* clock skew */
-#define	RND_TYPE_TAPE		/* tape drive */
-#define	RND_TYPE_TTY		/* tty device */
-#define	RND_TYPE_VM		/* virtual memory faults */
-
-#define	RND_TYPE_MAX		/* value of highest-numbered type */
-
-#define	RND_FLAG_COLLECT_TIME		/* use timings of samples */
-#define	RND_FLAG_COLLECT_VALUE		/* use values of samples */
-#define	RND_FLAG_ESTIMATE_TIME		/* estimate entropy of timings */
-#define	RND_FLAG_ESTIMATE_VALUE		/* estimate entropy of values */
-#define	RND_FLAG_NO_COLLECT		/* ignore samples from this */
-#define	RND_FLAG_NO_ESTIMATE		/* do not estimate entropy */

-

-
The following ioctls are supported:

-

-  

-    (uint32_t)

-  
Return the number of bits of entropy the system is estimated to have.

-  

-    (rndstat_t)

-  

-    

-    
typedef struct {
-	uint32_t	start;
-	uint32_t	count;
-	rndsource_t	source[RND_MAXSTATCOUNT];
-} rndstat_t;

-    

-    
Fill the source array with information
-        about up to count entropy sources, starting at
-        start. The actual number of sources described is
-        returned in count. At most
-        RND_MAXSTATCOUNT sources may be requested at
-        once.

-  

-  

-    (rndstat_name_t)

-  

-    

-    
typedef struct {
-	char		name[16];
-	rndsource_t	source;
-} rndstat_name_t;

-    

-    
Fill source with information about the
-        entropy source named name, or fail with
-        ENOENT if there is none.

-  

-  

-    (rndctl_t)

-  

-    

-    
typedef struct {
-	char		name[16];
-	uint32_t	type;
-	uint32_t	flags;
-	uint32_t	mask;
-} rndctl_t;

-    

-    
For each entropy source of the type
-        type, or if type is
-        0xff then for the entropy source named
-        name, replace the flags in
-        mask by flags.

-  

-  

-    (rnddata_t)

-  

-    

-    
typedef struct {
-	uint32_t	len;
-	uint32_t	entropy;
-	unsigned char	data[RND_SAVEWORDS * sizeof(uint32_t)];
-} rnddata_t;

-    

-    
Feed len bytes of data to the entropy
-        pool. The sample is expected to have been drawn with at least
-        entropy bits of entropy.

-    
This ioctl can be used only once per boot. It is intended for
-        a system that saves entropy to disk on shutdown and restores it on boot,
-        so that the system can immediately be unpredictable without having to
-        wait to gather entropy.

-  

-  

-    (rndpoolstat_t)

-  

-    

-    
typedef struct {
-	uint32_t poolsize;	/* size of each LFSR in pool */
-	uint32_t threshold;	/* no. bytes of pool hash returned */
-	uint32_t maxentropy;	/* total size of pool in bits */
-	uint32_t added;		/* no. bits of entropy ever added */
-	uint32_t curentropy;	/* current entropy `balance' */
-	uint32_t discarded;	/* no. bits dropped when pool full */
-	uint32_t generated;	/* no. bits yielded by pool while
-				   curentropy is zero */
-} rndpoolstat_t;

-    

-    
Return various statistics about entropy.

-  

-

-

-

-

-
The following sysctl(8) variables provided by
-    rnd can be set by privileged users:

-

-  

-    (bool)

-  
(Default on.) Enables entering data into the entropy pool. If disabled, no
-      new data can be entered into the entropy pool, whether by device drivers,
-      by writes to /dev/random or
-      /dev/urandom, or by the
-      RNDADDDATA ioctl.

-  

-    (bool)

-  
(Default off.) Enables ‘entropy depletion’, meaning that
-      even after attaining full entropy, the kernel subtracts the number of bits
-      read out of the entropy pool from its estimate of the system entropy. This
-      is not justified by modern cryptography — an adversary will never
-      guess the 256-bit secret in a Keccak sponge no matter how much output from
-      the sponge they see — but may be useful for testing.

-  

-    (int)

-  
Trigger for entropy consolidation: executing
-    

-    
# sysctl -w
-      kern.entropy.consolidate=1

-    
causes the system to consolidate pending entropy from per-CPU
-        pools into the global pool, and waits until done.

-  

-

-
The following read-only sysctl(8) variables
-    provide information to privileged users about the state of the entropy
-  pool:

-

-  

-    (unsigned int)

-  
Number of bits of entropy the system is waiting for in the global pool
-      before reads from /dev/random will return without
-      blocking. When zero, the system is considered to have full entropy.

-  

-    (unsigned int)

-  
Number of bits of entropy pending in per-CPU pools. This is the amount of
-      entropy that will be contributed to the global pool at the next
-      consolidation, such as from triggering
-      kern.entropy.consolidate.

-

-
The following read-only sysctl(8) variables
-    provide information to any users, privileged or unprivileged:

-

-  

-    (unsigned int)

-  
An integer that changes whenever the system determines applications should
-      reseed from the system entropy pool. This can happen for various reasons:
-    
    
-      
  • The system has reached full entropy for the first time.
    • 
-      
  • A virtual machine clone has been detected (e.g., by
-          acpivmgenid(4)).
    • 
-      
  • An operator has set
-        kern.entropy.consolidate.
    • 
-    

-    
Consulted by arc4random(3), and inside the
-        kernel by subsystems such as cprng(9), to decide
-        whether to reseed.

-    
Initially set to 2^32 - 1 (i.e.,
-        (unsigned)-1) meaning the system has never
-        reached full entropy; never again set to 2^32 - 1. Never zero, so
-        applications can initialize a cache of the epoch to zero to ensure they
-        reseed the next time they check whether it is different from the stored
-        epoch.

-  

-

-

-

-

-
(This section describes the current implementation of the
-    rnd subsystem at the time of writing. It may be
-    out-of-date by the time you read it, and nothing in here should be construed
-    as a guarantee about the behaviour of the
-    /dev/random and /dev/urandom
-    devices.)

-
Device drivers gather samples from entropy sources and absorb them
-    into a collection of per-CPU Keccak sponges called ‘entropy
-    pools’ using the rnd(9) kernel API. The device
-    driver furnishes an estimate for the entropy of the sampling process, under
-    the assumption that each sample is independent. When the estimate of entropy
-    pending among the per-CPU entropy pools reaches a threshold of 256 bits, the
-    entropy is drawn from the per-CPU pools and consolidated into a global pool.
-    Keys for /dev/random,
-    /dev/urandom, kern.arandom,
-    and the in-kernel cprng(9) subsystem are extracted from
-    the global pool.

-
Early after boot, before CPUs have been detected, device drivers
-    instead enter directly into the global pool. If anything in the system
-    extracts data from the pool before the threshold has been reached at least
-    once, the system will print a warning to the console and reset the entropy
-    estimate to zero. The reason for resetting the entropy estimate to zero in
-    this case is that an adversary who can witness output from the pool with
-    partial entropy — say, 32 bits — can undergo a feasible brute
-    force search to ascertain the complete state of the pool; as such, the
-    entropy of the adversary's state of knowledge about the pool is zero.

-
If the operator is confident that the drivers' estimates of the
-    entropy of the sampling processes are too conservative, the operator can
-    issue

-

-
# sysctl -w
-  kern.entropy.consolidate=1

-
to force consolidation into the global pool. The operator can also
-    fool the system into thinking it has more entropy than it does by feeding
-    data from /dev/urandom into
-    /dev/random, but this voids the security model and
-    should be limited to testing purposes.

-

-    reads from /dev/urandom are served by a persistent
-    per-CPU Hash_DRBG instance that is reseeded from the entropy pool after any
-    entropy consolidation. Reads from /dev/random and
-     reads
-    from /dev/urandom are served by a temporary
-    Hash_DRBG seeded from the entropy pool on each read.

-
When ‘entropy depletion’ is enabled by setting the
-    sysctl variable kern.entropy.depletion to 1, every
-    read from /dev/random is limited to 256 bits, since
-    reading more than that would nearly always block again.

-

-

-

-

-  
/dev/random

-  
Uniform random byte source. May block.

-  
/dev/urandom

-  
Uniform random byte source. Never blocks.

-

-

-

-

-
The rnd subsystem may print the following
-    warnings to the console likely indicating security issues:

-

-  
WARNING: system needs entropy for security; see entropy(7)

-  
A process tried to draw from the entropy pool before enough inputs from
-      reliable entropy sources have been entered.
-    
The entropy may be low enough that an adversary who sees the
-        output could guess the state of the pool by brute force, so in this
-        event the system resets its estimate of entropy to none.

-    
This message is rate-limited to happen no more often than once
-        per minute, so if you want to make sure it is gone you should consult
-        kern.entropy.needed to confirm it is zero.

-  

-

-
The rnd subsystem may print any of various
-    messages about obtaining an entropy seed from the bootloader to diagnose
-    saving and loading seeds on disk:

-

-  
entropy: entering seed from bootloader with N bits of entropy

-  
The bootloader provided an entropy seed to the kernel, which recorded an
-      estimate of N bits of entropy in the process that generated it.

-  
entropy: no seed from bootloader

-  
The bootloader did not provide an entropy seed to the kernel before
-      starting the kernel. This does not necessarily indicate a problem; not all
-      bootloaders support the option, and the rc.conf(5)
-      setting random_seed=YES can serve instead.

-  
entropy: invalid seed length N, expected sizeof(rndsave_t) = M

-  
The bootloader provided an entropy seed of the wrong size to the kernel.
-      This may indicate a bug in rndctl(8). The seed will be
-      ignored.

-  
entropy: invalid seed checksum

-  
The entropy seed provided by the bootloader was malformed. The seed will
-      be entered into the entropy pool, but it will be considered to contribute
-      no entropy.

-  
entropy: double-seeded by bootloader

-  
A buggy bootloader tried to provide an entropy seed more than once to the
-      kernel. Subsequent seeds will be entered into the entropy pool, but they
-      will be considered to contribute no entropy.

-  
entropy: best effort

-  
The system has gathered enough samples from interrupt timings and other
-      non-confident sources of entropy for the first time to unblock
-      /dev/random, but it may not have full entropy from
-      a seed or hardware random number generator.

-  
entropy: ready

-  
The system has full entropy for the first time.

-

-

-

-

-
arc4random(3), acpivmgenid(4),
-    entropy(7), rndctl(8),
-    cprng(9), rnd(9)

-
Elaine Barker and
-    John Kelsey, Recommendation for
-    Random Number Generation Using Deterministic Random Bit Generators,
-    National Institute of Standards and Technology,
-    https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final,
-    United States Department of Commerce,
-    June 2015, NIST Special
-    Publication 800-90A, Revision 1.

-
Meltem Sönmez
-    Turan, Elaine Barker, John
-    Kelsey, Kerry A. McKay,
-    Mary L. Baish, and Mike
-    Boyle, Recommendations for the Entropy Sources Used
-    for Random Bit Generation, National Institute of
-    Standards and Technology,
-    https://csrc.nist.gov/publications/detail/sp/800-90b/final,
-    United States Department of Commerce,
-    January 2018, NIST Special
-    Publication 800-90B.

-
Daniel J. Bernstein,
-    Entropy Attacks!,
-    http://blog.cr.yp.to/20140205-entropy.html,
-    2014-02-05.

-
Nadia Heninger,
-    Zakir Durumeric, Eric
-    Wustrow, and J. Alex Halderman,
-    Mining Your Ps and Qs: Detection of Widespread Weak Keys
-    in Network Devices, Proceedings of the 21st USENIX
-    Security Symposium, USENIX,
-    https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger,
-    https://factorable.net/,
-    205-220, August
-    2012.

-
Edwin T. Jaynes,
-    Probability Theory: The Logic of Science,
-    Cambridge University Press,
-    https://bayes.wustl.edu/,
-    2003.

-

-

-

-
The /dev/random and
-    /dev/urandom devices first appeared in
-    NetBSD 1.3.

-

-

-

-
The rnd subsystem was first implemented by
-    Michael Graff
-    <explorer@flame.org>,
-    was then largely rewritten by Thor Lancelot Simon
-    <tls@NetBSD.org>, and
-    was most recently largely rewritten by Taylor R.
-    Campbell
-    <riastradh@NetBSD.org>.

-

-

-

-
Many people are confused about what
-    /dev/random and /dev/urandom
-    mean. Unfortunately, no amount of software engineering can fix that.

-

-

-
-  
-    
-    
-  
-
August 27, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/route.4 3.html b/static/netbsd/man4/route.4 3.html
deleted file mode 100644
index 7e236c50..00000000
--- a/static/netbsd/man4/route.4 3.html	
+++ /dev/null
@@ -1,337 +0,0 @@
-
-  
-    
-    
-    
-  
-
ROUTE(4)Device Drivers ManualROUTE(4)

-

-

-

-
route — kernel
-    packet forwarding database

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <net/if.h>
-  

-  #include <net/route.h>

-
int
-  

-  socket(PF_ROUTE,
-    SOCK_RAW,
-    int family);

-

-

-

-
UNIX provides some packet routing
-    facilities. The kernel maintains a routing information database, which is
-    used in selecting the appropriate network interface when transmitting
-    packets.

-
A user process (or possibly multiple co-operating processes)
-    maintains this database by sending messages over a special kind of socket.
-    This supplants fixed size ioctl(2)'s used in earlier
-    releases. Routing table changes may only be carried out by the super
-  user.

-
The operating system may spontaneously emit routing messages in
-    response to external events, such as receipt of a redirect, or failure to
-    locate a suitable route for a request. The message types are described in
-    greater detail below.

-
Routing database entries come in two flavors: for a specific host,
-    or for all hosts on a generic subnetwork (as specified by a bit mask and
-    value under the mask. The effect of wildcard or default route may be
-    achieved by using a mask of all zeros, and there may be hierarchical
-  routes.

-
When the system is booted and addresses are assigned to the
-    network interfaces, each protocol family installs a routing table entry for
-    each interface when it is ready for traffic. Normally the protocol specifies
-    the route through each interface as a “direct” connection to
-    the destination host or network. If the route is direct, the transport layer
-    of a protocol family usually requests the packet be sent to the same host
-    specified in the packet. Otherwise, the interface is requested to address
-    the packet to the gateway listed in the routing entry (i.e. the packet is
-    forwarded).

-
When routing a packet, the kernel will attempt to find the most
-    specific route matching the destination. (If there are two different mask
-    and value-under-the-mask pairs that match, the more specific is the one with
-    more bits in the mask. A route to a host is regarded as being supplied with
-    a mask of as many ones as there are bits in the destination). If no entry is
-    found, the destination is declared to be unreachable, and a routing-miss
-    message is generated if there are any listeners on the routing control
-    socket described below.

-
A wildcard routing entry is specified with a zero destination
-    address value, and a mask of all zeroes. Wildcard routes will be used when
-    the system fails to find other routes matching the destination. The
-    combination of wildcard routes and routing redirects can provide an
-    economical mechanism for routing traffic.

-
One opens the channel for passing routing control messages by
-    using the socket call shown in the synopsis above:

-
The family parameter may be
-    AF_UNSPEC which will provide routing information for
-    all address families, or can be restricted to a specific address family by
-    specifying which one is desired. There can be more than one routing socket
-    open per system.

-
Messages are formed by a header followed by a small number of
-    sockaddrs (now variable length particularly in the ISO case), interpreted by
-    position, and delimited by the new length entry in the sockaddr. An example
-    of a message with four addresses might be an ISO redirect: Destination,
-    Netmask, Gateway, and Author of the redirect. The interpretation of which
-    address are present is given by a bit mask within the header, and the
-    sequence is least significant to most significant bit within the vector.

-
Any messages sent to the kernel are returned, and copies are sent
-    to all interested listeners. The exception to this is a new address marked
-    as tentative, where copies will be sent once Duplicate Address Detection has
-    completed and the tentative flag cleared or the duplicated flag set. Also,
-    new address messages will also be emitted when other flags on the address
-    change such as deprecated and detached. The kernel will provide the process
-    ID for the sender, and the sender may use an additional sequence field to
-    distinguish between outstanding messages. However, message replies may be
-    lost when kernel buffers are exhausted.

-
The kernel may reject certain messages, and will
-    indicate this by filling in the rtm_errno field. The
-    routing code returns EEXIST if requested to
-    duplicate an existing entry, ESRCH if requested to
-    delete a non-existent entry, or ENOBUFS if
-    insufficient resources were available to install a new route. In the current
-    implementation, all routing processes run locally, and the values for
-    rtm_errno are available through the normal
-     mechanism,
-    even if the routing reply message is lost.

-
A process may avoid the expense of reading replies to its own
-    messages by issuing a setsockopt(2) call indicating that
-    the SO_USELOOPBACK option at the
-    SOL_SOCKET level is to be turned off. A process may
-    ignore all messages from the routing socket by doing a
-    shutdown(2) system call for further input.

-
A process can specify which route message types it's interested in
-    by passing an array of route message types to the
-    setsockopt(2) call with the
-    RO_MSGFILTER option at the
-    PF_ROUTE level. For example, to only get specific
-    messages:

-

-
unsigned char rtfilter[] = { RTM_IFINFO, RTM_IFANNOUNCE };
-
-if (setsockopt(routefd, PF_ROUTE, RO_MSGFILTER,
-    &rtfilter, (socklen_t)sizeof(rtfilter)) == -1)
-	err(1, "setsockopt(RO_MSGFILTER)");

-

-
A process can specify which RTM_MISS destination addresses it's
-    interested in by passing an array of struct sockaddr to the
-    setsockopt(2) call with the
-    RO_MISSFILTER option at the
-    PF_ROUTE level. For example, to only get RTM_MISS
-    messages for specific destinations:

-

-
char buf[1024] = { '\0' }, *cp = buf;
-struct sockaddr_in sin = {
-	.sin_family = AF_INET,
-	.sin_len = sizeof(sin),
-};
-
-inet_aton("192.168.0.1", &sin.sin_addr);
-memcpy(cp, &sin, sin.sin_len);
-cp += RT_ROUNDUP(sin.sin_len);
-
-inet_aton("192.168.0.2", &sin.sin_addr);
-memcpy(cp, &sin, sin.sin_len);
-cp += RT_ROUNDUP(sin.sin_len);
-
-if (setsockopt(routefd, PF_ROUTE, RO_MISSFILTER,
-    &sin, (socklen_t)(cp - buf)) == -1)
-	err(1, "setsockopt(RO_MISSFILTER)");

-

-
If a route is in use when it is deleted, the routing entry will be
-    marked down and removed from the routing table, but the resources associated
-    with it will not be reclaimed until all references to it are released. User
-    processes can obtain information about the routing entry to a specific
-    destination by using a RTM_GET message, or by
-    reading the /dev/kmem device, or by calling
-    sysctl(3).

-
The messages are:

-

-
#define	RTM_ADD		0x1    /* Add Route */
-#define	RTM_DELETE	0x2    /* Delete Route */
-#define	RTM_CHANGE	0x3    /* Change Metrics, Flags, or Gateway */
-#define	RTM_GET		0x4    /* Report Information */
-#define	RTM_LOSING	0x5    /* Kernel Suspects Partitioning */
-#define	RTM_REDIRECT	0x6    /* Told to use different route */
-#define	RTM_MISS	0x7    /* Lookup failed on this address */
-#define RTM_LOCK	0x8	/* fix specified metrics */
-#define RTM_OLDADD	0x9	/* caused by SIOCADDRT */
-#define RTM_OLDDEL	0xa	/* caused by SIOCDELRT */
-#define	RTM_ONEWADDR	0xc    /* Old (pre-8.0) RTM_NEWADDR message */
-// #define RTM_RESOLVE	0xb	/* req to resolve dst to LL addr */
-#define	RTM_ODELADDR	0xd    /* Old (pre-8.0) RTM_DELADDR message */
-#define	RTM_OOIFINFO	0xe    /* Old (pre-1.5) RTM_IFINFO message */
-#define	RTM_OIFINFO	0xf    /* Old (pre-6.0) RTM_IFINFO message */
-#define	RTM_IFANNOUNCE	0x10   /* iface arrival/departure */
-#define	RTM_IEEE80211	0x11	/* IEEE80211 wireless event */
-#define	RTM_SETGATE	0x12	/* set prototype gateway for clones
-				 * (see example in arp_rtrequest).
-				 */
-#define	RTM_LLINFO_UPD	0x13	/* indication to ARP/NDP/etc. that link-layer
-				 * address has changed
-				 */
-#define	RTM_IFINFO	0x14   /* iface/link going up/down etc. */
-#define	RTM_OCHGADDR	0x15   /* Old (pre-8.0) RTM_CHGADDR message */
-#define	RTM_NEWADDR	0x16   /* address being added to iface */
-#define	RTM_DELADDR	0x17   /* address being removed from iface */
-#define	RTM_CHGADDR	0x18   /* address properties changed */

-

-
A message header consists of one of the following:

-

-
struct rt_msghdr {
-    u_short rtm_msglen;        /* to skip over non-understood messages */
-    u_char  rtm_version;       /* future binary compatibility */
-    u_char  rtm_type;          /* message type */
-    u_short rtm_index;         /* index for associated ifp */
-    int     rtm_flags;         /* flags, incl kern & message, e.g. DONE */
-    int     rtm_addrs;         /* bitmask identifying sockaddrs in msg */
-    pid_t   rtm_pid;           /* identify sender */
-    int     rtm_seq;           /* for sender to identify action */
-    int     rtm_errno;         /* why failed */
-    int     rtm_use;           /* from rtentry */
-    u_long  rtm_inits;         /* which metrics we are initializing */
-    struct  rt_metrics rtm_rmx;	/* metrics themselves */
-};
-
-struct if_msghdr {
-    u_short ifm_msglen;        /* to skip over non-understood messages */
-    u_char  ifm_version;       /* future binary compatibility */
-    u_char  ifm_type;          /* message type */
-    int     ifm_addrs;         /* like rtm_addrs */
-    int     ifm_flags;         /* value of if_flags */
-    u_short ifm_index;         /* index for associated ifp */
-    struct  if_data ifm_data;  /* statistics and other data about if */
-};
-
-struct ifa_msghdr {
-    u_short ifam_msglen;       /* to skip over non-understood messages */
-    u_char  ifam_version;      /* future binary compatibility */
-    u_char  ifam_type;         /* message type */
-    u_short ifam_index;        /* index for associated ifp */
-    int     ifam_flags;        /* value of ifa_flags */
-    int     ifam_addrs;        /* like rtm_addrs */
-    pid_t   ifam_pid;          /* identify sender */
-    int     ifam_addrflags;    /* family specific address flags */
-    int     ifam_metric;       /* value of ifa_metric */
-};
-
-struct if_announcemsghdr {
-    u_short ifan_msglen;       /* to skip over non-understood messages */
-    u_char  ifan_version;      /* future binary compatibility */
-    u_char  ifan_type;         /* message type */
-    u_short ifan_index;        /* index for associated ifp */
-    char    ifan_name[IFNAMSIZ]; /* if name, e.g. "en0" */
-    u_short ifan_what;         /* what type of announcement */
-};

-

-
The RTM_IFINFO message uses a
-    if_msghdr header, the
-    RTM_NEWADDR, RTM_CHGADDR,
-    and RTM_DELADDR messages use a
-    ifa_msghdr header, the
-    RTM_IFANNOUNCE message uses a
-    if_announcemsghdr header, and all other messages use
-    the rt_msghdr header.

-
The metrics structure is:

-

-
struct rt_metrics {
-    u_long rmx_locks;          /* Kernel must leave these values alone */
-    u_long rmx_mtu;            /* MTU for this path */
-    u_long rmx_hopcount;       /* max hops expected */
-    u_long rmx_expire;         /* lifetime for route, e.g. redirect */
-    u_long rmx_recvpipe;       /* inbound delay-bandwidth product */
-    u_long rmx_sendpipe;       /* outbound delay-bandwidth product */
-    u_long rmx_ssthresh;       /* outbound gateway buffer limit */
-    u_long rmx_rtt;            /* estimated round trip time */
-    u_long rmx_rttvar;         /* estimated rtt variance */
-    u_long rmx_pksent;         /* packets sent using this route */
-};

-

-
Flags include the values:

-

-
#define	RTF_UP        0x1       /* route usable */
-#define	RTF_GATEWAY   0x2       /* destination is a gateway */
-#define	RTF_HOST      0x4       /* host entry (net otherwise) */
-#define	RTF_REJECT    0x8       /* host or net unreachable */
-#define	RTF_DYNAMIC   0x10      /* created dynamically (by redirect) */
-#define	RTF_MODIFIED  0x20      /* modified dynamically (by redirect) */
-#define	RTF_DONE      0x40      /* message confirmed */
-#define	RTF_MASK      0x80      /* subnet mask present */
-#define RTF_CONNECTED 0x100     /* hosts on this route are neighbours */
-#define RTF_LLDATA    0x400     /* used by apps to add/del L2 entries */
-#define	RTF_STATIC    0x800     /* manually added */
-#define	RTF_BLACKHOLE 0x1000    /* just discard pkts (during updates) */
-#define	RTF_PROTO2    0x4000    /* protocol specific routing flag */
-#define	RTF_PROTO1    0x8000    /* protocol specific routing flag */
-#define	RTF_SRC       0x10000   /* route has fixed source address */
-#define	RTF_ANNOUNCE  0x20000   /* announce new ARP or NDP entry */
-#define	RTF_LOCAL     0x40000   /* route represents a local address */
-#define	RTF_BROADCAST 0x80000   /* route represents a bcast address */

-

-
Specifiers for metric values in rmx_locks and rtm_inits are:

-

-
#define	RTV_MTU       0x1    /* init or lock _mtu */
-#define	RTV_HOPCOUNT  0x2    /* init or lock _hopcount */
-#define	RTV_EXPIRE    0x4    /* init or lock _expire */
-#define	RTV_RPIPE     0x8    /* init or lock _recvpipe */
-#define	RTV_SPIPE     0x10   /* init or lock _sendpipe */
-#define	RTV_SSTHRESH  0x20   /* init or lock _ssthresh */
-#define	RTV_RTT       0x40   /* init or lock _rtt */
-#define	RTV_RTTVAR    0x80   /* init or lock _rttvar */

-

-
Specifiers for which addresses are present in the messages
-  are:

-

-
#define RTA_DST       0x1    /* destination sockaddr present */
-#define RTA_GATEWAY   0x2    /* gateway sockaddr present */
-#define RTA_NETMASK   0x4    /* netmask sockaddr present */
-#define RTA_GENMASK   0x8    /* cloning mask sockaddr present */
-#define RTA_IFP       0x10   /* interface name sockaddr present */
-#define RTA_IFA       0x20   /* interface addr sockaddr present */
-#define RTA_AUTHOR    0x40   /* sockaddr for author of redirect */
-#define RTA_BRD       0x80   /* for NEWADDR, broadcast or p-p dest addr */
-#define RTA_TAG       0x100  /* route tag */

-

-
Flags for IPv6 addresses:

-

-
#define IN6_IFF_ANYCAST		0x01	/* anycast address */
-#define IN6_IFF_TENTATIVE	0x02	/* tentative address */
-#define IN6_IFF_DUPLICATED	0x04	/* DAD detected duplicate */
-#define IN6_IFF_DETACHED	0x08	/* may be detached from the link */
-#define IN6_IFF_DEPRECATED	0x10	/* deprecated address */
-#define IN6_IFF_NODAD		0x20	/* don't perform DAD on this address
-					 * (used only at first SIOC* call)
-					 */
-#define IN6_IFF_AUTOCONF	0x40	/* autoconfigurable address. */
-#define IN6_IFF_TEMPORARY	0x80	/* temporary (anonymous) address. */

-

-

-

-

-
socket(2), sysctl(3)

-

-

-

-
Since NetBSD 8.0,
-    RTF_CLONED, RTF_CLONING,
-    RTF_LLINFO, RTF_XRESOLVE and
-    RTM_RESOLVE were obsolete.
-    RTF_CONNECTED and RTF_LLDATA
-    appeared in NetBSD 8.0.

-
ifa_msghdr gained the fields ifam_pid and
-    ifam_addrflags in NetBSD 8.0.

-

-

-
-  
-    
-    
-  
-
February 4, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/rs5c372rtc.4 4.html b/static/netbsd/man4/rs5c372rtc.4 4.html
deleted file mode 100644
index dea223db..00000000
--- a/static/netbsd/man4/rs5c372rtc.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
RS5C372RTC(4)Device Drivers ManualRS5C372RTC(4)

-

-

-

-
rs5c372rtc — RICOH
-    RS5C372A and RS5C372B real-time clock

-

-

-

-
rs5c372rtc at iic? addr 0x32

-

-

-

-
The rs5c372rtc driver provides support for
-    the RICOH RS5C372A and RS5C372B real-time clock chips.

-
Access methods to retrieve and set date and time are
-    provided through the
-     interface
-    defined in todr(9).

-

-

-

-
iic(4), todr(9)

-

-

-

-
The rs5c372rtc device appeared in
-    NetBSD 4.0.

-

-

-

-
The driver only supports clock function.

-

-

-
-  
-    
-    
-  
-
September 15, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/rt.4 4.html b/static/netbsd/man4/rt.4 4.html
deleted file mode 100644
index 96e967bc..00000000
--- a/static/netbsd/man4/rt.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
RT(4)Device Drivers ManualRT(4)

-

-

-

-
rt — AIMS Lab
-    Radiotrack FM radio device driver

-

-

-

-
rt0 at isa? port 0x20c
-  

-  rt1 at isa? port 0x284
-  

-  rt2 at isa? port 0x30c
-  

-  rt3 at isa? port 0x384
-  

-  radio* at rt?

-

-

-

-
The rt driver provides support for the
-    AIMS Lab Radiotrack FM radio tuners and compatible RadioReveal RA300 and
-    SoundForte RadioX SF16-FMI FM radio tuners.

-
The Radiotrack is a stereo FM tuner that allows to tune in the
-    range 87.5 - 108.0 MHz, report signal status on the current frequency, and
-    force audio output to mono.

-
The Radiotrack cards take only one I/O port. The I/O port is set
-    by the driver to the value specified in the configuration file and must be
-    either 0x20c or 0x30c.

-

-

-

-
isa(4), radio(4)

-

-

-

-
The rt device driver appeared in
-    OpenBSD 3.0 and NetBSD
-  1.6.

-

-

-

-
The rt driver was written by Vladimir
-    Popov and Maxim Tsyplakov. The man page was written by Vladimir Popov.

-

-

-

-
Support for the SF16-FMI cards is rather ugly, volume control is
-    not working and the driver can not correctly determine signal state.

-

-

-
-  
-    
-    
-  
-
October 8, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/rtfps.4 4.html b/static/netbsd/man4/rtfps.4 4.html
deleted file mode 100644
index 77bb795c..00000000
--- a/static/netbsd/man4/rtfps.4 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTFPS(4)Device Drivers ManualRTFPS(4)

-

-

-

-
rtfps —
-    multiplexing serial communications interface

-

-

-

-
rtfps0 at isa? port 0x1230 irq 10
-  

-  com2 at rtfps0 slave 0
-  

-  com3 at rtfps0 slave 1
-  

-  com4 at rtfps0 slave 2
-  

-  com5 at rtfps0 slave 3

-

-

-

-
The rtfps driver provides support for IBM
-    RT PC boards that multiplex together up to four EIA RS-232C (CCITT V.28) or
-    RS-422A communications interfaces.

-
Each rtfps device is the master device for
-    up to four com devices. The kernel configuration
-    specifies these com devices as slave devices of the
-    rtfps device, as shown in the synopsis. The port
-    specification for the rtfps device is used to
-    compute the base addresses for the com
-  subdevices.

-

-

-

-

-  
/dev/tty0?

-  
 

-

-

-

-

-
com(4)

-

-

-

-
The rtfps driver was written by Charles
-    Hannum, based on the ast driver.

-

-

-

-
The rtfps driver is unlikely to work on
-    non-EISA and non-PCI machines. The ISA bus only asserts 10 I/O address
-    lines, and this is not enough.

-
Even on EISA and PCI machines, some address conflicts have been
-    observed. On one machine, the second port always conflicted with something
-    (though it's not clear what) and caused strange results. Disabling the
-    second port in the kernel config allowed the other three ports to function
-    correctly.

-

-

-
-  
-    
-    
-  
-
August 7, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/rtii.4 4.html b/static/netbsd/man4/rtii.4 4.html
deleted file mode 100644
index 782db109..00000000
--- a/static/netbsd/man4/rtii.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTII(4)Device Drivers ManualRTII(4)

-

-

-

-
rtii — AIMS Lab
-    Radiotrack II FM radio device driver

-

-

-

-
option RADIO_TEA5759

-

-  

-  rtii0 at isa? port 0x20c
-  

-  rtii1 at isa? port 0x30c
-  

-  radio* at rtii0

-

-

-

-
The rtii driver provides support for the
-    AIMS Lab Radiotrack II FM radio tuners.

-
The Radiotrack II is a stereo FM tuner that allows to tune in the
-    range 87.5 - 108.0 MHz, report signal status on the current frequency, force
-    audio output to mono, perform hardware signal search, and has an internal
-    AFC.

-
The Radiotrack II cards take only one I/O port. The I/O port is
-    set by the driver to the value specified in the configuration file and must
-    be either 0x20c or 0x30c.

-
Philips Semiconductors released two almost identical chips TEA5757
-    and TEA5759. The TEA5757 is used in FM-standards in which the local
-    oscillator frequency is above the radio frequency (e.g. European and
-    American standards). The TEA5759 is the version in which the oscillator
-    frequency is below the radio frequency (e.g. Japanese standards). The option
-    RADIO_TEA5759 changes the algorithm of frequency
-    calculation for the TEA5757 based cards to conform with the Japanese
-    standards.

-

-

-

-
isa(4), radio(4)

-

-

-

-
The rtii device driver appeared in
-    OpenBSD 3.0 and NetBSD
-  1.6.

-

-

-

-
The rtii driver was written by Vladimir
-    Popov and Maxim Tsyplakov. The man page was written by Vladimir Popov.

-

-

-
-  
-    
-    
-  
-
October 8, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/rtk.4 4.html b/static/netbsd/man4/rtk.4 4.html
deleted file mode 100644
index 463ec8d2..00000000
--- a/static/netbsd/man4/rtk.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTK(4)Device Drivers ManualRTK(4)

-

-

-

-
rtk — Ethernet
-    driver for Realtek 8129/8139/8100 based Ethernet boards

-

-

-

-
rtk* at cardbus? function ?
-  

-  rtk* at pci? dev ? function ?

-
Configuration of PHYs is necessary. See
-  mii(4).

-

-

-

-
The rtk device driver supports network
-    adapters based on the Realtek 8129/8139/8100 chips.

-

-

-

-
Media selection is done using ifconfig(8) using
-    the standard ifmedia(4) mechanism. Refer to those manual
-    pages for more information.

-

-

-

-
cardbus(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
August 5, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/rtsx.4 4.html b/static/netbsd/man4/rtsx.4 4.html
deleted file mode 100644
index 79113e7d..00000000
--- a/static/netbsd/man4/rtsx.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTSX(4)Device Drivers ManualRTSX(4)

-

-

-

-
rtsx — Realtek SD
-    card reader

-

-

-

-
rtsx* at pci?
-  

-  sdmmc* at rtsx?

-

-

-

-
The rtsx driver provides support for the
-    Realtek RTS5209, RTS5227, RTS5229, RTS522A, RTS525A, RTL8402, RTL8411 and
-    RTL8411B SD card readers.

-
The sdmmc(4) subsystem performs SD/MMC
-    transactions to communicate with whatever MMC, SD or SDHC devices are
-    inserted into the SD slot.

-

-

-

-
intro(4), sdmmc(4)

-

-

-

-
The rtsx driver first appeared in
-    OpenBSD 5.3 and in NetBSD
-    7.0.

-

-

-

-
The rtsx driver was written by
-    Stefan Sperling ⟨stsp@openbsd.org⟩ for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro
-    ⟨nonaka@netbsd.org⟩.

-

-

-

-
The rtsx driver does not support MS
-    (Memory Stick) and xD (Extreme Digital) devices even though the hardware
-    supports them.

-
Support for SDIO interrupts is not implemented.

-

-

-
-  
-    
-    
-  
-
April 27, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/rtw.4 3.html b/static/netbsd/man4/rtw.4 3.html
deleted file mode 100644
index 75f690bd..00000000
--- a/static/netbsd/man4/rtw.4 3.html	
+++ /dev/null
@@ -1,272 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTW(4)Device Drivers ManualRTW(4)

-

-

-

-
rtw — Realtek
-    RTL8180L IEEE 802.11b wireless network driver

-

-

-

-
rtw* at cardbus? function ?
-  

-  rtw* at pci? dev ? function ?

-

-

-

-
The rtw driver supports PCI/CardBus
-    802.11b wireless adapters based on the Realtek RTL8180L.

-
A variety of radio transceivers can be found in these devices,
-    including the Philips SA2400A, Maxim MAX2820, and GCT GRF5101, though not
-    all of them are currently supported.

-
These are the modes the rtw driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
IBSS mode

-  
Also known as  mode or
-      
-      mode. This is the standardized method of operating without an access
-      point. Stations associate with a service set. However, actual connections
-      between stations are peer-to-peer.

-  
Host AP

-  
In this mode the driver acts as an access point (base station) for other
-      cards.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
rtw supports software WEP. Wired
-    Equivalent Privacy (WEP) is the de facto encryption standard for wireless
-    networks. It can be typically configured in one of three modes: no
-    encryption; 40-bit encryption; or 104-bit encryption. Unfortunately, due to
-    serious weaknesses in WEP protocol it is strongly recommended that it not be
-    used as the sole mechanism to secure wireless communication. WEP is not
-    enabled by default.

-

-

-

-
The rtw driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5) using the following parameters:

-

-  

-    bssid

-  
Set the desired BSSID.

-  

-  
Unset the desired BSSID. The interface will automatically select a BSSID
-      in this mode, which is the default.

-  

-    n

-  
Set the channel (radio frequency) to be used by the driver based on the
-      given channel ID n.

-  

-  
Unset the desired channel to be used by the driver. The driver will
-      automatically select a channel in this mode, which is the default.

-  

-    media

-  
The rtw driver supports the following
-      media types:
-    

-    

-      

-      
Enable autoselection of the media type and options.

-      

-      
Set 802.11b DS 1Mbps operation.

-      

-      
Set 802.11b DS 2Mbps operation.

-      

-      
Set 802.11b DS 5.5Mbps operation.

-      

-      
Set 802.11b DS 11Mbps operation.

-    

-  

-  

-    opts

-  
The rtw driver supports the following media
-      options:
-    

-    

-      

-      
Select Host AP operation.

-      

-      
Select IBSS operation.

-      

-      
Select monitor mode.

-    

-  

-  

-    opts

-  
Disable the specified media options on the driver and return it to the
-      default mode of operation (BSS).

-  

-    id

-  
Set the network ID. The id can either be any text
-      string up to 32 characters in length, or a series of hexadecimal digits up
-      to 64 digits. An empty id string allows the
-      interface to connect to any available access points. By default the
-      rtw driver uses an empty string. Note that network
-      ID is synonymous with Extended Service Set ID (ESSID).

-  

-    key

-  
Enable WEP encryption using the specified key. The
-      key can either be a string, a series of hexadecimal
-      digits (preceded by ‘0x’), or a set of keys of the form
-      “n:k1,k2,k3,k4”, where ‘n’ specifies which of
-      the keys will be used for transmitted packets, and the four keys,
-      “k1” through “k4”, are configured as WEP keys.
-      If a set of keys is specified, a comma (‘,’) within the key
-      must be escaped with a backslash. Note that if multiple keys are used,
-      their order must be the same within the network.
-      rtw is capable of using both 40-bit (5 characters
-      or 10 hexadecimal digits) or 104-bit (13 characters or 26 hexadecimal
-      digits) keys.

-  

-  
Disable WEP encryption. This is the default mode of operation.

-  

-  
Enable WEP encryption with the persistent key stored in the network
-    card.

-

-

-

-

-
The following adapters should work:

-

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Bus
CardBus
CardBus
CardBus
CardBus
CardBus
CardBus
CardBus
CardBus
CardBus

-

-

-

-
The following ifconfig.if(5) example creates a
-    host-based access point on boot:

-

-
inet 192.168.1.1 255.255.255.0 NONE media autoselect \
-	mediaopt hostap ssid my_net chan 11

-

-
Configure rtw0 for WEP, using hex key
-    “0x1deadbeef1”:

-

-
# ifconfig rtw0 nwkey 0x1deadbeef1

-

-
Return rtw0 to its default settings:

-

-
# ifconfig rtw0 -bssid -chan media autoselect \
-	ssid "" -nwkey

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig rtw0 192.168.1.1 netmask 0xffffff00 ssid my_net

-

-

-

-

-
arp(4), cardbus(4),
-    ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    ifconfig.if(5), ifconfig(8)

-
Realtek,
-    http://www.realtek.com.tw.

-

-

-

-
The rtw device driver first appeared in
-    NetBSD 3.0 and then in OpenBSD
-    3.7.

-

-

-

-
The rtw driver was written by
-    David Young ⟨dyoung@NetBSD.org⟩ and
-    ported to OpenBSD by Jonathan
-    Gray
-    <jsg@openbsd.org>, who
-    wrote this man page.

-

-

-

-
Only the Philips SA2400A and Maxim MAX2820 RF transceivers are
-    known to work. Devices incorporating a GCT RF transceiver are not supported
-    due to a lack of documentation from GCT.

-
While PCI devices will attach most of them are not able to
-    transmit.

-

-

-
-  
-    
-    
-  
-
December 29, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/rtwn.4 4.html b/static/netbsd/man4/rtwn.4 4.html
deleted file mode 100644
index 20a27e7b..00000000
--- a/static/netbsd/man4/rtwn.4 4.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
RTWN(4)Device Drivers ManualRTWN(4)

-

-

-

-
rtwn — Realtek
-    RTL8188CE/RTL8192CE PCIe IEEE 802.11b/g/n wireless network device

-

-

-

-
rtwn* at pci? dev ? function ?

-

-

-

-
The rtwn driver supports PCIe wireless
-    network devices based on the Realtek RTL8188CE and RTL8192CE chipset.

-
The RTL8188CE is a highly integrated 802.11n adapter that combines
-    a MAC, a 1T1R capable baseband and an RF in a single chip. It operates in
-    the 2GHz spectrum only.

-
The RTL8192CE is a highly integrated multiple-in, multiple-out
-    (MIMO) 802.11n adapter that combines a MAC, a 2T2R capable baseband and an
-    RF in a single chip. It operates in the 2GHz spectrum only.

-
These are the modes the rtwn driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The rtwn driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the current encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it.

-
The rtwn driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5).

-

-

-

-
The driver needs the following firmware files, which are loaded
-    when an interface is brought up:

-

-

-

-  
/libdata/firmware/if_rtwn/rtl8192cfw.bin

-  
 

-  
/libdata/firmware/if_rtwn/rtl8192cfwU.bin

-  
 

-  
/libdata/firmware/if_rtwn/rtl8192cfwU_B.bin

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    rtwn0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
nwkey 0x1deadbeef1 chan 11
-dhcp

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig rtwn0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
rtwn%d: could not read firmware ...

-  
For some reason, the driver was unable to read the microcode file from the
-      filesystem. The file might be missing or corrupted.

-  
rtwn%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), netintro(4),
-    pci(4), ifconfig.if(5),
-    wpa_supplicant.conf(5), ifconfig(8),
-    wpa_supplicant(8)

-

-

-

-
The rtwn driver first appeared in
-    OpenBSD 5.8 and in NetBSD
-    8.0.

-

-

-

-
The rtwn driver was written by
-    Stefan Sperling ⟨stsp@openbsd.org⟩ for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro
-    ⟨nonaka@NetBSD.org⟩. It was based on the
-    urtwn(4) driver written by Damien
-    Bergamini ⟨damien.bergamini@free.fr⟩.

-

-

-

-
The rtwn driver does not support any of
-    the 802.11n capabilities offered by the adapters. Additional work is
-    required in ieee80211(9) before those features can be
-    supported.

-

-

-
-  
-    
-    
-  
-
August 27, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/rum.4 3.html b/static/netbsd/man4/rum.4 3.html
deleted file mode 100644
index f945a1ac..00000000
--- a/static/netbsd/man4/rum.4 3.html	
+++ /dev/null
@@ -1,315 +0,0 @@
-
-  
-    
-    
-    
-  
-
RUM(4)Device Drivers ManualRUM(4)

-

-

-

-
rum — Ralink
-    Technology USB IEEE 802.11a/b/g wireless network device

-

-

-

-
rum* at uhub? port ?

-

-

-

-
The rum driver supports USB 2.0 wireless
-    adapters based on the Ralink RT2501USB and RT2601USB chipsets.

-
The RT2501USB chipset is the second generation of 802.11a/b/g
-    adapters from Ralink. It consists of two integrated chips, an RT2571W
-    MAC/BBP and an RT2528 or RT5226 radio transceiver.

-
The RT2601USB chipset consists of two integrated chips, an RT2671
-    MAC/BBP and an RT2527 or RT5225 radio transceiver. This chipset uses the
-    IEEE 802.11n MIMO (multiple-input multiple-output) technology with multiple
-    antennas to extend the operating range of the adapter and to achieve higher
-    throughput.

-
These are the modes the rum driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
IBSS mode

-  
Also known as  mode or
-      
-      mode. This is the standardized method of operating without an access
-      point. Stations associate with a service set. However, actual connections
-      between stations are peer-to-peer.

-  
Host AP

-  
In this mode the driver acts as an access point (base station) for other
-      cards.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The rum driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it.

-

-

-

-
The rum driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5) using the following parameters:

-

-  

-    bssid

-  
Set the desired BSSID.

-  

-  
Unset the desired BSSID. The interface will automatically select a BSSID
-      in this mode, which is the default.

-  

-    n

-  
Set the channel (radio frequency) to be used by the driver based on the
-      given channel ID n.

-  

-  
Unset the desired channel to be used by the driver. The driver will
-      automatically select a channel in this mode, which is the default.

-  

-    media

-  
The rum driver supports the following
-      media types:
-    

-    

-      

-      
Enable autoselection of the media type and options.

-      

-      
Set 802.11b DS 1Mbps operation.

-      

-      
Set 802.11b DS 2Mbps operation.

-      

-      
Set 802.11b DS 5.5Mbps operation.

-      

-      
Set 802.11b DS 11Mbps operation.

-      

-      
Set 802.11a/g OFDM 6Mbps operation.

-      

-      
Set 802.11a/g OFDM 9Mbps operation.

-      

-      
Set 802.11a/g OFDM 12Mbps operation.

-      

-      
Set 802.11a/g OFDM 18Mbps operation.

-      

-      
Set 802.11a/g OFDM 24Mbps operation.

-      

-      
Set 802.11a/g OFDM 36Mbps operation.

-      

-      
Set 802.11a/g OFDM 48Mbps operation.

-      

-      
Set 802.11a/g OFDM 54Mbps operation.

-    

-  

-  

-    opts

-  
The rum driver supports the following media
-      options:
-    

-    

-      

-      
Select Host AP operation.

-      

-      
Select IBSS operation.

-      

-      
Select monitor mode.

-    

-  

-  

-    opts

-  
Disable the specified media options on the driver and return it to the
-      default mode of operation (BSS).

-  

-    mode

-  
The rum driver supports the following modes:
-    

-    

-      

-      
Force 802.11a operation.

-      

-      
Force 802.11b operation.

-      

-      
Force 802.11g operation.

-    

-  

-  

-    id

-  
Set the network ID. The id can either be any text
-      string up to 32 characters in length, or a series of hexadecimal digits up
-      to 64 digits. An empty id string allows the
-      interface to connect to any available access points. By default the
-      rum driver uses an empty string. Note that network
-      ID is synonymous with Extended Service Set ID (ESSID).

-  

-    key

-  
Enable WEP encryption using the specified key. The
-      key can either be a string, a series of hexadecimal
-      digits (preceded by ‘0x’), or a set of keys of the form
-      “n:k1,k2,k3,k4”, where ‘n’ specifies which of
-      the keys will be used for transmitted packets, and the four keys,
-      “k1” through “k4”, are configured as WEP keys.
-      If a set of keys is specified, a comma (‘,’) within the key
-      must be escaped with a backslash. Note that if multiple keys are used,
-      their order must be the same within the network.
-      rum is capable of using both 40-bit (5 characters
-      or 10 hexadecimal digits) or 104-bit (13 characters or 26 hexadecimal
-      digits) keys.

-  

-  
Disable WEP encryption. This is the default mode of operation.

-

-

-

-

-
The following firmware file is loaded when an interface is brought
-    up:

-

-

-

-  
/libdata/firmware/rum/rum-rt2573

-  
 

-

-

-See firmload(9) for how to change this.
-

-

-

-
The following adapters should work:

-

-

-

-  
Airlink101 AWLL5025

-  
 

-  
ASUS WL-167g ver 2

-  
 

-  
Belkin F5D7050 ver 3

-  
 

-  
Belkin F5D9050 ver 3

-  
 

-  
CNet CWD-854 ver F

-  
 

-  
Conceptronic C54RU ver 2

-  
 

-  
D-Link DWL-G122 rev C1

-  
 

-  
D-Link WUA-1340

-  
 

-  
Edimax EW-7318USG

-  
 

-  
Gigabyte GN-WB01GS

-  
 

-  
Hawking HWUG1

-  
 

-  
LevelOne WNC-0301USB

-  
 

-  
Linksys WUSB54G rev C

-  
 

-  
Planex GW-USMM

-  
 

-  
Senao NUB-3701

-  
 

-  
Sitecom WL-113 ver 2

-  
 

-  
Sitecom WL-172

-  
 

-  
Synet MW-P54SS

-  
 

-  
TP-LINK TL-WN321G

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    rum0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11:

-

-
inet 192.168.1.1 netmask 255.255.255.0 nwkey 0x1deadbeef1 chan 11

-

-
The following ifconfig.if(5) example creates a
-    host-based access point on boot:

-

-
inet 192.168.1.1 netmask 255.255.255.0 media autoselect \
-	mediaopt hostap nwid my_net chan 11

-

-
Configure rum0 for WEP, using hex key
-    “0x1deadbeef1”:

-

-
# ifconfig rum0 nwkey 0x1deadbeef1

-

-
Return rum0 to its default settings:

-

-
# ifconfig rum0 -bssid -chan media autoselect \
-	nwid "" -nwkey

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig rum0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
rum%d: failed loadfirmware of file %s

-  
For some reason, the driver was unable to read the microcode file from the
-      filesystem. The file might be missing or corrupted.

-  
rum%d: could not load 8051 microcode

-  
An error occurred while attempting to upload the microcode to the onboard
-      8051 microcontroller unit.

-  
rum%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), usb(4),
-    ifconfig.if(5), hostapd(8),
-    ifconfig(8), firmload(9)

-
Ralink
-    Technology

-

-

-

-
The rum driver first appeared in
-    NetBSD 4.0 and OpenBSD
-  4.0.

-

-

-

-
The rum driver was written by
-    Niall O'Higgins
-    <niallo@openbsd.org>
-    and
-  

-  Damien Bergamini
-    <damien@openbsd.org>.

-

-

-

-
The rum driver supports automatic control
-    of the transmit speed in BSS mode only. Therefore the use of a
-    rum adapter in Host AP mode is discouraged.

-
The Synet MW-P54SS USB Wireless Broadband Router first attaches as
-    a virtual cd(4) device on the umass(4)
-    mass storage bus. It will re-attach with this driver after using
-    eject(1) on the corresponding device.

-

-

-
-  
-    
-    
-  
-
September 21, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/run.4 4.html b/static/netbsd/man4/run.4 4.html
deleted file mode 100644
index d3d98964..00000000
--- a/static/netbsd/man4/run.4 4.html	
+++ /dev/null
@@ -1,280 +0,0 @@
-
-  
-    
-    
-    
-  
-
RUN(4)Device Drivers ManualRUN(4)

-

-

-

-
run — Ralink
-    Technology USB IEEE 802.11a/b/g/n wireless network device

-

-

-

-
run* at uhub? port ?

-

-

-

-
The run driver supports USB 2.0 wireless
-    adapters based on the Ralink RT2700U, RT2800U and RT3000U chipsets.

-
The RT2700U chipset consists of two integrated chips, an RT2770
-    MAC/BBP and an RT2720 (1T2R) or RT2750 (dual-band 1T2R) radio
-  transceiver.

-
The RT2800U chipset consists of two integrated chips, an RT2870
-    MAC/BBP and an RT2820 (2T3R) or RT2850 (dual-band 2T3R) radio
-  transceiver.

-
The RT3000U is a single-chip solution based on an RT3070 MAC/BBP
-    and an RT3020 (1T1R), RT3021 (1T2R), RT3022 (2T2R) or RT3052 (dual-band
-    2T2R) radio transceiver.

-
These are the modes the run driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The run driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it. The
-    run driver offloads both encryption and decryption
-    of data frames to the hardware for the WEP40, WEP104, TKIP(+MIC) and CCMP
-    ciphers.

-
The run driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5).

-

-

-

-
The driver needs the following firmware files, which are loaded
-    when an interface is brought up:

-

-

-

-  
/libdata/firmware/run/run-rt2870

-  
 

-  
/libdata/firmware/run/run-rt3071

-  
 

-

-

-

-

-

-
The following adapters should work:

-

-

-

-  
Airlink101 AWLL6090

-  
 

-  
ASUS USB-N11

-  
 

-  
ASUS USB-N13

-  
 

-  
ASUS WL-160N

-  
 

-  
Belkin F5D8051 ver 3000

-  
 

-  
Belkin F5D8053

-  
 

-  
Belkin F5D8055

-  
 

-  
Belkin F6D4050 ver 1

-  
 

-  
Belkin F6D4050 ver 2

-  
 

-  
Belkin F7D1101 ver 2

-  
 

-  
Buffalo WLI-UC-AG300N

-  
 

-  
Buffalo WLI-UC-G300N

-  
 

-  
Buffalo WLI-UC-G301N

-  
 

-  
Buffalo WLI-UC-GN

-  
 

-  
Buffalo WLI-UC-GNHP

-  
 

-  
Buffalo WLI-UC-GNM

-  
 

-  
Buffalo WLI-UC-GNM2

-  
 

-  
Cisco AM10

-  
 

-  
Corega CG-WLUSB2GNL

-  
 

-  
Corega CG-WLUSB2GNR

-  
 

-  
Corega CG-WLUSB300AGN

-  
 

-  
Corega CG-WLUSB300GNM

-  
 

-  
D-Link DWA-130 rev B1

-  
 

-  
D-Link DWA-140

-  
 

-  
DrayTek Vigor N61

-  
 

-  
Edimax EW-7711UAn

-  
 

-  
Edimax EW-7711UTn

-  
 

-  
Edimax EW-7717Un

-  
 

-  
Edimax EW-7718Un

-  
 

-  
Edimax EW-7722UTn

-  
 

-  
Gigabyte GN-WB30N

-  
 

-  
Gigabyte GN-WB31N

-  
 

-  
Gigabyte GN-WB32L

-  
 

-  
Hawking HWDN1

-  
 

-  
Hawking HWUN1

-  
 

-  
Hawking HWUN2

-  
 

-  
Hercules HWNU-300

-  
 

-  
Linksys AE1000

-  
 

-  
Linksys WUSB54GC v3

-  
 

-  
Linksys WUSB600N

-  
 

-  
Logitec LAN-W150N/U2

-  
 

-  
Logitec LAN-W300N/U2

-  
 

-  
Mvix Nubbin MS-811N

-  
 

-  
Planex GW-US300Mini-X

-  
 

-  
Planex GW-US300MiniS

-  
 

-  
Planex GW-US300MiniW

-  
 

-  
Planex GW-USMicro300

-  
 

-  
Planex GW-USMicroN

-  
 

-  
Sitecom WL-182

-  
 

-  
Sitecom WL-188

-  
 

-  
Sitecom WL-301

-  
 

-  
Sitecom WL-302

-  
 

-  
Sitecom WL-315

-  
 

-  
Sitecom WLA-4000

-  
 

-  
Sitecom WLA-5000

-  
 

-  
SMC SMCWUSBS-N2

-  
 

-  
Sweex LW153

-  
 

-  
Sweex LW303

-  
 

-  
Sweex LW313

-  
 

-  
TRENDnet TEW-645UB

-  
 

-  
Unex DNUR-81

-  
 

-  
Unex DNUR-82

-  
 

-  
ZyXEL NWD-211AN

-  
 

-  
ZyXEL NWD-271N

-  
 

-  
ZyXEL NWD2105

-  
 

-  
ZyXEL NWD210N

-  
 

-  
ZyXEL NWD2205

-  
 

-  
ZyXEL NWD270N

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    run0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
dhcp NONE NONE NONE nwkey 0x1deadbeef1 chan 11

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig run0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
run%d: error %d, could not read firmware %s

-  
For some reason, the driver was unable to read the microcode file from the
-      filesystem. The file might be missing or corrupted.

-  
run%d: could not load 8051 microcode

-  
An error occurred while attempting to upload the microcode to the onboard
-      8051 microcontroller unit.

-  
run%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), usb(4),
-    ifconfig.if(5), wpa_supplicant.conf(5),
-    ifconfig(8), wpa_supplicant(8)

-
Ralink Technology:
-    http://www.ralinktech.com/

-

-

-

-
The run driver first appeared in
-    OpenBSD 4.5 and in NetBSD
-    7.0.

-

-

-

-
The run driver was written by
-    Damien Bergamini ⟨damien@openbsd.org⟩
-    for OpenBSD and ported to
-    NetBSD by FUKAUMI Naoki.

-

-

-

-
The run driver does not support any of the
-    802.11n capabilities offered by the RT2800 and RT3000 chipsets. Additional
-    work is required in ieee80211(9) before those features can
-    be supported.

-

-

-
-  
-    
-    
-  
-
July 31, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/s390rtc.4 4.html b/static/netbsd/man4/s390rtc.4 4.html
deleted file mode 100644
index af0cec89..00000000
--- a/static/netbsd/man4/s390rtc.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
S390RTC(4)Device Drivers ManualS390RTC(4)

-

-

-

-
s390rtc — Seiko
-    Instruments S-35390 real-time clock

-

-

-

-
s390rtc* at iic? addr 0x30

-

-

-

-
The s390rtc driver provides support for
-    the Seiko Instruments S-xx390 real-time clock chip.

-
Access methods to retrieve and set date and time are
-    provided through the
-     interface
-    defined in todr(9).

-

-

-

-
iic(4), todr(9)

-

-

-

-
The s390rtc device appeared in
-    NetBSD 6.0.

-

-

-

-
The driver does not support the chip's alarm features.

-

-

-
-  
-    
-    
-  
-
April 5, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/satalink.4 4.html b/static/netbsd/man4/satalink.4 4.html
deleted file mode 100644
index 924a70b4..00000000
--- a/static/netbsd/man4/satalink.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
SATALINK(4)Device Drivers ManualSATALINK(4)

-

-

-

-
satalink — Silicon
-    Image SATALink disk controller driver

-

-

-

-
satalink* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The satalink driver supports the Silicon
-    Image SATALink 3112 2-port and 3114 4-port Serial ATA controllers, and
-    provides the interface with the hardware for the ata(4)
-    driver.

-
The 0x0002 flag forces the satalink driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the SATA
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-
-  
-    
-    
-  
-
December 19, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/sb.4 4.html b/static/netbsd/man4/sb.4 4.html
deleted file mode 100644
index ba224902..00000000
--- a/static/netbsd/man4/sb.4 4.html	
+++ /dev/null
@@ -1,91 +0,0 @@
-
-  
-    
-    
-    
-  
-
SB(4)Device Drivers ManualSB(4)

-

-

-

-
sb — SoundBlaster
-    family (and compatible) audio device driver

-

-

-

-
sb0 at isa? port 0x220 irq 5 drq 1 drq2 5
-  

-  sb1 at isa? port 0x240 irq 7 drq 1 flags 1
-  

-  sb* at isapnp?
-  

-  sb* at pnpbios? index ?
-  

-  audio* at audiobus?
-  

-  midi* at sb?
-  

-  mpu* at sb?
-  

-  opl* at sb?

-

-

-

-
The sb driver provides support for the
-    SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Jazz 16, SoundBlaster AWE
-    32, SoundBlaster AWE 64, and hardware register-level compatible audio
-  cards.

-
The SoundBlaster series are half-duplex cards, capable of 8- and
-    16-bit audio sample recording and playback at rates up to 44.1kHz (depending
-    on the particular model).

-
The base I/O port address is usually jumper-selected to either
-    0x220 or 0x240 (newer cards may provide software configuration, but this
-    driver does not directly support them--you must configure the card for its
-    I/O addresses with other software). The SoundBlaster takes 16 I/O ports. For
-    the SoundBlaster and SoundBlaster Pro, the IRQ and DRQ channels are
-    jumper-selected. For the SoundBlaster 16, the IRQ and DRQ channels are set
-    by this driver to the values specified in the config file. The IRQ must be
-    selected from the set {5,7,9,10}.

-
The configuration file must use 1 flags
-    specification to enable the Jazz16 support. This is to avoid potential
-    conflicts with other devices when probing the Jazz 16 because it requires
-    use of extra I/O ports not in the base port range.

-
With a SoundBlaster 16 card the device is full duplex, but it can
-    only sensibly handle a precision of 8 bits. It does so by extending the
-    output 8 bit samples to 16 bits and using the 8 bit DMA channel for input
-    and the 16 bit channel for output.

-
The joystick interface (if enabled by a jumper) is handled by the
-    joy(4) driver, and the optional SCSI CD-ROM interface is
-    handled by the aic(4) driver.

-
SoundBlaster 16 cards have MPU401 emulation and can use the mpu
-    attachment, older cards have a different way to generate MIDI and has a midi
-    device attached directly to the sb.

-

-

-

-
aic(4), audio(4),
-    i386/pnpbios(4), isa(4),
-    isapnp(4), joy(4),
-    midi(4), mpu(4),
-    opl(4)

-

-

-

-
The sb device driver appeared in
-    NetBSD 1.0.

-

-

-

-
Non-SCSI CD-ROM interfaces are not supported.

-
The MIDI interface on the SB hardware is braindead, and the driver
-    needs to busy wait while writing MIDI data. This will consume a lot of
-    system time.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/sbp.4 4.html b/static/netbsd/man4/sbp.4 4.html
deleted file mode 100644
index 981346f9..00000000
--- a/static/netbsd/man4/sbp.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
SBP(4)Device Drivers ManualSBP(4)

-

-

-

-
sbp — Serial Bus
-    Protocol 2 (SBP-2) Mass Storage Devices driver

-

-

-

-
sbp* at ieee1394if? euihi ? euilo ?

-

-

-

-
The sbp driver provides support for SBP-2
-    devices that attach to the IEEE1394 port. It should work with all SBP-2
-    devices which the scsi(4) layer supports, for example,
-    HDDs, CDROM drives, and DVD drives.

-
Some users familiar with umass(4) might wonder
-    why the device is not detached at the scsi(4) layer when
-    the device is unplugged. It is detached only if the device has not been
-    plugged again during several bus resets. This is for preventing to detach an
-    active file system even when the device cannot be probed correctly for some
-    reason after a bus reset or when the device is temporary disconnected
-    because the user changes the bus topology. If you want to force to detach
-    the device, run fwctl -r several times.

-

-

-

-
ieee1394if(4), scsi(4),
-    fwctl(8), scsictl(8),
-    sysctl(8)

-

-

-

-
The sbp driver was written by
-    Katsushi Kobayashi and Hidetoshi
-    Shimokawa.

-
This manual page was written by Katsushi
-    Kobayashi. It was added to NetBSD 4.0 by
-    KIYOHARA Takashi.

-

-

-
-  
-    
-    
-  
-
June 18, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/sbt.4 4.html b/static/netbsd/man4/sbt.4 4.html
deleted file mode 100644
index 4692b9c6..00000000
--- a/static/netbsd/man4/sbt.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
SBT(4)Device Drivers ManualSBT(4)

-

-

-

-
sbt — SDIO
-    Bluetooth adapter

-

-

-

-
sbt* at sdmmc?

-

-

-

-
The sbt device driver provides support for
-    Type-A and Type-B SDIO Bluetooth adapters.

-

-

-

-
bluetooth(4), intro(4),
-    sdmmc(4)

-

-

-

-
The sbt device driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The sbt driver was written by
-    Uwe Stuehler ⟨uwe@openbsd.org⟩ for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro
-    ⟨nonaka@netbsd.org⟩.

-

-

-
-  
-    
-    
-  
-
April 21, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/sbus.4 4.html b/static/netbsd/man4/sbus.4 4.html
deleted file mode 100644
index 1084818b..00000000
--- a/static/netbsd/man4/sbus.4 4.html	
+++ /dev/null
@@ -1,149 +0,0 @@
-
-  
-    
-    
-    
-  
-
SBUS(4)Device Drivers ManualSBUS(4)

-

-

-

-
SBus —
-    introduction to machine-independent SBus bus support and
-    drivers

-

-

-

-
sbus* at mainbus?
-  

-  sbus* at iommu?
-  

-  sbus* at xbox?

-
These

-

-
-  
-    
-    
-  
-
SBusattachments are specific to the NetBSD/sparc and
-      NetBSD/sparc64 ports.

-

-

-

-
SBus is a I/O interconnect bus mostly
-    found in SPARC workstations and small to medium server class systems. It
-    supports both on-board peripherals and extension boards. The
-    SBus specifications define the bus protocol as well
-    as the electrical and mechanical properties of the extension slots.

-

-

-

-
NetBSD includes machine-independent
-    SBus drivers, sorted by device type and driver
-  name:

-

-

-

-

-  
esp(4)

-  
NCR53c94 and compatible SCSI interfaces.

-  
isp(4)

-  
Qlogic SCSI interfaces.

-

-

-

-

-

-

-

-  
le(4)

-  
Lance 7990 series Ethernet interfaces.

-  
hme(4)

-  
“Happy Meal” Ethernet interfaces.

-  
be(4)

-  
“Big Mac” Ethernet board.

-  
qe(4)

-  
Quad Ethernet Controller board.

-

-

-

-

-

-

-

-  
xbox(4)

-  
an Sbus expansion box.

-

-

-

-

-

-

-

-  
bwtwo(4)

-  
framebuffer device.

-  
cgthree(4)

-  
framebuffer device.

-  
cgsix(4)

-  
framebuffer device.

-  
pnozz(4)

-  
framebuffer device.

-  
tcx(4)

-  
framebuffer device.

-  
zx(4)

-  
framebuffer device.

-

-

-

-

-

-

-

-  
audiocs(4)

-  
CS4231 codec.

-

-

-

-

-

-

-

-  
magma(4)

-  
Magma Serial/Parallel combo device.

-

-

-

-

-

-

-

-  
fdc(4)

-  
Floppy disk controller

-

-

-

-

-

-

-
intro(4)

-

-

-

-
The machine-independent SBus subsystem
-    appeared in NetBSD 1.3.

-

-

-
-  
-    
-    
-  
-
September 6, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/sc.4 4.html b/static/netbsd/man4/sc.4 4.html
deleted file mode 100644
index 1f6a0529..00000000
--- a/static/netbsd/man4/sc.4 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
SC(4)Device Drivers ManualSC(4)

-

-

-

-
sc — Sun Sun-2
-    SCSI bus host adaptor driver

-

-

-

-

-

-
sc0 at mbmem0 addr 0x80000 ipl 2
-  

-  sc1 at mbmem0 addr 0x84000 ipl 2

-

-

-

-
sc0 at vme0 addr 0x200000 irq 2 vec
-  0x40

-

-

-

-

-
The sc driver provides support for the Sun
-    Microsystems "Sun-2" SCSI Bus Controller chipset found on various
-    VME boards (Sun part #s 501-1045, 501-1138, 501-1149, and 501-1167) and on
-    the "Sun-2 SCSI/Serial" (Sun part # 501-1006) Multibus board.

-
All versions of this driver can be configured with a
-    flags directive in the config(1) file.
-    The values are bits in a bitfield, and are interpreted as follows:

-

-

-

-  
0x0ff

-  
Set bit (1<<target) to disable SCSI parity checking

-  
0x100

-  
Set this bit to disable DMA interrupts (poll)

-  
0x200

-  
Set this bit to disable DMA entirely (use PIO)

-

-

-
For example: "flags 0x1ff" would disable DMA interrupts,
-    and disable parity checking for targets 0-7. The "target" is the
-    SCSI ID number of a particular device on a particular SCSI bus.

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-

-
Matt Fredette
-    ⟨fredette@NetBSD.org⟩,
-  

-  David Jones,
-  

-  Gordon Ross ⟨gwr@NetBSD.org⟩,
-  

-  Adam Glass ⟨glass@NetBSD.org⟩,
-  

-  Jason R. Thorpe
-  ⟨thorpej@NetBSD.org⟩.

-

-

-

-
This SCSI chipset is rumored to have bugs in its handling of SCSI
-    parity, therefore it is recommended that you disable parity on all SCSI
-    devices connected to this controller, and configure it with a 0x0ff value
-    for its flags directive in the config(1)
-    file.

-
This chipset has no support for raising the ATN signal, so there
-    is no way to ever schedule a MSG_OUT phase on the bus. Currently, the driver
-    will ultimately reset the bus if this phase is ever requested by the upper
-    layer SCSI driver.

-
This chipset has no support for SCSI disconnect/reselect. This
-    means that slow devices, such as tape drives, can hog, or "lock
-    up" the SCSI bus.

-
This driver has not been tested in combination with non-SCSI
-    devices behind Emulex or Adaptec bridges, which are common in Sun 2s and in
-    Sun Shoebox-type configurations. These devices pre-date the SCSI-I spec, and
-    might not behave the way the chipset code currently expects.

-

-

-
-  
-    
-    
-  
-
June 28, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/sc16is7xx.4 2.html b/static/netbsd/man4/sc16is7xx.4 2.html
deleted file mode 100644
index 5032d26f..00000000
--- a/static/netbsd/man4/sc16is7xx.4 2.html	
+++ /dev/null
@@ -1,305 +0,0 @@
-
-  
-    
-    
-    
-  
-
sc16is7xx(4)Device Drivers Manualsc16is7xx(4)

-

-

-

-
sc16is7xx — Driver
-    for NXP SC16IS7xx family of UART bridges via a I2C or SPI bus

-

-

-

-
sc16is7xx* at iic? addr 0x48
-  

-  sc16is7xx* at iic? addr 0x49
-  

-  sc16is7xx* at iic? addr 0x4a
-  

-  sc16is7xx* at iic? addr 0x4b
-  

-  sc16is7xx* at iic? addr 0x4c
-  

-  sc16is7xx* at iic? addr 0x4d
-  

-  sc16is7xx* at iic? addr 0x4e
-  

-  sc16is7xx* at iic? addr 0x4f
-  

-  sc16is7xx* at iic? addr 0x50
-  

-  sc16is7xx* at iic? addr 0x51
-  

-  sc16is7xx* at iic? addr 0x52
-  

-  sc16is7xx* at iic? addr 0x53
-  

-  sc16is7xx* at iic? addr 0x54
-  

-  sc16is7xx* at iic? addr 0x55
-  

-  sc16is7xx* at iic? addr 0x56
-  

-  sc16is7xx* at iic? addr 0x57

-

-  

-  sc16is7xx* at spi? slave 0
-  

-  sc16is7xx* at spi? slave 1

-

-  

-  options SC16IS7XX_SPI_FREQUENCY=4
-  

-  com* at sc16is7xx?
-  

-  gpio* at gpiobus?

-

-

-

-

-
The sc16is7xx driver provides one or two
-    UART interfaces and a gpio bus over I2C or SPI. The
-    sc16is7xx addr argument
-    selects the address at the iic(4) bus and the
-    sc16is7xx slave argument
-    selects which chip select will be used on the spi(4) bus.
-    The UART is mostly register compatiable with the 16C450, although it does
-    have aspects of the 16C550 and 16C660. This driver just provides the
-    frontend half and uses com(4) for the backend half. The
-    sc16is7xx is compatiable with COM_16550 and
-    COM_16660. If the COM_ option is left out entirely a 64 byte FIFO, hardware
-    flow control and the automatic use of the prescaler will be enabled.

-
The prescaler is a additional divide by 4 factor that is mostly
-    used when the baud rate clock has a very high frequency and there is an
-    attempt to use a very low baud rate. In that case, the divider will exceed
-    the number of bits provided by the clock divider registers. The additional
-    prescaler factor will allow for these low baud rates in this case.

-
The SC16IS7XX_SPI_FREQUENCY can used to set the SPI clock
-    frequency from 1 to 4 or 1 to 15 in Mhz depending on the chip varient.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
This sysctl can be used to set the clock frequency that is being used by
-      the chip to generate the baud rate. There is no standard frequency for
-      this clock, although 14.7456 Mhz is common, but 1.8432 Mhz, 3.072 Mhz and
-      12.000 Mhz are also known to exist. This value is in Hz and must be set
-      correctly for the baud rate to work as expected. The
-      SC16IS7XX_DEFAULT_FREQUENCY kernel option and the clock-frequency option
-      in a FDT overlay can also be used to set this value.

-  

-  
The chip supports a interrupt line to a gpio pin that can be used on
-      systems that have FDT support. If the driver can not make use of this
-      interrupt line then it will use a polling kernel thread to check for an
-      interrupt. This sysctl adjusts how often this thread checks. It is in ms
-      and defaults to 50. It is very possible to saturate a I2C bus if the
-      checks are too frequent, but if they are not often enough there will be
-      latency in the processing of incoming and outgoing characters.

-

-
Unexpected behavior may result if the frequency is changed while
-    something has the port open.

-

-

-

-
On systems that support FDT the following can be used to enable
-    the driver and set parameters:

-

-
/dts-v1/;
-/plugin/;
-
-/ {
-        compatible = "brcm,bcm2835";
-
-        fragment@0 {
-                target = <&spi>;
-
-                __overlay__ {
-                        status = "okay";
-                        pinctrl-names = "default";
-                        pinctrl-0 = <&spi0_gpio7>;
-
-                        sc16is750@0 {
-                                compatible = "nxp,sc16is750";
-                                reg = <0x00>;
-                                interrupt-parent = <&gpio>;
-                                interrupts = <17 2>;
-				gpio-controller;
-                        };
-                };
-        };
-};

-The above is for a Raspberry PI 3 for enabling the the spi bus itself and the
-  sc16is7xx device on the spi0 bus and allowing it to
-  use gpio pin 17 with a negative edge interrupt. Since
-  "gpio-controller;" was specified a gpiobus will be attached.
-

-
/dts-v1/;
-/plugin/;
-
-/ {
-        compatible = "brcm,bcm2837";
-
-        fragment@0 {
-                target= <&i2c1>;
-
-                __overlay__ {
-                        sc16is740@48 {
-                                compatible = "nxp,sc16is740";
-                                reg = <0x48>;
-                                clock-frequency = <14745600>;
-                                interrupt-parent = <&gpio>;
-                                interrupts = <17 2>;
-                        };
-                };
-        };
-};

-The above is also for a Raspberry PI 3 that configures a SC16IS740 for an I2C
-  bus. Since "gpio-controller;" was not specified, no gpiobus will be
-  attached.
-

-

-

-
There are a number of family members for this chip. All of them
-    except the SC16IS740 and SC16IS741 have gpio(4) pins.
-    These pins are simple input and output pins and in many cases share a ALT0
-    function that allows them to be modem control lines.

-

-
-  
-    
-    
-    
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-
PinSC16IS750 / SC16IS760ALT0SC16IS752 / SC16IS762ALT0Bank
GP0GP0-GP0DSRBB
GP1GP1-GP1DTRBB
GP2GP2-GP2CDBB
GP3GP3-GP3RIBB
GP4GP4DSRGP4DSRAA
GP5GP5DTRGP5DTRAA
GP6GP6CDGP6CDAA
GP7GP7RIGP7RIAA

-

-
If any of the pins are configured as modem control lines, the
-    entire bank of 4 pins will be modem control lines. Likewise, if any of the
-    pins in a bank are configured for input or output, the entire bank of pins
-    will be input or output and the modem control will be removed.

-
It is not possible to tell the difference between a SC16IS74x
-    varient from a SC16IS750 or SC16IS760, so gpio(4) will be
-    present on both variants. If FDT can be used, a the
-    "gpio-controller;" directive can be used to tell more specifically
-    if the GPIO pins are present. In the FDT case, if
-    "gpio-controller;" is left out and the chip has GPIO pins, then
-    they will be turned into their respective modem control pins.

-

-

-

-
com(4), gpio(4),
-    iic(4), spi(4),
-    sysctl(8)

-

-

-

-
The sc16is7xx driver first appeared in
-    NetBSD 12.0.

-

-

-

-
The sc16is7xx driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The driver does not support all of the aspects of the chip family,
-    in particular, the RS-485 and IrDA modes. The driver is unlikely to work as
-    a console or with KGDB. There are assumptions built into the
-    com(4) backend that assumes that the chip is connected
-    directly to the computer bus and this will not be true for the SC16IS7XX
-    family of devices.

-
A kernel panic will happen if an attempt is made to attach another
-    driver to the gpio pins of the SC16IS7XX using gpioctl or by compiling a
-    kernel with such an attachment. The SPI or I2C bus needs to wait while the
-    transfer is in progress and the other driver will attempt to do the
-    attachment with a spin lock held.

-
The bandwidth of the I2C bus is typically set to 100 kbits/sec.
-    Attempting to use higher baud rates, especially without flow control, may
-    result in excessive silo overlows. An SPI bus may perform better, but silo
-    overflows can still happen.

-

-

-
-  
-    
-    
-  
-
October 7, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/schide.4 4.html b/static/netbsd/man4/schide.4 4.html
deleted file mode 100644
index cc7dc301..00000000
--- a/static/netbsd/man4/schide.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCHIDE(4)Device Drivers ManualSCHIDE(4)

-

-

-

-
schide — Intel SCH
-    IDE disk controllers driver

-

-

-

-
schide* at pci? dev ? function ?

-

-

-

-
The schide driver supports the Intel SCH
-    IDE controllers and provides the interface with the hardware for the
-    ata(4) driver.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-
-  
-    
-    
-  
-
November 7, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/scmd.4 4.html b/static/netbsd/man4/scmd.4 4.html
deleted file mode 100644
index 8bc8a584..00000000
--- a/static/netbsd/man4/scmd.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCMD(4)Device Drivers ManualSCMD(4)

-

-

-

-
scmd — Common
-    driver for the Sparkfun Serial Controlled Motor Driver

-

-

-

-
scmd* at iic? ...
-  

-  scmd* at spi? ...

-

-

-

-
The scmd driver provides the common
-    framework to the Sparkfun SCMD board. The SCMD board is a Cypress core ARM
-    SOC in front of a DRV8835 motor driver chip. There are a number of ways to
-    talk to the board and scmdi2c(4) and
-    scmdspi(4) should be consulted for the I2C and SPI
-    frontend drivers. The board is fully documented in the datasheet for at
-    Sparkfun.

-
The board provides a register address space of 126 registers which
-    control the various behaviors of the motors attached to the board. Each SCMD
-    board can handle two motors, and up to 16 SCMD boards may be chained
-    together allowing for 34 motors to be controlled from a single master
-    instance. The secondary boards are accessed by set of view port registers
-    from the main board. The scmd(4) driver and its associated
-    frontends flatten the main SCMD board and all chained boards into a linear
-    register space that can be opened, seeked, read from and written to like any
-    other file or device without having to worry about the view port.

-
A command line utility scmdctl(1) is provided
-    that allows convenient command line commands for most of the functions
-    provided by the SCMD board.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
If the driver is compiled with SCMD_DEBUG, this
-      node will appear and can be used to set the debugging level.

-

-

-

-

-

-  
/dev/scmdu

-  
character device allowing access to the register space of a main
-      u, SCMD device

-

-

-

-

-
iic(4), spi(4),
-    scmdi2c(4), scmdspi(4),
-    scmdctl(1), sysctl(8)

-

-

-

-
The scmd driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The scmd driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
January 1, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/scmdi2c.4 4.html b/static/netbsd/man4/scmdi2c.4 4.html
deleted file mode 100644
index 364307c8..00000000
--- a/static/netbsd/man4/scmdi2c.4 4.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCMDI2C(4)Device Drivers ManualSCMDI2C(4)

-

-

-

-
scmdi2c — I2C
-    frontend to the Sparkfun Serial Controlled Motor Driver

-

-

-

-
scmd* at iic? addr 0x58
-  

-  scmd* at iic? addr 0x59
-  

-  scmd* at iic? addr 0x5a
-  

-  scmd* at iic? addr 0x5b
-  

-  scmd* at iic? addr 0x5c
-  

-  scmd* at iic? addr 0x5d
-  

-  scmd* at iic? addr 0x5e
-  

-  scmd* at iic? addr 0x5f
-  

-  scmd* at iic? addr 0x60
-  

-  scmd* at iic? addr 0x61

-

-

-

-
The scmdi2c driver provides the I2C
-    frontend attachment for the Sparkfun SCMD device.

-

-

-

-
The following sysctl(3) variables are inherited
-    from scmd(4) :

-

-  

-  
If the driver is compiled with SCMD_DEBUG, this
-      node will appear and can be used to set the debugging level.

-

-

-

-

-

-  
/dev/scmdu

-  
character device allowing access to the register space of a main
-      u, SCMD device

-

-

-

-

-
iic(4), spi(4),
-    scmdi2c(4), scmdspi(4),
-    scmdctl(1), sysctl(8)

-

-

-

-
The scmdi2c driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The scmdi2c driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
December 1, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/scmdspi.4 4.html b/static/netbsd/man4/scmdspi.4 4.html
deleted file mode 100644
index ee0d4d79..00000000
--- a/static/netbsd/man4/scmdspi.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCMDSPI(4)Device Drivers ManualSCMDSPI(4)

-

-

-

-
scmdspi — SPI
-    frontend to the Sparkfun Serial Controlled Motor Driver

-

-

-

-
scmd* at spi? slave 0
-  

-  scmd* at spi? slave 1

-

-

-

-
The scmdspi driver provides the SPI
-    frontend attachment for the Sparkfun SCMD device.

-

-

-

-
The following sysctl(3) variables are inherited
-    from scmd(4) :

-

-  

-  
If the driver is compiled with SCMD_DEBUG, this
-      node will appear and can be used to set the debugging level.

-

-

-

-

-

-  
/dev/scmdu

-  
character device allowing access to the register space of a main
-      u, SCMD device

-

-

-

-

-
iic(4), spi(4),
-    scmdi2c(4), scmdspi(4),
-    scmdctl(1), sysctl(8)

-

-

-

-
The scmdspi driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The scmdspi driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
When used in SPI mode, the SCMD device uses an odd method of doing
-    reads that can become stuck. See the command spi_read_one in the
-    scmdctl(1) utility to try and unstick the device when this
-    happens.

-

-

-

-
-  
-    
-    
-  
-
December 1, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/scsi.4 4.html b/static/netbsd/man4/scsi.4 4.html
deleted file mode 100644
index a3217051..00000000
--- a/static/netbsd/man4/scsi.4 4.html	
+++ /dev/null
@@ -1,217 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCSI(4)Device Drivers ManualSCSI(4)

-

-

-

-
scsi, scsibus
-    — Small Computer Systems Interface (SCSI) bus
-    driver

-

-

-

-
scsibus* at scsi?
-  

-  atapibus* at atapi?
-  

-  options SCSIDEBUG
-  

-  options SCSIVERBOSE

-

-

-

-
The scsi driver is the top,
-    machine-independent layer of the two-layer software system that provides an
-    interface for the implementation of drivers to control various SCSI or ATAPI
-    bus devices, and to use different SCSI bus host adapters or EIDE
-    controllers. SCSI bus is capable of supporting a wide variety of
-    peripherals, including hard disks, removable disks, CD-ROMs, scanners, tape
-    drives, and other miscellaneous high-speed devices.

-
The bottom layer is composed of the drivers for individual EIDE or
-    SCSI bus controller chips (e.g. NCR 5380), accessed through various host bus
-    interfaces, including, but not limited to PCI, ISA, Sbus, TURBOchannel, and
-    NuBus. These individual devices are referred to as "host adaptors"
-    in SCSI terminology, because they connect the SCSI bus to the host
-  computer.

-
When NetBSD probes the SCSI busses, it
-    "attaches" any devices it finds to the appropriate drivers.

-

-

-  
sd(4)

-  
hard disks

-  
cd(4)

-  
CD-ROM drives

-  
st(4)

-  
tape drives

-  
ch(4)

-  
media changers

-  
ss(4)

-  
scanners

-

-
If no specific driver matches the device, then
-    scsi attaches the device to the
-    uk(4) driver so that user level SCSI
-    ioctl(2) calls may still be performed against the device.
-    Currently, only sd(4), cd(4),
-    st(4), and uk(4) can attach to an atapi
-    bus.

-
Please see the intro(4) manual page to see which
-    SCSI bus host adaptors are supported by NetBSD on
-    your computer system.

-

-

-

-
The scsi software supports some
-    NetBSD kernel config(1) options.
-    They are:

-

-  

-  
Compile in a wide variety of
-      ()
-      statements that can be turned on by ioctl(2).

-  

-  
Enable additional and more descriptive error and status messages from the
-      scsi software.

-

-
All devices and the SCSI busses support boot time allocation so
-    that an upper number of devices and controllers does not need to be
-    configured.

-
The devices are either
-     so they
-    appear at a particular device unit number or
-    
-    so that they appear as the next available unused unit number.

-
To configure a driver in the kernel without wiring down the device
-    use a config line similar to

-
ch* at scsibus? target ? lun ?

-
to include the ch(4) changer driver.

-
To wire down a unit use a config line similar to

-
ch1 at scsibus0 target 4 lun 0

-
to assign changer 1 as the changer with SCSI ID 4, logical unit 0,
-    on bus 0. Individual SCSI busses can be wired down to specific controllers
-    with a config line similar to

-
scsibus0 at ahc0

-
which assigns SCSI bus 0 to the first unit using the
-    ahc(4) driver.

-
When you have a mixture of wired down and counted devices then the
-    counting begins with the first non-wired down unit for a particular type.
-    That is, if you have a disk wired down as

-
sd1 at scsibus0 target 1 lun 0

-
then the first non-wired disk shall come on line as
-    .

-

-

-

-
There are a number of ioctl(2) calls that work
-    on any SCSI device. They are defined in sys/scsiio.h
-    and can be applied against any SCSI device that permits them. For the tape,
-    it must be applied against the control device. See the manual page for each
-    device type for more information about how generic SCSI
-    ioctl(2) calls may be applied to a specific device.

-

-  

-  
Reset a SCSI device.

-  

-  
Turn on debugging. All SCSI operations originating from this device's
-      driver will be traced to the console, along with other information.
-      Debugging is controlled by four bits, described in the header file. If no
-      debugging is configured into the kernel, debugging will have no effect.
-      SCSI debugging is controlled by the configuration option
-      SCSIDEBUG.

-  

-  
Take a SCSI command and data from a user process and apply them to the
-      SCSI device. Return all status information and return data to the process.
-      The ioctl(2) call will return a successful status even
-      if the device rejected the command. As all status is returned to the user,
-      it is up to the user process to examine this information to decide the
-      success of the command.

-  

-  
Ask the driver what its bus, target and LUN are.

-  

-  
Ask the device to disappear. This may not happen if the device is in
-    use.

-

-

-

-

-
The system allows common device drivers to work through many
-    different types of adapters. The adapters take requests from the upper
-    layers and do all IO between the SCSI bus and the system. The maximum size
-    of a transfer is governed by the adapter. Most adapters can transfer 64KB in
-    a single operation, however many can transfer larger amounts.

-

-

-

-
Some adapters support
-     in which the system is capable of operating as a device,
-    responding to operations initiated by another system. Target Mode will be
-    supported for some host adapters, but is not yet complete for this version
-    of the SCSI system.

-

-

-

-
When the kernel is compiled with option
-    SCSIDEBUG, the SCIOCDEBUG
-    ioctl(2) can be used to enable various amounts of tracing
-    information on any specific device. Devices not being traced will not
-    produce trace information. The four bits that make up the debug level, each
-    control certain types of debugging information.

-

-  

-  
shows all SCSI bus operations including SCSI commands, error information
-      and the first 48 bytes of any data transferred.

-  

-  
shows routines called.

-  

-  
shows information about what branches are taken and often some of the
-      return values of functions.

-  

-  
shows more detailed information including DMA scatter-gather logs.

-

-

-

-

-
config(1), ioctl(2),
-    ata(4), cd(4), ch(4),
-    intro(4), sd(4),
-    se(4), ss(4), st(4),
-    uk(4), scsictl(8)

-

-

-

-
This scsi system appeared in MACH 2.5 at
-    TRW.

-
This man page was originally written by Julian Elischer
-    ⟨julian@freebsd.org⟩ for FreeBSD and
-    extensively modified by Erik Fair
-    ⟨fair@NetBSD.org⟩ for NetBSD.

-

-

-

-
Not every device obeys the SCSI specification as faithfully as it
-    should. As such devices are discovered by the NetBSD
-    Project, their names are added to a
-     compiled into the scsi driver along a
-    list of flags indicating which particular bad behaviors the device exhibits
-    (and that the driver should be prepared to work around).

-

-

-
-  
-    
-    
-  
-
August 18, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/sctp.4 3.html b/static/netbsd/man4/sctp.4 3.html
deleted file mode 100644
index ddac2f28..00000000
--- a/static/netbsd/man4/sctp.4 3.html	
+++ /dev/null
@@ -1,297 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCTP(4)Device Drivers ManualSCTP(4)

-

-

-

-
sctp — Internet
-    Stream Control Transmission Protocol

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/socket.h>
-  

-  #include <netinet/sctp.h>

-
int
-  

-  socket(AF_INET,
-    SOCK_STREAM,
-    IPPROTO_SCTP);

-
int
-  

-  socket(AF_INET,
-    SOCK_SEQPACKET,
-    IPPROTO_SCTP);

-

-

-

-
The SCTP protocol provides reliable, flow-controlled, two-way
-    transmission of data. It is a message oriented protocol and can support the
-    SOCK_STREAM and
-    SOCK_SEQPACKET abstractions. SCTP uses the standard
-    Internet address format and, in addition, provides a per-host collection of
-    “port addresses”. Thus, each address is composed of an
-    Internet address specifying the host and network, with a specific SCTP port
-    on the host identifying the peer entity.

-
There are two models of programming in SCTP. The first uses the
-    SOCK_STREAM abstraction. In this abstraction sockets
-    utilizing the SCTP protocol are either “active” or
-    “passive”. Active sockets initiate connections to passive
-    sockets. By default, SCTP sockets are created active; to create a passive
-    socket, the listen(2) system call must be used after
-    binding the socket with the bind(2) or
-    sctp_bindx(3) system calls. Only passive sockets may use
-    the accept(2) call to accept incoming connections. Only
-    active sockets may use the connect(2) call to initiate
-    connections.

-
The other abstraction SOCK_SEQPACKET
-    provides a “connectionless” mode of operation in that the user
-    may send to an address (using any of the valid send calls that carry a
-    socket address) and an association will be setup implicitly by the
-    underlying SCTP transport stack. This abstraction is the only one capable of
-    sending data on the third leg of the four-way handshake. A user must still
-    call listen(2) to allow the socket to accept connections.
-    Calling listen(2) however does not restrict the user from
-    still initiating implicit connections to other peers.

-
The SCTP protocol directly supports multi-homing. So when binding
-    a socket with the “wildcard” address
-    INADDR_ANY, the SCTP stack will inform the peer
-    about all of the local addresses that are deemed in scope of the peer. The
-    peer will then possibly have multiple paths to reach the local host.

-
The SCTP transport protocol is also multi-streamed.
-    Multi-streaming refers to the ability to send sub-ordered flows of messages.
-    A user performs this by specifying a specific stream in one of the extended
-    send calls such as the sctp_send(3) function call. Sending
-    messages on different streams will allow parallel delivery of data i.e., a
-    message loss in stream 1 will not block the delivery of messages sent in
-    stream 2.

-
The SCTP transport protocol also provides a unordered service as
-    well. The unordered service allows a message to be sent and delivered with
-    no regard to the ordering of any other message.

-

-

-
The NetBSD implementation of SCTP also supports the following
-    extensions:

-

-  
sctp partial reliability

-  
This extension allows one to have message be skipped and not delivered
-      based on some user specified parameters.

-  
sctp dynamic addressing

-  
This extension allows addresses to be added and deleted dynamically from
-      an existing association.

-  
sctp authentication

-  
This extension allows the user to authenticate specific peer chunks
-      (including data) to validate that the peer who sent the message is in fact
-      the peer who setup the association. A shared key option is also provided
-      for so that two stacks can pre-share keys.

-  
packet drop

-  
Some routers support a special satellite protocol that will report losses
-      due to corruption. This allows retransmissions without subsequent loss in
-      bandwidth utilization.

-  
stream reset

-  
This extension allows a user on either side to reset the stream sequence
-      numbers used by any or all streams.

-

-
SCTP supports a number of socket options which can be set with
-    setsockopt(2) and tested with
-    getsockopt(2) or sctp_opt_info(3):

-

-  

-  
Under most circumstances, SCTP sends data when it is presented; when
-      outstanding data has not yet been acknowledged, it gathers small amounts
-      of output to be sent in a single packet once an acknowledgement is
-      received. For some clients, such as window systems that send a stream of
-      mouse events which receive no replies, this packetization may cause
-      significant delays. The boolean option
-      SCTP_NODELAY defeats this algorithm.

-  

-  
This option returns specific information about an associations
-      “Retransmission Time Out”. It can also be used to change the
-      default values.

-  

-  
This option returns specific information about the requested
-    association.

-  

-  
This option allows you to get or set the default sending parameters when
-      an association is implicitly setup. It allows you to change such things as
-      the maximum number of streams allowed inbound and the number of streams
-      requested of the peer.

-  

-  
For the one-to-many model (SOCK_SEQPACKET)
-      associations are setup implicitly. This option allows the user to specify
-      a default number of idle seconds to allow the association be maintained.
-      After the idle timer (where no user message have been sent or have been
-      received from the peer) the association will be gracefully closed. The
-      default for this value is 0, or unlimited (i.e., no automatic close).

-  

-  
The dynamic address extension allows a peer to also request a particular
-      address of its be made into the primary address. This option allows the
-      caller to make such a request to a peer. Note that if the peer does not
-      also support the dynamic address extension, this call will fail. Note the
-      caller must provide a valid local address that the peer has been told
-      about during association setup or dynamically.

-  

-  
This option allows the setting of the primary address that the caller
-      wishes to send to. The caller provides the address of a peer that is to be
-      made primary.

-  

-  
The dynamic address extension also allows a user to pass a 32 bit opaque
-      value upon association setup. This option allows a user to set or get this
-      value.

-  

-  
By default SCTP will fragment user messages into multiple pieces that will
-      fit on the network and then later, upon reception, reassemble the pieces
-      into a single user message. If this option is enabled instead, any send
-      that exceeds the path maximum transfer unit (P-MTU) will fail and the
-      message will NOT be sent.

-  

-  
This option will allow a user to set or get specific peer address
-      parameters.

-  

-  
When a user does not use one of the extended send calls (e.g.,
-      sctp_sendmsg(3)) a set of default values apply to each
-      send. These values include things like the stream number to send to as
-      well as the per-protocol id. This option lets a caller both get and set
-      these values. If the user changes these default values, then these new
-      values will be used as the default whenever no information is provided by
-      the sender (i.e., the non-extended API is used).

-  

-  
SCTP has non-data events that it can communicate to its application. By
-      default these are all disabled since they arrive in the data path with a
-      special flag MSG_NOTIFICATION set upon the
-      received message. This option lets a caller both get what events are
-      current being received as well as set different events that they may be
-      interested in receiving.

-  

-  
SCTP supports both IPV4 and IPV6. An association may span both IPV4 and
-      IPV6 addresses since SCTP is multi-homed. By default, when opening an IPV6
-      socket, when data arrives on the socket from a peer's V4 address the V4
-      address will be presented with an address family of AF_INET. If this is
-      undesirable, then this option can be enabled which will then convert all
-      V4 addresses into mapped V6 representations.

-  

-  
By default SCTP chooses its message fragmentation point based upon the
-      smallest P-MTU of the peer. This option lets the caller set it to a
-      smaller value. Note that while the user can change this value, if the
-      P-MTU is smaller than the value set by the user, then the P-MTU value will
-      override any user setting.

-  

-  
This option lets the user both set and get the delayed ack time (in
-      milliseconds) that SCTP is using. The default is 200 milliseconds.

-  

-  
SCTP at times may need to start delivery of a very large message before
-      the entire message has arrived. By default SCTP waits until the incoming
-      message is larger than one fourth of the receive buffer. This option
-      allows the stacks value to be overridden with a smaller value.

-  

-  
SCTP at times will start partial delivery (as mentioned above). In the
-      normal case successive reads will continue to return the rest of the
-      message, blocking if needed, until all of that message is read. However
-      this means other messages may have arrived and be ready for delivery and
-      be blocked behind the message being partially delivered. If this option is
-      enabled, when a partial delivery message has no more data to be received,
-      then a subsequent read may return a different message that is ready for
-      delivery. By default this option is off since the user must be using the
-      extended API's to be able to tell the difference between messages (via the
-      stream and stream sequence number).

-  

-  
By default only the dynamic addressing chunks are authenticated. This
-      option lets a user request an additional chunk be authenticated as well.
-      Note that successive calls to this option will work and continue to add
-      more chunks that require authentication. Note that this option only
-      effects future associations and not existing ones.

-  

-  
This option allows a user to specify a shared key that can be later used
-      to authenticate a peer.

-  

-  
This option will let you get or set the list of HMAC algorithms used to
-      authenticate peers. Note that the HMAC values are in priority order where
-      the first HMAC identifier is the most preferred and the last is the least
-      preferred.

-  

-  
This option allows you to make a key active for the generation of
-      authentication information. Note that the peer must have the same key or
-      else the data will be discarded.

-  

-  
This option allows you to delete an old key.

-  

-  
The sockets api document allows an extended send/receive information
-      structure to be used. The extended structure includes additional fields
-      related to the next message to be received (after the current receive
-      completes) if such information is known. By default the system will not
-      pass this information. This option allows the user to request this
-      information.

-  

-  
By default when bound to all address and the system administrator has
-      enables automatic dynamic addresses, the SCTP stack will automatically
-      generate address changes into add and delete requests to any peers by
-      setting this option to true. This option allows an endpoint to disable
-      that behavior.

-  

-  
By default SCTP implements micro-burst control so that as the congestion
-      window opens up no large burst of packets can be generated. The default
-      burst limit is four. This option lets the user change this value.

-  

-  
Many sctp extended calls have a context field. The context field is a 32
-      bit opaque value that will be returned in send failures. This option lets
-      the caller set the default context value to use when none is provided by
-      the user.

-  

-  
By default, a single send is a complete message. SCTP generates an implied
-      record boundary. If this option is enabled, then all sends are part of the
-      same message until the user indicates an end of record with the special
-      flag SCTP_EOR passed in the sctp_sndrcvinfo flags
-      field. This effectively makes all sends part of the same message until the
-      user specifies differently. This means that a caller must NOT change the
-      stream number until after the SCTP_EOR is passed
-      to SCTP else an error will be returned.

-  

-  
This option is a read only option that returns various status information
-      about the specified association.

-  

-  
This read only option returns information about a peer address.

-  

-  
This read only option returns a list of the chunks the peer requires to be
-      authenticated.

-  

-  
This read only option returns a list of the locally required chunks that
-      must be authenticated.

-  

-  
This socket option is used to cause a stream sequence number or all stream
-      sequence numbers to be reset. Note that the peer SCTP endpoint must also
-      support the stream reset extension as well.

-

-

-

-

-

-
accept(2), bind(2),
-    connect(2), listen(2),
-    sctp_bindx(3), sctp_connectx(3),
-    sctp_opt_info(3), sctp_recvmsg(3),
-    sctp_sendmsg(3)

-
Stream Control Transmission
-    Protocol, RFC,
-    4960, September
-    2007.

-

-

-

-
The sctp protocol appeared in
-    NetBSD 8.0.

-

-

-
-  
-    
-    
-  
-
July 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/sd.4 3.html b/static/netbsd/man4/sd.4 3.html
deleted file mode 100644
index ae4483c6..00000000
--- a/static/netbsd/man4/sd.4 3.html	
+++ /dev/null
@@ -1,153 +0,0 @@
-
-  
-    
-    
-    
-  
-
SD(4)Device Drivers ManualSD(4)

-

-

-

-
sd — SCSI and
-    ATAPI disk driver

-

-

-

-
sd* at scsibus? target ? lun ?
-  

-  sd3 at scsibus0 target 3 lun 0
-  

-  sd* at atapibus? drive ? flags 0x0000

-

-

-

-
The sd driver provides support for SCSI
-    bus and Advanced Technology Attachment Packet Interface (ATAPI) disks. It
-    allows the disk to be divided up into a set of pseudo devices called
-    .
-    In general the interfaces are similar to those described by
-    wd(4).

-
Where the wd(4) device has a fairly low level
-    interface to the system, SCSI devices have a much higher level interface and
-    talk to the system via a SCSI host adapter (e.g., ahc(4)).
-    A SCSI adapter must also be separately configured into the system before a
-    SCSI disk can be configured.

-
When the SCSI adapter is probed during boot, the SCSI
-    bus is scanned for devices. Any devices found which answer as
-    ‘’
-    type devices will be attached to the sd driver.

-
For the use of flags with ATAPI devices, see
-    wd(4).

-

-

-

-
On many systems disklabel(8) is used to
-    partition the drive into filesystems. On some systems the
-    NetBSD portion of the disk resides within a native
-    partition, and another program is used to create the
-    NetBSD portion.

-
For example, the i386 port uses fdisk(8) to
-    partition the disk into a BIOS level partition. This allows sharing the disk
-    with other operating systems.

-

-

-

-
The following config(1) options may be applied
-    to SCSI disks as well as to other disks.

-

-  

-  
Set the number of retries that will be performed for operations it makes
-      sense to retry (e.g., normal reads and writes). The default is four
-    (4).

-  

-  
Set amount of time, in milliseconds, a normal read or write is expected to
-      take. The defaults is sixty seconds (60000 milliseconds). This is used to
-      set watchdog timers in the SCSI HBA driver to catch commands that might
-      have died on the device.

-

-

-

-

-
The following ioctl(2) calls apply to SCSI disks
-    as well as to other disks. They are defined in the header file
-    <sys/dkio.h> and use data
-    structures defined in
-    <sys/disklabel.h>.

-

-  

-  
Read, from the kernel, the in-core copy of the disklabel for the drive.
-      This may be a fictitious disklabel if the drive has never been
-      initialized, in which case it will contain information read from the SCSI
-      inquiry commands.

-  

-  
Give the driver a new disklabel to use. The driver will
-      not write the new disklabel to the disk.

-  

-  
Keep or drop the in-core disklabel on the last close.

-  

-  
Enable or disable the driver's software write protect of the disklabel on
-      the disk.

-  

-  
Give the driver a new disklabel to use. The driver will
-      write the new disklabel to the disk.

-  

-  
Lock the media cartridge into the device, or unlock a cartridge previously
-      locked. Used to prevent user and software eject while the media is in
-    use.

-  

-  
Eject the media cartridge from a removable device.

-

-
In addition, the scsi(4) general
-    ()
-    commands may be used with the sd driver, but only
-    against the ‘c’ (whole disk)
-    partition.

-

-

-

-
If a removable device is attached to the
-    sd driver, then the act of changing the media will
-    invalidate the disklabel and information held within the kernel. To avoid
-    corruption, all accesses to the device will be discarded until there are no
-    more open file descriptors referencing the device. During this period, all
-    new open attempts will be rejected. When no more open file descriptors
-    reference the device, the first next open will load a new set of parameters
-    (including disklabel) for the drive.

-

-

-

-

-  
/dev/sdup

-  
block mode SCSI disk unit u, partition
-      p

-  
/dev/rsdup

-  
raw mode SCSI disk unit u, partition
-      p

-

-

-

-

-
None.

-

-

-

-
ioctl(2), intro(4),
-    scsi(4), wd(4),
-    disklabel(5), disklabel(8),
-    fdisk(8), scsictl(8)

-

-

-

-
The sd driver was originally written for
-    Mach 2.5, and was ported to FreeBSD by Julian
-    Elischer. It was later ported to NetBSD.

-

-

-
-  
-    
-    
-  
-
June 9, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/sdhc.4 4.html b/static/netbsd/man4/sdhc.4 4.html
deleted file mode 100644
index b795d9e0..00000000
--- a/static/netbsd/man4/sdhc.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
SDHC(4)Device Drivers ManualSDHC(4)

-

-

-

-
sdhc — SD Host
-    Controller

-

-

-

-
sdhc* at acpi?
-  

-  sdhc* at pci?
-  

-  sdhc* at cardbus? function ?
-  

-  sdmmc* at sdhc?

-

-

-

-
The sdhc driver provides support for SD
-    controllers following the SD Host Controller Standard Simplified
-    Specification.

-
The sdmmc(4) subsystem performs SD/MMC
-    transactions to communicate with whatever MMC, SD, SDHC, or SDIO devices are
-    inserted into the SD slot.

-

-

-

-
intro(4), sdmmc(4)

-

-

-

-
The sdhc driver was written by
-    Uwe Stuehler ⟨uwe@openbsd.org⟩ for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro
-    ⟨nonaka@netbsd.org⟩.

-

-

-
-  
-    
-    
-  
-
June 21, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/sdmmc.4 4.html b/static/netbsd/man4/sdmmc.4 4.html
deleted file mode 100644
index 7cd51edb..00000000
--- a/static/netbsd/man4/sdmmc.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
SDMMC(4)Device Drivers ManualSDMMC(4)

-

-

-

-
sdmmc — SD
-    bus

-

-

-

-
sdmmc* at pxamci?	# pxa2x0 specific
-  

-  sdmmc* at rtsx?
-  

-  sdmmc* at sdhc?
-  

-  sdmmc* at wb?
-  

-  ld* at sdmmc?

-

-

-

-
The sdmmc subsystem provides
-    machine-independent bus support and drivers for SD/MMC devices.

-
Standard SD/SDHC memory devices will show up as a logical disk,
-    using ld(4).

-

-

-

-
intro(4), ld(4),
-    rtsx(4), sbt(4),
-    sdhc(4), wb(4)

-

-

-

-
The sdmmc driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The sdmmc driver was written by
-    Uwe Stuehler ⟨uwe@openbsd.org⟩ for
-    OpenBSD and ported to NetBSD
-    by NONAKA Kimihiro ⟨nonaka@netbsd.org⟩
-    and KIYOHARA Takashi
-    ⟨kiyohara@kk.iij4u.or.jp⟩.

-

-

-
-  
-    
-    
-  
-
March 19, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/sdtemp.4 3.html b/static/netbsd/man4/sdtemp.4 3.html
deleted file mode 100644
index 253ca389..00000000
--- a/static/netbsd/man4/sdtemp.4 3.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
SDTEMP(4)Device Drivers ManualSDTEMP(4)

-

-

-

-
sdtemp — JEDEC
-    JC-42.4 compatible memory module temperature sensors

-

-

-

-
sdtemp* at iic? addr 0x18
-  

-  sdtemp* at iic? addr 0x19
-  

-  sdtemp* at iic? addr 0x1a
-  

-  sdtemp* at iic? addr 0x1b
-  

-  sdtemp* at iic? addr 0x1c
-  

-  sdtemp* at iic? addr 0x1d
-  

-  sdtemp* at iic? addr 0x1e
-  

-  sdtemp* at iic? addr 0x1f

-

-

-

-
The sdtemp driver provides support for the
-    Microchip Technology MCP9805/98242 and other chips that conform to JEDEC
-    Standard 21-C section 4.7. Memory module temperature sensors are optional on
-    DDR2 and newer DIMMs. Sensors provided by this driver, including the on-chip
-    thresholds for the Alarm Window and Critical level, are accessed through the
-    envsys(4) API.

-
The sdtemp supports temperature ranges
-    from -256 to +255 degrees C.

-
Chips supported by the sdtemp driver
-    include TSE2004av compliant devices and:

-
    
-  
  • Analog Devices ADT7408
    • 
-  
  • Atmel AT30TS00 and AT30TSE004
    • 
-  
  • On semiconductor (Catalyst) CAT34TS02, CAT34TS02C, CAT34TS04 and
-    CAT6095
    • 
-  
  • Giantec Semiconductor GT30TS00 and GT34TS02
    • 
-  
  • Integrated Deviced Technology TSE2002B3, TSE2002GB2, TSE2004GB2, TS3000B3,
-      TS3000GB0, TS3000GB2, and TS30001GB2
    • 
-  
  • Maxim MAX6604
    • 
-  
  • Microchip Technology EMC1501, MCP9804, MCP9805, MCP9843, MCP98242,
-      MCP98243, and MCP98244
    • 
-  
  • NXP Semiconductors SE97 and SE98
    • 
-  
  • STmicroelectronics STTS424, STTS424E, STTS2002, STTS2004, and
-    STTS3000
    • 
-

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The sdtemp device appeared in
-    NetBSD 6.0.

-

-

-

-
Interrupt support is unimplemented.

-

-

-
-  
-    
-    
-  
-
February 22, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/se.4 4.html b/static/netbsd/man4/se.4 4.html
deleted file mode 100644
index eea32b05..00000000
--- a/static/netbsd/man4/se.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
SE(4)Device Drivers ManualSE(4)

-

-

-

-
se — Cabletron
-    EA41x SCSI bus Ethernet interface driver

-

-

-

-
se* at scsibus? target ? lun ?

-

-

-

-
The se driver supports the Cabletron EA41x
-    SCSI bus Ethernet interface.

-
This driver is a bit unusual. It must look like a network
-    interface and it must also appear to be a SCSI device to the SCSI
-  system.

-
In addition, to facilitate SCSI commands issued by
-    userland programs, there are
-    (),
-    (),
-    and
-    ()
-    entry points. This allows a user program to, for example, display the EA41x
-    statistic and download new code into the adaptor - functions which can't be
-    performed through the ifconfig(8) interface. Normal
-    operation does not require any special userland program.

-

-

-

-
scsi(4), ifconfig(8)

-

-

-

-
Ian Dall
-    <ian.dall@dsto.defence.gov.au>

-
Acknowledgement: Thanks are due to Philip L.
-    Budne
-    <budd@cs.bu.edu> who
-    reverse engineered the EA41x. In developing this code, Phil's userland
-    daemon "etherd", was referred to extensively in lieu of accurate
-    documentation for the device.

-

-

-

-
The EA41x doesn't conform to the SCSI specification in much at
-    all. About the only standard command supported is "inquiry". Most
-    commands are 6 bytes long, but the recv data is only 1 byte. Data must be
-    received by periodically polling the device with the recv command.

-

-

-
-  
-    
-    
-  
-
February 3, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/sea.4 4.html b/static/netbsd/man4/sea.4 4.html
deleted file mode 100644
index b4ed3395..00000000
--- a/static/netbsd/man4/sea.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
SEA(4)Device Drivers ManualSEA(4)

-

-

-

-
sea —
-    Seagate/Future Domain ISA SCSI adapter card
-  driver

-

-

-

-
sea0 at isa? iomem 0xc8000 irq 5
-  

-  scsibus* at sea?

-

-

-

-
The sea driver provides support for the
-    following SCSI controllers on ISA bus boards:

-

-

-

-  
ST01/02

-  
 

-  
Future Domain TMC-885

-  
 

-  
Future Domain TMC-950

-  
 

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-
-  
-    
-    
-  
-
November 29, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/sec.4 4.html b/static/netbsd/man4/sec.4 4.html
deleted file mode 100644
index 3e0d75b8..00000000
--- a/static/netbsd/man4/sec.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
SEC(4)Device Drivers ManualSEC(4)

-

-

-

-
sec — Acorn SCSI
-    Expansion Card driver

-

-

-

-
sec* at podulebus0 slot ?
-  

-  scsibus* at sec?

-

-

-

-
The sec driver supports the Acorn SCSI
-    Expansion Card, model numbers AKA30, AKA31, and AKA32. These cards support
-    8-bit parallel synchronous transfers at up to 4 MHz.

-

-

-

-
podulebus(4), scsi(4)

-

-

-
-  
-    
-    
-  
-
October 1, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/seeprom.4 4.html b/static/netbsd/man4/seeprom.4 4.html
deleted file mode 100644
index 380455df..00000000
--- a/static/netbsd/man4/seeprom.4 4.html	
+++ /dev/null
@@ -1,113 +0,0 @@
-
-  
-    
-    
-    
-  
-
SEEPROM(4)Device Drivers ManualSEEPROM(4)

-

-

-

-
seeprom —
-    24-series I2C EEPROM driver

-

-

-

-
seeprom0 at iic0 addr 0x51: AT24Cxx or compatible
-    EEPROM: size 256
-  

-  seeprom16 at iic1 addr 0x57: power-supply: size
-  8192

-

-

-

-
The seeprom driver provides support for
-    the ATMEL 24-series of I2C EEPROMs, and compatibles, available from a
-    variety of vendors. The Philips PCF8582 is also supported, as compatible
-    with the AT24C02.

-
Access to the contents of the memory is through a character
-    device.

-
The size of the EEPROM is either read from the firmware, or can be
-    set using the flags keyword in the kernel configuration. The value of the
-    flag represents the EEPROM size in Kbit.

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
128
256
512
1024
2048
4096
8192
16384
32768
65536

-

-

-

-
Indirect configuration:

-
seeprom* at iic? addr 0x51 flags
-  0x2

-Direct configuration:
-
seeprom* at iic? addr?

-

-

-

-
iic(4)

-

-

-

-
The seeprom device appeared in
-    NetBSD 2.0.

-

-

-

-
AT24C1024 EEPROM's are not supported.

-
Software write protection on the AT34Cxx EEPROMs is not
-  supported.

-
The seeprom driver reads and writes one
-    byte at a time to be compatible with all controllers.

-

-

-
-  
-    
-    
-  
-
October 25, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/sem.4 4.html b/static/netbsd/man4/sem.4 4.html
deleted file mode 100644
index e8fa1ba8..00000000
--- a/static/netbsd/man4/sem.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
SEM(4)Device Drivers ManualSEM(4)

-

-

-

-
sem — POSIX
-    semaphores

-

-

-

-
The POSIX semaphore code is included by default in all
-  kernels.

-

-

-

-
The sem facility provides system calls
-    used by the standard C library (libc) to implement POSIX semaphores.

-

-

-

-
config(1), sem_destroy(3),
-    sem_getvalue(3), sem_init(3),
-    sem_open(3), sem_post(3),
-    sem_wait(3), options(4)

-

-

-

-
The sem facility appeared as a kernel
-    option in NetBSD 2.0 and became non-optional in
-    NetBSD 7.0.

-

-

-
-  
-    
-    
-  
-
August 20, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/ses.4 4.html b/static/netbsd/man4/ses.4 4.html
deleted file mode 100644
index 72f67114..00000000
--- a/static/netbsd/man4/ses.4 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
SES(4)Device Drivers ManualSES(4)

-

-

-

-
ses — SCSI
-    Environmental Services Driver

-

-

-

-
ses* at scsibus? target ? lun ?

-

-

-

-
The ses driver provides support for all
-    SCSI devices of the environmental services class that are attached to the
-    system through a supported SCSI Host Adapter, as well as emulated support
-    for SAF-TE (SCSI Accessible Fault Tolerant Enclosures). The environmental
-    services class generally are enclosure devices that provide environmental
-    information such as number of power supplies (and state), temperature,
-    device slots, and so on.

-
A SCSI Host adapter must also be separately configured into the
-    system before a SCSI Environmental Services device can be configured.

-

-

-

-
The following ioctl(2) calls apply to
-    SES devices. They are defined in the header file
-    <scsipi/ses.h> (q.v.).

-

-  

-  
Used to find out how many SES objects are driven by this
-      particular device instance.

-  

-  
Read, from the kernel, an array of SES objects which contains the object
-      identifier, which sub-enclosure it is in, and the SES
-      type of the object.

-  

-  
Get the overall enclosure status.

-  

-  
Set the overall enclosure status.

-  

-  
Get the status of a particular object.

-  

-  
Set the status of a particular object.

-  

-  
Get the associated help text for an object (not yet implemented).
-      SES devices often have descriptive text for an object
-      which can tell you things like location (e.g, "left power
-      supply").

-  

-  
Initialize the enclosure.

-

-

-

-

-

-  
/dev/sesN

-  
The 
-      ses device.

-

-

-

-

-
When the kernel is configured with DEBUG enabled, the first open
-    to an SES device will spit out overall enclosure parameters to the
-  console.

-

-

-

-
getencstat(8), sesd(8),
-    setencstat(8), setobjstat(8)

-

-

-

-
The ses driver was written for the SCSI
-    subsystem by Matthew Jacob. This is the functional equivalent of a similar
-    driver available in Solaris, Release 7.

-

-

-
-  
-    
-    
-  
-
May 24, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/sf.4 4.html b/static/netbsd/man4/sf.4 4.html
deleted file mode 100644
index 11377bd9..00000000
--- a/static/netbsd/man4/sf.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
SF(4)Device Drivers ManualSF(4)

-

-

-

-
sf — Adaptec
-    AIC-6915 10/100 Ethernet driver

-

-

-

-
sf* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The sf device driver supports the Adaptec
-    AIC-6915 10/100 Ethernet chip. This chip is found on several Adaptec
-    Ethernet boards:

-
    
-  
  • ANA-62011 Single port 10/100 64-bit
    • 
-  
  • ANA-62022 Dual port 10/100 64-bit
    • 
-  
  • ANA-62044 Quad port 10/100 64-bit
    • 
-  
  • ANA-62020 Single port 100BASE-FX 64-bit
    • 
-  
  • ANA-69011 Single port 10/100 32-bit
    • 
-

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The sf driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The sf driver was written by
-    Jason R. Thorpe
-  ⟨thorpej@NetBSD.org⟩.

-

-

-

-
The sf driver does not support the
-    IPv4/TCP/UDP checksum function of the AIC-6915.

-
The sf driver does not support the VLAN
-    function of the AIC-6915.

-

-

-
-  
-    
-    
-  
-
June 18, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/sf2r.4 4.html b/static/netbsd/man4/sf2r.4 4.html
deleted file mode 100644
index f8fe5e77..00000000
--- a/static/netbsd/man4/sf2r.4 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
SF2R(4)Device Drivers ManualSF2R(4)

-

-

-

-
sf2r — SoundForte
-    RadioLink SF16-FMR2 FM radio device driver

-

-

-

-
option RADIO_TEA5759

-

-  

-  sf2r0 at isa? port 0x384
-  

-  radio* at sf2r0

-

-

-

-
The sf2r driver provides support for the
-    SF16-FMR2 FM radio tuners.

-
The SF16-FMR2 is a stereo FM tuner that allows to tune in the
-    range 87.5 - 108.0 MHz, report signal status on the current frequency, force
-    audio output to mono, perform hardware signal search, and has an internal
-    AFC.

-
The SF16-FMR2 cards take only one I/O port. The I/O port is set by
-    the driver to the value specified in the configuration file and must be
-    0x384.

-
Philips Semiconductors released two almost identical chips TEA5757
-    and TEA5759. The TEA5757 is used in FM-standards in which the local
-    oscillator frequency is above the radio frequency (e.g. European and
-    American standards). The TEA5759 is the version in which the oscillator
-    frequency is below the radio frequency (e.g. Japanese standards). The option
-    RADIO_TEA5759 changes the algorithm of frequency
-    calculation for the TEA5757 based cards to conform with the Japanese
-    standards.

-

-

-

-
isa(4), radio(4)

-

-

-

-
The sf2r device driver appeared in
-    OpenBSD 3.0 and NetBSD
-  1.6.

-

-

-

-
The sf2r driver was written by
-    Vladimir Popov and Maxim
-    Tsyplakov. The man page was written by Vladimir
-    Popov.

-

-

-

-
MediaForte made two variants of the SF16-FMR2 cards, the first one
-    has an internal amplifier of the output sound, the second one does not have
-    such an amplifier. The current driver supports only the second variant.

-

-

-
-  
-    
-    
-  
-
August 25, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/sfb.4 4.html b/static/netbsd/man4/sfb.4 4.html
deleted file mode 100644
index a0edd372..00000000
--- a/static/netbsd/man4/sfb.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
SFB(4)Device Drivers ManualSFB(4)

-

-

-

-
sfb — PMAGB-B HX
-    colour/grayscale accelerated 2-D framebuffer

-

-

-

-
sfb* at tc? slot ? offset ?
-  

-  wsdisplay* at sfb?

-

-

-

-
The sfb driver provides support for the
-    PMAGB-B HX colour/grayscale 2-D framebuffer for the TURBOchannel bus. The
-    PMAGB-B is an 8 bpp colour/grayscale framebuffer capable of running at a
-    resolution of 1280-by-1024 at 66 or 72 Hz.

-

-

-

-
cfb(4), mfb(4),
-    px(4), pxg(4), tc(4),
-    tfb(4), wscons(4)

-

-

-
-  
-    
-    
-  
-
August 22, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/sgp40mox.4 3.html b/static/netbsd/man4/sgp40mox.4 3.html
deleted file mode 100644
index 31393633..00000000
--- a/static/netbsd/man4/sgp40mox.4 3.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
SGP40MOX(4)Device Drivers ManualSGP40MOX(4)

-

-

-

-
sgp40mox — Driver
-    for Sensirion SGP40 MOx gas sensor

-

-

-

-
sgp40mox* at iic? addr 0x59

-

-

-

-
The sgp40mox driver provides an air
-    quality measurement from the SGP40 sensor via the
-    envsys(4) framework. The sgp40mox
-    addr argument selects the address at the
-    iic(4) bus. The crc validity and temperature and %RH
-    compensation can be changed through sysctl(8) nodes.

-
In order to calculate the VOC index, the volatile organic
-    compounds index, which is the measure of air quality the sensor is polled
-    once a second and the raw sensor value is fed into the Sensirion VOC
-    algorithm. This VOC algorithm used in this driver is licensed under a 3
-    clause BSD license and was pulled from the Sensirion Github repository at
-    https://github.com/Sensirion/embedded-sgp.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
This should be set to the temperature in Celsius of the environment that
-      the sensor is in. The valid values are from -45 to 130 degrees
-    Celsius.

-  

-  
This should be set to the %RH of the environment that the sensor is in.
-      The valid values are from 0 to 100.
-    
For the best performance of the VOC algorithm it is important
-        that the temperature and %RH compensation values be current and set
-        using the sysctl(3) variables mentioned above. This
-        data will need to be pulled from another source, such as a another
-        sensor in the environment that the SGP40 is in.

-  

-  

-  
If set, the crc calculation will be ignored on the calls to the chip for
-      the purposes of measurement.

-  

-  
If the driver is compiled with SGP40_DEBUG, this
-      node will appear and can be used to set the debugging level.

-  

-  
To read the air quality metric from the chip requires that the command be
-      sent, then a delay must be observed before a read can be done to get the
-      values back. The delays are documented in the data sheet for the chip. The
-      driver will attempt to read back the values readattempts number of times.
-      The default is 10 which should be more than enough for most purposes.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The sgp40mox driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The sgp40mox driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The driver does not make complete use of the VOC algorithm. In
-    particular, there is no need to restart the algorithm from scratch if there
-    is a stoppage of polling for less than 10 minutes. The driver does not have
-    the ability to determine that, and therefore assumes that the sensor is
-    completely cold each time the driver attaches to the chip.

-
The temperature and humidity compensation could be allowed to
-    contain fractional degrees Celsius and %RH. The driver only supports setting
-    whole numbers for either of those.

-

-

-
-  
-    
-    
-  
-
October 7, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/sgsmix.4 4.html b/static/netbsd/man4/sgsmix.4 4.html
deleted file mode 100644
index f4e9ffc8..00000000
--- a/static/netbsd/man4/sgsmix.4 4.html	
+++ /dev/null
@@ -1,40 +0,0 @@
-
-  
-    
-    
-    
-  
-
SGSMIX(4)Device Drivers ManualSGSMIX(4)

-

-

-

-
sgsmix — driver
-    for SGS 7433 Basic Audio Processor found in some Apple machines

-

-

-

-
iic* at cuda?
-  

-  sgsmix* at iic? addr 0x8a

-

-

-

-
The sgsmix driver provides support for the
-    external mixer chip on Apple's “personality cards” found in
-    beige Power Macintosh G3. All mixer controls are accessed through the
-    awacs(4) driver, sgsmix
-    additionally provides bass and treble controls.

-

-

-

-
awacs(4), cuda(4),
-    iic(4)

-

-

-
-  
-    
-    
-  
-
May 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/shb.4 3.html b/static/netbsd/man4/shb.4 3.html
deleted file mode 100644
index c180f213..00000000
--- a/static/netbsd/man4/shb.4 3.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
SHB(4)Device Drivers ManualSHB(4)

-

-

-

-
shb — bus for
-    SuperH on-chip peripheral devices

-

-

-

-
shb* at mainbus?

-

-

-

-
The shb driver provides a bus to which
-    drivers for integrated peripheral devices found in various SuperH
-    microprocessors attach.

-

-  
adc

-  
analog/digital converter.

-  
sci

-  
serial communication interface.

-  
scif

-  
serial communication interface with FIFO.

-  
wdog

-  
watchdog timer.

-

-

-

-

-
adc(4), sci(4),
-    scif(4), wdog(4)

-

-

-

-
The shb driver first appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
October 21, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/shmif.4 4.html b/static/netbsd/man4/shmif.4 4.html
deleted file mode 100644
index 0a75b6a6..00000000
--- a/static/netbsd/man4/shmif.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
SHMIF(4)Device Drivers ManualSHMIF(4)

-

-

-

-
shmif — rump
-    kernel shared memory network interface

-

-

-

-
#include
-    <rump/rump.h>

-
int
-  

-  rump_pub_shmif_create(const char
-    *path, int *ifnum);

-

-

-

-
The shmif interface uses a memory mapped
-    regular file as a virtual Ethernet bus. All interfaces connected to the same
-    bus see each others' traffic.

-
Using a memory mapped regular file as a bus has two
-  implications:

-
    
-  
  1. The bus identifier is not in flat global namespace.
    2. 
-  
  2. Configuring and using the interface is possible without superuser
-      privileges on the host (normal host file access permissions for the bus
-      hold).
    3. 
-

-
It is not possible to directly access the host networking
-    facilities from a rump kernel using purely shmif.
-    However, traffic can be routed to another rump kernel instance which
-    provides both shmif and virt(4)
-    networking.

-
An shmif interface can be created in two
-    ways:

-
    
-  
  • Programmatically by calling
-      ().
-      The bus pathname is passed in path. The number of
-      the newly created interface is available after a successful call by
-      dereferencing ifnum.
    • 
-  
  • Dynamically at runtime with ifconfig(8) or
-      equivalent using the
-       command.
-      In this case the bus path must be configured with
-      ifconfig(8)
-      
-      before the interface address can be configured.
    • 
-

-
Destroying an shmif interface
-    is possible only via ifconfig(8)
-    .

-
An shmif interface
-    emulates TX/RX offload options in software. They are specified by
-    ifconfig(8). Alternatively, its
-    
-    flag is directly specified by environment variable
-    RUMP_SHMIF_CAPENABLE, for example:

-

-  
0x7ff80

-  
for all TX/RX offload

-  
0x6aa80

-  
for all TX offload

-  
0x15500

-  
for all RX offload

-

-
See /usr/include/net/if.h for more
-    details.

-

-

-

-
rump(3), virt(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
December 12, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/shpcic.4 4.html b/static/netbsd/man4/shpcic.4 4.html
deleted file mode 100644
index 42577a18..00000000
--- a/static/netbsd/man4/shpcic.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
SHPCIC(4)Device Drivers ManualSHPCIC(4)

-

-

-

-
shpcic — RENESAS
-    SuperH on-chip PCI controller

-

-

-

-
shpcic* at mainbus?
-  

-  pci* at shpcic? bus?

-

-

-

-
The shpcic driver provides support for the
-    RENESAS SuperH PCI controller. SHPCIC is an on-chip module found in
-    following models:

-
    
-  
  • SH7751
    • 
-  
  • SH7751R
    • 
-

-

-

-

-
pci(4)

-

-

-

-
The shpcic driver first appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
September 15, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/sht3xtemp.4 3.html b/static/netbsd/man4/sht3xtemp.4 3.html
deleted file mode 100644
index fc88d56f..00000000
--- a/static/netbsd/man4/sht3xtemp.4 3.html	
+++ /dev/null
@@ -1,122 +0,0 @@
-
-  
-    
-    
-    
-  
-
SHT3XTEMP(4)Device Drivers ManualSHT3XTEMP(4)

-

-

-

-
sht3xtemp — Driver
-    for Sensirion SHT30/SHT31/SHT35 sensor chip via I2C bus

-

-

-

-
sht3xtemp* at iic? addr 0x44
-  

-  sht3xtemp* at iic? addr 0x45

-

-

-

-
The sht3xtemp driver provides measurements
-    from the SHT30/SHT31/SHT35 humidity/temperature sensors via the
-    envsys(4) framework. The sht3xtemp
-    addr locator selects the address at the
-    iic(4) bus. The mode of operation, repeatability, heater
-    controls, periodic update rate and CRC validity can be changed through
-    sysctl(8) nodes.

-

-

-

-
The following sysctl(8) variables are
-  provided:

-

-  

-  
Lists the modes supported by the driver and chip.

-  

-  
Set the operation mode of the chip. The SHT3X chip can run in a
-      single-shot measurement mode or a periodic update mode. Use one of the
-      strings listed in hw.sht3xtemp.modes.

-  

-  
List the periodic update rates supported by the driver and chip.

-  

-  
Set the periodic update rate when the mode of operation is set to
-      periodic. The unit for this is measurements per second, or ART which is a
-      mode that operates at an update rate of 4Hz higher response time. Use one
-      of the strings listed in hw.sht3xtemp.rates.
-    
Since it is possible to have subsecond periodic updates from
-        the chip if so desired a device file is provided that can be used to get
-        the raw temperature and humidity values outside of the
-        envsys(4) framework. The structure of this output is
-        the raw temperature plus an 8-bit CRC followed by the raw humidity plus
-        an 8-bit CRC.

-  

-  

-  
List the valid values for the repeatability used for a measurement.

-  

-  
Set the repeatability for the measurement. The higher the repeatability
-      the longer the measurement will take and the more power used. Use one of
-      the strings listed in
-      hw.sht3xtemp.repeatabilities.

-  

-  
If set, the crc calculation for %RH and temperature in the measurement
-      phrase will be ignored.

-  

-  
Turn the heater on and off.

-  

-  
If the driver is compiled with SHT3X_DEBUG, this
-      node will appear and can be used to set the debugging level.

-  

-  
To read %RH or temperature the chip requires that the command be sent,
-      then a delay must be observed before a read can be done to get the values
-      back. The delays are documented in the datasheet for the chip. The driver
-      will attempt to read back the values readattempts number of times. The
-      default is 10 which should be more than enough for most purposes.

-  

-  
The chip supports a set of commands that lets it use I2C clock stretching
-      to perform the temperature or humidity measurement. If this is set to 1
-      then use the clock stretching commands with the device. Note that the I2C
-      controller must support clock stretching in order for this to work
-      reliability. When this option is enabled, the readattempts sysctl noted
-      above will not be used. This option only apply to single shot
-      measurements.

-

-

-

-

-

-  
/dev/sht3xtempu

-  
SHT3X device unit u file.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The sht3xtemp driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The sht3xtemp driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The datasheet did not provide enough information to get the alarm
-    function of the chip working.

-

-

-
-  
-    
-    
-  
-
October 31, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/sht4xtemp.4 4.html b/static/netbsd/man4/sht4xtemp.4 4.html
deleted file mode 100644
index 773652ae..00000000
--- a/static/netbsd/man4/sht4xtemp.4 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
SHT4XTEMP(4)Device Drivers ManualSHT4XTEMP(4)

-

-

-

-
sht4xtemp — Driver
-    for Sensirion SHT40/SHT41/SHT45 sensor chip via I2C bus

-

-

-

-
sht4xtemp* at iic? addr 0x44

-

-

-

-
The sht4xtemp driver provides measurements
-    from the SHT40/SHT41/SHT45 humidity/temperature sensors via the
-    envsys(4) framework. The sht4xtemp
-    addr argument selects the address at the
-    iic(4) bus. The resolution, heater controls and crc
-    validity can be changed through sysctl(8) nodes.

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-  

-  
Lists the resolutions supported by the driver and chip.

-  

-  
Set the resolution, or number of bits, used for %RH and temperature. Use
-      one of the strings listed in
-      hw.sht4xtemp.resolutions.

-  

-  
If set, the crc calculation for %RH and temperature will be ignored.

-  

-  
Turn the heater on and off. Please note that the heater is turned on right
-      before the measurement and runs for a pulse width of time. Then the
-      measurement is taken and the heater is turned off. There is no way to keep
-      the heater running with this chip.

-  

-  
From 1 to 3, the amount of energy put into the heater. The higher the
-      number, the more power used.

-  

-  
Lists the valid heater pulses supported by the driver and chip.

-  

-  
Set the heater pulse length. Use one of the strings listed in
-      hw.sht4xtemp.heaterpulses.

-  

-  
If the driver is compiled with SHT4X_DEBUG, this
-      node will appear and can be used to set the debugging level.

-  

-  
To read %RH or temperature the chip requires that the command be sent,
-      then a delay must be observed before a read can be done to get the values
-      back. The delays are documented in the datasheet for the chip. The driver
-      will attempt to read back the values readattempts number of times. The
-      default is 10 which should be more than enough for most purposes.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The sht4xtemp driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The sht4xtemp driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
September 28, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/si.4 4.html b/static/netbsd/man4/si.4 4.html
deleted file mode 100644
index 87325f14..00000000
--- a/static/netbsd/man4/si.4 4.html	
+++ /dev/null
@@ -1,141 +0,0 @@
-
-  
-    
-    
-    
-  
-
SI(4)Device Drivers ManualSI(4)

-

-

-

-
si, sw —
-    NCR 5380 SCSI bus host adaptor driver

-

-

-

-

-

-
si0 at obio0 addr 0x140000 ipl 2

-

-

-
sun3 and sun3x

-
si0 at vme2 addr 0x200000 ipl 2 vect 0x40
-  

-  si1 at vme2 addr 0x204000 ipl 2 vect 0x41

-

-

-

-
sebuf0 at vme2 addr 0x300000 ipl 2 vect 0x74 #
-    and 0x75
-  

-  sebuf1 at vme2 addr 0x340000 ipl 2 vect 0x76 # and
-    0x77
-  

-  si* at sebuf?

-

-

-

-
si0 at vme0 addr 0x200000 pri 2 vec
-  0x40

-

-

-

-
sw0 at obio0 addr 0x0a000000 level 3

-

-

-

-

-
The si and sw
-    "SCSI Weird" drivers provide support for the NCR 5380 SCSI Bus
-    Controller (SBC) chip found on various Sun Microsystems CPU motherboards
-    (obio), and on the "Sun-3 VME SCSI" (Sun part # 501-1236) board
-    used in systems with VME bus.

-

-
sun3 and sun3x

-
The sun3 and sun3x version of this driver can be configured with a
-    flags directive in the config(1) file.
-    The values are bits in a bitfield, and are interpreted as follows:

-

-

-

-  
0x000ff

-  
Set bit (1<<target) to disable SCSI disconnect/reselect

-  
0x0ff00

-  
Set bit (1<<(target+8)) to disable SCSI parity checking

-  
0x10000

-  
Set this bit to disable DMA interrupts (poll)

-  
0x20000

-  
Set this bit to disable DMA entirely (use PIO)

-

-

-
For example: "flags 0x1000f" would disable DMA
-    interrupts, and disable disconnect/reselect for targets 0-3. The
-    "target" is the SCSI ID number of a particular device on a
-    particular SCSI bus.

-

-

-

-
The sun4 version of this driver can also be configured with a
-    flags directive in the config(1) file.
-    The values are bits in a bitfield, and are interpreted as follows:

-

-

-

-  
0x01

-  
Use DMA (may be polled)

-  
0x02

-  
Use DMA completion interrupts

-  
0x04

-  
Allow SCSI disconnect/reselect

-

-

-
For example: "flags 0x07" would enable DMA, interrupts,
-    and reselect. By default, DMA is enabled in the sun4 driver.

-

-

-

-

-
cd(4), ch(4),
-    intro(4), scsi(4),
-    sd(4), st(4)

-

-

-

-
David Jones, Gordon Ross
-    ⟨gwr@NetBSD.org⟩,
-  

-  Adam Glass ⟨glass@NetBSD.org⟩,
-  

-  Jason R. Thorpe
-  ⟨thorpej@NetBSD.org⟩.

-

-

-

-
The VME variant has a bit to enable or disable the DMA engine, but
-    that bit also gates the interrupt line from the NCR5380 (!!). Therefore, in
-    order to get any interrupt from the NCR5380, (i.e. for reselect) one must
-    clear the DMA engine transfer count and then enable DMA. This has the
-    further complication that you CAN NOT touch the NCR5380 while the DMA enable
-    bit is set, so we have to turn DMA back off before we even look at the
-    NCR5380.

-
Support for the Sun 4/100 sw "SCSI
-    Weird" is not complete. DMA works, but interrupts (and, thus,
-    reselection) don't for reasons unknown. Further progress has halted pending
-    the availability of a machine for testing.

-
DMA, DMA completion interrupts, and reselection work fine on a Sun
-    4/260 with modern SCSI-II disks attached. There have been reports of
-    reselection failing on Sun Shoebox-type configurations where there are
-    multiple non-SCSI devices behind Emulex or Adaptec bridges. These devices
-    pre-date the SCSI-I spec, and might not behave the way the NCR5380 code
-    expects. For this reason, only DMA is enabled by default in the sun4
-  driver.

-

-

-
-  
-    
-    
-  
-
May 7, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/si70xxtemp.4 3.html b/static/netbsd/man4/si70xxtemp.4 3.html
deleted file mode 100644
index 3f157188..00000000
--- a/static/netbsd/man4/si70xxtemp.4 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
SI70XXTEMP(4)Device Drivers ManualSI70XXTEMP(4)

-

-

-

-
si70xxtemp —
-    Driver for Silicon Labs SI7013/SI7020/SI7021, HTU21D and
-    SHT21 sensor chip via I2C bus

-

-

-

-
si70xxtemp* at iic? addr 0x40

-

-

-

-
The si70xxtemp driver provides
-    measurements from the SI7013/SI7020/SI7021 humidity/temperature sensors via
-    the envsys(4) framework. The
-    si70xxtemp addr locator
-    selects the address at the iic(4) bus. The resolution,
-    heater control and crc validity can be changed through
-    sysctl(8) nodes.

-

-

-

-
The following sysctl(8) variables are
-  provided:

-

-  

-  
Lists the resolutions supported by the driver and chip.

-  

-  
Set the resolution, or number of bits, used for %RH and temperature. Use
-      one of the strings listed in
-      hw.si70xxtemp.resolutions.

-  

-  
If set, the crc calculation for %RH and temperature will be ignored.

-  

-  
If 1, the chip is getting enough power.

-  

-  
Turn the heater on and off.

-  

-  
From 1 to 6, the amount of energy put into the heater. The higher the
-      number, the more power used.
-    
Some HTU21D chips do not support a heater register. These
-        chips are detected and the heater features of the driver will be
-        disabled.

-  

-  

-  
If the driver is compiled with SI70XX_DEBUG, this
-      node will appear and can be used to set the debugging level.

-  

-  
To read %RH or temperature the driver uses a No Hold Master command. This
-      command needs to be sent to the device, a wait must then occur and then
-      another read command is sent to read back the values. Depending on the
-      resolution, and other factors, the wait time varies. The driver will
-      attempt to read back the values readattempts number of times. The default
-      is 40 which should be enough for most purposes. There is an initial wait
-      of 10,500 microseconds followed by a additional 1,000 microseconds per
-      read attempt.

-  

-  
The chip supports a set of commands that lets it use I2C clock stretching
-      to perform the temperature or humidity measurement. If this is set to 1
-      then use the clock stretching commands with the device. Note that the I2C
-      controller must support clock stretching in order for this to work
-      reliability. When this option is enabled, the readattempts sysctl noted
-      above will not be used.

-

-

-

-

-
envsys(4), iic(4),
-    envstat(8), sysctl(8)

-

-

-

-
The si70xxtemp driver first appeared in
-    NetBSD 8.0.

-

-

-

-
The si70xxtemp driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-
-  
-    
-    
-  
-
December 28, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/siisata.4 4.html b/static/netbsd/man4/siisata.4 4.html
deleted file mode 100644
index d0146417..00000000
--- a/static/netbsd/man4/siisata.4 4.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
SIISATA(4)Device Drivers ManualSIISATA(4)

-

-

-

-
siisata — Silicon
-    Image SATA-II controllers driver

-

-

-

-
siisata* at pci? dev ? function ?
-  

-  siisata* at cardbus? function ?

-

-

-

-
The siisata driver supports the Silicon
-    Image SteelVine family of SATA-II controllers, interfacing the hardware with
-    the ata(4) and atapi(4) subsystems.

-
The following controllers are supported by the
-    siisata driver:

-

-

-

-  
Silicon Image SiI3124 4-port PCI/PCI-X

-  
 

-  
Silicon Image SiI3132 2-port PCI-Express x1

-  
 

-  
Adaptec 1220SA (SiI3132 chip)

-  
 

-  
Silicon Image SiI3531 1-port PCI-Express x1

-  
 

-

-

-

-

-

-
ata(4), atapi(4),
-    cardbus(4), pci(4),
-    wd(4)

-

-

-

-
The siisata driver first appeared in
-    NetBSD 5.0. NCQ support was added in
-    NetBSD on October 7, 2017.

-

-

-

-
The siisata driver was written by
-    Jonathan A. Kollasch
-    <jakllsch@kollasch.net>.
-    NCQ support was added by him, and
-  

-  Jaromir Dolecek
-    <jdolecek@NetBSD.org>.

-

-

-

-
Device hot swapping is not yet supported.

-
Silicon Image's Software RAID is not yet supported by the
-    ataraid(4) driver. raid(4) can be used
-    instead.

-

-

-
-  
-    
-    
-  
-
October 7, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/siop.4 4.html b/static/netbsd/man4/siop.4 4.html
deleted file mode 100644
index 1ed55a99..00000000
--- a/static/netbsd/man4/siop.4 4.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
SIOP(4)Device Drivers ManualSIOP(4)

-

-

-

-
siop — Symbios
-    Logic/NCR 53c8xx SCSI driver

-

-

-

-

-

-
siop* at mainbus? irq 3
-  

-  siop* at phatomas? irq 3

-

-

-

-
siop* at pci? dev ? function ?

-

-  

-  options SIOP_SYMLED
-  

-  scsibus* at siop?

-

-

-

-

-
The siop driver provides support for the
-    Symbios Logic/NCR 53x8xx series of SCSI controller chips:

-

-
    
-  
  • 53c810, 53c810a and 53c815 (Fast SCSI)
    • 
-  
  • 53c820, 53c825 and 53c825a (Fast-Wide SCSI)
    • 
-  
  • 53c860 (Ultra SCSI)
    • 
-  
  • 53c875 and 53c875j (Ultra-Wide SCSI)
    • 
-  
  • 53c876 (Dual Ultra-Wide SCSI)
    • 
-  
  • 53c885 (Ultra-Wide SCSI and Ethernet)
    • 
-  
  • 53c895 (Ultra2-Wide SCSI)
    • 
-  
  • 53c896 (PCI 64bit, dual Ultra2-Wide SCSI)
    • 
-  
  • 53c1010-33 (PCI 64bit, dual Ultra160 SCSI)
    • 
-  
  • 53c1510d (PCI 64bit, dual Ultra2-wide SCSI)
    • 
-

-The SIOP_SYMLED option causes the driver to report SCSI activity on the GPIO pin
-  1, which is connected to the activity LED on some adapters. At this time only
-  the 53c895 based Symbios and Tekram adapters are known to require this.
-
If both siop and the
-    esiop(4) drivers are compiled, esiop(4)
-    will take precedence for controllers it supports.

-

-

-

-
cd(4), ch(4),
-    esiop(4), intro(4),
-    pci(4), scsi(4),
-    sd(4), st(4),
-  uk(4)

-

-

-

-
The siop driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The siop driver was written by Manuel
-    Bouyer ⟨Manuel.Bouyer@lip6.fr⟩ for
-    NetBSD.

-

-

-

-
siop supports the 53c1010-33 in
-    Ultra2-wide mode only. Use esiop(4) for Ultra160
-  support.

-

-

-
-  
-    
-    
-  
-
April 5, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/sip.4 4.html b/static/netbsd/man4/sip.4 4.html
deleted file mode 100644
index e1383aa6..00000000
--- a/static/netbsd/man4/sip.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
SIP(4)Device Drivers ManualSIP(4)

-

-

-

-
sip — SiS
-    900-based Ethernet driver

-

-

-

-
sip* at pci? dev ? function ?

-
Configuration of PHYs is also necessary. See
-    mii(4).

-

-

-

-
The sip device driver supports Ethernet
-    interfaces based on the Silicon Integrated Systems SiS 900, SiS 7016, and
-    National Semiconductor DP83815 Ethernet chips.

-
The SiS 900 is found on many motherboards featuring SiS chipsets,
-    and on some embedded systems, and has a built-in PHY. The SiS 7016 is an
-    older version of the chip, which uses an external PHY.

-
The National Semiconductor DP83815 is found on NetGear FA-311 and
-    FA-312 Ethernet boards, and has a built-in PHY.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The sip driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The sip driver was originally written by
-    Jason R. Thorpe for Network Computer, Inc.

-
It has since been modified by Jason R.
-    Thorpe ⟨thorpej@NetBSD.org⟩ and Allen
-    Briggs ⟨briggs@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
May 17, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/siside.4 4.html b/static/netbsd/man4/siside.4 4.html
deleted file mode 100644
index 1dcf51fa..00000000
--- a/static/netbsd/man4/siside.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
SISIDE(4)Device Drivers ManualSISIDE(4)

-

-

-

-
siside — Silicon
-    Integrated System IDE disk controllers driver

-

-

-

-
siside* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The siside driver supports the Silicon
-    Integrated System IDE controllers, and provides the interface with the
-    hardware for the ata(4) driver.

-
The 0x0002 flag forces the siside driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/sk.4 3.html b/static/netbsd/man4/sk.4 3.html
deleted file mode 100644
index 4f36d6da..00000000
--- a/static/netbsd/man4/sk.4 3.html	
+++ /dev/null
@@ -1,203 +0,0 @@
-
-  
-    
-    
-    
-  
-
SK(4)Device Drivers ManualSK(4)

-

-

-

-
sk, skc,
-    msk, mskc —
-    SysKonnect XMAC II and Marvell GMAC based Gigabit
-    Ethernet

-

-

-

-
skc* at pci? dev ? function ?
-  

-  sk* at skc?
-  

-  mskc* at pci? dev ? function ?
-  

-  msk* at mskc?

-

-

-

-
The sk driver provides support for
-    SysKonnect based Gigabit Ethernet adapters and Marvell based Gigabit
-    Ethernet adapters, including the following:

-

-
    
-  
  • SK-9821 SK-NET GE-T single port, copper adapter
    • 
-  
  • SK-9822 SK-NET GE-T dual port, copper adapter
    • 
-  
  • SK-9841 SK-NET GE-LX single port, single mode fiber adapter
    • 
-  
  • SK-9842 SK-NET GE-LX dual port, single mode fiber adapter
    • 
-  
  • SK-9843 SK-NET GE-SX single port, multimode fiber adapter
    • 
-  
  • SK-9844 SK-NET GE-SX dual port, multimode fiber adapter
    • 
-  
  • SK-9521 V2.0 single port, copper adapter (32-bit)
    • 
-  
  • SK-9821 V2.0 single port, copper adapter
    • 
-  
  • SK-9843 V2.0 single port, copper adapter
    • 
-  
  • 3Com 3c940 single port, copper adapter
    • 
-  
  • Belkin Gigabit Desktop Network PCI Card, single port, copper (32-bit)
    • 
-  
  • D-Link DGE-530T single port, copper adapter
    • 
-  
  • Linksys EG1032v2 single-port, copper adapter
    • 
-  
  • Linksys EG1064v2 single-port, copper adapter
    • 
-

-
The msk driver provides support for the
-    Marvell Yukon-2 based Gigabit Ethernet adapters, including the
-  following:

-

-
    
-  
  • Marvell Yukon 88E8035, copper adapter
    • 
-  
  • Marvell Yukon 88E8036, copper adapter
    • 
-  
  • Marvell Yukon 88E8038, copper adapter
    • 
-  
  • Marvell Yukon 88E8050, copper adapter
    • 
-  
  • Marvell Yukon 88E8052, copper adapter
    • 
-  
  • Marvell Yukon 88E8053, copper adapter
    • 
-  
  • Marvell Yukon 88E8055, copper adapter
    • 
-  
  • SK-9E21 1000Base-T single port, copper adapter
    • 
-  
  • SK-9E22 1000Base-T dual port, copper adapter
    • 
-  
  • SK-9E81 1000Base-SX single port, multimode fiber adapter
    • 
-  
  • SK-9E82 1000Base-SX dual port, multimode fiber adapter
    • 
-  
  • SK-9E91 1000Base-LX single port, single mode fiber adapter
    • 
-  
  • SK-9E92 1000Base-LX dual port, single mode fiber adapter
    • 
-  
  • SK-9S21 1000Base-T single port, copper adapter
    • 
-  
  • SK-9S22 1000Base-T dual port, copper adapter
    • 
-  
  • SK-9S81 1000Base-SX single port, multimode fiber adapter
    • 
-  
  • SK-9S82 1000Base-SX dual port, multimode fiber adapter
    • 
-  
  • SK-9S91 1000Base-LX single port, single mode fiber adapter
    • 
-  
  • SK-9S92 1000Base-LX dual port, single mode fiber adapter
    • 
-  
  • SK-9E21D 1000Base-T single port, copper adapter
    • 
-

-
The SysKonnect based adapters consist of two main components: the
-    XaQti Corp. XMAC II Gigabit MAC (sk) and the
-    SysKonnect GEnesis controller ASIC (skc). The XMAC
-    provides the Gigabit MAC and PHY support while the GEnesis provides an
-    interface to the PCI bus, DMA support, packet buffering and arbitration. The
-    GEnesis can control up to two XMACs simultaneously, allowing dual-port NIC
-    configurations.

-
The Marvell based adapters are a single integrated circuit, but
-    are still presented as a separate MAC (sk) and
-    controller ASIC (skc). At this time, there are no
-    dual-port Marvell based NICs.

-
The sk driver configures dual port
-    SysKonnect adapters such that each XMAC is treated as a separate logical
-    network interface. Both ports can operate independently of each other and
-    can be connected to separate networks. The SysKonnect driver software
-    currently only uses the second port on dual port adapters for failover
-    purposes: if the link on the primary port fails, the SysKonnect driver will
-    automatically switch traffic onto the second port.

-
The XaQti XMAC II supports full and half duplex operation with
-    autonegotiation. The XMAC also supports unlimited frame sizes. Support for
-    jumbo frames is provided via the interface MTU setting. Selecting an MTU
-    larger than 1500 bytes with the ifconfig(8) utility
-    configures the adapter to receive and transmit jumbo frames. Using jumbo
-    frames can greatly improve performance for certain tasks, such as file
-    transfers and data streaming.

-
Hardware TCP/IP checksum offloading for IPv4 is available but not
-    supported by the driver.

-
The following media types and options (as given to
-    ifconfig(8)) are supported:

-

-

-  

-    autoselect

-  
Enable autoselection of the media type and options. The user can manually
-      override the autoselected mode. ifconfig.if(5)

-  

-    1000baseSX mediaopt
-    full-duplex

-  
Set 1000Mbps (Gigabit Ethernet) operation on fiber and force full-duplex
-      mode.

-  

-    1000baseSX mediaopt
-    half-duplex

-  
Set 1000Mbps (Gigabit Ethernet) operation on fiber and force half-duplex
-      mode.

-  

-    1000baseT mediaopt
-    full-duplex

-  
Set 1000Mbps (Gigabit Ethernet) operation and force full-duplex mode.

-

-

-
For more information on configuring this device, see
-    ifconfig(8). To view a list of media types and options
-    supported by the card, try ifconfig
-    -m
-    <device>. For example,
-    ifconfig -m
-    sk0.

-

-

-

-

-  
sk%d: couldn't map memory

-  
A fatal initialization error has occurred.

-  
sk%d: couldn't map ports

-  
A fatal initialization error has occurred.

-  
sk%d: couldn't map interrupt

-  
A fatal initialization error has occurred.

-  
sk%d: failed to enable memory mapping!

-  
The driver failed to initialize PCI shared memory mapping. This might
-      happen if the card is not in a bus-master slot.

-  
sk%d: no memory for jumbo buffers!

-  
The driver failed to allocate memory for jumbo frames during
-      initialization.

-  
sk%d: watchdog timeout

-  
The device has stopped responding to the network, or there is a problem
-      with the network connection (cable).

-

-

-

-

-
ifmedia(4), intro(4),
-    netintro(4), pci(4),
-    ifconfig.if(5), ifconfig(8)

-
XaQti XMAC II datasheet,
-    http://www.xaqti.com.

-
SysKonnect GEnesis programming
-    manual,
-    http://www.syskonnect.com.

-

-

-

-
The sk device driver first appeared in
-    FreeBSD 3.0. OpenBSD support
-    was added in OpenBSD 2.6.
-    NetBSD support was added in NetBSD
-    2.0.

-
The msk driver first appeared in
-    OpenBSD 4.0, and was ported to
-    NetBSD 4.0.

-

-

-

-
The sk driver was written by
-    Bill Paul
-    <wpaul@ctr.columbia.edu>.
-    Support for the Marvell Yukon-2 was added by Mark
-    Kettenis
-    <kettenis@openbsd.org>.

-

-

-

-
Support for checksum offload is unimplemented. Particularly for
-    Yukon-II hardware, there are multiple different receive and transmit offload
-    silicon bugs which have to be worked around in software when using hardware
-    offloading. For this reason, support for hardware offloading is not very
-    desirable for these controllers, and unlikely to be ever implemented.

-
Performance with at least some Marvell-based adapters is poor,
-    especially on loaded PCI buses or when the adapters are behind PCI-PCI
-    bridges. It is believed that this is because the Marvell parts have
-    significantly less buffering than the original SysKonnect cards had.

-

-

-
-  
-    
-    
-  
-
April 23, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/sl.4 4.html b/static/netbsd/man4/sl.4 4.html
deleted file mode 100644
index ea67a8cf..00000000
--- a/static/netbsd/man4/sl.4 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
SL(4)Device Drivers ManualSL(4)

-

-

-

-
sl — Serial Line
-    IP (SLIP) network interface

-

-

-

-
pseudo-device sl

-

-

-

-
The sl interface allows asynchronous
-    serial lines to be used as IPv4 network interfaces using the SLIP
-  protocol.

-
To use the sl interface, the administrator
-    must first create the interface and assign a tty line to it. The
-    sl interface is created using the
-    ifconfig(8) create subcommand, and
-    slattach(8) is used to assign a tty line to the interface.
-    Once the interface is attached, network source and destination addresses and
-    other parameters are configured via ifconfig(8).

-
The sl interface can use Van Jacobson TCP
-    header compression and ICMP filtering. The following flags to
-    ifconfig(8) control these properties of a SLIP link:

-

-  
link0

-  
Turn on Van Jacobson header compression.

-  
-link0

-  
Turn off header compression. (default)

-  
link1

-  
Don't pass through ICMP packets.

-  
-link1

-  
Do pass through ICMP packets. (default)

-  
link2

-  
If a packet with a compressed header is received, automatically enable
-      compression of outgoing packets. (default)

-  
-link2

-  
Don't auto-enable compression.

-

-

-

-

-

-  
sl%d: af%d not supported.

-  
The interface was handed a message with addresses formatted in an
-      unsuitable address family; the packet was dropped.

-

-

-

-

-
inet(4), intro(4),
-    ppp(4), ifconfig(8),
-    slattach(8), sliplogin(8),
-    slstats(8)

-
J. Romkey,
-    A Nonstandard for Transmission of IP Datagrams over Serial
-    Lines: SLIP, RFC,
-    1055, June
-  1988.

-
Van Jacobson,
-    Compressing TCP/IP Headers for Low-Speed Serial
-    Links, RFC, 1144,
-    February 1990.

-

-

-

-
The sl device appeared in
-    NetBSD 1.0.

-

-

-

-
SLIP can only transmit IPv4 packets between preconfigured hosts on
-    an asynchronous serial link. It has no provision for address negotiation,
-    carriage of additional protocols (e.g. XNS, AppleTalk, DECNET), and is not
-    designed for synchronous serial links. This is why SLIP has been superseded
-    by the Point-to-Point Protocol (PPP), which does all of those things, and
-    much more.

-

-

-
-  
-    
-    
-  
-
January 18, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/slhci.4 4.html b/static/netbsd/man4/slhci.4 4.html
deleted file mode 100644
index 8e0c991c..00000000
--- a/static/netbsd/man4/slhci.4 4.html	
+++ /dev/null
@@ -1,142 +0,0 @@
-
-  
-    
-    
-    
-  
-
SLHCI(4)Device Drivers ManualSLHCI(4)

-

-

-

-
slhci —
-    Cypress/ScanLogic SL811HS USB Host Controller
-  driver

-

-

-

-

-

-
slhci* at zbus?

-

-

-

-
slhci* at pcmcia? function ?
-  

-  usb* at slhci?

-

-

-

-
slhci* at isa? port ? irq ?
-  

-  usb* at slhci?

-

-

-

-
tcu* at tc? slot ? offset ?
-  

-  slhci* at tcu?
-  

-  usb* at slhci?

-

-

-

-
slhci0 at intio0 addr 0xece380 intr 251
-  

-  slhci1 at intio0 addr 0xeceb80 intr 250
-  

-  usb* at slhci?

-

-  

-  options SLHCI_TRY_LSVH

-

-

-

-

-
The slhci driver provides support for
-    Cypress/ScanLogic SL811HS USB Host Controller.

-
The driver supports control, bulk, and interrupt transfers but not
-    isochronous (audio), which cannot be supported by this chip without
-    perfectly reliable 1ms interrupts. USB is polled and this chip requires the
-    driver to initiate all transfers. The driver interrupts at least once every
-    ms when a device is attached even if no data is transferred. The driver
-    polls the chip when the transfer is expected to be completed soon; with
-    maximum use of the bus, the driver will not exit for most of each ms. Use of
-    this driver can easily have a significant performance impact on any
-  system.

-
The chip is unreliable in some conditions, possibly due in part to
-    difficulty meeting timing restrictions (this is likely to be worse on
-    multiprocessor systems). Unexpected device behavior may trigger some
-    problems; power cycling externally powered devices may help resolve
-    persistent problems. Detection of invalid chip state will usually cause the
-    driver to halt, however is recommended that all data transfers be verified.
-    Data corruption due to controller error will not be detected automatically.
-    Unmounting and remounting a device is necessary to prevent use of cached
-    data.

-
The driver currently will start the next incoming packet before
-    copying in the previous packet but will not copy the next outgoing packet
-    before the previous packet is transferred. Reading or writing the chip is
-    about the same speed as the USB bus, so this means that one outgoing
-    transfer is half the speed of one incoming transfer and two outgoing
-    transfers are needed to use the full available bandwidth.

-
All revisions of the SL811HS have trouble with low speed devices
-    attached to some (likely most) hubs. Low speed traffic via hub is not
-    allowed by default, but can be enabled with options
-    SLHCI_TRY_LSVH in the kernel config file or by setting the
-    slhci_try_lsvh variable to non-zero using
-    ddb(4) or gdb(1).

-
Many USB keyboards have built in hubs and may be low speed
-    devices. All USB mice I have seen are low speed devices, however a serial
-    mouse should be usable on a hub with a full speed Serial-USB converter. A
-    PS2-USB keyboard and mouse converter is likely to be a single low speed
-    device.

-
Some hardware using this chip does not provide the USB minimum
-    100mA current, which could potentially cause problems even with externally
-    powered hubs. The system can allow excess power use in some other cases as
-    well. Some signs of excess power draw may cause the driver to halt, however
-    this may not stop the power draw. To be safe verify power use and
-    availability before connecting any device.

-

-

-

-
Hardware supported by the slhci driver
-    includes:

-
    
-  
  • Ratoc CFU1U
    • 
-  
  • Nereid Ethernet/USB/Memory board
    • 
-  
  • Thylacine USB Host Controller
    • 
-  
  • flxd TC-USB
    • 
-

-

-

-

-
config(1), isa(4),
-    pcmcia(4), tc(4),
-    tcu(4), usb(4)

-
Cypress SL811HS datasheet,
-    errata, and application note,
-    http://www.cypress.com.

-

-

-

-
The slhci driver appeared in
-    NetBSD 2.0 and was rewritten in
-    NetBSD 5.0.

-

-

-

-
Tetsuya Isaki
-    ⟨isaki@NetBSD.org⟩
-  

-  Matthew Orgass

-

-

-
-  
-    
-    
-  
-
October 14, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/slide.4 4.html b/static/netbsd/man4/slide.4 4.html
deleted file mode 100644
index db8b8d60..00000000
--- a/static/netbsd/man4/slide.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
SLIDE(4)Device Drivers ManualSLIDE(4)

-

-

-

-
slide — Symphony
-    Labs and Winbond IDE disk controllers driver

-

-

-

-
slide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The slide driver supports the Symphony
-    Labs 82C105 and Winbond W83C553F IDE controllers, and provides the interface
-    with the hardware for the ata(4) driver.

-
The 0x0002 flag forces the slide driver to
-    disable DMA on chipsets for which DMA would normally be enabled. This can be
-    used as a debugging aid, or to work around problems where the IDE controller
-    is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/slurm.4 4.html b/static/netbsd/man4/slurm.4 4.html
deleted file mode 100644
index 770d245d..00000000
--- a/static/netbsd/man4/slurm.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
SLURM(4)Device Drivers ManualSLURM(4)

-

-

-

-
slurm — Silicon
-    Labs USB FM radio device driver

-

-

-

-
slurm* at uhub? port ?
-  

-  radio* at slurm?

-

-

-

-
The slurm driver provides support for USB
-    FM radios based on the Silicon Labs si470x reference design, such as the
-    Instant FM Music RDX-155.

-
Programs such as radioctl(1) can control the
-    device using the radio(4) interface. The device supports:
-    querying and setting frequency, volume, signal, and stereo status, as well
-    as searching for stations.

-

-

-

-
radioctl(1), radio(4),
-    uaudio(4)

-

-

-

-
The slurm device driver appeared in
-    NetBSD 7.0.

-

-

-

-
The slurm driver was written by
-    Jonathan A. Kollasch.

-

-

-
-  
-    
-    
-  
-
July 8, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/sm.4 4.html b/static/netbsd/man4/sm.4 4.html
deleted file mode 100644
index bbcd44d3..00000000
--- a/static/netbsd/man4/sm.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
SM(4)Device Drivers ManualSM(4)

-

-

-

-
sm —
-    SMC91Cxx-based Ethernet interfaces device driver

-

-

-

-
sm0 at ifpga0 addr 0xb8000000 irq 27
-  

-  sm0 at isa? port 0x300 irq 10
-  

-  sm* at mhzc?
-  

-  sm* at pcmcia? function ?
-  

-  sm* at nubus?

-

-

-

-
The sm device driver supports
-    SMC91C9x-based and SMC91C1xx-based Ethernet interfaces.

-
The ifpga0 attachment of the sm driver
-    supports SMC91C9x-based Ethernet interface on the ARM Integrator/CP
-  board.

-
The ISA attachment of the sm driver
-    supports any SMC91C9x-based Ethernet interface on the ISA bus, including the
-    EFA Info*Express SVC VLB interface, and the on-board SMC91C9x Ethernet found
-    in many embedded PCs and laptop docking stations.

-
The mhzc attachment of the sm driver
-    supports the Megahertz combo Ethernet and modem card.

-
The PCMCIA attachment of the sm driver
-    supports Megahertz X-JACK Ethernet cards.

-
The nubus attachment of the sm driver
-    supports SMC-based Ethernet cards for the macintosh.

-

-

-

-
The SMC91C1xx supports the MII interface and so the list of
-    supported media depends on several factors, including which PHY is attached.
-    The SMC91C9x supports AUI and UTP media types.

-
To enable the AUI media, select the
-     or
-     media
-    type with ifconfig(8)'s media
-    directive. To select UTP, select the
-    
-    or  media
-    type.

-
ifconfig(8)'s -m option
-    will display the full list of supported media
-    directives for a particular configuration.

-

-

-

-

-  
sm0: unable to read MAC address from CIS

-  
This indicates that the Ethernet address, which is stored in the CIS
-      information on the Megahertz X-JACK PCMCIA Ethernet card, is
-    corrupted.

-

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), mhzc(4),
-    mii(4), pcmcia(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
September 6, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/smsc.4 4.html b/static/netbsd/man4/smsc.4 4.html
deleted file mode 100644
index 3bbd7050..00000000
--- a/static/netbsd/man4/smsc.4 4.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
SMSC(4)Device Drivers ManualSMSC(4)

-

-

-

-
smsc — Standard
-    Microsystems Corporation LPC47B397 Super I/O

-

-

-

-
smsc0 at isa? port 0x2e

-

-

-

-
The smsc driver provides support for the
-    hardware monitoring portion of the Standard Microsystems Corporation
-    LPC47B397, SCH5307-NS, and SCH5317 Super I/O chips to be used with the
-    envsys(4) API.

-
The chip supports 8 sensor inputs:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uKCPU 1 Temperature
uKCPU 2 Temperature
uKAmbient Temperature
uKunused
RPMCPU 1 Fan
RPMunused
RPMunused
RPMCPU 2 Fan

-

-

-

-
Motherboards with the chip supported by the
-    smsc driver include:

-
    
-  
  • Tyan Thunder K8WE (S2895)
    • 
-

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The smsc device appeared in
-    NetBSD 5.0.

-

-

-
-  
-    
-    
-  
-
April 3, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/smscmon.4 4.html b/static/netbsd/man4/smscmon.4 4.html
deleted file mode 100644
index c88862bb..00000000
--- a/static/netbsd/man4/smscmon.4 4.html	
+++ /dev/null
@@ -1,115 +0,0 @@
-
-  
-    
-    
-    
-  
-
SMSCMON(4)Device Drivers ManualSMSCMON(4)

-

-

-

-
smscmon — Standard
-    Microsystems Corporation LPC47M192 Super I/O

-

-

-

-
smscmon0 at iic? addr 0x2c
-  

-  smscmon0 at iic? addr 0x2d

-

-

-

-
The smscmon driver provides support for
-    the hardware monitoring portion of the Standard Microsystems Corporation
-    LPC47M192 and LPC47M997 Super I/O chips to be used with the
-    envsys(4) API.

-
The chip supports 11 sensor inputs:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uV DC2.5V Supply
uV DCCPU Vcore
uV DC3.3V Supply
uV DC5V Supply
uV DC12V Supply
uV DCChip's supply voltage
uV DC1.5V Supply
uV DC1.8V Supply
uKCPU temperature
uKLocal chip temperature
uK

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The smscmon device appeared in
-    NetBSD 6.0.

-

-

-

-
The smscmon driver was written by
-    Takahiro Hayashi.

-

-

-
-  
-    
-    
-  
-
June 1, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/smscphy.4 4.html b/static/netbsd/man4/smscphy.4 4.html
deleted file mode 100644
index a65cec68..00000000
--- a/static/netbsd/man4/smscphy.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
SMSCPHY(4)Device Drivers ManualSMSCPHY(4)

-

-

-

-
smscphy — SMSC
-    LAN87xx 10/100 Ethernet PHYs

-

-

-

-
smscphy* at mii? phy ?

-

-

-

-
The smscphy driver supports SMSC LAN8700,
-    LAN8710, and LAN8720 10/100 Ethernet PHYs.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-

-
The smscphy device driver first appeared
-    in FreeBSD 8.0 and NetBSD
-    9.0.

-

-

-

-
The smscphy driver was written by
-    Ben Gray for FreeBSD and
-    ported to NetBSD by Masanobu
-    SAITOH.

-

-

-
-  
-    
-    
-  
-
November 1, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/smsh.4 4.html b/static/netbsd/man4/smsh.4 4.html
deleted file mode 100644
index d9b10886..00000000
--- a/static/netbsd/man4/smsh.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
SMSH(4)Device Drivers ManualSMSH(4)

-

-

-

-
smsh — SMSC
-    LAN9118/LAN9218 Family Ethernet interfaces device driver

-

-

-

-
smsh0 at gxio? port 0x40000300 gpirq
-  99

-

-

-

-
The smsh device driver supports SMSC
-    LAN9118 and LAN9218 Family Ethernet interfaces.

-
The ISA attachment of the smsh driver
-    supports any LAN9118 Family Ethernet interface on the ISA bus, the on-board
-    LAN9118 Family Ethernet found in many embedded PCs. However, no ISA
-    attachment has been written yet.

-
LAN9218 Family supports also HP Auto-MDIX.

-

-

-

-
Media selection done using ifconfig(8) using the
-    standard ifmedia(4) mechanism. Refer to those manual pages
-    for more information.

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), mii(4),
-    ifconfig(8)

-

-

-

-
The smsh driver first appeared in
-    NetBSD 6.0.

-

-

-

-
The smsh driver was written by
-    KIYOHARA Takashi
-    <kiyohara@kk.iij4u.or.jp>.

-

-

-

-
No ISA attachment yet.

-

-

-
-  
-    
-    
-  
-
December 2, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/sn.4 4.html b/static/netbsd/man4/sn.4 4.html
deleted file mode 100644
index 3da5b9b9..00000000
--- a/static/netbsd/man4/sn.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
SN(4)Device Drivers ManualSN(4)

-

-

-

-
sn — National
-    Semiconductor DP83932 (SONIC) based Ethernet device driver

-

-

-

-

-

-
sn0 at jazzio?

-

-

-

-
sn* at obio?
-  

-  sn* at nubus?

-

-

-

-

-
The sn interface provides access to a 10
-    Mb/s Ethernet network via the National Semiconductor DP83932 (SONIC)
-    Ethernet chip set.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    sn interface employs the address resolution protocol
-    described in arp(4) to dynamically map between Internet
-    and Ethernet addresses on the local network.

-

-

-

-

-

-
The sn driver supports on-board JAZZ based
-    SONIC interfaces found on Acer PICA and NEC machines.

-

-

-

-
The sn driver is currently known to
-    support the following NuBus cards:

-
    
-  
  • Apple LC Twisted-pair (part #820-0532-A) PDS card
    • 
-  
  • Cayman Gatorcard PDS
    • 
-  
  • Dayna DaynaPort/E30
    • 
-

-
In addition, the sn interface supports the
-    following interfaces:

-
    
-  
  • on-board Ethernet for non-AV Quadras
    • 
-  
  • on-board Ethernet for 500-series PowerBooks
    • 
-  
  • Apple CS Ethernet Twisted-pair card for Comm Slot found on LC575, Quadra
-      630, LC630, and Performa 580.
    • 
-

-

-

-

-

-

-  
sn%d: transmit FIFO underrun

-  

-  
sn%d: receive FIFO overrun

-  

-  
sn%d: receive buffer exceeded

-  

-  
sn%d: receive buffers exhausted

-  

-  
sn%d: receive descriptors exhausted

-  
These messages indicate that the interface gets errors (due to heavy load
-      etc.) and reinitialized.

-

-

-

-

-
arp(4), inet(4),
-    netintro(4), ifconfig(8)

-

-

-

-
The sn interface for mac68k, which was
-    derived from a driver for old NetBSD/pica port,
-    first appeared in NetBSD 1.3.

-
Jason Thorpe has rewritten a new machine independent SONIC driver
-    which uses bus_dma(9) and bus_space(9)
-    APIs after NetBSD 1.5 release, and
-    NetBSD/arc has been switched to using the machine
-    independent (MI) driver.

-
NetBSD/mac68k has also been switched to
-    using the MI driver after the NetBSD 4.0
-  release.

-

-

-
-  
-    
-    
-  
-
May 16, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/sony.4 4.html b/static/netbsd/man4/sony.4 4.html
deleted file mode 100644
index 4d126d88..00000000
--- a/static/netbsd/man4/sony.4 4.html	
+++ /dev/null
@@ -1,120 +0,0 @@
-
-  
-    
-    
-    
-  
-
SONY(4)Device Drivers ManualSONY(4)

-

-

-

-
sony — Sony
-    Miscellaneous Controller

-

-

-

-
sony* at acpi?

-

-

-

-
Some Sony notebook computers have a controller that handles
-    various built-in devices. The sony driver provides
-    support for accessing/modifying the settings of some of these devices via
-    the sysctl(8) interface.

-
The following sysctl(8) variables are
-  available:

-

-

-  

-    [R/W]

-  
Controls current LCD brightness. Range [0-8].

-  

-    [R/W]

-  
Controls power on LCD brightness. Range [0-8].

-  

-    [R/W]

-  
Controls CD power.

-  

-    [R/O]

-  
Unknown

-  

-    [R/W]

-  
Unknown

-  

-    [R/W]

-  
Unknown

-  

-    [R/W]

-  
Unknown

-  

-    [R/W]

-  
Audio control (mute when 0)

-  

-    [R/O]

-  
Indicates a Host Key Event. Bits are set when an event occurs and cleared
-      when this value is read. The following table describes the bit set for
-      each button pressed:
-    

-    

-    

-      

-      
S1 button

-      

-      
S2 button

-      

-      
Fn + F10 (magnify)

-      

-      
Mute button

-      

-      
Fn + F12 (suspend to disk)

-      

-      
Fn + F7 (LCD/external monitor)

-      

-      
Fn + F6 (brighter backlight)

-      

-      
Fn + F5 (darker backlight)

-      

-      
Fn + F4 (volume up)

-      

-      
Fn + F3 (volume down)

-    

-    

-  

-

-

-

-

-
acpi(4), i386/spic(4)

-

-

-

-
The sony driver appeared in
-    NetBSD 4.0.

-

-

-

-
Sami Kantoluoto for the original driver
-    and manual information. Christos Zoulas for cleaning
-    up the driver and this manual page.

-

-

-

-
    
-  
  • The sony driver just parses integer values from
-      the acpi(4) tree. It could be more intelligent and parse
-      other controls.
    • 
-  
  • The sysctl(8) interface is not great. The names of the
-      sysctl(8) tree are not self-explanatory.
    • 
-  
  • No validity checks are performed on the user input. Playing with random
-      values and/or unknown controls can harm your machine.
    • 
-  
  • The name of the driver is too generic.
    • 
-

-

-

-
-  
-    
-    
-  
-
August 25, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/spc.4 4.html b/static/netbsd/man4/spc.4 4.html
deleted file mode 100644
index eb7e8e81..00000000
--- a/static/netbsd/man4/spc.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
SPC(4)Device Drivers ManualSPC(4)

-

-

-

-
spc — Fujitsu
-    MB87030/MB89352 SCSI driver

-

-

-

-
spc* at pcmcia? function ?

-

-

-
spc0 at dio? scode ?

-

-

-

-
spc0 at mainbus0

-

-

-

-
spc0 at scsirom0
-  

-  spc1 at scsirom1

-

-  

-  scsibus* at spc?

-

-

-

-

-
The spc driver provides support for the
-    Fujitsu MB87030/MB89352 SCSI Protocol Controller (SPC) chips.

-

-

-

-
cd(4), ch(4),
-    intro(4), pcmcia(4),
-    scsi(4), sd(4), ss(4),
-    st(4), uk(4),
-    scsipi(9)

-

-

-

-
Synchronous data transfers are not currently supported.

-

-

-
-  
-    
-    
-  
-
August 1, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/spdmem.4 4.html b/static/netbsd/man4/spdmem.4 4.html
deleted file mode 100644
index da4147fc..00000000
--- a/static/netbsd/man4/spdmem.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
SPDMEM(4)Device Drivers ManualSPDMEM(4)

-

-

-

-
spdmem — Generic
-    Memory Module Serial Presence Detect

-

-

-

-
spdmem* at iic? addr 0x50
-  

-  spdmem* at iic? addr 0x51
-  

-  spdmem* at iic? addr 0x52
-  

-  spdmem* at iic? addr 0x53
-  

-  spdmem* at iic? addr 0x54
-  

-  spdmem* at iic? addr 0x55
-  

-  spdmem* at iic? addr 0x56
-  

-  spdmem* at iic? addr 0x57

-

-

-

-
The spdmem driver provides support for
-    generic memory module Serial Presence Detect. During kernel boot it displays
-    module type, and where possible, the size and rated speed of the memory
-    module. Additional information such as bank configuration and width is
-    printed if the kernel is booted in verbose mode.

-
The Serial Presence Detect data for each memory module is also
-    made accessible to user mode via sysctl(8). An entry for
-    each spdmem device is created under the
-    hw top-level MIB.

-
Some SPD ROMs also have a temperature sensor. It's supported by
-    sdtemp(4).

-

-

-

-
iic(4), intro(4),
-    sdtemp(4)

-

-

-

-
The spdmem driver first appeared in
-    NetBSD 5.0.

-

-

-

-
The spdmem driver was written by
-    Nicolas Joly
-    <njoly@pasteur.fr>
-    with additional work by Paul Goyette
-    <paul@whooppee.com>.

-

-

-
-  
-    
-    
-  
-
July 27, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/speaker.4 3.html b/static/netbsd/man4/speaker.4 3.html
deleted file mode 100644
index a6560174..00000000
--- a/static/netbsd/man4/speaker.4 3.html	
+++ /dev/null
@@ -1,306 +0,0 @@
-
-  
-    
-    
-    
-  
-
SPEAKER(4)Device Drivers ManualSPEAKER(4)

-

-

-

-
speaker — console
-    speaker audio device driver

-

-

-

-
spkr*	at pcppi?
-  

-  spkr*	at audio?

-

-  

-  #include <dev/spkrio.h>

-

-

-

-
The speaker device driver allows applications to control the
-    console speaker on machines with a PC-like 8253 timer implementation or a
-    synthesized speaker from an audio device/soundcard.

-
Only one process may have this device open at any given
-    time; open(2) and close(2) are used to
-    lock and relinquish it. An attempt to open(2) when another
-    process has the device locked will return -1 with an
-    EBUSY error indication. Writes to the device are
-    interpreted as “play strings” in a simple ASCII melody
-    notation. An
-    () for
-    tone generation at arbitrary frequencies is also supported.

-
For the pcppi(4) device
-    sound-generation does
-     monopolize the
-    processor; in fact, the driver spends most of its time sleeping while the PC
-    hardware is emitting tones. Other processes may emit beeps while the driver
-    is running.

-
For the audio device speaker, the speaker uses one of the virtual
-    audio channels. Enabling this device will also provide a
-    wsbell(4) keyboard bell.

-
Applications may call
-    () on
-    a speaker file descriptor to control the speaker driver directly;
-    definitions for the ioctl() interface are in
-    <dev/spkrio.h>.

-
The tone_t structure is as follows:

-

-
typedef struct {
-	int	frequency;	/* in hertz */
-	int	duration;	/* in 1/100ths of a second */
-} tone_t;

-

-
A frequency of zero is interpreted as a rest.

-
At present there are four ioctls:

-

-  

-  
Returns an integer, which is the current bell volume as a percentage
-      (0–100).

-  

-  
Accepts an integer, which is the desired volume as a percentage.

-  

-  
Accepts a pointer to a single tone structure as third argument and plays
-      it.

-  

-  
Accepts a pointer to the first of an array of tone structures and plays
-      them in continuous sequence; this array must be terminated by a final
-      member with a zero duration.

-

-

-

-
The play string language is modelled on the
-    PLAY statement conventions of IBM BASIC
-    2.0. The MB,
-    MF and X commands of
-    PLAY are not useful in a UNIX environment and are
-    not implemented. The “octave-tracking” feature is also
-  new.

-
There are 84 accessible notes numbered 1–84 in 7 octaves
-    numbered 0–6; octave 2 starts with middle C. The tuning is
-    equal-tempered A440.

-
In the initial state the current octave is 4, the default note
-    duration is quarter notes, the tempo is 120 bpm, and the articulation is
-    non-legato or normal, i.e. half-second notes with the last 1/16th second
-    being “rest time”.

-
Play strings are interpreted left to right as a series of play
-    command groups. Letter case is ignored. Whitespace between groups is ignored
-    and may be used to separate melody sections. Play command groups are as
-    follows:

-

-  
,
-    D, E,
-    F, G,
-    A, B

-  
Letters ‘A’ through
-      ‘G’ cause the corresponding note to
-      be played in the current octave. A note letter may optionally be followed
-      by an
-      , one of ‘#’,
-      ‘+’, or
-      ‘-’; the first two of these cause it
-      to be sharped one half-tone, the last causes it to be flatted one
-      half-tone. It may also be followed by a time value number and by sustain
-      dots (see below). Time values are interpreted as for the
-      ‘L’ command below;.

-  
n,
-    OL, ON

-  
If n is numeric, this sets the current octave.
-      ‘OL’ enables, and
-      ‘ON’ disables
-      
-      (it is disabled by default). When octave-tracking is on, interpretation of
-      a pair of letter notes will change octaves if necessary in order to make
-      the smallest possible jump between notes. Thus
-      “olbc” will be played as
-      “olb>c”, and
-      “olcb” as
-      “olc<b”. Octave tracking is
-      temporarily disabled for one letter note that follows
-      ‘>’,
-      ‘<’ or
-      ‘On’.

-  

-  
Bump the current octave up one.

-  

-  
Drop the current octave down one.

-  
n

-  
Play note n, n being 1 to 84
-      or 0 for a rest of current time value. May be followed by sustain
-    dots.

-  
n

-  
Sets the current time value for notes. The default is
-      “L4”, quarter notes. The lowest
-      possible value is 1; values up to 64 are accepted.
-      “L1” sets whole notes,
-      “L2” sets half notes,
-      “L4” sets quarter notes, etc...

-  
n,
-    ~n

-  
Pause (rest), with n interpreted as for
-      ‘L’. May be followed by sustain
-      dots.

-  
n

-  
Sets the number of quarter notes per minute; default is 120. Musical names
-      for common tempi are:
-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
very slowLarghissimo
Largo40–60
Larghetto60–66
Grave
Lento
Adagio66–76
slowAdagietto
Andante76–108
mediumAndantino
Moderato108–120
fastAllegretto
Allegro120–168
Vivace
Veloce
Presto168–208
very fastPrestissimo

-  

-  
,
-    MN, MS

-  
Set articulation. ‘MN’ (for normal)
-      is the default; the last 1/8th of the note's value is rest time. You can
-      set ‘ML’ for legato (no rest time)
-      or ‘MS’ for staccato (1/4 rest
-      time).

-

-
Notes, that is, C,
-    D, E,
-    F, G,
-    A, B, or
-    N command character groups, may be followed by
-    sustain dots. Each dot causes the note's value to be lengthened by one-half
-    for each one. Thus, a note dotted once is held for 3/2 of its undotted
-    value; dotted twice, it is held 9/4, and three times would give 27/8.

-

-

-

-

-

-  
/dev/speaker

-  
 

-

-

-

-

-
audio(4), pcppi(4),
-    wsbell(4), sysctl(8)

-

-

-

-
This speaker device was originally for the
-    pcppi PC timer interface. Support was added for a synthesized device by
-    Nathanial Sloss, first appearing in NetBSD 8.0.

-

-

-

-
Eric S. Raymond
-    <esr@snark.thyrsus.com>

-

-

-

-
Due to roundoff in the pitch tables and slop in the
-    tone-generation and timer hardware (neither of which was designed for
-    precision), neither pitch accuracy nor timings will be mathematically
-  exact.

-
There is no volume control.

-
The action of two or more sustain dots does not reflect standard
-    musical notation, in which each dot adds half the value of the previous dot
-    modifier, not half the value of the note as modified. Thus, a note dotted
-    once is held for 3/2 of its undotted value; dotted twice, it is held 7/4,
-    and three times would give 15/8. The multiply-by-3/2 interpretation,
-    however, is specified in the IBM BASIC manual and has been retained for
-    compatibility.

-
In play strings which are very long (longer than your system's
-    physical I/O blocks) note suffixes or numbers may occasionally be parsed
-    incorrectly due to crossing a block boundary.

-

-

-
-  
-    
-    
-  
-
June 13, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/spi.4 4.html b/static/netbsd/man4/spi.4 4.html
deleted file mode 100644
index 81db5989..00000000
--- a/static/netbsd/man4/spi.4 4.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
SPI(4)Device Drivers ManualSPI(4)

-

-

-

-
spi — introduction
-    to machine-independent SPI bus support and drivers

-

-

-

-
spi* at mainbus?
-  

-  spi* at umcpmio?

-
Other attachments are machine-dependent and will depend on the bus
-    topology of your system. See intro(4) for your system for
-    more information.

-

-

-

-
NetBSD includes a machine dependent SPI
-    (Serial Peripheral Interface) bus subsystem, and several different
-    machine-independent SPI device drivers.

-
Your system may support additional machine-dependent SPI devices.
-    Consult your system's intro(4) for additional
-  information.

-
SPI is a 4-wire synchronous full-duplex serial bus. Some systems
-    provide support for Microwire, which is Philips' name for a strict subset of
-    SPI, with more rigidly defined signaling. Therefore, Microwire devices are
-    also supported by the SPI framework.

-
Note that when referencing SPI devices in a
-    config(1) file, the ‘slave’ must be
-    provided, as SPI lacks any way to automatically probe devices.

-

-

-

-
The following ioctl(2) calls apply to
-     devices.
-    They are defined in the header file
-    <dev/spi/spi_io.h>:

-

-  

-  
Used to choose the operational mode and clock. The
-      sic_mode defines polarity and phase of the clock.
-      sic_speed is the clock speed in Hz, a value of 0
-      means to keep the default speed of the device.
-    

-    
typedef struct spi_ioctl_configure {
-	int sic_addr;
-	int sic_mode;
-	int sic_speed;
-} spi_ioctl_configure_t;

-    

-  

-  

-  
Used to handle an I/O transaction.
-    

-    
typedef struct spi_ioctl_transfer {
-	int sit_addr;
-	const void *sit_send;
-	size_t sit_sendlen;
-	void *sit_recv;
-	size_t sit_recvlen;
-} spi_ioctl_transfer_t;

-    

-  

-

-

-

-

-
NetBSD includes the following
-    machine-independent SPI drivers:

-

-

-  
bmx280thp(4)

-  
Bosch BMP280 / BME280 sensor.

-  
m25p(4)

-  
STMicroelectronics M25P family of NOR flash devices.

-  
mcp23s17gpio(4)

-  
Microchip MCP23S17 16-bit GPIO chip.

-  
mcp3kadc(4)

-  
Microchip MCP3x0x SAR analog to digital converter.

-  
mcp48x1dac(4)

-  
Microchip MCP4801/MCP4811/MCP4821 digital to analog converter.

-  
sc16is7xx(4)

-  
NXP 16C450 like UART bridge

-  
scmdspi(4)

-  
SPI frontend for the Sparkfun Serial Controlled Motor Driver.

-  
ssdfb(4)

-  
OLED/PLED framebuffer modules.

-  
tm121temp(4)

-  
Texas Instruments TMP121 temperature sensor.

-

-

-

-

-

-

-  
/dev/spiu

-  
SPI device unit u file.

-

-

-

-

-
spi(9)

-

-

-

-
The machine-independent SPI framework was written by
-    Garrett D'Amore for the Champaign-Urbana Community
-    Wireless Network Project (CUWiN), and appeared in NetBSD
-    4.0. The ioctl(2) interface allowing configuration
-    from userspace appeared in NetBSD 9.0.

-

-

-
-  
-    
-    
-  
-
February 27, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/spif.4 4.html b/static/netbsd/man4/spif.4 4.html
deleted file mode 100644
index 37fc21d8..00000000
--- a/static/netbsd/man4/spif.4 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
SPIF(4)Device Drivers ManualSPIF(4)

-

-

-

-
spif — SBus
-    (spiffy) Serial/Parallel Interface

-

-

-

-
spif* at sbus? slot ? offset ? 
-    (sun4c/sun4m/sun4u)
-  

-  stty* at spif?  (sun4c/sun4m/sun4u)
-  

-  sbpp* at spif?  (sun4c/sun4m/sun4u)

-

-

-

-
The spif driver provides support for the
-    Sun Serial/Parallel Interface card (Sun part number 501-1931), which is
-    based on the Cirrus Logic CD180 octal serial controller and the Cirrus Logic
-    PPC2 parallel port controller.

-
The device minor numbers for this driver are encoded as
-  follows:

-

-
    +---+---+---+---+---+---+---+---+
-    | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-    +---+---+---+---+---+---+---+---+
-      |   |   |   |   |   |   |   |
-      |   |   |   |   |   +---+---+---> port number
-      |   |   |   |   |
-      |   |   |   |   +---------------> unused
-      |   |   |   |
-      |   |   |   +-------------------> dial-out (on tty ports)
-      |   |   |
-      |   |   +-----------------------> unused
-      |   |
-      +---+---------------------------> card number

-

-
Up to four cards are supported in the system.

-
Each of the serial ports has an 8 byte FIFO for receive and
-    transmit as well as automatic hardware (RTS/CTS) flow control.

-

-

-

-

-  
/dev/ttyS[0123][0-7]

-  
Serial ports

-  
/dev/bppS[0-3]

-  
Parallel ports

-

-

-

-

-

-  
spif%d: ccr timeout

-  
A timeout occurred while writing to one of the CD180 registers.

-  
stty%d-%d: ring overflow

-  
Incoming characters were discarded because the application in control of
-      the device did not read the input fast enough.

-

-

-

-

-
intro(4), sbus(4),
-    tty(4)

-

-

-

-
The spif adapter was first supported in
-    OpenBSD 2.5. The driver was ported to
-    NetBSD 3.0.

-

-

-

-
The driver was written by Jason Wright
-    <jason@thought.net>,
-    and is heavily based on the magma(4) driver written by
-    Iain Hibbert.

-

-

-

-
The parallel port is not supported yet.

-
Dial-out (cua) devices are not yet supported.

-

-

-
-  
-    
-    
-  
-
February 4, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/sqphy.4 4.html b/static/netbsd/man4/sqphy.4 4.html
deleted file mode 100644
index 1f0ef6bb..00000000
--- a/static/netbsd/man4/sqphy.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
SQPHY(4)Device Drivers ManualSQPHY(4)

-

-

-

-
sqphy — Driver for
-    Seeq 80220/80221, 80223, and 80225 10/100 Ethernet PHYs

-

-

-

-
sqphy* at mii? phy ?

-

-

-

-
The sqphy driver supports the Seeq
-    80220/80221, 80223, and 80225 10/100 Ethernet PHYs. The 80223 is a 3.3 volt
-    version of the 80221. The 80225 is a stripped down version of the 80223.
-    These PHYs are found on a variety of high-performance Ethernet
-  interfaces.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
July 25, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/srt.4 3.html b/static/netbsd/man4/srt.4 3.html
deleted file mode 100644
index d0b20954..00000000
--- a/static/netbsd/man4/srt.4 3.html	
+++ /dev/null
@@ -1,108 +0,0 @@
-
-  
-    
-    
-    
-  
-
SRT(4)Device Drivers ManualSRT(4)

-

-

-

-
srt —
-    source-routing network interface

-

-

-

-
pseudo-device srt

-

-

-

-
The srt interface is a software interface
-    that implements source-address-based routing. Packets are directed to the
-    srt interface using normal routing decision process.
-    Packets queued for delivery are then processed according to the rules
-    established for the interface using the srtconfig(1)
-    utility.

-
To use an srt device, the
-    administrator must first create the interface. This can be done by using the
-    ifconfig(8) create command. An
-    open(2) call on
-    /dev/srt
-    will also create a network interface with a unit number the same as the
-    minor device number of that device if the interface doesn't exist yet.

-
To be useful, the srt interface
-    needs to be configured using srtconfig(1) which uses the
-    associated srt character device
-    /dev/srt.

-
The network interfaces should be named
-    srt0,
-    srt1, etc. The
-    srt interface supports only the
-    open(2), close(2), and
-    ioctl(2) operations; other operations such as
-    read(2) and write(2) are not
-  supported.

-
All standard network interface ioctl(2) calls
-    are supported by the srt interface. In addition, the
-    following ioctl(2) calls (defined in
-    ⟨net/if_srt.h⟩) are supported on the
-    srt character device:

-

-

-  

-  
The argument is a pointer to an integer, in which the number of entries in
-      the device's routing table is returned.

-  

-  
The argument is the address of a struct srt_rt. The
-      routing table entry specified by the “inx” member is
-      returned.

-  

-  
The argument is the address of a struct srt_rt. The
-      routing entry is placed into the device's routing table at the index
-      specified by the “inx” member.

-  

-  
The argument is the address of a struct srt_rt. The
-      routing entry specified by the “inx” member is deleted from
-      the device's routing table. (Any entries in the device's routing table
-      with higher index values are renumbered.)

-  

-  
The argument is a pointer to an integer containing any of the following
-      flags to be set:
-    

-      

-      
If set, do not automatically update the interface's MTU.

-    

-  

-  

-  
The argument is a pointer to an integer in which the current flags are
-      returned.

-  

-  
This call updates the flags in the same manner as
-      SRT_SFLAGS. The original flags are returned in the
-      integer pointed to by the argument.

-  

-  
Currently this is a no-op.

-

-

-

-

-

-
srtconfig(1), inet(4),
-    intro(4)

-

-

-

-
The srt device was added in
-    NetBSD 5.0 by der Mouse
-    <mouse@NetBSD.org>.
-    This manual page was prepared by Paul Goyette
-    <pgoyette@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
March 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/ss.4 4.html b/static/netbsd/man4/ss.4 4.html
deleted file mode 100644
index 3fb15789..00000000
--- a/static/netbsd/man4/ss.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
SS(4)Device Drivers ManualSS(4)

-

-

-

-
ss — SCSI scanner
-    driver

-

-

-

-
ss* at scsibus? target ? lun ?

-

-

-

-
The ss driver provides support for SCSI
-    bus based document scanners.

-

-

-

-

-  
/dev/ssu

-  
SCSI bus scanner unit u

-  
/dev/nssu

-  
SCSI bus scanner unit u - no rewind.

-  
/dev/enssu

-  
SCSI bus scanner unit u - ioctl(2)
-      operations only.

-

-

-

-

-
scsi(4), uk(4)

-

-

-

-
Kenneth Stailey, Joachim
-    Koenig

-

-

-

-
Only a limited number of HP Scanjet and Mustek scanners are
-    supported. Other scanners can probably be accessed using the SCSI
-    uk(4) driver instead.

-

-

-
-  
-    
-    
-  
-
June 1, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/ssdfb.4 4.html b/static/netbsd/man4/ssdfb.4 4.html
deleted file mode 100644
index 69f917f1..00000000
--- a/static/netbsd/man4/ssdfb.4 4.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
SSDFB(4)Device Drivers ManualSSDFB(4)

-

-

-

-
ssdfb — OLED/PLED
-    framebuffer device driver

-

-

-

-
options FONT_SPLEEN5x8
-  

-  ssdfb* at iic? addr ?
-  

-  ssdfb* at iic? addr 0x3c
-  

-  ssdfb* at iic? addr 0x3d flags 0x102
-  

-  ssdfb* at spi? slave ? flags 0x105
-  

-  wsdisplay* at ssdfb?

-

-

-

-
The ssdfb driver provides
-    wsdisplay(4) support for OLED/PLED framebuffer modules
-    based on one of the following controller chips:

-
    
-  
  • Solomon Systech Ltd SSD1306
    • 
-  
  • Sino Wealth Electronic Ltd SH1106
    • 
-  
  • Solomon Systech Ltd SSD1322
    • 
-  
  • Solomon Systech Ltd SSD1353
    • 
-

-
The following products (controller + panel assemblies) are
-    supported:

-
    
-  
  • :
-      Generic SSD1306 modules using default settings
    • 
-  
  • :
-      Generic SH1106 modules using default settings
    • 
-  
  • :
-      Adafruit Industries, LLC product 931 (128x32)
    • 
-  
  • :
-      Adafruit Industries, LLC product 938 (128x64)
    • 
-  
  • :
-      Generic SSD1322 modules using default settings
    • 
-  
  • :
-      Generic SSD1353 modules using default settings
    • 
-  
  • :
-      Display Elektronik GmbH DEP 160128A(1)-RGB
    • 
-

-
The flags value can contain one or more of the following, bitwise
-    OR'ed:

-
    
-  
  • :
-      Exactly one product id from the above list
    • 
-  
  • :
-      indicates that the display is mounted upside down and flips the
-    screen
    • 
-  
  • :
-      enable inverse video
    • 
-  
  • :
-      forcibly attach as console
    • 
-

-
On most displays, the contrast setting can be adjusted with the
-    wsconsctl(8) program.

-

-

-

-
To attach an SSD1322 display using the 4-wire
-    spi(4) interface on an Allwinner A20 ARM single board
-    computer, the following Device Tree overlay can be used:

-

-
&spi0 {
-	ssdfb@0 {
-		compatible = "solomon,ssd1322";
-		reg = <0x00>;
-		dc-gpio = <0x10 0x07 0x02 0x00>;
-		status = "okay";
-	};
-};

-

-
To attach an SSD1306 display using the iic(4)
-    interface on the same board, use:

-

-
&i2c2 {
-	ssdfb@3c {
-		compatible = "solomon,ssd1306fb-i2c";
-		reg = <0x3c>;
-		status = "okay";
-	};
-};

-

-

-

-

-
iic(4), wsdisplay(4)

-

-

-

-
An ssdfb driver first appeared in
-    OpenBSD 6.4 and later in NetBSD
-    9.0.

-

-

-

-
The ssdfb driver was written by
-    Tobias Nygren
-    <tnn@NetBSD.org>.

-
It was inspired by (and shares its name with) the
-    OpenBSD driver written by Patrick
-    Wildt
-    <patrick@blueri.se>
-    but does not share any code.

-

-

-
-  
-    
-    
-  
-
August 5, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/st.4 3.html b/static/netbsd/man4/st.4 3.html
deleted file mode 100644
index d97cfba3..00000000
--- a/static/netbsd/man4/st.4 3.html	
+++ /dev/null
@@ -1,351 +0,0 @@
-
-  
-    
-    
-    
-  
-
ST(4)Device Drivers ManualST(4)

-

-

-

-
st — SCSI/ATAPI
-    tape driver

-

-

-

-
st* at scsibus? target ? lun ?
-  

-  st1 at scsibus0 target 4 lun 0
-  

-  st* at atapibus? drive ? flags 0x0000

-

-

-

-
The st driver provides support for SCSI
-    and Advanced Technology Attachment Packet Interface (ATAPI) tape drives. It
-    allows a tape drive to be run in several different modes depending on minor
-    numbers and supports several different ‘sub-modes’. The device
-    can have both a
-    
-    interface and a
-    
-    interface; however, only the raw interface is usually used (or
-  recommended).

-
SCSI and ATAPI devices have a relatively high level interface and
-    talk to the system via a SCSI or ATAPI adapter and a SCSI or ATAPI adapter
-    driver (e.g. ahc(4), pciide(4)). A SCSI
-    or ATAPI adapter must also be separately configured into the system before a
-    SCSI or ATAPI tape can be configured.

-
As the SCSI or ATAPI adapter is probed during
-    boot, the SCSI or ATAPI bus is scanned for devices. Any devices found which
-    answer as
-    ‘’
-    type devices will be attached to the st driver.

-

-

-

-
The st driver is based around the concept
-    of a
-    “”, which is defined as the period between the time
-    that a tape is mounted, and the time when it is unmounted. Any parameters
-    set during a mount session remain in effect for the remainder of the session
-    or until replaced. The tape can be unmounted, bringing the session to a
-    close in several ways. These include:

-
    
-  
  1. Closing an ‘unmount device’, referred to as sub-mode 00
-      below. An example is /dev/rst0.
    2. 
-  
  2. Using the MTOFFL ioctl(2)
-      command, reachable through the
-      ‘offline’ command of
-      mt(1).
    3. 
-  
  3. Opening a different mode will implicitly unmount the tape, thereby closing
-      off the mode that was previously mounted. All parameters will be loaded
-      freshly from the new mode (See below for more on modes).
    4. 
-

-

-

-

-
There are several different ‘operation’ modes. These
-    are controlled by bits 2 and 3 of the minor number and are designed to allow
-    users to easily read and write different formats of tape on devices that
-    allow multiple formats. The parameters for each mode can be set individually
-    by hand with the mt(1) command. When a device
-    corresponding to a particular mode is first mounted, The operating
-    parameters for that mount session are copied from that mode. Further changes
-    to the parameters during the session will change those in effect for the
-    session but not those set in the operation mode. To change the parameters
-    for an operation mode, one must compile them into the
-    “quirk” table in the driver's source
-  code.

-
In addition to the operating modes mentioned above, bits 0 and 1
-    of the minor number are interpreted as ‘sub-modes’. The
-    sub-modes differ in the action taken when the device is closed:

-

-  
00

-  
A close will rewind the device; if the tape has been written, then a file
-      mark will be written before the rewind is requested. The device is
-      unmounted.

-  
01

-  
A close will leave the tape mounted. If the tape was written to, a file
-      mark will be written. No other head positioning takes place. Any further
-      reads or writes will occur directly after the last read, or the written
-      file mark.

-  
10

-  
A close will rewind the device. If the tape has been written, then a file
-      mark will be written before the rewind is requested. On completion of the
-      rewind an unload command will be issued. The device is unmounted.

-  
11

-  
This is Control mode, which allows the tape driver to be opened without a
-      tape inserted to allow various ioctls (e.g. MTIOCGET or MTIOCTOP to set
-      density or blocksize) and raw SCSI command on through. I/O can be done in
-      this mode, if desired, with the same rewind/eject behaviour as mode 01.
-      This isn't really an 'action taken on close' type of distinction, but this
-      seems to be the place to put this mode.

-

-

-

-

-
SCSI tapes may run in either
-    ‘’
-    or
-    ‘’
-    block-size modes. Most QIC-type devices run in fixed block-size mode, where
-    most nine-track tapes and many new cartridge formats allow variable
-    block-size. The difference between the two is as follows:

-

-  
Variable block-size

-  
Each write made to the device results in a single logical record written
-      to the tape. One can never read or write
-       of a record
-      from tape (though you may request a larger block and read a smaller
-      record); nor can one read multiple blocks. Data from a single write is
-      therefore read by a single read. The block size used may be any value
-      supported by the device, the SCSI adapter and the system (usually between
-      1 byte and 64 Kbytes, sometimes more).
-    
When reading a variable record/block from the tape, the head
-        is logically considered to be immediately after the last item read, and
-        before the next item after that. If the next item is a file mark, but it
-        was never read, then the next process to read will immediately hit the
-        file mark and receive an end-of-file notification.

-  

-  
Fixed block-size

-  
Data written by the user is passed to the tape as a succession of fixed
-      size blocks. It may be contiguous in memory, but it is considered to be a
-      series of independent blocks. One may never write an amount of data that
-      is not an exact multiple of the blocksize. One may read and write the same
-      data as a different set of records, In other words, blocks that were
-      written together may be read separately, and vice-versa.
-    
If one requests more blocks than remain in the file, the drive
-        will encounter the file mark. Because there is some data to return
-        (unless there were no records before the file mark), the read will
-        succeed, returning that data. The next read will return immediately with
-        an EOF (as above, if the file mark is never read, it remains for the
-        next process to read if in no-rewind mode).

-  

-

-

-

-

-
The handling of file marks on write is automatic. If the user has
-    written to the tape, and has not done a read since the last write, then a
-    file mark will be written to the tape when the device is closed. If a rewind
-    is requested after a write, then the driver assumes that the last file on
-    the tape has been written, and ensures that there are two file marks written
-    to the tape. The exception to this is that there seems to be a standard
-    (which we follow, but don't understand why) that certain types of tape do
-    not actually write two file marks to tape, but when read, report a
-    ‘phantom’ file mark when the last file is read. These devices
-    include the QIC family of devices (it might be that this set of devices is
-    the same set as that of fixed block devices. This has not been determined
-    yet, and they are treated as separate behaviors by the driver at this
-  time).

-

-

-

-
Attempts to write past EOM and how EOM is reported are handled
-    slightly differently based upon whether EARLY WARNING recognition is enabled
-    in the driver.

-
If EARLY WARNING recognitions is not enabled,
-    then detection of EOM (as reported in SCSI Sense Data with an EOM indicator)
-    causes the write operation to be flagged with I/O error (EIO). This has the
-    effect for the user application of not knowing actually how many bytes were
-    read (since the return of the read(2) system call is set
-    to −1).

-
If EARLY WARNING recognition
-     enabled, then
-    detection of EOM (as reported in SCSI Sense Data with an EOM indicator) has
-    no immediate effect except that the driver notes that EOM has been detected.
-    If the write completing didn't transfer all data that was requested, then
-    the residual count (counting bytes not written) is
-    returned to the user application. In any event, the next attempt to write
-    (if that is the next action the user application takes) is immediately
-    completed with no data transferred, and a residual returned to the user
-    application indicating that no data was transferred. This is the traditional
-    UNIX EOF indication. The state that EOM had been seen is then cleared.

-
In either mode of operation, the driver does not prohibit the user
-    application from writing more data, if it chooses to do so. This will
-    continue up until the physical end of media, which is usually signalled
-    internally to the driver as a CHECK CONDITION with the Sense Key set to
-    VOLUME OVERFLOW. When this or any otherwise unhandled error occurs, an error
-    return of EIO will be transmitted to the user application. This does indeed
-    mean that if EARLY WARNING is enables and the device continues to set EOM
-    indicators prior to hitting physical end of media, that an indeterminate
-    number of 'short write returns' as described in the previous paragraph will
-    occur. However, the expected user application behaviour (in common with
-    other systems) is to close the tape and rewind and request another tape upon
-    the receipt of the first EOM indicator, possibly after writing one trailer
-    record.

-

-

-

-
Because different tape drives behave differently, there is a
-    mechanism within the source to st to quickly and
-    conveniently recognize and deal with brands and models of drive that have
-    special requirements.

-
There is a table (called the “quirk
-    table”) in which the identification strings of known errant
-    drives can be stored. Alongside each is a set of flags that allows the
-    setting of densities and blocksizes for each of the modes, along with a set
-    of `QUIRK' flags that can be used to enable or disable sections of code
-    within the driver if a particular drive is recognized.

-

-

-

-
The following ioctl(2) calls apply to SCSI
-    tapes. Some also apply to other tapes. They are defined in the header file
-    <sys/mtio.h>.

-

-  

-  
(struct mtget) Retrieve the status and parameters
-      of the tape. Error status and residual is unlatched and cleared by the
-      driver when it receives this ioctl.

-  

-  
(struct mtop) Perform a multiplexed operation. The
-      argument structure is as follows:
-    

-    
struct mtop {
-	short	mt_op;
-	daddr_t	mt_count;
-};

-    

-    
The following operation values are defined for
-        mt_op:

-    

-      

-      
Write mt_count end of file marks at the present
-          head position.

-      

-      
Skip over mt_count file marks. Leave the head on
-          the EOM side of the last skipped file mark.

-      

-      
Skip
-          
-          over mt_count file marks. Leave the head on the
-          BOM (beginning of media) side of the last skipped file mark.

-      

-      
Skip forwards over mt_count records.

-      

-      
Skip backwards over mt_count records.

-      

-      
Rewind the device to the beginning of the media.

-      

-      
Rewind the media (and, if possible, eject). Even if the device cannot
-          eject the media it will often no longer respond to normal
-        requests.

-      

-      
No-op; set status only.

-      

-      
Erase the media from current position. If the field
-          mt_count is nonzero, a full erase is done (from
-          current position to end of media). If mt_count
-          is zero, only an erase gap is written. It is hard to say which drives
-          support only one but not the other option

-      

-      
Enable controller buffering.

-      

-      
Disable controller buffering.

-      

-      
Set the blocksize to use for the device/mode. If the device is capable
-          of variable blocksize operation, and the blocksize is set to 0, then
-          the drive will be driven in variable mode. This parameter is in effect
-          for the present mount session only, unless the device was opened in
-          Control Mode (in which case this set value persists until a
-        reboot).

-      

-      
Set the density value (see mt(1)) to use when
-          running in the mode opened (minor bits 2 and 3). This parameter is in
-          effect for the present mount session only, unless the device was
-          opened in Control Mode (in which case this set value persists until a
-          reboot). Any byte sized value may be specified. Note that only a very
-          small number of them will actually usefully work. The rest will cause
-          the tape drive to spit up.

-      

-      
Enable or disable tape drive data compression. Typically tape drives
-          will quite contentedly ignore settings on reads, and will probably
-          keep you from changing density for writing anywhere but BOT.

-      

-      
Enable or disable EARLY WARNING at EOM behaviour (using the count as a
-          boolean value).

-    

-  

-  

-  
(uint32_t) Read device logical block position. Not
-      all drives support this option.

-  

-  
(uint32_t) Read device hardware block position.
-      Not all drives support this option.

-  

-  
(uint32_t) Position the tape to the specified
-      device logical block position.

-  

-  
(uint32_t) Position the tape to the specified
-      hardware block position. Not all drives support this option.

-

-

-

-

-

-  
/dev/[n][e]rst[0-9]

-  
general form:

-  
/dev/rst0

-  
Mode 0, Rewind on close

-  
/dev/nrst0

-  
Mode 1, No rewind on close

-  
/dev/erst0

-  
Mode 2, Eject on close (if capable)

-  
/dev/enrst0

-  
Mode 3, Control Mode (elsewise like mode 0)

-

-

-

-

-
mt(1), intro(4),
-    mtio(4), scsi(4)

-

-

-

-
This st driver was originally written for
-    Mach 2.5 by Julian Elischer, and was ported to
-    NetBSD by Charles Hannum. This man page was edited
-    for NetBSD by Jon Buller.

-

-

-

-
The selection of compression could possibly also be usefully done
-    as with a minor device bit.

-

-

-
-  
-    
-    
-  
-
August 23, 1996NetBSD 10.1

diff --git a/static/netbsd/man4/ste.4 4.html b/static/netbsd/man4/ste.4 4.html
deleted file mode 100644
index d2dc2a24..00000000
--- a/static/netbsd/man4/ste.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
STE(4)Device Drivers ManualSTE(4)

-

-

-

-
ste — Sundance
-    ST-201 10/100 Ethernet driver

-

-

-

-
ste* at pci? dev ? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The ste device driver supports the
-    Sundance ST-201 10/100 Ethernet chip. This chip is found on the D-Link
-    DFE-550TX, the quad-port D-Link DFE-580TX, and some other mid-range 10/100
-    Ethernet boards.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The ste driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The ste driver was written by
-    Jason R. Thorpe
-  ⟨thorpej@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
June 19, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/stf.4 3.html b/static/netbsd/man4/stf.4 3.html
deleted file mode 100644
index 1064d74c..00000000
--- a/static/netbsd/man4/stf.4 3.html	
+++ /dev/null
@@ -1,190 +0,0 @@
-
-  
-    
-    
-    
-  
-
STF(4)Device Drivers ManualSTF(4)

-

-

-

-
stf — 6to4 tunnel
-    interface

-

-

-

-
pseudo-device stf

-

-

-

-
The stf interface supports
-    “6to4” IPv6 in IPv4 encapsulation. It can tunnel IPv6 traffic
-    over IPv4, as specified in RFC3056.
-    stf interfaces are dynamically created and destroyed
-    with the ifconfig(8) create and
-    destroy subcommands. Only one
-    stf interface may be created.

-
For ordinary nodes in 6to4 sites, you do not need a
-    stf interface. The stf
-    interface is only necessary on the site border router (called the
-    “6to4 router” in the specification).

-
Due to the way the 6to4 protocol is specified,
-    stf interfaces require certain configuration to work
-    properly. A single (no more than one) valid 6to4 address needs to be
-    configured on the interface. “A valid 6to4 address” is an
-    address which has the following properties. If any of the following
-    properties are not satisfied, stf raises a runtime
-    error on packet transmission. Read the specification for more details.

-
    
-  
  • matches 2002:xxyy:zzuu::/48, where
-      xxyy:zzuu is the hexadecimal notation of an IPv4
-      address for the node. The IPv4 address used can be taken from any
-      interface your node has. Since the specification forbids the use of IPv4
-      private address, the address needs to be a global IPv4 address.
    • 
-  
  • Subnet identifier portion (48th to 63rd bit) and interface identifier
-      portion (lower 64 bits) are properly filled to avoid address
-    collisions.
    • 
-

-
If you would like the node to behave as a relay router, the prefix
-    length for the IPv6 interface address needs to be 16 so that the node would
-    consider any 6to4 destination as “on-link”. If you would like
-    to restrict 6to4 peers to be inside a certain IPv4 prefix, you may want to
-    configure the IPv6 prefix length to be “16 + IPv4 prefix
-    length”. The stf interface will check the
-    IPv4 source address on packets if the IPv6 prefix length is larger than
-  16.

-
stf can be configured to be ECN (Explicit
-    Congestion Notification) friendly. This can be configured by
-    IFF_LINK1. See gif(4) for
-  details.

-
Please note that the 6to4 specification is written as an
-    “accept tunneled packet from everyone” tunneling device. By
-    enabling the stf device, you are making it much
-    easier for malicious parties to inject fabricated IPv6 packets to your node.
-    Also, malicious parties can inject IPv6 packets with fabricated source
-    addresses to make your node generate improper tunneled packets.
-    Administrators must be cautious when enabling the interface. To prevent
-    possible attacks, the stf interface filters out the
-    following packets (note that the checks are in no way complete):

-
    
-  
  • Packets with IPv4 unspecified addresses as outer IPv4 source/destination
-      (0.0.0.0/8)
    • 
-  
  • Packets with the loopback address as outer IPv4 source/destination
-      (127.0.0.0/8)
    • 
-  
  • Packets with IPv4 multicast addresses as outer IPv4 source/destination
-      (224.0.0.0/4)
    • 
-  
  • Packets with limited broadcast addresses as outer IPv4 source/destination
-      (255.0.0.0/8)
    • 
-  
  • Packets with private addresses as outer IPv4 source/destination
-      (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
    • 
-  
  • Packets with IPv4 link-local addresses as outer IPv4 source/destination
-      (169.254.0.0/16)
    • 
-  
  • Packets with subnet broadcast addresses as outer IPv4 source/destination.
-      The check is made against subnet broadcast addresses for all of the
-      directly connected subnets.
    • 
-  
  • Packets that do not pass ingress filtering. Outer IPv4 source addresses
-      must meet the IPv4 topology on the routing table. Ingress filtering can be
-      turned off by IFF_LINK2 bit.
    • 
-  
  • The same set of rules are applied against the IPv4 address embedded into
-      the inner IPv6 address, if the IPv6 address matches the 6to4 prefix.
    • 
-  
  • Packets with site-local or link-local unicast addresses as inner IPv6
-      source/destination
    • 
-  
  • Packets with node-local or link-local multicast addresses as inner IPv6
-      source/destination
    • 
-

-
It is recommended to filter/audit incoming IPv4 packets with IP
-    protocol number 41, as necessary. It is also recommended to filter/audit
-    encapsulated IPv6 packets as well. You may also want to run normal ingress
-    filtering against inner IPv6 addresses to avoid spoofing.

-
By setting the IFF_LINK0 flag on the
-    stf interface, it is possible to disable the input
-    path, making direct attacks from the outside impossible. Note, however, that
-    other security risks exist. If you wish to use the configuration, you must
-    not advertise your 6to4 addresses to others.

-

-

-

-
Note that 8504:0506 is equal to
-    133.4.5.6, written in hexadecimal.

-

-
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
-# ifconfig stf0 create inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
-	prefixlen 16 alias

-

-
The following configuration accepts packets from IPv4 source
-    address 9.1.0.0/16 only. It emits 6to4 packets only
-    for IPv6 destination 2002:0901::/32 (IPv4 destination will match
-    9.1.0.0/16).

-

-
# ifconfig ne0 inet 9.1.2.3 netmask 0xffff0000
-# ifconfig stf0 create inet6 2002:0901:0203:0000:a00:5aff:fe38:6f86 \
-	prefixlen 32 alias

-

-
The following configuration uses the stf
-    interface as an output-only device. You need to have alternative IPv6
-    connectivity (other than 6to4) to use this configuration. For outbound
-    traffic, you can reach other 6to4 networks efficiently via
-    stf. For inbound traffic, you will not receive any
-    6to4-tunneled packets (less security drawbacks). Be careful not to advertise
-    your 6to4 prefix to others (2002:8504:0506::/48),
-    and not to use your 6to4 prefix as a source address.

-

-
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
-# ifconfig stf0 create inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
-	prefixlen 16 alias deprecated link0
-# route add -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

-

-

-

-

-
gif(4), inet(4),
-    inet6(4)

-

-
Brian Carpenter and
-    Keith Moore, Connection of IPv6
-    Domains via IPv4 Clouds, RFC,
-    3056, February
-    2001.

-
C. Huitema,
-    An Anycast Prefix for 6to4 Relay Routers,
-    RFC, 3068,
-    June 2001.

-
F. Baker and
-    P. Savola, Ingress Filtering for
-    Multihomed Networks, RFC,
-    3704, March
-  2004.

-
P. Savola and
-    C. Patel, Security Considerations
-    for 6to4, RFC,
-    3964, December
-    2004.

-
Jun-ichiro itojun
-    Hagino, Possible abuse against IPv6 transition
-    technologies,
-    draft-itojun-ipv6-transition-abuse-01.txt,
-    July 2000, expired, work in
-    progress.

-

-

-

-
The stf device first appeared in WIDE/KAME
-    IPv6 stack.

-

-

-

-
No more than one stf interface is allowed
-    for a node, and no more than one IPv6 interface address is allowed for an
-    stf interface. This is to avoid source address
-    selection conflicts between the IPv6 layer and the IPv4 layer, and to cope
-    with ingress filtering rules on the other side. This is a feature to make
-    stf work right for all occasions.

-

-

-
-  
-    
-    
-  
-
January 2, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/stge.4 4.html b/static/netbsd/man4/stge.4 4.html
deleted file mode 100644
index 4f41baa3..00000000
--- a/static/netbsd/man4/stge.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
STGE(4)Device Drivers ManualSTGE(4)

-

-

-

-
stge —
-    Sundance/Tamarack TC9021 Gigabit Ethernet driver

-

-

-

-
stge* at pci? dev ? function ?

-
Configuration of PHYs or Ten-bit interfaces may also be necessary.
-    See mii(4).

-

-

-

-
The stge device driver supports the
-    Sundance/Tamarack TC9021 Gigabit Ethernet chip.

-
The Sundance/Tamarack TC9021 is found on the D-Link DGE-550T, and
-    the Antares Microsystems Gigabit Ethernet board. It uses an external PHY or
-    an external 10-bit interface.

-
The TC9021 supports IPv4/TCP/UDP checksumming in hardware. The
-    stge driver supports this feature of the chip. See
-    ifconfig(8) for information on how to enable this
-  feature.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8)

-

-

-

-
The stge driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The stge driver was written by
-    Jason R. Thorpe
-  ⟨thorpej@NetBSD.org⟩.

-

-

-

-
The stge driver does not support the VLAN
-    tag insertion/removal feature of the TC9021 chip. This is primarily because
-    the TC9021's VLAN do not have a useful programming interface.

-
The stge driver does not yet support jumbo
-    Ethernet frames.

-
The stge driver does not yet function
-    properly with 1000BASE-T fitted boards. Currently, only 1000BASE-SX boards
-    work.

-

-

-
-  
-    
-    
-  
-
July 24, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/sti.4 4.html b/static/netbsd/man4/sti.4 4.html
deleted file mode 100644
index 9fff800f..00000000
--- a/static/netbsd/man4/sti.4 4.html	
+++ /dev/null
@@ -1,276 +0,0 @@
-
-  
-    
-    
-    
-  
-
STI(4)Device Drivers ManualSTI(4)

-

-

-

-
sti — HP Standard
-    Text Interface

-

-

-

-
sti*	at mainbus0
-  

-  sti*	at phantomas?
-  

-  sti*	at pci?
-  

-  wsdisplay*	at sti?

-

-

-

-
The sti was created by HP to provide
-    uniform frame-buffer access operations for their 9000/300 and 9000/700
-    series of workstations.

-
The following models are supported (though not all features or
-    frame buffer depths may be available):

-
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-  
-
ModelBitsMem3DMachines/Cards
EVRX80.5HP9000/362/382
EVRX80.75HP9000/382
EVRX82HP9000/425e
GRX8g2SGC
CRX82SGC
Tomcat82SGC
Stinger82HP9000/7[12]5/74[257]i
Artist82HP9000/712/7[12]5/74[38]i
CRX-242416SGC
HCRX-882GSC
HCRX-242416GSC
Visualize EG162HP B/C-class, GSC/PCI
Visualize FXE2424yPCI 32/66
Visualize FX22424yPCI 64/66
Visualize FX4/FX62432yPCI 64/66

-
Implementation consists of a set of functions burnt in to the PROM
-    on the card and providing the following set of functions (see below for PROM
-    revision history on functions supported by particular PROM revision):

-

-
    
-  
  • Initialize graphics.
    • 
-  
  • State management.
    • 
-  
  • Print a character onto the screen using currently selected font.
    • 
-  
  • Copy a region of the frame-buffer to another location.
    • 
-  
  • Self testing.
    • 
-  
  • Exception handling.
    • 
-  
  • Frame-buffer configuration enquiry.
    • 
-  
  • Setting colour-map entry.
    • 
-  
  • DMA parameters.
    • 
-  
  • Flow control.
    • 
-  
  • User timing.
    • 
-  
  • Processing management.
    • 
-  
  • Miscellaneous utility functions.
    • 
-

-
There are two modes for accessing the PROM: “byte”
-    and “word” mode. In “byte” mode each 4-byte word
-    contains only the low-ordered big-endian byte of data; i.e., to compose one
-    word of data 4 words should be read and low-ordered bytes of those should be
-    shifted correspondingly. In “word” mode each word contains all
-    4 bytes of valid data.

-
PROM revision history:

-

-  
8.02

-  
Original release.

-  
8.03

-  

-    
    
-      
  • OSF-extended self test (a.k.a fast).
    • 
-      
  • Restore display.
    • 
-    

-  

-  
8.04

-  

-    
    
-      
  • Implement curr_mon function.
    • 
-      
  • Graphical boot screen.
    • 
-      
  • Implement “block move”.
    • 
-      
  • Implement “set colour-map entry”.
-          sti Implement word mode.
    • 
-      
  • Support for multiple monitors.
    • 
-      
  • Support user_data sti
-          space usage.
    • 
-      
  • Support for extra memory.
    • 
-      
  • Support for Windows NT (tm).
    • 
-      
  • Monitor frequency reference.
    • 
-      
  • Early console.
    • 
-      
  • Support added for: PCXL, GSC bus, ROM-less
-          operation.
    • 
-    

-  

-  
8.05

-  

-    
    
-      
  • Interrupt support.
    • 
-      
  • Report card's power usage.
    • 
-      
  • Birds of Prey.
    • 
-      
  • User interrupts.
    • 
-    

-  

-  
8.06

-  

-    
    
-      
  • Multiple fonts.
    • 
-      
  • Monitor table descriptor strings.
    • 
-      
  • PCXL2 and PCXU monitor descriptors.
    • 
-    

-  

-  
8.08

-  

-    
    
-      
  • HP-UX 10 support for Visualize FX
    • 
-      
  • dma_ctrl function added.
    • 
-      
  • flow_ctrl function added.
    • 
-      
  • user_timing function added.
    • 
-    

-  

-  
8.09

-  

-    
    
-      
  • Addition changes for Visualize FX due to
-          rearchitecture for performance.
    • 
-      
  • process_mgr function added.
    • 
-    

-  

-  
8.0a

-  
PCXL2 and PCXU dual PCI EPROM map mode,
-      implemented on Visualize EG.

-  
8.0b

-  
Support for HP-UX non-implicit locking DMA, implemented on
-      Visualize FXE.

-  
8.0c

-  
sti_util function added (flashing under HP-UX and
-      other sideband traffic).

-  
8.0d

-  
Colour frame buffer support.

-

-

-

-

-
intro(4), phantomas(4),
-    wsdisplay(4)

-

-
Standard Text Interface For
-    Graphics Devices, Hewlett-Packard,
-    Revision 8.13, March 1,
-    2000.

-

-

-

-
The sti driver was written by
-    Michael Shalayeff
-    <mickey@openbsd.org>
-    for HPPA port for OpenBSD 2.7.

-

-

-

-
Currently, neither scroll back nor screen blanking functions are
-    implemented.

-

-

-
-  
-    
-    
-  
-
May 29, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/stpcide.4 4.html b/static/netbsd/man4/stpcide.4 4.html
deleted file mode 100644
index 2a3b0bbc..00000000
--- a/static/netbsd/man4/stpcide.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
STPCIDE(4)Device Drivers ManualSTPCIDE(4)

-

-

-

-
stpcide —
-    STMicroelectronics STPC IDE disk controllers
-  driver

-

-

-

-
stpcide* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The stpcide driver supports the
-    STMicroelectronics STPC x86 SoC internal IDE controllers, and provides the
-    interface with the hardware for the ata(4) driver. The
-    driver features DMA mode 2 and PIO mode 4 transfer speeds.

-
The 0x0002 flag forces the stpcide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The timings used for the DMA and PIO modes are for STPC Atlas and
-    its siblings with their PCI clock configured at 33 MHz. Other speeds
-    including the STPC Vega Ultra-IDE controller will need adjustments.

-

-

-
-  
-    
-    
-  
-
October 31, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/stuirda.4 4.html b/static/netbsd/man4/stuirda.4 4.html
deleted file mode 100644
index 496d9a06..00000000
--- a/static/netbsd/man4/stuirda.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
STUIRDA(4)Device Drivers ManualSTUIRDA(4)

-

-

-

-
stuirda —
-    Sigmaltel 4116/4220 USB-IrDA bridge support

-

-

-

-
stuirda* at uhub?
-  

-  irframe* at uirda?

-

-

-

-
The stuirda driver provides support for
-    SigmaTels USB-IrDA bridges that nearly follow the bridge specification:

-

-

-

-  
SigmaTel ST4116

-  
 

-  
SigmaTel ST4210

-  
 

-  
SigmaTel ST4220

-  
 

-

-

-
Access to the IrDA device is through the
-    irframe(4) driver. Before accessing it, a firmware patch
-    must be downloaded. At the time of writing this, it can be found at:
-    http://www.sigmatel.com/documents/stir4210_4220_4116_patch_files.tar.gz

-
Unpack the archive with

-
tar -C
-    /libdata/firmware/stuirda/
-    -xzf
-    stir4210_4220_4116_patch_files.tar.gz

-

-

-

-
irframe(4), usb(4)

-

-

-

-
The stuirda driver appeared in
-    NetBSD 5.0.

-

-

-

-
stuirda needs the firmware for
-    configuration, so it can't be loaded at kernel startup time. As a
-    workaround, you can plug in the USB-IrDA-bridge after booting.

-

-

-
-  
-    
-    
-  
-
October 13, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/sv.4 4.html b/static/netbsd/man4/sv.4 4.html
deleted file mode 100644
index 6c48b640..00000000
--- a/static/netbsd/man4/sv.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
SV(4)Device Drivers ManualSV(4)

-

-

-

-
sv — S3 SonicVibes
-    audio device driver

-

-

-

-
sv* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  opl* at sv?

-

-

-

-
The sv driver provides support sound cards
-    based on the S3 SonicVibes chip, e.g. the Turtle Beach Daytona card.

-

-

-

-
audio(4), opl(4),
-    pci(4)

-

-

-

-
The sv device driver appeared in
-    NetBSD 1.4.

-

-

-

-
The waveform synth and MIDI port are not supported.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/svwsata.4 4.html b/static/netbsd/man4/svwsata.4 4.html
deleted file mode 100644
index 82ca15bf..00000000
--- a/static/netbsd/man4/svwsata.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
SVWSATA(4)Device Drivers ManualSVWSATA(4)

-

-

-

-
svwsata —
-    Serverworks Serial ATA disk controller driver

-

-

-

-
svwsata* at pci? dev ? function ? flags
-    0x0000

-

-

-

-
The svwsata driver supports the
-    Serverworks K2, Frodo4, Frodo8 and HT-1000 Serial ATA controllers, and
-    provides the interface with the hardware for the ata(4)
-    driver.

-
The 0x0002 flag forces the svwsata driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the SATA
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-
-  
-    
-    
-  
-
March 7, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/swsensor.4 4.html b/static/netbsd/man4/swsensor.4 4.html
deleted file mode 100644
index 1236c223..00000000
--- a/static/netbsd/man4/swsensor.4 4.html	
+++ /dev/null
@@ -1,137 +0,0 @@
-
-  
-    
-    
-    
-  
-
SWSENSOR(4)Device Drivers ManualSWSENSOR(4)

-

-

-

-
swsensor —
-    software environmental sensor

-

-

-

-
pseudo-device swsensor

-

-

-

-
The swsensor driver provides a software
-    environmental sensor that works with sysctl(8) and
-    envstat(8). The driver is intended to be loaded as a
-    kernel module. One can, however, include the
-    swsensor driver directly in a kernel using the
-    configuration from the synopsis. By default, the sensor is of type
-    ENVSYS_UNITS_INTEGER.

-
The following values can be specified in the
-    modload(8) command when loading the
-    swsensor module to alter the driver's behavior.

-

-  

-    

-  
 

-  

-  
Controls whether or not swsensor provides
-      internally-maintained limits and limit checking
-    

-      

-        

-      
 

-      

-      
sensor has no internally-maintained limits

-      

-      
sensor provides its own internal limit value

-      

-      
sensor maintains an internal adjustable limit and performs its own
-          comparison between the sensor's limit and its current value

-    

-  

-  

-  
The initial alarm limit value, if limit emulation is selected (i.e., if
-      mode is set to 1 or 2)

-  

-  
 

-  

-  
The maximum and minimum values. The corresponding
-      ENVSYS_FVALID_MAX and
-      ENVSYS_FVALID_MIN flags are implicitly set.

-  

-  
This boolean value controls the setting of the
-      ENVSYS_FPERCENT flag.

-  

-  
Define the sensor's unit/type. By default, a Temperature sensor is
-      created. Any of the string values from the following table can be
-      specified:
-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
TemperatureFanVoltage AC
Voltage DCOhmsWatts
AmpereWatt hourAmpere hour
IndicatorIntegerDrive
Battery capacityBattery charge

-    (Values are case-sensitive, and spaces must be included.)

-  

-  
Provide an initial value for the sensor. If this is omitted, the sensor's
-      initial value is set to zero.

-

-
For example,

-
modload -s
-  type=Voltage\ DC swsensor

-will create a sensor of type ENVSYS_UNITS_SVOLTS_DC,
-  while
-
modload -i mode=1 -i
-  limit=50 swsensor

-will create a sensor which has an initial, device-provided limit of 50.
-
The sensor's raw value and state can be manually updated by
-    modifying the sysctl(8) variables
-    “hw.swsensor.cur_value” and “hw.swsensor.state”
-    variables respectively.

-

-

-

-
modctl(2), envstat(8),
-    sysctl(8)

-

-

-

-
The swsensor driver was written by
-    Paul Goyette and first appeared in
-    NetBSD 6.0.

-

-

-

-
The swsensor driver emulates a device with
-    only a single sensor.

-
The swsensor driver can only emulate one
-    hardware-managed limit; this is assumed to be the
-    critical-min limit.

-

-

-
-  
-    
-    
-  
-
June 1, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/swwdog.4 4.html b/static/netbsd/man4/swwdog.4 4.html
deleted file mode 100644
index abf35973..00000000
--- a/static/netbsd/man4/swwdog.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
SWWDOG(4)Device Drivers ManualSWWDOG(4)

-

-

-

-
swwdog — software
-    watchdog timer

-

-

-

-
pseudo-device swwdog

-

-

-

-
The swwdog driver provides a software
-    watchdog timer that works with wdogctl(8). If the timer
-    expires, the system reboots if the boolean variable
-    swwdog_reboot is true;
-    otherwise, the system will panic. swwdog_reboot is
-    accessible as the sysctl(8) variable hw.swwdog.reboot and
-    defaults to false.

-
The default period of swwdog is 60
-    seconds.

-
As with other watchdog timers, the swwdog
-    driver prevents a system from suspending when the watchdog is armed.

-

-

-

-
sysctl(8), wdogctl(8)

-

-

-

-
The swwdog driver was written by
-    Steven M. Bellovin.

-

-

-

-
Only one watchdog timer can be active at any given time.
-    (Arguably, this is a bug in the watchdog timer framework.) Therefore, only a
-    single instance of the swwdog device can be
-  created.

-
Kernel tickle mode is useless with swwdog
-    and arguably should be rejected, since both it and this driver rely on the
-    same callout mechanism; if one is blocked, almost certainly the other is as
-    well.

-
The alarm option to wdogctl(8) isn't
-    implemented.

-

-

-
-  
-    
-    
-  
-
June 8, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/sysmon.4 4.html b/static/netbsd/man4/sysmon.4 4.html
deleted file mode 100644
index c9e45e2e..00000000
--- a/static/netbsd/man4/sysmon.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
SYSMON(4)Device Drivers ManualSYSMON(4)

-

-

-

-
sysmon — system
-    monitoring and power management interface

-

-

-

-
The machine-independent sysmon is a
-    general purpose framework for system monitoring and power management. The
-    main components of sysmon include:

-
    
-  
  • An ioctl(2) interface available via
-      /dev/sysmon. The userland counterparts include
-      utilities such as envstat(8) and daemons such as
-      powerd(8).
    • 
-  
  • An interface for the purpose of delivering different system and power
-      events to userspace; sysmon_pswitch(9).
    • 
-  
  • A general purpose sensor framework,
-    sysmon_envsys(9).
    • 
-  
  • A general purpose task queue, sysmon_taskq(9).
    • 
-  
  • An interface for watchdog timers.
    • 
-

-

-

-

-

-
/dev/sysmon

-

-

-

-

-
envsys(4), swsensor(4),
-    envstat(8), powerd(8),
-    wdogctl(8), pmf(9)

-

-

-

-
Jason R. Thorpe
-    <thorpej@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
June 22, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/tap.4 3.html b/static/netbsd/man4/tap.4 3.html
deleted file mode 100644
index 544b5ee3..00000000
--- a/static/netbsd/man4/tap.4 3.html	
+++ /dev/null
@@ -1,138 +0,0 @@
-
-  
-    
-    
-    
-  
-
TAP(4)Device Drivers ManualTAP(4)

-

-

-

-
tap — Ethernet
-    tunnel software network interface

-

-

-

-
pseudo-device tap

-

-

-

-
The tap driver allows the creation and use
-    of virtual Ethernet devices. Those interfaces appear just as any real
-    Ethernet NIC to the kernel, but can also be accessed by userland through a
-    character device node in order to read frames being sent by the system or to
-    inject frames. In that respect it is very similar to what
-    tun(4) provides.

-

-

-
Interfaces may be created in two different ways: using the
-    ifconfig(8) create command with a
-    specified device number, or its ioctl(2) equivalent,
-    SIOCIFCREATE, or using the special cloning device
-    /dev/tap.

-
The former works the same as any other cloning network interface:
-    the administrator can create and destroy interfaces at any time, notably at
-    boot time. This is the easiest way of combining tap
-    and bridge(4). Later, userland will actually access the
-    interfaces through the specific device nodes
-    /dev/tapN.

-
The latter is aimed at applications that need a virtual Ethernet
-    device for the duration of their execution. A new interface is created at
-    the opening of /dev/tap, and is later destroyed when
-    the last process using the file descriptor closes it.

-

-

-

-
Whether the tap devices are accessed
-    through the special cloning device /dev/tap or
-    through the specific devices /dev/tapN, the possible
-    actions to control the matching interface are the same.

-
When using /dev/tap though, as the
-    interface is created on-the-fly, its name is not known immediately by the
-    application. Therefore the TAPGIFNAME ioctl is
-    provided. It should be the first action an application using the special
-    cloning device will do. It takes a pointer to a struct
-    ifreq as an argument.

-
Ethernet frames sent out by the kernel on a
-    tap interface can be obtained by the controlling
-    application with read(2). It can also inject frames in the
-    kernel with write(2). There is absolutely no validation of
-    the content of the injected frame, it can be any data, of any length.

-
One call of write(2) will inject a single frame
-    in the kernel, as one call of read(2) will retrieve a
-    single frame from the queue, to the extent of the provided buffer. If the
-    buffer is not large enough, the frame will be truncated.

-
tap character devices support the
-    FIONREAD ioctl which returns the size of the next
-    available frame, or 0 if there is no available frame in the queue.

-
They also support non-blocking I/O through the
-    FIONBIO ioctl. In that mode,
-    EWOULDBLOCK is returned by read(2)
-    when no data is available.

-
Asynchronous I/O is supported through the
-    FIOASYNC, FIOSETOWN, and
-    FIOGETOWN ioctls. The first will enable
-    SIGIO generation, while the two other configure the
-    process group that will receive the signal when data is ready.

-
Synchronisation may also be achieved through the use of
-    select(2), poll(2), or
-    kevent(2).

-

-

-

-
When a tap device is created, it is
-    assigned an Ethernet address of the form f2:0b:a4:xx:xx:xx. This address can
-    later be changed using ifconfig(8) to add an active link
-    layer address, or directly via the SIOCALIFADDR
-    ioctl on a PF_LINK socket, as it is not available on
-    the ioctl handler of the character device interface.

-

-

-
-
When an application has opened the tap
-    character device the link is considered up, otherwise down. As such, it is
-    best to open the character device once connectivity has been established so
-    that Duplicate Address Detection, if applicable, can be performed. If
-    connectivity is lost, the character device should be closed.

-

-

-

-

-

-  
/dev/tap

-  
cloning device

-  
/dev/tap[0-9]*

-  
individual character device nodes

-

-

-

-

-
bridge(4), l2tp(4),
-    tun(4), vether(4),
-    ifconfig(8)

-

-

-

-
The tap driver first appeared in
-    NetBSD 3.0.

-

-

-

-
Starting from NetBSD 10.0, the
-    tap driver can no longer be used as a
-    bridge(4) endpoint because it supports a link state based
-    on if it has been opened or not. Use the vether(4) driver
-    instead as it's been explicitly designed for this purpose.

-

-

-
-  
-    
-    
-  
-
May 2, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/tc.4 4.html b/static/netbsd/man4/tc.4 4.html
deleted file mode 100644
index cfee3af6..00000000
--- a/static/netbsd/man4/tc.4 4.html	
+++ /dev/null
@@ -1,116 +0,0 @@
-
-  
-    
-    
-    
-  
-
TC(4)Device Drivers ManualTC(4)

-

-

-

-
tc — TURBOchannel
-    expansion bus driver

-

-

-

-

-

-
tc* at tcasic?

-

-

-

-
tc* at mainbus0

-

-

-

-
tc0 at vsbus0

-

-

-

-

-
The tc driver provides machine-independent
-    support for the DEC TURBOchannel expansion bus found on all DEC 5000-series
-    machines with MIPS, DEC 3000-series with Alpha processors and VAXstation
-    4000 machines with the optional TURBOchannel adaptor.

-
Your system may support additional TURBOchannel devices. Drivers
-    for TURBOchannel devices not listed here are machine-dependent. Consult your
-    system's intro(4) for additional information.

-

-

-

-
NetBSD includes machine-independent
-    TURBOchannel drivers, sorted by device type and driver name:

-

-

-

-

-  
tcds(4)

-  
PMAZ-DS, PMAZ-FS, PMAZB-AA and PMAZC-AA dual-channel SCSI adapters

-

-

-

-

-

-

-

-  
le(4)

-  
LANCE Ethernet interface

-

-

-

-

-

-

-

-  
cfb(4)

-  
PMAG-B CX colour unaccelerated 2-D framebuffer

-  
mfb(4)

-  
PMAG-A MX monochrome framebuffer

-  
px(4)

-  
PMAG-C PX accelerated graphics boards

-  
pxg(4)

-  
PMAG-D, PMAG-E and PMAG-F PXG accelerated graphics boards

-  
sfb(4)

-  
PMAGB-BA HX colour unaccelerated 2-D framebuffer

-  
tfb(4)

-  
PMAG-J TX 24-bit colour unaccelerated 2-D framebuffer

-

-

-

-

-

-

-

-  
ioasic(4)

-  
baseboard IO control ASIC for DEC TURBOchannel systems

-  
tcu(4)

-  
TC-USB USB host and GPIO option

-

-

-

-

-

-

-
intro(4), tc(9)

-

-

-

-
The tc driver first appeared in
-    NetBSD 1.1.

-

-

-

-
The tc driver makes poor use of interrupt
-    priority on the 5000/1xx series systems.

-

-

-
-  
-    
-    
-  
-
February 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/tcds.4 4.html b/static/netbsd/man4/tcds.4 4.html
deleted file mode 100644
index 75d062c5..00000000
--- a/static/netbsd/man4/tcds.4 4.html	
+++ /dev/null
@@ -1,39 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCDS(4)Device Drivers ManualTCDS(4)

-

-

-

-
tcds —
-    TURBOchannel dual-channel SCSI adapters

-

-

-

-
tcds* at tc? slot ? offset ?

-

-

-

-
The tcds driver provides support for the
-    DEC TURBOchannel PMAZ-DS, PMAZ-FS, PMAZB-AA and PMAZC-AA dual-channel SCSI
-    adapters. Each channel is driven by the asc(4) driver. The
-    PMAZ-FS (Alpha onboard only) and PMAZC-AA (option board) provide two Fast
-    Narrow SCSI busses, while the PMAX-DS (Alpha onboard only) and PMAZB-AA only
-    provide Narrow SCSI. For the onboard Alpha controllers, one bus is for
-    internal devices and one bus for external devices.

-

-

-

-
asc(4)

-

-

-
-  
-    
-    
-  
-
February 6, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/tcic.4 4.html b/static/netbsd/man4/tcic.4 4.html
deleted file mode 100644
index de6fb37f..00000000
--- a/static/netbsd/man4/tcic.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCIC(4)Device Drivers ManualTCIC(4)

-

-

-

-
tcic — Databook
-    PCMCIA controller driver

-

-

-

-
tcic0 at isa? port 0x240 iomem 0xd0000 iosiz
-    0x4000
-  

-  pcmcia* at tcic? controller ? socket ?

-

-

-

-
NetBSD provides support for the Databook
-    DB86082, DB86084, DB86184, and DB86072 PCMCIA controllers.

-

-

-

-
isa(4), pcic(4),
-    pcmcia(4)

-

-

-

-
The tcic driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
May 21, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/tcom.4 4.html b/static/netbsd/man4/tcom.4 4.html
deleted file mode 100644
index 28a43319..00000000
--- a/static/netbsd/man4/tcom.4 4.html	
+++ /dev/null
@@ -1,90 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCOM(4)Device Drivers ManualTCOM(4)

-

-

-

-
tcom —
-    multiplexing serial communications interface

-

-

-

-
For 4-port TC-400 series boards:

-

-  

-  tcom0 at isa? port 0x100 irq 5
-  

-  com2 at tcom? slave ?
-  

-  com3 at tcom? slave ?
-  

-  com4 at tcom? slave ?
-  

-  com5 at tcom? slave ?

-
For 8-port TC-800 series boards:

-

-  

-  tcom0 at isa? port 0x100 irq 5
-  

-  com2 at tcom? slave ?
-  

-  com3 at tcom? slave ?
-  

-  com4 at tcom? slave ?
-  

-  com5 at tcom? slave ?
-  

-  com6 at tcom? slave ?
-  

-  com7 at tcom? slave ?
-  

-  com8 at tcom? slave ?
-  

-  com9 at tcom? slave ?

-

-

-

-
The tcom driver provides support for the
-    Byte Runner Technologies TC-400 and TC-800 series boards that multiplex
-    together up to four or eight EIA RS-232C (CCITT V.28) communications
-    interfaces.

-
Each tcom device is the master device for
-    up to eight com devices. The kernel configuration
-    specifies these com devices as slave devices of the
-    tcom device, as shown in the synopsis. The slave ID
-    given for each com device determines which bit in
-    the interrupt multiplexing register is tested to find interrupts for that
-    device. The port specification for the tcom device
-    is used to compute the base addresses for the com
-    subdevices and the port for the interrupt multiplexing register.

-
Not all possible configuration options are currently supported
-    (for example, speeds beyond 115200 baud are not currently supported).

-

-

-

-

-  
/dev/tty??

-  
 

-

-

-

-

-
com(4)

-

-

-

-
The tcom driver was written by Jukka
-    Marin.

-

-

-
-  
-    
-    
-  
-
May 20, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/tcp.4 3.html b/static/netbsd/man4/tcp.4 3.html
deleted file mode 100644
index 1de8958a..00000000
--- a/static/netbsd/man4/tcp.4 3.html	
+++ /dev/null
@@ -1,235 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCP(4)Device Drivers ManualTCP(4)

-

-

-

-
tcp — Internet
-    Transmission Control Protocol

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netinet/in.h>

-
int
-  

-  socket(AF_INET,
-    SOCK_STREAM,
-    0);

-
int
-  

-  socket(AF_INET6,
-    SOCK_STREAM,
-    0);

-

-

-

-
The TCP provides reliable, flow-controlled, two-way transmission
-    of data. It is a byte-stream protocol used to support the
-    SOCK_STREAM abstraction. TCP uses the standard
-    Internet address format and, in addition, provides a per-host collection of
-    “port addresses”. Thus, each address is composed of an
-    Internet address specifying the host and network, with a specific TCP port
-    on the host identifying the peer entity.

-
Sockets using TCP are either “active” or
-    “passive”. Active sockets initiate connections to passive
-    sockets. By default TCP sockets are created active; to create a passive
-    socket the listen(2) system call must be used after
-    binding the socket with the bind(2) system call. Only
-    passive sockets may use the accept(2) call to accept
-    incoming connections. Only active sockets may use the
-    connect(2) call to initiate connections.

-
Passive sockets may “underspecify” their location to
-    match incoming connection requests from multiple networks. This technique,
-    termed “wildcard addressing”, allows a single server to
-    provide service to clients on multiple networks. To create a socket which
-    listens on all networks, the Internet address
-    INADDR_ANY must be bound. The TCP port may still be
-    specified at this time; if the port is not specified the system will assign
-    one. Once a connection has been established the socket's address is fixed by
-    the peer entity's location. The address assigned the socket is the address
-    associated with the network interface through which packets are being
-    transmitted and received. Normally this address corresponds to the peer
-    entity's network.

-
TCP supports a number of socket options which can be set with
-    setsockopt(2) and tested with
-    getsockopt(2):

-

-  

-  
Under most circumstances, TCP sends data when it is presented; when
-      outstanding data has not yet been acknowledged, it gathers small amounts
-      of output to be sent in a single packet once an acknowledgment is
-      received. For a small number of clients, such as window systems that send
-      a stream of mouse events which receive no replies, this packetization may
-      cause significant delays. Therefore, TCP provides a boolean option,
-      TCP_NODELAY (from
-      <netinet/tcp.h>, to defeat
-      this algorithm.

-  

-  
By default, a sender- and receiver-TCP will negotiate among themselves to
-      determine the maximum segment size to be used for each connection. The
-      TCP_MAXSEG option allows the user to determine the
-      result of this negotiation, and to reduce it if desired.

-  

-  
This option enables the use of MD5 digests (also known as TCP-MD5) on
-      writes to the specified socket. In the current release, only outgoing
-      traffic is digested; digests on incoming traffic are not verified. The
-      current default behavior for the system is to respond to a system
-      advertising this option with TCP-MD5; this may change.
-    
One common use for this in a NetBSD
-        router deployment is to enable based routers to interwork with Cisco
-        equipment at peering points. Support for this feature conforms to RFC
-        2385. Only IPv4 (AF_INET) sessions are supported.

-    
In order for this option to function correctly, it is
-        necessary for the administrator to add a tcp-md5 key entry to the
-        system's security associations database (SADB) using the
-        setkey(8) utility. This entry must have an SPI of
-        0x1000 and can therefore only be specified on a per-host basis at this
-        time.

-    
If an SADB entry cannot be found
-        for the destination, the outgoing traffic will have an invalid digest
-        option prepended, and the following error message will be visible on the
-        system console:
-        .

-  

-  

-  
TCP probes a connection that has been idle for some amount of time. The
-      default value for this idle period is 4 hours. The
-      TCP_KEEPIDLE option can be used to affect this
-      value for a given socket, and specifies the number of seconds of idle time
-      between keepalive probes. This option takes an unsigned
-      int value, with a value greater than 0.

-  

-  
When the SO_KEEPALIVE option is enabled, TCP
-      probes a connection that has been idle for some amount of time. If the
-      remote system does not respond to a keepalive probe, TCP retransmits the
-      probe after some amount of time. The default value for this retransmit
-      interval is 150 seconds. The TCP_KEEPINTVL option
-      can be used to affect this value for a given socket, and specifies the
-      number of seconds to wait before retransmitting a keepalive probe. This
-      option takes an unsigned int value, with a value
-      greater than 0.

-  

-  
When the SO_KEEPALIVE option is enabled, TCP
-      probes a connection that has been idle for some amount of time. If the
-      remote system does not respond to a keepalive probe, TCP retransmits the
-      probe a certain number of times before a connection is considered to be
-      broken. The default value for this keepalive probe retransmit limit is 8.
-      The TCP_KEEPCNT option can be used to affect this
-      value for a given socket, and specifies the maximum number of keepalive
-      probes to be sent. This option takes an unsigned int
-      value, with a value greater than 0.

-  

-  
If a TCP connection cannot be established within some amount of time, TCP
-      will time out the connect attempt. The default value for this initial
-      connection establishment timeout is 150 seconds. The
-      TCP_KEEPINIT option can be used to affect this
-      initial timeout period for a given socket, and specifies the number of
-      seconds to wait before the connect attempt is timed out. For passive
-      connections, the TCP_KEEPINIT option value is
-      inherited from the listening socket. This option takes an
-      unsigned int value, with a value greater than
-    0.

-  

-  
Information about a socket's underlying TCP session may be retrieved by
-      passing the read-only option TPC_INFO to
-      getsockopt(2). It accepts a single argument: a pointer
-      to an instance of struct tcp_info.
-    
This API is subject to change; consult the source to determine
-        which fields are currently filled out by this option.
-        NetBSD specific additions include send window
-        size, receive window size, and bandwidth-controlled window space.

-  

-

-
The option level for the setsockopt(2) call is
-    the protocol number for TCP, available from
-    getprotobyname(3).

-
In the historical BSD TCP implementation,
-    if the TCP_NODELAY option was set on a passive
-    socket, the sockets returned by accept(2) erroneously did
-    not have the TCP_NODELAY option set; the behavior
-    was corrected to inherit TCP_NODELAY in
-    NetBSD 1.6.

-
Options at the IP network level may be used with TCP; see
-    ip(4) or ip6(4). Incoming connection
-    requests that are source-routed are noted, and the reverse source route is
-    used in responding.

-
There are many adjustable parameters that control various aspects
-    of the NetBSD TCP behavior; these parameters are
-    documented in sysctl(7), and they include:

-
    
-  
  • RFC 1323 extensions for high performance
    • 
-  
  • Send/receive buffer sizes
    • 
-  
  • Default maximum segment size (MSS)
    • 
-  
  • SYN cache parameters
    • 
-  
  • Hughes/Touch/Heidemann Congestion Window Monitoring algorithm
    • 
-  
  • Keepalive parameters
    • 
-  
  • newReno algorithm for congestion control
    • 
-  
  • Logging of connection refusals
    • 
-  
  • RST packet rate limits
    • 
-  
  • SACK (Selective Acknowledgment)
    • 
-  
  • ECN (Explicit Congestion Notification)
    • 
-  
  • Congestion window increase methods; the traditional packet counting or RFC
-      3465 Appropriate Byte Counting
    • 
-  
  • RFC 3390: Increased initial window size
    • 
-

-

-

-

-
A socket operation may fail with one of the following errors
-    returned:

-

-  
[EISCONN]

-  
when trying to establish a connection on a socket which already has
-    one;

-  
[ENOBUFS]

-  
when the system runs out of memory for an internal data structure;

-  
[ETIMEDOUT]

-  
when a connection was dropped due to excessive retransmissions;

-  
[ECONNRESET]

-  
when the remote peer forces the connection to be closed;

-  
[ECONNREFUSED]

-  
when the remote peer actively refuses connection establishment (usually
-      because no process is listening to the port);

-  
[EADDRINUSE]

-  
when an attempt is made to create a socket with a port which has already
-      been allocated;

-  
[EADDRNOTAVAIL]

-  
when an attempt is made to create a socket with a network address for
-      which no network interface exists.

-

-

-

-

-
getsockopt(2), socket(2),
-    inet(4), inet6(4),
-    intro(4), ip(4),
-    ip6(4), sysctl(7)

-
Transmission Control
-    Protocol, RFC, 793,
-    September 1981.

-
Requirements for Internet Hosts
-    -- Communication Layers, RFC,
-    1122, October
-  1989.

-

-

-

-
The tcp protocol stack appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
February 14, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/tcu.4 4.html b/static/netbsd/man4/tcu.4 4.html
deleted file mode 100644
index b01e1b66..00000000
--- a/static/netbsd/man4/tcu.4 4.html	
+++ /dev/null
@@ -1,46 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCU(4)Device Drivers ManualTCU(4)

-

-

-

-
tcu — TURBOchannel
-    USB host options

-

-

-

-
tcu* at tc? slot ? offset ?

-

-  

-  slhci* at tcu?
-  

-  usb* at slhci?

-

-  

-  gpio* at gpiobus?

-

-

-

-
The tcu driver provides support for the
-    flxd TC-USB TURBOchannel USB host options based upon a Cypress SL811HST USB
-    1.1 host controller and a glue logic CPLD. USB is handled by the
-    slhci(4) driver. Eight GPIO pins provided by the CPLD can
-    be accessed through the gpio(4) driver.

-

-

-

-
gpio(4), slhci(4),
-    tc(4), usb(4)

-

-

-
-  
-    
-    
-  
-
August 9, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/tdvfb.4 4.html b/static/netbsd/man4/tdvfb.4 4.html
deleted file mode 100644
index f6f5d291..00000000
--- a/static/netbsd/man4/tdvfb.4 4.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
TDVFB(4)Device Drivers ManualTDVFB(4)

-

-

-

-
tdvfb — 3Dfx
-    Voodoo Graphics / Voodoo 2 framebuffer driver

-

-

-

-
tdvfb* at pci?
-  

-  wsdisplay* at tdvfb?
-  

-  options TDVFB_CONSOLE

-

-

-

-
The tdvfb driver provides support for the
-    graphics cards based on 3Dfx Voodoo Graphics (SST-1) and 3Dfx Voodoo2 (CVG)
-    chipsets and provides an interface for the machine independent
-    wscons(4) driver.

-
Since both Voodoo Graphics and Voodoo2 were originally designed as
-    a 3D-only solutions, most boards do not have any kind of firmware. The
-    tdvfb driver is able to do low level initialization
-    (boot) of the board, which means that it can be used on all architectures
-    and is truly machine independent. However, it also means that driver cannot
-    detect automatically if the card is used as a console. The
-    TDVFB_CONSOLE option is provided and should be set
-    if the tdvfb driver is intended to be used as a
-    console.

-

-

-

-
genfb(4), voodoofb(4),
-    wsdisplay(4)

-
3Dfx Interactive, Inc.,
-    Voodoo2 Graphics Engine for 3D Game Acceleration,
-    Revision 1.16, December 1,
-    1999.

-

-

-

-
The tdvfb device first appeared in
-    NetBSD 7.0.

-

-

-

-
The tdvfb driver was written by
-    Radoslaw Kujawa. 3Dfx Glide 2.x source code, Linux
-    driver by Ghozlane Toumi were used as reference. The
-    wscons(4) attachment code is based mostly on the
-    genfb(4) driver by Michael
-  Lorenz.

-

-

-

-
3Dfx Voodoo2 has a simple 2D graphics engine. The
-    tdvfb driver has minimal support for this engine. It
-    is activated only when the card is running in a 16-bit mode (this is a
-    hardware limitation).

-
Video mode is hard-coded to 800x600 at 60Hz. Default bit depth for
-    little endian machines is 16-bit, for big endian machines it is 32-bit.
-    Resolution and depth should be selectable at least via kernel configuration
-    file. It is not possible to detect what resolutions are supported by the
-    monitor, since Voodoo Graphics and Voodoo2 have no DDC interface.

-
8-bit depth is not supported by the hardware. 16-bit depth is
-    supported by the hardware and is the preferred depth, however it does not
-    work correctly on big endian machines at the moment (this is a driver
-    problem).

-

-

-
-  
-    
-    
-  
-
August 3, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/tea5767radio.4 4.html b/static/netbsd/man4/tea5767radio.4 4.html
deleted file mode 100644
index 9628de80..00000000
--- a/static/netbsd/man4/tea5767radio.4 4.html	
+++ /dev/null
@@ -1,65 +0,0 @@
-
-  
-    
-    
-    
-  
-
TEA5767RADIO(4)Device Drivers ManualTEA5767RADIO(4)

-

-

-

-
tea5767 —
-    Philips/NXP TEA5767 FM Chip

-

-

-

-
tea5767radio* at iic? addr 0x60 flags 0x00
-  

-  radio* at tea5767radio?

-

-

-

-
The tea5767 driver provides support for
-    the Philips/NXP TEA5767 FM stereo radio.

-
The tea5767 can tune in the range 87.5 -
-    108.0 MHz, perform hardware signal search and supports mono/stereo
-  toggling.

-
The flags control the FM Band, XTAL, and PLL values as
-  follows:

-

-  
0x01

-  
Sets the FM Band to Japan.

-  
0x02

-  
Sets the PLL bit.

-  
0x04

-  
Sets the XTAL bit.

-  
0x08

-  
Force enables hardware search support.

-

-

-

-

-
iic(4), radio(4),
-    radio(9)

-
TEA5767,
-    Low-power FM stereo radio, Rev.
-    05, 26 January 2007.

-

-

-

-
Many popular TEA5767 evaluation boards feature low quality
-    32.768kHz crystals. The inaccuracy of these crystals may often lead to
-    malfunction of the hardware search function. Therefore, the
-    tea5767 driver tries to detect the crystal quality
-    during attachment. If the crystal of insufficient accuracy was detected, the
-    hardware search function is disabled. It can be forcefully re-enabled by
-    setting the 0x08 flag.

-

-

-
-  
-    
-    
-  
-
July 6, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/termios.4 4.html b/static/netbsd/man4/termios.4 4.html
deleted file mode 100644
index adca8dac..00000000
--- a/static/netbsd/man4/termios.4 4.html	
+++ /dev/null
@@ -1,1035 +0,0 @@
-
-  
-    
-    
-    
-  
-
TERMIOS(4)Device Drivers ManualTERMIOS(4)

-

-

-

-
termios — general
-    terminal line discipline

-

-

-

-
#include
-    <termios.h>

-

-

-

-
This describes a general terminal line discipline that is
-    supported on tty asynchronous communication ports.

-

-

-
When a terminal file is opened, it normally causes the process to
-    wait until a connection is established. For most hardware, the presence of a
-    connection is indicated by the assertion of the hardware
-     (CD) line. If the termios structure
-    associated with the terminal file has the CLOCAL
-    flag set in the cflag, or if the O_NONBLOCK flag is
-    set in the open(2) call, then the open will succeed even
-    without a connection being present.

-
In practice, applications seldom open these files; they are opened
-    by special programs, such as getty(8) or
-    rlogind(8), and become an application's standard input,
-    output, and error files.

-

-

-

-
Every process is associated with a particular process group and
-    session. The grouping is hierarchical: every member of a particular process
-    group is a member of the same session. This structuring is used in managing
-    groups of related processes for purposes of
-    ;
-    that is, the ability from the keyboard (or from program control) to
-    simultaneously stop or restart a complex command (a command composed of one
-    or more related processes).

-
The grouping into process groups allows delivering of signals that
-    stop or start the group as a whole, along with arbitrating which process
-    group has access to the single controlling terminal. The grouping at a
-    higher layer into sessions is to restrict the job control related signals
-    and system calls to within processes resulting from a particular instance of
-    a "login".

-
Typically, a session is created when a user logs in, and the login
-    terminal is set up to be the controlling terminal; all processes spawned
-    from that login shell are in the same session, and inherit the controlling
-    terminal. A job control shell operating interactively (that is, reading
-    commands from a terminal) normally groups related processes together by
-    placing them into the same process group. A set of processes in the same
-    process group is collectively referred to as a "job".

-
When the foreground process group of the terminal
-    is the same as the process group of a particular job, that job is said to be
-    in the
-    .
-    When the process group of the terminal is different than the process group
-    of a job (but is still the controlling terminal), that job is said to be in
-    the
-    .

-
Normally the shell reads a command and starts the job that
-    implements that command. If the command is to be started in the foreground
-    (typical), it sets the process group of the terminal to the process group of
-    the started job, waits for the job to complete, and then sets the process
-    group of the terminal back to its own process group (it puts itself into the
-    foreground).

-
If the job is to be started in the background (as denoted by the
-    shell operator "&"), it never changes the process group of the
-    terminal and doesn't wait for the job to complete (that is, it immediately
-    attempts to read the next command).

-
If the job is started in the foreground, the user may type a
-    character (usually ‘^Z’) which
-    generates the terminal stop signal (SIGTSTP) and has
-    the affect of stopping the entire job. The shell will notice that the job
-    stopped (see wait(2)), and will resume running after
-    placing itself in the foreground.

-
The shell also has commands for placing stopped jobs in the
-    background, and for placing stopped or background jobs into the
-  foreground.

-

-

-

-
An orphaned process group is a process group that has no process
-    whose parent is in a different process group, yet is in the same session.
-    Conceptually it means a process group that doesn't have a parent that could
-    do anything if it were to be stopped. For example, the initial login shell
-    is typically in an orphaned process group. Orphaned process groups are
-    immune to keyboard generated stop signals and job control signals resulting
-    from reads or writes to the controlling terminal.

-

-

-

-
A terminal may belong to a process as its controlling terminal.
-    Each process of a session that has a controlling terminal has the same
-    controlling terminal. A terminal may be the controlling terminal for at most
-    one session. The controlling terminal for a session is allocated by the
-    session leader by issuing the TIOCSCTTY ioctl. A
-    controlling terminal is never acquired by merely opening a terminal device
-    file. When a controlling terminal becomes associated with a session, its
-    foreground process group is set to the process group of the session
-  leader.

-
The controlling terminal is inherited by a child process during a
-    fork(2) function call. A process relinquishes its
-    controlling terminal when it creates a new session with the
-    setsid(2) function; other processes remaining in the old
-    session that had this terminal as their controlling terminal continue to
-    have it. A process does not relinquish its controlling terminal simply by
-    closing all of its file descriptors associated with the controlling terminal
-    if other processes continue to have it open.

-
When a controlling process terminates, the controlling terminal is
-    disassociated from the current session, allowing it to be acquired by a new
-    session leader. Subsequent access to the terminal by other processes in the
-    earlier session will be denied, with attempts to access the terminal treated
-    as if modem disconnect had been sensed.

-

-

-

-
If a process is in the foreground process group of its controlling
-    terminal, read operations are allowed. Any attempts by a process in a
-    background process group to read from its controlling terminal causes a
-    SIGTTIN signal to be sent to the process's group
-    unless one of the following special cases apply: If the reading process is
-    ignoring or blocking the SIGTTIN signal, or if the
-    process group of the reading process is orphaned, the
-    read(2) returns -1 with errno set to
-    EIO and no signal is sent. The default action of the
-    SIGTTIN signal is to stop the process to which it is
-    sent.

-
If a process is in the foreground process group of its controlling
-    terminal, write operations are allowed. Attempts by a process in a
-    background process group to write to its controlling terminal will cause the
-    process group to be sent a SIGTTOU signal unless one
-    of the following special cases apply: If TOSTOP is
-    not set, or if TOSTOP is set and the process is
-    ignoring or blocking the SIGTTOU signal, the process
-    is allowed to write to the terminal and the SIGTTOU
-    signal is not sent. If TOSTOP is set, and the
-    process group of the writing process is orphaned, and the writing process is
-    not ignoring or blocking SIGTTOU, the
-    write(2) returns -1 with errno set to
-    EIO and no signal is sent.

-
Certain calls that set terminal parameters are treated in the same
-    fashion as write, except that TOSTOP is ignored;
-    that is, the effect is identical to that of terminal writes when
-    TOSTOP is set.

-

-

-

-
A terminal device associated with a terminal device file may
-    operate in full-duplex mode, so that data may arrive even while output is
-    occurring. Each terminal device file has associated with it an input queue,
-    into which incoming data is stored by the system before being read by a
-    process. The system imposes a limit, {MAX_INPUT}, on
-    the number of bytes that may be stored in the input queue. The behavior of
-    the system when this limit is exceeded depends on the setting of the
-    IMAXBEL flag in the termios
-    c_iflag. If this flag is set, the terminal is sent an
-    ASCII BEL character each time a character is
-    received while the input queue is full. Otherwise, the input queue is
-    flushed upon receiving the character.

-
Two general kinds of input processing are available, determined by
-    whether the terminal device file is in canonical mode or noncanonical mode.
-    Additionally, input characters are processed according to the
-    c_iflag and c_lflag fields. Such
-    processing can include echoing, which in general means transmitting input
-    characters immediately back to the terminal when they are received from the
-    terminal. This is useful for terminals that can operate in full-duplex
-  mode.

-
The manner in which data is provided to a process reading from a
-    terminal device file is dependent on whether the terminal device file is in
-    canonical or noncanonical mode.

-
Another dependency is whether the
-    O_NONBLOCK flag is set by open(2)
-    or fcntl(2). If the O_NONBLOCK
-    flag is clear, then the read request is blocked until data is available or a
-    signal has been received. If the O_NONBLOCK flag is
-    set, then the read request is completed, without blocking, in one of three
-    ways:

-
    
-  
  1. If there is enough data available to satisfy the entire request, and the
-      read completes successfully the number of bytes read is returned.
    2. 
-  
  2. If there is not enough data available to satisfy the entire request, and
-      the read completes successfully, having read as much data as possible, the
-      number of bytes read is returned.
    3. 
-  
  3. If there is no data available, the read returns -1, with errno set to
-      EAGAIN.
    4. 
-

-
When data is available depends on whether the input processing
-    mode is canonical or noncanonical.

-

-

-

-
In canonical mode input processing, terminal input is processed in
-    units of lines. A line is delimited by a newline
-    ‘\n’ character, an end-of-file
-    (EOF) character, or an end-of-line
-    (EOL) character. See the
-    Special Characters section for
-    more information on EOF and
-    EOL. This means that a read request will not return
-    until an entire line has been typed, or a signal has been received. Also, no
-    matter how many bytes are requested in the read call, at most one line is
-    returned. It is not, however, necessary to read a whole line at once; any
-    number of bytes, even one, may be requested in a read without losing
-    information.

-
{MAX_CANON} is a limit on the number of
-    bytes in a line. The behavior of the system when this limit is exceeded is
-    the same as when the input queue limit {MAX_INPUT},
-    is exceeded.

-
Erase and kill processing occur when either of two special
-    characters, the ERASE and
-    KILL characters (see the
-    Special Characters section), is
-    received. This processing affects data in the input queue that has not yet
-    been delimited by a newline NL,
-    EOF, or EOL character. This
-    un-delimited data makes up the current line. The
-    ERASE character deletes the last character in the
-    current line, if there is any. The KILL character
-    deletes all data in the current line, if there is any. The
-    ERASE and KILL characters
-    have no effect if there is no data in the current line. The
-    ERASE and KILL characters
-    themselves are not placed in the input queue.

-

-

-

-
In noncanonical mode input processing, input bytes are not
-    assembled into lines, and erase and kill processing does not occur. The
-    values of the VMIN and VTIME
-    members of the c_cc array are used to determine how to
-    process the bytes received.

-
VMIN represents the minimum number of
-    bytes that should be received when the read(2) system call
-    successfully returns. VTIME is a timer of 0.1 second
-    granularity that is used to time out bursty and short term data
-    transmissions. If VMIN is greater than
-    {MAX_INPUT}, the response to the request is
-    undefined. The four possible values for VMIN and
-    VTIME and their interactions are described
-  below.

-

-

-

-
In this case VTIME serves as an inter-byte
-    timer and is activated after the first byte is received. Since it is an
-    inter-byte timer, it is reset after a byte is received. The interaction
-    between VMIN and VTIME is as
-    follows: as soon as one byte is received, the inter-byte timer is started.
-    If VMIN bytes are received before the inter-byte
-    timer expires (remember that the timer is reset upon receipt of each byte),
-    the read is satisfied. If the timer expires before
-    VMIN bytes are received, the characters received to
-    that point are returned to the user. Note that if
-    VTIME expires at least one byte is returned because
-    the timer would not have been enabled unless a byte was received. In this
-    case (VMIN > 0, VTIME
-    > 0) the read blocks until the VMIN and
-    VTIME mechanisms are activated by the receipt of the
-    first byte, or a signal is received. If data is in the buffer at the time of
-    the read(2), the result is as if data had been received
-    immediately after the read(2).

-

-

-

-
In this case, since the value of VTIME is
-    zero, the timer plays no role and only VMIN is
-    significant. A pending read is not satisfied until
-    VMIN bytes are received (i.e., the pending read
-    blocks until VMIN bytes are received), or a signal
-    is received. A program that uses this case to read record-based terminal
-    I/O may block indefinitely in the read
-  operation.

-

-

-

-
In this case, since VMIN = 0,
-    VTIME no longer represents an inter-byte timer. It
-    now serves as a read timer that is activated as soon as the read function is
-    processed. A read is satisfied as soon as a single byte is received or the
-    read timer expires. Note that in this case if the timer expires, no bytes
-    are returned. If the timer does not expire, the only way the read can be
-    satisfied is if a byte is received. In this case the read will not block
-    indefinitely waiting for a byte; if no byte is received within
-    VTIME*0.1 seconds after the read is initiated, the
-    read returns a value of zero, having read no data. If data is in the buffer
-    at the time of the read, the timer is started as if data had been received
-    immediately after the read.

-

-

-

-
The minimum of either the number of bytes requested or the number
-    of bytes currently available is returned without waiting for more bytes to
-    be input. If no characters are available, read returns a value of zero,
-    having read no data.

-

-

-

-
When a process writes one or more bytes to a terminal device file,
-    they are processed according to the c_oflag field (see
-    the Output Modes section). The
-    implementation may provide a buffering mechanism; as such, when a call to
-    write(2) completes, all of the bytes written have been
-    scheduled for transmission to the device, but the transmission will not
-    necessarily have been completed.

-

-

-

-
Certain characters have special functions on input or output or
-    both. These functions are summarized as follows:

-

-  

-  
Special character on input and is recognized if the
-      ISIG flag (see the
-      Local Modes section) is enabled.
-      Generates a SIGINT signal which is sent to all
-      processes in the foreground process group for which the terminal is the
-      controlling terminal. If ISIG is set, the
-      INTR character is discarded when processed.

-  

-  
Special character on input and is recognized if the
-      ISIG flag is enabled. Generates a
-      SIGQUIT signal which is sent to all processes in
-      the foreground process group for which the terminal is the controlling
-      terminal. If ISIG is set, the
-      QUIT character is discarded when processed.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. Erases the last character in
-      the current line; see
-      Canonical Mode Input
-      Processing. It does not erase beyond the start of a line, as delimited
-      by an NL, EOF, or
-      EOL character. If ICANON
-      is set, the ERASE character is discarded when
-      processed.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. Deletes the entire line, as
-      delimited by a NL, EOF, or
-      EOL character. If ICANON
-      is set, the KILL character is discarded when
-      processed.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. When received, all the bytes
-      waiting to be read are immediately passed to the process, without waiting
-      for a newline, and the EOF is discarded. Thus, if
-      there are no bytes waiting (that is, the EOF
-      occurred at the beginning of a line), a byte count of zero is returned
-      from the read(2), representing an end-of-file
-      indication. If ICANON is set, the
-      EOF character is discarded when processed.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. It is the line delimiter
-      ‘\n’.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. Is an additional line
-      delimiter, like NL.

-  

-  
If the ISIG flag is enabled, receipt of the
-      SUSP character causes a
-      SIGTSTP signal to be sent to all processes in the
-      foreground process group for which the terminal is the controlling
-      terminal, and the SUSP character is discarded when
-      processed.

-  

-  
Special character on both input and output and is recognized if the
-      IXON (output control) or
-      IXOFF (input control) flag is set. Can be used to
-      temporarily suspend output. It is useful with fast terminals to prevent
-      output from disappearing before it can be read. If
-      IXON is set, the STOP
-      character is discarded when processed.

-  

-  
Special character on both input and output and is recognized if the
-      IXON (output control) or
-      IXOFF (input control) flag is set. Can be used to
-      resume output that has been suspended by a STOP
-      character. If IXON is set, the
-      START character is discarded when processed.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set; it is the
-      ‘\r’, as denoted in the C Standard
-      {2}. When ICANON and ICRNL
-      are set and IGNCR is not set, this character is
-      translated into a NL, and has the same effect as a
-      NL character.

-

-
The following special characters are extensions defined by this
-    system and are not a part of IEEE Std 1003.1
-    (“POSIX.1”) termios.

-

-  

-  
Secondary EOL character. Same function as
-      EOL.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. Erases the last word in the
-      current line according to one of two algorithms. If the
-      ALTWERASE flag is not set, first any preceding
-      whitespace is erased, and then the maximal sequence of non-whitespace
-      characters. If ALTWERASE is set, first any
-      preceding whitespace is erased, and then the maximal sequence of
-      alphabetic/underscores or non alphabetic/underscores. As a special case in
-      this second algorithm, the first previous non-whitespace character is
-      skipped in determining whether the preceding word is a sequence of
-      alphabetic/underscores. This sounds confusing but turns out to be quite
-      practical.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. Causes the current input edit
-      line to be retyped.

-  

-  
Has similar actions to the SUSP character, except
-      that the SIGTSTP signal is delivered when one of
-      the processes in the foreground process group issues a
-      read(2) to the controlling terminal.

-  

-  
Special character on input and is recognized if the
-      IEXTEN flag is set. Receipt of this character
-      causes the next character to be taken literally.

-  

-  
Special character on input and is recognized if the
-      IEXTEN flag is set. Receipt of this character
-      toggles the flushing of terminal output.

-  

-  
Special character on input and is recognized if the
-      ICANON flag is set. Receipt of this character
-      causes a SIGINFO signal to be sent to the
-      foreground process group of the terminal. Also, if the
-      NOKERNINFO flag is not set, it causes the kernel
-      to write a status message to the terminal that displays the current load
-      average, the name of the command in the foreground, its process ID, the
-      symbolic wait channel, the number of user and system seconds used, the
-      percentage of CPU the process is getting, and the resident set size of the
-      process.

-

-
The NL and CR
-    characters cannot be changed. The values for all the remaining characters
-    can be set and are described later in the document under Special Control
-    Characters.

-
Special character functions associated with changeable special
-    control characters can be disabled individually by setting their value to
-    {_POSIX_VDISABLE}; see
-    Special Control
-    Characters.

-
If two or more special characters have the same value, the
-    function performed when that character is received is undefined.

-

-

-

-
If a modem disconnect is detected by the terminal interface for a
-    controlling terminal, and if CLOCAL is not set in
-    the c_cflag field for the terminal, the
-    SIGHUP signal is sent to the controlling process
-    associated with the terminal. Unless other arrangements have been made, this
-    causes the controlling process to terminate. Any subsequent call to the
-    read(2) function returns the value zero, indicating end of
-    file. Thus, processes that read a terminal file and test for end-of-file can
-    terminate appropriately after a disconnect. Any subsequent
-    write(2) to the terminal device returns -1, with
-    errno set to EIO, until the
-    device is closed.

-

-

-

-

-

-

-
The last process to close a terminal device file causes any output
-    to be sent to the device and any input to be discarded. Then, if
-    HUPCL is set in the control modes, and the
-    communications port supports a disconnect function, the terminal device
-    performs a disconnect.

-

-

-

-
Routines that need to control certain terminal I/O characteristics
-    do so by using the termios structure as defined in
-    the header <termios.h>. This
-    structure contains minimally four scalar elements of bit flags and one array
-    of special characters. The scalar flag elements are named:
-    c_iflag, c_oflag,
-    c_cflag, and c_lflag. The
-    character array is named c_cc, and its maximum index
-    is NCCS.

-

-

-

-
Values of the c_iflag field describe the
-    basic terminal input control, and are composed of following masks:

-

-

-

-  

-  
/* ignore BREAK condition */

-  

-  
/* map BREAK to SIGINT */

-  

-  
/* ignore (discard) parity errors */

-  

-  
/* mark parity and framing errors */

-  

-  
/* enable checking of parity errors */

-  

-  
/* strip 8th bit off chars */

-  

-  
/* map NL into CR */

-  

-  
/* ignore CR */

-  

-  
/* map CR to NL (ala CRMOD) */

-  

-  
/* enable output flow control */

-  

-  
/* enable input flow control */

-  

-  
/* any char will restart after stop */

-  

-  
/* ring bell on input queue full */

-

-

-
In the context of asynchronous serial data transmission, a break
-    condition is defined as a sequence of zero-valued bits that continues for
-    more than the time to send one byte. The entire sequence of zero-valued bits
-    is interpreted as a single break condition, even if it continues for a time
-    equivalent to more than one byte. In contexts other than asynchronous serial
-    data transmission the definition of a break condition is implementation
-    defined.

-
If IGNBRK is set, a break condition
-    detected on input is ignored, that is, not put on the input queue and
-    therefore not read by any process. If IGNBRK is not
-    set and BRKINT is set, the break condition flushes
-    the input and output queues and if the terminal is the controlling terminal
-    of a foreground process group, the break condition generates a single
-    SIGINT signal to that foreground process group. If
-    neither IGNBRK nor BRKINT is
-    set, a break condition is read as a single
-    ‘\0’, or if
-    PARMRK is set, as
-    ‘\377’,
-    ‘\0’,
-    ‘\0’.

-
If IGNPAR is set, a byte with a framing or
-    parity error (other than break) is ignored.

-
If PARMRK is set, and
-    IGNPAR is not set, a byte with a framing or parity
-    error (other than break) is given to the application as the three-character
-    sequence ‘\377’,
-    ‘\0’, X, where
-    ‘\377’,
-    ‘\0’ is a two-character flag preceding
-    each sequence and X is the data of the character received in error. To avoid
-    ambiguity in this case, if ISTRIP is not set, a
-    valid character of ‘\377’ is given to
-    the application as ‘\377’,
-    ‘\377’. If neither
-    PARMRK nor IGNPAR is set, a
-    framing or parity error (other than break) is given to the application as a
-    single character ‘\0’.

-
If INPCK is set, input parity checking is
-    enabled. If INPCK is not set, input parity checking
-    is disabled, allowing output parity generation without input parity errors.
-    Note that whether input parity checking is enabled or disabled is
-    independent of whether parity detection is enabled or disabled (see
-    Control Modes). If parity detection
-    is enabled but input parity checking is disabled, the hardware to which the
-    terminal is connected recognizes the parity bit, but the terminal special
-    file does not check whether this bit is set correctly or not.

-
If ISTRIP is set, valid input bytes are
-    first stripped to seven bits, otherwise all eight bits are processed.

-
If INLCR is set, a received
-    NL character is translated into a
-    CR character. If IGNCR is
-    set, a received CR character is ignored (not read).
-    If IGNCR is not set and
-    ICRNL is set, a received CR
-    character is translated into a NL character.

-
If IXON is set, start/stop output control
-    is enabled. A received STOP character suspends
-    output and a received START character restarts
-    output. If IXANY is also set, then any character may
-    restart output. When IXON is set,
-    START and STOP characters
-    are not read, but merely perform flow control functions. When
-    IXON is not set, the START
-    and STOP characters are read.

-
If IXOFF is set, start/stop input control
-    is enabled. The system shall transmit one or more
-    STOP characters, which are intended to cause the
-    terminal device to stop transmitting data, as needed to prevent the input
-    queue from overflowing and causing the undefined behavior described in
-    Input Processing and
-    Reading Data, and shall transmit one or more
-    START characters, which are intended to cause the
-    terminal device to resume transmitting data, as soon as the device can
-    continue transmitting data without risk of overflowing the input queue. The
-    precise conditions under which STOP and START
-    characters are transmitted are implementation defined.

-
If IMAXBEL is set and the input queue is
-    full, subsequent input shall cause an ASCII BEL
-    character to be transmitted to the output queue.

-
The initial input control value after open(2) is
-    implementation defined.

-

-

-

-
Values of the c_oflag field describe the
-    basic terminal output control, and are composed of the following masks:

-

-

-

-  

-  
/* enable following output processing */

-  

-  
/* map NL to CR-NL (ala CRMOD) */

-  

-  
/* map CR to NL */

-  

-  
/* expand tabs to spaces */

-  

-  
/* discard EOT's (^D) on output */

-  

-  
/* do not transmit CRs on column 0 */

-  

-  
/* on the terminal NL performs the CR function */

-

-

-
If OPOST is set, the remaining flag masks
-    are interpreted as follows; otherwise characters are transmitted without
-    change.

-
If ONLCR is set, newlines are translated
-    to carriage return, linefeeds.

-
If OCRNL is set, carriage returns are
-    translated to newlines.

-
If OXTABS is set, tabs are expanded to the
-    appropriate number of spaces (assuming 8 column tab stops).

-
If ONOEOT is set, ASCII
-    EOT's are discarded on output.

-
If ONOCR is set, no CR character is
-    transmitted when at column 0 (first position).

-
If ONLRET is set, the NL character is
-    assumed to do the carriage-return function; the column pointer will be set
-    to 0.

-

-

-

-
Values of the c_cflag field describe the
-    basic terminal hardware control, and are composed of the following masks.
-    Not all values specified are supported by all hardware.

-

-

-

-  

-  
/* character size mask */

-  

-  
/* 5 bits (pseudo) */

-  

-  
/* 6 bits */

-  

-  
/* 7 bits */

-  

-  
/* 8 bits */

-  

-  
/* send 2 stop bits */

-  

-  
/* enable receiver */

-  

-  
/* parity enable */

-  

-  
/* odd parity, else even */

-  

-  
/* hang up on last close */

-  

-  
/* ignore modem status lines */

-  

-  
/* CTS flow control of output */

-  

-  
/* logically the same as CCTS_OFLOW |
-      CCTS_IFLOW */

-  

-  
/* RTS flow control of input */

-  

-  
/* flow control output via Carrier */

-

-

-
The CSIZE bits specify the byte size in
-    bits for both transmission and reception. The c_cflag
-    is masked with CSIZE and compared with the values
-    CS5, CS6,
-    CS7, or CS8. This size does
-    not include the parity bit, if any. If CSTOPB is
-    set, two stop bits are used, otherwise one stop bit. For example, at 110
-    baud, two stop bits are normally used.

-
If CREAD is set, the receiver is enabled.
-    Otherwise, no character is received. Not all hardware supports this bit. In
-    fact, this flag is pretty silly and if it were not part of the
-    termios specification it would be omitted.

-
If PARENB is set, parity generation and
-    detection are enabled and a parity bit is added to each character. If parity
-    is enabled, PARODD specifies odd parity if set,
-    otherwise even parity is used.

-
If HUPCL is set, the modem control lines
-    for the port are lowered when the last process with the port open closes the
-    port or the process terminates. The modem connection is broken.

-
If CLOCAL is set, a connection does not
-    depend on the state of the modem status lines. If
-    CLOCAL is clear, the modem status lines are
-    monitored.

-
Under normal circumstances, a call to the
-    open(2) function waits for the modem connection to
-    complete. However, if the O_NONBLOCK flag is set or
-    if CLOCAL has been set, the
-    open(2) function returns immediately without waiting for
-    the connection.

-
If the tty(4)
-    TIOCFLAG_CLOCAL flag has been set on the port then
-    the CLOCAL flag will automatically be set on every
-    open.

-
The CCTS_OFLOW and
-    CRTS_IFLOW flags are currently unused. Only
-    CRTSCTS, which has the combined effect, is
-    implemented. Note that CRTSCTS support is hardware
-    and driver dependent. Check the specific port driver manual page to see if
-    hardware flow control is supported on the port you are using.

-
If the tty(4)
-    TIOCFLAG_CRTSCTS flag has been set on the port then
-    the CRTSCTS flag will automatically be set on every
-    open.

-
If MDMBUF is set then output flow control
-    is controlled by the state of Carrier Detect.

-
If the tty(4)
-    TIOCFLAG_MDMBUF flag has been set on the port then
-    the MDMBUF flag will automatically be set on every
-    open.

-
If the object for which the control modes are set is not an
-    asynchronous serial connection, some of the modes may be ignored; for
-    example, if an attempt is made to set the baud rate on a network connection
-    to a terminal on another host, the baud rate may or may not be set on the
-    connection between that terminal and the machine it is directly connected
-    to.

-

-

-

-
Values of the c_lflag field describe the
-    control of various functions, and are composed of the following masks.

-

-

-

-  

-  
/* visual erase for line kill */

-  

-  
/* visually erase chars */

-  

-  
/* enable echoing */

-  

-  
/* echo NL even if ECHO is
-      off */

-  

-  
/* visual erase mode for hardcopy */

-  

-  
/* echo control chars as ^(Char) */

-  

-  
/* enable signals INTR,
-      QUIT, [D]SUSP */

-  

-  
/* canonicalize input lines */

-  

-  
/* use alternative WERASE algorithm */

-  

-  
/* enable DISCARD and
-      LNEXT */

-  

-  
/* external processing */

-  

-  
/* stop background jobs from output */

-  

-  
/* output being flushed (state) */

-  

-  
/* no kernel output from VSTATUS */

-  

-  
/* re-echo input buffer at next read */

-  

-  
/* don't flush output on signal */

-

-

-
If ECHO is set, input characters are
-    echoed back to the terminal. If ECHO is not set,
-    input characters are not echoed.

-
If ECHOE and
-    ICANON are set, the ERASE
-    character causes the terminal to erase the last character in the current
-    line from the display, if possible. If there is no character to erase, an
-    implementation may echo an indication that this was the case or do
-  nothing.

-
If ECHOK and
-    ICANON are set, the KILL
-    character causes the current line to be discarded and the system echoes the
-    ‘\n’ character after the
-    KILL character.

-
If ECHOKE and
-    ICANON are set, the KILL
-    character causes the current line to be discarded and the system causes the
-    terminal to erase the line from the display.

-
If ECHOPRT and
-    ICANON are set, the system assumes that the display
-    is a printing device and prints a backslash and the erased characters when
-    processing ERASE characters, followed by a forward
-    slash.

-
If ECHOCTL is set, the system echoes
-    control characters in a visible fashion using a caret followed by the
-    control character.

-
If ALTWERASE is set, the system uses an
-    alternative algorithm for determining what constitutes a word when
-    processing WERASE characters (see
-    WERASE).

-
If ECHONL and
-    ICANON are set, the
-    ‘\n’ character echoes even if
-    ECHO is not set.

-
If ICANON is set, canonical processing is
-    enabled. This enables the erase and kill edit functions, and the assembly of
-    input characters into lines delimited by NL,
-    EOF, and EOL, as described
-    in Canonical Mode
-    Input Processing.

-
If ICANON is not set, read requests are
-    satisfied directly from the input queue. A read is not satisfied until at
-    least VMIN bytes have been received or the timeout
-    value VTIME expired between bytes. The time value
-    represents tenths of seconds. See
-    Noncanonical Mode
-    Input Processing for more details.

-
If ISIG is set, each input character is
-    checked against the special control characters INTR,
-    QUIT, and SUSP (job control
-    only). If an input character matches one of these control characters, the
-    function associated with that character is performed. If
-    ISIG is not set, no checking is done. Thus these
-    special input functions are possible only if ISIG is
-    set.

-
If IEXTEN is set, implementation-defined
-    functions are recognized from the input data. How
-    IEXTEN being set interacts with
-    ICANON, ISIG,
-    IXON, or IXOFF is
-    implementation defined. If IEXTEN is not set, then
-    implementation-defined functions are not recognized, and the corresponding
-    input characters are not processed as described for
-    ICANON, ISIG,
-    IXON, and IXOFF.

-
If NOFLSH is set, the normal flush of the
-    input and output queues associated with the INTR,
-    QUIT, and SUSP characters
-    are not be done.

-
If TOSTOP is set, the signal
-    SIGTTOU is sent to the process group of a process
-    that tries to write to its controlling terminal if it is not in the
-    foreground process group for that terminal. This signal, by default, stops
-    the members of the process group. Otherwise, the output generated by that
-    process is output to the current output stream. Processes that are blocking
-    or ignoring SIGTTOU signals are excepted and allowed
-    to produce output and the SIGTTOU signal is not
-    sent.

-
If NOKERNINFO is set, the kernel does not
-    produce a status message when processing STATUS
-    characters (see STATUS).

-

-

-

-
The special control characters values are defined by the array
-    c_cc. This table lists the array index, the
-    corresponding special character, and the system default value. For an
-    accurate list of the system defaults, consult the header file
-    <ttydefaults.h>.

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
Special CharacterDefault Value
EOF^D
EOL_POSIX_VDISABLE
EOL2_POSIX_VDISABLE
ERASE^? ‘\177’
WERASE^W
KILL^U
REPRINT^R
INTR^C
QUIT^\\ ‘\34’
SUSP^Z
DSUSP^Y
START^Q
STOP^S
LNEXT^V
DISCARD^O
---1
---0
STATUS^T

-
If the value of one of the changeable special control characters
-    (see Special Characters) is
-    {_POSIX_VDISABLE}, that function is disabled; that
-    is, no input data is recognized as the disabled special character. If
-    ICANON is not set, the value of
-    {_POSIX_VDISABLE} has no special meaning for the
-    VMIN and VTIME entries of
-    the c_cc array.

-
The initial values of the flags and control characters after
-    open(2) is set according to the values in the header
-    <sys/ttydefaults.h>.

-

-

-

-

-
tcsendbreak(3),
-  tcsetattr(3)

-

-

-
-  
-    
-    
-  
-
October 7, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/tfb.4 4.html b/static/netbsd/man4/tfb.4 4.html
deleted file mode 100644
index e84dd9fd..00000000
--- a/static/netbsd/man4/tfb.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
TFB(4)Device Drivers ManualTFB(4)

-

-

-

-
tfb — PMAG-J and
-    PMAGB-J TX colour unaccelerated 2-D framebuffer

-

-

-

-
tfb* at tc? slot ? offset ?
-  

-  wsdisplay* at tfb?

-

-

-

-
The tfb driver provides support for the
-    PMAG-J and PMAGB-J TX colour framebuffer for the TURBOchannel bus. The
-    PMAG-J is an 8 bpp or 24 bpp colour framebuffer capable of running at a
-    resolution of 1280-by-1024 at 66 Hz. The PMAGB-J is an 8 bpp or 24 bpp
-    colour framebuffer capable of running at a resolution of 1280-by-1024 at 72
-    Hz.

-

-

-

-
cfb(4), mfb(4),
-    px(4), pxg(4), sfb(4),
-    tc(4), wscons(4)

-

-

-
-  
-    
-    
-  
-
August 22, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/thinkpad.4 4.html b/static/netbsd/man4/thinkpad.4 4.html
deleted file mode 100644
index c4c5e4cd..00000000
--- a/static/netbsd/man4/thinkpad.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
THINKPAD(4)Device Drivers ManualTHINKPAD(4)

-

-

-

-
thinkpad —
-    IBM/Lenovo Thinkpad laptop features support

-

-

-

-
thinkpad* at acpi?

-

-

-

-
The thinkpad driver provides support for
-    vendor specific features found in IBM and Lenovo brand laptops, such as
-    function key handling, hotkey handling, battery controls, and temperature
-    and fan monitoring.

-

-

-

-
acpi(4), aps(4),
-    pmf(9), sysmon_envsys(9)

-

-

-

-
The thinkpad device driver appeared in
-    NetBSD 5.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-
-  
-    
-    
-  
-
April 27, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/ti.4 4.html b/static/netbsd/man4/ti.4 4.html
deleted file mode 100644
index 6c4ae51a..00000000
--- a/static/netbsd/man4/ti.4 4.html	
+++ /dev/null
@@ -1,151 +0,0 @@
-
-  
-    
-    
-    
-  
-
TI(4)Device Drivers ManualTI(4)

-

-

-

-
ti — Alteon
-    Networks Tigon I and Tigon II Gigabit Ethernet driver

-

-

-

-
ti* at pci? dev ? function ?

-

-

-

-
The ti driver provides support for PCI
-    Gigabit Ethernet adapters based on the Alteon Networks Tigon Gigabit
-    Ethernet controller chip. The Tigon contains an embedded R4000 CPU, Gigabit
-    MAC, dual DMA channels and a PCI interface unit. The Tigon II contains two
-    R4000 CPUs and other refinements. Either chip can be used in either a 32-bit
-    or 64-bit PCI slot. Communication with the chip is achieved via PCI shared
-    memory and bus master DMA. The Tigon I and II support hardware multicast
-    address filtering, VLAN tag extraction and insertion, and jumbo Ethernet
-    frames sizes up to 9000 bytes. Note that the Tigon I chipset is no longer in
-    active production: all new adapters should come equipped with Tigon II
-    chipsets.

-
There are several PCI boards available from both Alteon and other
-    vendors that use the Tigon chipset under OEM contract. The
-    ti driver has been tested with the following
-    Tigon-based adapters:

-
    
-  
  • The Alteon AceNIC V Gigabit (1000BASE-SX and 1000BASE-T variants) Ethernet
-      adapter
    • 
-  
  • The 3Com 3c985-SX Gigabit Ethernet adapter
    • 
-  
  • The Netgear GA620 Gigabit (1000BASE-SX and 1000BASE-T variants) Ethernet
-      adapter
    • 
-  
  • The Digital EtherWORKS 1000SX PCI Gigabit Adapter (DEGPA)
    • 
-

-
The following should also be supported but have not yet been
-    tested:

-
    
-  
  • Silicon Graphics PCI Gigabit Ethernet adapter
    • 
-

-
While the Tigon chipset supports 10, 100 and 1000Mbps speeds,
-    support for 10 and 100Mbps speeds is only available on boards with the
-    proper transceivers. Most adapters are only designed to work at 1000Mbps,
-    however the driver should support those NICs that work at lower speeds as
-    well.

-
Support for jumbo frames is provided via the interface MTU
-    setting. Selecting an MTU larger than 1500 bytes with the
-    ifconfig(8) utility configures the adapter to receive and
-    transmit jumbo frames. Using jumbo frames can greatly improve performance
-    for certain tasks, such as file transfers and data streaming.

-
The ti driver supports the following media
-    types:

-

-  
autoselect

-  
Enable autoselection of the media type and options.

-  
10baseT/UTP

-  
Set 10Mbps operation. The mediaopt option can also
-      be used to select either full-duplex or
-      half-duplex modes.

-  
100baseTX

-  
Set 100Mbps (fast Ethernet) operation. The mediaopt
-      option can also be used to select either full-duplex
-      or half-duplex modes.

-  
1000baseSX

-  
Set 1000Mbps (Gigabit Ethernet over multimode fiber) operation. Only full
-      full-duplex mode is supported at this speed.

-  
1000baseT

-  
Set 1000Mbps (Gigabit Ethernet over twisted pair) operation. Only full
-      full-duplex mode is supported at this speed.

-

-
The ti driver supports the following media
-    options:

-

-  
full-duplex

-  
Force full duplex operation.

-  
half-duplex

-  
Force half duplex operation.

-

-
The Alteon Tigon and Tigon II support IPv4/TCP/UDP checksumming in
-    hardware. The ti supports this feature of the chip's
-    firmware. See ifconfig(8) for information on how to enable
-    this feature.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-

-  
ti%d: can't map memory space

-  
A fatal initialization error has occurred.

-  
ti%d: couldn't map / establish interrupt

-  
A fatal initialization error has occurred.

-  
ti%d: jumbo buffer allocation failed

-  
The driver failed to allocate memory for jumbo frames during
-      initialization.

-  
ti%d: bios thinks we're in a 64 bit slot, but we aren't

-  
The BIOS has programmed the NIC as though it had been installed in a
-      64-bit PCI slot, but in fact the NIC is in a 32-bit slot. This happens as
-      a result of a bug in some BIOSes. This can be worked around on the Tigon
-      II, but on the Tigon I initialization will fail.

-  
ti%d: board self-diagnostics failed!

-  
The ROMFAIL bit in the CPU state register was set after system startup,
-      indicating that the on-board NIC diagnostics failed.

-  
ti%d: unknown hwrev

-  
The driver detected a board with an unsupported hardware revision. The
-      ti driver supports revision 4 (Tigon 1) and
-      revision 6 (Tigon 2) chips and has firmware only for those devices.

-  
ti%d: watchdog timeout

-  
The device has stopped responding to the network, or there is a problem
-      with the network connection (cable).

-

-

-

-

-
netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The ti device driver first appeared in
-    NetBSD 1.4.2.

-

-

-

-
The ti driver was written by
-    Bill Paul
-    <wpaul@ctr.columbia.edu>.

-

-

-

-
The driver currently tries to access some on-board memory
-    transparently. This mapping (BUS_SPACE_MAP_LINEAR) fails on systems where
-    the corresponding PCI memory range is located in "sparse" space
-    only.

-
This driver currently does not work on big-endian systems.

-

-

-
-  
-    
-    
-  
-
June 2, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/tl.4 4.html b/static/netbsd/man4/tl.4 4.html
deleted file mode 100644
index 72330fc4..00000000
--- a/static/netbsd/man4/tl.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
TL(4)Device Drivers ManualTL(4)

-

-

-

-
tl — Ethernet
-    driver for Texas Instruments ThunderLAN based board

-

-

-

-
tl* at pci? dev ? function ?

-
Configuration of PHYs is necessary. See
-  mii(4).

-

-

-

-
The tl device driver supports network
-    adapters based on the Texas Instruments ThunderLAN chip.

-

-

-

-
Supported cards include:

-

-

-  
Compaq Netelligent

-  
in baseboard and PCI variants (10BASE-T-only variant untested).

-  
Compaq NetFlex 3/P

-  
in baseboard variant only (the PCI variant doesn't use the same
-    chip!).

-  
It Baseboard Compaq Deskpro 4000 5233MMX Ethernet

-  
(This has been tested on the Deskpro 4000M only).

-  
TI TravelMate 5000 series laptop docking station's Ethernet board.

-  
 

-

-

-

-

-

-
The different models of the supported boards come with some subset
-    of RJ-45, BNC and AUI connectors. Media selection is done using
-    ifconfig(8) using the standard
-    ifmedia(4) mechanism. Refer to those manual pages for more
-    information.

-
The tl driver doesn't have full automatic
-    media selection. By default it will do an Nway (IEEE 802.3u) negotiation on
-    the 10BASE-T port for the speed and duplex mode with the link partner. If
-    the AUI or BNC port is used, an explicit media type must be specified to
-    ifconfig(8).

-

-

-

-
ifmedia(4), mii(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The board marked as untested will always claim having an AUI
-    connector, where it may be a BNC one.

-

-

-
-  
-    
-    
-  
-
May 16, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/tlp.4 4.html b/static/netbsd/man4/tlp.4 4.html
deleted file mode 100644
index 1dc66e03..00000000
--- a/static/netbsd/man4/tlp.4 4.html	
+++ /dev/null
@@ -1,427 +0,0 @@
-
-  
-    
-    
-    
-  
-
TLP(4)Device Drivers ManualTLP(4)

-

-

-

-
tlp — DECchip
-    21x4x and clone Ethernet interfaces device driver

-

-

-

-
tlp* at eisa? slot ?
-  

-  tlp* at pci? dev ? function ?
-  

-  tlp* at cardbus? function ?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The tlp device driver supports Ethernet
-    interfaces based on the DECchip 21x4x “Tulip” (DEC fourth
-    generation Ethernet controller) and a variety of clone chips. The Tulip has
-    several features designed to make it flexible and reduce CPU usage:

-
    
-  
  • Flexible receive filter allowing for 16 perfect matches, 16 perfect
-      inverse matches, 512-bit hash table plus 1 perfect match, or 512-bit hash
-      table only.
    • 
-  
  • Uniform transmit descriptor architecture, configurable as a ring (allowing
-      2 buffers per descriptor) or a chain (allowing 1 buffer per
-    descriptor).
    • 
-  
  • Uniform receive descriptor architecture, configurable as a ring (allowing
-      2 buffers per descriptor) or a chain (allowing 1 buffer per
-    descriptor).
    • 
-  
  • Interrupt pacing; host may choose whether or not completion of processing
-      of an individual descriptor causes an interrupt.
    • 
-  
  • Support for jumbo packets (by disabling transmit and receive watchdog
-      timers).
    • 
-  
  • A patented transmit backoff algorithm which solves the Ethernet capture
-      effect problem.
    • 
-  
  • Flexible bus modes to optimize DMA cycles for various cache sizes and bus
-      implementations.
    • 
-  
  • Programmable transmit FIFO drain threshold to allow DMA overlap and reduce
-      time to transmit.
    • 
-  
  • Flexible media attachment facilities.
    • 
-

-
The tlp driver supports the following
-    chips:

-
    
-  
  •  -- This is the original Tulip Ethernet chip. It supports
-      10Mb/s speeds over a built-in serial interface. The serial interface has
-      support for 10BASE-T and AUI media. The AUI port may be connected to
-      10BASE5 AUI or 10BASE2 BNC connectors, or both, selected by a gang jumper
-      on the board. Some boards connect the BNC connector to an external serial
-      interface. The driver has no way of knowing this, but the external serial
-      interface may be selected with the “manual” media setting.
-    
    Boards that include this chip include the DEC DE-435, on-board
-        Ethernet on many DEC AlphaStation and AlphaServer systems, ZNYX ZX312,
-        ZX312T, ZX314, ZX315, SMC 8432, SMC 8434, ACCTON EN1203, and some Cogent
-        multi-port boards.
    
-    
    This chip also appears on the DEC DE-425 EISA Ethernet board.
-        This board is a DECchip 21040 and a PLX PCI glue chip, which provides
-        the interface to the EISA bus, and special address decoding so that the
-        PCI configuration space registers of the 21040 are accessible in normal
-        EISA I/O space.
    
-    
    The very first versions of this chip were labeled
-        “DC1003” and “DC1003 Prototype”.
    
-  
    • 
-  
  •  -- This is the second chip in the Tulip family, dubbed
-      “Tulip Plus”. It supports 10Mb/s speeds over a built-in
-      serial interface. The serial interface has support for 10BASE-T, 10BASE5
-      AUI, and 10BASE2 BNC media. The serial interface also includes support for
-      IEEE 802.3u NWay over the 10BASE-T interface, for negotiation of duplex
-      mode with the link partner.
-    
    Boards that include this chip include the DEC DE-450 and some
-        SMC boards.
    
-  
    • 
-  
  •  -- This is the third chip in the Tulip family,
-      dubbed “FasterNet”. It supports 10Mb/s speeds with a
-      built-in 10BASE-T encoder/decoder, and 100Mb/s speeds with a built-in
-      100BASE PCS function. Support for 100BASE-TX and 100BASE-T4 is provided by
-      a built-in scrambler. Support for 100BASE-FX is possible with an
-      appropriate PMD connected to the 100BASE PCS. The 21140 and 21140A also
-      support 10Mb/s and 100Mb/s speeds over an MII interface connected to one
-      or more PHYs.
-    
    The 21140 and 21140A include a general purpose I/O facility,
-        which may be used to toggle relays on the board. This facility is often
-        used to reset individual board modules (e.g. the MII bus), select the
-        output path of the chip (e.g. connect the UTP port on the board to the
-        PHY, built-in 10BASE-T ENDEC, or built-in 100BASE-T PMD), or detect link
-        status (by reading an output pin on the 100BASE-T magnetics).
    
-    
    The 21140 and 21140A use a standardized data structure located
-        in the SROM to describe how the chip should be programmed for various
-        media settings, including the internal chip pathway, and GPIO settings.
-        If the SROM data is not in the standardized format, the device driver
-        must know specific programming information for that particular
-      board.
    
-    
    Boards that include the 21140 and 21140A include the DEC
-        EB140, DE-500XA, DE-500AA, Asante EtherFast, DaynaPORT BlueStreak,
-        Cogent EM100TX, EM110TX, EM440T4 multi-port, Kingston KNE100TX, older
-        versions of the NetGear FA-310TX, SMC 9332, SMC 9334, ZNYX ZX34x
-        multi-port, and Adaptec ANA-6944A/TX multi-port.
    
-  
    • 
-  
  •  -- These are the fourth and fifth chips in the
-      Tulip family. While they have two different chip numbers, the 21142 and
-      21143 are essentially identical, with only minor differences related to
-      available technology at time of manufacture. Both chips include support
-      for 10Mb/s speeds over a built-in serial interface, and support for 10Mb/s
-      and 100Mb/s speeds over an MII interface connected to one or more PHYs.
-      The serial interface includes support for 10BASE-T, 10BASE5 AUI, and
-      10BASE2 BNC media, as well as support for IEEE 802.3u NWay over the
-      10BASE-T interface, for negotiation of duplex mode and link speed with the
-      link partner.
-    
    The 21143 adds support for 100Mb/s speeds with a built-in PCS
-        function. Support for 100BASE-TX and 100BASE-T4 is provided by a
-        built-in scrambler. Support for 100BASE-FX is possible with an
-        appropriate PMD connected to the 100BASE PCS.
    
-    
    The 21142 and 21143 include a general purpose I/O facility,
-        which may be used to toggle relays on the board. This facility is often
-        used to reset individual board modules (e.g. the MII bus), select the
-        output path of the chip (e.g. connect the UTP port on the board to the
-        PHY, built-in serial interface, or built-in 100BASE-T PMD), or detect
-        link status (by reading an output pin on the 100BASE-T magnetics).
    
-    
    The 21142 and 21143 use a standardized data structure located
-        in the SROM to describe how the chip should be programmed for various
-        media settings, including the internal chip pathway, and GPIO settings.
-        If the SROM data is not in the standardized format, the device driver
-        must know specific programming information for that particular
-      board.
    
-    
    Boards that include the 21142 include the DEC EB142, and
-        on-board Ethernet on the Digital Personal Workstation (Alpha
-        “Miata” and x86 models) and several Digital PCs.
    
-    
    Boards that include the 21143 include the DEC EB143, DE-500BA,
-        several commonly-available 100BASE-FX boards, the NetGear FA-510c
-        CardBus card, and the Compu-Shack FASTline-II PCI boards.
    
-  
    • 
-  
  •  -- These chips, dubbed “PNIC”,
-      were some of the first commonly-available Tulip clones, appearing on
-      low-cost boards when it became difficult for board vendors to obtain
-      DECchip 21140A parts. They include support for 10Mb/s speeds over a
-      built-in 10BASE-T encoder/decoder, and 100Mb/s speeds over a built-in PCS
-      function. Support for 100BASE-TX and 100BASE-T4 is provided by a built-in
-      scrambler and transceiver module. The transceiver module also includes
-      support for NWay, for negotiating duplex mode and link speed with the link
-      partner. These chips also include support for 10Mb/s and 100Mb/s speeds
-      over and MII interface connected to one or more PHYs.
-    
    These chips also include a GPIO facility, although it is
-        programmed differently than the 21140's.
    
-    
    Unfortunately, these chips seem to be plagued by two
-        unfortunate hardware bugs: in some situations, the receive logic
-        incorrectly dumps the entire transmit FIFO into the receive chain,
-        rather than a single Ethernet frame, and the DMA engines appear to be
-        substandard; they must be run in store-and-forward mode, and
-        occasionally fail to upload the filter setup frame.
    
-    
    Boards that include the 82C168 and 82C169 include the newer
-        NetGear FA-310TX, the Kingston KNE110TX, and some older LinkSys LNE100TX
-        boards.
    
-  
    • 
-  
  •  -- Of all the clones,
-      these chips, dubbed “PMAC”, are the best. They are very
-      close clones of their respective originals, with the exception of some
-      slight programming magic necessary to work around an apparent hardware
-      bug.
-    
    The 98713 is a DECchip 21140A clone. It includes all of the
-        21140A's features, and uses the same SROM data format.
    
-    
    The 98713A is a half-clone of the DECchip 21143. It has
-        support for serial, PCS, and MII media. The serial interface has a
-        built-in NWay function. However, the 98713A does not have a GPIO
-        facility, and, as a result, usually does not use the same SROM format as
-        the 21143 (no need for GPIO programming information).
    
-    
    The 98715, 98715A, and 98725 are more 21143-like, but lack the
-        GPIO facility and MII. These chips also support ACPI power
-      management.
    
-    
    Boards that include the Macronix chips include some SVEC
-        boards, some SOHOWare boards, and the Compex RL100TX.
    
-  
    • 
-  
  •  -- This chip, dubbed the “PNIC-II”, was
-      co-designed by Lite-On and Macronix. It is almost identical to the
-      Macronix 98725, with a few exceptions: it has Wake-On-LAN support, uses a
-      128-bit receive filter hash table, and supports IEEE 802.3x flow control.
-    
    Boards that include the 82C115 include the newer LinkSys
-        (Version 2) LNE100TX boards.
    
-  
    • 
-  
  •  -- This chip is a very low-end barely-a-clone of the
-      21140. It supports 10Mb/s and 100Mb/s speeds over an MII interface only,
-      and has several programming differences from the 21140.
-    
    The receive filter is completely different: it supports only a
-        single perfect match, and has only a 64-bit multicast filter hash table.
-        The receive filter is programmed using special registers rather than the
-        standard Tulip setup frame.
    
-    
    This chip is also plagued by a terrible DMA engine. The chip
-        must be run in store-and-forward mode or it will often transmit garbage
-        onto the wire.
    
-    
    Interrupt pacing is also less flexible on the chip.
    
-    
    Boards that include the 89C940F include the Complex RL100ATX,
-        some Unicom 10/100 boards, and several no-name 10/100 boards.
    
-  
    • 
-  
  •  -- This chip is a low cost, single-chip (sans magnetics)
-      10/100 Ethernet implementation. It supports 10Mb/s and 100Mb/s speeds over
-      an internal PHY. There is no generic MII bus; instead the IEEE
-      802.3u-compliant PHY is accessed via special registers on the chip. This
-      chip also supports Wake-On-LAN and IEEE 802.3x flow control.
-    
    The receive filter on the AL981 is completely different: it
-        supports only a single perfect match, and has only a 64-bit multicast
-        filter hash table. The receive filter is programmed using special
-        registers rather than the standard Tulip setup frame.
    
-    
    This chip also supports ACPI power management.
    
-    
    A list of boards which include the AL981 is not yet
-      available.
    
-    
    Support for the AL981 has not yet been tested. If you have a
-        board which uses this chip, please contact the author (listed
-      below).
    
-  
    • 
-  
  •  -- This chip is a CardBus 21143 clone with a
-      loosely-coupled modem function (the modem is on a separate CardBus
-      function, but the MAC portion includes a shadow of its interrupt status).
-      Media is provided by an IEEE 802.3u-compliant PHY connected to an MII
-      interface. These chips have no SROM; instead, the MAC address must be
-      obtained from the card's CIS information. Unlike most other Tulip-like
-      chips, the X3201-3 requires that transmit buffers be aligned to a 4-byte
-      boundary. This virtually ensures that each outgoing packet must be copied
-      into an aligned buffer, since the Ethernet header is 14 bytes long.
-    
    This chip also supports ACPI power management.
    
-    
    This chip is found in Xircom RealPort(tm) 10/100 CardBus
-        Ethernet/Modem cards, as well as some Intel OEM'd RealPort(tm) and IBM
-        Etherjet cards.
    
-  
    • 
-  
  •  -- These chips are 21104A-like with a few minor
-      exceptions. Media is provided by an internal IEEE 802.3u-compliant PHY
-      accessed as if it were connected to a normal MII interface. The DM9102A
-      also provides an external MII interface, to which a HomePNA 1 PHY is
-      typically connected. The DM9102A also includes support for CardBus.
-    
    This chip also supports ACPI power management and
-      Wake-On-LAN.
    
-    
    A complete list of boards with the DM9102 and DM9102A is not
-        available. However, the DM9102 is often found on PC motherboards that
-        include a built-in Ethernet interface.
    
-  
    • 
-  
  •  -- These chips are 21143-like with some exceptions.
-      Media is proved by an internal IEEE 802.3u-compliant PHY connected to an
-      MII interface. Unlike most other Tulip-like chips, AX88140A and AX88141
-      both require that the transmit buffers be aligned to a 4-byte boundary.
-    
    It has a specific broadcast bit.
    
-    
    This chip also supports ACPI power management.
    
-    
    A list of boards which include the AX88140A or the AX88141 is
-        not yet available.
    
-  
    • 
-  
  •  -- These chips are 21143 clones with coupled
-      modem function. Media is provided by an IEEE 802.3u-compliant PHY
-      connected to an MII interface.
-    
    A list of boards which include the RS7112 is not yet
-        available.
    
-  
    • 
-

-

-

-

-
Media selection done using ifconfig(8) using the
-    standard ifmedia(4) mechanism. Refer to those manual pages
-    for more information.

-

-

-

-
arp(4), eisa(4),
-    ifmedia(4), mii(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-
Digital Equipment
-    Corporation, DECchip 21040 Ethernet LAN Controller
-    for PCI Hardware Reference Manual, May 1994,
-    Order Number EC-N0752-72.

-
Digital Equipment
-    Corporation, DECchip 21041 PCI Ethernet LAN
-    Controller Hardware Reference Manual,
-    Preliminary, April 1995,
-    Order Number EC-QAWXA-TE.

-
Digital Equipment
-    Corporation, DECchip 21041 DC1017-BA Errata,
-    Revision 1.0, April 27,
-    1995, Order Number EC-QD2MA-TE.

-
Digital Equipment
-    Corporation, DECchip 21140 PCI Fast Ethernet LAN
-    Controller Hardware Reference Manual, Supersedes
-    EC-Q0CA-TE, May 1995,
-    Order Number EC-Q0CB-TE.

-
Digital Equipment
-    Corporation, DECchip 21140A PCI Fast Ethernet LAN
-    Controller Hardware Reference Manual, Supersedes
-    EC-QN7NA-TE, EC-QN7NB-TE, January 1996,
-    Order Number EC-QN7NC-TE.

-
Intel Corporation,
-    21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller
-    Hardware Reference Manual, Revision 1.0,
-    October 1998, Document Number
-    278074-001.

-
Digital Equipment
-    Corporation, Ethernet Address ROM Programming: An
-    Application Note, April 1994,
-    Order Number EC-N3214-72.

-
Digital Equipment
-    Corporation, Using the DECchip 21041 with Boot ROM,
-    Serial ROM, and External Register: An Application Note,
-    April 1995, Order Number
-    EC-QJLGA-TE.

-
Digital Equipment
-    Corporation, Connecting the DECchip 21140 PCI Fast
-    Ethernet LAN Controller to the Network: An Application Note,
-    Preliminary, December
-    1994, Order Number EC-QAR2A-TE.

-
Macronix International Co.,
-    Ltd., MXIC MX98713 PMAC 100/10BASE PCI MAC
-    Controller, Revision 1.1,
-    November 8, 1996, Part Number:
-    PM0386.

-
Macronix International Co.,
-    Ltd., MXIC MX98713A Fast Ethernet MAC
-    Controller, Revision 1.0,
-    August 28, 1997, Part Number:
-    PM0489.

-
Macronix International Co.,
-    Ltd., MXIC MX98715A Single Chip Fast Ethernet NIC
-    Controller, Revision 1.2,
-    February 24, 1999, Part Number:
-    PM0537.

-
Macronix International Co.,
-    Ltd., MXIC MX98725 Single Chip Fast Ethernet NIC
-    Controller, Revision 1.7,
-    September 15, 1998, Part Number:
-    PM0468.

-
Macronix International Co.,
-    Ltd., MXIC MX98715 Application Note,
-    Revision 1.5, October 9,
-    1998, Part Number: PM0498.

-
Macronix International Co.,
-    Ltd., MXIC MX98715A Application Note,
-    Revision 1.2, October 9,
-    1998, Part Number: PM0541.

-
Macronix International Co.,
-    Ltd., MXIC MX98725 Application Note,
-    Revision 1.1, July 10,
-    1998, Part Number: PM0525.

-
Macronix International Co.,
-    Ltd., MXIC LC82C115 Single Chip Fast Ethernet NIC
-    Controller, Revision 0.2,
-    February 12, 1999, Part Number:
-    PM0572.

-
LITE ON, Inc.,
-    PNIC Hardware Specification,
-    Revision 1.0, December 1,
-    1994.

-
ADMtek Incorporated,
-    Comet: AL981 PCI 10/100 Fast Ethernet Controller with
-    Integrated PHY, Revision 0.93,
-    January, 1999.

-
Winbond Electronics
-    Corporation, Winbond LAN W89C840F 100/10Mbps
-    Ethernet Controller, Revision A1,
-    April 1997.

-
Xircom X3201-3 CardBus 10/100
-    Mbps Ethernet Controller Software Developer's Specification,
-    Revision B, April 7, 1999,
-    Reference number: 103-0548-001.

-
Davicom DM9102 10/100 Mbps
-    Single Chip LAN Controller, Version
-    DM9102-DS-F01, July 22, 1999.

-
Davicom DM9102A Single Chip
-    Fast Ethernet NIC Controller, Version
-    DM9102A-DS-F01, January 20, 2000.

-
ASIX Electronics Co.,
-    ASIX AX88140A 100BaseTX/FX PCI Bus Fast Ethernet MAC
-    Controller, Preliminary,
-    March 11, 1997, Document Number
-    AX140D2.DOC.

-
Conexant Systems, Inc.,
-    LANfinity - Home Networking Physical Layer Device with
-    Integrated Analog Front End Circuitry, Revision
-    A, March 12, 1999.

-

-

-

-
The tlp driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The tlp driver was written by
-    Jason R. Thorpe while employed at the Numerical
-    Aerospace Simulation Facility, NASA Ames Research Center. The author may be
-    contacted at ⟨thorpej@NetBSD.org⟩.

-
ASIX AX88140A and AX881401 support was added by
-    Rui Paulo ⟨rpaulo@NetBSD.org⟩.

-
Conexant RS7112 support was contributed by Frank
-    Wille ⟨frank@phoenix.owl.de⟩.

-

-

-

-
Media autosense is not yet supported for any serial or PCS
-    function media. It is, however, supported for IEEE 802.3u-compliant PHY
-    media.

-

-

-
-  
-    
-    
-  
-
March 26, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/tlphy.4 4.html b/static/netbsd/man4/tlphy.4 4.html
deleted file mode 100644
index 40bd295f..00000000
--- a/static/netbsd/man4/tlphy.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
TLPHY(4)Device Drivers ManualTLPHY(4)

-

-

-

-
tlphy — Driver for
-    TI ThunderLAN internal Ethernet PHYs

-

-

-

-
tlphy* at mii? phy ?

-

-

-

-
The tlphy driver supports the internal PHY
-    on TI ThunderLAN Ethernet interfaces. The ThunderLAN PHY supports 10BASE5
-    (AUI) and 10BASE2 (BNC) on some ThunderLAN implementations.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), tl(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
November 3, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/tm121temp.4 4.html b/static/netbsd/man4/tm121temp.4 4.html
deleted file mode 100644
index 701af759..00000000
--- a/static/netbsd/man4/tm121temp.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
TM121TEMP(4)Device Drivers ManualTM121TEMP(4)

-

-

-

-
tm121temp — Texas
-    Instruments TMP121 temperature sensor

-

-

-

-
tm121temp0 at spi? slave 0

-

-

-

-
The tm121temp driver provides support for
-    the Texas Instruments (formerly Burr-Brown) TMP121 temperature sensor with
-    the envsys(4) API. These devices are connected to the host
-    system with spi(4) or Microwire 4-wire serial busses. The
-    tm121temp is capable of measuring temperatures with
-    a 2 degree accuracy over the frame from -40 to 125 Celsius. Temperatures are
-    reported with a granularity of 625 microKelvins.

-
tm121temp devices can transfer information
-    at up to 10MHz, and support SPI mode 0.

-
The device reports itself with envsys(4) using
-    the generic device name. This name can be overridden, by specifying an
-    alternate name in the device property
-  “envsys-description”.

-

-

-

-
envsys(4), spi(4),
-    envstat(8)

-

-

-

-
The tm121temp driver was written by
-    Garrett D'Amore and first appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
October 9, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/tpm.4 4.html b/static/netbsd/man4/tpm.4 4.html
deleted file mode 100644
index 151df6a3..00000000
--- a/static/netbsd/man4/tpm.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
TPM(4)Device Drivers ManualTPM(4)

-

-

-

-
tpm — Trusted
-    Platform Module

-

-

-

-
tpm* at isa? iomem 0xfed40000
-  

-  tpm* at acpi?

-

-

-

-
The tpm driver provides support for
-    various Trusted Platform Module (TPM) chips.

-
Supported modules:

-

-
    
-  
  • TPM 2.0 chips over ACPI
    • 
-  
  • TPM 1.2 chips over ACPI and ISA
    • 
-

-
Note that the supported interface version is TIS1.2 in each
-  case.

-
The TPM may need to be enabled in the system's firmware or BIOS,
-    which requires a reboot to take effect. This is generally beyond the control
-    of NetBSD. Enabling a TPM does not require using
-    trusted boot — it can be enabled, for example, only for the
-    rnd(4) entropy source.

-

-

-

-
config(1), intro(4),
-    rnd(4)

-

-

-

-
The tpm driver was written by
-    Maxime Villard, Michael
-    Shalayeff and Hans-Joerg Hoexer.

-

-

-
-  
-    
-    
-  
-
January 15, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/tprof.4 4.html b/static/netbsd/man4/tprof.4 4.html
deleted file mode 100644
index 05df5429..00000000
--- a/static/netbsd/man4/tprof.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
TPROF(4)Device Drivers ManualTPROF(4)

-

-

-

-
tprof — a sampling
-    based profiler

-

-

-

-
pseudo-device tprof

-

-

-

-
The tprof driver provides kernel services
-    necessary for tprof(8).

-
Specifically, it makes its backend driver collect profiling
-    samples and provide them to the userland consumer.

-
The API/ABI is currently undocumented and will likely change in
-    future without keeping compatibility.

-
On x86, the tprof_x86 module must be loaded in addition to the
-    tprof driver.

-

-

-

-
tprof(8)

-

-

-

-
The tprof driver was written by
-    YAMAMOTO Takashi.

-

-

-

-
There is no way to configure multiple backend drivers
-  statically.

-

-

-
-  
-    
-    
-  
-
December 12, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/tps65217pmic.4 4.html b/static/netbsd/man4/tps65217pmic.4 4.html
deleted file mode 100644
index abee2b71..00000000
--- a/static/netbsd/man4/tps65217pmic.4 4.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
TPS65217PMIC(4)Device Drivers ManualTPS65217PMIC(4)

-

-

-

-
tps65217pmic —
-    Texas Instruments TPS65217 Power Management IC
-    driver

-

-

-

-
tps65217pmic0 at iic? addr 0x24

-

-

-

-
The tps65217pmic driver provides minimal
-    support for the TPS65217 chip and allows reporting regulated voltages
-    through the envsys(4) API.

-
The TPS65217 consists of low-dropout regulators (LDO) and
-    step-down converters with integrated switching FETs (DCDC):

-
    
-  
  • LDO1: 1.0V - 3.3V
    • 
-  
  • LDO2: 0.9V - 3.3V
    • 
-  
  • LDO3: 1.5V - 3.3V
    • 
-  
  • LDO4: 1.5V - 3.3V
    • 
-  
  • DCDC1: 0.9V - 1.8V
    • 
-  
  • DCDC2: 0.9V - 3.3V
    • 
-  
  • DCDC1: 0.9V - 1.5V
    • 
-

-

-

-

-
envsys(4)

-

-

-

-
The tps65217pmic device first appeared in
-    NetBSD 7.0.

-

-

-

-
The tps65217pmic driver was written by
-    Radoslaw Kujawa
-    <radoslaw.kujawa@gmail.com>.
-    Voltage change callback for AM335x was added by Manuel
-    Bouyer. White LED (backlight) support was added by
-    KIYOHARA Takashi.

-

-

-

-
The driver can only report current voltage regulator settings. It
-    can not measure the real voltage, as the TPS65217 chip lacks hardware to do
-    that. Some boards allow voltage measurement by connecting the power output
-    to external sensor, or analog input of the MPU, but this is outside of the
-    scope of this driver.

-
Modifying voltage regulator parameters from user space was
-    deliberately left unimplemented, as these parameters should only be set at
-    the firmware or kernel level. Setting wrong parameters may result in
-    permanent hardware damage.

-
The tps65217pmic driver offers a function
-    that can be used to change the voltage from other kernel components
-    (currently used by AM335x support code).

-

-

-

-
Battery and interrupt support is not implemented.

-

-

-
-  
-    
-    
-  
-
June 28, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/tqphy.4 4.html b/static/netbsd/man4/tqphy.4 4.html
deleted file mode 100644
index 0444df4d..00000000
--- a/static/netbsd/man4/tqphy.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
TQPHY(4)Device Drivers ManualTQPHY(4)

-

-

-

-
tqphy — Driver for
-    TDK Semiconductor 78Q2120 10/100 Ethernet PHYs

-

-

-

-
tqphy* at mii? phy ?

-

-

-

-
The tqphy driver supports the TDK
-    Semiconductor 78Q2120 PHY found in some CardBus and Mini-PCI Ethernet
-  cards.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-

-
Due to hardware bugs, the tqphy driver refuses to match chips with
-    revision 3 or lower. For these chips, use ukphy(4)
-    instead.

-

-

-
-  
-    
-    
-  
-
September 27, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/tra.4 4.html b/static/netbsd/man4/tra.4 4.html
deleted file mode 100644
index ba7b599a..00000000
--- a/static/netbsd/man4/tra.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
TRA(4)Device Drivers ManualTRA(4)

-

-

-

-
tra — Fujitsu
-    MB86950 based Tiara Ethernet cards driver

-

-

-

-
tra* at mca? slot ?

-

-

-

-
The tra driver supports Tiara MCA bus
-    Ethernet adapters and clones, based on the Fujitsu MB86950 Ethernet
-    controller. Supported boards include:

-

-

-  
Tiara LANCard/E Ethernet Adapter

-  
 

-  
Standard MicroSystems 3016/MC Ethernet

-  
 

-

-

-

-

-

-
ifmedia(4), intro(4),
-    mca(4), ifconfig(8)

-

-

-

-
The tra driver appeared in
-    NetBSD 4.0.

-

-

-

-
The tra driver has been written by
-    Dave Barnes ⟨djb_pizza@ieee.org⟩.

-

-

-

-
Multicast is not supported. There is no hardware support for
-    multicast, and the driver does not implement a software-only solution.

-

-

-
-  
-    
-    
-  
-
March 3, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/trm.4 4.html b/static/netbsd/man4/trm.4 4.html
deleted file mode 100644
index b7ab723a..00000000
--- a/static/netbsd/man4/trm.4 4.html	
+++ /dev/null
@@ -1,66 +0,0 @@
-
-  
-    
-    
-    
-  
-
TRM(4)Device Drivers ManualTRM(4)

-

-

-

-
trm — Tekram
-    TRM-S1040 ASIC based PCI SCSI host adapter driver

-

-

-

-
trm* at pci? dev ? function ?
-  

-  scsibus* at trm?

-

-

-

-
The trm driver supports PCI SCSI host
-    adapters based on the Tekram TRM-S1040 SCSI ASIC.

-

-

-

-
Supported SCSI controllers include:

-
    
-  
  • Tekram DC-315 PCI Ultra SCSI adapter without flash BIOS and internal SCSI
-      connector
    • 
-  
  • Tekram DC-315U PCI Ultra SCSI adapter without flash BIOS
    • 
-  
  • Tekram DC-395U PCI Ultra SCSI adapter with flash BIOS
    • 
-  
  • Tekram DC-395UW PCI Ultra-Wide SCSI adapter with flash BIOS
    • 
-  
  • Tekram DC-395F PCI Ultra-Wide SCSI adapter with flash BIOS and 68-pin
-      external SCSI connector
    • 
-

-
For Tekram DC-390 PCI SCSI host adapter, use
-    pcscp(4) driver.

-
For Tekram DC-310/U and DC-390U/UW/F PCI SCSI host adapters, use
-    siop(4) driver.

-

-

-

-
cd(4), ch(4),
-    intro(4), pci(4),
-    scsi(4), sd(4), ss(4),
-    st(4), uk(4),
-    scsipi(9)

-
Tekram Systems
-    Co.

-

-

-

-
The trm driver was originally written for
-    NetBSD 1.4/i386 by Erich Chen of Tekram Technology,
-    and Rui-Xiang Guo rewrote the driver to use bus_space(9)
-    and bus_dma(9) for NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
November 6, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/tsllux.4 4.html b/static/netbsd/man4/tsllux.4 4.html
deleted file mode 100644
index 3fd1cad3..00000000
--- a/static/netbsd/man4/tsllux.4 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
TSLLUX(4)Device Drivers ManualTSLLUX(4)

-

-

-

-
tsllux — Taos
-    TSL256x Light-to-Digital Converter

-

-

-

-
tsllux* at iic? addr 0x29 flags 0x0
-  

-  tsllux* at iic? addr 0x39 flags 0x0
-  

-  tsllux* at iic? addr 0x49 flags 0x0

-

-

-

-
The tsllux driver provides support for the
-    Taos TSL2560 and TSL2561 light-to-digital converter (ambient light sensor)
-    with the envsys(4) API.

-
The TSL2560 is designed to work with SMBus at 100 kHz. The TSL2561
-    is designed to work with I2C Fast-Mode at 400 kHz. The sensors come in a
-    variety of packages, including 6-lead Chipscale (CS), 6-lead TMB (T), dual
-    flat no-lead (FN), and 6-lead ChipLED (CL). The ‘CS’ package
-    requires a different set of coefficients for calculating the Lux value from
-    the raw sensor data. This behavior is enabled by specifying the flag
-    0x1 in the kernel configuration file or by using a
-    sysctl(8) variable; see below.

-
The tsllux driver exports some
-    sysctl(8) variables to control the behavior of the sensor
-    and driver:

-

-  
hw.tsllux0.cs_package (boolean, read-write)

-  
This variable indicates if the driver instance has been configured to use
-      the coeffecients appropriate for the ‘CS’ package
-    variant.

-  
hw.tsllux0.auto_gain (boolean, read-write)

-  
This variable indicates if the driver has been configured to use an
-      auto-gain algorithm to improve sensitivity of the sensor while taking care
-      to avoid sensor saturation. Auto-gain is disabled by default.

-  
hw.tsllux0.gain (integer, read-write)

-  
This variable indicates the selected sensor gain. If auto-gain is enabled,
-      this will reflect the current gain setting selected by the auto-gain
-      algorithm. Otherwise, it reflects the previously-configured gain. Valid
-      values are 1 and 16. The
-      default gain is 1. Writing to this variable
-      implicitly disables auto-gain.

-  
hw.tsllux0.integration_time (integer, read-write)

-  
This variable indicates the selected analog-to-digital converter
-      integration time. Longer integration times correspond to more accurate
-      readings, at the cost of more costly read operation. Valid values are
-      13 (13.7ms), 101 (101ms),
-      and 402 (402ms). The default value is
-      101. Note that that due to the granularity of
-      sleep timing in the kernel, the tsllux driver will
-      busy-wait for wait times less than 1 Hz, and add an additional sleep clock
-      tick for wait times greater than 1 Hz. See hz(9).

-

-

-

-

-
envsys(4), iic(4)

-

-

-

-
The tsllux driver first appeared in
-    NetBSD 9.0.

-

-

-

-
The tsllux driver was written by
-    Jason R Thorpe
-    <thorpej@NetBSD.org>.

-

-

-

-
The driver does not currently support the sensor's interrupt
-    features or the sensor's manual integration timing feature.

-

-

-
-  
-    
-    
-  
-
May 21, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/tty.4 2.html b/static/netbsd/man4/tty.4 2.html
deleted file mode 100644
index 3262c807..00000000
--- a/static/netbsd/man4/tty.4 2.html	
+++ /dev/null
@@ -1,403 +0,0 @@
-
-  
-    
-    
-    
-  
-
TTY(4)Device Drivers ManualTTY(4)

-

-

-

-
tty — general
-    terminal interface

-

-

-

-
#include
-    <sys/ioctl.h>

-

-

-

-
This section describes the interface to the terminal drivers in
-    the system.

-

-

-
Each hardware terminal port on the system usually has two terminal
-    special device files associated with it in the directory
-    /dev/ (for example,
-    /dev/tty03 and
-  /dev/dty03).

-
The /dev/ttyXX special file is used for
-    dial-in modems and terminals. When a user logs into the system on one of
-    these hardware terminal ports, the system has already opened the associated
-    device and prepared the line for normal interactive use (see
-    getty(8)).

-
The /dev/dtyXX special file is a
-    SunOS-compatible dial-out device. Unlike the dial-in device, opening the
-    dial-out device never blocks. If the corresponding dial-in device is already
-    opened (not blocked in the open waiting for carrier), then the dial-out open
-    will fail immediately; otherwise it will succeed immediately. While the
-    dial-out device is open, the dial-in device may not be opened. If the
-    dial-in open is blocking, it will wait until the dial-out device is closed
-    (and carrier is detected); otherwise it will fail immediately.

-
There is also a special case of a terminal file that
-    connects not to a hardware terminal port, but to another program on the
-    other side. These special terminal devices are called
-     (pseudo
-    terminals) and provide the mechanism necessary to give users the same
-    interface to the system when logging in over a network (using
-    rlogin(1) or telnet(1), for example).
-    Even in these cases the details of how the terminal file was opened and set
-    up is already handled by special software in the system. Thus, users do not
-    normally need to worry about the details of how these lines are opened or
-    used. Also, these lines are often used for dialing out of a system (through
-    an out-calling modem), but again the system provides programs that hide the
-    details of accessing these terminal special files (see
-    tip(1)).

-
When an interactive user logs in, the system prepares the line to
-    behave in a certain way (called a line discipline), the
-    particular details of which is described in stty(1) at the
-    command level, and in termios(4) at the programming level.
-    A user may be concerned with changing settings associated with his
-    particular login terminal and should refer to the preceding man pages for
-    the common cases. The remainder of this man page is concerned with
-    describing details of using and controlling terminal devices at a low level,
-    such as that possibly required by a program wishing to provide features
-    similar to those provided by the system.

-

-

-

-
A terminal file is used like any other file in the system in that
-    it can be opened, read, and written to using standard system calls. For each
-    existing terminal file, there is a software processing module called a
-    line discipline associated with it. The line
-    discipline essentially glues the low level device driver code with the
-    high level generic interface routines (such as read(2) and
-    write(2)), and is responsible for implementing the
-    semantics associated with the device. When a terminal file is first opened
-    by a program, the default line discipline called the
-    termios line discipline is associated with the file.
-    This is the primary line discipline that is used in most cases and provides
-    the semantics that users normally associate with a terminal. When the
-    termios line discipline is in effect, the terminal
-    file behaves and is operated according to the rules described in
-    termios(4). Please refer to that man page for a full
-    description of the terminal semantics. The operations described here
-    generally represent features common across all line
-    disciplines, however some of these calls may not make sense in
-    conjunction with a line discipline other than
-    termios, and some may not be supported by the
-    underlying hardware (or lack thereof, as in the case of ptys).

-

-

-

-
All of the following operations are invoked using the
-    ioctl(2) system call. Refer to that man page for a
-    description of the
-    
-    and argp parameters. In addition to the ioctl
-    requests defined here, the specific line discipline in
-    effect will define other requests specific to it
-    (actually, termios(4) defines them as function calls, not
-    ioctl requests). The following section lists the available
-    ioctl requests. The name of the request, a description of its purpose, and
-    the typed argp parameter (if any) are listed. For example,
-    the first entry says

-

-
TIOCSLINED char name[32]

-
and would be called on the terminal associated with file
-    descriptor zero by the following code fragment:

-

-
	ioctl(0, TIOCSLINED, "termios");

-

-

-

-

-

-  

-    char name[32]

-  
Change to the new line discipline called name.

-  

-    char name[32]

-  
Return the current line discipline in the string pointed to by
-      name.

-  

-    void

-  
Set the terminal hardware into BREAK condition.

-  

-    void

-  
Clear the terminal hardware BREAK condition.

-  

-    void

-  
Assert data terminal ready (DTR).

-  

-    void

-  
Clear data terminal ready (DTR).

-  

-    int *tpgrp

-  
Return the current process group the terminal is associated with in the
-      integer pointed to by tpgrp. This is the underlying
-      call that implements the tcgetpgrp(3) call.

-  

-    int *tpgrp

-  
Associate the terminal with the process group (as an integer) pointed to
-      by tpgrp. This is the underlying call that
-      implements the tcsetpgrp(3) call.

-  

-    struct termios *term

-  
Place the current value of the termios state associated with the device in
-      the termios structure pointed to by term. This is
-      the underlying call that implements the tcgetattr(3)
-      call.

-  

-    struct termios *term

-  
Set the termios state associated with the device immediately. This is the
-      underlying call that implements the tcsetattr(3) call
-      with the TCSANOW option.

-  

-    struct termios *term

-  
First wait for any output to complete, then set the termios state
-      associated with the device. This is the underlying call that implements
-      the tcsetattr(3) call with the
-      TCSADRAIN option.

-  

-    struct termios *term

-  
First wait for any output to complete, clear any pending input, then set
-      the termios state associated with the device. This is the underlying call
-      that implements the tcsetattr(3) call with the
-      TCSAFLUSH option.

-  

-    int *num

-  
Place the current number of characters in the output queue in the integer
-      pointed to by num.

-  

-    char *cp

-  
Simulate typed input. Pretend as if the terminal received the character
-      pointed to by cp.

-  

-    void

-  
This call is obsolete but left for compatibility. In the past, when a
-      process that didn't have a controlling terminal (see
-       in termios(4)) first opened a terminal
-      device, it acquired that terminal as its controlling terminal. For some
-      programs this was a hazard as they didn't want a controlling terminal in
-      the first place, and this provided a mechanism to disassociate the
-      controlling terminal from the calling process. It
-       be
-      called by opening the file /dev/tty and calling
-      TIOCNOTTY on that file descriptor.
-    
The current system does not allocate a controlling
-        terminal to a process on an
-        ()
-        call: there is a specific ioctl called TIOCSCTTY
-        to make a terminal the controlling terminal. In addition, a program can
-        ()
-        and call the
-        ()
-        system call which will place the process into its own session - which
-        has the effect of disassociating it from the controlling terminal. This
-        is the new and preferred method for programs to lose their controlling
-        terminal.

-  

-  

-    void

-  
Stop output on the terminal (like typing ^S at the keyboard).

-  

-    void

-  
Start output on the terminal (like typing ^Q at the keyboard).

-  

-    void

-  
Make the terminal the controlling terminal for the process (the process
-      must not currently have a controlling terminal).

-  

-    void

-  
Wait until all output is drained.

-  

-    void

-  
Set exclusive use on the terminal. No further opens are permitted except
-      by root. Of course, this means that programs that are run by root (or
-      setuid) will not obey the exclusive setting - which limits the usefulness
-      of this feature.

-  

-    void

-  
Clear exclusive use of the terminal. Further opens are permitted.

-  

-    int *what

-  
If the value of the int pointed to by what contains
-      the FREAD bit as defined in
-      <sys/fcntl.h>, then all
-      characters in the input queue are cleared. If it contains the
-      FWRITE bit, then all characters in the output
-      queue are cleared. If the value of the integer is zero, then it behaves as
-      if both the FREAD and
-      FWRITE bits were set (i.e. clears both
-    queues).

-  

-    struct winsize *ws

-  
Put the window size information associated with the terminal in the
-      winsize structure pointed to by
-      ws. The window size structure contains the number of
-      rows and columns (and pixels if appropriate) of the devices attached to
-      the terminal. It is set by user software and is the means by which most
-      full-screen oriented programs determine the screen size. The
-      winsize structure is defined in
-      <sys/ioctl.h>.

-  

-    struct winsize *ws

-  
Set the window size associated with the terminal to be the value in the
-      winsize structure pointed to by
-      ws (see above).

-  

-    int *qsize

-  
Get the current size of the tty input and output queues.

-  

-    int *qsize

-  
Set the size of the tty input and output queues. Valid sizes are between
-      1024 and 65536 and input
-      values are converted to a power of two. All pending input and output is
-      dropped.

-  

-    int *on

-  
If on points to a non-zero integer, redirect kernel
-      console output (kernel printf's) to this terminal. If
-      on points to a zero integer, redirect kernel console
-      output back to the normal console. This is usually used on workstations to
-      redirect kernel messages to a particular window.

-  

-    int *state

-  
The integer pointed to by state contains bits that
-      correspond to modem state. Following is a list of defined variables and
-      the modem state they represent:
-    

-    

-      
TIOCM_LE

-      
Line Enable.

-      
TIOCM_DTR

-      
Data Terminal Ready.

-      
TIOCM_RTS

-      
Request To Send.

-      
TIOCM_ST

-      
Secondary Transmit.

-      
TIOCM_SR

-      
Secondary Receive.

-      
TIOCM_CTS

-      
Clear To Send.

-      
TIOCM_CAR

-      
Carrier Detect.

-      
TIOCM_CD

-      
Carrier Detect (synonym).

-      
TIOCM_RNG

-      
Ring Indication.

-      
TIOCM_RI

-      
Ring Indication (synonym).

-      
TIOCM_DSR

-      
Data Set Ready.

-    

-    
This call sets the terminal modem state to that represented by
-        state. Not all terminals may support this.

-  

-  

-    int *state

-  
Return the current state of the terminal modem lines as represented above
-      in the integer pointed to by state.

-  

-    int *state

-  
The bits in the integer pointed to by state
-      represent modem state as described above, however the state is OR-ed in
-      with the current state.

-  

-    int *state

-  
The bits in the integer pointed to by state
-      represent modem state as described above, however each bit which is on in
-      state is cleared in the terminal.

-  

-    int *state

-  
The bits in the integer pointed to by state contain
-      bits that correspond to serial port state. Following is a list of defined
-      flag values and the serial port state they represent:
-    

-    

-      
TIOCFLAG_SOFTCAR

-      
Ignore hardware carrier.

-      
TIOCFLAG_CLOCAL

-      
Set the termios(4) CLOCAL
-          flag on open.

-      
TIOCFLAG_CRTSCTS

-      
Set the termios(4) CRTSCTS
-          flag on open.

-      
TIOCFLAG_MDMBUF

-      
Set the termios(4) MDMBUF
-          flag on open.

-    

-    
This call sets the serial port state to that represented by
-        state. Not all serial ports may support this.

-  

-  

-    int *state

-  
Return the current state of the serial port as represented above in the
-      integer pointed to by state.

-

-

-

-

-

-
Two ioctls are maintained for backwards compatibility. They
-    provide methods to get and set the current line discipline, but are not
-    extensible.

-

-  

-    int *ldisc

-  
Change to the new line discipline pointed to by
-      ldisc. The old list of available line disciplines
-      are listed in
-      <sys/ttycom.h> and are:
-    

-    

-      
TTYDISC

-      
Termios interactive line discipline.

-      
TABLDISC

-      
Tablet line discipline.

-      
SLIPDISC

-      
Serial IP line discipline.

-      
PPPDISC

-      
Point to Point Protocol line discipline.

-      
STRIPDISC

-      
Starmode Radio IP line discipline.

-    

-  

-  

-    int *ldisc

-  
Return the current line discipline in the integer pointed to by
-      ldisc.

-

-

-

-

-
stty(1), ioctl(2),
-    tcgetattr(3), tcsetattr(3),
-    ttyaction(3), pty(4),
-    termios(4), ttys(5),
-    getty(8), linedisc(9)

-

-

-

-
A console typewriter device /dev/tty and
-    asynchronous communication interfaces /dev/tty[0-5]
-    first appeared in Version 1 AT&T UNIX.
-    Separate dial-out device files were implemented in SunOS 4. They were cloned
-    by Charles M. Hannum for NetBSD
-    1.4.

-

-

-
-  
-    
-    
-  
-
September 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/tun.4 4.html b/static/netbsd/man4/tun.4 4.html
deleted file mode 100644
index 964d3fe9..00000000
--- a/static/netbsd/man4/tun.4 4.html	
+++ /dev/null
@@ -1,174 +0,0 @@
-
-  
-    
-    
-    
-  
-
TUN(4)Device Drivers ManualTUN(4)

-

-

-

-
tun — tunnel
-    software network interface

-

-

-

-
pseudo-device tun

-

-

-

-
The tun interface is a software loopback
-    mechanism that can be loosely described as the network interface analog of
-    the pty(4), that is, tun does for
-    network interfaces what the pty driver does for
-    terminals.

-
The tun driver, like the
-    pty driver, provides two interfaces: an interface
-    like the usual facility it is simulating (a network interface in the case of
-    tun, or a terminal for pty),
-    and a character-special device “control” interface.

-
To use a tun device, the
-    administrator must first create the interface. This can be done by using the
-    ifconfig(8) create command, or via
-    the SIOCIFCREATE ioctl. An
-    () call on
-    /dev/tunN will also create a
-    network interface with the same unit number of that device if it doesn't
-    exist yet.

-
The network interfaces should be named
-    tun0,
-    tun1, etc. Each interface supports
-    the usual network-interface ioctl(2)s, such as
-    SIOCSIFADDR and
-    SIOCSIFNETMASK, and thus can be used with
-    ifconfig(8) like any other interface. At boot time, they
-    are POINTOPOINT interfaces, but this can be changed;
-    see the description of the control device, below. When the system chooses to
-    transmit a packet on the network interface, the packet can be read from the
-    control device (it appears there as “output”); writing a
-    packet to the control device generates an input packet on the network
-    interface, as if the (non-existent) hardware had just received it.

-
The tunnel device, normally
-    /dev/tunN, is exclusive-open (it
-    cannot be opened if it is already open) and is restricted to the super-user
-    (regardless of file system permissions). A
-    () call
-    will return an error (EHOSTDOWN) if the interface is
-    not “ready” (which means that the interface address has not
-    been set). Once the interface is ready, read() will
-    return a packet if one is available; if not, it will either block until one
-    is or return EAGAIN, depending on whether
-    non-blocking I/O has been enabled. If the packet is longer than is allowed
-    for in the buffer passed to read(), the extra data
-    will be silently dropped.

-
Packets can be optionally prepended with the
-    destination address as presented to the network interface output routine
-    (‘tunoutput’). The destination address
-    is in ‘struct sockaddr’ format. The
-    actual length of the prepended address is in the member
-    ‘sa_len’. The packet data follows
-    immediately. A write(2) call passes a packet in to be
-    “received” on the pseudo-interface. Each
-    () call
-    supplies exactly one packet; the packet length is taken from the amount of
-    data provided to write(). Writes will not block; if
-    the packet cannot be accepted for a transient reason (e.g., no buffer space
-    available), it is silently dropped; if the reason is not transient (e.g.,
-    packet too large), an error is returned. If “link-layer mode”
-    is on (see TUNSLMODE below),
-    the actual packet data must be preceded by a ‘struct
-    sockaddr’. The driver currently only inspects the
-    ‘sa_family’ field. The following
-    ioctl(2) calls are supported (defined in
-    ⟨net/if_tun.h⟩):

-

-  

-  
The argument should be a pointer to an int; this
-      sets the internal debugging variable to that value. What, if anything,
-      this variable controls is not documented here; see the source code.

-  

-  
The argument should be a pointer to an int; this
-      stores the internal debugging variable's value into it.

-  

-  
The argument should be a pointer to an int; its
-      value must be either IFF_POINTOPOINT or
-      IFF_BROADCAST (optionally
-      IFF_MULTICAST may be or'ed into the value). The
-      type of the corresponding tunn
-      interface is set to the supplied type. If the value is anything else, an
-      EINVAL error occurs. The interface must be down at
-      the time; if it is up, an EBUSY error occurs.

-  

-  
The argument should be a pointer to an int; a
-      non-zero value turns off “multi-af” mode and turns on
-      “link-layer” mode, causing packets read from the tunnel
-      device to be prepended with network destination address.

-  

-  
The argument should be a pointer to an int; the
-      ioctl sets the value to one if the device is in “multi-af”
-      mode, and zero otherwise.

-  

-  
The argument should be a pointer to an int; a
-      non-zero value turns off “link-layer” mode, and enables
-      “multi-af” mode, where every packet is preceded with a four
-      byte address family.

-  

-  
Turn non-blocking I/O for reads off or on, according as the argument
-      int's value is or isn't zero. (Writes are always
-      non-blocking.)

-  

-  
Turn asynchronous I/O for reads (i.e., generation of
-      SIGIO when data is available to be read) off or
-      on, according as the argument int's value is or
-      isn't zero.

-  

-  
If any packets are queued to be read, store the size of the first one into
-      the argument int; otherwise, store zero.

-  

-  
Set the process group to receive SIGIO signals,
-      when asynchronous I/O is enabled, to the argument
-      int value.

-  

-  
Retrieve the process group value for SIGIO signals
-      into the argument int value.

-

-
The control device also supports select(2) for
-    read; selecting for write is pointless, and always succeeds, since writes
-    are always non-blocking.

-
On the last close of the data device, by default, the interface is
-    brought down (as if with “ifconfig tunn
-    down”). All queued packets are thrown away.
-    If the interface is up when the data device is not open output packets are
-    always thrown away rather than letting them pile up.

-

-
-
When an application has opened the tun
-    character device the link is considered up, otherwise down. As such, it is
-    best to open the character device once connectivity has been established so
-    that Duplicate Address Detection, if applicable, can be performed. If
-    connectivity is lost, the character device should be closed.

-

-

-

-

-
ioctl(2), read(2),
-    select(2), write(2),
-    inet(4), intro(4),
-    ifconfig(8)

-

-

-

-
IPv6 support comes mostly from FreeBSD and
-    was added in NetBSD 4.0 by
-  

-  Rui Paulo ⟨rpaulo@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
September 27, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/twa.4 4.html b/static/netbsd/man4/twa.4 4.html
deleted file mode 100644
index 61f64793..00000000
--- a/static/netbsd/man4/twa.4 4.html	
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    
-    
-    
-  
-
TWA(4)Device Drivers ManualTWA(4)

-

-

-

-
twa — 3ware Apache
-    RAID controller driver

-

-

-

-
twa* at pci? dev ? function ?

-

-

-

-
The twa driver provides support for the
-    3ware Apache family of RAID controllers. Attached disk arrays are supported
-    by the ld driver.

-

-

-

-
intro(4), ld(4)

-

-

-

-
The twa driver first appeared in
-    NetBSD 3.1.

-

-

-

-
The twa driver was written by Vinod
-    Kashyap and was modified for inclusion in NetBSD by
-    Jordan Rhody
-    ⟨jordanr@spam.wasabisystems.com⟩.

-

-

-
-  
-    
-    
-  
-
November 6, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/twe.4 4.html b/static/netbsd/man4/twe.4 4.html
deleted file mode 100644
index 6d3a1851..00000000
--- a/static/netbsd/man4/twe.4 4.html	
+++ /dev/null
@@ -1,43 +0,0 @@
-
-  
-    
-    
-    
-  
-
TWE(4)Device Drivers ManualTWE(4)

-

-

-

-
twe — 3ware
-    Escalade RAID controller driver

-

-

-

-
twe* at pci? dev ? function ?

-

-

-

-
The twe driver provides support for the
-    3ware Escalade family of RAID controllers. Supported models include series
-    5000, 6000, 7000, and 8000.

-
Attached disk arrays are supported by the
-    ld driver.

-

-

-

-
intro(4), ld(4)

-

-

-

-
The twe driver first appeared in
-    NetBSD 1.5.3, and was based on the
-    FreeBSD driver of the same name.

-

-

-
-  
-    
-    
-  
-
May 10, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/txp.4 4.html b/static/netbsd/man4/txp.4 4.html
deleted file mode 100644
index 44262f6c..00000000
--- a/static/netbsd/man4/txp.4 4.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
TXP(4)Device Drivers ManualTXP(4)

-

-

-

-
txp — 3Com 3XP
-    Typhoon/Sidewinder (3CR990) Ethernet interface

-

-

-

-
txp* at pci? dev ? function ?

-

-

-

-
The txp interface provides access to the
-    10Mb/s and 100Mb/s Ethernet networks via the 3Com Typhoon/Sidewinder
-    chipset. This driver supports the following cards:

-

-
    
-  
  • 3Com 3CR990-TX-95
    • 
-  
  • 3Com 3CR990-TX-97
    • 
-  
  • 3Com 3CR990SVR95
    • 
-  
  • 3Com 3CR990SVR97
    • 
-

-
Basic Ethernet functions are provided as well as support for
-    vlan(4) tag removal and insertion assistance, receive
-    ip(4), tcp(4), and
-    udp(4) checksum offloading, and transmit
-    ip(4) checksum offloading. There is currently no support
-    for transmit tcp(4) or udp(4) checksum
-    offloading, tcp(4) segmentation, nor
-    ipsec(4) acceleration. Note that hardware checksumming is
-    only used when the interface is not in bridge(4) mode.

-
Each of the host's network addresses is specified at boot time
-    with an SIOCSIFADDR ioctl(2). The
-    txp interface employs the address resolution
-    protocol described in arp(4) to dynamically map between
-    Internet and Ethernet addresses on the local network.

-
When a txp interface is brought up, by
-    default, it will attempt to auto-negotiate the link speed and duplex mode.
-    The speeds, in order of attempt, are: 100Mb/s Full Duplex, 100Mb/s Half
-    Duplex, 10 Mb/s Full Duplex, and 10 Mb/s Half Duplex.

-
The txp supports several media types,
-    which are selected via the ifconfig(8) command. The
-    supported media types are:

-

-

-  
media autoselect

-  
Attempt to autoselect the media type (default)

-  
media 100baseTX mediaopt full-duplex

-  
Use 100baseTX, full duplex

-  
media 100baseTX [mediaopt half-duplex]

-  
Use 100baseTX, half duplex

-  
media 10baseT mediaopt full-duplex

-  
Use 10baseT, full duplex

-  
media 10baseT [mediaopt half-duplex]

-  
Use 10baseT, half duplex

-

-

-

-

-

-
arp(4), ifmedia(4),
-    inet(4), intro(4),
-    ip(4), netintro(4),
-    pci(4), tcp(4),
-    udp(4), vlan(4),
-    ifconfig(8)

-

-

-

-
The txp driver first appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
August 21, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/u3g.4 4.html b/static/netbsd/man4/u3g.4 4.html
deleted file mode 100644
index 71e27a47..00000000
--- a/static/netbsd/man4/u3g.4 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
U3G(4)Device Drivers ManualU3G(4)

-

-

-

-
u3g — USB support
-    for 3G datacards

-

-

-

-
To compile this driver into the kernel, place the following lines
-    in your kernel configuration file:

-
umodeswitch* at uhub? port
-  ?
-

-u3g* at uhub? port ?
-

-ucom* at u3g?

-

-

-

-
The u3g driver provides support for the
-    multiple USB-to-serial interfaces exposed by many 3G USB/PC Card modems.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
The u3g driver supports the following
-    adapters:

-

-
    
-  
  • Huawei E171
    • 
-  
  • Huawei E220 (E270?)
    • 
-  
  • Huawei EM770W
    • 
-  
  • Huawei Mobile
    • 
-  
  • Novatel MC950D
    • 
-  
  • NTT DOCOMO L-02C
    • 
-  
  • Option Globetrotter 3G
    • 
-  
  • Option Globetrotter 3G Fusion (only 3G part, not WLAN)
    • 
-  
  • Option Globetrotter 3G Fusion Quad (only 3G part, not WLAN)
    • 
-  
  • Option Globetrotter 3G Quad
    • 
-  
  • Vodafone Mobile Connect Card 3G
    • 
-

-
The supported 3G cards provide the necessary modem port for ppp,
-    pppd, or mpd connections as well as extra ports (depending on the specific
-    device) to provide other functions (diagnostic port, SIM toolkit port).

-

-

-

-
tty(4), ubsa(4),
-    ucom(4), usb(4)

-

-

-

-
The u3g driver appeared in
-    NetBSD 5.0. The ubsa(4) manual
-    page was modified for u3g by Andrea
-    Guzzo
-    <aguzzo@anywi.com> in
-    September 2008.

-

-

-

-
The u3g driver was written by
-    Andrea Guzzo
-    <aguzzo@anywi.com>.
-    Hardware for testing provided by AnyWi Technologies, Leiden, NL.

-

-

-
-  
-    
-    
-  
-
October 8, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/ualea.4 4.html b/static/netbsd/man4/ualea.4 4.html
deleted file mode 100644
index 11f27aee..00000000
--- a/static/netbsd/man4/ualea.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
UALEA(4)Device Drivers ManualUALEA(4)

-

-

-

-
ualea — USB
-    Araneus Alea I/II TRNG

-

-

-

-
ualea* at uhub? port ? configuration ? interface
-    ?

-

-

-

-
The ualea driver reads data generated
-    randomly by an Araneus Alea I/II device and adds it to the kernel entropy
-    pool.

-

-

-

-
rnd(4),
-    https://www.araneus.fi/products/alea2/en/

-

-

-

-
The ualea driver first appeared in
-    NetBSD 8.0.

-

-

-

-
Taylor R Campbell
-    <riastradh@NetBSD.org>

-

-

-

-
Destruction of an Alea II TRNG device with a consumer-grade
-    laundry washing machine is ineffective.

-

-

-
-  
-    
-    
-  
-
April 18, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/uark.4 4.html b/static/netbsd/man4/uark.4 4.html
deleted file mode 100644
index d4a6118e..00000000
--- a/static/netbsd/man4/uark.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
UARK(4)Device Drivers ManualUARK(4)

-

-

-

-
uark — Arkmicro
-    Technologies ARK3116 based USB serial adapter

-

-

-

-
uark* at uhub?
-  

-  ucom* at uark?

-

-

-

-
The uark driver supports Arkmicro
-    Technologies ARK3116 based serial adapters.

-
The following devices should work with the
-    uark driver:

-

-
HL USB-RS232
-HugePine USB-UART
-KQ-U8A Data Cable
-Skymaster USB to RS232

-

-

-

-

-
tty(4), ucom(4),
-    uhub(4), usb(4)

-

-

-

-
The uark device driver first appeared in
-    OpenBSD 4.0 and was ported to
-    NetBSD 6.0.

-

-

-

-
The uark driver was written by
-    Jonathan Gray ⟨jsg@openbsd.org⟩.

-

-

-

-
Setting hardware flow control is not currently supported. It is
-    not yet known how to ask the hardware to send a break.

-

-

-
-  
-    
-    
-  
-
May 30, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/uatp.4 3.html b/static/netbsd/man4/uatp.4 3.html
deleted file mode 100644
index 25a93e74..00000000
--- a/static/netbsd/man4/uatp.4 3.html	
+++ /dev/null
@@ -1,151 +0,0 @@
-
-  
-    
-    
-    
-  
-
UATP(4)Device Drivers ManualUATP(4)

-

-

-

-
uatp — USB Apple
-    trackpad driver

-

-

-

-
uatp* at uhidev? reportid ?
-  

-  wsmouse* at uatp? mux 0

-

-

-

-
The uatp driver provides support for the
-    USB trackpads found in Apple laptops since 2005, exposed through
-    wsmouse(4). Some USB Apple trackpads are standard USB HID
-    mice supported by ums(4), but uatp
-    supports more features. The following sysctl(8) variables
-    control behavior of USB Apple trackpads:

-

-  

-  
Bit mask of buttons to emulate when two fingers are on the trackpad while
-      the button is pressed.

-  

-  
Bit mask of buttons to emulate when three fingers are on the trackpad
-      while the button is pressed.

-  

-  
What to do when multiple fingers are moved on the trackpad. If set to 0,
-      ignore the input. If set to 1, move as if a single finger were at the mean
-      position of the fingers. If set to 2, scroll. Note that scrolling is
-      currently broken.

-  

-  
Number of sensor columns detecting the x positions of fingers on the
-      trackpad. The driver should detect this based on the model of hardware, so
-      you should not have to set this, and likewise for the x ratio and y
-      sensors and ratio.

-  

-  
Ratio of the number of sensor columns in the trackpad to the number of
-      distinct cursor x positions.

-  

-  
Number of sensor rows detecting the y positions of fingers on the
-      trackpad.

-  

-  
Ratio of the number of sensor rows in the trackpad to the number of
-      distinct cursor y positions.

-  

-  
Nonnegative integer giving a lower bound on the “pressure” a
-      sensor must report for the driver to recognize input from it.

-  

-  
Nonnegative integer to subtract from the “pressure” reported
-      by a sensor when averaging them to estimate the pressure of a single
-      finger.

-  

-  
If zero, palm detection is disabled. Otherwise, a positive integer giving
-      the number of consecutive sensors wide or high that will be interpreted as
-      a palm instead of a finger and therefore ignored.

-  

-  
 

-  

-  
 

-  

-  
When a finger moves on the trackpad, the new smoothed (cursor) position is
-      computed as a positive linear combination of the old raw (trackpad)
-      position, the old smoothed position, and the new raw position. The weights
-      of the linear combination are given by these sysctl knobs.

-  

-  
Threshold below which a difference in smoothed position will not be
-      reported as an input event to userland.

-  

-  
Positive integer by which a difference in smoothed position will be
-      multiplied before passing it as an input event to userland.

-  

-  
Positive integer by which a difference in smoothed position will be
-      divided, after multiplying it by the motion multiplier, before passing it
-      as an input event to userland.

-  

-  
Threshold above which to use the fast motion factors below.

-  

-  
Positive integer by which to multiply a large difference in smoothed
-      position.

-  

-  
Positive integer by which to divide a large difference in smoothed
-      position, after multiplying it by the fast motion multiplier.

-  

-  
Number of input packets before uatp reports motion
-      to userland.

-  

-  
Positive integer giving the number of milliseconds of a finger's contact
-      with the trackpad before it will not be considered a tap.

-  

-  
Positive integer giving the maximum number of milliseconds after a tap
-      before a second tap will keep the button down.

-  

-  
Bit mask of buttons that a one-finger tap will press.

-  

-  
Bit mask of buttons that a two-finger tap will press.

-  

-  
Bit mask of buttons that a three-finger tap will press.

-  

-  
Maximum distance in smoothed position that will be interpreted as a tap
-      instead of motion.

-

-

-

-

-
ums(4), wsmouse(4)

-

-

-

-
The uatp driver first appeared in
-    NetBSD 7.0.

-

-

-

-
The uatp driver was originally written by
-    Taylor R. Campbell
-    <riastradh@NetBSD.org>.

-

-

-

-
Sometimes, particularly when X starts up, the driver gets wedged
-    in an interrupt storm and does not reset the device. Setting
-    hw.uatpN.sensor_threshold to a large number, say
-    1000, and then back to its original value, can fix this.

-
Palm detection is not very robust.

-
Multi-touch scrolling is currently broken.

-
Pinch-to-zoom and other fancy multi-touch input is not
-    implemented.

-
On suspending and resuming, uatp detaches
-    and reattaches, and loses all sysctl settings in the process.

-
Do not submerge your uatp devices in
-    water: USB adenosine triphosphate is unstable in water, and will hydrolyze
-    to USB adenosine diphosphate and phosphate, which is a lower energy state
-    that makes your mouse narcoleptic in X.

-

-

-
-  
-    
-    
-  
-
August 4, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/uaudio.4 4.html b/static/netbsd/man4/uaudio.4 4.html
deleted file mode 100644
index 0b32d1c4..00000000
--- a/static/netbsd/man4/uaudio.4 4.html	
+++ /dev/null
@@ -1,96 +0,0 @@
-
-  
-    
-    
-    
-  
-
UAUDIO(4)Device Drivers ManualUAUDIO(4)

-

-

-

-
uaudio — USB audio
-    device driver

-

-

-

-
uaudio* at uhub?
-  

-  audio* at audiobus?

-

-

-

-
The uaudio driver provides support for USB
-    audio class devices.

-
A USB audio device consists of a number of components: input
-    terminals (e.g. USB digital input), output terminals (e.g. speakers), and a
-    number of units in between (e.g. volume control). The following types of
-    units are handled by the uaudio driver and are
-    accessible via the mixer (see audio(4)) interface:

-

-  

-  
A mixer has a number of inputs and one output. Each input has a control
-      that determines its volume in the output. The name of the control is
-      mixN-S,
-      where N is a number that identifies which mixer it
-      is and S which input.

-  

-  
A selector unit selects one of multiple audio sources such as mic-in and
-      line-in. The name of the control is
-      selN-S1S2S3...,
-      where N is a number that identifies which selector
-      unit it is and the sequence of Sn indicates
-      candidate units for the audio source.

-  

-  
A feature unit changes the sound in some way, like bass, treble, mute, or
-      volume. The name of the control is determined in a heuristic way. If the
-      unit changes the sound to a speaker output terminal, the names of the
-      controls may be outputs.speaker.bass,
-      outputs.speaker.treble,
-      outputs.speaker.mute,
-      outputs.speaker, or likewise.

-  

-  
A processing unit does one of a number of audio processing functions
-      (e.g., channel up-down mixing, Dolby ProLogic, or chorus effects). The
-      name of the on–off control is
-      proN.M-enable,
-      where N is a number that identifies which processing
-      unit it is and M which kind. Depending on the type
-      of processing unit there may be other controls as well.

-  

-  
An extension unit performs some unspecified audio processing The name of
-      the on–off control is
-      extN-enable,
-      where N is a number that identifies which processing
-      unit it is.

-

-
For more information the USB Audio class specification is
-    indispensable reading.

-

-

-

-
audio(4), usb(4)

-
USB Approved Class
-    Specification Documents,
-    http://www.usb.org/developers/docs/devclass_docs/.

-

-

-

-
The uaudio driver appeared in
-    NetBSD 1.5. Support for USB Audio Class 2.0 devices
-    appeared in NetBSD 11.0.

-

-

-

-
There is no support for multiple-endpoints audio stream, adaptive
-    recording, async playback, and TYPE-II/III formats.

-
There is the possibility that a device has multiple mixer items
-    which have the same name.

-

-

-
-  
-    
-    
-  
-
May 21, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/uberry.4 4.html b/static/netbsd/man4/uberry.4 4.html
deleted file mode 100644
index b508de14..00000000
--- a/static/netbsd/man4/uberry.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
UBERRY(4)Device Drivers ManualUBERRY(4)

-

-

-

-
uberry — USB
-    driver for the RIM BlackBerry phones

-

-

-

-
uberry* at uhub? port ?

-

-

-

-
The uberry driver provides support for the
-    original BlackBerry, the BlackBerry Pearl, the BlackBerry Pearl Duo, and
-    other models.

-
This is a stub driver that only allows the device to be charged
-    from the USB port. If the uberry driver attaches to
-    a device that has support for memory cards (such as the BlackBerry Pearl
-    series), the uberry driver will detach and the
-    device will be re-attached using the umass(4) driver.

-

-

-

-
umass(4), usb(4)

-

-

-

-
The uberry driver appeared in
-    NetBSD 5.0.

-

-

-
-  
-    
-    
-  
-
May 25, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/ubsa.4 4.html b/static/netbsd/man4/ubsa.4 4.html
deleted file mode 100644
index 15ae1a6a..00000000
--- a/static/netbsd/man4/ubsa.4 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
UBSA(4)Device Drivers ManualUBSA(4)

-

-

-

-
ubsa — USB support
-    for Belkin serial adapters

-

-

-

-
ubsa* at uhub?
-  

-  ucom* at ubsa?

-

-

-

-
The ubsa driver supports the following
-    adapters:

-

-

-

-  
Belkin F5U103

-  
 

-  
Belkin F5U120

-  
 

-  
e-Tek Labs Kwik232

-  
 

-  
GoHubs GoCOM232

-  
 

-  
Option N.V. Mobile Connect 3G datacard

-  
 

-  
Option N.V. GlobeTrotter Fusion Quad Lite UMTS/GPRS

-  
 

-  
Option N.V. GlobeTrotter Fusion Quad Lite 3D

-  
 

-  
Peracom single port serial adapter

-  
 

-

-

-

-

-

-
The ubsa driver provides support for the
-    USB-to-RS-232 Bridge chip used by a variety of serial adapters from Belkin
-    and other vendors. The bridge is also embedded into several UMTS/GPRS
-  cards.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The ubsa driver first appeared in
-    FreeBSD 5.0 and was ported to
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
February 10, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/ubsec.4 4.html b/static/netbsd/man4/ubsec.4 4.html
deleted file mode 100644
index 3948f625..00000000
--- a/static/netbsd/man4/ubsec.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
UBSEC(4)Device Drivers ManualUBSEC(4)

-

-

-

-
ubsec — Broadcom
-    and BlueSteel uBsec 5x0x crypto accelerator

-

-

-

-
ubsec* at pci? dev ? function ?

-

-

-

-
The ubsec driver supports cards containing
-    any of the following chips:

-

-

-  
Bluesteel 5501

-  
The original chipset, no longer made. This extremely rare unit was not
-      very fast, lacked an RNG, and had a number of other bugs.

-  
Broadcom BCM5801

-  
A BCM5805 without public key engine or random number generator.

-  
Broadcom BCM5802

-  
A slower version of the BCM5805.

-  
Broadcom BCM5805

-  
Faster version of Bluesteel 5601.

-  
Broadcom BCM5820

-  
64 bit version of the chip, and significantly more advanced.

-  
Broadcom BCM5821

-  
Faster version of the BCM5820. This is the chip found on the Sun Crypto
-      Accelerator 1000.

-  
Broadcom BCM5822

-  
Faster version of the BCM5820.

-  
Broadcom BCM5823

-  
Faster version of the BCM5822 that also supports AES.

-  
Broadcom BCM5825

-  
Faster PCI Express or PCI-X version of the chip.

-  
Broadcom BCM5860

-  
IPSec/SSL Security Processor that is faster and has more features.

-  
Broadcom BCM5861

-  
Faster version of the BCM5860.

-  
Broadcom BCM5862

-  
Faster version of the BCM5861.

-

-

-
The ubsec driver registers itself to
-    accelerate DES, Triple-DES, MD5, SHA1, MD5-HMAC, and SHA1-HMAC operations
-    for opencrypto(9), and thus for ipsec(4)
-    and crypto(4). The driver also supports acceleration of
-    AES-CBC with the BCM5823 or newer.

-
On those models which contain a public key engine (almost all of
-    the more recent ones), this feature is registered with the
-    crypto(4) subsystem.

-
On all models except the Bluesteel 5501 and Broadcom 5801, the
-    driver registers itself to provide random data to the
-    rnd(4) subsystem.

-

-

-

-
crypto(4), intro(4),
-    ipsec(4), rnd(4),
-    opencrypto(9)

-

-

-

-
The ubsec device driver appeared in
-    OpenBSD 2.8. The ubsec
-    device driver was imported to FreeBSD 5.0,
-    back-ported to FreeBSD 4.8, and subsequently
-    imported to NetBSD 2.0.

-

-

-

-
The BCM5801 and BCM5802 have not actually been tested.

-

-

-
-  
-    
-    
-  
-
June 13, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/ubt.4 4.html b/static/netbsd/man4/ubt.4 4.html
deleted file mode 100644
index e2fc7af4..00000000
--- a/static/netbsd/man4/ubt.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
UBT(4)Device Drivers ManualUBT(4)

-

-

-

-
ubt — USB
-    Bluetooth driver

-

-

-

-
ubt* at uhub? port ? configuration ? interface
-    ?

-

-

-

-
The ubt driver provides support for USB
-    Bluetooth dongles to the Bluetooth protocol stack.

-
USB Bluetooth dongles provide two interfaces, both of which the
-    ubt driver claims. The second interface is used for
-    Isochronous data and will have several alternate configurations regarding
-    bandwidth consumption, which can be set using the hw.ubtN.config
-    sysctl(8) variable. The number of alternate configurations
-    is indicated by the value in the hw.ubtN.alt_config variable, and the isoc
-    frame size for the current configuration is shown in the hw.ubtN.sco_rxsize
-    and hw.ubtN.sco_txsize variables.

-
By default, configuration 0 is selected, which means that no
-    bandwidth is used on the Isochronous interface and no SCO data can be sent.
-    Consult the Bluetooth USB specification at https://www.bluetooth.org/ for
-    complete instructions on setting bandwidth consumption. The following
-    extract may be useful as a general guidance though details may differ
-    between manufacturers.

-

-

-  
0

-  
No active voice channels

-  
1

-  
One voice channel with 8-bit encoding

-  
2

-  
Two voice channels with 8-bit encoding, or one voice channel with 16-bit
-      encoding.

-  
3

-  
Three voice channels with 8-bit encoding

-  
4

-  
Two voice channels with 16-bit encoding

-  
5

-  
Three voice channels with 16-bit encoding

-

-

-

-

-
bluetooth(4), uhub(4),
-    sysctl(8)

-

-

-

-
This ubt device driver was originally a
-    character device written by David Sainty and
-    Lennart Augustsson. It was rewritten to support
-    socket based Bluetooth access for NetBSD 4.0 by
-    Iain Hibbert.

-

-

-

-
Isochronous data is seemingly not well supported over USB in the
-    current system and to get SCO working, you may have to calculate the SCO
-    packet size that the stack will use. This is the sco_mtu value reported by
-    the btconfig(8) command, and when combined with the SCO
-    header (3 bytes) should fit exactly into an integer number of Isochronous
-    data frames where the frame size is indicated by the
-    ‘hw.ubtN.sco_txsize’ sysctl variable.

-
For example: I want one voice channel (which is all that is
-    supported, for now) so am using configuration #2, with a frame length of 17
-    bytes. This gives possible values of:

-

-
(17 * 1) - 3 = 14

-
(17 * 2) - 3 = 31

-
(17 * 3) - 3 = 48

-
(17 * 4) - 3 = 65

-
(17 * 5) - 3 = 82

-
etc.

-
btconfig(8) shows the maximum SCO payload as 64
-    bytes, so I am using the next smaller size of 48, to minimize the overhead
-    of the 3 header bytes.

-
The SCO packet size can be changed using the
-    ‘scomtu’ option to btconfig(8).

-
The failure mode is that the USB Bluetooth dongle locks up though
-    generally removal/reinsertion will clear the problem.

-

-

-

-
The Isochronous configuration can only be changed when the device
-    is not marked up.

-

-

-
-  
-    
-    
-  
-
August 27, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/uchcom.4 4.html b/static/netbsd/man4/uchcom.4 4.html
deleted file mode 100644
index 87ffe223..00000000
--- a/static/netbsd/man4/uchcom.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
UCHCOM(4)Device Drivers ManualUCHCOM(4)

-

-

-

-
uchcom — USB
-    support for WinChipHead CH341/CH340 serial adapters driver

-

-

-

-
uchcom* at uhub?
-  

-  ucom* at uchcom?

-

-

-

-
The uchcom driver supports the following
-    adapters:

-

-

-

-  
HL USB-RS232

-  
 

-

-

-

-

-

-
The uchcom driver provides support for the
-    WinChipHead CH341/CH340 USB-to-RS-232 Bridge chip.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The uchcom driver appeared in
-    NetBSD 5.0.

-

-

-

-
Actually, this chip seems unable to drive other than 8 data bits
-    and 1 stop bit line.

-

-

-
-  
-    
-    
-  
-
September 2, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/ucom.4 4.html b/static/netbsd/man4/ucom.4 4.html
deleted file mode 100644
index b35fb2eb..00000000
--- a/static/netbsd/man4/ucom.4 4.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
UCOM(4)Device Drivers ManualUCOM(4)

-

-

-

-
ucom — USB tty
-    support

-

-

-

-
ucom* at u3g?
-  

-  ucom* at uark?
-  

-  ucom* at ubsa?
-  

-  ucom* at uchcom?
-  

-  ucom* at uftdi?
-  

-  ucom* at ugensa?
-  

-  ucom* at uhmodem?
-  

-  ucom* at uipaq?
-  

-  ucom* at ukyopon?
-  

-  ucom* at umcs? portno ?
-  

-  ucom* at umct?
-  

-  ucom* at umodem?
-  

-  ucom* at uplcom?
-  

-  ucom* at uslsa?
-  

-  ucom* at uvisor? portno ?
-  

-  ucom* at uvscom?
-  

-  ucom* at uxrcom?

-

-

-

-
The ucom driver attaches to USB modems,
-    serial ports, and other devices that need to look like a tty. The
-    ucom driver shows a behaviour like a
-    tty(4). This means that normal programs such as
-    tip(1) or pppd(8) can be used to access
-    the device.

-
The portno locator can be used to decide
-    which port to use for device that have multiple external ports.

-
Note that while ucom supports the
-    (undocumented) pulse-per-second API normally used on conventional serial
-    ports, USB serial devices typically have a varying latency around 1 ms due
-    to the USB frame structure.

-
The ttyXX devices are traditional dial-in devices; the dtyXX
-    devices are used for dial-out. (See tty(4).)

-

-

-

-

-  
/dev/dtyU?

-  
 

-  
/dev/ttyU?

-  
 

-

-

-

-

-
tty(4), u3g(4),
-    uark(4), ubsa(4),
-    uchcom(4), uftdi(4),
-    ugensa(4), uhmodem(4),
-    uipaq(4), ukyopon(4),
-    umcs(4), umct(4),
-    umodem(4), uplcom(4),
-    usb(4), uslsa(4),
-    uvisor(4), uvscom(4),
-    uxrcom(4)

-

-

-

-
The ucom driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
April 12, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/ucycom.4 3.html b/static/netbsd/man4/ucycom.4 3.html
deleted file mode 100644
index 2e0ea479..00000000
--- a/static/netbsd/man4/ucycom.4 3.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
UCYCOM(4)Device Drivers ManualUCYCOM(4)

-

-

-

-
ucycom — USB
-    support for Cypress microcontroller based serial adapters

-

-

-

-
ucycom at uhidev? reportid ?

-

-

-

-
The ucycom driver supports the following
-    adapters:

-

-

-

-  
Various low-cost USB-RS232 adapters

-  
 

-  
Delmore Earthmate GPS receiver

-  
 

-

-

-

-

-

-
The ucycom driver provides support for
-    Cypress microcontroller based USB-to-RS-232 adapter. The
-    ucycom driver shows a behaviour like a
-    tty(4). This means that normal programs such as
-    tip(1) or pppd(8) can be used to access
-    the device.

-

-

-

-

-  
/dev/ttyY?

-  
 

-

-

-

-

-
uhidev(4), usb(4)

-

-

-

-
The ucycom driver appeared in
-    NetBSD 4.0.

-

-

-
-  
-    
-    
-  
-
July 16, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/udav.4 4.html b/static/netbsd/man4/udav.4 4.html
deleted file mode 100644
index 3ee0bcc3..00000000
--- a/static/netbsd/man4/udav.4 4.html	
+++ /dev/null
@@ -1,76 +0,0 @@
-
-  
-    
-    
-    
-  
-
UDAV(4)Device Drivers ManualUDAV(4)

-

-

-

-
udav — Davicom
-    DM9601 USB Ethernet driver

-

-

-

-
udav* at uhub?
-  

-  ukphy* at mii?

-

-

-

-
The udav driver supports the following
-    adapters:

-

-

-

-  
Corega FEther USB-TXC

-  
 

-  
ShanTou ST268 USB NIC

-  
 

-  
ShanTou ADM8515

-  
 

-  
SUNRISING SR9600 Ethernet

-  
 

-

-

-

-

-

-
The udav driver provides support for USB
-    Ethernet adapters based on the Davicom DM9601 chipset.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), netintro(4),
-    usb(4), usbnet(4),
-    ifconfig(8)

-
Davicom DM9601 data
-    sheet,
-    http://www.davicom.com.tw/big5/download/Data%20Sheet/DM9601-DS-F01-062202s.pdf.

-

-

-

-
The udav device driver first appeared in
-    NetBSD 2.0.

-

-

-

-
The udav driver was written by
-    Shingo WATANABE
-  ⟨nabe@nabechan.org⟩.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/udl.4 4.html b/static/netbsd/man4/udl.4 4.html
deleted file mode 100644
index c894a16d..00000000
--- a/static/netbsd/man4/udl.4 4.html	
+++ /dev/null
@@ -1,71 +0,0 @@
-
-  
-    
-    
-    
-  
-
UDL(4)Device Drivers ManualUDL(4)

-

-

-

-
udl — DisplayLink
-    DL-1x0/1x5 USB display device driver

-

-

-

-
udl* at uhub?
-  

-  wsdisplay* at udl?

-

-

-

-
The udl driver provides support for
-    DisplayLink DL-1x0/1x5 based USB LCD screens, docks, and display
-  adapters.

-
The following devices are supported:

-

-
    
-  
  • Buffalo GX-DVI/U2B
    • 
-  
  • Century Japan Plus One LCD-8000U
    • 
-  
  • Century Japan Plus One LCD-4300U
    • 
-  
  • DisplayLink DVI adapter
    • 
-  
  • HP Docking Station
    • 
-  
  • HP USB DVI (NL571)
    • 
-  
  • IOGEAR DVI GUC2020
    • 
-  
  • IO-DATA USB-RGB
    • 
-  
  • IO-DATA LCD-USB7X
    • 
-  
  • IO-DATA LCD-USB10XB-T
    • 
-  
  • Lenovo ThinkVision LT1421
    • 
-  
  • Lilliput UM-70
    • 
-  
  • Logitec LDE-WX015U
    • 
-  
  • Nanovision MiMo
    • 
-  
  • Polaris2 USB dock
    • 
-  
  • Rextron DVI adapter
    • 
-  
  • Samsung LD220
    • 
-  
  • Samsung LD190
    • 
-  
  • Samsung U70
    • 
-  
  • StarTech CONV-USB2DVI
    • 
-  
  • Sunweit USB to DVI adapter
    • 
-  
  • VideoHome NBdock1920
    • 
-

-

-

-

-
The udl device driver appeared in
-    OpenBSD 4.6 and NetBSD
-  6.0.

-

-

-

-
The udl driver was written by
-    Marcus Glocker for OpenBSD,
-    and ported to NetBSD with many modifications by
-    Naoki Fukaumi.

-

-

-
-  
-    
-    
-  
-
July 10, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/udp.4 4.html b/static/netbsd/man4/udp.4 4.html
deleted file mode 100644
index 71e6b56a..00000000
--- a/static/netbsd/man4/udp.4 4.html	
+++ /dev/null
@@ -1,112 +0,0 @@
-
-  
-    
-    
-    
-  
-
UDP(4)Device Drivers ManualUDP(4)

-

-

-

-
udp — Internet
-    User Datagram Protocol

-

-

-

-
#include
-    <sys/socket.h>
-  

-  #include <netinet/in.h>

-
int
-  

-  socket(AF_INET,
-    SOCK_DGRAM,
-    0);

-
int
-  

-  socket(AF_INET6,
-    SOCK_DGRAM,
-    0);

-

-

-

-
UDP is a simple, unreliable datagram protocol which is used to
-    support the SOCK_DGRAM abstraction for the Internet
-    protocol family. UDP sockets are connectionless, and are normally used with
-    the sendto(2) and recvfrom(2) calls,
-    though the connect(2) call may also be used to fix the
-    destination for future packets (in which case the recv(2)
-    or read(2) and send(2) or
-    write(2) system calls may be used).

-
UDP address formats are identical to those used by TCP. In
-    particular UDP provides a port identifier in addition to the normal Internet
-    address format. Note that the UDP port space is separate from the TCP port
-    space (i.e. a UDP port may not be “connected” to a TCP port).
-    In addition broadcast packets may be sent (assuming the underlying network
-    supports this) by using a reserved “broadcast address”; this
-    address is network interface dependent.

-
There are two UDP-level
-    setsockopt(2)/getsockopt(2) options.
-    UDP_OPTIONS may be used to change the default
-    behavior of the socket. For example:

-

-
setsockopt(s, IPPROTO_UDP, UDP_OPTIONS, NULL, 0);

-

-
The UDP_ENCAP option can be used to
-    encapsulate ESP packets in UDP. There is one valid encapsulation option:
-    UDP_ENCAP_ESPINUDP from RFC3948 defined in
-    <netinet/udp.h>.

-
Options at the IP transport level may be used with UDP; see
-    ip(4) or ip6(4).

-

-

-

-
A socket operation may fail with one of the following errors
-    returned:

-

-  
[EADDRINUSE]

-  
when an attempt is made to create a socket with a port which has already
-      been allocated;

-  
[EADDRNOTAVAIL]

-  
when an attempt is made to create a socket with a network address for
-      which no network interface exists.

-  
[EISCONN]

-  
when trying to establish a connection on a socket which already has one,
-      or when trying to send a datagram with the destination address specified
-      and the socket is already connected;

-  
[ENOBUFS]

-  
when the system runs out of memory for an internal data structure;

-  
[ENOTCONN]

-  
when trying to send a datagram, but no destination address is specified,
-      and the socket hasn't been connected;

-

-

-

-

-
getsockopt(2), recv(2),
-    send(2), socket(2),
-    inet(4), inet6(4),
-    intro(4), ip(4),
-    ip6(4), rfc6056(7),
-    sysctl(7)

-
User Datagram Protocol,
-    RFC, 768,
-    August 28, 1980.

-
Requirements for Internet Hosts
-    — Communication Layers, RFC,
-    1122, October
-  1989.

-

-

-

-
The udp protocol appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
May 31, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/udsbr.4 4.html b/static/netbsd/man4/udsbr.4 4.html
deleted file mode 100644
index 5442def8..00000000
--- a/static/netbsd/man4/udsbr.4 4.html	
+++ /dev/null
@@ -1,45 +0,0 @@
-
-  
-    
-    
-    
-  
-
UDSBR(4)Device Drivers ManualUDSBR(4)

-

-

-

-
udsbr — support
-    for D-Link DSB-R100 USB radio

-

-

-

-
udsbr* at uhub?
-  

-  radio* at udsbr?

-

-

-

-
The udsbr driver provides support for the
-    D-Link DSB-R100 USB radio.

-
The device is accessed through the radio(4)
-    driver.

-
The DSB-R100 is a rather poor radio and the only feedback that you
-    can get from the radio is if it has a stereo signal or not.

-

-

-

-
radio(4), usb(4)

-

-

-

-
The udsbr driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
January 2, 2002NetBSD 10.1

diff --git a/static/netbsd/man4/uep.4 4.html b/static/netbsd/man4/uep.4 4.html
deleted file mode 100644
index 8435f8d0..00000000
--- a/static/netbsd/man4/uep.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
UEP(4)Device Drivers ManualUEP(4)

-

-

-

-
uep — USB eGalax
-    Touchpanel

-

-

-

-
uep* at uhub? port ?
-  

-  wsmouse* at uep?

-

-

-

-
The uep driver provides support for USB
-    touchpanel controllers by eGalax. Access to panel events is through the
-    wsmouse(4) driver.

-

-

-

-
usb(4), wsmouse(4)

-

-

-

-
The uep driver was written by Tyler C.
-    Sarna for NetBSD. The uep
-    driver appeared in NetBSD 3.0.

-

-

-

-
Calibration is only possible at compile time. Also, not all
-    NetBSD-supplied X servers support the absolute
-    position events it generates.

-

-

-
-  
-    
-    
-  
-
December 4, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/uftdi.4 4.html b/static/netbsd/man4/uftdi.4 4.html
deleted file mode 100644
index 0b2f2cb8..00000000
--- a/static/netbsd/man4/uftdi.4 4.html	
+++ /dev/null
@@ -1,134 +0,0 @@
-
-  
-    
-    
-    
-  
-
UFTDI(4)Device Drivers ManualUFTDI(4)

-

-

-

-
uftdi — USB
-    support for serial adapters based on the FT8U100AX and FT8U232AM

-

-

-

-
uftdi* at uhub?
-  

-  ucom* at uftdi?

-

-

-

-
The uftdi driver provides support for
-    various serial adapters based on the FTDI USB UART IC family. Supported chip
-    models are FT8U100AX, FT8U232AM, FT232BM, FT232R, dual channel FT2232D, dual
-    channel FT2232H, and quad channel FT4232H.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
The uftdi driver supports the following
-    adapters:

-

-

-

-  
B&B Electronics uLinks RS-422/485

-  
 

-  
Brainboxes US serial converter range

-  
 

-  
Buffalo BSUSRC06

-  
 

-  
CableCreation CD0487

-  
 

-  
Coastal ChipWorks TNC-X

-  
 

-  
Crystalfontz CFA-631 LCD

-  
 

-  
Crystalfontz CFA-632 LCD

-  
 

-  
Crystalfontz CFA-633 LCD

-  
 

-  
Crystalfontz CFA-634 LCD

-  
 

-  
Crystalfontz CFA-635 LCD

-  
 

-  
CTI USB-485-Mini and and USB-Nano-485

-  
 

-  
Falcom Samba 55/56 GSM/GPRS modem

-  
 

-  
Falcom Twist GSM/GPRS modem

-  
 

-  
Future Technology Devices DB9

-  
 

-  
Future Technology Devices IC

-  
 

-  
Future Technology Devices KW

-  
 

-  
Future Technology Devices RS232

-  
 

-  
Future Technology Devices Y6

-  
 

-  
Future Technology Devices Y8

-  
 

-  
Future Technology Devices Y9

-  
 

-  
Future Technology Devices YS

-  
 

-  
Gearmo USA-FTDI4X

-  
 

-  
GlobalScale Technogogies SheevaPlug and OpenRD

-  
 

-  
HP USB-Serial adapter shipped with some HP laptops

-  
 

-  
Inland UAS111

-  
 

-  
Intrepid Control Systems NeoVI Blue

-  
 

-  
Intrepid Control Systems ValueCAN

-  
 

-  
Matrix Orbital LK/VK/PK202-24 LCD

-  
 

-  
Matrix Orbital LK/VK204-24 LCD

-  
 

-  
Matrix Orbital MX2/MX3/MX6 Series

-  
 

-  
Matrix Orbital MX4/MX5 Series LCD

-  
 

-  
QVS USC-1000

-  
 

-  
RATOC Systems REX-USB60F

-  
 

-  
Robot Electronics USB to I2C Communications Module

-  
 

-  
RT Systems Inc. CT57A Radio Cable

-  
 

-  
Sealevel Systems USB-Serial adapter

-  
 

-  
SIIG US2308 Serial

-  
 

-  
Telldus Tellstick and Tellstick Duo

-  
 

-  
VScom USB-COM Mini

-  
 

-

-

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The uftdi driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
November 11, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/ug.4 4.html b/static/netbsd/man4/ug.4 4.html
deleted file mode 100644
index b4456417..00000000
--- a/static/netbsd/man4/ug.4 4.html	
+++ /dev/null
@@ -1,157 +0,0 @@
-
-  
-    
-    
-    
-  
-
UG(4)Device Drivers ManualUG(4)

-

-

-

-
ug — Abit uGuru
-    system hardware monitor

-

-

-

-
ug* at acpi?
-  

-  ug0 at isa? port 0xe0

-

-

-

-
The ug driver provides support for the
-    Abit uGuru hardware monitor to be used with the envsys(4)
-    interface.

-
The ug driver has 19 sensors:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uKCPU Temp
uKSystem Temp
uKPWN Temp
uV DCCore voltage
uV DCDDRVdd
uV DCDDRVtt
uV DCNBVdd
uV DCSBVdd
uV DCHTVdd
uV DCAGPVdd
uV DCVdd5V
uV DCVdd3V3
uV DCVdd5VSB
uV DCVdd3VDual
RPMCPU Fan
RPMNB Fan
RPMSYS Fan
RPMAUX Fan 1
RPMAUX Fan 2

-

-

-

-
acpi(4), envsys(4),
-    envstat(8)

-

-

-

-
The ug driver first appeared in
-    NetBSD 4.0.

-

-

-

-
The ug driver was written by
-    Mihai Chelaru
-    <kefren@netbsd.ro>.

-

-

-

-
Interrupt support is unimplemented.

-

-

-
-  
-    
-    
-  
-
May 8, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/ugen.4 3.html b/static/netbsd/man4/ugen.4 3.html
deleted file mode 100644
index 709152ba..00000000
--- a/static/netbsd/man4/ugen.4 3.html	
+++ /dev/null
@@ -1,331 +0,0 @@
-
-  
-    
-    
-    
-  
-
UGEN(4)Device Drivers ManualUGEN(4)

-

-

-

-
ugen — USB generic
-    device support

-

-

-

-
ugen* at uhub? flags N
-  

-  ugen* at uhub? vendor V product P flags 1
-  

-  ugenif* at uhub? vendor V product P configuration C interface
-    I
-  

-  ugenif* at uhub? vendor V product P configuration C interface
-    I flags 1

-

-

-

-
The ugen driver provides support for all
-    USB devices that do not have a special driver. It supports access to all
-    parts of the device, but not in a way that is as convenient as a special
-    purpose driver.

-
Normally the ugen driver is used when no
-    other driver attaches to a device. If “flags 1” is specified,
-    the ugen will instead attach with a very high
-    priority and always be used. Together with the
-    vendor and product locators
-    this can be used to force the ugen driver to be used
-    for a certain device.

-
The ‘ugenif’ form of attachment can be
-    used to “steal” only one interface from some device for use by
-    the ugen driver. Most likely you want to explicitly
-    specify at least vendor, product and interface with this form, as otherwise
-    the ugen driver would capture all of your
-    usb devices. If “flags 1” is
-    specified, the ‘ugenif’ form will match at the lowest
-    priority, thus allowing it to match only otherwise unclaimed interfaces.
-    : You have to be
-    extremely careful, when using this form, as the attached
-    ugen driver has access to all of the device and can
-    easily interfere with the driver(s) used for the other interface(s).

-
As an example of this second form of attachment there are various
-    debugging boards available based on some FTDI chip, where one interface is
-    used for JTAG debugging and the other is used as a serial interface. In this
-    case you want to attach the ugen driver to interface
-    0 of this particular board identified by vendor and
-    product while letting uftdi(4)
-    together with ucom(4) to attach at interface 1.

-
There can be up to 127 USB devices connected to a USB bus. Each
-    USB device can have up to 16 endpoints. Each of these endpoints will
-    communicate in one of four different modes: control, isochronous, bulk, or
-    interrupt. Each of the endpoints will have a different device node. The four
-    least significant bits in the minor device number determines which endpoint
-    the device accesses and the rest of the bits determines which USB
-  device.

-
If an endpoint address is used both for input and output the
-    device can be opened for both read or write.

-
To find out what endpoints exist there are a series of
-    ioctl(2) operations on the control endpoint that return
-    the USB descriptors of the device, configurations, interfaces, and
-    endpoints.

-
The control transfer mode can only happen on the control endpoint
-    which is always endpoint 0. The control endpoint accepts requests and may
-    respond with an answer to such requests. Control requests are issued by
-    ioctl(2) calls.

-
The bulk transfer mode can be in or out depending on the endpoint.
-    To perform IO on a bulk endpoint read(2) and
-    write(2) should be used. All IO operations on a bulk
-    endpoint are normally unbuffered. The
-    USB_SET_BULK_RA and
-    USB_SET_BULK_WB ioctl(2) calls
-    enable read-ahead and write-behind buffering, respectively. This buffering
-    supports fixed-sized USB transfers and is intended for devices with regular
-    and continuing data transfers. When read-ahead or write-behind are enabled,
-    the file descriptor may be set to use non-blocking IO.

-
When in a read-ahead/writeback mode, select(2)
-    for read and write operates normally, returning true if there is data in the
-    read buffer and space in the write buffer, respectively. When not,
-    select(2) always returns true, because there is no way to
-    predict how the device will respond to a read or write request.

-
The interrupt transfer mode can be in or out depending on the
-    endpoint. To perform IO on an interrupt endpoint read(2)
-    and write(2) should be used. A moderate amount of
-    buffering is done by the driver.

-
All endpoints handle the following ioctl(2)
-    calls:

-

-

-  

-    (int)

-  
Allow short read transfer. Normally a transfer from the device which is
-      shorter than the request specified is reported as an error.

-  

-    (int)

-  
Set the timeout on the device operations, the time is specified in
-      milliseconds. The value 0 is used to indicate that there is no
-    timeout.

-

-
The control endpoint (endpoint 0) handles the following
-    ioctl(2) calls:

-

-

-  

-    (int)

-  
Get the device configuration number.

-  

-    (int)

-  
Set the device into the given configuration number.
-    
This operation can only be performed when the control endpoint
-        is the sole open endpoint.

-  

-  

-    (struct usb_alt_interface)

-  
Get the alternative setting number for the interface with the given index.
-      The config_index is ignored in this call.
-    

-    
struct usb_alt_interface {
-	int	uai_config_index;
-	int	uai_interface_index;
-	int	uai_alt_no;
-};

-    

-  

-  

-    (struct usb_alt_interface)

-  
Set the alternative setting to the given number in the interface with the
-      given index. The uai_config_index is ignored in
-      this call.
-    
This operation can only be performed when no endpoints for the
-        interface are open.

-  

-  

-    (struct usb_alt_interface)

-  
Return the number of different alternate settings in the
-      uai_alt_no field.

-  

-    (usb_device_descriptor_t)

-  
Return the device descriptor.

-  

-    (struct usb_config_desc)

-  
Return the descriptor for the configuration with the given index. For
-      convenience the current configuration can be specified by
-      USB_CURRENT_CONFIG_INDEX.
-    

-    
struct usb_config_desc {
-	int	ucd_config_index;
-	usb_config_descriptor_t ucd_desc;
-};

-    

-  

-  

-    (struct usb_interface_desc)

-  
Return the interface descriptor for an interface specified by its
-      configuration index, interface index, and alternative index. For
-      convenience the current alternative can be specified by
-      USB_CURRENT_ALT_INDEX.
-    

-    
struct usb_interface_desc {
-	int	uid_config_index;
-	int	uid_interface_index;
-	int	uid_alt_index;
-	usb_interface_descriptor_t uid_desc;
-};

-    

-  

-  

-    (struct usb_endpoint_desc)

-  
Return the endpoint descriptor for the endpoint specified by its
-      configuration index, interface index, alternative index, and endpoint
-      index.
-    

-    
struct usb_endpoint_desc {
-	int	ued_config_index;
-	int	ued_interface_index;
-	int	ued_alt_index;
-	int	ued_endpoint_index;
-	usb_endpoint_descriptor_t ued_desc;
-};

-    

-  

-  

-    (struct usb_full_desc)

-  
Return all the descriptors for the given configuration.
-    

-    
struct usb_full_desc {
-	int	ufd_config_index;
-	u_int	ufd_size;
-	u_char	*ufd_data;
-};

-    

-    The ufd_data field should point to a memory area of
-      the size given in the ufd_size field. The proper
-      size can be determined by first issuing a
-      USB_GET_CONFIG_DESC and inspecting the
-      wTotalLength field.

-  

-    (struct usb_string_desc)

-  
Get a string descriptor for the given language id and string index.
-    

-    
struct usb_string_desc {
-	int	usd_string_index;
-	int	usd_language_id;
-	usb_string_descriptor_t usd_desc;
-};

-    

-  

-  

-  
Send a USB request to the device on the control endpoint. Any data sent
-      to/from the device is located at data. The size of
-      the transferred data is determined from the
-      request. The ucr_addr
-      field is ignored in this call. The ucr_flags field
-      can be used to flag that the request is allowed to be shorter than the
-      requested size, and the ucr_actlen field will
-      contain the actual size on completion.
-    

-    
struct usb_ctl_request {
-	int	ucr_addr;
-	usb_device_request_t ucr_request;
-	void	*ucr_data;
-	int	ucr_flags;
-#define USBD_SHORT_XFER_OK	0x04	/* allow short reads */
-	int	ucr_actlen;		/* actual length transferred */
-};

-    

-    This is a dangerous operation in that it can perform arbitrary operations on
-      the device. Some of the most dangerous (e.g., changing the device address)
-      are not allowed.

-  

-    (struct usb_device_info)

-  
Get an information summary for the device. This call will not issue any
-      USB transactions.

-

-
Bulk endpoints handle the following ioctl(2)
-    calls:

-

-

-  

-    (int)

-  
Enable or disable bulk read-ahead. When enabled, the driver will begin to
-      read data from the device into a buffer, and will perform reads from the
-      device whenever there is room in the buffer. The read(2)
-      call will read data from this buffer, blocking if necessary until there is
-      enough data to read the length of data requested. The buffer size and the
-      read request length can be set by the
-      USB_SET_BULK_RA_OPT ioctl(2)
-      call.

-  

-    (int)

-  
Enable or disable bulk write-behind. When enabled, the driver will buffer
-      data from the write(2) call before writing it to the
-      device, enabling the write(2) call to return
-      immediately. write(2) will block if there is not enough
-      room in the buffer for all the data. The buffer size and the write request
-      length can be set by the USB_SET_BULK_WB_OPT
-      ioctl(2) call.

-  

-    (struct usb_bulk_ra_wb_opt)

-  
Set the size of the buffer and the length of the read requests used by the
-      driver when bulk read-ahead is enabled. The changes do not take effect
-      until the next time bulk read-ahead is enabled. Read requests are made for
-      the length specified, and the host controller driver (i.e.,
-      ehci(4), ohci(4), and
-      uhci(4)) will perform as many bus transfers as required.
-      If transfers from the device should be smaller than the maximum length,
-      ra_wb_request_size must be set to the required
-      length.
-    

-    
struct usb_bulk_ra_wb_opt {
-	u_int	ra_wb_buffer_size;
-	u_int	ra_wb_request_size;
-};

-    

-  

-  

-    (struct usb_bulk_ra_wb_opt)

-  
Set the size of the buffer and the length of the write requests used by
-      the driver when bulk write-behind is enabled. The changes do not take
-      effect until the next time bulk write-behind is enabled.

-

-
Note that there are two different ways of addressing
-    configurations, interfaces, alternatives, and endpoints: by index or by
-    number. The index is the ordinal number (starting from 0) of the descriptor
-    as presented by the device. The number is the respective number of the
-    entity as found in its descriptor. Enumeration of descriptors use the index,
-    getting and setting typically uses numbers.

-
Example: All endpoints (except the control endpoint) for the
-    current configuration can be found by iterating the
-    interface_index from 0 to
-    config_desc->bNumInterface-1 and for each of
-    these iterating the endpoint_index from 0 to
-    interface_desc->bNumEndpoints. The
-    config_index should set to
-    USB_CURRENT_CONFIG_INDEX and
-    alt_index should be set to
-    USB_CURRENT_ALT_INDEX.

-

-

-

-

-  
/dev/ugenN.EE

-  
Endpoint EE of device
-    N.

-

-

-

-

-
usb(4)

-

-

-

-
The ugen driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 25, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/ugensa.4 4.html b/static/netbsd/man4/ugensa.4 4.html
deleted file mode 100644
index c63906f2..00000000
--- a/static/netbsd/man4/ugensa.4 4.html	
+++ /dev/null
@@ -1,105 +0,0 @@
-
-  
-    
-    
-    
-  
-
UGENSA(4)Device Drivers ManualUGENSA(4)

-

-

-

-
ugensa — USB
-    generic serial adapter

-

-

-

-
ugensa* at uhub?
-  

-  ucom* at ugensa?

-

-

-

-
The ugensa driver supports the following
-    adapters (or their USB device portion, for adaptors that contain a USB host
-    controller, hub and a USB device):

-

-

-

-  
Airprime PC5220

-  
 

-  
Novatel FlexPak GPS receiver

-  
 

-  
Qualcom CDMA MSM (found in Kyocera KPC650 EVDO interface)

-  
 

-  
Qualcom Inc. CDMA AC8700 (found in the ZTE 1x EVDO interface)

-  
 

-  
Sierra AirCard 580

-  
 

-  
Sierra AirCard 595

-  
 

-  
Sierra AirCard 875 [not tested]

-  
 

-  
Sierra Wireless EM5625 [not tested]

-  
 

-  
Sierra Wireless MC5720 [not tested]

-  
 

-  
Sierra Wireless MC5725 [not tested]

-  
 

-  
Sierra Wireless MC8755 [not tested]

-  
 

-  
Sierra Wireless MC8755 [not tested]

-  
 

-  
Sierra Wireless MC8755 [not tested]

-  
 

-  
Sierra Wireless MC8765 [not tested]

-  
 

-  
Sierra Wireless MC8775 [not tested]

-  
 

-  
Novatel Wireless Merlin CDMA (found in Verizon V620) [not tested]

-  
 

-  
Novatel ExpressCard [not tested]

-  
 

-  
Novatel Wireless S720 [not tested]

-  
 

-  
Novatel Ovation U720 [not tested]

-  
 

-  
Novatel Merlin XU870 HSDPA ExpressCard [not tested]

-  
 

-  
Novatel Merlin ES620 [not tested]

-  
 

-  
Dell/Novatel Wireless HDSPA modem

-  
 

-  
Dell W5500 HDSPA modem [not tested]

-  
 

-  
AnyDATA ADU-E500A [not tested]

-  
 

-  
Linux's USB 3.0 debug port serial communication

-  
 

-

-

-

-

-

-
The ugensa driver provides support for the
-    USB-to-RS-232 Bridge chip used by various vendors.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The ugensa driver first appeared in
-    NetBSD 3.0.

-

-

-
-  
-    
-    
-  
-
July 4, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/uha.4 4.html b/static/netbsd/man4/uha.4 4.html
deleted file mode 100644
index 7725bf43..00000000
--- a/static/netbsd/man4/uha.4 4.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
UHA(4)Device Drivers ManualUHA(4)

-

-

-

-
uha — Ultrastor
-    SCSI bus adapter for ISA/EISA bus

-

-

-

-
uha0 at isa? port 0x330 irq ? drq ?
-  

-  uha* at eisa? slot ? irq ?
-  

-  scsibus* at uha?

-

-

-

-
The uha driver provides support for the
-    following SCSI adapters:

-

-

-

-  
Ultrastor ISA 14f

-  
 

-  
Ultrastor EISA 24f

-  
 

-  
Ultrastor ISA 34f

-  
 

-

-

-

-

-

-
cd(4), ch(4),
-    eisa(4), intro(4),
-    isa(4), scsi(4),
-    sd(4), st(4)

-

-

-
-  
-    
-    
-  
-
November 29, 1994NetBSD 10.1

diff --git a/static/netbsd/man4/uhci.4 4.html b/static/netbsd/man4/uhci.4 4.html
deleted file mode 100644
index 9ce90196..00000000
--- a/static/netbsd/man4/uhci.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
UHCI(4)Device Drivers ManualUHCI(4)

-

-

-

-
uhci — USB
-    Universal Host Controller driver

-

-

-

-
uhci* at cardbus? function ?
-  

-  uhci* at pci? dev ? function ?
-  

-  usb* at uhci?

-

-

-

-
The uhci driver provides support for USB
-    Universal Host Controller Interface.

-

-

-

-
cardbus(4), pci(4),
-    usb(4)

-

-

-

-
The uhci driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
July 24, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/uhid.4 3.html b/static/netbsd/man4/uhid.4 3.html
deleted file mode 100644
index cad91074..00000000
--- a/static/netbsd/man4/uhid.4 3.html	
+++ /dev/null
@@ -1,131 +0,0 @@
-
-  
-    
-    
-    
-  
-
UHID(4)Device Drivers ManualUHID(4)

-

-

-

-
uhid — USB generic
-    HID support

-

-

-

-
uhid* at uhidev? reportid ? flags N

-

-

-

-
The uhid driver provides support for all
-    HID (Human Interface Device) interfaces in USB devices that do not have a
-    special driver.

-
Normally the uhid driver is used when no
-    other HID driver attaches to a device. If “flags 1” is
-    specified, the uhid driver will instead attach with
-    a very high priority and always be used. Together with the
-    vendor and product locators
-    on the uhidev(4) driver this can be used to force the
-    uhid driver to be used for a certain device.

-
The device handles the following ioctl(2)
-  calls:

-

-  

-  
Get the report identifier used by this HID report.

-  

-  
Get the HID report descriptor. Using this descriptor the exact layout and
-      meaning of data to/from the device can be found. The report descriptor is
-      delivered without any processing.
-    

-    
struct usb_ctl_report_desc {
-    int     ucrd_size;
-    u_char  ucrd_data[1024];	/* filled data size will vary */
-};

-    

-  

-  

-  
Sets the device in a mode where each read(2) will return
-      the current value of the input report. Normally a
-      read(2) will only return the data that the device
-      reports on its interrupt pipe. This call may fail if the device does not
-      support this feature.

-  

-  
Get a report from the device without waiting for data on the interrupt
-      pipe. The report field indicates which report is
-      requested. It should be UHID_INPUT_REPORT,
-      UHID_OUTPUT_REPORT, or
-      UHID_FEATURE_REPORT. This call may fail if the
-      device does not support this feature.
-    

-    
struct usb_ctl_report {
-	int     ucr_report;
-	u_char	ucr_data[1024];	/* used data size will vary */
-};

-    

-  

-  

-  
Set a report in the device. The report field
-      indicates which report is to be set. It should be
-      UHID_INPUT_REPORT,
-      UHID_OUTPUT_REPORT, or
-      UHID_FEATURE_REPORT. This call may fail if the
-      device does not support this feature.

-  

-  
Return the device descriptor.

-  

-  
Get an information summary for the device. This call will not issue any
-      USB transactions.

-  

-  
Get a string descriptor for the given language id and string index.
-    

-    
struct usb_string_desc {
-	int	usd_string_index;
-	int	usd_language_id;
-	usb_string_descriptor_t usd_desc;
-};

-    

-  

-

-
Use read(2) to get data from the device. Data
-    should be read in chunks of the size prescribed by the report
-  descriptor.

-
Use write(2) send data to the device. Data
-    should be written in chunks of the size prescribed by the report
-  descriptor.

-

-

-

-

-  
/dev/uhid?

-  
 

-

-

-

-

-
usbhidaction(1), usbhidctl(1),
-    uhidev(4), usb(4)

-

-

-

-
The uhid driver appeared in
-    NetBSD 1.4. Support for the
-    USB_GET_DEVICEINFO and
-    USB_GET_STRING_DESC ioctls appeared in
-    NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
May 14, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/uhidev.4 3.html b/static/netbsd/man4/uhidev.4 3.html
deleted file mode 100644
index ddc3024e..00000000
--- a/static/netbsd/man4/uhidev.4 3.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
UHIDEV(4)Device Drivers ManualUHIDEV(4)

-

-

-

-
uhidev — USB Human
-    Interface Device support

-

-

-

-
uhidev* at uhub?
-  

-  ucycom* at uhidev? reportid ?
-  

-  uhid* at uhidev? reportid ?
-  

-  ukbd* at uhidev? reportid ?
-  

-  ums* at uhidev? reportid ?
-  

-  uts* at uhidev? reportid ?

-

-

-

-
The uhidev driver handles all Human
-    Interface Devices. Each HID device can have several components, e.g., a
-    keyboard and a mouse. These components use different report identifiers (a
-    byte) to distinguish which one data is coming from. The
-    uhidev driver has other drivers attached that handle
-    particular kinds of devices and uhidev only
-    dispatches data to them based on the report id.

-

-

-

-
ucycom(4), uhid(4),
-    ukbd(4), ums(4),
-    usb(4), uts(4)

-

-

-

-
The uhidev driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
September 6, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/uhmodem.4 3.html b/static/netbsd/man4/uhmodem.4 3.html
deleted file mode 100644
index 2d4a7f74..00000000
--- a/static/netbsd/man4/uhmodem.4 3.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
UHMODEM(4)Device Drivers ManualUHMODEM(4)

-

-

-

-
uhmodem — USB
-    support for Huawei 3G wireless modem device

-

-

-

-
uhmodem* at uhub?
-  

-  ucom* at uhmodem?

-

-

-

-
The uhmodem driver supports the following
-    adapters:

-

-

-

-  
Huawei E220

-  
 

-  
E-mobile D01HW

-  
 

-  
E-mobile D02HW

-  
 

-  
NTT DoCoMo a2502

-  
 

-

-

-

-

-

-
The uhmodem driver provides support for
-    the Huawei 3G wireless modems and its variants. This type of device has
-    multiple com ports. And some modems have own storage to contain its device
-    driver (for Windows). The uhmodem driver can handle
-    all of these functions on the device.

-
When the device attached, it will attach multiple ucom devices.
-    The former one is main com device to use communication with your network
-    provider, and others are sub com devices to monitor the condition of data
-    communication and/or network status. These com devices can be used
-    simultaneously.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ubsa(4),
-    ucom(4), usb(4)

-

-

-

-
The uhmodem driver first appeared in
-    NetBSD 5.0. Separate from ubsa driver.

-

-

-
-  
-    
-    
-  
-
January 8, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/uhso.4 4.html b/static/netbsd/man4/uhso.4 4.html
deleted file mode 100644
index 3e757317..00000000
--- a/static/netbsd/man4/uhso.4 4.html	
+++ /dev/null
@@ -1,169 +0,0 @@
-
-  
-    
-    
-    
-  
-
UHSO(4)Device Drivers ManualUHSO(4)

-

-

-

-
uhso — Option N.V.
-    Wireless WAN modem driver

-

-

-

-
uhso*	at uhub? port ?

-

-

-

-
The uhso driver supports at least the
-    following adapters:

-

-

-

-  
GlobeSurfer HSUPA

-  
 

-  
GlobeSurfer iCON 7.2

-  
 

-  
GlobeTrotter Express 40x

-  
 

-  
GlobeTrotter Express HSUPA

-  
 

-  
GlobeTrotter HSUPA

-  
 

-  
GlobeTrotter HSUPA Modem

-  
 

-  
GlobeTrotter Max HSDPA

-  
 

-  
GlobeTrotter Module 382

-  
 

-  
GlobeTrotter iCON 225

-  
 

-  
GlobeTrotter iCON 321

-  
 

-  
GlobeTrotter iCON 322

-  
 

-  
GlobeTrotter iCON 401

-  
 

-  
GlobeTrotter iCON 505

-  
 

-  
GlobeTrotter iCON EDGE

-  
 

-

-

-

-

-

-
The Option N.V. modems appear at first as a
-    umass(4) device containing the Windows and MacOS drivers
-    and, upon receipt of a SCSI "REZERO UNIT" command, will detach
-    from the USB bus and reattach as a Wireless WAN modem. Unless disabled by
-    clearing the sysctl(8) variable
-    hw.uhso.autoswitch, the driver will handle that
-    automatically.

-
The modems provide a number of IO channels spread over several USB
-    interfaces which are mapped by function to a standard port number in each
-    driver instance. The defined channels are:

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
Control0
Diagnostic1
Diagnostic 22
Application3
Application 24
GPS5
GPS Control6
PC Smartcard7
Modem8
MSD9
Voice10
Network11

-
Apart from the Network port, which is attached as a network
-    interface, the ports are attached as tty(4) devices using
-    the port number as the minor device number. In order to connect using
-    pppd(8), the Modem tty should be used (eg
-  /dev/ttyHS0.08).

-
The Network port provides a direct IPv4 interface, but before this
-    can be used the modem needs to be placed in connected mode and network
-    settings subsequently retrieved using the proprietary "_OWANCALL"
-    and "_OWANDATA" AT commands on the Control port.

-
Note that the Modem and Network ports should not be enabled at the
-    same time for USB performance reasons.

-

-

-

-

-  
/dev/ttyHS?.??

-  
 

-  
/dev/dtyHS?.??

-  
 

-  
/dev/ctyHS?.??

-  
 

-

-

-

-

-
intro(4), netintro(4),
-    tty(4), uhub(4),
-    usb(4), ifconfig(8)

-

-

-

-
This driver originated as the hso module
-    for FreeBSD written by Frederik
-    Lindberg. It was rewritten for NetBSD, and to
-    provide more complete device support with information extracted from the
-    hso driver for Linux provided by Option N.V.

-
The rewrite and this manual page by Iain
-    Hibbert.

-

-

-
-  
-    
-    
-  
-
July 19, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/uintuos.4 3.html b/static/netbsd/man4/uintuos.4 3.html
deleted file mode 100644
index d291591a..00000000
--- a/static/netbsd/man4/uintuos.4 3.html	
+++ /dev/null
@@ -1,52 +0,0 @@
-
-  
-    
-    
-    
-  
-
UINTUOS(4)Device Drivers ManualUINTUOS(4)

-

-

-

-
uintuos — Wacom
-    Intuos drawing tablet device driver

-

-

-

-
uintuos* at uhidbus?

-

-

-

-
The uintuos driver provides support for
-    Wacom Intuos PTS Pen devices. The device driver returns absolute mouse
-    position events through a wsmouse(4) device, similar to a
-    touch panel.

-
The following devices are supported:

-
    
-  
  • Wacom Intuos CTH-490
    • 
-  
  • Wacom Intuos CTL-6100WL
    • 
-

-

-

-

-
uhid(4), usb(4),
-    wsmouse(4)

-

-

-

-
The uintuos device driver appeared in
-    NetBSD 10.0.

-

-

-

-
The uintuos driver was written by
-    Yorick Hardy.

-

-

-
-  
-    
-    
-  
-
July 8, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/uipad.4 4.html b/static/netbsd/man4/uipad.4 4.html
deleted file mode 100644
index 5f849d1e..00000000
--- a/static/netbsd/man4/uipad.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
UIPAD(4)Device Drivers ManualUIPAD(4)

-

-

-

-
uipad — USB
-    support for charging iOS devices

-

-

-

-
uipad* at uhub? port ?

-

-

-

-
The uipad driver supports the following
-    iOS based devices:

-

-

-

-  
Apple iPad

-  
 

-  
Apple iPad 2

-  
 

-  
Apple iPad 3

-  
 

-  
Apple iPad Mini

-  
 

-

-

-

-

-

-
The uipad driver provides support for
-    charging iOS based devices by sending the magic command to a connected
-    device, instructing it to start charging.

-

-

-

-
uhub(4), usb(4)

-

-

-

-
The NetBSD driver first appeared in
-    NetBSD 6.0.

-

-

-

-
Christos Zoulas
-    <christos@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
September 30, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/uipaq.4 4.html b/static/netbsd/man4/uipaq.4 4.html
deleted file mode 100644
index 562c4051..00000000
--- a/static/netbsd/man4/uipaq.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
UIPAQ(4)Device Drivers ManualUIPAQ(4)

-

-

-

-
uipaq — USB
-    support for iPAQ units

-

-

-

-
uipaq* at uhub?
-  

-  ucom* at uipaq?

-

-

-

-
The uipaq driver supports the following
-    adapters:

-

-

-

-  
HP iPAQ 22xx/Jornada 548

-  
 

-  
HP Jornada 568

-  
 

-  
Compaq IPaq PocketPC

-  
 

-  
Casio BE300

-  
 

-

-

-

-

-

-
The uipaq driver provides support for the
-    USB serial emulation provided by the iPAQ devices.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    uhub(4), usb(4)

-

-

-

-
The NetBSD support was added in
-    NetBSD 4.0 and it was imported from
-    OpenBSD 3.8.

-

-

-
-  
-    
-    
-  
-
July 18, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/uirda.4 4.html b/static/netbsd/man4/uirda.4 4.html
deleted file mode 100644
index 7b5cbb93..00000000
--- a/static/netbsd/man4/uirda.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
UIRDA(4)Device Drivers ManualUIRDA(4)

-

-

-

-
uirda — USB-IrDA
-    bridge support

-

-

-

-
uirda* at uhub?
-  

-  irframe* at uirda?

-

-

-

-
The uirda driver provides support for
-    USB-IrDA bridges that follow the bridge specification and also the following
-    adapters:

-

-

-

-  
ACTiSYS ACT-IR2000U FIR-USB Adapter

-  
 

-  
Kawatsu KC-180 USB IrDA Device

-  
 

-  
Extended Systems XTNDAccess IrDA USB (ESI-9685)

-  
 

-

-

-
Access to the IrDA device is through the
-    irframe(4) driver.

-

-

-

-
irframe(4), usb(4)

-

-

-

-
The uirda driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
December 11, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/uk.4 4.html b/static/netbsd/man4/uk.4 4.html
deleted file mode 100644
index a04aa84f..00000000
--- a/static/netbsd/man4/uk.4 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
UK(4)Device Drivers ManualUK(4)

-

-

-

-
uk — SCSI
-    user-level driver

-

-

-

-
uk* at scsibus? target ? lun ?

-

-

-

-
The uk driver provides support for a
-    process to address devices on the SCSI bus for which there is no configured
-    driver.

-
A SCSI adapter must also be separately configured into the system
-    before this driver makes sense.

-

-

-

-
If a count is given, that number of
-    uk devices will be configured into the
-    NetBSD kernel.

-

-

-

-
The uk driver has no ioctls of its own but
-    rather acts as a medium for the generic scsi(4) ioctls.
-    These are described in
-    <sys/scsiio.h>.

-

-

-

-

-  
/dev/uk[0-255]

-  
unknown SCSI devices.

-

-

-

-

-
All scsi(4) debug ioctls work on
-    uk devices.

-

-

-

-
ioctl(2), cd(4),
-    ch(4), scsi(4), sd(4),
-    ss(4), st(4)

-

-

-

-
The uk driver appeared in 386BSD 0.1.

-

-

-
-  
-    
-    
-  
-
October 11, 1993NetBSD 10.1

diff --git a/static/netbsd/man4/ukbd.4 4.html b/static/netbsd/man4/ukbd.4 4.html
deleted file mode 100644
index 1733ca07..00000000
--- a/static/netbsd/man4/ukbd.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
UKBD(4)Device Drivers ManualUKBD(4)

-

-

-

-
ukbd — USB
-    keyboard support

-

-

-

-
ukbd* at uhidev? reportid ?
-  

-  wskbd* at ukbd? console ?

-

-

-

-
The ukbd driver provides support for USB
-    keyboards (i.e., HID devices with reports in usage page 7). Access to the
-    keyboard is through the wscons(4) driver.

-

-

-

-
uhidev(4), usb(4),
-    wskbd(4)

-

-

-

-
The ukbd driver appeared in
-    NetBSD 1.4.

-

-

-

-
The ukbd driver is brought into action
-    rather late in the boot process, so if it is used as the console driver then
-    ddb(4) is not usable until late in the boot.

-

-

-
-  
-    
-    
-  
-
July 12, 1998NetBSD 10.1

diff --git a/static/netbsd/man4/ukphy.4 4.html b/static/netbsd/man4/ukphy.4 4.html
deleted file mode 100644
index 7b30278c..00000000
--- a/static/netbsd/man4/ukphy.4 4.html	
+++ /dev/null
@@ -1,41 +0,0 @@
-
-  
-    
-    
-    
-  
-
UKPHY(4)Device Drivers ManualUKPHY(4)

-

-

-

-
ukphy — Driver for
-    generic/unknown IEEE 802.3u Ethernet PHYs

-

-

-

-
ukphy* at mii? phy ?

-

-

-

-
The ukphy driver supports the basic
-    functionality of most Ethernet PHYs.

-

-

-

-
ifmedia(4), intro(4),
-    mii(4), ifconfig(8)

-

-

-

-
In areas where the programming interface for PHYs differ, such as
-    detecting the currently active medium, this driver often does not work
-    optimally. When available, it is best to use a PHY-specific driver.

-

-

-
-  
-    
-    
-  
-
September 8, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/ukyopon.4 4.html b/static/netbsd/man4/ukyopon.4 4.html
deleted file mode 100644
index d6fea39d..00000000
--- a/static/netbsd/man4/ukyopon.4 4.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
UKYOPON(4)Device Drivers ManualUKYOPON(4)

-

-

-

-
ukyopon — Kyocera
-    AIR-EDGE PHONE support

-

-

-

-
ukyopon* at uhub?
-  

-  ucom* at ukyopon? portno ?

-

-  

-  #include
-  <dev/usb/ukyopon.h>

-

-

-

-
The ukyopon driver provides support for
-    Kyocera AIR-EDGE PHONE AH-K3001V.

-
Two units of this driver attach to an AIR-EDGE PHONE: the modem
-    port and the data transfer port. The modem port is compatible to
-    umodem(4), and can be used for dialup connections. The
-    data transfer port is for reading and writing internal storage of AIR-EDGE
-    PHONE.

-
Both devices are accessed through the ucom(4)
-    driver which makes them behave like a tty(4).

-
The manipulation of the internal storage is through external
-    programs, for example, the pkgsrc/comms/kyopon
-    package.

-

-

-

-
The following ioctl(2) calls apply to the
-    ukyopon device:

-

-  

-    struct ukyopon_identify

-  
Read, from the kernel, the identification information of the device,
-      useful to assure that the opened device node is a modem or a data transfer
-      port of ukyopon device.
-    

-    
struct ukyopon_identify {
-	char	ui_name[16];		/* driver name */
-
-	int	ui_busno;		/* usb bus number */
-	uint8_t	ui_address;		/* device address */
-
-	enum ukyopon_model {
-		UKYOPON_MODEL_UNKNOWN
-	} ui_model;			/* possibly future use */
-	enum ukyopon_port {
-		UKYOPON_PORT_UNKNOWN,
-		UKYOPON_PORT_MODEM,	/* modem port */
-		UKYOPON_PORT_DATA	/* data transfer port */
-	} ui_porttype;			/* port type */
-	int	ui_rsvd1, ui_rsvd2;
-};
-#define UKYOPON_NAME		"ukyopon"

-    

-    
The ui_name field contains the driver
-        signature, and has the string UKYOPON_NAME.

-    
The ui_busno field contains the
-        usb(4) bus number to which the device is connected;
-        the ui_address field contains the address of the
-        device in the bus. These fields are useful to identify the physical
-        device from the file descriptor.

-    
The ui_porttype field contains the type
-        of device: UKYOPON_PORT_MODEM means the device
-        is associated to the modem port, and
-        UKYOPON_PORT_DATA means the device is associated
-        to the data transfer port.

-    
Other fields are reserved for future extension and cleared to
-        zeros.

-  

-

-
In addition, ukyopon devices accept all
-    ioctl(2) calls that umodem(4)
-  accepts.

-

-

-

-
tty(4), ucom(4),
-    umodem(4), usb(4),
-    pkgsrc/comms/kyopon

-

-

-

-
The ukyopon driver appeared in
-    NetBSD 3.0.

-

-

-

-
“Kyopon” is a widely-used nickname of Kyocera
-    AIR-EDGE PHONE.

-

-

-
-  
-    
-    
-  
-
May 18, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/ulpt.4 4.html b/static/netbsd/man4/ulpt.4 4.html
deleted file mode 100644
index 4d72d657..00000000
--- a/static/netbsd/man4/ulpt.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
ULPT(4)Device Drivers ManualULPT(4)

-

-

-

-
ulpt — USB printer
-    support

-

-

-

-
ulpt* at uhub?

-

-

-

-
The ulpt driver provides support for
-    Universal Serial Bus (USB) printers that follow either the USB printer
-    uni-directional or bi-directional protocol.

-
Additional bits OR-ed in the minor device number with the unit
-    number select various features of the driver:

-
-  
-    
-    
-  
-  
-    
-    
-  
-
0x40Do not initialize (reset) the device on the port.

-
Some printers cannot handle the reset on open; in case of problems
-    try the ulpn device.

-

-

-

-

-  
/dev/ulpt?

-  
USB printer with reset on open

-  
/dev/ulpn?

-  
USB printer without reset on open

-

-

-

-

-
lpt(4), usb(4)

-
USB Device Class Definition for
-    Printing Devices, USB Implementors Forum,
-    http://www.usb.org/developers/devclass_docs/usbprint11.pdf,
-    January 2000.

-

-

-

-
The ulpt driver appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
May 16, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/umass.4 4.html b/static/netbsd/man4/umass.4 4.html
deleted file mode 100644
index d0e5e12a..00000000
--- a/static/netbsd/man4/umass.4 4.html	
+++ /dev/null
@@ -1,89 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMASS(4)Device Drivers ManualUMASS(4)

-

-

-

-
umass — USB mass
-    storage support

-

-

-

-
umass* at uhub?
-  

-  atapibus* at umass?
-  

-  scsibus* at umass? channel ?
-  

-  wd* at umass?

-

-

-

-
The umass driver provides support for USB
-    mass storage class devices. The driver supports subclasses SCSI, 8020i
-    (ATAPI), 8070i (ATAPI), QIC157 (ATAPI), RBC (subset of SCSI), and UFI (USB
-    Floppy). The driver handles the protocols Bulk-Only, CBI, and
-  CBI-with-CCI.

-

-

-

-
Devices known to work with this driver include:

-

-

-

-  
Creative Tech NOMAD MuVo TX

-  
 

-  
FujiFilm FinePix1300 Digital Camera

-  
 

-  
Imation SuperDisk

-  
 

-  
IOmega Zip 100

-  
 

-  
IOmega Zip 250

-  
 

-  
Kingston DataTraveler 2.0

-  
 

-  
LaCie CD R/W

-  
 

-  
Lexar Media JumpDrive Flash Disks

-  
 

-  
Neodio Multi-format Flash Controller

-  
 

-  
Olympus C-5050 ZOOM Digital Camera

-  
 

-  
SanDisk ImageMate SDDR-31

-  
 

-  
Siemens MP3-Player USB

-  
 

-  
Sony DSC Digital Cameras

-  
 

-  
STMicroelectronics ST92163 Mass Storage library Tester

-  
 

-  
Y-E Data FlashBuster floppy

-  
 

-

-

-

-

-

-
atapi(4), scsi(4),
-    usb(4), wd(4)

-

-

-

-
The umass driver is a port of the
-    FreeBSD driver. The umass
-    driver appeared in NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
April 13, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/umb.4 4.html b/static/netbsd/man4/umb.4 4.html
deleted file mode 100644
index c15308de..00000000
--- a/static/netbsd/man4/umb.4 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMB(4)Device Drivers ManualUMB(4)

-

-

-

-
umb — USB Mobile
-    Broadband Interface Model (MBIM)

-

-

-

-
umb* at uhub? port?

-

-

-

-
The umb driver provides support for USB
-    MBIM devices.

-
MBIM devices establish connections via cellular networks such as
-    GPRS, UMTS, and LTE. They appear as a regular point-to-point network
-    interface, transporting raw IP frames.

-
Required configuration parameters like PIN and APN have to be set
-    with umbctl(8). Once the SIM card has been unlocked with
-    the correct PIN, it will remain in this state until the MBIM device is
-    power-cycled. In case the device is connected to an "always-on"
-    USB port, it may be possible to connect to a provider without entering the
-    PIN again even if the system was rebooted.

-

-

-

-
The following devices should work:

-

-

-

-  
Ericsson H5321gw and N5321gw

-  
 

-  
Fibocom L831-EAU

-  
 

-  
Medion Mobile S4222 (MediaTek OEM)

-  
 

-  
Sierra Wireless EM7345

-  
 

-  
Sierra Wireless EM7455

-  
 

-  
Sierra Wireless EM8805

-  
 

-  
Sierra Wireless MC8305

-  
 

-

-

-

-

-

-
intro(4), netintro(4),
-    usb(4), ifconfig.if(5),
-    ifconfig(8), umbctl(8)

-
Universal Serial Bus
-    Communications Class Subclass Specification for Mobile Broadband Interface
-    Model,
-    http://www.usb.org/developers/docs/devclass_docs/MBIM10Errata1_073013.zip.

-

-

-

-
The umb device driver first appeared in
-    OpenBSD 6.0 and NetBSD
-  9.0.

-

-

-

-
The umb driver was written by
-    Gerhard Roth
-    <gerhard@openbsd.org>
-    and ported from OpenBSD by Pierre
-    Pronchery
-    <khorben@defora.org>.

-

-

-

-
The umb driver does not support IPv6.

-
Devices which fail to provide a conforming MBIM implementation
-    will probably be attached as some other driver, such as
-    u3g(4).

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/umcpmio.4 4.html b/static/netbsd/man4/umcpmio.4 4.html
deleted file mode 100644
index a34f6209..00000000
--- a/static/netbsd/man4/umcpmio.4 4.html	
+++ /dev/null
@@ -1,479 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMCPMIO(4)Device Drivers ManualUMCPMIO(4)

-

-

-

-
umcpmio —
-    Microchip Technologies MCP2210, MCP2221/MCP2221A multi-io
-    bridge

-

-

-

-
umcpmio* at uhidev? reportid ?
-  

-  gpio* at gpiobus?
-  

-  spi* at umcpmio?
-  

-  iic* at umcpmio? # or
-  

-  iic* at i2cbus?

-

-

-

-
The umcpmio driver provides support for
-    the MCP2210 and MCP2221/MCP2221A multi-io bridge chips. The MCP2210 provides
-    9 simple gpio pins with multiple functions that attach as a
-    gpio(4) device and the ability to do SPI via the
-    spi(4) framework. The pins function as
-    gpio(4) pins or as chip select for the
-    spi(4) function. The MCP2221 provides 4 simple gpio pins
-    with multiple functions that attach as a gpio(4) device,
-    an I2C port that attaches as an iic(4) device and a UART
-    serial port that attaches using umodem(4) as a normal
-    ucom(4)
-    ttyU* device. The UART is
-    presented as one USB function, while the GPIO and I2C pins are presented as
-    a second HID USB function.

-

-

-
There are 9 basic gpio pins available with the following
-    functions:

-

-
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-    
-  
-
PinGPIOALT0ALT3ALT4ALT5ALT6
GP0I/OCS----
GP1I/OCS----
GP2I/OCSSSPND---
GP3I/OCSSPI activity---
GP4I/OCSLOWPWR---
GP5I/OCSUSBCFG---
GP6I/OCSFalling edgeRising edgeLow pulseHigh pulse
GP7I/OCSRelease ACK---
GP8I-Release REQ---

-

-
The IRQ counter on GP6 can be read with a
-    sysctl(8). The manor in which the GP6 IRQ counter detects
-    the event is configured by setting it to ALT3 to ALT6. GP8 is only an input
-    pin when configured for gpio purposes. The chip select, CS, function will be
-    enabled automatically if a request to use the spi(4)
-    framework is performed that requests the use of the associated chip select
-    pin.

-

-

-

-
The MCP2210 supports a basic SPI engine via the
-    spi(4) framework. Various SPI delays are configured with
-    umcpmioctl(8).

-
The SPI engine on the MCP2210 only functions in full duplex mode.
-    That is, it is not possible to just send bytes without also receiving them.
-    The driver will queue up any recived bytes that might have come though on a
-    transaction and present them to the upstream layer from the queue when
-    asked. This queue will be cleared out for a particular slave address when a
-    configuration call is made against a particular slave device.

-
Upon making a configuration call to the
-    umcpmio driver, the driver will set the pin
-    associated with the requested slave address to ALT0. Since the
-    spi(4) framework does not support the notion of a session,
-    this pin will never be reset by the umcpmio driver.
-    Further, it is entirely possible to use gpioctl(8) to
-    change the pin assignment in such a way that SPI no longer works as it is
-    also not possible to know if a pin is in use at any moment in time.

-

-

-

-
The MCP2210 has 256 bytes of EEPROM available via the
-    /dev/umcpmio0EEP device. Random reads and writes may
-    be performed against this device, but there can only one one opener at a
-    time.

-

-

-

-
There are 4 basic gpio pins available with the following
-    functions:

-

-
-  
-    
-    
-    
-    
-    
-    
-  
-  
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-    
-    
-  
-
PinGPIOALT0ALT1ALT2ALT3
GP0I/OUART RX--SSPND
GP1I/OADC1UART TXIRQClock output
GP2I/OADC2DAC1-USBCFG
GP3I/OADC3DAC2-I2C activity

-

-
ADC1, ADC2 and ADC3 are independent of each other and each 10 bits
-    in length. To utilize one of the ADC pins, an open(2) is
-    performed against /dev/umcpmio0GP1,
-    /dev/umcpmio0GP2 or
-    /dev/umcpmio0GP3 with only the
-    O_RDONLY flag set. Reads against the open file
-    descriptor will produce uint16_t values.

-
There is actually only one DAC present in the chip, but it is
-    mirrored to GP2 and GP3 if the pin is set to ALT1. The DAC is 5 bits in
-    length, and to use it, an open(2) is performed against
-    /dev/umcpmio0GP2 or
-    /dev/umcpmio0GP3 with only the
-    O_WRONLY flag set. Writes of
-    uint8_t bytes to the file descriptor will result in an
-    analog signal being created on the output pin.

-
The clock output is derived from the USB clock of 48MHz. The duty
-    cycle and clock divider can be adjusted with sysctl(8)
-    variables. To utilize GP1 as the clock output, the ALT3 function can be set
-    with gpioctl(8) command.

-

-

-

-
The MCP2221/MCP2221A supports a hardware I2C port with a simple
-    scripting engine. When the driver attaches, the I2C speed is set to 100Kb/s.
-    The ability to perform an I2C READ without a STOP is not supported by the
-    MCP2221/MCP2221A engine and the driver turns a READ without STOP into a READ
-    with STOP. This behavior is just an attempt to allow a device to function,
-    and it may not work for any particular device. In particular, it is known
-    that the ds2482ow(4) device will not work as expected.

-
The MCP2221/MCP2221A chip will automatically detect and deal with
-    a device that uses I2C clock stretching.

-

-

-

-
The UART on the MCP2221/MCP2221A utilizes the
-    umodem(4) driver. The UART function of the chip only
-    supports 8-N-1 communications.

-

-

-

-

-
The following sysctl(3) variables are
-  provided:

-

-

-  

-  
 

-  

-  
If UMCPMIO_DEBUG is defined, additional debugging
-      output can be enabled.
-    

-  

-  

-  
 

-  

-  
This is how long the driver will wait for a HID response to come back from
-      the chip. This variable is in microseconds and defaults to 2500. The
-      driver will only allow response_errcnt number of
-      errors when waiting for a response from a HID report. This includes
-      timeouts due to exceeding response_wait.

-

-

-

-

-  

-  
Enable or disable verbose connection reset messages when there are errors.
-    

-  

-  

-  
When the MCP2210 is busy, use busy_delay number of ms to wait before
-      trying the operation again. The default is 0 as there usually will not be
-      any reason is wait.
-    

-  

-  

-  
 

-  

-  
The number of times to retry either a chipdrain or transfer operation. A
-      chipdrain is used when the chip has sent back data, but the upstream is
-      not ready for it yet. A transfer is a normal SPI transfer.
-    

-  

-  

-  
 

-  

-  
When the GP6 pin is set to ALT3 to ALT6, this sysctl reads back the
-      counter. To reset the counter write 1 to the reset_counter sysctl. The
-      counter will also be reset if any pin changes from a input or output pin
-      to one of the ALT functions or vise versa. The trigger for this could be
-      the use of gpioctl(8) or if the pin is changed to become
-      a CS from a general I/O pin for the spi(4)
-      infrastructure.

-

-

-

-

-

-  

-  
Report on the console if a driver attempts to use an I2C READ without
-      STOP. A READ without STOP is not supported by the MCP2221/MCP2221A I2C
-      engine and will be turned into a READ with STOP by the driver.
-    

-  

-  

-  
The driver checks in a number of cases if the I2C engine is busy and will
-      wait for busy_delay microseconds before checking
-      again.
-    

-  

-  

-  
The number of times to try to do an I2C READ when the engine is busy.
-    

-  

-  

-  
The number of times to try to do an I2C WRITE when the engine is busy.
-    

-  

-  

-  
 

-  

-  
When GP1 is configured to use function ALT3, it will output a clock pulse.
-      The valid values for clock_duty_cycle are
-      ‘75%’,
-      ‘50%’,
-      ‘25%’, and
-      ‘0%’. That is, 75% of the time a
-      high and 25% of the time a low will be present on the GP1 pin. The valid
-      values for clock_divider are
-      ‘375kHz’,
-      ‘750kHz’,
-      ‘1.5MHz’,
-      ‘3MHz’,
-      ‘6MHz’,
-      ‘12MHz’, and
-      ‘24MHz’.
-    

-  

-  

-  
 

-  

-  
Sets the VREF value for the DAC or ADC. The valid values are
-      ‘4.096V’,
-      ‘2.048V’,
-      ‘1.024V’,
-      ‘OFF’, and
-      ‘VDD’.

-

-

-

-

-

-

-  
/dev/umcpmio0ctl

-  
A control device for the chip instance that allows for a number of IOCTLs.
-    

-  

-  
/dev/umcpmio0GP1

-  
 

-  
/dev/umcpmio0GP2

-  
 

-  
/dev/umcpmio0GP3

-  
Device files that allow access to the ADC or DAC functions of the
-      associated gpio pin on the MCP2221/MCP2221A.
-    

-  

-  
/dev/umcpmio0EEP

-  
Device file that interacts with the EEPROM on the MCP2210.

-

-

-

-

-
gpio(4), iic(4),
-    spi(4), sysctl(8),
-    umcpmioctl(8)

-

-

-

-
The umcpmio driver first appeared in
-    NetBSD 11.0. Support for the MCP2210 was added in
-    NetBSD 12.0.

-

-

-

-
The umcpmio driver was written by
-    Brad Spencer
-    <brad@anduin.eldar.org>.

-

-

-

-
The gpio pins on the these two chips are very slow and one should
-    not expect to be able to rapidly change their state. Even if the problem
-    mentioned below did not exist, one should not expect to be able to use any
-    of the gpio bit banger drivers such as gpioiic(4) or
-    gpioow(4).

-
The interrupt function of the MCP2221/MCP2221A on GP1 cannot
-    currently be used because it is currently not possible to attach through the
-    driver. There may be two possible problems going on:

-
    
-  
  • The gpio(4) framework runs at
-      IPL_VM with a spin lock and when it attempts to
-      establish an interrupt that uses the gpio from
-      umcpmio, calls are made into the USB stack that
-      will want to wait in a way that is not allowed while holding a spin
-    lock.
    • 
-  
  • autoconf(9) runs with
-      KERNEL_LOCK and during the attachment, this lock
-      is held when calls are made into the USB stack that will cause a wait that
-      is not allowed while holding KERNEL_LOCK.
    • 
-

-
Either or both of these may be going on, but the end result is
-    that the kernel will panic while attempting to perform a USB transfer while
-    another driver is attempting to attach through
-    umcpmio.

-
Likewise, a ‘gpioctl gpio1 attach
-    ...’ type call will also panic for the same reason.

-
The end result is that gpioirq(4),
-    gpiopps(4) and gpioow(4) will not work
-    with the gpio from umcpmio.

-
Please note that the umcpmio driver itself
-    can use the USB stack during attachment and there does not appear to be any
-    problems using the GPIO pins or setting GPIO pin configurations. It is only
-    when the driver is a target during another driver's attachment that there is
-    a problem.

-
The ability to set or change values in most of the chip's FLASH
-    memory is not supported. This includes changing the configuration protection
-    password. Likewise, support for entering the configuration protection
-    password does not exist, should a particular chip have password protection
-    enabled.

-
On the MCP2210, changing any pin from INPUT or OUTPUT to ALTx or
-    vise versa has to rewrite some of the setting for all pins. A consequence of
-    doing this is that for a very brief time, the default direction and values
-    will be set on all pins. This has the biggest impact on OUTPUT pins which
-    might generate a small pulse. This behavior really can't be avoided as there
-    is no way with the MCP2210 to write the configuration of just one pin at a
-    time. For this same reason, the IRQ event counter will be reset if any pin
-    switches from INPUT or OUTPUT to ALTx or vise versa.

-
The MCP2210 supports active high or active low CS signals per CS.
-    However, the spi(4) framework does not have any way to
-    specify the direction of the CS signal, so the only SPI CS signal supported
-    is the usual active low signal.

-

-

-
-  
-    
-    
-  
-
November 13, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/umcs.4 4.html b/static/netbsd/man4/umcs.4 4.html
deleted file mode 100644
index eeef65d9..00000000
--- a/static/netbsd/man4/umcs.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMCS(4)Device Drivers ManualUMCS(4)

-

-

-

-
umcs — USB
-    multiport serial adapters driver

-

-

-

-
umcs* at uhub?
-  

-  ucom* at umcs?

-

-

-

-
The umcs driver supports a wide variety of
-    hardware based on the MosChip 7810, 7820, 7840 chipsets and clones thereof.
-    Devices range from single port to eight port (implemented as a USB hub and
-    two umcs four port instances behind it).

-
Examples of hardware known to work with this driver are:

-

-

-

-  
LOGILINK AU0033

-  
 

-

-

-

-

-

-
The umcs driver attaches the MosChip
-    multiport chipset with individual port drivers via
-    ucom(4), which makes it behave like a
-    tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The umcs driver appeared in
-    NetBSD 7.

-

-

-
-  
-    
-    
-  
-
May 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/umct.4 4.html b/static/netbsd/man4/umct.4 4.html
deleted file mode 100644
index e706520f..00000000
--- a/static/netbsd/man4/umct.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMCT(4)Device Drivers ManualUMCT(4)

-

-

-

-
umct — USB support
-    for MCT USB RS-232 serial adapters driver

-

-

-

-
umct* at uhub?
-  

-  ucom* at umct?

-

-

-

-
The umct driver supports the following
-    adapters:

-

-

-

-  
Belkin F5U109

-  
 

-  
D-Link DU-H3SP USB BAY

-  
 

-  
MCT USB RS-232 Converter 25 pin Model U232-P25

-  
 

-  
MCT USB RS-232 Converter 9 pin Model U232-P9

-  
 

-  
Sitecom USB RS-232 Converter

-  
 

-

-

-

-

-

-
The umct driver provides support for MCT
-    USB-to-RS-232 Converter and their family products.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The umct driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
May 11, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/umidi.4 4.html b/static/netbsd/man4/umidi.4 4.html
deleted file mode 100644
index d2955391..00000000
--- a/static/netbsd/man4/umidi.4 4.html	
+++ /dev/null
@@ -1,129 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMIDI(4)Device Drivers ManualUMIDI(4)

-

-

-

-
umidi — USB
-    support for MIDI devices

-

-

-

-
umidi* at uhub?
-  

-  midi* at umidi?

-

-

-

-
The umidi driver supports USB MIDI devices
-    that conform to the
-    . Vendor-specific
-    support is also included for the following:

-

-

-

-

-  
MidiSport 2x4

-  
 

-

-

-

-

-

-

-

-  
Fantom-X

-  
 

-  
PC300

-  
 

-  
PCR

-  
 

-  
SC8820

-  
 

-  
SC8850

-  
 

-  
SCD70

-  
 

-  
SD20

-  
 

-  
SD80

-  
 

-  
SD90

-  
 

-  
SK500

-  
 

-  
SonicCell

-  
 

-  
U8

-  
 

-  
UA25

-  
 

-  
UA100

-  
 

-  
UA101

-  
 

-  
UA10F

-  
 

-  
UA4FX

-  
 

-  
UA700

-  
 

-  
UA1000

-  
 

-  
UM1

-  
 

-  
UM2

-  
 

-  
UM3

-  
 

-  
UM4

-  
 

-  
UM550

-  
 

-  
UM880N

-  
 

-  
XV5050

-  
 

-

-

-

-

-

-

-

-  
UX256

-  
(product-specific support)

-  
Others

-  
Other Yamaha MIDI devices will be attached and are expected to work
-    also.

-

-

-
Devices supported by the umidi driver will
-    appear as midi(4) devices.

-

-

-

-

-
midi(4), usb(4)

-

-

-

-
The umidi driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
October 14, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/umodem.4 4.html b/static/netbsd/man4/umodem.4 4.html
deleted file mode 100644
index cebf41e7..00000000
--- a/static/netbsd/man4/umodem.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMODEM(4)Device Drivers ManualUMODEM(4)

-

-

-

-
umodem — USB modem
-    support

-

-

-

-
umodem* at uhub?
-  

-  ucom* at umodem?

-

-

-

-
The umodem driver provides support for USB
-    modems in the Communication Device Class using the Abstract Control Model.
-    These modems are basically standard serial line modems, but they are
-    accessed via USB instead. They support a regular AT command set. The
-    commands can either be multiplexed with the data stream or handled through
-    separate pipes. In the latter case the AT commands have to be given on a
-    device separate from the data device.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The umodem driver appeared in
-    NetBSD 1.5.

-

-

-

-
Only modems with multiplexed commands and data are supported at
-    the moment.

-

-

-
-  
-    
-    
-  
-
August 16, 1999NetBSD 10.1

diff --git a/static/netbsd/man4/ums.4 4.html b/static/netbsd/man4/ums.4 4.html
deleted file mode 100644
index 0f6266d7..00000000
--- a/static/netbsd/man4/ums.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
UMS(4)Device Drivers ManualUMS(4)

-

-

-

-
ums — USB mouse
-    and touchpanel support

-

-

-

-
ums* at uhidev? reportid ?
-  

-  wsmouse* at ums?

-

-

-

-
The ums driver provides support for USB
-    mice and touchpanels. Access to the movement data is through the
-    wsmouse(4) driver.

-
Be aware that many USB mice will, if the mouse device is not open,
-    detach and reattach themselves repeatedly at regular intervals (usually
-    around one minute) causing spam on the console and the system log. This is
-    apparently intentional behavior on the part of the hardware manufacturers.
-    The best workaround is to keep the mouse device open, either via X11, or, if
-    not using the window system, by running wsmoused(8).

-

-

-

-
uhidev(4), usb(4),
-    wsmouse(4)

-

-

-

-
The ums driver appeared in
-    NetBSD 1.4. Touchpanel support was added in
-    NetBSD 5.1.

-

-

-
-  
-    
-    
-  
-
June 6, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/unix.4 4.html b/static/netbsd/man4/unix.4 4.html
deleted file mode 100644
index f0e0acec..00000000
--- a/static/netbsd/man4/unix.4 4.html	
+++ /dev/null
@@ -1,214 +0,0 @@
-
-  
-    
-    
-    
-  
-
UNIX(4)Device Drivers ManualUNIX(4)

-

-

-

-
unix — UNIX-domain
-    protocol family

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/un.h>

-

-

-

-
The UNIX-domain protocol family is a collection of protocols that
-    provides local (on-machine) interprocess communication through the normal
-    socket(2) mechanisms. The UNIX-domain family supports the
-    SOCK_STREAM, SOCK_SEQPACKET,
-    and SOCK_DGRAM socket types and uses filesystem
-    pathnames for addressing.

-

-

-

-
UNIX-domain addresses are variable-length filesystem pathnames of
-    at most 104 characters. The include file
-    <sys/un.h> defines this
-    address:

-

-
struct sockaddr_un {
-        u_char  sun_len;
-        u_char  sun_family;
-        char    sun_path[104];
-};

-

-
Binding a name to a UNIX-domain socket with
-    bind(2) causes a socket file to be created in the
-    filesystem. This file is not removed when the socket is
-    closed; unlink(2) must be used to remove the file.

-
The length of UNIX-domain address, required by
-    bind(2) and connect(2), can be
-    calculated by the macro
-    ()
-    defined in <sys/un.h>. The
-    sun_path field must be terminated by a NUL character
-    to be used with SUN_LEN(), but the terminating NUL
-    is not part of the address. The
-    NetBSD kernel ignores any user-set value in the
-    sun_len member of the structure.

-
The UNIX-domain protocol family does not support broadcast
-    addressing or any form of “wildcard” matching on incoming
-    messages. All addresses are absolute- or relative-pathnames of other
-    UNIX-domain sockets. Normal filesystem access-control mechanisms are also
-    applied when referencing pathnames; e.g., the destination of a
-    connect(2) or sendto(2) must be
-    writable.

-

-

-

-
The UNIX-domain protocol family comprises simple transport
-    protocols that support the SOCK_STREAM,
-    SOCK_SEQPACKET, and
-    SOCK_DGRAM abstractions.

-
SOCK_STREAM and
-    SOCK_SEQPACKET sockets also support the
-    communication of UNIX file descriptors through the
-    use of the msg_control field in the
-    msg argument to sendmsg(2) and
-    recvmsg(2). Supported file descriptors may be sent in
-    control messages of type SCM_RIGHTS holding an array
-    of int file descriptor objects; see
-    cmsg(3) for details on assembling and examining control
-    messages.

-
A file descriptor received this way is a
-     of
-    the sender's descriptor, as if it were created with a call to
-    dup(2). Per-process descriptor flags, set with
-    fcntl(2), are not passed to a receiver.
-    Descriptors that are awaiting delivery, or that are purposely not received,
-    are automatically closed by the system when the destination socket is
-    closed.

-
A UNIX-domain socket supports the
-    following socket options for use with setsockopt(2) and
-    getsockopt(2) at the level
-    SOL_LOCAL:

-

-  

-    (int)

-  
May be enabled with setsockopt(2) on a
-      SOCK_SEQPACKET or
-      SOCK_STREAM socket. If enabled,
-      connect(2) will block until a peer is waiting in
-      accept(2).

-  

-    (int)

-  
May be enabled with setsockopt(2) on a
-      SOCK_DGRAM,
-      SOCK_SEQPACKET, or a
-      SOCK_STREAM socket. This option provides a
-      mechanism for the receiver to receive the credentials of the process as a
-      recvmsg(2) control message. The
-      msg_control field in the
-      msghdr structure points to a buffer that contains a
-      cmsghdr structure followed by a variable length
-      sockcred structure, defined in
-      <sys/socket.h> as follows:
-    

-    
struct sockcred {
-        pid_t   sc_pid;       /* process id */
-        uid_t   sc_uid;       /* real user id */
-        uid_t   sc_euid;      /* effective user id */
-        gid_t   sc_gid;       /* real group id */
-        gid_t   sc_egid;      /* effective group id */
-        int     sc_ngroups;   /* number of supplemental groups */
-        gid_t   sc_groups[1]; /* variable length */
-};

-    

-    
The
-        ()
-        macro computes the size of the sockcred structure
-        for a specified number of groups. The cmsghdr
-        fields have the following values:

-    

-    
cmsg_len = CMSG_LEN(SOCKCREDSIZE(ngroups))
-cmsg_level = SOL_SOCKET
-cmsg_type = SCM_CREDS

-    

-  

-  

-    (struct unpcbid)

-  
May be queried with getsockopt(2) to get the PID and
-      effective user and group IDs of a SOCK_STREAM or
-      SOCK_SEQPACKET peer when it did
-      connect(2) or bind(2). The returned
-      structure is
-    

-    
struct unpcbid {
-        pid_t unp_pid;        /* process id */
-        uid_t unp_euid;       /* effective user id */
-        gid_t unp_egid;       /* effective group id */
-};

-    

-    
as defined in
-        <sys/un.h>.

-  

-

-

-

-

-
The following code fragment shows how to bind a socket to
-    pathname:

-

-
const char *pathname = "/path/to/socket";
-struct sockaddr_un addr;
-int ret;
-
-memset(&addr, 0, sizeof(addr));
-addr.sun_family = AF_LOCAL;
-if (strlen(pathname) >= sizeof(addr.sun_path))
-        goto too_long;
-strncpy(addr.sun_path, pathname, sizeof(addr.sun_path));
-ret = bind(s, (const struct sockaddr *)&addr, SUN_LEN(&addr));
-if (ret != 0)
-        goto bind_failed;
-...

-

-

-

-

-
The sun_len field exists only in system
-    derived from 4.4BSD. On systems which don't have the
-    SUN_LEN() macro, the following definition is
-    recommended:

-

-
#ifndef SUN_LEN
-#define SUN_LEN(su)	sizeof(struct(sockaddr_un))
-#endif

-

-

-

-

-
socket(2), CMSG_DATA(3),
-    intro(4)

-
Stuart Sechrest,
-    An Introductory 4.4BSD Interprocess Communication
-    Tutorial. (see
-    /usr/share/doc/reference/ref3/sockets)

-
Samuel J. Leffler,
-    Robert S. Fabry, William N.
-    Joy, Phil Lapsley, Steve
-    Miller, and Chris Torek,
-    Advanced 4.4BSD IPC Tutorial. (see
-    /usr/share/doc/reference/ref3/sockets-advanced)

-

-

-

-
The sc_pid field was introduced in
-    NetBSD 8.0.

-

-

-
-  
-    
-    
-  
-
June 28, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/upgt.4 4.html b/static/netbsd/man4/upgt.4 4.html
deleted file mode 100644
index 1d1bca02..00000000
--- a/static/netbsd/man4/upgt.4 4.html	
+++ /dev/null
@@ -1,165 +0,0 @@
-
-  
-    
-    
-    
-  
-
UPGT(4)Device Drivers ManualUPGT(4)

-

-

-

-
upgt —
-    Conexant/Intersil PrismGT SoftMAC USB IEEE 802.11b/g
-    wireless network device

-

-

-

-
upgt* at uhub? port ?

-

-

-

-
The upgt driver supports the USB 2.0
-    Conexant/Intersil PrismGT series wireless adapters based on the GW3887
-    chipset.

-
These are the modes the upgt driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The upgt driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it. The
-    upgt driver relies on the software 802.11 stack for
-    both encryption and decryption of data frames.

-
The upgt driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5).

-

-

-

-
The driver needs a firmware file which is loaded when an interface
-    is brought up:

-

-

-

-  
/libdata/firmware/upgt/upgt-gw3887

-  
 

-

-

-
Currently these firmware files can not be included in
-    NetBSD base system. Please download these files and
-    put them into the above firmware directory.

-
A tar archive file that includes
-    upgt-gw3887 firmware can be found at:

-

-
http://www.nazgul.ch/upgt/upgt-firmware-1.1.tar.gz

-

-

-

-

-
The following adapters should work:

-

-

-

-  
Belkin F5D7050 (version 1000)

-  
 

-  
Cohiba Proto Board

-  
 

-  
D-Link DWL-G120 Cohiba

-  
 

-  
D-Link DWL-G122 rev A2

-  
 

-  
FSC Connect2Air E-5400 USB D1700

-  
 

-  
Gigaset USB Adapter 54

-  
 

-  
Inventel UR045G

-  
 

-  
IOGear GWU513

-  
 

-  
Linksys WUSB54AG

-  
 

-  
Linksys WUSB54G ver 2

-  
 

-  
Medion MD40900

-  
 

-  
Philips CPWUA054

-  
 

-  
SMC EZ ConnectG SMC2862W-G

-  
 

-  
Sagem XG703A

-  
 

-  
Spinnaker DUT

-  
 

-  
Spinnaker Proto Board

-  
 

-  
Thomson SpeedTouch 121g

-  
 

-  
Willcom / Sharp WS003SH/WS004SH smart phone internal wireless LAN

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    upgt0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    dhcpcd(8):

-

-
ssid 'my network' nwkey 0x1deadbeef1 chan 11
-dhcp

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig upgt0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    usb(4), ifconfig.if(5),
-    ifconfig(8)

-

-

-

-
The upgt driver first appeared in
-    OpenBSD 4.3. It was ported to
-    NetBSD by FUKAUMI Naoki and first appeared in
-    NetBSD 6.0.

-

-

-

-
The upgt driver was written by
-    Marcus Glocker
-    <mglocker@openbsd.org>.

-
The hardware specification was reverse engineered by the people at
-    http://lekernel.net/prism54/.

-

-

-

-
The upgt driver just supports the USB 2.0
-    devices (GW3887 chipset) but not the USB 1.0 devices containing the NET2280,
-    ISL3880, and ISL3886 chipsets. Some further efforts would be necessary to
-    add USB 1.0 support to the driver.

-

-

-
-  
-    
-    
-  
-
July 4, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/upl.4 4.html b/static/netbsd/man4/upl.4 4.html
deleted file mode 100644
index 347861e1..00000000
--- a/static/netbsd/man4/upl.4 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
UPL(4)Device Drivers ManualUPL(4)

-

-

-

-
upl — USB support
-    for Prolific based host-to-host adapters

-

-

-

-
upl* at uhub?

-

-

-

-
The upl driver provides support for
-    Prolific PL2301/PL2302 based host-to-host USB connectors.

-
The upl driver appears as a point-to-point
-    network interface and should be configured with
-    ifconfig(8) in the same way as other point-to-point
-    interfaces. The upl device supports IPv4 only.

-

-

-

-
The upl driver supports the following
-    adapters from the following vendors:

-

-

-  
Aserton

-  
 

-  
Bencent

-  
 

-  
Butterfly

-  
 

-  
Camtel

-  
 

-  
Inland

-  
 

-  
Longshine

-  
 

-  
PC Linq

-  
 

-  
Prolific

-  
 

-  
StarMount

-  
 

-  
Univex

-  
 

-  
VVMer

-  
 

-

-

-
Belkin, Entrega, and Xircom do
-     use this chip and
-    are not supported by this driver.

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
netintro(4), usb(4),
-    usbnet(4), ifconfig(8)

-

-

-

-
The upl driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/uplcom.4 4.html b/static/netbsd/man4/uplcom.4 4.html
deleted file mode 100644
index b7d55a41..00000000
--- a/static/netbsd/man4/uplcom.4 4.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
UPLCOM(4)Device Drivers ManualUPLCOM(4)

-

-

-

-
uplcom — USB
-    support for Prolific PL-2303 serial adapters driver

-

-

-

-
uplcom* at uhub?
-  

-  ucom* at uplcom?

-

-

-

-
The uplcom driver supports the following
-    adapters:

-

-

-

-  
BAFO BF-800

-  
 

-  
BAFO BF-810

-  
 

-  
ELECOM UC-SGT

-  
 

-  
HAL Corporation Crossam2

-  
 

-  
IOGEAR UC-232A

-  
 

-  
I/O DATA USB-RSAQ

-  
 

-  
I/O DATA USB-RSAQ2

-  
 

-  
I/O DATA USB-RSAQ3

-  
 

-  
I/O DATA USB-RSAQ5

-  
 

-  
PLANEX USB RS-232 URS-03

-  
 

-  
Sharp CE-175TU

-  
 

-  
Sitecom CN-116 USB to serial

-  
 

-  
Sony Ericsson DCU-10

-  
 

-  
Sony Ericsson DCU-11

-  
 

-  
SOURCENEXT KeiKaiDenwa 8

-  
 

-

-

-

-

-

-
The uplcom driver provides support for the
-    Prolific PL-2303 USB-to-RS-232 Bridge chip.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The uplcom driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
July 14, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/ure.4 4.html b/static/netbsd/man4/ure.4 4.html
deleted file mode 100644
index 264d1f5c..00000000
--- a/static/netbsd/man4/ure.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
URE(4)Device Drivers ManualURE(4)

-

-

-

-
ure — RealTek
-    RTL8152/RTL8153 10/100/Gigabit USB Ethernet device

-

-

-

-
ure* at uhub?
-  

-  rgephy* at mii?
-  

-  rlphy* at mii?

-

-

-

-
The ure driver provides support for USB
-    Ethernet adapters based on the RealTek RTL8152 USB Fast Ethernet devices
-    including:

-

-

-

-  
Cable Matters 202023 USB 2.0 to 10/100 Fast Ethernet Network Adapter

-  
 

-

-

-
and RTL8153 USB Gigabit Ethernet devices including:

-

-

-

-  
Anker A7611 Aluminum USB 3.0 to Ethernet Adapter

-  
 

-

-

-
The RTL8152 contains an integrated Fast Ethernet MAC, which
-    supports both 10 and 100Mbps speeds in either full or half duplex. The
-    RTL8153 has a Gigabit Ethernet MAC and additionally supports 1000Mbps
-    speeds.

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    rgephy(4), rlphy(4),
-    uhub(4), usb(4),
-    usbnet(4), ifconfig(8)

-

-

-

-
The ure device driver first appeared in
-    OpenBSD 6.0 and NetBSD
-  9.0.

-

-

-

-
The ure driver was written by
-    Kevin Lo
-    <kevlo@FreeBSD.org>
-    for OpenBSD and ported to
-    NetBSD by Rin Okuyama
-    <rin@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/url.4 4.html b/static/netbsd/man4/url.4 4.html
deleted file mode 100644
index 0ca197c6..00000000
--- a/static/netbsd/man4/url.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
URL(4)Device Drivers ManualURL(4)

-

-

-

-
url — Realtek
-    RTL8150L USB Ethernet driver

-

-

-

-
url* at uhub?
-  

-  urlphy* at mii?

-

-

-

-
The url driver provides support for USB
-    Ethernet adapters based on the Realtek RTL8150L USB-ether bridge chip.

-
The url driver supports the following
-    adapters:

-

-

-

-  
CompUSA USBKR100

-  
 

-  
GreenHouse GH-USB100B

-  
 

-  
Melco Inc. LUA-KTX

-  
 

-  
Sitecom LN013

-  
 

-

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), mii(4),
-    netintro(4), usb(4),
-    usbnet(4), ifconfig(8)

-

-

-

-
The url device driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The url driver was written by
-    Shingo WATANABE
-  ⟨nabe@nabechan.org⟩.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/urndis.4 4.html b/static/netbsd/man4/urndis.4 4.html
deleted file mode 100644
index b0cf9f8e..00000000
--- a/static/netbsd/man4/urndis.4 4.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
URNDIS(4)Device Drivers ManualURNDIS(4)

-

-

-

-
urndis — USB
-    Remote NDIS Ethernet device

-

-

-

-
urndis* at uhub?

-

-

-

-
The urndis driver provides support for
-    Ethernet access over Remote NDIS. The urndis driver
-    should work with all USB RNDIS devices, but the following devices are known
-    to work:

-

-
    
-  
  • Geeksphone ONE
    • 
-  
  • Google Nexus One
    • 
-  
  • HTC Desire
    • 
-  
  • HTC Dream / T-Mobile G1 / ADP1
    • 
-  
  • HTC Hero
    • 
-  
  • HTC Magic
    • 
-  
  • HTC Tattoo
    • 
-  
  • HTC Wildfire
    • 
-  
  • LGE Nexus 5
    • 
-  
  • Motorola Moto X (2nd Gen.)
    • 
-  
  • OnePlus 5T
    • 
-  
  • Samsung Galaxy S / S2
    • 
-  
  • Samsung Galaxy S8 Active
    • 
-  
  • Sony Xperia XA2
    • 
-

-
The urndis driver does not support
-    different media types or options. For more information on configuring this
-    device, see ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), intro(4),
-    netintro(4), usb(4),
-    usbnet(4), ifconfig.if(5),
-    ifconfig(8)

-

-

-

-
The urndis device driver first appeared in
-    OpenBSD 4.7 and in NetBSD
-    6.0.

-

-

-

-
The urndis driver was written by
-    Jonathan Armani
-    <armani@openbsd.org>,
-    Michael Knudsen
-    <mk@openbsd.org>, and
-    Fabien Romano
-    <fabien@openbsd.org>.

-

-

-
-  
-    
-    
-  
-
February 12, 2023NetBSD 10.1

diff --git a/static/netbsd/man4/urtw.4 4.html b/static/netbsd/man4/urtw.4 4.html
deleted file mode 100644
index 5ceaf75f..00000000
--- a/static/netbsd/man4/urtw.4 4.html	
+++ /dev/null
@@ -1,133 +0,0 @@
-
-  
-    
-    
-    
-  
-
URTW(4)Device Drivers ManualURTW(4)

-

-

-

-
urtw — Realtek
-    RTL8187B/L USB IEEE 802.11b/g wireless network device

-

-

-

-
urtw* at uhub? port ?

-

-

-

-
The urtw driver supports USB 802.11b/g
-    wireless adapters based on the Realtek RTL8187B/L.

-
urtw supports
-    station and monitor mode
-    operation. Only one virtual interface may be configured at any time. For
-    more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
The urtw driver supports Realtek
-    RTL8187B/L based wireless network devices, including:

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
Belkin F5D7050ERTL8225USB
Linksys WUSB54GCv2RTL8225USB
Netgear WG111v2RTL8225USB
Netgear WG111v3RTL8225USB
Safehome WLG-1500SMA5RTL8225USB
Shuttle XPC Accessory PN20RTL8225USB
Sitecom WL168v1RTL8225USB
Sitecom WL168v4RTL8225USB
SureCom EP-9001-g(2A)RTL8225USB
TRENDnet TEW-424UB V3.xRRTL8225USB

-

-

-

-
ifconfig.if(5) example configures urtw0 to join
-    whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
nwkey 0x1deadbeef1 chan 11
-dhcp

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig urtw0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-
arp(4), netintro(4),
-    usb(4), ifconfig.if(5),
-    wpa_supplicant.conf(5), ifconfig(8),
-    wpa_supplicant(8)
-    Realtek

-

-

-

-
The urtw device driver first appeared in
-    FreeBSD 8.0 and NetBSD
-  6.0.

-

-

-

-
The urtw driver was written by
-    Weongyo Jeong
-  ⟨weongyo@FreeBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
January 12, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/urtwn.4 3.html b/static/netbsd/man4/urtwn.4 3.html
deleted file mode 100644
index 5a9becd5..00000000
--- a/static/netbsd/man4/urtwn.4 3.html	
+++ /dev/null
@@ -1,222 +0,0 @@
-
-  
-    
-    
-    
-  
-
URTWN(4)Device Drivers ManualURTWN(4)

-

-

-

-
urtwn — Realtek
-    RTL8188CU/RTL8188EU/RTL8192CU/RTL8192EU USB IEEE 802.11b/g/n wireless
-    network device

-

-

-

-
urtwn* at uhub? port ?

-

-

-

-
The urtwn driver supports USB 2.0 wireless
-    network devices based on Realtek RTL8188CUS, RTL8188CE-VAU, RTL8188EUS,
-    RTL8188RU, RTL8192CU and RTL8192EU chipsets.

-
The RTL8188CUS and RTL8188EUS are highly integrated 802.11n
-    adapters that combine a MAC, a 1T1R capable baseband and an RF in a single
-    chip. They operate in the 2GHz spectrum only. The RTL8188RU is a high-power
-    variant of the RTL8188CUS. The RTL8188CE-VAU is a PCI Express Mini Card
-    adapter that attaches to the USB interface.

-
The RTL8192CU and RTL8192EU are highly integrated multiple-in,
-    multiple-out (MIMO) 802.11n adapters that combine a MAC, a 2T2R capable
-    baseband and an RF in a single chip. It operates in the 2GHz spectrum
-  only.

-
These are the modes the urtwn driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
IBSS mode

-  
Also known as  mode or
-      
-      mode. This is the standardized method of operating without an access
-      point. Stations associate with a service set. However, actual connections
-      between stations are peer-to-peer.

-  
Host AP

-  
In this mode the driver acts as an access point (base station) for other
-      cards.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
The urtwn driver can be configured to use
-    Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA-PSK and
-    WPA2-PSK). WPA is the de facto encryption standard for wireless networks. It
-    is strongly recommended that WEP not be used as the sole mechanism to secure
-    wireless communication, due to serious weaknesses in it.

-
The urtwn driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5).

-

-

-

-
The driver needs the following firmware files, which are loaded
-    when an interface is attached:

-

-

-

-  
/libdata/firmware/if_urtwn/rtl8188eufw.bin

-  
 

-  
/libdata/firmware/if_urtwn/rtl8192cfw.bin

-  
 

-  
/libdata/firmware/if_urtwn/rtl8192cfwU.bin

-  
 

-  
/libdata/firmware/if_urtwn/rtl8192efw.bin

-  
 

-

-

-

-

-

-
The following adapters should work:

-

-

-

-  
Airlink101 AWLL5088

-  
 

-  
Aus. Linx AL-9604R1S

-  
 

-  
ASUSTeK USB-N10 NANO

-  
 

-  
B-Link BL-LW05-5R

-  
 

-  
Belkin F7D1102 Surf Wireless Micro

-  
 

-  
D-Link DWA-121

-  
 

-  
D-Link DWA-125

-  
 

-  
D-Link DWA-131

-  
 

-  
D-Link DWA-133

-  
 

-  
D-Link DWA-135

-  
 

-  
Digitus DN-7042

-  
 

-  
Edimax EW-7811Un

-  
 

-  
EDUP EP-N8508

-  
 

-  
ELECOM WDC-150SU2M

-  
 

-  
Full River FR-W100NUL

-  
 

-  
Hercules Wireless N USB Pico HWNUp-150

-  
 

-  
IO-DATA WN-G150UMW

-  
 

-  
Mercusys MW150US v2

-  
 

-  
Netgear WNA1000A

-  
 

-  
Planex GW-USEco300

-  
 

-  
Planex GW-USNano2

-  
 

-  
Planex GW-USValue-EZ

-  
 

-  
Planex GW-USWExtreme

-  
 

-  
POWCHIP POW-N18

-  
 

-  
Sitecom N300 USB (WLA-2102 v1)

-  
 

-  
Sitecom WL-365

-  
 

-  
Solwise NET-WL-UMD-606N

-  
 

-  
TP-LINK TL-WN722N v2

-  
 

-  
TP-LINK TL-WN723N v3

-  
 

-  
TP-LINK TL-WN725N v2

-  
 

-  
TP-LINK TL-WN821N

-  
 

-  
TP-LINK TL-WN822N v4

-  
 

-  
TP-LINK TL-WN823N v2

-  
 

-  
TRENDnet TEW-648UBM

-  
 

-

-

-

-

-

-
The following ifconfig.if(5) example configures
-    urtwn0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11, obtaining an IP address using
-    DHCP:

-

-
nwkey 0x1deadbeef1 chan 11
-dhcp

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig urtwn0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
urtwn%d: error %d, could not read firmware %s

-  
For some reason, the driver was unable to read the microcode file from the
-      filesystem. The file might be missing or corrupted.

-  
urtwn%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), netintro(4),
-    usb(4), ifconfig.if(5),
-    wpa_supplicant.conf(5), ifconfig(8),
-    wpa_supplicant(8)

-

-

-

-
The urtwn device driver first appeared in
-    OpenBSD 4.9 and in NetBSD
-    6.0.

-

-

-

-
The urtwn driver was written by
-    Damien Bergamini ⟨damien@openbsd.org⟩
-    for OpenBSD and ported to
-    NetBSD by NONAKA Kimihiro
-    ⟨nonaka@NetBSD.org⟩.

-

-

-

-
The urtwn driver does not support any of
-    the 802.11n capabilities offered by the adapters. Additional work is
-    required in ieee80211(9) before those features can be
-    supported.

-

-

-
-  
-    
-    
-  
-
May 26, 2024NetBSD 10.1

diff --git a/static/netbsd/man4/usb.4 4.html b/static/netbsd/man4/usb.4 4.html
deleted file mode 100644
index 1a488946..00000000
--- a/static/netbsd/man4/usb.4 4.html	
+++ /dev/null
@@ -1,554 +0,0 @@
-
-  
-    
-    
-    
-  
-
USB(4)Device Drivers ManualUSB(4)

-

-

-

-
usb — Universal
-    Serial Bus driver

-

-

-

-
ehci* at cardbus? function ?
-  

-  ehci* at pci? dev ? function ?
-  

-  ohci* at cardbus? function ?
-  

-  ohci* at pci? dev ? function ?
-  

-  xhci* at pci? dev ? function ?
-  

-  slhci* at isa? port ? irq ?
-  

-  slhci* at pcmcia? function ?
-  

-  uhci* at cardbus? function ?
-  

-  uhci* at pci? dev ? function ?
-  

-  usb* at ehci?
-  

-  usb* at ohci?
-  

-  usb* at uhci?
-  

-  usb* at slhci?
-  

-  uhub* at usb?
-  

-  uhub* at uhub? port ? configuration ? interface ? vendor ?
-    product ? release ?
-  

-  XX* at uhub? port ? configuration ? interface ? vendor ?
-    product ? release ?

-

-  

-  options USBVERBOSE

-

-  

-  #include <dev/usb/usb.h>
-  

-  #include
-  <dev/usb/usbhid.h>

-

-

-

-
NetBSD provides machine-independent bus
-    support and drivers for USB devices.

-
The NetBSD usb
-    driver has three layers (like scsi(4) and
-    pcmcia(4)): the controller, the bus, and the device layer.
-    The controller attaches to a physical bus (like pci(4)).
-    The USB bus attaches to the controller and the root hub attaches to the bus.
-    Further devices, which may include further hubs, attach to other hubs. The
-    attachment forms the same tree structure as the physical USB device tree.
-    For each USB device there may be additional drivers attached to it.

-
The uhub device controls USB hubs and must
-    always be present since there is at least a root hub in any USB system.

-
NetBSD supports the following
-    machine-independent USB drivers:

-

-

-

-

-  
umass(4)

-  
USB Mass Storage Devices, e.g., external disk drives

-

-

-

-

-

-

-

-  
aue(4)

-  
ADMtek AN986/ADM8511 Pegasus family 10/100 USB Ethernet device

-  
axe(4)

-  
ASIX Electronics AX88172/AX88178/AX88772 10/100/Gigabit USB Ethernet
-      device

-  
axen(4)

-  
ASIX Electronics AX88178a/AX88179 10/100/Gigabit USB Ethernet device

-  
cdce(4)

-  
USB Communication Device Class Ethernet device

-  
cue(4)

-  
CATC USB-EL1201A USB Ethernet device

-  
kue(4)

-  
Kawasaki LSI KL5KUSB101B USB Ethernet device

-  
mos(4)

-  
MosChip MCS7730/7830/7832 10/100 USB Ethernet device

-  
mue(4)

-  
Microchip LAN75xx/LAN78xx 10/100/Gigabit USB Ethernet device

-  
ncm(4)

-  
USB Network Control Model Ethernet device

-  
udav(4)

-  
Davicom DM9601 10/100 USB Ethernet device

-  
ure(4)

-  
Realtek RTL8152/RTL8153 10/100/Gigabit USB Ethernet device

-  
url(4)

-  
Realtek RTL8150L 10/100 USB Ethernet device

-  
urndis(4)

-  
USB Remote NDIS Ethernet device

-  
usmsc(4)

-  
SMSC LAN95xx 10/100 USB Ethernet device

-

-

-

-

-

-

-

-  
atu(4)

-  
Atmel AT76C50x IEEE 802.11b wireless network device

-  
ral(4)

-  
Ralink Technology USB IEEE 802.11b/g wireless network device

-  
rum(4)

-  
Ralink Technology USB IEEE 802.11a/b/g wireless network device

-  
run(4)

-  
Ralink Technology USB IEEE 802.11a/b/g/n wireless network device

-  
ubt(4)

-  
USB Bluetooth dongles

-  
upgt(4)

-  
Conexant/Intersil PrismGT SoftMAC USB 802.11b/g wireless network
-    device

-  
urtwn(4)

-  
Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless network
-    device

-  
zyd(4)

-  
ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device

-

-

-

-

-

-

-

-  
uark(4)

-  
Arkmicro Technologies ARK3116 based USB serial adapters

-  
ubsa(4)

-  
Belkin USB serial adapter

-  
uchcom(4)

-  
WinChipHead CH341/340 based USB serial adapter

-  
ucom(4)

-  
USB tty support

-  
ucycom(4)

-  
Cypress microcontroller based USB serial adapter

-  
uftdi(4)

-  
FT8U100AX USB serial adapter

-  
ugensa(4)

-  
USB generic serial adapter

-  
uipaq(4)

-  
iPAQ USB units

-  
ukyopon(4)

-  
USB Kyocera AIR-EDGE PHONE device

-  
ulpt(4)

-  
USB printer support

-  
umct(4)

-  
MCT USB-RS232 USB serial adapter

-  
umodem(4)

-  
USB modem support

-  
uplcom(4)

-  
Prolific PL-2303 USB serial adapter

-  
uslsa(4)

-  
Silicon Laboratories CP2101/CP2102 based USB serial adapter

-  
uvisor(4)

-  
USB Handspring Visor

-  
uvscom(4)

-  
SUNTAC Slipper U VS-10U USB serial adapter

-  
uxrcom(4)

-  
Exar XR21V141x USB serial adapter

-

-

-

-

-

-

-

-  
u3g(4)

-  
USB 3G modems

-  
uhmodem(4)

-  
Huawei 3G wireless modems

-  
uhso(4)

-  
Option N.V. Wireless WAN modems

-  
umb(4)

-  
USB Mobile Broadband Interface Model (MBIM) devices

-

-

-

-

-

-

-

-  
uaudio(4)

-  
USB audio devices

-  
umidi(4)

-  
USB MIDI devices

-

-

-

-

-

-

-

-  
pseye(4)

-  
Sony PlayStation Eye webcam device driver

-  
udl(4)

-  
DisplayLink DL-1x0/1x5 USB display devices

-  
uvideo(4)

-  
USB video class devices (e.g. webcams, capture cards)

-

-

-

-

-

-

-

-  
slurm(4)

-  
Silicon Labs USB FM radios

-  
udsbr(4)

-  
D-Link DSB-R100 USB radio device

-

-

-

-

-

-

-

-  
uatp(4)

-  
Apple trackpads

-  
uep(4)

-  
eGalax touch panel controllers

-  
uhid(4)

-  
Generic driver for Human Interface Devices

-  
uhidev(4)

-  
Base driver for all Human Interface Devices

-  
uintuos(4)

-  
Wacom Intuos drawing tablets

-  
ukbd(4)

-  
USB keyboards that follow the boot protocol

-  
ums(4)

-  
USB mouse devices

-  
uthum(4)

-  
TEMPer and TEMPerHUM temperature and humidity sensors

-  
uts(4)

-  
Generic driver for touchscreens and touch digitizers

-

-

-

-

-

-

-

-  
stuirda(4)

-  
Sigmaltel 4116/4220 USB-IrDA bridge

-  
ualea(4)

-  
USB Araneus Alea I/II random number generators

-  
uberry(4)

-  
Battery charging RIM BlackBerry phones via USB

-  
ugen(4)

-  
USB generic devices

-  
uipad(4)

-  
Battery charging iOS devices via USB

-  
uirda(4)

-  
USB IrDA bridges

-  
upl(4)

-  
Prolific based host-to-host adapters

-  
usscanner(4)

-  
SCSI-over-USB scanners

-  
ustir(4)

-  
SigmaTel STIr4200 USB IrDA bridges

-  
utoppy(4)

-  
Topfield TF5000PVR range of digital video recorders

-

-

-

-

-

-

-
The USB 1.x is a 12 Mb/s serial bus with 1.5 Mb/s for low speed
-    devices. USB 2.x handles 480 Mb/s. Each USB has a host controller that is
-    the master of the bus; all other devices on the bus only speak when spoken
-    to.

-
There can be up to 127 devices (apart from the host controller) on
-    a bus, each with its own address. The addresses are assigned dynamically by
-    the host when each device is attached to the bus.

-
Within each device there can be up to 16 endpoints. Each endpoint
-    is individually addressed and the addresses are static. Each of these
-    endpoints will communicate in one of four different modes: control,
-    isochronous, bulk, or interrupt. A device always has at least one endpoint.
-    This endpoint has address 0 and is a control endpoint and is used to give
-    commands to and extract basic data, such as descriptors, from the device.
-    Each endpoint, except the control endpoint, is unidirectional.

-
The endpoints in a device are grouped into interfaces. An
-    interface is a logical unit within a device; e.g., a compound device with
-    both a keyboard and a trackball would present one interface for each. An
-    interface can sometimes be set into different modes, called alternate
-    settings, which affects how it operates. Different alternate settings can
-    have different endpoints within it.

-
A device may operate in different configurations. Depending on the
-    configuration the device may present different sets of endpoints and
-    interfaces.

-
Each device located on a hub has several
-    config(1) locators:

-

-  
port

-  
this is the number of the port on closest upstream hub.

-  
configuration

-  
this is the configuration the device must be in for this driver to attach.
-      This locator does not set the configuration; it is iterated by the bus
-      enumeration.

-  
interface

-  
this is the interface number within a device that an interface driver
-      attaches to.

-  
vendor

-  
this is the 16 bit vendor id of the device.

-  
product

-  
this is the 16 bit product id of the device.

-  
release

-  
this is the 16 bit release (revision) number of the device.

-

-The first locator can be used to pin down a particular device according to its
-  physical position in the device tree. The last three locators can be used to
-  pin down a particular device according to what device it actually is.
-
The bus enumeration of the USB bus proceeds in several steps:

-
    
-  
  1. Any device specific driver can attach to the device.
    2. 
-  
  2. If none is found, any device class specific driver can attach.
    3. 
-  
  3. If none is found, all configurations are iterated over. For each
-      configuration all the interface are iterated over and interface drivers
-      can attach. If any interface driver attached in a certain configuration
-      the iteration over configurations is stopped.
    4. 
-  
  4. If still no drivers have been found, the generic USB driver can
-    attach.
    5. 
-

-

-

-

-
Use the following to get access to the USB specific structures and
-    defines.

-

-
#include <dev/usb/usb.h>

-

-
The /dev/usbN can be opened and a few
-    operations can be performed on it. The poll(2) system call
-    will say that I/O is possible on the controller device when a USB device has
-    been connected or disconnected to the bus.

-
The following ioctl(2) commands are supported on
-    the controller device:

-

-  

-    struct usb_device_info

-  
This command can be used to retrieve some information about a device on
-      the bus. The addr field should be filled before the
-      call and the other fields will be filled by information about the device
-      on that address. Should no such device exist an error is reported.
-    

-    
struct usb_device_info {
-	uint8_t	udi_bus;
-	uint8_t	udi_addr;
-	usb_event_cookie_t udi_cookie;
-	char		udi_product[USB_MAX_ENCODED_STRING_LEN];
-	char		udi_vendor[USB_MAX_ENCODED_STRING_LEN];
-	char		udi_release[8];
-	char		udi_serial[USB_MAX_ENCODED_STRING_LEN];
-	uint16_t	udi_productNo;
-	uint16_t	udi_vendorNo;
-	uint16_t	udi_releaseNo;
-	uint8_t	udi_class;
-	uint8_t	udi_subclass;
-	uint8_t	udi_protocol;
-	uint8_t	udi_config;
-	uint8_t	udi_speed;
-#define USB_SPEED_LOW  1
-#define USB_SPEED_FULL 2
-#define USB_SPEED_HIGH 3
-	int		udi_power;
-	int		udi_nports;
-	char		udi_devnames[USB_MAX_DEVNAMES][USB_MAX_DEVNAMELEN];
-	uint8_t	udi_ports[16];
-#define USB_PORT_ENABLED 0xff
-#define USB_PORT_SUSPENDED 0xfe
-#define USB_PORT_POWERED 0xfd
-#define USB_PORT_DISABLED 0xfc
-};

-    

-    
The product,
-        vendor, release, and
-        serial fields contain self-explanatory
-        descriptions of the device.

-    
The class field contains the device
-        class.

-    
The config field shows the current
-        configuration of the device.

-    
The lowspeed field is set if the device
-        is a USB low speed device.

-    
The power field shows the power
-        consumption in milli-amps drawn at 5 volts, or zero if the device is
-        self powered.

-    
If the device is a hub the nports field
-        is non-zero and the ports field contains the
-        addresses of the connected devices. If no device is connected to a port
-        one of the USB_PORT_* values indicates its
-      status.

-  

-  

-    struct usb_device_stats

-  
This command retrieves statistics about the controller.
-    

-    
struct usb_device_stats {
-	u_long	uds_requests[4];
-};

-    

-    
The requests field is indexed by the
-        transfer kind, i.e. UE_*, and indicates how many
-        transfers of each kind have been completed by the controller.

-  

-  

-    struct usb_ctl_request

-  
This command can be used to execute arbitrary requests on the control
-      pipe. This is
-      
-      and should be used with great care since it can destroy the bus
-    integrity.

-

-
The include file
-    <dev/usb/usb.h> contains
-    definitions for the types used by the various ioctl(2)
-    calls. The naming convention of the fields for the various USB descriptors
-    exactly follows the naming in the USB specification. Byte sized fields can
-    be accessed directly, but word (16 bit) sized fields must be access by the
-    (field)
-    and
-    (field,
-    value) macros to handle byte order and alignment
-    properly.

-
The include file
-    <dev/usb/usbhid.h> similarly
-    contains the definitions for Human Interface Devices (HID).

-

-

-

-
All USB events are reported via the
-    /dev/usb device. This devices can be opened for
-    reading and each read(2) will yield an event record (if
-    something has happened). The poll(2) system call can be
-    used to determine if an event record is available for reading.

-
The event record has the following definition:

-

-
struct usb_event {
-        int                                 ue_type;
-#define USB_EVENT_CTRLR_ATTACH 1
-#define USB_EVENT_CTRLR_DETACH 2
-#define USB_EVENT_DEVICE_ATTACH 3
-#define USB_EVENT_DEVICE_DETACH 4
-#define USB_EVENT_DRIVER_ATTACH 5
-#define USB_EVENT_DRIVER_DETACH 6
-        struct timespec                     ue_time;
-        union {
-                struct {
-                        int                 ue_bus;
-                } ue_ctrlr;
-                struct usb_device_info      ue_device;
-                struct {
-                        usb_event_cookie_t  ue_cookie;
-                        char                ue_devname[16];
-                } ue_driver;
-        } u;
-};

-

-
The ue_type field identifies the type of
-    event that is described. The possible events are attach/detach of a host
-    controller, a device, or a device driver. The union contains information
-    pertinent to the different types of events.

-
The ue_bus contains the number of the USB
-    bus for host controller events.

-
The ue_device record contains information
-    about the device in a device event event.

-
The ue_cookie is an opaque value that
-    uniquely determines which device a device driver has been attached to (i.e.,
-    it equals the cookie value in the device that the driver attached to). The
-    ue_devname contains the name of the device (driver) as
-    seen in, e.g., kernel messages.

-
Note that there is a separation between device and device driver
-    events. A device event is generated when a physical USB device is attached
-    or detached. A single USB device may have zero, one, or many device drivers
-    associated with it.

-

-

-

-
For each USB bus, i.e., for each host controller, there is a
-    kernel thread that handles attach and detach of devices on that bus. The
-    thread is named usbN where N is
-    the bus number.

-
In addition there is a kernel thread,
-    usbtask, which handles various minor tasks that are
-    initiated from an interrupt context, but need to sleep, e.g., time-out abort
-    of transfers.

-

-

-

-
usbhidaction(1), usbhidctl(1),
-    cardbus(4), ehci(4),
-    isa(4), ohci(4),
-    pci(4), pcmcia(4),
-    slhci(4), uhci(4),
-    xhci(4), usbdevs(8)

-
Universal Serial Bus
-    Specifications Documents,
-    http://www.usb.org/developers/docs/.

-

-

-

-
The usb driver appeared in
-    NetBSD 1.4.

-

-

-

-
There should be a serial number locator, but
-    NetBSD does not have string valued locators.

-

-

-
-  
-    
-    
-  
-
April 1, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/usbnet.4 3.html b/static/netbsd/man4/usbnet.4 3.html
deleted file mode 100644
index 80fcef3e..00000000
--- a/static/netbsd/man4/usbnet.4 3.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
USBNET(4)Device Drivers ManualUSBNET(4)

-

-

-

-
usbnet — generic
-    USB network driver backend diagnostics

-

-

-

-
The usbnet subsystem provides support for
-    USB network devices. This manual describes diagnostics that may be seen.

-

-

-

-

-  
devN: sysctl_createv failed

-  
Unable to create debug node for NetBSD.

-  
devN: usb errors on rx

-  
Error status from device upon Rx interrupt, device may be
-    non-functional.

-  
devN: usb error on tx

-  
Error status from device upon Tx interrupt., device may be
-    non-functional.

-  
devN: usb error on intr

-  
Error status from device upon interrupt, device may be
-    non-functional.

-  
devN: rxeof: too large transfer

-  
Network input rejected.

-  
devN: close pipe N

-  
Closing of Rx, Tx or Interrupt pipe failed, device may be
-    non-functional.

-  
devN: open rx/tx pipes failed

-  
Opening of Rx or Tx pipes failed, device non-functional.

-  
devN: [rt]x list init failed

-  
Creation of Rx or Tx list failed, device non-functional.

-  
devN: watchdog timeout

-  
Time out in transmission.

-  
devN: pipe abort failed

-  
Aborting USB pipes after watchdog timeout failed.

-  
devN: couldn't establish power handler

-  
Call to pmf_device_register(9) failed, disabling system
-      suspend.

-

-
The usbnet manual lists generic
-    diagnostics generated by USB network devices.

-

-

-

-
arp(4), aue(4),
-    axe(4), axen(4),
-    cdce(4), cue(4),
-    ifmedia(4), intro(4),
-    kue(4), mos(4),
-    mue(4), netintro(4),
-    smsc(4), udav(4),
-    upl(4), ure(4),
-    url(4), urndis(4),
-    usb(4), usbnet(9)

-

-

-

-
The usbnet framework first appeared in
-    NetBSD 9.0.

-

-

-

-
The usbnet framework was written by
-    Matthew R. Green
-    <mrg@eterna23.net>

-

-

-
-  
-    
-    
-  
-
June 15, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/userconf.4 4.html b/static/netbsd/man4/userconf.4 4.html
deleted file mode 100644
index 605fd348..00000000
--- a/static/netbsd/man4/userconf.4 4.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
USERCONF(4)Device Drivers ManualUSERCONF(4)

-

-

-

-
userconf —
-    in-kernel device configuration manager

-

-

-

-
options USERCONF

-

-

-

-
userconf is the in-kernel device
-    configuration manager. It is used to alter the kernel autoconfiguration
-    framework at runtime. userconf is activated from the
-    boot loader by passing the -c option to the
-  kernel.

-

-

-

-
The general command syntax is:

-
command
-  [option]

-
userconf has a
-    more(1)-like functionality; if a number of lines in a
-    command's output exceeds the number defined in the lines variable, then
-    userconf displays “-- more --” and
-    waits for a response, which may be one of:

-

-

-  
<return>

-  
one more line.

-  
<space>

-  
one more page.

-  

-  
abort the current command, and return to the command input mode.

-

-

-

-

-

-
userconf supports the following
-  commands:

-

-  

-    count

-  
Specify the number of lines before more.

-  

-    8 | 10 |
-    16

-  
Base for displaying large numbers.

-  

-    devno | dev

-  
Change devices.

-  

-    devno | dev

-  
Disable devices.

-  

-    devno | dev

-  
Enable devices.

-  

-  
A synonym for quit.

-  

-    devno | dev

-  
Find devices.

-  

-  
Display online help.

-  

-  
List current configuration.

-  

-  
Leave userconf.

-  

-  
A synonym for help.

-

-

-

-

-
The userconf framework first appeared in
-    OpenBSD 2.0, and was then integrated into
-    NetBSD 1.6.

-

-

-

-
The userconf framework was written by
-    Mats O Jansson
-    <moj@stacken.kth.se>.

-

-

-
-  
-    
-    
-  
-
July 1, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/uslsa.4 4.html b/static/netbsd/man4/uslsa.4 4.html
deleted file mode 100644
index 428d6a86..00000000
--- a/static/netbsd/man4/uslsa.4 4.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
USLSA(4)Device Drivers ManualUSLSA(4)

-

-

-

-
uslsa — USB
-    support for Silicon Labs CP210x series serial adapters

-

-

-

-
uslsa* at uhub?
-  

-  ucom* at uslsa?

-

-

-

-
The uslsa driver is known to work with the
-    following adapters:

-

-

-

-  
Adafruit 954 USB to TTL Serial Cable

-  
 

-  
Helicomm IP-Link 1220-DVM

-  
 

-  
Nokia CA-42 USB

-  
 

-  
Siemens MC60 Data Cable

-  
 

-  
Suunto USB Serial Adaptor

-  
 

-

-

-

-

-

-
The uslsa driver provides support for the
-    Silicon Labs USB-to-RS-232 Bridge chip.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-
Silicon
-    Laboratories.

-
Silicon Laboratories AN571:
-    CP210x Virtual COM Port Interface..

-

-

-

-
The uslsa driver appeared in
-    NetBSD 4.0.

-

-

-

-
The uslsa driver was written by
-    Jonathan A. Kollasch. Code and style was borrowed
-    from existing NetBSD USB-serial drivers.

-

-

-

-
Settings other than 8 data bits, no parity, and 1 stop bit seem to
-    be refused by the CP2101.

-

-

-
-  
-    
-    
-  
-
January 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/usmsc.4 4.html b/static/netbsd/man4/usmsc.4 4.html
deleted file mode 100644
index 819557d3..00000000
--- a/static/netbsd/man4/usmsc.4 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
USMSC(4)Device Drivers ManualUSMSC(4)

-

-

-

-
usmsc — SMSC
-    LAN95xx 10/100 USB Ethernet device

-

-

-

-
usmsc* at uhub?
-  

-  ukphy* at mii?

-

-

-

-
The usmsc driver supports SMSC
-    LAN9500/LAN9500A/LAN9530/LAN9730/LAN89530 USB 2.0 10/100 Ethernet devices
-    and LAN951x USB 2.0 hub and 10/100 Ethernet devices, including:

-

-

-

-  
RaspberryPI

-  
 

-  
Gamber Johnson MAG Docking Station 7160-0204

-  
 

-  
Gamber Johnson MAG Docking Station 7160-0205

-  
 

-  
Gamber Johnson MAG Docking Station 7160-0227

-  
 

-  
GWC Technology HE2440

-  
 

-  
HP USB Media Port Replicator

-  
 

-  
j5create Newport Station JUD200

-  
 

-  
Kensington Universal Notebook Docking Station (K33926US)

-  
 

-  
LevelOne USB-0501

-  
 

-  
Samsung Central Station monitors

-  
 

-  
StarTech USBVGADOCK2

-  
 

-  
XPower XP2440

-  
 

-

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
See usbnet(4) for diagnostics.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    uhub(4), ukphy(4),
-    usb(4), usbnet(4),
-    ifconfig(8)

-

-

-

-
The usmsc driver was written by
-    Ben Gray ⟨bgray@freebsd.org⟩ for
-    FreeBSD and ported to NetBSD
-    from the OpenBSD version by Nick
-    Hudson ⟨skrll@netbsd.org⟩.

-
The usmsc driver first appeared in
-    NetBSD 7.0.

-

-

-
-  
-    
-    
-  
-
August 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/usscanner.4 4.html b/static/netbsd/man4/usscanner.4 4.html
deleted file mode 100644
index 05e40b71..00000000
--- a/static/netbsd/man4/usscanner.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
USSCANNER(4)Device Drivers ManualUSSCANNER(4)

-

-

-

-
usscanner — driver
-    for some SCSI-over-USB scanners

-

-

-

-
usscanner* at uhub?
-  

-  scsibus* at usscanner?
-  

-  ss* at scsibus?

-

-

-

-
The usscanner provides support for some
-    scanners based on non-standard SCSI-over-USB, e.g., HP5300C.

-

-

-

-
The usscanner driver works with the
-    following scanners:

-

-

-

-

-  
HP ScanJet 5300C

-  
 

-

-

-

-

-

-

-
scsi(4), usb(4),
-    pkgsrc/graphics/sane-backends

-

-

-

-
The usscanner driver appeared in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
January 11, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/ustir.4 4.html b/static/netbsd/man4/ustir.4 4.html
deleted file mode 100644
index 4a2ca4aa..00000000
--- a/static/netbsd/man4/ustir.4 4.html	
+++ /dev/null
@@ -1,62 +0,0 @@
-
-  
-    
-    
-    
-  
-
USTIR(4)Device Drivers ManualUSTIR(4)

-

-

-

-
ustir — SigmaTel
-    STIr4200-based USB-IrDA bridge support

-

-

-

-
ustir* at uhub?
-  

-  irframe* at ustir?

-

-

-

-
The ustir driver provides support for
-    USB-IrDA bridges based on the SigmaTel STIr4200. The driver is known to work
-    with the following adapters:

-

-
    
-  
  • Mars II 740 USB IrDA Adapter
    • 
-

-
Access to the IrDA device is through the
-    irframe(4) driver.

-

-

-

-
irframe(4), uirda(4),
-    usb(4)

-

-

-

-
The ustir driver appeared in
-    NetBSD 1.6.

-

-

-

-
The ustir driver was written by
-    David Sainty
-    <dsainty@NetBSD.org>.

-

-

-

-
The STIr4200 cannot notify the driver when it has received data,
-    instead it has to be continuously polled. This driver polls (when idle) at a
-    fairly low rate of 10 times per second, which means that system performance
-    is not overly affected by rapid polling, but latency is fairly high.

-

-

-
-  
-    
-    
-  
-
December 24, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/uthum.4 4.html b/static/netbsd/man4/uthum.4 4.html
deleted file mode 100644
index 18014d99..00000000
--- a/static/netbsd/man4/uthum.4 4.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
UTHUM(4)Device Drivers ManualUTHUM(4)

-

-

-

-
uthum — TEMPer and
-    TEMPerHUM USB temperature and humidity sensor

-

-

-

-
uthum* at uhidev? reportid ?

-

-

-

-
The uthum driver provides support for the
-    pcsensors TEMPer and TEMPerHUM HID device. The sensor possesses a collection
-    of sensor values which are made available through the
-    envstat(8) interface. The humidity data unit is
-    “%RH” and the temperature data unit is
-  “degC”.

-

-

-

-
intro(4), uhidev(4),
-    envstat(8)

-

-

-

-
The uthum driver was originally written by
-    Yojiro UO
-    <yuo@nui.org>.
-    NetBSD porting was done by Antoine
-    Reilles
-    <tonio@NetBSD.org>.

-

-

-

-
The TEMPer and TEMperHUM have various versions which have the same
-    VID/PID and they need different data processing. Currently only two types
-    are supported.

-

-

-
-  
-    
-    
-  
-
November 23, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/utoppy.4 4.html b/static/netbsd/man4/utoppy.4 4.html
deleted file mode 100644
index 96b45781..00000000
--- a/static/netbsd/man4/utoppy.4 4.html	
+++ /dev/null
@@ -1,235 +0,0 @@
-
-  
-    
-    
-    
-  
-
UTOPPY(4)Device Drivers ManualUTOPPY(4)

-

-

-

-
utoppy — USB
-    driver for the Topfield TF5000PVR range of digital video
-  recorders

-

-

-

-
utoppy* at uhub? port ?

-

-  

-  #include
-  <dev/usb/utoppy.h>

-

-

-

-
The utoppy driver provides support for the
-    Topfield TF5000PVR range of DVB recorders (nicknamed
-    ‘Toppy’) which are popular in Europe
-    and Australia. These recorders have a USB device interface which can be used
-    to transfer recordings to and from the unit's hard disk. The USB interface
-    can also be used to upload binary images for execution on the Toppy's MIPS
-    cpu.

-
The Toppy's USB protocol has not been officially documented by
-    Topfield, but the basic features have been reverse engineered by others in
-    order to write replacements for the official
-    ‘Altair’ download/upload program from
-    Topfield.

-
Existing replacements for Altair suffer from the fact that they
-    are ultimately built on top of ugen(4). This has a number
-    of detrimental side-effects:

-
    
-  
  1. Performance suffers since all Toppy command packets have to cross the
-      user-kernel interface.
    2. 
-  
  2. The userland programs are full of clutter to deal with interpreting the
-      command/status packets, not to mention byte-swapping and host endian
-      issues.
    3. 
-  
  3. Signals can interrupt a data transfer at a critical point, leaving the
-      Toppy in an undefined state. For example, interrupting a download with
-      ‘Turbo’ mode enabled will leave the
-      Toppy completely unresponsive to the remote control, and prevent
-      timer-based recordings from starting.
    4. 
-

-
The utoppy driver provides a clean and
-    stable interface to the Toppy protocol, and ensures that an interrupt caused
-    by a signal does not leave the Toppy in an undefined state.

-

-

-

-
Use the following header file to get access to the utoppy specific
-    structures and defines.

-

-
#include <dev/usb/utoppy.h>

-

-
The utoppy driver can be accessed through
-    the /dev/utoppyN character device. The primary means
-    of controlling the driver is by issuing a series of
-    ioctl(2) system calls followed by
-    read(2) or write(2) system calls as
-    appropriate.

-
The following ioctl(2) commands are supported by
-    the utoppy driver:

-

-  

-    int *mode

-  
This command can be used to enable or disable
-      ‘Turbo’ mode for subsequent
-      UTOPPYIOREADFILE or
-      UTOPPYIOWRITEFILE commands (see below). If
-      num is non-zero, Turbo mode will be enabled.
-      Otherwise Turbo mode will be disabled. In non-Turbo mode, the Toppy's USB
-      interface is capable of sustaining around 5.6 Mbit/s during a file
-      transfer. With Turbo mode enabled, it can sustain just over 16 Mbit/s. Of
-      course, these figures are valid only if the Toppy is connected via a USB
-      2.0 interface. Performance using an older USB 1 interface will be
-      significantly lower.

-  

-    void

-  
This command can be used to abort an in-progress
-      UTOPPYIOREADDIR,
-      UTOPPYIOREADFILE, or
-      UTOPPYIOWRITEFILE command.

-  

-    void

-  
This command will cause the Toppy to reboot cleanly.

-  

-    struct utoppy_stats *stats

-  
This command retrieves statistics for the Toppy's hard disk.
-    

-    
struct utoppy_stats {
-	uint64_t us_hdd_size;	/* Size of the disk, in bytes */
-	uint64_t us_hdd_free;	/* Free space, in bytes */
-};

-    

-  

-  
UTOPPYIORENAME struct utoppy_rename *rename

-  
This command is used to rename a file or directory on the Toppy's hard
-      disk. The full pathname to each file must be provided.
-    

-    
struct utoppy_rename {
-	char *ur_old_path;	/* Path to existing file */
-	char *ur_new_path;	/* Path to new file */
-};

-    

-  

-  
UTOPPYIOMKDIR char *path

-  
This command creates the directory specified by
-      path.

-  
UTOPPYIODELETE char *path

-  
This command deletes the file or directory specified by
-      path.

-  
UTOPPYIOREADDIR char *path

-  
This command initiates a read of the contents of the directory specified
-      by path. After issuing this command, the directory
-      contents must be read using consecutive read(2) system
-      calls. Each read(2) will transfer one or more directory
-      entries into the user-supplied buffer. The buffer must be large enough to
-      receive at least one directory entry. When read(2)
-      returns zero, all directory entries have been read.
-    
A directory entry is described using the following data
-        structure:

-    

-    
struct utoppy_dirent {
-	char ud_path[UTOPPY_MAX_FILENAME_LEN + 1];
-	enum {
-		UTOPPY_DIRENT_UNKNOWN,
-		UTOPPY_DIRENT_DIRECTORY,
-		UTOPPY_DIRENT_FILE
-	} ud_type;
-	off_t ud_size;
-	time_t ud_mtime;
-	uint32_t ud_attributes;
-};

-    

-    
The ud_path field contains the name of
-        the directory entry.

-    
The ud_type field specifies whether the
-        entry corresponds to a file or a sub-directory.

-    
The ud_size field is valid for files
-        only, and specifies the file's size in bytes.

-    
The ud_mtime field describes the file or
-        directory's modification time, specified as seconds from the Unix epoch.
-        The timestamp is relative to the current timezone, so
-        localtime(3) can be used to convert it into human
-        readable form. Note that the Toppy sets directory timestamps to a
-        predefined value so they are not particularly useful.

-    
The ud_attributes field is not used at
-        this time.

-  

-  
UTOPPYIOREADFILE struct utoppy_readfile *

-  
This command is used to initiate reading a file from the Toppy's hard
-      disk. The full pathname, together with the file offset at which to start
-      reading, is specified using the following data structure:
-    

-    
struct utoppy_readfile {
-	char *ur_path;
-	off_t ur_offset;
-};

-    

-    
After issuing this command, the file must be read using
-        consecutive read(2) system calls. When
-        read(2) returns zero, the entire file has been
-      read.

-  

-  
UTOPPYIOWRITEFILE struct utoppy_writefile *

-  
This command is used to initiate writing to a file on the Toppy's hard
-      disk. The file to be written is described using the following data
-      structure:
-    

-    
struct utoppy_writefile {
-	char *uw_path;
-	off_t uw_offset;
-	off_t uw_size;
-	time_t uw_mtime;
-};

-    

-    
The uw_path field specifies the full
-        pathname of the file to be written.

-    
The uw_offset field specifies the file
-        offset at which to start writing, assuming the file already exists.
-        Otherwise, uw_offset must be zero.

-    
The protocol requires that the Toppy must be informed of a
-        file's size in advance of the file being written. This is accomplished
-        using the uw_size field. It may be possible to
-        work around this limitation in a future version of the driver.

-    
The uw_mtime field specifies the file's
-        timestamp expressed as seconds from the Unix epoch in the local
-        timezone.

-  

-

-
Due to limitations with the protocol, a
-    utoppy device can be opened by only one application
-    at a time. Also, only a single UTOPPYIOREADDIR,
-    UTOPPYIOREADFILE, or
-    UTOPPYIOWRITEFILE command can be in progress at any
-    given time.

-

-

-

-

-  
/dev/utoppy0

-  
device node

-

-

-

-

-
utoppya(1), usb(4)

-

-

-

-
The utoppy driver appeared in
-    NetBSD 4.0.

-

-

-

-
Steve C. Woodford
-    <scw@netbsd.org>

-

-

-
-  
-    
-    
-  
-
April 3, 2006NetBSD 10.1

diff --git a/static/netbsd/man4/uts.4 4.html b/static/netbsd/man4/uts.4 4.html
deleted file mode 100644
index 050d8f92..00000000
--- a/static/netbsd/man4/uts.4 4.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
UTS(4)Device Drivers ManualUTS(4)

-

-

-

-
uts — USB generic
-    touchscreens

-

-

-

-
uts* at uhidev? reportid ?
-  

-  wsmouse* at uts?

-

-

-

-
The uts driver provides support for USB
-    touchscreens, otherwise known as Touch Digitizer devices. Access to panel
-    events is through the wsmouse(4) driver.

-

-

-

-
uhidev(4), wsmouse(4)

-

-

-

-
The uts driver was written by Pierre
-    Pronchery for NetBSD. The
-    uts driver appeared in NetBSD
-    6.0.

-

-

-

-
uts currently does not support
-    calibration. Also, not all NetBSD-supplied X servers
-    support the absolute position events it generates.

-

-

-
-  
-    
-    
-  
-
January 16, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/uvideo.4 4.html b/static/netbsd/man4/uvideo.4 4.html
deleted file mode 100644
index ff672205..00000000
--- a/static/netbsd/man4/uvideo.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
UVIDEO(4)Device Drivers ManualUVIDEO(4)

-

-

-

-
uvideo — USB video
-    device driver

-

-

-

-
uvideo* at uhub?
-  

-  video* at videobus?

-

-

-

-
The uvideo driver provides support for USB
-    video class devices.

-
A USB video device consists of a number of components. Every
-    device has one control interface. Each device optionally provides streaming
-    interfaces (input or output).

-

-

-

-
usb(4), video(4),
-    video(9)

-
USB Approved Class
-    Specification Documents,
-    http://www.usb.org/developers/devclass_docs/.

-

-

-

-
Patrick Mahoney
-    <pat@polycrystal.org>

-

-

-

-
Does not support all of UVC spec. Only supports the one streaming
-    input interface. Does not support the interrupt endpoint for some
-  controls.

-
Exports the Video4Linux2 API via video(9), and
-    V4L2 lacks support for some UVC features such as still images.

-

-

-
-  
-    
-    
-  
-
September 20, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/uvisor.4 4.html b/static/netbsd/man4/uvisor.4 4.html
deleted file mode 100644
index 27ba1d9c..00000000
--- a/static/netbsd/man4/uvisor.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
UVISOR(4)Device Drivers ManualUVISOR(4)

-

-

-

-
uvisor — USB
-    support for the Handspring Visor, a Palmpilot compatible PDA

-

-

-

-
uvisor* at uhub?
-  

-  ucom* at uvisor? portno ?

-

-

-

-
The uvisor driver provides support for the
-    Handspring Visor, a Palmpilot compatible PDA.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4). The device has
-    several ports for different purposes, each of them gets its own
-    ucom(4) device. The attach message describes the purpose
-    of each port.

-
The usual Pilot tools can be used to access the Visor on the
-    HotSync port.

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The uvisor driver appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
March 10, 2000NetBSD 10.1

diff --git a/static/netbsd/man4/uvscom.4 4.html b/static/netbsd/man4/uvscom.4 4.html
deleted file mode 100644
index 978c9a97..00000000
--- a/static/netbsd/man4/uvscom.4 4.html	
+++ /dev/null
@@ -1,48 +0,0 @@
-
-  
-    
-    
-    
-  
-
UVSCOM(4)Device Drivers ManualUVSCOM(4)

-

-

-

-
uvscom — USB
-    support for SUNTAC Slipper U VS-10U serial adapters driver

-

-

-

-
uvscom* at uhub?
-  

-  ucom* at uvscom?

-

-

-

-
The uvscom driver provides support for the
-    SUNTAC Slipper U VS-10U chip. Slipper U is a PC Card to USB converter for
-    data communication card adapters. It supports DDI Pocket's Air H" C@rd,
-    C@rd H" 64, NTT's P-in, P-in m@ster, and various other data
-    communication card adapters.

-
The device is accessed through the ucom(4)
-    driver which makes it behave like a tty(4).

-

-

-

-
tty(4), ucom(4),
-    usb(4)

-

-

-

-
The uvscom driver first appeared in
-    FreeBSD and later in NetBSD
-    1.6.

-

-

-
-  
-    
-    
-  
-
May 21, 2001NetBSD 10.1

diff --git a/static/netbsd/man4/uxrcom.4 4.html b/static/netbsd/man4/uxrcom.4 4.html
deleted file mode 100644
index 038b2bc2..00000000
--- a/static/netbsd/man4/uxrcom.4 4.html	
+++ /dev/null
@@ -1,72 +0,0 @@
-
-  
-    
-    
-    
-  
-
UXRCOM(4)Device Drivers ManualUXRCOM(4)

-

-

-

-
uxrcom — Exar
-    XR21V141x USB serial adapter

-

-

-

-
uxrcom* at uhub?
-  

-  ucom* at uxrcom?

-

-

-

-
The uxrcom driver supports serial adapters
-    based on the XR21V1410, XR21V1412, and XR21V1414 chipsets. Devices range
-    from single port to eight port (implemented as a USB hub and two
-    uxrcom four port instances behind it). Examples of
-    hardware known to work with this driver are:

-

-

-

-  
Gearmo GM-U28RS232 8 Port USB to Serial DB9 RS232 Adapter

-  
 

-

-

-

-

-

-
The uxrcom driver attaches the Exar
-    XR21V141x multiport chipset with individual port drivers via
-    ucom(4), which makes it behave like a
-    tty(4).

-

-

-

-
tty(4), ucom(4),
-    uhub(4), umodem(4),
-    usb(4)

-

-

-

-
The uxrcom device driver first appeared in
-    OpenBSD 6.5 and in NetBSD
-    9.1.

-

-

-

-
The uxrcom driver for the single port
-    XR21V1410 was written by Mark Kettenis
-    <kettenis@openbsd.org>.
-    The multi-port NetBSD driver is based on the
-    OpenBSD driver but uses the common
-    umodem(4) framework. The NetBSD
-    driver was written by by Simon Burge
-    <simonb@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 12, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/vald.4 4.html b/static/netbsd/man4/vald.4 4.html
deleted file mode 100644
index 23dcff82..00000000
--- a/static/netbsd/man4/vald.4 4.html	
+++ /dev/null
@@ -1,63 +0,0 @@
-
-  
-    
-    
-    
-  
-
VALD(4)Device Drivers Manual (i386)VALD(4)

-

-

-

-
vald — Toshiba
-    Programmable I/O controller

-

-

-

-
vald* at acpi?

-

-

-

-
Some Toshiba computers have a special I/O controller that handles
-    various interface devices. This special I/O controller is accessed by the
-    “GHCI” ACPI method. The vald driver
-    provides some support for it.

-
The vald driver handles the following
-    hot-keys:

-

-

-

-  
Fn+F5

-  
Switch between LCD and External Video output.

-  
Fn+F6

-  
Decrease LCD brightness.

-  
Fn+F7

-  
Increase LCD brightness.

-  
Fn+F8

-  
Switch fan (ON/OFF).

-

-

-
The vald driver has only been tested on
-    the Libretto L3 and on the Portege 3440.

-

-

-

-
acpi(4)

-

-

-

-
The vald driver appeared in
-    NetBSD 1.6.

-

-

-

-
vald may have problems with X11 when
-    switching between LCD and External Video output.

-

-

-
-  
-    
-    
-  
-
January 25, 2008NetBSD 10.1

diff --git a/static/netbsd/man4/valz.4 4.html b/static/netbsd/man4/valz.4 4.html
deleted file mode 100644
index 9c48afe0..00000000
--- a/static/netbsd/man4/valz.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
VALZ(4)Device Drivers ManualVALZ(4)

-

-

-

-
valz — Toshiba
-    Programmable I/O controller for Dynabook series

-

-

-

-
valz* at acpi?

-

-

-

-
Toshiba Dynabook series computers provide HCI/SCI I/O controllers
-    that handle various interface devices. This special I/O controller is
-    accessed by the “GHCI” ACPI method. The
-    valz driver provides some support for it.

-
The valz driver handles the following
-    hot-keys:

-

-

-

-  
Fn+F9

-  
Toggle internal touchpad and trackpoint.

-  
Fn+Tab

-  
Toggle LCD backlight.

-

-

-
The valz driver has only been tested on
-    the Dynabook R63/PS and some Dynabook models from 2013 or later.

-

-

-

-
acpi(4), vald(4)

-

-

-

-
The valz driver appeared in
-    NetBSD 8.0.

-

-

-

-
Not all HCI/SCI functions are implemented.

-

-

-
-  
-    
-    
-  
-
October 12, 2015NetBSD 10.1

diff --git a/static/netbsd/man4/veriexec.4 4.html b/static/netbsd/man4/veriexec.4 4.html
deleted file mode 100644
index cf7c757a..00000000
--- a/static/netbsd/man4/veriexec.4 4.html	
+++ /dev/null
@@ -1,248 +0,0 @@
-
-  
-    
-    
-    
-  
-
VERIEXEC(4)Device Drivers ManualVERIEXEC(4)

-

-

-

-
veriexec —
-    Veriexec pseudo-device

-

-

-

-
pseudo-device veriexec

-

-

-

-
Veriexec verifies the integrity of specified
-    executables and files before they are run or read. This makes it much more
-    difficult to insert a trojan horse into the system and also makes it more
-    difficult to run binaries that are not supposed to be running, for example,
-    packet sniffers, DDoS clients and so on.

-
The veriexec pseudo-device is used to load
-    and delete entries to and from the in-kernel Veriexec
-    databases, as well as query information about them. It can also be used to
-    dump the entire database.

-

-

-
Veriexec uses proplib(3) for
-    communication between the kernel and userland.

-

-  

-  
Load an entry for a file to be monitored by Veriexec.
-    
The dictionary passed contains the following elements:

-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
filestringfilename for this entry
entry-typeuint8entry type (see below)
fp-typestringfingerprint hashing algorithm
fpdatathe fingerprint
keep-filenameboolwhether or not to retain the entry's filename

-    
“entry-type” can be one or more (binary-OR'd) of
-        the following:

-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
can execute directly
can execute indirectly (interpreter, mmap(2))
can be opened
located on untrusted storage

-  

-  

-  
Removes either an entry for a single file or entries for an entire mount
-      from Veriexec.
-    
The dictionary passed contains the following elements:

-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
filestringfilename or mount-point

-  

-  

-  
Dump the Veriexec monitored files database from the
-      kernel.
-    
Only files for which the filename was kept will be dumped. The
-        returned array contains dictionaries with the following elements:

-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
filestringfilename
fp-typestringfingerprint hashing algorithm
fpdatathe fingerprint
entry-typeuint8entry type (see above)

-  

-  

-  
Flush the Veriexec database, removing all entries.
-    
This command has no parameters.

-  

-  

-  
Queries Veriexec about a file, returning information
-      that may be useful about it.
-    
The dictionary passed contains the following elements:

-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
filestringfilename

-    
The dictionary returned contains the following elements:

-    
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-      
-        
-        
-        
-      
-    
entry-typeuint8entry type (see above)
statusuint8entry status
fp-typestringfingerprint hashing algorithm
fpdatathe fingerprint

-    
“status” can be one of the following:

-    
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-      
-        
-        
-      
-    
not evaluated
fingerprint match
fingerprint mismatch

-  

-

-
Note that the requests VERIEXEC_LOAD,
-    VERIEXEC_DELETE, and
-    VERIEXEC_FLUSH are not permitted once the strict
-    level has been raised past 0.

-

-

-

-

-
proplib(3), sysctl(3),
-    security(7), sysctl(8),
-    veriexecctl(8), veriexecgen(8),
-    veriexec(9)

-

-

-

-
veriexec is part of the default
-    configuration on the following architectures: amd64, i386, macppc, prep,
-    sparc64.

-

-

-

-
Brett Lymn
-    <blymn@NetBSD.org>
-  

-  Elad Efrat
-    <elad@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
January 17, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/vether.4 4.html b/static/netbsd/man4/vether.4 4.html
deleted file mode 100644
index 935d0d12..00000000
--- a/static/netbsd/man4/vether.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VETHER(4)Device Drivers ManualVETHER(4)

-

-

-

-
vether — virtual
-    Ethernet interface

-

-

-

-
pseudo-device vether

-

-

-

-
The vether interface simulates a normal
-    Ethernet interface by encapsulating standard network frames with an Ethernet
-    header, specifically for use as a member in a
-  bridge(4).

-
To use vether the administrator needs to
-    configure an address onto the interface so that packets can be routed to it.
-    An Ethernet header will be prepended and, if the
-    vether interface is a member of a
-    bridge(4), the frame will show up there.

-
The vether link state can be controlled
-    using ifconfig(8):

-

-

-

-  

-  
link state “up”

-  

-  
link state “down”

-

-

-

-

-

-
bridge(4), ifconfig(8)

-

-

-

-
The vether interface first appeared in
-    OpenBSD 4.7 and NetBSD
-  10.

-

-

-

-
Theo de Raadt
-    <deraadt@openbsd.org>

-

-

-

-
Like tap(4), the Ethernet address chosen will be
-    partially random, and may occasionally collide with another address.

-

-

-
-  
-    
-    
-  
-
September 26, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/vga.4 4.html b/static/netbsd/man4/vga.4 4.html
deleted file mode 100644
index 8a9f0f57..00000000
--- a/static/netbsd/man4/vga.4 4.html	
+++ /dev/null
@@ -1,131 +0,0 @@
-
-  
-    
-    
-    
-  
-
VGA(4)Device Drivers ManualVGA(4)

-

-

-

-
vga — VGA graphics
-    driver for wscons

-

-

-

-
options
-    VGA_CONSOLE_SCREENTYPE="??x??"
-  

-  options VGA_CONSOLE_ATI_BROKEN_FONTSEL

-

-  

-  vga0 at isa?
-  

-  vga* at pci?
-  

-  wsdisplay* at vga? console ?

-

-

-

-
This driver handles VGA graphics hardware within the
-    wscons(4) console framework. It doesn't provide direct
-    device driver entry points but makes its functions available via the
-    internal wsdisplay(4) interface.

-
The vga driver supports text-mode hardware
-    acceleration on the VGA hardware. Currently, the driver runs the display
-    with a 720×400 pixel resolution. The VGA text-mode accelerator
-    divides the display into fixed-size character cells. The size of the
-    character cells specifies the number of characters available on the screen
-    and the resolution of the font. The wsdisplay screen “types”
-    supported by the vga driver are described by the
-    number of character cells available on the screen. See below for a complete
-    list of supported screen modes in the vga
-  driver.

-
Each screen mode requires a suitable font to be loaded into the
-    kernel by the wsfontload(8) utility, before the screen can
-    be used. The size of the font and the screen mode must match for use on the
-    720×400 display. For example, a screen mode with 80 columns and 40
-    rows requires a font where each character is 8 pixels wide and 10 pixels
-    high. The vga driver can display fonts of the
-    original IBM type and ISO-8859-1 encoded fonts. A builtin font of 256
-    characters and 8×16 pixels is always present on the VGA hardware.

-
The colour VGA hardware supports the display of 16 different
-    colours at the same time. It is possible with VGA colour systems to use
-    fonts with 512 characters at any one time. This is due to the fact that with
-    VGA adapters one can specify an alternate font to be used instead of bright
-    letters (used for highlighting on the screen). As an experimental feature,
-    the “higher half” fonts of the former
-    NetBSD/i386 pcvt driver
-    distribution can be used too if the kernel option
-    “WSCONS_SUPPORT_PCVTFONTS” was set at compile time. This is
-    only useful with the “*bf” screen types; a font containing the
-    ASCII range of characters must be available too on this screen.

-
Currently, the following screen types are supported:

-

-  
80x25

-  
This is the standard VGA text mode with 80 columns and 25 rows. Sixteen
-      different colors can be displayed at the same time. Characters are
-      8×16 pixels, and a font consists of 256 characters.

-  
80x25bf

-  
is a modified version of the previous. It only allows 8 colors to be
-      displayed. In exchange, it can access two fonts at the same time, so that
-      512 different characters can be displayed.

-  
80x40

-  
A text mode with 80 columns and 40 rows. Similar to the standard mode, 16
-      colors and 256 characters are available. Characters are 8×10
-      pixels. For this mode to be useful, a font of that character size must be
-      downloaded.

-  
80x40bf

-  
is analogously to “80x25bf” a version with 512 displayable
-      characters but 8 colors only.

-  
80x50

-  
A text mode with 80 columns and 50 rows. Similar to the standard mode, 16
-      colors and 256 characters are available. Characters are 8×8 pixels.
-      For this mode to be useful, a font of that character size must be
-      downloaded.

-  
80x50bf

-  
is analogously to “80x25bf” a version with 512 displayable
-      characters but 8 colors only.

-  
80x24

-  
is a variant of the “80x25” screen type which displays 24
-      lines only. It uses the standard 8x16 VGA font. This mode might be useful
-      for applications which depend on closer DEC VT100 compatibility.

-  
80x24bf

-  
Analogously, like “80x24” but with 512 character slots and 8
-      colors.

-

-
If you have an Ati videocard and you are experiencing problems
-    with fonts other than 80x25, you can try to set options
-    VGA_CONSOLE_ATI_BROKEN_FONTSEL in you kernel configuration and see if
-    it helps.

-
The vga driver supports multiple virtual
-    screens on one physical display. The screens allocated on one display can be
-    of different “types”. The type is determined at the time the
-    virtual screen is created and can't be changed later. Screens are either
-    created at kernel startup (then the default type is used) or later with help
-    of the wsconscfg(8) utility.

-

-

-

-
isa(4), pcdisplay(4),
-    pci(4), wscons(4),
-    wsconscfg(8), wsfontload(8)

-

-

-

-
Only a subset of the possible text modes is supported.

-
VGA cards are supposed to emulate an MDA if a monochrome display
-    is connected. In this case, the device will naturally not support colors at
-    all, but offer the capability to display underlined characters instead. The
-    “80x25bf”, “80x40bf”, “80x50bf”
-    and “80x24bf” screen types will not be available. This mode of
-    operation has not been tested.

-

-

-
-  
-    
-    
-  
-
May 4, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/vge.4 4.html b/static/netbsd/man4/vge.4 4.html
deleted file mode 100644
index 039b1bb2..00000000
--- a/static/netbsd/man4/vge.4 4.html	
+++ /dev/null
@@ -1,148 +0,0 @@
-
-  
-    
-    
-    
-  
-
VGE(4)Device Drivers ManualVGE(4)

-

-

-

-
vge — VIA
-    Networking Technologies VT6122 PCI Gigabit Ethernet adapter
-  driver

-

-

-

-
vge* at pci? dev ? function ?

-
Configuration of PHYs is also necessary. See
-    mii(4).

-

-

-

-
The vge driver provides support for
-    various NICs and embedded Ethernet interfaces based on the VIA Networking
-    Technologies VT6122 Gigabit Ethernet controller chips.

-
The VT6122 is a 33/66Mhz 64-bit PCI device which combines a
-    tri-speed MAC with an integrated 10/100/1000 copper PHY. (Some older cards
-    use an external PHY.) The MAC supports TCP/IP hardware checksums (IPv4
-    only), TCP large send, VLAN tag insertion and stripping, as well as VLAN
-    filtering, a 64-entry CAM filter and a 64-entry VLAN filter, 64-bit
-    multicast hash filter, 4 separate transmit DMA queues, flow control and
-    jumbo frames up to 16K in size. The VT6122 has a 16K receive FIFO and 48K
-    transmit FIFO.

-
The vge driver takes advantage of the
-    VT6122's checksum offload and VLAN tagging features, as well as the jumbo
-    frame and CAM filter support. The CAM filter is used for multicast address
-    filtering to provide 64 perfect multicast address filter support. If it is
-    necessary for the interface to join more than 64 multicast groups, the
-    driver will switch over to using the hash filter.

-
The jumbo frame support can be enabled by setting the interface
-    MTU to any value larger than the default of 1500 bytes, up to a maximum of
-    9000 bytes. The receive and transmit checksum offload support can be toggled
-    on and off using the ifconfig(8) utility.

-
The vge driver supports the following
-    media types:

-

-  

-  
Enable autoselection of the media type and options. The user can manually
-      override the autoselected mode by adding media options to
-      rc.conf(5).

-  

-  
Set 10Mbps operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 100Mbps (Fast Ethernet) operation. The ifconfig(8)
-      mediaopt option can also be used to select either
-      full-duplex or half-duplex
-      modes.

-  

-  
Set 1000baseTX operation over twisted pair. The
-      ifconfig(8) mediaopt option can
-      also be used to select either full-duplex or
-      half-duplex modes.

-

-
The vge driver supports the following
-    media options:

-

-  

-  
Force full duplex operation.

-  

-  
Force half duplex operation.

-

-
The vge driver also supports one special
-    link option for 1000baseTX cards:

-

-  

-  
With 1000baseTX cards, establishing a link between two ports requires that
-      one port be configured as a master and the other a slave. With
-      autonegotiation, the master/slave settings will be chosen automatically.
-      However when manually selecting the link state, it is necessary to force
-      one side of the link to be a master and the other a slave. The
-      vge driver configures the ports as slaves by
-      default. Setting the link0 flag with
-      ifconfig(8) will set a port as a master instead.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
The vge driver supports VIA Networking
-    VT3119 and VT6122 based Gigabit Ethernet adapters including:

-

-
    
-  
  • VIA Networking LAN-on-motherboard Gigabit Ethernet
    • 
-  
  • ZyXEL GN650-T 64-bit PCI Gigabit Ethernet NIC (ZX1701)
    • 
-  
  • ZyXEL GN670-T 32-bit PCI Gigabit Ethernet NIC (ZX1702)
    • 
-

-

-

-

-

-  
vge%d: couldn't map memory

-  
The driver failed to initialize PCI shared memory mapping. This might
-      happen if the card is not in a bus-master slot.

-  
vge%d: unable to map interrupt

-  
A fatal initialization error has occurred.

-  
vge%d: watchdog timeout

-  
The device has stopped responding to the network, or there is a problem
-      with the network connection (cable). Driver resets the device.

-

-

-

-

-
arp(4), ciphy(4),
-    ipgphy(4), mii(4),
-    netintro(4), ukphy(4),
-    vlan(4), ifconfig(8)

-

-

-

-
The vge device driver first appeared in
-    FreeBSD 5.3 and then in NetBSD
-    3.0.

-

-

-

-
The vge driver was written by
-    Bill Paul
-    <wpaul@windriver.com>.
-    The NetBSD port was done by Jaromir
-    Dolecek ⟨jdolecek@NetBSD.org⟩.

-

-

-

-
VLAN packet filtering is done in software at the moment, though
-    using hardware VLAN tagging.

-

-

-
-  
-    
-    
-  
-
March 5, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/viaenv.4 4.html b/static/netbsd/man4/viaenv.4 4.html
deleted file mode 100644
index 810dfdb6..00000000
--- a/static/netbsd/man4/viaenv.4 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIAENV(4)Device Drivers ManualVIAENV(4)

-

-

-

-
viaenv — VIA
-    VT82C686A/VT8231 Hardware Monitor and Power Management Timer

-

-

-

-
viaenv* at pci? dev ? function ?

-

-

-

-
The viaenv is an
-    envsys(4) compatible driver for the Hardware Monitor and
-    the Power Management timer in the VIA VT82C686A and VT8231 South
-  Bridges.

-
The device has 10 sensors:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
uKCPU temperature
uKSystem temperature
uK?
RPMCPU fan
RPMSystem fan
uV DCCPU core voltage (2.0V)
uV DCNorth Bridge core voltage (2.5V)
uV DCInternal core voltage (3.3V)
uV DC+5V
uV DC+12V

-
Sensor data is updated every 1.5 seconds.

-

-

-

-
envsys(4), envstat(8)

-

-

-

-
The viaenv device appeared in
-    NetBSD 1.5.

-

-

-

-
Interrupt support is unimplemented, as is support for setting
-    values.

-

-

-
-  
-    
-    
-  
-
January 20, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/viaide.4 4.html b/static/netbsd/man4/viaide.4 4.html
deleted file mode 100644
index 1165d702..00000000
--- a/static/netbsd/man4/viaide.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIAIDE(4)Device Drivers ManualVIAIDE(4)

-

-

-

-
viaide — AMD,
-    NVIDIA and VIA IDE disk controllers driver

-

-

-

-
viaide* at pci? dev ? function ? flags
-    0x0000
-  

-  options PCIIDE_AMD756_ENABLEDMA

-

-

-

-
The viaide driver supports the following
-    IDE controllers and provides the interface with the hardware for the
-    ata driver:

-
    
-  
  • Advanced Micro Devices AMD-756, 766, 768 and CS5536 IDE Controllers
    • 
-  
  • NVIDIA nForce, nForce2, nForce2 400, nForce3, nForce3 250, nForce4, MCP04,
-      MCP55, MCP61, MCP65, MCP67 IDE and SATA Controllers.
    • 
-  
  • VIA Technologies VT82C586, VT82C586A, VT82C586B, VT82C596A, VT82C596B,
-      VT82C686A, VT82C686B, VT8233, VT8233A, VT8233C, VT8235,
-      VT8237/VT8237R/VT6420, VT8237A, VT8237S, VT8251, VT8261, CX700(M/M2),
-      VX700, VX800/820, VX855/875, VX900/VX11 Integrated IDE and SATA
-      Controllers, VT6415/VT6330 single-channel IDE Controllers, VT6410 IDE RAID
-      Controller, and VT6421 SATA RAID & IDE Controller.
    • 
-

-
The 0x0002 flag forces the viaide driver
-    to disable DMA on chipsets for which DMA would normally be enabled. This can
-    be used as a debugging aid, or to work around problems where the IDE
-    controller is wired up to the system incorrectly.

-

-

-

-
ata(4), atapi(4),
-    intro(4), pci(4),
-    pciide(4), wd(4),
-    wdc(4)

-

-

-

-
The AMD756 chip revision D2 has a bug affecting DMA (but not
-    Ultra-DMA) modes. The workaround documented by AMD is to not use DMA on any
-    drive which does not support Ultra-DMA modes. This does not appear to be
-    necessary on all drives, the PCIIDE_AMD756_ENABLEDMA option can be used to
-    force multiword DMA on the buggy revisions. Multiword DMA can eventually be
-    disabled on a per-drive basis with config flags, see
-    wd(4). The bug, if triggered, will cause a total system
-    hang.

-
The timings used for the PIO and DMA modes for controllers listed
-    above are for a PCI bus running at 30 or 33 MHz. This driver may not work
-    properly on overclocked systems.

-

-

-
-  
-    
-    
-  
-
October 17, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/video.4 4.html b/static/netbsd/man4/video.4 4.html
deleted file mode 100644
index 9a9143ef..00000000
--- a/static/netbsd/man4/video.4 4.html	
+++ /dev/null
@@ -1,215 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIDEO(4)Device Drivers ManualVIDEO(4)

-

-

-

-
video —
-    device-independent video driver layer

-

-

-

-
#include
-    <sys/videoio.h>

-

-

-

-
The video driver provides support for
-    various video peripherals. It provides a uniform programming interface layer
-    above different underlying video hardware drivers. The video layer provides
-    a Video4Linux2 compatible API. A number of ioctl(2)
-    commands are supported controlling the device.

-
The device file for video operation is
-    /dev/video.

-

-

-

-
Video data is separated into logical video samples which will
-    typically be one complete video frame. With compressed formats, a video
-    sample may be one logical chunk and not one complete frame depending on the
-    compression format. Video samples may be read from
-    /dev/video in one of several different modes.

-
In read mode, calls to read(2) will return at
-    most the data of one video sample. If the entire sample is not read, then
-    subsequent reads will return at most the remaining data in that video
-    sample.

-
Video samples may be mapped into memory with
-    mmap(2). The driver allocates internal buffers for a
-    number of video samples which are mapped into memory. Initiating this mode
-    requires several ioctl(2) commands:
-    VIDIOC_REQBUFS to request the driver reserve
-    buffers, VIDIOC_QUERYBUF to query the details of
-    each buffer, mmap(2) to map each buffer into memory,
-    VIDIOC_QBUF to queue the buffers for receiving video
-    data, VIDIOC_STREAMON to begin streaming of video
-    data, and VIDIOC_DQBUF to remove a filled buffer
-    from the queue. At this point the video data from the dequeued buffer is
-    valid.

-

-

-

-

-  

-  
This command queries the capabilities of the device. The first three
-      fields are informational NULL terminated strings filled by the driver:
-      driver describes the driver used by this device,
-      card describes the video capture card or camera, and
-      bus_info represents the bus to which the hardware
-      device is attached.
-    
The capabilities field contains a number
-        of flags indicating various features supported by the driver or
-        hardware:

-    

-      

-      
support video capturing

-      

-      
supports the read(2) and/or
-          write(2) mode

-      

-      
supports mmap(2) mode

-    

-    

-    
struct v4l2_capability {
-	uint8_t		driver[16];
-	uint8_t		card[32];
-	uint8_t		bus_info[32];
-	uint32_t	version;
-	uint32_t	capabilities;
-	uint32_t	reserved[4];
-};

-    

-  

-

-

-

-

-

-  

-  
This command requests that the driver reserve space for
-      count samples. type must be
-      set to V4L2_BUF_TYPE_VIDEO_CAPTURE and
-      memory to V4L2_MEMORY_MMAP.
-      The returned count represents the actual number of
-      samples reserved which may be more or fewer than requested.
-    

-    
struct v4l2_requestbuffers {
-	uint32_t		count;
-	enum v4l2_buf_type	type;
-	enum v4l2_memory	memory;
-	uint32_t		reserved[2];
-};

-    

-  

-  

-  
This command should be called for each buffer in
-      count above. The fields index,
-      type, and memory must be set
-      to a valid index from 0 to count-1, and the same
-      type and memory as used in VIDIOC_QUERYBUF. The
-      driver returns m.offset and
-      length.
-    

-    
struct v4l2_buffer {
-	uint32_t		index;
-	enum v4l2_buf_type	type;
-	uint32_t		bytesused;
-	uint32_t		flags;
-	enum v4l2_field		field;
-	struct timeval		timestamp;
-	struct v4l2_timecode	timecode;
-	uint32_t		sequence;
-	enum v4l2_memory	memory;
-	union {
-		uint32_t	offset;
-		unsigned long	userptr;
-	} m;
-	uint32_t		length;
-	uint32_t		input;
-	uint32_t		reserved;
-};

-    

-  

-  
mmap(2)

-  
Each buffer must be mapped with a call to mmap(2),
-      passing the length and
-      m.offset values obtained above. The prot
-      PROT_READ|PROT_WRITE and flags
-      MAP_SHARED are recommended.

-  

-  
This command indicates to the driver that the buffer is ready to receive a
-      video sample. The following fields must be set:
-      index, set to a valid buffer index from 0 to
-      count - 1; type, set to the
-      same type used above; and memory, set to the same
-      memory used above. Each buffer should be queued with this command. Order
-      is not important.

-  

-  
This command starts streaming. Queued buffers will be filled with data.
-      select(2) will indicate that a buffer is done and
-      available for reading.

-  

-  
This command dequeues an available buffer from the driver. If no buffer is
-      available, it blocks until one is, unless
-      O_NONBLOCK was specified to
-      open(2), in which case it returns
-      EAGAIN. select(2), or
-      poll(2) prior to initiating any other mode will begin
-      streaming of video for reading with read(2). In this
-      streaming mode select(2) or poll(2)
-      indicate the availability of a video frame. Calls to
-      read(2) will return at most the video data of one video
-      sample. If the entire sample is not read, then subsequent reads will
-      return at most the remaining data in that video sample.

-

-

-

-

-

-  
/dev/video

-  
 

-

-

-

-

-
auvitek(4), pseye(4),
-    uvideo(4), video(9)

-
V4L2 API
-    Specification

-

-

-

-
The video device driver first appeared in
-    NetBSD 5.0.

-

-

-

-
Patrick Mahoney
-    <pat@polycrystal.org>

-

-

-

-
Does not support the complete V4L2 API. Only supports the capture
-    interface. Does not support writing, overlay, VBI, tuner, audio, radio, or
-    asyncio.

-

-

-
-  
-    
-    
-  
-
March 5, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/vio9p.4 4.html b/static/netbsd/man4/vio9p.4 4.html
deleted file mode 100644
index 51ed9e9c..00000000
--- a/static/netbsd/man4/vio9p.4 4.html	
+++ /dev/null
@@ -1,67 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIO9P(4)Device Drivers ManualVIO9P(4)

-

-

-

-
vio9p — VirtIO 9p
-    front-end driver

-

-

-

-
vio9p* at virtio?

-

-

-

-
In conjunction with mount_9p(8), the
-    vio9p driver enables a
-    NetBSD system running as a VM guest to mount an
-    exported file system by the host via virtio-9p. It exports a 9p end-point of
-    virtio-9p via a character device file for mount_9p(8).

-
Each exported file system is assigned a character device and
-    accessible via /dev/vio9p0,
-    /dev/vio9p1 and so on, respectively, in exporting
-    order by the host.

-

-

-

-

-  
/dev/vio9p?

-  
 

-

-

-

-

-
The following command mounts the first exported file system by the
-    host at /mnt/9p:

-

-
# mount_9p -cu /dev/vio9p0 /mnt/9p

-

-

-

-

-
virtio(4), mount_9p(8)

-

-

-

-
The vio9p driver first appeared in
-    NetBSD 10.0.

-

-

-

-
The vio9p driver was written by
-    Ryota Ozaki
-    <ozaki-r@iij.ad.jp>.

-

-

-
-  
-    
-    
-  
-
October 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/viocon.4 4.html b/static/netbsd/man4/viocon.4 4.html
deleted file mode 100644
index 05fa7052..00000000
--- a/static/netbsd/man4/viocon.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIOCON(4)Device Drivers ManualVIOCON(4)

-

-

-

-
viocon — VirtIO
-    console device

-

-

-

-
viocon* at virtio?

-

-

-

-
The viocon driver provides support for the
-    virtio(4) console interface provided by KVM, QEMU, and
-    others.

-
It provides serial ports that are attached as ttys.

-

-

-

-

-  
/dev/ttyVI00

-  
 

-  
/dev/ttyVI10

-  
 

-  
/dev/ttyVI20

-  
 

-  
/dev/ttyVI30

-  
 

-  
/dev/ttyVI40

-  
 

-

-

-

-

-
intro(4), tty(4),
-    virtio(4)

-

-

-

-
The viocon driver first appeared in
-    OpenBSD 5.9.

-

-

-

-
The viocon driver was written for
-    OpenBSD by Stefan Fritsch
-    <sf@sfritsch.de>. It
-    was ported to NetBSD 10.0.

-

-

-

-
Use as a kernel console for NetBSD is not
-    yet supported.

-
The multiport feature is not yet supported.

-

-

-
-  
-    
-    
-  
-
August 13, 2022NetBSD 10.1

diff --git a/static/netbsd/man4/viogpu.4 4.html b/static/netbsd/man4/viogpu.4 4.html
deleted file mode 100644
index e7360041..00000000
--- a/static/netbsd/man4/viogpu.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIOGPU(4)Device Drivers ManualVIOGPU(4)

-

-

-

-
viogpu — VirtIO
-    GPU device

-

-

-

-
viogpu* at virtio?
-  

-  wsdisplay* at viogpu?

-

-

-

-
The viogpu driver provides support for the
-    virtio(4) GPU interface provided by QEMU and other virtual
-    machines to create a wscons(4) console. It does not
-    provide access to the 3D functionality of the virtio GPU device. It does not
-    support mapping the framebuffer for generic graphics use by drivers such as
-    wsfb(4).

-

-

-

-
intro(4), virtio(4)
-    wscons(4), wsdisplay(4),

-

-

-

-
The viogpu driver first appeared in
-    OpenBSD 7.4 and was ported for
-    NetBSD 11.

-

-

-

-
The viogpu driver was written by
-    joshua stein
-    <jcs@openbsd.org>.

-

-

-
-  
-    
-    
-  
-
April 20 2023NetBSD 10.1

diff --git a/static/netbsd/man4/vioif.4 4.html b/static/netbsd/man4/vioif.4 4.html
deleted file mode 100644
index c28f8159..00000000
--- a/static/netbsd/man4/vioif.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIOIF(4)Device Drivers ManualVIOIF(4)

-

-

-

-
vioif — VirtIO NIC
-    driver

-

-

-

-
virtio* at pci? dev ? function ?
-  

-  vioif* at virtio?

-

-

-

-
virtio(4) defines an interface for efficient,
-    standard, and extensible I/O between the hypervisor and the virtual machine.
-    The vioif driver supports virtio-compliant virtual
-    network interface cards.

-

-

-

-
netintro(4), virtio(4),
-    ifconfig(8)

-
Rusty Russell, IBM
-    Corporation, Virtio PCI Card Specification,
-    http://ozlabs.org/~rusty/virtio-spec/.

-

-

-

-
The vioif device driver appeared in
-    NetBSD 6.0.

-

-

-

-
No offloading support.

-

-

-
-  
-    
-    
-  
-
November 26, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/viomb.4 4.html b/static/netbsd/man4/viomb.4 4.html
deleted file mode 100644
index ed46c66a..00000000
--- a/static/netbsd/man4/viomb.4 4.html	
+++ /dev/null
@@ -1,70 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIOMB(4)Device Drivers ManualVIOMB(4)

-

-

-

-
viomb — VirtIO
-    memory ballooning driver

-

-

-

-
virtio* at pci? dev ? function ?
-  

-  viomb* at virtio?

-

-

-

-
virtio(4) defines an interface for efficient,
-    standard, and extensible I/O between the hypervisor and the virtual machine.
-    The viomb driver supports the virtio-compliant
-    memory ballooning device.

-
Memory ballooning works as follows:

-

-
    
-  
  1. The host operator requests a guest to return some amount of memory to the
-      host (via e.g. Qemu monitor balloon command).
    2. 
-  
  2. The hypervisor sends the request via VirtIO memory ballooning device.
    3. 
-  
  3. The guest viomb driver requests allocation of that
-      amount of physical memory from the NetBSD memory
-      management system.
    4. 
-  
  4. The viomb device tells the hypervisor the guest
-      physical memory address of the allocated memory via VirtIO memory
-      ballooning device.
    5. 
-

-
The sysctl node hw.viomb.npages shows the
-    requested number of memory pages to return to the hypervisor, while
-    hw.viomb.actual shows the actual number of memory
-    pages that are already returned to the hypervisor.

-

-

-

-
virtio(4), sysctl(8),
-    x86/balloon(4)

-

-
Rusty Russell, IBM
-    Corporation, Virtio PCI Card Specification,
-    http://ozlabs.org/~rusty/virtio-spec/.

-

-

-

-
The viomb device driver appeared in
-    NetBSD 6.0.

-

-

-

-
The userland interface should be same as the Xen ballooning
-    device.

-

-

-
-  
-    
-    
-  
-
August 25, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/viornd.4 4.html b/static/netbsd/man4/viornd.4 4.html
deleted file mode 100644
index b6ccdd3d..00000000
--- a/static/netbsd/man4/viornd.4 4.html	
+++ /dev/null
@@ -1,57 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIORND(4)Device Drivers ManualVIORND(4)

-

-

-

-
viornd — VirtIO
-    entropy source

-

-

-

-
viornd* at virtio?

-

-

-

-
When the system has entropy demand, the
-    viornd driver, used with a compatible hypervisor
-    such as QEMU, KVM, or Google Compute Engine, requests entropy using the
-    VirtIO random number interface and feeds it into the system entropy
-  pool.

-

-

-

-
rnd(4), virtio(4)

-

-

-

-
The viornd driver appeared in
-    OpenBSD 5.5.

-

-

-

-
The viornd driver was written by
-    Stephan Fritsch
-    <sf@fritsch.de> and
-    reworked to request entropy upon demand by Thor Lancelot
-    Simon
-    <tls@NetBSD.org>.

-

-

-

-
VirtIO appears to support at least 8 pending entropy requests, but
-    viornd currently supports only one pending request
-    at a time.

-

-

-
-  
-    
-    
-  
-
October 26, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/vioscsi.4 4.html b/static/netbsd/man4/vioscsi.4 4.html
deleted file mode 100644
index 7f1cad12..00000000
--- a/static/netbsd/man4/vioscsi.4 4.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIOSCSI(4)Device Drivers ManualVIOSCSI(4)

-

-

-

-
vioscsi — VirtIO
-    SCSI adapter

-

-

-

-
vioscsi* at virtio?
-  

-  scsibus* at vioscsi?

-

-

-

-
vioscsi driver provides support for
-    virtio(4) SCSI adapters.

-

-

-

-
scsi(4), sd(4),
-    virtio(4)

-

-

-

-
The vioscsi driver first appeared in
-    OpenBSD 5.5. It first appeared in
-    NetBSD 7.1, with further stabilization in
-    NetBSD 8.0.

-

-

-

-
The vioscsi driver was written by
-    Matthew Dempsky
-    <matthew@dempsky.org>.
-    NetBSD port done by Christos
-    Zoulas. Further stabilization done by Jaromir
-    Dolecek
-    <jdolecek@NetBSD.org>.

-

-

-

-
vioscsi driver limits probe to 1 channel,
-    16 targets, and 1024 LUNs to reduce boot time.

-

-

-
-  
-    
-    
-  
-
May 27, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/virt.4 4.html b/static/netbsd/man4/virt.4 4.html
deleted file mode 100644
index 4e6a24e0..00000000
--- a/static/netbsd/man4/virt.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIRT(4)Device Drivers ManualVIRT(4)

-

-

-

-
virt — rump kernel
-    virtual network interface

-

-

-

-
The virt interface acts as a link between
-    a rump kernel and a host tap(4) interface. Interface
-    number <n> always corresponds with the host tap interface
-    tap<n>. All data sent by virt is written into
-    /dev/tap<n> and all data read from
-    /dev/tap<n> is passed as Ethernet input to the
-    rump kernel.

-
A virt interface can be created and
-    destroyed in the normal fashion with ifconfig(8).

-
The host's tap(4) interface can be further
-    bridged with hardware interfaces to provide full Internet access to a rump
-    kernel.

-

-

-

-
rump(3), bridge(4),
-    tap(4), brconfig(8),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
July 3, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/virtio.4 4.html b/static/netbsd/man4/virtio.4 4.html
deleted file mode 100644
index ddd39183..00000000
--- a/static/netbsd/man4/virtio.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIRTIO(4)Device Drivers ManualVIRTIO(4)

-

-

-

-
virtio —
-    Para-virtualized I/O in a virtual machine

-

-

-

-
virtio* at fdt?
-  

-  virtio* at pci? dev ? function ?
-  

-  ld* at virtio?
-  

-  viocon* at virtio?
-  

-  vioif* at virtio?
-  

-  viomb* at virtio?
-  

-  viornd* at virtio?
-  

-  vioscsi* at virtio?

-

-

-

-
virtio defines an interface for efficient,
-    standard and extensible I/O between the hypervisor and the virtual machine.
-    The virtio device driver represents an emulated
-    device that the hypervisor makes available to the virtual machine.

-
virtio driver itself provides the core
-    infrastructure to communicate with the hypervisor (called virtqueues) and
-    supports the following devices:

-

-

-  
ld(4)

-  
A Disk device.

-  
viocon(4)

-  
Console device.

-  
vioif(4)

-  
An Ethernet device.

-  
viomb(4)

-  
A pseudo-device to release memory back to the hypervisor.

-  
viornd(4)

-  
An entropy source.

-  
vioscsi(4)

-  
A SCSI adapter.

-

-

-

-

-
ld(4), pci(4),
-    viocon(4), vioif(4),
-    viomb(4), viornd(4),
-    vioscsi(4)

-

-
Rusty Russell, IBM
-    Corporation, Virtio PCI Card Specification,
-    http://ozlabs.org/~rusty/virtio-spec/.

-
Virtual I/O Device (VIRTIO)
-    Version 1.0,
-    https://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html.

-

-

-

-
The virtio driver first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
June 7, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/virtio_mmio.4 4.html b/static/netbsd/man4/virtio_mmio.4 4.html
deleted file mode 100644
index e6347eef..00000000
--- a/static/netbsd/man4/virtio_mmio.4 4.html	
+++ /dev/null
@@ -1,60 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIRTIO_MMIO(4)Device Drivers ManualVIRTIO_MMIO(4)

-

-

-

-
virtio_mmio —
-    VirtIO over memory mapped device

-

-

-

-
pv* at pv?
-  

-  virtio* at pv?

-

-  

-  acpi0 at mainbus0
-  

-  virtio* at acpi?

-

-

-

-
virtio_mmio can be used in virtual
-    environments without pci(4) support (a common situation in
-    embedded devices models) might use simple memory mapped device
-    (virtio_mmio) instead of the
-    pci(4) device.

-
The memory mapped virtio(4) device behavior is
-    based on the pci(4) device specification. Therefore most
-    operations including device initialization, queues configuration and buffer
-    transfers are nearly identical.

-
Unlike pci(4),
-    virtio_mmio provides no generic device discovery
-    mechanism. For each device, the guest OS will need to know the location of
-    the registers and interrupt(s) used.

-
Device location can be read from either acpi(4)
-    or via kernel command line parameters, implemented as a
-    pv(4) virtual device.

-

-

-

-
acpi(4), pv(4),
-    virtio(4)

-

-
Virtual I/O Device (VIRTIO)
-    Version 1.2,
-    https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html.

-

-

-
-  
-    
-    
-  
-
January 15, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/vlan.4 4.html b/static/netbsd/man4/vlan.4 4.html
deleted file mode 100644
index 3d4909ac..00000000
--- a/static/netbsd/man4/vlan.4 4.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
VLAN(4)Device Drivers ManualVLAN(4)

-

-

-

-
vlan — IEEE 802.1Q
-    Virtual LAN network device

-

-

-

-
pseudo-device vlan

-

-

-

-
The vlan interface provides support for
-    IEEE 802.1Q Virtual Local Area Networks (VLAN). This supports the trunking
-    of more than one network on a single network interface by using 802.1Q
-    tagged and untagged frames.

-
To use a vlan interface, the administrator
-    must first create the interface and then specify the VID (VLAN identifier,
-    the first 12 bits from a 16-bit integer which distinguishes each VLAN from
-    any others) and (parent) physical interface associated with the VLAN. This
-    can be done by using the ifconfig(8)
-    create, vlan, and
-    vlanif subcommands from a shell command line or
-    script. From within a C program, use the ioctl(2) system
-    call with the SIOCSIFCREATE and
-    SIOCSIFVLAN arguments.

-
Packets sent through a vlan interface are
-    tagged with the VID and passed to the parent interface for transmission.
-    Tagged packets received on the parent interface are passed to the
-    vlan interface with the corresponding VID associated
-    with the parent interface. Packets sent directly through the parent
-    interface are transmitted as untagged frames. Untagged frames received on
-    the parent interface are handled by the parent interface. Tagged frames
-    received on the parent interface with a VID of 0 and an EtherType of IP or
-    IPv6 are processed on the parent interface. Tagged frames received on the
-    parent interface for which no vlan interface with a
-    matching VID exists are dropped and counted as “unknown
-    protocol”. (These are displayed by the ifconfig(8)
-    -v option.)

-
If the vlan pseudo-device is not
-    configured in the kernel only packets tagged with a VID of 0 are
-  processed.

-
To be compatible with other IEEE 802.1Q devices, the
-    vlan interface supports a 1500 byte MTU, which means
-    that the parent interface will have to handle packets that are 4 bytes
-    larger than the original Ethernet standard.

-
vlan can be used with devices not
-    supporting the IEEE 802.1Q MTU, but then the MTU of the
-    vlan interface will be 4 bytes too small and will
-    not interoperate properly with other IEEE 802.1Q devices, unless the MTU of
-    the other hosts on the VLAN are also lowered to match.

-

-

-

-
The following will create interface vlan0 with
-    VID six, on the Ethernet interface tlp0:

-

-
ifconfig vlan0 create
-ifconfig vlan0 vlan 6 vlanif tlp0

-

-
After this set up, IP addresses (and/or other protocols) can be
-    assigned to the vlan0 interface. All other hosts on the
-    Ethernet connected to tlp0 which configure a VLAN and use
-    VID six will see all traffic transmitted through
-  vlan0.

-
The same VLAN can be created at system startup time by placing the
-    following in /etc/ifconfig.vlan0:

-

-
create
-vlan 6 vlanif tlp0

-

-

-

-

-
bridge(4), ifconfig(8)

-

-

-

-
The vlan device first appeared in
-    NetBSD 1.5.1, and was derived from a VLAN
-    implementation that appeared in FreeBSD and
-    OpenBSD.

-

-

-

-
The vlan interfaces do not currently
-    inherit changes made to the physical interfaces' MTU.

-

-

-
-  
-    
-    
-  
-
May 29, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/vmmon.4 4.html b/static/netbsd/man4/vmmon.4 4.html
deleted file mode 100644
index b067ee6d..00000000
--- a/static/netbsd/man4/vmmon.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
VMMON(4)Device Drivers ManualVMMON(4)

-

-

-

-
vmmon —
-    unknown

-

-

-

-
unknown

-

-

-

-
No description.

-

-

-

-
Nothing

-

-

-

-
<jdolecek@NetBSD.org>
-    has not yet written this man page.

-

-

-
-  
-    
-    
-  
-
April 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/vmnet.4 4.html b/static/netbsd/man4/vmnet.4 4.html
deleted file mode 100644
index 640c9ccf..00000000
--- a/static/netbsd/man4/vmnet.4 4.html	
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    
-    
-    
-  
-
VMNET(4)Device Drivers ManualVMNET(4)

-

-

-

-
vmnet —
-    unknown

-

-

-

-
unknown

-

-

-

-
No description.

-

-

-

-
Nothing

-

-

-

-
<jdolecek@NetBSD.org>
-    has not yet written this man page.

-

-

-
-  
-    
-    
-  
-
April 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/vmt.4 4.html b/static/netbsd/man4/vmt.4 4.html
deleted file mode 100644
index b09c2994..00000000
--- a/static/netbsd/man4/vmt.4 4.html	
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  
-    
-    
-    
-  
-
VMT(4)Device Drivers Manual (x86)VMT(4)

-

-

-

-
vmt — VMware Tools
-    driver

-

-

-

-
vmt0 at cpu0

-

-

-

-
The vmt driver is a kernel level
-    implementation of VMware Tools. VMware Tools are intended to provide better
-    support for operating systems running inside virtual machines.

-
vmt handles shutdown, reboot, resume
-    requests from the host by sending events using
-    sysmon_pswitch(9) of type PSWITCH_TYPE_POWER,
-    PSWITCH_TYPE_RESET, and PSWITCH_TYPE_SLEEP that can be handled by
-    powerd(8). vmt will log
-    notifications that the guest has been suspended or resumed by the host.

-
vmt reports the guest's hostname and first
-    non-loopback IP address to the host.

-

-

-
The vmt driver synchronizes the virtual
-    machine's clock with the host clock in the following situations:

-
    
-  
  • When the virtual machine resumes after having been suspended.
    • 
-  
  • Periodically with the interval indicated by the
-      machdep.vmt0.clock_sync.period
-      sysctl(8) variable. This is done so that the virtual
-      machine can keep its clock synchronized when the host is suspended,
-      because in this case the vmt driver receives no
-      notification of such an event. Setting this tunable to zero disables clock
-      synchronization.
    • 
-

-

-

-

-

-
powerd(8)

-

-

-

-
The vmt driver first appeared in
-    OpenBSD 4.4 and was then ported to
-    NetBSD 6.0.

-

-

-

-
The vmt driver was written by
-    David Gwynne
-    <dlg@openbsd.org>.

-

-

-

-
vmt is known to cause a conflict with
-    vmtoolsd(8) from open-vm-tools.
-    vmt works by establishing an RPC channel called TCLO
-    between VMware guest and host to receive controlling messages from the host.
-    The problem is that vmt is essentially a subset of
-    vmtoolsd(8), and they both use the same RPC channel, but
-    TCLO is never meant to be simultaneously used by two distinct services in
-    the same VM guest. So when vmtoolsd(8) is running while
-    also vmt is active, they continually fight for the
-    channel, both get rejected by the confused VM host, and neither one can
-    establish a stable communication line.

-
So before launching vmtoolsd(8) the
-    vmt driver should be detached by running:

-

-
# drvctl -d vmt0

-

-
And after terminating vmtoolsd(8) the
-    vmt driver should be re-attached by running:

-

-
# drvctl -r -a cpufeaturebus cpu0

-

-

-

-
-  
-    
-    
-  
-
October 6, 2013NetBSD 10.1

diff --git a/static/netbsd/man4/vmx.4 4.html b/static/netbsd/man4/vmx.4 4.html
deleted file mode 100644
index 645ebb3c..00000000
--- a/static/netbsd/man4/vmx.4 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
VMX(4)Device Drivers ManualVMX(4)

-

-

-

-
vmx — VMware
-    VMXNET3 Virtual Interface Controller device

-

-

-

-
vmx* at pci? dev ? function ?

-

-

-

-
The vmx driver provides support for the
-    VMXNET3 virtual NIC available in virtual machines by VMware. It appears as a
-    simple Ethernet device but is actually a virtual network interface to the
-    underlying host operating system.

-
This driver supports the VMXNET3 driver
-    protocol, as an alternative to the emulated pcn(4),
-    wm(4) interfaces also available in the VMware environment.
-    The vmx driver is optimized for the virtual machine,
-    it can provide advanced capabilities depending on the underlying host
-    operating system and the physical network interface controller of the host.
-    In comparison to the earlier VMXNET versions, VMXNET3 supports additional
-    features like multiqueue support, IPv6 checksum offloading, MSI/MSI-X
-    support and hardware VLAN tagging in VMware's VLAN Guest Tagging (VGT)
-  mode.

-
The vmx driver supports VMXNET3 VMware
-    virtual NICs provided by the virtual machine hardware version 7 or newer, as
-    provided by the following products:

-

-
    
-  
  • VMware ESX/ESXi 4.0 and newer
    • 
-  
  • VMware Server 2.0 and newer
    • 
-  
  • VMware Workstation 6.5 and newer
    • 
-  
  • VMware Fusion 2.0 and newer
    • 
-

-
The vmx driver supports the following
-    media types:

-

-  
autoselect

-  
Enable autoselection of the media type and options. The driver always uses
-      the fastest available speed and the media options provided by the
-      underlying host of the virtual machine.

-  
10GbaseT mediaopt full-duplex

-  
Set 10Gbps operation.

-  
1000baseT mediaopt full-duplex

-  
Set 1000Mbps operation.

-

-
For more information on configuring this device, see
-    ifconfig(8).

-

-

-

-
The following entry must be added to the VMware configuration file
-    to provide the vmx device:

-

-
ethernet0.virtualDev = "vmxnet3"

-

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), pcn(4), wm(4),
-    ifconfig(8)

-

-

-

-
The vmx device driver first appeared in
-    OpenBSD 5.5 and was ported for
-    NetBSD 7.0.

-

-

-

-
The vmx driver was originally written by
-    Tsubai Masanari. NetBSD
-    porting was done by Hikaru ABE
-    <hikaru@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 7, 2014NetBSD 10.1

diff --git a/static/netbsd/man4/vnd.4 4.html b/static/netbsd/man4/vnd.4 4.html
deleted file mode 100644
index d87a046d..00000000
--- a/static/netbsd/man4/vnd.4 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
VND(4)Device Drivers ManualVND(4)

-

-

-

-
vnd — vnode disk
-    driver

-

-

-

-
pseudo-device vnd
-  

-  options VND_COMPRESSION

-

-

-

-
The vnd driver provides a disk-like
-    interface to a file. This is useful for a variety of applications, including
-    swap files and building miniroot or floppy disk images.

-
This document assumes that you're familiar with how to generate
-    kernels and how to properly configure disks and pseudo-devices in a kernel
-    configuration file.

-
In order to compile in support for the
-    vnd, you must add a line similar to the following to
-    your kernel configuration file:

-

-
pseudo-device	vnd		# vnode disk driver

-

-
To also compile in support for reading compressed disk images, add
-    the following option to your kernel config file:

-

-
options        VND_COMPRESSION    # compressed vnd(4)

-

-
Compressed disk images are expected in the cloop2 format. They can
-    be created from “normal” disk images by the
-    vndcompress(1) program.

-
There is a run-time utility that is used for configuring both
-    compressed and uncompressed vnds; see
-    vnconfig(8) for more information.

-

-

-

-

-  
/dev/{,r}vnd*

-  
vnd device special files.

-

-

-

-

-
config(1), vndcompress(1),
-    fsck(8), MAKEDEV(8),
-    mount(8), newfs(8),
-    vnconfig(8)

-

-

-

-
The vnode disk driver was originally written at the University of
-    Utah. The compression handling is based on code by Cliff
-    Wright ⟨cliff@snipe444.org⟩.

-

-

-

-
The vnd driver does not work if the file
-    does not reside in a local filesystem.

-

-

-
-  
-    
-    
-  
-
September 29, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/voodoofb.4 4.html b/static/netbsd/man4/voodoofb.4 4.html
deleted file mode 100644
index 03b67d0e..00000000
--- a/static/netbsd/man4/voodoofb.4 4.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
VOODOOFB(4)Device Drivers ManualVOODOOFB(4)

-

-

-

-
voodoofb — 3Dfx
-    Voodoo 3 / Voodoo Banshee framebuffer driver

-

-

-

-
voodoofb* at pci?
-  

-  wsdisplay* at voodoofb?

-

-

-

-
The voodoofb driver provides support for
-    the 3Dfx Voodoo 3 and 3Dfx Voodoo Banshee series of graphics cards and
-    provides an interface for machine independent wscons(4)
-    driver.

-
Currently voodoofb depends on the firmware
-    to do low level initialization of the card (e.g. program video RAM
-    controller). However, it is capable of changing the resolution and uses DDC2
-    to pick an appropriate video mode.

-
A 2D graphics engine is used to accelerate all drawing operations.
-    Direct access to video memory is not required by
-    voodoofb.

-

-

-

-
genfb(4), wsdisplay(4)

-

-

-

-
The voodoofb driver was written by
-    Michael Lorenz. This man page was written by
-    Radoslaw Kujawa.

-

-

-
-  
-    
-    
-  
-
November 9, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/vr.4 4.html b/static/netbsd/man4/vr.4 4.html
deleted file mode 100644
index 0145bfa1..00000000
--- a/static/netbsd/man4/vr.4 4.html	
+++ /dev/null
@@ -1,56 +0,0 @@
-
-  
-    
-    
-    
-  
-
VR(4)Device Drivers ManualVR(4)

-

-

-

-
vr — Ethernet
-    driver for VIA Rhine Ethernet boards

-

-

-

-
vr* at pci? dev ? function ?

-
Configuration of PHYs is necessary. See
-  mii(4).

-

-

-

-
The vr device driver supports network
-    adapters based on the VIA VT3043(Rhine), VIA VT86C100A(Rhine-II), and VIA
-    VT6105(Rhine-III) chips.

-

-

-

-
Supported cards include:

-

-

-  
D-Link DFE530TX

-  
 

-

-

-

-

-

-
Media selection is done using ifconfig(8) using
-    the standard ifmedia(4) mechanism. Refer to those manual
-    pages for more information.

-

-

-

-
ifmedia(4), mii(4),
-    netintro(4), pci(4),
-    vlan(4), ifconfig(8)

-

-

-
-  
-    
-    
-  
-
December 16, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/vte.4 4.html b/static/netbsd/man4/vte.4 4.html
deleted file mode 100644
index 624230a9..00000000
--- a/static/netbsd/man4/vte.4 4.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
VTE(4)Device Drivers ManualVTE(4)

-

-

-

-
vte — Vortex86 RDC
-    R6040 Fast Ethernet driver

-

-

-

-
vte* at pci? dev ? function ?

-
Configuration of PHYs is necessary. See
-    rdcphy(4).

-

-

-

-
The vte device driver provides support for
-    RDC R6040 Fast Ethernet controller which is commonly found on Vortex86
-    System On a Chip (SoC).

-
The RDC R6040 has integrated 10/100 PHY for 10/100Mbps support in
-    full or half-duplex. The controller supports interrupt moderation mechanism,
-    a 64-bit multicast hash filter, VLAN over-size frame and four station
-    addresses. The vte device driver uses three station
-    addresses out of four as perfect multicast filter.

-

-

-

-
The following variables are available

-

-  
hw.vte.vte<x>.int_rxct

-  
Maximum number of packets to fire RX completion interrupt. The accepted
-      range is 0 (disable interrupt moderation) to 15, the default is 0.

-  
hw.vte.vte<x>.int_txct

-  
Maximum number of packets to fire TX completion interrupt. The accepted
-      range is 0 (disable interrupt moderation) to 15, the default is 0.

-

-

-

-

-
ifmedia(4), mii(4),
-    netintro(4), vlan(4),
-    ifconfig(8)

-
DM&P Electronics Inc.
-    Vortex86,
-    http://www.dmp.com.tw.

-

-

-

-
The vte driver was written for
-    FreeBSD by Pyun YongHyeon
-    ⟨yongari@FreeBSD.org⟩ and ported to
-    NetBSD by Manuel Bouyer
-    ⟨bouyer@NetBSD.org⟩. The vte device
-    driver first appeared in NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
January 23, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/wapbl.4 4.html b/static/netbsd/man4/wapbl.4 4.html
deleted file mode 100644
index 27b5956b..00000000
--- a/static/netbsd/man4/wapbl.4 4.html	
+++ /dev/null
@@ -1,146 +0,0 @@
-
-  
-    
-    
-    
-  
-
WAPBL(4)Device Drivers ManualWAPBL(4)

-

-

-

-
WAPBL — Write
-    Ahead Physical Block Logging file system journaling

-

-

-

-
options WAPBL
-  

-  options WAPBL_DEBUG

-

-

-

-
The WAPBL driver provides meta-data
-    journaling for file systems. In particular, it is used with the fast file
-    system (FFS) to provide rapid file system consistency checking after a
-    system outage. It also provides better general-use performance over regular
-    FFS.

-
WAPBL currently maintains its journal in one of two locations:

-

-  
- After the file system

-  
The journal is placed in the same partition as the file system, but
-      between the file system and the end of the partition.

-  
- Within the file system

-  
The journal is allocated as a special contiguous file within the file
-      system. The journal file is not visible via normal file system
-    access.

-

-
A new journal is created automatically when a file system is
-    mounted via mount(8) with the -o
-    log option. If no journal size has been specified with
-    tunefs(8), then the size of the journal will be based on
-    1MB of journal per 1GB of file system, to a maximum journal size of
-  64MB.

-
If there is adequate space between the end of the file system and
-    the end of the partition, then unless the journal size has been specified
-    with tunefs(8) then the journal will be created after the
-    file system. To obtain space between the file system and the end of the
-    partition the size of the partition can be adjusted using
-    disklabel(8). Care must be taken not to damage existing
-    data on existing partitions, but this method will work well if, for example,
-    a swap partition can be shrunk in order to accommodate the journal after the
-    file system on a partition before the swap partition.

-
For a new file system,

-

-
newfs -s -64m wd0a

-

-
can be used to leave space for a 64MB journal at the end of
-    /dev/wd0a.

-
To specify the size of the journal within the file system
-    tunefs(8) can be used as follows:

-

-
tunefs -l 64m wd0a

-

-
to indicate that a journal of size 64MB on the file system on
-    /dev/wd0a should be created the next time that file
-    system is mounted. This must be done before the file system is mounted with
-    the “-o log” option. For existing file systems and general
-    use, however, simply using

-

-
mount -o log /dev/wd0a /mnt

-

-
will be sufficient to create an appropriate journal within the
-    file system. Running

-

-
tunefs -l 0 wd0a

-

-
will schedule the log for removal on the next read-write mount,
-    and running

-

-
tunefs -l 0 wd0a

-

-
followed by

-

-
mount -o log /dev/wd0a /mnt

-

-
will remove the log and then re-create it with the default size.
-    This method can also be used to grow or shrink the size of the journal by
-    first scheduling the log for removal, then mounting read-write, but with
-    logging disabled (so no new log will be created), then unmounting again,
-    setting the desired log size and finally re-mounting with logging
-  enabled.

-
With the journal, fsck(8) is no longer required
-    at system boot. If the system has been shutdown in an unclean fashion then
-    the journal will be replayed when the file system is mounted.
-    fsck(8) can still be used to force a consistency check of
-    the file system should that be desired.

-
For kernel developers, the compile time option
-    WAPBL_DEBUG turns on debugging.

-

-

-

-
config(1), fsck(8),
-    mount(8), newfs(8),
-    umount(8)

-

-

-

-
WAPBL was originally written by
-    Darrin B. Jewell while at Wasabi Systems Inc. Wasabi
-    Systems contributed the code to NetBSD, and it was
-    integrated by Simon Burge, Antti
-    Kantee, Andy Doran, and Greg
-    Oster.

-
WAPBL first appeared in
-    NetBSD 5.0.

-

-

-

-
Older releases of the system, and other systems that support the
-    UFS format should only access
-    WAPBL file systems in read-only mode. Additionally,
-    the fsck(8) command from such systems should not be run
-    against WAPBL file systems. Failure to observe these
-    guidelines may damage the file system.

-
WAPBL requires the super block to be in
-    the UFS2 format. The super block format can be checked using the
-    -s option with dumpfs(8), and
-    older FFSv1 file systems will need to be updated to the newer super block
-    layout with the -c option to
-    fsck_ffs(8).

-
fsync(2) causes all outstanding metadata
-    transactions to be committed to disk, introducing additional latency. This
-    can have an impact on database software and other software that calls
-    fsync(2) often.

-
In-file system log allocation should be done on a relatively quiet
-    file system. The error path for log allocation failures could result in a
-    “dangling inode” issue, requiring an fsck(8)
-    to fix.

-

-

-
-  
-    
-    
-  
-
December 3, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/wb.4 4.html b/static/netbsd/man4/wb.4 4.html
deleted file mode 100644
index 7b043c5f..00000000
--- a/static/netbsd/man4/wb.4 4.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
WB(4)Device Drivers ManualWB(4)

-

-

-

-
wb — Winbond
-    W83L518D Integrated Media Reader device driver

-

-

-

-
wb* at acpi?
-  

-  sdmmc* at wb?
-  

-  ld* at sdmmc?

-

-

-

-
The wb driver provides support for the
-    Winbond W83L518D Integrated Media Reader.

-
This device supports SD/MMC, Memory Stick, Memory Stick Pro, and
-    Smart Cards. The wb driver currently only supports
-    the SD/MMC interface.

-

-

-

-
ld(4), sdmmc(4)

-

-

-

-
The wb device driver appeared in
-    NetBSD 6.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@invisible.ca>

-

-

-

-
DMA mode is not yet implemented.

-

-

-
-  
-    
-    
-  
-
September 30, 2009NetBSD 10.1

diff --git a/static/netbsd/man4/wbsio.4 4.html b/static/netbsd/man4/wbsio.4 4.html
deleted file mode 100644
index bc5a8d7c..00000000
--- a/static/netbsd/man4/wbsio.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
WBSIO(4)Device Drivers ManualWBSIO(4)

-

-

-

-
wbsio — Winbond
-    (Nuvoton) LPC Super I/O

-

-

-

-
wbsio* at isa? port 0x2e
-  

-  wbsio* at isa? port 0x4e
-  

-  lm* at wbsio?
-  

-  gpio* at gpiobus?

-

-  

-  options WBSIO_GPIO

-

-

-

-
The wbsio driver provides support for the
-    Winbond (was spun off as Nuvoton) LPC Super I/O ICs. The hardware monitoring
-    function and GPIO are currently supported.

-
Support for the hardware monitor function is provided through the
-    lm(4) driver. The GPIO function supports 64 pins for
-    NCT6795D. Access to the pins provided by the gpio(4)
-    interface.

-

-

-

-
gpio(4), intro(4),
-    isa(4), lm(4)

-

-

-

-
The wbsio driver first appeared in
-    OpenBSD 4.3. NetBSD support
-    was added in NetBSD 6.0.

-

-

-

-
The wbsio driver was written by
-    Mark Kettenis
-    <kettenis@openbsd.org>.
-    It was adapted to NetBSD by
-    Constantine A. Murenin
-    <cnst@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
December 12, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/wd.4 4.html b/static/netbsd/man4/wd.4 4.html
deleted file mode 100644
index 5dd73350..00000000
--- a/static/netbsd/man4/wd.4 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
WD(4)Device Drivers ManualWD(4)

-

-

-

-
wd — WD100x
-    compatible hard disk driver

-

-

-

-
wd* at atabus? drive ? flags 0x0000
-  

-  wd* at umass?
-  

-  options WD_SOFTBADSECT

-

-

-

-
The wd driver supports hard disks that
-    emulate the Western Digital WD100x. This includes standard MFM, RLL, ESDI,
-    IDE, EIDE, and SATA drives.

-
The flags are used only with controllers that support DMA
-    operations and mode settings (like some pciide controllers). The lowest
-    order nibble (rightmost digit) of the flags defines the PIO mode, the next
-    four bits define the DMA mode and the third nibble defines the UltraDMA
-    mode. For each set of four bits, the 3 lower bits define the mode to use and
-    the last bit must be set to 1 for this setting to be used. For DMA and UDMA,
-    0xf (1111) means 'disable'. For example, a flags value of 0x0fac (1111 1010
-    1100) means 'use PIO mode 4, DMA mode 2, disable UltraDMA'. 0x0000 means
-    "use whatever the drive claims to support."

-
The kernel configuration option “options
-    WD_SOFTBADSECT” enables a software managed bad-sector list
-    which will prevent further accesses to sectors where an unrecoverable read
-    error occurred. A user interface is provided by dkctl(8).
-    Unlike the (historical) mechanisms provided by bad144(8)
-    and badsect(8), the software list supports neither sector
-    replacement nor retention across reboots.

-
The following sysctl(8) variables control
-    behavior of disks attached using this driver:

-

-  

-  
Whether to use NCQ ATA commands for the disk. Only effective when the disk
-      hardware actually claims to support NCQ. Default to true.

-  

-  
Use optional NCQ priority for high-priority I/O like meta-data. Intended
-      only for experimental use right now, might negatively affect performance.
-      This setting only has effect if hw.wdX.use_ncq is
-      also true. Default to false.

-

-

-

-

-
Certain Seagate Barracuda drives sold around 2003 have a known
-    firmware bug leading to corrupted write transfers for sector counts n*15 +
-    1, in combination with certain ATA controllers, most commonly Silicon Image
-    3xxx. Affected drives include, but are not limited to:

-

-

-

-  
Seagate ST3120023AS

-  
 

-  
Seagate ST380023AS

-  
 

-  
Seagate ST360015AS

-  
 

-

-

-
If you have one of these drives, it's recommended to replace the
-    drive. There used to exist a driver workaround greatly reducing performance,
-    but the code was completely removed in NetBSD
-  8.0.

-

-

-

-
ata(4), intro(4),
-    pciide(4), scsi(4),
-    umass(4), wdc(4),
-    atactl(8), dkctl(8)

-

-

-

-
The optional software bad sector list does not interoperate well
-    with sector remapping features of modern disks. To let the disk remap a
-    sector internally, the software bad sector list must be flushed or disabled
-    before.

-

-

-
-  
-    
-    
-  
-
January 13, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/wdc.4 4.html b/static/netbsd/man4/wdc.4 4.html
deleted file mode 100644
index acec7a45..00000000
--- a/static/netbsd/man4/wdc.4 4.html	
+++ /dev/null
@@ -1,86 +0,0 @@
-
-  
-    
-    
-    
-  
-
WDC(4)Device Drivers ManualWDC(4)

-

-

-

-
wdc — WD100x
-    compatible hard disk controllers driver

-

-

-

-

-

-
wdc0 at isa? port 0x1f0 irq 14 flags 0x00
-  

-  wdc1 at isa? port 0x170 irq 15 flags 0x00
-  

-  wdc* at isapnp?

-

-

-

-
wdc* at ofisa?

-

-

-

-
wdc* at pcmcia? function ?

-

-

-

-
wdc0 at pioc? offset 0x01f0 irq 9

-

-

-

-
wdc0 at mainbus0

-

-

-

-
wdc0 at mainbus0

-

-

-

-

-
The wdc driver provides the interface with
-    the hardware for the ata(4) driver. This driver supports
-    IDE and EIDE controllers, as well as MFM, RLL and ESDI on the ISA bus. PCI
-    IDE controllers in legacy mode are also supported, but the
-    pciide(4) driver may provide more functionality.

-
On the ISA front-end, the following flags are supported:

-

-

-  
0x0001

-  
Enables 32-bit I/O negotiation in the driver. This is known to cause
-      problems with some motherboards.

-  
0x0002

-  
Don't probe for the second drive.

-  
0x0004

-  
Set WDC_CAPABILITY_ATA_NOSTREAM flag.

-  
0x0008

-  
Set WDC_CAPABILITY_ATAPI_NOSTREAM flag.

-

-

-

-

-

-
ata(4), atapi(4),
-    intro(4), isa(4),
-    isapnp(4), mainbus(4),
-    ofisa(4), pciide(4),
-    pcmcia(4), scsi(4),
-    wd(4)

-

-

-
-  
-    
-    
-  
-
October 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/wds.4 4.html b/static/netbsd/man4/wds.4 4.html
deleted file mode 100644
index 8252feb1..00000000
--- a/static/netbsd/man4/wds.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
WDS(4)Device Drivers ManualWDS(4)

-

-

-

-
wds — WD7000
-    compatible ISA SCSI driver

-

-

-

-
wds0 at isa? port 0x350 irq 15 drq 6		# WD7000,
-    TMC-7000
-  

-  wds1 at isa? port 0x358 irq 11 drq 5
-  

-  scsibus* at wds?

-

-

-

-
The wds driver supports the WD7000 family
-    of SCSI adaptors and compatibles, including:

-

-

-  
WD7000-ASC

-  
busmastering DMA controller

-  
WD7000-ASE

-  
an ASC with floppy controller and ESDI, manufactured for Apollo
-      workstations.

-  
WD7000-FASST2

-  
an ASC with new firmware and scatter-gather hardware.

-

-

-

-

-

-
cd(4), ch(4),
-    intro(4), isa(4),
-    scsi(4), sd(4),
-  st(4)

-

-

-
-  
-    
-    
-  
-
February 17, 1997NetBSD 10.1

diff --git a/static/netbsd/man4/we.4 4.html b/static/netbsd/man4/we.4 4.html
deleted file mode 100644
index 79badd0a..00000000
--- a/static/netbsd/man4/we.4 4.html	
+++ /dev/null
@@ -1,147 +0,0 @@
-
-  
-    
-    
-    
-  
-
WE(4)Device Drivers ManualWE(4)

-

-

-

-
we — Western
-    Digital/SMC WD80x3, SMC Elite Ultra, and SMC EtherEZ Ethernet cards device
-    driver

-

-

-

-

-

-
we0 at isa? port 0x280 iomem 0xd0000 irq 9
-  

-  we1 at isa? port 0x300 iomem 0xcc000 irq 10

-

-

-

-
we* at mca? slot ?

-

-

-

-
we0 at vme0 irq 4 # SMC Elite Ultra with SMC_TT
-    VME-ISA bridge

-

-

-

-

-
The we device driver supports Western
-    Digital/SMC WD80x3, SMC Elite Ultra, and SMC EtherEZ Ethernet cards.

-

-

-

-
For some clone boards the driver is not able to recognize 16bit or
-    8bit interfaces correctly. Since this makes a huge difference (see
-    diagnostic section below) you can override this by specifying flags value in
-    the config file:

-
we2 at isa? port 0x300 iomem 0xe0000 irq 15 flags
-    4

-
The values to add together for flags are:

-

-  
2

-  
force adapter to be treated as 8bit, even if it probes as a 16bit
-      interface. Improper use of this flag will make the driver fail or send
-      invalid Ethernet packets.

-  
4

-  
force adapter to be treated as 16bit, even if it probes as a 8bit
-      interface. For example the COMPEX ENT/U boards identify as WD8003
-      compatibles, but are in fact 16bit cards. Using this flag on a board that
-      really is a 8bit board will result in bogus packets being sent.

-  
8

-  
disable the use of double transmit buffers to save space in the on-board
-      RAM for more receive buffers.

-

-
Note that all supported MCA cards are 16bit, and the SMC_TT
-    VME-ISA bridge interface for atari supports only SMC Elite Ultra.

-

-

-

-
The ability to select media from software is dependent on the
-    particular model of WD/SMC card. The following models support only manual
-    configuration: WD8003S, WD8003E, and WD8013EBT.

-
Other WD/SMC 80x3 interfaces support two types of media on a
-    single card. All support the AUI media type. The other media is either BNC
-    or UTP behind a transceiver. Software cannot differentiate between BNC and
-    UTP cards. On some models, the AUI port is always active.

-
The SMC Elite Ultra and SMC EtherEZ interfaces support three media
-    a single card: AUI, BNC, and UTP. If the transceiver is active, the BNC
-    media is selected. Otherwise, the AUI and UTP ports are both active.

-
To enable the AUI media, select the
-     or
-     media
-    type with ifconfig(8)'s media
-    directive. To select the other media (transceiver), select the
-    
-    or  media
-    type.

-

-

-

-

-  
we0: overriding IRQ <n> to <m>

-  
The IRQ specified in the kernel configuration file is different from that
-      found in the card's configuration registers. The value in the kernel
-      configuration file is being overridden by the one configured into the
-      card.

-  
we0: can't wildcard IRQ on a <model>

-  
The IRQ was wildcarded in the kernel configuration file, and the card is a
-      WD8003S, WD8003E, or WD8013EBT, which do not support software IRQ
-      configuration.

-  
we0: failed to clear shared memory at offset <off>

-  
The memory test was unable to clear the interface's shared memory region.
-      This often indicates that the card is configured at a conflicting
-      
-    address.

-  
we0: warning - receiver ring buffer overrun

-  
The DP8390 Ethernet chip used by this board implements a shared-memory
-      ring-buffer to store incoming packets.
-    
The 16bit boards (8013 series) have 16k of memory as well as
-        fast memory access speed. Typical memory access speed on these boards is
-        about 4MB/second. These boards generally have no problems keeping up
-        with full Ethernet speed and the ring-buffer seldom overfills.

-    
However, the 8bit boards (8003) usually have only 8k bytes of
-        shared memory. This is only enough room for about 4 full-size (1500
-        byte) packets. This can sometimes be a problem, especially on the
-        original WD8003E, because these boards' shared-memory access speed is
-        quite slow; typically only about 1MB/second. The overhead of this slow
-        memory access, and the fact that there is only room for 4 full-sized
-        packets means that the ring-buffer will occasionally overrun. When this
-        happens, the board must be reset to avoid a lockup problem in early
-        revision 8390's. Resetting the board causes all of the data in the
-        ring-buffer to be lost, requiring it to be retransmitted/received,
-        congesting the board further. Because of this, maximum throughput on
-        these boards is only about 400-600k per second.

-    
This problem is exasperated by NFS because the 8bit boards
-        lack sufficient memory to support the default 8k byte packets that NFS
-        and other protocols use as their default. If these cards must be used
-        with NFS, use the NFS -r and
-        -w options in /etc/fstab
-        to limit NFS's packet size. 4096 byte packets generally work.

-  

-

-

-

-

-
ifmedia(4), intro(4),
-    isa(4), mca(4),
-    ifconfig(8)

-

-

-
-  
-    
-    
-  
-
March 23, 2010NetBSD 10.1

diff --git a/static/netbsd/man4/wg.4 4.html b/static/netbsd/man4/wg.4 4.html
deleted file mode 100644
index 9f210a62..00000000
--- a/static/netbsd/man4/wg.4 4.html	
+++ /dev/null
@@ -1,189 +0,0 @@
-
-  
-    
-    
-    
-  
-
WG(4)Device Drivers ManualWG(4)

-

-

-

-
wg — virtual
-    private network tunnel (EXPERIMENTAL)

-

-

-

-
pseudo-device wg

-

-

-

-
The wg interface implements a
-    roaming-capable virtual private network tunnel, configured with
-    ifconfig(8) and wgconfig(8).

-

-    wg is experimental.

-
Packets exchanged on a wg interface are
-    authenticated and encrypted with a secret key negotiated with the peer, and
-    the encapsulation is exchanged over IP or IPv6 using UDP.

-
Every wg interface can be configured with
-    an IP address using ifconfig(8), a private key generated
-    with wg-keygen(8), an optional listen port, and a
-    collection of peers.

-
Each peer configured on an wg interface
-    has a public key and a range of IP addresses the peer is allowed to use for
-    its wg interface inside the tunnel. Each peer may
-    also optionally have a preshared secret key and a fixed endpoint IP address
-    outside the tunnel.

-

-

-

-
Typical network topology:

-

-
Stationary server:                         Roaming client:
-+---------+                                    +---------+
-|    A    |                                    |    B    |
-|---------|                                    |---------|
-|         | 192.0.2.123          198.51.100.45 |         |
-|        [wm0]----------internet-----------[bge0]        |
-|    [wg0] port 1234 - - - (tunnel) - - - - - - [wg0]    |
-|   10.2.0.1                  |               10.2.0.42  |
-|   fd00:2::1                 |              fd00:2::42  |
-|         |                   |                |         |
-+--[wm1]--+          +-----------------+       +---------+
-     | 10.1.0.1      | VPN 10.2.0.0/24 |
-     |               |     fd00:2::/64 |
-     |               +-----------------+
-+-----------------+
-| LAN 10.1.0.0/24 |
-|     fd00:1::/64 |
-+-----------------+

-

-
Generate key pairs on A and B:

-

-
A# (umask 0077; wg-keygen > /etc/wg/wg0)
-A# wg-keygen --pub < /etc/wg/wg0 > /etc/wg/wg0.pub
-A# cat /etc/wg/wg0.pub
-N+B4Nelg+4ysvbLW3qenxIwrJVE9MdjMyqrIisH7V0Y=
-
-B# (umask 0077; wg-keygen > /etc/wg/wg0)
-B# wg-keygen --pub < /etc/wg/wg0 > /etc/wg/wg0.pub
-B# cat /etc/wg/wg0.pub
-X7EGm3T3IfodBcyilkaC89j0SH3XD6+/pwvp7Dgp5SU=

-

-
Generate a pre-shared key on A and copy it to B to defend against
-    potential future quantum cryptanalysis (not necessary for
-  functionality):

-

-
A# (umask 0077; wg-keygen > /etc/wg/wg0.A-B)

-

-
Configure A to listen on port 1234 and allow connections from B to
-    appear in the 10.2.0.0/24 and fd00:2::/64 subnets:

-

-
A# ifconfig wg0 create
-A# ifconfig wg0 inet 10.2.0.1/24
-A# ifconfig wg0 inet6 fd00:2::1/64
-A# wgconfig wg0 set private-key /etc/wg/wg0
-A# wgconfig wg0 set listen-port 1234
-A# wgconfig wg0 add peer B \
-    X7EGm3T3IfodBcyilkaC89j0SH3XD6+/pwvp7Dgp5SU= \
-    --preshared-key=/etc/wg/wg0.A-B \
-    --allowed-ips=10.2.0.42/32,fd00:2::42/128
-A# ifconfig wg0 up
-A# ifconfig wg0
-wg0: flags=0x8041<UP,RUNNING,MULTICAST> mtu 1420
-        status: active
-        inet6 fe80::22f7:d6ff:fe3a:1e60%wg0/64 flags 0 scopeid 0x3
-        inet6 fd00:2::1/64 flags 0
-        inet 10.2.0.1/24 flags 0

-

-
You can put all these commands in
-    /etc/ifconfig.wg0 so that the interface gets
-    configured automatically during startup:

-

-
A# cat /etc/ifconfig.wg0
-inet 10.2.0.1/24
-inet6 fd00:2::1/64
-!wgconfig $int set private-key /etc/wg/wg0
-!wgconfig $int set listen-port 1234
-!wgconfig $int add peer B X7EGm3T3IfodBcyilkaC89j0SH3XD6+/pwvp7Dgp5SU= \
-    --preshared-key=/etc/wg/wg0.A-B \
-    --allowed-ips=10.2.0.42/32,fd00:2::1/128
-up

-

-
Configure B to connect to A at 192.0.2.123 on port 1234 and the
-    packets can begin to flow:

-

-
B# ifconfig wg0 create
-B# ifconfig wg0 inet 10.2.0.42/24
-B# ifconfig wg0 inet6 fd00:2::42/64
-B# wgconfig wg0 set private-key /etc/wg/wg0
-B# wgconfig wg0 add peer A \
-    N+B4Nelg+4ysvbLW3qenxIwrJVE9MdjMyqrIisH7V0Y= \
-    --preshared-key=/etc/wg/wg0.A-B \
-    --allowed-ips=10.2.0.1/32,fd00:2::1/128 \
-    --endpoint=192.0.2.123:1234
-B# ifconfig wg0 up
-B# ifconfig wg0
-wg0: flags=0x8041<UP,RUNNING,MULTICAST> mtu 1420
-        status: active
-        inet6 fe80::56eb:59ff:fe3d:d413%wg0/64 flags 0 scopeid 0x3
-        inet6 fd00:2::42/64 flags 0
-        inet 10.2.0.42/24 flags 0
-B# ping -n 10.2.0.1
-PING 10.2.0.1 (10.2.0.1): 56 data bytes
-64 bytes from 10.2.0.1: icmp_seq=0 ttl=255 time=2.721110 ms
-...
-B# ping6 -n fd00:2::1
-PING6(56=40+8+8 bytes) fd00:2::42 --> fd00:2::1
-16 bytes from fd00:2::1, icmp_seq=0 hlim=64 time=2.634 ms
-...

-

-
Same as before, you can put all these commands in
-    /etc/ifconfig.wg0 so that the interface gets
-    configured automatically during startup:

-

-
B# cat /etc/ifconfig.wg0
-inet 10.2.0.42/24
-inet6 fd00:2::42/64
-!wgconfig $int set private-key /etc/wg/wg0
-!wgconfig $int add peer A N+B4Nelg+4ysvbLW3qenxIwrJVE9MdjMyqrIisH7V0Y= \
-    --preshared-key=/etc/wg/wg0.A-B \
-    --allowed-ips=10.2.0.1/32,fd00:2::1/128 \
-    --endpoint=192.0.2.123:1234
-up

-

-

-

-

-
wg-keygen(8), wgconfig(8),
-    wg-userspace(8)

-

-

-

-
The wg interface aims to be compatible
-    with the WireGuard protocol, as described in:

-
Jason A. Donenfeld,
-    WireGuard: Next Generation Kernel Network Tunnel,
-    https://web.archive.org/web/20180805103233/https://www.wireguard.com/papers/wireguard.pdf,
-    2018-06-30, Document ID:
-    4846ada1492f5d92198df154f48c3d54205657bc.

-

-

-

-
The wg interface first appeared in
-    NetBSD 10.0.

-

-

-

-
The wg interface was implemented by
-    Ryota Ozaki
-    <ozaki.ryota@gmail.com>.

-

-

-
-  
-    
-    
-  
-
December 8, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/wi.4 4.html b/static/netbsd/man4/wi.4 4.html
deleted file mode 100644
index 7ebf8a7d..00000000
--- a/static/netbsd/man4/wi.4 4.html	
+++ /dev/null
@@ -1,167 +0,0 @@
-
-  
-    
-    
-    
-  
-
WI(4)Device Drivers ManualWI(4)

-

-

-

-
wi — WaveLAN/IEEE
-    and PRISM-II 802.11 wireless network driver

-

-

-

-
wi* at pcmcia? function ?
-  

-  wi* at pci? dev ? function ?

-

-

-

-
The wi driver provides support for Lucent
-    Technologies WaveLAN/IEEE PCCARD adapters (also known as WaveLAN II cards)
-    and various PCI/MiniPCI/PCCARD adapters which use Intersil PRISM-II and
-    PRISM-2.5 chipsets. Note that while Lucent sells both ISA and PCMCIA
-    WaveLAN/IEEE devices, the ISA product is actually a PCMCIA card in an ISA to
-    PCMCIA bridge adapter. Consequently, the wi driver
-    is required for both the ISA and PCMCIA NICs. Also note that some of the
-    PRISM-II adapters works only at 3.3V, hence cardbus(4)
-    support is required for those cards to set VCC correctly, even though they
-    are 16-bit cards.

-
The core of the WaveLAN/IEEE is the Lucent Hermes controller. All
-    host/device interaction is via programmed I/O with the Hermes. The Hermes
-    supports 802.11 and 802.3 frames, power management, BSS, WDS and ad-hoc
-    operation modes. The Silver and the Gold cards of the WaveLAN/IEEE also
-    support WEP. Unlike the other IEEE 802.11 network cards, the WaveLAN Gold
-    cards accept 104 bits key (13 characters) for WEP encryption. The Intersil
-    PRISM-II controller supports WEP as well.

-
The wi driver encapsulates all traffic as
-    802.11 frames, however it can receive either 802.11 or 802.3 frames.
-    Transmit speed is selectable between 1Mbps fixed, 2Mbps fixed or 2Mbps with
-    auto fallback. For WaveLAN/IEEE Turbo adapters, speeds up to 6Mbps are
-    available. For WaveLAN/IEEE Turbo 11Mbps adapters and PRISM-II adapters,
-    speeds up to 11Mbps are available.

-
The wi driver supports configuration of
-    Lucent cards for special ad-hoc operation. In this mode, the nwid is ignored
-    and stations can communicate among each other without the aid of an access
-    point. Note that this mode is specific to Lucent chips, and not in the IEEE
-    802.11 specification. Due to changes in the implementation of this special
-    ad-hoc mode, Lucent-based cards with different firmware revisions may not
-    interoperate in this mode. This mode is no longer the default and must be
-    selected using the ifconfig(8) (media option
-    “adhoc,flag0”) utility.

-
Recent versions of Lucent and PRISM-II firmware support IBSS
-    creation. IBSS is the standard IEEE 802.11 ad-hoc mode. In this mode, the
-    nwid should be specified. At least one node must be able to create IBSS. The
-    IBSS mode is enabled by “adhoc” or “ibss” media
-    option. IBSS creation is automatically enabled if supported.

-
The wi driver defaults to infrastructure
-    mode (i.e., using an access point).

-
Recent versions of PRISM-II firmware support operating as an
-    802.11 Access Point. In this mode, the Access Point station should set the
-    nwid. This will create a standard 802.11 network, and the Access Point
-    station will show up in an Access Point scan. This mode is enabled using the
-    “hostap” media option.

-
For more information on configuring this device, see
-    ifconfig(8) and ifmedia(4).

-

-

-

-
Cards supported by the wi driver
-  include:

-

-
    
-  
  • 3Com AirConnect 3CRWE737A
    • 
-  
  • 3Com AirConnect 3CRWE777A
    • 
-  
  • Alvarion BreezeNET
    • 
-  
  • Lucent WaveLAN/IEEE 2.0Mb Bronze
    • 
-  
  • Lucent WaveLAN/IEEE 2.0Mb Silver
    • 
-  
  • Lucent WaveLAN/IEEE Turbo
    • 
-  
  • Lucent WaveLAN/IEEE Turbo 11Mbps
    • 
-  
  • Melco AIR CONNECT WLI-PCM-L11, WLI-PCM-L11G
    • 
-  
  • Melco AIR CONNECT WLI-CF-S11G
    • 
-  
  • Compaq WL100 11Mbps Wireless
    • 
-  
  • Corega Wireless LAN PCC-11, PCCA_11, PCCB_11
    • 
-  
  • DEC/Cabletron RoamAbout 802.11 DS High Rate
    • 
-  
  • D-Link DWL-520 11Mbps PCI Card, Revs. A1,A2,B1,B2
    • 
-  
  • D-Link DWL-520 11Mbps PCI Card, Rev. C1 not supported,
-      see atw(4)
    • 
-  
  • D-Link DWL-520 11Mbps PCI Card, Rev. D not supported,
-      see rtw(4)
    • 
-  
  • D-Link DWL-650 11Mbps WLAN Card
    • 
-  
  • D-Link DWL-650 11Mbps WLAN Card, Rev. P not supported
-      (Prism 3 chipset)
    • 
-  
  • D-Link DCF-650W CF Card
    • 
-  
  • ELECOM Air@Hawk LD-WL11
    • 
-  
  • ELSA AirLancer MC-11
    • 
-  
  • Ericsson Wireless LAN
    • 
-  
  • Farallon Skyline 11Mbps Wireless
    • 
-  
  • Intel PRO/Wireless 2011 LAN PC Card
    • 
-  
  • ICOM SL-1100
    • 
-  
  • IO-DATA WN-B11/PCM
    • 
-  
  • Intersil PRISM Mini-PCI
    • 
-  
  • Linksys Group, Inc. Instant Wireless Network PC Card, CF Card
    • 
-  
  • Linksys Group, Inc. Instant Wireless Network WMP11 PCI Card
    • 
-  
  • Linksys Group, Inc. Instant Wireless Network WMP11v4 PCI Card
-      not supported
    • 
-  
  • NCR WaveLAN/IEEE
    • 
-  
  • NEC Wireless Card CMZ-RT-WP, PK-WL001, PC-WL/11C
    • 
-  
  • PLANEX GeoWave/GW-NS110
    • 
-  
  • Symbol Spectrum24 Wireless Networker PC Card, CF Card
    • 
-  
  • TDK LAK-CD011WL
    • 
-  
  • SMC EZ Connect 11M Wireless CF Card SMC2642W
    • 
-  
  • SMC EliteConnect Wireless Adapter PC Card SMC2531W-B
    • 
-  
  • Z-Com XI-626 PCI Card
    • 
-

-
The original PRISM-I chipset is supported by the
-    awi(4) driver.

-

-

-

-

-  
wi%d: init failed

-  
The WaveLAN failed to come ready after an initialization command was
-      issued.

-  
wi%d: failed to allocate %d bytes on NIC

-  
The driver was unable to allocate memory for transmit frames in the NIC's
-      on-board RAM.

-  
wi%d: device timeout

-  
The WaveLAN failed to generate an interrupt to acknowledge a transmit
-      command.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    pcmcia(4), ifconfig(8),
-    wiconfig(8)

-
HCF Light programming
-    specification,
-    http://www.wavelan.com.

-

-

-

-
The wi device driver first appeared in
-    NetBSD 1.5.

-

-

-

-
The wi driver was written by
-    Bill Paul
-    <wpaul@ctr.columbia.edu>.

-

-

-

-
The execution of wiconfig(8) while the interface
-    is down can produce some error messages.

-

-

-
-  
-    
-    
-  
-
June 2, 2016NetBSD 10.1

diff --git a/static/netbsd/man4/wm.4 4.html b/static/netbsd/man4/wm.4 4.html
deleted file mode 100644
index 0b887e5e..00000000
--- a/static/netbsd/man4/wm.4 4.html	
+++ /dev/null
@@ -1,179 +0,0 @@
-
-  
-    
-    
-    
-  
-
WM(4)Device Drivers ManualWM(4)

-

-

-

-
wm — Intel i8254x
-    Gigabit Ethernet driver

-

-

-

-
wm* at pci? dev ? function ?

-

-  

-  options WM_RX_PROCESS_LIMIT_DEFAULT
-  

-  options WM_RX_INTR_PROCESS_LIMIT_DEFAULT

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The wm device driver supports Gigabit
-    Ethernet interfaces based on the Intel i8254x family of Gigabit Ethernet
-    chips. The interfaces supported by the wm driver
-    include:

-
    
-  
  • Intel i82542 1000BASE-X Ethernet
    • 
-  
  • Intel i82543GC 1000BASE-X Ethernet
    • 
-  
  • Intel i82543GC 1000BASE-T Ethernet
    • 
-  
  • Intel i82544EI 1000BASE-T Ethernet
    • 
-  
  • Intel i82544EI 1000BASE-X Ethernet
    • 
-  
  • Intel i82544GC 1000BASE-T Ethernet
    • 
-  
  • Intel i82544GC (LOM) 1000BASE-T Ethernet
    • 
-  
  • Intel i82540EM 1000BASE-T Ethernet
    • 
-  
  • Intel i82540EM (LOM) 1000BASE-T Ethernet
    • 
-  
  • Intel i82540EP 1000BASE-T Ethernet
    • 
-  
  • Intel i82541EI 1000BASE-T Ethernet
    • 
-  
  • Intel i82541EI (Mobile) 1000BASE-T Ethernet
    • 
-  
  • Intel i82541ER 1000BASE-T Ethernet
    • 
-  
  • Intel i82541GI 1000BASE-T Ethernet
    • 
-  
  • Intel i82541PI 1000BASE-T Ethernet
    • 
-  
  • Intel i82545EM 1000BASE-T Ethernet
    • 
-  
  • Intel i82545EM 1000BASE-X Ethernet
    • 
-  
  • Intel i82545GB 1000BASE-T Ethernet
    • 
-  
  • Intel i82545GB 1000BASE-X Ethernet
    • 
-  
  • Intel i82545GM 1000BASE-T Ethernet
    • 
-  
  • Intel i82546EB 1000BASE-T Ethernet (dual-port)
    • 
-  
  • Intel i82546EB 1000BASE-X Ethernet (dual-port)
    • 
-  
  • Intel i82546GB 1000BASE-T Ethernet (dual-port)
    • 
-  
  • Intel i82546GB 1000BASE-X Ethernet (dual-port)
    • 
-  
  • Intel i82547EI 1000BASE-T Ethernet (CSA)
    • 
-  
  • Intel i82547GI 1000BASE-T Ethernet (CSA)
    • 
-  
  • Intel i82571 1000BASE-T Ethernet (dual-port)
    • 
-  
  • Intel i82572 1000BASE-T Ethernet
    • 
-  
  • Intel i82573 1000BASE-T Ethernet
    • 
-  
  • Intel i82575 1000BASE-T Ethernet
    • 
-  
  • Intel i82576 Ethernet (Copper, Fiber)
    • 
-  
  • Intel i80003 Ethernet (Copper, Fiber)
    • 
-  
  • Intel i82801H (ICH8 LAN) 1000BASE-T Ethernet
    • 
-  
  • Intel i82801I (ICH9 LAN) 1000BASE-T Ethernet
    • 
-  
  • Intel i82801J (ICH10 LAN) 1000BASE-T Ethernet
    • 
-  
  • Intel 82578 with Intel 5 series chipset (PCH)
    • 
-  
  • Intel 82579 with Intel 6 or 7 series chipset (PCH2)
    • 
-  
  • Intel 82580 Ethernet (Copper, Fiber)
    • 
-  
  • Intel 82583 1000BASE-T Ethernet
    • 
-  
  • Intel I350 Ethernet (Copper, Fiber)
    • 
-  
  • Intel I354 (C2000 Internal) Ethernet (Copper, Fiber)
    • 
-  
  • Intel I210 Ethernet (Copper, Fiber)
    • 
-  
  • Intel I211 Ethernet
    • 
-  
  • Intel I217 and I218 Ethernet
    • 
-  
  • Intel I219 Ethernet (with Intel [123]00 series chipset)
    • 
-

-
In addition to Intel's own “PRO/1000” line of
-    Gigabit Ethernet interfaces, these chips also appear on some server systems,
-    processor evaluation boards, and in embedded systems.

-
The i825[478]x supports IPv4/TCP/UDP checksumming and TCP
-    segmentation in hardware. The wm driver supports
-    these features of the chip. At least for some chips (e.g. I219) hardware TCP
-    segmentation is slow, and slows down transmit performance when turned on.
-    See ifconfig(8) for information on how to enable this
-    feature.

-
Many chips supported by the wm driver
-    support jumbo frames, however several chips do not support jumbo frames,
-    e.g. i82542, i82081H and 82567V. Jumbo frames can be configured via the
-    interface MTU setting. Selecting an MTU larger than 1500 bytes with the
-    ifconfig(8) utility configures the adapter to receive and
-    transmit jumbo frames.

-

-

-

-
The driver default behavior is to handle packets in interrupt
-    context, which reduces the CPU time available to user processes when under
-    heavy network load. The
-    
-    sysctl(8) alters this behavior so that packets are handled
-    by a kernel thread, which executes at a lower priority. This gives user
-    processes more opportunity to be executed, at the expense of network
-    throughput.

-
The following options can be set at build time:

-

-

-  

-  
The maximum number of received packets processed in each
-      softint(9) context. This option only affects multiqueue.
-      The value range is from zero to UINT_MAX. The
-      default value is 100. When you increase this value, both the receive
-      latency and the receive throughput will increase.

-  

-  
Transmit side of WM_RX_PROCESS_LIMIT_DEFAULT.

-  

-  
The maximum number of received packets processed in each hardware
-      interrupt context. This option only affects multiqueue. The value range is
-      from zero to UINT_MAX. The default value is 0.
-      When you increase this value, both the receive latency and the receive
-      throughput will decrease.

-  

-  
Transmit side of
-    WM_RX_INTR_PROCESS_LIMIT_DEFAULT.

-  

-  
Enable many event counters such as each Tx drop counter and Rx interrupt
-      counter. In 64 bit architectures, this is enabled by default. Caution: If
-      this flag is enabled, the number of evcnt entries increase very much.

-  

-  
Disable event counters for 64 bit architectures.

-  

-  
If this option is set non-zero value, this driver does not use msi. The
-      default value is 0.

-  

-  
If this option is set non-zero value, this driver does not use msix. The
-      default value is 0.

-

-

-
Setting WM_RX_INTR_PROCESS_LIMIT_DEFAULT
-    to zero means so-called polling mode, that is, once an interrupt occurs, the
-    driver keep processing received packets until
-    WM_RX_PROCESS_LIMIT_DEFAULT. Polling mode increases
-    latency a little, however it suppresses performance degradation at high load
-    very well.

-
If you want to disable polling mode (to use traditional interrupt
-    driven mode), you should set
-    WM_RX_PROCESS_LIMIT_DEFAULT to zero and set
-    WM_RX_INTR_PROCESS_LIMIT_DEFAULT to
-    UINT_MAX.

-

-

-

-
arp(4), ifmedia(4),
-    mii(4), netintro(4),
-    pci(4), ifconfig(8),
-    sysctl(8)

-

-

-

-
The wm driver first appeared in
-    NetBSD 1.6.

-

-

-

-
The wm driver was written by
-    Jason R. Thorpe
-    <thorpej@wasabisystems.com>.

-

-

-

-
EEE (Energy Efficiency Ethernet) is not currently supported.

-

-

-
-  
-    
-    
-  
-
February 17, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/wpi.4 4.html b/static/netbsd/man4/wpi.4 4.html
deleted file mode 100644
index 1d7dd0d7..00000000
--- a/static/netbsd/man4/wpi.4 4.html	
+++ /dev/null
@@ -1,206 +0,0 @@
-
-  
-    
-    
-    
-  
-
WPI(4)Device Drivers ManualWPI(4)

-

-

-

-
wpi — Intel
-    PRO/Wireless 3945ABG IEEE 802.11a/b/g wireless network driver

-

-

-

-
wpi* at pci? dev ? function ?

-

-

-

-
The wpi driver provides support for Intel
-    PRO/Wireless 3945ABG Mini PCI Express network adapters.

-
These are the modes the wpi driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks to which it wouldn't
-      normally have access, or to scan for access points.

-

-
wpi supports software WEP. Wired
-    Equivalent Privacy (WEP) is the de facto encryption standard for wireless
-    networks. It can be typically configured in one of three modes: no
-    encryption; 40-bit encryption; or 104-bit encryption. Unfortunately, due to
-    serious weaknesses in the WEP protocol it is strongly recommended that it
-    not be used as the sole mechanism to secure wireless communication. WEP is
-    not enabled by default.

-

-

-

-
The wpi driver can be configured at
-    runtime with ifconfig(8) using the following
-  parameters:

-

-  

-    bssid

-  
Set the desired BSSID.

-  

-  
Unset the desired BSSID. The interface will automatically select a BSSID
-      in this mode, which is the default.

-  

-    n

-  
Set the channel (radio frequency) to be used by the driver based on the
-      given channel ID n.

-  

-  
Unset the desired channel to be used by the driver. The driver will
-      automatically select a channel in this mode, which is the default.

-  

-    media

-  
The wpi driver supports the following
-      media types:
-    

-    

-      

-      
Enable autoselection of the media type and options.

-    

-  

-  

-    opts

-  
The wpi driver supports the following media
-      options:
-    

-    

-      

-      
Select monitor mode.

-    

-  

-  

-    opts

-  
Disable the specified media options on the driver and return it to the
-      default mode of operation (BSS).

-  

-    mode

-  
The wpi driver supports the following modes:
-    

-    

-      

-      
Force 802.11a operation.

-      

-      
Force 802.11b operation.

-      

-      
Force 802.11g operation.

-    

-  

-  

-    id

-  
Set the network ID. The id can either be any text
-      string up to 32 characters in length, or a series of hexadecimal digits up
-      to 64 digits. An empty id string allows the
-      interface to connect to any available access points. By default the
-      wpi driver uses an empty string. Note that network
-      ID is synonymous with Extended Service Set ID (ESSID).

-  

-    key

-  
Enable WEP encryption using the specified key. The
-      key can either be a string, a series of hexadecimal
-      digits (preceded by ‘0x’), or a set of keys of the form
-      “n:k1,k2,k3,k4”, where ‘n’ specifies which of
-      the keys will be used for transmitted packets, and the four keys,
-      “k1” through “k4”, are configured as WEP keys.
-      If a set of keys is specified, a comma (‘,’) within the key
-      must be escaped with a backslash. Note that if multiple keys are used,
-      their order must be the same within the network.
-      wpi is capable of using both 40-bit (5 characters
-      or 10 hexadecimal digits) or 104-bit (13 characters or 26 hexadecimal
-      digits) keys.

-  

-  
Disable WEP encryption. This is the default mode of operation.

-

-

-

-

-
The driver needs at least version 2.14.4 of the following firmware
-    file, which is loaded when an interface is brought up:

-

-

-

-  
/libdata/firmware/if_wpi/iwlwifi-3945.ucode

-  
 

-

-

-

-

-

-

-
# ifconfig wpi0 nwkey 0x1deadbeef1

-

-
Return wpi0 to its default settings:

-

-
# ifconfig wpi0 -bssid -chan media autoselect \
-	nwid "" -nwkey

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig wpi0 192.168.1.1 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
wpi%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-  
wpi%d: fatal firmware error

-  
For some reason, the firmware crashed. The driver will reset the hardware.
-      This should not happen.

-  
wpi%d: Radio transmitter is off

-  
The radio transmitter is off and thus no packet can go out. The driver
-      will reset the hardware. Make sure the laptop radio switch is on.

-  
wpi%d: could not read firmware file

-  
For some reason, the driver was unable to read the firmware image from the
-      filesystem. The file might be missing or corrupted.

-  
wpi%d: firmware file too short: %d bytes

-  
The firmware image is corrupted and can't be loaded into the adapter.

-  
wpi%d: could not load firmware

-  
An attempt to load the firmware into the adapter failed. The driver will
-      reset the hardware.

-

-

-

-

-
On some laptops the radio transmitter button must be pushed twice
-    to get the driver working, or you will get a wpi%d: fatal
-    firmware error when the interface will be set to up

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    pci(4), ifconfig(8),
-    firmload(9)

-
The IPW Web Page,
-    http://damien.bergamini.free.fr/ipw/.

-

-

-

-
The wpi driver was originally written by
-    Damien Bergamini
-    <damien@openbsd.org>.
-    NetBSD porting was done by
-    Jean-Baptiste Campesato
-    <camjelemon@gmail.com>.

-

-

-
-  
-    
-    
-  
-
October 14, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/wsbell.4 4.html b/static/netbsd/man4/wsbell.4 4.html
deleted file mode 100644
index 32680ac2..00000000
--- a/static/netbsd/man4/wsbell.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSBELL(4)Device Drivers ManualWSBELL(4)

-

-

-

-
wsbell — generic
-    bell support in wscons

-

-

-

-
wsbell* at spkr? console?

-

-

-

-
The wsbell driver utilizes the
-    speaker(4) driver to provide a system bell with or without
-    a keyboard for the wscons(4) framework. When a bell
-    character is received on a wsdisplay(4) screen,
-    wsbell sounds the bell.

-
The wsconsctl(8) utility gives access to several
-    configurable parameters that affect the sound of the system bell.

-

-

-
The following ioctl(2) calls are provided by the
-    wsbell driver. Their definitions are found in
-    dev/wscons/wsconsio.h.

-

-  

-  
Will sound the default bell.

-  

-  
Will return a struct wskbd_bell_data with the current bell
-    parameters.

-  

-  
Takes a struct wskbd_bell_data and uses it to set the bell parameters.
-      These are used by the WSKBDIO_BELL ioctl(2) call.

-  

-  
Will sound a bell using a supplied struct wskbd_bell_data for its
-      parameters.

-  

-  
Will return a struct wskbd_bell_data with the default
-      bell parameters.

-  

-  
Takes a struct wskbd_bell_data and uses it to set the
-      default bell parameters.

-

-
Ioctls use the following structure:

-

-
struct wskbd_bell_data {
-	u_int	which;			/* values to get/set */
-#define	WSKBD_BELL_DOPITCH	0x1	/* get/set pitch */
-#define	WSKBD_BELL_DOPERIOD	0x2	/* get/set period */
-#define	WSKBD_BELL_DOVOLUME	0x4	/* get/set volume */
-#define	WSKBD_BELL_DOALL	0x7	/* all of the above */
-	u_int	pitch;			/* pitch, in Hz */
-	u_int	period;			/* period, in milliseconds */
-	u_int	volume;			/* percentage of max volume */
-};

-

-

-

-

-

-
    
-  
  • /usr/include/dev/wscons/wsconsio.h.
    • 
-

-

-

-

-
speaker(4), wscons(4),
-    wskbd(4), wsmux(4),
-    wsconsctl(8), wsbell(9)

-

-

-
-  
-    
-    
-  
-
June 13, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/wscons.4 4.html b/static/netbsd/man4/wscons.4 4.html
deleted file mode 100644
index c58e94bd..00000000
--- a/static/netbsd/man4/wscons.4 4.html	
+++ /dev/null
@@ -1,260 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSCONS(4)Device Drivers ManualWSCONS(4)

-

-

-

-
wscons —
-    workstation console access

-

-

-

-
wsdisplay* at ...
-  

-  wskbd* at ... mux N
-  

-  wsmouse* at ... mux N

-

-  

-  pseudo-device wsmux

-

-  

-  options WSEMUL_SUN
-  

-  options WSEMUL_VT100
-  

-  options WSEMUL_NO_DUMB
-  

-  options WSEMUL_DEFAULT="xxx"

-

-  

-  options WS_DEFAULT_FG=WSCOL_XXX
-  

-  options WS_DEFAULT_BG=WSCOL_XXX
-  

-  options
-    WS_DEFAULT_COLATTR="(WSATTR_XXX | WSATTR_YYY)"
-  

-  options
-    WS_DEFAULT_MONOATTR="(WSATTR_XXX | WSATTR_YYY)"
-  

-  options WS_KERNEL_FG=WSCOL_XXX
-  

-  options WS_KERNEL_BG=WSCOL_XXX
-  

-  options
-    WS_KERNEL_COLATTR="(WSATTR_XXX | WSATTR_YYY)"
-  

-  options
-    WS_KERNEL_MONOATTR="(WSATTR_XXX | WSATTR_YYY)"

-

-  

-  options WSDISPLAY_COMPAT_PCVT
-  

-  options WSDISPLAY_COMPAT_SYSCONS
-  

-  options WSDISPLAY_COMPAT_USL
-  

-  options WSCOMPAT_USL_SYNCTIMEOUT=nnn
-  

-  options WSDISPLAY_COMPAT_RAWKBD

-

-  

-  options WSKBD_EVENT_AUTOREPEAT
-  

-  options WSKBD_USONLY

-

-

-

-
The wscons driver provides support for
-    machine independent access to the console.

-
wscons is made of a number of cooperating
-    modules, in particular

-
    
-  
  • hardware support for display adapters, keyboards and mice, see
-      wsdisplay(4), wskbd(4), and
-      wsmouse(4)
    • 
-  
  • input event multiplexor, see wsmux(4)
    • 
-  
  • terminal emulation modules (see below), and
    • 
-  
  • compatibility options to support control operations and other low-level
-      behaviour of existing terminal drivers (see below)
    • 
-

-

-

-
wscons does not define its own set of
-    terminal control sequences and special keyboard codes in terms of
-    terminfo(5). Instead a “terminal emulation”
-    is assigned to each virtual screen when the screen is created. (See
-    wsconscfg(8).) Different terminal emulations can be active
-    at the same time on one display. The following choices are available:

-

-  
dumb

-  
This minimal terminal support is available unless the kernel option
-      options WSEMUL_NO_DUMB was specified at build
-      time. No control sequences are supported besides the ASCII control
-      characters. The cursor is not addressable. Only ASCII keyboard codes will
-      be delivered, cursor and functions keys do not work.

-  
sun

-  
The “sun” console emulation is available if
-      options WSEMUL_SUN was specified at kernel build
-      time. It supports the control sequences of SUN machine consoles and
-      delivers its keyboard codes for function and keypad keys in use. This
-      emulation is sufficient for full-screen applications.

-  
vt100

-  
is available with the kernel compile option options
-      WSEMUL_VT100. It provides the most commonly used functions of DEC
-      VT100 terminals with some extensions introduced by the DEC VT220 and DEC
-      VT320 models. The features of the original VT100 which are not or not
-      completely implemented are:
-    
    
-      
  • VT52 support, 132-column-mode, smooth scroll, light background,
-          keyboard autorepeat control, external printer support, keyboard
-          locking, newline/linefeed switching: Escape sequences related to these
-          features are ignored or answered with standard replies. (DECANM,
-          DECCOLM, DECSCLM, DECSCNM, DECARM, DECPFF, DECPEX, KAM, LNM)
    • 
-      
  • Function keys are not reprogrammable and fonts can not be downloaded.
-          DECUDK and DECDLD sequences will be ignored.
    • 
-      
  • Neither C1 control set characters will be recognized nor will 8-bit
-          keyboard codes be delivered.
    • 
-      
  • The “DEC supplemental graphic” font is approximated by
-          the ISO-latin-1 font, though there are subtle differences.
    • 
-      
  • The actual rendering quality depends on the underlying graphics
-          hardware driver. Characters might be missing in the available fonts
-          and be substituted by more or less fitting replacements.
-        
    Depending on the keyboard used, not all function keys
-            might be available.
    
-      
    • 
-    

-    
In addition to the plain VT100 functions are supported:

-    
    
-      
  • ANSI colors.
    • 
-      
  • Some VT220-like presentation state settings and -reports (DECRSPS),
-          especially tabulator settings.
    • 
-    

-    
In most applications, wscons will work
-        sufficiently as a VT220 emulator.

-  

-

-
The WSEMUL_DEFAULT kernel option is used
-    to select one of the described terminal options as the default choice. The
-    default takes effect at kernel startup, i.e. for the operating system
-    console or additional screens allocated through the
-    WSDISPLAY_DEFAULTSCREENS option (see
-    wsdisplay(4)), or if no emulation type was passed to the
-    wsconscfg(8) utility.

-

-

-

-
These options allow X servers and other programs using low-level
-    console driver functions usually written specifically for other console
-    drivers to run on NetBSD systems. The options are in
-    particular:

-

-  
WSDISPLAY_COMPAT_USL

-  
Support the protocol for switches between multiple virtual screens on one
-      display as used by most PC-UNIX variants. This is used by the
-      NetBSD wsconscfg(8)
-    utility.

-  
WSDISPLAY_COMPAT_RAWKBD

-  
Allows to get raw XT keyboard scancodes from PC keyboards as needed by
-      i386 X servers.

-  
WSDISPLAY_COMPAT_PCVT

-  
Emulates enough of the NetBSD/i386
-      “pcvt” driver to make X servers work.

-  
WSDISPLAY_COMPAT_SYSCONS

-  
Emulates enough of the FreeBSD
-      “syscons” driver to make X servers work. Useful with
-      FreeBSD binary emulation.

-

-
Linux/i386 X servers usually run successfully if the first two
-    options are enabled together with the NetBSD Linux
-    binary emulation.

-
(To have programs looking for device special files of other
-    console drivers find the wscons driver entry points,
-    symlinks are a helpful measure.)

-

-

-

-

-  
options WS_DEFAULT_FG=WSCOL_XXX

-  
 

-  
options WS_DEFAULT_BG=WSCOL_XXX

-  
 

-  
options
-    WS_DEFAULT_COLATTR="(WSATTR_XXX | WSATTR_YYY)"

-  
 

-  
options
-    WS_DEFAULT_MONOATTR="(WSATTR_XXX | WSATTR_YYY)"

-  
Make default console output appear in specific colors and attributes.
-      WS_DEFAULT_FG and
-      WS_DEFAULT_BG set the foreground and background
-      used on color displays. WS_DEFAULT_COLATTR and
-      WS_DEFAULT_MONOATTR are additional attribute flags
-      used on color or monochrome displays, respectively. Whether the attributes
-      are supported or not depends on the actually used graphics adapter. These
-      options are ignored by the “dumb” terminal emulation.
-    
See src/sys/dev/wscons/wsdisplayvar.h
-        for available WSCOL_XXX and
-        WSATTR_XXX values.

-    

-  

-  
options WS_KERNEL_FG=WSCOL_XXX

-  
 

-  
options WS_KERNEL_BG=WSCOL_XXX

-  
 

-  
options
-    WS_KERNEL_COLATTR="(WSATTR_XXX | WSATTR_YYY)"

-  
 

-  
options
-    WS_KERNEL_MONOATTR="(WSATTR_XXX | WSATTR_YYY)"

-  
Make console output originating from the kernel appear differently than
-      output from user level programs (via /dev/console
-      or the specific tty device like /dev/ttyE0). Their
-      meaning is the same as their WS_DEFAULT_*
-      counterparts.
-    

-  

-  
options WSCOMPAT_USL_SYNCTIMEOUT=nnn

-  
The virtual screen switching protocol enabled by
-      WSDISPLAY_COMPAT_USL uses a somewhat complex
-      handshake protocol to pass control to user programs such as X servers
-      controlling a virtual screen. In order to prevent a non-responsive
-      application from locking the whole console system, a screen switch will be
-      rolled back after a 5 second timeout if the application does not respond.
-      This option can be used to specify in seconds a different timeout value.
-    

-  

-  
options WSKBD_EVENT_AUTOREPEAT

-  
If set, this option enables auto repeat even in event mode. The auto
-      repeat will generate key down events while the key is pressed.
-    

-  

-  
options WSKBD_USONLY

-  
In order to strip down the space usage of wscons, all keymaps except the
-      US english one can be removed from the kernel with this option, which
-      results in a space gain of about 10kB.

-

-

-

-

-

-
wsdisplay(4), wskbd(4),
-    wsmouse(4), wsmux(4),
-    wsconscfg(8), wsconsctl(8),
-    wsfontload(8), wscons(9)

-

-

-
-  
-    
-    
-  
-
June 5, 2012NetBSD 10.1

diff --git a/static/netbsd/man4/wsdisplay.4 3.html b/static/netbsd/man4/wsdisplay.4 3.html
deleted file mode 100644
index 51f6f476..00000000
--- a/static/netbsd/man4/wsdisplay.4 3.html	
+++ /dev/null
@@ -1,530 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSDISPLAY(4)Device Drivers ManualWSDISPLAY(4)

-

-

-

-
wsdisplay —
-    generic display device support in wscons

-

-

-

-
wsdisplay* at ega? console ? (EGA display
-    on ISA)
-  

-  wsdisplay* at vga? console ? (VGA display on ISA or
-    PCI)
-  

-  wsdisplay* at pcdisplay? console ? (generic PC (ISA)
-    display)
-  

-  wsdisplay* at tga? console ? (DEC TGA display, alpha
-    only)
-  

-  wsdisplay* at pfb? console ? (PCI framebuffer, bebox
-    only)
-  

-  wsdisplay0 at ofb? console ? (Open Firmware
-    framebuffer, macppc only)
-  

-  wsdisplay* at nextdisplay? console ? (NeXT display)
-  

-  wsdisplay0 at smg0 (VAXstation small monochrome
-    display)
-  

-  wsdisplay* at ... kbdmux N

-

-  

-  options WSDISPLAY_BORDER_COLOR=WSCOL_XXX
-  

-  options WSDISPLAY_CUSTOM_BORDER
-  

-  options WSDISPLAY_CUSTOM_OUTPUT
-  

-  options WSDISPLAY_DEFAULTSCREENS=N
-  

-  options WSDISPLAY_SCROLLSUPPORT

-

-

-

-
The wsdisplay driver is an abstraction
-    layer for display devices within the wscons(4) framework.
-    It attaches to the hardware specific display device driver and makes it
-    available as a text terminal or graphics interface.

-
A display device can have the ability to display characters on it
-    (without the help of an X server), either directly by hardware or through
-    software putting pixel data into the display memory. Such displays are
-    called “emulating”, the wsdisplay
-    driver will connect a terminal emulation module and provide a tty-like
-    software interface. In contrary, non-emulating displays can only be used by
-    special programs like X servers.

-
The console locator in the configuration
-    line refers to the device's use as the output part of the operating system
-    console. A device specification containing a positive value here will only
-    match if the device is in use as the system console. (The console device
-    selection in early system startup is not influenced.) This way, the console
-    device can be connected to a known wsdisplay device instance. (Naturally,
-    only “emulating” display devices are usable as console.)

-
The kbdmux locator in the configuration
-    line refers to the wsmux(4) that will be used to get
-    keyboard events. If this locator is -1 no mux will be used.

-
The logical unit of independent contents displayed on a display
-    (sometimes referred to as “virtual terminal”) is called a
-    “screen” here. If the underlying device driver supports it,
-    multiple screens can be used on one display. (As of this writing, only the
-    vga(4) and the VAX “smg” display drivers
-    provide this ability.) Screens have different minor device numbers and
-    separate tty instances. One screen possesses the “focus”, this
-    means it is visible and its tty device will get the keyboard input. (In some
-    cases - if no screen is set up or if a screen was just deleted - it is
-    possible that no focus is present at all.) The focus can be switched by
-    either special keyboard input (typically
-    ⟨Ctrl⟩⟨Alt⟩⟨Fn⟩,
-    ⟨Stop⟩⟨Fn⟩ on Sun
-    hardware, ⟨Command⟩⟨Fn⟩ on
-    ADB keyboards) or an ioctl command issued by a user program. Screens are
-    created and deleted through the /dev/ttyEcfg control
-    device (preferably using the wsconscfg(8) utility).
-    Alternatively, the compile-time option
-    WSDISPLAY_DEFAULTSCREENS=n
-    will also create (at autoconfiguration time) n initial
-    screens of the display driver's default type with the system's default
-    terminal emulator.

-

-

-
The following kernel options are available to configure the
-    behavior of the wsdisplay driver:

-

-  
options WSDISPLAY_BORDER_COLOR=WSCOL_XXX

-  
Sets the border color at boot time. Possible values are defined in
-      src/sys/dev/wscons/wsdisplayvar.h. Defaults to
-      WSCOL_BLACK.

-  
options WSDISPLAY_CUSTOM_BORDER

-  
Enables the WSDISPLAYIO_GBORDER and
-      WSDISPLAYIO_SBORDER ioctls, which allow the
-      customization of the border color from userland (after boot). See
-      wsconsctl(8).

-  
options WSDISPLAY_CUSTOM_OUTPUT

-  
Enables the WSDISPLAYIO_GMSGATTRS and
-      WSDISPLAYIO_SMSGATTRS ioctls, which allow the
-      customization of the console output and kernel messages from userland
-      (after boot). See wsconsctl(8).

-  
options WSDISPLAY_DEFAULTSCREENS=N

-  
Sets the number of virtual screens to allocate at boot time. Useful for
-      small root filesystems where the wsconscfg(8) utility is
-      not wanted.

-  
options WSDISPLAY_SCROLLSUPPORT

-  
Enables scrolling support. The key combinations are
-      ⟨Left Shift⟩⟨Page Up⟩ and
-      ⟨Left Shift⟩⟨Page Down⟩ by
-      default. Please note that this function may not work under the system
-      console and is available depending on the framebuffer you are using.

-

-

-

-

-
The following ioctl(2) calls are provided by the
-    wsdisplay driver or by devices which use it. Their
-    definitions are found in
-    <dev/wscons/wsconsio.h>.

-

-  

-    (int)

-  
Retrieve the type of the display. The list of types is in
-      <dev/wscons/wsconsio.h>.

-  

-    (struct wsdisplayio_fbinfo)

-  
Retrieve extended information about a framebuffer display, including the
-      framebuffer's pixel packing layout. The returned structure is as follows:
-    

-    
struct wsdisplayio_fbinfo {
-	uint64_t fbi_fbsize;
-	uint64_t fbi_fboffset;
-	uint32_t fbi_width;
-	uint32_t fbi_height;
-	uint32_t fbi_stride;
-	uint32_t fbi_bitsperpixel;
-	uint32_t fbi_pixeltype;
-	union _fbi_subtype {
-		struct _fbi_rgbmasks {
-			uint32_t red_offset;
-			uint32_t red_size;
-			uint32_t green_offset;
-			uint32_t green_size;
-			uint32_t blue_offset;
-			uint32_t blue_size;
-			uint32_t alpha_offset;
-			uint32_t alpha_size;
-		} fbi_rgbmasks;
-		struct _fbi_cmapinfo {
-			uint32_t cmap_entries;
-		} fbi_cmapinfo;
-	} fbi_subtype;
-	uint32_t fbi_flags;
-};

-    

-    
For a "true colour" display, the
-        fbi_pixeltype field contains
-        WSFB_RGB and the
-        fbi_rgbmasks field contains the pixel packing
-        layout. For a colour indexed display, the
-        fbi_pixeltype field contains
-        WSFB_CI and the
-        fbi_cmapinfo field contains the number of color
-        map entries.

-  

-  

-    (struct wsdisplay_fbinfo)

-  
Retrieve basic information about a framebuffer display. The returned
-      structure is as follows:
-    

-    
struct wsdisplay_fbinfo {
-	u_int	height;
-	u_int	width;
-	u_int	depth;
-	u_int	cmsize;
-};

-    

-    
The height and
-        width members are counted in pixels. The
-        depth member indicates the number of bits per
-        pixel, and cmsize indicates the number of color
-        map entries accessible through
-        WSDISPLAYIO_GETCMAP and
-        WSDISPLAYIO_PUTCMAP. This call is likely to be
-        unavailable on text-only displays.

-  

-  

-    (struct wsdisplay_cmap)

-  
Retrieve the current color map from the display. This call needs the
-      following structure set up beforehand:
-    

-    
struct wsdisplay_cmap {
-	u_int	index;
-	u_int	count;
-	u_char	*red;
-	u_char	*green;
-	u_char	*blue;
-};

-    

-    
The index and
-        count members specify the range of color map
-        entries to retrieve. The red,
-        green, and blue members
-        should each point to an array of count
-        u_chars. On return, these
-        will be filled in with the appropriate entries from the color map. On
-        all displays that support this call, values range from 0 for minimum
-        intensity to 255 for maximum intensity, even if the display does not use
-        eight bits internally to represent intensity.

-  

-  

-    (struct wsdisplay_cmap)

-  
Change the display's color map. The argument structure is the same as for
-      WSDISPLAYIO_GETCMAP, but
-      red, green, and
-      blue are taken as pointers to the values to use to
-      set the color map. This call is not available on displays with fixed color
-      maps.

-  

-    (int)

-  
Get the current state of the display's video output. Possible values are:
-    

-      

-      
The display is blanked.

-      

-      
The display is enabled.

-    

-  

-  

-    (int)

-  
Set the state of the display's video output. See
-      WSDISPLAYIO_GVIDEO above for possible values.

-  

-    (struct wsdisplay_curpos)

-  
Retrieve the current position of the hardware cursor. The returned
-      structure is as follows:
-    

-    
struct wsdisplay_curpos {
-        u_int x, y;
-};

-    

-    
The x and y
-        members count the number of pixels right and down, respectively, from
-        the top-left corner of the display to the hot spot of the cursor. This
-        call is not available on displays without a hardware cursor.

-  

-  

-    (struct wsdisplay_curpos)

-  
Set the current cursor position. The argument structure, and its
-      semantics, are the same as for
-      WSDISPLAYIO_GCURPOS. This call is not available on
-      displays without a hardware cursor.

-  

-    (struct wsdisplay_curpos)

-  
Retrieve the maximum size of cursor supported by the display. The
-      x and y members of the
-      returned structure indicate the maximum number of pixel rows and columns,
-      respectively, in a hardware cursor on this display. This call is not
-      available on displays without a hardware cursor.

-  

-    (struct wsdisplay_cursor)

-  
Retrieve some or all of the hardware cursor's attributes. The argument
-      structure is as follows:
-    

-    
struct wsdisplay_cursor {
-	u_int	which;
-	u_int	enable;
-	struct wsdisplay_curpos pos;
-	struct wsdisplay_curpos hot;
-	struct wsdisplay_cmap cmap;
-	struct wsdisplay_curpos size;
-	u_char *image;
-	u_char *mask;
-};
-
-    

-    

-    The which member indicates which of the values the
-      application requires to be returned. It should contain the logical OR of
-      the following flags:
-    

-      

-      
Get enable, which indicates whether the cursor
-          is currently displayed (non-zero) or not (zero).

-      

-      
Get pos, which indicates the current position of
-          the cursor on the display, as would be returned by
-          WSDISPLAYIO_GCURPOS.

-      

-      
Get hot, which indicates the location of the
-          “hot spot” within the cursor. This is the point on the
-          cursor whose position on the display is treated as being the position
-          of the cursor by other calls. Its location is counted in pixels from
-          the top-right corner of the cursor.

-      

-      
Get cmap, which indicates the current cursor
-          color map. Unlike in a call to
-          WSDISPLAYIO_GETCMAP,
-          cmap here need not have its
-          index and count members
-          initialized. They will be set to 0 and 2 respectively by the call.
-          This means that cmap.red,
-          cmap.green, and
-          cmap.blue must each point
-          to at least enough space to hold two
-          u_chars.

-      

-      
Get size, image, and
-          mask. These are, respectively, the dimensions of
-          the cursor in pixels, the bitmap of set pixels in the cursor and the
-          bitmap of opaque pixels in the cursor. The format in which these
-          bitmaps are returned, and hence the amount of space that must be
-          provided by the application, are device-dependent.

-      

-      
Get all of the above.

-    

-    
The device may elect to return information that was not
-        requested by the user, so those elements of struct
-        wsdisplay_cursor which are pointers should be initialized to
-        NULL if not otherwise used. This call is not
-        available on displays without a hardware cursor.

-  

-  

-    (struct wsdisplay_cursor)

-  
Set some or all of the hardware cursor's attributes. The argument
-      structure is the same as for WSDISPLAYIO_GCURSOR.
-      The which member specifies which attributes of the
-      cursor are to be changed. It should contain the logical OR of the
-      following flags:
-    

-      

-      
If enable is zero, hide the cursor. Otherwise,
-          display it.

-      

-      
Set the cursor's position on the display to pos,
-          the same as WSDISPLAYIO_SCURPOS.

-      

-      
Set the “hot spot” of the cursor, as defined above, to
-          hot.

-      

-      
Set some or all of the cursor color map based on
-          cmap. The index and
-          count elements of cmap
-          indicate which color map entries to set, and the entries themselves
-          come from cmap.red,
-          cmap.green, and
-          cmap.blue.

-      

-      
Set the cursor shape from size,
-          image, and mask. See above
-          for their meanings.

-      

-      
Do all of the above.

-    

-    
This call is not available on displays without a hardware
-        cursor.

-  

-  

-    (u_int)

-  
Get the current mode of the display. Possible results include:
-    

-      

-      
The display is in emulating (text) mode.

-      

-      
The display is in mapped (graphics) mode.

-      

-      
The display is in mapped (frame buffer) mode.

-    

-  

-  

-    (u_int)

-  
Set the current mode of the display. For possible arguments, see
-      WSDISPLAYIO_GMODE.

-  

-    (u_int)

-  
Get the number of bytes per row, which may be the same as the number of
-      pixels.

-  

-    (struct wsdisplay_msgattrs)

-  
Get the attributes (colors and flags) used to print console messages,
-      including separate fields for default output and kernel output. The
-      returned structure is as follows:
-    

-    
struct wsdisplay_msgattrs {
-	int default_attrs, default_bg, default_fg;
-	int kernel_attrs, kernel_bg, kernel_fg;
-};

-    

-    
The default_attrs and
-        kernel_attrs variables are a combination of
-        WSATTR_* bits, and specify
-        the attributes used to draw messages. The
-        default_bg, default_fg,
-        kernel_bg and kernel_fg
-        variables specify the colors used to print messages, being
-        ‘_bg’ for the background and ‘_fg’ for the
-        foreground; their values are one of all the
-        WSCOL_* macros
-      available.

-  

-  

-    (struct wsdisplay_msgattrs)

-  
Set the attributes (colors and flags) used to print console messages,
-      including separate fields for default output and kernel output. The
-      argument structure is the same as for
-      WSDISPLAYIO_GMSGATTRS.

-  

-    (u_int)

-  
Retrieve the color of the screen border. This number corresponds to an
-      ANSI standard color.

-  

-    (u_int)

-  
Set the color of the screen border, if applicable. This number corresponds
-      to an ANSI standard color. Not all drivers support this feature.

-  

-    (struct wsdisplay_char)

-  
Gets a single character from the screen, specified by its position. The
-      structure used is as follows:
-    

-    
struct wsdisplay_char {
-	int row, col;
-	uint16_t letter;
-	uint8_t background, foreground;
-	char flags;
-};

-    

-    
The row and col
-        parameters are used as input; the rest of the structure is filled by the
-        ioctl and is returned to you. letter is the ASCII
-        code of the letter found at the specified position,
-        background and foreground
-        are its colors and flags is a combination of
-        WSDISPLAY_CHAR_BRIGHT and/or
-        WSDISPLAY_CHAR_BLINK.

-  

-  

-    (struct wsdisplay_char)

-  
Puts a character on the screen. The structure has the same meaning as
-      described in WSDISPLAY_GETWSCHAR, although all of
-      its fields are treated as input.

-  

-    (u_int)

-  
Toggle the splash screen. This call is only available with the
-      SPLASHSCREEN kernel option.

-  

-    (struct wsdisplayio_edid_info)

-  
Retrieve EDID data from a driver.
-    

-    
struct wsdisplayio_edid_info {
-	uint32_t buffer_size;
-	uint32_t data_size;
-	void *edid_data;
-};

-    

-    The caller is responsible for allocating a buffer of at least 128 bytes (the
-      minimum size of an EDID block) and set data_size to its size. If the EDID
-      block is bigger the call will fail with EAGAIN and
-      the driver will set data_size to the required buffer size. Otherwise the
-      EDID block will be written into the buffer pointed at by edid_data and
-      data_size will be set to the number of bytes written.

-  

-    (int)

-  
Set the wscons_event protocol version. The default is 0 for binary
-      compatibility. The latest version is always available as
-      WSDISPLAYIO_EVENT_VERSION, and is currently 1. All
-      new code should use a call similar to the below to ensure the correct
-      version is returned.
-    

-    
int ver = WSDISPLAYIO_EVENT_VERSION;
-if (ioctl(fd, WSDISPLAYIO_SETVERSION, &ver) == -1)
-    err(EXIT_FAILURE, "cannot set version");

-    

-  

-

-

-

-

-

-

-  
/dev/ttyE*

-  
Terminal devices (per screen).

-  
/dev/ttyEcfg

-  
Control device.

-  
/dev/ttyEstat

-  
Status device.
-    

-  

-  
/usr/include/dev/wscons/wsconsio.h

-  
 

-

-

-

-

-
ioctl(2), pcdisplay(4),
-    tty(4), vga(4),
-    wscons(4), wsconscfg(8),
-    wsconsctl(8), wsfontload(8),
-    wsdisplay(9)

-

-

-

-
The wsdisplay code currently limits the
-    number of screens on one display to 8.

-
The terms “wscons” and “wsdisplay” are
-    not cleanly distinguished in the code and in manual pages.

-
“Non-emulating” display devices are not tested.

-

-

-
-  
-    
-    
-  
-
May 16, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/wsfont.4 4.html b/static/netbsd/man4/wsfont.4 4.html
deleted file mode 100644
index 0ea8d1ca..00000000
--- a/static/netbsd/man4/wsfont.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSFONT(4)Device Drivers ManualWSFONT(4)

-

-

-

-
wsfont — dynamic
-    font loading support

-

-

-

-
pseudo-device wsfont

-

-

-

-
The wsfont pseudo device allows display
-    fonts for the wscons subsystem to be loaded dynamically into the kernel. The
-    fonts are loaded dynamically using the wsfontload(8)
-    utility.

-

-

-

-
wscons(4), wsdisplay(4),
-    wsconsctl(8), wsfontload(8),
-    wsfont(9)

-

-

-

-
Fonts cannot be unloaded from the kernel.

-

-

-
-  
-    
-    
-  
-
April 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man4/wskbd.4 4.html b/static/netbsd/man4/wskbd.4 4.html
deleted file mode 100644
index 92125fce..00000000
--- a/static/netbsd/man4/wskbd.4 4.html	
+++ /dev/null
@@ -1,354 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSKBD(4)Device Drivers ManualWSKBD(4)

-

-

-

-
wskbd — generic
-    keyboard support in wscons

-

-

-

-
wskbd* at pckbd? console ? mux 1 (standard
-    PC keyboard)
-  

-  wskbd* at ukbd? console ? mux 1 (USB keyboard)
-  

-  wskbd* at lkkbd? console ? mux 1 (DEC LK200/400 serial
-    keyboard)
-  

-  wskbd0 at akbd? console ? mux 1 (Apple ADB keyboard)
-  

-  wskbd0 at nextkbd? console ? mux 1 (NeXT keyboard)
-  

-  wskbd* at vrkiu? console ? mux 1 (NEC VR4000 series
-    HPC keyboard)
-  

-  wskbd* at skbd? console ? mux 1 (keyboard of misc
-    hpcmips handheld devices)
-  

-  wskbd* at btkbd? console ? mux 1 (Bluetooth
-  keyboard)

-

-  

-  #include
-    <dev/wscons/wsconsio.h>
-  

-  #include
-    <dev/wscons/wsksymdef.h>

-

-

-

-
The wskbd driver handles common tasks for
-    keyboards within the wscons(4) framework. It is attached
-    to the hardware specific keyboard drivers and provides their connection to
-    “wsdisplay” devices and a character device interface.

-
The common keyboard support consists of:

-
    
-  
  • Mapping from keycodes (defined by the specific keyboard driver) to keysyms
-      (hardware independent, defined in
-      <dev/wscons/wsksymdef.h>).
    • 
-  
  • Handling of “compose” sequences. Characters commonly not
-      present as separate key on keyboards can be generated after either a
-      special “compose” key is pressed or a “dead
-      accent” character is used.
    • 
-  
  • Certain translations, like turning an ALT modifier into an ESC
-    prefix.
    • 
-  
  • Automatic key repetition (“typematic”).
    • 
-  
  • Parameter handling for “keyboard bells”.
    • 
-  
  • Generation of “keyboard events” for use by X servers.
    • 
-

-
The wskbd driver provides a number of
-    ioctl functions to control key maps and other parameters. These functions
-    are accessible though the associated wsdisplay(4) device
-    as well. A complete list is in
-    <dev/wscons/wsconsio.h>. The
-    wsconsctl(8) utility allows to access key maps and other
-    variables.

-
The console locator in the configuration
-    line refers to the device's use as input part of the operating system
-    console. A device specification containing a positive value here will only
-    match if the device is in use as system console. (The console device
-    selection in early system startup is not influenced.) This way, the console
-    device can be connected to a known wskbd device instance.

-

-

-
The following encodings are supported. Device drivers for legacy
-    keyboard interfaces may only support a subset of these. However, generally,
-    all encodings are supported by pckbd(4) and
-    ukbd(4).

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
User-defined
English/US keyboard mapping (default)
English/UK keyboard mapping
Belgian
Brazilian with “dead accents”
Canadian French
Czech (QWERTY)
Danish with “dead accents”
Dutch
Estonian with “dead accents”
Finnish
French
German QWERTZ with “dead accents”
German Neo 2 layout
Greek
Hungarian
Icelandic with “dead accents”
Italian
Japanese
Latin American Spanish
Norwegian with “dead accents”
Polish
Portuguese
Russian
Spanish
Swedish with “dead accents”
Swiss French
Swiss German
Turkish (QWERTY) with “dead accents”
Ukrainian
English/US mapping for DEC LK400-style keyboards with PC keyboard
-      interface (e.g., LK461)
English/US keyboard with “Dvorak” layout
English/US keyboard with “Colemak” layout

-
The “.nodead” suffix
-    (KB_NODEAD flag) can be applied to layouts with
-    “dead accents” to switch them off.

-
The KB_US, KB_UK,
-    KB_FR, KB_JP and
-    KB_US|KB_DVORAK mappings can be modified to swap the
-    left ⟨Ctrl⟩ and the ⟨CapsLock⟩ keys by the
-    KB_SWAPCTRLCAPS variant bit or the
-    “.swapctrlcaps” suffix.

-
The “.metaesc” suffix
-    (KB_METAESC flag) option can be applied to any
-    layout. If set, keys pressed together with the ALT modifier are prefixed by
-    an ESC character. (Standard behaviour is to add 128 to the ASCII value.)

-

-

-

-
The following ioctl(2) calls are provided by the
-    wskbd driver or by devices which use it. Their
-    definitions are found in
-    <dev/wscons/wsconsio.h>.

-

-  

-  
Get the keyboard type.

-  

-  
Get the keyboard mode, 0 means translated through keyboard map, 1 means
-      raw.

-  

-  
Set the keyboard mode.

-  
,
-    WSKBDIO_SETBELL,
-    WSKBDIO_GETBELL,
-    WSKBDIO_SETDEFAULTBELL,
-    WSKBDIO_GETDEFAULTBELL (struct
-    wskbd_bell_data)

-  
Get and set keyboard bell settings.

-  
,
-    WSKBDIO_GETKEYREPEAT,
-    WSKBDIO_SETDEFAULTKEYREPEAT,
-    WSKBDIO_GETDEFAULTKEYREPEAT (struct
-    wskbd_keyrepeat_data)

-  
Get and set keyboard autorepeat settings.

-  
,
-    WSKBDIO_GETLEDS (int)

-  
Get and set keyboard LED settings.

-  
,
-    WSKBDIO_SETMAP (struct
-    wskbd_map_data)

-  
Get and set keyboard keymapping settings.

-  
,
-    WSKBDIO_SETENCODING
-    (kbd_t)

-  
Get and set keyboard encoding settings.

-  
,
-    WSKBDIO_SETKEYCLICK (int)

-  
Get and set keyboard keyclick settings.

-  

-    (int)

-  
Set the wscons_event protocol version. The default
-      is 0 for binary compatibility. The latest version is always available as
-      WSKBDIO_EVENT_VERSION, and is currently 1. All new
-      code should use a call similar to the below to ensure the correct version
-      is returned.
-    

-    
int ver = WSKBDIO_EVENT_VERSION;
-if (ioctl(fd, WSKBDIO_SETVERSION, &ver) == -1)
-	err(EXIT_FAILURE, "cannot set version");

-    

-  

-

-

-

-

-

-
    
-  
  • /dev/wskbd*
    • 
-

-

-

-

-
btkbd(4), pckbd(4),
-    ukbd(4), wscons(4),
-    wsmux(4), wsconsctl(8),
-    wskbd(9)

-

-

-

-
The list of builtin mappings doesn't follow any logic. It grew as
-    people submitted what they needed.

-

-

-
-  
-    
-    
-  
-
September 18, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/wsmouse.4 4.html b/static/netbsd/man4/wsmouse.4 4.html
deleted file mode 100644
index 6f020a0d..00000000
--- a/static/netbsd/man4/wsmouse.4 4.html	
+++ /dev/null
@@ -1,146 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSMOUSE(4)Device Drivers ManualWSMOUSE(4)

-

-

-

-
wsmouse — generic
-    mouse support in wscons

-

-

-

-
wsmouse* at pms? mux 0 (PS/2 mouse,
-    including ``IntelliMouse''-compatible wheel mice)
-  

-  wsmouse* at ums? mux 0 (USB mouse)
-  

-  wsmouse* at uts? mux 0 (USB touchscreen)
-  

-  wsmouse* at lms? mux 0 (Logitech bus mouse, i386 only)
-  

-  wsmouse* at mms? mux 0 (Microsoft InPort mouse, i386
-    only)
-  

-  wsmouse0 at ams? mux 0 (Apple ADB mouse)
-  

-  wsmouse*	at btms? mux 0 (Bluetooth mouse)
-  

-  wsmouse* at lkms? mux 0 (DEC VSXXX serial mice)

-

-

-

-
The wsmouse driver is an abstraction layer
-    for mice within the wscons(4) framework. It is attached to
-    the hardware specific mouse drivers and provides a character device
-    interface which returns struct wscons_event via
-    read(2). For use with X servers, “mouse
-    events” can be generated.

-
The wsconsctl(8) utility gives access to several
-    configurable details that affect this driver.

-

-

-
The following ioctl(2) calls are provided by the
-    wsmouse driver or by devices which use it. Their
-    definitions are found in dev/wscons/wsconsio.h.

-

-  

-    (struct wsmouse_parameters)

-  
 

-  

-    (struct wsmouse_parameters)

-  
Obtain and set various mouse parameters as a key/value set. Currently
-      these primarily relate to touchpads. The structure struct
-      wsmouse_parameters is defined as follows:
-    

-    
struct wsmouse_param {
-	enum wsmousecfg key;
-	int value;
-};
-
-struct wsmouse_parameters {
-	struct wsmouse_param *params;
-	unsigned int nparams;
-};

-    

-    
The number of parameters to read or write must be specified in
-        nparams. For each parameter, when
-        WSMOUSEIO_GETPARAMS is used, a key must be
-        specified. When WSMOUSEIO_SETPARAMS is used, a
-        key and a value must be specified. A single ioctl may retrieve up to
-        WSMOUSECFG_MAX
-      nparams.

-  

-  

-    (struct wsmouse_repeat)

-  
Retrieve the current automatic button repeating configuration. The
-      structure returned is as follows:
-    

-    
struct wsmouse_repeat {
-	unsigned long   wr_buttons;
-	unsigned int    wr_delay_first;
-	unsigned int    wr_delay_decrement;
-	unsigned int    wr_delay_minimum;
-};

-    

-    
The wr_buttons field is a bit mask that
-        specifies which buttons send press and release events periodically while
-        they are physically held down. The least significant bit corresponds to
-        button 0.

-    
The other three fields describe the frequency upon which these
-        automatic events are sent. wr_delay_first
-        specifies the milliseconds before the first repeated event is sent.
-        wr_delay_decrement is used to calculate the delay
-        between the most recently generated event and the forthcoming one: the
-        previous delay is taken and it is decreased by the value given in this
-        variable. wr_delay_minimum specifies the minimum
-        delay, in milliseconds, between two consecutive events.

-  

-  

-    (struct wsmouse_repeat)

-  
Set the automatic button repeating configuration. See
-      WSMOUSEIO_GETREPEAT above for more details.

-  

-    (int)

-  
Set the wscons_event protocol version. The default is 0 for binary
-      compatibility. The latest version is always available as
-      WSMOUSE_EVENT_VERSION, and is currently 1. All new
-      code should use a call similar to the below to ensure the correct version
-      is returned.
-    

-    
int ver = WSMOUSE_EVENT_VERSION;
-if (ioctl(fd, WSMOUSEIO_SETVERSION, &ver) == -1)
-    err(EXIT_FAILURE, "cannot set version");

-    

-  

-

-

-

-

-

-
    
-  
  • /dev/wsmouse*
    • 
-  
  • /usr/include/dev/wscons/wsconsio.h.
    • 
-

-

-

-

-
btms(4), dreamcast/mms(4),
-    i386/lms(4), i386/mms(4),
-    pms(4), uep(4),
-    ums(4), uts(4),
-    wscons(4), wsmux(4),
-    moused(8), wsconsctl(8),
-    wsmoused(8), wsmouse(9)

-

-

-
-  
-    
-    
-  
-
September 25, 2021NetBSD 10.1

diff --git a/static/netbsd/man4/wsmux.4 4.html b/static/netbsd/man4/wsmux.4 4.html
deleted file mode 100644
index 73f41a91..00000000
--- a/static/netbsd/man4/wsmux.4 4.html	
+++ /dev/null
@@ -1,90 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSMUX(4)Device Drivers ManualWSMUX(4)

-

-

-

-
wsmux — console
-    keyboard/mouse multiplexor for wscons

-

-

-

-
wskbd* at ... mux 1
-  

-  wsbell* at ... mux 1
-  

-  wsmouse* at ... mux 0

-

-  

-  pseudo-device wsmux

-

-

-

-
The wsmux is a pseudo-device driver that
-    allows several wscons(4) input devices to have their
-    events multiplexed into one stream.

-
The typical usage for this device is to have two multiplexors, one
-    for mouse events and one for keyboard and bell events. All
-    wsmouse(4) devices should direct their events to the mouse
-    mux (normally 0) and all keyboard devices, except the console, should direct
-    their events to the keyboard mux (normally 1). A device will send its events
-    to the mux indicated by the mux locator. If none is
-    given the device will not use a multiplexor. The keyboard multiplexor should
-    be connected to the display, using the wsconscfg(8)
-    command. It will then receive all keystrokes from all keyboards and,
-    furthermore, keyboards can be dynamically attached and detached without
-    further user interaction. Additionally, bell events generated for the
-    display will be directed to all attached wsbell(4)
-    devices. In a similar way, the window system will open the mouse multiplexor
-    and receive all mouse events; mice can also be dynamically attached and
-    detached.

-
If a wskbd(4), wsbell(4), or
-    wsmouse(4) device is opened despite having a mux it will
-    be detached from the mux.

-
It is also possible to inject events into a multiplexor from a
-    user program.

-

-

-

-
For each mux device,
-    /dev/wsmuxN there is a control
-    device /dev/wsmuxctlN. The
-    control device has a minor number 128 greater than the regular mux device.
-    It can be used to control the mux even when it is open, e.g., by
-    wsmuxctl(8).

-

-

-  
/dev/wsmouse

-  
a.k.a. /dev/wsmux0

-  
/dev/wskbd

-  
a.k.a. /dev/wsmux1

-  
/usr/include/dev/wscons/wsconsio.h

-  
 

-

-

-

-

-
wsbell(4), wscons(4),
-    wsdisplay(4), wskbd(4),
-    wsmouse(4), moused(8),
-    wsconscfg(8), wsconsctl(8),
-    wsmoused(8), wsmuxctl(8)

-

-

-

-
If more than one type of keyboard is used,
-    WSKBDIO_GTYPE will return the type of the first
-    keyboard.

-

-

-
-  
-    
-    
-  
-
August 13, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/wss.4 4.html b/static/netbsd/man4/wss.4 4.html
deleted file mode 100644
index 3ec1095e..00000000
--- a/static/netbsd/man4/wss.4 4.html	
+++ /dev/null
@@ -1,61 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSS(4)Device Drivers ManualWSS(4)

-

-

-

-
wss — Windows
-    Sound System hardware audio driver

-

-

-

-
wss0 at isa? port 0x530 irq 10 drq 0 drq2
-    1
-  

-  wss0 at isa? port 0x530 irq 10 drq 0 flags 1
-  

-  wss* at acpi?
-  

-  wss* at isapnp?
-  

-  wss* at pnpbios? index ?
-  

-  audio* at audiobus?
-  

-  opl* at wss?

-

-

-

-
The wss driver supports Microsoft's
-    Windows Sound System, the MAD16 chip based hardware, and their clones.

-
The base I/O port is set by a jumper on the board; valid choices
-    are 0x530, 0x604, 0xE80, or 0xF40. Both IRQ and DMA channels are software
-    programmable. The IRQ may be set to 7, 9, 10, or 11, and the DMA channel may
-    be set to 0, 1, or 3.

-
The device flags must have bit 0 (value 1)
-    set to enable the MAD16 support. This is to avoid potential conflicts with
-    other devices when probing the MAD16 because it requires use of extra I/O
-    ports not in the base port range. Chips needing this flag include the OPTi
-    82C928, 82C929, 82C831, and the OAK OTI-601D. Setting bit 1 (value 2) in
-    flags disables the joystick port on MAD16
-  hardware.

-

-

-

-
acpi(4), audio(4),
-    isa(4), isapnp(4),
-    joy(4), opl(4),
-    i386/pnpbios(4)

-

-

-
-  
-    
-    
-  
-
August 25, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/wt.4 4.html b/static/netbsd/man4/wt.4 4.html
deleted file mode 100644
index 813d61ae..00000000
--- a/static/netbsd/man4/wt.4 4.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
WT(4)Device Drivers ManualWT(4)

-

-

-

-
wt —
-    Archive/Wangtek cartridge tape driver

-

-

-

-
wt0 at isa? port 0x300 irq 5 drq 1

-

-

-

-
The wt driver provides support for the
-    following Archive and Wangtek boards:

-

-

-

-  
QIC-02

-  
 

-  
QIC-36

-  
 

-

-

-
Raw devices are indicated by an “r” preceding the
-    device name. The driver can be opened with either rewind on close
-    (/dev/rst*) or no rewind on close
-    (/dev/nrst*) options.

-
The tape format is specified by adding 8 or 16 to the device
-    number. For example, for the wt0 device's raw rewind on close device nodes,
-    /dev/rwt0 is the 150 MByte density device,
-    /dev/rwt8 is the 120 MByte density device, and
-    /dev/rwt16 is the 60 MByte device.

-

-

-

-
intro(4)

-

-

-

-
The wt driver conflicts unpleasantly with
-    the we driver (SMC Ethernet adapters) at the same
-    I/O address. The probe reprograms their EEPROMs.

-

-

-
-  
-    
-    
-  
-
July 10, 1995NetBSD 10.1

diff --git a/static/netbsd/man4/wwanc.4 4.html b/static/netbsd/man4/wwanc.4 4.html
deleted file mode 100644
index bcec3c16..00000000
--- a/static/netbsd/man4/wwanc.4 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
WWANC(4)Device Drivers ManualWWANC(4)

-

-

-

-
wwanc — Intel XMM
-    7360 LTE modem

-

-

-

-
wwanc* at pci? dev ? function ?
-  

-  wwan* at wwanc?

-

-

-

-
The wwanc driver provides support for
-    Fibocom L850-GL / Intel XMM7360.

-
The device establishes connections via cellular networks such as
-    GPRS, UMTS, and LTE. They appear as a regular point-to-point network
-    interface, transporting raw IP frames.

-
The SIM card needs to be unlocked, the
-    wwanc driver provides no means to provide a password
-    for the SIM.

-

-

-

-
The following devices should work:

-

-

-

-  
Intel XMM7360

-  
 

-

-

-

-

-

-
intro(4), netintro(4),
-    pci(4), ifconfig.if(5),
-    ifconfig(8), MAKEDEV(8),
-    Linux driver
-    repository

-

-

-

-
The wwanc device driver first appeared
-    NetBSD 10.0.

-

-

-

-
Development of the Linux and OpenBSD
-    driver was supported by genua GmbH. The wwanc driver
-    was written by James Wah
-    <james@laird-wah.net>
-    for Linux, it was ported to OpenBSD and
-    NetBSD by Jaromir Dolecek
-    <jdolecek@NetBSD.org>
-    for Moritz Systems Technology Company Sp. z o.o.

-

-

-

-
The wwanc driver IPv6 support is
-  untested.

-
Network initialization requires a Python script published in the
-    Linux driver repository, available as package
-    pkgsrc/net/py-xmm7360. The script requires the
-    management device nodes to be created via:

-

-
cd /dev && ./MAKEDEV xmm0

-

-

-

-
-  
-    
-    
-  
-
July 27, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/xbd.4 4.html b/static/netbsd/man4/xbd.4 4.html
deleted file mode 100644
index f0f78e3d..00000000
--- a/static/netbsd/man4/xbd.4 4.html	
+++ /dev/null
@@ -1,73 +0,0 @@
-
-  
-    
-    
-    
-  
-
XBD(4)Device Drivers Manual (xen)XBD(4)

-

-

-

-
xbd — Xen frontend
-    paravirtualized block device interface

-

-

-

-
xbd* at xenbus?

-

-

-

-
The xbd interface forms the frontend part
-    of the paravirtualized drivers used by Xen guest domains to have a block
-    device interface.

-
From a guest point of view, xbd is similar
-    to a hard disk, and can be treated in the very same way regarding
-    partitioning, file systems creation and usage, and mounting. By default, a
-    NetBSD guest domain will assume that
-    “xbd0a” serves as the root file system.

-
When the host is NetBSD, the
-    xbd interface is backed by a
-    xbdback(4) interface. In the XenStore,
-    xbd and xbdback are
-    identified by “vbd” (virtual block device) entries.

-

-

-

-

-  
xbd%d: using event channel %d

-  
Specifies the event channel used by this xbd
-      interface.

-  
xbd%d: %s MB, %d bytes/sect x %u sectors

-  
Gives the total size of the xbd block device, its
-      sector size and total number of sectors.

-  
xbd%d: WARNING: cache flush not supported by backend

-  
The backend driver associated with this xbd device
-      does not support cache flushing operation. This can be problematic for
-      file system operations that require cache sync to avoid data loss or
-      corruption.

-

-

-

-

-
xbdback(4), xenbus(4),
-    dkctl(8)

-

-

-

-
The xbd driver first appeared in
-    NetBSD 3.0.

-

-

-

-
The xbd driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 8, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/xbdback.4 4.html b/static/netbsd/man4/xbdback.4 4.html
deleted file mode 100644
index c8b05304..00000000
--- a/static/netbsd/man4/xbdback.4 4.html	
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    
-    
-    
-  
-
XBDBACK(4)Device Drivers Manual (xen)XBDBACK(4)

-

-

-

-
xbdback — Xen
-    backend paravirtualized block device interface

-

-

-

-
pseudo-device xbdback

-

-

-

-
The xbdback interface forms the backend
-    part of the paravirtualized drivers used by Xen domains to offer a block
-    device interface, similar to a hard disk. xbdback
-    interfaces are backed either by a physical device directly, or an image file
-    mounted through vnd(4).

-
All xbdback interfaces follow the
-    “xbdbackXiY” naming convention, where ‘X’
-    represents the guest domain identifier, and ‘Y’ an arbitrary
-    identifier. This identifier is usually associated to the device node as seen
-    by the guest using major(3) and minor(3)
-    numbers. For example, identifier “769” (0x301) means major
-     and minor
-    , identified as
-    “hda1” under Linux convention. For
-    NetBSD, the guest device name specified in the guest
-    configuration file does not matter, and can be chosen arbitrarily.

-
A xbdback interface will appear as a
-    xbd(4) block device inside a
-    NetBSD guest domain. In the XenStore,
-    xbd and xbdback are
-    identified by “vbd” (virtual block device) entries.

-

-

-

-

-  
xbd backend: attach device %s (size %d) for domain %d

-  
Gives the device used as xbdback interface for the
-      given guest domain, and its size, in bytes.

-  
xbd backend 0x%x for domain %d using event channel %d, protocol %s

-  
Gives the backend identifier, guest domain ID, event channel ID, and
-      protocol used for block level communication.

-  
xbdback %s: can't VOP_OPEN device 0x%x: %d

-  
When this message appears in the system message buffer with error 16
-      (EBUSY), the device is likely to be already
-      mounted. It must be unmounted first, as the system will refuse to open it
-      a second time.

-

-

-

-

-
vnd(4), xbd(4),
-    xenbus(4)

-

-

-

-
The xbdback driver first appeared in
-    NetBSD 4.0.

-

-

-

-
The xbdback driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
June 7, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/xbox.4 4.html b/static/netbsd/man4/xbox.4 4.html
deleted file mode 100644
index eae6891b..00000000
--- a/static/netbsd/man4/xbox.4 4.html	
+++ /dev/null
@@ -1,42 +0,0 @@
-
-  
-    
-    
-    
-  
-
XBOX(4)Device Drivers ManualXBOX(4)

-

-

-

-
xbox — SPARC SBus
-    Expansion Subsystem

-

-

-

-
xbox* at sbus? slot ? offset ?
-  

-  sbus* at xbox?

-

-

-

-
The xbox driver provides support for the
-    Sun SBus Expansion Subsystem. This device consists of an SBus card and a
-    chassis which has three additional SBus slots.

-

-

-

-
intro(4), sbus(4)

-

-

-

-
Support for the xbox first appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
March 31, 2004NetBSD 10.1

diff --git a/static/netbsd/man4/xenbus.4 4.html b/static/netbsd/man4/xenbus.4 4.html
deleted file mode 100644
index f925d508..00000000
--- a/static/netbsd/man4/xenbus.4 4.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
XENBUS(4)Device Drivers Manual (xen)XENBUS(4)

-

-

-

-
xenbus — Xen bus
-    abstraction for paravirtualized drivers

-

-

-

-
xenbus* at hypervisor?

-

-

-

-
The xenbus interface offers an abstraction
-    layer used for communications between domains.
-    xenbus is mainly used by split paravirtualized
-    drivers, so backend and frontend devices can exchange configuration
-    information, properties, and statistics.

-
xenbus is not used for data transfer
-    (network frames, blocks, PCI commands, ...). This functionality is
-    implemented by each paravirtualized driver independently, typically via
-    shared memory pages and an event channel that serves as a virtual interrupt,
-    for signaling.

-
The xenbus abstraction offers guests the
-    possibility to read and write information directly from and to XenStore, a
-    centralized database accessible to all domains. For this reason, it also has
-    an event channel associated to it, so that domains can post messages to the
-    XenStore facility.

-

-

-

-

-  
xenbus0: using event channel %d

-  
The event channel associated to the xenbus
-      interface, for communication with the XenStore database.

-

-

-

-

-
pciback(4), xbd(4),
-    xbdback(4), xennet(4),
-    xpci(4), xvif(4)

-

-

-

-
The xenbus driver first appeared in
-    NetBSD 3.0.

-

-

-

-
The xenbus driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 8, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/xennet.4 4.html b/static/netbsd/man4/xennet.4 4.html
deleted file mode 100644
index bf94c50d..00000000
--- a/static/netbsd/man4/xennet.4 4.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
XENNET(4)Device Drivers Manual (xen)XENNET(4)

-

-

-

-
xennet — Xen
-    frontend paravirtualized network interface

-

-

-

-
xennet* at xenbus?

-

-

-

-
The xennet interface forms the frontend
-    part of the paravirtualized drivers used by Xen guest domains to have
-    network connectivity.

-
When the host domain is NetBSD, the
-    endpoint of the xennet interface is a
-    xvif(4) interface. In the XenStore,
-    xvif and xennet are
-    identified by “vif” (virtual interface) entries.

-
Conceptually, frontends and backends drivers are similar to two
-    Ethernet cards connected via a crossover cable.

-
xennet interfaces can pass VLAN tagged
-    packets.

-
The minimum number of RX buffers can be
-    controlled with the hw.xennet.xnfrx_lowat using the
-    sysctl(8) utility. The default is to reserve no minumum
-    number of cached RX buffers. A minimum number of reserved RX buffers can
-    also be compiled into the kernel config using the
-    
-    option.

-

-

-

-

-  
xennet%d: can't read mac address, err %d

-  
The MAC address for this interface could not be read from XenStore.

-  
xennet%d: %s is not a valid mac address

-  
The MAC address specified in the configuration file of the newly created
-      guest domain is invalid.

-  
xennet%d: using event channel %d

-  
The Xen event channel (virtual interrupt) ID associated to this
-      xennet.

-  
xennet%d: using RX copy mode

-  
The xennet and its associated endpoint use copy
-      mode for communication: packets are copied from one domain's memory to
-      another.

-

-

-

-

-
bridge(4), ifmedia(4),
-    options(4), xenbus(4),
-    xvif(4), ifconfig(8)

-

-

-

-
The xennet driver first appeared in
-    NetBSD 3.0.

-

-

-

-
The xennet driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>
-    and Christian Limpach
-    <chris@pin.lu>.

-

-

-
-  
-    
-    
-  
-
August 27, 2025NetBSD 10.1

diff --git a/static/netbsd/man4/xge.4 4.html b/static/netbsd/man4/xge.4 4.html
deleted file mode 100644
index 69068910..00000000
--- a/static/netbsd/man4/xge.4 4.html	
+++ /dev/null
@@ -1,82 +0,0 @@
-
-  
-    
-    
-    
-  
-
XGE(4)Device Drivers ManualXGE(4)

-

-

-

-
xge — Neterion
-    Xframe-I Ten Gigabit Ethernet driver

-

-

-

-
xge* at pci? dev ? function ?

-

-

-

-
The xge device driver supports the
-    Neterion Xframe-I LR Ethernet adapter, which uses a single mode fiber
-    (1310nm) interface.

-
The Xframe supports IPv4/TCP/UDP checksumming in hardware, as well
-    as TCP Segmentation Offloading (TSO) and hardware VLAN handling. The driver
-    currently does not support the hardware VLAN feature. See
-    ifconfig(8) for information on how to enable TSO and
-    hardware checksum calculation.

-

-

-

-

-  
xge%s: failed configuring endian, %llx != %llx!

-  
The Xframe could not be turned into the correct endian operation. This is
-      most likely a hardware error.

-  
xge%d: failed allocating txmem.

-  

-  
xge%d: failed allocating rxmem.

-  
The computer has run out of kernel memory.

-  
xge%d: adapter not quiescent, aborting

-  

-  
xge%d: ADAPTER_STATUS missing bits %s

-  
The Xframe could not be turned into a usable state. Most likely an Xframe
-      hardware error.

-  
xge%d: cannot create TX DMA maps

-  

-  
xge%d: cannot create RX DMA maps

-  
This error is either a kernel error or that the kernel has run out of
-      available memory.

-  
xge%d: bad compiler struct alignment, %d != %d

-  
The compiler did not align the structure correctly. This is a compiler
-      problem.

-

-

-

-

-
arp(4), ifmedia(4),
-    netintro(4), pci(4),
-    ifconfig(8)

-

-

-

-
The xge driver first appeared in
-    NetBSD 3.0.

-

-

-

-
The xge driver was written by
-    Anders Magnusson
-    <ragge@ludd.luth.se>.

-

-

-

-
There should be an XGMII framework for the driver to use.

-

-

-
-  
-    
-    
-  
-
September 9, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/xhci.4 4.html b/static/netbsd/man4/xhci.4 4.html
deleted file mode 100644
index 1ffa903b..00000000
--- a/static/netbsd/man4/xhci.4 4.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
XHCI(4)Device Drivers ManualXHCI(4)

-

-

-

-
xhci — USB
-    eXtensible Host Controller driver

-

-

-

-
xhci* at pci? dev ? function ?
-  

-  usb* at xhci?

-

-

-

-
The xhci driver provides support for the
-    USB Extensible Host Controller Interface, which is used by USB 1.x, 2.0, and
-    3.x controllers.

-

-

-

-
ehci(4), ohci(4),
-    pci(4), uhci(4),
-    usb(4)

-

-

-

-
The xhci driver appeared in
-    NetBSD 7.0.

-

-

-

-
xhci driver is mostly working, but still
-    in development.

-

-

-
-  
-    
-    
-  
-
September 30, 2018NetBSD 10.1

diff --git a/static/netbsd/man4/xi.4 4.html b/static/netbsd/man4/xi.4 4.html
deleted file mode 100644
index 9768c143..00000000
--- a/static/netbsd/man4/xi.4 4.html	
+++ /dev/null
@@ -1,77 +0,0 @@
-
-  
-    
-    
-    
-  
-
XI(4)Device Drivers ManualXI(4)

-

-

-

-
xi — Xircom
-    CreditCard Ethernet device driver

-

-

-

-
xi* at xirc?

-
Configuration of PHYs may also be necessary. See
-    mii(4).

-

-

-

-
The xi driver provides support for the
-    Xircom CreditCard family of PCMCIA Ethernet adapters. Supported cards
-    include:

-

-
    
-  
  • Xircom CreditCard Ethernet II
    • 
-  
  • Xircom CreditCard 10/100 Ethernet
    • 
-  
  • Xircom RealPort 10/100 Ethernet + Modem (Ethernet function only)
    • 
-  
  • Intel EtherExpress Pro/100
    • 
-  
  • Compaq Netelligent 10/100
    • 
-

-
Cards which should work, but have not been confirmed include:

-

-
    
-  
  • Xircom RealPort Ethernet
    • 
-  
  • Xircom RealPort 10/100 Ethernet
    • 
-

-
Some Xircom Ethernet products are supported by the
-    tlp(4) driver.

-

-

-

-
Media selection is done using ifconfig(8) using
-    the standard ifmedia(4) mechanism. Refer to those manual
-    pages for more information.

-

-

-

-
ifmedia(4), mii(4),
-    netintro(4), pcmcia(4),
-    tlp(4), xirc(4),
-    ifconfig(8)

-

-

-

-
The xi device driver appeared in
-    NetBSD 1.5.

-

-

-

-
The driver suffers from poor performance. Even with the 10/100
-    cards, do not expect more than ~450KB/s. Some 10/100 cards may not
-    autonegotiate reliably and require manual media selection.

-
The Xircom multifunction cards which contain both Ethernet and
-    modem interfaces are known to have problems. This is due to the card not
-    reporting itself correctly as a multifunction card.

-

-

-
-  
-    
-    
-  
-
June 1, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/xirc.4 4.html b/static/netbsd/man4/xirc.4 4.html
deleted file mode 100644
index 19bc23c7..00000000
--- a/static/netbsd/man4/xirc.4 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
XIRC(4)Device Drivers ManualXIRC(4)

-

-

-

-
xirc — Xircom
-    Ethernet/modem card driver

-

-

-

-
xirc* at pcmcia? function ?
-  

-  com* at xirc?
-  

-  xi* at xirc?

-

-

-

-
The xirc device driver provides support
-    for the Xircom combined Ethernet and modem cards.

-

-

-

-
com(4), pcmcia(4),
-    xi(4)

-

-

-

-
The xirc driver appeared in
-    NetBSD 3.0.

-

-

-
-  
-    
-    
-  
-
June 1, 2007NetBSD 10.1

diff --git a/static/netbsd/man4/xpci.4 4.html b/static/netbsd/man4/xpci.4 4.html
deleted file mode 100644
index 43a8f403..00000000
--- a/static/netbsd/man4/xpci.4 4.html	
+++ /dev/null
@@ -1,64 +0,0 @@
-
-  
-    
-    
-    
-  
-
XPCI(4)Device Drivers Manual (xen)XPCI(4)

-

-

-

-
xpci — Xen
-    frontend paravirtualized PCI pass-through driver

-

-

-

-
xpci* at xenbus?
-  

-  pci* at xpci?

-

-

-

-
The xpci driver is the frontend part of
-    the PCI pass-through functionality that can be used by Xen guest domains to
-    communicate with PCI devices.

-
From a guest point of view, xpci is
-    similar to a pci(4) bus, except that the guest talks with
-    the PCI backend driver instead of the real physical device directly.

-
When the host domain is NetBSD, the
-    xpci driver is backed by a
-    pciback(4) driver within the dom0.

-

-

-

-
pci(4), pciback(4),
-    xenbus(4)

-

-

-

-
The xpci driver first appeared in
-    NetBSD 5.1.

-

-

-

-
The xpci driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>.

-

-

-

-
As PCI passthrough offers the possibility for guest domains to
-    send arbitrary PCI commands to a physical device, this has direct impact on
-    the overall stability and security of the system. For example, in case of
-    erroneous or malicious commands, the device could overwrite physical memory
-    portions, via DMA.

-

-

-
-  
-    
-    
-  
-
January 8, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/xvif.4 4.html b/static/netbsd/man4/xvif.4 4.html
deleted file mode 100644
index 91519d9a..00000000
--- a/static/netbsd/man4/xvif.4 4.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
XVIF(4)Device Drivers Manual (xen)XVIF(4)

-

-

-

-
xvif — Xen backend
-    paravirtualized network interface

-

-

-

-
pseudo-device xvif

-

-

-

-
The xvif interface forms the backend part
-    of the paravirtualized drivers used by Xen domains to offer network
-    connectivity.

-
When the guest domain is NetBSD, the
-    endpoint of the xvif interface is a
-    xennet(4) interface. In the XenStore,
-    xvif and xennet are
-    identified by “vif” (virtual interface) entries.

-
All xvif interfaces follow the
-    “xvifXiY” naming convention, where ‘X’
-    represents the guest domain identifier, and ‘Y’ an arbitrary
-    identifier; most of the time, it is the frontend interface identifier, e.g.
-    “xennetY”.

-
For convenience, the MAC address of an
-    xvif interface is chosen by incrementing the third
-    byte of the MAC address of the frontend device.

-
Conceptually, frontends and backends drivers are similar to two
-    Ethernet cards connected via a crossover cable.

-

-

-

-

-  
xvif%di%d: can't read %s/mac: %d

-  
The MAC address for this interface could not be read from XenStore.

-  
xvif%di%d: %s is not a valid mac address

-  
The MAC address specified in the configuration file of the newly created
-      guest domain is invalid.

-  
xvif%di%d: Ethernet address %s

-  
MAC address of the xvif interface.

-

-

-

-

-
ifmedia(4), xennet(4),
-    ifconfig(8)

-

-

-

-
The xvif driver first appeared in
-    NetBSD 4.0.

-

-

-

-
The xvif driver was written by
-    Manuel Bouyer
-    <bouyer@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 7, 2011NetBSD 10.1

diff --git a/static/netbsd/man4/yds.4 4.html b/static/netbsd/man4/yds.4 4.html
deleted file mode 100644
index b5ddbc67..00000000
--- a/static/netbsd/man4/yds.4 4.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
YDS(4)Device Drivers ManualYDS(4)

-

-

-

-
yds — Yamaha DS-1
-    series PCI audio controller device driver

-

-

-

-
yds* at pci? dev ? function ?
-  

-  audio* at audiobus?
-  

-  mpu* at yds?
-  

-  opl* at yds?

-

-

-

-
The yds device driver supports built-in
-    sound devices and sound cards based on Yamaha YMF724/740/744/754 PCI audio
-    controller chip, also known as DS-1 series.

-

-

-

-
ac97(4), audio(4),
-    mpu(4), opl(4),
-  pci(4)

-

-

-

-
The yds device driver appeared in
-    NetBSD 1.5.1.

-

-

-

-
The game port is not supported.

-
The volume of the OPL part is fixed.

-

-

-
-  
-    
-    
-  
-
June 22, 2005NetBSD 10.1

diff --git a/static/netbsd/man4/ym.4 4.html b/static/netbsd/man4/ym.4 4.html
deleted file mode 100644
index f3d9460a..00000000
--- a/static/netbsd/man4/ym.4 4.html	
+++ /dev/null
@@ -1,157 +0,0 @@
-
-  
-    
-    
-    
-  
-
YM(4)Device Drivers ManualYM(4)

-

-

-

-
ym — Yamaha
-    OPL3-SA2 and OPL3-SA3 audio device driver

-

-

-

-
ym* at acpi?
-  

-  ym* at isapnp?
-  

-  ym* at pnpbios? index ?
-  

-  audio* at audiobus?
-  

-  mpu* at ym?
-  

-  opl* at ym?

-

-

-

-
The ym driver provides support for Yamaha
-    YMF711 (OPL3-SA2) and YMF715x (OPL3-SA3) sound devices.

-
The OPL3-SAx device has WSS compatible full-duplex 16bit CODEC,
-    OPL3 FM synthesizer, and MPU401 compatible MIDI I/O port interface.
-    Additionally, OPL3-SA3 has built-in ‘3D Enhanced’
-  equalizer.

-
The joystick interface is handled by the joy(4)
-    driver.

-

-

-

-
The mixer device of ym driver can be
-    accessed by mixerctl(1) command. The layout is shown
-    below.

-

-
            dac ------------------------<-----  -----------------
-midi(OPL3/ZV)->-+----------------------------+->|inputs.midi    |
-cd      ->------+-*--------------------------+->|inputs.cd      |
-line    ->----*-+-+--------------------------+->|inputs.line    |
-speaker ->----+-+-+--------------------------+->|inputs.speaker |
-mic     ->--*-+-+-+--------------------------+->|inputs.mic     |
-            v v v v      monitor.monitor     |  |               |
-        ---------------  -------  |  ------- |  |               |
-        |record.record|->| A/D |---->| D/A |-*->|inputs.dac     |analog
-        |             |  |conv.|-- ->|conv.|    |               |output
-        ---------------  ------- | | -------    | outputs.master|-->
-                           wave  v | wave       | equalization.*|
-                         recording playback     -----------------

-

-
Note that the ‘inputs.dac’
-    is twice as sensitive as other
-    ‘inputs’ volume variables.

-
The hardware volume changes the
-    ‘outputs.master’ value.

-
If an external input source is unmuted by setting corresponding
-    ‘inputs.*.mute’ variable to
-    ‘off’, the device is never put in
-    global power down or power save mode. This is because if the device is in
-    global power down or power save mode, the output is automatically muted.

-
All the external input sources (CD playback, line input, speaker,
-    and MIC) are muted by default.

-
The ‘equalization.*’
-    variables does not exists on OPL3-SA2. The
-    ‘equalization.treble’ and ‘equalization.bass’
-    are enhancement only, and any values below the center position (128) don't
-    take any effect.

-

-

-

-
The ym driver is capable of power
-    management on the OPL3-SAx devices. The following modes can be selected by
-    setting ‘power.save’ variable of
-    mixerctl(1) to
-    ‘powerdown’,
-    ‘powersave’, and
-    ‘nosave’ respectively.

-

-

-  
Global power-down mode

-  
When a subpart of the device is unused, the part is power-down after a
-      timeout period (specified by
-      ‘power.save.timeout’ variable of
-      mixerctl(1) in seconds). When all the subparts of the
-      device are unused, and all the external input sources are muted, the
-      driver puts the device in ‘Global Power Down’ mode.
-    
On the global power down mode, the power consumption is
-        minimized (10μA (SA3) or 200μA (SA2) typ.), but the click
-        noise on power up/down the device is rather loud.

-    
This mode should not be used with headphones or hi-fi
-      audio systems, or your ears or the systems may be damaged.

-  

-  
Power save mode

-  
When a subpart of the device is unused, the part is powered-down after a
-      timeout period (specified by
-      ‘power.save.timeout’ variable of
-      mixerctl(1) in seconds). When all the subparts of the
-      device are unused, and all the external input sources are muted, the
-      driver put the device in ‘Power Save’ mode.
-    
In power save mode, the power consumption is reduced (5mA
-        typ.). The click noise on power up/down of the device is very small, but
-        this operation requires muting/unmuting the device, which make some
-        noise. In order to reduce the noise, setting the master volume at the
-        small value is effective.

-  

-  
No power-save mode

-  
Once the device is powered-up, it remains on after the use of the device.
-      Once a subpart of the device is powered-up, it shall not be power-down.
-      This mode minimizes click noises on power switching, but maximizes power
-      consumption (30-100mA).
-    
On suspending, the device is put into power-save state.

-  

-

-

-

-

-
mixerctl(1), apm(4),
-    audio(4), isapnp(4),
-    joy(4), midi(4),
-    mpu(4), opl(4),
-    i386/pnpbios(4)

-

-

-

-
The ym device driver appeared in
-    NetBSD 1.4.

-

-

-

-
Although the parameters of the device are saved and restored on
-    apm(4) suspend/resume, the DMA state is not restored. That
-    is, if the system suspends during playback, this is not continued after
-    suspend/resume cycle.

-
The joystick port is not under power management. If a
-    joy(4) device is configured, the device will never be put
-    in global power down or power save mode.

-
The external devices, such as Zoomed Video port, OPL4-ML/2, modem,
-    and CD-ROM are not supported.

-

-

-
-  
-    
-    
-  
-
August 23, 2020NetBSD 10.1

diff --git a/static/netbsd/man4/zero.4 4.html b/static/netbsd/man4/zero.4 4.html
deleted file mode 100644
index 2230c4f0..00000000
--- a/static/netbsd/man4/zero.4 4.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZERO(4)Device Drivers ManualZERO(4)

-

-

-

-
zero — the zero
-    device

-

-

-

-
The zero special device provides an
-    infinite stream of zeros.

-

-

-

-

-  
/dev/zero

-  
 

-

-

-

-

-
A zero device first appeared in SunOS 4.0
-    and subsequently 4.4BSD

-

-

-
-  
-    
-    
-  
-
September 9, 2019NetBSD 10.1

diff --git a/static/netbsd/man4/zstty.4 4.html b/static/netbsd/man4/zstty.4 4.html
deleted file mode 100644
index bac49af5..00000000
--- a/static/netbsd/man4/zstty.4 4.html	
+++ /dev/null
@@ -1,374 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZSTTY(4)Device Drivers ManualZSTTY(4)

-

-

-

-
zstty, zsc,
-    zs — Zilog 8530 Serial
-    Communications Controller (SCC) for RS-232C, RS-422, and RS-423

-

-

-

-
options PPS_SYNC
-  

-  options PPS_TRAILING_EDGE

-

-

-
zsc0	at ioasic? offset 0x100000
-  

-  zsc1	at ioasic? offset 0x180000
-  

-  zstty0	at zsc0 channel ?	# serial ports on B channels
-  

-  zstty2	at zsc1 channel ?	# serial ports on B channels
-  

-  lkkbd0	at zsc1 channel ?	# keyboard port on A channels
-  

-  vsms0	at zsc0 channel ?	# mouse port on A channels

-

-

-

-
zsc*	at mainbus0
-  

-  zstty*	at zsc? channel ?

-

-

-

-
zsc0	at mainbus? addr 0x1c800000 irq 4
-  

-  zstty0	at zsc0 channel 0
-  

-  zstty1	at zsc0 channel 1

-

-

-

-
zsc0	at sbdio?
-  

-  zstty0	at zsc? channel 0	# SIO ch-A
-  

-  zstty1	at zsc? channel 1	# SIO ch-B

-

-

-

-
zsc0	at obio?
-  

-  zstty*	at zsc? channel ?
-  

-  options ZS_TXDMA

-

-

-

-
zsc0	at obio0 addr 0xbb000000
-  

-  zstty0	at zsc0 channel 0
-  

-  zstty1	at zsc0 channel 1

-

-

-

-
zsc*	at pcc? ipl 4
-  

-  zsc*	at pcctwo? ipl 4
-  

-  zstty*	at zsc? channel ?

-

-

-

-
zsc0	at hb0 addr 0xe0d40000 ipl 5 vect 64 flags
-    0x0	# news1700
-  

-  zsc0	at hb1 addr 0xe1780000 ipl 5 vect 64 flags 0x1	#
-    news1200
-  

-  zstty0	at zsc0 channel 0
-  

-  zstty1	at zsc0 channel 1

-

-

-

-
zsc0	at hb0 addr 0xbfec0000 level 1 flags 0x0	#
-    on-board
-  

-  zsc1	at hb0 addr 0xb8c40100 level 1 flags 0x1	# expansion
-    board
-  

-  zsc2	at hb0 addr 0xb8c40104 level 1 flags 0x1
-  

-  zsc0	at ap?
-  

-  zstty0	at zsc0 channel 0
-  

-  zstty1	at zsc0 channel 1
-  

-  zstty2	at zsc1 channel 0
-  

-  zstty3	at zsc1 channel 1
-  

-  zstty4	at zsc2 channel 0
-  

-  zstty5	at zsc2 channel 1

-

-

-

-
zsc0	at intio? ipl 5
-  

-  #zsc1	at intio? ipl 5
-  

-  zstty0	at zsc0 channel 0	# Serial Port A
-  

-  zstty1	at zsc0 channel 1	# Serial Port B

-

-

-

-
zsc0	at	ioasic? offset 0x100000 # Z85C30
-  

-  zsc1	at	ioasic? offset 0x180000 # Z85C30
-  

-  zstty*	at	zsc? channel ?		# serial ports on B/A
-    channels
-  

-  lkkbd*	at	zsc1 channel ?		# keyboard port on A
-    channels
-  

-  vsms*	at	zsc0 channel ?		# mouse port on A
-  channels

-

-

-

-
zsc* 	at hpc0 offset ?
-  

-  zstty*	at zsc? channel ?

-

-

-

-
zs0	at mainbus0				# sun4c
-  

-  zs0	at obio0				# sun4m
-  

-  zs0	at obio0 addr 0xf1000000 level 12	# sun4/200 and
-    sun4/300
-  

-  zs0	at obio0 addr 0x01000000 level 12	# sun4/100
-  

-  zstty0	at zs0 channel 0			# ttya
-  

-  zstty1	at zs0 channel 1			# ttyb
-  

-  zs1	at mainbus0				# sun4c
-  

-  zs1	at obio0				# sun4m
-  

-  zs1	at obio0 addr 0xf0000000 level 12	# sun4/200 and
-    sun4/300
-  

-  zs1	at obio0 addr 0x00000000 level 12	# sun4/100
-  

-  kbd0	at zs1 channel 0			# keyboard
-  

-  ms0	at zs1 channel 1			# mouse
-  

-  zs2	at obio0 addr 0xe0000000 level 12	# sun4/300
-  

-  zstty2	at zs2 channel 0			# ttyc
-  

-  zstty3	at zs2 channel 1			# ttyd

-

-

-

-
zs*	at sbus? slot ? offset ?
-  

-  zs*	at fhc?
-  

-  zstty*	at zs? channel ?			# ttys
-  

-  kbd0	at zstty?
-  

-  ms0	at zstty?

-

-

-

-
zs0	at obio0 addr 0x002000	# 2/120, 2/170
-  

-  zs1	at obmem0 addr 0x780000	# 2/120, 2/170
-  

-  zs0	at obio0 addr 0x7f2000	# 2/50
-  

-  zs1	at obio0 addr 0x7f1800	# 2/50
-  

-  zs2	at mbmem0 addr 0x080800	# 2/120, 2/170 (first sc
-    SCSI)
-  

-  zs3	at mbmem0 addr 0x081000	# 2/120, 2/170 (first sc
-    SCSI)
-  

-  zs4	at mbmem0 addr 0x084800	# 2/120, 2/170 (second sc
-    SCSI)
-  

-  zs5	at mbmem0 addr 0x085000	# 2/120, 2/170 (second sc
-    SCSI)
-  

-  zstty*	at zs? channel ?	# ttya
-  

-  kbd0	at zstty?		# keyboard
-  

-  ms0	at zstty?		# mouse

-

-

-

-
zstty0	at zsc1 channel 0	# ttya
-  

-  zstty1	at zsc1 channel 1	# ttyb
-  

-  kbd0	at zsc0 channel 0	# keyboard
-  

-  ms0	at zsc0 channel 1	# mouse

-

-

-

-
zsc0	at intio0 addr 0xe98000 intr 112
-  

-  zstty0	at zsc0 channel 0		# built-in RS-232C
-  

-  ms0	at zsc0 channel 1		# standard mouse
-  

-  #zsc1	at intio0 addr 0xeafc00 intr 113
-  

-  #zstty2	at zsc1 channel 0
-  

-  #zstty3	at zsc1 channel 1
-  

-  #zsc2	at intio0 addr 0xeafc10 intr 114
-  

-  #zstty4	at zsc2 channel 0
-  

-  #zstty5	at zsc2 channel 1

-

-

-

-

-
The zstty driver provides TTY support for
-    Zilog 8530 Dual UART chips.

-
Input and output for each line may set to any baud rate in the
-    range 50 to 38400 (and higher on some machines).

-
The
-     option
-    enables code to use the Data Carrier Detect (DCD) signal line for attachment
-    to an external precision clock source (e.g., GPS, CDMA) which generates a
-    Pulse Per Second (PPS) signal. This is used by ntpd(8) to
-    discipline the system clock, and more accurately count/measure time. See
-    options(4) for more discussion.

-

-

-

-

-

-

-  
/dev/ttyB0

-  
 

-  
/dev/ttyB1

-  
 

-

-

-

-

-

-  
/dev/ttya

-  
 

-  
/dev/ttyb

-  
 

-  
/dev/ttyc

-  
 

-  
/dev/ttyd

-  
 

-

-

-

-

-

-  
/dev/ttya

-  
 

-  
/dev/ttyb

-  
 

-  
/dev/ttyc

-  
 

-  
/dev/ttyd

-  
 

-

-

-

-

-

-  
/dev/ttya

-  
 

-  
/dev/ttyb

-  
 

-

-

-

-

-

-  
/dev/ttyZ0

-  
 

-  
/dev/ttyZ1

-  
 

-

-

-

-

-

-

-  
zs0*: fifo overflow

-  

-    

-    The on-chip “FIFO” has overflowed and incoming data has been
-      lost. This generally means the machine is not responding to interrupts
-      from the ZS chip fast enough, which can be remedied only by using a lower
-      baud rate.

-  
zs0*: ring overflow

-  

-    

-    The software input "ring" has overflowed. This usually means input
-      flow-control is not configured correctly (i.e. incorrect cable
-    wiring).

-

-

-

-

-
kbd(4), ms(4),
-    options(4), tty(4),
-    ntpd(8)

-

-

-

-
The zstty driver was derived from the
-    sparc zs driver supplied
-    with 4.4BSD UNIX.

-

-

-

-
/dev/ttyB1 on alpha is created by
-    MAKEDEV(8) with minor number 2, so the corresponding
-    device should be zstty2, not zstty1.

-

-

-

-
The old Zilog 8530 chip has a very small FIFO (3 bytes?) and
-    therefore has very strict latency requirements for the interrupt service
-    routine. This limits the usable baud rates on many machines.

-

-

-
-  
-    
-    
-  
-
September 12, 2017NetBSD 10.1

diff --git a/static/netbsd/man4/zyd.4 4.html b/static/netbsd/man4/zyd.4 4.html
deleted file mode 100644
index e7153d13..00000000
--- a/static/netbsd/man4/zyd.4 4.html	
+++ /dev/null
@@ -1,305 +0,0 @@
-
-  
-    
-    
-    
-  
-
ZYD(4)Device Drivers ManualZYD(4)

-

-

-

-
zyd — ZyDAS
-    ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device

-

-

-

-
zyd* at uhub? port ?

-

-

-

-
The zyd driver provides support for
-    wireless network adapters based around the ZyDAS ZD1211 and ZD1211B USB
-    chips.

-
These are the modes the zyd driver can
-    operate in:

-

-  
BSS mode

-  
Also known as
-      
-      mode, this is used when associating with an access point, through which
-      all traffic passes. This mode is the default.

-  
monitor mode

-  
In this mode the driver is able to receive packets without associating
-      with an access point. This disables the internal receive filter and
-      enables the card to capture packets from networks which it wouldn't
-      normally have access to, or to scan for access points.

-

-
zyd supports software WEP. It can be
-    typically configured in one of three modes: no encryption; 40-bit
-    encryption; or 104-bit encryption. Unfortunately, due to serious weaknesses
-    in WEP protocol it is strongly recommended that it not be used as the sole
-    mechanism to secure wireless communication. WEP is not enabled by
-  default.

-

-

-

-
The zyd driver can be configured at
-    runtime with ifconfig(8) or on boot with
-    ifconfig.if(5) using the following parameters:

-

-  

-    bssid

-  
Set the desired BSSID.

-  

-  
Unset the desired BSSID. The interface will automatically select a BSSID
-      in this mode, which is the default.

-  

-    n

-  
Set the channel (radio frequency) to be used by the driver based on the
-      given channel ID n.

-  

-  
Unset the desired channel to be used by the driver. The driver will
-      automatically select a channel in this mode, which is the default.

-  

-    media

-  
The zyd driver supports the following
-      media types:
-    

-    

-      

-      
Enable autoselection of the media type and options.

-      

-      
Set 802.11b DS 1Mbps operation.

-      

-      
Set 802.11b DS 2Mbps operation.

-      

-      
Set 802.11b DS 5.5Mbps operation.

-      

-      
Set 802.11b DS 11Mbps operation.

-    

-  

-  

-    opts

-  
The zyd driver supports the following media
-      options:
-    

-      

-      
Select Independent Basic Service Set (IBSS) operation.

-    

-  

-  

-    opts

-  
Disable the specified media options on the driver and return it to the
-      default mode of operation (BSS).

-  

-    id

-  
Set the network ID. The id can either be any text
-      string up to 32 characters in length, or a series of hexadecimal digits up
-      to 64 digits. An empty id string allows the
-      interface to connect to any available access points. By default the
-      zyd driver uses an empty string. Note that network
-      ID is synonymous with Extended Service Set ID (ESSID).

-  

-  
Set the network ID to the empty string to allow the interface to connect
-      to any available access point.

-  

-    key

-  
Enable WEP encryption using the specified key. The
-      key can either be a string, a series of hexadecimal
-      digits (preceded by ‘0x’), or a set of keys of the form
-      “n:k1,k2,k3,k4”, where ‘n’ specifies which of
-      the keys will be used for transmitted packets, and the four keys,
-      “k1” through “k4”, are configured as WEP keys.
-      If a set of keys is specified, a comma (‘,’) within the key
-      must be escaped with a backslash. Note that if multiple keys are used,
-      their order must be the same within the network.
-      zyd is capable of using both 40-bit (5 characters
-      or 10 hexadecimal digits) or 104-bit (13 characters or 26 hexadecimal
-      digits) keys.

-  

-  
Disable WEP encryption. This is the default mode of operation.

-

-

-

-

-
The following devices are known to be supported by the
-    zyd driver:

-

-

-

-  
3COM 3CRUSB10075

-  
 

-  
Acer WLAN-G-US1

-  
 

-  
Airlink+ AWLL3025

-  
 

-  
Airlink 101 AWLL3026

-  
 

-  
AOpen 802.11g WL54

-  
 

-  
Asus A9T integrated wirless

-  
 

-  
Asus WL-159g

-  
 

-  
Belkin F5D7050 v.4000

-  
 

-  
Billion BiPAC 3011G

-  
 

-  
Buffalo WLI-U2-KG54L

-  
 

-  
CC&C WL-2203B

-  
 

-  
DrayTek Vigor 550

-  
 

-  
Edimax EW-7317UG

-  
 

-  
Edimax EW-7317LDG

-  
 

-  
Fiberline Networks WL-43OU

-  
 

-  
iNexQ UR055g

-  
 

-  
Linksys WUSBF54G

-  
 

-  
Longshine LCS-8131G3

-  
 

-  
MSI US54SE

-  
 

-  
Philips SNU5600

-  
 

-  
Planet WL-U356

-  
 

-  
Planex GW-US54GZ

-  
 

-  
Planex GW-US54GZL

-  
 

-  
Planex GW-US54Mini

-  
 

-  
Safecom SWMULZ-5400

-  
 

-  
Sagem XG 760A

-  
 

-  
Sagem XG 76NA

-  
 

-  
Sandberg Wireless G54 USB

-  
 

-  
Sitecom WL-113

-  
 

-  
SMC SMCWUSB-G

-  
 

-  
Sweex wireless USB 54 Mbps

-  
 

-  
Tekram/Siemens USB adapter

-  
 

-  
Telegent TG54USB

-  
 

-  
Trendnet TEW-424UB

-  
 

-  
Trendnet TEW-429UB

-  
 

-  
TwinMOS G240

-  
 

-  
US Robotics 5423

-  
 

-  
X-Micro XWL-11GUZX

-  
 

-  
Yakumo QuickWLAN USB

-  
 

-  
Zonet ZEW2501

-  
 

-  
ZyXEL ZyAIR G-220

-  
 

-

-

-

-

-

-
The adapter needs some firmware files, which are loaded on demand
-    by the driver when a device is attached:

-

-

-

-  
/libdata/firmware/zyd/zyd-zd1211

-  
 

-  
/libdata/firmware/zyd/zyd-zd1211b

-  
 

-

-

-See firmload(9) for how to change this.
-

-

-

-
The following ifconfig.if(5) example configures
-    zyd0 to join whatever network is available on boot, using WEP key
-    “0x1deadbeef1”, channel 11:

-

-
inet 192.168.1.1 netmask 255.255.255.0 nwkey 0x1deadbeef1 chan 11

-

-
Configure zyd0 for WEP, using hex key
-    “0x1deadbeef1”:

-

-
# ifconfig zyd0 nwkey 0x1deadbeef1

-

-
Return zyd0 to its default settings:

-

-
# ifconfig zyd0 -bssid -chan media autoselect \
-	nwid "" -nwkey

-

-
Join an existing BSS network, “my_net”:

-

-
# ifconfig zyd0 192.168.0.2 netmask 0xffffff00 nwid my_net

-

-

-

-

-

-  
zyd%d: could not read firmware file %s (error=%d)

-  
For some reason, the driver was unable to read the firmware file from the
-      filesystem. The file might be missing or corrupted.

-  
zyd%d: could not load firmware (error=%d)

-  
An error occurred while attempting to upload the firmware to the onboard
-      microcontroller unit.

-  
zyd%d: could not send command (error=%s)

-  
An attempt to send a command to the firmware failed.

-  
zyd%d: sorry, radio %s is not supported yet

-  
Support for the specified radio chip is not yet implemented in the driver.
-      The device will not attach.

-  
zyd%d: device version mismatch: 0x%x (only >= 43.30 supported)

-  
Early revisions of the ZD1211 chipset are not supported by this driver.
-      The device will not attach.

-  
zyd%d: device timeout

-  
A frame dispatched to the hardware for transmission did not complete in
-      time. The driver will reset the hardware. This should not happen.

-

-

-

-

-
arp(4), ifmedia(4),
-    intro(4), netintro(4),
-    usb(4), ifconfig.if(5),
-    ifconfig(8), firmload(9)

-

-

-

-
The zyd driver was written by
-    Florian Stoehr
-    <ich@florian-stoehr.de>,
-    Damien Bergamini
-    <damien@openbsd.org>,
-    and Jonathan Gray
-    <jsg@openbsd.org>.

-

-

-

-
The zyd driver does not support a lot of
-    the functionality available in the hardware. More work is required to
-    properly support the IBSS and power management features.

-

-

-
-  
-    
-    
-  
-
March 24, 2019NetBSD 10.1

diff --git a/static/netbsd/man8/MAKEDEV.8 4.html b/static/netbsd/man8/MAKEDEV.8 4.html
deleted file mode 100644
index 786c20ed..00000000
--- a/static/netbsd/man8/MAKEDEV.8 4.html	
+++ /dev/null
@@ -1,815 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAKEDEV(8)System Manager's ManualMAKEDEV(8)

-

-

-

-
MAKEDEV — create
-    system and device special files

-

-

-

-
-  
-    
-    
-  
-
MAKEDEV[-fMsu] [-m
-      mknod] [-p
-      pax] [-t
-      mtree] {special |
-      device} [...]

-

-

-

-
MAKEDEV is used to create system and
-    device special files. As arguments it takes the names of known devices, like
-    sd0, or of special targets, like
-    all or std, which create a
-    collection of device special files, or local, which
-    invokes MAKEDEV.local(8) with the
-    all argument.

-
The script is in /dev/MAKEDEV. Devices are
-    created in the current working directory; in normal use,
-    MAKEDEV should be invoked with
-    /dev as the current working directory.

-
Supported options are:

-

-  

-  
Force permissions to be updated on existing devices. This works only if
-      MAKEDEV invokes mknod(8); it is
-      not compatible with the -p,
-      -s, or -t options.

-  

-  
Create a memory file system, union mounted over the current directory, to
-      contain the device special files. The memory file system is created using
-      mount_tmpfs(8) or mount_mfs(8), in
-      that order of preference.
-    
If the -M flag is specified more than
-        once, then MAKEDEV assumes that it is being
-        invoked from init(8) to populate a memory file system
-        for /dev. In this case,
-        MAKEDEV will also redirect its output to the
-        system console.

-  

-  

-    mknod

-  
Force the use of mknod(8), and specify the name or path
-      to the mknod(8) program. [Usually, $TOOL_MKNOD or
-      mknod.]

-  

-    pax

-  
Force the use of pax(1), and specify the name or path to
-      the pax(1) program. [Usually, $TOOL_PAX or pax.]

-  

-  
Generate an mtree(8) specfile instead of creating
-      devices.

-  

-    mtree

-  
Force the use of mtree(8), and specify the name or path
-      to the mtree(8) program. [Usually, $TOOL_MTREE or
-      mtree.]

-  

-  
Don't re-create devices that already exist.

-

-
MAKEDEV has several possible methods of
-    creating device nodes:

-
    
-  
  • By invoking the mknod(8) command once for each device
-      node. This is the traditional method, but it is slow because each device
-      node is created using a new process.
-    
    The -m option forces
-        MAKEDEV to use the mknod(8)
-        method.
    
-  
    • 
-  
  • By internally creating a specfile in a format usable by
-      mtree(8), and providing the specfile on standard input
-      to a pax(1) or mtree(8) command,
-      invoked with options that request it to create the device nodes as well as
-      any necessary subdirectories. This is much faster than creating device
-      nodes with mknod(8), because it requires much fewer
-      processes; however, it's not compatible with the
-      -f option.
-    
    The -p or -t
-        options force MAKEDEV to use the
-        pax(1) or mtree(8) methods.
    
-  
    • 
-  
  • If the -s option is specified, then
-      MAKEDEV will not create device nodes at all, but
-      will output a specfile in a format usable by
-    mtree(8).
    • 
-

-
The -m, -p,
-    -s, and -t flags are
-    mutually exclusive. If none of these flags is specified, then
-    MAKEDEV will use mtree(8),
-    pax(1), or mknod(8), in that order of
-    preference, depending on which commands appear to be available and usable.
-    In normal use, it's expected that mtree(8) will be
-    available, so it will be chosen. If MAKEDEV is
-    invoked by init(8), it's expected that
-    mtree(8) will not be available, but
-    pax(1) may be available.

-
The special targets supported on NetBSD
-    are:

-

-

-  
all

-  
Makes all known devices, including local devices. Tries to make the
-      'standard' number of each type.

-  
init

-  
A set of devices that is used for MFS /dev by init. May be equal to
-      ``all''.

-  
floppy

-  
Devices to be put on install floppies

-  
ramdisk

-  
Devices to be put into INSTALL kernel ramdisks.

-  
std

-  
Standard devices

-  
local

-  
Configuration specific devices

-  
lua

-  
Lua device

-  
wscons

-  
Make wscons devices

-  
usbs

-  
Make USB devices

-

-
Please note that any hash marks (“#”) in the
-    following list of supported device targets must be replaced by digits when
-    calling MAKEDEV:

-

-  
Tapes:

-  

-    

-      
st#

-      
SCSI tapes, see st(4)

-      
wt#

-      
QIC-interfaced (e.g. not SCSI) 3M cartridge tape, see
-          wt(4)

-      
ht#

-      
MASSBUS TM03 and TU??, see vax/ht(4)

-      
mt#

-      
MSCP tapes (e.g. TU81, TK50), see vax/mt(4)

-      
tm#

-      
UNIBUS TM11 and TE10 emulations (e.g. Emulex TC-11), see
-          vax/tm(4)

-      
ts#

-      
UNIBUS TS11, see vax/ts(4)

-      
ut#

-      
UNIBUS TU45 emulations (e.g. si 9700), see
-        vax/ut(4)

-      
uu#

-      
TU58 cassettes on DL11 controller, see
-        vax/uu(4)

-    

-  

-  
Disks:

-  

-    

-      
dk#

-      
Wedge disk slices, see dk(4)

-      
ccd#

-      
Concatenated disk devices, see ccd(4)

-      
cd#

-      
SCSI or ATAPI CD-ROM, see cd(4)

-      
cgd#

-      
Cryptographic disk devices, see cgd(4)

-      
raid#

-      
RAIDframe disk devices, see raid(4)

-      
sd#

-      
SCSI disks, see sd(4)

-      
wd#

-      
``winchester'' disk drives (ST506,IDE,ESDI,RLL,...), see
-          wd(4)

-      
bmd#

-      
Nereid bank memory disks, see x68k/bmd(4)

-      
ed#

-      
IBM PS/2 ESDI disk devices, see edc(4)

-      
fd#

-      
``floppy'' disk drives (3 1/2", 5 1/4"), see
-          amiga/fdc(4), sparc64/fdc(4),
-          x86/fdc(4)

-      
fss#

-      
Files system snapshot devices, see fss(4)

-      
gdrom#

-      
Dreamcast ``gigadisc'' CD-ROM drive, see
-          dreamcast/gdrom(4)

-      
hk#

-      
UNIBUS RK06 and RK07, see vax/hk(4)

-      
hp#

-      
MASSBUS RM??, see vax/hp(4)

-      
ld#

-      
Logical disk devices (e.g., hardware RAID), see
-          ld(4)

-      
mcd#

-      
Mitsumi CD-ROM, see mcd(4)

-      
md#

-      
Memory pseudo-disk devices, see md(4)

-      
ofdisk#

-      
OpenFirmware disk devices

-      
ra#

-      
MSCP disks (RA??, RD??)

-      
rb#

-      
730 IDC w/ RB80 and/or RB02

-      
rd#

-      
HDC9224 RD disks on VS2000, see hp300/rd(4)

-      
rl#

-      
UNIBUS RL02, see vax/rl(4)

-      
rx#

-      
MSCP floppy disk (RX33/50/...)

-      
up#

-      
Other UNIBUS devices (e.g. on Emulex SC-21V controller), see
-          vax/up(4)

-      
vnd#

-      
``file'' pseudo-disks, see vnd(4)

-      
xbd#

-      
Xen virtual disks, see xbd(4)

-      
xd#

-      
Xylogic 753/7053 disks, see sparc/xd(4)

-      
xy#

-      
Xylogic 450/451 disks, see sparc/xy(4)

-    

-  

-  
Pointing devices:

-  

-    

-      
wsmouse#

-      
wscons mouse events, see wsmouse(4)

-      
lms#

-      
Logitech bus mouse, see i386/lms(4)

-      
mms#

-      
Microsoft bus mouse, see dreamcast/mms(4),
-          i386/mms(4)

-      
qms#

-      
``quadrature mouse'', see acorn32/qms(4)

-      
pms#

-      
PS/2 mouse

-      
mouse

-      
Mouse (provides events, for X11)

-    

-  

-  
Keyboard devices:

-  

-    

-      
wskbd#

-      
wscons keyboard events, see wskbd(4)

-      
kbd

-      
Raw keyboard (provides events, for X11), see
-          sparc/kbd(4), sun2/kbd(4),
-          sun3/kbd(4)

-      
kbdctl

-      
Keyboard control

-    

-  

-  
Terminals/Console ports:

-  

-    

-      
tty[01]#

-      
Standard serial ports, see tty(4)

-      
tty0#

-      
SB1250 (``sbscn'') serial ports (sbmips), see
-        tty(4)

-      
ttyE#

-      
wscons - Workstation console (``wscons'') glass-tty emulators

-      
ttyCZ?

-      
Cyclades-Z multiport serial boards. Each ``unit'' makes 64 ports., see
-          cz(4)

-      
ttyCY?

-      
Cyclom-Y multiport serial boards. Each ``unit'' makes 32 ports., see
-          cy(4)

-      
ttye#

-      
ITE bitmapped consoles, see amiga/ite(4)

-      
ttyv0

-      
pccons

-      
ttyC?

-      
NS16550 (``com'') serial ports

-      
ttyS#

-      
SA1110 serial port (hpcarm)

-      
ttyTX?

-      
TX39 internal serial ports (hpcmips)

-      
ttyB?

-      
DEC 3000 ZS8530 (``scc'') serial ports (alpha)

-      
ttyA#

-      
Mfc serial ports (amiga)

-      
ttyB#

-      
Msc serial ports (amiga)

-      
ttyC#

-      
Com style serial ports (DraCo, HyperCom) (amiga) On the DraCo, units 0
-          and 1 are the built-in ``modem'' and ``mouse'' ports, if
-        configured.

-      
ttyA0

-      
8530 Channel A (formerly ser02) (atari)

-      
ttyA1

-      
8530 Channel B (formerly mdm02) (atari)

-      
ttyB0

-      
UART on first 68901 (formerly mdm01) (atari)

-      
ixpcom

-      
IXP12x0 COM ports

-      
epcom

-      
EP93xx COM ports

-      
plcom

-      
ARM PL01[01] serial ports

-      
wmcom

-      
EPOC Windermere COM ports

-      
ttyM?

-      
HP200/300 4 port serial mux interface (hp300)

-      
ttya

-      
``ttya'' system console (luna68k)

-      
ttyb

-      
Second system serial port (luna68k)

-      
tty#

-      
Onboard serial ports (mvme68k) On the mvme147 these are: ttyZ1, ttyZ2
-          and ttyZ3. On the mvme167, and '177: ttyC1, ttyC2 and ttyC3. Note that
-          tty[CZ]0 is grabbed by the console device so is not created by
-          default, see tty(4)

-      
dc#

-      
PMAX 4 channel serial interface (kbd, mouse, modem, printer)

-      
scc#

-      
82530 serial interface (pmax)

-      
ttyZ#

-      
Zilog 8530 (``zstty'') serial ports, see
-        zstty(4)

-      
tty[abcd]

-      
Built-in serial ports (sparc)

-      
tty#

-      
Z88530 serial controllers (sparc64), see tty(4)

-      
ttyh#

-      
SAB82532 serial controllers (sparc64), see
-          sparc64/sab(4)

-      
tty[a-j]

-      
Built-in serial ports (sun2, sun3)

-      
ttyC?

-      
pccons (arc)

-      
dz#

-      
UNIBUS DZ11 and DZ32 (vax), see emips/dz(4),
-          vax/dz(4)

-      
dh#

-      
UNIBUS DH11 and emulations (e.g. Able DMAX, Emulex CS-11) (vax), see
-          vax/dh(4)

-      
dmf#

-      
UNIBUS DMF32 (vax), see vax/dmf(4)

-      
dhu#

-      
UNIBUS DHU11 (vax), see vax/dhu(4)

-      
dmz#

-      
UNIBUS DMZ32 (vax), see vax/dmz(4)

-      
dl#

-      
UNIBUS DL11 (vax), see vax/dl(4)

-      
xencons

-      
Xen virtual console

-    

-  

-  
Terminal multiplexors:

-  

-    

-      
dc#

-      
4 channel serial interface (keyboard, mouse, modem, printer)

-      
dh#

-      
UNIBUS DH11 and emulations (e.g. Able DMAX, Emulex CS-11), see
-          vax/dh(4)

-      
dhu#

-      
UNIBUS DHU11, see vax/dhu(4)

-      
dl#

-      
UNIBUS DL11, see vax/dl(4)

-      
dmf#

-      
UNIBUS DMF32, see vax/dmf(4)

-      
dmz#

-      
UNIBUS DMZ32, see vax/dmz(4)

-      
dz#

-      
UNIBUS DZ11 and DZ32, see emips/dz(4),
-          vax/dz(4)

-      
scc#

-      
82530 serial interface

-    

-  

-  
Call units:

-  

-    

-      
dn#

-      
UNIBUS DN11 and emulations (e.g. Able Quadracall), see
-          vax/dn(4)

-    

-  

-  
Pseudo terminals:

-  

-    

-      
ptm

-      
Pty multiplexor device, and pts directory, see
-          ptm(4)

-      
pty#

-      
Set of 16 master and slave pseudo terminals, see
-          pty(4)

-      
opty

-      
First 16 ptys, to save inodes on install media

-      
ipty

-      
First 2 ptys, for install media use only

-    

-  

-  
Printers:

-  

-    

-      
arcpp#

-      
Archimedes parallel port

-      
lpt#

-      
Stock lp, see lpt(4),
-          acorn32/lpt(4), mvme68k/lpt(4),
-          x86/lpt(4)

-      
lpa#

-      
Interruptless lp

-      
par#

-      
Amiga motherboard parallel port

-      
cpi#

-      
Macintosh Nubus CSI parallel printer card, see
-          mac68k/cpi(4)

-    

-  

-  
USB devices:

-  

-    

-      
usb#

-      
USB control devices, see usb(4)

-      
uhid#

-      
USB generic HID devices, see uhid(4)

-      
ulpt#

-      
USB printer devices, see ulpt(4)

-      
ugen#

-      
USB generic devices, see ugen(4)

-      
uscanner#

-      
USB scanners, see uscanner(4)

-      
ttyHS#

-      
USB Option N.V. modems

-      
ttyU#

-      
USB modems, see ucom(4)

-      
ttyY#

-      
USB serial adapters

-    

-  

-  
Video devices:

-  

-    

-      
bwtwo#

-      
Monochromatic frame buffer, see sparc/bwtwo(4),
-          sun2/bwtwo(4), sun3/bwtwo(4)

-      
cgtwo#

-      
8-bit color frame buffer, see sparc/cgtwo(4),
-          sun3/cgtwo(4)

-      
cgthree#

-      
8-bit color frame buffer, see sparc/cgthree(4)

-      
cgfour#

-      
8-bit color frame buffer, see sparc/cgfour(4),
-          sun3/cgfour(4)

-      
cgsix#

-      
Accelerated 8-bit color frame buffer, see
-          sparc/cgsix(4)

-      
cgeight#

-      
24-bit color frame buffer, see sparc/cgeight(4)

-      
etvme

-      
Tseng et-compatible cards on VME (atari)

-      
ik#

-      
UNIBUS interface to Ikonas frame buffer, see
-          vax/ik(4)

-      
leo

-      
Circad Leonardo VME-bus true color (atari)

-      
ps#

-      
UNIBUS interface to Picture System 2, see
-        vax/ps(4)

-      
qv#

-      
QVSS (MicroVAX) display

-      
tcx#

-      
Accelerated 8/24-bit color frame buffer, see
-          sparc/tcx(4)

-    

-  

-  
Maple bus devices:

-  

-    

-      
maple

-      
Maple bus control devices, see
-        dreamcast/maple(4)

-      
mlcd#

-      
Maple bus LCD devices, see dreamcast/mlcd(4)

-      
mmem#

-      
Maple bus storage devices, see
-        dreamcast/mmem(4)

-    

-  

-  
IEEE1394 bus devices:

-  

-    

-      
fw#

-      
IEEE1394 bus generic node access devices

-      
fwmem#

-      
IEEE1394 bus physical memory of the remote node access devices

-    

-  

-  
Special purpose devices:

-  

-    

-      
ad#

-      
UNIBUS interface to Data Translation A/D converter, see
-          vax/ad(4)

-      
agp#

-      
AGP GART devices, see agp(4)

-      
altq

-      
ALTQ control interface, see altq(4)

-      
amr#

-      
AMI MegaRaid control device, see amr(4)

-      
apm

-      
Power management device, see i386/apm(4)

-      
audio#

-      
Audio devices, see audio(4)

-      
bell#

-      
OPM bell device (x68k)

-      
bktr

-      
Brooktree 848/849/878/879 based TV cards, see
-          bktr(4)

-      
bpf

-      
Packet filter, see bpf(4)

-      
bthub

-      
Bluetooth Device Hub control interface, see
-        bthub(4)

-      
cfs#

-      
Coda file system device

-      
ch#

-      
SCSI media changer, see ch(4)

-      
cir#

-      
Consumer IR, see cir(4)

-      
clockctl

-      
Clock control for non root users, see
-        clockctl(4)

-      
cpuctl

-      
CPU control

-      
crypto

-      
Hardware crypto access driver, see crypto(4)

-      
dmoverio

-      
Hardware-assisted data movers, see dmoverio(4)

-      
dpt#

-      
DPT/Adaptec EATA RAID management interface, see
-          dpt(4)

-      
dpti#

-      
DPT/Adaptec I2O RAID management interface, see
-          dpti(4)

-      
drm#

-      
Direct Rendering Manager interface, see drm(4)

-      
dtv#

-      
Digital TV interface, see dtv(4)

-      
fb#

-      
PMAX generic framebuffer pseudo-device

-      
fd

-      
File descriptors

-      
gpiopps#

-      
1PPS signals on GPIO pins, see gpiopps(4)

-      
grf#

-      
Graphics frame buffer device, see amiga/grf(4)

-      
hdaudio#

-      
High Definition audio control device, see
-        hdaudio(4)

-      
hdmicec#

-      
HDMI CEC devices

-      
hil

-      
HP300 HIL input devices, see hil(4)

-      
icp

-      
ICP-Vortex/Intel RAID control interface, see
-        icp(4)

-      
iic#

-      
IIC bus device, see iic(4)

-      
io

-      
X86 IOPL access for COMPAT_10, COMPAT_FREEBSD, see
-          hppa/io(4), i386/io(4)

-      
iop#

-      
I2O IOP control interface, see iop(4)

-      
ipmi#

-      
OpenIPMI compatible interface, see ipmi(4)

-      
ipl

-      
IP Filter

-      
irframe#

-      
IrDA physical frame, see irframe(4)

-      
ite#

-      
Terminal emulator interface to HP300 graphics devices, see
-          amiga/ite(4)

-      
joy#

-      
Joystick device, see joy(4)

-      
kttcp

-      
Kernel ttcp helper device, see kttcp(4)

-      
lockstat

-      
Kernel locking statistics

-      
magma#

-      
Magma multiport serial/parallel cards, see
-          sparc/magma(4)

-      
midi#

-      
MIDI, see midi(4)

-      
mfi#

-      
LSI MegaRAID/MegaSAS control interface, see
-        mfi(4)

-      
mlx#

-      
Mylex DAC960 control interface, see mlx(4)

-      
mly#

-      
Mylex AcceleRAID/eXtremeRAID control interface, see
-          mly(4)

-      
np#

-      
UNIBUS Ethernet co-processor interface, for downloading., see
-          vax/np(4)

-      
npf

-      
NPF packet filter

-      
nsmb#

-      
SMB requester, see nsmb(4)

-      
nvme#

-      
Non-Volatile Memory Host Controller Interface device driver, see
-          nvme(4)

-      
nvme#ns*

-      
Non-Volatile Memory namespace

-      
nvmm

-      
NetBSD Virtual Machine Monitor, see nvmm(4)

-      
openfirm

-      
OpenFirmware accessor

-      
pad#

-      
Pseudo-audio device driver, see pad(4)

-      
pci#

-      
PCI bus access devices, see pci(4)

-      
pf

-      
PF packet filter

-      
putter

-      
Pass-to-Userspace Transporter

-      
px#

-      
PixelStamp Xserver access, see px(4)

-      
qemufwcfg#

-      
QEMU Firmware Configuration, see qemufwcfg(4)

-      
radio#

-      
Radio devices, see radio(4)

-      
random

-      
Random number generator, see rnd(4)

-      
rtc#

-      
RealTimeClock, see atari/rtc(4),
-          evbppc/rtc(4), hp300/rtc(4)

-      
scsibus#

-      
SCSI busses, see scsi(4)

-      
se#

-      
SCSI Ethernet, see se(4)

-      
ses#

-      
SES/SAF-TE SCSI Devices, see ses(4)

-      
speaker

-      
PC speaker, see speaker(4)

-      
spi#

-      
SPI bus device, see spi(4)

-      
sram

-      
Battery backuped memory (x68k)

-      
srt#

-      
Source-address based routing, see srt(4)

-      
ss#

-      
SCSI scanner, see ss(4)

-      
stic#

-      
PixelStamp interface chip

-      
sysmon

-      
System Monitoring hardware, see envsys(4)

-      
tap#

-      
Virtual Ethernet device, see tap(4)

-      
tprof

-      
Task profiler, see tprof(4)

-      
tun#

-      
Network tunnel driver, see tun(4)

-      
twa

-      
3ware Apache control interface, see twa(4)

-      
twe

-      
3ware Escalade control interface, see twe(4)

-      
uk#

-      
Unknown SCSI device, see uk(4)

-      
veriexec

-      
Veriexec fingerprint loader, see veriexec(4)

-      
vhci

-      
Virtual host controller interface

-      
video#

-      
Video capture devices, see video(4)

-      
view#

-      
Generic interface to graphic displays (Amiga)

-      
wsfont#

-      
Console font control, see wsfont(4)

-      
wsmux#

-      
wscons event multiplexor, see wsmux(4)

-      
xenevt

-      
Xen event interface

-    

-  

-  
iSCSI communication devices

-  

-    

-      
iscsi#

-      
ISCSI driver and /sbin/iscsid communication

-    

-  

-  
Trusted Computing devices

-  

-    

-      
tpm

-      
Trusted Platform Module, see tpm(4)

-    

-  

-  
Debugging and tracing

-  

-    

-      
dtrace

-      
Dynamic tracing framework

-    

-  

-

-

-

-

-
The following environment variables affect the execution of
-    MAKEDEV:

-

-  

-  
If this is set, then MAKEDEV will define several
-      shell functions and then return, ignoring all its command line options and
-      arguments. This is used to enable MAKEDEV.local(8) to
-      use the shell functions defined in MAKEDEV.

-

-

-

-

-

-  
/dev

-  
special device files directory

-  
/dev/MAKEDEV

-  
script described in this man page

-  
/dev/MAKEDEV.local

-  
script for site-specific devices

-

-

-

-

-
If the script reports an error that is difficult to understand,
-    you can get more debugging output by using

-
sh
-  -x MAKEDEV
-  argument

-.
-

-

-

-
config(1), pax(1),
-    intro(4), diskless(8),
-    init(8), MAKEDEV.local(8),
-    mknod(8), mount_mfs(8),
-    mount_tmpfs(8), mtree(8)

-

-

-

-
The MAKEDEV command appeared in
-    4.2BSD. The -f,
-    -m, and -s options were
-    added in NetBSD 2.0. The -p,
-    -t, and -M options were
-    added in NetBSD 5.0. The ability to be used as a
-    function library was added in NetBSD 5.0.

-

-

-

-
The -f option is not compatible with the
-    use of mtree(8) or pax(1).

-

-

-

-
Not all devices listed in this manpage are supported on all
-    platforms.

-
This man page is generated automatically from the same sources as
-    /dev/MAKEDEV, in which the device files are not
-    always sorted, which may result in an unusual (non-alphabetical) order.

-
In order to allow a diskless NetBSD client
-    to obtain its /dev directory from a file server
-    running a foreign operating system, one of the following techniques may be
-    useful to populate a directory of device nodes on the foreign server:

-
    
-  
  • If the foreign server is sufficiently similar to
-      NetBSD, run MAKEDEV in an
-      appropriate directory of the foreign server, using the
-      -m flag to refer to a script that converts from
-      command line arguments that would be usable with the
-      NetBSD mknod(8) command to the
-      equivalent commands for the foreign server.
    • 
-  
  • Run MAKEDEV with the
-      -s flag to generate an mtree(8)
-      specification file; this can be done on any host with a POSIX-compliant
-      shell and a few widely-available utilities. Use the
-      pax(1) command with the -w
-      -M flags to convert the mtree(8)
-      specification file into an archive in a format that supports device nodes
-      (such as ustar format); this can be done on a
-      NetBSD host, or can be done in a cross-build
-      environment using
-      /bin/nbpax.
-      Finally, use appropriate tools on the foreign server to unpack the archive
-      and create the device nodes.
    • 
-

-

-

-
-  
-    
-    
-  
-
April 1, 2020NetBSD 10.1

diff --git a/static/netbsd/man8/MAKEDEV.local.8 4.html b/static/netbsd/man8/MAKEDEV.local.8 4.html
deleted file mode 100644
index d5bd6117..00000000
--- a/static/netbsd/man8/MAKEDEV.local.8 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
MAKEDEV.LOCAL(8)System Manager's ManualMAKEDEV.LOCAL(8)

-

-

-

-
MAKEDEV.local —
-    create site-specific device special files

-

-

-

-
-  
-    
-    
-  
-
MAKEDEV.local[-fMsu] [-m
-      mknod] [-p
-      pax] [-t
-      mtree] {all |
-      site-specific-argument}
-      [...]

-

-

-

-
MAKEDEV.local is used to create
-    site-specific device special files. Each argument may be the word
-    all or a site-specific argument. By default, there
-    are no valid site-specific arguments, and the all
-    argument has no effect; This may be changed by editing the script.

-
The script is in /dev/MAKEDEV.local.
-    Devices are created in the current working directory; in normal use,
-    MAKEDEV.local should be invoked with
-    /dev as the current working directory.

-
Supported options for MAKEDEV.local are
-    the same as for MAKEDEV(8).

-

-

-

-

-  
/dev

-  
special device files directory

-  
/dev/MAKEDEV

-  
script that invokes MAKEDEV.local with the
-      all argument.

-  
/dev/MAKEDEV.local

-  
script described in this man page

-

-

-

-

-
config(1), intro(4),
-    MAKEDEV(8), mknod(8)

-

-

-

-
The MAKEDEV.local command appeared in
-    4.2BSD. Handling of the same command line options as
-    MAKEDEV(8), and the use of MAKEDEV(8) as
-    a function library, was added in NetBSD 5.0.

-

-

-

-
The relationship between MAKEDEV.local and
-    MAKEDEV(8) is complex:

-
    
-  
  • If MAKEDEV(8) is invoked with the
-      all or local argument,
-      then it will invoke MAKEDEV.local as a child
-      process, with options similar to those that were originally passed to
-      MAKEDEV(8), and with the all
-      argument.
    • 
-  
  • MAKEDEV.local uses shell functions defined in
-      MAKEDEV(8). This is done by loading
-      MAKEDEV(8) using the shell “.” command,
-      with the MAKEDEV_AS_LIBRARY variable set (to
-      inform MAKEDEV(8) that it should behave as a function
-      library, not as an independent program).
    • 
-

-

-

-
-  
-    
-    
-  
-
August 6, 2011NetBSD 10.1

diff --git a/static/netbsd/man8/afterboot.8 4.html b/static/netbsd/man8/afterboot.8 4.html
deleted file mode 100644
index 870e185b..00000000
--- a/static/netbsd/man8/afterboot.8 4.html	
+++ /dev/null
@@ -1,795 +0,0 @@
-
-  
-    
-    
-    
-  
-
AFTERBOOT(8)System Manager's ManualAFTERBOOT(8)

-

-

-

-
afterboot — things
-    to check after the first complete boot

-

-

-

-

-

-
This document attempts to list items for the system administrator
-    to check and set up after the installation and first complete boot of the
-    system. The idea is to create a list of items that can be checked off so
-    that you have a warm fuzzy feeling that something obvious has not been
-    missed. A basic knowledge of UNIX is assumed.

-
Complete instructions for correcting and fixing items is not
-    provided. There are manual pages and other methodologies available for doing
-    that. For example, to view the man page for the ls(1)
-    command, type:

-

-
man 1 ls

-

-
Administrators will rapidly become more familiar with
-    NetBSD if they get used to using the manual
-  pages.

-

-

-

-
On a fresh install with no other user accounts, login as
-    “root”. You can do so on the console,
-    or over the network using ssh(1). If you have enabled the
-    SSH daemon (see sshd(8)) and wish to allow root logins
-    over the network, edit the /etc/ssh/sshd_config file
-    and set “PermitRootLogin” to “yes” (see
-    sshd_config(5)). The default is to not permit root logins
-    over the network after fresh install in NetBSD.

-
Upon successful login on the console, you may see the message
-    “We recommend creating a non-root account...”. For security
-    reasons, it is bad practice to login as root during regular use and
-    maintenance of the system. In fact, the system will only let you login as
-    root on a secure terminal. By default, only the console is considered to be
-    a secure terminal. Instead, administrators are encouraged to add a
-    “regular” user, add said user to the “wheel”
-    group, then use the su(1) command when root privileges are
-    required:

-

-
useradd -G wheel -m myuser
-passwd myuser

-

-

-

-

-
Change the password for the root user. (Note that throughout the
-    documentation, the term “superuser” is a synonym for the root
-    user.) Choose a password that has numbers, digits, and special characters
-    (not space) as well as from the upper and lower case alphabet. Do not choose
-    any word in any language. It is common for an intruder to use dictionary
-    attacks. Type the command /usr/bin/passwd to change
-    it.

-
It is a good idea to always specify the full path name for both
-    the passwd(1) and su(1) commands as this
-    inhibits the possibility of files placed in your execution
-    PATH for most shells. Furthermore, the superuser's
-    PATH should never contain the current directory
-    (“.”).

-

-

-

-
Check the system date with the date(1) command.
-    If needed, change the date, and/or change the symbolic link of
-    /etc/localtime to the correct time zone in the
-    /usr/share/zoneinfo directory.

-
Examples:

-

-  

-  
Set the current date to October 5th, 2020 6:20pm.

-  

-  
Set the time zone to Eastern Europe Summer Time.

-

-

-

-

-
One of the first things you will likely need to do is to set up
-    your keyboard map (and maybe some other aspects about the system console).
-    To change your keyboard layout, edit the
-    “encoding” variable found in
-    /etc/wscons.conf.

-
wscons.conf(5) contains more information about
-    this file.

-

-

-

-
All significant and easily fixed problems will be reported at
-    the security
-    advisories web page. It is recommended that you check this page
-    regularly.

-
Additionally, you should set
-    “fetch_pkg_vulnerabilities=YES” in
-    /etc/daily.conf to allow your system to
-    automatically update the local database of known vulnerable packages to the
-    latest version available on-line. The system will later check, on a daily
-    basis, if any of your installed packages are vulnerable based on the
-    contents of this database. See daily.conf(5) and
-    security.conf(5) for more details.

-

-

-

-
If your machine does not have a hardware random number generator,
-    it may not be safe to use on the internet until it has enough entropy to
-    generate unpredictable secrets for programs like web browsers and
-    ssh(1). You can use rndctl(8) to list
-    the entropy sources with rndctl -l, or save entropy
-    from another machine running NetBSD with
-    rndctl -S and load it on this one with
-    rndctl -L (as long as there are no eavesdroppers on
-    the medium between the two machines). See entropy(7) for
-    more details.

-

-

-

-
Use the hostname command to verify that
-    the name of your machine is correct. See the man page for
-    hostname(1) if it needs to be changed. You will also need
-    to change the contents of the “hostname”
-    variable in /etc/rc.conf or edit the
-    /etc/myname file to have it stick around for the
-    next reboot. Note that “hostname” is
-    supposed include a domainname, and that this should not be confused with YP
-    (NIS) domainname(1). If you are using
-    dhcpcd(8) to configure network interfaces, it might
-    override these local hostname settings if your DHCP server specifies
-    client's hostname with other network configurations.

-

-

-

-
The first thing to do is an ifconfig -a to
-    see if the network interfaces are properly configured. Correct by editing
-    /etc/ifconfig.interface or the
-    corresponding
-    “ifconfig_interface”
-    variable in rc.conf(5) (where
-    interface is the interface name, e.g.,
-    “le0”) and then using ifconfig(8) to
-    manually configure it if you do not wish to reboot.

-
Alternatively, many networks allow interfaces to be configured
-    automatically via DHCP. To get dhcpcd(8) to start
-    automatically on boot, you will need to have this line in
-    /etc/rc.conf:

-

-
dhcpcd=YES

-
See dhcpcd(8) and
-    dhcpcd.conf(5) for more information on setting up a DHCP
-    client. For information on setting up Wi-Fi, see
-    Wireless networking.

-
You can add new “virtual interfaces” by adding the
-    required entries to
-    /etc/ifconfig.interface. Read
-    the ifconfig.if(5) man page for more information on the
-    format of
-    /etc/ifconfig.interface files.
-    The loopback interface will look something like:

-

-
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32972
-	inet 127.0.0.1 netmask 0xff000000
-	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
-	inet6 ::1 prefixlen 128

-

-
an Ethernet interface something like:

-

-
le0: flags=9863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
-	inet 192.168.4.52 netmask 0xffffff00 broadcast 192.168.4.255
-	inet6 fe80::5ef0:f0f0%le0 prefixlen 64 scopeid 0x1

-

-
and a PPP interface something like:

-

-
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST>
-        inet 203.3.131.108 --> 198.181.0.253 netmask 0xffff0000

-

-
See mrouted(8) for instructions on configuring
-    multicast routing.

-

-

-

-
Issue a netstat -rn command. The output
-    will look something like:

-

-
Routing tables
-
-Internet:
-Destination    Gateway           Flags  Refs     Use  Mtu  Interface
-default        192.168.4.254     UGS      0 11098028    -  le0
-127            127.0.0.1         UGRS     0        0    -  lo0
-127.0.0.1      127.0.0.1         UH       3       24    -  lo0
-192.168.4      link#1            UC       0        0    -  le0
-192.168.4.52   8:0:20:73:b8:4a   UHL      1     6707    -  le0
-192.168.4.254  0:60:3e:99:67:ea  UHL      1        0    -  le0
-
-Internet6:
-Destination        Gateway       Flags  Refs  Use     Mtu  Interface
-::/96              ::1           UGRS     0     0   32972  lo0 =>
-::1                ::1           UH       4     0   32972  lo0
-::ffff:0.0.0.0/96  ::1           UGRS     0     0   32972  lo0
-fc80::/10          ::1           UGRS     0     0   32972  lo0
-fe80::/10          ::1           UGRS     0     0   32972  lo0
-fe80::%le0/64      link#1        UC       0     0    1500  le0
-fe80::%lo0/64      fe80::1%lo0   U        0     0   32972  lo0
-ff01::/32          ::1           U        0     0   32972  lo0
-ff02::%le0/32      link#1        UC       0     0    1500  le0
-ff02::%lo0/32      fe80::1%lo0   UC       0     0   32972  lo0

-

-
The default gateway address is stored in the
-    “defaultroute” variable in
-    /etc/rc.conf, or in the file
-    /etc/mygate. If you need to edit this file, a
-    painless way to reconfigure the network afterwards is to issue

-

-
service network restart

-

-
Or, you may prefer to manually configure using a series of
-    route add and route delete
-    commands (see route(8)). If you run
-    dhcpcd(8) you will have to kill it by running

-

-
service dhcpcd stop

-

-
before you flush the routes.

-
If you wish to route packets between interfaces, add one or both
-    of the following directives (depending on whether IPv4 or IPv6 routing is
-    required) to /etc/sysctl.conf:

-

-
net.inet.ip.forwarding=1

-
net.inet6.ip6.forwarding=1

-
As an alternative, compile a new kernel with the
-    “GATEWAY” option. Packets are not forwarded by default, due to
-    RFC requirements.

-

-

-

-
By default, nodes are created in /dev for
-    a fairly typical number of devices.

-
However, if this system has a large number of devices connected
-    (e.g. for large scale storage), you may want to enable
-    devpubd(8) to ensure a sufficient number of nodes are
-    available. Set “devpubd=YES” in
-    /etc/rc.conf to create nodes automatically during
-    system runtime. You can also run the node creation script by hand:

-

-
cd /dev && sh MAKEDEV

-

-

-

-

-
By default, all services are disabled in a fresh
-    NetBSD installation, and SSH is no exception. You
-    may wish to enable it so you can remotely control your system. Set
-    “sshd=YES” in
-    /etc/rc.conf and then starting the server with the
-    command

-

-
service sshd start

-

-
The first time the server is started, it will generate a new
-    keypair, which will be stored inside the directory
-    /etc/ssh.

-

-

-

-
The system resolves host names according the rules for hosts in
-    the name service switch configuration at
-    /etc/nsswitch.conf. By default, it will query
-    /etc/hosts first, and then the DNS resolver
-    specified in /etc/resolv.conf.

-
Multicast DNS and DNS Service Discovery are usually not enabled by
-    default on a fresh NetBSD system, and can be enabled
-    by setting “mdnsd=YES” in
-    /etc/rc.conf, and either rebooting or running the
-    following command:

-

-
service mdnsd start

-

-
You may also wish to enable mdnsd as a source for host lookups in
-    /etc/nsswitch.conf, see
-    nsswitch.conf(5).

-
If your network does not have a usable DNS resolver, e.g. one
-    provided by DHCP, you can run a local caching recursive resolver by setting
-    “named=YES” in /etc/rc.conf and either
-    rebooting or running the following command:

-

-
service named start

-

-
named(8) is configured in
-    /etc/named.conf by default to run as a local caching
-    recursive resolver. Then, to make the system use it, put the following in
-    /etc/resolv.conf:

-

-
nameserver 127.0.0.1

-

-

-

-

-
To configure the system to connect to a Wi-Fi network with a
-    password using WPA:

-

-
wpa_passphrase networkname password >> /etc/wpa_supplicant.conf

-

-
To configure the system to connect to an open wireless network
-    with no password, edit /etc/wpa_supplicant.conf
-    instead of using wpa_passphrase(8):

-

-
network={
-	ssid="Public-WiFi"
-	key_mgmt=NONE
-	priority=100
-}

-

-
Then bring up the interface and start the necessary daemons:

-

-
ifconfig iwm0 up
-service wpa_supplicant onestart
-service dhcpcd onestart

-

-
To automatically connect at boot, add the following to
-    /etc/rc.conf:

-

-
ifconfig_iwm0="up"

-
dhcpcd=YES

-
wpa_supplicant=YES

-
While using wpa_supplicant(8), you can easily
-    retrieve network scan results with wpa_cli(8):

-

-
wpa_cli scan_results

-

-
Or trigger a rescan:

-

-
wpa_cli scan

-

-

-

-

-
Several services depend on the RPC portmapper
-    rpcbind(8) - formerly known as
-    portmap - being running for proper operation. This
-    includes YP (NIS) and NFS exports, among other services. To get the RPC
-    portmapper to start automatically on boot, you will need to have this line
-    in /etc/rc.conf:

-

-
rpcbind=YES

-

-

-

-
Check the YP domain name with the domainname(1)
-    command. If necessary, correct it by editing the
-    /etc/defaultdomain file or by setting the
-    “domainname” variable in
-    /etc/rc.conf. The
-    /etc/rc.d/network script reads this file on bootup
-    to determine and set the domain name. You may also set the running system's
-    domain name with the domainname(1) command. To start YP
-    client services, simply run ypbind, then perform the
-    remaining YP activation as described in passwd(5) and
-    group(5).

-
In particular, to enable YP passwd support, you'll need to update
-    /etc/nsswitch.conf to include “nis”
-    for the “passwd” and “group” entries. A
-    traditional way to accomplish the same thing is to add following entry to
-    local passwd database via vipw(8):

-

-
+:*::::::::

-

-
Note this entry has to be the very last one. This traditional way
-    works with the default nsswitch.conf(5) setting of
-    “passwd”, which is “compat”.

-
There are many more YP man pages available to help you. You can
-    find more information by starting with nis(8).

-

-

-

-
Check that the disks are mounted correctly by comparing the
-    /etc/fstab file against the output of the
-    mount(8) and df(1) commands.
-  Example:

-

-
# cat /etc/fstab
-/dev/sd0a / ffs     rw              1 1
-/dev/sd0b none swap sw
-/dev/sd0e /usr ffs  rw              1 2
-/dev/sd0f /var ffs  rw              1 3
-/dev/sd0g /tmp ffs  rw              1 4
-/dev/sd0h /home ffs rw              1 5
-
-# mount
-/dev/sd0a on / type ffs (local)
-/dev/sd0e on /usr type ffs (local)
-/dev/sd0f on /var type ffs (local)
-/dev/sd0g on /tmp type ffs (local)
-/dev/sd0h on /home type ffs (local)
-
-# df
-Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
-/dev/sd0a         22311    14589     6606    69%    /
-/dev/sd0e        203399   150221    43008    78%    /usr
-/dev/sd0f         10447      682     9242     7%    /var
-/dev/sd0g         18823        2    17879     0%    /tmp
-/dev/sd0h          7519     5255     1888    74%    /home
-
-# pstat -s
-Device      512-blocks     Used    Avail Capacity  Priority
-/dev/sd0b       131072    84656    46416    65%    0

-

-
Edit /etc/fstab and use the
-    mount(8) and umount(8) commands as
-    appropriate. Refer to the above example and fstab(5) for
-    information on the format of this file.

-
You may wish to do NFS mounts now too, or you can do them
-  later.

-

-

-

-
In order to make sure the system clock is synchronized to that of
-    a publicly accessible NTP server, make sure that
-    /etc/rc.conf contains the following:

-

-
ntpdate=YES

-
ntpd=YES

-
See date(1), ntpdate(8),
-    ntpd(8), rdate(8), and
-    timed(8) for more information on setting the system's
-    date.

-

-

-

-
The NetBSD packages collection, pkgsrc,
-    includes a large set of third-party software. A lot of it is available as
-    binary packages that you can download from
-    https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/
-    or a mirror.

-
For most users, using pkgin to manage binary packages is
-    recommended.

-
To install pkgin, if it was not done by the installer:

-

-
PKG_PATH=https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/[...]
-export PKG_PATH
-pkg_add pkgin
-pkgin update
-pkgin install bash mpg123 fluxbox ...

-

-
See
-    https://www.pkgsrc.org/ and
-    pkgsrc/doc/pkgsrc.txt for more details.

-

-

-

-

-
The system should be usable now, but you may wish to do more
-    customizing, such as adding users, etc. Many of the following sections may
-    be skipped if you are not using that package (for example, skip the
-    Kerberos section if you won't be using
-    Kerberos). We suggest that you cd /etc and edit most
-    of the files in that directory.

-
Note that the /etc/motd file is modified
-    by /etc/rc.d/motd whenever the system is booted. To
-    keep any custom message intact, ensure that you leave two blank lines at the
-    top, or your message will be overwritten.

-

-

-
To add new users and groups, there are
-    useradd(8) and groupadd(8); see also
-    user(8) for further programs for user and group
-    manipulation. You may use vipw(8) to add users to the
-    /etc/passwd file and edit
-    /etc/group by hand to add new groups. The manual
-    page for su(1), tells you to make sure to put people in
-    the ‘wheel’ group if they need root access (non-Kerberos). For
-    example:

-

-
wheel:*:0:root,myself

-

-
Follow instructions for kerberos(8) if using
-    Kerberos for authentication.

-

-

-

-
/etc/rc and the
-    /etc/rc.d/* scripts are invoked at boot time after
-    single user mode has exited, and at shutdown. The whole process is
-    controlled by the master script /etc/rc. This script
-    should not be changed by administrators.

-
The directory /etc/rc.d contains a series
-    of scripts used at startup/shutdown, called by
-    /etc/rc. /etc/rc is in turn
-    influenced by the configuration variables present in
-    /etc/rc.conf.

-
The script /etc/rc.local is run as the
-    last thing during multiuser boot, and is provided to allow any other local
-    hooks necessary for the system.

-

-

-

-
To enable or disable various services on system startup,
-    corresponding entries can be made in /etc/rc.conf.
-    You can take a look at /etc/defaults/rc.conf to see
-    a list of default system variables, which you can override in
-    /etc/rc.conf. Note you are
-     supposed
-    to change /etc/defaults/rc.conf directly, edit only
-    /etc/rc.conf. See rc.conf(5) for
-    further information.

-

-

-

-
To use the amd(8) automounter, create the
-    /etc/amd directory, copy example config files from
-    /usr/share/examples/amd to
-    /etc/amd and customize them as needed.
-    Alternatively, you can get your maps with YP.

-

-

-

-
If you are using ccd(4) concatenated disks, edit
-    /etc/ccd.conf. You may wish to take a look to
-    ccdconfig(8) for more information about this file. Use the
-    ccdconfig -U command to unload and the
-    ccdconfig -C command to create tables internal to
-    the kernel for the concatenated disks. You then mount(8),
-    umount(8), and edit /etc/fstab as
-    needed.

-

-

-

-
npf(7) is the default firewall used on
-    NetBSD. You may wish to enable it if your machine is
-    connected directly to the internet. To do this, edit
-    /etc/npf.conf and set “npf=YES” in
-    /etc/rc.conf. Configuration examples for NPF can be
-    found in /usr/share/examples/npf. Before installing
-    a configuration, you can validate it with npfctl(8).

-

-

-

-
If you've installed X, you may want to turn on
-    xdm(1), the X Display Manager. To do this, set
-    “xdm=YES” in /etc/rc.conf.

-

-

-

-
Edit /etc/printcap and
-    /etc/hosts.lpd to get any printers set up. Consult
-    lpd(8) and printcap(5) if needed.

-

-

-

-
Various internet services can be enabled in
-    /etc/inetd.conf, including
-    httpd(8) and finger(1). Note that by
-    default all services are disabled for security reasons. Only add things that
-    are really needed.

-

-

-

-
If you are going to use Kerberos for authentication, see
-    kerberos(8) and “info heimdal” for more
-    information. If you already have a Kerberos master, change directory to
-    /etc/kerberosV and configure. Remember to get a
-    srvtab from the master so that the remote commands
-    work.

-

-

-

-
Check /etc/mail/aliases and update
-    appropriately if you want e-mail to be routed to non-local addresses or to
-    different users.

-
Run newaliases(1) after changes.

-

-

-

-
NetBSD uses Postfix as its Mail Transfer
-    Agent. Postfix is started by default, but its initial configuration does not
-    cause it to listen on the network for incoming connections. To configure
-    Postfix, see /etc/postfix/main.cf and
-    /etc/postfix/master.cf. If you wish to use a
-    different MTA (e.g., sendmail), install your MTA of choice and edit
-    /etc/mailer.conf to point to the proper
-  binaries.

-

-

-

-
If this is a DHCP server, edit
-    /etc/dhcpd.conf and
-    /etc/dhcpd.interfaces as needed. You will have to
-    make sure /etc/rc.conf has “dhcpd=YES”
-    or run dhcpd(8) manually.

-

-

-

-
If this is a Bootparam server, edit
-    /etc/bootparams as needed. You will have to turn it
-    on in /etc/rc.conf by adding
-    “bootparamd=YES”.

-

-

-

-
If this is an NFS server, make sure
-    /etc/rc.conf has:

-

-
nfs_server=YES
-mountd=YES
-rpcbind=YES

-

-
Edit /etc/exports and get it correct.
-    After this, you can start the server by issuing:

-

-
service rpcbind start
-service mountd start
-service nfsd start

-

-which will also start dependencies.
-

-

-

-
Edit /etc/rbootd.conf if needed for remote
-    booting. If you do not have HP computers doing remote booting, do not enable
-    this.

-

-

-

-
Look at and possibly edit the
-    /etc/daily.conf,
-    /etc/weekly.conf, and
-    /etc/monthly.conf configuration files. You can check
-    which values you can set by looking to their matching files in
-    /etc/defaults. Your site specific things should go
-    into /etc/daily.local,
-    /etc/weekly.local, and
-    /etc/monthly.local.

-
These scripts have been limited so as to keep the system running
-    without filling up disk space from normal running processes and database
-    updates. (You probably do not need to understand them.)

-

-

-

-
Look at the other files in /etc and edit
-    them as needed. (Do not edit files ending in .db
-    — like pwd.db,
-    spwd.db, nor localtime, nor
-    rmt, nor any directories.)

-

-

-

-
Check what is running by typing crontab -l
-    as root and see if anything unexpected is present. Do you need anything
-    else? Do you wish to change things? For example, if you do not like root
-    getting standard output of the daily scripts, and want only the security
-    scripts that are mailed internally, you can type crontab
-    -e and change some of the lines to read:

-

-
30  1  *  *  *   /bin/sh /etc/daily 2>&1 > /var/log/daily.out
-30  3  *  *  6   /bin/sh /etc/weekly 2>&1 > /var/log/weekly.out
-30  5  1  *  *   /bin/sh /etc/monthly 2>&1 > /var/log/monthly.out

-

-
See crontab(5).

-

-

-

-
After the first night's security run, change ownerships and
-    permissions on files, directories, and devices; root should have received
-    mail with subject: "<hostname> daily insecurity output.".
-    This mail contains a set of security recommendations, presented as a list
-    looking like this:

-

-
var/mail:
-        permissions (0755, 0775)
-etc/daily:
-        user (0, 3)

-

-
The best bet is to follow the advice in that list. The recommended
-    setting is the first item in parentheses, while the current setting is the
-    second one. This list is generated by mtree(8) using
-    /etc/mtree/special. Use chmod(1),
-    chgrp(1), and chown(8) as needed.

-

-

-

-

-
At this point, the system should be fully configured to your
-    liking. It is now a good time to ensure that the system behaves according to
-    its specifications and that it is stable on your hardware. Please refer to
-    tests(7) for details on how to do so.

-
You can use ps(1), netstat(1),
-    and fstat(1) to check on running processes, network
-    connections, and opened files, respectively. Other tools you may find useful
-    are systat(1) and top(1).

-

-

-

-
chgrp(1), chmod(1),
-    config(1), crontab(1),
-    date(1), df(1),
-    domainname(1), fstat(1),
-    hostname(1), make(1),
-    man(1), netstat(1),
-    newaliases(1), passwd(1),
-    pkg_add(1), ps(1),
-    ssh(1), su(1),
-    systat(1), top(1),
-    xdm(1), ccd(4),
-    aliases(5), crontab(5),
-    dhcpcd.conf(5), exports(5),
-    fstab(5), group(5),
-    hosts(5), ifconfig.if(5),
-    mailer.conf(5), named.conf(5),
-    nsswitch.conf(5), passwd(5),
-    printcap(5), rc.conf(5),
-    resolv.conf(5), sshd_config(5),
-    wpa_supplicant.conf(5), wscons.conf(5),
-    hier(7), hostname(7),
-    pkgsrc(7), tests(7),
-    amd(8), ccdconfig(8),
-    chown(8), devpubd(8),
-    dhcpcd(8), dhcpd(8),
-    dmesg(8), groupadd(8),
-    ifconfig(8), inetd(8),
-    kerberos(8), lpd(8),
-    mdnsd(8), mount(8),
-    mrouted(8), mtree(8),
-    named(8), nis(8),
-    ntpd(8), ntpdate(8),
-    rbootd(8), rc(8),
-    rdate(8), rmt(8),
-    route(8), rpc.bootparamd(8),
-    rpcbind(8), sshd(8),
-    timed(8), umount(8),
-    useradd(8), vipw(8),
-    wpa_cli(8), wpa_supplicant(8),
-    yp(8), ypbind(8)

-

-

-

-
This document first appeared in OpenBSD
-    2.2. It has been adapted to NetBSD and first
-    appeared in NetBSD 2.0.

-

-

-
-  
-    
-    
-  
-
June 4, 2021NetBSD 10.1

diff --git a/static/netbsd/man8/boot.8 4.html b/static/netbsd/man8/boot.8 4.html
deleted file mode 100644
index 6cc9571e..00000000
--- a/static/netbsd/man8/boot.8 4.html	
+++ /dev/null
@@ -1,223 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's ManualBOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
This document provides information on using common features in the
-    NetBSD boot loader. Additional information may be
-    found in architecture-specific boot(8) manual pages.

-

-

-
In the native NetBSD boot protocol,
-    options are passed from the boot loader to the kernel via flag bits in the
-    boothowto variable (see
-    boothowto(9)). Some boot loaders may also support other
-    boot protocols.

-

-

-
-
Some boot loaders may present a menu, which may be configured via
-    boot.cfg(5).

-

-

-

-
In interactive mode, the boot loader will present a prompt,
-    allowing input of these commands:

-

-

-  

-    [device:][filename]
-    [-1234abcdmqsvxz]

-  
The default device will be set to the disk that the
-      boot loader was loaded from. To boot from an alternate disk, the full name
-      of the device should be given at the prompt. device
-      is of the form xd
-      [N[x]] where
-      xd is the device from which to boot,
-      N is the unit number, and x is
-      the partition letter.
-    
The following list of supported devices may vary from
-        installation to installation:

-    

-    

-      
hd

-      
Hard disks.

-      
fd

-      
Floppy drives.

-    

-    
The default filename is
-        netbsd; if the boot loader fails to successfully
-        open that image, it then tries netbsd.gz
-        (expected to be a kernel image compressed by gzip), followed by
-        netbsd.old,
-        netbsd.old.gz, onetbsd,
-        and finally onetbsd.gz. Alternate system images
-        can be loaded by just specifying the name of the image.

-    
Options are:

-    

-      

-      
Sets the machine-dependent flag
-          
-          in boothowto.

-      

-      
Sets the machine-dependent flag
-          
-          in boothowto.

-      

-      
Sets the machine-dependent flag
-          
-          in boothowto.

-      

-      
Sets the machine-dependent flag
-          
-          in boothowto.

-      

-      
Sets the
-          
-          flag in boothowto. This causes the kernel to
-          prompt for the root file system device, the system crash dump device,
-          and the path to init(8).

-      

-      
Sets the
-          
-          flag in boothowto. This causes subsequent reboot
-          attempts to halt instead of rebooting.

-      

-      
Sets the
-          
-          flag in boothowto. This causes the kernel to
-          enter the userconf(4) device configuration manager
-          as soon as possible during the boot. userconf(4)
-          allows devices to be enabled or disabled, and allows device locators
-          (such as hardware addresses or bus numbers) to be modified before the
-          kernel attempts to attach the devices.

-      

-      
Sets the
-          
-          flag in boothowto. Requests the kernel to enter
-          debug mode, in which it waits for a connection from a kernel debugger;
-          see ddb(4).

-      

-      
Sets the
-          
-          flag in boothowto. Informs the kernel that a
-          mini-root file system is present in memory.

-      

-      
Sets the
-          
-          flag in boothowto. Boot the system in quiet
-          mode.

-      

-      
Sets the
-          
-          flag in boothowto. Boot the system in
-          single-user mode.

-      

-      
Sets the
-          
-          flag in boothowto. Boot the system in verbose
-          mode.

-      

-      
Sets the
-          
-          flag in boothowto. Boot the system with debug
-          messages enabled.

-      

-      
Sets the
-          
-          flag in boothowto. Boot the system in silent
-          mode.

-    

-  

-  

-    dev

-  
Immediately switch the console to the specified device
-      dev and reprint the banner.
-      dev must be one of pc,
-      com0, com1,
-      com2, com3,
-      com0kbd, com1kbd,
-      com2kbd, com3kbd, or
-      auto. See
-      Console Selection
-      Policy in x86/boot_console(8).

-  

-    [device]

-  
Set the default drive and partition for subsequent filesystem operations.
-      Without an argument, print the current setting.
-      device is of the form specified in
-      boot.

-  

-  
Print an overview about commands and arguments.

-  

-    [path]

-  
Print a directory listing of path, containing
-      inode number, filename, and file type. path can
-      contain a device specification.

-  

-  
Reboot the system.

-

-

-
In an emergency, the bootstrap methods described in the
-    NetBSD installation notes for the specific
-    architecture can be used.

-

-

-

-

-

-  
/boot

-  
boot program code loaded by the primary bootstrap

-  
/netbsd

-  
system code

-  
/netbsd.gz

-  
gzip-compressed system code

-  
/usr/mdec/boot

-  
master copy of the boot program (copy to /boot)

-  
/usr/mdec/bootxx_fstype

-  
primary bootstrap for filesystem type fstype, copied to the start of the
-      NetBSD partition by
-      installboot(8).

-

-

-

-

-
Architecture-specific boot(8) manual pages (such
-    as emips/boot(8), sparc64/boot(8),
-    x86/boot(8)), ddb(4),
-    userconf(4), halt(8),
-    installboot(8), reboot(8),
-    rescue(8), shutdown(8),
-    boothowto(9)

-

-

-

-
The kernel file name must be specified before, not after, the boot
-    options. Any filename specified after the boot
-    options, e.g.:

-

-

-
boot -d netbsd.test

-

-
is ignored, and the default kernel is booted.

-

-

-
-  
-    
-    
-  
-
August 16, 2014NetBSD 10.1

diff --git a/static/netbsd/man8/compat_30.8 4.html b/static/netbsd/man8/compat_30.8 4.html
deleted file mode 100644
index 8126cf11..00000000
--- a/static/netbsd/man8/compat_30.8 4.html	
+++ /dev/null
@@ -1,145 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_30(8)System Manager's ManualCOMPAT_30(8)

-

-

-

-
compat_30 — setup
-    procedure for backward compatibility on post-3.0 releases

-

-

-

-
options COMPAT_30

-

-

-

-
The compat_30 module allows
-    NetBSD to run NetBSD 3.0
-    executables.

-
The support is present if the kernel was built with option
-    COMPAT_30. It is not available as a loadable
-  module.

-
Static executables typically need no additional setup. Dynamic
-    binaries may require shared libraries whose major version number changed
-    since NetBSD 3.0, which are listed below. A shadow
-    directory under /emul is not used; the libraries can
-    be obtained from a NetBSD 3.0 distribution and
-    installed in the original directories shown, as the major version number in
-    the file name will prevent conflicts. If an upgrade installation from
-    NetBSD 3.0 has been done and these libraries are
-    still present, nothing more need be done.

-

-

-
    
-  
  • /lib/libcrypto.so.2.1
-      /lib/libcrypto.so.2
    • 
-  
  • /usr/lib/libcrypto.so.2.1
-      /usr/lib/libcrypto.so.2
    • 
-  
  • /lib/libevent.so.0.2
-      /lib/libevent.so.0
    • 
-  
  • /usr/lib/libevent.so.0.2
-      /usr/lib/libevent.so.0
    • 
-  
  • /usr/lib/libg2c.so.2.0
-      /usr/lib/libg2c.so.2
    • 
-  
  • /usr/lib/libkadm.so.5.0
-      /usr/lib/libkadm.so.5
    • 
-  
  • /usr/lib/libkafs.so.6.0
-      /usr/lib/libkafs.so.6
    • 
-  
  • /usr/lib/libkdb.so.5.0
-      /usr/lib/libkdb.so.5
    • 
-  
  • /usr/lib/libkrb5.so.19.1
-      /usr/lib/libkrb5.so.19
    • 
-  
  • /usr/lib/libkrb.so.6.0
-      /usr/lib/libkrb.so.6
    • 
-  
  • /usr/lib/libkstream.so.2.0
-      /usr/lib/libkstream.so.2
    • 
-  
  • /usr/lib/libmagic.so.0.1
-      /usr/lib/libmagic.so.0
    • 
-  
  • /usr/lib/libpcap.so.1.4
-      /usr/lib/libpcap.so.1
    • 
-  
  • /lib/libradius.so.0.0
-      /lib/libradius.so.0
    • 
-  
  • /usr/lib/libradius.so.0.0
-      /usr/lib/libradius.so.0
    • 
-  
  • /usr/lib/libssh.so.1.0
-      /usr/lib/libssh.so.1
    • 
-  
  • /usr/lib/libssl.so.3.0
-      /usr/lib/libssl.so.3
    • 
-  
  • /usr/lib/libstdc++.so.5.0
-      /usr/lib/libstdc++.so.5
    • 
-  
  • /lib/libz.so.0.4
-      /lib/libz.so.0
    • 
-  
  • /usr/lib/libz.so.0.4
-      /usr/lib/libz.so.0
    • 
-  
  • /usr/lib/libamu.so.2.1
-      /usr/lib/libamu.so.2
    • 
-

-

-

-

-

-
COMPAT_30 enables the
-    NetBSD 3.0 versions of the following system calls,
-    whose syscall numbers and argument structures were changed after the 3.0
-    release to accommodate 64-bit filesystems: fhstat(2),
-    fstat(2), getdents(2),
-    lstat(2), stat(2).

-
The filehandle structure (formerly
-    fhandle_t) was made opaque to userland and
-    variable-sized. A fh_size argument was added to
-    related syscalls: fhstat(2),
-    fhstatvfs(2), fhstatvfs1(2),
-    fhopen(2), getfh(2). This changes the
-    API and ABI of those syscalls, COMPAT_30 enables
-    binary compatibility with the old ABI. Source compatibility is not provided,
-    as use of those syscalls is supposed to be rare.

-
The error code from the socket(2) syscall
-    changed from EPROTONOSUPPORT to
-    EAFNOSUPPORT in the case of an unsupported address
-    family. COMPAT_30 enables binary compatibility with
-    the old ABI. Source compatibility is not provided.

-
The struct ntptimeval used by
-    ntp_gettime(2) changed with the implementation of
-    timecounters.

-

-

-

-
config(1), fhstat(2),
-    fstat(2), getdents(2),
-    lstat(2), stat(2),
-    options(4)

-

-

-

-
NetBSD offers back-compatibility options
-    back to NetBSD 0.9, but the first to be documented
-    with a manual page is compat_30.

-

-

-

-
The compatible getdents(2) is unable to see
-    directory entries beneath the top layer of a union, even though the real 3.0
-    getdents() did not have that problem.

-

-

-

-
Programs with security impact that receive incorrect directory
-    contents from getdents() may behave improperly, as
-    when they are unable to find, or find the wrong versions of, important
-    files.

-

-

-
-  
-    
-    
-  
-
December 15, 2007NetBSD 10.1

diff --git a/static/netbsd/man8/compat_bsdos.8 4.html b/static/netbsd/man8/compat_bsdos.8 4.html
deleted file mode 100644
index dad249b8..00000000
--- a/static/netbsd/man8/compat_bsdos.8 4.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_BSDOS(8)System Manager's ManualCOMPAT_BSDOS(8)

-

-

-

-
compat_bsdos —
-    binary compatibility for BSDi releases

-

-

-

-
The COMPAT_NOMID kernel option includes
-    compatibility with
-    BSDi 1.x–3.x
-    a.out(5) binaries on NetBSD/i386
-    and NetBSD/amd64. The option is enabled by default
-    in the GENERIC kernel on i386, but needs to be set
-    along with EXEC_AOUT on amd64.

-
Null memory protection must be disabled with the
-    sysctl(7) option vm.user_va0_disable
-    set to 0 for the binaries to run successfully.

-
BSD/OS binaries may be placed under
-    /emul directory to match the location of other
-    non-native executables on NetBSD, but the
-    compatibility environment does not automatically lookup libraries under
-    /emul/bsdos as happens with the shared libraries for
-    NetBSD 1.0–1.5 a.out(5)
-    binaries under /emul/aout.

-
BSD/386 1.0–1.1 uses static
-    binaries that do not dynamically load libraries at runtime.

-
BSD/OS 2.0 introduced “static
-    shared libraries” as the default for standard binaries. The shared
-    libraries are compiled from /lib and
-    /usr/lib to a custom format bound to memory loading
-    addresses for each library under /shlib. BSDi
-    libraries under /shlib are not in the standard
-    ar(5) or position-independent shared object formats and
-    cannot be loaded by ldconfig(8) on
-    NetBSD. In order for BSDi executables to access the
-    objects at the hardcoded /shlib path, the user may
-    setup a symbolic link from /shlib to
-    /emul/bsdos/shlib.

-
BSD/OS 4.0 switched to an ELF binary
-    executable format that does not run under the compatibility layers currently
-    available on NetBSD.

-

-

-

-
ld.aout_so(1), options(4),
-    a.out(5), elf(5),
-    sysctl(7), compat_netbsd32(8),
-    ldconfig(8)

-

-

-

-
BSD/386 1.0–1.1 was derived
-    from 4.3BSD Reno code in the Net/2 release.

-
BSD/OS 2.0 was based on
-    4.4BSD Lite, but added the new static shared library
-    format as the runtime default for executables. The build system included the
-    shlicc command with the
-    -Bstatic flag that allowed reverting to the standard
-    library archive format that remained available under
-    /lib and /usr/lib.

-
NetBSD 1.0 added shared libraries using a
-    standard position-independent shared object format. The previous default
-    relocatable libraries in the traditional ar(5) format
-    remained available.

-
OpenBSD 2.2–4.7 included a
-    different compatibility implementation under the
-    COMPAT_BSDOS kernel option.

-

-

-

-
BSD/OS compatibility was broken on
-    NetBSD 5–6.

-
BSD/OS 3.0 added SPARC support, but the
-    binaries are incorrectly recognized as SunOS executables and fail on
-    NetBSD/sparc and
-    NetBSD/sparc64.

-

-

-
-  
-    
-    
-  
-
August 27, 2020NetBSD 10.1

diff --git a/static/netbsd/man8/compat_freebsd.8 4.html b/static/netbsd/man8/compat_freebsd.8 4.html
deleted file mode 100644
index 53475343..00000000
--- a/static/netbsd/man8/compat_freebsd.8 4.html	
+++ /dev/null
@@ -1,258 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_FREEBSD(8)System Manager's ManualCOMPAT_FREEBSD(8)

-

-

-

-
compat_freebsd —
-    setup procedure for running FreeBSD binaries

-

-

-

-
compat_freebsd is not maintained anymore, and new FreeBSD
-  binaries cannot be expected to work. The compat_freebsd feature is available
-  in NetBSD only to support the FreeBSD tw_cli driver.

-
NetBSD supports running
-    FreeBSD binaries. Most binaries should work, except
-    programs that use FreeBSD-specific features. These
-    include i386-specific calls, such as syscons utilities. The
-    FreeBSD compatibility feature is active for kernels
-    compiled with the COMPAT_FREEBSD option enabled.

-
A lot of programs are dynamically linked. This means, that you
-    will also need the FreeBSD shared libraries that the
-    program depends on, and the runtime linker. Also, you will need to create a
-    “shadow root” directory for FreeBSD
-    binaries on your NetBSD system. This directory is
-    named /emul/freebsd. Any file operations done by
-    FreeBSD programs run under
-    NetBSD will look in this directory first. So, if a
-    FreeBSD program opens, for example,
-    /etc/passwd, NetBSD will
-    first try to open /emul/freebsd/etc/passwd, and if
-    that does not exist open the ‘real’
-    /etc/passwd file. It is recommended that you install
-    FreeBSD packages that include configuration files,
-    etc under /emul/freebsd, to avoid naming conflicts
-    with possible NetBSD counterparts. Shared libraries
-    should also be installed in the shadow tree.

-
Generally, you will need to look for the shared libraries that
-    FreeBSD binaries depend on only the first few times
-    that you install a FreeBSD program on your
-    NetBSD system. After a while, you will have a
-    sufficient set of FreeBSD shared libraries on your
-    system to be able to run newly imported FreeBSD
-    binaries without any extra work.

-

-

-
How to get to know which shared libraries
-    FreeBSD binaries need, and where to get them?
-    Basically, there are 2 possibilities (when following these instructions: you
-    will need to be root on your NetBSD system to do the
-    necessary installation steps).

-

-
    
-  
  1. You have access to a FreeBSD system. In this case
-      you can temporarily install the binary there, see what shared libraries it
-      needs, and copy them to your NetBSD system.
-      Example: you have just ftp-ed the FreeBSD binary
-      of SimCity. Put it on the FreeBSD system you have
-      access to, and check which shared libraries it needs by running
-      ‘ldd sim’:
-    
    
-    
    me@freebsd% ldd /usr/local/lib/SimCity/res/sim
-/usr/local/lib/SimCity/res/sim:
-	-lXext.6 => /usr/X11R6/lib/libXext.so.6.0 (0x100c1000)
-	-lX11.6 => /usr/X11R6/lib/libX11.so.6.0 (0x100c9000)
-	-lc.2 => /usr/lib/libc.so.2.1 (0x10144000)
-	-lm.2 => /usr/lib/libm.so.2.0 (0x101a7000)
-	-lgcc.261 => /usr/lib/libgcc.so.261.0 (0x101bf000)
    
-    
    
-    
    You would need go get all the files from the last column, and
-        put them under /emul/freebsd. This means you
-        eventually have these files on your NetBSD
-        system:
    
-    
      
-      
    • /emul/freebsd/usr/X11R6/lib/libXext.so.6.0
      • 
-      
    • /emul/freebsd/usr/X11R6/lib/libX11.so.6.0
      • 
-      
    • /emul/freebsd/usr/lib/libc.so.2.1
      • 
-      
    • /emul/freebsd/usr/lib/libm.so.2.0
      • 
-      
    • /emul/freebsd/usr/lib/libgcc.so.261.0
      • 
-    
    
-    
    Note that if you already have a
-        FreeBSD shared library with a matching major
-        revision number to the first column of the ldd
-        output, you won't need to copy the file named in the last column to your
-        system, the one you already have should work. It is advisable to copy
-        the shared library anyway if it is a newer version, though. You can
-        remove the old one. So, if you have these libraries on your system:
    
-    
      
-      
    • /emul/freebsd/usr/lib/libc.so.2.0
      • 
-    
    
-    
    and you find that the ldd output for a new binary you want to
-        install is:
    
-    
    
-    
    -lc.2 => /usr/lib/libc.so.2.1 (0x10144000)
    
-    
    
-    
    You won't need to worry about copying
-        /usr/lib/libc.so.2.1 too, because the program
-        should work fine with the slightly older version. You can decide to
-        replace the libc.so anyway, and that should leave you with:
    
-    
      
-      
    • /emul/freebsd/usr/lib/libc.so.2.1
      • 
-    
    
-    
    Finally, you must make sure that you have the
-        FreeBSD runtime linker and its config files on
-        your system. You should copy these files from the
-        FreeBSD system to their appropriate place on
-        your NetBSD system (in the
-        /emul/freebsd tree):
    
-    
      
-      
    • usr/libexec/ld.so
      • 
-      
    • var/run/ld.so.hints
      • 
-    
    
-  
    2. 
-  
  2. You don't have access to a FreeBSD system. In that
-      case, you should get the extra files you need from various ftp sites.
-      Information on where to look for the various files is appended below. For
-      now, let's assume you know where to get the files.
-    
    Retrieve the following files (from _one_ ftp site to avoid any
-        version mismatches), and install them under
-        /emul/freebsd (i.e.
-        foo/bar is installed as
-        /emul/freebsd/foo/bar):
    
-    
      
-      
    • sbin/ldconfig
      • 
-      
    • usr/bin/ldd
      • 
-      
    • usr/lib/libc.so.x.y.z
      • 
-      
    • usr/libexec/ld.so
      • 
-    
    
-    
    ldconfig and
-        ldd don't necessarily need to be under
-        /emul/freebsd, you can install them elsewhere in
-        the system too. Just make sure they don't conflict with their
-        NetBSD counterparts. A good idea would be to
-        install them in /usr/local/bin as
-        ldconfig-freebsd and
-        ldd-freebsd.
    
-    
    Run the FreeBSD ldconfig program with
-        directory arguments in which the FreeBSD runtime
-        linker should look for shared libs. /usr/lib are
-        standard, you could run like the following:
    
-    
    
-    
    me@netbsd% mkdir -p /emul/freebsd/var/run
-me@netbsd% touch /emul/freebsd/var/run/ld.so.hints
-me@netbsd% ldconfig-freebsd /usr/X11R6/lib /usr/local/lib
    
-    
    
-    
    Note that argument directories of ldconfig are mapped to
-        /emul/freebsd/XXXX by
-        NetBSD's compat code, and should exist as such
-        on your system. Make sure
-        /emul/freebsd/var/run/ld.so.hints is existing
-        when you run FreeBSD's ldconfig, if not, you may
-        lose NetBSD's
-        /var/run/ld.so.hints.
-        FreeBSD ldconfig should
-        be statically linked, so it doesn't need any shared libraries by itself.
-        It will create the file
-        /emul/freebsd/var/run/ld.so.hints. You should
-        rerun the FreeBSD version of the ldconfig
-        program each time you add a new shared library.
    
-    
    You should now be set up for FreeBSD
-        binaries which only need a shared libc. You can test this by running the
-        FreeBSD ldd on itself.
-        Suppose that you have it installed as
-        ldd-freebsd, it should produce something
-      like:
    
-    
    
-    
    me@netbsd% ldd-freebsd `which ldd-freebsd`
-/usr/local/bin/ldd-freebsd:
-	-lc.2 => /usr/lib/libc.so.2.1 (0x1001a000)
    
-    
    
-    
    This being done, you are ready to install new
-        FreeBSD binaries. Whenever you install a new
-        FreeBSD program, you should check if it needs
-        shared libraries, and if so, whether you have them installed in the
-        /emul/freebsd tree. To do this, you run the
-        FreeBSD version ldd on
-        the new program, and watch its output. ldd (see
-        also the manual page for ldd(1)) will print a list of
-        shared libraries that the program depends on, in the form
-        -l<majorname> => <fullname>.
    
-    
    If it prints “not found” instead of
-        <fullname> it means that you need an extra library. Which library
-        this is, is shown in <majorname>, which will be of the form
-        XXXX.<N> You will need to find a libXXXX.so.<N>.<mm>
-        on a FreeBSD ftp site, and install it on your
-        system. The XXXX (name) and <N> (major revision number) should
-        match; the minor number(s) <mm> are less important, though it is
-        advised to take the most recent version.
    
-    
    
-  
    3. 
-  
  3. In some cases, FreeBSD binary needs access to
-      certain device file. For example, FreeBSD X server
-      software needs FreeBSD
-      /dev/ttyv0 for ioctls. In this case, create a
-      symbolic link from /emul/freebsd/dev/ttyv0 to a
-      wscons(4) device file like
-      /dev/ttyE0. You will need to have at least
-      options WSDISPLAY_COMPAT_SYSCONS and probably also
-      options WSDISPLAY_COMPAT_USL in your kernel (see
-      options(4) and wscons(4)).
    4. 
-

-

-

-

-
:
-    the information below is valid as of the time this document was written
-    (June, 1995), but certain details such as names of ftp sites, directories
-    and distribution names may have changed by the time you read this.

-
The FreeBSD distribution is available on a
-    lot of ftp sites. Sometimes the files are unpacked, and you can get the
-    individual files you need, but mostly they are stored in distribution sets,
-    usually consisting of subdirectories with gzipped tar files in them. The ftp
-    site for the distributions is:
-    ftp://ftp.FreeBSD.org/pub/FreeBSD

-
This distribution consists of a number of tar-ed and gzipped
-    files, Normally, they're controlled by an install program, but you can
-    retrieve files “by hand” too. The way to look something up is
-    to retrieve all the files in the distribution, and ``tar ztvf'' through them
-    for the file you need. Here is an example of a list of files that you might
-    need.

-

-
Needed                 Files
-
-ld.so                  2.0-RELEASE/bindist/bindist.??
-ldconfig               2.0-RELEASE/bindist/bindist.??
-ldd                    2.0-RELEASE/bindist/bindist.??
-libc.so.2              2.0-RELEASE/bindist/bindist.??
-libX11.so.6.0          2.0-RELEASE/XFree86-3.1/XFree86-3.1-bin.tar.gz
-libX11.so.6.0          XFree86-3.1.1/X311bin.tgz
-libXt.so.6.0           2.0-RELEASE/XFree86-3.1/XFree86-3.1-bin.tar.gz
-libXt.so.6.0           XFree86-3.1.1/X311bin.tgz

-

-
The files called “bindist.??” are tar-ed, gzipped
-    and split, so you can extract contents by “cat bindist.?? | tar zpxf
-    -”.

-
Extract the files from these gzipped tarfiles in your
-    /emul/freebsd directory (possibly omitting or
-    afterwards removing files you don't need), and you are done.

-

-

-

-

-
The information about FreeBSD
-    distributions may become outdated.

-

-

-
-  
-    
-    
-  
-
February 10, 2018NetBSD 10.1

diff --git a/static/netbsd/man8/compat_linux.8 4.html b/static/netbsd/man8/compat_linux.8 4.html
deleted file mode 100644
index 803a4867..00000000
--- a/static/netbsd/man8/compat_linux.8 4.html	
+++ /dev/null
@@ -1,161 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_LINUX(8)System Manager's ManualCOMPAT_LINUX(8)

-

-

-

-
compat_linux —
-    setup procedure for running Linux binaries

-

-

-

-
NetBSD supports running Linux binaries.
-    This applies to aarch64, alpha, amd64, arm, i386, m68k, and powerpc systems
-    for now. Both the a.out and ELF binary formats are supported. Most programs
-    should work. NetBSD aarch64 and amd64 can execute
-    both 32-bit and 64-bit Linux programs. Programs that will not work include
-    some that use i386-specific calls, such as enabling virtual 8086 mode.
-    Currently, sound is supported through OSSv3 compat.

-
The Linux compatibility feature is active for kernels compiled
-    with the COMPAT_LINUX option enabled. If support for
-    Linux a.out executables is desired, the EXEC_AOUT
-    option should be enabled in addition to option
-    COMPAT_LINUX. Similarly, if support for Linux 32-bit
-    and/or 64-bit ELF executables is desired, the
-    EXEC_ELF32 and/or EXEC_ELF64
-    options (respectively) should be enabled in addition to
-    COMPAT_LINUX. If sound support is desired,
-    COMPAT_OSSAUDIO should be enabled.

-
A lot of programs are dynamically linked. This means that you will
-    also need the Linux shared libraries that the program depends on, and the
-    runtime linker. Also, you will need to create a “shadow root”
-    directory for Linux binaries on your NetBSD system.
-    This directory is named /emul/linux or
-    /emul/linux32 for 32-bit emulation on 64-bit
-    systems. Any file operations done by Linux programs run under
-    NetBSD will look in this directory first. So, if a
-    Linux program opens, for example, /etc/passwd,
-    NetBSD will first try to open
-    /emul/linux/etc/passwd, and if that does not exist
-    open the ‘real’ /etc/passwd file. It
-    is recommended that you install Linux packages that include configuration
-    files, etc under /emul/linux, to avoid naming
-    conflicts with possible NetBSD counterparts. Shared
-    libraries should also be installed in the shadow tree. Filenames that start
-    "/../" are only looked up in the real root.

-
Generally, you will need to look for the shared libraries that
-    Linux binaries depend on only the first few times that you install a Linux
-    program on your NetBSD system. After a while, you
-    will have a sufficient set of Linux shared libraries on your system to be
-    able to run newly imported Linux binaries without any extra work.

-

-

-
Find the dependencies of a Linux binary using
-    readelf(1):

-

-
$ readelf -d ./runner | grep Shared
- 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
- 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libXxf86vm.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libGL.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libopenal.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
- 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
- 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
- 0x00000001 (NEEDED)                     Shared library: [libcrypto.so.1.0.0]
- 0x00000001 (NEEDED)                     Shared library: [libXext.so.6]
- 0x00000001 (NEEDED)                     Shared library: [libX11.so.6]
- 0x00000001 (NEEDED)                     Shared library: [libXrandr.so.2]
- 0x00000001 (NEEDED)                     Shared library: [libGLU.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libssl.so.1.0.0]
- 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
- 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

-

-
For x86, you can simply install the openSUSE shared libraries
-    using the pkgsrc/emulators/suse131_* or
-    pkgsrc/emulators/suse131_32_* packages.

-
For example, an application which requires
-    libcrypto.so.1.0.0,
-    libXext.so.6, and libGL.so.1
-    will require openssl, x11,
-    and glx, in addition to the
-    base SUSE package.

-
Otherwise, you may have to obtain shared libraries from another
-    Linux system, and copy them to e.g.
-    /emul/linux/lib64.

-

-

-

-
Some Linux binaries expect procfs to be mounted and that it
-    contains some Linux-specific extensions. If it's not the case, they behave
-    unexpectedly or even crash.

-
Mount procfs on NetBSD using following
-    command:

-

-

-  
$ mount_procfs procfs /emul/linux/proc

-  
 

-

-

-
You can also set up your system so that procfs is mounted
-    automatically on system boot, by putting an entry like the one below to
-    /etc/fstab.

-

-

-  
procfs /emul/linux/proc procfs ro

-  
 

-

-

-
Note: mount_procfs(8) defaults to Linux flavored
-    procfs since NetBSD 5.0. Ensure you do not mount
-    procfs with nolinux.

-
See mount_procfs(8) for further information.

-

-

-

-
Newer version of Linux use
-    /etc/nsswitch.conf for network information, such as
-    NIS and DNS. You must create or get a valid copy of this file and put it in
-    /emul/linux/etc.

-

-

-

-

-
compat_linux is generally not enabled in
-    GENERIC kernels for security reasons, but is
-    available as a module. It must be added to modules.conf(5)
-    to be used. It will not be loaded automatically.

-

-

-

-
The information about Linux distributions will become
-  outdated.

-
Absolute pathnames pointed to by symbolic links are only looked up
-    in the shadow root when the symbolic link itself was found by an absolute
-    pathname inside the shadow root. This is not consistent.

-
Linux executables cannot handle directory offset cookies > 32
-    bits. Should such an offset occur, you will see the message
-    “linux_getdents: dir offset too large for emulated program”.
-    Currently, this can only happen on NFS mounted file systems, mounted from
-    servers that return offsets with information in the upper 32 bits. These
-    errors should rarely happen, but can be avoided by mounting this file system
-    with offset translation enabled. See the -X option
-    to mount_nfs(8). The -2 option to
-    mount_nfs(8) will also have the desired effect, but is
-    less preferable.

-

-

-
-  
-    
-    
-  
-
September 26, 2021NetBSD 10.1

diff --git a/static/netbsd/man8/compat_netbsd32.8 4.html b/static/netbsd/man8/compat_netbsd32.8 4.html
deleted file mode 100644
index 11755c86..00000000
--- a/static/netbsd/man8/compat_netbsd32.8 4.html	
+++ /dev/null
@@ -1,109 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_NETBSD32(8)System Manager's ManualCOMPAT_NETBSD32(8)

-

-

-

-
compat_netbsd32 —
-    setup procedure for 32-bit compatibility on 64-bit
-    platforms

-

-

-

-
The compat_netbsd32 module allows
-    NetBSD/sparc64 to run
-    NetBSD/sparc executables,
-    NetBSD/aarch64 to run
-    NetBSD/arm executables,
-    NetBSD/mips64 to run
-    NetBSD/mips executables, and
-    NetBSD/amd64 to run
-    NetBSD/i386 executables. On
-    NetBSD/mips64 the default userland is N32 which is a
-    handled by compat_netbsd32 framework, and 64-bit
-    binaries are handled similarly to the setup for 32-bit compatibility. It
-    also provides compatibility between OABI and EABI binaries on 32-bit
-    NetBSD/arm ports.

-
To use compat_netbsd32, one must either
-    have COMPAT_NETBSD32 and
-    EXEC_ELF32 in the kernel, or load the
-    compat_netbsd32 and exec_elf32 kernel modules.

-
Static executables typically need no additional setup. Dynamic
-    binaries require the dynamic linker plus shared libraries.

-
Since NetBSD 5.0 the base system has
-    directly included support for 32-bit compatibility by installing 32-bit
-    libraries and dynamic linker into /usr. This
-    includes compiler support for compiling 32-bit applications on platforms
-    where this is supported.

-
For a.out compatibility,
-    /usr/libexec/ld.so from a 32-bit distribution is
-    required to exist, and the a.out shared libraries must be found in
-    /emul/aout as normal for a.out compatibility. For
-    32-bit (64-bit on NetBSD/mips64) ELF compatibility,
-    the relevant /usr/libexec/ld.elf_so needs to be
-    found in

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
i386/usr/libexec/ld.elf_so-i386
sparc/usr/libexec/ld.elf_so-sparc
O32/usr/libexec/ld.elf_so-o32
N64/usr/libexec/ld.elf_so-64
powerpc/usr/libexec/ld.elf_so-powerpc
eabi/usr/libexec/ld.elf_so-eabi

-
Note that the kernel handles rewriting the built-in ELF
-    interpreter to the above path.

-
Before NetBSD 5.0 all of these files
-    needed to be placed under /emul/netbsd32.

-
The shared libraries for a.out binaries do not live under the
-    /emul/netbsd32 directory, but under the
-    /emul/aout directory, where the a.out dynamic linker
-    will find them.

-

-

-

-
A list of things which fail to work in compatibility mode should
-    be here.

-
aio(3) is not supported.

-
Some ioctl(2) commands are not supported,
-    including drm(4).

-

-

-
-  
-    
-    
-  
-
January 17, 2019NetBSD 10.1

diff --git a/static/netbsd/man8/compat_sunos.8 4.html b/static/netbsd/man8/compat_sunos.8 4.html
deleted file mode 100644
index 4acb2888..00000000
--- a/static/netbsd/man8/compat_sunos.8 4.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_SUNOS(8)System Manager's ManualCOMPAT_SUNOS(8)

-

-

-

-
compat_sunos —
-    setup procedure for m68k, sparc and sparc64
-    architectures

-

-

-

-
NetBSD/sparc64,
-    NetBSD/sparc and some of the
-    NetBSD/m68k architectures can run SunOS executables.
-    Most executables will work.

-
The exceptions include programs that use the SunOS kvm
-    library, and various system calls,
-    ()'s, or
-    kernel semantics that are difficult to emulate. The number of reasons why a
-    program might fail to work is (thankfully) longer than the number of
-    programs that fail to run.

-
Static executables will normally run without any extra setup. This
-    procedure details the directories and files that must be set up to allow
-    dynamically linked executables to work.

-
The files you need are on your SunOS machine. You need to worry
-    about the legal issues of ensuring that you have a right to use the required
-    files on your machine. On your NetBSD machine, do
-    the following:

-
    
-  
    2. 
-  
    3. 
-  
    4. 
-  
    5. 
-  
  5. If you ever expect to use YP, you will want to create a link:
-    
    
-    
    ln -s /var/run/ypbind.lock /etc/ypbind.lock
    
-    
    
-  
    6. 
-

-
Alternatively, you can use an NFS mount to accomplish the same
-    effect. On your NetBSD machine, do the
-  following:

-
    
-  
    2. 
-  
    3. 
-

-
This will place the SunOS libraries on your
-    NetBSD machine in a location where the SunOS
-    compatibility code will look for first, where they do not conflict with the
-    standard libraries.

-

-

-

-
When using compat_sunos on
-    NetBSD/sparc64, the
-    COMPAT_NETBSD32 option must also be used.

-

-

-

-
A list of things which fail to work in compatibility mode should
-    be here.

-
SunOS executables can not handle directory offset cookies > 32
-    bits. Should such an offset occur, you will see the message
-    “sunos_getdents: dir offset too large for emulated program”.
-    Currently, this can only happen on NFS mounted filesystems, mounted from
-    servers that return offsets with information in the upper 32 bits. These
-    errors should rarely happen, but can be avoided by mounting this filesystem
-    with offset translation enabled. See the -X option
-    to mount_nfs(8). The -2 option to
-    mount_nfs(8) will also have the desired effect, but is
-    less preferable.

-
The NetBSD/sparc64 support is less
-    complete than the other ports.

-

-

-
-  
-    
-    
-  
-
February 3, 2001NetBSD 10.1

diff --git a/static/netbsd/man8/compat_ultrix.8 4.html b/static/netbsd/man8/compat_ultrix.8 4.html
deleted file mode 100644
index f4275366..00000000
--- a/static/netbsd/man8/compat_ultrix.8 4.html	
+++ /dev/null
@@ -1,106 +0,0 @@
-
-  
-    
-    
-    
-  
-
COMPAT_ULTRIX(8)System Manager's ManualCOMPAT_ULTRIX(8)

-

-

-

-
compat_ultrix —
-    setup procedure for ULTRIX compatibility on MIPS and VAX
-    architectures

-

-

-

-
NetBSD/mips and
-    NetBSD/vax architectures can run Risc ULTRIX and VAX
-    ULTRIX executables, respectively. However, you have to worry about the legal
-    issues of ensuring that you have a right to use any ULTRIX binaries on your
-    machine.

-
Most executables will work. The exceptions include
-    programs that use proprietary, ULTRIX-specific features (LAT, CI support,
-    DECnet support) and various system calls,
-    ()'s, or
-    ULTRIX kernel semantics that are difficult to emulate (e.g. ULTRIX
-    packetfilter) or buggy (e.g. ULTRIX NIS).

-
All ULTRIX executables are static, so no shared libraries are
-    required for ULTRIX compatibility. However, ULTRIX is based on a
-    4.3BSD alpha release. ULTRIX commands and libraries
-    are often much older than their NetBSD or even SunOS
-    4.x equivalents, and may require incompatible configuration files.

-

-

-

-
Set up resolv.conf and
-    svc.conf as below:

-

-

-

-  
# mkdir -p /emul/ultrix/etc

-  

-    

-  

-  
# cd /emul/ultrix/etc

-  

-    

-  

-  
# egrep 'domain|nameserver' /etc/resolv.conf > ./resolv.conf

-  

-    

-  

-  
# cp -p /usr/share/examples/emul/ultrix/etc/*	./

-  
 

-

-

-

-

-
The ULTRIX resolver library only understands
-    
-    and
-    
-    lines in resolv.conf(5). You should create a copy of
-    /etc/resolv.conf containing only those commands and
-    put it in /emul/ultrix/etc/resolv.conf. Note that
-    the domain search order used by ULTRIX executables may not be the same as
-    native binaries; there is no good way around this.

-

-

-

-
ULTRIX uses /etc/svc.conf to select an
-    ordered search of NIS, Hesiod, or local flat-file mappings. You should
-    create an /emul/ultrix/etc/svc.conf specifying
-    either local files or bind (DNS) lookups for all ULTRIX name services.

-

-

-

-

-
resolv.conf(5)

-

-

-

-
RISC ULTRIX NIS (YP) is known to not work. The ULTRIX NIS
-    libraries have a consistent endian-ness bug. ULTRIX NIS client will not
-    inter-operate with the NetBSD
-    ypbind(8) process. The only workaround is to use
-    /etc/svc.conf to disable NIS (YP).

-
The ndbm hashed-password file used by ULTRIX are incompatible with
-    the db hashed-password file used by NetBSD. There is
-    no good solution for this. NIS would be a good one, if ULTRIX NIS
-  worked.

-
The API used by Xservers to talk to the kernel is currently
-    compatible with ULTRIX 4.1. An implementation of the ULTRIX 4.2 Xws
-    interface (used by X11R6) is in progress.

-
A complete list of things which fail to work in ULTRIX
-    compatibility mode should be added here.

-

-

-
-  
-    
-    
-  
-
January 16, 1999NetBSD 10.1

diff --git a/static/netbsd/man8/creds_msdos.8 4.html b/static/netbsd/man8/creds_msdos.8 4.html
deleted file mode 100644
index a9d37cce..00000000
--- a/static/netbsd/man8/creds_msdos.8 4.html	
+++ /dev/null
@@ -1,99 +0,0 @@
-
-  
-    
-    
-    
-  
-
CREDS_MSDOS(8)System Manager's ManualCREDS_MSDOS(8)

-

-

-

-
creds_msdos —
-    automatically add login credentials from MS-DOS
-    partition

-

-

-

-
-  
-    
-    
-  
-
creds_msdosstart

-

-

-

-
The creds_msdos rc.d script allows
-    automatic addition of login credentials during boot using a special file
-    found on the MS-DOS partition of a bootable image. This script is not
-    distributed with the normal system and is only included with pre-installed
-    bootable images. The goal is to allow remote access of the system without
-    having to edit the primary root file system (which may not be accessible
-    from the host the image is being written from), but place this information
-    in the MS-DOS partition that most platforms can easily access.

-
Typically, an installable image (such as
-    arm64.img) is written to an SD card or similar
-    media, and has both a native FFS partition as well as an MS-DOS partition
-    for booting. If this script is enabled and has been pointed at the boot
-    partition it will inspect the file creds.txt for any
-    credentials to be added to the system.

-
The following list gives the supported options in the credentials
-    files. In all cases user is the username to be
-    created, and the user will be added to the
-    ‘wheel’ group.

-

-  

-    user keyfile

-  
Look for the keyfile in the MS-DOS boot partition
-      and merge ssh keys from this file into user's
-      ~/.ssh/authorized_keys file.

-  

-    user keystring

-  
Add the keystring to the user's
-      ~/.ssh/authorized_keys file.

-  

-    user pwhash

-  
Use pwhash as the users's password hash.

-  

-    user password

-  
Use password as the users's unencrypted raw password
-      that will be hashed.
-    
This method is
-        
-        as it leaves unencrypted passwords around until such time that the
-        script runs. If this method is used then the
-        creds.txt file will be shredded and deleted
-        using ‘rm -P’ after the
-        credentials are updated.

-  

-

-

-

-

-
/boot/creds.txt

-

-

-

-
pwhash(1), rm(1),
-    ssh(1), ssh_config(5),
-    mount_msdos(8), sshd(8),
-    useradd(8)

-

-

-

-
The creds_msdos script appeared in
-    NetBSD 9.0.

-

-

-

-
Matthew R. Green
-    <mrg@eterna23.net>.

-

-

-
-  
-    
-    
-  
-
June 10, 2019NetBSD 10.1

diff --git a/static/netbsd/man8/diskless.8 4.html b/static/netbsd/man8/diskless.8 4.html
deleted file mode 100644
index 0ff9e35e..00000000
--- a/static/netbsd/man8/diskless.8 4.html	
+++ /dev/null
@@ -1,542 +0,0 @@
-
-  
-    
-    
-    
-  
-
DISKLESS(8)System Manager's ManualDISKLESS(8)

-

-

-

-
diskless — booting
-    a system over the network

-

-

-

-
The ability to boot a system over the network is useful for two
-    kinds of systems:

-

-  

-  
a system with no attached mass storage media to boot or run from (e.g. a
-      network computer).

-  

-  
a system with a hard drive that only contains system and application
-      software, and user data is mounted over the network from a central
-    server.

-

-
It can also be done as a temporary measure while repairing or
-    re-installing file systems on a local disk. This capability is necessarily
-    platform dependent because of its dependence on system firmware support; not
-    all platforms supported by NetBSD are capable of
-    being network booted.

-
The protocols used to obtain a network address (e.g. an IP host
-    address), include, but are not limited to:

-

-

-

-  
RARP

-  
Reverse Address Resolution Protocol (ARP)

-  
DHCP

-  
Dynamic Host Configuration Protocol

-  
BOOTP

-  
Bootstrap Protocol

-

-

-
This information can also be derived from non-volatile RAM or by a
-    transform of a network interface (e.g. Ethernet) MAC address.

-
The protocols used to load a NetBSD kernel
-    over a network include, but are not limited to:

-

-

-

-  
TFTP

-  
Trivial File Transfer Protocol

-  
NFS

-  
Sun Network File System

-  
RMP

-  
HP Remote Maintenance Protocol

-  
MOP

-  
DEC Maintenance Operations Protocol

-

-

-
Derivation of the filename of the secondary bootstrap program can
-    be done by a transform of a network interface MAC address (or other protocol
-    address), or provided by a server as with BOOTP, and DHCP. How this is done
-    is platform dependent; see boot(8).

-
The NetBSD kernel doesn't care how it gets
-    loaded and started. The protocols used to boot
-    NetBSD can be completely different from the ones
-    that NetBSD uses operationally, i.e. you can netboot
-    the system using HP RMP and the NetBSD kernel can
-    use IP to communicate after bootstrap.

-
There is no standard way to pass all the required information from
-    a boot loader to an operating system kernel, so the
-    NetBSD kernel usually has to recapitulate the same
-    (or similar) protocol exchanges over the network to obtain a network
-    address, determine which servers to use, and so on.
-    NetBSD supports obtaining this information from
-    RARP, BOOTP, DHCP, and Sun RPC "bootparams". See
-    options(4) for a list of methods that can be compiled into
-    a NetBSD kernel.

-
NetBSD only supports the Sun Network File
-    System (NFS) for mounting its root file system over a network.
-    NetBSD can use any local mass storage device for
-    which it has a driver, after bootstrap, even if that device is not supported
-    by the system's firmware for booting.

-
N.B. DHCP is essentially a series of extensions
-    to BOOTP; the NetBSD dhcpd(8) is
-    capable of responding to both kinds of protocol requests.

-
In the majority of configurations, network boot servers and
-    clients are attached to the same LAN so that broadcast queries from the
-    clients can be heard by the servers. Unless specially configured, routers
-    block broadcasts from propagating from LAN to LAN; some routers can be
-    configured to "forward" broadcast BOOTP packets to another LAN
-    attached to that router, which permits a server on that remote LAN to
-    respond to the client's broadcast query.

-

-

-

-
When booting a system over the network, there are three phases of
-    interaction between client and server:

-

-
    
-  
  1. The system firmware (or stage-1 bootstrap) loads a boot program.
    2. 
-  
  2. The boot program loads a NetBSD kernel.
    3. 
-  
  3. The NetBSD kernel performs an NFS mount of the
-      root file system.
    4. 
-

-
Each of these phases is described in further detail below.

-

-

-
In phase 1, the system firmware loads a boot program. Firmware
-    designs vary widely, so this phase is inherently machine-specific. Some
-    examples:

-
DEC Alpha systems use BOOTP to determine the client's IP address
-    and then use TFTP to load a secondary bootstrap program from the server and
-    filename specified in the BOOTP reply. DEC Alpha systems can also use MOP to
-    load a program to run the system.

-
Sun systems use RARP to determine the client's IP address,
-    transform that address to a hexadecimal string to form the filename of the
-    secondary boot program, and then use TFTP to download the boot program from
-    the server that sent the RARP reply.

-
HP 300-series systems use the HP RMP to download a boot
-  program.

-
Typical personal computers may load a network boot program either
-    from diskette or from a PROM on a Network Interface Card (NIC). Some
-    BIOSes support booting from a network interface.

-

-

-

-
In phase 2, the secondary boot program loads a kernel. Operation
-    in this phase depends on the design of the boot program. A secondary
-    bootstrap program that uses RARP and Sun RPC BOOTPARAMS typically does the
-    following:

-

-
    
-  
  1. gets the client IP address using RARP.
    2. 
-  
  2. gets the client name and server IP address by broadcasting an RPC /
-      BOOTPARAMS / WHOAMI request with the client IP address.
    3. 
-  
  3. gets the server path for this client's root using an RPC / BOOTPARAMS /
-      GETFILE request with the client name.
    4. 
-  
  4. gets the root file handle by calling mountd(8) with the
-      server path for the client root file system.
    5. 
-  
  5. gets the kernel file handle by calling NFS
-      ()
-      on the root file handle.
    6. 
-  
  6. loads the kernel using NFS read calls on the kernel file handle.
    7. 
-  
  7. transfers control to the kernel entry point.
    8. 
-

-
A secondary bootstrap program that uses BOOTP and/or DHCP
-    typically does the following:

-

-
    
-  
  1. query for the client's bootstrap parameters. The response must include the
-      client's IP address, server's IP address, an NFS root path, and a filename
-      to load the NetBSD kernel from.
    2. 
-  
  2. gets the root file handle by calling mountd(8) with the
-      server path for the client root file system.
    3. 
-  
  3. gets the kernel file handle by calling NFS
-      ()
-      on the root file handle.
    4. 
-  
  4. loads the kernel using NFS read calls on the kernel file handle.
    5. 
-  
  5. transfers control to the kernel entry point.
    6. 
-

-

-

-

-
In phase 3, the kernel performs an NFS mount of the root file
-    system. The kernel repeats much of the work done by the boot program because
-    there is no standard way for the boot program to pass the information it
-    gathered on to the kernel.

-
In general, the GENERIC kernel config(1) file
-    for any particular architecture will specify compile-time options to use the
-    same protocol used by the secondary boot program for that architecture. A
-    NetBSD kernel can be compiled to use any of BOOTP,
-    DHCP, or Sun RPC BOOTPARAMS; see options(4).

-
The procedure typically used by the kernel is as follows:

-

-
    
-  
  1. The kernel finds a boot server using the same procedures as described
-      above to determine the client's IP address, an NFS server, etc.
    2. 
-  
  2. The kernel gets the NFS file handle for root using the same procedure as
-      described above.
    3. 
-  
  3. The kernel calls the NFS
-      ()
-      function to get the last-modified time of the root directory, and uses it
-      to check the system clock.
    4. 
-

-

-

-

-

-
Before a client can bootstrap over the network, its server must be
-    configured. Each daemon that implements these protocols must be set up so
-    that it can answer queries from the clients. Some of these daemons are
-    invoked as packets come in, by inetd(8), and some must run
-    independently, started from /etc/rc; see
-    rc.conf(5).

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
RARPrarpdrc.conf(5)
DHCPdhcpdrc.conf(5)
BOOTPbootpdinetd.conf(5)
TFTPtftpdinetd.conf(5)
Sun RPCrpcbindrc.conf(5)
Sun RPCrpc.bootparamdrc.conf(5)
Sun NFSmountdrc.conf(5)
Sun NFSnfsiodrc.conf(5)
HP RMPrbootdrc.conf(5)

-
N.B. DHCP is essentially a series of extensions
-    to BOOTP; the NetBSD dhcpd(8) is
-    capable of responding to both kinds of protocol requests. Since they both
-    bind to the same UDP port, only one may be run on a given server.

-
In the following examples, the client's hostname is
-    myclient; the server is myserver, and
-    the addresses are all fictional. In these examples the hostnames may be
-    Fully Qualified Domain Names (FQDN, e.g. "myclient.mydomain.com")
-    provided that they are used consistently.

-

-

-
For clients that use RARP to obtain their IP address, an entry
-    must be added for each client to /etc/ethers with
-    the client's Ethernet MAC address and Internet hostname:

-

-

-
8:0:20:7:c5:c7          myclient

-

-
This will be used by rarpd(8) to reply to
-    queries from the clients. There must be one entry per client system.

-
A client system's Ethernet MAC address is often printed on the
-    system case, or on a chip on its motherboard, or on the NIC. If not,
-    "sniffing" the network with tcpdump(8) when the
-    client is powered-on should reveal its Ethernet MAC address.

-
Each client system that uses RARP must have its own, unique IP
-    address assigned to it. Assign an IP address for myclient in your
-    /etc/hosts file, or in the master file for your DNS
-    zone. For /etc/hosts the entry should look like:

-

-

-
192.197.96.12           myclient

-

-

-

-

-
The NetBSD DHCP server
-    dhcpd(8) was developed by the Internet Software Consortium
-    (ISC).

-
DHCP can provide a wide range of information to a requesting
-    client; the key data for bootstrapping a diskless client are:

-

-
    
-  
  1. an IP address
    2. 
-  
  2. a subnet mask
    3. 
-  
  3. a TFTP server address for loading the secondary bootstrap and the
-      NetBSD kernel
    4. 
-  
  4. a filename of the secondary bootstrap
    5. 
-  
  5. an NFS server address for the client's file system
    6. 
-  
  6. the client's root file system path, to be NFS mounted.
    7. 
-

-
An example for /etc/dhcpd.conf

-

-
host myclient {
-	hardware ethernet 8:0:20:7:c5:c7;
-	fixed-address myclient;		# client's assigned IP address
-	filename "myclient.netboot";	# secondary bootstrap
-	next-server myserver;		# TFTP server for secondary bootstrap
-	option swap-server myserver;	# NFS server for root filesystem
-	option root-path "/export/myclient/root";
-}

-

-
That
-     declaration
-    goes inside a
-    
-    declaration, which gives parameters for all hosts on the subnet that will be
-    using DHCP, such as the "routers" (the default route),
-    "subnet-mask", "broadcast-address",
-    "domain-name-servers", etc. See dhcpd.conf(5)
-    for details. In that example, myclient has an assigned IP
-    address.

-
The DHCP parameters required for network bootstrapping a system
-    will vary from platform to platform, as dictated by each system's firmware.
-    In particular, because DHCP is extensible, some hardware vendors have
-    specified DHCP options to return information to requesting clients that are
-    specific to that platform. Please see your platform's
-    boot(8) for details.

-

-

-

-
If booting a Sun system, or other system that expects to use TFTP,
-    ensure that inetd(8) is configured to run
-    tftpd(8). The tftpd(8) server should be
-    set up to serve the directory /tftpboot.

-
If booting a SPARC system, install a copy of the appropriate
-    diskless secondary boot loader (such as
-    /usr/mdec/boot or
-    ofwboot.net) in the
-    /tftpboot directory. Make a link such that the boot
-    program is accessible by a filename composed of the client's IP address in
-    hexadecimal, a dot, and the architecture name (all upper case). For
-  example:

-

-

-
# cd /tftpboot
-# ln -s boot C0C5600C.SUN4

-

-
For a Sun-3 or UltraSPARC system, the filename would be just
-    C0C5600C (these systems' firmware does not append the architecture name).
-    The name used is architecture dependent, it simply has to match what the
-    booting client's system firmware wishes it to be.

-
If the client's system firmware fails to fetch the expected file,
-    tcpdump(8) can be used to discover which filename the
-    client is requesting. Also, examination of tftpd(8) log
-    entries (typically in /var/log/messages) should show
-    whether the server is hearing the client system, and what filename the
-    client is asking for.

-

-

-

-
If booting an HP 300-series system, ensure that
-    /etc/rbootd.conf is configured properly to transfer
-    the boot program to the client. An entry might look like this:

-

-

-
08:00:09:01:23:E6	SYS_UBOOT	# myclient

-

-
The secondary bootstrap program for an HP 300-series system
-    SYS_UBOOT (which may be called
-    uboot.lif before installation) must be installed in
-    the directory /usr/mdec/rbootd.

-
See the rbootd(8) manual page for more
-    information.

-

-

-

-
Add myclient to the bootparams database in
-    /etc/bootparams:

-

-

-
myclient  root=myserver:/export/myclient/root \
-          swap=myserver:/export/myclient/root/swap \
-          dump=myserver:/export/myclient/root/swap

-

-
and ensure that rpc.bootparamd(8) and
-    rpcbind(8) are running. Both myclient
-    and myserver must have IP addresses in the DNS or
-    /etc/hosts.

-

-

-

-
Build the swap file for myclient on the NFS
-    server:

-

-

-
# cd /export/myclient/root
-# dd if=/dev/zero of=swap bs=16k count=1024

-

-
This creates a 16 megabyte swap file.

-
Populate myclient's root
-    file system on the NFS server. How this is done depends on the client
-    architecture and the version of the NetBSD
-    distribution. It can be as simple as copying and modifying the server's root
-    file system, or unpack a complete NetBSD binary
-    distribution for the appropriate platform.

-
If the NFS server is going to support multiple different
-    architectures (e.g. Alpha, PowerPC, SPARC, MIPS), then it is important to
-    think carefully about how to lay out the NFS server's exported file systems,
-    to share what can be shared (e.g. text files, configuration files, user home
-    directories), and separate that which is distinct to each architecture (e.g.
-    binary executables, libraries).

-

-

-

-
Export the client-populated file systems on the NFS server in
-    /etc/exports:

-

-

-
/usr -ro myclient
-# for SunOS:
-# /export/myclient -rw=myclient,root=myclient
-# for NetBSD:
-/export/myclient -maproot=root -alldirs myclient

-

-
If the server and client are of the same architecture, then the
-    client can share the server's /usr file system (as
-    is done above). If not, you must build a properly fleshed out
-    /usr partition for the client in some other part of
-    the server's file system, to serve to the client.

-
If your server is a SPARC, and your client a Sun-3, you might
-    create and fill /export/usr.sun3 and then use the
-    following /etc/exports lines:

-

-

-
/export/usr.sun3 -ro myclient
-/export/myclient -rw=myclient,root=myclient

-

-
Of course, in either case you will have to have an NFS server
-    running on the server side.

-

-

-

-

-
Copy and customize at least the following files in
-    /export/myclient/root:

-

-

-
# cd /export/myclient/root/etc
-# vi fstab
-# cp /etc/hosts hosts
-# echo 'hostname="myclient"' >> rc.conf
-# echo "inet 192.197.96.12" > ifconfig.le0

-

-
Note that "le0" above should be replaced with the name
-    of the network interface that the client will use for booting; the network
-    interface name is device dependent in NetBSD.

-
Correct the critical mount points and the swap file in the
-    client's /etc/fstab (which will be
-    /export/myclient/root/etc/fstab) i.e.

-

-

-
myserver:/export/myclient/root  /    nfs  rw 0 0
-myserver:/usr                   /usr nfs  rw 0 0
-/swap                           none swap sw 0 0

-

-
Note, you
-     specify the
-    swap file in /etc/fstab or it will not be used! See
-    swapctl(8).

-
It may be useful to set “flushroutes=NO” in
-    /etc/rc.conf to avoid the default route supplied by
-    the boot setup disappearing mid-boot.

-

-

-

-

-  
/etc/hosts

-  
table of associated IP addresses and IP host names; see
-      hosts(5)

-  
/etc/ethers

-  
table of associated Ethernet MAC addresses and IP host names used by
-      rarpd(8); see ethers(5)

-  
/etc/bootparams

-  
client root pathname and swap pathname; see
-      bootparams(5)

-  
/etc/exports

-  
exported NFS mount points; see exports(5)

-  
/etc/rbootd.conf

-  
configuration file for HP RMP; see rbootd(8)

-  
/usr/mdec/rbootd

-  
location of boot programs offered by rbootd(8)

-  
/tftpboot

-  
location of boot programs offered by tftpd(8)

-

-

-

-

-
bootparams(5), dhcpd.conf(5),
-    ethers(5), exports(5),
-    fstab(5), hosts(5),
-    networks(5), boot(8),
-    dhcpd(8), mopd(8),
-    mountd(8), nfsd(8),
-    rarpd(8), rbootd(8),
-    reboot(8), rpc.bootparamd(8),
-    tftpd(8)

-
Reverse Address Resolution
-    Protocol, RFC, 903,
-    June 1984.

-
Bootstrap Loading using
-    TFTP, RFC, 906,
-    June 1984.

-
Bootstrap Protocol,
-    RFC, 951,
-    September 1985.

-
The TFTP Protocol (Revision
-    2), RFC, 1350,
-    July 1992.

-
Dynamic Host Configuration
-    Protocol, RFC,
-    2131, March
-  1997.

-
DHCP Options and BOOTP Vendor
-    Extensions, RFC,
-    2132, March
-  1997.

-
RFC Editor

-

-

-
-  
-    
-    
-  
-
January 8, 2026NetBSD 10.1

diff --git a/static/netbsd/man8/hpcboot.8 4.html b/static/netbsd/man8/hpcboot.8 4.html
deleted file mode 100644
index f03ac869..00000000
--- a/static/netbsd/man8/hpcboot.8 4.html	
+++ /dev/null
@@ -1,133 +0,0 @@
-
-  
-    
-    
-    
-  
-
HPCBOOT(8)System Manager's ManualHPCBOOT(8)

-

-

-

-
hpcboot — load and
-    boot kernel from Windows CE

-

-

-

-
-  
-    
-    
-  
-
hpcboot.exe

-

-

-

-
hpcboot is a program that runs on
-    Windows CE. It loads and executes the specified
-    NetBSD kernel. hpcboot
-    supports hpcarm, hpcmips, and hpcsh ports.

-
Click on the “Boot” button to start the boot process
-    with selected options. Click on the “Cancel” button to exit
-    hpcboot.

-

-

-
On this tab you can select the kernel to boot and options to pass
-    to the kernel.

-

-  
Directory

-  
In this combobox you specify the “current” directory. The
-      kernel and miniroot image pathnames are taken to be relative to this
-      directory.
-    
hpcboot can load kernel and miniroot
-        from FAT and UFS filesystems, and via HTTP.

-  

-  
Kernel

-  
In this text field you specify the name of the kernel to load. Kernels
-      compressed with gzip(1) are supported.

-  
Model

-  
Select your H/PC model in this combobox.

-  
Root File System

-  
This group of controls lets you specify the desired root file system type.
-      You can select wd(4), sd(4),
-      md(4), and NFS root.
-    
If you select md(4) memory disk root file
-        system, you should specify the path name of the file system image in the
-        text field below. Miniroot images compressed with
-        gzip(1) are supported.

-  

-  
Kernel Boot Flags

-  
This group of controls is used to pass boot flags to the kernel.

-

-

-

-

-
On this tab you can specify miscellaneous options that mostly
-    control the hpcboot program itself.

-

-  
Auto Boot

-  
If this option is selected hpcboot will
-      automatically boot NetBSD after the specified
-      timeout.

-  
Reverse Video

-  
Tells kernel if it should use the framebuffer in reverse video mode.

-  
Pause Before Boot

-  
If selected, a warning dialog will be presented
-       anything
-      is done, right after the “Boot” button is pressed.

-  
Load Debug Info

-  
This option currently does nothing.

-  
Safety Message

-  
If selected, a warning dialog will be presented
-       the kernel
-      has been loaded and prepared to be started. This will be your last chance
-      to cancel the boot.

-  
Extra Kernel Options

-  
In this text field you can specify additional options to pass to the
-      kernel.

-

-

-

-

-
This tab gets its name from the big text area that
-    hpcboot uses as the “console” to
-    report its progress.

-

-  
Save To File

-  
If checked, the progress log will be sent to the specified file
-    instead.

-  
“Checkboxes Anonymous”

-  
The row of 8 checkboxes controls debugging options for
-      hpcboot itself. They control the bits of an
-      internal variable, the leftmost checkbox being the 7th bit.

-  
“Buttons Anonymous”

-  
The buttons “a” to “d” control 4
-      “hooks” a developer might want to use during
-      hpcboot development.

-

-

-

-

-

-
kloader(4), boot(8)

-

-

-

-
The hpcboot utility first appeared in
-    NetBSD 1.6.

-

-

-

-
hpcboot reads the entire kernel image at
-    once, and requires enough free area on the main memory.

-

-

-
-  
-    
-    
-  
-
April 3, 2004NetBSD 10.1

diff --git a/static/netbsd/man8/intro.8 4.html b/static/netbsd/man8/intro.8 4.html
deleted file mode 100644
index 6bc45052..00000000
--- a/static/netbsd/man8/intro.8 4.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(8)System Manager's ManualINTRO(8)

-

-

-

-
intro —
-    introduction to system maintenance procedures and
-    commands

-

-

-

-
This section contains information related to system operation and
-    maintenance.

-
It describes commands used to create new file systems
-    (newfs(8)), verify the integrity of the file systems
-    (fsck(8)), control disk usage
-    (edquota(8)), maintain system backups
-    (dump(8)), and recover files when disks die an untimely
-    death (restore(8)). Network related services like
-    inetd(8) and ftpd(8) are also
-  described.

-
A number of pages in this section describe general system
-    management topics. For example, the diskless(8) page
-    describes how to boot a system over a network, and the
-    compat_linux(8) page describes how to run Linux binaries
-    on NetBSD architectures that support it.

-

-

-

-
The intro section manual page appeared in
-    4.2BSD.

-

-

-
-  
-    
-    
-  
-
December 14, 2010NetBSD 10.1

diff --git a/static/netbsd/man8/man8.hpcarm/boot.8 3.html b/static/netbsd/man8/man8.hpcarm/boot.8 3.html
deleted file mode 100644
index 728d6424..00000000
--- a/static/netbsd/man8/man8.hpcarm/boot.8 3.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (hpcarm)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
Windows CE machines with StrongARM CPUs use the
-    hpcboot(8) program to boot
-  NetBSD.

-

-

-
Unfortunately, NetBSD can't reboot itself
-    at power-up or after crashes. The machine will go through the cold reset and
-    boot into Windows CE. You will have to restart
-    NetBSD manually using
-  hpcboot(8).

-
Once NetBSD starts, an automatic
-    consistency check of the file systems will be performed, and unless this
-    fails, the system will resume multi-user operations.

-

-

-

-
On cold reset Windows CE handheld machines attempt to boot
-    the Windows CE operating system from the boot ROM. The boot ROM is
-    usually not rewritable, so you cannot erase or damage Windows CE
-    image.

-
You can't boot NetBSD directly, skipping
-    Windows CE. The NetBSD bootloader,
-    hpcboot(8), is provided as a Windows CE application
-    program instead. Though the bootloader is an application program, it blows
-    the entire running Windows CE, its data, and its settings away from
-    RAM (but not ROM!) when the kernel boots successfully. If
-    NetBSD is halted the machine will go through the
-    cold reset and will reboot into Windows CE.

-

-

-

-
Please, refer to the hpcboot(8) manual page.

-

-

-

-

-

-  
hpcboot.exe

-  
bootloader program for Windows CE

-

-

-

-

-
hpcboot(8)

-

-

-

-
There is no general way to launch the bootloader automatically, as
-    only a few Windows CE machines provide an “auto run”
-    mechanism.

-
This port doesn't support kloader(4), which
-    means that when the system is rebooted, it goes back to
-  Windows CE.

-

-

-
-  
-    
-    
-  
-
January 13, 2006NetBSD 10.1

diff --git a/static/netbsd/man8/man8.mac68k/boot.8 3.html b/static/netbsd/man8/man8.mac68k/boot.8 3.html
deleted file mode 100644
index 918f9639..00000000
--- a/static/netbsd/man8/man8.mac68k/boot.8 3.html	
+++ /dev/null
@@ -1,88 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (mac68k)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-

-

-
Normally, the NetBSD kernel on the mac68k
-    architecture is booted from the native operating system by means of an
-    application program. When the kernel takes over, it initializes itself and
-    proceeds to boot the system. An automatic consistency check of the file
-    systems takes place, and unless this fails, the system comes up to
-    multi-user operations. The proper way to shut the system down is with the
-    shutdown(8) command.

-
If the system crashes, it will enter the kernel debugger,
-    ddb(4), if it is configured in the kernel. If the debugger
-    is not present, or the debugger is exited, the system will attempt a dump to
-    the configured dump device (which will be automatically recovered with
-    savecore(8) during the next boot cycle). After the dump is
-    complete (successful or not), the system will attempt a reboot.

-
On most mac68k machines with "soft-power" after the
-    IIcx, the power switch can be physically rotated and locked in the 'on'
-    position. The native OS can be configured to automatically start the
-    NetBSD boot program. Additionally, the
-    NetBSD boot program can be configured to boot
-    NetBSD without intervention. When a system is so
-    configured, it can crash or lose power and reboot back to a fully multi-user
-    state without any intervention.

-

-

-

-
The boot application runs in the native OS on the system. It has a
-    dialog where booting preferences may be changed and an option whereby these
-    options may be saved. The preferences are stored in the program itself, not
-    in a preferences folder--thus allowing two separate copies of the program to
-    be configured differently (e.g. to boot different netbsd or netbsd.test, or
-    to boot from two different drives).

-
One option that may be specified is a boot to single-user mode.
-    This stops the boot process very early on and allows system maintenance. If
-    one wishes to provide some security at this phase of the boot, remove the
-    ‘secure’ option from ttye0 in the
-    ttys(5) file.

-
Another useful option that may be specified is the "serial
-    console" option. This will allow a serial device (terminal or computer)
-    to act as a console for the system. This device must be configured to use
-    9600 baud, eight bits, no parity, and one stop bit (9600-N81). Either the
-    printer port or the modem port (tty01 and tty00, respectively) may be used
-    for this.

-
It is sometimes useful to boot a kernel that resides in a folder
-    in native OS rather than from the usual location in the
-    NetBSD file system. A radio button is supplied for
-    this purpose. Note that some programs will not run properly if the kernel is
-    not found as /netbsd within the
-    NetBSD file system.

-

-

-

-

-

-  
/netbsd

-  
system kernel

-

-

-

-

-
ddb(4), ttys(5),
-    savecore(8), shutdown(8)

-

-

-
-  
-    
-    
-  
-
July 1, 1995NetBSD 10.1

diff --git a/static/netbsd/man8/man8.macppc/boot.8 3.html b/static/netbsd/man8/man8.macppc/boot.8 3.html
deleted file mode 100644
index 07107669..00000000
--- a/static/netbsd/man8/man8.macppc/boot.8 3.html	
+++ /dev/null
@@ -1,296 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (macppc)BOOT(8)

-

-

-

-
boot — Macppc
-    system bootstrapping procedures

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed as described in fsck(8), and unless this fails,
-    the system will resume multi-user operations.

-

-

-

-
The boot ROM performs a Power On Self Test (POST) then loads Open
-    Firmware. Depending on the Open Firmware variable
-    ‘auto-boot?’ it will either stop at
-    the Open Firmware prompt or attempt to boot an operating system. Depending
-    on the contents of the ‘use-nvramrc?’,
-    ‘boot-command’,
-    ‘boot-device’, and
-    ‘boot-file’ Open Firmware variables,
-    it will attempt to boot MacOS, MacOS X, or
-  NetBSD.

-
To boot NetBSD, Open Firmware loads the
-    bootloader macppc/ofwboot(8) from the specified
-    ‘boot-device’. The bootloader then
-    loads the kernel from the ‘boot-file’,
-    (if it exists). Otherwise, it tries to load (in the following order):
-    netbsd, netbsd.gz, or
-    netbsd.macppc on the “a” partition of
-    the same device that had the bootloader.

-

-

-

-
An essential but incomplete list of Open Firmware commands
-    follows. A more thorough list is contained in the FAQ.
-    https://www.NetBSD.org/ports/macppc/faq.html#ofw-use

-
boot [boot-device
-    [boot-file]] [options]

-
Boot an operating system. The default arguments for this command
-    are taken from the Open Firmware environment variables:

-

-  
boot-device

-  
primary bootloader location

-  
boot-file

-  
kernel location

-  
options

-  
flags passed to the kernel

-

-
reset-all

-
Reset the system, and proceed as specified by the
-    ‘use-nvramrc?’ and
-    ‘auto-boot?’ variables. If
-    ‘use-nvramrc?’ is set to
-    ‘true’, then the system will attempt
-    to execute the commands stored in the
-    ‘nvramrc’ variable. If
-    ‘auto-boot?’ is set to
-    ‘true’, the system will attempt to use
-    the values stored in ‘boot-command’,
-    ‘boot-device’, and
-    ‘boot-file’ to boot the system. If
-    ‘auto-boot?’ is set to
-    ‘false’, the system will halt at the
-    Open Firmware prompt.

-
shut-down

-
Power off the system.

-
setenv variable
-    value

-
Set an Open Firmware variable, e.g.,

-

-
setenv auto-boot? false
-setenv boot-device hd:,\ofwboot.xcf
-setenv boot-file netbsd-GENERIC.gz

-

-
set-default
-  variable

-
Set an Open Firmware variable to its default value.

-
printenv
-  [variable]

-
Show Open Firmware variables and values.

-
eject fd

-
Eject floppy disk on systems with on-board floppy drives.

-
mac-boot

-
Attempt to boot MacOS on an Open Firmware 3 system.

-
bye

-
Attempt to boot MacOS on an Open Firmware 1.0.5, 2.0.x, or 2.4
-    system.

-

-

-

-
An essential but incomplete list of Open Firmware variables
-    follows. A more thorough list is contained in the FAQ.
-    https://www.NetBSD.org/ports/macppc/faq.html#ofw-variables

-

-  

-  
What Open Firmware will do at system startup or reset:
-    

-      
true

-      
automatically bootstrap an operating system using values from the
-          ‘boot-command’,
-          ‘boot-device’, and
-          ‘boot-file’ variables.

-      
false

-      
stop at the Open Firmware prompt.

-    

-  

-  

-  
If ‘true’ runs commands in variable
-      ‘nvramrc’.

-  

-  
Kernel memory location. Do not modify this value on Open
-      Firmware 3 systems — you may damage your
-      computer. All other Open Firmware versions should use
-      F00000.

-  

-  
Bootloader memory location. Do not modify this value on Open
-      Firmware 3 systems — you may damage your
-      computer. All other Open Firmware versions should use
-      600000.

-  

-  
The command to use for booting. Typically, the default of
-      ‘boot’ is used.

-  

-  
Device from which to load primary bootloader. Value depends on a variety
-      of factors. See macppc/ofwboot(8).

-  

-  
Kernel location. Value depends on a variety of factors. See
-      macppc/ofwboot(8).

-  

-  
What type of console input device (ADB keyboard, USB keyboard, or serial
-      port).
-    

-      
kbd

-      
ADB keyboard on models with ADB, USB keyboard on models with USB, and
-          built-in keyboard on laptops. This is the default on some Open
-          Firmware 2.0.x machines and all Open Firmware 2.4 and 3 machines.

-      
ttya

-      
‘Modem’ serial port on machines with serial ports.
-          Properties are 38400 bps, 8 bits, no parity, 1 stop bit, no
-          handshaking. This is the default on all Open Firmware 1.0.5 systems
-          and some Open Firmware 2.0.x systems.

-      
ttyb

-      
‘Printer’ serial port on machines with serial ports.
-          Properties are the same as the ‘Modem’ port.

-      
scca

-      
Serial port on Xserve models. Properties are 57600 bps, 8 bits, no
-          parity, 1 stop bit, no handshaking.

-    

-  

-  
output-device

-  
What type of console output device (On-board video, AGP video, PCI video,
-      built-in LCD, or serial console). Value depends on a variety of factors.
-      See macppc/ofwboot(8) and
-      https://www.NetBSD.org/ports/macppc/faq.html#ofw-input-output-devices

-  
nvramrc

-  
If ‘use-nvramrc?’ is set to true,
-      these FORTH commands will be run when the computer is reset

-

-

-

-

-
When Open Firmware loads the primary bootloader, it will print
-    something like the following:

-

-
 loading XCOFF
- tsize=CC50 dsize=14AC bsize=2668 entry=640000
- SECTIONS:
- .text    00640000 00640000 0000CC50 000000E0
- .data    0064D000 0064D000 000014AC 0000CD30
- .bss     0064E4B0 0064E4B0 00002668 00000000
- loading .text, done..
- loading .data, done..
- clearing .bss, done..

-

-
When macppc/ofwboot(8) is started, it prints
-    something like the following:

-

-
 >> NetBSD/macppc OpenFirmware Boot, Revision 1.7
- >> (autobuild@tgm.daemon.org, Thu Feb  6 17:50:27 UTC 2003)

-

-
When macppc/ofwboot(8) is loading the kernel, it
-    prints something like the following:

-

-
 4395364+254568 [220144+193803]=0x4d477c
-  start=0x100000

-

-
When the NetBSD kernel has started it
-    prints a banner similar to the following:

-

-
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
-     The NetBSD Foundation, Inc.  All rights reserved.
- Copyright (c) 1982, 1986, 1989, 1991, 1993
-     The Regents of the University of California.  All rights reserved.
-
- NetBSD 1.6ZC (GENERIC) #0: Tue Sep 30 13:09:10 UTC 2003
-        autobuild@tgm.NetBSD.org:/autobuild/HEAD/macppc/OBJ/autobuild/HEAD/src/sys/arch/macppc/compile/GENERIC

-

-

-

-

-
Once the NetBSD/macppc kernel is booted
-    normally it initializes itself and proceeds to start the system. An
-    automatic consistency check of the file systems takes place, and unless this
-    fails, the system comes up to multi-user operation.

-
The proper way to shut the system down is with the
-    shutdown(8) command.

-
If the system crashes, it will enter the kernel debugger,
-    ddb(4), if it is configured in the kernel. If the crash
-    occurred during initialization and the debugger is not present or is exited,
-    the kernel will halt the system.

-
If the crash occurred during normal operation and the debugger is
-    not present or is exited, the system will attempt a dump to the configured
-    dump device (which will be automatically recovered with
-    savecore(8) during the next bootstrap cycle), and after
-    the dump is complete (successful or not) the kernel will attempt a
-  reboot.

-

-

-

-

-

-  
/boot

-  
NetBSD secondary bootstrap program (Open Firmware
-      1.x and 2.x)

-  
/netbsd

-  
default NetBSD system kernel

-  
/usr/mdec/bootxx

-  
NetBSD primary bootstrap program (Open Firmware
-      1.x and 2.x) a.k.a. “partition zero” bootloader

-  
/usr/mdec/ofwboot

-  
NetBSD secondary bootstrap program (Open Firmware
-      1.x and 2.x)

-  
/usr/mdec/ofwboot.xcf

-  
primary bootstrap for netboot and “cd9660” (ISO 9660),
-      “MS-DOS”, “HFS”, and “HFS+” file
-      systems.

-

-

-

-

-
ddb(4), intro(4),
-    diskless(8), halt(8),
-    init(8), installboot(8),
-    macppc/ofwboot(8), rc(8),
-    reboot(8), savecore(8),
-    shutdown(8)

-
https://www.NetBSD.org/ports/macppc/faq.html
-  

-  https://www.NetBSD.org/docs/network/netboot/

-

-

-

-
IEEE Std 1275-1994 (“Open
-    Firmware”)
-    http://playground.sun.com/1275/home.html

-

-

-

-
The device names used by NetBSD/macppc and
-    Open Firmware often have no relation to each other.

-
Apple Computer's Open Firmware implementation is easily confused.
-    It is best to reboot your computer after a failed boot attempt,
-    halt, or shutdown -h. Use
-    the Open Firmware reset-all command.

-
Apple Computer's Open Firmware implementation is notoriously bad.
-    Thorough instructions for installing and booting
-    NetBSD are in the install notes
-    (INSTALL.html) included with every release of
-    NetBSD.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.macppc/ofwboot.8 3.html b/static/netbsd/man8/man8.macppc/ofwboot.8 3.html
deleted file mode 100644
index 3a16094d..00000000
--- a/static/netbsd/man8/man8.macppc/ofwboot.8 3.html	
+++ /dev/null
@@ -1,367 +0,0 @@
-
-  
-    
-    
-    
-  
-
OFWBOOT(8)System Manager's Manual (macppc)OFWBOOT(8)

-

-

-

-
ofwboot,
-    ofwboot.elf, ofwboot.xcf
-    — Open Firmware boot command

-

-

-

-
-  
-    
-    
-  
-
ofwboot

-

-

-

-
Open Firmware is a FORTH-like command interpreter started by the
-    BootROM after the power-on self test (POST). This command interpreter allows
-    the user flexibility in choosing how their machine boots an operating
-    system. NetBSD uses Open Firmware to initialize many
-    of the devices in a system and uses it to load the primary bootloader,
-    ofwboot.

-
The information in this man page should only serve as a guideline
-    for users. Apple has made many revisions to Open Firmware, and the earlier
-    versions had many problems and inconsistencies. You may find that a boot
-    command that works on one model will not work on another.

-
In this man page, only one Open Firmware command will be
-    described, boot, because it is used to pass
-    arguments to ofwboot. The Open Firmware
-    boot command takes up to three arguments:

-

-
boot [boot-device [boot-file]] [options]

-

-
where

-

-

-

-  
boot-device

-  
primary bootloader location

-  
boot-file

-  
kernel location

-  
options

-  
flags passed to the kernel (see below)

-

-

-

-

-
The first argument, boot-device, actually
-    designates the primary bootloader location and its name in the form:

-

-
-device:[partition-num][,\bootloader-filename]
-

-

-
A typical example, from a PowerBook (FireWire), is

-

-
/pci@f2000000/mac-io@17/ata-4@1f000/@0:9,\ofwboot.xcf

-
Note that colon (‘:’)
-    delimits the device to the left, and comma
-    (‘,’) separates the bootloader
-    filename from the first part. For Open Firmware versions before 3, the
-    primary bootloader is installed in partition “zero”, and it is
-    not necessary to specify the bootloader-filename. For
-    Open Firmware version 3, you must specify the bootloader filename.

-
Open Firmware stores aliases to common devices in NVRAM. In the
-    example the above,
-    /pci@f2000000/mac-io@17/ata-4@1f000/@0 is the path
-    on a PowerBook (FireWire) to the built-in ATA/100 hard drive. Use the
-    devalias command in Open Firmware to print out a
-    list of common device names on a particular model. The
-    boot-device above could then be simplified to:

-

-
hd:9,\ofwboot.xcf

-
bootloader-filename is usually
-    ofwboot.xcf. See also the
-    FILES section for further discussion.

-
If boot-device is omitted from the
-    boot command, the Open Firmware variable
-    boot-device is used.

-

-

-

-
It may be necessary to specify the boot-file
-    if Open Firmware does not know where to find the kernel. The default is to
-    load the file named netbsd on partition
-    “a” from the device used to load the
-    primary bootloader.

-
For systems with Open Firmware versions less than 3 which are set
-    up using sysinst, the
-    boot-file argument is not necessary. Systems with Open
-    Firmware version 3 may need to specify the
-  boot-file.

-
The syntax is similar to the boot-device
-    argument:

-

-
-[boot-file-device:partition-num/][kernel-name]
-

-

-
This is a little different, since a kernel-name may be specified
-    without listing a boot-file-device and
-    partition-num. Additionally, a
-    boot-file-device and
-    partition-num may need to be specified, while using
-    the default kernel-name.

-
If no kernel-name is specified, the primary
-    bootloader will try to find kernels named either
-    netbsd or netbsd.gz on the
-    boot-device or (if specified) boot-file-device.

-

-

-

-
Possible options are:

-

-  

-  
ask for the boot device

-  

-  
single-user mode boot

-  

-  
debug mode

-  

-  
exit to Open Firmware after processing arguments

-

-

-

-

-

-
If set, the following Open Firmware variables will be used to
-    determine which boot-device and
-    boot-file Open Firmware should use when booting a
-    system. If the user specifies arguments on the command line, these values
-    are overridden.

-

-  

-  
used as the first argument

-  

-  
used as the second argument

-  

-  
setting this variable to false will present the
-      user with an Open Firmware command prompt after power-on reset. A value of
-      true will automatically boot the system using the
-      variables boot-device and
-      boot-file. (This is not really related to the boot
-      command, but is included for completeness.)

-

-
To restore these variables to their default values, use the
-    set-default Open Firmware command:

-

-
set-default boot-device

-

-

-

-
The three files ofwboot,
-    ofwboot.elf, and ofwboot.xcf
-    are the same program, in different executable formats.

-

-  
ofwboot

-  
ofwboot is installed via
-      installboot(8) on systems with Open Firmware versions
-      less than 3. It is not necessary to specify this file name on the Open
-      Firmware boot command, as it is stored in a
-      special location in the NetBSD partition that is
-      marked “bootable” in the Apple partition map entry. The
-      bootable partition can be specified as partition “zero”. For
-      example, the following command might be used to boot from a SCSI device
-      with ID 2: 0 >boot scsi-int/sd@2:0.

-  
ofwboot.xcf

-  
ofwboot.xcf is in XCOFF format. This file is used
-      on all Open Firmware 3 systems, and on Open Firmware systems prior to 3
-      when the bootloader is not installed in partition “zero”,
-      such as from an ISO-9660 format CD-ROM.

-  
ofwboot.elf

-  
ofwboot.elf is in elf(5) format
-      and only functions on systems with Open Firmware version 3. To avoid
-      confusion, all users should be using ofwboot.xcf,
-      as ofwboot.elf offers no additional functionality.
-      It is only included for historical reasons.

-  
boot.fs

-  
This 1.44 MB disk image contains everything necessary to boot and install
-      NetBSD. It includes the partition
-      “zero” bootloader (ofwboot), an
-      INSTALL kernel (with limited device drivers), and the
-      sysinst utility in a RAM disk. Since Open Firmware
-      does not care what media files are loaded from, only whether they are
-      supported and in the correct format, this disk image may be placed on
-      media other than floppy disks, such as hard drives or Zip disks. Use
-      dd(1) on Unix, or DiskCopy on
-      MacOS 9.1 or later, or suntar on any MacOS version
-      to copy this image onto the media.

-  
netbsd

-  
production kernel, using the GENERIC set of devices which supports almost
-      all hardware available for this platform.

-  
netbsd_GENERIC_MD.gz

-  
GENERIC kernel (the same as netbsd), with RAM disk
-      and sysinst included.

-  
NetBSD-{RELEASE}-macppc.iso

-  
bootable CD-ROM image for all supported systems. Usually located at
-      https://cdn.NetBSD.org/pub/NetBSD/images/{RELEASE}/

-

-

-

-

-
In the following examples
-    ‘0 > ’ is the Open
-    Firmware prompt.

-
    
-  
  • Boot the default installation into single user mode.
-    
    0 > boot -s
    
-  
    • 
-  
  • Boot an Open Firmware 3 system, with netbsd
-      installed on partition “a”:
-    
    0 > boot
-      hd:,\ofwboot.xcf
    
-  
    • 
-  
  • Boot the kernel named netbsd.new from partition
-      “a” of the hard disk into
-      ddb(4) using ELF version of
-      ofwboot from the USB flash drive:
-    
    0 > boot
-      usb0/disk:,\ofwboot.elf hd/netbsd.new -d
    
-    or
-    
    0 > boot
-      usb1/disk:,\ofwboot.elf hd/netbsd.new -d
    
-    Note: You can check which usb device name should be used by
-      “devalias” and
-      “dev usb0 ls” commands etc.
    • 
-  
  • Boot from bootable CD-ROM of NetBSD release with
-      Open Firmware 3 or higher:
-    
    0 > boot
-      cd:,\ofwboot.xcf
    
-  
    • 
-  
  • Boot from bootable CD-ROM (internal SCSI, id=3) of
-      NetBSD release with Open Firmware versions prior
-      to 3:
-    
    0 > boot
-      scsi/sd@3:0
    
-  
    • 
-  
  • Boot from a USB flash drive containing a bootable CD-ROM ISO image of
-      NetBSD release with Open Firmware 3 or higher:
-    
    0 > boot
-      usb0/disk@1:3,\ofwboot.xcf
    
-    or
-    
    0 > boot
-      usb1/disk@1:3,\ofwboot.xcf
    
-    Note: The partition number “3” is an
-      ISO9660/HFS hybrid partition specified by the Apple partition map in the
-      macppc CD ISO image of NetBSD release.
    • 
-  
  • Boot from floppy disk:
-    
    0 > boot fd:0
    
-  
    • 
-  
  • Boot from network, with bootps, bootptab(5),
-      tftpd(8), and nfsd(8) server
-      available:
-    
    0 > boot enet:0
    
-  
    • 
-  
  • Boot from network, but use internal root partition of second drive:
-    
    0 > boot enet:0
-      ultra1:0
    
-  
    • 
-  
  • Boot MacOS, looking for the first available bootable disk:
-    
    0 > boot
-      hd:,\\:tbxi
    
-  
    • 
-  
  • Boot MacOS X residing on partition 10:
-    
    0 > boot
-      hd:10,\\:tbxi
    
-  
    • 
-

-

-

-

-

-
DEFAULT CATCH!, code=FF00300 at %SRR0: FF80AD38 %SRR1: 00001070

-

-
Could be “device not found” or I/O errors on the
-    device. The numbers are just for example. If the error is caused by I/O
-    errors (especially on CD boot), retrying the same command after restarting
-    Open Firmware by reset-all command might help.

-

-
CLAIM failed

-

-Open Firmware got errors on memory allocation ops etc. This could also happen by
-  buggy Open Firmware implementation, or improper
-  real-base variable settings.
-

-
Can't LOAD from this device

-

-Open Firmware found the device, but it is not supported by
-  load.
-

-
0 > boot yy:0/netbsd
-RESETing to change Configuration!

-

-yy:0 doesn't exist, so Open Firmware ignores the string
-  and uses the default parameters to boot MacOS; the MacOS boot routine then
-  clears some of the Open Firmware variables.
-

-
0 > boot ata/ata-disk@0:9 specified partition is not bootable
- ok

-

-As it says.
-

-
0 > boot ata/ata-disk@0:0
->> NetBSD/macppc OpenFirmware Boot, Revision 1.3
->> (root@nazuha, Fri Jun  8 22:21:55 JST 2001)
-no active package3337696/

-

-and hangs: See the real-base part in the FAQ.
-
Note: It is recommended to restart Open Firmware by
-    reset-all command if you get these Open Firmware
-    errors, to avoid further unexpected random errors.

-

-

-

-
installboot(8)

-
INSTALL.html

-
NetBSD/macppc
-    Frequently Asked Questions

-
NetBSD/macppc
-    Partitioning HOW-TO

-
NetBSD/macppc
-    Model Support

-
Diskless
-    NetBSD HOW-TO

-

-

-

-
IEEE Std 1275-1994 (“Open
-    Firmware”)

-

-

-

-
ofwboot can only boot from devices
-    recognized by Open Firmware.

-
Early PowerMacintosh systems (particularly the 7500) seem to have
-    problems with netbooting. Adding an arp entry at the tftp server with

-

-
arp -s booting-host-name
-  its-ethernet-address

-
may resolve this problem (see arp(8)).

-
Once boot failed,

-

-
0 > boot CLAIM failed
- ok

-

-
successive boots may not be possible. You need to type
-    reset-all or power-cycle to re-initialize Open
-    Firmware.

-

-

-
-  
-    
-    
-  
-
June 9, 2024NetBSD 10.1

diff --git a/static/netbsd/man8/man8.pmax/boot.8 2.html b/static/netbsd/man8/man8.pmax/boot.8 2.html
deleted file mode 100644
index 651d9a25..00000000
--- a/static/netbsd/man8/man8.pmax/boot.8 2.html	
+++ /dev/null
@@ -1,162 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (pmax)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
The NetBSD kernel is started by placing it
-    near the beginning of physical memory and transferring to the entry point.
-    Since the system is not reenterable, it is necessary to read it in from disk
-    or tape each time it is to be bootstrapped.

-

-

-
Normally, the system will boot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed, and unless this fails, the system will resume multi-user
-    operations.

-

-

-

-
At power up, all DECstation ROMs consult the
-    haltaction environment variable in EEPROM to
-    determine whether or not to attempt to boot automatically. If this variable
-    is set to ‘h’, the ROM prints a prompt on the console and
-    waits for user commands. If set to ‘b’, the ROM attempts to
-    autoboot.

-

-

-

-

-
On the DECstation 2100 and 3100, the path used for automatic
-    booting is stored in the bootpath environment
-    variable.
-  

-   The path is made up of a device type specifier (e.g., rz, tz, mop or tftp)
-    followed by a triplet in the form (x,y,z), followed by a filename to
-  load.

-
Within the triplet, x is the controller (always 0), y is the SCSI
-    id of the drive to boot from or 0 for net boots, and z is the partition to
-    boot from (usually 0 for SCSI devices, always zero for network booting). For
-    both disk and network boots, () may be specified instead of (0,0,0).

-
The filename is optional for bootp/tftp and mop booting, since in
-    these cases the network protocol can be used to determine which file to
-    boot. When booting off the tape, no filename should be specified. When
-    booting off of disk, the filename is optional but is usually specified. If
-    no filename is specified when booting off disk, the following filenames are
-    tried in order: netbsd.pmax,
-    netbsd, netbsd.gz,
-    netbsd.bak, netbsd.old,
-    onetbsd, gennetbsd.
-    Generally, the kernel is named netbsd.

-
An example bootpath setting would be:

-
setenv bootpath
-  rz(0,1,0)netbsd

-
At the PROM prompt, the user may boot
-    NetBSD with either the auto
-    or the boot command. If the
-    auto command is used, the -a
-    argument is passed to the kernel, requesting a multi-user boot; otherwise
-    the -s argument is passed, requesting that
-    NetBSD boot to single user mode.

-
When either the boot or the
-    auto command is issued with no arguments, the kernel
-    specified in the bootpath environment variable is booted. With the
-    boot command, an alternative kernel may be specified
-    with the -f flag, followed by the path of the kernel
-    to boot, as described above. For example:

-
boot -f
-  rz(0,4,0)netbsd.new

-

-

-

-
On TURBOchannel machines (all DECstation 5000 models), the boot
-    path is specified in the boot environment variable, along with any arguments
-    to be passed to the kernel. Note that to specify boot arguments (e.g.,
-    -a) when setting the boot
-    environment variable, the filename and arguments must be enclosed in quotes.
-    For example:

-
setenv boot
-  “3/rz4/netbsd -a”

-
The device from which to boot is specified as the TURBOchannel
-    slot number, a TURBOchannel-option-specific device name, and a path to the
-    file to load, all separated by slashes. You can get a list of the devices
-    installed in your TURBOchannel slots (as well as any built-in devices which
-    appear as TURBOchannel slots) by typing the cnfg
-    command at the boot prompt. You can get more detailed information about a
-    specific TURBOchannel option by typing cnfg followed
-    by the slot number of that option.

-
For SCSI devices, the option-specific device identifier is either
-    rz# for disks or tz# for tapes, where # is the SCSI id of the device. For
-    network devices, the option-specific protocol identifier is either mop or
-    tftp. Filename requirements are as for the DECstation 2100 and 3100.

-
To start NetBSD from the boot prompt, the
-    boot command must be used. With no arguments, this
-    simply boots the default kernel with the default arguments as set with
-    setenv boot. If no boot
-    environment variable is set or if an alternative kernel is to be booted, the
-    path of that kernel may be specified after the boot command as described
-    above, and any arguments may be passed similarly. For example:

-
boot
-  3/rz4/netbsd.new -a

-

-

-

-
The kernel supports the following arguments:

-

-

-  

-  
Autoboot -- try and boot to multi-user mode without further input.

-  

-  
Use a miniroot already present in memory.

-  

-  
Prompt for the root file system device, the system crash dump device, and
-      the path to init(8).

-  

-  
Do not prompt for the root file system device, the system crash dump
-      device, and the path to init(8). If the configured-in
-      devices are present, use them.

-  

-  
Boot only to single-user mode.

-

-

-
Since DECstation PROMs also parse any arguments with a leading
-    "-", and reject unrecognized options, arguments other than
-    "a" or "s" should be specified after the kernel name
-    with no leading "-". For example:

-
boot 3/rz4/netbsd
-  ns

-

-

-

-
ddb(4), halt(8),
-    init(8), installboot(8),
-    rc(8), reboot(8),
-    savecore(8), shutdown(8)

-

-

-

-
The boot command is currently under
-    development.

-

-

-
-  
-    
-    
-  
-
April 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man8/man8.prep/boot.8 3.html b/static/netbsd/man8/man8.prep/boot.8 3.html
deleted file mode 100644
index aa126c52..00000000
--- a/static/netbsd/man8/man8.prep/boot.8 3.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (prep)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
-  
-    
-    
-  
-
boot

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed as described in fsck(8), and unless this fails,
-    the system will resume multi-user operations.

-

-

-

-
The prep architecture does not allow the direct booting of a
-    kernel from the hard drive. Instead it requires a complete boot image to be
-    loaded. This boot image contains a NetBSD kernel,
-    which will then provide access to the devices on the machine. The image can
-    be placed on any device that the firmware considers a bootable device.
-    Usually this is either a SCSI disk, tape, CD-ROM, or floppy drive.

-

-

-

-
The prep architecture and bootloader does not support any option
-    parsing at the boot prompt.

-

-

-

-
The prep port requires a special boot partition on the primary
-    boot device in order to load the kernel. This partition consists of a
-    PC-style i386 partition label, a small bootloader, and a kernel image. The
-    prep firmware looks for a partition of type 0x41 (65) and expects the
-    bootloader, immediately followed by the kernel, to be there. The
-    prep/mkbootimage(8) command needs to be used to generate
-    this image.

-

-

-

-

-

-  
/netbsd

-  
system code

-  
/usr/mdec/boot

-  
system bootstrap

-  
/usr/mdec/boot_com0

-  
system bootstrap with serial console

-

-

-

-

-
disklabel(8), fsck(8),
-    halt(8), init(8),
-    installboot(8), prep/mkbootimage(8),
-    rc(8), shutdown(8),
-    syslogd(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sandpoint/altboot.8 3.html b/static/netbsd/man8/man8.sandpoint/altboot.8 3.html
deleted file mode 100644
index dfd4be2d..00000000
--- a/static/netbsd/man8/man8.sandpoint/altboot.8 3.html	
+++ /dev/null
@@ -1,181 +0,0 @@
-
-  
-    
-    
-    
-  
-
ALTBOOT(8)System Manager's Manual (sandpoint)ALTBOOT(8)

-

-

-

-
altboot — program
-    to boot NetBSD kernel from disk or
-  network

-

-

-

-
altboot is a standalone program which
-    works on top of a NAS product's bootloader. It is capable of loading a
-    NetBSD kernel from an IDE or SATA disk drive, or via
-    network with NFS or TFTP protocol. altboot can be
-    stored in flash ROM. Typically you will first copy it from flash into RAM
-    and then invoke it there to boot the NetBSD
-  kernel.

-
altboot runs in conjunction with popular
-    U-Boot/PPCBoot bootloaders used by NAS products. With an appropriate boot
-    command line, saved in the environment, altboot can
-    load and start a NetBSD kernel without manual
-    intervention. The original U-Boot/PPCBoot bootloaders remain useful and
-    altboot works as a functional extension of them.

-

-

-

-
altboot occupies less than 128KB in volume
-    and can be stored to any vacant space of the system's flash. It is made to
-    run at RAM address offset 0x0100'0000. U-Boot/PPCboot is instructed to copy
-    the program to RAM in this way:

-

-
=> cp.b fffe0000 1000000
-  20000

-
Here 0xfffe'0000 is the flash address where
-    altboot is stored while 0x0100'0000 is the RAM
-    address to copy to.

-
The invocation syntax is:

-

-
=> go 1000000
-  ide:N opt1 opt2
-  ... bootname

-

-  
ide:N

-  
where N is a string of digits, which defines the
-      number of connected drives on each PATA channel. This option is useful to
-      avoid the delays, when altboot is trying to detect
-      a non-existing drive. Examples:
-    

-      
ide:10

-      
A single master drive on the first channel. Nothing on the second
-          channel.

-      
ide:22

-      
A master and slave drive on both channels of the first
-        controller.

-      
ide:1111

-      
A master drive on each channel. The first two digits belong to the
-          first controller, the last two to the second controller.

-    

-    
Unspecified digits will be read as 0.
-        The ide option has only a meaning for PATA disks.
-        Omitting it makes it default to ide:10.

-  

-  
optN

-  
multi, auto, ask, single, ddb, userconf, norm, quiet, verb, silent, debug
-    
Omitting optN makes altboot default to
-        multi-user mode boot.

-    
N.B., the maximum number of allowed go command arguments
-        varies and depends on the U-Boot/PPCBoot buildtime configuration.

-  

-  
bootname

-  
One of the following:
-    

-    
nfs:filename

-    
nfs:

-    
tftp:filename

-    
tftp:

-    
wdNp:filename

-    
wdNp

-    :
-    
mem:address

-    
net:

-    
The last one is a synonym for “nfs”.

-  

-  
nfs:filename

-  
issue a DHCP request to determine the IP address and download
-      filename from the NFS server.

-  
nfs:

-  
target file is determined by filename field of
-      /etc/dhcpd.conf

-  
tftp:filename

-  
issue a DHCP request to determine IP address and download
-      filename from the TFTP server.

-  
tftp:

-  
target file is determined by filename field of
-      /etc/dhcpd.conf

-  
wdNp:filename

-  
load the ELF NetBSD kernel
-      filename from an FFSv2 or FFSv1 filesystem.
-      N is a number to distinguish the target drive.
-      p is a partition specifier. When omitted, partition
-      ‘a’ is assumed. “wd0a” means partition
-      ‘a’ of the first disk drive.

-  
wdNp:

-  
use filename “netbsd” for booting the ELF
-      NetBSD kernel.

-  
mem:address

-  
boots the ELF NetBSD kernel from any address in
-      memory. The address argument has to be specified as
-      a hexadecimal number and denotes the start address of the ELF image in
-      memory.

-

-
altboot can boot from RAID 1 partitions,
-    but only if the RAID partition is the first partition on the disk.

-
U-Boot/PPCBoot provides a way to run a short list of commands
-    right after power-on. The following is a procedure to setup the system for
-    starting NetBSD after a 5 second delay, allowing the
-    user to break into interactive mode. Note that a backslashed
-    ‘;’ is necessary to enter the script correctly.

-

-
=> setenv bootcmd cp.b fffe0000 1000000 20000\; go 1000000 wd0:
-=> setenv bootdelay 5
-=> saveenv

-

-
When U-Boot/PPCBoot is lacking important commands like cp or go,
-    or is unable to save the environment, then there is still the option to
-    replace the Linux kernel module by altboot.img and
-    save it to the same address in flash ROM. In this case you have only two
-    options left to pass arguments:

-

-
    
-  
  • Enter the interactive command line mode, after
-      altboot has started. This requires a serial
-      console.
    • 
-  
  • Write a fixed command line into flash, replacing the Linux
-      initrd image. The command line is a normal ASCII file, started by the
-      identifier
-       and
-      terminated by any control character between 0 and 31. Example:
-    
    altboot:silent ide:1111
-      wd0:netbsd
    
-  
    • 
-

-

-

-

-
dhcpd(8), diskless(8),
-    nfsd(8), raidctl(8),
-    tftpd(8)

-

-

-

-
The NetBSD/sandpoint
-    altboot first appeared in NetBSD
-    6.0.

-

-

-

-
The Realtek Gigabit Ethernet driver does not work correctly at
-    1000 Mbps. Another known problem of this driver is that it runs into a
-    timeout after a coldstart. The system has to be rebooted at least once to
-    make it work.

-

-

-
-  
-    
-    
-  
-
October 7, 2013NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sgimips/boot.8 3.html b/static/netbsd/man8/man8.sgimips/boot.8 3.html
deleted file mode 100644
index 6729f911..00000000
--- a/static/netbsd/man8/man8.sgimips/boot.8 3.html	
+++ /dev/null
@@ -1,114 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (sgimips)BOOT(8)

-

-

-

-
boot — sgimips
-    system bootstrapping procedures

-

-

-

-
Silicon Graphics MIPS-based computers all feature essentially
-    similar firmware systems. However, as of the Indigo R4x00 series (IP20),
-    quasi- ARCS (Advanced RISC Computing Specification) compatible features are
-    also present. All known PROM implementations support loading executables
-    from disk devices, as well as from the network via BOOTP and TFTP.

-

-

-

-
SGI provides a small filesystem at the beginning of each bootable
-    disk called a Volume Header, which contains a boot loader and other
-    standalone utilities. Booting NetBSD requires that
-    we write our bootloader into to the volume header using
-    sgimips/sgivol(8).

-
Once a bootloader is present in the volume header, it may be
-    executed directly by the PROM either manually, or at boot time using the
-    “OSLoader” PROM environment variable. The
-    NetBSD bootloader will obtain the kernel filename to
-    boot from the PROM or EEPROM. This is specified by setting the PROM
-    environment variable “OSLoadFilename” to an appropriate value.
-    For instance, “/netbsd.ecoff”.

-
For example, the following will configure the PROM to use the
-    bootloader “aoutboot” to load the kernel
-    “netbsd.old”

-

-
setenv OSLoader
-  aoutboot

-
setenv
-  OSLoadFilename netbsd.old

-

-

-

-
The system firmware will obtain an IP address, TFTP server
-    address, and an optional filename from the BOOTP server and download it via
-    TFTP. The PROM's configurable network address environment variable
-    “netaddr” must match the address provided by the BOOTP
-  server.

-
An example BOOTP entry for dhcpd(8) follows:

-

-
	host indigo3k {
-		hardware ethernet 08:00:69:42:42:42;
-		fixed-address 192.168.0.2;
-		option host-name "indigo3k.foo";
-		#filename "/netbsd.ecoff";
-		next-server 192.168.0.1;
-		option root-path "/export/indigo3k/root";
-		server-name "192.168.0.1";
-	}

-

-
To boot a kernel named “netbsd.ecoff” the user would
-    type:

-
boot -f
-  bootp():/netbsd.ecoff

-
See dhcpd.conf(5) for more information on
-    configuring dhcpd(8) as a BOOTP server.

-

-

-

-
dhcpd.conf(5), dhcpd(8),
-    sgimips/sgivol(8)

-

-

-

-
Some older PROM revisions do not support loading of ELF images.
-    The build system automatically prepares ECOFF versions, which are correctly
-    interpreted.

-

-

-

-
NetBSD does not support booting from disk
-    on systems lacking an ARCS-compatible firmware (presently supported systems
-    include Personal Iris and Indigo R3000). It is possible to work around this
-    by creating a sufficiently large volume header and placing the kernel in it,
-    or by network booting.

-
Some firmware revisions have a bug, which precludes them from
-    communicating with TFTP servers using ports above 32767. When using
-    NetBSD as the TFTP server, this problem may be
-    worked around as follows:

-

-
sysctl -w
-  net.inet.ip.anonportmin=20000

-
sysctl -w
-  net.inet.ip.anonportmax=32767

-
Another bug exists in some firmware revisions, which precludes the
-    PROM from communicating with TFTP servers that employ PMTU (Path MTU)
-    discovery. This bug may be worked around by disabling PMTU on the TFTP
-    server. This does not presently affect NetBSD
-    servers.

-
This man page is horribly incomplete.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sgimips/sgivol.8 3.html b/static/netbsd/man8/man8.sgimips/sgivol.8 3.html
deleted file mode 100644
index 3fe273d2..00000000
--- a/static/netbsd/man8/man8.sgimips/sgivol.8 3.html	
+++ /dev/null
@@ -1,163 +0,0 @@
-
-  
-    
-    
-    
-  
-
SGIVOL(8)System Manager's Manual (sgimips)SGIVOL(8)

-

-

-

-
/usr/mdec/sgivol —
-    configure SGI Volume Header

-

-

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] device

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] -i
-      [-h vhsize]
-      device

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] -r
-      vhfilename diskfilename
-      device

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] -w
-      vhfilename diskfilename
-      device

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] -d
-      vhfilename device

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] -m
-      vhfilename vhfilename
-      device

-

-
-  
-    
-    
-  
-
/usr/mdec/sgivol[-fq] -p
-      partno partfirst
-      partblocks parttype
-      device

-

-

-

-
The /usr/mdec/sgivol program prepares an
-    SGI Volume Header to be used to boot NetBSD. The SGI
-    PROM is able to load executables within the header, which in turn are used
-    to load the kernel from another file system.

-

-

-

-
The following options are available:

-

-  

-  
Force the operation. Do not ask the user before proceeding.

-  

-  
Set the size of the newly initialized volume header in blocks. One block
-      is 512 bytes. The default volume header size is 3135 blocks (1.53MB).

-  

-  
Suppress output.

-

-

-

-

-
The numerical partition types for the volume header include:

-

-
	 0:	Volume Header
-	 1:	Replicated Tracks
-	 2:	Replicated Sectors
-	 3:	Raw
-	 4:	BSD4.2 file system
-	 5:	SysV file system
-	 6:	Entire Volume (all disk blocks)
-	 7:	EFS
-	 8:	Logical Volume
-	 9:	Raw Logical Volume
-	10:	XFS
-	11:	XFS Log
-	12:	XLV Volume
-	13:	XVM Volume

-

-

-

-

-
To display the existing volume header and partition table on disk
-    “sd0”:

-
sgivol
-  sd0

-
To initialize a new volume header 42 512-byte blocks large on disk
-    “sd0”:

-
sgivol -i -h 42
-  sd0

-
To copy a file boot from the volume header
-    to local file /tmp/boot on disk
-  “sd0”:

-
sgivol -r boot
-  /tmp/boot sd0

-
To copy a local file /usr/mdec/ip2xboot to
-    the volume header as boot on disk
-    “sd0”:

-
sgivol -w boot
-  /usr/mdec/ip2xboot sd0

-
To delete the existing file boot from the
-    volume header on disk “sd0”:

-
sgivol -d boot
-  sd0

-
To move (rename) an existing file file1 to
-    file2 in the volume header on disk
-    “sd0”:

-
sgivol -m file1
-  file2 sd0

-
To change partition 0 to type 4 (BSD4.2) beginning at block offset
-    3200 and continue for 28000 blocks on disk “sd0”:

-
sgivol -p 0 3200
-  28000 4 sd0

-

-

-

-
sgimips/boot(8)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sparc/binstall.8 3.html b/static/netbsd/man8/man8.sparc/binstall.8 3.html
deleted file mode 100644
index e1a4e4ab..00000000
--- a/static/netbsd/man8/man8.sparc/binstall.8 3.html	
+++ /dev/null
@@ -1,84 +0,0 @@
-
-  
-    
-    
-    
-  
-
BINSTALL(8)System Manager's Manual (sparc)BINSTALL(8)

-

-

-

-
/usr/mdec/binstall —
-    install sparc and sparc64 boot blocks

-

-

-

-
-  
-    
-    
-  
-
/usr/mdec/binstall[-htUuv] [-b
-      bootprog] [-f
-      filesystem] [-m
-      mdec] [-i
-      installbootprog] [“net” |
-      “ffs”] [directory]

-

-

-

-
The /usr/mdec/binstall program prepares a
-    sparc or sparc64 system for booting, either from local disk from a
-    “ffs” partition or over the network. The default type of boot
-    block installed is derived from the host system. If it is an UltraSPARC, the
-    sparc64 boot blocks will be used, otherwise the SPARC boot blocks will be
-    used. /usr/mdec/binstall can be forced to prepare a
-    disk for either.

-

-

-

-
The following options are available:

-

-  

-  
Set the second stage boot program to bootprog. This
-      will typically be boot.net for sparc systems and
-      ofwboot.net for sparc64 systems.

-  

-  
Set the path to the filesystem being installed for to
-      filesystem. This is otherwise derived from the
-      [directory].

-  

-  
Display help.

-  

-  
Set the path to the installboot(8) program to
-      installbootprog. This is useful for using
-      /usr/mdec/binstall on non-sparc or sparc64
-      systems.

-  

-  
Sets the path to the machine dependent directory to
-      mdec. This is the directory that both the boot
-      blocks and the installboot(8) program live.

-  

-  
Test mode; does not run any program. Implies the
-      -v option.

-  

-  
Install sparc (SPARC) boot blocks.

-  

-  
Install sparc64 (UltraSPARC) boot blocks.

-  

-  
Be verbose.

-

-

-

-

-
disklabel(8),
-  installboot(8)

-

-

-
-  
-    
-    
-  
-
January 6, 2002NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sparc/boot.8 3.html b/static/netbsd/man8/man8.sparc/boot.8 3.html
deleted file mode 100644
index 8fc56545..00000000
--- a/static/netbsd/man8/man8.sparc/boot.8 3.html	
+++ /dev/null
@@ -1,214 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (sparc)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
-  
-    
-    
-  
-
boot[-adqsv] [--
-      ⟨boot string⟩]

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed as described in fsck(8), and unless this fails,
-    the system will resume multi-user operations.

-

-

-

-
The Sun boot firmware, either old-style or new-style (Open Boot
-    Prom), performs a Power On Self Test (POST), and then will boot an operating
-    system according to configuration in Open Firmware environment
-  variables.

-

-

-

-

-  

-  
Prompt for the root file system device, the system crash dump device, and
-      the path to init(8).

-  

-  
Bring the system up in debug mode. Here it waits for a kernel debugger
-      connect; see gdb(1).

-  

-  
Boot kernel in compat mode. Starting with revision 1.14 (introduced on
-      2003/03/01), the sparc boot program loads the
-      NetBSD kernel at its linked virtual address. This
-      feature requires a kernel built after 2003/02/21 (corresponding to kernel
-      version 1.6Q). To load older kernels, the -C
-      option must be used, which loads the kernel at physical address 0x4000.
-      The size of a kernel loaded in this way is limited to approximately
-    3MB.

-  

-  
Boot the system in quiet mode.

-  

-  
Bring the system up in single-user mode.

-  

-  
Boot the system in verbose mode.

-

-
Any extra flags or arguments, or the ⟨boot
-    string⟩ after the -- separator are passed to the boot PROM.
-    Other flags are currently ignored.

-
The SPARC boot ROM comes in two flavours: an
-    “old-style” ROM is used in sun4 machines, while a
-    “new-style” ROM can be found on sun4c and sun4m models. The
-    “new-style” SPARC boot ROM is a full-featured Forth system
-    with emacs key bindings. It can be put in “old-style”
-    user-interface compatibility mode (in which case it shows a simple
-    ‘>’ prompt), but this is essentially useless. However, by
-    default on sun4c models, the ROM runs in old-mode; to enter new-mode type
-    ‘n’. The ROM then shows a Forth-style “ok”
-    prompt. It is recommended to have the ROM always start in its native
-    “new-style” mode. Utter the following incantation in new-mode
-    to force the ROM to always start in new-mode.

-
	ok setenv sunmon-compat? false

-
The ROM will normally load the kernel from
-    “sd(0,0,0)vmunix”. To change the default so that
-    NetBSD will be loaded from somewhere else, type the
-    following

-
	ok setenv boot-from sd(0,0,0)netbsd

-
On newer SPARC machines, there are various aliases to access
-    common devices. A typical list of usable boot devices (extracted from the
-    output of the Open Boot PROM command devalias)
-  is:

-

-
floppy         /obio/SUNW,fdtwo
-net-aui        /iommu/sbus/ledma@f,400010:aui/le@f,c00000
-net-tpe        /iommu/sbus/ledma@f,400010:tpe/le@f,c00000
-net            /iommu/sbus/ledma@f,400010/le@f,c00000
-disk           /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0
-cdrom          /iommu/sbus/espdma@f,400000/esp@f,800000/sd@6,0:d
-tape           /iommu/sbus/espdma@f,400000/esp@f,800000/st@4,0
-tape1          /iommu/sbus/espdma@f,400000/esp@f,800000/st@5,0
-tape0          /iommu/sbus/espdma@f,400000/esp@f,800000/st@4,0
-disk3          /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0
-disk2          /iommu/sbus/espdma@f,400000/esp@f,800000/sd@2,0
-disk1          /iommu/sbus/espdma@f,400000/esp@f,800000/sd@1,0
-disk0          /iommu/sbus/espdma@f,400000/esp@f,800000/sd@0,0

-

-
For new-style machines, if a device specification
-    includes a partition letter (for example
-     in above
-    list), that partition is used by default, otherwise the first (a) partition
-    is used. If booting from the net device, there is no partition involved.

-
At any time you can break back to the ROM by pressing the
-    ‘L1’ and ‘a’ keys at the same time (if the
-    console is a serial port the same is achieved by sending a
-    ‘break’). If you do this accidentally you can continue
-    whatever was in progress by typing ‘go’.

-

-

-

-

-
This section only applies to new-style machines.

-
All Open Boot PROM environment variables can be printed with the
-    printenv command and changed with the
-    setenv command. The boot process relevant variables
-    and their suggested value for booting NetBSD
-  are:

-

-
auto-boot?            true
-boot-file
-boot-device           disk
-diag-switch?          false

-

-
Of course you may select any other boot device, if you
-    do not want to boot from the device aliased to
-    , see the
-    discussion on devices above.

-

-

-

-
This section only applies to new-style machines.

-
The following Open Boot PROM commands are related to the boot
-    process:

-

-
boot               boot the system from the default device
-boot device filename arguments
-                   boot the specified device, filename and arguments
-probe-ide          list devices on the primary IDE controller
-probe-ide-all      list devices on all known IDE controllers
-probe-scsi         list devices on the primary SCSI controller
-probe-scsi-all     list devices on all known SCSI controllers
-reset              reset the system

-

-For disk and tape devices, the boot device is specified as
-  ‘/path/device@target,lun:partition’.
-

-

-

-
This section only applies to old-style machines.

-
The following PROM monitor commands are related to the boot
-    process:

-

-
b       boot the system from the default device
-b device filename arguments
-        boot the specified device, filename and arguments
-b?      list boot device types
-k2      reset the system

-

-
For SCSI disk and tape devices, the boot device is specified as
-    ‘device(controller,unit,partition)’, where
-    ‘unit’ is the hexadecimal value of the SCSI id of the target
-    multiplied by eight plus the lun, and ‘partition’ is the
-    partition number, starting from 0.

-

-

-

-

-  
/netbsd

-  
system code

-  
/boot

-  
system bootstrap

-

-

-

-

-
crash(8), disklabel(8),
-    fsck(8), halt(8),
-    init(8), installboot(8),
-    rc(8), shutdown(8),
-    sparc64/boot(8), syslogd(8)

-

-

-

-
On sun4 machines, the NetBSD sparc boot
-    loader can only boot from RAID partitions that start at the beginning of the
-    disk.

-
On sun4 and early PROM version sun4c machines, the PROM can only
-    boot from the first 1Gb of the disk.

-
On later PROM version sun4c and early PROM version sun4m machines,
-    the PROM can only boot from the first 2Gb of the disk.

-
On later PROM version sun4m machines, the PROM can only boot from
-    the first 4Gb of the disk.

-

-

-
-  
-    
-    
-  
-
June 17, 2006NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sparc64/boot.8 3.html b/static/netbsd/man8/man8.sparc64/boot.8 3.html
deleted file mode 100644
index 678b466a..00000000
--- a/static/netbsd/man8/man8.sparc64/boot.8 3.html	
+++ /dev/null
@@ -1,205 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (sparc64)BOOT(8)

-

-

-

-
boot, ofwboot
-    — system bootstrapping procedures

-

-

-

-
-  
-    
-    
-  
-
boot[-adqsv] [--
-      ⟨boot string⟩]

-

-

-

-
Sun UltraSPARC systems support booting from locally attached
-    storage media (e.g. hard disk, CD-ROM), and booting over Ethernet networks
-    using BOOTP.

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed as described in fsck(8), and unless this fails,
-    the system will resume multi-user operations.

-

-

-

-
The Sun Open Firmware performs a Power On Self Test (POST), and
-    then will boot an operating system according to configuration in Open
-    Firmware environment variables.

-

-

-

-

-  

-  
Prompt for the root file system device, the system crash dump device, and
-      the path to init(8).

-  

-  
Bring the system up in debug mode. Here it waits for a kernel debugger
-      connect; see gdb(1).

-  

-  
Boot the system in quiet mode.

-  

-  
Bring the system up in single-user mode.

-  

-  
Boot the system in verbose mode.

-

-
Any extra flags or arguments, or the ⟨boot
-    string⟩ after the -- separator are passed to the boot PROM.
-    Other flags are currently ignored.

-
At any time you can halt the running system and get back to the
-    Open Firmware. If the console is the Sun framebuffer and keyboard, press the
-    ‘STOP’ and ‘A’ keys at the same time on the
-    keyboard. On older models of Sun keyboards, the ‘STOP’ key is
-    labeled ‘L1’.

-
If the console is a serial port the same is achieved by sending a
-    ‘BREAK’.

-
If you do this accidentally, you can continue whatever was in
-    progress with the go command.

-

-

-

-

-
Since machines vary greatly in the way their devices are
-    connected, there are aliases defined by the firmware. You can either use the
-    fully qualified Open Firmware path of a device node, or the alias.

-
The secondary boot loader, ofwboot, takes
-    boot commands virtually the same as Open Firmware.
-    Thus, the following examples apply equally to
-    ofwboot as well as Open Firmware.

-
A typical list of usable boot devices (extracted from the output
-    of the Open Firmware command devalias) is:

-

-
net                      /sbus/SUNW,hme@e,8c00000
-disk                     /sbus/SUNW,fas@e,8800000/sd@0,0
-cdrom                    /sbus/SUNW,fas@e,8800000/sd@6,0:f
-disk6                    /sbus/SUNW,fas@e,8800000/sd@6,0
-disk5                    /sbus/SUNW,fas@e,8800000/sd@5,0
-disk4                    /sbus/SUNW,fas@e,8800000/sd@4,0
-disk3                    /sbus/SUNW,fas@e,8800000/sd@3,0
-disk2                    /sbus/SUNW,fas@e,8800000/sd@2,0
-disk1                    /sbus/SUNW,fas@e,8800000/sd@1,0
-disk0                    /sbus/SUNW,fas@e,8800000/sd@0,0

-

-
If a device specification includes a partition letter
-    (for example 
-    in above list), that partition is used by default, otherwise the first (a)
-    partition is used. If booting from the net device, there is no partition
-    involved.

-
The boot device is an optional first part of the boot string, if
-    no device is specified the default device is used (see below).

-

-

-

-
All Open Firmware environment variables can be printed with the
-    printenv command and changed with the
-    setenv command. The boot process relevant variables
-    and their suggested value for booting NetBSD
-  are:

-

-
boot-command          boot
-auto-boot?            true
-boot-file
-boot-device           disk
-diag-switch?          false

-

-
Of course you may select any other boot device, if you
-    do not want to boot from the device aliased to
-    , see the
-    discussion on devices above.

-

-

-

-

-  
/netbsd

-  
system code

-  
/ofwboot

-  
system bootstrap

-  
/usr/mdec/ofwboot.net

-  
alternate bootstrap when booting from the network, see
-      diskless(8) for details.

-

-

-

-

-
Boot from CD-ROM:

-

-
boot cdrom

-

-
Note that some multi-architecture CDs are not able to use the
-    default sparc64 partition for CD-ROMs (f), so they may require an explicit
-    partition letter, for example

-

-
boot cdrom:c

-

-
When using external SCSI CD-ROM drives it is important to know two
-    things: the Sun firmware expects the SCSI ID to be six, and the drive must
-    support 512-byte block reads, in addition to the standard 2048-byte
-  reads.

-
Use

-

-
boot net -sd

-

-
to boot single user from network and break into the kernel
-    debugger as soon as possible.

-
Use

-

-
boot net tftp:netbsd -a

-

-
to boot a kernel named netbsd obtained via tftp and have it ask
-    for root file system, swap partition and init location once it is up.

-
During installation from a different operating system

-

-
boot disk:b

-

-
is used to boot a “miniroot” file system from the
-    swap partition.

-

-

-

-
disklabel(8), diskless(8),
-    fsck(8), halt(8),
-    init(8), installboot(8),
-    rc(8), shutdown(8),
-    sparc/boot(8), syslogd(8)

-

-

-

-
Sun developed its firmware and promoted it to become
-    IEEE Std 1275-1994 (“Open
-  Firmware”).

-
IEEE 1275
-    Open Firmware

-

-

-

-
NetBSD provides no way to boot UltraSPARC
-    systems from floppy disks. This is unlikely to change, due to very low
-    demand for this feature.

-
The OBP on Ultra 1 and Ultra 2 machines can only boot from the
-    first 4Gb of the disk.

-

-

-
-  
-    
-    
-  
-
November 9, 2008NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sun2/boot.8 3.html b/static/netbsd/man8/man8.sun2/boot.8 3.html
deleted file mode 100644
index a35eab08..00000000
--- a/static/netbsd/man8/man8.sun2/boot.8 3.html	
+++ /dev/null
@@ -1,137 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (sun2)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
-  
-    
-    
-  
-
b[dev [(cntrl,
-      unit, part)]]
-      [file] [-adqsv]

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed as described in fsck(8), and unless this fails,
-    the system will resume multi-user operations.

-

-

-

-
Normally, the b command alone is
-    sufficient to boot the system, as the PROM chooses a default boot device
-    dev if none is specified. The PROM chooses the first
-    device present on the system from the following ordered list:

-

-

-
sd	SCSI disk
-ie	Intel Ethernet
-ec	3Com Ethernet

-

-
Unless specified, the controller number
-    cntrl, unit number unit, and
-    partition number part default to zero, which is almost
-    always correct.

-
The controller number can be specified if there is more than one
-    of the given device in the system. For example, use “ie(1,,)”
-    to boot off of the second Intel Ethernet in the system.

-
The unit number specifies one of the many devices attached to a
-    controller. The exact meaning and values vary depending on the device name.
-    For example, “sd(,18,)” boots the disk at target 6 on the
-    first SCSI controller, 18 being the target number 6, multiplied by 4, and
-    given in hexadecimal.

-
The partition number specifies one of the many partitions on a
-    device. The exact meaning and values vary depending on the device name. For
-    example, “sd(,18,1)” boots the second partition on the disk at
-    target 6 on the first SCSI controller.

-
The PROM only loads a first-stage boot program, currently either
-    /usr/mdec/bootxx (for a disk boot), or
-    /usr/mdec/bootyy (for a network boot). This
-    first-stage boot program then loads the second-stage boot program from the
-    same device, currently either /usr/mdec/ufsboot (for
-    a disk boot), or /usr/mdec/netboot (for a network
-    boot).

-
The second-stage boot program will then attempt to load the kernel
-    named file (or vmunix if none
-    is specified). The second-stage disk boot program
-    /usr/mdec/ufsboot loads the kernel from the same
-    device that it was loaded from, while the second-stage network boot program
-    /usr/mdec/netboot will load the kernel from the NFS
-    root as determined by the procedure described in
-    diskless(8).

-

-

-

-

-  

-  
Prompt for the root file system device, the system crash dump device, and
-      the path to init(8).

-  

-  
Bring the system up in debug mode. Here it waits for a kernel debugger
-      connect; see ddb(4).

-  

-  
Boot the system in quiet mode.

-  

-  
Bring the system up in single-user mode.

-  

-  
Boot the system in verbose mode.

-

-
Other flags are currently ignored.

-
At any time you can break back to the ROM by pressing the
-    ‘L1’ and ‘a’ keys at the same time (if the
-    console is a serial port the same is achieved by sending a
-    ‘break’). If you do this accidentally you can continue
-    whatever was in progress by typing ‘c’ followed by the return
-    key.

-

-

-

-

-

-  
/netbsd

-  
system code

-  
/usr/mdec/bootxx

-  
first-level boot block for disks

-  
/usr/mdec/bootyy

-  
first-level boot block for NFS (diskless) boot

-  
/usr/mdec/netboot

-  
boot program for NFS (diskless) boot

-  
/usr/mdec/ufsboot

-  
second-level boot program for UFS disks

-  
/usr/sbin/installboot

-  
program to install bootxx on a disk

-

-

-

-

-
crash(8), disklabel(8),
-    fsck(8), halt(8),
-    init(8), rc(8),
-    shutdown(8), syslogd(8)

-

-

-
-  
-    
-    
-  
-
April 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man8/man8.sun3/boot.8 3.html b/static/netbsd/man8/man8.sun3/boot.8 3.html
deleted file mode 100644
index d551add9..00000000
--- a/static/netbsd/man8/man8.sun3/boot.8 3.html	
+++ /dev/null
@@ -1,92 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (sun3)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed as described in fsck(8), and unless this fails,
-    the system will resume multi-user operations.

-

-

-

-
A disk-boot program (/usr/mdec/ufsboot)
-    will attempt to load netbsd from partition A of the
-    boot device, which must currently be an “sd” disk.
-    Alternatively, network boot program
-    (/usr/mdec/netboot) will load
-    netbsd from the NFS root as determined by the
-    procedure described in diskless(8).

-

-

-

-

-  

-  
Prompt for the root file system device, the system crash dump device, and
-      the path to init(8).

-  

-  
Bring the system up in debug mode. Here it waits for a kernel debugger
-      connect; see ddb(4).

-  

-  
Boot the system in quiet mode.

-  

-  
Bring the system up in single-user mode.

-  

-  
Boot the system in verbose mode.

-

-
Any extra flags or arguments, or the ⟨boot
-    string⟩ after the -- separator are passed to the boot PROM.
-    Other flags are currently ignored.

-
At any time you can break back to the ROM by pressing the
-    ‘L1’ and ‘a’ keys at the same time (if the
-    console is a serial port the same is achieved by sending a
-    ‘break’). If you do this accidentally you can continue
-    whatever was in progress by typing ‘c’ followed by the return
-    key.

-

-

-

-

-

-  
/netbsd

-  
system code

-  
/usr/mdec/bootxx

-  
first-level boot block for disks

-  
/usr/mdec/netboot

-  
boot program for NFS (diskless) boot

-  
/usr/mdec/ufsboot

-  
second-level boot program for UFS disks

-  
/usr/mdec/installboot

-  
program to install bootxx on a disk

-

-

-

-

-
disklabel(8), fsck(8),
-    halt(8), init(8),
-    rc(8), shutdown(8),
-    syslogd(8)

-

-

-
-  
-    
-    
-  
-
April 8, 2003NetBSD 10.1

diff --git a/static/netbsd/man8/man8.vax/boot.8 3.html b/static/netbsd/man8/man8.vax/boot.8 3.html
deleted file mode 100644
index 4b27750d..00000000
--- a/static/netbsd/man8/man8.vax/boot.8 3.html	
+++ /dev/null
@@ -1,190 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (vax)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. Provided the auto-restart is enabled on the machine front panel, an
-    automatic consistency check of the file systems will be performed, and
-    unless this fails, the system will resume multi-user operations.

-

-

-

-
These are processor-type dependent. On an 11/780, there are two
-    floppy files for each disk controller, both of which cause boots from unit 0
-    of the root file system of a controller located on mba0 or uba0. One gives a
-    single user shell, while the other invokes the multi-user automatic reboot.
-    Thus these files are HPS and HPM for the single and multi-user boot from
-    MASSBUS RP06/RM03/RM05 disks, UPS and UPM for UNIBUS storage module
-    controller and disks such as the EMULEX SC-21 and AMPEX 9300 pair, RAS and
-    RAM to boot from MSCP controllers and disks such as the RA81, or HKS and HKM
-    for RK07 disks. There is also a script for booting from the default device,
-    which is normally a copy of one of the standard multi-user boot scripts, but
-    which may be modified to perform other actions or to boot from a different
-    unit. The situation on the 8600 is similar, with scripts loaded from the
-    console RL02.

-
Giving the command

-

-
>>>BOOT HPM

-
would boot the system from (e.g.) an RP06 and run the automatic
-    consistency check as described in fsck(8). (Note that it
-    may be necessary to type control-P and halt the processor to gain the
-    attention of the LSI-11 before getting the >>> prompt.) The
-  command

-

-
>>>BOOT ANY

-
invokes a version of the boot program in a way which allows you to
-    specify any system as the system to be booted. It reads from the console a
-    device specification (see below) followed immediately by a pathname.

-
The scripts may be modified for local configuration if necessary.
-    The flags are placed in register 11 (as defined in
-    <sys/reboot.h>). The boot
-    device is specified in register 10. The encoding of this register is also
-    defined in <sys/reboot.h>.
-    The current encoding has a historical basis, and is shown in the following
-    table:

-

-

-
bits	usage
-0-7	boot device type (the device major number)
-8-15	disk partition
-16-19	drive unit
-20-23	controller number
-24-27	adaptor number (UNIBUS or MASSBUS as appropriate)

-

-
The adaptor number corresponds to the normal configuration on the
-    11/750, and to the order in which adaptors are found on the 11/780 and 8600
-    (generally the same as the numbers used by
-  UNIX).

-
On an 11/750, the reset button will boot from the device selected
-    by the front panel boot device switch. In systems with RK07's, position B
-    normally selects the RK07 for boot. This will boot multi-user. To boot from
-    RK07 with boot flags you may specify

-

-

-
>>>B/-n DMA0

-

-
where, giving a n of 1 causes the boot
-    program to ask for the name of the system to be bootstrapped, giving a
-    n of 2 causes the boot program to come up single user,
-    and a n of 3 causes both of these actions to occur.
-    The ``DM'' specifies RK07, the ``A'' represents the adaptor number (UNIBUS
-    or MASSBUS), and the ``0'' is the drive unit number. Other disk types which
-    may be used are DB (MASSBUS), DD (TU58), and DU (UDA-50/RA disk). A non-zero
-    disk partition can be used by adding (partition times 1000 hex) to
-    n.

-
The boot procedure on the Micro VAX II is similar. A switch on the
-    back panel sets the power-up action to autoboot or to halt. When halted, the
-    processor may be booted using the same syntax as on the 11/750.

-
The 11/750 boot procedure uses the boot ROMs to load block 0 off
-    of the specified device. The /usr/mdec directory
-    contains a number of bootstrap programs for the various disks which should
-    be placed in a new pack by disklabel(8). Similarly, the
-    Micro VAX II boot procedure loads a boot parameter block from block 0 of the
-    disk. The rdboot “bootstrap” contains
-    the correct parameters for an MSCP disk such as the RD53.

-
On any processor, the boot program finds the
-    corresponding file on the given device (netbsd by
-    default), loads that file into memory location zero, and starts the program
-    at the entry address specified in the program header (after clearing off the
-    high bit of the specified entry address).

-
The file specifications used with “BOOT ANY” or
-    “B/3” are of the form:

-

-
device(adaptor,controller,unit,minor)

-
where device is the type of the device to be
-    searched, adaptor is the UNIBUS or MASSBUS number of
-    the adaptor to which the device is attached,
-    controller is the unit number of the controller or
-    MASSBUS tape formatter on that adaptor, unit is the
-    unit number of the disk or transport slave unit of the tape, and
-    minor is the disk partition or tape file number.
-    Leading adaptor or controller numbers default to 0. Normal line editing
-    characters can be used when typing the file specification. The following
-    list of supported devices may vary from installation to installation:

-

-

-
hp	MASSBUS disk drive
-up	UNIBUS storage module drive
-ht	TE16,TU45,TU77 on MASSBUS
-kra	storage module on a KDB50
-mt	TU78 on MASSBUS
-hk	RK07 on UNIBUS
-ra	storage module on a MSCP-compatible UNIBUS controller
-rb	storage module on a 730 IDC
-rl	RL02 on UNIBUS
-tm	TM11 emulation tape drives on UNIBUS
-tms	TMSCP-compatible tape
-ts	TS11 on UNIBUS
-ut	UNIBUS TU45 emulator

-

-
For example, to boot from a file system which starts at cylinder 0
-    of unit 0 of a MASSBUS disk, type
-    ‘hp(0,0)netbsd’ to the boot prompt;
-    ‘hp(2,0,1,0)netbsd’ would specify
-    drive 1 on MASSBUS adaptor 2;
-    ‘up(0,0)netbsd’ would specify a UNIBUS
-    drive, ‘hk(0,0)netbsd’ would specify
-    an RK07 disk drive,
-    ‘ra(1,0,0,0)netbsd’ would specify a
-    UDA50 disk drive on a second UNIBUS, and
-    ‘rb(0,0)netbsd’ would specify a disk
-    on a 730 IDC. For tapes, the minor device number gives a file offset;
-    ‘mt(1,2,3,4)’ would specify the fifth
-    file on slave 3 of the formatter at
-    ‘drive’ 2 on mba 1.

-
On an 11/750 with patchable control store, microcode patches will
-    be installed by boot if the file
-    pcs750.bin exists in the root of the filesystem from
-    which the system is booted.

-
In an emergency, the bootstrap methods described in the paper
-    Installing and Operating 4.3bsd can be used to boot
-    from a distribution tape.

-

-

-

-

-

-  
/netbsd

-  
system code

-  
/boot

-  
system bootstrap

-  
/usr/mdec/xxboot

-  
sector 0-15 boot block

-  
/pcs750.bin

-  
microcode patch file on 750

-

-

-

-

-
arff(8), halt(8),
-    reboot(8), shutdown(8)

-

-

-

-
The boot command appeared in
-    4.0BSD.

-

-

-
-  
-    
-    
-  
-
April 19, 1994NetBSD 10.1

diff --git a/static/netbsd/man8/man8.vax/crash.8 2.html b/static/netbsd/man8/man8.vax/crash.8 2.html
deleted file mode 100644
index c24425b8..00000000
--- a/static/netbsd/man8/man8.vax/crash.8 2.html	
+++ /dev/null
@@ -1,175 +0,0 @@
-
-  
-    
-    
-    
-  
-
CRASH(8)System Manager's Manual (vax)CRASH(8)

-

-

-

-
crash — UNIX
-    system failures

-

-

-

-
This section explains what happens when the system crashes and
-    (very briefly) how to analyze crash dumps.

-
When the system crashes voluntarily it prints a message of the
-    form

-

-
panic: why i gave up the
-  ghost

-
on the console, takes a dump on a mass storage peripheral, and
-    then invokes an automatic reboot procedure as described in
-    reboot(8). (If auto-reboot is disabled on the front panel
-    of the machine the system will simply halt at this point.) Unless some
-    unexpected inconsistency is encountered in the state of the file systems due
-    to hardware or software failure, the system will then resume multi-user
-    operations.

-
The system has a large number of internal consistency checks; if
-    one of these fails, then it will panic with a very short message indicating
-    which one failed. In many instances, this will be the name of the routine
-    which detected the error, or a two-word description of the inconsistency. A
-    full understanding of most panic messages requires perusal of the source
-    code for the system.

-
The most common cause of system failures is hardware failure,
-    which can reflect itself in different ways. Here are the messages which are
-    most likely, with some hints as to causes. Left unstated in all cases is the
-    possibility that hardware or software error produced the message in some
-    unexpected way.

-

-  
iinit

-  
This cryptic panic message results from a failure to mount the root
-      filesystem during the bootstrap process. Either the root filesystem has
-      been corrupted, or the system is attempting to use the wrong device as
-      root filesystem. Usually, an alternative copy of the system binary or an
-      alternative root filesystem can be used to bring up the system to
-      investigate.

-  
Can't exec /sbin/init

-  
This is not a panic message, as reboots are likely to be futile. Late in
-      the bootstrap procedure, the system was unable to locate and execute the
-      initialization process, init(8). The root filesystem is
-      incorrect or has been corrupted, or the mode or type of /sbin/init forbids
-      execution.

-  
IO err in push

-  
 

-  
hard IO err in swap

-  
The system encountered an error trying to write to the paging device or an
-      error in reading critical information from a disk drive. The offending
-      disk should be fixed if it is broken or unreliable.

-  
realloccg: bad optim

-  
 

-  
ialloc: dup alloc

-  
 

-  
alloccgblk: cyl groups corrupted

-  
 

-  
ialloccg: map corrupted

-  
 

-  
free: freeing free block

-  
 

-  
free: freeing free frag

-  
 

-  
ifree: freeing free inode

-  
 

-  
alloccg: map corrupted

-  
These panic messages are among those that may be produced when filesystem
-      inconsistencies are detected. The problem generally results from a failure
-      to repair damaged filesystems after a crash, hardware failures, or other
-      condition that should not normally occur. A filesystem check will normally
-      correct the problem.

-  
timeout table overflow

-  
This really shouldn't be a panic, but until the data structure involved is
-      made to be extensible, running out of entries causes a crash. If this
-      happens, make the timeout table bigger.

-  
KSP not valid

-  
 

-  
SBI fault

-  
 

-  
CHM? in kernel

-  
These indicate either a serious bug in the system or, more often, a glitch
-      or failing hardware. If SBI faults recur, check out the hardware or call
-      field service. If the other faults recur, there is likely a bug somewhere
-      in the system, although these can be caused by a flakey processor. Run
-      processor microdiagnostics.

-  
machine check %x:
-    

-  
 

-  
   machine dependent machine-check information

-  
Machine checks are different on each type of CPU. Most of the internal
-      processor registers are saved at the time of the fault and are printed on
-      the console. For most processors, there is one line that summarizes the
-      type of machine check. Often, the nature of the problem is apparent from
-      this message and/or the contents of key registers. The VAX Hardware
-      Handbook should be consulted, and, if necessary, your friendly field
-      service people should be informed of the problem.

-  
trap type %d, code=%x, pc=%x

-  
A unexpected trap has occurred within the system; the trap types are:
-    

-    
0	reserved addressing fault
-1	privileged instruction fault
-2	reserved operand fault
-3	bpt instruction fault
-4	xfc instruction fault
-5	system call trap
-6	arithmetic trap
-7	ast delivery trap
-8	segmentation fault
-9	protection fault
-10	trace trap
-11	compatibility mode fault
-12	page fault
-13	page table fault

-    

-    
The favorite trap types in system crashes are trap types 8 and
-        9, indicating a wild reference. The code is the referenced address, and
-        the pc at the time of the fault is printed. These problems tend to be
-        easy to track down if they are kernel bugs since the processor stops
-        cold, but random flakiness seems to cause this sometimes. The debugger
-        can be used to locate the instruction and subroutine corresponding to
-        the PC value. If that is insufficient to suggest the nature of the
-        problem, more detailed examination of the system status at the time of
-        the trap usually can produce an explanation.

-  

-  
init died

-  
The system initialization process has exited. This is bad news, as no new
-      users will then be able to log in. Rebooting is the only fix, so the
-      system just does it right away.

-  
out of mbufs: map full

-  
The network has exhausted its private page map for network buffers. This
-      usually indicates that buffers are being lost, and rather than allow the
-      system to slowly degrade, it reboots immediately. The map may be made
-      larger if necessary.

-

-
That completes the list of panic types you are likely to see.

-
When the system crashes it writes (or at least attempts to write)
-    an image of memory into the back end of the dump device, usually the same as
-    the primary swap area. After the system is rebooted, the program
-    savecore(8) runs and preserves a copy of this core image
-    and the current system in a specified directory for later perusal. See
-    savecore(8) for details.

-
To analyze a dump you should begin by running
-    adb with the -k flag on the
-    system load image and core dump. If the core image is the result of a panic,
-    the panic message is printed. Normally the command “$c” will
-    provide a stack trace from the point of the crash and this will provide a
-    clue as to what went wrong. For more detail see “Using ADB to Debug
-    the UNIX Kernel”.

-

-

-

-
gdb(1), reboot(8)
-  

-  “VAX 11/780 System Maintenance Guide” and “VAX Hardware
-    Handbook” for more information about machine checks.
-  

-  “Using ADB to Debug the UNIX Kernel”

-

-

-
-  
-    
-    
-  
-
June 5, 1993NetBSD 10.1

diff --git a/static/netbsd/man8/man8.vax/drtest.8 3.html b/static/netbsd/man8/man8.vax/drtest.8 3.html
deleted file mode 100644
index 5d8aad9f..00000000
--- a/static/netbsd/man8/man8.vax/drtest.8 3.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRTEST(8)System Manager's Manual (vax)DRTEST(8)

-

-

-

-
drtest —
-    stand-alone disk test program

-

-

-

-
drtest is a stand-alone program used to
-    read a disk track by track. It was primarily intended as a test program for
-    new stand-alone drivers, but has shown useful in other contexts as well,
-    such as verifying disks and running speed tests. For example, when a disk
-    has been formatted (by vax/format(8)), you can check that
-    hard errors has been taken care of by running
-    drtest. No hard errors should be found, but in many
-    cases quite a few soft ECC errors will be reported.

-
While drtest is running, the cylinder
-    number is printed on the console for every 10th cylinder read.

-

-

-

-
A sample run of drtest is shown below. In
-    this example (using a 750), drtest is loaded from
-    the root file system; usually it will be loaded from the machine's console
-    storage device. Boldface means user input. As usual, ``#'' and ``@'' may be
-    used to edit input.

-

-

-
>>>
-%%
-loading hk(0,0)boot
-Boot
-: 
-Test program for stand-alone up and hp driver
-
-Debugging level (1=bse, 2=ecc, 3=bse+ecc)?
-Enter disk name [type(adapter,unit), e.g. hp(1,3)]? 
-Device data: #cylinders=1024, #tracks=16, #sectors=32
-Testing hp(0,0), chunk size is 16384 bytes.
-
-Start ...Make sure hp(0,0) is online
- ...
-
- ...
-
-

-

-

-

-

-
The diagnostics are intended to be self explanatory. Note,
-    however, that the device number in the diagnostic messages is identified as
-    
-    instead of
-    
-    where X = a*8+u, e.g., hp(1,3) becomes hp11.

-

-

-

-
bad144(8), vax/format(8)

-

-

-

-
The drtest command appeared in
-    4.2BSD.

-

-

-

-
Helge Skrivervik

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.vax/format.8 3.html b/static/netbsd/man8/man8.vax/format.8 3.html
deleted file mode 100644
index 9e7a3a19..00000000
--- a/static/netbsd/man8/man8.vax/format.8 3.html	
+++ /dev/null
@@ -1,220 +0,0 @@
-
-  
-    
-    
-    
-  
-
FORMAT(8)System Manager's Manual (vax)FORMAT(8)

-

-

-

-
format — how to
-    format disk packs

-

-

-

-
There are two ways to format disk packs. The simplest is to use
-    the format program. The alternative is to use the
-    DEC standard formatting software which operates under the DEC diagnostic
-    supervisor. This manual page describes the operation of
-    format, then concludes with some remarks about using
-    the DEC formatter.

-
format is a standalone program used to
-    format and check disks prior to constructing file systems. In addition to
-    the formatting operation, format records any bad
-    sectors encountered according to DEC standard 144. Formatting is performed
-    one track at a time by writing the appropriate headers and a test pattern
-    and then checking the sector by reading and verifying the pattern, using the
-    controller's ECC for error detection. A sector is marked bad if an
-    unrecoverable media error is detected, or if a correctable ECC error too
-    many bits in length is detected (such errors are indicated as
-    “ECC” in the summary printed upon completing the format
-    operation). After the entire disk has been formatted and checked, the total
-    number of errors are reported, any bad sectors and skip sectors are marked,
-    and a bad sector forwarding table is written to the disk in the first five
-    even numbered sectors of the last track. It is also possible to reformat
-    sections of the disk in units of tracks. format may
-    be used on any UNIBUS or MASSBUS drive supported by the up
-    and hp device drivers which uses 4-byte headers
-    (everything except RP's).

-
The test pattern used during the media check may be selected from
-    one of: 0xf00f (RH750 worst case), 0xec6d (media worst case), and 0xa5a5
-    (alternating 1's and 0's). Normally the media worst case pattern is
-  used.

-
format also has an option to perform an
-    extended “severe burn-in”, which makes a number of passes
-    using different patterns. The number of passes can be selected at run time,
-    up to a maximum of 48, with provision for additional passes or termination
-    after the preselected number of passes. This test runs for many hours,
-    depending on the disk and processor.

-
Each time format is run to format an
-    entire disk, a completely new bad sector table is generated based on errors
-    encountered while formatting. The device driver, however, will always
-    attempt to read any existing bad sector table when the device is first
-    opened. Thus, if a disk pack has never previously been formatted, or has
-    been formatted with different sectoring, five error messages will be printed
-    when the driver attempts to read the bad sector table; these diagnostics
-    should be ignored.

-
Formatting a 400 megabyte disk on a MASSBUS disk controller
-    usually takes about 20 minutes. Formatting on a UNIBUS disk controller takes
-    significantly longer. For every hundredth cylinder formatted
-    format prints a message indicating the current
-    cylinder being formatted. (This message is just to reassure people that
-    nothing is amiss.)

-
format uses the standard
-    notation of the standalone I/O library in identifying a drive to be
-    formatted. A drive is specified as
-    , where
-     refers to
-    the controller type (either hp or up),
-    x is the unit number of the drive; 8 times the UNIBUS or
-    MASSBUS adaptor number plus the MASSBUS drive number or UNIBUS drive unit
-    number; and  is
-    the file system partition on drive x (this should always
-    be 0). For example, “hp(1,0)” indicates that drive 1 on
-    MASSBUS adaptor 0 should be formatted; while “up(10,0)”
-    indicates that UNIBUS drive 2 on UNIBUS adaptor 1 should be formatted.

-
Before each formatting attempt, format
-    prompts the user in case debugging should be enabled in the appropriate
-    device driver. A carriage return disables debugging information.

-
format should be used prior to building
-    file systems (with newfs(8) to ensure that all sectors
-    with uncorrectable media errors are remapped. If a drive develops
-    uncorrectable defects after formatting, either bad144(8)
-    or badsect(8) should be able to avoid the bad sectors.

-

-

-

-
A sample run of format is shown below. In
-    this example (using a VAX-11/780), format is loaded
-    from the console floppy; on an 11/750 format will be
-    loaded from the root file system with vax/boot(8)
-    following a “B/3” command. Boldface means user input. As
-    usual, “#” and “@” may be used to edit
-  input.

-

-
>>>L FORMAT
-	LOAD DONE, 00004400 BYTES LOADED
->>>S 2
-Disk format/check utility
-
-Enable debugging (0=none, 1=bse, 2=ecc, 3=bse+ecc)? 0
-Device to format? hp(8,0)
-(error messages may occur as old bad sector table is read)
-Formatting drive hp0 on adaptor 1: verify (yes/no)? yes
-Device data: #cylinders=842, #tracks=20, #sectors=48
-Starting cylinder (0):
-Starting track (0):
-Ending cylinder (841):
-Ending track (19):
-Available test patterns are:

-

-

-
1 - (f00f) RH750 worst case
-2 - (ec6d) media worst case
-3 - (a5a5) alternating 1's and 0's
-4 - (ffff) Severe burnin (up to 48 passes)

-

-

-
Pattern (one of the above, other to restart)? 2
-Maximum number of bit errors to allow for soft ECC (3):
-Start formatting...make sure the drive is online
- ...
-(soft ecc's and other errors are reported as they occur)
- ...
-(if 4 write check errors were found, the program terminates like this...)
- ...
-Errors:
-Bad sector: 0
-Write check: 4
-Hard ECC: 0
-Other hard: 0
-Marked bad: 0
-Skipped: 0
-Total of 4 hard errors revectored.
-Writing bad sector table at block 808272
-(808272 is the block # of the first block in the bad sector table)
-Done
-(...program restarts to allow formatting other disks)
-(...to abort halt machine with ^P)

-

-

-

-

-
The diagnostics are intended to be self explanatory.

-

-

-

-
 The steps needed
-    for 11/750 or 11/730 CPU's are similar, but not covered in detail here.

-
The formatting procedures are different for each type of disk.
-    Listed here are the formatting procedures for RK07's, RP0X, and RM0X
-  disks.

-
You should shut down UNIX and halt the machine to do any disk
-    formatting. Make certain you put in the pack you want formatted. It is also
-    a good idea to spin down or write protect the disks you don't want to
-    format, just in case.

-

-

-
Load the console floppy labeled, “RX11 VAX DSK LD DEV
-    #1” in the console disk drive, and type the following commands:

-

-
>>>BOOT
-DIAGNOSTIC SUPERVISOR.  ZZ-ESSAA-X5.0-119  23-JAN-1980 12:44:40.03
-DS>ATTACH DW780 SBI DW0 3 5
-DS>ATTACH RK611 DMA
-DS>ATTACH RK07 DW0 DMA0
-DS>SELECT DMA0
-DS>LOAD EVRAC
-DS>START/SEC:PACKINIT

-

-

-

-

-
Follow the above procedures except that the ATTACH and SELECT
-    lines should read:

-

-
DS>ATTACH RH780 SBI RH0 8 5
-DS>ATTACH RP0X RH0 DBA0		(RP0X is, e.g., RP06)
-DS>SELECT DBA0

-

-
This is for drive 0 on mba0; use 9 instead of 8 for mba1, etc.

-

-

-

-
Follow the above procedures except that the ATTACH and SELECT
-    lines should read:

-

-
DS>ATTACH RH780 SBI RH0 8 5
-DS>ATTACH RM0X RH0 DRA0
-DS>SELECT DRA0

-

-
Don't forget to put your UNIX console floppy back in the floppy
-    disk drive.

-

-

-

-

-
bad144(8), badsect(8),
-    newfs(8)

-

-

-

-
An equivalent facility should be available which operates under a
-    running UNIX system.

-
It should be possible to reformat or verify part or all of a disk,
-    then update the existing bad sector table.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x68k/boot.8 3.html b/static/netbsd/man8/man8.x68k/boot.8 3.html
deleted file mode 100644
index f069b3f4..00000000
--- a/static/netbsd/man8/man8.x68k/boot.8 3.html	
+++ /dev/null
@@ -1,193 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (x68k)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed, and unless this fails, the system will resume multi-user
-    operations.

-

-

-

-
The X68000/X68030 system boots from the device which is determined
-    by the configuration of battery-backuped SRAM. By default, the boot ROM
-    attempts to boot from floppy disk drives (from 0 to 3) first, and then
-    attempts to boot from hard disk (SASI or SCSI). On the
-    NetBSD/x68k, booting from SCSI disks (sd??) and 2HD
-    floppy disks (fd?a, fd?c) is currently supported.

-

-

-

-
When the floppy disk is selected as the boot device, the initial
-    program loader of the IOCS (firmware) reads the
-    fdboot_ufs program at the top of the disk, and then
-    the fdboot_ufs program loads the /boot program from
-    the FFS or LFS file system. Normally, the /boot
-    program then loads the NetBSD kernel
-    /netbsd from the same floppy. In addition, the
-    /boot program has abilities to uncompress gzip'ed
-    kernels, to read the kernel from other disks of other file systems etc (see
-    below).

-
For floppy disks, fdboot_ustar is also
-    provided to read large kernels which do not fit one a single floppy.

-

-

-

-
When a SCSI hard disk is selected as the boot device, the initial
-    program loader on the SCSI host adapter's ROM reads the operating
-    system-independent IPL menu program at the top of the disk. The IPL menu
-    program recognizes the partition table, and selects the partition to read
-    the operating system kernel. During this phase, when the HELP key on the
-    keyboard is pressed, the IPL menu program displays the partition menu of
-    that disk to prompt the user to select the boot partition (although the
-    NetBSD implementation of the IPL menu,
-    /usr/mdec/mboot, does not have this
-  functionality).

-
Next, the IPL menu reads the OS-dependent boot program from the
-    top of the selected partition. For NetBSD FFS/LFS
-    file systems sdboot_ufs is used. The
-    sdboot_ufs program then loads the
-    /boot program from that partition.

-

-

-

-
Once running, a banner similar to the following will appear:

-

-
NetBSD Multi-boot, Revision 1.1
-(user@buildhost, builddate)
-Press return to boot now, any other key for boot menu
-booting sd0a:netbsd - starting in 5

-

-
After a countdown, the system image listed will be loaded. (In the
-    example above, it will be
-    “sd0a:netbsd” which is the file
-    netbsd on partition “a” of the
-    NetBSD SCSI hard disk of ID 0. Pressing a key within
-    the time limit will enter interactive mode.

-

-

-

-
In interactive mode, the boot loader will present a prompt,
-    allowing input of these commands:

-

-

-  

-    [device:][filename]
-    [-adqsv]

-  
The default device will be set to the disk that the
-      boot loader was loaded from. To boot from an alternate disk, the full name
-      of the device should be given at the prompt. device
-      is of the form
-      xd[N[x]]
-      where xd is the device from which to boot,
-      N is the unit number, and x is
-      the partition letter.
-    
The following list of supported devices may vary from
-        installation to installation:

-    

-    

-      
sd

-      
SCSI disks on a controller recognized by the IOCS. The unit number is
-          the SCSI ID.

-      
fd

-      
Floppy drives as numbered by the IOCS.

-    

-    
The default filename is
-        netbsd; if the boot loader fails to successfully
-        open that image, it then tries netbsd.gz
-        (expected to be a kernel image compressed by gzip(1)).
-        Alternate system images can be loaded by just specifying the name of the
-        image.

-    
Options are:

-    

-      

-      
Prompt for the root file system device, the system crash dump device,
-          and the path to init(8).

-      

-      
Bring the system up in debug mode. Here it waits for a kernel debugger
-          connect; see ddb(4).

-      

-      
Boot the system in quiet mode.

-      

-      
Bring the system up in single-user mode.

-      

-      
Boot the system in verbose mode.

-    

-  

-  

-  
Print an overview about commands and arguments.

-  

-    [path]

-  
Print a directory listing of path, containing
-      inode number, filename and file type. path can
-      contain a device specification.

-  

-  
Reboot the system.

-

-

-

-

-

-
Note for X68030+MC68030 systems: Nothing special to be attended
-    to; you can boot NetBSD just like as other operating
-    systems such as Human68k and OS-9.

-
Note for X68030/040turbo(68040 accelerator by BEEPs) systems:
-    NetBSD can boot under 040 mode. It can also boot
-    under 030 mode if you have MC68030 on the board.

-
Note for X68000/Xellent30(68030 accelerator by TSR)+MC68030
-    systems: In order to boot NetBSD, you must choose
-    030 mode by using CH30.SYS, which must reside in the
-    battery-backuped SRAM.

-
Note for X68000/Jupiter-X(68040/060 accelerator by FTZ-net)
-    systems: The system must be in 040/060 processor mode.

-

-

-

-

-

-  
/netbsd

-  
system code

-  
/netbsd.gz

-  
gzip-compressed system code

-  
/usr/mdec/xxboot_ufs

-  
boot block (read by installboot), xx is disktype

-  
/usr/mdec/boot

-  
source of /boot (can be just copied to the root directory)

-  
/boot

-  
main part of the boot program

-

-

-

-

-
reboot(2), disklabel(8),
-    halt(8), reboot(8),
-    shutdown(8)

-

-

-
-  
-    
-    
-  
-
August 16, 2014NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x68k/loadbsd.8 3.html b/static/netbsd/man8/man8.x68k/loadbsd.8 3.html
deleted file mode 100644
index ee2e8bab..00000000
--- a/static/netbsd/man8/man8.x68k/loadbsd.8 3.html	
+++ /dev/null
@@ -1,130 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOADBSD(8)System Manager's Manual (x68k)LOADBSD(8)

-

-

-

-
loadbsd — load and
-    boot NetBSD/x68k kernel from Human68k

-

-

-

-
-  
-    
-    
-  
-
loadbsd.x[-hvV] [-abDNqs]
-      [-r root_device]
-      kernel_file

-

-

-

-
loadbsd is a program runs on Human68k. It
-    loads and executes the specified NetBSD/x68k
-  kernel.

-
The options (for loadbsd itself) are as
-    follows:

-

-  

-  
Show help and exit.

-  

-  
Do not execute the kernel, if specified in combination with boot
-    options.

-  

-  
Enable verbose mode.

-  

-  
Print version of loadbsd and exit.

-

-
The options for NetBSD kernel are as
-    follows:

-

-  

-  
Auto (multi-user) boot. This disables -s
-    flag.

-  

-  
Ask boot device during boot. Pass RB_ASKNAME boot
-      flag to the kernel.

-  

-  
Enter kernel debugger. Pass RB_KDB boot flag to
-      the kernel.

-  

-    root_device

-  
Specify boot device, which shall be mounted as root device. The default
-      device is ‘sd@0,0:a’. Note that the
-      boot device name is
-       the
-      same as that of NetBSD. See
-      BOOT DEVICE NAMES below.

-  

-  
Boot the system in quiet mode. Pass AB_QUIET boot
-      flag to the kernel.

-  

-  
Single user boot. Pass RB_SINGLE boot flag to the
-      kernel. This disables -a flag. This flag is set by
-      default.

-

-
Although listed separately, the options may be in any order.

-

-

-

-
The format of boot device names is:

-

-
[/interface/]dev@unit[,lun][:partition]

-

-  
interface

-  
SCSI interface type. One of:
-      ‘spc@0’,
-      ‘spc@1’,
-      ‘mha@0’. If the dev is a SCSI
-      device, and interface is omitted, the current boot interface is used.

-  
dev

-  
Device type. One of: ‘fd’ (floppy
-      disk drive), ‘sd’ (SCSI disk),
-      ‘cd’ (SCSI CD-ROM),
-      ‘md’ (Memory disk).

-  
unit

-  
Device unit #. You must specify the target SCSI ID if dev is a SCSI
-      device.

-  
lun

-  
SCSI LUN #. 0 is assumed if omitted.

-  
partition

-  
Partition letter of device. Partition
-      ‘a’ is used if omitted.

-

-

-

-

-

-  
/usr/mdec/loadbsd.x

-  
You will find this program here.

-

-

-

-

-
reboot(2), x68k/boot(8)

-

-

-

-
The loadbsd utility first appeared in
-    NetBSD 1.4.

-

-

-

-
loadbsd reads the entire kernel image at
-    once, and requires enough free area on the main memory.

-

-

-
-  
-    
-    
-  
-
December 23, 2023NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x68k/newdisk.8 3.html b/static/netbsd/man8/man8.x68k/newdisk.8 3.html
deleted file mode 100644
index 75ed50c2..00000000
--- a/static/netbsd/man8/man8.x68k/newdisk.8 3.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
NEWDISK(8)System Manager's Manual (x68k)NEWDISK(8)

-

-

-

-
newdisk — Prepare
-    a new disk to be usable for X680x0

-

-

-

-
-  
-    
-    
-  
-
newdisk[-vnfcp] [-m
-      mboot] raw_device

-

-

-

-
newdisk prepares a new hard disk to be
-    bootable from by X680x0. It should NOT be used for floppy disks.

-
It creates a disk mark for IOCS to determine the disk geometry,
-    writes the primary boot program (mboot), and creates empty partition table.
-    The option are as follows:

-

-  

-  
Verbose mode.

-  

-  
Dryrun mode. Nothing is written to the disk.

-  

-  
Force. Usually, when newdisk detects existing disk
-      mark, it aborts with some error messages. -f
-      option prevents this behaviour.

-  

-  
Check only. newdisk looks at the disk whether it
-      is already marked.

-  

-  
Do not create the partition table.

-  

-    mboot

-  
Specifies the mboot program to be written.

-

-

-

-

-

-  
/usr/mdec/mboot

-  
The default primary boot program.

-

-

-

-

-
installboot(8),
-  x68k/boot(8)

-

-

-

-
The newdisk utility first appeared in
-    NetBSD 1.5.

-

-

-

-
newdisk was written by
-    MINOURA Makoto
-    <minoura@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x86/boot.8 3.html b/static/netbsd/man8/man8.x86/boot.8 3.html
deleted file mode 100644
index 3b446c36..00000000
--- a/static/netbsd/man8/man8.x86/boot.8 3.html	
+++ /dev/null
@@ -1,705 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT(8)System Manager's Manual (x86)BOOT(8)

-

-

-

-
boot — system
-    bootstrapping procedures

-

-

-

-
Intel Architecture, 32-bit (IA-32) computers (the IBM PC and its
-    clones) that can run NetBSD/i386 or
-    NetBSD/amd64 can use any of the following boot
-    procedures, depending on what the hardware and BIOS support:

-

-  
boot

-  
bootstrap NetBSD from the system BIOS

-  
efiboot

-  
bootstrap NetBSD from the system UEFI

-  
x86/dosboot(8)

-  
bootstrap NetBSD from MS-DOS

-  
x86/pxeboot(8)

-  
network bootstrap NetBSD from a TCP/IP LAN with
-      DHCP, TFTP, and NFS.

-

-

-

-
Normally, the system will reboot itself at power-up or after
-    crashes. An automatic consistency check of the file systems will be
-    performed, and unless this fails, the system will resume multi-user
-    operations.

-

-

-

-
The 386 PC AT clones attempt to boot the floppy disk drive A
-    (otherwise known as drive 0) first, and failing that, attempt to boot the
-    hard disk C (otherwise known as hard disk controller 1, drive 0). The
-    NetBSD bootblocks are loaded and started either by
-    the BIOS, or by a boot selector program (such as OS-BS, BOOTEASY, the OS/2
-    Boot Menu or NetBSD's
-    boot-selecting master boot record - see
-    x86/mbr(8)).

-

-

-

-
Once running, a banner similar to the following will appear:

-

-
>> NetBSD BIOS Boot, revision 3.0
->> (user@buildhost, builddate)
->> Memory: 637/15360 k
-Press return to boot now, any other key for boot menu
-booting hd0a:netbsd - starting in 5

-

-
After a countdown, the system image listed will be loaded. In the
-    example above, it will be
-    “hd0a:netbsd” which is the file
-    /netbsd on partition
-    “a” of the
-    NetBSD MBR partition of the first hard disk known to
-    the BIOS (which is an IDE or similar device — see the
-    BUGS section).

-
Pressing a key within the time limit, or before the boot program
-    starts, will enter interactive mode. When using a short or 0 timeout, it is
-    often useful to interrupt the boot by holding down a shift key, as some
-    BIOSes and BIOS extensions will drain the keystroke buffer at various points
-    during POST.

-
If present, the file /boot.cfg will be
-    used to configure the behaviour of the boot loader including setting the
-    timeout, choosing a console device, altering the banner text and displaying
-    a menu allowing boot commands to be easily chosen. See
-    boot.cfg(5).

-

-

-

-
The NetBSD/x86 boot loader can boot a
-    kernel using either the native NetBSD boot protocol,
-    or the “multiboot” protocol (which is compatible with some
-    other operating systems). In the native NetBSD boot
-    protocol, options are passed from the boot loader to the kernel via flag
-    bits in the boothowto variable (see
-    boothowto(9)). In the multiboot protocol, options are
-    passed from the boot loader to the kernel as strings.

-

-

-

-
If the first stage boot fails to load the boot, it will print a
-    terse message indicating the reason for the failure. The possible error
-    messages and their cause are listed in x86/mbr(8).

-
If the first stage boot succeeds, the banner will be shown and the
-    error messages should be self-explanatory.

-

-

-

-
In interactive mode, the boot loader will present a prompt,
-    allowing input of these commands:

-

-

-  

-    [device:][filename]
-    [-1234abcdmqsvxz]

-  
The default device will be set to the disk from
-      which the boot loader was loaded. The partition is set to the first match
-      in this list:
-    
    
-      
  1. The first gpt(8) partition with the
-          bootme attribute set.
    2. 
-      
  2. The partition from which the boot loader was loaded from, if that can
-          be detected.
    3. 
-      
  3. The first partition with a file system that could be bootable.
    4. 
-      
  4. The first partition.
    5. 
-    

-    
To boot from an alternate disk, the full name of the device
-        should be given at the prompt. device is of the
-        form NAME=partition_label
-        when booting from a gpt(8) partitioned disk.
-        Otherwise, the syntax is
-        xd[N[x]]
-        where xd is the device from which to boot,
-        N is the unit number, and x
-        is the partition letter.

-    
In the latter case, the following list of supported devices
-        may vary from installation to installation:

-    

-      
hd

-      
Hard disks as numbered by the BIOS. This includes ST506, IDE, ESDI,
-          RLL disks on a WD100[2367] or lookalike controller(s), and SCSI disks
-          on SCSI controllers recognized by the BIOS.

-      
fd

-      
Floppy drives as numbered by the BIOS.

-      
cd

-      
CD-ROM drives as numbered by the BIOS.

-      
raid

-      
RAIDframe configured from hard disks recognized by the BIOS. Only RAID
-          level 1 sets are supported by bootstrap code. If the RAID is
-          partitioned, the first partition is used, or the first
-          gpt(8) partition that has the
-          bootme attribute set. Inner RAIDframe partitions
-          can also be given to the dev command using he
-          NAME=partition_label
-          syntax.

-    

-    
The default filename is
-        netbsd; if the boot loader fails to successfully
-        open that image, it then tries netbsd.gz
-        (expected to be a kernel image compressed by gzip), followed by
-        onetbsd, onetbsd.gz,
-        netbsd.old, and finally
-        netbsd.old.gz.

-    
In support of the KERNEL_DIR build
-        option (see mk.conf(5)), the boot loader will then try
-        netbsd/kernel,
-        netbsd/kernel.gz,
-        onetbsd/kernel,
-        onetbsd/kernel.gz,
-        netbsd.old/kernel, and finally
-        netbsd.old/kernel.gz. Alternate system images
-        can be loaded by just specifying the filename of the image. If the
-        specified filename does not contain an embedded
-        or trailing slash character, the boot loader will also try
-        filename/kernel and
-        filename/kernel.gz. (A leading slash character
-        will be ignored.)

-    
Options are:

-    

-      

-      
Sets the machine-dependent flag RB_MD1 in
-          boothowto. In
-          NetBSD/x86, this disables multiprocessor boot;
-          the kernel will boot in uniprocessor mode.

-      

-      
Sets the machine-dependent flag RB_MD2 in
-          boothowto. In
-          NetBSD/x86, this disables ACPI.

-      

-      
Sets the machine-dependent flag RB_MD3 in
-          boothowto. In
-          NetBSD/amd64, this disables SVS.

-      

-      
Sets the machine-dependent flag RB_MD4 in
-          boothowto. In
-          NetBSD/x86, this has no effect.

-      

-      
Sets the RB_ASKNAME flag in
-          boothowto. This causes the kernel to prompt for
-          the root file system device, the system crash dump device, and the
-          path to init(8).

-      

-      
Sets the RB_HALT flag in
-          boothowto. This causes subsequent reboot
-          attempts to halt instead of rebooting.

-      

-      
Sets the RB_USERCONF flag in
-          boothowto. This causes the kernel to enter the
-          userconf(4) device configuration manager as soon as
-          possible during the boot. userconf(4) allows devices
-          to be enabled or disabled, and allows device locators (such as
-          hardware addresses or bus numbers) to be modified before the kernel
-          attempts to attach the devices.

-      

-      
Sets the RB_KDB flag in
-          boothowto. Requests the kernel to enter debug
-          mode, in which it waits for a connection from a kernel debugger; see
-          ddb(4).

-      

-      
Sets the RB_MINIROOT flag in
-          boothowto. Informs the kernel that a mini-root
-          file system is present in memory.

-      

-      
Sets the AB_QUIET flag in
-          boothowto. Boot the system in quiet mode.

-      

-      
Sets the RB_SINGLE flag in
-          boothowto. Boot the system in single-user
-        mode.

-      

-      
Sets the AB_VERBOSE flag in
-          boothowto. Boot the system in verbose mode.

-      

-      
Sets the AB_DEBUG flag in
-          boothowto. Boot the system with debug messages
-          enabled.

-      

-      
Sets the AB_SILENT flag in
-          boothowto. Boot the system in silent mode.

-    

-  

-  

-    dev[,speed]

-  
[Not available for x86/dosboot(8)] Immediately switch
-      the console to the specified device dev and reprint
-      the banner. dev must be one of
-      pc, com0,
-      com1, com2,
-      com3, com0kbd,
-      com1kbd, com2kbd,
-      com3kbd, or auto. See
-      Console Selection
-      Policy in x86/boot_console(8).
-    
A speed for the serial port is optional
-        and defaults to 9600. If a value of zero is specified, then the current
-        baud rate (set by the BIOS) will be used. Setting the
-        speed with the pc device
-        is not possible.

-    
UEFI may support some USB and PCI-based serial ports. See the
-        UEFI serial ports section
-        for details. Using the consdev command without
-        arguments lists the available ports. com0 to
-        com3 are reserved for standard ISA serial ports,
-        other ports are assigned to com4 and beyond. The
-        generic com{unit}[,speed] syntax can be used to
-        select any port.

-    
Bootstrap can tell the kernel to use a USB-to-serial adapter
-        for console using the ucom{unit}[,speed] syntax.
-        No console switch happens in bootstrap, and kernel console
-        initialization will be deferred after USB devices attachment. This means
-        early boot will be silent, and userconf(4) interactive
-        mode cannot be used. The default ucom speed is
-        115200.

-  

-  

-    dev[,speed]

-  
Configure the kernel console like consdev but do
-      not attempt to switch console in bootstrap. This is useful when using a
-      USB-to-serial adapter that is known as a com device
-      in bootstrap but as a ucom device for the kernel.
-      One may use a syntax like:
-    

-    
consdev com4,115200
-kconsdev ucom0,115200

-    

-    Note that command ordering matters.

-  

-    [device]

-  
Set the default drive and partition for subsequent file system operations.
-      Without an argument, print the current setting.
-      device is of the form specified in
-      boot.

-  

-  
[Only available for UEFI boot] Dump UEFI device paths.

-  

-  
[Only available for UEFI boot] Dump UEFI environment variables from
-    NVRAM.

-  

-    file

-  
[Only available for BIOS and UEFI boot] Load a file system image from the
-      specified file, and request the kernel to use it as
-      the root file system. The makefs(8) utility may be used
-      to create suitable file system images.

-  

-    [mode_index]

-  
[Only available for UEFI boot] Without argument, list the available video
-      modes. If an argument is given, select a video mode.

-  

-  
Print an overview about commands and arguments.

-  

-    module [arguments]

-  
[Not available for x86/dosboot(8)] Load the specified
-      kernel module, and pass it the specified
-      arguments. If the module name is not an absolute
-      path,
-    
/stand/⟨arch⟩/⟨osversion⟩/modules/⟨module⟩/⟨module⟩.kmod

-    is used. Possible uses of the load command include
-      loading a memory disk image before booting a kernel, or loading a Xen DOM0
-      kernel before booting the Xen hypervisor. See
-      boot.cfg(5) for examples.
-    
In addition to the boot options
-        specified above, the Xen DOM0 kernel accepts
-        (arguments being separated with spaces):

-    

-      
=dev
-        (or root=dev)

-      
Override the default boot device. dev is of the
-          form
-          NAME=partition_label for
-          gpt(8) partitioned disks. It can also be a unit name
-          (‘wd0’), or an interface name
-          (‘bge0’,
-          ‘wm0’, ...) for cases where the
-          root file system has to be loaded from network (see the
-          BUGS section in
-          x86/pxeboot(8)).

-      
=dev

-      
Console used by DOM0 kernel during boot. dev
-          accepts the same values as the ones given for the
-          consdev command. See
-          Console Selection
-          Policy in x86/boot_console(8).

-      
=my_ip:serv_ip:gw_ip:mask:host:iface

-      
Specify various parameters for a network boot (IPs are in dot
-          notation), each one separated by a colon:
-        

-          
my_ip

-          
address of the host

-          
serv_ip

-          
address of the NFS server

-          
gw_ip

-          
address of the gateway

-          
mask

-          
network mask

-          
host

-          
address of the host

-          
iface

-          
interface (e.g., “xennet0”
-              or “eth0”)

-        

-      

-      
=address:rootpath

-      
Boot the system with root on NFS. address is the
-          address of the NFS server, and rootpath is the
-          remote mount point for the root file system.

-      
=pcidevs

-      
Pass a list of PCI IDs for use with the PCI backend driver,
-          pciback(4). pcidevs is formed
-          of multiple IDs (in
-          bus:device.function
-          notation), each ID being surrounded with brackets. PCI domain IDs are
-          currently ignored. See pciback(4).

-    

-  

-  

-    [path]

-  
[Not available for x86/pxeboot(8)] Print a directory
-      listing of path, containing inode number, filename,
-      and file type. path can contain a device
-      specification.

-  

-  
[Only available for UEFI boot] Dump UEFI memory map.

-  
-  
[Only available for BIOS and UEFI boot] Display the boot menu and initiate
-      a countdown, similarly to what would have happened if interactive mode had
-      not been entered.

-  

-    {on |
-    off |
-    enabled |
-    disabled}

-  
[Not available for x86/dosboot(8)] The values
-      ‘enabled’,
-      ‘on’ will enable module loading for
-      boot and multiboot,
-      whereas ‘disabled’,
-      ‘off’ will turn off the
-    feature.

-  

-    fstype

-  
[Only available for x86/dosboot(8)] Switch file system
-      type; fstype should be one of
-      dos or ufs.

-  

-    kernel [arguments]

-  
[Not available for x86/dosboot(8)] Boot the specified
-      kernel, using the “multiboot” protocol
-      instead of the native NetBSD boot protocol. The
-      kernel is specified in the same way as with the
-      boot command.
-    
The multiboot protocol may be used in the following cases:

-    

-      
NetBSD/Xen
-        kernels

-      
The Xen DOM0 kernel must be loaded as a module using the
-          load command, and the Xen hypervisor must be
-          booted using the multiboot command. Options
-          for the DOM0 kernel (such as “-s” for single user mode)
-          must be passed as options to the load command.
-          Options for the hypervisor (such as
-          “dom0_mem=256M” to reserve 256MB
-          of memory for DOM0) must be passed as options to the
-          multiboot command. See
-          boot.cfg(5) for examples on how to boot
-          NetBSD/Xen.

-      
NetBSD multiboot
-        kernels

-      
A NetBSD kernel that was built with
-          options MULTIBOOT (see
-          x86/multiboot(8)) may be booted with either the
-          boot or multiboot
-          command, passing the same arguments in either
-          case.

-      
Non-NetBSD
-        kernels

-      
A kernel for a
-          non-NetBSD operating
-          system that expects to be booted using the multiboot protocol (such as
-          by the GNU “GRUB” boot loader) may be booted using the
-          multiboot command. See the foreign operating
-          system's documentation for the available
-          arguments.

-    

-  

-  

-  
[Only available for BIOS and UEFI boot] Boot a kernel that has the
-      KASLR option set, for Kernel Address Space Layout
-      Randomizaton.

-  

-  
Reboot the system.

-  

-    [default |
-    none |
-    address]

-  
[Only UEFI boot] Sets where the kernel is copied by bootstrap before it is
-      started. Values other than default require a kernel built with the
-      SELFRELOC option, so that can relocate itself at
-      the right address, otherwise a crash occurs at boot time.
-    

-      
default

-      
Copy the kernel at ELF header load address, this is the historical
-          behavior.

-      
none

-      
Leave the kernel where it was loaded and start it as is.

-      
address

-      
Copy the kernel at given address.

-    

-  

-  

-    file

-  
[Only available for BIOS and UEFI boot] Load the specified
-      file and request the kernel to use it as a seed for
-      the rnd(4) random number generator. The
-      file should be in the private format used by
-      rndctl(8), and should have been saved by
-      ‘rndctl -S’ shortly before the
-      previous shutdown. See the random_seed and
-      random_file variables in
-      rc.conf(5), and the
-      /etc/rc.d/random_seed script, for a way to manage
-      the seed file. Using the same seed file on more then one host, or for more
-      than one boot on the same host, will reduce the quality of random numbers
-      and may impact system security.

-  

-    spec

-  
[Only available for BIOS and UEFI boot] Pass an explicit root
-      specification to the kernel. See BTINFO_ROOTDEVICE for details.

-  

-    file

-  
[Only available for BIOS and UEFI boot] Load a graphical image from the
-      specified file and request the kernel to use it as a
-      splash screen. The file should contain an image in
-      one of these formats: JPEG (baseline only, not progressive), PNG (8-bit
-      only), TGA, BMP (non-1bpp, non-RLE), GIF, PSD (composited view only), or
-      PIC.

-  

-    [mode_index]

-  
[Only available for UEFI boot] Without argument, list the available text
-      modes (displayed as column x line in hexadecimal, therefore
-      50x19 means 80 columns and
-      25 lines). With an argument, select a text
-    mode.

-  

-    command

-  
[Not available for x86/dosboot(8)] Pass command
-      command to userconf(4) at boot
-      time. These commands are processed before the interactive
-      userconf(4) shell is executed, if requested.

-  

-    [full]

-  
[Only available for UEFI boot] Display UEFI bootstrap version. With the
-      [full] argument, also display information about UEFI itself.

-  

-    {modenum |
-    on |
-    off |
-    enabled |
-    disabled |
-    list}

-  
[Only available for BIOS and x86/pxeboot(8)] Initialise
-      the video card to the specified resolution and bit depth. The
-      modenum should be in the form of
-      ‘0x100’,
-      ‘800x600’,
-      ‘800x600x32’. The values
-      ‘enabled’,
-      ‘on’ put the display into the
-      default mode, and ‘disabled’,
-      ‘off’ returns the display into
-      standard vga mode. The value ‘list’
-      lists all supported modes.

-

-

-
In an emergency, the bootstrap methods described in the
-    NetBSD installation notes for the x86 architectures
-    can be used to boot from floppy or other media, or over the network.

-

-

-

-
The kernel uses information from the bootloader to locate the file
-    system to mount as root. There are three methods:

-

-

-  

-    from

-  
boot.cfg(5) or multiboot. The bootloader passes the root
-      device name as driver, unit, and partition (like
-      ‘sd0a).’ This will be automatically
-      substituted by a dk(4) wedge if one is discovered.
-    
If the bootloader passes a wedge name as
-        “wedge:” or
-        “NAME=” followed by the name. The
-        kernel will search for a dk(4) device with that
-      name.

-  

-  

-    determined by bootblock

-  
The bootloader passes start offset and length of a hard disk partition and
-      a offset, size and hash of a “boot area”. Then kernel
-      searches all disks and wedges for a block sequence at that offset with a
-      matching hash. If one is found, the kernel will look for a wedge on that
-      device at the same offset.
-    
An additional partition number is provided if the bootloader
-        also passed a BTINFO_BOOTDISK record. This (or
-        partition ‘a’) will be used by the
-        kernel as a fallback if there is no matching wedge.

-  

-  

-    determined by bootblock

-  
This uses the device number passed by the BIOS that distinguishes between
-      floppy, hard drive and CD-ROM boot.
-    

-      
Floppy

-      
The kernel searches for the fd(4) device with the
-          correct unit, the partition number is used to select a specific disk
-          format. See fd(4) for details.

-      
Hard drive

-      
The bootloader passed a partition number and disklabel data (offset,
-          type, checksum, packname). The kernel searches all disks for a
-          matching disklabel. If one is found, the kernel will use that device
-          and partition number.

-      
CDROM

-      
The BIOS does not distinguish between multiple CD devices. The kernel
-          searches for the first cd(4) device. So you can only
-          boot from unit 0.

-    

-  

-

-

-

-

-

-

-
Serial ports supported by a UEFI driver can be used in UEFI and in
-    NetBSD bootstrap. UEFI usually supports ISA serial ports, and it may support
-    PCI or USB-to- serial adapters, depending on vendor-specific
-    implementations.

-
An open source UEFI driver is available form Tianocore EDK2, for
-    USB-to-serial adapters using the FTDI FT232R chip. USB vendor ID and product
-    ID for those devices are 0x0403 and
-    0x6001.

-
To use it, obtain the FtdiUsbSerialDxe.efi
-    driver from Tianocore EDK2 and save it in the EFI bootstrap partition, for
-    instance in /EFI/EDK2/FtdiUsbSerialDxe.efi then
-    create a /EFI/boot/startup.nsh script containing
-    something like

-

-
FS0:
-load \EFI\EDK2\FtdiUsbSerialDxe.efi
-bootx64.efi

-

-
Then make sure UEFI boots into the UEFI shell. If it is not
-    available in the built-in options, Shell.efi can be
-    obtained from Tianocore EDK2 and installed in
-    /EFI/boot/Shell.efi.

-

-

-

-

-  
/boot

-  
boot program code loaded by the primary bootstrap

-  
/boot.cfg

-  
optional configuration file

-  
/netbsd

-  
system code

-  
/netbsd.gz

-  
gzip-compressed system code

-  
/usr/mdec/boot

-  
master copy of the boot program (copy to /boot)

-  
/usr/mdec/bootxx_fstype

-  
primary bootstrap for file system type fstype, copied to the start of the
-      NetBSD partition by
-      installboot(8).

-  
/usr/mdec/bootia32.efi

-  
 

-  
/usr/mdec/bootx64.efi

-  
UEFI bootstraps for NetBSD/i386 and
-      NetBSD/amd64, which should be copied to the
-      /EFI/boot directory in a FAT formatted partition
-      of type EFI (either x86/mbr(8) or
-      gpt(8), see the BUGS
-      section). NetBSD UEFI bootstrap reads its
-      configuration from the /EFI/NetBSD/boot.cfg file
-      in the EFI partition.

-

-

-

-

-
ddb(4), fd(4),
-    pciback(4), userconf(4),
-    boot.cfg(5), halt(8),
-    installboot(8), reboot(8),
-    rescue(8), shutdown(8),
-    x86/boot_console(8), x86/dosboot(8),
-    x86/mbr(8), x86/multiboot(8),
-    x86/pxeboot(8), boothowto(9)

-

-

-

-
The kernel file name must be specified before, not after, the boot
-    options. Any filename specified after the boot
-    options, e.g.:

-

-
boot -d netbsd.test

-
is ignored, and the default kernel is booted.

-
Hard disks are always accessed by BIOS functions. Unit numbers are
-    BIOS device numbers which might differ from numbering in the
-    NetBSD kernel or physical parameters (e.g., SCSI
-    slave numbers). There isn't any distinction between “sd” and
-    “wd” devices at the bootloader level. This is less a bug of
-    the bootloader code than a shortcoming of the PC architecture. The default
-    disk device's name printed in the starting message is derived from the
-    “type” field of the NetBSD disklabel
-    (if it is a hard disk).

-
UEFI implementations are supposed to support either
-    x86/mbr(8) or gpt(8) partitioning, but
-    some do not handle the latter. UEFI booting from a gpt(8)
-    partitioned disk is still possible in this case, by adding an overlapping
-    EFI partition in the protective x86/mbr(8) block. This can
-    be achieved using the following commands (you must adapt the hard disk and
-    EFI partition start end size to fit your setup):

-

-
dd if=/dev/rwd0d bs=512 count=1 of=mbr
-fdisk -FIfaui1s 4/34/32768 -c /usr/mdec/mbr mbr
-dd if=mbr bs=512 count=1 of=/dev/rwd0d conv=notrunc

-

-
The resulting x86/mbr(8) partition table will
-    look like this:

-

-
0: GPT Protective MBR (sysid 238)
-    start 1, size 2097151 (1024 MB, Cyls 0-130/138/8)
-        PBR is not bootable: Bad magic number (0x0000)
-1: Primary DOS with 16 bit FAT <32M (sysid 4)
-    start 34, size 32768 (16 MB, Cyls 0/0/35-2/10/42), Active
-2: <UNUSED>
-3: <UNUSED>

-

-

-

-
-  
-    
-    
-  
-
October 9, 2025NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x86/boot_console.8 3.html b/static/netbsd/man8/man8.x86/boot_console.8 3.html
deleted file mode 100644
index 6658a99f..00000000
--- a/static/netbsd/man8/man8.x86/boot_console.8 3.html	
+++ /dev/null
@@ -1,124 +0,0 @@
-
-  
-    
-    
-    
-  
-
BOOT_CONSOLE(8)System Manager's Manual (x86)BOOT_CONSOLE(8)

-

-

-

-
boot_console —
-    selection of a console device in the x86
-  bootloader

-

-

-

-
The NetBSD x86 bootloader selects a
-    console device for its user interaction and passes information about it to
-    the NetBSD kernel. When booting from the system
-    BIOS, the console device and properties are saved in the primary bootstrap
-    by installboot(8). For other boot procedures (such as
-    x86/dosboot(8)) the selection process is controlled by
-    bootloader compile-time options and system setup at the bootloader startup
-    time. The selection may be changed on-the-fly from within the
-  bootloader.

-

-

-
The compile-time options (to be set in the booter's
-    “Makefile”) are:

-

-  
policy

-  
enables support for serial input/output. By default this option is not set
-      and the standard PC keyboard and display are always used as the console
-      device. See Console
-      Selection Policy below for valid values of
-      policy.

-  

-  
causes direct hardware access to be used for serial input / output. With
-      this option, software handshake (XON/XOFF) is used for flow control.
-      Without this option, BIOS functions are employed for serial port handling,
-      which require hardware handshake lines to be completely wired.

-  
integer

-  
sets the baud-rate for the serial console. This option has only an effect
-      when used in combination with the
-      “DIRECT_SERIAL” option above,
-      otherwise, the default setting of 9600 baud is used. The value of
-      integer must be something that makes sense as a
-      serial port baud rate.

-  

-  
Require a character input within seven (7) seconds from serial console
-      device to be selected.

-

-

-

-

-
The actual policy for the console selection is determined by the
-    value of “SUPPORT_SERIAL” The
-    following options are available:

-

-  

-  
Force use of the standard PC keyboard and display as the console.

-  

-    ...
-    

-  
Use the serial port with the corresponding BIOS number as the console. No
-      attempt is made to verify connectivity on the selected port. If the port
-      is not known to the BIOS, it falls back to
-      “CONSDEV_PC”. (Note: This feature
-      can be deliberately used for console selection if the serial ports have
-      been disabled in the BIOS.)

-  

-    ...
-    

-  
If the port is known to the BIOS, and output of a character to the port
-      succeeds (and if “DIRECT_SERIAL” is
-      defined the RS-232 “modem ready” status is on after the
-      character is output), the port is used as console. If the port is not
-      known to the BIOS, or the test output fails, it falls back to
-      “CONSDEV_PC”.

-  

-  
Auto-select the console. All serial ports known to the BIOS are probed in
-      sequence. If output of a character to the port succeeds (and if
-      “DIRECT_SERIAL” is defined the
-      RS-232 “modem ready” status is on after the character is
-      output), the port is used as console. If no serial port passes the check,
-      “CONSDEV_PC” is used. The progress
-      of the selection process is shown at the PC display as digits
-      corresponding to the serial port number currently probed.

-

-

-

-

-

-

-  
src/sys/arch/i386/stand/{boot,pxeboot}/Makefile

-  
compile time options for the boot programs.

-

-

-

-

-
console(4), installboot(8),
-    x86/boot(8)

-

-

-

-
The serial communication parameters (byte-size, parity, stop-bits)
-    are not settable (either at compile time or run time). The default
-    parameters are “8 N 1”.

-
The baud rate is not settable when using BIOS I/O. It should be
-    settable at compile time with
-    “CONSPEED” just as it is when using
-    “DIRECT_SERIAL”. The default speed is
-    9600 baud (the maximum for BIOS I/O).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x86/dosboot.8 3.html b/static/netbsd/man8/man8.x86/dosboot.8 3.html
deleted file mode 100644
index b5461c0d..00000000
--- a/static/netbsd/man8/man8.x86/dosboot.8 3.html	
+++ /dev/null
@@ -1,111 +0,0 @@
-
-  
-    
-    
-    
-  
-
DOSBOOT(8)System Manager's Manual (x86)DOSBOOT(8)

-

-

-

-
dosboot — boot
-    NetBSD/x86 from DOS

-

-

-

-
-  
-    
-    
-  
-
dosboot[-u] [-c
-      command] [-i]
-      [path [-adqsv]]

-

-

-

-
dosboot is an MS-DOS program. It is a boot
-    loader for NetBSD/x86 designed to permit
-    NetBSD to be booted directly from MS-DOS. By
-    default, it boots a file with name NETBSD in the
-    current MS-DOS directory. dosboot shares common code
-    with the standard boot loader, x86/boot(8).

-
The recognized options are:

-

-

-  

-  
Execute command (see below).

-  

-  
Enter interactive mode. dosboot will present a
-      prompt, allowing input of commands (see below).

-  

-  
Boot from a UFS file system instead of an MS-DOS file system.

-  
path

-  
Specifies the kernel file. In MS-DOS mode (default) a normal MS-DOS
-      filename (with or without drive specification) is accepted. In UFS mode
-      (after -u or after a mode
-      ufs command), a path in a NetBSD file
-      system is expected. By default, the file is looked up in partition
-      ‘a’ of the first hard disk. Another device or partition can
-      be specified by prepending a block device name in terms of
-      NetBSD, followed by a colon (see
-      x86/boot(8) and examples).

-  

-  
Flags passed to the kernel, see x86/boot(8).

-

-

-
See x86/boot(8) for commands accepted after the
-    -c flag or in interactive mode.

-
dosboot is also installed in the
-    release(7) hierarchy, under
-    installation/misc/dosboot.com.

-

-

-

-
/usr/mdec/dosboot.com

-

-

-

-
To boot a NetBSD kernel located on MS-DOS
-    drive D, one would issue:

-

-
dosboot D:\NODOS\NETBSD

-

-
To boot from a NetBSD floppy into single
-    user mode, type e.g.:

-

-
dosboot -u fd0a:netbsd -s

-

-

-

-

-
release(7), x86/boot(8)

-

-

-

-
The NetBSD/x86
-    dosboot command first appeared in
-    NetBSD 1.3.

-

-

-

-
dosboot assumes that the processor is in
-    real mode at startup. It does not work well in the presence of MS-DOS
-    extenders and memory managers.

-
dosboot does not run directly under
-    Windows 95.

-
In UFS mode, files can only be loaded from devices known to the
-    BIOS. The device names do not necessarily comply with the names later used
-    by the booted NetBSD kernel.

-
In MS-DOS mode, no useful boot device specification is passed to
-    NetBSD. It is necessary to have the root device
-    hardwired into the kernel configuration or to enter it manually.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x86/mbr.8 4.html b/static/netbsd/man8/man8.x86/mbr.8 4.html
deleted file mode 100644
index 58f1bf01..00000000
--- a/static/netbsd/man8/man8.x86/mbr.8 4.html	
+++ /dev/null
@@ -1,154 +0,0 @@
-
-  
-    
-    
-    
-  
-
MBR(8)System Manager's Manual (x86)MBR(8)

-

-

-

-
mbr, bootselect
-    — Master Boot Record bootcode

-

-

-

-
An IBM PC boots from a disk by loading its first sector and
-    executing the code in it. For a hard disk, this first sector usually
-    contains a table of partitions present on the disk. The first sector of a
-    disk containing such a table is called the Master Boot Record (MBR).

-
The code present in the MBR will typically examine the partition
-    table, find the partition that is marked active, and boot from it. Booting
-    from a partition simply means loading the first sector in that partition,
-    and executing the code in it, as is done for the MBR itself.

-
NetBSD supplies several versions of the
-    MBR bootcode:

-

-  
 /usr/mdec/mbr

-  
This version has the same functionality as that supplied by DOS/Windows
-      and other operating systems: it picks the active partition and boots from
-      it. Its advantage over other, older MBRs, is that it can detect and use
-      extensions to the BIOS interface that will allow it to boot partitions
-      that cross or start beyond the 8 Gigabyte boundary.

-  

-    /usr/mdec/mbr_bootsel

-  
The bootselecting MBR contains configurable code that will present the
-      user with a simple menu, allowing a choice between partitions to boot
-      from, and hard disks to boot from. The choices and default settings can be
-      configured through fdisk(8).

-  
 /usr/mdec/mbr_ext

-  
The extended bootselecting MBR additionally allows
-      NetBSD to be loaded from an Extended partition. It
-      only supports systems whose BIOS supports the extensions to boot
-      partitions beyond the 8 Gigabyte boundary.

-  
 /usr/mdec/mbr_com0

-  
This has the same features as mbr_ext but will
-      read and write from the first serial port. It assumes that the BIOS has
-      initialized the baud rate.

-  
 /usr/mdec/mbr_com0_9600

-  
This has the same features as mbr_com0.
-      Additionally, it initializes the serial port to 9600 baud.

-

-
The rest of this manual page will discuss the bootselecting
-    versions of the MBR. The configurable items of the bootselector are:

-

-  
timeout

-  
The number of seconds that the bootcode will wait for the user to press a
-      key, selecting a menu item. Must be in the range 0-3600, or -1 when it
-      will wait forever.

-  
default

-  
The default partition or disk to boot from, should the timeout
-    expire.

-

-
The bootselector will output a menu of the
-     names
-    for each partition (as configured by fdisk(8)). The user
-    can then select the partition or drive to boot from via the keyboard.

-
The numeric keys
-     upwards will initiate
-    a startup from the corresponding partition.

-
Function keys
-     through
-     (keys
-     through
-     for the serial
-    versions) will boot from hard disks 0 through 7 (BIOS numbers 0x80 through
-    0x87). Booting from a drive is simply done by reading the MBR of that drive
-    and executing it, so the bootcode present in the MBR of the chosen drive
-    determines which partition (if any) will be booted in the end.

-
The
-     key will
-    cause the bootcode to find the active partition, and boot from it. If no key
-    is pressed, the (configurable) default selection is picked.

-

-

-

-
The following errors are detected:

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
1No active partitionThe MBR has a partition table without an active partition.
2Disk read errorThere was an error reading the bootsector for the partition or drive
-      selected.
3No operating systemThe bootsector was loaded successfully, but it was not valid (i.e., the
-      magic number check failed, or it contained no code).
LInvalid CHS readThe boot partition cannot be read using a CHS read and the system BIOS
-      doesn't support LBA reads.
?Unknown key.

-
The standard boot code will output the text message and stop. It
-    may be necessary to reset to the system to continue.

-
The bootselect code will output 'Error <code>' and await
-    further input.

-

-

-

-
disklabel(8), fdisk(8),
-    installboot(8), mbrlabel(8),
-    x86/boot(8)

-

-

-

-
The bootselect code has constraints because of the limited amount
-    of space available. The only way to be absolutely sure that a bootselector
-    will always fit on the disk when a partition table is used, is to make it
-    small enough to fit into the first sector (512 bytes, 404 excluding the
-    partition table and bootselect menu).

-
The error messages are necessarily terse.

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x86/multiboot.8 4.html b/static/netbsd/man8/man8.x86/multiboot.8 4.html
deleted file mode 100644
index 7f53ca34..00000000
--- a/static/netbsd/man8/man8.x86/multiboot.8 4.html	
+++ /dev/null
@@ -1,85 +0,0 @@
-
-  
-    
-    
-    
-  
-
MULTIBOOT(8)System Manager's Manual (x86)MULTIBOOT(8)

-

-

-

-
multiboot —
-    procedure for booting NetBSD/x86 from a Multiboot-compliant
-    boot loader

-

-

-

-
Multiboot is a specification that defines a protocol between a
-    boot loader and a kernel. This protocol allows passing boot information
-    between the two in a standard way, allowing any Multiboot-compliant boot
-    loader to boot any Multiboot-compliant kernel. The
-    NetBSD kernel supports Multiboot if it was compiled
-    with options MULTIBOOT (the default in the
-    ‘GENERIC’ and ‘GENERIC_LAPTOP’
-  configurations).

-
Unlike when using the native boot loader, the
-    NetBSD kernel recognizes a set of command line
-    arguments if booted through a Multiboot-compliant boot loader. This is
-    because the Multiboot protocol is not complete enough to completely
-    configure a NetBSD kernel.

-
The following arguments are recognized:

-

-  
console

-  
Specifies the console device name. Can be one of ‘com’ or
-      ‘pc’. If the former, console_addr and
-      console_speed should be given too.

-  
console_addr

-  
Specifies the serial port address for the console. Defaults to the value
-      of options CONADDR or ‘0x3f8’ if
-      this was not given.

-  
console_speed

-  
Specifies the serial port speed for the console. Defaults to the value of
-      options CONSPEED or ‘9600’ if this
-      was not given.

-  
root

-  
Specifies the name of the device to be mounted as the root partition. It
-      should not be needed because the kernel tries its best to guess which is
-      the root partition (basing the decision on the device from which the
-      kernel was loaded from). In cases where the automatic detection fails,
-      this flag comes useful. Example: ‘root=wd0e’.

-

-

-

-
GRUB Legacy is the most popular bootloader that supports
-    Multiboot. You can boot a NetBSD kernel (assuming it
-    is compiled with Multiboot support) with a line similar to the following
-    one:

-

-
kernel (fd0)/netbsd.gz -c console=pc root=wd0e

-

-

-

-

-

-
options(4)

-

-

-

-
multiboot support first appeared in
-    NetBSD 4.0.

-

-

-

-
multiboot support was added by
-    Julio M. Merino Vidal
-    <jmmv@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
October 25, 2006NetBSD 10.1

diff --git a/static/netbsd/man8/man8.x86/pxeboot.8 4.html b/static/netbsd/man8/man8.x86/pxeboot.8 4.html
deleted file mode 100644
index 86bc5894..00000000
--- a/static/netbsd/man8/man8.x86/pxeboot.8 4.html	
+++ /dev/null
@@ -1,240 +0,0 @@
-
-  
-    
-    
-    
-  
-
PXEBOOT(8)System Manager's Manual (x86)PXEBOOT(8)

-

-

-

-
pxeboot — network
-    boot NetBSD/x86 through a PXE BIOS extension

-

-

-

-
pxeboot is a
-    NetBSD boot program running on top of a PXE BIOS
-    extension which is provided by the motherboard or a plug-in network adapter,
-    in accordance with the Intel Preboot eXecution Environment (PXE)
-    specification.

-
By default, the pxeboot program is
-    configured with modules loading and boot.cfg(5) support
-    disabled. See EXAMPLES for how to enable
-    these options individually. This manual page assumes that
-    boot.cfg(5) support is enabled.

-
Network booting a system through PXE is a two-stage process:

-
    
-  
  1. The PXE BIOS issues a DHCP request and fetches the
-      NetBSD pxeboot program
-      using TFTP.
    2. 
-  
  2. The NetBSD pxeboot program
-      takes control. It immediately issues another DHCP request to get the name
-      of a boot.cfg(5) file to load, using
-      “boot.cfg” by default. If the boot config file is not found,
-      or if the supplied file appears not to be a boot configuration file, the
-      file is skipped. Otherwise it is loaded and obeyed as described in
-      boot.cfg(5). If a boot configuration is not loaded, the
-      user has the option to enter a limited version of the standard interactive
-      boot mode by pressing a key within five seconds. After this time, or after
-      the user's boot command, another DHCP request is
-      issued and the kernel filename returned by the DHCP reply, using
-      “netbsd” by default, is loaded. To read the kernel file, the
-      NFS (version 2) or TFTP protocols can be used.
    3. 
-

-
The DHCP request issued by the NetBSD
-    pxeboot program has the following special
-    parameters:

-

-  
Bootfile name

-  
is set to “boot.cfg” during the first request, and then to
-      the filename argument on the
-      boot command line typed in by the user (can be
-      empty), using “netbsd” in the non-interactive case.

-  
DHCP Vendor class identifier tag

-  
is set to “NetBSD:i386:libsa”.

-

-
The DHCP server can use these fields (i.e. the DHCP vendor class
-    identifier tag and the requested file name, possibly supplied by the user's
-    command line input to the pxeboot program) to
-    distinguish between the various originators of requests (PXE BIOS, first and
-    second pxeboot stage, NetBSD
-    kernel), and to alter its behaviour. For example, this can be used to
-    support alternative NetBSD installations on one
-    machine.

-
In addition to the standard network interface configuration, the
-    following fields in the DHCP reply are interpreted:

-

-  
Bootfile name

-  
specifies the protocol to be used, and the filename of the boot config or
-      NetBSD kernel to be booted, separated by a colon.
-      Available protocols are “nfs” and “tftp”. The
-      boot config or kernel filename part is interpreted relatively to the NFS
-      root directory (see the
-       reply
-      field below) or the TFTP server's root directory (which might be a
-      subdirectory within the TFTP server's filesystem, depending on the
-      implementation), respectively. If the Bootfile name
-      field replied by the DHCP server does not contain a colon, it is ignored,
-      and the filename typed in at the
-      pxeboot command line prompt (or the
-      “netbsd” default, see the section about the
-      Bootfile name field in the DHCP request above) is used.
-      If no protocol was specified, “nfs” is assumed.

-  
Next server

-  
is used as the location of the tftp server.

-  
Swap server

-  
can be used to override the “server IP address” if NFS is
-      used to access the kernel. This matches the behaviour of the
-      NetBSD kernel to access its root file system on
-      NFS. This way, different TFTP and NFS servers can be communicated to the
-      DHCP client (it is actually a deficiency of the DHCP protocol to provide a
-      “root path” field but no corresponding IP address).

-  
Root path

-  
is used as path to be mounted in the NFS case to access the kernel file,
-      matching the NetBSD kernel's behaviour.

-

-
See x86/boot(8) for the commands accepted in
-    interactive mode.

-
By default the output from pxeboot and
-    from the booted kernel will go to the system's BIOS console. This can be
-    changed to be one of the serial ports by using
-    installboot to modify the boot options contained in
-    the pxeboot_ia32.bin file.

-

-

-

-

-  
/usr/mdec/pxeboot_ia32.bin

-  
 

-

-

-

-

-
To enable boot.cfg(5) support in the
-    pxeboot program:

-

-
installboot -e -o bootconf pxeboot_ia32.bin

-

-
To enable modules loading support in the
-    pxeboot program:

-

-
installboot -e -o modules pxeboot_ia32.bin

-

-
The first /etc/dhcpd.conf example shows a
-    simple configuration which just loads “boot.cfg” and
-    “netbsd” from the client's NFS root directory, using the
-    defaults for protocol and kernel filename. Similar setups should be possible
-    with any BOOTP/DHCP server.

-

-
host myhost {
-    hardware ethernet 00:00:00:00:00:00;
-    fixed-address myhost;
-    option host-name "myhost";
-    filename "pxeboot_ia32.bin";
-    option swap-server mynfsserver;
-    option root-path "/export/myhost";
-}

-

-
The following /etc/dhcpd.conf entry sets
-    loads the boot config and kernel over tftp. This can be used, for example,
-    for installing machines by using an install kernel.

-

-
host myhost {
-    hardware ethernet 00:00:00:00:00:00;
-    fixed-address myhost;
-    option host-name "myhost";
-    next-server mytftpserver;
-
-    # This section allows dhcpd to respond with different answers
-    # for the different tftp requests for the bootloader and kernel.
-    if substring (option vendor-class-identifier, 0, 20)
-      = "PXEClient:Arch:00000" {
-        filename "pxeboot_ia32.bin";
-    } elsif substring (option vendor-class-identifier, 0, 17)
-      = "NetBSD:i386:libsa" {
-        if filename = "boot.cfg" {
-            filename "tftp:boot.cfg";
-        } else if filename = "netbsd" {
-            filename "tftp:netbsd-INSTALL.gz";
-        }
-    }
-}

-

-
The following /etc/dhcpd.conf entry shows
-    how different system installations can be booted depending on the user's
-    input on the pxeboot command line.

-

-
host myhost {
-    hardware ethernet 00:00:00:00:00:00;
-    fixed-address myhost;
-    option host-name "myhost";
-    next-server mytftpserver;
-    if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
-        filename "pxeboot_ia32.bin";
-    } elsif filename = "boot.cfg" {
-        filename "tftp:boot.cfg";
-    } elsif filename = "tftp" {
-        filename "tftp:netbsd.myhost";
-    } else {
-        option swap-server mynfsserver;
-        option root-path "/export/myhost";
-        if filename = "generic" {
-            filename "nfs:gennetbsd";
-        } else {
-            filename "nfs:netbsd";
-        }
-    }
-}

-

-
The TFTP server is supplied using the
-    
-    directive. The NFS server for the root file system is
-    .
-    The
-    
-    is only used in the NFS case and by the NetBSD
-    kernel to mount the root file system.

-

-

-

-
boot.cfg(5), dhcpd(8),
-    diskless(8), installboot(8),
-    x86/boot(8)

-
Intel Corporation,
-    Preboot Execution Environment (PXE) Specification,
-    Version 2.1, September 20,
-    1999.

-

-

-

-
The NetBSD/x86
-    pxeboot command first appeared in
-    NetBSD 1.6.

-

-

-

-
If an error is encountered while reading the
-    NetBSD kernel file or if its file format wasn't
-    recognized, it is impossible to retry the operation because the PXE network
-    stack is already removed from the system RAM.

-
You need the pxeboot from an i386 build to
-    boot an i386 kernel, and that from an amd64 build to boot an amd64
-  kernel.

-
In a Xen setup, the NetBSD DOM0 kernel is
-    loaded as a module, and cannot know the device from which the Xen hypervisor
-    was booted. In this case, the DOM0 kernel will fall back to the default boot
-    device (typically the first disk on the host). If the boot device is
-    different from the default one, consider passing additional arguments, like
-    bootdev, to the DOM0 kernel as explained in the
-    load command subsection in
-    x86/boot(8).

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/nis.8 4.html b/static/netbsd/man8/nis.8 4.html
deleted file mode 100644
index 7f6b534e..00000000
--- a/static/netbsd/man8/nis.8 4.html	
+++ /dev/null
@@ -1,214 +0,0 @@
-
-  
-    
-    
-    
-  
-
NIS(8)System Manager's ManualNIS(8)

-

-

-

-
nis, yp —
-    description of the NIS (formerly YP) subsystem

-

-

-

-
-  
-    
-    
-  
-
ypbind[-ypset]

-

-
-  
-    
-    
-  
-
ypbind[-ypsetme]

-

-

-
-  
-    
-    
-  
-
ypset[-h host]
-      [-d domain]
-      server

-

-

-
-  
-    
-    
-  
-
yppoll[-h host]
-      [-d domain]
-      mapname

-

-

-
-  
-    
-    
-  
-
ypcat[-kt] [-d
-      domainname] mapname

-

-
-  
-    
-    
-  
-
ypcat-x

-

-

-
-  
-    
-    
-  
-
ypmatch[-kt] [-d
-      domainname] key ...
-      mapname

-

-
-  
-    
-    
-  
-
ypmatch-x

-

-

-
-  
-    
-    
-  
-
ypwhich[-d domain]
-      [[-t] -m
-      [mname] | host]

-

-
-  
-    
-    
-  
-
ypwhich-x

-

-

-
-  
-    
-    
-  
-
ypserv[-d] [-x]

-

-

-
-  
-    
-    
-  
-
yppush[-d domainname]
-      [-h hostname]
-      [-v] mapname

-

-

-
-  
-    
-    
-  
-
ypxfr[-bcf] [-d
-      domain] [-h
-      host] [-s
-      domain] [-C
-      tid prog ipadd port]
-      mapname

-

-

-
-  
-    
-    
-  
-
ypinit-m [domainname]

-

-
-  
-    
-    
-  
-
ypinit-s master_server
-      [domainname]

-

-

-
-  
-    
-    
-  
-
yptest

-

-

-
-  
-    
-    
-  
-
rpc.yppasswdd[-noshell] [-nogecos]
-      [-nopw] [-m
-      arg1 arg2 ...]

-

-

-

-
The NIS subsystem allows network management of passwd and group
-    file entries through the functions getpwent(3) and
-    getgrent(3). NIS also provides hooks for other client
-    programs, such as amd(8) and
-    rpc.bootparamd(8), that can use NIS maps.

-
Password maps in standard YP are insecure, because the pw_passwd
-    field is accessible by any user. A common solution to this is to generate a
-    secure map (using “makedbm -s”) which can only be accessed by
-    a client bound to a privileged port. To activate the secure map, see the
-    appropriate comment in /var/yp/Makefile.yp.

-
The NIS subsystem is conditionally started in
-    /etc/rc. See the
-    /etc/rc.conf file for configuration variables.

-

-

-

-
domainname(1), ypcat(1),
-    ypmatch(1), ypwhich(1),
-    ypclnt(3), group(5),
-    hosts_access(5), nsswitch.conf(5),
-    passwd(5), rc.conf(5),
-    rc(8), ypbind(8),
-    ypinit(8), yppoll(8),
-    yppush(8), ypserv(8),
-    ypset(8), yptest(8),
-    ypxfr(8)

-

-

-

-
The NIS client subsystem was originally written by Theo de Raadt
-    to be compatible with Sun's implementation. The NIS server suite was
-    originally written by Mats O Jansson.

-

-

-

-
If ypbind(8) cannot find a server, the system
-    behaves the same way as Sun's code: it hangs.

-
The ‘secure map’ feature is not compatible with
-    non-BSD implementations as found e.g. in Solaris.

-

-

-
-  
-    
-    
-  
-
February 26, 2005NetBSD 10.1

diff --git a/static/netbsd/man8/pam.8 4.html b/static/netbsd/man8/pam.8 4.html
deleted file mode 100644
index ba34745d..00000000
--- a/static/netbsd/man8/pam.8 4.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
PAM(8)System Manager's ManualPAM(8)

-

-

-

-
pam — Pluggable
-    Authentication Modules framework

-

-

-

-
The Pluggable Authentication Modules (PAM) framework is a system
-    of libraries that perform authentication tasks for services and
-    applications. Applications that use the PAM API may have their
-    authentication behavior configured by the system administrator through the
-    use of the service's PAM configuration file.

-
PAM modules provide four classes of functionality:

-

-  
account

-  
Account verification services such as password expiration and access
-      control.

-  
auth

-  
Authentication services. This usually takes the form of a
-      challenge-response conversation. However, PAM can also support, with
-      appropriate hardware support, biometric devices, smart-cards, and so
-      forth.

-  
password

-  
Password (or, more generally, authentication token) change and update
-      services.

-  
session

-  
Session management services. These are tasks that are performed before
-      access to a service is granted and after access to a service is withdrawn.
-      These may include updating activity logs or setting up and tearing down
-      credential forwarding agents.

-

-
A primary feature of PAM is the notion of “stacking”
-    different modules together to form a processing chain for the task. This
-    allows fairly precise control over how a particular authentication task is
-    performed, and under what conditions. PAM module configurations may also
-    inherit stacks from other module configurations, providing some degree of
-    centralized administration.

-

-

-

-
login(1), passwd(1),
-    su(1), pam(3),
-    pam.conf(5), pam_chroot(8),
-    pam_deny(8), pam_echo(8),
-    pam_exec(8), pam_ftpusers(8),
-    pam_group(8), pam_guest(8),
-    pam_krb5(8), pam_ksu(8),
-    pam_lastlog(8), pam_login_access(8),
-    pam_nologin(8), pam_permit(8),
-    pam_radius(8), pam_rhosts(8),
-    pam_rootok(8), pam_securetty(8),
-    pam_self(8), pam_skey(8),
-    pam_ssh(8), pam_unix(8)

-

-

-

-
The Pluggable Authentication Module framework was originally
-    developed by SunSoft, described in DCE/OSF-RFC 86.0, and first deployed in
-    Solaris 2.6. It was later incorporated into the X/Open Single Sign-On
-    Service (XSSO) Pluggable Authentication Modules specification.

-
The Pluggable Authentication Module framework first appeared in
-    NetBSD 3.0.

-

-

-
-  
-    
-    
-  
-
February 28, 2005NetBSD 10.1

diff --git a/static/netbsd/man8/rc.8 4.html b/static/netbsd/man8/rc.8 4.html
deleted file mode 100644
index d14cb1d8..00000000
--- a/static/netbsd/man8/rc.8 4.html	
+++ /dev/null
@@ -1,292 +0,0 @@
-
-  
-    
-    
-    
-  
-
RC(8)System Manager's ManualRC(8)

-

-

-

-
rc, rc.local,
-    rc.shutdown,
-    rc.shutdown.final, rc.d/
-    — startup and shutdown scripts

-

-

-

-
-  
-    
-    
-  
-
rc

-

-
-  
-    
-    
-  
-
rc.local

-

-
-  
-    
-    
-  
-
rc.shutdown

-

-
-  
-    
-    
-  
-
rc.d/

-

-

-

-
rc is the command script which controls
-    the startup of various services, and is invoked by init(8)
-    as part of the process of entering the automatic reboot to multi-user
-    startup, or after the single user mode shell has exited. If
-    init(8) is starting the automatic reboot process,
-    rc is invoked with the argument of
-    ‘autoboot’.

-
rc.local is a command script to which
-    local boot-time actions can be added. It is (nearly) the last thing invoked
-    by rc during a normal boot.

-
rc.shutdown is the command script which
-    shuts down various services, and is invoked by shutdown(8)
-    as part of the process of shutting down the system.

-
rc.d/ is the directory which contains
-    various sh(1) scripts, one for each service, which are
-    called by rc at startup,
-    rc.shutdown at shutdown, and as necessary during
-    system operation to stop, start, restart, reload, or otherwise control the
-    service.

-

-

-
    
-  
  1. Source /etc/rc.subr to load various
-      rc.subr(8) shell functions to use.
    2. 
-  
  2. If autobooting, set
-      
-      and enable a flag (rc_fast=yes), which prevents the
-      rc.d scripts from performing the check for already
-      running processes (thus speeding up the boot process). This
-      rc_fast=yes speedup won't occur when
-      rc is started up after exiting the single-user
-      shell.
    3. 
-  
  3. Invoke rcorder(8) to order the files in
-      /etc/rc.d/ that do not have a
-      “nostart” keyword (refer to rcorder(8)'s
-      -s flag), and assigns the result to a
-    variable.
    4. 
-  
  4. Calls each script in turn using
-      ()
-      (from rc.subr(8)), which sets $1
-      to ‘start’, and sources the script in a sub-shell. If the
-      script has a ‘.sh’ suffix then it is sourced directly into
-      the current shell.
    5. 
-  
  5. The output from the above steps is sent to a post-processor. If
-      rc_silent is false, then the post-processor displays the
-      output. If rc_silent is true, then the post-processor
-      invokes the command specified in rc_silent_cmd once
-      for each line, without otherwise displaying the output. Useful values for
-      rc_silent_cmd include “:” to display
-      nothing at all, and “twiddle” to display a spinning symbol
-      on the console. Regardless of the value of rc_silent,
-      the post-processor saves the output in
-      /var/run/rc.log.
    6. 
-

-

-

-

-
    
-  
  1. Source /etc/rc.subr to load various
-      rc.subr(8) shell functions to use.
    2. 
-  
  2. Invoke rcorder(8) to order the files in
-      /etc/rc.d/ that have a “shutdown”
-      keyword (refer to rcorder(8)'s
-      -k flag), reverses that order, and assigns the
-      result to a variable.
    3. 
-  
  3. Calls each script in turn using run_rc_script()
-      (from rc.subr(8)), which sets $1
-      to ‘stop’, and sources the script in a sub-shell. If the
-      script has a ‘.sh’ suffix then it is sourced directly into
-      the current shell.
    4. 
-  
  4. Runs /etc/rc.shutdown.final if it exists, passing
-      the currently ongoing shutdown action, which will be one of:
-    
      
-      
    • shutdown when going to single user mode.
      • 
-      
    • halt when halting the machine (but not powering it down).
      • 
-      
    • reboot when rebooting the machine.
      • 
-      
    • poweroff when halting the machine and powering it off.
      • 
-    
    
-    
    The script may be used to control additional actions, e.g.
-        powering off external devices, restarting a UPS (in case main power is
-        restored in the interval betweeen the computer powering off and the UPS
-        running out of battery).
    
-  
    5. 
-

-

-

-

-
rc.d/ is located in
-    /etc/rc.d. The following file naming conventions are
-    currently used in rc.d/:

-

-

-  
ALLUPPERCASE

-  
Scripts that are ‘placeholders’ to ensure that certain
-      operations are performed before others. In order of startup, these are:
-    

-      
NETWORKING

-      
Ensure basic network services are running, including general network
-          configuration (network) and
-          dhcpcd.

-      
SERVERS

-      
Ensure basic services (such as NETWORKING,
-          ppp, syslogd, and
-          kdc) exist for services that start early (such
-          as named), because they're required by
-          DAEMON below.

-      
DAEMON

-      
Before all general purpose daemons such as
-          dhcpd, lpd, and
-          ntpd.

-      
LOGIN

-      
Before user login services (inetd,
-          telnetd, rshd,
-          sshd, and xdm), as
-          well as before services which might run commands as users
-          (cron, postfix, and
-          sendmail).

-    

-  

-  
inline.sh

-  
Scripts that are sourced into the current shell rather than a sub-shell
-      have a ‘.sh’ suffix. Extreme care
-      must be taken in using this, as the startup sequence will terminate if the
-      script causes the current shell process to terminate.
-      /etc/rc.d/bootconf.sh uses this behaviour to allow
-      the user to select a different configuration (including
-      /etc/rc.conf) early in the boot.

-  
service

-  
Scripts that are sourced in a sub-shell. The boot does not stop if such a
-      script terminates with a non-zero status, but a script can stop the boot
-      if necessary by invoking the
-      ()
-      function (from rc.subr(8)).

-

-

-
Each script should contain rcorder(8) keywords,
-    especially an appropriate “PROVIDE” entry.

-
The scripts are expected to support at least the following
-    arguments:

-

-

-  

-  
Start the service. This should check that the service is to be started as
-      specified by rc.conf(5). Also checks if the service is
-      already running and refuses to start if it is. This latter check is not
-      performed by standard NetBSD scripts if the system
-      is starting directly to multi-user mode, to speed up the boot
-    process.

-  

-  
If the service is to be started as specified by
-      rc.conf(5), stop the service. This should check that the
-      service is running and complain if it's not.

-  

-  
Perform a stop then a start.

-  

-  
If the script starts a process (rather than performing a one-off
-      operation), show the status of the process. Otherwise it's not necessary
-      to support this argument. Defaults to displaying the process ID of the
-      program (if running).

-  

-  
If the script starts a process (rather than performing a one-off
-      operation), wait for the command to exit. Otherwise it's not necessary to
-      support this argument.

-  

-  
Display which rc.conf(5) variables are used to control
-      the startup of the service (if any).

-

-

-
Other arguments (such as ‘reload’,
-    ‘dumpdb’, etc) can be added if necessary.

-
The argument may have one of the following prefixes to alter its
-    operation:

-

-

-  

-  
Skip the check for an existing running process. Sets
-      rc_fast=yes.

-  

-  
Skips the rc.conf(5) check, ignores a failure result
-      from any of the prerequisite checks, executes the command, and always
-      returns a zero exit status. Sets
-      .

-  

-  
Skips the rc.conf(5) check, but performs all other
-      prerequisite tests.

-

-

-
In order to simplify scripts, the
-    ()
-    function from rc.subr(8) may be used.

-

-

-

-

-

-  
/etc/rc

-  
Startup script called by init(8).

-  
/etc/rc.d/

-  
Directory containing control scripts for each service.

-  
/etc/rc.local

-  
Local startup script.

-  
/etc/rc.shutdown

-  
Shutdown script called by shutdown(8).

-  
/etc/rc.subr

-  
Contains rc.subr(8) functions used by various
-    scripts.

-  
/etc/rc.conf

-  
System startup configuration file.

-  
/var/run/rc.log

-  
Log file created by rc.

-

-

-

-

-
rc.conf(5), init(8),
-    rc.subr(8), rcorder(8),
-    reboot(8), shutdown(8)

-
Luke Mewburn,
-    The Design and Implementation of the NetBSD rc.d
-    system, Proceedings of the FREENIX Track: 2001 USENIX
-    Annual Technical Conference, USENIX Association,
-    http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/full_papers/mewburn/mewburn.pdf,
-    June 25-30, 2001.

-

-

-

-
The rc command appeared in
-    4.0BSD. The /etc/rc.d
-    support was implemented in NetBSD 1.5 by
-    Luke Mewburn ⟨lukem@NetBSD.org⟩. The
-    post-processor, support for rc_silent, and saving
-    output to a file, was implemented in NetBSD 6.0 by
-    Alan Barrett.

-

-

-
-  
-    
-    
-  
-
December 7, 2024NetBSD 10.1

diff --git a/static/netbsd/man8/rc.subr.8 4.html b/static/netbsd/man8/rc.subr.8 4.html
deleted file mode 100644
index 93855b5f..00000000
--- a/static/netbsd/man8/rc.subr.8 4.html	
+++ /dev/null
@@ -1,575 +0,0 @@
-
-  
-    
-    
-    
-  
-
RC.SUBR(8)System Manager's ManualRC.SUBR(8)

-

-

-

-
rc.subr —
-    functions used by system shell scripts

-

-

-

-
-

-

-

-
rc.subr contains commonly used shell
-    script functions which are used by various scripts such as
-    rc(8), and the periodic system services which are
-    controlled by daily.conf(5),
-    monthly.conf(5), security.conf(5), and
-    weekly.conf(5).

-
The rc.subr functions are accessed by
-    sourcing /etc/rc.subr into the current shell.

-
The following shell functions are available:

-

-  

-    action file
-    current backup

-  
Make a backup copy of file into
-      current. If the rc.conf(5)
-      variable
-      
-      is ‘YES’, use rcs(1) to archive the
-      previous version of current, otherwise save the
-      previous version of current as
-      backup.
-    
action may be one of the following:

-    

-      

-      
file is now being backed up by or possibly
-          re-entered into this backup mechanism. current
-          is created, and if necessary, the rcs(1) files are
-          created as well.

-      

-      
file has changed and needs to be backed up. If
-          current exists, it is copied to
-          backup or checked into rcs(1)
-          (if the repository file is old), and then file
-          is copied to current.

-      

-      
file is no longer being tracked by this backup
-          mechanism. If rcs(1) is being used, an empty file is
-          checked in and current is removed, otherwise
-          current is moved to
-          backup.

-    

-  

-  

-    file [suffix]

-  
Just like basename(1), except implemented using shell
-      built-in commands, and usable before the /usr/bin
-      direcory is available.

-  

-    var

-  
Return 0 if var is defined to ‘YES’,
-      ‘TRUE’, ‘ON’, or ‘1’. Return 1
-      if var is defined to ‘NO’,
-      ‘FALSE’, ‘OFF’, or ‘0’.
-      Otherwise, warn that var is not set correctly. The
-      values are case insensitive.
-    
Note that the warning message shown by this function when
-        var is not set references a manual page where the
-        user can find more information. Its name is picked up from the
-        rcvar_manpage variable.

-  

-  

-    pidfile procname
-    [interpreter]

-  
Parses the first word of the first line of pidfile
-      for a PID, and ensures that the process with that PID is running and its
-      first argument matches procname. Prints the matching
-      PID if successful, otherwise nothing. If interpreter
-      is provided, parse the first line of procname,
-      ensure that the line is of the form
-    
#! interpreter [...]

-    and use interpreter with its optional arguments and
-      procname appended as the process string to search
-      for.

-  

-    procname [interpreter]

-  
Prints the PIDs of any processes that are running with a first argument
-      that matches procname.
-      interpreter is handled as per
-      check_pidfile.

-  

-  
Copy input to output, collapsing
-      ⟨backslash⟩⟨newline⟩ to nothing, but leaving
-      other backslashes alone. dirname
-      file Just like dirname(1), except
-      implemented using shell built-in commands, and usable before the
-      /usr/bin direcory is available.

-  

-    exitval message

-  
Display an error message to stderr, log it to the system
-      log using logger(1), and exit
-      with an exit value of exitval. The error message
-      consists of the script name (from $0), followed by
-      “: ERROR: ”, and then message.

-  

-    command

-  
Source in the rc.conf(5) configuration files for
-      command. First, /etc/rc.conf
-      is sourced if it has not yet been read in. Then,
-      /etc/rc.conf.d/command is
-      sourced if it is an existing file. The latter may also contain other
-      variable assignments to override run_rc_command
-      arguments defined by the calling script, to provide an easy mechanism for
-      an administrator to override the behaviour of a given
-      rc.d(8) script without requiring the editing of that
-      script.

-  

-    command var

-  
Read the rc.conf(5) variable var
-      for command and set in the current shell, using
-      load_rc_config in a sub-shell to prevent unwanted
-      side effects from other variable assignments.

-  

-    type

-  
Go through a list of critical file systems, as found in the
-      rc.conf(5) variable
-      type,
-      mounting each one that is not currently mounted.

-  

-    command [arguments]

-  
Execute the specified command with the specified arguments, in such a way
-      that its output bypasses the post-processor that rc(8)
-      uses for most commands. This implies that the output will not appear in
-      the /var/run/rc.log file, and will appear on the
-      console regardless of the value of rc_silent. This
-      is expected to be useful for interactive commands, and this mechanism is
-      automatically used by run_rc_command when a script
-      contains the rcorder(8) keyword
-      “interactive”.
-    
If invoked from a context that does not appear to be under the
-        control of rc(8), then the command is executed without
-        special treatment.

-  

-  
-  
Print the specified string in such a way that it
-      should be handled as meta-data by the rc(8)
-      post-processor. If invoked from a context that does not appear to be under
-      the control of rc(8), then the
-      string is discarded.
-    
Any rc.d(8) script may invoke this function
-        with an argument that begins with “note:”, followed by one
-        line of arbitrary text; the text will be logged by
-        rc(8) but will not be displayed on the console.

-    
The use of arguments that do not begin with
-        “note:” is reserved for internal use by
-        rc(8) and rc.subr.

-  

-  
-  
Print the specified string in such a way that it
-      should be handled as normal output by the rc(8)
-      post-processor. If invoked from a context that does not appear to be under
-      the control of rc(8), then the
-      string is printed to standard output.
-    
If the -n flag is specified, then the
-        string is printed without a newline.

-    
Intended use cases include:

-    
    
-      
  • An rc.d script can use “print_rc_normal
-          -n” to print a partial line in such a
-          way that it appears immediately instead of being buffered by
-          rc(8)'s post-processor.
    • 
-      
  • An rc.d script that is run via the no_rc_postprocess
-          function (so most of its output is invisible to
-          rc(8)'s post-processor) can use
-          print_rc_normal to force some of its output to be
-          seen by the post-processor.
    • 
-    

-  

-  

-    command [...]

-  
Print a usage message for $0, with
-      commands being the list of valid arguments prefixed
-      by “[fast|force|one]”.

-  

-    item [...]

-  
Print the list of items in reverse order.

-  

-    argument [parameter ...]

-  
Run the argument method for the current
-      rc.d(8) script, based on the settings of various shell
-      variables. run_rc_command is extremely flexible,
-      and allows fully functional rc.d(8) scripts to be
-      implemented in a small amount of shell code. The optional set of
-      parameters is passed verbatim to the command, but not to its pre/post
-      hooks.
-    
argument is searched for in the list of
-        supported commands, which may be one of:

-    

-    

-      

-      
Start the service. This should check that the service is to be started
-          as specified by rc.conf(5). Also checks if the
-          service is already running and refuses to start if it is. This latter
-          check is not performed by standard NetBSD
-          scripts if the system is starting directly to multi-user mode, to
-          speed up the boot process.

-      

-      
If the service is to be started as specified by
-          rc.conf(5), stop the service. This should check that
-          the service is running and complain if it's not.

-      

-      
Perform a stop then a start.
-          Defaults to displaying the process ID of the program (if
-        running).

-      

-      
Display which rc.conf(5) variables are used to
-          control the startup of the service (if any).

-    

-    

-    
If pidfile or procname is
-        set, also support:

-    

-    

-      

-      
Wait for the command to exit.

-      

-      
Show the status of the process.

-    

-    

-    
Other supported commands are listed in the optional variable
-        extra_commands.

-    
argument may have one of the following
-        prefixes which alters its operation:

-    

-    

-      

-      
Skip the check for an existing running process, and sets
-          .

-      

-      
Skip the checks for rcvar being set to yes, and sets
-          .
-          This ignores argument_precmd
-          returning non-zero, and ignores any of the
-          required_* tests failing, and always returns a zero
-          exit status.

-      

-      
Skip the checks for rcvar being set to yes, but
-          performs all the other prerequisite tests.

-    

-    

-    
run_rc_command uses the following
-        shell variables to control its behaviour. Unless otherwise stated, these
-        are optional.

-    

-    

-      

-      
The name of this script. This is not optional.

-      

-      
The value of rcvar is checked with
-          checkyesno to determine if this method should
-          be run.

-      

-      
The manual page containing information about rcvar.
-          It will be part of the warning message shown when
-          rcvar is undefined. Defaults to
-          rc.conf(5).

-      

-      
Full path to the command. Not required if
-          argument_cmd is defined for
-          each supported keyword.

-      

-      
Optional arguments and/or shell directives for
-          command.

-      

-      

-          is started with
-        
#! command_interpreter
-          [...]

-        which results in its ps(1) command being
-        
command_interpreter [...]
-          command

-        so use that string to find the PID(s) of the running command rather than
-          ‘command’.

-      

-      
Extra commands/keywords/arguments supported.

-      

-      
Path to pid file. Used to determine the PID(s) of the running command.
-          If pidfile is set, use
-        
check_pidfile $pidfile
-          $procname

-        to find the PID. Otherwise, if command is set, use
-        
check_process
-          $procname

-        to find the PID.

-      

-      
Process name to check for. Defaults to the value of
-          command.

-      

-      
Check for the existence of the listed directories before running the
-          default start method.

-      

-      
Check for the readability of the listed files before running the
-          default start method.

-      

-      
Perform checkyesno on each of the list
-          variables before running the default start method.

-      

-      
Directory to cd to before running
-          command, if ${name}_chroot is not
-          provided.

-      

-      
Directory to chroot(8) to before running
-          command. Only supported after
-          /usr is mounted.

-      

-      
List of additional or modified environment variables to set when
-          starting command.

-      

-      
Arguments to call command with. This is usually set
-          in rc.conf(5), and not in the
-          rc.d(8) script. The environment variable
-          ‘flags’ can be used to override
-          this.

-      

-      
nice(1) level to run command as.
-          Only supported after /usr is mounted.

-      

-      
User to run command as, using
-          chroot(8). if ${name}_chroot is
-          set, otherwise uses su(1). Only supported after
-          /usr is mounted.

-      

-      
Group to run the chrooted command as.

-      

-      
Comma separated list of supplementary groups to run the chrooted
-          command with.

-      
argument_cmd

-      
Shell commands which override the default method for
-          argument.

-      
argument_precmd

-      
Shell commands to run just before running
-          argument_cmd or the default
-          method for argument. If this returns a non-zero
-          exit code, the main method is not performed. If the default method is
-          being executed, this check is performed after the
-          required_* checks and process (non-)existence
-          checks.

-      
argument_postcmd

-      
Shell commands to run if running
-          argument_cmd or the default
-          method for argument returned a zero exit
-        code.

-      

-      
Signal to send the processes to stop in the default
-          stop method. Defaults to
-          SIGTERM.

-      

-      
Signal to send the processes to reload in the default
-          reload method. Defaults to
-          SIGHUP.

-    

-    

-    
For a given method argument, if
-        argument_cmd is not defined,
-        then a default method is provided by
-      run_rc_command:

-    

-    

-      

-      

-      

-      
If command is not running and
-          checkyesno rcvar succeeds,
-          start command.

-      

-      
Determine the PIDs of command with
-          check_pidfile or
-          check_process (as appropriate),
-          kill sig_stop those PIDs,
-          and run wait_for_pids on those PIDs.

-      

-      
Similar to stop, except that it uses
-          sig_reload instead, and doesn't run
-          wait_for_pids.

-      

-      
Runs the stop method, then the
-          start method.

-      

-      
Show the PID of command, or some other script
-          specific status operation.

-      

-      
Wait for command to exit.

-      

-      
Display which rc.conf(5) variable is used (if any).
-          This method always works, even if the appropriate
-          rc.conf(5) variable is set to
-        ‘NO’.

-    

-    

-    
The following variables are available to the methods (such as
-        argument_cmd) as well as after
-        run_rc_command has completed:

-    

-    

-      

-      
Argument provided to run_rc_command, after fast and
-          force processing has been performed.

-      

-      
Flags to start the default command with. Defaults to
-          ${name}_flags, unless overridden by the environment
-          variable ‘flags’. This variable
-          may be changed by the
-          argument_precmd method.

-      

-      
PID of command (if appropriate).

-      

-      
Not empty if “fast” prefix was used.

-      

-      
Not empty if “force” prefix was used.

-    

-    

-  

-  

-    file argument

-  
Start the script file with an argument of
-      argument, and handle the return value from the
-      script.
-    
Various shell variables are unset before
-        file is started:

-    
name,
-      command, command_args,
-      command_interpreter, extra_commands,
-      pidfile, rcvar,
-      required_dirs, required_files,
-      required_vars,
-      argument_cmd,
-      argument_precmd.
-      argument_postcmd.

-    
The startup behaviour of file depends
-        upon the following checks:

-    
    
-      
  1. If file ends in .sh, it
-          is sourced into the current shell.
    2. 
-      
  2. If file appears to be a backup or scratch file
-          (e.g., with a suffix of ‘~’, ‘#’,
-          ‘.OLD’, or ‘.orig’), ignore it.
    3. 
-      
  3. If file is not executable, ignore it.
    4. 
-      
  4. If the rc.conf(5) variable
-          
-          is empty, source file in a sub shell, otherwise
-          source file into the current shell.
    5. 
-      
  5. If file contains the
-          rcorder(8) keyword “interactive”, then
-          the command is executed using
-          no_rc_postprocess.
    6. 
-    

-  

-  

-  
Prevent booting to multiuser mode. If the
-      
-      variable is ‘yes’, then a
-      
-      signal is sent to the parent process (which is assumed to be
-      rc(8)). Otherwise, the shell exits with status
-      1.

-  

-  
Display one of the characters ‘/, -, \, |’, followed by a
-      backspace. Repeated calls to this function will create the appearance of a
-      spinning symbol, as a different character is displayed on each call.
-      Output is to /dev/tty, so this function may be
-      useful even inside a script whose output has been redirected.

-  

-    [pid [...]]

-  
Wait until all of the provided pids don't exist any
-      more, printing the list of outstanding pids every
-      two seconds.

-  

-    message

-  
Display a warning message to stderr and log it to the
-      system log using logger(1). The warning message consists
-      of the script name (from $0), followed by “:
-      WARNING: ”, and then message.

-  

-    var

-  
Change the value of the specified variable from any of the forms
-      acceptable to the checkyesno function, to
-      “true” or “false”.

-

-

-

-

-

-  
/etc/rc.subr

-  
The rc.subr file resides in
-      /etc.

-

-

-

-

-
rc.conf(5), rc(8)

-

-

-

-
rc.subr appeared in
-    NetBSD 1.3. The rc.d(8) support
-    functions appeared in NetBSD 1.5. Support for the
-    rc(8) post-processor appeared in NetBSD
-    6.0.

-

-

-
-  
-    
-    
-  
-
December 17, 2012NetBSD 10.1

diff --git a/static/netbsd/man8/rescue.8 4.html b/static/netbsd/man8/rescue.8 4.html
deleted file mode 100644
index f1cfdffc..00000000
--- a/static/netbsd/man8/rescue.8 4.html	
+++ /dev/null
@@ -1,94 +0,0 @@
-
-  
-    
-    
-    
-  
-
RESCUE(8)System Manager's ManualRESCUE(8)

-

-

-

-
rescue — rescue
-    utilities in /rescue

-

-

-

-
The /rescue directory contains a
-    collection of common utilities intended for use in recovering a badly
-    damaged system. With the transition to a dynamically-linked root beginning
-    with NetBSD 2.0, there is a real possibility that
-    the standard tools in /bin and
-    /sbin may become non-functional due to a failed
-    upgrade or a disk error. The tools in /rescue are
-    statically linked and should therefore be more resistant to damage. However,
-    being statically linked, the tools in /rescue are
-    also less functional than the standard utilities. In particular, they do not
-    have full use of the locale, pam(3), and nsswitch
-    libraries.

-
If your system fails to boot, and it shows an error message
-    similar to:

-

-
init: not found

-
try booting the system with the boot flag
-    “-a” and supplying
-    /rescue/init, which is the
-    rescue init(8), as the init
-  path.

-
If your system fails to boot, and it shows a prompt similar
-  to:

-

-
Enter full pathname of shell or
-  RETURN for /bin/sh: 

-
the first thing to try running is the standard shell,
-    /bin/sh. If that fails, try running
-    /rescue/sh, which is the
-    rescue shell. To repair the system, the root
-    partition must first be remounted read-write. This can be done with the
-    following mount(8) command:

-

-
/rescue/mount -uw /

-
The next step is to double-check the contents of
-    /bin, /lib,
-    /libexec, and /sbin,
-    possibly mounting a NetBSD installation CD-ROM and
-    copying files from there. Once it is possible to successfully run
-    /bin/sh, /bin/ls, and other
-    standard utilities, try rebooting back into the standard system.

-
The /rescue tools are compiled using
-    crunchgen(1), which makes them considerably more compact
-    than the standard utilities.

-

-

-

-

-  
/rescue

-  
Root of the rescue hierarchy.

-

-

-

-

-
crunchgen(1)

-

-

-

-
The rescue utilities first appeared in
-    NetBSD 2.0.

-

-

-

-
The rescue system was written by
-    Luke Mewburn
-    <lukem@NetBSD.org>.
-    This manual page was written by Simon L. Nielsen
-    <simon@FreeBSD.org>,
-    based on text by Tim Kientzle
-    <kientzle@FreeBSD.org>.

-

-

-
-  
-    
-    
-  
-
April 5, 2012NetBSD 10.1

diff --git a/static/netbsd/man8/veriexec.8 4.html b/static/netbsd/man8/veriexec.8 4.html
deleted file mode 100644
index e04a0fc5..00000000
--- a/static/netbsd/man8/veriexec.8 4.html	
+++ /dev/null
@@ -1,176 +0,0 @@
-
-  
-    
-    
-    
-  
-
VERIEXEC(8)System Manager's ManualVERIEXEC(8)

-

-

-

-
veriexec — file
-    integrity subsystem

-

-

-

-
Veriexec is an in-kernel, real-time, file-system
-    independent, file integrity subsystem. It can be used for a variety of
-    purposes, including defense against trojaned binaries, indirect attacks via
-    third-party remote file-systems, and malicious configuration file
-    corruption.

-

-

-

-

-

-
Veriexec requires a signatures database -- a
-    list of monitored files, along with their digital fingerprint and
-    (optionally) access modes. The format of this file is described by
-    veriexec(5).

-
NetBSD provides a tool,
-    veriexecgen(8), for generating the signatures database.
-    Example usage:

-

-
# veriexecgen

-

-
Although it should be loaded on system boot (see “RC
-    Configuration” below), this list can be loaded manually using
-    veriexecctl(8):

-

-
# veriexecctl load

-

-

-

-

-
Veriexec requires a kernel with
-    fileassoc(9) support and a pseudo-device to run:

-

-
options FILEASSOC
-pseudo-device veriexec

-

-
Additionally, one or more options for digital fingerprint
-    algorithm support:

-

-
options VERIFIED_EXEC_FP_SHA256
-options VERIFIED_EXEC_FP_SHA384
-options VERIFIED_EXEC_FP_SHA512

-

-
Some kernels already enable Veriexec by default.
-    See your kernel's config file for more information.

-

-

-

-
Veriexec also allows loading signatures and
-    setting the strict level (see below) during the boot process using the
-    following variables set in rc.conf(5):

-

-
veriexec=YES
-veriexec_strict=1 # IDS mode

-

-

-

-

-

-
Veriexec can operate in four modes, also
-    referred to as strict levels:

-

-  
Learning mode (strict level 0)

-  
The only level at which the fingerprint tables can be modified, this level
-      is used to help fine-tune the signature database. No enforcement is made,
-      and verbose information is provided (fingerprint matches and mismatches,
-      file removals, incorrect access, etc.).

-  
IDS mode (strict level 1)

-  
IDS (intrusion detection system) mode provides an adequate level of
-      integrity for the files it monitors. Implications:
-    

-    
    
-      
  • Monitored files cannot be removed
    • 
-      
  • If raw disk access is granted to a disk with monitored files on it,
-          all monitored files' fingerprints will be invalidated
    • 
-      
  • Access to files with mismatched fingerprints is denied
    • 
-      
  • Write access to monitored files is allowed
    • 
-      
  • Access type is not enforced
    • 
-    

-  

-  
IPS mode (strict level 2)

-  
IPS (intrusion prevention system) mode provides a high level of integrity
-      for the files it monitors. Implications:
-    

-    
    
-      
  • All implications of IDS mode
    • 
-      
  • Write access to monitored files is denied
    • 
-      
  • Access type is enforced
    • 
-      
  • Raw disk access to disk devices with monitored files on them is
-        denied
    • 
-      
  • Execution of non-monitored files is denied
    • 
-      
  • Write access to kernel memory via /dev/mem and
-          /dev/kmem is denied
    • 
-    

-  

-  
Lockdown mode (strict level 3)

-  
Lockdown mode provides high assurance integrity for the entire system.
-      Implications:
-    

-    
    
-      
  • All implications of IPS mode
    • 
-      
  • Access to non-monitored files is denied
    • 
-      
  • Write access to files is allowed only if the file was opened before
-          the strict level was raised to this mode
    • 
-      
  • Creation of new files is denied
    • 
-      
  • Raw access to system disks is denied
    • 
-    

-  

-

-

-

-

-
Veriexec exports runtime information that may be
-    useful for various purposes.

-
It reports the currently supported fingerprinting algorithms, for
-    example:

-

-
# /sbin/sysctl kern.veriexec.algorithms
-kern.veriexec.algorithms = SHA256 SHA384 SHA512

-

-
It reports the current verbosity and strict levels, for
-  example:

-

-
# /sbin/sysctl kern.veriexec.{verbose,strict}
-kern.veriexec.verbose = 0
-kern.veriexec.strict = 1

-

-
It reports a summary of currently loaded files and the
-    mount-points they're on, for example:

-

-
# /sbin/sysctl kern.veriexec.count
-kern.veriexec.count.table0.mntpt = /
-kern.veriexec.count.table0.fstype = ffs
-kern.veriexec.count.table0.nentries = 33

-

-
Other information may be retrieved using
-    veriexecctl(8).

-

-

-

-
options(4), veriexec(5),
-    sysctl(7), sysctl(8),
-    veriexecctl(8), veriexecgen(8)

-

-

-

-
Elad Efrat
-    <elad@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
September 13, 2017NetBSD 10.1

diff --git a/static/netbsd/man8/wizd.8 4.html b/static/netbsd/man8/wizd.8 4.html
deleted file mode 100644
index 2f5e3c05..00000000
--- a/static/netbsd/man8/wizd.8 4.html	
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    
-    
-    
-  
-
WIZD(8)System Manager's ManualWIZD(8)

-

-

-

-
wizd —
-    automatically correct typographical errors in man
-    pages

-

-

-

-
-  
-    
-    
-  
-
wizd

-

-

-

-
wizd automatically checks and corrects
-    spelling errors, usage problems with mdoc(7) macros, and
-    other typographical errors in man pages.

-
wizd is invoked by any
-    cvs(1) commit to a man page.

-
wizd also performs periodic sanity checks
-    on the distribution set lists. E-mail alerts will be triggered if the build
-    installs files that are marked as obsolete and therefore get automatically
-    removed.

-

-

-

-
wizd responds to the following
-  signals:

-

-  
<wiz@NetBSD.org>

-  
Examine a man page for errors. The man page and particular errors in
-      question may be specified in standard internet mail format.

-

-
wizd additionally sometimes delivers the
-    following signals to other committer processes:

-

-  

-  
An error was detected in a man page.

-

-

-

-

-
cvs(1), intro(1),
-    man(1), mdoc(7)

-

-

-

-
wizd appeared in NetBSD
-    1.5.

-

-

-

-
wizd is not only copyrighted, but also
-    registered.

-

-

-

-
Sleeps sometimes. Leaves laptop at home sometimes.

-

-

-
-  
-    
-    
-  
-
March 30, 2015NetBSD 10.1

diff --git a/static/netbsd/man9/KERNEL_LOCK.9 3.html b/static/netbsd/man9/KERNEL_LOCK.9 3.html
deleted file mode 100644
index bdc4092c..00000000
--- a/static/netbsd/man9/KERNEL_LOCK.9 3.html	
+++ /dev/null
@@ -1,228 +0,0 @@
-
-  
-    
-    
-    
-  
-
KERNEL_LOCK(9)Kernel Developer's ManualKERNEL_LOCK(9)

-

-

-

-
KERNEL_LOCK —
-    compatibility with legacy uniprocessor code

-

-

-

-
#include
-    <sys/systm.h>

-
void
-  

-  KERNEL_LOCK(int
-    nlocks, struct lwp
-    *l);

-
void
-  

-  KERNEL_UNLOCK_ONE(struct
-    lwp *l);

-
void
-  

-  KERNEL_UNLOCK_ALL(struct
-    lwp *l, int
-    *nlocksp);

-
void
-  

-  KERNEL_UNLOCK_LAST(struct
-    lwp *l);

-
bool
-  

-  KERNEL_LOCKED_P();

-

-

-

-
The KERNEL_LOCK facility serves to
-    gradually transition software from the kernel's legacy uniprocessor
-    execution model, where the kernel runs on only a single CPU and never in
-    parallel on multiple CPUs, to a multiprocessor system.

-
 KERNEL_LOCK.
-    KERNEL_LOCK is meant only for gradual transition of
-    NetBSD to natively MP-safe code, which uses
-    mutex(9) or other locking(9) facilities
-    to synchronize between threads and interrupt handlers. Use of
-    KERNEL_LOCK hurts system performance and
-    responsiveness. This man page exists only to document the legacy API in
-    order to make it easier to transition away from.

-
The kernel lock, sometimes also known as ‘giant
-    lock’ or ‘big lock’, is a recursive exclusive spin-lock
-    that can be held by a CPU at any interrupt priority level and is dropped
-    while sleeping. This means:

-

-  
recursive

-  
If a CPU already holds the kernel lock, it can be acquired again and
-      again, as long as it is released an equal number of times.

-  
exclusive

-  
Only one CPU at a time can hold the kernel lock.

-  
spin-lock

-  
When one CPU holds the kernel lock and another CPU wants to hold it, the
-      second CPU ‘spins’, i.e., repeatedly executes instructions
-      to see if the kernel lock is available yet, until the first CPU releases
-      it. During this time, no other threads can run on the spinning CPU.
-    
This means holding the kernel lock for long periods of time,
-        such as nontrivial computation, must be avoided. Under
-        LOCKDEBUG kernels, holding the kernel lock for
-        too long can lead to ‘spinout’ crashes.

-  

-  
held by a CPU

-  
The kernel lock is held by a CPU, not by a process, kthread, LWP, or
-      interrupt handler. It may be shared by a kthread LWP and several softint
-      LWPs at the same time, for example, if the softints interrupted the thread
-      on a CPU.

-  
any interrupt priority level

-  
The kernel lock does not block interrupts; subsystems
-      running with the kernel lock use spl(9) to synchronize
-      with interrupt handlers.
-    
Interrupt handlers that are not marked MP-safe are always run
-        with the kernel lock. If the interrupt arrives on a CPU where the kernel
-        lock is already held, it is simply taken again recursively on interrupt
-        entry and released to its original recursion depth on interrupt
-      exit.

-  

-  
dropped while sleeping

-  
Any time the kernel sleeps to let other threads run, for any reason
-      including tsleep(9) or condvar(9) or
-      even adaptive mutex(9) locks, it releases the kernel
-      lock before going to sleep and then reacquires it afterward.
-    
This means, for instance, that although data structures
-        accessed only under the kernel lock won't be changed before the sleep,
-        they may be changed by another thread during the sleep. For example, the
-        following program may crash on an assertion failure because the sleep in
-        mutex_enter(9) can allow another CPU to run and change
-        the global variable x:

-    

-    
	KERNEL_LOCK(1, NULL);
-	x = 42;
-	mutex_enter(...);
-	...
-	mutex_exit(...);
-	KASSERT(x == 42);
-	KERNEL_UNLOCK_ONE(NULL);

-    

-    
This means simply introducing calls to
-        mutex_enter(9) and mutex_exit(9) can
-        break kernel-locked assumptions. Subsystems need to be consistently
-        converted from KERNEL_LOCK and
-        spl(9) to mutex(9),
-        condvar(9), etc.; mixing mutex(9)
-        and KERNEL_LOCK usually doesn't work.

-  

-

-
Holding the kernel lock does
-    not prevent other code from running on other CPUs at the same time. It
-    only prevents other
-    
-    code from running on other CPUs at the same time.

-

-

-

-

-  
(nlocks,
-    l)

-  
Acquire nlocks recursive levels of kernel lock.
-    
If the kernel lock is already held by another CPU, spins until
-        it can be acquired by this one. If the kernel lock is already held by
-        this CPU, records the kernel lock recursion depth and returns
-        immediately.

-    
Most of the time
-        nlocks is 1, but code that deliberately releases
-        all of the kernel locks held by the current CPU in order to sleep and
-        later reacquire the same number of kernel locks will pass a value of
-        nlocks obtained from
-        ().

-  

-  
(l)

-  
Release one level of the kernel lock. Equivalent to
-      (1,
-      l, NULL);.

-  
KERNEL_UNLOCK_ALL(l,
-    nlocksp)

-  
Store the kernel lock recursion depth at nlocksp and
-      release all recursive levels of the kernel lock.
-    
This is often used inside logic implementing sleep, around a
-        call to mi_switch(9), so that the same number of
-        recursive kernel locks can be reacquired afterward once the thread is
-        reawoken:

-    

-    
	int nlocks;
-
-	KERNEL_UNLOCK_ALL(l, &nlocks);
-	... mi_switch(l) ...
-	KERNEL_LOCK(nlocks, l);

-    

-  

-  
(l)

-  
Release the kernel lock, which must be held at exactly one level.
-    
This is normally used at the end of a non-MP-safe thread,
-        which was known to have started with exactly one level of the kernel
-        lock, and is now about to exit.

-  

-  
()

-  
True if the kernel lock is held.
-    
To be used only in diagnostic assertions with
-        KASSERT(9).

-  

-

-
The legacy argument l must be
-    NULL or curlwp, which mean
-    the same thing.

-

-

-

-
Some NetBSD kernel abstractions execute
-    caller-specified functions with the kernel lock held by default, for
-    compatibility with legacy code, but can be explicitly instructed
-     to hold
-    the kernel lock by passing an MP-safe flag:

-
-
The following NetBSD subsystems are still
-    kernel-locked and need re-engineering to take advantage of parallelism on
-    multiprocessor systems:

-
-
All interrupt handlers at IPL_VM, or lower
-    (spl(9)) run with the kernel lock on most ports.

-

-

-

-
locking(9), mutex(9),
-    spl(9)

-

-

-
-  
-    
-    
-  
-
February 13, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/accept_filter.9 3.html b/static/netbsd/man9/accept_filter.9 3.html
deleted file mode 100644
index d9cd0808..00000000
--- a/static/netbsd/man9/accept_filter.9 3.html	
+++ /dev/null
@@ -1,140 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCEPT_FILTER(9)Kernel Developer's ManualACCEPT_FILTER(9)

-

-

-

-
accept_filter,
-    accept_filt_add,
-    accept_filt_del,
-    accept_filt_generic_mod_event,
-    accept_filt_get — filter
-    incoming connections

-

-

-

-
#define ACCEPT_FILTER_MOD

-
#include
-    <sys/param.h>
-  

-  #include <sys/kernel.h>
-  

-  #include <sys/sysctl.h>
-  

-  #include <sys/signalvar.h>
-  

-  #include <sys/socketvar.h>
-  

-  #include
-    <netinet/accept_filter.h>

-
int
-  

-  accept_filt_add(struct
-    accept_filter *filt);

-
int
-  

-  accept_filt_del(char
-    *name);

-
int
-  

-  accept_filt_generic_mod_event(module_t
-    mod, int event,
-    void *data);

-
struct accept_filter *
-  

-  accept_filt_get(char
-    *name);

-

-

-

-
Accept filters allow an application to request that the kernel
-    pre-process incoming connections. This manual page describes the kernel
-    interface for accept filters. User applications request accept filters via
-    the setsockopt(2) system call, passing in an
-    optname of
-  SO_ACCEPTFILTER.

-

-

-

-
A module that wants to be an accept filter must provide a
-    struct accept_filter to the system:

-

-
struct accept_filter {
-	char	accf_name[16];
-	void	(*accf_callback)(struct socket *so, void *arg, int waitflag);
-	void *	(*accf_create)(struct socket *so, char *arg);
-	void	(*accf_destroy)(struct socket *so);
-	SLIST_ENTRY(accept_filter) accf_next;	/* next on the list */
-};

-

-
The module should register it with the function
-    accept_filt_add(), passing a pointer to a
-    struct accept_filter, allocated with
-    malloc(9).

-
The accept filters currently provided with
-    NetBSD (accf_data(9) and
-    accf_http(9)) are implemented as pseudo-devices, but an
-    accept filter may use any supported means of initializing and registering
-    itself at system startup or later, including the module framework if
-    supported by the running kernel.

-
The fields of struct accept_filter are as
-    follows:

-

-  
accf_name

-  
Name of the filter; this is how it will be accessed from userland.

-  
accf_callback

-  
The callback that the kernel will do once the connection is established.
-      It is the same as a socket upcall and will be called when the connection
-      is established and whenever new data arrives on the socket, unless the
-      callback modifies the socket's flags.

-  
accf_create

-  
Called whenever a setsockopt(2) installs the filter onto
-      a listening socket.

-  
accf_destroy

-  
Called whenever the user removes the accept filter on the socket.

-

-
The accept_filt_del() function passed the
-    same string used in accept_filter.accf_name during
-    registration with accept_filt_add(), the kernel will
-    then disallow and further userland use of the filter.

-
The accept_filt_get() function is used
-    internally to locate which accept filter to use via the
-    setsockopt(2) system call.

-
The accept_filt_generic_mod_event()
-    function can be used by accept filters which are loadable kernel modules to
-    add and delete themselves.

-

-

-

-
setsockopt(2), accf_data(9),
-    accf_http(9), malloc(9)

-

-

-

-
The accept filter mechanism was introduced in
-    FreeBSD 4.0. It was ported to
-    NetBSD by Coyote Point Systems, Inc. and appeared in
-    NetBSD 5.0.

-

-

-

-
This manual page was written by Alfred
-    Perlstein, Sheldon Hearn, and
-    Jeroen Ruigrok van der Werven.

-
The accept filter concept was pioneered by David
-    Filo at Yahoo! and refined to be a loadable module system by
-    Alfred Perlstein.

-

-

-
-  
-    
-    
-  
-
November 12, 2008NetBSD 10.1

diff --git a/static/netbsd/man9/accf_data.9 3.html b/static/netbsd/man9/accf_data.9 3.html
deleted file mode 100644
index e8bdda78..00000000
--- a/static/netbsd/man9/accf_data.9 3.html	
+++ /dev/null
@@ -1,68 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCF_DATA(9)Kernel Developer's ManualACCF_DATA(9)

-

-

-

-
accf_data — buffer
-    incoming connections until data arrives

-

-

-

-
options INET
-  

-  pseudo-device accf_data

-

-

-

-
This is a filter to be placed on a socket that will be using
-    ()
-    to receive incoming connections.

-
It prevents the application from receiving the
-    connected descriptor via
-    ()
-    until data arrives on the connection.

-

-

-

-
If the accf_data accept filter is present
-    in the kernel configuration, this will enable the data accept filter on the
-    socket sok.

-

-
	struct accept_filter_arg afa;
-
-	bzero(&afa, sizeof(afa));
-	strcpy(afa.af_name, "dataready");
-	setsockopt(sok, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa));

-

-

-

-

-
setsockopt(2),
-    accept_filter(9), accf_http(9)

-

-

-

-
The accept filter mechanism and the
-    accf_data filter were introduced in
-    FreeBSD 4.0. They were ported to
-    NetBSD by Coyote Point Systems and appeared in
-    NetBSD 5.0.

-

-

-

-
This manual page and the filter were written by
-    Alfred Perlstein.

-

-

-
-  
-    
-    
-  
-
August 10, 2008NetBSD 10.1

diff --git a/static/netbsd/man9/acct_process.9 3.html b/static/netbsd/man9/acct_process.9 3.html
deleted file mode 100644
index 1b058cfc..00000000
--- a/static/netbsd/man9/acct_process.9 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
ACCT_PROCESS(9)Kernel Developer's ManualACCT_PROCESS(9)

-

-

-

-
acct_process —
-    populate and write the process accounting record

-

-

-

-
#include
-    <sys/acct.h>

-
int
-  

-  acct_process(struct
-    lwp *l);

-

-

-

-
The acct_process function is called when
-    the process exits. If accounting is turned off, it returns immediately. If
-    accounting is turned on via acct(2), then the
-    acct_process populates the accounting structure
-    described in acct(5), then writes the accounting record to
-    the file specified by acct(2).

-

-

-

-
acct_process returns 0 on success and the
-    same error codes as vn_rdwr(9) on failure.

-

-

-

-
acct(2), acct(5),
-    vn_rdwr(9).

-

-

-
-  
-    
-    
-  
-
August 5, 2024NetBSD 10.1

diff --git a/static/netbsd/man9/autoconf.9 3.html b/static/netbsd/man9/autoconf.9 3.html
deleted file mode 100644
index 35df3b00..00000000
--- a/static/netbsd/man9/autoconf.9 3.html	
+++ /dev/null
@@ -1,385 +0,0 @@
-
-  
-    
-    
-    
-  
-
AUTOCONF(9)Kernel Developer's ManualAUTOCONF(9)

-

-

-

-
autoconf,
-    config_search, config_found,
-    config_match, config_attach,
-    config_attach_pseudo,
-    config_detach,
-    config_detach_children,
-    config_deactivate,
-    config_defer,
-    config_interrupts,
-    config_mountroot,
-    config_pending_incr,
-    config_pending_decr,
-    config_finalize_register —
-    autoconfiguration framework

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/device.h>
-  

-  #include <sys/errno.h>

-
cfdata_t
-  

-  config_search(device_t
-    parent, void *aux,
-    const struct cfargs
-  *);

-
device_t
-  

-  config_found(device_t
-    parent, void *aux,
-    cfprint_t print,
-    const struct cfargs
-  *);

-
int
-  

-  config_match(device_t
-    parent, cfdata_t
-    cf, void *aux);

-
int
-  

-  config_probe(device_t
-    parent, cfdata_t
-    cf, void *aux);

-
device_t
-  

-  config_attach(device_t
-    parent, cfdata_t
-    cf, void *aux,
-    cfprint_t print,
-    const struct cfargs
-  *);

-
device_t
-  

-  config_attach_pseudo(cfdata_t
-    cf);

-
int
-  

-  config_detach(device_t
-    dev, int
-  flags);

-
int
-  

-  config_detach_children(device_t
-    dev, int
-  flags);

-
int
-  

-  config_deactivate(device_t
-    dev);

-
int
-  

-  config_defer(device_t
-    dev, void
-    (*func)(device_t));

-
void
-  

-  config_interrupts(device_t
-    dev, void
-    (*func)(device_t));

-
void
-  

-  config_mountroot(device_t
-    dev, void
-    (*func)(device_t));

-
void
-  

-  config_pending_incr();

-
void
-  

-  config_pending_decr();

-
int
-  

-  config_finalize_register(device_t
-    dev, int
-    (*func)(device_t));

-

-

-

-
Autoconfiguration is the process of matching hardware devices with
-    an appropriate device driver. In its most basic form, autoconfiguration
-    consists of the recursive process of finding and attaching all devices on a
-    bus, including other busses.

-
The autoconfiguration framework supports direct
-    configuration where the bus driver can determine the devices present.
-    The autoconfiguration framework also supports indirect
-    configuration where the drivers must probe the bus looking for the
-    presence of a device. Direct configuration is preferred since it can find
-    hardware regardless of the presence of proper drivers.

-
The autoconfiguration process occurs at system bootstrap and is
-    driven by a table generated from a “machine description” file
-    by config(1). For a description of the
-    config(1) “device definition” language, see
-    config(9).

-
Each device must have a name consisting of an alphanumeric string
-    that ends with a unit number. The unit number identifies an instance of the
-    driver. Device data structures are allocated dynamically during
-    autoconfiguration, giving a unique address for each instance.

-
Several of the autoconfiguration functions take a
-    strongly-typed variadic list of arguments to pass information from driver
-    autoconfiguration functions to the kernel's autoconfiguration system. This
-    list is constructed using the
-    ()
-    macro, like this example:

-

-
config_search(self, NULL,
-    CFARGS(.search = mainbus_search,
-           .iattr = "mainbus"));

-

-
Each tag is followed by a tag-specific value.

-

-

-  
submatch

-  
A pointer to a ‘submatch’ function used in
-      direct configuration.

-  
search

-  
A pointer to a ‘search’ function used in
-      indirect configuration.

-  
iattr

-  
A pointer to a constant C string (const char *)
-      specifying an interface attribute. If a parent device carries only a
-      single interface attribute, then this argument may be omitted. If an
-      interface attribute is specified that the parent device does not carry, or
-      no interface attribute is specified and the parent device carries more
-      than one, behavior is undefined. On kernels built with the
-      DIAGNOSTIC option, this may result in an assertion
-      panic.

-  
locators

-  
A pointer to a constant array of integers (const int
-      *) containing interface attribute-specific locators.

-  
devhandle

-  
A devhandle_t (passed by value) corresponding to the
-      device being attached.

-

-

-
If no arguments are to be passed, the special value
-    CFARGS_NONE may be used in place of the
-    ()
-    macro.

-

-

-

-

-  
config_search(parent,
-    aux, cfargs)

-  
Cfargs consumed: search,
-      iattr, locators.
-    
-    
The role of the search function is to call
-        ()
-        for each potential child and call
-        config_attach() for any positive matches. If no
-        search function is specified, then the parent should record the return
-        value from config_search() and call
-        config_attach() itself.

-    
Note that this function is designed so that it can be used to
-        apply an arbitrary function to all potential children. In this case
-        callers may choose to ignore the return value.

-  

-  
(parent,
-    aux, print,
-    cfargs)

-  
Cfargs consumed: submatch,
-      iattr, locators,
-      devhandle.
-    
Performs direct configuration on a
-        physical device.
-        ()
-        is called by the parent and in turn calls the specified submatch
-        function as determined by the configuration table. The submatch function
-        compares user-specified locators from the machine description file
-        against those specifying a found device, calling
-        ()
-        if they match (including wildcard matching). If a submatch function is
-        not specified, then driver match functions are called directly. The
-        argument parent is the pointer to the parent's
-        device structure. If an interface attribute is specified, only potential
-        children eligible to attach to that interface attribute will be
-        consulted. If specified, the locators argument lists the locator values
-        for the found device and may be used by the submatch function and will
-        be recorded in the device structure of the child device. The given
-        aux argument describes the device that has been
-        found. config_found() internally uses
-        config_search(). The softc
-        structure for the matched device will be allocated, and the appropriate
-        driver attach function will be called. If the device is matched, the
-        system prints the name of the child and parent devices, and then calls
-        the print function to produce additional
-        information if desired. If no driver takes a match, the same
-        print function is called to complain. The print
-        function is called with the aux argument and, if
-        the matches failed, the full name (including unit number) of the parent
-        device, otherwise NULL. The
-        print function must return an integer value.

-    
Two special strings, “not configured” and
-        “unsupported” will be appended automatically to non-driver
-        reports if the return value is UNCONF or
-        UNSUPP respectively; otherwise the function
-        should return the value QUIET. If a device
-        handle is specified, that handle will be associated with the resulting
-        child device structure if a driver matches.

-    
()
-        returns a pointer to the attached device's device
-        structure if the device is attached, NULL
-        otherwise. Most callers can ignore this value, since the system will
-        already have printed a diagnostic.

-  

-  
(parent,
-    cf, aux)

-  
Match a device (direct configuration). Invokes the driver's match function
-      according to the configuration table. The
-      config_match() function returns a nonzero integer
-      indicating the confidence of supporting this device and a value of 0 if
-      the driver doesn't support the device.

-  
config_probe(parent,
-    cf, aux)

-  
Probe for a device (indirect configuration). Invokes the driver's match
-      function according to the configuration table. The
-      config_probe() function returns a nonzero integer
-      to indicate a successful probe and a value of 0 otherwise. Unlike
-      config_match(), the return value of
-      config_probe() is not intended to reflect a
-      confidence value.

-  
config_attach(parent,
-    cf, aux,
-    print, cfargs)

-  
Cfargs consumed: locators,
-      devhandle.
-    
Attach a found device. Allocates the memory
-        for the softc structure and calls the drivers
-        attach function according to the configuration table. If successful,
-        ()
-        returns a pointer to the device structure. If
-        unsuccessful, it returns NULL.

-  

-  
config_attach_pseudo(cf)

-  
Create an instance of a pseudo-device driver. config(5)
-      syntax allows the creation of pseudo-devices from which regular
-      device_t instances can be created. Such objects are
-      similar to the devices that attach at the root of the device tree.
-    
The caller is expected to allocate
-        and fill the cfdata_t object and pass it to
-        ().
-        The content of that object is similar to what is returned by
-        config_search() for regular devices.

-  

-  
(dev,
-    flags)

-  
Called by the parent to detach the child device. The second argument
-      flags contains detachment flags. Valid values are
-      DETACH_FORCE (force detachment, e.g., because of
-      hardware removal) and DETACH_QUIET (do not print a
-      notice). config_detach() returns zero if
-      successful and an error code otherwise.
-      config_detach() is always called from a thread
-      context, allowing condition variables to be used while the device detaches
-      itself.

-  
(dev,
-    flags)

-  
Iterate through all attached devices, calling
-      config_detach() for each child of
-      dev, passing flags. If
-      detaching any child results in an error, the iteration will halt and any
-      remaining devices will not be detached.
-      config_detach_children() returns zero if
-      successful and an error code otherwise.

-  
(dev)

-  
Called by the parent to deactivate the child device
-      dev. config_deactivate() is
-      called from interrupt context to immediately relinquish resources and
-      notify dependent kernel subsystems that the device is about to be
-      detached. At some later point config_detach() will
-      be called to finalise the removal of the device.

-  
(dev,
-    func)

-  
Called by the child to defer the remainder of its configuration until all
-      its parent's devices have been attached. At this point, the function
-      func is called with the argument
-      dev.

-  
(dev,
-    func)

-  
Called by the child to defer the remainder of its configuration until
-      interrupts are enabled. At this point, the function
-      func is called with the argument
-      dev.

-  
(dev,
-    func)

-  
Called by the child to defer the remainder of its configuration until the
-      root file system is mounted. At this point, the function
-      func is called with the argument
-      dev. This is used for devices that need to load
-      firmware image from a mounted file system.

-  
()

-  
Increment the config_pending semaphore. It is used
-      to account for deferred configurations before mounting the root file
-      system.

-  
()

-  
Decrement the config_pending semaphore. It is used
-      to account for deferred configurations before mounting the root file
-      system.

-  
(dev,
-    func)

-  
Register a function to be called after all real devices have been found.
-    
Registered functions are all executed until all of them return
-        0. The callbacks should return 0 to indicate they do not require to be
-        called another time, but they should be aware that they still might be
-        in case one of them returns 1.

-  

-

-

-

-

-
The autoconfiguration framework itself is implemented within the
-    file sys/kern/subr_autoconf.c. Data structures and
-    function prototypes for the framework are located in
-    sys/sys/device.h.

-

-

-

-
config(1), config(5),
-    condvar(9), config(9),
-    driver(9)

-

-

-

-
Autoconfiguration first appeared in
-    4.1BSD. The autoconfiguration framework was
-    completely revised in 4.4BSD. The detach and
-    deactivate interfaces appeared in NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
August 7, 2021NetBSD 10.1

diff --git a/static/netbsd/man9/bcdtobin.9 3.html b/static/netbsd/man9/bcdtobin.9 3.html
deleted file mode 100644
index cdb38943..00000000
--- a/static/netbsd/man9/bcdtobin.9 3.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
BCDTOBIN(9)Kernel Developer's ManualBCDTOBIN(9)

-

-

-

-
bcdtobin, bintobcd
-    — convert a single byte between (unsigned) packed
-    bcd and binary

-

-

-

-
#include
-    <sys/systm.h>

-
unsigned int
-  

-  bcdtobin(unsigned
-    int bcd);

-
unsigned int
-  

-  bintobcd(unsigned
-    int bin);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions convert a single byte between (unsigned) packed bcd and binary
-    encodings.

-

-

-

-
The bcdtobin() function returns the binary
-    value of its BCD-encoded argument, bcd. The
-    bintobcd() function returns the BCD encoding of its
-    binary argument, bin.

-

-

-
-  
-    
-    
-  
-
March 11, 2006NetBSD 10.1

diff --git a/static/netbsd/man9/bcopy.9 3.html b/static/netbsd/man9/bcopy.9 3.html
deleted file mode 100644
index 2888fc62..00000000
--- a/static/netbsd/man9/bcopy.9 3.html	
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    
-    
-    
-  
-
BCOPY(9)Kernel Developer's ManualBCOPY(9)

-

-

-

-
bcopy — copy byte
-    string

-

-

-

-
#include
-    <sys/systm.h>

-
void
-  

-  bcopy(const
-    void *src, void
-    *dst, size_t
-  len);

-

-

-

-
The
-  ()
-  interface is obsolete. Do not add new code using it. It will soon be purged.
-  Use memcpy(9) instead. (The bcopy()
-  function is now a macro for memcpy(9).)

-
The
-    ()
-    function copies len bytes from string
-    src to string dst.

-

-
Unlike bcopy(3) the two strings must not
-  overlap!

-In the traditional BSD kernel, overlapping copies were
-  handled by the now-purged
-  ()
-  function. If you need to copy overlapping data, see
-  memmove(9).
-
If len is zero, no bytes are copied.

-

-

-

-
bcopy(3), memcpy(9),
-    memmove(9)

-

-

-
-  
-    
-    
-  
-
July 7, 2001NetBSD 10.1

diff --git a/static/netbsd/man9/bufq.9 3.html b/static/netbsd/man9/bufq.9 3.html
deleted file mode 100644
index c02fc983..00000000
--- a/static/netbsd/man9/bufq.9 3.html	
+++ /dev/null
@@ -1,211 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUFQ(9)Kernel Developer's ManualBUFQ(9)

-

-

-

-
bufq, bufq_init,
-    bufq_register,
-    bufq_unregister, bufq_state,
-    bufq_alloc, bufq_drain,
-    bufq_free,
-    bufq_getstrategyname,
-    bufq_move, bufq_put,
-    bufq_get, bufq_peek,
-    bufq_cancel — device buffer
-    queues

-

-

-

-
#include
-    <sys/bufq.h>

-
void
-  

-  bufq_init(void);

-
int
-  

-  bufq_register(struct
-    bufq_strat *);

-
int
-  

-  bufq_unregister(struct
-    bufq_strat *);

-
int
-  

-  bufq_alloc(struct
-    bufq_state **bufq, const
-    char *strategy, int
-    flags);

-
void
-  

-  bufq_drain(struct
-    bufq_state *bufq);

-
void
-  

-  bufq_free(struct
-    bufq_state *bufq);

-
const char *
-  

-  bufq_getstrategyname(struct
-    bufq_state *bufq);

-
void
-  

-  bufq_move(struct
-    bufq_state *dst, struct
-    bufq_state *src);

-
void
-  

-  bufq_put(struct
-    bufq_state *bufq, struct
-    buf *bp);

-
struct buf *
-  

-  bufq_get(struct
-    bufq_state *bufq);

-
struct buf *
-  

-  bufq_peek(struct
-    bufq_state *bufq);

-
struct buf *
-  

-  bufq_cancel(struct
-    bufq_state *bufq, struct
-    buf *bp);

-

-

-

-
The bufq subsystem is a set of operations
-    for the management of device buffer queues. Various strategies for ordering
-    of entries in the buffer queues can be provided by loadable kernel modules
-    (see module(9)). By default, the
-    BUFQ_FCFS and BUFQ_DISKSORT
-    strategies are included in the kernel; see options(4) for
-    more details.

-
The primary data type for using the operations is
-    the bufq_state structure, which is opaque for users. Each
-    buffer queue strategy module is defined by the
-    
-    structure, which is also opaque for users.

-

-

-

-

-  
(void)

-  
Initialize the bufq subsystem. This routine must
-      be called before any other bufq routines.

-  
(bs)

-  
Registers the specified buffer queue strategy module so it can be used in
-      subsequent operations.

-  
(bs)

-  
Unregisters the specified buffer queue strategy module. The routine will
-      fail if any buffer queues for the specified strategy are in use (see
-      bufq_alloc() below).

-  
bufq_alloc(bufq,
-    strategy, flags)

-  
Allocate and initialize a bufq_state descriptor.
-    
The argument strategy specifies a buffer
-        queue strategy to be used for this buffer queue. The following special
-        values can be used:

-    

-    

-    

-      

-      
Let
-          ()
-          select a strategy.

-      

-      
Let bufq_alloc() select a strategy, assuming
-          it will be used for a normal disk device.

-    

-    

-    
Valid bits for the flags are:

-    

-    

-    

-      

-      
sort by b_rawblkno

-      

-      
sort by
-          
-          and then by b_rawblkno

-      

-      
Fail if a strategy specified by strategy is not
-          available. In that case, bufq_alloc returns
-          ENOENT. If this flag is not specified,
-          ()
-          will silently use one of available strategies.

-    

-    

-    
If a specific strategy is specified but not currently
-        available, the bufq subsystem will attempt to
-        auto-load the corresponding kernel module using
-        module_autoload(9).

-  

-  
(bufq)

-  
Drain a bufq_state descriptor.

-  
(bufq)

-  
Destroy a bufq_state descriptor.

-  
(bufq)

-  
Get a strategy identifier of a buffer queue, the string returned will be
-      NUL-terminated and it always will be a valid strategy name.

-  
(dst,
-    src)

-  
Move all requests from the buffer queue src to the
-      buffer queue dst.

-  
(bufq,
-    bp)

-  
Put the buf bp in the queue.

-  
(bufq)

-  
Get the next buf from the queue and remove it from the queue. Returns
-      NULL if the queue is empty.

-  
(bufq)

-  
Get the next buf from the queue without removal. The next buf will remain
-      the same until bufq_get(),
-      bufq_put(), or
-      bufq_drain() is called. Returns
-      NULL if the queue is empty.

-  
(bufq,
-    bp)

-  
Cancel the buf bp issued earlier on the queue.
-      Returns NULL if the element can not be found on
-      the queue or bp if it has been found and removed.
-      This operation can be computationally expensive if there are a lot of
-      buffers queued.

-

-

-

-

-
The actual code implementing the device buffer queues can be found
-    in the file sys/kern/subr_bufq.c. The code
-    implementing specific buffer queue strategies can be found in the files
-    sys/kern/bufq_*.c.

-

-

-

-
A list of currently available buffer queue strategies is available
-    via the “kern.bufq.strategies” sysctl(7)
-    variables.

-

-

-

-
The bufq subsystem appeared in
-    NetBSD 2.0.

-

-

-

-
The bufq subsystem was written by
-    Jürgen Hannken-Illjes
-    ⟨hannken@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
November 17, 2016NetBSD 10.1

diff --git a/static/netbsd/man9/bus_space.9 3.html b/static/netbsd/man9/bus_space.9 3.html
deleted file mode 100644
index 71ce652b..00000000
--- a/static/netbsd/man9/bus_space.9 3.html	
+++ /dev/null
@@ -1,2110 +0,0 @@
-
-  
-    
-    
-    
-  
-
BUS_SPACE(9)Kernel Developer's ManualBUS_SPACE(9)

-

-

-

-
bus_space,
-    bus_space_barrier,
-    bus_space_copy_region_1,
-    bus_space_copy_region_2,
-    bus_space_copy_region_4,
-    bus_space_copy_region_8,
-    bus_space_free,
-    bus_space_handle_is_equal,
-    bus_space_is_equal,
-    bus_space_map,
-    bus_space_mmap,
-    bus_space_peek_1,
-    bus_space_peek_2,
-    bus_space_peek_4,
-    bus_space_peek_8,
-    bus_space_poke_1,
-    bus_space_poke_2,
-    bus_space_poke_4,
-    bus_space_poke_8,
-    bus_space_read_1,
-    bus_space_read_2,
-    bus_space_read_4,
-    bus_space_read_8,
-    bus_space_read_multi_1,
-    bus_space_read_multi_2,
-    bus_space_read_multi_4,
-    bus_space_read_multi_8,
-    bus_space_read_multi_stream_1,
-    bus_space_read_multi_stream_2,
-    bus_space_read_multi_stream_4,
-    bus_space_read_multi_stream_8,
-    bus_space_read_region_1,
-    bus_space_read_region_2,
-    bus_space_read_region_4,
-    bus_space_read_region_8,
-    bus_space_read_region_stream_1,
-    bus_space_read_region_stream_2,
-    bus_space_read_region_stream_4,
-    bus_space_read_region_stream_8,
-    bus_space_read_stream_1,
-    bus_space_read_stream_2,
-    bus_space_read_stream_4,
-    bus_space_read_stream_8,
-    bus_space_release,
-    bus_space_reservation_addr,
-    bus_space_reservation_init,
-    bus_space_reservation_size,
-    bus_space_reservation_map,
-    bus_space_reservation_unmap,
-    bus_space_reserve,
-    bus_space_reserve_subregion,
-    bus_space_set_region_1,
-    bus_space_set_region_2,
-    bus_space_set_region_4,
-    bus_space_set_region_8,
-    bus_space_subregion,
-    bus_space_tag_create,
-    bus_space_tag_destroy,
-    bus_space_unmap,
-    bus_space_vaddr,
-    bus_space_write_1,
-    bus_space_write_2,
-    bus_space_write_4,
-    bus_space_write_8,
-    bus_space_write_multi_1,
-    bus_space_write_multi_2,
-    bus_space_write_multi_4,
-    bus_space_write_multi_8,
-    bus_space_write_multi_stream_1,
-    bus_space_write_multi_stream_2,
-    bus_space_write_multi_stream_4,
-    bus_space_write_multi_stream_8,
-    bus_space_write_region_1,
-    bus_space_write_region_2,
-    bus_space_write_region_4,
-    bus_space_write_region_8,
-    bus_space_write_region_stream_1,
-    bus_space_write_region_stream_2,
-    bus_space_write_region_stream_4,
-    bus_space_write_region_stream_8,
-    bus_space_write_stream_1,
-    bus_space_write_stream_2,
-    bus_space_write_stream_4,
-    bus_space_write_stream_8 —
-    bus space manipulation functions

-

-

-

-
#include
-    <sys/bus.h>

-
bool
-  

-  bus_space_handle_is_equal(bus_space_tag_t
-    space, bus_space_handle_t
-    handle1,
-    bus_space_handle_t
-    handle2);

-
bool
-  

-  bus_space_is_equal(bus_space_tag_t
-    space1, bus_space_tag_t
-    space2);

-
void
-  

-  bus_space_release(bus_space_tag_t
-    t,
-    bus_space_reservation_t
-    *bsr);

-
int
-  

-  bus_space_reserve(bus_space_tag_t
-    t, bus_addr_t bpa,
-    bus_size_t size,
-    int flags,
-    bus_space_reservation_t
-    *bsrp);

-
int
-  

-  bus_space_reserve_subregion(bus_space_tag_t
-    t, bus_addr_t
-    reg_start, bus_addr_t
-    reg_end, bus_size_t
-    size, bus_size_t
-    alignment, bus_size_t
-    boundary, int
-    flags,
-    bus_space_reservation_t
-    *bsrp);

-
void
-  

-  bus_space_reservation_init(bus_space_reservation_t
-    *bsr, bus_addr_t
-    addr, bus_size_t
-    size);

-
bus_size_t
-  

-  bus_space_reservation_size(bus_space_reservation_t
-    *bsr);

-
int
-  

-  bus_space_reservation_map(bus_space_tag_t
-    t,
-    bus_space_reservation_t
-    *bsr, int flags,
-    bus_space_handle_t
-    *bshp);

-
void
-  

-  bus_space_reservation_unmap(bus_space_tag_t
-    t, bus_space_handle_t
-    bsh, bus_size_t
-    size);

-
int
-  

-  bus_space_map(bus_space_tag_t
-    space, bus_addr_t
-    address, bus_size_t
-    size, int flags,
-    bus_space_handle_t
-    *handlep);

-
void
-  

-  bus_space_unmap(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    size);

-
int
-  

-  bus_space_subregion(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, bus_size_t
-    size, bus_space_handle_t
-    *nhandlep);

-
int
-  

-  bus_space_alloc(bus_space_tag_t
-    space, bus_addr_t reg_start,
-    bus_addr_t reg_end, bus_size_t
-    size, bus_size_t alignment,
-    bus_size_t boundary, int flags,
-    bus_addr_t *addrp, bus_space_handle_t
-    *handlep);

-
void
-  

-  bus_space_free(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    size);

-
void *
-  

-  bus_space_vaddr(bus_space_tag_t
-    space, bus_space_handle_t
-    handle);

-
paddr_t
-  

-  bus_space_mmap(bus_space_tag_t
-    space, bus_addr_t
-    addr, off_t off,
-    int prot,
-    int flags);

-
int
-  

-  bus_space_tag_create(bus_space_tag_t
-    obst, uint64_t
-    present, uint64_t
-    extpresent, const struct
-    bus_space_overrides *ov,
-    void *ctx,
-    bus_space_tag_t
-  *bstp);

-
void
-  

-  bus_space_tag_destroy(bus_space_tag_t
-    bst);

-
int
-  

-  bus_space_peek_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    *datap);

-
int
-  

-  bus_space_peek_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    *datap);

-
int
-  

-  bus_space_peek_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    *datap);

-
int
-  

-  bus_space_peek_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    *datap);

-
int
-  

-  bus_space_poke_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    data);

-
int
-  

-  bus_space_poke_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    data);

-
int
-  

-  bus_space_poke_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    data);

-
int
-  

-  bus_space_poke_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    data);

-
uint8_t
-  

-  bus_space_read_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset);

-
uint16_t
-  

-  bus_space_read_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset);

-
uint32_t
-  

-  bus_space_read_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset);

-
uint64_t
-  

-  bus_space_read_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset);

-
void
-  

-  bus_space_write_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    value);

-
void
-  

-  bus_space_write_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    value);

-
void
-  

-  bus_space_write_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    value);

-
void
-  

-  bus_space_write_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    value);

-
void
-  

-  bus_space_barrier(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, bus_size_t
-    length, int
-  flags);

-
void
-  

-  bus_space_read_region_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_stream_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_stream_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_stream_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_region_stream_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_stream_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_stream_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_stream_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_region_stream_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_1(bus_space_tag_t
-    space, bus_space_handle_t
-    srchandle, bus_size_t
-    srcoffset,
-    bus_space_handle_t
-    dsthandle, bus_size_t
-    dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_2(bus_space_tag_t
-    space, bus_space_handle_t
-    srchandle, bus_size_t
-    srcoffset,
-    bus_space_handle_t
-    dsthandle, bus_size_t
-    dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_4(bus_space_tag_t
-    space, bus_space_handle_t
-    srchandle, bus_size_t
-    srcoffset,
-    bus_space_handle_t
-    dsthandle, bus_size_t
-    dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_copy_region_8(bus_space_tag_t
-    space, bus_space_handle_t
-    srchandle, bus_size_t
-    srcoffset,
-    bus_space_handle_t
-    dsthandle, bus_size_t
-    dstoffset, bus_size_t
-    count);

-
void
-  

-  bus_space_set_region_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    value, bus_size_t
-    count);

-
void
-  

-  bus_space_set_region_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    value, bus_size_t
-    count);

-
void
-  

-  bus_space_set_region_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    value, bus_size_t
-    count);

-
void
-  

-  bus_space_set_region_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    value, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_stream_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_stream_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_stream_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_read_multi_stream_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint64_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_stream_1(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint8_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_stream_2(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint16_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_stream_4(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint32_t
-    *datap, bus_size_t
-    count);

-
void
-  

-  bus_space_write_multi_stream_8(bus_space_tag_t
-    space, bus_space_handle_t
-    handle, bus_size_t
-    offset, const uint64_t
-    *datap, bus_size_t
-    count);

-

-

-

-
The bus_space functions exist to allow
-    device drivers machine-independent access to bus memory and register areas.
-    All of the functions and types described in this document can be used by
-    including the <sys/bus.h>
-    header file.

-
Many common devices are used on multiple architectures, but are
-    accessed differently on each because of architectural constraints. For
-    instance, a device which is mapped in one system's I/O space may be mapped
-    in memory space on a second system. On a third system, architectural
-    limitations might change the way registers need to be accessed (e.g.,
-    creating a non-linear register space). In some cases, a single driver may
-    need to access the same type of device in multiple ways in a single system
-    or architecture. The goal of the bus_space functions
-    is to allow a single driver source file to manipulate a set of devices on
-    different system architectures, and to allow a single driver object file to
-    manipulate a set of devices on multiple bus types on a single
-  architecture.

-
Not all busses have to implement all functions described in this
-    document, though that is encouraged if the operations are logically
-    supported by the bus. Unimplemented functions should cause compile-time
-    errors if possible.

-
All of the interface definitions described in this document are
-    shown as function prototypes and discussed as if they were required to be
-    functions. Implementations are encouraged to implement prototyped
-    (type-checked) versions of these interfaces, but may implement them as
-    macros if appropriate. Machine-dependent types, variables, and functions
-    should be marked clearly in
-    <machine/bus_defs.h> and in
-    <machine/bus_funcs.h> to
-    avoid confusion with the machine-independent types and functions, and, if
-    possible, should be given names which make the machine-dependence clear.

-

-

-

-
Bus spaces are described by bus space tags, which can be created
-    only by machine-dependent code. A given machine may have several different
-    types of bus space (e.g., memory space and I/O space), and thus may provide
-    multiple different bus space tags. Individual busses or devices on a machine
-    may use more than one bus space tag. For instance, ISA devices are given an
-    ISA memory space tag and an ISA I/O space tag. Architectures may have
-    several different tags which represent the same type of space, for instance
-    because of multiple different host bus interface chipsets.

-
A range in bus space is described by a bus address and a bus size.
-    The bus address describes the start of the range in bus space. The bus size
-    describes the size of the range in bytes. Busses which are not byte
-    addressable may require use of bus space ranges with appropriately aligned
-    addresses and properly rounded sizes.

-
Access to regions of bus space is facilitated by use of bus space
-    handles, which are usually created by mapping a specific range of a bus
-    space. Handles may also be created by allocating and mapping a range of bus
-    space, the actual location of which is picked by the implementation within
-    bounds specified by the caller of the allocation function.

-
All of the bus space access functions require one bus space tag
-    argument, at least one handle argument, and at least one offset argument (a
-    bus size). The bus space tag specifies the space, each handle specifies a
-    region in the space, and each offset specifies the offset into the region of
-    the actual location(s) to be accessed. Offsets are given in bytes, though
-    busses may impose alignment constraints. The offset used to access data
-    relative to a given handle must be such that all of the data being accessed
-    is in the mapped region that the handle describes. Trying to access data
-    outside that region is an error.

-
Bus space I/O operations on mappings made
-    with BUS_SPACE_MAP_PREFETCHABLE or
-    BUS_SPACE_MAP_CACHEABLE may be reordered or combined
-    for performance on devices that support it, such as write-combining (a.k.a.
-    ‘prefetchable’) graphics framebuffers or cacheable ROM images.
-    The
-    ()
-    function orders reads and writes in prefetchable or cacheable mappings
-    relative to other reads and writes in bus spaces. Barriers are needed
-     when
-    prefetchable or cacheable mappings are involved:

-
    
-  
  • Bus space reads and writes on non-prefetchable, non-cacheable mappings at
-      a single device are totally ordered with one another.
    • 
-  
  • Ordering of memory operations on normal memory with bus space I/O for
-      triggering DMA or being notified of DMA completion requires
-      bus_dmamap_sync(9).
    • 
-

-
People trying to write portable drivers with the
-    bus_space functions should try to make minimal
-    assumptions about what the system allows. In particular, they should expect
-    that the system requires bus space addresses being accessed to be naturally
-    aligned (i.e., base address of handle added to offset is a multiple of the
-    access size), and that the system does alignment checking on pointers (i.e.,
-    pointer to objects being read and written must point to properly-aligned
-    data).

-
The descriptions of the bus_space
-    functions given below all assume that they are called with proper arguments.
-    If called with invalid arguments or arguments that are out of range (e.g.,
-    trying to access data outside of the region mapped when a given handle was
-    created), undefined behaviour results. In that case, they may cause the
-    system to halt, either intentionally (via panic) or unintentionally (by
-    causing a fatal trap or by some other means) or may cause improper operation
-    which is not immediately fatal. Functions which return void or which return
-    data read from bus space (i.e., functions which don't obviously return an
-    error code) do not fail. They could only fail if given invalid arguments,
-    and in that case their behaviour is undefined. Functions which take a count
-    of bytes have undefined results if the specified count
-    is zero.

-

-

-

-
Several types are defined in
-    <machine/bus_defs.h> to
-    facilitate use of the bus_space functions by
-    drivers.

-

-

-  
bus_addr_t

-  

-    
The bus_addr_t type is used to describe
-        bus addresses. It must be an unsigned integral type capable of holding
-        the largest bus address usable by the architecture. This type is
-        primarily used when mapping and unmapping bus space.

-    

-  

-  
bus_size_t

-  

-    
The bus_size_t type is used to describe
-        sizes of ranges in bus space. It must be an unsigned integral type
-        capable of holding the size of the largest bus address range usable on
-        the architecture. This type is used by virtually all of the
-        bus_space functions, describing sizes when
-        mapping regions and offsets into regions when performing space access
-        operations.

-    

-  

-  
bus_space_tag_t

-  

-    
The bus_space_tag_t type is used to
-        describe a particular bus space on a machine. Its contents are
-        machine-dependent and should be considered opaque by machine-independent
-        code. This type is used by all bus_space
-        functions to name the space on which they're operating.

-    

-  

-  
bus_space_handle_t

-  

-    
The bus_space_handle_t type is used to
-        describe a mapping of a range of bus space. Its contents are
-        machine-dependent and should be considered opaque by machine-independent
-        code. This type is used when performing bus space access operations.

-    

-  

-  
bus_space_reservation_t

-  

-    
The
-        bus_space_reservation_t type is used to describe a
-        range of bus space. It logically consists of a
-        bus_addr_t, the first address in the range, and a
-        bus_size_t, the length in bytes of the range.
-        Machine-independent code creates and interrogates a
-        bus_space_reservation_t using a constructor,
-        (),
-        and accessor functions,
-        ()
-        and
-        ().

-  

-

-

-

-

-
To check whether or not one bus_space_tag_t
-    refers to the same space as another in machine-independent code, do not use
-    either memcmp(9) or the C equals (==) operator. Use
-    (),
-    instead.

-

-

-

-
Bus space must be mapped before it can be used, and should be
-    unmapped when it is no longer needed. The
-    bus_space_map(),
-    bus_space_reservation_map(),
-    bus_space_reservation_unmap(), and
-    bus_space_unmap() functions provide these
-    capabilities.

-
Some drivers need to be able to pass a
-    subregion of already-mapped bus space to another driver or module within a
-    driver. The
-    ()
-    function allows such subregions to be created.

-

-

-  
(space,
-    address, size,
-    flags, handlep)

-  

-    
The
-        ()
-        function exclusively reserves and maps the region of bus space named by
-        the space, address, and
-        size arguments. If successful, it returns zero and
-        fills in the bus space handle pointed to by
-        handlep with the handle that can be used to access
-        the mapped region. If unsuccessful, it will return non-zero and leave
-        the bus space handle pointed to by handlep in an
-        undefined state.

-    
The flags argument controls how the
-        space is to be mapped. Supported flags include:

-    

-    

-      

-      
Try to map the space so that accesses can be cached by the system
-          cache. If this flag is not specified, the implementation should map
-          the space so that it will not be cached. This mapping method will only
-          be useful in very rare occasions.
-        
This flag must have a value of 1 on all implementations
-            for backward compatibility.

-      

-      

-      
Try to map the space so that accesses can be prefetched by the system,
-          and writes can be buffered. This means, accesses should be side effect
-          free (idempotent). The
-          ()
-          methods will flush the write buffer or force actual read accesses. If
-          this flag is not specified, the implementation should map the space so
-          that it will not be prefetched or delayed.

-      

-      
Try to map the space so that its contents can be accessed linearly via
-          normal memory access methods (e.g., pointer dereferencing and
-          structure accesses). The bus_space_vaddr()
-          method can be used to obtain the kernel virtual address of the mapped
-          range. This is useful when software wants to do direct access to a
-          memory device, e.g., a frame buffer. If this flag is specified and
-          linear mapping is not possible, the
-          bus_space_map() call should fail. If this flag
-          is not specified, the system may map the space in whatever way is most
-          convenient. Use of this mapping method is not encouraged for normal
-          device access; where linear access is not essential, use of the
-          ()
-          methods is strongly recommended.

-    

-    

-    
Not all combinations of flags make sense or are supported with
-        all spaces. For instance,
-        BUS_SPACE_MAP_CACHEABLE may be meaningless when
-        used on many systems' I/O port spaces, and on some systems
-        BUS_SPACE_MAP_LINEAR without
-        BUS_SPACE_MAP_PREFETCHABLE may never work. When
-        the system hardware or firmware provides hints as to how spaces should
-        be mapped (e.g., the PCI memory mapping registers'
-        "prefetchable" bit), those hints should be followed for
-        maximum compatibility. On some systems, requesting a mapping that cannot
-        be satisfied (e.g., requesting a non-prefetchable mapping when the
-        system can only provide a prefetchable one) will cause the request to
-        fail.

-    
Some implementations may keep track of use of bus space for
-        some or all bus spaces and refuse to allow duplicate allocations. This
-        is encouraged for bus spaces which have no notion of slot-specific space
-        addressing, such as ISA and VME, and for spaces which coexist with those
-        spaces (e.g., EISA and PCI memory and I/O spaces co-existing with ISA
-        memory and I/O spaces).

-    
Mapped regions may contain areas for which there is no device
-        on the bus. If space in those areas is accessed, the results are
-        bus-dependent.

-    

-  

-  
(space,
-    bsr, flags,
-    handlep)

-  

-    
The
-        ()
-        function is similar to bus_space_map() but it
-        maps a region of bus space that was previously reserved by a call to
-        bus_space_reserve() or
-        bus_space_reserve_subregion(). The region is
-        given by the space and bsr
-        arguments. If successful, it returns zero and fills in the bus space
-        handle pointed to by handlep with the handle that
-        can be used to access the mapped region. If unsuccessful, it will return
-        non-zero and leave the bus space handle pointed to by
-        handlep in an undefined state.

-    
A region mapped by
-        ()
-        may only be unmapped by a call to
-        bus_space_reservation_unmap().

-    
For more details, see the description of
-        ().

-    

-  

-  
(space,
-    handle, size)

-  

-    
The
-        ()
-        function unmaps and relinquishes a region of bus space reserved and
-        mapped with bus_space_map(). When unmapping a
-        region, the size specified should be the same as
-        the size given to bus_space_map() when mapping
-        that region.

-    
After
-        ()
-        is called on a handle, that handle is no longer valid. (If copies were
-        made of the handle they are no longer valid, either.)

-    
This function will never fail. If it
-        would fail (e.g., because of an argument error), that indicates a
-        software bug which should cause a panic. In that case,
-        ()
-        will never return.

-    

-  

-  
(space,
-    handle, size)

-  

-    
The
-        ()
-        function is similar to bus_space_unmap() but it
-        should be called on handles mapped by
-        bus_space_reservation_map() and only on such
-        handles. Unlike bus_space_unmap(),
-        bus_space_reservation_unmap() does not
-        relinquish exclusive use of the bus space named by
-        handle and size; that is the
-        job of bus_space_release().

-    

-  

-  
(space,
-    handle, offset,
-    size, nhandlep)

-  

-    
The
-        ()
-        function is a convenience function which makes a new handle to some
-        subregion of an already-mapped region of bus space. The subregion
-        described by the new handle starts at byte offset
-        offset into the region described by
-        handle, with the size given by
-        size, and must be wholly contained within the
-        original region.

-    
If successful,
-        ()
-        returns zero and fills in the bus space handle pointed to by
-        nhandlep. If unsuccessful, it returns non-zero and
-        leaves the bus space handle pointed to by nhandlep
-        in an undefined state. In either case, the handle described by
-        handle remains valid and is unmodified.

-    
When done with a handle created by
-        (),
-        the handle should be thrown away. Under no circumstances should
-        bus_space_unmap() be used on the handle. Doing
-        so may confuse any resource management being done on the space, and will
-        result in undefined behaviour. When
-        bus_space_unmap() or
-        bus_space_free() is called on a handle, all
-        subregions of that handle become invalid.

-    

-  

-  
(tag,
-    handle)

-  

-    
This method returns the kernel
-        virtual address of a mapped bus space if and only if it was mapped with
-        the BUS_SPACE_MAP_LINEAR flag. The range can be
-        accessed by normal (volatile) pointer dereferences. If mapped with the
-        BUS_SPACE_MAP_PREFETCHABLE flag, the
-        ()
-        method must be used to force a particular access order.

-    

-  

-  
(tag,
-    addr, off,
-    prot, flags)

-  

-    
This method is used to provide support
-        for memory mapping bus space into user applications. If an address space
-        is addressable via volatile pointer dereferences,
-        ()
-        will return the physical address (possibly encoded as a
-        machine-dependent cookie) of the bus space indicated by
-        addr and off.
-        addr is the base address of the device or device
-        region, and off is the offset into that region
-        that is being requested. If the request is made with
-        BUS_SPACE_MAP_LINEAR as a flag, then a linear
-        region must be returned to the caller. If the region cannot be mapped
-        (either the address does not exist, or the constraints can not be met),
-        bus_space_mmap() returns
-        -1 to indicate failure.

-    
Note that it is not necessary that the
-        region being requested by a
-        ()
-        call be mapped into a bus_space_handle_t.

-    
()
-        is called once per PAGE_SIZE page in the range.
-        The prot argument indicates the memory protection
-        requested by the user application for the range.

-    

-  

-  
(space,
-    handle1, handle2)

-  
Use bus_space_handle_is_equal() to check whether
-      or not handle1 and handle2
-      refer to regions starting at the same address in the bus space
-      space.

-

-

-

-

-
Some devices require or allow bus space to be allocated by the
-    operating system for device use. When the devices no longer need the space,
-    the operating system should free it for use by other devices. The
-    bus_space_alloc(),
-    bus_space_free(),
-    bus_space_reserve(),
-    bus_space_reserve_subregion(), and
-    bus_space_release() functions provide these
-    capabilities. The functions bus_space_reserve(),
-    bus_space_reserve_subregion(), and
-    bus_space_release() are not yet available on all
-    architectures.

-

-

-  
(space,
-    reg_start, reg_end,
-    size, alignment,
-    boundary, flags,
-    addrp, handlep)

-  

-    
The
-        ()
-        function allocates and maps a region of bus space with the size given by
-        size, corresponding to the given constraints. If
-        successful, it returns zero, fills in the bus address pointed to by
-        addrp with the bus space address of the allocated
-        region, and fills in the bus space handle pointed to by
-        handlep with the handle that can be used to access
-        that region. If unsuccessful, it returns non-zero and leaves the bus
-        address pointed to by addrp and the bus space
-        handle pointed to by handlep in an undefined
-        state.

-    
Constraints on the allocation are given
-        by the reg_start, reg_end,
-        alignment, and boundary
-        parameters. The allocated region will start at or after
-        reg_start and end before or at
-        reg_end. The alignment
-        constraint must be a power of two, and the allocated region will start
-        at an address that is an even multiple of that power of two. The
-        boundary constraint, if non-zero, ensures that the
-        region is allocated so that first address in
-        region / boundary has the same value as
-        last address in region /
-        boundary. If the constraints cannot be met,
-        ()
-        will fail. It is an error to specify a set of constraints that can never
-        be met (for example, size greater than
-        boundary).

-    
The flags parameter is the same as the
-        like-named parameter to bus_space_map, the same
-        flag values should be used, and they have the same meanings.

-    
Handles created by
-        ()
-        should only be freed with bus_space_free().
-        Trying to use bus_space_unmap() on them causes
-        undefined behaviour. The bus_space_subregion()
-        function can be used on handles created by
-        bus_space_alloc().

-    

-  

-  
(t,
-    bpa, size,
-    flags, bsrp)

-  

-    
The
-        ()
-        function reserves, for the caller's exclusive use,
-        size bytes starting at the address
-        bpa in the space referenced by
-        t.

-    
()
-        does 
-        map the space. The caller should use
-        bus_space_reservation_map() to map the
-        reservation. flags contains a hint how the caller
-        may map the reservation, later. Whenever possible, callers should pass
-        the same flags to bus_space_reserve() as they
-        will pass to bus_space_reservation_map() to map
-        the reservation.

-    
On success,
-        ()
-        records the reservation at bsrp and returns 0. On
-        failure, bsrp is undefined, and
-        bus_space_reserve() returns a non-zero error
-        code. Possible error codes include

-    

-    

-      
ENOMEM

-      
There was not sufficient bus space at bpa to
-          satisfy the request.

-      
EOPNOTSUPP

-      
bus_space_reserve() is not supported on this
-          architecture, or flags was incompatible with the
-          bus space represented by t.

-    

-    

-    

-  

-  
(t,
-    reg_start, reg_end,
-    size, alignment,
-    boundary, flags,
-    bsrp)

-  

-    
The
-        ()
-        function reserves, for the caller's exclusive use,
-        size bytes in the space referenced by
-        t. The parameters reg_start,
-        reg_end, alignment,
-        boundary, and flags each
-        work alike to the bus_space_alloc() parameters
-        of the same names.

-    
On success,
-        ()
-        records the reservation at bsrp and returns 0. On
-        failure, bsrp is undefined, and
-        bus_space_reserve_subregion() returns a non-zero
-        error code. Possible error codes include

-    

-    

-      
ENOMEM

-      
There was not sufficient bus space at bpa to
-          satisfy the request.

-      
EOPNOTSUPP

-      
bus_space_reserve() is not supported on this
-          architecture, or flags was incompatible with the
-          bus space represented by t.

-    

-    

-    

-  

-  
(t,
-    bsr)

-  

-    
The
-        ()
-        function releases the bus space bsr in
-        t that was previously reserved by
-        bus_space_reserve() or
-        bus_space_reserve_subregion().

-    
If
-        ()
-        is called on a reservation that has been mapped by
-        bus_space_reservation_map() without subsequently
-        being unmapped, the behavior of the system is undefined.

-    

-  

-  
(space,
-    handle, size)

-  

-    
The
-        ()
-        function unmaps and frees a region of bus space mapped and allocated
-        with bus_space_alloc(). When unmapping a region,
-        the size specified should be the same as the size
-        given to bus_space_alloc() when allocating the
-        region.

-    
After
-        ()
-        is called on a handle, that handle is no longer valid. (If copies were
-        made of the handle, they are no longer valid, either.)

-    
This function will never fail. If it
-        would fail (e.g., because of an argument error), that indicates a
-        software bug which should cause a panic. In that case,
-        ()
-        will never return.

-  

-

-

-

-

-
The simplest way to access bus space is to read or write a single
-    data item. The bus_space_read_N() and
-    bus_space_write_N() families of functions provide
-    the ability to read and write 1, 2, 4, and 8 byte data items on busses which
-    support those access sizes.

-

-

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset)

-  

-    
The
-        ()
-        family of functions reads a 1, 2, 4, or 8 byte data item from the offset
-        specified by offset into the region specified by
-        handle of the bus space specified by
-        space. The location being read must lie within the
-        bus space region specified by handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data item being read. On some systems, not obeying this
-        requirement may cause incorrect data to be read, on others it may cause
-        a system crash.

-    
Read operations done by the
-        ()
-        functions may be executed out of order with respect to other read and
-        write operations if either are on prefetchable or cacheable mappings
-        unless order is enforced by use of the
-        bus_space_barrier() function.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-    

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-    
The
-        ()
-        family of functions writes a 1, 2, 4, or 8 byte data item to the offset
-        specified by offset into the region specified by
-        handle of the bus space specified by
-        space. The location being written must lie within
-        the bus space region specified by handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data item being written. On some systems, not obeying this
-        requirement may cause incorrect data to be written, on others it may
-        cause a system crash.

-    
Write operations done by the
-        ()
-        functions may be executed out of order with respect to other read and
-        write operations if either are on prefetchable or cacheable mappings
-        unless order is enforced by use of the
-        bus_space_barrier() function.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-  

-

-

-

-

-
One problem with the
-    ()
-    and bus_space_write_N() family of functions is that
-    they provide no protection against exceptions which can occur when no
-    physical hardware or device responds to the read or write cycles. In such a
-    situation, the system typically would panic due to a kernel-mode bus error.
-    The bus_space_peek_N() and
-    bus_space_poke_N() family of functions provide a
-    mechanism to handle these exceptions gracefully without the risk of crashing
-    the system.

-
As with
-    ()
-    and bus_space_write_N(), the peek and poke functions
-    provide the ability to read and write 1, 2, 4, and 8 byte data items on
-    busses which support those access sizes. All of the constraints specified in
-    the descriptions of the bus_space_read_N() and
-    bus_space_write_N() functions also apply to
-    bus_space_peek_N() and
-    bus_space_poke_N().

-
The return value indicates the outcome of
-    the peek or poke operation. A return value of zero implies that a hardware
-    device is responding to the operation at the specified offset in the bus
-    space. A non-zero return value indicates that the kernel intercepted a
-    hardware exception (e.g., bus error) when the peek or poke operation was
-    attempted. Note that some busses are incapable of generating exceptions when
-    non-existent hardware is accessed. In such cases, these functions will
-    always return zero and the value of the data read by
-    ()
-    will be unspecified.

-
Finally, it should be noted that at this
-    time the
-    ()
-    and bus_space_poke_N() functions are not re-entrant
-    and should not, therefore, be used from within an interrupt service routine.
-    This constraint may be removed at some point in the future.

-

-

-  
(space,
-    handle, offset,
-    datap)

-  

-  
(space,
-    handle, offset,
-    datap)

-  

-  
(space,
-    handle, offset,
-    datap)

-  

-  
(space,
-    handle, offset,
-    datap)

-  

-    
The
-        ()
-        family of functions cautiously read a 1, 2, 4, or 8 byte data item from
-        the offset specified by offset in the region
-        specified by handle of the bus space specified by
-        space. The data item read is stored in the
-        location pointed to by datap. It is permissible
-        for datap to be NULL, in which case the data item
-        will be discarded after being read.

-    

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-    
The
-        ()
-        family of functions cautiously write a 1, 2, 4, or 8 byte data item
-        specified by value to the offset specified by
-        offset in the region specified by
-        handle of the bus space specified by
-        space.

-  

-

-

-

-

-
Devices that support prefetchable (also known as
-    ‘write-combining’) or cacheable I/O may be mapped with
-    BUS_SPACE_MAP_PREFETCHABLE or
-    BUS_SPACE_MAP_CACHEABLE for higher performance by
-    allowing bus space read and write operations to be reordered, fused, torn,
-    and/or cached by the system.

-
When a driver requires ordering, e.g. to
-    write to a command ring in bus space and then update the command ring
-    pointer, the
-    ()
-    function enforces it.

-

-

-  
(space,
-    handle, offset,
-    length, flags)

-  

-    
The
-        ()
-        function enforces ordering of bus space read and write operations for
-        the specified subregion (described by the offset
-        and length parameters) of the region named by
-        handle in the space named by
-        space.

-    
The flags argument controls what types
-        of operations are to be ordered. Supported flags are:

-    

-    

-      

-      
Guarantee that any program-prior bus space read on
-          any bus space has returned data from the device or
-          memory before any program-later bus space read, bus space write, or
-          memory access via
-          (),
-          on the specified range in the given bus space.
-        
This functions similarly to
-            membar_acquire(3), but additionally orders bus
-            space I/O which membar_ops(3) may not.

-      

-      

-      
Guarantee that any program-prior bus space read, bus space write, or
-          memory access via
-          (),
-          on the specified range in the given bus space, has completed before
-          any program-later bus space write on any bus space.
-        
This functions similarly to
-            membar_release(3), but additionally orders bus
-            space I/O which membar_ops(3) may not.

-      

-      

-        |
-        

-      
Guarantee that any program-prior bus space read, bus space write, or
-          memory access via
-          ()
-          on any bus space has completed before any
-          program-later bus space read, bus space write, or memory access via
-          bus_space_vaddr() on any bus
-          space.
-        
Note that this is independent of the specified bus space
-            and range.

-        
This functions similarly to
-            membar_sync(3), but additionally orders bus space
-            I/O which membar_ops(3) may not. This combination
-            is very unusual, and often much more expensive; most drivers do not
-            need it.

-      

-    

-    

-    
Example: Consider a command ring in bus space with a command
-        ring pointer register, and a response ring in bus space with a response
-        ring pointer register.

-    

-    
error = bus_space_map(sc->sc_regt, ..., 0, &sc->sc_regh);
-if (error)
-	...
-error = bus_space_map(sc->sc_memt, ..., BUS_SPACE_MAP_PREFETCHABLE,
-    &sc->sc_memh);
-if (error)
-	...

-    

-    
To submit a command (assuming there is space in the ring),
-        first write it out and then update the pointer:

-    

-    
i = sc->sc_nextcmdslot;
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i), cmd);
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i) + 4, arg1);
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i) + 8, arg2);
-...
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i) + 4*n, argn);
-bus_space_barrier(sc->sc_memt, sc->sc_memh, CMDSLOT(i), 4*n,
-    BUS_SPACE_BARRIER_WRITE);
-bus_space_write_4(sc->sc_regt, sc->sc_regh, CMDPTR, i);
-sc->sc_nextcmdslot = (i + n + 1) % sc->sc_ncmdslots;

-    

-    
To obtain a response, read the pointer first and then the ring
-        data:

-    

-    
ptr = bus_space_read_4(sc->sc_regt, sc->sc_regh, RESPPTR);
-while ((i = sc->sc_nextrespslot) != ptr) {
-	bus_space_barrier(sc->sc_memt, sc->sc_memh, RESPSLOT(i), 4,
-	    BUS_SPACE_BARRIER_READ);
-	status = bus_space_read_4(sc->sc_memt, sc->sc_memh, RESPSLOT(i));
-	handle_response(status);
-	sc->sc_nextrespslot = (i + 1) % sc->sc_nrespslots;
-}

-    

-  

-

-

-

-

-
Some devices use buffers which are mapped as regions in bus space.
-    Often, drivers want to copy the contents of those buffers to or from memory,
-    e.g., into mbufs which can be passed to higher levels of the system or from
-    mbufs to be output to a network. In order to allow drivers to do this as
-    efficiently as possible, the
-    ()
-    and bus_space_write_region_N() families of functions
-    are provided.

-
Drivers occasionally need to copy one
-    region of a bus space to another, or to set all locations in a region of bus
-    space to contain a single value. The
-    ()
-    family of functions and the bus_space_set_region_N()
-    family of functions allow drivers to perform these operations.

-

-

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-    
The
-        ()
-        family of functions reads count 1, 2, 4, or 8 byte
-        data items from bus space starting at byte offset
-        offset in the region specified by
-        handle of the bus space specified by
-        space and writes them into the array specified by
-        datap. Each successive data item is read from an
-        offset 1, 2, 4, or 8 bytes after the previous data item (depending on
-        which function is used). All locations being read must lie within the
-        bus space region specified by handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data items being read and the data array pointer should be
-        properly aligned. On some systems, not obeying these requirements may
-        cause incorrect data to be read, on others it may cause a system
-      crash.

-    
Read operations done by the
-        ()
-        functions may be executed in any order. They may also be executed out of
-        order with respect to other read and write operations if either are on
-        prefetchable or cacheable mappings unless order is enforced by use of
-        the bus_space_barrier() function. There is no
-        way to insert barriers between reads of individual bus space locations
-        executed by the bus_space_read_region_N()
-        functions.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-    

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-    
The
-        ()
-        family of functions reads count 1, 2, 4, or 8 byte
-        data items from the array specified by datap and
-        writes them to bus space starting at byte offset
-        offset in the region specified by
-        handle of the bus space specified by
-        space. Each successive data item is written to an
-        offset 1, 2, 4, or 8 bytes after the previous data item (depending on
-        which function is used). All locations being written must lie within the
-        bus space region specified by handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data items being written and the data array pointer should
-        be properly aligned. On some systems, not obeying these requirements may
-        cause incorrect data to be written, on others it may cause a system
-        crash.

-    
Write operations done by the
-        ()
-        functions may be executed in any order. They may also be executed out of
-        order with respect to other read and write operations if either are on
-        prefetchable or cacheable mappings unless order is enforced by use of
-        the bus_space_barrier() function. There is no
-        way to insert barriers between writes of individual bus space locations
-        executed by the bus_space_write_region_N()
-        functions.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-    

-  

-  
(space,
-    srchandle, srcoffset,
-    dsthandle, dstoffset,
-    count)

-  

-  
(space,
-    srchandle, srcoffset,
-    dsthandle, dstoffset,
-    count)

-  

-  
(space,
-    srchandle, srcoffset,
-    dsthandle, dstoffset,
-    count)

-  

-  
(space,
-    srchandle, srcoffset,
-    dsthandle, dstoffset,
-    count)

-  

-    
The
-        ()
-        family of functions copies count 1, 2, 4, or 8
-        byte data items in bus space from the area starting at byte offset
-        srcoffset in the region specified by
-        srchandle of the bus space specified by
-        space to the area starting at byte offset
-        dstoffset in the region specified by
-        dsthandle in the same bus space. Each successive
-        data item read or written has an offset 1, 2, 4, or 8 bytes after the
-        previous data item (depending on which function is used). All locations
-        being read and written must lie within the bus space region specified by
-        their respective handles.

-    
For portability, the starting addresses of the regions
-        specified by each handle plus its respective offset should be a multiple
-        of the size of data items being copied. On some systems, not obeying
-        this requirement may cause incorrect data to be copied, on others it may
-        cause a system crash.

-    
Read and write operations done
-        by the
-        ()
-        functions may be executed in any order. They may also be executed out of
-        order with respect to other read and write operations if either are on
-        prefetchable or cacheable mappings unless order is enforced by use of
-        the bus_space_barrier() function. There is no
-        way to insert barriers between reads or writes of individual bus space
-        locations executed by the
-        bus_space_copy_region_N() functions.

-    
Overlapping copies between
-        different subregions of a single region of bus space are handled
-        correctly by the
-        ()
-        functions.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-    

-  

-  
(space,
-    handle, offset,
-    value, count)

-  

-  
(space,
-    handle, offset,
-    value, count)

-  

-  
(space,
-    handle, offset,
-    value, count)

-  

-  
(space,
-    handle, offset,
-    value, count)

-  

-    
The
-        ()
-        family of functions writes the given value to
-        count 1, 2, 4, or 8 byte data items in bus space
-        starting at byte offset offset in the region
-        specified by handle of the bus space specified by
-        space. Each successive data item has an offset 1,
-        2, 4, or 8 bytes after the previous data item (depending on which
-        function is used). All locations being written must lie within the bus
-        space region specified by handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data items being written. On some systems, not obeying this
-        requirement may cause incorrect data to be written, on others it may
-        cause a system crash.

-    
Write operations done by the
-        ()
-        functions may be executed in any order. They may also be executed out of
-        order with respect to other read and write operations if either are on
-        prefetchable or cacheable mappings unless order is enforced by use of
-        the bus_space_barrier() function. There is no
-        way to insert barriers between writes of individual bus space locations
-        executed by the bus_space_set_region_N()
-        functions.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-  

-

-

-

-

-
Some devices implement single locations in bus space which are to
-    be read or written multiple times to communicate data, e.g., some ethernet
-    devices' packet buffer FIFOs. In order to allow drivers to manipulate these
-    types of devices as efficiently as possible, the
-    ()
-    and bus_space_write_multi_N() families of functions
-    are provided.

-

-

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-    
The
-        ()
-        family of functions reads count 1, 2, 4, or 8 byte
-        data items from bus space at byte offset offset in
-        the region specified by handle of the bus space
-        specified by space and writes them into the array
-        specified by datap. Each successive data item is
-        read from the same location in bus space. The location being read must
-        lie within the bus space region specified by
-        handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data items being read and the data array pointer should be
-        properly aligned. On some systems, not obeying these requirements may
-        cause incorrect data to be read, on others it may cause a system
-      crash.

-    
Read operations done by the
-        ()
-        functions may be executed out of order with respect to other read and
-        write operations if the latter are on prefetchable or cacheable mappings
-        unless order is enforced by use of the
-        bus_space_barrier() function.
-        bus_space_read_multi_N() makes no sense itself
-        on prefetchable or cacheable mappings.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-    

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-    
The
-        ()
-        family of functions reads count 1, 2, 4, or 8 byte
-        data items from the array specified by datap and
-        writes them into bus space at byte offset offset
-        in the region specified by handle of the bus space
-        specified by space. Each successive data item is
-        written to the same location in bus space. The location being written
-        must lie within the bus space region specified by
-        handle.

-    
For portability, the starting address of the region specified
-        by handle plus the offset should be a multiple of
-        the size of data items being written and the data array pointer should
-        be properly aligned. On some systems, not obeying these requirements may
-        cause incorrect data to be written, on others it may cause a system
-        crash.

-    
Write operations done by the
-        ()
-        functions may be executed out of order with respect to other read and
-        write operations if the latter are on prefetchable or cacheable mappings
-        unless order is enforced by use of the
-        bus_space_barrier() function.
-        bus_space_write_multi_N() makes no sense itself
-        on prefetchable or cacheable mappings.

-    
These functions will never fail. If they would fail (e.g.,
-        because of an argument error), that indicates a software bug which
-        should cause a panic. In that case, they will never return.

-  

-

-

-

-

-
Most of the bus_space functions imply a
-    host byte-order and a bus byte-order and take care of any translation for
-    the caller. In some cases, however, hardware may map a FIFO or some other
-    memory region for which the caller may want to use multi-word, yet
-    untranslated access. Access to these types of memory regions should be with
-    the
-    ()
-    functions.

-

-

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    value)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-  
(space,
-    handle, offset,
-    datap, count)

-  

-

-
These functions are defined just as their non-stream counterparts,
-    except that they provide no byte-order translation.

-

-

-

-

-  
(obst,
-    present, extpresent,
-    ov, ctx,
-    bstp)

-  
Create a copy of the tag obst at
-      *bstp. Except for the behavior overridden by
-      ov, *bstp inherits the
-      behavior of obst under
-      bus_space calls.
-    
ov contains function pointers
-        corresponding to bus_space routines. Each
-        function pointer has a corresponding bit in
-        present or extpresent, and
-        if that bit is 1, the function pointer overrides the corresponding
-        bus_space call for the new tag. Any combination
-        of these bits may be set in present:

-    

-    

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-      

-      
 

-    

-    
()
-        does not copy ov. After a new tag is created by
-        bus_space_tag_create(), ov
-        must not be destroyed until after the tag is destroyed by
-        bus_space_tag_destroy().

-    
The first argument of every override-function is a
-        void *, and ctx is passed in
-        that argument.

-    
Return 0 if the call succeeds. Return
-        EOPNOTSUPP if the architecture does not support
-        overrides. Return EINVAL if
-        present is 0, if ov is
-        NULL, or if present
-        indicates that an override is present, but the corresponding override in
-        ov is NULL.

-    
If the call does not succeed, *bstp is
-        undefined.

-  

-  
(bst)

-  
Destroy a tag, bst, created by a prior call to
-      bus_space_tag_create(). If
-      bst was not created by
-      bus_space_tag_create(), results are undefined. If
-      bst was already destroyed, results are
-    undefined.

-

-

-

-

-
The definition of the bus_space functions
-    should not yet be considered finalized. There are several changes and
-    improvements which should be explored, including:

-
    
-  
  • Exporting the bus_space functions to userland so
-      that applications (such as X servers) have easier, more portable access to
-      device space.
    • 
-  
  • Redefining bus space tags and handles so that machine-independent bus
-      interface drivers (for example PCI to VME bridges) could define and
-      implement bus spaces without requiring machine-dependent code. If this is
-      done, it should be done in such a way that machine-dependent optimizations
-      should remain possible.
    • 
-  
  • Converting bus spaces (such as PCI configuration space) which currently
-      use space-specific access methods to use the
-      bus_space functions where that is
-    appropriate.
    • 
-  
  • Redefining the way bus space is mapped and allocated, so that mapping and
-      allocation are done with bus specific functions which return bus space
-      tags. This would allow further optimization than is currently possible,
-      and would also ease translation of the bus_space
-      functions into user space (since mapping in user space would look like it
-      just used a different bus-specific mapping function).
    • 
-

-

-

-

-
The current version of the bus_space
-    interface specification differs slightly from the original specification
-    that came into wide use. A few of the function names and arguments have
-    changed for consistency and increased functionality. Drivers that were
-    written to the old, deprecated specification can be compiled by defining the
-    __BUS_SPACE_COMPAT_OLDDEFS preprocessor symbol
-    before including
-    <sys/bus.h>.

-

-

-

-
membar_ops(3), bus_dma(9)

-

-

-

-
The bus_space functions were introduced in
-    a different form (memory and I/O spaces were accessed via different sets of
-    functions) in NetBSD 1.2. The functions were merged
-    to work on generic “spaces” early in the
-    NetBSD 1.3 development cycle, and many drivers were
-    converted to use them. This document was written later during the
-    NetBSD 1.3 development cycle and the specification
-    was updated to fix some consistency problems and to add some missing
-    functionality.

-

-

-

-
The bus_space interfaces were designed and
-    implemented by the NetBSD developer community.
-    Primary contributors and implementors were Chris
-    Demetriou, Jason Thorpe, and
-    Charles Hannum, but the rest of the
-    NetBSD developers and the user community played a
-    significant role in development.

-
Chris Demetriou wrote this manual
-  page.

-

-

-
-  
-    
-    
-  
-
August 12, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/clock.9 3.html b/static/netbsd/man9/clock.9 3.html
deleted file mode 100644
index 5bf14a78..00000000
--- a/static/netbsd/man9/clock.9 3.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
CLOCK(9)Kernel Developer's ManualCLOCK(9)

-

-

-

-
days_in_month,
-    is_leap_year, days_per_year
-    — handy time utilities

-

-

-

-
#include
-    <sys/clock.h>

-
#define SECS_PER_MINUTE 60
-  

-  #define SECS_PER_HOUR 3600
-  

-  #define SECS_PER_DAY 86400
-  

-  #define DAYS_PER_COMMON_YEAR 365
-  

-  #define DAYS_PER_LEAP_YEAR 366
-  

-  #define SECS_PER_COMMON_YEAR (SECS_PER_DAY *
-    DAYS_PER_COMMON_YEAR)
-  

-  #define SECS_PER_LEAP_YEAR (SECS_PER_DAY *
-    DAYS_PER_LEAP_YEAR)

-
static inline int
-  

-  days_in_month(int
-    m);

-
static inline int
-  

-  is_leap_year(uint64_t
-    year);

-
static inline int
-  

-  days_per_year(uint64_t
-    year);

-

-

-

-
The <sys/clock.h>
-    file provides handy time constants and static inline
-    functions.

-

-

-

-
The
-    ()
-    function returns the number of days in the given month.
-    days_in_month() assumes 28 days for February. If the
-    input value is out of the valid range (1-12) then the function returns
-  -1.

-
The
-    ()
-    and
-    ()
-    functions take as the input parameter a value in the Gregorian year
-  format.

-

-

-

-
bintime(9), boottime(9),
-    time_second(9), time_uptime(9),
-    todr_gettime(9)

-

-

-

-
The <sys/clock.h>
-    header with handy utilities originated from
-    <dev/clock_subr.h>, which
-    originated from
-    <arch/hp300/hp300/clock.c>.

-
The
-    <arch/hp300/hp300/clock.c>
-    file first appeared in NetBSD 0.8 as a set of hp300
-    time-converting functions.
-    <dev/clock_subr.h> first
-    appeared in NetBSD 1.3 as a shared list of functions
-    to convert between “year/month/day/hour/minute/second” and
-    seconds since 1970 (“POSIX time”). The
-    <sys/clock.h> file first
-    appeared in NetBSD 8.

-

-

-

-
Kamil Rytarowski

-

-

-
-  
-    
-    
-  
-
December 26, 2014NetBSD 10.1

diff --git a/static/netbsd/man9/cnmagic.9 3.html b/static/netbsd/man9/cnmagic.9 3.html
deleted file mode 100644
index ea61d72b..00000000
--- a/static/netbsd/man9/cnmagic.9 3.html	
+++ /dev/null
@@ -1,164 +0,0 @@
-
-  
-    
-    
-    
-  
-
CNMAGIC(9)Kernel Developer's ManualCNMAGIC(9)

-

-

-

-
cn_init_magic,
-    cn_trap, cn_isconsole,
-    cn_check_magic,
-    cn_destroy_magic,
-    cn_set_magic, cn_get_magic
-    — console magic key sequence management

-

-

-

-
#include
-    <sys/systm.h>

-
void
-  

-  cn_init_magic(cnm_state_t
-    *cnms);

-
void
-  

-  cn_trap();

-
int
-  

-  cn_isconsole(dev_t
-    dev);

-
void
-  

-  cn_check_magic(dev_t
-    dev, int k,
-    cnm_state_t *cnms);

-
void
-  

-  cn_destroy_magic(cnm_state_t
-    *cnms);

-
int
-  

-  cn_set_magic(char
-    *magic);

-
int
-  

-  cn_get_magic(char
-    *magic, int
-  len);

-

-

-

-
The NetBSD console magic key sequence
-    management framework is designed to provide flexible methods to set, change,
-    and detect magic key sequences on console devices and break into the
-    debugger or ROM monitor with a minimum of interrupt latency.

-
Drivers that generate console input should make
-    use of these routines. A different cnm_state_t should
-    be used for each separate input stream. Multiple devices that share the same
-    input stream, such as USB keyboards, can share the same
-    cnm_state_t. Once a cnm_state_t
-    is allocated, it should be initialized with
-    ()
-    so it can be used by
-    ().
-    If a driver thinks it might be the console input device it can set the magic
-    sequence with cn_set_magic() to any arbitrary
-    string. Whenever the driver receives input, it should call
-    cn_check_magic() to process the data and determine
-    whether the magic sequence has been hit.

-
The magic key sequence can be accessed through the
-    hw.cnmagic sysctl variable.
-    This is the raw data and may be keycodes rather than processed characters,
-    depending on the console device.

-

-

-

-
The following functions describe the console magic interface.

-

-  
(cnm)

-  
Initialize the console magic state pointed to by cnm
-      to a usable state.

-  
()

-  
Trap into the kernel debugger or ROM monitor. By default this routine is
-      defined to be
-      ()
-      but can be overridden in MI header files.

-  
(dev)

-  
Determine whether a given dev is the system console.
-      This macro tests to see if dev is the same as
-      cn_tab->cn_dev but can be overridden in MI header
-      files.

-  
cn_check_magic(dev,
-    k, cnms)

-  
All input should be passed through
-      cn_check_magic() so the state machine remains in a
-      consistent state. cn_check_magic() calls
-      cn_isconsole() with dev to
-      determine if this is the console. If that returns true then it runs the
-      input value k through the state machine. If the
-      state machine completes a match of the current console magic sequence
-      cn_trap() is called. Some input may need to be
-      translated to state machine values such as the serial line
-      BREAK sequence.

-  
(cnms)

-  
This should be called once what cnms points to is no
-      longer needed.

-  
cn_set_magic(magic)

-  
cn_set_magic() encodes a
-      nul terminated arbitrary string into values that
-      can be used by the state machine and installs it as the global magic
-      sequence. The escape sequence is character value
-      0x27 and can be used to encode special values:
-    

-    

-    

-      
0x27

-      
The literal value 0x27.

-      
0x01

-      
Serial BREAK sequence.

-      
0x02

-      

-          character.

-    

-    

-    
Returns 0 on success or a non-zero
-        error value.

-  

-  
(magic,
-    len)

-  
Extract the current magic sequence from the state machine and return up to
-      len bytes of it in the buffer pointed to by
-      magic. It uses the same encoding accepted by
-      ().
-      Returns 0 on success or a non-zero error
-    value.

-

-

-

-

-
ddb(4), sysctl(8),
-    cons(9)

-

-

-

-
The NetBSD console magic key sequence
-    management framework first appeared in NetBSD
-  1.6.

-

-

-

-
The NetBSD console magic key sequence
-    management framework was designed and implemented by
-    Eduardo Horvath ⟨eeh@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
July 7, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/condvar.9 3.html b/static/netbsd/man9/condvar.9 3.html
deleted file mode 100644
index 1def4ca5..00000000
--- a/static/netbsd/man9/condvar.9 3.html	
+++ /dev/null
@@ -1,362 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONDVAR(9)Kernel Developer's ManualCONDVAR(9)

-

-

-

-
cv, condvar,
-    cv_init, cv_destroy,
-    cv_wait, cv_wait_sig,
-    cv_timedwait,
-    cv_timedwait_sig,
-    cv_timedwaitbt,
-    cv_timedwaitbt_sig,
-    cv_signal, cv_broadcast,
-    cv_has_waiters — condition
-    variables

-

-

-

-
#include
-    <sys/condvar.h>

-
void
-  

-  cv_init(kcondvar_t
-    *cv, const char
-    *wmesg);

-
void
-  

-  cv_destroy(kcondvar_t
-    *cv);

-
void
-  

-  cv_wait(kcondvar_t
-    *cv, kmutex_t
-    *mtx);

-
int
-  

-  cv_wait_sig(kcondvar_t
-    *cv, kmutex_t
-    *mtx);

-
int
-  

-  cv_timedwait(kcondvar_t
-    *cv, kmutex_t *mtx,
-    int ticks);

-
int
-  

-  cv_timedwait_sig(kcondvar_t
-    *cv, kmutex_t *mtx,
-    int ticks);

-
int
-  

-  cv_timedwaitbt(kcondvar_t
-    *cv, kmutex_t *mtx,
-    struct bintime *bt,
-    const struct bintime
-    *epsilon);

-
int
-  

-  cv_timedwaitbt_sig(kcondvar_t
-    *cv, kmutex_t *mtx,
-    struct bintime *bt,
-    const struct bintime
-    *epsilon);

-
void
-  

-  cv_signal(kcondvar_t
-    *cv);

-
void
-  

-  cv_broadcast(kcondvar_t
-    *cv);

-
bool
-  

-  cv_has_waiters(kcondvar_t
-    *cv);

-

-  

-  options DIAGNOSTIC
-  

-  options LOCKDEBUG

-

-

-

-
Condition variables (CVs) are used in the kernel to synchronize
-    access to resources that are limited (for example, memory) and to wait for
-    pending I/O operations to complete.

-
The kcondvar_t type provides storage for the
-    CV object. This should be treated as an opaque object and not examined
-    directly by consumers.

-

-

-

-

-  
options DIAGNOSTIC

-  

-    
Kernels compiled with the DIAGNOSTIC
-        option perform basic sanity checks on CV operations.

-  

-  
options LOCKDEBUG

-  

-    
Kernels compiled with the LOCKDEBUG
-        option perform potentially CPU intensive sanity checks on CV
-      operations.

-  

-

-

-

-

-

-  
(cv,
-    wmesg)

-  

-    
Initialize a CV for use. No other operations can be performed
-        on the CV until it has been initialized.

-    
The wmesg argument specifies a string of
-        no more than 8 characters that describes the resource or condition
-        associated with the CV. The kernel does not use this argument directly
-        but makes it available for utilities such as ps(1) to
-        display.

-  

-  
(cv)

-  

-    
Release resources used by a CV. If there
-        could be waiters, they should be awoken first with
-        ().
-        The CV must not be used afterwards.

-  

-  
cv_wait(cv,
-    mtx)

-  

-    
Cause the current LWP to wait non-interruptably
-        for access to a resource, or for an I/O operation to complete. The LWP
-        will resume execution when awoken by another thread using
-        ()
-        or cv_broadcast().

-    
mtx specifies a kernel
-        mutex to be used as an interlock, and must be held by the calling LWP on
-        entry to
-        ().
-        It will be released once the LWP has prepared to sleep, and will be
-        reacquired before cv_wait() returns.

-    
A small window exists between testing for
-        availability of a resource and waiting for the resource with
-        (),
-        in which the resource may become available again. The interlock is used
-        to guarantee that the resource will not be signalled as available until
-        the calling LWP has begun to wait for it.

-    
Non-interruptable waits have the potential to deadlock the
-        system, and so must be kept short (typically, under one second).

-    
()
-        is typically used within a loop or restartable code sequence, because it
-        may awaken spuriously. The calling LWP should re-check the condition
-        that caused the wait. If necessary, the calling LWP may call
-        cv_wait() again to continue waiting.

-  

-  
cv_wait_sig(cv,
-    mtx)

-  

-    
As per
-        (),
-        but causes the current LWP to wait interruptably. If the LWP receives a
-        signal, or is interrupted by another condition such as its containing
-        process exiting, the wait is ended early and an error code returned.

-    
If
-        ()
-        returns as a result of a signal, the return value is
-        ERESTART if the signal has the
-        SA_RESTART property. If awoken normally, the
-        value is zero, and EINTR under all other
-        conditions.

-  

-  
cv_timedwait(cv,
-    mtx, ticks)

-  

-    
As per
-        (),
-        but will return early if a timeout specified by the
-        ticks argument expires.

-    
ticks is an
-        architecture and system dependent value related to the number of clock
-        interrupts per second. See hz(9) for details. The
-        mstohz(9) macro can be used to convert a timeout
-        expressed in milliseconds to one suitable for
-        ().
-        If the ticks argument is zero,
-        cv_timedwait() behaves exactly like
-        cv_wait().

-    
If the timeout expires before the LWP is awoken, the return
-        value is EWOULDBLOCK. If awoken normally, the
-        return value is zero.

-  

-  
(cv,
-    mtx, ticks)

-  

-    
As per
-        (),
-        but also accepts a timeout value and will return
-        EWOULDBLOCK if the timeout expires.

-  

-  
cv_timedwaitbt(cv,
-    mtx, bt,
-    epsilon)

-  
 

-  
cv_timedwaitbt_sig(cv,
-    mtx, bt,
-    epsilon)

-  

-    
As per
-        ()
-        and cv_wait_sig(), but will return early if the
-        duration bt has elapsed, immediately if
-        bt is zero. On return,
-        cv_timedwaitbt() and
-        cv_timedwaitbt_sig() subtract the time elapsed
-        from bt in place, or set it to zero if there is no
-        time remaining.

-    
Note that
-        ()
-        and
-        ()
-        may return zero indicating success, rather than
-        EWOULDBLOCK, even if they set the timeout to
-        zero; this means that the caller must re-check the condition in order to
-        avoid potentially losing a cv_signal(), but the
-        
-        wait will time out immediately.

-    
The hint epsilon, which can be
-        DEFAULT_TIMEOUT_EPSILON if in doubt, requests
-        that the wakeup not be delayed more than bt
-        + epsilon, so that the
-        system can coalesce multiple wakeups within their respective epsilons
-        into a single high-resolution clock interrupt or choose to use cheaper
-        low-resolution clock interrupts instead.

-    
However, the system is still limited by its best clock
-        interrupt resolution and by scheduling competition, which may delay the
-        wakeup by more than bt +
-        epsilon.

-  

-  
(cv)

-  

-    
Awaken one LWP waiting on the specified condition variable.
-        Where there are waiters sleeping non-interruptaby, more than one LWP may
-        be awoken. This can be used to avoid a "thundering herd"
-        problem, where a large number of LWPs are awoken following an event, but
-        only one LWP can process the event.

-    
The mutex passed to the wait function
-        (mtx) should be held or have been released
-        immediately before
-        ()
-        is called.

-    
(Note that
-        ()
-        is erroneously named in that it does not send a signal in the
-        traditional sense to LWPs waiting on a CV.)

-  

-  
cv_broadcast(cv)

-  

-    
Awaken all LWPs waiting on the specified condition
-      variable.

-    
As with
-        (),
-        the mutex passed to the wait function (mtx) should
-        be held or have been released immediately before
-        cv_broadcast() is called.

-  

-  
cv_has_waiters(cv)

-  

-    
Return true if one or more LWPs are
-        waiting on the specified condition variable.

-    
()
-        cannot test reliably for interruptable waits. It should only be used to
-        test for non-interruptable waits made using
-        cv_wait().

-    
()
-        should only be used when making diagnostic assertions, and must be
-        called while holding the interlocking mutex passed to
-        cv_wait().

-  

-

-

-

-

-
Consuming a resource:

-

-
	/*
-	 * Lock the resource.  Its mutex will also serve as the
-	 * interlock.
-	 */
-	mutex_enter(&res->mutex);
-
-	/*
-	 * Wait for the resource to become available.  Timeout after
-	 * five seconds.  If the resource is not available within the
-	 * allotted time, return an error.
-	 */
-	struct bintime timeout = { .sec = 5, .frac = 0 };
-	while (res->state == BUSY) {
-		error = cv_timedwaitbt(&res->condvar,
-		    &res->mutex, &timeout, DEFAULT_TIMEOUT_EPSILON);
-		if (error) {
-			KASSERT(error == EWOULDBLOCK);
-			mutex_exit(&res->mutex);
-			return ETIMEDOUT;
-		}
-	}
-
-	/*
-	 * It's now available to us.  Take ownership of the
-	 * resource, and consume it.
-	 */
-	res->state = BUSY;
-	mutex_exit(&res->mutex);
-	consume(res);

-

-
Releasing a resource for the next consumer to use:

-

-
	mutex_enter(&res->mutex);
-	res->state = IDLE;
-	cv_signal(&res->condvar);
-	mutex_exit(&res->mutex);

-

-

-

-

-
The core of the CV implementation is in
-    sys/kern/kern_condvar.c.

-
The header file sys/sys/condvar.h
-    describes the public interface.

-

-

-

-
sigaction(2), membar_ops(3),
-    errno(9), mstohz(9),
-    mutex(9), rwlock(9)

-

-
Jim Mauro and
-    Richard McDougall, Solaris
-    Internals: Core Kernel Architecture, Prentice
-    Hall, 2001, ISBN
-    0-13-022496-0.

-

-

-

-
The CV primitives first appeared in NetBSD
-    5.0. The cv_timedwaitbt() and
-    cv_timedwaitbt_sig() primitives first appeared in
-    NetBSD 9.0.

-

-

-
-  
-    
-    
-  
-
September 7, 2023NetBSD 10.1

diff --git a/static/netbsd/man9/cons.9 3.html b/static/netbsd/man9/cons.9 3.html
deleted file mode 100644
index 2983cb8d..00000000
--- a/static/netbsd/man9/cons.9 3.html	
+++ /dev/null
@@ -1,137 +0,0 @@
-
-  
-    
-    
-    
-  
-
CONS(9)Kernel Developer's ManualCONS(9)

-

-

-

-
cnbell, cnflush,
-    cngetc, cngetsn,
-    cnhalt, cnpollc,
-    cnputc — console access
-    interface

-

-

-

-
#include
-    <dev/cons.h>

-
void
-  

-  cnbell(u_int
-    pitch, u_int
-    period, u_int
-    volume);

-
void
-  

-  cnflush(void);

-
int
-  

-  cngetc(void);

-
int
-  

-  cngetsn(char
-    *cp, int size);

-
void
-  

-  cnhalt(void);

-
void
-  

-  cnpollc(int
-    on);

-
void
-  

-  cnputc(int
-    c);

-

-

-

-
These functions operate over the current console device. The
-    console must be initialized before these functions can be used.

-
Console input polling functions
-    (),
-    ()
-    and
-    ()
-    are only to be used during initial system boot, e.g., when asking for root
-    and dump device or to get necessary user input within mountroothooks. Once
-    the system boots, user input is read via standard tty(4)
-    facilities.

-
The following is a brief description of each function:

-

-  
()

-  
Ring a bell at appropriate pitch, for duration of
-      period milliseconds at given
-      volume. Note that the volume
-      value is ignored commonly.

-  
()

-  
Waits for all pending output to finish.

-  
cngetc()

-  
Poll (busy wait) for an input and return the input key. Returns 0 if there
-      is no console input device. cnpollc()
-       be called
-      before cngetc() could be used.
-      cngetc() should be used during kernel startup
-      only.

-  
cngetsn()

-  
Read one line of user input, stop reading once the newline key is input.
-      Input is echoed back. This uses cnpollc() and
-      cngetc(). Number of read characters is
-      size at maximum, user is notified by console bell
-      when the end of input buffer is reached. <Backspace> key works as
-      expected. <@> or <CTRL>-u make
-      cngetsn() discard input read so far, print newline
-      and wait for next input. cngetsn() returns number
-      of characters actually read, excluding the final newline.
-      cp is
-       zero-ended
-      before return. cngetsn() should be used during
-      kernel startup only.

-  
()

-  
Terminates the console device (i.e. cleanly shuts down the console
-      hardware.)

-  
cnpollc()

-  
Switch the console driver to polling mode if on is
-      nonzero, or back to interrupt driven mode if on is
-      zero. cnpollc() should be used during kernel
-      startup only.

-  
()

-  
Console kernel output character routine. Commonly, kernel code uses
-      printf(9) rather than using this low-level
-    interface.

-

-

-

-

-
This waits until a <Enter> key is pressed:

-

-
int c;
-
-cnpollc(1);
-for(;;) {
-	c = cngetc();
-	if ((c == '\r' || (c == '\n')) {
-		printf("\n");
-		break;
-	}
-}
-cnpollc(0);

-

-

-

-

-
pckbd(4), pcppi(4),
-    tty(4), wscons(4),
-    wskbd(4), printf(9),
-    spl(9), wscons(9)

-

-

-
-  
-    
-    
-  
-
June 8, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/cprng.9 3.html b/static/netbsd/man9/cprng.9 3.html
deleted file mode 100644
index 4949c78c..00000000
--- a/static/netbsd/man9/cprng.9 3.html	
+++ /dev/null
@@ -1,218 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPRNG(9)Kernel Developer's ManualCPRNG(9)

-

-

-

-
cprng,
-    cprng_strong_create,
-    cprng_strong_destroy,
-    cprng_strong,
-    cprng_strong32,
-    cprng_strong64, cprng_fast,
-    cprng_fast32, cprng_fast64
-    — cryptographic pseudorandom number
-    generators

-

-

-

-
#include
-    <sys/cprng.h>

-
cprng_strong_t *
-  

-  cprng_strong_create(const
-    char *name, int
-    ipl, int
-  flags);

-
void
-  

-  cprng_strong_destroy(cprng_strong_t
-    *cprng);

-
size_t
-  

-  cprng_strong(cprng_strong_t
-    *cprng, void *buf,
-    size_t len,
-    int flags);

-
uint32_t
-  

-  cprng_strong32(void);

-
uint64_t
-  

-  cprng_strong64(void);

-
size_t
-  

-  cprng_fast(void
-    *buf, size_t
-  len);

-
uint32_t
-  

-  cprng_fast32(void);

-
uint64_t
-  

-  cprng_fast64(void);

-

-
#define CPRNG_MAX_LEN   524288

-

-

-

-

-
The cprng family of functions provide
-    cryptographic pseudorandom number generators automatically seeded from the
-    kernel entropy pool. All applications in the kernel requiring random data or
-    random choices should use the cprng_strong family of
-    functions, unless performance constraints demand otherwise.

-
The cprng_fast family of functions may be
-    used in applications that can tolerate exposure of past random data, such as
-    initialization vectors or transaction ids that are sent over the internet
-    anyway, if the applications require higher throughput or lower per-request
-    latency than the cprng_strong family of functions
-    provide. If in doubt, choose cprng_strong.

-
A single instance of the fast generator
-    serves the entire kernel. A well-known instance of the strong generator,
-    kern_cprng, may be used by any in-kernel caller, but
-    separately seeded instances of the strong generator can also be created by
-    calling
-    ().

-
The cprng
-    functions may be used in soft interrupt context, except for
-    ()
-    and cprng_strong_destroy() which are allowed only at
-    IPL_NONE in thread context; see
-    spl(9).

-
The cprng functions replace the legacy
-    arc4random(9) and rnd_extract_data(9)
-    functions.

-

-

-

-

-  
(name,
-    ipl, flags)

-  
Create an instance of the cprng_strong generator. This generator currently
-      implements the NIST SP 800-90A Hash_DRBG with SHA-256 as the hash
-      function.
-    
The name argument is used to
-        “personalize” the Hash_DRBG according to the standard, so
-        that its initial state will depend both on seed material from the
-        entropy pool and also on the personalization string (name).

-    
The ipl argument specifies the interrupt
-        priority level for the mutex which will serialize access to the new
-        instance of the generator (see spl(9)), and must be no
-        higher than IPL_SOFTSERIAL.

-    
The flags argument must be zero.

-    
Creation will succeed even if full entropy for the generator
-        is not available. In this case, the first request to read from the
-        generator may cause reseeding.

-    
()
-        may sleep to allocate memory.

-  

-  
cprng_strong_destroy(cprng)

-  
Destroy cprng.
-    
()
-        may sleep.

-  

-  
(cprng,
-    buf, len,
-    flags)

-  
Fill memory location buf with up to
-      len bytes from the generator
-      cprng, and return the number of bytes.
-      len must be at most
-      CPRNG_MAX_LEN. flags must be
-      zero.

-  
cprng_strong32()

-  
Generate 32 bits using the kern_cprng strong
-      generator.
-    
()
-        does not sleep.

-  

-  
cprng_strong64()

-  
Generate 64 bits using the kern_cprng strong
-      generator.
-    
()
-        does not sleep.

-  

-  
cprng_fast(buf,
-    len)

-  
Fill memory location buf with
-      len bytes from the fast generator.
-    
()
-        does not sleep.

-  

-  
cprng_fast32()

-  
Generate 32 bits using the fast generator.
-    
()
-        does not sleep.

-  

-  
cprng_fast64()

-  
Generate 64 bits using the fast generator.
-    
()
-        does not sleep.

-  

-

-

-

-

-
The cprng family of functions provide the
-    following security properties:

-
    
-  
  • An attacker who has seen some outputs of any of the
-      cprng functions cannot predict past or future
-      unseen outputs.
    • 
-  
  • An attacker who has compromised kernel memory cannot predict past outputs
-      of the cprng_strong functions. However, such an
-      attacker may be able to predict past outputs of the
-      cprng_fast functions.
    • 
-

-
The second property is sometimes called “backtracking
-    resistance”, “forward secrecy”, or “key
-    erasure” in the cryptography literature. The
-    cprng_strong functions provide backtracking
-    resistance; the cprng_fast functions do not.

-

-

-

-
The cprng_strong functions are implemented
-    in sys/kern/subr_cprng.c, and use the NIST SP
-    800-90A Hash_DRBG implementation in
-    sys/crypto/nist_hash_drbg. The
-    cprng_fast functions are implemented in
-    sys/crypto/cprng_fast/cprng_fast.c, and use the
-    ChaCha8 stream cipher.

-

-

-

-
condvar(9), rnd(9),
-    spl(9)

-
Elaine Barker and
-    John Kelsey, Recommendation for
-    Random Number Generation Using Deterministic Random Bit Generators
-    (Revised), National Institute of Standards and
-    Technology, 2011, NIST
-    Special Publication 800-90A, Rev 1.

-
Daniel J. Bernstein,
-    ChaCha, a variant of Salsa20,
-    http://cr.yp.to/papers.html#chacha,
-    2008-01-28, Document ID:
-    4027b5256e17b9796842e6d0f68b0b5e.

-

-

-

-
The cprng family of functions first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
August 16, 2020NetBSD 10.1

diff --git a/static/netbsd/man9/cpu_configure.9 3.html b/static/netbsd/man9/cpu_configure.9 3.html
deleted file mode 100644
index 2a67aa1b..00000000
--- a/static/netbsd/man9/cpu_configure.9 3.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPU_CONFIGURE(9)Kernel Developer's ManualCPU_CONFIGURE(9)

-

-

-

-
cpu_configure —
-    machine-dependent device autoconfiguration

-

-

-

-
#include
-    <sys/systm.h>

-
void
-  

-  cpu_configure(void);

-

-

-

-
The machine-dependent
-    ()
-    is called during system bootstrap to perform the machine-dependent portion
-    of device autoconfiguration. It sets the configuration machinery in motion
-    by finding the root bus (“mainbus”). When this function
-    returns, interrupts must be enabled.

-
The following tasks are performed by
-    ():

-
-

-

-

-
autoconf(9),
-  cpu_startup(9)

-

-

-
-  
-    
-    
-  
-
April 13, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/cpu_dumpconf.9 3.html b/static/netbsd/man9/cpu_dumpconf.9 3.html
deleted file mode 100644
index d7fabb54..00000000
--- a/static/netbsd/man9/cpu_dumpconf.9 3.html	
+++ /dev/null
@@ -1,69 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPU_DUMPCONF(9)Kernel Developer's ManualCPU_DUMPCONF(9)

-

-

-

-
cpu_dumpconf,
-    cpu_dump, cpu_dumpsize,
-    dumpsys — machine-dependent
-    kernel core dumps

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  cpu_dumpconf(void);

-
int
-  

-  cpu_dump(int
-    (*dump)(dev_t, daddr_t, void *, size_t),
-    daddr_t *blknop);

-
int
-  

-  cpu_dumpsize(void);

-
void
-  

-  dumpsys(void);

-

-

-

-
()
-    is the machine-dependent interface invoked during system bootstrap to
-    determine the dump device and initialize machine-dependent kernel core dump
-    state. Internally, cpu_dumpconf() will invoke
-    cpu_dumpsize() to calculate the size of
-    machine-dependent kernel core dump headers.

-
()
-    is invoked by
-    ()
-    to dump kernel physical memory onto the dump device.
-    dumpsys() invokes cpu_dump()
-    to write the machine-dependent header to the dump device at block number
-    *blknop using the dump device's PIO dump routine
-    specified by the dump argument.

-
(),
-    (),
-    and dumpsys() are parts of the machine-dependent
-    interface, however they are not exported to machine-independent code.

-

-

-

-
cpu_reboot(9)

-

-

-
-  
-    
-    
-  
-
May 24, 2002NetBSD 10.1

diff --git a/static/netbsd/man9/cpu_need_resched.9 3.html b/static/netbsd/man9/cpu_need_resched.9 3.html
deleted file mode 100644
index 4db08d3c..00000000
--- a/static/netbsd/man9/cpu_need_resched.9 3.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPU_NEED_RESCHED(9)Kernel Developer's ManualCPU_NEED_RESCHED(9)

-

-

-

-
cpu_need_resched —
-    context switch notification

-

-

-

-
#include
-    <sys/cpu.h>

-
void
-  

-  cpu_need_resched(struct
-    cpu_info *ci, struct lwp
-    *l, int flags);

-

-

-

-
The
-    ()
-    function is the machine-independent interface for the scheduler to notify
-    machine-dependent code that a context switch from the current LWP
-    l, on the cpu ci, is required.
-    This event may occur if a higher priority LWP appears on the run queue or if
-    the current LWP has exceeded its time slice. l is the
-    last LWP observed running on the CPU. It may no longer be running, as
-    cpu_need_resched() can be called without holding
-    scheduler locks.

-
If the RESCHED_KPREEMPT flag is specified
-    in flags and __HAVE_PREEMPTION
-    C pre-processor macro is defined in
-    <machine/intr.h>,
-    machine-dependent code should make a context switch happen as soon as
-    possible even if the CPU is running in kernel mode. If the
-    RESCHED_KPREEMPT flag is not specified, then
-    RESCHED_UPREEMPT is specified instead.

-
If the RESCHED_IDLE flag is specified in
-    flags, the last thread observed running on the CPU was
-    the idle LWP.

-
If RESCHED_REMOTE
-    flag is specified in flags, the request is not for the
-    current CPU. The opposite also holds true. If ci is
-    not the current processor,
-    ()
-    typically issues an inter processor call to the processor to make it notice
-    the need of a context switch as soon as possible.

-
()
-    is always called with kernel preemption disabled.

-
Typically, the
-    ()
-    function will perform the following operations:

-
    
-  
  • Set a per-processor flag which is checked by userret(9)
-      when returning to user-mode execution.
    • 
-  
  • Post an asynchronous software trap (AST).
    • 
-  
  • Send an inter processor interrupt to wake up
-      cpu_idle(9) and/or force an user process across the
-      user/kernel boundary, thus making a trip through
-      ().
    • 
-

-

-

-

-
sched_4bsd(9), userret(9)

-

-

-
-  
-    
-    
-  
-
November 17, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/cpu_rootconf.9 3.html b/static/netbsd/man9/cpu_rootconf.9 3.html
deleted file mode 100644
index fe371383..00000000
--- a/static/netbsd/man9/cpu_rootconf.9 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
CPU_ROOTCONF(9)Kernel Developer's ManualCPU_ROOTCONF(9)

-

-

-

-
cpu_rootconf,
-    rootconf, setroot —
-    root file system setup

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  cpu_rootconf(void);

-
void
-  

-  rootconf(void);

-
void
-  

-  setroot(device_t
-    bootdv, int
-    bootpartition);

-

-

-

-
The
-    ()
-    is a machine-dependent interface invoked during system bootstrap to
-    determine the root file system device and initialize machine-dependent file
-    system state. cpu_rootconf() provides the global
-    variables booted_device,
-    booted_partition,
-    booted_startblk, booted_nblks,
-    and bootspec. cpu_rootconf
-    invokes the machine-independent function rootconf
-    which calls the function setroot to record the root
-    device and the root partition information for use in machine-independent
-    code.

-
rootconf may adjust the global variables and
-    determines the parameters for setroot. This is for example used to translate
-    a device and partition number provided by the bootloader into a disk wedge
-    device covering the same partition.

-
If the bootloader already identified a disk wedge, it passes a
-    non-zero value for booted_nblks, then
-    booted_startblk and booted_nblks
-    specify a disk wedge as the boot device.

-
setroot evaluates several sources to
-    identify the root device in the following order until a valid device is
-    selected:

-
    
-  
  1. The kernel configuration variable rootspec which is
-      set by config(1). The value is the name and unit of the
-      root device, e.g., "sd0" (disk) or "dk0" (wedge) or
-      "le0" (network) or the prefix "wedge:" followed by the
-      name of the disk wedge. For disk devices the partition passed as argument
-      to setroot is used.
    2. 
-  
  2. The variable bootspec following the same
-    syntax.
    3. 
-  
  3. The result of an interactive query of the root device if
-      boothowto has set the flag
-      RB_ASKNAME. The input uses the same syntax as the
-      previous sources. Here also the kernel dump device is queried.
    4. 
-  
  4. The boot device and partition passed as arguments.
    5. 
-

-
If a root device cannot be selected, setroot
-    sets the RB_ASKNAME flag and loops.

-
Otherwise the kernel dump device is identified in a similar manner
-    from

-
    
-  
  1. The result of a previous interactive query. See above.
    2. 
-  
  2. The kernel configuration variable dumpspec, if
-    set.
    3. 
-  
  3. The second partition of the root device, if it is a regular disk.
    4. 
-  
  4. The first disk wedge device of type DKW_PTYPE_SWAP.
    5. 
-

-

-

-

-
config(1), dk(4),
-    boot(8), boothowto(9)

-

-

-
-  
-    
-    
-  
-
November 11, 2014NetBSD 10.1

diff --git a/static/netbsd/man9/csf.9 3.html b/static/netbsd/man9/csf.9 3.html
deleted file mode 100644
index 4702e2dc..00000000
--- a/static/netbsd/man9/csf.9 3.html	
+++ /dev/null
@@ -1,295 +0,0 @@
-
-  
-    
-    
-    
-  
-
CSF(9)Kernel Developer's ManualCSF(9)

-

-

-

-
CSF — The
-    NetBSD common scheduler framework

-

-

-

-
#include
-    <sys/sched.h>

-
void
-  

-  sched_rqinit(void);

-
void
-  

-  sched_setup(void);

-
void
-  

-  sched_cpuattach(struct
-    cpu_info *);

-
void
-  

-  sched_tick(struct
-    cpu_info *);

-
void
-  

-  sched_schedclock(lwp_t
-    *);

-
bool
-  

-  sched_curcpu_runnable_p(void);

-
lwp_t *
-  

-  sched_nextlwp(void);

-
void
-  

-  sched_enqueue(lwp_t
-    *, bool);

-
void
-  

-  sched_dequeue(lwp_t
-    *);

-
void
-  

-  sched_nice(struct
-    proc *, int);

-
void
-  

-  sched_proc_fork(struct
-    proc *, struct proc
-    *);

-
void
-  

-  sched_proc_exit(struct
-    proc *, struct proc
-    *);

-
void
-  

-  sched_lwp_fork(lwp_t
-    *);

-
void
-  

-  sched_lwp_exit(lwp_t
-    *);

-
void
-  

-  sched_setrunnable(lwp_t
-    *);

-
void
-  

-  sched_print_runqueue(void
-    (*pr)(const char *, ...));

-
void
-  

-  sched_pstats_hook(struct
-    proc *, int);

-
void
-  

-  sched_pstats(void
-    *arg);

-
pri_t
-  

-  sched_kpri(lwp_t
-    *);

-
void
-  

-  resched_cpu(lwp_t
-    *);

-
void
-  

-  setrunnable();

-
void
-  

-  schedclock(lwp_t
-    *);

-
void
-  

-  sched_init(void);

-

-

-

-
CSF provides a modular and self-contained
-    interface for implementing different thread scheduling algorithms. The
-    different schedulers can be selected at compile-time. Currently, the
-    schedulers available are sched_4bsd(9), the traditional
-    4.4BSD thread scheduler, and sched_m2(9) which implements
-    a SVR4/Solaris like approach.

-
The interface is divided into two parts: A set of functions each
-    scheduler needs to implement and common functions used by all
-  schedulers.

-

-

-

-
The following functions have to be implemented by the individual
-    scheduler.

-

-

-

-  
void
-    (struct
-    cpu_info *)

-  
Per-CPU scheduler initialization routine.

-  
void
-    (void)

-  
Initialize the scheduler's runqueue data structures.

-  
void
-    (void)

-  
Setup initial scheduling parameters and kick off timeout driven
-    events.

-

-

-

-

-
Runqueue handling is completely internal to the scheduler. Other
-    parts of the kernel should access runqueues only through the following
-    functions:

-

-  
void
-    (lwp_t
-    *, bool)

-  
Place an LWP within the scheduler's runqueue structures.

-  
void
-    (lwp_t
-    *)

-  
Remove an LWP from the scheduler's runqueue structures.

-  
lwp_t *
-    (void)

-  
Return the LWP that should run the CPU next.

-  
bool
-    (void)

-  
Indicate if there is a runnable LWP for the current CPU.

-  
void
-    (void
-    (*pr)(const char *, ...))

-  
Print runqueues in DDB.

-

-

-

-

-

-  
void
-    (struct
-    cpu_info *)

-  
Periodically called from hardclock(9). Determines if a
-      reschedule is necessary, if the running LWP has used up its quantum.

-  
void
-    (lwp_t
-    *)

-  
Periodically called from
-      ()
-      in order to handle priority adjustment.

-

-

-

-

-

-  
void
-    (struct
-    proc *, int)

-  
Recalculate the process priority according to its nice value.

-

-

-

-

-

-  
void
-    (struct
-    proc *, struct proc *)

-  
Inherit the scheduling history of the parent process after
-      ().

-  
void
-    (struct
-    proc *, struct proc *)

-  
Charge back a processes parent for its resource usage.

-  
void
-    (lwp_t
-    *)

-  
LWP-specific version of the above

-  
void
-    (lwp_t
-    *)

-  
LWP-specific version of the above

-  
void
-    (lwp_t
-    *)

-  
Scheduler-specific actions for
-      ().

-  
void
-    (struct
-    proc *, int)

-  
Scheduler-specific actions for
-      ().

-

-

-

-

-

-

-  
pri_t
-    (lwp_t
-    *)

-  
Scale a priority level to a kernel priority level, usually for an LWP that
-      is about to sleep.

-  
void
-    sched_pstats(void *)

-  
Update process statistics and check CPU resource allocation.

-  
inline void
-    (lwp_t
-    *)

-  
Arrange for a reschedule.

-  
void
-    setrunnable(lwp_t *)

-  
Change process state to be runnable, placing it on a runqueue if it is in
-      memory, awakening the swapper otherwise.

-  
void
-    schedclock(lwp_t *)

-  
Scheduler clock. Periodically called from
-      ().

-  
void
-    (void)

-  
Initialize callout for sched_pstats() and call
-      sched_setup() to initialize any other
-      scheduler-specific data.

-

-

-

-

-
The CSF programming interface is defined
-    within the file sys/sys/sched.h.

-
Functions common to all scheduler implementations are in
-    sys/kern/kern_synch.c.

-
The traditional 4.4BSD scheduler is implemented in
-    sys/kern/sched_4bsd.c.

-
The M2 scheduler is implemented in
-    sys/kern/sched_m2.c.

-

-

-

-
mi_switch(9), preempt(9),
-    sched_4bsd(9), sched_m2(9)

-

-

-

-
The CSF appeared in
-    NetBSD 5.0.

-

-

-

-
The CSF was written by
-    Daniel Sieger
-  ⟨dsieger@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
October 27, 2014NetBSD 10.1

diff --git a/static/netbsd/man9/curproc.9 3.html b/static/netbsd/man9/curproc.9 3.html
deleted file mode 100644
index 17d4ed8c..00000000
--- a/static/netbsd/man9/curproc.9 3.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
CURPROC(9)Kernel Developer's ManualCURPROC(9)

-

-

-

-
curcpu, curlwp,
-    curproc — current processor,
-    thread, and process

-

-

-

-
#include
-    <sys/proc.h>

-
struct cpu_info *
-  

-  curcpu(void);

-
struct proc *curproc;
-  

-  struct lwp *curlwp;

-
#include
-    <sys/cpu.h>

-
bool
-  

-  curcpu_stable(void);

-

-

-

-
The following retrieve the current CPU, process, and thread
-    (lightweight process, or LWP), respectively:

-

-  
()

-  
Returns a pointer to the struct cpu_info structure
-      representing the CPU that the code calling it is running on.
-    
The value of
-        ()
-        is unstable and may be stale as soon as it is read unless the caller
-        prevents preemption by raising the IPL (spl(9),
-        mutex(9)), by disabling preemption
-        (kpreempt_disable(9)), or by binding the thread to its
-        CPU (curlwp_bind(9)).

-    
The function
-        ()
-        can be used in assertions (KASSERT(9)) to verify that
-        curcpu() is stable in the current context.
-        curcpu_stable() MUST NOT be used to make dynamic
-        decisions about whether to query curcpu().

-  

-  

-  
Yields a pointer to the struct proc structure
-      representing the currently running process.
-    
The value of curproc is stable and
-        does not change during execution except in machine-dependent logic to
-        perform context switches, so it works like a global constant, not like a
-        stateful procedure.

-  

-  

-  
Yields a pointer to the struct lwp structure
-      representing the currently running thread.
-    
The value of curlwp is stable and does
-        not change during execution except in machine-dependent logic to perform
-        context switches, so it works like a global constant, not like a
-        stateful procedure.

-  

-

-

-

-

-
The
-    ()
-    macro is defined in the machine-independent
-    machine/cpu.h.

-
The curproc macro is defined in
-    sys/lwp.h.

-
The curlwp macro has a machine-independent
-    definition in sys/lwp.h, but it may be overridden by
-    machine/cpu.h, and must be overridden on
-    architectures supporting multiprocessing and kernel preemption.

-
The
-    ()
-    function is defined in kern/subr_cpu.c.

-

-

-

-
cpu_number(9),
-  proc_find(9)

-

-

-
-  
-    
-    
-  
-
July 8, 2023NetBSD 10.1

diff --git a/static/netbsd/man9/ddc.9 3.html b/static/netbsd/man9/ddc.9 3.html
deleted file mode 100644
index 18a348e1..00000000
--- a/static/netbsd/man9/ddc.9 3.html	
+++ /dev/null
@@ -1,96 +0,0 @@
-
-  
-    
-    
-    
-  
-
DDC(9)Kernel Developer's ManualDDC(9)

-

-

-

-
ddc — VESA Display
-    Data Channel V2

-

-

-

-
#include
-    <dev/i2c/ddcvar.h>

-
int
-  

-  ddc_read_edid(i2c_tag_t tag,
-    uint8_t *dest, size_t len);

-

-

-

-
The
-    ()
-    reads a VESA Extended Display Identification Data block (EDID) via VESA
-    Display Data Channel (DDCv2). DDCv2 is a protocol for data exchange between
-    display devices (such as monitors and flat panels) and host machines using
-    an I2C bus.

-
The tag argument is a machine-dependent tag
-    used to specify the I2C bus on which the DDCv2 device is located. The
-    dest argument is a pointer to a buffer where the EDID
-    data will be stored. The len argument is the amount of
-    data to read into the buffer. (The buffer must be large enough.) Typically,
-    this value will be 128, which is the size of a normal EDID data block.

-
Normally the EDID data block will be
-    post-processed with the
-    ()
-    function.

-

-

-

-
The ddc_read_edid() function returns zero
-    on success, and non-zero otherwise.

-

-

-

-
The ddc_read_edid() function is part of
-    the ddc(4) driver, and is only included in the kernel if
-    that driver is also included.

-

-

-

-
The following code uses ddc_read_edid() to
-    retrieve and print information about a monitor:

-

-

-
	struct edid_info info;
-	i2c_tag_t        tag;
-	char		 buffer[128];
-
-	...
-	/* initialize i2c tag... */
-	...
-	if ((ddc_read_edid(tag, buffer, 128) == 0) &&
-	    (edid_parse(buffer, &info) == 0))
-		edid_print(info);
-	...

-

-
Note that this must be called before the PCI bus is attached
-    during autoconfiguration.

-

-

-

-
ddc(4), edid(9),
-    iic(9)

-

-

-

-
DDCv2 support was added in NetBSD 4.0.

-

-

-

-
Garrett D'Amore
-    <gdamore@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
May 11, 2006NetBSD 10.1

diff --git a/static/netbsd/man9/delay.9 3.html b/static/netbsd/man9/delay.9 3.html
deleted file mode 100644
index 8c4089bf..00000000
--- a/static/netbsd/man9/delay.9 3.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
DELAY(9)Kernel Developer's ManualDELAY(9)

-

-

-

-
delay, DELAY
-    — microsecond delay

-

-

-

-
#include
-    <sys/param.h>

-
void
-  

-  delay(unsigned
-    int us);

-
void
-  

-  DELAY(unsigned
-    int us);

-

-

-

-
Wait approximately us microseconds.

-
The delay is implemented as a machine loop, preventing
-    events other than interrupt handlers for unmasked interrupts to run.
-    () is
-    reentrant (doesn't modify any global kernel or machine state) and is safe to
-    use in interrupt or process context.

-
For long delays, condition variables should be considered, however
-    they can only be used from process context and their resolution is limited
-    by the system clock frequency.

-

-

-

-
condvar(9), hz(9),
-    kpause(9)

-

-

-
-  
-    
-    
-  
-
July 20, 2011NetBSD 10.1

diff --git a/static/netbsd/man9/dksubr.9 3.html b/static/netbsd/man9/dksubr.9 3.html
deleted file mode 100644
index 631fd210..00000000
--- a/static/netbsd/man9/dksubr.9 3.html	
+++ /dev/null
@@ -1,300 +0,0 @@
-
-  
-    
-    
-    
-  
-
DKSUBR(9)Kernel Developer's ManualDKSUBR(9)

-

-

-

-
dk_softc, dk_init,
-    dk_attach, dk_detach,
-    dk_open, dk_close,
-    dk_size, dk_dump,
-    dk_ioctl, dk_strategy,
-    dk_strategy_defer,
-    dk_strategy_pending,
-    dk_start, dk_done,
-    dk_drain, dk_discard,
-    dk_getdefaultlabel,
-    dk_getdisklabel — disk
-    driver subroutines

-

-

-

-
#include
-    <sys/bufq.h>
-  

-  #include <sys/disk.h>
-  

-  #include <dev/dkvar.h>

-
void
-  

-  dk_init(struct
-    dk_softc *,
-    device_t,
-    int dtype);

-
void
-  

-  dk_attach(struct
-    dk_softc *);

-
void
-  

-  dk_detach(struct
-    dk_softc *);

-
int
-  

-  dk_open(struct
-    dk_softc *, dev_t,
-    int flags,
-    int fmt,
-    struct lwp *);

-
int
-  

-  dk_close(struct
-    dk_softc *, dev_t,
-    int flags,
-    int fmt,
-    struct lwp *);

-
int
-  

-  dk_discard(struct
-    dk_softc *, dev_t,
-    off_t pos,
-    off_t len);

-
int
-  

-  dk_size(struct
-    dk_softc *,
-  dev_t);

-
int
-  

-  dk_dump(struct
-    dk_softc *, dev_t,
-    daddr_t blkno,
-    void *vav,
-    size_t size);

-
int
-  

-  dk_ioctl(struct
-    dk_softc *, dev_t,
-    u_long cmd,
-    void *data,
-    int flag,
-    struct lwp *);

-
void
-  

-  dk_strategy(struct
-    dk_softc *, struct buf
-    *);

-
int
-  

-  dk_strategy_defer(struct
-    dk_softc *, struct buf
-    *);

-
int
-  

-  dk_strategy_pending(struct
-    dk_softc *);

-
void
-  

-  dk_start(struct
-    dk_softc *, struct buf
-    *);

-
void
-  

-  dk_done(struct
-    dk_softc *, struct buf
-    *);

-
int
-  

-  dk_drain(struct
-    dk_softc *);

-
void
-  

-  dk_getdefaultlabel(struct
-    dk_softc *, struct
-    disklabel *);

-
void
-  

-  dk_getdisklabel(struct
-    dk_softc *,
-  dev_t);

-

-

-

-
The disk driver subroutines provide common functionality for all
-    disk drivers to reduce the amount of replicated code. For many disk drivers,
-    their corresponding entry points can be made mostly stubs.

-
The subroutines encapsulate data structures found in a driver's
-    softc into

-

-
struct dk_softc {
-	device_t		sc_dev;
-	struct disk		sc_dkdev;
-	struct bufq_state	sc_bufq;
-	krndsource_t		sc_rnd_source;
-...
-}

-

-The dk_softc structure therefore replaces the
-  device_t member of the driver's softc struct.
-
The following is a brief description of each function in the
-    framework:

-

-  
()

-  
Initialize the dk_softc structure.

-  
()

-  
Attach framework after driver has attached the disk(9)
-      subsystem, created a bufq(9) and is ready to handle
-    I/O.

-  
()

-  
Undo dk_attach.

-  
()

-  
Handles open steps for the disk(9) framework, acquires
-      the disklabel and validates open parameters. The driver may provide the
-      d_firstopen callback to handle initialization
-      steps.

-  
()

-  
Handles close steps for the disk(9) framework. The
-      driver may provide the d_lastclose callback to
-      handle finalization steps. dk_open and
-      dk_close are serialized by the openlock
-    mutex.

-  
()

-  
Validates parameters, computes raw block numbers and passes these to the
-      d_discard callback.

-  
()

-  
Returns dump size information from the disklabel(9) and
-      opens and closes the driver when necessary.

-  
()

-  
Validates parameters, computes raw block numbers and iterates over the
-      d_dumpblocks callback in appropriate chunks
-      determined by the d_iosize callback.

-  
()

-  
Handles the ioctls DIOCKLABEL,
-      DIOCWLABEL, DIOCGDEFLABEL,
-      DIOCGSTRATEGY, and
-      DIOCSSTRATEGY and passes other disk ioctls through
-      the disk(9) framework. Returns
-      ENOTTY when an ioctl isn't implemented. This
-      routine is run as a fallback to handle commands that are not specific to
-      the driver.

-  
()

-  
Validates parameters, computes raw block numbers, queues a buffer for I/O
-      and triggers queue processing by calling
-    dk_start.

-  
()

-  
Alternative to dk_strategy that only queues the
-      buffer. Drivers that implement a separate I/O thread can use
-      dk_strategy_defer within their own strategy
-      routine and signal the thread through a private interface.

-  
()

-  
This function is called by an I/O thread to determine if work has been
-      queued by dk_strategy_defer. The driver must then
-      call dk_start to trigger queue processing.

-  
()

-  
If bp != NULL put it into
-      the queue. Run the d_diskstart callback for every
-      buffer until the queue is empty or the callback returns
-      EAGAIN. In the latter case, the buffer is saved
-      and issued on the next queue run. This also calls
-      disk_busy accordingly to handle I/O metrics.

-  
()

-  
Called by the driver when an I/O operation completed.
-      dk_done logs errors, calls
-      disk_unbusy to handle I/O metrics and collects
-      entropy for the cprng(9).

-  
()

-  
Aborts all queued I/O. This function must be called instead of
-      ()
-      to cooperate with dk_start.

-  
()

-  
Compute a common default disklabel for all disk drivers. Some drivers
-      provide device specific information or assign specific disk formats to
-      partitions. Such drivers may implement the d_label
-      callback that is called by dk_getdefaultlabel
-      after initializing the label with common values.

-  
()

-  
Read disklabel with machine dependent low-level function
-      readdisklabel and do sanity checks.

-

-

-

-

-
The driver needs to provide a common set of entry points that are
-    used by the disk driver subroutines and the disk(9)
-    framework.

-

-
struct dkdriver {
-        void    (*d_strategy)(struct buf *);
-        void    (*d_minphys)(struct buf *);
-        int     (*d_open)(dev_t, int, int, struct lwp *);
-        int     (*d_close)(dev_t, int, int, struct lwp *);
-        int     (*d_diskstart)(device_t, struct buf *);
-        void    (*d_iosize)(device_t, int *);
-        int     (*d_dumpblocks)(device_t, void *, daddr_t, int);
-        int     (*d_lastclose)(device_t);
-        int     (*d_discard)(device_t, off_t, off_t);
-        int     (*d_firstopen)(device_t, dev_t, int, int);
-        void    (*d_label)(device_t, struct disklabel *);
-};

-

-

-  
()

-  
The driver strategy routine queues a single buffer for I/O and starts
-      queue processing as appropriate.

-  
()

-  
The driver minphys routine limits the buffer
-      b_bcount to the maximum size for an I/O transfer
-      supported by the driver and hardware. It also calls
-      minphys to apply the platform limit.

-  
()

-  
The driver open routine.

-  
()

-  
The driver close routine.

-  
()

-  
Issues a single I/O request, called by
-    dk_start.

-  
()

-  
Truncate I/O size to the driver limit. This is similar to
-      minphys but operates on an integer value instead
-      of a buffer.

-  
()

-  
Issue a single I/O requests, called by
-    dk_dump.

-  
()

-  
Private cleanup after last user is finished. Often used to flush write
-      caches.

-  
()

-  
Issue a single I/O request to invalidate a disk region.

-  
()

-  
Private initialization when first user opens the driver.

-

-

-

-

-
cgd(4), ld(4),
-    cprng(9), disk(9),
-    driver(9)

-

-

-

-
The NetBSD common disk driver subroutines
-    appeared in NetBSD 2.0 as a base for the
-    cryptographic disk driver and was extended to handle disk wedges in
-    NetBSD 4.0. Most functionality provided by
-    ld(4) was included and extended in NetBSD
-    8.0 to support other disk drivers. The callback interface used by the
-    disk(9) framework has been merged as well.

-

-

-
-  
-    
-    
-  
-
November 28, 2016NetBSD 10.1

diff --git a/static/netbsd/man9/dopowerhooks.9 3.html b/static/netbsd/man9/dopowerhooks.9 3.html
deleted file mode 100644
index 30034aef..00000000
--- a/static/netbsd/man9/dopowerhooks.9 3.html	
+++ /dev/null
@@ -1,51 +0,0 @@
-
-  
-    
-    
-    
-  
-
DOPOWERHOOKS(9)Kernel Developer's ManualDOPOWERHOOKS(9)

-

-

-

-
dopowerhooks — run
-    all power hooks

-

-

-

-
void
-  

-  dopowerhooks(int
-    why);

-

-

-

-

-    dopowerhooks
-    
-    
-    pmf_system_suspend(9)
-    

-
The
-    ()
-    function invokes all power hooks established using the
-    powerhook_establish(9) function. When power is
-    disappearing the power hooks are called in reverse order, i.e., the power
-    hook established last will be called first. When power is restored they are
-    called normal order.

-
This function is called from the apm(4) driver
-    when a power change is detected.

-

-

-

-
powerhook_establish(9)

-

-

-
-  
-    
-    
-  
-
February 11, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/doshutdownhooks.9 3.html b/static/netbsd/man9/doshutdownhooks.9 3.html
deleted file mode 100644
index 4e531af1..00000000
--- a/static/netbsd/man9/doshutdownhooks.9 3.html	
+++ /dev/null
@@ -1,53 +0,0 @@
-
-  
-    
-    
-    
-  
-
DOSHUTDOWNHOOKS(9)Kernel Developer's ManualDOSHUTDOWNHOOKS(9)

-

-

-

-
doshutdownhooks —
-    run all shutdown hooks

-

-

-

-
void
-  

-  doshutdownhooks(void);

-

-

-

-

-    doshutdownhooks
-    
-    
-    pmf_system_shutdown(9)
-    

-
The
-    ()
-    function invokes all shutdown hooks established using the
-    shutdownhook_establish(9) function. Shutdown hooks are
-    called in reverse order, i.e., the shutdown hook established last will be
-    called first.

-
This function is called from
-    ()
-    with interrupts turned off. It is called immediately before the system is
-    halted or rebooted, after file systems have been unmounted, after the clock
-    has been updated, and after a system dump has been done (if necessary).

-

-

-

-
cpu_reboot(9),
-    shutdownhook_establish(9)

-

-

-
-  
-    
-    
-  
-
February 11, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/driver.9 3.html b/static/netbsd/man9/driver.9 3.html
deleted file mode 100644
index e33ab52e..00000000
--- a/static/netbsd/man9/driver.9 3.html	
+++ /dev/null
@@ -1,249 +0,0 @@
-
-  
-    
-    
-    
-  
-
DRIVER(9)Kernel Developer's ManualDRIVER(9)

-

-

-

-
driver —
-    description of a device driver

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/device.h>
-  

-  #include <sys/errno.h>

-
static int
-  

-  foo_match(device_t
-    parent, cfdata_t
-    match, void
-  *aux);

-
static void
-  

-  foo_attach(device_t
-    parent, device_t
-    self, void
-  *aux);

-
static int
-  

-  foo_detach(device_t
-    self, int
-  flags);

-
static int
-  

-  foo_activate(device_t
-    self, enum devact
-    act);

-

-

-

-
This page briefly describes the basic
-    NetBSD autoconfiguration interface used by device
-    drivers. For a detailed overview of the autoconfiguration framework see
-    autoconf(9).

-
Each device driver must present to the system a standard
-    autoconfiguration interface. This interface is provided by the
-    cfattach structure. The interface to the driver is
-    constant and is defined statically inside the driver. For example, the
-    interface to driver ‘foo’ is defined
-    with:

-

-
CFATTACH_DECL_NEW(foo,                  /* driver name */
-        sizeof(struct foo_softc),       /* size of instance data */
-        foo_match,                      /* match/probe function */
-        foo_attach,                     /* attach function */
-        foo_detach,                     /* detach function */
-        foo_activate);                  /* activate function */

-

-
For each device instance controlled by the driver, the
-    autoconfiguration framework allocates a block of memory to record
-    device-instance-specific driver variables. The size of this memory block is
-    specified by the second argument in the
-    CFATTACH_DECL family of macros. The memory block is
-    referred to as the driver's softc structure. The
-    softc structure is only accessed within the driver, so
-    its definition is local to the driver. Nevertheless, the
-    softc structure should adopt the standard
-    NetBSD configuration and naming conventions. For
-    example, the softc structure for driver
-    ‘foo’ is defined with:

-

-
struct foo_softc {
-        device_t sc_dev;                /* generic device info */
-        /* device-specific state */
-};

-

-
If a driver has character device interfaces accessed from
-    userland, the driver must define the cdevsw structure.
-    The structure is constant and is defined inside the driver. For example, the
-    cdevsw structure for driver
-    ‘foo’ can be defined with:

-

-
const struct cdevsw foo_cdevsw {
-        .d_open = fooopen,
-        .d_close = nullclose,
-        .d_read = fooread,
-        .d_write = nowrite,
-        .d_ioctl = fooioctl,
-        .d_stop = nostop,
-        .d_tty = notty,
-        .d_poll = foopoll,
-        .d_mmap = nommap,
-        .d_kqfilter = nokqfilter,
-        .d_discard = nodiscard,
-        .d_flag = D_OTHER | D_MPSAFE,
-};

-

-
The structure variable must be named
-    foo_cdevsw by appending the letters
-    ‘_cdevsw’ to the driver's base name.
-    This convention is mandated by the autoconfiguration framework.

-
If the driver ‘foo’ has also
-    block device interfaces, the driver must define the
-    bdevsw structure. The structure is constant and is
-    defined inside the driver. For example, the bdevsw
-    structure for driver ‘foo’ is defined
-    with:

-

-
const struct bdevsw foo_bdevsw {
-        .d_open = fooopen,
-        .d_close = fooclose,
-        .d_strategy = foostrategy,
-        .d_ioctl = fooioctl,
-        .d_dump = nodump,
-        .d_psize = nosize,
-        .d_flag = D_DISK | D_MPSAFE,
-};

-

-
The structure variable must be named
-    foo_bdevsw by appending the letters
-    ‘_bdevsw’ to the driver's base name.
-    This convention is mandated by the autoconfiguration framework.

-
During system bootstrap, the autoconfiguration
-    framework searches the system for devices. For each device driver, its match
-    function is called (via its cfattach structure) to
-    match the driver with a device instance. The match function is called with
-    three arguments. This first argument parent is a
-    pointer to the driver's parent device structure. The second argument
-    match is a pointer to a data structure describing the
-    autoconfiguration framework's understanding of the driver. Both the
-    parent and match arguments are
-    ignored by most drivers. The third argument aux
-    contains a pointer to a structure describing a potential device-instance. It
-    is passed to the driver from the parent. The match function would type-cast
-    the aux argument to its appropriate attachment
-    structure and use its contents to determine whether it supports the device.
-    Depending on the device hardware, the contents of the attachment structure
-    may contain “locators” to locate the device instance so that
-    the driver can probe it for its identity. If the probe process identifies
-    additional device properties, it may modify the members of the attachment
-    structure. For these devices, the NetBSD convention
-    is to call the match routine
-    ()
-    instead of
-    ()
-    to make this distinction clear. Either way, the match function returns a
-    nonzero integer indicating the confidence of supporting this device and a
-    value of 0 if the driver doesn't support the device. Generally, only a
-    single driver exists for a device, so the match function returns 1 for a
-    positive match.

-
The autoconfiguration framework will call the
-    attach function (via its cfattach structure) of the
-    driver which returns the highest value from its match function. The attach
-    function is called with three arguments. The attach function performs the
-    necessary process to initialise the device for operation. The first argument
-    parent is a pointer to the driver's parent device
-    structure. The second argument self is a pointer to
-    the driver's device structure. The device's softc
-    structure can be obtained from it using the
-    ()
-    function (see disk(9)). The third argument
-    aux is a pointer to the attachment structure. The
-    parent and aux arguments are the
-    same as passed to the match function.

-
The driver's attach function is called
-    before system interrupts are enabled. If interrupts are required during
-    initialisation, then the attach function should make use of
-    ()
-    (see autoconf(9)).

-
Some devices can be removed from the system without requiring a
-    system reboot. The autoconfiguration framework calls the driver's detach
-    function (via its cfattach structure) during device
-    detachment. If the device does not support detachment, then the driver does
-    not have to provide a detach function. The detach function is used to
-    relinquish resources allocated to the driver which are no longer needed. The
-    first argument self is a pointer to the driver's
-    device structure. It is the same structure as passed to the attach function.
-    The second argument flags contains detachment flags.
-    Valid values are DETACH_FORCE (force detachment;
-    hardware gone) and DETACH_QUIET (do not print a
-    notice).

-
The activate function is used by some buses to notify drivers from
-    interrupt context when detachment is imminent, with
-    act set to DVACT_DEACTIVATE.
-    Currently only pcmcia(9) and cardbus(9)
-    use this. If the action is not supported the activate function should return
-    EOPNOTSUPP.

-
Most drivers will want to make use of interrupt facilities.
-    Interrupt locators provided through the attachment structure should be used
-    to establish interrupts within the system. Generally, an interrupt interface
-    is provided by the parent. The interface will require a handler and a
-    driver-specific argument to be specified. This argument is usually a pointer
-    to the device-instance-specific softc structure. When a hardware interrupt
-    for the device occurs the handler is called with the argument. Interrupt
-    handlers should return 0 for “interrupt not for me”, 1 for
-    “I took care of it”, or -1 for “I guess it was mine,
-    but I wasn't expecting it”.

-
For a driver to be compiled into the kernel,
-    config(1) must be aware of its existence. This is done by
-    including an entry in files.<bus> in the directory containing the
-    driver. For example, the driver foo attaching to bus
-    bar with dependency on kernel module
-    baz has the entry:

-

-
device foo: baz
-attach foo at bar
-file dev/bar/foo.c foo

-

-
An entry can now be added to the machine description file:

-
foo*
-  at
-  bar?

-
For device interfaces of a driver to be compiled into the kernel,
-    config(1) must be aware of its existence. This is done by
-    including an entry in
-    majors.⟨arch⟩.
-    For example, the driver foo with character device
-    interfaces, a character major device number cmaj,
-    block device interfaces, a block device major number
-    bmaj and dependency on kernel module
-    baz has the entry:

-
device-major
-  foo char
-  cmaj block
-  bmaj baz

-
For a detailed description of the machine description file and the
-    “device definition” language see
-  config(9).

-

-

-

-
config(1), autoconf(9),
-    config(9), devsw(9),
-    pmf(9)

-

-

-
-  
-    
-    
-  
-
April 30, 2017NetBSD 10.1

diff --git a/static/netbsd/man9/errno.9 3.html b/static/netbsd/man9/errno.9 3.html
deleted file mode 100644
index 3942db0e..00000000
--- a/static/netbsd/man9/errno.9 3.html	
+++ /dev/null
@@ -1,101 +0,0 @@
-
-  
-    
-    
-    
-  
-
ERRNO(9)Kernel Developer's ManualERRNO(9)

-

-

-

-
errno — kernel
-    internal error numbers

-

-

-

-
#include
-    <sys/errno.h>

-

-

-

-
This section provides an overview of the error numbers used
-    internally by the kernel and indicate neither success nor failure. These
-    error numbers are not returned to userland code.

-

-

-

-
Kernel functions that indicate success or failure by means of
-    either 0 or an errno(2) value sometimes have a need to
-    indicate that “special” handling is required at an upper layer
-    or, in the case of ioctl(2) processing, that
-    “nothing was wrong but the request was not handled”. To handle
-    these cases, some negative errno(2) values are defined
-    which are handled by the kernel before returning a different
-    errno(2) value to userland or simply zero.

-
The following is a list of the defined names and their
-    meanings as given in
-    <errno.h>. It is important
-    to note that the value -1 is
-     used, since it is
-    commonly used to indicate generic failure and leaves it up to the caller to
-    determine the action to take.

-

-  
-2 EJUSTRETURN
-    .

-  
No more work is required and the function should just return.

-  
-3 ERESTART
-    .

-  
The system call should be restarted. This typically means that the machine
-      dependent system call trap code will reposition the process's instruction
-      pointer or program counter to re-execute the current system call with no
-      other work required.

-  
-4 EPASSTHROUGH
-    .

-  
The operation was not handled and should be passed through to another
-      layer. This often occurs when processing ioctl(2)
-      requests since lower layer processing may not handle something that
-      subsequent code at a higher level will.

-  
-5 EDUPFD
-    

-  
This error is returned from the device open routine indicating that the
-      l_dupfd field contains the file descriptor
-      information to be returned to the caller, instead of the file descriptor
-      that has been opened already. This error is used by cloning device
-      multiplexors. Cloning device multiplexors open a new file descriptor and
-      associate that file descriptor with the appropriate cloned device. They
-      set l_dupfd to that new file descriptor and return
-      EDUPFD. vn_open(9) takes the
-      file descriptor pointed to by l_dupfd and arranges
-      for it to be copied to the file descriptor that the open call will
-    return.

-  
-6 EMOVEFD
-    

-  
This error is similar to EDUPFD except that the
-      file descriptor in l_dupfd is closed after it has
-      been copied.

-

-

-

-

-
errno(2), ioctl(9)

-

-

-

-
An errno manual page appeared in
-    Version 6 AT&T UNIX. This
-    errno manual page appeared in
-    NetBSD 3.0.

-

-

-
-  
-    
-    
-  
-
December 3, 2004NetBSD 10.1

diff --git a/static/netbsd/man9/evcnt.9 3.html b/static/netbsd/man9/evcnt.9 3.html
deleted file mode 100644
index 5fbf24af..00000000
--- a/static/netbsd/man9/evcnt.9 3.html	
+++ /dev/null
@@ -1,257 +0,0 @@
-
-  
-    
-    
-    
-  
-
EVCNT(9)Kernel Developer's ManualEVCNT(9)

-

-

-

-
evcnt,
-    evcnt_attach_dynamic,
-    evcnt_attach_static,
-    evcnt_detach — generic event
-    counter framework

-

-

-

-
#include
-    <sys/evcnt.h>

-
void
-  

-  evcnt_attach_dynamic(struct
-    evcnt *ev, int
-    type, const struct evcnt
-    *parent, const char
-    *group, const char
-    *name);

-
void
-  

-  evcnt_attach_static(struct
-    evcnt *ev);

-
void
-  

-  evcnt_detach(struct
-    evcnt *ev);

-

-

-

-
The NetBSD generic event counter framework
-    is designed to provide a flexible and hierarchical event counting facility,
-    which is useful for tracking system events (including device
-  interrupts).

-
The fundamental component of this framework is the
-     structure.
-    Its user-accessible fields are:

-

-
struct evcnt {
-	uint64_t	ev_count;	/* how many have occurred */
-	TAILQ_ENTRY(evcnt) ev_list;	/* entry on list of all counters */
-	unsigned char	ev_type;	/* counter type; see below */
-	unsigned char	ev_grouplen;	/* 'group' len, excluding NUL */
-	unsigned char	ev_namelen;	/* 'name' len, excluding NUL */
-	const struct evcnt *ev_parent;	/* parent, for hierarchical ctrs */
-	const char	*ev_group;	/* name of group */
-	const char	*ev_name;	/* name of specific event */
-};

-

-
The system maintains a global linked list of all active event
-    counters. This list, called allevents, may grow or
-    shrink over time as event counters are dynamically added to and removed from
-    the system.

-
Each event counter is marked (in the ev_type
-    field) with the type of event being counted. The following types are
-    currently defined:

-

-

-  

-  
Miscellaneous; doesn't fit into one of the other types.

-  

-  
Interrupt counter, reported by vmstat -i.

-  

-  
Processor trap style events.

-

-

-
Each event counter also has a group name
-    (ev_group) and an event name
-    (ev_name) which are used to identify the counter. The
-    group name may be shared by a set of counters. For example, device interrupt
-    counters would use the name of the device whose interrupts are being counted
-    as the group name. The counter name is meant to distinguish the counter from
-    others in its group (and need not be unique across groups). Both names
-    should be understandable by users, since they are printed by commands like
-    vmstat(1). The constant
-    EVCNT_STRING_MAX is defined to be the maximum group
-    or event name length in bytes (including the trailing
-    NUL). In the current implementation it is 256.

-
To support hierarchical tracking of events, each event counter can
-    name a “parent” event counter. For instance, interrupt
-    dispatch code could have an event counter per interrupt line, and devices
-    could each have counters for the number of interrupts that they were
-    responsible for causing. In that case, the counter for a device on a given
-    interrupt line would have the line's counter as its parent. The value
-    NULL is used to indicate that a counter has no
-    parent. A counter's parent must be attached before the counter is attached,
-    and detached after the counter is detached.

-
The
-    ()
-    macro can be used to provide a static initializer for an event counter
-    structure. It is invoked as
-    EVCNT_INITIALIZER(type,
-    parent, group,
-    name), and its arguments will be placed into the
-    corresponding fields of the event counter structure it is initializing. The
-    group and name arguments must be
-    constant strings.

-

-

-

-
The following is a brief description of each function in the
-    framework:

-

-  
(ev,
-    type, parent,
-    group, name)

-  
Attach the event counter structure pointed to by ev
-      to the system event list. The event counter is cleared and its fields
-      initialized using the arguments to the function call. The contents of the
-      remaining elements in the structure (e.g., the name lengths) are
-      calculated, and the counter is added to the system event list.
-    
The strings specified as the group and counter names must
-        persist (with the same value) throughout the life of the event counter;
-        they are referenced by, not copied into, the counter.

-  

-  
(ev)

-  
Attach the statically-initialized event counter structure pointed to by
-      ev to the system event list. The event counter is
-      assumed to be statically initialized using the
-      EVCNT_INITIALIZER() macro. This function simply
-      calculates structure elements' values as appropriate (e.g., the string
-      lengths), and adds the counter to the system event list.

-  
(ev)

-  
Detach the event counter structure pointed to by ev
-      from the system event list.

-

-
Note that no method is provided to increment the value of an event
-    counter. Code incrementing an event counter should do so by directly
-    accessing its ev_count field in a manner that is known
-    to be safe. For instance, additions to a device's event counters in the
-    interrupt handler for that device will often be safe without additional
-    protection (because interrupt handler entries for a given device have to be
-    serialized). However, for other uses of event counters, additional locking
-    or use of machine-dependent atomic operation may be appropriate. (The
-    overhead of using a mechanism that is guaranteed to be safe to increment
-    every counter, regardless of actual need for such a mechanism where the
-    counter is being incremented, would be too great. On some systems, it might
-    involve a global lock and several function calls.)

-

-

-

-
This section includes a description on basic use of the framework
-    and example usage of its functions.

-
Device drivers can use the
-    evcnt_attach_dynamic() and
-    evcnt_detach() functions to manage device-specific
-    event counters. Statically configured system modules can use
-    evcnt_attach_static() to configure global event
-    counters. Similarly, loadable modules can use
-    evcnt_attach_static() to configure their global
-    event counters, evcnt_attach_dynamic() to attach
-    device-specific event counters, and evcnt_detach()
-    to detach all counters when being unloaded.

-
Device drivers that wish to use the generic event counter
-    framework should place event counter structures in their
-    “softc” structures. For example, to keep track of the number
-    of interrupts for a given device (broken down further into “device
-    readable” and “device writable” interrupts) a device
-    driver might use:

-

-
struct foo_softc {
-	[ . . . ]
-	struct evcnt sc_ev_intr;	/* interrupt count */
-	struct evcnt sc_ev_intr_rd;	/* 'readable' interrupt count */
-	struct evcnt sc_ev_intr_wr;	/* 'writable' interrupt count */
-	[ . . . ]
-};

-

-
In the device attach function, those counters would be registered
-    with the system using the evcnt_attach_dynamic()
-    function, using code like:

-

-
void
-fooattach(device_t parent, device_t self, void *aux)
-{
-	struct foo_softc *sc = device_private(self);
-
-	[ . . . ]
-
-	/* Initialize and attach event counters. */
-	evcnt_attach_dynamic(&sc->sc_ev, EVCNT_TYPE_INTR,
-	    NULL, device_xname(self), "intr");
-	evcnt_attach_dynamic(&sc->sc_ev_rd, EVCNT_TYPE_INTR,
-	    &sc->sc_ev, device_xname(self), "intr rd");
-	evcnt_attach_dynamic(&sc->sc_ev_wr, EVCNT_TYPE_INTR,
-	    &sc->sc_ev, device_xname(self), "intr wr");
-
-	[ . . . ]
-}

-

-
If the device can be detached from the system, its detach function
-    should invoke evcnt_detach() on each attached
-    counter (making sure to detach any “parent” counters only
-    after detaching all children).

-
Code like the following might be used to initialize a static event
-    counter (in this example, one used to track CPU alignment traps):

-

-
	struct evcnt aligntrap_ev = EVCNT_INITIALIZER(EVCNT_TYPE_MISC,
-	    NULL, "cpu", "aligntrap")

-

-
To attach this event counter, code like the following could be
-    used:

-

-
	evcnt_attach_static(&aligntrap_ev);

-

-

-

-

-
The event counter framework itself is implemented within the file
-    sys/kern/subr_evcnt.c. Data structures and function
-    prototypes for the framework are located in
-    sys/sys/device.h.

-
Event counters are used throughout the system.

-
The vmstat(1) source file
-    usr.bin/vmstat/vmstat.c shows an example of how to
-    access event counters from user programs.

-

-

-

-
vmstat(1)

-

-

-

-
A set of interrupt counter interfaces with similar names to the
-    interfaces in the NetBSD generic event counter
-    framework appeared as part of the new autoconfiguration system in
-    4.4BSD. Those interfaces were never widely adopted
-    in NetBSD because of limitations in their
-    applicability. (Their use was limited to non-hierarchical, dynamically
-    attached device interrupt counters.) The NetBSD
-    generic event counter framework first appeared in NetBSD
-    1.5.

-

-

-

-
The NetBSD generic event counter framework
-    was designed and implemented by Chris Demetriou
-    ⟨cgd@NetBSD.org⟩.

-

-

-
-  
-    
-    
-  
-
January 14, 2011NetBSD 10.1

diff --git a/static/netbsd/man9/fileassoc.9 3.html b/static/netbsd/man9/fileassoc.9 3.html
deleted file mode 100644
index d4c28048..00000000
--- a/static/netbsd/man9/fileassoc.9 3.html	
+++ /dev/null
@@ -1,338 +0,0 @@
-
-  
-    
-    
-    
-  
-
FILEASSOC(9)Kernel Developer's ManualFILEASSOC(9)

-

-

-

-
fileassoc —
-    in-kernel, file system independent, file meta-data
-    association

-

-

-

-
#include
-    <sys/fileassoc.h>

-
int
-  

-  fileassoc_register(const
-    char *name,
-    fileassoc_cleanup_cb_t
-    cleanup_cb, fileassoc_t
-    *result);

-
int
-  

-  fileassoc_deregister(fileassoc_t
-    id);

-
void *
-  

-  fileassoc_lookup(struct
-    vnode *vp, fileassoc_t
-    id);

-
int
-  

-  fileassoc_table_delete(struct
-    mount *mp);

-
int
-  

-  fileassoc_table_clear(struct
-    mount *mp, fileassoc_t
-    id);

-
int
-  

-  fileassoc_table_run(struct
-    mount *mp, fileassoc_t
-    id, fileassoc_cb_t
-    cb, void
-  *cookie);

-
int
-  

-  fileassoc_file_delete(struct
-    vnode *vp);

-
int
-  

-  fileassoc_add(struct
-    vnode *vp, fileassoc_t
-    id, void
-  *data);

-
int
-  

-  fileassoc_clear(struct
-    vnode *vp, fileassoc_t
-    id);

-

-

-

-
The fileassoc KPI allows association of
-    meta-data with files independent of file system support for such elaborate
-    meta-data.

-
When plugging a new fileassoc to the system, a developer can
-    specify private data to be associated with every file, as well as
-    (potentially different) private data to be associated with every file system
-    mount.

-
For example, a developer might choose to associate a custom ACL
-    with every file, and a count of total files with ACLs with the mount.

-

-

-

-
Designed with simplicity in mind, the
-    fileassoc KPI usually accepts four different types
-    of parameters to the most commonly used routines:

-

-  
struct mount * mp

-  
Describing a mount on which to take action.

-  
struct vnode * vp

-  
Describing a file on which to take action.

-  
fileassoc_t
-    id

-  
Describing an id, as returned from a successful call to
-      ().

-  
void * data

-  
Describing a custom private data block, attached to either a file or a
-      mount.

-

-
Before using the fileassoc KPI it is
-    important to keep in mind that the interface provides memory management only
-    for fileassoc internal memory. Any additional memory
-    stored in the tables (such as private data structures used by custom
-    fileassocs) should be allocated and freed by the developer.

-
fileassoc
-    provides the ability to specify a “cleanup” routine to
-    ()
-    (see below) to be called whenever an entry for a file or a mount is
-  deleted.

-

-

-
These routines allow a developer to allocate a
-    fileassoc slot to be used for private data.

-

-  
fileassoc_register(name,
-    cleanup_cb, result)

-  
Registers a new fileassoc as name, and returns a
-      fileassoc_t via result to be
-      used as identifier in subsequent calls to the
-      fileassoc subsystem.
-    
()
-        returns zero on success. Otherwise, an error number will be
-      returned.

-    
If cleanup_cb is not
-        NULL, it will be called during delete/clear
-        operations (see routines below) with indication whether the passed data
-        is file- or mount-specific.

-    
cleanup_cb should be a function
-        receiving a void * and returning
-        void. See the
-        EXAMPLES section for
-      illustration.

-  

-  
(id)

-  
Deregisters a fileassoc whose id is
-      id.
-    
Note that calling
-        ()
-        only frees the associated slot in the fileassoc
-        subsystem. It is up to the developer to take care of garbage
-      collection.

-  

-

-

-

-

-
These routines allow lookup of fileassoc
-    mounts, files, and private data attached to them.

-

-  
(vp,
-    id)

-  
Returns the private data for the file/id combination or
-      NULL if not found.

-

-

-

-

-

-  
(mp)

-  
Deletes a fileassoc table for mp.

-  
(mp,
-    id)

-  
Clear all table entries for fileassoc from
-      mp.
-    
If specified, the fileassoc's “cleanup routine”
-        will be called with a pointer to the private data structure.

-  

-  
(mp,
-    id, cb,
-    cookie)

-  
For each entry for id, call cb
-      with the entry being the first argument, and cookie
-      being the second argument.
-    
cb is a function returning
-        void and receiving two void
-        * parameters.

-  

-

-

-

-

-

-  
(vp)

-  
Delete the fileassoc entries for vp.
-    
If specified, the “cleanup routines” of all
-        fileassoc types added will be called with a pointer to the corresponding
-        private data structure and indication of
-        FILEASSOC_CLEANUP_FILE.

-  

-

-

-

-

-

-  
(vp,
-    id, data)

-  
Add private data in data for
-      vp, for the fileassoc specified by
-      id.
-    
If a table for the mount-point vp is on
-        doesn't exist, one will be created automatically.
-        fileassoc manages internally the optimal table
-        sizes as tables are modified.

-  

-  
(vp,
-    id)

-  
Clear the private data for vp, for the fileassoc
-      specified by id.
-    
If specified, the fileassoc's “cleanup routine”
-        will be called with a pointer to the private data structure and
-        indication of FILEASSOC_CLEANUP_FILE.

-  

-

-

-

-

-

-
The following code examples should give you a clue on using
-    fileassoc for your purposes.

-
First, we'll begin with registering a new id. We need to do that
-    to save a slot for private data storage with each mount and/or file:

-

-
fileassoc_t myhook_id;
-int error;
-
-error = fileassoc_register("my_hook", myhook_cleanup, &myhook_id);
-if (error != 0)
-	...handle error...

-

-
In the above example we pass a
-    myhook_cleanup() routine. It could look something
-    like this:

-

-
void
-myhook_cleanup(void *data)
-{
-
-	printf("Myhook: Removing entry for file.\n");
-	...handle file entry removal...
-	free(data, M_TEMP);
-}

-

-
Another useful thing would be to add our private data to a file.
-    For example, let's assume we keep a custom ACL with each file:

-

-
int
-myhook_acl_add(struct vnode *vp, struct myhook_acl *acl)
-{
-	int error;
-
-	error = fileassoc_add(vp, myhook_id, acl);
-	if (error) {
-		printf("Myhook: Could not add ACL.\n");
-		...handle error...
-	}
-
-	printf("Myhook: Added ACL.\n");
-
-	return (0);
-}

-

-
Adding an entry will override any entry that previously
-  exists.

-
Whatever your plug is, eventually you'll want to access the
-    private data you store with each file. To do that you can use the
-  following:

-

-
int
-myhook_acl_access(struct vnode *vp, int access_flags)
-{
-	struct myhook_acl *acl;
-
-	acl = fileassoc_lookup(vp, myhook_id);
-	if (acl == NULL)
-		return (0);
-
-	error = myhook_acl_eval(acl, access_flags);
-	if (error) {
-		printf("Myhook: Denying access based on ACL decision.\n");
-		return (error);
-	}
-
-	return (0);
-}

-

-
And, in some cases, it may be desired to remove private data
-    associated with an file:

-

-
int error;
-
-error = fileassoc_clear(vp, myhook_id);
-if (error) {
-	printf("Myhook: Error occurred during fileassoc removal.\n");
-	...handle error...
-}

-

-
As mentioned previously, the call to
-    fileassoc_clear() will result in a call to the
-    “cleanup routine” specified in the initial call to
-    fileassoc_register().

-
The above should be enough to get you started.

-
For example usage of fileassoc, see the
-    Veriexec code.

-

-

-

-
The fileassoc is implemented within
-    src/sys/kern/kern_fileassoc.c.

-

-

-

-
veriexec(9)

-

-

-

-
The fileassoc KPI first appeared in
-    NetBSD 4.0.

-

-

-

-
Elad Efrat
-    <elad@NetBSD.org>
-  

-  Brett Lymn
-    <blymn@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
December 1, 2016NetBSD 10.1

diff --git a/static/netbsd/man9/firmload.9 3.html b/static/netbsd/man9/firmload.9 3.html
deleted file mode 100644
index b402b742..00000000
--- a/static/netbsd/man9/firmload.9 3.html	
+++ /dev/null
@@ -1,151 +0,0 @@
-
-  
-    
-    
-    
-  
-
FIRMLOAD(9)Kernel Developer's ManualFIRMLOAD(9)

-

-

-

-
firmload —
-    Firmware loader API for device drivers

-

-

-

-
#include
-    <dev/firmload.h>

-
int
-  

-  firmware_open(const
-    char *drvname, const char
-    *imgname,
-    firmware_handle_t
-  *fhp);

-
int
-  

-  firmware_close(firmware_handle_t
-    fh);

-
off_t
-  

-  firmware_get_size(firmware_handle_t
-    fh);

-
int
-  

-  firmware_read(firmware_handle_t
-    fh, off_t offset,
-    void *buf,
-    size_t size);

-
void *
-  

-  firmware_malloc(size_t
-    size);

-
void
-  

-  firmware_free(void
-    *buf, size_t
-  size);

-

-

-

-
firmload provides a simple and convenient
-    API for device drivers to load firmware images from files residing in the
-    file system that are necessary for the devices that they control. Firmware
-    images reside in sub-directories, one for each driver, of a series of
-    colon-separated path prefixes specified by the sysctl variable
-    hw.firmware.path.

-

-

-

-
The following functions are provided by the
-    firmload API:

-

-  
(drvname,
-    imgname, fhp)

-  

-    
Open the firmware image
-        imgname for the driver
-        drvname. The path to the firmware image file is
-        constructed by appending the string “/drvname/imgname” to
-        each configured path prefix until opening the firmware image file
-        succeeds. Upon success,
-        ()
-        returns 0 and stores a firmware image handle in the location pointed to
-        by fhp. Otherwise, an error code is returned to
-        indicate the reason for failure.

-  

-  
(fh)

-  

-    
Close the firmware image file associated with the firmware
-        handle fh. Returns 0 upon success or an error code
-        to indicate the reason for failure.

-  

-  
(fh)

-  

-    
Returns the size of the image file associated with the
-        firmware handle fh.

-  

-  
(fh,
-    offset, buf,
-    size)

-  

-    
Reads from the image file associated with the firmware handle
-        fh beginning at offset
-        offset for length size. The
-        firmware image data is placed into the buffer specified by
-        buf. Returns 0 upon success or an error code to
-        indicate the reason for failure.

-  

-  
(size)

-  

-    
Allocates a region of wired kernel
-        memory of size size. Note:
-        ()
-        may block.

-  

-  
(buf,
-    size)

-  

-    
Frees a region of memory previously
-        allocated by
-        ().

-  

-

-

-

-

-
Default search path for firmware

-

-  
/libdata/firmware

-  
 

-  
/usr/libdata/firmware

-  
 

-  
/usr/pkg/libdata/firmware

-  
 

-  
/usr/pkg/libdata

-  
 

-

-

-

-

-
autoconf(9), malloc(9),
-    vnsubr(9)

-

-

-

-
The firmload framework first appeared in
-    NetBSD 4.0.

-

-

-

-
Jason Thorpe
-    <thorpej@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
March 16, 2018NetBSD 10.1

diff --git a/static/netbsd/man9/flash.9 3.html b/static/netbsd/man9/flash.9 3.html
deleted file mode 100644
index 721e2898..00000000
--- a/static/netbsd/man9/flash.9 3.html	
+++ /dev/null
@@ -1,75 +0,0 @@
-
-  
-    
-    
-    
-  
-
FLASH(9)Kernel Developer's ManualFLASH(9)

-

-

-

-
flash — subsystem
-    for flash-like memory devices

-

-

-

-
#include
-    <dev/flash/flash.h>

-
device_t
-  

-  flash_attach_mi(const
-    struct flash_interface *fl,
-    device_t dev);

-

-

-

-
Flash-like devices can register themselves to the
-    flash layer with the
-    flash_hw_if structure. This structure has function
-    pointers and other fields.

-
The attachment can be done by calling
-    ()
-    with this structure and the device's device_t as an
-    argument. Return value is the flash layer device. The
-    flash_interface structure is shown below.

-

-
struct flash_interface {
-	int (*erase) (device_t, struct flash_erase_instruction *);
-	int (*read) (device_t, off_t, size_t, size_t *, uint8_t *);
-	int (*write) (device_t, off_t, size_t, size_t *, const uint8_t *);
-	int (*block_markbad)(device_t, uint64_t);
-	int (*block_isbad)(device_t, uint64_t);
-	int (*sync) (device_t);
-
-	int (*submit)(device_t, struct buf *);
-
-	/* storage for partition info */
-	struct flash_partition partition;
-
-	/* total size of mtd */
-	flash_addr_t size;
-	uint32_t page_size;
-	uint32_t erasesize;
-	uint32_t writesize;
-	uint32_t minor;
-	uint8_t	type;
-};

-

-

-

-

-
flash(4), nand(9)

-

-

-

-
Adam Hoka
-    <ahoka@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
March 31, 2011NetBSD 10.1

diff --git a/static/netbsd/man9/fstrans.9 3.html b/static/netbsd/man9/fstrans.9 3.html
deleted file mode 100644
index 9de74e53..00000000
--- a/static/netbsd/man9/fstrans.9 3.html	
+++ /dev/null
@@ -1,307 +0,0 @@
-
-  
-    
-    
-    
-  
-
FSTRANS(9)Kernel Developer's ManualFSTRANS(9)

-

-

-

-
fstrans,
-    fstrans_setstate,
-    fstrans_getstate,
-    fstrans_start,
-    fstrans_start_nowait,
-    fstrans_start_lazy,
-    fstrans_done,
-    fstrans_is_owner,
-    fscow_establish,
-    fscow_disestablish,
-    fscow_run — file system
-    suspension helper subsystem

-

-

-

-
#include
-    <sys/mount.h>
-  

-  #include <sys/fstrans.h>

-
void
-  

-  fstrans_start(struct
-    mount *mp);

-
int
-  

-  fstrans_start_nowait(struct
-    mount *mp);

-
void
-  

-  fstrans_start_lazy(struct
-    mount *mp);

-
void
-  

-  fstrans_done(struct
-    mount *mp);

-
int
-  

-  fstrans_setstate(struct
-    mount *mp, enum
-    fstrans_state new_state);

-
enum fstrans_state
-  

-  fstrans_getstate(struct
-    mount *mp);

-
int
-  

-  fstrans_is_owner(struct
-    mount *mp);

-
int
-  

-  fscow_establish(struct
-    mount *mp, int
-    (*func)(void *, struct buf *, bool),
-    void *cookie);

-
int
-  

-  fscow_disestablish(struct
-    mount *mp, int
-    (*func)(void *, struct buf *, bool),
-    void *cookie);

-
int
-  

-  fscow_run(struct
-    buf *bp, bool
-    data_valid);

-

-

-

-
The fstrans subsystem assists file system
-    suspension and copy-on-write snapshots.

-
The file system's normal operations, such as
-    its vnodeops(9), must be bracketed by
-    ()
-    and fstrans_done() in a
-    
-    transaction, which is blocked by suspending the file system and while it is
-    suspended.

-
Operations needed while suspending the
-    file system must be bracketed by
-    ()
-    and fstrans_done() in a
-    
-    transaction, which is allowed while suspending the file system, but blocked
-    while the file system is suspended.

-
Transactions are per-thread and nestable: if
-    a thread is already in a transaction, it can enter another transaction
-    without blocking. Each
-    ()
-    must be paired with fstrans_done(). Transactions for
-    multiple distinct mount points may not be nested.

-
The file system's
-    VFS_SUSPENDCTL(9) method can use
-    ()
-    to:

-
    
-  
  • enter the FSTRANS_SUSPENDING state to suspend all
-      normal operations but allow lazy transactions,
    • 
-  
  • enter the FSTRANS_SUSPENDED state to suspend all
-      operations, and
    • 
-  
  • restore to the FSTRANS_NORMAL state to resume all
-      operations.
    • 
-

-
A file system supporting
-    fstrans may establish a copy-on-write callback with
-    ().
-    The copy-on-write callback will be called every time a buffer is written to
-    a block device with
-    ()
-    and every time a buffer is read into the buffercache(9)
-    with B_MODIFY set indicating the caller's intent to
-    modify it. Anyone modifying a buffer may additionally use
-    fscow_run() to explicitly invoke the established
-    callback. The copy-on-write callback must be disestablished with
-    fscow_disestablish() when the file system is done
-    with it.

-

-

-

-

-  
fstrans_start(mp)

-  
Enter a transaction on the file system mp in the
-      current thread. If the file system is in a state that blocks such
-      transactions, wait until it changes state to one that does not.
-    
If the file system is suspended, wait until it is resumed.

-    
However, if the current thread is already
-        in a transaction on mp,
-        ()
-        will enter a nested transaction and return immediately without
-      waiting.

-    
May sleep.

-  

-  
(mp)

-  
Like fstrans_start(), but return
-      EBUSY immediately if transactions are blocked in
-      its current state.
-    
May sleep nevertheless on internal locks.

-  

-  
(mp)

-  
Like fstrans_start(), but will not block while
-      suspending.
-    
May sleep.

-  

-  
(mp)

-  
End the current transaction on mp.

-  
fstrans_getstate(mp)

-  
Return the current state of the file system mp.
-    
Must be called within a transaction for the answer to be
-        stable.

-  

-  
(mp,
-    new_state)

-  
Change the state of the file system mp to
-      new_state, and wait for all transactions not allowed
-      in new_state to complete.
-    

-      

-      
Allow all transactions.

-      

-      
Block FSTRANS_SHARED transactions but allow
-          FSTRANS_LAZY transactions.

-      

-      
Block all transactions.

-    

-    
A thread that changes a file system to a
-        state other than FSTRANS_NORMAL enters a
-        transaction for the purposes of
-        ()
-        until it changes state back to
-      FSTRANS_NORMAL.

-    
Additionally, a thread that changes a
-        file system to a state other than FSTRANS_NORMAL
-        acquires an exclusive lock on the file system state, so that
-        ()
-        will return true in that thread, and no other thread can change the file
-        system's state until the owner restores it to
-        FSTRANS_NORMAL.

-    
May sleep, and may be interrupted by a
-        signal. On success, return zero. On failure, restore the file system to
-        the FSTRANS_NORMAL state and return an error
-        code.
-        ()
-        never fails if new_state is
-        FSTRANS_NORMAL.

-  

-  
fstrans_is_owner(mp)

-  
Return true if the current thread is currently
-      suspending the file system mp.

-  
fscow_establish(mp,
-    func, cookie)

-  
Establish a copy-on-write callback for the file system
-      mp. The function func will be
-      called for every buffer bp written through this file
-      system as
-    
func(cookie,
-      bp, data_valid

-    ) where data_valid is true if and only if the buffer
-      bp has not yet been modified.
-    
May sleep.

-  

-  
(mp,
-    func, cookie)

-  
Disestablish a copy-on-write callback established with
-      fscow_establish().
-    
May sleep.

-  

-  
(bp,
-    data_valid)

-  
Run all copy-on-write callbacks established for the file system this
-      buffer belongs to, if they have not already been run for this buffer. If
-      data_valid is true the
-      buffer data has not yet been modified.
-    
May sleep.

-  

-

-

-

-

-
The following is an example of a file system suspend
-  operation.

-

-
int
-xxx_suspendctl(struct mount *mp, int cmd)
-{
-	int error;
-
-	switch (cmd) {
-	case SUSPEND_SUSPEND:
-		error = fstrans_setstate(mp, FSTRANS_SUSPENDING);
-		if (error)
-			return error;
-		return fstrans_setstate(mp, FSTRANS_SUSPENDED);
-
-	case SUSPEND_RESUME:
-		return fstrans_setstate(mp, FSTRANS_NORMAL);
-
-	default:
-		return EINVAL;
-	}
-}

-

-
This is an example of a file system operation.

-

-
int
-xxx_create(void *v)
-{
-	struct vop_create_args *ap = v;
-	struct mount *mp = ap->a_dvp->v_mount;
-	int error;
-
-	fstrans_start(mp);
-
-	/* Actually create the node. */
-
-	fstrans_done(mp);
-
-	return 0;
-}

-

-

-

-

-
The fstrans subsystem is implemented in
-    the file sys/kern/vfs_trans.c.

-

-

-

-
vfs_resume(9),
-  vfs_suspend(9)

-

-

-

-
The fstrans subsystem appeared in
-    NetBSD 5.0.

-

-

-

-
The fstrans subsystem was written by
-    Jürgen Hannken-Illjes
-    ⟨hannken@NetBSD.org⟩.

-

-

-

-
fstrans is useful only for temporary
-    suspension — it does not help to permanently block file system
-    operations for unmounting, because fstrans_start()
-    cannot fail.

-

-

-
-  
-    
-    
-  
-
October 4, 2018NetBSD 10.1

diff --git a/static/netbsd/man9/genfs.9 3.html b/static/netbsd/man9/genfs.9 3.html
deleted file mode 100644
index 599f3fb9..00000000
--- a/static/netbsd/man9/genfs.9 3.html	
+++ /dev/null
@@ -1,137 +0,0 @@
-
-  
-    
-    
-    
-  
-
GENFS(9)Kernel Developer's ManualGENFS(9)

-

-

-

-
genfs — genfs
-    routines

-

-

-

-
#include
-    <miscfs/genfs/genfs.h>

-
int
-  

-  genfs_can_chflags(vnode_t
-    *vp, kauth_cred_t,
-    cred",
-    uid_t owner_uid,
-    bool
-  changing_sysflags);

-
int
-  

-  genfs_can_chmod(vnode_t
-    *vp, kauth_cred_t
-    cred, uid_t
-    cur_uid, gid_t
-    cur_gid, mode_t
-    new_mode);

-
int
-  

-  genfs_can_chown(vnode_t
-    *vp, kauth_cred_t
-    cred, uid_t
-    cur_uid, gid_t
-    cur_gid, uid_t
-    new_uid, gid_t
-    new_gid);

-
int
-  

-  genfs_can_chtimes(vnode_t
-    *vp, kauth_cred_t
-    cred, uid_t
-    owner_uid, u_int
-    vaflags);

-
int
-  

-  genfs_can_extattr(vnode_t
-    *vp, kauth_cred_t
-    cred, accmode_t
-    accmode, int
-    attrnamespace);

-
int
-  

-  genfs_can_sticky(vnode_t
-    *vp, kauth_cred_t
-    cred, uid_t
-    dir_uid, uid_t
-    file_uid);

-

-

-

-
The functions documented here are general routines for internal
-    use in file systems to implement common policies for performing various
-    operations. The developer must understand that these routines implement no
-    system-wide policies and only take into account the object being accessed
-    and the nominal values of the credentials accessing it.

-
In other words, these functions are not meant to be called
-    directly. They are intended to be used in kauth(9) vnode
-    scope authorization calls, for providing the fall-back file system
-  decision.

-
As a rule of thumb, code that looks like this is wrong:

-

-
error = genfs_can_foo(...); /* WRONG */

-

-
While code that looks like this is right:

-

-
error = kauth_authorize_vnode(..., genfs_can_foo(...));

-

-

-

-

-

-  
(vnode_t
-    *vp, kauth_cred_t cred)

-  
"uid_t owner_uid" "bool changing_sysflags" Implements
-      chflags(2) policy.

-  
(vnode_t
-    *vp, kauth_cred_t cred, uid_t
-    cur_uid, gid_t cur_gid, mode_t
-    new_mode)

-  
Implements chmod(2) policy.

-  
(vnode_t
-    *vp, kauth_cred_t cred, uid_t
-    cur_uid, gid_t cur_gid, uid_t
-    new_uid, gid_t new_gid)

-  
Implements chown(2) policy.

-  
(vnode_t
-    *vp, kauth_cred_t cred, uid_t
-    owner_uid, u_int vaflags)

-  
Implements utimes(2) policy.

-  
(vnode_t
-    *vp, kauth_cred_t cred,
-    accmode_t accmode, int
-    attrnamespace)

-  
Implements extended attributes access policy.

-  
(vnode_t
-    *vp, kauth_cred_t cred, uid_t
-    dir_uid, uid_t file_uid)

-  
Implements rename and delete policy from sticky directories.

-

-

-

-

-
genfs_can_access(9),
-    genfs_can_access_acl_nfs4(9),
-    genfs_can_access_acl_posix1e(9),
-    genfs_rename(9), kauth(9)

-

-

-

-
Elad Efrat
-    <elad@NetBSD.org>
-    wrote this manual page.

-

-

-
-  
-    
-    
-  
-
January 17, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/genfs_can_access.9 3.html b/static/netbsd/man9/genfs_can_access.9 3.html
deleted file mode 100644
index 1671198e..00000000
--- a/static/netbsd/man9/genfs_can_access.9 3.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
GENFS_CAN_ACCESS(9)Kernel Developer's ManualGENFS_CAN_ACCESS(9)

-

-

-

-
genfs_can_access —
-    generate an access control decision using vnode
-    parameters

-

-

-

-
#include
-    <miscfs/genfs/genfs.h>

-
int
-  

-  genfs_can_access(vnode_t *vp,
-    kauth_cred_t cred, uid_t
-    file_uid, gid_t file_gid, mode_t
-    file_mode, struct acl *acl,
-    accmode_t accmode);

-

-

-

-
This call implements the logic for the
-    UNIX discretionary file security model common to
-    many file systems in FreeBSD. It accepts the vnode
-    vp, requesting credential cred,
-    permissions via owning UID file_uid, owning GID
-    file_gid, file permissions
-    file_mode, access ACL for the file
-    acl, desired access mode
-    accmode,

-
This call is intended to support implementations of
-    VOP_ACCESS(9), which will use their own access methods to
-    retrieve the vnode properties, and then invoke
-    ()
-    in order to perform the actual check. Implementations of
-    VOP_ACCESS(9) may choose to implement additional security
-    mechanisms whose results will be composed with the return value.

-
The algorithm used by
-    ()
-    selects a component of the file permission bits based on comparing the
-    passed credential, file owner, and file group. If the credential's effective
-    UID matches the file owner, then the owner component of the permission bits
-    is selected. If the UID does not match, then the credential's effective GID,
-    followed by additional groups, are compared with the file group—if
-    there is a match, then the group component of the permission bits is
-    selected. If neither the credential UID or GIDs match the passed file owner
-    and group, then the other component of the permission bits is selected.

-
Once appropriate protections are selected for the current
-    credential, the requested access mode, in combination with the vnode type,
-    will be compared with the discretionary rights available for the credential.
-    If the rights granted by discretionary protections are insufficient, then
-    super-user privilege, if available for the credential, will also be
-    considered.

-

-

-

-
genfs_can_access() will return 0 on
-    success, or a non-zero error value on failure.

-

-

-

-

-  
[]

-  
Permission denied. An attempt was made to access a file in a way forbidden
-      by its file access permissions.

-  
[]

-  
Operation not permitted. An attempt was made to perform an operation
-      limited to processes with appropriate privileges or to the owner of a file
-      or other resource.

-

-

-

-

-
genfs(9),
-    genfs_can_access_acl_nfs4(9),
-    genfs_can_access_acl_posix1e(9),
-    vnode(9), VOP_ACCESS(9)

-

-

-

-
This manual page and the current implementation of
-    vaccess() were written by Robert
-    Watson.

-

-

-
-  
-    
-    
-  
-
January 17, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/hardclock.9 3.html b/static/netbsd/man9/hardclock.9 3.html
deleted file mode 100644
index c0c53cc3..00000000
--- a/static/netbsd/man9/hardclock.9 3.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
HARDCLOCK(9)Kernel Developer's ManualHARDCLOCK(9)

-

-

-

-
hardclock —
-    real-time timer

-

-

-

-
void
-  

-  hardclock(struct
-    clockframe *frame);

-

-

-

-
The
-    ()
-    function is called hz(9) times per second. It implements
-    the real-time system clock. The argument frame is an
-    opaque, machine-dependent structure that encapsulates the previous machine
-    state.

-
The
-    ()
-    performs different tasks such as:

-
    
-  
  • Run the current process's virtual and profile time (decrease the
-      corresponding timers, if they are activated, and generate
-      SIGVTALRM or SIGPROF,
-      respectively).
    • 
-  
  • Increment the time-of-day, taking care of any ntpd(8) or
-      adjtime(2) induced changes and leap seconds, as well as
-      any necessary compensations to keep in sync with PPS signals or external
-      clocks, if support for this is in the kernel (see
-      options(4)).
    • 
-  
  • Schedule softclock interrupts if any callouts should be triggered (see
-      callout(9)).
    • 
-

-

-

-

-
adjtime(2), ntp_adjtime(2),
-    signal(7), ntpd(8),
-    callout(9), hz(9)

-

-

-
-  
-    
-    
-  
-
March 25, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/heartbeat.9 3.html b/static/netbsd/man9/heartbeat.9 3.html
deleted file mode 100644
index 4a279c6a..00000000
--- a/static/netbsd/man9/heartbeat.9 3.html	
+++ /dev/null
@@ -1,131 +0,0 @@
-
-  
-    
-    
-    
-  
-
HEARTBEAT(9)Kernel Developer's ManualHEARTBEAT(9)

-

-

-

-
heartbeat —
-    periodic checks to ensure CPUs are making
-  progress

-

-

-

-
options HEARTBEAT
-  

-  options HEARTBEAT_MAX_PERIOD_DEFAULT=15

-

-  

-  #include <sys/heartbeat.h>

-
void
-  

-  heartbeat_start(void);

-
void
-  

-  heartbeat(void);

-
void
-  

-  heartbeat_suspend(void);

-
void
-  

-  heartbeat_resume(void);

-
#ifdef DDB

-
void
-  

-  heartbeat_dump(void);

-
#endif

-

-

-

-
The heartbeat subsystem verifies that soft
-    interrupts (softint(9)) and the system
-    timecounter(9) are making progress over time, and panics
-    if they appear stuck.

-
The number of seconds before heartbeat
-    panics without progress is controlled by the sysctl knob
-    kern.heartbeat.max_period, which defaults to 15. If
-    set to zero, heartbeat checks are disabled.

-
The periodic hardware timer interrupt handler calls
-    ()
-    every tick on each CPU. Once per second (i.e., every hz(9)
-    ticks), heartbeat() schedules a soft interrupt at
-    priority SOFTINT_CLOCK to advance the current CPU's
-    view of time_uptime(9).

-
()
-    checks whether time_uptime(9) has changed, to see if
-    either the timecounter(9) or soft interrupts on the
-    current CPU are stuck. If it hasn't advanced within
-    kern.heartbeat.max_period seconds worth of ticks, or
-    if it has updated and the current CPU's view of it hasn't been updated by
-    more than kern.heartbeat.max_period seconds, then
-    heartbeat() panics.

-
()
-    also checks whether the next online CPU has advanced its view of
-    time_uptime(9), to see if soft interrupts (including
-    callout(9)) on that CPU are stuck. If it hasn't updated
-    within kern.heartbeat.max_period seconds,
-    heartbeat() sends an ipi(9) to
-    panic on that CPU. If that CPU has not acknowledged the
-    ipi(9) within one second,
-    heartbeat() panics on the current CPU instead.

-

-

-

-

-  
heartbeat()

-  
Check for timecounter and soft interrupt progress on this CPU and on
-      another CPU, and schedule a soft interrupt to advance this CPU's view of
-      timecounter progress.
-    
Called by hardclock(9) periodically.

-  

-  
()

-  
Print each CPU's heartbeat counter, uptime cache, and uptime cache
-      timestamp (in units of heartbeats) to the console.
-    
Can be invoked from ddb(9) by
-        ‘call heartbeat_dump’.

-  

-  
()

-  
Resume heartbeat monitoring of the current CPU.
-    
Called after a CPU has started running but before it has been
-        marked online.

-  

-  
()

-  
Start monitoring heartbeats systemwide.
-    
Called by
-        () in
-        sys/kern/init_main.c as soon as soft interrupts
-        can be established.

-  

-  
()

-  
Suspend heartbeat monitoring of the current CPU.
-    
Called after the current CPU has been marked offline but
-        before it has stopped running.

-  

-

-

-

-

-
The heartbeat subsystem is implemented in
-    sys/kern/kern_heartbeat.c.

-

-

-

-
swwdog(4), wdogctl(8)

-

-

-

-
The heartbeat subsystem first appeared in
-    NetBSD 11.0.

-

-

-
-  
-    
-    
-  
-
July 6, 2023NetBSD 10.1

diff --git a/static/netbsd/man9/hz.9 3.html b/static/netbsd/man9/hz.9 3.html
deleted file mode 100644
index 39a5112c..00000000
--- a/static/netbsd/man9/hz.9 3.html	
+++ /dev/null
@@ -1,79 +0,0 @@
-
-  
-    
-    
-    
-  
-
HZ(9)Kernel Developer's ManualHZ(9)

-

-

-

-
hz, tick,
-    tickadj, stathz,
-    profhz — system time
-    model

-

-

-

-
#include
-    <sys/kernel.h>

-

-  

-  extern int hz;
-  

-  extern int tick;
-  

-  extern int tickadj;
-  

-  extern int stathz;
-  

-  extern int profhz;

-

-

-

-
The essential clock handling routines in
-    NetBSD are written to operate with two timers that
-    run independently of each other. The main clock, running
-    hz times per second, is used to keep track of real
-    time.

-
In another words, hz specifies the number of
-    times the hardclock(9) timer ticks per second. Normally
-    hardclock(9) increments time by tick
-    each time it is called. If the system clock has drifted,
-    adjtime(2) may be used to skew this increment based on the
-    rate of tickadj.

-
The second timer is used to gather timing statistics. It also
-    handles kernel and user profiling. If the second timer is programmable, it
-    is randomized to avoid aliasing between the two clocks. The mean frequency
-    of the second timer is stathz. If a separate clock is
-    not available, stathz is set to
-    hz.

-
If profiling is enabled, the clock normally used to drive
-    stathz may be run at a higher rate
-    profhz, which is required to be a multiple of
-    stathz. This will give higher resolution profiling
-    information.

-
These system variables are also available as
-    
-    from sysctl(3) and
-    
-    from sysctl(8). The hz is
-    hardware-dependent; it can be overridden (if the machine dependent code
-    supports this) by defining HZ in the kernel
-    configuration file (see options(4)). Only override the
-    default value if you really know what you are doing.

-

-

-

-
adjtime(2), callout(9),
-    hardclock(9), microtime(9),
-    time_second(9)

-

-

-
-  
-    
-    
-  
-
March 25, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/ieee80211_proto.9 3.html b/static/netbsd/man9/ieee80211_proto.9 3.html
deleted file mode 100644
index 82e9d6e8..00000000
--- a/static/netbsd/man9/ieee80211_proto.9 3.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_PROTO(9)Kernel Developer's ManualIEEE80211_PROTO(9)

-

-

-

-
ieee80211_proto_attach,
-    ieee80211_proto_detach,
-    ieee80211_print_essid,
-    ieee80211_dump_pkt,
-    ieee80211_fix_rate,
-    ieee80211_proto — software
-    802.11 stack protocol helper functions

-

-

-

-
#include
-    <net80211/ieee80211_var.h>
-  

-  #include
-    <net80211/ieee80211_proto.h>

-
void
-  

-  ieee80211_proto_attach(struct
-    ieee80211com *ic);

-
void
-  

-  ieee80211_proto_detach(struct
-    ieee80211com *ic);

-
void
-  

-  ieee80211_print_essid(u_int8_t
-    *essid, int
-  len);

-
void
-  

-  ieee80211_dump_pkt(u_int8_t
-    *buf, int len,
-    int rate,
-    int rssi);

-
int
-  

-  ieee80211_fix_rate(struct
-    ieee80211_node *ni, int flags);

-

-

-

-
These functions are helper functions used throughout the software
-    802.11 protocol stack.

-

-

-

-
ieee80211(9)

-

-

-

-
The ieee80211 series of functions first
-    appeared in NetBSD 1.5, and were later ported to
-    FreeBSD 4.6.

-

-

-

-
This man page was written by Bruce M.
-    Simpson
-    <bms@FreeBSD.org> and
-    Darron Broad
-    <darron@kewl.org>.

-

-

-
-  
-    
-    
-  
-
September 12, 2006NetBSD 10.1

diff --git a/static/netbsd/man9/ieee80211_radiotap.9 3.html b/static/netbsd/man9/ieee80211_radiotap.9 3.html
deleted file mode 100644
index 06b0d5ce..00000000
--- a/static/netbsd/man9/ieee80211_radiotap.9 3.html	
+++ /dev/null
@@ -1,233 +0,0 @@
-
-  
-    
-    
-    
-  
-
IEEE80211_RADIOTAP(9)Kernel Developer's ManualIEEE80211_RADIOTAP(9)

-

-

-

-
ieee80211_radiotap —
-    software 802.11 stack packet capture definitions

-

-

-

-
#include
-    <net80211/ieee80211_var.h>
-  

-  #include
-    <net80211/ieee80211_ioctl.h>
-  

-  #include
-    <net80211/ieee80211_radiotap.h>
-  

-  #include <net/bpf.h>

-

-

-

-
The ieee80211_radiotap definitions provide
-    a device-independent bpf(4) attachment for the capture of
-    information about 802.11 traffic which is not part of the 802.11 frame
-    structure.

-
Radiotap was designed to balance the desire for a capture format
-    that conserved CPU and memory bandwidth on embedded systems, with the desire
-    for a hardware-independent, extensible format that would support the diverse
-    capabilities of virtually all 802.11 radios.

-
These considerations led radiotap to settle on a format consisting
-    of a standard preamble followed by an extensible bitmap indicating the
-    presence of optional capture fields.

-
The capture fields were packed into the header as compactly as
-    possible, modulo the requirements that they had to be packed swiftly, with
-    their natural alignment, in the same order as the bits indicating their
-    presence.

-
This typically includes information such as signal quality and
-    timestamps. This information may be used by a variety of user agents,
-    including tcpdump(8). It is requested by using the
-    bpf(4) data-link type
-    DLT_IEEE_80211_RADIO.

-
Each frame using this attachment has the following header
-    prepended to it:

-

-
struct ieee80211_radiotap_header {
-	u_int8_t	it_version;	/* set to 0 */
-	u_int8_t	it_pad;
-	u_int16_t	it_len;		/* entire length */
-	u_int32_t	it_present;	/* fields present */
-} __attribute__((__packed__));

-

-
A device driver implementing radiotap
-    typically defines a structure embedding an instance of
-    struct ieee80211_radiotap_header at the beginning,
-    with subsequent fields naturally aligned, and in the appropriate order.
-    Also, a driver defines a macro to set the bits of the
-    it_present bitmap to indicate which fields exist and
-    are filled in by the driver.

-
Radiotap capture fields are in little-endian byte order.

-
Radiotap capture fields
-    . That is, 16-, 32-, and 64-bit fields must begin on 16-,
-    32-, and 64-bit boundaries, respectively. In this way, drivers can avoid
-    unaligned accesses to radiotap capture fields. radiotap-compliant drivers
-    must insert padding before a capture field to ensure its natural alignment.
-    radiotap-compliant packet dissectors, such as tcpdump(8),
-    expect the padding.

-
Developers beware: all compilers may not pack structs alike. If a
-    driver developer constructs their radiotap header with a packed structure,
-    in order to ensure natural alignment, then it is important that they insert
-    padding bytes by themselves.

-
Radiotap headers are copied to the userland via a
-    separate bpf attachment. It is necessary for the driver to create this
-    attachment after calling ieee80211_ifattach(9) by calling
-    ()
-    with the data-link type set to
-  DLT_IEEE802_11_RADIO.

-
When the information is available, usually
-    immediately before a link-layer transmission or after a receive, the driver
-    copies it to the bpf layer using the
-    ()
-    function.

-
The following extension fields are defined for
-    radiotap, in the order in which they should appear in
-    the buffer copied to userland:

-

-  

-  
This field contains the unsigned 64-bit value, in microseconds, of the
-      MAC's 802.11 Time Synchronization Function timer, when the first bit of
-      the MPDU arrived at the MAC. This field should be present for received
-      frames only.

-  

-  
This field contains a single unsigned 8-bit value, containing a bitmap of
-      flags specifying properties of the frame being transmitted or
-    received.

-  

-  
This field contains a single unsigned 8-bit value, which is the data rate
-      in use in units of 500Kbps.

-  

-  
This field contains two unsigned 16-bit values. The first value is the
-      frequency upon which this PDU was transmitted or received. The second
-      value is a bitmap containing flags which specify properties of the channel
-      in use. These are documented within the header file,
-      <net80211/ieee80211_radiotap.h>.

-  

-  
This field contains two 8-bit values. This field should be present for
-      frequency-hopping radios only. The first byte is the hop set. The second
-      byte is the pattern in use.

-  

-  
This field contains a single signed 8-bit value, which indicates the RF
-      signal power at the antenna, in decibels difference from 1mW.

-  

-  
This field contains a single signed 8-bit value, which indicates the RF
-      noise power at the antenna, in decibels difference from 1mW.

-  

-  
This field contains a single unsigned 16-bit value, indicating the quality
-      of the Barker Code lock. No unit is specified for this field. There does
-      not appear to be a standard way of measuring this at this time; this
-      quantity is often referred to as “Signal Quality” in some
-      datasheets.

-  

-  
This field contains a single unsigned 16-bit value, expressing transmit
-      power as unitless distance from maximum power set at factory calibration.
-      0 indicates maximum transmit power. Monotonically nondecreasing with lower
-      power levels.

-  

-  
This field contains a single unsigned 16-bit value, expressing transmit
-      power as decibel distance from maximum power set at factory calibration. 0
-      indicates maximum transmit power. Monotonically nondecreasing with lower
-      power levels.

-  

-  
Transmit power expressed as decibels from a 1mW reference. This field is a
-      single signed 8-bit value. This is the absolute power level measured at
-      the antenna port.

-  

-  
For radios which support antenna diversity, this field contains a single
-      unsigned 8-bit value specifying which antenna is being used to transmit or
-      receive this frame. The first antenna is antenna 0.

-  

-  
This field contains a single unsigned 8-bit value, which indicates the RF
-      signal power at the antenna, in decibels difference from an arbitrary,
-      fixed reference.

-  

-  
This field contains a single unsigned 8-bit value, which indicates the RF
-      noise power at the antenna, in decibels difference from an arbitrary,
-      fixed reference.

-  

-  
An unsigned 16-bit bitmap indicating properties of received frames.

-  

-  
An unsigned 16-bit bitmap indicating properties of transmitted
-    frames.

-  

-  
Unsigned 8-bit value indicating how many times the NIC retransmitted the
-      Request to Send (RTS) in an RTS/CTS handshake before receiving an 802.11
-      Clear to Send (CTS).

-  

-  
Unsigned 8-bit value indicating how many times the NIC retransmitted a
-      unicast data packet before receiving an 802.11 Acknowledgement.

-  

-  
This bit is reserved for any future extensions to the
-      radiotap structure. A driver sets
-      IEEE80211_RADIOTAP_EXT to extend the it_present
-      bitmap by another 32 bits. The bitmap can be extended by multiples of 32
-      bits to 96, 128, 160 bits or longer, by setting
-      IEEE80211_RADIOTAP_EXT in the extensions. The
-      bitmap ends at the first extension field where
-      IEEE80211_RADIOTAP_EXT is not set.

-

-

-

-

-
Radiotap header for the Cisco Aironet driver:

-

-
struct an_rx_radiotap_header {
-	struct ieee80211_radiotap_header	ar_ihdr;
-	u_int8_t	ar_flags;
-	u_int8_t	ar_rate;
-	u_int16_t	ar_chan_freq;
-	u_int16_t	ar_chan_flags;
-	u_int8_t	ar_antsignal;
-	u_int8_t	ar_antnoise;
-} __attribute__((__packed__));

-

-
Bitmap indicating which fields are present in the above
-  structure:

-

-
#define AN_RX_RADIOTAP_PRESENT \
-	((1 >> IEEE80211_RADIOTAP_FLAGS) | \
-	 (1 >> IEEE80211_RADIOTAP_RATE) | \
-	 (1 >> IEEE80211_RADIOTAP_CHANNEL) | \
-	 (1 >> IEEE80211_RADIOTAP_DBM_ANTSIGNAL) | \
-	 (1 >> IEEE80211_RADIOTAP_DBM_ANTNOISE))

-

-

-

-

-
bpf(4), ieee80211(9)

-

-

-

-
The ieee80211_radiotap definitions first
-    appeared in NetBSD 1.5, and were later ported to
-    FreeBSD 4.6.

-

-

-

-
The ieee80211_radiotap interface was
-    designed and implemented by David Young
-    <dyoung@pobox.com>.
-    David Young is the maintainer of the radiotap
-    capture format. Contact him to add new capture fields.

-
This manual page was written by Bruce M.
-    Simpson
-    <bms@FreeBSD.org> and
-    Darron Broad
-    <darron@kewl.org>.

-

-

-
-  
-    
-    
-  
-
March 12, 2006NetBSD 10.1

diff --git a/static/netbsd/man9/imax.9 3.html b/static/netbsd/man9/imax.9 3.html
deleted file mode 100644
index 9848ab9b..00000000
--- a/static/netbsd/man9/imax.9 3.html	
+++ /dev/null
@@ -1,83 +0,0 @@
-
-  
-    
-    
-    
-  
-
IMAX(9)Kernel Developer's ManualIMAX(9)

-

-

-

-
imax, imin,
-    lmax, lmin,
-    uimax, uimin,
-    ulmax, ulmin —
-    compare integers

-

-

-

-
int
-  

-  imax(int
-    a, int b);

-
int
-  

-  imin(int
-    a, int b);

-
long
-  

-  lmax(long
-    a, long b);

-
long
-  

-  lmin(long
-    a, long b);

-
u_int
-  

-  uimax(u_int
-    a, u_int b);

-
u_int
-  

-  uimin(u_int
-    a, u_int b);

-
u_long
-  

-  ulmax(u_long
-    a, u_long b);

-
u_long
-  

-  ulmin(u_long
-    a, u_long b);

-

-

-

-
The
-    (),
-    (),
-    (),
-    and
-    ()
-    functions return whichever argument is algebraically smaller, differing only
-    in their argument and return types: these functions operate on,
-    respectively, natural size, long, unsigned and unsigned long integers.

-
The
-    (),
-    (),
-    (),
-    and
-    ()
-    functions are identical except that they return the algebraically larger
-    argument between a and b.

-

-

-

-
ilog2(3)

-

-

-
-  
-    
-    
-  
-
July 10, 2024NetBSD 10.1

diff --git a/static/netbsd/man9/inittodr.9 3.html b/static/netbsd/man9/inittodr.9 3.html
deleted file mode 100644
index b8f919ad..00000000
--- a/static/netbsd/man9/inittodr.9 3.html	
+++ /dev/null
@@ -1,74 +0,0 @@
-
-  
-    
-    
-    
-  
-
INITTODR(9)Kernel Developer's ManualINITTODR(9)

-

-

-

-
inittodr —
-    initialize system time

-

-

-

-
void
-  

-  inittodr(time_t
-    base);

-

-

-

-
The
-    ()
-    function determines the time and sets the system clock. It tries to pick the
-    correct time using a set of heuristics that examine the system's
-    battery-backed clock and the time reported by the file system, as given in
-    base. Those heuristics include:

-
    
-  
  • If the battery-backed clock has a valid time, and is not significantly
-      behind the time provided by base, it is used.
    • 
-  
  • If the battery-backed clock does not have a valid time, or is
-      significantly behind the time provided in base, and
-      the time provided in base is within reason,
-      base is used as the current time.
    • 
-  
  • If the battery-backed clock appears invalid, and
-      base appears non-sensical or was not provided (was
-      given as zero), an arbitrary base (typically some time within the same
-      year that the kernel was last updated) will be used.
    • 
-

-
Once a system time has been determined, it is stored in the
-    time variable.

-

-

-

-
The inittodr() function prints diagnostic
-    messages if it has trouble figuring out the system time. Conditions that can
-    cause diagnostic messages to be printed include:

-
    
-  
  • There is no battery-backed clock present on the system.
    • 
-  
  • The battery-backed clock's time appears nonsensical.
    • 
-  
  • The base time appears nonsensical.
    • 
-  
  • The base time and the battery-backed clock's time
-      differ by a large amount.
    • 
-

-

-

-

-
clock_ymdhms_to_secs(9),
-    resettodr(9), time_second(9)

-

-

-

-
Some systems use heuristics for picking the correct time that are
-    slightly different.

-

-

-
-  
-    
-    
-  
-
September 6, 2006NetBSD 10.1

diff --git a/static/netbsd/man9/interrupt_distribute.9 3.html b/static/netbsd/man9/interrupt_distribute.9 3.html
deleted file mode 100644
index 7cf9b23e..00000000
--- a/static/netbsd/man9/interrupt_distribute.9 3.html	
+++ /dev/null
@@ -1,44 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTERRUPT_DISTRIBUTE(9)Kernel Developer's ManualINTERRUPT_DISTRIBUTE(9)

-

-

-

-
interrupt_distribute —
-    assign an interrupt to a CPU

-

-

-

-
#include
-    <sys/interrupt.h>

-
int
-  

-  interrupt_distribute(void
-    *ich, const kcpuset_t
-    *newset, kcpuset_t
-    *oldset);

-

-

-

-
The interrupt_distribute function exists
-    to assign an interrupt to a CPU.

-
If a driver (or the other kernel
-    component) wishes to assign an interrupt to a CPU, it should pass an
-    interrupt handler such as the return value of
-    ()
-    as ich argument, and it should pass the kcpuset to
-    which it should be assigned as newset. To get the
-    previous value, pass a non-NULL value to
-    oldset.

-

-

-
-  
-    
-    
-  
-
August 17, 2015NetBSD 10.1

diff --git a/static/netbsd/man9/intro.9 3.html b/static/netbsd/man9/intro.9 3.html
deleted file mode 100644
index e02756d7..00000000
--- a/static/netbsd/man9/intro.9 3.html	
+++ /dev/null
@@ -1,347 +0,0 @@
-
-  
-    
-    
-    
-  
-
INTRO(9)Kernel Developer's ManualINTRO(9)

-

-

-

-
intro —
-    introduction to kernel internals

-

-

-

-
This section contains information related to the internal
-    operation of the system kernel. It describes function interfaces and
-    variables of use to the systems and device driver programmer.

-
In addition to the normal man page format, the kernel pages
-    include an additional section:

-

-  
CODE REFERENCES

-  
Contains the pathname(s) of the source file(s) which contain the
-      definition and/or source code of the variables or functions being
-      documented. Any paths are relative to the top level of the source tree
-      (traditionally /usr/src).

-

-

-

-

-
Introduction to kernel memory allocators. See
-    memoryallocators(9).

-
Machine-dependent portion of the virtual memory system. See
-    pmap(9).

-
Virtual memory system external interface. See
-    uvm(9).

-

-

-

-
Buffer cache interfaces. See buffercache(9).

-
Device buffer queues. See bufq(9).

-
Initiate I/O on raw devices. See physio(9).

-
I/O descriptor allocation interface. See
-    getiobuf(9).

-

-

-

-
Idle CPU while waiting for work. See
-    cpu_idle(9).

-
Finish a fork operation. See
-  cpu_lwp_fork(9).

-
Switch to another light weight process. See
-    mi_switch(9).

-
Current process and processor. See
-  curproc(9).

-
Set process uid and gid. See
-  do_setresuid(9).

-
New processes and kernel threads. See fork1(9),
-    kthread(9).

-
Context switch notification. See
-    cpu_need_resched(9).

-
Common scheduler framework. See csf(9).

-
Software signal facilities. See signal(9).

-
Suspend the scheduler. See suspendsched(9).

-
Return path to user-mode execution. See
-    userret(9).

-

-

-

-
High-level file operations. See
-  dofileread(9).

-
Convert an extended attribute namespace identifier to a string and
-    vice versa. See extattr(9).

-
Operations on file entries. See file(9).

-
In-kernel, file system independent, file-meta data association.
-    See fileassoc(9).

-
File descriptor tables and operations. See
-    filedesc(9).

-
File descriptor owner handling functions. See
-    fsetown(9).

-
File system suspension helper subsystem. See
-    fstrans(9).

-
Pathname lookup, cache and management. See
-    namei(9), namecache(9).

-
Kernel interface to file systems. See
-  vfs(9).

-
Kernel representation of a file or directory and vnode attributes.
-    See vnode(9), vattr(9).

-

-

-

-
Kernel interfaces for manipulating output queues on network
-    interfaces. See altq(9).

-
Externally visible ARP functions. See
-  arp(9).

-
Ethernet and FDDI driver support functions and macros. See
-    ethersubr(9).

-
Core 802.11 network stack functions and rate adaptation based on
-    received signal strength. See ieee80211(9),
-    rssadapt(9).

-
Compute Internet checksum. See in_cksum(9).

-
Look up the IPv4 source address best matching an IPv4 destination.
-    See in_getifa(9).

-
Functions and macros for managing memory used by networking code.
-    See mbuf(9).

-
Packet filter interface. See pfil(9).

-
Route callout functions. See rt_timer(9).

-
TCP congestion control API. See
-  tcp_congctl(9).

-

-

-

-
See locking(9) for an overview.

-
Condition variables. See condvar(9).

-
Kernel lock functions. See lock(9).

-
Memory barriers. See membar_ops(3).

-
Mutual exclusion primitives. See mutex(9).

-
Restartable atomic sequences. See ras(9).

-
Reader / writer lock primitives. See
-  rwlock(9).

-
Machine-independent software interrupt framework. See
-    softint(9).

-
Functions to modify system interrupt priority level. See
-    spl(9).

-
Functions to raise the system priority level. See
-    splraiseipl(9).

-

-

-

-
Kernel authorization framework. See
-  kauth(9).

-
API for cryptographic services in the kernel. See
-    opencrypto(9).

-
Security model development guidelines. See
-    secmodel(9).

-

-

-

-
Execute a function after a specified length of time. See
-    callout(9).

-
Microsecond delay. See delay(9).

-
Real-time timer. See hardclock(9).

-
System clock frequency. See hz(9).

-
Initialization of system time and time-of-day clock support. See
-    inittodr(9), todr(9).

-
Check that a timeval value is valid, and correct. See
-    itimerfix(9).

-
System time variables. See timecounter(9).

-
Realtime system clock. See microtime(9).

-
Get the time elapsed since boot. See
-    microuptime(9).

-
Convert milliseconds to system clock ticks. See
-    mstohz(9).

-
Function to help implement rate-limited actions. See
-    ppsratecheck(9).

-
Function to help implement rate-limited actions. See
-    ratecheck(9).

-
Set battery-backed clock from system time. See
-    resettodr(9).

-
System time variables. See time_second(9).

-

-

-

-
Kernel space to/from user space copy functions. See
-    copy(9).

-
Store data to user-space. See ustore(9).

-
Fetch data from user-space. See ufetch(9).

-
Move data described by a struct uio. See
-    uiomove(9).

-

-

-

-
Machine-dependent clock setup interface. See
-    cpu_initclocks(9).

-
Machine-dependent process core dump interface. See
-    cpu_coredump(9).

-
Machine-dependent kernel core dumps. See
-    cpu_dumpconf(9).

-
Unique CPU identification number See
-    cpu_number(9).

-
Halt or reboot the system See cpu_reboot(9).

-
Machine-dependent root file system setup See
-    cpu_rootconf(9).

-
Machine-dependent CPU startup See
-    cpu_startup(9).

-
Disk label management routines. See
-    disklabel(9).

-

-

-

-
Autoconfiguration frame-work. See
-  autoconf(9).

-
Description of a device driver. See
-  driver(9).

-
The autoconfiguration framework ``device definition'' language.
-    See config(9).

-
Machine-dependent device autoconfiguration. See
-    cpu_configure(9).

-

-

-

-
Bus and Machine Independent DMA Mapping Interface. See
-    bus_dma(9).

-
Bus space manipulation functions. See
-    bus_space(9).

-
Generic disk framework. See disk(9).

-
Hardware-assisted data mover interface. See
-    dmover(9). Generic event counter framework. See
-    evcnt(9).

-
Firmware loader API for device drivers. See
-    firmload(9).

-
How to implement a new ioctl call to access device drivers. See
-    ioctl(9).

-
Extensible line discipline framework. See
-    linedisc(9).

-

-

-

-
Console magic key sequence management. See
-    cnmagic(9).

-
Console access interface. See cons(9).

-
Raster display operations. See rasops(9).

-
Generic virtual console framework. See
-  vcons(9).

-
Machine-independent console support. See
-    wscons(9).

-

-

-

-
Interface between low and high level audio drivers. See
-    audio(9).

-
Bluetooth Device/Protocol API. See
-  bluetooth(9).

-
Support for CardBus PC-Card devices. See
-    cardbus(9).

-
VESA Display Data Channel V2. See ddc(9).

-
VESA Extended Display Identification Data. See
-    edid(9).

-
Inter IC (I2C) bus. See iic(9).

-
Baseboard I/O control ASIC for DEC TURBOchannel systems. See
-    ioasic(9).

-
Industry-standard Architecture. See isa(9).

-
Introduction to ISA Plug-and-Play support. See
-    isapnp(9).

-
MicroChannel Architecture bus. See mca(9).

-
PPBUS microseqencer developer's guide. See
-    microseq(9).

-
Peripheral Component Interconnect. See
-  pci(9).

-
Perform PCI bus configuration. See
-    pci_configure_bus(9).

-
PCI bus interrupt manipulation functions. See
-    pci_intr(9).

-
PC keyboard port interface. See pckbport(9).

-
Support for PCMCIA PC-Card devices. See
-    pcmcia(9).

-
Interface between low and high level radio drivers. See
-    radio(9).

-
Functions to make a device available for entropy collection. See
-    rnd(9).

-
SCSI/ATAPI middle-layer interface. See
-    scsipi(9).

-
TURBOchannel bus. See tc(9).

-
USB tty support. See ucom(9).

-
USB device drivers interface. See usbdi(9).

-
Versa Module Euroboard bus. See vme(9).

-
Machine-independent IDE/ATAPI driver. See
-    wdc(9).

-

-

-

-
Functions to add or remove kernel event filters. See
-    kfilter_register(9).

-
Functions to raise kernel event. See
-  knote(9).

-
Record and wakeup select requests. See
-    selrecord(9).

-
Simple do-it-in-thread-context framework. See
-    workqueue(9).

-

-

-

-
Kernel expression verification macros. See
-    KASSERT(9).

-
Convert a single byte between (unsigned) packed bcd and binary.
-    See bcdtobin(9).

-
Bitmask output conversion. See snprintb(3).

-
General purpose extent manager. See
-  extent(9).

-
Compare integers. See imax(9).

-
Kernel formatted output conversion. See
-    kprintf(9).

-
Data comparing, moving, copying, setting and cleaning. See
-    memcmp(9), memmove(9),
-    memcpy(9), memset(9),
-    bcmp(9), bcopy(9),
-    bzero(9), kcopy(9).

-
Log a message from the kernel through the /dev/klog device. See
-    log(9).

-
Bring down system on fatal error. See
-  panic(9).

-

-

-

-
Power management and inter-driver messaging. See
-    pmf(9).

-
Run all shutdown hooks. See
-    pmf_system_shutdown(9).

-
Kernel internal error numbers. See errno(9).

-
Kernel hash functions, hash table construction and destruction.
-    See hash(9), hashinit(9).

-
Format a number into a human readable form. See
-    humanize_number(9).

-
Options string management. See optstr(9).

-
Performs pattern matching on strings. See
-    pmatch(9).

-
Add or remove a shutdown hook. See pmf(9).

-
Non-local jumps. See setjmp(9).

-
System variable control interfaces. See
-    sysctl(9).

-

-

-

-
The NetBSD kernel internals section first
-    appeared in NetBSD 1.2.

-

-

-
-  
-    
-    
-  
-
July 14, 2018NetBSD 10.1

diff --git a/static/netbsd/man9/ioctl.9 3.html b/static/netbsd/man9/ioctl.9 3.html
deleted file mode 100644
index db973c99..00000000
--- a/static/netbsd/man9/ioctl.9 3.html	
+++ /dev/null
@@ -1,289 +0,0 @@
-
-  
-    
-    
-    
-  
-
IOCTL(9)Kernel Developer's ManualIOCTL(9)

-

-

-

-
ioctl — how to
-    implement a new ioctl call to access device drivers

-

-

-

-
#include
-    <sys/ioctl.h>
-  

-  #include <sys/ioccom.h>

-
int
-  

-  ioctl(int,
-    unsigned long,
-    ...);

-

-

-

-
ioctl are internally defined as

-

-  
#define FOOIOCTL fun(t,n,pt)

-  
 

-

-
where the different variables and functions are:

-

-  

-  
the name which will later be given in the ioctl(2)
-      system call as second argument, e.g.,
-    
ioctl(s, FOOIOCTL,
-      ...)

-    .

-  
()

-  
a macro which can be one of
-    

-      
_IO

-      
the call is a simple message to the kernel by itself. It does not copy
-          anything into the kernel, nor does it want anything back.

-      
_IOR

-      
the call only reads parameters from the kernel and does not pass any
-          to it

-      
_IOW

-      
the call only writes parameters to the kernel, but does not want
-          anything back

-      
_IOWR

-      
the call writes data to the kernel and wants information back.

-    

-  

-  
t

-  
This integer describes to which subsystem the ioctl applies.
-      t can be one of
-    

-      
'1'

-      
pulse-per-second interface

-      
'a'

-      
ISO networking

-      
'A'

-      
ac devices (hp300)

-      
'A'

-      
Advanced Power Management (hpcmips, i386, sparc), see
-          apm(4)

-      
'A'

-      
ADB devices (mac68k, macppc)

-      
'A'

-      
audio(4)

-      
'b'

-      
Bluetooth HCI sockets, see bluetooth(4)

-      
'b'

-      
Bluetooth Hub Control, see bthub(4)

-      
'b'

-      
Bluetooth SCO audio driver, see btsco(4)

-      
'B'

-      
bell device (x68k)

-      
'B'

-      
bpf(4)

-      
'c'

-      
coda

-      
'c'

-      
cd(4)

-      
'c'

-      
ch(4)

-      
'C'

-      
clock devices (amiga, atari, hp300, x68k)

-      
'd'

-      
the disk subsystem

-      
'E'

-      
envsys(4)

-      
'f'

-      
files

-      
'F'

-      
Sun-compatible framebuffers

-      
'F'

-      
ccd(4) and vnd(4)

-      
'g'

-      
qdss framebuffers

-      
'G'

-      
grf devices (amiga, atari, hp300, mac68k, x68k)

-      
'h'

-      
HIL devices (hp300)

-      
'H'

-      
HIL devices (hp300)

-      
'H'

-      
HPc framebuffers

-      
'i'

-      
a (pseudo) interface

-      
'I'

-      
ite(4) (mac68k)

-      
'J'

-      
ISA joystick interface

-      
'k'

-      
Sun-compatible (and other) keyboards

-      
'l'

-      
leo devices (atari)

-      
'm'

-      
mtio(4)

-      
'M'

-      
mouse devices (atari)

-      
'M'

-      
mlx(4)

-      
'n'

-      
virtual console device (arm32)

-      
'n'

-      
SMB networking

-      
'O'

-      
OpenPROM and OpenFirmware

-      
'p'

-      
power control (x68k)

-      
'P'

-      
parallel port (amiga, x68k)

-      
'P'

-      
profiling (arm32)

-      
'P'

-      
printer/plotter interface (hp300)

-      
'P'

-      
pci(4)

-      
'P'

-      
compat/ossaudio and soundcard.h

-      
'P'

-      
sparc/magma(4) bpp (sparc)

-      
'q'

-      
altq(9)

-      
'q'

-      
pmax graphics devices

-      
'Q'

-      
altq(9)

-      
'Q'

-      
raw SCSI commands

-      
'r'

-      
the routing subsystem

-      
'r'

-      
md(4)

-      
'R'

-      
rnd(4)

-      
's'

-      
the socket layer

-      
'S'

-      
SCSI disks (arc, hp300, pmax)

-      
'S'

-      
watchdog devices (sh3)

-      
'S'

-      
ISA speaker devices

-      
'S'

-      
stic devices

-      
'S'

-      
scanners

-      
't'

-      
the tty layer

-      
'u'

-      
user defined ???

-      
'U'

-      
scsibus (see scsi(4))

-      
'v'

-      
Sun-compatible “firm events”

-      
'V'

-      
view device (amiga, atari)

-      
'V'

-      
sram device (x68k)

-      
'w'

-      
watchdog devices

-      
'W'

-      
wt devices

-      
'W'

-      
wscons devices

-      
'x'

-      
bt8xx devices

-      
'Z'

-      
ite devices (amiga, atari, x68k)

-      
'Z'

-      
passthrough ioctls

-    

-  

-  
n

-  
This numbers the ioctl within the group. There may be only one
-      n for a given t. This is an
-      unsigned 8 bit number.

-  
pt

-  
This specifies the type of the passed parameter. This one gets internally
-      transformed to the size of the parameter, so for example, if you want to
-      pass a structure, then you have to specify that structure and not a
-      pointer to it or sizeof(struct foo)

-

-
In order for the new ioctl to be known to the system it is
-    installed in either ⟨sys/ioctl.h⟩ or
-    one of the files that are reached from
-    ⟨sys/ioctl.h⟩.

-

-

-

-
All ioctl() routines should return either
-    0 or a defined error code. The use of magic numbers such as -1, to indicate
-    that a given ioctl code was not handled is strongly discouraged. The value
-    -1 coincides with the historic value for ERESTART
-    which was shown to produce user space code that never returned from a call
-    to ioctl(2).

-
For ioctl codes that are not handled by a given routine, the
-    pseudo error value EPASSTHROUGH is provided.
-    EPASSTHROUGH indicates that no error occurred during
-    processing (it did not fail), but neither was anything processed (it did not
-    succeed). This supersedes the use of either ENOTTY
-    (which is an explicit failure) or -1 (which has no contextual meaning) as a
-    return value. ENOTTY will get passed directly back
-    to user space and bypass any further processing by other ioctl layers. Only
-    code that wishes to suppress possible further processing of an ioctl code
-    (e.g., the tty line discipline code) should return
-    ENOTTY. All other code should return
-    EPASSTHROUGH, even if it knows that no other layers
-    will be called upon.

-
If the value EPASSTHROUGH is returned to
-    sys_ioctl(), then it will there be changed to
-    ENOTTY to be returned to user space, thereby
-    providing the proper error notification to the application.

-

-

-

-

-
#define	FOOIOCTL	_IOWR('i', 23, int)
-
-int a = 3;
-error = ioctl(s, FOOIOCTL, &a);

-

-
Within the
-    ioctl()-routine of the
-    driver, it can be then accessed like

-

-
driver_ioctl(..., u_long cmd, void *data)
-{
-	...
-	switch (cmd) {
-
-	case FOOIOCTL:
-		int *a = (int *)data;
-		printf(" Value passed: %d\n", *a);
-		break;
-	}
-}

-

-

-

-

-
Note that if you for example try to read information from an
-    ethernet driver where the name of the card is included in the third argument
-    (e.g., ioctl(s, READFROMETH, struct ifreq *)), then you have to use the
-    ()
-    form not the
-    (),
-    as passing the name of the card to the kernel already consists of writing
-    data.

-

-

-

-
ioctl(2)

-

-

-
-  
-    
-    
-  
-
July 7, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/kcopy.9 3.html b/static/netbsd/man9/kcopy.9 3.html
deleted file mode 100644
index 21723f5f..00000000
--- a/static/netbsd/man9/kcopy.9 3.html	
+++ /dev/null
@@ -1,54 +0,0 @@
-
-  
-    
-    
-    
-  
-
KCOPY(9)Kernel Developer's ManualKCOPY(9)

-

-

-

-
kcopy — copy data
-    with abort on page fault

-

-

-

-
#include
-    <sys/systm.h>

-
int
-  

-  kcopy(const
-    void *src, void
-    *dst, size_t
-  len);

-

-

-

-
()
-    copies len bytes from src to
-    dst, aborting if a fatal page fault is
-  encountered.

-
()
-    must save and restore the old fault handler since it is called by
-    uiomove(9), which may be in the path of servicing a
-    non-fatal page fault.

-

-

-

-
kcopy() returns 0 on success and an error
-    number on failure.

-

-

-

-
errno(2), memcpy(9),
-    uiomove(9)

-

-

-
-  
-    
-    
-  
-
April 6, 2017NetBSD 10.1

diff --git a/static/netbsd/man9/kcpuset.9 3.html b/static/netbsd/man9/kcpuset.9 3.html
deleted file mode 100644
index cbd8d284..00000000
--- a/static/netbsd/man9/kcpuset.9 3.html	
+++ /dev/null
@@ -1,339 +0,0 @@
-
-  
-    
-    
-    
-  
-
KCPUSET(9)Kernel Developer's ManualKCPUSET(9)

-

-

-

-
kcpuset,
-    kcpuset_create,
-    kcpuset_destroy,
-    kcpuset_clone, kcpuset_copy,
-    kcpuset_use, kcpuset_unuse,
-    kcpuset_copyin,
-    kcpuset_copyout,
-    kcpuset_zero, kcpuset_fill,
-    kcpuset_set, kcpuset_clear,
-    kcpuset_isset,
-    kcpuset_isotherset,
-    kcpuset_iszero,
-    kcpuset_match,
-    kcpuset_intersect,
-    kcpuset_merge,
-    kcpuset_remove, kcpuset_ffs,
-    kcpuset_ffs_intersecting,
-    kcpuset_countset,
-    kcpuset_atomic_set,
-    kcpuset_atomic_clear,
-    kcpuset_atomicly_intersect,
-    kcpuset_atomicly_merge,
-    kcpuset_atomicly_remove,
-    kcpuset_export_32 — dynamic
-    kernel CPU sets

-

-

-

-
#include
-    <sys/kcpuset.h>

-
void
-  

-  kcpuset_create(kcpuset_t
-    **retkcp, bool
-    zero);

-
void
-  

-  kcpuset_destroy(kcpuset_t
-    *kcp);

-
void
-  

-  kcpuset_clone(kcpuset_t
-    **retkcp, const kcpuset_t
-    *skcp);

-
void
-  

-  kcpuset_copy(kcpuset_t
-    *dkcp, const kcpuset_t
-    *skcp);

-
void
-  

-  kcpuset_use(kcpuset_t
-    *kcp);

-
void
-  

-  kcpuset_unuse(kcpuset_t
-    *kcp, kcpuset_t
-    **lst);

-
int
-  

-  kcpuset_copyin(const
-    cpuset_t *ucp, kcpuset_t
-    *kcp, size_t
-  len);

-
int
-  

-  kcpuset_copyout(kcpuset_t
-    *kcp, cpuset_t
-    *ucp, size_t
-  len);

-
void
-  

-  kcpuset_zero(kcpuset_t
-    *kcp);

-
void
-  

-  kcpuset_fill(kcpuset_t
-    *kcp);

-
void
-  

-  kcpuset_set(kcpuset_t
-    *kcp, cpuid_t
-  cpu);

-
void
-  

-  kcpuset_clear(kcpuset_t
-    *kcp, cpuid_t
-  cpu);

-
bool
-  

-  kcpuset_isset(const
-    kcpuset_t * kcp, cpuid_t
-    cpu);

-
bool
-  

-  kcpuset_isotherset(const
-    kcpuset_t * kcp, cpuid_t
-    cpu);

-
bool
-  

-  kcpuset_iszero(const
-    kcpuset_t *kcp);

-
bool
-  

-  kcpuset_intersecting_p(const
-    kcpuset_t *kcp1, const
-    kcpuset_t *kcp2);

-
bool
-  

-  kcpuset_match(const
-    kcpuset_t *kcp1, const
-    kcpuset_t *kcp2);

-
void
-  

-  kcpuset_intersect(kcpuset_t
-    *kcp1, const kcpuset_t
-    *kcp2);

-
void
-  

-  kcpuset_merge(kcpuset_t
-    *kcp1, const kcpuset_t
-    *kcp2);

-
void
-  

-  kcpuset_remove(kcpuset_t
-    *kcp1, const kcpuset_t
-    *kcp2);

-
cpuid_t
-  

-  kcpuset_ffs(const
-    kcpuset_t *kcp);

-
cpuid_t
-  

-  kcpuset_ffs_intersecting(const
-    kcpuset_t *kcp1, const
-    kcpuset_t *kcp2);

-
int
-  

-  kcpuset_countset(const
-    kcpuset_t *kcp);

-
void
-  

-  kcpuset_atomic_set(kcpuset_t
-    *kcp, cpuid_t
-  cpu);

-
void
-  

-  kcpuset_atomic_clear(kcpuset_t
-    *kcp, cpuid_t
-  cpu);

-
void
-  

-  kcpuset_atomicly_intersect(kcpuset_t
-    *kcp1, const kcpuset_t
-    *kcp2);

-
void
-  

-  kcpuset_atomicly_merge(kcpuset_t
-    *kcp1, const kcpuset_t
-    *kcp2);

-
void
-  

-  kcpuset_atomicly_remove(kcpuset_t
-    *kcp1, const kcpuset_t
-    *kcp2);

-
void
-  

-  kcpuset_export_u32(const
-    kcpuset_t *kcp, uint32_t
-    *bitfield, size_t
-    len);

-

-

-

-
The machine-independent kcpuset subsystem
-    provides support for dynamic processor sets. Conceptually
-    kcpuset can be understood to be the kernel
-    equivalent of the user space cpuset(3) interface.

-

-

-

-

-  
(retkcp,
-    zero)

-  
The kcpuset_create() function creates a dynamic
-      CPU set and stores the result to retkcp. If the
-      boolean zero is not false, the allocated set is also
-      initialized to zero.

-  
(kcp)

-  
Destroys the CPU set kcp and schedules any linked
-      CPU sets for deferred destruction.

-  
(dkcp,
-    skcp)

-  
Copies the CPU set pointed by skcp to
-      dkcp.

-  
(retkcp,
-    skcp)

-  
Creates a dynamic CPU set and stores the result to
-      retkcp and copies the CPU set pointed by
-      skcp to the new CPU set.

-  
(kcp)

-  
Marks kcp as being in use by increasing the
-      reference count of the object. Note that initially
-      kcpuset_create() sets the reference count to
-    1.

-  
(kcp,
-    lst)

-  
Decreases the internal reference count of kcp, and
-      on the last reference (when the count reaches zero), destroys
-      kcp. If lst is not
-      NULL, then instead of destroying,
-      kcp will be added to the lst
-      list for a deferred destruction.

-  
(ucp,
-    kcp, len)

-  
Copies the len bytes long user-space CPU set
-      ucp to the kernel CPU set
-    kcp.

-  
(kcp,
-    ucp, len)

-  
Copies the kernel CPU set kcp to the user-space CPU
-      set ucp.

-  
(kcp)

-  
Clears the set kcp.

-  
(kcp)

-  
Fills the whole set kcp with ones.

-  
(kcp,
-    cpu)

-  
Adds cpu to the set kcp.

-  
(kcp,
-    cpu)

-  
Removes cpu from the set
-    kcp.

-  
(kcp,
-    cpu)

-  
Returns true if cpu is part of the CPU set
-      kcp.

-  
(kcp,
-    cpu)

-  
Returns true if there any CPUs other than cpu in the
-      CPU set kcp.

-  
(kcp)

-  
Returns true if the set kcp is empty.

-  
(kcp1,
-    kcp2)

-  
Compares the sets kcp1 and
-      kcp2, returning true if these are identical.

-  
(kcp1,
-    kcp2)

-  
Removes any CPU not set in kcp2 from the set
-      kcp1.

-  
(kcp1,
-    kcp2)

-  
Merges the set kcp2 to the set
-      kcp1.

-  
(kcp1,
-    kcp2)

-  
Removes any CPU present in kcp2 from the set
-      kcp1.

-  
(kcp)

-  
Returns the lowest numbered cpu present in
-      kcp plus 1. If kcp is empty, a
-      value of 0 is returned. kcp

-  
(kcp1,
-    kcp2)

-  
Returns the lowest numbered cpu present in the
-      intersection of kcp1 and kcp2
-      plus 1. If the intersection is empty, a value of 0 is returned.

-  
(kcp)

-  
Counts how many CPUs are in the set kcp.

-  
(kcp,
-    cpu)

-  
The kcpuset_atomic_set() function operates as
-      kcpuset_set(), but the operation is atomic; see
-      atomic_ops(3) for more details.

-  
(kcp,
-    cpu)

-  
Removes cpu from the CPU set
-      kcp atomically.

-  
(kcp1,
-    kcp2)

-  
The kcpuset_atomicly_intersect() function operates
-      as kcpuset_intersect(), but the operation is
-      performed using atomic operations; see atomic_ops(3) for
-      more details.

-  
(kcp1,
-    kcp2)

-  
The kcpuset_atomicly_merge() function operates as
-      kcpuset_merge(), but the operation is performed
-      using atomic operations; see atomic_ops(3) for more
-      details.

-  
(kcp1,
-    kcp2)

-  
The kcpuset_atomicly_remove() function operates as
-      kcpuset_remove(), but the operation is performed
-      using atomic operations; see atomic_ops(3) for more
-      details.

-  
(kcp,
-    bitfield, len)

-  
Exports the CPU set kcp into a format of 32-bit
-      integer array, specified by bitfield and length in
-      bytes by len. An integers is in the host byte-order
-      and represents a bit field. The first bit at index zero represents CPU
-      number 0, and so on.

-

-

-

-

-
The kcpuset subsystem is implemented
-    within sys/kern/subr_kcpuset.c.

-

-

-

-
cpuset(3)

-

-

-

-
The kcpuset subsystem first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
July 17, 2013NetBSD 10.1

diff --git a/static/netbsd/man9/kmem.9 3.html b/static/netbsd/man9/kmem.9 3.html
deleted file mode 100644
index 1acd9611..00000000
--- a/static/netbsd/man9/kmem.9 3.html	
+++ /dev/null
@@ -1,297 +0,0 @@
-
-  
-    
-    
-    
-  
-
KMEM(9)Kernel Developer's ManualKMEM(9)

-

-

-

-
kmem — kernel
-    wired memory allocator

-

-

-

-
#include
-    <sys/kmem.h>

-
void *
-  

-  kmem_alloc(size_t
-    size, km_flag_t
-    kmflags);

-
void *
-  

-  kmem_zalloc(size_t
-    size, km_flag_t
-    kmflags);

-
void
-  

-  kmem_free(void
-    *p, size_t
-  size);

-
void *
-  

-  kmem_intr_alloc(size_t
-    size, km_flag_t
-    kmflags);

-
void *
-  

-  kmem_intr_zalloc(size_t
-    size, km_flag_t
-    kmflags);

-
void
-  

-  kmem_intr_free(void
-    *p, size_t
-  size);

-
char *
-  

-  kmem_asprintf(const
-    char *fmt,
-  ...);

-
char *
-  

-  kmem_strdupsize(const
-    char *str, size_t
-    *size, km_flag_t
-    kmflags);

-
char *
-  

-  kmem_strdup(const
-    char *str, km_flag_t
-    kmflags);

-
char *
-  

-  kmem_strndup(const
-    char *str, size_t
-    manxlen, km_flag_t
-    kmflags);

-
void
-  

-  kmem_strfree(char
-    *str);

-
void *
-  

-  kmem_tmpbuf_alloc(size_t
-    size, void
-    *stackbuf, size_t
-    stackbufsize, km_flag_t
-    kmflags);

-
void
-  

-  kmem_tmpbuf_free(void
-    *p, size_t size,
-    void *stackbuf);

-

-  

-  options KMEM_SIZE

-

-

-

-
()
-    allocates kernel wired memory. It takes the following arguments.

-

-  
size

-  
Specify the size of allocation in bytes.

-  
kmflags

-  
Either of the following:
-    

-      

-      
If the allocation cannot be satisfied immediately, sleep until enough
-          memory is available. If KM_SLEEP is specified,
-          then the allocation cannot fail.

-      

-      
Don't sleep. Immediately return NULL if there
-          is not enough memory available. It should only be used when failure to
-          allocate will not have harmful, user-visible effects.
-        

-        
Use of KM_NOSLEEP is strongly
-          discouraged as it can create transient, hard to debug failures that
-          occur when the system is under memory pressure.

-        
In situations where it is not possible to sleep, for
-            example because locks are held by the caller, the code path should
-            be restructured to allow the allocation to be made in another
-          place.

-      

-    

-  

-

-
The contents of allocated memory are uninitialized.

-
Unlike Solaris, kmem_alloc(0, flags) is illegal.

-
()
-    is the equivalent of kmem_alloc(), except that it
-    initializes the memory to zero.

-
()
-    functions as the well known
-    ()
-    function, but allocates memory using kmem_alloc().
-    This routine can sleep during allocation. The size of the allocated area is
-    the length of the returned character string, plus one (for the NUL
-    terminator). This must be taken into consideration when freeing the returned
-    area with kmem_free().

-
()
-    frees kernel wired memory allocated by kmem_alloc()
-    or kmem_zalloc() so that it can be used for other
-    purposes. It takes the following arguments.

-

-  
p

-  
The pointer to the memory being freed. It must be the one returned by
-      kmem_alloc() or
-      kmem_zalloc().

-  
size

-  
The size of the memory being freed, in bytes. It must be the same as the
-      size argument used for
-      kmem_alloc() or
-      kmem_zalloc() when the memory was allocated.

-

-
Freeing NULL is illegal.

-
(),
-    ()
-    and
-    ()
-    are the equivalents of the above kmem routines which can be called from the
-    interrupt context. These routines are for the special cases. Normally,
-    pool_cache(9) should be used for memory allocation from
-    interrupt context.

-
The
-    ()
-    function is a utility function that can be used to copy the string in the
-    str argument to a new buffer allocated using
-    kmem_alloc() and optionally return the size of the
-    allocation (the length of the string plus the trailing
-    NUL) in the size argument if
-    that is not NULL.

-
The
-    ()
-    function is a simplified version of
-    kmem_strdupsize() that does not return the size of
-    the allocation.

-
The
-    ()
-    function is variation of kmem_strdup() that copies
-    at most maxlen characters from the string
-    str always NUL terminating the copied string.

-
The
-    ()
-    function can be used to free a NUL terminated string
-    computing the length of the string using strlen(3) and
-    adding one for the NUL and then using
-    kmem_free().

-
The
-    ()
-    function is a utility function for allocating memory for temporary use,
-    where allocation on the stack is desirable, but only up to a certain size.
-    If the requested size fits within the specified stack buffer, the stack
-    buffer is returned. Otherwise, memory is allocated with
-    kmem_alloc(). The
-    ()
-    function compares the result of a previous call to
-    kmem_tmpbuf_alloc() and frees the memory using
-    kmem_free() if it is not the specified stack
-  buffer.

-

-

-

-
Making KM_SLEEP allocations while holding
-    mutexes or reader/writer locks is discouraged, as the caller can sleep for
-    an unbounded amount of time in order to satisfy the allocation. This can in
-    turn block other threads that wish to acquire locks held by the caller. It
-    should be noted that kmem_free() may also block.

-
For some locks this is permissible or even unavoidable. For
-    others, particularly locks that may be taken from soft interrupt context, it
-    is a serious problem. As a general rule it is better not to allow this type
-    of situation to develop. One way to circumvent the problem is to make
-    allocations speculative and part of a retryable sequence. For example:

-

-
  retry:
-        /* speculative unlocked check */
-        if (need to allocate) {
-                new_item = kmem_alloc(sizeof(*new_item), KM_SLEEP);
-        } else {
-                new_item = NULL;
-        }
-        mutex_enter(lock);
-        /* check while holding lock for true status */
-        if (need to allocate) {
-                if (new_item == NULL) {
-                        mutex_exit(lock);
-                        goto retry;
-                }
-                consume(new_item);
-                new_item = NULL;
-        }
-        mutex_exit(lock);
-        if (new_item != NULL) {
-                /* did not use it after all */
-                kmem_free(new_item, sizeof(*new_item));
-        }

-

-

-

-

-

-

-
Kernels compiled with the KMEM_SIZE option
-    ensure the size given in
-    ()
-    matches the actual allocated size. On kmem_alloc(),
-    the kernel will allocate an additional contiguous kmem page of eight bytes
-    in the buffer, will register the allocated size in the first kmem page of
-    that buffer, and will return a pointer to the second kmem page in that same
-    buffer. When freeing, the kernel reads the first page, and compares the size
-    registered with the one given in kmem_free(). Any
-    mismatch triggers a panic.

-
KMEM_SIZE is enabled by default on
-    DIAGNOSTIC.

-

-

-

-

-
On success, kmem_alloc(),
-    kmem_asprintf(),
-    kmem_intr_alloc(),
-    kmem_intr_zalloc(),
-    kmem_strdupsize(), and
-    kmem_zalloc() return a pointer to allocated memory.
-    Otherwise, NULL is returned.

-

-

-

-
The kmem subsystem is implemented within
-    the file sys/kern/subr_kmem.c.

-

-

-

-
intro(9), memoryallocators(9),
-    percpu(9), pool_cache(9),
-    uvm_km(9)

-

-

-

-
The kmem_alloc(),
-    kmem_asprintf(),
-    kmem_free(),
-    kmem_strdupsize(),
-    kmem_strfree(), and
-    kmem_zalloc() functions cannot be used from
-    interrupt context, from a soft interrupt, or from a callout. Use
-    pool_cache(9) in these situations.

-

-

-

-
As the memory allocated by kmem_alloc() is
-    uninitialized, it can contain security-sensitive data left by its previous
-    user. It is the caller's responsibility not to expose it to the world.

-

-

-
-  
-    
-    
-  
-
January 24, 2021NetBSD 10.1

diff --git a/static/netbsd/man9/localcount.9 3.html b/static/netbsd/man9/localcount.9 3.html
deleted file mode 100644
index d71eac71..00000000
--- a/static/netbsd/man9/localcount.9 3.html	
+++ /dev/null
@@ -1,170 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOCALCOUNT(9)Kernel Developer's ManualLOCALCOUNT(9)

-

-

-

-
localcount,
-    localcount_init,
-    localcount_fini,
-    localcount_acquire,
-    localcount_release,
-    localcount_drain —
-    reference-count primitives

-

-

-

-
#include
-    <sys/localcount.h>

-
void
-  

-  localcount_init(struct
-    localcount *lc);

-
void
-  

-  localcount_fini(struct
-    localcount *lc);

-
void
-  

-  localcount_acquire(struct
-    localcount *lc);

-
void
-  

-  localcount_release(struct
-    localcount *lc, struct
-    kcondvar *cv, struct
-    kmutex *mtx);

-
void
-  

-  localcount_drain(struct
-    localcount *lc, struct
-    kcondvar *cv, struct
-    kmutex *mtx);

-

-

-

-
Localcounts are used in the kernel to implement a medium-weight
-    reference counting mechanism. During normal operations, localcounts do not
-    need the interprocessor synchronization associated with
-    atomic_ops(3) atomic memory operations, and (unlike
-    psref(9)) localcount references
-    can be held across sleeps and can migrate between CPUs. Draining a
-    localcount requires more expensive interprocessor
-    synchronization than atomic_ops(3) (similar to
-    psref(9)). And localcount
-    references require eight bytes of memory per object per-CPU, significantly
-    more than atomic_ops(3) and almost always more than
-    psref(9).

-
As a rough heuristic, localcount should be
-    used for classes of objects of which there are perhaps a few dozen instances
-    (such as autoconf(9) devices) but not thousands of
-    instances (such as network flows) and on which there may be a mixture of
-    long-term I/O waits, such as xyzread for a device xyz(4), and short-term
-    fast operations, such as
-    xyzioctl(IOC_READ_A_CPU_REG).

-

-

-

-

-  
(lc)

-  
Dynamically initialize localcount lc for use.
-    
No other operations can be performed on a localcount until it
-        has been initialized.

-  

-  
(lc)

-  
Release resources used by localcount lc. The caller
-      must have already called localcount_drain(). The
-      localcount may not be used after localcount_fini()
-      has been called until it has been re-initialized by
-      localcount_init().

-  
localcount_acquire(lc)

-  
Acquire a reference to the localcount lc.
-    
The caller must ensure by some other
-        mechanism that the localcount will not be destroyed before the call to
-        ();
-        typically this will be via a pserialize(9) read
-        section.

-  

-  
(lc,
-    cv, mtx)

-  
Release a reference to the localcount lc. If the
-      localcount is currently being drained, the mutex mtx
-      will be used to synchronize updates to the global reference count (i.e.,
-      the total across all CPUs). If the reference count goes to zero,
-      localcount_release() will broadcast availability
-      of the condvar cv.

-  
localcount_drain(lc,
-    cv, mtx)

-  
Wait for all references to the localcount lc to be
-      released. The caller must hold the mutex mtx; the
-      mutex will be released during inter-CPU cross-calls (see
-      xcall(9)) and while waiting on the condvar
-      cv. The same cv and
-      mtx must be used with
-      localcount_release().
-    
The caller must guarantee that no
-        new references can be acquired with
-        ()
-        before calling localcount_drain(). For example,
-        any object that may be found in a list and acquired must be removed from
-        the list before calling localcount_drain();
-        removal from the list would typically be protected by calling
-        pserialize_perform(9) to wait for any
-        pserialize(9) readers to complete.

-    
Once the localcount object
-        lc is passed to
-        (),
-        it must be passed to localcount_fini() before
-        any other re-use.

-  

-

-

-

-

-
The core of the localcount implementation is located in
-    sys/kern/subr_localcount.c.

-
The header file sys/sys/localcount.h
-    describes the public interface, and interfaces that machine-dependent code
-    must provide to support localcounts.

-

-

-

-
atomic_ops(3), condvar(9),
-    mutex(9), psref(9)

-

-

-

-
The localcount primitives first appeared in
-    NetBSD 8.0.

-

-

-

-
localcount was designed by
-    Taylor R. Campbell, who also provided a draft
-    implementation. The implementation was completed, tested, and integrated by
-    Paul Goyette.

-

-

-

-
The localcount facility does not provide
-    any way to examine the reference count without actually waiting for the
-    count to reach zero.

-
Waiting for a localcount reference count
-    to drain (reach zero) is a one-shot operation. Once the
-    localcount has been drained, no further operations
-    are allowed until the localcount has been
-    re-initialized.

-

-

-
-  
-    
-    
-  
-
February 25, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/lock.9 3.html b/static/netbsd/man9/lock.9 3.html
deleted file mode 100644
index 304547b0..00000000
--- a/static/netbsd/man9/lock.9 3.html	
+++ /dev/null
@@ -1,49 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOCK(9)Kernel Developer's ManualLOCK(9)

-

-

-

-
lock,
-    simple_lock_init,
-    simple_lock,
-    simple_lock_try,
-    simple_unlock,
-    simple_lock_freecheck,
-    simple_lock_dump, lockinit,
-    lockmgr, lockstatus,
-    lockmgr_printinfo,
-    spinlockinit, spinlockmgr
-    — kernel lock functions

-

-

-

-
These interfaces have been obsoleted and removed from the
-  system.

-
Please see the condvar(9),
-    mutex(9), and rwlock(9) manual pages for
-    information on kernel synchronisation primitives.

-

-

-

-
condvar(9), mutex(9),
-    rwlock(9)

-

-

-

-
The kernel locking API first appeared in
-    4.4BSD-lite2, and was replaced in
-    NetBSD 5.0.

-

-

-
-  
-    
-    
-  
-
January 30, 2008NetBSD 10.1

diff --git a/static/netbsd/man9/locking.9 3.html b/static/netbsd/man9/locking.9 3.html
deleted file mode 100644
index 9704a7c1..00000000
--- a/static/netbsd/man9/locking.9 3.html	
+++ /dev/null
@@ -1,333 +0,0 @@
-
-  
-    
-    
-    
-  
-
LOCKING(9)Kernel Developer's ManualLOCKING(9)

-

-

-

-
locking —
-    introduction to kernel synchronization and interrupt
-    control

-

-

-

-
The NetBSD kernel provides several
-    synchronization and interrupt control primitives. This man page aims to give
-    an overview of these interfaces and their proper application. Also included
-    are basic kernel thread control primitives and a rough overview of the
-    NetBSD kernel design.

-

-

-

-
The aim of synchronization, threads and interrupt control in the
-    kernel is:

-
    
-  
  • To control concurrent access to shared resources (critical sections).
    • 
-  
  • Spawn tasks from an interrupt in the thread context.
    • 
-  
  • Mask interrupts from threads.
    • 
-  
  • Scale on multiple CPU system.
    • 
-

-
There are three types of contexts in the
-    NetBSD kernel:

-
    
-  
  •  - running processes (represented by
-      struct proc) and light-weight processes
-      (represented by struct lwp, also known as kernel
-      threads). Code in this context can sleep, block resources and own
-      address-space.
    • 
-  
  •  - limited by thread context. Code in this
-      context must be processed shortly. These interrupts don't own any address
-      space context. Software interrupts are a way of deferring hardware
-      interrupts to do more expensive processing at a lower interrupt
-    priority.
    • 
-  
  •  - Code in this context must be processed as quickly as
-      possible. It is forbidden for a piece of code to sleep or access
-      long-awaited resources here.
    • 
-

-
The main differences between processes and kernel threads are:

-
    
-  
  • A single process can own multiple kernel threads (LWPs).
    • 
-  
  • A process owns address space context to map userland address space.
    • 
-  
  • Processes are designed for userland executables and kernel threads for
-      in-kernel tasks. The only process running in the kernel-space is
-      proc0 (called swapper).
    • 
-

-

-

-

-

-

-
The atomic_ops family of functions provide
-    atomic memory operations. There are 7 classes of atomic memory operations
-    available: addition, logical “and”, compare-and-swap,
-    decrement, increment, logical “or”, swap.

-
See atomic_ops(3).

-

-

-

-
Condition variables (CVs) are used in the kernel to synchronize
-    access to resources that are limited (for example, memory) and to wait for
-    pending I/O operations to complete.

-
See condvar(9).

-

-

-

-
The membar_ops family of functions provide
-    memory access barrier operations necessary for synchronization in
-    multiprocessor execution environments that have relaxed load and store
-    order.

-
See membar_ops(3).

-

-

-

-
The memory barriers can be used to control the order in which
-    memory accesses occur, and thus the order in which those accesses become
-    visible to other processors. They can be used to implement
-    “lockless” access to data structures where the necessary
-    barrier conditions are well understood.

-

-

-

-
Thread-base adaptive mutexes. These are lightweight, exclusive
-    locks that use threads as the focus of synchronization activity. Adaptive
-    mutexes typically behave like spinlocks, but under specific conditions an
-    attempt to acquire an already held adaptive mutex may cause the acquiring
-    thread to sleep. Sleep activity occurs rarely. Busy-waiting is typically
-    more efficient because mutex hold times are most often short. In contrast to
-    pure spinlocks, a thread holding an adaptive mutex may be pre-empted in the
-    kernel, which can allow for reduced latency where soft real-time application
-    are in use on the system.

-
See mutex(9).

-

-

-

-
Restartable atomic sequences are user code only sequences which
-    are guaranteed to execute without preemption. This property is assured by
-    checking the set of restartable atomic sequences registered for a process
-    during cpu_switchto(9). If a process is found to have been
-    preempted during a restartable sequence, then its execution is rolled-back
-    to the start of the sequence by resetting its program counter which is saved
-    in its process control block (PCB).

-
See ras(9).

-

-

-

-
Reader / writer locks (RW locks) are used in the kernel to
-    synchronize access to an object among LWPs (lightweight processes) and soft
-    interrupt handlers. In addition to the capabilities provided by mutexes, RW
-    locks distinguish between read (shared) and write (exclusive) access.

-
See rwlock(9).

-

-

-

-
These functions raise and lower the interrupt priority level. They
-    are used by kernel code to block interrupts in critical sections, in order
-    to protect data structures.

-
See spl(9).

-

-

-

-
The software interrupt framework is designed to provide a generic
-    software interrupt mechanism which can be used any time a low-priority
-    callback is required. It allows dynamic registration of software interrupts
-    for loadable drivers, protocol stacks, software interrupt prioritization,
-    software interrupt fair queuing and allows machine-dependent optimizations
-    to reduce cost.

-
See softint(9).

-

-

-

-
The splraiseipl function raises the system
-    priority level to the level specified by icookie,
-    which should be a value returned by makeiplcookie(9). In
-    general, device drivers should not make use of this interface. To ensure
-    correct synchronization, device drivers should use the
-    condvar(9), mutex(9), and
-    rwlock(9) interfaces.

-
See splraiseipl(9).

-

-

-

-
Passive serialization is a reader / writer synchronization
-    mechanism designed for lock-less read operations. The read operations may
-    happen from software interrupt at IPL_SOFTCLOCK.

-
See pserialize(9).

-

-

-

-
Passive references allow CPUs to cheaply acquire and release
-    passive references to a resource, which guarantee the resource will not be
-    destroyed until the reference is released. Acquiring and releasing passive
-    references requires no interprocessor synchronization, except when the
-    resource is pending destruction.

-
See psref(9).

-

-

-

-
Localcounts are used in the kernel to implement a medium-weight
-    reference counting mechanism. During normal operations, localcounts do not
-    need the interprocessor synchronization associated with
-    atomic_ops(3) atomic memory operations, and (unlike
-    psref(9)) localcount references can be held across sleeps
-    and can migrate between CPUs. Draining a localcount requires more expensive
-    interprocessor synchronization than atomic_ops(3) (similar
-    to psref(9)). And localcount references require eight
-    bytes of memory per object per-CPU, significantly more than
-    atomic_ops(3) and almost always more than
-    psref(9).

-
See localcount(9).

-

-

-

-
The workqueue utility routines are provided to defer work which is
-    needed to be processed in a thread context.

-
See workqueue(9).

-

-

-

-

-
The following table describes in which contexts the use of the
-    NetBSD kernel interfaces are valid. Synchronization
-    primitives which are available in more than one context can be used to
-    protect shared resources between the contexts they overlap.

-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
atomic_ops(3)yesyesyes
condvar(9)yespartlyno
membar_ops(3)yesyesyes
mutex(9)yesdependsdepends
rwlock(9)yesyesno
softint(9)yesyesyes
spl(9)yesnono
splraiseipl(9)yesnono
pserialize(9)yesyesno
psref(9)yesyesno
localcount(9)yesyesno
workqueue(9)yesyesyes

-

-

-

-
atomic_ops(3), membar_ops(3),
-    condvar(9), mutex(9),
-    ras(9), rwlock(9),
-    softint(9), spl(9),
-    splraiseipl(9), workqueue(9)

-

-

-

-
Initial SMP support was introduced in NetBSD
-    2.0 and was designed with a giant kernel lock. Through
-    NetBSD 4.0, the kernel used spinlocks and a per-CPU
-    interrupt priority level (the spl(9) system). These
-    mechanisms did not lend themselves well to a multiprocessor environment
-    supporting kernel preemption. The use of thread based (lock) synchronization
-    was limited and the available synchronization primitive (lockmgr) was
-    inefficient and slow to execute. NetBSD 5.0
-    introduced massive performance improvements on multicore hardware by Andrew
-    Doran. This work was sponsored by The NetBSD
-    Foundation.

-
A locking manual first appeared in
-    NetBSD 8.0 and was inspired by the corresponding
-    locking manuals in FreeBSD
-    and DragonFly.

-

-

-

-
Kamil Rytarowski
-    <kamil@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
August 23, 2017NetBSD 10.1

diff --git a/static/netbsd/man9/ltsleep.9 3.html b/static/netbsd/man9/ltsleep.9 3.html
deleted file mode 100644
index 852103ea..00000000
--- a/static/netbsd/man9/ltsleep.9 3.html	
+++ /dev/null
@@ -1,203 +0,0 @@
-
-  
-    
-    
-    
-  
-
LTSLEEP(9)Kernel Developer's ManualLTSLEEP(9)

-

-

-

-
ltsleep, mtsleep,
-    tsleep, wakeup —
-    process context sleep and wakeup

-

-

-

-
#include
-    <sys/proc.h>

-
int
-  

-  mtsleep(wchan_t
-    ident, pri_t
-    priority, const char
-    *wmesg, int timo,
-    kmutex_t *mtx);

-
int
-  

-  tsleep(wchan_t
-    ident, pri_t
-    priority, const char
-    *wmesg, int
-  timo);

-
void
-  

-  wakeup(wchan_t
-    ident);

-

-

-

-
The interfaces described in this manual page are
-    obsolete and will be removed from a future version of the
-    system.

-
The
-    ()
-    

-
 condvar(9), mutex(9),
-    and rwlock(9)
-    

-
These functions implement voluntary context switching.
-    () and
-    mtsleep() are used throughout the kernel whenever
-    processing in the current context can not continue for any of the following
-    reasons:

-
    
-  
  • The current process needs to await the results of a pending I/O
-    operation.
    • 
-  
  • The current process needs resources (e.g., memory) which are temporarily
-      unavailable.
    • 
-

-
The function
-    () is
-    used to notify sleeping processes of possible changes to the condition that
-    caused them to go to sleep. Typically, an awakened process will —
-    after it has acquired a context again — retry the action that blocked
-    its operation to see if the “blocking” condition has
-  cleared.

-
The
-    ()
-    and mtsleep() functions take the following
-    arguments:

-

-  
ident

-  
An identifier of the “wait channel” representing the
-      resource for which the current process needs to wait. This typically is
-      the virtual address of some kernel data-structure related to the resource
-      for which the process is contending. The same identifier must be used in a
-      call to wakeup() to get the process going again.
-      ident should not be
-    NULL.

-  
priority

-  
The process priority to be used when the process is awakened and put on
-      the queue of runnable processes. This mechanism is used to optimize
-      “throughput” of processes executing in kernel mode. If the
-      flag PCATCH is OR'ed into
-      priority the process checks for posted signals
-      before and after sleeping.

-  
wmesg

-  
A pointer to a character string indicating the reason a process is
-      sleeping. The kernel does not use the string, but makes it available
-      (through the process structure field p_wmesg) for
-      user level utilities such as ps(1).

-  
timo

-  
If non-zero, the process will sleep for at most
-      timo/hz seconds. If this amount of time elapses
-      and no wakeup(ident) has
-      occurred, and no signal (if PCATCH
-      was set) was posted,
-      tsleep() will return
-      EWOULDBLOCK.

-

-
The
-    ()
-    function takes an additional argument and flag:

-

-  
mtx

-  
A mutex(9) representing the lock protecting the
-      data-structures. On entry mtsleep() will release
-      the lock and re-acquire the lock on return.

-  
priority

-  
If the flag PNORELOCK is OR'ed into
-      priority then mtsleep() will
-      not re-acquire the lock.

-

-
The
-    ()
-    function will mark all processes which are currently sleeping on the
-    identifier ident as runnable. Eventually, each of the
-    processes will resume execution in the kernel context, causing a return from
-    tsleep() or mtsleep(). Note
-    that processes returning from sleep should always re-evaluate the conditions
-    that blocked them, since a call to wakeup() merely
-    signals a
-    
-    change to the blocking conditions.

-

-

-

-
tsleep() and
-    mtsleep() return 0 if they return as a result of a
-    wakeup(). If a tsleep() and
-    mtsleep() return as a result of a signal, the return
-    value is ERESTART if the signal has the
-    SA_RESTART property (see
-    sigaction(2)), and EINTR
-    otherwise. If tsleep() and
-    mtsleep() return because of a timeout, the return
-    value is EWOULDBLOCK.

-

-

-

-
Note the conversion from tsleep/wakeup into
-    condvar(9) should not be done mechanically i.e.
-    “blindly”. Code logic should be understood before changing,
-    and it may also need to be revisited for the change. Please also read the
-    condvar(9) man page.

-
The
-    ()
-    and mtsleep(), and wakeup()
-    pairs should generally be replaced by cv_wait(9) /
-    cv_wait_sig(9) / cv_timedwait(9) /
-    cv_timedwait_sig(9) and cv_signal(9) /
-    cv_broadcast(9) pairs. The
-    ()
-    variant to use can be determined from looking at the corresponding
-    tsleep() usage.

-
There are two arguments of interest: timo
-    and priority. The priority value
-    may have OR'ed the flag PCATCH.

-
The PCATCH flag means that the blocking
-    thread should be awoken on signal, and the sleep call should be replaced
-    with cv_wait_sig(9).

-
The timo value, if it is not zero, indicates
-    how long to sleep, and the sleep call should be replaced with
-    cv_timedwait(9).

-
If both the PCATCH flag and a non-zero
-    timo value are specified, then
-    cv_timedwait_sig(9) should be used.

-
A mutex(9) (interlock) must be held
-    across
-    ()
-    and
-    ()
-    calls, in order to protect state. Most old code will require the addition of
-    locking, whereas some will require amending to remove
-    PNORELOCK.

-

-

-

-
sigaction(2), condvar(9),
-    hz(9), kpause(9),
-    mutex(9), rwlock(9)

-

-

-

-
The sleep/wakeup process synchronization mechanism is very old. It
-    appeared in a very early version of Unix. tsleep()
-    appeared in 4.4BSD.
-    ltsleep() appeared in NetBSD
-    1.5.

-

-

-
-  
-    
-    
-  
-
May 7, 2024NetBSD 10.1

diff --git a/static/netbsd/man9/man9.x86/rdmsr.9 3.html b/static/netbsd/man9/man9.x86/rdmsr.9 3.html
deleted file mode 100644
index e964d37b..00000000
--- a/static/netbsd/man9/man9.x86/rdmsr.9 3.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
RDMSR(9)Kernel Developer's Manual (x86)RDMSR(9)

-

-

-

-
msr, rdmsr,
-    rdmsr_safe, wrmsr —
-    functions for x86 MSRs

-

-

-

-
#include
-    <x86/cpufunc.h>

-
uint64_t
-  

-  rdmsr(u_int
-    msr);

-
int
-  

-  rdmsr_safe(u_int
-    msr, uint64_t
-    *valp);

-
void
-  

-  wrmsr(u_int
-    msr, uint64_t
-  val);

-

-

-

-
The RDMSR instruction reads from a x86
-    model-specific register (MSR). Conversely, the
-    WRMSR instruction is used to write to a
-    MSR. In NetBSD the
-    (),
-    rdmsr_safe(), and
-    ()
-    functions are used to access MSRs. The header
-    <x86/specialreg.h> includes
-    definitions for some of the commonly used MSRs, that is, control registers
-    that are present in some x86 processor models but unavailable in others.

-

-

-

-

-  
rdmsr(msr)

-  
Returns the value read from msr.

-  
rdmsr_safe(msr,
-    valp)

-  
The rdmsr_safe() function is a safer variant of
-      rdmsr(). Upon successful completion, the function
-      returns zero and the value read from the register
-      msr is returned in valp. If a
-      fault occurs while accessing msr,
-      rdmsr_safe() returns
-      EFAULT.

-  
wrmsr(msr,
-    val)

-  
The wrmsr() function writes
-      val to the register msr.

-

-
Note that even though
-    ()
-    provides support for reading MSRs in a safe manner,
-    it is still a good practice to always verify that the given model-specific
-    register is present by using the CPUID instruction,
-    available in NetBSD via
-    ().

-

-

-

-
rdtsc(9),
-  x86/x86_msr_xcall(9)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man9/man9.x86/tsc.9 3.html b/static/netbsd/man9/man9.x86/tsc.9 3.html
deleted file mode 100644
index cf839df4..00000000
--- a/static/netbsd/man9/man9.x86/tsc.9 3.html	
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    
-    
-    
-  
-
TSC(9)Kernel Developer's Manual (x86)TSC(9)

-

-

-

-
tsc — Time Stamp
-    Counter

-

-

-

-
#include
-    <x86/x86/tsc.h>

-
uint64_t
-  

-  rdtsc(void);

-
void
-  

-  tsc_tc_init(void);

-
void
-  

-  tsc_sync_ap(struct
-    cpu_info *ci);

-
void
-  

-  tsc_sync_bp(struct
-    cpu_info *ci);

-
void
-  

-  tsc_sync_drift(int64_t
-    drift);

-

-

-

-
The time stamp counter (TSC) is a hardware counter found in all
-    contemporary x86 processors. The counter is implemented as a 64-bit
-    model-specific register (MSR) that is incremented at every clock cycle. The
-    RDTSC (“read time stamp counter”) register has been present
-    since the original Pentium.

-
Already because of the access method, TSC provides a low-overhead
-    and high-resolution way to obtain CPU timing information. This traditional
-    premise was violated when such factors as system sleep states, CPU
-    “hotplugging”, “hibernation”, and CPU frequency
-    scaling were introduced to the x86 lineage. This was however mainly a short
-    abruption: in many new x86 CPUs the time stamp counter is again invariant
-    with respect to the stability of the clock frequency. Care should be however
-    taken in implementations that rely on this assumption.

-

-

-

-

-  
()

-  
The rdtsc() function returns the value read from
-      RDTSC.

-  
()

-  
The tsc_tc_init() function initializes the TSC as
-      a timecounter(9). The function is called early in the
-      boot process when the processors attach.

-  
tsc_sync_bp(ci)

-  
The tsc_sync_bp() function synchronizes the
-      counter for the boot processor (BP). The supplied ci
-      must refer to the BP itself. The tsc interface
-      takes internally care of such issues as out-of-order execution, where
-      instructions are not necessarily performed in the order of execution,
-      possibly causing a misleading cycle count.

-  
tsc_sync_ap(ci)

-  
The tsc_sync_ap() function synchronize the counter
-      for the application processor ci. Interrupts must be
-      off at machine-level when the function is called.
-    
It is necessary to call both
-        ()
-        and
-        ()
-        during the boot, but additional synchronization may be required also
-        during runtime. As an example, the TSC needs to be synchronized for all
-        processors when the system resumes from an acpi(4)
-        sleep state.

-  

-  
(drift)

-  
Finally, the tsc_sync_drift() function records
-      drift, measured in clock cycles. This is called when
-      the APs attach.

-

-

-

-

-
gettimeofday(2), hpet(4),
-    hz(9), timecounter(9),
-    x86/rdmsr(9)

-

-

-
-  
-    
-    
-  
-
February 17, 2017NetBSD 10.1

diff --git a/static/netbsd/man9/memcmp.9 3.html b/static/netbsd/man9/memcmp.9 3.html
deleted file mode 100644
index 0d809b4b..00000000
--- a/static/netbsd/man9/memcmp.9 3.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEMCMP(9)Kernel Developer's ManualMEMCMP(9)

-

-

-

-
memcmp — compare
-    byte string

-

-

-

-
#include
-    <sys/systm.h>

-
int
-  

-  memcmp(const
-    void *b1, const void
-    *b2, size_t
-  len);

-

-

-

-
The
-    ()
-    function compares byte string b1 against byte string
-    b2. Both strings are assumed to be
-    len bytes long.

-

-

-

-
The memcmp() function returns zero if the
-    two strings are identical, otherwise returns the difference between the
-    first two differing bytes (treated as unsigned char values, so that
-    ‘\200’ is greater than
-    ‘\0’, for example). Zero-length
-    strings are always identical.

-

-

-

-
The memcmp() function conforms to
-    ANSI X3.159-1989
-  (“ANSI C89”).

-

-

-
-  
-    
-    
-  
-
July 7, 2001NetBSD 10.1

diff --git a/static/netbsd/man9/memset.9 3.html b/static/netbsd/man9/memset.9 3.html
deleted file mode 100644
index 43b06ae0..00000000
--- a/static/netbsd/man9/memset.9 3.html	
+++ /dev/null
@@ -1,50 +0,0 @@
-
-  
-    
-    
-    
-  
-
MEMSET(9)Kernel Developer's ManualMEMSET(9)

-

-

-

-
memset — write a
-    byte to byte string

-

-

-

-
#include
-    <sys/systm.h>

-
void *
-  

-  memset(void
-    *b, int c,
-    size_t len);

-

-

-

-
The
-    ()
-    function writes len bytes of value
-    c (converted to an unsigned char) to the string
-    b.

-

-

-

-
The memset() function returns the original
-    value of b.

-

-

-

-
The memset() function conforms to
-    ANSI X3.159-1989
-  (“ANSI C89”).

-

-

-
-  
-    
-    
-  
-
July 7, 2001NetBSD 10.1

diff --git a/static/netbsd/man9/microseq.9 3.html b/static/netbsd/man9/microseq.9 3.html
deleted file mode 100644
index 88fba6fd..00000000
--- a/static/netbsd/man9/microseq.9 3.html	
+++ /dev/null
@@ -1,531 +0,0 @@
-
-  
-    
-    
-    
-  
-
MICROSEQ(9)Kernel Developer's ManualMICROSEQ(9)

-

-

-

-
microseq — ppbus
-    microseqencer developer's guide

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include
-    <dev/ppbus/ppbus_conf.h>
-  

-  #include
-    <dev/ppbus/ppbus_msq.h>

-

-

-

-
See ppbus(4) for ppbus
-    description and general info about the microsequencer.

-
The purpose of this document is to encourage developers to use the
-    microsequencer mechanism in order to have:

-
    
-  
  1. a uniform programming model
    2. 
-  
  2. efficient code
    3. 
-

-
Before using microsequences, you are encouraged to look at the
-    atppc(4) microsequencer implementation and an example of
-    how using it in vpo(4).

-

-

-

-

-

-
The parallel port model chosen for ppbus(4) is
-    the PC parallel port model. Thus, any register described later has the same
-    semantic than its counterpart in a PC parallel port. For more info about
-    ISA/ECP programming, get the Microsoft standard referenced “Extended
-    Capabilities Port Protocol and ISA interface Standard”. Registers
-    described later are standard parallel port registers.

-
Mask macros are defined in the standard ppbus(4)
-    include files for each valid bit of parallel port registers.

-

-

-

-
In compatible or nibble mode, writing to this register will drive
-    data to the parallel port data lines. In any other mode, drivers may be
-    tri-stated by setting the direction bit (PCD) in the control register. Reads
-    to this register return the value on the data lines.

-

-

-

-
This read-only register reflects the inputs on the parallel port
-    interface.

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
7nBUSYinverted version of parallel port Busy signal
6nACKversion of parallel port nAck signal
5PERRORversion of parallel port PERROR signal
4SELECTversion of parallel port Select signal
3nFAULTversion of parallel port nFault signal

-
Others are reserved and return undefined result when read.

-

-

-

-
This register directly controls several output signals as well as
-    enabling some functions.

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
5PCDdirection bit in extended modes
4IRQENABLE1 enables an interrupt on the rising edge of nAck
3SELECTINinverted and driven as parallel port nSelectin signal
2nINITdriven as parallel port nInit signal
1AUTOFEEDinverted and driven as parallel port nAutoFd signal
0STROBEinverted and driven as parallel port nStrobe signal

-

-

-

-

-

-

-

-    are either parallel port accesses, program iterations, submicrosequence or C
-    calls. The parallel port must be considered as the logical model described
-    in ppbus(4).

-
Available microinstructions are:

-

-
#define MS_OP_GET       0	/* get <ptr>, <len>			*/
-#define MS_OP_PUT       1	/* put <ptr>, <len>			*/
-#define MS_OP_RFETCH	2	/* rfetch <reg>, <mask>, <ptr>		*/
-#define MS_OP_RSET	3	/* rset <reg>, <mask>, <mask>		*/
-#define MS_OP_RASSERT	4	/* rassert <reg>, <mask>		*/
-#define MS_OP_DELAY     5	/* delay <val>				*/
-#define MS_OP_SET       6	/* set <val>				*/
-#define MS_OP_DBRA      7	/* dbra <offset>			*/
-#define MS_OP_BRSET     8	/* brset <mask>, <offset>		*/
-#define MS_OP_BRCLEAR   9	/* brclear <mask>, <offset>		*/
-#define MS_OP_RET       10	/* ret <retcode>			*/
-#define MS_OP_C_CALL	11	/* c_call <function>, <parameter>	*/
-#define MS_OP_PTR	12	/* ptr <pointer>			*/
-#define MS_OP_ADELAY	13	/* adelay <val>				*/
-#define MS_OP_BRSTAT	14	/* brstat <mask>, <mask>, <offset>	*/
-#define MS_OP_SUBRET	15	/* subret <code>			*/
-#define MS_OP_CALL	16	/* call <microsequence>			*/
-#define MS_OP_RASSERT_P	17	/* rassert_p <iter>, <reg>		*/
-#define MS_OP_RFETCH_P	18	/* rfetch_p <iter>, <reg>, <mask>	*/
-#define MS_OP_TRIG	19	/* trigger <reg>, <len>, <array>	*/

-

-

-

-

-
The
-     of microinstructions is:

-
    
-  
  • the
-      
-      which points to the next microinstruction to execute either in the main
-      microsequence or in a subcall
    • 
-  
  • the current value of
-       which points to
-      the next char to send/receive
    • 
-  
  • the current value of the internal
-      
    • 
-

-
This data is modified by some of the microinstructions, not
-  all.

-

-

-

-
are microinstructions used to do either predefined standard
-    IEEE1284-1994 transfers or programmed non-standard I/O.

-

-

-

-
is used to retrieve the current value of a parallel port register,
-    apply a mask and save it in a buffer.

-
Parameters:

-
    
-  
  1. register
    2. 
-  
  2. character mask
    3. 
-  
  3. pointer to the buffer
    4. 
-

-
Predefined macro: MS_RFETCH(reg,mask,ptr)

-

-

-

-
is used to assert/clear some bits of a particular parallel port
-    register, two masks are applied.

-
Parameters:

-
    
-  
  1. register
    2. 
-  
  2. mask of bits to assert
    3. 
-  
  3. mask of bits to clear
    4. 
-

-
Predefined macro: MS_RSET(reg,assert,clear)

-

-

-

-
is used to assert all bits of a particular parallel port
-  register.

-
Parameters:

-
    
-  
  1. register
    2. 
-  
  2. byte to assert
    3. 
-

-
Predefined macro: MS_RASSERT(reg,byte)

-

-

-

-
is used to delay the execution of the microsequence.

-
Parameter:

-
    
-  
  1. delay in microseconds
    2. 
-

-
Predefined macro: MS_DELAY(delay)

-

-

-

-
is used to set the value of the internal branch register.

-
Parameter:

-
    
-  
  1. integer value
    2. 
-

-
Predefined macro: MS_SET(accum)

-

-

-

-
is used to branch if internal branch register decremented by one
-    result value is positive.

-
Parameter:

-
    
-  
  1. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    2. 
-

-
Predefined macro: MS_DBRA(offset)

-

-

-

-
is used to branch if some of the status register bits of the
-    parallel port are set.

-
Parameter:

-
    
-  
  1. bits of the status register
    2. 
-  
  2. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    3. 
-

-
Predefined macro: MS_BRSET(mask,offset)

-

-

-

-
is used to branch if some of the status register bits of the
-    parallel port are cleared.

-
Parameter:

-
    
-  
  1. bits of the status register
    2. 
-  
  2. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    3. 
-

-
Predefined macro: MS_BRCLEAR(mask,offset)

-

-

-

-
is used to return from a microsequence. This instruction is
-    mandatory. This is the only way for the microsequencer to detect the end of
-    the microsequence. The return code is returned in the integer pointed by the
-    (int *) parameter of the ppb_MS_microseq().

-
Parameter:

-
    
-  
  1. integer return code
    2. 
-

-
Predefined macro: MS_RET(code)

-

-

-

-
is used to call C functions from microsequence execution. This may
-    be useful when a non-standard I/O is performed to retrieve a data character
-    from the parallel port.

-
Parameter:

-
    
-  
  1. the C function to call
    2. 
-  
  2. the parameter to pass to the function call
    3. 
-

-
The C function shall be declared as a int(*)(void
-    *p, char *ptr). The ptr parameter is the current position in the
-    buffer currently scanned.

-
Predefined macro: MS_C_CALL(func,param)

-

-

-

-
is used to initialize the internal pointer to the currently
-    scanned buffer. This pointer is passed to any C call (see above).

-
Parameter:

-
    
-  
  1. pointer to the buffer that shall be accessed by
-      ()
-      microsequence calls. Note that this pointer is automatically incremented
-      during xxx_P() calls.
    2. 
-

-
Predefined macro: MS_PTR(ptr)

-

-

-

-
is used to make a cv_timedwait(9) during
-    microsequence execution.

-
Parameter:

-
    
-  
  1. delay in ms
    2. 
-

-
Predefined macro: MS_ADELAY(delay)

-

-

-

-
is used to branch on status register state condition.

-
Parameter:

-
    
-  
  1. mask of asserted bits. Bits that shall be asserted in the status register
-      are set in the mask
    2. 
-  
  2. mask of cleared bits. Bits that shall be cleared in the status register
-      are set in the mask
    3. 
-  
  3. integer offset in the current executed (sub)microsequence. Offset is added
-      to the index of the next microinstruction to execute.
    4. 
-

-
Predefined macro: MS_BRSTAT(asserted_bits,clear_bits,offset)

-

-

-

-
is used to return from the submicrosequence call. This action is
-    mandatory before a RET call. Some microinstructions (PUT, GET) may not be
-    callable within a submicrosequence.

-
No parameter.

-
Predefined macro: MS_SUBRET()

-

-

-

-
is used to call a submicrosequence. A submicrosequence is a
-    microsequence with a SUBRET call. Parameter:

-
    
-  
  1. the submicrosequence to execute
    2. 
-

-
Predefined macro: MS_CALL(microseq)

-

-

-

-
is used to assert a register with data currently pointed by the
-    internal PTR pointer. Parameter:

-
    
-  
  1. amount of data to write to the register
    2. 
-  
  2. register
    3. 
-

-
Predefined macro: MS_RASSERT_P(iter,reg)

-

-

-

-
is used to fetch data from a register. Data is stored in the
-    buffer currently pointed by the internal PTR pointer. Parameter:

-
    
-  
  1. amount of data to read from the register
    2. 
-  
  2. register
    3. 
-  
  3. mask applied to fetched data
    4. 
-

-
Predefined macro: MS_RFETCH_P(iter,reg,mask)

-

-

-

-
is used to trigger the parallel port. This microinstruction is
-    intended to provide a very efficient control of the parallel port.
-    Triggering a register is writing data, wait a while, write data, wait a
-    while... This allows to write magic sequences to the port. Parameter:

-
    
-  
  1. amount of data to read from the register
    2. 
-  
  2. register
    3. 
-  
  3. size of the array
    4. 
-  
  4. array of unsigned chars. Each couple of u_chars define the data to write
-      to the register and the delay in us to wait. The delay is limited to 255
-      us to simplify and reduce the size of the array.
    5. 
-

-
Predefined macro: MS_TRIG(reg,len,array)

-

-

-

-

-

-

-

-
union ppb_insarg {
-     int     i;
-     char    c;
-     void    *p;
-     int     (* f)(void *, char *);
-};
-
-struct ppb_microseq {
-     int                     opcode;         /* microins. opcode */
-     union ppb_insarg        arg[PPB_MS_MAXARGS];    /* arguments */
-};

-

-

-

-

-
To instantiate a microsequence, just declare an array of
-    ppb_microseq structures and initialize it as needed. You may either use
-    predefined macros or code directly your microinstructions according to the
-    ppb_microseq definition. For example,

-

-
     struct ppb_microseq select_microseq[] = {
-
-	     /* parameter list
-	      */
-	     #define SELECT_TARGET    MS_PARAM(0, 1, MS_TYP_INT)
-	     #define SELECT_INITIATOR MS_PARAM(3, 1, MS_TYP_INT)
-
-	     /* send the select command to the drive */
-	     MS_DASS(MS_UNKNOWN),
-	     MS_CASS(H_nAUTO | H_nSELIN |  H_INIT | H_STROBE),
-	     MS_CASS( H_AUTO | H_nSELIN |  H_INIT | H_STROBE),
-	     MS_DASS(MS_UNKNOWN),
-	     MS_CASS( H_AUTO | H_nSELIN | H_nINIT | H_STROBE),
-
-	     /* now, wait until the drive is ready */
-	     MS_SET(VP0_SELTMO),
-/* loop: */     MS_BRSET(H_ACK, 2 /* ready */),
-	     MS_DBRA(-2 /* loop */),
-/* error: */    MS_RET(1),
-/* ready: */    MS_RET(0)
-     };

-

-
Here, some parameters are undefined and must
-    be filled before executing the microsequence. In order to initialize each
-    microsequence, one should use the
-    ()
-    function like this:

-

-
ppb_MS_init_msq(select_microseq, 2,
-		SELECT_TARGET, 1 << target,
-		SELECT_INITIATOR, 1 << initiator);

-

-
and then execute the microsequence.

-

-

-

-
The microsequencer is executed either at ppbus or adapter level
-    (see ppbus(4) for info about ppbus system layers). Most of
-    the microsequencer is executed at atppc(4) level to avoid
-    ppbus(4) to adapter function call overhead. But some
-    actions like deciding whereas the transfer is IEEE1284-1994 compliant are
-    executed at ppbus(4) layer.

-

-

-

-

-
atppc(4), ppbus(4),
-    vpo(4)

-

-

-

-
The microseq manual page first appeared in
-    FreeBSD 3.0.

-

-

-

-
This manual page is based on the FreeBSD
-    microseq manual page and was update for the
-    NetBSD port by Gary
-  Thorpe.

-

-

-

-
Only one level of submicrosequences is allowed.

-
When triggering the port, maximum delay allowed is 255 us.

-

-

-
-  
-    
-    
-  
-
December 29, 2003NetBSD 10.1

diff --git a/static/netbsd/man9/microtime.9 3.html b/static/netbsd/man9/microtime.9 3.html
deleted file mode 100644
index 0966aa13..00000000
--- a/static/netbsd/man9/microtime.9 3.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
MICROTIME(9)Kernel Developer's ManualMICROTIME(9)

-

-

-

-
bintime,
-    getbintime, microtime,
-    getmicrotime, nanotime,
-    getnanotime — get the
-    current time

-

-

-

-
#include
-    <sys/time.h>

-
void
-  

-  bintime(struct bintime *bt);

-
void
-  

-  getbintime(struct bintime
-  *bt);

-
void
-  

-  microtime(struct timeval
-  *tv);

-
void
-  

-  getmicrotime(struct timeval
-    *tv);

-
void
-  

-  nanotime(struct timespec
-  *tsp);

-
void
-  

-  getnanotime(struct timespec
-    *tsp);

-

-

-

-
The
-    ()
-    and getbintime() functions store the system time as
-    a struct bintime at the addresses specified by
-    bt. The microtime() and
-    getmicrotime() functions perform the same utility,
-    but record the time as a struct timeval instead.
-    Similarly the nanotime() and
-    getnanotime() functions store the time as a
-    struct timespec. The structures are described in
-    timeval(3).

-
The
-    (),
-    microtime(), and
-    ()
-    functions always query the timecounter to return the current time as
-    precisely as possible. Whereas getbintime(),
-    getmicrotime(), and
-    getnanotime() functions are abstractions which
-    return a less precise, but faster to obtain, time.

-
The intent of the
-    (),
-    (),
-    and
-    ()
-    functions is to enforce the user's preference for timer accuracy versus
-    execution time. They should be used where a precision of
-    1/HZ (e.g., 10 msec on a 100HZ machine,
-    see hz(9)) is acceptable or where performance is
-  priority.

-
The system realtime clock is guaranteed to be monotonically
-    increasing at all times. As such, all calls to these functions are
-    guaranteed to return a system time greater than or equal to the system time
-    returned in any previous calls. Comparable functions exist to retrieve the
-    time elapsed since boot; see microuptime(9).

-

-

-

-
The implementation of the
-    ()
-    family of functions is in sys/kern/kern_tc.c as a
-    part of the timecounter(9) framework.

-
The implementation of the time counter sources used by the
-    timecounter(9) is machine dependent, hence its location in
-    the source code tree varies from architecture to architecture.

-

-

-

-
settimeofday(2),
-    bintime_add(9), inittodr(9),
-    time_second(9), tvtohz(9)

-

-

-

-
This manual page was written by Jeremy
-    Cooper and
-  

-  Kelly Yancey
-    <kbyanc@posi.net>.

-

-

-

-
Despite the guarantee that the system realtime clock will always
-    be monotonically increasing, it is always possible for the system clock to
-    be manually reset by the system administrator to any date.

-

-

-
-  
-    
-    
-  
-
May 13, 2013NetBSD 10.1

diff --git a/static/netbsd/man9/module.9 3.html b/static/netbsd/man9/module.9 3.html
deleted file mode 100644
index f8cf2512..00000000
--- a/static/netbsd/man9/module.9 3.html	
+++ /dev/null
@@ -1,539 +0,0 @@
-
-  
-    
-    
-    
-  
-
MODULE(9)Kernel Developer's ManualMODULE(9)

-

-

-

-
module,
-    module_load,
-    module_autoload,
-    module_unload,
-    module_init_class,
-    module_hold, module_rele,
-    module_find_section,
-    module_kernel, module_name,
-    module_source,
-    module_register_callbacks,
-    module_unregister_callbacks,
-    module_specific_key_create,
-    module_specific_key_delete,
-    module_getspecific,
-    module_setspecific — kernel
-    module loader

-

-

-

-
#include
-    <sys/module.h>

-
MODULE(class,
-    name,
-    required);

-
int
-  

-  module_load(const
-    char *name, int
-    flags, prop_dictionary_t
-    props, modclass_t
-    class);

-
int
-  

-  module_autoload(const
-    char *name, modclass_t
-    class);

-
int
-  

-  module_unload(const
-    char *name);

-
void
-  

-  module_init_class(modclass_t
-    class);

-
void
-  

-  module_hold(module_t
-    *module);

-
void
-  

-  module_rele(module_t
-    *module);

-
int
-  

-  module_find_section(const
-    char *, void **,
-    size_t *);

-
module_t *
-  

-  module_kernel(void);

-
const char *
-  

-  module_name(struct
-    module *module);

-
modsrc_t
-  

-  module_source(struct
-    module *module);

-
void
-  

-  module_init(void);

-
void
-  

-  module_start_unload_thread(void);

-
void
-  

-  module_builtin_require_force(void);

-
void
-  

-  module_load_vfs_init(void);

-
void *
-  

-  module_register_callbacks(void
-    (*)(struct module *),
-    void (*unload)(struct module
-    *));

-
void
-  

-  module_unregister_callbacks(void
-    *);

-
specificdata_key_t
-  

-  module_specific_key_create(specificdata_key_t
-    *keyp,
-    specificdata_dtor_t
-    dtor);

-
void
-  

-  module_specific_key_delete(specificdata_key_t
-    key);

-
void *
-  

-  module_getspecific(module_t
-    *mod, specificdata_key_t
-    key);

-
void *
-  

-  module_setspecific(module_t
-    *mod, specificdata_key_t
-    key, void
-  *data);

-

-

-

-
Modules are sections of code that can be independently linked and
-    selectively loaded into or unloaded from a running kernel. This provides a
-    mechanism to update the module without having to relink the kernel and
-    reboot. Modules can be loaded from within the kernel image, provided by the
-    boot loader, or loaded from the file system.

-
The module subsystem includes two data
-    types:

-
    
-  
  1. The module_t type provides storage to describe a
-      module.
    2. 
-  
  2. The modinfo_t type resides within
-      module_t and contains module header info.
    3. 
-

-
The module subsystem is protected by the global
-    kernconfig_mutex.

-

-

-

-

-  
(class,
-    name, required)

-  
The MODULE() macro creates and initializes a
-      modinfo_t structure. The class
-      argument identifies the class of module, and must be one of the following
-      (note that MODULE_CLASS_ANY should not be used
-      here):
-    

-    

-      

-      
The module provide a virtual file system - see
-          vfs(9)

-      

-      
The module is a device driver - see driver(9)

-      

-      
The module provides an alternate execution environment - see the
-          various COMPAT_xxx options in
-          options(4)

-      

-      
The module provides a security model - see
-          secmodel(9)

-      

-      
The module provides a buffer queue strategy - see
-          bufq(9)

-      

-      
The module provides miscellaneous kernel services

-    

-    

-    
The name argument provides the name of
-        the module. Loaded modules, including those that are built-in to the
-        kernel, must all have unique names.

-    
The required argument is a quoted string
-        containing a comma-separated list of module names that are required by
-        this module. The list must not contain any white-space. When a module is
-        loaded, all of its required modules are auto-loaded and initialized
-        before the module itself is loaded. Loading of required modules is a
-        recursive operation.

-    
If there are no required modules, this argument should be
-        specified as NULL.

-    
In addition to the explicit arguments, the
-        ()
-        macro creates a reference to the module's
-        modcmd() function. This function is defined
-      as:

-    

-    

-      
int

-      
(modcmd_t
-          cmd, void *data)

-    

-    

-    
(where xxx is the name of the module, from the
-        MODULE macro).

-    
The cmd argument requests one of the
-        following operations:

-    

-    

-      

-      
Perform module-specific initialization when the module is loaded.

-      

-      
Perform module-specific clean-up before the module is unloaded.

-      

-      
Notify the module that it is about to be unloaded.

-      

-      
Request the module to provide status information (not currently
-          implemented).

-    

-    

-    
All modules'
-        ()
-        functions must implement the MODULE_CMD_INIT and
-        MODULE_CMD_FINI commands. The other commands are
-        optional, and should return ENOTTY if not
-        implemented.

-    
For the MODULE_CMD_INIT command, the
-        data argument is used to pass a pointer to the
-        module's prop_dictionary(3). For the
-        MODULE_CMD_STAT command, the
-        data argument points to a buffer where the status
-        information should be placed.

-    
The __link_set mechanism is used to enable the
-        module subsystem to locate the
-        modinfo_t structure.

-  

-  
(name,
-    flags, props,
-    class)

-  
Load a module, link it into the running kernel, and call the module's
-      modcmd() routine with a cmd
-      argument of MODULE_CMD_INIT. If the specified
-      module requires other modules, they are loaded first; if any required
-      module cannot be loaded or if any of their
-      modcmd() control routines returns a non-zero
-      status, loading of this module and the specific required module will fail.
-      The required modules are marked for automatic unloading. Thus, if the
-      loading of the module failed, the required modules will be automatically
-      unloaded after a short delay.
-    
The loader will look first for a built-in
-        module with the specified name that has not been
-        disabled (see
-        ()
-        below). If a built-in module with that name is not
-        found, the list of modules prepared by the boot loader is searched. If
-        the named module is still not found, an attempt is made to locate the
-        module within the file system, provided it has been mounted by the
-        initialization code.

-    
The flags argument can include:

-    

-    

-      

-      
When loading a module from the file system, do not attempt to locate a
-          corresponding prop_dictionary file.

-      

-      
Force loading of disabled built-in modules and modules built for a
-          different version of the operating system.

-    

-    

-    
The props argument points
-        to an externalized property list which is passed to the module's
-        ()
-        routine. If a module is being loaded from the file system, and the
-        MODCTL_NO_PROP flag is not set, the system
-        searches for a file with the same name as the module file, but with the
-        suffix “.plist”. If this file is
-        found, the prop_dictionary it contains is loaded and merged with the
-        prop_dictionary from the props argument.

-    
The class argument can be any of:

-    

-    

-    

-      

-      
 

-      

-      
Device driver

-      

-      
Executable image handler

-      

-      
Miscellaneous module

-      

-      
Security model (see secmodel(9) for more
-        details)

-      

-      
Virtual file system

-    

-    

-    
If the class is not
-        MODULE_CLASS_ANY, the class of the module being
-        loaded must match the requested class. Except when
-        verifying a module's class when it is being loaded, module classes other
-        than MODULE_CLASS_SECMODEL are transparent to
-        the module subsystem. They are provided only for the benefit of the
-        subsystem's clients. Modules with class
-        MODULE_CLASS_SECMODEL are automatically
-        registered with
-        ()
-        after being successfully loaded, and automatically deregistered with
-        ()
-        when being unloaded.

-    
The
-        ()
-        routine is primarily intended as the implementation of the
-        MODCTL_LOAD option of the
-        modctl(2) system call.

-  

-  
module_autoload(name,
-    class)

-  
Auto-load a module, making it available for automatic unloading. The
-      name and class arguments are
-      the same as for the module_load() routine.
-    
The module subsystem uses a kernel thread
-        to attempt to automatically unload modules a short time (currently, 10
-        seconds) after being loaded by
-        ().
-        Before the module is unloaded by this thread, its
-        modcmd() is called with the
-        cmd argument specified as
-        MODULE_CMD_AUTOUNLOAD. A module can prevent
-        itself from being unloaded by returning a non-zero value. Exception: If
-        kern.module.autounload_unsafe is set, a module
-        that returns ENOTTY, meaning it does not
-        understand the command, may still be autounloaded.

-    
The
-        ()
-        function is intended for use by kernel components to locate and load
-        optional system components. The function is also used to load modules
-        that are required by other modules.

-    
The directory from which the module is loaded
-        will be searched for a file with the same name as the module file, but
-        with the suffix “.plist”. If this
-        file is found, the prop_dictionary it contains will be loaded and passed
-        to the module's
-        ()
-        routine. If this prop_dictionary contains a
-        “noautoload” property which is set
-        to “true” then the system will
-        refuse to load the module.

-  

-  
module_unload(name)

-  
Unload a module. If the module's reference count is non-zero, the function
-      returns EBUSY. Otherwise, the module's
-      modcmd() routine is called with a
-      cmd argument of
-      MODULE_CMD_FINI. If the
-      modcmd() routine returns with an error, then the
-      error is returned to the caller otherwise the module is unloaded.
-    
The reference counts of all modules that
-        were required by this module are decremented, but the required modules
-        are not unloaded by the call to
-        ().
-        Instead, the required modules may be unloaded by subsequent calls to
-        module_unload().

-    
Unloading a built-in module causes the
-        module to be marked as disabled. This prevents the module from being
-        re-loaded, except by the
-        ()
-        function with the flags argument set to
-        MODULE_FORCE_LOAD.

-    
The
-        ()
-        function may be called by the modctl(2) system call,
-        by the module subsystem's internal auto-unload thread, or by other
-        kernel facilities. Generally, other kernel facilities should not be
-        calling this function.

-  

-  
(class)

-  
Load and initialize all available modules of the specified
-      class. Any built-in modules that have not been
-      disabled, and any modules provided by the boot loader are loaded.

-  
(module)

-  
Increment the reference count of a module. A module cannot be unloaded if
-      its reference count is non-zero.

-  
(module)

-  
Decrement the reference count of a module.

-  
(name,
-    addr, size)

-  
Find the start address and size of linker section
-      name within a module. The miniroot module uses this
-      routine to find the address and size of the embedded file system image.
-      This routine can only examine the linker data for the module that is
-      currently being initialized; it cannot examine data for any other
-    module.

-  
(void)

-  
Returns a pointer to a module_t structure describing
-      the kernel module.

-  
(module)

-  
Returns a pointer to the module's name.

-  
(module)

-  
Returns the source of the module, one of
-      MODULE_SOURCE_KERNEL,
-      MODULE_SOURCE_BOOT, or
-      MODULE_SOURCE_FILESYS.

-  
(void)

-  
Initialize the module subsystem. Creates and initializes various data
-      structures, locates all built-in modules, and establishes the sub-system's
-      sysctl(8) tree. module_init() is
-      called early in system initialization to facilitate use of security model
-      modules.

-  
(void)

-  
Create the thread that attempts to automatically unload modules that were
-      loaded via the module_autoload() routine. The
-      function is called only once, after the scheduler and timer functions are
-      initialized.

-  
(void)

-  
Mark as "disabled" any built-in modules that have not been
-      successfully initialized. Modules marked "disabled" can only be
-      loaded if the MODCTL_LOAD_FORCE is specified.
-      module_builtin_require_force() is called near the
-      end of system initialization, after the init(8) process
-      is created.

-  
(void)

-  
The module subsystem is initialized early, long before any file systems
-      are available. After the root file system is mounted,
-      module_load_vfs_init(void)
-      is used to enable loading modules from the file system. Until this routine
-      is called, modules can only be loaded if they were built-in to the kernel
-      image or provided by the boot loader.

-  
(void
-    (*load)(struct module *), void (*unload)(struct module
-    *))

-  
Register a new set of callbacks. The load callback
-      is invoked after any module (including this module) is successfully
-      loaded; the unload callback is invoked before any
-      module is unloaded. Each load or unload event can result in multiple
-      invocations of the callback routines. An opaque cookie is returned which
-      can be passed to
-      ().

-  
module_unregister_callbacks(void
-    *opaque)

-  
Unregister a set of callback routines previously registered with
-      module_register_callbacks(). The
-      opaque argument should be the return value from the
-      previous module_register_callbacks() call.

-  
(specificdata_key_t
-    *keyp, specificdata_dtor_t dtor)

-  
Creates a new specificdata_key for use within the
-      module domain. The key identifier is returned in
-      keyp.

-  
(specificdata_key_t
-    key)

-  
Deletes the specified specificdata_key key from the
-      module domain.

-  
(module_t
-    *mod, specificdata_key_t key)

-  
Retrieves the value associated with key from module
-      mod.

-  
(module_t
-    *mod, specificdata_key_t key,
-    void *data)

-  
Stores data as the value associated with
-      key for module mod.

-

-

-

-

-
The module subsystem is designed to be called recursively, but
-    only within a single LWP. This permits one module's
-    modcmd() routine to load or unload other
-  modules.

-
Additional considerations:

-
    
-  
  • A module is not permitted to load or unload itself. Attempts
-      to load or unload a module from within its own
-      ()
-      routine will fail with EEXIST or
-      EBUSY, respectively.
    • 
-  
  • Although a module can be loaded by using either
-      module_load() or
-      module_autoload(), it is not possible for the
-      module's modcmd() routine to distinguish between
-      the two methods. Any module which needs to ensure that it does not get
-      auto-unloaded must either handle the
-      MODULE_CMD_AUTOUNLOAD command in its
-      modcmd() routine, or use
-      module_hold() to increment its reference count.
-      Note however that modules loaded manually with
-      modload(8) are never auto-unloaded.
    • 
-

-

-

-

-
A set of example modules is available in the
-    src/sys/modules/examples directory hierarchy.

-

-

-

-
The core of the kernel module implementation is in
-    sys/kern/kern_module.c and
-    sys/kern/kern_module_vfs.c.

-
The routines for linking the module are in
-    sys/kern/subr_kobj.c.

-
The routines for reading a module from the file system are in
-    sys/kern/subr_kobj_vfs.c.

-
The header file
-    <sys/sys/module.h> describes
-    the public interface.

-
In addition, each architecture is expected to
-    provide
-    (),
-    (),
-    and
-    ().
-    kobj_machdep() is for any machine dependent actions,
-    such as flushing caches, that are needed when a module is loaded or
-    unloaded. kobj_reloc() deals with resolution of
-    relocatable symbols. module_init_md() is for finding
-    modules passed in by the boot loader.

-

-

-

-
modctl(2), module(7),
-    specificdata(9), intro(9lua)

-

-

-

-
The kernel module subsystem first appeared in
-    NetBSD 5.0. It replaces the “LKM”
-    subsystem from earlier releases.

-

-

-

-
The module system was written by
-    Andrew Doran
-    <ad@NetBSD.org>. This
-    manual page was written by Paul Goyette
-    <pgoyette@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
July 21, 2021NetBSD 10.1

diff --git a/static/netbsd/man9/namecache.9 3.html b/static/netbsd/man9/namecache.9 3.html
deleted file mode 100644
index 39271d56..00000000
--- a/static/netbsd/man9/namecache.9 3.html	
+++ /dev/null
@@ -1,223 +0,0 @@
-
-  
-    
-    
-    
-  
-
NAMECACHE(9)Kernel Developer's ManualNAMECACHE(9)

-

-

-

-
namecache,
-    cache_lookup,
-    cache_revlookup,
-    cache_enter, cache_purge,
-    cache_purgevfs,
-    namecache_print — name
-    lookup cache

-

-

-

-
#include
-    <sys/namei.h>
-  

-  #include <sys/proc.h>
-  

-  #include <sys/uio.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  cache_lookup(struct
-    vnode *dvp, const char
-    *name, size_t
-    namelen, uint32_t
-    nameiop, uint32_t
-    nameiflags, int
-    *iswhiteout, struct vnode
-    **vpp);

-
int
-  

-  cache_revlookup(struct
-    vnode *vp, struct vnode
-    *dvp, char **bpp,
-    char *bufp);

-
void
-  

-  cache_enter(struct
-    vnode *dvp, struct vnode
-    *vp, const char
-    *name, size_t
-    namelen, uint32_t
-    nameiflags);

-
void
-  

-  cache_purge(struct
-    vnode *vp);

-
void
-  

-  cache_purgevfs(struct
-    mount *mp);

-
void
-  

-  namecache_print(struct
-    vnode *vp, void
-    (*func)(const char *, ...));

-

-

-

-
The name lookup cache is the mechanism to allow the file system
-    type dependent algorithms to quickly resolve a file's vnode from its
-    pathname. The name lookup cache is generally accessed through the
-    higher-level namei(9) interface.

-
The name of the file is used to look up an entry associated with
-    the file in the name lookup cache. If no entry is found, one is created for
-    it. If an entry is found, the information obtained from the cache lookup
-    contains information about the file which is useful to the file system type
-    dependent functions.

-
The name lookup cache is managed by a least recently used (LRU)
-    algorithm so frequently used names will hang around. The cache itself is a
-    hash table called nchashtbl, containing
-    namecache entries that are allocated dynamically from a
-    kernel memory pool. Each entry has the following structure:

-

-
#define NCHNAMLEN	31	/* maximum name segment length */
-struct  namecache {
-        LIST_ENTRY(namecache) nc_hash;  /* hash chain */
-        TAILQ_ENTRY(namecache) nc_lru;  /* LRU chain */
-        LIST_ENTRY(namecache) nc_vhash; /* directory hash chain */
-        LIST_ENTRY(namecache) nc_dvlist;
-        struct  vnode *nc_dvp;          /* vnode of parent of name */
-        LIST_ENTRY(namecache) nc_vlist;
-        struct  vnode *nc_vp;           /* vnode the name refers to */
-        int     nc_flags;               /* copy of componentname's ISWHITEOUT */
-        char    nc_nlen;                /* length of name */
-        char    nc_name[NCHNAMLEN];     /* segment name */
-};

-

-
For simplicity (and economy of storage), names longer than a
-    maximum length of NCHNAMLEN are not cached; they occur infrequently in any
-    case, and are almost never of interest.

-
Each namecache entry can appear
-    on two hash chains in addition to nchashtbl:
-    
-    (the name cache directory hash chain), and
-    
-    (the name cache LRU chain). The hash chains are indexed by a hash value
-    obtained from the file's name and the address of its parent directory
-  vnode.

-
Functions which access to the name cache pass
-    arguments in the partially initialised
-    
-    structure. See vnodeops(9) for details on this
-  structure.

-

-

-

-

-  
(dvp,
-    name, namelen,
-    nameiop, nameiflags,
-    iswhiteout, vpp)

-  
Look for a name in the cache. cache_lookup() is
-      called with dvp pointing to the vnode of the
-      directory to search. The name and
-      namelen arguments specify the name to look for. The
-      nameiop and nameiflags should
-      be taken from the cn_nameiop and
-      cn_flags fields of struct componentname.
-    
The lookup can produce either a cache miss or a cache
-        hit, and a cache hit can either be a positive hit, where the name looked
-        up refers to some existing object, or a negative hit, where the name
-        looked up is known to refer to
-         existing
-        object. (The lookup cannot fail, in the sense of generating an error
-        condition that requires aborting the operation in progress.)

-    
On a cache miss,
-        ()
-        returns zero (false). On a positive hit, the unlocked vnode for the
-        object found is stored in vpp, and a nonzero
-        (true) value is returned. On a negative hit, vpp
-        is set to contain a null pointer and a nonzero value is returned.
-        Usually a negative hit will prompt the caller to fail with
-        ENOENT.

-    
The iswhiteout
-        argument is a pointer to an integer result that will be set to nonzero
-        if the entry represents a whiteout, and zero if it does not. This
-        pointer may be NULL if the caller does not
-        support whiteouts. According to the current scheme for handling
-        whiteouts, if
-        ()
-        sets iswhiteout the caller should add
-        ISWHITEOUT to the cn_flags
-        field of its struct componentname.

-  

-  
(vp,
-    dvp, bpp,
-    bufp)

-  
Scan cache looking for name of directory entry pointing at
-      vp and fill in dvpp. If
-      bufp is non-NULL, also place
-      the name in the buffer which starts at bufp,
-      immediately before bpp, and move bpp backwards to
-      point at the start of it. If the lookup succeeds, the vnode is referenced.
-      Returns 0 on success, -1 on cache miss, positive errno on failure.

-  
(dvp,
-    vp, name,
-    namelen, nameiflags)

-  
Add an entry to the cache. The name and
-      namelen arguments specify the name to add to the
-      cache. The dvp argument specifies the directory the
-      name appears in. The vp argument specifies the
-      object to enter in the cache. The nameiflags
-      argument should come from the cn_flags member of
-      struct componentname.
-    
If vp is NULL, a
-        negative cache entry is created, specifying that the entry does not
-        exist in the file system.

-  

-  
(vp)

-  
Flush the cache of a particular vnode vp.
-      cache_purge() is called when a vnode is renamed to
-      hide entries that would now be invalid.

-  
(mp)

-  
Flush cache of a whole file system mp.
-      cache_purgevfs() is called when file system is
-      unmounted to remove entries that would now be invalid.

-  
(vp,
-    func)

-  
Print all entries of the name cache. func is the
-      printf(9) format.
-      namecache_print() is only defined if the kernel
-      option DDB is compiled into the kernel.

-

-

-

-

-
The name lookup cache is implemented within the file
-    sys/kern/vfs_cache.c.

-

-

-

-
intro(9), namei(9),
-    vfs(9), vnode(9)

-

-

-

-
The name lookup cache first appeared in
-    4.2BSD.

-

-

-

-
The original name lookup cache was written by
-    Robert Elz.

-

-

-
-  
-    
-    
-  
-
February 7, 2014NetBSD 10.1

diff --git a/static/netbsd/man9/nullop.9 3.html b/static/netbsd/man9/nullop.9 3.html
deleted file mode 100644
index 26154789..00000000
--- a/static/netbsd/man9/nullop.9 3.html	
+++ /dev/null
@@ -1,80 +0,0 @@
-
-  
-    
-    
-    
-  
-
NULLOP(9)Kernel Developer's ManualNULLOP(9)

-

-

-

-
nullop — dummy
-    functions

-

-

-

-
#include
-    <sys/systm.h>

-
int
-  

-  nullop(void
-    *v);

-
void
-  

-  voidop(void);

-
int
-  

-  enodev(void);

-
int
-  

-  enxio(void);

-
int
-  

-  enoioctl(void);

-
int
-  

-  enosys(void);

-
int
-  

-  eopnotsupp(void);

-

-

-

-
The
-    ()
-    function provides a generic “null operation”. It always
-    returns the value 0. The
-    ()
-    function takes no arguments and does nothing.

-
The
-    (),
-    (),
-    (),
-    (),
-    and
-    ()
-    functions always fail, returning ENODEV,
-    ENXIO, ENOTTY,
-    ENOSYS, and EOPNOTSUPP,
-    respectively.

-

-

-

-
The following example demonstrates a case where
-    nullop() may be useful:

-

-
uint64_t xc;
-
-...
-
-xc = xc_broadcast(0, (xcfunc_t)nullop, NULL, NULL);
-xc_wait(xc);

-

-

-

-
-  
-    
-    
-  
-
July 25, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/optstr.9 3.html b/static/netbsd/man9/optstr.9 3.html
deleted file mode 100644
index c46e0389..00000000
--- a/static/netbsd/man9/optstr.9 3.html	
+++ /dev/null
@@ -1,128 +0,0 @@
-
-  
-    
-    
-    
-  
-
OPTSTR(9)Kernel Developer's ManualOPTSTR(9)

-

-

-

-
optstr_get,
-    optstr_get_string,
-    optstr_get_number,
-    optstr_get_number_binary,
-    optstr_get_number_hex,
-    optstr_get_macaddr — Options
-    string management

-

-

-

-
#include
-    <sys/optstr.h>

-
bool
-  

-  optstr_get(const char *optstr,
-    const char *key, char *buf,
-    size_t bufsize);

-
bool
-  

-  optstr_get_string(const char
-    *optstr, const char *key, char
-    **result);

-
bool
-  

-  optstr_get_number(const char
-    *optstr, const char *key,
-    unsigned long *result);

-
bool
-  

-  optstr_get_number_binary(const char
-    *optstr, const char *key,
-    unsigned long *result);

-
bool
-  

-  optstr_get_number_hex(const char
-    *optstr, const char *key,
-    unsigned long *result);

-
bool
-  

-  optstr_get_macaddr(const char
-    *optstr, const char *key,
-    uint8_t result[ETHER_ADDR_LEN]);

-

-

-

-
An options string is a list of key/value pairs represented in
-    textual form. Each pair is expressed as
-    key=value
-    and is separated from other pairs by one or more spaces. For example:

-

-
key1=value1 key2=value2
-  key3=value3

-
Options strings are used to pass information between userland
-    programs and the kernel in a binary-agnostic way. This makes them endianness
-    and ABI independent.

-

-

-

-
The following functions are provided to manage options
-  strings:

-

-  
(optstr,
-    key, buf,
-    bufsize)

-  
Scans the optstr options string looking for the key
-      key and stores its value in the buffer pointed to by
-      buf copying a maximum of
-      bufsize bytes. Returns
-      ‘true’ if the key was found or
-      ‘false’ otherwise, in which case
-      buf is left unmodified.

-

-
The optstr_get_item
-    family of functions provide the ability to scan for the key, and return the
-    value converted to an appropriate type.

-

-

-  
(optstr,
-    key, result)

-  
 

-  
(optstr,
-    key, result)

-  
 

-  
(optstr,
-    key, result)

-  
 

-  
(optstr,
-    key, result)

-  
 

-  
(optstr,
-    key, result)

-  
These functions scan the optstr options string
-      looking for the key key and returns the key value
-      converted as per the function name in result. All
-      functions return ‘true’ if the key
-      was found or ‘false’ otherwise, in
-      which case result is left unmodified.

-

-

-

-

-
The options string management functions are implemented within the
-    files sys/kern/subr_optstr.c and
-    sys/sys/optstr.h.

-

-

-

-
Options strings appeared in NetBSD
-  4.0.

-

-

-
-  
-    
-    
-  
-
May 20, 2023NetBSD 10.1

diff --git a/static/netbsd/man9/panic.9 3.html b/static/netbsd/man9/panic.9 3.html
deleted file mode 100644
index 27a73f6c..00000000
--- a/static/netbsd/man9/panic.9 3.html	
+++ /dev/null
@@ -1,91 +0,0 @@
-
-  
-    
-    
-    
-  
-
PANIC(9)Kernel Developer's ManualPANIC(9)

-

-

-

-
panic — bring down
-    system on fatal error

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/systm.h>

-
void
-  

-  vpanic(const
-    char *fmt, va_list
-    ap);

-
void
-  

-  panic(const
-    char *fmt,
-  ...);

-

-

-

-
The
-    ()
-    and
-    ()
-    functions terminate the NetBSD system. The message
-    fmt is a printf(3) style format
-    string which is printed to the console and saved in the variable
-    panicstr for later retrieval via core dump inspection.
-    A newline character is added at the end automatically, and is thus not
-    needed in the format string.

-
If a kernel debugger is installed, control is passed
-    to it after the message is printed. If the kernel debugger is
-    ddb(4), control may be passed to it, depending on the
-    value of ddb.onpanic. See options(4) for
-    more details on setting ddb.onpanic. If control is not
-    passed through to ddb(4), a
-    ddb(4)-specific function is used to print the kernel stack
-    trace, and then control returns to
-    ().

-
If control remains in
-    (), an
-    attempt is made to save an image of system memory on the configured dump
-    device.

-
If during the process of handling the panic,
-    () is
-    called again (from the filesystem synchronization routines, for example),
-    the system is rebooted immediately without synchronizing any
-  filesystems.

-
()
-    is meant to be used in situations where something unexpected has happened
-    and it is difficult to recover the system to a stable state, or in
-    situations where proceeding might make things worse, leading to data
-    corruption and/or loss. It is not meant to be used in scenarios where the
-    system could easily ignore and/or isolate the condition/subsystem and
-    proceed.

-
In general developers should try to reduce the number
-    of ()
-    calls in the kernel to improve stability.

-

-

-

-
The panic() function never returns.

-

-

-

-
printf(3), sysctl(3),
-    ddb(4), options(4),
-    savecore(8), swapctl(8),
-    sysctl(8), printf(9)

-

-

-
-  
-    
-    
-  
-
October 4, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/pci_configure_bus.9 3.html b/static/netbsd/man9/pci_configure_bus.9 3.html
deleted file mode 100644
index de32dcfc..00000000
--- a/static/netbsd/man9/pci_configure_bus.9 3.html	
+++ /dev/null
@@ -1,256 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_CONFIGURE_BUS(9)Kernel Developer's ManualPCI_CONFIGURE_BUS(9)

-

-

-

-
pci_configure_bus,
-    pci_conf_hook,
-    pci_conf_interrupt,
-    pciconf_resource_init,
-    pciconf_resource_add,
-    pciconf_resource_fini —
-    perform PCI bus configuration

-

-

-

-
#include
-    <dev/pci/pciconf.h>

-
int
-  

-  pci_configure_bus(pci_chipset_tag_t
-    pc, struct
-    pciconf_resources *res,
-    int firstbus,
-    int cacheline_size);

-
struct pciconf_resources *
-  

-  pciconf_resource_init(void);

-
void
-  

-  pciconf_resource_add(struct
-    pciconf_resources *res,
-    int type,
-    bus_addr_t addr,
-    bus_size_t size);

-
void
-  

-  pciconf_resource_fini(struct
-    pciconf_resources *res);

-

-

-

-
The
-    ()
-    function configures a PCI bus for use. This involves:

-
    
-  
  • Defining bus numbers for all busses on the system,
    • 
-  
  • Setting the Base Address Registers for all devices,
    • 
-  
  • Setting up the interrupt line register for all devices,
    • 
-  
  • Configuring bus latency timers for all devices, and
    • 
-  
  • Configuring cacheline sizes for all devices.
    • 
-

-
In traditional PCs and Alpha systems, the
-    BIOS or firmware takes care of this task, but that is not the case for all
-    systems.
-    ()
-    should be called prior to the autoconfiguration of the bus.

-
The pc argument is a
-    machine-dependent tag used to specify the PCI chipset to the system. This
-    should be the same value used with
-    ().
-    The res argument is a container for PCI bus resources
-    that will be used to configure the bus. The firstbus
-    argument indicates the number of the first bus to be configured. The
-    cacheline_size argument is used to configure the PCI
-    Cache Line Size Register; it should be the size, in bytes, of the largest
-    D-cache line on the system.

-
An implementation may choose to not have
-    full configuration performed by
-    ()
-    on certain PCI devices, such as PCI host bridges or PCI bus analyzers which
-    are instantiated as devices on the bus. In order for this to take place, the
-    header
-    <machine/pci_machdep.h> must
-    define the __HAVE_PCI_CONF_HOOK symbol (without a
-    value), and a machine-dependent function
-    pci_conf_hook() (declared in the same header) must
-    be defined. The prototype for this function is:

-
int
-    (pci_chipset_tag_t
-    pc, int bus, int device,
-    int function, pcireg_t id);

-
In this function, bus,
-    device, and function uniquely
-    identify the item being configured; in addition to this, the value of the
-    device's PCI identification register is passed in id.
-    For each device
-    ()
-    can then decide upon the amount of configuration to be performed by
-    returning a bitwise inclusive-or of the following flags:

-

-

-  

-  
Configure Base Address Registers that map I/O space

-  

-  
Configure Base Address Registers that map memory space

-  

-  
Configure Expansion ROM Base Address register

-  

-  
Enable I/O space accesses

-  

-  
Enable memory space accesses

-  

-  
Enable bus mastering

-

-

-
In addition, PCI_CONF_ALL specifies all of
-    the above.

-
One of the functions of
-    ()
-    is to configure interrupt “line” information. This must be
-    done on a machine-dependent basis, so a machine-dependent function
-    pci_conf_interrupt() must be defined. The prototype
-    for this function is

-
void
-    (pci_chipset_tag_t
-    pc, int bus, int device,
-    int pin, int swiz,
-    int *iline)

-
In this function, bus,
-    device, and pin, uniquely
-    identify the item being configured. The swiz argument
-    is a “swizzle”, a sum of the device numbers of the primary
-    interface of the bridges between the host bridge and the current device. The
-    function is responsible for setting the value of
-    iline. See chapter 9 of the “PCI-to-PCI Bridge
-    Architecture Specification” for more information on swizzling (also
-    known as interrupt routing).

-
The resources used to configure the PCI
-    bus are encapsulated into a resource container. The
-    ()
-    function allocates and initializes one of these containers, and the
-    ()
-    function adds resources to the container, specifying the type, start
-    address, and size of the resource being added. The following resource types
-    are supported:

-

-

-  

-  
An address region used for PCI I/O accesses.

-  

-  
An address region used for PCI memory accesses where reads may have side
-      effects.

-  

-  
An address region used for PCI memory accesses where reads do not have
-      side effects (e.g. ROMs, frame buffers, other memory-like regions that are
-      marked as prefetchable in their BAR).

-

-

-
If an implementation does not distinguish between prefetchable and
-    non-prefetchable memory, then adding a
-    PCICONF_RESOURCE_PREFETCHABLE_MEM resource is not
-    required; PCICONF_RESOURCE_MEM resources will be
-    used for ROMs and BARs that are marked as prefetchable.

-
Once the bus has been successfully
-    configured, the resource container should be disposed of by calling
-    ().

-

-

-

-
If successful pci_configure_bus() returns
-    0. A non-zero return value means that the bus was not completely configured
-    for some reason. A description of the failure will be displayed on the
-    console.

-

-

-

-
The pci_configure_bus() function is only
-    included in the kernel if the kernel is compiled with the
-    PCI_NETBSD_CONFIGURE option enabled.

-

-

-

-
The pci_conf_hook() function in evbppc's
-    walnut implementation looks like:

-

-

-
int
-pci_conf_hook(pci_chipset_tag_t pc, int bus, int dev, int func,
-    pcireg_t id)
-{
-
-	if ((PCI_VENDOR(id) == PCI_VENDOR_IBM &&
-	     PCI_PRODUCT(id) == PCI_PRODUCT_IBM_405GP) ||
-	    (PCI_VENDOR(id) == PCI_VENDOR_INTEL &&
-	     PCI_PRODUCT(id) == PCI_PRODUCT_INTEL_80960_RP)) {
-		/* Don't configure the bridge and PCI probe. */
-		return 0;
-	}
-	return (PCI_CONF_ALL & ~PCI_CONF_MAP_ROM);
-}

-

-
The pci_conf_interrupt() function in the
-    sandpoint implementation looks like:

-

-

-
void
-pci_conf_interrupt(pci_chipset_tag_t pc, int bus, int dev, int pin,
-    int swiz, int *iline)
-{
-	if (bus == 0) {
-		*iline = dev;
-	} else {
-		*iline = 13 + ((swiz + dev + 3) & 3);
-	}
-}

-

-
This configuration example is taken from the bebox port.

-

-

-
#define PCI_IO_START    0x00008000
-#define PCI_IO_END      0x0000ffff
-#define PCI_IO_SIZE     ((PCI_IO_END - PCI_IO_START) + 1)
-
-#define PCI_MEM_START   0x00000000
-#define PCI_MEM_END     0x0fffffff
-#define PCI_MEM_SIZE    ((PCI_MEM_END - PCI_MEM_START) + 1)
-	...
-	struct pciconf_resources *pcires;
-	...
-	pcires = pciconf_resource_init();
-	pciconf_resource_add(pcires, PCICONF_RESOURCE_IO,
-	    PCI_IO_START, PCI_IO_SIZE);
-	pciconf_resource_add(pcires, PCICONF_RESOURCE_MEM,
-	    PCI_MEM_START, PCI_MEM_SIZE);
-	...
-	pci_configure_bus(pc, pcires, 0, CACHELINESIZE);
-	...
-	pciconf_resource_fini(pcires);
-	...

-

-
Note that this must be called before the PCI bus is attached
-    during autoconfiguration.

-

-

-

-
pci(4)

-

-

-

-
pci_configure_bus() was added in
-    NetBSD 1.6.

-

-

-
-  
-    
-    
-  
-
July 7, 2020NetBSD 10.1

diff --git a/static/netbsd/man9/pci_intr.9 3.html b/static/netbsd/man9/pci_intr.9 3.html
deleted file mode 100644
index b80bb699..00000000
--- a/static/netbsd/man9/pci_intr.9 3.html	
+++ /dev/null
@@ -1,184 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_INTR(9)Kernel Developer's ManualPCI_INTR(9)

-

-

-

-
pci_intr,
-    pci_intr_map,
-    pci_intr_string,
-    pci_intr_evcnt,
-    pci_intr_establish,
-    pci_intr_establish_xname,
-    pci_intr_disestablish,
-    pci_intr_setattr — PCI bus
-    interrupt manipulation functions

-

-

-

-
#include
-    <dev/pci/pcivar.h>

-
int
-  

-  pci_intr_map(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t
-  *ih);

-
const char *
-  

-  pci_intr_string(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    ih, char *buf,
-    size_t len);

-
const struct evcnt *
-  

-  pci_intr_evcnt(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    ih);

-
void *
-  

-  pci_intr_establish(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    ih, int ipl,
-    int (*intrhand)(void *),
-    void *intrarg);

-
void *
-  

-  pci_intr_establish_xname(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    ih, int ipl,
-    int (*intrhand)(void *),
-    void *intrarg,
-    const char *xname);

-
void
-  

-  pci_intr_disestablish(pci_chipset_tag_t
-    pc, void *ih);

-
int
-  

-  pci_intr_setattr(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    *ih, int attr,
-    uint64_t data);

-

-

-

-
The pci_intr functions exist to allow
-    device drivers machine-independent access to PCI bus interrupts. The
-    functions described in this page are typically declared in a port's
-    <machine/pci_machdep.h>
-    header file; however, drivers should generally include
-    <dev/pci/pcivar.h> to get
-    other PCI-specific declarations as well.

-
Each driver has an
-    ()
-    function which has a bus-specific attach_args
-    structure. Each driver for a PCI device is passed a pointer to an object of
-    type struct pci_attach_args which contains, among
-    other things, information about the location of the device in the PCI bus
-    topology sufficient to allow interrupts from the device to be handled.

-
If a driver wishes to establish an interrupt
-    handler for the device, it should pass the struct
-    pci_attach_args * to the
-    ()
-    function, which returns zero on success, and nonzero on failure. The
-    function sets the pci_intr_handle_t pointed at by its
-    second argument to a machine-dependent value which identifies a particular
-    interrupt source.

-
If the driver wishes to refer to the
-    interrupt source in an attach or error message, it should use the value
-    returned by
-    ().
-    The buffer passed to pci_intr_string() should be at
-    least PCI_INTRSTR_LEN bytes.

-
Subsequently, when the driver is prepared
-    to receive interrupts, it should call
-    ()
-    to actually establish the handler; when the device interrupts,
-    intrhand will be called with a single argument
-    intrarg, and will run at the interrupt priority level
-    ipl.

-
The return value of
-    ()
-    may be saved and passed to
-    ()
-    to disable the interrupt handler when the driver is no longer interested in
-    interrupts from the device.

-
()
-    is almost the same as pci_intr_establish(). The
-    difference is only xname which is used by
-    intrctl(8) to show the device name(s) of the interrupt
-  id.

-
The
-    ()
-    function sets an attribute attr of the interrupt
-    handler to data. Currently, only the following
-    attribute is supported:

-

-  

-  
If this attribute is set to true, it specifies
-      that the interrupt handler is multiprocessor safe and works its own
-      locking; otherwise the kernel lock will be held for the call to the
-      interrupt handler. The default is false.

-

-
The
-    ()
-    function returns zero on success, and nonzero on failure.

-
The
-    ()
-    function should return an evcnt structure pointer or
-    NULL if there is no evcnt associated with this
-    interrupt. See evcnt(9) for more details.

-

-

-
A port's implementation of pci_intr_map()
-    may use the following members of struct
-    pci_attach_args to determine how the device's interrupts are
-  routed.

-

-
	pci_chipset_tag_t pa_pc;
-	pcitag_t pa_tag;
-	pcitag_t pa_intrtag; /* intr. appears to come from here */
-	pci_intr_pin_t pa_intrpin; /* intr. appears on this pin */
-	pci_intr_line_t pa_intrline; /* intr. routing information */
-	pci_intr_pin_t pa_rawintrpin; /* unswizzled pin */

-

-
PCI-PCI bridges swizzle (permute) interrupt wiring. Depending on
-    implementation details, it may be more convenient to use either original or
-    the swizzled interrupt parameters. The original device tag and interrupt pin
-    can be found in pa_tag and
-    pa_rawintrpin respectively, while the swizzled tag and
-    pin can be found in pa_intrtag and
-    pa_intrpin.

-
When a device is attached to a primary bus, both pairs of fields
-    contain the same values. When a device is found behind one or more pci-pci
-    bridges, pa_intrpin contains the
-    “swizzled” interrupt pin number, while
-    pa_rawintrpin contains the original interrupt pin;
-    pa_tag contains the PCI tag of the device itself, and
-    pa_intrtag contains the PCI tag of the uppermost
-    bridge device.

-

-

-

-

-
evcnt(9), pci(9),
-    pci_msi(9)

-

-

-

-
pci_intr_establish_xname() was added in
-    NetBSD 8.0 as part of MSI/MSI-X support.

-

-

-
-  
-    
-    
-  
-
September 20, 2018NetBSD 10.1

diff --git a/static/netbsd/man9/pci_msi.9 3.html b/static/netbsd/man9/pci_msi.9 3.html
deleted file mode 100644
index 1c2d0d0e..00000000
--- a/static/netbsd/man9/pci_msi.9 3.html	
+++ /dev/null
@@ -1,296 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCI_MSI(9)Kernel Developer's ManualPCI_MSI(9)

-

-

-

-
pci_msi, pci_msix,
-    pci_msi_count,
-    pci_msi_alloc,
-    pci_msi_alloc_exact,
-    pci_msix_count,
-    pci_msix_alloc,
-    pci_msix_alloc_exact,
-    pci_msix_alloc_map,
-    pci_intx_alloc,
-    pci_intr_alloc,
-    pci_intr_release,
-    pci_intr_type — PCI MSI{,-X}
-    manipulation functions

-

-

-

-
int
-  

-  pci_msi_count(pci_chipset_tag_t
-    pc, pcitag_t
-  tag);

-
int
-  

-  pci_msi_alloc(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t **ihps,
-    int *count);

-
int
-  

-  pci_msi_alloc_exact(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t **ihps,
-    int count);

-
int
-  

-  pci_msix_count(pci_chipset_tag_t
-    pc, pcitag_t
-  tag);

-
int
-  

-  pci_msix_alloc(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t **ihps,
-    int *count);

-
int
-  

-  pci_msix_alloc_exact(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t **ihps,
-    int count);

-
int
-  

-  pci_msix_alloc_map(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t **ihps,
-    u_int *table_indexes,
-    int count);

-
int
-  

-  pci_intx_alloc(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t
-  **ihp);

-
int
-  

-  pci_intr_alloc(const
-    struct pci_attach_args *pa,
-    pci_intr_handle_t **ihp,
-    int *counts,
-    pci_intr_type_t
-    max_type);

-
void
-  

-  pci_intr_release(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    *pih, int
-  count);

-
pci_intr_type_t
-  

-  pci_intr_type(pci_chipset_tag_t
-    pc, pci_intr_handle_t
-    ih);

-

-

-

-
The pci_msi functions exist to allow
-    device drivers to use MSI/MSI-X. When the system uses MSI/MSI-X, it must
-    define the __HAVE_PCI_MSI_MSIX build option.

-
Each driver has an
-    ()
-    function which has a bus-specific attach_args
-    structure. Each driver for a PCI device is passed a pointer to an object of
-    type struct pci_attach_args which contains, among
-    other things, information about the location of the device in the PCI bus
-    topology sufficient to allow interrupts from the device to be handled.

-
()
-    returns the max number of the device's MSI. If the device can not use MSI,
-    pci_msi_count() returns zero.
-    ()
-    works in the same manner for MSI-X.

-
If a driver wishes to establish an MSI handler
-    for the device, it should pass the struct pci_attach_args
-    * and count
-    ()
-    or
-    ()
-    functions, which return zero on success, and nonzero on failure. When the
-    functions are successful, they return the pointer to the allocated handle
-    array in pihs whose size is
-    count or less. The difference between
-    pci_msi_alloc() and
-    pci_msi_alloc_exact() is whether
-    count can be decremented or not.
-    pci_msi_alloc() can decrement
-    count, and which is similar to
-    FreeBSD's
-    ().
-    In contrast, pci_msi_alloc_exact() can not decrement
-    count.

-
If the driver wishes to refer to the MSI
-    source in an attach or error message, it should use the value returned by
-    ()
-    the same as INTx. The buffer passed to
-    pci_intr_string() should be at least
-    PCI_INTRSTR_LEN bytes long.

-
Subsequently, when the driver is prepared
-    to receive MSIs, it should call
-    ()
-    the same as INTx to actually establish the handler; when the device
-    interrupts, intrhand will be called with a single
-    argument intrarg, and will run at the interrupt
-    priority level ipl.

-
The return value of
-    ()
-    may be saved and passed to
-    ()
-    to disable the interrupt handler the same as INTx when the driver is no
-    longer interested in MSIs from the device. After that, the driver should
-    also call pci_intr_release() to free resources about
-    MSI as well as INTx and MSI-X. If pih is NULL,
-    pci_intr_release() does nothing.

-
If a driver wishes to establish an MSI-X
-    handler for the device, it is almost the same as MSI. The only differences
-    is
-    ().
-    This function can assign separate handlers for each MSI-X table entry. I.e.,
-    if the driver wants to assign the handlers in the following way:

-

-
	msix_handler0 => MSI-X table index: 4
-	msix_handler1 => MSI-X table index: 5
-	msix_handler2 => MSI-X table index: 0

-

-the driver should set table_indexes this way:
-

-
	table_indexes[0] = 4;
-	table_indexes[1] = 5;
-	table_indexes[2] = 0;

-

-
If the driver wants to fall back to INTx, the
-    driver should use
-    ()
-    and
-    ()
-    instead of
-    ()
-    to resolve contradiction of the interrupt handler ownership. I.e.,
-    pci_intr_map() does not have the ownership (the
-    function just calculates value), in contrast,
-    pci_msi_alloc() and
-    ()
-    have (the functions allocate memory for interrupt handlers).

-
()
-    is wrapper function which select and automatically fallback allocation
-    functions according to the argument counts. The
-    elements of counts array means each required interrupt
-    count for INTx, MSI, and MSI-X. The index count of
-    counts must be
-    PCI_INTR_TYPE_SIZE. max_type
-    must be PCI_INTR_TYPE_MSIX,
-    PCI_INTR_TYPE_MSI, or
-    PCI_INTR_TYPE_INTX. The parameter does not mean
-    array index counts of counts. The parameter means the
-    interrupt type which pci_intr_alloc() tries to
-    allocate first. I.e., if the driver wants to allocate interrupts in the
-    following way:

-

-
	5 MSI-X
-	1 MSI (if MSI-X allocation failed)
-	INTx (if MSI allocation failed either)

-

-the driver should call pci_intr_alloc() in the following
-  way:
-

-
	int counts[PCI_INTR_TYPE_SIZE];
-	counts[PCI_INTR_TYPE_MSIX] = 5;
-	counts[PCI_INTR_TYPE_MSI] = 1;
-	counts[PCI_INTR_TYPE_INTX] = 1;
-	error = pci_intr_alloc(pa, ihps, counts,
-			       PCI_INTR_TYPE_MSIX);

-

-If the driver wants to allocate interrupts in the following way:
-

-
	hardware max number MSI-X
-	1 MSI (if MSI-X allocation failed)

-

-that is, the driver does not use INTx, the driver should call
-  pci_intr_alloc() in the following way:
-

-
	int counts[PCI_INTR_TYPE_SIZE];
-	counts[PCI_INTR_TYPE_MSIX] = -1; /* -1 means max */
-	counts[PCI_INTR_TYPE_MSI] = 1;
-	counts[PCI_INTR_TYPE_INTX] = 0; /* 0 means not use */
-	error = pci_intr_alloc(pa, ihps, counts,
-			       PCI_INTR_TYPE_MSIX);

-

-If the driver wants to allocate interrupts in the following way:
-

-
	3 MSI
-	INTx (if MSI allocation failed)

-

-that is, the driver does not use MSI-X, the driver should call
-  pci_intr_alloc() in the following way:
-

-
	int counts[PCI_INTR_TYPE_SIZE];
-	counts[PCI_INTR_TYPE_MSIX] = 0; /* 0 means not use */
-	counts[PCI_INTR_TYPE_MSI] = 3;
-	counts[PCI_INTR_TYPE_INTX] = 1;
-	error = pci_intr_alloc(pa, ihps, counts,
-			       PCI_INTR_TYPE_MSI);

-

-If the driver wants to allocate interrupts in the following way:
-

-
	1 MSI-X
-	1 MSI
-	INTx (if MSI/MSI-X allocation failed)

-

-that is, general usage, the driver should call simply
-  pci_intr_alloc() in the following way:
-

-
	error = pci_intr_alloc(pa, ihps, NULL, 0);

-

-max_type is ignored in this case.
-  pci_intr_alloc() returns zero on any allocation
-  function success, and non-zero on all allocation function failures. On
-  success, counts is overwritten by a really allocated
-  count. I.e., if 5 MSI-X is allocated, counts is
-

-
	counts[PCI_INTR_TYPE_MSIX] == 5
-	counts[PCI_INTR_TYPE_MSI] == 0
-	counts[PCI_INTR_TYPE_INTX] == 0

-

-on return.
-
()
-    returns the interrupt type of ih. The return value is
-    PCI_INTR_TYPE_MSIX for MSI-X,
-    PCI_INTR_TYPE_MSI for MSI, and
-    PCI_INTR_TYPE_INTX for others.

-

-

-

-
pci_intr(9)

-

-

-

-
pci_msi support first appeared in
-    NetBSD 8.0. Support is present on
-    ,
-    
-    and
-    
-    architectures.

-

-

-

-
The pci_msi interfaces were designed and
-    implemented by Kengo Nakahara
-    <knakahara@NetBSD.org>.

-

-

-
-  
-    
-    
-  
-
January 12, 2021NetBSD 10.1

diff --git a/static/netbsd/man9/pckbport.9 3.html b/static/netbsd/man9/pckbport.9 3.html
deleted file mode 100644
index d1920d32..00000000
--- a/static/netbsd/man9/pckbport.9 3.html	
+++ /dev/null
@@ -1,319 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCKBPORT(9)Kernel Developer's ManualPCKBPORT(9)

-

-

-

-
pckbport,
-    pckbport_attach,
-    pckbport_attach_slot,
-    pckbport_cnattach,
-    pckbportintr,
-    pckbport_set_inputhandler,
-    pckbport_flush,
-    pckbport_poll_cmd,
-    pckbport_enqueue_cmd,
-    pckbport_poll_data,
-    pckbport_set_poll,
-    pckbport_xt_translation,
-    pckbport_slot_enable — PC
-    keyboard port interface

-

-

-

-
#include
-    <dev/pckbport/pckbportvar.h>

-
pckbport_tag_t
-  

-  pckbport_attach(void
-    *, struct
-    pckbport_accessops const *);

-
struct device *
-  

-  pckbport_attach_slot(struct
-    device *,
-    pckbport_tag_t,
-    pckbport_slot_t);

-
int
-  

-  pckbport_cnattach(void
-    *, struct
-    pckbport_accessops const *,
-    pckbport_slot_t);

-
void
-  

-  pckbportintr(pckbport_tag_t,
-    pckbport_slot_t,
-    int);

-
void
-  

-  pckbport_set_inputhandler(pckbport_tag_t,
-    pckbport_slot_t,
-    pckbport_inputfcn,
-    void *,
-    char *);

-
void
-  

-  pckbport_flush(pckbport_tag_t,
-    pckbport_slot_t);

-
int
-  

-  pckbport_poll_cmd(pckbport_tag_t,
-    pckbport_slot_t,
-    u_char *,
-    int,
-    int,
-    u_char *,
-    int);

-
int
-  

-  pckbport_enqueue_cmd(pckbport_tag_t,
-    pckbport_slot_t,
-    u_char *,
-    int,
-    int,
-    int,
-    u_char *);

-
int
-  

-  pckbport_poll_data(pckbport_tag_t,
-    pckbport_slot_t);

-
void
-  

-  pckbport_set_poll(pckbport_tag_t,
-    pckbport_slot_t,
-    int);

-
int
-  

-  pckbport_xt_translation(pckbport_tag_t,
-    pckbport_slot_t,
-    int);

-
void
-  

-  pckbport_slot_enable(pckbport_tag_t,
-    pckbport_slot_t,
-    int);

-

-

-

-
The machine-independent pckbport subsystem
-    provides an interface layer corresponding to the serial keyboard and mouse
-    interface used on the IBM PS/2 and many other machines. It interfaces a
-    controller driver such as pckbc(4) to device drivers such
-    as pckbd(4) and pms(4).

-
A single controller can have up to two ports (known as
-    “slots”), and these are identified by values of type
-    pckbport_slot_t. The values
-    PCKBPORT_KBD_SLOT and
-    PCKBPORT_AUX_SLOT should be used for keyboard and
-    mouse ports respectively. Each controller is identified by an opaque value
-    of type pckbport_tag_t.

-

-

-
A PC keyboard controller registers itself by calling
-    (cookie,
-    ops), with ops being a pointer
-    to a struct pckbport_accessops containing pointers to
-    functions for driving the controller, which will all be called with
-    cookie as their first argument.
-    pckbport_attach() returns the
-    pckbport_tag_t assigned to the controller. The
-    controller is then expected to call
-    ()
-    for each slot with which it is equipped, passing the struct
-    device * corresponding to the controller. This function returns a
-    pointer to the child device attached to the slot, or
-    NULL if no such device was attached.

-
The elements of struct
-    pckbport_accessops each take as their first two arguments the
-    cookie passed to
-    ()
-    and the slot in question. The elements are:

-

-  
int
-    (*t_xt_translation)(void
-    *cookie, pckbport_slot_t slot,
-    int on)

-  
If on is non-zero, enable, otherwise disable,
-      AT-to-XT keycode translation on the slot specified. Returns 1 on success,
-      0 on failure (or if the controller does not support such
-    translation).

-  
int
-    (*t_send_devcmd)(void *cookie,
-    pckbport_slot_t slot, u_char
-    byte)

-  
Send a single byte to the device without waiting for
-      completion. Returns 1 on success, 0 on failure.

-  
int
-    (*t_poll_data1)(void *cookie,
-    pckbport_slot_t slot)

-  
Wait for and return one byte of data from the device, without using
-      interrupts. This function will only be called after
-      (*t_set_poll)() has been used to put the slot in
-      polling mode. If no data are forthcoming from the device after about
-      100ms, return -1.

-  
void
-    (*t_slot_enable)(void *cookie,
-    pckbport_slot_t slot, int
-    on)

-  
If on is non-zero, enable, otherwise disable, the
-      slot. If a slot is disabled, it can be powered down, and is not expected
-      to generate any interrupts. When first attached, ports should be
-    disabled.

-  
void
-    (*t_intr_establish)(void
-    *cookie, pckbport_slot_t slot)

-  
Set up an interrupt handler for the slot. Called when a device gets
-      attached to it.

-  
void
-    (*t_set_poll)(void *cookie,
-    pckbport_slot_t slot, int
-    on)

-  
If on is non-zero, enable, otherwise disable,
-      polling mode on the slot. In polling mode, data received from the device
-      are provided to (*t_poll_data1)() and not passed
-      to
-      (),
-      whether or not interrupts are enabled. In non-polling mode, data from the
-      device are expected to cause interrupts. The controller interrupt handler
-      should call
-      pckbportintr(tag,
-      slot, byte) once for each
-      byte received from the device. When first attached,
-      a port should be in non-polling mode.

-

-

-

-

-
Devices that attach to pckbport
-    controllers do so using the normal autoconf(9) mechanism.
-    Their (*ca_match)() and
-    (*ca_attach)() functions get passed a
-    struct pckbport_attach_args which contains the
-    controller and slot number where the device was found. Device drivers can
-    use the following functions to communicate with the controller. Each takes
-    tag and slot arguments to
-    specify the slot to be acted on.

-

-  
(tag,
-    slot, fn,
-    arg, name)

-  
Arrange for fn to be called with argument
-      arg whenever an unsolicited byte is received from
-      the slot. The function will be called at
-      ().

-  
(tag,
-    slot)

-  
Ensure that there is no pending input from the slot.

-  
(tag,
-    slot, cmd,
-    len, responselen,
-    respbuf, slow)

-  
Issue a complete device command, cmd,
-      len bytes long, expecting a response
-      responselen bytes long, which will be placed in
-      respbuf. If slow is true, the
-      command is expected to take over a second to execute.
-      pckbport_poll_cmd() handles getting an
-      acknowledgement from the device and retrying the command if necessary.
-      Returns 0 on success, and an error value on failure. This function should
-      only be called during autoconfiguration or when the slot has been placed
-      into polling mode by
-      ().

-  
(tag,
-    slot, cmd,
-    len, responselen,
-    sync, respbuf)

-  
Issue a complete device command, cmd,
-      len bytes long, expecting a response
-      responselen bytes long, which will be places in
-      respbuf. If sync is true,
-      pckbport_enqueue_cmd() waits for the command to
-      complete before returning, otherwise it returns immediately. It is not
-      safe to set sync when calling from an interrupt
-      context. The pckbport layer handles getting an
-      acknowledgement from the device and retrying the command if necessary.
-      Returns 0 on success, and an error value on failure.

-  
(tag,
-    slot)

-  
Low-level command to poll for a single byte of data from the device, but
-      ignoring bytes that are part of the response to a command issued through
-      ().

-  
pckbport_set_poll(tag,
-    slot, on)

-  
If on is true, enable polling on the slot, otherwise
-      disable it. In polling mode, pckbport_poll_cmd()
-      can be used to issue commands and
-      pckbport_poll_data() to read unsolicited data,
-      without enabling interrupts. In non-polling mode, commands should be
-      issued using pckbport_enqueue_cmd(), unsolicited
-      data are handled by the input function, and disabling interrupts will
-      suspend pckbport operation.

-  
(tag,
-    slot, on)

-  
Passthrough of (*t_xt_translation)() (see
-    above).

-  
(enable,
-    tag, slot,
-    on)

-  
Passthrough of (*t_slot_enable)() (see
-    above).

-

-

-

-

-
On systems that can attach consoles through
-    pckbport, the controller's console attachment
-    function (called very early in autoconfiguration) calls
-    (cookie,
-    ops, slot). The first two
-    arguments are the same as for pckbport_attach(),
-    while the third indicates which slot the console keyboard is attached to.
-    pckbport_cnattach() either calls
-    (),
-    if it is available, or
-    ().
-    The latter allows machine-dependent keyboard drivers to attach themselves,
-    but it is only called if a device with the
-    ‘pckbport_machdep_cnattach’ attribute
-    is configured into the system. pckbport_cnattach()
-    returns 0 on success and an error value on failure.
-    pckbport_machdep_cnattach() is expected to do the
-    same.

-

-

-

-

-
The pckbport code, and the
-    pckbd(4) and pms(4) device drivers are
-    in sys/dev/pckbport.

-

-

-

-
pckbc(4), pckbd(4),
-    pms(4), autoconf(9),
-    spl(9)

-

-

-

-
The pckbport system appeared in
-    NetBSD 2.0. Before that, pckbd(4)
-    and pms(4) attached directly to pckbc(4)
-    without any sensible way of using a different controller.

-

-

-
-  
-    
-    
-  
-
August 5, 2004NetBSD 10.1

diff --git a/static/netbsd/man9/pcq.9 3.html b/static/netbsd/man9/pcq.9 3.html
deleted file mode 100644
index 0dc43915..00000000
--- a/static/netbsd/man9/pcq.9 3.html	
+++ /dev/null
@@ -1,162 +0,0 @@
-
-  
-    
-    
-    
-  
-
PCQ(9)Kernel Developer's ManualPCQ(9)

-

-

-

-
pcq —
-    producer/consumer queue

-

-

-

-
#include
-    <sys/pcq.h>

-
pcq_t *
-  

-  pcq_create(size_t
-    maxlen, km_flags_t
-    kmflags);

-
void
-  

-  pcq_destroy(pcq_t
-    *pcq);

-
void *
-  

-  pcq_get(pcq_t
-    *pcq);

-
size_t
-  

-  pcq_maxitems(pcq_t
-    *pcq);

-
void *
-  

-  pcq_peek(pcq_t
-    *pcq);

-
bool
-  

-  pcq_put(pcq_t
-    *pcq, void
-  *item);

-

-

-

-
The machine-independent pcq interface
-    provides lockless producer/consumer queues. A queue
-    (pcq_t) allows multiple writers (producers), but only
-    a single reader (consumer). The consumer is expected to be protected by a
-    lock that covers the structure that the pcq_t is
-    embedded into (e.g., socket lock, ifnet hwlock). These queues operate in a
-    first-in, first-out (FIFO) manner. The act of inserting or removing an item
-    from a pcq_t does not modify the item in any way.
-    pcq does not prevent an item from being inserted
-    multiple times into a single pcq_t.

-

-

-

-

-  
(maxlen,
-    kmflags)

-  
Create a queue that can store at most maxlen items
-      at one time. kmflags should be either
-      KM_SLEEP, if pcq_create()
-      is allowed to sleep until resources are available, or
-      KM_NOSLEEP if it should return
-      NULL immediately, if resources are
-    unavailable.

-  
(pcq)

-  
Free the resources held by pcq.

-  
pcq_get(pcq)

-  
Remove the next item to be consumed from the queue and return it. If the
-      queue is empty, return NULL. The caller must
-      prevent concurrent gets from occurring.

-  
(pcq)

-  
Return the maximum number of items that the queue can store at any one
-      time.

-  
pcq_peek(pcq)

-  
Return the next item to be consumed from the queue but do not remove it
-      from the queue. If the queue is empty, return
-      NULL.

-  
pcq_put(pcq,
-    item)

-  
Place an item at the end of the queue. If there is no room in the queue
-      for the item, return false; otherwise, return
-      true. The item must not have the value of
-      NULL.

-

-

-

-
Any memory operations sequenced before
-    pcq_put() of an item in one thread happen before all
-    memory operations with data dependencies on the item returned by
-    pcq_get() or pcq_peek() in
-    another thread. For example:

-

-
int mumble;
-
-/* producer */
-mumble = 42;			// A
-foo->x = 123;			// B
-refcnt = foo->refcnt;		// C
-pcq_put(pcq, foo);
-KASSERT(refcnt == 0);
-
-/* consumer */
-foo = pcq_get(pcq);
-if (foo == NULL)
-	return;
-atomic_inc_uint(&foo->refcnt);	// D
-x = foo->x;			// E
-if (x == 123)
-	KASSERT(mumble == 42);	// F

-

-
In this example, memory operations B and C
-    happen-before D and E. However, no ordering is guaranteed for A or F
-    relative to any other memory operations, because the memory location of
-    mumble is independent of the pointer
-    foo returned by
-    ().

-
If you must guarantee A happens before F, then on
-    the consumer side, after
-    ()
-    or
-    (),
-    you can call
-    ()
-    to turn it into an acquire operation instead of a consume operation;
-    ()
-    serves as the matching release operation. (This is a little dicey. Perhaps
-    there should be separate
-    ()
-    and
-    ()
-    operations if this semantics is necessary.)

-

-

-

-

-
The pcq interface is implemented within
-    the file sys/kern/subr_pcq.c.

-

-

-

-
atomic_ops(3), queue(3)

-

-

-

-
The pcq interface first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
January 22, 2012NetBSD 10.1

diff --git a/static/netbsd/man9/pfil.9 3.html b/static/netbsd/man9/pfil.9 3.html
deleted file mode 100644
index f140ca0d..00000000
--- a/static/netbsd/man9/pfil.9 3.html	
+++ /dev/null
@@ -1,246 +0,0 @@
-
-  
-    
-    
-    
-  
-
PFIL(9)Kernel Developer's ManualPFIL(9)

-

-

-

-
pfil,
-    pfil_head_create,
-    pfil_head_destroy,
-    pfil_head_get,
-    pfil_hook_get,
-    pfil_add_hook,
-    pfil_remove_hook,
-    pfil_run_hooks,
-    pfil_add_ihook,
-    pfil_remove_ihook,
-    pfil_run_addrhooks,
-    pfil_run_ifhooks — packet
-    filter interface

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mbuf.h>
-  

-  #include <net/if.h>
-  

-  #include <net/pfil.h>

-
pfil_head_t *
-  

-  pfil_head_create(int
-    type, void
-  *key);

-
int
-  

-  pfil_head_destroy(pfil_head_t
-    *ph);

-
pfil_head_t *
-  

-  pfil_head_get(int
-    type, void
-  *key);

-
struct packet_filter_hook *
-  

-  pfil_hook_get(int
-    dir, pfil_head_t
-    *ph);

-
int
-  

-  pfil_add_hook(pfil_func_t
-    func, void *arg,
-    int flags,
-    pfil_head_t *ph);

-
int
-  

-  pfil_remove_hook(pfil_func_t
-    func, void *arg,
-    int flags,
-    pfil_head_t *ph);

-
int
-  

-  (*func)(void
-    *arg, struct mbuf
-    **mp, struct ifnet
-    *, int dir);

-
int
-  

-  pfil_run_hooks(pfil_head_t
-    *ph, struct mbuf
-    **mp, struct ifnet
-    *ifp, int dir);

-
int
-  

-  pfil_add_ihook(pfil_ifunc_t
-    ifunc, void *arg,
-    int flags,
-    pfil_head_t *ph);

-
int
-  

-  pfil_remove_ihook(pfil_ifunc_t
-    ifunc, void *arg,
-    int flags,
-    pfil_head_t *ph);

-
void
-  

-  (*ifunc)(void
-    *arg, unsigned long
-    cmd, void
-  *ptr);

-
void
-  

-  pfil_run_addrhooks(pfil_head_t
-    *ph, unsigned long,
-    struct ifaddr *ifa);

-
void
-  

-  pfil_run_ifhooks(pfil_head_t
-    *ph, unsigned long,
-    struct ifnet *ifp);

-

-

-

-
The pfil framework allows for a specified
-    function to be invoked for every incoming or outgoing packet for a
-    particular network I/O stream. These hooks may be used to implement a
-    firewall or perform packet transformations.

-
Packet filtering points are created with
-    ().
-    Filtering points are identified by a data link (int)
-    type and a (void *)
-    key. If a packet filtering point already exists for
-    that data link type and key then
-    the pfil_head_create() function returns
-    NULL. Packet filters use the
-    ()
-    function specifying the data link type and the
-    key to look up the filtering point with which they
-    register themselves. The key is unique to the
-    filtering point. The data link type is a
-    bpf(4)
-    DLT_type constant indicating
-    what kind of header is present on the packet at the filtering point.
-    Filtering points may be destroyed with the
-    ()
-    function.

-
Packet filters register/unregister themselves
-    with a filtering point with the
-    ()
-    and
-    ()
-    functions, respectively. The head is looked up using the
-    ()
-    function, which takes the data link type and the
-    key that the packet filter expects. Filters may
-    provide an argument to be passed to the filter when invoked on a packet.

-
When a filter is invoked, the packet appears just as if it
-    “came off the wire”. That is, all protocol fields are in
-    network byte order. The filter is called with its specified argument, the
-    pointer to the pointer to the mbuf containing the packet, the pointer to the
-    network interface that the packet is traversing, and the direction (either
-    PFIL_IN or PFIL_OUT, see
-    also below) that the packet is traveling. The filter may change which mbuf
-    the mbuf ** argument references. The filter returns an
-    errno if the packet processing is to stop, or 0 if the processing is to
-    continue. If the packet processing is to stop, it is the responsibility of
-    the filter to free the packet.

-
The flags parameter,
-    used in the
-    ()
-    and
-    ()
-    functions, indicates when the filter should be called. The flags are:

-

-

-

-  

-  
call me on incoming packets

-  

-  
call me on outgoing packets

-  

-  
call me on all of the above

-

-

-
By the same token, event handlers
-    register/unregister themselves with the
-    ()
-    and
-    ()
-    functions, respectively. The event handler is called with its specified
-    argument, the event id (either PFIL_IFNET_ATTACH or
-    PFIL_IFNET_DETACH, see also below) or ioctl number,
-    and the pointer to the network interface or the pointer to the ifaddr.

-
The flags parameter,
-    used in the
-    ()
-    and
-    ()
-    functions, indicates when the filter should be called. The flags are:

-

-

-

-  

-  
call me on interface reconfig (cmd is ioctl #)

-  

-  
call me on interface attach/detach (cmd is either
-      PFIL_IFNET_ATTACH or
-      PFIL_IFNET_DETACH)

-

-

-

-

-

-
bpf(4)

-

-

-

-
The pfil interface first appeared in
-    NetBSD 1.3. The pfil input
-    and output lists were originally implemented as
-    <sys/queue.h>
-    LIST structures; however this was changed in
-    NetBSD 1.4 to TAILQ
-    structures. This change was to allow the input and output filters to be
-    processed in reverse order, to allow the same path to be taken, in or out of
-    the kernel.

-
The pfil interface was changed in 1.4T to
-    accept a 3rd parameter to both pfil_add_hook() and
-    pfil_remove_hook(), introducing the capability of
-    per-protocol filtering. This was done primarily in order to support
-    filtering of IPv6.

-
In 1.5K, the pfil framework was changed to
-    work with an arbitrary number of filtering points, as well as be less
-    IP-centric.

-
pfil_add_ihook() and
-    pfil_remove_ihook() were added in
-    NetBSD 8.0.

-

-

-

-
The pfil interface was designed and
-    implemented by Matthew R. Green, with help from
-    Darren Reed, Jason R.
-    Thorpe, and Charles M. Hannum.
-    Darren Reed added support for IPv6 in addition to
-    IPv4. Jason R. Thorpe added support for multiple
-    hooks and other clean up.

-

-

-

-
The current pfil implementation will need
-    changes to suit a threaded kernel model.

-

-

-
-  
-    
-    
-  
-
January 15, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/physio.9 3.html b/static/netbsd/man9/physio.9 3.html
deleted file mode 100644
index 6f566d57..00000000
--- a/static/netbsd/man9/physio.9 3.html	
+++ /dev/null
@@ -1,93 +0,0 @@
-
-  
-    
-    
-    
-  
-
PHYSIO(9)Kernel Developer's ManualPHYSIO(9)

-

-

-

-
physio — initiate
-    I/O on raw devices

-

-

-

-
int
-  

-  physio(void (*strategy)(buf_t
-    *), buf_t *bp, dev_t dev,
-    int flags, void (*minphys)(buf_t
-    *), struct uio *uio);

-

-

-

-
The
-    ()
-    is a helper function typically called from character device read and write
-    routines to start I/O on a user process buffer. It calls back on the
-    provided strategy routine one or more times to
-    complete the transfer described by uio. The maximum
-    amount of data to transfer with each call to strategy
-    is determined by the minphys routine.

-
Since uio normally describes
-    user space addresses,
-    ()
-    needs to lock the appropriate data area into memory before each transaction
-    with strategy (see uvm_vslock(9) and
-    uvm_vsunlock(9)). The physio()
-    function always awaits the completion of the entire requested transfer
-    before returning, unless an error condition is detected earlier. In all
-    cases, the buffer passed in bp is locked (marked as
-    “busy”) for the duration of the entire transfer.

-
A break-down of the arguments follows:

-

-  
strategy

-  
The device strategy routine to call for each chunk of data to initiate
-      device I/O.

-  
bp

-  
The buffer to use with the strategy routine. The buffer flags will have
-      B_BUSY, B_PHYS, and
-      B_RAW set when passed to the strategy routine. If
-      NULL, a buffer is allocated from a system
-    pool.

-  
dev

-  
The device number identifying the device to interact with.

-  
flags

-  
Direction of transfer; the only valid settings are
-      B_READ or B_WRITE.

-  
minphys

-  
A device specific routine called to determine the maximum transfer size
-      that the device's strategy routine can handle.

-  
uio

-  
The description of the entire transfer as requested by the user process.
-      Currently, the results of passing a uio structure
-      with the ‘uio_segflg’ set to anything other than
-      UIO_USERSPACE, are undefined.

-

-

-

-

-
If successful physio() returns 0.
-    EFAULT is returned if the address range described by
-    uio is not accessible by the requesting process.
-    physio() will return any error resulting from calls
-    to the device strategy routine, by examining the
-    B_ERROR buffer flag and the ‘b_error’
-    field. Note that the actual transfer size may be less than requested by
-    uio if the device signals an “end of
-    file” condition.

-

-

-

-
read(2), write(2)

-

-

-
-  
-    
-    
-  
-
September 12, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/pmatch.9 3.html b/static/netbsd/man9/pmatch.9 3.html
deleted file mode 100644
index 54a90803..00000000
--- a/static/netbsd/man9/pmatch.9 3.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMATCH(9)Kernel Developer's ManualPMATCH(9)

-

-

-

-
pmatch — performs
-    pattern matching on strings

-

-

-

-
#include
-    <sys/systm.h>

-
int
-  

-  pmatch(const
-    char *string, const char
-    *pattern, const char
-    **estr);

-

-

-

-
Extract substring matching pattern from
-    string. If not NULL,
-    estr points to the end of the longest exact or
-    substring match.

-
()
-    uses the following metacharacters:

-

-  

-  
match any single character.

-  

-  
match any character 0 or more times.

-  

-  
define a range of characters that will match. The range is defined by 2
-      characters separated by a ‘-’. The
-      range definition has to end with a
-      ‘]’. A
-      ‘^’ following the
-      ‘[’ will negate the range.

-

-

-

-

-
pmatch() will return 2 for an exact match,
-    1 for a substring match, 0 for no match and -1 if an error occurs.

-

-

-
-  
-    
-    
-  
-
October 12, 2003NetBSD 10.1

diff --git a/static/netbsd/man9/pmf.9 3.html b/static/netbsd/man9/pmf.9 3.html
deleted file mode 100644
index d9e091dd..00000000
--- a/static/netbsd/man9/pmf.9 3.html	
+++ /dev/null
@@ -1,320 +0,0 @@
-
-  
-    
-    
-    
-  
-
PMF(9)Kernel Developer's ManualPMF(9)

-

-

-

-
PMF,
-    pmf_device_register,
-    pmf_device_register1,
-    pmf_device_deregister,
-    pmf_device_suspend,
-    pmf_device_resume,
-    pmf_device_recursive_suspend,
-    pmf_device_recursive_resume,
-    pmf_device_resume_subtree,
-    pmf_class_network_register,
-    pmf_class_input_register,
-    pmf_class_display_register,
-    pmf_system_suspend,
-    pmf_system_resume,
-    pmf_system_shutdown,
-    pmf_event_register,
-    pmf_event_deregister,
-    pmf_event_inject,
-    pmf_set_platform,
-    pmf_get_platform — power
-    management and inter-driver messaging framework

-

-

-

-
#include
-    <sys/device.h>

-
bool
-  

-  pmf_device_register(device_t
-    dev, bool
-    (*suspend)(device_t dev, const pmf_qual_t *qual),
-    bool (*resume)(device_t dev,
-    const pmf_qual_t *qual));

-
bool
-  

-  pmf_device_register1(device_t
-    dev, bool
-    (*suspend)(device_t dev, const pmf_qual_t *qual),
-    bool (*resume)(device_t dev,
-    const pmf_qual_t *qual),
-    bool (*shutdown)(device_t dev,
-    int how));

-
void
-  

-  pmf_device_deregister(device_t
-    dev);

-
bool
-  

-  pmf_device_suspend(device_t
-    dev, const pmf_qual_t
-    *qual);

-
bool
-  

-  pmf_device_resume(device_t
-    dev, const pmf_qual_t
-    *qual);

-
bool
-  

-  pmf_device_recursive_suspend(device_t
-    dev, const pmf_qual_t
-    *qual);

-
bool
-  

-  pmf_device_recursive_resume(device_t
-    dev, const pmf_qual_t
-    *qual);

-
bool
-  

-  pmf_device_subtree_resume(device_t
-    dev, const pmf_qual_t
-    *qual);

-
void
-  

-  pmf_class_network_register(device_t
-    dev, struct ifnet
-    *ifp);

-
bool
-  

-  pmf_class_input_register(device_t
-    dev);

-
bool
-  

-  pmf_class_display_register(device_t
-    dev);

-
bool
-  

-  pmf_system_suspend(const
-    pmf_qual_t *qual);

-
bool
-  

-  pmf_system_resume(const
-    pmf_qual_t *qual);

-
void
-  

-  pmf_system_shutdown(int);

-
bool
-  

-  pmf_event_register(device_t
-    dev, pmf_generic_event_t
-    ev, void
-    (*handler)(device_t dev),
-    bool global);

-
void
-  

-  pmf_event_deregister(device_t
-    dev, pmf_generic_event_t
-    ev, void
-    (*handler)(device_t dev),
-    bool global);

-
bool
-  

-  pmf_event_inject(device_t
-    dev, pmf_generic_event_t
-    ev);

-
bool
-  

-  pmf_set_platform(const
-    char *key, const char
-    *value);

-
const char *
-  

-  pmf_get_platform(const
-    char *key);

-

-

-

-
The machine-independent PMF framework
-    provides power management and inter-driver messaging support for device
-    drivers.

-

-

-

-
Drivers for devices implementing PMF may
-    make use of the following data type:

-

-  
pmf_qual_t

-  
An opaque aggregate of qualifications on a PMF
-      suspend or resume call.

-  
pmf_generic_event_t

-  
A device driver can register as a listener for specific events, or inject
-      events into the message queue. The following message types are defined:
-    
-  

-

-

-

-

-

-  
(dev,
-    suspend, resume)

-  
Register a device with the power management framework. The
-      suspend and resume functions
-      are passed dev and a
-      pmf_qual_t, and will be called when the system state
-      changes; they should return true on success and
-      false on failure. If either
-      suspend or resume is
-      NULL then it is assumed that device state does not
-      need to be captured and resumed on a power transition. Bus and class-level
-      power management will still be performed.
-    
()
-        always returns true. Callers should ignore the return value.

-  

-  
pmf_device_register1(dev,
-    suspend, resume,
-    shutdown)

-  
Like pmf_device_register(), but additionally
-      registers a shutdown handler. During system shutdown,
-      ()
-      calls shutdown on dev with the
-      reboot(2) “howto” in the second argument.
-      shutdown should return true
-      on success and false on failure.
-    
()
-        always returns true. Callers should ignore the return value.

-  

-  
(dev)

-  
Deregister a device with the power management framework.

-  
(dev,
-    qual)

-  
Suspend a device by first calling the class suspend handler, followed by
-      the driver suspend handler, and finally the bus suspend handler.

-  
(dev,
-    qual)

-  
Resume a device by first calling the bus resume handler, followed by the
-      driver resume handler, and finally the class resume handler.

-  
(dev,
-    qual)

-  
As pmf_device_suspend(), but ensures that all
-      child devices of dev are suspended.

-  
(dev,
-    qual)

-  
As pmf_device_resume(), but ensures that all
-      parent devices of dev are resumed.

-  
(dev,
-    qual)

-  
As pmf_device_resume(), but ensures that all child
-      devices of dev are resumed.

-  
(dev,
-    ifp)

-  
Register a device with the power management framework as a network-class
-      device.

-  
(dev)

-  
Register a device with the power management framework as an input-class
-      device.

-  
(dev)

-  
Register a device with the power management framework as a display-class
-      device.

-  
(qual)

-  
Suspend all attached devices. Devices are suspended by traversing the
-      autoconfiguration tree beginning with the leaf nodes. This function will
-      fail if any attached drivers do not support the power management
-      framework.

-  
(qual)

-  
Resume all attached devices. Devices are resumed by traversing the
-      autoconfiguration tree beginning with devices that do not have a parent.
-      This function will fail if any attached drivers do not support the power
-      management framework.

-  
pmf_system_shutdown(int)

-  
Shutdown all attached devices. Devices are shut down by traversing the
-      autoconfiguration tree beginning with the leaf nodes. The integer argument
-      is passed to the driver shutdown functions. It should contain the
-      reboot(2) “howto” argument. This function
-      ignores the presence of attached drivers that do not support the power
-      management framework.

-  
(dev,
-    ev, handler,
-    global)

-  
Register the callback handler to be called whenever
-      an ev event is triggered. If
-      global is true,
-      handler accepts anonymous events from
-      ().

-  
(dev,
-    ev, handler,
-    global)

-  
Deregister the callback previously registered with
-      pmf_event_register().

-  
pmf_event_inject(dev,
-    ev)

-  
Inject an inter-driver message into the message queue. If
-      dev is NULL, the event is
-      considered to be anonymous and one or more drivers may handle this event,
-      otherwise the event is delivered directly to the callback registered by
-      dev.

-  
(key,
-    value)

-  
Insert a name-value pair into the platform information database.

-  
(key)

-  
Retrieve the value for key from the platform
-      information database. Returns NULL if the key is
-      not present.

-

-

-

-

-
The power management framework is implemented within the files
-    sys/sys/pmf.h,
-    sys/sys/device.h,
-    sys/kern/kern_pmf.c, and
-    sys/kern/subr_autoconf.c.

-

-

-

-
autoconf(9), driver(9)

-

-

-

-
The PMF framework appeared in
-    NetBSD 5.0.

-

-

-

-
Jared D. McNeill
-    <jmcneill@NetBSD.org>
-  

-  Joerg Sonnenberger
-    <joerg@NetBSD.org>

-

-

-

-
pmf_device_register() and
-    pmf_device_register1() never fail and should return
-    void, but until all callers are updated to ignore the return value, they
-    must continue to return bool:
-    PR kern/57575

-

-

-
-  
-    
-    
-  
-
March 9, 2024NetBSD 10.1

diff --git a/static/netbsd/man9/proc_find.9 3.html b/static/netbsd/man9/proc_find.9 3.html
deleted file mode 100644
index 7f11e854..00000000
--- a/static/netbsd/man9/proc_find.9 3.html	
+++ /dev/null
@@ -1,59 +0,0 @@
-
-  
-    
-    
-    
-  
-
PROC_FIND(9)Kernel Developer's ManualPROC_FIND(9)

-

-

-

-
proc_find,
-    pgrp_find — find process or
-    process group

-

-

-

-
#include
-    <sys/proc.h>

-
struct proc *
-  

-  proc_find(pid_t
-    pid);

-
struct pgrp *
-  

-  pgrp_find(pid_t
-    pgid);

-
extern kmutex_t *proc_lock;

-

-

-

-
The
-    ()
-    and
-    ()
-    functions retrieve process and process group structures from process ID
-    pid and process group ID pgid.
-    Both functions must be called by holding a mutex(9) on
-    proc_lock.

-

-

-

-
Upon successful completion, the described functions return a
-    pointer to either struct proc or struct
-    pgrp. Otherwise, if the requested ID was not found,
-    NULL is returned.

-

-

-

-
curproc(9)

-

-

-
-  
-    
-    
-  
-
July 1, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/pserialize.9 3.html b/static/netbsd/man9/pserialize.9 3.html
deleted file mode 100644
index 151a711b..00000000
--- a/static/netbsd/man9/pserialize.9 3.html	
+++ /dev/null
@@ -1,185 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSERIALIZE(9)Kernel Developer's ManualPSERIALIZE(9)

-

-

-

-
pserialize —
-    passive serialization mechanism

-

-

-

-
#include
-    <sys/pserialize.h>

-
pserialize_t
-  

-  pserialize_create(void);

-
void
-  

-  pserialize_destroy(pserialize_t
-    psz);

-
int
-  

-  pserialize_read_enter(void);

-
void
-  

-  pserialize_read_exit(int
-    s);

-
void
-  

-  pserialize_perform(pserialize_t
-    psz);

-

-

-

-
Passive serialization is a reader / writer synchronisation
-    mechanism designed for lock-less read operations. The read operations may
-    happen from software interrupt at IPL_SOFTCLOCK.

-

-

-

-

-  
()

-  
Allocate a new synchronisation object.

-  
()

-  
Destroy the synchronisation object. No synchronisation activity should
-      happen at this point.

-  
()

-  
Enter the critical path of the reader side. Returns an IPL value, which
-      must be passed to pserialize_read_exit(9). Protected
-      code path is not allowed to block.

-  
()

-  
Exit the critical path of the reader side. Takes the IPL value returned by
-      pserialize_read_enter(9).

-  
()

-  
Perform the passive serialization on the writer side. Passing of this
-      function ensures that no readers are in action. Writers are typically
-      additionally serialized with a separate mechanism, e.g.
-      mutex(9), to remove objects used by readers from a
-      published list. Operation blocks and it may only be performed from thread
-      context.

-

-

-

-

-
Given a global database of frotz records:

-

-
	struct frotz {
-		...
-		struct frotz	*f_next;
-	};
-
-	static struct {
-		kmutex_t	lock;
-		pserialize_t	psz;
-		struct frotz	*first;
-	} frobbotzim __cacheline_aligned;

-

-
Create a frotz and publish it, as a writer:

-

-
	struct frotz *f = pool_get(&frotz_pool, PR_WAITOK);
-
-	/* Initialize f.  */
-	...
-
-	mutex_enter(&frobbotzim.lock);
-	f->f_next = frobbotzim.first;
-	/*
-	 * Publish the contents of f->f_next before we publish the
-	 * pointer to f in frobbotzim.first.
-	 */
-	atomic_store_release(&frobbotzim.first, f);
-	mutex_exit(&frobbotzim.lock);

-

-
Find a frotz, as a reader:

-

-
	struct frotz *f;
-	int error = ENOENT;
-	int s;
-
-	s = pserialize_read_enter();
-	/* Fetch frobbotzim.first before we fetch anything it point to.  */
-	for (f = atomic_load_consume(&frobbotzim.first);
-	     f != NULL;
-	     f = f->f_next) {
-		if (f->f_... == key) {
-			/*
-			 * Grab whatever part of the frotz we need.
-			 * Note that we can't use the frotz after
-			 * pserialize_read_exit, without a stronger
-			 * kind of reference, say a reference count
-			 * managed by atomic_ops(3).
-			 */
-			*resultp = f->f_...;
-			error = 0;
-			break;
-		}
-	}
-	pserialize_read_exit(s);
-
-	return error;

-

-
Remove a frotz, as a writer, and free it once there are no more
-    readers:

-

-
	struct frotz **fp, *f;
-
-	mutex_enter(&frobbotzim.lock);
-	for (fp = &frobbotzim.first; (f = *fp) != NULL; fp = &f->f_next) {
-		if (f->f_... == key) {
-			/*
-			 * Unhook it from the list.  Readers may still
-			 * be traversing the list at this point, so
-			 * the next pointer must remain valid and
-			 * memory must remain allocated.
-			 */
-			*fp = f->f_next;
-			break;
-		}
-	}
-	mutex_exit(&frobbotzim.lock);
-
-	/*
-	 * Wait for all existing readers to complete.  New readers will
-	 * not see f because the list no longer points to it.
-	 */
-	pserialize_perform(frobbotzim.psz);
-
-	/* Now nobody else can be touching f, so it is safe to free.  */
-	if (f != NULL)
-		pool_put(&frotz_pool, f);

-

-

-

-

-
The pserialize is implemented within the
-    file sys/kern/subr_pserialize.c.

-

-

-

-
membar_ops(3), condvar(9),
-    mutex(9), rwlock(9)

-
Hennessy, et al.,
-    Passive serialization in a multitasking
-    environment, US Patent and Trademark Office,
-    US Patent 4809168, February 28,
-    1989.

-

-

-

-
Passive serialization mechanism first appeared in
-    NetBSD 6.0.

-

-

-
-  
-    
-    
-  
-
January 26, 2016NetBSD 10.1

diff --git a/static/netbsd/man9/pslist.9 3.html b/static/netbsd/man9/pslist.9 3.html
deleted file mode 100644
index 9aa95f84..00000000
--- a/static/netbsd/man9/pslist.9 3.html	
+++ /dev/null
@@ -1,386 +0,0 @@
-
-  
-    
-    
-    
-  
-
PSLIST(9)Kernel Developer's ManualPSLIST(9)

-

-

-

-
pslist —
-    pserialize-safe linked lists

-

-

-

-
#include
-    <sys/pslist.h>

-
struct pslist_head head =
-    PSLIST_INITIALIZER;
-  

-  struct pslist_entry entry =
-    PSLIST_ENTRY_INITIALIZER;

-
void
-  

-  PSLIST_INIT(struct
-    pslist_head *head);

-
void
-  

-  PSLIST_DESTROY(struct
-    pslist_head *head);

-
void
-  

-  PSLIST_ENTRY_INIT(TYPE
-    *element, PSLIST_ENTRY
-    NAME);

-
void
-  

-  PSLIST_ENTRY_DESTROY(TYPE
-    *element, PSLIST_ENTRY
-    NAME);

-
void
-  

-  PSLIST_WRITER_INSERT_HEAD(struct
-    pslist_head *head, TYPE
-    *new, PSLIST_ENTRY
-    NAME);

-
void
-  

-  PSLIST_WRITER_INSERT_BEFORE(TYPE
-    *element, TYPE
-    *new, PSLIST_ENTRY
-    NAME);

-
void
-  

-  PSLIST_WRITER_INSERT_AFTER(TYPE
-    *element, TYPE
-    *new, PSLIST_ENTRY
-    NAME);

-
void
-  

-  PSLIST_WRITER_REMOVE(TYPE
-    *element, PSLIST_ENTRY
-    NAME);

-
TYPE *
-  

-  PSLIST_WRITER_FIRST(const
-    struct pslist *head,
-    TYPE,
-    PSLIST_ENTRY NAME);

-
TYPE *
-  

-  PSLIST_WRITER_NEXT(const
-    TYPE *element,
-    TYPE,
-    PSLIST_ENTRY NAME);

-
PSLIST_WRITER_FOREACH(const
-    TYPE *element, const
-    struct pslist_head *head,
-    TYPE,
-    PSLIST_ENTRY NAME);

-
TYPE *
-  

-  PSLIST_READER_FIRST(const
-    struct pslist *head,
-    TYPE,
-    PSLIST_ENTRY NAME);

-
TYPE *
-  

-  PSLIST_READER_NEXT(const
-    TYPE *element,
-    TYPE,
-    PSLIST_ENTRY NAME);

-
PSLIST_READER_FOREACH(const
-    TYPE *element, const
-    struct pslist_head *head,
-    TYPE,
-    PSLIST_ENTRY NAME);

-

-

-

-
The pslist data structure is a linked list
-    like list in queue(3). It is
-    augmented with memory barriers so that any number of readers can safely run
-    in parallel with at most one writer, without needing any interprocessor
-    synchronization such as locks or atomics on the reader side.

-
The head of a linked list is represented by a
-    struct pslist_head object allocated by the caller,
-    e.g. by embedding it in another struct, which should be otherwise treated as
-    opaque. A linked list head must be initialized with
-    PSLIST_INITIALIZER or
-    ()
-    before it may be used. When initialized, a list head represents an empty
-    list. A list should be empty and destroyed with
-    ()
-    before the struct pslist_head object's memory is
-    reused.

-
Each entry in a linked list is represented by a
-    struct pslist_entry object, also opaque, and embedded
-    as a member in a caller-allocated structure called an
-    . A
-    struct pslist_entry object must be initialized with
-    PSLIST_ENTRY_INITIALIZER or
-    ()
-    before it may be used.

-
When initialized, a list entry is
-    unassociated. Inserting an entry associates it with a particular list.
-    Removing it partially disassociates it from that list and prevents new
-    readers from finding it in the list, but allows extant parallel readers to
-    continue reading the next entry. The caller must then wait, e.g. with
-    pserialize_perform(9), for all extant parallel readers to
-    finish, before destroying the list entry with
-    ()
-    and then freeing or reusing its memory.

-

-

-

-
The following operations may be performed on list heads and
-    entries when the caller has exclusive access to them — no parallel
-    writers or readers may have access to the same objects.

-

-  

-  
Constant initializer for a struct pslist_head
-      object.

-  
PSLIST_INIT(head)

-  
Initialize the list headed by head to be empty.

-  
PSLIST_DESTROY(head)

-  
Destroy the list headed by head, which must be
-      empty.
-    
This has an effect only with the
-        DIAGNOSTIC option, so it is not strictly
-        necessary, but it can help to detect bugs early; see
-        KASSERT(9).

-  

-  

-  
Constant initializer for an unassociated struct
-      pslist_entry object.

-  
(element,
-    NAME)

-  
Initialize the struct pslist_entry object
-      element->NAME.

-  
PSLIST_ENTRY_DESTROY(element,
-    NAME)

-  
Destroy the struct pslist_entry object
-      element->NAME.
-      Either element must never have been inserted into a
-      list, or it must have been inserted and removed, and the caller must have
-      waited for all parallel readers to finish reading it first.

-

-

-

-

-
The following operations may be performed on list heads and
-    entries when the caller has exclusive
-    
-    access to them — parallel readers for the same objects are allowed,
-    but no parallel writers.

-

-  
(head,
-    element, NAME)

-  
Insert the element element at the beginning of the
-      list headed by head, before any existing elements in
-      the list.
-    
The object
-        element->NAME
-        must be a struct pslist_entry object which has
-        been initialized but not inserted.

-  

-  
(element,
-    new, NAME)

-  
Insert the element new into a list before the
-      element element.
-    
The object
-        element->NAME
-        must be a struct pslist_entry object which has
-        been inserted into a list. The object
-        new->NAME
-        must be a struct pslist_entry

-  

-  
(element,
-    new, NAME)

-  
Insert the element new into a list after the element
-      element.
-    
The object
-        element->NAME
-        must be a struct pslist_entry object which has
-        been inserted into a list. The object
-        new->NAME
-        must be a struct pslist_entry

-  

-  
(element,
-    NAME)

-  
Remove the element element from the list into which
-      it has been inserted.
-    
The object
-        element->NAME
-        must be a struct pslist_entry object which has
-        been inserted into a list.

-  

-  
(head,
-    type, NAME)

-  
Return a pointer to the first element o of type
-      type with a struct
-      pslist_entry member
-      o->NAME,
-      or NULL if the list is empty.

-  
(element,
-    type, NAME)

-  
Return a pointer to the next element o of type
-      type with a struct
-      pslist_entry member
-      o->NAME
-      after element in a list, or
-      NULL if there are no elements after
-      element.

-  
(element,
-    head, type,
-    NAME)

-  
Loop header for iterating over each element element
-      of type type with struct
-      pslist_entry member
-      element->NAME
-      starting at the list head head.
-    
The caller must not modify the list while iterating over
-      it.

-  

-

-

-

-

-
The following operations may be performed on list heads and
-    entries when the caller is in a passively serialized read section —
-    see pserialize(9).

-

-  
(head,
-    type, NAME)

-  
Return a pointer to the first element o of type
-      type with a struct
-      pslist_entry member
-      o->NAME,
-      or NULL if the list is empty.

-  
(element,
-    type, NAME)

-  
Return a pointer to the next element o of type
-      type with a struct
-      pslist_entry member
-      o->NAME
-      after element in a list, or
-      NULL if there are no elements after
-      element.

-  
(element,
-    head, type,
-    NAME)

-  
Loop header for iterating over each element element
-      of type type with struct
-      pslist_entry member
-      element->NAME
-      starting at the list head head.

-

-

-

-

-
Example frotz structure and global state:

-

-
	struct frotz {
-		uint64_t		f_key;
-		uint64_t		f_datum;
-		struct pslist_entry	f_entry;
-	};
-
-	static struct {
-		kmutex_t		lock;
-		pserialize_t		psz;
-		struct pslist_head	list;
-		struct pool		pool;
-	} frobnitzem __cacheline_aligned;

-

-
Initialize the global state:

-

-
	mutex_init(&frobnitzem.lock, MUTEX_DEFAULT, IPL_NONE);
-	frobnitzem.psz = pserialize_create();
-	PSLIST_INIT(&frobnitzem.list);
-	pool_init(&frobnitzem.pool, sizeof(struct frotz), ...);

-

-
Create and publish a frotz:

-

-
	uint64_t key = ...;
-	uint64_t datum = ...;
-
-	struct frotz *f = pool_get(&frobnitzem.pool, PR_WAITOK);
-
-	/* Initialize f.  */
-	f->f_key = key;
-	f->f_datum = datum;
-	PSLIST_ENTRY_INIT(f, f_entry);
-
-	/* Publish it.  */
-	mutex_enter(&frobnitzem.lock);
-	PSLIST_WRITER_INSERT_HEAD(&frobnitzem.list, f, f_entry);
-	mutex_exit(&frobnitzem.lock);

-

-
Look up a frotz and return its associated datum:

-

-
	uint64_t key = ...;
-	struct frotz *f;
-	int error = ENOENT;
-	int s;
-
-	s = pserialize_read_enter();
-	PSLIST_READER_FOREACH(f, &frobnitzem.list, struct frotz, f_entry) {
-		if (f->f_key == key) {
-			*datump = f->f_datum;
-			error = 0;
-			break;
-		}
-	}
-	pserialize_read_exit(s);
-	return error;

-

-
Remove a frotz and wait for readers to finish using it before
-    reusing the memory allocated for it:

-

-
	struct frotz *f = ...;
-
-	mutex_enter(&frobnitzem.lock);
-	PSLIST_WRITER_REMOVE(f, f_entry);
-	mutex_exit(&frobnitzem.lock);
-
-	pserialize_perform(&frobnitzem.psz);
-
-	PSLIST_ENTRY_DESTROY(f, f_entry);
-	pool_put(&frobnitzem.pool, f);

-

-

-

-

-
The pslist data structure is implemented
-    by static inlines and macros in
-  sys/sys/pslist.h.

-

-

-

-
queue(3), pserialize(9),
-    psref(9)

-

-

-

-
The pslist data structure first appeared
-    in NetBSD 8.0.

-

-

-

-
Taylor R Campbell
-    <riastradh@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
July 7, 2016NetBSD 10.1

diff --git a/static/netbsd/man9/ras.9 3.html b/static/netbsd/man9/ras.9 3.html
deleted file mode 100644
index defc6050..00000000
--- a/static/netbsd/man9/ras.9 3.html	
+++ /dev/null
@@ -1,121 +0,0 @@
-
-  
-    
-    
-    
-  
-
RAS(9)Kernel Developer's ManualRAS(9)

-

-

-

-
ras_lookup,
-    ras_fork, ras_purgeall
-    — restartable atomic sequences

-

-

-

-
#include
-    <sys/types.h>
-  

-  #include <sys/proc.h>
-  

-  #include <sys/ras.h>

-
void *
-  

-  ras_lookup(struct
-    proc *p, void
-    *addr);

-
int
-  

-  ras_fork(struct
-    proc *p1, struct proc
-    *p2);

-
int
-  

-  ras_purgeall(struct
-    proc *p);

-

-

-

-
Restartable atomic sequences are user code sequences which are
-    guaranteed to execute without preemption. This property is assured by
-    checking the set of restartable atomic sequences registered for a process
-    during cpu_switchto(9). If a process is found to have been
-    preempted during a restartable sequence, then its execution is rolled-back
-    to the start of the sequence by resetting its program counter saved in its
-    process control block (PCB).

-
The RAS functionality is provided by a combination of the
-    machine-independent routines discussed in this page and a machine-dependent
-    component in cpu_switchto(9). A port which supports
-    restartable atomic sequences will define __HAVE_RAS
-    in <machine/types.h> for
-    machine-independent code to conditionally provide RAS support.

-
A complicated side-effect of restartable atomic sequences is their
-    interaction with the machine-dependent ptrace(2) support.
-    Specifically, single-step traps and/or the emulation of single-stepping must
-    carefully consider the effect on restartable atomic sequences. A general
-    solution is to ignore these traps or disable them within restartable atomic
-    sequences.

-

-

-

-
The functions which operate on restartable atomic sequences
-  are:

-

-  
(p,
-    addr)

-  
This function searches the registered restartable atomic sequences for
-      process p which contain the user address
-      addr. If the address addr is
-      found within a RAS, then the restart address of the RAS is returned,
-      otherwise -1 is returned.

-  
(p1,
-    p2)

-  
This function is used to copy all registered restartable atomic sequences
-      for process p1 to process p2.
-      It is primarily called from fork1(9) when the sequences
-      are inherited from the parent by the child.

-  
(p)

-  
This function is used to remove all registered restartable atomic
-      sequences for process p. It is primarily used to
-      remove all registered restartable atomic sequences for a process during
-      exec(3) and by rasctl(2).

-

-

-

-

-
The RAS framework itself is implemented within the file
-    sys/kern/kern_ras.c. Data structures and function
-    prototypes for the framework are located in
-    <sys/ras.h>.
-    Machine-dependent portions are implemented within
-    cpu_switchto(9) in the machine-dependent file
-    sys/arch/<arch>/<arch>/locore.S.

-

-

-

-
rasctl(2), cpu_switchto(9),
-    fork1(9)

-
Gregory McGarry,
-    An Implementation of User-level Restartable Atomic
-    Sequences on the NetBSD Operating System, Proceedings
-    of the FREENIX Track: 2003 USENIX Annual Technical Conference,
-    USENIX Association,
-    http://www.usenix.org/publications/library/proceedings/usenix03/tech/freenix03/full_papers/mcgarry/mcgarry.pdf,
-    311-322, June 9-14,
-    2003.

-

-

-

-
The RAS functionality first appeared in NetBSD
-    2.0.

-

-

-
-  
-    
-    
-  
-
April 17, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/roundup.9 3.html b/static/netbsd/man9/roundup.9 3.html
deleted file mode 100644
index a0cfeb99..00000000
--- a/static/netbsd/man9/roundup.9 3.html	
+++ /dev/null
@@ -1,100 +0,0 @@
-
-  
-    
-    
-    
-  
-
ROUNDUP(9)Kernel Developer's ManualROUNDUP(9)

-

-

-

-
roundup — macros
-    for counting and rounding

-

-

-

-
#include
-    <sys/param.h>

-
size
-  

-  howmany(x,
-    size);

-
size
-  

-  roundup(x,
-    size);

-
size
-  

-  rounddown(x,
-    size);

-
size
-  

-  roundup2(x,
-    size);

-
size
-  

-  rounddown2(x,
-    size);

-
int
-  

-  powerof2(x);

-

-

-

-
The
-    ()
-    and
-    ()
-    macros return an integer from rounding x up and down,
-    respectively, to the next size. The
-    ()
-    macro in turn reveals how many times size fits into
-    x, rounding the residual up.

-
The
-    ()
-    and
-    ()
-    macros also round up and down, respectively, but with the assumption that
-    size is a power of two. If x is
-    indeed a power of two,
-    ()
-    return 1.

-

-

-

-
The return value is an integer from the respective operation. If
-    x is 0, all macros except
-    powerof2() return 0. The behavior is undefined if
-    size is 0.

-

-

-

-
The following example rounds the variable rx
-    to a 32-bit boundary:

-

-
uint16_t rx;
-
-...
-
-rx = roundup2(rx, sizeof(uint32_t));

-

-

-

-

-
ilog2(3), param(3),
-    imax(9)

-

-

-

-
All described macros make no assumptions about the type of the
-    parameters. These are implicitly assumed to be unsigned integers.

-

-

-
-  
-    
-    
-  
-
October 2, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/rwlock.9 3.html b/static/netbsd/man9/rwlock.9 3.html
deleted file mode 100644
index 239ed9ad..00000000
--- a/static/netbsd/man9/rwlock.9 3.html	
+++ /dev/null
@@ -1,256 +0,0 @@
-
-  
-    
-    
-    
-  
-
RWLOCK(9)Kernel Developer's ManualRWLOCK(9)

-

-

-

-
rw, rw_init,
-    rw_destroy, rw_enter,
-    rw_exit, rw_tryenter,
-    rw_tryupgrade, rw_downgrade,
-    rw_read_held, rw_write_held,
-    rw_lock_held, rw_lock_op
-    — reader / writer lock primitives

-

-

-

-
#include
-    <sys/rwlock.h>

-
void
-  

-  rw_init(krwlock_t
-    *rw);

-
void
-  

-  rw_destroy(krwlock_t
-    *rw);

-
void
-  

-  rw_enter(krwlock_t
-    *rw, const krw_t
-    op);

-
void
-  

-  rw_exit(krwlock_t
-    *rw);

-
int
-  

-  rw_tryenter(krwlock_t
-    *rw, const krw_t
-    op);

-
int
-  

-  rw_tryupgrade(krwlock_t
-    *rw);

-
void
-  

-  rw_downgrade(krwlock_t
-    *rw);

-
int
-  

-  rw_read_held(krwlock_t
-    *rw);

-
int
-  

-  rw_write_held(krwlock_t
-    *rw);

-
int
-  

-  rw_lock_held(krwlock_t
-    *rw);

-
krw_t
-  

-  rw_lock_op(krwlock_t
-    *rw);

-

-  

-  options DIAGNOSTIC
-  

-  options LOCKDEBUG

-

-

-

-
Reader / writer locks (RW locks) are used in the kernel to
-    synchronize access to an object among LWPs (lightweight processes) and soft
-    interrupt handlers.

-
In addition to the capabilities provided by mutexes, RW locks
-    distinguish between read (shared) and write (exclusive) access.

-
RW locks are in one of three distinct states at any given
-  time:

-

-  

-  
The lock is not held.

-  

-  
The lock holders intend to read the protected object. Multiple callers may
-      hold a RW lock with “read intent” simultaneously.

-  

-  
The lock holder intends to update the protected object. Only one caller
-      may hold a RW lock with “write intent”.

-

-
The krwlock_t type provides storage for the
-    RW lock object. This should be treated as an opaque object and not examined
-    directly by consumers.

-
Note that these interfaces must not be used from a hardware
-    interrupt handler.

-

-

-

-

-  
options DIAGNOSTIC

-  

-    
Kernels compiled with the DIAGNOSTIC
-        option perform basic sanity checks on RW lock operations.

-  

-  
options LOCKDEBUG

-  

-    
Kernels compiled with the LOCKDEBUG
-        option perform potentially CPU intensive sanity checks on RW lock
-        operations.

-  

-

-

-

-

-

-  
(rw)

-  

-    
Initialize a lock for use. No other operations can be
-        performed on the lock until it has been initialized.

-  

-  
(rw)

-  

-    
Release resources used by a lock. The lock may not be used
-        after it has been destroyed.

-  

-  
(rw,
-    op)

-  

-    
If RW_READER is specified as the
-        argument to op, acquire a read lock. The caller
-        may block and will not return until the hold is acquired. Callers must
-        not recursively acquire read locks.

-    
If RW_WRITER is specified, acquire a
-        write lock. If the lock is already held, the caller will block and not
-        return until the hold is acquired.

-    
RW locks and other types of locks must always be acquired in a
-        consistent order with respect to each other. Otherwise, the potential
-        for system deadlock exists.

-  

-  
(rw)

-  

-    
Release a lock. The lock must have been previously acquired by
-        the caller.

-  

-  
(rw,
-    op)

-  

-    
Try to acquire a lock, but do not block if the lock is already
-        held. If the lock is acquired successfully, return non-zero. Otherwise,
-        return zero.

-    
Valid arguments to op are
-        RW_READER or
-      RW_WRITER.

-  

-  
(rw)

-  

-    
Try to upgrade a lock from one read hold to a write hold. If
-        the lock is upgraded successfully, returns non-zero. Otherwise, returns
-        zero.

-  

-  
(rw)

-  

-    
Downgrade a lock from a write hold to a read hold.

-  

-  
(rw)

-  

-    
Return non-zero if write lock is held by current lwp.
-        Otherwise, return zero.

-  

-  
(rw)

-  

-    
Returns non-zero if read lock is held by any lwp. Otherwise,
-        return zero.

-  

-  
(rw)

-  

-    
Returns non-zero if either read or write lock is held by any
-        lwp. Otherwise, return zero.

-    
(),
-        rw_read_held(), and
-        rw_lock_held() should not generally be used to
-        make locking decisions at run time: they are provided for diagnostic
-        purposes, for example making assertions.

-    
Negative assertions (lock not held)
-        should not be made due to atomicity issues, excepting
-        (),
-        which can safely be used to assert that a write lock is NOT held by the
-        current LWP.

-  

-  
(rw)

-  

-    
For a lock that is known to be held by the calling LWP, return
-        either RW_READER or
-        RW_WRITER to denote the type of hold. This is
-        useful when dropping and later re-acquiring a lock, if the type of hold
-        is not already known.

-  

-

-

-

-

-
RW locks are subject to high cache contention on multiprocessor
-    systems, and scale poorly when the write:read ratio is not strongly in
-    favour of readers. Ideally, RW locks should only be used in settings when
-    the following three conditions are met:

-
    
-  
  • The data object(s) protected by the RW lock are read much more frequently
-      than written.
    • 
-  
  • The read-side hold time for the RW lock is long (in the order of thousands
-      of processor clock cycles).
    • 
-  
  • Strong synchronization semantics are required: there is no scope for
-      lockless, lazy or optimistic synchronization.
    • 
-

-
Generally speaking, it is better to organise code paths and/or
-    data flows such that fewer and weaker synchronization points are required to
-    ensure correct operation.

-

-

-

-
The core of the RW lock implementation is in
-    sys/kern/kern_rwlock.c.

-
The header file sys/sys/rwlock.h describes
-    the public interface, and interfaces that machine-dependent code must
-    provide to support RW locks.

-

-

-

-
membar_ops(3), lockstat(8),
-    condvar(9), mutex(9)

-
Jim Mauro and
-    Richard McDougall, Solaris
-    Internals: Core Kernel Architecture, Prentice
-    Hall, 2001, ISBN
-    0-13-022496-0.

-

-

-

-
The RW lock primitives first appeared in NetBSD
-    5.0.

-

-

-
-  
-    
-    
-  
-
February 22, 2020NetBSD 10.1

diff --git a/static/netbsd/man9/scanc.9 3.html b/static/netbsd/man9/scanc.9 3.html
deleted file mode 100644
index 89cfb775..00000000
--- a/static/netbsd/man9/scanc.9 3.html	
+++ /dev/null
@@ -1,55 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCANC(9)Kernel Developer's ManualSCANC(9)

-

-

-

-
scanc — use byte
-    string as lookup table index

-

-

-

-
#include
-    <lib/libkern/libkern.h>

-
int
-  

-  scanc(u_int
-    size, const u_char
-    *cp, const u_char
-    table[], int
-  mask);

-

-

-

-
The
-    ()
-    function scans the byte string cp, whose length is
-    size. A character in the string is used as an index in
-    the 256-byte table. If a bitwise-AND of the byte from
-    the table and mask isn't zero or the string is
-    exhausted, the scan stops.

-

-

-

-
The scanc() function returns the length of
-    the rest of the string, including the character which made the scan stop. If
-    the scanc() function exhausted the string, it
-    returns 0.

-

-

-

-
The scanc() function emulates a VAX
-    instruction with the same name.

-

-

-
-  
-    
-    
-  
-
April 24, 2013NetBSD 10.1

diff --git a/static/netbsd/man9/sched_4bsd.9 3.html b/static/netbsd/man9/sched_4bsd.9 3.html
deleted file mode 100644
index d08d4b85..00000000
--- a/static/netbsd/man9/sched_4bsd.9 3.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
SCHED_4BSD(9)Kernel Developer's ManualSCHED_4BSD(9)

-

-

-

-
sched_4bsd — The
-    4.4BSD thread scheduler

-

-

-

-
#include
-    <sys/sched.h>

-
void
-  

-  resetpriority(lwp_t
-    *l);

-
void
-  

-  sched_tick(struct
-    cpu_info *ci);

-
void
-  

-  sched_schedclock(lwp_t
-    *l);

-
void
-  

-  sched_pstats_hook(struct
-    proc *p, int
-    minslp);

-
void
-  

-  sched_setrunnable(lwp_t
-    *l);

-
void
-  

-  updatepri(lwp_t
-    *l);

-

-

-

-
The traditional 4.4BSD scheduler employs a
-    “multilevel feedback queues” algorithm, favouring interactive,
-    short-running threads to CPU-bound ones.

-
()
-    recomputes the priority of a thread running in user mode. If the resulting
-    priority is higher than that of the current thread, a reschedule is
-    arranged.

-
()
-    gets called from hardclock(9) every 100ms to force a
-    switch between equal priority threads.

-
The priority of the current thread is
-    adjusted through
-    ().
-    The priority of a thread gets worse as it accumulates CPU time.

-
()
-    gets called from
-    ()
-    every Hz ticks in order to recompute the priorities of all threads.

-
()
-    checks if an LWP has slept for more than one second. If so, its priority is
-    updated by
-    ().

-

-

-

-
To determine the scheduler currently in use

-

-
$ sysctl kern.sched.name
-kern.sched.name = 4.4BSD

-

-

-

-

-
The 4.4BSD scheduler subsystem is
-    implemented within the file
-  sys/kern/sched_4bsd.c.

-

-

-

-
csf(9), hardclock(9),
-    mi_switch(9), sched_m2(9),
-    userret(9)

-
Marshall Kirk McKusick,
-    Keith Bostic, Michael J.
-    Karels, and John S. Quarterman,
-    The Design and Implementation of the 4.4BSD Operating
-    System, Addison Wesley,
-    1996.

-

-

-
-  
-    
-    
-  
-
April 9, 2019NetBSD 10.1

diff --git a/static/netbsd/man9/secmodel_extensions.9 3.html b/static/netbsd/man9/secmodel_extensions.9 3.html
deleted file mode 100644
index e5aa5184..00000000
--- a/static/netbsd/man9/secmodel_extensions.9 3.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
SECMODEL_EXTENSIONS(9)Kernel Developer's ManualSECMODEL_EXTENSIONS(9)

-

-

-

-
secmodel_extensions —
-    extensions security model

-

-

-

-
secmodel_extensions implements extensions
-    to the traditional security model based on the original
-    4.4BSD. They can be used to grant additional
-    privileges to ordinary users, or enable specific security measures like
-    curtain mode.

-
The extensions are described below.

-

-

-

-
When enabled, all returned objects will be filtered according to
-    the user-id requesting information about them, preventing users from
-    accessing objects they do not own.

-
It affects the output of many commands, including
-    fstat(1), netstat(1),
-    ps(1), sockstat(1), and
-    w(1).

-
This extension is enabled by setting
-    security.models.extensions.curtain or
-    security.curtain sysctl(7) to a
-    non-zero value.

-
It can be enabled at any time, but cannot be disabled anymore when
-    the securelevel of the system is above 0.

-

-

-

-
When enabled, it allows file-systems to be mounted by an ordinary
-    user who owns the point node and has at least read
-    access to the special device
-    mount(8) arguments. Note that the
-    nosuid and nodev flags must
-    be given for non-superuser mounts.

-
This extension is enabled by setting
-    security.models.extensions.usermount or
-    vfs.generic.usermount sysctl(7) to
-    a non-zero value.

-
It can be disabled at any time, but cannot be enabled anymore when
-    the securelevel of the system is above 0.

-

-

-

-
When enabled, an ordinary user is allowed to control the CPU
-    affinity(3) of the processes and threads they own.

-
This extension is enabled by setting
-    security.models.extensions.user_set_cpu_affinity
-    sysctl(7) to a non-zero value.

-
It can be disabled at any time, but cannot be enabled anymore when
-    the securelevel of the system is above 0.

-

-

-

-
Prevent hardlinks to files that the user does not own or has group
-    access to.

-
To enable user ownership checks, set the
-    sysctl(7) variable
-    security.models.extensions.hardlink_check_uid to a
-    non-zero value.

-
To enable group membership checks, set the
-    sysctl(7) variable
-    security.models.extensions.hardlink_check_gid to a
-    non-zero value.

-
These variables can be enabled anytime, but cannot be disabled
-    anymore when the securelevel of the system is above 0.

-

-

-

-
affinity(3), sched(3),
-    sysctl(7), kauth(9),
-    secmodel(9), secmodel_bsd44(9),
-    secmodel_securelevel(9),
-    secmodel_suser(9)

-

-

-

-
Elad Efrat
-    <elad@NetBSD.org>

-

-

-
-  
-    
-    
-  
-
March 27, 2022NetBSD 10.1

diff --git a/static/netbsd/man9/signal.9 3.html b/static/netbsd/man9/signal.9 3.html
deleted file mode 100644
index 6cfaf949..00000000
--- a/static/netbsd/man9/signal.9 3.html	
+++ /dev/null
@@ -1,482 +0,0 @@
-
-  
-    
-    
-    
-  
-
SIGNAL(9)Kernel Developer's ManualSIGNAL(9)

-

-

-

-
signal, siginit,
-    sigactsinit, sigactsunshare,
-    sigactsfree, execsigs,
-    sigaction1, sigprocmask1,
-    sigpending1, sigsuspend1,
-    sigaltstack1, pgsignal,
-    kpgsignal, psignal,
-    kpsignal, issignal,
-    postsig, killproc,
-    sigexit, trapsignal,
-    sendsig, sigcode,
-    sigtramp — software signal
-    facilities

-

-

-

-
#include
-    <sys/signal.h>
-  

-  #include <sys/signalvar.h>

-
void
-  

-  siginit(struct
-    proc *p);

-
void
-  

-  sigactsinit(struct
-    proc *pp, int
-    share);

-
void
-  

-  sigactsunshare(struct
-    proc *p);

-
void
-  

-  sigactsfree(struct
-    proc *p);

-
void
-  

-  execsigs(struct
-    proc *p);

-
int
-  

-  sigaction1(struct
-    lwp *l, int signum,
-    const struct sigaction
-    *nsa, struct sigaction
-    *osa, void *tramp,
-    int vers);

-
int
-  

-  sigprocmask1(struct
-    lwp *l, int how,
-    const sigset_t *nss,
-    sigset_t *oss);

-
void
-  

-  sigpending1(struct
-    lwp *l, sigset_t
-    *ss);

-
int
-  

-  sigsuspend1(struct
-    lwp *l, const sigset_t
-    *ss);

-
int
-  

-  sigaltstack1(struct
-    lwp *l, const struct
-    sigaltstack *nss, struct
-    sigaltstack *oss);

-
void
-  

-  pgsignal(struct
-    pgrp *pgrp, int
-    signum, int
-    checkctty);

-
void
-  

-  kpgsignal(struct
-    pgrp *pgrp, ksiginfo_t
-    *ks, void *data,
-    int checkctty);

-
void
-  

-  psignal(struct
-    proc *p, int
-    signum);

-
void
-  

-  kpsignal(struct
-    proc *p, ksiginfo_t
-    *ks, void
-  *data);

-
int
-  

-  issignal(struct
-    lwp *l);

-
void
-  

-  postsig(int
-    signum);

-
void
-  

-  killproc(struct
-    proc *p, const char
-    *why);

-
void
-  

-  sigexit(struct
-    lwp *l, int
-    signum);

-
void
-  

-  trapsignal(struct
-    lwp *l, const ksiginfo_t
-    *ks);

-
void
-  

-  sendsig(const
-    ksiginfo_t *ks, const
-    sigset_t *mask);

-

-

-

-
The system defines a set of signals that may be delivered to a
-    process. These functions implement the kernel portion of the signal
-    facility.

-
Signal numbers used throughout the kernel signal facilities should
-    always be within the range of [1-NSIG].

-
Most of the kernel's signal infrastructure is implemented in
-    machine-independent code. Machine-dependent code provides support for
-    invoking a process's signal handler, restoring context when the signal
-    handler returns, generating signals when hardware traps occur, triggering
-    the delivery of signals when a process is about to return from the kernel to
-    userspace.

-
The signal state for a process is contained in
-    struct sigctx. This includes the list of signals with
-    delivery pending, information about the signal handler stack, the signal
-    mask, and the address of the signal trampoline.

-
The registered signal handlers for a process are recorded in
-    struct sigacts. This structure may be shared by
-    multiple processes.

-
The kernel's signal facilities are implemented by the following
-    functions:

-

-  
(p)

-  

-    
This function initializes the signal state of
-        proc0 to the system default. This signal state is
-        then inherited by init(8) when it is started by the
-        kernel.

-  

-  
(pp,
-    share)

-  

-    
This function creates an initial struct
-        sigacts for the process pp. If the
-        share argument is non-zero, then
-        pp shares the struct sigacts
-        by holding a reference. Otherwise, pp receives a
-        new struct sigacts which is copied from the
-        parent.

-  

-  
(p)

-  

-    
This function causes the process p to no
-        longer share its struct sigacts The current state
-        of the signal actions is maintained in the new copy.

-  

-  
(p)

-  

-    
This function decrements the reference count on the
-        struct sigacts of process p.
-        If the reference count reaches zero, the struct
-        sigacts is freed.

-  

-  
(p)

-  

-    
This function is used to reset the signal state of the process
-        p to the system defaults when the process execs a
-        new program image.

-  

-  
(l,
-    signum, nsa,
-    osa, tramp,
-    vers)

-  

-    
This function implements the
-        sigaction(2) system call. The
-        tramp and vers arguments
-        provide support for userspace signal trampolines. Trampoline version 0
-        is reserved for the legacy kernel-provided signal trampoline;
-        tramp must be NULL in this
-        case. Otherwise, vers specifies the ABI of the
-        trampoline specified by tramp. The signal
-        trampoline ABI is machine-dependent, and must be coordinated with the
-        ()
-        function.

-  

-  
(l,
-    how, nss,
-    oss)

-  

-    
This function implements the sigprocmask(2)
-        system call.

-  

-  
(l,
-    ss)

-  

-    
This function implements the sigpending(2)
-        system call.

-  

-  
(l,
-    ss)

-  

-    
This function implements the sigsuspend(2)
-        system call.

-  

-  
(l,
-    nss, oss)

-  

-    
This function implements the sigaltstack(2)
-        system call.

-  

-  
(pgrp,
-    signum, checkctty)

-  

-    
This is a wrapper function for
-        ()
-        which is described below.

-  

-  
kpgsignal(pgrp,
-    ks, data,
-    checkctty)

-  

-    
Schedule the signal
-        ks->ksi_signo to be delivered to all members of
-        the process group pgrp. If
-        checkctty is non-zero, the signal is only sent to
-        processes which have a controlling terminal. The
-        data argument and the complete signal scheduling
-        semantics are described in the
-        ()
-        function below.

-  

-  
(l,
-    ks)

-  

-    
Sends the signal ks->ksi_signo caused
-        by a hardware trap to the current process.

-  

-  
(p,
-    signum)

-  

-    
This is a wrapper function for
-        ()
-        which is described below.

-  

-  
kpsignal(p,
-    ks, data)

-  

-    
Schedule the signal ks->ksi_signo to
-        be delivered to the process p. The
-        data argument, if not
-        NULL, points to the file descriptor data that
-        caused the signal to be generated in the SIGIO
-        case.

-    
With a few exceptions noted below, the target
-        process signal disposition is updated and is marked as runnable, so
-        further handling of the signal is done in the context of the target
-        process after a context switch; see
-        ()
-        below. Note that kpsignal() does not by itself
-        cause a context switch to happen.

-    
The target process is not marked as runnable in the following
-        cases:

-    
    
-      
  • The target process is sleeping uninterruptibly. The signal will be
-          noticed when the process returns from the system call or trap.
    • 
-      
  • The target process is currently ignoring the signal.
    • 
-      
  • If a stop signal is sent to a sleeping process that takes the default
-          action (see sigaction(2)), the process is stopped
-          without awakening it.
    • 
-      
  • SIGCONT restarts a stopped process (or puts them back to sleep)
-          regardless of the signal action (e.g., blocked or ignored).
    • 
-    

-    
If the target process is being traced,
-        ()
-        behaves as if the target process were taking the default action for
-        signum. This allows the tracing process to be
-        notified of the signal.

-  

-  
issignal(l)

-  

-    
This function determines which signal, if any, is to be posted
-        to the current process. A signal is to be posted if:

-    
    
-      
  • The signal has a handler provided by the program image.
    • 
-      
  • The signal should cause the process to dump core and/or
-        terminate.
    • 
-      
  • The signal should interrupt the current system call.
    • 
-    

-    
Signals which cause the process to be stopped
-        are handled within
-        ()
-        directly.

-    
()
-        should be called by machine-dependent code when returning to userspace
-        from a system call or other trap or interrupt by using the following
-        code:

-    

-    
while (signum = CURSIG(curproc))
-	postsig(signum);

-    

-  

-  
(signum)

-  

-    
The
-        ()
-        function is used to invoke the action for the signal
-        signum in the current process. If the default
-        action of a signal is to terminate the process, and the signal does not
-        have a registered handler, the process exits using
-        sigexit(), dumping a core image if
-      necessary.

-  

-  
(p,
-    why)

-  

-    
This function sends a SIGKILL signal to the specified process.
-        The message provided by why is sent to the system
-        log and is also displayed on the process's controlling terminal.

-  

-  
(l,
-    signum)

-  

-    
This function forces the current process to exit with the
-        signal signum, generating a core file if
-        appropriate. No checks are made for masked or caught signals; the
-        process always exits.

-  

-  
(ks,
-    mask)

-  

-    
This function is provided by machine-dependent
-        code, and is used to invoke a signal handler for the current process.
-        ()
-        must prepare the registers and stack of the current process to invoke
-        the signal handler stored in the process's struct
-        sigacts. This may include switching to an alternate signal stack
-        specified by the process. The previous register, stack, and signal state
-        are stored in a ucontext_t, which is then copied
-        out to the user's stack.

-    
The registers and stack must be set up to invoke the signal
-        handler as follows:

-    

-    
(*handler)(int signum, siginfo_t *info, void *ctx)

-    

-    
where signum is the signal number,
-        info contains additional signal specific
-        information when SA_SIGINFO is specified when
-        setting up the signal handler. ctx is the pointer
-        to ucontext_t on the user's stack. The registers
-        and stack must also arrange for the signal handler to return to the
-        signal trampoline. The trampoline is then used to return to the code
-        which was executing when the signal was delivered using the
-        setcontext(2) system call.

-    
For performance reasons, it is recommended that
-        ()
-        arrange for the signal handler to be invoked directly on architectures
-        where it is convenient to do so. In this case, the trampoline is used
-        only for the signal return path. If it is not feasible to directly
-        invoke the signal handler, the trampoline is also used to invoke the
-        handler, performing any final set up that was not possible for
-        sendsig() to perform.

-    
()
-        must invoke the signal trampoline with the correct ABI. The ABI of the
-        signal trampoline is specified on a per-signal basis in the
-        ()
-        structure for the process. Trampoline version 0 is reserved for the
-        legacy kernel-provided, on-stack signal trampoline. All other trampoline
-        versions indicate a specific trampoline ABI. This ABI is coordinated
-        with machine-dependent code in the system C library.

-  

-

-

-

-
The signal trampoline is a special piece of code which provides
-    support for invoking the signal handlers for a process. The trampoline is
-    used to return from the signal handler back to the code which was executing
-    when the signal was delivered, and is also used to invoke the handler itself
-    on architectures where it is not feasible to have the kernel invoke the
-    handler directly.

-
In traditional UNIX systems, the signal
-    trampoline, also referred to as the “sigcode”, is provided by
-    the kernel and copied to the top of the user's stack when a new process is
-    created or a new program image is exec'd. Starting in
-    NetBSD 2.0, the signal trampoline is provided by the
-    system C library. This allows for more flexibility when the signal facility
-    is extended, makes dealing with signals easier in debuggers, such as
-    gdb(1), and may also enhance system security by allowing
-    the kernel to disallow execution of code on the stack.

-
The signal trampoline is specified on a per-signal basis. The
-    correct trampoline is selected automatically by the C library when a signal
-    handler is registered by a process.

-
Signal trampolines have a special naming convention which enables
-    debuggers to determine the characteristics of the signal handler and its
-    arguments. Trampoline functions are named like so:

-

-
__sigtramp_<flavor>_<version>

-

-
where:

-

-  
⟨flavor⟩

-  
The flavor of the signal handler. The following flavors are valid:
-    

-      
sigcontext

-      
Specifies a traditional BSD-style (deprecated) signal handler with the
-          following signature:
-        

-        
void (*handler)(int signum,
-	int code,
-	struct sigcontext *scp);

-        

-      

-      
siginfo

-      
Specifies a POSIX-style signal handler with the following signature:
-        

-        
void (*handler)(int signum,
-	siginfo_t *si,
-	void *uc);

-        

-        
Note: sigcontext style signal handlers are deprecated, and
-            retained only for compatibility with older binaries.

-      

-    

-  

-  
⟨version⟩

-  
Specifies the ABI version of the signal trampoline. The trampoline ABI is
-      coordinated with the machine-dependent kernel
-      ()
-      function. The trampoline version needs to be unique even across different
-      trampoline flavors, in order to simplify trampoline selection in the
-      kernel.

-

-
The following is an example if a signal trampoline name which
-    indicates that the trampoline is used for traditional BSD-style signal
-    handlers and implements version 1 of the signal trampoline ABI:

-

-
__sigtramp_sigcontext_1

-

-
The current signal trampoline is:

-

-
__sigtramp_siginfo_2

-

-

-

-

-

-
sigaction(2), signal(7),
-    condvar(9)

-

-

-
-  
-    
-    
-  
-
April 29, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/sockopt.9 3.html b/static/netbsd/man9/sockopt.9 3.html
deleted file mode 100644
index 75fa4080..00000000
--- a/static/netbsd/man9/sockopt.9 3.html	
+++ /dev/null
@@ -1,157 +0,0 @@
-
-  
-    
-    
-    
-  
-
SOCKOPT(9)Kernel Developer's ManualSOCKOPT(9)

-

-

-

-
sockopt_init,
-    sockopt_destroy,
-    sockopt_get, sockopt_getint,
-    sockopt_set, sockopt_setint
-    — socket options handling

-

-

-

-
#include
-    <sys/socketvar.h>

-
void
-  

-  sockopt_init(struct
-    sockopt *sopt, int
-    level, int name,
-    size_t size);

-
void
-  

-  sockopt_destroy(struct
-    sockopt *sopt);

-
int
-  

-  sockopt_get(struct
-    sockopt *sopt, void
-    *value, size_t
-    size);

-
int
-  

-  sockopt_getint(struct
-    sockopt *sopt, int
-    *value);

-
int
-  

-  sockopt_set(struct
-    sockopt *sopt, const void
-    *value, size_t
-    size);

-
int
-  

-  sockopt_setint(struct
-    sockopt *sopt, int
-    value);

-

-

-

-
The sockopt structure is used to pass a
-    socket option and associated value:

-

-
struct sockopt {
-	int		sopt_level;		/* option level */
-	int		sopt_name;		/* option name */
-	size_t		sopt_size;		/* data length */
-	size_t		sopt_retsize;		/* returned data length */
-	void *		sopt_data;		/* data pointer */
-	uint8_t		sopt_buf[sizeof(int)];	/* internal storage */
-};

-

-
The internal storage is used for the common case of values up to
-    integer size so that memory allocation is not required and sopt_data will
-    point to this in that case.

-
Rather than provide accessor functions, the
-    sockopt structure is public and the contents are
-    expected to be internally consistent, but the normal practice would be to
-    use the appropriate methods for storage and retrieval of values where a
-    known datatype is expected, as the size will be verified.

-
Note: a sockopt structure may only be used for a single
-    level/name/size combination. If the structure is to be re-used, it must be
-    destroyed and re-initialized with the new values.

-

-

-

-

-  
options DIAGNOSTIC

-  
Kernels compiled with the DIAGNOSTIC option will
-      perform basic sanity checks on socket options operations.

-

-

-

-

-

-  
(sopt,
-    level, name,
-    size)

-  
Initialise sockopt storage. If size is given,
-      sockopt_init() will arrange for sopt_data to point
-      to a buffer of size bytes for the sockopt value.
-      Where memory needs to be allocated to satisfy this,
-      sockopt_init() may sleep.

-  
(sopt)

-  
Destroy sockopt storage, releasing any allocated memory.

-  
(sopt,
-    value, size)

-  
Copy out sockopt value. Will return EINVAL if an
-      incorrect data size is given.

-  
(sopt,
-    value)

-  
Common case of get sockopt integer value. Will return
-      EINVAL if sockopt does not contain an integer
-      sized value.

-  
sockopt_set(sopt,
-    value, size)

-  
Copy in sockopt value. The sockopt structure must contain a data field of
-      size bytes or be previously unset, in which case a
-      data buffer may be allocated using kmem_alloc(9) with
-      the KM_NOSLEEP flag which may cause
-      sockopt_set() to return
-      ENOMEM.
-    
Note: If you need to use
-        ()
-        in a context where memory allocation may be required and you do not wish
-        to contemplate failure, the sockopt structure can be initialised in a
-        more suitable context using sockopt_init() which
-        will not fail.

-  

-  
(sopt,
-    value)

-  
Common case of set sockopt integer value. The sockopt structure must
-      contain an int sized data field or be previously unset, in which case the
-      data pointer will be set to the internal storage.

-

-

-

-

-
The function prototypes and sockopt structure are defined in the
-    sys/sys/socketvar.h header file, and the socket
-    options implementation is in
-  sys/kern/uipc_socket.c.

-

-

-

-
errno(2), kmem(9)

-

-

-

-
The socket options KPI was inspired by a similar KPI in
-    FreeBSD and first appeared in
-    NetBSD 5.0.

-

-

-
-  
-    
-    
-  
-
January 3, 2018NetBSD 10.1

diff --git a/static/netbsd/man9/strlist.9 3.html b/static/netbsd/man9/strlist.9 3.html
deleted file mode 100644
index 8b78bd4c..00000000
--- a/static/netbsd/man9/strlist.9 3.html	
+++ /dev/null
@@ -1,212 +0,0 @@
-
-  
-    
-    
-    
-  
-
OFSL(9)Kernel Developer's ManualOFSL(9)

-

-

-

-
strlist,
-    strlist_next, strlist_count,
-    strlist_string,
-    strlist_match,
-    strlist_index,
-    strlist_append — functions
-    to interact with OpenFirmware-style string lists

-

-

-

-
#include
-    <sys/systm.h>

-
const char *
-  

-  strlist_next(const
-    char *sl, size_t
-    slsize, size_t
-    *cursorp);

-
void
-  

-  strlist_count(const
-    char *sl, size_t
-    slsize);

-
const char *
-  

-  strlist_string(const
-    char *sl, size_t
-    slsize, unsigned int
-    index);

-
int
-  

-  strlist_match(const
-    char *sl, size_t
-    slsize, const char
-    *str);

-
int
-  

-  strlist_pmatch(const
-    char *sl, size_t
-    slsize, const char
-    *pattern);

-
int
-  

-  strlist_index(const
-    char *sl, size_t
-    slsize, const char
-    *str);

-
bool
-  

-  strlist_append(char
-    **slp, size_t
-    *slsizep, const char
-    *str);

-

-

-

-
The strlist functions provide a simple way
-    to interact with OpenFirmware (IEEE 1275) string lists.

-
An OpenFirmware string list is simply a buffer containing one or
-    more NUL-terminated strings concatenated together. For example, a string
-    list containing the strings “foo”, “bar”, and
-    “baz” would be represented in memory as:

-

-
foo\0bar\0baz\0

-

-
The following functions are available:

-

-  
(const
-    char *sl, size_t slsize, size_t
-    *cursorp)

-  
This function provides a way to enumerate the strings in a string list. To
-      enumerate a string list, initialize cursor to 0 and
-      pass it by reference to strlist_next(). Each call
-      to strlist_next() returns the current string and
-      advances the cursor to the next string in the list. If all strings in the
-      list have been enumerated, strlist_next() will
-      return NULL.

-  
(const
-    char *sl, size_t slsize)

-  
Returns the number of strings in the string list.

-  
(const
-    char *sl, size_t slsize,
-    unsigned int index)

-  
Returns a pointer to the string in the string list at the specified index
-      or NULL if the index is out of range.

-  
(const
-    char *sl, size_t slsize, const
-    char *str)

-  
Returns a weighted match value if the specified string appears in the
-      string list. The value returned is the number of strings in the string
-      list minus the index of the matched string. For example, if a string list
-      contains the strings “foo”, “bar”, and
-      “baz”, a match against “foo” returns 3 and a
-      match against “baz” returns 1. If the string does not appear
-      in the string list, 0 is returned.

-  
(const
-    char *sl, size_t slsize, const
-    char *pattern)

-  
Like strlist_match(), but uses
-      ()
-      to compare strings, allowing for wildcard characters to be specified in
-      pattern.

-  
(const
-    char *sl, size_t slsize, const
-    char *str)

-  
Returns the index of the specified string if it appears in the string
-      list, or -1 if the string does not appear in the string list.

-  
(char
-    **slp, size_t *slsizep, const
-    char *str)

-  
Appends a copy of the specified string to the stringlist. Begin by
-      initializing sl to NULL and
-      slsize to 0. Pass these by reference to
-      strlist_append(). New memory for the string list
-      will be allocated as needed. The resulting string list can be freed with
-      ().
-      Returns true if the string was successfully
-      appended to the string list or false if memory
-      allocation fails.

-

-

-

-

-
The following shows an example of string list enumeration using
-    strlist_next():

-

-
void
-print_stringlist(const char *sl, size_t slsize)
-{
-	const char *cp;
-	size_t cursor;
-
-	printf("There are %u strings in the string list:\n",
-	    strlist_count(sl, slsize));
-	for (cursor = 0;
-	     (cp = strlist_next(sl, slsize, &cursor) != NULL; ) {
-		printf("\t%s\n", cp);
-	}
-}

-

-
The following example shows a simple way to use
-    strlist_match():

-

-
bool
-is_compatible(int phandle, const char *compat_str)
-{
-	char buf[128];
-	int proplen;
-
-	proplen = OF_getprop(phandle, "compatible", buf, sizeof(buf));
-	return strlist_match(buf, proplen, compat_str) != 0;
-}

-

-
The following example shows a use of
-    strlist_pmatch():

-

-
bool
-is_pc_printer_port(const char *pnp_id_list, size_t list_size)
-{
-	return strlist_pmatch(pnp_id_list, list_size, "PNP04??") != 0;
-}

-

-
The following example converts an array of strings to a string
-    list using strlist_append():

-

-
char *
-string_array_to_string_list(const char **array, int count,
-    size_t *slsizep)
-{
-	char *sl;
-	size_t slsize;
-	int i;
-
-	for (i = 0, sl = NULL, slsize = 0; i < count; i++) {
-		if (!strlist_append(&sl, &slsize, array[i])) {
-			kmem_free(sl, slsize);
-			return NULL;
-		}
-	}
-
-	*slsizep = slsize;
-	return sl;
-}

-

-

-

-

-
kmem(9), pmatch(9)

-

-

-

-
The strlist functions first appeared in
-    NetBSD 10.0.

-

-

-
-  
-    
-    
-  
-
January 20, 2021NetBSD 10.1

diff --git a/static/netbsd/man9/tc.9 3.html b/static/netbsd/man9/tc.9 3.html
deleted file mode 100644
index ebfdfeed..00000000
--- a/static/netbsd/man9/tc.9 3.html	
+++ /dev/null
@@ -1,185 +0,0 @@
-
-  
-    
-    
-    
-  
-
TC(9)Kernel Developer's ManualTC(9)

-

-

-

-
TC,
-    tc_intr_establish,
-    tc_intr_disestablish,
-    tc_intr_evcnt. tc_mb,
-    tc_wmb, tc_syncbus,
-    tc_badaddr,
-    TC_DENSE_TO_SPARSE,
-    TC_PHYS_TO_UNCACHED —
-    TURBOchannel bus

-

-

-

-
#include
-    <sys/bus.h>
-  

-  #include <dev/tc/tcvar.h>
-  

-  #include <dev/tc/tcdevs.h>

-
void
-  

-  tc_intr_establish(struct
-    device *dev, void
-    *cookie, int level,
-    int (*handler)(void *),
-    void *arg);

-
void
-  

-  tc_intr_disestablish(struct
-    device *dev, void
-    *cookie);

-
const struct evcnt *
-  

-  tc_intr_evcnt(struct
-    device *dev, void
-    *cookie);

-
void
-  

-  tc_mb();

-
void
-  

-  tc_wmb();

-
void
-  

-  tc_syncbus();

-
int
-  

-  tc_badaddr(tc_addr_t
-    tcaddr);

-
tc_addr_t
-  

-  TC_DENSE_TO_SPARSE(tc_addr_t
-    addr);

-
tc_addr_t
-  

-  TC_PHYS_TO_UNCACHED(tc_addr_t
-    addr);

-

-

-

-
The TC device provides support for the DEC
-    TURBOchannel bus found on all DEC TURBOchannel machines with MIPS
-    (DECstation 5000 series, excluding the 5000/200) and Alpha (3000-series)
-    systems. TURBOchannel is a 32-bit wide synchronous DMA-capable bus, running
-    at 25 MHz on higher-end machines and at 12.5 MHz on lower-end machines.

-

-

-

-
Drivers for devices attached to the TURBOchannel bus will make use
-    of the following data types:

-

-  
struct tc_attach_args

-  
A structure use to inform the driver of TURBOchannel bus properties. It
-      contains the following members:
-    

-    
	bus_space_tag_t	ta_memt;
-	bus_dma_tag_t	ta_dmat;
-	char		ta_modname[TC_ROM_LLEN+1];
-	u_int		ta_slot;
-	tc_offset_t	ta_offset;
-	tc_addr_t	ta_addr;
-	void		*ta_cookie;
-	u_int		ta_busspeed;

-    

-    
The
-        
-        member specifies the TURBOchannel bus speed and is useful for
-        time-related functions. Values values are
-        
-        for the 12.5 MHz bus and
-        
-        for the 50 MHz bus.

-  

-

-

-

-

-

-  
(dev,
-    cookie, level,
-    handler, arg)

-  
Establish an interrupt handler with device dev for
-      the interrupt described completely by cookie, the
-      value passed to the driver in the
-      
-      member of the tc_attach_args structure. The priority of
-      the interrupt is specified by level. When the
-      interrupt occurs the function handler is called with
-      argument arg.

-  
(dev,
-    cookie)

-  
Dis-establish the interrupt handler with device dev
-      for the interrupt described completely cookie.

-  
(dev,
-    cookie)

-  
Do interrupt event counting with device dev for the
-      event described completely by cookie.

-  
()

-  
A read/write memory barrier. Any CPU-to-memory reads/writes before the
-      barrier must complete before any CPU-to-memory reads/writes after it.

-  
()

-  
A write memory barrier. Any CPU-to-memory writes before the barrier must
-      complete before any CPU-to-memory writes after it.

-  
()

-  
Synchronise writes on the TURBOchannel bus by ensuring CPU writes are
-      propagated across the TURBOchannel bus.

-  
(tcaddr)

-  
Returns non-zero if the given address tcaddr is
-      invalid.

-  
(addr)

-  
Convert the given physical address addr in
-      TURBOchannel dense space to the corresponding address in TURBOchannel
-      sparse space.

-  
(addr)

-  
Convert the given system memory physical address
-      addr to the physical address of the corresponding
-      region that is not cached.

-

-

-

-

-
The TURBOchannel bus is a direct-connection bus. During
-    autoconfiguration, the parent specifies the name of the found TURBOchannel
-    module into the ta_modname member of the
-    tc_attach_args structure. Drivers should match on this
-    name.

-

-

-

-
The TURBOchannel bus supports 32-bit, bidirectional DMA transfers.
-    Support is provided by the standard bus_dma(9)
-  interface.

-

-

-

-
The TURBOchannel subsystem itself is implemented within the file
-    sys/dev/tc/tc_subr.c. Machine-dependent portions can
-    be found in sys/arch/<arch>/tc/tcbus.c.

-

-

-

-
tc(4), autoconf(9),
-    bus_dma(9), bus_space(9),
-    driver(9)

-

-

-
-  
-    
-    
-  
-
October 7, 2001NetBSD 10.1

diff --git a/static/netbsd/man9/tcp_congctl.9 3.html b/static/netbsd/man9/tcp_congctl.9 3.html
deleted file mode 100644
index 5342e324..00000000
--- a/static/netbsd/man9/tcp_congctl.9 3.html	
+++ /dev/null
@@ -1,87 +0,0 @@
-
-  
-    
-    
-    
-  
-
TCP_CONGCTL(9)Kernel Developer's ManualTCP_CONGCTL(9)

-

-

-

-
tcp_congctl — TCP
-    congestion control API

-

-

-

-
#include
-    <netinet/tcp_congctl.h>

-
int
-  

-  tcp_congctl_register(const
-    char *, struct
-    tcp_congctl *);

-
int
-  

-  tcp_congctl_unregister(const
-    char *);

-

-

-

-
The tcp_congctrl API is used to add or
-    remove TCP congestion control algorithms on-the-fly and to modularize them.
-    It includes basically two functions:

-

-  
(const
-    char *, struct tcp_congctl *)

-  
Registers a new congestion control algorithm. The struct
-      tcp_congctl argument must contain a list of callbacks like the
-      following:
-    

-    
struct tcp_congctl {
-	int  (*fast_retransmit)(struct tcpcb *,
-	    struct tcphdr *);
-	void (*slow_retransmit)(struct tcpcb *);
-	void (*fast_retransmit_newack)(struct tcpcb *,
-	    struct tcphdr *);
-	void (*newack)(struct tcpcb *,
-	    struct tcphdr *);
-	void (*cong_exp)(struct tcpcb *);
-};

-    

-  

-  
(const
-    char *)

-  
If found, unregister the selected TCP congestion control algorithm.

-

-

-

-

-
tcp_congctl_register() and
-    tcp_congctl_unregister() both return
-    0 when there is no error. If the name is already
-    registered, tcp_congctl_register() will return
-    EEXIST.
-    tcp_congctl_unregister() can return
-    ENOENT if there is no congestion control algorithm
-    by that name and can return EBUSY if the matched
-    algorithm is being used by userspace applications.

-

-

-

-
Implementation is in
-    sys/netinet/tcp_congctl.c and the interface is in
-    sys/netinet/tcp_congctl.h.

-

-

-

-
tcp(4)

-

-

-
-  
-    
-    
-  
-
October 15, 2006NetBSD 10.1

diff --git a/static/netbsd/man9/ucom.9 3.html b/static/netbsd/man9/ucom.9 3.html
deleted file mode 100644
index 774d39d3..00000000
--- a/static/netbsd/man9/ucom.9 3.html	
+++ /dev/null
@@ -1,204 +0,0 @@
-
-  
-    
-    
-    
-  
-
UCOM(9)Kernel Developer's ManualUCOM(9)

-

-

-

-
ucom — interface
-    for USB tty like devices

-

-

-

-
The ucom driver is a (relatively) easy way
-    to make a USB device look like a tty(4). It basically
-    takes two bulk pipes, input and output, and makes a tty out of them. This is
-    useful for a number of device types, e.g., serial ports (see
-    uftdi(4)), modems (see umodem(4)), and
-    devices that traditionally look like a tty (see
-    uvisor(4)).

-
Communication between the real driver and the
-    ucom driver is via the attachment arguments (when
-    attached) and via the ucom_methods struct

-

-

-

-

-
struct ucom_attach_args {
-	int ucaa_portno;
-	int ucaa_bulkin;
-	int ucaa_bulkout;
-	u_int ucaa_ibufsize;
-	u_int ucaa_ibufsizepad;
-	u_int ucaa_obufsize;
-	u_int ucaa_opkthdrlen;
-	const char *ucaa_info;
-	struct usbd_device *ucaa_device;
-	struct usbd_interface *ucaa_iface;
-	const struct ucom_methods *ucaa_methods;
-	void *ucaa_arg;
-};

-

-

-  

-  
identifies the port if the devices should have more than one
-      ucom attached. Use the value
-      UCOM_UNK_PORTNO if there is only one port.

-  

-  
the number of the bulk input pipe.

-  

-  
the number of the bulk output pipe.

-  

-  
the size of the read requests on the bulk in pipe.

-  

-  
the size of the input buffer. This is usually the same as
-      ibufsize.

-  

-  
the size of the write requests on the bulk out pipe.

-  

-  
the size of the output buffer. This is usually the same as
-      ucaa_obufsize.

-  

-  
a handle to the device.

-  
struct usbd_interface *ucaa_iface

-  
a handle to the interface that should be used.

-  
struct ucom_methods *ucaa_methods

-  
a pointer to the methods that the ucom driver
-      should use for further communication with the driver.

-  
void *ucaa_arg

-  
the value that should be passed as first argument to each method.

-

-

-

-

-
The ucom_methods struct contains a number
-    of function pointers used by the ucom driver at
-    various stages. If the device is not interested in being called at a
-    particular point it should just use a NULL pointer
-    and the ucom driver will use a sensible default.

-

-
struct ucom_methods {
-	void (*ucom_get_status)(void *sc, int portno,
-	    u_char *lsr, u_char *msr);
-	void (*ucom_set)(void *sc, int portno, int reg, int onoff);
-#define UCOM_SET_DTR 1
-#define UCOM_SET_RTS 2
-#define UCOM_SET_BREAK 3
-	int (*ucom_param)(void *sc, int portno, struct termios *);
-	int (*ucom_ioctl)(void *sc, int portno, u_long cmd,
-	    void *data, int flag, proc_t *p);
-	int (*ucom_open)(void *sc, int portno);
-	void (*ucom_close)(void *sc, int portno);
-	void (*ucom_read)(void *sc, int portno, u_char **ptr,
-	    uint32_t *count);
-	void (*ucom_write)(void *sc, int portno, u_char *to,
-	    u_char *from, uint32_t *count);
-};

-

-

-  
void
-    (*ucom_get_status)(void *sc,
-    int portno, u_char *lsr,
-    u_char *msr)

-  
get the status of port portno. The status consists
-      of the line status, lsr, and the modem status
-      msr. The contents of these two bytes is exactly as
-      for a 16550 UART.

-  
void
-    (*ucom_set)(void *sc,
-    int portno, int reg,
-    int onoff)

-  
Set (or unset) a particular feature of a port.

-  
int
-    (*ucom_param)(void *sc,
-    int portno, struct termios
-    *t)

-  
Set the speed, number of data bit, stop bits, and parity of a port
-      according to the termios(4) struct.

-  
int
-    (*ucom_ioctl)(void *sc,
-    int portno, u_long cmd,
-    void *data, int flag,
-    proc_t *p)

-  
implements any non-standard ioctl(2) that a device
-      needs.

-  
int
-    (*ucom_open)(void *sc,
-    int portno)

-  
called just before the ucom driver opens the bulk
-      pipes for the port.

-  
void
-    (*ucom_close)(void *sc,
-    int portno)

-  
called just after the ucom driver closes the bulk
-      pipes for the port.

-  
void
-    (*ucom_read)(void *sc,
-    int portno, u_char **ptr,
-    uint32_t *count)

-  
if the data delivered on the bulk pipe is not just the raw input
-      characters this routine needs to increment ptr by as
-      many characters to skip from the start of the raw input and decrement
-      count by as many characters to truncate from the end
-      of the raw input.

-  
void
-    (*ucom_write)(void *sc,
-    int portno, u_char *dst,
-    u_char *src, uint32_t
-    *count)

-  
if the data written to the bulk pipe is not just the raw characters then
-      this routine needs to copy count raw characters from
-      src into the buffer at dst and
-      do the appropriate padding. The count should be
-      updated to the new size. The buffer at src is at
-      most ibufsize bytes and the buffer at
-      dst is ibufsizepad bytes.

-

-
Apart from these methods there is a function

-

-

-  
void
-    (struct
-    ucom_softc *)

-  
 

-

-

-
which should be called by the driver whenever it notices a status
-    change.

-

-

-

-
tty(4), u3g(4),
-    uark(4), ubsa(4),
-    uchcom(4), uftdi(4),
-    ugensa(4), uhmodem(4),
-    uipaq(4), ukyopon(4),
-    umct(4), umodem(4),
-    uplcom(4), usb(4),
-    uslsa(4), uvisor(4),
-    uvscom(4)

-

-

-

-
This ucom interface first appeared in
-    NetBSD 1.5.

-

-

-
-  
-    
-    
-  
-
September 12, 2016NetBSD 10.1

diff --git a/static/netbsd/man9/usbd_status.9 3.html b/static/netbsd/man9/usbd_status.9 3.html
deleted file mode 100644
index 9b3cad01..00000000
--- a/static/netbsd/man9/usbd_status.9 3.html	
+++ /dev/null
@@ -1,97 +0,0 @@
-
-  
-    
-    
-    
-  
-
USBD_STATUS(9)Kernel Developer's ManualUSBD_STATUS(9)

-

-

-

-
usbd_status — USB
-    device drivers interface return status values

-

-

-

-
#include
-    <dev/usb/usbdi.h>

-

-

-

-
This documents the full list of return values used by the generic
-    USB code. Interface-specific definitions will be given with interface.

-

-

-

-
Return values are split into two main groups: expected values and
-    error values.

-
There are only two expected values:

-

-  

-  
The operation completed successfully.

-  

-  
The operation was successfully submitted, usually part of an asynchronous
-      operation.

-

-
These are the error values:

-

-  

-  
The requested operation could not be completed due to pending requests,
-      usually from a pipe close operation.

-  

-  
The initial status of a USB transfer. See usbdi(9) for
-      more details about USB transfers.

-  

-  
Invalid arguments were supplied for the requested operation.

-  

-  
No memory could be allocated.

-  

-  
The USB transfer has been cancelled, and not completed.

-  

-  
The requested USB pipe could not be found. See usbdi(9)
-      for more details about USB pipes.

-  

-  
The requested operation could not be performed due to the device having
-      active connections, such as USB audio device currently playing.

-  

-  
USB bus has reached its maximum limit of devices.

-  

-  
Call to usbd_set_address() failed during new USB
-      device discovery.

-  

-  
New device has requested more power than is available.

-  

-  
New USB Hub too deep from the root.

-  

-  
Non-specific error happened during IO.

-  

-  
USB device is not configured; it has no configuration descriptor.

-  

-  
Operation timed out.

-  

-  
USB transfer succeeded but not all requested data was returned.

-  

-  
USB controller has stalled (controller specific.)

-  

-  
Process was interrupted by external means (such as a signal) while waiting
-      for a transfer to complete.

-

-

-

-

-
usb(4), usbdi(9)

-

-

-

-
This usbd_status interface first appeared
-    in NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
May 12, 2012NetBSD 10.1

diff --git a/static/netbsd/man9/usbnet.9 3.html b/static/netbsd/man9/usbnet.9 3.html
deleted file mode 100644
index 39a68489..00000000
--- a/static/netbsd/man9/usbnet.9 3.html	
+++ /dev/null
@@ -1,669 +0,0 @@
-
-  
-    
-    
-    
-  
-
USBNET(9)Kernel Developer's ManualUSBNET(9)

-

-

-

-
usbnet — common
-    USB Ethernet driver framework

-

-

-

-
#include
-    <dev/usb/usbnet.h>

-

-

-
void
-  

-  usbnet_set_link(struct
-    usbnet *un, bool
-    link);

-
struct ifnet *
-  

-  usbnet_ifp(struct
-    usbnet *un);

-
struct ethercom *
-  

-  usbnet_ec(struct
-    usbnet *un);

-
struct mii_data *
-  

-  usbnet_mii(struct
-    usbnet *un);

-
krndsource_t *
-  

-  usbnet_rndsrc(struct
-    usbnet *un);

-
void *
-  

-  usbnet_softc(struct
-    usbnet *un);

-
bool
-  

-  usbnet_havelink(struct
-    usbnet *un);

-
int
-  

-  usbnet_ispromisc(struct
-    usbnet *un);

-
bool
-  

-  usbnet_isdying(struct
-    usbnet *un);

-
void
-  

-  usbnet_enqueue(struct
-    usbnet *un, uint8_t
-    *buf, size_t
-    buflen, int
-    csum_flags, uint32_t
-    csum_data, int
-    mbuf_flags);

-
void
-  

-  usbnet_input(struct
-    usbnet *un, uint8_t
-    *buf, size_t
-    buflen);

-
void
-  

-  usbnet_attach(struct
-    usbnet *un);

-
void
-  

-  usbnet_attach_ifp(struct
-    usbnet *un, unsigned
-    if_flags, unsigned
-    if_extflags, const struct
-    usbnet_mii *unm);

-
int
-  

-  usbnet_detach(device_t
-    dev, int
-  flags);

-
int
-  

-  usbnet_activate(device_t
-    dev, devact_t
-  act);

-

-

-

-

-
The usbnet framework provides methods
-    usable for USB Ethernet drivers. The framework has support for these
-    features:

-
    
-  
  • Partial autoconf handling
    • 
-  
  • USB endpoint pipe handling
    • 
-  
  • Rx and Tx chain handling
    • 
-  
  • Generic handlers or support for several struct ifnet callbacks
    • 
-  
  • Network stack locking protocol
    • 
-  
  • Interrupt handling
    • 
-

-
usbnet provides many or all of the
-    traditional “softc” members inside struct
-    usbnet, which can be used directly as the device softc structure if no
-    additional storage is required. A structure exists for receive and transmit
-    chain management, struct usbnet_chain, that tracks the
-    metadata for each transfer descriptor available, minimum of one each for Rx
-    and Tx slots, and will be passed to the Rx and Tx callbacks.

-
There is a struct usbnet_ops structure that
-    provides a number of optional and required callbacks that will be described
-    below.

-
For autoconfiguration the device attach routine
-    is expected to ensure that this device's struct usbnet
-    is the first member of the device softc, if it can not be used directly as
-    the device softc, as well as set up the necessary structure members, find
-    end-points, find the Ethernet address if relevant, call
-    (),
-    set up interface, Ethernet, and MII capabilities, and finally call
-    usbnet_attach_ifp(). The device detach routine
-    should free any resources allocated by attach and then call
-    usbnet_detach(), possibly directly using
-    usbnet_detach() as most consumers have no additional
-    resources not owned and released by the usbnet
-    framework itself. The device activate function should be set to
-    usbnet_activate().

-
When bringing an interface up from if_init(9),
-    which happens under IFNET_LOCK(9),
-    usbnet will:

-
    
-  
  1. call “uno_init” to initialize the hardware for sending and
-      receiving packets,
    2. 
-  
  2. open the USB pipes,
    3. 
-  
  3. allocate Rx and Tx buffers for transfers,
    4. 
-  
  4. call “uno_mcast” to initially program the hardware multicast
-      filter, and finally
    5. 
-  
  5. start the Rx transfers so packets can be received.
    6. 
-

-
See the RECEIVE AND
-    SEND section for details on using the chains.

-
When bringing an interface down from if_stop(9),
-    which happens under IFNET_LOCK(9),
-    usbnet will:

-
    
-  
  1. abort the USB pipes,
    2. 
-  
  2. call “uno_stop” to stop the hardware from receiving packets
-      (unless the device is detaching),
    3. 
-  
  3. free Rx and Tx buffers for transfers, and
    4. 
-  
  4. close the USB pipes.
    5. 
-

-
For interface ioctl, most of the handling is in the framework.
-    While the interface is running, the optional “uno_mcast”
-    callback is invoked after handling the SIOCADDMULTI
-    and SIOCDELMULTI ioctl commands to update the
-    hardware's multicast filter from the ethersubr(9) lists.
-    The optional “uno_ioctl” callback, which is invoked under
-    IFNET_LOCK(9), can be used to program special settings
-    like offload handling.

-
If ioctl handling requires capturing
-    device-specific ioctls then the “uno_override_ioctl” callback
-    may be used instead to replace the framework's ioctl handler completely
-    (i.e., the replacement should call any generic ioctl handlers such as
-    ()
-    as required). For sending packets, the “uno_tx_prepare”
-    callback must be used to convert an mbuf into a chain buffer ready for
-    transmission.

-
For devices requiring MII handling there are callbacks for reading
-    and writing registers, and for status change events. Access to all the MII
-    functions is serialized by usbnet.

-
As receive must handle the case of multiple
-    packets in one buffer, the support is split between the driver and the
-    framework. A “uno_rx_loop” callback must be provided that
-    loops over the incoming packet data found in a chain, performs necessary
-    checking, and passes the network frame up the stack via either
-    ()
-    or
-    ().
-    Typically Ethernet devices prefer
-  usbnet_enqueue().

-
General accessor functions for struct
-    usbnet:

-

-  
-  
Set the link status for this un to
-      link.

-  
(un)

-  
Returns pointer to this un's struct
-      ifnet.

-  
(un)

-  
Returns pointer to this un's struct
-      ethercom.

-  
(un)

-  
Returns pointer to this un's struct
-      mii_data.

-  
(un)

-  
Returns pointer to this un's
-      krndsource_t.

-  
(un)

-  
Returns pointer to this un's device softc.

-  
-  
Returns true if link is active.

-  
(un)

-  
True if IFF_PROMISC is enabled, false if not.
-    
May be used only in “uno_init” and
-        “uno_mcast”.

-    
Drivers must use this in “uno_mcast” instead of
-        reading ifp->if_flags.

-  

-  
(un)

-  
Returns true if device is dying (has been pulled or deactivated, pending
-      detach). This should be used only to abort timeout loops early.

-

-
Buffer enqueue handling for struct
-  usbnet:

-

-  
(un,
-    buf, buflen,
-    csum_flags, csum_data,
-    mbuf_flags)

-  
Enqueue buffer buf for length
-      buflen with higher layers, using the provided
-      csum_flags, and csum_data,
-      which are written directly to the mbuf packet header, and
-      mbuf_flags, which is or-ed into the mbuf flags for
-      the created mbuf.

-  
(un,
-    buf, buflen)

-  
Enqueue buffer buf for length
-      buflen with higher layers.

-

-
Autoconfiguration handling for struct
-    usbnet. See the
-    AUTOCONFIGURATION section for
-    more details about these functions.

-

-  
(un)

-  
Initial stage attach of a USB network device. Performs internal
-      initialization and memory allocation only — nothing is published
-      yet.

-  
usbnet_attach_ifp(un,
-    if_flags, if_extflags,
-    unm)

-  
Final stage attach of a USB network device. Publishes the network
-      interface to the rest of the system.
-    
If the passed in unm is
-        non-NULL then an MII interface will be created
-        using the values provided in the struct usbnet_mii
-        structure, which has these members passed to
-        ():

-    

-      
un_mii_flags

-      
Flags.

-      
un_mii_capmask

-      
Capability mask.

-      
un_mii_phyloc

-      
PHY location.

-      
un_mii_offset

-      
PHY offset.

-    

-    
A default
-        unm can be set using the
-        ()
-        macro. The if_flags and
-        if_extflags will be or-ed into the interface flags
-        and extflags.

-  

-  
usbnet_detach(dev,
-    flags)

-  
Device detach. Stops all activity and frees memory. Usable as
-      driver(9) detach method.

-  
usbnet_activate(dev,
-    act)

-  
Device activate (deactivate) method. Usable as driver(9)
-      activate method.

-

-

-

-

-
The framework expects the usbnet structure to have these members
-    filled in with valid values or functions:

-

-  
un_sc

-  
Real softc allocated by autoconf and provided to attach, should be set to
-      the usbnet structure if no device-specific softc is needed.

-  
un_dev

-  
device_t saved in attach, used for messages mostly.

-  
un_iface

-  
The USB iface handle for data interactions, see
-      ()
-      for more details.

-  
un_udev

-  
The struct usbd_device for this device, provided as the usb_attach_arg's
-      uaa_device member.

-  
un_ops

-  
Points to a struct usbnet_ops structure which
-      contains these members:
-    

-      
void
-        (*uno_stop)(struct ifnet
-        *ifp, int disable)

-      
Stop hardware activity (optional). Called under
-          IFNET_LOCK(9) when bringing the interface down, but
-          skipped when the device is detaching.

-      
int
-        (*uno_ioctl)(struct ifnet
-        *ifp, u_long cmd, void
-        *data)

-      
Handle driver-specific ioctls (optional). Called under
-          IFNET_LOCK(9).

-      
void
-        (*uno_mcast)(struct ifnet
-        *)

-      
Program hardware multicast filters from ethersubr(9)
-          lists (optional). Called between, and not during,
-          “uno_init” and “uno_stop”.

-      
int
-        (*uno_override_ioctl)(struct
-        ifnet *ifp, u_long cmd, void
-        *data)

-      
Handle all ioctls, including standard ethernet ioctls normally handled
-          internally by usbnet (optional). May or may
-          not be called under IFNET_LOCK(9).

-      
int
-        (*uno_init)(struct ifnet
-        *ifp)

-      
Initialize hardware activity (optional). Called under
-          IFNET_LOCK(9) when bringing the interface up.

-      
int
-        (*uno_read_reg)(struct usbnet
-        *un, int phy, int reg,
-        uint16_t *val)

-      
Read MII register. Required with MII. Serialized with other MII
-          functions, and only called after “uno_init” and before
-          “uno_stop”.

-      
int
-        (*uno_write_reg)(struct usbnet
-        *un, int phy, int reg,
-        uint16_t val)

-      
Write MII register. Required with MII. Serialized with other MII
-          functions, and only called after “uno_init” and before
-          “uno_stop”.

-      
usbd_status
-        (*uno_statchg)(struct ifnet
-        *ifp)

-      
Handle MII status change. Required with MII. Serialized with other MII
-          functions, and only called after “uno_init” and before
-          “uno_stop”.

-      
unsigned
-        (*uno_tx_prepare)(struct usbnet
-        *un, struct mbuf *m, struct
-        usbnet_chain *c)

-      
Prepare an mbuf for transmit. Required. Called sequentially between,
-          and not during, “uno_init” and
-        “uno_stop”.

-      
void
-        (*uno_rx_loop)(struct usbnet
-        *un, struct usbnet_chain *c,
-        uint32_t total_len)

-      
Prepare one or more chain for enqueue. Required. Called sequentially
-          between, and not during, “uno_init” and
-          “uno_stop”.

-      
void
-        (*uno_intr)(struct usbnet
-        *un, usbd_status status)

-      
Process periodic interrupt (optional). Called sequentially between,
-          and not during, “uno_init” and
-        “uno_stop”.

-      
void
-        (*uno_tick)(struct usbnet
-        *un)

-      
Called every second with USB task thread context (optional). Called
-          sequentially between, and not during, “uno_init” and
-          “uno_stop”.

-    

-  

-  
un_intr

-  
Points to a struct usbnet_intr structure which
-      should have these members set:
-    

-      
uni_buf

-      
If non-NULL, points to a buffer passed to
-          usbd_open_pipe_intr() in the device init
-          callback, along with the size and interval.

-      
uni_bufsz

-      
Size of interrupt pipe buffer.

-      
uni_interval

-      
Frequency of the interrupt in milliseconds.

-    

-  

-  
un_ed

-  
Array of endpoint descriptors. There indexes are provided:
-      USBNET_ENDPT_RX,
-      USBNET_ENDPT_TX, and
-      USBNET_ENDPT_INTR. The Rx and Tx endpoints are
-      required.

-  
un_phyno

-  
MII phy number. Not used by usbnet.

-  
un_eaddr

-  
6 bytes of Ethernet address that must be provided before calling
-      usbnet_attach_ifp() if the device has
-    Ethernet.

-  
un_flags

-  
Device owned flags word. The usbnet framework will
-      not touch this value.

-  
un_rx_xfer_flags

-  
Passed to
-      ()
-      for receiving packets.

-  
un_tx_xfer_flags

-  
Passed to usbd_setup_xfer() for sending
-    packets.

-  
un_rx_list_cnt

-  
Number of chain elements to allocate for Rx.

-  
un_tx_list_cnt

-  
Number of chain elements to allocate for Tx.

-  
un_rx_bufsz

-  
Rx buffer size.

-  
un_tx_bufsz

-  
Tx buffer size.

-

-
The device detach and activate callbacks can
-    typically be set to
-    ()
-    and
-    ()
-    unless device-specific handling is required, in which case, they can be
-    called before or after such handling.

-
The capabilities described in both
-    struct ifp and struct ethercom
-    must be set before calling
-    ().

-

-

-

-
Receive and send routines are structured around the
-    usbnet_cdata and usbnet_chain
-    structures, the un_ed,
-    un_rx_xfer_flags, and
-    un_tx_xfer_flags members, and the
-    uno_init(),
-    uno_tx_prepare(),
-    uno_rx_loop(), and
-    uno_stop() callbacks of
-    usbnet_ops.

-
Typically, the device attach routine will fill in members of the
-    usbnet structure, as listed in
-    AUTOCONFIGURATION. The
-    un_ed array should have the
-    USBNET_ENDPT_RX and
-    USBNET_ENDPT_TX array entries filled in, and
-    optionally the USBNET_ENDPT_INTR entry filled in if
-    applicable.

-
The
-    ()
-    callback enables the hardware, and if necessary reprograms the hardware
-    multicast filter, before the framework initiates USB Tx/Rx transfers. All
-    USB transfer setup is handled by the framework. The driver callbacks merely
-    copy data in or out of a chain entry using what is typically a
-    device-specific method.

-
The
-    ()
-    callback, called sequentially, converts the provided
-    usbnet_chain data and length into a series (one or
-    more) of packets that are enqueued with the higher layers using either
-    usbnet_enqueue() (for most devices) or
-    usbnet_input() for devices that use
-    ().
-    (This currently relies upon the struct ifnet having
-    the “_if_input” member set as well, which is true for current
-    consumers.)

-
The
-    ()
-    callback must convert the provided struct mbuf into
-    the provided struct usbnet_chain performing any
-    device-specific padding, checksum, header or other. Note that this callback
-    must check that it is not attempting to copy more than the chain buffer
-    size, as set in the usbnet “un_tx_bufsz”
-    member. This callback is only called once per packet, sequentially.

-
The struct usbnet_chain structure which
-    contains a “unc_buf” member which has the chain buffer
-    allocated where data should be copied to or from for receive or transmit
-    operations. It also contains pointers back to the owning
-    struct usbnet, and the struct
-    usbd_xfer associated with this transfer.

-
After aborting all USB Tx/Rx transfers when bringing
-    an interface down, the framework calls the optional
-    ()
-    callback to disable the hardware.

-

-

-

-
For devices that have MII support these callbacks in
-    struct usbnet_ops must be provided:

-

-  
uno_read_reg

-  
Read an MII register for a particular PHY. Returns standard
-      errno(2). Must initialize the result even on
-    failure.

-  
uno_write_reg

-  
Write an MII register for a particular PHY. Returns standard
-      errno(2).

-  
uno_statchg

-  
Handle a status change event for this interface.

-

-

-

-

-
The interrupt-specific callback, “uno_intr”, is an
-    optional callback that can be called periodically, registered by
-    usbnet using the
-    usbd_open_pipe_intr() function (instead of the
-    ()
-    function). The usbnet framework provides most of the
-    interrupt handling and the callback simply inspects the returned buffer as
-    necessary. To enable this callback point the struct
-    usbnet member “un_intr” to a struct
-    usbnet_intr structure with these members set:

-

-  
uni_buf

-  
Data buffer for interrupt status replies.

-  
uni_bufsz

-  
Size of the above buffer.

-  
uni_interval

-  
Interval in millieconds.

-

-
These values will be passed to
-    ().

-

-

-

-
The porting of an older driver to the
-    usbnet framework is largely an effort in deleting
-    code. The process involves making these changes:

-

-  
Headers

-  
Many headers are included in usbnet.h and can be
-      removed from the driver, as well as headers no longer used, such as
-      callout.h and rndsource.h,
-      etc.

-  
Device softc

-  
The majority of the driver's existing “softc” structure can
-      likely be replaced with usage of struct usbnet and
-      its related functionality. This includes at least the device_t pointer,
-      Ethernet address, the ethercom and mii_data structures, end point
-      descriptors, usbd device, interface, and task and callout structures (both
-      these probably go away entirely) and all the associated watchdog handling,
-      timevals, list size, buffer size and xfer flags for both Rx, and Tx, and
-      interrupt notices, interface flags, device link, PHY number, chain data,
-      locks including Rx, Tx, and MII. There is a driver-only
-      “un_flags” in the usbnet structure
-      available for drivers to use.
-    
Many drivers can use the
-        usbnet structure as the device private storage
-        passed to CFATTACH_DECL_NEW. Many internal
-        functions to the driver may look better if switched to operate on the
-        device's usbnet as, for example, the
-        usbd_device value is now available (and must be
-        set by the driver) in the usbnet, which may be
-        needed for any call to
-        ().
-        The standard endpoint values must be stored in the
-        usbnet “un_ed[]” array.

-    
As usbnet manages xfer chains all code
-        related to the opening, closing, aborting and transferring of data on
-        pipes is performed by the framework based upon the buffer size and more
-        provided in subnet, so all code related to them
-        should be deleted.

-  

-  
Interface setup

-  
The vast majority of interface-specific code should be deleted. For
-      device-specific interface values, the ifnet flags
-      and exflags can be set, as well as the ethercom
-      “ec_capabilities” member, before calling
-      ().
-      All calls to
-      (),
-      mii_attach(),
-      (),
-      (),
-      (),
-      (),
-      (),
-      and
-      ()
-      should be eliminated. The device “ioctl” routine can use the
-      default handling with a callback for additional device-specific
-      programming (multicast filters, etc.), which can be empty, or, the
-      override ioctl can be used for heavier requirements. The device
-      “stop” routine is replaced with a simple call that turns off
-      the device-specific transmitter and receiver if necessary, as the
-      framework handles pipes and transfers and buffers.

-  
MII handling

-  
For devices with MII support the three normal callbacks (read, write, and
-      status change) must be converted to usbnet. Local
-      “link” variables need to be replaced with accesses to
-      usbnet_set_link() and
-      usbnet_havelink(). Other ifmedia callbacks that
-      were passed to ifmedia_init() should be deleted
-      and any work moved into “uno_statchg”.

-  
Receive and Transmit

-  
The usbnet framework handles the majority of
-      handling of both network directions. The interface init routine should
-      keep all of the device-specific setup but replace all pipe management with
-      a call to
-      ().
-      The typical receive handling will normally be replaced with a receive loop
-      function that can accept one or more packets, “uno_rx_loop”,
-      which can use either usbnet_enqueue() or
-      usbnet_input() to pass the packets up to higher
-      layers. The typical interface “if_start” function and any
-      additional functions used will normally be replaced with a relatively
-      simple “uno_tx_prepare” function that simply converts an
-      mbuf into a usbnet_chain
-      useful for this device that will be passed onto
-      ().
-      The framework's handling of the Tx interrupt is all internal.

-  
Interrupt pipe handling

-  
For devices requiring special handling of the interrupt pipe (i.e., they
-      use the usbd_open_pipe_intr() method), most of the
-      interrupt handler should be deleted, leaving only code that inspects the
-      result of the interrupt transfer.

-  
Common errors

-  
It's common to forget to set link active on devices with MII. Be sure to
-      call usbnet_set_link() during any status change
-      event.
-    
Many locking issues are hidden without
-        LOCKDEBUG, including hard-hangs. It's highly
-        recommended to develop with LOCKDEBUG.

-    
The usbnet “un_ed” array
-        is unsigned and should use “0” as the no-endpoint
-      value.

-  

-

-

-

-

-
usb(4), driver(9),
-    usbd_status(9), usbdi(9)

-

-

-

-
This usbnet interface first appeared in
-    NetBSD 9.0. Portions of the original design are
-    based upon ideas from Nick Hudson
-    <skrll@NetBSD.org>.

-

-

-

-
Matthew R. Green
-    <mrg@eterna23.net>

-

-

-
-  
-    
-    
-  
-
March 15, 2020NetBSD 10.1

diff --git a/static/netbsd/man9/uvm.9 3.html b/static/netbsd/man9/uvm.9 3.html
deleted file mode 100644
index 19108045..00000000
--- a/static/netbsd/man9/uvm.9 3.html	
+++ /dev/null
@@ -1,580 +0,0 @@
-
-  
-    
-    
-    
-  
-
UVM(9)Kernel Developer's ManualUVM(9)

-

-

-

-
uvm — virtual
-    memory system external interface

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <uvm/uvm.h>

-

-

-

-
The UVM virtual memory system manages access to the computer's
-    memory resources. User processes and the kernel access these resources
-    through UVM's external interface. UVM's external interface includes
-    functions that:

-

-
    
-  
  • initialize UVM sub-systems
    • 
-  
  • manage virtual address spaces
    • 
-  
  • resolve page faults
    • 
-  
  • memory map files and devices
    • 
-  
  • perform uio-based I/O to virtual memory
    • 
-  
  • allocate and free kernel virtual memory
    • 
-  
  • allocate and free physical memory
    • 
-

-
In addition to exporting these services, UVM has two kernel-level
-    processes: pagedaemon and swapper. The pagedaemon process sleeps until
-    physical memory becomes scarce. When that happens, pagedaemon is awoken. It
-    scans physical memory, paging out and freeing memory that has not been
-    recently used. The swapper process swaps in runnable processes that are
-    currently swapped out, if there is room.

-
There are also several miscellaneous functions.

-

-

-

-

-  
void

-  
(void);

-  
void

-  
uvm_init_limits(struct lwp
-      *l);

-  
void

-  
uvm_setpagesize(void);

-  
void

-  
uvm_swap_init(void);

-

-
()
-    sets up the UVM system at system boot time, after the console has been
-    setup. It initializes global state, the page, map, kernel virtual memory
-    state, machine-dependent physical map, kernel memory allocator, pager and
-    anonymous memory sub-systems, and then enables paging of kernel objects.

-
()
-    initializes process limits for the named process. This is for use by the
-    system startup for process zero, before any other processes are created.

-
()
-    does early boot initialization. This currently includes:
-    ()
-    which initializes the uvmexp members pagesize (if not already done by
-    machine-dependent code), pageshift and pagemask.
-    ()
-    which initialises the uvm_hotplug(9) subsystem. It should
-    be called by machine-dependent code early in the
-    ()
-    call (see pmap(9)).

-
()
-    initializes the swap sub-system.

-

-

-

-
See uvm_map(9).

-

-

-

-

-  
int

-  
uvm_fault(struct vm_map
-      *orig_map, vaddr_t vaddr,
-      vm_prot_t access_type);

-

-
()
-    is the main entry point for faults. It takes orig_map
-    as the map the fault originated in, a vaddr offset
-    into the map the fault occurred, and access_type
-    describing the type of access requested. uvm_fault()
-    returns a standard UVM return value.

-

-

-

-
See ubc(9).

-

-

-

-

-  
int

-  
uvm_io(struct vm_map *map,
-      struct uio *uio);

-

-
()
-    performs the I/O described in uio on the memory
-    described in map.

-

-

-

-
See uvm_km(9).

-

-

-

-

-  
struct vm_page *

-  
uvm_pagealloc(struct uvm_object
-      *uobj, voff_t off, struct
-      vm_anon *anon, int flags);

-  
void

-  
uvm_pagerealloc(struct vm_page
-      *pg, struct uvm_object *newobj,
-      voff_t newoff);

-  
void

-  
uvm_pagefree(struct vm_page
-      *pg);

-  
int

-  
uvm_pglistalloc(psize_t
-      size, paddr_t low, paddr_t
-      high, paddr_t alignment,
-      paddr_t boundary, struct pglist
-      *rlist, int nsegs, int
-      waitok);

-  
void

-  
uvm_pglistfree(struct pglist
-      *list);

-  
void

-  
uvm_page_physload(paddr_t
-      start, paddr_t end, paddr_t
-      avail_start, paddr_t avail_end,
-      int free_list);

-

-
()
-    allocates a page of memory at virtual address off in
-    either the object uobj or the anonymous memory
-    anon, which must be locked by the caller. Only one of
-    uobj and anon can be non
-    NULL. Returns NULL when no
-    page can be found. The flags can be any of

-

-
#define UVM_PGA_USERESERVE      0x0001  /* ok to use reserve pages */
-#define UVM_PGA_ZERO            0x0002  /* returned page must be zero'd */

-

-
UVM_PGA_USERESERVE means to allocate a
-    page even if that will result in the number of free pages being lower than
-    uvmexp.reserve_pagedaemon (if the current thread is
-    the pagedaemon) or uvmexp.reserve_kernel (if the
-    current thread is not the pagedaemon). UVM_PGA_ZERO
-    causes the returned page to be filled with zeroes, either by allocating it
-    from a pool of pre-zeroed pages or by zeroing it in-line as necessary.

-
()
-    reallocates page pg to a new object
-    newobj, at a new offset
-  newoff.

-
()
-    frees the physical page pg. If the content of the page
-    is known to be zero-filled, caller should set
-    PG_ZERO in pg->flags so that the page allocator
-    will use the page to serve future UVM_PGA_ZERO
-    requests efficiently.

-
()
-    allocates a list of pages for size size byte under
-    various constraints. low and
-    high describe the lowest and highest addresses
-    acceptable for the list. If alignment is non-zero, it
-    describes the required alignment of the list, in power-of-two notation. If
-    boundary is non-zero, no segment of the list may cross
-    this power-of-two boundary, relative to zero. nsegs is
-    the maximum number of physically contiguous segments. If
-    waitok is non-zero, the function may sleep until
-    enough memory is available. (It also may give up in some situations, so a
-    non-zero waitok does not imply that
-    uvm_pglistalloc() cannot return an error.) The
-    allocated memory is returned in the rlist list; the
-    caller has to provide storage only, the list is initialized by
-    uvm_pglistalloc().

-
()
-    frees the list of pages pointed to by list. If the
-    content of the page is known to be zero-filled, caller should set
-    PG_ZERO in pg->flags so that the page allocator
-    will use the page to serve future UVM_PGA_ZERO
-    requests efficiently.

-
()
-    loads physical memory segments into VM space on the specified
-    free_list. It must be called at system boot time to
-    set up physical memory management pages. The arguments describe the
-    start and end of the physical
-    addresses of the segment, and the available start and end addresses of pages
-    not already in use. If a system has memory banks of different speeds the
-    slower memory should be given a higher free_list
-    value.

-

-

-

-

-  
void

-  
uvm_pageout(void);

-  
void

-  
uvm_scheduler(void);

-

-
()
-    is the main loop for the page daemon.

-
()
-    is the process zero main loop, which is to be called after the system has
-    finished starting other processes. It handles the swapping in of runnable,
-    swapped out processes in priority order.

-

-

-

-

-  
int

-  
uvm_loan(struct vm_map *map,
-      vaddr_t start, vsize_t len,
-      void *v, int flags);

-  
void

-  
uvm_unloan(void *v,
-      int npages, int flags);

-

-
()
-    loans pages in a map out to anons or to the kernel.
-    map should be unlocked, start
-    and len should be multiples of
-    PAGE_SIZE. Argument flags
-    should be one of

-

-
#define UVM_LOAN_TOANON       0x01    /* loan to anons */
-#define UVM_LOAN_TOPAGE       0x02    /* loan to kernel */

-

-
v should be pointer to array
-    of pointers to struct anon or
-    struct vm_page, as appropriate. The caller has to
-    allocate memory for the array and ensure it's big enough to hold
-    len / PAGE_SIZE pointers. Returns 0 for success, or
-    appropriate error number otherwise. Note that wired pages can't be loaned
-    out and
-    ()
-    will fail in that case.

-
()
-    kills loans on pages or anons. The v must point to the
-    array of pointers initialized by previous call to
-    uvm_loan(). npages should
-    match number of pages allocated for loan, this also matches number of items
-    in the array. Argument flags should be one of

-

-
#define UVM_LOAN_TOANON       0x01    /* loan to anons */
-#define UVM_LOAN_TOPAGE       0x02    /* loan to kernel */

-

-
and should match what was used for previous call
-    to
-    ().

-

-

-

-

-  
struct uvm_object *

-  
uao_create(vsize_t size,
-      int flags);

-  
void

-  
uao_detach(struct uvm_object
-      *uobj);

-  
void

-  
uao_reference(struct uvm_object
-      *uobj);

-  
bool

-  
uvm_chgkprot(void *addr,
-      size_t len, int rw);

-  
void

-  
uvm_kernacc(void *addr,
-      size_t len, int rw);

-  
int

-  
uvm_vslock(struct vmspace
-      *vs, void *addr, size_t
-      len, vm_prot_t prot);

-  
void

-  
uvm_vsunlock(struct vmspace
-      *vs, void *addr, size_t
-      len);

-  
void

-  
uvm_meter(void);

-  
void

-  
uvm_proc_fork(struct proc
-      *p1, struct proc *p2, bool
-      shared);

-  
int

-  
uvm_grow(struct proc *p,
-      vaddr_t sp);

-  
void

-  
uvn_findpages(struct uvm_object
-      *uobj, voff_t offset, int
-      *npagesp, struct vm_page **pps,
-      int flags);

-  
void

-  
uvm_vnp_setsize(struct vnode
-      *vp, voff_t newsize);

-

-
The
-    (),
-    (),
-    and uao_reference() functions operate on anonymous
-    memory objects, such as those used to support System V shared memory.
-    uao_create() returns an object of size
-    size with flags:

-

-
#define UAO_FLAG_KERNOBJ        0x1     /* create kernel object */
-#define UAO_FLAG_KERNSWAP       0x2     /* enable kernel swap */

-

-
which can only be used once each at system boot
-    time.
-    ()
-    creates an additional reference to the named anonymous memory object.
-    ()
-    removes a reference from the named anonymous memory object, destroying it if
-    removing the last reference.

-
()
-    changes the protection of kernel memory from addr to
-    addr + len to the value of rw.
-    This is primarily useful for debuggers, for setting breakpoints. This
-    function is only available with options KGDB.

-
()
-    checks the access at address addr to
-    addr + len for rw access in the
-    kernel address space.

-
()
-    and
-    ()
-    control the wiring and unwiring of pages for process p
-    from addr to addr + len. These
-    functions are normally used to wire memory for I/O.

-
()
-    calculates the load average.

-
()
-    forks a virtual address space for process' (old) p1
-    and (new) p2. If the shared
-    argument is non zero, p1 shares its address space with p2, otherwise a new
-    address space is created. This function currently has no return value, and
-    thus cannot fail. In the future, this function will be changed to allow it
-    to fail in low memory conditions.

-
()
-    increases the stack segment of process p to include
-    sp.

-
()
-    looks up or creates pages in uobj at offset
-    offset, marks them busy and returns them in the
-    pps array. Currently uobj must
-    be a vnode object. The number of pages requested is pointed to by
-    npagesp, and this value is updated with the actual
-    number of pages returned. The flags can be any bitwise inclusive-or of:

-

-

-

-  

-  
Zero pseudo-flag meaning return all pages.

-  

-  
Don't sleep — yield NULL for busy pages or
-      for uncached pages for which allocation would sleep.

-  

-  
Don't allocate — yield NULL for uncached
-      pages.

-  

-  
Don't use cached pages — yield NULL
-      instead.

-  

-  
Don't yield read-only pages — yield NULL
-      for pages marked PG_READONLY.

-  

-  
Don't yield clean pages — stop early at the first clean one. As a
-      side effect, mark yielded dirty pages clean. Caller must write them to
-      permanent storage before unbusying.

-  

-  
Traverse pages in reverse order. If
-      ()
-      returns early, it will have filled
-      *npagesp entries at the end
-      of pps rather than the beginning.

-

-

-
()
-    sets the size of vnode vp to
-    newsize. Caller must hold a reference to the vnode. If
-    the vnode shrinks, pages no longer used are discarded.

-

-

-

-

-  
paddr_t

-  
atop(paddr_t pa);

-  
paddr_t

-  
ptoa(paddr_t pn);

-  
paddr_t

-  
round_page(address);

-  
paddr_t

-  
trunc_page(address);

-

-
The
-    () macro
-    converts a physical address pa into a page number. The
-    ()
-    macro does the opposite by converting a page number pn
-    into a physical address.

-
()
-    and
-    ()
-    macros return a page address boundary from rounding
-    address up and down, respectively, to the nearest page
-    boundary. These macros work for either addresses or byte counts.

-

-

-

-
UVM provides support for the CTL_VM domain
-    of the sysctl(3) hierarchy. It handles the
-    VM_LOADAVG, VM_METER,
-    VM_UVMEXP, and VM_UVMEXP2
-    nodes, which return the current load averages, calculates current VM totals,
-    returns the uvmexp structure, and a kernel version independent view of the
-    uvmexp structure, respectively. It also exports a number of tunables that
-    control how much VM space is allowed to be consumed by various tasks. The
-    load averages are typically accessed from userland using the
-    getloadavg(3) function. The uvmexp structure has all
-    global state of the UVM system, and has the following members:

-

-
/* vm_page constants */
-int pagesize;   /* size of a page (PAGE_SIZE): must be power of 2 */
-int pagemask;   /* page mask */
-int pageshift;  /* page shift */
-
-/* vm_page counters */
-int npages;     /* number of pages we manage */
-int free;       /* number of free pages */
-int paging;     /* number of pages in the process of being paged out */
-int wired;      /* number of wired pages */
-int reserve_pagedaemon; /* number of pages reserved for pagedaemon */
-int reserve_kernel; /* number of pages reserved for kernel */
-
-/* pageout params */
-int freemin;    /* min number of free pages */
-int freetarg;   /* target number of free pages */
-int inactarg;   /* target number of inactive pages */
-int wiredmax;   /* max number of wired pages */
-
-/* swap */
-int nswapdev;   /* number of configured swap devices in system */
-int swpages;    /* number of PAGE_SIZE'ed swap pages */
-int swpginuse;  /* number of swap pages in use */
-int nswget;     /* number of times fault calls uvm_swap_get() */
-int nanon;      /* number total of anon's in system */
-int nfreeanon;  /* number of free anon's */
-
-/* stat counters */
-int faults;             /* page fault count */
-int traps;              /* trap count */
-int intrs;              /* interrupt count */
-int swtch;              /* context switch count */
-int softs;              /* software interrupt count */
-int syscalls;           /* system calls */
-int pageins;            /* pagein operation count */
-                        /* pageouts are in pdpageouts below */
-int pgswapin;           /* pages swapped in */
-int pgswapout;          /* pages swapped out */
-int forks;              /* forks */
-int forks_ppwait;       /* forks where parent waits */
-int forks_sharevm;      /* forks where vmspace is shared */
-
-/* fault subcounters */
-int fltnoram;   /* number of times fault was out of ram */
-int fltnoanon;  /* number of times fault was out of anons */
-int fltpgwait;  /* number of times fault had to wait on a page */
-int fltpgrele;  /* number of times fault found a released page */
-int fltrelck;   /* number of times fault relock called */
-int fltrelckok; /* number of times fault relock is a success */
-int fltanget;   /* number of times fault gets anon page */
-int fltanretry; /* number of times fault retrys an anon get */
-int fltamcopy;  /* number of times fault clears "needs copy" */
-int fltnamap;   /* number of times fault maps a neighbor anon page */
-int fltnomap;   /* number of times fault maps a neighbor obj page */
-int fltlget;    /* number of times fault does a locked pgo_get */
-int fltget;     /* number of times fault does an unlocked get */
-int flt_anon;   /* number of times fault anon (case 1a) */
-int flt_acow;   /* number of times fault anon cow (case 1b) */
-int flt_obj;    /* number of times fault is on object page (2a) */
-int flt_prcopy; /* number of times fault promotes with copy (2b) */
-int flt_przero; /* number of times fault promotes with zerofill (2b) */
-
-/* daemon counters */
-int pdwoke;     /* number of times daemon woke up */
-int pdrevs;     /* number of times daemon rev'd clock hand */
-int pdfreed;    /* number of pages daemon freed since boot */
-int pdscans;    /* number of pages daemon scanned since boot */
-int pdanscan;   /* number of anonymous pages scanned by daemon */
-int pdobscan;   /* number of object pages scanned by daemon */
-int pdreact;    /* number of pages daemon reactivated since boot */
-int pdbusy;     /* number of times daemon found a busy page */
-int pdpageouts; /* number of times daemon started a pageout */
-int pddeact;    /* number of pages daemon deactivates */

-

-

-

-

-
uvm_chgkprot() is only available if the
-    kernel has been compiled with options KGDB.

-
All structure and types whose names begin with “vm_”
-    will be renamed to “uvm_”.

-

-

-

-
swapctl(2), getloadavg(3),
-    kvm(3), sysctl(3),
-    ddb(4), options(4),
-    memoryallocators(9), pmap(9),
-    ubc(9), uvm_km(9),
-    uvm_map(9)

-
Charles D. Cranor and
-    Gurudatta M. Parulkar, The UVM
-    Virtual Memory System, Proceedings of the USENIX
-    Annual Technical Conference, USENIX Association,
-    http://www.usenix.org/event/usenix99/full_papers/cranor/cranor.pdf,
-    117-130, June 6-11,
-    1999.

-

-

-

-
UVM is a new VM system developed at Washington University in St.
-    Louis (Missouri). UVM's roots lie partly in the Mach-based
-    4.4BSD VM system, the
-    FreeBSD VM system, and the SunOS 4 VM system. UVM's
-    basic structure is based on the 4.4BSD VM system.
-    UVM's new anonymous memory system is based on the anonymous memory system
-    found in the SunOS 4 VM (as described in papers published by Sun
-    Microsystems, Inc.). UVM also includes a number of features new to
-    BSD including page loanout, map entry passing,
-    simplified copy-on-write, and clustered anonymous memory pageout. UVM is
-    also further documented in an August 1998 dissertation by Charles D.
-  Cranor.

-
UVM appeared in NetBSD 1.4.

-

-

-

-
Charles D. Cranor
-    <chuck@ccrc.wustl.edu>
-    designed and implemented UVM.

-
Matthew Green
-    <mrg@eterna23.net>
-    wrote the swap-space management code and handled the logistical issues
-    involved with merging UVM into the NetBSD source
-    tree.

-
Chuck Silvers
-    <chuq@chuq.com>
-    implemented the aobj pager, thus allowing UVM to support System V shared
-    memory and process swapping.

-

-

-
-  
-    
-    
-  
-
March 23, 2015NetBSD 10.1

diff --git a/static/netbsd/man9/uvm_hotplug.9 3.html b/static/netbsd/man9/uvm_hotplug.9 3.html
deleted file mode 100644
index d42fe4b1..00000000
--- a/static/netbsd/man9/uvm_hotplug.9 3.html	
+++ /dev/null
@@ -1,443 +0,0 @@
-
-  
-    
-    
-    
-  
-
UVM_HOTPLUG(9)Kernel Developer's ManualUVM_HOTPLUG(9)

-

-

-

-
uvm_physseg_init,
-    uvm_physseg_valid_p,
-    uvm_physseg_get_start,
-    uvm_physseg_get_end,
-    uvm_physseg_get_avail_start,
-    uvm_physseg_get_avail_end,
-    uvm_physseg_get_pg,
-    uvm_physseg_get_pmseg,
-    uvm_physseg_get_free_list,
-    uvm_physseg_get_start_hint,
-    uvm_physseg_set_start_hint,
-    uvm_physseg_get_next,
-    uvm_physseg_get_prev,
-    uvm_physseg_get_first,
-    uvm_physseg_get_last,
-    uvm_physseg_get_highest_frame,
-    uvm_physseg_find,
-    uvm_page_physload,
-    uvm_page_physunload,
-    uvm_page_physunload_force,
-    uvm_physseg_plug,
-    uvm_physseg_unplug,
-    uvm_physseg_set_avail_start,
-    uvm_physseg_set_avail_end —
-    memory hotplug manager

-

-

-

-
#include
-    <uvm/uvm_physseg.h>

-
void
-  

-  uvm_physseg_init(void);

-
uvm_physseg_t
-  

-  uvm_page_physload(paddr_t
-    start, paddr_t end,
-    paddr_t avail_start,
-    paddr_t avail_end,
-    int free_list);

-
bool
-  

-  uvm_page_physunload(uvm_physseg_t
-    upm, int free_list,
-    paddr_t *paddrp);

-
bool
-  

-  uvm_page_physunload_force(uvm_physseg_t
-    upm, int free_list,
-    paddr_t *paddrp);

-
bool
-  

-  uvm_physseg_plug(paddr_t
-    pfn, size_t npages,
-    uvm_physseg_t *upmp);

-
bool
-  

-  uvm_physseg_unplug(paddr_t
-    pfn, size_t
-    npages);

-

-

-

-
These utility routines provide the ability to tell
-    uvm(9) about system memory segments. When the kernel is
-    compiled with 'options UVM_HOTPLUG', memory segments
-    are handled in a dynamic data structure (rbtree(3))
-    compared to a static array when not. This enables kernel code to add or
-    remove information about memory segments at any point after boot - thus
-    "hotplug".

-
(),
-    uvm_page_physunload(), and
-    uvm_page_physunload_force() are legacy interfaces
-    which may be removed in the future. They must never be used after
-    uvm_init(9).

-
:
-    This is an experimental feature and should not be used in production
-    environments. Furthermore, attempting to "hotplug" without
-    'options UVM_HOTPLUG' after boot will almost
-    certainly end in a panic(9).

-

-

-

-

-

-
The function
-    ()
-    initializes the hotplug subsystem. This is expected to happen exactly once,
-    at boot time, and from MD code.

-

-

-

-
uvm_page_physload() registers
-    uvm(9) with a memory segment span, and on a specified
-    free_list. It must be called at system boot time as
-    part of setting up memory management. The arguments describe the start and
-    end of the physical addresses of the segment, and the available start and
-    end addresses of pages not already in use. If a system has memory banks of
-    different speeds the slower memory should be given a higher
-    free_list value.

-

-

-  
start

-  
Starting page frame number of the physical memory segments.

-  
end

-  
Ending page frame number of the physical memory segments.

-  
avail_start

-  
Available starting page frame number of the physical memory segments.

-  
avail_end

-  
Available ending page frame number of the physical memory segments.

-  
free_list

-  
The free list types are defined in the Machine Dependent code.

-

-

-
This function returns a valid
-    uvm_physseg_t handle when a successful plug occurs,
-    else it will return UVM_PHYSSEG_TYPE_INVALID when
-    the plug fails.

-
()
-    registers uvm(9) with a memory segment span. It can also
-    be called to initiate a hotplug and register a newly "hotplugged"
-    physical memory range into the VM. Unlike
-    uvm_page_physload() this function can, if
-    'options UVM_HOTPLUG' is enabled at compile time, be
-    used after uvm_init(9). The arguments describe the start
-    page frame, the number of pages to plug starting from the start page frame
-    and an optional return variable, which points to a valid
-    uvm_physseg_t handle when a successful plug
-  occurs.

-

-

-  
pfn

-  
Starting page frame number of the physical memory segment.

-  
npages

-  
Total number of pages from the starting page frame number to plug in.

-  
upmp

-  
If upmp is not NULL, then on a successful plug, a
-      valid pointer to the uvm_physseg_t handle for the segment which was
-      plugged is returned.

-

-

-
This function returns true when a successful
-    plug occurs, false otherwise.

-

-

-

-
The functions
-    (),
-    uvm_page_physunload_force(), and
-    uvm_physseg_unplug() make uvm(9)
-    forget about previously registered memory segments or portions of such.

-
()
-    unloads pages from a segment (from the front or from the back) depending on
-    its availability. When the last page is removed, the segment handle is
-    invalidated and supporting metadata is freed.

-
Note: This function can only be used
-    during boot time. Pages, once unloaded, are unregistered from uvm and are
-    therefore assumed to be managed by the code which called
-    (9)
-    (usually boot time MD code, for boottime memory "allocation").

-
The arguments are:

-

-

-  
upm

-  
The handle identifying segment from which we are trying to unload
-    memory.

-  
free_list

-  
The free list types are defined in the Machine Dependent code.

-  
paddrp

-  
The pointer to the physical address that was unloaded.

-

-

-
If the unload was successful, true is
-    returned, false otherwise.

-
()
-    unconditionally unloads pages from a segment. When the last page is removed,
-    the segment handle is invalidated and supporting metadata is freed.

-
Note: This function can only be
-    used during boot time. Pages, once unloaded, are unregistered from uvm and
-    are therefore assumed to be managed by the code which called
-    (9)
-    (usually boot time MD code, for boottime memory "allocation").

-
The arguments are:

-

-

-  
upm

-  
The handle identifying segment from which we are trying to unload
-    memory.

-  
free_list

-  
The free list types are defined in the Machine Dependent code.

-  
paddrp

-  
The pointer to the physical address that was unloaded.

-

-

-
If the unload was successful true is
-    returned, false otherwise.

-
()
-    can be called to unplug an existing physical memory segment. Unlike
-    uvm_page_physunload() and
-    uvm_page_physunload_force(), it can be called after
-    uvm_init(9), if 'options
-    UVM_HOTPLUG' is enabled at compile time.
-    (9)
-    makes no effort to manage the state of the underlying physical memory. It is
-    up to the caller to ensure that it is not in use, either by
-    uvm(9), or by any other sub-system. Further, any hardware
-    quiescing that may be required is the responsibility of MD code. The
-    arguments describe the start page frame and the number of pages to unplug.
-    The arguments are:

-

-

-  
pfn

-  
Starting page frame number of the physical memory segment.

-  
npages

-  
Total number of pages from the starting page frame number to unplug.

-

-

-
Returns true or false
-    depending on success or failure respectively.

-

-

-

-

-

-  
bool

-  
(uvm_physseg_t
-      upm)

-  
paddr_t

-  
uvm_physseg_get_start(uvm_physseg_t
-      upm)

-  
paddr_t

-  
uvm_physseg_get_end(uvm_physseg_t
-      upm)

-  
paddr_t

-  
uvm_physseg_get_avail_start(uvm_physseg_t
-      upm)

-  
paddr_t

-  
uvm_physseg_get_avail_end(uvm_physseg_t
-      upm)

-  
struct vm_page *

-  
uvm_physseg_get_pg(uvm_physseg_t
-      upm, paddr_t index)

-  
struct pmap_physseg
-    *

-  
(uvm_physseg_t
-      upm)

-  
int

-  
uvm_physseg_get_free_list(uvm_physseg_t
-      upm)

-  
u_int

-  
uvm_physseg_get_start_hint(uvm_physseg_t
-      upm)

-  
bool

-  
uvm_physseg_set_start_hint(uvm_physseg_t
-      upm, u_int start_hint)

-  
uvm_physseg_t

-  
uvm_physseg_get_next(uvm_physseg_t
-      upm)

-  
uvm_physseg_t

-  
uvm_physseg_get_prev(uvm_physseg_t
-      upm)

-  
uvm_physseg_t

-  
uvm_physseg_get_first(void)

-  
uvm_physseg_t

-  
uvm_physseg_get_last(void)

-  
paddr_t

-  
uvm_physseg_get_highest_frame(void)

-  
paddr_t

-  
uvm_physseg_find(paddr
-      pframe, psize_t *offsetp)

-  
void

-  
uvm_physseg_set_avail_start(uvm_physseg_t
-      upm, paddr_t avail_start)

-  
void

-  
uvm_physseg_set_avail_end(uvm_physseg_t
-      upm, paddr_t avail_end)

-

-
()
-    validates a handle that is passed in, returns true if
-    the given handle is valid, false otherwise.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the starting physical address of the segment. The returned value is
-    of type paddr_t. In case the handle is invalid the
-    returned value will match (paddr_t) -1.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the ending physical address of the segment. The returned value is of
-    type paddr_t. In case the handle is invalid the
-    returned value will match (paddr_t) -1.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the available starting physical address of the segment. The returned
-    value is of type paddr_t. In case the handle is
-    invalid the returned value will match (paddr_t)
-  -1.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the available ending physical address of the segment. The returned
-    value is of type paddr_t. In case the handle is
-    invalid the returned value will match (paddr_t)
-  -1.

-
()
-    if a valid uvm_physseg_t handle along with an index
-    value is passed in, it returns the struct vm_page *
-    object contained in that location.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the struct pmap_physseg * object contained in
-    the handle.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the free_list type for which the current
-    segment is associated with. The returned value is of type
-    int.

-
()
-    if a valid uvm_physseg_t handle is passed in, it
-    returns the start_hint type for the current segment.
-    The returned value is of type u_int.

-
()
-    if a valid handle along with the start_hint is passed
-    in, the value is set in the segment. And a true is
-    returned to indicate a successful value setting. In case the handle is
-    invalid a false is returned.

-
()
-    if a valid handle is passed in, it returns the next valid
-    uvm_physseg_t handle in the sequence. However if the
-    handle passed is the last segment in the sequence the function returns
-    UVM_PHYSSEG_TYPE_INVALID_OVERFLOW. Passing an invalid
-    handle is not fatal, and returns
-    UVM_PHYSSEG_TYPE_INVALID.

-
()
-    if a valid handle is passed in, it returns the previous validh
-    uvm_physseg_t handle in the sequence. However if the
-    handle passed is the first segment in the sequence the function returns
-    UVM_PHYSSEG_TYPE_INVALID_EMPTY. Passing an invalid
-    handle is not fatal, and returns
-    UVM_PHYSSEG_TYPE_INVALID.

-
()
-    returns the first valid uvm_physseg_t handle in the
-    sequence. However if there are no valid handles in the sequence yet, the
-    function returns UVM_PHYSSEG_TYPE_INVALID_EMPTY.

-
()
-    returns the last valid uvm_physseg_t handle in the
-    sequence. However if there are no valid handles in the sequence yet, the
-    function returns UVM_PHYSSEG_TYPE_INVALID_EMPTY.

-
()
-    returns the frame number of the highest registered physical page frame which
-    is of type paddr_t. XXX: Searching on empty sequences
-    are not yet processed in the function.

-
()
-    searches for a given segment containing the page frame
-    (paddr_t) passed in. If a segment that falls between
-    starting and ending addresses is found, the corresponding
-    uvm_physseg_t handle is returned else a
-    UVM_PHYSSEG_TYPE_INVALID is returned. The second
-    parameter, if not set to NULL, the offset value of
-    the page frame passed in with respect to the starting address is set to the
-    appropriate psize_t value if the search was successful
-    in finding the segment.

-
()
-    if a valid uvm_physseg_t handle is passed in along
-    with the available starting physical address of the segment of type
-    paddr_t, the value is set in the segment.

-
()
-    if a valid uvm_physseg_t handle is passed in along
-    with the available ending physical address of the segment of type
-    paddr_t, the value is set in the segment.

-

-

-

-
uvm_physseg_plug() and
-    uvm_physseg_unplug() must never be used after
-    uvm_init(9) in a kernel build where
-    'options UVM_HOTPLUG' is not enabled.

-

-

-

-
Tests for uvm_physseg_init are in
-    tests/sys/uvm.

-
Unit / functional tests are in
-    tests/sys/uvm/t_uvm_physseg.c. These tests focus on
-    the expected working of the uvm_physseg_init API and
-    its utility functions.

-
Load tests can be found in
-    tests/sys/uvm/t_uvm_physseg_load.c. These tests
-    focus on stressing the uvm_physseg_init
-    implementation in order to make performance comparisons between kernel
-    builds with and without 'options UVM_HOTPLUG'

-

-

-

-
The uvm hotplug feature is implemented in the file
-    sys/uvm/uvm_physseg.c. The uvm hotplug API is
-    exported via sys/uvm/uvm_physseg.h.

-

-

-

-
extent(9), free(9),
-    malloc(9), memoryallocators(9),
-    uvm(9)

-

-

-

-
This API emerged out of the need to insert new pages at runtime in
-    the Xen x86/balloon(4) driver.

-

-

-

-
Cherry G. Mathew
-    <cherry@NetBSD.org>
-    designed and integrated the API.

-
Santhosh N. Raju
-    <santhosh.raju@gmail.com>
-    implemented the dynamic segment handling code and all tests for this
-  API.

-
Nick Hudson
-    <skrll@NetBSD.org>
-    contributed bugfixes and testing on a wide range of hardware ports.

-

-

-
-  
-    
-    
-  
-
January 17, 2020NetBSD 10.1

diff --git a/static/netbsd/man9/uvm_map.9 3.html b/static/netbsd/man9/uvm_map.9 3.html
deleted file mode 100644
index d50fc351..00000000
--- a/static/netbsd/man9/uvm_map.9 3.html	
+++ /dev/null
@@ -1,318 +0,0 @@
-
-  
-    
-    
-    
-  
-
UVM_MAP(9)Kernel Developer's ManualUVM_MAP(9)

-

-

-

-
uvm_map — virtual
-    address space management interface

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <uvm/uvm.h>

-
int
-  

-  uvm_map(struct
-    vm_map *map, vaddr_t
-    *startp, vsize_t
-    size, struct uvm_object
-    *uobj, voff_t
-    uoffset, vsize_t
-    align, uvm_flag_t
-    flags);

-
void
-  

-  uvm_unmap(struct
-    vm_map *map, vaddr_t
-    start, vaddr_t
-    end);

-
int
-  

-  uvm_map_pageable(struct
-    vm_map *map, vaddr_t
-    start, vaddr_t end,
-    bool new_pageable,
-    int lockflags);

-
bool
-  

-  uvm_map_checkprot(struct
-    vm_map *map, vaddr_t
-    start, vaddr_t end,
-    vm_prot_t
-  protection);

-
int
-  

-  uvm_map_protect(struct
-    vm_map *map, vaddr_t
-    start, vaddr_t end,
-    vm_prot_t new_prot,
-    bool set_max);

-
int
-  

-  uvm_map_protect_user(struct
-    lwp *l, vaddr_t
-    start, vaddr_t end,
-    vm_prot_t new_prot);

-
int
-  

-  uvm_deallocate(struct
-    vm_map *map, vaddr_t
-    start, vsize_t
-    size);

-
struct vmspace *
-  

-  uvmspace_alloc(vaddr_t
-    min, vaddr_t
-  max);

-
void
-  

-  uvmspace_exec(struct
-    lwp *l, vaddr_t
-    start, vaddr_t
-    end);

-
struct vmspace *
-  

-  uvmspace_fork(struct
-    vmspace *vm);

-
void
-  

-  uvmspace_free(struct
-    vmspace *vm);

-
void
-  

-  uvmspace_share(struct
-    proc *p1, struct proc
-    *p2);

-
vaddr_t
-  

-  uvm_uarea_alloc(void);

-
void
-  

-  uvm_uarea_free(vaddr_t
-    uaddr);

-
vaddr_t
-  

-  uvm_uarea_system_alloc(void);

-
void
-  

-  uvm_uarea_system_free(vaddr_t
-    uaddr);

-

-

-

-
The UVM facility for virtual address space management.

-

-

-

-
()
-    establishes a valid mapping in map map, which must be
-    unlocked. The new mapping has size size, which must be
-    a multiple of PAGE_SIZE.

-
The uobj and uoffset
-    arguments can have four meanings:

-
    
-  
  • When uobj is
-      NULL and uoffset is
-      UVM_UNKNOWN_OFFSET,
-      ()
-      does not use the machine-dependent PMAP_PREFER
-      function.
    • 
-  
  • When uobj is NULL and
-      uoffset is any other value, it is used as the hint
-      to PMAP_PREFER.
    • 
-  
  • When uobj is not NULL and
-      uoffset is
-      UVM_UNKNOWN_OFFSET,
-      uvm_map() finds the offset based upon the virtual
-      address, passed as startp.
    • 
-  
  • When uobj is not NULL and
-      uoffset is any other value, then a regular mapping
-      is performed at this offset. The start address of the map will be returned
-      in startp.
    • 
-

-If uobj is supplied, then
-  uvm_map()
-  
-  the caller's reference to uobj on success;
-  uvm_unmap() will release it when removing this
-  mapping. On failure, uvm_map() leaves the reference
-  count of uobj unmodified.
-
align specifies alignment of mapping unless
-    UVM_FLAG_FIXED is specified in
-    flags. align must be a power of
-    2.

-
flags passed to
-    ()
-    are typically created using the
-    (vm_prot_t
-    prot, vm_prot_t maxprot,
-    vm_inherit_t inh, int advice,
-    int flags) macro, which uses the following values.

-
The values that prot and
-    maxprot can take are:

-

-

-  
UVM_PROT_NONE

-  
No protection bits.

-  
UVM_PROT_R

-  
Read.

-  
UVM_PROT_W

-  
Write.

-  
UVM_PROT_X

-  
Exec.

-  
UVM_PROT_MASK

-  
Mask to extraction the protection bits.

-

-

-Additionally, the following constants for ORed values are available:
-  UVM_PROT_RW, UVM_PROT_RX,
-  UVM_PROT_WX and UVM_PROT_RWX.
-
The values that inh can take are:

-

-

-  
UVM_INH_SHARE

-  
Share the map.

-  
UVM_INH_COPY

-  
Copy the map.

-  
UVM_INH_NONE

-  
No inheritance.

-  
UVM_INH_MASK

-  
Mask to extract inherit flags.

-

-

-
The values that advice can take are:

-

-

-  
UVM_ADV_NORMAL

-  
"Normal" use.

-  
UVM_ADV_RANDOM

-  
"Random" access likelihood.

-  
UVM_ADV_SEQUENTIAL

-  
"Sequential" access likelihood.

-  
UVM_ADV_MASK

-  
Mask to extract the advice flags.

-

-

-
The values that flags can take are:

-

-

-  
UVM_FLAG_FIXED

-  
Attempt to map on the address specified by startp.
-      Otherwise, it is used just as a hint.

-  
UVM_FLAG_OVERLAY

-  
Establish overlay.

-  
UVM_FLAG_NOMERGE

-  
Do not merge map entries, if such merge is possible.

-  
UVM_FLAG_COPYONW

-  
Use copy-on-write i.e. do not fault in the pages immediately.

-  
UVM_FLAG_AMAPPAD

-  
Used for BSS: allocate larger amap, if extending is likely.

-  
UVM_FLAG_TRYLOCK

-  
Fail if cannot acquire the lock immediately.

-  
UVM_FLAG_NOWAIT

-  
Not allowed to sleep. Fail, in such case.

-  
UVM_FLAG_QUANTUM

-  
Indicates that map entry cannot be split once mapped.

-  
UVM_FLAG_WAITVA

-  
Sleep until VA space is available, if it is not.

-  
UVM_FLAG_VAONLY

-  
Unmap only VA space. Used by
-      ().

-  
UVM_FLAG_UNMAP

-  
Any existing entries in the range for this mapping should be unmapped as
-      part of creating the new mapping. Use of this flag without also specifying
-      UVM_FLAG_FIXED is a bug.

-

-

-
The UVM_MAPFLAG macro
-    arguments can be combined with an or operator. There are several special
-    purpose macros for checking protection combinations, e.g., the
-    UVM_PROT_WX. There are also some additional macros
-    to extract bits from the flags. The UVM_PROTECTION,
-    UVM_INHERIT,
-    UVM_MAXPROTECTION and
-    UVM_ADVICE macros return the protection,
-    inheritance, maximum protection, and advice, respectively.
-    ()
-    returns zero on success or error number otherwise.

-
()
-    removes a valid mapping, from start to
-    end, in map map, which must be
-    unlocked.

-
()
-    changes the pageability of the pages in the range from
-    start to end in map
-    map to new_pageable.
-    uvm_map_pageable() returns zero on success or error
-    number otherwise.

-
()
-    checks the protection of the range from start to
-    end in map map against
-    protection. This returns either
-    true or false.

-
()
-    changes the protection start to
-    end in map map to
-    new_prot, also setting the maximum protection to the
-    region to new_prot if set_max is
-    true. This function returns a standard UVM return value.

-
()
-    verifies that the new permissions honor PAX restrictions if applicable and
-    forwards to uvm_map_protect() on passing.

-
()
-    deallocates kernel memory in map map from address
-    start to start + size.

-
()
-    allocates and returns a new address space, with ranges from
-    min to max.

-
()
-    either reuses the address space of thread l (its
-    process) if there are no other references to it, or creates a new one with
-    uvmspace_alloc(). The range of valid addresses in
-    the address space is reset to start through
-    end.

-
()
-    creates and returns a new address space based upon the
-    vm address space, typically used when allocating an
-    address space for a child process.

-
()
-    lowers the reference count on the address space vm,
-    freeing the data structures if there are no other references.

-
()
-    causes process p2 to share the address space of
-    p1.

-
()
-    allocates memory for a u-area (i.e. kernel stack, PCB, etc) and returns the
-    address.

-
()
-    frees a u-area allocated with uvm_uarea_alloc().

-
()
-    and
-    ()
-    are optimized routines, which are used for kernel threads.

-

-

-

-
pmap(9), uvm(9),
-    uvm_km(9), vmem(9)

-

-

-

-
UVM and uvm_map first appeared in
-    NetBSD 1.4.

-

-

-
-  
-    
-    
-  
-
May 20, 2017NetBSD 10.1

diff --git a/static/netbsd/man9/vattr.9 3.html b/static/netbsd/man9/vattr.9 3.html
deleted file mode 100644
index 3b467fc3..00000000
--- a/static/netbsd/man9/vattr.9 3.html	
+++ /dev/null
@@ -1,98 +0,0 @@
-
-  
-    
-    
-    
-  
-
VATTR(9)Kernel Developer's ManualVATTR(9)

-

-

-

-
vattr, vattr_null
-    — vnode attributes

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/vnode.h>

-
void
-  

-  vattr_null(struct
-    vattr *vap);

-

-

-

-
Vnode attributes describe attributes of a file or directory
-    including file permissions, owner, group, size, access time and modification
-    time.

-
A vnode attribute has the following structure:

-

-
struct vattr {
-        enum vtype      va_type;        /* vnode type (for create) */
-        mode_t          va_mode;        /* files access mode and type */
-        nlink_t         va_nlink;       /* number of references to file */
-        uid_t           va_uid;         /* owner user id */
-        gid_t           va_gid;         /* owner group id */
-        dev_t           va_fsid;        /* file system id (dev for now) */
-        ino_t           va_fileid;      /* file id */
-        u_quad_t        va_size;        /* file size in bytes */
-        long            va_blocksize;   /* blocksize preferred for i/o */
-        struct timespec va_atime;       /* time of last access */
-        struct timespec va_mtime;       /* time of last modification */
-        struct timespec va_ctime;       /* time file changed */
-        struct timespec va_birthtime;   /* time file created */
-        u_long          va_gen;         /* generation number of file */
-        u_long          va_flags;       /* flags defined for file */
-        dev_t           va_rdev;        /* device the special file represents */
-        u_quad_t        va_bytes;       /* bytes of disk space held by file */
-        u_quad_t        va_filerev;     /* file modification number */
-        u_int           va_vaflags;     /* operations flags, see below */
-        long            va_spare;       /* remain quad aligned */
-};

-

-
A field value of VNOVAL represents a field whose
-    value is unavailable or which is not to be changed. Valid flag values for
-    
-  are:

-

-

-

-  
VA_UTIMES_NULL

-  
utimes argument was NULL

-  
VA_EXCLUSIVE

-  
exclusive create request

-

-

-
Vnode attributes for a file are set by the vnode operation
-    VOP_SETATTR(9). Vnode attributes for a file are retrieved
-    by the vnode operation VOP_GETATTR(9). For more
-    information on vnode operations see vnodeops(9).

-

-

-

-

-  
(vap)

-  
Set vnode attributes in vap to VNOVAL.

-

-

-

-

-
vattr_null() is implemented in
-    sys/kern/vfs_subr.c.

-

-

-

-
intro(9), vfs(9),
-    vnode(9), vnodeops(9)

-

-

-
-  
-    
-    
-  
-
January 8, 2010NetBSD 10.1

diff --git a/static/netbsd/man9/vfs.9 3.html b/static/netbsd/man9/vfs.9 3.html
deleted file mode 100644
index f5ce15c7..00000000
--- a/static/netbsd/man9/vfs.9 3.html	
+++ /dev/null
@@ -1,37 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFS(9)Kernel Developer's ManualVFS(9)

-

-

-

-
vfs — kernel
-    interface to file systems

-

-

-

-
The virtual file system, vfs, is the
-    kernel interface to file systems. The interface specifies the calls for the
-    kernel to access file systems. It also specifies the core functionality that
-    a file system must provide to the kernel.

-
The focus of vfs activity is
-    the  and is
-    discussed in vnode(9). File system operations such as
-    mounting and syncing are discussed in vfsops(9).

-

-

-

-
intro(9), vfsops(9),
-    vnode(9), vnodeops(9)

-

-

-
-  
-    
-    
-  
-
September 22, 2001NetBSD 10.1

diff --git a/static/netbsd/man9/vfsops.9 3.html b/static/netbsd/man9/vfsops.9 3.html
deleted file mode 100644
index 0466fe6d..00000000
--- a/static/netbsd/man9/vfsops.9 3.html	
+++ /dev/null
@@ -1,461 +0,0 @@
-
-  
-    
-    
-    
-  
-
VFSOPS(9)Kernel Developer's ManualVFSOPS(9)

-

-

-

-
vfsops, VFS_MOUNT,
-    VFS_START, VFS_UNMOUNT,
-    VFS_ROOT, VFS_QUOTACTL,
-    VFS_STATVFS, VFS_SYNC,
-    VFS_VGET, VFS_LOADVNODE,
-    VFS_NEWVNODE, VFS_FHTOVP,
-    VFS_VPTOFH, VFS_SNAPSHOT,
-    VFS_SUSPENDCTL — kernel file
-    system interface

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/vnode.h>

-
int
-  

-  VFS_MOUNT(struct mount *mp,
-    const char *path, void *data,
-    size_t *dlen);

-
int
-  

-  VFS_START(struct
-    mount *mp, int
-    flags);

-
int
-  

-  VFS_UNMOUNT(struct
-    mount *mp, int
-    mntflags);

-
int
-  

-  VFS_ROOT(struct
-    mount *mp, int
-    lktype, struct vnode
-    **vpp);

-
int
-  

-  VFS_QUOTACTL(struct
-    mount *mp, struct
-    quotactl_args *args);

-
int
-  

-  VFS_STATVFS(struct
-    mount *mp, struct statvfs
-    *sbp);

-
int
-  

-  VFS_SYNC(struct
-    mount *mp, int
-    waitfor, kauth_cred_t
-    cred);

-
int
-  

-  VFS_VGET(struct
-    mount *mp, ino_t
-    ino, int lktype,
-    struct vnode **vpp);

-
int
-  

-  VFS_LOADVNODE(struct
-    mount *mp, struct vnode
-    *vp, const void
-    *key, size_t
-    key_len, const void
-    **new_key);

-
int
-  

-  VFS_NEWVNODE(struct
-    mount *mp, struct vnode
-    *dvp, struct vnode
-    *vp, struct vattr
-    *vap, kauth_cred_t
-    cred, void *extra,
-    size_t *key_len,
-    const void
-  **new_key);

-
int
-  

-  VFS_FHTOVP(struct
-    mount *mp, struct fid
-    *fhp, int lktype,
-    struct vnode **vpp);

-
int
-  

-  VFS_VPTOFH(struct
-    vnode *vp, struct fid
-    *fhp, size_t
-    *fh_size);

-
int
-  

-  VFS_SNAPSHOT(struct
-    mount *mp, struct vnode
-    *vp, struct timespec
-    *ts);

-
int
-  

-  VFS_SUSPENDCTL(struct
-    mount *mp, int
-    cmd);

-

-

-

-
In a similar fashion to the vnode(9) interface,
-    all operations that are done on a file system are conducted through a single
-    interface that allows the system to carry out operations on a file system
-    without knowing its construction or type.

-
All supported file systems in the kernel have an entry in the
-    vfs_list_initial table. This table is generated by
-    config(1) and is a
-    NULL-terminated list of
-    vfsops structures. The vfsops structure describes the
-    operations that can be done to a specific file system type. The following
-    table lists the elements of the vfsops vector, the corresponding invocation
-    macro, and a description of the element.

-

-
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
int (*vfs_mount)()Mount a file system
int (*vfs_start)()Make operational
int (*vfs_unmount)()Unmount a file system
int (*vfs_root)()Get the file system root vnode
int (*vfs_quotactl)()Query/modify space quotas
int (*vfs_statvfs)()Get file system statistics
int (*vfs_sync)()Flush file system buffers
int (*vfs_vget)()Get vnode from file id
int (*vfs_loadvnode)()Initialize vnode with file
int (*vfs_newvnode)()Initialize vnode with new file
int (*vfs_fhtovp)()NFS file handle to vnode lookup
int (*vfs_vptofh)()Vnode to NFS file handle lookup
void (*vfs_init)()-Initialize file system
void (*vfs_reinit)()-Reinitialize file system
void (*vfs_done)()-Cleanup unmounted file system
int (*vfs_mountroot)()-Mount the root file system
int (*vfs_snapshot)()Take a snapshot
int (*vfs_suspendctl)()Suspend or resume

-
Some additional non-function members of the vfsops structure are
-    the file system name vfs_name and a reference count
-    vfs_refcount. It is not mandatory for a file system
-    type to support a particular operation, but it must assign each member
-    function pointer to a suitable function to do the minimum required of it. In
-    most cases, such functions either do nothing or return an error value to the
-    effect that it is not supported. vfs_reinit,
-    vfs_mountroot, vfs_fhtovp, and
-    vfs_vptofh may be NULL.

-
At system boot, each file system with an entry in
-    vfs_list_initial is established and initialized. Each
-    initialized file system is recorded by the kernel in the list
-    vfs_list and the file system specific initialization
-    function vfs_init in its vfsops vector is invoked.
-    When the file system is no longer needed vfs_done is
-    invoked to run file system specific cleanups and the file system is removed
-    from the kernel list.

-
At system boot, the root file system is mounted by invoking the
-    file system type specific vfs_mountroot function in
-    the vfsops vector. All file systems that can be mounted as a root file
-    system must define this function. It is responsible for initializing to list
-    of mount structures for all future mounted file systems.

-
Kernel state which affects a specific file system type can be
-    queried and modified using the sysctl(8) interface.

-

-

-

-

-  
(mp,
-    path, data,
-    dlen)

-  
Mount a file system specified by the mount structure
-      mp on the mount point described by
-      path. The argument data
-      contains file system type specific data, while the argument
-      dlen points to a location specifying the length of
-      the data.
-    
()
-        initializes the mount structure for the mounted file system. This
-        structure records mount-specific information for the file system and
-        records the list of vnodes associated with the file system. This
-        function is invoked both to mount new file systems and to change the
-        attributes of an existing file system. If the flag
-        MNT_UPDATE is set in
-        mp->mnt_flag, the file system should update its
-        state. This can be used, for instance, to convert a read-only file
-        system to read-write. The current attributes for a mounted file system
-        can be fetched by specifying MNT_GETARGS. If
-        neither MNT_UPDATE or
-        MNT_GETARGS are specified, a new file system
-        will attempted to be mounted.

-  

-  
VFS_START(mp,
-    flags)

-  
Make the file system specified by the mount structure
-      mp operational. The argument
-      flags is a set of flags for controlling the
-      operation of VFS_START(). This function is invoked
-      after VFS_MOUNT() and before the first access to
-      the file system.

-  
VFS_UNMOUNT(mp,
-    mntflags)

-  
Unmount a file system specified by the mount structure
-      mp. VFS_UNMOUNT() performs
-      any file system type specific operations required before the file system
-      is unmounted, such are flushing buffers. If
-      MNT_FORCE is specified in the flags
-      mntflags then open files are forcibly closed. The
-      function also deallocates space associated with data structure that were
-      allocated for the file system when it was mounted.

-  
VFS_ROOT(mp,
-    lktype, vpp)

-  
Get the root vnode of the file system specified by the mount structure
-      mp. The vnode is returned in the address given by
-      vpp, with lock type lktype.
-      lktype can be LK_NONE, or
-      LK_SHARED, or
-      LK_EXCLUSIVE. This function is used by the
-      pathname translation algorithms when a vnode that has been covered by a
-      mounted file system is encountered. While resolving the pathname, the
-      pathname translation algorithm will have to go through the directory tree
-      in the file system associated with that mount point and therefore requires
-      the root vnode of the file system.

-  
VFS_QUOTACTL(mp,
-    args)

-  
Query/modify user space quotas for the file system specified by the mount
-      structure mp. The argument structure provides the
-      operation ID and arguments to perform. This is the same interface as
-      documented in __quotactl(2) except that the file system
-      argument has been resolved. All copyin(9) and
-      copyout(9) processing is handled by code above the file
-      system.

-  
VFS_STATVFS(mp,
-    sbp)

-  
Get file system statistics for the file system specified by the mount
-      structure mp. A statvfs structure filled with the
-      statistics is returned in sbp.
-      VFS_STATVFS() is the file system type specific
-      implementation of the statvfs(2) and
-      fstatvfs(2) system calls.

-  
VFS_SYNC(mp,
-    waitfor, cred)

-  
Flush file system I/O buffers for the file system specified by the mount
-      structure mp. The waitfor
-      argument indicates whether a partial flush or complete flush should be
-      performed. The argument cred specifies the calling
-      credentials. VFS_SYNC() does not provide any
-      return value since the operation can never fail.

-  
VFS_VGET(mp,
-    ino, lktype,
-    vpp)

-  
Get vnode for a file system type specific file id
-      ino for the file system specified by the mount
-      structure mp, with lock type
-      lktype. lktype can be
-      LK_NONE, or LK_SHARED, or
-      LK_EXCLUSIVE. The vnode is returned in the address
-      specified vpp. The function is optional for file
-      systems which have a unique id number for every file in the file system.
-      It is used internally by the UFS file system and also by the NFSv3 server
-      to implement the READDIRPLUS NFS call. If the file system does not support
-      this function, it should return EOPNOTSUPP.

-  
VFS_LOADVNODE(mp,
-    vp, key,
-    key_len, new_key)

-  
Initialise the vnode vp with the file identified by
-      the arguments key and key_len
-      for the file system specified by the mount structure
-      mp.
-    
The new key is returned in the address specified by
-        new_key.

-    
Caller of this function assures no other thread will try to
-        load this file.

-  

-  
(mp,
-    dvp, vp,
-    vap, cred,
-    extra, key_len,
-    new_key)

-  
Initialise the vnode vp with a new file for the file
-      system specified by the mount structure mp.
-    
The argument dvp points to the directory
-        to create the file in.

-    
The argument vap points to the
-        attributes for the file to create.

-    
The argument cred holds the credentials
-        for the file to create.

-    
The argument extra allows the caller to
-        pass more information about the file to create.

-    
The key for the file is returned in the addresses specified by
-        key_len and new_key.

-  

-  
(mp,
-    fhp, lktype,
-    vpp)

-  
Get the vnode for the file handle fhp in the file
-      system specified by the mount structure mp, with
-      lock type lktype. lktype can
-      be LK_NONE, or LK_SHARED,
-      or LK_EXCLUSIVE. The locked vnode is returned in
-      vpp.
-    
When exporting, the call to
-        ()
-        should follow a call to
-        (),
-        which checks if the file is accessible to the client.

-    
If file handles are not supported by the file system, this
-        function must return EOPNOTSUPP.

-  

-  
(vp,
-    fhp, fh_size)

-  
Get a file handle for the vnode specified by vp. The
-      file handle is returned in fhp. The contents of the
-      file handle are defined by the file system and are not examined by any
-      other subsystems. It should contain enough information to uniquely
-      identify a file within the file system as well as noticing when a file has
-      been removed and the file system resources have been recycled for a new
-      file.
-    
The parameter fh_size points to the
-        container size for the file handle. This parameter should be updated to
-        the size of the finished file handle. Note that it is legal to call this
-        function with fhp set to
-        NULL in case fh_size is
-        zero. In case fh_size indicates a storage space
-        too small, the storage space required for the file handle corresponding
-        to vp should be filled in and
-        E2BIG should be returned.

-    
If file handles are not supported by the file system, this
-        function must return EOPNOTSUPP.

-  

-  
(mp,
-    vp, ts)

-  
Take a snapshot of the file system specified by the mount structure
-      mp and make it accessible through the locked vnode
-      vp. If ts is not
-      NULL it will receive the time this snapshot was
-      taken. If the file system does not support this function, it should return
-      EOPNOTSUPP.

-  
VFS_SUSPENDCTL(mp,
-    cmd)

-  
Suspend or resume all operations on this file system.
-      cmd is either
-      SUSPEND_SUSPEND to suspend or
-      SUSPEND_RESUME to resume operations. If the file
-      system does not support this function, it should return
-      EOPNOTSUPP.

-

-

-

-

-
The vfs operations are implemented within the files
-    sys/kern/vfs_subr.c and
-    sys/kern/vfs_init.c.

-

-

-

-
intro(9), namei(9),
-    vfs(9), vfssubr(9),
-    vnode(9), vnodeops(9)

-

-

-

-
The vfs operations vector, its functions and the corresponding
-    macros appeared in 4.3BSD.

-

-

-
-  
-    
-    
-  
-
August 7, 2020NetBSD 10.1

diff --git a/static/netbsd/man9/video.9 3.html b/static/netbsd/man9/video.9 3.html
deleted file mode 100644
index 8177e9c8..00000000
--- a/static/netbsd/man9/video.9 3.html	
+++ /dev/null
@@ -1,182 +0,0 @@
-
-  
-    
-    
-    
-  
-
VIDEO(9)Kernel Developer's ManualVIDEO(9)

-

-

-

-
video — interface
-    between low and high level video drivers

-

-

-

-
#include
-    <dev/video_if.h>

-
device_t
-  

-  video_attach_mi(const
-    struct video_hw_if *hw_if,
-    device_t hw_dev);

-
void
-  

-  video_submit_payload(device_t
-    vl_dev, const struct
-    video_payload *payload);

-

-

-

-
The video device driver is divided into a high level, machine
-    independent layer, and a low level hardware dependent layer. The interface
-    between these is the video_hw_if structure function
-    pointers called by the video layer, and video layer functions called by the
-    hardware driver.

-
The high level video driver attaches to the low level driver when
-    the latter calls video_attach_mi. The
-    video_hw_if struct is as shown below.
-    dev is the device struct for the hardware device.
-    Return value is the video layer device.

-

-
struct video_hw_if {
-	int	(*open)(void *, int); /* open hardware */
-	void	(*close)(void *);     /* close hardware */
-
-	const char *	(*get_devname)(void *);
-
-	int	(*enum_format)(void *, uint32_t, struct video_format *);
-	int	(*get_format)(void *, struct video_format *);
-	int	(*set_format)(void *, struct video_format *);
-	int	(*try_format)(void *, struct video_format *);
-
-	int	(*start_transfer)(void *);
-	int	(*stop_transfer)(void *);
-
-	int	(*control_iter_init)(void *, struct video_control_iter *);
-	int	(*control_iter_next)(void *, struct video_control_iter *);
-	int	(*get_control_desc_group)(void *,
-					  struct video_control_desc_group *);
-	int	(*get_control_group)(void *, struct video_control_group *);
-	int	(*set_control_group)(void *, const struct video_control_group *);
-};

-

-
The upper layer of the video driver allocates buffers for video
-    samples. The hardware driver submits data to the video layer with
-    video_submit_payload. vl_dev is
-    the video layer device returned by
-  video_attach_mi.

-

-
struct video_payload {
-	const uint8_t	*data;
-	size_t		size;
-	int		frameno;
-	bool		end_of_frame;
-};

-

-

-  
data

-  
Pointer to the video data for this payload. This may only be a portion of
-      the data in one video sample or frame.

-  
size

-  
Size in bytes of the video data in this payload

-  
frameno

-  
Frame number to which this payload belongs. The hardware driver must
-      toggle the frame number between 0 and 1 so the video layer can detect
-      sample or frame boundaries.

-  
end_of_frame

-  
Optional end of frame marker. If the hardware layer sets this, the video
-      layer can immediately pass the completed sample or frame to userspace
-      rather than waiting for the next payload to toggle
-      frameno.

-

-

-

-

-
The fields of video_hw_if are described in
-    some more detail below. Some fields are optional and can be set to
-    NULL if not needed.

-

-  

-  
optional, is called when the video device is opened. It should initialize
-      the hardware for I/O. Every successful call to open
-      is matched by a call to close. Return 0 on success,
-      otherwise an error code.

-  

-  
optional, is called when the audio device is closed.

-  

-  
mandatory, returns a NUL-terminated string naming the device, e.g. a
-      vendor and product model name.

-  

-  
mandatory, called with an index from 0 to
-      max_index - 1. Fills format
-      with the format description at that index. Returns 0 on success, otherwise
-      an error code.

-  

-  
mandatory, fills format with the current video
-      format. There should be a default format so this function works before and
-      streaming has begun. Returns 0 on success, otherwise an error code.

-  

-  
mandatory, sets the format of the video stream based on
-      format. Fills format with the
-      actual format used which may not be the same as requested. Returns 0 on
-      success, otherwise an error code.

-  

-  
optional, like set_format but does not actually
-      change the stream format, just checks what is available. Returns 0 on
-      success, otherwise an error code.

-  

-  
mandatory, starts the capture of video frames. Incoming video data must be
-      submitted to the video layer with repeated calls to
-      ().

-  

-  
 

-  

-  
Does nothing at this time.

-  

-  
Does nothing at this time.

-  

-  
 

-  

-  
 

-

-

-

-

-
video(4)

-

-

-

-
Patrick Mahoney
-    <pat@polycrystal.org>

-

-

-

-
Incomplete. Only supports a single video capture stream. Does not
-    support output streams. Format handling may change in the future. Control
-    handling may change. Current design requires copying all incoming video
-    data.

-

-

-
-  
-    
-    
-  
-
July 24, 2008NetBSD 10.1

diff --git a/static/netbsd/man9/vnodeops.9 3.html b/static/netbsd/man9/vnodeops.9 3.html
deleted file mode 100644
index 17e8c6f5..00000000
--- a/static/netbsd/man9/vnodeops.9 3.html	
+++ /dev/null
@@ -1,1441 +0,0 @@
-
-  
-    
-    
-    
-  
-
VNODEOPS(9)Kernel Developer's ManualVNODEOPS(9)

-

-

-

-
vnodeops,
-    VOP_LOOKUP, VOP_CREATE,
-    VOP_MKNOD, VOP_OPEN,
-    VOP_CLOSE, VOP_ACCESS,
-    VOP_GETATTR, VOP_SETATTR,
-    VOP_READ, VOP_WRITE,
-    VOP_FALLOCATE, VOP_FDISCARD,
-    VOP_IOCTL, VOP_FCNTL,
-    VOP_POLL, VOP_KQFILTER,
-    VOP_REVOKE, VOP_MMAP,
-    VOP_FSYNC, VOP_SEEK,
-    VOP_REMOVE, VOP_LINK,
-    VOP_RENAME, VOP_MKDIR,
-    VOP_RMDIR, VOP_SYMLINK,
-    VOP_READDIR, VOP_READLINK,
-    VOP_ABORTOP, VOP_INACTIVE,
-    VOP_RECLAIM, VOP_LOCK,
-    VOP_UNLOCK, VOP_ISLOCKED,
-    VOP_BMAP, VOP_PRINT,
-    VOP_PATHCONF, VOP_ADVLOCK,
-    VOP_WHITEOUT, VOP_GETPAGES,
-    VOP_PUTPAGES, VOP_STRATEGY,
-    VOP_BWRITE, VOP_GETEXTATTR,
-    VOP_SETEXTATTR,
-    VOP_LISTEXTATTR,
-    VOP_DELETEEXTATTR — vnode
-    operations

-

-

-

-
#include
-    <sys/param.h>
-  

-  #include <sys/buf.h>
-  

-  #include <sys/dirent.h>
-  

-  #include <sys/vnode.h>
-  

-  #include <sys/mount.h>
-  

-  #include <sys/namei.h>
-  

-  #include <sys/unistd.h>
-  

-  #include <sys/fcntl.h>
-  

-  #include <sys/lockf.h>
-  

-  #include <sys/extattr.h>

-
int
-  

-  VOP_LOOKUP(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp);

-
int
-  

-  VOP_CREATE(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap);

-
int
-  

-  VOP_MKNOD(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap);

-
int
-  

-  VOP_OPEN(struct
-    vnode *vp, int
-    mode, kauth_cred_t
-    cred);

-
int
-  

-  VOP_CLOSE(struct
-    vnode *vp, int
-    fflag, kauth_cred_t
-    cred);

-
int
-  

-  VOP_ACCESS(struct
-    vnode *vp, int
-    mode, kauth_cred_t
-    cred);

-
int
-  

-  VOP_GETATTR(struct
-    vnode *vp, struct vattr
-    *vap, kauth_cred_t
-    cred);

-
int
-  

-  VOP_SETATTR(struct
-    vnode *vp, struct vattr
-    *vap, kauth_cred_t
-    cred);

-
int
-  

-  VOP_READ(struct
-    vnode *vp, struct uio
-    *uio, int ioflag,
-    kauth_cred_t cred);

-
int
-  

-  VOP_WRITE(struct
-    vnode *vp, struct uio
-    *uio, int ioflag,
-    kauth_cred_t cred);

-
int
-  

-  VOP_FALLOCATE(struct
-    vnode *vp, off_t
-    pos, off_t
-  len);

-
int
-  

-  VOP_FDISCARD(struct
-    vnode *vp, off_t
-    pos, off_t
-  len);

-
int
-  

-  VOP_IOCTL(struct
-    vnode *vp, u_long
-    command, void
-    *data, int fflag,
-    kauth_cred_t cred);

-
int
-  

-  VOP_FCNTL(struct
-    vnode *vp, u_int
-    command, void
-    *data, int fflag,
-    kauth_cred_t cred);

-
int
-  

-  VOP_POLL(struct
-    vnode *vp, int
-    events);

-
int
-  

-  VOP_KQFILTER(struct
-    vnode *vp, struct knote
-    *kn);

-
int
-  

-  VOP_REVOKE(struct
-    vnode *vp, int
-    flags);

-
int
-  

-  VOP_MMAP(struct
-    vnode *vp, vm_prot_t
-    prot, kauth_cred_t
-    cred);

-
int
-  

-  VOP_FSYNC(struct
-    vnode *vp, kauth_cred_t
-    cred, int flags,
-    off_t offlo,
-    off_t offhi);

-
int
-  

-  VOP_SEEK(struct
-    vnode *vp, off_t
-    oldoff, off_t
-    newoff, kauth_cred_t
-    cred);

-
int
-  

-  VOP_REMOVE(struct
-    vnode *dvp, struct vnode
-    *vp, struct componentname
-    *cnp);

-
int
-  

-  VOP_LINK(struct
-    vnode *dvp, struct vnode
-    *vp, struct componentname
-    *cnp);

-
int
-  

-  VOP_RENAME(struct
-    vnode *fdvp, struct vnode
-    *fvp, struct
-    componentname *fcnp,
-    struct vnode *tdvp,
-    struct vnode *tvp,
-    struct componentname
-    *tcnp);

-
int
-  

-  VOP_MKDIR(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap);

-
int
-  

-  VOP_RMDIR(struct
-    vnode *dvp, struct vnode
-    *vp, struct componentname
-    *cnp);

-
int
-  

-  VOP_SYMLINK(struct
-    vnode *dvp, struct vnode
-    **vpp, struct
-    componentname *cnp,
-    struct vattr *vap,
-    char *target);

-
int
-  

-  VOP_READDIR(struct
-    vnode *vp, struct uio
-    *uio, kauth_cred_t
-    cred, int *eofflag,
-    off_t **cookies,
-    int *ncookies);

-
int
-  

-  VOP_READLINK(struct
-    vnode *vp, struct uio
-    *uio, kauth_cred_t
-    cred);

-
int
-  

-  VOP_ABORTOP(struct
-    vnode *dvp, struct
-    componentname *cnp);

-
int
-  

-  VOP_INACTIVE(struct
-    vnode *vp);

-
int
-  

-  VOP_RECLAIM(struct
-    vnode *vp);

-
int
-  

-  VOP_LOCK(struct
-    vnode *vp, int
-    flags);

-
int
-  

-  VOP_UNLOCK(struct
-    vnode *vp);

-
int
-  

-  VOP_ISLOCKED(struct
-    vnode *vp);

-
int
-  

-  VOP_BMAP(struct
-    vnode *vp, daddr_t
-    bn, struct vnode
-    **vpp, daddr_t
-    *bnp, int
-  *runp);

-
int
-  

-  VOP_PRINT(struct
-    vnode *vp);

-
int
-  

-  VOP_PATHCONF(struct
-    vnode *vp, int
-    name, register_t
-    *retval);

-
int
-  

-  VOP_ADVLOCK(struct
-    vnode *vp, void
-    *id, int op,
-    struct flock *fl,
-    int flags);

-
int
-  

-  VOP_WHITEOUT(struct
-    vnode *dvp, struct
-    componentname *cnp, int
-    flags);

-
int
-  

-  VOP_GETPAGES(struct
-    vnode *vp, voff_t
-    offset, struct vm_page
-    **m, int *count,
-    int centeridx,
-    vm_prot_t access_type,
-    int advice,
-    int flags);

-
int
-  

-  VOP_PUTPAGES(struct
-    vnode *vp, voff_t
-    offlo, voff_t
-    offhi, int
-  flags);

-
int
-  

-  VOP_STRATEGY(struct
-    vnode *vp, struct buf
-    *bp);

-
int
-  

-  VOP_BWRITE(struct
-    vnode *vp, struct buf
-    *bp);

-
int
-  

-  VOP_GETEXTATTR(struct
-    vnode *vp, int
-    attrnamespace, const char
-    *name, struct uio
-    *uio, size_t *size,
-    kauth_cred_t cred);

-
int
-  

-  VOP_SETEXTATTR(struct
-    vnode *vp, int
-    attrnamespace, const char
-    *name, struct uio
-    *uio, kauth_cred_t
-    cred);

-
int
-  

-  VOP_LISTEXTATTR(struct
-    vnode *vp, int
-    attrnamespace, struct uio
-    *uio, size_t *size,
-    kauth_cred_t cred);

-
int
-  

-  VOP_DELETEEXTATTR(struct
-    vnode *vp, int
-    attrnamespace, const char
-    *name, kauth_cred_t
-    cred);

-
Not all header files are required for each function.

-

-

-

-
The vnode operations vector describes what operations can be done
-    to the file associated with the vnode. The system maintains one vnode
-    operations vector for each file system type configured into the kernel. The
-    vnode operations vector contains a pointer to a function for each operation
-    supported by the file system. Many of the functions described in the vnode
-    operations vector are closely related to their corresponding system calls.
-    In most cases, they are called as a result of the system call associated
-    with the operation being invoked.

-
Functions in the vnode operations vector are invoked using
-    specialized macros. The following table gives a summary of the
-  operations.

-

-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
VOP_LOOKUPLookup file name in name cache
VOP_CREATECreate a new file
VOP_MKNODMake a new device
VOP_OPENOpen a file
VOP_CLOSEClose a file
VOP_ACCESSDetermine file accessibility
VOP_GETATTRGet file attributes
VOP_SETATTRSet file attributes
VOP_READRead from a file
VOP_WRITEWrite to a file
VOP_FALLOCATEAllocate backing for a file
VOP_FDISCARDDiscard backing for a file
VOP_IOCTLPerform device-specific I/O
VOP_FCNTLPerform file control
VOP_POLLTest if poll event has occurred
VOP_KQFILTERRegister a knote
VOP_REVOKEEliminate vnode activity
VOP_MMAPMap file into user address space
VOP_FSYNCFlush pending data to disk
VOP_SEEKTest if file is seekable
VOP_REMOVERemove a file
VOP_LINKLink a file
VOP_RENAMERename a file
VOP_MKDIRMake a new directory
VOP_RMDIRRemove a directory
VOP_SYMLINKCreate a symbolic link
VOP_READDIRRead directory entry
VOP_READLINKRead contents of a symlink
VOP_ABORTOPAbort pending operation
VOP_INACTIVERelease the inactive vnode
VOP_RECLAIMReclaim vnode for another file
VOP_LOCKSleep until vnode lock is free
VOP_UNLOCKWake up process sleeping on lock
VOP_ISLOCKEDTest if vnode is locked
VOP_BMAPLogical block number conversion
VOP_PRINTPrint debugging information
VOP_PATHCONFReturn POSIX pathconf data
VOP_ADVLOCKAdvisory record locking
VOP_WHITEOUTWhiteout vnode
VOP_GETPAGESRead VM pages from file
VOP_PUTPAGESWrite VM pages to file
VOP_STRATEGYRead/write a file system buffer
VOP_BWRITEWrite a file system buffer
VOP_GETEXTATTRGet extended attribute
VOP_SETEXTATTRSet extended attribute
VOP_LISTEXTATTRList extended attributes
VOP_DELETEEXTATTRRemove extended attribute

-
The implementation details of the vnode operations vector are not
-    quite what is described here.

-
If the file system type does not support a specific operation, it
-    must nevertheless assign an appropriate stub in the vnode operations vector
-    to do the minimum required of it. In most cases, such functions either do
-    nothing or return an error value to the effect that it is not supported.

-
Many of the functions in the vnode operations vector take a
-    componentname structure. It is used to encapsulate many parameters into a
-    single function argument. It has the following structure:

-

-
struct componentname {
-        /*
-         * Arguments to lookup.
-         */
-        uint32_t cn_nameiop;    /* namei operation */
-        uint32_t cn_flags;      /* flags to namei */
-        kauth_cred_t cn_cred;   /* credentials */
-        /*
-         * Shared between lookup and commit routines.
-         */
-        const char *cn_nameptr; /* pointer to looked up name */
-        size_t  cn_namelen;     /* length of looked up component */
-        size_t  cn_consume;     /* chars to consume in lookup() */
-};

-

-
The top half of the structure is used exclusively
-    for the pathname lookups using
-    ()
-    and is initialized by the caller. The semantics of the lookup are affected
-    by the lookup operation specified in
-    
-    and the flags specified in
-    .
-    Valid operations are:

-

-

-

-  
LOOKUP

-  
perform name lookup only

-  
CREATE

-  
set up for file creation

-  
DELETE

-  
set up for file deletion

-  
RENAME

-  
set up for file renaming

-  
OPMASK

-  
mask for operation

-

-

-
Valid values for
-    
-    are:

-

-

-

-  
LOCKLEAF

-  
lock inode on return

-  
LOCKPARENT

-  
want parent vnode returned locked

-  
NOCACHE

-  
name must not be left in name cache (see
-    namecache(9))

-  
FOLLOW

-  
follow symbolic links

-  
NOFOLLOW

-  
do not follow symbolic links (pseudo)

-  
MODMASK

-  
mask of operational modifiers

-

-

-
No vnode operations may be called from interrupt context. Most
-    operations also require the vnode to be locked on entry. To prevent
-    deadlocks, when acquiring locks on multiple vnodes, the lock of parent
-    directory must be acquired before the lock on the child directory.

-
Vnode operations for a file system type generally should not be
-    called directly from the kernel, but accessed indirectly through the
-    high-level convenience functions discussed in
-  vnsubr(9).

-

-

-

-

-  
(dvp,
-    vpp, cnp)

-  
Lookup a single pathname component in a given directory. The argument
-      dvp is the locked vnode of the directory to search
-      and cnp is the pathname component to be searched
-      for. If the pathname component is found, the address of the resulting
-      unlocked vnode is returned in vpp. The operation
-      specified in
-      
-      indicates VOP_LOOKUP() the reason for requesting
-      the lookup and uses it to cache file system type specific information in
-      the vnode for subsequent operations.
-    
There are three types of lookups:
-        ".", ".." (ISDOTDOT), and regular. If the pathname
-        component being searched for is ".", then
-        dvp has an extra reference added to it and it is
-        returned in *vpp. For other pathname components,
-        ()
-        checks the accessibility of the directory and searches the name cache
-        for the pathname component. See namecache(9). If the
-        pathname is not found in the name cache, the directory is searched for
-        the pathname. The resulting unlocked vnode is returned in
-        vpp. dvp is always returned
-        locked.

-    
On failure *vpp is
-        NULL, and *dvp is left
-        locked. If the operation is successful *vpp is
-        unlocked and zero is returned. Typically, if *vpp
-        and dvp are the same vnode the caller will need to
-        release twice (decrement the reference count) and unlock once.

-  

-  
(dvp,
-    vpp, cnp,
-    vap)

-  
Create a new file in a given directory. The argument
-      dvp is the locked vnode of the directory to create
-      the new file in and cnp is the pathname component of
-      the new file. The argument vap specifies the
-      attributes that the new file should be created with. If the file is
-      successfully created, the address of the resulting unlocked vnode is
-      returned in vpp and zero is returned.
-    
This function is called after
-        ()
-        when a file is being created. Normally,
-        VOP_LOOKUP() will have set the SAVENAME flag in
-        cnp->cn_flags to keep the memory pointed to by
-        cnp->cn_pnbuf valid. If an error is detected when
-        creating the file, this memory is released. If the file is created
-        successfully it will be released unless the SAVESTART flags in specified
-        in cnp->cn_flags.

-  

-  
(dvp,
-    vpp, cnp,
-    vap)

-  
Make a new device-special file in a given directory. The argument
-      dvp is the locked vnode of the directory to create
-      the new device-special file in and cnp is the
-      pathname component of the new device-special file. The argument
-      vap specifies the attributes that the new
-      device-special file should be created with. If the file is successfully
-      created, the address of the resulting unlocked vnode is returned in
-      vpp and zero is returned.
-    
This function is called after
-        ()
-        when a device-special file is being created. Normally,
-        VOP_LOOKUP() will have set the SAVENAME flag in
-        cnp->cn_flags to keep the memory pointed to by
-        cnp->cn_pnbuf valid. If an error is detected when
-        creating the device-special file, this memory is released. If the
-        device-special file is created successfully it will be released unless
-        the SAVESTART flags in specified in
-      cnp->cn_flags.

-  

-  
VOP_OPEN(vp,
-    mode, cred)

-  
Open a file. The argument vp is the vnode of the
-      file to open and mode specifies the access mode
-      required by the calling process. The calling credentials are specified by
-      cred. The access mode is a set of flags, including
-      FREAD, FWRITE, O_NONBLOCK, O_APPEND, etc.
-      VOP_OPEN() must be called before a file can be
-      accessed by a thread. The vnode reference count is incremented.
-    
()
-        expects the vnode vp to be locked on entry and
-        will leave it locked on return. If the operation is successful zero is
-        returned, otherwise an appropriate error code is returned.

-  

-  
(vp,
-    fflag, cred)

-  
Close a file. The argument vp is the vnode of the
-      file to close and fflag specifies the access mode by
-      the calling process. The possible flags are FREAD,
-      FWRITE and FNONBLOCK. The
-      calling credentials are specified by cred.
-      VOP_CLOSE() frees resources allocated by
-      VOP_OPEN().
-    
The vnode vp will be locked on entry and
-        should remain locked on return.

-  

-  
(vp,
-    mode, cred)

-  
Determine the accessibility (permissions) of the file against the
-      specified credentials. The argument vp is the vnode
-      of the file to check, mode is the type of access
-      required and cred contains the user credentials to
-      check. The argument mode is a mask which can contain
-      VREAD, VWRITE or VEXEC. If the file is accessible in the specified way,
-      zero is returned, otherwise an appropriate error code is returned.
-    
The vnode vp will be locked on entry and
-        should remain locked on return.

-  

-  
(vp,
-    vap, cred)

-  
Get specific vnode attributes on a file. The argument
-      vp is the vnode of the file to get the attributes
-      for. The argument cred specifies the calling
-      credentials. VOP_GETATTR() uses the file system
-      type specific data object vp->v_data to reference the
-      underlying file attributes. The attributes are returned in
-      vap. Attributes which are not available are set to
-      the value VNOVAL.
-    
For more information on vnode attributes
-        see vattr(9). Historically it was considered
-        acceptable to call
-        ()
-        without first locking the vnode. This usage is deprecated.

-    
The vnode vp will be locked on entry and
-        should remain locked on return.

-  

-  
(vp,
-    vap, cred)

-  
Set specific vnode attributes on a file. The argument
-      vp is the locked vnode of the file to set the
-      attributes for. The argument cred specifies the
-      calling credentials. VOP_SETATTR() uses the file
-      system type specific data object vp->v_data to
-      reference the underlying file attributes. The new attributes are defined
-      in vap. Attributes which are not being modified by
-      VOP_SETATTR() should be set to the value VNOVAL.
-      If the operation is successful zero is returned, otherwise an appropriate
-      error is returned.
-    
For more information on vnode attributes see
-        vattr(9).

-  

-  
(vp,
-    uio, ioflag,
-    cred)

-  
Read the contents of a file. The argument vp is the
-      vnode of the file to read from, uio is the location
-      to read the data into, ioflag is a set of flags and
-      cred are the credentials of the calling process.
-    
The ioflag argument is used to give
-        directives and hints to the file system. When attempting a read, the
-        high 16 bits are used to provide a read-ahead hint (in unit of file
-        system blocks) that the file system should attempt. The low 16 bits are
-        a bit mask which can contain the following flags:

-    

-    

-    

-      
IO_UNIT

-      
do I/O as atomic unit

-      
IO_APPEND

-      
append write to end

-      
IO_SYNC

-      
sync I/O file integrity completion

-      
IO_NODELOCKED

-      
underlying node already locked

-      
IO_NDELAY

-      
FNDELAY flag set in file table

-      
IO_DSYNC

-      
sync I/O data integrity completion

-      
IO_ALTSEMANTICS

-      
use alternate I/O semantics

-      
IO_NORMAL

-      
operate on regular data

-      
IO_EXT

-      
operate on extended attributes

-      
IO_DIRECT

-      
do not buffer data in the kernel

-    

-    

-    
Zero is returned on success, otherwise an error is returned.
-        The vnode should be locked on entry and remains locked on exit.

-  

-  
(vp,
-    uio, ioflag,
-    cred)

-  
Write to a file. The argument vp is the vnode of the
-      file to write to, uio is the location of the data to
-      write, ioflag is a set of flags and
-      cred are the credentials of the calling process.
-    
The ioflag argument is
-        used to give directives and hints to the file system. The low 16 bits
-        are a bit mask which can contain the same flags as
-        ().

-    
Zero is returned on success, otherwise an error is returned.
-        The vnode should be locked on entry and remains locked on exit.

-  

-  
(vp,
-    pos, len)

-  
Allocate backing store. The argument vp is the vnode
-      for the file. The pos and len
-      arguments (specified in bytes) name an extent within the file. The blocks
-      underlying this range, rounding up at the top and down at the bottom if
-      needed, are checked; if no physical storage is allocated, a physical block
-      is allocated and zeroed. This operation removes “holes” from
-      files.

-  
(vp,
-    pos, len)

-  
Discard backing store. The argument vp is the vnode
-      for the file. The pos and len
-      arguments (specified in bytes) name an extent within the file. The blocks
-      underlying this range, rounding down at the top and up at the bottom if
-      needed, are checked. If any physical storage is used, it is deallocated.
-      This operation creates “holes” in files. Discarded blocks of
-      regular files read back afterwards as zeroes. On devices, the underlying
-      discard-block operation if any (e.g. ATA TRIM) is issued. The device
-      handles this as it sees fit. In particular it is
-      
-      guaranteed that discarded blocks on devices will be zeroed; reading a
-      discarded block might produce zeros, or ones, or the previously existing
-      data, or some other data, or trash.

-  
VOP_IOCTL(vp,
-    command, data,
-    fflag, cred)

-  
Perform device-specific I/O. The argument vp is the
-      vnode of the file, normally representing a device. The argument
-      command specifies the device-specific operation to
-      perform and cnp provides extra data for the
-      specified operation. The argument fflags is a set of
-      flags. The argument cred is the caller's
-      credentials. If the operation is successful, zero is returned, otherwise
-      an appropriate error code is returned.
-    
Most file systems do not supply a function for
-        ().
-        This function implements the ioctl(2) system call.

-  

-  
(vp,
-    command, data,
-    fflag, cred)

-  
Perform file control. The argument vp is the locked
-      vnode of the file. The argument command specifies
-      the operation to perform and cnp provides extra data
-      for the specified operation. The argument fflags is
-      a set of flags. The argument cred is the caller's
-      credentials. If the operation is successful, zero is returned, otherwise
-      an appropriate error code is returned.

-  
(vp,
-    events)

-  
Test if a poll event has occurred. The argument vp
-      is the vnode of the file to poll. It returns any events of interest as
-      specified by events that may have occurred for the
-      file. The argument events is a set of flags as
-      specified by poll(2).
-    
The vnode vp remains unlocked throughout
-        the whole operation.

-  

-  
(vp,
-    kn)

-  
Register a knote kn with the vnode
-      vn. If the operation is successful zero is returned,
-      otherwise an appropriate error code is returned.
-    
The vnode vp remains unlocked throughout
-        the whole operation.

-  

-  
(vp,
-    flags)

-  
Eliminate all activity associated with the vnode vp.
-      The argument flags is a set of flags. If REVOKEALL
-      is set in flags all vnodes aliased to the vnode
-      vp are also eliminated. If the operation is
-      successful zero is returned, otherwise an appropriate error is returned.
-    
The vnode vp remains unlocked throughout
-        the whole operation.

-  

-  
(vp,
-    prot, cred)

-  
Inform file system that vp is in the process of
-      being memory mapped. The argument prot specifies the
-      vm access protection the vnode is going to be mapped with. The argument
-      cred is the caller's credentials. If the file system
-      allows the memory mapping, zero is returned, otherwise an appropriate
-      error code is returned.
-    
Most file systems do not supply a function for
-        ()
-        and use
-        ()
-        to default for success. Only file systems which do not integrate with
-        the page cache at all typically want to disallow memory mapping.

-  

-  
(vp,
-    cred, flags,
-    offlo, offhi)

-  
Flush pending data buffers for a file to disk. The argument
-      vp is the locked vnode of the file for flush. The
-      argument cred is the caller's credentials. The
-      argument flags is a set of flags. If FSYNC_WAIT is
-      specified in flags, the function should wait for I/O
-      to complete before returning. The argument offlo and
-      offhi specify the range of file to flush. If the
-      operation is successful zero is returned, otherwise an appropriate error
-      code is returned.
-    
This function implements the sync(2) and
-        fsync(2) system calls.

-  

-  
(vp,
-    oldoff, newoff,
-    cred)

-  
Test if the file is seekable for the specified offset
-      newoff. The argument vp is the
-      locked vnode of the file to test. For most file systems this function
-      simply tests if newoff is valid. If the specified
-      newoff is less than zero, the function returns error
-      code EINVAL.

-  
(dvp,
-    vp, cnp)

-  
Remove a file. The argument dvp is the locked vnode
-      of the directory to remove the file from and vp is
-      the locked vnode of the file to remove. The argument
-      cnp is the pathname component about the file to
-      remove. If the operation is successful zero is returned, otherwise an
-      appropriate error code is returned. Both dvp and
-      vp are locked on entry and are to be unlocked before
-      returning.

-  
-  
Link to a file. The argument dvp is the locked node
-      of the directory to create the new link and vp is
-      the vnode of the file to be linked. The argument cnp
-      is the pathname component of the new link. If the operation is successful
-      zero is returned, otherwise an error code is returned. The directory vnode
-      dvp should be locked on entry and will be released
-      and unlocked on return. The vnode vp should not be
-      locked on entry and will remain unlocked on return.

-  
VOP_RENAME(fdvp,
-    fvp, fcnp,
-    tdvp, tvp,
-    tcnp)

-  
Rename a file. The argument fdvp is the vnode of the
-      old parent directory containing in the file to be renamed and
-      fvp is the vnode of the file to be renamed. The
-      argument fcnp is the pathname component about the
-      file to be renamed. The argument tdvp is the vnode
-      of the new directory of the target file and tvp is
-      the vnode of the target file (if it exists). The argument
-      tcnp is the pathname component about the file's new
-      name. If the operation is successful zero is returned, otherwise an error
-      code is returned.
-    
The caller must hold the target file system's
-        rename lock. The source directory and file vnodes should be unlocked and
-        their reference counts should be incremented before entry. The target
-        directory and file vnodes should both be locked on entry.
-        ()
-        updates the reference counts prior to returning.

-    
Because of the complexity and nastiness of
-        the interface, please do not write new code that calls
-        ()
-        directly until such time as ongoing cleanup work reaches a point where
-        the interface has been rendered halfway sane.

-  

-  
(dvp,
-    vpp, cnp,
-    vap)

-  
Make a new directory in a given directory. The argument
-      dvp is the locked vnode of the directory to create
-      the new directory in and cnp is the pathname
-      component of the new directory. The argument vap
-      specifies the attributes that the new directory should be created with. If
-      the file is successfully created, the address of the resulting unlocked
-      vnode is returned in vpp and zero is returned.
-    
This function is called after
-        ()
-        when a directory is being created. Normally,
-        VOP_LOOKUP() will have set the SAVENAME flag in
-        cnp->cn_flags to keep the memory pointed to by
-        cnp->cn_pnbuf valid. If an error is detected when
-        creating the directory, this memory is released. If the directory is
-        created successfully it will be released unless the SAVESTART flags in
-        specified in cnp->cn_flags.

-  

-  
(dvp,
-    vp, cnp)

-  
Remove a directory in a given directory. The argument
-      dvp is the locked vnode of the directory to remove
-      the directory from and vp is the locked vnode of the
-      directory to remove. The argument cnp is the
-      pathname component of the directory. Zero is returned on success,
-      otherwise an error code is returned. Both dvp and
-      vp should be locked on entry and will be released
-      and unlocked on return.

-  
-  
Create a symbolic link in a given directory. The argument
-      dvp is the locked vnode of the directory to create
-      the symbolic link in and cnp is the pathname
-      component of the symbolic link. The argument vap
-      specifies the attributes that the symbolic link should be created with and
-      target specifies the pathname of the target of the
-      symbolic link. If the symbolic link is successfully created, the address
-      of the resulting unlocked vnode is returned in vpp
-      and zero is returned.
-    
This function is called after
-        ()
-        when a symbolic link is being created. Normally,
-        VOP_LOOKUP() will have set the SAVENAME flag in
-        cnp->cn_flags to keep the memory pointed to by
-        cnp->cn_pnbuf valid. If an error is detected when
-        creating the symbolic link, this memory is released. If the symbolic
-        link is created successfully it will be released unless the SAVESTART
-        flags in specified in cnp->cn_flags.

-  

-  
VOP_READDIR(vp,
-    uio, cred,
-    eofflag, cookies,
-    ncookies)

-  
Read directory entry. The argument vp is the vnode
-      of the directory to read the contents of and uio is
-      the destination location to read the contents into. The argument
-      cred is the caller's credentials. The argument
-      eofflag is the pointer to a flag which is set by
-      VOP_READDIR() to indicate an end-of-file
-      condition. If eofflag is
-      NULL, the end-of-file condition is not returned.
-      The arguments cookies and
-      ncookies specify the addresses for the list and
-      number of directory seek cookies generated for NFS. Both
-      cookies and ncookies should be
-      NULL if they aren't required to be returned by
-      VOP_READDIR(). The directory contents are read
-      into struct dirent structures and uio->uio_offset
-      is set to the offset of the next unread directory entry. This offset may
-      be used in a following invocation to continue a sequential read of the
-      directory contents. If the operation is successful zero is returned,
-      otherwise an appropriate error code is returned.
-    
The directory should be locked on entry and will remain locked
-        on return.

-    
In case ncookies and
-        cookies are supplied, one cookie should be
-        returned per directory entry. The value of the cookie for each directory
-        entry should be the offset within the directory where the on-disk
-        version of the following directory entry starts. That is, for each
-        directory entry i, the corresponding cookie should
-        refer to the offset of directory entry i + 1.

-    
Note that the cookies
-        array must be allocated by the callee using the M_TEMP malloc type as
-        callers of
-        ()
-        must be able to free the allocation.

-  

-  
-  
Read the contents of a symbolic link. The argument
-      vp is the locked vnode of the symlink and
-      uio is the destination location to read the contents
-      into. The argument cred is the credentials of the
-      caller. If the operation is successful zero is returned, otherwise an
-      error code is returned.
-    
The vnode should be locked on entry and will remain locked on
-        return.

-  

-  
(dvp,
-    cnp)

-  
Abort pending operation on vnode dvp and free
-      resources allocated in cnp.
-    
This operation is rarely implemented in
-        file systems and
-        ()
-        is typically used instead.

-  

-  
(vp)

-  
Release the inactive vnode. VOP_INACTIVE() is
-      called when the kernel is no longer using the vnode. This may be because
-      the reference count reaches zero or it may be that the file system is
-      being forcibly unmounted while there are open files. It can be used to
-      reclaim space for open but deleted files. The argument
-      vp is the locked vnode to be released. If the
-      operation is successful zero is returned, otherwise an appropriate error
-      code is returned. The vnode vp must be locked on
-      entry, and will remain locked on return.

-  
(vp)

-  
Reclaim the vnode for another file system.
-      VOP_RECLAIM() is called when a vnode is being
-      reused for a different file system. Any file system specific resources
-      associated with the vnode should be freed. The argument
-      vp is the vnode to be reclaimed. If the operation is
-      successful zero is returned, otherwise an appropriate error code is
-      returned. The vnode vp should be locked on entry,
-      and will be returned unlocked.

-  
(vp,
-    flags)

-  
Sleep until vnode lock is free. The argument vp is
-      the vnode of the file to be locked. The argument
-      flags is LK_EXCLUSIVE to
-      take the lock exclusively or LK_SHARED to take a
-      shared lock. If flags contains
-      LK_NOWAIT and the lock is busy, the operation will
-      return immediately with an error code. If flags
-      contains LK_RETRY this is a hint the caller wants
-      the lock on dead vnodes too. If the operation is successful zero is
-      returned, otherwise an appropriate error code is returned.
-      VOP_LOCK() is used to serialize access to the file
-      system such as to prevent two writes to the same file from happening at
-      the same time. Kernel code should use vn_lock(9) to lock
-      a vnode rather than calling VOP_LOCK()
-    directly.

-  
(vp)

-  
Wake up process sleeping on lock. The argument vp is
-      the vnode of the file to be unlocked. If the operation is successful zero
-      is returned, otherwise an appropriate error code is returned.
-      VOP_UNLOCK() is used to serialize access to the
-      file system such as to prevent two writes to the same file from happening
-      at the same time.

-  
(vp)

-  
Test if the vnode vp is locked. Possible return
-      values are LK_EXCLUSIVE,
-      LK_SHARED or 0 for lock held exclusively by the
-      calling thread, shared lock held by anyone or unlocked, respectively.
-    
This function must never be used to make locking decisions at
-        run time: it is provided only for diagnostic purposes.

-  

-  
(vp,
-    bn, vpp,
-    bnp, runp)

-  
Convert the logical block number bn of a file
-      specified by vnode vp to its physical block number
-      on the disk. The physical block is returned in bnp.
-      In case the logical block is not allocated, -1 is used.
-    
If vpp is not
-        NULL, the vnode of the device vnode for the file
-        system is returned in the address specified by
-        vpp. If runp is not
-        NULL, the number of contiguous blocks starting
-        from the next block after the queried block will be returned in
-        runp.

-  

-  
(vp)

-  
Print debugging information. The argument vp is the
-      vnode to print. If the operation is successful zero is returned, otherwise
-      an appropriate error code is returned.

-  
(vp,
-    name, retval)

-  
Implement POSIX pathconf(2) and
-      fpathconf(2) support. The argument
-      vp is the locked vnode to get information about. The
-      argument name specified the type of information to
-      return. The information is returned in the address specified by
-      retval. Valid values for name
-      are:
-    

-    

-    

-      
_PC_LINK_MAX

-      
return the maximum number of links to a file

-      
_PC_NAME_MAX

-      
return the maximum number of bytes in a file name

-      
_PC_PATH_MAX

-      
return the maximum number of bytes in a pathname

-      
_PC_PIPE_BUF

-      
return the maximum number of bytes which will be written atomically to
-          a pipe

-      
_PC_CHOWN_RESTRICTED

-      
return 1 if appropriate privileges are required for the
-          chown(2) system call, otherwise zero

-      
_PC_NO_TRUNC

-      
return 0 if file names longer than {NAME_MAX}
-          are silently truncated

-    

-    

-    
If name is recognized,
-        *retval is set to the specified value and zero is
-        returned, otherwise an appropriate error is returned.

-  

-  
(vp,
-    id, op,
-    fl, flags)

-  
Manipulate Advisory record locks on a vnode. The argument
-      vp is the vnode on which locks are manipulated. The
-      argument id is the id token which is changing the
-      lock and op is the fcntl(2)
-      operation to perform. Valid values are:
-    

-    

-    

-      
F_SETLK

-      
set lock

-      
F_GETLK

-      
get the first conflicted lock

-      
F_UNLCK

-      
clear lock

-    

-    

-    
The argument fl is a
-        description of the lock. In the case of
-        SEEK_CUR, The caller should add the current file
-        offset to fl->l_start beforehand.
-        ()
-        treats SEEK_CUR as
-        SEEK_SET.

-    
The argument flags is the set of flags.
-        Valid values are:

-    

-    

-    

-      
F_WAIT

-      
wait until lock is granted

-      
F_FLOCK

-      
use flock(2) semantics for lock

-      
F_POSIX

-      
use POSIX semantics for lock

-    

-    

-    
If the operation is successful zero is returned, otherwise an
-        appropriate error is returned.

-  

-  
(dvp,
-    cnp, flags)

-  
Whiteout pathname component in directory with vnode
-      dvp. The argument cnp
-      specifies the pathname component to whiteout.
-    
The vnode dvp should be locked on entry
-        and will remain locked on return.

-  

-  
(vp,
-    offset, m,
-    count, centeridx,
-    access_type, advice,
-    flags)

-  
Read VM pages from file. The argument vp is the
-      locked vnode to read the VM pages from. The argument
-      offset is offset in the file to start accessing and
-      m is an array of VM pages. The argument
-      count points a variable that specifies the number of
-      pages to read. If the operation is successful zero is returned, otherwise
-      an appropriate error code is returned. If PGO_LOCKED is specified in
-      ,
-      VOP_GETPAGES() might return less pages than
-      requested. In that case, the variable pointed to by
-      
-      will be updated.
-    
This function is primarily used by the page-fault handing
-        mechanism.

-  

-  
(vp,
-    offlo, offhi,
-    flags)

-  
Write modified (dirty) VM pages to file. The argument
-      vp is the vnode to write the VM pages to. The
-      vnode's vm object lock (v_uobj.vmobjlock) must be
-      held by the caller and will be released upon return. The arguments
-      offlo and offhi specify the
-      range of VM pages to write. In case offhi is given
-      as 0, all pages at and after the start offset offlo
-      belonging the vnode vp will be written. The argument
-      flags controls the behavior of the routine and takes
-      the vm pager's flags (PGO_ -prefixed). If the
-      operation is successful zero is returned, otherwise an appropriate error
-      code is returned.
-    
The function is primarily used by the
-        pageout handling mechanism and is commonly implemented indirectly by
-        ()
-        with the help of
-        ()
-        and VOP_BMAP().

-  

-  
VOP_STRATEGY(vp,
-    bp)

-  
Read/write a file system buffer. The argument vp is
-      the vnode to read/write to. The argument bp is the
-      buffer to be read or written. VOP_STRATEGY() will
-      either read or write data to the file depending on the value of
-      .
-      If the operation is successful zero is returned, otherwise an appropriate
-      error code is returned.

-  
(vp,
-    bp)

-  
Write a file system buffer. The argument vp is the
-      vnode to write to. The argument bp specifies the
-      buffer to be written. If the operation is successful zero is returned,
-      otherwise an appropriate error code is returned.

-  
(vp,
-    attrnamespace, name,
-    uio, size,
-    cred)

-  
Get an extended attribute. The argument vp is the
-      locked vnode of the file or directory from which to retrieve the
-      attribute. The argument attrnamespace specifies the
-      extended attribute namespace. The argument name is a
-      nul-terminated character string naming the attribute to retrieve. The
-      argument uio, if not NULL,
-      specifies where the extended attribute value is to be written. The
-      argument size, if not NULL,
-      will contain the number of bytes required to read all of the attribute
-      data upon return. In most cases, uio will be
-      NULL when size is not, and
-      vice versa. The argument cred specifies the user
-      credentials to use when authorizing the request.

-  
(vp,
-    attrnamespace, name,
-    uio, cred)

-  
Set an extended attribute. The argument vp is the
-      locked vnode of the file or directory to which to store the attribute. The
-      argument namespace specifies the extended attribute
-      namespace. The argument name is a nul-terminated
-      character string naming the attribute to store. The argument
-      uio specifies the source of the extended attribute
-      data. The argument cred specifies the user
-      credentials to use when authorizing the request.

-  
(vp,
-    attrnamespace, uio,
-    size, cred)

-  
Retrieve the list of extended attributes. The argument
-      vp is the locked vnode of the file or directory
-      whose attributes are to be listed. The argument
-      attrnamespace specifies the extended attribute
-      namespace. The argument uio, if not
-      NULL, specifies where the extended attribute list
-      is to be written. The argument size, if not
-      NULL, will contain the number of bytes required to
-      read all of the attribute names upon return. In most cases,
-      uio will be NULL when
-      size is not, and vice versa. The argument
-      cred specifies the user credentials to use when
-      authorizing the request.

-  
(vp,
-    attrnamespace, name,
-    cred)

-  
Remove attribute name from file associated with
-      vp. The argument attrnamespace
-      specifies the extended attribute namespace. If full removal is not
-      supported, the file system should return
-      EOPNOTSUPP to allow the caller to zero out the
-      value with VOP_SETEXTATTR().
-    
The vnode vp should be locked on entry
-        and will remain locked on return.

-  

-

-

-

-

-
src/sys/kern/vnode_if.src contains the
-    list of vnode functions, their definitions and an exact locking
-  protocol.

-

-

-

-

-  
[]

-  
Access for the specified operation is denied.

-  
[]

-  
Quota exceeded.

-  
[]

-  
attempt to read from an illegal offset in the directory; unrecognized
-      input

-  
[]

-  
a read error occurred while reading the directory or reading the contents
-      of a symbolic link

-  
[]

-  
A CREATE or RENAME operation would be successful.

-  
[]

-  
The requested attribute is not defined for this vnode.

-  
[]

-  
The component was not found in the directory.

-  
[]

-  
The file system is full.

-  
[]

-  
The vnode does not represent a directory.

-  
[]

-  
attempt to remove a directory which is not empty

-  
[]

-  
an attempt was made to change an immutable file

-  
[]

-  
the file system is read-only

-

-

-

-

-
extattr(9), intro(9),
-    namei(9), vattr(9),
-    vfs(9), vfsops(9),
-    vnode(9)

-

-

-

-
The vnode operations vector, its functions and the corresponding
-    macros appeared in 4.3BSD.

-

-

-
-  
-    
-    
-  
-
June 15, 2023NetBSD 10.1

diff --git a/static/netbsd/man9/wapbl.9 3.html b/static/netbsd/man9/wapbl.9 3.html
deleted file mode 100644
index 241ea757..00000000
--- a/static/netbsd/man9/wapbl.9 3.html	
+++ /dev/null
@@ -1,424 +0,0 @@
-
-  
-    
-    
-    
-  
-
WAPBL(9)Kernel Developer's ManualWAPBL(9)

-

-

-

-
WAPBL,
-    wapbl_start, wapbl_stop,
-    wapbl_begin, wapbl_end,
-    wapbl_flush, wapbl_discard,
-    wapbl_add_buf,
-    wapbl_remove_buf,
-    wapbl_resize_buf,
-    wapbl_register_inode,
-    wapbl_unregister_inode,
-    wapbl_register_deallocation,
-    wapbl_jlock_assert,
-    wapbl_junlock_assert —
-    write-ahead physical block logging for file
-  systems

-

-

-

-
#include
-    <sys/wapbl.h>

-
typedef void (*wapbl_flush_fn_t)(struct mount *,
-    daddr_t *, int *, int);

-
int
-  

-  wapbl_start(struct
-    wapbl **wlp, struct mount
-    *mp, struct vnode
-    *devvp, daddr_t
-    off, size_t count,
-    size_t blksize,
-    struct wapbl_replay *wr,
-    wapbl_flush_fn_t flushfn,
-    wapbl_flush_fn_t
-    flushabortfn);

-
int
-  

-  wapbl_stop(struct
-    wapbl *wl, int
-    force);

-
int
-  

-  wapbl_begin(struct
-    wapbl *wl, const char
-    *file, int
-  line);

-
void
-  

-  wapbl_end(struct
-    wapbl *wl);

-
int
-  

-  wapbl_flush(struct
-    wapbl *wl, int
-    wait);

-
void
-  

-  wapbl_discard(struct
-    wapbl *wl);

-
void
-  

-  wapbl_add_buf(struct
-    wapbl *wl, struct buf
-    *bp);

-
void
-  

-  wapbl_remove_buf(struct
-    wapbl *wl, struct buf
-    *bp);

-
void
-  

-  wapbl_resize_buf(struct
-    wapbl *wl, struct buf
-    *bp, long oldsz,
-    long oldcnt);

-
void
-  

-  wapbl_register_inode(struct
-    wapbl *wl, ino_t
-    ino, mode_t
-  mode);

-
void
-  

-  wapbl_unregister_inode(struct
-    wapbl *wl, ino_t
-    ino, mode_t
-  mode);

-
void
-  

-  wapbl_register_deallocation(struct
-    wapbl *wl, daddr_t
-    blk, int len);

-
void
-  

-  wapbl_jlock_assert(struct
-    wapbl *wl);

-
void
-  

-  wapbl_junlock_assert(struct
-    wapbl *wl);

-

-

-

-
WAPBL, or
-    , is an abstraction for file systems to write
-    physical blocks in the buffercache(9) to a bounded-size
-    log first before their real destinations on disk. The name means:

-

-

-  
logging

-  
batches of writes are issued atomically via a log

-  
physical block

-  
only physical blocks, not logical file system operations, are stored in
-      the log

-  
write-ahead

-  
before writing a block to disk, its new content, rather than its old
-      content for roll-back, is recorded in the log

-

-

-
When a file system using
-    WAPBL issues writes (as in
-    bwrite(9) or bdwrite(9)), they are
-    grouped in batches called
-    
-    in memory, which are serialized to be consistent with program order before
-    WAPBL submits them to disk atomically.

-
Thus, within a transaction, after one write, another write need
-    not wait for disk I/O, and if the system is interrupted, e.g. by a crash or
-    by power failure, either both writes will appear on disk, or neither
-  will.

-
When a transaction is full, it is written to a circular
-    buffer on disk called the
-    . When the
-    transaction has been written to disk, every write in the transaction is
-    submitted to disk asynchronously. Finally, the file system may issue new
-    writes via WAPBL once enough writes submitted to
-    disk have completed.

-
After interruption, such as a crash or power failure, some writes
-    issued by the file system may not have completed. However, the log is
-    written consistently with program order and before file system writes are
-    submitted to disk. Hence a consistent program-order view of the file system
-    can be attained by resubmitting the writes that were successfully stored in
-    the log using wapbl_replay(9). This may not be the same
-    state just before interruption — writes in transactions that did not
-    reach the disk will be excluded.

-
For a file system to use
-    WAPBL, its VFS_MOUNT(9) method
-    should first replay any journal on disk using
-    wapbl_replay(9), and then, if the mount is read/write,
-    initialize WAPBL for the mount by calling
-    ().
-    The VFS_UNMOUNT(9) method should call
-    ().

-
Before issuing any
-    buffercache(9) writes, the file system must acquire a
-    shared lock on the current WAPBL transaction with
-    (),
-    which may sleep until there is room in the transaction for new writes. After
-    issuing the writes, the file system must release its shared lock on the
-    transaction with wapbl_end(). Either all writes
-    issued between wapbl_begin() and
-    wapbl_end() will complete, or none of them will.

-
File systems may also witness an
-     lock
-    on the current transaction when WAPBL is flushing
-    the transaction to disk, or aborting a flush, and invokes a file system's
-    callback. File systems can assert that the transaction is locked with
-    (),
-    or not
-    
-    locked, with wapbl_junlock_assert().

-
If a file system requires multiple
-    transactions to initialize an inode, and needs to destroy partially
-    initialized inodes during replay, it can register them by
-    ino_t inode number before initialization with
-    ()
-    and unregister them with
-    ()
-    once initialization is complete. WAPBL does not
-    actually concern itself whether the objects identified by
-    ino_t values are ‘inodes’ or
-    ‘quaggas’ or anything else — file systems may use this
-    to list any objects keyed by ino_t value in the
-  log.

-
When a file system frees resources on disk and issues writes to
-    reflect the fact, it cannot then reuse the resources until the writes have
-    reached the disk. However, as far as the buffercache(9) is
-    concerned, as soon as the file system issues the writes, they will appear to
-    have been written. So the file system must not attempt to reuse the resource
-    until the current WAPBL transaction has been flushed
-    to disk.

-
The file system can defer freeing
-    a resource by calling
-    ()
-    to record the disk address of the resource and length in bytes of the
-    resource. Then, when WAPBL next flushes the
-    transaction to disk, it will pass an array of the disk addresses and lengths
-    in bytes to a file-system-supplied callback. (Again,
-    WAPBL does not care whether the ‘disk
-    address’ or ‘length in bytes’ is actually that; it will
-    pass along daddr_t and int
-    values.)

-

-

-

-

-  
wapbl_start(wlp,
-    mp, devvp,
-    off, count,
-    blksize, wr,
-    flushfn, flushabortfn)

-  
Start using WAPBL for the file system mounted at
-      mp, storing a log of count
-      disk sectors at disk address off on the block device
-      devvp writing blocks in units of
-      blksize bytes. On success, stores an opaque
-      struct wapbl * cookie in
-      *wlp for use with the other
-      WAPBL routines and returns zero. On failure,
-      returns an error number.
-    
If the file system had replayed the log
-        with wapbl_replay(9), then wr
-        must be the struct wapbl_replay * cookie used to
-        replay it, and
-        ()
-        will register any inodes that were in the log as if with
-        wapbl_register_inode(); otherwise
-        wr must be NULL.

-    
flushfn is a callback
-        that WAPBL will invoke as
-        flushfn (mp,
-        deallocblks, dealloclens,
-        dealloccnt) just before it flushes a transaction
-        to disk, with the an exclusive lock held on the transaction, where
-        mp is the mount point passed to
-        (),
-        deallocblks is an array of
-        dealloccnt disk addresses, and
-        dealloclens is an array of
-        dealloccnt lengths, corresponding to the addresses
-        and lengths the file system passed to
-        wapbl_register_deallocation(). If flushing the
-        transaction to disk fails, WAPBL will call
-        flushabortfn with the same arguments to undo any
-        effects that flushfn had.

-  

-  
wapbl_stop(wl,
-    force)

-  
Flush the current transaction to disk and stop using
-      WAPBL. If flushing the transaction fails and
-      force is zero, return error. If flushing the
-      transaction fails and force is nonzero, discard the
-      transaction, permanently losing any writes in it. If flushing the
-      transaction is successful or if force is nonzero,
-      free memory associated with wl and return zero.

-  
wapbl_begin(wl,
-    file, line)

-  
Wait for space in the current transaction for new writes, flushing it if
-      necessary, and acquire a shared lock on it.
-    
The lock is not exclusive: other threads may acquire shared
-        locks on the transaction too. The lock is not recursive: a thread may
-        not acquire it again without calling wapbl_end
-        first.

-    
May sleep.

-    
file and line are
-        the file name and line number of the caller for debugging purposes.

-  

-  
(wl)

-  
Release a shared lock on the transaction acquired with
-      wapbl_begin().

-  
(wl,
-    wait)

-  
Flush the current transaction to disk. If wait is
-      nonzero, wait for all writes in the current transaction to complete.
-    
The current transaction must not be locked.

-  

-  
(wl)

-  
Discard the current transaction, permanently losing any writes in it.
-    
The current transaction must not be locked.

-  

-  
(wl,
-    bp)

-  
Add the buffer bp to the current transaction, which
-      must be locked, because someone has asked to write it.
-    
This is meant to be called from within
-        buffercache(9), not by file systems directly.

-  

-  
(wl,
-    bp)

-  
Remove the buffer bp, which must have been added
-      using wapbl_add_buf, from the current transaction,
-      which must be locked, because it has been invalidated (or XXX ???).
-    
This is meant to be called from within
-        buffercache(9), not by file systems directly.

-  

-  
(wl,
-    bp, oldsz,
-    oldcnt)

-  
Note that the buffer bp, which must have been added
-      using wapbl_add_buf, has changed size, where
-      oldsz is the previous allocated size in bytes and
-      oldcnt is the previous number of valid bytes in
-      bp.
-    
This is meant to be called from within
-        buffercache(9), not by file systems directly.

-  

-  
(wl,
-    ino, mode)

-  
Register ino with the mode
-      mode as commencing initialization.

-  
(wl,
-    ino, mode)

-  
Unregister ino, which must have previously been
-      registered with wapbl_register_inode using the same
-      mode, now that its initialization has
-    completed.

-  
wapbl_register_deallocation(wl,
-    blk, len)

-  
Register len bytes at the disk address
-      blk as ready for deallocation, so that they will be
-      passed to the flushfn that was given to
-      wapbl_start().

-  
wapbl_jlock_assert(wl)

-  
Assert that the current transaction is locked.
-    
Note that it might not be locked by the current
-        thread: this assertion passes if
-         thread has it
-        locked.

-  

-  
(wl)

-  
Assert that the current transaction is not exclusively locked by the
-      current thread.
-    
Users of WAPBL
-        observe exclusive locks only in the flushfn and
-        flushabortfn callbacks to
-        ().
-        Outside of such contexts, the transaction is never exclusively locked,
-        even between wapbl_begin() and
-        wapbl_end().

-    
There is no way to assert that the current
-        transaction is not locked at all — i.e., that the caller may
-        acquire a shared lock on the transaction with
-        ()
-        without danger of deadlock.

-  

-

-

-

-

-
The WAPBL subsystem is implemented in
-    sys/kern/vfs_wapbl.c, with hooks in
-    sys/kern/vfs_bio.c.

-

-

-

-
buffercache(9), vfsops(9),
-    wapbl_replay(9)

-

-

-

-
WAPBL works only for file system metadata
-    managed via the buffercache(9), and provides no way to log
-    writes via the page cache, as in VOP_GETPAGES(9),
-    VOP_PUTPAGES(9), and ubc_uiomove(9),
-    which is normally used for file data.

-
Not only is WAPBL unable to log writes via
-    the page cache, it is also unable to defer buffercache(9)
-    writes until cached pages have been written. This manifests as the
-    well-known garbage-data-appended-after-crash bug in FFS: when appending to a
-    file, the pages containing new data may not reach the disk before the inode
-    update reporting its new size. After a crash, the inode update will be on
-    disk, but the new data will not be — instead, whatever garbage data
-    in the free space will appear to have been appended to the file.
-    WAPBL exacerbates the problem by increasing the
-    throughput of metadata writes, because it can issue many metadata writes
-    asynchronously that FFS without WAPBL would need to
-    issue synchronously in order for fsck(8) to work.

-
The criteria for when the transaction must be flushed to disk
-    before wapbl_begin() returns are heuristic, i.e.
-    wrong. There is no way for a file system to communicate to
-    wapbl_begin() how many buffers, inodes, and
-    deallocations it will issue via WAPBL in the
-    transaction.

-
WAPBL mainly supports write-ahead, and has
-    only limited support for rolling back operations, in the form of
-    wapbl_register_inode() and
-    wapbl_unregister_inode(). Consequently, for example,
-    large writes appending to a file, which requires multiple disk block
-    allocations and an inode update, must occur in a single transaction —
-    there is no way to roll back the disk block allocations if the write fails
-    in the middle, e.g. because of a fault in the middle of the user buffer.

-
wapbl_jlock_assert() does not guarantee
-    that the current thread has the current transaction locked.
-    wapbl_junlock_assert() does not guarantee that the
-    current thread does not have the current transaction locked at all.

-
There is only one WAPBL transaction for
-    each file system at any given time, and only one
-    WAPBL log on disk. Consequently, all writes are
-    serialized. Extending WAPBL to support multiple logs
-    per file system, partitioned according to an appropriate scheme, is left as
-    an exercise for the reader.

-
There is no reason for WAPBL to require
-    its own hooks in buffercache(9).

-
The on-disk format used by WAPBL is
-    undocumented.

-

-

-
-  
-    
-    
-  
-
March 26, 2015NetBSD 10.1

diff --git a/static/netbsd/man9/wsbell.9 3.html b/static/netbsd/man9/wsbell.9 3.html
deleted file mode 100644
index 05dad7f0..00000000
--- a/static/netbsd/man9/wsbell.9 3.html	
+++ /dev/null
@@ -1,103 +0,0 @@
-
-  
-    
-    
-    
-  
-
WSBELL(9)Kernel Developer's ManualWSBELL(9)

-

-

-

-
wsbell,
-    wsbelldevprint — wscons
-    system bell support

-

-

-

-
#include
-    <dev/wscons/wsconsio.h>
-  

-  #include
-    <dev/wscons/wsbellvar.h>

-
int
-  

-  wsbelldevprint(void
-    *aux, const char
-    *pnp);

-

-

-

-
The wsbell module is a component of the
-    wscons(9) framework, providing keyboard-independent bell
-    support. All of the support is provided by the wsbell(4)
-    device driver, which must be a child of the hardware device driver. The only
-    hardware device drivers that can provide a wsbell
-    facility are speaker(4) devices.

-

-

-

-
Speaker drivers providing support for wscons bell devices will
-    make use of the following data types:

-

-  
struct wsbelldev_attach_args

-  
A structure used to attach the wsbell(4) child device.
-      It has the following members:
-    

-    
	void *accesscookie;

-    

-  

-

-

-

-

-

-  
(aux,
-    pnp)

-  
The default wsbell printing routine used by
-      ().
-      (see autoconf(9)).

-

-

-

-

-
Speaker drivers which want to use the wsbell module must be a
-    parent to the wsbell(4) device and provide an attachment
-    interface. To attach the wsbell(4) device, the speaker
-    driver must allocate and populate a
-    wsbelldev_attach_args structure with a pointer to the
-    parent's device structure as an access cookie and call
-    config_found() to perform the attach (see
-    autoconf(9)).

-

-

-

-
When a bell event is received on a wsdisplay(4)
-    device the system bell is sounded.

-

-

-

-
The wscons subsystem is implemented within the directory
-    sys/dev/wscons. The wsbell
-    module itself is implement within the file
-    sys/dev/wscons/wsbell.c. ioctl(2)
-    operations are listed in
-  sys/dev/wscons/wsconsio.h.

-

-

-

-
ioctl(2), wsbell(4),
-    wscons(4), wskbd(4),
-    autoconf(9), driver(9),
-    intro(9), wscons(9),
-    wsdisplay(9), wskbd(9)

-

-

-
-  
-    
-    
-  
-
June 30, 2017NetBSD 10.1

-- 
cgit v1.2.3